Page 18

EETE JUNE 2013

M2M Comunications High-level M2M application design for mobile-based services By Yi Huang Machine-to-machine (M2M) applications are complex systems that can only be realized on the basis of a coherent design. The route to coherence is via a requirements analysis, and data interchange via mobile communication networks confronts developers with a number of requirements that feed into design decisions from the use of Machine Form Factor (MFF) SIMs to choosing the right communication protocol. Connecting machines, devices, and objects is in full swing, be it in an industry context under the Smart Factory heading or in private projects such as home automation. Machine-to-machine applications combine embedded systems and communication technologies. Developers make use of a wide range of communication routes, from direct wiring to wireless networks like W-LAN and Zigbee. Connecting embedded systems by mobile networks, however, opens up a number of particularly interesting scenarios, from the surveillance camera that transmits a picture by MMS to wristwatches with a built-in emergency call function. Thanks to the commitment of mobile network operators in the M2M growth segment enabling devices to communicate with each other via a mobile network is now easier than ever before. Deutsche Telekom’s M2M Developer Community, for example, now offers an entry-level package that bundles an Arduino board with a GSM chip, an M2M SIM card, and access to a Cloud-based developer platform. Yet the use of mobile technology differs from programming network applications in general. What must developers bear in mind? The requirements analysis provides initial answers to this question. Every M2M project has individual requirements that need to be identified at the outset of the development process. Requirements may change in the course of a project, but in many cases a faulty design can thereby be prevented in advance. In principle, there is no single blueprint for an M2M solution requirements analysis. The range of applications is simply too wide. In practice, however, using the target group and the application area along with the application scope and framework as starting points, working through them systematically, and identifying requirements accordingly has been found to be a successful approach – see figure 1. Target group and application area The target group’s requirements provide inter alia an indication of the scope of functions required. What exactly is the application to achieve? What added value does it offer to users? As a rule, industry-specific expertise is required to fully identify target group requirements and application area processes. Translating target group-related requirements into the language of engineers is one of the greatest challenges of the requirements analysis. In some cases, however, requirements are immediately evident. Take, for example, a toy robot that is to be controlled by a smartphone. The user interface should be simple enough for even a child to use it. Complicated menu structures and a plethora of options are out of place. The application area is the first indicator of hardware requirements. Household devices can be less robust than devices for industrial use. That is why an Arduino board as a learning and prototyping platform is unsuitable for factory applications. More robust wireless terminals made by manufacturers such as Cinterion, Telit, or Sierra Wireless should be used instead. Furthermore, ambient conditions determine the choice of Subscriber Identity Module (SIM). SIM chip cards identify users in a wireless network. They look inconspicuous but are in reality tiny computers consisting of a CPU, a I/O unit, ROM, RAM, and EEPROM. Standard SIM cards cannot cope with major fluctuations in temperature. That is why, for industrial M2M uses, there are special MFF SIMs. They are smaller than the SIM cards with which we are familiar from mobile terminal devices, can be soldered onto circuit boards and are designed for use in extreme conditions. They can withstand temperatures of between -40 and +105°C. Many M2M applications are designed to function autonomously in remote locations. A pump control system, for instance, must work for long periods without human intervention. A resulting M2M application requirement is that the application must constantly monitor its state in the network. Fig. 1: Identifying the user requirements. Application scope Further requirements can be deduced from the application scope. The problem solution approach in figure 2 shows several typical areas of an M2M application, from generating data to providing a service. Some applications must address every area, others only some. As soon as the application relays data via the mobile network in one of these steps, a decision must be made on the communication protocol to be used. The quantity of data transmitted is a cost factor. So M2M developers need to be very conversant with protocols in order to implement the mobile data interchange efficiently. Take TCP and UDP, for example. Both protocols define how data is transmitted to an IP address, but in different ways. TCP can be compared to a forwarding agency that promises safe Yi Huang is Marketing & Proposition manager in the M2M Competence Center at Deutsche Telekom – www.telekom.de – He can be reached at Yi.Huang@telekom.de 18 Electronic Engineering Times Europe June 2013 www.electronics-eetimes.com


EETE JUNE 2013
To see the actual publication please follow the link above