2.1. OPC UA (IEC62451) Standard
OPC UA (IEC62451) was standardized by the IEC TC57 group in December 2012. The classic OPC was separated into OPC Data Access (DA), OPC Historical Data Access (HDA), OPC Alarms & Conditions (AC), and OPC Extensible Markup Language (XML). The classic OPC features were integrated into OPC UA. Additionally, service-oriented architecture (SOA) was added to OPC UA [
3].
The information model of integrated OPC UA is shown in
Figure 1 [
4]. The classic OPC can be built on top of the OPC UA-based information model. Vendor-specific models and domain/technology-specific models can be built on top of the OPC UA-based information model and the classic OPC, exposing their specific information via OPC UA. OPC UA AddressSpace, provided by OPC UA, is defined along with general information models based on object type. All information models using OPC UA define the following: (i) the entry points into the address space used by clients to navigate through the instances and types of OPC UA servers; (ii) the base types that build the root for the different types of hierarchies; (iii) the built-in but extensible types (i.e., object types and data types); and (iv) the server object that provides capability and diagnostic information. OPC UA information models, as well as complex models, can provide simple information. The base modeling concepts of OPC UA are nodes and references between nodes. Each node contains attributes, such as ID and name.
OPC UA software layers are shown in
Figure 2. The complete software stack can be implemented with C, .Net, or JAVA. OPC UA is not limited to these programming languages and development platforms, however, only these environments are currently used for implementing the OPC foundation UA stack deliverables [
9].
Figure 3 shows the OPC UA AddressSpace. The AddressSpace model specifies the building blocks to expose instance and type information and thus the OPC UA meta-model used to describe and expose information models and to build the OPC UA server AddressSpace. The OPC UA AddressSpace is modeled as a set of nodes that are accessible by OPC UA clients using OPC UA services. The nodes in the AddressSpace are used to represent real objects, their definitions, and their references to each other. The view is a specific subset of the AddressSpace that is of interest to the OPC UA clients [
10].
2.2. IEC 61850 Standard
IEC 61850 is a communication standard for electrical substation automation systems. It is the standard protocol used in digital substation systems and smart distributed systems. The goal of the IEC 61850 series is to provide interoperability between the IEDs from different suppliers or, more precisely, between functions to be performed by systems for power utility automation while residing in equipment from different suppliers. IEC 61850-7 describes the relationships between other parts of the IEC 61850 series [
11].
The models of the Abstract Communication Service Interface (ACSI) provide [
12]:
The definition of the basic model of the utility information models contained in IEC 61850-7-3 (common data classes for utility automation applications), IEC 61850-7-4 (compatible logical node classes and compatible data classes for utility automation applications), and IEC 61850-6 (the substation configuration language).
The definition of information exchange service models.
The following overall classes are defined: Server, Logical Device, Logical Node, and Data Object.
The IEC 61850 information model is shown in
Figure 4. The information model is an abstract representation of the devices inside the substation. The logical devices (LDs) comprise a virtual representation of physical devices, such as relays or bays in the substation. An LD includes many logical nodes (LNs). LNs are virtual representations of components of devices, such as switches, circuit breakers, and voltage meters. Data objects (DOs) are representations of the common information of nodes. All devices follow a common naming scheme; even if the manufacturer is different, it is possible to access the same device. DOs are typed by common data classes (CDC) from IEC 61850-7-3 or IEC 61850-7-2 [
12,
13].
Functional constraints (FC) play a crucial role in the definition of the information models and in the services used to access the various parts of the information model. The FC is not shown in the object reference. The FC information may be mapped into the object reference in a Specific Communication Service Mapping; IEC 61850-8-1 maps the FC between the logical node name and the data name (Relay1:MMXU1$CF$PhV). FCs are defined as follows: MX—measurements; ST—status; CF—configuration; RP—unbuffered report control blocks; LG—log control blocks; BR—buffered report control blocks; GO—Generic Oriented Object System Event (GOOSE) control blocks; GS—Generic Substation Status Event (GSSE) control blocks; SV—substituted values; SE—setting group editing [
14].
The language for the configuration of electrical substation IEDs is called System Configuration description Language (SCL) [
15]. It is used to describe IED configurations and communication systems according to IEC 61850-5 and IEC 61850-7. It allows the formal description of the relations between the utility automation system and the process (substation, switchyard).
Table 1 shows all the groups in the logical node defined in IEC 61850-7-4 [
16]. This group is defined as approximately 90 logical nodes, such as the common applications and supply of substation equipment. One major focus is the definition of information models for applications relating to the Protection and Protection-related. The two groups constitute almost half of the logical node. This shows the high importance of the Protection for the safety and stable operation of the power system.
2.3. Design of OPC UA AddressSpace for IEC 61850
Figure 5 shows the whole design flow of OPC UA AddressSpace for IEC 61850. First, the engineer has to define IEC 61850 logical node type using UA’s UaModeler—
Section 2.3. Second, the user needs to generate IEC 61850 logical node instance using SCL to OPC UA AddressSpace Tool—
Section 2.4. IEC 61850 logical node type source file and IEC 61850 logical node instance source file represent the IEC 61850 information in OPC UA.
OPC UA provides extensible information models. The information models of OPC UA are mapped after generating the abstract object on AddressSpace. Therefore, the IEC 61850 information model has to be modeled onto OPC UA AddressSpace. The following describes how the IEC16850 is mapped to the OPC UA AddressSpace.
The mapping of the IEC 61850 information model onto OPC UA AddressSpace is shown in
Figure 6 [
1]. The OPC UA AddressSpace changes the model from the IEC 61850 information to the IEC62541 information. Then, it has and holds as nodes on AddressSpace.
To structure the objects, three standard UA reference types are used [
2]:
- -
HasComponent describes part of the relationship between LN and its attributes as well as between CDC and its attributes. Furthermore, it is used for the grouping by FC.
- -
Organizes is used to group the CDC attributes by FC.
- -
HasTypeDefinition connects the LN attributes with the according CDC.
Mapping example: The model of the XCBR, one of the logical nodes (LNs) of the IEC 61850, using UA’s Modeler tool can be mapped by reference to
Figure 5. The XCBR LN of the IEC 61850 is the circuit breaker (CB) of the substations or distributed devices [
12]. It is mapped to object type because of the LN class. Additionally, it has many common data classes (CDCs) of the attribute type [
11]. CDCs are modeled to object type. CDCs reference the LN data defined in the IEC 61850. The Single Point Status (SPS), one of the CDCs, provides status information. The quality of the measured value (q) and the timestamp of the measured value (t) are modeled to the variable [
11]. The predefined data type is referred to in Modeler. The XCBR LN has LN data: Loc (local control behavior), EEHealth (external equipment health), EEName (external equipment name plate), and so forth, as the HasComponent. The HasComponent ReferenceType is used, exposing the configuration of a device as a component of the device. The attribute types of LN refer to the CDC, such as SPS to HasTypeDefinition [
1,
10].
Data-type mapping is the most basic information in the rules of mapping. IEC 61850 BasicTypes are consistent with OPC UA BaseDataTypes.
Table 2 shows the data-type mapping table for mapping the IEC 61850 and OPC UA.
Figure 7 shows ACSI server class mapping. The server class represents the external visible behavior of a device. It is composed of 1 to N logical device classes. The attribute ServiceAccessPoint identifies a server within the scope of a subnetwork. The attribute LogicalDevice identifies a logical device that is contained in a general server. The attribute File identifies a file system included in a general server. The attribute TPAppAssociation identifies a client with which a server maintains a two-party application association. The attribute MCAppAssociation identifies a subscriber with which a server maintains a multicast application association. ServiceAccessPoint is mapped to the variable node class type. The remaining attributes are mapped to the object node class type [
6,
10,
12].
ACSI logical device mapping is shown in
Figure 8. The logical device classes comprise three or more logical node classes. The attribute LDName unambiguously identifies an instance of a logical device within the scope of a subnetwork. The attribute LDRef identifies the reference path of a logical device within the scope of a subnetwork. The attribute LogicalNode is a list of all logical nodes that are contained in a general logical device class. LDName and LDRef are mapped to the variable Node class type. LogicalNode is mapped to the object node class type.
The ACSI logical node class is a composition of LNName, LNRef, DataObjects, DATA-SET, BRCB (buffered report control block), and URCB (unbuffered report control block) [
9]. The attribute LNName unambiguously identifies a logical node within the scope of a logical device. The attribute LNRef is the unique path name of a logical node. The attribute DataObject is a data object contained in a logical node. The attribute DataSet is a list of all data sets that are included in a logical node. The attribute BRCB is a list of all buffered report control blocks that are comprised in a logical node. The attribute URCB is a list of all unbuffered report control blocks that are contained in a logical node. LNName and LNRef are mapped to the variable node class type. The remaining attributes are mapped to the object node class type.
The ACSI data object class is a key element in IEC 61850. It is a composition of DataObjectName, DataObjectRef, and DataObjectType. The attribute DataObjectName unambiguously identifies a data object within the scope of a logical node. The attribute DataObjectRef is the unique path name of a data object. The DataObjectType is the CDC type.
Table 3 shows an example of the common data class (CDC—Data Object). The CDCs are defined in IEC 61850-7-3 [
13]. CDCs are a configured common data attribute (base data type or data structure) and they are defined for use in IEC 61850-7-4 [
16]. CDCs define the relation between their attributes and the functional constraint as well as the possible trigger options. CDC specifications are classified as status, measurand, controls, status settings, analog settings, and description. DPS (double point status) belongs to status.
Table 4 shows an example of mapping using the IEC 61850 information model defined in IEC 61850-7-4. The logical node is to be composed of several CDCs. The logical node is composed of three categories of data, and status information can be information that controls the logical node. The categories are defined in several classes of data. The logical node is mapped to the OPC UA node model based on the previously mapped CDC.
The UaModeler tool is used to implement the OPC UA AddressSpace for IEC 61850 ACSI mapping. The UaModeler tool produces the source code for types of mapped IEC 61850 models (e.g., XCBR type). It can easily implement information modeling, and it is represented graphically for the OPC UA AddressSpace. The generated source code is C++, ANSI C, .NET [
17].