M2MGen - An Application Generator for Machine to
Machine (M2M) Applications
Chanan Glezer
1
, Sudha Krishnamurthy
2
, Kilian Schloeder
2
Omer Anson
1
and Gil Tahan
1
1
Deustche Telekom AG Labs at Ben Gurion University of the Negev
Beer Sheva 84105, Israel
2
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
Copyright
c
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)
1
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
2
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
3
, 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
1
http://www.mitre.org/news/the_edge/july_01/miller.html
2
http://www.vector-imagineering.com/vi_flexray_solutions_en,,223.html
3
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
4
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
5
); de-
pendability and failure prediction algorithms (using SHARPE
6
) 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.
4
www.epcglobal.org
5
http://www.haifa.il.ibm.com/dept/services/soms_ebs.html
6
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
rd
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
7
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
7
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