Towards the Automatic Alignment of CIM and SCL Ontologies

Transcription

1 Standardization, Interoperability and Coexistence & Regulation (IEEE SmartGridComm) Towards the Automatic Alignment of CIM and SCL Ontologies R. Santodomingo, J.A. Rodríguez-Mondéjar, M.A. Sanz-Bobi Institute for Research in Technology (IIT) Comillas Pontifical University, ICAI School of Engineering Madrid, Spain Abstract During the planning and configuration of future energy smart grids translations of configuration files between CIM and IEC standards are going to be required. In order to carry out such translations it is necessary to align the CIM and SCL ontologies, which define the semantics of the configuration files. This work presents a methodology to automatically obtain the alignments between such ontologies. The methodology is based on the interaction between two existing tools: CIMMappingBench and ESODAT. This interaction requires the participation of the Domain Expert, which is a software tool developed in this work. The Domain Expert is able to employ specific knowledge about the electric system domain in order to find new alignments. The tests carried out showed the ability of the methodology to find most of the alignments required to translate a configuration file representing a simple facility. Keywords-energy management; substation automation; IEC standards; harmonization I. INTRODUCTION The Common Information Model (CIM) is standardized by standards series IEC and and is recommended as one of the core standards for the future energy grid [1]. The CIM is mainly used for the following use cases: exchanging custom messages using CIM semantics and syntax based on XML 2 serializations; exchanging instance data of the distribution and transmission grid topology, serialized using the Resource Description Framework (RDF) 3 standard; and standardizing interfaces between systems and interface descriptions. The standard series IEC are also a recommended in the context of smart grids [1]. The overall focus of the standard family lies on substation automation and the corresponding communication (substation inter-device communication). Two different data models can be found in the IEC 61850: the LN model [2], which defines the semantics of the messages to be exchanged between the devices, and the SCL (Substation Configuration Language) model [3], which defines the concepts to be employed in the XML files during the configuration of the automation system. Many approaches, such as [4], argue for a harmonization of these standards because there are many cases in which an 1 International Electrotechnical Commission S. Rohjans, M. Uslar OFFIS Institute for Information Technology R&D Division Energy Oldenburg, Germany {Rohjans, Uslar}@offis.de interaction between remote management applications (that use the CIM) and local automation devices and tools (using IEC 61850) is required [5]. During the planning and configuration of the electric networks such interactions involve the translation of configuration files (CIM/XML [6] and SCL [4]) from one standard to the other. In order to carry out these translations it is necessary to obtain the semantic correspondences between the entities (classes, properties, attributes) defined in CIM and the corresponding entities defined in SCL, i.e. it is necessary to align the CIM and the SCL ontologies. Given the extension and complexity of the ontologies and the possible modifications in their future versions, in this contribution we introduce a holistic approach for the automatic alignment of CIM and SCL ontologies. We combine and extend two existing approaches to gain improved results. The first part of the combination is an extended version of the CIMMappingBench which was developed within the context of the COLIN [7] (CIM Ontology alignment methodology) framework and is able to semi-automatically generate ontology alignments expressed in OWL (Web Ontology Language) 4. The second part of the approach involves the data translator ESODAT (Electric System Ontologies Data Translator) [8]. Combining these parts leads to an improvement in the alignment generation and processing in order to automate the translation of configuration files between CIM and IEC without modifying the original standards. Such improvement in the alignment generation is achieved by employing specific knowledge about the electric system domain. This specific knowledge is automatically processed by the Domain Expert, which is a software tool developed in this work. In general, the automatic alignment of ontologies generated from standards will facilitate both: the interaction between systems based on such standards and the detection of the existing heterogeneities between their data models. Moreover, the methodology proposed in this work could also be employed to align different versions of the same standard, facilitating its version management. This paper is organized as follows. Section II presents the ontologies to be aligned (CIM and SCL) and the existing tools employed in this work to generate the alignments: the CIMMappingBench and ESODAT. Section III gives an /11/$ IEEE 422

2 overview of the process defined in this work to automatically find the alignments between the ontologies. Such process is based on the interaction of CIMMappingBench and ESODAT. This interaction requires the participation of the Domain Expert tool in order to propose new alignments employing specific knowledge about the electric system domain. Sections IV to VII describe the functionality of the Domain Expert. Section VIII shows the results obtained in the tests carried out. Finally, Section IX includes the conclusions and future works. II. FUNDAMENTALS A. CIM & SCL Ontologies One of the core components of the CIM is an extensive and abstract data model which represents an ontology for the energy domain. The model is maintained as Unified Modelling Language (UML)-model by different model managers (TC57 WG13 and WG14) and its development is supported by the CIM users group (CIMug) 5. Version 13 of the data model consists of 45 packages including about 900 classes with more than 2650 attributes and being connected by about 870 associations [9]. Thus, CIM enables modeling almost all desired matters within the energy domain for communications of Energy Management Systems (EMS) and Distribution Management Systems (DMS). Originally, the focus of IEC (developed by TC57 WG10 6 ) was on substation automation and protection equipment and thus, applied in a different area as CIM focusing on EMS and DMS communications. In the context of this contribution, especially part 6 of the standard series is of high importance. It defines the SCL [4] which enables a standardized configuration to completely describe electric facilities and automation systems by configuration files. B. CIMMappingBench & ESODAT COLIN tries to overcome the different dimensions of heterogeneity in terms of harmonizing smart grid standards by establishing an ontology-based integration methodology [7]. One of the most striking harmonization needs is between CIM and IEC 61850; at this point the CIMMappingBench is applied [11]. The CIMMappingBench is developed as a stand-alone tool and is able to import data models in XMI (XML Metadata Interchange) and XML formats. The imported data models can be exported as OWL- files or results from quantitative analysis can be saved in CSV (Comma Separated Values) format. Beside the possibility to browse through the models using a tree-structured GUI (Graphical User Interface), also an interface is provided to be implemented by different matchers. For the case of mapping CIM and IEC data models a specialized matcher was implemented to meet the requirements of the two data models. In this contribution the CIMMappingBench generated the initial alignments between CIM and SCL. The matching process in the CIMMappingBench comprises several steps. In the first step, the strings of the names and descriptions of the CIM and SCL classes and attributes have to be prepared by employing: stemming algorithms to reduce the Technical Committee 57 Working Group 10 names and descriptions to their stem or root form, filters to avoid redundant words, and information from electropedia 7 to identify words with similar meanings. In the second step, CIM and SCL entities (classes and properties) are compared by using string-based methods, such as Jaro-Winkler 8 and Levenshtein 9, and structural analysis, which is able to detect two equivalent classes having different names and descriptions but similar attributes. Finally, once the similarity matrix M (Fig. 1) is obtained relating the entities of both ontologies, the alignments are exported in an OWL-file. ESODAT [8] is a data translator that is able to process the alignments expressed in OWL and SWRL 10 (Semantic Web Rule Language) to translate configuration files from CIM/XML to SCL and vice versa. ESODAT is based on Jena and OWL API, which both are open-source frameworks for building semantic web applications. III. CIMMAPPINGBENCH ESODAT INTERACTION Interaction of CIMMappingBench and ESODAT makes it possible to find the alignments that establish the semantic correspondences between CIM and SCL entities for the translation of configuration files by employing specific knowledge about the electric system domain. As shown in Fig. 1, such interaction is an iterative process that starts with the alignments Aº obtained with the CIMMappingBench. The alignments are imported by ESODAT to translate an instance configuration file (cim/xml) from one standard to the other. This instance file has to follow the definitions included in the specific knowledge file of the corresponding standard. At this point, the Domain Expert evaluates the output of the translation (cim/xmlº) and proposes new alignments A in order to improve the translation in the following iteration. This iterative process stops when the Domain Expert detects that the translation has not improved from the previous iteration. Fig. 1 shows the process to find the alignments for the translation from CIM to SCL. To find the alignments from SCL to CIM the process has to be repeated with an instance file scl. Fig. 1. CIMMappingBench ESODAT interaction staffwww.dcs.shef.ac.uk/people/s.chapman/stringmetrics.html#jaro

3 In order to evaluate the output of the translation and propose new alignments, the Domain Expert has to create its knowledge base from files defining specific knowledge about how to represent a type of facility (radial substation, breaker and a half substation, etc.) in both standards. Once the Domain Expert has created its knowledge base, it is able to evaluate the output of the translation by comparing it with the correct representation of an installation in the corresponding standard. Finally, from this comparison, the Domain Expert follows a set of generic rules to propose new alignments that improve the translation. Following sections describe in detail the functionality of the Domain Expert. In particular, it will be explained how in a specific iteration the Domain Expert is able to evaluate the output of a CIM/XML to SCL translation and to propose new alignments. The process for a translation in the opposite direction, i.e. from SCL to CIM/XML, is analogous. IV. KNOWLEDGE BASE ACQUISITION The specific knowledge files that describe how to represent a type of facility in CIM/XML and SCL employ OWL and SWRL languages. From each specific knowledge file the Domain Expert creates a semantic network [11] in which each node represents a type of element that have to appear in the output of the translation (Fig. 2). However, in the definition of a type of facility there are elements that may or may not appear. For example, in some facilities of a specific type there may be a current transformer connected to one point of the facility, and in other ones this element may not appear. In such cases the node is declared as optional in the semantic network. Each node n in the semantic network has the following elements: <c, â, âv, âref>. Such elements represent: c, the name of the class; â, the attributes that are required in the node; âv, the attributes required in the node and that have to take a specific value, for example scl:type = CBR in a node which represents a circuit breaker in the SCL ontology; âref, the attributes that establish a relationship with other object by reference, for example, scl:pathname and scl:connectivitynode establish the relationship by reference between a terminal and a connectivity node in the SCL ontology. Each node will be associated with the required nodes by the relationships r, such as, for example, the scl:terminal property in Fig. 2. The semantic networks also include the relationships by reference. V. STRUCTURE ASSOCIATION In order to evaluate the translation carried out in a specific iteration, the Domain Expert compares the instances obtained in the output of such translation with the nodes defined in the corresponding semantic network. For example, in a translation from CIM/XML to SCL, the Domain Expert compares the output of the translation with the semantic network that contains the information about how to represent the specific type of facility in SCL. This semantic network is called So, from output or target semantic network, and the other one is called Si, from input or source semantic network. To perform the comparison the Domain Expert makes a structure association between the output of the translation and the semantic network. Such structure association is based on similarity functions σ(i.n) that will give a unitary measure of the similarity between the instance i and the node n attending to different characteristics. A. Class similarity (σc) The first similarity function that is calculated by the Domain Expert is the σc(i.n), that indicates if the instance i appears in the output of the translation with the same class that the node n, i.e. c n, in the semantic network. Let s suppose that E1Q1QA1T1 is an instance included in a CIM/XML file (cim/xml) that belongs to the cim:terminal class. If the alignment establishing that cim:terminal is equivalent to scl:tterminal is processed by the data translator, in the output of the translation such instance will appear belonging to the scl:tterminal class. Thus, taking into account the nodes described in Fig. 2, the similarity function σc(e1q1qa1t1, SCLTerminal1) will be equal to 1 and, for instance, σc(e1q1qa1t1, SCLBreaker1) will be equal to 0. This process has to be done for all the instances in the output of the translation and all the nodes in the corresponding semantic network. The result is a similarity matrix Mc that includes the values of the similarities σc(i,n) for all the instances i in the configuration file and all the nodes n in the semantic network. B. Property similarity (σp) The second similarity function that is calculated is the σp(i.n), that indicates the similarity between the properties and attributes of the instance i (Pi) and the properties and attributes of the node n (Pn) (1). Let s suppose that the instance E1Q1QA1 appears in the output of a CIM/XML to SCL translation having the attribute scl:name. Again, following the nodes described in Fig. 2, the similarity functions σp(e1q1qa1, SCLBreaker1) will be equal to 1/3 and σp(e1q1qa1, SCLTerminal1) will be equal to 1/6. The similarity matrix Mp includes all the values σp(i.n) for all the instances i and all the nodes n. σp(i, n) Pi Pn = (1) Pi Pn Fig. 2. Fragment of a Semantic Network So C. Local similarity (σl) The local similarity σl(i.n) aggregates the values of σc(i.n) and σp(i.n) (2). σl(i, n) = wc σc(i, n) + wp σp(i, n) (2) 424

4 In (2), wc and wp are the weights for σc(i.n) and σp(i.n), respectively. In this study the value given to wc is 0 7 and to wp is 0 3. This is because we considered that the information given by σc(i.n) is more valuable to compare i to n than the information given by σp(i.n). However, in future versions the Domain Expert will be able to automatically change the weights in order to improve the alignment generation in the next iteration. D. Global similarity (σg) The local similarities σl(i.n) only take into account the information obtained from the data translation. The global similarities σg(i,n) add the knowledge about the structure in the input file (cim/xml), i.e. the knowledge about which instances are associated in the input file. This is based on the hypothesis that if two instances are related somehow in the input or source ontology, they will be probably related also in the output or target ontology. The computation of the global similarities has to be iterative because circular dependencies are expected, i.e. the fact that i is associated to n makes it more probable that i is associated to n, and vice versa. A computation based on the Similarity Flooding [12] is used in this study and will be explained here. Following the Similarity Flooding, the first step is to create a graph that will be called G. In this graph the nodes are pairs <i,n> and each node is related with another one <i,n > if a relationship exists between i and i in the input file cim/xml and if a relationship exists between n and n in So. In both cases, the relationships between instances by reference, e.g. between a scl:tterminal and a scl:tconnectivitynode, will be taken into account. For example, let s suppose that the instance SE12 is related to E1 in the input by the cim:voltagelevel.substation object property, and in the semantic network So, the node SCLSubstation is related to the node SCLVoltageLevel2 with the scl:voltgalevel object property. In that way, the nodes <SE12, SCLSubstation> and <E1, SCLVoltageLevel1> are going to be associated in the graph G. Each association between the nodes <i,n> of G has to be assigned to a weight w, which is going to be equal to 1/m, being m, the number of associations that has the source node. Once the graph G is created, the iterative process starts. Initially the global similarity σg(i,n) between each instance i and each node n is equal to the corresponding local similarity σl(i,n). The global similarity in the following steps is calculated with the equation (3). it+ 1 σg (i,n) = σl(i,n) + σg (i',n') w( < i,n >, < i',n' > ) (3) < i',n' > G Finally, the similarities have to be normalized with the highest σg(i,n) value. Employing the normalized similarities, the algorithm stops if the expression in (4) is true. In (4) ε is the threshold, which in this work was set to 0 1. i cim/xml,n So; σgµ (i, n) σgµ (i, n) < ε it it+ 1 E. Associations between instances and nodes Once the normalized global similarities σg μ(i,n) are calculated, the instances in cim/xml can be associated to their most probable nodes in So, and in the same way, the nodes in it (4) So have to be associated to their most probable instances in cim/xml. This association may not be bijective because of the coverage mismatches between both ontologies, i.e. there may be some instances that are not translated to the target ontology and there may be some nodes in So that are not represented in the original ontology instance file cim/xml. Taking this into account, the associations between instances i in the input file cim/xml and nodes n in the semantic network So will be obtained with the following rules: a) for each instance i, take the node n with the maximum global similarity σg μ(i,n); b) for each node n, take the instance i with the maximum global similarity σg μ(i,n); c) if i has the maximum σg μ(i,n) for n and n has the maximum σg μ(i,n) for i, then i is associated the node n; and d) if after this, there are two instances associated to the same node, remove such associations. VI. ALIGNMENT GENERATION RULES The previous section explains how the Domain Expert associates the instances in the input file cim/xml to the nodes in the semantic network So. This process is also carried out by the Domain Expert to associate the instances to the nodes in Si. Hereinafter, the nodes in So will be noted as no and the nodes in Si as ni. Once the instances i are associated to the nodes no in So, and the nodes ni in Si, the next step is to propose the alignments that make such associations more probable. For that purpose, the Domain Expert employs a set of generic rules that detect and classify the differences between the instances in the output of the translation and the corresponding nodes no in So. For each type of difference or mistake detected in the output of the translation the rules propose a new alignment. For example, the first rule employed by the Domain Expert to propose new alignments is the following. When the instance i does not belong in the output of the translation to the same class that the class of the corresponding node no (c no ) the Domain Expert proposes the alignment expressed in (5). In (5): c ni is the class of ni, â vi are the attributes of ni that have to take a specific value, c no is the class of no and â vo are the attributes of no that have to take a specific value, x, [c (x) âv ] [c (x) âv ] (5) ni ni Let s suppose that the instance E1Q1QA1 is associated in So to SCLBreaker1 (Fig. 2) and in Si to CIMBreaker1, which is a node that belongs to cim:breaker class and that does not have any a vi attribute. Let s also suppose that in the output of the translation the instance appears belonging to a different class that the class of the corresponding no, i.e. scl:tconductingequipment. In such case, the proposed alignment would be the one expressed in (6). x, [cim : Breaker(x)] [scl : tconductin gequipment(x) no scl VII. ITERATIVE PROCESS no : type(x, CBR)] Sections V and VI described the steps carried out by the Domain Expert in a single iteration to detect the mistakes that may appear during the translation in such iteration and propose new alignments to solve these mistakes in the following iteration. This section explains when the iterative process stops, this means when the Domain Expert decides that no more additional alignments can be proposed in order to improve the (6) 425

5 translations. The function whose value indicates that the iterative process has reached to its end has to indicate the wellness of the translations carried out in the iterative process. The measure of such wellness is based on the global similarities σg μ(i,no) calculated in each iteration to associate the instances of the input file cim/xml to the corresponding nodes in the semantic network So. These similarity functions measure the similarity between each i instance and each node no. In order to calculate the similarity of the complete structure association between the instances and the nodes, and therefore, measure the wellness of the translation in the iteration, it is necessary to define a total similarity function σ TOT, whose value will be obtained from (7). σ = σg (i, no) σr (7) TOT I R In (7): I is the set of all the instances i included in the input file, R is the set of all the relationships ro between the nodes no in the semantic network So; and σr i is the similarity function between the relationships ro of the node no in So and the relationships of the instances i in the input file cim/xml. The value of σr i is equal to 1 if the relationship ro associating no to other node no in the semantic network So appears also in the output of the translation associating i to i, being i the corresponding instance to no. If ro does not appear in the output, but the instance i is associated to i in the input file by a relationship ri the value of σr i is equal to 0 5. In the rest of the cases the value of σr i is 0. For example, let`s suppose that the instance SE12 is associated in So to the node SCLSubstation. Such node is associated in So to the node SCLVoltageLevel1 with the relationship ro scl:voltagelevel. The instance associated to SCLVoltageLevel1 is E1. In the output of the translation SE12 is not associated to E1, but in the input file the relationship ri cim:voltagelevel.substation associates these two instances. In this case, the value of σr i would be equal to 0 5. The value of σ TOT is not unitary, i.e. could be greater than 1. The unitary value σ TOTμ could be obtained by dividing σ TOT by the maximum σ TOT that can be calculated in the semantic network So, i.e. the total similarity that would be obtained in So if all the similarities σg μ(i,no) and σr i were equal to 1. The iterative process stops when σ TOTμ does not change more than a threshold ε (in our case set to 0 01) in comparison with the value in the previous iteration. µ VIII. TESTS A. Alignments Aº The initial alignments Aº are the starting point for the iterative process between ESODAT and the Domain Expert. Such alignments have to be very accurate, i.e. importing less initial alignments but with the certainty that they are true it is better for the convergence of the iterative process than importing more initial alignments but with some false positives among them. For that reason, the CIMMappingBench used very restrictive thresholds (0 9) in the generation of the initial alignments Aº. The results obtained in the tests are shown in Table I. i TABLE I. INITIAL ALIGNMENTS Aº CIM ontology cim:substation(x) cim:voltagelevel(x) cim:bay(x) cim:conductingequipment(x) cim:terminal(x) cim:connectivitynode(x) SCL ontology scl:tsubstation(x) scl:tvoltagelevel(x) scl:tbay(x) scl:tconductingequipment(x) scl:tterminal(x) scl:tconnectivitynode(x) cim:identifiedobject.name(x, y) scl:name(x, y) B. Specific Knowledge & Instance Configuration File The specific knowledge that was given to the Domain Expert in the tests as OWL and SWRL files involved the representation of a very simple type of electric facility in both standards. Such type of facility is a substation that consists of two voltage levels. The first one contains a breaker and a connectivity node, and the second one just contains a connectivity node. Obviously, this type of facility would not have much sense in the real world, but it was very useful for the evaluation of the Domain Expert functionality. The last input required to start the iterative process is the instance configuration file representing a facility that belongs to the type of facility described in the specific knowledge files imported by the Domain Expert. In our case, the instance configuration file employed in the tests was a CIM/XML file representing a substation with the characteristics described above (Fig. 3). C. Knowledge Base Acquisition (Si and So) The Domain Expert acquired its knowledge base from the specific knowledge files that describe how to represent the type of facility shown in Fig. 3 in both standards. Such knowledge base consisted of two semantic networks: Si describing how to represent the type of facility in CIM and So describing how to represent the type of facility in SCL (Fig. 2). D. Results obtained in the first iteration This sub-section shows the results obtained during the first iteration. In this iteration ESODAT processed the alignments Aº included in Table I in order to translate the CIM/XML file into SCL. The comparison between the instances in the output of the translation and the nodes defined in So resulted in the global similarity matrix Mg shown in Table II, in which the similarities in bold indicate that an association was established between the instance represented in the corresponding file and the node represented in the corresponding column. From these associations and following the set of rules introduced in Section VI, four new alignments were proposed. One of them was the alignment expressed in (6). E. Results obtained in the last iteration In the third iteration the iterative process stopped with the σ TOTμ equal to The resulting additional alignments proposed by the Domain Expert are shown in Table III. 426

6 TABLE III. PROPOSED ALIGNMENTS Fig. 3. Type of facility defined in the specific knowledge files and names of the instances (in brackets) included in the CIM/XML file TABLE II. GLOBAL SIMILARITY MATRIX IN FIRST ITERATION SCLSubstation SCLVoltageLevel1 SCLVoltageLevel2 SCLBay1 SE12 1,00 0,04 0,04 0,32 0,32 0,03 0,04 0,03 0,09 0,10 E1 0,04 0,80 0,83 0,04 0,03 0,14 0,19 0,18 0,02 0,02 D1 0,04 0,79 0,88 0,04 0,04 0,17 0,23 0,21 0,02 0,02 E1Q1 0,33 0,05 0,05 0,93 0,87 0,04 0,04 0,04 0,26 0,27 D1Q1 0,31 0,04 0,04 0,86 0,83 0,03 0,04 0,03 0,20 0,21 E1Q1L1 0,04 0,15 0,18 0,04 0,03 0,74 0,79 0,35 0,02 0,02 E1Q1QA1 0,05 0,19 0,22 0,06 0,04 0,36 0,40 0,59 0,03 0,03 E1Q1QA1T1 0,10 0,04 0,04 0,26 0,21 0,03 0,03 0,03 0,73 0,74 E1Q1QA1T2 0,12 0,04 0,04 0,28 0,22 0,07 0,03 0,03 0,74 0,75 D1Q1L1 0,04 0,19 0,23 0,05 0,04 0,77 0,82 0,39 0,03 0,02 IX. SCLBay2 SCLConnectivityNode1 SCLConnectivitNode2 SCLBreaker1 CONCLUSION AND FUTURE WORK The translation of configuration files between CIM and IEC standards is necessary to achieve the interoperability in the scope of future smart grids. In order to carry out such translations the alignment of CIM and SCL ontologies is required. Taking into account the extension and complexity of the ontologies and the possible extensions and modifications in future versions of the standards, it is very useful to automate the alignment process as much as possible. This work presents a new methodology to automatically align CIM and SCL ontologies by combining two existing approaches: CIMMappingBench and ESODAT. This methodology employs: string-distance-based, lexicon-based, structure-based and specific-domain-knwoledge-based methods to automatically find the semantic correspondences between the ontologies. In order to use the specific domain knowledge to obtain new alignments a new software tool, called Domain Expert, was developed in this work. The tests carried out showed the ability of the methodology to obtain most of the required alignments (including quite complex ones) to translate a configuration file representing a simple facility. SCLTerminal1 SCLTermianl2 CIM ontology SCL ontology cim:bay(x) cim:bay.voltagelevel(x,y) scl:bay(y,x) cim:breaker(x) scl:tconductingequipment(x) scl:type(x, CBR) cim:breaker(x) cim:equipment.equipmentcontainer(x,y) scl:conductingequipment(y,x) cim:connectivitynode(x) cim:connectivitynode.connectivitynode- scl:connectivitynode(y,x) Container(x,y) cim:terminal(x) cim:terminal.conductingequipment(x,y) scl:terminal(y,x) cim:voltagelevel(x) cim:voltagelevel.substation(x,y) scl:voltagelevel(y,x) In the current version the specific knowledge files imported by the Domain Expert were created manually, but in the future they will be obtained by automatic learning methods or with the help of a tool that guides a non-expert in their elaboration. Moreover, the Domain Expert will be able to automatically calculate the thresholds and weights employed in the process in order to improve the alignment generation. REFERENCES [1] NIST FrameWork and RoadMap for Smart Grid Interoperability Standards, Release 1.0. NIST Special Publication January [2] Draft IEC communication networks and systems in substations - part 7-4: Basic communication structure - compatible logical node classes and data classes, IEC TC57 Standard, [3] IEC communication neworks and systems in substations - part 6: Configuration description language for communication in electrical substations related to IEDs, IEC TC57 Standard, [4] C. Frei, O. Preiss and T. Kostic, "Method and System for bi-directional data conversion between IEC and IEC 61970," International Patent Application PCT/CH2004/000510, [5] Harmonizing the international electrotechnical comission common information model (CIM) and standards via a unified model: Key to achieve smart grid interoperability objectives. EPRI, Palo Alto, CA: [6] Draft IEC : Energy management system application programming interface (EMS-API) - part 552: CIM XML exchange format, IEC TC57Standard, January [7] Uslar, Mathias, F. Gruening, and Sebastian Rohjans A Use Case for Ontology Evolution and Interoperability: The IEC Utility Standards Reference Framework Pp in Cases on Semantic Interoperability for Information Systems Integration: Practices and Applications, edited by Y. Kalfoglou. IGI Global. [8] R. Santodomingo, J. A. Rodríguez-Mondéjar and M. A. Sanz-Bobi, "Ontology matching approach to the harmonization of CIM and IEC standards," in IEEE SmartGridComm [9] M. Uslar, S. Rohjans, M. Specht, and J. Gonzalez. What is the CIM lacking? in IEEE SmartGridComm [10] Uslar, Mathias Ontologiebasierte Integration heterogener Standards in der Energiewirtschaft. Edewecht: Oldenburg Computer Science Series XIII. [11] D. Popovic and V.P. Bhatkar, Methods and Tools for Applied Artificial Intelligence, Marcel Dekker, Inc., New York, [12] S. Melnik, H. Garcia-Molina, and E. Rahm. Similarity flooding: a versatile graph matching algorithm, in ICDE International Conf