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.