How to Verify IEC 61850 to IEC 104 Translations Without Physical IED (by Omicron)

By Onur Durak

This approach addresses Boehm’s Law by identifying configuration errors and interoperability issues early in  the design phase, significantly reducing the costs and time associated with troubleshooting during on-site  commissioning. Furthermore, virtualization bridges the knowledge gap between traditional electrical  engineering and modern IT infrastructure, providing a scalable platform for functional monitoring and  automated testing. Ultimately, this methodology allows utilities to maintain grid stability and operational  flexibility, transforming the commissioning process into a streamlined, no problem workflow.

1/ The Evolution of Digital Substation Verification

Imagine it’s the 2010s and you’re a plant automation engineer. You’re on your way to commission a project.  When you arrive at the airport, you receive an email with the subject line “Update on the RTUs” and the  following content: “I hope this email finds you well. I’m reaching out regarding the RTUs. We had to change  the signal mapping for the control center. Attached is the latest backup. Could you please check the mappings  again?” It’s quite possible that this email doesn’t find you well and you reply with a “Well, it depends.” 

The power grid is changing, and with it the best practices we once learned as electrical engineers during our  training. Yet the pace of these changes seems quite slow when compared to the transformations taking place  in the industries that rely on the power grid. With the dawn of the era of centralization and virtualization of  protection and automation systems, plant engineers are increasingly able to respond to such requests with  “no problem” instead of “it depends.” This article examines current testing practices for substations, where  HMI observation tests are performed on a PC without the need for hardware IEDs. The article also explores  the time-saving benefits of this approach in the context of an evolving power grid. 

2/ Control center communication via IEC 60870-5-104 

As we are in the era of peopleless substations, the importance of reliable communication with the control  center is crucial. For this reason, it is already standard practice to use Remote Terminal Units (RTUs) for data  centralization and protocol conversion, as well as for establishing a real-time connection between the  substation and the control center. One of the most common communication protocols is IEC 60870-5-104  (commonly referred to “IEC 104”), which requires translation from the MMS protocol of the IEC 61850 standard  used in the substation’s station bus network. 

There are several practical reasons why the IEC 104 protocol is used for control center communication rather  than the IEC 61850 protocol. One of the main reasons is that IEC 104 has been widely used for decades and  is employed to control and monitor geographically distributed processes in SCADA systems, particularly for  substation automation. Due to its long-standing use, many utilities have established the necessary  infrastructure and gained experience with IEC 104, making this protocol a more convenient and cost-effective  choice for control center communication. 

IEC 61850, on the other hand, offers more extensive functionality and better interoperability within substations  and was primarily developed for communication in substation environments. However, despite the growing  adoption of IEC 61850 in wide area networks (WANs) over the past few years, it will still take some time before  the protocol is truly established and has become the standard. As a result, IEC 104 remains a practical choice  for communication between control centers and substations: It is well-established, compatible with existing  systems, and suitable for WANs. 

By integrating these two standards, utilities can achieve seamless communication between substations and  control centers. This enables real-time monitoring and grid control, allowing for faster intervention in the event  of faults or anomalies. Furthermore, this integration facilitates simpler data management and analysis, thereby  laying the groundwork for more informed decisions and improved grid stability. 

The use of RTUs as gateways and protocol converters plays a crucial role in this integration. RTUs can convert  IEC 61850 protocols into IEC 104 protocols, thereby ensuring that data from modern digital substations is  effectively transmitted to control centers. This not only enhances interoperability but also reduces the need for  extensive infrastructure changes, making the integration process more cost-effective. 

3/ Software RTUs: Why are they the future? 

Forget bulky, dedicated hardware. When we talk about an RTU today, we simply mean software – no extra  boxes, no wiring, just pure digital magic. That’s the power of a “Software-RTU” (also known as a “Soft-RTU”).  It allows us to completely rethink how we connect to and control station automation systems. You can think of  it as a highly intelligent software agent that can run on virtually any standard computer—from a rugged  industrial PC to a virtual machine in the cloud. Compared to their traditional hardware counterparts, Soft-RTUs  offer an impressive level of flexibility and scalability. Need to add a new server? No problem! Just configure it  in the software. Want to integrate a different protocol? A quick update is all it takes, and you’re good to go.  This saves a lot of time and money on implementation and makes system expansion a breeze. 

This software-centric approach not only reduces hardware costs and maintenance efforts but also opens up  entirely new possibilities for more comprehensive data processing and integration. Since Soft-RTUs run in a  standard computing environment, they can seamlessly leverage existing IT infrastructure, security measures,  and tools with impressive performance. For you, this means: You can collect data, process it at the network  edge, and seamlessly send it to your SCADA system, historians, or even cloud-based platforms to derive more  comprehensive insights from it. Because Soft-RTUs can act as versatile gateways between various industry  protocols, they are invaluable for modernizing legacy systems and serving as a bridge between Operational  Technology (OT) and Information Technology (IT). If you’re looking for a cost-effective, customizable, and  future-proof way to manage your remote assets, it’s time to let a Soft-RTU handle the heavy lifting. Although  they are among the most critical assets in substations, they do not bear the burden of being responsible for  protection functions, and they require less computing performance, making it easier to digitize them sooner  and more safely than intelligent electronic devices. 

4/ Comparison: Digital twins for substation automation and simulation 

The term “Digital Twin” is currently on everyone’s lips in the PAC world. A digital twin is a virtual representation  of a physical object—a concept that has existed for many years. Thanks to advancements in CPUs, which  have become much more powerful and reliable, digital twins are also growing in popularity in the context of  power grids. In addition to the use of vPAC systems in substations, it has become a major trend to use digital  twins of intelligent electronic devices in electrical systems to monitor the states of assets, perform risk  analyses, and verify protection configurations.

In short, a digital twin of an IED is a much more comprehensive and dynamic virtual replica of a specific  physical IED. In contrast, an IED simulation feature in a testing tool serves as a software-based proxy whose  primary purpose is to replicate the communication behavior and data model of a real IED. Its main purpose is  to enable the testing of other devices or systems that interact with the IED. These may include, for example,  a SCADA master, other protection relays (for GOOSE communication), or devices that receive and process  Sampled Values. In this simulation, the IED’s SCL configuration file is typically used to precisely mimic its  external communication interface and data points, thereby providing a static yet functional representation that  is essential for validating interoperability and protocol compliance during specific test campaigns. This makes  this setup the more convenient option for on-the-go testing. After all, it would be quite costly to book an extra  seat on the plane for an industrial PC capable of running the entire system in order to test the desired last minute changes en route to the substation. 

5/ Signal Testing in a virtual environment: an example 

When I’m asked to describe virtualization in our industry, I start by asking, “What is an IED??” The answer is  quite simple: An IED is a microprocessor-based controller specialized in handling protection, control, and  automation functions. To me, that sounds like a PC with a limited, specialized functional range on which the  digital twin of the IEDs we use in our substations can be run, a classic example of virtualization. Virtualization  is often achieved through hypervisors, which create virtual machines (VMs) that emulate the hardware and  make it possible to run multiple operating systems on a single physical computer. Each VM acts like a separate  computer, providing strong isolation. Another virtualization method, containerization, virtualizes at the  operating system level. Containers all use the same host OS kernel and are therefore lighter and faster to  deploy. They create a packet consisting of the application and its dependencies, ensuring consistency across  environments. 

An innovative concept like virtual protection, automation, and control (vPAC) demonstrates how software defined solutions are pushing the boundaries of what is possible in industry, particularly in energy systems.  With vPAC, traditional physical protection relays and other specialized IEDs can be replaced in the future by  virtualized software functions running on high-performance standard industrial servers (often referred to as  IPCs). 

After a brief detour into the world of virtualization in our industry, let’s get back to the main topic: How can we  test signals using a specific approach? We don’t need all those virtualized solutions to do this – the concept  of “simulation,” which we touched on briefly earlier, makes it possible. However, we’ll revisit the potential  benefits of virtualization later on.

So what does this have to do with our approach? Well, let’s put the individual parts together using an example.  First, we’ll put our electronic appliances back into airplane mode and set up our architecture as shown in  Figure 5: 

(1) Let’s boot up the virtual machines: You’ll need a PC with a hypervisor capable of running multiple  virtual machines. With this approach, we’ll use the VM configuration to easily deploy the tools as  follows: 

a. VM1: the testing tool, 

b. VM2: the RTU, 

c. VM3: the HMI,  

d. VMx: depending on what is needed in each case, but focusing on signal testing, these three  are sufficient. Our test environment should already be set up as shown in Figure 3. 

(2) Let’s configure the virtual network: Depending on the project, it is quite easy to configure a virtual  Ethernet switch in the hypervisor and even connect it to a physical adapter. However, since we are  working entirely in a virtualized environment for this purpose, it should be sufficient to configure a  network as shown in Figure 4:  

a. vSwitch-1: This virtual switch creates the station bus, on which our simulated IEDs, the HMI,  and one of the RTU ports for MMS communication are located. Additionally, a port of the test  tool must be connected to this bus. 

b. vSwitch-2: In our case, this is not necessary, but to be prepared for any eventuality, we also  set up a process bus for the BCU/BPU IEDs and the PIU/MU/SCUs. 

c. vSwitch-3: This virtual switch is configured to connect the gateway’s control center port. In the  test setup described here, another port of the test tool is also connected. The test tool will also  simulate the control center as a client to the gateway’s IEC-104 server.  

d. vSwitch-4: This virtual switch is configured to connect the management ports of all appliances  provisioned in the hypervisor (RTU, test tool, etc.).

(3) Together with the subtasks, we can thus develop a solution in two steps that allows us to perform  tests. To do this, we need the some configuration files, such as: 

a. SCL file for the substation: To test control center communication signals, simply import the  SCL file into the test tool. During the test, the IEDs can be simulated in this way. In other  words, we virtualize the IEC 61850 signals of multiple IEDs so that the Soft-RTU can act as a  client for the IEDs’ MMS protocol. 

b. RTU configuration: Required for the test, since we are ultimately testing protocol  implementation in this case. Since this is primarily an on-the-fly test, the modified configuration  can simply be updated via the management port. 

c. HMI runtime: In our case, this was not updated, but if we want to combine the signal test with  the HMI tests, it is helpful.  

When we integrate the above-mentioned documents into our test setup, we get a view as shown in Figure 6.  In a centralized view, we see the test tool for observation of the test, including the simulated IEDs according  to the SCL file, the HMI runtime for observing the displays, and the RTU runtime with a summary of the  communication, typically the substation.

(3) Together with the subtasks, we can thus develop a solution in two steps that allows us to perform  tests. To do this, we need the some configuration files, such as: 

a. SCL file for the substation: To test control center communication signals, simply import the  SCL file into the test tool. During the test, the IEDs can be simulated in this way. In other  words, we virtualize the IEC 61850 signals of multiple IEDs so that the Soft-RTU can act as a  client for the IEDs’ MMS protocol. 

b. RTU configuration: Required for the test, since we are ultimately testing protocol  implementation in this case. Since this is primarily an on-the-fly test, the modified configuration  can simply be updated via the management port. 

c. HMI runtime: In our case, this was not updated, but if we want to combine the signal test with  the HMI tests, it is helpful.  

When we integrate the above-mentioned documents into our test setup, we get a view as shown in Figure 6.  In a centralized view, we see the test tool for observation of the test, including the simulated IEDs according  to the SCL file, the HMI runtime for observing the displays, and the RTU runtime with a summary of the  communication, typically the substation.

How test cases are configured depends on the specific testing tool. There are several testing tools available  on the market, as well as a few virtualized equivalents. A virtualized testing tool is not required for this test  method, but a VM enables a variety of approaches. We will now create the test case using one of these tools,  or we can simply run the previously created test case again. The required mapping lists must be imported into  this tool. This allows the signals to be assessed directly. For a focused view, the signals can be mapped in just a few steps (see Figure 7). The next steps involve defining the test case steps, selecting the command  route (IEC 61850 <-> IEC 104), setting parameters, and executing the test. It is also convenient to have a test  report with the test results available immediately. This test tool also enables automated assessment of the  expected results, which is helpful for gateway tests. In our case, however, the HMI is being tested. Therefore,  a manual assessment option is preferable. The testing tool allows you to supplement the test report with drop down comments and then easily share it with others who request a signal verification due to the changed  configuration. 

This eliminates the need to write long emails explaining the issues. A simple “Attached are the results and my  comments” is sufficient. While there may be enough time during the flight to review everything again, there is  often not enough legroom to make corrections. 

6/ Why should we have this?  

As mentioned above, testing is essential. While safety testing may be considered more important, before  turning to this somewhat more complex area, let’s first address the topic of signal testing for the sake of clarity  and as an introduction. 

Thanks to (or because of) the system’s complexity, signal availability, and higher speeds – accompanied by  greater bandwidths – significantly more signals now need to be transmitted from the substation to the control  centers. You can practically hear the sarcastic “Yippee!” from our colleagues in the field. 

In the past, thorough system testing required significant investments in hardware, complex wiring, and time consuming physical test setups in a lab or even on-site. This was often associated with a limited number of  test scenarios, high costs, and bottlenecks in development and deployment cycles. Who even has a  warehouse big enough to house real high-voltage equipment for a FAT? Or how practical is it to have to use  that warehouse every single time? Not very. And then, of course, there’s Boehm’s Law, named after computer  scientist Barry Boehm, which states that the cost of finding and fixing a defect increases exponentially as time  goes on. This means: The further along we are in the development cycle, the more expensive troubleshooting  becomes. This principle from software development can also apply to the engineering of substations.

So far in this article, the topic of testing in virtual environments has not been addressed. The method described  here is merely one aspect of it and can be viewed as a foundation for virtualized testing. This is precisely  where virtualization emerges as a game changer. Let’s imagine that all it takes is configuring a few additional  virtual switches and ports to not only test the system partially but also to route it to testing tools, allowing test  engineers to test a live system before a firmware upgrade. Let’s take this concept a step further. 

Virtualization (and simulation as an equally valid approach) makes it possible to have an entire substation in  front of you at your desk, allowing test engineers to perform a technical review of their own substation design  in advance, configure the substation once, and then make minor changes to the layout. Once our file  “Substation-XX_First-Draft.scd” is ready, we can immediately check and validate everything and identify any  errors or issues that were previously overlooked. Virtualization also makes it possible to easily share reference  documents with other teams or external partners. Once the file “Substation-XX_Final-Revision.scd” is stored  in a cybersecure, protected cloud, all you need to do is share the corresponding folder with the colleagues  responsible for the FAT. They are familiar with the procedure, they know what to check, and they now have  everything in a single folder, which actually shortens the time needed to prepare for the FAT. Virtualization  makes engineers happy because it allows them to focus on more important tasks, such as system tests and  injections. Speaking as a commissioning engineer, it would be great to be able to go to the substation knowing  that everything has been virtually tested in advance and found to be working. And to come back to Boehm’s  Law: We have lower costs because we save time, since we’ll encounter fewer problems during commissioning  and the SAT and thus have fewer issues to resolve. Or, as in our example, even on the way to the SAT, you  look at the safety measures while flying. 

The widespread digitization of substations, moving away from hard-wired logic and discrete components  toward networked IEDs and software-defined functions (as in vPAC/cPAC systems), has fundamentally  changed maintenance and safety measures and ushered in the era of regular firmware updates. In traditional,  insulated substations, safety was often a matter of physical hardening and physical network isolation. With the  integration of communication networks (such as IEC 61850) and increased connectivity, these previously  isolated OT environments are now exposed to the same constantly evolving cyber threats as IT networks.  Regular firmware updates no longer serve solely to fix bugs or add new features; they have become a critical  factor in cybersecurity. Updates often contain patches for newly discovered vulnerabilities, such as Common  Vulnerabilities and Exposures (CVEs); they close potential backdoors that could be exploited by malicious  actors; and they strengthen the appliance’s defenses against cyber attacks at the highest technical level.  Neglecting these updates can lead to operational disruptions, data manipulation, or even a complete takeover  by attackers in digital substations, which is why a robust patch management strategy is an essential  component of modern network security.

However, there is also a downside: even though the necessity of regular firmware updates in digital substations  for cybersecurity reasons is undisputed, many utilities face significant obstacles and are therefore hesitant to  implement such upgrades in a timely manner. 

The main reason for this reluctance lies in the critical nature and complexity of substation operations, which  require absolute reliability and stability. Any change to a live system — including the installation of firmware  updates — carries the risk of unforeseen errors, incompatibilities with existing assets or configurations, or  unintended operational disruptions. 

Consequently, utilities must conduct extensive and rigorous tests after every firmware update, which is  anything but simple. During these tests, the specific configuration of the substation is replicated, extensive  control measurements are performed, protection concepts are validated, and seamless interoperability with  the entire system is ensured. 

All of this takes a lot of time and resources, and often requires dedicated test environments and qualified  personnel. The risk that an update will disrupt operations, even if only temporarily, often outweighs the  perceived immediate benefits for cybersecurity, leading to an overly cautious, delayed, and strictly regulated  approach to firmware deployment. 

This is precisely where virtualization offers a transformative solution to the dilemma faced by utilities regarding  firmware updates. By creating exact (or sufficiently accurate) digital replicas of substation environments,  utilities can now perform the necessary rigorous tests without disrupting ongoing operations or having to invest  in costly physical test environments for every scenario. These virtual testing environments can be scaled up  as needed, opening up the possibility of testing new firmware versions on multiple simulated substation  configurations simultaneously. Crucially, the virtual nature of these environments allows testing processes to  be automated to an unprecedented degree. 

Automated test scripts can simulate millions of operational scenarios, even performing injection of various fault  conditions, for example, and systematically verify the system’s behavior and the effectiveness of protection  and automation concepts after the update is deployed — all at a speed that is impossible with manual methods.  This comprehensive, rapid, and lower-risk validation process gives utilities the confidence needed to perform  more frequent firmware updates. This ultimately reduces vulnerability to cyber threats and ensures the ongoing  stability and safety of the grid without requiring a complete or even prolonged interruption of power supply. 

7/ Virtualization as the Foundation for Modern Substation Engineering 

The transition from hardware-centric commissioning to software-defined verification fundamentally redefines  the workflow of the plant automation engineer. By utilizing Soft-RTUs and IED simulation, engineers can move  away from bulky, expensive lab setups toward agile, virtualized environments that allow for the entire  substation to be reviewed at a desk. This shift directly addresses Boehm’s Law by identifying design flaws and  signal mapping errors – such as IEC 61850 to IEC 104 translations – during the early design phase when they  are least expensive to fix. This early involvement ensures that the final physical deployment is not a “temporary  solution” but a validated, high-performance architecture. 

This virtualization approach effectively bridges the knowledge gap between traditional electrical engineering  and modern IT-based infrastructure. By running digital twins on standard industrial PCs (IPCs) or virtual  machines, utilities gain a scalable platform for functional monitoring, which is essential for detecting  communication timing deviations and interoperability inconsistencies before they impact grid stability. This  environment allows engineers to automate millions of operational scenarios and fault conditions, providing a  level of testing depth that is impossible with manual methods. 

Ultimately, embracing virtualized testing and vPAC systems transforms the traditionally rigid commissioning  process into a flexible, data-driven cycle. It streamlines the preparation FATs and SATs by allowing teams to  share verified, “secure by default” configuration files via cybersecure cloud environments. For the engineer in  the field, this means arriving at the substation with the confidence that the system is already working as  intended, reducing on-site troubleshooting and ensuring a more reliable, stable power supply for the long term.