Eric J. Bruno
All too often, IoT solutions contain a hodgepodge of components, devices and software at the remote end. This can include a gateway (or a smart phone or tablet in its place), Wifi connectivity (Mifi’s are sometimes used), and varying sensors and boards with a multitude of communication protocols. For instance, there may be Zigbee communication from electrical controllers to a specialized Zigbee gateway, then Ethernet connectivity to a second gateway that connects to the Internet, and possibly other smart devices on-site depending on the solution.
This might get the job done, but it’s not reasonably flexible or reusable. Instead, what’s needed is a standardized approach to device and sensor communication, where back-end server connectivity is seen as an extension of the remote solution. This is what we call the IoT Service Bus (ISB), and its enabled by IoT gateway software (and device libraries) that provide the following:
The ISB effectively extends the enterprise cloud or data center infrastructure to remote locations in order to connect sensors and devices in a holistic IoT application (see Figure 1).
This is a logical diagram that helps to conceptualize the solution. For instance, while simpler, less capable devices communicate with the back-end services through the IoT gateway, the smarter, more capable devices can bypass the gateway by using a built-in ISB library component. This also assumes the smart device speaks an enterprise communication protocol (i.e. WebSockets) as opposed to an IoT protocol (i.e. MQTT). Otherwise, even for more capable devices, the ISB gateway serves as a bridge as shown in Figure 2.
Also illustrated is how an ISB Gateway can serve as a bridge to other ISB Gateway instances at the same location. This hierarchical gateway approach is useful in many implementations, such as building automation (i.e. with a gateway per floor), or other scenarios involving large clusters of devices. It can help to isolate subsets of devices for reasons of convenience, communications, and/or security.
Diving deeper into the ISB Gateway, it’s based on a layered implementation (see Figure 3 for an exploded view). Built on OSGi, components can be individually updated and restarted, and new components can be provisioned and added. For example, this includes event processing components, custom communication adapters, even custom IoT applications that run on the gateway.
Multimedia support is useful in IoT solutions that require audio, video or photo data processing. For example, some factory automation solutions require periodic photo or video capture for quality assurance or analytics processing. Data indexing is useful in event-based systems where data grouping and aggregation is required. Not shown here are smaller components such as logging. OSGi also provides flexibility as individual components can be turned off if not needed (i.e. multimedia).
Overall, the ISB is meant to extend your enterprise infrastructure to your devices in a standardized and reusable way. In the next issue, we’ll explore the back-end architecture, meant to run within the cloud or data center, which enables ISB-to-ESB communication, security, provisioning, and more.