Iec 61970 1 2005

NORME INTERNATIONALE CEI IEC INTERNATIONAL STANDARD 61970 1 Première édition First edition 2005 12 Interface de programmation d''''application pour système de gestion d''''énergie (EMS API) – Partie 1 Ligne[.]

Scénarios d'intégration

Les systèmes de gestion d'énergie sont un assemblage de divers sous-systèmes logiciels

Guidelines in the field of SCADA, production control, and load forecasting apply to various integration scenarios It is recognized that existing single-interface systems must evolve to utilize the specified interfaces Different integration situations are considered; while these are typical scenarios, the following examples represent only possible subsets: a) Integration of applications developed by different vendors into a cohesive system.

In this scenario, independently developed application components, such as Optimal Power Flow (OPF), are integrated into a system that supports the necessary infrastructure This allows the system integrator to more easily incorporate individual components into either an existing or newly developed system Additionally, there is online data exchange between distinct systems.

The driving center must interact with various distinct systems within the company and with other businesses Information exchange requires the use of loosely coupled integration schemes, such as with a Distribution Management System (DMS), the company's accounting system, or other Enterprise Management Systems (EMS) Typically, business integration scenarios fall into this category, focusing on the integration of separate systems that share technical data.

In this scenario, application software from various vendors utilizes partially overlapping technical modeling data, such as the impedance of a line segment Additionally, there is a series data exchange between identical applications across different systems.

Limited integration can be achieved through file transfer techniques, which require an agreed-upon exchange format An example of this scenario is using the File Transfer Protocol (FTP) along with a file formatted in Extensible Markup Language (XML) to exchange network templates Additionally, developing a new application within a homogeneous system is also a viable approach.

This refers to suppliers or utility companies that are developing new applications intended to be integrated into their existing systems, utilizing the current standards for application interfaces.

Considérations sur l'intégration

The scope of integration covered by these standards is broadly categorized into two areas: a) the integration of software components for the implementation of an EMS or a similar system, and b) the integration of independent systems.

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

Energy management systems consist of various software subsystems, such as SCADA, generation control, and load forecasting The established guidelines for this field apply to multiple integration scenarios, acknowledging that existing systems with unique interfaces must adapt to the specified interfaces Several integration situations are anticipated, including the integration of applications from different suppliers into a cohesive system.

In this scenario, independently developed application components (such as an Optimal

Power Flow (OPF)) are integrated into a system (which includes supporting infrastructure)

The system integrator can seamlessly incorporate individual components into both existing and newly developed systems, facilitating efficient online data exchange between separate systems.

Effective communication between the control center and various independent systems within the corporation, as well as across enterprises, is essential To facilitate this, loosely coupled integration schemes are required for seamless information exchange This includes interactions with systems such as Document Management Systems (DMS), corporate accounting systems, and other Energy Management Systems (EMS) Typically, enterprise integration scenarios fall under this category, particularly when integrating separate systems that share engineering data.

Application packages from various vendors often utilize partially overlapping engineering modeling data, such as line segment impedance Additionally, there is a need for the exchange of serialized data between identical applications across 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

An example of this scenario is the use of File Transfer Protocol (FTP) along with an XML-based format for exchanging power system models Additionally, the development of a new application within a homogeneous system is highlighted.

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

The standards support two main categories of integration: a) the integration of software components for implementing an Energy Management System (EMS) or similar systems, and b) the integration of independent systems.

To ensure effective interaction between software components and systems, it is essential to use a Common Information Model (CIM) that provides a consistent and coherent meaning (i.e., semantics) to the exchanged or queried information For instance, when sharing information about a transformer's impedance, the equipment must be classified as a transformer, along with the attribute name for the impedance value This information allows for the precise identification of a transformer based on its corresponding impedance The semantic names of these real-world objects, along with their attributes, descriptions, and relationships with other real-world objects, are provided by the CIM model.

However, the two categories of integration discussed in the following articles differ slightly in other aspects The EMS-API standard collection aims to address both categories, as they are regarded as having component interfaces.

4.2.2 Intégration de composants logiciels dans un système

Plusieurs problèmes doivent être résolus avant d'intégrer des composants logiciels développés de manière indépendante dans un système a) Interactions des composants logiciels:

The interaction of software components must be collaborative for the system to function correctly This interaction can occur through property access, method invocation, or event handling Public interfaces, consisting of properties, methods, and events, should be clearly identified, and a contract for their usage must be specified to support the integration of software components When similar interaction scenarios exist within a system, specifying consistent interface forms simplifies integration and maintenance Additionally, public technical model data is essential for initialization.

The physical electrical system and its associated information are simulated using technical data as outlined in the CIM model Software components share aspects of this technical data to perform their functions Before launching a software component, it must be initialized with a consistent and accurate model of the real-world system it simulates A common interface for accessing shared public data provides a coherent mechanism for software components to initialize their internal models Once the software components are initialized, interaction mechanisms can be employed to update the technical models.

Software components must be packaged and delivered in specific formats for system integration The current software industry features several key technological frameworks, each with its own packaging format It is essential for standard specifications to enhance implementation possibilities by facilitating the integration of independently developed software To achieve this goal, it is important to define interactions between software components in an abstract form that can adapt to specific technological and language specializations.

To effectively manage this type of integration scenario, it is essential to standardize the properties, methods, and events utilized at the component interface level, along with the data content of the exchanged information.

To properly interact, both software components and systems need a Common Information

The Common Information Model (CIM) ensures a unified and consistent understanding of exchanged or accessed information For instance, to communicate details about a transformer's impedance, it is essential to classify the equipment as a transformer and specify the attribute name for the impedance value This allows for the identification of a specific transformer instance along with its corresponding impedance The CIM provides the semantic names of these real-world objects, including their attributes, descriptions, and relationships to other objects.

The EMS-API series of standards aims to meet the distinct needs of two categories of integration, each presenting unique component interfaces.

4.2.2 Integration of software components into a system

To integrate independently developed software components into a system, several issues need to be addressed a) Software component interactions:

Interfaces basées sur des composants

The EMS-API standards aim to promote the independent development of reusable software components and facilitate their integration into the construction of control center systems by establishing interface standards for these components.

L'industrie du logiciel, y compris les principaux fournisseurs de Systèmes de Gestion d'Energie

The evolution of Emergency Medical Services (EMS) and application software providers for EMS has transitioned from modular software design concepts to object-oriented approaches, culminating in the latest refinement of component-based architectures This trend is prominently illustrated by the component models adopted by CORBA® 4 (Common Object Request Broker Architecture).

Broker Architecture), EJB® (Enterprise Java Beans)® de Sun® 5 et DCOM (Distributed

Common Object Modeling) de Microsoft® 6 (Voir l’Annexe A pour une description de ces trois modèles de composants)

Component-based approaches facilitate the integration of software and complete systems from diverse sources XML web services provide a model for seamless integration over the Internet, allowing applications to communicate and share data regardless of operating system or programming language These services exemplify a growing component runtime environment increasingly used in business-to-business (B2B) information exchanges.

In the context of EMS-API, the focus is shifting towards developing standards for software component interfaces that facilitate the exchange and access of public information, rather than standardizing the integration framework services that provide these capabilities The aim is for applications that comply with these standards to be offered individually and reused across multiple systems While additional infrastructure services, such as directory and security services, may be necessary in a real system, they are not covered by this standard These services are rightly considered the responsibility of the system integrator or provider, as they are part of the EMS system platform rather than reusable, off-the-shelf components.

The goal is not to create standard interfaces for middleware but rather to ensure independence from any specific set of middleware services This approach enables integrators to accurately choose the type and scale of infrastructure needed for each system, while allowing service designers to evolve and innovate, thereby simplifying the development of components.

This means that a software developer is not required to interact directly with specific services The system integrator acts as the "glue" that allows these components to be integrated into the system environment They have greater flexibility in configuring components and selecting the services that best meet the needs of the system being implemented, such as performance and availability.

CORBA is the commercial name of a product distributed by OMG This information is intended for users of the current international standard and does not imply that IEC endorses or recommends the exclusive use of the specified product Equivalent products may be utilized if it is demonstrated that they yield the same results.

5 Sun is an abbreviation for Sun Microsystems, a company based in the United States This information is provided for the users of the current international standard and does not imply that IEC endorses or recommends this company.

Microsoft, short for Microsoft Corporation, is a company based in the United States This information is provided for the users of the current international standard and does not imply that the IEC endorses or recommends this company.

The EMS-API standards aim to promote the independent development of reusable software components and enhance their integration in control center systems through standardized component interfaces The software industry, particularly major Energy Management System (EMS) vendors and application software suppliers, has evolved from top-down modular design to object-oriented approaches, ultimately refining these concepts with component-based architectures.

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)

Component-based approaches enable the seamless integration of software and complete systems from diverse sources XML Web Services offer an Internet-based integration model for any-to-any connectivity, allowing applications to communicate and share data over the Internet This model utilizes "document exchange" for information sharing, independent of the operating system or programming language used.

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 EMS-API's focus is shifting towards developing standards for software component interfaces that facilitate the exchange and access of public information, rather than standardizing the integration framework services This approach aims to enable applications that comply with these standards to be delivered individually and reused across various systems While additional infrastructure services, such as directory services and security, may be necessary for a complete system, they fall outside the scope of this standard and are more appropriately the responsibility of system integrators or suppliers, as they pertain to the EMS system platform rather than being reusable plug-and-play components.

The primary objective is to maintain independence from specific middleware services rather than creating standard interfaces This flexibility enables integrators to choose the most suitable infrastructure for each system, fostering innovation and evolution in service designs while also simplifying component development.

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.)

CORBA, a product offered by OMG, is mentioned for user convenience in this International Standard This reference does not imply IEC's endorsement of the product Users may opt for equivalent products, provided they demonstrate the ability to achieve the same outcomes.

5 Sun refers to Sun Microsystems, a corporation based in the USA This information is provided for user convenience and does not imply any endorsement by the IEC of the mentioned company.

Relations avec les normes de la série CEI 61968

The IEC 61968 series focuses on system interfaces for distribution management systems There are many similarities between these standards and those of the related series.

The CEI 61970 standard overlaps with various application domains and is closely related to the CEI 61968 series, which is also based on the CIM model.

The IEC 61968 standard builds upon the CIM foundation established in IEC 61970-301 by expanding it to include additional specializations of existing classes and introducing new class sets for model objects related to distribution issues Therefore, it is essential to analyze both series of standards, IEC 61970 and IEC 61968, to fully understand the application domain of the CIM model.

Les normes de la série CEI 61968 ont également pour objet la définition des échanges d'informations standard entre des fonctions de gestion de la distribution, à l'instar des normes

CEI 61970-4xx; cependant, mais elles ne visent pas à définir des interfaces de programmation d'application (c'est-à-dire les services à mettre en oeuvre par les composants) La série

CEI 61968 prévoit cependant la possibilité de transférer les messages standard, tels qu'ils y sont définis, aux API définies dans les normes de la série CEI 61970

Java is a commercial product distributed by Sun Microsystems This information is intended for users of the current international standard and does not imply that the IEC endorses or recommends the exclusive use of this designated product Equivalent products may be utilized if it is demonstrated that they yield the same results.

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

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

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

The EMS-API project enables the design of interfaces and events for utility applications without delays caused by middleware issues This approach allows vendors to expedite their market entry 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

The IEC 61968 series of standards, which are based on the Common Information Model (CIM), extend the CIM Base defined in IEC 61970-301 by incorporating additional specializations and introducing new classes to effectively model objects within the distribution problem domain To fully understand the CIM's scope, it is essential to examine both the IEC 61970 and IEC 61968 standards.

The IEC 61968 series of standards focuses on establishing standard information exchanges between distribution business functions, akin to the IEC 61970-4XX standards However, it does not define application program interfaces (APIs) for component implementation Instead, it anticipates that the standard messages outlined in the IEC 61968 series can be transmitted over the APIs specified in the IEC 61970 series.

Java, a product offered by Sun Microsystems, is mentioned for user convenience in this International Standard This reference does not imply IEC's endorsement of Java, and users may opt for equivalent products that demonstrate comparable results.

5 Modèle de référence EMS-API

Généralités

The EMS-API reference model is an abstract architecture that visualizes the problem space being addressed It provides a language for describing and analyzing solutions, establishes terminology, and offers additional aids that enhance mutual understanding of the issues the EMS-API standards aim to resolve.

The reference model is not a design in itself and is not intended to describe software layers; however, a layered approach appears implicit and unavoidable Its primary function is to clearly indicate the aspects of the problem space relevant to the EMS-API standards domain, while excluding those outside the scope of the EMS project.

API et de justifier ces choix Il a également pour objet de mettre en évidence les liens entre les différentes parties de la norme

Figure 1 illustrates a reference model, where the shaded areas indicate the portions covered by the current standard The unshaded areas represent essential parts of a system that establish a framework for reusable application components This document addresses all aspects of the model.

(CIM) Série 61970-3xx Spécification d’interfaces de composants (CIS)

Conteneur du composant API Conteneur composant Services intergiciels Profils de communication

Codage et décodage du modèle

Interfaces du composant A Interfaces de composants

Codage et décodage du modèle

Figure 1 – Modèle de référence EMS-API

The EMS-API reference model serves as an abstract architecture that visualizes the addressed problem space, facilitates a common language for discussing solutions, defines essential terminology, and offers various aids to foster a mutual understanding of the issues being resolved through EMS-API standards.

The reference model is not a design or a description of software layers, although a layering approach is often implied Its main purpose is to clarify the aspects of the problem space addressed by the EMS-API standards and to delineate what falls outside the EMS-API project's scope and the reasons for this distinction Additionally, it aims to illustrate the relationships between different components of the standard.

Figure 1 illustrates the reference model, highlighting the shaded areas that pertain to this standard, while the non-shaded areas indicate essential components for establishing a framework for reusable application components Each section of the model will be elaborated on in subsequent sections of this document.

Component Interface Specs (CIS) 61970-4XX Series

Component container API Component container Middleware services Communication profiles

Application information exchange and data access software

Model encode/ decode Legacy wrapper

Figure 1 – EMS-API Reference Model

Environnement du centre de conduite

The reference model is specifically designed for control center environments, typically involving local area networks (LAN) and occasionally wide area networks (WAN) A control center may include multiple systems that support the operations of a utility service company.

An Energy Management System (EMS) integrates with a Distribution Management System (DMS) and other essential systems for managing Autonomous Network Operators (ANOs) and Regional Transport Organizations (RTOs) It supports various user groups and organizational functions, including service operators, supervisors, operator training, operational planning, database maintenance, and software development In an EMS, numerous applications are utilized across these contexts, making it crucial to easily configure (preferably automatically) applications for multiple uses This configuration is achieved by associating properties with each component interface rather than altering the internal code of the component.

Contexte d'application

An application context consists of a group of applications that collaborate as an organizational unit to achieve high-level objectives It establishes a timeline and an execution environment Examples of EMS application contexts are provided in Table 2.

Tableau 2 – Exemples de contextes d'application EMS

Temps réel Commande en ligne du système électrique

Etude des opérations Exécution d'applications réseau pour étudier et/ou analyser des pratiques d'opérations (très court terme)

Etude de la planification de l'extension

Exécution d'études réseau et/ou simulation pour évaluer d'autres solutions possibles (à l'avenir/à long terme)

Formation Fournit un environnement de formation pour les exploitants, nécessitant la simulation et des applications d'analyse

Although the reference model does not explicitly state it, multiple contexts can obviously exist simultaneously, each potentially involving the same applications in different data exchanges Additionally, several instances of a particular context can coexist For instance, two or more studies may operate in parallel for different operators within the "Operations Study" context, while the same applications run in the "Real-Time" context.

Application

An application consists of one or more components that perform management functions within a specific domain It is designed and developed by a domain expert The granularity of the components within the application is determined by the designer's choice Application generators can integrate components from various developers or suppliers to create a cohesive application.

It is important to note that the term "context" is used differently in relation to component models for EJB and CORBA In this case, context refers to a component container that implements components with access to runtime services provided by the container, which include transactions, security, events, and persistence.

The reference model is designed for control center environments, which typically consist of computer networks connected via Local Area Networks (LANs) and occasionally Wide Area Networks (WANs) These centers support various utility operations through systems like Energy Management Systems (EMS), Distribution Management Systems (DMS), and others essential for Independent System Operator (ISO) and Regional Transmission Organization (RTO) functions They cater to diverse user groups, including operators, supervisors, and those involved in training, planning, database maintenance, and software development In an EMS, applications must be easily configurable for different contexts, ideally through automatic adjustments using properties linked to each component interface, rather than modifying the internal code.

An application context is a set of applications that collaborate as a cohesive unit to achieve a specific high-level goal It establishes both a time frame and an execution environment Examples of contexts for EMS applications are provided in Table 2.

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

Extension Planning Study Execution of network and/or simulation studies to evaluate alternatives

Training Provide training environment for operators, requiring simulation and analysis applications

The reference model implies the existence of multiple contexts that can operate simultaneously, often involving the same applications across various data exchanges Additionally, it is possible for several instances of a specific context to coexist.

In the context of Operations Studies, multiple studies may be conducted simultaneously for different operators, while the same applications are running concurrently.

An application consists of multiple components that execute specific business functions within a particular domain, crafted by a domain expert The level of detail in these components is determined by the designer Application developers have the flexibility to integrate components from various developers or vendors to create a cohesive application.

8 It should be noted that the term context is used differently in the discussion of component models for EJB and

CORBA utilizes context within a component container to grant component implementations access to essential runtime services These services encompass transactions, security, events, and persistence, enhancing the functionality and reliability of the components.

An application developer should be able to fully utilize a component without needing access to its source code Components can be customized to meet specific application requirements through a set of external property values For instance, a button component has a property that specifies the name to be displayed on the button The extent of permissible customizations depends on the external property values defined by the component developer This approach is akin to the traditional programming design concept, which allows for program customization by specifying appropriate values for configurable parameters instead of altering the source code.

Le Tableau B.1 fournit une liste des catégories d'applications, des noms abstraits et des fonctions réalisées.

Composant

A component is a reusable software functional block, essentially a prefabricated piece of application code that can be combined with other components and custom-written code to quickly create a tailored application.

To be classified as a component, an application code must offer a standard interface that allows other parts of the application to invoke its functions and access internal data for processing The component model outlines the structure of this interface.

Components vary in granularity, ranging from small elements like a simple graphical user interface (GUI) object, such as a button, to complex applications like a state estimator In the latter case, the application may be designed from scratch as a single component or may include a legacy application wrapped to comply with component interface standards.

Un composant peut être installé sur un support transportable, tel qu'un CD, et expédié pour être utilisé dans un système fournissant des conteneurs de composants

Generally, components openly expose methods, properties, and events through an integration infrastructure Events are particularly significant as they facilitate the integration of independently developed components By utilizing a standard set of events, Component A does not need to be aware of the details of the interface with Component B or even know that Component B exists The key aspect is that the standard focuses on the interface with the component rather than the integration infrastructure.

Application héritée et enveloppeurs

A legacy application slightly differs from the previously defined concept of an application It can be a standalone application that performs management functions, which a utility company may have purchased or developed before establishing any component models for integration Additionally, it may refer to a comprehensive system that acts as a source and/or repository for data required or published by other systems that need to be integrated to facilitate information exchange.

Une application héritée est par exemple:

– une application de gestion de production mise en oeuvre dans FORTRAN sans égard aux interfaces de composants;

An application developer can utilize a component fully without needing access to its source code, as components can be tailored to meet specific application needs through external property values For instance, a button component includes a property that defines the displayed name on the button The extent of customization available is contingent upon the component developer's foresight in offering adequate external property values This approach parallels the traditional programming practice of customizing software by adjusting configurable parameters instead of altering the source code.

Refer to Table B.1 for a list of application categories, abstract names, and functions performed

A component serves as a reusable software building block, consisting of pre-built, encapsulated application code This allows for seamless integration with other components and custom handwritten code, enabling the rapid development of tailored applications.

To qualify as a component, application code must offer a standard interface that allows other application parts to invoke its functions and access its data The component model outlines the structure of this interface.

Components vary in their granularity A component can be very small, such as a simple

A Graphic User Interface (GUI) widget, such as a button, can serve as a standalone element or be part of a more complex application, like a state estimator This application may be developed from the ground up as a single component or involve integrating a legacy application to meet component interface standards.

A component can be put on a transportable medium, such as a CD, and shipped for use in a system that provides component containers

Components typically expose methods, properties, and events through an integration infrastructure, with events being crucial for integrating independently-developed components By adhering to a standard set of events, Component A can operate without needing to know specific details about Component B or its existence The essential aspect is that the standardization applies to the component's interface rather than the integration infrastructure itself.

A legacy application differs significantly from standard application definitions, as it can refer to a standalone application fulfilling a specific business function, which may have been acquired or developed before any integration model was established Additionally, it can represent a complete system that serves as a source or sink for data required or published by other systems, necessitating integration to enable effective information exchange.

– a Unit Commitment application implemented in FORTRAN without regard for component interfaces;

A complete EMS transmission without published open interfaces is essential for providing SCADA data to distribution networks and, conversely, for receiving updates of its electrical system model from fault management systems.

An inherited wrapper enables the encapsulation of a legacy application or system that does not comply with component interface standards It transforms the input and output data of a legacy program into one or more component interfaces, allowing it to engage in information exchange within a component-based architecture.

Using a legacy wrapper enables a legacy application/system to operate as a ready-to-use component that can exchange information with other components through a common infrastructure or framework.

Legacy wrappers can be designed and implemented by domain experts who developed or own the legacy application/system, such as the EMS provider, who then supplies the wrapper for use across multiple installations utilizing component technology If the legacy program is a customized and isolated "enterprise" application, the system integrator may need to create a wrapper that will be used exclusively on a single system.

Modèle de composants

A component model outlines the fundamental architecture of a component by specifying the structure of its interfaces and the interaction mechanisms with the component, its container, and other components It provides guidelines for creating and implementing components that can work together to form a larger application.

A component generator should not be required to implement multiprocess processing, concurrent access control, resource pooling, security, and transaction management within each component If these services were to be integrated into every component, it would be challenging to achieve a truly ready-to-use set of applications The component model standardizes and automates the utilization of these services.

There are four main component models widely used in the current software industry, as detailed in Appendix A The industry has recognized that eliminating the dependency on containers or infrastructure by components marks a significant advancement towards a future where components can be developed, assembled, and deployed independently However, since there are four distinct models, component providers may offer slightly different versions of each model to leverage the full capabilities of the underlying container and execution system, as well as their inherent performance While this is not strictly necessary, if component providers impose design restrictions to ensure compatibility across the four models, any differences can be addressed through component adapters provided by the system integrator In some cases, the system integrator may opt to combine multiple component technologies and utilize transitional technologies to enable interoperability among different systems.

(par exemple, un système d'exécution CORBA fonctionnant avec un système d'exécution

– an entire transmission EMS without open, published interfaces that is needed to supply

SCADA data to distribution systems and in turn receive updates to its power system model from outage management systems

A legacy wrapper serves to encapsulate legacy applications or systems that do not meet component interface standards It transforms the input and output of a legacy program into one or more component interfaces, enabling participation in information exchange within a component-based system architecture.

A legacy wrapper enables a legacy application or system to function as a plug-and-play component, facilitating seamless information exchange with other components through a unified infrastructure or framework.

Legacy wrappers can be created by the domain expert of the legacy application, such as the EMS vendor, for use across multiple system installations utilizing component technology In contrast, if the legacy program is a unique custom "enterprise" application, the system integrator may need to develop the wrapper, which would then be applicable to a single system only.

A component model outlines the fundamental architecture of a component, detailing its interface structure and interaction mechanisms with its container and other components It offers essential guidelines for developing and implementing components that collaborate effectively to build a larger application.

A component builder should avoid the repetitive implementation of multithreading, concurrency control, resource pooling, security, and transaction management in every component If each component required these services, achieving seamless plug-and-play application assembly would be challenging A standardized component model automates and streamlines the utilization of these essential services.

The software industry recognizes four widely accepted component models, detailed in Annex A, which emphasize the importance of eliminating container or infrastructure awareness from components This shift aims to enable independent development, assembly, and deployment of components While component vendors may choose to create tailored versions for each model to leverage the full capabilities of the underlying container and execution system, this customization is not mandatory.

Component vendors must design their products to function correctly across four models, allowing system integrators to use component adapters for specific implementations Additionally, integrators can combine multiple component technologies and employ bridging solutions, such as enabling interoperability between a CORBA execution system and a Microsoft DCOM execution system.

Conteneur de composants

Components operate within a container, which serves as a context for one or more components while providing management and control services In practical terms, a container offers an operating system process or a thread for the component, isolating it from the execution platform.

When a client calls a component server, the container automatically allocates a processing execution unit and initiates the component The container manages all resources on behalf of the component and oversees all interactions between the component and external systems.

Component containers are typically provided by the system vendor as an integral part of the component execution system Standard services offered for components include naming, events, transactions, security, and persistence However, not all services required for a real-time application in a utility company may be included in the standard container services provided by commercial software vendors Appendix C outlines how these services can be implemented in a real-world scenario.

Adaptateur de composant

The operations and behaviors of a container are defined by its component model, which establishes a contract for the services and interfaces provided Consequently, components designed for a specific execution environment are generally not transferable to another To reuse a component in different execution systems, a component adapter is necessary If this is not feasible, component interfaces can be defined according to a neutral standard, requiring an adapter to align standard interfaces with those provided by the container This concept resembles the "transferability layer" integral to the Java Enterprise platform, which serves as the execution system for EJB components.

Un adaptateur de composant est défini comme une partie de logiciel située entre l'application

The component adapter serves as a crucial element within the component container and integration infrastructure, offering essential support services such as publish/subscribe mechanisms, message queuing, and naming It can handle protocol differences, data transformation, and translation as needed Additionally, the adapter may provide component support for security, transactions, and persistence, particularly when the component's runtime environment does not offer these services externally.

Component adapters address the discrepancies between a) the component interface, the chosen runtime environment, and container technology, and b) a component interface and other component interfaces utilized throughout the system, including variations in event definitions These discrepancies arise due to several factors.

The system comprises independently developed components whose interfaces were not coordinated in advance, indicating a lack of compliance with standards, which is likely a common scenario.

– Le système comporte des composants partiellement normalisés, mais les parties non normalisées ne sont pas compatibles

– Bien qu'elles soient normalisées, certaines parties ne sont pas compatibles car elles correspondent à différentes versions de la norme

Components operate within a container, which serves as a context for managing and controlling one or more components In real-world applications, a container typically provides an operating system process or thread for component execution, effectively insulating it from the underlying runtime platform When a client requests a server component, the container automatically allocates a process thread and initiates the component Additionally, the container oversees all resource management and facilitates interactions between the component and external systems.

Component containers are essential elements supplied by the system provider, forming a crucial part of the component execution system They typically offer services such as naming, events, transactions, security, and persistence However, not all services required for a utility real-time application may be included in the standard offerings from commercial software suppliers For detailed implementation of these services, refer to Annex C.

The operations and behaviors of a container are defined and dictated by its component model

The component model establishes a contract for the provision of container services and interfaces Consequently, components designed for a specific execution system or environment are typically not directly transferable to different execution environments.

Therefore, in order to achieve reuse with multiple execution systems, a component adapter is required for any execution system except the one for which the component was designed

Component interfaces can be established based on a neutral standard, necessitating a component adapter for all containers to translate these standard interfaces into those offered by the container This approach is similar to the "portability layer" found in the Java Enterprise Platform, which serves as the component execution system for EJB.

A component adapter is a software intermediary that connects an application or component to the component container and integration infrastructure, offering essential services such as publish/subscribe, message queuing, and naming It can also handle protocol differences, data transformation, and translation as needed Furthermore, the adapter can enhance component support for security, transactions, and persistence, especially when the execution environment lacks these features.

Component adapters address the discrepancies between the component interface and the selected execution system environment and container technology, as well as the variations between different component interfaces within the system This encompasses differences in event definitions, which emerge due to these inconsistencies.

– The system is made up of independently developed components whose interfaces were not coordinated in advance (i.e., not standardized, which is probably the usual case)

– The system contains partially standardized components, but the non-standard parts are incompatible

– The standardized parts are still incompatible because they reflect different versions of the standard

Depending on the environment and the tools provided by the component container, the component adapter can connect the component's event portals to the appropriate event domains and locate the corresponding dependency components, if they exist.

Component adapters can implement specific services required for the operation of components within predefined EMS contexts, which are not available with commercial component execution systems.

A system integrator or execution system provider typically offers component adapters, which are codes designed to align event types, data types, and services of one component with those of other components within a specific implemented system Additionally, these adapters configure the information flows for the component As a result, system integrators customize these adapters to fit the specific system and component requirements.

Système d'exécution de composants

The components of a server operate within an environment provided by an application or a component execution system The term "component execution system" encompasses the entire reference model, from the container layer to the lower layers, including the component container, middleware services, and communication profiles It also includes other platform services that are typically hidden, such as the operating system and persistent storage These systems are referred to as container systems because the container serves as the primary interface to the interface standards outlined in this specification.

Container systems include existing middleware that adheres to the contract and policies established for the container model adopted by the system's component framework Any execution framework that complies with the container contract for component support is valid For instance, an EMS provider can design an EMS application execution system to support containers, enabling the use of both internally developed components and those purchased from other component suppliers.

L'Annexe D comporte d'autres exemples commerciaux de ce type

Les systèmes d'exécution de composants sont généralement donnés par le fournisseur du système.

Intergiciel

The term "middleware" refers to a diverse range of software products that serve as an integration, conversion, and/or translation layer Middleware offers generic interfaces for events, messaging, data access, transactions, and more.

Middleware providers offer products that support specific combinations of generic services through their proprietary interfaces Typically, they do not focus on a particular industry, although they often provide converters for widely used applications, such as PeopleSoft® 9.

SAP and other providers may or may not offer all the necessary services for a real-time operations environment in a utility company Each utility company can select different middleware providers based on their specific operational decisions.

PeopleSoft is the commercial name of a product distributed by Oracle This information is intended for users of the current international standard and does not imply that the IEC endorses or recommends the exclusive use of the specified product Equivalent products may be utilized if it can be demonstrated that they yield the same results.

The component adapter may link the component's event portals to relevant event topics and identify the necessary dependency components, depending on the environment and tools offered by the component container.

Component adapters can provide essential utility services required for components to function effectively within the previously identified EMS contexts, which are not typically offered by standard component execution systems.

A system integrator or execution system supplier provides custom component adapters, which are essential for ensuring compatibility between different components within a system These adapters consist of code designed to align event types, data types, and services expected by each component with those of other components in the implemented system Additionally, they configure the information flows for each component, making them uniquely tailored to the specific system and component requirements.

Server components operate within an environment established by an application or component execution system, which includes the entire reference model from the container layer down This system comprises the component container, middleware services, and communication profiles, along with other essential platform-supplied services such as the operating system and persistent storage Often referred to as container systems, these environments provide the primary interface to the interface standards outlined in this standard.

Container systems consist of middleware products that comply with the container contract and the component model policies of the system Any execution framework that meets the container contract criteria for supporting components is eligible For instance, an EMS supplier can create an EMS application execution system that supports containers, allowing the integration of both internally developed and externally sourced components Additional commercial examples can be found in Annex D.

The system supplier typically provides component execution systems

Middleware refers to a variety of software products that serve as an integration, conversion, and translation layer It offers generic interfaces for events, messaging, data access, and transactions, facilitating seamless communication between different applications and systems.

Middleware vendors offer products that deliver a range of generic services through proprietary interfaces While these vendors typically do not focus on specific industries, they often include converters for popular applications like PeopleSoft® 9 and SAP.

They may or may not provide all the services needed in a utility real-time operations environment

PeopleSoft, a product offered by Oracle, is mentioned here for the convenience of users of this International Standard This reference does not imply any endorsement of the product by the IEC.

Equivalent products may be used if they can be shown to lead to the same results

Licensed to MECON Limited in Ranchi/Bangalore for internal use only, supplied by Book Supply Bureau Information technology is implemented at the enterprise level to establish company-specific standards that are not easily modified Component interface standards are crucial for maintaining consistency and efficiency.

EMS-API doivent donc être écrites de sorte à pouvoir être déployées avec des produits intergiciels variés

Middleware is continually evolving It is essential that the EMS-API component interface standards do not rule out the use of higher-quality available products, provided that an integration effort is made Appendix D includes commercial examples of this type.

Tiêu đề	IEC 61970-1 2005
Trường học	Not specified
Chuyên ngành	Energy Management System
Thể loại	Guidelines and general requirements
Năm xuất bản	2005
Thành phố	Not specified

Định dạng
Số trang	90
Dung lượng	817,65 KB