What IEC 61850 is, and what it is not?
1. What IEC 61850 is, and what it is not
Substations designed in the past made use of protection and control schemes implemented with single-function, electromechanical or static devices and hard-wired relay logic. SCADA functions were centralized and limited to monitoring of circuit loadings, bus voltages, aggregated alarms, control of circuit breakers and tap changers, etc. Disturbance recording and sequence-of-event data if available was centralized and local to the substation.
With the advent of microprocessor-based multi-function Intelligent Electronic Devices (IEDs) came the opportunity to move more functionality into fewer devices; resulting in simpler designs with reduced wiring. In addition, owing to communication capabilities of the IEDs more information could be made remotely available; translating into fewer visits to the substation.
Microprocessor-based protection solutions have been successful because they offered substantial cost savings while fitting very well into pre-existing frameworks of relay application.
A modern microprocessor-based IED replaces an entire panel of electro-mechanical relays with external wiring intact, and internal dc wiring replaced by integrated relay logic. Users retained total control over the degree of integration of various functions, while interoperability with the existing environment (instrument transformers, other relays, control switches, etc.) has been maintained using traditional hard-wired connections. Distributed functions are rare, and restricted mainly to the SCADA realm.
In terms of SCADA integration, the first generation of such systems achieved moderate success especially in cases where the end-user could lock into a solution from a single vendor. Integrating systems made up of IEDs from multiple vendors invariably led to interoperability issues on the SCADA side. Integration solutions tended to be customized. Owners of such systems were faced with long-term support and maintenance issues. During this period two leading protocols emerged: DNP 3.0 and IEC 60870.
Beginning in the early 1990s, initiatives were undertaken to develop a communications architecture that would facilitate the design of systems for protection, control, monitoring, and diagnostics in the substation. The primary goals were to simplify development of these multi-vendor substation automation systems and to achieve higher levels of integration reducing even further the amount of engineering and wiring required. These initiatives have culminated in the release of EPRI-sponsored Utility Communications Architecture, or UCA, specification, a precursor of the 61850 international standards. After decades of competing protocols and integration challenges, 61850 was created by an International Electro technical Commission working group consisting of vendors, utilities, and consultants who were focused on the development of a standard in which devices from all vendors could be connected together to share data, services, and functions.
The vision of 61850 is extremely broad. While starting with a next generation SCADA protocol, the concept encourages and facilitates advanced applications in protection and control, to the extent of blending in non-conventional CTs and VTs into the overall scheme by providing for a standardized way of exchanging information digitally between the producers and recipients of this information. The “61850” phrase became a designator for the next generation substation system with a higher degree of integration, reduced cost, greater flexibility, communication networks replacing hard-wired connections, plug-and-play functionality, reduced construction and commissioning time, and other advantages. While many of these benefits are delivered by the SCADA part of the 61850 alone, there is an expectation that the other visionary elements of the package are also mandatory and ready for extensive deployment.
The 61850 Standard makes extensive use of the concept of virtualization. Data that is produced by IEDs is presented in a standardized format. In this way IED functions become generic from the point of view of the system designer but the underlying functions retain vendor specific characteristics that may be unique and proprietary in nature. The available data is also logically partitioned according to groupings that should be familiar to relay and SCADA engineers (protection, metering, supervisory control, etc.). The data is “self describing” in nature, obviating the need for memory maps and allowing the integrator to “browse” a device for the needed data. Presented data have attributes that are common across vendor platforms.
Additionally, the 61850 series standardizes the mechanisms by which data is accessed and exchanged within the substation. The IEC 61850 concept standardizes SCADA data and services, as well as encourages peer-to-peer exchange of information between the IEDs: Included are mechanisms for reporting and logging of information, mechanisms for passing critical messages such as tripping signals between devices, and mechanisms for transfer of voltage and current samples from process-level devices (microprocessor-based CTs & VTs) to protection devices. The design of automation functions requires a considerable amount of configuration of the constituent IEDs. Currently, when building multi-vendor automation systems, the designer is confronted with one or more configuration tools from each vendor. The 61850 series addresses this by defining a description language for substation configuration (Substation Configuration Language, SCL). SCL permits the development of tools that can be used to describe the substation at a high level (single line diagram). These tools are also envisioned to configure reports/logs, control commands, critical peer-to-peer messages and sampled analog values. Vendor specific configuration tools must interface with system level tools using standard SCL files.
While the 61850 series facilitates the implementation of functions (protection schemes, control schemes, etc.) that are distributed amongst several IEDs (possibly from different vendors), the specification does not attempt to standardize the functions themselves in any detail. It is left to the end user to impose his or her own engineering practices and philosophies to the particular application. Correspondingly, the 61850 Standard makes few requirements as to which data models and data items are to be made available in a particular IED. The allocation of data models as well as much of the data that makes up the models is left to the IED vendor. This creates a potential disconnect between the vendor and the end-user. It is therefore critical for the system designer to carefully check specifications when selecting IEDs.
Similarly, the 61850 Standard details the attributes of the data exchanged between devices. These attributes include information on the quality of the data and information on the operating state of the source of the data (for example, normal versus test). Decisions on the response of a function that is presented with degraded data are outside the scope of the Standard. Additionally, the Standard permits the configuration of timing priorities for messages passed between devices. It is, for the most part, left to the designer to determine what level of priority is required for the application.
The Standard defines the description language (SCL) to be used by configuration tools, while the functionality of the tools themselves is outside the scope of the Standard. More importantly the overall engineering processes are not defined and are likely to be different than those of the past. Much of the IED settings will remain in the domain of the manufacturer specific IED configuration tool. There will (at least initially) be some conflicts created. Undoubtedly, engineering processes and the corresponding configuration tools will have to evolve in unison.
The IEC standard itself does not offer any particular system architecture to follow. Instead it describes several building blocks with the hope they will fit the future architecture while the latter is conceived. This is not a significant issue for functions integrated between SCADA and IEDs, but presents an obstacle for functions executed between IEDs and their remote inputs and outputs.
Some of the functions that have been implemented in the past will map easily into the IEC 61850 domain. Others will not. In some cases, long-held, underlying principles of system protection will have to be re-examined.