Neu: Branchenempfehlung für die Harmonisierung von Ortsnetzstationen

Die Verbände BDEW und ZVEI haben am 29. September 2026 eine 16-seitige und  beachtenswerte Branchenempfehlung für die Harmonisierung von Ortsnetzstationen veröffentlicht! 

In der Executive Summary lautet der vierte Satz: "Durch die Reduzierung der Variantenvielfalt können Ressourcen geschont, Planungs- und Beschaffungsprozesse vereinfacht und Realisierungszeiten verkürzt werden."

Weiter unten: "Die Unterstützer bekennen sich mit dieser Branchenempfehlung zu einer gemeinsamen Verantwortung von Netzbetreibern und Herstellern für die Umsetzung der Energiewende. Sie wollen mit diesem Dokument Potenziale aufzeigen, um die technische und organisatorische Komplexität im Ausbau der Stromnetze zu reduzieren, die Digitalisierung voranzutreiben und die Umsetzungsgeschwindigkeit zu erhöhen ..."

Auf den Seiten 11/12 ist zu lesen: "Zur Vereinfachung der Integration könnte der Einsatz eines einheitlichen Stationsbusses geprüft werden, um Messwerte und Steuerbefehle über standardisierte Schnittstellen übertragen zu können. Dies erleichtert zudem eine Vorfertigung sowie spätere Erweiterungen. Dabei könnten Steckverbinder die aufwendige Einzelverdrahtung ersetzen. Für die Kommunikation mit übergeordneten Systemen (z. B. Netzleitsystem, IoT) wird die Standardisierung auf wenige geeignete Protokolle und einheitliche Datenmodelle empfohlen."

Hier klicken, um die Empfehlung herunterzuladen [pdf, 2,1 MB].

Spätestens jetzt wird den meisten Lesern die Normenserie IEC 61850 in den Sinn kommen! Oder?

Mit dem neuen IEC61850-Protokoll nach IEC 61850-8-3 (aktuell in der CD-Kommentierung) ist die allgemeine Kommunikation (ohne GOOSE und Sampled Values) innerhalb und außerhalb der Ortsnetzstationen ein sehr gut geeignetes Protokoll, das die einheitlichen Datenmodelle, das Engineering und die Konfiguration der Normenreihe unverändert verwendet!

Ich bin gespannt, wie die Reaktionen ausfallen!

Erste Reaktionen (sehr positiv!) sind hier zu finden.

Update on Traffic Engineering with IEC 61850

The other day I have discussed Traffic Engineering with IEC 61850. In a second post today I showed how SCL can be used to validate incoming messages.

Now I will show you in the analogy of traffic control how limits on the street are signaled. Fotos by Karlheinz Schwarz. 

First example Maximum Load Limit on a bridge: 

Second example with three limits: one vehicle at a time, max gross weight, and max speed:

Third example: max Tunnel hight 4,00 Meter

I guess you understand that IEC 61850 SCL can be used to configure signals for limits ... 

Enjoy. 

Cyberattacks Targeting OT Systems and IEC 61850

According to Security Week, "Hackers targeted operational technology (OT) systems at two private water utilities in Colorado in late August, apparently attempting to cause disruptions.

Few technical details are available, but it seems the attackers targeted industrial control systems (ICS) at the water utilities, which serve fewer than 200 people. 

A spokesperson for Colorado Governor Jared Polis told The Denver Post [paywalled] that the attackers changed equipment settings, disabled remote access and alarms, and altered pumping cycles. However, the disruptions were brief and did not affect water services or public safety."

I highly recommend small and all electric power utilities to pay attention to this situation and improve the cyber-security of the power system devices like SCADA, control, protection, RTUs, ... changing equipment settings could cause dangerous situations like blackouts, ... 

IEC 61850 information models can play an important role when somebody wants to change settings of a process control signal. The other day I used the IEDScout from Omicron to limit the setting value of a CDC=APC (Analogue Setting) structured setting. I set the maxVal to 1,000 (in the server) and tried with a second instance of IEDScout as a client to set the process value to Oper.ctlVal > maxVal ... the server responds with an MMS Write-Error and a Report "Inconsistent-parameters". The server did not accept a value outside of the maxVal and minVal. The process value did not change at all!

This possibility is a standardized (kind of "security") function incorporated into the CDC=APC !!!

Sure, the maxVal and minVal should be blocked for online changes! That could be configured in the CSL file as well.

So, IEC 61850 and especially SCL provide more than just a communication configuration ... many function related definitions are defined for the various common data classes!!

Let me know in case you want to further discuss this.

P.S.: After I published the above post I came across the following LinkedIn post   

CVE-2025-6625 — Improper Input Validation
> Crafted FTP command can take the controller offline
> CVSS 7.5 — network reachable, no auth, availability hit
> Energy, water, manufacturing fleets still run these PACs

Input VALIDATION is a crucial issue ... YES!

P.S2.: I just read another post on LinkedIn regarding DNP3 message validation. Interesting.

P.S3: Update

What is IEC 61850-8-1 MMS Compared to IEC 61850-8-3 DMS?

The paper "The Standard Message Specification for Industrial Automation Systems ISO 9506 (MMS)" has been downloaded 6,691 times from the ResearchGate ... seems to be an interesting document. 

Now, since we are working on a new protocol standard for IEC 61850-7-2 Client/Server communication (IEC 61850-8-3, DMS, Direct Message Specification), the question is: What is the difference between MMS and DMS?

Here are some answers:

DMS will be an alternative protocol for MMS ... with WebSocket connectivity, ASN.1 message schema, ASN.1 JER JSON encoding, ... very simple ... a straight forward from IEC 61850-7-2 ACSI (abstract messages) to concrete messages ... 1:1 ... no tricks ...

There are a few crucial aspects: (1) MMS as a standard that needs outdated OSI upper layers, (2) MMS is very complex and does not easily fit for IEC 61850-7-2 ACSI ... needs a tricks mapping to MMS in IEC 61850-8-1, (3) DMS communicates over WebSockets (bidirectional), (4) DMS uses JSON for message encoding (or DER binary) many tools are available, (5) the message schema of DMS is far simpler than the MMS message schema ... even both are using ASN.1 as schema notation, (6) MMS is not a good friend of many experts, (7) the Proof of Concept for RTI2 (Netherlands DSOs) is the basis for IEC 61850-8-3 ... and available at GitHub ...

From an system point of view (engineering, SCL, Models, abstract services, ... application functions, ...) there is no difference between the two protocols. From a smart implementation point of view the "stacks" could have an API that is independent of the protocols. There needs to be a tiny layer that decides if, e.g., a Report (with the payload from the application models) is wrapped with MMS or DMS ... for DMS there are two options: JER (JSON) and DER (binary) ... from a DMS stack point of view there is one line of code (!!) that is needed to encode in JSON or binary ...

Of course, the MMS message syntax and encoding are not compatible with DMS message syntax and encoding. BUT: they both carry the same payload!! ... thanks to the huge list of standardized "Signals" (models).

Both solutions run on TCP/IP ... there may be multi-protocol IEDs available some time down the road ... as we see today that many IEDs are supporting multiple protocols ... 

People asked me: Why did you not have this solution developed earlier?!? I developed something with my granddaughter when she did her Bachelor at KIT ... check my blog with some historical discussions

IEC published the Committee Draft (57/2980/CD) on IEC 61850-8-3

The next step of the publication of IEC 61850-8-3 has been reached

Yesterday (2026-09-04) IEC published the Committee Draft (57/2980/CD) on

"Communication networks and systems for power utility automation –
Part 8-3: Specific Communication Service Mapping (SCSM) –
Mapping to Direct Message Specification (DMS), JSON Encoding Rules, and WebSockets"

The commenting period closes on 2026-10-30 ... very soon.

All experts that are members of the IEC TC 57 National Committees can access the document and provide comments online.

My experience with the editing processing tool (OSD - Online Standards Development) is very positive: After I finished the editing on Monday (2026-08-31) IEC could easily publish the CD ... the document follows automatically the format of IEC ... because it is an IEC (ISO) tool ... perfect.

The crucial definition is the ASN.1 message schema that is used to code and decode messages (see see below for a link to the ASN.1 schema used in the RTI2 open-source software):

The committee draft (57/2980/CD) is based on the Netherlands Netbeheers Proof of Concept for RTI2 (real-time interface). Netbeheer is supporting the implementation as open-source software under GitHub. The message syntax of the committee draft is the latest ASN.1 module. The ASN.1 version at GitHub is a pre-version of the official version:
General: https://github.com/Netbeheer-Nederland/iec61850-websocket

Direct Access to the ASN.1 Schema: https://github.com/Netbeheer-Nederland/iec61850-websocket/blob/main/src/ws61850/asn1/schema/ws_iec61850_tpaa_full.asn

Please check my blog for additional information on IEC 61850-8-3.
Any question? Please let me know.

IEC 61850 for Newbees - Traffic Engineering with IEC 61850-6 (SCL)

I agree: The standard series IEC 61850 is quite comprehensive ... some believe it is complex. Ok. What can I do to help you getting a better understanding? I will try to help you. 

Today I will show how IEC 61850-6 (SCL, System Configuration Language) can be used for traffic engineering - traffic means: "signals" are communicated back an forth: analogue measurements, status measurements, control, configuration, event-driven reports, event-driven logs, ... start and stop of event recorder, trip-signals, ... in IEC 61850 "signals" are named and a binding of an instance to the application process (e.g., Bay1 Circuit Breaker 2) is specified ...

I am using a brief prose language ... this description could be transformed to an SCL compliant (machine processable ) XML file.

The many "signals" are travelling from a source to a destination ... let's say the following valid (allowed) routes are:

1. A->B,
2. B->A,
3. V->A,
4. A->C, 
5. D->E, 
6. R->S, 
7. R->A

Each letter is representing a source or destination of the "signal" flow. The "->" is representing one of the specific "signals" standardized in IEC 61850. In the first route A sends an operate to B and B is reporting back to A a changed status information ...

In SCL we can configure now for each route in detail the sources, destinations, strongly typed "signals", communication services, ... The SCL compliant System Configuration Description (SCD) would list all details on all routes ... 

The source knows by the SCD document which "signal" is to be sent (when and how) to which destination. The destination knows by the SCD document which "signal" it receives (from which device, when and how).

What else can we do with the SCD file?

1. A tool could check if all source and destination (devices) are specified ... a source A is configured to send a signal to B ... Is B at all specified? Maybe it was forgotten.
2. A tool could check if for all source and destination devices the addresses are configured. 
3. Another tool could check if all traveling "signals" (messages) are specified in the SCD document. A "signal" that travels during online operation from X to B (here X tries to connect to B) is not specified and thus NOT ALOWED. The tool could rase the red flag telling the system engineer that an unknown device X is active on the network. 
4. ... many other possibilities are listed in the following figures from my seminar slides (some 10+) years old.

I hope you got an impression what IEC 61850-6 (SCL) could provide.

SCL is the backbone of IEC 61850!

Check HERE for a crucial use-case for SCL (cyber security ...).

Let me know if you have a question on this post.
P.S: Update

Sample of an IEC 61850-8-3 request-response message sequence using JSON

The standard IEC 61850-8-3 under preparation will use ASN.1 JER (JSON) encoding. In order to understand, what that means check the following message sequence of the service (copied from the Wireshark trace, without WebSocket, TCP/IP, ... headers).

Note that you can use the Open Source Software of the PoC (Proof of Concept) to let client and server exchange real messages ... enjoy!

getLogicalDeviceDirectory

    { "request": {

            "associateId": "cp1",
            "invokeId": 1,
            "service": {
                "getLogicalDeviceDirectory": {
                    "ldName": "LD0"
                }}}}

    { "response": {
            "associateId": "cp1",
            "invokeId": 1,
            "service": {
                "getLogicalDeviceDirectory": {
                    "lnName": [
                        "LLN0",
                        "LPHD1",
                        "DWMX1",
                        "DGEN1",
                        "MMXU1"
                    ]}}}}

setDataValues

   {"request": {

            "associateId": "cp1",
            "invokeId": 56,
            "service": {
                "setDataValues": {
                    "ref": {
                        "ref": "LD0/LLN0.Mod.ctlModel",
                        "fc": "cf"
                    },
                    "dataAttrVal": [
                        {
                            "data": {
                                "enumerated": "2"
                           }} ]}} }

    {"response": {
            "associateId": "cp1",
            "invokeId": 56,
            "service": {
                "setDataValues": null
            }}}

    

Any question? Guess there is likely no need to ask, what this is ...

Search for "8-3".

IEC 61850 for Power Quality — solving the PQA integration problem

IEC 61850 has solutions for a lot of systems where currents and voltages are crucial ingredients of a system. Click HERE for a list of use-cases.

One of the practical challenges for TSOs (Transport System Operators) and DSOs (Distribution System Operator) is the integration of Power Quality Analyzers into utility monitoring systems. 

Traditionally, each PQA (Power Quality Analyzer) manufacturer has its own communication interface, data structures and software tools, so integrating equipment from different vendors often requires developing and maintaining vendor-specific drivers, especially when detailed PQ parameters and events are involved. IEC 61850 offers a good way to address this problem. 

Vendors like SATEC offer PQA ... e.g., PM180 is an example of a Class A Power Quality Analyzer where IEC 61850 is used not only for basic electrical measurements, but also for Power Quality information. PQ parameters, harmonics, frequency-related information, events, alarms and status can become part of the IEC 61850 information environment instead of remaining accessible only through a proprietary PQA interface. 

Client/Server (Reporting etc.) can be used for measurements, PQ parameters, events and monitoring, while GOOSE provides fast exchange of event and automation information. PMU functionality is also available for synchronized measurement applications. For a TSO or DSO, the key benefit is architectural: instead of integrating every new PQA through another proprietary driver, Power Quality devices can become part of the same IEC 61850 infrastructure already used for other substation IEDs.

Click HERE for accessing the corresponding ICD document (IED Capability Document).

The new IEC 61850-7-440:
Basic communication structure –
Compatible logical node classes and data object classes – Power quality metering

will contain the following PQ specific Logical Nodes (currently in IEC 61850-7-4 Ed2.1):

• Flicker measurement Name: MFLK 
• Harmonics or interharmonics Name: MHAI .
• Non-phase-related AC harmonics and interharmonics Name: MHAN 
• Metering single phase Name: MMTN
• Metering 3 phase Name: MMTR 
• Frequency variation Name: QFVR 
• Current transient Name: QITR 
• Current unbalance variation Name: QIUB
• Voltage transient Name: QVTR 
• Voltage unbalance variation Name: QVUB 
• Voltage variation Name: QVVR

Other vendors have similar PQAs ...

Siemens PCS7 (TIA) PowerControl Station Gateway connects PLCs with IEC 61850 IEDs

In a post earlier today I wrote: "It does not make sense to decouple power systems from big(ger) applications." ... this reminded me to discuss another use case ... factory automation to substation ...

Siemens offers PLCs with the PCS7 family. They have developed gateways that bring the substation closer to the power user ... 

PCS 7 PowerControl Station Gateway connection of a SIPROTEC 5 protection device (speaking IEC 61850!)

The brochure states at the beginning: "In addition to the demanding process automation requirements in many industrial plants, it is also necessary to integrate the medium-voltage power supply switchgear into a complete automation system.

Components of such plants are electrical consumers with high energy requirements (factories, chemocal plants, ...). Individual consumers are monitored and controlled via protection devices, also known as IEDs (intelligent electronic devices)."

So, my statement on the post earlier today has been confirmed! 

The same is available for the integration of a substation into a Siemens TIA (Totally Integrated Automation) ... TIA Station Gateway: excerpt of that page:

"With the new IEC 61850 server functionality, you can extend your station gateway integration allowing you to reliably publish process data directly to IEC 61850 clients via GOOSE Publisher or MMS polling and reporting with a high degree of performance. Whether protection systems, instrumentation and control or automation environments: The publisher ensures that events are quickly transferred and facilitates fixed data models and the highest degree of interoperability."

WOW.

How IEC 61850 Leverages Mine Thermal Energy Storage

Bruno Silveira posted on LinkedIn an very interesting article about using IEC 61850 to a full extend!

He shows, that decarbonizing regional energy networks requires coupling thermal district networks directly with electrical distribution grids.

Excerpt: "To maximize operational responsiveness without jeopardizing critical grid stability or operational technology (OT) security, MTES (Mine Thermal Energy Storage) assets must interface directly with modern IEC 61850 Substation Automation Systems (SAS)."

This is the right view of applications being part of the electrical system: either as source or sink of electrical power!! Currents and voltages are the crucial ingredients of the energy storage systems ... electric storage or electric or ... whatever. Always the same need: coupling storage networks directly with electrical distribution grids.

It does not make sense to decouple power systems from big(ger) applications.

Click HERE for his article with an overview.

IEC 61850 covers applications inside substations AND beyond substations

IEC 61850 is applicable for general automation applications as well as for electric power delivery systems. The following lists give an impression of what kind of domains are taken into account so far ... more to come:

Information models and exchange for

• real-time and near real-time applications  (pub/sub: GOOSE, Sampled Values)
• protection
• monitoring, supervision, and control (client/server TCP/IP and WebSocket)
• substation and feeder equipment
• substation-to-substation
• substation-to-control centre
• power plant-to-control centre
• distributed generation
• distributed energy resources
• micro grids
• metering
• power quality
• condition monitoring
• hydro, steam, gas power plants
• wind generation plants
• data centers
• …

System Configuration and engineering

• System Configuration Language (SCL)
• Basic Application Profiles
• top-down-engineering (model-based engineering)
• - …

These lists demonstrate that the standard series IEC 61850 covers applications inside substations AND beyond substations. One crucial question remains: What are the logical nodes and data objects ... from which parts of the standard series IEC 61850 are required for a specific application domain?
The answer is here: ask me.

HERE you can find a sample model for an IEC 61850 Profile for Distributed Energy Resources Supporting IEEE 1547 [pdf] ... quite interesting ...

You may search the web for MICS (IEC 61850 model implementation conformance Statement) ... 

Note that substations are very crucial components of the interconnected electric energy systems.

Let me know if you need some help.

IEC 61850: THE SECRET LANGUAGE KEEPING OUR LIGHTS ON!

Maybe you have not yet heard what IEC 61850 is all about! If you have no glue what it is, read a very great article from one of the IEC 61850 champions: Dr. Alex Apostolov (Omicron).

Click HERE to follow the post on LinkedIn with a link to the article.

You should read that article ... it is worth to read.

Excerpt ... from cover page:

"It’s like flipping a switch and turning on a light. You don’t think twice about it. Behind that simple flick of a switch is a silent promise: a commitment embedded deep within the grid. It’s not just wires and relays. It’s trust, engineered layer by layer, by minds that understand that milliseconds matter. This promise is powered by a language that’s not English or Spanish, but a digital dialect. It’s called IEC 61850, a standard whispering in the background, in real-time harmony. It’s already transforming the grid by streamlining design, accelerating testing, and enabling real-time intelligence that’s dynamic, digitized and decentralized. But first, let’s decode what it is, and why milliseconds matter more than ever."

"Dr. Alex Apostolov shares (in a podcast) how milliseconds, not megawatts, are shaping the future of protection engineering."

Remember: Protection engineering is very crucial for our living!

IEC 61850-90-3: Using IEC 61850 for condition monitoring diagnosis and analysis

IEC TC 57 is working on a new part of the IEC 51850 series (public available specification; draft 287 pages):

PRECD PAS 61850-90-3 ED1: Using IEC 61850 for condition monitoring diagnosis and analysis

Excerpt from introduction:

"The CMD (Condition Monitoring Diagnosis) which diagnoses power grid health status has been one of the major issues to improve the reliability of the power system by preventing a potential failure in advance. Since too many different information modelling, information exchange, and configuration techniques for CMD in various forms from many vendors are currently used, they need to be standardized within the IEC.

IEC 61850 is intended to be used to communicate with the condition monitoring equipment. A seamless communication with the sensor network is also desirable."

Here is an excerpt of the various use-cases (Power Transformer):

Some Logical Nodes for power transformer monitoring:

1. SLTC Tap-changer supervision
2. SVAM Vibroacoustic OLTC supervision
3. SDBR Dehydrating breather supervision
4. SPRD Pressure relief device supervision
5. SBHR Buchholz relay supervision
6. SDIV Diverter switch supervision
7. SFIL Insulating liquid filter supervision
8. SNPS Nitrogen preservation system supervision in this picture)
9. SMDU OLTC motor drive unit supervision
10. STRQ Supervision of OLTC torque
11. SMCI Motor current index supervision
12. SVIN Vacuum interrupter supervision
13. YLTC Tap-changer control
14. SPTR Power transformer supervision
15. SPTW Supervision of winding power transformer
16. SPTC Supervision of core power transformer
17. SIML Supervision of liquid insulation medium
18. ....

Other use cases are: 

• Switchgear
• Underground cable (UGC)
• Overhead line (OHL)
• Vibration monitoring

In case you are interested in supporting this work, let me know.

How are IEC 61850 Information Models related to Functions?

The common understanding of information is crucial for the understanding of the related functions that produce, consume, and exchange the information. Information is always "bound" to functions ... no function - no information.

Let's have a look at this function: 

Supervision of a temperature value ... report an alarm to a well known entity when the temperature change rate reaches a value of xyz ... this is the FUNCTION. Now we model it with IEC 61850:

The temperature supervision is modeled in the logical node MySTMP1. We use the data objects Tmp (reported every x minutes), RteAlm (reported when the value of the RteAlmSet is reached, e.g., 0.5 K/s).

This "function" is described in an SCL document ... here the MySTMP1 is bound to a topology (SSD), e.g., room temperature in building so-and-so, the reports are sent to the SCADA system mySCADA-client, ... the factory acceptance test can more or less be automated based on the SCL document.

The IEC 61850 STMP logical node model follows the temperature supervision function!! 

The function was there well before IEC 61850 was born!

IEC 61850 standardizes the information shared with a real function.

The following diagram shows the basic modelling approach in IEC 61850:

• IEC 61850-7-2 defines the foundation
• IEC 61850-7-3 defines the common data classes: MV for measurements, SPS for single point status, and ASG for analogue sessings.
• IEC 61850-7-4 defines the logical node and data object classes.

More details will follow ... stay tuned.

The real challenge with IEC 61850 is: You likely get the feeling when you start reading hundreds of pages: unable to see the wood for the trees.

Let me know if you need help ... after 30 years I can support you.

Is there a problem to connect devices directly to the Internet?

The answer to this question depends ... it is likely that still today responsible people belief that it is no issue ... why?

A well know authority in the field of protecting critical infrastructure reminded people to read the following report (10 years old!):

Project SHINE (SHodan INtelligence Extraction) Findings Report.

I highly recommend you to read the report ... and take it into account in your daily business.

Is IEC 61850 an old Standard?

What do you think? It depends ... IEC 61850 is a standard series of many parts ... published in different years ...

The other day I was reading that somebody on LinkedIn beliefs that IEC 61850 is old ... Oops. Here is what I answered:

I was involved in the development of MMS (ISO 9506, starting mid 1980s), later in ICCP (TASE.2, IEC 60870-6, using MMS), then IEC 61850 (starting 1995, using as well the "old" MMS). 

The AC interconnected power systems have been developed more than 130 years ago ... and improved since then ... AND: Yet we do not complain that they are OLD. They have done a great job. Old wine may be better than young wine ... or?

The standard series IEC 61850 has many aspects to consider: 

• System Configuration Language (SCL, IEC 61850-6) is brand new! 
• GOOSE and sampled values are brand new! 
• The many standard "signals" like MMXU.Hz for frequency measurement are old in the sense that frequency is a physical given.
• There is something we may call "old": the use of the "old" MMS as the protocol for client/server communication according to IEC 61850-8-1 (-8-2). ok.
• There is an alternative new web-based solution under way: IEC 61850-8-3 (a new protocol for client/server in IEC 61850 ... WebSocket transport, ASN.1 message schema, ASN.1 JSON encoding rules, and ASN.1 DER encoding rules).

If you want to learn why the Netherlands DSOs initiated the IEC 61850-8-3, check HERE.

A great reply says: "The transport choice is what stands out: MMS was never reachable from a browser, WebSocket with JSON encoding is, which changes what client tooling can be without an install."

There are other brand new parts of IEC 61850 just published, e.g., IEC 61850-7-410 for hydro, gas, and steam power plants.

New Edition published: IEC 61850-7-410 for Hydroelectric Power Plants, Steam and Gas Turbines

The new edition of IEC 61850-7-410 has been published (this is Edition 3.0):

Communication networks and systems for power utility automation - Part 7-410: Basic communication structure - Hydroelectric power plants, steam and gas turbines - Logical node classes

IEC 61850-7-410:2026 specifies the logical node classes for use in the domain of hydroelectric power stations, steam and gas turbines. 

Read more details and access a sample HERE.

The standard defines a huge number of details ... excerpt of one group of LNs: 

Logical nodes for primary equipment

The IEC_61850-7-410.NSD.2024A3 light code component can be downloaded HERE. The light code components (XML) lists all logical nodes and data objects, for example:

LN: Penstock burst protection Name: KPBP

Unfortunately the semantic of the "names" are only available in the full code component ... comes with the the standard ... for sale.

Trick: The names and brief description for the logical nodes come with the sample (as shown above).

Which and how many IEC 61850 devices are successfully tested for conformance?

That's a good question ... that could easily be answered. Really! How? Let me explain:

The organization that is in charge for IEC 61850 conformance tests is the UCA International Usersgroup (UCAIUG). This organization has defined the test cases ... and issues certificates after a product has been positively tested by an authorized UCAIUG test lab like DNV.

The UCAIUG maintains a data base of certificates issued ... the data base has a lot of filter to search for some specific services a product supports. The following figure shows an excerpt of  a search for server devices that support IEC 61850-7-2 Setting Group Control services: 826 clients/server ... 656 server ...

Click HERE for the above search.

It takes some time to understand the filter and options ... it is a huge tool!!

Below is the filter for servers only (click on the link to the left):

To understand the details of the applied test cases, you have check with the UCAIUG test specifications ... example for Setting Group B4 and B4+ ...

1,682 devices (Client, Server, Merging Units, ...) have been tested positively ... they are listed in the data base.

Click HERE for the list of Testlabs for IEC 61850.

Perfect! Drop me an email or post a comment to this post.

Enjoy.