1 Scope

The OPC UA Compressed Air Systems (CAS) Companion Specification includes a description of a system and a basic description of its components regarding a Compressed Air System. Main scope of this specification is the communication between the Main Control System and the higher-level manufacturing system(s). More specific, it is the transport of condition data of a CAS vertically into higher level manufacturing systems (MES; etc.) for information and monitoring purposes and to set basic parameters regarding the target values of the respective CAS. The description of the CAS and its components is focused on selected use cases, e. g. device identification, configuration, maintenance management, energy management, and operation.

This Companion Specification is not intended to provide viable representations for components such as compressors or dryers outside the context of a compressed air system. It is not intended to use parts of this Companion Specification outside the context of a compressed air system. Particularly, it is not intended to use the components in the context of machine-to-machine communication.

Note: The focus lies on the system which the MCS represents. The MCS communicates with other machines outside of this system. It matches the demand of several users with the compressed air generation by controlling the components especially the compressors of that compressed air system. Therefore, this Companion Specification cannot be directly compared with a Companion Specification for direct machine to machine communication where the component is directly integrated in another machine or process like the Companion Specification for pumps, machine tools, etc.

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-9, OPC Unified Architecture - Part 9: Alarms and Conditions

OPC 10000-9

OPC 10000-100, OPC Unified Architecture - Part 100: Device Information Model

OPC 10000-100

OPC 10000-200, OPC Unified Architecture - Part 200: Industrial Automation

OPC 10000-200

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

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

IEC 60050, International Electrotechnical Vocabulary

ISO 8573-1:2010-04, Compressed air – Part 1: Contaminants and purity classes

ISO 11011:2013, Compressed air — Energy efficiency — Assessment

ISO 50001, Energy management systems - Requirements with guidance for use

ISO 80000:2009, Quantities and units

NAMUR NE 107:2017-04-10, Self-monitoring and diagnosis of field devices

Details of the Asset Administration Shell – Part 1: The exchange of information between partners in the value chain of Industrie 4.0

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 Compressed Air Systems 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, as well as the following apply.

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

3.2 OPC UA for Compressed Air Systems terms

3.2.1 Airnet

Piping and all Components between at least two distinct points, the inputs and outputs of the Airnet, in a Compressed Air System.

Note 1 to entry: A Component can be connected to multiple Airnets.

Note 2 to entry: Airnets may touch or overlap each other.

Note 3 to entry: For examples on how Airnets can be used in the context of this specification see chapter 6.

3.2.2 CASPart

Identifiable and browsable element in a Compressed Air System.

Note 1 to entry: CASParts defined in this specification are: Airnet, all Components, Main Control System.

3.2.3 Component

CASPart that serves a particular purpose in compressed air generation, treatment, measurement, or storage.

Note 1 to entry: Components defined in this specification are: Charging System, Compressor, Condensate Drain, Condensate Separator, Converter, Cooling System, Dryer, Filter, Heat Recovery System, Receiver, Sensor.

Note 2 to entry: A Component may be connected to no, one, or more than one Airnet.

3.2.4 Compressed Air System

System that generates compressed air, consists of Components and at least one Airnet, and is commonly equipped with one Main Control System.

3.2.5 ComponentClass

Specific type of a Component and value of the ComponentClass Variable of an instance of the FunctionalGroup Design of a Component.

3.2.6 Customer Distribution Point

Connection point of a Compressed Air System to subsequent machines or systems.

Note 1 to entry: Usually the Customer Distribution Point is located at one of the outlets of an Airnet.

Note 2 to entry: The Customer Distribution Point provides Variables and/or Objects which describe the conditions of the compressed air.

3.2.7 DeviceClass

Specific class of a CASPart and value of the DeviceClass Property of an instance of the FunctionalGroup Identification of a CASPart.

Note 1 to entry: Available DeviceClasses for CASPart of this specification are listed in Table 9.

3.2.8 FunctionalGroup

Instance of the FunctionalGroupType or one of its subtypes.

Note 1 to entry: In this specification, FunctionalGroup usually refers to an instance of a Compressed Air System specific ObjectType like OperationalType, AnalysesType, or DesignType.

3.2.9 GroupName

BrowseName of instances of the OptionalPlaceholder Object <ComponentsGroup> of instances of the ObjectType ComponentsGroupType.

Note 1 to entry: Available GroupNames for part groups of this specification are listed in Table 9.

3.2.10 Integrated [Component]

A Component is Integrated if the Main Control System has control over the generation or treatment of compressed air.

Note 1 to entry: A compressor is Integrated if the Main Control System has control over the loaded state.

Note 2 to entry: The Main Control System can switch a Component between the two states Integrated and Isolated.

3.2.11 Isolated [Component]

A Component is Isolated if the Main Control System has no control over the generation or treatment of compressed air.

Note 1 to entry: A Component is Isolated if the Main Control System does not control the loaded state.

Note 2 to entry: The Main Control System can switch a Component between the two states Integrated and Isolated.

3.2.12 Main Control System

CASPart that controls all Components and Airnets simultaneously, represents the Compressed Air System, and serves for communication between the Components and higher-level systems.

3.2.13 Main Function [of a Component]

The actual main function of Components is not specified in this specification. The following examples of Main Functions do not imply the actual function of the referenced Component.

3.2.14 Quantity

A Variable representing physical measurements performed by a sensor, or calculations performed by a CASPart or the Main Control System to simulate a physical measurement.

Note 1 to entry: A physical quantity may be measured by an external sensor but is assigned to a specific CASPart.

Note 2 to entry: The measuring sensor may be integrated into the CASPart.

Note 3 to entry: A calculation performed on the Main Control System which is used by a Component shall be assigned to that Component.

3.2.15 Requirements [of an Airnet]

The actual requirements of an Airnet are not specified in this specification. The following examples of Requirements do not imply the actual requirements of an Airnet.

3.2.16 Unavailable [Compressor]

A compressor is Unavailable if it cannot be Integrated and controlled by the Main Control System.

Note 1 to entry: The Main Control System cannot switch a compressor from Unavailable to any other state.

3.3 Abbreviated terms

3.4 Conventions used in this document

3.4.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.4.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.4.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.4.2 NodeIds and BrowseNames

3.4.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.4.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 184 provides a list of namespaces and their indexes as used in this document.

3.4.3 Common Attributes

3.4.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.4.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.4.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.4.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.4.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 Compressed Air Systems and OPC UA

4.1 Introduction to Compressed Air Systems

This document  describes  an  information  model, which  aims  to  cover  the whole Compressed Air System. A typical Compressed Air System consists of several devices, such as compressors, dryers, filters, air quality monitoring units etc., it is commonly also equipped with a Main Control System. The latter is used to control and/or monitor the connected devices and gather information from the same. This aggregated information is often provided to higher level systems through existing field bus technology (e.g. Profibus, Modbus, CAN Bus), with the drawback that the content and structure of the provided information is highly dependent on the manufacturer of the Main Control System. With this specification an integration in a Main Control System would be possible.

The variety of Compressed Air System is rather wide. It could be e.g. two compressors and a Main Control System and a basic compressed air treatment as a minimum configuration. More complex Compressed Air System have several compressors which must be controlled and several Airnets of different pressures with specific dryers, filters etc.

Therefore, this specification covers a very broad range of systems as well as of applications.

A typical more complex Compressed Air System is described in the following figure:

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 Compressed Air Systems, 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 2.

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

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 4 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 5 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 6 – 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

Below is a list of possible use cases a Main Control System may implement fully or partly.

5.1 Device Identification

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

In addition to nameplate information of the CASParts of a Compressed Air System, the operator / integrator requires properties to describe its functional role and installation place.

An operator / integrator should be able to explore the topology of the Compressed Air System. All browsable Components shall be identifiable. This includes non-communicating Components (e.g. Airnet, receiver) as well as assets capable of communication (e.g. compressor).

5.2 Configuration

To improve commissioning respective recommissioning time, the operator / integrator requires support in configuration of the Compressed Air System. Configuration procedures due to replacement, upgrades, etc. should be supported by configuration templates and loading / storing of configuration settings.

5.3 Maintenance Management

For the integration of Compressed Air System Components in an operator's maintenance management application, the Main Control System should provide Compressed Air System specific maintenance properties.

To support asset monitoring, the Main Control System 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 Main Control System shall provide a generalized Compressed Air System health status, based on the NAMUR NE107 categories. Each Component should have a specific set of alarms and conditions assigned to it.

5.4 Energy Management

To integrate a Compressed Air System into the operator´s energy management, the Main Control System should provide energy-related information about the Compressed Air System and its installed CASParts, e.g. power consumption, flow, pressure, efficiency. The provided information is calculated or measured, representing current values, or aggregated in time (weekly, monthly etc.).

The operator should be able to trigger analyses of the Compressed Air Systems energy performance within the Main Control System.

5.5 Operation

An operator / integrator should be able to remotely activate / deactivate (via the Main Control System) the generation of compressed air. It should be possible to select from different operating modes for the Compressed Air System.

For the operators / integrators process monitoring, the Main Control System provides access to standardized state machine information, alarms, warnings, and events. The operator monitors the generation of compressed air by accessing operational data of the Compressed Air System via the Main Control System. The Main Control System shall provide actual values of e.g. pressure, flow, inlet / outlet temperature and power consumption. Actual values of other Compressed Air System CASParts (e.g. sensors) should also be offered. To analyze historical data of Compressed Air System operation within the Main Control System, an operator / integrator may browse archive data in the Main Control System.

6 OPC UA for Compressed Air Systems Information Model

This section introduces the “OPC UA Information Model for Compressed Air Systems – Main Control System”.

6.1 Model Overview

Figure 7 shows all ObjectTypes which are defined by this companion specification.

6.1.1 Variables

In most cases Variables have the TypeDefinition 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 definition for each Variable.

Variables that use the DataType Boolean are modeled with the TypeDefinition TwoStateDiscreteType. Such Variables have the TrueState and FalseState Properties, which provide human readable and mandatory True and False states in their Value Attribute.

6.1.2 FunctionalGroups

When applicable, 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.2 Compressed air conditions for downstream machines or systems

Machines or systems downstream the Compressed Air System that use the compressed air require data on the condition of the compressed air. These conditions are provided at one or more Customer Distribution Points, depending on the concrete Compressed Air System setup. When modeling a Compressed Air System, the Customer Distribution Points shall be described as such. This can be done using external documentation, but it is recommended to use the Description Attribute of the Node that serves as the output of the Compressed Air System. Common examples of Customer Distribution Points are presented in chapter 6.3 Airnet Examples.

6.3 Airnet Examples

Figure 8 shows a simple model of an Airnet. The inlet of the Airnet is the sum of the inlets of compressors C1 and C2. The outlet of the Airnet is the Customer Distribution Point. All CASParts that are inside the red box are connected to the red Airnet and treated as such. The Main Control System is not a part of the Airnet.

Figure 9 shows a Compressed Air System with two separate Airnets. The inlet of the red (upper) Airnet is the sum of the inlets of compressors C1 and C2. The outlet of the red Airnet is the upper Customer Distribution Point. All CASParts that are inside the red box are connected to the red Airnet and treated as such. The inlet of the blue (lower) Airnet is the sum of the inlets of compressors C3 and C4. The outlet of the blue Airnet is the lower Customer Distribution Point. All CASParts that are inside the blue box are connected to the blue Airnet and treated as such. The Main Control System is not a part of any Airnet.

Figure 10 shows an arbitrary example on how two Airnets of the same Compressed Air System can be connected. The inlet of the red (bigger) Airnet is the sum of compressors C1, C2, C3, and C4. The two outlets of the red Airnet are the inlet of the dryer D3 and the lower Customer Distribution Point. All CASParts that are inside the red box are connected to the red Airnet and treated as such. The inlet of the blue (smaller) Airnet is the inlet of the dryer D3. The outlet of the blue Airnet is the upper Customer Distribution Point. All CASParts that are inside the blue box are connected to the blue Airnet and treated as such. The Main Control System is not a part of any Airnet.

Figure 11 shows two overlapping Airnets of the same Compressed Air System. The inlet of the red (upper) Airnet is the sum of compressors C1 and C2. The two outlets of the red Airnet are the upper and the lower Customer Distribution Points. All CASParts that are inside the red box are connected to the red Airnet and treated as such. The inlet of the blue (lower) Airnet is the sum of compressors C3 and C4. The outlet of the blue Airnet is the lower Customer Distribution Point. All CASParts that are inside the blue box are connected to the blue Airnet and treated as such. The sensor M2 is connected to both Airnets. If Valve CV3 is open, the red Airnet is the active Airnet for M2. If Valve CV3 is closed, the blue Airnet is the active Airnet for M2. Valve CV3 is connected to the red Airnet and not to the blue Airnet, because its purpose is to divert the air from the Airnet with the higher pressure (red, 11 bar) to the lower distribution point and not from the Airnet with the lower pressure (blue, 8 bar) to the upper distribution point. The Main Control System is not a part of any Airnet.

6.4 Identification

The Compressed Air System and Airnets are identified by an Identification Object of the CASIdentificationType which uses the Interface ITagNameplateType and its Properties.

The Main Control System is identified by an Identification Object of the MachineryComponentIdentificationType.

Components are identified by an Identification Object of a subtype of the abstract MachineryItemIdentificationType defined by OPC UA for Machinery (OPC 40001-1). The MachineryItemIdentificationType and its subtypes provide the capabilities to globally uniquely identify the Component and have access to vendor defined information about the Component and manage user-specific information for the identification of the Component. When instantiating a Component, the Identification Object must use an appropriate subtype of the MachineryItemIdentificationType.

For all Components and the Main Control System the DeviceClass Property has its Value Attribute set to a mandatory specific value and its ModellingRule changed to mandatory.

Table 9 shows for each CASPart what value shall be set for different applications like the DeviceClass, BrowseName and GroupName.

For Components that are not defined by this specification, the DeviceClass Property shall be mandatory as well. The value shall match the name of the new Component.

All properties of the MachineryItemIdentificationType and its subtypes shall be used as intended by the OPC UA for Machinery (OPC 40001-1) specification.

To comply with the Finding all Machines in a Server use case of the OPC UA for Machinery (OPC 40001-1) specification, all Components that are considered as machines by their manufacturer or the customer shall be added to the Machines Object defined in OPC 40001-1 and use the MachineIdentificationType as TypeDefinition for their Identification Object. The Compressed Air System, the Main Control System, and Airnets are not considered as machine in the sense of OPC 40001-1, whereas the following Components may be considered as machines in this context (this list is not exhaustive):

Compressors

Converters

Dryers

6.5 Extending FunctionalGroups

The manufacturer or system integrator of a Compressed Air System 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 FunctionalGroupType.

It is also possible to define a subtype of the 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 Variables which are representing Quantities, the BaseAnalogType or one of its subtypes shall be used as TypeDefinition. When creating Variable which are not representing Quantities, the DataItemType or one of its subtypes, other than the BaseAnalogType, shall be used as TypeDefinition. Either way, the Definition Property shall be instantiated to further clarify the intended purpose of the Variable.

Figure 12 illustrates some usage examples on how to extend FunctionalGroups of a compressor.

6.6 Alarms and Conditions

Most CASParts have an optional FunctionalGroup with the default BrowseName Events. This FunctionalGroup provides Objects for common alarms and conditions. In total four conditions are defined: EmergencyStop, Service, Shutdown, and Warning. An OptionalPlaceholder Object <Event> with the TypeDefinition ConditionType is defined. If a manufacturer or system integrator adds additional alarms or conditions to a CASPart, <Event> shall be used. When instantiating <Event>, a concrete subtypes of the abstract ConditionType has to be used as TypeDefinition. To comply with Annex B of OPC 10000-9 – Part 9: Alarms and Conditions, a CASPart must have a HasCondition reference for each instantiated condition using the condition instance as TargetNode and the CASPart as SourceNode.

A manufacturer or system integrator may add custom alarms and conditions targeting specific Variables or Objects of a CASPart. In that case, the Variable or Object is the SourceNode and the condition instance is the TargetNode. If such an alarm or condition is created, the CASPart shall have a HasEventSource reference with the CASPart as SourceNode and the Variable or Object as TargetNode.

To further comply with Annex B of OPC 10000-9, the Compressed Air System Object shall be the TargetNode of a HasNotifier reference, originating at the OPC UA Server Object. The Compressed Air System Object shall have a HasNotifier reference for each CASPart which instantiates alarms or conditions.

Every instantiated Component shall have at least one appropriate GeneratesEvent reference targeting the NAMUR NE 107 alarms defined in OPC 10000-100. These are CheckFunctionAlarmType, FailureAlarmType, MaintenanceRequiredAlarmType, and OffSpecAlarmType.

6.6.1 Severity

As defined by OPC 10000-5, all events shall have a severity assigned to them. This specification specifies specific severity ranges for some events. If no specific severity or severity range is provided for a defined event or condition, the manufacturer or integrator may choose from the default OPC UA range. The chosen severity when assigning it to a condition or event shall match the following categorization.

Figure 13 shows examples on how alarms and conditions shall be used in a Compressed Air System.

6.7 Adding new Components

All Component ObjectTypes in this specification (clauses 7.8 – 7.19) may be used for subtyping when defining more specific Components. If future companion specifications, a manufacturer, or system integrator wants to define a more specific ObjectType for one of the existing Components, the ObjectType of that Component shall be used as supertype.

If future companion specifications, a manufacturer, or system integrator wants to define a new Component which is not yet provided by this specification and which is no subtype of one of the existing Components, the CASComponentType shall be used as SourceNode for the new ObjectType.

If a manufacturer or system integrator wants to add a Component which is not yet defined by this specification and does not want to create a new ObjectType, the CASComponentType may be used as TypeDefinition for that Component. In such a case, the DataType of Design_ComponentClass must be changed to a concrete DataType.

Either way, in most cases a new Enumeration DataType is required to specify which ComponentClasses are possible for the new Component. The DataType shall be provided by the same party that introduces the new ObjectType.

Figure 14 shows all three approaches described above that a manufacturer or system integrator can take. The left panel shows the introduction of the new compressor type TurboCompressorType in a separate Namespace. The middle panel shows the introduction of a completely new Component type in a separate Namespace. The right panel shows the use of the CASComponentType as TypeDefinition for a new Component in a separate namespace. For each approach, the corresponding new enumeration is shown below.

6.8 Asset Administration Shell for Compressed Air Systems – Main Control System

This document was created in parallel with the asset administration shell for Compressed Air Systems – Main Control System.

The organization Plattform Industrie 4.0 published the specification Details 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.

Figure 15 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.” [1]

The content of an asset administration shell 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.” [1]

The content of this OPC UA Companion Specification is linked to the asset administration shell for Compressed Air Systems – Main Control Systems in a specific way. In general, submodels are modeled as subtypes of the FunctionalGroupType of OPC 10000-100.

7 OPC UA ObjectTypes

7.1 CASType ObjectType Definition

The CASType is the representation of a Compressed Air System and provides both Objects for Quantities and FunctionalGroups for its Airnets, Components, and the Main Control System. It is illustrated in Figure 16 and formally defined in Table 11.

The CASType ObjectType is a concrete type and shall be used directly.

The optional Object Airnets organizes all available Airnets.

The optional Object Components organizes all installed Components by their ComponentClasses.

The optional FunctionalGroup Identification provides Properties to identify a Compressed Air System.

The optional Object MCS is the representation of the Main Control System.

The InstanceDeclarations of the CASType have additional Attributes defined in Table 12.

Figure 17 shows a usage example for the instantiation of an arbitrary Compressed Air System that has two Airnets, two compressors, one dryer, and two valves. The Airnets share CompressorX.

For each DeviceClass connected to the Compressed Air System, there is one ComponentGroup Object in the Components Object of the CompressedAirSystem Object. The instances of the compressors, valves, and the dryer are children of these Objects.

Both Airnets have a Components Object, just like the CompressedAirSystem Object. For each DeviceClass connected to an Airnet, there is one ComponentGroup Object in the Components Object of that Airnet. Connected Components are referenced by an Organizes reference.

7.2 AirnetsType ObjectType Definition