Iec tr 62357 2003

TECHNICAL REPORT IEC TR 62357 First edition 2003 07 Power system control and associated communications – Reference architecture for object models, services and protocols Reference number IEC/TR 62357[.]

Scope and purpose of reference architecture

The primary goal of a reference architecture is to outline the various object models, services, and protocols, along with their interrelationships This foundation allows for the development of a strategy to identify the need for common models and suggests methods to achieve them In cases where changes are hindered by the maturity of standards, recommendations for adapters to facilitate necessary transformations between models are provided.

This report deals with the following standardisation initiatives and their relationships:

IEC Technical Committee 57 is tasked with creating standards for power system control and related telecommunications This Technical Report encompasses several working groups under the committee's purview.

• IEC Technical Committee 57 Working group 3 – standards for reliable data acquisition and control on narrow-band serial data links or over TCP/IP networks between SCADA masters and substations.

• IEC Technical Committee 57 Working group 7 – standards for the exchange of real- time operational data between control centers over Wide Area Networks (WANs).

• IEC Technical Committee 57 Working group 9 – standards for data communications over distribution line carrier systems.

• IEC Technical Committee 57 Working groups 10, 11 and 12 – standards for substations.

IEC Technical Committee 57 Working Group 13 develops standards aimed at enhancing the integration of applications within control centers These standards also address interactions with external operations in distribution and other external information sources and sinks essential for real-time operations.

• IEC Technical Committee 57 Working group 14 – standards for Distribution

Management System interfaces for information exchange with other IT systems.

• IEC Technical Committee 57 Working group 15 – standards for data and communication security.

• IEC Technical Committee 57 Working group 16 – standards for deregulated energy market communications.

2 The Electric Power Research Institute (EPRI), which is responsible for the following projects that have contributed to the work of IEC Technical Committee 57:

The CCAPI project is focused on creating interfaces that facilitate information sharing among application programs within a control center, encompassing areas such as transmission, distribution, and generation This initiative also contributes valuable input to the IEC Technical Committee 57 Working Groups 13 and 14.

• UCA2, which focuses primarily on communications to substation and substation devices in transmission and distribution substations (provides input to IEC Technical

• ICCP, also known as TASE.2, for inter-control center communications, but also applicable to substation communications in certain circumstances (provides input to

IEC Technical Committee 57 Working group 7)

LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.

IEC Technical Committee 57 is involved in various standards-related activities that contribute to both existing and future standards, which can be customized to address specific utility requirements These activities and their application domains are illustrated in Figure 1, highlighting key areas of interest.

The Object Management Group (OMG) is an industry consortium that oversees the CORBA standards for open distributed computing In collaboration with the OMG Utilities Domain Task Force (DTF), the IEC Technical Committee 57 Working Group 13 is focused on creating standards for the common access and acquisition of SCADA data.

• Open Application Group (OAG), an industry consortium responsible for Enterprise

IEC Technical Committee 57 Working Group 14 is collaborating with the OAG to create standardized XML messages for effective information exchange between distribution management systems and various IT systems, enhancing Application Integration (EAI) solutions.

This Technical Report does not cover the connections between individual IEC Technical Committee 57 working groups and related organizations For more details, readers are encouraged to consult the aforementioned working groups and the respective websites of these organizations.

ISO ODP IEEE CIRED Open GIS

CORBA (OMG) Enterprise Java Beans DCOM (Microsoft)

Figure 1 – Coordination among standards activities

Figure 2 shows the scope of activity encompassed by the IEC Technical Committee 57 working groups identified above The standards shown in Figure 2 are described in the following Clause.

IEC TC 57 Overview of Standards

Figure 2 – Application of IEC Technical Committee 57 Standards to a power system

IEC 60870-5 Standards from IEC Technical Committee 57 Working group 3

IEC Technical Committee 57 Working Group 3 was established to create standards for dependable communications over narrow-band serial data links, primarily for interactions between SCADA masters in control centers and RTUs in transmission substations The initial standard, IEC 60870-5-101, introduced a three-layer protocol stack specifically engineered for high reliability and low bit rates Subsequently, the focus of IEC Technical Committee 57 expanded to encompass additional aspects of communication standards.

Working Group 3 expanded its focus to incorporate telecontrol protocols compatible with data networks, including router-based WANs This development led to the creation of IEC 60870-5-104, which facilitates network access for IEC 60870-5-101 through standard transport profiles, predominantly utilizing TCP/IP.

The standards rely on an "anonymous point-oriented model" to determine the values received and the devices managed This implies that the origin of a data value, whether it be an analog measurement, status, or accumulator value, is identified by an RTU point number or name.

This is in contrast to the “device-oriented models” being developed in IEC Technical

Committee 57's Working Groups 10, 11, and 12 focus on the IEC 61850 standards, which utilize object models to represent real-world substations and field devices Each value is identified by the name of the device that supplies it, and the comprehensive modeling of the device also incorporates additional information, including nameplate data.

IEC 60870-6 Standards from IEC Technical Committee 57 Working group 7

IEC Technical Committee 57 Working Group 7 concentrated on creating protocols for Wide Area Networks (WAN) to connect control centers with diverse databases and Energy Management System (EMS) applications The objective was to establish protocols and services that adhere to the OSI 7-layer reference model, leveraging existing ISO standards to the greatest extent feasible.

The first standard published was TASE.1, comprising IEC 60870-6-501, IEC 60870-6-502,

IEC 60870-6-504, and IEC 60870-6-701, which is based on the ELCOM-90 protocol from

Norway over an OSI protocol stack While TASE.1 includes enhanced functionality, the application program interface was maintained exactly as defined in the ELCOM-90 protocol documents.

The second standard published was TASE.2, comprising IEC 60870-6-503, IEC 60870-6-505,

IEC 60870-6-702 and IEC 60870-6-802 standards facilitate not only SCADA data and device control but also the exchange of information messages, including unstructured ASCII text and short binary files, as well as structured data objects like transmission schedules, transfer accounts, and periodic generation reports Commonly referred to as ICCP, this standard derives its name from the EPRI project that initiated the development of its draft specifications.

The TASE.2 standards utilize a client/server architecture, where the client initiates transactions that the server processes These transactions and services for data transfer are defined using object models, including Association, Data Value, and Data.

Set, Transfer Sets, Device Control, etc The actual data to be transferred was separated from these services and defined as static data objects, such as Indication Points, Control Points,

Transfer Account, Device Outage, etc Thus an attempt was made to separate the data objects to be transferred from the underlying services used to transfer the data.

However, since the primary objective of TASE.2 was to support the exchange of real-time

SCADA data, schedules, and accounting information are largely independent of their sources, meaning the specific physical devices providing measurands or status data are not crucial As long as a power system model within the control center can associate received point data with its location in the network topology, point-oriented models effectively represent the data values and control commands sent to other control centers or substation host computers acting as SCADA masters While an object model approach defines data objects and services, an anonymous point-oriented model identifies the received values and controlled devices, as outlined by the IEC Technical Committee.

3 The term control center here also includes power plants and automated substations that contain a host computer acting as a SCADA master located within the substation itself.

4 The scope of IEC Technical Committee 57 and IEC Technical Committee 57 Working group 7 was later modified to embrace the use of TCP/IP for the Transport Layer as well.

IEC 60870-6-503 defines the services and protocols, including a mapping of the abstract services and data types defined in the server objects onto MMS services and data types.

IEC 60870-6-802 defines the data objects and their mapping onto MMS data types.

IEC 60870-6-702 defines an Application Profile for TASE.2 protocol stack in the upper 3 layers IEC 60870-6-505 is a User Guide for TASE.2.

IEC 61334 Standards from IEC Technical Committee 57 Working group 9

IEC Technical Committee 57 Working Group 9 establishes standards for distribution automation through distribution line carrier systems These standards focus on protocols that enable access to field distribution devices from distribution operations management systems via existing power lines.

These standards encompass communication via distribution line carrier technology across medium voltage (MV) and low voltage (LV) networks The distribution line communication system enables two-way communication, facilitating a wide range of devices with diverse functions, including station control units, remotely controlled feeder switches, meters, transformer station concentrators, portable input units, light control, load management, and traffic lights.

Standard IEC 61334-4-1 defines the reference architecture based on the client-server model.

IEC 61334-4-41, also referred to as the Distribution Line Messaging System (DLMS), presents an abstract, object-oriented server model that takes into account the limited resources of distribution devices The application protocol's protocol data units are defined using ASN.1, and the standard also includes efficient encoding rules as outlined in IEC 61334-6.

The IEC 61334-5-1 to IEC 61334-5-5 series defines several physical and MAC layers using different modulation technologies suited for LV and MV communication IEC 61334-4-511 and

IEC 61334-4-512 outlines the management framework and procedures for the IEC 61334-5-1 profile, while IEC 61334-3-21 and IEC 61334-3-22 establish the requirements for safely coupling DLC signals into the MV line.

The DLMS standard IEC 61334-4-41 forms the basis for a series of standards developed by

IEC Technical Committee 13 Working group 04 for metering applications In particular, the

IEC 62056 series provides a complete communication stack – including the meter device models – which is compatible with IEC 61334-4-41.

IEC 61850 Standards from IEC Technical Committee 57 Working groups 10 to 12

In response to the growing need for standards in substation automation, new working groups (IEC Technical Committee 57 Working Groups 10, 11, and 12) were established to create standards for architectures and interfaces within substations and distribution feeders These standards aim to enable direct access to field devices, facilitating engineering tasks such as device reconfiguration and asset management, while also accommodating devices from various vendors in a unified manner.

These standards define a reference architecture based on a client/server model, similar to the

TASE.2 standards, in which the client initiates transactions that are processed by the server.

In contrast to the TASE.2 standards, physical field devices are represented as objects with specific attributes and methods, allowing clients to interact directly with the object model This interaction enables users to access attribute values, such as nameplate data and measured values, as well as control the devices Additionally, the common services required by all substation devices, particularly field devices, are modeled as server objects in accordance with the IEC 61850-7 Abstract Communication Service Interface (ACSI).

Communication services are articulated through object modeling techniques, allowing field devices to integrate these services by designating which objects in their models inherit class objects defined in the ACSI For instance, a utility field device model that includes a measured value for a substation host will inherit the attributes and methods from the Basic Data Class as outlined in IEC 61850-7-2.

Standardized mappings of abstract services to various application layer communication protocols are outlined in IEC 61850-8-x (station bus) and IEC 61850-9-x (process bus) This ensures that common utility functions are executed consistently across all field devices, regardless of the underlying communication stacks.

Similar to the TASE.2 standards, the ACSI description makes use of a client/server model.

However, since the primary objective of the ACSI is to provide access to device objects, the field objects are modeled directly in IEC 61850.

This work is based on object models for substation devices that originated with the EPRI- sponsored UCA2 project, and IEEE Technical Report 1550, described in Annex B.

Future IEC 61970 Standards from IEC Technical Committee 57 Working group 13

IEC Technical Committee 57 Working Group 13 was established to create EMS API standards that enhance the integration of independently developed EMS applications These standards facilitate communication between various EMS systems and other power system operation systems, such as generation and distribution management By defining standard application program interfaces, the group enables seamless access to public data and information exchange, regardless of the internal data representation.

The standards are centered on a Common Information Model (CIM) that offers an abstract representation of a complete power system through Unified Modeling Language (UML) notation As a component of the EMS-API framework, the CIM defines the semantics for this API, while additional sections of the standard outline the syntax for the API.

The CIM is a conceptual framework that encapsulates the key components of an electric utility enterprise, as typically found in an EMS information model It encompasses public classes and attributes for these components, along with the interconnections among them.

Technical Committee 57 focuses on various elements of the power system, primarily modeled in the Common Information Model (CIM) This includes critical components like generation equipment, generation dynamics, schedules, energy schedules, financial aspects, and reservations Additionally, certain elements of the power system, such as substation equipment—transformers, switches, and breakers—are represented in both the CIM and other modeling frameworks.

The comprehensive CIM is partitioned into several packages for convenience Future IEC

61970-301 defines a base set of packages which provide a logical view of the physical aspects of Energy Management System information, including the Core, Topology, Wires,

Outage, Protection, Measurements, Load Model, Generation, and Domain Future IEC 61970-

302 defines the Energy Scheduling, Reservation, and Financial packages Future IEC 61970-

2.5.2 Component Interface Specifications (CIS) for Information Exchange

To facilitate a specific application and exchange type, it is essential to identify the object classes and attributes involved in the data exchange This involves establishing interface message structures that encapsulate the data, which may represent subsets or views of CIM object classes Essentially, the CIM serves as a data dictionary, outlining the information exchanged between applications.

The Component Interface Specifications (CIS) define the data content and behavior for applications within an EMS, utilizing UML notation for interface classes related to information exchange The EMS-API standards focus on establishing interface standards rather than standard applications, making it essential to consider the application categories supported by these standards The CIS is being prepared for various application categories, which include, but are not limited to, the following.

• Network Applications (for example, State Estimator, Optimal Power Flow, etc.),

• External systems (for example, Distribution Management Systems (DMS), weather, wholesale power marketing, etc.),

The EMS-API standards define generic APIs that are independent of specific data content, while the details of the information to be exchanged are outlined in the CIS interface classes In practice, system implementers or integrators determine the applications or systems to be integrated and create an information exchange model (IEM) repository that contains metadata for all information exchanges.

2.5.3 Future IEC 61970 Standards as an Integration Framework

Figure 3 highlights the essential interfaces within a control center utilizing EMS-API standards, where SCADA data is accessible to EMS applications through Component Interfaces defined by EMS-API CIS standards The middleware technology, known as the component execution system (CES), can be selected by the system implementer from various top options, as it is not dictated by EMS-API standards As long as the SCADA data presented at the SCADA component interface to the CES adheres to EMS-API standards, any compliant application can effectively receive and interpret the data.

Component Execution System and Component Adapters (e.g., Integration Bus)

Figure 3 – EMS-API Standards as an Integration Framework

The EMS-API standard mandates that data at the interface must adhere to the Common Information Model (CIM) in terms of both semantics and syntax Consequently, any application seeking to access SCADA data only needs to align with the CIM This necessitates a transformation from the original data representation used for data acquisition to the CIM format.

Figure 4 depicts the necessary interfaces and transformations SCADA data, received through IEC 60870-6 TASE.2 links from a control center or a substation's SCADA master, is converted by the TASE.2 Adapter to ensure future compliance.

IEC 61970 CIM More specifically, it is transformed to comply with the SCADA CIS defined as part of the EMS-API standards In a similar fashion, SCADA data received via IEC 61850

ACSI links from either substation or field devices is transformed in the ACSI Adapter to be

CIM-compliant SCADA data from an existing SCADA system that uses the IEC 60870-5 standards, DNP, or some proprietary RTU protocol is transformed by a custom SCADA

To ensure CIM compliance, the System Adapter standardizes SCADA data across various protocols and services, providing a uniform representation on the integration bus Consequently, applications that utilize SCADA data, such as data repositories and historical information systems, must be designed to interface solely with the IEC 61970 EMS-API CIS SCADA interface for seamless integration within the system framework.

Figure 4 also illustrates the use of database adapters to transform data from proprietary representations in an EMS database or from industry standard representations in a Historical

Information System to the CIM representation for access via the integration bus.

IEC 61968 Standards from IEC Technical Committee 57 Working group 14

IEC Technical Committee 57 Working Group 14 was formed shortly after IEC Technical

Committee 57 Working Group 13 to address the need for standards for System Interfaces for

Distribution Management Systems (SIDMS) are guided by the IEC 61968 series, which aims to enhance the integration of diverse software applications used in managing utility electrical distribution networks These standards outline essential requirements, an integration architecture, and interfaces for key components of a utility's operations.

Distribution Management System (DMS) and other associated external IT systems Examples of DMS include Asset Management Systems, Work Order Management Systems, Geographic

Information Systems and Customer Information Systems, while Customer Resource

Management serves as an external IT system interface, utilizing message-based technology to integrate applications into a cohesive framework known as Enterprise Application Integration (EAI) The IEC 61968 standard provides guidance for utilities in implementing EAI Figure 5 visually illustrates the scope of IEC 61968-1 concerning various business functions.

(ERP, Billing, Energy trading, other systems)

Figure 5 – Distribution Management System with IEC 61968 compliant interface architecture

Standards interfaces are being defined for each class of applications identified in the IEC

The 61968-1 Interface Reference Model (IRM) is developed by IEC Technical Committee 57 Working Group 14, which employs the Unified Modeling Language (UML) to define additional Real World Objects (RWO) classes within the Common Information Model (CIM) These classes are essential for facilitating inter-application information exchange in the distribution domain, and they will be specified in the upcoming IEC 61970-3xx standards.

IEC 61968-11) govern the semantics used in message types being defined for the Information

Exchange Model (IEM), which is to be included in Parts 3 to 10 of IEC 61968.

The eXtensible Markup Language (XML) is a structured data format designed for document interchange, especially over the Internet Its main application is facilitating information exchange between diverse and potentially incompatible computer systems, making it highly effective in this domain.

System Interfaces for Distribution Management Therefore, where applicable, Parts 3 to 10 of

IEC 61968 will define document structures in XML In addition to close cooperation with the

CCAPI Task Force and IEC Technical Committee 57 Working group 13, IEC Technical

Committee 57 Working group 14 also works collaboratively with the Open Applications Group

(OAG) to improve the ability of utilities to integrate between T and D applications (IEC

Technical Committee 57 domain) and Enterprise Resource Planning (ERP) applications (OAG domain) OAG message exchange is defined using XML.

IEC Technical Committee 57 Working Group 14 is developing its standards based on the same Common Information Model (CIM) utilized by Working Group 13, while incorporating specific extensions tailored for the distribution systems outlined by IEC Technical Committee 57.

Working group 14 Thus IEC Technical Committee 57 Working group 14 and IEC Technical

Committee 57 Working group 13 are both using the CIM for inter-application information exchange and building an IEM as needed to define the specific semantics and syntax for these exchanges.

Note that the use of object modeling techniques internal to each of the applications/systems integrated with either IEC Technical Committee 57 Working group 13 or IEC Technical

Committee 57 Working Group 14 standards are not mandatory in this context; they primarily serve to describe data at the interface intended for sharing Consequently, the Common Information Model (CIM) acts as the authoritative language for both semantics and syntax within the network that connects various applications and systems.

IEC Technical Committee 57 Working group 15 Standards for Data and

IEC Technical Committee 57 Working group 15 is chartered with developing security standards which encompass all the work of Technical Committee 57 At the present time

(2003), this work has just begun and as a result, no standards currently exist It is expected that future editions of this Technical Report will incorporate these standards.

IEC Technical Committee 57 Working group 16 Standards for a Framework for

The working group is tasked with creating a framework for communications in deregulated energy markets As of 2003, this initiative is in its early stages, and no standards have been established yet Future iterations of this document are anticipated to include these standards.

This article presents a Technical Committee 57 reference architecture that organizes standards into a cohesive framework Its main objective is to pinpoint the interfaces necessitating data transformation.

Figure 6 illustrates a top-down view of the IEC Technical Committee 57 standards, highlighting the integration of systems and applications through inter-application messaging facilitated by commercial off-the-shelf middleware The subsequent layers focus on data representation, as defined by the CIM, and application program interfaces, in accordance with the future IEC 61970 and IEC 61968 interface standards.

Inter-Application Messaging Middleware Future IEC 61970/IEC 61968 Common Information Model (CIM) Future IEC 61970 Component Interface Specifications (CIS)

OSI Protocol Stacks (ISO/TCP)

Switchgear, Transformers RTU IEC 61850 Process Bus

Figure 6 – Technical Committee 57 Reference Architecture

The next layer 4 represents the various transmission and distribution computer systems/applications for which integration standards are being developed in IEC Technical

Committee 57 This includes the following:

• EMS applications, including inter-control center data links,

• a variety of distribution systems, such as meter reading and control, customer inquiry, records and asset management, maintenance and construction, operational planning, etc.

For each of these layer 4 applications, an “inboard” interface and an “outboard” interface is shown For the purposes of this diagram, these interfaces are defined as follows:

Outboard interface: the view looking outward toward the external systems/devices with which these layer 4 applications/systems communicate to acquire data and/or control devices.

Layer 4 applications function as clients that initiate transactions with remote servers, connected through various communication networks These networks may face geographic and utilization constraints, including limited bit rates, proprietary data link layers, restricted usage times, and satellite hop delays The network topology can be hierarchical, with central sites managing numerous field sites, or it may support peer-to-peer interactions Additionally, communication configurations can vary, encompassing point-to-point, multi-drop, mesh, hierarchical, and WAN-to-LAN setups, with intermediate nodes serving as routers, gateways, or data concentrators.

The Technical Committee 57 standards, established by IEC Technical Committee 57 Working Groups 3, 7, 9, 10, 11, and 12, define the information exchange on the outboard interface These standards focus on the client/server interaction and the communication protocol stacks that facilitate communication between clients and servers, as illustrated in the lower layers of the reference architecture.

Inboard interface: the view looking inward toward other layer 4 applications/systems for the purposes of exchanging information typically in a peer-to-peer fashion.

Layer 4 applications and systems typically interact as peers, although some may adopt a client/server model where each system acts as both client and server Information exchange on the inboard interface relies on the semantics and syntax outlined in the upcoming IEC 61970/IEC 61968 CIM standards The specific message contents and behaviors are defined in the forthcoming IEC 61970 CIS for control center applications and in the IEC 61968 SIDMS for DMS applications, as developed by IEC Technical Committee 57 Working Groups.

13 and 14, respectively These standards are shown in the upper layers of the reference model.

Some applications/systems in layer 4 have both outboard and inboard interfaces, such as

SCADA systems, inter-control center communications, and certain DMS applications function as clients for external interfaces while serving as data sources for internal applications.

The SCADA system, equipped with an ACSI client, communicates with ACSI servers through IEC 61850 standards to retrieve data from substations and field devices In the future, it may also function as a server utilizing upcoming IEC standards.

61970 standards to exchange data with EMS applications, such as Topology Processor or

State Estimator, in a control center environment.

SCADA Interfaces

Among the applications shown is SCADA for real-time data acquisition and device control.

While there are several protocol/service and interface standards in IEC Technical Committee

The future IEC 61970 SCADA CIS establishes a standard for SCADA data representation and behavior, facilitating the exchange of SCADA data with other EMS/DMS applications This is crucial for real-time operation and control on the inboard interface, as illustrated in the reference architecture for SCADA operations on the outboard interface.

As can be seen, there are several standards defined for accessing substation and field devices These include standards from IEC Technical Committee 57 Working groups 3, 7, 9,

10 and 11 plus standards from other Technical Committees The data representation is different for these working groups as defined in their respective standards (i.e., IEC 60870-5,

IEC 60870-6, and IEC 61850) as previously described Therefore, there is a need for the

SCADA data representations from each of these SCADA services to be harmonized with the

CIM representation of SCADA data There are two approaches to accomplish this:

1 Provide for data transformation processing in the SDADA system or at the interfaces to the SCADA system using the existing standards models.

2 Resolve the differences in models within the developing standards before they become finalized to negate the need for real-time data transformation.

A dedicated web interface allows for the configuration and data access of substation and field devices, providing real-time information that is typically not captured by SCADA systems This functionality supports engineering tasks and enables users to access data remotely through web browsers, as long as they are connected to the network The interface leverages the full capabilities of the IEC 61850 ACSI, facilitating device discovery and access to comprehensive object model data from intelligent devices, alongside standard SCADA data Notably, the object models utilized in this context do not need to align with those defined in the CIM when used independently from the control center.

Inter-CC Data Links

The inter-control center data link services/protocols are provided by IEC 60870-6-503,

IEC 60870-6-702, and IEC 60870-6-802 There are no other standards for this service in IEC

Technical Committee 57 These standards are now complete and extensively deployed in commercial products in the field at many utilities around the world.

The data representation for SCADA systems in IEC 60870-6-503 and IEC 60870-6-802 is not aligned with the CIM representation Given the widespread use of these standards, data transformation appears to be the most feasible solution in the short term Looking ahead, it may be beneficial to develop the ability to transfer specific objects.

Additional standards exist for information exchange between control centers, which are not detailed here An XML version of the Common Information Model (CIM) facilitates the exchange of power system models without the need for a special protocol Current implementations utilize file transfer via FTP over TCP/IP for this purpose.

EMS Applications

Most EMS applications rely on the SCADA application or inter-control center data links to provide real-time operational data As a result, there are no relevant IEC Technical Committee

57 standards on the outboard interface side of these applications, so there are no data or object model harmonization issues between IEC Technical Committee 57 standards.

There are challenges related to the proprietary data formats used by various EMS applications and the CIM/CIS standards being developed under the IEC 61970 standards by IEC Technical Committee 57 Working Group 13 In implementing these standards, two potential integration scenarios may arise.

1 Existing EMS applications are “wrapped” to transform the existing proprietary application interface to the interface specified in the CISs and the data representation specified in the CIM.

EMS applications are being updated to align with the future IEC 61970 standards by providing the specified API For new applications, the standard interface will be integrated into the original design, eliminating the necessity for wrappers.

DMS Applications and External IT Applications

The distinction between inboard and outboard interfaces blurs somewhat with DMS applications/systems such as Asset Management, Work Order Management, Geographic Information,

Customer Information systems are primarily designed as stand-alone systems, with interfaces to external IT systems, excluding strictly utility systems like Customer Resource Management, governed by the IEC 61968 standards The Common Information Model (CIM) facilitates information exchange between these systems, categorizing the interfaces as inboard interfaces, as illustrated in Figure 6.

Substation/Field Devices

Switchgear, transformers, and other substation or field devices can be accessed indirectly via an RTU or directly through the use of substation automation and intelligent devices.

RTUs offer restricted access to standard SCADA point-oriented data exclusively through IEC 60870-5 standards Given the maturity of these standards, the most effective method for achieving harmonization is through data transformation at the control center.

Substation automation utilizing IEC 61850 standards enhances device access through device-oriented data models It allows for the integration of real-time SCADA data with configuration, topological, and asset information within the power system model in the CIM of the EMS Therefore, harmonizing object and attribute names, along with data types, by adopting common conventions for the device models used in the EMS is crucial.

4 Data Modeling in IEC Technical Committee 57

Data can be modeled in various ways, reflecting different methods of representing information for transfer over data links or interfaces governed by IEC standards.

Technical Committee 57 emphasizes the importance of data representation in the lower layers of a protocol stack for ensuring interoperability among products from various vendors However, from a harmonization perspective, the critical aspect lies in the interfaces where software adhering to one standard interacts with software following another standard.

Harmonization can be understood as the exchange of data through object models that represent the same physical object To achieve consistency across all interfaces, it is ideal to utilize a single set of models This section outlines the object models currently employed by IEC Technical Committee 57.

Annex A provides a summary of what is modelled in each of the major IEC Technical

Common Information Model (CIM) and Component Interface Specifications (CIS)

The CIM serves as an essential framework for modeling the entire power system, focusing on both operational and asset-management perspectives, particularly for the elements necessary for managing real-time operations.

The CIM is an abstract model that encapsulates the key objects within an electric utility enterprise, as typically found in an EMS information model It comprises public classes and attributes for these objects, along with their interrelationships The abstract nature of the objects in the CIM allows for diverse applications across various contexts.

The CIM is represented in class diagrams using UML notation, organized into multiple packages for ease of understanding, as illustrated in Figure 7 However, it functions as a single interconnected class diagram, with packages serving as a method to group related model elements.

The Common Information Model encompasses a comprehensive set of packages designed to simplify the model's design, understanding, and review Entities within this model can have associations that span multiple package boundaries, and each application utilizes information represented across various packages.

Figure 7 – Common Information Model (CIM) Packages

Figure 7 illustrates the defined packages for the CIM and their dependency relationships, with dashed lines indicating dependencies that point from the dependent package to the one it relies on The IEC Technical Committee 57 focuses on various aspects of the power system that are exclusively modeled in the CIM, including generation equipment, dynamics, schedules, financial elements, and reservations Additionally, certain components of the power system, such as substation equipment like transformers, switches, and breakers, are modeled in both the CIM and other frameworks.

The UML class diagrams for each CIM package illustrate all the classes within the package and their interrelationships Additionally, any relationships with classes from other packages are depicted, accompanied by notes that specify the owning package of those classes.

In a power system, classes and objects are essential for creating a unified representation for Energy Management System (EMS) applications A class serves as a blueprint for real-world entities like power transformers, generators, and loads, which are integral to the overall power system model Additionally, EMS applications must handle various objects, including schedules and measurements, necessitating a standardized representation to ensure compliance with the EMS-API standard for plug-compatibility and interoperability Each unique entity within the power system is modeled as an instance of its respective class, allowing for effective processing, analysis, and storage.

The Common Information Model (CIM) is designed to enhance data exchange, with its entities primarily supporting basic operations such as create, delete, update, and read.

To enhance the configurability of the CIM for various implementations, it is essential to prioritize ease of attribute modification over class definition changes This approach suggests minimizing the number of specific class sub-types and instead focusing on generic classes that utilize attributes to specify type names Consequently, applications can leverage this information to create specific object types as needed, while also requiring supplementary details to establish valid types and relationships.

Classes possess attributes that define the characteristics of their objects In the CIM, each class includes attributes that identify and describe specific instances Only those attributes relevant to EMS applications are featured in the class descriptions.

Each attribute has a type, which identifies what kind of attribute it is Typical attributes are of the types integer, float, Boolean, string, and enumeration, which are called primitive types.

However, many additional types are defined as part of the CIM specification For example,

CapacitorBank has a MaximumkV attribute of type Voltage The definition of data types is contained in the Domain Package.

Relationships between classes reveal how they are structured in terms of each other CIM classes are related in a variety of ways, including generalization, simple association, composite and shared aggregation.

The CIM standard extends beyond its role in an EMS, serving as a vital tool for integration across various domains It provides a common power system model that enhances interoperability and ensures plug compatibility among diverse applications and systems, regardless of specific implementations.

Much of the work of this group, especially the CIM, is based on proposals received from the

EPRI-sponsored Control Center Application Program Interface (CCAPI) project described in the next section.

The original purpose of the CIM was to model that portion of the power system of interest to

EMS applications being handled in IEC Technical Committee 57 Working group 13 However, the scope was recently broadened to embrace the scope of IEC Technical Committee 57

Working group 14, and is now being expanded to include models needed for DMS applications and systems For a complete description of the entire CIM model, see future

IEC 61970-301, future IEC 61970-302, and future IEC 61970-303.

Some of the important features of the CIM are:

The CIM is hierarchical Attributes common to more than one subclass of object are inherited from a common class.

The CIM is designed to be normalized, ensuring that all attributes are unique to a single class while allowing integration into other classes through relationships such as generalization, association, and aggregation This flexibility enables the model to be applicable across various unforeseen applications In contrast, a denormalized model would involve creating new classes and duplicating attributes to tailor the structure for specific application perspectives.

The CIM is a static information model that represents physical objects through interrelated classes It was designed without a specific application in mind, which means that the objects an application may need to access are not confined to a single class Instead, the CIM consists of numerous "small objects" rather than "big objects" that applications typically operate on Consequently, it is inappropriate to incorporate operations or methods into the existing class definitions within the CIM.

The CIM is modeled in Rational ROSE The CIM was constructed using Rational ROSE

Rational Software Corporation's Version 4.0 features a comprehensive CIM stored as a mdl file, which can be accessed through Rational ROSE This allows users to view class diagrams along with detailed descriptions of classes, attributes, types, and relationships The graphical navigation interface enables easy point-and-click access to all CIM specification data directly from the class diagram within each package, enhancing user experience and accessibility Each top-level package is also distributed accordingly.

.cat file, allowing new models to be constructed from the CIM packages.

The CIM IEC documents are auto-generated using Rational SODA.

The CIM has a representation in XML using an RDF schema.

The CIM is an OMG standard.

The CIM is in use in many production systems.

The CIM is meant to contain classes and attributes that will be exchanged over public interfaces between major applications.

The objective is to retain only the essential generic features that can lead to a detailed implementation Typically, adjusting the value or domain of an attribute is simpler than altering a class definition This approach enhances the model's robustness, allowing it to accommodate a wider range of requirements, and increases its stability, as new requirements can often be addressed without necessitating changes to the model.

Whereas the CIM is a static model, the CIS documents which are the subject of the future IEC

IEC 61850 ACSI and Logical Devices

In IEC 61850, Logical Device models simulate the functionality of actual devices by establishing standard classes and objects, which are created through inheritance and aggregation from a unified set of Abstract Communication Server Interfaces.

The ACSI, as defined in IEC 61850-7-2, outlines the server objects essential for communication with field devices, while it does not specify the content of the information exchanged Additionally, Logical Devices are addressed in IEC 61850-7-3.

61850-7-4, define the content of the information transferred.

ACSI-based devices allow users to utilize device features via clearly defined network services that operate on the objects The ACSI data access model establishes the guidelines for defining and structuring object models, as specified by industry groups, into communicable objects.

The IEC 61850 standards incorporate the services and models from the EPRI Common

Access Service Methods (CASM) 5 with some revisions based on more recent developments.

The object-oriented terminology used in these standards is similar to the UML used in the CIM and includes: class, object, method, attribute, inherit, instantiate, and aggregate However,

IEC 61850 uses the object modelling facilities of ASN.1, ISO/IEC 8824-2 rather than UML.

The ISO/IEC 8824-1 standard defines a type language for outlining the abstract structure of a protocol, specifically focusing on the data contained within messages This standard offers a notation system for representing data values and data types effectively.

In the ACSI framework, a client/server model is utilized where the client initiates transactions processed by the server The ACSI server conceals actual data and devices, representing them through objects Clients access these objects via a server class object, while the servers and their contained object instances are linked to communication stacks for interaction with real devices.

5 See Annex B for a description of CASM.

Hi d e/ en cap su la te re al W o rl d

Figure 8 – ACSI Client/Server Model

Logical Devices are virtual representations of real substation and field devices As in real devices, Logical Devices are a composite of multiple parts, which are represented by Logical

Nodes The collection of these Logical Nodes provide the functionality of the complete device.

A distribution relay device typically incorporates multiple standardized relay functions and is equipped with the ability to measure voltages and currents in the conductors it manages This device can be represented according to IEC standards.

61850, a Logical Device would be created that contained a nameplate, Device Identity, a measurement unit Logical Node, and one or more standardized relay function Logical Nodes.

It should be noted that IEC 61850 allows for arbitrary assembly of Logical Nodes into Logical

Devices The composition of a Logical Device is left to the manufacturer and can always be determined from an instance of a Logical Device via the communications services of ACSI.

The implementation of IEC 61850 Logical Devices and ACSI facilitates seamless communication with substation and field devices, enabling automatic discovery of device properties This capability allows for real-time updates to the control center's database, eliminating the need for manual data entry when changes occur in the field, such as new installations, revisions, or equipment removals.

The TASE.2 models function as a virtual control center, focusing on SCADA operations in a point-oriented manner Unlike traditional systems, these models do not include representations of the physical devices being monitored or controlled.

Management of physical devices in the field is not within the scope of IEC Technical

Committee 57 Working group 7, so there is no provision for configuration of devices or discovery of new devices as there is in the IEC 61850 standards.

Data acquisition with TASE.2 relies on the assumption that topological information linked to point data is stored locally within the power system model at the receiving control center's database TASE.2 facilitates updates to measurement and status values through a unique reference number assigned to each point, which is mutually agreed upon by both sending and receiving control centers during the establishment of Bilateral Tables for access control.

The data models developed to date have evolved as several overlapping models to suit different users Broadly speaking, the models can be classified as:

The control center and distribution management view of a network encompasses a wide array of simplified devices, along with various non-power system elements such as consumers, schedules, documents, and assets This comprehensive perspective is essential for maintaining data consistency across all information exchanges among participating systems.

2 the substation (i.e., protection) view of a smaller number of more complex devices.

Object models are different because they are designed for different applications and users A major area of overlap within IEC Technical Committee 57 standards occurs with:

1 Substation and equipment identification including hierarchical relationships, and

2 discrete and analog status (i.e., measurements) including units and quality.

Annex A provides a comparative overview of various models in the SCADA domain, highlighting that the list is not exhaustive but representative It reveals significant overlap among models for analog measurands, status changes, and control points Notably, future IEC 61970 and IEC 61850 models will overlap in substation and feeder device categories, while areas like contracts and generation show no such overlap.

5 Strategic Use of Reference Architecture for Harmonization and New Work

This paper does not aim to resolve the differences between the identified object and data models However, it proposes that the reference architecture can serve as a foundational tool for identifying areas that require harmonization The following points are recommended as initial starting points.

Adoption of Reference Architecture

To establish a consistent framework, it is essential to agree on a common reference architecture that standardizes terminology and interfaces This architecture will act as a guideline for future projects It is recommended that the reference model presented in this paper undergo review and revision until a consensus is reached.

Use of Common Object Modeling Language

The next step is to agree to a common modeling language It is suggested that the Unified

Modeling Language (UML) has emerged as the standard language for object modeling within IEC Technical Committee 57 It offers various notations, including class diagrams, state diagrams, and event sequence diagrams A significant benefit of UML is the availability of multiple CASE tools that facilitate model preparation, navigation, and the automatic generation of necessary Word documents for IEC standards promotion UML has already been embraced by Working Groups 13 and 14 of IEC Technical Committee 57.

Harmonization at Model Boundaries

As stated earlier, from a harmonization point of view, the two most important places where having identical models really matters are:

At the interfaces where software adhering to one standard interacts with software following a different standard, challenges arise For instance, a SCADA server may collect data using a specific model, such as IEC 60870-5-101, TASE.2, or ACSI, and then needs to provide that data to applications utilizing an alternative model, like CIM.

2 Where these object models purport to represent the same physical real-world object.

For optimal consistency across all interfaces, it is essential to utilize a unified set of models At the very least, the attributes common to both models must maintain uniform naming conventions and data representation In scenarios where object models are required by EMS applications, adopting a control-centric perspective on device models would provide significant benefits.

Resolution of Model Differences

To address model discrepancies with overlapping elements, it is recommended that experts from the relevant working groups collaborate to identify necessary commonalities and establish consistency The aim is to ensure uniform naming and data representation for shared classes or attributes, thereby eliminating the need for naming mappings and data transformations This approach has already been successfully implemented for the majority of SCADA data items within the CIM and ACSI frameworks Additionally, if significant classes or attributes are absent from a model, efforts should be made to incorporate these missing elements.

A proposed reference model for Technical Committee 57 aims to establish a framework for future standards development and to address discrepancies in object models within ongoing standards By offering a comprehensive overview and structure for standards development, the model seeks to enhance understanding among contributors, facilitating the harmonization of IEC Technical Committee 57 object models and ultimately promoting broader acceptance.

IEC Technical Committee 57 standards in new product development and fewer incompatibilities requiring custom adapters and gateways for implementing new computer systems and network for power system control.

Annex A Objects Modeled within IEC Technical Committee 57

The table below highlights key elements of a power system as modeled by various standards from IEC Technical Committee 57 Although this list is not exhaustive, it effectively demonstrates the commonalities among the different standards.

IEC 61850 ACSI IEC 60870- 6 TASE.2 IEC 60870-5-101/

Annex B EPRI Utility Communications Architecture (UCA)

EPRI launched research and development initiatives alongside IEC Technical Committee 57 to create comprehensive standards for integrating power system applications and devices for real-time operations This effort uniquely started with a top-down analysis of the entire electric utility enterprise to identify necessary standards and recommend a common set of protocols within the seven-layer OSI reference model The outcome of this project was the initial version of the UCA.

The application layer standard ISO/IEC 9506 is utilized for all real-time data acquisition and control applications within UCA This MMS specification establishes a standardized message format that facilitates various services, including reading, writing, and reporting of both simple and complex data types, as well as event management, journaling, remote program control, and data and program uploads/downloads The MMS protocol offers a comprehensive real-time network programming environment, supporting a diverse array of distributed applications.

The MMS Forum was established to implement these recommendations, consisting of several teams focused on applying MMS to the six key domains identified in the UCA within a utility.

The exchange of real-time data acquisition and control information within the utility industry breaks down into two primary classes of applications: access to data in real-time databases

(such as energy management system (EMS) and supervisory control data acquisition system

(SCADA)), and access to real-time end devices (switchgear, meters, remote terminal units

RTUs and other related applications exhibit distinct data models and access control needs The MMS services and data representation are designed to accommodate both application classes, albeit with varying data formats and interpretations.

The Control Center team collaborated with the UCS project, an earlier EPRI initiative focused on enhancing control center communications with MMS, to create the ICCP specifications These specifications served as the foundation for the TASE.2 standards established by the IEC Technical Committee.

Committee 57 Working Group 7 marked the successful implementation of MMS within the UCA vision, utilizing object models to define services supported by TASE.2 This approach also incorporated static object models to outline the data structures for exchange, focusing on attributes without methods or operations Additionally, the power plant team embraced ICCP for communication between power plants and control centers, integrating a set of power plant data objects into the TASE.2 standards.

When utilizing the OSI reference model in a specific application environment, it is essential to choose appropriate protocols for each OSI layer, thereby creating a tailored communications profile UCA Version 2.0 features profiles that incorporate protocols from both the OSI model and other standards.

The TCP/IP protocol family includes both connection-oriented and connectionless communication profiles, suitable for local area networks (LAN) and wide area networks (WAN), as well as specialized media like radio For low bandwidth environments and devices with limited processing or memory capabilities, reduced profiles are available, omitting layers three through six and their associated functionalities.

TASE.2 supports models of real-time SCADA database elements as well as a variety of scheduling and other data exchange models TASE.2 standards, as specified in the standards

IEC 60870-6-503, IEC 60870-6-802, and IEC 60870-6-702, were based primarily on input from MMS Forum Control Center Working Group and the earlier EPRI-sponsored UCS project.

The Power Plant team has implemented TASE.2 as the foundation for communications between the power plant and the control center, incorporating a comprehensive set of power plant data objects.

The TASE.2 standards marked the inaugural successful implementation of MMS within the UCA vision, utilizing object models to define the services offered by TASE.2 Additionally, it introduced static object models, which outline the data structures for exchange by detailing attributes without including methods or operations.

The UCA2 project has advanced real-time device access by creating detailed device object models that outline the necessary variables and algorithms for each device class Major vendors of voltage regulators and tap changers have adopted a standardized base object model, ensuring that their devices, when accessed through MMS, offer a consistent set of variables with uniform naming conventions, such as "tap_position," and data formats This standardization enables plug compatibility across different vendors, models, and versions, facilitating basic regulation control.

UCA devices feature self-describing, vendor-independent object models that, along with supporting profiles, offer a unified view of real-time data across the utility enterprise Users can access this data directly from various devices, including substations and customer interfaces, using standard commercial software like MMS browsers, while adhering to security and access controls The technology supports a wide range of platforms, from large-scale systems like EMS to PCs, workstations, and even compact embedded systems such as pole-top field devices and affordable meters.

Tiêu đề	Power system control and associated communications – Reference architecture for object models, services and protocols
Trường học	IEC (International Electrotechnical Commission)
Chuyên ngành	Power System Control and Communications
Thể loại	Technical report
Năm xuất bản	2003
Thành phố	Geneva

Định dạng
Số trang	36
Dung lượng	726,12 KB