Model transformation between OPC UA and UML

Author’s Accepted Manuscript Model Transformation between OPC UA and UML Byunghun Lee, Dae-Kyoo Kim, Hyosik Yang, Sungsoo Oh

www.elsevier.com

PII: DOI: Reference:

S0920-5489(16)30076-9 http://dx.doi.org/10.1016/j.csi.2016.09.004 CSI3136

To appear in: Computer Standards & Interfaces Received date: 14 April 2016 Revised date: 28 July 2016 Accepted date: 14 September 2016 Cite this article as: Byunghun Lee, Dae-Kyoo Kim, Hyosik Yang and Sungsoo Oh, Model Transformation between OPC UA and UML, Computer Standards & Interfaces, http://dx.doi.org/10.1016/j.csi.2016.09.004 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting galley proof before it is published in its final citable form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

Model Transformation between OPC UA and UML Byunghun Leea , Dae-Kyoo Kima , Hyosik Yangb , Sungsoo Ohb a Dept.

of Comp. Sci. and Eng. Oakland University, Rochester, MI 48309, USA b Dept. of Comp. Eng. Sejong University, Seoul, South Korea

Abstract OPC Unified Architecture (UA) is a platform-independent standard for messagebased communication between clients and servers on various types of network to facilitate information exchange. OPC UA has been adopted in various domains such as power grids, building automation, and smart devices to support interoperability of involved systems. These domains also use Unified Modeling Language (UML) as the standard notation for data modeling or system modeling. Use of two different notations in the same domain causes compatibility issues. To address this, we present an approach for transforming OPC UA to UML to improve their compatibility and integration. In the approach, we rigorously analyze the semantics of OPC UA elements and establish a mapping between OPC UA elements and UML elements based on the analysis. Based on the mapping, we define transformation algorithms using Query/View/Transformation (QVT) which is a standard model transformation language by OMG. We demonstrate the approach using case examples in the power grid, building automation, and smart device domains. Keywords: , Model transformation, OPC UA, QVT, UML

1. Introduction OPC Unified Architecture (OPC UA) [1] is a standard for information exchange for industrial systems (e.g., manufacturing systems) and it has been Email addresses: [email protected] (Byunghun Lee), [email protected] (Dae-Kyoo Kim), [email protected] (Hyosik Yang), [email protected] (Sungsoo Oh)

Preprint submitted to Journal of LATEX Templates

September 30, 2016

adopted in various domains such as power grids (e.g., [2, 3, 4]) building automa5

tion(e.g., [5, 6, 7]), and smart devices (e.g., [1, 8]) to address interoperability where it serves as a base for Seamless Integration Architecture [9]. Another standard that has been widely adopted in these domains (e.g., [10, 11, 12, 13, 14, 15]) is the Unified Modeling Language (UML) [16] which is the standard for modeling software systems. As witnessed above, the UML has rapidly expanded

10

its applicability to the major domains at which OPC UA aims and there has been an increasing overlap of the two standards in their coverage and use. However, the two standards OPC UA and UML have different notations which have caused confusion in understanding their notations. To the best of our knowledge, there is no existing work addressing the trans-

15

formation of UML to OPC UA. The most relevant work is mapping IEC 61850 and CIM (which are the standard data models described in UML in the power domain) to OPC UA (e.g.,[2, 3, 17]). In their work, one mapping is defined between IEC 61850 elements and OPC UA elements and another mapping is defined between CIM elements and OPC UA elements. Based on the mappings,

20

they generate corresponding XML expressions describing OPC UA elements. Although IEC 61850 and CIM are described in UML, their mappings are driven by the semantics of IEC 61850 and CIM. Thus, the existing work does not address general mappings independent from any specific domain between UML and OPC UA.

25

In this work, we present a metamodeling approach for transforming OPC UA model instances to UML models. Specifically, we focus on OPC UA AddressSpace Model [1] which defines objects and related information provided by servers to clients. The corresponding part in UML is the Common Structure, Values, Classification, Simple Classifier, and Structured Classifier models [16])

30

which define structural aspects of UML. Thus, we focus on these models. Within the scope, we analyze the semantics of involved OPC UA and UML elements and establish mappings between them with rigorous rationales. Based on the mapping, we define transformation algorithms using Query/View/Transformation (QVT) [18], a de-facto standard for model transformation by Object Man2

35

agement Group (OMG). We demonstrate transformation through three case examples, the first one in the power grid domain, the second one in the building automation domain, and the third one in the smart device domain. The first and second examples demonstrate the transformation from OPC UA to UML, while the third one shows the opposite from UML to OPC UA. Major contri-

40

butions of this work include the definition of a general mapping between OPC UA and UML which can be used across different domains, rigorous reasonings about mapping definitions based on a semantic analysis of involved elements, use of the standard transformation language QVT for describing transformation algorithms, and support for bi-directional transformation.

45

The rest of the paper is organized as follows. Section 2 gives an overview of OPC UA and UML. Section 3 analyzes the semantics of OPC UA and UML elements and defines mappings between them. Section 4 describes QVT transformation algorithms for bi-direction transformation from OPC UA to UML and vice versa. Section 5 demonstrates the three case examples in the power grid,

50

building automation, and smart device domains. Section 6 discusses related work. Section 7 concludes the paper.

2. Background In this section, we give an overview of UML and OPC UA in terms of metamodels and model elements. 55

2.1. OPC Unified Architecture OPC UA is an industrial automation standard to exchange information and control for industrial domains (e.g., manufacturing system domain, power system domain). In the context of a smart grid, OPC UA is a promising standard for improving the interoperability in “National Institute of Standards and

60

Technology (NIST) Framework and Roadmap for Smart Grid Interoperability Standards” [19] and International Electrotechnical Commission (IEC) technical committee (TC) 57 Architecture Seamless Integration Architecture [9].

3

OPC UA unified classic OPC which uses distributed component object model (DCOM) based on Microsoft Windows platform to operate systems platform65

independently. Figure 1 shows OPC UA standard specifications. OPC UA specifies the information model, the message model, the communication model, and the conformance model in the standard. These models facilitate to exchange messages between clients and server over various network environments for various kinds

70

of systems and devices. The OPC UA information models represent structure, behavior, and semantics of OPC UA server. The AddressSpace in an OPC UA server is a set of Nodes, which is exposed to clients. The Address Space model is a metamodel of the OPC UA AddressSpace.

Core Specification Parts

Access Type Specification Parts Part 8 – Data Access Part 9 – Alarms & Conditions Part 10 – Programs Part 11 – Historical Access

Part 1 – Overview & Concepts Part 2 – Security Model Part 3 – Address Space Model Part 4 – Services Part 5 – Information Model Part 6 – Service Mappings Part 7 – Profiles

Utility Specification Parts Part 12 – Discovery Part 13 – Aggregates

Figure 1: Structure of the OPC UA [1]

Table 1 shows notations for OPC UA Nodes which are used to visualize OPC 75

UA AddressSpaces. OPC UA notation differs from UML notations. In the table, shaded diagrams indicate types of objects, variables, and references, and italic fonts are used for abstract types. Note that, the Node is a component used for building AddressSpace which is exposed to clients. Table 2 shows the reference notations.

80

The followings describe components of references. • The SymmetricReferenceTypes are represented as links between nodes with closed and filled arrows pointing to the connected nodes. 4

Table 1: Node OPC UANotation Node Notation Table 1: OPC UA [1][1]

Name

Notation

Object

Object

ObjectType

ObjectType

Variable

Variable

Table 1: OPC UA Node Notation [1]

Name VariableType Object

ReferenceType ObjectType Variable DataType

Notation VariableType

Object

ReferenceType ObjectType

Variable DataType

VariableType

VariableType

Method ReferenceType

ReferenceType

ViewDataType

Method

DataType

View

Method

Method

View

View

Table 2: OPC UA Reference Type Notation [1] Table 2: OPC UA Reference Type Notation [1]

Table 2: OPC UA Reference Type Notation [1] Reference Type Notation

Reference Type

Symmetric Reference Symmetric Reference TypeType Asymmetric Reference Type

Asymmetric Reference Type

Hierarchical Reference Type

Hierarchical Reference Type

Notation

ReferenceType ReferenceType ReferenceType

ReferenceType ReferenceType

ReferenceType

• The AsymmetricReferenceTypes are represented as links between nodes with a closed and filled arrow pointing to the target node. 5 85

• Other hierarchical reference types are subtypes of the HierarchicalRefer-

• The AsymmetricReferenceTypes are represented as links between nodes ences. with a closed filled arrow pointing the target node.values OPCand UA has concrete reference in Table 3.to The IsAbstract attribute of these reference types are true. Note that when the IsAbstract attribute and

target node. Table UA Notation Reference Table 3: OPC 3: UAOPC Reference [1] Notation [1]

Reference

Notation

InverseName

HasComponent

ComponentOf

HasProperty

PropertyOf

HasTypeDefinition

Defines

HasSubtype

SubtypeOf

HasEventSource

EventSourceOf

• The HasComponent reference is used for the ObjectType, the Object, the

• The AsymmetricReferenceTypes are represented as links between nodes

VariableType, and the Variable. Reversely, these nodes can be compo-

with a closed and filled arrow pointing to the target node.

nents. Note that, in the Figure 4, we use different reference name for the 95

85

HasComponent reference since Eclipse does not allow the same reference

• Other hierarchical reference types are subtypes of the HierarchicalRefer-

names to identify clearly references.

ences.

• The HasProperty reference is used for the Base and its inherited classes.

OPCVariable UA has concrete reference in Table 3. The IsAbstract attribute values The is used as a property.

of these reference types are true. Note that when the IsAbstract attribute and • The HasTypeDefinition reference is used to indicate the types of the Object

100

90

the and Symmetric attribute are false, a reference type can have the InverseName the Variable. attribute’s value. The InverseName attribute provides different role name from • The HasSubtype reference is used for sub types. It should be noted that

target node. sub classes know their super classes in UML. However, super classes know their sub classes.

• The HasComponent reference is used for the ObjectType, the Object, the

• The HasEventSource is used for the Object as an event notifier.

VariableType, and the Variable. Reversely, these nodes can be compo-

105

95

nents. Note Language that, in the Figure 4, we use different reference name for the 2.2. Unified Modeling since Eclipse doesManagement not allow Group the same reference UMLHasComponent [16] is the standardreference modeling language by Object (OMG) for developing softwareclearly systems.references. UML is defined in three-tier infrastrucnames to identify ture metamodel level (M2), model level (M1), and object level (M0). The M2

• The HasProperty reference is used for the Base and its inherited classes. The Variable is used as a 6property. • The HasTypeDefinition reference is used to indicate the types of the Object 100

and the Variable. • The HasSubtype reference is used for sub types. It should be noted that 6

sub classes know their super classes in UML. However, super classes know their sub classes. • The HasEventSource is used for the Object as an event notifier. 105

2.2. Unified Modeling Language UML [16] is the standard modeling language by Object Management Group (OMG) for developing software systems. UML is defined in three-tier infrastructure metamodel level (M2), model level (M1), and object level (M0). The M2 level defines the abstract syntax for models at M1 whose elements are instances

110

(classes) of the metaclasses at M2. Similarly, a model at M1 captures the abstraction of object models at the M0 level whose elements are instances (objects) of the classes at M1. Figure 2 shows the three-tier infrastructure where the topdown describes instance relationships and the bottom-up represents metamodel relationships. In this work, we focus on the Classification model (Section 9) in

115

UML which corresponds to the OPC UA Address Space Model. M2

Metaclass meta instance

M1

Class meta instance

M0

Object

Figure 2: Three Tier Architecture

Figure 5 shows an example of a UML class diagram describing assess management in the power system domain. The diagram defines two classes Asset and Location which are associated each other. The Asset class captures tangible utility resources such as power system equipment, cabinets, and buildings in 120

terms of properties such as address, condition, and lifecycle. The Location class describes the location information (e.g., addresses, phone numbers) of assets. 7

Asset Location mainAddress : StreetAddress secondaryAddress : StreetAddress phone1 : TelephoneNumber phone2 : TelephoneNumber status : Status type :String

Location

0..* Assets

0..1

electronicAddress : ElectronicAddress initialCondition : String lifecycle : :LifeCycleDate lotNumber : String purchasePrice : Money serialNumber : String status : Status type : String utcNumber : String

Figure 3: UML Class Diagram

Table 4 shows notations for relationships in UML. The Association describes how a class is associated another class. The Association has an association name and role names at the ends of the Association. The Aggregation and Composition 125

are specialized associations. Although they are the kinds of associations, they differently capture a whole-part relationships. The Generalization represents a hierarchical relationship (super class and sub class) between classes. The Dependency is a relationship between two classes when a change of a class affects another class.

130

3. Mapping UML to OPC UA In this section, we analyze the correspondence between OPC UA elements and UML elements in terms of data entities, relationships, and data types. The analysis focuses on the Address Space model in OPC UA and its corresponding part the Classification model in UML.

135

3.1. Data Entity Mapping Figure 4 shows the OPC UA nodes defined in the Address Space Model [1]. The Base node is the base of the Address Space Model, inheriting its properties

8

status : Status type : String utcNumber : String

status : Status type :String

Figure 3: UML Class Diagram

4: Relationships in UML Table 4: Table Relationships in UML

Relationship

Notation

Association

Association name role name A role name B

Generalization Aggregation Composition Dependency

(e.g., NodeID, name) to other nodes. Nodes are of different types including Ob-

130

3. Mapping UML to OPC UA

ject, Variable, Method, ObjectType, VariableType, ReferenceType, and DataType,

140 and View. In the following, we analyze each node type to be mapped to a corIn this section, we analyze the correspondence between OPC UA elements

responding UML element.

and UML elements in terms of data entities, relationships, and data types. The analysis focuses on the Address Space model in OPC UA andObjectType its corresponding part the Classification model in UML. Base ReferenceType

Object

NodeID: EString name: EString

135

3.1. Data Entity Mapping

VariableType

Figure 4 shows the OPC UA nodes defined in the Address Space Model [1]. Method

DataType

View

Variable

The Base node is the base of the Address Space Model, inheriting its properties (e.g., NodeID, name) to other nodes. Nodes are of different types including ObFigure 4: OPC UA Nodes

8 ObjectType to Class. The ObjectType node is the type definition used to define a type with properties (e.g., variables, methods) which are populated in instances of the type. Figure 5(a) shows the abstract syntax of the ObjectType node. The 9

145

HasSubType relationship on the node specifies the hierarchy of object types. Given that, we identify the Class class in UML corresponding to the ObjectType node. Figure 5(b) shows the Class class [16].

Classifier 1 * HasSubTypee

ObjectType Class isAbstract : Boolean isFinalSpecialization : Boolean

IsAbstract : Boolean

(a) ObjectType in OPC UA

(b) Classifier in UM

Figure 5: OPC UA ObjectType and UML Class

The Class is a subclass of the Classifier class which specifies classifiable entities (e.g., classes, use cases). The Class class is a specialized classifier in that 150

its instances have a set of features (e.g., properties, operations) which correspond to the properties of an instance of the ObjectType node. The Class has the isAbstract and isFinalSpecification attributes inherited from the Classifier class. The isAbstract attribute is set to true to specify an abstract class and the isFinalSpecialization attribute is set to true to denote a final concrete class.

155

Object to InstanceSpecification. The Object node in OPC UA captures instances of a type (e.g., systems, components) which is further an instance of the ObjectType node. Figure 6(a) shows the relationships between the Object node and the ObjectType node. The HasTypeDefinition relationship specifies that the ObjectType node defines a set of types whose instances are instances of the Object

160

node. The HasObjectComponent relationship specifies the reverse relationship that an instance of the Object node has as its type an instance of the ObjectType node. An Object instance may have a specific value for its attributes which are also Object instances. Thus, the Object node should have a self-relationship capturing that. To address this, we added a self-relationship on the Object node 10

165

in the figure. ObjectType *

Class

1 HasTypeDefinition

*

HasObjectComponent *

classifier

instanceSpecification *

*

Object

newly added

(a) OPC UA Object

InstanceSpecification

(b) UML InstanceSpecification

Figure 6: OPC UA Object and UML InstanceSpecification

Based on the relationships in Figure 6(a), we identify the InstanceSpecification class in UML corresponding to the Object node. Figure 6(b) shows the InstanceSpecification class [16]. The InstanceSpecification class specifies instances of a classifier which is an instance of the Classifier class. Based on 170

the correspondence of Class to ObjectType and InstanceSpecification to Object, the relationship between the two classes semantically matches the instance relationship between the ObjectType and Object. The multiplicity “*” on each association end specifies that zero or more instances of the class are associated with one instance of the other class in the relationship.

175

Variable to Property. The Variable node in OPC UA denotes run-time values in instances of the ObjectType and Object nodes. Depending on the ability to contain other variables, a variable can be either a data variable or a property. A data variable is an instance of the DataVariable node which is a structured variable containing other variables, while a property is an instance of the Prop-

180

erty node which is a non-structured variable representing simply an engineering value (e.g., startTime). Figure 7(a) shows the Variable node. The OPC UA metamodel defines a relationship between the Variable node and the Object node. However, the relationship is not necessary as the Variable node already has a relationship with the ObjectType node. Thus, we do not consider the

11

185

relationship in this work, which is denoted as a dotted line in the figure. ownedA te ownedAttribute

Class

ObjectType *

0..1 clas class

Property * definingFeature

*

Variable * removed

1

HasVariableComponent HasOwnComponent owningInstance

HasVariableComponent *

InstanceSpecification

Object

1

(a) OPC UA Variable

* slot

* slot

Slot

(b) UML Property

Figure 7: OPC UA Variable and UML InstanceSpecification

The values represented by the Variable node correspond to attributes in UML class diagrams which are captured by the Property class in UML. Thus, the Variable node is mapped to the Property class which is shown in Figure 7(b). Note that OPU UA has the Attribute node defined which does not correspond 190

to any UML element. This node specifies metadata for node classes and has its own hierarchy defining various kinds of attributes. For example, the AccessLevel node is a child node of the Property node and it is associated with the Variable node to specify if the value of the variable is readable or writable. VariableType to Stereotyped Class. The VariableType node in OPC UA denotes

195

the type of a data variable. Figure 8(a) shows the node and its relationships to the Variable node. The type definition relationship is captured by the HasTypeDefinition association. Based on the semantics of the VariableType node, we identify it corresponding to the Class class in UML, but with a stereotype. The VariableType node

200

defines a type for structured entities similar to objects in UML, which justifies it to be mapped to the Class class. However, the Class class is already mapped to the ObjectType node in the above and OPC UA specifies ObjectType separate

12

HasSubType

VariableType *

Class

1 HasTypeDefinition

HasComponent *

*

class

ownedAttrubute

0..1

*

Property

Variable

(a) OPC UA VariableType

(b) UML DataType

Figure 8: OPC UA VariableType and UML DataType

from VariableType. Thus, we avoid mapping the ObjectType and VariableType nodes to the same class and attach a stereotype  VariableType  to the Class 205

class for the VariableType node. Figure 8(b) shows the Class class associated with the Property class. Note that the PropertyType node which defines the type of the Property node (a kind of the Variable node) corresponds to the DataType class in UML. Method to Operation. The Method node specifies functions whose scope is bounded

210

by the owning Object or ObjectType instances. Figure 9(a) shows the Method node in relation to the Object and ObjectType nodes. The OPC UA specifically describes the Method node as methods are “similar to the methods of a class in object-oriented programming”. Given that, we map the Method node to the Operation class which is the abstraction of implementation methods. Figure 9(b)

215

shows the Operation class specified as an owned operation of the Class class and a specification of the Behavior class capturing implementation methods. Figure 10 visualizes the mapping defined in the above. 3.2. Relationship Mapping In OPC UA, relationships are referred to as references which are captured

220

by the ReferenceType node. Figure 11 shows the syntactic definition of the Ref13

ObjectType

Class

class

Operation

*

0..1

*

specification 0..1

* HasMethodComponent ownedOperation

Method

* *

method

Behavior

HasMethodComponent

Object

*

(a) OPC UA Method

(b) UML Operation

Figure 9: OPC UA Method and UML Operation

OPC UA

UML

ObjectType

Class

Object

InstanceSpecification

VariableType

Association

Variable

Generalization

ReferenceType

Operation DataType

DataType

Property

Method Figure 10: Mapping UML and OPC UA

erenceType node. The definition specifies that a reference type has attributes of Symmetric, InverseName, and IsAbstract. The Symmetric attribute specifies the reference symmetric, and the InverseName attribute specifies the inverse reference (see Table 3), and the IsAbstract attribute denotes the reference ab225

stract. Reference types may be structured in a subtype hierarchy which is captured by the  reference  association. This classifies reference types into HierarchicalReferences and Non-HierarchicalReferences which are shown in Figure 12. The NonHierarchicalReferences node, which is abstract, and its subtypes

230

capture non-hierarchical relationships. The subtypes include HasModelParent,

14

Attribute

Symmetric

Attribute

ReferenceType HasSubtype*

InversName

1

Attribute

IsAbstract

Figure 11: OPC UA ReferenceType

GenerateEvent, HasEncoding, HasModelingRule, HasDescription, and HasTypeDefinition, each having a specific context. The HierarchicalReferences node, which is abstract, has as direct subtypes the HasEventSource and Organizes nodes which are concrete and the HasChild node which is abstract. The HasEv235

entSource node captures event generation from a source to a notifying node in a non-looping structure. It has a subtype of HasNotifier specifying the structure of notifiers (i.e., relating a notifier to other notifiers). The Organizes node signifies organizing nodes in a non-looping hierarchy. The HasChild node signifies non-looping hierarchies. It has the Aggregate and HasSubType nodes as its

240

subtypes. The Aggregate node is abstract, capturing “belong-to” relationships between a target node and a source node where the target node is viewed as a part of the source node (without ownership). On the other hand, the HasSubType node specifies subtype relationships of types. The Aggregate node is further classified into HasProperty capturing the ownership of node properties

245

and HasComponent capturing the part-of relationship between a target node and a source node (with no ownership specified). Both nodes are concrete. The HasComponent node has a subtype of HasOrderedComponent which defines ordered subtypes. Note that in this work, we renamed the HasComponent reference between the ObjectType and Object to HasObjectComponent (see Fig-

250

ure 6), the one between the ObjectType and Variable to HasVariableComponent (see Figure 7), and the one between the ObjectType and Method to HasMethodComponent (see Figure 9) to avoid name conflicts in the name space. Also note that we only consider concrete nodes in mapping to UML elements because 15

model transformation concerned in this work involves only instances of concrete 255

elements. Reference

NonHierarchicalRefernces

HierarchicalReferences

HasEventSource

HasChild

Organizes HasModelParent

HasNotifier

GeneratesEvent Aggregates

HasSubtype HasEncoding

HasProperty

HasModellingRule

HasComponent

HasDescription HasTypeDefinition

HAsOrderedComponent

Figure 12: OPC UA Reference Types

UML defines Association, Generalization, and Substitution. Figure 13 shows the UML metamodel for these relationships. The Association class, which is a child of the base relationship class Relationship, captures associations, aggregations, and compositions. An instance of the Association class has two ends 260

which are defined as properties of the classes associated by the instance. The type of the instance is specified in the aggregation attribute in the Property class. The AggregationKind enumeration defines three possible types – none, shared, and composition indicating respectively association, aggregation, and composition. The Generalization class, which a subclass of the DirectedRela-

265

tionship class, specifies generatlization/specificalization relationships between classes, which forms a class hierarchy for inheritance. The Substitution class, which is a subclass of the Realization class, specifies compliance relationships between a contract classifier (e.g., interfaces) and a substituting classifier (e.g., concrete classes).

270

In the analysis of corresponding UML elements, we found that there is no matching UML element for the ReferenceType node. This is because the Ref16

Class

specific * generalization

Generalization

DirectedRelationship

1

<>

class

0..1 1

substitutingClassfier

AggregationKind

* substitution

none shared composite *

ownedAttribute

Substitution

Realization

Association

Relationship

ownedEnd

Property

0..1

aggregation : AggregationKind = none * owningAssociation

Figure 13: UML Relationship Metamodel

erenceType node simply serves as the type for the predefined references in Figure 12 which are instances of the ReferenceType node. However, in UML, relationship types (e.g., Association, Generalization) are defined as subtypes of the 275

Relation class, not its instances. Thus, ReferenceType cannot be mapped to the Relation class. On the other hand, the predefined references in OPC UA can be mapped to subtypes of the Relation class. However, this mapping is defined over different levels – the instance level in OPC UA and the metamodel level in UML.

280

Subtypes of NonHierarchicalReferences, Organize, HasEventSource, and HasNotifier to Association. The NonHierarchicalReferences node specifies non-hierarchical relationships and its subtypes (e.g., HasModelParent, GenerateEvent) carry a specific context. For instance, the HasModelParent node is used to expose the ModelParent of an Object which defines the scope where the

285

Object is defined. They can be viewed as associations in UML. At the metamodel level, the Association class does not carry any specific context. Thus, the specific context carried by the subtypes of the NonHierarchicalReferences is not captured in UML. However, if desired, this can be addressed by simply defining a stereotype for each subtype (e.g.,  HasModelParent ).

290

We also found that hierarchical nodes of Organize, HasEventSource, and HasNotifier correspond to the Association class. The semantics of these nodes 17

are domain-specific, which cannot be captured in UML as UML is not specific to any domain. Thus, they can be viewed simply as associations. Note that in this mapping, the aggregation attribute of the Association class is set to none 295

in the AggregationKind enumeration. HasSubType to Generalization. Per the semantics in the above, the HasSubType node captures subtype relationships (inheritance) of types, which corresponds to the semantics of the Generalization class in UML. HasProperty, HasComponent, and HasOrderedComponent to Aggregation. The

300

HasProperty node specifies the relationship between an owned property and the owning node. This can be viewed as the whole-and-part relationship captured by aggregation in UML where the owning node is whole and the owned property is a part. The HasComponent node and its subtype HasOrderedComponent define part-of relationships without ownership. This semantics is closer than

305

that of HasProperty to UML aggregation. Note that UML aggregation does not specify about ownership. OPC UA specifically states that lifetime dependency on HasComponent between the target node and the source node is not specified. Thus, we do not map the node to composition in UML which requires lifetime dependency. The subtype HasOrderedComponent of HasComponent imposes an

310

order on part-of relationships. UML aggregation does not consider ordering on parts. Thus, the ordering constraint should be specified separately (e.g., OCL expressions). Note that per the UML metamodel in Figure 13, UML Aggregation is defined as the Association class with the aggregation attribute set to shared in the AggregationKind enumeration. Given that, Aggregation can be viewed

315

as a specialization of Association. Therefore, HasProperty, HasComponent, and HasOrderedComponent can also be mapped to Association. Figure 14 shows the relationship mapping. 3.3. Data Type Mapping OPC UA data types are defined as instances of the DataType node. Figure 15

320

shows the abstract syntax of the node. The DataType node is associated with 18

OPC UA

UML

Subtypes of NonHierarchicalReferences, Organize, HadNotifier, HaveEventSource

Association

HasSubType

Generalization

HasProperty HasComponent

Aggregation

HasOrderedComponent Figure 14: Mapping UML and OPC UA Reference

the IsAbstract attribute which defines an abstract data type. The HasSubType association in the syntax captures structured data types. DataType

Attribute

IsAbstract HasSubtype *

1

Figure 15: OPC UA DataType

Figure 16 shows the structure of standard data types in OPC UA. BaseDataType is the root type and all other types are defined as its subtypes. In the 325

structure, the BaseDataType, Enumeration, Image, Number, Integer, Structure, and UInteger types are abstract (whose IsAbstract is set) and other are concrete. The NodeId type is a structured type that identifies a node within a server. The Qualified type is a structured type that contains a quality name. The LocaleId type is a string that specifies language/county/region. The LocalizedText type is

330

a structured type that specifies translated strings. The ByteString type defines a sequence of Byte values. The DateTime type defines a Gregorian calendar date. The Duration type defines a time interval in milliseconds. The IdType type is an enumeration that identifies the IdType of a NodeId. The Image type and its subtypes define a ByteString representing an image in various formats.

335

The TimeZoneDataType type defines the local time. The NamingRuleType type

19

defines the NamingRule as an enumeration The NodeClass type defines a NodeClass as an enumeration The UtcTime type defines Coordinated Universal Time (UTC) values. The XmlElement type defines XML elements. Other types are self-descriptive. NamingRuleType Localized

NodeId

Argument

QualifiedName

Text

IdType Enumeration

NodeClass

String

XmlElement

Integer

LocaleId

SByte

Int16

Int32

Number

Double

Int64

Image GIF

Structure

BaseDataType

Boolean

Float

Duration

Image BMP

Guid

UInteger

Byte

UInt16

Image PNG

TimeZoneDataType

DateTime

ByteString

UtcTime

Image

UInt32

UInt64

Image JPG

Figure 16: OPC UA DataTypes

340

Figure 17 shows the structure of UML data type classes. The DataType class is a kind of classifier whose instances are identified only by their value. Thus, all the instances having the same value are considered to be equal. An instance of DataType may have properties and the instance is called a structured data type. It may also have operations manipulating the values of properties. The

345

DataType class has subclasses of Primitive and Enumeration. The Primitive class defines predefined data types without substructure. They include Integer, Boolean, String, UnlimitedNatural, and Real. The UnlimitedNatural type defines the infinite set of natural numbers plus the unlimted value which is represented using an asterisk. Other types are self-descriptive. The Enumeration class

350

defines an enumeration whose values are user-defined enumeration literals which are instances of the EnumerationLiteral class. Given that, we establish the following mapping.

20

Classifier

Property DataType

datatype * 0..1 ownedAttribute datatype * 0..1 ownedOperation

PrimitiveType

Enumeration

Operation

1 enumeration 1 classifier

ownedLiteral *

InstanceSpecification

EnumerationLiteral

enumerationLiteral *

Figure 17: UML Datatype Metamodel

Subtypes of Structure to DataType. The subtypes (e.g., NodeId, Qualified) of the Structure type are structured types which can be mapped to the DataType 355

class in UML. In this mapping, instances of the DataType are required to have properties that match the structured properties of the OPC UA types. Subtypes of Integer and UInteger and DateTime to Integer. The subtypes of Integer and UInteger define integers of different sizes and they all can be mapped to the Integer type in UML which defines an infinite set of integers. DateTime

360

in OPC UA represents a Gregorian calendar date as a 64-bit signed integer. Thus, it can be mapped to the Integer type in UML. Boolean to Boolean. OPC UA Boolean defines either TRUE or FALSE, which corresponds to UML Boolean whose instance is either true or false. String to String. The String type in OPC UA defines a Unicode character string

365

excluding non-whitespace control characters. This corresponds to the String type in UML which defines a sequence of characters including non-Roman alphabets. It is not specified whether control characters are included or not. 21

Float and Double to Real. OPC UA Float and Double define respectively the Single Precision (32 bits) and the Double Precision (64bits) in IEEE 754-1985. 370

This corresponds to Real in UML which represents real numbers. This type is typically implemented using a floating point standard such as ISO/IEC/IEEE 60559:2011 whose content is identical to the predecessor IEEE 754 standard [16]. Subtypes of Enumeration to Enumeration. The subtypes of Enumeration type in OPC UA define a list of values. This corresponds to the Enumeration class

375

where the list of values in the OPC UA enumeration types match the enumeration literal in UML enumerations. Figure 18 visualizes the data type mapping.

OPC UA

UML

Boolean Float Double Subtypes of Integer Subtypes of UInteger DateTime String Enumeration Structure

Boolean Real Integer String Enumeration Datatype

Figure 18: Mapping UML and OPC UA Datatypes

4. QVT Transformation In this section, we describe model transformation between OPC UA models 380

and UML models using QVT. We considered QVT [18] and ATL [20] and chose QVT as the base transformation platform because it is a standard for transforming models by OMG which also defines the UML. Thus, QVT has better compatibility with the UML. Also, QVT have been more widely adopted. In the power domain, QVT has also been adopted by IEC 62361 [21], which has

385

been drafted by WG19, for specifying mappings between IEC 61850 and IEC

22

61970 which would foster its adoption to other related IEC standards such as IEC 61968. Figure 19 illustrates the transformation process. The process involves two layers – metamodel layer (M2) and model layer (M1). M2 defines the mapping between the OPC UA metamodel and the UML metamodel and a set 390

of transformation rules describing how an instance of the OPC UA metamodel should be transformed to an instance of the UML metamodel at M1. In the rest of the section, we describe the transformation of OPC UA to UML and the opposite transformation of UML to OPC UA based on the mapping established in Section 3. M2 OPC UA Metamodel

Mapping

Conforms to

UML Metamodel

Conforms to

Conforms to

M1 OPC UA Instance

Transformation

UML Instance

Figure 19: Model-to-Model QVT Transformation

395

4.1. Transforming OPC UA to UML In this subsection, we describe the transformation from OPC UA to UML in terms of transformation initialization and data entity transformation. 4.1.1. Transformation Initialization Listing 1 shows the initiation of transformation declaring the OPC UA meta-

400

model and UML metamodel and their Uniform Resource Identifier (URIs). The main() operation initiates the transformation using the Model entity as the root element to consolidate all the involved elements in the input model. Listing 1: Transformation Initialization

405

1

modeltype OPCUA ’strict’ uses ’http://opcua/1.0’;

2

modeltype UML ’strict’ uses ’http://www.omg.org/spec/UML/20110701’;

3

transformation opc2uml(in opcua:OPCUA, out uml:UML);

4

main() {

23

5

assert fatal(opcua.rootObjects()[OPCUA::Model]->notEmpty()) with log("There is no root

6

opcua.rootObjects()[OPCUA::Model]->map toUMLModel();

.");

410

7

}

Listing 2 defines the abstract ToNamedElement() operation which specifies the transformation of OPC UA Base to UML NamedElement. The transformation is carried out by mapping the attributes of the Base to the corresponding attributes in the NamedElement. For example, the name (self.name) of the Base 415

instance is mapped to the name (result.name) of the NamedElement instance. Listing 2: Transforming OPC UA BaseNode to UML NamedElement 1 2 3

abstract mapping OPCUA::Base::ToNamedElement():UML::NamedElement{ result.name:=self.name; }

Listing 3 defines the toUMLModel() operation to transform an OPC UA 420

ObjectType instance to a UML Class instance per the mapping of ObjectType to Class in Section 3. In line 3-5, a package is created to contain the classes transformed in line 6 which carries out the transformation of OPC UA ObjectType instances to UML Class instances. Listing 3: Transforming UML Model to OPC UA Model 1

425

mapping OPCUA::Model::toUMLModel():UML::Model{

2

name:="Model_"+self.name;

3

var package:=object Package{

4

430

name:=’package’;

5

};

6

package.packagedElement += self.nodes[OPCUA::ObjectType]->map ObejctTypeToClass();

7 8

result.packagedElement += package; }

4.1.2. Data Entity Transformation Listing 4 shows the ObejctTypeToClass() operation which is responsible for transforming OPC UA ObjectType to UML Class by mapping associations of Ob435

jectType to the corresponding attributes in Class. Line 2 carries out the transformation of an HasObjectComponent association to a class property using the ObjectToProperty() operation defined in Listing 5. In the line, self.HasObjectComponent 24

returns an Object instance which is transformed to a Property instance in UML through the operation. The transformed property is then added to the trans440

formed class. Note that per the mapping in Figure 10, OPC UA Object is mapped to UML InstanceSpecification which is associated with Property through Slot in Figure 7. Thus, the ObjectToProperty operation conforms to the defined mapping. Line 3 transforms an HasVariableComponent association to a class property using the VariableToProperty() operation in Listing 7. Listing 4: Transforming OPC UA ObjectType to UML Class

445

1

mapping OPCUA::ObjectType::ObejctTypeToClass():UML::Class inherits OPCUA::Base:: ToNamedElement{

2 3 4

result.ownedAttribute += self.HasObjectComponent->map ObjectToProperty(); result.ownedAttribute += self.HasVariableComponent->map VariableToProperty(); }

Listing 5 defines the ObjectToProperty operation for transforming OPC UA

450

Object to UML InstanceSpecification. Line 2 identifies a UML Class instance that has the same name as the name of the ObjectType instance that is referenced by the name attribute of the HasTypeDefinition association in the OPC UA Object instance. If no class exists having the same name, the ObjectType instance 455

is transformed to a corresponding Class instance in line 3. The transformed Class instance is set to the classifier of InstanceSpecification in line 5. Line 6 creates an instance of the Slot class for the transformed InstanceSpecification instance to be represented as a property of the Class instance transformed in line 3. Listing 5: Transforming OPC UA Object to UML InstanceSpecification

460

1

mapping OPCUA::Object::ObjectToInstanceSpecification():UML::InstanceSpecification inherits OPCUA::Base::ToNamedElement{

2 3

if (uml.objects()[Class]->selectOne(c|c.name=self.HasTypeDefinition.name)=null) then { opcua.objects()[ObjectType]->selectOne(ot|ot.name=self.HasTypeDefinition.name).map ObejctTypeToClass();

465

4

} endif;

5

result.classifier:=uml.objects()[Class]->selectOne(c|c.name=self.HasTypeDefinition.name );

6

470

var slot:=object Slot{

7

name:=result.name+’_slot’;

8

slot:=result;

25

9 10

}; result.owningInstance:=slot;

Listing 6 defines the VariableToProperty operation for transforming the OPC Variable instance to a corresponding UML Property instance and it can be 475

explained similarly to the ObjectToProperty operation in Listing 5. Listing 6: The VariableToProperty() Operation 1

mapping OPCUA::Variable::VariableToProperty():UML::Property inherits OPCUA::Base:: ToNamedElement{

2

if (uml.objects()[Class]->selectOne( c | c.name=self.HasTypeDefinition.name)=null) then

3

opcua.objects()[VariableType]->selectOne( vt | vt.name= self.HasTypeDefinition.name).

{ 480

map VariableTypeToClass(); 4 5 6

} endif; result.type:=uml.objects()[Class]->selectOne( c | c.name=self.HasTypeDefinition.name); }

Listing 7 describes the VariableTypeToClass() operation for transforming

485

OPC UA VariableType to UML Class. Line 2 transforms the HasComponent reference of VariableType to a class attribute. The OPC UA Variable node referenced by HasComponent is transformed to UML Property. Listing 7: Transforming OPC UA VariableType to UML Class 1

mapping OPCUA::VariableType::VariableTypeToClass():UML::Class inherits OPCUA::Base:: ToNamedElement{

490

2 3 4

result.ownedAttribute += self.HasComponent->map VariableToProperty(); result.ownedAttribute += self.dataType.map DataTypeToDataType(); }

Listing 8 specifies the DataTypeToDataType() operation which transforms 495

OPC UA DataType to UML DataType. If the data type has no properties, it is determined as a primitive type (i.e., Int32, float) and transformed to a UML primitive using the opcUAPrimitiveToUMLPrimitive() operation defined in Listing 9. Listing 8: Transforming OPC UA DataType to UML DataType 1

500

2

mapping OPCUA::DataType::DataTypeToDataType():UML::DataType{ if (self.HasProperty->isEmpty()) then {

3 4 5

result:=self.opcUAPrimitiveToUMLPrimitive(); } endif; }

26

Listing 9 defines the opcUAPrimitiveToUMLPrimitive() operation which re505

turns UML Integer for OPC UA Int32 and returns UML Float for OPC UA float. Listing 9: The opcUAPrimitiveToUMLPrimitive() Helper 1 2

510

helper OPCUA::DataType::opcUAPrimitiveToUMLPrimitive() :UML::DataType { return switch {

3

case (self->oclIsKindOf(Int32)) return self.map toInteger();

4

case (self->oclIsKindOf(float)) return self.map toFloat();

5 6 7

else assert fatal (self=null) with log(’It is not an available datatype’); }; }

4.2. Transforming UML to OPC UA In this subsection, we describe the opposite transformation from UML to

515

OPC UA in terms of transformation initialization and data entity transformation. 4.2.1. Transformation Initialization Listing 10 describes the initialization of transformation. In the initialization, 520

the metamodels of UML and OPC UA are declared in line 1-2 and the main() operation starts the model transformation at line 4. Line 6 specifies transforming every entity involved in the UML model to a corresponding OPC UA entity. Listing 10: Transformation Initialization

525

1

modeltype UML ’strict’ uses ’http://www.omg.org/spec/UML/20110701’;

2

modeltype OPCUA ’strict’ uses ’http://opcua/1.0’;

3

transformation uml2opc(in uml:UML, out opcua:OPCUA);

4

main() {

5 6 7

assert fatal(uml[UML::Model]->notEmpty()) with log("There is no root."); uml[UML::Model]->map toOpcuaModel(); }

The UML model might consist of multiple packages each containing a set of

530

classes. Listing 11 shows the transformation of the classes in each package. Listing 11: Transformation UML Package to OPC UA Model 1 2

mapping UML::Model::toOpcuaModel():OPCUA::Model{ name:="Model_"+self.name;

27

3

nodes+=self.packagedElement[UML::Package]->packagedElement[UML::Class]->map ClassToObjectType();

535

4

}

Listing 12 defines the abstract mapping operation for mapping the UML NamedElement metaclass to the OPC UA Base entity. Listing 12: Transformation UML NamedElement to OPC UA Base 1 540

abstract mapping UML::NamedElement::NamedElementToBaseClass():OPCUA::Base{

2

result.name:=self.name;

3

result.BrowseName:=self.namespace.name+"/"+self.name;

4 5

result.NodeID:=self.name; }

4.2.2. Data Entity Transformation Listing 13 defines the ClassToObjectType() operation which transforms an

545

instance of UML Class to an instance of OPC UA ObjectType. The operation involves transforming the owned attributes of the class. Owned attributes include the attributes that present the associations of the class. An attribute that captures an association is transformed to an OPC UA Object instance by 550

the AttributeToObject() operation (defined in Listing 14) in Line 2. Line 3 describes the transformation of a non-association attribute using the AttributeToVariable() operation (defined in Listing 16) which returns an OPC UA variable corresponding to the attribute. The returned variable also contains its type information set in the AttributeToProperty() operation. Note that unlike

555

the AttributeToObject() operation which is defined as a mapping operation, the AttributeToProperty() operation is defined as a helper operation which is not constrained by a mapping. Though they have different natures in use, both serve as transformation operations in this work. Line 4 sets the nodeClass attribute of the transformed OPC UA ObjectType instance to the ObjectType value in the

560

NodeClass enumeration in OPC UA. Listing 13: Transforming UML Class to OPC UA ObjectType 1

mapping UML::Class::ClassToObjectType():OPCUA::ObjectType inherits UML::NamedElement:: NamedElementToBaseClass{

28

2

result.HasObjectComponent+=self.ownedAttribute[association <> null]->map

3

result.HasVariableComponent+=self.ownedAttribute[association=null]->AttributeToProperty

4

result.nodeClass:=OPCUA::NodeClass::ObjectType;

AttributeToObject(); 565

();

5

}

Listing 14 defines the AttributeToObject() operation which is responsible for 570

transforming an instance of UML Property to an instance of OPC UA Object. Line 2 identifies the type of the UML Property instance using the getObjectType() query operation (defined in Listing 15) to set the HasTypeDefinition reference of the transformed OPC UA Object instance. Listing 14: Transforming UML Property to OPC UA Object 1

mapping UML::Property::AttributeToObject():OPCUA::Object inherits UML::NamedElement:: NamedElementToBaseClass{

575

2 3 4

result.HasTypeDefinition:=self.type.name.getObjectType(); result.nodeClass:=OPCUA::NodeClass::Object }

Listing 15 defines the getObjectType() operation to identify the name of the 580

UML Property instance to set the type of the transformed OPC UA Object instance. Listing 15: The getObjectType() Query 1 2

query String::getObjectType():OPCUA::ObjectType{ return opcua.objectsOfType(OPCUA::ObjectType)->select(type|type.name=self)->asSequence ()->at(1);

585

3

}

Listing 16 shows the AttributeToVariable() helper operation which creates an instance of OPC UA Variable for a non-association attribute. This also involves transforming the type of the attribute to an instance of OPC UA VariableType. A non-association attribute may have either a class or a primitive type as its 590

type. If the type is a class, the type of the transformed Variable instance is set to the name of the class by the defineVariableType() operation (defined in Listing 17), which is specified in Line 4. In the case of a primitive type, the type of the transformed Variable instance is set to null as OPC UA does not consider a primitive type as a VariableType which prevents a UML primitive type from 29

595

being transformed to an instance of OPC UA VariableType. This is specified in Line 5. Listing 16: The AttributeToVariable() Helper 1 2

600

helper UML::Property::AttributeToVariable():OPCUA::Variable{ var variable:=object OPCUA::Variable {

3

nodeClass:=OPCUA::NodeClass::Variable;

4

if(self.isPrimitive()=false) then HasTypeDefinition:=self.type.name.defineVariableType

5

else HasTypeDefinition:=null endif

(dataType)

6 7 605

8

}; return variable; }

Listing 17 defines the defineVariableType() operation for identifying the type of a given variable using the name of the variable’s type which is accessible via the navigation of self.type.name in Listing 16. The operation selects an instance of the VariableType whose name matches the name of the variable’s type. If 610

found, the instance is returned. This is specified in Line 2-4. Otherwise, an instance is created with its name set to the name of the variable’s type, which is specified in Line 6-12. Listing 17: The defineVariableType() Query 1

query String::defineVariableType(in datatype_of_variable :OPCUA::DataType):OPCUA:: VariableType{

615

2

if(opcua.objectsOfType(OPCUA::VariableType)->size()>0) then {

3

var variableType:=opcua.objectsOfType(OPCUA::VariableType)->select( type|type.name=

4

return variableType;

self )->asSequence()->at(1);

620

5

}

6

else {

7

var variableType:=object OPCUA::VariableType{

8

name:=self;

9

nodeClass:=OPCUA::NodeClass::VariableType;

10 625

HasComponent:=datatype_of_variable.HasProperty;

11

};

12 13 14 15

return variableType; }endif; return null; }

30

630

Note that UML is more general than OPC UA in context. This requires making a choice in mapping similar types of elements in OPC UA to a single element in UML. For instance, OPC UA defines several types of integers, but UML defines only one type for integers. Thus, one has to choose a specific type in OPC UA along with a justification. In such a case, the loss of OPC

635

UA specific information should be expected during transformation, which is inevitable.

5. Case Studies In this section, we present three case studies of transforming an OPC UA model to a UML model or vice versa based on the mapping defined in Section 3 640

and the transformation rules in Section 4. In the first case study, we demonstrate the transformation of an OPC UA model to a UML model in the power grid domain. The second case study demonstrates the transformation of an OPC UA model to a UML in the building automation domain. Lastly, the third case study presents the opposite transformation from a UML model to an OPC UA

645

model an OPC UA model in the smart device domain. 5.1. Case Study 1: IEC 61850 OPC UA has been adopted in the power domain to address the platformindependent interoperability issue [19]. Power domain applications (e.g., Substation Automation Systems [SASs], Distributed Energy Resources [DERs],

650

building automation systems) communicate with each other, which involves significant data exchanges to fulfill intended goals (e.g., efficiency, safety). This requires interoperability among involved systems, which has been identified as a high priority issue to be addressed. OPC UA is a promising solution to address the interoperation issue. UML has already been used in the power domain for

655

data modeling for substation automation in IEC 61850 [10] and for power management in IEC 61970 (also known as Common Information Model [CIM]) [11]. The overlap of the two standards in their coverage and use has been increasing

31

(e.g., see [2, 3, 4]), which brings up the need for model transformation between the standards to support their compatibility. 660

In this study, we demonstrate how the transformation, we use an OPC UA instance describing the IEC 61850 MMXU logical node. Figure 20 shows the model instance. The diagram defines two ObjectTypes MMXU representing the MMXU logical node and MV representing the MV common data class. The MMXU ObjectType is associated with an Object MMXU1 via a HasTypeDef-

665

inition reference. The MMXU1 Object consists of the totW, totVa, and totVar Objects which are instances of the MV ObjectType. The ownerships of totW, totVa, and totVar for MMXU1 are captured via the HasComponent references. The MV ObjectType defines a Variable instMag which is an instance of the AnalogueValueType VariableType which defines i and f Variables. The details

670

of OPC UA notations are described in Subsection 2.1. The diagram is drawn using UaModeler [22]. totW totVa

MMXU1

MV

totVar instMag

MMXU AnalogueValueType

i

f

Figure 20: OPC UA Representation of MMXU in IEC 61850

The OPC UA instance is represented into an Ecore model which is the input format to the QVT plug-in of Eclipse which is used in this work for model transformation. Figure 21 shows the Ecore model representation of the OPC 675

UA model in Figure 20. In the transformation, the MMXU ObjectType is transformed to the MMXU

32

platform:/resource/UML2OPC.model/model/opcua/OPCUAModel.xmi Model MMXU Object Type MMXU Object Type MV Variable subMag Structure AnalogueValue Variable Type AnalogueValue Object totVa Object totVar Object totW variable i Variable f Variable instMag Data Type Int32 Data Type Float Figure 21: OPC UA MMXU Ecore Model

class. The properties of the MMXU logical node are in turn transformed into classes. A tree view shows a structure of the MMXU logical node. The class diagram is generated from the given structure. Figure 22 shows the output 680

instance produced by the transformation. platform:/resource/OPC2UML.mode/model/opc2uml.xmi Model_MMXU package MMXU totVa : MV totVar : MV totW : MV MV subMag : AnalogueValue instMag : AnalogueValue AnalogueValue i f Figure 22: Ecore Model

Figure 23 shows the transformed class diagram. The diagram specifies that the MMXU logical node has three attributes (as associations) totVar, totW, and totVa whose type is the measured value (MV) common data class. The MV 33

class also has an attribute of instMag of the AnalogueValue type has an integer 685

attribute i and a float attribute f. MMXU

totVar

MV

totW

AnalogueValue instMag

totVa

i : integer f : float

Figure 23: The MMXU logical node

QVT generates a trace file for transformation which can be used as a tool for validating the transformation result. Figure 24 shows the transformation trace. In the figure, OPC UA ObjectType is transformed to UML Class which involves the removal of the nodeClass property of OPC UA ObjectType. 690

5.2. Case Study 2: BACnet OPC UA has been widely used in the building automation domain (e.g., [6, 7]). In particular, it has been accepted by the community of BACnet which is a standard for building automation systems [23]. At the same time, the UML has expanded its applicability to the same domain, which has led to increasing

695

initiatives (e.g., [12, 13]). In this case study, we demonstrate the transformation of the OPC UA model [23] that describes the BACnetAnalogInputType ObjectType in BACnet to a corresponding UML model. Figure 25 shows the model instance of the BACnetAnalogInputType ObjectType which represents sensor inputs (e.g., temperature, illuminance) in BAC-

700

net. BACnetAnalogInputType defines variables of deviceType, objectIdentifier, profileName, and presentValue whose types are respectively Device Type, Object Identifier, Profile Name, and Present Value. Figure 26 shows the Ecore model representation of the OPC UA model in Figure 25.

705

The transformation of the Ecore model produces the Ecore model shown in Figure 27 which represents the transformed UML model. The transformation

34

Transformed Transformed Transformed

toUMLModel (SELF: Model, Result: Model) in self : Model = Model org.eclipse.emf.impl.DynamicObjectImpl@315bb2bb Nodes : Base 0..* name : EString 1 A MMXU_Model out result : Model = Model Model_MMXU ObjectTypeToClass (SELF: ObjectType, Result: Class) in self : ObjectType = ObjectType org.eclipse.emf.impl.DynamicObjectImpl@7c9015c6 NodeID : EString 1 name : EString 1 A MMXU nodeClass : NodeClass 1 To be removed ObjectType = 8 out result : Class = Class MMXU ToNamedElement (SELF: ObjectType, RESULT: Class) ObjectToInstanceSpecification (SELF: Object, Result: InstanceSpecification) in self : Object = Object org.eclipse.emf.impl.DynamicObjectImpl@7c0rv15c6 NodeID : EString 1 name : EString 1 A totVa nodeClass : NodeClass 1 To be removed Object = 1 out result : InstanceSpecification = InstanceSpecification totVa : MV ToNamedElement (SELF: Object, RESULT: Property) ObjectTypeToClass (SELF: ObjectType, RESULT: Class) ToNamedElement (SELF: ObjectType , RESULT: Class) VariableToProperty (SELF: Variable, RESULT: Property) ToNamedElement (SELF: Variable, RESULT: Property) VariableTypeToClass (SELF: VariableType, Result: Class) in self : VariableType = VariableType org.eclipse.emf.impl.DynamicObjectImpl@5c01e5c6 out result : Class = Class AnalogueValue ToNamedElement (SELF: VariableType, RESULT: Class) VariableToProperty (SELF: Variable, RESULT: Property) ToNamedElement (SELF: Variable, RESULT: Property) VariableToProperty (SELF: Variable, RESULT: Property) ToNamedElement (SELF: Variable, RESULT: Property) Figure 24: Transformation Trace

35

deviceType objectIdentifier

Device_Type

Object_Identifier

BACnetAnalogInputType profileName presentValue

Profile_Name

Presnet_Value

Figure 25: OPC UA Representation of the AnalogInput Object in BACnet

platform:/resource/UML2OPC.model/model/opcua/bacnet.xmi Model BACnet Object Type BACnetAnalogInputType Variable Type Object_Idenfitier variable objectIdentifier Variable Type Profile_Name variable profileName Variable Type Present_Value variable presentValue Variable Type Device_Type variable deviceType Figure 26: OPC UA BACnetAnalogInputType Ecore Model

also produces a transformation trace (not shown) similar to the one in Figure 24 platform:/resource/OPC2UML.mode/model/opc/opc2uml.bacnet.xmi Model_BACnet package BACnetAnalogInputType deviceType : Device_Type objectIdentifier : Object_Identifier profileName : Profile_Name presentValue : Present_Value Device_Type Object_Identifier Profile_Name Present_Value Figure 27: The BACnetAnalogInputType Ecore Model

Figure 28 shows the transformed class diagram. In the diagram, the variables

36

in the BACnet model are transformed to associations (e.g., deviceType) and their 710

types are transformed into classes (e.g., Device Type). Device_Type v de

BACnetAnalogInputType

p Ty ice

f enti ctId obje

e

ier

Object_Identifier

pro

file Na me

Profile_Name

e alu tV

sen pre

Present_Value

Figure 28: The BACnetAnalogInputType Class

5.3. Case Study 3: Boiler System In this case study, we use a smart boiler system [24] in the smart device domain where UML is increasingly used (e.g., see [14, 15]). The system comes with computing capability, consisting of input and output pipes and a boiler 715

drum. Figure 29 shows the system. In the diagram, the Boiler class has as associations three attributes – inputPipe, boiledDrum, and outputPipe whose types are respectively the BoilerInputPipe, Drum, and BoilerOutputPipe classes. The BoilerInputPipe class is associated with the Valve class for controlling water flow.

720

Figure 30 shows the Ecore model representation of the UML Boiler model. Figure 31 shows the Ecore model representation of the transformed OPC UA model. Figure 32 shows the transformed OPC UA model. The transformation of the model results in the creation of the Boiler ObjectType whose objects (in-

37

BoilerInputPipe inp

Boiler

valve

Valve

ipe utP

boiler D

rum

Drum

p tPi tpu ou

BoilerOutputPipe

e

Figure 29: The Boiler Class

platform:/resource/OPC2UML.mode/model/uml/uml2opcua.Boiler.xmi Model_Boiler_Model package Boiler inputPipe : BoilerInputPipe outPutPipe : BoilerOutputPipe boilerDrum : Drum BoilerInputPipe valve : Valve BoilerOutputPipe Drum Valve Figure 30: The UML Boiler Ecore Model

725

stances of Object) are inputPipe, boilerDrum, and outputPipe. These objects are linked to the Boiler ObjectType via hasComponent references which capture their composition relationships. Note that although the attributes of the Boiler class are transformed to OPC UA objects due to the composition semantics, they can be alternatively transformed to OPC UA variables per the mapping in

730

Figure 10, The three classes of BoilerInputPipe, Drum, and BoilerOutputPipe in Figure 29 are transformed into instances of ObjectType which serve as types for the three objects of the Boiler ObjectType.

38

platform:/resource/UML2OPC.model/model/opcua/uml_toOPC_Boiler.xmi Model Boiler_Model Object Type Boiler Object Type BoilerInputPipe Object Type BoilerOutputPipe Object Type Drum Object Type Valve Object inputPipe Object valve Object outputPipe Object boilerDrum Figure 31: OPC UA BoilerType Ecore Model

Valve

valve

Boiler

inputPipe

BoilerInputPipe

boilerDrum

Drum

outputPipe

BoilerOutputPipe

Figure 32: OPC UA BoilerType

6. Related Work In this section, we review existing works (e.g., [2, 3, 4] which are all from the 735

same research group) on mapping IEC 61850 and CIM to OPC UA. IEC 61850 and CIM are the data model standards in the power system domain which are described in UML (with certain variations in IEC 61850). As they are described in UML, the existing work can be viewed as relevant to mapping UML (in the context of the power domain) to OPC UA. Their work can be divided into

740

mapping IEC 61850 to OPC UA and mapping CIM to OPC UA.

39

They studied semantic correspondence between CIM elements and OPC UA elements [2]. In the work, they defined a simple mapping that relates i) abstract CIM classes to OPC UA ObjectTypes, ii) concrete instances of abstract CIM classes to OPC UA Objects, and iii) CIM attributes to either OPC UA 745

Proprerits or DataVariables. However, no rationales are given for the mapping. Extending the previous work, they defined a mapping between IEC 61850 and OPC UA and demonstrate how the MMXU logical node in IEC 61850 can be represented in the OPC UA notation [17]. The mapping includes mappings of i) LN Classes, LNodeTypes, and CDC, to ObjectTypes, ii) LN and LN Data

750

to Objects, iii) CDC DataAttribute to Variable, and iii) CDC DataAttributeType to DataTypes where the first elements in the mapping are IEC 61850 elements and the second elements are OPC UA elements. However, their mapping accompanies little rationales, which makes it unclear how the mapping is established.

755

They implemented the mapping of CIM to OPC UA in an Enterprise Architecture add-in called CIMbaT [4] which generates XML representations of OPC UA NodeSet from a CIM model. The initial mapping introduced in the previous work [2] is extended by considering i) CIM generalizations mapped to OPC References, ii) CIM associations mapped to either OPC References or

760

ReferenceTypes, iii) CIM enumerations, data types, and compounds mapped to OPC DataTypes. CIMbaT is later on extended to UMLbaT [3] by combining the mappings of IEC 61850 and CIM together. In summary, the existing work mainly focuses on mapping IEC 61850 and CIM UML elements to OPC UA AddressSpace elements and generating OPC

765

UA NodeSet XML files. The defined mappings are simple with few rationales given as to how the mappings are established. Their mappings also require a selection to be made for some CIM elements that are mapped to multiple OPC UA elements. For example, they map CIM attributes to either OPC Priorities or DataVariables and CIM associations mapped to either OPC References or

770

ReferenceTypes. However, there are no guidelines as to how the selection should be made. Such additional decisions are required because the UML elements are 40

more general than OPC UA elements. The mappings are based on the semantics in 61850 and CIM rather than the semantics of UML itself. Thus, the application of their approach is limited to UML models of IEC 61850 and CIM.

775

7. Conclusion We have presented an approach for bi-directional transformation between OPC UA and UML. In the approach, we analyzed the semantics of OPC UA elements and mapped them to corresponding UML elements. Based on the mapping, we defined transformation algorithms described in QVT. We demonstrated

780

the approach using three case examples in the power grid, building automation, and smart device domains. A major contribution of this work is that the defined mapping for transformation is general enough to be used across different domains and it provides solid reasonings for the mapping based on a rigorous analysis of the semantics of the elements in OPC UA and UML. Another signifi-

785

cant contribution is that it demonstrates the feasibility of the approach through the implementation of the mapping using the standard transformation language QVT. The mapping between UML and OPC UA is defined at the metamodel level as required by QVT. However, we found that OPC UA elements are not fully

790

aligned with the layer infrastructure in UML. In UML, meta-elements define the syntax of UML modeling and only their instances are used in modeling. However, in OPC UA, both a type (a metamodel element) and its instances can be used together in modeling. This has forced the mapping of UML and OPC UA to be misaligned to some extent where some UML meta-elements (e.g.,

795

relationships) had to be mapped to instances of meta-elements in OPC UA. In QVT, we addressed this by considering the OPC UA instances as subtypes of their metatype, which is feasible from a metamodeling perspective. [1] IEC 62541, OPC Unified Architecture, V1.02, available at www.iec.ch (2010).

41

800

[2] S. Rohjans, M. Uslar, H. Appelrath, OPC UA and CIM: Semantics for the Smart Grid, in: Proceedings of IEEE PES Transmission and Distribution Conference and Exposition, 2010, pp. 1–8. [3] S. Rohjans, K. Piech, S. Lehnhoff, UML-based modeling of OPC UA address spaces for power systems, in: Proceedings of IEEE International

805

Workshop on Intelligent Energy Systems (IWIES), 2013, pp. 209–214. [4] S. Rohjans, K. Piech, M. Uslar, J. Cabadi, CIMbaT - Automated Generation of CIM-based OPC UA-Address Spaces, in: Proceedings of IEEE International Conference on Smart Grid Communications, 2011, pp. 416– 421.

810

[5] ASHRAE, Standard 135 BACnet - a data communication protocol for building automation and control networks, available at www.ashrae.org. [6] A. Fernbach, W. Granzer, W. Kastner, Interoperability at the management level of building automation systems: A case study for BACnet and OPC UA, in: Proceedings of the 16th IEEE Conference on Emerging Technolo-

815

gies Factory Automation (ETFA), 2011, pp. 1–8. [7] W. Granzer, W. Kastner, Information modeling in heterogeneous Building Automation Systems, in: Proceedings of the 9th IEEE International Workshop on Factory Communication Systems (WFCS), 2012, pp. 291–300. [8] G. Cndido, F. Jammes, J. Barata, A. W. Colombo, Generic Management

820

Services for DPWS-Enabled Devices, in: Proceedings of the 35th Annual Conference of IEEE Industrial Electronics Society, 2009, pp. 3931–3936. [9] IEC, Power systems management and associated information exchange Part 1: Reference architecture, Tech. rep., IEC (October 2012). [10] IEC 61850, Communication networks and systems for power utility au-

825

tomation, available at www.iec.ch (2002–2005).

42

[11] IEC 61970-301, Energy management system application program interface (ems-api) - part 301: Common information model (cim) base, available at www.iec.ch (2012). [12] M. Jung, J. Weidinger, W. Kastner, A. Olivieri, Heterogeneous Device In830

teraction Using an IPv6 Enabled Service-oriented Architecture for Building Automation Systems, in: Proceedings of the 28th Annual ACM Symposium on Applied Computing, 2013, pp. 1939–1941. [13] T. Teich, S. Wolf, T. Neumann, S. Junghans, S. Franke, Concept for a Service-Oriented Architecture in Building Automation Systems, Procedia

835

Engineering (69) (2014) 597–602. [14] Object-Managment-Group, Data Distribution Service (DDS) (April 2015). [15] M. Behan, O. Krejcar, Modern smart device-based concept of sensoric networks, Journal of Wireless Communications and Networking (155). doi:10.1186/1687-1499-2013-155.

840

[16] The Object Management Group (OMG), Unified Modeling Language (UML), Version 2.5 Formal/2015-03-01, OMG, http://www.omg.org (March 2015). [17] S. Lehnhoff, W. Mahnke, S. Rohjans, S. Uslar, IEC 61850 based OPC UA Communication - The Future of Smart Grid Automation, in: Proceedings

845

of Power Systems Computation Conference, 2011. [18] Object management group: Query/View/Transformation(QVT), http:// www.omg.org/spec/QVT/1.1. [19] P. D. Gallagher, NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 3.0, Tech. rep., NIST (May 2014).

850

[20] Frdric Jouault and Brahim-Khalil LOUKIL and William Piers, Model-tomodel transformation with atl, https://www.eclipsecon.org/2008/sub/ attachments/Modeltomodel_Transformation_with_ATL.pdf (2008). 43

[21] Power systems management and associated information exchange - interoperability in the long term - part 102: Cim - iec 61850 harmonization 855

(document 57/1350/np) (2013). [22] Unified Automation - UaModeler, https://www.unified-automation. com/products/development-tools/uamodeler.html. [23] OPC UA Information Model for BACnet, Tech. rep., BACnet Interest Group Europe and OPC Foundation (March 2014).

860

[24] M. Postol, OPC UA INFORMATION MODEL DEPLOYMENT, 2015.

44