Physical AI safety after GTC Berlin: what the Halos model leaves to the integrator

Robotics was a prominent theme at NVIDIA GTC Berlin, but one of the most relevant observations concerned infrastructure. Jensen Huang said that “long before the AI models emerge, the infrastructure has to exist.” He was talking about AI factories. It applies just as much inside the machine.

Key takeaways

NVIDIA Halos combines preassessed platform elements with an inspection of how partners integrate them. That reduces reassessment of the platform foundations for each new machine, but the system-level safety case stays with the integrator.
Preassessed elements come with assumptions of use. The integrator has to show those assumptions hold in the finished machine, and that includes the storage holding safety-related configuration, calibration and software.
A robot delivered in 2027 will be running different software by 2032. Each update needs a safety impact assessment, and the storage architecture has to cope with interrupted updates, power cuts and models that outgrow the space allocated to them.
SnapFS stages updates in a writable clone, activates the selected state atomically, keeps a snapshot to return to, verifies stored data with integrity hashes and replaces rigid partitions with subvolumes in a shared pool.
Inside the machine, this is the persistence side of the physical AI data layer: the data behind the machine’s behavior has to remain trustworthy through normal operation, updates and recovery.

Reusable platforms need reusable safety evidence

Huang described Hyperion, NVIDIA’s vehicle platform, as “the computer itself, the functional safety system, the active safety system, an operating system designed for physical AI safety,” and said robots need the same. His argument was about scale: one standard configuration, many customers, enough volume to turn the flywheel. He named Volkswagen’s commercial vehicles, JLR, Volvo and Mercedes-Benz as Hyperion partners, and the Agile ONE SN reference humanoid is due in early 2027 with compute and software already integrated.

NVIDIA Halos brings together compute, sensor connectivity and safety software for robotics. Launched in June at Automate in Chicago, it also featured in the GTC Berlin announcements. Its approach combines preassessed platform elements with inspection of how partners integrate them. The Halos AI Systems Inspection Lab assesses that integration and provides an inspection report and certificate that partners can use to support final assessment by an independent certification body. This reduces the need to reassess the platform foundations for each new machine.

Preassessed elements come with assumptions of use, and the integrator must show that those assumptions hold in the finished machine. The safety case must also account for the remaining components and their interactions. That includes the storage holding safety-related configuration, calibration and software: how is its integrity maintained, and what happens if it becomes unavailable or corrupted? Tuxera’s contribution is storage software and supporting verification evidence that customers can incorporate into their own system-level safety case.

Safety evidence must survive updates

A robot delivered in 2027 may run different models, record more sensor data and support new features by 2032. Updates can affect the configuration and assumptions supporting its safety case. Each change therefore needs an assessment of its safety impact, with verification and further assessment where required.

The practical failures are familiar. An interrupted update leaves the machine unable to boot. A power cut leaves configuration data inconsistent. A larger model no longer fits the space allocated years earlier. Across a fleet, these problems can mean downtime, service visits and additional engineering work.

Consider an update that changes a perception model and its calibration together. The machine needs a compatible combination after installation or recovery, and the operator needs a record of which versions are active. Diagnostic records explaining a failed update should survive a rollback. These are requirements to address when designing the update and storage architecture.

Machines have to change without breaking

Tuxera is building SnapFS to address these storage challenges. It is currently in active development, with a technology preview and early access ahead of general availability.

SnapFS is designed to stage updates in a writable clone and activate the selected file system state atomically. A retained snapshot provides a previous file system state to return to if an update fails. The complete recovery path still depends on the boot process, application checks and compatibility with components outside that snapshot.

Snapshots share unchanged data, avoiding the need to reserve a complete second copy of the snapshotted content. Combined with an update mechanism that transfers and writes only changed data, this can reduce download size and flash writes compared with full-image replacement. A/B protection can still be appropriate for the boot chain and minimal recovery components, alongside snapshots for larger, frequently changing software and data.

SnapFS is designed to verify stored data using integrity hashes and report an error when verification fails, rather than silently returning corrupted data. The application must then follow a defined recovery or safe-state response. Detecting invalid data and responding appropriately to its loss are both necessary parts of the system design.

SnapFS also replaces rigid application partitions with subvolumes drawing from a shared storage pool. Quotas limit consumption, while reservations protect capacity for critical workloads. This gives applications more room to evolve without repartitioning, although total capacity and the headroom needed for updates and retained snapshots still require planning.

What this means for the physical AI data layer

GTC Berlin reinforced the value of reusable platforms and safety evidence that integrators can build on. Storage and update design must support that approach throughout the machine’s working life, keeping relevant data consistent, recoverable and traceable as software changes.

This is the persistence side of Tuxera’s physical AI data layer, alongside the reliable movement of data between devices, edge systems and the cloud. Inside the machine, the practical question is whether the data supporting its behavior remains trustworthy through normal operation, updates and recovery.

Next step

The data layer under your safety platform

If you are building robots or autonomous systems on NVIDIA Halos or a similar safety platform, our team can walk through how certifiable storage and recoverable updates fit into your evidence chain.

Talk to our team