Scott Olson (POWER Engineers) investigated recently to figure out the situation of the application of IEC 61850 in the U.S.: He found IEC 61850 on the radar screen!
In his report (A personal view of IEC 61850) he wrote early January 2012 that IEC 61850 is “More Than a Protocol”. Yes – it is much more than a protocol. It is not something like “DNP4” or “IEC 60870-5-105”. The standard series IEC 61850 provides a bunch of definitions applicable in many different subsets – there will never be an implementation that implements the whole standard series! Never ever.
Some explanation on basic concepts of the standard series IEC 61850 follow (before we have a closer look into Scott Olson’s report):
IEC 61850 provides models of real world information (status, measurements, and control points, settings, …) for many different application domains. The following slide shows an example of a model: XCBR – circuit breaker of a real substation.
Another area is the system configuration language (SCL) that describes many aspects of devices and the whole system. Third, there is the communication shown in the top left corner. The communication defines services. These services are realized by protocols. The protocols are comprising TCP/IP based client-server communication and Ethernet based real-time communication (GOOSE and sampled measured values – sensor-data).
Protocols are needed – the crucial issues are models and configuration language.
Some of the services that communicate the state-changes of the circuit breaker are as follows:
Is it worth to compare the protocols of various standards? Check the following table to figure out what the left side has to offer … and what the standards on the right have:
IEC 61850 is mainly focusing on crucial aspects of the many applications and on the system – system means: what to communicate, from where to where, how to communicate, when, … how to configure systems and devices, how to document requirements and systems, …
A remaining question is: What is most important to look at or to implement or to apply? It depends. From a device point of view it is absolute important to have the communication services and protocol – and application program interface (API) – implemented. This is required in TWO devices – the server, that provides the models, and the client that reads values or receives spontaneous reports:
From a application point of view it is crucial to look at the models!! ;-)
The models should be discussed independent of ANY protocol!!! Many people have understood that the models, services and protocols of IEC 61850 are all independent of each other – that is one of the crucial benefits! That is the reason why IEC 61400-25-4 (Wind Power application of IEC 61850) defines the mapping of process values (the signal lists) and simple services to DNP3 and IEC 60870-5-101/104. Because the models, services and configuration language are independent of the protocols.
And also note that the use of IEC 61850 is first of all intended for the substation automation and power generation … finally it may be used (in the long term) in the communication with control centers.
Back to the crucial lessons Mr Olson and others have learnt:
He writes: “We received a great email from one of our readers, who reminded us that there was a difference between a standard and a protocol—the latter being a component of the former—and that it was possible to implement IEC 61850 protocols without going all out to implement the standard.
"For example," our reader offered, "61850 GOOSE messaging may be used between IEDs to eliminate physical wiring and increase speed of interaction between IEDs while continuing to use DNP to communicate upwards to SCADA and higher-level systems where slower communications updates are acceptable.
It was such a great point to make: The migration to the IEC 61850 standard does not force the absolute replacement of protocols that are already in place. Solutions can be implemented that allow parts of 61850 to be added to the network while the legacy protocols continue to be used over the same network. For example, station bus protocol (IEC 61850-8-1) could be used to simplify the
interface between IEDs, human-machine interfaces (HMIs), etc. within the substation network while continuing to use DNP interface to SCADA. As process bus (IEC 61850-9-2) devices become readily available, the opportunity to eliminate copper wiring between current transformers (CTs) and IEDs could provide tremendous …”
The lesson that everybody should learn soon (or should have learnt): IEC 61850 could be implemented in many different subsets for even more simple to complex applications. I hope that at the end of 2012 the universe has understood that the standard series IEC 61850 is more than just a protocol – it goes far beyond DNP3, IEC 60870-5-101/104, even beyond OPC and OPC UA! It’s a system-supporting solution.
By the way, this blog is visited by many experts from North America. It is likely that Mr Olson’s lesson will be read by many U.S. people.
Click HERE for the full “personal view”.
In a open job description for an Automation Engineer in Rochester (New York) I just read today (2012-01-28) the following:
Requirements:
MUST HAVE
…
Knowledge of digital projection
Knowledge of IEC 61850
Knowledge of communication protocols- DNP
Know SCADA systems manufacturers and equipment
…
IEC 61850 and protocols are two things!
Posts
2 comments:
This is absolutely correct - there is a migration path and decision as to which parts of the IEC 61850 Standard are applied where and why.
When we talk about DNP (colloquially stands for "Does No Protection" because it doesn’t do peer-to-peer :) ) there are typically two parts - the DNP between the relays and the RTU/Gateway/HMI/SOE Logger and the other between the RTU/Gateway etc and the control centre.
In some cases this is more tricky to do than a greenfield “no brainer” – still the greenfield or complete system replacement may still need DNP/legacy comms outside the substation fence.
Perhaps adding a new bay or replacement of aged/faulty devices might be the reason to start the embryo of a 61850 system in that substation – or at least provide for the possibility in the foreseeable future – you don’t want to replace like for like if in a few years time you will need to replace it again when another augmentation of an additional bay (wind farm, additional transformer …) or a bigger refurbishment or replacement of the system is undertaken. Refer Laufenberg Switzerland as a progressive upgrade of the primary plant and at the same time implementation of 61850. In these cases 61850 and the legacy protocol jointly exist at the bay level and to the SCADA – one day it would be called a complete 61850 substation but that will take time.
In some cases the RTU has reached its end of life/no spares so implementing 61850 as part of a generic broader strategy by the utility doesn’t necessarily mean you HAVE to replace all the DNP relays or the DNP control centre.
Or the old protection relay on one bay needs replacement (electromechanical, first generation electronic or even first generation microprocessor from the early 1980’s all now well beyond end of expected life). Like for like is not possible so what do you put in that particular bay or is this a catalyst for a bigger replacement project?
However these are all still wires, device or protocol myopic views of “why do it”!
The real reason why any 61850 system is worth considering is the “Reusable Engineering” it provides when [properly] applying the System Configuration Language in Part 6.
Just recently I saw a project where the configuration of the devices was based on using the vendor-specific tools to configure 5 different vendors types of IEC 61850 devices on a 'serial number - by - serial number' approach and a spreadsheet of points handed to the SCADA engineer to manually map these into a point base data base of the RTU.
Is it any wonder this approach suggests to them that ‘peer-to-peer’ GOOSE is not worth the effort compared to “a single wire from one bay to another”
Unless the design office engineering process and tools are considered vs the effort of doing point based engineering of SCADA or terminal number based wiring schematics of protection, you’ve actually missed probably 90% of the real reason why you should actively consider the change
Another benefit of using the standard models and the configuration language is the possibility for specific application domains, to define specific subsets (profiles) that can easily be re-used.
E.g., the model for monitoring, settings and control information of a CHP (combined heat and power) or an inverter for a PV application. Such a model would have the same logical nodes (LN) and data objects independent of the vendor. Vendors may extend the models for vendor-specific information their system has.
IEC 61850-7-1 defines the rules how to extend models.
Such profiles are templates that can be re-used in engineering or SCADA systems or the like - the crucial basic information is the same independent of the vendor! The electrical measurements would be modeled with the LN MMXU; phase A current would be in MyLogicalDevice/MMXU1.A.phsA.cVal.mag or in YourLD/MMXU1.A.phsA.cVal.mag ... since the path to the future smart(er) energy system is a marathon - not a sprint - we have some time to learn how to use models, configuration, GOOSE, sampled values, etc. ... Haste makes waste - take your time to see the benefits of a smooth migration to IEC 61850.
Post a Comment