In conventional IEC 61850 engineering, errors surface at the worst possible moment: during commissioning, when hardware is on-site, teams are deployed, and project schedules are under pressure. The top-down engineering process — formalized in TR IEC 61850-90-30:2025 and TR IEC 61850-7-6 (Ed. 2) — moves that moment dramatically earlier: to before a single IED is selected, before a contract is signed, before any physical device exists. Fourteen European TSOs, including Elia and 50Hertz, signed a Common Statement in 2023 endorsing this approach as the direction for digital substation engineering. The first article in this series covered why the industry is moving in this direction and what drove the fourteen-utility consensus. This article explains the mechanics: what happens at each of the five steps, what files are exchanged, and why the process produces better outcomes than what came before.
Why Bottom-Up Falls Short
The conventional IEC 61850 process starts with the IED. You obtain an ICD file from a vendor, build the system around what the device can do, and communicate requirements through PDF specification documents — which each vendor reads and interprets independently. By the time mismatches surface, the equipment is procured, the project is committed, and corrections are expensive. The top-down process reverses this sequence entirely: functional requirements are defined first in machine-readable format, validated without hardware, and only then handed to vendors as a structured specification they can process in their own tools.
The Five-Step Process at a Glance
The process consists of five steps, each producing a structured file that becomes the input for the next. Three categories of tool are involved: a System Specification Tool (SST) operated by the utility engineer, an IED Configuration Tool (ICT) operated by the IED vendor, and a System Configuration Tool (SCT) operated by the utility engineer again. Here is how they connect:
flowchart LR
A["Step 1\nSystem Profiling\nFSD / ASD\n(SST)"] -->|"ASD files\n6-100 namespace"| B["Step 2\nSystem Specification\nISD / SSD\n(SST)"]
B -->|"SSD\nto simulation"| C["Step 3\nSimulation &\nValidation\n(Simulation Gate)"]
C -->|"fail:\nrevise SSD"| B
C -->|"pass:\nvalidated SSD\n+ ISD to vendor"| D["Step 4\nIED Capability\nprocess ICD\n(ICT)"]
D -->|"process ICD + SSD"| E["Step 5\nSystem Configuration\nSCD\n(SCT)"]
E -->|"SCD"| F["IED\nDeployment"]
style C fill:#d4f4dd,stroke:#2d9e5a
All files use SCL format with 6-100 namespace extensions. Step 3 may involve an iterative cycle — simulation is integrated into specification development, with the engineer specifying, testing, and refining until behaviour is confirmed. ISD files go to vendors only after the specification has been validated.
Step 1: System Profiling — Vendor-Free Function Templates
Step 1 produces the functional building blocks used throughout the project. The system engineer creates reusable templates — called Function Specification Descriptions (FSD) and Application Specification Descriptions (ASD) — without any reference to a specific IED manufacturer or product line.
An FSD describes a single protection or control function: its logical nodes, signals, and required data attributes. An ASD assembles multiple FSDs into a complete application — for example, a distance protection application (P21) or a circuit breaker control application. The ASD also carries:
- Data flow — how signals move between functions, annotated with service type (GOOSE, SMV, or Internal) and direction
- BehaviorDescription — the functional logic, written either as plain-text requirements or formalized as IEC 61131-3 Function Block Diagrams (FBD)
- ProcessResources — placeholders for signals expected from other applications not yet combined into the project
That last element matters. When a protection application expects a trip command to reach the circuit breaker, that connection cannot be fully resolved within a single ASD — the CB application is a separate template. So it is modeled as a ProcessResource placeholder, and resolved in Step 2 when both applications are combined.
Functions within an ASD are grouped using AllocationRoles — logical roles such as "PIU," "Bay Controller," or "Protection." An AllocationRole defines what a logical IED will do; it does not name a physical device or manufacturer. At this stage, no vendor is involved at all.
In the Elia proof-of-concept, demonstrated in December 2023 using Helinks STS (Helinks/Alvexis), the team created two ASD templates: a circuit breaker application with four allocation roles, and a P21 distance protection application with IEC 61131-3 trip logic. Both templates were entirely independent of any vendor's product capabilities.
Thomas Sterckx of Elia summarized the principle: "You can really do it in a technology-independent way. It's also a vendor-independent specification."
Step 2: System Specification — Machine-Readable IED Requirements
In Step 2, the engineer instantiates the ASD library templates into a concrete project. When two applications are combined, their ProcessResources are resolved: the protection application's expected trip-to-CB signal is now mapped to the actual function in the CB application. The system begins to take shape — still without hardware.
For each physical IED in the project, the engineer generates an IED Specification Description (ISD): a machine-readable file that replaces the traditional stack of PDF requirements documents. An ISD contains:
- The expected data model: logical devices, logical nodes, data objects, and attributes (specified via DOS/DAS elements)
- DataFlow specifications: what signals the IED must receive and send, with service type and SourceRef UUIDs
- BehaviorDescriptions: the required functional logic the IED must implement
- Physical interface and naming expectations (LNodeSpecNaming elements)
One ISD can be sent to multiple vendors simultaneously. Each vendor processes it with their own IED Configuration Tool — not by reading and interpreting text, but by machine-parsing the SCL file. The responses come back in a structured, comparable format. As Thomas Sterckx explained: "Instead of giving [the IED supplier] a large series of written documents, you can give him something that is machine-readable, that he can process inside his own tool."
The output of Step 2 is twofold: ISD files for each IED, and an SSD (System Specification Description) capturing the complete project specification — which also serves as the input to Step 3. The SSD proceeds immediately to simulation. The ISD files, however, are not sent to vendors at this point: they are dispatched only after the specification has been validated through simulation (Step 3, or at the end of the iterative simulation cycle). This sequencing is intentional — submitting an ISD to a vendor before validation risks locking in a specification that has not been confirmed to work as intended.
Step 3: System Simulation and Validation — Testing Before Hardware Exists
This is the step that defines top-down engineering.
No hardware. No vendor selected. No contract signed.
The SSD or ASD is imported into a simulation tool, and the system behavior is tested against the functional specification — entirely in software. What makes this possible is the formal structure of the ASD itself. A PDF specification describes protection logic in natural language. An ASD encodes the same requirements as IEC 61131-3 Function Block Diagrams — a representation that tools can parse, render, and execute directly. This is not simulation in the approximating sense; it is execution of the specification as written.
Two views are available. The first is a data flow graph: process resources (inputs) on the left, functional logic in the middle, outputs on the right. All signal paths are visible, including service type and direction — the engineer can trace any input to any output before a single IED is configured. The second is behavior execution: where the ASD contains IEC 61131-3 FBD logic, the tool renders it and allows interactive manipulation. Set an input value to active — the signal propagates through the function block diagram in real time, and you observe which outputs fire.
For structured validation at scale, scenarios can be defined as tabular test cases: one row per scenario, with predefined input values and expected output values for every signal in the application. The tool executes the sequence, flags discrepancies, and captures timing — allowing verification of time-dependent behavior where millisecond precision matters.
Importantly, simulation is not necessarily a one-pass gate at the end of specification work. As Jackson Moore described: "this can be an iterative process — the testing can occur as the design is still being developed." In practice this means the engineer may specify a portion of the ASD or SSD, simulate it, refine based on the results, and simulate again — cycling through specify → simulate → refine until the behaviour is fully confirmed. The simulation tool is integrated into the specification workflow, not appended to it.
The output of Step 3 is not a new file. It is a verified specification — the same SSD or ASD, confirmed to behave as intended. At this point the ISD files are ready to go to vendors (Step 4): they carry a specification that has been executed and validated, not merely written. The economic argument is direct: a specification error found at Step 3 costs an afternoon of rework on an SCL file. The same error found during commissioning — after procurement, after mobilisation, with hardware on-site and teams deployed — costs orders of magnitude more. The technical mechanism is equally direct: because behavior is formalized in IEC 61131-3 rather than in natural language, it can be executed by a tool independently of any specific device.
Jackson Moore, who demonstrated simulation in the Elia proof-of-concept: "Many potential errors can now be identified much earlier in the engineering process — and are comparatively much cheaper and easier to fix."
Step 4: IED Capability Description — The Vendor Responds
The ISD file goes to the IED manufacturer, who imports it into their IED Configuration Tool. The tool automatically cross-references the specification with the device's actual data model — identifying which logical nodes and data objects are available, which need to be created, and where the vendor's naming conventions differ from those in the specification.
The output is a process ICD: a standard ICD file extended with mapping information from the 6-100 namespace. It explicitly documents:
- How each logical node in the specification maps to the vendor's actual LN (
mappedLnUuid,mappedDoName) - ExtRef placeholders (
extRefUuid) linked to SourceRef entries in the specification — these will be resolved automatically by the SCT in Step 5 - Any BehaviorDescription deviations: if the vendor cannot implement the specified logic exactly as written, that deviation is documented in the file rather than left implicit
- UUID-based traceability linking the process ICD back to the originating SSD and ISD via the
SourceFilesheader entry
Vendors have two implementation options. They can retain proprietary naming while documenting the full mapping — maximizing backward compatibility with existing toolchains. Alternatively, they can import the unified data model from the specification, adopting the names exactly as specified — maximizing interoperability, at the cost of more adaptation work within the ICT.
In the Elia PoC, Cedric Harispu demonstrated this step using Siemens DIGSI 5 with a 6MU merging unit and a 7SA87 distance protection relay. DIGSI 5 automatically recognized the logical devices from the ISD, handled the LNode-to-LN mapping, and produced process ICD files for both devices — including creating GOOSE input entries that were not part of the default device configuration.
The critical outcome: the engineer receives a machine-readable response. Discrepancies between specification and vendor capability are explicit, traceable, and documented — not buried in an email exchange.
The process ICD is not only "the vendor's answer." It is designed to enable automated verification on the user's side. Once the process ICD is received, the SCT can automatically compare the vendor implementation against the original specification — flagging unmapped signals, naming deviations, and BehaviorDescription gaps without manual inspection. As Thomas Sterckx stated: "this process ICD also allows you to automate the validation step on a user's side — to validate what you have received from an IED supplier."
Step 5: System Configuration — Automated SCD Assembly
The system engineer receives process ICD files from all vendors and imports them into the System Configuration Tool. The SCT reads the mapping information from the 6-100 namespace and automates the assembly of the final SCD.
Specifically, the SCT:
- Creates IED instances from the process ICD templates
- Resolves SourceRef entries from the specification into concrete ExtRef links, using the
extRefUuidmappings the vendor provided - Generates datasets, GOOSE and SMV control blocks, and communication parameters
- Flags any unresolved signals — where a specification element was not covered in the process ICD
In the Elia PoC, importing two process ICD files (Siemens PIU and Siemens distance protection relay) into Helinks STS populated a GOOSE matrix with subscriptions, generated control blocks with datasets for position and trip signals, and produced a complete communication configuration — the 28 ExtRef entries in the PIU IED were resolved automatically, and GOOSE control blocks appeared where previously there were none.
SCT tools that support process ICD import and automatic SourceRef binding resolution — such as Tekvel Park — can perform this assembly with minimal manual intervention.
The degree of automation at Step 5 is directly proportional to the quality of work in Steps 1 through 4. A complete ISD, a well-executed process ICD with full mapping, and a validated BehaviorDescription from Step 3 combine to make Step 5 largely automatic. Any gap in those upstream files translates directly into manual configuration work here.
Following SCD export, the file is returned to the IED vendor for final device loading. In the Elia PoC, the SCD was imported into DIGSI 5 and verified in a Siemens Digital Twin environment — two virtual devices confirming correct sampled value reception, GOOSE subscription behavior, and data model naming consistency before any physical hardware was touched.
What This Changes
Top-down IEC 61850 engineering changes three things for the practicing engineer. Specification errors are caught during the design phase — before procurement decisions, before vendor commitments, before any hardware is on-site. Interaction with IED vendors becomes structured: an ISD replaces PDF documents, a process ICD replaces informal responses, and the entire exchange is machine-readable and traceable. And vendor selection becomes genuinely competitive: one ISD sent to multiple vendors produces comparable, structured responses that can be evaluated on technical merit.
Thomas Sterckx of Elia stated it directly: "You can now test what you have engineered before it gets implemented in a device. So many potential errors can now be identified much earlier in the engineering process."
The technical standards are published. The tooling exists. The procurement process is running at Elia. The next article in this series examines how the ISD format changes the IED procurement and tendering process in practice.
Sources
- Thomas Sterckx, Yannick Thiessoz, Jackson Moore, Cedric Harispu — IEC 61850 Top-Down Engineering PoC Webinar (Elia Group, December 2023)
- Elia Group — Common Vision for IEC 61850 Top-Down Engineering (2023)
- TR IEC 61850-90-30:2025 — Communication networks and systems for power utility automation — Part 90-30: IEC 61850 system engineering guidelines
- TR IEC 61850-7-6:2024 (Ed. 2) — Guidelines for IEC 61850 system and project management