SPÉCIFICATION TECHNIQUE CEI IEC TECHNICAL SPECIFICATION TS 61970 401 Première édition First edition 2005 09 Interface de programmation d''''application pour système de gestion d''''énergie (EMS API) – Parti[.]
Généralités
The upcoming CEI 61970-4XX series defines the interfaces that a component or application must implement to exchange information with other components or applications and to access public data through a standardized pathway These component interfaces outline the specific events, methods, and properties that applications can utilize for this purpose, as well as the content of the information exchanged.
The purpose of the CIS is to facilitate integration with independently developed applications or systems While typical applications and components are identified as part of the EMS-API project to assist in defining the types of information that need to be transferred, the goal is not to define specific components It is important for component vendors to remain free to create various sets of component interfaces in bundled offerings, while ensuring compliance with future standards.
1 Voir la CEI 61970-1 pour la liste et la description des catégories d’applications typiques et des systèmes qui sont du domaine d’application de ces normes
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
IEC 61970-1, Energy management system application program interface (EMS-API) – Part 1:
IEC 61970-2, Energy management system application program interface (EMS-API) – Part 2:
Utility Management System (UMS) Data Access Facility (DAF), OMG Adopted Specification,
Version 2.0, formal/02-11-08, November 2002 (Referred to herein as ‘OMG reference 1’)
Data Acquisition from Industrial Systems Specification (DAIS), OMG Adopted Specification,
Version 1.0, formal/02-11-07, November 2002 (Referred to herein as ‘OMG reference 2’)
Historical Data Acquisition from Industrial Systems Specification (HDAIS), OMG Adopted
Specification, dtc/03-02-01, February 2003 (Referred to herein as ‘OMG reference 3’)
OPC Data Access Custom Interface Specification, Version 2.05, OPC file: opcda205_cust.doc,
OPC Foundation, December 17, 2000 (Referred to herein as ‘OPC reference 1’)
OPC Alarms and Events Custom Interface Specification, Version 1.02, OPC file: opcae102_cust.doc, OPC Foundation, November 2, 1999 (Referred to herein as ‘OPC reference 2’)
OPC Historical Data Access Custom Interface Standard, Version 1.1, OPC file: opc_hist_cust.doc, OPC Foundation, January 26, 2001 (Referred to herein as ‘OPC reference 3’)
For the purposes of this part of IEC 61970, the terms and definitions given in IEC 61970-2 apply
The upcoming IEC 61970-4XX series outlines the required interfaces for components or applications to standardize information exchange with other components and access publicly available data These interfaces detail the specific events, methods, and properties that applications can utilize, along with the information content involved in these exchanges.
The CIS aims to enable seamless integration with independently developed applications and systems While the EMS-API project identifies typical applications and components to clarify the types of information to be transferred, it does not seek to define the components themselves Component vendors are encouraged to create diverse collections of component interfaces within their packages, ensuring compliance with the upcoming IEC 61970 series.
1 See IEC 61970-1 for a list and description of the typical application categories and systems within the scope of these standards
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
For message-based exchanges, the primary goal of the CIS is to define the content of the information exchanged between two or more applications, as well as to specify the services used for message transfer This framework enables the development of new applications with prior knowledge of the available information and its format, as well as the expected information and its format from recipient applications Additionally, for integrating existing systems, the CIS facilitates the creation of a single adapter for infrastructure technology, regardless of who develops the other systems.
4.2 Structure documentaire de la CEI 61970-4XX
Multiple component interface services are essential for various application categories, leading to the treatment of service definitions as generic services independent of the applications that utilize them Consequently, these generic services are documented in a series of standards, while the specific application usage and the information exchanged by applications using these generic services are documented in other series The IEC 61970 framework provides an overview of the CIS standards and guidance on their implementation in system integration projects Future parts of IEC 61970, specifically 402 to 449, will specify the generic services supported by component interfaces, detailing standardized interface functionality through explanatory text, UML notation, and Interface Definition Language (IDL) The upcoming IEC 61970-450 will outline the CIS Information Exchange Model, illustrating the use case process for defining information content and providing integration examples Parts 451 to 499 will address specific information exchange requirements for defined application categories, detailing standardized information exchange content, which can be communicated in various formats, including messages, notifications, or XML documents, along with necessary interface properties and methods Supporting documentation will include use cases and event sequence diagrams.
Depending on the type of exchange planned for the application category, specific generic services may be established to ensure interoperability between components developed by different vendors The goal of implementing these standards is to provide maximum flexibility for the middleware.
("middleware") choisi pour effectivement réaliser les échanges d’information tout en continuant d’assurer l’interopérabilité
Le contenu de l’information est documenté dans le Modèle d’Echange d’Information (IEM pour ôInformation Exchange Modelằ) pour chaque catộgorie d’application
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
The primary goal of the Communication Interface Specification (CIS) is to define the content of messages exchanged between applications and the services used for transmission This clarity allows for the development of new applications with a clear understanding of available information and the expectations of receiving applications Additionally, for integrating existing systems, the CIS facilitates the creation of a single adapter that is compatible with any infrastructure technology, regardless of the original developers of the systems involved.
The IEC 61970 series of standards addresses the need for generic component interface services utilized across various application categories These services are documented separately from their specific applications to ensure clarity and usability The CIS Framework provides an overview of these standards and guidance for system implementation and integration Future standards, IEC 61970-402 to 449, will detail the generic services supported by component interfaces, using narrative text and UML notation to standardize interface functionality for information exchange Additionally, IEC 61970-450 will outline the CIS Information Exchange Model, illustrating use case processes and integration examples, while establishing common requirements for subsequent standards Finally, IEC 61970-451 to 499 will focus on the specific information exchange needs of typical application categories, defining standard exchanges as events that can be communicated in various formats, including messages, notifications, or XML documents, along with the necessary properties and methods for each interface Supporting documentation will include use cases and event sequence diagrams.
To ensure interoperability among components from various suppliers, specific generic services may be defined based on the intended type of exchange for the application category The goal of applying these standards is to maximize flexibility in the selected middleware for information exchanges while maintaining interoperability.
The information content is documented in an Information Exchange Model (IEM) for each application category
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
5 Vue générale des normes de service générique API
Cet Article donne une vue générale des services génériques inclus dans la future série
The primary objectives of CEI 61970-4XX generic services are to minimize the efforts required for integrating applications within utility companies These generic services complement broader software industry initiatives, including Java connector architecture, W3C web service recommendations, and Microsoft Net architecture.
The upcoming IEC 61970-4XX standards aim to facilitate and accelerate the adoption of generic technologies within utility companies They will isolate applications from the underlying middleware technology, allowing compliant software components to operate across various middleware technologies, such as message brokers and databases This approach ensures minimal impact on the application environment, even if the underlying middleware technology changes for any reason.
Middleware may need to be replaced or extended after the system is built and operational To fully leverage the Common Information Model (CIM), many APIs fail to adopt a unified data model, often presenting data as a set of records without clear connections CIM provides a framework where individual records, such as a repair order, can be linked to the overall model of the electric network system It is essential to limit the creation of fine-grained APIs that become application-specific, reducing the number of APIs that developers and integrators must learn and minimizing maintenance for control center infrastructure providers A streamlined set of APIs is designed to establish a common data exchange mechanism for all applications while remaining general enough to meet diverse application needs Additionally, preventing the standardization of incompatible control center APIs is crucial, as programmers prefer a consistent and user-friendly set of APIs that do not overlap and offer a complementary programming model across all APIs.
Les services génériques sont basés autant que possible sur les normes internationales existantes ou industrielles En particulier, ces services sont basés sur les normes décrites en
Les normes OPC sont des normes industrielles basées sur les technologies d’OLE Microsoft
ActiveX, COM (Component Object Model), and DCOM (Distributed Component Object Model) are essential technologies in automation OPC, originally known as OLE for Process Control, comprises standardized sets of interfaces, properties, and methods designed for process control and production automation applications.
ActiveX/COM defines the interaction and data sharing between individual software components OPC standards provide a common interface for communication with various process control devices, regardless of the control software or devices involved in the process.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
5 Overview of the generic API service standards
Objectifs des services génériques
Cet Article donne une vue générale des services génériques inclus dans la future série
The primary objectives of CEI 61970-4XX generic services are to minimize the efforts required for integrating applications within utility companies These generic services complement broader software industry initiatives, including Java connector architecture, W3C web service recommendations, and Microsoft Net architecture.
The upcoming IEC 61970-4XX standards aim to facilitate and accelerate the adoption of generic technologies within utility companies They will isolate applications from the underlying middleware technology, allowing compliant software components to function across various middleware technologies, such as message brokers and databases This approach ensures minimal impact on the application environment, even if the underlying middleware technology changes for any reason.
Middleware may need to be replaced or extended after the system is built and operational To fully leverage the Common Information Model (CIM), many APIs fail to adopt a unified data model, often presenting data as a set of records without clear connections CIM provides a framework where individual records, such as a repair order, can be linked to the overall model of the electric network system It is essential to limit the creation of fine-grained APIs that become application-specific, reducing the number of APIs that programmers and integrators must learn and minimizing maintenance for control center infrastructure providers The goal is to establish a common data exchange mechanism that is general enough to meet the needs of all intended applications Additionally, preventing the standardization of incompatible APIs within the control center is crucial, as programmers prefer a consistent and user-friendly set of APIs that do not overlap and offer a complementary programming model across all APIs.
Utilisation des normes existantes
Les services génériques sont basés autant que possible sur les normes internationales existantes ou industrielles En particulier, ces services sont basés sur les normes décrites en
Les normes OPC sont des normes industrielles basées sur les technologies d’OLE Microsoft
ActiveX, COM (Component Object Model), and DCOM (Distributed Component Object Model) are integral technologies in automation OPC, originally known as OLE for Process Control, comprises standardized sets of interfaces, properties, and methods designed for process control and production automation applications.
ActiveX/COM defines the interaction and data sharing between individual software components OPC standards provide a common interface for communication with various process control devices, regardless of the control software or devices involved in the process.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
5 Overview of the generic API service standards
This Clause outlines the generic services that will be featured in the upcoming IEC 61970-4XX series of standards, aimed at reducing the integration effort for utility applications These services complement wider software industry initiatives, including the Java connector architecture, W3C’s Web Services recommendations, and Microsoft’s frameworks.
The future IEC 61970-4XX standards aim to simplify and accelerate the deployment of generic technologies in utility environments by isolating applications from underlying middleware technologies, allowing for flexibility in using various middleware options without significant impact on the application environment Additionally, these standards leverage the Common Information Model (CIM) to establish a unified data framework, ensuring that individual records are contextually related within the overall power system model To streamline integration, a limited set of APIs is defined, reducing the complexity for integrators and minimizing maintenance for control center infrastructure suppliers while still meeting diverse application needs Furthermore, the standards prevent the standardization of incompatible control center APIs, promoting a consistent and user-friendly API set that complements each other without substantial overlap.
The generic services are based on existing international or industry standards to the maximum extent possible In particular, these services are based on the standards described in 5.2.2 and 5.2.3
The OPC standards are industry standards that are based on Microsoft's OLE (now Active X),
COM (Component Object Model) and DCOM (Distributed Component Object Model) are essential technologies that facilitate interaction between software components OPC (originally OLE for Process Control) offers a standardized set of interfaces, properties, and methods tailored for process control and manufacturing automation These ActiveX/COM technologies enable seamless data sharing among individual software components By adhering to OPC standards, users can communicate effectively with various process-control devices, ensuring compatibility across different controlling software and hardware.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
L’organisation qui gère les normes OPC est la fondation OPC La fondation compte plus de
With 300 members globally, including all major suppliers in the instrumentation control and process control systems sector, the organization aims to establish an open, interoperable interface standard This standard is based on the functional requirements of COM, DCOM, and Microsoft’s ActiveX technology, ensuring optimal interoperability among control/automation applications, field systems/devices, and business/office applications.
The OPC standards define APIs for various functionalities; however, only specific sections of these standards are referenced in the upcoming IEC 61970-4XX series In summary, the APIs directly utilized are those that provide services to clients.
– s’abonner aux données de mesure;
– s’abonner aux alarmes et aux événements;
– récupérer et établir des données historiques résidant dans un archivage
The specific APIs integrated into generic services include the Data Access (DA) Custom Interface Specification, an OPC standard that defines various objects for reading and writing timestamped data values with a quality index The defined objects include a server, a group, and an item, with the OPC server object maintaining information about the server and serving as a container for storing group objects.
The OPC group object maintains self-information and provides a mechanism to logically contain and organize OPC items within a dataset OPC items are associated with properties such as value, timestamp, and quality The Alarms and Events (AE) Custom Interface Specification defines the mechanisms for notifying OPC clients about specific event conditions and alarms AE also offers services that allow OPC clients to identify events and conditions managed by the OPC server and obtain their current status Additionally, the Historical Data Access (HDA) Custom Interface Specification outlines several objects for accessing time series data, including methods for synchronizing and desynchronizing reads and writes of time series, as well as subscribing to data updates and callbacks.
Other OPC APIs are indirectly incorporated through their use in OMG standards, as referenced in section 5.2.3 Specific references are provided in the upcoming IEC 61970-4XX standards, which specify the generic services that include these standards.
L’OMG (Object Management Group) a été formé en 1989 pour créer une place de marché pour le logiciel basé sur les composants, par l’introduction d’un logiciel objet normalisé
Currently, this consortium comprises approximately 800 members worldwide, including virtually all major companies in the IT industry and hundreds of smaller firms The organization's charter includes the establishment of guiding principles for the industry and detailed specifications for object management, providing a framework for application development Compliance with these specifications enables the development of a heterogeneous processing environment across all major hardware platforms and operating systems.
Currently, implementations of the OMG specifications can be found across various operating systems worldwide The OMG specification series outlines the standardized interfaces essential for object-oriented distributed computing.
LICENSED TO MECON Limited - RANCHI/BANGALORE FOR INTERNAL USE AT THIS LOCATION ONLY, SUPPLIED BY BOOK SUPPLY BUREAU.
The OPC Foundation, comprising over 300 global members, including leading providers of control systems and process control technologies, oversees the management of OPC standards Its mission is to create an open and interoperable interface standard that leverages Microsoft COM, DCOM, and ActiveX technology, enhancing interoperability among automation applications, field devices, and business systems.
OPC standards define APIs for various functionalities, but only specific sections are referenced in the upcoming IEC 61970-4XX series In summary, the directly utilized APIs are those that offer services for clients.
– subscribe to alarms and events;
– get and set historical data residing in an archive
The article discusses specific APIs integrated into generic services, highlighting two key specifications The Data Access (DA) Custom Interface Specification is an OPC standard that outlines objects for reading and writing data values, including a server, group, and item, which are essential for managing data with quality and timestamps The OPC server object acts as a container for group objects, while the group object organizes OPC items into a dataset, each associated with properties like value, timestamp, and quality Additionally, the Alarms and Events (AE) Custom Interface Specification defines how OPC clients are notified of specific events and alarm conditions, enabling them to determine the supported events and their current status from an OPC server.