IoT Connectivity: Choosing a Black-Box, White-Box, or Gray-Box Approach

September 6, 2018 Josh Pederson, ECD Contributor

Internet of Things (IoT) developers have a choice of approaches for creating connectivity to IoT clouds, each with different advantages and trade-offs. How can you tell which option is the best one?

The fastest and easiest way to connect an IoT product to an IoT cloud is using a full-featured production IoT software agent, like the ones offered by leading IoT platform providers. Integrated onto wireless IoT module hardware, production agents represent the ‘black box’ approach. At the other end of the spectrum, the most stripped-down approach for IoT cloud connectivity is to use a basic software developer kit (SDK), offered by Amazon Web Services (AWS), Microsoft Azure, and others. This would be the ‘white box’ approach.

More recently, IoT solution developers now have a new alternative that can be considered a ‘gray box’ approach: a portable IoT software agent. The portable agent is like a beefed-up SDK, with modular options that provide various IoT connectivity capabilities.

Here is a run-down on the black box, white box, and new gray box approaches.

Production Agents: Black Box IoT Cloud Connectivity

Production-level IoT software agents are pre-integrated with a specific model of wireless IoT module hardware. The IoT module, sometimes called a radio chip, provides the basic communications circuitry to enable a connected product to send and receive data using a wireless protocol such as Wi-Fi, cellular or Bluetooth.

Production agents offer broad feature sets for handling the diverse details of IoT product connectivity to a particular IoT cloud, such as message handling, scheduling, over-the-air (OTA) updates, user registration and troubleshooting. But they represent a black box approach because all these built-in capabilities are essentially out of sight and untouchable.

Pros of the black box approach:

  • Developers of IoT products don’t have to worry about mastering all the engineering skills and expertise demanded by IoT cloud connectivity.
  • Especially for manufacturers new to IoT and making their first connected products, production agents can significantly speed time to market.
  • Connected product makers can cut their IoT development costs, as well as the associated risks and headaches.

Cons of the black box approach:

  • Because production agents pair access to a particular IoT cloud with a specific model of module hardware, the production agent software and the module hardware are a package deal. Developers wanting to connect to a specific IoT cloud can’t choose an IoT module that hasn’t already been tested and certified to work together—a process that can take many months.
  • Using the production agent approach requires that manufacturers purchase an additional microcontroller, load their IoT application onto it, and program the microcontroller to talk to the wireless module. This requirement adds to the bill-of-material (BOM) costs.
  • The production agent is essentially a closed system, and experienced IoT developers can become frustrated by the lack of flexibility in their IoT cloud connectivity options.

SDKs: White Box IoT Cloud Connectivity

SDKs provide only the most generic libraries for communicating over low-level and standardized protocols. Makers of IoT products build their own messaging and data models over these standardized protocols, which include MQTT, CoAP, and HTTP.

SDKs represent a white box approach because they are open to tweaking and customization by developers. In fact, they require IoT product manufacturers to assume most of the responsibility for their IoT cloud connectivity.

Pros of the white box approach:

  • Makers of connected products have enormous flexibility in deciding what features to include in their IoT cloud connectivity, as well as how those features are implemented.
  • They can choose to work with any wireless IoT module, based on price or on features best suited to their connected products’ characteristics or design goals.
  • Without the requirement to purchase an additional microcontroller to use in conjunction with the wireless module, manufacturers can reduce their BOM costs compared to using a production agent.

Cons of the white box approach:

  • In-house engineering teams need to be large and IoT-savvy enough to handle all the intricate details of developing, testing, implementing, and supporting IoT cloud connectivity—as well as ensuring that the cloud connectivity interacts seamlessly with all the other end-to-end requirements of a complete IoT solution.
  • Doing all the IoT cloud connectivity engineering and testing in-house increases the risk for manufacturers.
  • The do-it-yourself (DIY) approach can also extend development time and raise costs of an IoT project unless the in-house teams are extremely proficient in IoT-specific issues.

Portable Agents: Gray Box IoT Cloud Connectivity

The portable IoT software agent is a new alternative for connecting a device to an IoT cloud. A portable agent enables connectivity to a particular IoT cloud from any cellular or Wi-Fi module. It manages the connectivity, reliability and security of connectivity to the IoT cloud in addition to providing the low-level connectivity provided by an SDK.

The portable agent is de-coupled from any drivers or connectivity-specific protocol stack at the wireless module level. Architecturally, the portable agent is interfaced by two abstraction layers: an application layer on top and an IoT platform adaptation layer below.

The application layer includes a set of interface APIs provided by the IoT cloud provider for integrating host applications with the portable agent. The adaptation layer interfaces with the underlying IoT cloud platform, encapsulating low-level interfaces and platform-dependent code and translating it into IoT cloud APIs that are specified by the IoT platform provider. These adaptation-layer APIs integrate with the portable agent along with a library of platform-dependent utilities.

Portable agents have a modular design that allows for the addition of IoT connectivity components—e.g., schedules, OTA updates, Wi-Fi setup—as needed. Also on a modular basis, portable agents can also provide access to various connected device setup and user registration mechanisms offered by the IoT cloud platform provider.

Portable agents represent a gray box approach because their capabilities lie between those of SDKs and portable agents.

Pros of the gray box approach:

  • Portable agents combine the flexibility of SDKs with some of the already-baked qualities of production agents. They include rigorous test suites for both the application and adaptation layers to help ensure robust IoT functionality at both the component and end-to-end levels.
  • Portable agents can significantly cut the time needed to get to market with connected products by allowing manufacturers to skip the lengthy, expensive testing-and-certification process to pair an IoT cloud platform with a particular wireless module.
  • Because they are no longer restricted to a list of certified cellular or Wi-Fi modules, manufacturers can use the portable agent approach to take advantage of cost savings negotiated with any wireless module vendor, even if the module has not been certified to support their IoT cloud of choice.
  • Compared to production agents, portable agents enable manufacturers to reduce BOM costs and the footprint of their product by not having to purchase a separate microcontroller.
  • At the same time, portable agents take care of more of the connectivity to the IoT cloud than SDKs provide.
  • Wireless module makers can use portable agents to design and offer a more diverse range of modules to a wider range of customers that are creating IoT products. They can also use support of a particular IoT cloud as a differentiating feature in marketing their wireless module products.

Cons of the gray box approach:

  • Manufacturers using portable agents need to do more development work than with production agents to establish IoT cloud connectivity.
  • As a result, portable agents require a relatively high level of in-house expertise with all aspects of developing and scaling connected products.
  • Portable agents work exclusively with a particular IoT cloud platform, so they offer less flexibility than SDKs in that aspect of IoT design choices.

The Ideal Choice? It Depends

Which IoT cloud connectivity approach is the ideal one? It depends on your design goals, your level of experience with IoT products, how quickly you need to get to market, your budget, your BOM targets, and how many units you plan to ship for the IoT product you are building.

If you lack strong in-house IoT product expertise, production agents let you get to market quickly and with less risk. If you have a large stable of deep IoT expertise, SDKs provide the ultimate in flexibility and can help you save BOM costs.

If you have reached a point of some confidence in your IoT product development capabilities, or if you want to retrofit existing products with a different wireless module, or if you’re in the wireless module business, portable agents offer an attractive new alternative. You get most of the flexibility of SDKs along with some of the development guardrails of production agents. You can skip the time, expense, and hassle of waiting for the best wireless module for your design to be certified for your IoT cloud platform of choice.

Josh Pederson is director of product marketing at Ayla Networks in Santa Clara, Calif. He holds a master’s degree in information systems management from Golden Gate University.

Previous Article
Five Minutes with…Peter Thorne, Director, Cambashi
Five Minutes with…Peter Thorne, Director, Cambashi

Are you up to speed on digital twins? If you’re not, you probably should be, especially if you plan to play...

Next Article
Microsoft Azure IoT SDK Support Added to Express Logic X-Ware Platform

How to Develop Cross-Industry IoT Interoperability

Multi-Part Series