While the shift towards more renewable energy is exciting, it is also putting pressure on our electricity grid. A few years ago, the Dutch DSOs noticed the rising risk of congestion and realized that there was no granular and scalable way to communicate and coordinate with the growing number of DERs (solar panels, wind turbines, and batteries) connected to their networks in real-time.

That’s why in 2020, Netbeheer Nederland (Dutch DSOs) initiated a project to develop the Realtime Interface (RTI), a framework for real-time information and setpoint communication between DSOs and DERs at the Point of Common Coupling (PoCC). They opened the project to market parties for voluntary participation, and our team decided to take on that challenge.

The technical details of this development and deployment process were presented at the CIRED 2025 conference and can be freely accessed here. This article offers a narrative look at that journey – the hurdles, testing, and collaboration that led to the first certified RTI customer endpoint.

Starting with what we had

Before the RTI project began, the Teleport already existed as an independent, local controller for DERs. It managed solar inverters, wind turbines, and battery storage systems by processing market signals and optimizing energy production, storage, and consumption “behind-the-meter”.

Key design aspects made it suitable for the RTI functionality:

• Security: Built with security principles aligned with ISO27001 and ENCS guidelines.
• Hardware: Equipped with a capable Linux-based processor and the dual Ethernet ports required for RTI network segmentation.
• Compatibility: Supported an extensive library of over 450 asset types.

While the foundation was strong, RTI compliance required real-time DSO communication using the complex IEC 61850 protocol, a protocol far more complex than the Modbus we were used to.

So, we rolled up our sleeves and got to work.

The IEC 61850 challenge

Building IEC 61850 support from scratch was rather impractical. We integrated an existing third-party library, but it was written in C++, while our asset library used different programming. We had to start by creating a bridge (a binding mechanism) between the two.

Achieving compliance with IEC 61850 was a demanding, step-by-step process. The standard itself spans over 10,000 pages, and testing required specific hardware setups. Since the Teleport didn’t have native digital/analogue inputs/outputs needed for some tests, we used an external Modbus-compatible device, leveraging the Teleport’s built-in Modbus support.

To keep costs manageable and accelerate development, we conducted extensive in-house testing using the official certification authority’s software before going for formal certification. This iterative loop involved:

• Debugging the data model:
  Initial tests revealed inconsistencies, partly due to issues in the early RTI data model specifications, which we reported back to Netbeheer Nederland. Early tests had a failure rate around 20% due to mismatches or unnecessary checks. Careful refinement of data models and configurations gradually improved compliance.
• Hunting library bugs:
  The server and reporting functions were particularly challenging due to the library’s structure and the standard’s sheer scope. Because our hardware was quite efficient, standard debugging tools weren’t always effective. Our engineers relied heavily on inserting detailed logs into the library code itself to understand its behaviour. We inserted logs, analyzed outputs, documented errors in detail, and reported them to the library supplier. Some of the bugs got fixed, and others… we had to solve them ourselves.
• Iteration and regression testing:
  Every fix required re-testing. Sometimes, a fix for one issue would unintentionally cause a previously passed test to fail (a regression), demanding further refinement until the solution was fully validated.

Making RTI work with market signals

Compared to the intricacies of IEC 61850, implementing the specific RTI logic was more straightforward. The RTI essentially defines a specific data model and set of actions using the IEC 61850 protocol. Netbeheer Nederland provided clear technical specifications and a verification plan outlining the required behaviour and tests.

The most significant RTI implementation challenge was making the RTI functionality work alongside the market signals the Teleport already managed (i.e. day-ahead prices, balancing market signals, and local control loops).

Unlike a typical setpoint aiming for an exact target, the RTI dynamic limit defines a maximum threshold for power feed-in or consumption. We needed to reconcile this limit with existing market-based optimization.

Our solution was to calculate the most restrictive constraint by taking the minimum value from all active limits (RTI, market signals, local protection). This ensures RTI compliance while preserving flexibility for market optimization. The system can shut off production entirely, operate at intermediate levels, or maximize feed-in — whatever the combination of constraints allows.

From beta testing to certification

Since the RTI specification was still evolving during development, we started testing with the “beta.4” version. We actively collaborated with Netbeheer Nederland, providing feedback on the data model and test procedures. In the absence of an official tool, we even developed a small, manual test tool for verification. These RTI-specific tests focused on validating behaviors like correctly entering “safe mode” upon connection loss. We achieved beta compliance rapidly, quickly addressing minor issues that arose, such as handling negative setpoint values.

Once the final RTI specification (version 1.0) was released, only minor adjustments were needed, mainly making certain connection settings configurable for enhanced security. After these final tweaks and re-certification, the Teleport officially became the first certified RTI customer endpoint in April 2024.

From lab to field

Certification is one thing; real-world operation is another. We partnered closely with the Dutch DSO EnexisRead the full story (in Dutch) on Enexis’ website. for testing.

Lab tests came first: Enexis set up equipment in their facility while we operated a Teleport from our own lab. We initially didn’t use real energy assets; the Teleport generated synthetic measurements and responded to control signals. We verified basic communication (did the measurements sent match those received?) and then moved to complex scenarios like enabling safe mode, sending curtailment signals, and simulating connection loss, comparing the results against expected outcomes. When it worked, we moved to the field tests.

Field testing brought real-world conditions. We installed a Teleport and power meter at a test site, connected to solar inverters, while Enexis deployed equipment on the grid operator side. An Ethernet cable linked the two setups for RTI communication.

We replicated lab scenarios but now used actual measurement data and sent real control commands to the inverters. This allowed direct observation and validation of power changes on both sides of the connection. We started with the beta RTI spec and tested subsequent updates remotely.

We encountered one practical challenge: the solar inverters were 50 meters away, requiring additional Ethernet infrastructure. Despite such logistical hurdles, the field tests were a success, proving the Teleport could reliably operate under real-world conditions while meeting all RTI requirements.

Further tests with DSOs Stedin and Liander also confirmed interoperability, highlighting the crucial need for strict adherence to the specifications by all parties.

Lessons from the process

• Complexity requires patience.
  IEC 61850 compliance demanded methodical, iterative work. There are no shortcuts when implementing a protocol this comprehensive.
• Real-world conditions reveal new challenges.
  Lab tests validate functionality. Field tests reveal logistical issues — like ensuring reliable communication over distance — that you can’t anticipate in a lab.
• Collaboration improves the outcome.
  Close coordination with Netbeheer Nederland and DSOs allowed us to refine the RTI specification based on actual implementation experience. Stakeholder feedback addressed both technical and operational issues.
• Standards enable scale.
  The certified Teleport now works across multiple Dutch DSOs. We’ve also adapted and certified the Teleport for Greece’s and Flanders’ (Belgium) regulatory standards – and more to come! – demonstrating how standardized design enables broader European deployment.

Looking ahead

Developing the first RTI endpoint was a journey where our team met technical dives, (particularly into the complexities of IEC 61850!) , the practicalities of field deployment, and the absolute necessity of close collaboration between all stakeholders – Netbeheer Nederland, DSOs, and technology providers like us.

The Teleport’s successful certification and deployment underscore its readiness to support the Dutch grid. And the work continues. Future RTI versions are already planned: version 1.1 in the coming year will enhance cybersecurity with TLS encryption, and version 2.0 aims for an internet-based architecture supporting both real-time and planned control.

For those interested in a deeper dive into the technical specifics of the development, testing protocols, and compliance journey, we invite you to read our full paper presented at the CIRED 2025 conference.