Difference between IEC 60870-5-104 and IEC 61850

There seems to be a growing interest to understand what the difference is between IEC 60870-5-104 and IEC 61850. There have been many discussions, complaints, and frustrations ... no wonder.Here is what I have answered to somebody this week:

Dear xxx,

I guess I got it ... you are analyzing the communication inside a station ... to the IEDs (protection, control, ...).

The IEC 60870-5-104 plus a lot of utility or project specific (signal) engineering will do the job – has done it for decades.

The engineering is the key issue when comparing the two standards … if you can compare them at all!!

IEC 61850 offers a lot more than 104 or DNP3 …

From a message overhead point of view, you can say, that both are more or less the same ... because they use both Ethernet and TCP/IP. There is no benefit to use one or the other.

It is likely that IED vendors will mainly focus on IEC 61850 ... and may get rid of 104 in the long run.

I have always said that utilities using 104 in all substations should continue to use it – until they build new substations or do major refurbishments. There is no need to replace a running 104 solution with IEC 61850 ...

Another issue is: To use GOOSE for interlocking … to get rid of copper … or use it for tripping … and use sampled values some time down the road.

Finally there is an issue with manpower: If the utility has senior experts in 104 close to retirement … they should wait until they have retired. Yes! I have seen many old engineers not willing to learn something completely new!!
Click HERE for a detailed comparison written by domain experts.
Hope that helps a bit more.
Best Regards,

Karlheinz

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 ... 

VHPready Signal MMXU1.TotW.instMag – versus IOA 113

Signals configured in IEC 61850 and configured in IEC 60870-5-104 look quite different.

The following figure shows the same signal (Current electric Power – Aktuell erzeugte elektrische Leistung) in IEC 61850 (left) and IEC 60870-5-104 (right):

The IEC 61850 model exposes the value, quaity and timestamp as well as the semantic (TotalWatt). The total watt of what? Of the “Current electric Power – Aktuell erzeigte elektrische Leistung” as described in the DC (description of the signal).

On the other side we have the information object address (IOA = 113) that carries the same value in IEC 60870-5-104. What does the value 3456 mean? No idea in IEC 60870-5-104. You have to know upfront what 113 means. IEC 61850 stores the meaning in the device (model).

In the above case we see also the IOA=113 in the description (DC) of the IEC 61850 model. It is a text string attached to the DC attribute.

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!

What does Self-Description in IEC 61850 and IEC 61400-25 mean?

The other day I was asked to explain the self-description to a larger group of SCADA and Asset management experts. The requirement was, to do it in some 3 minutes. I have many ways to explain it: slides, live presentation, or just a white-board.

I decided to produce a short video clip – because I have the right equipment on my desk and convenient tools to produce a video.

The result is now online and can be viewed.

Click HERE to view the 4 minutes clip.

I have planned to provide more video clips showing benefits of IEC 61850 and IEC 61400-25 and IEC 6070-5-104, …