Skip to navigation

Release Notes

View as Markdown

These Release Notes describe the key features, software enhancements and improvements for NVIDIA Halos Outside-In Safety Blueprint releases.

1.4 EA

This release changes how Safety Core processes connect to each other, makes the SEI configuration strict, makes the Perception Monitor safety-relevant, and selects each AI monitor’s mode on the launcher command line. Several changes stop an existing 1.3 deployment from starting until you act. Each item below says what changed and what to do.

Rebuild or reinstall every Safety Core runtime from this release together: the CCPLEX packages, the container image and, for SDM on FSI, the FSI firmware. Mixed versions reject each other’s messages (see Wire format).

Transports

  • Every link between Safety Core processes is now an AF_UNIX SOCK_SEQPACKET socket in /run/nvpsf: client registration and reports (nvpssd), the SEI daemon to the NvPSD Gateway (nvpssd_to_psd), and the NvPSD Gateway to the SDMs and fsicom-agent (nvpsd_gateway). None of them can be selected or configured.
  • The NvPSD Gateway no longer listens on UDP port 50000 and opens no network port. Its --sdm_ip and --sdm_port options are gone and are refused as unknown options, as are --transport, --sdm_socket and --sdm_allow.
  • fsicom-agent connects through the socket. --gw-ip and --gw-port are retired and refused, as are --gw-transport and --gw-socket.
  • atl_sdm no longer accepts --gateway_ip or --gateway_port. proximity_sdm still accepts them, with no effect.
  • Peer check. Every socket accepts a peer only if the peer’s primary group id equals its own, and the SDMs, fsicom-agent and the NvPSD Gateway also check the server they connect to. Every Safety Core process, on the host and in the container, must therefore run with one primary group. All processes in the container, or all on the host as root, meet this. launch_hoisa.sh --runtime docker starts the SDMs or fsicom-agent on the host with the container user’s group; a process you start on the host next to the container needs the same. See Shared process group.
  • Kernel socket buffers. The NvPSD Gateway, the CCPLEX SDMs and fsicom-agent check that the kernel grants the socket buffers they need. The gateway refuses to start when net.core.rmem_max or net.core.wmem_max is too small, with nvpsf_transport: SO_RCVBUF granted <n> bytes but <m> are required ...; raise net.core.rmem_max. See Kernel socket buffers.
  • Registration refusals are answered. The gateway replies to a refused SDM registration with a reason (malformed, no_valid_event_types, table_full or rate_limited), and the SDMs and fsicom-agent log it. Registrations are rate limited per connection by the new gateway options --regr_max_per_window (default 4) and --regr_window_ms (default 10000).
  • fsicom-agent --relay-fsi-resp now requires --cmd-identifier: 0xA2 for the forklift safety function, 0xA5 for Proximity Monitoring. launch_hoisa.sh passes it.

SEI configuration (nvpss.conf)

  • New mandatory keys: deploymentMode (2D or 3D), enableFusion (true or false), required_safety_monitor, required_perception_monitor and required_mdx_instances. Add them before you upgrade; the shipped file sets 2D, true, 1, 1 and 1.
  • Strict loading. A missing or unreadable file, a missing mandatory key, a line without =, or a repeated deploymentMode, enableFusion or required-source key now stops the daemon. In 1.3 a missing required key made the daemon discard the whole file and run on built-in defaults.
  • PSSDToPSDComBackend is retired. A file that still contains it is refused, whatever its value. Delete the line.
  • Unknown names in bypassFusionEvents are now ignored with an error record, instead of being replaced by EVENT_0. SW_FAIL is always bypassed.
  • New optional keys: psd_operational_queue_depth, psd_critical_queue_depth, fusion_failure_error_ms, client_reject_error_threshold, and, in 3D, sensorGroupConfig.
  • The shipped timeWindowSize is now 400 ms (it was 1000 ms). Events older than this, or dated more than this far in the future, are marked stale and dropped by the SDMs, with or without fusion.
  • nvpss_daemon --conf <path> reads another file.

See SEI Configuration for every key and its failure message.

Sensor identity

  • sensor_pipelines_config.conf is new and mandatory for the CCPLEX SDMs. It lists the reviewed sensor set behind the all-safety-relevant-sensors-failed latch, which used to be compiled into each SDM. The package installs it live at /opt/nvidia/psf/bin/sensor_pipelines_config.conf with the three reference cameras. A site with a different camera set must edit it. The SDMs refuse to start if it is missing or malformed.
  • Events from sensors that are not configured are refused. In 1.3 the MDX client sent such an event with pipelineId 0, which bypassed the identity and sensor-health checks. It is now dropped (Dropping event: sensor not in sensor_config, so it has no pipelineID: <name>), and the SEI daemon refuses any per-sensor event without a pipelineId. Make the names in Kafka and in sensor_config.conf agree.
  • An event that drives a decision must name its sensor. An event with an empty sensorIdentifier on a camera pipelineId used to be accepted, which skipped the name check that catches a wrong pipelineId. It is now rejected in 2D and 3D, with fusion on or off (Rejecting event: empty sensorIdentifier for pipelineID <n> ...). SW_FAIL and the trust reports (SENSOR_*, AI_PIPELINE_*) are not refused for an empty name. The MDX client already names every event; a custom event source that leaves the name empty must set it.
  • 3D (BEV) deployments are declared, not inferred. With deploymentMode = 3D the SEI daemon needs a sensor group file (sensorGroupConfig) and enableFusion = false, the MDX client resolves the BEV group name through sensor_pipelines_config.conf, and that file lists the group instead of the cameras. This replaces the 1.3 advice to leave the group out of the configuration. See Sensor files.

Launchers

  • Each AI monitor has its own required mode. launch_hoisa.sh and the container both require --saim-mode learn|active|skip and --pcm-mode learn|active|skip. Neither selects the other. launch_hoisa.sh --mode remains as a deprecated alias for --saim-mode only, and --skip-pcm as a deprecated alias for --pcm-mode skip; both print a warning. A command line with only --mode now stops with Error: --pcm-mode is required and must be learn, active, or skip: add --pcm-mode.
  • launch_hoisa.sh --runtime docker starts host processes with the container user’s group. Once the container runs, the launcher reads the group ID of its nvidia user and starts the SDMs or fsicom-agent on the host as root with that group, through setpriv, so the NvPSD Gateway in the container accepts them. A control-plane run with --runtime docker now needs setpriv through passwordless sudo, and refuses Docker with user-namespace remapping or in rootless mode. It warns, without stopping, when host accounts share the container user’s group or user ID, because they can reach the Safety Core sockets. --runtime host is unchanged. See Host processes and the container’s group and Known Limitations.
  • The modes must match nvpss.conf. When the control plane runs (a monitor in active, or both skipped), required_safety_monitor and required_perception_monitor must be 1 for a monitor in active and 0 for one in learn or skip. A mismatch stops the launcher before anything starts. The launchers never change the file.
  • Learning runs. With only learn and skip selected, the launchers run the learning monitors and exit. They start no SEI daemon, NvPSD Gateway, MDX client or SDM, and do not read nvpss.conf; --nvpss-conf is ignored with a warning. A learning monitor never switches to active. In a run where the other monitor is active, a learning monitor stops when it has written its baselines and the rest keeps running.
  • PCM runs in the container. Under --runtime docker, SAIM and PCM both run inside the Safety Core container, which now also gets /var/run/docker.sock, the PCM baseline directory and pcm.log. Under --runtime host both run on the host. The container entrypoint starts PCM, so a plain docker run needs no PCM on the host.
  • New PCM options on both launchers: --pcm-baseline-dir (default /opt/nvidia/psf/bin/pcm_baseline) and --pcm-config (default /opt/nvidia/psf/bin/pcm_monitor.cfg). The container’s --broker now reaches PCM too, as launch_hoisa.sh --kafka-broker does. --app, --sdm-config and --event-mapping also apply to learning runs, where they select the decision maker bindings PCM records.
  • Supervision. Both launchers stop the run when an active monitor exits, when a learning monitor fails, or when a monitor’s log can no longer be written. launch_hoisa.sh also stops everything when the container exits, with Error: PSF Docker container exited unexpectedly.
  • Every CCPLEX ATL and Proximity SDM needs an SDM configuration file that binds its situations to event codes. Pass it with the new --sdm-config option, of launch_hoisa.sh or of the container. Templates are installed in /opt/nvidia/psf/bin/ as *.conf.sample. This applies to a plain docker run that starts the SDM in the container too.
  • Several decision makers on one stack. --app accepts atl,pxc, pxc,atl, atl,atl, pxc,pxc and atl_dual, with one --sdm-config, command receiver port and optional --sdm-log-file per SDM. The container also accepts --app atl_proximity.
  • New launch_hoisa.sh options: --sdm-config, --sdm-log-file, --event-mapping, --sensor-pipelines-config, --atl-zone1-conf, --atl-zone2-conf, --zone2-cmd-rx-port, --halo-ip, --halo-port, --saim-mode, --pcm-mode, --pcm-baseline-dir and --pcm-config.
  • New container options: --sdm-config, --sdm-log-file, --event-mapping, --sdm-external, --atl-zone1-conf, --atl-zone2-conf, --zone2_cmd_rx_port, --proximity_cmd_rx_port, --pair_ttl_ms, --pcm-mode, --pcm-baseline-dir and --pcm-config.
  • --nvpss-conf applies to both runtimes. With --runtime host it is passed to the daemon as --conf.
  • --gateway-ip and --gateway-port have no effect and should be left out.
  • The MDX client takes --instance-id, which the launchers set to 1, and exactly one of --sensor-config (2D) or --sensor-pipelines-config (3D).

See Launchers and command-line options.

Perception Monitor is safety-relevant and required by default

  • In 1.3 the Perception Monitor (PCM) was a preview whose AI_PIPELINE_INVALID only suppressed event-driven decisions. Now every SDM, on the CCPLEX and on the FSI, latches its safe state on AI_PIPELINE_INVALID, and accepts a release only after AI_PIPELINE_VALID.
  • The shipped nvpss.conf requires PCM: start it with --pcm-mode active, or set required_perception_monitor = 0 and use --pcm-mode skip. A required PCM that never registers latches every SDM about 4 minutes after the SEI daemon starts.
  • PCM sends its first AI_PIPELINE_VALID only when its checks have real evidence, and re-sends the current verdict every 5 s by default (verdict_resend_ms). In LEARN mode it never reports.
  • PCM checks the data the SDMs decide on. Besides unknown cameras and frame rate, its data check now covers frame freshness (observation time stamps), the ROI and proximity data that the configured SDMs use, and ten consecutive undecodable messages. Bounding boxes, confidence and object classes no longer count.
  • Setup problems are not faults. Docker unreachable, a Kafka error, no usable baseline or an empty container list is logged and turns the affected check off instead of reporting AI_PIPELINE_INVALID. A listed container that never appears is logged, not a fault; once seen, a container that stops with any exit code is a fault. The shipped container list now names five containers: vss-vios-nvstreamer, vss-vios-streamprocessing, vss-rtvi-cv, vss-behavior-analytics and kafka.
  • pcm_monitor.cfg needs new sections. [fault_aggregator] with bad_ticks_to_invalid and good_ticks_to_valid is required, and so are bad_objects_percent and bad_frames_percent in [data_validation] while the data check is on. Without them PCM does not start in active mode. Start from the shipped file instead of a 1.3 copy.
  • New baseline location and format. PCM baselines live in /opt/nvidia/psf/bin/pcm_baseline/. LEARN writes one pcm_baseline.cfg for the whole camera set, including the decision maker bindings it was learned with; an active run with other bindings does not use it. Baselines learned into /opt/nvidia/psf/bin by 1.3 are ignored, with a warning: learn again.
  • Reference PCM baselines for the three demo cameras ship as pcm_<camera>_baseline.cfg.default. They fit --app atl,pxc with atl_sdm_zone1.conf and pxc_sdm_forklift.conf; other configurations need a learn run.
  • PCM log lines now read [<date> <time>] [PCM][INFO|WARNING|ERR] <message>, in /var/log/psf/pcm.log under both runtimes.

Safety AI Monitor

  • Learn the SAIM baselines again after upgrading. SAIM refuses baselines from earlier releases with ... was learned on a 0x0 tile grid but this build uses 15x15. Re-run LEARN to regenerate this baseline. and stops watching that camera. The camera then stays at its start-up state and is never counted as failed, so learn every camera before you rely on active mode. The shipped .cfg.default templates are new too; under the Docker runtime the container reads them from the host, so upgrade the Debian package together with the image. See Baselines.
  • Scoring per tile. SAIM also measures a 15×15 grid of tiles in every frame. A change in the whole-frame metrics counts only as far as the tiles agree on it, so moving forklifts and people no longer lower the score. A new area score drops below the low threshold when a blocked, saturated, blurred or noisy part of the image covers more than about 2.5% of the frame for about 5 s; the verdict follows after the debounce. The frame score is the lowest of the brightness and structure, colour and area scores. See What SAIM checks.
  • Supported frame sizes. SAIM analyses 1920×1080 and 3840×2160 streams only, and a baseline only at the size it was learned at. Other sizes stop that camera with SAIM_INTERNAL_ERROR. See Known Limitations.
  • Lost streams are reported sooner and recovered without a restart. A stream ends after more than 5 s without packets, instead of 60 s, and a trusted camera reports SAIM_STREAM_DISCONNECT at once. In active mode SAIM retries a lost or unreachable camera every 5 s for as long as it runs, and starts watching it again when it comes back. It no longer gives up on a camera after six attempts, except when the camera’s URL is malformed, and no longer exits when no camera can be reached. See Camera failures.
  • RTSP control URL. SAIM sends PLAY, keep-alives and TEARDOWN to the control URL the server returns, so servers that answer with a per-viewer URL, such as NVStreamer, work.
  • Fixed: on IGX Thor (PVA), SAIM could analyse a frame before it was fully copied.

Safe state

  • Lost safety sources latch every SDM. If SAIM, PCM or a numbered MDX client stops being registered for any reason (hang, crash, exit, heartbeat loss), or a required one never registers, every SDM latches, and no release is accepted until that source is back. Restarting a monitor therefore needs a release afterwards.
  • A source whose reports are all rejected latches every SDM, after client_reject_error_threshold consecutive rejections, until the SEI daemon confirms it usable again.
  • Standing verdicts are re-sent. The SEI daemon re-sends every standing SENSOR_INVALID and AI_PIPELINE_INVALID each status interval, so an SDM that restarts latches again.
  • New fault reports. The gateway sends a recovery record (cause 14) once its link to the SEI daemon is healthy again. When the SEI daemon’s queue for fault reports is full, a report displaces an event from a distrusted source, or the daemon reports ERROR until it can deliver it. On FSI, a request that fsicom-agent cannot queue now latches the FSI SDM.
  • A safe release is evaluated against a whole request, so it cannot be accepted between one cause clearing and another being raised by the same request.
  • Camera initialisation does not latch. Every SDM, on the CCPLEX and on the FSI, does not count a camera as failed while SAIM initialises it, from SAIM’s CAUSE_SAIM_INIT report until the camera reports healthy, including events that the SEI marks unhealthy in that time. A SENSOR_INVALID with any other cause still counts as a failure. See Sensor health.

See Causes and records and Safe-state model.

Wire format

  • Schema version 5 (1.3 used 3). Every event carries a one-byte cause (0–18) instead of a rule name string, and the event types after EVENT_23 are renumbered (SW_FAIL is 24). A runtime built from another schema rejects every message, so install the CCPLEX packages, the image and the FSI firmware in the same maintenance action.
  • Logs print causes as numbers (cause=4), on every runtime. Scripts that search for cause names must use the numbers in Causes and records.

Other changes

  • The Proximity reference command receiver now supports the VST relay options --vst_ip and --vst_port.
  • proximity_sdm can send its commands to a VST halo overlay too (--halo_ip, --halo_port; launch_hoisa.sh --halo-ip, --halo-port).
  • The runtime package and the image install a log rotation rule, /etc/logrotate.d/pss, for /var/log/psf/*.log and /var/log/pss.log: daily, 7 old files kept, rotated early above 100 MB, compressed.
  • The runtime package installs /opt/nvidia/psf/tests/pcm/test_monitor_launch.sh, a check of the launchers’ monitor handling that needs no Docker, Kafka, GPU or sudo.

Closed-loop testing

The closed-loop harness gains Safety Core proximity control of the simulated forklift, one scenario id per run, and multi-forklift fleets. The reference perception pipeline has been upgraded to VSS Warehouse Blueprint 3.3, and the simulation to NVIDIA Isaac Sim 6.1. The IGX Thor profiles (hil, base on IGX Thor) stay on VSS Warehouse 3.2.1 and the Safety Core 1.3 package in this release, so the Safety Core changes above do not apply to them yet. Some features remain in an alpha state and should not be used in production.

Proximity control in the closed loop

  • PSF_APP=pxc runs the Proximity SDM in the SIL loop on the 3D feed, and PSF_APP=both runs it beside ATL in one container. The forklift controller obeys the decision — capped speed on REDUCE, stopped on STOP, stopped when the link goes silent — and the in-scene indicator shows the level. An optional floor line draws each scored pair with its separation. See SIL — 3D Perception.

Scenarios and fleets (breaking for the closed-loop harness)

  • One SCENARIO id names the scene, fleet file, cameras config and waypoint set, read by Isaac Sim and every forklift controller (scenarios.yaml).
  • Forklifts are spawned from robots.yaml, which also carries each truck’s drive: and proximity: behavior. The FORKLIFT_* drive variables, FORKLIFT_WAYPOINTS_DIR, FORKLIFT_USE_NAMESPACE and FORKLIFT_ROBOT_ID are removed; waypoints moved to waypoints/<map>/<robot>.json.
  • The ROS surface is namespaced per robot: /forklift_b/cmd_vel, /forklift_b/odom, TF forklift_b/odom → forklift_b/base_link, node forklift_b_controller. Scripts and RViz configs that name the 1.3 topics need the prefix. See Forklift Controller.
  • Added two-forklift runs through the multi-robot compose profile on the experimental warehouse_40x20 scene.

VSS Warehouse Blueprint 3.3 upgrade

  • The reference perception pipeline is VSS Warehouse 3.3.0 (GitHub release v3.3.0), deployed with the VSS repository’s vss-build-vision-ai skill or by hand. Its images are in nvcr.io/nvidia/vss-core and need Docker logged in to nvcr.io with the NGC API key. VSS 3.3 ships the Sparse4D model and the loading-dock BEV calibration, so the separate R101 model install and the -3d calibration dataset are gone. See Deploy AI Perception.

NVIDIA Isaac Sim 6.1

  • The closed-loop harness runs on Isaac Sim 6.1 (nvcr.io/nvidia/isaac-sim:6.1.0), with IRA configs at version 1.7.0; Isaac Sim 6.1 refuses 1.6.0. Isaac Sim 6.1 ships the upstream fix for the RTSP cold-start has no caps race.

1.3 EA

This early access (EA) release builds on 1.2.1 and includes major safety-path, perception-trust, event-ingestion, packaging, and deployment updates. The reference perception pipeline has been upgraded to VSS Warehouse Blueprint 3.2.1. Some features remain in an alpha state and should not be used in production.

Key Features and Enhancements

Fail-safe SDM lockout and validated release

  • Added fault-safe SDM lockout and validated safe-release behavior for ATL and Proximity on CCPLEX and FSI.

Perception Container Monitor (Preview)

  • Added Perception Monitor (PCM) to assess container and Kafka message data health and report status to SEI.
  • PCM is Preview in 1.3 and must not be used to trigger a safe state.
  • Its verdict does reach the decision path: when PCM reports the AI pipeline invalid, the reference SDMs treat perception as untrusted and log incoming events without processing them for decisions. A PCM fault therefore suppresses event-driven decisions rather than commanding a safe state, and the behavior is not validated for safety use in this release. Pass --skip-pcm to launch_hoisa.sh to leave PCM out.

Safety AI Monitor improvements

  • Added PVA backend support for IGX.
  • Added GPU/PVA backend improvements, additional frame-quality checks.

Command receiver logging

  • The reference command receivers now write their verbose per-packet log to /tmp/cmdrx.log and reserve the console for safe-state latch, clear, and release events, so the safe-release prompt is no longer buried in packet output. Use --log-file <PATH> to redirect the detail, or --no-log-file to restore the previous console behavior.

Hardware-in-the-Loop (HIL) testing profile

  • Added the hil profile, which splits the closed loop across two hosts: NVIDIA Isaac Sim, the communication layer, and the forklift controller run on an x86 stimulus host, while the VSS Warehouse perception stack and the Safety Core run on an NVIDIA IGX Thor. See Hardware-in-the-Loop Testing.
  • The safety decision returns to the simulation over UDP to the communication layer on the stimulus host. The on-video VST overlay used by the base profile is not driven in this profile.
  • Added a two-host preflight check that validates the address pairing, the command port, ssh reachability, and clock synchronization before bring-up.

Regression Testing Reporter (Preview)

  • Added the Regression Testing Reporter, a closed-loop regression-testing layer that records NVIDIA Isaac Sim ground truth alongside the safety decision on one timeline, then scores each test case on whether the alarm was raised and cleared at the right moment. It runs on top of a deployed SIL stack and needs no manual labeling. See Regression Testing Reporter.
  • Added its debug viewer, a browser tool that plays a graded test case back with the video, ground truth, perception, behavior events, and Safety Core state on a shared timeline. See Debug Viewer.
  • Added the hoisa-generate-regression-report skill, which drives a multi-scenario run and produces the report.

Closed-loop forklift controller

  • The forklift-controller service now drives the forklift against its odometry feed. It steers toward the next point on the route, advances only once the forklift has actually arrived, and publishes cmd_vel; the in-scene control graph converts what it receives and nothing more. Earlier builds played back fixed segments — a duration and a velocity per segment — from inside the Action Graph, with no position feedback.
  • Position feedback corrects wheel slip as it happens, so a long run holds its route instead of drifting off it.
  • A slow or stop command scales the controller’s velocity, and the forklift still drives to the same point on the route, so a slow-down costs time rather than distance. The safety decision itself does not change how the forklift drives — the controller is a stimulus generator. See Forklift Controller.
  • Routes are authored outside the simulation as JSON, so changing one no longer means editing the Action Graph. Added the Forklift Waypoint Generator, a web tool that draws a route over the warehouse floor plan and exports that JSON, including the origin that fixes the odometry frame. See Forklift Waypoint Generator.

NVIDIA Isaac Sim 6.0

  • Upgraded the closed-loop testing harness from Isaac Sim 5.1 to 6.0.
  • Breaking change. Isaac Sim now serves its camera streams over RTSP directly, so the separate streaming relay is gone: the harness no longer starts a mediamtx service, and the stream URLs move from the relay to Isaac Sim’s own ports. Existing sensor registrations and any scripted stream URLs need updating.
  • Breaking change. Pedestrian behavior is authored as IRA 1.6 behavior trees; the legacy text command files are no longer read.

VSS Warehouse Blueprint 3.2.1 upgrade

  • Upgraded the reference AI perception source from VSS for Warehouse Operations 3.2.0 to 3.2.1, and updated every documentation reference to match.

Agentic deployment

  • The hoisa-deploy-profile skill now covers the hil profile, the IGX Thor Safety Core, and the 3D perception backend alongside base and sil.
  • A second skill, hoisa-generate-regression-report, ships alongside it; see Regression Testing Reporter (Preview).

Cloud deployment on NVIDIA Brev

  • Added an NVIDIA Brev Launchable that provisions a cloud GPU instance with the driver, Docker, the NVIDIA Container Toolkit, and both repositories in place, then brings up the sil closed loop from a single notebook and prints the evidence that the safety decision is following the simulated scene. Evaluating the blueprint no longer requires a host of your own. See Deploy on NVIDIA Brev.

3D perception profile

1.2.1 EA

This early access (EA) update builds on 1.2. The NVIDIA Halos Outside-In Safety Blueprint source is published for integrators under NVIDIA license terms, the reference perception pipeline has been upgraded to VSS Warehouse Blueprint 3.2.0, and the packaging and deployment guidance has been refreshed. Some features remain in an alpha state and should not be used in production.

Key Features and Enhancements

Source availability

  • The Safety Core source and packaging scripts are published so integrators can build and extend the reference applications. The files carry proprietary NVIDIA license headers: distribution and use are governed by the applicable NVIDIA license terms, and publication does not place the source under an open-source license.

VSS Warehouse Blueprint 3.2.0 upgrade

  • Upgraded the reference AI perception source from NVIDIA Metropolis Blueprint for video search & summarization (VSS) for Warehouse Operations 3.1.0 to 3.2.0, including all related documentation references.
  • VSS Warehouse Operations Blueprint is deployed from its public GitHub repository. Deploy AI Perception and the closed-loop (SIL/HIL) testing guides have been updated for the new deployment flow, service names, environment settings, and 2D and 3D perception configuration.

Deployment skill updates

  • The deployment skill for coding agents (such as Claude Code, Codex, and Cursor) is part of the published repository as a single hoisa-deploy-profile skill that deploys Halos by profile: base (Safety Core on an existing perception feed, on x86 or on NVIDIA IGX Thor with the decision maker on CCPLEX or FSI) and sil (full closed loop). The VSS Warehouse Operations Blueprint 3.2.0 as perception backend is deployed first via the separate vss-deploy-profile skill from the VSS Warehouse Blueprint.

Packaging and distribution updates

  • Safety Core packages and container images are published in NGC under nvidia/halos-outside-in (with the gated FSI firmware package under nvidia/outside-in-safety), at version 1.2.1.
  • The fsicom-agent host bridge ships in the psf-tegra-fsi.deb package.

Command receiver VST relay

  • The ATL reference command receiver can optionally relay validated decision packets to a VST display destination with --vst_ip and --vst_port. Both options are required together; relay delivery failures do not interrupt command reception or acknowledgement. The Proximity receiver does not implement this relay.

Safety-flashed IGX Thor deployment guidance

  • Added guidance for deploying the VSS Warehouse Blueprint - 2D profile on safety-flashed IGX Thor systems, including container runtime and image pull workarounds. See Annex A for details.

1.2 EA

This is an early access (EA) release including a refactored architecture and new features. There are some features in an alpha state and should not be used in production.

Key Features and Enhancements

Safety Decision Maker on FSI for IGX

  • Added support for running the Safety Decision Maker (SDM) on the Functional Safety Island (FSI) for IGX platforms.

Safety AI Monitor (Preview)

  • Added Safety AI Monitor, supported on GPU only, to validate input video for Out-of-Distribution (OOD) and camera blockage detection.

Proximity monitoring reference application

  • Added a new Proximity Monitoring reference application for proximity detection between a human operator and robot.

Safety Core updates

  • Added performance and functional safety updates and bug fixes to the Safety Core components.

Closed-loop testing harness updates

  • Added the groundwork for Hardware-in-the-Loop (HIL) testing (Preview). The deployable hil profile arrived in 1.3.
  • Added support for deployment support via agentic skills and coding agent platforms (Claude, Codex, etc.) (Preview)
  • Added support for 3D vision AI perception pipeline (Preview)

1.1 EA

This is an early access (EA) release including a refactored architecture and new features. There are some features in an alpha state and should not be used in production.

Key Features and Enhancements

New reference applications for safety control

  • Introduced a reference Automated Trailer Loading (ATL) application that uses the Safety Core to control a forklift’s safety function based on outside-in perception of humans inside and around the trailer.

Software-in-Loop (SIL) testing support

  • Added end-to-end Software-in-Loop (SIL) testing that validates the Halos Outside-In Safety Blueprint system using Isaac Sim.
  • SIL runs the real VSS Warehouse Operations Blueprint, Safety Event Integrator, Safety Decision Maker, and communication layer against simulated warehouse, forklift, humans, and camera streams to safely exercise safety logic and failure scenarios.

Multi-camera and multi-pipeline fusion

  • Enhanced Safety Event Integrator (SEI) logic to support fusion of events from multiple cameras and redundant perception pipelines.

Outside-In safety with VSS Blueprint

  • Leveraged the VSS Blueprint (Warehouse Operations 2D Vision AI profile) to use RT-DETR-based detection, tracking, and ROI/tripwire analytics as the primary safety perception source.