Performance, scalability, and sustainability in SCADA systems depend not only on the
hardware used, but also directly on how system functions are distributed
across the architecture. Increasing data volumes, alarm rates, user numbers,
and integration requirements can create significant performance bottlenecks in
monolithic structures where all functions are executed within a single software process.
The evolution of the EOS SCADA architecture demonstrates how these requirements have been
addressed progressively. The architecture evolved from a first-generation monolithic
structure to the second-generation SCADA RUNTIME + EVENT RECORDER model,
and then to a third-generation architecture with further task separation through
FAST EVENT RECORDER + LIVE EVENTS + LIVE DASH.
Why Does SCADA Architecture Evolve?
As a SCADA system grows, not only does the number of tags increase; data acquisition
frequency, alarm generation rate, historical data queries, user interactions, and data
exchange with external systems also increase. Concentrating these operations within the same
process means that changes in the performance of one component can directly affect other functions.
Core architectural approach: Because real-time control and operator
interaction are critical, moving resource-intensive operations such as archiving,
historical data visualization, alarm analysis, and reporting to separate components over
time makes the system more stable, scalable, and manageable.
Therefore, architectural evolution does not simply mean adding new software. The real
improvement is focusing each software component on a specific task and
distributing the workload between components in a balanced manner.
1. First-Generation Architecture – 2023 Release
In the first-generation architecture, the core functions of the SCADA system were
concentrated in a single software component, SCADA RUNTIME. While this
approach provides a simple operating model for small and medium-scale applications, as the
system grows, different workloads may compete for resources within the same process.
Main tasks performed by SCADA RUNTIME:
- Reading process data from devices and performing data acquisition.
- Displaying acquired data in real time on operator screens.
- Executing plant control and command operations.
- Archiving process data.
- Generating, managing, and displaying alarms.
- Providing data to other systems through MODBUS, OPC, and similar interfaces.
- Visualizing historical data.
- Listing and reviewing historical alarms.
1.1. Performance Limits of the Monolithic Structure
Executing all tasks within a single software process can simultaneously place significant
pressure on CPU, memory, and disk I/O resources, particularly in projects containing large
numbers of tags, operating at high data frequencies, or performing intensive historical data queries.
- Slowdown of operator screens during historical archive queries involving thousands of data points.
- Archiving operations affecting real-time visualization performance.
- Heavy alarm traffic sharing the same resources with control and user-interface operations.
- Resource consumption in one component directly affecting other SCADA functions.
Architectural limitation: The fundamental problem of the monolithic
structure is not that any individual function is inherently inadequate; rather, real-time,
archiving, alarm, and analytical workloads with different characteristics are concentrated
within the same runtime environment.
2. Second-Generation Architecture – SCADA RUNTIME + EVENT RECORDER
To reduce the performance bottlenecks observed in the first-generation structure, the
second generation adopted a workload separation approach. At this stage,
data acquisition and archiving tasks were separated from SCADA RUNTIME and transferred to
the EVENT RECORDER component.
| Component |
Main Tasks |
Architectural Role |
| SCADA RUNTIME |
Real-time data visualization, operator interfaces, and plant control operations. |
Operations and control layer. |
| EVENT RECORDER |
Data acquisition, archiving, alarm derivation, alarm archiving, and data delivery through interfaces such as MODBUS/OPC. |
Data acquisition and recording layer. |
This separation of responsibilities was intended to reduce CPU and I/O load on SCADA RUNTIME,
provide smoother operator screens, and allow data acquisition and archiving processes to run
more reliably.
2.1. Redundant Operation Capability
Another important benefit of the second-generation architecture is the ability to establish
redundant operating scenarios with appropriate configuration. An EVENT RECORDER can read data
from devices and transmit the same data both to SCADA RUNTIME and to a
redundant EVENT RECORDER. This supports continuity at the data acquisition
and recording layer.
Purpose of the redundancy approach: To keep an alternative operating path
available for data acquisition and system continuity if a single recording component becomes unavailable.
3. Third-Generation Architecture – Advanced Task Separation
Although the second-generation architecture separated data acquisition and archiving load
through EVENT RECORDER, intensive historical data visualization, alarm analysis, and reporting
could eventually place additional demands on the resources of this component.
The fundamental approach of the third generation is to take task separation one step further.
For this purpose, new software components such as LIVE EVENTS and
LIVE DASH were introduced, separating historical data access, event review,
and web-based analytical operations from the data acquisition layer.
Core components of the third-generation architecture:
- SCADA RUNTIME: Real-time data visualization and operator control.
- FAST EVENT RECORDER: Data acquisition, archiving, alarm derivation, alarm archiving, and data delivery to external systems.
- LIVE EVENTS: Historical data visualization and historical alarm listing.
- LIVE DASH: Web-based data analytics, trend analysis, reporting, and performance evaluation.
3.1. Task Distribution and Workload
| Layer |
Task |
Priority |
| SCADA RUNTIME |
Real-time monitoring, operator screens, and plant control. |
Low latency and continuous availability. |
| FAST EVENT RECORDER |
Data acquisition, archiving, alarm generation, and data delivery. |
High data continuity and recording reliability. |
| LIVE EVENTS |
Historical data and alarm review. |
Operational review and event analysis. |
| LIVE DASH |
Web-based analytics, trends, reporting, and performance evaluation. |
Analytical access and decision support. |
4. Benefits of the Third-Generation Architecture
The objective of the third-generation architecture is not only to solve existing performance
problems. It is also to make the system more adaptable to future increases in tag count, data
volume, user numbers, and integration requirements.
- Preservation of real-time performance: Operator screens and control operations are more effectively separated from historical data and analytical workloads.
- Distributed resource utilization: CPU, memory, and disk I/O requirements can be distributed across different software components and, when necessary, different computers.
- Scalability: As the system grows, the required component can be scaled or optimized instead of redesigning the entire architecture.
- Operational awareness: LIVE EVENTS and LIVE DASH make historical events, trends, and performance indicators more suitable for operational assessment.
- Independent optimization: Data acquisition, real-time visualization, and analytical functions can each be optimized according to their own workloads.
- System continuity: The resilience of the architecture can be increased by supporting redundant data acquisition and recording scenarios.
5. Comparison of the Three Generations
| Feature |
1st Generation |
2nd Generation |
3rd Generation |
| Core approach | Monolithic | Initial task separation | Distributed and task-separated |
| Data acquisition | SCADA RUNTIME | EVENT RECORDER | FAST EVENT RECORDER |
| Real-time visualization | SCADA RUNTIME | SCADA RUNTIME | SCADA RUNTIME |
| Historical data visualization | SCADA RUNTIME | Within EVENT RECORDER workload | LIVE EVENTS |
| Analytics and reporting | Within the same runtime environment | Together with EVENT RECORDER | LIVE DASH |
| Redundancy | Limited | Can be supported with EVENT RECORDER | More advanced distributed architecture approach |
| Scalability | Limited | Improved | High |
6. Corporate Development and Engineering Perspective
This architectural change should be regarded not as a one-time technology transformation,
but as a gradual engineering process in which experience gained from real projects
is reflected in the architecture.
In enterprise software development projects, requirements become clearer over time,
performance bottlenecks emerge under real operating conditions, and solution architectures
mature through field experience. Therefore, the transition from the first generation to the
third does not mean that the previous architecture was completely unsuccessful. Each generation
represents a technical response to the needs revealed by the architecture that preceded it.
Fundamental logic of the evolution: First, all functions were combined
within a single structure; then the data acquisition and archiving workload was separated;
finally, historical data access and analytical operations were also moved to independent
components. In this way, the architecture matured together with real-world system experience.
7. Third-Generation Approach for Modern Plants
In modern energy facilities with high data volumes, a SCADA system is no longer simply an
application that brings data to operator screens. The system must simultaneously address
different requirements such as real-time control, high-speed data acquisition, long-term
archiving, alarm management, historical event analysis, web-based monitoring, and performance evaluation.
Therefore, the most important characteristic of the third-generation architecture is that
these functions are separated into specialized software layers instead of
competing with one another within a single process. This allows real-time operation and
historical analysis to continue within the same overall system without adversely affecting each other.
Example workflow:
- FAST EVENT RECORDER collects and archives data from the field.
- SCADA RUNTIME uses this data for real-time operator monitoring and control.
- LIVE EVENTS provides operational review of historical data and alarms.
- LIVE DASH transforms the data into web-based analytics, trends, and performance evaluation.
8. Conclusion and Evaluation
The transition of the EOS SCADA architecture from a first-generation monolithic structure to
a third-generation distributed and task-separated structure is the natural result of increasing
data volumes, performance expectations, continuity requirements, and analytical needs.
In the first generation, all tasks were concentrated in SCADA RUNTIME. In the second generation,
data acquisition and archiving were separated into EVENT RECORDER. In the third generation,
task separation was taken further through FAST EVENT RECORDER, LIVE EVENTS, and LIVE DASH.
As a result, the third-generation approach provides a sustainable architecture that
preserves real-time SCADA performance, manages high data volumes, facilitates access
to historical data, expands analytical capabilities, and enables components to be optimized
independently.
Important consideration: Installing the software components alone is not
sufficient to fully realize the benefits of the third-generation architecture. Data flows,
network topology, archiving policies, redundancy scenarios, server resources, and operating
procedures must be designed together.
