Challenges of SCADA Systems in Renewable Energy Sources
Between Documentation and Reality: Where the Challenges of SCADA Systems in Renewable Energy Begin
At the presentation level, most SCADA systems appear complete. Supported protocols, scalable architecture, redundancy, cybersecurity – everything seems to be in place. The problem begins precisely when a project stops being a presentation and becomes a system that must operate in a real environment: a distributed portfolio of PV farms, wind power plants, and energy storage systems, with multiple technology vendors and a grid operator whose requirements often differ depending on the region. It is at this point that the gap between declaration and implementation becomes visible at every level – from platform selection, through communication, all the way to data.
The first decision is made very early and is often underestimated. In theory, choosing a SCADA platform comes down to a simple dilemma: a closed ecosystem from a major vendor or an “open” solution. In practice, reality is far more complex, and the choice itself is not about technology, but about the model of control over the system.
For portfolios measured in hundreds of megawatts, the key question is not whether the system works today, but who will be able to modify it five or seven years from now, and under what conditions. In practice, these models often overlap, which further complicates the assessment of a system’s actual independence.
Many platforms declare openness, which in reality ends with access to selected interfaces. APIs may be limited, access to data filtered, and any significant modification may require returning to the original vendor. At the same time, the market offers openly closed solutions that are complete and stable, but by design create dependence on a single supplier. There is also an intermediate model that appears very frequently in practice: a system presented as the integrator’s “own SCADA”, while in reality being based on an external licensed platform.
For the end user, this means that real control over the system – access to configuration, expansion possibilities, or complete documentation – remains limited. There is also an approach in which the system is designed as open from the very beginning within the boundaries of the facility, with full access to data, configuration, and the possibility of future expansion without dependence on a single supplier. In practice, this means greater responsibility on the integrator’s side, while at the same time providing the user with greater control over the system in the long term.
Vendor lock-in is rarely felt during the procurement stage. Its real cost becomes apparent only during the first significant modification, when a task that should take a few weeks begins to be measured in months and additional costs.
Even the best-selected platform will not solve the problems that arise at the communication level. The list of supported protocols in the documentation may be impressive: IEC 61850, IEC 60870-5-104, Modbus TCP, OPC UA, MQTT, and, at the metering layer, DLMS/COSEM for energy meters. In practice, however, integration does not take place at the level of protocol names, but at the level of their implementation.
The same Modbus protocol may involve different addressing schemes, different scaling methods, and different interpretations of data depending on the manufacturer. IEC 104 introduces differences in control models and operator expectations. OPC UA is often used as a transport layer without a consistent semantic model, while MQTT, despite its flexibility, does not
impose a data model. In the case of energy meters, data profiles and reading mechanisms (DLMS/COSEM) add another layer of complexity and further expand the scope of integration.
As a result, a natural level of complexity appears already at the project stage: multiple protocols, different data models, and different approaches to their interpretation. Systems may “speak the same language”, but they still require a shared understanding of what the data actually means. This is precisely the stage at which project teams spend the most time.
When communication starts working properly, attention shifts to architecture. Modern SCADA systems for renewable energy assets operate today in a distributed model, where part of the functionality is executed locally at the site (RTUs, controllers, protection systems), while another part is handled by central systems, often using cloud infrastructure.
The division between edge and cloud sounds logical. In practice, however, the boundary between them is often determined not by process requirements, but by integration convenience. At the same time, there are functions that unquestionably must remain on-site – control, protection logic, and critical operations – as well as functions that can be moved higher up the stack, such as analytics or reporting. Maintaining this boundary is crucial for the long-term stability of the system.
The issue of redundancy follows a similar pattern. In documentation, almost every system appears highly available: two servers, two communication links, two PPC controllers, backup infrastructure. Until the first failure occurs.
In practice, hidden single points of failure emerge: a single database, a communication broker, or a network infrastructure component. This is often not the result of a lack of redundancy, but rather of incomplete redundancy or a lack of consistency between individual system layers.
Added to this is the lack of disaster recovery testing and the absence of realistic recovery procedures. Redundancy that has never been tested simply does not exist.
Cybersecurity follows the same pattern. NIS2 requirements or approaches compliant with IEC 62443 can be correctly described in documentation, but their actual effectiveness depends on the architecture of the system. If OT/IT segmentation, traffic control, and access management were not considered from the very beginning, no procedure will compensate for those shortcomings. In the realities of renewable energy, where on-site human resources are limited, security by design ceases to be a slogan and becomes a necessity.
At the end of this chain lies the element that appears least frequently in project discussions and at the same time has the greatest impact on the value of the entire system – data.
In many projects, the data layer is reduced to a brief mention of a historian. In reality, however, it is the way information is collected, stored, and made available that determines whether a system will remain useful after several years of operation. Data-related problems rarely result from a lack of technology. Most often, they are the consequence of nobody defining what the data should actually represent before data collection began.
A system may operate correctly in real time while simultaneously generating data that cannot be effectively used later. This is particularly important today, as SCADA is no longer merely a visualization and control system but is increasingly becoming a source of information for forecasting, EMS platforms, analytics, and market settlement processes. At this point, a natural boundary of responsibility emerges: SCADA should collect and provide data in a consistent and
reliable manner, while the interpretation and further use of that data should belong to higher-level systems. Attempting to combine all these functions within a single solution usually leads to system overload and a loss of transparency.
Looking at all these layers together – platform, communication, architecture, and data – a recurring pattern becomes visible. Technologies change, protocols evolve, and architectures become increasingly complex. Yet the way systems are often designed remains the same. Systems are designed as if their future could be fully predicted at the project stage, while in reality every SCADA system supporting renewable energy assets will continue to evolve. New operator requirements will emerge, new data sources will appear, and new ways of using that data will be developed.
That is why the quality of a system is not determined by how it looks on the day of commissioning, but by whether it can be understood, modified, and expanded without having to start from scratch. Everything else will change sooner or later. The only question is whether the system will be ready for that change.
