The proposed solution: • is both machine readable and human readable, although primarily intended for programmatic access, • can be accessed using any tool that supports the Document Obj
General
Model exchange consists of sharing a set of documents that include instance data, known as a model, along with a header Each model and header's structure and semantics 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.
A CIMXML document shall consists of a header and a model section
The header section of a document provides essential details about the model, including its creation date and description It may also highlight the relationships between this model and others, which is crucial in workflows where models are interdependent, such as when one model succeeds or relies on another.
Rules for CIMXML documents and headers
A CIMXML document is described by a single header Multiple headers in a CIMXML document are not allowed
The header section shall always be the first element in a CIMXML document The header section elements are
The data in the model section is defined by one or more profiles listed within the header
Elements in a CIMXML document may have references to elements (resources) in other CIMXML documents
In a CIMXML document, only one header element is permitted, which means the model section can only include elements that the header can describe If additional headers are required, a separate CIMXML document must be created for each header.
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
The classes FullModel, DifferenceModel, and Statements represent the model data, while the Model class defines the header This article provides a bottom-up description of these classes.
• The Statements class represent a set of Definition (refer to 7.2.3.5) and/or Description (refer to 7.2.3.6) elements
• The FullModel (refer to 7.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 7.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 data rather than the CIMXML document itself A new rdf:about identification is generated only when there are changes to the model data in the created documents.
A repeated creation of documents from unchanged model data should have the same rdf:about identification as previous document generated from the same model data
In the generated document, the sequence of XML elements is generally unimportant, with the exception of the FullModel element, which must always be positioned at the beginning The attributes of the Model class are detailed in Table 2.
Model created The date when the document was created
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 The number of UTF-8 characters is limited to 2000
Model modelingAuthoritySet A urn/uri referring to the organisation or role sourcing the model in the
CIMXML document Models from the same organisation or role but for different profiles shall have the same urn/uri
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 an integer that is changed in synchronisation with the rdf:about identifier, refer to description of the Model class preceding this table
Model DependentOn References to other models that the model in this document depends on, e.g
– 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
The referenced models are identified by the FullModel rdf:about attribute (see 7.2.3.4) for full model documents and by DifferenceModel rdf:about attribute (see 7.2.4.6) for difference model documents
The producer of the CIMXML document maintains the references, which are applicable to the specific model version and identifier for which the document was created.
The use of DependentOn by consumers is optional However, if a consumer has accessed the DependentOn documents, it is anticipated that the currently consumed document will not contain any dangling references.
Model Depending All documents depending on the model described by this document This role is not intended to be included in any document exchanging instance data
When a model is updated, it supersedes the previous models that served as the basis for the update This document references the models that have been superseded, with each superseded model noted in the header A model may supersede multiple models, and the referenced models are identified by the FullModel rdf:about attribute for full model documents and by the DifferenceModel rdf:about attribute for difference model documents.
The references in a CIMXML document are managed by its producer and are applicable to the specific model version and identifier for which the document was created Consumers may optionally use the Supersedes feature; however, if they have accessed the Supersedes documents, it is anticipated that there will be no unresolved references in the currently accessed document.
Model SupersededBy All models superseding this model This role is not intended to be included in any document exchanging instance data
When a document is regenerated from an unchanged model, all attributes will match those of the original document However, if the received model is modified in any way, the attributes may differ based on the specific nature of the modifications.
DependentOn, Depending, Supersedes, and SupersededBy indicate the context of the document at the time it was created The references in a receiving system are optional, and their usage may vary based on the specific use case, as noted in section 5.4.
The profile attribute is a URI having the following format for IEC profiles:
• http://iec.ch///-/// where text in is replaced by a describing text, e.g
• http://iec.ch/TC57/2011/61970-452/Equipment/2/1
The profile URI must be considered as a whole, as the complete string is essential for identifying a profile Therefore, software should not attempt to parse or interpret any substrings of the profile URI, such as year, standard, or part.
Other organizations using the CIMXML serialization may have other profile URIs
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 (7.2.3.3)
2) Statement elements appear as Definition (7.2.3.5) or Description elements (7.2.3.6)
3) Literal attributes, e.g Model.created, appears as literal property elements (7.2.3.8)
4) Roles appear, e.g Model.Supersedes, as resource property elements (7.2.3.11)
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 document can be regenerated multiple times using the same model, and when this occurs, the identification (Model rdf:about) remains consistent with previous documents generated from that model.
A DifferenceModel and a FullModel document created from the same model share identical identification and Supersedes, allowing them to be used interchangeably However, if a receiving system requires a full model equivalent to the one in the FullModel document, the DifferenceModel must be applied to the corresponding full model that has been superseded.
Work flow
A workflow consists of a series of exchange events, as outlined in section 5.3 This model incorporates time-related workflow events through the Model.Supersedes attribute and profile-related events via the Model.DependentOn attribute, illustrated in Figure 2.
Figure 2 – Example work flow events
In this example, a network model is shared as a collection of models defined 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, the equipment model E3 is represented by both a full and a DifferenceModel 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 includes 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 validated T2b with E2, this is the only compatible combination 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 stability of identifiers over time also requires the following
• An identifier shall be created for any object when its existence become know Note that objects in a model may or may not represent real physical equipment
• An identifier for an object, e.g a deleted object, is not allowed to be reused
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 designed to be compatible with ISO/IEC 9834-8:2005, which details the procedures for OSI Registration Authorities in generating and registering Universally Unique Identifiers (UUIDs) and their application as ASN.1 Object Identifier components, as specified in ITU-T Rec X.667, 2004.
CIMXML elements are identified by a URI Also other forms than the URI is allowed but not recommended
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 characters are lower case conforming to W3C (ISO 8859/1 8-bit single-byte coded graphic character set known as Latin Alphabet No 1
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:
In RDF, the rdf:ID identifier is unique within a document, while rdf:about is unique within a namespace When using the UUID namespace urn:uuid for rdf:about, identifiers become globally unique Therefore, CIMXML advocates for the use of rdf:about identification within the UUID namespace for all identifiers.
In earlier RDF specifications, an rdf:ID indicated the creation of a new resource, while rdf:about referred to an existing resource However, this distinction has since been abandoned.
As both are UUIDs they have the same meaning For backwards compatibility both are allowed but the rdf:about form is the preferred
Identifiers in the FullModel and DifferenceModel elements shall always use the rdf:about identification in the UUID name space, i.e starting with “urn:uuid:”.
CIMXML element identification
Resource identification is crucial in RDF, as every object is designated with 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 6.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 6.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 considered invalid in RDF This underscore is consistently applied to enhance parser simplicity, regardless of whether the UUID begins with a non-numeric character.
• The prefix is defined as an xml:base=“urn:uuid:”
• rdf:ID=”_26cc8d71-3b7e-4cf8-8c93-8d9d557a4846” the rdf:ID” form
• rdf:about=”#_26cc8d71-3b7e-4cf8-8c93-8d9d557a4846” the “hash” form
• rdf:about=”urn:uuid:26cc8d71-3b7e-4cf8-8c93-8d9d557a4846” the “urn:uuid:” form
A receiver compatible with Edition 2 is supposed to be able to process all three forms
A receiver compatible with Edition 1 is supposed to process the rdf:ID and rdf:about forms
A producer compatible with Edition 2 should preferably only use the urn:uuid: form but is allowed to continue produce the rdf:ID and rdf:about forms
A producer compatible with Edition 1 will produce the the rdf:ID and rdf:about forms.
Older ID formats
In recent years, various resource identifiers (IDs) have been utilized, some of which do not adhere to the formatting standards outlined in section 6.3 As a result, existing systems may be operating with object identifiers that fail to comply with these specified guidelines.
Identifiers not complying with 6.3 is not allowed to consist of more than 60 UTF-8 characters
An ID change indicates that identifiers in the old format will not align with those in the new format unless a translation or mapping is applied Since IDs do not inherently describe themselves, creating such translations can be challenging.
Due to the far reaching consequences of an ID format change existing systems are allowed to continue use the old format for objects
When upgrading to Edition 2 of this document, new objects in the system must adopt the ID format specified in section 6.1 Existing objects created prior to this edition can retain their original ID format without needing conversion Consequently, the system will accommodate both the old and new ID formats.
Object type
General
CIMXML elements are defined using the Definition element (see 7.2.3.6) When exchanging multiple documents, elements with the same ID may have varying types However, this specification does not outline the method for communicating type changes.
References to a more generic type than the actual
In data exchanges involving multiple profiles, an object with the same ID may be represented in various documents A profile can describe data at a lower level in the inheritance hierarchy than the actual object type, such as the PowerSystemResource (PSR), which is seldom instantiated directly but rather through its subclasses When data related to a CIM class is distributed across multiple profiles, each profile is permitted to utilize the most suitable level in the inheritance hierarchy for the exchange This approach simplifies profiling by allowing a focus on the relevant data, as illustrated by the example of exchange locations.
Figure 4 – CIM PSR – Location data model
The PSR class includes a Location attribute, which allows for the exchange of location information However, since PSR is instantiated as more specific classes like Breaker and BusbarSystem, it is impractical to list all possible classes for location exchange due to the evolving number of leaf classes Therefore, a stable profile for exchanging location information is essential.
IEC just to use the PowerSystemResource class The profile will then just include PowerSystemResource and a CIMXML element will look as follows: