1 Scope

This specification was created by a joint working group of the OPC Foundation and AutomationML e.V.. It defines an OPC UA Information Model to represent the AutomationML models.

OPC Foundation

The OPC Foundation defines standards for online data exchange between automation systems. They address access to current data (OPC DA), alarms and events (OPC A&E) and historical data (OPC HDA). Those standards are successfully applied in industrial automation.

The new OPC Unified Architecture (OPC UA) unifies the existing standards and brings them to state-of-the-art technology using service-oriented architecture (SOA). Platform-independent technology allows the deployment of OPC UA beyond current OPC applications only running on Windows-based PC systems. OPC UA can also run on embedded systems as well as Linux / UNIX based enterprise systems. The provided information can be generically modelled and therefore arbitrary information models can be provided using OPC UA.

AutomationML e.V.

The AutomationML initiative is an open, in 2006 founded industrial consortium which became a registered association in 2009. It welcomes all interested company and research institute.

Purposes of AutomationML e.V. are promotion and further development of AutomationML to standardise data exchange in the engineering process of production systems. Therefore, AutomationML e.V. develops and maintains an open, neutral, XML based, and free industry data representation standard which enables a domain and company spanning transfer of engineering data. Instead of developing a new data format for that purpose, already existing formats were used, extended, adapted, and merged in a proper way. So far, the representation of plant specific data in general and in special the plant structure, geometry and kinematics, and logic description is possible. Additional representations for networks, mechatronical systems, and others are in progress. Hence, AutomationML is the most comprehensive data format of plant engineering. It is already used in the field and is also available in several products. Within IEC 62714 all parts of AutomationML are going to be standardised internationally.

2 Reference documents

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

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

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

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

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

IEC 62714-1:2014, Engineering data exchange format for use in industrial automation systems engineering - Automation markup language - Part 1: Architecture and general requirements

IEC 62714-2:2015, Engineering data exchange format for use in industrial automation systems engineering - Automation markup language - Part 2: Role class libraries

IEC 62714-3, Engineering data exchange format for use in industrial automation systems engineering - Automation markup language - Part 3: Geometry and kinematics

IEC 62714-4, Engineering data exchange format for use in industrial automation systems engineering - Automation markup language - Part 3: Logic and behavior

IEC 62264-1: 2013, Enterprise-control system integration - Part 1: Models and terminology (similar to ANSI ISA 95)

IEC 61512-1:1997, Batch control - Part 1: Models and terminology (similar to ANSI ISA 88)

IEC 62424:2008, Representation of process control engineering - Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools

3 Terms, definitions, and conventions

3.1 Use of terms

Defined terms of OPC UA specifications, types and their components defined in OPC UA specifications and in this specification are highlighted with italic in this document.

AutomationML related terms and names are always used together with the prefix AutomationML.

3.2 Abbreviations and symbols

3.3 Conventions used in this document

3.3.1 Conventions for naming of interconnection between elements

Relations between elements in AutomationML are referred to as references between nodes in OPC UA.

3.3.2 Conventions for Node descriptions

Node definitions are specified using tables (See Table 1)

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. That implies that the referenced Node has a HasModelParent Reference with the Node defined in the Table as TargetNode (see OPC 10000-3 for the definition of ModelParents).

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. In Table 2 examples are given.

The TypeDefinition is specified for Objects and Variables.

The TypeDefinition column specifies a NodeId of a TypeDefinitionNode, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding TypeDefinitionNode. The symbolic name of the NodeId is used in the table.

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

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

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

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

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

3.3.3 NodeIds and BrowseNames

3.3.3.1 NodeIds

The NodeIds of all Nodes described in this document are only symbolic names.

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 namespace for this specification is defined in the following chapters. The NamespaceIndex for all NodeIds defined in this specification is server specific and depends on the position of the namespace URI in the server namespace table.

Note: This specification does not only define concrete Nodes, but also requires that some Nodes have to be generated, for example one for each device type available in the frame application. 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 by this specification, because they are not defined by this specification but generated by the Server.

3.3.3.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this specification is specified in the tables defining the Nodes. The NamespaceIndex for all BrowseNames defined in this specification is server specific and depends on the position of the namespace URI defined in this specification in the server namespace table.

If the BrowseName is not defined by this specification, a namespace index prefix like ‘0:EngineeringUnits’ 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 specification.

3.3.4 Common Attributes

3.3.4.1 General

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

3.3.4.2 Objects

For all Objects specified in this specification, the Attributes named in Table 4 shall be set as specified in the table.

3.3.4.3 Variables

For all Variables specified in this specification, the Attributes named in Table 5 shall be set as specified in the table.

3.3.4.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 6 shall be set as specified in the table.

4 General information to AutomationML and OPC UA

4.1 Introduction to AutomationML

The AutomationML data format, developed by AutomationML e.V., standardised in IEC 62714, is an open, neutral, XML-based, and free data exchange format which enables a domain and company spanning transfer of engineering data of production systems in a heterogeneous engineering tool landscape. The goal of AutomationML is to interconnect engineering tools in their different disciplines, e.g. plant planning, mechanical engineering, electrical engineering, process engineering, process control engineering, HMI development, PLC programming, robot programming.

AutomationML stores engineering information following the object oriented paradigm and allows model­ling of physical and logical plant components as data objects encapsulating different aspects. An object may consist of other sub-objects, and may itself be part of a larger composition or aggregation. Typical objects in plant automation comprise information on topology, geometry, kinematics, logic, and behaviour.

In addition, AutomationML follows a modular structure. AutomationML is based on IEC 62424 (CAEX) and integrates other already existing XML-based data formats (see Figure 1). These data formats are used on an “as-is” basis within their own specifications and are not branched for AutomationML needs.

Logically AutomationML is partitioned in:

description of the plant structure and communication systems expressed as a hierarchy of AutomationML objects and described by means of CAEX following IEC 62424

description of geometry and kinematics of the different AutomationML objects represented by means of COLLADA 1.4.1 and 1.5.0 (ISO/PAS 17506:2012)

description of control related logic data of the different AutomationML objects represented by means of PLCopen XML 2.0 and 2.0.1 (IEC61131-10)

description of relations among AutomationML objects and references to information that is stored in documents outside the top level format

Due to the different aspects of AutomationML, the IEC 62714 series consists of different parts focussing on different aspects:

IEC 62714-1: Architecture and general requirements - This part specifies the general AutomationML architecture, the modelling of engineering data, classes, instances, relations, references, hierarchies, basic AutomationML libraries and extended AutomationML concepts. It describes the use of CAEX. It is the basis of all future parts and provides mechanisms to reference other sub-formats.

IEC 62714-2: Role class libraries - This part is intended to specify additional AutomationML libraries to derive necessary roles for semantic definition in individual application cases.

IEC 62714-3: Geometry and kinematics - This part is intended to specify the modelling of geometry and kinematics information based on COLLADA.

IEC 62714-4: Logic - This part is intended to specify the modelling of logics, sequencing, behaviour and control related information based on PLCopen XML.

Further parts may be added in the future in order to interconnect additional data standards to AutomationML.

4.1.1 Top-level format CAEX

The foundation of AutomationML is the application of CAEX as the top level format. Furthermore, AutomationML defines an appropriate CAEX profile fulfilling all relevant needs of AutomationML to model engineering information of production systems. It integrates the three data formats CAEX, COLLADA, and PLCopenXML, and enables an extension, if necessary, in the future.

CAEX enables an object oriented approach (see Figure 2) where

semantics of system objects can be specified using roles defined and collected in role class libraries,

semantics of interfaces between system objects can be specified using interface classes defined and collected in interface class libraries,

classes of system objects can be specified using system unit classes (SUC) defined and collected in system unit class libraries, and

individual objects are modelled in an instance hierarchy (IH) as a hierarchy of internal elements (IE) referencing system unit classes they are derived from, role classes defining its semantics, and interface objects used to interlink objects among each other or with externally modelled information (e.g. COLLADA and PLCopenXML files).

4.2 Introduction to OPC Unified Architecture

4.2.1 General

The main use case for OPC standards is the online data exchange between devices and HMI or SCADA systems using Data Access functionality. In this use case the device data is provided by an OPC server and is consumed by an OPC client integrated into the HMI or SCADA system. OPC DA provides functionality to browse through a hierarchical namespaces containing data items and to read, write and to monitor these items for data changes. The classic OPC standards are based on Microsoft COM/DCOM technology for the communication between software components from different vendors. Therefore classic OPC server and clients are restricted to Windows PC based automation systems.

OPC UA incorporates all features of classic OPC standards like OPC DA, A&E and HDA but defines platform independent communication mechanisms and generic, extensible and object-oriented modelling capabilities for the information a system wants to expose.

The OPC UA network communication part defines different mechanisms optimized for different use cases. The first version of OPC UA is defining an optimized binary TCP protocol for high performance intranet communication as well as a mapping to accepted internet standards like Web Services. The abstract communication model does not depend on a specific protocol mapping and allows adding new protocols in the future. Features like security, access control and reliability are directly built into the transport mechanisms. Based on the platform independence of the protocols, OPC UA servers and clients can be directly integrated into devices and controllers.

The OPC UA Information Model provides a standard way for Servers to expose Objects to Clients. Objects in OPC UA terms are composed of other Objects, Variables and Methods. OPC UA also allows relationships to other Objects to be expressed.

The set of Objects and related information that an OPC UA Server makes available to Clients is referred to as its AddressSpace. The elements of the OPC UA Object Model are represented in the AddressSpace as a set of Nodes described by Attributes and interconnected by References. OPC UA defines eight classes of Nodes to represent AddressSpace components. The classes are Object, Variable, Method, ObjectType, DataType, ReferenceType and View. Each NodeClass has a defined set of Attributes.

This specification makes use of three essential OPC UA NodeClasses: Objects, Methods and Variables.

Objects are used to represent components of a system. An Object is associated to a corresponding ObjectType that provides definitions for that Object.

Methods are used to represent commands or services of a system.

Variables are used to represent values. Two categories of Variables are defined, Properties and DataVariables.

Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties are not allowed to have Properties defined for them. An example for Properties of Objects is the Object_Identifier Property of a XXX ObjectType.

DataVariables represent the contents of an Object. DataVariables may have component DataVariables. This is typically used by Servers to expose individual elements of arrays and structures. This specification uses DataVariables to represent data like the XXX of a XXX Object.

4.2.2 Graphical Notation

OPC UA defines a graphical notation for an OPC UA AddressSpace. It defines graphical symbols for all NodeClasses and how different types of References between Nodes can be visualized. Figure 3 shows the symbols for the six NodeClasses used in this specification. NodeClasses representing types always have a shadow.

Figure 4 shows the symbols for the ReferenceTypes used in this specification. The Reference symbol is normally pointing from the source Node to the target Node. The only exception is the HasSubType Reference. The most important References like HasComponent, HasProperty, HasTypeDefinition and HasSubType have special symbols avoiding the name of the Reference. For other ReferenceTypes or derived ReferenceTypes the name of the ReferenceType is used together with the symbol.

Figure 5 shows a typical example for the use of the graphical notation. Object_A and Object_B are instances of the ObjectType_Y indicated by the HasTypeDefinition References. The ObjectType_Y is derived from ObjectType_X indicated by the HasSubType Reference. The Object_A has the components Variable_1, Variable_2 and Method_1.

To describe the components of an Object on the ObjectType the same NodeClasses and References are used on the Object and on the ObjectType like for ObjectType_Y in the example. The instance Nodes used to describe an ObjectType are instance declaration Nodes.

To provide more detailed information for a Node, a subset or all Attributes and their values can be added to a graphical symbol.

4.3 Use Cases

The specification describes the combination of AutomationML with OPC UA online information like process data and diagnostic information. It extends the application domain of OPC UA (see Figure 6). Therefore, different use cases which will be possible by the combination of both standards were identified.

One opportunity from combining AutomationML and OPC UA is to communicate and operationalise AutomationML by means of OPC UA. It is possible to simplify the creation of OPC UA information models based on existing AutomationML data. This can be realized by a so called OPC UA companion specification due to analogies between AutomationML and the OPC UA information model. The companion specification for AutomationML consists of an object model including many specific semantics which can be used online with multiple involved parties by OPC UA. This makes an online version of the AutomationML model possible - AutomationML models can be exchanged via OPC UA – and includes OPC UA data management, online communication functionality, multi-user support, access methods, security, etc. This is especially important for re-engineering and maintenance use cases where the AutomationML model evolves over time. The present AutomationML model can be managed by OPC UA and makes an up-to-date description of the system as-is possible.

One other opportunity is the lossless exchange of the OPC UA system configuration within AutomationML models. The manual exchange of OPC UA server configuration data will be replaced by a specified description in AutomationML. Parameters to set up OPC UA communication between tools can be exchanged using AutomationML. This realizes consistent data, produces less errors and results in an easier and faster configuration of UA servers and clients. OPC UA can benefit from the description of the complete communication network configuration and structure including communication components of sensors and actuators with respect to communication system parameters, network structure and wiring, quality of service.

5 AutomationML Model Overview

5.1 Modeling concepts

AutomationML models are divided into different hierarchical trees (see Figure 7): InstanceHierarchy, RoleClassLibs, SystemUnitClassLib, and InterfaceClassLib.

The main AutomationML elements and all possible relations between them are shown in Figure 8. The organization in a hierarchical tree involves that every element type can have child elements of the same type (see ChildElement relations). SystemUnitClasses and RoleClasses are defined in an inheritance structure; the RefBaseClassPath relations define such inheritance relations. RoleClasses can be assigned to SystemUnitClasses and InternalElements. In the latter case there are two different ways to make the RoleClass assignment using SupportedRoleClasses or the RoleRequirement. The remaining arrows in Figure 8 describe the possible relations between InternalElements and SystemUnitClasses. An InternalElement can inherit from a SystemUnitClass. In the scope of AutomationML SystemUnitClasses are only templates and can be changed after instantiation. The backward relation indicates that a SystemUnitClass can define sub-elements in terms of InternalElements. These sub-elements (InternalElements) should be included on instantiation. RoleClasses describe functions of a physical or logical plant object independent of a technical implementation. They offer a possibility to specify an object in an abstract way and independent of the manufacturer. The assignment of a RoleClass to an object (SystemUnitClass or InternalElement) results in the allocation of fundamental functions or requirements.

Figure 9 depicts the basic structure of a RoleClass (RC), SystemUnitClass (SUC), or InternalElement (IE). Each can contain arbitrary nested Attributes and Interfaces (see ChildElement relations). The Interfaces are called ExternalInterfaces and shall inherit from an InterfaceClass. They can be connected to other ExternalElements via InternalLinks. The InterfaceClasses are stored hierarchically and shall have independent inheritance relations. InterfaceClasses and certainly ExternalInterfaces may also have arbitrary nested Attributes.

5.2 Model Overview

5.2.1 Mapping Explanations for Namespaces

Several nodesets (see Figure 10) are defined to organise the address space. Figure 10 includes the nodeset name, the corresponding namespace URI and the file name containing the nodeset. All nodesets are based on the UA Base types. The nodeset AutomationML Base types (AML, see Chapter 6) defines all nodes and type definitions necessary for the modelling of AutomationML in OPC UA. This includes e.g. organisational nodes for the entry into the AutomationML folder for RoleClassLibs or AutomationML types (ObjectType CAEXFileType). One nodeset is defined for the standardised and informative AutomationML libraries (AMLLibs, see Chapter 6.4) coming from IEC62714-1, IEC62714-2, IEC62714-3, and IEC62714-4. And finally, one or more nodesets are used for the concrete AutomationML documents (Filename of each AutomationML document).

5.2.2 Mapping Explanations for AutomationML model elements

The main structure of an AutomationML file from Figure 7 is mapped into a slightly variant structure depicted in Figure 11. The InstanceHierarchies and libraries shall be stored in common folders (AutomationMLInstanceHierarchies, AutomationMLLibraries, AutomationMLSystemUnitClassLibs, AutomationMLRoleClassLibs, AutomationMLInterfaceClassLibs).

The AutomationML BaseElementTypes transformation into OPC UA Types is depicted in Figure 12, the transformation of AutomationML elements into OPC UA Types is depicted in Figure 13.

Figure 12 depicts the mapping of the relations between the main AutomationML elements (see Figure 8). The structure of the picture is not changed, so the mapping can be read directly from the graphic. Table 7 and Table 8 resume the mapping rules in a list. Basically, AutomationML InternalElements are represented by OPC UA Objects, AutomationML SystemUnitClasses and RoleClasses are represented by OPC UA ObjectTypes. Detailed definition of new ObjectTypes, ReferenceTypes and VariableTypes are given in Chapter 6.

ChildElement relations within class structures (SystemUnitClass, RoleClass) are mapped to the OPC UA ‘Organizes’ references. InternalElements which follow the ChildElement relation are referenced via ‘HasComponent’ references. The inheritance relations within SystemUnitClasses and RoleClasses are mapped to OPC UA ‘HasSubtype’ references. The internal structures of SystemUnitClasses are depicted by InternalElements which are connected via OPC UA ‘HasComponent’ references. The RefBaseClassPath relation of AutomationML is an OPC UA ‘HasTypeDefinition’ reference. The referencing of RoleClasses to InternalElements or SystemUnitClasses via SupportedRoleClass or RoleRequirement of AutomationML is done via OPC UA ‘HasAMLRoleReference’ references.

The mappings of the AutomationML object details (see Figure 9) are depicted in Figure 13. The analogy between the two figures is obvious. Table 9 and Table 10 summarize the mapping rules in a list. AutomationML Attributes become OPC UA Variables. AutomationML InterfaceClasses are transformed into OPC UA ObjectTypes and the corresponding AutomationML ExternalInterface elements are modelled by OPC UA Objects.

The Attributes and ExternalInterfaces are referenced via ‘HasComponent’ references. The InterfaceClass is the type definition of the ExternalInterface therefore it is assigned via ‘HasTypeDefinition’ reference. Similarly to the RoleClasses and SystemUnitClasses, the relations between InterfaceClasses are mapped to ‘Organizes’ references within the XML tree structure and to ‘HasSubtype’ references concerning inheritance relation. Relations between ExternalInterfaces (AutomationML InternalLinks) are assigned via ‘HasAMLInternalLink’ reference. Details are given in Chapter 6.

5.3 Mapping Example

Figure 14 depicts the tree structure of an AutomationML example. This example shows a simple AutomationML document (version 2.0) which contains:

one InstanceHierarchy with InternalElements

one SystemUnitClassLib with one SystemUnitClass

one RoleClassLib with one RoleClass and

one InterfaceClassLib with one InterfaceClass.

The elements in this example are designed to model some aspects of a manufacturing system. The RoleClassLib contains a RoleClass to characterize a system component as a ’Tool’. The InterfaceClassLib contains an InterfaceClass which models the energy supply of any tool. The SystemUnitClassLib contains a class representing an electric screwdriver. The InstanceHierarchy describes a manufacturing system containing the two screwdrivers in the system.

The used AutomationML-Libraries (AutomationMLBaseRoleClassLibrary and AutomationMLInterfaceClassLibrary) are stored in separated CAEX files and are included via external references.

Annex A contains the XML text of the example in AutomationML.

The example shown in Figure 14 will now be redefined within OPC UA. Annex A contains the XML text of the example in OPC UA.

Figure 15 depicts the main structure of the example including the folder objects for the organization of the address space. The used graphical notation is defined by the OPC Foundation and is explained in chapter 4.2.2. It includes the OPC UA Objects used to organize the address space structure which are explained in chapter 6.4.1.

Figure 16 depicts the role classes of the example. It includes the inheritance structure of the roles. In the RoleClassLibs ‘ManufacturingRoleClasses’ the RoleClass ‘Tool’ is included.

Figure 17 shows the SystemUnitClasses. The SystemUnitClassLib ‘LibOfCommonTools’ includes a SystemUnitClass ‘ElectricScrewdriver’ with reference to the role ‘Tool’. This SystemUnitClass includes an ExternalInterface ‘EnergySupply’.

In Figure 18 you can find the InterfaceClassLib ‘MyInterfaces’ including the InterfaceClass ‘Energy’.

The mapping of the InstanceHierarchy is shown in Figure 19. The File ‘Topology.aml’ includes the InstanceHierarchy ‘ManufacturingSystem’ which includes two InternalElements ‘firstScrewdriver’ and ‘secondScrewdriver’. They are derived from the SystemUnitClass ‘ElectricScrewdriver’ and inherit its structure and elements, such as a variable ‘ID’, an ExternalInterface ‘EnergySupply’ and the assigned RoleClass ‘Tool’. The InternalElement ‘firstScrewdriver’ additionally consists of a variable ‘NewAttribute’.

6 AutomationML Base Types OPC UA Model

6.1 ObjectTypes

6.1.1 General

The property ID of the ObjectType nodes describes a unique identifier.

The property Version of the ObjectType nodes consists of organizational information about the state of the version.

6.1.2 CAEXBasicObjectType

6.1.2.1 General

The CAEXBasicObjectType defines all general characteristics of a CAEX element. All other CAEX elements derive from it. The CAEXBasicObjectType inherits all Properties of the BaseObjectType.

6.1.2.2 ObjectType Definition

The CAEXBasicObjectType is formally defined in Table 11 .

6.1.2.3 ObjectType Description

6.1.2.3.1 Version

Version provides the version number for the CAEXBasicObjectType

6.1.3 CAEXFileType

6.1.3.1 General

The CAEXFileType defines all general characteristics of a CAEX file and includes all CAEX libraries and instance hierarchies. The CAEXFileType inherits all properties of the CAEXBasicObjectType.

6.1.3.2 ObjectType Definition

The CAEXFileType is formally defined in Table 12 .

6.1.3.3 ObjectType Description

6.1.3.3.1 InstanceHierarchies

The InstanceHierarchies folder includes all CAEX InstanceHierarchies of a CAEX file.

6.1.3.3.2 InterfaceClassLibs

The InterfaceClassLibs folder includes all CAEX InterfaceClassLibs of a CAEX file.

6.1.3.3.3 RoleClassLibs

The RoleClassLibs folder includes all CAEX RoleClassLibs of a CAEX file.

6.1.3.3.4 SystemUnitClassLibs

The SystemUnitClassLibs folder includes all CAEX SystemUnitClassLibs of a CAEX file.

6.1.4 CAEXObjectType

6.1.4.1 General

The CAEXObjectType defines all general characteristics of a CAEX object. All other CAEX objects derive from it. The CAEXObjectType inherits all Properties of the CAEXBasicObjectType.

6.1.4.2 ObjectType Definition

The CAEXObjectType is formally defined in Table 13 .

6.1.4.3 ObjectType Description

6.1.4.3.1 ID

ID provides a unique ID of the CAEXObjectType which shall be in form of a UUID.

6.1.5 AutomationMLBaseInterface

6.1.5.1 General

The AutomationMLBaseInterface defines all general characteristics of a CAEX InterfaceClass object. All other InterfaceClass objects derive from it. The CAEXObjectType inherits all Properties of the CAEXObjectType.

6.1.5.2 ObjectType Definition

The AutomationMLBaseInterface is formally defined in Table 14 .

6.1.6 AutomationMLBaseRole

6.1.6.1 General

The AutomationMLBaseRole defines all general characteristics of a CAEX RoleClass object. All other RoleClass objects derive from it. The AutomationMLBaseRole inherits all Properties of the CAEXObjectType.

6.1.6.2 ObjectType Definition

The AutomationMLBaseRole is formally defined in Table 15 .

6.1.7 AutomationMLBaseSystemUnit

6.1.7.1 General

The AutomationMLBaseSystemUnit defines all general characteristics of a CAEX SystemUnitClass object. All other SystemUnitClass objects derive from it. The CAEXObjectType inherits all Properties of the CAEXObjectType.

6.1.7.2 ObjectType Definition

The AutomationMLBaseSystemUnit is formally defined in Table 16 .

6.2 ReferenceTypes

Following the AutomationML specific OPC UA definitions will be listed.

6.2.1 HasAMLRoleReference

6.2.1.1 General

The HasAMLRoleReference is a concrete ReferenceType that can be used directly. It is a subtype of NonHierarchicalReference.

6.2.1.2 ObjectType Definition

The HasAMLRoleReference is formally defined in Table 17.

This ReferenceType is used to describe a SupportedRoleClass or RoleRequirement relation in AutomationML.

The SourceNode of this ReferenceType shall be an object.

The TargetNode of this ReferenceType shall be a subtype of AMLRoleClass.

6.2.2 HasAMLInternalLink

6.2.2.1 General

The HasAMLInternalLink is a concrete ReferenceType that can be used directly. It is a subtype of NonHierarchicalReference.

6.2.2.2 ReferenceType Definition

The HasAMLInternalLink is formally defined inTable 18.

This ReferenceType is used to describe an InternalLink relation in AutomationML.

The SourceNode of this ReferenceType shall be an object which is derived from the AutomationMLBaseInterface or one of its subtypes.

The TargetNode of this ReferenceType shall be an object which is derived from the AutomationMLBaseInterface or one of its subtypes.

6.3 VariableTypes

6.3.1 AMLBaseVariableType

6.3.1.1 General

The AMLBaseVariableType defines all general characteristics of AutomationML attributes. All other AutomationML attributes derive from it.

6.3.1.2 VariableType Definition

The AMLBaseVariableType is formally defined in Table 19 .

6.3.1.3 VariableType Description

6.3.1.3.1 ID

ID provides a unique ID of the AMLBaseVariableType which shall be in form of a UUID.

6.3.1.3.2 Version

Version provides the version number for the AMLBaseVariableType

6.4 Mapping of AutomationML XML DataTypes to OPC UA DataTypes

The mapping of AutomationML XML DataTypes to OPC UA DataTypes is described in Table 20.

6.4.1 OPC UA Objects used to organize the address space structure

The access to the model is split up into an AutomationML specific entry possibility and an OPC UA specific entry possibility. The organizational nodes facilitate the navigation (browse) to elements. Figure 20 depicts an example address space. Different colours represent different nodesets as explained in chapter 5.2.1.

For users familiar with OPC UA, objects and object types can be accessed via the classical UA way (Objects folder and ObjectTypes folder). The global instance view can be reached via the Objects node and a specific node called AutomationMLInstanceHierarchies of type FolderType. The global type view can be reached via the ObjectTypes node and the corresponding AutomationML-specific object types.

The file view is dedicated to AutomationML users who are looking for a direct AutomationML view/representation. This is realized by the node of type FolderType named AutomationMLFiles below the Objects node. This node organizes all File_xyz nodes where File_xyz stands for the AML file name.

The File_xyz node consists of nodes of type FolderType called

InstanceHierarchies(for AutomationML InstanceHierarchy elements),

RoleClassLibs (for AutomationML RoleClassLibrary elements),

SystemUnitClassLibs (for AutomationML AutomationML SystemUnitClassLibrary elements), and

InterfaceClassLibs (for AutomationML InterfaceClassLibrary elements).

Below File_xyz all references must be browsable bidirectionally (isForward = False).

The naming for the AutomationML specific nodes is as follows: AutomationMLFiles, AutomationMLLibraries, AutomationMLInstanceHierarchies, CAEXBaseType are entry points into the hierarchies. They include AutomationML or CAEX in their browse names. Everything below these nodes does not need an AutomationML or CAEX prefix anymore, e.g. RoleClassLibs.

Be careful: The representation of the inheritance hierarchy is confusing if more than one file and AML base libraries are included in one OPC UA address space (with different nodesets).

6.4.1.1 Instances and entry points

6.4.1.1.1 AutomationMLFiles

This Instance is a child of Objects. It is defined in Table 21 .

The AutomationMLFiles folder represents a browse entry point when looking for AutomationML files in the OPC UA information model.

6.4.1.1.2 AutomationMLInstanceHierarchies

This Instance is a child of Objects. It is defined in Table 22 .

The AutomationMLInstanceHierarchies folder represents a browse entry point when looking for AutomationML InstanceHierarchies in the OPC UA information model.

6.4.1.1.3 AutomationMLLibraries

This Instance is a child of Objects. It is defined in Table 23 .

The AutomationMLLibraries folder represents a browse entry point when looking for AutomationML libraries in the OPC UA information model.

6.4.1.1.4 InterfaceClassLibs

This Instance is a child of AutomationMLLibraries. It is defined in Table 24 .

The InterfaceClassLibsfolder represents a browse entry point when looking for AutomationML InterfaceClassLibs in the OPC UA information model.

6.4.1.1.5 RoleClassLibs

This Instance is a child of AutomationMLLibraries. It is defined in Table 25 .

The RoleClassLibsfolder represents a browse entry point when looking for AutomationML RoleClassLibs in the OPC UA information model.

6.4.1.1.6 SystemUnitClassLibs

This Instance is a child of AutomationMLLibraries. It is defined in Table 26 .

The SystemUnitClassLibsfolder represents a browse entry point when looking for AutomationML SystemUnitClassLibs in the OPC UA information model.

7 AutomationML Libraries OPC UA Model

7.1 General

The property ID of the ObjectType nodes describes a unique identifier.

The property Version of the ObjectType nodes consists of organizational information about the state of the version.

7.2 AutomationMLInterfaceClassLib

7.2.1 Instances

7.2.1.1 AutomationMLInterfaceClassLib

This Instance is a child of InterfaceClassLibs. It is defined in Table 27.

It consists of the Standard AutomationML Interface Class Library (Part 1). The content is extended with Part 3 and Part 4 of the AutomationML standard specification.

7.2.2 ObjectTypes

7.2.2.1 AutomationMLBaseInterface

7.2.2.1.1 General

The interface class “AutomationMLBaseInterface” is a base abstract interface type and shall be used as parent for the description of all AML interface classes.

7.2.2.1.2 ObjectType Definition

The AutomationMLBaseInterface is formally defined in Table 28.

7.2.2.2 AttachmentInterface

7.2.2.2.1 General

The interface class “AttachmentInterface” shall be used to denote a geometrical connection point of an AutomationML object.

7.2.2.2.2 ObjectType Definition

The AttachmentInterface is formally defined in Table 29.

7.2.2.3 Communication

7.2.2.3.1 General

The interface class “Communication” shall be used for the description of communication related interfaces.

7.2.2.3.2 ObjectType Definition

The Communication is formally defined in Table 30.

7.2.2.4 SignalInterface

7.2.2.4.1 General

The interface class “SignalInterface” shall be used for modelling signals.

7.2.2.4.2 ObjectType Definition

The SignalInterface is formally defined in Table 31.

7.2.2.5 ExternalDataConnector

7.2.2.5.1 General

The interface class “ExternalDataConnector” is a basic abstract interface type and shall be used for the description of connector interfaces referencing external docu¬ments. The classes “COLLADAInterface” and “PLCopenXMLInterface” are derived from this class. All existing and future connector classes shall be derived directly or indirectly from this class.

7.2.2.5.2 ObjectType Definition

The ExternalDataConnector is formally defined in Table 32.

7.2.2.5.3 ObjectType Description

7.2.2.5.3.1 refURI

The attribute “refURI” shall be used in order to store the path to the reference external document.

7.2.2.6 COLLADAInterface

7.2.2.6.1 General

The interface class “COLLADAInterface” shall be used in order to reference external COLLADA documents and to publish interfaces that are defined inside an external COLLADA document. Details are intended to be specified in IEC 62714-3.

7.2.2.6.2 ObjectType Definition

The COLLADAInterface is formally defined in Table 33.

7.2.2.6.3 ObjectType Description

7.2.2.7 PLCopenXMLInterface

7.2.2.7.1 General

The interface class “PLCopenXMLInterface” shall be used in order to reference external PLCOpenXML documents and to publish interfaces that are defined inside an external PLCOpenXML document. Details are intended to be specified in IEC 62714-3.

7.2.2.7.2 ObjectType Definition

The PLCopenXMLInterface is formally defined in Table 34.

7.2.2.8 LogicInterface

7.2.2.8.1 General

The interface class “LogicInterface” shall be used in order to reference a logic description within an external PLCopen XML document.

7.2.2.8.2 ObjectType Definition

The LogicInterface is formally defined in Table 35.

7.2.2.9 VariableInterface

7.2.2.9.1 General

The interface class “VariableInterface” shall be used in order to reference variables in external PLCopen XML document.

7.2.2.9.2 ObjectType Definition

The VariableInterface is formally defined in Table 36.

7.2.2.10 InterlockingVariableInterface

7.2.2.10.1 General

The interface class “InterlockingVariableInterface” shall be used in order to reference variables representing an interlocking condition in external PLCopen XML document.

7.2.2.10.2 ObjectType Definition

The InterlockingVariableInterface is formally defined in Table 37.

7.2.2.10.3 ObjectType Description

7.2.2.10.3.1 SafeConditionEquals

SafeConditionEquals indicates which value of the reference variable indicates a save state. Values are

“TRUE”: indicates that the value “TRUE” of the variable within the PLCopen XML description represents the safe state of the signal group.

“FALSE”: indicates that the value “FALSE” of the variable within the PLCopen XML description represents the safe state of the signal group.

Note: Use of the attribute is optional, default value is TRUE

7.2.2.11 InterlockingConnector

7.2.2.11.1 General

The interface class “InterlockingConnector” shall be used in order to model relations between signal groups and component groups.

7.2.2.11.2 ObjectType Definition

The InterlockingConnector is formally defined in Table 38.

7.2.2.11.3 ObjectType Description

7.2.2.12 Order

7.2.2.12.1 General

The interface class “Order” is an abstract class that shall be used for the description of orders, e.g. a successor or a predecessor.

7.2.2.12.2 ObjectType Definition

The Order is formally defined in Table 39.

7.2.2.12.3 ObjectType Description

7.2.2.12.3.1 Direction

The attribute “Direction” shall be used in order to specify the direction. Permitted values are “In”, “Out” or “InOut”.

7.2.2.13 PortConnector

7.2.2.13.1 General

The interface class “PortConnector” shall be used in order to provide a high level relation between ports.

7.2.2.13.2 ObjectType Definition

The PortConnector is formally defined in Table 40.

7.2.2.14 PPRConnector

7.2.2.14.1 General

The interface class “PPRConnector” shall be used in order to provide a relation between resources, products and processes.

7.2.2.14.2 ObjectType Definition

The PPRConnector is formally defined in Table 41.

7.2.2.14.2.1 ObjectTypes

7.3 AutomationMLBaseRoleClassLib

7.3.1 Instances

7.3.1.1 AutomationMLBaseRoleClassLib

This Instance is a child of RoleClassLibs. It is defined in Table 42.

It consists of the Standard AutomationML Base Role Class Library (Part 1). The content is extended with Part 3 and Part 4 of the AutomationML standard specification.

7.3.2 ObjectTypes

7.3.2.1 AutomationMLBaseRoleClassLib

7.3.2.1.1 General

The role class “AutomationMLBaseRole” is a basic abstract role type and the base class for all standard or user-defined role classes.

7.3.2.1.2 ObjectType Definition

The AutomationMLBaseRole is formally defined in Table 43.

7.3.2.2 Group

7.3.2.2.1 General

The role class “Group” is a role type for objects that serve for the grouping of mirror objects that belong together from a certain engineering perspective. AML Group objects shall reference this role.

7.3.2.2.2 ObjectType Definition

The Group is formally defined in Table 44.

7.3.2.2.3 ObjectType Description

7.3.2.2.3.1 AssociatedFacet

The attribute “AssociatedFacet” shall be used for the definition of the name of the corresponding Facet. Example: AssociatedFacet = “PLCFacet”

7.3.2.3 Facet

7.3.2.3.1 General

The role class “Facet” is a role type for objects that serve as sub-view on attributes or interfaces of an AML object. AML Facet objects shall reference this role. Details and examples are specified in 8.3.

7.3.2.3.2 ObjectType Definition

The Facet is formally defined in Table 45

7.3.2.4 Port

7.3.2.4.1 General

The role class “Port” is a role type for objects that groups a number of interfaces and allows describing complex interfaces in this way. AML Port objects shall reference this role. Details and examples are specified in 8.2.

7.3.2.4.2 ObjectType Definition

The Port is formally defined in Table 46.

7.3.2.4.3 ObjectType Description

7.3.2.4.3.1 Cardinality

This attribute is a complex attribute which can describe MaxOccur or MinOccur.

7.3.2.4.3.2 Category

The category attribute describes the Port type. The value of this attribute is user-defined. Only ports with the same category value are allowed to be connected. Example: category = “MaterialFlow”

7.3.2.4.3.3 ConnectionPoint

This CAEX Interface allows connecting this Port with a number of other ports on an abstract level. The internal relations between single Port interfaces are not described in this way.

7.3.2.4.3.4 Direction

This attribute shall be used to describe the direction of the Port. Values shall be one of the following: “In” or “Out” or “InOut”. Ports with the direction “In” can only be connected to ports with the direction “Out” or “InOut” and ports with the direction “Out” can only be connected with ports with the direction “In” or “InOut”. Ports with the direction “InOut” can be connected to Ports of arbitrary direction. Examples: Direction =”Out” (e.g. a plug) Direction = “In” (e.g. a socket) Direction = “InOut” This information can be used e.g. in order to prove the validity of a connection.

7.3.2.5 Resource

7.3.2.5.1 General

The role class “Resource” is a basic abstract role type and the base class for all AML resource roles. It describes plants, equipment or other production resources. AML resource objects shall directly or indirectly reference this role.

7.3.2.5.2 ObjectType Definition

The Resource is formally defined in Table 47

7.3.2.6 Product

7.3.2.6.1 General

The role class “Product” is a basic abstract role type and the base class for all AML product roles. It describes products, product parts or product related materials that are processed in the described plant. AML product objects shall directly or indirectly reference this role.

7.3.2.6.2 ObjectType Definition

The Product is formally defined in Table 48.

7.3.2.7 Process

7.3.2.7.1 General

The role class “Process” is a basic abstract role type and the base class for all AML process roles. It describes production related processes. AML process objects shall directly or indirectly reference this role.

7.3.2.7.2 ObjectType Definition

The Process is formally defined in Table 49.

7.3.2.8 Structure

7.3.2.8.1 General

The role class “Structure” is a basic abstract role type for objects that serve as structure elements in the plant hierarchy, e.g. a folder, a site or a manufacturing line. AML structure objects shall directly or indirectly reference this role.

7.3.2.8.2 ObjectType Definition

The Structure is formally defined in Table 50.

7.3.2.9 ResourceStructure

7.3.2.9.1 General

The role class “ResourceStructure” is an abstract role type for a resource oriented object hierarchy. AML resource structure objects shall directly or indirectly reference this role

7.3.2.9.2 ObjectType Definition

The ResourceStructure is formally defined in Table 51.

7.3.2.10 ProductStructure

7.3.2.10.1 General

The role class “ProductStructure” is an abstract role type for a product oriented object hierarchy. AML product structure objects shall directly or indirectly reference this role.

7.3.2.10.2 ObjectType Definition

The ProductStructure is formally defined in Table 52.

7.3.2.11 ProcessStructure

7.3.2.11.1 General

The role class “ProcessStructure” is an abstract role type for a process oriented object hierarchy. AML process structure objects shall directly or indirectly reference this role.

7.3.2.11.2 ObjectType Definition

The ProcessStructure is formally defined in Table 53.

7.3.2.12 Frame

7.3.2.12.1 General

The role class “Frame” denotes a distinct coordinate system. This coordinate system is explicitly accentuated for special usage.

7.3.2.12.2 ObjectType Definition

The Frame is formally defined in Table 54.

7.3.2.13 ComponentGroup

7.3.2.13.1 General

The role class “ComponentGroup” is a role type for objects that group objects belonging to one component group according to the interlocking definition of AutomationML.

7.3.2.13.2 ObjectType Definition

The ComponentGroup is formally defined in Table 55.

7.3.2.14 SignalGroup

7.3.2.14.1 General

The role class “SignalGroup” is a role type for objects that group objects belonging to one signal group according to the interlocking definition of AutomationML.

7.3.2.14.2 ObjectType Definition

The SignalGroup is formally defined in Table 56.

7.3.2.15 PropertySet

7.3.2.15.1 General

The role class “PropertySet” is an abstract role type that serves for the definition of sets of properties corresponding to a certain engineering aspect. AML property set objects shall directly or indirectly reference this role.

7.3.2.15.2 ObjectType Definition

The PropertySet is formally defined in Table 57.

7.4 AutomationMLDMIRoleClassLib

7.4.1 Instances

7.4.1.1 AutomationMLDMIRoleClassLib

This Instance is a child of RoleClassLibs. It is defined in Table 58.

It consists of the AutomationML Discrete Manufacturing Industry Role Class Library.

7.4.2 ObjectTypes

7.4.2.1 DiscManufacturingEquipment

7.4.2.1.1 General

The role class “DiscManufacturingEquipment” shall be used for equipment related to discrete manufacturing industries.

7.4.2.1.2 ObjectType Definition

The DiscManufacturingEquipment is formally defined in Table 59.

7.4.2.2 Transport

7.4.2.2.1 General

The role class “Transport” shall be used for equipment that performs transport processes to transfer items.

7.4.2.2.2 ObjectType Definition

The Transport is formally defined in Table 60.

7.4.2.3 Storage

7.4.2.3.1 General

The role class “Storage” shall be used for equipment that is used to buffer products or material temporarily within the plant. It can also be used to feed products or materials into the production process or to export products or materials out of the production process.

7.4.2.3.2 ObjectType Definition

The Storage is formally defined in Table 61.

7.4.2.4 Fixture

7.4.2.4.1 General

The role class “Fixture” shall be used for equipment that reduces the degrees of freedom of an item.

7.4.2.4.2 ObjectType Definition

The Fixture is formally defined in Table 62.

7.4.2.5 Gate

7.4.2.5.1 General

The role class “Gate” shall be used for equipment that can block or monitor an entrance, departure, or a passage way.

7.4.2.5.2 ObjectType Definition

The Gate is formally defined in Table 63.

7.4.2.6 Robot

7.4.2.6.1 General

The role class “Robot” shall be used for robots.

7.4.2.6.2 ObjectType Definition

The Robot is formally defined in Table 64.

7.4.2.7 Tool

7.4.2.7.1 General

The role class “Tool” shall be used for equipment used by resources that is necessary to or aids in the performance of an operation on the product.

7.4.2.7.2 ObjectType Definition

The Tool is formally defined in Table 65.

7.4.2.8 Carrier

7.4.2.8.1 General

The role class “Carrier” shall be used for transport equipment that carries items.

7.4.2.8.2 ObjectType Definition

The Carrier is formally defined in Table 66.

7.4.2.9 Machine

7.4.2.9.1 General

The role class “Machine” shall be used for mechanic or mechatronic equipment that creates added value on products and is designed expressly to perform specific tasks.

7.4.2.9.2 ObjectType Definition

The Machine is formally defined in Table 67.

7.4.2.10 StaticObject

7.4.2.10.1 General

The role class “StaticObject” shall be used for passive, static items positioned in the production environment.

7.4.2.10.2 ObjectType Definition

The StaticObject is formally defined in Table 68.

7.5 AutomationMLCMIRoleClassLib

7.5.1 Instances

7.5.1.1 AutomationMLCMIRoleClassLib

This Instance is a child of RoleClassLibs. It is defined in Table 69.

It consists of the AutomationML Continuous Manufacturing Industry Role Class Library.

7.5.2 ObjectTypes

7.5.2.1 ContManufacturingEquipment

7.5.2.1.1 General

The role class “ContManufacturingEquipment” shall be used for equipment related to continuous manufacturing industries.

7.5.2.1.2 ObjectType Definition

The ContManufacturingEquipment is formally defined in Table 70.

7.6 AutomationMLBMIRoleClassLib

7.6.1 Instances

7.6.1.1 AutomationMLBMIRoleClassLib

This Instance is a child of RoleClassLibs. It is defined in Table 71.

It consists of the AutomationML Batch Manufacturing Industry Role Class Library.

7.6.2 ObjectTypes

7.6.2.1 BatchManufacturingEquipment

7.6.2.1.1 General

The role class “BatchManufacturingEquipment” shall be used for equipment related to batch manufacturing industries.

7.6.2.1.2 ObjectType Definition

The BatchManufacturingEquipment is formally defined in Table 72.

7.7 AutomationMLCSRoleClassLib

7.7.1 Instances

7.7.1.1 AutomationMLCSRoleClassLib

This Instance is a child of RoleClassLibs. It is defined in Table 73.

It consists of the AutomationML Control Industry Role Class Library.

7.7.2 ObjectTypes

7.7.2.1 ControlEquipment

7.7.2.1.1 General

The role class “ControlEquipment” shall be used for equipment related to a control system. ControlEquipment can be used for every type of industry.

7.7.2.1.2 ObjectType Definition

The ControlEquipment is formally defined in Table 74.

7.7.2.2 Communication

7.7.2.2.1 General

7.7.2.2.2 ObjectType Definition

The Communication is formally defined in Table 75.

7.7.2.3 ControlHardware

7.7.2.3.1 General

The role class “ControlHardware” shall be used for hardware that provides runtime environments.

7.7.2.3.2 ObjectType Definition

The ControlHardware is formally defined in Table 76.

7.7.2.4 PC

7.7.2.4.1 General

The role class “PC” shall be used for any general-purpose computer that provides runtime environments for software being executed on it.

7.7.2.4.2 ObjectType Definition

The PC is formally defined in Table 77.

7.7.2.5 IPC

7.7.2.5.1 General

The role class “IPC” shall be used for any PC-based computing platform for industrial applications that provides runtime environments for software being executed on it.

7.7.2.5.2 ObjectType Definition

The IPC is formally defined in Table 78.

7.7.2.6 Handheld

7.7.2.6.1 General

The role class “Handheld” shall be used for any portable, programmable, electronic device with an own power supply for particular applications.

7.7.2.6.2 ObjectType Definition

The Handheld is formally defined in Table 79.

7.7.2.7 EmbeddedDevice

7.7.2.7.1 General

The role class “EmbeddedDevice” shall be used for any device designed to perform one or a few dedicated software functions. It is embedded as part of a complete device often including hardware and mechanical parts.

7.7.2.7.2 ObjectType Definition

The EmbeddedDevice is formally defined in Table 80.

7.7.2.8 Sensor

7.7.2.8.1 General

The role class “Sensor” shall be used for sensors.

7.7.2.8.2 ObjectType Definition

The Sensor is formally defined in Table 81.

7.7.2.9 Actuator

7.7.2.9.1 General

The role class “Actuator” shall be used for actuators.

7.7.2.9.2 ObjectType Definition

The Actuator is formally defined in Table 82.

7.7.2.10 Controller

7.7.2.10.1 General

The role class “Controller” shall be used for self-acting functionalities that process signals according to a predefined logic and generate output signals in order to reach an intended behaviour of technical processes.

7.7.2.10.2 ObjectType Definition

The Controller is formally defined in Table 83.

7.7.2.11 PLC

7.7.2.11.1 General

The role class “PLC” shall be used for programmable control functionality focusing the processing of signals.

7.7.2.11.2 ObjectType Definition

The PLC is formally defined in Table 84.

7.7.2.12 NC

7.7.2.12.1 General

The role class “NC” shall be used for programmable control functionality focusing the processing of numerical signals.

7.7.2.12.2 ObjectType Definition

The NC is formally defined in Table 85.

7.7.2.13 RC

7.7.2.13.1 General

The role class “RC” shall be used for programmable control functionality driving robots in order to reach an intended behaviour of the robot kinematic system and corresponding connected periphery.

7.7.2.13.2 ObjectType Definition

The RC is formally defined in Table 86.

7.7.2.14 PAC

7.7.2.14.1 General

The role class “PAC” shall be used for programmable automation functionality focusing on cross-domain functionality like binary, motion and continuous control.

7.7.2.14.2 ObjectType Definition

The PAC is formally defined in Table 87.

7.8 AutomationMLExtendedRoleClassLib

7.8.1 Instances

7.8.1.1 AutomationMLExtendedRoleClassLib

This Instance is a child of RoleClassLibs. It is defined in Table 88.

The AutomationMLExtendedRoleClassLibrary is a recommended extension of the AutomationMLBaseRoleClassLib and the AutomationMLDMIRoleClassLib and covers a wide area of typical roles of the discrete manufacturing industry.

7.8.2 ObjectTypes

7.8.2.1 PLCFacet

7.8.2.1.1 General

The role class “PLCFacet” should be used for the view concerning everything involved in PLC control code generators: PLC view on AML objects which points to information concerning PLC.

7.8.2.1.2 ObjectType Definition

The PLCFacet is formally defined in Table 89.

7.8.2.2 HMIFacet

7.8.2.2.1 General

The role class “HMIFacet” should be used for the view concerning everything involved in HMI: HMI view on AML objects which points to information concerning HMI.

7.8.2.2.2 ObjectType Definition

The HMIFacet is formally defined in Table 90.

7.8.2.3 Enterprise

7.8.2.3.1 General

The role class “Enterprise” should be used for business structures. The definition of an “Enterprise” is given in IEC 62264-1:2013, 5.3.2: “An enterprise is a collection of sites and areas and represents the top level of a role based equipment hierarchy. The enterprise is responsible for determining what products will be manufactured, at which sites they will be manufactured, and in general how they will be manufactured. Level 4 functions are generally concerned with the enterprise and site levels. However, enterprise planning and scheduling may involve areas, work centers, or work units within an area.”

7.8.2.3.2 ObjectType Definition

The Enterprise is formally defined in Table 91.

7.8.2.4 Site

7.8.2.4.1 General

The role class “Site” should be used for localisation. It is also used for hierarchical organization. The definition of a “Site” is given in IEC 62264-1:2013, 5.3.3: “A site is a physical, geographical, or logical grouping determined by the enterprise. It may contain areas, production lines, process cells, and production units. Site planning and scheduling may involve cells, lines, or units within the areas. A geographical location and main production capability usually identifies a site. Examples of site identifications are ‘Deer Park Olefins Plant’ and ‘Johnson City Manufacturing Facility’. Sites are often used for rough-cut planning and scheduling. Sites generally have well-defined manufacturing capabilities.

7.8.2.4.2 ObjectType Definition

The Site is formally defined in Table 92.

7.8.2.5 Area

7.8.2.5.1 General

The role class “Area” should be used for production buildings and their subdivisions (structure/hall), used for hierarchical organization. The definition of an “Area” is given in IEC 62264-1:2013, 5.3.4: “An area is a physical, geographical, or logical grouping determined by the site. It may contain process cells, production units, and production lines. The main production capability and geographical location within a site usually identify areas. Examples of area identifications are ‘North End Tank Farm’ and ‘Building 2 Electronic Assembly’. Areas generally have well-defined manufacturing capabilities and capacities. The capabilities and capacities are used for planning and scheduling. An area is made up of lower-level elements that perform the manufacturing functions. There are three types of elements defined that correspond to continuous manufacturing models, discrete (repetitive and nonrepetitive) manufacturing models, and batch manufacturing models. An area may have one or more of any of the lower-level elements depending upon the manufacturing requirements. Many areas will have a combination of production lines for the discrete operations, production units for the continuous processes, and process cells for batch processes. For example, a beverage manufacturer may have an area with continuous mixing in a production unit, which feeds a batch process cell for batch processing, feeding a bottling line for a discrete bottling process.”

7.8.2.5.2 ObjectType Definition

The Area is formally defined in Table 93.

7.8.2.6 ProductionLine

7.8.2.6.1 General

The role class “ProductionLine” should be used for defining the role based equipment hierarchy defined in IEC 62264-1:2013, 5.3.7, for discrete manufacturing at the work cell level: “Production lines and work cells are the lowest level of equipment. Work cells are usually only identified when there is flexibility in the routing of work within a production line. Production lines and work cells may be composed of lower-level elements, but definitions of these are outside the scope of this document. The major processing activity often identifies the production line. Examples of production line identifications are ‘Bottling Line #1’, ‘Capping Line #15’, and ‘Water Pump Assembly Line #4’. Production line and work cells have well-defined manufacturing capabilities and throughput capacities.”

7.8.2.6.2 ObjectType Definition

The ProductionLine is formally defined in Table 94.

7.8.2.7 WorkCell

7.8.2.7.1 General

The role class “WorkCell” should be used for defining the role based equipment hierarchy defined in IEC 62264-1:2013 at the work cell level: for sub units/sub production steps of units/production lines, station, processes single component, cycle, location in which the production step takes place. It is used for hierarchization. The definition of a “WorkCell” is given in IEC 62264-1:2013, 5.3.7: “Production lines and work cells are the lowest level of equipment. Work cells are usually only identified when there is flexibility in the routing of work within a production line. Production lines and work cells may be composed of lower-level elements, but definitions of these are outside the scope of this document. The major processing activity often identifies the production line. Examples of production line identifications are ‘Bottling Line #1’, ‘Capping Line #15’, and ‘Water Pump Assembly Line #4’. Production line and work cells have well-defined manufacturing capabilities and throughput capacities.”

7.8.2.7.2 ObjectType Definition

The WorkCell is formally defined in Table 95.

7.8.2.8 ProcessCell

7.8.2.8.1 General

The role class “ProcessCell” should be used for sub units/sub production steps of units/production lines, station, processes single component, cycle, location in which the production step takes place. It is used for hierarchization. The definition of a “ProcessCell” is given in IEC 62264-1:2013, 5.3.8: “Process cells and units are the lowest level of equipment for batch manufacturing processes. Units are usually only identified if there is flexibility in the routing of product within a process cell. The definitions for process cells and units are contained in the IEC 61512-1 standard. The major processing capability or family of products produced often identifies the process cell. Examples of process cell identifications are ‘Mixing Line #5’ and ‘Detergent Line 13’. Process cells and units have well-defined manufacturing capabilities and batch capacities.”

7.8.2.8.2 ObjectType Definition

The ProcessCell is formally defined in Table 96.

7.8.2.9 Unit

7.8.2.9.1 General

The role class “Unit” should be used for linked chained production plants. It is used for hierarchization. The definition of a “Unit” is given in IEC 62264-1:2013, 5.3.8: “Process cells and units are the lowest level of equipment for batch manufacturing processes. Units are usually only identified if there is flexibility in the routing of product within a process cell. The definitions for process cells and units are contained in the IEC 61512-1 standard. The major processing capability or family of products produced often identifies the process cell. Examples of process cell identifications are ‘Mixing Line #5’ and ‘Detergent Line 13’. Process cells and units have well-defined manufacturing capabilities and batch capacities.”

7.8.2.9.2 ObjectType Definition

The Unit is formally defined in Table 97.

7.8.2.10 ProductionUnit

7.8.2.10.1 General

The role class “ProductionUnit” should be used for sub units/sub production steps of units/production lines, station, processes single component, cycle, location in which the production step takes place. It is used for hierarchization. The definition of a “ProductionUnit” is given in IEC 62264-1:2013, 5.3.6: “Production units are the lowest level of equipment for continuous manufacturing processes. Production units are composed of lower level elements, such as equipment modules, sensors, and actuators, but definitions of these are outside the scope of the IEC 62714 series. A production unit generally encompasses all of the equipment required for a segment of continuous production that operates in a relatively autonomous manner. It generally converts, separates, or reacts to one or more feedstocks to produce intermediate or final products. The major processing activity or product generated often identifies the production unit. Examples of production unit identifications are ‘Catalytic Cracker #1’ and ‘Alkylation Unit 2’. Production units have well-defined processing capabilities and throughput capacities.”

7.8.2.10.2 ObjectType Definition

The ProductionUnit is formally defined in Table 98.

7.8.2.11 StorageZone

7.8.2.11.1 General

The role class “StorageZone” should be used defining the role based equipment hierarchy defined in IEC 62264-1:2013 at the storage zone level: The definition of an “StorageZone” is given in IEC 62264-1: 2013, 5.3.9: “Storage zones and storage units are the lowest level of material movement equipment typically scheduled by the Level 4 and Level 3 functions for discrete, batch and continuous manufacturing processes. A storage zone is a type of work center and a storage unit is a type of work unit that is organized as elements within an area. These are the lower-level elements of an equipment hierarchy used in material storage and movement activities. A storage zone typically has the capability needed for the receipt, storage, retrieval, movement and shipment of materials. This may include the movement of materials from one work center to another work center within or between enterprises.”

7.8.2.11.2 ObjectType Definition

The StorageZone is formally defined in Table 99.

7.8.2.12 StorageUnit

7.8.2.12.1 General

The role class “StorageUnit” should be used defining the role based equipment hierarchy defined in IEC 62264-1:2013 at the storage unit level: The definition of an “StorageUnit” is given in IEC 62264-1: 2013, 5.3.9: “Storage zones and storage units are the lowest level of material movement equipment typically scheduled by the Level 4 and Level 3 functions for discrete, batch and continuous manufacturing processes. Storage units are typically managed at a finer level of detail than a storage zone. The physical location of a storage unit may change over time; for example, for goods in transit. Storage units may be dedicated to a given material, group of materials, or method of storage. Storage units can be further divided to address any hierarchical storage management scheme.”

7.8.2.12.2 ObjectType Definition

The StorageUnit is formally defined in Table 100.

7.8.2.13 Turntable

7.8.2.13.1 General

The role class “Turntable” should be used for rotating transport equipment which changes the horizontal transport direction of a product and/or carrier.

7.8.2.13.2 ObjectType Definition

The Turntable is formally defined in Table 101.

7.8.2.14 Conveyor

7.8.2.14.1 General

The role class “Conveyor” should be used for generic equipment which performs linear transport.

7.8.2.14.2 ObjectType Definition

The Conveyor is formally defined in Table 102.

7.8.2.15 BeltConveyor

7.8.2.15.1 General

The role class “BeltConveyor” should be used for equipment which performs linear transport realized by one or more belts as transport platform.

7.8.2.15.2 ObjectType Definition

The BeltConveyor is formally defined in Table 103.

7.8.2.16 RollConveyor

7.8.2.16.1 General

The role class “RollConveyor” should be used for equipment which performs linear transport realized by a sequence of rolls as transport platform.

7.8.2.16.2 ObjectType Definition

The RollConveyor is formally defined in Table 104.

7.8.2.17 ChainConveyor

7.8.2.17.1 General

The role class “ChainConeyor” should be used for equipment which performs linear transport driven by an endless chain as transport medium.

7.8.2.17.2 ObjectType Definition

The ChainConveyor is formally defined in Table 105.

7.8.2.18 PalletConveyor

7.8.2.18.1 General

The role class “PalletConveyor” should be used for equipment which is especially designed for linear transport of pallets.

7.8.2.18.2 ObjectType Definition

The PalletConveyor is formally defined in Table 106.

7.8.2.19 OverheadConveyor

7.8.2.19.1 General

The role class “OverheadConveyor” should be used for equipment that performs overhead transport of hanging products or carriers.

7.8.2.19.2 ObjectType Definition

The OverheadConveyor is formally defined in Table 107.

7.8.2.20 LiftingTable

7.8.2.20.1 General

The role class “LiftingTable” should be used for equipment that performs discrete vertical transport. The transport medium is also lifted. Normally used for minor heights.

7.8.2.20.2 ObjectType Definition

The LiftingTable is formally defined in Table 108.

7.8.2.21 AGV

7.8.2.21.1 General

The role class “AGV” should be used for equipment that performs automated transportation of discrete units independent of other transport equipment.

7.8.2.21.2 ObjectType Definition

The AGV is formally defined in Table 109.

7.8.2.22 Transposer

7.8.2.22.1 General

The role class “Transposer” should be used for transport equipment that performs the change of the transport medium. Changes the classification or relation of product to the carrier (one to another).

7.8.2.22.2 ObjectType Definition

The Transposer is formally defined in Table 110.

7.8.2.23 CarrierHandlingSystem

7.8.2.23.1 General

The role class “CarrierHandlingSystem” should be used for equipment that performs an action to the carrier.

7.8.2.23.2 ObjectType Definition

The CarrierHandlingSystem is formally defined in Table 111.

7.8.2.24 BodyStore

7.8.2.24.1 General

The role class “BodyStore” should be used for buffering discrete products.

7.8.2.24.2 ObjectType Definition

The BodyStore is formally defined in Table 112.

7.8.2.25 Lift

7.8.2.25.1 General

The role class “Lift” should be used for equipment that performs discrete vertical transport. Normally used for larger heights.

7.8.2.25.2 ObjectType Definition

The Lift is formally defined in Table 113.

7.8.2.26 Rollerbed

7.8.2.26.1 General

The role class “Rollerbed” should be used for a sequence of rolls. None of these rolls are driven.

7.8.2.26.2 ObjectType Definition

The Rollerbed is formally defined in Table 114.

7.8.2.27 StationaryTool

7.8.2.27.1 General

The role class “StationaryTool” should be used for tools fixed at one place.

7.8.2.27.2 ObjectType Definition

The StationaryTool is formally defined in Table 115.

7.8.2.28 MovableTool

7.8.2.28.1 General

The role class “MovableTool” should be used for tools which can be moved by equipment e.g. robots.

7.8.2.28.2 ObjectType Definition

The MovableTool is formally defined in Table 116.

7.8.2.29 ControlCabinet

7.8.2.29.1 General

The role class “ControlCabinet” should be used for enclosed electrical and/or electronic assembly.

7.8.2.29.2 ObjectType Definition

The ControlCabinet is formally defined in Table 117.

7.8.2.30 IODevice

7.8.2.30.1 General

The role class “IODevice” should be used for devices providing the functionality to connect sensors or actuators with an automation system. IODevice can consist of different modules.

7.8.2.30.2 ObjectType Definition

The IODevice is formally defined in Table 118.

7.8.2.31 HMI

7.8.2.31.1 General

The role class “HMI” should be used for the functionality to visualize an industrial control and monitoring system for the effective operation and control of the machine by humans.

7.8.2.31.2 ObjectType Definition

The HMI is formally defined in Table 119.

7.8.2.32 WarningEquipment

7.8.2.32.1 General

The role class “WarningEquipment” should be used for equipment providing warning functionality. NOTE The functionality can be realized in auditive, visual, haptic or other way.

7.8.2.32.2 ObjectType Definition

The WarningEquipment is formally defined in Table 120.

7.8.2.33 ActuatingDrive

7.8.2.33.1 General

The role class “ActuatingDrive” should be used for physical unit used for driving mechanically actuated final controlling elements.

7.8.2.33.2 ObjectType Definition

The ActuatingDrive is formally defined in Table 121.

7.8.2.34 MotionController

7.8.2.34.1 General

The role class “MotionController” should be used for logic to generate set points (the desired output or motion profile) and close a position or velocity feedback loop.

7.8.2.34.2 ObjectType Definition

The MotionController is formally defined in Table 122.

7.8.2.35 Panel

7.8.2.35.1 General

The role class “Panel” should be used for physical object providing one possibility for humans to interact with machines.

7.8.2.35.2 ObjectType Definition

The Panel is formally defined in Table 123.

7.8.2.36 MeasuringEquipment

7.8.2.36.1 General

The role class “MeasuringEquipment” should be used for defining equipment defined in IEC60050-311:2001, 311-03-05: “assembly of measuring instruments intended for specified measurement purposes”

7.8.2.36.2 ObjectType Definition

The MeasuringEquipment is formally defined in Table 124.

7.8.2.37 Clamp

7.8.2.37.1 General

The role class “Clamp” should be used for equipment that performs fixation processes to hold items at one specific point.

7.8.2.37.2 ObjectType Definition

The Clamp is formally defined in Table 125.

7.8.2.38 ProcessController

7.8.2.38.1 General

The role class “ProcessController” should be used for the control of a specific tool or machine that performs process steps on a product.

7.8.2.38.2 ObjectType Definition

The ProcessController is formally defined in Table 126.

7.8.2.39 Loader

7.8.2.39.1 General

The role class “Loader” should be used for equipment to introduce products into the production process.

7.8.2.39.2 ObjectType Definition

The Loader is formally defined in Table 127.