SCADA systems are becoming smarter and more interconnected and transforming the plant floor and in how they're being utilized. Learn more from a thought leader on his personal experience on how he’s successfully utilized them.
Thoughts on the present and future of supervisory control and data acquisition (SCADA) systems and how they benefit controls engineers and system integrators are provided by:
John Kan, connectivity products manager, Motion Ai, Charlotte, N.C.
Question: How did SCADA systems evolve from their early beginnings to the sophisticated systems we have today?
Kan: SCADA systems can trace their origins to the earliest human-machine interface (HMI) on the factory floor in the early 1970s. Distributed control systems (DCS) started to have displays during that time. The first SCADA systems ran under DOS (disk operating system) and were a central gathering place to show a broad overview of what many programmable logic controllers (PLCs) could provide. However, demand quickly grew for sophisticated communication to other databases and better graphics. Critical for today’s implementations is that SCADA is one of the dominant ways to push large data amounts in databases and historians, which reside on-premises and in the cloud.
Question: Can you highlight some key milestones in the development of SCADA technology over the years?
Kan: The acceptance of industrial Ethernet networking enabled SCADA programs to have a larger reach than ever, because they were no longer limited by serial communications or some of the common bus networks of the 1990s. Computers became more powerful, so more processing could be done, and many scripting languages started to appear—such as VBScript. As networking became more ubiquitous, web clients standardized their systems, and many SCADA packages have built-in local web servers vs. proprietary clients. And with cloud applications, it is common to integrate with Microsoft Azure and AWS (Amazon Web Services). This is relevant, as transferring large data into these platforms cost-effectively is now feasible.
Question: Can you discuss some industry-specific challenges that SCADA systems have helped address or mitigate over the years?
Kan: Without the evolution of SCADA, the concepts and processes for updating cloud applications and web-based dashboards would likely be much more fragmented. The systems brought a common “semantic standard” to industry. For example, trending means to take a value and show it in either a graphical format on a display or log the data historically on media. Because of the relatively high computing power required by a SCADA program’s different functions on early computers, developers had to innovate and distribute functionality for trending, alarming, data collection, communicating with various PLCs, etc. The whole point of distributing this data is to allow connectivity to software and cloud-based applications that specialize in analyzing data for predictive maintenance—a critical component of overall asset management.
Question: How can the industry address the growing need for interoperability between different SCADA systems and devices?
Kan: Education on understanding communication standards is critical. Most SCADA systems support Open Platform Communications Unified Architecture (OPC UA). Client functionality is a given, but server functionality is becoming important as other clients require the data from the SCADA package. Some major programs that use OPC UA are Wonderware, VTScada, Ignition, Iconics, and Siemens TIA Portal. Message queuing telemetry transport (MQTT) is used more frequently for communications, especially in the IoT world.
SCADA systems become smarter, connected to IIoT
Question: What are the major barriers to the continuing expansion of IIoT technology in relation to SCADA systems?
Kan: One of the biggest barriers is philosophical, as pilot IoT systems are often deployed in small pilot tests to verify proof of concept. Also, many IoT systems have cellular capabilities, which are convenient but sometimes difficult to provide to large organizations with many different kinds of automation “islands.” Standards of communication between IoT platforms and SCADA packages are evolving. Protocols like OPC UA and MQTT are becoming established interoperability standards. In addition, many groups, such as PLC programmers, automation engineers, programmers, IT personnel and cloud specialists, must collaborate for successful implementation.
Question: For end-users looking to implement more IIoT technology into their SCADA systems, can it be done incrementally, or is wholesale replacement of systems and/or equipment required?
Kan: IoT systems are excellent examples of how to deploy systems incrementally. Wholesale replacement is not required. There are two schools of thought on this: 1) an all-inclusive system from the sensor or PLC to a dashboard from one manufacturer or 2) a core system such as an IoT gateway that can be easily mixed and matched with other pieces of the data transfer. The “best-in-class solution” gives an IoT provider much more flexibility to meet a customer’s needs. Also, solutions with many interchangeable parts will automatically involve the customer in understanding the scope of the problem they are trying to solve.
Question: What other considerations come into play when integrating more IIoT technology into a SCADA system?
Kan: Something often overlooked is that a data collection system connected to a SCADA system is only as good as the network it runs on. Many locations that want to update their visibility to the process are trying to do it with outdated Ethernet networks. Network segmentation using VLANs or Layer 3 devices that implement NAT technology (network address translation) are often just as important as the gateway and sensors. As more asset management and predictive maintenance software and cloud-based applications require large data amounts, the ability to deliver that data cannot be ignored.
Question: What changes in skillsets and workforce training will be required to keep pace with this advancing technology?
Kan: The traditional separation of mechanically oriented engineers, electrical controls engineers and IT personnel has always been a challenge to overcome. Many colleges and universities are offering more blended “mechatronics” types of programs, which teach from the start that mechanical, electrical and IT are all connected in today’s modern manufacturing environment. Companies need to spend much more time teaching their employees to think in terms of “systems” rather than individual pieces. Finally, industrial distribution needs to transform from part-sellers to problem-solvers as partners listening to customers’ needs.
HMIs and SCADA systems on the factory floor
Question: Can you explain the role of HMIs in SCADA systems and how they contribute to the overall functionality and usability?
Kan: HMIs and SCADA systems are not mutually exclusive on a factory floor. HMIs are often seen as a pushbutton and light replacement or a supplement to an existing system. One HMI can be connected to a group of machines and components in a cell. Often, on an HMI, special maintenance screens for qualified personnel help troubleshoot a machine. SCADA software often connects various HMIs in a central point with other devices. While HMI panels exist on the factory floor, a SCADA installation is often centrally located in a factory—even in a designated office. However, the line between them becomes less distinct as many HMI panels have features previously regulated by SCADA software.
Question: What are the key considerations when designing and implementing SCADA systems with HMIs for different industries?
Kan: A key consideration for HMI is physical mounting. HMIs are typically mounted in a panel through a cutout. VESA mounts are used often, especially with newer HMIs that are web clients and mounted on a wall. Arm mounts are used to position HMIs freely on the factory floor. Another consideration is the environment. For example, IP69K-rated HMIs are critical in washdown situations in food and beverage, chemical processing, etc. For panels mounted outside, NEMA 4X is important in high-sunlight areas. SCADA is usually run on a computer in a controlled environment. Most important is to ensure that their computer has enough processing power and RAM to run the application.
Question: How do SCADA systems and HMIs contribute to predictive maintenance strategies, and what technologies are employed to optimize equipment reliability and minimize downtime?
Kan: A well-thought predictive maintenance scenario considers what is connected to the HMI or SCADA. There are certain places where PLCs should pre-process data before sending it to a SCADA system or IoT application. For example, if you have a large machine with hydraulic cylinders and want to measure and compare travel time with a baseline, the best place to do it is within the PLC logic. One should avoid sending information higher than what is better dealt with locally (at the PLC or HMI level). Another example is in measuring the pH value of a wastewater lagoon. It is important to check regularly, but checking every second and storing a great deal of data in a cloud database wastes time, energy and resources.
Question: What challenges do you commonly encounter when integrating SCADA systems with HMIs, and how do you address these challenges?
Kan: HMIs and SCADA systems are often in different sections of an enterprise. A major challenge is the infrastructure or lack of it at a location. Sometimes, Ethernet connectivity is the first thing that has to happen. In a plant, 802.11 wireless networks are tightly controlled and are not easily added to. On the compatibility side, different groups are often responsible for development with HMI and SCADA, so standards should be set. Sometimes, OEMs provide a machine with an HMI but “lock access” so that no changes can be made.
Question: What advancements have been made in the field of SCADA systems and HMIs, and how do these innovations enhance their capabilities and efficiency?
Kan: A SCADA system’s major functions are to gather, display and distribute. Gathering includes acquiring data from different PLCs and other devices. Certain protocols have emerged as a common way to get data from devices and communicate with other entities. These include Ethernet/IP, Modbus TCP/IP, Profinet, etc. Being an OPC UA client allows SCADA packages to talk to many third-party devices. Display options are expanding because of newer standardized web client technology. Processing power has allowed many HMIs to use virtual network computing (VNC) technology. Communication with other software entities via MQTT protocol, application programming interfaces (APIs) or software development kits (SDKs) grows continuously. Also, access to other databases using SQL is constant.
Again, with the advent of connection technology standards, the ability to transport large data amounts for predictive maintenance and asset management is a common ability that all of the major SCADA systems provide.
