Hardware manufacturers have made significant efforts to develop attractive solutions for connecting sensor networks. Depending on field requirements, a wide variety of options have emerged. There are gateways for specific application areas, such as EXPEMB's FlexGate gateway, which is optimized for LoRa. There are also multi-talented systems, such as congatec's conga-IoT gateway, which provides up to eight radio antennas, enabling an extremely diverse selection of wireless technologies, as well as the connection of additional peripherals and fieldbuses. However, application-specific hardware platforms are only the first step toward a solution platform that makes it easier for OEM developers to obtain data from embedded devices and heterogeneous sensor networks in the cloud.
In the ideal world of cloud application developers, distributed hardware requires little attention. Developers want the process of connecting devices, machines, and systems to the cloud to be as simple as plugging USB devices or PCIe expansion cards into a PC: open the cloud, recognize the devices, configure them as needed, and the cloud connection is complete. If embedded computing devices had such a user-friendly interface, including peripherals, it would be very simple to automatically create all the required cloud applications and dashboards with the right frameworks and tools. The problem is that sensor data from the field level—ranging in size from a few bits for temperature measurements to gigabits of data from large video streams—is generated by a wide variety of sensors and delivered in a wide range of distinct data structures, across heterogeneous protocols, interfaces, and transmission paths. Without local logic that can process this heterogeneous data and convert it into information worth transmitting, establishing a useful connection to the cloud is virtually impossible. The cloud allows you to record any state at the highest density or collect only the necessary data in the short or long term, for example, to perform Big Data analytics and provide on-demand access to this data from anywhere. For this to work, you need a gateway, either a virtual system platform or a dedicated device, where the data is received, translated, processed, and transmitted transparently to the respective cloud interfaces.
The primary importance of gateways:
Gateways play a key role in orchestrating sensor networks because they are the node from which information is sent to the field, the cloud, or other neighboring gateways. In addition to the correct hardware configuration, they also need excellent linguistic and decision-making capabilities. They require logic to collect, analyze, and transcode sensor data and decide how to use this information. Finally, they need the ability to structure data consistently, plus logic for bidirectional communication within the cloud solution, all with secure end-to-end encryption.
The new Cloud API (Application Programming Interface) for congatec IoT gateways is an example of middleware and logic for the easy orchestration of wireless sensor networks. Its goal is to simplify the connection of embedded computing technology and associated peripherals to the cloud by providing application-ready software modules that customers can use as a template to develop their own applications. With the congatec Cloud API for IoT gateways, local sensor networks of all types can be integrated into any cloud solution.
The IoT gateway communicates locally with smart sensors, processing and converting the received sensor data. Embedded driver modules (EDMs) serve as an interface for third-party hardware and expansion cards, providing the logic that translates the received data into the application-specific semantics of the IoT gateway's logic. Data is transmitted step-by-step to the cloud through predefined interfaces and decision processes, using transparently defined modules and function blocks that can employ identical logical interfaces across all applications.
The Key Role of Middleware:
Software, especially IoT gateway middleware, is crucial for receiving data from the industrial field, translating, packaging, and transferring it to the cloud on demand. However, this is where compatibility typically breaks down because, to date, there are no standardized APIs for communication between sensors, gateways, and the cloud. This gap must now be closed by standardizing cloud APIs for IoT gateways. The goal is to find a unified way to receive and process data locally and then forward it to the cloud. After all, only an application-ready and, above all, standardized cloud API design enables plug-and-play integration of different wireless sensor connections such as Bluetooth LE, ZigBee, LoRa, and other LPWANs, as well as wired protocols for building and industrial automation. In this way, even highly heterogeneous protocol configurations can be easily integrated with minimal development effort. The same applies to cloud communications, of course, because the individual requirements for proprietary servers or third-party offerings such as Microsoft Azure, Telekom, or Amazon AWS Cloud must also be met in a plug-and-play manner.
The first software components to be standardized are the various cloud API function modules. From a field perspective, the sensor engine with EDM implemented in the congatec Cloud API for IoT gateways plays a key role, as it enables the translation and transmission of data from local sensors and actuators to a generic, protocol-independent middleware. It also standardizes measurements into freely definable physical units and verifies the meaning of the received data. With the standardized EAPI interface connection, the modules can provide relevant hardware parameters, such as system temperatures and voltages, CPU utilization, or theft detection.
Through its application-specific rules engine, the gateway sends local alerts and triggers automated actions when certain thresholds are exceeded or are about to be exceeded. Thanks to its hardware-independent sensor engine, OEM developers can consistently implement the same types of sensors, such as temperature sensors, in the same way. This simplifies configuration and increases efficiency.
What's missing beyond this logic for hardware connection and abstraction is a standardized cloud interface that can also be freely changed depending on the cloud provider. To address this, congatec has developed an interface module in cooperation with M2MGO: the communication engine. It provides encrypted communication with servers or different clouds via smart wired or wireless connections. If all function modules were offered based on an open, vendor-independent standard, sensors, gateways, and clouds could be freely assembled as needed. It would always work.
In addition to plug-and-play cloud connectivity for the hardware, developers also need a convenient solution for configuring IoT gateways to implement the described scenarios. One solution that integrates seamlessly with the congatec Cloud API for IoT gateways is the M2MGO People-System-Things (PST) cloud framework. Beyond device and system data management, PST provides a robust feature set for creating applications without any programming. Users can generate complete web applications using a drag-and-drop editor. Depending on the available devices, mobile end-user applications can now even be created automatically, without manual intervention.
Ecosystem Structure:
Of course, such an open cloud API approach can only be as strong as the ecosystem that supports it. For truly plug-and-play solutions, major embedded computing, peripheral, and cloud vendors will need to support a cloud API, as each hardware device requires a dedicated sensor engine, and each cloud requires an appropriate cloud engine. Depending on the required gateway decision logic, specific rule engine executions are all that is needed. This minimizes the development effort required to connect to the cloud. In standard installations, it is possible to deploy certified, application-ready modules without writing a single line of additional program code. Plug and play, as well as parameterization rather than programming, are the guiding principles. If all standard modules are installed correctly, the supplied sensor engine reads, translates, and processes the data on the IoT gateway immediately after capture, using the cloud's language. As a result, the user can view the processed information in an automatically generated web application instead of having to individually program and develop the entire process for each sensor. In the future, all desired data will be automatically transferred to the cloud and to the user.
Advantages of Standardization
But standardization offers even more advantages: with standardized function blocks, customers are no longer tied to a particular vendor. Furthermore, standardizing such APIs provides an ideal foundation for OEM migration strategies. Developers only need to design their IoT application once and can then port it to any sensor, gateway, and cloud combination for new applications. Such portability is highly convenient because a cloud solution that connects fieldbuses locally and then communicates via WLAN to a Microsoft Azure cloud is different from one that collects data locally via WLAN or LoRa and then transfers it over 3G/4G to a telecom cloud. If individual gateways support a standardized cloud API, developers only need to change the cloud engine; everything else can remain the same. This is an efficient way to implement even the most unique requirements with standard, application-ready building blocks. To give an example, here's a quick calculation: an IoT solution with four alternative sensor networks and three possible cloud environments for different applications previously required 12 completely different implementations on the IoT gateway (3x4). A standardized cloud API drastically reduces the complexity of the task to integrating or deploying just 7 engines (3 cloud engines plus 4 sensor engines). If some of these engines are already available, the effort is reduced even further. All these options also support the long-term availability of solutions.
The Status Quo of Standardization Efforts:
Given the numerous advantages of open standardization for OEMs and IoT application providers, the Standardization Group for Embedded Technologies eV (SGET) established a working group two years ago. As a preliminary result, SGET presented the first demonstration system of its kind at Embedded World 2017. The group is currently working to finalize version 1.0 of the new cloud API standard for embedded systems and expansion modules. The goal is official adoption of the standard in early 2018. Until then, more manufacturers are encouraged to participate, as the broader the support base, the greater the chances of establishing this standard for the long term. The cloud API standardization effort would receive a significant boost if, in addition to embedded technology manufacturers, peripheral device vendors and major cloud service providers also endorsed this open standard. Gaining the support of these stakeholders is therefore an important task for SGET within the standardization process.
Authors:
