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. 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 Assets are described by characteristics according to which assets can be compared. Characteristics that make assets comparable by their magnitude are called quantity, e.g. a length or a temperature. A Unit of Measurement (UoM) defines the magnitude of a quantity, e.g. metre is a unit of the quantity length with a defined magnitude. Referencing a Unit of Measurement allows to state the magnitude of a charasteristic in comparison to that unit, e.g. "The cube has the length of 3 metres.". Not all quantities can be compared even if they share the same Unit of Measurement. E.g. torque and energy both have the physical unit newton-meters (Nm), but they belong to different quantities that cannot be compared. For that reason, in definitions units and quantities should always be given as a pair [100], [101], [102]. Note: Countable quantities are a special kind of quantity whose magnitude is given in discrete values, e.g. "number of pages of the document". The data specification template specified in this document allows to use Units of Measurement by providing a minimal set of attributes conformant to the relevant standards, especially IEC 61360 and ISO/IEC 80000. Different use cases for modelling Units of Measurement have to be distinguished. These use cases build up on one another: Use Case 1: Stating that a value has a specific UoM Use Case 2: Stating that a value has a specific UoM and providing information for interpreting that UoM (focus of this document) Use Case 3: Stating that a value has a user-defined UoM and providing a complete definition of that unit Use Case 1 can be addressed using Part 3a: Data Specification - IEC61360 (IDTA-01003-a) [22]. 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 Measurement 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 Measurement 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. Related Standards 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. The IEC maintains a collection of more than 2,100 units and 350 quantities in the IEC CDD, which complies with the IEC TS 62720 standard.[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] It is widely used, but in some apsects outdated and inconsistent. UNECE Rec. 21 does not list units for continuous quantities, but rather discrete units used in logistics such as package, pallet or item. 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 framework.[4]. This dictionary is still work inprogress. While not being a data dictionary themselves, some existing meta models also provide templates to model units. OPC UA is maintained by the OPC Foundation does not define a unit data dictionary, but provides generic means to model units and quantities.[5],[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 measurement. 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 DataSpecificationUnitOfMeasurement supports the modeling of Units of Measurement for submodel elements with values. Figure 2 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. Figure 2. Overview Relationship Metamodel Part 1 & Data Specification Unit of Measurement 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 Measurement Using the template DataSpecificationIec61360 as specified in IDTA-01003-a is a prerequisite for using the template DataSpecificationUnitOfMeasurement 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 Measurement the Reference DataSpecificationIec61360/unitId does not reference an external data dictionary. Instead it references a ConceptDescription via its ConceptDescription/id. The referenced ConceptDescription shall have the DataSpecificationContent DataSpecificationUnitOfMeasurement. This relation is illustrated exemplary in Figure 3. In that example a property with the idShort "heightOfController7411" has been modelled. This property has the value of "54,4" and its semantics is detailled by the ECLASS data dictionary entry "0173-1#02-BAA020#011". In this example a ConceptDescription is supplied which contains this semantic information. The semanticId references the appropriate ConceptDescription with the DataSpecificationContent DataSpecificationIec61360. Here it is defined that the property is a height and the property’s value is given in the unit "mm". Analogously, the unitId references the ConceptDescription with the DataSpecificationContent DataSpecificationUnitOfMeasurement. Here the definition of the unit and its quantity is given. In this example the definition is supplied by the ECLASS data dictionary entry "0173-1#05-AAA480#003". Figure 3. Exemplary usage of Data Specification Unit of Measurement General Remarks for Working with Units of Measurement This subsection states some general remarks for working with Units of Measurement 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/default unit according to the respective data dictionary shall be used. If the ConceptDescription is provided for a quantitative or measurable property a unit or a unitId shall be supplied in DataSpecification61360 (IDTA-01003-a). If the the respective data dictionary does not define a primary or default unit for a quantitative or measurable property, then a ConceptDescription shall be supplied that defines unit or unitId. If a unit or unitId is supplied that differs from the original property’s data dictionary entry, then the entry in the ConceptDescription takes precendence. Using a unit that differs from the primary or default unit of the property’s data dictionary entry does not break the semantic of that property. The whole purpose of a stringent semantic UoM data dictionary is to create interoperability by enabling applications to convert the value of properties from one UoM to another. If needed, it is possible to model multiple properties that have the identical data dictionary entry with different UoM. However, because Concept Descriptions are unique (identifiable) this modelling task is quite complicated and therefore not recommended. Figure Figure 4 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. Figure 4. Illustration of modelling two properties with identical semantics, but different units 1. https://cdd.iec.ch/ 2. https://unece.org/trade/uncefact/cl-recommendations 3. https://service.unece.org/trade/uncefact/vocabulary/rec20/ 4. https://si-digital-framework.org 5. https://reference.opcfoundation.org/Core/Part8/v105/docs/5.6.3 6. https://reference.opcfoundation.org/Core/Part8/v105/docs/6 7. https://eclipse-esmf.github.io/samm-specification/snapshot/units.html