How to Exchange a Voltage Measurement with IEC 61850?

As discussed before you will find a reasonable example to learn the benefits of applying IEC 61850.
Let's look at a voltage measurement:



According to IEC Electropedia we find many names for the same semantic: voltage, Spannung, spenning, ... Ok. These help humans to understand what we are talking about. But what about machines (controllers, SCADA systems, ..)?
They have to use a data type (int16, int32, float32, ...) and a reference (address ...) for a specific protocol like Modbus. Each vendor will likely use different types and addresses.
What's about the scale in applications that use integer? Is the scale known when you read the value of a voltage? Do you know the offset or the multiplier (V, kV, mV, ...)?
How do you know where the measurement is taken in the electrical system (location in the single line diagram)?
Answers to these questions may be found in a set of documents sitting on a shelf or on someones computer - hard to find out if the owner is on vacation.
With IEC 61850 we have a model that could be implemented so that all these details are always accessible online from each device that is a source of measurements:



Phase A voltage has a standard name "MMXU.PhV.phsA" with the value, quality, timestamp, units, and scale. These names are used all over in any IEC 61850 device.

IEC 61850 services allow to retrieve the MMXU model and read the values:



The device has all information to interpret the voltage value for phase A.

Finally we need to know where the value is measured in the single line diagram. IEC 61850-6 (SCL) provides the solution specified as an SCL file (simplified SSD - Substation Specification Description):


The above voltage could be designated as follows:
MySub_400kV_3A63_BayFunction_ABC/ACMMXU1.PhV.phsA

The value is located in the device "BayController". The device is communication wise identified by an IP Address.

This information really exposes all information needed to interpret a measurement. 

Note that this name needs not to be communicated when the value is reported cyclically or issued by a limit change.The report message could only carry the value, quality and timestamp.

The SCL file has all information to configure the whole system and the devices.

Any question?

Hope you have learned this: IEC 61850 goes very far beyond a protocol! We only need the protocol when we retrieve the selfdescription or read out or report the values.

And: the nice thing is that any device that implements the standard uses the same model, configuration, and services. What else do we need?

If we would apply just a protocol like Modbus then most of the information exposed (directly from the device) through the standard IEC 61850 would have to be stored in paper docs or excel sheets ... 

Are Object Names like “CircuitBreakerMainStreet” a Security Problem?

Security is a very crucial issue in the power management and automation. There are standards and other specifications that help to “close” the automations, information and communication systems. Several blog posts discuss these issues.

In a discussion recently the problem with semantic names like “CircuitBreakerMainStreet” for process information (signals) was understood as crucial. Would such names make it easier for somebody to attack a system? Why should the problem be in the Name? If you keep the doors to your device or engineering system wide open – you should not be surprised if your system will be hacked and the infrastructure be damaged.

Is there really a difference (from a security point of view) if the identification is “CircuitBreakerMainStreet” or “Staus1829” or just “1829”? There would be an issue if somebody could retrieve the name from the device by a “too open” communication protocol. Even with IEC 61850 it should be prevented that everybody could just retrieve the self-description. Keep the door to the model closed … allow only the configuration engineer to access it. This would require to implement IEC 62351-8 (Role based access) or something similar.

The easiest access to the model (SCL file or any other configuration Excel Sheet) is likely hacking the engineering computer and download the corresponding configuration files – or to work at the engineering company and copy the files ... It does not matter what is communicated later at run-time, if you get the signal designation and the used identifiers in the protocol you can understand the bits on the wire. This applies to all protocols! DNP3, IEC 60870-5-104, Modbus, IEC 61850, CIM, … Profibus, ProfiNet, …

We have to keep an eye on the whole chain – not just look at the protocol and how signals are designated:

The main objective of the IEC 61850 based engineering process resulting in a comprehensive model description like a SCD File (System Configuration Description according to IEC 61850-6, SCL) is to get a system document that is consistent, has less errors and less omissions! Part of the SCD content can be retrieved by self description service of IEC 61850-8-1 – not.

Let’s now look at two persons that use such a comprehensive system document: first person is authorized person using the document and second person is UN-authorized person using the document. Let’s look at two use cases:

Case A: Provide and use “open”, comprehensive SCD File.
Case B: Use proprietary system configuration description.

… and discuss the situation:

	authorized person	UN-authorized person
Case A	Can properly monitor and control the system because the operation is using a consistent and well documented system configuration. Needs to be maintained.	In the (hopeful very unlikely) event of gaining access to the system configuration it may harm the system.
Case B	E.g., especially after some years in operation and after operators have been replaced by new staff, then it may be possible that the operators are not able to properly operate the system!	It is unlikely that the UN-authorized person can do a lot of harm.

I believe that Case A is the preferred one that should be implemented: the possibility to properly operate the system by an authorized person outweighs the potential harm that can be done by an UN-authorized person.

One thing is for sure: Protect the system!! Don’t allow anybody to get on your network or systems, implement authentication, and many more …

What do you think? What is your experience? Are you aware of any analysis on this?

I would appreciate receiving your feedback – or you may just post a comment online.

Finally: One more detail on names:

Just a reminder: The IEC 61850 reporting messages and the GOOSE messages do not need to exchange these names like “CircuitBreakerMainStreet”. The content of these messages is specified by the corresponding DataSets. For Reporting see this blog post.

We have to focus on the WHOLE System!