Successfully Orchestrating Sensor Networks



How cloud API standardization clears the way to plug-and-play cloud solutions

Clouds and the multiple ways they can store, analyze, and generate data on demand have become indispensable for many OEMs. Uses include monitoring and controling decentralized smart home automation, building control, and facility management systems. Yet in practice, it is often difficult to process and transfer decentralized sensor data. This is mainly due to the endless variety of distributed logic in the field. Inconsistent data, protocols, and transmission media as well as heterogeneous operating systems and proprietary interfaces to different cloud providers all too often result in fragmented and complicated implementation despite the large cloud potential. So how do you simplify the process of getting sensor data into the cloud?

Hardware manufacturers have gone to great efforts to develop attractive solutions for connecting sensor networks in smart homes, buildings and intelligent facilities. Depending on field requirements, very different options have emerged. There are gateways for specific application fields, such as the FlexGate gateway from EXPEMB, optimized for LoRa and perfectly suited for deep indoor smart metering.

Figure 1: The conga-IoT gateway can be equipped with up to eight radio antennas that are connected via 1x M.2 and 6 Mini PCI Express slots for wireless or wired communication modules. Cloud API support enables plug-and-play delivery of system data to the cloud. With the appropriate support, the same applies to the expansion modules. (Image: congatec)

Also on the market are gateways with up to eight radio antennas. With such gateways, users enjoy a broad choice of wireless technologies, such as Zigbee, ZWave, Bluetooth, and WLAN, and can also connect additional peripherals such as fieldbuses. However, hardware platforms that suit the application are only the first step towards a solution platform that makes it easy for OEM developers to get the data from embedded devices and heterogeneous sensor networks into the cloud.

The problem is that the 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 as wide a range of different data structures, via heterogeneous protocols, interfaces and transmission paths. Without a local logic that can process this heterogeneous data into information that is worth transmitting, it is virtually impossible to realize a meaningful cloud connection. The cloud allows you to log any state in the highest density, or to collect only data needed in the short or long term, for instance to carry out Big Data analysis, and to provide on demand access to this data from anywhere. For this to work at all, you need a gateway—whether a virtual system platform or a dedicated device—where the data is received, translated, processed, and transmitted as transparent information to the respective cloud interfaces.

The Central Importance of Gateways

Gateways play a central role in the orchestration of sensor networks because they are the node from which information is sent towards the field, the cloud and other neighboring gateways. In addition to the right hardware configuration, they also need excellent linguistic and decision-making capabilities. They require a logic to collect, analyze and transcode sensor data and to decide what to do with this information. Finally, they need the capability to structure the data consistently plus a logic for bidirectional communication within the cloud solution—all with secure end-to-end encryption.

This type of enhanced gateway includes middleware and glue logic for easy orchestration of wireless sensor networks. It aims to simplify the connection of embedded computer technology and associated peripherals to the cloud by providing application-ready software modules that customers can use as a blueprint to develop their own applications. A solution that includes this functionality is the congatec Cloud Application Program Interface (API) for IoT Gateways (Figure 2), which enables local sensor networks of all kinds to be integrated into any cloud solution.

Figure 2: The Cloud API features a modular architecture, with a standardized process for connecting individual components. This approach enables a modular use of ready-built components such as third-party rule engines. In the cloud application developers’ ideal world, the distributed hardware needs little attention. Developers want the process of connecting devices, machines and systems to the cloud to be as simple as connecting USB devices or PCIe expansion cards to a PC: Open cloud, recognize devices, and configure as needed—and presto—the cloud connection is ready. If embedded computing devices had such an easy-to-use interface that worked for peripherals as well, it would be simple to automatically create all the required apps and dashboards in the cloud with the appropriate frameworks and tools.

Optimized IoT gateways communicate locally with intelligent sensors, processing and converting the received sensor data. Embedded Driver Modules (EDMs) serve as an interface to the hardware and third-party expansion cards. EDM glue logic translates the received data into the semantics of the application-specific IoT gateway logic. The data is then transmitted step by step into the cloud via predefined interfaces and decision processes, using transparently defined modules and function blocks that can employ identical logic interfaces in each application (Figure 3).

Figure 3: Cloud API enabled IoT building blocks feature defined interfaces to the Cloud API. Solution developers benefit from ready to use ecosystem building blocks to build their solution with off-the-shelf components.

Middleware Matters

The software—especially the middleware of the IoT gateways—is in charge of receiving data from the industrial field and then translating, packaging, and transferring it on demand to the cloud. Yet this is exactly where compatibility generally ceases, because to date there have been no standardized APIs enabling sensors, gateways, and clouds to communicate. Standardizing cloud APIs for IoT gateways can close the gap. The goal is to find a unified way of receiving and processing data locally, and then forwarding 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. This way, even highly heterogeneous protocol configurations can be integrated easily and with minimum development effort. The same applies to the cloud communications, of course, because individual requirements for proprietary servers or third-party offers such as the Microsoft Azure, Telekom or Amazon AWS Cloud must also be met in a plug-and-play fashion.

The first software components to be standardized are the various cloud API function modules. From the field point of view, an optimized gateway’s sensor engine with EDMs implemented plays a key role as it enables the translation and transmission of data from the local sensors and actuators to a generic, protocol-independent middleware. It also normalizes measurements to freely definable physical units and checks the received data for meaningfulness. With the connection of the standardized EAPI interface, the modules can provide relevant hardware parameters, such as system temperatures and voltages, CPU utilization, or burglary detection.

Via the application-specific rule engine, the modern gateway ideally sends local alerts and triggers automated actions when certain thresholds are or threaten to be exceeded. Thanks to the enhancement of the sensor engine, the gateway itself is hardware-agnostic, enabling OEM developers to implement the same sensor types, such as temperature sensors, always in the same way. This simplifies configuration and increases efficiency.

What is still 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. A joint effort between congatec and M2MGO provides an example: an interface module that functions as a communication engine. It provides encrypted communication with servers or different clouds via smart wireless or wired connections. If all function modules were offered on the basis of a manufacturer-independent and open standard, sensors, gateways and clouds could be freely assembled as desired. It would always work.

In addition to plug and play cloud connectivity for the hardware, what developers need to implement the described scenarios is a convenient solution for the configuration of the IoT gateways. The M2MGO People-System-Things (PST) cloud framework, which makes possible seamless integration with next generation gateways, enables such configuration. Besides a device and data management system, the PST framework provides a solid feature set to create applications without any programming. Users can generate full-fledged web apps with the help of a drag-and-drop editor (Figure 4). Depending on the available devices, mobile end user apps 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, all major vendors of embedded computer technology, peripherals, and clouds will need to support such a cloud API, as each hardware device demands a dedicated sensor engine, and each cloud an appropriate cloud engine. Depending on the required gateway decision logic, specific executions of the rule engine are all that’s needed, thus minimizing the development effort for connecting to the cloud.

Figure 4: With congatec’s Cloud-API for IoT gateways and the People-System-Things (PST) Cloud framework from M2MGO users can generate full-fledged web apps without coding using only drag-and-drop.

 

In standard installations, it is possible to deploy certified application-ready modules without having to write a single line of additional program code. “Plug and play” and “parameterization, not programming” become the guiding mottoes. If all standard modules are correctly installed, the supplied sensor engine reads, translates and processes the data in the IoT gateway immediately after its capture in the language of the cloud. As a result, the user can view the processed information on an automatically created web app instead of having to individually program and develop the entire process for each sensor. In future, all the desired data will automatically be transferred to the cloud and to the user.

Advantages of Standardization

But standardization offers still further advantages: With standardized function blocks, customers are no longer tied to a particular supplier. In addition, the standardization of such APIs provides an ideal foundation for an OEM’s migration strategies. Developers need only design their IoT application once and can then port it to any sensors, gateways and cloud combinations 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, differs from one that collects data locally via WLAN or LoRa and then transfers it via 3G/4G to a telecom cloud.

If the individual gateways support a standardized cloud API, developers need only change the cloud engine; everything else can remain as is. This is an efficient way to implement even the most individual requirements with application-ready standard blocks. To give you an example, here’s a quick calculation: An IoT solution with four alternative sensor networks and three possible clouds for different applications previously required 12 entirely different implementations on its IoT gateway (3×4). A standardized cloud API drastically reduces the complexity of the task to the integration or implementation of only seven engines (three cloud engines plus four 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.

What’s Next for Standardization

Open standardization has a long list of advantages for OEMs and IoT application providers, so the organization Standardization Group for Embedded Technologies e.V. (SGET) established a working group two years ago. As a preliminary result, the SGET presented the first demo system of this 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—because the broader the support base, the greater the chance of establishing this standard in the long term. The cloud API standardization effort would receive an immense boost if, in addition to the manufacturers of embedded computer technology, peripheral device vendors and leading cloud providers were to support this open standard as well. Winning support from these stakeholders is therefore an important task of the SGET within the standardization process.


Kevin-Louis Pawelke is CEO, M2MGO. Pawelke has 14 years of consulting, business development, and project management in various international companies.

 

 

Jens Uhlig is CIO and IoT Solution Architect, M2MGO.

 

 

 

Carsten Rebmann is Director R&D, congatec.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: