I recently went on a work trip with one of my new programmers. He peppered me with questions on the entire trip, which was great. During our days away we worked on changing IP addresses for a small network of IP based radios. We struggled HARD to get everything connected and working again with the new settings. After two days we succeeded and went home. On the way back to base, my programmer asked about IoT. What it would be useful for? Why is it important? I responded, “If clients invested in and used IoT we would not have struggle for two days with proprietary radios to make a SCADA system work. IoT is built to be plug-and-play.”
After a few years of being blasted by marketing and tech leaders posting about the power of IoT, clients and vendors are beginning to ask more frequently what is IoT, why they need IoT, and how is IoT different from the SCADA systems they have used or sold in the past. There is a large misunderstanding of what these systems are capable of and how they might be different from SCADA systems we have used to this point, and IoT is definitely different and distinct, despite the similarities to SCADA.
Really busy? See the tl;dr at the bottom of the post.
SCADA stands for Supervisory Control and Data Acquisition. It is a set of technologies that the oil and gas industry has been using for decades. The core functionality is built on simple remote automated systems that allow for programmed control and remote monitoring. Remote sites are programmed to provide automatic controls to keep operations stable and safe. A high pressure may cause a well valve to shut off. A high level may start a pump to empty a tank. Remote monitoring was usually built through proprietary private data radio connected directly to a client’s control network, or to the SCADA host server.
In these systems a SCADA host server will ‘call up’ a remote site over the radio with a message and ask, “What values are in your memory?” The remote site will respond, providing all the numbers requested, usually in a raw list with little or no context. The remote device does not know about the SCADA server outside of hearing the message and knowing it should respond when spoken to. The SCADA host is programmed to know what context the data has. This might be the order the numbers come in and what they represent. Any collected data is stored on the SCADA host and displayed to operators who may make real time decisions based on the status of that remote equipment. If a business system also needs that data then a custom program or data transfer moves the data out from the SCADA host to the next system. These data transfer methods are often fragile and break when networks or systems change when they are upgraded. If the SCADA host cannot provide the data to the business system in the correct format then that business system may reach out through the network to the remote site directly to obtain data, resulting in multiple connections out to site.
In short SCADA is about basic connectivity and real time status. It takes a good number of manual programming hours to configure correctly and add context to the data. SCADA systems are often plagued with proprietary protocols with weird edge cases (this version works, but that version doesn’t) and fragile data transfer methods. The value SCADA provides is in the remote monitoring and dashboard display of data. This reduces operator work load (fewer site trips) and generally makes client operations more efficient.
IoT is Internet of Things, sometimes noted as the Industrial Internet of Things (IIoT). It is a collection of technologies that are relatively new. The remote device will still have local programming to keep its operation safe and automatic. However, here is where the differences start. The remote device will be programmed to know about and make a connection to a remote server, usually with a security certificate. The certificate allows the remote server can verify the identity of the device. The remote device will be programmed to monitor its sensors and status and will transmit updates to the server when values or states change, or on an interval (most devices can be programmed for both). The data will be published to the server with context. Information about what the values represent, the time the value changed, the units of measure, the sensor serial number, sensor location or health may all be transferred or published to the server, depending on the programming. The remote device will also subscribe to any control messages the server may record. This is how controls are sent back to the remote device. The two major differences in IoT are that the data is published (not polled) and that data is sent with context.
The IoT server does not have to be programmed about the data context either. IoT servers are generally quite simple and accept publish messages and then send out updates to connected subscribers when new data comes in. In IoT if a business data system needs access to field data it simply subscribes to the IoT server and begins consuming the data published from the field. The complexity of moving data between systems is now far more robust because it relies on the business system software to interpret the data from the field using the context provided.
Now the true power of IoT comes from what is possible once you are into the publish/subscribe technology and the complexity of programming all the data transfer is no longer there. Data analytics and machine learning platforms are available that can plug-in to IoT servers and they can be setup to solve business problems on the fly as new data is published. Other business systems simply connect and subscribe. No more messy programming. Data movement tasks can be very complicated to do with traditional SCADA software, and the specific systems knowledge in industry is getting less and less as these SCADA systems age, the software becomes obsolete and wise SCADA programmers retire.
I am looking forward to working more with IoT technology and looking forward to working with the sharp young people we have on the team who are interested in learning and creating solutions with the new ideas coming down the technology pipeline.
- Relies on poll/response type communications initiated by the SCADA server.
- Provides connectivity.
- Focus is on real time status.
- Data usually comes across without context.
- Data path is often proprietary radio or hard wired systems.
- Data often moves to a proprietary SCADA server first and is then exported or moved manually or with custom programming from there to other systems.
- Data analytics happens outside SCADA platforms.
- Security is often non-existent or is available through obscurity or air gaps. Devices do not check identity of SCADA servers, and respond to anyone when requested to. Some network security is provided with firewalls, but it is still really easy for bad actors to penetrate and perform man in the middle attacks on these legacy systems.
- Remote device sends and asks for data from the IoT Server using a publish/subscribe method.
- Connectivity is provided by common network hardware.
- Focus is on using data to solve problems, rather than simply provide status.
- Data comes with context.
- Data path is often simple and non-proprietary.
- IoT Hubs/Servers are built to transmit data instantly to subscribers when it arrives from publishers. No need for manual exports or custom programming.
- Data analytics tools can plug directly into IoT hubs.
- Security is provided with certificates for identity and traditional IT network security (firewalls, etc.)