Glossary#
- HOISA#
The abbreviation for the NVIDIA Halos Outside-In Safety Blueprint, used sparingly in this documentation where brevity matters. The blueprint extends robot perception beyond on-board sensors by using external infrastructure cameras and AI agents to dynamically control robot behavior and perform at maximum efficiency. Formerly known as PSF (Proactive Safety Framework).
- VSS#
NVIDIA Metropolis Blueprint for video search and summarization (VSS) — A blueprint to build reasoning video analytics AI agents from simple natural language prompts using NVIDIA Metropolis Video Search and Summarization (VSS) skills with coding agents, extracting real-time valuable insights from video data.
- SEI#
Safety Event Integrator — The central component that receives, correlates, and fuses safety events from multiple sources. Formerly known as PSS (Proactive Safety Supervisor).
- SDM#
Safety Decision Maker — The component responsible for translating fused safety events into control actions. Formerly known as PSD (Proactive Safety Decision).
- SBB#
Safety Black Box — The logging and audit trail component that records execution parameters for real-time access and offline analysis. Formerly known as PSB (Proactive Safety Black Box).
- SUI#
Safety User Interface — The user interface component for monitoring and configuration. Formerly known as PSU (Proactive Safety User Interface).
- SIPP#
Sensor Input Processing Pipeline — The AI-based perception data generation component that processes sensor inputs (e.g., camera streams, radar) to identify safety-relevant events.
- SIL#
Software-in-the-Loop — A simulation-based testing methodology that runs the full HOISA software stack against virtual sensor inputs generated by NVIDIA Isaac Sim, enabling end-to-end validation without physical hardware.
- HIL#
Hardware-in-the-Loop — A testing methodology that runs the perception stack and the Safety Core on the target hardware while NVIDIA Isaac Sim supplies the sensor inputs from a separate host, closing the safety loop across the two machines.
- SRR#
The short name of the Regression Testing Reporter, the layer that scores a closed-loop run against NVIDIA Isaac Sim ground truth. It is retained from the tool’s original name, Scenario Recorder + Reporter, and survives in directory names, service names, and the debug viewer, so the commands in the closed-loop testing guides use
srrdirectly.- SAIM#
Safety AI Monitor - The component responsible for monitoring the health of the camera sensor inputs feeding HOISA and producing trust report to SEI.
- PCM#
Perception Container Monitor - The component responsible for assessing perception-pipeline health and reporting
AI_PIPELINE_VALIDorAI_PIPELINE_INVALIDto SEI.- Safety Event#
A structured data object (
SafetyEvent) representing a detected safety-relevant condition, including type, severity, timestamp, confidence level, and fusion metadata.- FusedSafetyEvent#
The output of the SEI fusion process. Contains the original event data plus a
SafetyEventStatus(FUSED, PASSTHROUGH, STALE, or UNKNOWN) indicating the fusion outcome.- Event Fusion#
The process of correlating and combining safety events from multiple sources — temporal, spatial, or attribute-based — to improve confidence and reduce false positives.
- FSI#
Functional Safety Island — A hardware-isolated compute environment on NVIDIA Tegra platforms for safety-critical operations.
- fsicom-agent#
The host-side bridge that connects an FSI-hosted Safety Decision Maker to the NvPSD Gateway on the CCPLEX, and optionally relays the decisions coming back from the FSI to a command receiver over UDP. It ships in
psf-tegra-fsiand replaces the CCPLEX SDM binary in SDM-on-FSI mode.- nvFsiCom#
The platform daemon that owns FSI communication through
/dev/fsicom_client. It is not part of HOISA;fsicom-agentcannot initialize its FSI channel until this daemon is running.- SW_FAIL#
Software Failure event — A special event type indicating a malfunction in the safety software stack that compromises the safety control path.
- PSSCom#
A high-performance, NVIDIA proprietary communication library for packet streaming between source and sink endpoints within HOISA.
- ROI#
Region of Interest — A user-defined spatial zone in the camera view used to monitor occupancy and trigger safety events when objects enter or exit.
- Tripwire#
A virtual line placed in the camera view (e.g., at doors or aisle boundaries) that triggers directional crossing events when objects pass through it.
- ATL#
Automated Trailer Loading — A reference application in HOISA that involves the control of forklift safety functions during trailer loading and unloading operations.
- DecisionRequest#
The data structure sent from SEI to SDM containing fused safety events, sensor health status, and system status for safety decision processing.
- DecisionResponse#
The data structure returned by SDM containing the recommended action, decision identifier, and confidence level.
- L4T#
Linux for Tegra — NVIDIA’s Linux distribution for Tegra-based platforms (e.g., IGX Thor). HOISA runs in L4T user space on these systems.
- CCPLEX#
CPU Complex — The main CPU subsystem on NVIDIA Tegra SoCs where HOISA user-space components execute.
- NGC#
NVIDIA GPU Cloud — The registry and CLI used to download HOISA Debian packages, Docker images, and VSS deployment resources.
- VST#
Video Storage Toolkit — The VSS component that ingests and re-streams camera feeds. SAIM reads its RTSP URLs, and the reference command receivers can relay decision packets to it for on-screen display.
- MDX#
Metropolis Data eXchange — The Kafka topic family (
mdx-events,mdx-frames) that VSS publishes perception output on, and the source of themdx_clientname.- DVM#
Decoded Video Metrics — The per-pipeline decode statistics the Perception Container Monitor baselines and then compares against at runtime to judge AI pipeline health.
- PVA#
Programmable Vision Accelerator — The vision accelerator on IGX and Tegra platforms. SAIM uses it as its backend on aarch64, where the GPU backend is used on x86-64.
- NVDEC#
NVIDIA Video Decoder — The hardware video-decode engine SAIM uses to decode camera streams for its integrity checks.
- safety_monitor#
The SAIM process binary. Runs in
learnmode to capture per-sensor baselines and inactivemode to issueSENSOR_VALID/SENSOR_INVALIDverdicts.- nv_perception_monitor#
The PCM process binary. Assesses AI perception pipeline health and reports
AI_PIPELINE_VALID/AI_PIPELINE_INVALID.- PLC#
Programmable Logic Controller — The external controller that receives decision commands from the SDM and acts on the machine under control. In the reference applications this role is played by the command receiver, and SDM log messages use “PLC” for the endpoint that requests a safe release.
- PSF#
Proactive Safety Framework — The former name of the blueprint. It survives in package names (
psf-desktop,psf-tegra), the install prefix/opt/nvidia/psf, and the log directory/var/log/psf.- PSS#
Proactive Safety Supervisor — The former name of SEI. It survives in the daemon binary
nvpss_daemonand its configuration filenvpss.conf.- PSD#
Proactive Safety Decision — The former name of SDM. It survives in the gateway binary
nvpsd_gatewayand in the SEI-to-SDM transport settings (for examplePSSDToPSDComBackend).- PSB#
Proactive Safety Black Box — The former name of SBB.
- PSU#
Proactive Safety User Interface — The former name of SUI.
- nvpss_daemon#
The SEI daemon process. It receives safety events from event ingestion and trust reports from SAIM and PCM, fuses them, and issues
DecisionRequestmessages toward the SDM. Readsnvpss.conf.- nvpsd_gateway#
The gateway process that carries
DecisionRequestandDecisionResponsetraffic between the SEI daemon and the SDM, whether the SDM runs on the CCPLEX or on the FSI, with heartbeat supervision of the link.- mdx_client#
The event-ingestion process. It consumes VSS Kafka topics (
mdx-events,mdx-frames), translates messages intoSafetyEventrecords using the event-mapping configuration, and reports them to the SEI daemon.- psf-desktop#
The Debian package carrying x86-64 application binaries and libraries. Companion packages are
psf-tegra(aarch64), the matching-devpackages for headers and makefiles, andpsf-tegra-fsifor FSI firmware and thefsicom-agenthost bridge.