BSI Standards PublicationEnergy Management System Application Program Interface EMS-API Part 552: CIMXML Model Exchange Format... IEC 60050 Series International Electrotechnical Vocabula
General
Model exchange consists of sharing a set of documents, each containing instance data known as a model along with a header The structure and semantics of these models are defined by a profile, which is not part of the exchanged data The entire exchange process is regulated by a set of profiles outlined in a Profile Document.
The header of a model document provides essential details such as the creation date and a description of the model It may also highlight the relationships between different models, which is crucial in workflows where models are interconnected, indicating dependencies or succession among them.
Subclauses 4.2 to 4.4 define the model with header data and work flow it is designed to support.
CIMXML documents and headers
A CIMXML document is described by a single header Multiple headers in a CIMXML document are not allowed Hence instance data in a CIMXML document adhere to a single profile
In case multiple and possibly related CIMXML documents need to be kept together they shall be collected in an archive, e.g zip.
Model and header data description
A description of a model is attached as header data to the model Figure 1 describes the model with header information class Header Model
+ created :DateTime + scenarioTime :DateTime + description :String + modelingAuthoritySet :URI [0 1]
The classes FullModel, DifferenceModel, and Statements represent the model data, while the Model and Description classes define the header This article provides a bottom-up overview of these classes.
The FullModelDocumentElement class encompasses all elements found in a full model document, which includes two subtypes: Statements and FullModel Typically, a full model document consists of a single FullModel element accompanied by a set of Definition elements.
• The Statements class represent a set of Definition (refer to 6.2.3.5) and/or Description (refer to 6.2.3.6) elements
• The FullModel (refer to 6.2.3.4) class represent the full model header and its contents is described by the Model class
The DifferenceModel class serves as the header for the difference model, as detailed in section 6.2.4.6 It is defined by the Model class and includes two association roles: forwardDifferences and reverseDifferences, each of which can contain a single set of Statements.
The Model class defines the common header content for both the FullModel and the DifferenceModel, identified by a unique rdf:about attribute This attribute specifically describes the model itself rather than the document containing the header, meaning that multiple documents generated from the same data model will share the same rdf:about Consequently, any change to the model will result in a new rdf:about when a document is created.
The Model class attributes are described in Table 1
Model created The date when the model was created (note this is typically not when the
CIMXML document was created which is after this time)
Model scenarioTime The date and time that the model represents, e.g the current time for an operational model, a historical model or a future planned model
Model description A description of the model, e.g the name of person that created the model and for what purpose
Model modelingAuthoritySet A URN describing the equipment model sourcing the data in a CIMXML document, e.g a model for the whole or a part of a country
Model profile A URN describing the Profiles that governs this model It uniquely identifies the Profile and its version
The model version refers to the specific iteration of the model that sources data within a CIMXML document This includes variations of the equipment model for the ModelingAuthoritySet and distinct study cases that yield different solutions.
The version attribute is a custom string that synchronizes with the rdf:about identifier, as described in the Model class Additionally, the Model DependentOn refers to the models that the current model relies on, providing essential context for its dependencies.
– A load flow solution depends on the topology model it was computed from
– A topology model computed by a topology processor depends on the network model it was computed from
Model Depending All models depending on this model This role is not intended to be included in any document exchanging instance data
When a model is updated, the new version replaces the previous models that served as the foundation for the update This refers to CIMXML documents that detail the updated models.
Model SupersededBy All models superseding this model This role is not intended to be included in any document exchanging instance data
The profile attribute is a URI having the following format: http://iec.ch///-// e.g http://iec.ch/TC57/2011/61970-452/Equipment/2
The UML in Figure 1 translates into CIMXML elements as follows:
1) A leaf class in Figure 1 (DifferenceModel, Statements and FullModel) appears as class elements under the document element (6.2.3.3)
2) Statement elements appear as Definition (6.2.3.5) or Description elements (6.2.3.6)
3) Literal attributes, e.g Model.created, appears as literal property elements (6.2.3.8)
4) Roles appear, e.g Model.Supersedes, as resource property elements (6.2.3.10)
5) Inherited attributes and roles appear directly as elements under the leaf class following the rules 3, 4 and 5 above
6) A CIMXML model document is identified by a Model rdf:about attribute (implicit in the UML) Hence the roles DependentOn and Supersedes are references to the Model rdf:about attribute
A full model document can be regenerated multiple times using the same source data, and when this occurs, the model identification (Model rdf:about) remains consistent with the original full model document, provided the source data has not changed.
When creating a complete model document that replaces a differential, the new document will retain the same model identification (Model rdf:about) as the differential, provided that the model has not changed since the differential's creation Therefore, it serves as an alternative to the differential.
Work flow
A workflow consists of a series of exchange events, as outlined in section 4.3 This model incorporates time-related workflow events through the Model.Supersedes attribute and profile-related events via the Model.DependentOn attribute An illustrative example can be found in Figure 2.
Profile Full model DifferentialModel DependentOn Supersedes
Figure 2 – Example work flow events
In this example, a network model is shared as a collection of models governed by a Profile Document that includes Equipment, Topology, and State Variables documents The left timeline in Figure 2 illustrates the exchange of the Equipment model document over time, while the center timeline depicts the exchange of new Topology results and their dependencies on Equipment models The rightmost timeline shows the exchange of multiple State Variable documents and their reliance on Topology documents Notably, equipment model E3 is represented by both a full and an incremental document This scenario in Figure 2 is a straightforward case, with a more complex situation illustrated in Figure 3.
Figure 3 – Example work flow events with more dependencies
CIMXML documents, as illustrated in Figure 3, can be generated from a data modeling environment featuring multiple parallel change tracks For instance, the equipment model consists of three tracks—E-Ax, E-Bx, and E-C—that ultimately converge into the comprehensive model E2, which supersedes the individual equipment model tracks.
A recipient of CIMXML documents can utilize topology documents TA, TB, TABa, or T2b alongside the equipment model from E2 However, since the sender has only verified T2b with E2, this combination is the only one guaranteed to be compatible Additionally, the receiver has the option to apply TB and TABb to T1 instead of using T2b.
URIs as identifiers
UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier) can be used to identify resources in such a way that the
• identifiers can be independently and uniquely allocated by different authorities This is a big advantage with the UUID
• identifiers are stable over time and across documents
Embedding the UUID in a Uniform Resource Name (URN) allows for the simplification of the document by removing XML base namespace declarations (xml:base attributes) A URN serves as a concise, fixed-length, absolute URI.
The standard for an URN containing a UUID is defined by the Internet Engineering Task Force RFC 4122
RFC 4122 outlines the syntax for URNs and the allocation of the UUID segment following the last colon This algorithm is compatible with IEC 9834-8:2004, which details the procedures for operating OSI Registration Authorities, specifically regarding the generation and registration of Universally Unique Identifiers (UUIDs) and their application as ASN.1 Object Identifier components, as stated in ITU-T Rec X.667, 2004.
CIMXML elements are identified by a URI A URI can have two forms:
The URL and URN forms have fundamentally different structures, i.e.:
• URL form; protocol://authority/path?query#fragment where the protocol in CIMXML is http
• URN form: urn:namespace:specification where the namespace in CIMXML is uuid
The URN specification format is summarized below
• 12 character hex number where letters are lower case
An example of the URN form is shown below
About rdf:ID and rdf:about
A CIMXML element can be identified by two different RDF constructs:
The use of rdf:ID and rdf:about has a specific meaning that does not align with their definition in RDF The meanings are:
• an rdf:ID specifies the life of object globally, i.e its creation or deletion
• an rdf:about is a reference to an existing object.
CIMXML element identification
Object identification is crucial in RDF, as every element representing an object is assigned an rdf:ID or rdf:about XML attribute In the CIM framework, all classes that derive from IdentifiedObject possess the UML object identification attribute IdentifiedObject.mRID, which is implicitly linked to the rdf:ID/rdf:about XML attribute.
A CIMXML document may only use the URN form (see 5.1) as further described below
CIMXML files utilize XML elements to represent CIM objects such as ACLineSegments and Substations, incorporating various association roles that appear as references within the XML elements, typically through rdf:resource or rdf:about attributes The exchange of CIM data occurs across interconnected CIMXML documents, as outlined in Clause 4, with some references extending beyond individual document boundaries This necessitates that the identification of a CIM object remains stable throughout its lifecycle to prevent disruptions in referencing across these document boundaries.
A common practice in object oriented systems is to assume all objects have an identifier that is unique in space and time which means:
• Different objects are assigned different identifiers
• Identifiers once assigned are never reused even if the original object having it is gone
The URN form as described in 5.1 is used as CIMXML element identification with the following differences
The prefix "urn:uuid:" is substituted with an underscore "_" to prevent a numeric starting character in the non-base part of the identifier, as beginning with a numeric character is invalid in RDF This underscore is consistently added to simplify parsers, regardless of whether the UUID begins with a non-numeric character.
• the prefix is defined as an xml:base=“urn:uuid:”
6 CIMXML format rules and conventions
General
The CIM RDF Schema outlined in IEC 61970-501 enables the conversion of a power system model into an XML document, known as a CIMXML document This document utilizes tags provided by the CIM RDF schema, allowing for effective model exchange The CIMXML model can be parsed, facilitating the import of information into external systems.
Power System Data CIM XML as
Figure 4 – CIMXML-based power system model exchange mechanism
Simplified RDF syntax
General
RDF syntax offers multiple methods to represent identical data sets, such as expressing associations between resources through resource attributes or by nesting elements This flexibility can complicate the use of certain XML tools, like XSL processors, with CIMXML documents.
A subset of the RDF Syntax is utilized in the creation of CIMXML documents, streamlining the process for implementers to develop model serialization and de-serialization software This simplified syntax enhances the efficiency of general XML tools when working with CIMXML documents As a proper subset of the standard RDF syntax, it remains compatible with existing RDF de-serialization software.
This article outlines a subset of the RDF Syntax designed specifically for the exchange of power system models among utilities The specification aims to facilitate the development of de-serialization software for RDF data, streamline the serialization process, and enhance the performance of general XML tools, like XSLT processors, when handling serialized RDF data.
The reduced syntax is a subset of the standard RDF syntax, making it compatible with RDF de-serialization tools like SirPAC This distinguishes it from other simplified syntax proposals.
The reduced syntax maintains the full capabilities of the RDF data model, allowing for the exchange of any RDF data Additionally, it preserves key features of RDF, including the ability to extend a model defined in one document with statements from a second document.
Notation
The simplified syntax is outlined in the following section, where each element type is introduced with a model, defining text, and a reference to the RDF grammar For detailed semantics, refer to the RDF recommendation The notation for the element model includes: a) Italicized symbols representing element types, attribute names, or values, which are defined in the text; b) The symbol "rdf" denotes the implementation's chosen namespace prefix for RDF, while "cim" represents the CIM namespace prefix; c) Comments within the model specify allowed content, with italicized symbols indicating defined elements or content, and constructions like (a | b) showing alternatives, while a* indicates zero or more repetitions of a; d) All other text in the model is considered literal.
Syntax definition
The article enhances the definition of syntax by incorporating examples that facilitate a clearer understanding of formal syntax concepts A single example is utilized across multiple syntax definitions, with the specific syntax being emphasized in bold for clarity.
1 Numbers in square brackets refer to the bibliography
6.2.3.2 Name space URIs defined in this specification
The following name spaces are defined in this specification:
• cim-model-description_uri described by xmlns:md
• difference-model-namespace-uri described by xmlns:dm
Their values are defined as:
• xmlns:md=”http://iec.ch/TC57/61970-552/ModelDescription/1#”
• xmlns:dm=”http://iec.ch/TC57/61970-552/DifferenceModel/1#”
The RDF (Resource Description Framework) is a framework for representing information about resources in the web It includes various data types such as HTML, language-tagged strings, and plain literals RDF properties define relationships between resources, with key properties including subject, predicate, and object RDF also categorizes data into classes like Bag, Seq, and Alt, which represent different types of containers Additionally, RDF supports structured values through properties like value, first, and rest, and includes data types for XML and JSON literals The RDF vocabulary is essential for semantic web applications and data interchange.
The RDF document must declare the element type as rdf:RDF and include the RDF namespace at http://www.w3.org/1999/02/22-rdf-syntax-ns# Additionally, the CIM namespace is required, with adjustments made for newer versions of the CIM schema, necessitating agreement between parties on the version used Other namespaces may also be declared, and it is essential that the xml:base attribute is always present, as referenced in section 5.3.
2008-12-24
T2
New 2
0.4066
T1
ND New1
T2
ND New2
230K