EN 61970-1:2006

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Programski vmesnik za sistem za upravljanje energije (EMS-API) - 1. del: Smernice in splošne zahteve (IEC 61970-1:2005)Schnittstelle der Anwendungsprotokolle von Energieverwaltungssystemen (EMS-API) -- Teil 1: Leitfaden und allgemeine AnforderungenInterface de programmation d'application pour système de gestion d'énergie (EMS-API) -- Partie 1: Lignes directrices et exigences généralesEnergy management system application program interface (EMS-API) -- Part 1: Guidelines and general requirements35.200Vmesniška in povezovalna opremaInterface and interconnection equipment29.240.30Krmilna oprema za elektroenergetske sistemeControl equipment for electric power systemsICS:Ta slovenski standard je istoveten z:EN 61970-1:2006SIST EN 61970-1:2007en,fr,de01-november-2007SIST EN 61970-1:2007SLOVENSKI
STANDARD
EUROPEAN STANDARD EN 61970-1 NORME EUROPÉENNE
EUROPÄISCHE NORM May 2006
CENELEC European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung
Central Secretariat: rue de Stassart 35, B - 1050 Brussels
© 2006 CENELEC -
All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 61970-1:2006 E
ICS 33.200
English version
Energy management system application program interface (EMS-API) Part 1: Guidelines and general requirements (IEC 61970-1:2005)
Interface de programmation d'application pour système de gestion d'énergie
(EMS-API) Partie 1: Lignes directrices et exigences générales (CEI 61970-1:2005)
Schnittstelle der Anwendungsprotokolle von Energieverwaltungssystemen
(EMS-API) Teil 1: Leitfaden und allgemeine Anforderungen (IEC 61970-1:2005)
This European Standard was approved by CENELEC on 2005-12-01. CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the Central Secretariat or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to the Central Secretariat has the same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom.
at national level by publication of an identical
national standard or by endorsement
(dop)
2006-12-01 – latest date by which the national standards conflicting
with the EN have to be withdrawn
(dow)
2008-12-01 Annex ZA has been added by CENELEC. __________ Endorsement notice The text of the International Standard IEC 61970-1:2005 was approved by CENELEC as a European Standard without any modification. In the official version, for Bibliography, the following note has to be added for the standard indicated: IEC 61968 NOTE
Harmonized in the EN 61968 series (not modified). __________ SIST EN 61970-1:2007

- 3 - EN 61970-1:2006 Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. NOTE Where an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD applies. Publication Year Title EN/HD Year IEC 61970-2 – 1) Energy management system application program interface (EMS-API)
Part 2: Glossary
CLC/TS 61970-2 2005 2) IEC 61970-301 – 1) Energy management system application program interface (EMS-API) Part 301: Common Information Model (CIM) base EN 61970-301 2004 2)
1) Undated reference. 2) Valid edition at date of issue. SIST EN 61970-1:2007

NORME INTERNATIONALECEIIEC INTERNATIONAL STANDARD 61970-1Première éditionFirst edition2005-12 Interface de programmation d'application pour système de gestion d'énergie (EMS-API) – Partie 1: Lignes directrices et exigences générales
Energy management system application program interface (EMS-API) – Part 1: Guidelines and general requirements
Pour prix, voir catalogue en vigueur For price, see current catalogue IEC 2005
Droits de reproduction réservés

Copyright - all rights reserved Aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l'éditeur. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher. International Electrotechnical Commission,
3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, SwitzerlandTelephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch
Web: www.iec.ch CODE PRIX PRICE CODE X Commission Electrotechnique InternationaleInternational Electrotechnical CommissionSIST EN 61970-1:2007

61970-1  IEC:2005 – 3 – CONTENTS FOREWORD.7 INTRODUCTION.11 1 Scope.13 2 Normative References.13 3 Terms and definitions.13 4 System integration.15 4.1 Integration scenarios.15 4.2 Integration considerations.15 4.3 Component-based interfaces.21 4.4 Relationship to IEC 61968 series of standards.23 5 EMS-API reference model.25 5.1 General.25 5.2 Control center environment.27 5.3 Application context.27 5.4 Application.27 5.5 Component.29 5.6 Legacy application and wrappers.29 5.7 Component model.31 5.8 Component container.33 5.9 Component adapter.33 5.10 Component execution system.35 5.11 Middleware.35 5.12 Communication profiles.37 5.13 Reference model examples.37 6 EMS-API standards.41 6.1 General.41 6.2 CIM (IEC 61970-3XX).41 6.3 CIS (IEC 61970-4XX).47 6.4 CIS technology mappings (IEC 61970-5XX).49 7 General expected infrastructure functionality.49 7.1 General.49 7.2 Component Container.51 7.3 Middleware.53 7.4 Communication Profile Services.53 7.5 Utility-specific services.55
Annex A (informative)
Component models.57 Annex B (informative)
Typical applications and functions.65 Annex C (informative)
Utility issues with standard component models.75 Annex D (informative)
Examples of component execution systems
and middleware products.79
Bibliography.81
61970-1  IEC:2005 – 5 – Figure 1 – EMS-API Reference Model.25 Figure 2 – EMS using EMS-API component standard interfaces.39
Table 1 – Benefits of Component-based Interfaces.23 Table 2 – Examples of EMS application contexts.27 Table B.1 – Typical applications and functions.65
61970-1  IEC:2005 – 7 – INTERNATIONAL ELECTROTECHNICAL COMMISSION ___________
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 1: Guidelines and general requirements
FOREWORD 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations. 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user. 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter. 5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any equipment declared to be in conformity with an IEC Publication. 6) All users should ensure that they have the latest edition of this publication. 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication. 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights. IEC shall not be held responsible for identifying any or all such patent rights. International Standard IEC 61970-1 has been prepared by IEC technical committee 57: Power systems management and associated information exchange. The text of this standard is based on the following documents: FDIS Report on voting 57/777/FDIS 57/795/RVD
Full information on the voting for the approval of this standard can be found in the report on voting indicated in the above table. This publication has been drafted in accordance with the ISO/IEC Directives, Part 2. SIST EN 61970-1:2007

61970-1  IEC:2005 – 9 – IEC 61970 consists of the following parts, under the general title Energy management system application program interface (EMS-API): Part 1:
Guidelines and general requirements
Part 2:
Glossary Part 301:
Common Information Model (CIM) base
Part 302:
Common information model (CIM) financial, energy scheduling and reservations1 Part 401:
Component interface specification (CIS) framework Part 402:
Component interface specification (CIS) – Common services1 Part 403:
Component Interface Specification (CIS) – Generic data access1 Part 404:
Component Interface Specification (CIS) – High speed data access1 Part 405:
Component Interface Specification (CIS) – Generic eventing and subscription1 Part 407:
Component Interface Specification (CIS) – Time series data access1 Part 453:
Exchange of Graphics Schematics Definitions (Common Graphics Exchange)1 Part 501:
Common Information Model (CIM) XML Codification for Programmable Reference and Model Data Exchange The committee has decided that the contents of this publication will remain unchanged until the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific publication. At this date, the publication will be
• reconfirmed; • withdrawn; • replaced by a revised edition, or • amended.
___________ 1 Under consideration. SIST EN 61970-1:2007

61970-1  IEC:2005 – 11 – INTRODUCTION This standard is part of the IEC 61970 series that defines application program interfaces (APIs) for an energy management system (EMS). This standard is based to a large extent upon the work of the EPRI Control Center API (CCAPI) research project (RP-3654-1). The principle objectives of the EPRI CCAPI project are to: – reduce the cost and time needed to add new applications to an EMS or other system2; – protect the investment in existing applications that are working effectively; – improve the capability to exchange information between disparate systems both within and external to the control center environment. The technical approach is to provide an integration framework for interconnecting existing applications/systems that is – based on a common architecture and information model; – independent of the underlying technology. The principal task of the IEC 61970 series of standards is to develop a set of guidelines and standards to facilitate 1) the integration of applications developed by different suppliers in the control center environment3 and 2) the exchange of information to systems external to the control center environment. The scope of these specifications includes other transmission systems as well as distribution and generation systems external to the control center that need to exchange real-time operational data with the control center. Therefore, another related goal of these standards is to enable the integration of existing legacy systems as well as new systems built to conform to these standards in these application domains.
The complete set of standards includes the following parts: Part 1:
Guidelines and general requirements Part 2:
Glossary Part 3XX:
Common Information Model (CIM)
Part 4XX:
Component Interface Specification (CIS) Part 5XX:
CIS Technology Mappings IEC 61970-1 provides a set of guidelines and general infrastructure capabilities needed for the application of the EMS-API interface standards. It describes the reference model that provides the framework for the application of the other parts of the EMS-API standards. This reference model is based on a component architecture, which places the focus of the standards on component interfaces for information exchange between applications in a control center environment. The model is also applicable to similar information exchanges between control center applications and systems external to the control center environment, such as other control centers, Independent System Operators (ISOs), Regional Transmission Organizations (RTOs), and Distribution Management Systems (DMS). IEC 61970-1 also includes general capabilities for the integration infrastructure, which while not part of this standard, is expected to provide certain essential services to support the EMS-API interface standards.
___________ 2 Ideally, an application should be installed on a system with minimal effort and no modification of source code; i.e., the way software packages are installed on a desktop computer. The EMS-API Project goal is to at least approach that ideal by reducing the often significant efforts currently required to install third-party applications in an EMS. 3
The control center environment includes traditional transmission control within a utility as well as the newer Independent System Operators (ISOs) and Regional Transmission Operators (RTOs), which are not affiliated with any one utility. SIST EN 61970-1:2007

61970-1  IEC:2005 – 13 – ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 1: Guidelines and general requirements
1 Scope This part of the IEC 61970 series provides a set of guidelines and general infrastructure capabilities required for the application of the EMS-API interface standards. This part of the IEC 61970 series describes typical integration scenarios where these standards are to be applied and the types of applications to be integrated. A reference model is defined to provide a framework for the application of the other parts of these EMS-API standards. This reference model is based on a component architecture that places the focus of the standards on component interfaces for information exchange between applications in a control center environment. While the primary objective of
the EMS-API is to support the integration of applications within the control center, the reference model is also applicable to information exchanges between control center applications and systems external to the control center environment, such as other control centers, ISOs, RTOs, and distribution systems. This standard describes the role of the other parts of the standard, including the Common Information Model (CIM) in the IEC 61970-3XX series, the Component Interface Specifications (CIS) in the IEC 61970-4XX series, and Technology Mappings in the IEC 61970-5XX series. This part of the IEC 61970 series also includes general capabilities that are needed by the integration infrastructure to facilitate the exchange of information via the component interfaces specified by the CIS. While the integration infrastructure itself is not part of this standard, it is expected to provide certain essential services to support the EMS-API interface standards. These services are enumerated in Clause 6.
This part of the IEC 61970 series does not specify individual implementations or products, nor does it constrain the representation of information within a computer system application. This standard specifies the externally visible interfaces, including semantics and syntax, required to support the interoperability of products supplied by different vendors. 2 Normative References The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. IEC 61970-2, Energy management system application program interface (EMS-API) – Part 2: Glossary IEC 61970-301, Energy management system application program interface (EMS-API) – Part 301: Common Information Model (CIM) base 3 Terms and definitions For the purposes of this document, the terms and definitions given in IEC 61970-2 apply. SIST EN 61970-1:2007

61970-1  IEC:2005 – 15 – 4 System integration 4.1 Integration scenarios Energy management systems are an assemblage of various software subsystems (SCADA, generation control, load forecast, etc.). The guidelines created for this area (or portions thereof) apply to several different integration scenarios. This work recognizes that existing systems with their unique interfaces will need to evolve to use the interfaces specified in this work. The following different types of integration situations are envisaged. While these are typical scenarios, they are only a subset of the possible examples. a) Integration of applications developed by different suppliers into one homogenous system:
In this scenario, independently developed application components (such as an Optimal Power Flow (OPF)) are integrated into a system (which includes supporting infrastructure). This allows the system integrator to more easily integrate an individual component into any system, whether it is an existing system or a newly developed system. b) On-line data exchange between separate systems:
The control center needs to communicate with other, separate systems within the corporation and between enterprises. Loosely coupled integration schemes are needed to exchange information. Examples include information exchanges with a DMS, the corporate accounting system, or another EMS. Enterprise integration scenarios generally fit into this category. c) Integration of separate systems sharing some engineering data:
This corresponds to the situation where application packages from different vendors use partly overlapping engineering modeling data (such as the impedance of a line segment). d) Exchange of serialized data between the same applications in different systems:
Limited integration can be achieved by using file transfer techniques. An agreed upon format is used for this type of export/import exchange. The use of File Transport Protocol (FTP) and an eXtensible Markup Language (XML)-based format file (or document) for the exchange of power sysem models is an example of this scenario. e) Developing a new application in a homogenous system:
This corresponds to vendors or utilities developing new applications for integration into their existing systems (as opposed to integration in other systems) using these standards for the application interface. 4.2 Integration considerations 4.2.1 General The scope of integration to be supported by these standards falls into two loosely defined categories: a) Integration of software components to implement an EMS or similar system. b) Integration of independent systems. SIST EN 61970-1:2007

61970-1  IEC:2005 – 17 – To properly interact, both software components and systems need a Common Information Model (CIM) to provide a common, consistent meaning (i.e., semantics) to the information exchanged or accessed. For example, to exchange information about a transformer impedance, the classification of the piece of equipment as a transformer is needed together with the attribute name for the impedance value. With this information, a particular instance of a transformer can be identified with its corresponding impedance. The semantic name of these real world objects (together with their attributes, descriptions, and relationships to other real world objects) is provided by the CIM (see 6.2). However, in other respects, these two categories of integration as discussed in the following clauses have slightly different needs. The intent of the EMS-API series of standards is to address both, and both are viewed as presenting component interfaces. 4.2.2 Integration of software components into a system 4.2.2.1 General To integrate independently developed software components into a system, several issues need to be addressed. a) Software component interactions:
Software components need to interact in a collaborative fashion for the system to function properly. This interaction can be in the form of property access, method invocation, and event handling. The public interfaces consisting of properties, methods, and events shall be identified, and a contract on their use shall be specified in order to support integration of software components. Where similar interaction scenarios exist within the system, the specification of consistent interface patterns simplify system integration and maintenance. b) Public engineering model data for initialization:
The physical power system and related information is simulated with engineering data as reflected in the CIM. Software components share aspects of this engineering data to perform their functions. Upon software component start-up, a component needs to be initialized with a consistent, accurate model of the real-world system it is simulating. A common interface for access to this public, shared data provides a consistent mechanism for software components to initialize their internal models. Once initialized, software component interaction mechanisms can be used to keep their engineering models up to date. c) Packaging for deployment:
Software components need to be realized in specific forms for packaging and delivery to system integration. A few major technology frameworks exist in the software industry today, each with their own format for packaging. The specification of standards should promote flexibility in implementation possibilities while facilitating the integration of independently developed software. To accomplish this, software component interactions should be specified in an abstract form that is capable of particular technology and language specializations. To support this type of integration scenario, the properties, methods, and events used at the component interface need to be standardized as well as the data content of the information exchange. SIST EN 61970-1:2007

61970-1  IEC:2005 – 19 – 4.2.2.2 Application categories The scope of the EMS-API standards includes all applications typically found within a control center environment as well as interfaces to external systems needed to support real-time operations. However, since the intent of the EMS-API standard is to define interface standards rather than to define standard applications, the scope of the project can best be understood by considering the list of application categories that will be supported by the EMS-API standards. The actual packaging of component interfaces specified in the CIS into applications is left to the application suppliers; therefore, any attempt to define a list of individual applications by name would unnecessarily constrain suppliers.
The list of application categories and typical applications supported by this standard can be found in Table B.1. The following is a summary of the list: • supervisory Control and Data Acquisition (SCADA); • alarm processing; • topology processing; • network applications; • load management; • generation control; • load forecast; • energy/transmission scheduling; • accounting settlements; • maintenance scheduling; • historical information archival; • data engineering; • generic user interface; • dynamic simulation; • dispatcher training simulator; • external systems (e.g., DMS, weather, wholesale power marketing, etc.). 4.2.3 Integration of systems In the integration of heterogeneous systems, where there is likely to be no similarity in the operating environment nor control over it, the emphasis is more on supporting loosely coupled, asynchronous “document” exchanges. In this context, a “document” may be thought of as a large, rich data structure, such as an XML document. Document exchange implies that the data exchanged is complex, structured, and self-describing. The exchange is more likely to involve individual, atomic information transfers where all information regarding how to handle the information and/or action requested in the transfer is self-contained, rather than multi-step transactions where the handling of the information transfer may be contingent upon previous information transfers or events.
61970-1  IEC:2005 – 21 – 4.3 Component-based interfaces One goal of the EMS-API standards is to encourage the independent development of reusable software components and facilitate their integration in the construction of control center systems through the development of component interface standards. The software industry, including the major Energy Management System (EMS) vendors and suppliers of application software for an EMS, has undergone an evolution from basing software engineering concepts on top down modular software design to object-oriented approaches to the latest refinement using component-based architectures. The component models embraced by the Common Object Request Broker Architecture (CORBA®)4, Sun®5’s Enterprise Java Beans® (EJB®), and Microsoft®6’s Distributed Common Object Modeling (DCOM) best exemplify this trend. (See Annex A for a description of these three component models).
These component-based approaches also facilitate the integration of software and complete systems from various sources. For this type of any-to-any integration, XML Web Services provide another Internet-based integration model. XML Web services allow applications to communicate and share data over the Internet using the type of information exchange earlier referred to as “document exchange,” regardless of operating system or programming language. These services provide another example of a component execution environment becoming more prevalent in Business-to-Business (B2B) information exchanges. (See Annex A for a description of XML Web Services). The effect on the EMS-API is to shift the focus to developing standards for software component interfaces for exchanging and accessing public information rather than on standardizing the integration framework services that provide these capabilities. The expectation is that applications that adhere to these standards can then be individually delivered and reused in multiple systems. While other infrastructure services may be needed in an actual system, such as directory services and security, these are not the goal of this standard. In fact, they may be more properly considered the domain of the system integrator or system supplier (i.e., part of the EMS system platform, not a reusable plug-and-play component).
The goal is not to develop standard interfaces for middleware. In fact, the goal is just the opposite – to be independent of any particular set of middleware services. This allows integrators to select the right type and scale of infrastructure for each system. It allows service designs to evolve and innovate, and it simplifies component development as well.
It also means that a software developer does not have to deal directly with these services. The system integrator provides the “glue” to insert these components into the system environment.
This gives the integrator more freedom to configure components and choose the services best suited to the needs of the system being implemented (i.e., performance, availability, etc.). ___________ 4
CORBA is the trade name of a product supplied by OMG. This information is given for the convenience of users of this International Standard and does not constitute an endorsement by IEC of the product named. Equivalent products may be used if they can be shown to lead to the same results. 5
Sun is shorthand for Sun Microsystems, a USA-based corporation. This information is given for the convenience of users of this International Standard and does not constitute an endorsement by IEC of the company named.
Microsoft is shorthand for Microsoft Corporation, a USA-based corporation. This information is given for the convenience of users of this International Standard and does not constitute an endorsement by IEC of the company named. SIST EN 61970-1:2007

61970-1  IEC:2005 – 23 – The following two examples illustrate this independence of components: – CORBA components specifically do not require the use of CORBA Notification (or any particular service) as its event system. – COM+ components are written exactly the same way whether they are deployed in an environment with or without Distributed Transaction Coordinator (DTC) and/or a Microsoft Message Queue (MSMQ). Table 1 lists some of the benefits of this component-based approach to interface standards. Table 1 – Benefits of Component-based Interfaces Explicitly addresses the EMS-API project software plug-and-play goal Does not prescribe an overall system design nor the choice and design of services Aligns with overall software industry direction to permit the use of mainstream tools to develop components and configure systems Frees the EMS-API project from rediscovering and reinventing solutions for the many problems of "plug-and-play" software
Provides a more complete solution including important areas such as packaging (what goes on the component disc CD), documentation, versioning, etc.
Does not require designing and/or prescribing middleware services, particularly event, naming and transaction services, but rather permits the use of commercially-available products to provide these services Provides a canonical form for the utility specific standards developed on the project, enabling developers to directly machine-translate interface definitions into their preferred interface language: Object Management Group (OMG)/International Standards Organization (ISO) Interface Definition Language (IDL), Java®7 interface syntax or Microsoft IDL Allows the EMS-API project to focus on designing interfaces and events for utility applications without having to wait for all the middleware problems to be solved. This permits vendors to get to market quicker with EMS-API-compliant interfaces in their application products
4.4 Relationship to IEC 61968 series of standards The IEC 61968 series of standards deals with system interfaces for distribution management systems. There is a great deal of similarity between these standards and those contained in the IEC 61970 series of standards, not only because of some overlap in scope, but because the IEC 61968 series of standards are also based on the CIM. The IEC 61968 series of standards build on the CIM Base specified in IEC 61970-301 wherever possible by extending it to include additional specializations of existing classes, but also adding entirely new sets of classes to model objects found in the distribution problem domain. Therefore, to comprehend the entire scope of the CIM, it is necessary to review both the IEC 61970 and IEC 61968 series of standards which deal with the CIM.
The IEC 61968 series of standards are also concerned with defining standard information exchanges between distribution business functions, similar to the IEC 61970-4XX standards, but do not attempt to define application program interfaces (i.e., services to be implemented by components). However, the IEC 61968 series of standards envision that the standard messages defined therein can be transferred over the APIs defined in these IEC 61970 series of standards. ___________ 7 Java is the trade name of a product supplied by Sun Microsystems. This information is given for the convenience of users of this International Standard and does not constitute an endorsement by IEC of the product named. Equivalent products may be used if they can be shown to lead to the same results. SIST EN 61970-1:2007

61970-1  IEC:2005 – 25 – 5 EMS-API reference model 5.1 General The EMS-API reference model is an abstract architecture that provides a visualization of the problem space being addressed, provides a language for describing and discussing solutions, defines terminology, and provides other similar aids toward achieving a mutual understanding of the problem being solved with the EMS-API standards. The reference model is not a design, nor is it intended to describe software layers, although a layering approach is hard to avoid and is implied. The primary function is to show clearly which parts of the problem space are the subject of the EMS-API standards, and by contrast, which are outside the domain of the EMS-API project and why. It is also intended to show how different parts of the standard relate to each other. Figure 1 is a diagram of the reference model, with the shaded areas representing those portions of the reference model that are the subject of this standard. The non-shaded areas represent parts of a system that are essential for creating a framework for reusable application components. Each part of the model is discussed later in this document.
Common Information Model(CIM) 61970-3XX SeriesComponent
Interface Specs(CIS) 61970-4XX SeriesComponent adapterComponent container APIComponent containerMiddleware servicesCommunication profilesIEC StandardsApplication information exchangeand data access softwareComponent adapterApplication 2Application 1Component A Model encode/ decode ComponentBModelencode/decodeLegacy wrapperLegacy applicationLegacy applicationAPIComponent execution system Persistent storageApplications and components Component execution services:- Naming - Events - Transactions - Persistence - Security ComponentB interfacesComponent A interfaces Component interfacesIEC
2297/05
Figure 1 – EMS-API Reference Model SIST EN 61970-1:2007

61970-1  IEC:2005 – 27 – 5.2 Control center environment The reference model is specifically intended to apply to control center environments, which typically comprise networks of computers connected by Local Area Networks (LANs) and sometimes Wide Area Networks (WANs). A control center may include a variety of systems in support of utility operations, including EMS, DMS, and other systems needed for ISO and RTO business functions. It supports a number of different user groups and organizational functions, including on-duty operators, supervisors, operator training, operations planning, database maintenance, and software development. In an EMS, many applications are used in a number of these contexts, and it is important that an application can be easily configured (preferably automatically) for use in multiple contexts. This is accomplished through the use of properties that are associated with each component interface rather than through changes to the internal code of the component. 5.3 Application context An application context comprises a collection of applications working together as an organizational unit to accomplish some high-level objective.8 An application context defines a time frame and an environment for execution. Table 2 includes examples of contexts for EMS applications: Table 2 – Examples of EMS application contexts Real Time On-line control of the power system Operations Study Execution of network applications to study and/or analyze operations practices (near-term) Extension Planning Study Execution of network and/or simulation studies to evaluate alternatives (future/long term) Training Provide training environment for operators, requiring simulation and analysis applications
While not shown explicitly in the reference model, it is understood that several contexts may exist simultaneously, each involving potentially the same applications in different data exchanges. Furthermore, there may be multiple instances of a particular context coexisting. For example, there may be two or more studies running in parallel for two different operators in the Operations Study context, while concurrently the same applications are executing in the Real Time context. 5.4 Application An application comprises one or more components that perform some business function in a given domain. It is designed and written by a domain expert. The granularity of the components comprising the application is the designer’s choice. Application builders can combine components from different developers or different vendors to construct an application. ___________ 8
It should be noted that the term context is used differently in the discussion of component models for EJB and CORBA, for example, where context is used in connection with a component container providing component implementations with access to the runtime services implemented by the container. These services include transactions, security, events, and persistence. SIST EN 61970-1:2007

61970-1  IEC:2005 – 29 – An application developer should be able to make full use of a component without requiring access to its source code. Components can be customized to suit the specific requirements of an application through a set of external property values. For example, the button component has a property that specifies the name that should appear on the button. Of course, the amount of customization allowable depends on the foresight of the component developer in providing sufficient external property values. This is somewhat equivalent to the older concept in program design of customizing a program through specifying appropriate values for configurable parameters rather than having to modify source code.
Refer to Table B.1 for a list of application categories, abstract names, and functions performed. 5.5 Component A component is a reusable software building block. It is a pre-built piece of encapsulated application code that can be combined with other components and with handwritten code to rapidly produce a custom application.
In order to qualify as a component, application code shall provide a standard interface that enables other parts of the application to invoke its functions and to access and manipulate the data within the component. The component model defines the structure of the interface. Components vary in their granularity. A component can be very small, such as a simple Graphic User Interface (GUI) widget (e.g., a button) or it can implement an entire complex application, such as a state estimator a
...