Research on CIM Update and Extension Based on Ontology

The problem of model difference exists in the application integration based on CIM. Difference caused by diverse versions will lead to semantic conflict and inconsistency, which make data sharing impossible. To solve this problem, we need to perform research on CIM update and extension. Therefore we propose a CIM update and extension research method based on ontology. In this study the CIM update and extension are divided into four scenarios, add, delete, change and rename and corresponded algorithm are discussed. Finally, we conduct an experiment based on real model and compare the results with the ones did manually to verify this research's effectiveness and practicality.


INTRODUCTION
Standardized and open power system information is the basis for application integration.IEC61968/70standards not only describes the semantics of the information to be exchanged between different applications, but also provide the maximum flexibility and scalability for data exchange and utilization (Nielsen and Nielsen, 2010).As the gradual standardization of the power system, a series of information integration has been practiced at home and abroad (King, 2009;Liu et al., 2008;Singh, 2009).However, the problem of model difference exists in application integration based on CIM.There are two main reasons.First, CIM is evolving with the application requirements, leading to frequent version updates (Cao et al., 2011;Liu et al., 2012).Second, different enterprises may privately expand CIM according to their demand, which may cause semantic conflict and inconsistency (Liu et al., 2012;Popovic et al., 2007).To summarize, the reasons that cause model difference are update and extension.Model semantic difference will lead to semantic conflict and inconsistency which will disable the ability of data sharing among components.Therefore fast and accurate model difference analysis has significance in engineering practice (Uslar et al., 2010).
By utilizing the results of difference analysis, electric power company technical staff can maintain CIM more easily and make demands on different manufactures' application integration system according to actual demand.On the other side, considering that manufactures always develop application integration system based on one version of CIM, the results of difference analysis can contribute to system maintenance as well as shorten the time for system updating and upgrading.
Reference (Yu et al., 2012) proposed a method for CIM consistency validation by parsing power grid metadata information from exchanged message among different applications and comparing metadata with unified CIM to analyze syntax's compatibility and semantics' consistency.However, the research lays particular stress on metadata semantics verification (Li et al., 2010) without deep study on CIM itself.
In order to solve the problem of model difference, we propose a CIM update and extension research method based on ontology.When build new systems based on a newer version of CIM, we also need to update the original system to map this new CIM.But, before that, the differences between these two different CIM versions should be detected.Considering CIM is a quite large model, if we find the differences manually, the time costs is huge and there will be many possible errors in the final results.Therefore, fast and accurate different analysis is a necessary pre-requisite.In this study, the CIM update and extension are divided into four scenarios.In this study, we identified several CIM update and extension scenarios referring to the updated model M u1 and original model M o1 .
Add and delete: Class Substation is an added class defined in mode M u1 .Class Substation has an aggregation relationship with class Voltage and is a subclass of class EquipmentContainer.Also, class Equipment has been deleted from model M o1 .We can conclude that if a class is deleted, all the relationships about this class will also be removed.
In particular, according to the definition of add and delete scenario, class Conducting Equipment in M o1 and class Conducting Device in M u1 should also be classified as add and delete scenario.However, considering the attributes of these two classes are identical, we define these two classes as a new scenario, which will be discussed later in this section.
Change: During the evolving process, from the original model to the updated one, if a class's attributes or relationships change, we define it as change scenario.
Considering class BaseVoltage, the first attribute of it changes, from isDC:Boolean to isAC:Boolean.

CIMUPDATE AND EXTENSION ANALYSIS METHOD
The flow chart of CIM update and extension analysis is shown in Fig. 3.It consists of two major steps.First, convert XMI to OWL (Motik et al., 2009).Second, difference analysis based on ontology.
Convert XMI to OWL: CIM is maintained by Enterprise Architect (EA), the class diagrams can export to XMI format.Therefore this step involves transition among three basic languages, UML (Unified Modeling Language), XMI (Metadata Exchange Language) and OWL (Web Ontology Language).
Parsing XMI: While the XMI standard purports to facilitate the interchange of UML models, it has been largely ineffective in practice.There are two technical reasons for this.First and foremost, XMI attempts to solve a technical problem far more difficult than exchanging UML models; it attempts to provide a mechanism for facilitating the exchange of any language defined by the OMG's Meta model Object Fig. 3 In order to parse XMI, we construct an XML parser to recognize constructs of interest while ignoring surrounding syntax.When a construct is recognized, corresponding statements are inserted into an OWL/RDF model.The XMI id's (rather than the human readable, modeling names) are used to link up scraps of UML gleaned from different parts of the XMI document.
A translation phase then renames each XMI id for the modeling name and assigns a namespace.In other words, the URI reference is constructed for each class and property.
Convert UML to OWL: After parsing XMI, considering the conceptual similarity between UML class diagram and OWL, we can convert UML class diagram into OWL.The mapping between UML and OWL concepts is shown in Table 1.

Difference Analysis based on ontology:
Pre-processing: It can be concluded from previous analysis that CIM is made up of classes and relationships among them.A class can be divided into a normal class or an enumeration class.A normal class contains attributes and relationships, while an enumeration class contains only attributes.During the process of difference analysis based on ontology, we define node to represent OWL-related concepts, these concepts are organized in Table 2.
With reference to the above definition, the node description for class ConductingEquipment in M o1 can be shown as Table 3 represents.By the way of node description, a normal class'sattributes and the relationships associated with it can be accurately and completely described.
Similarly, an enumeration class contains only attributes and each attribute corresponds to an IndividualNode.Take enumeration class CoolantType (cooling mode) in CIM 61970 Wires package for example, CoolantType contains 3 attributes and Table 4 depicts its node description.

Algorithm description:
The algorithm discussed in this section is based on class.Considering that a normal class contains both attributes and relationships while an enumeration class contains only attributes, we assume enumeration class has 0 relationships.Figure 4 depicts the entire algorithm whose concrete steps are described below.

Parsing XMI:
The section describes document.We utilize conceptual similarity between UML and OWL to extract useful information.
Figure 5 shows the XMI parsing results.Corresponding information about and ObjectProperty is listed in this figure.Class contains class name and the inheritance relation.

RESULT ANALYSIS
Statistical data is shown in Therefore, class BaseVoltage belongs to change scenario.Moreover, class EquipmentContainer and class VoltageLevel establish new relationships with added class Substation, so these two classes are also changed classes.Rename: As previously stated, though class Conducting Equipment and class Conducting Device have different names, these two classes' attributes and relationships are identical, we define this scenario as rename.To judge whether two classes belong to rename scenario, we need to calculate two classes' similarity value.Define similarity value as follows:For two classes C o = {P o1 ,…, P oi , A o1 ,…,A oj } and C u = {P u1 , …, P um , A u1 , …, A un }, C o contains attributes and j relationships, contains m attributes and n relationships, define the similarity value between C o and C u :(1) where, |C o ∩C u | represents the total number of same attributes and relations between classes.

Fig. 6 :
Fig. 6: Detail information of original model = {Voltage Level, Terminal, Equipment Container, Base Voltage, Substation, Conducting Device} Each class may have attributes and the lines between classes represent relationships.Basically, there are three types of relationships, inheritance, association and aggregation in CIM.In Fig. 1, class Conducting Equipment has an inheritance relationship with class Equipment， which defines Conducting Equipment as being a subclass of Equipment.As a subclass, it inherits all the attributes of its parent, but can also contain its own attributes.Conducting Equipment also has an association relationship with class Base Voltage.At each end of the association link is the multiplicity.For the Conducting Equipment-Base Voltage association, these indicate that a Base Voltage must have from 0 to many (0..*) Conducting Equipments, while a Conducting Equipment can have from 0 to 1 (0..1)Base Voltage.Furthermore, class Equipment has an aggregation relationship with class Equipment Container, indicating that Equipment Container is a container class for class Equipment.The multiplicity on the diagram operates in the same manner as to that of the association.
: Analysis process of CIM extension and update

Table 5 :
CIM extension and update analysis's statistical result Total No.

Table 6 :
Analysis result of class EndDeviceAsset

Table 5 .
The original model contains a total of 757 normal updated model contains 679 normal classes.During the