32
ARTICLE 5: CIM - UNDER THE HOOD Authors; Lars-Ola (LOO), Kurt (KH), Becky (BI), Kendall (KD), Margaret (MG), Tanja (TK), Alan (AM) Change history (this section will be removed once the document is finalized) Version 4 April 28, 2015 2015-05-07, TK: Accepted all changes, kept change tracking; comments to parts of document non-assigned to me started with “(note TK: ” – discuss the comment and then remove. I added below my figures what should look like a caption, but didn’t use any Word’s “insert caption” command until we confirm which figures are to keep. Continued editing after our web conference. 2015-05-16 version 5, LOO: Accepted all previous changes and merged texts from myself, Kurt and Kendall. 2015-05-26 version 6, BLI: Added text to separation of roles 2015-05-26 version 7 LOO: Accepted all changes. 2015-05-29 version 8 KDD: Added composition section details (more work to do but about right size.) Some minor text edits in the profiles section. No changes or comments outside these two sections. 2015-06-04 version 9 KLH: Added comments and made minor text corrections and clarifications. I’m concerned that this article goes deeper than is going to be useful for most readers without providing at least a basic understanding of the CIM UML model. I think we need to add a short section on the CIM UML with concrete examples and try to include the same concrete examples where ever possible throughout the article. 2015-07-06 version 10 LOO: Notes from 2015-07-06 meeting 2015-07-10 version 11 AMM: Updates by Alan 2015-07-12 version 12 LOO: Updates by Lars-Ola

Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

  • Upload
    vunga

  • View
    217

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

ARTICLE 5: CIM - UNDER THE HOODAuthors; Lars-Ola (LOO), Kurt (KH), Becky (BI), Kendall (KD), Margaret (MG), Tanja (TK), Alan (AM)

Change history (this section will be removed once the document is finalized)Version 4 April 28, 2015

2015-05-07, TK: Accepted all changes, kept change tracking; comments to parts of document non-assigned to me started with “(note TK: ” – discuss the comment and then remove. I added below my figures what should look like a caption, but didn’t use any Word’s “insert caption” command until we confirm which figures are to keep. Continued editing after our web conference.

2015-05-16 version 5, LOO: Accepted all previous changes and merged texts from myself, Kurt and Kendall.

2015-05-26 version 6, BLI: Added text to separation of roles

2015-05-26 version 7 LOO: Accepted all changes.

2015-05-29 version 8 KDD: Added composition section details (more work to do but about right size.) Some minor text edits in the profiles section. No changes or comments outside these two sections.

2015-06-04 version 9 KLH: Added comments and made minor text corrections and clarifications.

I’m concerned that this article goes deeper than is going to be useful for most readers without providing at least a basic understanding of the CIM UML model. I think we need to add a short section on the CIM UML with concrete examples and try to include the same concrete examples where ever possible throughout the article.

2015-07-06 version 10 LOO: Notes from 2015-07-06 meeting

2015-07-10 version 11 AMM: Updates by Alan

2015-07-12 version 12 LOO: Updates by Lars-Ola

2015-07-13 version 13 LOO: Comments added by Chavdar, changes accepted and after that removal of comments.

2015-07-14 version 14 TK: Cleaned up a little bit, accepted some deletions where nothing left to do, corrected a couple of typos, inserted TOC (should help find the “red line”), touched original chapter 2 (now called Setting the stage), added some comments or replied to Chavdar’s (right bar in Word), added two figures in the profile serialisation section.

2015-07-08 version 15 LOO: Went through an accepted deletions I think we agree on. Did adjustments according to comments. Added a little more on the network model evolution since CPSM. Added back a

Page 2: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

hopefully better discussion on node-breaker and bus-branch models and the implications on serialization formats. Shrunk intro to the interop section. Added discussion on node-breaker and bus-branch models in examples section.

Page 3: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

Contents (Delete this section for final document)Change history.............................................................................................................................................1

The big picture.............................................................................................................................................3

Scope statement; LOO.............................................................................................................................3

Setting the stage..........................................................................................................................................3

Interoperability............................................................................................................................................4

Overview.................................................................................................................................................4

Data structuring / schema / semantic model..........................................................................................5

Data partitioning......................................................................................................................................6

The canonical model....................................................................................................................................7

UML and basic rules of CIM canonical model..........................................................................................7

Local non-(IEC)standard extension..........................................................................................................7

CIM profiles for data exchanges..................................................................................................................7

Overview.................................................................................................................................................7

Examples.................................................................................................................................................8

How IEC uses CIM profiling....................................................................................................................11

Payload serialization level.........................................................................................................................13

Messaging and the 61968-100 WS and XSD structures.............................................................................15

Anatomy of an interface........................................................................................................................15

Data composition by receiving systems.....................................................................................................17

Conclusions................................................................................................................................................21

Definitions.................................................................................................................................................21

Further Readings.......................................................................................................................................22

Authors......................................................................................................................................................22

Page 4: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

The big pictureScope statement; LOOPrimarily about (related) exchange governance. Each payload is typically not simply related to itself.

Tailoring local related exchanges

Setting the stageHistorically, the initial CIM canonical model and its first profile (with “profile” meaning a subset of the CIM canonical model), at that time called “CPSM (Common Power System Model) profile the based on requirements defined by NERC”, were created to allow for an EMS intra-application exchange of power system model data, such as typically used in network analysis (state estimation, topology processing, power flow, security analysis), as well as EMS-to-EMS import and export of network model snapshots. This has driven the initial efforts to produce a network model “data format” that contains semantics within the data file itself. The CPSM profile has evolved into an extensive standard supporting many network analysis applications as well as network related data as locations and schematic diagrams, e.g. the ENTSO-E CIM standard for Common Grid Model Exchange Standard (CGMES).

The canonical CIM support both detailed node-breaker and bus-branch models for network analysis applications. The CPSM profile was intended for use in operational systems (EMS) and hence support node-breaker models with detailed substations including breakers, disconnectors, measurements, equipment structures within substations etc. This is different from bus-branch models intended for power flow applications where all substation details has been replaced by power flow busses.

Node-breaker models has many more object types (e.g. Breakers, Disconnectors, Measurements, VoltageLevels etc.) and relations between them than a bus-branch model. Representing these relations in exchange documents can made by references (pointers) or by inclusion of the referenced data at the place of the reference. Documents based on XML Schema can include referenced data by hierarchical nesting, this was the only way to support references in XML Schema when CPSM was created. Hierarchical nesting of references has drawbacks; the same data may be referenced multiple times resulting in duplication, the data is not available and is described in another document. Hence the CIMXML exchange format (IEC 61970-552) was created where all relations are expressed as references.

The base canonical CIM was covering the needs for network analysis studies, but the utility industry wanted more, in particular in the realm of distribution operations, where business processes were less dependent on the network analysis model, but in contrast needed to support data exchanges with

Page 5: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

various enterprise systems. Canonical CIM started growing beyond the network analysis (or functional) view to support data exchanges between the distribution operations (DMS) and outage management systems (OMS), asset record systems such as geographical information systems (GIS), work management systems (WMS), customer management systems (CMS), meter data management systems (MDMS), various distribution network planning applications as well as market management systems and external systems (e.g., enterprise resource planning, etc.). When integrating the above systems, it is important to specify not only the data (canonical data exchanged that those heterogenious systems and their internal data stores will require to function properly in the enterprise environment), but also how the data is exchanged. This is typically described by expected sequences of messages among interacting systems and this kind of data exchange typically relies on some kind of enterprise messaging infrastructure with required qualities of service (e.g., guaranteed delivery, speed of delivery, traffic logging for audit trails, security, etc.) – especially important for the case of business to business (B2B) exchanges. It is also usual practice to provide a standard envelope for the payloads that can then be exchanged by virtually any transport. This is what IEC 61968-100 does.

Nowadays, we see the tendency of transmission utilities being in need to integrate their enterprise systems based on CIM and they are taking advantage of the standard canonical CIM model and experience from the distribution world. Inverse is also true, i.e., larger distribution utilities see advantage in leveraging distribution network models within many of their business processes and they are actually taking advantage of the canonical CIM model and experience from the transmission world.

The following sections will show how the set of standards around CIM cover a big number of needs for data exchanges in electrical utilities and markets, from networks modelling for power flow kind of studies, to dynamics, to operations and planning, to smart metering, to unique identification of real world entities, to integration with various enterprise systems – to name a few.During the formation of energy markets within the North American region, the need to standardize market exchanges became apparent. At this time, a committee of Regional Transmission Owners was formed to address the definition of the energy market supplemental model data and market communications for the North American markets. These use cases were developed as the market operation extensions which are now contained within CIM.

The European Network of Transmission System Operators for Electricity (ENTSO-E) was being formed in 2009. Besides all the tasks defined in the European legislation ENTSO-E supported the integration of member Transmission System Operator’s (TSO) business requirements and use cases into the CIM.

InteroperabilityOverviewThe CIM standard was already from its early beginning in 1994 intended to enable interoperability. Originally it was interoperability between applications that has been widened to interoperability between systems. Another widening was from applications for network analysis to work processes within a utility and energy markets as mentioned above. The network analysis has also grown from power flow type of applications to short circuit analysis, dynamics analysis etc. Yet another widening is support for network display layout, geographical locations, assets information, asset health etc.

Page 6: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

This widening is still ongoing and extensions are still added. In EU the consequence of the common energy market, increased renewable production and reduction of CO2 emissions resulted in accelerated use of CIM. When ENTSO-E started to use the CIM in its Common Grid Model Exchange Standard (CGMES), needs to further extend the CIM were discovered.

The central architectural idea behind CIM is to describe data semantics such that exchanged data objects can be traced back to the canonical CIM semantics. CIM supports this by is its capability to describe relations between objects, e.g.

Equipment in the functional model (PowerSystemResurce CIM class) relate to physical equipment in the asset model (Asset CIM class). This makes it possible to answer a question like; what is the serial number and actual short circuit current (asset model) of the breaker I am currently using in position Q1 (functional model) in my substation?

Registered resources in the market model relate to generating units in the functional model. This is useful when a production schedule from the market is validated with Congestion Forecast (e.g. in intra-day CF / day-ahead CF) or used in a Security Constrained Unit Commitment (SCUC).

These are just a few examples of many relations between the different parts of the CIM. Relations like this enable cross navigation between data exchanged according to different profiles. Two use cases building on the above examples are

A Supervisory Control and Data Acquisition (SCADA) system typically records how many times a breaker operates. Knowing which breaker in the asset registry is used in the circuit monitored by SCADA can then be used to tell the asset registry how many times the breaker has been operated. This is needed to determine breaker wear.

A market system typically deals with net production from registered units at plant level. Knowing what functional generating units corresponds to a registered unit makes it possible to map registered unit net production schedules on functional unit gross production also considering outages and de-ratings. This mapping is needed for Congestion Forecast (CF) and Security Constrained Unit Commitment (SCUC).

Relations between objects require a concise global identification mechanism such that objects are uniquely referenced and not mixed with each other. Human generated names have the drawback that different objects are likely to have the same name, e.g. the substation name “Airport” may exist in many places. Additionally names may need to change over time, but unique identification must be persistent. Hierarchical naming is a usual way to get more precision as with postal addresses, internet addresses etc. But naming schemes like this require authority support and administration for its maintenance. In CIM, the Master Resource ID (mRID) identification scheme is recommended to be used for object identification, for more details see below.

When extending CIM it is important to have use cases such as those mentioned above in mind such that the relations are added to support navigation across profiles. The relations like this need to be present in the CIM canonical model to facilitate cross navigation between profiles. Hence a good modelling practice is to make sure that data shared by different profiles are described in the canonical CIM. The description shall also be precise with clear semantics to avoid that the same data item is used to mean different things in different profiles. Unclear description of a CIM class, attribute or relation has resulted in investigations to figure out the semantics over the past years. So spending time in creating good

Page 7: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

descriptions make it easier for future users to use the model correctly and avoid duplicate use for different things. Another benefit by being specific is that data that may look the same actually are different when reading the description for the data.

As mentioned above CIM has grown considerably since its creation. This has resulted in a reputation that CIM is continuously changing which is actually true with respect to all extensions. The early parts however have been stable, in particular in recent years. When a new model is added to the CIM it hasn’t typically been implemented yet. As implementations appear issues are normally discovered and corrections are needed. Hence newer parts of the CIM are initially less stable but as interoperability tests aiming at vetting of CIM standards are conducted and usage increases, the model stabilizes. As the usage of CIM has increased the standardization work has also become much more careful in making extensions such that the impact on existing implementations is minimized.

Data structuring / schema / semantic modelThe CIM canonical model (see The canonical model) includes a very large number of classes and each class has associations describing relationships with other classes. Most classes also have attributes describing characteristics of the class. Any given work flow or data exchange will use only a fraction of the classes, associations and attributes defined in the CIM. Profiles (see CIM profiles for data exchanges) are defined to specify the specific subset of classes, associations and attributes from the CIM that are used for a particular data exchange.

Because the information included in a profile is based on the CIM canonical model the meaning of the information is clearly understood. For instance, any profile that includes the class and attribute defining the resistance of an AC transmission line (attribute “r” of the “ACLineSegment” class) will have the same understanding of the data being exchanged.

The CIM UML model uses a type system that also helps to ensure a clear understanding of the attributes. CIM data types are defined for common electrical quantities such as “ActivePower,” “AngleRadians,” “Resistance,” and “Susceptance.” For instance, attribute “r” of the “ACLineSegment” class uses the CIM data type “Resistance”.

In most cases a data exchange will need to reference data objects previously exchanged. For instance the results of a power flow will reference the individual pieces of equipment from a network model that was previously exchanged. When changes are made to a network model an incremental update can be exchanged that will reference the objects that have been added, modified or deleted.

Data objects that may need to be referenced have to be kept persistent by the receiver of the data and they must have unique, persistent identification. In CIM the class IdentifiedObject has been defined specifically as a superclass for any class that needs to be persistent after it is initially exchanged. The master resource identifier attribute, “mRID,” of IdentifiedObject is included in the CIM to provide a common method for persistent, unique identification. When used in a data exchange the “mRID” is required to be unique within the context of the exchange. Global uniqueness is achieved by using a Universally Unique Identifiers (UUIDs), which is strongly recommended, but not required.

In an ideal data exchange UUIDs would be used as the mRIDs to uniquely identify all objects, but this cannot always be achieved when working with existing applications that already have other established

Page 8: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

methods of unique identification. In this case CIM naming attributes and classes such as the “name” attribute on “IdentifiedObject” or the alternate name classes “Name,” “NameType,” and “NameTypeAuthority” can be leveraged.

Data partitioning Network model data documents representing large interconnected power networks may become large. This is dealt with by partitioning documents in two ways

Documents with different types of data described by different CIM Profiles. Documents with parts of instance data from different Model Authorities.

As described in the “Data structuring” section CIM data is divided into profiles that enable exchange of non-overlapping data facilitating a modular division of data in sets that can be exchanged when needed. As a network part of a power system is typically managed by an authority, e.g. an organization being responsible for or operating the network part, the CIM concept of a Model Authority and Model Authority Set has been created. In an interconnected power system with multiple responsible organizations the Model Authority Sets are defined by the boundaries between them. Both the network parts and the boundaries between them are Model Authority Sets and their data can be exchanged as separate sets.

The canonical modelUML and basic rules of CIM canonical model

With some rationale for things like unique class names, package changes agility

Non-cyclic dependencies, meaning of dependencies

Make reference to the existing guide, make that guide an IEC TR.

Local non-(IEC) standard extension

CIM profiles for data exchangesOverviewIn this section we take a closer look at CIM profiles, how they are created and some of the different capabilities and uses of profiles. Profiles describe the payload part of exchanges as might be exchanged in files or as the payload section of message based exchanges described in 61968-100. The reason for profiling is to naturally impart a degree of consistency and uniformity that enables development of individual implementations but additionally and most importantly enhances and streamlines system data integration activities.

CIM profiles are descriptions of a restricted part of the overarching CIM canonical model which are relevant to a particular implementation such as an exchange. Profiles and the process of profiling work in the domain of schema. The end result of profiling is normally a concrete schema governing an implementation such as an XSD or RDFS (RDF schema) that IT professionals can use to implement, validate, or otherwise assist in the actual exchange of instance data supporting a business process.

Page 9: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

FIGURE 1 PROFILE RELATIONSHIPS

The relationships of canonical model, profile, schema, and instance data are shown in Figure 1. We say a particular profile “is based on” the canonical model from which it is a restriction. Each element of the profile in turn “is based on” a specific part of the canonical model and hence derives a semantic.

Several CIM specific tools, such as the open source CIMTool (www.CIMTool.org), are available to help define the profile and to generate standard schema artifacts. The IEC 62631-100 “Naming and Design Rules” standard defines how profiles should map into XSD and similarly IEC 61970-501 describes how RDFS (RDF Schema) is produced from a profile definition. IT professionals can then leverage the standard IT schema artefacts in implementations that manage instance data within business processes.

ExamplesIn its simplest form a profile is a selection of the specific parts of interest from the complete canonical model.

Page 10: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

FIGURE 2 SUBSET OF CIM CANONICAL MODEL

In Figure 2, we have a subset of the complete CIM Canonical model looking at a small section of the UML covering the functional and metering components. Here the model inheritance tree is shown along with all of the attributes1. The attributes here cover a number of different applications of the data that are defined as multiple profiles.

The connectivity information for node-breaker and bus-branch models are shown in Figure 2 to the upper right. Each ConductingEquipment has a number of Terminals corresponding to the number physical connection points at the ConductingEquipment. In a node-breaker model the connections are described by ConnectivityNodes and the Terminals refer to the ConnectivityNodes where they are connected. As closed Breakers or Disconnectors have zero impedance a network model builder (also called topology processor) remove and replace them with a power flow buses connecting all injections and non-zero impedance elements. The TopologicalNode represent the power flow busses in canonical CIM and Terminal also has a reference to TopologicalNode.

1 The EndDevice and Terminal inheritance trees have been reduced to improve clarity, but all attributes have been retained

Page 11: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

FIGURE 3 EXAMPLE COMPUTATION OF A POWER FLOW BUS

Figure 3 show how the Breakers/Disconnectors BR3, DC2 and BR1 as well as ConnectivityNodes CN6, CN5, CN4 and CN3 are replaced by the power flow bus TopologicalNode TPx. TopologicalNode TPx connect the equipment BusbarSection BB1 (where there is a voltage Measurement), PowerTransformer T1 and ACLineSegment Cable1.

Node-breaker and bus-branch models can be easily combined by converting bus-branch ToplogicalNodes into ConnectivityNodes and then merging the two. The merging is simple if the merged models have a common Model Authority Set boundary.

FIGURE 4 SUBSET FOR BUS-BRANCH PROFILE

In Figure 3 we can see a subset of this canonical model in a small Bus-Branch profile. Four of the classes from the original canonical model have been used with a subset of attributes from each. The

Page 12: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

inheritance has been collapsed and the mRID and name attribute from IdentifiedObject have been retained in the four classes. EnergyConsumer retains only the p and q attributes from the canonical model classFigure 7 IEC profiling practices and standards and all other attributes have been omitted from the profile. The ACLineSegment class retains only the basic attributes required for simple power flow with the zero-sequence attributes from the canonical model discarded for this profile.

At the Terminal level we retain the link to TopologicalNode as this is the CIM class for representing a computed bus in a bus-branch representation of a model. The ConnectivityNode association is removed as this us used for node-switch models and so is not required for our bus-branch profile. All association cardinalities have been tightened so they are no longer optional. For some associations the minimum and maximum cardinalities are the same, so the EnergyConsumer must have one Terminal association while the ACLineSegment must now have two. Other have a restricted minimum and unrestricted maximum, so the TopologicalNode must have at least 1 Terminal. The direction of the association is also defined at the profile so an implementation knows which side of the association should be serialised.

FIGURE 5 SUBSET FOR NODE-SWITCH PROFILE

A second profile is shown in Figure 4 that is similar to that of the Bus-Branch profile, re-using 3 of the 4 classes with the addition of the Switch and ConnectivityNode. While the Terminal and EnergyConsumer class attributes are the same, the ACLineSegment also includes the zero-sequence attributes, and the Switch class from the canonical model is included with a subset of its attributes. In this profile the Terminal-ConnectivityNode association is used rather than the Terminal-TopologicalNode, requiring the inclusion of the ConnectivityNode class and the corresponding relationship to Terminal and the removal of the TopologicalNode.

Page 13: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

FIGURE 6 END DEVICE PROFILE EXAMPLE

Moving outside of the functional model exchange, a simple End Device Profile example is shown in Figure 5. This uses the EndDevice and UsagePoint classes with a small subset of their attributes. The EnergyConsumer class is re-used with some additional attributes added from the canonical model. The general UsagePoint-Equipments relationship has been restricted to only apply to EnergyConsumer (a subclass of Equipment) and as with the other profiles, the cardinalities have all been restricted and the direction defined.

How IEC uses CIM profilingThe IEC has standardized certain profiles using selected technologies and different options within the flexibility of the profiling process. These techniques are available for any organization using CIM standards and are often employed where specific business processes need exchange implementations that have not been standardized and may include local CIM canonical model extensions as discussed in the CIM modelling guide.

Page 14: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

FIGURE 7 IEC PROFILING PRACTICES AND STANDARDS

TODO: If document numbers listed a section that shortly describe each document is required.

A box section for those that want the details how to find CIM documents.

Figure 7 shows the relevant IEC and W3C standards involved in profiling. Note that profiles can be based on any part of the canonical model from any working group and, in the case of project implementations requiring it, local CIM extensions.

Of note is the introduction of a contextual profile (IEC 62325-450) from which further profiles are derived. This contextual profile is useful for restricting the canonical model in a common manner for a set of profiles as is required for example in the European market exchanges. The profiling techniques

Page 15: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

are the same at both levels but only the final IEC 62325-45x series of profiles produce payload schema. For the European market messages, the IEC 62325-450 performs more complex restrictions and enables the individual IEC 62325-45x profiles to be simple profile selections and XSD serialization specifications.

Profiles for network analysis models and other closely related data are described in the IEC 61970-4xx profiles and are typically serialized using RDF technology as described in IEC 61970-501 and IEC 61970-552. Profiles for Metering, Assets, Work Management, and similar areas covered by IEC TC57 WG14 typically use XSD based messages and are described in IEC 61968-x standards. By design, the CIM profiling practice allows the same information to be exchanged in multiple technologies, though in practice this does not typically occur. It is common for profiles to make references to CIM data exchanged in different technologies, so the best technology choice can be made for each business exchange.

Payload serialization levelPrevious sections have addressed the upper half of Figure 7 , namely canonical CIM and profile derivation from it by means of restrictions. This section addresses the rest, i.e., syntactic aspects of profiles and considerations to take into account when selecting a syntax.

At present, standard CIM profiles get translated into one of two distinct flavours, both based on W3C XML syntax, as graphically illustrated in Figure 8Error: Reference source not found, for RDF Schema or RDFS (a) and for XML Schema or XSD (b).

FIGURE 8 – SAMPLE EXTRACT FROM (A) RDFS-BASED AND (B) XSD-BASED PROFILE.

The very first CIM payload type was defined in early 2000’s (or late 1990?) using W3C RDF Schema (RDFS) and the payload instance data was thus serialised as a special dialect of XML, called RDF. The RDFS representation of a profile has been defined in IEC 61970-501, and the instance data format, or the payload serialisation format compliant to that schema has been called CIMXML and defined in IEC 61970-552. The subset of RDFS used for some CIM profiles still today has been defined in such a way that the instance data (expressed in RDF, see Figure 9 (a) for an illustration) looks very flat and importantly, leverages the file-scope uniqueness of data as defined by that syntax – namely, through so called RDF identifiers; in the profile(Figure 8Error: Reference source not found a), this corresponds to the attribute ‘ref’ (blue circle) and in the data file (Figure 9 a) to the value in rdf:ID. To ensure that there is no nesting at all, at the previous step (profile definition), the user is supposed to apply shallow relationships (ref’s) to objects, which will preserve the flatness of the data.

Page 16: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

RDFS based profiles are widely used for bulk network data model exchanges, for either full models or the increments thereof. The syntax in itself is simple, and the language allows to define ontologies and reason on them. On the challenging side, the tooling support for validation, editing and parsing is somewhat limited and may have a steep learning curve.

With the need of (initially: distibution) utility organisations to exchange data among heterogenious systems and often without the need for network models, the second flavour of syntax for payload types emerged as a natural choice well suited for enterprise integration: “vanilla” XML, that validates against the W3C XML Schema (also referred to as XSD). The translation of CIM profiles into the XSD syntax is defined in IEC 62361-100 and is widely used for standard as well as for custom profiles. This syntax is the mainstream integration technology with miriad of tools supporting its development, well understood by both application developers and integrators, and is an integral part of web-enabled technologies. The profiles defined with the XSD syntax in mind have no limitation in structure and are indeed often reflecting the “navigation path” through relationships from the canonical CIM model; a graphical example is given in Figure 8 (b), with the red rectangle. It is possible to use the “shallow” references as in RDFS based profiles (blue circle), however, there is no XSD native counterpart to RDF identifiers - all the more that payloads may not use CIM mRID for identification, but rather the battery of name-related classes, that have been added with base CIM15 to support object registries. XSD syntax also allows multiple profiles for a single type (e.g., a street address with only street name, street number and postal code; and a street address with all the available descriptors); defined locally or globally. Finally, the work is in progress to support modularity of payload types by enabling the inclusion of a “profile snippet” into multiple profiles. A sample instance data that may comply to an XSD-based profile is shown in Figure 9 (b).

FIGURE 9 – SAMPLE (A) RDF AND (B) XML SYNTAX FOR CIM-BASED DATA.

Due to its widespread usage in the industry, majority of new XSD based profiles of standard CIM are defined using XSD syntax, in particular those that support processes outside network model exchanges. The syntax is equally well suited for configuration (“static” / bulk) and for operation (“dynamic” / on-line) data exchanges, as illustrated with e.g., metering profiles from IEC 61968-9. On the challenging side, there is at present no native mechanism for referencing objects used, and referencing may be exclusively through dedicated naming classes.

Note that in theory, a profile defined for use with RDFS syntax can also be expressed with XSD syntax; the other way round is possible only in a special case (where the profile gets defined as if it were for RDFS syntax, i.e., flat, with exclusive use of references).

Page 17: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

Messaging and the 61968-100 WS and XSD structuresTo come up to a running software, the first set of objectives is to specify interfaces:

– what is the content (or payload) of data exchanges among actors?

– how is it modelled (in the canonical information model) and how is it translated into an implementation artefact (i.e., some kind of data schema)?

– by which transport it gets exchanged?

while satisfying the requirements, including those related to interoperability. Once we have answered these questions and started specifying concrete data exchange payloads, all actors concerned with any given payload can progress in parallel and independently of each other by implementing and testing their local applications as long as everybody programs to the agreed interfaces.

To allow for this level of flexibility, it is best to adopt for interface specification those technologies that are independent of hardware platform, operating system or programming language. This is the approach also recommended and followed by utility enterprise integration standards such as IEC 61968. In the section “Anatomy of an interface”, we will dissect a message derived from one such sample interface.

Anatomy of an interfaceWe will analyze a message compliant with an interface that has properties discussed above. Left side of Figure 10 shows the general approach to defining communication interfaces by using encapsulation or nesting. Those familiar with the OSI reference model for communication protocols will recognize the idea: The object of exchange (payload) is nested deepest and wrapped into some kind of envelope. That envelope then becomes the object of exchange (payload) one level up and is again wrapped into another kind of envelope. We have denoted three levels in our example:

– L1, the first level, that we will call domain interface level,

– L2, the second level, that we will call message interface level, and,

– L3, the third level, that we will refer to as transport interface level.

In theory, one could go further up and wrap content of L3 into some fourth level, L4, but for our purposes, these three levels are sufficient. The fact that we can clearly separate them means that we can independently develop and test “real” software at each level, while “mocking” the functionality of the other levels. This is an important aspect of any project execution or implementation effort.

Page 18: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

FIGURE 10 – SAMPLE SOAP MESSAGE

Let us now look at the right hand side of Figure xyz-SOAP. This shows a set of very concrete technology choices.

– The domain interface level L1 reflects the payload whose type is called EndDeviceControls and it has been derived from the canonical distribution CIM (defined in IEC 61968-9 and IEC 61968-11, respectively), and that is compliant with the W3C XML Schema format. That specific domain payload allows one, for instance, to send control actions to end devices (such as smart meters) by providing the identity of the end device and the program level for demand response.

– The message interface level L2 reflects the message envelope expressed also in W3C XML Schema format as defined in IEC 61968-100. This is the level where we need to provide extra information that is required by the software that handles message exchanges on a bus and that does not need to “unpack” the payload, but just to route it to the correct receiving applications. Typical information that must be specified are the verb and the noun – telling what needs to be done (verb) with the content of the payload (noun).

– Finally, the transport interface level L3 reflects the standard SOAP message (often meant when one says Web Service), with the SOAP header and the whole of level L2 encapsulated in the SOAP message body.

There may be cases where a single actor needs to exchange some of the messages within a single organization and in a simplified way, without need for platform independence and overhead of e.g. Web Service (and its SOAP implementation). To support this kind of exchange, we could simply skip the transport interface level L3 and pass around the message envelope of level L2 with its containing

Page 19: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

payload in level L1 by using e.g. a JMS broker (in a standard way, as in IEC 61968-100) or some other means for message exchange.

The example above has used the payload (L1) in W3C XML format. Given the structure of the envelope (L2), it allows embedding domain payloads in literally any format, including W3C RDF format.

Alternately, for certain data exchange scenarios, simple file exchange may be sufficient in which case the domain payload (L1) would simply be the file to exchange; in this case, some non-standard pre-configuration needs to take place ( e.g. to state the URI of the file on a file system).

Data composition by receiving systemsThe main objective of CIM is to support utility business processes and these normally require the assembly or composition of data from a number of sources. These sources may use different exchange technologies, different (but related) schema or structure, and different content which is often referencing other content.

CIM based integration enables systems to more readily compose and utilize data originating from multiple sources and potentially with different (but related) structure and content.

Page 20: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

FIGURE 11 DATA PARTITIONING BY INSTANCE AND BY SCHEMA

As shown in Figure 4 there are two main ways CIM data is partitioned.

1) Model Authority Sets partition by instance – e.g. by transmission operators 2) Profiles partition by schema – e.g. by network model

Data may be exchanged in different technologies. For example, a network model exchanged using RDF XML technology and network outage data exchanged using XSD based XML. We expect the semantics and object identities to be valid across technologies such that the outages could relate to the network

Page 21: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

model. Additionally we may exchange both full models and incremental changes to be applied to full model descriptions.

By considering all exchanged data to be conforming to a common semantic model, we can describe how data from different technologies, different sources, and different profiles will compose within a receiving system. We focus upon the receiver here, but of course data providers must adhere to standards in order for the receiver to benefit.

FIGURE 12 BUSINESS PROCESS COMPOSING DATA

To some, the composition of CIM data is obvious, but for clarity and in preparation for describing more complex situations, we go through how CIM objects compose.

Page 22: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

We describe a generalized “receiver model context” (RMC) in which CIM data is to be composed within the business process. This context defines each business object to be uniquely defined by an MRID. Thus references to business objects within that context can be implemented using MRID’s. IEC does not standardize internals of business process implementations, but the interface standards are designed such that a business process can implement a consistent composed model of the various input standards.

FIGURE 13 OBJECT LEVEL COMPOSITION

Page 23: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

shows an example of how a receiver with CIM data can compose new data.

<< Still some work in this section. Break double figures apart. Add short conclusion. Intend to be only slightly longer, or about the same size when delete this paragraph. Remove “Resource” from schema/instance partitioning diagram. Maybe combine the object example to show both references and attributes composition in same diagram.>>

Conclusions

Definitions

(1) Canonical CIM:

This is an abstract model of domain or data exchange (our CIM UML).

(2) Profile:

This is a restriction of canonical CIM, a small subset of it as required for a specific interface for external data exchanges (although people may take the same approach for internal system interfaces). We use a profiling tool to reduce canonical CIM to the desired content, and the tool produces for us a schema that will govern the format of the instance data to be exchanged.

class BMRID=2

payload 1

payload 2

RMC

class AMRID=1

class BMRID=2

Proxy class A

MRID=1

class AMRID=1

unordered

Page 24: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

(3) Payload:

This is an instance of Profile according to a given syntax. We use XML (complying with RDFS or XSD); in future we may want to use something else (e.g. JSON format); others may already be using something else based on CIM, or CIM extensions or not related to CIM at all. (note TK: this is L1 from Figure xyz-SOAP)

(4) Message:

This is an instance of message envelope, e.g. Message.xsd (61968-100), that includes among others one or more Payloads (3). It also contains the full context of data exchange (verb, noun, etc.) to let the receiver know what to do with the received payload. (note TK: this is L2 from Figure xyz-SOAP)

(5) Dataset:

TBD

(6) Models:

Model – Data that describe an existing entity or thing.

Electrical network model – A model or data describing an electrical network.

Base model – An electrical network model used as part of a case.

As built model – an electrical network model that corresponds to a constructed network

Case – complete set of inputs to a network analysis study case.

Full model – A complete description of an electrical network model.

Difference model or Incremental model: TODO add description

Further Readings– up to 6 items (note TK: this leaves place for 4 more; should we add reference to actual series: 61968, 61970 and 62325? If so, one more left.)

CIM modelling guide

CIM Primer

Authors– one line per author

Page 25: Change history (this section will be removed once the ...cimug.ucaiug.org/Projects/IEEEmagCIM/Shared Documen…  · Web viewNode-breaker models has many more object types (e.g. Breakers,

Tatjana Kostic is with ABB Corporate Research, Baden-Daettwil, Switzerland.