Email: jean-francois.cabadi@power.alstom.com. AbstractâRealizations of so called smart grids imply numerous challenges for stakeholders within the energy ...
Standardization, Interoperability and Coexistence & Regulation (IEEE SmartGridComm)
CIMbaT - Automated Generation of CIM-based OPC UA-Address Spaces Sebastian Rohjans IEEE ComSoc Affiliate, Klaus Piech, Mathias Uslar
Jean-Francois Cabadi
OFFIS Institute for Information Technology Oldenburg, Germany Email: {rohjans, piech, uslar}@offis.de
IEC TC57/WG13 ALSTOM Power Systems SA Massy, France Email: jean-francois.cabadi@power.alstom.com
Abstract—Realizations of so called smart grids imply numerous challenges for stakeholders within the energy domain. ICT plays more and more a key role as it provides methodologies and approaches fostering smart grid applications. One of the challenges addresses integrated communications among energy management systems, distribution management systems, power generation systems and SCADA systems. In this case, a key issue to be considered is interoperability in terms of both syntax and semantics. For both, using standardized components like interfaces, protocols and data models, is essential to cope with the increasing number of actors and systems. Standards covering these components are discussed in various roadmaps and studies making recommendations. The Common Information Model is one of the recommended core standards for the smart grid and provides amongst others, a comprehensive data model for the energy domain. Another recommended standard is the OPC Unified Architecture being an abstract standard for server-clientcommunications which could be used in domain-specific contexts. Thus, combining the CIM data model and the UA communication architecture leads to a highly interoperable infrastructure meeting syntactic and semantic requirements. In this contribution, a two-step-approach is introduced realizing such an architecture.
I. I NTRODUCTION One significant problem in future smart grids is the interoperability between the different applications, devices and stakeholders [1]. Among them, a large amount of data has to be exchanged, so that lots of new interfaces arise [2]. Beside the physical power infrastructure, a suitable information infrastructure is needed to efficiently operate the future smart grid [3]. Standardization is a widely accepted and established way to cope with interoperability issues [4]. Also, in smart grid environments established standardization efforts exist [5], [6]. Several national and international roadmaps (like [7], [3], [8], [9]) are focusing on smart grid standardization and give recommendations on which standards should be used. One of the identified core standards is the data model of the IEC1 61970/61968/62325 Common Information Model (CIM) which provides a large information model for the energy domain. To use these informations, it is necessary to combine the CIM with communication standards. The IEC TC 57 is in charge of standard mappings of the CIM to recognized communication standards such as Extensible Markup Language (XML) or Resource Description Framework 1 International
(RDF) documents. The OPC Unified Architecture (UA; IEC 62541) is also a recommended smart grid Information and Communication Technology (ICT) standard and provides the needed capabilities to make the CIM applicable in terms of communication of data payloads. In detail, the UA is based on abstract data and information models. For each purpose the abstract data model - the Address Space - has to be filled with appropriate smart grid data like e.g. measurement data. Within the electric utility domain, the CIM provides almost all needed information and semantics to develop a domain-specific UA Address Space. In this contribution, we will give insights into real-worldrequirements concerning the application of the OPC UA and we will show why the CIM is a good and suitable choice for the UA data model to enable a seamless integration between process, automation and management layer. Use cases are considered in - but not limited to - the power transmission and generation domain: fleet scheduling, performance and condition monitoring, maintenance. Furthermore, we introduce a two-step-approach of how the CIM semantics can be used to generate OPC UA Address Spaces. The solution is based on the Unified Modeling Language (UML)-model of the CIM. The first step includes a methodology describing how a UA model designer could modify the UML-model to develop a platform specific model (PSM) which is the input for an external generator creating an UA Address Space. The second step introduces CIMbaT which is an Enterprise Architect (EA) AddIn - the tool that is used to maintain the CIM by the IEC model managers and the CIM user group2 (CIMug) - and semiautomatically generates an UA Address Space. Several design decisions can be made during the process and based on those decisions, the Address Space will be automatically generated. The final output are UA Address Spaces which have been evaluated in server-client-testbeds. The results show that it is both possible and meaningful to combine the CIM and the OPC UA to enable seamless integration in terms of smart grid communications. The contribution is structured as follows: Section II introduces the CIM as the basic information model for the implemented communication architecture. OPC UA in considered in 2 http://cimug.ucaiug.org/
Electrotechnical Commission
978-1-4577-1702-4/11/$26.00 ©2011 IEEE
416
section III to explain the basic communication concepts of the architecture. Requirements identified by real-world application are listed in section IV, followed by the derived mapping rules (section IV-A). The next part of the contribution deals with the two steps PSM in section V and CIMbaT in section VI. An evaluation based on test-servers and -clients is shown in section VII. Finally, section VIII concludes the paper and provides an outlook on further works. II. C OMMON I NFORMATION M ODEL The CIM is standardized in the IEC standard series 61970, 61968, and 62325 and it is also provided and developed by the CIMug, using UML, the lingua franca for modeling in software engineering. For instance, version 13 of the data model includes 45 packages comprising about 900 classes with more than 2650 attributes and being connected by about 870 associations [10]. Hence, CIM provides an opportunity for modeling almost all relevant use cases in terms of smart grid communications among Energy Management Systems (EMS) and Distribution Management Systems (DMS). Beside physical objects like generating units also virtual objects like voltage levels can be represented by CIM objects. Due to the fact that the CIM is an abstract and platform independent model, it covers a large application area. However, to make the CIM applicable, certain technology mappings have to be defined. XML and RDF are technologies for which mappings have been specified. In general the CIM is used for two primary objectives [11]: ∙
∙
Encapsulating entire power system models: For this use case, the RDF serialization of the CIM is used. In most cases, to exchange topology data of transmission and distribution networks. Hence, it is possible to exchange static and dynamic data as well as the current state of electrical networks in a standardized way. Exchanging data between applications: The XML serialization is used to define messages based on CIM semantics. This leads to seamless semantic data exchange among components in multi-vendor systems.
Even if the CIM is a large data model, extensions are necessary to use it for certain purposes in enterprises. It is not unusual that only a small part of such enterprise-specific profiles consist of native CIM classes. In general, profiles are applied to handle the CIM data model. For instance, the Common Power System Model (CPSM) is standardized to define transmission system models and the Common Distribution Power System Model (CDPSM) is standardized to define distribution system models. To make use of the CIM information combinations with communication standards are needed. Therefore, the CIM includes the Component Interface Specifications (CIS). They specify interfaces which can be implemented by components or applications to exchange data in a standardized way.
III. OPC U NIFIED A RCHITECTURE The OPC Foundation3 developed the OPC UA as successor of Classic OPC (OPC DA (Data Access), OPC AE (Alarms and Events) and OPC HDA (Historical Data Access)). Meanwhile, the UA is standardized by the IEC 62541 standard series [12]. Classic OPC is implemented in almost all industrial automation systems and is thus, well accepted. The three major improvements of the UA are platform independence, the capability to exchange data beyond local networks and providing a generic information model which is a basis for domain specific information models. The OPC UA consists of 13 parts, whereas the parts three to six are the most important ones in the context of this contribution. They deal with abstract services for server-clientcommunications, specific technology mappings for those services (Web Services and UA binary), the Address Space which is a meta model as well as a very generic information model. In this contribution, we take the CIM as an utility domain specific model to be set on top of the generic UA model and use the UA for integrated automation purposes [13]4 . The communication is based on a concept relying on nodes which are connected by references. Thereby, all node objects have attributes describing them. Furthermore, the nodes are grouped into classes according to their purposes, thereby again, the node classes have specific attributes. Besides the communication part, data modeling is the second fundament of OPC UA. In [14] the base principals of UA modeling are listed as follows: ∙ Using object-oriented techniques including type hierarchies and inheritance. ∙ Type information is exposed and can be accessed the same way as instances. ∙ Full meshed network of nodes allowing information to be connected in various ways. ∙ Extensibility regarding the type hierarchies as well as the types of references between nodes. ∙ No limitations on how to model information in order to allow an appropriate model for the provided data. ∙ OPC UA information modeling is always done on serverside. These principals enable generating simple - but also very complex - information models. IV. R EQUIREMENTS During the life-cycle of a CIM-based software product, the product’s information model changes. The IEC standard CIM addresses typical use cases in selected application domains. To address specific use cases (innovative function) or associated domains (e.g. generation), the IEC CIM needs to be extended to become the product’s information model. For instance, at 3 http://www.opcfoundation.org 4 Whereas is in [13] a more extensive and conceptual approach was introduced additionally covering semantic web services, here only domainspecific modelling of OPC UA information models is focused. Thus, this results can be used as input for the approach introduced in [13]
417
Alstom5 , the information model of a generation fleet scheduling product appears to contain 30% IEC classes: 30 IEC + 55 Alstom, most of the extension is due to the application domain. The information model of another product, an EMS modeler, also contains 30% IEC classes: 105 IEC + 245 Alstom, there most of the extension is due to the product functions. To fulfill new customer needs while capitalizing generic functions, to integrate IEC CIM releases also, the product’s CIM must be able to evolve continuously. It is thus necessary to automate the implementation of CIM into OPC UA as much as possible: first establish rules, then develop tools. The rules and tools described in this paper aim at supporting the ongoing IEC work by testing proposals during the development of real products. The ongoing IEC work addresses mainly the description of use cases (61970-451) and OPC UA mapping (61970-502-8).
∙
∙
A. Mapping Rules ∙
∙
∙
∙
∙
∙
∙
∙
V. P LATFORM S PECIFIC M ODEL
OPC UA types correspond to CIM elements as depicted in figure 2: – ReferenceType nodes correspond to CIM associations – ObjectType nodes correspond to CIM classes – VariableType nodes correspond to CIM class properties – DataType nodes correspond to CIM data types Only the classes whose instances are exposed in the Address Space (and their superclasses as well) need to be present in the ObjectTypes hierarchy. Classes which instances are not exposed in the Address Space need not to be exposed as ObjectTypes. The OPC server shall create VariableType nodes for all concrete CIM class properties. These nodes are exposed in the VariableTypes folder. An important issue is to deal with DataType attribute: in many cases, the NodeId of the DataType node - the DataTypeId - will be well-known to clients and servers. IEC 62541-3 defines DataTypes and IEC 62541-6 defines their DataTypeIds. Example: Float and String. Other DataTypes and their corresponding DataTypeIds may be specific to CIM (e.g. ActivePower) or even vendor-defined (specific to a product). CIM is a semantic model which does not specify the implementation format. For instance, the CIM Integer may default to OPC UA Int32 in a given product, but this default DataType should be replaced for selected CIM properties (e.g. UInt64 for accumulator value). Each CIM generalization relationship is implemented using a HasSubType reference between the ObjectType nodes corresponding to the considered superclass and subclass. Each CIM binary association relationship is implemented using a non-symmetric reference. Both forward and inverse references shall be supported by the server. Each
5 http://www.alstom.com/
such non-symmetric ReferenceType is defined as a subtype of an OPC NonHierarchicalReferences ReferenceType whose BrowseName is ”CIMReference”. Attributes: The values for selected OPC attributes are defined in the CIM UML such as e.g. BrowseName and DisplayName based on CIM element name, Description based on CIM element comment etc. The values for OPC additional properties as well are defined in the CIM UML such as e.g. SourceLowerCardinality based on CIM association-end’s lower multiplicity. Required delivery: A final requirement is to support the OPC UA Address Space definition by generating a ModelDesign.xml file. This file is not a formal standard described in a referenced specification, but it is a key of the OPC Foundation Software Development Kit (SDK), and thus a de-facto standard.
The previous requirements define mapping rules to be applied for generating the OPC UA Address Space from the CIM, whatever the release of the CIM is. To apply these rules for a given release of the CIM, a software engineer has still to decide design choices on an element-by-element basis. These design choices are captured by adding OPC UA specific information to the CIM release elements before actual OPC UA Address Space generation. This ”extended” UML model is called the OPC UA PSM, which expression has been borrowed from OMG’s Model R supported by UML tools used when Driven Architecture⃝ engineering CIM. This approach is consistent with other ongoing efforts related to CIM: ∙ at IEC, improving the traceability from 61970-301 UML CIM to standard profiles and interoperability tests ∙ at IEC, improving the consistency of 61850 standards with an UML underlying model ∙ in proprietary CIM-based products, generating consistent interfaces other than OPC UA (e.g. RDF Schema (RDFS) and XML Schema Definition (XSD)) The main design choices to decide in the PSM are: ∙ Abstract types ∙ Association direction ∙ Choice between Property or DataVariable ∙ DataTypes ∙ Access rights ∙ Historical access ∙ Root of the default View ∙ Views E.g. Abstract types: ObjectType node attribute IsAbstract should be set to False if corresponding object instances are exposed in the Address Space, True otherwise. The value of this attribute is selected in the PSM by applying a different UML stereotype to abstract and non-abstract classes. Association direction: In the UML CIM model, associations are not symmetric. The two ends of an association
418
between two classes have distinct names and distinct multiplicities. Again, when browsing the OPC Address Space, the corresponding OPC reference forward and inverse directions are handled differently. Because OPC constraints are ignored when building the CIM, the preferred OPC SourceNode does not necessarily match the CIM SourceRole but may match the CIM TargetRole as well. The actual OPC direction is currently defined by applying a specific stereotype to the association to be inverted. Other options could be chosen consistently with IEC choices for the XSD and RDFS UML profiles, such as using navigable associations or aggregations. Choice between Property or DataVariable: the default choice is to expose the CIM properties as Property nodes. If the stereotype ”UA-isDataVariable True” is applied to a PSM property, DataVariable nodes should be exposed as instances of this property.
Fig. 1.
CIMbat: Design-Step
A. Without Platform Specific Model Product maintenance would be an issue without PSM. The UML CIM is developed and maintained according to user requirements. Then the ModelDesign.xml is developed and maintained according to the UML CIM and to design choices. The important thing is that the design choices must be preserved when the UML CIM is modified. With the PSM approach, the design choices are stored in the PSM, then the PSM is synchronized with CIM. We rely on UML tools to update the PSM when the CIM is modified, so that the engineer has to input only the design choices related to CIM modifications. ModelDesign.xml is safely generated, without regression with respect to previous generations, only the modifications need to be tested. Without PSM, the design choices would be embedded in ModelDesign.xml. The issue would be to synchronize ModelDesign.xml with CIM modifications. It would not be acceptable that the design choices already defined must be input a second time by the engineer (because of regression risk), so the engineer would have to merge the two XML files R by using an XML editor such as XMLSpy⃝ . We suspect that the regression risk is higher in the case of merging XML than in the case of merging UML. On the other hand, the advantage of editing the XML file rather than a PSM would be the flexibility. VI. CIM BAT CIMbaT is developed as an EA Add-In and comprises two CIM mapping components implemented with C# in Visual Studio. One component is the CIM-to-WSML (Web Service Modeling Language)6 mapping in which the CIM classes, associations, association-ends, generalizations, attributes and data types are mapped to WSML conform instances written into a WSML-file representing an ontology. This created file can be imported by the Web Services Modeling Toolkit (WSMT)7 to do further modifications aiming at creating 6 http://www.wsmo.org/wsml/ 7 http://sourceforge.net/projects/wsmt/
an ontology suitable for semantic web services for electric utilities. The main component is the CIM-to-UA Address Space mapping which is constructed as a step-by-step wizard. The mapping rules are depending on the coordination with the IEC which is working on a mapping draft (as described in section IV-A). The mapped elements will be written into a XML-file. The wizard includes a XML configuration file in which the main and default settings can be done manually such as the namespaces and the prefixes for the stereotypes. The default values inside the configuration file can also be manipulated in the first wizard step. The configuration file is needed for preselecting the default values in the wizard and also for setting default values in the mapping. The wizard includes also a design-step for editing the mappings for single CIM classes and their attributes and associations in which the user got the possibility to set OPC UA properties like IsAbstract, SupportsEvents, Historizing and DataType. That means for instance, the engineer can override the default mapping rules for OPC DataType Integer or Float. Also the decision whether a CIM class attribute shall be mapped to a OPC Property or DataVariable is possible in the CIM designer. The manipulable CIM elements can be easily selected within a tree-structure and the editable values are displayed on the right-hand side (see figure 1). For each setting there is a specific stereotype which will be added to the updated CIM element and thus, creating the PSM. These UA-specific stereotypes are unique and include a value like True or False. The UA-specific stereotypes will be recognized in the mapping, like if a CIM attribute has a UAspecific stereotype for declaring it to an OPC DataVariable, then the mapping will create an OPC VariableType with a BaseDataVariableType declaration plus an OPC Variable within the related OPC ObjectType. Because the changes will be saved as UA-specific stereotypes in the CIM model they will be recognized when restarting the wizard. That means the design choices are preserved. If the mapper cannot find a UAspecific stereotype for a CIM element, then the default values
419
Fig. 2.
CIM to OPC UA Mapping
from the configuration file will be used. It is also possible to design Views and manage them. The Views are used for limiting the visible Nodes and References. The designed Views will also be saved as UA-specific stereotypes and mapped to OPC View nodes. As Views are intended to be defined on instance level, this step only provides the possibility to pre-define them on the abstract level. So, this is a preparing step for future instantiating functionalities. In coordination with the IEC and the decisions from the engineer the CIM elements will be mapped as shown in figure 2. As one can see in figure 2 all CIM classes will be mapped to an OPC ObjectType. ObjectTypes can own children such as variable/property and references. If a CIM class implies attributes then these attributes have to be mapped to variables or properties (depending on the IEC mapping rules and design decisions). These attributes will also be mapped to VariableTypes and the variables or properties are referenced to it. If the CIM class inherits from another CIM class (CIM generalization) then this inheritance needs to be referenced in the ObjectType with a OPC HasSubType reference. Other references are those used for modeling CIM associations. Each CIM association will be mapped to a OPC ReferenceType which will be referenced to the associated ObjectTypes. The CIM data types like enumeration, compound and primitive types will be mapped to OPC DataTypes. For the primitive CIM data types (String, Boolean etc.) the mapping uses the OPC BuildIn-DataTypes so that these ones doesn’t have to be mapped explicitly. Each OPC VariableType has an attribute ”DataType” to reference the DataTypes. All created OPC elements will be written into an XML-file compliant with the standard OPC Foundation UA ModelDesign.xsd schema: ∙ ReferenceTypes ∙ DataTypes ∙ VariableTypes ∙ ObjectTypes ∙ Objects Inherited types will be written after the legacy types. The future goal is to integrate a design step for creating instances out of the CIM elements. The designed instances will be mapped to OPC Objects with the references to the
Fig. 3.
OPC UA server running with CIM-based semantics
inherited OPC Object- and VariableTypes. VII. E VALUATION For the evaluation, a group of engineers with different expertise used CIMbaT to model CIM-based Address Spaces. Therefore, the last three releases of the CIM UML model were taken as basis. Also CIM-based models extended by Alstom to meet real-world requirements, CIM profiles and derived models were chosen to evaluate the implemented mapping rules. The evaluation was an iterative process as feedback was considered immediately to improve the tool. To test the generated Address Space, instances of some of the created ObjectTypes were needed. To get these instances a RDF-file with CIM-based topology data was used as basis. A small C# programm which parses through this RDF-file created the objects out of the classes by comparing them with the ObjectTypes, VariableTypes etc. from the generated R this Address Space Address Space. With Altova XML-Spy⃝ was validated with the XSD-schema from the OPC UA SDK. Now, the Address Space has to be loaded into an OPC-server and getting access to it with an OPC-client. The OPC UA Quickstarts and the OPC UA SDK 1.0 (both provided by the OPC Foundation) were suitable to realize this. To get access to the Address Space the pre-compiled Quickstart DataAccess client was used. For getting more detailed information from the server the SDK 1.0 client was used. Running the Address Space with the server needs a few more configurations. Then, the code has to be compiled to start the OPC-server with the changes. The last step is to run the pre-compiled DataAccess client which enables browsing the Address Space by an expendable tree-structure. The information from the nodes are displayed, like value and object attributes. The SDK 1.0 client is optimal to test the Address Space in detail, because with it all the OPC UA types used in the Address Space can be browsed and monitored. In figure 3 an OPC object is illustrated based on a CIM class (GeneratingUnit) with its attributes.
420
Fig. 4.
A CIM-association in the UA Adress Space
The detailed information from a created ReferenceType are depicted in figure 4. The evaluation showed that all needed design decision can be made with CIMbaT and that the generated Address Space can be used for running OPC-servers and accessing the data by OPC-clients without any problems. Furthermore, the tool analyses the UML models by parsing them before the mapping process so that some errors and inconsistencies within some of the used models could be detected. Since, the main objective of the approach is to make use of semantics provided by a data model in order to design another model and thus focusing model transformation, it is hard to define certain metrics for evaluation purposes. The most important aspects are the usability and meeting all design requirements of the engineers. VIII. C ONCLUSIONS AND F UTURE W ORK Following the recommendation of the IEC to develop a mapping between CIM and OPC UA, a two-step approach was introduced implementing such a mapping. Both steps were started independently and the people in charge learned from each other later on by providing feedback. The PSMstep was more driven by real-world-requirements and thus also deals with issues like model extensions, whereas CIMbaT was originally developed in a research context. The integration of both steps shows that it is reasonable to use the CIM data model as a basis for UA-based communications in the energy domain and so, build an integrated and highly standardized architecture. Furthermore, state-of-the-art simulation environments provided by the OPC Foundation were used to evaluate the approach. As CIMbaT has already adapted the PSM mapping rules to meet real-world-requirements, the future goal is to develop the combined steps together. Nevertheless, the results will be fed back to both, people in charge of the mapping in IEC TC 57 WG 13 and the OPC Foundation. Therefore, the experiences will enter into the development of the IEC 61970502-8 standard and on the other side, in efforts developing a OPC UA Companion Specification for the CIM, in order to proceed strengthening the role of CIM within future smart grids.
CIMbaT will be continuously improved. The next step includes the implementation of functionalities which allow instantiating the abstract Address Space. Thus, CIMbaT could be used to generate an abstract CIM-based Address Space and also to design an applicable model. Furthermore, CIMbaT could be extended and modified to become the OPC Foundation’s tool for integrating all UML-based data models and OPC UA. Beside the discussed mappings, the OPC UA could also be used in combination with other standardized data models in terms of communications in smart grids. So, there is already work in progress to use the IEC 61850 data model for UAbased communication [15]. A intermediate-term goal to be achieved is promoting the UA as an harmonizing component for smart grid data models. Thereby, it is important to notice that the application of the OPC UA in smart grids is not aiming at replacing established communication standards like IEC 61850. In fact, the OPC UA can be applied complementary by serving as one possible way of exchanging the data and thus improving the performance. However, to validate the promising performance it is necessary to run appropriate tests, what is not in the scope of this contribution covering model design issues. R EFERENCES [1] DKE, The German Standardization Roadmap E-Energy/Smart Grid. VDE, 2010. [Online]. Available: www.dke.de/de/std/Kompetenzzentrum E-Energy/Seiten/Links.aspx [2] M. Tr¨oschel, Aktive Einsatzplanung in holonischen Virtuellen Kraftwerken. Edewecht: Oldenburger Verlag f¨ur Wirtschaft, Informatik und Recht, 2010. [3] NIST, “NIST Framework and Roadmap for Smart Grid Interoperability Standards,” 2010. [4] IEA and ISO, “International Standards to develop and promote energy efficiency and renewable energy sources,” 2007. [5] S. Rohjans, M. Uslar, R. Bleiker, J. Gonz´alez, M. Specht, T. Suding, and T. Weidelt, “Survey of Smart Grid Standardization Studies and Recommendations,” in First IEEE International Conference on Smart Grid Communications, 2010. [6] M. Uslar, S. Rohjans, R. Bleiker, J. M. Gonz´alez, T. Suding, M. Specht, and T. Weidelt, “Survey of Smart Grid Standardization Studies and Recommendations - Part 2,” in IEEE Innovative Smart Grid Technologies Europe, 2010. [7] SMB Smart Grid Strategic Group (SG3), “IEC Smart Grid Standardization Roadmap,” 2010. [8] J. Ø stergaard, “European SmartGrids Technology Platform-Vision and Strategy for Europes Electricity Networks of the Future,” 2006. [9] CEN, CENELEC, and ETSI, “JWG Report on Standards for the Smart Grid,” 2010. [10] M. Uslar, S. Rohjans, M. Specht, and J. Gonzales, “What is the CIM lacking ?” in IEEE SmartGridComm 2010, 2010. [11] A. W. McMorran. (2007) An Introduction to IEC 61970-301 & 6196811: The Common Information Model. [12] IEC, “62541-1 Ed. 1.0: OPC Unified Architecture Specification - Part 1: Overview and Concepts,” 2008. [13] S. Rohjans, M. Uslar, and H. J. Appelrath, “OPC UA and CIM: Semantics for the smart grid,” in Transmission and Distribution Conference and Exposition, 2010 IEEE PES, 2010, pp. 1–8. [14] W. Mahnke, S.-H. Leitner, and M. Damm, OPC Unified Architecture, 2009. [15] S. Lehnhoff, W. Mahnke, S. Rohjans, and M. Uslar, “IEC 61850 based OPC UA Communication - The Future of Smart Grid Automation,” in 17th Power Systems Computation Conference (PSCC’11), Stockholm, 2011.
421
