M2MGen - An Application Generator for Machine to

Machine (M2M) Applications

Chanan Glezer

, Sudha Krishnamurthy

, Kilian Schloeder

Omer Anson

and Gil Tahan

Deustche Telekom AG Labs at Ben Gurion University of the Negev

Beer Sheva 84105, Israel

Deutsche Telekom AG Labs, D-10587 Berlin, Germany

Abstract. This research conceptualizes an architecture (M2MGen) aimed at

generating M2M applications as a service offered by a telecommunications

network provider. M2MGen employs various plug-ins and knowledge con-

structs which can be configured to meet requirements of clients from various

industry sectors interested in deploying M2M applications. The architecture

addresses the following aspects: Data-acquisition Management, Communica-

tion Management, Business-service Management and Control Management.

1 Introduction

Machine to Machine (M2M) is a term used to describe the technologies that enable

computers, embedded processors, smart sensors, actuators and mobile devices to

communicate with one another, take measurements and make decisions - often with-

out human intervention [1].

M2M enabling technologies add value in a variety of application domains. The con-

sumer goods supply-chain (via RFID on UHF bands), homeland-security, facility

management, military, automotive industry, and the health care sector have each had

major efforts in sensor networking over the past several years and decades [2-4, 8-

10].

2 Related Work

In the consumer goods sector, the support of a broad array of major firms such as

Wal-Mart, Gillette, and Procter & Gamble has contributed to RFID’s momentum and

has helped advance the formation of standards via EPCglobal. Both Wal-Mart and the

Department of Defense have mandated suppliers to deliver EPC-tagged cases and

pallets that are ready for RFID tracking. Broad adoption of case- and pallet-level

Glezer C., Krishnamurthy S., Schloeder K., Anson O. and Tahan G. (2007).

M2MGen - An Application Generator for Machine to Machine (M2M) Applications.

In Proceedings of the 1st International Workshop on RFID Technology - Concepts, Applications, Challenges, pages 133-140

DOI: 10.5220/0002411301330140

 SciTePress

tagging is expected by 2007 or 2008. Forecasts by various market researchers indicate

the RFID tracking market will reach more than $4 billion in 2007 [2].

Among the key initiatives of the Homeland Security Agency is to develop a common

data highway for a comprehensive set of homeland security sensors. The US DoD’s

Global Information Grid (GIG)

has been a major program emphasizing broad use

of advanced information technologies (IT) to create “decision superiority” by provid-

ing the ability to collect, fuse, process and disseminate an uninterrupted flow of in-

formation, command and control.

The automotive industry has historically been a driver of low-cost, rugged sensors.

Next-generation sensor systems for automotive applications must operate in an in-

creasingly networked environment. FlexRay

is a communication system developed

by a consortium founded in 2000 by BMW, DaimlerChrysler, Motorola, and Philips

Semiconductors that now has nearly all major players in the world committed.

FlexRay is designed for the high data transmission rates required by advanced auto-

motive control systems. These systems are expected to replace nearly every hydraulic

line and mechanical cable in today's automobiles with wire-based networks.

Devices within the health care system generally do not function as a system - yet in

many cases would benefit from such an approach. This creates a number of limita-

tions, including the inability to easily fuse data, share resources, upgrade algorithms,

and systematically collect data for further analysis. CIMIT

, a consortium of Harvard

teaching hospitals with scientists and engineers from Massachusetts Institute of Tech-

nology (MIT) and Charles Stark Draper Laboratory (supported by over 50 major

pharmaceutical and medical device firms), is applying a systems perspective and

introducing new technologies in re-architecting an array of current medical systems.

Specific design goals are for networks that 1) support a variety of devices in a reli-

able, yet flexible manner, 2) are sufficiently low-cost to make wide deployment feasi-

ble, and 3) are sufficiently simple so that they can be installed and used by existing

personnel during a medical procedure - all in a way that makes it easy for medical

professionals to act on relevant information in real time.

The Facility Management domain and its typical scenarios is the chosen test bed for

the proposed M2MGen Platform. Examples of M2M-enabled applications for facility

management include Frankfurt’s Airport (Fraport) which implemented a new mainte-

nance process replacing the paper-based process with mobile and RFID technology

[9]. Fraport’s air-conditioning and ventilation system has 22,000 automatic fire shut-

ters and numerous fire doors and smoke detectors. The new system’s architecture

consists of RFID tags on the fire shutters; mobile devices bundled with an RFID

reader and mobile application; and an SAP-based middleware interconnecting with a

back-end asset management system. Pakanen et al. [8] proposed a system where a

http://www.mitre.org/news/the_edge/july_01/miller.html

http://www.vector-imagineering.com/vi_flexray_solutions_en,,223.html

www.cimit.org

134

microprocessor device interfaced to an Air Handling Unit (AHU). The idea was to

observe the recently installed AHU in order to see if it fulfils the requirements set by

the customer. The microprocessor device measured temperatures at a number of loca-

tions, such as the leaving water temperature of the heating coil, the supply air tem-

perature and the outdoor temperature. Sensor data from the AHU was relayed to the

Internet through a Public Switch Telephony Network (PSTN) and GSM networks. In

addition, a Web-user interface was created to enable remote control of the AHU.

Watson et al. [10] applied M2M technology to five commercial buildings in a test of

Demand Responsive (DR) energy management. The goal was to reduce electric de-

mand when a remote price signal rose above a predetermined price. Chow et al. [3]

present an RFID based Resource Management System (RFID-RMS). The system is

designed to help users to select the most suitable resource usage packages for han-

dling warehouse operation orders by retrieving and analyzing useful knowledge from

a case-based repository of solutions in both a time saving and cost effective manner.

Jedermann et al. [4] propose a quality index for controlling quality of agricultural

products in transit. This index was generated from raw values that could be perma-

nently measured inside a container. These are the environmental conditions like tem-

perature and humidity and gaseous metabolism products like carbon dioxide and

ethylene. The autonomous monitoring system for means of transport (MOT) consists

of three layers: the sensor nodes, an internal wireless network and the assessing unit.

3 Problem Statement

Forrester Research analyzed the M2M software vendors and categorized them into

four broad areas: RFID pure plays, application vendors, platform giants, and integra-

tion specialists [6]. Each of these groups has a different focus. Pure plays offer prod-

ucts that integrate with RFID readers, filter and aggregate data, and incorporate busi-

ness rules. Application vendors market a plethora of RFID-compatible applications

from warehouse and asset management to more sophisticated solutions with reader

coordination, data filtering, and business logic capabilities. Platform giants are pro-

viders of strategic RFID middleware architecture, which leverages the vendors’ ap-

plication development, data management, and process integration products. Finally,

integration specialists add RFID capabilities such as reader coordination to their ex-

isting technologies.

M2M-enabled applications are typically tailor-assembled per customer by combining

instruments from a technological “toolbox” comprising among others: standardized

communication protocols, RFID/sensor technologies, and middleware (event process-

ing, billing, integration, and interfaces with legacy enterprise application).

There has been no attempt however to provide a single, generic platform capable of

defining, generating, deploying and managing a variety of M2M applications in dif-

ferent application domains (i.e., facility management, transportation and logistics,

health, military, automotive, etc.). It is expected that such a model and system can

simplify and enhance the efficiency of handling M2M-enabled application especially

for Small-Medium Enterprises (SMEs). Such organizations are usually not equipped

135

with the know-how and experience for handling the complexities in deploying M2M-

enabled applications. The goal of this paper is to present a conceptual model of such a

platform, namely the M2M application generator (M2MGen) which is currently de-

veloped and tested by deploying a variety of scenarios in the area of Facility Man-

agement.

4 The M2MGen Architecture

Figure 1 depicts the architecture we propose for an M2M application generator

(M2MGen). The architecture comprises of the following three elements in congru-

ence with the above requirements: Data Acquisition, Communication, Business Ser-

vice and Control Management.

Data Acquisition Managers (DAM) is in charge of importing AIDC data from vari-

ous readers that interact with a plethora of sensors. The DAM serves as an interface

for configuring various AIDC devices (i.e., readers, analogue sensors) and accommo-

dating new devices via a standard API. The DAM communicates with numerous

RFID readers and other devices and the information collected about an RFID tag or

other devices is then forwarded to the BSM. The DAM resolves the heterogeneity

among readers, converting different read records into a single representation.

Communication Manager (COM) is responsible for connecting multiple DAM

servers with the BSM. The main purpose of the COM is to mobilize AIDC data, con-

figuration commands, and notifications about situations (business events) across the

M2M platform network. The COM supports both wired/wireless communications for

long/short ranges across Internet/Intranet/Extranet networking infrastructures.

Business Service Manager (BSM) receives AIDC raw events collected and transmit-

ted by one or more DAMs. The goal of the BSM is to store, process and analyze the

AIDC low-level events, thereby inferencing and alerting about new or changing situa-

tions (business events) such as equipment malfunctions; transactions; service re-

quests; EPC

Global product decoding (lookups). The BSM incorporates knowledge

of various kinds to support its functionalities such as: rules for conversion of low-

level to business-level events (Complex Event Processing using IBM’s AMiT

); de-

pendability and failure prediction algorithms (using SHARPE

) incorporating thresh-

olds and critical values for alerts with varying urgency-levels; subscription rules for

situation notifications propagated to human users ,(facility managers, technicians etc.)

and external applications such as Enterprise Resource Planning (ERP), Supply Chain

Management (SCM), Customer Relationship Management (CRM), etc. Business

events generated by the BSM need to be prioritized and distributed based on the ca-

pacities of their subscribers (human and application consumers) to handle the events.

www.epcglobal.org

http://www.haifa.il.ibm.com/dept/services/soms_ebs.html

http://www.ee.duke.edu/~kst/

136

Control Manager (CON) is responsible for managing the configuration of the M2M

platform, that is, deploying the various managers and incorporating knowledge about

the usage scenarios. The scenarios, modeled by defining CEP rules including critical

thresholds, are uploaded into the BSM upon deployment of the application instance

for each client of the system. The CON can duplicate instances of the managers or

employ virtualization technology which enables separation of the three managers

Fig. 1. Architecture of M2MGen Platform.

(COM, BSM, DAM) of different clients on the same physical machine. This later will

also provide better security because data of different clients will be separated.

All in all, the M2MGen platform network includes many instances of DAMs. Each

DAM instance serves one customer and is connected to its supervising BSM. The

CON enables control over a DAM for all clients by using virtualization technology.

Each physical DAM server runs multiple logical DAM instances of different custom-

ers and CON will depict them as separate DAMs under the menu-tree. The COM and

BSM also use distinct logical servers for each client that can also be virtualized on a

single physical server for each.

Barcode

reader

Cust omer Premises

EPCI S

Cont r ol

Manager

Pr ovi der Pr emi ses

Ext . Ap pl .

Syst em

Administrat or

Camer aAnalogue SensorGPS

Barcode Tag

Devi ces

RFID Tag

RFID

Handheld

Reader

AIDC Dat a

Configuration

Commands

Notification

[black lines denote AIDC data flow/magenta lines control]

Confi gur ati on

Commands

Internet

Communication Manager

Business Service Manager (BSM)

User s

Communication Manager

Data Acquisit ion Manager

Barcode

Connect or

GPS Base

St at i on

Analogue

Cont r ol l er

Camer a

Connec t or

RFID Fi xed

Read er

Reader

Barcode

reader

Cust omer Premises

EPCI S

Cont r ol

Manager

Pr ovi der Pr emi ses

Ext . Ap pl .

Syst em

Administrat or

Camer aAnalogue SensorGPS

Barcode Tag

Devi ces

RFID Tag

Camer aAnalogue SensorGPS

Barcode Tag

Devi ces

RFID Tag

RFID

Handheld

Reader

AIDC Dat a

Configuration

Commands

Notification

[black lines denote AIDC data flow/magenta lines control]

Confi gur ati on

Commands

Internet

Communication Manager

Business Service Manager (BSM)

User s

Communication Manager

Data Acquisit ion Manager

Barcode

Connect or

GPS Base

St at i on

Analogue

Cont r ol l er

Camer a

Connec t or

RFID Fi xed

Read er

Reader

Barcode

Connect or

GPS Base

St at i on

Analogue

Cont r ol l er

Camer a

Connec t or

RFID Fi xed

Read er

Barcode

Connect or

GPS Base

St at i on

Analogue

Cont r ol l er

Camer a

Connec t or

RFID Fi xed

Read er

Reader

137

5 Demonstration of the M2MGen Architecture

The M2MGen platform is demonstrated by developing a prototype and deploying on

it several scenarios in the area of Facility Management. The scenarios involve typical

work activities of in-house and 3

party service personnel in charge of maintaining

technical equipment in office buildings (i.e., HVAC, elevators, electricity, photocopi-

ers, printers, vending machines etc.).

The scenarios include: access management; data logging of maintenance operations

on RFID-tagged equipment; inventory control (registration, verification and synchro-

nization with backend legacy systems); remote monitoring and control of analogue

sensors (i.e., temperature); over the air software updates; Real-time Location System

(RTLS) tracking; and predictive maintenance (to forecast and prevent faults and han-

dle buy vs. fix decisions).

Following is an illustration of a scenario for remote monitoring and control of devices

which has been formalized using the Event Condition Action (ECA) notation. The

Complex Event Processor attempts to detect whenever the devices in the server room

are too hot, and decide by that if the server room itself is too hot. The stages in the

scenario are as follows:

Device Alarm

1. A device declares it is too hot. A lifespan

is initiated. An action could also tell the

device to minimize its power usage, and by that reduce the heat it is producing.

2. From here on, there are two possibilities:

(a) Other devices declare overheating. In this case, a situation occurs after n such

complaints.

i. After n complaints from devices about overheating, a situation occurs.

This situation should turn on the air conditioning units in the room, in order

to cool it down.

ii. If the devices did not notify that they returned to normal temperature after

a specified interval, a second situation occurs, which should alarm to add an

air-conditioning unit to the room.

(b) The device that declared it is too hot is the only device to declare such an event. In

this case, the problem is in the device. A situation occurs, which, by its actions, can

temporal interval during which active behavior is relevant. It is bounded by two events called

initiator and terminator. An occurrence of an initiator event initiates the lifespan and an occu

rence of a terminator event terminates it. Lifespans express the temporal perspective of Amit

context. (ieeexplore.ieee.org/iel5/8595/27234/01210216.pdf?arnumber=1210216)

138

alert the need of maintenance to the device, and minimize its power usage, as in stage

1, some more. Perhaps even shut the device down, to avoid damage.

The CEP makes sure that the device does not report twice, and thus confuse the CEP

into thinking more machines are overheated.

Device Alarm (ECA notation)

event: deviceOverheat

Type: Input Event

Condition: The device is too hot

Attributes:

deviceID: The ID of the device. Within this ID is incorperated

the ID of the room in which the device resides.

event: deviceNoLongerHot

Type: Input Event

Condition: The device is back to normal heat

Attributes:

deviceID: The ID of the device. Within this ID is in-

corperated the ID of the room in which the

device resides.

Actions: Unique

1. Stop the RoomDidntCool alarm

Condition:

1. A device reports that it is no longer hot

Actions: Recurring

1. Sound an alarm

Condition: One of:

1. At least one device stated overheating. Alarm type can be dynamic in

accord of the number of overheating devices in room.

The M2MGen Prototype is currently being developed using a plethora of AIDC ena-

bling technologies. The DAM accommodates: standard High-Frequency (HF) and

Low-Frequency (LF) proximity readers and a programmable logic controller for the

access control scenario; HF analogue temperature sensor and Zigbee motes for the

remote monitoring and control scenario; UHF passive and active RFID tags for the

data logging and inventory control scenarios. The CON is implemented using Micro-

soft .Net Framework and the DAM, BSM are implemented using Java. The connec-

tivity between DAM, BSM and CON is provided by the COM and is realized by

employing Web services over wired and wireless WAN connections (DSL, cellular).

6 Conclusions

Current RFID developments represent opportunities to smaller manufacturers and

other small and medium-sized enterprises (SMEs). Nevertheless, limited budgets,

lack of in-house expertise, and lack of access to the newest technologies are but a few

139

of the significant barriers faced by SMEs. Many entrants that are newly thrust into

RFID technology assessments and selections view RFID as primarily consisting of

only tags and readers. The full scope of technologies often needed to implement

RFID, either on the shop floor or throughout a supply chain, is wider and more com-

plex. In addition to tags and readers, SMEs need to consider appropriate sensors,

computers, middleware, database systems, enterprise applications, business processes,

networking, and business process management tools to fully implement RFID (Mon-

tes, et al., 2005).

This research conceptualized a model for a M2M application generator intended to

assist SMEs in overcoming the hurdles and complexities of deploying M2M applica-

tions in various domains. A detailed design spec has been completed and a prototype

of the platform is under development. The prototype will be used to evaluate the

feasibility of the proposed model to serve SME clients interested in leveraging M2M

solutions. The initial scenarios demonstrated and tested are in the domain of Facility

Management (i.e., tagged-device data logging, access management, inventory control,

etc.).

References

1. G. Allmendinger: The Ubiquity Shift The Age Of Smart Services, Presentation at

M2MExpo Harbor Research (2004).

2. J. Dexheimer and R. Hannemann: Investement Opportunities in Sensor Networking: Dust,

Hype, Fuzz, and Reality, First Analysis, Physical Sciences Inc., and DS3 Partners.

3. H. K.H. Chow , King Lun Choya, , W.B. Lee , K.C. Lau: Design of a RFID case-based

resource management system for warehouse operations, Expert Systems with Applications,

30, 561–576 (2006).

4. R. Jedermann, C. Behrens, D. Westphal and W. Lang: Applying autonomous sensor sys-

tems in logistics—Combining sensor networks, RFIDs and software agents, Sensors and

Actuators A: Physical, In Press, Corrected Proof, Available online 13 March 2006,

5. G. Lawton Machine-to-machine technology gears up for growth, Computer, 37 (9), 12- 15

(2004).

6. S. Leaver et al.: Evaluating RFID Middleware: Picking The Right Solution For Integrating

RFID Data Into Business Applications, Forrester Research Inc (2004)

7. S. Montes, L. Astor, T. Rhoades, D. Caprio, C. Londono, S. Millick, B. Vickery, J. Ng:

Radio Frequency. Identification. Opportunities and Challenges in Implementation”. Tech-

nical Paper, Department of Commerce. Washington D.C.. (2005).

8. J.E., Pakanen, K. Hakkarainen, K. Karhukorpi, P. Jokela, T. Peltola, J. Sundström: A Low-

Cost Internet Connection for Intelligent Appliances of Buildings, Electronic Journal of In-

formation Technology in Construction, 7, 45(2002).

9. C. Legner, F.Thiesse, "RFID-Based Facility Maintenance at Frankfurt Airport," IEEE

Pervasive Computing ,vol. 05, no. 1, 34-39 (2006).

10. D. S. Watson, M. A. Piette, O. Sezgen, and N. Motegi, Machine to Machine (M2M) Tech-

nology in Demand Responsive Commercial Buildings, Proceedings from the ACEEE 2004

Summer Study on Energy Efficiency in Buildings: Breaking out of the Box, August 22-27

(2004).

140