6 OPC UA ObjectTypes

6.1 General remark

The AAS metamodel contains model elements representing security aspects. These are not part of this version of the companion specification and a matter of the next revision.

6.2 AAS root ObjectTypes

Table 11 defines the root class AASAssetAdministrationShellType of the OPC UA Asset Administration Shell.

Note: For a single submodel either a <Submodel> component or a <SubmodelReference> component is created. Submodel references are used in case that the submodel is deployed on a different OPC UA Server, i.e. it is not located in the address space. Otherwise the submodel can be directly added.

The components of the AASAssetAdministrationShellType have additional references which are defined in Table 12.

6.3 AASReferenceType

For AAS references as used in ReferenceElement of RelationshipElement a new non-hierarchial ReferenceType “AASReference” is introduced (Figure 9). The OPC UA ReferenceType 0:HasComponent is not directly used to reference an element because OPC UA references can only reference elements in the same address space. For more details please see rule 24 in section 5.1.

The details of the AASReferenceType are defined in Table 13.

The components of the AASReferenceType have additional references which are defined inTable 14.

Objects of the AASReferenceType can reference another referable node instance. Instances of the following ObjectTypes can be referenced:

AASAccessPermissionRuleType

AASAnnotatedRelationshipElementType

AASAssetAdministrationShellType

AASAssetType

0:BaseEventType

AASBlobType

AASCapabilityType

AASConceptDictionaryType

AASCustomConceptDescriptionType

AASFileType

AASEntityType

AASEventType

AASIrdiConceptDescriptionType

AASIriConceptDescriptionType

AASMultiLanguagePropertyType

AASOperationType

AASPropertyType

AASRangeType

AASReferenceElementType

AASRelationshipElementType

AASSubmodelType

AASSubmodelElementType

AASSubmodelElementCollectionType

AASViewType

6.4 Referable and Identifiable

The identification concept serves to clearly identify all AAS elements. In principle, a distinction can be made between the following partial identification concepts, which differ in their validity area (Figure 10).

• Globally unique identification, e.g. IRDI or URI - this is called "Identifiable"

• Locally unique identification (instance-related ID valid only in the inner context of an AAS) - this is called "Referable"

• semantic referencing (reference to a conceptual library (dictionary / repository))

In Figure 10 these are shown. The light blue backed rectangles are each AASs. The attributes of the AAS named in the upper section (AAS - Asset Administration Shell, Asset and Submodel) have a globally valid identifier. In addition to the identifier itself, the identifier is also given its type, which can be URI, IRDI or Custom (manufacturer-specific). The identifiers of these AAS elements are thus unique. This is necessary because it is the entry point into the AAS. If this is compared with an OPC UA Server URI, then the same applies since the validity in the namespace of the OPC UA server must also be unique.

The middle section of Figure 10 shows AAS elements that have locally unique identifiers. This allows for e.g. the same properties can be present several times and also submodels can be used again and again. The validity of this identification concept is only in its context (namespace), i.e. along the composition from the globally unique identifiers until the individual instances. An example of idShort is "MaxTemp" and for the composition in the identification: "urn: PROFIBUS: PROFIBUS-PA: V3-02: Parameter: 1: 1: MaxTemp # 0002".

With these two concepts, the identification of an AAS, i.e. the addressing is clearly possible. However, as with the example of the PROFIBUS PA profile, the name MaxTemp is unique only in this profile. In the planning documents of the plants there are also specifications for the maximum temperature, as well as in the manual of the transmitter. All three parameters correspond to the same understanding, but they are not automatically interconvertible by machine. This is where the third identification concept of AAS comes in. The lower part of Figure 10 shows the semantic references that refer to dictionaries, which are feature catalogs that store the understanding of the properties and important attributes (data type, unit of measurement, ...). From selected AAS elements e.g. submodel and property can be checked if the same thing is meant despite different naming. It is possible to specify only the semantic reference and it is expected that the user can interpret this. However, it is also possible to embed the corresponding dictionary in the AAS.

For these three identification principles, there are corresponding model elements in the AAS metamodel. It is also possible that an element e.g. a submodel has both a local identifier and a semantic reference. The reserved word "keys" encapsulates each of the attributes of the identifier. The attribute "local" allows elements to be located outside the AAS where it is identifiable. Local = "TRUE" means the identifier value "Value" refers to the same AAS, Local = "FALSE" means the identifier value "Value" refers to an external location. The “Local” variable is defined in AASKeyDataType (Table 70).

Figure 11 shows an overview about the IAASReferableType ObjectType.

For the identification concept, a mapping to the OPC UA information model is shown in (Figure 11). It can be seen that "Identifiable" is a specialization of "Referable". The identifiable identification contains not only the identifier but also the type and optionally a version and revision. The Category for the Referable Identifier are inherited. What is striking is that in OPC UA modelling at this level, the formal idShort designation is not visible. idShort is always mapped to the browsing name of an OPC UA node by the generally valid rule (see). In this way, the locally valid identification customary in OPC UA can be used.

Overall, this AAS identification concept is an extension of the OPC UA BrowseName Identification (valid in the namespace of the OPC UA Server).

6.4.1 IAASReferableType

Table 15 defines the AASReferable ObjectType.

The OPC UA node attribute “description” is used for the IAASReferableType instances.

The components of the IAASReferableType have additional references which are defined in Table 16.

6.4.2 IAASIdentifiableType

Table 17 defines the IAASIdentifiable ObjectType.

The components of the IAASReferableType have additional references which are defined in Table 18.

6.4.3 AASAdministrativeInformationType

The AdministrativeInformationType is a subtype of the BaseObjectType. Table 19 defines the AASAdministrationInformation ObjectType.

The components of the AASAdministrativeInformationType have additional references which are defined in Table 20.

6.5 AASIdentifierType

Table 21 defines the AASIdentifier ObjectType. It is used to uniquely identify an entity.

The components of the AASIdentifierType have additional references which are defined in Table 22.

6.6 AASAssetType

Figure 12 shows an overview about the AASAsset ObjectType.

The Asset Type describes meta data of an asset that is represented by an AAS. The asset has a globally unique identifier (I4AASIdentifiableType) plus – if needed – additional domain specific (proprietary) identifiers (Table 23). Optionally it can refer to a list of submodels.

The components of the AASAssetType have additional references which are defined in Table 24.

6.7 AASSubmodelType

Figure 13 shows an overview about the AASSubmodel ObjectType.

A Submodel defines a specific aspect of the asset represented by the AAS and is defined in Table 25.

A submodel is used to structure the information model of an AAS representing the technical functionality of the underlying asset into distinguishable parts. Each submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodel templates. Submodels can have different life-cycles.

Note: The concept of template and instance applies to properties.

The default value of the variable “ModelingKind” is “Instance”.

For each AASSubmodelType instance the semanticId is mapped to the OPC UA HasDictionaryEntry reference. This is why the semanticId refers to the instance of the submodel element. This is equivalent to the DictionaryEntry which refers to the concept dictionary element which describes the individual instance not the submodel type.

The components of the AASSubmodelType have additional references which are defined in Table 26.

6.8 SubmodelElementType specialization

To meet the range of aspects of the assets which have to be described in the AAS a set of submodel element types are defined. Each submodel element type represents one of these aspects. Figure 14 provides a general overview.

6.8.1 AASSubmodelElementType common attributes

Figure 15 shows an overview about the AASSubmodelElement ObjectType.

A data element is a submodel element that is not further composed of other submodel elements (Table 27). A data element is a submodel element that has a value. The type of value may differ for different data elements.

The default value of the variable “ModelingKind” is “Instance”.

For each AASSubmodelElementType instance the semanticId is mapped to the OPC UA HasDictionaryEntry. This is at instance level because the DictionaryEntry refers to the concept dictionary element, which describes the individual instance and not the submodel element type.

The components of the AASSubmodelElementType have additional references which are defined in Table 28.

6.8.2 AASSubmodelElementCollectionType

Figure 16 shows an overview about the AASSubmodelElementCollection ObjectType.

A submodel element collection is a set or list of submodel elements. The AASSubmodelElementCollectionType is defined in Table 29

The components of the AASSubmodelElementCollectionType have additional references which are defined in Table 30.

The value elements in this collection are not ordered (i.e. http://Admin-shell.io/aas/2/0/ SubmodelElementCollection/ordered == False).

6.8.3 AASOrderedSubmodelElementCollectionType

Figure 17 shows an overview about the AASOrderedSubmodelElementCollection ObjectType.

Table 31 defines the AASOrderedSubmodelElementCollection ObjectType.

The components of the AASOrderedSubmodelElementCollectionType have additional references which are defined in Table 32.

The value elements in this collection are ordered (i.e. http://Admin-shell.io/aas/2/0/ SubmodelElementCollection/ordered == True).

6.8.4 AASMultiLanguagePropertyType

Figure 18 shows an overview about the AASMultiLanguageProperty ObjectType

This submodel element type is used for properties with a value that can be provided in multiple languages (see Table 33).

The components of the AASMultiLanguagePropertyType have additional references which are defined in Table 34.

6.8.5 AASPropertyType

Figure 19 shows an overview about the AASProperty ObjectType.

The valueId attribute references a DictionaryEntry. Table 35 defines the AASProperty ObjectType.

The components of the AASPropertyType have additional references which are defined in Table 36.

6.8.6 AASCapabilityType

Table 37 defines the AASCapability ObjectType.

6.8.7 AASOperationType

Figure 20 shows an overview about the AASOperation ObjectType.

AASOperationType is defined in Table 38. It encapsulates the standard OPC UA Method “Operation”. All rules for the OPC UA Method NodeClass declaration apply. “Operation” is defined without Arguments but with the OptionalPlaceholder ModellingRule. As defined in OPC 10000-3, this rule allows the inclusion of Arguments to this Method on sub-types or on instances.

An example of a method definition is:

Signature

Method_xy_name (

)

Each individual element of the InputArgument and OutputArgument has to be referenced by a 0:HasDictionaryEntry to its semantic definition.

6.8.8 AASBlobType

Figure 21 shows an overview about the AASBlob ObjectType.

Table 39 defines the AASBlob ObjectType.

The components of the AASBlobType have additional references which are defined in Table 40.

6.8.9 AASFileType

Figure 22 shows an overview about the AASFile ObjectType.

Table 41 defines the AASFile ObjectType.

The components of the AASFileType have additional references which are defined in Table 42.

The additional reference to the real file of type 0:FileType is optional and not specified as such in the asset administration shell metamodel.

6.8.10 AASRelationshipElementType

Figure 23 shows an overview about the AASRelationElement ObjectType.

A relationship element is used to define a relationship between two referable elements (Table 43).

Objects which have the AASReferenceType shall reference another type. According to Table 43 these are the following references:

the “First” node shall reference the Referable Type instance having the role of the subject

the “Second” node shall reference the Referable Type instance having the role of the object

The components of the AASRelationshipType have additional references defined in Table 44.

Table 45 defines the AASAnnotatedRelationshipElement ObjectType.

The components of the AASAnnotatedRelationshipElementType have additional references which are defined in Table 46.

The following SubmodelElement objects are allowed for AASAnnotatedRelationshipElementType:

AASProperty

AASMultiLanguageProperty

AASRangeType

AASReferenceElementType

AASFileType

AASBlobType

6.8.11 AASReferenceElementType

Figure 24 shows an overview about the AASReferenceElement ObjectType.

An AASReferenceElement has a Reference as value (Table 47). This reference has an aggregation of keys (see Table 47) which represents a key chain. The resolved key chain points to an element.

The Object which has the AASReferenceType shall reference another type. According to Table 47 the “Value” can contain the allowed subtypes of AASSubmodelElementTypes as defined in chapter 6.3.

The components of the AASReferenceElementType have additional references which are defined in Table 48.

6.8.12 AASEventType

Figure 25 shows an overview about the AASEvent ObjectType.

Table 49 defines the AASEvent ObjectType.

6.8.13 AASEntityType

Figure 26 shows an overview about the AASEntity ObjectType.

Table 50 defines the AASEntity ObjectType.

The components of the AASEntityType have additional references which are defined in Table 51.

6.8.14 AASRangeType

If Min missing then negative open range infinitely, if max missing the open range infinitely.

Only simple data type of the OPC UA specification are allowed.

The components of the AASRangeType have additional references which are defined in Table 53.

6.9 Concept description

The AAS can define its own dictionary that contains semantic definitions of its submodel elements. These semantic definitions are called concept descriptions (ConceptDescription). It is optional whether an AAS defines its own concept dictionary (ConceptDescription) or not.

A concept description is inheriting from the predefined OPC UA IrdiDictionaryEntry or UriDictionaryEntry (Figure 27). This is why there are both ObjectTypes: “AASIrdiConceptDescriptionType” or “AASIriConceptDescriptionType” and not only one like for the other AAS classes. Additionally, for user specific dictionaries the “AASCustomConceptDescriptionType” is derived from the general OPC UA DictionaryEntryType. The semanticId is modelled by using the predefined OPC UA ReferenceType HasDictionaryEntry and is either referencing an object of type “AASIrdiConceptDescriptionType” and of type “AASUriConceptDescriptionType” or “AASCustomConceptDescriptionType”. Additionally, a concept description has at least one Add-In to allow the usage of the IEC61360 data specification template (see rules for data specifications in section 5.1 and section 6.10).

The ConceptDescription types are located under the standard OPC UA folder Dictionaries.

6.9.1 AASIrdiConceptDescriptionType

Table 54 defines the AASIrdiConceptDescription ObjectType.

The components of the AASIrdiConceptDescriptionType have additional references which are defined in Table 55.

6.9.2 AASIriConceptDescriptionType

Table 56 defines the AASIriConceptDescription ObjectType.

The components of the AASIriConceptDescriptionType have additional references which are defined in Table 57.

6.9.3 AASCustomConceptDescriptionType

Table 58 defines the AASCustomConceptDescription ObjectType.

The components of the AASCustomConceptDescriptionType have additional references which are defined in Table 59.

6.10 AAS Data Specification Templates

6.10.1 AASDataSpecificationType

Concrete data specifications are inheriting from the AAS ObjectType “AASDataSpecificationType”. The AAS attributes of DataSpecification are modelled as properties of the AASDataSpecificationType but are not instantiated. This is always the case in OPC UA if there are no modelling rules attached to a property (Table 60).

The concept of embedded data specifications is used. The element that is using the data specification uses the OPC ReferenceType “HasComponent”. This Add-In uses pairs of elements: one property being the global external reference to a data specification, the other one the data specification.

6.10.2 AASDataSpecificationIEC61360Type

Figure 28 shows an overview about the AASDataSpecificationIEC61360 ObjectType.

Table 61 defines the AASDataSpecificationIEC61360 ObjectType.

6.10.3 AASDataSpecificationType

The components of the AASDataSpecificationType have additional references which are defined in Table 62.

6.11 AAS Qualifiers

6.11.1 AASQualifierType

Figure 29 shows an overview about the AASQualifier ObjectType.

Table 63 defines the AASQualifier ObjectType.

The components of the AASQualifierType have additional references which are defined in Table 64.

6.11.2 AASQualifier usage

The HasDictionaryEntity of Table 63 is denoted by the complete qualifier. The ValueId of Table 63 is referencing the individual value instantiated in the Value of the AASQualifier instance. There are multiple qualifier value depending on the application domain and the application case. While the semanticId of the qualifier is fixed the semanticId of the ValueId is instance dependent. A JSON example is shown below. The “semanticId” references the AASQualifier instance itself. The "DinSpec29000QualifierType" ValueId Keys value references the “required” value semantic coming from the DIN-SEC 29000.

Note: the IRI for defining the unique semantic ids of the qualifier and its values are only examples.

"qualifiers": [

{

"semanticId": {

"keys": [

{

"type": "GlobalReference",

"local": false,

"value": "http://DINSPEC/29000/PropertyValueStatement/ExpressionSemantic",

"index": 0,

"idType": "IRI"

}

]

},

"type": "ExpressionSemantic",

"value": "REQUIREMENT_0",

"valueId": {

"keys": [

{

"type": "GlobalReference",

"local": false,

"value": " http://DINSPEC/29000/PropertyValueStatement/ExpressionSemantic/Requirement",

"index": 0,

"idType": "IRI"

}

]

},

6.12 AASViewType

Table 65 defines the AASView ObjectType.

For each AASViewType instance the semanticId is mapped to the OPC UA DictionaryEntryType. This is at instance level because the DictionaryEntry refers to the concept dictionary element which describes the individual instance not the AASView type.

The components of the AASViewType have additional references which are defined in Table 66.