The 4 fundamental C's of IoT architecture and design

blueprint design architecture
Credit: Shutterstock

A discussion of the 4 fundamental design and architectural considerations for high performing IoT ecosystems.

Related Topics

The secret to a successful and value oriented Internet of Things (IoT) ecosystem lies in the four C’s of Categorization, Calibration, Control and Collection of the Internet connected “things.” Delivering and deriving value from IoT requires the collection of relevant signals and data from highly calibrated connected devices and a timely adaptation of the device that improves the existing state and delivers exceptional value.

Categorization

Categorization is the ability of the service provider to categorize their devices and other things according to various factors and characteristics such as device type and family, affinity to a use case, physical and virtual location, calibration settings, intended use of the collected data (e.g. A/B testing), data payload and any other possible characteristics of the device, its manufacturer, its environment, its connectivity profile, the collected data and the intended use of the data.

Categorization is applicable to all stages of IoT management i.e. calibration, collection and control. Categorization is not only useful during data collection, preparation and analysis but also other less strategic but yet critical aspects such as device deployment, device maintenance and repair, reliability, health monitoring and alerting. The ability to fine tune device segmentation through categorization capabilities leads to a high degree of flexibility, visibility and control over the IoT architecture.

The real value of categorization is delivered during analysis time where micro segments can be identified and analyzed to understand the micro and macro impact of various factors to the performance of the device and the experience of the user/customer.

Calibration

Calibration refers to the ability of the service provider to adapt and fine tune the device’s sensing abilities to both collect signals and data at the optimal fidelity, frequency and mode (specific to the scenario and intended usage of the data).

Calibration, ideally, should be remotely defined and propagated. The service provider should target the ability to define the calibration scheme for a device, a collection of devices (where the collection can be defined by properties of the device), its environment or its usage. Devices and connected things should be remotely addressed with one or more calibration schemes.

In addition, devices should be able to register and download a calibration profile that determines how and what data they collect. In this mode, devices should be able to ping their back end and download the required calibration scheme that determines how and what data they collect.

Calibration can and should be variable given the time and location of the device i.e a device should be able to adopt a more aggressive or expansive calibration scheme given a specific time and/or location or in response to another external signal or stimuli.

Service providers need to ensure that remote calibration is possible and backed by a programmed system driven by rules and heuristics that can semi autonomously enable devices to adapt to control the best possible data given its environment and then circumstances.

Control

Control refers to the ability of the service provider to exert control over the devices remotely over a virtual connection. Control includes the ability to change or modify the device’s behavior, look and feel and/or how it interacts with its environment and users. Control also includes the ability for the service provider to remotely calibrate or influence the data collected from the device.

Control can be enforced through several mechanisms. The most common mechanism involves configuring the device with the ability to change its behavior or appearance based on an incoming signal. The incoming signal is transmitted through a previously agreed protocol and format between the device and the remote service provider. The signals are transmitted over the Internet or other specially defined networks. Another option can involve a device pinging the service provider back end for new “directives” that it downloads. This mechanism requires the device to poll the back end continuously at a predefined frequency.

Collection

Collection refers to the ability of the device to send data payloads back to the service provider back end. Collection can be initiated both as a push or a pull from the device. Collection can be triggered and influenced by the size of the payload, the calibrated data sensing frequency, the available network and the desired data upload frequency. Typically there are three different ways to build in collection.

Option 1: Direct Upload to data backend

In this option, devices directly connect to the back end to push data payloads. This approach requires that the data back end be able to scale to the number of devices, the upload frequency and the payload size to ensure that there is minimal data loss. This option works best for small, infrequent data uploads over highly available Internet connectivity

Option 2: Upload through proxy

In this option, devices upload their data to a proxy device that has the required power and stronger connection to the network to be able to upload data to the data back end. The proxy can also act as a batching layer and can be controlled through separate calibration and collection parameters from the actual device.

Option 3: Upload via stages

In this option, multiple devices upload data to a staging area that collects and collates data from multiple devices and then sends the entire batch to the actual data back end. This approach reduces the number of connections in parallel that the data back end needs to support and federates the data collection process across multiple staging systems.

Conclusion

The ability to successfully implement an IoT architecture requires service providers to carefully plan out their 4Cs to ensure that their architecture is best suited to the device, users, the use case and their back end. Ideally, each level in the IoT architecture is highly configurable enabling the device to easily switch its configured personas depending on business and user needs.

This article is published as part of the IDG Contributor Network. Want to Join?

To comment on this article and other CIO content, visit us on Facebook, LinkedIn or Twitter.
Related:
Download the CIO October 2016 Digital Magazine
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.