Machine-to-Machine (M2M) communication, or the ability to connect and manage remote devices over the air, offers enormous potential. With the ability to centrally control remote industrial equipment, track vehicle fleets, manage electric vehicle charging stations, expand the capabilities of consumer devices, and much more, M2M has profound implications for virtually every industry.

Given the novelty of M2M technology, however, developing connected devices has traditionally been an expensive and time-consuming process, largely due to the fact that system designers had to build the entire M2M architecture from scratch. Today, designers have a powerful new option in their M2M toolkit: Embedded Application Frameworks (EAFs). By deploying connected services on mature, prepackaged Real-Time Operating Systems (RTOSs) and libraries embedded directly into the communications module, M2M designers can substantially reduce the time and costs involved in developing new M2M hardware and focus their efforts on creating innovative connected applications.

Challenges of developing M2M systems

At its core, M2M technology involves augmenting a device or piece of equipment with intelligent services and connecting that device to a back-end infrastructure that can monitor or control it. To accomplish this, an M2M device employs two basic elements: a mechanism to communicate with the back-end infrastructure (a wireless modem or module) and software to run the services.

Mature wireless communication modules have been available for many years, and designers of connected devices have often used off-the-shelf components to provide connectivity. Most of them relied on a traditional multichip architecture. In practice, this required assembling the hardware and software – usually based on a full-blown OS along with its associated software libraries, running on a stand-alone microprocessor supported by external memory – before designers could even begin addressing the services running on top of the device.

Early developers of connected devices had few choices available because there simply wasn’t a mature market of prepackaged software available for supporting M2M connectivity. But this reliance on bespoke device architectures introduced a number of inefficiencies that today’s developers can no longer afford.

Developing systems in this manner takes a long time. Assembling and integrating the entire architecture from scratch typically requires a minimum of one year in development before the system can be brought to market. While this might have been an acceptable timeframe in the early days of M2M, system providers today cannot afford to wait that long. They need to stake their position in the marketplace as quickly as possible.

Building the entire architecture from scratch is also inherently expensive. Apart from the operational costs associated with integrating and testing all components of the architecture in-house, relying on this model also typically involves using a full-blown RTOS and having to equip the device with full-scale processing power to run it. Some complex M2M applications require this much horsepower, but for the vast majority (which often simply monitor a device and send out data to a back-end server), a full-blown RTOS is overkill. Why invest in a full-scale OS and microprocessor, when what the device is actually doing requires just a fraction of that computational capability?

The biggest drawback of this approach, however, is that it requires connected device developers – often at a start-up company – to devote significant time and resources to things that have nothing to do with their core areas of expertise. For example, if a developer is building an M2M system for health care, the value of that system lies in the intelligence created for a specific health care application. A developer of industrial systems possesses expertise in developing services that effectively monitor and control that equipment using the most appropriate protocols. Whatever the industry or expertise, a connected device developer’s core value proposition is most likely not assembling multichip computing architectures.

Embedding intelligence in the communication module

EAFs address these issues by providing a means to embed M2M services directly into the communication module, alongside blocks of prepackaged software, connectivity capabilities, and processing resources (see Figure 1). In this way, an EAF makes it easier, faster, and less expensive to deploy an M2M system. It allows developers to use mature, proven, widely deployed technology instead of having to reinvent it. EAFs improve:

·    Time to market: By using prepackaged components and embedding software code directly in the communication module, M2M system providers can substantially reduce development timelines. Instead of taking a year to develop all aspects of the system, many M2M applications can be developed and brought the market in less than six months.

·    Development costs: Deploying software in an EAF on the communication module eliminates the need to buy and assemble a separate RTOS, microprocessor, and external memory for a device. Because an EAF provides a lightweight OS specifically optimized to run common M2M services, it can share processing resources and memory with the communication module. This also reduces operational expenses by eliminating the need to staff engineers with expertise in OSs and communications, and instead focus engineering resources on the application and its unique services.

·    Efficiency: Relying on a multichip architecture with a separate communication module and microprocessor limits the RTOS to a relatively simple command interface with the modem. When the application is embedded on an EAF in the communications module, however, it can directly access all the different layers of the communications stack. That means the developer has more control over how the application monitors and accesses the communications stack at different levels using different APIs. It also delivers capabilities beyond those available to a stand-alone RTOS.

Most importantly, EAFs address the “core-versus-context” question, allowing connected device manufacturers to focus on the unique value they bring to the system.

Key elements of an EAF

So what should connected device manufacturers look for when considering the EAF model? Any EAF should include the following core components:

·    Lightweight OS optimized for M2M: While a few M2M applications require a more powerful RTOS, most do not. The keys for the EAF OS are a small footprint and ruggedization for M2M deployments. The OS should be natively designed to provide APIs that control voice call, data call, SMS, and TCP/IP connectivity. It should be optimized to take full advantage of its direct access to the communications stack. To provide full support for a connected application, the OS should also provide a core feature set that includes:

-  Real time, including guaranteed response time to external or internal interruptions, regardless of its state.

-  Flexibility to prioritize tasks.

-  Multitask capabilities to define and synchronize as many tasks as services require.

-  Flexibility in processing speeds and power options to optimize battery life.

-  Memory, firmware, and software protection features.

-  Ability to use APIs to access the cellular modem’s audio and data path.

·    Software libraries: To simplify the development process and speed time to market, the EAF should include a variety of software libraries and APIs that provide a variety of functions the device or services might need. This includes services such as location/GPS connectivity, comprehensive Internet connectivity protocols, and wireless and Internet security services. The EAF should also support third-party libraries that take advantage of software developed for the specific needs of the target market. Ideally, the EAF should be backed not just by the communication module vendor, but also by a community of partners and developers working to expand its capabilities.

·    Development tools: The EAF should also include a package of development tools that make it easy to code, debug, and monitor M2M applications, and these tools should be open source and free to use. Ultimately, the EAF should provide everything needed to develop and embed the M2M application into the module.

·    Cloud connectivity: Finally, the EAF should provide tools to streamline cloud-based management of connected devices, including a fully realized system to handle device monitoring and software/firmware upgrades over the air. The system should allow developers to monitor the health of the devices and identify potential problems. It should also include proven tools to remotely upgrade the OS stack, as well as the M2M application itself using a patch mechanism.

Taking advantage of prepackaged M2M components

The EAF discussion raises an age-old question for businesses: Should I make it or buy it? For most companies and most M2M systems, buying makes a good deal of sense. After all, if you were starting a car company, would you make your own tires and windshield wipers? Your own stereos and navigation systems? Clearly, there are some elements of the product developers will want to build themselves, as that’s where they can add the unique value that differentiates their system. But for most of the M2M architecture, the market now offers mature prepackaged components that are both proven and cost-effective.

Some companies have concerns about ceding control over the system when using prepackaged M2M components. However, the reality is that lack of control should not be an issue with any modern EAF. As long as the EAF supports open standards, developers should be able to write code in a common programming language such as C/C++, which means they retain the ability to port that code to any other platform used in the future.

Of course, there will always be exceptions to this rule of thumb. For some companies and projects, it makes sense to build everything in-house, as the product’s value lies in reinventing the entire system. There are also M2M systems that are simply not suitable to run on an EAF – more complex, heavier applications that require the horsepower of a more powerful processor and a full OS.

Even this distinction might not be relevant for long. Today’s EAFs rely on previous-generation processors that have been on the market for several years. As EAFs continue to evolve and take advantage of higher-powered processors and multicore architectures, even companies developing very complex M2M applications will likely be able to embed them into the communications module EAF and benefit from the same advantages.

As EAFs and the M2M market continue to evolve, there will be fewer and fewer reasons for connected device manufacturers to invest in building basic M2M capabilities, much less entire device architectures. Ultimately, this will make system design much easier for M2M developers. More importantly, as designers focus more on delivering unique value instead of on M2M hardware, we can expect to see M2M innovations that at present can only be imagined.

Pierre Teyssier is senior VP of engineering for the M2M Embedded Solutions Business Unit at Sierra Wireless.

Sierra Wireless
[email protected]
Twitter: @SierraWireless
www.sierrawireless.com