29.240.30 - Control equipment for electric power systems
ICS 29.240.30 Details
Control equipment for electric power systems
Steuergerate fur Verteilsysteme
Appareil de commande pour lignes electriques
Krmilna oprema za elektroenergetske sisteme
General Information
e-Library Subscription
Create subscription and get permanent access to documents within 29.240.30 - Control equipment for electric power systems
Currently subscription includes documents marked with .We are working on making all documents available within the subscription.
IEC 62351-3:2023 specifies how to provide confidentiality, integrity protection, and message level authentication for protocols that make use of TCP/IP as a message transport layer and utilize Transport Layer Security when cyber-security is required. This may relate to SCADA and telecontrol protocols, but also to additional protocols if they meet the requirements in this document.
IEC 62351-3 specifies how to secure TCP/IP-based protocols through constraints on the specification of the messages, procedures, and algorithms of Transport Layer Security (TLS) (TLSv1.2 defined in RFC 5246, TLSv1.3 defined in RFC 8446). In the specific clauses, there will be subclauses to note the differences and commonalities in the application depending on the target TLS version. The use and specification of intervening external security devices (e.g., "bump-in-the-wire") are considered out-of-scope.
In contrast to previous editions of this document, this edition is self-contained in terms of completely defining a profile of TLS. Hence, it can be applied directly, without the need to specify further TLS parameters, except the port number, over which the communication will be performed. Therefore, this part can be directly utilized from a referencing standard and can be combined with further security measures on other layers. Providing the profiling of TLS without the need for further specifying TLS parameters allows declaring conformity to the described functionality without the need to involve further IEC 62351 documents.
This document is intended to be referenced as a normative part of other IEC standards that have the need for providing security for their TCP/IP-based protocol exchanges under similar boundary conditions. However, it is up to the individual protocol security initiatives to decide if this document is to be referenced.
The document also defines security events for specific conditions, which support error handling, security audit trails, intrusion detection, and conformance testing. Any action of an organization in response to events to an error condition described in this document are beyond the scope of this document and are expected to be defined by the organization’s security policy.
This document reflects the security requirements of the IEC power systems management protocols. Should other standards bring forward new requirements, this document may need to be revised.
This second edition cancels and replaces the first edition published in 2014, Amendment 1:2018 and Amendment 2:2020. This edition constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous edition:
a) Inclusion of the TLSv1.2 related parameter required in IEC 62351-3 Ed.1.2 to be specified by the referencing standard. This comprises the following parameter:
• Mandatory TLSv1.2 cipher suites to be supported.
• Specification of session resumption parameters.
• Specification of session renegotiation parameters.
• Revocation handling using CRL and OCSP.
• Handling of security events.
b) Inclusion of a TLSv1.3 profile to be applicable for the power system domain in a similar way as for TLSv1.2 session.
- Standard52 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62351 defines the application authentication mechanism (A-profile) specifying messages, procedures and algorithms for securing the operation of all protocols based on or derived from IEC 60870-5: Telecontrol Equipment and Systems - Transmission Protocols.
This Standard applies to at least those protocols listed in Table 1.
[Table 1]
The initial audience for this International Standard is intended to be the members of the working groups developing the protocols listed in Table 1.
For the measures described in this standard to take effect, they must be accepted and referenced by the specifications for the protocols themselves. This document is written to enable that process. The working groups in charge of take this standard to the specific protocols listed in Table 1 may choose not to do so.
The subsequent audience for this specification is intended to be the developers of products that implement these protocols.
Portions of this standard may also be of use to managers and executives in order to understand the purpose and requirements of the work.
This document is organized working from the general to the specific, as follows:
- Clauses 2 through 4 provide background terms, definitions, and references.
- Clause 5 describes the problems this specification is intended to address.
- Clause 6 describes the mechanism generically without reference to a specific protocol.
- Clauses 7 and 8 describe the mechanism more precisely and are the primary normative part of this specification.
- Clause 9 define the interoperability requirements for this authentication mechanism.
- Clause 10 describes the requirements for other standards referencing this specification
Unless specifically labelled as informative or optional, all clauses of this specification are normative.
- Standard126 pagesEnglish languagesale 10% offe-Library read for1 day
The IEC 61970-401 document describes how the IEC 61970-450 to -499, IEC TS 61970-600 and IEC 61970-600 profile standards as well as any other CIM based profile specifications are structured and created. Profile documents describe a subset of the canonical CIM dedicated to a specific data exchange, the canonical CIM is described in the IEC 61970-300 series documents as well as the IEC 61968-11.
Rules for creation of canonical CIM is outside the scope of this document.
The IEC 61970-401 document specifies the structure of a profile specification and the rules for creating the subsets from the canonical CIM. The guiding principle for the profiling method is that the information described by a profile is a true subset of the canonical CIM and retain class, role and attribute names from the canonical CIM. The data types in CIM are described by classes stereotyped Primitive or CIMDatatype that is a composition of three attributes value, unit and multiplier. The main objective being that different datasets (see section 3) exchanged using different profiles based on canonical CIM solely rely on the definitions and basic principles of the canonical CIM which is a key to make interoperability efforts feasible. This also enables different profiles to relate data between them by using the canonical CIM as a hub and supports a reader of a data set or a message to easily find descriptions of elements in both the profile and the canonical CIM. The support for relating data in different data sets or messages described by different profiles is required when data is divided across different data sets governed by different profiles. Such use cases are defined for network models where the network description is separated from the operational conditions of the network (seen as an input) and the results.
There are several languages that can describe profiles, e.g. UML (serialized as XMI), RDFS, Ecore or OWL. UML includes a graphical language that is implemented by UML editors. OWL does not have a graphical language, but several editors exist that support the display and editing of OWL data. The language in which a profile is described is outside the scope of this specification as well as how profiles are presented and edited in user interfaces. Relevant specifications are referenced in section 2.
A profile in UML is described by classes, attributes, associations and roles, the common way to describe information in UML. The UML language also include the concept of stereotypes and tagged values that enables custom extensions of the UML language. Hence profiling with UML means copying and updating classes, attributes, associations and stereotypes from the canonical CIM. A profile in OWL is described by classes and properties. There are two types of OWL properties matching with UML attributes and UML roles. Profiling in OWL means creating OWL classes and properties by selecting UML classes, attributes, and roles from canonical CIM the same way as it is done for profiling with UML. This specification standardizes the operations used to create the profile elements from the canonical CIM. As canonical CIM is described in UML the operations are described in the terms of UML classes, attributes and roles. There is a mapping between UML and OWL so either language can be used to describe the created profiles.
This specification support profiles describing data exchanged with CIMXML files according to IEC 61970-552. But other formats are also supported if the exchanged data comply with profiles created according to this document.
Tools that process data described by profiles created according to this document will need a machine readable version of the profiles, also called syntactical profile. IEC 61970-501 is an RDFS based serialization intended for this. Hence profiling tools shall support the generation of profiles in the IEC 61970-501 serialisation format. [...]
- Standard36 pagesEnglish languagesale 10% offe-Library read for1 day
1.1 General
This International Standard is Part 100 of IEC 61968. It defines how messages may be exchanged between co-operating systems in order to facilitate the transfer of application-specific data. Such application-specific data include but are not limited to the message payloads defined in IEC 61968 (Parts 3-9 and Part 13), IEC 61970 and IEC 62325.
1.2 About This International Standard
This International Standard provides normative definitions for:
- a set of message archetypes (clause 5);
- a set of message exchange patterns that both sending and receiving systems are expected to implement (clause 6);
- the exact format of the messages that are to be transmitted over the various integration technologies including a precise description of the information that each message must contain (clause 7);
- a set of constraints and conventions to which applications must adhere in order to facilitate message exchange using IEC 61968-100 (clause 8);
- the details of how IEC 61968-100 messages should be implemented using various underlying transport mechanisms (clause 9).
1.3 What is not covered by this International Standard
Security considerations lie outside the scope of IEC 61968-100. This document defers to the IEC 62351 series for definitions and practices relating to the secure transmission of messages.
1.4 Future Considerations
1.4.1 Choice of Encoding Mechanisms
IEC 61968-100:2021 prescribes XML as the normative encoding mechanism for all messages defined by this International Standard.
Future editions of IEC 61968-100 may specify additional normative encoding methods including support for IEC 62361-104. The latter defines encodings to facilitate the exchange of information in the form of JSON documents whose semantics are defined by the IEC CIM and whose syntax is defined by an IETF JSON schema.
1.4.2 Choice of Web Service Technologies
IEC 61968-100:2021 provides normative definitions for the use of SOAP Web Services (clause 9.2) and Java Messaging Service (clause 9.3) for the transport of messages.
Future editions of IEC 61968-100 may specify additional normative web service technologies such as REST.
- Standard251 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62325 specifies a UML package for the HVDC Link scheduling business
process and its associated document contextual models, assembly models and XML schemas
for use within the European style electricity markets.
This part of IEC 62325 is based on the European style market contextual model
(IEC 62325-351). The business process covered by this part of IEC 62325 is described in
Subclause 5.3.
The relevant aggregate core components (ACCs) defined in IEC 62325-351 have been
contextualised into aggregated business information entities (ABIEs) to satisfy the requirements
of the European style market HVDC Link scheduling business process.
- Standard56 pagesEnglish languagesale 10% offe-Library read for1 day
The specifications of this document refer to general, respectively core, communication
requirements of the application functions in all domains of power utility automation systems.
Dedicated communication requirements and most examples of application functions in this
document are from the domain substation automation but may be reused in or extended to other
domains within power utility automation systems. Note that sometimes instead of the term
substation automation domain the term substation domain is used, especially if both the
switchyard devices (primary system) and the automation system (secondary system) are
regarded.
The description of the application functions is not used to standardize these functions, but to
identify communication requirements between Intelligent Electronic Devices (IEDs) hosting
these functions within plants and substations in the power system, between such stations (e.g.
between substation for line protection) and between the plant or substation and higher-level
remote operating places (e.g. network control centres) and maintenance places. In addition
interfaces to remote technical services (e.g. maintenance centres) are considered. The general
scope is the communication requirements for power utility automation systems. The basic goal
is interoperability for all interactions providing a seamless communication system for the overall
power system management. Another prerequisite for interoperability is a commonly defined
method for time synchronization.
Standardizing application functions and their implementation is completely outside the scope of
this document. Therefore, it cannot be assumed a single philosophy of allocating application
functions to devices. To support the resulting request for free allocation of these functions, a
proper breakdown of these functions into parts relevant for communication is defined. The
exchanged data and their required performance are defined.
The same or similar IEDs from substations like protective and control devices are found in other
domains like power plants also. Using this document for such devices in these plants facilitates
the system integration e.g. between the power plant control and the related substation
automation system. For some of such other application domains like wind power plants, hydro
power plants and distributed energy resources specific standard parts according to the
IEC 61850 series have been already defined and published.
- Amendment80 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment9 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft530 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61970 belongs to the IEC 61970-450 to IEC 61970-499 series that, taken as a
whole, defines at an abstract level the content and exchange mechanisms used for data
transmitted between power system analyses applications, control centres and/or control centre
components.
The purpose of this document is to rigorously define the subset of classes, class attributes, and
roles from the CIM necessary to describe the result of state estimation, power flow and other
similar applications that produce a steady-state solution of a power network, under a set of use
cases which are included informatively in this document.
This document is intended for two distinct audiences, data producers and data recipients, and
can be read from those two perspectives. From the standpoint of model export software used
by a data producer, the document defines how a producer may describe an instance of a
network case in order to make it available to some other program. From the standpoint of a
consumer, the document defines what that importing software must be able to interpret in order
to consume power flow cases.
There are many different use cases for which use of this document is expected and they differ
in the way that the document will be applied in each case. Implementers are expected to
consider what use cases they wish to cover in order to know the extent of different options they
must cover. As an example, the profiles defined in this document will be used in some cases to
exchange starting conditions rather than solved conditions, so if this is an important use case,
it means that a consumer application needs to be able to handle an unsolved state as well as
one which has met some solution criteria
- Standard110 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61970-600 defines the profiles included in the Common Grid Model Exchange
Standard (CGMES) that are based on IEC 61970-450-series and IEC 61968-13 profiles. This
document refers to the IEC 61970-450-series and IEC 61968-13 profiles only in cases where
they are identical. If the referenced profile is not yet published, this document includes the
profile definition and related constraints’ definitions. In the case where a CGMES profile makes
restriction on the referenced profile, the restriction is defined in this document.
The equipment boundary profile (EQBD) is the only profile that is not part of IEC 61970-450-
series and IEC 61968-13 profiles. This profile is deprecated as modifications have been made
to align between EQBP and the equipment profile (EQ). Although the updated EQBD is
addressing the requirement that boundary also can be located inside a substation, which will
be the case for many Distribution System Operators (DSOs), additional information would need
to be exchanged. For instance, system integrity protection schemes, that can be shared by
multiple utility would require another way of boundary handling. In this document EQBD is
included in CGMES only to create better backwards compatibility with previous version of the
CGMES.
The machine-readable documentation that supports model driven development of the profiles
defined in this part are generated as Resource Description Framework Schema (RDFS)
according to IEC 61970-501:2006 (with some extension) and IEC 61970-501:ED2 when
published.
- Standard879 pagesEnglish languagesale 10% offe-Library read for1 day
This document is one of the IEC 61970-450 to 499 series that, taken as a whole, defines at an abstract level the content and exchange mechanisms used for data transmitted between control centres and/or control centre components, such as power systems applications.
The purpose of this document is to define the subset of classes, class attributes, and roles from the CIM necessary to execute state estimation and power flow applications. The North American Electric Reliability Council (NERC) Data Exchange Working Group (DEWG) Common Power System Modelling group (CPSM) produced the original data requirements, which are shown in Annex E. These requirements are based on prior industry practices for exchanging power system model data for use primarily in planning studies. However, the list of required data has been extended starting with the first edition of this standard to facilitate a model exchange that includes parameters common to breaker-oriented applications. Where necessary this document establishes conventions, shown in Clause 6, with which an XML data file must comply in order to be considered valid for exchange of models.
This document is intended for two distinct audiences, data producers and data recipients, and may be read from two perspectives.
From the standpoint of model export software used by a data producer, the document describes a minimum subset of CIM classes, attributes, and associations which must be present in an XML formatted data file for model exchange. This standard does not dictate how the network is modelled, however. It only dictates what classes, attributes, and associations are to be used to describe the source model as it exists.
- Standard277 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61850 defines the IEC 61850 information models to be used in the exchange
of information with distributed energy resources (DER) and Distribution Automation (DA)
systems. DERs include distribution-connected generation systems, energy storage systems,
and controllable loads, as well as facility DER management systems, including aggregated
DER, such as plant control systems, facility DER energy management systems (EMS), building
EMS, campus EMS, community EMS, microgrid EMS, etc. DA equipment includes equipment
used to manage distribution circuits, including automated switches, fault indicators, capacitor
banks, voltage regulators, and other power management devices.
The IEC 61850 DER information model standard utilizes existing IEC 61850-7-4 logical nodes
where possible, while defining DER and DA specific logical nodes to provide the necessary data
objects for DER and DA functions, including for the DER interconnection grid codes specified
by various countries and regions.
Although this document explicitly addresses distribution-connected resources, most of the
resource capabilities, operational functions, and architectures are also applicable to
transmission-connected resources
- Standard552 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61970, which covers the definition of Common Grid Model Exchange Standard
(CGMES), defines the main rules and application’s requirements to meet business requirements
for assembled and merged model to fit relevant business services. This document does not
define the business requirements, business processes nor how applications are implemented.
This document defines how relevant Common Information Model (CIM) standards work together
so that specific business requirements can be resolved.
It also includes extensions to the Common Information Model (CIM). The current extensions are
defined in IEC 61970-301:2020 and will be covered in its future Amendment 1, but additional
extensions can be defined in other standards in the IEC 61970-600-series. The extensions can
be used to define additional profiles or to expand IEC 61970-450-series or IEC 61968-13
profiles. However, primary CGMES includes additional constraints on existing profiles and
validation of assembled and merged models that is based on existing profiles. This can be done
by making optional attributes and associations mandatory (required).
In addition, this document includes the specification of the serialisation that must be supported
by referring to an existing standard defined in IEC 61970-550-series, e.g., IEC 61970-552, and
making relevant constraints related to it.
The goal is to achieve interoperability between applications using CGMES in a highperformance
environment with combined minimum effort so that relevant business processes
are satisfied.
An overview of IEC 61970-600 series is provided in the following table, which also presents
identified needs that are not yet addressed.
- Standard50 pagesEnglish languagesale 10% offe-Library read for1 day
Per the IEC 61968 Interface Reference Model, the Network Operations function defined in this part of IEC 61968 provides utilities the means to supervise main substation topology (breaker and switch state), feeder topology and control equipment status through SCADA, AMI and other data sources. It also provides the means for handling network connectivity and loading conditions. Finally, it makes it possible for utilities to locate customer telephone complaints and coordinate activities of field crews with respect to planned and unplanned outages.
IEC 61968-3 specifies the information content of a set of message payloads that can be used to support many of the business functions related to network operations. Typical uses of the message payloads defined in IEC 61968-3 include data acquisition by external systems, fault isolation, fault restoration, trouble management and coordination of the real-time state of the network.
The scope diagram shown in [Figure 1] illustrates the possibility of implementing IEC 61968-3 functionality 51 as either a single integrated advanced distribution management system or as a set of separate functions - OMS, DMS and SCADA. Utilities may chose to buy these systems from different vendors and integrate them using the IEC 61968-3 messages. Alternatively, a single vendor could provide two or all of these components as a single integrated system. In the case of more than one system being provided by the same vendor, the vendor may chose to use either extensions of the IEC 61968- messages or a proprietary integration mechanism to provide enhanced functionality over and above what is required/supported by the IEC 61968-3 specification. While this is a possible implementation, clause 4.3 defines the scope in terms of business functions that are implemented in common vendor offerings.
Annexes in this standard document integration scenarios or use cases, which are informative examples showing typical ways of using the message payloads defined in this document as well as message payloads to be defined in other parts of the IEC 61968 series.
- Standard374 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62325 specifies a UML package for the electricity balancing business process
and its associated document contextual models, assembly models and XML schemas for use
within the European style electricity markets.
This part of IEC 62325 is based on the European style market contextual model
(IEC 62325-351). The business process covered by this part of IEC 62325 is described in
Clause 5.
The relevant aggregate core components (ACCs) defined in IEC 62325-351 have been
contextualised into aggregated business information entities (ABIEs) to satisfy the requirements
of the European style market publication business process.
- Standard148 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61970 specifies a standard interface for exchanging dynamic model information
needed to support the analysis of the steady state stability (small-signal stability) and/or
transient stability of a power system or parts of it. The schema(s) for expressing the dynamic
model information are derived directly from the CIM, more specifically from IEC 61970-302.
The scope of this document includes only the dynamic model information that needs to be
exchanged as part of a dynamic study, namely the type, description and parameters of each
control equipment associated with a piece of power system equipment included in the steady
state solution of a complete power system network model. Therefore, this profile is dependent
upon other standard profiles for the equipment as specified in IEC 61970-452, CIM static
transmission network model profiles, the topology, the steady state hypothesis and the steadystate
solution (as specified in IEC 61970-456, Solved power system state profiles) of the power
system, which bounds the scope of the exchange. The profile information described by this
document needs to be exchanged in conjunction with IEC 61970-452 and IEC 61970-456
profiles’ information to support the data requirements of transient analysis tools. IEC 61970-456
provides a detailed description of how different profile standards can be combined to form
various types of power system network model exchanges.
This document supports the exchange of the following types of dynamic models:
• standard models: a simplified approach to exchange, where models are contained in
predefined libraries of classes interconnected in a standard manner that represent dynamic
behaviour of elements of the power system. The exchange only indicates the name of the
model along with the attributes needed to describe its behaviour.
• proprietary user-defined models: an exchange that would provide users the ability to
exchange the parameters of a model representing a vendor or user proprietary device where
an explicit description of the model is not described in this document. The connections
between the proprietary models and standard models are the same as described for the
standard models exchange. Recipient of the data exchange will need to contact the sender
for the behavioural details of the model.
This document builds on IEC 61970-302, CIM for dynamics which defines the descriptions of
the standard dynamic models, their function block diagrams, and how they are interconnected
and associated with the static network model. This type of model information is assumed to be
pre-stored by all software applications hence it is not necessary to be exchanged in real-time
or as part of a dynamics model exchange.
- Standard460 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61968 specifies profiles that can be used to exchange Network Models in a
Utility or between a Utility and external applications to the utility. This document provides a list
of profiles which allow to model balanced and unbalanced distribution networks in order to
conduct network analysis (Power flow calculation). Therefore, it leverages already existing
profiles (IEC 61970-45x based on IEC 61970-301 (CIM base) or profiles based on
IEC 6196811
CIM extension for Distribution). This document reuses some profiles without any
change, or eventually extends them or restricts them. Moreover, it proposes other profiles to
reflect Distribution needs.
Use of CIM in Distribution is not a new topic. Several documents can be of interest
[13][17][18][19][20]. This document includes informative parts, as CIM model extensions, which
could be integrated in future versions of the IEC CIM Model. These extensions have been used
by some utilities for utility internal information exchange use cases and to support information
exchanges between different market participants like Transmisstion System Operators (TSO),
Distributed System Operators (DSO), Distributed Network Operators (DNO) and Significant Grid
Users (SGU) including generators and industry (see Annex J for example).
- Standard374 pagesEnglish languagesale 10% offe-Library read for1 day
IEC 62325-451-10:2020 specifies a UML package for the Energy Consumption Data business process and its associated document contextual model, assembly model and XML schema for use within the European style electricity markets.
The relevant aggregate core components (ACCs) defined in IEC 62325-351 have been contextualised into aggregated business information entities (ABIEs) to satisfy the requirements of the European style market Energy Consumption Data business process.
The contextualised ABIEs have been assembled into the Energy Consumption Data document contextual model.
A related assembly model and an XML schema for the exchange of Energy Consumption information between market participants is automatically generated from the assembled document contextual model. The XML schema follows IEC Code Components management and copyright licensing
- Standard138 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment21 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62351 specifies messages, procedures, and algorithms for securing the
operation of all protocols based on or derived from the IEC 61850 series.The initial audience for this document is intended to be the members of the working groups
developing or making use of the protocols listed in Table 1. For the measures described in this
specification to take effect, they must be accepted and referenced by the specifications for the
protocols themselves. This document is written to enable that process.
The subsequent audience for this document is intended to be the developers of products that
implement these protocols.
Portions of this document may also be of use to managers and executives in order to understand
the purpose and requirements of the work.
- Standard37 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment105 pagesEnglish languagesale 10% offe-Library read for1 day
The scope of this part of IEC 61968 is the description of a set of functions that are needed for
enterprise integration of DERMS functions. These exchanges are most likely between a DERMS
and a DMS. However, since this is an enterprise integration standard which may leverage
IEC 61968-100:2013 for application integration (using web services or JMS) or other looselycoupled
implementations, there are no technical limitations for systems with which a DERMS
might exchange information. Also, it should be noted that a DERMS might communicate with
individual DER using a variety of standards and protocols such as IEC 61850, IEEE 2030.5,
Distribution Network Protocol (DNP), Sunspec Modbus, or perhaps Open Field Message Bus
(OpenFMB). One role of the DERMS is to manage this disparity and complexity of
communications on the behalf of the system operator. However, the communication to individual
DER is out of scope of this standard. Readers are invited to look to those standards to
understand communication to individual DERs' smart inverter.
The scope will be limited to the following use case categories:
• DER group creation – a mechanism to manage DER in aggregate
• DER group maintenance – a mechanism to add, remove, or modify the members and/or
aggregated capabilities of a given group of DER
• DER group deletion – removing an entire group
• DER group status monitoring – a mechanism for quantifying or ascertaining the current
capabilities and/or status of a group of DER
• DER group forecast – a mechanism for predicting the capabilities and/or status of a group
of DER for a given time period in the future
• DER group dispatch – a mechanism for requesting that specified capabilities of a group of
DER be dispatched to the grid
• DER group voltage ramp rate control – a mechanism for requesting that a DER group
following a ramp rate curve
• DER group connect/disconnect – a mechanism to request that DER either isolate
themselves, or reconnect to the grid as needed
- Standard53 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment44 pagesEnglish languagesale 10% offe-Library read for1 day
The common information model (CIM) is an abstract model that represents all the major objects
in an electric utility enterprise typically involved in utility operations. By providing a standard
way of representing power system resources as object classes and attributes, along with their
relationships, the CIM facilitates the integration and interoperability of network applications
developed independently by different vendors, between entire systems running network
applications developed independently, or between a system running network applications and
other systems concerned with different aspects of power system operations, such as generation
or distribution management. SCADA is modelled to the extent necessary to support power
system simulation and inter-control centre communication. The CIM facilitates integration by
defining a common language (i.e. semantics) based on the CIM to enable these applications or
systems to access public data and exchange information independent of how such information
is represented internally.
The object classes represented in the CIM are abstract in nature and can be used in a wide
variety of applications. The use of the CIM goes far beyond its application in an EMS. This
document should be understood as a tool to enable integration in any domain where a common
power system model is needed to facilitate interoperability and plug compatibility between
applications and systems independent of any particular implementation.
Due to the size of the complete CIM, the object classes contained in the CIM are grouped into
several logical Packages, each of which represents a certain part of the overall power system
being modelled. Collections of these Packages are progressed as separate International
Standards. This document specifies a Base set of packages which provide a logical view of the
functional aspects of Energy Management System (EMS) and power system modelling
information within the electric utility enterprise that is shared between all applications. Other
standards specify more specific parts of the model that are needed by only certain applications.
Subclause 4.3 of this document provides the current grouping of packages into standards
documents.
- Standard557 pagesEnglish languagesale 10% offe-Library read for1 day
The scope of this part of IEC 62351 is to facilitate role-based access control (RBAC) for power
system management. RBAC assigns human users, automated systems, and software
applications (collectively called "subjects" in this document) to specified "roles", and restricts
their access to only those resources, which the security policies identify as necessary for their
roles.
As electric power systems become more automated and cyber security concerns become more
prominent, it is becoming increasingly critical to ensure that access to data (read, write, control,
etc.) is restricted. As in many aspects of security, RBAC is not just a technology; it is a way of
running a business. RBAC is not a new concept; in fact, it is used by many operating systems
to control access to system resources. Specifically, RBAC provides an alternative to the all-ornothing
super-user model in which all subjects have access to all data, including control
commands.
RBAC is a primary method to meet the security principle of least privilege, which states that no
subject should be authorized more permissions than necessary for performing that subject’s
task. With RBAC, authorization is separated from authentication. RBAC enables an organization
to subdivide super-user capabilities and package them into special user accounts termed roles
for assignment to specific individuals according to their associated duties. This subdivision
enables security policies to determine who or what systems are permitted access to which data
in other systems. RBAC provides thus a means of reallocating system controls as defined by
the organization policy. In particular, RBAC can protect sensitive system operations from
inadvertent (or deliberate) actions by unauthorized users. Clearly RBAC is not confined to
human users though; it applies equally well to automated systems and software applications,
i.e., software parts operating independent of user interactions.
The following interactions are in scope:
– local (direct wired) access to the object by a human user, a local and automated computer
agent, or a built-in HMI or panel;
– remote (via dial-up or wireless media) access to the object by a human user;
– remote (via dial-up or wireless media) access to the object by a remote automated computer
agent, e.g. another object at another substation, a distributed energy resource at an enduser’s
facility, or a control centre application.
While this document defines a set of mandatory roles to be supported, the exchange format for
defined specific or custom roles is also in scope of this document.
Out of scope for this document are all topics which are not directly related to the definition of
roles and access tokens for local and remote access, especially administrative or organizational
tasks, such as:
– user names and password definitions/policies;
– management of keys and/or key exchange;
– engineering process of roles;
– assignment of roles;
– selection of trusted certificate authorities issuing credentials (access tokens);
– defining the tasks of a security officer;
– integrating local policies in RBAC;
NOTE Specifically, the management of certificates is addressed in IEC 62351-9.
Existing standards (see ANSI INCITS 359-2004, IEC 62443 (all parts), and IEEE 802.1X-2004)
in process control industry and access control (RFC 2904 and RFC 2905) are not sufficient as
none of them specify neither the exact role name and associated permissions nor the format of
the access tokens nor the detailed mechanism by which access tokens are transferred to and
authenticated by the target system – all this information is needed though for interoperability.
On the other hand, IEEE 1686 already defines a minimum number of roles to be supported as
well as permissions, which are to be addressed by the roles. Note that IEEE 1686 is currently
being revised.
- Standard77 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61968 is the first in a series that, taken as a whole, defines interfaces for the
major elements of an interface architecture for power system management and associated
information exchange.
This document identifies and establishes recommendations for standard interfaces based on
an Interface Reference Model (IRM). Subsequent clauses of this document are based on each
interface identified in the IRM. This set of standards is limited to the definition of interfaces.
They provide for interoperability among different computer systems, platforms, and languages.
IEC 61968-100 gives recommendations for methods and technologies to be used to
implement functionality conforming to these interfaces.
As used in IEC 61968, distribution management consists of various distributed application
components for the utility to manage electrical distribution networks. These capabilities
include monitoring and control of equipment for power delivery, management processes to
ensure system reliability, voltage management, demand-side management, outage
management, work management, network model management, facilities management, and
metering. The IRM is specified in Clause 3. The IRM defines the high-level view of the TC 57
reference architecture and the detailed in the relevant 61968 series, 61970 series or 62325
series. The goal of the IRM is to provide a common relevant context view for TC 57 that
covers domains like transmission, distribution, market, generation, consumer, regional
reliability operators, and regulators.
- Standard106 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment13 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment141 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment144 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment27 pagesEnglish languagesale 10% offe-Library read for1 day
- Standard427 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment112 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61968 specifies the information content of a set of message types that can be
used to support many of the business functions related to records and asset management.
Typical uses of the message types defined in this document include network extension
planning, copying feeder or other network data between systems, network or diagram edits
and asset inspection. Message types defined in other parts of IEC 61968 may also be
relevant to these use cases.
- Standard171 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61850 specifies a method of exchanging data through any kinds of network, including public networks. Among the various kinds of services specified in IEC 61850-7-2, only the client/server and time synchronization services are considered so far.
NOTE Client/server services of GOOSE and SMV models are mapped as well (see Table 1). For the client/server services, the principle is to map the objects and services of the ACSI (Abstract Communication Service Interface defined in IEC 61850-7-2) to XML messages transported over XMPP. The mapping description includes mainly three aspects:
• The usage of the XMPP protocol itself, describing in details which features are really used and how they are used by the mapping (see Clause 6).
• How to achieve end-to-end secured communications (see Clause 7).
• The description of the XML payloads corresponding to each ACSI service thanks in particular to the XML Schema and XML message examples (starting at Clause 9).
NOTE 1 This document does not address the detailed usage of the XMPP protocol.
NOTE 2 This document does not address system management services.
NOTE 3 For the information of people familiar with the mapping defined in IEC 61850-8-1, the XML messages defined in the present document are derived from those defined in IEC 61850-8-1 but with an XML encoding instead of a binary one. In this way implementing gateways between IEC 61850-8-1 and IEC 61850-8-2 is very straightforward in both directions. However reading IEC 61850-8-1 is not necessary to understand the present document except when it is used in conjunction with one of the GOOSE mappings described in IEC 61850-8-1.
- Standard258 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61970 is a member of the IEC 61970-450 to 499 series that, taken as a whole, defines, at an abstract level, the content and exchange mechanisms used for data transmitted between control centre components.
Included in this part of IEC 61970 are the general use cases for exchange of diagram layout data, and guidelines for linking the layout definitions with CIM data. Guidelines for management of schematic definitions through multiple revisions are also included.
- Amendment7 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62351 extends the scope of IEC TS 62351-4:2007 [1]1 by specifying a
compatibility mode that provides interoperation with implementation based on IEC TS 62351-
4:2007 and by specifying extended capabilities referred to as native mode.
This part of IEC 62351 specifies security requirements both at the transport layer and at the
application layer. While IEC TS 62351-4:2007 primarily provided some limited support at the
application layer for authentication during handshake for the Manufacturing Message
Specification (MMS) based applications, this document also provides support for extended
integrity and authentication both for the handshake phase and for the data transfer phase. It
provides for shared key management and data transfer encryption at the application layer and
it provides security end-to-end (E2E) with zero or more intermediate entities. While IEC TS
62351-4:2007 only provides support for systems based on the MMS, i.e. systems using an
Open Systems Interworking (OSI) protocol stack, this document also provides support for
application protocols using other protocol stacks, e.g. an Internet protocol suite (see 4.1).
This support is extended to protect application protocols using XML encoding. This extended
security at the application layer is referred to as E2E-security.
In addition to E2E security, this part of IEC 62351 also provides mapping to environmental
protocols carrying the security related information. Only OSI and XMPP environments are
currently considered.
It is intended that this part of IEC 62351 be referenced as a normative part of standards that
have a need for using application protocols, e.g., MMS, in a secure manner.
It is anticipated that there are implementations, in particular Inter-Control Centre
Communications Protocol (ICCP) implementations that are dependent on the IEC TS 62351-
4:2007 specifications of the T-profile and the A-security-profile. The specifications from IEC
TS 62351-4:2007 are therefore included in this part of IEC 62351. Implementations supporting
these specifications will interwork with implementation based on IEC TS 62351-4:2007.
NOTE The A-security-profile is in the strict sense not a profile, but the term is here kept for historical reasons.
This document represents a set of mandatory and optional security specifications to be
implemented to protect application protocols.
The initial audience for this document is the members of the working groups developing or
making use of protocols. For the measures described in this part of IEC 62351 to take effect,
they shall be accepted and referenced by the specifications for the protocols themselves.
The subsequent audience for this document is the developers of products that implement
these protocols and the end user that want to specify requirements for its own environment.
Portions of this document may also be of use to managers and executives in order to
understand the purpose and requirements of the work.
- Standard113 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft75 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment188 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62325 is for European electricity markets.
This document specifies a standard for a communication platform which every Transmission
System Operator (TSO) in Europe can use to exchange reliably and securely documents for
the energy market. Consequently a European market participant (TSO, regional supervision
centre, distribution utility, power exchange, etc.) could benefit from a single, common,
harmonised and secure platform for message exchange with other participants; thus, reducing
the cost of building different information technology (IT) platforms to interface with all the
parties involved.
“MADES” (MArket Data Exchange Standard) is the acronym to designate this standard.
MADES is a specification for a decentralised common communication platform based on
international IT standards:
• From an application program perspective, MADES specifies the software interfaces to
exchange electronic documents with peer applications. Such interfaces mainly provide
means to send and receive documents using a so-called “MADES communication system”
(or "MADES system" or simply "system"). The sender can request about the status of the
delivery of a document and the recipient issues a message back, the acknowledgement,
when receiving the document. This makes a MADES system usable for exchanging
documents in business processes requiring a reliable delivery.
• MADES also specifies services hidden to the applications such as recipient localisation,
recipient connection status, message routing and security. Services include directory,
authentication, signing, encryption, message tracking, message logging and message
temporary storage.
The purpose of MADES is to create a secured message exchange standard based on
standard communication protocols and utilising IT best practices for exchanging data over any
TCP/IP communication network, in order to facilitate business-to-business (B2B) information
exchanges as described in IEC 62325-351 and the IEC 62325-451 series.
A MADES system acts as a post-office organisation: the transported object is a “message” in
which the document of the sender is securely packaged in an envelope containing metadata,
which is necessary information for transportation, tracking and delivery.
- Standard90 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62351 specifies how to provide confidentiality, integrity protection, and message level authentication for SCADA and telecontrol protocols that make use of TCP/IP as a message transport layer when cyber-security is required.
Although there are many possible solutions to secure TCP/IP, the particular scope of this part is to provide security between communicating entities at either end of a TCP/IP connection within the end communicating entities. The use and specification of intervening external security devices (e.g. “bump-in-the-wire”) are considered out-of-scope.
This part of IEC 62351 specifies how to secure TCP/IP-based protocols through constraints on the specification of the messages, procedures, and algorithms of Transport Layer Security (TLS) (defined in RFC 5246) so that they are applicable to the telecontrol environment of the IEC. TLS is applied to protect the TCP communication. It is intended that this standard be referenced as a normative part of other IEC standards that have the need for providing security for their TCP/IP-based protocol. However, it is up to the individual protocol security initiatives to decide if this standard is to be referenced.
This part of IEC 62351 reflects the security requirements of the IEC power systems management protocols. Should other standards bring forward new requirements, this standard may need to be revised.
- Amendment11 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62325 specifies a UML package for the market information publication
business process and its associated document contextual models, assembly models and XML
schemas for use within the European-style electricity markets.
This part of IEC 62325 is based on the European-style market contextual model
(IEC 62325-351). The business process covered by this part of IEC 62325 is described in
Clause 5.
The relevant aggregate core components (ACCs) defined in IEC 62325-351 have been
contextualised into aggregated business information entities (ABIEs) to satisfy the
requirements of the European-style market publication business process.
- Standard254 pagesEnglish languagesale 10% offe-Library read for1 day
Specifies the information content of a set of message types that can be used to support many of the business functions related to network operations. Typical uses of the message types defined in this part include data acquisition by external systems, fault isolation, fault restoration, trouble management, maintenance of the plant, and the commissioning of the plant.
- Standard163 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 61970 belongs to the IEC 61970-450 to IEC 61970-499 series that, taken as
a whole, define at an abstract level the content and exchange mechanisms used for data
transmitted between power system analyses applications, control centers and/or control
center components.
The purpose of this document is to rigorously define the subset of classes, class attributes,
and roles from the CIM necessary to describe the result of state estimation, power flow and
other similar applications that produce a steady-state solution of a power network, under a set
of use cases which are included informatively in this standard.
This document is intended for two distinct audiences, data producers and data recipients, and
may be read from those two perspectives. From the standpoint of model export software used
by a data producer, the document describes how a producer may describe an instance of a
network case in order to make it available to some other program. From the standpoint of a
consumer, the document describes what that importing software must be able to interpret in
order to consume power flow cases.
There are many different use cases for which use of this document is expected and they differ
in the way that the document will be applied in each case. Implementers are expected to
consider what use cases they wish to cover in order to know the extent of different options
they must cover. As an example, this document will be used in some cases to exchange
starting conditions rather than solved conditions, so if this is an important use case, it means
that a consumer application needs to be able to handle an unsolved state as well as one
which has met some solution criteria.
- Standard70 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62325 specifies the common information model (CIM) for energy market
communications.
The CIM is an abstract model that represents all the major objects in an electric utility
enterprise typically involved in utility operations and electricity market management. By
providing a standard way of representing power system resources as object classes and
attributes, along with their relationships, the CIM facilitates the integration of market
management system (MMS) applications developed independently by different vendors,
between entire MMS systems developed independently, or between an MMS system and
other systems concerned with different aspects of market management, such as capacity
allocation, day-ahead management, balancing, settlement, etc.
The CIM facilitates integration by defining a common language (i.e. semantics) based on the
CIM to enable these applications or systems to access public data and exchange information
independent of how such information is represented internally.
The object classes represented in the CIM are abstract in nature and may be used in a wide
variety of applications. The use of the CIM goes far beyond its application in a market
management system.
Due to the size of the complete CIM, the object classes contained in the CIM are grouped into
a number of logical packages, each of which represents a certain part of the overall power
system being modeled. Collections of these packages are progressed as separate
international standards. This particular document specifies a set of packages which provide a
logical view of the functional aspects of market management within an electricity market, and
other functional aspects including environmental aspects that are closely related to electricity
markets and that are shared between all applications. Other standards specify more specific
parts of the model that are needed by only certain applications. Subclause 4.2 provides the
current grouping of packages into standards documents.
This new edition of IEC 62325-301 contains support for demand-side communication within a
wholesale market. The IEC 62325-301 additions include support for demand-side resource
registration and enrollment of a market participating resource as well as support for
deployment and performance evaluation of demand side resources. A new package has been
included in this edition of IEC 62325-301 to support environmental (weather) data. This new
package ‘Environmental’ provides support for weather conditions including forecasts,
observations, measurements, phenomena, and alerts. Additional updates have been added
within the ‘MarketManagement’ package to support the transparency regulations, flow based
market coupling and new network codes to support the European Markets. These updates
include new classes, attributes and associations within the IEC 62325 packages as well as
updates to existing classes, attributes and associations to accurately represent the existing
use cases.
- Standard443 pagesEnglish languagesale 10% offe-Library read for1 day
The common information model (CIM) is an abstract model that represents all the major
objects in an electric utility enterprise typically involved in utility operations. By providing a
standard way of representing power system resources as object classes and attributes, along
with their relationships, the CIM facilitates the integration of energy management system
(EMS) applications developed independently by different vendors, between entire EMSs
developed independently, or between an EMS and other systems concerned with different
aspects of power system operations, such as generation or distribution management. SCADA
is modelled to the extent necessary to support power system simulation and communication
between control centres. The CIM facilitates integration by defining a common language (i.e.
semantics) based on the CIM to enable these applications or systems to access public data
and exchange information independent of how such information is represented internally.
Due to the size of the complete CIM, the object classes contained in the CIM are grouped into
a number of logical packages, each of which represents a certain part of the overall power
system being modelled. Collections of these packages are being developed as separate
International Standards.
This particular document specifies a Dynamics package which contains extensions to the CIM
to support the exchange of models between software applications that perform analysis of the
steady-state stability (small-signal stability) or transient stability of a power system as defined
by IEEE / CIGRE Definition and classification of power system stability IEEE/CIGRE joint task
force on stability terms and definitions.
The model descriptions in this standard provide specifications for each type of dynamic model
as well as the information that needs to be included in dynamic case exchanges between
planning/study applications.
The scope of the CIM extensions specified in this standard includes:
• standard models: a simplified approach to describing dynamic models, where models
representing dynamic behaviour of elements of the power system are contained in
predefined libraries of classes which are interconnected in a standard manner. Only the
names of the selected elements of the models along with their attributes are needed to
describe dynamic behaviour.
• proprietary user-defined models: an approach providing users the ability to define the
parameters of a dynamic behaviour model representing a vendor or user proprietary
device where an explicit description of the model is not provided by the standard. The
same libraries and standard interconnections are used for both proprietary user-defined
models and standard models. The behavioural details of the model are not documented in
the standard, only the model parameters.
- Standard476 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62351 defines network and system management (NSM) data object models
that are specific to power system operations. These NSM data objects will be used to monitor
the health of networks and systems, to detect possible security intrusions, and to manage the
performance and reliability of the information infrastructure. The goal is to define a set of
abstract objects that will allow the remote monitoring of the health and condition of IEDs
(Intelligent Electronic Devices), RTUs (Remote Terminal Units), DERs (Distributed Energy
Resources) systems and other systems that are important to power system operations.
Power systems operations are increasingly reliant on information infrastructures, including
communication networks, IEDs, and self-defining communication protocols. Therefore,
management of the information infrastructure has become crucial to providing the necessary
high levels of security and reliability in power system operations.
The telecommunication infrastructure that is in use for the transport of telecontrol and
automation protocols is already subject to health and condition monitoring control, using the
concepts developed in the IETF Simple Network Management Protocol (SNMP) standards for
network management. However, power system specific devices (like teleprotection,
telecontrol, substation automation, synchrophasors, inverters and protections) need instead a
specific solution for monitoring their health.
The NSM objects provide monitoring data for IEC protocols used for power systems
(IEC 61850, IEC 60870-5-104) and device specific environmental and security status. As a
derivative of IEC 60870-5-104, IEEE 1815 DNP3 is also included in the list of monitored
protocols. The NSM data objects use the naming conventions developed for IEC 61850,
expanded to address NSM issues. For the sake of generality these data objects, and the data
types of which they are comprised, are defined as abstract models of data objects.
In addition to the abstract model, in order to allow the integration of the monitoring of power
system devices within the NSM environment in this part of IEC 62351, a mapping of objects to
the SNMP protocol of Management Information Base (MIBs) is provided.
The objects that are already covered by existing MIBs are not defined here but are expected
to be compliant with existing MIB standards.
- Standard237 pagesEnglish languagesale 10% offe-Library read for1 day
This IEC document is one of the IEC 61970-450 to 499 series that, taken as a whole, defines
at an abstract level the content and exchange mechanisms used for data transmitted between
control centers and/or control center components, such as power systems applications.
The purpose of this document is to define the subset of classes, class attributes, and roles
from the CIM necessary to execute state estimation and power flow applications. The North
American Electric Reliability Council (NERC) Data Exchange Working Group (DEWG)
Common Power System Modeling group (CPSM) produced the original data requirements,
which are shown in Annex E. These requirements are based on prior industry practices for
exchanging power system model data for use primarily in planning studies. However, the list
of required data has been extended to facilitate a model exchange that includes parameters
common to breaker-oriented applications. Where necessary this document establishes
conventions, shown in Clause 6, with which an XML data file must comply in order to be
considered valid for exchange of models.
This document is intended for two distinct audiences, data producers and data recipients, and
may be read from two perspectives.
From the standpoint of model export software used by a data producer, the document
describes a minimum subset of CIM classes, attributes, and associations which must be
present in an XML formatted data file for model exchange. This standard does not dictate how
the network is modelled, however. It only dictates what classes, attributes, and associations
are to be used to describe the source model as it exists.
Optional and required classes, attributes and associations must be imported if they are in the
model file prior to import. If an optional attribute does not exist in the imported file, it does not
have to be exported in case exactly the same data set is exported, i.e. the tool is not obliged
to automatically provide this attribute. If any mandatory attribute or association is missing, the
exchanged data is considered invalid. Specific business processes may relax restrictions of
the profile, but such exchanges would not be considered to be compliant with the standard.
Business processes governing different exchanges can also require mandatory exchange of
certain optional attributes or associations.
Furthermore, an exporter may, at his or her discretion, produce an XML data file containing
additional class data described by the CIM RDF Schema but not required by this document
provided these data adhere to the conventions established in Clause 6.
From the standpoint of the model import used by a data recipient, the document describes a
subset of the CIM that importing software must be able to interpret in order to import exported
models. As mentioned above, data providers are free to exceed the minimum requirements
described herein as long as their resulting data files are compliant with the CIM RDF Schema
and the conventions established in Clause 6. The document, therefore, describes additional
classes and class data that, although not required, exporters will, in all likelihood, choose to
include in their data files. The additional classes and data are labeled as required (cardinality
1..1) or as optional (cardinality 0..1) to distinguish them from their required counterparts.
Please note, however, that data importers could potentially receive data containing instances
of any and all classes described by the CIM RDF Schema.
- Standard177 pagesEnglish languagesale 10% offe-Library read for1 day
Based on the European style market profile (ESMP) (IEC 62325-351), this part of IEC 62325-
451 specifies a package for the settlement and reconciliation business process and the
associated document contextual model, assembly model and XML schema for use within
European style markets.
The relevant aggregate core components (ACCs) defined in IEC 62325-351 have been
contextualised into aggregated business information entities (ABIEs) to satisfy the
requirements of this business process. The contextualised ABIEs have been assembled into
the relevant document contextual models. Related assembly models and XML schema for the
exchange of information between market participants are automatically generated from the
assembled document contextual models.
This part of IEC 62325 provides a uniform layout for the transmission of aggregated data in
order to settle the electricity market. It is however not the purpose of this document to define
the formula to be taken into account to settle or reconcile a market. The purpose of this
document is only to enable the information exchange necessary to carry out the computation
of settlement and reconciliation.
The settlement process or reconciliation process is the way to compute the final position of
each market participant as well as its imbalance amounts.
- Standard62 pagesEnglish languagesale 10% offe-Library read for1 day
- Amendment15 pagesEnglish languagesale 10% offe-Library read for1 day
Based on the European style market contextual model (IEC 62325-351), this part of
IEC 62325 specifies a UML package for the acknowledgment business process and its
associated document contextual model, assembly model and XML schema for use within the
European style electricity markets.
The relevant aggregate core components (ACCs) defined in IEC 62325-351 have been
contextualized into aggregated business information entities (ABIEs) to satisfy the
requirements of the European style market acknowledgment business process.
The contextualized ABIEs have been assembled into the acknowledgment document
contextual model.
A related assembly model and an XML schema for the exchange of acknowledgement
information between market participants is automatically generated from the assembled
document contextual model.
- Standard44 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62351 specifies cryptographic key management, namely how to generate,
distribute, revoke, and handle public-key certificates and cryptographic keys to protect digital
data and its communication. Included in the scope is the handling of asymmetric keys (e.g.
private keys and public-key certificates), as well as symmetric keys for groups (GDOI).
This part of IEC 62351 assumes that other standards have already chosen the type of keys
and cryptography that will be utilized, since the cryptography algorithms and key materials
chosen will be typically mandated by an organization’s own local security policies and by the
need to be compliant with other international standards. This document therefore specifies
only the management techniques for these selected key and cryptography infrastructures. The
objective is to define requirements and technologies to achieve interoperability of key
management.
The purpose of this part of IEC 62351 is to guarantee interoperability among different vendors
by specifying or limiting key management options to be used. This document assumes that
the reader understands cryptography and PKI principles.
- Standard88 pagesEnglish languagesale 10% offe-Library read for1 day
This part of IEC 62351 specifies schema, procedures, and algorithms for securing XML
documents that are used within the scope of the IEC as well as documents in other domains
(e.g. IEEE, proprietary, etc.). This part is intended to be referenced by standards if secure
exchanges are required, unless there is an agreement between parties in order to use other
recognized secure exchange mechanisms.
This part of IEC 62351 utilizes well-known W3C standards for XML document security and
provides profiling of these standards and additional extensions. The IEC 62351-11 extensions
provide the capability to provide:
• Header: the header contains information relevant to the creation of the secured document
such as the Date and Time when IEC 62351-11 was created.
• A choice of encapsulating the original XML document in an encrypted (Encrypted) or nonencrypted
(nonEncrypted) format. If encryption is chosen, there is a mechanism provided
to express the information required to actually perform encryption in an interoperable
manner (EncryptionInfo).
• AccessControl: a mechanism to express access control information regarding information
contained in the original XML document.
• Body: is used to contain the original XML document that is being encapsulated.
• Signature: a signature that can be used for the purposes of authentication and tamper
detection.
For the measures described in this document to take effect, they must be accepted and
referenced by the specifications themselves. This document is written to enable that process.
The subsequent audience for this part of IEC 62351 is intended to be the developers of
products that implement these specifications.
Portions of this part of IEC 62351 may also be of use to managers and executives in order to
understand the purpose and requirements of the work.
- Standard41 pagesEnglish languagesale 10% offe-Library read for1 day
- Standard41 pagesEnglish languagesale 10% offe-Library read for1 day