Nvidia extends its automotive safety stack to robots with Halos

Nvidia has taken the functional safety stack it built for self-driving cars and repackaged it for robots. Halos OS for robotics, running on the IGX Thor compute module, is a full-stack safety system aimed at industrial robots, humanoids and autonomous mobile robots; together the two form the Halos platform. Agility, maker of the Digit humanoid, is the first named adopter, folding IGX Thor and Halos OS into its own human-detection system. The argument underneath is that robotics does not need to build a safety foundation from scratch — it can inherit one written for cars.

The ledger Nvidia puts behind that claim is entirely automotive: more than 18,000 engineering-years spent on vehicle safety, over 21 billion transistors verified, more than 7 million lines of safety-assessed code, more than 22,000 system safety monitors, over 330 published papers on autonomous-vehicle safety, and more than 30 certificates and assessment reports.

What carries across is process rather than product. The automotive and robotics stacks share the same software lifecycle and hardware development process, the same verified tooling, and the same base functional safety standards — ISO 26262, IEC 61508 and ISO 13849 — with compliance in both domains confirmed by independent assessment from TÜV SÜD and TÜV Rheinland. Nvidia also leads the work on IEC 61508, the core functional safety standard for robotics, and on ISO/IEC TS 22440, which is being written for functional safety and AI; it chairs IEC TC 65 AhG 30 and contributes to ISO 25785-1. A vendor that sits on the committees writing the rules and sells the pre-assessed parts that satisfy them occupies an unusually comfortable position, and Nvidia is not being coy about occupying it.

The stack is three layers, mirroring Halos for autonomous vehicles. At the bottom is hardware platform safety: IGX Thor and the Holoscan Sensor Bridge, or HSB. Above it runs Halos OS, the software safety stack executing on IGX Thor in robots and AMRs — the same approach used for autonomous-vehicle safety on DRIVE AGX, widened. Inside Halos OS sits Halos Core, the base safety operating system, plus a set of blueprints, among them the Halos outside-in safety reference blueprint, which supplements a robot's perception with external cameras covering the work area and AI agents that can change the machine's behavior dynamically.

IGX Thor is an industrial AI compute module that pairs perception throughput with hardware functional safety: up to 2,070 FP4 TFLOPS of AI performance, 14 Neoverse Arm cores, and 128 GB of memory at 273 GB/s — enough to run demanding real-time robotics workloads and safety monitoring simultaneously.

What separates it from a general-purpose compute platform is the built-in safety hardware, managed by the safety extension package, or SEP, inside Halos Core. SEP collects and distributes hardware faults between the FSI and the Safety MCU, and ships reference firmware for both, an error propagation layer called EPL, and the Edge Safety Link safety protocol. HSB connects sensors and actuators to IGX over Ethernet, carrying the safety chain down to sensor level. The description of how IGX and Halos OS apply in a safety context is available under NDA.

The hardware arrives with a partner list to match. IGX manufacturing partners include Advantech, Nexcobot, Inventec and Connect Tech. Safety microcontrollers and sensors come from Infineon, NXP Semiconductors and Texas Instruments. HSB silicon partners are Texas Instruments, STMicroelectronics, NXP Semiconductors and Lattice Semiconductor.

Halos Core is the next generation of DriveOS, the software layer already certified to automotive safety standards, now running on IGX Thor. Two configurations are in early access. Halos Core Linux supplies the full safe software base: a Linux runtime for applications and compute, SEP for fault collection and distribution, the Edge Safety Link communication protocol, an RTOS for the FSI and RTOS firmware for the Safety MCU.

Halos Core Linux with QNX adds the NV Hypervisor, which partitions IGX into isolated virtual machines: a Linux VM for AI and applications, and a QNX VM for safety-critical functions. QNX is a real-time operating system with long service in certified safety systems, and its presence buys stricter isolation between software components for workloads at higher safety integrity levels.

Blackberry supplies QNX at this layer, Acontis brings EtherCAT/FSOE, and FreeRTOS is in the mix; AWS, which stewards FreeRTOS, will offer a safety certification package as part of Halos OS, with other partners in the ecosystem. Robotics middleware tooling and Halos Infra are available but explicitly not yet meant for safety applications. Architecture documentation sits in the IGX Safety Product Brief, behind developer registration on the Nvidia Developer portal.

The application layer is where Nvidia's real argument about robot safety lives. The outside-in safety reference blueprint pushes perception past the robot's onboard sensors, using external infrastructure cameras, AI-based perception and safety logic to speed up real-time functional safety development without surrendering operational performance. It runs on IGX, ships as open source, and comes with documentation mapped to AI functional safety standards including ISO/IEC TR 5469 and the in-development ISO/IEC TS 22440. Its components are configurable: data in, such as camera video streams, and safety signals out for an autonomous vehicle or a robot.

The worked example is automated trailer loading, or ATL — a safety concept verified by TÜV Rheinland and built on the outside-in blueprint. Inside-out systems that rely only on the robot's own sensors perform badly inside trailers: the space is confined, onboard sensor errors cause cargo and trailer walls to read as obstacles, and the forklift crawls or stops outright. Switching onboard safety off restores throughput, but only if the shutdown is itself controlled and safe.

In the ATL example, a system called SIPP, built on Nvidia's VSS reference blueprint for warehouse operations, ingests several video streams, detects and tracks objects, and matches them against events inside a defined region of interest around the loading zone and a control line at the trailer entrance. The SDM module determines at any moment whether people are in the loading zone and whether the forklift is inside the trailer or outside it.

With the forklift inside the trailer and no workers in the loading zone, SDM temporarily disables the forklift's onboard safety system, letting the machine run at full efficiency. The moment a worker enters the loading zone, the region-of-interest crossing event travels through SEI to SDM and the forklift's safety system comes back on in full. If the SAIM module detects camera conditions degrading — the lights going out, fumes obscuring the view — it raises an additional out-of-distribution event and SDM responds accordingly. Nvidia says the approach delivers higher throughput and more reliable coverage of safety scenarios than onboard systems alone.

This is the most interesting thing in the announcement and the least remarked upon. Nvidia's flagship demonstration of a safety platform is a system that turns a machine's safety off. That is a defensible engineering position — the industry's operational problem is rarely that robots are unsafe, it is that safety systems are conservative enough to make automation uneconomic, and ATL is an honest admission of it. It also relocates the entire safety case from the robot to the ceiling. The forklift's own perception is declared unreliable inside the trailer, and the thing overruling it is a set of infrastructure cameras that the same blueprint concedes can be blinded by darkness or fumes. SAIM exists precisely because that failure mode is expected.

The gap is what the announcement does not quantify. Out-of-distribution detection is not instantaneous, and a forklift running at full efficiency with onboard safety suspended is a considerably worse object to stand near than one crawling. There is no latency figure for the degradation-to-fallback path and no residual-risk number for the window between a camera going bad and SDM acting on it. TÜV Rheinland verified the concept, which is not the same as certifying a deployment — and by Nvidia's own description of the process, certifying the deployed system remains the integrator's job.

That process is the second half of the product. The Halos AI Systems Inspection Lab is an inspection body accredited by ANAB under ISO/IEC 17020, which Nvidia calls the world's first accredited program addressing AI and functional safety together across both autonomous vehicles and robotics. A partner or OEM brings its product to the lab to check that Halos requirements for safety, AI safety and cybersecurity have been integrated correctly; Nvidia's safety and regulatory experts assess the system against pre-verified Halos stack components — the IGX SoM, Halos Core and Halos applications — and issue an inspection certificate and report. The partner then carries that to a third-party certification agency — TÜV Rheinland, TÜV SÜD, SGS, exida, CERTX or UL Solutions — for final certification of the whole system. Because the Halos components and their integration have already been pre-assessed, partners skip verifying the platform from scratch and concentrate on certifying their own application logic, cutting time and cost.

Read commercially, this is the sharpest piece of the strategy. The lab converts certification paperwork into a switching cost: a robotics company that has taken its stack through the Halos inspection path and out the far side of TÜV does not casually re-platform onto another vendor's silicon afterwards. The compute is sold on TFLOPS; the lock-in is sold on stamps.

Agility is running Digit's software, AI components and cybersecurity through the lab against IEC 61508, ISO 13849 and ISO/IEC TR 5469 ahead of final third-party certification, and is the highest-profile of the new arrivals. The lab ecosystem now counts more than 43 companies and continues to grow; joining alongside Agility are Lyte AI, Neurealm, Ouster and Peer Robotics, with Boston Dynamics, KION Group, Infineon, Texas Instruments, NXP Semiconductors, Lattice Semiconductor, Synapticon, Reynolds & Moore, the cybersecurity firm SecEdge, and FORT Robotics already inside.

Developers can register for early access to Halos Core and start building safety applications for robotics on IGX. The outside-in work sits on GitHub as NVIDIA/halos-outside-in-safety, with two AI agent skills — warehouse-deploy and halos-deploy — that assemble and launch a safety agent from a single prompt, handling prerequisites, component downloads from NGC, configuration, the VSS warehouse blueprint and Halos SIL deployment, so the reference blueprint can be adapted to a specific scenario without manual environment setup.

That split is worth holding onto. The blueprint that tells a robot when it is safe to move fast is open source and deployable from one prompt; the document describing how IGX and Halos OS actually behave in a safety context is under NDA. Nvidia is inviting the robotics industry to build on a safety foundation whose most load-bearing details are visible only to those who sign first.