Picking an IoT Gateway for a Proof of Concept

“How do I go about selecting an IoT Gateway for building my Proof of Concept?”

Let’s consider a conditioning monitoring application wherein we need to monitor the health of an induction motor and provide predictive maintenance insights to the operators of the motor.

For this, we would like to measure the vibration, current and maybe temperature too, corresponding to different parts of the motor. Once we start gathering these measurements, we would like to communicate with a central server on the Cloud, where we might use Machine Learning to provide predictive maintenance insights. The sensor nodes in this case communicate over a low power 6LoWPAN network with the IoT Gateway. The Gateway aggregates the sensor data and communicates with the Cloud using a protocol such as AQMP.

Figure 1: Condition monitoring application that depicts the role of the IoT Gateway in the system.

What would be the requirements for the IoT Gateway in such a system?

For me, it would be the following:

1. Networking: An ideal Gateway for me would support multiple options such as Ethernet, WiFi and Cellular for communicating with the Cloud. It would support wireless interfaces such as 802.15.4 (6LowPAN/Thread) and wired interfaces such as RS232 for communicating with sensor nodes. The Gateway would also support BLE (or USB) for field provisioning.
2. Cloud Communication: Major cloud platforms such as Microsoft Azure and AWS provide SDK(s) for easy integration of the Gateway with their IoT hubs — the Gateway should support these SDK(s).
3. Security: Ability to use TLS or SSL for securing cloud communication is critical. The major cloud platform SDK(s) provide device management features that should enable a good degree of security.
4. Processing: I wouldn’t expect to do much processing on the Gateway -relying mainly on the cloud for the heavy lifting. But having the flexibility to do some real-time processing would be good.
5. Power: Not critical as the Gateway would typically be mains-powered.
6. Cost: I wouldn’t be too sensitive towards cost as there would typically be just one Gateway per deployment.

The way I would design an IoT system is to first prototype the Gateway code — using Azure SDK for example, on one of several maker platforms. Then, once I have a Proof of Concept, I would move to an Edge Gateway by Dell or Advantech. This would provide me with professional quality hardware (product level certifications for FCC, CE, etc., industrial grade enclosure) on which to run my Gateway code.

Figure 2: IoT Gateway in the path from Proof of Concept to Product

For my analysis, I compared three maker platforms — the Raspberry Pi 3, the Intel Edison and the FRDM-K64F. There are other platforms I had in mind too — notably, the Particle Electron for applications that might require cellular communication. But in the interest of time, I picked three platforms that seemed to have potential to support the widest range of applications.

In the table below, I try to compare some features that were important to me across these three platforms.

Table 1: Comparison of features across three maker platforms for use as an IoT Gateway

So which one is the winner? There is probably no right answer — I think there might be a place for each of the 3 platforms:

• Raspberry Pi 3 for getting started with a Proof of Concept due to it’s excellent community support.
• Intel Edison for it’s higher performance and smaller form factor. Plus, the integrated Quark MCU that runs an RTOS makes it quite promising.
• The FRDM-K64F platform offers a powerful MCU that might be a good fit for applications that need real-time processing. However, I am not sure I would want to use it as a gateway — using a Linux based device (such as the Raspberry Pi or Edison) offers more flexibility in terms of support for Node.js or Python.

The contest then narrowed down to between the Pi 3 and the Edison. In my final analysis, I picked 4 aspects for comparison:

1. Cloud Connectivity: taking Microsoft Azure as an example, I found that it should be possible for me write a Node.js program using the SDK provided by Azure and it should work equally well on the Pi3 and the Edison since the underlying OS is Linux. So, my gateway code is likely to be portable across both platforms, which is good.
2. Real Time Processing: The Quark MCU running RTOS on the Edison might have been a killer feature on the Edison but my sense is that it might take some more time for some good documentation, examples and support to become available.
3. Networking: The lack of an Ethernet port or Ethernet shield for the Edison seemed like a deal-breaker for me as many industrial applications tend to prefer the use of Ethernet over WiFi for greater reliability.
4. Support: There is no denying the fact that the the Raspberry Pi 3 enjoys the benefit of a longer legacy — but there is simply no comparison for the support that Pi 3 offers a newbie. Be it in terms of open source repositories (~21,000 on GitHub vs ~700 for the Edison) or community engagement, the Pi 3 seems to win hands down.

With this analysis, the choice became clear to me — the Pi 3 would be my ideal IoT Gateway for a Proof of Concept.

In future posts, I will try delving deeper in to some of the finer details involved in building IoT applications.

What would your ideal IoT Gateway look like? Is there any other factor you would consider when selecting a Gateway for your application? Please feel free to shoot me your comments, suggestions or questions! I would be happy to exchange notes. Together, we can be #AheadOfWhatsPossible.