Iec tr 62325 101 2005

TECHNICAL REPORT IEC TR 62325 101 First edition 2005 02 Framework for energy market communications – Part 101 General guidelines Reference number IEC/TR 62325 101 2005(E) L IC E N SE D T O M E C O N L[.]

Generic Open-edi standards

The IEC 62325 series is based on ISO/IEC 14662 and Internet technologies, notably on XML

(Extensible Markup Language) of the W3C (Word Wide Web Consortium) with references to existing or emerging standards or de-facto standards for global e-business

IEC 60870-6 (all parts), Telecontrol equipment and systems – Part 6: Telecontrol protocols compatible with ISO standards and ITU-T recommendations

IEC 61968 (all parts), Application integration at electric utilities – System interfaces for distribution management

IEC 61970 (all parts), Energy management system application program interface (EMS-API)

IEC 62210, Power system control and associated communications – Data and communication security

ISO/IEC 14662, Information technology – Open-edi reference model

UN/CEFACT Modelling Methodology (UMM), NO90 R12 or higher

UN/CEFACT Meta Model, NO90 R10 or higher

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

UN/CEFACT XML Naming and Design Rules, draft 2004 4

UN/CEFACT Core Components Technical Specification

In this part of IEC 62325, RFCs (Request For Comments) from the Internet Engineering Task

Force (IETF) and recommendations from other Organisations such as the Word Wide Web

The Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) are referenced in the previous sections, but their specific documents are not included in this article.

Sectorial Open-edi standards

Market modelling based on this implies to some extent sectorial standards At the moment no references are given

Terms and definitions

Abbreviations

BDS Business Document Specification (instance)

BDSS Business Document Specification Schema

BPMS Business Process Management System

BPSS Business Process Specification Schema (or instance)

CC Core Component (based on BIE)

DSO Distribution System Operator (of power system)

DUNS Data Universal Numbering System (North America)

EAN European Article Number (Europe) ebXML electronic business XML

ICT Information and Communication Technology

MIME Secure/Multipurpose Internet Mail Extensions

SAML Security Assertion Mark-up Language

SCADA Supervision, Control, and Data Acquisition

SMTP Simple Mail Transfer Protocol

SO System Operator (of power system)

SOAP Simple Object Access Protocol

TSO Transmission System Operator (of power system)

UMM UN/CEFACT Modelling Methodology

WSDL Web Services Definition Language

XKMS XML Key Management Specification

Communication and data networks

Many market participants need to communicate with each other in the energy market In the

IEC 62325 series, it is assumed that e-business in energy markets makes use of Internet, which is public, unreliable and insecure in a reliable and secure manner (see Figure 1)

Process data with IEC 60870-6 (TASE.2), Business data,

Figure 1 – Energy market communication over the Internet

Within the market, other types of networks besides the Internet also are possible by agreement, as shown by Table 1

Table 1 – Type of data networks

Internet Cheap, unreliable, insecure Public

Virtual private network (VPN) Secure logical network in the Inter- net

Uses the Internet in a closed user group for trusted partners Extranet Private physically separated network For trusted partners

Market participants primarily engage in a 'one-to-many' communication pattern rather than a general 'any-to-any' approach For instance, transmission system operators and power exchanges maintain a 'one-to-many' relationship with traders.

Clearing service providers, such as those facilitating supplier changes, maintain a one-to-many relationship with distribution service providers and suppliers Energy brokers, who offer trading information without engaging in trading themselves, also exhibit a one-to-many relationship with traders Consequently, it is essential for the communication hubs at the "one-to" end of these relationships to establish standardized business communication interfaces for market participants, utilizing an agreed-upon technology Given that e-business technologies are designed for global operations, including the discovery of previously unknown business partners, it is crucial to streamline the numerous technological options into a minimal profile that meets essential requirements.

Business areas and processes

In the energy market, electricity and gas are generated, traded, and supplied to consumers, requiring a constant balance between generation and supply to ensure network security Both producers and customers have equal access to the energy network, allowing customers to choose their suppliers in a deregulated environment The commercial operations of energy networks for transmission and distribution remain transparent to all market participants, regardless of the physical infrastructure involved Additionally, essential services are necessary to support market functions, including participant registration, network access, supplier changes, customer relocations, metering, data collection, account settlement, and billing.

The energy supply chain consists of three main phases: trading planning, trading operational, and system operation In the trading planning phase, energy consumption is forecasted, and trading strategies are developed The trading operational phase involves executing trades to align with forecasts and allocating generation resources accordingly The system operation phase ensures the physical flow of energy from generation through transmission and distribution to consumers, maintaining balanced schedules for generation, import/export, and consumption This phase guarantees real-time balancing of generation and consumption, ensuring system reliability Additionally, various support services are essential, such as settlement services, which manage billing for consumption and address operational imbalances, holding the Balance responsible for any discrepancies between scheduled and actual generation and consumption.

Responsible Parties (traders and others)

Services (registration, metering, settlement, billing)

System operation (scheduling and balancing) generation production

Generation production Tradingtrading Supplysupply Consumption consumption

Change of supplier Sell energy

Table 2 outlines the business areas, associated processes, and roles of market participants in the energy sector For a simplified market model that provides context for e-business in energy markets, refer to IEC 62325-102 It's important to note that nomenclature may vary across different markets Certain business processes are categorized as energy services, suggesting they can be outsourced to service providers Additionally, while suppliers and sub-suppliers, such as aggregators of consumption, play a role, they are not included in this discussion.

When discussing 'market participants', it is essential to interpret this as 'market participant roles' rather than referring to specific companies This distinction is crucial because a single market participant can fulfill multiple roles For instance, a distribution utility may act as a distribution system operator, a distribution service provider, a supplier, and an energy service provider, all while adhering to the regulations of a specific system.

Table 2 – Business areas, processes and market participants

Business area Business process Roles of involved market participants

Bilateral trading Trader, central matching service provider (confirmation)

Bidding at power exchange Trader, Power exchange Financial clearing Trader, clearing responsible parties Auxiliary services trading Trader, transmission system operator

Cross boarder auctioning Trader, transmission system operator Supply

Selling energy to end consumers Supplier Transmission

Registration, network access and transmission

Transmission system operator, transmission service provider, generators, customers

Registration, network access and distribution

Distribution system operator, distribution service provider, generators, customers

Scheduling consumption and generation Transmission system operator, balance responsible parties (trader, supplier, generator)

Scheduling import/export Transmission system operator, balance responsible parties (trader)

Operation (Balancing) Transmission System operator, generators (auxiliary services) Energy services Service provider, etc many market participants

Metering (meter readings) Customer, distribution service provider, metering service provider Access to collected metering data Supplier, trader, metering service provider

Settlement of accounts of consumption and generation

Service provider, supplier, generator, etc

Settlement of accounts of imbal- ance Transmission system operator, balance responsible parties (trader, supplier, generators), service provider

Change of supplier Customer, supplier, distribution service provider Relocation of customer Customer, supplier, distribution service provider Exchange of market metadata Customer, supplier, distribution service provider

Performance

Table 3 outlines the essential performance requirements regarding the duration of message interactions among market participants, ensuring that a business process concludes within a specified timeframe This duration represents the maximum end-to-end time for message transport, excluding application processing time It's important to note that these requirements can vary across different markets and should be clearly defined within each project.

Business area Business process Process period Maximum duration of interaction

Generation planning Next hour, day, month < 1 min Trading

Bilateral trading Next day, next month, next year, next years

Brokering Next day, next month, next year, next years

Bidding at power exchange Intra day, next day < 5 s

Financial Clearing Intra day, next day, next week, next month, next year, next years

Selling energy to end consumers Month < 1 day Transmission

Network access, contract Month < 1 day Distribution

Network access, contract Month < 1 day System operation

Planning (scheduling) Next hour, next day < 1 min Auxiliary services Next day < 2 min to 4 h Energy services

Metering (readings) Week, month < 1 day Access to collected metering data Day, week, month < 1 h

Settlement of accounts of consumption and generation

Settlement of accounts of imbal- ance

Clearing of change of supplier Month (week, day) < 1 day Change of supplier Week, month < 1 day Relocation of customer Month < 1 day Exchange of market metadata Week, month < 1 day

In B2B peer-to-peer network setups over the Internet, message transfer times are generally under 5 seconds, ensuring efficient communication However, in portal network configurations that utilize hubs with push-pull mechanisms and intermediate message storage, the time taken for message transport is influenced by the retrieval of stored messages This scenario is also applicable to dial-up connections.

(SMTP) In portal network configurations with routing, the duration of message transport depends on the throughput at peak load

Quality of service

Quality of Service (QoS) focuses on ensuring reliable and secure messaging transfer It is essential for service parameters to be configurable, allowing for the use of specific profiles tailored to the energy market These profiles are influenced by the network utilized and the associated business processes.

Network communication can experience issues such as message loss, corruption, duplication, and out-of-sequence delivery, leading to unreliable service Additionally, systems may fail, and messaging services can be disrupted by network failures Without effective countermeasures, the reliability of network services remains compromised.

Table 4 outlines the reliability risks and corresponding countermeasures, which include persistent storage of messages to safeguard against system failures or interruptions, as well as error notifications to the application regarding messaging issues.

Lost Acknowledgement with re-transmission after time out

Corrupted Acknowledgement with re-transmission after time out

Out of sequence Sequence control with sequence number

Not accepted Unsigned or signed delivery receipt

A dependable messaging service must implement strategies to ensure consistent performance, particularly in the face of an unreliable Internet connection It is essential for such a service to address the risks outlined in Table 4, as reliability is crucial for specific business processes conducted online.

The energy market, like all e-business sectors, relies heavily on security measures due to the vulnerabilities of the Internet and the necessity of adhering to legal standards As a niche within the broader e-business landscape, energy enterprises face the challenge of operating without specific regulatory requirements tailored to their sector Potential security risks and corresponding countermeasures are outlined in Table 5.

Annex B addresses key security aspects that influence the deployment and utilization of e-business technologies, specifically within the framework of IEC 62210, focusing on computerized supervision, control, metering, and protection systems in electrical utilities.

Non-repudiation of origin and receipt Audit trails, logging of messages

- of origin Digital signed messages

- of receipt Digital signed acknowledgements and receipts

Loss of integrity of messages Message digest and digital signatures of messages

Loss of confidentiality Encryption of messages

Wrong identity Authentication of origin with digital signatures and credentials

Unauthorized access and fraud Authorisation with access control lists based on digital signatures

Forged date and time Authentication of date and time within a message

A secure messaging service should provide a secure service taken into account the risks stated in Table 5

Security needs and levels must be integrated into a business process model, although this aspect falls outside the scope of this section of IEC 62325 For detailed guidance, refer to the relevant parts of the standard.

IEC 62325 series) should be used

5 Application of the Open-edi reference model

The Open-edi reference model

The e-business architecture and the IEC 62325 series follow the Open-edi reference model

ISO/IEC 14662 emphasizes the separation of business transactions into two key components: the Business Operational View (BOV) and the Functional Service View (FSV) This model facilitates the mapping of services, ensuring that communication technology remains independent.

Business aspects of business transactions

Information technology aspects of business transactions

Business aspects of business transactions

Information technology aspects of business transactions

T R A N S A C T I O N S (ISO/IEC 14662 Information technology – Open-edi reference model) -

Governed by UN/CEFACT Unified Modeling Methodology (UMM), N090

Figure 3 – The Open-edi reference model

Market structure and business views

The IEC 62325 series posits that the energy market is composed of various business areas utilizing a unified e-business communication infrastructure It also suggests that, in addition to distinct market models within each business area (specific BOV), the overlap and interaction among these areas result in shared market models (common BOV) Figure 4 illustrates the market structure and perspectives.

Common business models, messages and core components

Re-usable business models, messages and IT infrastructure cross markets and business areas

ICT = Information and Communication Technology

Figure 4 – Energy market structure and views

6 The Open-edi architecture for deregulated energy markets

Delimitation: market versus process

In deregulated energy markets, market participants decide ‘who’ produces ‘how’ much energy

The decisions regarding 'where' and 'when' in the supply chain influence customer choices of suppliers in retail, while suppliers select traders in wholesale, and traders choose generators Notably, the energy network operates as a natural monopoly.

The market focuses on the economic selection and timely delivery of products and energy-related services, often within hours This process relies on the dependable and secure operation of technical systems.

The technical process of generation, transmission, and distribution underpins market transactions and ensures the reliable and secure operation of the system This includes facilitating energy exchanges and maintaining real-time balance between generation and load, with adjustments occurring within seconds for load-frequency control and milliseconds for local protection.

The commercial and technical systems in the market are interdependent, with each side influencing the other For instance, the scheduled plans of market participants regarding generation and load can indirectly affect the overall process.

The energy market must adjust to reported congestion and outages, highlighting the importance of e-business in facilitating the connection between the market and operational processes This interface is a crucial component of the overall market structure.

In the context of market communications, a series of standards on the process side deal with control centres and are to some degree, closely interrelated with market transactions:

The IEC 60870-6 series (TASE.2) focuses on the communication of process data between control centers, including energy exchange schedules This communication can also be facilitated through e-business technologies outlined in the IEC 62325 series via a process Extranet, utilizing the same technology for interfacing between the market and the process, as well as between control centers.

The IEC 61970 and IEC 61968 series of standards enhance the integration of applications within control centers, enabling seamless interactions with external operations and information sources necessary for real-time management These standards establish interfaces for distributed management systems, facilitating effective information exchange with various IT systems Both series focus on the Integration Bus (IB) and the Common Information Model (CIM), ensuring a cohesive framework for operational efficiency.

CIM model may also include parts that are influenced by the market, for example scheduling for energy exchange, reservation, and financial.

Conventions

The energy market, like other markets, has distinct legal, commercial, and technical requirements that can vary significantly across different regions and market structures While there is a trend towards convergence due to liberalization, it is essential for all market participants to reach a shared understanding of the justification, requirements, business rules, and processes before implementing e-business solutions This understanding encompasses the identification of roles, business areas, processes, collaborations, and the necessary information exchanges A formalized e-business market model, independent of specific communication technologies, is crucial for ensuring adaptability to various e-business platforms now and in the future, thereby providing long-lasting value.

It is recommended to use the UN/CEFACT Modelling Methodology (UMM) to describe the

Business Operational View (BOV) of the ISO/IEC 14662 Open-edi reference model standard

While other e-business modeling methodologies can be utilized, the UMM is particularly recommended for use with ebXML e-business technology UMM is a tailored subset of the Rational Unified Process (RUP), which is a specialization of the Unified Software Development Process It employs the Unified Modeling Language (UML) from the Open Management Group (OMG), incorporating extensions to the UML meta model through business domain-specific stereotyping This approach facilitates the definition of business processes and information, leading to the creation of objects and detailed descriptions of interface-specific object behavior.

Additional worksheets with predefined structure to capture textual information may be used

Tools are available for UML and these can be specialised for e-business by using stereo- types

Table 6 gives a simplified overview of the UMM workflow, its focus and artefacts

Workflow Main focus for e-business View UML and XML artefacts

Business modelling Business context, business area, process area BOM (Business Opera- tions Map) Use case diagrams, scenario descriptions

Requirements Business processes and collaborations

BRV (Business Require- ments View)

Detailed use case diagrams, Activity diagrams

Analysis Transactions, identification of business documents

BTV (Business Transac- tion View)

Sequence diagrams, collaboration diagrams

Design Business documents, Busi- ness service interface BSV (Business Service

View) Class diagrams, XML- messages, interaction parameters

Key sectors in energy markets include generation, trading, supply, system operation (which encompasses scheduling, balancing, and settlement of imbalances), energy services (such as supplier changes, metering, account settlement, and billing), as well as transmission and distribution.

Table 7 shows an example workflow with ‘drill-down’ from business modelling to analysis for change of supplier (exchange of market metadata)

Table 7 – Example workflow with drill down

Process area Change of supplier

Transaction Request of contract data of new customer Identification of documents Contract data request document, etc

The modeling methodology is not an exact science; it relies on sound business practices rather than a one-size-fits-all approach Consequently, there is no universal guideline for utilizing UMM effectively Additionally, UML workflows may not align directly with the phases of an e-business project, and the boundaries between these workflows are often unclear, as they delve into greater detail from one workflow to the next.

The UMM outlines analysis patterns for business transactions, which are reusable in various collaborations It identifies six key patterns through activity diagrams: (1) Commercial Transaction, (2) Request/Confirm, (3) Query/Response, (4) Request/Response, (5) Notification, and (6) Information Distribution Among these, the Commercial Transaction models the "offer and acceptance" process, establishing a residual obligation for both parties to meet the contractual terms with economic commitment.

Transaction patterns are linked to seven specific property values that define the interaction parameters for both requesting and responding business activities These parameters include: (1) the time taken to acknowledge receipt, (2) the time required to acknowledge acceptance, (3) the time needed to perform the task, and (4) whether authorization is required.

In the context of business transactions, it is essential to consider the following aspects: the validity of statements (true or false), the non-repudiation of origin and content (true or false), the non-repudiation of receipt (true or false), and the recurrence, which refers to the number of re-transmissions Additionally, property values can be customized for each specific agreed transaction.

The UMM defines also the following five business service interactions for business transactions and business collaboration agreements based on UML sequence diagrams: (1) Service-

Service, (3) Agent-Service-Service, (4) Service-Service-Agent, (5) Service-Agent-Service, (6)

6.2.2 Business documents language and schemas

Business documents are defined in XML (Extensible Markup Language), a subset of the

SGML (Standard Generalised Markup Language) language XML is not a language as the name implies but a meta language to define application languages with the help of DTD

(document type definitions) and XML Schemas

Where XML documents are the preferred payload, documents of arbitrary syntax are also al- lowed (for example EDIFACT, X12) and will be used for migration

6.2.3 Re-use of information entities and processes

Industry organizations utilize standardized, reusable core components from UN/CEFACT to define domain-specific XML business documents Additionally, UN/CEFACT standardizes domain-independent business documents of general interest This standardization extends to core processes as well, with both core components and core processes being accessible in business libraries within registries and repositories.

Before standardization is finished, it is possible to define one’s own market specific messages, core components and core processes and later switch to standardized ones.

Business and information model

The generic market processes outlined in section 4.2 are detailed in IEC 62325-102, serving as a reference for energy market e-business communication This standard illustrates a simplified market model using the UMM framework as an example.

Market modeling deliveries provide participants with a comprehensive understanding of market dynamics, allowing vendors to implement systems tailored to specific e-business technologies It is essential to view these deliveries as outcomes of the modeling process rather than as phases within an iterative and incremental framework.

The deliveries include two parts, the market user guide, and the formal UMM Market Model for system implementation

The market user guide provides a comprehensive overview of the market model, featuring text, tables, images, and graphics Additionally, it outlines the legal and regulatory framework that governs the market.

The market model provides a formal and detailed description of the entire market, utilizing the e-business UN/CEFACT modeling methodology (UMM) based on the UML modeling language This approach encompasses four key workflows: business modeling, requirements, analysis, and design.

The documentation of the market model focuses solely on the final results of the modeling process, excluding any iterations or intermediate versions of artifacts generated during the workflows.

The workflows business modelling, requirements, and analysis should be as far as possible independent of the e-business technology used The organisation of these workflows with the

The Business Operations Map (BOM) utilizes functional decomposition to categorize the entire market into distinct business areas, process areas, and supporting processes This approach also identifies market participants in specific roles, known as actors in UML, to streamline the model's components and enhance the efficiency of information flow and interfaces.

The BOM model management diagram employs UML packages to structure and analyze the high-level architecture of an e-business system, focusing on subsystems such as business areas, process areas, and their interdependencies Each package can encompass various model elements, including classes, use cases, activity diagrams, or additional packages At the conceptual level, these packages display the names of the included classes.

UML use cases capture the interactions between market participants and specific system functionalities, focusing on business areas, processes, collaborations, and transactions, while omitting the implementation details of these interactions.

Use case diagrams illustrate the relationships between various use cases and the interactions of one or more actors with these use cases Additionally, UMM forms provide a structured textual representation of use cases, enhanced by straightforward text descriptions.

Use-case extensions model variations from a base use-case, utilizing associations with the stereotype "extension." Additionally, use-cases can be divided into smaller components through dependency relationships, which are stereotyped as "includes."

UML activity diagrams visualize use cases by illustrating the workflow of business processes, serving two main purposes Firstly, they provide an overview of the business dynamics within an entire market or specific business areas These diagrams are developed alongside use cases and can encompass multiple use cases within a market or business sector, with each swim lane representing a distinct business area or process.

The second objective is to visually document a business workflow within a use case that illustrates a business process, collaboration, or transaction, featuring one starting state and multiple ending states Each market participant's role (actor) is depicted through a swim lane.

UML sequence diagrams effectively illustrate the interactions between market participants by highlighting the chronological order of business messages They are particularly useful for modeling business transactions.

UML class diagrams serve to model various aspects of business processes, collaborations, transactions, and the documents exchanged within these contexts These business documents are formulated from business information entities that originate from standardized core components The UML core components provide a visual representation of the elements, relationships, and constraints associated with the vocabulary of the e-business energy market.

The design workflow depends on the e-business technology used and includes technology specific configuration details in machine-readable XML format

A large and diverse market can be divided into a homogeneous core segment, such as a federally or internationally regulated wholesale market, and various regional inhomogeneous segments, like regionally or nationally regulated retail and supply markets Additionally, there may be alternative processes available within these inhomogeneous markets.

Market Reference Model may be useful for the future harmonisation of market processes

Market identification schema

E-business in energy markets provides a common Market Identification Schema (MIS) The primary objects that need to be identified are:

• Market participant: traders, generators, suppliers, system operators, big consumers, power exchanges, transmission network providers, distribution network providers, agents and service providers (brokers, metering providers, clearing providers)

• Area: distribution networks, transmission networks, balance areas (control areas) consist- ing of a number of networks, market areas, etc

• Metering point: for generation units, cross border connections, consumers, etc

The Management Information System (MIS) mandates that allocated codes remain consistent over time, requiring each enterprise to have a unique code or one code per market role Changes to the code are only permissible if the enterprise undergoes a legal status change; a mere name change does not affect the code Additionally, network area codes should only be modified if there are changes in the network areas, such as combinations or divisions Importantly, metering point codes must remain unchanged, even if the meter or the metering service provider changes.

The Management Information System (MIS) necessitates essential services, including accurate code allocation, management of code lists through deletion and modification, and access to information regarding the meanings of codes Additionally, it requires contact details for designated organizations and communication parameters such as email, website, and network addresses.

For the identification in the energy market, market specific schemas as for example EIC

(ETSO (European Transmission System Operators) Identification Code), or international schemas as for example EAN or DUNS should be used In case of EAN, an example of MIS is:

• Market participant: Number of 13 digits including a check digit called the Global Location

• Network area: Number of 13 digits (GLN)

The metering point is identified by an 18-digit number known as the Global Service Related Number (GSRN), which includes a check digit These numbers are typically assigned in large series, allowing existing numbers to be utilized with a long prefix and a check digit as a suffix.

Security in e-business extends beyond just communication infrastructure and presents various challenges It relies not only on legal frameworks, technologies, and standards but also on organizational measures In the context of energy markets, e-business security is fundamentally grounded in these legal frameworks.

Some countries or regions accept the legal binding of electronic commercial transactions with electronic signatures as being legally equivalent to hand-written signatures

This article focuses on security from a communication perspective, highlighting the need for more comprehensive frameworks to achieve full XML end-to-end persistent security, including application security Ongoing developments in Security Assertion Mark-up Language (SAML) and XML Access are essential for enhancing these security measures.

Control Mark-up Language (XACML, based on access limitations ACL (with access control lists)) of the OASIS initiative and the XML Key Management Specification (XKMS) of W3C

The latter is shortly described below

Countermeasures to security risks rely on three key technologies: encryption, digital signatures, and trusted certification of public key pairs within a public key infrastructure (PKI) Encryption ensures privacy, while digital signatures offer message integrity and authenticate the requester, facilitating access authorization based on the identity of the requester.

Public key encryption schemes require significant computing resources, which is why they are often combined with secret key encryption in various technologies and standards In this hybrid approach, the secret key is utilized for session-based encryption and is exchanged using public key encryption.

In the energy market with established relations between market participants only “persistent” and “message or application layer” security with XML Digital Signature (W3C) and as a default

XML Encryption (W3C) is essential for ensuring long-lasting security configurations that extend beyond a single session It provides end-to-end security for messages or applications, unlike transport and network security, which only protect site-to-site communications The XML digital signature guarantees the integrity and authentication of both the message and the sender/recipient, and it can also facilitate authorization Typically, messages are first signed and then encrypted, with the XML digital signature applied to the entire ebXML message, including the message envelope and payload.

Table 9 outlines the security technologies for energy markets, highlighting XML Encryption as the preferred default option While S/MIME and OpenPGP/MIME are available as alternatives, S/MIME is recommended over OpenPGP/MIME Additionally, non-persistent transport layer and network layer encryption methods, such as TLS and IPSec, should only be utilized by mutual agreement.

Technology From Used on layer Persistent Energy market

XML Digital Signature /MIME Should be used if needed

Default encryption if needed S/MIME v3

IETF application or message yes

TLS (SSL v3 only for back- ward compatibility)

IPSec (for VPN) IETF network no

1) only if XML Encryption /MIME is not available

HTTP/S is a combination of HTTP and TLS or SSL

Whereas user authentication is based on signatures on application level, system authentication and possibly encryption takes place on transport or network level preferably in the DMZ

The XML Key Management Specification (XKMS) W3C recommendation draft deals with the management of security information related to public key pairs within, but not limited to Public

Key Infrastructures (PKI), based on trusted certificates such as X.509 v3, SPKI, or within PKI- less environments, for example, as with OpenPGP XKMS is an API-like protocol using the

Simple Object Access Protocol (SOAP), Web Services Language (WSDL) and XML Schema

The goal is to offload key management tasks from applications to an enterprise trust service, which handles registration, access, revocation, and recovery of security information linked to public keys The XKMS trust service operates independently of public key schemas like W3C XML Digital Signature and XML Encryption, aiming to enhance these standards while simplifying the complexities of Public Key Infrastructure (PKI) for applications Figure 5 illustrates the XKMS concept in relation to XML messaging.

XML messaging based on SOAP

(encrypted, signed messages and security information)

Public Key Infrastructure (PKI) (based on X509 v3, )

Figure 5 – Example of use of XKMS within a public key infrastructure (PKI)

Regional energy markets should select an existing PKI profile to ensure security in energy market communications This profile, primarily based on X.509 v3 and relevant RFCs, encompasses a variety of applications beyond just energy markets, including e-Government and e-business It outlines data formats and communication protocols for interoperable PKI-based applications, focusing on essential security services such as authentication, confidentiality, and non-repudiation Additionally, the profile emphasizes interoperability, integrating various online services from certification service providers (CSPs), including certification, directory, and time-stamp services, along with client applications that utilize these services.

Figure 6 illustrates the components of PKI, which are merely an example of how these elements can be organized into sub-modules Market participants have the flexibility to function as Certificate Service Providers (CSPs) or to depend on third-party CSP providers In the former scenario, they can choose to cross-certify themselves.

PKI-profile based on X.509 and PKIX- standards (RFC‘s)

Certification request Online certificate status

Figure 6 – PKI-profile for interfaces between PKI components (example)

The following subclauses describe various network configurations for e-business (see Figure 7).

Peer-to-peer

In a peer-to-peer configuration, market participants can directly connect with one another via a B2B gateway over the Internet This setup requires robust management within the market, ensuring adherence to essential technology-dependent artifacts necessary for effective e-business operations A well-managed registry or repository plays a crucial role in this process.

MECON Limited is licensed for internal use at the Ranchi and Bangalore locations, with materials supplied by the Book Supply Bureau It is recommended that only one organization, in accordance with market business rules and common specifications, provides support for this initiative.

In a peer-to-peer configuration over HTTP, it is essential for all market participants to remain online at all times, which excludes the use of dial-up connections Additionally, mailboxes can be facilitated through SMTP.

Portal

A portal, also known as a hub-and-spoke model, serves as a centralized communication system managed by a single organization for all market participants Typically operated by natural communication hubs such as regional system operators, ISOs, or power exchanges, this approach streamlines interactions A key benefit is that it standardizes the portal interface, ensuring compliance among all participants and reducing the complexity of multiple messages and interface configurations.

Simple portals only provide a path (routing) for messages with little added value such as for example message validation, certification, logging and test services

Value-added service portals provide format conversion and function as mailboxes, allowing one party to send messages that can be retrieved later by the recipient, a process known as push-pull Advanced portals can also forward requests from one market participant to multiple others, generating response messages based on the feedback from all addressed participants.

A portal can be beneficial in intricate multi-party collaborations, particularly when multiple market participants need to share the same market metadata, such as during supplier changes Additionally, it facilitates agreements among several parties in collaborative efforts, like energy exchange transactions.

Energy markets that span large geographical areas will be segmented into distinct regions, each equipped with its own portal interconnected with neighboring portals This portal setup allows for dial-up connections for small and medium enterprises (SMEs), as the portal can function as a mailbox.

Centralized portal configurations are essential for addressing performance issues related to throughput Implementing a priority schema for message routing within the portal can be beneficial, particularly based on the length of the messages.

Enterprise Application Integration (EAI)

Middleware is a technological framework that allows diverse and distributed applications and systems of an organisation to communicate and interact with each other seamlessly A well- designed middleware framework should:

• allow information to flow quickly and seamlessly to and from each application;

• enable new applications to be easily integrated into the enterprise “federation” of member applications and systems;

A standardized communication protocol is essential for facilitating seamless interaction among various applications, including mission-critical back-end systems, front-end customer interfaces, and B2B gateway applications This approach ensures compatibility across different vendors and their respective protocols, promoting efficient communication and integration.

• enable workflow management and automation of business processes across multiple applications;

• allow transformation of data between member applications with different data models and world-views;

• ideally use an event-driven model that employs a publish/subscribe approach to messaging that minimises network traffic, instead of the traditional request/reply model

• contain a common repository for storing metadata definitions of each application’s data model

In the utility world, the IEC 61970 series and IEC 61968 series specify an open standardized

The Enterprise Application Integration (EAI) framework facilitates Application-to-Application (A2A) integration by employing an abstraction layer that conceals the underlying communication protocols from applications, utilizing generic services adaptable to any protocol This is exemplified in distribution management, as illustrated in Figure 8 from IEC 61968-1 The EAI framework leverages the Common Information Model (CIM) metadata model, as defined in IEC 61970-301, to accurately describe the power system and operational domains within utility SCADA/EMS business, fostering a shared understanding among applications Additionally, Enterprise Resource Planning (ERP) systems adhere to the Open Applications Group (OAG) standards.

Application Group) recommendations or others can also be integrated

Within the context of the IEC 62325 series, a B2B gateway would be connected to the

EAI-Bus facilitates Internet access by utilizing middleware that connects technology-dependent XML configurations, maximizing the benefits of e-business collaborations through its descriptive capabilities.

( MR ) Meter Reading and Control

( AM) Records and Asset Management

(EMS ) Energy Management and Energy Trading

(SC) Supply Chain and Logistics

( OP ) Operational Planning and Optimization

Electric distribution network planning, constructing, maintaining, and operating

Generation and transmission management, enterprise resource planning, supply chain, and general corporate services

Business functions external to distribution management

NOTE The ‘Parts’ referred to are the parts of the IEC 61968 series

Figure 8 – IEC 61968 compliant middleware services for distribution management

Business Process Management Systems (BPMS)

Managing business processes becomes challenging when multiple applications communicate with each other (A2A) and with various systems across different enterprises (B2B) To address this complexity, the Business Process Management System (BPMS) aims to decouple business logic from applications, similar to how the presentation layer is handled This separation enhances the manageability of business processes.

BPMS business process meta model including internal processes of the enterprise as well as external exposed processes used in B2B activities with other enterprises

Business processes are described as a sequence of activities, which may invoke operations to communicate with internal applications and external applications over the Business Service

Interface (BSI) The BSI provides access to a B2B gateway hiding the technology of the messaging service used

The BPMS process meta model and notation are currently undergoing standardization The BPMS business process model focuses on the activities of a single enterprise, while the e-business collaboration model illustrates the shared perspective of two enterprises concerning message exchanges during business transactions.

The following text is mainly based on the relevant RFC’s and recommendations and provides general background of the base technologies

A.1 XML digital signature and encryption

The W3C XML digital signature and XML encryption recommendations facilitate the signing and encryption of various content types, including EDIFACT and X12, while offering enhanced support for XML They allow for the signing or encrypting of specific XML portions, referencing multiple objects in a signature, and incorporating metadata with signed or encrypted content XML signatures can accommodate multiple signatures, which is beneficial for content approval processes Both XML Signatures and Encryption enable the integration of signatures or encrypted content within the original XML document, ensuring a strong connection Additionally, signatures can be kept separate from the signed content, which is advantageous for large or binary data that may disrupt XML signature processing Similarly, encrypted cipher data can be included in an XML encrypted element or managed independently.

RFC 1847 defines a general mechanism for security multiparts in MIME (Secure/Multipurpose

Internet Mail Extensions (MIME) define the Multipart/Signed and Multipart/Encrypted types Multipart/Signed allows the first MIME part to hold arbitrary content, while the second part contains a signature for that content In contrast, Multipart/Encrypted uses the first part for encryption control information and the second part for the encrypted content.

Multipart/Encrypted is to pass a single MIME part containing encrypted content

An Internet-Draft is being developed to outline the integration of XML Digital Signatures and XML Encryption with Multipart MIME security, enhancing MIME integrity and confidentiality This draft expands upon RFC 1847 by introducing the application/signature+xml and application/encryption+xml protocols for Multipart/Signed and Multipart/Encrypted MIME types While non-XML content can also utilize XML signing and encryption, XML MIME content benefits from additional capabilities.

Multipart/Signed content is composed of two main components: the content part and the signature part The content can be any type, encoded in MIME canonical format, such as base64, and must include MIME headers that specify the content type The signature part, which is a signature of the entire content including the MIME headers, should be labeled as "application/signature+xml" Additionally, transforms allow for the signing of specific sections of the MIME part or XML, or the option to use a single MIME part for both the content and the signature.

Multipart/Encrypted content is composed of a control part and an encrypted content part, with the control part matching the protocol parameter, specifically "application/xml-encrypted." In the context of XML encryption, this control part must include the XML encryption content, which consists of one or more encrypted data elements The encrypted content section of the MIME message can be empty if the cipher text is already present within the XML encrypted data elements However, if the cipher data is not included in these elements, it can be placed in a second encrypted data MIME part, encoded in base64.

Table A.1 shows the main mandatory features

Table A.1 – Mandatory features of XML signature and XML encryption with MIME

Main mandatory features XML digital signature and XML encryption/MIME

Certificate format Binary, based on X.509v3

Symmetric encryption algorithm TripleDES ANSI X.952 (DES EDE3 CBC) or AES-128, AES-256 (CBC)

Signature algorithm DH (Diffie-Hellman, ANSI X9.42) with DSS

MIME encapsulation of signed data multipart/signed or CMS format

MIME encapsulation of encrypted data multipart/encrypted

S/MIME version 3 (Secure/Multipurpose Internet Mail Extensions) enhances MIME by providing a standardized method for securely sending and receiving MIME data It utilizes 7-bit character encoding to transform 8-bit character encoding or binary data into a 7-bit character stream This protocol offers essential cryptographic security services for electronic messaging, including authentication, message integrity, non-repudiation of origin through digital signatures, and privacy via encryption While primarily associated with email, S/MIME can also be applied to any transport mechanism that handles MIME data, such as HTTP S/MIME v3 is defined in four RFC parts, including Cryptographic Message Syntax (RFC 2630).

Specification (RFC 2633), S/MIME Version 3 Certificate Handling (RFC 2632), and Diffie-

Hellman Key Agreement Method (RFC 2631)

S/MIME v3 is a W3C recommendation that is free from patent issues, utilizing a certificate structure based on IETF's PKIX In contrast, S/MIME v2 is not advisable as it is merely an RFC draft and relies on patents (RCA) Additionally, there is an Enhanced Security Services protocol for S/MIME.

(RFC 2634), is a set of extensions to S/MIME to allow signed receipts, security labels, and secure mailing lists

Table A.2 – Mandatory features of S/MIME v3

Message format Binary, based on CMS

Certificate format Binary, based on X.509v3

Symmetric encryption algorithm TripleDES ANSI X.952 (DES EDE3 CBC)

Signature algorithm DH (Diffie-Hellman, ANSI X9.42) with DSS

MIME encapsulation of signed data Choice of multipart/signed or CMS format

MIME encapsulation of encrypted data application/pkcs7-mime

The OpenPGP protocol is also free of patent issues and described in the OpenPGP Message

RFC 2440 outlines the format for OpenPGP, while RFC 3156 details the MIME wrapping for Pretty Good Privacy (PGP) Typically, PGP users rely on personal trust to mutually sign certificates without a Public Key Infrastructure (PKI); however, OpenPGP can also be utilized in conjunction with a PKI.

Table A.3 – Mandatory features of XML signature and encryption with MIME

Main mandatory features OpenPGP/MIME

Message format Binary, based on previous PGP

Certificate format Binary, based on previous PGP

Symmetric encryption algorithm TripleDES (DES EDE3 Eccentric CFB)

Signature algorithm ElGamal with DSS

MIME encapsulation of signed data multipart/signed with ASCII armour

MIME encapsulation of encrypted data multipart/encrypted

A.4 Transport layer security with TLS

TLS is for transport layer security, not for end-end security on application level It provides data integrity, confidentiality, authentication, and non-repudiation between client and server

Non-repudiation is done using digital signatures and public key certificates Servers are authenticated, clients can be authenticated optionally

TLS has the following features:

Symmetric cryptography ensures a private connection by utilizing unique keys for data encryption, such as DES and RC4 These keys are generated specifically for each connection and rely on a secret that is negotiated through a different protocol.

(such as the TLS Handshake Protocol) The Record Protocol can also be used without encryption

The connection ensures reliability through message transport that incorporates a message integrity check via a keyed MAC, utilizing secure hash functions like SHA and MD5 for MAC computations Although the Record Protocol can function without a MAC, this mode is typically reserved for instances where another protocol is leveraging the Record Protocol to negotiate security parameters.

• The peer's identity can be authenticated using asymmetric, or public key, cryptography

(for example, RSA [RSA], DSS [DSS], etc.) This authentication can be made optional, but is generally required for at least one of the peers (mostly the server)

The negotiation of a shared secret ensures security by making the secret inaccessible to eavesdroppers Even in cases of authenticated connections, attackers positioned in the middle of the communication cannot retrieve the secret.

• The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication

This annex addresses key security aspects that influence the implementation and utilization of e-business technologies in accordance with IEC 62210, providing informative recommendations for end users.

IEC 62210 governs computerized supervision, control, metering, and protection systems in electrical utilities, emphasizing security in communication protocols both within and between these systems It prioritizes end-to-end communication security at both the application and system levels The recommendations provided are technology-agnostic and do not directly influence corporate security policies.

Tiêu đề	Framework for Energy Market Communications – Part 101: General Guidelines
Trường học	MECON Limited
Chuyên ngành	Energy Market Communications
Thể loại	Technical report
Năm xuất bản	2005
Thành phố	Geneva

Định dạng
Số trang	44
Dung lượng	718,5 KB