Gateways play a critical role in Commercial IoT applications. They manage end devices in a complex environment, collect and analyze data, provide local command and control, secure edge infrastructure, and communicate processed and/or aggregated data to the cloud. Determining your requirements for the gateway for your specific IoT use case is an important first step in designing an IoT solution. As prototyping an IoT gateway solution can help, I’m often asked about the best approach. And, more specifically, if Raspberry Pi or another solution is the best starting point. The answer depends in part on your particular needs when it comes to project timing, level of required support, hardware adaptability, production scale, security, power, connectivity, exterior appearance, and your business case.
As a result, in this article I’ll walk through two common IoT gateway prototyping approaches: Raspberry Pi and commercial-grade production gateways. Both with the common goal of scalable, cost-effective mass production in mind.
If you need to get started quickly Raspberry Pi is certainly a viable option, as they can be purchased readily on hundreds of websites. With hardware in hand you can get started right away. Unfortunately, the Pi does not come with an operating system, so you will need to spend some time choosing the right one and installing it on your one or more devices.
You may need to spend additional time once the OS is up and running determining add-ons required to make the Pi into a full featured IoT gateway.
Power is a critical consideration for your IoT gateway, especially as many commercial buildings today use Power over Ethernet (PoE). Installing Ethernet cabling, considered a “low voltage” installation, significantly simplifies installation and reduces cost, as PoE is less expensive than wiring in an outlet. Raspberry Pi does not offer PoE as an option, however this is mitigated by adding on a PoE adapter.
The Raspberry Pi 3 has both Wi-Fi and Bluetooth built in. This can pose an issue, though, if you try to stream too much data, as the two radios will compete for air time. For example, if your project will scan Bluetooth Low Energy (BLE) for nearby devices advertising sensor data or location information, your system will effectively be deaf every time the Wi-Fi radio sends a packet to the cloud.
Conversely, if your use case requires cellular connectivity, using Raspberry Pi means you’ll need to plug in a USB modem. You will also require a daughter card if you need BLE 5.0, Thread, ZigBee or other proprietary mesh protocol.
Raspberry Pi has a great online community. It is very active and many of the common pitfalls of setting the device up as an IoT gateway have already been experienced and overcome by other users. This being true, you will still need to do all the investigation and educate yourself very thoroughly to be successful. In the end you will need to be your own best support for the product throughout prototyping and even through its complete life cycle as your implementation will be unique to you. Further, if you get beyond prototyping and plan to deploy in a Commercial IoT application at scale you will need to build out your own 24/7 support system.
If you are looking for the most hardware flexibility and adaptability, then the Raspberry Pi is certainly the way to go. There are many, many ways to add functionality and capacity in all of the components. The challenge comes when you look to optimize the hardware for cost, ability, and efficiency at scale after you are done prototyping. Often times you will end up paying more at scale because your OS takes up a lot of space and so you need extra storage in each gateway. Or your Bluetooth antenna does not have good range, so you’ll need twice as many gateways as you expected to cover the area required in your solution. Finally, in many commercial environments you will need your final hardware configuration to be certified before it can be used in production, which can be time consuming process.
This is one area where the Pi will not compare very well. By default, security at each level (hardware, OS, network, application, etc.) will have to be implemented from scratch by you. For Commercial IoT use cases, you will need to secure the Pi in many ways to thwart the vulnerabilities inherent in having a connected computing device in a physically unsecured environment like a hotel room, restroom, or warehouse. Further, assuming you choose one of the common operations systems you will also need a way to keep it up-to-date, as new versions of the OS are released to protect against CVEs that are discovered. Thought this effort will not be too bad in prototyping it will be particularly challenging with hundreds or thousands of these gateways in a production environment.
Can you imagine the Raspberry Pi with its open plugs, connectors and motherboard at your local restaurant or retailer? Luckily, the popularity of the Raspberry means that you can easily find enclosures (though most are intended for hobbyists). In my experience, companies want a sleek IoT gateway enclosure with design elements for cable management, and often wall or ceiling mount options for installation.
The cost analysis of using a Raspberry Pi is similar to the cost analysis of almost any DIY solution, the acquisition cost of the base product is very affordable and looks appealing. However, once you have purchased all of the additional parts (extra antennas, cellular modem, enclosure, etc.) to make it into a fully featured, deployment-ready IoT gateway the cost is significantly more. Then there is a total cost of ownership, after the prototyping phase, based on the costs of building out a deployment, management, and security platform so that the solution can really function at scale. Finally, there are costs related to the increased risk associated with a first-of-a-kind product, along with building out an ongoing support department, and possible lost opportunity due to a longer time-to-market.
Next let’s assess production-ready commercial IoT gateways against these elements.
The actual purchase and acquisition of the IoT gateway will take longer with a commercial solution than with the Raspberry Pi. Since these commercial solutions are production-ready you will more than likely want to do a feature and cost comparison and possibly even a POC on several different models and/or services. However, once you decide on a solution, getting the solution up and running will happen 5-6 times faster with the commercial solution than with the Pi. In the end you will get through POC and prototyping, and move on to production, significantly faster than on a Pi, and you should also be able to build on the same platform through each development stage shortening time to market.
Production-ready IoT gateways often come equipped with popular commercial-grade features such as Power over Ethernet. Many commercial building spaces prefer PoE to simplify and reduce the cost of installation. An added benefit? Most wireless access points are powered by a switch that has a battery backup, so the IoT system using the same switch can still function even if the power goes out.
Connectivity is where a commercial IoT gateway can really shine. For example, some IoT gateways support Wi-Fi at both 2.4GHz and 5.8GHz, as well as give users cellular connectivity options. No matter how much data you need to transmit, it will do so smoothly, without competition for resources. Additionally, leading commercial-grade IoT gateways will also provide support for Bluetooth 5, Thread, ZigBee and possibly other proprietary mesh protocols, thus decreasing the engineering resources needed to design and manufacture your gateway solution.
Support is one of the biggest differences between the DIY approach of a Raspberry Pi based IoT gateway and a commercial solution. With the commercial solution you should expect to get 24/7 support provided by several levels of technicians. Most will offer immediate call-in support and an email option for lower severity concerns. Some will even offer the option to have the technician remotely access your gateways to investigate problems and tune them up.Finally, with, for example, Rigado’s Cascade IoT Edge-as-a- Service you are provided with a complete managed service where the connectivity infrastructure is taken care of so that you can focus just on your application and providing real, differentiated value to your customers.
With production-ready IoT gateways you’ll likely have several models to choose from, often with some configuration options, but ultimately not nearly as flexible as a Pi solution. What you should get in exchange for this less adaptable solution is the lowered risk of a more reliable, field proven design with increased hardware efficiency and optimization. These designs have been tested and re-tested. They have also been optimized to meet exact environmental requirements with no excessive hardware, so that they can be as cost effective as possible during prototyping and even more significantly so at scale.
Security in a DIY solution is often an afterthought, and this is certainly understandable. There is quite a bit of work that goes into getting the solution to just work and work consistently – collecting, processing and then sending data to the cloud. Often teams are already behind schedule just getting the solution to a point of working reliably. The good news is that some production-ready solutions offer security patching as a service, which is a great way of at least keeping the OS up to date. Beyond prototyping and into production, IoT security must necessarily go much further, because in most cases the IoT gateway is in an unsecured or only marginally secured environment like a hotel room or a restaurant. As such, there needs to be robust security at each level (hardware, OS, network, application, etc.) and this security needs to start at manufacturing and extend all the way to the production environment. For production environments at scale you will also need a complete monitoring and alerting system to proactively help you determine if a breach is occurring, so that you can counter it quickly.
When professional appearances matter, production-ready IoT gateways conceal cables and typically include wall and ceiling mounting options. And, in most cases will ship directly to your end-user customers where installers can simply open the box and add your gateway to the building. Leading gateway providers will even enable you to customize the gateway’s exterior, branding it with your company colors and more.
As mentioned above the initial purchase price for a production-ready IoT gateway will likely be considerably higher than that of the Raspberry Pi. In the case of some production-ready gateways there is also an ongoing cost for support and managed services that you do not have with the Raspberry Pi. The best comparison is really after a successful prototype and includes comparing the total cost over time for the gateway in production at scale, including the soft costs of deploying, updating, and maintaining the complete, secure IoT infrastructure.
In many cases the choice between a DIY and production- ready PoC solution is ultimately decided based on the personnel that you already have on staff. If you have hardware engineers and an assembly team already, and if you have software engineers and an operations team that will simply add the IoT infrastructure design, deployment, and maintenance to their current activities, then the DIY approach using something like the Raspberry Pi may be the more affordable option.
Or if your need is relatively small and your whole solution has 20 or so gateways in maybe one or two relatively secure locations, even at full production then the Pi may be the right choice. In this case it may be a bit of a pain to maintain and update the devices, but the pain is relatively low because the scale is small.
At the end of the day, deciding which path to take for your IoT gateway prototype is not easy. A majority of the drawbacks with the Raspberry Pi can be mitigated by adding onto it. Yet, adding elements can add time and cost to the process. Conversely, production-ready gateways come equipped with many popular features and functions. Yet, this means that you may end up paying for features that you don’t need and/or won’t use. To effectively assess which approach is best for you, I highly recommend starting with the end goal after prototyping — scalable, cost-effective mass production — and work backward to find the right gateway solution for your needs.