Internet-of-Things (IoT) usually is going about silo integration! This blog will explain what this means and how to deal with it. Including the way and how we implement this with the Azure IoT cloud.
This is the first blog in a series of blog posts explaining the complete chain of IoT using Azure IoT Reference Architecture (https://aka.ms/iotrefarchitecture). We use the Azure architecture as a reference implementation because we encounter Azure in the majority of our IoT projects. Other cloud platforms like Oracle, AWS, and IBM use similar architecture and components. In this blog, we start where the data is created: on-premise, and specifically we look at buildings and industry.
In IoT, we bridge the gap between the physical world and the enterprise IT systems to unlock the data and create real business value.
The picture below shows conceptually what we want to achieve:
In this blog we will focus on the first aspect: “Things Generate Data”.
The area we are talking about now is the Industrial Internet-of-Things (I)IoT: Connecting machines, apparatus, etc. (things) to the internet. This does not mean they are connected without any security and every hacker can directly interfere with it. No, it means that it is connected to an internet facing solution so it can communicate in a standard way with all services which are available on the internet. For example, bring it to the mobile phone or integrate it with other systems in different countries.
Traditional buildings and factories are using a huge variety of automation solutions. This is because a variety of vendors are involved. In buildings we encounter heating, ventilation and air-conditioning systems (HVAC), elevator systems, door access systems, the security control and the alarm installations. Sometimes a Building Management (aka Automation) System (BMS/BAS) is installed. This is usually, a different (Silo) system, which will bring a variety of connection protocols (like BACnet, DeviceNet, Modbus and LonWorks). See https://www.setra.com/blog/what-is-the-difference-between-bacnet-modbus-and-lonworks for a comparison of some of these protocols.
In the industrial area, we often encounter PLCs, SCADA, and HMI systems and they use effective protocols for that area like Modbus, Profinet and Fieldbus. Nowadays, most of these systems and installations are connected to the internet but make use of a vendor specific cloud solution. This is intentional because the operations and security risks of compromising the systems is unacceptable.
Some use cases in the (I)IoT are:
- Enhanced Condition Monitoring: New technologies can be applied to a better forecast when maintenance is needed.
- Enhanced Operational Monitoring: By integration of different systems a more holistic view (aka Digital Twin) on the operational status of the factory or building can be created. Better insights make it possible to quickly react to anomalies. For example, prevent unsafe and dangerous situation or operations.
- Enhanced Operational Usage: Optimize the usage of buildings, factories, production facilities and machinery. By understanding how it runs and how it is used to improve the usage. Especially to detect when it is used incorrectly.
To explain how to implement these use cases with Azure we first have a look at the Azure IoT Reference Architecture.
Here you can see again the concept of Things, Insights and Actions:
- Things generate data and things needs to be connected to the internet.
- Insights are created by processing the data, storing the data and on top of this do the (insights) reporting and dashboarding.
- This all can result in actions with are handled in the enterprise business systems.
In this blog we only focus on Things and as shown above (left in the picture) these are the IoT Edge Devices and IoT Devices:
- Sensors connected to IoT Edge Devices: These sensors needs an intermediate component (aka Edge Computing or IoT Gateway) to be able to connect to the IoT Platform. This is because of a security reason or because of the sensor itself isn’t capable of connecting to the internet properly.
- Smart Sensors (which are called IoT Devices here) who can connect securely and directly to the IoT Platform themselves. This is because they have to processing power to do this and make use of TCP/IP.
In the building and factory area the world is much more complicated than that. What we encounter in our IoT projects is that some of the building and factory systems are fully closed and self-containing. There isn’t a direct and easy way to interface with them. This makes it very difficult to unlock the data and make use of it in the enterprise IT. Technically the following solutions can be used to unlock these:
- For closed systems which make use of a proprietary protocol, we need a special adapter like an Electrical Wire Clamp T-connector. With special protocol inspection software, we can reverse engineer and find out which protocol is used and how to interpreter the data. Important is not to interfere with this data, so only read it and pass it through to the IoT platform.
- Some vendors supply systems which are open on-premise but have a vendor specific cloud solution. Most of the times this is a silo solution. To be able to use this data and combine it with other sources we need to get this data. This can be done using APIs (when available) or by downloading this data manually.
- A fully self-contained system can be connected by adding sensors to it. These sensors can be wired or usually use BLE or LoRaWAN. The data is sent to an internet security gateway which is connected wired, uses WiFi or uses mobile technology like NB IoT, 3G/4G.
- We can also gain more insight about the operational performance of fully self-contained systems by measuring the electrical high harmonics (also called harmonic voltage distortion) in the electrical power wires. We can do this with an Electrical T-Clamp, harmonics filter hardware, and special (AC/DC converter) hardware to transform this signal to digital data.
- Most vendors of closed systems nowadays also bring its own cloud solution. In that case, all the data is sent to their cloud. When this cloud doesn’t have any APIs for integration, sometimes you can make use of a manually created (CSV) data dump (if you are lucky).
- Another requirement we often see is that integration is allowed but it is only approved to do this in one direction: read and not write. When there is a risk for write or disturbance of the signal, we must go for adding our own sensors.
- In most IoT use cases, you have to deal with different protocols. A proprietary protocol needs to be translated to an industry standard protocol like TCP/IP, HTTP, REST/JSON or MQTT.
The picture below shows the different situations as explained above:
The last topic in this blog to address is the connectivity between the sensor and IoT Edge / IoT Gateway (as shown above). Sometimes sensors should be wired when the environmental conditions are bad and a lot of electromagnetic interference exists or a lot of radio signal disturbance. In that case, a shielded wire should be used. But when conditions are good than radio technology like BLE, LoRaWAN, NB IoT, LTE-M or 3G/4G/5G is preferred for flexibility. The decision which one to use is driven by a lot of factors:
- Which message throughput is needed?
- What is the maximum message length?
- How quickly do we need insights? What is the maximum allowed latency?
- How much energy is needed to broadcast the message?
- How does is the indoor condition look like (interference and signal disturbance)?
- Is outdoor coverage needed?
A good comparison between radio technologies can be found in this blog: https://www.polymorph.co.za/iot-connectivity-comparison-gsm-vs-lora-vs-sigfox-vs-nb-iot/
Remarks:
- For NB IoT or LTE-M check availability in your country.
- For LoRaWAN a public LoRaWAN network (https://www.thethingsnetwork.org/) exists but it is only available in certain countries. But as an alternative a private LoRaWAN gateway can be used which is connected to the internet (WiFi or 3G/4G).
- When a lot of sensors are applied in a dense area than you could run into bandwidth exhaustion. When this can’t be tackled you need think about using your own proprietary radio protocol.
There is much more to explain but we can’t do this here right now. In the next blog we will have an in-depth look at the IoT Edge / IoT Gateway. Also all other components for getting insights and generating actions will be addressed in blog articles after that.
This blog is brought to you by Conclusion Connect. Conclusion Connect is the IoT company of Conclusion and specialized in Industrial IoT and Smart Buildings.
For more information about our IoT services see https://www.conclusionconnect.nl/ or contact me.
