An IIot Gateway to the Cloud

A piece of learning we all seem to have gained from practical considerations of IoT infrastructure is that no, it doesn’t make sense to ship all the data from an IoT edge device to the cloud and let the cloud do all the computational heavy lifting. On the face of it that idea seemed good – all those edge devices could be super cheap (silicon dust) and super-low power.

But the downsides can be severe. The latency in a round-trip to the cloud may not be acceptable if that edge device needs real-time response to adjust machine behavior. Power at the edge can actually be worse if you are burning it to ship large quantities of data uphill. Security is a problem, as much in industrial IoT (IIoT) devices as in personal devices thanks to a potentially significant attack surface, from the edge to the cloud. Even reliability is at the mercy of the link and the cloud, perhaps acceptable for a consumer device, but not necessarily for industrial applications.

Which is why a lot more compute is moving to the edge. You can do most of the (local) compute you need there (especially for real-time needs), you have more control over the attack surface, you can buffer communication if the uplink is misbehaving and, if you’re careful, you can still do all of this with low power.

Then there’s the question of implementation technology. In the semiconductor world, we tend to assume this means custom ASIC solutions but it’s not always clear that approach is the most effective, especially in the IIoT where needs may be extremely diverse across widely different applications and may need to evolve as standards evolve. You could allow for more flexibility in software on the edge node, but that again becomes more power hungry.

In many IIoT applications a better compromise platform is an FPGA. It’s obviously reconfigurable and can be very power-efficient; not down at the mA consumer-level but quite satisfactory for many industrial support functions. And from a security point of view, while bitstreams (for reconfiguration) are not immune to hacking they are arguably better defended in today’s platforms than software. Moving more of those custom needs to hardware can only reduce the potential attack surface.

Ultimately whatever you are building has to connect both to sensors and actuators, and to the cloud. The sensor/actuator part of this will be part of your secret sauce presumably, as will be sensor fusion and data processing. But you don’t really need to reinvent all that communication, to sensors etc and to the cloud, if you can get it wrapped up in a reference platform. And if you can add hardware extensions on FPGA mezzanine card (FMC) daughter boards, you can configure most of what you need before you have to add anything. Sure, it won’t be as cheap (unit cost) or as compact as an ASIC, but it will be field configurable, there’s no NRE and anyway you can have it up and running tomorrow.

Aldec recently hosted a webinar in which they showed how to connect such a solution to the widely-popular AWS cloud services. They use their TySOM-1-7Z030 development board in the demo, based on the Xilinx Zynq processor with dual-core ARM A9, along with DDR, SD, flash and other interfaces, USB 2.0 and 3.0, UARTs, Gb Ethernet, HDMI, mPCIe and camera interfaces. Daughter cards offer multiple standard wireless interfaces also industrial interfaces such as RS standards and CAN, in a range of configurations covering ADAS, IoT, vision, industry and other applications.

Configuring this system follows an expected flow. You design the hardware part of the solution using Xilinx Vivado, along with Aldec Riviera-Pro for functional verification. The software part of the solution is built using the Xilinx SDK. Aldec don’t spend any time on this topic in the webinar (they have other resources you might find useful on those topics). The main focus of this webinar is on connecting your IIoT solution to AWS.

The Webinar walks you through setting up an AWS account, connecting to AWS IoT and registering and configuring your device. This requires a communication protocol, supplied by AWS, for which Aldec recommends the embedded C MQTT option, a lightweight messaging protocol for small sensors and mobile devices, optimized for high-latency / unreliable networks (remember those challenges). AWS then creates a connection kit and certificates for your “thing”, which you can add to your edge device.

Aldec provides demo examples with this type of build for TySOM boards so you can get started quickly with testcases then iterate towards your particular solution needs. Starting from a demo setup, the TySOM board will publish processed data from sensors to AWS. In the webinar, they show this in action, collecting and publishing temperature and humidity data on a fixed schedule.

The solution is scalable using multiple TySOM boards, each collecting different data from different sensors and each connecting to AWS. Looks like an interesting solution to get up and running quickly with an IIoT product/application. You can get more detail from the webinar HERE.