Figure5_

Figure6_

OPC UA Companion Specification

OPC 40250-1

 

OPC UA for Compressed Air Systems

Part 1: Main Control Systems

 

 

 

Release 1.00.1

2021-07-13

OPC 40250-1 (Release 1.00.1) is identical with VDMA 40250-1:2021-09  - Description: Figure4_

Figure1_


Contents

 

Page

Foreword. 12

1              Scope. 14

2              Normative references. 14

3              Terms, definitions, and conventions. 15

3.1          Overview.. 15

3.2          OPC UA for Compressed Air Systems terms. 15

3.3          Abbreviated terms. 17

3.4          Conventions used in this document 18

4              General information to Compressed Air Systems and OPC UA. 22

4.1          Introduction to Compressed Air Systems. 22

4.2          Introduction to OPC Unified Architecture. 23

5              Use cases. 29

5.1          Device Identification. 29

5.2          Configuration. 29

5.3          Maintenance Management 29

5.4          Energy Management 29

5.5          Operation. 29

6              OPC UA for Compressed Air Systems Information Model 30

6.1          Model Overview.. 30

6.2          Compressed air conditions for downstream machines or systems. 31

6.3          Airnet Examples. 31

6.4          Identification. 34

6.5          Extending FunctionalGroups. 35

6.6          Alarms and Conditions. 36

6.7          Adding new Components. 38

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

7              OPC UA ObjectTypes. 40

7.1          CASType ObjectType Definition. 40

7.2          AirnetsType ObjectType Definition. 42

7.3          ComponentsGroupType ObjectType Definition. 42

7.4          AirnetType ObjectType Definition. 44

7.5          AirnetComponentsType ObjectType Definition. 46

7.6          MCSType ObjectType Definition. 47

7.7          CASComponentType ObjectType Definition. 49

7.8          ChargingSystemType ObjectType Definition. 53

7.9          CompressorType ObjectType Definition. 53

7.10        ConverterType ObjectType Definition. 54

7.11        CoolingSystemType ObjectType Definition. 55

7.12        DrainType ObjectType Definition. 56

7.13        DryerType ObjectType Definition. 57

7.14        FilterType ObjectType Definition. 58

7.15        HeatRecoverySystemType ObjectType Definition. 58

7.16        ReceiverType ObjectType Definition. 59

7.17        SensorType ObjectType Definition. 60

7.18        SeparatorType ObjectType Definition. 62

7.19        ValveType ObjectType Definition. 63

7.20        ElectricalQuantitiesType ObjectType Definition. 64

7.21        ElectricalCircuitType ObjectType Definition. 65

7.22        FluidQuantitiesType ObjectType Definition. 65

7.23        ParticleType ObjectType Definition. 66

7.24        FluidCircuitType ObjectType Definition. 67

7.25        AnalysisType  ObjectType Definition. 68

7.26        AnalysesType ObjectType Definition. 69

7.27        CalibrationType ObjectType Definition. 69

7.28        CASIdentificationType ObjectType Definition. 70

7.29        ConfigurationType ObjectType Definition. 70

7.30        AirnetConfigurationType ObjectType Definition. 70

7.31        MCSConfigurationType ObjectType Definition. 71

7.32        CommunicationSettingsType ObjectType Definition. 72

7.33        DesignType ObjectType Definition. 73

7.34        CompressorDesignType ObjectType Definition. 74

7.35        ConverterDesignType ObjectType Definition. 75

7.36        DrainDesignType ObjectType Definition. 75

7.37        DryerDesignType ObjectType Definition. 76

7.38        FilterDesignType ObjectType Definition. 76

7.39        ReceiverDesignType ObjectType Definition. 77

7.40        SensorDesignType ObjectType Definition. 77

7.41        SeparatorDesignType ObjectType Definition. 78

7.42        ValveDesignType ObjectType Definition. 78

7.43        EventsType ObjectType Definition. 79

7.44        MaintenanceType ObjectType Definition. 80

7.45        OperationalType ObjectType Definition. 81

7.46        AirnetOperationalType ObjectType Definition. 82

7.47        CompressorOperationalType ObjectType Definition. 83

7.48        ConverterOperationalType ObjectType Definition. 85

7.49        DrainOperationalType ObjectType Definition. 85

7.50        DryerOperationalType ObjectType Definition. 86

7.51        ValveOperationalType ObjectType Definition. 88

7.52        StatisticsType ObjectType Definition. 88

7.53        CompressorStatisticsType ObjectType Definition. 89

8              OPC UA DataTypes. 90

8.1          FilterClassDataType. 90

8.2          SensorTechnologyOptionSet 90

8.3          CompressorTypeEnum.. 91

8.4          ConverterTypeEnum.. 91

8.5          DisplacementTypeEnum.. 92

8.6          DrainTypeEnum.. 92

8.7          DryerTypeEnum.. 93

8.8          FilterClassEnum.. 93

8.9          FilterTypeEnum.. 94

8.10        FluidTypeEnum.. 94

8.11        HealthStateEnum.. 95

8.12        AirnetHealthStateEnum.. 95

8.13        IntegratedStateEnum.. 95

8.14        AirnetIntegratedStateEnum.. 96

8.15        IpVersionEnum.. 96

8.16        LubricationTypeEnum.. 97

8.17        OperatingStateEnum.. 97

8.18        AirnetOperatingStateEnum.. 98

8.19        CompressorOperatingStateEnum.. 99

8.20        DryerOperatingStateEnum.. 100

8.21        ReceiverTypeEnum.. 101

8.22        SensorTypeEnum.. 102

8.23        SeparatorTypeEnum.. 102

8.24        ValveTypeEnum.. 103

9              Profiles and ConformanceUnits. 104

9.1          Conformance Units. 104

9.2          Facets and Profiles. 105

10           Namespaces. 112

10.1        Namespace Metadata. 112

10.2        Handling of OPC UA Namespaces. 113

Annex A (normative)  OPC UA for Compressed Air Systems Namespace and mappings. 114

Annex B (normative)  Edge Cases for Component and Airnet Handling. 115

Annex C (informative)  Bibliography. 116

 

Figures

Figure 1 – Compressed Air System.. 22

Figure 2 – The Scope of OPC UA within an Enterprise. 23

Figure 3 – A Basic Object in an OPC UA Address Space. 24

Figure 4 – The Relationship between Type Definitions and Instances. 25

Figure 5 – Examples of References between Objects. 26

Figure 6 – The OPC UA Information Model Notation. 27

Figure 8 – All ObjectTypes. 30

Figure 8 – Simple Airnet 31

Figure 9 – Two Simple Airnets. 32

Figure 10 – Connected Airnets. 32

Figure 11 – Overlapping Airnets. 33

Figure 12 – Extending FunctionalGroups. 35

Figure 13 – Alarms and Conditions. 37

Figure 14 – Adding New Component Types. 38

Figure 15 – I4.0 Component Consisting of Asset and Administration Shell 39

Figure 16 – CASType Illustration. 40

Figure 17 – CASType Components Reference Instantiation Example. 41

Figure 18 – ComponentsGroupType Illustration. 42

Figure 19 – AirnetType Illustration. 44

Figure 20 – Airnet Components Example. 45

Figure 21 – MCSType Illustration. 47

Figure 22 – CASComponentType Illustration. 49

Figure 23 – CompressorType Illustration. 53

Figure 24 – ConverterType Illustration. 54

Figure 25 – DryerType Illustration. 56

Figure 26 – DryerType Illustration. 57

Figure 27 – FilterType Illustration. 58

Figure 28 – ReceiverType Illustration. 59

Figure 29 – SensorType Illustration. 60

Figure 30 – SeparatorType Illustration. 62

Figure 31 – ValveType Illustration. 63

Figure 32 – CompressorOperationalType State Machine Illustration. 84

Figure 33 –DryerOperationalType Adsorption Dryer State Machine Illustration. 86

Figure 34 –DryerOperationalType Refrigerant Dryer State Machine Illustration. 87

Figure 35 –DryerOperationalType Membrane Dryer State Machine Illustration. 87

Figure 36 – OperatingState State Machine Illustration. 97

Figure 37 – AirnetOperatingState State Machine Illustration. 98

Figure 38 – CompressorOperatingState State Machine Illustration. 99

Figure 39 – DryerOperatingState Refrigerant Dryer State Machine Illustration. 100

Figure 40 – DryerOperatingState Membrane Dryer State Machine Illustration. 100

Figure 41 – DryerOperatingState Adsorption Dryer State Machine Illustration. 101

 


 

Tables

Table 1 – Examples of DataTypes. 18

Table 2 – Type Definition Table. 19

Table 3 – Examples of Other Characteristics. 19

Table 4 – Common Node Attributes. 20

Table 5 – Common Object Attributes. 20

Table 6 – Common Variable Attributes. 21

Table 7 – Common VariableType Attributes. 21

Table 8 – Common Method Attributes. 21

Table 9 – DeviceClass, BrowseName and GroupName for CASParts. 34

Table 10 – Severity Categorization. 36

Table 11 – CASType Definition. 40

Table 12 – CASType Attribute values for child Nodes. 40

Table 13 – AirnetsType Definition. 42

Table 14 – AirnetsType Attribute values for child Nodes. 42

Table 15 – ComponentsGroupType Definition. 43

Table 16 – ComponentsGroupType Attribute values for child Nodes. 43

Table 17 – AirnetType Definition. 44

Table 18 – AirnetType Attribute values for child Nodes. 45

Table 19 – AirnetComponentsType Definition. 46

Table 20 – AirnetComponentsType Attribute values for child Nodes. 46

Table 21 – MCSType Definition. 47

Table 22 – MCSType Attribute values for child Nodes. 48

Table 23 – CASComponentType Definition. 50

Table 24 – CASComponentType Additional Subcomponents. 51

Table 25 – CASComponentType Attribute values for child Nodes. 52

Table 26 – ChargingSystemType Definition. 53

Table 27 – CompressorType Definition. 54

Table 28 – CompressorType Attribute values for child Nodes. 54

Table 29 – ConverterType Definition. 55

Table 30 – CoolingSystemType Definition. 55

Table 31 – DrainType Definition. 56

Table 32 – DrainType Attribute values for child Nodes. 56

Table 33 – DryerType Definition. 57

Table 34 – FilterType Definition. 58

Table 35 – HeatRecoverySystemType Definition. 58

Table 36 – ReceiverType Definition. 59

Table 37 – SensorType Definition. 60

Table 38 – SensorType Additional Subcomponents. 61

Table 39 – SensorType Attribute values for child Nodes. 61

Table 40 – SeparatorType Definition. 62

Table 41 – SeparatorType Attribute values for child Nodes. 62

Table 42 – ValveType Definition. 63

Table 43 – ElectricalQuantitiesType Definition. 64

Table 44 – ElectricalQuantitiesType Attribute values for child Nodes. 64

Table 45 – ElectricalCircuitType Definition. 65

Table 46 – ElectricalCircuitType Attribute values for child Nodes. 65

Table 47 – FluidQuantitiesType Definition. 65

Table 48 – FluidQuantitiesType Attribute values for child Nodes. 66

Table 49 – ParticleType Definition. 66

Table 50 – ParticleType Attribute values for child Nodes. 66

Table 51 – FluidCircuitType Definition. 67

Table 52 – FluidCircuitType Attribute values for child Nodes. 67

Table 53 – AnalysisType Definition. 68

Table 54 – AnalysisType Attribute values for child Nodes. 68

Table 55 – Trigger Method AddressSpace Definition. 68

Table 56 – AnalysesType Definition. 69

Table 57 – AnalysesType Attribute values for child Nodes. 69

Table 58 – CalibrationType Definition. 69

Table 59 – CalibrationType Attribute values for child Nodes. 69

Table 60 – CASIdentificationType Definition. 70

Table 61 – ConfigurationType Definition. 70

Table 62 – AirnetConfigurationType Definition. 70

Table 63 – AirnetConfigurationType Attribute values for child Nodes. 71

Table 64 – MCSConfigurationType Definition. 71

Table 65 – MCSConfigurationType Attribute values for child Nodes. 71

Table 66 – LoadConfigurationFile Method AddressSpace Definition. 72

Table 67 – SaveConfigurationFile Method AddressSpace Definition. 72

Table 68 – CommunicationSettingsType Definition. 72

Table 69 – CommunicationSettingsType Attribute values for child Nodes. 73

Table 70 – DesignType Definition. 73

Table 71 – DesignType Attribute values for child Nodes. 73

Table 72 – CompressorDesignType Definition. 74

Table 73 – CompressorDesignType Attribute values for child Nodes. 74

Table 74 – ConverterDesignType Definition. 75

Table 75 – ConverterDesignType Attribute values for child Nodes. 75

Table 76 – DrainDesignType Definition. 75

Table 77 – DrainDesignType Attribute values for child Nodes. 75

Table 78 – DryerDesignType Definition. 76

Table 79 – DryerDesignType Attribute values for child Nodes. 76

Table 80 – FilterDesignType Definition. 76

Table 81 – FilterDesignType Attribute values for child Nodes. 76

Table 82 – ReceiverDesignType Definition. 77

Table 83 – ReceiverDesignType Attribute values for child Nodes. 77

Table 84 – SensorDesignType Definition. 77

Table 85 – SensorDesignType Attribute values for child Nodes. 77

Table 86 – SeparatorDesignType Definition. 78

Table 87 – SeparatorDesignType Attribute values for child Nodes. 78

Table 88 – ValveDesignType Definition. 78

Table 89 – ValveDesignType Attribute values for child Nodes. 78

Table 90 – EventsType Definition. 79

Table 91 – EventsType Attribute values for child Nodes. 79

Table 92 – EventsType States and Severities for child Nodes. 79

Table 93 – MaintenanceType Definition. 80

Table 94 – MaintenanceType Attribute values for child Nodes. 80

Table 95 – OperationalType Definition. 81

Table 96 – OperationalType Attribute values for child Nodes. 81

Table 97 – AirnetOperationalType Definition. 82

Table 98 – AirnetOperationalType Attribute values for child Nodes. 83

Table 99 – CompressorOperationalType Definition. 83

Table 100 – CompressorOperationalType Attribute values for child Nodes. 84

Table 101 – ConverterOperationalType Definition. 85

Table 102 – ConverterOperationalType Attribute values for child Nodes. 85

Table 103 – DrainOperationalType Definition. 85

Table 104 – DrainOperationalType Attribute values for child Nodes. 85

Table 105 – DrainTest Method AddressSpace Definition. 85

Table 106 – DryerOperationalType Definition. 86

Table 107 – DryerOperationalType Attribute values for child Nodes. 88

Table 108 – ValveOperationalType Definition. 88

Table 109 – ValveOperationalType Attribute values for child Nodes. 88

Table 110 – StatisticsType Definition. 89

Table 111 – StatisticsType Attribute values for child Nodes. 89

Table 112 – CompressorStatisticsType Definition. 89

Table 113 – CompressorStatisticsType Attribute values for child Nodes. 89

Table 114 – FilterClassDataType Structure. 90

Table 115 – FilterClassDataType Definition. 90

Table 116 – SensorTechnologyOptionSet Values. 90

Table 117 – SensorTechnologyOptionSet Definition. 90

Table 118 – CompressorTypeEnum Items. 91

Table 119 – CompressorTypeEnum Definition. 91

Table 120 – ConverterTypeEnum Items. 91

Table 121 – ConverterTypeEnum Definition. 91

Table 122 – DisplacementTypeEnum Items. 92

Table 123 – DisplacementTypeEnum Definition. 92

Table 124 – DrainTypeEnum Items. 92

Table 125 – DrainTypeEnum Definition. 92

Table 126 – DryerTypeEnum Items. 93

Table 127 – DryerTypeEnum Definition. 93

Table 128 – FilterClassEnum Items. 93

Table 129 – FilterClassEnum Definition. 94

Table 130 – FilterTypeEnum Items. 94

Table 131 – FilterTypeEnum Definition. 94

Table 132 – FluidTypeEnum Items. 94

Table 133 – FluidTypeEnum Definition. 94

Table 134 – HealthStateEnum Items. 95

Table 135 – HealthStateEnum Definition. 95

Table 136 – AirnetHealthStateEnum Items. 95

Table 137 – AirnetHealthStateEnum Definition. 95

Table 138 – IntegratedStateEnum Items. 95

Table 139 – IntegratedStateEnum Definition. 96

Table 140 – AirnetIntegratedStateEnum Items. 96

Table 141 – AirnetIntegratedStateEnum Definition. 96

Table 142 – IpVersionEnum Items. 96

Table 143 – IpVersionEnum Definition. 96

Table 144 – LubricationTypeEnum Items. 97

Table 145 – LubricationTypeEnum Definition. 97

Table 146 – OperatingStateEnum Items. 97

Table 147 – OperatingStateEnum Definition. 98

Table 148 – AirnetOperatingStateEnum Items. 98

Table 149 – AirnetOperatingStateEnum Definition. 98

Table 150 – CompressorOperatingStateEnum Items. 99

Table 151 – CompressorOperatingStateEnum Definition. 99

Table 152 – DryerOperatingStateEnum Items. 100

Table 153 – DryerOperatingStateEnum Definition. 101

Table 154 – ReceiverTypeEnum Items. 101

Table 155 – ReceiverTypeEnum Definition. 101

Table 156 – SensorTypeEnum Items. 102

Table 157 – SensorTypeEnum Definition. 102

Table 158 – SeparatorTypeEnum Items. 102

Table 159 – SeparatorTypeEnum Definition. 102

Table 160 – ValveTypeEnum Items. 103

Table 161 – ValveTypeEnum Definition. 103

Table 162 – Conformance Units for OPC UA for Compressed Air Systems. 104

Table 163 – Facet and Profile URIs for OPC UA for Compressed Air Systems. 105

Table 164 – CAS Base Analyses Server Facet 106

Table 165 – CAS Advanced Analyses Server Facet 106

Table 166 – CAS Base Configuration Server Facet 106

Table 167 – CAS Advanced Configuration Server Facet 106

Table 168 – CAS Base Maintenance Management Server Facet 107

Table 169 – CAS Advanced Maintenance Management Server Facet 107

Table 170 – CAS Energy Management Server Facet 107

Table 171 – CAS Operation Server Facet 107

Table 172 – CAS Base Server Profile. 108

Table 173 – CAS Advanced Server Profile. 108

Table 174 – CAS Maintenance Management Server Profile. 109

Table 175 – CAS Energy Management Server Profile. 109

Table 176 – CAS Dynamic Server Profile. 109

Table 177 – CAS Full Server Profile. 110

Table 178 – CAS Base Client Profile. 110

Table 179 – CAS Advanced Client Profile. 111

Table 180 – CAS Dynamic Client Profile. 111

Table 181 – CAS Dynamic Client Profile. 111

Table 182 – NamespaceMetadata Object for this Document 112

Table 183 – Namespaces used in a OPC UA for Compressed Air Systems Server 113

Table 184 – Namespaces used in this document 113

 

 


 

OPC Foundation / VDMA

____________

AGREEMENT OF USE

COPYRIGHT RESTRICTIONS

·          This document is provided "as is" by the OPC Foundation and VDMA.

·          Right of use for this specification is restricted to this specification and does not grant rights of use for referred documents.

·          Right of use for this specification will be granted without cost.

·          This document may be distributed through computer systems, printed or copied as long as the content remains unchanged and the document is not modified.

·          OPC Foundation and VDMA do not guarantee usability for any purpose and shall not be made liable for any case using the content of this document.

·          The user of the document agrees to indemnify OPC Foundation and VDMA and their officers, directors and agents harmless from all demands, claims, actions, losses, damages (including damages from personal injuries), costs and expenses (including attorneys' fees) which are in any way related to activities associated with its use of content from this specification.

·          The document shall not be used in conjunction with company advertising, shall not be sold or licensed to any party.

·          The intellectual property and copyright is solely owned by the OPC Foundation and VDMA.

 

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC or VDMA specifications may require use of an invention covered by patent rights. OPC Foundation or VDMA shall not be responsible for identifying patents for which a license may be required by any OPC or VDMA specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC or VDMA specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION NOR VDMA MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION NOR VDMA BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830

COMPLIANCE

The combination of VDMA and OPC Foundation shall at all times be the sole entities that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials as specified within this document. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by VDMA or the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

TRADEMARKS

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of Germany.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.

 


 

Foreword

The OPC specifications contain OPC UA Companion Specifications of several industry sectors and are developed by members of VDMA and/or the OPC Foundation. OPC UA is a machine to machine communication technology to transmit characteristics of products (e.g. manufacturer name, device type or components) and process data (e.g. temperatures, pressures or feed rates). To enable vendor unspecific interoperability the description of product characteristics and process data has to be standardized utilizing technical specifications, the OPC UA companion specifications.

Note: In this Companion Specification, the “product” described is a system, the compressed air system. It is not intended to use the described components such as compressors or dryers outside the context of a compressed air system.

 

Revision 1.00.1 Highlights

Compared with previous versions, the following changes have been made:

Summary

Resolution

OPC 40250-1 1.0.0

Initial release

OPC 40250-1 1.00.1

(identical with VDMA 40250-1:2021-09)

-   Object node “ns=1;i=5033” is defined in nodeset but has no parent. This is an orphan node and has been deleted.

-   The Variable 0:DefaultInstanceBrowseName in the ObjectType AirnetsType had the ModellingRule "-". To avoid validation errors when using the NodeSetValidator, the value of the cell was deleted.

-   Nodes Airnets and 4:Components in the ObjectType CASType had the ModelingRule Mandatory in NodeSet, while the Document had the ModelingRule Optional. NodeSet has been adapted accordingly.

-   Nodes listed below had AccessLevel 3 in NodeSet, while the Document had the AccessLevel 1. NodeSet was adjusted accordingly. Nodes:

-  3:StartTime in ObjectType ElectricalQuantitiesType

-  3:StartTime in ObjectType FluidQuantitiesType

-  Volume in ObjectType ReceiverDesignType

-  3:ResetCondition in ObjectType StatisticsType

-  3:StartTime in ObjectType StatisticsType

-   Nodes listed below had AccessLevel 7 in NodeSet, while the Document had the AccessLevel 3. NodeSet was adjusted accordingly. Nodes:

-  ActiveAirnet in ObjectType CASComponentType

 

VDMA Compressors, Compressed Air and Vacuum Technology

The VDMA represents around 3300 German and European companies in the mechanical engineering industry. The industry represents innovation, export orientation, medium-sized companies and employs around four mil-lion people in Europe, more than one million of them in Germany.

In the VDMA association the industry-specific trade association Compressors, Compressed Air and Vacuum Technology represents the economic and technical interests of around 80 German manufacturers vis-à-vis customers and buyer organizations, the public, national and international authorities, and other business circles. Our three specialist departments are Process Compressors, Compressed Air and Vacuum Technology. The specialist department Compressed Air Technology is dedicated to this specification.

The objective of this industry-driven platform is to support the compressed air industry through a wide spectrum of activities and services such as standardization, statistics, marketing, public relations, trade fair policy, networking events and representation of interests.

Under the auspices of VDMA, a companion specification for compressed air is developed by leading compressed air manufacturers and users within the "VDMA OPC Compressed Air Systems Initiative".


 

OPC Foundation

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

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

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

      Secure: encryption, authentication, authorization and auditing

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

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


       

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

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

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

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

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

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

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

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

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

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

OPC 10000-6, OPC Unified Architecture - Part 6: Mappings

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

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

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

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

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

OPC 10000-9, OPC Unified Architecture - Part 9: Alarms and Conditions

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

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

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

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

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

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.

EXAMPLE 1         The compressor C1 is of the ComponentClass Axial turbo compressor.

EXAMPLE 2         The filter F1 is of the ComponentClass Activated carbon filter.

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.

EXAMPLE 1       The compressor C1 is of the DeviceClass Compressor.

EXAMPLE 2       The filter F1 is of the DeviceClass Filter.

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.

EXAMPLE 1         The compressor C1 has the FunctionalGroups Identification, Design, and Operational.

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.

EXAMPLE 1         The Object for organizing all compressors in this Compressed Air System uses the GroupName Compressors.

EXAMPLE 2         The Object for organizing all Airnets in this Compressed Air System uses the GroupName Airnets.

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.

EXAMPLE 1         Charging system: to keep pressure upstream above a set minimum pressure or within a set pressure range

EXAMPLE 2         Compressor: to deliver compressed air into the piping with an expected volume flow and at an expected pressure

EXAMPLE 3         Condensate drain: to remove condensate from the compressed air piping or a condensate storage to outside the pressure system

EXAMPLE 4         Condensate separator: to separate the hydrocarbon contents from the condensate to create a clean condensate that can easily be disposed of

EXAMPLE 5         Converter: to eliminates hydrocarbons from the compressed air stream to create class 1 (and better) oil free air

EXAMPLE 6         Cooling system: to reduce the compressed air temperature to a desired level

EXAMPLE 7         Dryer: to remove moisture from compressed air and dry compressed air to a pressure dew point below the required value

EXAMPLE 8         Filter: to remove particles and aerosols from the compressed air flow

EXAMPLE 9         Heat recovery system: Main function: to heat up a material or substance flow by using the heat generated by the compressed air system

EXAMPLE 10       Receiver: to store compressed air and provide a buffer

EXAMPLE 11       Sensor: to measure specific parameters in the compressed air system and provide the data

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.

EXAMPLE 1         A temperature Quantity is measured by an internal sensor of a compressor at its outlet.

EXAMPLE 2         A pressure Quantity is measured by an external sensor at the inlet and outlet of a filter.

EXAMPLE 3         The isentropic efficiency of a compressor is a Quantity which is calculated by the Main Control System but assigned to the compressor.

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.

EXAMPLE 1         The Airnet pressure shall be within range.

EXAMPLE 2         The dew point shall be within range.

EXAMPLE 3         The volume flow rate shall be within range.

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.

EXAMPLE 1         A compressor in an error state may be Unavailable.

3.3         Abbreviated terms

CAS     Compressed Air System

HOC     Heat of Compression Dryer

KPI       key performance indicator

MCS     Main Control System

VSD     Variable Speed Drive

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 .

Table 1 – Examples of DataTypes

Notation

Data­Type

Value­Rank

Array­Dimensions

Description

0:Int32

0:Int32

-1

omitted or null

A scalar Int32.

0:Int32[]

0:Int32

1

omitted or {0}

Single-dimensional array of Int32 with an unknown size.

0:Int32[][]

0:Int32

2

omitted or {0,0}

Two-dimensional array of Int32 with unknown sizes for both dimensions.

0:Int32[3][]

0:Int32

2

{3,0}

Two-dimensional array of Int32 with a size of 3 for the first dimension and an unknown size for the second dimension.

0:Int32[5][3]

0:Int32

2

{5,3}

Two-dimensional array of Int32 with a size of 5 for the first dimension and a size of 3 for the second dimension.

0:Int32{Any}

0:Int32

-2

omitted or null

An Int32 where it is unknown if it is scalar or array with any number of dimensions.

0:Int32{ScalarOrOneDimension}

0:Int32

-3

omitted or null

An Int32 where it is either a single-dimensional array or a scalar.

 

      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.

Table 2 – Type Definition Table

Attribute

Value

Attribute name

Attribute value. If it is an optional Attribute that is not set “--“ will be used.

 

 

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

ReferenceType name

NodeClass of the TargetNode.

BrowseName of the target Node. If the Reference is to be instantiated by the server, then the value of the target Node’s BrowseName is “--“.

DataType of the referenced Node, only applicable for Variables.

TypeDefinition of the referenced Node, only applicable for Variables and Objects.

Additional characteristics of the TargetNode such as the ModellingRule or AccessLevel.

NOTE Notes referencing footnotes of the table content.

 

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.

Table 3 – Examples of Other Characteristics

Name

Short Name

Description

0:Mandatory

M

The Node has the Mandatory ModellingRule.

0:Optional

O

The Node has the Optional ModellingRule.

0:MandatoryPlaceholder

MP

The Node has the MandatoryPlaceholder ModellingRule.

0:OptionalPlaceholder

OP

The Node has the OptionalPlaceholder ModellingRule.

ReadOnly

RO

The Node AccessLevel has the CurrentRead bit set but not the CurrentWrite bit.

ReadWrite

RW

The Node AccessLevel has the CurrentRead and CurrentWrite bits set.

WriteOnly

WO

The Node AccessLevel has the CurrentWrite bit set but not the CurrentRead bit.

 

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.

Table 4 – Common Node Attributes

Attribute

Value

DisplayName

The DisplayName is a LocalizedText. Each server shall provide the DisplayName identical to the BrowseName of the Node for the LocaleId “en”. Whether the server provides translated names for other LocaleIds is server-specific.

Description

Optionally a server-specific description is provided.

NodeClass

Shall reflect the NodeClass of the Node.

NodeId

The NodeId is described by BrowseNames as defined in 3.4.2.1.

WriteMask

Optionally the WriteMask Attribute can be provided. If the WriteMask Attribute is provided, it shall set all non-server-specific Attributes to not writable. For example, the Description Attribute may be set to writable since a Server may provide a server-specific description for the Node. The NodeId shall not be writable, because it is defined for each Node in this specification.

UserWriteMask

Optionally the UserWriteMask Attribute can be provided. The same rules as for the WriteMask Attribute apply.

RolePermissions

Optionally server-specific role permissions can be provided.

UserRolePermissions

Optionally the role permissions of the current Session can be provided. The value is server-specific and depend on the RolePermissions Attribute (if provided) and the current Session.

AccessRestrictions

Optionally server-specific access restrictions can be provided.

 

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.

Table 5 – Common Object Attributes

Attribute

Value

EventNotifier

Whether the Node can be used to subscribe to Events or not is server-specific.

 

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.

Table 6 – Common Variable Attributes

Attribute

Value

MinimumSamplingInterval

Optionally, a server-specific minimum sampling interval is provided.

AccessLevel

The access level for Variables used for type definitions is server-specific, for all other Variables defined in this specification, the access level shall allow reading; other settings are server-specific.

UserAccessLevel

The value for the UserAccessLevel Attribute is server-specific. It is assumed that all Variables can be accessed by at least one user.

Value

For Variables used as InstanceDeclarations, the value is server-specific; otherwise it shall represent the value described in the text.

ArrayDimensions

If the ValueRank does not identify an array of a specific dimension (i.e. ValueRank <= 0) the ArrayDimensions can either be set to null or the Attribute is missing. This behavior is server-specific.

If the ValueRank specifies an array of a specific dimension (i.e. ValueRank > 0) then the ArrayDimensions Attribute shall be specified in the table defining the Variable.

Historizing

The value for the Historizing Attribute is server-specific.

AccessLevelEx

If the AccessLevelEx Attribute is provided, it shall have the bits 8, 9, and 10 set to 0, meaning that read and write operations on an individual Variable are atomic, and arrays can be partly written.

 

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.

Table 7 – Common VariableType Attributes

Attributes

Value

Value

Optionally a server-specific default value can be provided.

ArrayDimensions

If the ValueRank does not identify an array of a specific dimension (i.e. ValueRank <= 0) the ArrayDimensions can either be set to null or the Attribute is missing. This behavior is server-specific.

If the ValueRank specifies an array of a specific dimension (i.e. ValueRank > 0) then the ArrayDimensions Attribute shall be specified in the table defining the VariableType.

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.

Table 8 – Common Method Attributes

Attributes

Value

Executable

All Methods defined in this specification shall be executable (Executable Attribute set to “True”), unless it is defined differently in the Method definition.

UserExecutable

The value of the UserExecutable Attribute is server-specific. It is assumed that all Methods can be executed by at least one user.

 


 

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:

Figure7_

Figure 1 – Compressed Air System


 

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.

Figure8_

Figure 2 – The Scope of OPC UA within an Enterprise


 

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.

Figure9_

Figure 3 – A Basic Object in an OPC UA Address Space


 

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.

Figure10_

Figure 4 – The Relationship between Type Definitions and Instances


 

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.

Figure11_

Figure 5 – Examples of References between 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.

Figure12_

Figure 6 – The OPC UA Information Model Notation

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.

Figure 7 – All ObjectTypes - Description: Figure2_ Figure13_


 

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.

Figure14_

Figure 8 – Simple 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.

Figure15_

Figure 9 – Two Simple Airnets

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.

Figure16_

Figure 10 – Connected Airnets


 

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.

Figure17_

Figure 11 – Overlapping Airnets


 

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.

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

Figure18_

Figure 12 – Extending FunctionalGroups

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.

EXAMPLE             A high limit alarm is needed for the Temperature Quantity at the process fluid inlet of a dryer. The Object InletTemperatureHighLimitAlarm using the ExclusiveLimitAlarmType as TypeDefinition is created as child of the Events Object of the dryer instance. A HasCondition reference is created with the Temperature Quantity as SourceNode and 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 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.

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 13 shows examples on how alarms and conditions shall be used in a Compressed Air System.

Figure19_

Figure 13 – Alarms and Conditions


 

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.

Figure20_

Figure 14 – Adding New Component Types


 

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.

Figure21_ 

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

Figure22_

Figure 16 – CASType Illustration

Table 11 – CASType Definition

Attribute

Value

BrowseName

CASType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasComponent

Object

Airnets

 

AirnetsType

O

0:HasComponent

Object

4:Components

 

ComponentsGroupType

O

0:HasComponent

Object

2:Identification

 

CASIdentificationType

O

0:HasComponent

Object

MCS

 

MCSType

O

 

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.

Table 12 – CASType Attribute values for child Nodes

Source Path

Description Attribute

Airnets

All airnets in a compressed air system as browsable objects.

4:Components

All components in a compressed air system as browsable objects.

2:Identification

Identification properties of the compressed air system.

MCS

Representation of the MCS in a compressed air system.

 

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.

Figure23_

Figure 17 – CASType Components Reference Instantiation Example


 

7.2         AirnetsType ObjectType Definition

The AirnetsType enables the grouping of Airnets. It is formally defined in Table 13.

Table 13 – AirnetsType Definition

Attribute

Value

BrowseName

AirnetsType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 4:MachineComponentsType defined in OPC 40001-1, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the 4:MachineComponentsType

0:HasProperty

Variable

0:DefaultInstanceBrowseName

0:QualifiedName

0:PropertyType

 

0:HasComponent

Object

4:<Component>

 

AirnetType

OP

 

The InstanceDeclarations of the AirnetsType have additional Attributes defined in Table 14.

Table 14 – AirnetsType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

0:DefaultInstanceBrowseName

“Airnets”

The default BrowseName for instances of the type.

4:<Component>

 

Represents of an airnet.

 

7.3         ComponentsGroupType ObjectType Definition

The ComponentsGroupType enables the grouping of Components and can be nested. It is illustrated in Figure 18 and formally defined in Table 15.

Figure24_

Figure 18 – ComponentsGroupType Illustration

Table 15 – ComponentsGroupType Definition

Attribute

Value

BrowseName

ComponentsGroupType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 4:MachineComponentsType defined in OPC 40001-1, i.e. inheriting the InstanceDeclarations of that Node.

0:HasComponent

Object

<ComponentsGroup>

 

4:MachineComponentsType

OP

0:HasComponent

Object

ChargingSystems

 

4:MachineComponentsType

O

0:HasComponent

Object

Compressors

 

4:MachineComponentsType

O

0:HasComponent

Object

CondensateDrains

 

4:MachineComponentsType

O

0:HasComponent

Object

CondensateSeparators

 

4:MachineComponentsType

O

0:HasComponent

Object

Converters

 

4:MachineComponentsType

O

0:HasComponent

Object

CoolingSystems

 

4:MachineComponentsType

O

0:HasComponent

Object

Dryers

 

4:MachineComponentsType

O

0:HasComponent

Object

Filters

 

4:MachineComponentsType

O

0:HasComponent

Object

HeatRecoverySystems

 

4:MachineComponentsType

O

0:HasComponent

Object

Receivers

 

4:MachineComponentsType

O

0:HasComponent

Object

Sensors

 

4:MachineComponentsType

O

0:HasComponent

Object

Valves

 

4:MachineComponentsType

O

 

The OptionalPlaceholder Object <ComponentsGroup> allows nesting this ObjectType to further categorize the referenced Components. It also allows adding concrete Component groups not defined by this specification.

The InstanceDeclarations of the ComponentsGroupType have additional Attributes defined in Table 16.

Table 16 – ComponentsGroupType Attribute values for child Nodes

SourcePath 

Description Attribute 

<ComponentsGroup>

All components of a specific type in a compressed air system as browsable objects.

ChargingSystems 

Organizes all charging systems connected to the compressed air system. 

Compressors 

Organizes all compressors connected to the compressed air system. 

CondensateDrains 

Organizes all condensate drains connected to the compressed air system. 

CondensateSeparators 

Organizes all condensate separators connected to the compressed air system. 

Converters 

Organizes all converters connected to the compressed air system. 

CoolingSystems 

Organizes all cooling systems connected to the compressed air system. 

Dryers 

Organizes all dryers connected to the compressed air system. 

Filters 

Organizes all filters connected to the compressed air system. 

HeatRecoverySystems 

Organizes all heat recovery systems connected to the compressed air system. 

Receivers 

Organizes all receivers connected to the compressed air system. 

Sensors 

Organizes all sensors connected to the compressed air system. 

Valves 

Organizes all valves connected to the compressed air system. 

 


 

7.4         AirnetType ObjectType Definition

The AirnetType is the representation of an Airnet and provides both Objects for Quantities and FunctionalGroups. It is illustrated in Figure 19 and formally defined in Table 17.

Figure25_

Figure 19 – AirnetType Illustration

Table 17 – AirnetType Definition

Attribute

Value

BrowseName

AirnetType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:TopologyElementType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node.

0:HasComponent

Object

Ambient

 

FluidQuantitiesType

O

0:HasComponent

Object

4:Components

 

AirnetComponentsType

O

0:HasComponent

Object

2:Configuration

 

AirnetConfigurationType

O

0:HasComponent

Object

ElectricalCircuit

 

ElectricalCircuitType

O

0:HasComponent

Object

2:Operational

 

AirnetOperationalType

O

0:HasComponent

Object

ProcessFluidCircuit

 

FluidCircuitType

O

 

 

 

 

 

 

The following nodes override nodes added by the 2:TopologyElementType

0:HasComponent

Object

2:Identification

 

CASIdentificationType

M

 

The optional Object Ambient provides Quantities for the ambient air conditions at an Airnet. Of the optional Variables of the FluidQuantitiesType only AbsolutePressure, DewPoint, RelativeHumidity, and Temperature are available.

The optional Folder Components provides Folders for organizing Components connected to the Airnet. Usually, the Components are grouped by their DeviceClass and shall be referenced by using the Organizes ReferenceType. The concrete instance of a Component shall be instantiated in the Components Folder of the CASType instance.

Figure 20 shows an example on how to instantiate the FunctionalGroup Components for an Airnet in the AddressSpace of an OPC UA Server.

Figure26_

Figure 20 – Airnet Components Example

The optional FunctionalGroup Configuration provides Variables for configuring the behavior of an Airnet.

The optional Object ElectricalCircuit provides Quantities for the electrical ports of an Airnet.

The mandatory FunctionalGroup Identification provides Properties to identify an Airnet.

The optional FunctionalGroup Operational provides Variables for process data used during normal operation of an Airnet, such as measurements, efficiencies, and states.

The optional Object ProcessFluidCircuit provides static design information about the process fluid as well as Quantities for the process fluids inlets, outlets, and delta of an Airnet.

The InstanceDeclarations of the AirnetType have additional Attributes defined in Table 18.

Table 18 – AirnetType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

Ambient

 

Measurements and calculations of ambient air at the topology element.

 

Ambient

AbsolutePressure

 

 

Measured or calculated actual absolute pressure of the environment in which the component, piping or system is working.

 

Ambient

DewPoint

 

 

Measured or calculated actual dew point of the environment in which the component, piping or system is working.

 

Ambient

RelativeHumidity

 

 

Measured or calculated actual relative humidity of the environment in which the component, piping or system is working.

 

Ambient

Temperature

 

 

Measured or calculated actual temperature of the environment in which the component, piping or system is working.

4:Components

 

Organizes components assigned to the airnet.

2:Configuration

 

Configure the behavior of the topology element.

ElectricalCircuit

 

Measurements and calculations of the electrical ports and delta of the topology element.

2:Identification

 

Identification properties of the topology element.

2:Operational

 

Data for normal operation of the topology element.

ProcessFluidCircuit

 

Measurements and calculations of the process fluid ports and delta of the topology element.

 

ProcessFluidCircuit

FluidType

 

 

Enumeration of possible process fluid types.

7.5         AirnetComponentsType ObjectType Definition

The AirnetComponentsType enables the grouping of Airnets. It is formally defined in Table 19.

Table 19 – AirnetComponentsType Definition

Attribute

Value

BrowseName

AirnetComponentsType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:FolderType defined in OPC 10000-5.

0:HasComponent

Object

<ComponentsGroup>

 

0:FolderType

OP

0:HasComponent

Object

ChargingSystems

 

0:FolderType

O

0:HasComponent

Object

Compressors

 

0:FolderType

O

0:HasComponent

Object

CondensateDrains

 

0:FolderType

O

0:HasComponent

Object

CondensateSeparators

 

0:FolderType

O

0:HasComponent

Object

Converters

 

0:FolderType

O

0:HasComponent

Object

CoolingSystems

 

0:FolderType

O

0:HasComponent

Object

Dryers

 

0:FolderType

O

0:HasComponent

Object

Filters

 

0:FolderType

O

0:HasComponent

Object

HeatRecoverySystems

 

0:FolderType

O

0:HasComponent

Object

Receivers

 

0:FolderType

O

0:HasComponent

Object

Sensors

 

0:FolderType

O

0:HasComponent

Object

Valves

 

0:FolderType

O

 

The OptionalPlaceholder Object <ComponentsGroup> allows adding concrete Component groups not defined by this specification.

The InstanceDeclarations of the AirnetComponentsType have additional Attributes defined in Table 20.

Table 20 – AirnetComponentsType Attribute values for child Nodes

Source Path

Description Attribute

<ComponentsGroup>

All components of a specific type connected to the airnet.

ChargingSystems 

Organizes all charging systems connected to the airnet. 

Compressors 

Organizes all compressors connected to the airnet. 

CondensateDrains 

Organizes all condensate drains connected to the airnet. 

CondensateSeparators 

Organizes all condensate separators connected to the airnet. 

Converters 

Organizes all converters connected to the airnet. 

CoolingSystems 

Organizes all cooling systems connected to the airnet. 

Dryers 

Organizes all dryers connected to the airnet. 

Filters 

Organizes all filters connected to the airnet. 

HeatRecoverySystems 

Organizes all heat recovery systems connected to the airnet. 

Receivers 

Organizes all receivers connected to the airnet. 

Sensors 

Organizes all sensors connected to the airnet. 

Valves 

Organizes all valves connected to the airnet. 

 


 

7.6         MCSType ObjectType Definition

The MCSType is the representation of a Main Control System and provides both Objects for Quantities and FunctionalGroups. It is illustrated in Figure 21 and formally defined in Table 21.

Figure27_

Figure 21 – MCSType Illustration

Table 21 – MCSType Definition

Attribute

Value

BrowseName

MCSType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:TopologyElementType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node.

0:HasComponent

Object

Analyses

 

AnalysesType

O

0:HasComponent

Object

2:Configuration

 

MCSConfigurationType

O

0:HasComponent

Object

ElectricalCircuit

 

ElectricalCircuitType

O

0:HasComponent

Object

Events

 

EventsType

O

0:HasComponent

Object

2:Operational

 

OperationalType

O

0:HasComponent

Object

2:Statistics

 

StatisticsType

O

 

 

 

 

 

 

The following nodes override nodes added by the 2:TopologyElementType

0:HasComponent

Object

2:Identification

 

4:MachineryComponentIdentificationType

M

 

The optional FunctionalGroup Analyses provides Objects and Methods for analyses that can be invoked on the Main Control System.

The optional FunctionalGroup Configuration provides Objects and Methods for configuring the behavior of the Main Control System.

The optional Object ElectricalCircuit provides Quantities for the electrical input of the Main Control System.

The optional FunctionalGroup Events provides Objects for alarms and conditions of the Main Control System. Of the available optional Objects in the EventsType, only Service and Warning are instantiated.

The mandatory FunctionalGroup Identification provides Properties to identify the Main Control System. The optional Variable DeviceClass has its ModellingRule changed to mandatory and its Value Attribute set to a specific value.

The optional FunctionalGroup Operational provides Variables for process data used during normal operation of the Main Control System, such as measurements, efficiencies, and states.

The optional FunctionalGroup Statistics provides Variables for statistical applications of the Main Control System, such as counters.

The InstanceDeclarations of the MCSType have additional Attributes defined in Table 22.

Table 22 – MCSType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

Analyses

 

Invokable analyses for the topology element.

2:Configuration

 

Configure the behavior of the topology element.

ElectricalCircuit

 

Measurements and calculations of the electrical ports and delta of the topology element.

Events

 

Alarms and conditions of the topology element.

2:Identification

 

Identification properties of the topology element.

 

2:Identification

2:DeviceClass

 

“MCS”

Domain or for what purpose this item is used.

2:Operational

 

Data for normal operation of the topology element.

2:Statistics

 

Data for statistics applications for the topology element.

 


 

7.7         CASComponentType ObjectType Definition

The CASComponentType is the representation of a Component and provides both Objects for Quantities and FunctionalGroups. It is illustrated in Figure 22 and formally defined in Table 23.

Figure28_

Figure 22 – CASComponentType Illustration

Table 23 – CASComponentType Definition

Attribute

Value

BrowseName

CASComponentType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:TopologyElementType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node.

0:HasSubtype

ObjectType

ChargingSystemType

Defined in 7.8

0:HasSubtype

ObjectType

CompressorType

Defined in 7.9

0:HasSubtype

ObjectType

ConverterType

Defined in 7.10

0:HasSubtype

ObjectType

CoolingSystemType

Defined in 7.11

0:HasSubtype

ObjectType

DrainType

Defined in 7.12

0:HasSubtype

ObjectType

DryerType

Defined in 7.13

0:HasSubtype

ObjectType

FilterType

Defined in 7.14

0:HasSubtype

ObjectType

HeatRecoverySystemType

Defined in 7.15

0:HasSubtype

ObjectType

ReceiverType

Defined in 7.16

0:HasSubtype

ObjectType

SensorType

Defined in 7.17

0:HasSubtype

ObjectType

SeparatorType

Defined in 7.18

0:HasSubtype

ObjectType

ValveType

Defined in 7.19

 

 

 

 

 

 

0:HasProperty

Variable

ActiveAirnet

0:NodeId

0:PropertyType

O, RW

0:HasComponent

Object

Ambient

 

FluidQuantitiesType

O

0:HasComponent

Object

2:Configuration

 

ConfigurationType

O

0:HasComponent

Object

CoolantCircuit

 

FluidCircuitType

O

0:HasComponent

Object

Design

 

DesignType

O

0:HasComponent

Object

ElectricalCircuit

 

ElectricalCircuitType

O

0:HasComponent

Object

Events

 

EventsType

O

0:HasComponent

Object

2:Operational

 

OperationalType

O

0:HasComponent

Object

ProcessFluidCircuit

 

FluidCircuitType

O

0:HasComponent

Object

2:Statistics

 

StatisticsType

O

 

 

 

 

 

 

The following nodes override nodes added by the 2:TopologyElementType

0:HasComponent

Object

2:Identification

 

4:MachineryItemIdentificationType

M

 

The optional Property ActiveAirnet indicates which Airnet is currently using this Component. The Property shall only be instantiated if the Component is connected to more than one Airnet.

The optional Object Ambient provides Quantities for the ambient air conditions at a Component. Of the optional Variables of the FluidQuantitiesType only AbsolutePressure, DewPoint, RelativeHumidity, and Temperature are instantiated.

The optional FunctionalGroup Configuration provides a framework for properties aimed at configuring the behavior of a Component in a Compressed Air System.

The optional Object CoolantCircuit provides design information about the coolant used as well as measurements and calculations for the inlet, outlet, and delta of coolant conditions on a Component in a Compressed Air System.

The optional FunctionalGroup Design provides static design properties of a Component in a Compressed Air System and acts as a framework for design properties in general.

The optional Object ElectricalCircuit provides measurements and calculations for the electrical input, output, and delta of a Component in a Compressed Air System.

The optional FunctionalGroup Events provides instances of common conditions of a Component in a Compressed Air System. It also provides a framework for instantiating conditions in the AddressSpace. If the server is not capable of instantiating ConditionTypes, this group shall not be instantiated.

The mandatory FunctionalGroup Identification provides capabilities to identify a Component in a Compressed Air System.

The optional FunctionalGroup Operational provides properties for process data used during normal operation of a Component, such as measurements, efficiencies, and states.

The optional Object ProcessFluidCircuit provides design information about the process fluid processed as well as measurements and calculations for the inlet, outlet, and delta of process fluid conditions on a Component in a Compressed Air System.

The optional FunctionalGroup Statistics provides properties for statistics applications of a Component in a Compressed Air System, like counters.

The optional Property DeviceClass of the MachineryItemIdentificationType is overridden. The ModellingRule is changed to mandatory and the Value Attribute is set to a specific value for each DeviceClass. When a concrete subtype of the MachineryItemIdentificationType is selected for a subtype or an instance of the CASComponentType, the ModellingRule of the DeviceClass Property shall remain as mandatory.

When instantiating the CASComponentType or one of its subtypes, the instantiated Object shall have at least one appropriate GeneratesEvent reference targeting the subtypes of the DeviceHealthDiagnosticAlarmType.

The components of the CASComponentType have additional subcomponents defined in Table 24.

Table 24 – CASComponentType Additional Subcomponents

Source Path

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

The following nodes override nodes added by the 4:MachineryItemIdentificationType

2:Identification

0:HasProperty

Variable

2:DeviceClass

0:String

0:PropertyType

M, RO

 

 

 

 

 

 

 

The following nodes override nodes added by the OperationalType

2:Operational

0:HasComponent

Variable

HealthState

HealthStateEnum

0:DataItemType

O, RO

2:Operational

0:HasComponent

Variable

IntegratedState

IntegratedStateEnum

0:DataItemType

O, RO

2:Operational

0:HasComponent

Variable

OperatingState

OperatingStateEnum

0:DataItemType

O, RO

 


 

The InstanceDeclarations of the CASComponentType have additional Attributes defined in Table 25.

Table 25 – CASComponentType Attribute values for child Nodes

Source Path

Description Attribute

ActiveAirnet

Indicates which airnet is currently using this component.

Ambient

Measurements and calculations of ambient air at the topology element.

 

Ambient

AbsolutePressure

 

Measured or calculated actual absolute pressure of the environment in which the component, piping or system is working.

 

Ambient

DewPoint

 

Measured or calculated actual dew point of the environment in which the component, piping or system is working.

 

Ambient

RelativeHumidity

 

Measured or calculated actual relative humidity of the environment in which the component, piping or system is working.

 

Ambient

Temperature

 

Measured or calculated actual temperature of the environment in which the component, piping or system is working.

2:Configuration

Configure the behavior of the topology element.

CoolantCircuit

Measurements and calculations of the coolant ports and delta of the topology element.

 

CoolantCircuit

FluidType

 

Enumeration of possible coolant types.

Design

Static design properties of the topology element.

ElectricalCircuit

Measurements and calculations of the electrical ports and delta of the topology element.

Events

Alarms and conditions of the topology element.

2:Identification

Identification properties of the topology element.

 

2:Identification

2:DeviceClass

 

Domain or for what purpose this item is used.

2:Operational

Data for normal operation of the topology element.

 

2:Operational

HealthState

 

Actual health state of the component.

 

2:Operational

IntegratedState

 

Actual integrated state of the component.

 

2:Operational

OperatingState

 

Actual operating state of the component.

ProcessFluidCircuit

Measurements and calculations of the process fluid ports and delta of the topology element.

 

ProcessFluidCircuit

FluidType

 

Enumeration of possible process fluid types.

2:Statistics

Data for statistics applications for the topology element.

 


 

7.8         ChargingSystemType ObjectType Definition

The ChargingSystemType shall be used as TypeDefinition for concrete charging system Objects and shall be used as supertype for concrete charging system ObjectTypes. A charging system is a pressure maintenance system that maintains a minimum pressure in a Component. It is formally defined in Table 26.

Table 26 – ChargingSystemType Definition

Attribute

Value

BrowseName

ChargingSystemType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

7.9         CompressorType ObjectType Definition

The CompressorType is the representation of a compressor and extends its supertype by specific Nodes. According to EN 1012-1/ISO/DIS 18623-1, a compressor compresses a gas or vapor media to a pressure higher than that at the inlet. It is illustrated in Figure 23 and formally defined in Table 27.

Figure29_

Figure 23 – CompressorType Illustration

Table 27 – CompressorType Definition

Attribute

Value

BrowseName

CompressorType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

CompressorDesignType

O

0:HasComponent

Object

2:Identification

 

4:MachineIdentificationType

M

0:HasComponent

Object

2:Operational

 

CompressorOperationalType

O

0:HasComponent

Object

2:Statistics

 

CompressorStatisticsType

O

 

The InstanceDeclarations of the CompressorType have additional Attributes defined in Table 28.

Table 28 – CompressorType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

 

2:Identification

2:DeviceClass

 

“Compressor”

Domain or for what purpose this item is used.

 

7.10      ConverterType ObjectType Definition

The ConverterType is the representation of a converter and extends its supertype by specific Nodes. A converter eliminates hydrocarbons from a compressed air flow by catalytic reaction with oxygen into H2O and CO2. It is illustrated in Figure 24 and formally defined in Table 29.

Figure30_

Figure 24 – ConverterType Illustration

Table 29 – ConverterType Definition

Attribute

Value

BrowseName

ConverterType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

ConverterDesignType

O

0:HasComponent

Object

2:Operational

 

ConverterOperationalType

O

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

7.11      CoolingSystemType ObjectType Definition

The CoolingSystemType shall be used as TypeDefinition for concrete cooling system Objects and shall be used as supertype for concrete cooling system ObjectTypes. A cooling system removes heat from a Component or the air flow in a Compressed Air System. It is formally defined in Table 30.

Table 30 – CoolingSystemType Definition

Attribute

Value

BrowseName

CoolingSystemType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.


 

7.12      DrainType ObjectType Definition

The DrainType is the representation of a condensate drain and extends its supertype by specific Nodes. Derived from EN 1012-1/ISO/DIS 18623-1, a condensate drain minimizes the accumulation of stagnant liquid in a Compressed Air System. It is illustrated in Figure 25 and formally defined in Table 31.

Figure31_

Figure 25 – DryerType Illustration

Table 31 – DrainType Definition

Attribute

Value

BrowseName

DrainType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

DrainDesignType

O

0:HasComponent

Object

2:Operational

 

DrainOperationalType

O

0:HasComponent

Object

ProcessFluidCircuit

 

FluidCircuitType

O

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

The InstanceDeclarations of the DrainType have additional Attributes defined in Table 32.

Table 32 – DrainType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

 

ProcessFluidCircuit

FluidType

 

1

Enumeration of possible process fluid types.

7.13      DryerType ObjectType Definition

The DryerType is the representation of a dryer and extends its supertype by specific Nodes. According to ISO 5598, a dryer reduces the moisture vapor content of the compressed air. It is illustrated in Figure 26 and formally defined in Table 33.

Figure32_

Figure 26 – DryerType Illustration

Table 33 – DryerType Definition

Attribute

Value

BrowseName

DryerType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

DryerDesignType

O

0:HasComponent

Object

2:Operational

 

DryerOperationalType

O

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

7.14      FilterType ObjectType Definition

The FilterType is the representation of a filter and extends its supertype by specific Nodes. According to ISO 12500-1, a filter separates or removes contamination from a compressed air or gas stream. It is illustrated in Figure 27 and formally defined in Table 34.

Figure33_

Figure 27 – FilterType Illustration

Table 34 – FilterType Definition

Attribute

Value

BrowseName

FilterType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes are override from CASComponentType

0:HasComponent

Object

Design

 

FilterDesignType

O

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

7.15      HeatRecoverySystemType ObjectType Definition

The HeatRecoverySystemType shall be used as TypeDefinition for concrete heat recovery system Objects and shall be used as supertype for concrete heat recovery system ObjectTypes. Derived from VDMA EcoLexicon, a heat recovery system removes heat from a compressor for further utilization, such as room heating. It is formally defined in Table 35.

Table 35 – HeatRecoverySystemType Definition

Attribute

Value

BrowseName

HeatRecoverySystemType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 


 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

7.16      ReceiverType ObjectType Definition

The ReceiverType is the representation of a receiver and extends its supertype by specific Nodes. According to DIN EN 13445-1, a receiver is a pressure vessel with a housing and its direct attachments up to the coupling point connecting it to other equipment, designed and built to contain fluids under pressure. It is illustrated in Figure 28 and formally defined in Table 36.

Figure34_

Figure 28 – ReceiverType Illustration

Table 36 – ReceiverType Definition

Attribute

Value

BrowseName

ReceiverType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

ReceiverDesignType

O

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

7.17      SensorType ObjectType Definition

The SensorType is the representation of a sensor and extends its supertype by specific Nodes. According to ISO 5598, a sensor is a device that detects a condition in a system or component and produces an output signal. It is illustrated in Figure 29 and formally defined in Table 37.

Figure35_

Figure 29 – SensorType Illustration

Table 37 – SensorType Definition

Attribute

Value

BrowseName

SensorType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

0:HasComponent

Object

Calibration

 

CalibrationType

O

0:HasComponent

Object

2:Maintenance

 

MaintenanceType

O

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

SensorDesignType

O

0:HasComponent

Object

2:Operational

 

OperationalType

O

 

The optional FunctionalGroup Calibration provides Variables useful for the documentation of the sensor calibration.

The optional FunctionalGroup Maintenance provides Variables useful for the documentation of the sensor maintenance.

The optional FunctionalGroup Operational is extended with an OptionalPlaceholder <Quantity> for the sensor Quantity. When instantiating a SensorType, the DataType of the <Quantity> instance must be changed to a concrete DataType. The TypeDefinition may be chosen from BaseAnalogType and its subtypes.

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

The components of the SensorType have additional subcomponents defined in Table 38.

Table 38 – SensorType Additional Subcomponents

Source Path

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

2:Operational

0:HasComponent

Variable

<Quantity>

0:Number

0:BaseAnalogType

OP, RO

 

The InstanceDeclarations of the SensorType have additional Attributes defined in Table 39.

Table 39 – SensorType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

Calibration

 

Dates important for the calibration of a sensor.

2:Maintenance

 

Servicing intervals for the sensor.

 

2:Operational

<Quantity>

 

 

Measurement or calculation performed by a sensor.

 


 

7.18      SeparatorType ObjectType Definition

The SeparatorType is the representation of a condensate separator and extends its supertype by specific Nodes. According to ISO 5598, a condensate separator retains contaminants by means other than a filter element, e.g. specific gravity, magnetism, chemical properties, density. It is illustrated in Figure 30 and formally defined in Table 40.

Figure36_

Figure 30 – SeparatorType Illustration

Table 40 – SeparatorType Definition

Attribute

Value

BrowseName

SeparatorType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

SeparatorDesignType

O

0:HasComponent

Object

ProcessFluidCircuit

 

FluidCircuitType

O

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.

The InstanceDeclarations of the SeparatorType have additional Attributes defined in Table 41.

Table 41 – SeparatorType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

 

ProcessFluidCircuit

FluidType

 

1

Enumeration of possible process fluid types.

7.19      ValveType ObjectType Definition

The ValveType is the representation of a valve and extends its supertype by specific Nodes. Valves control the flow and passage of fluids through a piping network. It is illustrated in Figure 31 and formally defined in Table 42.

Figure37_

Figure 31 – ValveType Illustration

Table 42 – ValveType Definition

Attribute

Value

BrowseName

ValveType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the CASComponentType defined in 7.7, i.e. inheriting the InstanceDeclarations of that Node.

 

 

 

 

 

 

The following nodes override nodes added by the CASComponentType

0:HasComponent

Object

Design

 

ValveDesignType

O

0:HasComponent

Object

2:Operational

 

ValveOperationalType

O

 

When instantiating this ObjectType the Identification Object shall use one of the concrete subtypes of the MachineryItemIdentificationType, either MachineIdentificationType or MachineryComponentIdentificationType, depending on the concrete usage of this Component. The ModellingRule of the Property DeviceClass remains as mandatory and its Value Attribute shall match the value stated in Table 9.


 

7.20      ElectricalQuantitiesType ObjectType Definition

The ElectricalQuantitiesType provides Variables for Quantities of electrical properties and is formally defined in Table 43.

Table 43 – ElectricalQuantitiesType Definition

Attribute

Value

BrowseName

ElectricalQuantitiesType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasInterface

ObjectType

3:IStatisticsType

Defined in OPC 10000-200

 

 

 

 

 

 

0:HasComponent

Variable

ApparentPower

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

Current

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

Energy

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

Power

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

Voltage

0:Double

0:BaseAnalogType

O, RO

 

 

 

 

 

 

Applied from 3:IStatisticsType

0:HasComponent

Method

3:ResetStatistics

See 3:IStatisticsType

O

0:HasProperty

Variable

3:StartTime

0:DateTime

0:PropertyType

O, RO

 

The Variable StartTime and the Method ResetStatistics are defined by the IStatisticsType and shall be used as defined by the Interface.

The InstanceDeclarations of the ElectricalQuantitiesType have additional Attributes defined in Table 44.

Table 44 – ElectricalQuantitiesType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

ApparentPower

 

Measured or calculated actual apparent power consumption including all auxiliary components (e.g. on a compressor including fans, controller, …).

Current

 

Measured or calculated actual root mean square of the electric power consumption including all auxiliary components (e.g. on a compressor including fans, controller, …).

Energy

 

Measured or calculated accumulated electrical energy consumed including all auxiliary components (e.g. on a compressor including fans, controller, …) since last reset.

Power

 

Measured or calculated actual electric real power consumption including all auxiliary components (e.g. on a compressor including fans, controller, …).

Voltage

 

Measured or calculated actual root mean square of the voltage applied including all auxiliary components (e.g. on a compressor including fans, controller, …).

 


 

7.21      ElectricalCircuitType ObjectType Definition

The ElectricalCircuitType provides Objects that are used to group common Quantities of electrical properties and is formally defined in Table 51.

Table 45 – ElectricalCircuitType Definition

Attribute

Value

BrowseName

ElectricalCircuitType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasComponent

Object

<Other>

 

ElectricalQuantitiesType

OP

0:HasComponent

Object

Delta

 

ElectricalQuantitiesType

O

0:HasComponent

Object

Input

 

ElectricalQuantitiesType

O

0:HasComponent

Object

Output

 

ElectricalQuantitiesType

O

 

The OptionalPlaceholder <Other> is used to add manufacturer or system specific groups to an electrical circuit.

The InstanceDeclarations of the ElectricalCircuitType have additional Attributes defined in Table 46.

Table 46 – ElectricalCircuitType Attribute values for child Nodes

Source Path

Description Attribute

<Other>

Placeholder for manufacturer or system specific groups.

Delta

Measured or calculated deltas of electrical properties between inlet and outlet of the component.

Input

Measured or calculated electrical properties at the input of the component.

Output

Measured or calculated electrical properties at the output of the component.

 

7.22      FluidQuantitiesType ObjectType Definition

The FluidQuantitiesType provides Variables and Objects for fluid Quantities and is formally defined in Table 47.

Table 47 – FluidQuantitiesType Definition

Attribute

Value

BrowseName

FluidQuantitiesType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasInterface

ObjectType

3:IStatisticsType

Defined in OPC 10000-200

 

 

 

 

 

 

0:HasComponent

Variable

<Quantity>

0:Number

0:BaseAnalogType

OP, RO

0:HasComponent

Variable

AbsolutePressure

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

AccumulatedVolume

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

DewPoint

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

GaugePressure

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

MassFlowRate

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

OilConcentration

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Object

ParticlesPerSizeRange

 

ParticleType

O

0:HasComponent

Variable

RelativeHumidity

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

Temperature

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

Volume

0:Double

0:BaseAnalogType

O, RO

0:HasComponent

Variable

VolumeFlowRate

0:Double

0:BaseAnalogType

O, RO

 

 

 

 

 

 

Applied from 3:IStatisticsType

0:HasComponent

Method

3:ResetStatistics

See 3:IStatisticsType

O

0:HasProperty

Variable

3:StartTime

0:DateTime

0:PropertyType

O, RO

 

The Variable StartTime and the Method ResetStatistics are defined by the IStatisticsType and shall be used as defined by the Interface.

The OptionalPlaceholder <Quantity> is used to add additional Quantities to this group. In this case the abstract DataType 0:Number must be changed to a non-abstract DataType. The TypeDefinition may be chosen from BaseAnalogType and its subtypes.

The InstanceDeclarations of the FluidQuantitiesType have additional Attributes defined in Table 48.

Table 48 – FluidQuantitiesType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

<Quantity>

 

Manufacturer or system specific measurements or calculations.

AbsolutePressure

 

Measured or calculated actual absolute pressure of a fluid.

AccumulatedVolume

 

Measured or calculated accumulated volume of a fluid since last reset.

DewPoint

 

Measured or calculated actual dew point of a fluid.

GaugePressure

 

Measured or calculated actual gauge pressure of a fluid.

MassFlowRate

 

Measured or calculated actual mass flow rate of a fluid.

OilConcentration

 

Measured or calculated actual oil concentration of a fluid.

ParticlesPerSizeRange

 

Collection of particle counts for a fluid according to ISO 8573.

RelativeHumidity

 

Measured or calculated actual relative humidity of a fluid.

Temperature

 

Measured or calculated actual temperature of a fluid.

Volume

 

Measured or calculated actual volume of a fluid.

VolumeFlowRate

 

Measured or calculated actual volume flow rate of a fluid.

 

7.23      ParticleType ObjectType Definition

The ParticleType provides Variables for particle counting in a fluid in three categories according to ISO 8573-1:2010-04 Compressed air – Part 1: Contaminants and purity classes. It is formally defined in Table 49.

Table 49 – ParticleType Definition

Attribute

Value

BrowseName

ParticleType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasComponent

Variable

Fine

0:UInt64

0:BaseAnalogType

M, RO

0:HasComponent

Variable

Large

0:UInt64

0:BaseAnalogType

M, RO

0:HasComponent

Variable

Medium

0:UInt64

0:BaseAnalogType

M, RO

 

The InstanceDeclarations of the ParticleType have additional Attributes defined in Table 50.

Table 50 – ParticleType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

Fine

 

Particle count of sizes from 0.1 to 0.5 um.

Large

 

Particle count of sizes from 1.0 to 5.0 um.

Medium

 

Particle count of sizes from 0.5 to 1.0 um.

 


 

7.24      FluidCircuitType ObjectType Definition

The FluidCircuitType provides Objects that are used to group fluid Quantities and is formally defined in Table 51.

Table 51 – FluidCircuitType Definition

Attribute

Value

BrowseName

FluidCircuitType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasComponent

Object

<Other>

 

FluidQuantitiesType

OP

0:HasComponent

Object

Delta

 

FluidQuantitiesType

O

0:HasComponent

Variable

FluidType

FluidTypeEnum

0:DataItemType

O, RO

0:HasComponent

Object

Inlet

 

FluidQuantitiesType

O

0:HasComponent

Object

Outlet

 

FluidQuantitiesType

O

 

The OptionalPlaceholder Object <Other> is used to add manufacturer or system specific groups to a fluid circuit.

The InstanceDeclarations of the FluidCircuitType have additional Attributes defined in Table 52.

Table 52 – FluidCircuitType Attribute values for child Nodes

Source Path

Description Attribute

<Other>

Placeholder for manufacturer or system specific groups.

Delta

Measured or calculated deltas of fluid properties between inlet and outlet of the component.

FluidType

Enumeration of possible fluid types.

Inlet

Measured or calculated fluid properties at the inlet of the component.

Outlet

Measured or calculated fluid properties at the outlet of the component.

 


 

7.25      AnalysisType  ObjectType Definition

The AnalysisType provides Objects and Methods that are used for invoking an analysis on the Main Control System and is formally defined in Table 53.

Table 53 – AnalysisType Definition

Attribute

Value

BrowseName

AnalysisType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasComponent

Object

OutputFile

 

0:FileType

O

0:HasComponent

Method

Trigger

See 7.25.1

O

 

The optional Object OutputFile shall contain the result of an analysis if the Main Control System can provide a file in the AddressSpace of the OPC UA Server. If not, this Object must not be instantiated.

The results of an analysis may be submitted to the user via any communication technology. It is not necessary to provide the result in the OPC UA AddressSpace. However, it is recommended to do so if the Server is capable of such an operation. An analysis output file may be any kind of file. The manufacturer shall define the provided file type and any other necessary information.

The optional Method Trigger is used to invoke the generation of an analysis report on the Main Control System.

To define a parameterizable analysis, the manufacturer or integrator shall define a subtype of this AnalysisType. The Method Trigger shall be overridden, and the required parameters shall be added as InputArguments. The manufacturer or integrator may add Variables or Properties to the new subtype to represent the parameters.

The InstanceDeclarations of the AnalysisType have additional Attributes defined in Table 54.

Table 54 – AnalysisType Attribute values for child Nodes

Source Path

Description Attribute

OutputFile

File containing the result of an analysis.

Trigger

Triggers the analysis on the MCS in a compressed air system.

 

7.25.1        Trigger

The Method Trigger is used to trigger an analysis on the Main Control System. The signature of this Method is specified below. There are no InputArguments or OutputArguments defined. Its formal representation in the AddressSpace is defined in Table 55.

Signature

Trigger (

);

Table 55 – Trigger Method AddressSpace Definition

Attribute

Value

BrowseName

Trigger

References

Node Class

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 


 

7.26      AnalysesType ObjectType Definition

The AnalysesType provides Objects for invoking analyses performed by the Main Control System and is formally defined in Table 56. Such analyses may be performed on Compressed Air System or Airnet level.

Table 56 – AnalysesType Definition

Attribute

Value

BrowseName

AnalysesType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:FunctionalGroupType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node.

0:HasComponent

Object

<Analysis>

 

AnalysisType

OP

0:HasComponent

Object

<PrefabAnalysis>

 

0:FileType

OP

0:HasComponent

Object

EnergyReportISO50001

 

AnalysisType

O

 

The OptionalPlaceholder Object <PrefabAnalyses> can be used to provide results of analyses performed by the manufacturer, automatically recurring analyses performed by the Main Control System, or other analyses that do not require a trigger and an output file.

The optional Object EnergyReportISO50001 can be used as a pre-parameterized analysis for generating an energy report according to ISO 50001. The parameterization for this analysis should be provided on the Main Control System.

The InstanceDeclarations of the AnalysesType have additional Attributes defined in Table 57.

Table 57 – AnalysesType Attribute values for child Nodes

Source Path

Description Attribute

<Analysis>

Manufacturer or system specific analyses.

<PrefabAnalysis>

Prefabricated analysis provided by the MCS.

EnergyReportISO50001

Energy report according to ISO 50001.

 

7.27      CalibrationType ObjectType Definition

The CalibrationType provides Variables useful for the calibration of a sensor and is formally defined in Table 58.

Table 58 – CalibrationType Definition

Attribute

Value

BrowseName

CalibrationType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:FunctionalGroupType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node

0:HasComponent

Variable

LastCalibrationDate

0:DateTime

0:DataItemType

M, RO

0:HasComponent

Variable

NextCalibrationDate

0:DateTime

0:DataItemType

M, RO

 

The InstanceDeclarations of the CalibrationType have additional Attributes defined in Table 59.

Table 59 – CalibrationType Attribute values for child Nodes

Source Path

Description Attribute

LastCalibrationDate

Date when the sensor was last calibrated.

NextCalibrationDate

Date when the sensor is scheduled for the next calibration.

 


 

7.28      CASIdentificationType ObjectType Definition

The CASIdentificationType provides Properties for basic identification purposes for Compressed Air Systems and Airnets. It is formally defined in Table 60.

Table 60 – CASIdentificationType Definition

Attribute

Value

BrowseName

CASIdentificationType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:FunctionalGroupType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node

0:HasInterface

ObjectType

2:ITagNameplateType

Defined in OPC 10000-100

 

 

 

 

 

 

Applied from 2:ITagNameplateType

0:HasProperty

Variable

2:AssetId

0:String

0:PropertyType

O, RW

0:HasProperty

Variable

2:ComponentName

0:LocalizedText

0:PropertyType

O, RW

 

The Properties AssetId and ComponentName are defined by the ITagNameplateType and shall be used as defined by the Interface.

7.29      ConfigurationType ObjectType Definition

The ConfigurationType provides a framework for Nodes aimed at configuring the behavior of a CASPart. This specification defines configuration properties for Airnets  and the Main Control System. There are no configuration properties defined for Components. It is formally defined in Table 61.

Table 61 – ConfigurationType Definition

Attribute

Value

BrowseName

ConfigurationType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:FunctionalGroupType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node.

0:HasSubtype

ObjectType

AirnetConfigurationType

Defined in 7.30

0:HasSubtype

ObjectType

MCSConfigurationType

Defined in 7.31

 

7.30      AirnetConfigurationType ObjectType Definition

The AirnetConfigurationType provides Variables for configuring the behavior of an Airnet and is formally defined in Table 62.

Table 62 – AirnetConfigurationType Definition

Attribute

Value

BrowseName

AirnetConfigurationType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the ConfigurationType defined in 7.28, i.e. inheriting the InstanceDeclarations of that Node.

0:HasComponent

Variable

OperatingModes

0:UInt16

0:MultiStateDiscreteType

O, RW

0:HasComponent

Variable

OperatingProfiles

0:UInt16

0:MultiStateDiscreteType

M, RW

 

The optional Variable OperatingModes provides manufacturer or system specific operating modes of an Airnet. When instantiating the AirnetConfigurationType, the manufacturer or system integrator shall add specific operating modes to the EnumStrings Property. However, Value 0 is already predefined as stopped operating mode. Examples for other operating modes are energy or maintenance optimized operating modes which are not specified by this specification.

The mandatory Variable OperatingProfiles provides manufacturer or system specific operating profiles of an Airnet. On the Main Control System, operating profiles are stored as sets of parameters for parameterizing the behavior of an Airnet. When instantiating the AirnetConfigurationType, the manufacturer or system integrator shall add specific operating profiles to the EnumStrings Property. An operating profile may change the OperatingMode Variable. An example for such profiles is the weekday profile, which change the operating mode and/or other parameters depending on the weekday.

The InstanceDeclarations of the AirnetConfigurationType have additional Attributes defined in Table 63.

Table 63 – AirnetConfigurationType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

OperatingModes

 

Configured operating mode for an airnet in a compressed air system.

 

OperatingModes

0:EnumStrings

 

stopped

Available operating modes for an airnet in a compressed air system.

OperatingProfiles

 

Configured operating profile for an airnet in a compressed air system.

 

OperatingProfiles

0:EnumStrings

 

 

Available operating profiles for an airnet in a compressed air system.

 

7.31      MCSConfigurationType ObjectType Definition

The MCSConfigurationType provides Objects and Methods for configuring the behavior of the Compressed Air System and is formally defined in Table 64.

Table 64 – MCSConfigurationType Definition

Attribute

Value

BrowseName

MCSConfigurationType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the ConfigurationType defined in 7.28, i.e. inheriting the InstanceDeclarations of that Node.

0:HasComponent

Object

CommunicationSettings

 

CommunicationSettingsType

O

0:HasComponent

Object

ConfigurationFile

 

0:FileType

O

0:HasComponent

Method

LoadConfigurationFile

See 7.31.1

O

0:HasComponent

Method

SaveConfigurationFile

See 7.31.2

O

 

The optional Object CommunicationSettings is used to display the ethernet communication settings of the OPC UA connection point of the Main Control System.

The optional Object ConfigurationFile of the FileType shall be used to store the Main Control System configuration in the OPC UA AddressSpace. This configuration file may be uploaded to or downloaded from the Main Control System using the described Methods. It should be a persistent representation of the currently active configuration for the Compressed Air System.

The optional Method LoadConfigurationFile is the trigger for uploading the configuration stored in the ConfigurationFile Object to the Main Control System.

The optional Method SaveConfigurationFile is the trigger for downloading the current configuration from the Main Control System and store it in the ConfigurationFile Object.

The InstanceDeclarations of the MCSConfigurationType have additional Attributes defined in Table 65.

Table 65 – MCSConfigurationType Attribute values for child Nodes

Source Path

Description Attribute

CommunicationSettings

OPC UA communication settings of the MCS in a compressed air system.

ConfigurationFile

Configuration file for the MCS in a compressed air system.

LoadConfigurationFile

Loads the configuration stored in ConfigurationFile to the MCS.

SaveConfigurationFile

Saves the current configuration of the MCS to the stored ConfigurationFile.

 

7.31.1        LoadConfigurationFile

The Method LoadConfigurationFile is used to load the configuration file stored in ConfigurationFile into the Main Control System. The signature of this Method is specified below. There are no InputArguments or OutputArguments defined. Its formal representation in the AddressSpace is defined in Table 66.

Signature

LoadConfigurationFile (

);

Table 66 – LoadConfigurationFile Method AddressSpace Definition

Attribute

Value

BrowseName

LoadConfigurationFile

References

Node Class

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 

7.31.2        SaveConfigurationFile

The Method SaveConfigurationFile is used to save the current configuration of the Main Control System to the file stored in ConfigurationFile. The signature of this Method is specified below. There are no InputArguments or OutputArguments defined. Its formal representation in the AddressSpace is defined in Table 67.

Signature

SaveConfigurationFile (

);

Table 67 – SaveConfigurationFile Method AddressSpace Definition

Attribute

Value

BrowseName

SaveConfigurationFile

References

Node Class

BrowseName

DataType

TypeDefinition

ModellingRule

 

 

 

 

 

 

 

7.32      CommunicationSettingsType ObjectType Definition

The CommunicationSettingsType provides Variables for the communication settings of the Main Control System and is formally defined in Table 68.

Table 68 – CommunicationSettingsType Definition

Attribute

Value

BrowseName

CommunicationSettingsType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5.

0:HasProperty

Variable

DefaultGateway

0:String

0:PropertyType

O, RO

0:HasComponent

Variable

Dhcp

0:Boolean

0:TwoStateDiscreteType

O, RO

0:HasProperty

Variable

DnsServer

0:String

0:PropertyType

O, RO

0:HasProperty

Variable

DomainName

0:String

0:PropertyType

O, RO

0:HasProperty

Variable

Hostname

0:String

0:PropertyType

O, RO

0:HasProperty

Variable

IpAddress

0:String

0:PropertyType

M, RO

0:HasProperty

Variable

IpVersion

IpVersionEnum

0:PropertyType

O, RO

0:HasComponent

Variable

MacAddress

0:String

0:BaseDataVariableType

O, RO

0:HasProperty

Variable

SubnetMask

0:String

0:PropertyType

O, RO

 


 

The InstanceDeclarations of the CommunicationSettingsType have additional Attributes defined in Table 69.

Table 69 – CommunicationSettingsType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

DefaultGateway

 

IP Address of the default gateway used by the MCS.

Dhcp

 

States if DHCP is enabled or disabled on the MCS.

 

Dhcp

0:FalseState

 

“DHCP disabled”

 

 

Dhcp

0:TrueState

 

“DHCP enabled”

 

DnsServer

 

IP Address of the DNS server used by the MCS.

DomainName

 

Domain name the MCS is assigned to.

Hostname

 

Host name of the MCS.

IpAddress

 

IP address of the MCS.

IpVersion

 

Version of the internet protocol used for the MCS.

MacAddress

 

MAC address of the NIC of the MCS.

SubnetMask

 

Subnet mask of the MCS.

 

7.33      DesignType ObjectType Definition

The DesignType provides a framework and Variables for static design information of Components and is formally defined in Table 70.

Table 70 – DesignType Definition

Attribute

Value

BrowseName

DesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the 2:FunctionalGroupType defined in OPC 10000-100, i.e. inheriting the InstanceDeclarations of that Node

0:HasSubtype

ObjectType

CompressorDesignType

Defined in 7.34

0:HasSubtype

ObjectType

ConverterDesignType

Defined in 7.35

0:HasSubtype

ObjectType

DrainDesignType

Defined in 7.36

0:HasSubtype

ObjectType

DryerDesignType

Defined in 7.37

0:HasSubtype

ObjectType

FilterDesignType

Defined in 7.38

0:HasSubtype

ObjectType

ReceiverDesignType

Defined in 7.39

0:HasSubtype

ObjectType

SensorDesignType

Defined in 7.40

0:HasSubtype

ObjectType

SeparatorDesignType

Defined in 7.41

0:HasSubtype

ObjectType

ValveDesignType

Defined in 7.42

 

 

 

 

 

 

0:HasComponent

Variable

ComponentClass

0:Enumeration

0:DataItemType

O, RO

 

The InstanceDeclarations of the DesignType have additional Attributes defined in Table 71.

Table 71 – DesignType Attribute values for child Nodes

Source Path

Description Attribute

ComponentClass

Enumeration of possible types of the component’s device class.

 


 

7.34      CompressorDesignType ObjectType Definition

The CompressorDesignType extends its supertype by compressor specific Variables and is formally defined in Table 72.

Table 72 – CompressorDesignType Definition

Attribute

Value

BrowseName

CompressorDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node

0:HasComponent

Variable

DisplacementType

DisplacementTypeEnum

0:DataItemType

O, RO

0:HasComponent

Variable

LubricationType

LubricationTypeEnum

0:DataItemType

O, RO

0:HasComponent

Variable

NumberOfStages

0:UInt16

0:DataItemType

O, RO

0:HasComponent

Variable

VariableFlow

0:Boolean

0:TwoStateDiscreteType

O, RO

 

 

 

 

 

 

The following nodes override properties and components of the DesignType

0:HasComponent

Variable

ComponentClass

CompressorTypeEnum

0:DataItemType

O, RO

 

 

The InstanceDeclarations of the CompressorDesignType have additional Attributes defined in Table 73.

Table 73 – CompressorDesignType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

ComponentClass

 

Enumeration of possible compressor types.

DisplacementType

 

Enumeration of possible displacement types.

LubricationType

 

Enumeration of possible lubrication types for the compression process of a compressor.

NumberOfStages

 

Number of stages the compressor has available.

VariableFlow

 

Indicates if a compressor has a variable or fixed flow.

 

VariableFlow

0:FalseState

 

'Fixed flow' means the product offers no control for changing the volume flow independent of pressure.

 

 

VariableFlow

0:TrueState

 

'Variable flow' means the compressor package allows an intentional change in volume flow rate, most obviously by VSD but also by adjustable guide vanes in turbo compressors or by valve controls in piston compressors or other means.

 

 


 

7.35      ConverterDesignType ObjectType Definition

The ConverterDesignType extends its supertype by converter specific Variables and is formally defined in Table 74.

Table 74 – ConverterDesignType Definition

Attribute

Value

BrowseName

ConverterDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node

 

 

 

 

 

 

The following nodes override properties and components of the DesignType

0:HasComponent

Variable

ComponentClass

ConverterTypeEnum

0:DataItemType

O, RO

 

The InstanceDeclarations of the ConverterDesignType have additional Attributes defined in Table 75.

Table 75 – ConverterDesignType Attribute values for child Nodes

Source Path

Description Attribute

ComponentClass

Enumeration of possible converter types.

 

7.36      DrainDesignType ObjectType Definition

The DrainDesignType extends its supertype by condensate drain specific Variables and is formally defined in Table 76.

Table 76 – DrainDesignType Definition

Attribute

Value

BrowseName

DrainDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node

 

 

 

 

 

 

The following nodes override properties and components of the DesignType

0:HasComponent

Variable

ComponentClass

DrainTypeEnum

0:DataItemType

O, RO

 

The InstanceDeclarations of the DrainDesignType have additional Attributes defined in Table 77.

Table 77 – DrainDesignType Attribute values for child Nodes

Source Path

Description Attribute

ComponentClass

Enumeration of possible condensate drain types.

 


 

7.37      DryerDesignType ObjectType Definition

The DryerDesignType extends its supertype by dryer specific Variables and is formally defined in Table 78.

Table 78 – DryerDesignType Definition

Attribute

Value

BrowseName

DryerDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node

0:HasComponent

Variable

LowestAmbientTemperature

0:Double

0:BaseAnalogType

O, RO

 

 

 

 

 

 

The following nodes override properties and components of the DesignType

0:HasComponent

Variable

ComponentClass

DryerTypeEnum

0:DataItemType

O, RO

 

The InstanceDeclarations of the DryerDesignType have additional Attributes defined in Table 79.

Table 79 – DryerDesignType Attribute values for child Nodes

Source Path

Description Attribute

ComponentClass

Enumeration of possible dryer types.

LowestAmbientTemperature

Lowest allowable ambient temperature for the dryer to work as intended.

 

7.38      FilterDesignType ObjectType Definition

The FilterDesignType extends its supertype by filter specific Variables and is formally defined in Table 80.

Table 80 – FilterDesignType Definition

Attribute

Value

BrowseName

FilterDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node

0:HasComponent

Variable

FilterClass

FilterClassDataType

0:DataItemType

O, RO

 

 

 

 

 

 

The following nodes override properties and components of the DesignType

0:HasComponent

Variable

ComponentClass

FilterTypeEnum

0:DataItemType

O, RO

 

The InstanceDeclarations of the FilterDesignType have additional Attributes defined in Table 81.

Table 81 – FilterDesignType Attribute values for child Nodes

Source Path

Description Attribute

ComponentClass

Enumeration of possible filter types.

FilterClass

Filter classes according to ISO 8573-1.

 


 

7.39      ReceiverDesignType ObjectType Definition

The ReceiverDesignType extends its supertype by receiver specific Variables and is formally defined in Table 82.

Table 82 – ReceiverDesignType Definition

Attribute

Value

BrowseName

ReceiverDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node

 

 

 

 

 

 

The following nodes override properties and components of the DesignType

0:HasComponent

Variable

ComponentClass

ReceiverTypeEnum

0:DataItemType

O, RO

0:HasComponent

Variable

Volume

0:Double

0:AnalogUnitType

O, RO

 

The InstanceDeclarations of the ReceiverDesignType have additional Attributes defined in Table 83.

Table 83 – ReceiverDesignType Attribute values for child Nodes

Source Path

Description Attribute

ComponentClass

Enumeration of possible receiver types.

Volume

Total volume of the receiver.

 

7.40      SensorDesignType ObjectType Definition

The SensorDesignType extends its supertype by sensor specific Variables and is formally defined in Table 84.

Table 84 – SensorDesignType Definition

Attribute

Value

BrowseName

SensorDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node

0:HasComponent

Variable

SensorTechnology

SensorTechnologyOptionSet

0:DataItemType

O, RO

0:HasComponent

Variable

SoftSensor

0:Boolean

0:TwoStateDiscreteType

O, RO

 

 

 

 

 

 

The following nodes override properties and components of the DesignType

0:HasComponent

Variable

ComponentClass

SensorTypeEnum

0:DataItemType

O, RO

 

The InstanceDeclarations of the SensorDesignType have additional Attributes defined in Table 85.

Table 85 – SensorDesignType Attribute values for child Nodes

Source Path

Value Attribute

Description Attribute

ComponentClass

 

Enumeration of possible sensor types.

SensorTechnology

 

Selection of sensor technologies this sensor uses.

SoftSensor

 

Indicates if the sensor is a software or hardware sensor.

 

SoftSensor

0:FalseState

 

“This sensor is a hardware sensor.”

 

 

SoftSensor

0:TrueState

 

“This sensor is a software sensor.”

 

 

7.41      SeparatorDesignType ObjectType Definition

The SeparatorDesignType extends its supertype by condensate separator specific Variables and is formally defined in Table 86.

Table 86 – SeparatorDesignType Definition

Attribute

Value

BrowseName

SeparatorDesignType

IsAbstract

False

References

Node Class

BrowseName

DataType

TypeDefinition

Other

Subtype of the DesignType defined in 7.33, i.e. inheriting the InstanceDeclarations of that Node