In industrial automation, when various devices need to be used, it is necessary to understand the architecture designed in them. Devices communicate with each other in various ways - through hardware or communications to share data between the field and the control room. Which link goes into which connection is necessary to define and resolve, once we understand the architecture then we can easily work in the system.
SCADA system architecture
When designing a SCADA system, it is crucial to understand its architecture as it is one of the fundamental building blocks of automation. SCADA applications typically run on servers. Clients such as desktop computers and screens can act as HMIs by connecting them to the server.
Since operating devices such as PLCs and RTUs are also connected to the server, SCADA clients can be used to control and monitor operations. In this article, we will learn about several types of SCADA system architectures such as monolithic, distributed and networked.
Monolithic SCADA Architecture
Monolithic SCADA architecture is the first and most basic type of architecture used in SCADA systems. See the image below to understand.
A monolithic SCADA architecture consists of a single SCADA system communicating with an RTU (Remote Terminal Unit).
RTU is also a kind of PLC, but it does not have its own display and mainly communicates through wireless protocols. In addition, it is used in environmentally hazardous and inaccessible areas of factories.
When SCADA systems were first developed, the concept of computing was usually centered on mainframe systems. Networks usually don't exist, and each centralized system is isolated. Therefore, SCADA systems are self-contained systems with few connections to other systems.
Wide Area Networks (WANs) implemented to communicate with Remote Terminal Units (RTUs) are designed for one purpose only: to communicate with the RTUs in the field. Furthermore, the WAN protocols in use today were largely unknown at the time.
The communication protocols used in SCADA networks are developed by RTU equipment suppliers and are usually proprietary. Furthermore, these protocols are often very limited and do not allow almost any functionality beyond the required scanning and control points within the remote device. In general, it is not feasible to mix other types of data traffic with RTU communication in the network. The connection to the SCADA master is limited by the system provider. The connection to the master is usually at the bus level via a proprietary adapter or controller connected to the central processing unit (CPU) backplane.
Distributed SCADA architecture
Second-generation SCADA systems take advantage of system miniaturization and the development and improvement of local area network (LAN) technology to distribute processing among multiple systems. Multiple sites, each with a specific function, connect to the LAN and share information in real time.
These workstations are usually of the microcomputer class, smaller and less expensive than first-generation processors. Some of these distributed stations are used as communication processors, mainly communicating with field devices such as RTUs. Some are used as operator interfaces, providing a human-machine interface (HMI) to system operators. Others serve as computing processors or database servers. The distribution of the individual functions of the SCADA system across multiple systems provides the entire system with more processing power than a single processor. The networks connecting these individual systems are usually based on LAN protocols and cannot exceed the constraints of the local environment.
Some of the LAN protocols used are proprietary in nature, where providers create their own network protocols, or versions thereof, rather than extract existing ones from them. This allows providers to optimize their LAN protocols for real-time traffic, but limits (or effectively eliminates) other providers' network connections to the SCADA LAN. This diagram shows a typical second generation SCADA architecture.
Distributing the functions of the system through the system connected to the network not only helps to increase the processing power, but also improves the redundancy and reliability of the overall system. Unlike the simple active/standby switching scheme used in many first-generation systems, distributed architectures typically keep all sites on the LAN online at all times. For example, if one HMI station fails, another HMI station can be used to operate the system without waiting for a failover from the primary to the secondary system. The WAN used to communicate with field devices has not been significantly modified by the development of LAN connections between local stations in SCADA master stations. These external communication networks are still limited to the RTU protocol and are not available for other types of network traffic.
Networked SCADA Architecture
The architecture of the current generation of SCADA masters is closely related to that of the second generation, with the main difference being an open system architecture rather than a vendor-controlled proprietary environment. There are still several networked systems, which share the master station function. There are still RTUs using protocols owned by providers. The main improvement of the third generation is the architecture of open systems, using standards and open protocols, and enabling the distribution of SCADA functions over WANs rather than just LANs.
Open standards remove a number of limitations from previous generations of SCADA systems. Using the ready-to-use system allows users to easily connect third-party peripherals (such as monitors, printers, disk drives, tape drives, etc.) to the system or network. SCADA providers gradually got out of the hardware development business as they moved to "open" or "commercial" systems. These providers have turned to systems providers such as Compaq, Hewlett-Packard and Sun Microsystems because of their experience in developing basic computing platforms and operating system software. This allows SCADA vendors to focus their development on one area where they can add specific value to the system: the software for the SCADA master.
A major improvement in third-generation SCADA systems comes from the use of WAN protocols such as Internet Protocol (IP) for communication between master stations and communicating devices. This allows the part of the master station responsible for communicating with field devices to be "properly" separated from the master station over the WAN. Vendors are now producing RTUs that can communicate with masters over Ethernet connections. The diagram represents a SCADA network system.
Another advantage that comes with distributing SCADA functions over a WAN is disaster survivability. In second-generation systems, the distribution of SCADA processing over the LAN improves reliability, but if the facility housing the SCADA master is completely lost, the entire system may be lost as well. By distributing processing across physically separate locations, it is possible to build a SCADA system that can survive the complete loss of any one location. For some organizations that view SCADA as an ultra-critical function, this is a real benefit.
In this way, SCADA systems located in some remote areas of other countries can also access the system and communicate data with it. This means that SCADA systems can now be used not only in a single plant, but across multiple plants that are physically far apart.
SCADA development tools
In industrial settings, SCADA systems are critical as they help increase productivity, analyze data for smarter decisions, and communicate system issues to help reduce downtime. Simply drag and drop graphics in the Sovit2D development platform to easily design, implement and modify. Using Sovit2D software to design SCADA can save two-thirds of development and modification time. Sovit2D complies with HTML5 standard, based on B/S architecture, no need to install client, supports 2D and 3D screen configuration, easily realizes 3D visualization function and digital twin, supports local/cloud deployment, and can be easily integrated with user-owned systems application platform. It enables users to complete the final automation control project according to any configuration of their own control objects and control purposes.
