Omicron offers new ways for IEC 61850 Substation Automation System testing

Testing the automation, control, and SCADA communication in IEC 61850 Substation Automation System (SAS) is as time consuming as testing the protection – or often even more.

StationScout simplifies the testing and reduces the required effort significantly.

With its powerful functions, StationScout is a specialist for the whole lifecycle of a SAS – from engineering to continuous maintenance. The clear status overview provides ideal support for commissioning and maintenance engineers during the different tasks in Substation Automation Systems utilizing IEC 61850.

Key features:

Status overview: StationScout provides a clear overview of the substation, visualizing the communication according to IEC 61850 in SCL files, values and states in the substation.

Signal tracing: The communication diagram of StationScout allows for signal tracing, from the overview down to the detailed communication message attributes.

Automated testing: StationScout is able to re-use predefined test plans for an automated testing procedure.

Cyber security: The dedicated hardware of StationScout ensures cyber secure operation within the substation communication network.

Simulation: The powerful simulation features of StationScout simplify testing and commissioning. Missing IEDs and IOs can also be simulated.

Defining own names: IEC 61850 abbreviations are quite cryptic. Defining of own names in StationScout allows for comfortable asset handling.

Click HERE for detailed information about the StationScout (English)
Click HERE for detailed information about the StationScout (German)

What is the Scope of IEC 61850?

The title and scope of IEC 61850 has been extended from “substations” to “power utility automation” many years ago. The title of all new parts and Edition 2 of revised parts (e.g., IEC 61850-7-1 Edition 2) is:

Communication networks and systems for power utility automation

The scope of IEC 61850 (e.g., as defined in IEC 61850-7-1 Edition 2) has been extended to:

– hydroelectric power plants,
– substation to substation information exchange,
– information exchange for distributed automation,
– substation to control centre information exchange,
– information exchange for metering,
– condition monitoring and diagnosis, and
– information exchange with engineering systems for device configuration.

The written scope of standards can be used to ... but it does not constrain the use.

The scope of IEC 60870-5-104 is defined as follows: This part of IEC 60870 applies to telecontrol equipment and systems with coded bit serial data transmission for monitoring and controlling geographically widespread processes.

Does this preclude to use 104 as substation bus? No, not at all. It is in use in many substations - at least in Germany.

And when it comes to "widespread processes", e.g., PV systems that need to be monitored and controlled, it is natural to use DNP3 or 104, or? ... today ... yes. When it comes to TCP based communication there is a very little (or almost no) difference between one protocol and the other. When you look at the overhead generated by TCP/IP … !

The main issue is: What will it cost to plan, procure, install, rent, configure, ... operate the network infrastructure? The crucial costs are still in the hardware, wires, signal-converters, commissioning, configuration, testing, service, maintenance, and SECURITY measures to be implemented – that’s what I have seen in several "modern" approaches to control a PV system from a DSO. Saving a few minutes in the configuration with one or the other protocol is relatively negligible.

When we talk about cost, let's look at the end-to-end cost and life-cycle cost - not just looking at differences in protocols and scopes of standards.

Have a look at the resources needed to encrypt and decrypt messages at transport protocol layer: The resources for making the transport layer secure requires many more resources than those needed for one protocol message or the other.

Focus on the SYSTEM – which is more than looking at SCADA protocols.