Published on 12/27/2016 | Technology
I was recently at a Microsoft meetup where one of the attendees asked if the IoT Hub could replace SCADA. I chose to interpret the question as “could IoT in general or the Industrial Internet of Things (IIoT) replace SCADA?”. The answer of course is a definite no, but a little bit of yes, and it depends on your perspective. In reality, the concepts of IoT and MQTT are already changing SCADA and what SCADA is meant to be. Originally SCADA software was put in place to control and gather data from devices running equipment, people however often talk about SCADA as being everything from the devices back to the actual software including the network and communications infrastructure. As well, SCADA experts who have been in the field for a long time are often quick to point out that they have been dealing with “things” in the field for years and are actually the pioneers of IoT, they just never called it that.
Indeed, there are abundant examples in the SCADA world to support these claims. IoT-like solutions are being integrated into existing data acquisition architecture and logic controllers. We have seen wireless transmitters and field devices used in remote locations, and these are the things when we are talking about IIoT. The HART protocol is used for online calibration and monitoring from SCADA systems and RIOs (remote input output racks) with radio and optical links are used in current SCADA architecture. So we can already see how IIoT is already prevalent in SCADA environments and IIoT concepts are changing how we’ll look at the very idea of SCADA in the future.
But let’s break this into pieces and talk about how IIoT is influencing SCADA – which I think is a better question rather than asking if it will replace SCADA. SCADA of course, stands for Supervisory Control and Data Acquisition and is unique in that the whole job of SCADA from the software to the holistic system, is to ensure that operators and others know the state of equipment at all times, are aware of the context of the data in order to made informed and safe decisions and are always able to control 100% of the time when control is required. Some of this of course depends upon the strength of the network available to the systems as a whole. If it is a brittle network, the ability to ensure the state, context and control elements are always available is difficult. It doesn’t matter how amazing your system is if you can’t communicate to your PLCs, RTUs, transmitters and sensors. But let’s assume that the network is perfect, can the IoT Hub allow for the ability to supervise, control and acquire data? Of course it can. It was built with the intent of allowing users to gather data from devices and do powerful things with the data in a cost effective, scalable and flexible model.
So at first glance, the IoT devices and systems like the IoT Hub from Microsoft certainly seem capable of allowing operators to supervise, control and acquire data. But when you start digging you realise that while IoT Hub is an incredible concept and has a lot of the characteristics, it is missing some things.
Common Protocols – Most PLC and RTU vendors traditionally built proprietary protocols that their devices “speak”. Modbus has become a defacto standard, but there are so many variations to Modbus that even though there are similarities there are so many differences and variations of devices, that the SCADA systems had to embed drivers in the software. Without better control over standards we will struggle, but the IIoT revolution will still proceed and change SCADA.
Improved Network Performance and Options – Using MQTT Brokers as middleware that “report by exception” can improve your network performance by up to 85% typically. Having said that, if IIoT is going to replace SCADA, it isn’t just a matter of the IIoT being able to see the devices and get the data back, the data gathering services have to be able to always report on state and allow for immediate control. This requires guaranteed availability and knowledge about what is happening.
Applications – The applications within and around SCADA have to be present to that the context is always known. MQTT messaging can help with this because now for the first time ever these applications can be split out from the SCADA software completely and just be part of the publish / subscribe architecture. So a leak detection system can be changed without impacting the SCADA system. Your Measurement systems can get data directly from the devices without using SCADA. But the applications need to be somewhere or the concept falls flat. The context is also a challenge. Having context requires that displays, trends and applications are built into or integrate with the SCADA system. In a pipeline scenario, you may need a batch tracking system and you definitely need leak management capabilities. These can be built into the SCADA software, but are often built to stand beside and tightly integrate with the SCADA software. Keep in mind, some of the SCADA companies with powerful DCS software have worked for 20 years to build and acquire these applications to provide context to the data. They don’t exist, and I would argue shouldn’t exist as part of IoT.
Messaging Services Replacing SCADA as Middleware – The next logical step is to put middleware in between the SCADA software and the devices in the field. This decouples SCADA software from the devices and allows SCADA to be one of many potential subscribers to the data. You can now update your SCADA system easier and save money on innovation. You can have various systems looking at the data from the field with no impact to the primary SCADA system. You can manage tags more effectively. You can innovate quicker and easier!
Security – To me this is a bit of a red herring because I think the security of cloud services is amazing and if it is good enough for banks and health services it’s good enough for oil and gas operations. That’s my opinion, but while there will be a transition to cloud services and IIoT architectures, security should always be front and centre because of the criticality of what SCADA is operating. SCADA engineering is focussed on availability, reliability, accuracy and safety of the critical equipment which have financial and human cost. Mostly process plants are isolated from Internet for protection from cyber attacks/ hacking for safety purpose. We cannot lose sight of the importance of security as SCADA evolves but at the same time, the security challenges are not insurmountable.
So in the end, the question doesn’t matter. What really matters is that we all agree that because of the influence of IIoT and Cloud technology the concept of SCADA, data management and how people operate and manage assets are drastically changing. By the end of the next decade we won’t recognise SCADA anymore, however we will still be doing the work, gathering data and controlling the assets. The difference is we’ll be doing so within the new SCADA paradigm. But this is okay, because what we have thought of as being SCADA has always shifted and been flexible. Industrial automation has historically lagged technology innovation due to large corporations stifling innovation to extract profits. IIoT is causing a wave of new business models and technologies that are undeniably changing the landscape of SCADA. IIoT protocols like MQTT are changing how we think of SCADA as the “bottleneck” in the data flow.
My point is this; IIoT concepts and tools are extremely powerful and are influencing what SCADA is. IIoT is already part of SCADA and I believe that IIoT solutions will quickly be integrated into SCADA architecture so seamlessly that we wont even know the difference.
This article was originally posted on LogicYYC's blog.
