Have you ever felt lost in the middle of the IoT and IIoT hype train and its buzzwords? Do you have concerns about how an IIoT system will deal with your current hardware? In this article we will go through the usual system architecture for IIoT solutions. We will also describe the possible scenarios you can find on the plant floor and the alternatives to maximize your investment.
Table of Contents:
What is Iot?
The usual IIoT Architecture
Field devices and data gathering
Provisioning devices and security implications
Introduction
The Internet of Things (IoT) has become one of the hottest topics during the last few years. Although the concept of devices gathering data from multiple sources is not something new, the scale and the variety of devices that we have nowadays is without precedent. Also, the evolution of the networks (4G and 5G mobile networks), connectivity (LoRa and LoRaWan, DASH7…) and the technology (options available to implement robust IoT solutions) is allowing us to safely say that nowadays we have the required infrastructure and the required technology to implement meaningful solutions that solve really complex large-scale problems.
What is IoT?
One way of putting it is that IoT is the combination of hardware and software technologies that allows us to bridge the gap between the physical and the digital world. Once this gap is bridged, many meaningful things can be achieved to make our life easier and safer: from domotic solutions where we can monitor and perform actions in our own house using just a smartphone to complex solutions that allow us to monitor and administer the energy consumption in a supermarket. There are myriads of possible solutions and places where IoT can be helpful!
What is the main difference between IoT and IIoT?
Industrial Internet of Things, or Industrial IoT implementation, is basically the application of IoT technologies, concepts and approaches in an industrial environment. In other words, the IIoT solutions can allow us to support and improve, for instance, manufacturing processes or administer large water supply grids.
We will be focusing on the IIoT side of things, trying to provide an overview of a typical IIoT solution and their architecture, what are the components that make up these IIoT solutions and how data harvesting can be done.
The usual IIoT architecture
Let’s start with a brief introduction to the architecture of IIoT solutions. It is usually made up of four different elements: field devices, IoT Broker, back-end and the user applications.
Field devices are responsible for data harvesting and they are physically close to the industrial process, usually on the plant floor. Some of these devices maye be able to receive instructions from the system in order to modify their behaviour in a specific way. Examples of these field devices can be PLCs, sensors, actuators, specific IoT devices or any other connected hardware able to gather information.
The IoT Broker acts as a hub receiving all the information gathered by the field devices. This is one of the key pillars of any kind of IoT/IIoT solution as the performance, reliability and scalability of this component is crucial for the correct behaviour of the whole system. The reason why this component is so critical is because it may receive an overwhelming amount of information dealing with hundreds or thousands of field devices sending what they are gathering. This information should be handled in real time.
Then we have the back-end. It is loosely described in this diagram because there are a few options for the back-end implementation, depending on the complexity of the solution we are trying to apply. For now, let’s say that the back-end component is in charge of dealing with the gathered data and takes whatever action is needed in order to make sure that the business rules are applied to achieve the system’s goals.
Finally we have the applications that end-users, plant floor operators or white collar employees use to interact with the system. For example, monitoring tools to continuously keep track of the status of the industrial process, reporting tools or even an integration layer implemented by an API that allows external systems to consume part of the data being generated by the IIoT system.
Field devices and data gathering
Many times when thinking about IoT and IIoT devices, popular devices come to mind: Raspberry Pi, Arduino boards or some sensors from the other side of the world. Unfortunately, these components are not appropriate for industrial environments. Is critical to understand that not all hardware is suitable for industrial processes as it needs to operate under very special conditions: heat, humidity, dust… and during really long periods of time: 24/7. Here concepts like the Ingress Protection codes, NEMA ratings, industrial grade components etc. are really important to make sure the system has the required foundations to build something robust and resilient.
More often than not, we will need to deal with legacy infrastructure, hardware and devices. When building an IIoT system, it is usually created on the top of an existing industrial process. If a company spent 10 million dollars 7 years ago to modernize their production lines it is understandable that they still want to use that hardware, regardless of the compatibility with a fancy IIoT solution. The ability to be flexible enough to adapt our solution to these existing, and probably not-so-smart, devices will be critical for the real success of the system.
At the end, the plant floor will have a lot of these devices, smart and not-so-smart, and all of them will work in tandem to feed the IIoT system with lots of data.
IoT devices
Pure IoT devices are pieces of hardware that are able to perform a task and also have the ability to send information over the network. These devices can perform very specific tasks (like humidity sensors or mechanical actuators) or be designed to be general purpose devices, capable of achieving really complex tasks (like PLCs or micro-controllers).
In addition to the information sending capabilities, some of these pure IoT devices are capable of receiving messages from the IoT system. A PLC can receive a message from the IoT system to adjust its behaviour to, for example, slow down the conveyor belt that moves material from the warehouse to the first station in the line if the warehouse’s capacity is currently under 10%.
Not-so-smart devices
Unfortunately, not all devices in industrial processes are smart enough, at least not compared with pure IoT devices. Here we are not talking just about legacy hardware, we are talking about devices unable to perform a task and communicate with the IoT Broker.
Moreover, there is modern hardware that is not capable of sending data over a network or not able to use a data transmission protocol compatible with our IoT broker. Examples of this are many of the industrial sensors and actuators out there. This makes sense because the complexity (and price) of the component would be bigger if all of them would need to implement these networking and IoT capabilities. If IIoT is just an option, why should these components be compatible with IIoT solutions by default?
Bearing all this in mind, what are the possible solutions to overcome the situations where we don’t have smart-enough devices to achieve data gathering in the context of an IIoT system? Let’s explore a few of them.
Pure hardware solutions
One of the scenarios we have is, if our current hardware allows us, to take advantage of certain industrial specifications like the IO Link specification. This approach allows us to connect multiple IO Link devices (sensors and actuators) to a single IO Link master device. This master device can provide the networking capabilities while the sensors and actuators can provide the ability to perform the task needed.
We should explore all the possible options the existing hardware has to connect to the network and send information using the required format and protocols.
IoT Gateways based solutions
Another scenario that can be covered with modern hardware is the one where multiple devices that are not able to deal with IIoT systems can be arranged as slaves of another smart device. This smart device would be acting as an IoT Gateway and, among other actions, it will be able to interact with slaves and send/receive IoT information on their behalf. For instance, take a look at the Siemens product line of IIoT Gateways.
If for some reason the investment in additional automation hardware is not possible or existing hardware is not compatible with an out-of-the-box IoT Gateway, we always have the option to use an industrial computer with a piece of software (custom or third party) directly connecting to devices themselves using, for instance, OPC communication standards. This piece of software will be retrieving the data from the less-smart devices, do whatever is needed with it and then finally send it to the IoT Broker.
Provisioning devices and security implications
Provisioning can be considered the process of making the devices in charge of data gathering available/visible to the IIoT system. Usually this is the first step when a new device gets added to the system or an existing one reconnects after a power outage or a reboot.
Security is one of the main concerns for any existing software system. This is even more relevant for IIoT systems, where allowing unauthorized devices to send data could lead the industrial process to catastrophic scenarios for the company operating the system (DDoS attacks, information theft, sabotage…) that can compromise a lot of things, from the safety of the process itself to the reputation of the company.
For this reason, in any robust and safe IIoT system, device provisioning and security goes hand in hand. Our system should be able to ensure that just authorised devices can safely send data to the IoT Broker. If an unauthorized source is sending something, these messages are simply rejected. This provisioning approach fits with the prefered security model in IoT: Zero trust security model.
The implementation details depends on the IoT Broker component: some of them has built-in services that takes care of this secure provisioning at scale for you (for Azure IoT Hub, see Azure Device Provisioning Service) and others take advantage of other software infrastructures to offer this secure provisioning when connecting devices (for HiveMQ, see one of the options).
Don’t overlook having a secure provisioning process as it is one of the critical parts of your IIoT system!
Data Ingestion
Data ingestion in an IIoT system is the process of retrieving data generated by the field devices and then deciding what to do with it; where to send it or which component of the back-end will take care of it. This process of data distribution, within the context of IIoT solutions, is generally done by the software component called the IoT Broker.
IoT Brokers
An IoT broker is a processing engine that acts as a central hub for events and commands sent by the plant floor devices. Many IoT brokers leverage mechanisms to provide bidirectional communication: plant floor to back-end and vice versa.
Regarding the available options, we have dedicated products such as HiveMQ, Mosquitto, RabbitMQ or services offered by the main cloud providers such as Azure IoT Hub, AWS IoT Core or Google IoT Core.
Each of these options has a series of characteristics that can tip the balance for your choice: from where they run (cloud or on-premise), the available communication protocols, the ability to create a cluster of instances, the services that surround the broker, price …
As a recommendation, try to choose a broker that runs in a cloud environment as they are much more flexible when it comes to auto-scaling in order to accommodate the workload. For small, single-plant solutions any of the mentioned brokers will be able to manage it. If we talk about complex multi-plant and potentially multi-region solutions, offerings from cloud providers (Azure, AWS or Google Cloud) would be recommended because of all their surrounding infrastructure to help with the solution implementation.
If cloud solutions are not an option and something has just been implemented in-house, select a broker that can be configured in cluster mode to ensure a resilient solution with good performance.
Communication protocols
Another important choice when dealing with IIoT systems is to decide which data transmission protocol between the field devices and the IoT broker will be used. There are a lot of data transmission protocols but here we will just mention the most common ones.
MQTT. Lightweight protocol based on the publish/subscribe approach for information exchange. One of the most common protocols in IIoT as its light footprint allows it to be used with embedded systems. Designed for scenarios with limited bandwidth.
AMQP. It is a binary message-oriented protocol focused on reliability and security. It also provides transactional, routing and queuing features. It has extra focus on interoperability, which makes it shine in multi-client environments.
The choice will be restricted by the IoT Broker features. All of the most important IoT Brokers support MQTT (Azure IoT Hub, Google IoT Core, HiveMQ, Mosquitto…) and just few of them support AMQP (Azure IoT Hub, RabbitMQ). Other protocols are not having real traction at the moment in the context of available IoT brokers.
In the end, the combination of how well a protocol fits with the solution we are proposing and the compatibility with the IoT broker will define the way we exchange data from the plant floor with the IoT Broker.
Conclusion
We hope we have provided you with an interesting overview and will finish with some key take-outs:
First, the flexibility of our system’s architecture to adapt to existing plant devices and how we can deploy new ones is a critical item within our solution and its success depends in large part on it.
Security is a fundamental element of any system and, due to the number of different devices that are used in IIoT, it acquires a new dimension in these types of solutions.
Finally, the choice of the IoT Broker is also very important since its ability to ingest data and its characteristics will largely determine the realistic options we have in terms of communication protocols, scalability and related services.
Remembering these key aspects will help you follow the safe path to a successful IIoT implementation!
Author:
Javier Cervera Cano is a Senior Software Engineer with more than 13 years of experience specialized in .NET and Microsoft technologies. He has broad experience designing and building software solutions within the industrial field and worked more than 9 years with global manufacturer companies.
—
If you need help developing IoT/IIoT solution or any other software product, Zartis developers can help!
With our bespoke dedicated development team services, you can recruit world-class engineers and build high-quality software quickly, cost-effectively, and with minimal admin — all the while retaining complete control over the entire process.
Tell us about your project, or find out how the dedicated team model can level up your business. Drop us a line, we’ll be in touch shortly.
