IoT gateways need standardisation: replace as required...
02 July 2019
Who would want to be easily replaceable? But where x86 technology is concerned, this functionality has come a long way! Today, IoT gateway manufacturers are striving to raise the level of interchangeability further by standardising cloud communications.
This article was originally featured in EPDT's H2 2019 IoT & Industry 4.0 supplement, included in the July 2019 issue of EPDT magazine [read the digital issue]. Sign up to receive your own copy of EPDT each month.
And as Zeljko Loncaric, Marketing Engineer at expert supplier of industrial computer modules & single board computers, congatec explains, its congatec Cloud API for IoT Gateways paves the way for this…
No matter where you look: IoT and Industry 4.0 connectivity are among the biggest challenges facing companies today. On the one hand, machine manufacturers must offer retrofit kits for upgrading the installed base in factories worldwide. On the other hand, new solutions must be developed that can be integrated into new generations of devices, machines and systems. The feature set can differ greatly. While existing equipment is made smarter, for example, by virtually flange-mounting radio sensors on the devices, new solutions usually come as integrated single systems. It is therefore necessary to create a migration path. Old legacy applications still have serial interfaces. New applications are emerging in combination with wireless sensor networks, from NFC and ZigBee to low power wide area networks, such as LoRa. Such requirements lead to different hardware designs, as the FlexGate gateway from IoT embedded systems provider, EXPEMB illustrates.
The FlexGate gateway from EXPEMB is designed for harsh industrial environments and is specifically suited for LoRa communication. It can simultaneously follow eight LoRa channels to communicate with several thousand connected nodes. With Gigabit Ethernet, WLAN, 3G/4G and Bluetooth interfaces, the FlexGate gateways also offer a variety of options to connect to central clouds or fogs. All these options are available simultaneously on the gateway, plus there are individual scripts to set a fallback in the event of a faulty connection. A wide range of I/O towards the field – such as 2x USB ports, 1x serial interface, GPIOs and support of the Modbus fieldbus – allow the connection of additional local devices and networks as and when required. The gateway is based on a module from congatec and is freely scalable with ARM or x86 processors. While this system design allows many combinations, the focus is LoRa. Having said that, there are many other specialised solutions – some connect multiple serial interfaces, while others, such as the congatec IoT Gateway, are highly customisable.
The congatec IoT Gateway offers maximum flexibility for processor performance and software integration, and can be equipped with up to 8 wireless antennas, which can be connected via 3 mini PCI Express slots and 6 internal USB slots for wireless or wired communication modules. OEMs using the congatec IoT Gateway platform benefit from a pre-configured, pre-certified IoT gateway that makes it easy to connect a wide range of heterogeneous sensors and systems to cloud-based services. As the system has no specialisation, it can be used universally. The required interfaces, as well as the processor modules, can be configured as necessary. The integrated Qseven modules offer scalable computing power, ranging from NXP single-core i.MX6 processors to quad-core Intel Pentium CPUs – an ideal platform for flexible migrations with the right performance and interfaces to match the respective application. But because every application needs a specific design and neither one nor the other way will suit all purposes, there are of course many other solutions besides these two IoT gateways. These include the Technagon BC TeNUC-100 or the iesy NUC1-E8000-SK-1 box PCs, both of which are based on Qseven and can be used as IoT gateways.
The software makes the gateway
But what turns all these hardware designs into IoT gateways? It can only be the firmware or middleware that enables OEMs to receive the data from the industrial field in real time, analyse it and distribute it to the appropriate other instances. It is exactly at this point where the interchangeability of embedded computer technology ends, because there are no standardised APIs for sensor and cloud communication. congatec’s new Cloud API for IoT Gateways is designed to close this gap. The goal of standardisation is being able to connect different hardware with the same software, thereby making it unnecessary for developers to modify their software when switching from one IoT gateway to another.
The key software components of the Cloud API for IoT Gateways are the different Cloud API function modules, as well as the demo and test modules for provider-independent IoT clouds. Developed in compliance with the Universal Internet Connector (UIC) standard defined by the SGET, the sensor engine of the congatec Cloud API for IoT Gateways ensures protocol-independent communication with local sensors and actors. In addition, it normalises the measured values to freely definable physical units and checks them for consistency. The congatec CGOS library integrates relevant gateway system parameters, such as system temperature, CPU workload or intrusion detection. The gateway uses the rule engine to initiate local warnings and automated actions if certain parameters are exceeded or threaten to exceed the predefined limit. Last but not least, the communication engine standardises the encrypted and operator-independent wireless or wired cloud communication.
In a reference design, congatec has integrated the Microsoft Azure cloud, but it is of course possible to implement other 3rd party cloud offerings, as well as the on-premise clouds of OEMs or end users. The IoT cloud evaluation software provides developers with all the tools they need to consolidate sensor data in the cloud. In addition, it is possible to create central reporting and control rules for connected IoT applications, define further escalation scenarios and provide dashboards for remote clients.
With these function blocks, the Cloud API provides everything that’s needed to develop an IoT gateway. If the same SGET-specified API is utilised across different platforms, developers have an ideal basis for creating interchangeable IoT gateways. In addition, API standardisation paves the way for OEMs’ migration strategies, because once an IoT application has been developed, it can be installed on other hardware platforms for new applications without rewriting any of the application code. Such portability is extremely important, because a gateway that connects field buses locally and then communicates via WLAN looks different to a gateway that collects data locally via WLAN and then sends it to the cloud via 3G/4G. So from the point of the hardware, there is no way to create one gateway for all purposes. But it is possible to create modular options and standardise their application connectivity. This way, even the most specific individual requirements can be implemented with application-ready modules.
The software modules of the Cloud API for IoT Gateways are made available in C++ source code, which significantly simplifies the integration of the API into own IoT applications for Linux and Windows. Furthermore, since the current Cloud API cannot meet all requirements right from the start, congatec also provides additional software services for the extension of the Cloud API functions and the Cloud connection, so that the functional scope of the Cloud API will grow over time. Vendor-independent standardisation through the SGET will act as an additional boost, leading to further expansion of the functionalities and application scope of the standardised Cloud API for IoT Gateways.
Contact Details and Archive...