PSE - Power systems management

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.

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.

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

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

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.

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

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.

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.

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.

TAN - // IEC Corrigendum

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This part of IEC 62488 applies to Amplitude Modulation Single Sideband (AM-SSB) Analogue
Power Line Carrier (APLC) Terminals and Systems used to transmit information over power
lines (EHV/HV/MV).
In particular this document covers basically baseband signals with bandwidths of 4 kHz and
2,5 kHz, or multiples thereof, corresponding to the same high frequency bandwidth/s for
single or multi-channel APLC terminals.

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.

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.

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.

IEC 61970-301:2013 defines the Common Information Model (CIM), that is an abstract model representing 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 EMS systems developed independently, or between an EMS system and other systems concerned with different aspects of power system operations, such as generation or distribution management. SCADA is modeled to the extent necessary to support power system simulation and inter-control center 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. Major changes from the fourth edition include the following:  - transformer models have been modified to be consistent for use by distribution and transmission purposes;  - a more general and clear naming approach was added and several ambiguous attributes related to naming were dropped;  - phase component wires models have been enhanced to describe internal phase specific attributes and connections;  - addition of diagram layout models to facilitate the exchange of diagram layout information.

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.

IEC 61970-552:2013 specifies a Component Interface Specification (CIS) for Energy Management Systems Application Program Interfaces. This part specifies the format and rules for exchanging modelling information based upon the CIM. It uses the CIM RDF Schema presented in IEC 61970-501 as the meta-model framework for constructing XML documents of power system modelling information. The style of these documents is called CIMXML format. This standard supports a mechanism for software from independent suppliers to produce and consume CIM described modelling information based on a common format.

Applies to telecontrol equipment and systems with coded bit serial data transmission for monitoring and controlling geographically widespread processes. Defines a telecontrol companion standard that enables interoperability among compatible telecontrol equipment.

IEC 62325-351:2013 specifies a UML package which provides a logical view of the functional aspects of European style market management within an electricity markets. This package is based on the common information model (CIM). The use of the CIM goes far beyond its application in a market management system.

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.

This part of IEC 62361 describes a mapping from CIM profiles to W3C XML Schemas.
The purpose of this mapping is to facilitate the exchange of information in the form of XML
documents whose semantics are defined by the IEC CIM and whose syntax is defined by a
W3C XML schema.

IEC Corrigendum

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 customer support. Typical uses of
the message types include service request, customer agreement, and trouble management.
The purpose of this part of IEC 61968 is to define a standard for the integration of customer
support (CS), which would include customer service, trouble management and point of sale
related components integrated with other systems and business functions within the scope of
IEC 61968. The scope of this standard is the exchange of information between a customer
support system and other systems within the utility enterprise.

This part of IEC 61968 specifies the information content of a set of message types that can be
used to support business functions related to Maintenance and Construction. Typical uses of
the message types defined in this part of IEC 61968 include planned maintenance, unplanned
maintenance, conditional maintenance, work management, new service requests, etc.
Message types defined in other parts of IEC 61968 may also be relevant to these use cases.
The mapping of these messages to specific technologies such as XML will be described at a
later date.