Version 1.0 — April 2026
Author: STS Gym Research — stsgym.com
VIMI (VIMI Integrated Mission Infrastructure) is a DoD-aligned mission processing framework that integrates satellite-based infrared (IR) sensor data, multi-source track fusion, missile warning workflows, and federated simulation interoperability into a single, deployable system. Built on 10 Go-based microservices orchestrated in Kubernetes, VIMI processes SBIRS/NG-OPIR satellite sightings through a streaming Kafka pipeline to generate real-time threat tracks and alert levels in accordance with CONOPREP doctrine. The system bridges live assets, virtual simulators, and constructive (AI-generated) entities via DIS (IEEE 1278.1) and HLA (IEEE 1516-2010) protocols, enabling multi-federation joint training scenarios.
This paper describes VIMI's architecture, deployment methodology, current operational status, and a roadmap for completing the system's transition to a fully operational training and mission processing platform.
Modern DoD simulation-based training requires interoperability across geographically distributed systems, combining real-world sensor feeds (live), operator-driven simulations (virtual), and AI-generated entities (constructive) into unified training events. This LVC (Live/Virtual/Constructive) architecture is essential for exercises such as Ulchi-Freedom Guardian, which involve joint and coalition forces.
Current DoD mission processing systems — including Raytheon's FORGE MDPAF (Mission Data Processing Application Framework) for OPIR satellite data — provide a reference model for how infrared satellite data flows from sensor to warfighter. VIMI replicates and extends this model as an open training platform.
VIMI serves two primary purposes:
VIMI is currently deployed on a Kind (Kubernetes in Docker) cluster running on a single development server. All 10 microservices are operational, the Kafka pipeline is live, and Prometheus monitoring is active for all services. The system generates simulated satellite sightings at configurable intervals, producing threat tracks and CONOPREP-level alerts within the pipeline.
This paper documents VIMI v1.0 as of April 2026.
VIMI is built as a distributed microservices system in Go 1.22, containerized with Docker, and orchestrated in Kubernetes. Services communicate via Apache Kafka for asynchronous event streaming and HTTP/REST for synchronous queries.
┌─────────────────────────────────────────────────────────────┐
│ SBIRS / NG-OPIR Satellites │
└───────────────────────┬─────────────────────────────────────┘
│ IR Sighting Data
▼
┌─────────────────────────────────────────────────────────────┐
│ opir-ingest :8081 │
│ Ingests IR sightings, simulates satellite positions, │
│ publishes EntityStatePDUs + SightingEvents to Kafka │
└───────────────────────┬─────────────────────────────────────┘
│ vimi.opir.sightings (Kafka)
▼
┌─────────────────────────────────────────────────────────────┐
│ missile-warning-engine :8080 │
│ Kalman filter trajectory estimation, threat classification │
│ (SRBM/MRBM/IRBM/ICBM), impact point prediction │
│ → MissileTrack objects published to vimi.missile.tracks │
└───────────────────────┬─────────────────────────────────────┘
│ vimi.missile.tracks (Kafka)
▼
┌─────────────────────────────────────────────────────────────┐
│ sensor-fusion :8082 │
│ JPDA (Joint Probabilistic Data Association) │
│ Multi-sensor track correlation, track ID management │
│ → FusedTrack objects to vimi.tracks.fused │
└───────────────────────┬─────────────────────────────────────┘
│ vimi.tracks.fused (Kafka)
▼
┌─────────────────────────────────────────────────────────────┐
│ alert-dissemination :8084 │
│ CONOPREP → IMMINENT → INCOMING → HOSTILE alert levels │
│ C2 message formatting, JTIDS net assignment │
│ NCA/Pentagon/SOCOM notification routing │
└───────────────────────┬─────────────────────────────────────┘
│ vimi.alerts (Kafka)
▼
┌─────────────────────────────────────────────────────────────┐
│ lvc-coordinator :8083 │
│ DIS Entity State PDU management, dead reckoning (FOM) │
│ Live/Virtual/Constructive entity split, force tracking │
└───────────────────────┬─────────────────────────────────────┘
│
┌──────────────┴──────────────────────────────────┐
│ │
▼ ▼
┌────────────────────────────┐ ┌────────────────────────────┐
│ env-monitor :8085 │ │ replay-engine :8086 │
│ 1° global environmental │ │ DIS PDU recording to │
│ grid, cloud/precip/wind │ │ .dispcap files, playback │
│ SBIRS/AWACS/PATRIOT rating │ │ catalog API │
└────────────────────────────┘ └─────────────────────────────┘
│ │
└──────────────────────┬─────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ data-catalog :8087 │
│ OGC CSW (Catalogue Service Web), REST API │
│ Track/alert/recording discovery, keyword/BBox filtering │
└───────────────────────┬─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ dis-hla-gateway :8090 │
│ DIS ↔ HLA bidirectional translation │
│ EntityStatePDU / FirePDU / DetonationPDU │
│ HLA OMT class mapping, ECEF ↔ WGS84 conversion │
│ Kafka topics: vimi.hla.* ↔ vimi.dis.* │
└───────────────────────┬─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ vimi-plugin :8091 │
│ CICERONE web UI integration │
│ Globe display (tracks/alerts/env), command API │
│ Commands: vimi status/tracks/alerts/lvc/env/inject/globe│
└─────────────────────────────────────────────────────────────┘| Component | Minimum | Production |
|---|---|---|
| Compute | 4 cores, 8GB RAM | 16+ cores, 32GB+ RAM |
| Kubernetes | Kind (single node) | Multi-node K8s cluster |
| Kafka | 1 broker | 3-broker KRaft cluster |
| Storage | 20GB | 100GB+ (replay/events) |
| Network | 1 Gbps | 10 Gbps (federation) |
The complete VIMI system is contained in a single git repository:
trooper-vimi/
├── VIMI-FOM/FOM.xml # HLA Federation Object Model
├── dis-pdu/REGISTRY.md # DIS PDU type registry
├── apps/ # 10 microservice directories
│ ├── opir-ingest/ # Satellite data ingestion
│ ├── missile-warning-engine/ # Threat detection + tracking
│ ├── sensor-fusion/ # Multi-source track fusion
│ ├── alert-dissemination/ # Alert level management
│ ├── lvc-coordinator/ # Entity state + force tracking
│ ├── env-monitor/ # Environmental grid monitoring
│ ├── replay-engine/ # Event recording + playback
│ ├── data-catalog/ # OGC CSW discovery service
│ ├── dis-hla-gateway/ # DIS↔HLA translation
│ └── vimi-plugin/ # CICERONE UI integration
├── k8s/vimi-cluster/ # Kubernetes manifests
├── cicerone-scripts/ # CICERONE CLI extensions
├── scripts/ci/ # CI/CD runner registration
└── docs/VIMI-INSTALL-GUIDE.md # Deployment guidePurpose: Simulates infrared (IR) satellite sensor data from SBIRS (Space-Based Infrared System) and Next-Generation OPIR satellites. Generates realistic missile launch signatures with configurable false-alarm rates.
Inputs: Configuration (satellite constellation, sensor modes, DIS exercise ID)
Outputs:
vimi.opir.sightings (Kafka) — IR sighting eventsvimi.dis.entity-state (Kafka) — DIS Entity State PDUs for satellite positionsKey Features:
DoD Alignment: Replicates the SBIRS mission processing chain described in Raytheon's FORGE MDPAF architecture.
Purpose: The core threat processing engine. Receives IR sightings and produces missile track objects with trajectory estimation, missile type classification, and impact point prediction.
Inputs: vimi.opir.sightings (Kafka)
Outputs:
vimi.missile.tracks (Kafka) — Threat track objects/health, /metrics (HTTP) — Health + Prometheus metricsKey Features:
DoD Alignment: Implements trajectory estimation algorithms consistent with actual missile defense system (MDS) processing, aligned with C2BMC (Command and Control Battle Management) threat track data models.
Purpose: Correlates sightings and tracks from multiple sensors (SBIRS, AWACS, PATRIOT, THAAD, naval SPY) into a unified operational track picture. Implements JPDA (Joint Probabilistic Data Association) for ambiguous association scenarios.
Inputs: vimi.opir.sightings, vimi.missile.tracks (Kafka)
Outputs: vimi.tracks.fused (Kafka) — FusedTrack objects with composite confidence scores
Key Features:
Purpose: Issues threat alerts following CONOPREP (Condition of Probable Warfighting/Hostile Action) doctrine. Formats and routes C2 messages to appropriate command authorities.
Alert Levels:
| Level | Criteria | Notification |
|---|---|---|
| CONOPREP | Track initiated, TTA > 0 min | Unit commanders |
| IMMINENT | Impact predicted < 15 min | Theater C2 |
| INCOMING | Impact predicted < 10 min | Theater C2 + Air Defense |
| HOSTILE | Track confirmed, NCA approval | NCA + STRATCOM |
Inputs: vimi.tracks.fused (Kafka)
Outputs:
vimi.alerts (Kafka) — Alert eventsKey Features:
Purpose: Manages the Live/Virtual/Constructive entity registry. Maintains a unified entity state table for all tracks in the exercise, regardless of origin.
Inputs: All track Kafka topics, replay events
Outputs: vimi.entities (Kafka), DIS Entity State PDUs
Entity Types:
Key Features:
Purpose: Maintains a 1° resolution global environmental grid (180×360 cells). Models atmospheric conditions affecting IR sensor performance.
Grid Layers:
Sensor Performance Ratings: Each cell computes effective detection range for:
Purpose: Records all DIS PDU events and VIMI track/alert data to disk for post-exercise analysis and playback.
Recording Format: .dispcap — custom format wrapping standard DIS PDUs with VIMI metadata headers.
Capabilities:
Purpose: Provides an OGC CSW (Catalogue Service for the Web) interface for discovering VIMI assets — tracks, alerts, recordings, and environmental data.
Standards Compliance:
Asset Types: Tracks, Alerts, Recordings, Environmental Snapshots, FOM Documents
Purpose: Bidirectional translation bridge between DIS (IEEE 1278.1) and HLA (IEEE 1516) federations.
Translation Layer:
HLA Class Mapping:
HLAobjectRoot.Platform ←→ DIS EntityStatePDU
HLAobjectRoot.Fire ←→ DIS FirePDU
HLAobjectRoot.Detonation ←→ DIS DetonationPDU
HLAinteractionRoot.Fire ←→ DIS FirePDU
HLAinteractionRoot.StateUpdate ←→ DIS EntityStatePDUNote: Currently operates without a live RTI (Run-Time Infrastructure). The hla-bridge process connects to Kafka topics vimi.hla. and vimi.dis., translating messages bidirectionally. Integration with a live RTI (Portico, Mak) is planned for Phase 4.
Purpose: Provides the VIMI command-and-control interface within the CICERONE web application.
Commands:
vimi status — System health and pipeline status
vimi tracks — Active threat tracks with details
vimi alerts — Current alert levels
vimi lvc — LVC entity breakdown
vimi env — Environmental grid summary
vimi inject <type> — Inject synthetic scenario events
vimi globe — Open 3D globe display with tracks
vimi recording start/stop — Control DIS PDU recording
vimi federation — DIS/HLA federation peer status
vimi cluster — Kubernetes cluster status| Topic | Publisher | Subscribers | Description |
|---|---|---|---|
vimi.opir.sightings | opir-ingest | missile-warning-engine | Raw IR detections |
vimi.missile.tracks | missile-warning-engine | sensor-fusion, alert-dissemination | Threat tracks |
vimi.tracks.fused | sensor-fusion | alert-dissemination, lvc-coordinator | Correlated tracks |
vimi.alerts | alert-dissemination | lvc-coordinator, vimi-plugin | Alert events |
vimi.entities | lvc-coordinator | dis-hla-gateway | Entity state table |
vimi.env.events | env-monitor | (internal) | Environmental changes |
vimi.hla.inbound | HLA RTI | dis-hla-gateway | HLA interactions |
vimi.hla.outbound | dis-hla-gateway | HLA RTI | Translated HLA interactions |
vimi.dis.inbound | DIS net | dis-hla-gateway | Raw DIS PDUs |
vimi.dis.outbound | dis-hla-gateway | DIS net | Translated DIS PDUs |
All 10 VIMI services expose /metrics endpoints using github.com/prometheus/client_golang. A ServiceMonitor in the forge-monitor namespace watches all services labeled app=vimi across all namespaces.
Key Metrics:
| Service | Metrics |
|---|---|
| missile-warning-engine | vimi_tracks_total, vimi_tracks_active, vimi_alerts_total, vimi_alerts_active{level}, vimi_sightings_processed, vimi_kafka_consumer_lag |
| alert-dissemination | vimi_alerts_received_total, vimi_alerts_issued_total, vimi_alerts_active, vimi_nca_approvals_total, vimi_jtids_messages_total |
| All services | vimi_kafka_messages_sent_total{topic}, vimi_kafka_messages_received_total{topic}, vimi_errors_total |
Alert Rules (PrometheusRule vimi-alerts):
VIMINoActiveTracks — No tracks for 5 minutesVIMIHostileTrack — HOSTILE track active > 1 minuteVIMIAlertImminent — IMMINENT alert active > 30 secondsVIMIAlertIncoming — INCOMING alert active > 10 secondsVIMIAlertHostile — HOSTILE alert active > 5 secondsVIMIServiceDown — Service endpoint down > 2 minutes# Clone the repository
git clone https://YOUR_GITLAB/trooper-vimi.git
cd trooper-vimi
# Build all container images
for app in apps/*/; do
docker build -t vimi/$(basename $app):latest -f $app/Dockerfile $app
done
# Load images into Kind
for app in apps/*/; do
kind load docker-image vimi/$(basename $app):latest --name gms
done
# Deploy to Kubernetes
kubectl apply -f k8s/vimi-cluster/vimi-cluster.yaml
kubectl apply -f k8s/vimi-cluster/vimi-monitoring.yaml
# Verify
kubectl get pods -n vimiFull deployment guide: docs/VIMI-INSTALL-GUIDE.md
A complete GitLab CI/CD pipeline (.gitlab-ci.yml) automates the build → test → publish → deploy workflow:
build → test → security-scan → publish → deploy-k8sThe pipeline uses a Docker executor runner with DinD (Docker-in-Docker) support. Images are pushed to a configurable registry (default: local darth:5000).
As of April 2026, VIMI has been deployed on a Kind/Kubernetes cluster. All 10 services are running:
| Service | Status | Restarts | Notes |
|---|---|---|---|
| opir-ingest | Running | 1 | Simulating satellite sightings |
| missile-warning-engine | Running | 1 | Active threat tracks |
| sensor-fusion | Running | 1 | Multi-source correlation |
| alert-dissemination | Running | 1 | Alert levels: CONOPREP, IMMINENT |
| lvc-coordinator | Running | 1 | Entity state management |
| env-monitor | Running | 1 | Global environmental grid |
| replay-engine | Running | 1 | DIS PDU recording available |
| data-catalog | Running | 1 | OGC CSW discovery |
| dis-hla-gateway | Running | 1 | DIS↔HLA bridge (no live RTI) |
| vimi-plugin | Running | 1 | CICERONE UI integration |
Kafka Pipeline: ACTIVE — opir-ingest is producing simulated IR sightings; missile-warning-engine is detecting MRBM-class threats and issuing CONOPREP/IMMINENT alerts; sensor-fusion is correlating multi-sensor data.
Prometheus: All 10 services are being scraped. Live metrics show vimi_tracks_active=8, vimi_alerts_active{CONOPREP}=1, vimi_alerts_active{IMMINENT}=7.
The following items are required to take VIMI from a development/simulation environment to an operational training platform:
Effort: <1 hour
Status: Runner installed on darth; needs registration token from GitLab UI
The GitLab runner is installed and configured with Docker executor. A registration token from https://idm.wezzel.com/crab-meat-repos/trooper-vimi/-/settings/ci_cd is required to activate it. Once registered, all pushes to master will automatically build, test, and deploy VIMI.
Effort: 2–4 weeks
Status: dis-hla-gateway translates DIS↔HLA but does not connect to a live RTI
The dis-hla-gateway service uses Kafka topics for DIS↔HLA translation but currently operates without a Run-Time Infrastructure. Connecting to Portico or Mak will enable full HLA federation participation with other RTI-based simulators.
Options:
Effort: 4–8 weeks
Status: Not started
Multi-level security requires a cross-domain solution (CDS) to allow VIMI to operate at multiple classification levels simultaneously. Options include:
Effort: 4–8 weeks
Status: opir-ingest simulates SBIRS data
Replacing simulated data with actual SBIRS mission data feeds requires:
Effort: 2–3 weeks
Status: vimi-plugin provides command API; globe rendering not yet connected
The vimi-plugin exposes track and alert data via HTTP API. Connecting this to the CICERONE globe component ( Cesium-based 3D terrain visualization) requires:
Effort: 3–6 weeks
Status: alert-dissemination formats JTIDS messages but does not transmit
The alert-dissemination service formats JTIDS net assignment messages for Link 16. Full integration requires:
Effort: 6–12 weeks
Status: Single Kind cluster
For coalition training involving multiple geographically distributed sites:
Effort: 4–8 weeks
Effort items:
| Standard | Description | VIMI Implementation |
|---|---|---|
| IEEE 1278.1-2012 | DIS (Distributed Interactive Simulation) | dis-pdu/ registry, lvc-coordinator |
| IEEE 1516-2010 | HLA (High Level Architecture) | VIMI-FOM/FOM.xml, dis-hla-gateway |
| OGC CSW 2.0.2 | Catalogue Service for the Web | data-catalog service |
| ISO 23950 | Z39.50 search protocol | data-catalog service |
| DIS Exercise ID | Protocol version 7 | All DIS PDUs |
| HLA OMT | Object Model Template | 12 object classes, 11 interactions |
| SBIRS MDPAF | Mission Data Processing | opir-ingest (functional analog) |
VIMI provides a fully functional, deployable LVC mission processing framework demonstrating DoD-aligned simulation and mission data processing workflows. The system is production-ready at the component level — all 10 services are operational, the Kafka pipeline is live, and Prometheus monitoring is active. The primary gaps to operational deployment are runner registration (trivial), HLA RTI integration (moderate), and cross-domain security architecture (substantial).
The system serves as both a training platform for missile warning workflows and a reference implementation for building DoD-compliant LVC federation infrastructure.
VIMI is an STS Gym Research project. Repository: github.com/vimic/vimi
Contact: stsgym.com | wlrobbi@stsgym.com