EOS SCADA

The EOS SCADA solution and the software components to be used should primarily be determined according to the plant's monitoring, control, data collection, archiving, centralized data collection, and reporting requirements.

Especially in large plants containing thousands of data points, the primary role of RUNTIME should be real-time plant monitoring and control. Transferring the data archiving workload to a separate EOSfastEV or EOSvisualEV system can help provide RUNTIME with a simpler and more stable operating environment.

In addition, thanks to the built-in servers available in RUNTIME and EVENT RECORDER, EOS SCADA systems are not limited to using data only within their own environment. Collected data can be provided to other SCADA systems, control centers, data collection applications, or enterprise software through different methods such as HTML, MODBUS, OPC UA, IEC 60870, and MQTT.

EOS SCADA does not have to be used only as an independent SCADA system running on the computers of a single plant. In architectures where multiple plants are operated using their own local SCADA systems, the data collected at these plants can be consolidated in a centralized EVENT RECORDER system.

In this architecture, each plant can perform local data collection, monitoring, and archiving operations using its own RUNTIME and/or EVENT RECORDER system. The data available in the local system can then be transferred to the centralized EVENT RECORDER system through one of its built-in data servers.

This eliminates the need for the central system to connect directly to all field devices. Each plant remains responsible for its own communication infrastructure and local SCADA system, while the central system only collects, archives, compares, and presents the data provided by the plants.

This architecture can be used particularly in applications where a large number of hydroelectric power plants, solar power plants, wind farms, substations, pumping stations, or production and distribution facilities located in different geographical regions need to be monitored from a single central location.

One of the important advantages of the EOS SCADA architecture is that data serving can be performed through the built-in servers within RUNTIME and EVENT RECORDER without requiring the installation of a separate gateway software.

In this way, a local RUNTIME or EVENT RECORDER can be transformed from a system that uses collected data only within its own screens into a data source that can be accessed by centralized systems.

The following table provides a general guideline for determining which EOS software components can be used according to the plant's data volume and primary requirements.

The following table has been prepared to provide a quick overview of which EOS software components can be preferred for different plant requirements.

The following scenarios demonstrate how EOS SCADA can be configured to meet different data collection, monitoring, control, and archiving requirements within a single plant.

SCENARIO 1 — Small-Scale Plant Monitoring

Approximately 100 data points need to be monitored in real time on operator screens. There is no requirement to archive historical data.

SCENARIO 2 — Archiving a Large Number of Data Points

A plant contains thousands of data points. However, there is no need to display these data points on operator screens. The primary requirement is to continuously collect and archive the data.

SCENARIO 3 — Medium-Scale and Redundant SCADA

A plant contains approximately 1,000 data points and 100 alarms. Real-time monitoring and control, together with data and alarm archiving, are required.

SCENARIO 4 — Small Plant and Alarm Monitoring

Approximately 300 data points need to be monitored, and approximately 30 alarms need to be displayed to the operator.

SCENARIO 5 — Plant with Data and Alarm Archiving

A plant contains approximately 500 data points and 100 alarm definitions. In addition to real-time monitoring and control, historical data and alarm records need to be retained.

SCENARIO 6 — Monitoring and Archiving Thousands of Data Points

An energy or production plant contains more than 5,000 data points. Operators need to monitor key data on SCADA screens while a large volume of data needs to be archived.

SCENARIO 7 — High Data Volume and Redundant Archiving

A critical plant contains more than 10,000 data points, and continuous archiving of the data is required.

SCENARIO 8 — Medium-Scale Full SCADA System

A production plant contains approximately 2,000 data points and 500 alarm definitions. Real-time monitoring, control, alarm monitoring, data archiving, and analysis of historical records are required.

SCENARIO 9 — Alarm-Intensive Application

Although the number of data points is approximately 100, the plant contains nearly 500 alarm definitions. Storing and analyzing alarm history is important.

SCENARIO 10 — Very Large Data Collection System

In a large industrial system containing more than 50,000 data points, the primary objective is to collect and archive a large volume of data reliably.

SCENARIO 11 — Plant Requiring Long-Term Historical Data

A plant contains approximately 1,000 data points and 200 alarms. The data needs to be retained for many years, and historical performance needs to be analyzed.

SCENARIO 12 — Critical System Requiring Data Archiving Only

A system contains more than 5,000 data points and does not require operator screens. Continuous archiving of measurement values is of critical importance.

SCENARIO 13 — Large Energy Plant

A large energy plant contains more than 10,000 data points and approximately 1,000 alarms. In addition to real-time operation, highly reliable data and alarm archiving is required.

SCENARIO 14 — Small Plant with Detailed Historical Data and Reporting

A plant contains approximately 200 data points and 20 alarms. Although the data volume is low, historical data needs to be analyzed through charts and reports.

SCENARIO 15 — Production and Process Analysis

A continuously operating production plant contains approximately 3,000 data points and 300 alarms. Both operational monitoring and analysis of production performance based on historical data are required.

SCENARIO 16 — Critical Process and High Reliability

A critical process plant contains approximately 1,500 data points and 100 alarms. Both control and highly reliable data archiving are required.

An organization has multiple plants located in different geographical regions. At each plant, data is collected locally from PLCs, RTUs, energy analyzers, protection relays, or various field devices.

Each plant performs real-time monitoring and control operations using its own local RUNTIME system. It is also required to collect the local plant data at the central system and archive it for long-term storage.

In this case, the central EVENT RECORDER can be configured to receive data from the RUNTIME or EVENT RECORDER systems located at each plant instead of connecting directly to the individual field devices of each plant.

Local systems provide their data to the central system as data servers. The central EVENT RECORDER can combine and archive this data on a plant-by-plant basis.

With this architecture, a common historical database containing data from all plants can be created at the central system. Users can compare plants with each other, examine historical periods, and prepare centralized reports.

In a multi-plant system, it is not always possible for all plants to use the same communication protocol. One plant may use MODBUS, another OPC UA, another IEC 60870, while another may use MQTT-based communication.

One of the important advantages of EOS SCADA is the ability to use different data servers available within RUNTIME and EVENT RECORDER.

In this way, the local system can provide the collected data to the central system using a method compatible with the existing communication infrastructure. The central system can then collect this data through the corresponding protocol.

Thus, communication between the central system and local plants is no longer dependent on a single protocol. Each plant can connect to the central system using the communication infrastructure available at that plant.

An energy company has multiple generation plants located in different regions. Each plant is operated through its own local SCADA system. At the central location, it is desired to view the historical data of all plants from a single point.

At each plant, the RUNTIME collects data from local devices and performs real-time operation. Local data is transferred to the central system through the embedded data server of the RUNTIME or the local EVENT RECORDER.

The EVENT RECORDER located at the central system collects data received from remote plants and creates a centralized historical archive. This makes it possible for users at the central location to access the historical data of all plants.

LIVE EVENTS can be used to access the central archive. Users can examine trends, charts, alarm history, and reports for different plants through a web browser.

An important advantage of this architecture is that the central system does not have to access all field devices directly. Local SCADA systems can act as a data collection and data delivery layer between the field and the central system.

This allows the communication infrastructure to be maintained in a more controlled manner and reduces the central system's dependency on field devices.

It is not mandatory to use all software components together in every EOS SCADA project. The software components to be used can be determined according to the plant's data volume, operator monitoring requirements, control requirements, number of alarms, archiving period, centralized data collection needs, and reliability expectations.

Especially in large and distributed SCADA systems, separating the responsibilities of real-time plant operation, local data collection, centralized data collection, and high-volume data archiving can provide an important architectural advantage.

One of the important advantages of using EOS SCADA in distributed architectures is the ability to use different communication methods for data transfer between the local plant and the central system.

Thus, the EOS SCADA system can combine different communication infrastructures located at different plants into a common centralized data collection architecture.

LIVE EVENTS is not a software application that replaces real-time SCADA control. Its primary purpose is to access archives created by EVENT RECORDER and present the data and alarm information contained in these archives to users in different ways.

LIVE EVENTS can play an even more important role in centralized data collection architectures. Data transferred from multiple plants to the central EVENT RECORDER can be examined through a single web-based environment.

When determining which software components to use in a SCADA project, looking only at the number of data points is not sufficient. The purpose of the system, the distribution of the plants, and the need for centralized data should also be taken into consideration.

The EOS SCADA software family provides a scalable architecture according to the requirements of industrial plants of different sizes.

In small and medium-scale systems, the EDITOR + RUNTIME architecture may be sufficient on its own. As the number of data points and archiving requirements increase, the EVENT RECORDER component can be added to the system, allowing data and alarm archiving workloads to be separated from RUNTIME.

In multi-plant architectures, the scope of EOS SCADA becomes even broader. Each plant can collect field data through its local RUNTIME or EVENT RECORDER system and transfer this data to the central system through built-in data servers.

The EVENT RECORDER located at the central system can combine data received from different plants into a single centralized historical archive. Thus, a common central data archive can be created while the plants continue operating locally.

Different methods such as HTML, MODBUS, OPC UA, IEC 60870, and MQTT can be used for this data transfer. This allows plants with different communication infrastructures to be integrated into the same centralized SCADA and data archiving architecture.

When centrally archived data and alarm records need to be accessed through charts, lists, trends, and reports, LIVE EVENTS completes this architecture.

In critical and continuously operating plants, configuring EVENT RECORDER components redundantly can increase the reliability of both local and centralized data archiving.

You can contact us regarding software, technical content, or collaboration.

• benanbasoglu@gmail.com
• ANKARA