VSS Configurator
Overview
The VSS Configurator manages hardware profile settings and sensor configuration for the Warehouse Operations Blueprint. The Profile Configuration Manager applies deployment-time file changes for the 2d, 3d, and mv3dt modes. The Sensor Configuration Manager then discovers sensors, processes calibration when enabled, publishes configuration events, and registers cameras with VST.
For the service’s configuration reference and API details, see VSS Configurator. This page describes how the service is used in the warehouse blueprint.
System Flow
Profile Inputs
These variables control validation, derived values, and profile-time file changes. Some inputs are also used later by the sensor phase.
Derived Values
Files Changed Operation
File Operation Types
The profile manager dispatches yaml_update, json_update, text_config_update, text_replace, file_management, and recompute_bev_groups operations in blueprint order. Warehouse keep_count is currently disabled.
Files Changed
Common rows apply across modes unless the mode column says otherwise. Paths are repository-relative.
Mode Specific Differences
Hardware Overrides
Hardware profiles define max_streams_supported for each configured mode. Common operations use this ceiling to compute final_stream_count and update the files listed above. IGX-THOR and DGX-SPARK also append hardware-specific file operations after the common operations.
Stream Ceilings by Hardware Profile
For 2d, validation rejects IGX-THOR and DGX-SPARK when BP_PROFILE=bp_wh, even though both hardware blocks contain 2d settings. In 3d, their interval: "1" override runs Sparse4D at an effective 15 FPS; the profile comments specify 30 FPS otherwise.
Hardware Specific File Changes
DeepStream filenames below resolve under ${DS_CONFIG_DIR}. VST filenames resolve under ${VSS_APPS_DIR}/industry-profiles/warehouse-operations/warehouse-<mode>-app/vst/configs/, using the row’s mode. Values are applied after the common file operations; rows that repeat a common setting still show the explicit hardware operation.
Runtime Inputs
These inputs are used by the sensor phase after profile completion. Calibration paths, CALIBRATION_MODE, and sensor-source inputs may also be used by profile-time BEV recomputation as listed above. Most sensor-phase inputs change runtime state or mounted data, not repository configuration files.
Runtime Behavior and Constraints
NUM_STREAMS Contract
- At profile time,
final_stream_countis the requested count capped by the selected hardware limit. It sizes DeepStream and writes NVStreamerdata.nv_streamer_sync_file_count. - At runtime, the sensor manager reads the original
NUM_STREAMSagain. A non-empty NVStreamer list is considered complete whencount >= NUM_STREAMS. - The
>=test is only a readiness gate. IfNUM_STREAMSis 4 and NVStreamer returns 6, the configurator does not take the first four; all six returned groups continue through main-stream and health validation. - The specific video files and their ordering are selected by NVStreamer, not by calibration order. Calibration enriches matching sensor IDs; it does not choose the first N cameras.
- If the hardware cap is lower than
NUM_STREAMS, profile files may be sized for the cap while runtime waits for the original request. A partial non-empty list can proceed afterNVSTREAMER_STREAMS_ENDPOINT_TIMEOUT.
Calibration Freshness
With ENABLE_CALIBRATION_PROCESS=true, the sensor phase obtains calibration by fetch, upload, or mount and uses matching sensor IDs to add group and region metadata. In warehouse 3d, the configurator, VST, DeepStream, Behavior Analytics, and the import container mount the same host calibration file at different container paths. A write becomes visible through those mounts, but an already-running service is not forced to reload it.
In the warehouse 3d and mv3dt profiles, RECOMPUTE_BEV_CENTERS_ENABLED=true enables the profile-time recompute_bev_groups operation. With CALIBRATION_MODE=mount, it validates the configured camera set, recomputes BEV groups, and updates the mounted calibration file before PROFILE_CONFIG_READY_FILE is written. This operation runs before Gunicorn starts the background sensor phase.
Both calibration import containers depend on their configurator becoming healthy through /readyz, which checks profile readiness when profile configuration is enabled. The import scripts also wait for the Video Analytics API before uploading the mounted calibration. Enabled profile-time BEV recomputation therefore finishes before these imports start. Sensor discovery, calibration mapping, VST registration, and SDR publication still run separately in the background sensor phase. Later calibration edits may require a consumer reload or re-import; the startup gate does not trigger those actions automatically.
SDR Publication
When SEND_CONFIG_TO_SDR=true, the configurator publishes one configuration event for each sensor that survived NVStreamer main-stream and health checks. MESSAGE_BROKER_TYPE selects Redis or Kafka; WDM_REDIS_* or WDM_KFK_* supplies the destination and key fields. The event carries camera ID, RTSP URL, region and group when available, and downstream topic metadata. This is separate from the VST camera-add HTTP request. Publish errors are logged and do not make profile readiness fail. Warehouse 2d sets this flag to false; 3d and mv3dt set it to true.
Profile Readiness and VST Startup
The profile readiness marker is a Compose startup gate for dependent services. It means the enabled profile file operations completed successfully, including profile-time BEV recomputation in 3d and mv3dt when enabled. It does not mean sensors were discovered, runtime calibration mapping finished, cameras were added to VST, or SDR received messages. Those actions run later in the background sensor thread.
Decisions and Actions
The Current Behavior column records the implementation behavior. Use the Decision to Record and Suggested Owner columns to guide a configuration review.