Portable software agents: A ‘Goldilocks’ approach to IoT connectivity

The Internet of Things (IoT) involves a number of steps and complexities, each with multiple design decisions and trade-offs. For most connected devices, the first step is enabling connectivity between the physical object—the IoT ‘thing’—and the Internet, using an embedded wireless IoT module. The IoT module includes communications circuitry that enables a connected device to send and receive data over a wireless protocol such as Wi-Fi, cellular, or Bluetooth.

Connecting the device to an IoT cloud, and managing the connected device, requires specialized connectivity software. Until recently, makers of connected products could choose between two ways to connect their devices to an IoT cloud: a software development kit (SDK) or an IoT software agent integrated onto the wireless IoT module.

Regardless of the approach, connectivity software needs to be rigorously tested and certified to work with each model of hardware module. Given the range of IoT devices requiring connectivity—from wearable fitness trackers, coffee makers, and home thermostats to factory equipment, lighting systems, and commercial heat, ventilation, and air conditioning (HVAC) systems—pairing connectivity software to communications hardware can be daunting.

SDKs provide only the most generic libraries for communicating over low-level and standardized protocols, such as MQTT or CoAP. Production-level IoT software agents, in contrast, offer widely inclusive feature sets encompassing things such as message serialization, error handling, notifications, scheduling, over-the-air (OTA) updating, debugging, troubleshooting, authentication and authorization, user registration, and other capabilities—all certified, tested, and ready for production with a particular IoT module.

Now, however, IoT solution providers have a new option for establishing connectivity to an IoT cloud, with more capabilities than an SDK but leaner than a pre-built production agent. The new portable IoT software agent provides an important middle-road option for certain types of projects—a bring-your-own (BYO) option that’s not too hot, not too cold; not too big, not too small. In other words, a much more flexible ‘Goldilocks’ approach for connecting IoT products using a cellular or Wi-Fi module.

Key Challenges for Creating a Flexible Connectivity Solution

It’s tough designing connectivity solutions that can be compatible with the variety of protocols, processing, memory, and software considerations that each IoT product designer must consider. Previously, makers of connected products needed to choose between an open and flexible connectivity design, enabled by an SDK, or an integrated, turnkey design provided by an embedded IoT software agent.

IoT solutions introduce myriad new demands and skills requirements that few traditional manufacturers possess in-house. Manufacturers seeking to IoT-enable traditional products, especially those new to connected products, often find that choosing a software agent provides significant time-to-market advantages for their IoT products.

The software agent takes care of most of the complexities of IoT cloud connectivity, allowing manufacturers to focus their resources on what they already do well, without expending the enormous time and resources necessary to design, build, test, support, and scale connected solutions. All they need to do is use a few simple APIs to get the production software agent talking to the compatible production wireless module.

But this inclusive approach of using an IoT software agent has trade-offs, most notably a lack of flexibility in design options. An IoT software agent connects to a specific vendor’s IoT cloud, and each agent-module pairing is tested and certified for a particular module model from a particular module vendor. This approach also increases hardware costs: In addition to the IoT-enabled wireless module, a company has to purchase an additional microcontroller onto which they load their application code, then program the microcontroller to talk to the wireless module.

This integration between agent and module means that manufacturers of connected products are challenged to choose their IoT cloud and wireless module separately. Many manufacturers have volume discounts with one or a handful of module providers. If their preferred module vendor does not support an agent for their IoT cloud of choice, manufacturers must either spend more on bill-of-materials (BOM) costs to connect to their preferred IoT cloud with an out-of-spec module vendor, or keep their costs in check but be unable to connect via the IoT cloud that best supports their connected products’ functionality and performance.

Manufacturers with IoT-savvy engineering teams can overcome this trade-off by using an SDK instead of a software agent to build their own messaging and data model over protocols such as MQTT, CoAP, or HTTP. But realistically, this option is not available to any but the largest manufacturers with the most experience in designing and launching connected products. The rest have had to choose either flexibility and its accompanying cost savings (i.e., using an SDK and doing all their own IoT engineering) or the faster and typically safer route of leaving IoT connectivity details in the hands of a pre-built software agent.

When a Portable Agent Approach Makes Sense

The portable agent approach presents a new alternative. Think of it as an SDK enhanced with modular options for various IoT connectivity capabilities.

A portable agent enables connectivity to a particular IoT cloud from any wireless module. As a result, makers of IoT solutions that want to connect to that IoT cloud are no longer restricted to a list of certified wireless modules. The portable agent manages the connectivity, reliability, and security of connectivity to the IoT cloud in addition to providing the low-level connectivity provided by an SDK-type client. Users of portable agents also have access to source code, making this option more flexible than production agents, which do not expose source code.

Two types of companies are most likely to use a portable agent approach:

  • Higher-volume manufacturers with some experience launching connected products, or that want to retrofit existing products with a different wireless module.

  • Module makers themselves.

For manufacturers with some expertise designing IoT products, use of a portable agent justifies their one-time cost of engineering to couple the software agent to their preferred wireless module. Depending on the volume of connected products they ship, they can use the portable agent approach to take advantage of contractual cost savings with a wireless module vendor, even if their module of choice is not already certified to support their IoT cloud of choice.

Using the portable agent, these manufacturers can reduce the footprint of their product while saving on hardware BOM costs—and without the burden of being restricted to a particular hardware module. They can pass on the savings to their customers or use them to fuel R&D for future products.

For wireless module makers, the portable agent means the ability to offer a more diverse range of modules to a wider range of industries that are interested in creating IoT products. Module makers possess the IoT engineering skills to integrate software agents into their products. The portable agent approach empowers module vendors to enable connectivity in their products to a particular IoT cloud that might be of interest to specific types of customers.

Architecture and Features of a Portable Agent

The portable agent is de-coupled from any drivers or connectivity-specific protocol stack—i.e., the chipset-specific connectivity features are not baked into the portable agent—which translates into a smaller footprint than required for a production agent.


The portable software agent (Source: Ayla Networks)

The architecture consists of the portable agent interfaced by two abstraction layers: an application layer on top and an IoT platform adaptation layer below.

The application layer operates similarly in the case of a portable agent as with an IoT production software agent. An IoT product designer, or a third-party partner handling design duties, uses a set of interface APIs, provided by the IoT cloud provider, to integrate a host application with the portable agent.

The adaptation layer, which interfaces with the underlying IoT cloud platform, is where the portable and production software agent operation differs most strongly. The adaptation layer encapsulates the low-level interfaces and platform-dependent code and translates it into IoT cloud APIs, specified by the IoT platform provider, that integrate with the portable agent and a library of platform-independent utilities.

With the portable agent, it is the responsibility of the connected product or IoT solution provider to implement the adaptation layer. With a production IoT software agent, the adaptation layer implementation is handled automatically.

Integrating a Portable Agent Into the Design

To integrate a portable agent in a new design, the connected product manufacturer or module vendor must implement an adaptation layer that encapsulates hardware/chipset platform-dependent code and translates it into platform APIs. After integrating the portable agent with the hardware platform, designers can then integrate the high-level application code on top of the platform-specific agent.

Retrofitting a portable agent into existing designs adds the requirement to implement software changes to de-couple and modularize the application code from IoT platform- and networking-specific code. The amount of work entailed depends on the tightness of integration of the original design.

The portable agent features a modular design that allows for the addition and removal of IoT connectivity components as needed. For example, manufacturers of IoT products or wireless modules can choose to add features such as schedules, OTA updates, local connectivity support (such as LAN mode), or Wi-Fi setup.

Portable agent code can run either from RAM or directly from flash if execute-in-place (XIP) capability is supported. The memory choice depends on the module or hardware platform selected.

For provisioning, the portable agent provides the flexibility for manufacturers of connected products, or their design partners, to implement their own provisioning mechanism. The portable agent generates and allocates a list of unique device serial numbers to the manufacturer for loading during the manufacturing process. The IoT cloud platform associated with the portable agent then authenticates the uniqueness and validity of the device, although this authentication mechanism is separate from the portable agent itself.

The portable agent approach can also provide access to various connected device setup and user registration mechanisms offered by the IoT cloud platform provider. For instance, it can include secure and reliable registration mechanisms for different wireless connectivity protocols (e.g., Wi-Fi, Bluetooth, cellular), based on individual product requirements and end-user needs.

The portable agent approach does not sacrifice security to optimize for footprint. Portable agents include end-to-end security built in for data transmission and user authentication. Data is encrypted over industry-standard Transport Layer Security (TLS) using AES-128 encryption. Layered access control provides containment to prevent breach of one device compromising the whole system.

The Importance of Test Suites

An important factor in the portable agent approach is the inclusion of test suites that enforce the quality of the implementation—whether performed by a wireless module maker, a manufacturer’s in-house engineering team, or a third-party development partner. The more flexible a design approach, the greater the risk of something going wrong.

This is especially true for connected products, which must function at the highest levels across the full spectrum of IoT operation, from sensors embedded in each device through cloud connectivity, operation of the mobile or web application used to control the device, interoperability with other devices on the network, troubleshooting, support, and ongoing firmware updates and product enhancements.

The portable agent approach includes test suites for individual components at the adaptation and application layers. Adaptation layer tests include isolated testing to verify that the low-level IoT platform APIs are implemented according to specifications, thus minimizing risks before the portable agent is integrated on top of the platform layer. Tests cover both cellular and Wi-Fi connectivity.

Application layer tests ensure robust end-to-end IoT functionality after the portable agent is integrated. High-level functional testing includes provisioning, getting and setting data properties, schedules, local connectivity, OTA updates, and everything else needed to ensure that everything works well together.

Conclusion

Designing an IoT-connected product can be overwhelming. For first-time manufacturers, or those with limited in-house IoT expertise, using a full-featured, fully certified IoT software agent embedded onto a wireless module can save considerable time, expense, and hassle.

At the other end of the spectrum, manufacturers very comfortable with doing all their own IoT engineering can save costs and increase their design flexibility by starting with an SDK providing the barest minimum of IoT cloud connectivity functionality.

For situations where neither of these extremes provides an ideal approach—or where trade-offs among design flexibility, hardware costs, time to market, and level of IoT engineering skills become too onerous—the portable IoT software agent offers a viable, Goldilocks-like alternative to makers of both connected products and wireless modules.


YewYin Ng is a product manager at Ayla Networks, where he leads product definition and strategy for Ayla’s edge connectivity solutions, cellular platform, and developer onboarding. Prior to joining Ayla, YewYin held various product development roles at SanDisk. Leveraging his background in consumer electronics and embedded systems, he led various cross-functional teams to define, develop, and launch multiple innovative and high-impact products. YewYin earned a MS in Engineering Management from Santa Clara University and a BS in Electrical Engineering from University of Illinois.

2 thoughts on “Portable software agents: A ‘Goldilocks’ approach to IoT connectivity

  1. “I reckon that the whole IoT framework is still very much in its infancy. There's a lot more that we can do to make it more sophisticated such that everything communicates well with each other. It's a matter of focusing on the bottlenecks and improving the

    Log in to Reply
  2. “The 'Goldilocks' approach is by far the best method to implement when it comes to the technological sector. There really isn't a step that can provide a guarantee only the best platform is being put forward. What we need to do is to use this approach unti

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.