IoT gateways are the most demanded enabler for industrial IoT applications. This for good reasons: The communication infrastructure in the fields is fragmented; various sensor networks get deployed to connect existing and new machinery. And even in the clouds different communication protocols are used to connect to Big Data databases and enterprise-class management systems. Engineers consequently need a gateway platform for most efficient customization of the transcoding and communication management systems.
Life would be much easier if there was a way to transcode all the various industrial and device communication protocols and messages, similar to a Google translation tool that transfers long texts up to 5000 characters in real time today. It will take years to get such a system as an ‘out of the box’ solution that identifies the language and that is as sophisticated and precise as native speech, while also transferring all units and measurements correctly in a unified manner. But this is in general possible and may be easier to design than a truly human-like speech translation engine. In the meantime, engineers need to ‘train’ their IoT communication gateways with more simple means, for example by using spreadsheets or dedicated databases for specific protocol solutions to address the specific translation and decision processes of today’s diversified IoT applications.
A need for design efficiency improvements
For being able to build these transcoding and decision processes in the most efficient manner, engineers need a cloud enabled Application Programming Interface (API) that is designed for IoT gateways and edge servers to manage not only the various communication demands to the cloud, but also the smart sensor networks and the IoT gateways themselves. This API needs to be capable to most flexibly adapt to the various field communication needs on the one hand, and to be flexible towards the clouds and servers on the other. On the field level, it has to handle many different methods of communication, starting from serial interfaces to field busses and industrial Ethernet solutions up to the various wireless sensor networks for short distances – including BLE, ZigBee, and Z-Wave – as well as Low Power Wide Area Networks (LPWANs) such as LoRa or Sigfox.
The API therefore has to provide a flexible programmable interface for at least three or more communication channels: An upwards channel for the communication with the clouds; one or more downward channels for communication to the field(s); and one horizontal channel to connect with other gateways, which can be located nearby or at the other side of the world. On top of the transcoding and communication demands, a local analysis and decision process is required to reduce latency. Finally, an execution engine needs to be installed to send data to the various communication partners.
Dedicated hardware design is the first challenge
Engineers who want to build such IoT and Industry 4.0 gateways are faced with two challenges. They need to address the different field setups through dedicated hardware design. In most cases, they use computer-on-modules today for this setup as these offer the entire computing core as one application-ready component that comes further equipped with all required drivers. The carrier board for the modules executes the dedicated interfaces – whichever and wherever they are needed. Design guides help engineers to design these carrier boards properly and circuit diagrams, that often are made available for free, deliver a perfect blueprint to start the customized design. The scalability provided by modules secures NRE cost in gateway designs in the long term, consequently offering maximum payback on investments for decades. The competitive landscape with many module vendors ensures competitive pricing and provides a rich ecosystem of alternatives and accessories for the designs. Independent standardization bodies such as the SGET e.V. or PICMG guarantee a vendor independent development of the standards. But today, everything else needs to be built individually.
Hardware-near systems programming is the next hurdle
No. Stop. Not everything. First aid is already available with the standardized Embedded API defined by the PICMG and adopted by the SGET. This EAPI delivers standardized hardware function calls even across modules from different vendors to improve design security by more vendor independence and more standardization. Typical standardized function calls include the watchdog timer, I2C bus, GPIOs, backlight brightness or user storage in firmware flash. This makes it relatively easy to acquire the health data from a hardware platform and deliver it to the cloud. But no rule engines and communication stacks to the cloud, no integration systems for peripherals, or even smart wireless sensors are addressed with this API.
Consequently, next generation embedded systems that are connected to the clouds or other devices via the IoT or Industry 4.0 need a more powerful and comprehensive API. The ComX™ design initiative announced by congatec at ESEC in Japan goes beyond the current specifications for computer-on-modules. The ComX™ standardization targets two pillars: The API and middleware standardization including APIs for IoT gateways or embedded features of COM Express Type 7 server-on-modules; plus approved circuit diagrams and logic for required carrier board implementations such as FPGA integration, switching logic for USB-C, or for SMART battery logic.