Introduction

This document is part of the series "Specification of the Asset Administration Shell" that provide the specifications for interoperable usage of the Asset Administration Shell. This part defines a technology-neutral specification of a data specification template, enabling the description of concept descriptions for units of measurement. This UML metamodel serves as the basis for deriving several different formats for exchanging Asset Administration Shells, e.g. for XML, JSON, RDF as described in Part 1 of the document series (IDTA-01001). Data Specification Templates are implemented using the embedded data specification approach. This means, that the implementation is part of the overall schemas as defined for IDTA-01001.

Figure 1 shows the different ways of exchanging information via Asset Administration Shells. This part of the "Specification of the Asset Administration Shell" series is the basis for all of these types of information exchange.

image2
Figure 1. Types of Information Exchange via Asset Administration Shells

File exchange (1) is described in Part 5 of this document series (IDTA-01005).

The API (2) is specified in Part 2 of the document series "Specification of the Asset Administration Shell" (IDTA-01002) [14]. It also includes access to concept descriptions using the data specifications as specified in this document.

The I4.0 language (3) is based on the information metamodel specified in Part 1 and 3 [23].

Part 3 is not a single document. Instead, it is an own series of documents, each featuring a specific use case that is supported by the specified data specification templates.

General

The data specification template specified in this document allows to use Units of Measure (UoM) by providing a minimal set of attributes conformant to the relevant standards, especially IEC 61360 and ISO 80000.

Different use cases for modelling Units of Measures have to be distinguished. These use cases build up on one another:

  1. Stating that a value has a specific UoM

  2. Stating that a value has a specific UoM and providing information for interpreting that UoM

  3. Stating that a value has a user-defined UoM and providing a complete definition

Use Case 1 can be addressed using Part 3a: Data Specification - IEC61360 (IDTA-01003-a). This part provides the two attributes that allow to state a UoM for SubmodelElements with a numerical value, i.e. Property and Range: DataSpecificationIec61360/unitId and DataSpecificationIec61360/unit. The Data Specification Units of Measure is not needed for this use case. Use Case 2 is the topic of the current version of this document. In addition to Use Case 1, the aim is to provide a minimal set of additional attributes to describe a Unit of Measure and reference to external dictionaries for further information. Use Case 3 is currently out of scope but might be addressed in future versions of this document.

A unit of measure defines the magnitude of a quantity, e.g. length is a quantity and metre is a unit of that quantity with a defined magnitude. Multiple data dictionaries that define units and quantities exist with varying size and scope, e.g. ECLASS, IEC CDD or UNECE Recommendation 20. The lists of units ranges from basic SI units over vertical specific units to non-physical units such as “piece”. The attributes for describing UoM defined in this document have been chosen to be as generic as possible, to allow the usage of any of these dictionaries.

In the following some examples for existing data dictionaries are given.

  • IEC maintains in IEC CDD an IEC TS 62720 compliant collection of mover than 1800 units.[1] ECLASS and IEC CDD are continuously working on harmonizing their dictionaries, including the UoM. To assure interoperability when using units these dictionaries relate physical units to their SI unit and provide the respective conversion factors. (However, this is not yet available for all physical units).

  • UNECE Rec. 20 focuses on providing three character alphabetic and alphanumeric codes for representing units of measurement used in international trade.[2],[3]

  • The OPC Foundation does not define a unit dictionary, but provides means to model units and quantities.[4],[5]

  • The Bureau International des Poids et Mesures (BIPM) is the international organization through which Member States work together on matters related to metrology. As the home of the International System of Units (SI) it also lists a set of SI-related units and quantities as part of the SI digital frameweor.[6].

  • The Semantic Aspect Meta Model (SAMM) provides a catalog of units based on UNCE Rec. 20[7] in machine readable form and with unique identifiers. SAMM additionally provides the means to define new units of measure.

Predefined Data Specification Templates

Overview

A data specification template specifies which additional attributes shall be added to an element instance that are not part of the metamodel. Typically, data specification templates have a specific scope. For example, templates for concept descriptions differ from templates for operations, etc. More than one data specification template can be defined and used for an element instance. Which templates are used for an element instance is defined via HasDataSpecification.

This specification template DataSpecificationUnitOfMeasure supports the modeling of units of measure for submodel elements with values.

Overview Relationship Metamodel Part 1 & Data Specification Unit of Measure gives an overview of the data specification template and how it is used in combination with the information model as defined in Part 1 of the document series, namely DataSpecification, DataSpecificationContent, and ConceptDescription.

Overview Relationship Metamodel Part 1 & Data Specification Unit of Measure

@startuml skinparam packageStyle rectangle

package "Data Specification Templates - Part 1" { object DataSpecification [Template] { +description: MultiLanguageTextType[0..1] +administration: AdministrativeInformation[0..1] +id: Identifier +dataSpecificationContent: DataSpecificationContent } abstract class DataSpecificationContent [abstract] {} }

class DataSpecificationUnitOfMeasure<DataSpecificationContent> [Template] { +preferredName: ShortLangStringSet +symbol: string +code: string[0..1] +definition: LangStringSet[0..1] +preferredNameQuantity: ShortLangStringSet[0..1] +quantityID: Identifier[0..1] +classificationSystem: string[0..1] }

package "Concept Descriptions - Part 1" { class ConceptDescription<Identifiable\nHasDataSpecification> { +isCaseOf: Reference[0..*] } }

DataSpecificationContent <|- DataSpecificationUnitOfMeasure ConceptDescription <.. DataSpecificationUnitOfMeasure: may be used as\nData Specification DataSpecification ..> DataSpecificationContent @enduml

Part 1 does not prescribe how to define a concept description; it only supports the definition of concept descriptions. To do so, a data specification template needs to be assigned to the concept description. Which data specification is made available is defined via HasDataSpecification/dataSpecification.

The legend for understanding the UML diagrams and the table specification of the classes is explained in Templates for UML Tables and Legend for UML Modelling.

Using Data Specification Unit of Measure

Using the template DataSpecificationIec61360 as specified in IDTA-01003-a is a prerequisite for using the template DataSpecificationUnitOfMeasure specified in this document. DataSpecificationIec61360 provides the attributes DataSpecificationIec61360/unitId and DataSpecificationIec61360/unit. Thereby, unit is a string with the textual representation of the unit of the value of the SubmodelElement. unitId is a Reference with a matching unique ID of that unit.

When using the Data Specification Unit of Measure the Reference DataSpecificationIec61360/unitId does not reference an external dictionary, but instead references DataSpecificationUnitOfMeasure/id. This relation is illustrated exemplary in Exemplary usage of Data Specification Unit of Measure

Exemplary usage of Data Specification Unit of Measure

@startuml map Property { idShort ⇒ heightOfController7411 description ⇒ "Height of Controller" semanticId ⇒ type=ExternalReference, value=0173-1#02-BAA020#011 valueType ⇒ xs:real value ⇒ 54,4 }

map DataSpecificationIec61360 { administration ⇒ id ⇒ 0173-1#02-BAA020#011 idShort ⇒ height dataSpecification ⇒ https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3 preferredName ⇒ height shortName ⇒ height unit ⇒ mm unitId ⇒ type=ExternalReference, value=0173-1#05-AAA480#003 symbol ⇒ h dataType ⇒ REAL_MEASURE definition ⇒ "with objects with preferred position of use, the dimension which is generally measured oriented to gravity and generally measured perpendicular to the supporting surface" }

map DataSpecificationUnitOfMeasure { id ⇒ 0173-1#05-AAA480#003 idShort ⇒ millimeter dataSpecification ⇒ https://admin-shell.io/DataSpecificationTemplates/DataSpecificationUnitOfMeasure/3 preferredName ⇒ "millimeter" symbol ⇒ "mm" code ⇒ 0173-1#05-AAA480#003 definition ⇒ "0,001 fold of the SI base unit metre" preferredNameQuantity ⇒ "distance" quantityID ⇒ 0173-1#Z4-BAJ199#003 classificationSystem ⇒ "ECLASS" }

Property/semanticId --> DataSpecificationIec61360/id
DataSpecificationIec61360/unitId --> DataSpecificationUnitOfMeasure/id

@enduml

General Remarks for Working with Units of Measure

This subsection states some general remarks for working with Units of Measure that have proven to be helpful when kept in mind.

  • if only a semanticId is provided for a quantitative or measurable property but no ConceptDescription with DataSpecification61360 then the primary unit is used.

  • If the ConceptDescription provided for quantitative or measurable property is incomplete and neither a unit nor a unitId is supplied in DataSpecification61360 (IDTA-01003-a), the primary unit of the property definition according to the semantic repository is used. The semantic repository is identified indirectly via the ConceptDescription/id.

  • If the the applied semantic repository does not define a primary or default unit for a quantitative or measurable property, then a ConceptDescription shall be supplied that defines either unit or unitId.

  • If a unit or unitId is supplied that differs from the original property’s dictionary entry, then the entry in the Data Specification takes precendence.

  • Using a unit that differs from the primary or default unit of the property’s dictionary entry does not break the semantic of that property. The whole purpose of a stringent semantic UoM dictionary is to create interoperability by enabling applications to convert the value of properties from one unit to another.

  • If needed, it is possible to model multiple properties that have the identical dictionary entry with different UoM. However, because Concept Descriptions are unique (identifiable) this modelling task is quite complicated and therefore not recommended. Figure Illustration of modelling two properties with identical semantics with the exception of the UoM illustrates that the change of the unit does not break the semantic of the property, but it does break the addressability of the Concept Description. As the id of the Concept Description must be unique for different contents, the original semanticId can only be transported using the isCaseOf attribute.

Illustration of modelling two properties with identical semantics with the exception of the UoM

@startuml map property_1 { idShort ⇒ heightOfControllerA description ⇒ "Height of Controller" semanticId ⇒ type=ExternalReference, value=0173-1#02-BAA020#012 valueType ⇒ xs:real value ⇒ 54,4 }

map property_2 { idShort ⇒ heightOfControllerB description ⇒ "Height of Controller" semanticId ⇒ type=ConceptDescription, value=myHeight valueType ⇒ xs:real value ⇒ 17,2 }

map ConceptDescription_1_with_DataSpecificationIec61360 { id ⇒ 0173-1#02-BAA020#011 idShort ⇒ height dataSpecification ⇒ https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3 isCaseOf ⇒ 0173-1#02-BAA020#011 preferredName ⇒ height shortName ⇒ height unit ⇒ mm unitId ⇒ type=ExternalReference, value=0173-1#05-AAA480#003 symbol ⇒ h }

map ConceptDescription_2_with_DataSpecificationIec61360 { id ⇒ myHeight idShort ⇒ height dataSpecification ⇒ https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3 isCaseOf ⇒ 0173-1#02-BAA020#011 preferredName ⇒ height shortName ⇒ height unit ⇒ cm unitId ⇒ type=ExternalReference, value=0173-1#05-AAA008#003 symbol ⇒ h }

map ConceptDescription_1_with_DataSpecificationUnitOfMeasure { id ⇒ 0173-1#05-AAA480#003 idShort ⇒ millimeter dataSpecification ⇒ https://admin-shell.io/DataSpecificationTemplates/DataSpecificationUnitOfMeasure/3 preferredName ⇒ "millimeter" symbol ⇒ "mm" code ⇒ 0173-1#05-AAA480#003 definition ⇒ "0,001 fold of the SI base unit metre" preferredNameQuantity ⇒ "distance" quantityID ⇒ 0173-1#Z4-BAJ199#003 classificationSystem ⇒ "ECLASS" }

map ConceptDescription_2_with_DataSpecificationUnitOfMeasure { id ⇒ 0173-1#05-AAA008#003 idShort ⇒ millimeter displayName ⇒ description ⇒ dataSpecification ⇒ https://admin-shell.io/DataSpecificationTemplates/DataSpecificationUnitOfMeasure/3 isCaseOf ⇒ preferredName ⇒ "centimeter" symbol ⇒ "cm" code ⇒ 0173-1#05-AAA008#003 definition ⇒ "0,01 fold of the SI base unit metre" preferredNameQuantity ⇒ "distance" quantityID ⇒ 0173-1#Z4-BAJ199#003 classificationSystem ⇒ "ECLASS" }

property_1/semanticId → ConceptDescription_1_with_DataSpecificationIec61360/id property_2/semanticId → ConceptDescription_2_with_DataSpecificationIec61360/id DataSpecificationIec61360_1/unitId → ConceptDescription_1_with_DataSpecificationUnitOfMeasure/id DataSpecificationIec61360_2/unitId → ConceptDescription_2_with_DataSpecificationUnitOfMeasure/id

@enduml