Modern SCADA systems can span across large geographical locations and provide operators a complete overview of their processes, as well as remote control of equipment, advanced alarming, and powerful data processing capabilities. However, when SCADA was first conceptualized in the late 1950s, many of these functions were not possible or were very limited. In fact, looking back at the brief history of SCADA systems, it took multiple generations of development before we achieved the level of connectivity and functionality that today’s systems provide.

Monolithic Systems: First Generation

The first SCADA concepts were based on mainframe systems, which had little to no networking capabilities. Because of their limited networking capabilities, the first generation of SCADA systems were unable to interconnect with each other making them standalone systems.

Despite their lack of interconnectivity, the first generation of SCADA system could still create a wide area network (WAN). However, at the time, the only function of these wide area networks was to connect to different remote terminal units (RTU) to communicate data back and forth from the master computer.

To communicate with the RTUs, the first generation of SCADA systems only used proprietary protocols developed by RTU vendors that were only compatible with master computers from the same vendor. Additionally, these protocols only provided the ability to scan, control, and exchange data between the master computer and the RTUs sensors and inputs in the field.

These first SCADA systems quickly became in high demand from manufacturers across industries. However, as SCADA became more widely adopted, manufacturers began to pressure the RTU vendors to improve the system’s communication protocols. This push for improvements led to the first evolution of SCADA and ushered in the second generation of systems.

Distributed SCADA: Second Generation

With manufacturers pushing for improvements, the second generation of SCADA arrived, bringing system miniaturization and local area network (LAN) technology.

Termed distributed SCADA, the improved systems were now able to communicate with each other allowing for multiple stations that could exchange data in real-time. The systems also became smaller in size and were less expensive than the first generation of SCADA.

The second generation of SCADA also brought the first instances of common system components, which included communication processors, human-machine interfaces (HMI), RTUs, and databases.

While Distributed SCADA systems were smaller, less expensive, and more connected, the second generation was still limited to only being compatible with hardware, software, and peripheral devices provided by the vendor.

Networked SCADA: Third Generation

The third and current generation of SCADA was brought on by advances in industrial automation, and the vendor’s willingness to understand and adapt to the needs of the market.

Now dubbed networked SCADA, the third generation finally breaks away from relying on the vendor’s proprietary components and introduces an open system architecture. This open architecture allows for the use of open communication protocols and standards, which enables SCADA functionality to be distributed in WANs versus only being able to use closed LANs. Additionally, an open architecture also allowed for the use of third-party peripherals, which unlocked even greater functionality over the previous generation of SCADA systems.

With the ability to use WANs for more than just connecting to different RTUs to exchange data, the third generation of SCADA introduced WAN protocols, such as Internet Protocol (IP). This was a groundbreaking development, as it enabled all components of a SCADA system to communicate with each other through an ethernet connection.

Standardization and OPC Foundation

With SCADA now an open architecture system utilizing open communication protocols, a series of standards were formed to simplify system development and create consistency. In 1996, object linking and embedding for process control (OLE for Process Control) was established by the OPC Foundation to develop standards for open connectivity of industrial automation devices and systems. Eventually, OLE for Process Control was changed to open platform for communication (OPC) as the standards were adopted for other applications outside the scope of process control.

About Process Solutions

Located near Seattle, Washington, Process Solutions has over 30 years of experience providing high-quality control systems. With over 100 engineers and technicians on staff and an output of over 3,000 industrial control panels per year, Process Solutions is the Northwest’s largest control systems integrator. In addition to custom motor control panels, Process Solutions’ control systems services include PLC and HMI programming, robot system integration, energy management, and industrial refrigeration control systems, SCADA integration, and DAQuery machine monitoring software.