/ THE SHORT ANSWER
- 01Distinguish a product type from an installed asset instance.
- 02Use published submodels with an explicit version choice.
- 03Validate a cross-team service task before expanding scope.
/ dotSuper point of view
dotSuper analysis: interoperability starts with shared meaning and maintained ownership, not a larger digital twin interface.
Choose a service problem that identity can solve
If those identifiers are not connected, a digital twin may simply reproduce the same confusion in another interface.
IDTA's 2022 announcement describes a standardised digital nameplate submodel within the Asset Administration Shell.
[1] That provides a concrete industrial reference.
It does not mean every existing machine already has the required information or that a nameplate alone constitutes a complete digital twin.
Pick a task such as locating the correct maintenance document or identifying a replacement component.
State which identifiers the user starts with and what evidence they should reach.
This gives the project a practical success condition before the team debates dashboards, simulation or broad platform architecture.
Separate product type from installed instance
An installed machine may have a particular serial number, retrofit, configuration and service history.
Keep those relationships explicit so shared product information does not overwrite details that belong to one physical asset.
Assign an owner for each field.
The manufacturer may control the original product description, while the operator maintains installation location and local asset identifiers.
Agree how corrections are exchanged when both parties discover different versions of the same information.
Do not place unstable operational information directly into an identifier.
Locations, departments and commercial ownership can change.
A durable identifier should continue to resolve to the asset while the surrounding record explains its current state and history.
This is an implementation recommendation, not a claim that one identifier scheme fits every industrial environment.
Select a bounded submodel and version
[2] Use that catalogue to select the relevant artefact deliberately.
A historical announcement is not a substitute for the chosen implementation specification.
Document the version and required fields in the project brief.
Include how absent information is represented and which fields are optional for the first task.
Avoid filling gaps with guesses merely to make a record look complete.
Keep the first scope small enough to reconcile manually.
If the team cannot explain ten representative assets, a bulk migration will scale unresolved ambiguity along with the data.
| Check | Evidence | Owner |
|---|---|---|
| Physical identity | Readable identifier on the asset | Plant engineering |
| System mapping | Supplier and internal IDs linked | Asset data owner |
| Instance distinction | Serial and configuration relationship | Engineering |
| Document applicability | Approved revision links | Documentation owner |
| Version choice | Selected submodel specification | Integration lead |
| Correction route | Named change process | Supplier and operator |
A hypothetical Swabian pump assembly handover
The original documentation identifies the product family, but service staff need to distinguish two installed options that use different maintenance documents.
The handover maps each physical serial number to the customer's asset identifier and applicable document set.
A technician starting from the physical label can find the correct record, see the configuration and open the approved document revision.
During the exercise, one assembly has a replacement component recorded only in a service note.
The project exposes the missing relationship before a digital interface makes it look authoritative.
The owner resolves the record and defines how future replacements will update it.
No simulated performance model is needed to make that first outcome useful.
Avoid turning a QR code into an unowned promise
Ask who maintains the destination, what happens when a supplier platform changes and whether the record remains accessible to the intended users.
A broken link can make an apparently modern handover less useful than a well-maintained document register.
Separate public information from restricted service material.
The physical code may be visible to many people, while detailed configuration or customer records require access controls.
Design the landing experience so it explains available information without exposing content beyond the user's permission.
There are tradeoffs in hosting and integration.
A shared service may simplify distribution but create dependency on its availability.
Internal hosting may increase control while adding maintenance work.
Choose based on the task, ownership and continuity needs, rather than assuming that one architecture automatically delivers interoperability.
Prove the handover across organisational boundaries
They should identify the asset, confirm applicability and reach the relevant information without relying on an undocumented explanation from the integration team.
Include a changed configuration and an obsolete document in the acceptance exercise.
The system should distinguish history from current applicability and show where uncertainty remains.
Measure unresolved identity or document questions, because those are the issues the first implementation is intended to reduce.
Expand into live data only after the identity relationships are dependable.
The asset record can then anchor maintenance events, measurements and later AI retrieval.
Starting with a maintained nameplate and a successful handover gives the broader digital twin programme a useful foundation that people can understand and operate.
What this page cannot conclude
- 01The 2022 IDTA announcement provides historical context; current implementation requires selecting the applicable published specification and version.
- 02No interoperability test, product certification or digital product passport compliance assessment was performed.
- 03This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Sources
- 01Standardized Digital Nameplate, 16 November 2022Industrial Digital Twin Association (IDTA) · accessed Sep 15, 2026
- 02Asset Administration Shell specifications and submodel downloadsIndustrial Digital Twin Association (IDTA) · accessed Sep 15, 2026
This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Our editorial standard · Found an error? Send a correction with its source.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (September 15, 2026). Start Digital Twins With Reliable Asset Identity. dotSuper. https://dotsuper.net/feeds/applied-systems/germany-digital-nameplate-asset-identity