Prerequisites
Hardware, software, and access requirements for every Halos Outside-In Safety bring-up, gathered in one place. Work through this page once before you start: the quick starts and the Deployment Guide assume everything here is already in place.
Each section links to the guide that owns the detail, so you can go deeper on whichever profile you are deploying.
Which sections apply
Hardware
Isaac Sim runs on x86-64. The Safety Core runs on either architecture: the base
profile deploys on an x86-64 server or on an aarch64 IGX Thor, and in HIL the safety
host is always an IGX Thor.
Perception host
AI Perception is the VSS Warehouse Blueprint. The minimum for the 2D Vision AI profile is:
- 18 core CPU (x86 systems)
- 128 GB RAM
- 1 TB SSD
- 1 × 1 Gbps network interface
- 1 or 2 supported GPUs
Supported GPUs, and the number of camera streams each sustains on the 2D Vision AI profile:
For the full list, see VSS Warehouse Blueprint Prerequisites and the Warehouse Quickstart.
Closed-loop host
Software-in-the-Loop runs perception, the Safety Core, and Isaac Sim together on one host, at three cameras. That is a lighter load than a production perception deployment, so these figures stand on their own rather than adding to Perception host. What the closed loop does add is a GPU with RT cores:
The GPU needs 24 GB or more of VRAM: one RTX 5090, one RTX PRO 6000 Blackwell Workstation, or two L40S.
Isaac Sim renders with ray tracing and needs a GPU with RT cores. Compute-only accelerators do not have them: an H100 runs perception well and cannot run Isaac Sim.
On a two-GPU host, give perception the first GPU and Isaac Sim the RT-core one. On a single-GPU host, that one card needs both the RT cores and the VRAM.
Perception and Isaac Sim share this host, so treat the Recommended column as the floor rather than the Minimum.
Second host for HIL
Hardware-in-the-Loop splits the loop across two machines. Isaac Sim stays on the x86 stimulus host described above, and the IGX Thor runs AI Perception and the Safety Core, so the x86 side is not sized for perception. The safety host needs:
- NVIDIA IGX Thor running IGX-SW 2.0 with Jetson Linux BSP Rel 38.5, and JetPack installed after the BSP for CUDA and the other runtime components.
- 32 GB RAM and 200 GB of free disk. The CPU comes with the platform and the x86 core count above does not apply — an IGX Thor Developer Kit reports 14 cores and is a supported safety host.
- Mutually routable IP addresses on both hosts. A Thor reachable only over a USB tether or through a jump host cannot be used.
- Both hosts NTP-synced.
- A clone of the repository on each host, and ssh access from the stimulus host to the safety host.
- MAXN power mode and pinned clocks, per Runtime environment settings.
Flashing via the Jetson USB method includes Docker and the NVIDIA Container
Toolkit. L4T flash and SDK Manager do not, so install both separately on those
paths. Depending on the method, Docker may also need sudo until you complete
the Docker post-installation steps.
See HIL Architecture for the ports each host must expose.
Software
The OS and driver are tied to each other and to the platform, so pick the row for the host you are building rather than taking a single version.
Common to every platform:
- Docker 28.3.3+ and below 29.5.0
- Docker Compose Plugin v2.39.1+
- NVIDIA Container Toolkit 1.17.8+
- NGC CLI 4.10.0+
The VSS Warehouse Blueprint pins x86 hosts to Ubuntu 24.04. The base VSS Blueprint also supports 22.04 with driver 580.65.06, and the Safety Core itself runs on either release, so a Safety-Core-only host is not constrained by this — but any host running AI Perception should be on 24.04.
The IGX Thor driver looks like a downgrade and is not: 580.00 is the driver that
ships with the Jetson BSP and is what nvidia-smi reports there. The figures
in Runtime Profile were captured on exactly this combination.
Docker Engine 29.5.0 and later fails NGC image pulls with Incorrect Repository Format after the layers download. docker login still
succeeds, so the failure surfaces only at the pull. Pin to 28.3.3 if needed.
Runtime environment settings
The VSS Blueprint expects a set of host settings that are not defaults. Follow VSS Warehouse Blueprint Prerequisites for the commands; the checklist below is only so you can confirm nothing was skipped.
The clock settings are the ones to watch, for two reasons.
They do not persist across a reboot, so a host configured correctly once will silently drop to a lower operating point after the next restart.
And every figure in Runtime Profile was captured with MAXN (mode 0) and clocks pinned. A host left at default clocks will not reproduce them. The PVA and NVDEC utilization percentages are especially sensitive: they are percentages of busy time, so the same work reports a lower number at a higher clock, and runs at different clocks are not comparable.
Two of these fail silently rather than loudly, which is why they are worth
checking explicitly rather than assuming. Missing sysctl settings degrade
throughput and latency without an error, and a default-deny firewall leaves
bridge-networked containers unable to reach host-networked services, so the
affected workflow produces no output instead of a failure.
If you use the VSS Agent, Kibana or Phoenix UIs, they are served on TCP port
7777 of the deployment host.
NGC access
The Safety Core container image, the Debian packages, and the SIL data tarball
are published under nvidia/halos-outside-in and need no entitlement or
enrollment. Pulling them still requires a signed-in account: sign in at
https://ngc.nvidia.com with any NVIDIA account, accept the terms on the Halos Outside-In Safety resource page
when prompted, and authenticate Docker with an API key.
One package is still gated: the FSI firmware package, psf-tegra-fsi, which
is only needed to run the Safety Decision Maker on the Functional Safety
Island. Everything the base, sil, and hil profiles use is public.
Create an NGC API key at https://ngc.nvidia.com → Account → Setup → API Keys → Generate API Key.
Generate a Personal Key, with NGC Catalog selected under Key
Permissions. Legacy NGC API keys are not accepted by the Cosmos3 Reasoner NIM
(1.7.0+) that VSS deploys: they fail when the container is pulled or run, not
when the key is created, so the problem surfaces late.
Copy the key when it is shown. It cannot be retrieved afterwards.
The same key covers perception. To confirm it has the access VSS needs before starting a deployment:
If ngc config set reports Missing org - If Authenticated, org is also required, the org selected in the CLI config does not match the org the key
was generated against. Regenerate the key with the intended org selected.
Docker authentication
Docker must be authenticated to nvcr.io or protected image pulls fail with
401 Unauthorized. NGC CLI authentication alone is not enough. The login covers
the Safety Core image and the VSS 3.3.0 images in nvcr.io/nvidia/vss-core.
To pull the Safety Core image and confirm access, see Docker login and image pull in the Deployment Guide.
The 1.4 sil and base configurations need the PSF 1.4 Safety Core image, nv-psf-halos-1.4-6b92731, which sil.env and base.env pin: its launcher starts every decision maker from its own event-binding configuration. The 1.3 image does not run these configurations.
NGC CLI authentication
Required for downloading data and compose files.
Perception and calibration
The Safety Core consumes perception events, so the perception stack has to be up, publishing on Kafka and correctly calibrated before the Safety Core starts. The checks start at AI Perception is running in the Deployment Guide.
Per-profile additions
3D perception
SIL — 3D Perception assumes familiarity with:
Agentic deployment
Agentic Deployment also needs an agentskills.io-compatible coding agent on the host, such as Claude Code, Codex, or Cursor.
Next steps
- Deploy AI Perception — Deploy AI Perception on live cameras
- Deploy the Safety Core — Deploy the Safety Core on an existing perception feed
- SIL — 2D Perception — Bring up the single-host closed loop
- Deploy the HIL Closed Loop — Bring up the two-host closed loop
- Agentic Deployment — Have a coding agent perform the bring-up for you