IntelliGrid Architecture

 

 

Home

Parent Menu

Analysis Overview
Document Oveview
Architectural Principles
Architectural Analysis
Recommendations
Deployment Scenarios
Benefits
Network Management
Resilient Comm Services
Data Management
Requirements
RM-ODP/UML Overview

Same Level Menu

Field Device Integration
Enterprise Management
Application Integration
Asset Management
Energy Market Integration

Child Menu

 

Search IntelliGrid Site

Questions/Comments

Questions

 

Responses

 

Field Device Integration Deployment Scenario

This example shows how IEC61850 and DNP3-based SCADA systems can be integrated to provide unified rich model-based device access and control. 

Today's field devices are multifunctional Intelligent Electronic Devices (IEDs) that have become the standard in new or upgraded integrated substation protection, monitoring and control systems, as well as other field installations. The changes in the industry result as well in changes in the requirements for the communications capabilities of such devices. Multifunctional IEDs with advanced communications capabilities allow the utilities to deal with many important issues such as:

·       Requirements for local and remote user interface for different types of corporate clients

·       Requirements for extensive data sources from the field for integrated data acquisition and control systems

·       Requirements for distributed power system event and disturbance recording devices

·       Requirements for integrating seamless transitions between local actions by individual and neighboring field devices and distributed actions from control centers for global protection, control and monitoring functionality

·       Requirements for more efficient and very high speed communications-based transmission line or centralized wide area protection schemes

The selection of the communications protocol used at the substation and distribution feeder level is one of the critical factors to consider in the design of substation automation, energy management systems, and distribution automation systems. The protocol should provide all required capabilities that will allow the optimal implementation of different substation and system functions. The IntelliGrid Architecture recommends those common services, generic interfaces, standard technologies, and best practices that provide those capabilities, such as the use of discoverable information models to give standardized names to classes and properties, and to describe their relationships, their formats, and their interactions in standardized ways.

Most of the widely used communications protocols have been designed to meet only the specific requirements of conventional SCADA systems. They do not include security other than “security by obscurity”, network management is limited to knowing only if communications are available or not, and data management consists of tediously mapping point list numbers to locations in a real-time SCADA database. As a result, these protocols cannot completely meet the functional requirements for use in IntelliGrid Architecture-based energy management solutions. DNP3 is one of the most popular SCADA protocols that is a typical example of the challenges of integration of legacy IEDs in systems implementing CIM/GID models and services.

With regard to what data is exchanged, legacy device integration provides an example where complementary semantic sets can be joined.  Traditional device models tend to be communication oriented, namely multiple lists of points that are just an index number into an array.  These simple communication models can be seen as less rich and complementary from the point of view of enterprise semantics.  Consequently, as described below, the primary strategy consists of mapping communication parameters to utility operational model elements to extend the later with the former.

For data exchange methods, the IntelliGrid Architecture recommends the use of common information models to support device integration.  Specifically, IntelliGrid Architecture-based device integration stresses the importance of enhancing communication models with utility operational semantics.  Instead of requiring integration on the basis of a communication model, integration can occur via the use of a model-enabled API such as IEC61850 Abstract Common Services Interface (ACSI) or IEC61970’s High Speed Data Access (HDA).  Note that communication protocols such as DNP3 or IEC61850 ACSI as well as other common model enabled device communication API’s are generic in that they can be applied to any device type and do not hard code device specific semantics into the interface, meaning that their object models are separate from the services.

The main problem, therefore, is mapping the data elements in the IEDs to “well-known” object names. IEC61850 performs this mapping to IEC61850 object models at the device level, while IEC61970 needs to perform this mapping to the CIM power resource object model in the control center. Since these are different mappings, they need to be harmonized. The solution in this example presupposes a harmonized IEC61850/61970 information model as shown in Figure 1. 

Figure 1 Proposed Harmonized IEC61850 and IEC61970 Information Models

 

Figure 1 illustrates a proposed harmonization of IEC61850 and IEC61970 information models.  Two UML associations are key.  The inheritance association between IEC61970 Equipment and IEC61850 GeneralEquipment allows the extension of a CIM device with IEC61850 device information. The association between IEC61970 Measurement and IEC61850 DataAttribute allows us to map CIM measurements to IEC61850 object model values.  

DNP3 is not as simple to map because it uses simple objects that do not provide self-description. The diagram below illustrates a DNP3-based and IEC61850-based SCADA Networks.

Figure 2 DNP and IEC61850 Based SCADA Networks

 

Since DNP3 has been developed as a Master - Slave protocol for the power system data acquisition and control domain, it is not suitable for any high-speed protection or control applications defined in IntelliGrid Architecture Deterministic Rapid Response environment. It is also not designed to easily support the configuration of protective relays or other multifunctional IEDs with hundreds of settings nor to adequately represent the multi-layer functional hierarchy of such devices. Control functions in DNP3 are based on three control models.  Measurements in DNP3 are available through the analog input and counter (accumulator) objects. Each IED maps individual measurements to unstructured point index numbers in vendor-specific ways. The serial version of DNP can not support most standard security measures in the environments it is typically used in, namely with low bit-rate communications channels.

It is clear that one of the main limitations of a DNP network is the limited amount of metadata that can be associated with a DNP3 device or measurement point.  The proposed solution in this example is to present DNP3 data within a richer namespace presented by a GID server.  Ideally, this namespace would be compatible with not only IEC IEC61850, but also IEC IEC61970 CIM Power System models and DMTF CIM Enterprise Management models.  In other words, the sparse DNP3 model is decorated with rich IEC61850/61970/DMTF metadata so that the DNP3 data is made more meaningful to people and applications.

Since IEC IEC61970 defines a CIM set of packages which provide a logical view of the different aspects of Energy Management System information, the integration of legacy DNP3 based devices requires the mapping of the DNP3 points into the CIM object models.

The figure below shows the mapping of four analog measurements (voltage, active power, current and reactive power) available in two protection IEDs that support the DNP3 protocol into a CIM based rich model. These measurements are represented in DNP3 as 4 data points. Each of them has to be mapped into the hierarchical rich model defined in CIM. 

In the CIM model of Figure 1, a PowerSystemResource (PSR) may have zero to many measurements associated with it. Each measurement may contain one or more measurement values. Measurements of a PSR are classified by MeasurementType.

The MeasurementType.name in the CIM model is the IEC IEC61970 name assigned, while the MeasurementType.aliasName is the name assigned to the type in IEC IEC61850. For example Volts in the figure below is the MeasurementType.aliasName for the Voltage MeasurementType.name.

Figure 3 Mapping a Device Model to the CIM

 

The key, therefore, is the mapping of DNP data items into the IEC61850 namespace and then exposing this rich namespace via the GID. This solution goes a long way toward supporting the interoperability of telemetry data servers with telemetry data clients.  Once mapping is complete, the enriched namespaces of a DNP3 server can be based on the same information model as an IEC61850 server.  Consequently, the namespaces can be aggregated into a single integrated whole.  The fact that DNP3 or IEC61850 are used for the field communications can be completely hidden from the client by the GID interface.  From the client’s point of view, there is only a single telemetry server that presents the rich name space of IEC61850.  Adoption of standard ways of representing what data is exchanged combined with standards ways for how data is exchanged allow us to fully integrate SCADA systems and use the SCADA protocol most appropriate for the environment.

In this example a new GID Client for EMS operations applications, as well as a second GID Client for network analysis applications are being integrated with the DNP3 and IEC 61850 field devices using a CIM based solution. The GID servers are used to present the DNP3 and IEC 61850 devices data within the context of the CIM. They interface with the different IEDs connected to the DNP3 and IEC 61850 networks and receive from them the data required by the two GID Client applications.

The CIM/GID integration of DNP3 legacy field device and an IEC 61850 device includes the following applications:

·       CIM-based power system modeling environment within the control center

·       DNP3 field device GID server

·       IEC 61850 field device GID server

·       GID Client for operations applications

·       GID Client for network analysis

All GID clients and servers are connected to a CIM/GID based message bus. As shown in the figure below, adapters are used to connect the DNP3 based service manager and the IEC 61850 based service manager to the CIM/GID Based Message Bus.  These adapters server two purposes:

·                Define What data is exchanged

·                Define How the data is exchanged

Figure 4 Wrapping DNP with a IEC61850 Based Namespace

 

The goal of seamless integration of field devices that support different field device data monitoring techniques can be provided by a CIM/GID-based system. Therefore, the GID Clients functionality can take full advantage of the CIM regardless of what devices are used for the interface with the electric power system and its components. This allows the integration of existing or future CIM based EMS applications developed independently by different vendors regardless of the communications protocols supported by the field devices used as the data source or to execute the required control action in the substations.

Security technologies are being standardized for both DNP3 and IEC61850 through on-going work in IEC TC57 WG15. When this work is completed, the more complete suite of security requirements will need to be incorporated in the CIM/GID/IEC61850/DNP integrated package. Likewise, additional network management efforts will need to be incorporated as the understanding of these needs are developed more fully.

As shown in IntelliGrid Architecture Environment for Critical Operations Data Acquisition and Control, the key security requirements that should be added to the CIM/GID/IEC61850/DNP integrated package, include:

·       Authorization Service for Access Control

·       Information Integrity Service

·       Audit Service 

Since this Environment cuts across at least two and possibly more security domains (substation, field sites, control center), the security solutions must be a combination of security policy, security technologies, and security practices (such as training and rigorous monitoring of security).

The mapping of DNP objects to IEC61850 objects, and the subsequent “discovery” of these objects through the GID capabilities, warrant additional focus on guidelines that address exactly how these mappings should be done, and how they can best be at least partially automated. The use of electronically available metadata models of the IEC61850 objects is clearly the starting point, but the next steps need to be clarified.

IntelliGrid Architecture
Copyright EPRI 2004