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.

IEC TC 57 Proposes New Work on SCD Based Substation Network Auto-Routing

IEC TC 57 Proposes New Work on SCD Based Substation Network Auto-Routing:

57/1987/DC

Proposal to develop IEC TR 61850-90-22 –
Communication networks and systems for power utility automation –
Part 90-22: SCD based substation network auto-routing with visualization and supervision support

"The scope of the proposed TR is to provide a comprehensive analysis of increased challenges encountered in the field where substation network is adopted, and to propose a novel resolution which is SCD based substation network auto-routing with visualization and supervision."

The following issues are key: Network topology auto-discovery, IED auto-detection, GOOSE/SV auto-routing, QoS and traffic engineering, Redundant path and fast recovery, Traffic validation, policing and shaping, Network resource virtualization, ...

I am happy to see that this draft proposal as been published - it will implement what I have been said for years in my seminars: SCD documents are containing a lot more than just Logical Nodes ... more to come. Stay tuned.

Click HERE for the list of National Committees involved in IEC TC 57.