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

Change historyVersion 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 coment 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-05-26 version 7 LOO: Accepted all changes.

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

Tailoring local related exchanges

Separation of roles (might be intro, roadmap for reader); MG, TKMargaret had a good discussion of how CAISO has made this an important concern. Maybe we can get a CAISO statement on the topic.

(note TK: Margaret & all, I’ve just put some thoughts in, feel free to remove/adapt/whatever; don’t know whether to refer to EPRI CCAPI project?)

Historicaly, the initial CIM canonical model and its first profile (at that time called “CIMXML NERC profile”) were created to allow for an EMS intra-application exchange of power system model data, such as typically used in network analysis applications (state estimation, topology processing, power flow, security analysis), as well as EMS-to-EMS import and export of network model snapshots. Very naturally for this kind of usage, domain experts are expecting to work with “input and output data files”. This has driven the initial efforts to produce a network model “data format” that contains semantics within the data file itself (as a replacement to counting columns up to 72 characters in a text data file of some format).

…

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 are (were?) less dependent on the network analysis model, but in contrast needed to support data exchanges with various enterprise systems. Canonical CIM started growing beyond the “pure network analysis” 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 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 “what” (canonical data exchanged that those heterogenious systems and their internal data stores will require to function properly in the enterprise environment), but also the “how” side of data exchange. That “how” side is normally not file-based, but rather relies on an 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 some kind of envelope for the payloads that can then be exchanged by virtually any transport. This is what IEC 61968-100 does.

(note TK: Margaret, here to hook the story of 61968-100? See also section “Messaging and the 61968-100 WS and XSD structures”, you may want to pull some content of it up here.)

(note BI: Adding in text here to cover the markets for US and EU. It will also cover CAISO’s approach and concerns in developing market interfaces and the separation of roles.)

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

communuications for the North American markets. These use cases were developed as the market operation extensions which are now contained within CIM.

During the same time, the European Network of Transmission System Operators for Electricity (ENTSO-E) was being formed to address the need for a European wide harmonization of network access and communication. ENTSO-E supported the integration of member Transmission System Operator’s (TSO) business requirements and use cases into the CIM. The additional use cases from ENTSO-E have been developed and are included within the CIM market management.

(note TK: When done, remove the bullets below)

Focus of domain expertsSemantics

Requirements for persistence and QoS

Management of datasets, frames, exchange sequences

Sensible minimal exchanges

Focus of IT experts, more related to 61968-100, the story behind the 100

Files, middleware, security

Efficiency, persistence, QoS delivery

Technology

Data structuring / schema / semantic model; KH

The CIM 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 are defined to define 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 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.

Non-schema data partitioning (Modeling Authority Sets concepts); LOO(note TK: Be explicit in limiting the scope here to the big TSOs and not scare away the small DSOs who need not bother with this.)

(note TK: By the way: what is “non-schema data”? Do you mean horizontal partitioning, also known as sharding? If so, use an analogy, this may help others (who don’t know about MAS) understand the topic).

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. But in large interconnected power systems models describing the complete power system may become very large. As a part of a power system is typically managed by an authority, e.g. an organization being responsible for or operating the part, the CIM concept of a 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. The Model Authority Set concept is another way to modularize power system data and enable exchange of power system data that link together through shared boundary definitions.

The canonical model , keep small; MGUML 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(note TK: Some of this is also available in the model management guide; here it would be good to cover “watch for this” aspects learnt from experience.)

CIM exchange Profiles – deep dive ; KD

CIM exchange Profiles – deep diveOverview

In this section we take a closer look at CIM profiles, hnow 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.

FIGURE 1 PROFILE RELATIONHIPS 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 elementpart 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 model define the profile andcreating using the “Is Based On” relationship 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.

Profiling in detail.In its simplest form a profile is a selection of the specific parts of interest from the vastsprawling canonical model.

FIGURE 2 SIMPLE PROFILE BY SELECTION

In Figure 2, all the individual classes of the profiles have “Is Based On” relationships to those of the canonical CIM. Consistent class naming makes these class relationships intuitive. The individual properties are based on canonical properties having consistent names.

In Profile 1, the attributes “property1” and “property3” of class A are selected into the profile. The attribute “property2” is not selected and will not be part of an exchange conforming to Profile 1. Class B is also included with an association property referencing class A and will use the role name “A”. Note the profile describes the reverse multiplicity, though depending on the exchange technology, its multiplicity may not be automatically validated.

For simplicity, Figure 2 does not show details of datatypes (e.g. Float, String, Resistance, …), nor is inheritance used. The IEC CIM standards address all these details.

More complex “Is Based On” relationships are possible in the event special considerations are required. A profile may flatten inheritance hierarchies, further restrict multiplicities of properties, or restrict the range of datatypes (e.g. require a String to be less than 32 characters). These restrictions can be applied individually to properties by modifying the multiplicity or assigning a restricted datatype. Even more complex restrictions are possible via creating multiple profile classes or associations based on one canonical class. IEC 62325-450 describes these advanced restriction capabilities, but using the simplest form of restrictions the business case requires is recommended.

Selection of attribute properties is very fairly straight forward with possible complication of requiring a with the possibility that a restricted datatype may be employed where required, for example where certain string attributes are to be restricted to a specified length.

Association properties may be selected such that the association is wholly contained within the profile as in Profile 1 of Figure 2, or as in Profile 2, where the association spans profiles via an association with class B (via role B). The profile also normally defines the direction of the association for serialization purposes, though the semantics of both roles of the canonical model must be respected. Note that even for Profile 1, in some cases the conforming instance data may reference objects contained in other payloads or datasets. In the case of XSD profiles relationships can be expressed in terms of containment which would requires the containing object to also be exchanged within the same payload.

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 [need reference???].

FIGURE 3 IEC PROFILING PRACTICES AND STANDARDS

Figure 3 shows the relevantprimary IEC and W3C standards involved in profilingserialization processes. Note that profiles can 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 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 simpler 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 tend to 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 the each business purposeexchange.

Payload Serialization level (and special features); TK, BI(note TK: Below is all new text, I hope it all sounds impartial – with the good, bad for all. There is certainly space for improvements !)

Previous sections have addressed the upper half of the Figure xyzProfiling, 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; (note TK: here to refer to the picture and text below).

(note TK: Becky, if you could it would be great to pull out a snippet of e.g. CoreEquipment or Topology profile = any one used by WG13 with RDF in mind; and then of e.g. EndDeviceControls from 61968-9 metering. We all need to see whether to use text (might not be readable if we’re to put reasonable amount of it on a page) or XSD visualisation by XMLSpy or anything else that will show nesting / flattness).

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) looks very flat and importantly, leverages the file-scope uniqueness of data as defined by that syntax – namely, through so called RDF identifiers. To ensure that there is no nesting at all, at the previous step (profile definition), the user is supposed to apply shallow relationships (like pointers) to objects, which will preserve the flattness of the data (note TK: here to refer to something from the picture).

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 negative 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. It is possible to use the “shallow” references as in RDFS based profiles, 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 to have 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.

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.

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

(note TK: When done, remove the three sets of bullets below)

Xsd and conforming XMLNDR details

References as hierarchical (nested) XSD.

References without MRID

Generalized references.

Rdf (RDFS, OWL)RDF ID and MRID

Incremental

Open to other serialization forms or technologies CIM/E, JSON, Thrift, proprietary binary, EXI … Keep this section short but the concept needs to be covered.

Interoperability; LOO, TK, MG

The 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 analytics to work flows within a utility and energy markets. The network analytics 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.

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 CIM semantics. An important feature of CIM is its capability to describe relation between data objects, e.g.

Equipment in the functional model (PowerSystemResurces) relate to physical equipment in the asset model. This make it possible to answer a question like; what is the serial number and actual short circuit current of the breaker I am currently using in position Q1 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 IDCF/DACF) 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 enables cross navigation between data exchanged according to different profiles. Two use cases building on the above examples are

A SCADA typically record 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 deal with net production from registered units at plant level. Knowing what physical generating units corresponds to a registered unit makes it possible to map registered unit net production schedules on physical unit gross production also considering outages and de-ratings. This mapping is needed for Congestion Forecast and Security Constrained Unit Commitment.

Relations between objects require a concise global identification mechanism such that objects are uniquely referenced and not mixed with each other. Human generated names has the drawback that different objects are likely to have the same name, e.g. the substation name “Airport” may exist in many places. Hierarchical naming is a way get a more preciseness as with location or internet addresses. But naming schemes like this require authority support and administration for its maintenance. For CIM it has been decided to use a Master Resource ID (mRID) to identify objects. The mRID is intended to support computer identification of objects and processing of relations. The CIM standard strongly advice the use of UUIDs as mRID. A UUID is a machine generated 128 bit value that is globally unique with a very high probability. The mRID cannot replace human readable names and CIM support multiple human readable names for an object.

When extending CIM it is important to have use cases as the 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 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 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 my look the same actually are different when reading the description for the data.

As mentioned above CIM has growing 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 has been stable, in particular during the later 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 are made and usage increase the model stabilize. As the usage of CIM increase standardization work has also become much more careful in making extensions such that impact on existing implementations are minimized.

Messaging and the 61968-100 WS and XSD structures; TK, MG, BI(note TK: Margaret, Becky and all, I used as a starter my own text from a chapter that I contributed with colleagues, to the in-preparation ISTE-Wiley book on demand response; please feel free to modify / shorten / whatever. Before the text below, in the book chapter, I talked about enterprise and B2B integration atop a semantically aware enterprise messaging infrastructure, a la our 61968-1 IRM. The intro text down to the “Anatomy of an interface” would maybe better fit somewhere in the introduction, maybe the part on 61968-100 where we talk about both domain and integration concepts, then refer to subsequent sections?)

To 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 others 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 analyse a message compliant with an interface that has properties discussed above. Left side of Figure xyz-SOAP shows the general approach to defining communication interfaces by using encapsulation or nesting. Those familiar with the OSI reference model for communication protocols will recognise 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.

Figure xyz-SOAP – 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 organisation 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 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 to embed 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 (to e.g. state the URI of the file on a file system).

(note TK: Do we really want to address here again incremental changes? This would mean describing 61968-100 verbs ‘execute’ and ‘executed’, and if so, one would have to describe all the other verbs. We can, of course do that, but do we have enough space?

(note TK: When done, remove the two bullets below)

(note TK: When settled on content, think of adapting the title of this whole section to something more catchy and less technical)

Use of payload profiles, either RDF or XSD

Incremental changes

Data composition by receiving systems; KD, KH, MGThe 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.

FIGURE 4 DATA PARTITIONING BY INSTANCE AND BY SCHEMA

As shown in 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

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, 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 5 BUSINESS PROCESS COMPOSING DATA

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

We describe a generalized “receiver model context” 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 6 OBJECT LEVEL COMPOSITION

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.>> By MAS or by profile, makes no difference

Cross technology integration

Receiver data composition details

Object composition diagrams

Incremental change to existing data.

Composition with previously received information

Abbreviations (note TK: do we need this?)DMS –

EMS –

more…

Definitions

Figure xyzProfiling – Profiling at a glance

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

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

Power network model – A model or data describing a power network.

Base model – A power network model used as part of a case.

As built model – a power network model that correspond a constructed power network

Case – complete set of inputs to an analytical study case.

Full model – A complete description of a power network model.

Difference model or Incremental model:

A description of a power network model relative another full model. Assume X and Y are full models and Δ is a difference or incremental model. Then the following is true

A new full Y model can be created from an existing full model X and a difference model Δ, i.e. Y=X+Δ

A new full model Y just created from an existing full model X and a difference model Δ can be used to recreate the existing full model X by subtracting the difference model Δ, i.e. X=Y-Δ

Any two full models X and Y can be used to create difference model such that one of the full models can be recreated from the other by adding the created difference model, i.e. if Δ1=X-Y then X=Y+Δ1 and if Δ2=Y-X then Y=X+Δ2 and Δ1=- Δ2.

Further Readings– up to 6 items

(note TK: ensure to include CIM model management guidelines and CIM primer - thise leaves place for 4 more)

Authors– one line per author

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