AAS Units of Measurement 3.0: The unitId Change That Breaks ECLASS Wiring

If your Asset Administration Shell repository resolves unitId by looking up an ECLASS or IEC CDD entry, the new AAS Units of Measurement specification quietly inverts that assumption. IDTA published Part 3b — IDTA-01003-b, version 3.0 — in July 2026, and its single most consequential sentence says that when the new template is in play, DataSpecificationIec61360/unitId no longer points at an external dictionary at all. It points at a ConceptDescription that lives inside your own twin. That is a one-line change in a specification and a multi-week change in a deployed repository, because every resolver, every validator and every import pipeline you built around dictionary IRDIs now has to handle a second, structurally different case.

This post is a spec explainer plus a migration guide for people who already run an AAS repository wired to a dictionary. It is not an introduction to the Asset Administration Shell.

What this covers: the unitId redirection and what it breaks, the eight attributes of the new template, the UC1/UC2/UC3 scope boundary and where SAMM beats Part 3b, the quantity-pairing rule behind quantityID, a worked migration, and four naming inconsistencies inside the published PDF that will bite anyone writing a validator against it.

Context and Background

The Asset Administration Shell has always had a way to say “this number is in millimetres”. Part 3a, the IEC 61360 data specification, gives a ConceptDescription two attributes for exactly that: unit, a display string, and unitId, a Reference. In every production stack I have seen, unitId is an ExternalReference whose single key holds an ECLASS IRDI like 0173-1#05-AAA480#003, or an IEC CDD IRDI like 0112/2///62720#UAA862#001. Resolution means leaving the twin and asking a dictionary.

That worked, but it only ever answered half the question. A dictionary lookup tells a human what mm means. It does not travel with the AASX package, it does not survive an air-gapped deployment, and it does not tell a receiving application which quantity the unit belongs to — which, as we will see, is the difference between a torque and an energy. Part 3a can state a unit; it cannot make the unit self-describing.

Part 3b closes that gap. The AAS Units of Measurement template’s entire job is to describe one unit of measurement with a minimal, dictionary-neutral attribute set, and to carry the provenance of that description. The specification is deliberately modest about its ambitions: the preamble calls it “a very simple model … that can be extended in future versions”, and it says plainly that defining new units is out of scope.

Two facts about the release confuse people, so take them up front. First, the version number. The document states that “this version 3.0 is the initial version of the document”, and the change log explains why: “It has been numbered as version 3.0 to be consistent with Part 1 of the specification series.” There was no 1.x and no 2.x of Part 3b. Second, the baseline. The front matter declares dependencies on Part 1 Metamodel version 3.2 and Part 3a IEC 61360 version 3.1. Those are Release 26-01 artefacts. If you are still on an AAS v3.0 or v3.1 stack — and most deployed BaSyx and AASX Package Explorer estates are — Part 3b is not something you can adopt incrementally. It rides on a metamodel upgrade. Our walk-through of that upgrade is in the AAS metamodel 3.2 and Release 26-01 migration guide, and the Industrial Digital Twin Association content hub hosts the canonical PDFs.

How AAS Units of Measurement Rewires the unitId Reference

When a ConceptDescription carries the Part 3b template, DataSpecificationIec61360/unitId stops referencing an external dictionary entry and instead references another ConceptDescription by its ConceptDescription/id. That referenced ConceptDescription must itself carry the Units of Measurement template as its DataSpecificationContent.

The dictionary IRDI does not disappear — it usually becomes the id of the new ConceptDescription — but the semantics of the reference change from “external lookup key” to “internal identifiable object”.

Figure 1: The before/after wiring. Under Part 3a alone, unitId resolves out of the twin to a dictionary. Under Part 3b, it resolves inside the twin to a second ConceptDescription carrying the Units of Measurement template.

The left branch is the legacy path most repositories implement today: a property references a ConceptDescription, that ConceptDescription carries DataSpecificationIec61360, and its unitId holds a dictionary IRDI that only a dictionary can expand. The right branch is the Part 3b path: unitId holds the id of a second ConceptDescription, and that object carries eight attributes that describe the unit, its quantity, and the classification system it came from. The value of the change is that the second branch is resolvable with the package in hand.

The reference type stays External, and that is the trap

Here is the detail that will cost teams a day of debugging. The worked example in the specification models unitId as type=ExternalReference with key/type=GlobalReference and key/value=0173-1#05-AAA480#003 — the same shape as the legacy dictionary reference. It is not remodelled as a ModelReference to a ConceptDescription. The AAS metamodel deliberately allows a GlobalReference to resolve to an identifiable object, and ConceptDescription is Identifiable.

The consequence is that you cannot tell the two cases apart by inspecting the reference. A validator that sees ExternalReference/GlobalReference/0173-1#05-AAA480#003 cannot decide, from that reference alone, whether the target is a dictionary entry or a local ConceptDescription. It has to attempt a lookup in the ConceptDescription repository first and fall back to the dictionary. Any code that branches on reference type will silently take the wrong path, and because both paths produce a plausible answer for well-known units, the failure will not surface until someone ships a unit the dictionary and the twin disagree about.

Changing a unit breaks addressability, not semantics

The specification is unusually explicit about a second-order effect, and it is worth quoting the shape of the argument because it is the thing most coverage will miss. If you model two properties with identical semantics but different units — the same height, once in millimetres and once in centimetres — the change of unit “does not break the semantic of that property, but it does break the addressability of the Concept Description.”

The reason is identity. A ConceptDescription is Identifiable, so its id must be unique for different contents. Two ConceptDescription objects that differ only in their unit cannot share an id. One of them has to get a new one — the specification’s own illustration uses a local identifier such as myHeight. The moment that happens, the original dictionary IRDI can no longer be the id, and the specification says it “can only be transported using the isCaseOf attribute”.

So isCaseOf moves from a rarely-used convenience to a load-bearing part of your model. If your consumers resolve semantics by reading ConceptDescription/id and matching it against a dictionary — which is the naive and extremely common implementation — they will fail to recognise the re-unitised concept. They must instead read isCaseOf and match on that. The specification also notes that this modelling pattern is “quite complicated and therefore not recommended”, which is good advice and no help at all to the many real catalogues that already contain the same characteristic expressed in two units.

What actually breaks in a deployed repository

Four categories of code change behaviour, in rough order of how much work they are.

Resolvers are the obvious one. Any function with the signature “given a unitId reference, return a human-readable unit” must now try the local ConceptDescription store before the dictionary client, and must handle the case where the local object exists but carries the wrong DataSpecificationContent.

Validators are the expensive one. The rule “the referenced ConceptDescription shall have the DataSpecificationContent for Units of Measurement” is a cross-object constraint. It cannot be checked with a JSON Schema pass over a single ConceptDescription; it requires a second read. In a repository with hundreds of thousands of concepts, a naive implementation turns validation from a linear scan into a linear scan plus a lookup per property.

Import pipelines are the subtle one. An ECLASS or IEC CDD import that used to emit one ConceptDescription per property now emits one per property and one per distinct unit, with the unit objects deduplicated across the whole catalogue. That is a genuine change to the shape of the import, not a field mapping.

Package size is the one nobody budgets for. Every distinct unit in your catalogue becomes an Identifiable object inside the AASX package. For a catalogue with a few hundred units this is negligible; for a multi-vendor aggregation with thousands, it is a real increase in payload and in the cost of a full repository sync.

Inside the Template: Eight Attributes and Four Naming Traps

The template defines exactly eight attributes. Two are mandatory and six are optional. The mandatory pair is the minimum viable description of a unit; the optional six carry quantity, definition and provenance.

Figure 2: The DataSpecificationUoM template. preferredName and symbol are mandatory with cardinality 1; the remaining six are optional at 0..1. The simple data types carry real length limits.

preferredName is a LangStringSetUoM with cardinality 1 — the multilingual name of the unit as the classification system defines it, for example “millimetre”. symbol is a StringUoM with cardinality 1 — “mm”. Everything else is 0..1: specificUnitID, definition, preferredNameQuantity, quantityID, classificationSystem and classificationSystemVersion.

The length limits are enforceable constraints, not documentation

Part 3b defines four simple data types and gives each of them a hard character bound, which is more than most data specification templates bother to do. LangStringSetUoM allows each langString a maximum of 256 characters and a minimum of 1. StringUoM is a string of maximum 256 and minimum 1. DefinitionTypeUoM is a LangStringSet whose members run to 2048 characters. IdentifierUoM is a string of up to 2048 characters.

These matter in practice. IEC CDD unit definitions are long — the specification’s own example for the ohm runs to a full sentence with an embedded dimensional equation, and the volt example is longer still. If you import IEC CDD definitions verbatim you will be close to, though under, the 2048-character bound. The 256-character bound on StringUoM also constrains specificUnitID, which is fine for a UNECE common code like MMT and fine for an IRDI, but would not survive a long URL used as a proprietary key. Build the bound into your import validation rather than discovering it at serialisation time.

Four places where the published PDF disagrees with itself

This is the part you will not find in the release announcement, and it is the part that decides whether your validator works. Read the normative clause, not the overview figures.

The template class has two names. The normative specification clause defines the class as DataSpecificationUoM, gives the template id as https://admin-shell.io/DataSpecificationTemplates/DataSpecificationUoM/3, sets dataSpecificationContent to DataSpecificationUoM, and states that the namespace has the qualifier “UoM:”. Every attribute’s semantic identifier follows the same stem — .../DataSpecificationTemplates/DataSpecificationUoM/3/0/DataSpecificationUoM/symbol and so on. But the overview figures earlier in the document, and the prose around them, use DataSpecificationUnitOfMeasurement and the URI https://admin-shell.io/DataSpecificationTemplates/DataSpecificationUnitOfMeasurement/3. Those two URIs are not the same string, and hasDataSpecification/dataSpecification is matched as a string. Pick the normative one — DataSpecificationUoM/3 — and expect to see the long form in early third-party implementations that were written from the figures.

quantityID has two capitalisations. The UML figures and all eight annex mapping tables write quantityID with a capital D. The normative attribute table writes the attribute name as quantityId and gives its semantic identifier as .../DataSpecificationUoM/quantityId — while the explanatory text inside that very row reverts to quantityID. In JSON and RDF serialisations, case matters. Until IDTA issues an erratum, a defensive deserialiser should accept both and emit the normative quantityId.

The worked example and the attribute table give different quantity IRDIs. The usage figure shows quantityID as 0173-1#Z4-BAJ199#003. The normative attribute table’s example, and the ECLASS Advanced mapping table in the annex, both give 0173-1#Z4-BAJ199#002. One of them is a transcription error. Do not hard-code either into a test fixture without checking the live ECLASS entry.

The dependency versions are stated twice, differently. The front-matter “Metamodel Versions” block says Part 1 Metamodel version 3.2 and Part 3a version 3.1. The Normative References clause cites Part 1 as IDTA-01001-3-1 and Part 3a as IDTA-01003-a-3-1, and the specification clause states only that the document “is only valid in combination with IDTA-01001-3 and IDTA-01003-a-3”. The 3.2 figure appears once. Treat Release 26-01 as the target baseline, and confirm the exact Part 1 revision against your stack before you commit to a migration window.

None of these are fatal. All of them are the kind of thing that turns a two-day integration into a two-week one if you discover them in a customer’s staging environment rather than in the PDF.

Scope: UC1, UC2, UC3 and Where SAMM Still Wins

The specification opens with a three-way use-case split that is the cleanest decision aid in the document, and the fastest way to work out whether you need Part 3b at all.

Figure 3: The scope boundary. UC1 is Part 3a’s job, UC2 is what Part 3b adds, and UC3 — defining a new unit — is explicitly out of scope in version 3.0.

UC1 — state that a value has a specific unit. This is already solved. Part 3a gives you DataSpecificationIec61360/unit and DataSpecificationIec61360/unitId for submodel elements with a numeric value, meaning Property and Range. The specification says directly that the Units of Measurement template “is not needed for this use case”. If all your consumers do is display “54.4 mm”, you are done and you should not adopt Part 3b.

UC2 — state the unit and provide information for interpreting it. This is what Part 3b adds. The interpretation information is the quantity, the definition, and the identity of the classification system that produced both. This is the case that matters for cross-vendor data exchange, where the receiving system has never seen your dictionary and cannot be assumed to have network access to it.

UC3 — state that a value has a user-defined unit, with a complete definition of that unit. Explicitly out of scope. The specification says it “is currently out of scope, but might be addressed in future versions”.

That last boundary is the one that should drive an architecture decision, because a competing metamodel does not have it. The specification itself names the alternative: the Semantic Aspect Meta Model provides a catalogue of units based on UNECE Recommendation 20 in machine-readable form with unique identifiers, and — the spec’s words — “SAMM additionally provides the means to define new units of measurement.”

So the rule is concrete. If your domain has units that no public dictionary carries — a vendor-specific index, a composite rate, a derived figure of merit with a house definition — Part 3b version 3.0 cannot define them for you. It can only reference a definition that exists elsewhere. You either push for the unit to be added to a dictionary, model it as a plain property with a documented convention, or use SAMM for that slice of the model. Our broader comparison of these modelling stacks sits in the AAS vs DTDL vs OPC UA information model analysis.

The double-mapping warning is the most practical advice in the document

The annex carries a warning that deserves more attention than its two paragraphs suggest. If you source your units from a meta model rather than a dictionary — from an OPC UA nodeset, or from SAMM — you introduce “double-mapping”: UNECE Rec 20 attributes were mapped into the SAMM or OPC UA model, and you are now mapping that model’s attributes into the AAS template. The specification observes that double-mapping “often leads to a degradation of the information and should be avoided, if possible.”

The associated modelling rule is stricter than it looks: cite the source you actually used. If your unit definitions came from a SAMM model, set classificationSystem to “SAMM” and classificationSystemVersion to the SAMM version — even though SAMM is itself derived from UNECE Rec 20 — because, in the document’s phrase, “it is good scientific practice to only cite the sources that were actually used and not the sources cited by sources.” The recommended classificationSystem values are “ECLASS”, “IEC CDD”, “UNECE Rec 20”, “UNECE Rec 21”, “BIPM”, “OPC UA” and “SAMM”, and the list is explicitly non-exclusive.

The annex reinforces the point with a table of discouraged modelling. One negative example mixes an IEC CDD identifier with a UNECE-style specificUnitID and a definition from a third source; the explanation is that a receiver “cannot resolve these conflicts and does not know which source has precedence”. The other uses the bare UNECE common code MMT as a ConceptDescription/id, which fails because a three-character code is unique only within its own list and is therefore not a global identifier.

Quantities, Units and the Newton-Metre Trap

Two of the eight attributes exist because of a single, very old metrology problem, and the specification uses it as the normative rationale for the whole quantity half of the template.

Figure 4: Torque and energy share the symbol N.m but belong to different quantities. Because they are numerically equal and semantically incomparable, a unit is only meaningful when paired with its quantity.

Torque and energy both carry the physical unit newton-metre. They are dimensionally identical and they are not interchangeable: one is the moment of a force about an axis, the other is work. You cannot add them, average them, or substitute one for the other in a conversion. The specification’s conclusion is a rule, not an observation: “in definitions units and quantities should always be given as a pair”, citing the international vocabulary of metrology, ISO/IEC 80000-1 and IEC 61360.

preferredNameQuantity and quantityID are the template’s implementation of that pair. Two constraints govern them. First, they “must be consistent if both attributes are set” — you cannot label the quantity “distance” and point quantityID at the IRDI for mass. Second, and more subtly: “if the classification system lists multiple quantities for the unit, exactly one of those quantities must be selected in accordance with the properties purpose.”

That second rule shifts real work onto the modeller. IEC CDD lists the applicable quantities for a unit, and for a unit like the newton-metre there is more than one. The template has no cardinality for “all the quantities this unit could express” — quantityID is 0..1. So the ConceptDescription for a unit is not a neutral dictionary copy; it is a unit as used for a purpose. If your catalogue genuinely needs newton-metres for both torque and energy, you need two ConceptDescription objects with different ids, and you are back in the addressability problem from the previous section.

Why quantityID is optional, and why you should still set it

Both quantity attributes are 0..1, and the annex shows why. The ECLASS Basic mapping table sets quantityID to “—–“, meaning omit it, with the footnote that “ECLASS basic does not provide the IDs of the quantities in its export”. The UNECE Rec 20 mapping also omits quantityID — UNECE publishes a quantity name, not a quantity identifier. Only IEC CDD, ECLASS Advanced, BIPM and SAMM give you a resolvable quantity identifier.

That is a meaningful signal about dictionary quality. If you want machine-checkable quantity pairing rather than a human-readable label, your source dictionary choice is narrower than the marketing suggests. IEC CDD maintains more than 2,100 units and 350 quantities in compliance with IEC TS 62720, and relates physical units to their SI unit with conversion factors — though the specification is careful to add that this “is not yet available for all physical units”. UNECE Recommendation 20 provides three-character alphabetic and alphanumeric codes for trade, is widely used, and is described by the specification as “in some aspects outdated and inconsistent”. The BIPM SI digital framework is described as “still work in progress”, which is an honest assessment of a resource that is excellent for base and coherent derived units and thin beyond them.

A Concrete Migration: One Property, Two Repositories

The specification’s worked example is short enough to reproduce and complete enough to test against, so use it as your migration fixture. A property with idShort heightOfController7411 carries the value 54,4 — rendered with a decimal comma in the specification’s figure, which is worth noticing if you are transcribing by hand — with valueType xs:real. Its semanticId is an ExternalReference to the ECLASS entry 0173-1#02-BAA020#011.

Before Part 3b, the ConceptDescription for that semanticId carries DataSpecificationIec61360 with preferredName “height”, shortName “height”, unit mm, symbol h, dataType REAL_MEASURE, a definition, and unitId as an external reference to 0173-1#05-AAA480#003. That last reference is the whole legacy contract: an opaque dictionary key.

{
  "modelType": "ConceptDescription",
  "id": "0173-1#02-BAA020#011",
  "idShort": "height",
  "embeddedDataSpecifications": [{
    "dataSpecification": {
      "type": "ExternalReference",
      "keys": [{ "type": "GlobalReference",
        "value": "https://admin-shell.io/DataSpecificationTemplates/DataSpecificationIec61360/3" }]
    },
    "dataSpecificationContent": {
      "modelType": "DataSpecificationIec61360",
      "preferredName": [{ "language": "en", "text": "height" }],
      "shortName": [{ "language": "en", "text": "height" }],
      "unit": "mm",
      "symbol": "h",
      "dataType": "REAL_MEASURE",
      "unitId": {
        "type": "ExternalReference",
        "keys": [{ "type": "GlobalReference", "value": "0173-1#05-AAA480#003" }]
      }
    }
  }]
}

After Part 3b, that JSON does not change. Not one byte of it. The migration is entirely additive at this level: you create a second ConceptDescription whose id is the string unitId already pointed at, and you attach the Units of Measurement template to it.

{
  "modelType": "ConceptDescription",
  "id": "0173-1#05-AAA480#003",
  "idShort": "millimeter",
  "embeddedDataSpecifications": [{
    "dataSpecification": {
      "type": "ExternalReference",
      "keys": [{ "type": "GlobalReference",
        "value": "https://admin-shell.io/DataSpecificationTemplates/DataSpecificationUoM/3" }]
    },
    "dataSpecificationContent": {
      "modelType": "DataSpecificationUoM",
      "preferredName": [{ "language": "en", "text": "millimeter" }],
      "symbol": "mm",
      "specificUnitID": "0173-1#05-AAA480#003",
      "definition": [{ "language": "en", "text": "0,001 fold of the SI base unit metre" }],
      "preferredNameQuantity": [{ "language": "en", "text": "distance" }],
      "quantityID": "0173-1#Z4-BAJ199#003",
      "classificationSystem": "ECLASS",
      "classificationSystemVersion": "14.0"
    }
  }]
}

Three things about this fragment deserve comment.

The id and specificUnitID are the same string here, and the specification explains when they should not be. ConceptDescription/id “should be identical to the unique global identifier of the Unit of Measurement, if available”; if no global identifier exists, the id “can be chosen arbitrarily” and the classification system’s own identifier “must be denoted in the attribute specificUnitID“. The ECLASS annex table makes the other case concrete: when you use the ECLASS IRI form https://api.eclass-cdp.com/0173-1-05-AAA480-003 as the id, it recommends putting the IRDI 0173-1#05-AAA480#003 in specificUnitID. For UNECE the pattern inverts — you invent an id because a three-letter code is not globally unique, and specificUnitID holds MMT.

The modelType and dataSpecification URI use the normative DataSpecificationUoM form discussed above, not the long form from the figures. If you are interoperating with an implementation built from the figures, you will need to accept both on read.

classificationSystemVersion is “14.0” in the worked example even though the annex mapping tables show ECLASS 15.0 and snapshots from ECLASS 16.0. The version is per-ConceptDescription, and the annex’s advice is that it “should be consistent throughout an application” — units should not be mixed across dictionary versions. That is a repository-level invariant you should assert in CI, not a per-object nicety.

Sequencing the migration

Do the metamodel upgrade first and separately. Part 3b is unusable below the Release 26-01 baseline, so a Part 3b project that is also a Part 1 upgrade project is two projects. Ship the metamodel move, stabilise, then add units.

Build the unit catalogue second, as a standalone set of ConceptDescription objects derived from a single dictionary at a single version. Deduplicate across your whole property catalogue: one ConceptDescription per distinct unit, not one per property that uses it. If you already run a BaSyx estate, the ConceptDescription repository endpoint is the natural home for it, and our BaSyx implementation walk-through covers the deployment shape.

Change resolvers third, before you change any data. Make every consumer local-first and dictionary-fallback while the legacy references are still valid. Both paths resolve during this window, which is the point.

Only then flip validation to require that unitId targets a resolvable ConceptDescription carrying the AAS Units of Measurement template — and expect that flip to surface every property in your catalogue whose unit was wrong, missing, or quietly inherited from a dictionary default.

Trade-offs, Gotchas, and What Goes Wrong

The honest case against adopting AAS Units of Measurement now is that it buys self-description at the cost of duplication, and the duplication has no built-in consistency check.

You now hold unit information in two places: DataSpecificationIec61360/unit, a display string on the property’s concept, and the full description on the unit’s concept. Nothing in the specification requires them to agree. A property can say unit is “mm” while its unitId resolves to a ConceptDescription whose symbol is “cm”. Both objects are individually valid. The specification’s precedence rules resolve dictionary conflicts — “if a unit or unitId is supplied that differs from the original property’s data dictionary entry, then the entry in the ConceptDescription takes precedence” — but they do not adjudicate a conflict between unit and the referenced unit concept. Write that check yourself.

The default-unit rules are easy to implement wrongly. Two apply. If only a semanticId is provided for a quantitative property and no ConceptDescription with the IEC 61360 data specification exists, “the primary/default unit according to the respective data dictionary shall be used”. And if the dictionary defines no primary or default unit, “a ConceptDescription shall be supplied that defines unit or unitId”. The second rule is a SHALL that most validators do not implement, because it requires knowing whether the dictionary has a default — which means a dictionary call during validation.

Deletion is an unsolved problem. Once a unit ConceptDescription is referenced by many properties, removing it silently breaks every one of them. ConceptDescription has no reverse-reference index in the metamodel, so reference counting is your job, at repository level, for an object class that previously had no lifecycle at all.

Conformance has no teeth yet. Constraints in this document are prefixed AASc-3b- followed by a three-digit number, and version 3.0 defines none — the change log’s tables are omitted because “this is the first version of the document”. There is no constraint catalogue to test against, which means two conformant implementations can differ substantially in what they reject.

Serialisation guidance is thinner than the preamble promises. The document’s structural overview says the mappings clause covers formats “like XML, AutomationML, OPC UA information models, JSON or RDF”. The normative clause itself does not. It is a single paragraph that names XML, JSON and RDF and then delegates: Part 1 introduces those formats and the implementation guide for embedded data specifications, “This is why the different formats are described in IDTA-01001.” There are no per-format mapping tables for AutomationML or OPC UA information models in Part 3b. If you need an AutomationML or OPC UA representation of the template, you are deriving it from Part 1’s embedded-data-specification rules yourself. The annex’s OPC UA table maps OPC UA as a source dictionary for units — the other direction entirely.

Finally, ecosystem support is the real gate. AAS Units of Measurement is a July 2026 specification on a Release 26-01 baseline, and it will take time to land in AASX Package Explorer, BaSyx, the AAS Web UI and the commercial suites. Adopting early means writing the tooling.

Practical Recommendations

Start by deciding whether you are in UC1 or UC2, and be honest about it. If your consumers only render units for humans, Part 3a already does the job and Part 3b adds objects, validation cost and package size for nothing. The trigger for UC2 is a consumer that must compute with the unit — convert it, compare it across vendors, or reject an incompatible quantity — without a live dictionary connection.

If you are in UC2, treat the AAS Units of Measurement catalogue as a versioned artefact with an owner, not as a byproduct of property import. Pick one dictionary and one version for the whole application. Prefer IEC CDD or ECLASS Advanced if you need quantityID to be machine-resolvable, because ECLASS Basic and UNECE Rec 20 will leave it empty.

Write the normative names into your code once and centrally. DataSpecificationUoM, the template URI ending /DataSpecificationUoM/3, and — defensively — acceptance of both quantityID and quantityId on read.

A pre-migration checklist:

• Confirm your stack is on the Release 26-01 baseline; Part 3b cannot run below it.
• Inventory distinct units across the whole property catalogue and deduplicate before generating any ConceptDescription.
• Fix classificationSystem and classificationSystemVersion to one value each, application-wide, and assert it in CI.
• Make every unitId resolver local-first with dictionary fallback, and ship that before you ship data.
• Add a consistency check between DataSpecificationIec61360/unit and the referenced unit concept’s symbol — the specification does not.
• Add reference counting for unit ConceptDescription objects before anyone can delete one.
• Enforce the character bounds — 256 for StringUoM and each LangStringSetUoM entry, 2048 for DefinitionTypeUoM and IdentifierUoM — at import, not at serialisation.
• If any unit in your domain is not in a public dictionary, decide now: dictionary submission, plain-property convention, or SAMM. Part 3b will not define it.

Frequently Asked Questions

What is the AAS Units of Measurement specification?

It is Part 3b of the Asset Administration Shell specification series, published by IDTA as IDTA-01003-b version 3.0 in July 2026. It defines a data specification template that describes a single unit of measurement using eight attributes — name, symbol, identifier, definition, quantity name, quantity identifier, and the classification system and version it came from. Its purpose is to let a digital twin carry enough information to interpret a unit without calling an external dictionary at runtime.

Does IDTA-01003-b v3.0 replace IEC 61360 in the AAS?

No. It depends on it. The IEC 61360 data specification, Part 3a, is a hard prerequisite: Part 3b cannot be used standalone, because the unit and unitId attributes it redirects are defined in Part 3a. What changes is the target of unitId — from an external dictionary entry to a ConceptDescription carrying the Units of Measurement template. Part 3a’s own attributes and semantics are untouched, which is why the property-level JSON in a migration does not change.

Can I define my own unit with DataSpecificationUnitOfMeasurement?

Not in version 3.0. The specification splits the problem into three use cases and places user-defined units with a complete definition in UC3, which it states is “currently out of scope, but might be addressed in future versions”. Version 3.0 lets you reference and describe a unit that some classification system already defines. If you need to mint genuinely new units, the specification itself points at the Semantic Aspect Meta Model, which provides both a UNECE Rec 20-based catalogue and the means to define new units.

Why do I need quantityID if I already have the unit symbol?

Because a symbol does not identify a quantity. Torque and energy are both expressed in newton-metres but belong to different quantities that cannot be compared or converted into one another. The specification treats this as normative rationale: units and quantities should always be given as a pair. preferredNameQuantity and quantityID carry that pair, must be consistent when both are set, and when a dictionary lists several quantities for one unit, exactly one must be chosen to match the property’s purpose.

What happens to my semanticId when I change a property’s unit?

Changing the unit does not change the property’s semantics, but it does break the addressability of its ConceptDescription. Because a ConceptDescription id must be unique for different content, a concept re-expressed in a different unit needs a new id — so the original dictionary IRDI can no longer serve as the id. The specification says it “can only be transported using the isCaseOf attribute”. Consumers that match semantics on id alone will stop recognising the concept unless they also read isCaseOf.

Which AAS version do I need for AAS Units of Measurement?

The Release 26-01 baseline. The document’s Metamodel Versions block names Part 1 Metamodel version 3.2 and Part 3a version 3.1, while its Normative References clause cites Part 1 as IDTA-01001-3-1 and states the specification is valid only in combination with IDTA-01001-3 and IDTA-01003-a-3. Either way it is not usable on AAS v3.0 stacks. Confirm the exact Part 1 revision your tooling implements before planning a migration, because that upgrade is the larger piece of work.

Further Reading

• AAS Metamodel 3.2 and IDTA Release 26-01 migration guide — the metamodel upgrade that Part 3b depends on, and the prerequisite for any Units of Measurement work.
• AAS vs DTDL vs OPC UA information models compared — where the AAS modelling stack sits against the alternatives, including how each handles units.
• Asset Administration Shell submodels: an Industry 4.0 guide — the submodel and ConceptDescription fundamentals this post assumes.
• Asset Administration Shell with BaSyx: implementation tutorial — building and deploying the ConceptDescription repository that hosts a unit catalogue.
• IDTA-01003-b v3.0, Part 3b: Data Specification — Units of Measurement (PDF) — the primary source for everything above, CC-BY-4.0, DOI 10.62628/idta.01003-b-3.0.
• IEC Common Data Dictionary and the BIPM SI Digital Framework — the two dictionaries with machine-resolvable quantity identifiers.

By Riju — about