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

Figure 7shows all ObjectTypeswhich are defined by this companion specification.

image012.png image013.png

In most cases Variableshave the TypeDefinition DataItemType or one of its subtypes. The optional PropertyDefinition can be added to a Variablethat uses such a TypeDefinition. This allows manufacturers to store a specific definition for each Variable.

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

When applicable, the BrowseNameof a FunctionalGroupwas taken from the recommendation in OPC 10000-100.

A FunctionalGroupthat would have no Variables, Objects, or Methodsif instantiated shall not be instantiated.

Machines or systems downstream the Compressed Air Systemthat 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 Systemsetup. 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 Attributeof the Nodethat serves as the output of the Compressed Air System. Common examples of Customer Distribution Pointsare presented in chapter 6.3 Airnet Examples.

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

image014.png

Figure 8– Simple Airnet

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

image015.png

Figure 9– Two Simple Airnets

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

image016.png

Figure 10– Connected Airnets

Figure 11shows two overlapping Airnetsof the same Compressed Air System. The inlet of the red (upper) Airnetis the sum of compressors C1 and C2. The two outlets of the red Airnetare the upper and the lower Customer Distribution Points. All CASPartsthat are inside the red box are connected to the red Airnetand treated as such. The inlet of the blue (lower) Airnetis the sum of compressors C3 and C4. The outlet of the blue Airnet is the lower Customer Distribution Point. All CASPartsthat are inside the blue box are connected to the blue Airnetand 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 Airnetis the active Airnet for M2. Valve CV3 is connected to the red Airnetand not to the blue Airnet, because its purpose is to divert the air from the Airnetwith the higher pressure (red, 11 bar) to the lower distribution point and not from the Airnetwith the lower pressure (blue, 8 bar) to the upper distribution point. The Main Control Systemis not a part of any Airnet.

image017.png

Figure 11– Overlapping Airnets

The Compressed Air Systemand Airnetsare identified by an Identification Objectof the CASIdentificationType which uses the InterfaceITagNameplateType and its Properties.

The Main Control Systemis identified by an Identification Objectof the MachineryComponentIdentificationType.

Componentsare identified by an Identification Objectof 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 Componentand have access to vendor defined information about the Componentand manage user-specific information for the identification of the Component. When instantiating a Component, the Identification Objectmust use an appropriate subtype of the MachineryItemIdentificationType.

For all Components and theMain Control Systemthe DeviceClass Propertyhas its Value Attributeset to a mandatory specific value and its ModellingRulechanged to mandatory.

Table 9shows for each CASPartwhat value shall be set for different applications like the DeviceClass, BrowseNameand GroupName.

Table 9– DeviceClass, BrowseName and GroupName for CASParts

CASPart Name

DeviceClass

BrowseName

GroupName

Airnet

-

Airnet

Airnets

Charging System

Charging system

ChargingSystem

ChargingSystems

Compressor

Compressor

Compressor

Compressors

Condensate Drain

Condensate drain

CondensateDrain

CondensateDrains

Condensate Separator

Condensate separator

CondensateSeparator

CondensateSeparators

Converter

Converter

Converter

Converters

Cooling System

Cooling system

CoolingSystem

CoolingSystems

Dryer

Dryer

Dryer

Dryers

Filter

Filter

Filter

Filters

Heat Recovery System

Heat recovery system

HeatRecoverySystem

HeatRecoverySystems

Main Control System

MCS

MCS

-

Receiver

Receiver

Receiver

Receivers

Sensor

Sensor

Sensor

Sensors

Valve

Valve

Valve

Valves

For Componentsthat are not defined by this specification, the DeviceClass Propertyshall 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 Componentsthat are considered as machines by their manufacturer or the customer shall be added to the Machines Objectdefined in OPC 40001-1and use the MachineIdentificationType as TypeDefinition for their Identification Object. The Compressed Air System, the Main Control System, and Airnetsare not considered as machine in the sense of OPC 40001-1, whereas the following Componentsmay be considered as machines in this context (this list is not exhaustive):

  • Compressors
  • Converters
  • Dryers

The manufacturer or system integrator of a Compressed Air Systemmay wish to add Variables, Objects, or Methodswhich are not yet defined by this specification. In such a case the additional Variables, Objects, or Methodsshall be added to an appropriate FunctionalGroupof the Component. It is important, that the Variables, Objects, or Methodswhich are added match the description of the FunctionalGroupthey are added to. If there is no FunctionalGroupavailable the Variables, Objects, and Methodsfit in, the manufacturer or system integrator shall create a new Objectof 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 Methodsof the supertype are also available to the new subtype.

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

When creating Variableswhich are representing Quantities, the BaseAnalogType or one of its subtypes shall be used as TypeDefinition. When creating Variablewhich are not representing Quantities, the DataItemType or one of its subtypes, other than the BaseAnalogType, shall be used as TypeDefinition. Either way, the Definition Propertyshall be instantiated to further clarify the intended purpose of the Variable.

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

image018.png

Figure 12– Extending FunctionalGroups

Most CASParts have an optional FunctionalGroupwith the default BrowseNameEvents. This FunctionalGroupprovides Objectsfor 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 CASPartmust 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 Objectsof a CASPart. In that case, the Variable or Objectis the SourceNodeand the condition instance is the TargetNode. If such an alarm or condition is created, the CASPart shall have a HasEventSource reference with the CASPartas SourceNode and the Variableor Objectas TargetNode.

EXAMPLEA high limit alarm is needed for the Temperature Quantityat the process fluid inlet of a dryer. The Object InletTemperatureHighLimitAlarm using the ExclusiveLimitAlarmType as TypeDefinitionis created as child of the Events Object of the dryer instance. A HasCondition reference is created with the Temperature Quantityas SourceNodeand the InletTemperatureHighLimitAlarm as TargetNode. The dryer receives a HasEventSource reference to the Temperature Quantity.

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

Every instantiated Componentshall 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.

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.

Table 10– Severity Categorization

Severity

Lower limit

Upper limit

HIGH

801

1000

MEDIUM HIGH

601

800

MEDIUM

401

600

MEDIUM LOW

201

400

LOW

1

200

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

image019.png

Figure 13– Alarms and Conditions

All Component ObjectTypes in this specification (clauses 7.87.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 ObjectTypefor one of the existing Components, the ObjectTypeof that Componentshall 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 SourceNodefor the new ObjectType.

If a manufacturer or system integrator wants to add a Componentwhich 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 DataTypeof Design_ComponentClassmust be changed to a concrete DataType.

Either way, in most cases a new Enumeration DataTypeis required to specify which ComponentClassesare possible for the new Component. The DataTypeshall be provided by the same party that introduces the new ObjectType.

Figure 14shows 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 Componenttype in a separate Namespace. The right panel shows the use of the CASComponentType as TypeDefinition for a new Componentin a separate namespace. For each approach, the corresponding new enumeration is shown below.

image020.png

Figure 14– Adding New Component Types

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 15shows an abstract example on the composition of an I4.0 component and the content of an asset administration shell.

image021.jpg

Figure 15– I4.0 Component Consisting of Asset and 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.”

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

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