Digital Substation Pt.2 – Insights

As I’m still only at the beginning of this long journey, there are many questions that remain to be answered in this blog post. I’ve highlighted them with lightbulbs 💡 and they are like “breakpoints” where further debugging is needed.

Ecosystem

The edges of any ecosystem are always fuzzy so let’s start from the core. While I’ve been actively looking for hidden gems, it turns out that the key player by far in this area is the Linux Foundation Energy initiative. It acts as an umbrella to drive a variety of industry members towards open collaboration. Like I wrote before, the open-source communities in the energy sector at large and around substations in particular still seem to have a long way to go to catch up with other industries such as data centres and consumer electronics – which makes such collaborative efforts all the more valuable.

LF Energy is currently made up of roughly 50 members and 50 projects which all deserve some attention. I’ve arbitrarily cherry-picked a handful that appear to be the most relevant ones for this blog post. And let’s not forget to keep an eye open for other entities outside this circle.

Standards

Before we dive into a sea of lines of code, an important aspect to keep in mind is international standards. While they might seem rather daunting at first, they are also the backbone of the industry as they help ensure interoperability. Many open-source projects provide concrete implementations of them. It all essentially revolves around the now-famous IEC 61850. If you’ve never heard of it, the written interview from the technical committee lead provides a quick intro.

The most relatable parts of the standards for software engineers are messaging protocols (MMS, GOOSE, SV) as well as the substation configuration language (SCL). Here’s a small cheat sheet:

MMS: general-purpose messages with a topology of abstract objects inherited from the manufacturing world (ISO 9506)

GOOSE: low-latency publisher / subscriber events operating at the MAC address level (OSI level 2) in substation LANs

SV: sampled values, they are the digital equivalent of analogue signals

SCL: machine-readable XML dialect to describe a substation topology

The IEC standards are all proprietary. Copies of the PDF documents can be purchased from the International Electrotechnical Comission website. While this has been common practice for many decades, it also shows an obvious gap to fill when it comes to open source. I couldn’t even find canonical links with definitions to the acronyms mentioned earlier other than some lightweight Wikipedia entries or independent articles such as this one. The non-profit UCA user group goes in this direction but isn’t quite a true open-source community effort either.

To clarify what I have in mind, let’s take the example of how the graphics industry has adopted a now well-known and successful open standard approach (OpenGL, Vulkan) via the Khronos group. These standards are entirely open and available free of charge, including the certification test suites so anyone can run them on their GPU drivers. Only the final, authoritative certification is not free and is typically needed only by hardware vendors in the supply chain for end-user products.

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

As a side note, it’s also worth mentioning that earlier communication protocols such as Modbus are still around and they keep coming up in the literature. Electrical grid infrastructure naturally has a huge inertia due to the costs and amount of effort involved with replacing any part of it, and they’re built to last. A good example is this 2019 slide deck from Siemens. But let’s stay focused on the more modern solutions here.

Projects

How well do these international standards translate into currently available open-source tools? First, let’s enumerate a few. Starting with the LF Energy projects, here are the ones I picked:

• SEAPATH: hypervisor for digital substations
  • Resources: GitHub, wiki
  • Runs on Yocto and Debian with Ansible to deploy new VMs on top
• Power Grid Model: grid modeling and profiling
  • Resources: GitHub, PyPI
  • Comes with some nice examples
• PowSyBl: Power System Blocks
  • Resources: GitHub, documentation
  • All done in Java code, it would seem useful to have some data file format
  • Here’s a nice tutorial among a few others
• CoMPAS: Configuration Modules
  • Resources: GitHub, wiki
  • A docker compose setup is available
  • Some tutorial videos are available too
  • Looks great, finding my way around the project wasn’t very easy at first

Then here are a few independent ones which I found to be equally interesting:

• libiec61850: IEC 61850 library written in C
  • Resources: GitHub, documentation
  • Under the GPL v3, appears to be the only open-source one available
  • Part of MZ Automation
• OpenSCD: Open Substation Communication Designer
  • Resources: GitHub, wiki
  • Editor for SCL files, see the demo
  • Has a downstream fork for CoMPAS
• VeraGrid (formally GridCal): electrical grid simulation
  • Resources: GitHub, PyPI
  • While this is potentially highly relevant here, substation modeling still remains to be done
• OpenEnergyTools: toolbox related to digital substations and grids
  • Provides Typescript tools to handle SCL data
  • Nice community initiative, still early days

Each project mentioned above as well as many others would require at least a dedicated blog post and several hours of playing around to do them justice. So as a tl;dr summary, I found libiec61850 to be pretty neat and a great way to get started with the standard from a hands-on point of view. Reading the code already sheds some light on what it’s all about. Then I found VeraGrid to be of very high quality, but that’s slightly outside the physical substation realm. Other simulation and modeling tools can be used locally too, more or less easily. The biggest issue I have with those that relate directly to substations is how to use them in practice without having a real electrical grid at hand. I’m sure there must be ways to set up lightweight development environments but it didn’t seem too obvious. For example, I haven’t found sample Ansible deployment files for SEAPATH with typical VM instances other than in the release procedure.

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

Stacking things up

Also I’m struggling to understand how things fit together. In particular, I find it hard to see how these projects can be composed to form a functional stack. Say, where does VeraGrid sit compared to Power Grid Model and PowSyBl, or OpenSCD compared to CoMPAS-SCT? The mapping between electricity transportation and distribution networks on one hand and software projects on the other seems rather fuzzy too, but that may just be because I’m missing some information and expertise there. Then I don’t know to which extent libiec61850 is used in real-world substations, I would expect such use-cases to be somewhat publicly visible due to the GPL license.

For the sake of the exercise, let’s try and put together all the pieces I’ve gathered so far. A digital substation has a set of software services running on top of a dedicated local network (LAN) infrastructure. This is done via a hypervisor such as SEAPATH and isolated virtual machines which provide the different functions. The substation topology for the underlying electrical equipment such as circuit breakers etc. is described using the SCL language which OpenSCD or CoMPAS SCT can help manage. Critical communication within the substation’s LAN is done via GOOSE, mostly to protect the equipment against faults or surges. Sensors send data as samples values (SV) which are used by monitoring systems and the control logic to trigger actions. Routable-GOOSE (R-GOOSE) is used to open remote connections via the regular IP layer but without real-time guarantees. All the rest of the communication is handled via industry-standard MMS messages. Aside from grid modeling and simulation, this is all I can think of right now that applies to digital substations.

What stands out is that some areas seem to have competing projects while there are large gaps in other areas. What are the actual applications running in substations and implementing the control logic? Probably this is driven mostly by industry members with a rather narrow set of requirements. So I would expect all the missing parts to have proprietary implementations, a bit like consumer electronics or web technologies have open-source low-level building bricks to provide a platform for deploying proprietary applications.

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

My 2¢

While I have spent quite a bit of time looking into each of them, I’m still mostly commenting here on the “out-of-box” experience as a newcomer. So I may be missing some obvious things, but I suspect others like me might have to jump over the same hurdles. My general feeling is that there is a very strong momentum behind all these projects although the community around it is still in its infancy. I may be projecting too much, but what seems to be needed now is to expand the spectrum of people involved. New contributors with some relevant experience from different backgrounds and enough time available would help bring things to maturity. It reminds me of where embedded electronics was before Android took off around 2012 and Linux became the main OS in the industry. It’s true that while virtually anyone can get a computer and run plain software on it, the hardware involved with electrical grids means it’s bound to be destined to a much reduced user base. Still, smart homes and domestic generators such as solar panels are becoming increasingly common. As such, there is a potential for consumer-level nanogrids at the household scale. Having homes connected to the grid from a data point of view is increasingly common and raises awareness about energy usage. The main incentives for consumers may be keeping an eye on bills, where the electricity is coming from as well as its associated carbon footprint while preserving privacy.

I realise this has raised more questions than answers, which again probably shows where I lack some knowledge but also where the potential for growing the community side of the ecosystem might lie. Let’s now take a look at the second topic of this blog post and jump to a different starting point which does have a well-established software ecosystem.

Software Defined

Data centres route information through their networks with elaborate and dynamic rules. Similarly, substations route electricity. However, drawing an accurate parallel between these two kinds of routing is far from trivial. Network data packets are abstract entities that can be held in memory and carry their own headers, which are used to build sophisticated rules. An electrical energy flow has a very real physical dimension. A broken TCP connection doesn’t sound as dangerous as an electrical arc flash explosion. I suppose some concepts still apply, such as load balancing for data traffic and load shedding with power generators. We may also see an equivalent of the data plane in the electrical concept I’d like to call power plane. Generally speaking, even if the analogy with data routing only goes so far, the idea of describing both kinds of rules and deploying them dynamically via software is equally valid. So the first takeaway is that software-defined substations need their own dedicated frameworks and can’t just reuse networking ones for routing energy. Rather, we may want to take a closer look at how modern-day SDN came to be over the past twenty years or so. There are probably many lessons to be learnt from it and ideas to guide progress in software-defined substations (and material for more blog posts…).

Substation networking

The second aspect is that substations are built on top of computer networks. As such, SDN can totally be used to define their topologies. It’s not directly about how to route electricity any more but how to set up the control systems that do. In this respect, it is clearly related to data centres. One might even argue that a digital substation contains a small, quirky, dedicated data centre. Above all, network security is the most important aspect as digital substations become exposed to the Internet. Control logic gets run in isolated VMs on top of specialised hypervisors and standard security rules can be enforced when exposing them to the Internet: firewalls, encryption, authentication etc.

💡 Should networking, energy flows or both be software defined?

Duck the GOOSE

Still, some specific features are only found in digital substations. The main one that comes to my mind is the concept of low-latency events with the IEC 61850 GOOSE specification. To guarantee delivery time, it bypasses the TCP, UDP and IP parts of the network stack (i.e. OSI layers 3 and 4) to directly talk at the link level (layer 2) using MAC addresses. While this of course gives fine-grained access to the infrastructure, it comes at a high cost: no IP routing tables, specific security considerations and non-standard raw communication software sockets as per the libiec61850 implementation. Note that security might be simplified and even strengthened by skipping the IP layer, but I fear it’s not that simple when it comes to preventing escalation once an intrusion has occurred.

At any rate, I was quite surprised to learn about this and I’m sure it would also make other software engineers raise an eyebrow. For example, to the best of my knowledge, this doesn’t happen in the automotive industry which has similar challenges. Instead, a dedicated CAN bus is used to transfer sensor and actuator messages which translate easily to UDP for high-level applications such as car dashboards. A real-time operating system or RTOS such as QNX (proprietary) is typically used for handling the logic of critical functions. Why not use something similar in digital substations? Say, a CAN-like bus over fiber optics? Maybe it’s just down to practical considerations. Still there seems to be a disconnect with the wider standard IEC 61508 about the safety of electrical systems, but again I’m not an expert in that field. Then I found out about the IEC 61850-90-5 extension which basically does GOOSE on top of UDP or TCP, known as R-GOOSE as it’s routable to other IP networks, without the same time-critical considerations which puts it back in SDN land.

Fun times ahead

These are all insights into the hard problems of digital substations and I’m only scratching the surface. There’s no doubt that every technical design decision was rooted in sound expertise. I’ve tried to highlight the parts that I found to be the hardest to grasp and more generally speaking, how a more open-source culture could be fostered. We’ve seen how the Linux kernel really became probably the most successful open-source project, by allowing anyone to take part. How an unknown contributor ended up writing the basis for IPv6 support or how reverse-engineering enthusiasts have shifted entire business models. Acting on the same plane as major corporations, universities and everything in between is really what the free software philosophy is all about – beyond the plain distribution terms outlined in the license.

This week I’m attending my second LF Energy Summit Europe. It’s a fun, welcoming event and a great way to get introduced to the ecosystem. I might find some answers to my questions and probably will come up with many more. That will give me yet again plenty of things to cover for the third and last post of this series. Wrapping this one up now on my way to Aachen, traveling entirely by train, is a great way of immersing myself into the Energy world.

Last modified on 2025-09-24