1 Scope

OPC Foundation

OPC is the interoperability standard for the secure and reliable exchange of data and information in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.

OPC UA is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. This multi-layered approach accomplishes the original design specification goals of:

Platform independence: from an embedded microcontroller to cloud-based infrastructure

Secure: encryption, authentication, authorization and auditing

Extensible: ability to add new features including transports without affecting existing applications

Comprehensive information modelling capabilities: for defining any model from simple to complex

DECHEMA

“DECHEMA is the expert network for chemical engineering and biotechnology in Germany. As a non-profit professional society we represent these fields in science, industry, politics and the general public. DECHEMA promotes scientific and technical exchange among experts from different disciplines, organisations and generations. We consolidate the know-how of over 5,800 individual and sustaining members.” (https://dechema.de/en/)

DEXPI - Data Exchange in the Process Industry

“The objective of the DEXPI initative is to develop and promote a general data exchange standard for the process industry, covering all phases of the lifecycle of a (petro-)chemical plant, ranging from specification of functional requirements to assets in operation. Currently, the focus of the DEXPI initiative is the exchange of Piping and Instrumentation diagrams (P&IDs).” (http://www.dexpi.org/)

Scope of this work

The scope of this work is to extend the OPC UA standard data model with the capability of modelling and transferring the engineering information of Piping and Instrumentation Diagrams (P&IDs) that are based on ISO 15926 and the DEXPI 1.2 specification.

This companion specification is an extension of the overall OPC Unified Architecture standards and defines an information model that conforms to the DEXPI specification (which is based on the ISO 15926 standard).

The modelling targets of this standard shall exist in an OPC UA Address Space. This standard does not consider the modelling targets that are identified in other standards or vendor specifications.

2 Normative references

The following referenced documents are indispensable for the application of this specification. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

DEXPI related references:

DEXPI specification document:

https://gitlab.com/DEXPI/Specification

https://gitlab.com/DEXPI/Specification/blob/master/specification/DEXPI%20Specification%201.2.pdf

DEXPI specification in table format:

http://dexpi-information-model.aixcape.org/

Hierarchy of DEXPI classes:

See attached document “DEXPI_ENPRO_Data_Model.xlsx”, also here:

https://gitlab.com/dexpi/public-opc-ua/-/blob/master/DEXPI_ENPRO_Data_Model.xlsx

Partial mapping between DEXPI engineering units to UNECE engineering units (not used in this version of the specification):

See attached document “DEXPI Unit to UNECE Units mapping.xlsx”, also here:

https://gitlab.com/dexpi/public-opc-ua/-/blob/master/UNECE_to_OPCUA.xlsx

Proteus XML schema:

https://github.com/ProteusXML/proteusxml/releases/tag/v4.0.1

ISO 15926 standard:

https://www.posccaesar.org/wiki/ISO15926

https://www.iso.org/search.html?q=ISO%2015926

Journal article with an overview of the DEXPI effort:

Wiedau, M., von Wedel, L., Temmen, H., Welke, R. and Papakonstantinou, N., ENPRO Data Integration: Extending DEXPI Towards the Asset Lifecycle, 2019, Chemie Ingenieur Technik.

https://onlinelibrary.wiley.com/doi/full/10.1002/cite.201800112

OPC UA related references:

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-3

OPC 10000-4, OPC Unified Architecture - Part 4: Services

OPC 10000-4

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-5

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-7

OPC 10000-8, OPC Unified Architecture - Part 8: Data Access

OPC 10000-8

3 Terms, definitions and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling, the DEXPI specification and the ISO 15926 and Proteus XML are understood in this specification. This specification will use these concepts to describe the DEXPI Information Model. For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7, OPC 10000-8, the DEXPI specification and the ISO 15926 as well as the following apply.

Note that OPC UA terms and terms defined in this specification are italicized in the specification.

4 OPC UA for DEXPI 1.2

4.1 Abbreviations and symbols

CAE Computer Aided Engineering

DEXPI Data Exchange in the Process Industry

EPC Engineering-Procurement-Construction

P&ID Piping and Instrumentation Diagram

IIoT Industrial Internet of Things

4.2 Conventions used in this document

4.2.1 Conventions for Node descriptions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

• If the TargetNode is a component of the Node being defined in the table, the Attributes of the composed Node are defined in the same row of the table.

• The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3, ). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3, ) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

• The TypeDefinition is specified for Objects and Variables.

• The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

• The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Nodes of all other NodeClasses cannot be defined in the same table; therefore only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass, DataType and ModellingRule can be derived from the type definitions, and the symbolic name can be created as defined in 4.2.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

4.2.2 NodeIds and BrowseNames

4.2.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this specification is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this specification, the symbolic name is unique.

The namespace for all NodeIds defined in this specification is defined in Annex A. The namespace for this NamespaceIndex is Server-specific and depends on the position of the namespace URI in the server namespace table.

Note that this specification not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this specification, because they are not defined by this specification but generated by the Server.

4.2.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this specification is specified in the tables defining the Nodes. The NamespaceIndex for all BrowseNames defined in this specification is defined in Annex A.

If the BrowseName is not defined by this specification, a namespace index prefix is added to the BrowseName (e.g., prefix ‘0:’ leading to ‘0:EngineeringUnits’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this specification. 12.2 provides a list of namespaces and their indexes as used in this specification.

4.2.3 Common Attributes

4.2.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3, . Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this specification or if it is server-specific.

For all Nodes specified in this specification, the Attributes named in Table 3 shall be set as specified in the Table 3.

4.2.3.2 Objects

For all Objects specified in this specification, the Attributes named in Table 4 shall be set as specified in the Table 4. The definitions for the Attributes can be found in OPC 10000-3, .

4.2.3.3 Variables

For all Variables specified in this specification, the Attributes named in Table 5 shall be set as specified in the Table 5. The definitions for the Attributes can be found in OPC 10000-3, .

4.2.3.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 6 shall be set as specified in the Table 6. The definitions for the Attributes can be found in OPC 10000-3, .

4.2.3.5 Methods

For all Methods specified in this specification, the Attributes named in Table 7 shall be set as specified in the Table 7. The definitions for the Attributes can be found in OPC 10000-3, .

5 General information to DEXPI and OPC UA

5.1 Introduction to DEXPI

This introductionto the DEXPI group is part of the DEXPI specification document and was added here for readability and completeness purposes. For more information refer to the DEXPI specification 1.2 (see section 2 - Normative references).

5.1.1 About DEXPI

The DEXPI group (Data EXchange for the Process Industry) is a working party of the ProcessNet initiative under the lead of Dechema. ProcessNet describes itself as:

"ProcessNet is the German platform for chemical engineering with more than 5,000 members. Experts from the sciences, industry and administration exchange ideas and experience, discuss current topics and identify new scientific trends. ProcessNet is a joint initiative of DECHEMA and VDI-GVC.

ProcessNet organises numerous events targeting the interdisciplinary and cross-sectoral exchange of information. The most prominent conference is the ProcessNet Annual Meeting attracting more than 1,000 participants. The wide variety of thematically structured committees deal with scientific and technical problems and issues of paramount technological and societal relevance, they also trigger funding policy initiatives. ProcessNet is the national contact point for international co-operations. Participation in ProcessNet is open to all members of DECHEMA and/or VDI-GVC." (Source: www.processnet.org)

5.1.2 Motivation for the DEXPI

Due to the lack of interoperability between Computer Aided Engineering (CAE) (and other) systems, companies today face high efforts in data exchange while working together to execute projects for planning, construction and operation of process plants. Parties typically exchanging data in such projects are EP/EPCs, owner-operators, and vendors, but also site services and authorities. One of the main reasons for this high effort is the lack of an agreed understanding across the different systems, e.g. by means of a commonly used standard for data exchange within the process industry. To become more efficient during planning, construction and operation of plants, a data exchange model based on the ISO 15926 standard shall be established.

5.1.3 Objectives

The objective is to develop and promote a general method for data exchange, data interoperability and data integration for the process industry covering all phases of the lifecycle of a (petro-)chemical plant, ranging from specification of functional requirements to assets in operation. This method shall cover formats and content to address various problems seen today:

- Avoid format conversions (and thereby data loss) when passing engineering data and documents across CAE system boundaries.

- Make handover of engineering data during and at the end of a project easy and cost-effective.

- Reduce data exchange barriers between different CAE systems or different customizations of the same CAE systems. Support long-term storage of plant data in a CAE system-independent format. Today's commonly used standard formats like PDF don't support value-added improvements or at best, they do so insufficiently.

- Simplify co-existence of different CAE systems within a company, e.g. due to mergers/acquisitions or different priorities in different business units.

5.1.4 Expectations

EP/EPCs, suppliers and owner operators want to minimize the cost for handling engineering data during planning, construction and operation of process plants between different CAE systems and they want to create opportunities for new value-added functions based on the available engineering data. Therefore, the CAE vendors will implement a valid global standard for data exchange into their CAE systems. In the first phase, data exchange will cover the graphics and topology of the full Piping and Instrumentation Diagram (P&ID) and attributes of the discrete P&ID components.

The involved owner/operator companies from the DEXPI working group will define a common data model which is based on the ISO 15926 standard. The resulting data model will be aligned with other projects in the global ISO 15926 community, e.g. within Fiatech. The CAE vendors will implement this common data model as the basis for data exchange and will deliver it as part of their default system configuration. In addition, it is expected that CAE vendors agree on a common exchange format for the graphical representation of a P&ID and implement the result in their systems as well. The involved companies expect constructive team work by the CAE vendors during the definition of the common ISO 15926 conformant data model.

Objective of the first phase of the initiative is the transfer of a P&ID from one P&ID system to another P&ID system. The data transfer must include graphics, symbols, topology, all engineering attributes, enumerations, select lists etc. to enable seamless continuation of work on the P&ID in the destination system. Transfer of engineering data over the full life cycle of a plant between different CAE tools from simulation to basic/detail engineering up to operations and maintenance may be covered in subsequent phases.

5.2 Introduction to OPC Unified Architecture

5.2.1 What is OPC UA?

OPC UA is an open and royalty-free set of standards designed as a universal communication protocol. While there are numerous communication solutions available, OPC UA has key advantages:

A state-of-theart security model (see OPC 10000-2).

A fault-tolerant communication protocol.

An information modelling framework that allows application developers to represent their data in a way that makes sense to them.

OPC UA has a broad scope which delivers economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost are available. When combined with semantic models such as DEXPI, OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provide that data in a consistent format to any application requesting data - ERP, MES, PMS, Maintenance Systems, HMI, Smartphone or a standard Browser, for example. For a more complete overview, see OPC 10000-1.

5.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, OPC UA provides a set of Services (see OPC 10000-4) and a basic information model framework. This framework provides an easy manner for creating and exposing vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications. This specification is an example of an OPC UA Information Model designed to meet the needs of developers and users.

OPC UA Clients can be any consumer of data from another device on the network to browser-based thin clients and ERP systems. The full scope of OPC UA applications is shown in Figure 1.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing data exchange solution. Security is built into OPC UA as security requirements become more and more important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems.

5.2.3 Information modelling in OPC UA

5.2.3.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has a number of Attributes including a unique identifier called a NodeId and non-localized name called as BrowseName. An Object representing a ‘Reservation’ is shown in Figure 2.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 3 illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all the children that can be present in an instance of the type. In the example in Figure 3 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identify the children. This means Client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple Servers implement.

OPC UA also supports the concept of sub-typing. This allows a modeller to take an existing type and extend it. There are rules regarding sub-typing defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeller may decide that the existing ObjectType in some cases needs an additional Variable. The modeller can create a subtype of the ObjectType and add the Variable. A Client that is expecting the parent type can treat the new type as if it was of the parent type. Regarding DataTypes, subtypes can only restrict. If a Variable is defined to have a numeric value, a sub type could restrict it to a float.

References allow Nodes to be connected in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical are used to create arbitrary associations. Applications can define their own ReferenceType by creating subtypes of an existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 4 depicts several References, connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 5. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA Server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base structure is described in OPC 10000-5.

OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of Profiles, which segment the functionality into testable certifiable units. This allows the definition of functional subsets (that are expected to be implemented) within a companion specification. The Profiles do not restrict functionality, but generate requirements for a minimum set of functionality (see OPC 10000-7)

5.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built in knowledge of some Nodes. OPC UA Information Models generally define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

5.2.3.3 Companion Specifications

An OPC UA companion specification for an industry-specific vertical market describes an Information Model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market, and potentially also well-defined Objects as entry points into the AddressSpace.

6 Use cases

6.1 An IIoT ecosystem based on open standards

The ability to access P&ID design information over OPC UA is part of a bigger concept of an Industrial Internet of Things (IIoT) ecosystem. Vendor-specific IIoT solutions based on vertical tool stacks are offered to industrial stakeholders, but the interoperability between vendors is limited. This hinders adoption and is an obstacle for small companies that want to develop innovative IIoT services. An IIoT ecosystem based on open standards for most (if not all) plant information can be a future-proof platform for innovation and interoperability, see Figure 6.

The offered data can come from the operation of the process or can be static data, such as design and maintenance information. A communication layer based on an open standard can help to establish homogeneous and secure data access. The IIoT services can combine and process the available information in order to provide solutions ranging from industrial data analytics and visualization to data mining applications for decision support and process optimization.

Since the P&ID is recognized as a key design information diagram for industrial processes, it is valuable to be part of this open ecosystem concept. The ISO15926/DEXPI standard and specification was chosen as the most mature offering for P&ID interoperability between software vendors.

6.2 Data hand over between lifecycle phases and between project stakeholders

This case presents the DEXPI OPC UA specification as an enabler for dynamic exchange of P&ID information to the next steps of the system design lifecycle and to subcontractors who are interested in parts of the process or in specific equipment (see Figure 7).

The OPC UA server can always have up-to-date P&ID data and other project stakeholders (e.g. subcontractors) can view/edit them (if they have the access rights).

7 DEXPI Information Model overview

This overview of the DEXPI information model is part of the journal paper titled “ENPRO Data Integration: Extending DEXPI Towards the Asset Lifecycle” (https://onlinelibrary.wiley.com/doi/full/10.1002/cite.201800112) (see section 2 - Normative references); please refer to that article for more details.

An important outcome of the DEXPI P&ID project is the specification document (see section 2 - Normative references). It contains the data models for the plant break down structure, for the taxonomies and properties of the apparatuses & machines, of the piping components and of the instrumentation objects. The topology between the different engineering objects is included as well. All engineering objects and properties are defined with the ISO 15926 sandbox concept, i.e. the POSC Caesar sandbox is the preferred industry sandbox, and the DEXPI sandbox contains additional ISO 15926 part 4 class definitions. The DEXPI data model uses multiple inheritance, a paradigm not compatible with OPC UA (an ObjectType can inherit from only one parent). An additional table with hierarchical relations between the DEXPI classes is part of the DEXPI data model and provides the information needed for the parent-child relationships in the DEXPI OPC UA address space model. As basis of implementation the Proteus schema [6] was selected by the software vendors and has been upgraded to the version 4.0.1 to fulfill the DEXPI requirements. Among other aspects the Proteus schema contains the graphical concept. Proteus is one implementation method for the DEXPI P&ID specification. Alternative technologies could be part 3 of ISO 15926 or the SVG (Scalable Vector Graphics) format. Two additional data sources for the DEXPI information model are the herarch of the DEXPI class taxonomy and the mapping of engineering units (see Normative references section). The data modeling approaches for the various parts of a P&ID will be introduced in the next subsections.

Data model for P&ID objects

The plant break down structure and the identification concepts for engineering objects are important parts of an intelligent P&ID. The ISO 10209:2012 [7] contains essential specifications for these topics. DEXPI decided to use the following hierarchical structure described in Figure 8. Every plant item like a pump, a vessel or a pipe line is a tagged object and can be identified by a tag name, which is unique in the scope of a process plant. A process plant has a unique name in the scope of an enterprise’s site. Components of tagged objects like nozzles of a vessel have a sub tag identification concept, they always have a unique name in the scope of its tag. The DEXPI specification also supports some other structural elements like area, train or system. Every plant item can have references to those elements.

For apparatuses and machines there are different taxonomies. The ISO Standard Maintenance Portal contains a classification into the groups Heat Transfer, Rotating Equipment, Solid Handling and Static equipment. The PAS 1041 contains a list of the apparatus and machines with 22 groups and a total of 198 single elements, with an entry in the 4-stage eclass hierarchy in each case. BASF, Bayer, Covestro and Evonik apply enterprise-specific taxonomies which they have implemented in their technical systems. Another possibility for the classification arises from the ISO 10628-2:2012. Out of 29 defined groups 24 concern apparatuses and machines. Within these groups symbols are assigned to different subtypes. Many CAE systems for P&IDs use these symbols from ISO 10628. The DEXPI concept is a synthesis from all these input dimensions, however the groups of ISO 10628 deliver the leading classification concept. Figure 9 illustrates the DEXPI apparatuses and machines data model applied to a pump example.

Sub equipment types always are specializations of equipment types. DEXPI

supports the component concept as a decomposition approach. Some components belong to specific sub-equipment types while other are more general and belong to the top-level equipment type. E.g.

every equipment can have Nozzles or Chambers, components that are more specific, like an Impeller, are part of a CentrifugalPump. All these engineering objects and their properties have been specified as ISO 15926 part 4 classes in the used sandboxes.

For the P&ID piping taxonomy, ISO 10628-2:2012 is the major source as well. Valves and fittings with safety functions are part of the piping discipline, not of instrumentation. A pipeline as a PipingNetworkSystem and a single segment as a PipingNetworkSegment are terms of the ISO 15926 specification. Uniform rules were fixed in collaboration with the CAE vendors for breaks by Piping Network Segments. Essential properties of the pipings, their segments and their components are media, pipe classes, nominal diameter, isolation and heating requirement information. A pipeline number is unique within a process plant; piping segments get a segment number which is combined with the corresponding pipeline number to get a unique identifier. All piping components as well get a plant-wide unique number as an identification. The development of the working package “Instrumentation” was by far the biggest and most time consuming challenge in the DEXPI project because the representation of the instrumentation in the P&ID is used very differently in various standards and enterprises. Moreover, the ISO Community has not yet delivered a comprehensive solution. Additionally, Proteus XML contained no adequate concept in the version 3.3.0 which was current at the time the DEXPI project started. On the engineering side, especially the instrumentation standards ISA 5.1 and IEC 62424 as well as the outdated DIN 19227 are relevant. Many enterprises use a mixture of these standards as an enterprise or site norm. The DEXPI approach has not been created to introduce a new P&ID instrumentation standard, but to define a new transport standard. It

aims to support the different current approaches with a common information model compatible to all relevant instrumentation standards (see Figure 10).

The upper part of the model considers the functional concept, the lower one the device concept. The central functional object is the Process Instrumentation Function (in analogy to the concept PCE Request of the IEC 62424). Usually it is graphically shown with an instrumentation bubble. If required, Process Instrumentation Functions can be grouped in an Instrumentation Loop Function (PCE loop in IEC 62424). A use case for this is e.g. the definition of a local and at the same time central function like PI in which the pressure should be indicated in the field and also in the central operating room. Another use case is the multi sensor function D and F, in which a device should measure the density as well as the flow. A Process Instrumentation Function can have Process Signal Generating Functions as well as Actuating Functions as parts. Some standards have restrictions in this context, they permit either Process Signal Generating or Actuating Functions as parts. Regarding this issue, the DEXPI model is more comprehensive. Process Signal Generating and Actuating Functions are the objects which bundle up the functional demands for the sensing systems or actuating systems. In each case the property installation location, that at or in which object this function should be explained, is very important. The linking elements form the Signal Conveying Functions between the objects. All functional objects

Instrumentation Loop Function,

Process Instrumentation Function,

Process Signal Generating Function and

Actuating Function

have a unique identifier as a tag name. The DEXPI specification does not place any additional restrictions for naming conventions other than uniqueness, again to support as many different enterprise standards as possible. The device concept in the DEXPI model borrows very strongly from the IEC 61987 specification. Process Signal Generating and Actuating Systems (Composite Devices in IEC 61987) can have device components as parts. Some of these components are often shown on P&IDs graphically, for example, flow measuring instruments as sensor symbols as well as control valves and actuators. The model is extensible to other components. The Process Signal Generating System as well as the Actuating System are objects with unique identifiers within a plant. Their components are to be identified against it only within the scope of its use in the device group. The Process Signal Generating Systems must fulfill the demands of Process Signal Generating Functions, Actuating Systems the demands of the Actuating Functions. As a result, a bridge is built between the functional part and the device part in the model.

It is important to note that the engineering units and physical quantity types included to the DEXPI 1.2 specification document were not transferred to the OPC UA specification. The AnalogUnitType was used instead.

8 OPC UA ObjectTypes

This chapter includes the list of tables containing the Object Types related to the DEXPI classes. The “Association to” notes for the object types are capturing non-hierarchical associations present in the DEXPI UML model, they are mentioned in this way so that information is somehow transferred to the OPC UA specification and not lost.

Figure 11 shows as an example the basic relationships of the EquipmentType up to the BaseObjectType of the OPC UA specification and down to the PumpType and specific pump categories with examples of pump instances as OPC UA objects.

8.1 BaseDEXPIObjectType

Base object type, parent for all DEXPI Object types

8.2 ActuatingFunctionType

A function for acting control structures relating to the process.
Association to ActuatingLocation (PipingNetworkSegment)
Association to Systems (ActuatingSystem)
Association to ParentStructure (TechnicalItemParentStructure)
Association to PlantTrain (PlantTrain)
Association to PlantSystem (PlantSystem)
Association to AreaIsa95 (AreaIsa95)

ActuatingFunctionNumberAssignmentClass – An identifier for the ActuatingFunction. It usually contains the identifier of the ProcessInstrumentationFunction that includes the ActuatingFunction (see ProcessInstrumentationFunctionNumberAssignmentClass).

8.3 ActuatingSystemType

An assembly of artefacts that is designed to fulfill an ActuatingFunction.
Association to ParentStructure (TechnicalItemParentStructure)
Association to PlantTrain (PlantTrain)
Association to PlantSystem (PlantSystem)
Association to AreaIsa95 (AreaIsa95)

<Positioner> – OPC UA Object(s) that are part of the Object Type.

<ControlledActuator> – OPC UA Object(s) that are part of the Object Type.

<ShutOffValveReference> – OPC UA Object(s) that are part of the Object Type.

ActuatingSystemNumberAssignmentClass – The number of the ActuatingSystem.

TypicalInformationAssignmentClass – Typical information about the ActuatingSystem.

8.4 AgitatorRotorType

An agitator rotor.
Association to Chamber (Chamber)

MaterialOfConstructionCodeAssignmentClass – A code that gives the material of construction of the AgitatorRotor.

Diameter – The diameter of the AgitatorRotor.

LengthToMountingFlange – The length to the mounting flange of the AgitatorRotor.

RotorTypeAssignmentClass – The rotor type of the AgitatorRotor.

8.5 AngleType

8.6 AreaIsa95LocatedStructureType

A structure that can be located in an AreaIsa95.
Association to AreaIsa95 (AreaIsa95)

8.7 AreaIsa95Type

An area as defined by ISA 95.

AreaNameAssignmentClass – The name of the AreaIsa95.

AreaIdentificationCodeAssignmentClass – The identification code of the AreaIsa95.

8.8 AreaType

8.9 ChamberOwnerType

An object that can have chambers.

<Chamber> – OPC UA Object(s) that are part of the Object Type.

8.10 ChamberType

A physical object that is an enclosed space (from http://data.posccaesar.org/rdl/RDS903151421).

UpperLimitDesignTemperature – The highest temperature for which the Chamber is designed.

NominalDiameter – The nominal diameter of the Chamber, given as a length. See also <owner.NominalDiameterTypeRepresentationClass>.

InsideDiameter – The inside diameter of the Chamber.

SubTagNameAssignmentClass – The sub tag name of the Chamber.

MaterialOfConstructionCodeAssignmentClass – A code that gives the material of construction of the Chamber.

Width – The width of the Chamber.

Length – The length of the Chamber.

UpperLimitDesignPressure – The highest pressure for which the Chamber is designed.

ChamberDescriptionAssignmentClass – The description of the Chamber.

Height – The height of the Chamber.

NominalDiameterTypeRepresentationAssignmentClass – A readable representation of the type of the nominal diameter of the Chamber. The purpose of this value is to give a textual representation of the nominal diameter to be used in the graphics of a PID.

ChamberFunctionAssignmentClass – The function of the Chamber.

LowerLimitDesignPressure – The lowest pressure for which the Chamber is designed.

LowerLimitDesignTemperature – The lowest temperature for which the Chamber is designed.

ChamberFunctionSpecialization – A specialization indicating the function of the Chamber.

8.11 ColumnInternalsArrangementType

The internals of a column.

8.12 ColumnPackingsArrangementType

The packings of a column.

Height – The height of the ColumnPackingsArrangement.

PackingTypeAssignmentClass – The type of the packings in the ColumnPackingsArrangement.

MaterialOfConstructionCodeAssignmentClass – A code that gives the material of construction of the ColumnPackingsArrangement.

NumberOfPackings – The number of packings in the ColumnPackingsArrangement.

8.13 ColumnSectionType

A column section.

<Internal> – OPC UA Object(s) that are part of the Object Type.

Height – The height of the ColumnSection.

InsideDiameter – The inside diameter of the ColumnSection.

8.14 ColumnTraysArrangementType

The trays of a column.

TrayTypeAssignmentClass – The type of the trays in the ColumnTraysArrangement.

MaterialOfConstructionCodeAssignmentClass – A code that gives the material of construction of the ColumnTraysArrangement.

NumberOfTrays – The number of trays in the ColumnTraysArrangement.

8.15 CompressorEquipmentType

Equipment of a Compressor.

8.16 ControlledActuatorType

A transducer that is intended to convert energy (electric, mechanical, pneumatic or hydraulic) from an external source into kinetic energy (motion) in response to a signal or or power input.

FailActionSpecialization – The fail action of the ControlledActuator.

DeviceTypeNameAssignmentClass – The device type of the ControlledActuator.

SubTagNameAssignmentClass – The sub tag name of the ControlledActuator.

FailActionRepresentationAssignmentClass – A readable representation of the fail action of the ControlledActuator. This attribute should also be referenced in the graphics if applicable.

8.17 DEXPISupplementaryDataType

Additional data including the original XML source file, the DEXPI specification as UML XMI and used version numbers for the DEXPI specification and the Proteus schema

DEXPISpecificationVersion – Variable which holds the version of DEXPI specification.

ProteusXMLExternalLink – Variable which a link to the XML file of the input P&ID model.

ProteusSchemaVersion – Variable which holds the version of Proteus schema.

DEXPIXMIExternalLink – Variable which holds a link to the XMI file of DEXPI specification as UML.

DEXPIXMIFile – Object that holds the data of the XMI file of DEXPI specification as UML.

ProteusXMLFile – Object that holds the data of the Proteus XML file of DEXPI P&ID model.

8.18 DirectPipingConnectionType

A direct connection between two piping items, i.e. a connection that is not realized by a pipe.
Association to SourceItem (PipingSourceItem)
Association to TargetItem (PipingTargetItem)
Association to SourceNode (PipingNode)
Association to TargetNode (PipingNode)

8.19 DisplacerType

A displacer.
Association to Chamber (Chamber)

MaterialOfConstructionCodeAssignmentClass – A code that gives the material of construction of the Displacer.

StageIdentifierAssignmentClass – The stage identfifier of of the Displacer.

VolumePerStroke – The volume per stroke of the Displacer.

8.20 EquipmentType

A piece of equipment.
Association to ParentStructure (TechnicalItemParentStructure)
Association to PlantTrain (PlantTrain)
Association to PlantSystem (PlantSystem)
Association to AreaIsa95 (AreaIsa95)

<Chamber> – OPC UA Object(s) that are part of the Object Type.

<Nozzle> – OPC UA Object(s) that are part of the Object Type.

TagNameSequenceNumberAssignmentClass – The sequence number part of the tag number of the TaggedPlantItem. For example, the sequence number of the tag number "P4714-A" is "4714".

EquipmentDescriptionAssignmentClass – A short desciption of the Equipment in natural language. So far, there is no support for descriptions in different languages.

TagNamePrefixAssignmentClass – The prefix part of the tag number of the TaggedPlantItem. For example, the prefix of the tag number "P4714-A" is "P". The prefix often indicates the type of the equipment item, e.g., "P" can indicate a pump. See also <owner.TagNameAssignmentClass>.

TagNameSuffixAssignmentClass – The suffix part of the tag number of an TaggedPlantItem item. For example, the suffix of the tag number "P4714-A" is "A".

TagNameAssignmentClass – The tag number of the TaggedPlantItem. See also <owner.TagNamePrefixAssignmentClass>, <owner.TagNameSequenceNumberAssignmentClass>, and <owner.TagNameSuffixAssignmentClass>.

NozzleOwnerType – An object that can have nozzles.

ChamberOwnerType – An object that can have chambers.

TaggedPlantItemType – A fully tagged item in a plant.

8.21 AgitatorType

A dynamic mixer that stir or shake fluids by reaction force from moving vanes (from http://data.posccaesar.org/rdl/RDS16045622).

<Rotor> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the Agitator.

DesignShaftPower – The design shaft power of the Agitator.

8.22 CompressorType

A 'gas pressure increase device' and an 'artefact' that is driven by a prime mover by which energy is either constantly or periodically added to an amount of gas in order to increase its pressure (from http://data.posccaesar.org/rdl/RDS14286497).

DesignVolumeFlowRate – The volume flow rate for which the Compressor is designed.

DifferentialPressure – The differential pressure of the Compressor.

8.23 AirEjectorType

An ejector intended to create vacuum using compressed air (from http://data.posccaesar.org/rdl/RDS5770157).

<Impeller> – OPC UA Object(s) that are part of the Object Type.

DesignCapacityMotiveFluid – The design capacity for the motive fluid of the AirEjector.

8.24 AxialCompressorType

A dynamic compressor in which the gas is accelerated by the action of a bladed rotor and where the main flow is along the rotation axis of the rotor (from http://data.posccaesar.org/rdl/RDS417239).

<Impeller> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the AxialCompressor.

DesignShaftPower – The design shaft power of the AxialCompressor.

8.25 CentrifugalCompressorType

A dynamic compressor in which one ore more impellers accelerate the gas and where the main flow through the impeller is radial (from http://data.posccaesar.org/rdl/RDS417194).

<Impeller> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the CentrifugalCompressor.

DesignShaftPower – The design shaft power of the CentrifugalCompressor.

8.26 ReciprocatingCompressorType

A positive displacement compressor in which forced reduction of gas volume takes place by the movement of a displacing element in a cylinder or enclosure (from http://data.posccaesar.org/rdl/RDS417284).

<Displacer> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the ReciprocatingCompressor.

DesignShaftPower – The design shaft power of the ReciprocatingCompressor.

8.27 RotaryCompressorType

A positive displacement compressor in which compression displacement is effected by the positive action of rotating elements (from http://data.posccaesar.org/rdl/RDS435374).

<Displacer> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the RotaryCompressor.

DesignShaftPower – The design shaft power of the RotaryCompressor.

8.28 SpecialCompressorType

A Compressor that is not covered by any of the sibling classes of SpecialCompressor.

<CompressorEquipmentItem> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the SpecialCompressor.

DesignShaftPower – The design shaft power of the SpecialCompressor.

DesignCapacityMotiveFluid – The design capacity for the motive fluid of the SpecialCompressor.

TypeNameAssignmentClass – The name of the type of the SpecialCompressor.

8.29 FilterType

A separator intended to remove solids from vapour or liquid (from http://data.posccaesar.org/rdl/RDS300689).

8.30 GasFilterType

A filter that is specifically designed to filter a gas.

<FilterUnit> – OPC UA Object(s) that are part of the Object Type.

UpperLimitAllowableDesignPressureDrop – The maximum allowable design pressure drop of the GasFilter.

DesignRotationalSpeed – The design rotational speed of the GasFilter.

Capacity_VolumeFlowRate – The handling flow rate for which the GasFilter is designed.

DesignShaftPower – The design shaft power of the GasFilter.

8.31 LiquidFilterType

A filter that is specifically designed to filter a liquid.

<FilterUnit> – OPC UA Object(s) that are part of the Object Type.

DesignShaftPower – The design shaft power of the LiquidFilter.

UpperLimitAllowableDesignPressureDrop – The maximum allowable design pressure drop of the LiquidFilter.

Capacity_VolumeFlowRate – The handling flow rate for which the LiquidFilter is designed.

DesignRotationalSpeed – The design rotational speed of the LiquidFilter.

8.32 HeatExchangerType

An artefact that is intended to transfer heat from one object to another (from http://data.posccaesar.org/rdl/RDS304199).
Association to Agitator (Agitator)

DesignHeatFlowRate – The heat flow rate for which the HeatExchanger is designed.

DesignHeatTransferArea – The design heat transfer area of the HeatExchanger.

DesignHeatTransferCoefficient – The design heat transfer coefficient of the HeatExchanger.

8.33 AirCoolingSystemType

A cooling system which uses air as the cooling medium (from http://data.posccaesar.org/rdl/RDS277379).

<Rotor> – OPC UA Object(s) that are part of the Object Type.

DesignPower – The design power of the AirCoolingSystem.

DesignRotationalSpeed – The design rotational speed of the AirCoolingSystem.

DesignShaftPower – The design shaft power of the AirCoolingSystem.

8.34 ElectricHeaterType

A heater in which electric energy is converted into heat for useful purposes (from http://data.posccaesar.org/rdl/RDS14070475).

<TubeBundle> – OPC UA Object(s) that are part of the Object Type.

DesignPower – The design power of the ElectricHeater.

8.35 PlateAndShellHeatExchangerType

A corrugated plate heat exchanger that has a corrugated plate pack inside a shell (from http://data.posccaesar.org/rdl/RDS441719).

NumberOfPlates – The number of plates in the PlateAndShellHeatExchanger.

PlateHeight – The height of the plates in the PlateAndShellHeatExchanger.

PlateWidth – The width of the plates in the PlateAndShellHeatExchanger.

8.36 ShellAndTubeHeatExchangerType

A tubular heat exchanger in which a tube bundle is surrounded by a shell (from http://data.posccaesar.org/rdl/RDS419084).

<TubeBundle> – OPC UA Object(s) that are part of the Object Type.

TemaStandardTypeAssignmentClass – The type of the ShellAndTubeHeatExchanger according to the Tubular Exchanger Manufacturers Association, Inc. (TEMA, http://www.tema.org). This is a three-letter code.

8.37 SpiralHeatExchangerType

A spiral heat exchanger

8.38 ThinFilmEvaporatorType

A thin film evaporator.

<Rotor> – OPC UA Object(s) that are part of the Object Type.

DesignPower – The design power of the ThinFilmEvaporator.

DesignRotationalSpeed – The design rotational speed of the ThinFilmEvaporator.

DesignShaftPower – The design shaft power of the ThinFilmEvaporator.

8.39 MixerType

An object that mixes two or more different ingredients.

<MixingElementAssembly> – OPC UA Object(s) that are part of the Object Type.

8.40 KneaderType

A kneading machine that kneads different ingredients.

DesignRotationalSpeed – The design rotational speed of the Kneader.

DesignShaftPower – The design shaft power of the Kneader.

UpperLimitAllowableDesignPressureDrop – The maximum allowable design pressure drop of the Kneader.

8.41 RotaryMixerType

Rotating mixer.

DesignShaftPower – The design shaft power of the RotaryMixer.

UpperLimitAllowableDesignPressureDrop – The maximum allowable design pressure drop of the RotaryMixer.

DesignRotationalSpeed – The design rotational speed of the RotaryMixer.

8.42 StaticMixerType

A physical object that is intended to mix fluid by means of diverging the flow with static obstacles or by increasing locally the velocity.

UpperLimitAllowableDesignPressureDrop – The maximum allowable design pressure drop of the StaticMixer.

8.43 ProcessColumnType

A vertical vessel intended to enable chemical reactions or physical processes utilising differences in density of fluids and/or forced flow of fluid (from http://data.posccaesar.org/rdl/RDS4316825224).

<ColumnSection> – OPC UA Object(s) that are part of the Object Type.

NominalCapacityVolume – The nominal volumetric capacity of the ProcessColumn.

8.44 PumpType

A physical object that is a driven piece of equipment in which energy is either constantly or periodically added to an amount of pumped liquid in order to increase the pressure required for the process in which the pump is in operation (from http://data.posccaesar.org/rdl/RDS327239).

DifferentialPressure – The differential pressure of the Pump.

DesignVolumeFlowRate – The volume flow rate for which the Pump is designed.

DesignPressureHead – The design pressure head of the Pump.

8.45 CentrifugalPumpType

A dynamic pump utilizing impellers provided with vanes generating centrifugal force to achieve the required pressure head (from http://data.posccaesar.org/rdl/RDS416834).

<Impeller> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the CentrifugalPump.

DesignShaftPower – The design shaft power of the CentrifugalPump.

8.46 EjectorPumpType

A pump which uses pressurized gas or liquid passing through an ejector to transport liquid (from http://data.posccaesar.org/rdl/RDS860624).

DesignCapacityMotiveFluid – The design capacity for the motive fluid of the EjectorPump.

8.47 ReciprocatingPumpType

a positive displacement pump which contains a displacing element intended to be moved in a reciprocating movement to exert pressure on a fluid, typically moving within a cylindrical space (from http://data.posccaesar.org/rdl/RDS416969).

<Displacer> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the ReciprocatingPump.

DesignShaftPower – The design shaft power of the ReciprocatingPump.

8.48 RotaryPumpType

A positive displacement pump that consists of a chamber containing gears, cams, screws, vanes, plungers or similar elements actuated by relative rotation of the drive shaft or casing and which has no separate inlet and outlet valves (from http://data.posccaesar.org/rdl/RDS420749).

<Displacer> – OPC UA Object(s) that are part of the Object Type.

DesignRotationalSpeed – The design rotational speed of the RotaryPump.