Common Attributes General This clause specifies the abstract classes that represent commonly used attributes and terminology, together with the classes and data types exclusively used in these classes. They are represented in alphabetical order. Administrative Information Attributes Figure 1. Metamodel of Administrative Information Every identifiable may contain administrative information. Administrative information includes, for example, information about the version of the element, information about who created or who made the last change to the element, information about the languages available in case the element contains text; the master or default language may also be defined for translating purposes, information about the submodel template that guides the creation of the submodel In principle, the version corresponds to the version_identifier according to IEC 62832. However, it is not used for concept identifiers only (IEC TS 62832-1), but for all identifiable elements. Together, version and revision correspond to the version number according to IEC 62832. Other attributes of the administrative information like creator refer to ISO 15836-1:2017, the Dublin Core metadata element set. For more information on the concept of subject, see Attribute Based Access Control (ABAC) [49]. The assumption is that every subject has a unique identifier. AdministrativeInformation allows the usage of templates (HasDataSpecification). Data specifications are defined in separate documents. If an AAS contains two different Submodels with the same semanticId (Submodel/semanticId) these two submodels shall have different IDs (Submodel/id) and differ in either their a) version (Submodel/administration/version) (revision is ignored) or b) their creator (Submodel/administration/creator). With a) both submodels shall have version information. With b) both submodels shall have a creator. Note 1: typically, some of the administrative information like the version number might be part of the identification (Submodel/id). This is similar to the handling of identifiers for concept descriptions using IRDIs. In ECLASS, the IRDI 0173-1#02-AO677#002 contains the version information 002. Note 2: since submodels with different versions shall have different identifiers, it is possible that an Asset Administration Shell has two submodels with the same semanticId but different versions. If an AAS contains two different Submodels guided by the same Submodel Template (SMT), i.e. have the same templateId value (Submodel/administration/templateId), then the two submodels shall have different IDs (Submodel/id). In this case both Submodels shall have a templateId assigned to them (Submodel/administration/templateId). Note 3: In some cases there is neither a semanticId (Submodel/semanticId) nor a template ID (Submodel/administration/templateId) defined for the Submodel. In this case there is no way for the data consumer to formally see whether two Submodels are providing the same semantic information. Note 4: If a template ID of one of the standardized Submodel Templates of the IDTA is used to guide the creation of a Submodel then there is also a semantic ID defined for the Submodel. Class: AdministrativeInformation Explanation: Administrative metainformation for an element like version information Constraint AASd-005: If AdministrativeInformation/version is not specified, AdministrativeInformation/revision shall also be unspecified. This means that a revision requires a version. If there is no version, there is no revision. Revision is optional. Inherits from: HasDataSpecification ID: https://admin-shell.io/aas/3/1/AdministrativeInformation Attribute ID Explanation Type Card. version https://admin-shell.io/aas/3/1/AdministrativeInformation/version Version of the element VersionType 0..1 revision https://admin-shell.io/aas/3/1/AdministrativeInformation/revision Revision of the element RevisionType 0..1 creator https://admin-shell.io/aas/3/1/AdministrativeInformation/creator The subject ID of the subject responsible for making the element Reference 0..1 templateId https://admin-shell.io/aas/3/1/AdministrativeInformation/templateId Identifier of the template that guided the creation of the element Note 1: in case of a submodel, the template ID is the identifier of the submodel template that guided the creation of the submodel. Note 2: the submodel template ID is not relevant for validation. Here, the Submodel/semanticId shall be used. Note 3: usage of the template ID is not restricted to submodel instances. The creation of submodel templates can also be guided by another submodel template. Identifier 0..1 Has Data Specification Attributes Figure 2. Metamodel of HasDataSpecification Class: HasDataSpecification <<abstract>> Explanation: Element that can be extended by using data specification templates. A data specification template defines a named set of additional attributes an element may or shall have. The data specifications used are explicitly specified with their global ID. Inherits from: — ID: https://admin-shell.io/aas/3/1/HasDataSpecification Attribute ID Explanation Type Card. dataSpecification https://admin-shell.io/aas/3/1/HasDataSpecification/dataSpecifications External reference to the data specification template used by the element Note: this is an external reference. Reference 0..* For more details on data specifications, please see Clause Data Specification Templates. Has Extension Attributes Figure 3. Metamodel of Has Extensions Class: HasExtensions <<abstract>> Explanation: Element that can be extended by proprietary extensions Note 1: see Clause Constraints for Extensions for constraints related to extensions. Note 2: extensions are proprietary, i.e. they do not support global interoperability. Inherits from: — ID: https://admin-shell.io/aas/3/1/HasExtensions Attribute ID Explanation Type Card. extension https://admin-shell.io/aas/3/1/HasExtensions/extensions An extension of the element. Extension 0..* Class: Extension Explanation: Single extension of an element Inherits from: HasSemantics ID: https://admin-shell.io/aas/3/1/Extension Attribute ID Explanation Type Card. name https://admin-shell.io/aas/3/1/Extension Name of the extension NameType 1 valueType https://admin-shell.io/aas/3/1/Extension/valueType Data type of the value attribute of the extension Default: xs:string DataTypeDefXsd 0..1 value https://admin-shell.io/aas/3/1/Extension/value Value of the extension ValueDataType 0..1 refersTo https://admin-shell.io/aas/3/1/Extension/refersTos Reference to an element the extension refers to ModelReference<Referable> 0..* Has Kind Attributes Figure 4. Metamodel of HasKind Class: HasKind Explanation: An element with a kind is an element that can either represent a template or an instance. Default for an element is that it is representing an instance. Inherits from: — ID: https://admin-shell.io/aas/3/0/HasKind Attribute ID Explanation Type Card. kind https://admin-shell.io/aas/3/0/HasKind/kind Kind of the element: either template or instance Default Value = Instance ModellingKind 0..1 The kind enumeration is used to denote whether an element is of kind Template or Instance. It is used to distinguish between submodels and submodel templates. Enumeration: ModellingKind Explanation: Enumeration for denoting whether an element is a template or an instance Set of: — ID: https://admin-shell.io/aas/3/0/ModellingKind Literal ID Explanation Template https://admin-shell.io/aas/3/0/ModellingKind/Template specification of the common features of a structured element in sufficient detail that such an instance can be instantiated using it Instance https://admin-shell.io/aas/3/0/ModellingKind/Instance concrete, clearly identifiable element instance. Its creation and validation may be guided by a corresponding element template Has Semantics Attributes Figure 5. Metamodel of Semantic References (HasSemantics) For matching algorithm, see Clause Matching Strategies for Semantic Identifiers. Class: HasSemantics <<abstract>> Explanation: Element that can have a semantic definition plus some supplemental semantic definitions Constraint AASd-118: If a supplemental semantic ID (HasSemantics/supplementalSemanticId) is defined, there shall also be a main semantic ID (HasSemantics/semanticId). Inherits from: — ID: https://admin-shell.io/aas/3/1/HasSemantics Attribute ID Explanation Type Card. semanticId https://admin-shell.io/aas/3/1/HasSemantics/semanticId Identifier of the semantic definition of the element called semantic ID or also main semantic ID of the element Note: it is recommended to use an external reference, (e.g. referencing a globally resolvable semantic definition). This is even recommended in the case a ConceptDescription exists. Otherwise, lookup of the corresponding concept description may fail. In future releases a constraint may be added that makes it mandatory to use external references. Reference 0..1 supplementalSemanticId https://admin-shell.io/aas/3/1/HasSemantics/supplementalIds Identifier of a supplemental semantic definition of the element called supplemental semantic ID of the element Note: it is recommended to use an external reference, (e.g. referencing a globally resolvable semantic definition). This is even recommended in the case a ConceptDescription exists. Otherwise, lookup of the corresponding concept description may fail. In future releases a constraint may be added that makes it mandatory to use external references. Reference 0..* Identifiable Attributes Figure 6. Metamodel of Identifiables An identifiable element is a referable with a globally unique identifier (Identifier). Only the global ID (Identifiable/id) shall be used to reference an identifiable, because the idShort is not unique for an identifiable. Identifiables may have administrative information like version, etc. Non-identifiable referable elements can be referenced. However, this requires the context of the element. A referable that is not identifiable and not child within a SubmodelElementList has a short identifier (idShort) that is unique just in its context, its name space. Information about identification can be found in Clause Identification of Elements. See Clause Which Identifiers for Which Elements? for constraints and recommendations on when to use which type of identifier. See Clause Which Identifiers for Which Elements? for information about which identifier types are supported. Class: Identifiable <<abstract>> Explanation: An element that has a globally unique identifier Note: see Clause 5.3.12.2 for constraints related to identifiables. Inherits from: Referable ID: https://admin-shell.io/aas/3/1/Identifiable Attribute ID Explanation Type Card. administration https://admin-shell.io/aas/3/1/Identifiable/administration Administrative information of an identifiable element Note: some of the administrative information like the version number might need to be part of the identification. AdministrativeInformation 0..1 id https://admin-shell.io/aas/3/1/Identifiable/id The globally unique identification of the element Identifier 1 Qualifiable Attributes Figure 7. Metamodel of Qualifiables Class: Qualifiable <<abstract>> Explanation: A qualifiable element may be further qualified by one or more qualifiers. Note: see Clause Constraints for Qualifiers for constraints related to qualifiables. Inherits from: — ID: https://admin-shell.io/aas/3/1/Qualifiable Attribute ID Explanation Type Card. qualifier https://admin-shell.io/aas/3/1/Qualifiable/qualifiers Additional qualification of a qualifiable element Qualifier 0..* Qualifier Attributes Figure 8. Metamodel of Qualifiers Qualifiers may be defined for qualifiable elements. There are standardized qualifiers defined in IEC CDD, IEC61360-4 – IEC/SC 3D. A level qualifier defining the level type minimal, maximal, typical, and nominal value is specified in IEC 62569-1. In DIN SPEC 92000, qualifier types like e.g. expression semantics and expression logic are defined. Class: Qualifier Explanation: A qualifier is essentially a type-value-pair. Depending on the kind of qualifier, it makes additional statements w.r.t. the value of the qualified element, w.r.t the concept, i.e. semantic definition of the qualified element, w.r.t. existence and other meta information of the qualified element type. Constraint AASd-006: If both, the value and the valueId of a Qualifier are present, the value needs to be identical to the value of the referenced coded value in Qualifier/valueId. Constraint AASd-020: The value of Qualifier/value shall be consistent with the data type as defined in Qualifier/valueType. Inherits from: HasSemantics ID: https://admin-shell.io/aas/3/1/Qualifier Attribute ID Explanation Type Card. kind <<Experimental>> https://admin-shell.io/aas/3/1/Qualifier/kind The qualifier kind describes the kind of qualifier that is applied to the element. Default: ConceptQualifier QualifierKind 0..1 type https://admin-shell.io/aas/3/1/Qualifier/type The qualifier type describes the type of qualifier that is applied to the element. QualifierType 1 valueType https://admin-shell.io/aas/3/1/Qualifier/valueType Data type of the qualifier value DataTypeDefXsd 1 value https://admin-shell.io/aas/3/1/Qualifier/value The qualifier value is the value of the qualifier. ValueDataType 0..1 valueId https://admin-shell.io/aas/3/1/Qualifier/valueId Reference to the global unique ID of a coded value Note: it is recommended to use an external reference. Reference 0..1 It is recommended to add a semanticId for the concept of the Qualifier. Qualifier/type is the preferred name of the concept of the qualifier or its short name. Enumeration: QualifierKind Explanation: Enumeration for kinds of qualifiers Set of: — ID: https://admin-shell.io/aas/3/0/QualifierKind Literal ID Explanation ValueQualifier https://admin-shell.io/aas/3/0/QualifierKind/ValueQualifier Qualifies the value of the element; the corresponding qualifier value can change over time. Value qualifiers are only applicable to elements with kind="Instance". ConceptQualifier https://admin-shell.io/aas/3/0/QualifierKind/ConceptQualifier Qualifies the semantic definition (HasSemantics/semanticId) the element is referring to; the corresponding qualifier value is static. TemplateQualifier https://admin-shell.io/aas/3/0/QualifierKind/TemplateQualifier Qualifies the elements within a specific submodel on concept level; the corresponding qualifier value is static. Note: template qualifiers are only applicable to elements with kind="Template". See constraint AASd-129. Example of a ValueQualifier: property "temperature" and qualifier "value quality" with different qualifier values like "measured", "substitute value". Example of a ConceptQualifier: an Asset Administration Shell with two submodels with different IDs but the same semanticId = "Bill of Material". The qualifier could denote the life cycle with qualifier values like "as planned", "as maintained" etc. (see Figure 21). Example of a TemplateQualifier: a submodel element with qualifier value "mandatory" or "optional". This qualification is needed to build a correct submodel instance. For more information see [48]. Figure 9. Example: Qualifier from IEC CDD Referable Attributes Figure 10. Metamodel of Referables The metamodel differentiates between elements that are identifiable, referable, or none of both. The latter means they are neither inheriting from Referable nor from Identifiable, which applies e.g. to Qualifiers. Referable elements can be referenced via the idShort (with the exception of elements within a SubmodelElementList). For details on referencing, see Clause Referencing in Asset Administration Shells. Not every element of the metamodel is referable. There are elements that are just attributes of a referable. The idShort shall be unique in its name space for non-identifiable referables (exception: referables within a SubmodelElementList) (see Constraint AASd-022). A name space is defined as follows in this context: the parent element(s), which an element is part of and that is either referable or identifiable, is the name space of the element. Examples: a submodel is the name space for the properties directly contained in it; the name space of a submodel element contained in a submodel element collection is the submodel element collection. Class: Referable <<abstract>> Explanation: Note1 : an element that is referable by its idShort. This ID is not globally unique. This ID is unique within the name space of the element. Note 2: see Clause Constraints for Referables and Identifiables for constraints related to referables. Constraint AASd-002: idShort of Referables shall only feature letters, digits, hyphen ("-") and underscore ("_"); starting mandatory with a letter, and not ending with a hyphen, i.e. ^[a-zA-Z][a-zA-Z0-9_-]*[a-zA-Z0-9_]+$. Inherits from: HasExtensions ID: https://admin-shell.io/aas/3/1/Referable Attribute ID Explanation Type Card. category <<Deprecated>> https://admin-shell.io/aas/3/1/Referable/category The category is a value that gives further meta information w.r.t. the class of the element. It affects the expected existence of attributes and the applicability of constraints. Note: The category is not identical to the semantic definition (HasSemantics) of an element. The category could e.g. denote that the element is a measurement value, whereas the semantic definition of the element would denote that it is the measured temperature. NameType 0..1 idShort https://admin-shell.io/aas/3/1/Referable/idShort In case of identifiables, this attribute is a short name of the element. In case of a referable, this ID is an identifying string of the element within its name space. Note: if the element is a property and the property has a semantic definition (HasSemantics/semanticId) conformant to IEC61360, the idShort is typically identical to the short name in English, if available. NameType 0..1 displayName https://admin-shell.io/aas/3/1/Referable/displayName Display name; can be provided in several languages MultiLanguageNameType 0..1 description https://admin-shell.io/aas/3/1/Referable/description Description or comments on the element The description can be provided in several languages. If no description is defined, the definition of the concept description that defines the semantics of the element is used. Additional information can be provided, e.g. if the element is qualified and which qualifier types can be expected in which context or which additional data specification templates. MultiLanguageTextType 0..1 Predefined categories are described in Table 6. Note: categories are deprecated and should no longer be used. Table 1. Categories[1] for Elements with Value Category: Applicable to, Examples: Explanation: CONSTANT Property ReferenceElement An element with the category CONSTANT is an element with a value that does not change over time. In ECLASS, this kind of category has the category "Coded Value". PARAMETER Property MultiLanguageProperty Range SubmodelElementCollection An element with the category PARAMETER is an element that is once set and then typically does not change over time. This applies e.g. to configuration parameters. VARIABLE Property SubmodelElementList An element with the category VARIABLE is an element that is calculated during runtime, i.e. its value is a runtime value. 1. Note: categories of referables are deprecated.