Asset identity
Keep Asset history, views and dashboards through a move
Use a stable Asset identity and verified Attribute bindings to read history across locations. Reopen the same saved view, dashboard cell or identity-aware Catalog offer after a move.
Worked example
Example: a movable roll cassette
A cassette moves between a rolling stand, storage and a workshop. Its upper and lower rolls are subassets with their own identities and parameters, such as temperature, speed, vibration, wear and operating time.
A location-based topic may change while the physical equipment remains the same.
History follows verified intervals, not a guess based on equal names.
Physical nesting does not automatically approve every child’s source or movement.
Procedure
Follow the task in order
- 1Prepare the example structure and servicesUse the Hot rolling example — start profile from the material guide and the published Podman configuration for the installed demo. Start the compatible Archiver/API, then the demo. In Hot rolling demo → Setup and data journey review its root preparation. Let the first telemetry create the normal UNS branches before attaching identifiers. Existing ordinary MQTT measurements are not yet verified identity history.
- 2Approve the declared identifier sourceAs administrator open Asset identity → External identifiers → Approve source. Review provider demo.mes, external system novasteel.mes and type equipment.code from the installed demo configuration. Enter a meaningful review note and approve this namespace only for the fictional example. This is not permission to claim arbitrary Assets and does not attach any identifier.
- 3Attach each concrete identifier in Asset detailsIn Unified namespace open the relevant Asset’s node menu → Details → External identifiers → Attach reviewed identifier. Select the approved source, enter its exact external ID and a review note, then attach it to that current Asset. Repeat independently for the furnace, cassette and both roll subassets using the mapping below. Inspect the Asset path before each confirmation. Never attach all IDs to the parent station or infer them from matching names.Published demo identifier mapping
demo.mes / novasteel.mes / equipment.code RESS-14 forge-group/novasteel/hot-rolling/hrm-pusher-furnace CASSETTE-001 forge-group/novasteel/hot-rolling/hrm-stand-1/roll-cassette-001 WORK-ROLL-UPPER-001 forge-group/novasteel/hot-rolling/hrm-stand-1/roll-cassette-001/upper-work-roll-001 WORK-ROLL-LOWER-001 forge-group/novasteel/hot-rolling/hrm-stand-1/roll-cassette-001/lower-work-roll-001 - 4Enable reviewed transitions on the correct controllerFor a standalone installation open Asset identity → Continuity → Local controller configuration. This opens the existing local configuration editor, not shared Cluster configuration. Set entityIdentity.mqttTransitionsEnabled to true, Save and close. In Controller Management use Restart controller; keep microservices running. For a cluster use the established shared-profile review and protocol readiness instead. The switch does not approve sources, identifiers or conflicting claims.Existing local configuration property
"entityIdentity": { "mqttTransitionsEnabled": true } - 5Wait for confirmed bindings before collecting the demonstrationReturn to Hot rolling demo and use Check bindings. Require confirmed history binding for the cassette and each roll (3/3), then allow new measurements to archive. A first observation before binding can remain unattributed. If it stays 0/3, inspect the exact individual identifier associations, publisher identity:asset:publish permission for the configured demo branch, publication readiness and rollout diagnostics. Do not keep moving while the preparation is unresolved. After reviewing a source or attaching IDs, stop and start only the same demo instance once to refresh its cached signed proof; preserve its journal. This avoids waiting for the cached proof expiry. Refresh Check bindings afterwards.
- 6Open Asset history normallyIn Unified namespace open the Asset menu and choose Asset history, or open its Details and use the top Asset history action. In table mode the Asset breadcrumb opens identity history. Explore attribute on a leaf instead reads that concrete topic.
- 7Select a signal and a real historical rangeChoose the relative Attribute, From, To and Detail, then Load history. The default is recent history; an inactive demo may require an older range. Review the returned rows and Verified history sources, which show the authorized location intervals.
- 8Save an identity-based viewUse Save or Save as in Asset history. This stores the Asset identity and relative signal selection. An older topic-only Explore view remains tied to its path; it is not silently converted. After a new accepted move, reopen the saved Asset view and confirm its sources and time range.
- 9Reuse it on a dashboardCreate or edit a dashboard and add the saved Asset view through its cell picker. The identity-aware cell resolves verified current and historical bindings again on load. A missing view, revoked binding or denied historical interval is an error to inspect, not permission to use a former topic as a fallback.
- 10Inspect an identity-aware Catalog offerOpen Data Catalog and select an offer explicitly registered with a valid Asset reference. Its Asset data card can show the current source and last observation. History across moves opens the same stable Asset and relative Attribute. Arbitrary business API operations remain the contracts declared by the publisher; they are not automatically rewritten on a move.
- 11Validate a move and its subassetsLet the approved producer publish and the normal identity workflow verify and accept the new bindings. Then reopen the same view, dashboard and offer. Verify current path, old and new intervals and signal values for the cassette and each roll independently. The demo blocks physical cassette movement while the stand is occupied.
Expected result
What you should have
Boundaries
Important boundaries
- These preparation controls/profiles require Controller 2.2.31 or newer; they are not included in Runtime 2.2.30. Provider approval and each concrete association remain separate explicit operator decisions.
- Current-path access does not grant earlier-location access. Historical reads still enforce the permissions of the verified intervals.
- Names, topic suffixes and parent nesting are not evidence of identity. Missing, ambiguous or revoked bindings remain explicit failures.
- This is verified-interval history, not automatic identity approval or lossless attribution before a binding exists. Demo movements illustrate the mechanism; they are not a physical tracking system.
- The mobile demo does not rewrite earlier misdated measurements. A first packet received before a topic binding is confirmed cannot be claimed as transport-verified. Legacy path provisioning may expose a separately labelled interval with an unknown historical start; that evidence is retained, not retroactively promoted to a signed observation. New authenticated intervals begin at receipt time, and later samples are not backdated. Compare raw source rows with the recorded intervals rather than assuming every packet has the same evidence quality.
- Verified-interval history requires Controller 2.2.13 or newer. Demo 6.1.26 uses observation time for mobile telemetry; the optional preparation profiles and standalone entrypoint described here additionally require Controller 2.2.31 or newer.
- Controller source releases and Runtime image/artifact publication are separate. Before starting, verify that the Runtime you download actually contains Controller 2.2.31 or newer; a component release alone does not establish that availability.
This versioned public guide is maintained with the UNS OpenHub website and linked directly from the controller where the task applies.