ISO 23247-6 Digital Twin Composition: Integrated vs Unified vs Federated

Every plant that buys more than one digital twin eventually hits the same wall. The robot cell twin comes from the cell integrator, the AGV fleet twin comes from the AGV vendor, the press twin comes from the press OEM, and none of them agree on what a “station” is. ISO 23247-6 — published on 14 July 2026 as Edition 1 of Part 6 of the manufacturing digital twin framework — is the first International Standard that treats stitching those twins together as a named architectural problem with three distinct answers rather than an integration chore. It calls them integrated, unified, and federated composition. The distinction is not cosmetic: each one puts the semantic mapping in a different place, gives you a different consistency guarantee, and hands the ownership of failures to a different party.

What this covers: what the three composition kinds mean, how to choose between them on governance and latency rather than on vendor marketing, and how they line up against the Asset Administration Shell, OPC UA, OpenUSD layer composition, and the point-to-point integration you probably have today.

Context and Background

The ISO 23247 series has existed since 2021, and until this summer it stopped short of the interesting part. ISO 23247-1:2021 is a 12-page overview published on 22 October 2021 that sets terms and framework requirements. Part 2 defines the reference architecture built around four domains — the observable manufacturing element, the device communication domain, the digital twin domain, and the user domain. Part 3 covers digital representation of manufacturing elements, and Part 4 covers information exchange. All four are Edition 1, all four are dated 2021, and all four describe one digital twin of one set of observable manufacturing elements.

That is a fine model for a single machine and a poor model for a plant. Real factories accumulate twins the way they accumulate PLCs: one per procurement event, each with its own data model, its own hosting arrangement, and its own commercial terms. Nothing in Parts 1 through 4 told you what to do when twin A and twin B describe overlapping physical reality and disagree.

Two parts landed in 2026 to close that gap. ISO 23247-5:2026, “Digital thread for digital twin,” was published on 24 June 2026 — Edition 1, 26 pages — and specifies how a digital thread creates, connects, manages and maintains manufacturing twins across design, planning, production and testing. Three weeks later, on 14 July 2026, ISO 23247-6:2026 arrived: Edition 1, 31 pages, from ISO/TC 184/SC 4, the same industrial data subcommittee that owns STEP and the rest of the series.

The published abstract for ISO 23247-6 is short and worth reading literally. It says the document specifies digital twin compositions in manufacturing by defining principles, describing methodologies and providing use-case examples of digital twin communication, aggregation and interoperation, and that it identifies three kinds of composition — integrated, unified and federated — with requirements and step-by-step implementation guidelines for each. The committee’s original new-work proposal, still visible on the BSI standards development portal, framed the same scope as “configuration, communication, combination and collaboration between digital twins.”

Those two vocabularies are the tell. Communication, aggregation and interoperation are three escalating degrees of coupling, and they map onto the three composition kinds in the obvious order. Everything below builds from that reading, from the reference architecture in Parts 1 to 4, and from how these patterns already behave in the wild. For the wider standards landscape around this series, including how ISO 23247 and ISO/IEC 30173 divide the terminology work, the companion piece on digital twin standards is the place to start.

What ISO 23247-6 Means by Digital Twin Composition

Digital twin composition is the practice of making two or more independently built digital twins behave as one for some purpose. ISO 23247-6 names three ways to do it: integrated composition merges the twins into a single model under a single owner, unified composition keeps the twins separate but binds them through one shared semantic layer, and federated composition leaves each twin fully autonomous and negotiates a view across governance boundaries.

Figure 1: The three digital twin composition kinds named in ISO 23247-6, drawn by where the authoritative model lives.

The three panels differ in exactly one structural respect: where the single source of truth sits. In integrated composition the source models are consumed and a new authoritative model is produced inside one runtime. In unified composition the source twins keep running where they are and a shared semantic layer resolves identity and meaning across them. In federated composition there is no shared model at all — only a contract, a registry of who holds what, and a view assembled per query.

A note on epistemics before the detail. ISO standards are paywalled; ISO 23247-6 costs Swiss francs to read and its licence explicitly forbids feeding its text to machine learning systems. I have not quoted a single line of normative text here, and nothing below should be read as a clause reference. What is verifiable from the public catalogue record — the three named kinds, the publication date, the page count, the committee, and the abstract’s framing around communication, aggregation and interoperation — is stated as fact. Everything else is engineering inference from the abstract, the committee’s proposal scope, the earlier parts of the series, and how these patterns behave in systems I have actually had to run. I will flag the inference each time it matters. If you are going to build against Part 6, buy the 31 pages; treating a blog post as a conformance reference is how audit findings happen.

Integrated composition: one runtime swallows the others

Integrated composition means the composed twin is a new artifact. You take the robot cell model, the AGV model and the press model, translate all three into one internal representation, and run them inside one engine under one owner. The source twins may continue to exist upstream, but they stop being authoritative for the composed scope. The composed twin is.

This is what most “plant digital twin” products actually sell, and it is the pattern with the cleanest runtime story. There is one clock, one namespace, one transaction boundary. Simulation works, because you can step every element forward together. Optimisation works, because the solver sees one consistent state. Provenance queries work, because every element has one identity.

The cost is ownership. To integrate, you need the right to ingest and re-express each source model — which is a licensing question before it is an engineering one. Vendors who sell a twin as a service rarely grant it. You also inherit an ongoing translation liability: every time a source vendor ships a model update, someone on your side re-runs the import, re-validates, and re-releases. Integrated composition converts a network of interfaces into a single build pipeline, and build pipelines rot.

Unified composition: one meaning, many runtimes

Unified composition keeps the twins where they are and unifies what they mean. Each twin continues to execute in its own runtime, under its own operator, at its own update rate. What is shared is a semantic layer: a common vocabulary, a common identifier scheme for physical things, and agreed units, timestamps and state enumerations. A query against the unified twin is decomposed, dispatched to the constituent twins, and reassembled using that shared layer.

The word “unified” is doing precise work here. It is not “merged” — nothing is copied into a central model. It is not “federated” either, because there is a single agreed semantics that all participants are bound to. My reading of the abstract’s word “aggregation” is that it sits here: aggregation implies a whole assembled from parts that remain parts, which is exactly what unified composition produces.

Unified composition is the right answer more often than teams expect. It preserves each vendor’s ability to update their own twin without a central rebuild. It keeps operational data inside the boundary where it was generated, which matters enormously when the AGV vendor’s contract says telemetry does not leave their tenancy. And it gives you a real, queryable whole — unlike point-to-point integration, which gives you N² conversations and no whole at all.

The cost is the semantic layer itself, and that cost is political rather than technical. Somebody has to decide that a “station” is the thing the MES calls a station, not the thing the cell integrator calls a station. That decision has to survive three vendors, two plants and a reorganisation.

Federated composition: autonomy first, agreement per query

Federated composition drops the assumption of shared semantics. Each participating twin is fully autonomous: its own model, its own governance, its own release cadence, its own legal owner. What exists between them is a contract — what can be asked, what will be answered, at what freshness, under what terms — plus enough of a registry to route a question to the right holder.

This is the pattern for cross-enterprise twins. A tier-one supplier’s process twin and an OEM’s vehicle twin will never share an ontology, because the parties cannot agree on one and would not want to be bound by one if they could. What they can agree on is a narrow, versioned interface: the supplier answers specified questions about specified parts, and nothing else. The composed view exists only for the duration of the query.

Federation buys you autonomy and blast-radius isolation. It costs you consistency. There is no global clock, no cross-twin transaction, and no guarantee that two answers you receive describe the same instant. Every joined answer is stale by an amount you do not control and may not be told.

The pattern nobody names: still doing point-to-point

Worth stating plainly, because it is the incumbent. Most plants today do none of the three. They run direct integrations — a CSV drop here, an OPC UA subscription there, an ETL job into the historian — and call the result a digital twin. That is not composition in the ISO 23247-6 sense, because there is no composed twin: there are pairwise data flows and a dashboard. It is genuinely the right answer for two twins and a fixed question. It stops being the right answer at around four to five participants, where the number of pairwise interfaces passes the number of people willing to maintain them.

Who Owns the Join: Semantic Reconciliation as the Real Cost

Choosing a composition pattern is mostly choosing where to put the mapping and who pays to keep it correct. That decision outlives every other one in the project.

Figure 2: The same reconciliation work, relocated. Each ISO 23247-6 composition kind moves the mapping to a different owner and gives it a different cost curve.

The diagram traces one question — where does the translation between vendor A’s model and vendor B’s model physically live — through the three patterns, and shows what each answer does to effort as the system grows. Integrated composition puts the mapping inside the importing runtime, so effort scales with the number of sources. Unified composition puts it in a shared artifact, so effort scales with the governance cost of that artifact rather than with source count. Federated composition puts it in bilateral contracts, so effort scales with the number of relationships you actually activate.

Schema mismatch is the easy half

Engineers reflexively frame reconciliation as a schema problem: this twin calls it spindle_speed in RPM, that one calls it n_spindle in rad/s, write a converter. That part is tedious and tractable. Units, naming, enumerations, sampling rates and coordinate frames all yield to a mapping table and a test suite.

Identity does not. The hard question is whether vendor A’s Station-07 and vendor B’s ST7 denote the same physical thing, and whether they still do after the line was re-laid out in March. Nothing in a schema tells you that. Someone has to assert it, and someone has to maintain the assertion when the plant changes. This is why composition projects that budget for data engineering and not for master data governance run over.

The Asset Administration Shell community learned this early and encoded it. The IDTA submodel template for hierarchical structures enabling bills of material, built on IEC 81346-1, defines explicit HasPart, IsPartOf and SameAs relationships, and distinguishes self-managed entities that have their own AAS from co-managed entities that do not. SameAs exists precisely because identity across models is an assertion, not a derivation. Any composition layer you build will need its own equivalent, whether or not you call it that.

Temporal identity: the failure nobody tests

A subtler variant bites in brownfield plants. Twin A models the press as a single asset with a serial number. Twin B models the press as a sequence of configurations, because the tooling changes four times a shift. Both are correct for their purpose. Joining them requires deciding what the composed twin considers “the press” to be — and whichever answer you choose, one side’s historical queries now return something its users did not expect.

Integrated composition forces this decision at import time, visibly and once. Unified composition forces it into the shared semantic layer, where it becomes a negotiation. Federated composition lets each side keep its own answer and quietly returns inconsistent joins forever. That is a real argument for integration in scopes where you can afford it: the pain is front-loaded and observable rather than diffuse and deniable.

A rough effort model

Treat this as an order-of-magnitude sketch rather than a benchmark; the numbers are illustrative and come from pattern, not measurement. For a composition of N twins over a stable scope:

• Point-to-point grows roughly with the number of activated pairs, which tends toward N²/2 as questions multiply.
• Integrated grows roughly linearly with N, one importer per source, plus a fixed cost per source-model release you must track.
• Unified grows linearly with N for the adapters, plus a large, mostly fixed governance cost for the shared vocabulary that does not shrink as N falls.
• Federated grows with the number of relationships you actually use, which in cross-enterprise settings is usually far below N²/2 because most pairs never need to talk.

The practical consequence: unified composition is expensive at small N and cheap at large N, because the governance cost is amortised. Teams that pilot unified composition with three twins usually conclude it is not worth it, and they are correct about the pilot and wrong about the plant.

Synchronisation, Latency, and the Consistency You Do Not Get

Composition is a distributed systems problem wearing a manufacturing hat, and the distributed systems results apply unchanged. The moment two twins run in separate failure domains, you cannot have a consistent joined view, current data and availability simultaneously.

Figure 3: A federated read across two twins. The broker can annotate skew; it cannot eliminate it, and it cannot honour a request for a globally consistent cut.

The sequence shows an OEE application asking a federation broker for line state at time T. The broker fans the query out to a robot cell twin and an AGV fleet twin. The cell answers from a 40 ms-old state; the fleet answers from a 900 ms-old state, because its update path runs over a different network and a slower model. The broker returns a joined view with a skew annotation — the honest behaviour — and refuses the follow-up request for a globally consistent cut, because there is no shared clock domain in which such a cut is defined.

Latency budgets differ by an order of magnitude per pattern

Rough envelopes, again illustrative rather than measured, for a joined read across two twins in the same plant:

Pattern	Typical joined-read latency	Consistency you get	Who can break it
Integrated	Single-digit ms — it is a local memory read	Transactional within the composed twin	Only the composed twin’s owner
Unified	Tens to low hundreds of ms — fan-out plus semantic resolution	Per-source freshness, comparable semantics	Any constituent twin’s operator
Federated	Hundreds of ms to seconds — network, auth, contract enforcement	Eventual, per-edge, often unquantified	Any party, unilaterally
Point-to-point	Whatever the slowest hop is	None defined; joins happen in the dashboard	Anyone who edits a job

The integrated row is why simulation and closed-loop control stay integrated. You cannot run a model-predictive controller over a federated read; the freshness is not bounded. Conversely, the federated row is fine for a weekly supplier-quality reconciliation, where seconds of latency are irrelevant and autonomy is the whole point.

For the deterministic end of this spectrum, where the composition question turns into a network question, the site’s OPC UA over TSN reference architecture covers what it actually takes to get a bounded-latency shared clock domain in the first place. Note the dependency: unified composition with tight latency requirements presupposes time synchronisation you have to engineer separately.

Blast radius and failure semantics

Ask a sharper question than “what is the SLA”: ask what happens to the composed twin when one constituent goes dark.

In integrated composition, a source going dark degrades an input, not the twin. The composed model keeps running on its last state and probably keeps simulating, which is good for availability and dangerous for correctness — an integrated twin will happily present a confident, stale answer with no visible seam. You must build the staleness indicator yourself, because nothing in the architecture forces one.

In unified composition, a constituent going dark produces a partial answer. The shared semantic layer knows a participant is missing, so it can say so. That is architecturally better: the seam is visible by construction. The corresponding hazard is that every application must handle partial results, and most applications written by people expecting a database do not.

In federated composition, a participant going dark is a normal, expected condition. Contracts usually specify it. The failure mode is subtler: the composed view silently narrows, and consumers who do not check which participants responded draw conclusions from a biased subset. A plant-wide energy roll-up that quietly omits the two highest-consuming lines is worse than no roll-up.

Versioning is a synchronisation problem too

Model versions drift as surely as data does. When the press OEM ships a new twin release with a changed state machine, integrated composition holds you at the old version until you re-import, which is safe and slow. Unified composition requires the shared semantic layer to express both versions until every consumer migrates, which is the hardest engineering in the pattern. Federated composition lets each side move independently and pushes version negotiation into the contract, which works exactly as well as your contract versioning discipline does.

How the Three Patterns Map to Stacks You Already Run

ISO 23247-6 is technology-neutral, in keeping with the rest of the series. That neutrality is useful for standardisation and unhelpful when you need to pick a product this quarter. Here is how the three kinds land on four things practitioners actually deploy.

Asset Administration Shell

The AAS is the closest existing thing to a unified composition substrate. Its metamodel — standardised as IEC 63278-1:2023 for the structure, with the IDTA specifications carrying the working detail — gives you a shell per asset, submodels as the unit of meaning, and semantic identifiers that let two parties agree a property means the same thing without merging their systems. Submodel templates are shared vocabulary in the literal sense.

Where AAS is weakest for composition is exactly where unified composition is hardest: the identity join across shells owned by different parties. The hierarchical-structures submodel provides the relationship vocabulary, but somebody still has to populate it and keep it true. If you are evaluating this route, the AAS metamodel 3.2 migration notes cover what changed recently and what it costs to move.

AAS can also serve federated composition, using registries and discovery to locate shells across organisational boundaries while each party retains control. What it is not good at is integrated composition — nothing in the AAS is designed to be flattened into one runtime model, and teams that try end up writing an importer and abandoning the metamodel.

OPC UA information models

OPC UA has a composition story that predates this standard by a decade, and it is instructive because it is honest about namespaces. Each information model lives in a namespace identified by a globally unique NamespaceUri, while the NamespaceIndex used in node identifiers is only unique within a client–server session. That indirection is what lets information from many sources combine into one address space without identifier collisions, as the OPC UA modelling best practices describe.

An OPC UA aggregating server is a working example of unified composition at the protocol layer: it presents many underlying servers as one address space, preserving each source’s namespace. It also exposes the pattern’s characteristic difficulty. When two underlying servers expose the same static type model namespace, the aggregator has to merge them rather than keep them side by side — and nodes that vary per instance must be marked non-static in the namespace metadata or the aggregation is wrong. That is semantic reconciliation, surfacing as a configuration flag. Every unified composition has an equivalent flag somewhere, and it is always under-documented.

OpenUSD scene composition

OpenUSD deserves a place in this comparison because it is the one widely deployed system that treats composition as a first-class, formally specified operation rather than an integration technique — and because the contrast is genuinely illuminating.

USD composes a scene from layers using composition arcs, with a canonical strength ordering historically abbreviated LIVRPS — local, inherits, variantSets, references, payloads, specializes — and more recently LIVERPS after the addition of the relocates arc. Conflicting opinions from different layers are resolved deterministically by that ordering. Payloads give deferred loading of heavy data; references are always composed. Encapsulation guarantees that a referenced asset’s internal structure cannot be rewritten by a stronger layer, only overridden in value. NVIDIA’s OpenUSD composition arc documentation is the clearest public explanation of the mechanics.

Compare that to what ISO 23247-6 describes, and one difference dominates. USD composition is a deterministic function over static declarative data. Given the same layers, you get the same stage, every time, with conflicts resolved by a rule everyone can read. Digital twin composition is a runtime relationship between live, stateful, independently governed systems. There is no strength ordering that resolves “the cell twin says the gripper is closed and the vision twin says it is open,” because both are reporting measurements, not opinions about a scene.

That is the useful takeaway, and it is why teams porting a USD mental model onto plant twins get hurt. USD gives you composition of description; ISO 23247-6 is concerned with composition of behaviour and state. You can and should use USD composition for the geometric and configuration layer of a composed twin — that is what it is excellent at — while handling live state through one of the three ISO patterns. The site’s OpenUSD core spec 1.1 breakdown covers where the CAD-to-twin boundary sits in practice.

Plain point-to-point

The incumbent deserves a fair hearing. Point-to-point integration has no governance overhead, no shared artifact to negotiate, and no framework to learn. For two twins and one question it is unbeatable, and treating it as technical debt on principle is a mistake.

It fails on evolution, not on function. Each pairwise integration encodes an assumption about both endpoints, invisibly. When one endpoint changes, you discover the assumptions by watching things break. The composed-twin patterns all exist to make those assumptions explicit and reviewable in one place — which is worth paying for exactly when the number of assumptions exceeds what one person can hold in their head.

Trade-offs, Gotchas, and What Goes Wrong

Figure 4: A decision path through the ISO 23247-6 composition kinds, driven by model ownership, scope stability, vocabulary agreement and tolerance for stale answers.

The tree starts from model ownership because that constraint is usually immovable, then filters on scope stability, then on whether the parties can agree a vocabulary at all, and finally on whether a stale or partial answer is acceptable. If the answer to that last question is no and federation was the only option left, the honest outcome is not “federate anyway” — it is to narrow the scope until one of the stronger patterns becomes feasible.

Composition kind chosen by vendor, not by requirement. The most common failure. A platform vendor’s architecture determines the pattern because their product only implements one, and the requirements get reverse-engineered to match. Decide the pattern from the ownership and latency constraints first, then shortlist products that implement it.

Unified composition without a funded vocabulary owner. A shared semantic layer with no named owner and no budget becomes a stale mapping file within two quarters. The role is a standing one, not a project task. If nobody will fund it, you are building federated composition with extra steps.

Federated composition sold as unified. Watch for products that offer a “single pane of glass” over autonomous twins with no shared identity scheme. The pane is federated underneath, with the join done visually by the operator. That is fine if everyone knows it; it is dangerous when an analytics layer is built on top and starts treating the visual join as a data join.

Assuming ISO 23247-6 conformance means interoperability. It does not. Part 6 provides requirements and implementation guidelines for each composition kind; it does not define a wire protocol. Two conformant implementations of federated composition can be mutually unintelligible. Ask vendors which information exchange mechanism they use — Part 4 territory, or AAS, or OPC UA — not just whether they follow Part 6.

Silent staleness in integrated composition. An integrated twin presents one coherent state with no seams, which means a dead input looks identical to a healthy one unless you instrument it. Make per-source freshness a first-class, visible attribute of every composed element from day one; retrofitting it after a bad decision is a much worse conversation.

Confusing composition with the digital thread. Part 5 and Part 6 solve different problems. The digital thread connects a twin’s information across lifecycle stages — design to planning to production to test. Composition connects different twins at the same moment. Teams routinely buy a thread product expecting composition, or vice versa.

Practical Recommendations

Start by writing down, for each twin you intend to compose, three facts: who legally owns the model, what the freshest guaranteed update interval is, and whether you have the right to re-express it in another system. Those three answers usually collapse the decision to one viable pattern before any architecture discussion begins.

Then scope the join narrowly. Composition projects fail on ambition, not on technology. A composed twin that answers four specific cross-twin questions is achievable in a quarter; a composed twin that “represents the plant” is not achievable at all. Pick the questions, derive the minimum shared semantics those questions need, and refuse to model anything else until they work.

Budget the semantic layer as a product with an owner, not as a migration. If you choose unified composition, name the person, give them a release cadence, and put version-compatibility rules in writing before the second twin connects.

The working checklist:

• Record ownership, update interval and re-expression rights per constituent twin before choosing a pattern.
• Pick the composition kind from those constraints, then shortlist products — never the reverse.
• Define the four to six cross-twin questions the composition must answer, and nothing more.
• Make per-source freshness and per-source availability visible attributes of every composed element.
• Require applications to handle partial results explicitly; fail loudly on a missing participant rather than returning a narrowed view.
• Name a funded owner for the shared vocabulary if you are going unified, with a documented versioning policy.
• Ask vendors for their information-exchange mechanism, not just their ISO 23247-6 conformance claim.
• Keep USD or equivalent scene composition for geometry and configuration; do not route live state through it.
• Buy the standard before you build against it — 31 pages is cheaper than one wrong architecture.

Frequently Asked Questions

What is ISO 23247-6 and when was it published?

ISO 23247-6:2026 is Part 6 of the ISO 23247 digital twin framework for manufacturing, titled “Digital twin composition.” It was published on 14 July 2026 as Edition 1, runs to 31 pages, and comes from ISO/TC 184/SC 4. It specifies principles, methodologies and use cases for digital twin communication, aggregation and interoperation, and identifies three kinds of composition — integrated, unified and federated — with requirements and implementation guidance for each. It is a paid International Standard, not a free specification.

What is the difference between unified and federated digital twin composition?

Unified composition keeps each twin running in its own runtime but binds them through one agreed semantic layer, so a query can be decomposed and reassembled with confidence that terms and identities match. Federated composition drops that shared semantics: each twin stays fully autonomous under its own governance, and interaction happens through a negotiated contract per relationship. Unified gives you a coherent whole at the cost of governing a shared vocabulary. Federated gives you autonomy at the cost of consistency.

Does ISO 23247-6 replace the Asset Administration Shell or OPC UA?

No. ISO 23247-6 is technology-neutral and describes composition patterns rather than protocols or metamodels. The Asset Administration Shell and OPC UA are concrete mechanisms you would use to implement one of those patterns — AAS fits unified and federated composition well, and an OPC UA aggregating server is a working instance of unified composition at the address-space layer. Conformance to Part 6 does not by itself make two implementations interoperable.

How does ISO 23247-6 relate to ISO 23247-5?

They solve orthogonal problems and are easily confused. ISO 23247-5:2026, published 24 June 2026, specifies the digital thread: how a twin’s information is created, connected, managed and maintained across the product life cycle, from design through planning, production and testing. ISO 23247-6 addresses composition: how multiple twins that exist at the same time are made to work as one. A thread is longitudinal across time and lifecycle stages; a composition is lateral across systems at one moment.

Is OpenUSD composition the same idea as digital twin composition?

They share a word and not much else. OpenUSD composition is a deterministic function over static declarative layers, with conflicts resolved by a published strength ordering — LIVRPS, now LIVERPS with the relocates arc. Digital twin composition under ISO 23247-6 joins live, stateful, independently governed systems where conflicting measurements cannot be resolved by a precedence rule. Use USD for the geometry and configuration layer of a composed twin, and one of the three ISO patterns for live state.

Which composition pattern should a single plant with three vendor twins choose?

Usually integrated, if the licensing permits it, because at three twins the governance cost of a shared vocabulary is not yet amortised and a single runtime gives you clean simulation and transactional consistency. Check first whether you have the right to re-express each vendor model — that is the binding constraint far more often than the engineering. If one vendor refuses, unified composition scoped to a handful of specific cross-twin questions is the next-best answer.

Further Reading

• Digital twin standards compared: ISO 23247, ISO/IEC 30173 and the DTC framework — how the terminology and framework standards divide the territory.
• AAS metamodel 3.2 and the IDTA 26-01 release: what changed and what it costs to migrate — the substrate most unified compositions end up standing on.
• OpenUSD core spec 1.1 and the CAD-to-digital-twin decisions it forces — where scene composition belongs in a twin architecture.
• OPC UA over TSN: a deterministic IIoT reference architecture — what a shared clock domain actually requires.
• ISO 23247-6:2026 catalogue entry — the primary source, abstract and scope.
• OPC UA modelling best practices — namespaces, aggregation and the identity problems they expose.

By Riju — about