If you are developing or connecting larger generation assets in the Netherlands, the Realtime Interface, usually shortened to RTI, is no longer an abstract future requirement. Official Dutch DSO guidance from Enexis says that all new generation connections above 1 MW must have power control through RTI, and that for existing connections it becomes mandatory when reinforcement is requested for generation capacity above 1 MW. Separate Enexis battery guidance also says RTI is a standard requirement for batteries larger than 1 MW. The official Netbeheer Nederland specification is framed around RfG category B, meaning 1 MW to 50 MW, and standardises the technical interface between the system operator and the connected party.
The practical consequence is straightforward: if your project sits in this scope, you should assume the control and communications architecture is now part of the grid-connection problem, not a later optimisation layer. You need a customer endpoint, a defined control boundary, IEC 61850-based communication, and a compliance path that survives future software changes.
What the RTI actually is
Netbeheer Nederland describes the RTI as the interface between the system operator and the connected customer for exchanging measurement values and operational constraints in real time. In the RTI v1.0 technical specification, the Dutch system operators say the project started in 2020 and that the goal is to let operators and connected customers communicate in real time so scarce network capacity can be managed more actively.
This is not just a monitoring feed. The whole reason the RTI exists is that the operator may need to reduce active power output or impose operating constraints quickly enough to protect network security and manage congestion. The Dutch documentation explicitly ties the RTI back to Commission Regulation (EU) 2016/631, the Requirements for Generators code, which allows operators to require an interface for remote power reduction on qualifying generating units.
Why the Netherlands pushed this forward
The Dutch justification is not mysterious. Netbeheer Nederland says the country needs a standard interface because distribution networks were not originally designed for large amounts of distributed generation flowing back into them, and because the regulatory framework for congestion and capacity management changed. In the v1.0 specification, the Dutch operators specifically point to the November 2022 update of the Dutch grid code, which enabled more active congestion management in their networks.
That matters because the RTI is not best understood as a generic digitisation project. It is a congestion-management tool. If you are an asset owner, developer, or integrator, the question is not whether the interface is elegant. The question is whether the operator can trust your installation enough to leave it connected under tighter network conditions.
Which projects are in scope
The safest baseline is this: treat new or uprated category B generation connections in the Netherlands as RTI territory. Enexis says RTI is required for all new generation connections above 1 MW, and the Netbeheer Nederland v1.0 specification focuses on RfG category B, 1 MW to 50 MW. For storage projects, Enexis also says RTI is a standard requirement for batteries larger than 1 MW, which gives a first-party indication that the requirement is being operationalised beyond the narrowest generation-only reading.
The v1.1 specification, published publicly on July 1, 2025, also says the RTI architecture is developed so it can be applied to connections with a mix of generation and consumption and to larger connections. In other words, even if your exact use case is not the simplest solar-park example, the direction of travel is clear: the interface is becoming part of the standard control boundary for larger Dutch connections.
What has to be installed
The 2025 Dutch RTI addendum is useful because it makes the physical split much more concrete. It says the RTI consists of:
- a system operator endpoint
- a customer endpoint
- an Ethernet connection between the two
The same addendum makes the demarcation of responsibility clear. The system operator is responsible for its own endpoint and associated communications equipment. The customer is responsible for placing the customer endpoint, the Ethernet run to the operator endpoint, and the integration of that customer endpoint into the installation behind the connection point.
That is an important engineering detail. RTI compliance does not stop at buying a box that claims compatibility. Someone still has to map real plant behaviour into the endpoint, integrate it with the local controls stack, and ensure the operator's setpoints actually reach the equipment that matters.
What the customer endpoint must do
At a minimum, the customer endpoint has to participate in the RTI communications model and process the relevant signals coming from the operator side. Public Dutch implementation guidance says the generator must install a customer endpoint that can receive and process the control signal in accordance with IEC 61850. The official v1.1 specification also adds more explicit cyber-security requirements and says the specification set now includes the technical specification, a protocol implementation document, and an SCL file.
There are two production implications here that are easy to miss:
- The endpoint is part of a standards-based control interface, not just a simple northbound API integration.
- Firmware and software changes matter. The v1.1 specification says that if modifications affect RTI behaviour, a retest should be performed, and it explicitly gives firmware or software updates as examples.
That means the endpoint should be designed as a maintained product, not a one-off commissioning artifact. If a control gateway cannot be updated safely, versioned clearly, and re-verified when behaviour changes, it is going to age badly in this environment.
What changed in RTI v1.1
The most important change in the publicly available RTI v1.1 specification is that security requirements became more explicit. Netbeheer Nederland says version 1.1 introduces encryption and authentication on the IEC 61850 communication using IEC 62351. Public add-on notes published in October 2025 then relaxed some implementation details, which is a reminder that this is still an evolving standard and that integrators should track version changes actively rather than assuming the February 2024 rollout documents are the whole story.
What this means for developers, EPCs, and integrators
If you are building or connecting assets in this part of the market, there are four practical consequences.
1. Control architecture is now a connection risk
You can no longer treat local controls, telemetry, and grid-operator communications as something to tidy up after energisation. The endpoint, the plant interface, and the software update path are part of the connection package.
2. IEC 61850 capability is not optional for this use case
A lot of energy IoT systems are comfortable with MQTT, Modbus TCP, or REST APIs. Those protocols may still be useful elsewhere in the architecture, but RTI raises the bar because the customer endpoint has to speak the operator's language at the grid-control boundary.
3. Versioning and compliance need to be operationalised
If software changes can trigger re-verification, then release management matters. You need to know what version is running, what changed, and whether the change affects RTI behaviour.
4. The endpoint must be integrated into real plant logic
The grid operator can send a signal, but the real engineering work is turning that into dependable plant behaviour. That may mean interfacing with inverter controls, battery EMS logic, local PLC layers, or site-level curtailment logic. The endpoint is only the narrow neck of the hourglass.
Common misunderstandings
- "RTI is just another dashboard or monitoring feed." It is not. It exists so the operator can exchange operational constraints and real-time signals.
- "If we can expose data via an API, we are basically there." Not necessarily. The Dutch RTI boundary is standards-driven and explicitly structured around endpoints and IEC 61850 communication.
- "Once certified, we are done." Not really. RTI v1.1 makes it clear that software or firmware changes that affect behaviour can require retesting.
What to check next on a live project
- Is the project clearly within the Dutch RTI scope, including whether the connection is new, uprated, or mixed generation and consumption?
- Who owns the customer endpoint selection and integration?
- How will IEC 61850 functionality be implemented and tested?
- What is the software update and regression-testing path for the endpoint?
- Where exactly do operator setpoints terminate, and how do they reach the real controllable asset?
The deeper point is that RTI is a sign of where grid integration is heading more broadly. As congestion grows, connection permission and control capability start to converge. In that environment, the communications boundary is no longer an accessory. It is part of the electrical project.