If you are reading this post, you will most likely know what SCADA systems are. But in case you don’t, SCADA is an acronym for Supervisory Control and Data Acquisition. SCADA systems refer to control system architectures for high-level supervision of machine processes. These architectures combine hardware (edge devices, like sensors and control valves, programmable logic controllers and remote terminal units) with software (for the human-machine interface and for monitoring) to receive data from processes that the operators can use in order to optimize them.
SCADA systems can be spread over a wide geographical area, but they can also reside in just one physical location.
The adoption of SCADA systems has been particularly strong in utility companies, especially in the delivery of water, electricity and natural gas.
The challenges with SCADA
SCADA systems tend to be heterogeneous, because there are several generations of devices and they tend to be mixed within the systems. Companies are normally not interested in modernizing the devices; they want to keep them as they are whenever possible. But to do so, they need to make sure that devices from different generations can communicate properly with each other. For utility companies in particular, one of their biggest needs is to improve their outage management system (OMS) and distribution management system (DMS) without changing their SCADA systems.
As mentioned before, in many cases, the systems are distributed across wide areas. Therefore, accessing them across their different networks—and more importantly—in a more secure way (from both data security and reliability perspectives) can be a difficult task.
Another challenge is that consumption models are evolving quickly. So the way companies capture analytic data about that consumption must also evolve if they want to stay competitive and offer the best choices to their customers.
Reasons for modernization
There are two main reasons why companies need to modernize the way they interface with and use their SCADA systems. One is linked to customer satisfaction, the other to regulators.
Devices and concepts like smart meters, intelligent consumption and intelligent homes call for new ways of accessing data for accurate billing forecasting and consumption planning. At the same time, companies need to offer new features that interest customers while getting ready for new technological needs, such as enabling charging electric cars at scale. Outage detection and preventive management also have a direct impact on customer satisfaction; being able to use AIOps along with self-healing architectures is imperative.
The other driver for modernization comes from compliance and regulations. In North America, for example, there is the NERC (North American Electric Reliability Corporation), whose jurisdiction includes owners, operators and users of the bulk power system. It is overseen by the FERC (Federal Energy Regulatory Commission), which also regulates natural gas and hydropower projects. All utility companies in North America need to be compliant with the regulations that these two organizations publish. Flexibility is a must in order to adopt new regulations quickly.
A modern API integration platform
The most flexible and efficient way to modernize the interfaces with SCADA systems is to use an API-first approach with an architecture like the one shown in Figure 1.
![Figure 1. SCADA API platform Figure 1. SCADA API platform](/rhdc/managed-files/styles/wysiwyg_full_width/private/modernizing-scada-interfaces-img1.png.webp?itok=2xUuPRoB)
Figure 1. SCADA API platform
We can see that there are two clearly separated network zones: where the SCADA systems are (electric zone) and where the business applications are (enterprise zone). There can be other zones as well, but we’ll just use these for now. This separation is dictated by the NERC regulations that say that the SCADA systems have to be in their own isolated network.
The main idea is to have one container platform in the same network as the SCADA systems, where the applications that get data directly from the SCADA devices run, and another container platform in the other network zone, where the applications that need to consume the data from the devices (for analytics, etc.) reside.
Of course, there needs to be communication between the applications running on the different container platforms in the separate networks. For that, a messaging system is needed.
In the solution that we suggest, the container platform will be Red Hat OpenShift and the messaging system will be based on Red Hat AMQ, provided with Red Hat Integration. The APIs to call the different functions of the SCADA devices and of the customer applications will be implemented with Red Hat Fuse and managed with Red Hat 3Scale API Management (both also included in Red Hat Integration). The latter will be used for the creation of a control point that acts as a gateway between the different network zones.
![Figure 2. Connection between network zones Figure 2. Connection between network zones](/rhdc/managed-files/styles/wysiwyg_full_width/private/modernizing-scada-interfaces-img2.png.webp?itok=C8Kc1gJn)
Figure 2. Connection between network zones
![Figure 3. Detail of the electric zone Figure 3. Detail of the electric zone](/rhdc/managed-files/styles/wysiwyg_full_width/private/modernizing-scada-interfaces-img3.png.webp?itok=VBK4eEC2)
Figure 3. Detail of the electric zone
Because of the NERC regulations, there can be no inbound traffic to the electric zone, so all the information flows will originate there. The message queues will be replicated in both zones, and the applications in the electric zone will use APIs to request the business applications in the enterprise zone to provide the data needed for the requests. Once they receive it in the electric zone queue, they will forward the request to the SCADA devices and write the responses back to this message queue. This way, the messages are replicated in the other queue and consumed by the business applications.
![Figure 4. Information flow Figure 4. Information flow](/rhdc/managed-files/styles/wysiwyg_full_width/private/modernizing-scada-interfaces-img4.png.webp?itok=th4ppSoy)
Figure 4. Information flow
In Figure 4, we can see the aforementioned information flow. Also note that each Red Hat OpenShift cluster has its own control plane.
Red Hat SSO (included in Red Hat Runtimes) is another key component of the solution as it will be used by the applications to access the AMQ message queues. Finally, the platform is rounded off with Red Hat Ansible Automation Platform, which will be used to enforce the compliance of the cluster with the policies derived from the regulations. It will create and validate cluster configurations; it will also be used to automatically resolve issues detected by the control plane.
Summary
SCADA systems are a key source of information for companies. In the utilities sector, they allow for much better analytics and predictions that improve customer satisfaction. They also help companies deliver a better service with fewer outages and faster remediation.
The systems are heterogeneous and tend to be spread across very wide areas, which is why they need a more reliable and seamless way to communicate. The communication system has to be compliant with all the strict regulations that exist in different countries, and be flexible enough to incorporate new regulations quickly.
Modernizing the access to SCADA systems unlocks the full potential for innovation while abstracting low-level complex details, so developers of new applications do not need to worry about them. This makes it easier to incorporate artificial intelligence/machine learning (AI/ML) workflows, for example. This, in turn, can lead to improved maintenance and network stability, simplified creation of applications that let users monitor and manage their consumption, or better demand forecasting and investment planning—which can lead to more efficient buying and selling of capacity.
If you are interested in more solutions built with these and other Red Hat products, visit the Portfolio Architecture Center.
Über den Autor
Ricardo Garcia Cavero joined Red Hat in October 2019 as a Senior Architect focused on SAP. In this role, he developed solutions with Red Hat's portfolio to help customers in their SAP journey. Cavero now works for as a Principal Portfolio Architect for the Portfolio Architecture team.
Nach Thema durchsuchen
Automatisierung
Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen
Künstliche Intelligenz
Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen
Open Hybrid Cloud
Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.
Sicherheit
Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren
Edge Computing
Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen
Infrastruktur
Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen
Anwendungen
Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen
Original Shows
Interessantes von den Experten, die die Technologien in Unternehmen mitgestalten
Produkte
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud-Services
- Alle Produkte anzeigen
Tools
- Training & Zertifizierung
- Eigenes Konto
- Kundensupport
- Für Entwickler
- Partner finden
- Red Hat Ecosystem Catalog
- Mehrwert von Red Hat berechnen
- Dokumentation
Testen, kaufen und verkaufen
Kommunizieren
Über Red Hat
Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.
Wählen Sie eine Sprache
Red Hat legal and privacy links
- Über Red Hat
- Jobs bei Red Hat
- Veranstaltungen
- Standorte
- Red Hat kontaktieren
- Red Hat Blog
- Diversität, Gleichberechtigung und Inklusion
- Cool Stuff Store
- Red Hat Summit