Canvas 9 — Reference Architecture for Physical-AI Platforms in Heavy Industry

Nov 11, 2026

How to use this canvas

This canvas puts canvases 1–8 together into one generic reference architecture for physical-AI platforms in heavy industry (construction, mining and earth-moving autonomy). It names the layers, the interfaces between them and the decisions a platform has to make. It is canvas 9 of 9. It follows a research-area exploration framework with all enhancement modules: Emerging (11–12), Applied (13) and Interdisciplinary (14).

1. Core definition and scope

Definition. A physical-AI reference architecture for heavy industry is a reusable blueprint of components, interfaces and rules. It covers how data from machines becomes trained, validated models that run safely on those machines, and how the loop repeats. It is meant to hold across many product lines, sites and model types.

The organizing idea is NVIDIA's three-computer model: a training computer (DGX), a simulation computer (Omniverse and Cosmos on RTX PRO servers) and a runtime computer (Jetson AGX Thor) (NVIDIA). For heavy equipment, three more layers sit around those computers: the machine fleet and its connectivity, a shared data and control plane, and an assurance and feedback layer.

Logs flow up from machines through the site to the AI factory; signed models flow back down. On the machine, every learned action passes a runtime monitor, and the certified safety controller always has the final say.

Boundaries. Covered: layers, interfaces, cross-cutting concerns (identity, security, lineage, safety) and the platform decisions that bind canvases 1–8. Not covered: the internal design of each layer, which the earlier canvases address. Machine control systems certified under functional safety standards are treated as a fixed boundary that AI must respect, not redesign. Physical cluster and network wiring design is discussed only at the level of workload requirements.

Key sub-domains

1. Layering and decomposition. Edge, site, cloud and AI factory; planes for data, compute, control, assurance and feedback.

2. Interface contracts. Dataset manifest, run manifest, model package, engine contract, telemetry schema.

3. Deployment topology. On-prem GPU clusters, GPU cloud capacity, and embedded edge computers on machines; what runs where and why.

4. Cross-cutting concerns. Identity and access, supply-chain security, lineage, safety architecture, cost.

5. Safety architecture. How learned components sit inside a certified envelope with a runtime monitor and a fallback controller.

6. Platform governance. Architecture decision records, standards, reuse across product lines.

Central debate. One shared platform for all physical AI in a heavy-equipment organization, or federated stacks per product line with shared standards? A single platform gives reuse and one lineage; federation moves faster where mining, construction and on-road logistics differ in timing, safety and data. Public evidence shows both shapes: OEM-integrated autonomy stacks (for example Komatsu's FrontRunner) and OEM-agnostic retrofit kits (for example Bedrock Robotics and Teleo, described in section 4).

2. Historical context and evolution

The history runs from hand-built autonomy for one machine type to shared AI platforms that serve many machine types. The industry moved from rules-based autonomy stacks toward learned models trained in AI factories.

Scale today. Komatsu reports more than 11.5 billion metric tonnes moved by customers using FrontRunner since commercial introduction (Mining Weekly, Apr 2026; company-reported figure). Fortescue reported 193 autonomous trucks across its Pilbara operations in July 2021 (Engineering News), and a 2026 trade report describes BHP's Escondida Norte pit as fully autonomous, with 33 autonomous trucks (Sustainability Magazine).

Paradigm shifts

• From per-product autonomy to a shared platform. One edge computer family and one AI factory can serve haul trucks, dozers, excavators and in-cab assistants.

• From hand-coded perception to learned models. Foundation and VLA models need a data flywheel, simulation and assurance that rules-based stacks did not.

• From release-and-forget to continuous loops. Models are retrained from fleet data and updated over the air, so the architecture is a loop, not a pipeline.

3. Current state of research

The field has vendor reference designs and industrial layering standards, but no agreed reference architecture for learned autonomy on heavy equipment. This canvas is a synthesis attempt, not a settled standard.

Dominant frameworks

• Three-computer model (NVIDIA). Train on DGX, simulate on Omniverse/Cosmos, run on Jetson Thor, as a continuous loop. NVIDIA names Agility, Amazon Robotics, Figure and Skild AI as adopters (Pipeline).

• NVIDIA blueprints. Mega for multi-robot fleets in facility twins, which connects to fleet managers through the open VDA 5050 interface (NVIDIA Developer); Physical AI Data Factory for data curation and augmentation; Omniverse DSX for AI factory digital twins.

• Industrial layering. ISA-95 and RAMI 4.0 for enterprise-to-device layers; ISO 23247 for manufacturing digital twins; IEC 62443 zones and conduits for security.

• Off-highway standards. ISO 17757 for autonomous earth-moving and mining machine safety; ISO 15143-3 for mixed-fleet telematics data exchange.

• Safety architectures for learned components. Simplex and runtime-assurance patterns: a learned controller monitored by a verified checker that can switch to a certified fallback.

Key research questions

1. Which functions belong on the machine, at the site edge or in the cloud, given latency, connectivity and safety needs?

2. How should learned policies be bounded so certified safety functions stay valid under the EU Machinery Regulation?

3. What contracts between layers let teams evolve independently (data, model, engine, telemetry)?

4. How far can one foundation model serve many machine types, and what stays machine-specific?

5. How do you keep a platform portable across GPU vendors and clouds while using a vendor stack deeply?

Main approaches: reference-architecture design from domain analysis, architecture trade-off analysis, digital-twin-based validation, and field deployments that harden into platforms.

Challenges

• Heavy equipment runs at remote sites with poor connectivity and harsh conditions. Machine lifetimes are long (often cited as 10–20+ years; estimate), longer than any GPU generation.

• Mixed fleets: machines from several brands work side by side, so site systems must interoperate. Hitachi, for example, describes a multi-vendor "Solution Linkage" initiative for connecting equipment to existing fleet management (Hitachi Construction Machinery).

• Safety certification lags learned methods; no off-road AI safety standard exists yet (canvas 4).

Debates

• Modular vs end-to-end. Separate perception, planning and control modules are easier to certify; end-to-end VLA models generalize better but are harder to bound.

• Platform lock-in. Deep vendor integration speeds delivery; open standards (OpenUSD, ONNX, OTel, Kubernetes) keep exit options.

• Integrated vs retrofit autonomy. OEM-integrated stacks can use machine-internal signals and certified controllers; retrofit kits reach existing mixed fleets but must work through the machine's existing interfaces.

4. Key stakeholders and research centers

A reference architecture has to satisfy four groups at once: equipment makers and autonomy developers, platform vendors, the operators and dealers who run machines, and the regulators and standards bodies who approve them.

Inside heavy-equipment OEMs and autonomy developers (public evidence)

Internal owners as generic roles. In any organization that builds this stack, the architecture needs owners for the same functions: data platform, simulation, training, assurance and functional safety, ML platform and release, infrastructure, observability, and product security. The six interface contracts in section 14 assign each artifact to one such role.

Partners and ecosystem

• Platform vendors. NVIDIA stack as above; GPU cloud providers for burst training capacity (canvas 6).

• Simulation and twins. Omniverse and Isaac Sim for scenes and sensors, AGX Dynamics as a physics engine for earth-moving and terramechanics (canvas 2).

• Academia. Carnegie Mellon (DARPA-era autonomy architectures), ETH Zurich Robotic Systems Lab (autonomous excavators, Marco Hutter), UIUC (Simplex runtime-assurance architecture, Lui Sha).

Standards and regulators

• ISO/TC 127 (earth-moving machinery) and ISO/TC 82 (mining), owners of ISO 17757 and ISO 15143.

• Alliance for OpenUSD (scene and asset interchange), CNCF (cloud-native standards), VDA (VDA 5050 fleet interface).

• EU Commission (Machinery Regulation 2023/1230, AI Act as amended by Regulation 2026/1744), US OSHA and MSHA.

Tension to manage. Product lines want speed and autonomy; the platform wants shared contracts. A good reference architecture sets a few hard standards and leaves the rest to each line.

5. Methodological landscape

Reference architectures are built with a small set of proven methods: describe, decide, evaluate, then check continuously that the built system still matches the design.

Primary methods

Data collection for architecture work: stakeholder interviews per product line, inventories of existing fleet-management and telematics systems, latency and bandwidth measurements at real sites, incident and near-miss records, and cost data from canvas 8.

Analysis techniques: trade-off matrices, dependency and coupling analysis, latency budgets across the edge–cloud chain, failure-mode analysis (FMEA) per interface, and total-cost models for on-prem vs cloud GPU.

6. Interdisciplinary connections

Much of the work in a reference architecture is translation between disciplines that use different words for the same thing.

Collaboration opportunity. Mining autonomy has more than a decade of operating history (section 2) and therefore a working safety and operations model. Construction autonomy can reuse that model instead of inventing a new one, adapting it to less structured, more dynamic sites. This is an inference from the public record, not a documented practice.

7. Future directions

The architecture is likely to move from "one model per machine function" toward shared foundation models with machine-specific adapters, updated through a continuous loop. This is a forward-looking judgment, not an established result.

Emerging trends

• Cross-embodiment foundation policies. One model family adapted to trucks, dozers and excavators (canvas 3).

• World models in the loop. Cosmos-style models used for data augmentation, evaluation filtering and scenario generation (canvases 2 and 4).

• Site-level orchestration. Fleet managers coordinating mixed autonomous and manned machines through open interfaces, as Mega does with VDA 5050 in warehouses.

• Agentic operations. Assistants that act across fleet and maintenance applications, and AIOps agents that run the AI factory (canvas 8).

• AI factory digital twins. Designing power, cooling and compute in simulation before building (Omniverse DSX).

Research gaps in heavy-industry physical AI

1. No public reference architecture for learned autonomy on heavy equipment (this canvas is a synthesis, not a validated design).

2. No agreed interface standard between learned policies and certified safety controllers.

3. Few studies of architecture decay when foundation models are updated frequently but machines live 15 years or more.

4. Little published guidance on splitting compute between machine, site edge and cloud for construction sites.

5. Little independent field data on retrofit autonomy; most performance claims in the public record come from vendors.

Potential breakthroughs

• A standard safety-envelope interface that lets any certified controller bound any learned policy.

• Machine-agnostic model packages: one signed package format that many machine runtimes accept.

• Closed-loop certification evidence: field telemetry that updates the safety case automatically.

8. Resources and infrastructure

The stack below is a default set drawn from canvases 1–8. Open standards are listed so each layer has an exit path.

Standards to track: ISO 17757, ISO 15143, ISO 13849, IEC 62443, ISO/IEC 42001, ISO/IEC/IEEE 42010, ISO 23247, EU Machinery Regulation 2023/1230 and its AI delegated acts.

Venues: NVIDIA GTC, CES, ICRA, IROS, RSS, CoRL, ISARC (automation in construction), SAE COMVEC (commercial vehicles), MINExpo, bauma, IEEE Software Architecture (ICSA).

Funding: corporate R&D; venture capital for autonomy start-ups (see Bedrock Robotics and Teleo above); university partnerships; public programs on construction and mining automation such as US DOE and NSF programs and EU Horizon Europe on autonomous machinery.

9. Literature analysis

The literature for this canvas sits in three places: software architecture methods, safety architectures for autonomy, and the recent physical-AI and foundation-model work summarized in canvases 1–8.

Seminal works

Recent influential works

Gap. No peer-reviewed reference architecture for learned autonomy in construction and mining was found in this review. Public descriptions come from vendor and trade press; a paper describing layers and contracts, even at a high level, would fill the gap.

10. Practical applications

One architecture has to carry very different workloads, from a voice assistant to a 200-tonne autonomous truck. The table shows how each field-level application stresses the layers differently. Safety tiers are this canvas's own classification.

What the table shows

• Safety tier drives architecture. Safety-critical functions need the full path: canvas 4 gates, signed OTA, runtime monitors and a certified fallback. Assistive and non-safety functions can ship faster on a lighter track.

• The machine computer is shared. One embedded SoC can run the assistant, perception and autonomy side by side, so isolation and scheduling on that SoC (canvas 7) become an architecture concern.

• Data flows one way into one lake. Every application should log into the same data plane with the same lineage, or the flywheel splits into silos.

Industry parallels: NVIDIA's partners (Agility, Amazon Robotics, Figure, Skild AI) use the same three-computer pattern; KION and Accenture use Mega to test warehouse robot fleets in twins before deployment (NVIDIA).

11–12. Technology integration, ethics and regulation

Technology integration

• Identity everywhere. Every machine, model, dataset and engine gets a stable ID used in lineage, telemetry, OTA and cost. This is the one standard all canvases must share.

• Edge–cloud split. Control loops and safety monitors stay on the machine. Fleet coordination stays at the site edge so it survives outages. Training, simulation, evaluation and fleet analytics run in the AI factory.

• Compute. On-prem GPU clusters for steady training and sensitive data; GPU cloud for bursts; RTX PRO servers for simulation; an embedded edge computer on every AI-enabled machine. Requirements are stated per workload (canvas 6); physical cluster and network design is outside this canvas.

• Data. One lakehouse with dataset manifests and lineage; store-and-forward from machines with priority tiers.

• Security. IEC 62443 zones for machine, site, cloud and factory; secure boot and signed models on the machine; AIBOMs for every release.

Ethical considerations

• Workforce. Autonomy changes operator jobs. Supervised-autonomy designs, in which one remote operator oversees several machines, show one alternative to removing operators (The Robot Report). The architecture should support remote supervision and new roles, not only removal of operators.

• Shared sites. Autonomous machines work near people and other brands' machines. Interoperability and conservative defaults are an ethical as well as a technical choice.

• Operator data. In-cab voice and camera data must be minimized, redacted at the edge and used for agreed purposes only.

Privacy and data rights: GDPR for personal data from cabs and sites; EU Data Act access rights for users of connected machines; customer and dealer agreements decide what fleet data can enter training (canvas 1).

Regulatory requirements (as of Nov 2026)

13. Implementation framework

A platform of this kind is best built through vertical slices, not layer by layer: agree the shared contracts, prove one full loop on one machine line, then take a safety-critical function through it, then scale across product lines. This sequencing is a recommendation from the analysis above, not an established standard.

The assistive first loop proves the plumbing at low risk. Only then does a safety-critical function go through the same path, so certification work is spent on a platform that already works.

Required resources

• A small platform architecture group with named owners (generic roles) for each canvas layer.

• An architecture board spanning data platform, ML platform, product engineering, functional safety, security and infrastructure.

• One machine line with an embedded edge computer installed, a proving ground and a cooperating field site.

• AI factory capacity sized from canvas 6 and the cost model from canvas 8.

Timeline considerations

• Machine programs run on multi-year product cycles; platform work must align with model-year gates.

• The EU Machinery Regulation applies from 20 Jan 2027 and AI delegated acts will follow; a safety-critical slice must be designed for both.

• GPU and embedded-computer generations change every 1–2 years (estimate); contracts must outlive them.

Risk assessment (likelihood and impact are qualitative estimates)

Success metrics

• Time from a field issue to a fixed model on the affected machines.

• Share of AI functions built on the shared contracts (target: all new ones).

• Number of machine types served by the same data, training and OTA path.

• Certification evidence produced automatically from the platform (share of safety-case evidence with lineage links).

• Unit cost per validated model and AI cost per autonomous machine-hour (canvas 8).

14. Cross-domain integration

Six artifacts carry the whole loop. If each has a versioned schema and an owner, the nine canvases can evolve separately without breaking each other.

Interface contracts

Theoretical alignment. Each discipline names the same thing differently. Safety engineers say "item" and "operational design domain"; ML engineers say "model" and "data distribution"; platform engineers say "service" and "SLO". A shared glossary maps these terms, so a gate decision in canvas 4 can cite the same ODD that canvas 1 used to build the dataset.

Methodological compatibility.

• Safety work is plan-driven (V-model, safety case); ML work is iterative. Bridge them with a release train: models iterate freely, but only release candidates enter the safety-evidence path.

• Statistical evaluation (canvas 4) and SLOs (canvas 8) use different confidence language. Agree one way to express "good enough" per safety tier.

Communication protocols between disciplines

• One architecture decision log, open to every team.

• Contract changes go through a lightweight review with all consumers, like API change reviews.

• A regular architecture forum across product lines and platform vendors; a quarterly review with functional safety and security.

• Shared C4 diagrams, kept in the same repository as the contracts.

Open questions and follow-up prompts

Open questions for practitioners

• One shared physical-AI platform, or federated stacks per product line with shared contracts?

• Which slice should go first: an in-cab assistant (fast, low risk) or a construction autonomy function (slower, higher value)?

• How much training should stay on-prem vs GPU cloud, given data sensitivity and cost?

• Who should own the six interface contracts, and where should they live?

• How will learned functions interface with existing certified machine controllers?

• How far should the architecture depend on vendor-specific APIs vs open standards?

• How should integrated and retrofit autonomy share evidence and interfaces on mixed fleets?

Follow-up prompts

1. Elaborate on a C4 container diagram for the full loop, from an embedded computer on a machine to the AI factory and back.

2. Provide ADRs for the five biggest platform decisions with options and trade-offs.

3. Analyze quality-attribute scenarios (ATAM) for a site that is offline for 12 hours during a model rollout.

4. Suggest an experiment design for the first vertical slice, including success criteria and a rollback plan.

Sources

• NVIDIA — What is NVIDIA's three-computer solution for robotics?

• NVIDIA — Mega Omniverse Blueprint for industrial robot fleet digital twins

• NVIDIA Developer — Simulating robots in industrial facility digital twins

• NVIDIA — GTC 2026: virtual worlds powering the physical AI era

• Pipeline — NVIDIA drives American reindustrialization with physical AI

• Mining Weekly — Komatsu commissions its 1,000th ultra-class autonomous haul truck

• Equipment World — How Komatsu's autonomous haul trucks work

• Business Wire — Komatsu North America and Pronto launch autonomy solution for quarry-size trucks

• Australian Mining — Autonomous haulage program in Pilbara

• CIM Magazine — Two Australian mines move to all-driverless truck fleet

• Engineering News — Fortescue marks autonomous haul milestone

• Sustainability Magazine — How BHP has made its mine in Chile fully autonomous

• Hitachi Construction Machinery — Autonomous Haulage System

• OEM Off-Highway — Volvo and Holcim collaborate on autonomous electric haulers in quarries

• Mobility Outlook — Volvo's autonomous trucks haul 1 Mn tonne in Norway

• Equipment World — Deere previews autonomous haul truck

• pv magazine — Robotic pile driver faster than manual versions, says US start-up

• TechCrunch — Bedrock Robotics funding (Oct 2026)

• The Robot Report — Teleo raises $16.2 million to scale supervised autonomy

• EU AI Act resource — Regulation (EU) 2026/1744 sectoral amendments

• Canvases 1–8 in this series and their sources (data, simulation, training, evaluation, MLOps, orchestration, inference, observability).