> This page is for version 1.4.0 (Latest) (default).
> For other versions, use one of these documentation indexes:
> - 1.4.0 (Latest) (default): https://docs.nvidia.com/halos/outside-in-safety/1.4.0/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/halos/outside-in-safety/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/halos/outside-in-safety/_mcp/server.

# SIL Overview

## What is Software-in-the-Loop Testing?

Software-in-the-Loop (SIL) testing validates the Halos Outside-In Safety system using simulation before hardware deployment.

It swaps physical components (warehouse, forklift, cameras) with **virtual equivalents** while running the **actual production software** (AI Perception (VSS), Safety Core, Comm Layer).

### Key Components

The system simulates:

* **Warehouse Environment**: Virtual 20x20m warehouse with loading dock and trailer
* **Forklift Operations**: Autonomous forklift with ROS2 control for loading/unloading
* **Human Workers**: AI-controlled digital humans moving through the workspace
* **Camera Feeds**: Multiple RTSP camera streams from simulation
* **Perception Pipeline**: Real VSS Warehouse Blueprint with RT-DETR detection
* **Safety Logic**: Safety Core for event correlation and decision making

### What is NOT Simulated

These components run as production software:

* **Safety Event Integrator**: Multi-camera sensor fusion
* **Safety Decision Maker**: MUTE/UNMUTE logic for Automated Trailer Loading (ATL), and with `PSF_APP=pxc` or `both` the NORMAL/REDUCE/STOP proximity logic (see [SIL — 3D Perception](/halos/outside-in-safety/testing/sil/sil-3d))
* **Communication Layer**: UDP, OPC UA, and ROS2 protocol translation
* **VSS Warehouse Blueprint**: RT-DETR perception pipeline

This hybrid approach ensures the safety-critical software is validated under realistic conditions.

## Why Use SIL?

### Test Before Hardware Available

Validating safety logic before IGX Thor or physical robots arrive eliminates hardware dependency for software development.

### Faster Iteration

* No physical setup required
* Instant simulation reset
* Quick parameter changes
* Parallel testing scenarios

Key benefits:

* Modify forklift paths in minutes vs. hours of physical setup
* Test 100+ scenarios per day vs. 5-10 with hardware
* No risk of hardware damage during development

### Reproducible Scenarios

The same simulation produces identical results every time, enabling:

* Regression testing: Verify software updates don't break existing functionality
* Performance benchmarking: Measure latency improvements across versions
* Bug reproduction: Replay exact conditions that triggered issues
* Automated testing: Run scenarios in CI/CD pipelines

### Dangerous Scenario Testing

Test scenarios that are unsafe or impractical with real equipment:

* **Near-collision events**: Human enters ROI while forklift is moving at full speed
* **System failure modes**: What happens if perception briefly loses tracking?
* **Edge cases**: Multiple humans entering simultaneously, occlusion scenarios
* **Stress testing**: Maximum forklift speed, minimum reaction times

### Cost-Effective Development

Eliminate expenses associated with hardware testing:

* No robot shipping costs
* No facility rental
* No insurance for physical testing
* No specialized test personnel
* Scale development team without scaling hardware

## Automated Trailer Loading (ATL) Use Case

The default testing harness validates the Automated Trailer Loading scenario. Forklift–person proximity (`PSF_APP=pxc` / `both`) runs on the 3D feed and is described in [SIL — 3D Perception](/halos/outside-in-safety/testing/sil/sil-3d).

### Scenario Description

```text
Warehouse → Loading Dock → Trailer
    ↓
Autonomous forklift loads/unloads pallets
Human workers supervise operations
Overhead cameras monitor safety zones
```

### Safety Logic (MUTE/UNMUTE)

These are the two strings the communication layer logs. Read them as state names, not as
"safety off" and "safety on".

**MUTE (ALLOW OPERATION)**:

* Forklift fully inside trailer
* NO humans detected in Region of Interest (ROI)
* Loading may proceed at higher speed

**UNMUTE (PREVENT OPERATION)**:

* Human detected in ROI (≥1 person)
* Forklift exiting trailer
* Alarm raised; the permission to run at higher speed is withdrawn

The safety system raises an alarm or signals all clear; it does not stop the vehicle. Acting
on the decision is the integrator's responsibility.

### Why This Matters

**Productivity**: Faster movement inside trailers when no humans present. **Safety**: Only when cameras confirm no humans. **Outside-in cameras**: "Guardian angel" view forklift sensors cannot provide.

## Architecture Overview

![SIL Warehouse Architecture](/halos/outside-in-safety/_fern-files/_img/a05c6819020614e677d376fd1e3301d95f131e691b4f88a962383c892f6e5ad7.webp)

The SIL harness consists of four main components:

1. **AI Perception (VSS Warehouse Blueprint)**
   * RT-DETR perception for person and forklift detection
   * ROI (Region of Interest) and Tripwire monitoring
   * Kafka event streaming
   * Must be deployed separately before the core testing harness

2. **Safety Core (PSF)**
   * Safety Event Integrator: Correlates events from multiple cameras
   * Safety Decision Maker: ATL logic (MUTE/UNMUTE commands)
   * Event validation and fusion

3. **Communication Layer**
   * UDP Receiver: Receives commands from Safety Core
   * OPC UA Server: Industrial protocol interface
   * ROS2 Bridge: Publishes to Isaac Sim

4. **Isaac Sim**
   * Warehouse environment simulation
   * Forklift with Action Graph for ROS2 control
   * IRA (Isaacsim.Replicator.Agent) extension for digital human movement
   * Multiple cameras with RTSP output, self-hosted in-process (one server per camera)

### Data Flow

```text
Isaac Sim Cameras (15 FPS RTSP)
     ↓
AI Perception (VSS Warehouse Blueprint)
     ├─ RT-DETR inference
     ├─ Object tracking
     └─ ROI/Tripwire checks
     ↓ Kafka events
Safety Event Integrator
     ├─ Multi-camera fusion
     └─ Event validation
     ↓ Validated events
Safety Decision Maker
     ├─ ATL logic
     └─ MUTE/UNMUTE decision
     ↓ UDP packet (64 bytes)
Communication Layer
     ├─ Protocol translation
     └─ ROS2 publish
     ↓ /safety/is_muted topic
Isaac Sim Action Graph
     └─ Safety indicator (orange/green light)
```

## System Requirements

| Component   | Minimum                | Recommended            |
| ----------- | ---------------------- | ---------------------- |
| **CPU**     | 8 cores                | 16+ cores              |
| **RAM**     | 32 GB                  | 64 GB                  |
| **GPU**     | 5090                   | Pro 6000 Blackwell     |
| **Storage** | 200 GB                 | 200 GB                 |
| **OS**      | Ubuntu 22.04/24.04 LTS | Ubuntu 22.04/24.04 LTS |
| **Network** | 0.5 Gbps               | 1 Gbps                 |

## Next Steps

Ready to get started? Follow these guides:

1. [Prerequisites](/halos/outside-in-safety/getting-started/prerequisites) - Verify hardware and software requirements
2. [SIL — 2D Perception](/halos/outside-in-safety/testing/sil/sil-2d) - Deploy testing harness in 30 minutes
3. [SIL Architecture](/halos/outside-in-safety/testing/sil/architecture) - Deep dive into system design
4. [Isaac Sim Configuration](/halos/outside-in-safety/testing/sil/components/isaac-sim) - Customize Isaac Sim scenes
5. [Overview](/halos/outside-in-safety/testing/srr/overview) - Score the safety decision against ground truth with the **Regression Testing Reporter**