Plug into M2MThe next wave most likely to hit embedded system design is machine-to-machine (M2M) communications, but implementing M2M may be more challenging than designers expect.
The advent of the Internet has fostered many changes in the electronics industry, and more is yet to come. One change that many industry watchers see as the next trend in embedded system design is a growing ability for machines to exchange information with one another worldwide across the network. This machine-to-machine (M2M) communications has tremendous applications potential but poses significant challenges that can foil project teams not prepared to meet them. Prefabricated modules and related services may be the better way for designers to plug into the M2M revolution.
Communicating machinery is not a new concept; industrial control systems depend upon machines exchanging information. But M2M communications has several factors that distinguish it from traditional industrial control. One is architectural. M2M systems typically have relatively autonomous nodes that work together as an aggregate. Individual nodes can be added to or removed from the network without affecting the operation of the others or having a significant impact on the system as a whole. In contrast, the nodes of industrial control systems are typically interdependent. All of them need to remain active in order for the entire system to perform its function.
The communications architecture may also differ. Most industrial systems have a centralized control unit that issues all of the commands nodes and serves as the relay point for data exchanges among nodes. M2M systems may have this structure, or may include peer-to-peer communications among nodes that are self controlling. Many M2M systems do not even include a control component. Instead, they are information-gathering networks that may report data to a central repository or make it accessible on demand by multiple data consumers.
Geography is another factor distinguishing M2M from industrial control. Industrial control systems typically locate all of their nodes at a single location, such as a building or campus. M2M systems have no such restriction. While the choice of the communications channel may impose separation limits, the application does not. M2M systems can often be geographically unbounded, encompassing nodes scattered worldwide.
Typically, M2M systems also possess the attribute of mobility. The nodes need not be permanently located at one site, nor do they need to remain stationary while operating. Instead, M2M systems can address applications where the source of data is a vehicle or a container in transport. In applications where mobility is not a requirement, portability usually is. The nodes in such an M2M system can be easily relocated without affecting the structure or operation of the system as a whole.
Amidst all this diversity M2M nodes share one common characteristic: the ability to connect to a network when it is available. In fact, the network connection is an M2M node's defining element. The network connection transforms a single autonomous node into a cog in the much greater machine of the M2M application while the network itself serves to aggregate the activities of individual nodes into a system much more powerful than the sum of its parts. Thus, a well monitoring instrument becomes part of a real-time worldwide oil production monitoring system and a GPS (global positioning system) receiver becomes part of a taxi company's fleet management system or a shipping company's container tracking system.
It is in the link to the network that most of the challenges in M2M system design lie. One of the first challenges is choosing the best link for the application. Both wired and wireless links are available. The choice depends on many factors, including the range over which communications must take place, the mobility that the machines require, and the availability of infrastructure resources. Further, one single type of channel may not be appropriate for all node installations. M2M system developers will therefore need flexibility in their communications channel design, allowing for a variety of different links to be inserted as needed. Fortunately, modems that can be dropped into a design as components or modules are available for all of the wired and wireless options as Figures 1 and 2 explain.
Among the wired choices are traditional Ethernet as well as the public switched telephone network (PSTN). Wired choices are most appropriate for installations where the cabling is already available in the vicinity and where the node will be relatively stationary.
Most of the M2M applications that people envision, however, use a wireless connection. The easiest wireless connections to implement are the standards-based wireless channels, such as WiFi, Bluetooth, or ZigBee, which have many module providers and don't require the involvement of a network service provider. These wireless channels are all short-range systems, however, operating within a few meters to under a hundred meters. Applications that use one of these options thus tend to be confined to a relatively small geographic range, such as a factory or campus, although they may be mobile within that range.
For wide-area networking, such as across a city or larger geographic range, the most widespread communications link is the control channel used in cellular telephony. The control channel is a low-data-rate link that cellular companies use for authentication of calls, billing control, and network security functions. It is an under-utilized channel, and many cellular service providers sell the surplus bandwidth to non-telephony users. The communications channels used for pagers and text messaging are also being made available for use in M2M communications. As with the control channel, the paging channel option best serves low data rates.
Where cellular service is not available, satellites provide an alternative communications channel. In remote areas or for maritime deployment it may be the only communications option. Satellites can exchange low-bandwidth data with M2M nodes that are operating at modest power levels and with limited antennas. Higher bandwidth links, however, often require a fixed high-performance antenna that virtually erases the mobility advantages of wireless communications.
For the highest bandwidth applications, telephony channels of cellular services are the primary choice. Most cellular telephony systems are evolving to a data-centric model, making them a natural fit for M2M applications. In addition, cellular service providers are starting to encourage M2M services by offering attractive pricing during times of low demand for telephony capacity, such as late at night.
Several different cellular technologies are available for M2M communications. On CDMA (code-division multiple access) networks in the U.S., EV-DO (Evolutiondata only) is the primary technology available. For GSM in Europe and elsewhere, GPRS (general packet radio service) and EDGE (enhanced data rates for global evolution) are the associated technologies for data communications.
One drawback to the use of cellular networks, and many of the other wide-area wireless channels, is the high cost of certification. Government regulatory bodies require certification of radio transmitters, of course, but cellular service has two additional levels of certification requirement. The first is for compatibility with the wireless network protocol, administered by the industry groups listed in Table 1. The other is certification by the individual service provider. Service providers don't want risk an M2M application bringing down their telephony network, so they often impose their own certification testing requirements on potential service users. The effort and expense associated with these additional certification steps can be substantial and often come as a surprise to M2M application developers. Failure to anticipate these costs, or to pass the certification tests, can permanently derail an M2M design effort.
All of these choices and challenges may seem daunting to prospective M2M developers, but fortunately help is available. A number of companies, as shown in Table 2, offer consulting services that can help guide a development team through the certification steps. Some of them also offer their own radio-modem products, freeing development teams to concentrate on application hardware and software instead of the communications link.
Even the application hardware may be able to be purchased off-the-shelf along with the communications modem. Many board vendors offer single-board computers with wired or wireless modems built-in along with other popular M2M funcitons. The WinSystems LBC-GX board, for instance, includes a choice of GSM, GPRS or CDMA cellular modem, 802.11 or ZigBee wireless communications, and Ethernet or USB 2.0 along with an optional dial-up modem. WinSystems' product is shown in Figure 3.
Software issues remain
Although the hardware may be readily purchased, the software remains the development team's responsibility. The communications channel software is a critical area that development teams must consider. Many modems intended for connection to the Internet provide their own TCP/IP stack, but it may not be adequate for the application. Some implementations, for instance, provide only basic functions and a single socket. As a result, security functions and upper-layer protocols such as e-mail and HTTP may need to be part of the application software. Implementing these higher layers in the applications processor may stretch the performance limits of smaller processors.
When implementing significant parts of the communications channel in the application software is not an option, developers should look for modems that are full Internet-device servers. Servers completely off-load the communications tasks from the application processor while providing a full spectrum of protocol choices for the application to use in exchanging data over the Internet. Servers can also offer useful attributes such as fixed IP addresses for nodes, which simplify the identification of and targeting communications to specific nodes.
Along with considering the implementation of the communications channel, M2M application developers need to consider its implications. The Internet, particularly with wireless communications, is an unpredictable medium. The TCP/IP protocol guarantees data delivery, but makes no promises regarding timing. As a result, M2M applications cannot support anything like real-time control, and nodes must be able to perform their function, whether it is data collection or the local control of a system, without relying on the network connection. Operating parameters and commands may come over the network and the node may need to send its data across the network, but the node cannot depend on the network connection remaining continually intact.
The use of a network connection, particularly a wireless link, may also imply a need for implementing data security. The information being exchanged in M2M applications or the control features being made remotely available are subject to theft or malicious manipulation when broadcast over wireless links or routed through the public Internet. As a result, data transfers may require the use of encryption, authentication, and validation algorithms in addition to the communications protocols for the network in use. Some of these functions may be available in the communications modem. Others may need to be implemented in the applications software, again requiring Internet expertise.
The need for Internet protocol expertise, the wide choice of communications links available, and the difficulties of wireless certification all make creating M2M systems a significant challenge. Fortunately, the availability of drop-in communications modems and even entire M2M application nodes offers an opportunity for system developers to plug into the M2M trend at a reduced effort level.
Rich Quinnell is a contributor to many publications including EDN, Test and Measurement World, and EE Product News. He has covered electronic technology for more than 15 years, drawing on his experience as an embedded system designer for nearly as long. You may reach him at RichQuinnell@att.net.