1 Scope

In their basic function of conveying fluids or gases, pumps and vacuum pumps perform elementary tasks in numerous technical processes in the process industry, building technology, the semiconductor and manufacturing industries, the food industry and water management. Additional functionalities, such as self-monitoring, the generation of status and diagnostic information, offer great potential for optimizing operating processes. Information for the identification of pumps is essential for device management, measured values for energy consumption are an important source for energy management applications, etc. Highly functional pumps are also multivariable devices (e.g. pressure, volume flow, temperature, etc.) because they require information about the process during operation. Their versatile use and special significance make pumps and vacuum pumps an important asset in the current developments around Industry 4.0 (I4.0).

I4.0 stands for the intelligent digital networking of products and processes to optimize the value chains of manufacturers and users. The central object of current developments is the I4.0-component, a composition of Administration Shell and asset. The Administration Shell represents the asset - e.g. a pump or vacuum pump - in the digital I4.0-world. Among other things, it consists of submodels that describe different aspects or functions of the asset in the form of standardized properties. They form the basis for a common language of pumps.

In 2019 pump manufacturers of the VDMA trade associations Pumps + Systems and Compressors, Compressed Air and Vacuum Technology have specified a manufacturer-independent Administration Shell for pumps and vacuum pumps for applications in the process industry, building technology, the semiconductor and manufacturing industries, the food industry and water management. The work focused on three main I4.0 application scenarios for the digital integration of pumps and vacuum pumps into the I4.0 information world: the support of continuous and dynamic engineering over the life cycle, optimized operation through transparency and adaptability of delivered products, and the provision of value-based services.

Based on acknowledged and applied National, European and International Standards the descriptions and definitions were used to develop submodels for pumps in the Administration Shell project. The developments are based on fundamental work in the I4.0 environment, which describes the general structure of the administration shell. On this basis, pump-specific submodels are developed. These are based on different standards which describe aspects and requirements of pumps. In this OPC UA Companion Specification the contents of the individual sumodels of the Asset Administration Shell were transferred to the information model of OPC UA.

Alongside the development of this OPC UA Companion Specification, the submodels and properties of the Asset Administration Shell for pumps and vacuum pumps were integrated into the product classification system ECLASS. Following the ECLASS Release 12.0 this OPC UA Companion Specification can be extended by the ECLASS references.

2 Normative references

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

OPC 10000-1

OPC 10000-2, OPC Unified Architecture - Part 2: Security Model

OPC 10000-2

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-6, OPC Unified Architecture - Part 6: Mappings

OPC 10000-6

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

OPC 10000-100, OPC Unified Architecture - Part 100: Devices

OPC 10000-100

OPC 40001-1, OPC UA for Machinery - Part 1: Basic Building Blocks

http://www.opcfoundation.org/UA/Machinery/

ISO 3529-2 - Vacuum technology – Vocabulary – Part 2: Vacuum pumps and related terms. ISO, 2018

ISO 6708 - Pipework components — Definition and selection of DN (nominal size). ISO, 1995

ISO 13372 - Condition monitoring and diagnostics of machines — Vocabulary. ISO, 2012

ISO 21360-2 - Vacuum technology — Standard methods for measuring vacuum-pump performance - Part 2: Positive displacement vacuum pumps. ISO, 2012

ISO/TR 25417 - Acoustics – Definitions of basic quantities and terms. ISO, 2007

IEC 62683-1 - Low-voltage switchgear and controlgear - Product data and properties for information exchange - Part 1: Catalogue data. VDE, 2017

DIN EN 61360-4 - Genormte Datenelementtypen mit Klassifikationsschema für elektrische Bauteile- Teil 4. Beuth Verlag, 2005

IEC 61987-1 - Industrial-process measurement and control - Data structures and elements in process equipment catalogues - Part 1: Measuring equipment with analogue and digital output. VDE, 2006

DIN EN 1333 - Flanges and their joints – Pipework components – Definition and selection of PN. Beuth-Verlag, 2006

DIN EN 13306 - Maintenance – Maintenance terminology. Beuth-Verlag, 2018

DIN EN 13460 - Maintenance – Documentation for maintenance; Beuth-Verlag, 2009

DIN EN ISO 17769 -1 - Liquid pumps and installation – General terms, definitions, quantities, letter symbols and units – Part 1: Liquid pumps. Beuth-Verlag, 2012

DIN EN ISO 17769 -2 - Liquid pumps and installation – General terms, definitions, quantities, letter symbols and units – Part 2: Pumping System. Beuth-Verlag, 2013

DIN 28400-2 - Vacuum technology; terms and definitions; vacuum pumps. Beuth-Verlag, 1980

DIN 28426-1 - Vacuum technology; acceptance specifications for rotary plunger vacuum pumps. Beuth-Verlag, 1983

IEC 60050-351 - International electrotechnical vocabulary –Part 351: Control technology. IEC, 2013

DIN EN ISO 80000-8 - Quantities and units – Part 8: Acoustics. Beuth-Verlag, 2020

VDMA 24223 - Device Profile for Liquid and Vacuum Pumps- Part I: Device Information Model, Universal Profile Elements Generic Pumps.” 2006

VDMA 24223 - Device Profile for Liquid and Vacuum Pumps- Part IIA: Vacuum Pumps.” 2006

VDI 3805-4 - Product data exchange in the building services (TGA) - Pumps. Beuth-Verlag, 1999

3 Terms, definitions and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling, OPC Unified Architecture - Part 100, and OPC UA for Machinery - Part 1 are understood in this specification. This specification will use these concepts to describe the OPC UA for Pumps and Vacuum Pumps 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-100, OPC 40001-1, and VDMA 24223.

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

3.2 OPC UA for Pumps and Vacuum Pumps terms

3.2.1 PumpClass

Specific type of a Pump and value of the PumpClass Variable of an instance of the FunctionalGroup Design of a Pump.

3.2.2 FunctionalGroup

Instance of the 2:FunctionalGroupType or one of its subtypes.

Note 1 to entry: In this specification, FunctionalGroup usually refers to an instance of a Pump specific ObjectType like OperationalGroupType, ActuationType, or DesignType.

3.2.3 KindOfQuantity

aspect common to mutually comparable quantities

Note 1 to entry: The division of the concept of quantity into several kinds of quantity is to some extent arbitrary. Examples:

The quantities diameter, circumference, and wavelength, are generally considered to be quantities of the same kind, namely of the kind of quantity called length.

The quantities heat, kinetic energy, and potential energy, are generally considered to be quantities of the same kind, namely of the kind of quantity called energy.

Note 2 to entry: Quantities of the same kind within a given system of quantities have the same dimension of a quantity. However, quantities of the same dimension are not necessarily of the same kind.

Examples: The quantities moment of force and energy are not of the same kind, although they have the same dimension. Similarly for heat capacity and entropy, as well as for relative permeability and mass fraction.

Note 3 to entry: The term "kind" is mainly used in expressions such as "quantities of the same kind." Two quantities of the same kind are mutually comparable, so that they can be placed in order of magnitude. Length and mass are quantities of different kinds because they are not mutually comparable.

[SOURCE: ISO/IEC Guide 99:2007, 1.2, modified – Note 3 has been modified.]

3.2.4 Port

Connection point to a Pump used for fluids or auxiliary devices.

Note 1 to entry: Ports are described in chapter 6.2.

3.2.5 Pump

Asset of the DeviceClass Pump and representation of a pump or vacuum pump.

Note 1 to entry: This term includes all described pump types defined in this specification.

3.3 Conventions used in this document

3.3.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.

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.3.2.2).

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 and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.3.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined they are separated by commas. The name or the short name may be used.

3.3.2 NodeIds and BrowseNames

3.3.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 document 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 document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document 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 document, because they are not defined by this document but generated by the Server.

3.3.2.2 BrowseNames

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

If the BrowseName is not defined by this document, a namespace index prefix like ‘0:EngineeringUnits’ or ‘2:DeviceRevision’ is added to the BrowseName. This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 158 provides a list of namespaces and their indexes as used in this document.

3.3.3 Common Attributes

3.3.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 4 shall be set as specified in the table.

3.3.3.2 Objects

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

3.3.3.3 Variables

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

3.3.3.4 VariableTypes

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

3.3.3.5 Methods

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

4 General information to Pumps and Vacuum Pumps and OPC UA

4.1 Introduction to Pumps and Vacuum Pumps

Pumps are important industrial plant components in e.g. process industry, manufacturing industry and building engineering services. Due to a large installed basis, they allocate considerable capital and resources in numerous plants. An elementary task of pumps in operational process control engineering is to fulfill their basic function of conveying liquids or evacuating gases. Apart from the basic function, additional functionalities, e.g. self-monitoring, the generation of condition information and innovative diagnostics, open up a large potential for the optimization of the maintenance. To avoid breakdowns and to minimize downtimes of a production plant, self-monitoring and diagnostic functionalities are requested by plant operators. Information about the identification of pumps is essential for the audit trail and device management, the energy consumption is important for energy management applications etc. High-functional pumps are multivariable devices since they need information about the process. Such pumps are also a window to the process, an important source for additional information about the current process state [1].

Therefore, the integration of the informational bookkeeping of pumps into process control engineering is not only important for operational process control. Particularly its integration into a comprehensive plant asset management (e.g. foresighted maintenance) and plant energy management activates the full potential of pumps [1].

4.2 Introduction to OPC Unified Architecture

4.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 art 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 for 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 OPC UA for Pumps and Vacuum Pumps, 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 examples. For a more complete overview see OPC 10000-1.

4.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.

4.2.3 Information modelling in OPC UA

4.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. illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all of 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 modeler 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 modeler may decide that the existing ObjectType in some cases needs an additional Variable. The modeler 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 – The OPC UA Information Model Notation. 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 required 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)

4.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. Each namespace in OPC UA has a globally unique string called a NamespaceUri which identifies a naming authority and a locally unique integer called a NamespaceIndex, which is an index into the Server's table of NamespaceUris. The NamespaceIndex is unique only within the context of a Session between an OPC UA Client and an OPC UA Server- the NamespaceIndex can change between Sessions and still identify the same item even though the NamespaceUri's location in the table has changed. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for Nodes. The same globally unique NodeId can be used as the identifier in a node in many Servers – the node's instance data may vary but its semantic meaning is the same regardless of the Server it appears in. This means Clients can have built-in knowledge of what the data means in these 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.

4.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.

5 Use cases

5.1 Device Identification

The use case Device Identification forms the basis for the operation of a Pump and the operators plant asset management, e.g. Documentation Management, Energy Management and Maintenance Management. For this purpose, the Pump shall provide properties for asset identification.

In addition to nameplate information of the Pump, the operator / integrator requires properties to describe its functional role and installation place.

5.2 Configuration

This use case describes the pre-configuration and commissioning of Pump based on standardized manufacturer and operator information. For this purpose, general characteristics about the pump type shall be provided by the manufacturer. Properties that describe operational requirements for Pumps during operation shall be specified by the operator. Additionally, manufacturer and operator information of a Pump shall be compared.

5.3 Maintenance Management

For the integration of Pump in an operator's maintenance management application, the Pump should provide properties for general maintenance and the three strategies breakdown maintenance, preventive maintenance, and condition based maintenance.

To support asset monitoring, the Pump collects and analyzes operational and historical data (e.g. current values, deviations, performance, wear). Since plant operators require a generalized health status of plant assets, the Pump shall provide a generalized health status, based on the NAMUR NE107 categories.

Additionally, the Pump shall provide maintenance documentation, e.g. for ordering maintenance and wear parts.

5.4 Operation

This use case specifies all properties that characterize the operation of a Pump (e.g. current measurement and control values). It is based on measurements, events, and further information from the Pump operation. These can be collected and analyzed by the manufacturer or operator. Based on this analysis, Pumps can be reconfigured or updated during operation. In addition, new services can be loaded into the Pump to optimize pump operation.

6 OPC UA for Pumps and Vacuum Pumps information model overview

6.1 Modelling Concepts

The content of this OPC UA Companion Specification is based on the asset administration shell for pumps and vacuum pumps. The asset administration shell and its submodels were modeled to describe the whole life cycle of a Pump.

The organization Plattform Industrie 4.0 published the specification Details [2] of the Asset Administration Shell to define the concept and metamodel for asset administration shells. The specification describes every aspect of asset administration shells in detail and should be used for reference purposes.

Figure 6 shows an abstract example on the composition of an I4.0 component and the content of an asset administration shell.

An asset administration shell is defined by the Plattform Industrie 4.0 organization as a “standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems. It identifies the Administration Shell and the assets represented by it, holds digital models of various aspects (submodels) and describes technical functionality exposed by the Administration Shell or respective assets. ” [2]

The content of an asset administration shells consists of submodels and properties. “Each submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodels templates.” [2]

This OPC UA Companion Specification transfers the contents of the asset administration shell for pumps and vacuum pumps into an OPC UA model by defining generic and specific ObjectTypes, VariableTypes and DataTypes. In general, submodels are modeled as subtypes of the 2:FunctionalGroupType of OPC 10000-100. The pump, i.e. the asset administration shell, is modeled as a subtype of the 2:TopologyElementType of OPC 10000-100.

For more information about the asset administration shell metamodel, it is recommended to consult the Details of the Asset Administration Shell specification [2].

6.2 Model Overview

In this OPC UA Companion Specification there are several subtypes of the 2:FunctionalGroupType and the 2:TopologyElementType defined. Figure 7 shows the general relationships between the PumpType and the FunctionalGroups.

6.2.1 Ports

A Pump has several Ports. While most Pumps have inlet and outlet Ports, the number of other Ports may vary. For this reason, the concept of Ports is introduced. Ports can be used to connect other components or systems to the Pump. In this specification, the input and output Ports, as well as the drive Port for the connection of the pump drive are defined. A port is not part of a submodel and therefore a port is modeled as a separate BaseObject and not, like submodels, as a FunctionalGroup. Figure 8 shows how the Port concept was integrated into this OPC UA Companion Specification.

6.2.2 Variables

In most cases Variables have the TypeDefinition 0:DataItemType or one of its subtypes. The optional Property Definition can be added to a Variable that uses such a TypeDefinition. This allows manufacturers to store a specific definitions for each Variable.

Variables defined in this specification that have the TypeDefinition 0:BaseAnalogType or one of its subtypes, usually have a predefined unit for the 0:EngineeringUnits Property. If no value is specified, the 0:EngineeringUnits Property should not be instantiated, or the Value Attribute shall be Null. To comply with this Companion Specification, the default values specified should be used for the 0:EngineeringUnits Property. The 0:EngineeringUnits should be sensible to the use of the application.

Variables that use the DataType Boolean are modelled with the TypeDefinition 0:TwoStateDiscreteType. Such Variables have the TrueState and FalseState Properties which shall be used for defining the actual states.

Variables that are children of the SupvervisionType or one of its subtypes represent supervision states. Such a supervision state is active if the Boolean value is True (see example 1).

Variables that are not children of SupvervisionType or one of its subtypes provide defined True and False states in their description (see Example 2).

6.2.3 FunctionalGroups

Where it made sense, the BrowseName of a FunctionalGroup was taken from the recommendation in OPC 10000-100.

A FunctionalGroup that would have no Variables, Objects, or Methods if instantiated shall not be instantiated.

6.3 Extending FunctionalGroups

The manufacturer or system integrator of a Pump may wish to add Variables, Objects, or Methods which are not yet defined by this specification. In such a case the additional Variables, Objects, or Methods shall be added to an appropriate FunctionalGroup of the component. It is important, that the Variables, Objects, or Methods which are added match the description of the FunctionalGroup they are added to. If there is no FunctionalGroup available the Variables, Objects, and Methods fit in, the manufacturer or system integrator shall create a new Object of the 2:FunctionalGroupType.

It is also possible to define a subtype of the 2:FunctionalGroupType or one of its subtypes to define a new collection of Variables, Objects, or Methods. When subtyping, the manufacturer or system integrator should keep in mind, that all Variables, Objects, and Methods of the supertype are also available to the new subtype.

In general, no new Variables, Objects, or Methods shall be created that are already available in this specification. If the manufacturer or system integrator wants to add already existing Variables, Objects, or Methods to another FunctionalGroup, the Organizes ReferenceType shall be used.

When creating new Variables that are not specified by this specification and are representing measurements the 0:BaseAnalogType should be used as TypeDefinition. If such a Variable can be matched to a physical quantity, this Variable should have the additional subcomponent KindOfQuantity that stores the physical quantity information (see chapter 7.32). If the new Variable has a predefined unit, for example hours or meters, the optional Property 0:EngineeringUnits should be used. The Property 0:Definition shall also be used to further clarify the intended purpose of the Variable.

7 OPC UA ObjectTypes

7.1 PumpType ObjectType Definition