Attending LF Energy Summit Europe was a really inspiring experience. The event is growing very quickly every year which shows how much interest there is in the industry for open-source solutions. It was my second Summit and I’m now able to navigate my way through the various projects, companies and individuals – none of them were known to me just 18 months ago. Writing my previous post really helped me getting prepared for the event and I arrived with many questions in mind. I’m glad I’ve found some answers and met numerous people to discuss all these topics and beyond. For now, let’s focus on the ones I raised last time and what I’ve learnt since then.

Reference Stack

💡 What would be needed to create a complete open-source reference solution?

Having a fully open-source reference stack is definitely something many people are aiming for. It reminds me of the story of the early days of GNU, starting with just a C library before adding a kernel (Linux), a compiler (GCC), applications (glib, GTK) etc. The demo as seen in the main picture with the Savoir-Faire Linux team was a great way to showcase where things currently stand and how SEAPATH provides a very promising basis for an open-source reference stack. In a nutshell, it’s a hypervisor which addresses all the real-time and quality of service requirements for running applications in a digital substation. I’ll definitely be spending more time on this in the coming weeks.

However, the upper layers of the stack are still missing. As I anticipated, application VMs are all proprietary. Having some reference ones would be very useful, even if they aren’t suitable as-is for production deployments. They would first of all facilitate development and validation of the lower layers, then potentially provide building blocks for the real world. As community efforts are growing, I believe it should eventually materialise so I’ll be keeping an eye on that too.

As a bonus, there is also a path to having an open hardware reference design for at least some components with initiatives such as OwnTech. So the stack can grow both ways around SEAPATH, all the way from the hardware to application VMs.

IEC 61850 Libraries

💡 How about creating a non-official, open standard for IEC 61850?

One key building block of digital substation services is an implementation of the IEC 61850 communication protocols. This is a somewhat thorny topic as it’s a proprietary international standard surrounded by many legal grey areas. In my previous post, I suggested writing a new Rust crate under the MIT license. While in Aachen, I was delighted to meet Jakob Vogelsang who happens to be working on the OpenEnergyTools project which does just that!

I’m looking forward to start contributing very soon even though I don’t currently have access to the standard itself. This may in fact be all for the better if it can avoid a few legal issues. The details of how it’s all going to unfold still need to be worked out. At least we’ve been able to confirm that having an open-source implementation of the standard is permitted. It seems a bit simpler than some reverse-engineered GPU driver projects I’ve seen such as Panfrost which ended up being a huge success in spite of the countless pitfalls that paved the way there. Now, electrical equipment destined to be used in actual substations still has to meet safety regulations as per IEC standards too but that’s an orthogonal issue. Developers aren’t responsible for deploying the grid.

Real-Time Requirements

The topic of punching a hole through the ISO networking layers to get data packets delivered directly and in real time doesn’t transpire as an obvious source of concern. This doesn’t mean it will never be, a recurring theme at the Summit was that security is paramount but there is currently little clarity over how to achieve it or how secure the current systems are. So it might be an oversight, time will tell. There must have been some form of security audits in the past, maybe the results just haven’t been shared publicly. The industry tends to focus on safety first as with traditional substations and it takes a while to address the additional risks that the digital world brings to the table.

💡 How can one create a virtual digital substation for development?

Still, using the networking hardware rather than a dedicated digital CAN-like bus for GOOSE and sample values (SV) seems like a practical approach for keeping things simple. As long as these packets don’t disrupt the regular services running on TCP and the whole approach doesn’t pose serious security risks then I suppose it’s fine. At least it makes it easier to implement the rest of the stack so it definitively helps with development. Again, this is where I’m expecting SEAPATH to shine.

Also I’ve heard that the standards tend to be rather heavy-weight, so it may be justified to have more streamlined, optimised communication within some well-defined areas of substations and rely on the established protocols primarily for the sake of interoperability – food for thought.

Last Leg

I now have all the elements lined up for the third and last part of this blog series, except maybe that I haven’t been exposed to the hard reality of electrical grids yet. So I’ll continue down the same avenue with more hands-on experiments, maybe running SEAPATH with some basic hardware. What are the challenges faced when deploying and maintaining a digital substation in the field? How does regular grids compare with railway networks or other specialised use-cases? Let’s see where this takes us.

Last modified on 2025-09-29