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.