ASPEN Demo Playbook

Key Messages for Leadership

• ASPEN is a digital ocean — a physically accurate simulation of underwater vehicles and their operating environment
• Built on NVIDIA's latest platform — the same technology powering autonomous cars and digital twins
• Simulates real vehicles (REMUS, BlueROV2) with real ocean data from NOAA and Navy models
• Enables research at scale: fleet coordination, AI training, and mission rehearsal
• NPS will be the first Navy command with DGX GB300 — ASPEN is a flagship use case
• The portable demo runs on a single laptop; the same code scales to supercomputer for full research campaigns

Hardware & Environment

• Alienware laptop fully charged, power adapter accessible
• Ubuntu booted (not Windows)
• Isaac Sim installed and verified — run nvidia-smi, confirm CUDA version
• ASPEN scenarios tested within the last 24 hours
• C2 UI running in Chrome (npm run dev)
• External display connected and tested (if presenting to a room)

Backup & Timing

• Screen recording of a successful demo run saved as backup (in case of hardware failure)
• Plan for 10–15 minutes of demo with 5 minutes of Q&A

What Is It?

The ASPEN Command & Control UI is a professional-grade operational interface — a single-page web application built on React 19, TypeScript, Mapbox GL, and deck.gl. It was designed from the ground up to look, feel, and function like the kind of interface a Navy operator would use in a real mission environment. It is not a debug tool or a research dashboard bolted on top of a simulation. It is an operationally realistic front end that demonstrates what full-stack autonomous undersea operations would look like.

The interface runs in any modern browser and connects to the ASPEN simulation backend via a REST API and WebSocket stream. During the demo it runs against a high-fidelity mock backend that returns realistic data, correct data types, and real-time telemetry updates — indistinguishable from a live connection.

Why It Matters for the Demo

Simulation engines are hard for non-engineers to evaluate. Isaac Sim is powerful, but a raw 3D viewport with vehicle meshes and telemetry logs does not communicate operational value to a commander, program manager, or decision-maker. The C2 UI translates the simulation into the language of operations.

When an audience sees a mission being planned on a real nautical chart, watches multiple vehicles execute autonomously, sees a comms degradation alert fire in real time, and then reviews the deviation analysis — they understand what ASPEN enables. The C2 UI is the argument that this platform is operationally relevant, not just technically interesting.

Four Modes — Four Phases of Operations

Key Features to Highlight

• Operational realism — Classification banner (UNCLASSIFIED / SECRET / TOP SECRET) renders on every screen. MIL-STD-2525D symbology for all vehicles and overlays. This is the visual vocabulary of naval operations.
• Map-centric design — The Mapbox GL / deck.gl viewport is the primary workspace, not a secondary view. All planning, monitoring, and analysis happens in the geographic context where operations occur.
• Multi-vehicle fleet management — Supports concurrent vehicles with independent telemetry, sensor configurations, and autonomy states. Each vehicle card shows battery, comms health, depth, speed, and current behavior.
• Environmental awareness — Eight toggleable oceanographic layers: bathymetry, currents, temperature, salinity, sound velocity, wave height, ice coverage, and visibility. Each has configurable warning and critical thresholds that fire alerts during operations.
• Sound velocity profiling — Real-time SVP chart for any geographic position, showing the thermocline structure that governs acoustic sensor performance. Directly relevant to sonar operations.
• Mission validation — Before execution, the system validates waypoint count, depth constraint compliance, vehicle assignment, battery feasibility, and communications coverage. Validation results are color-coded by severity.
• Integration-ready architecture — The entire API surface is defined and contracted. Swapping the mock backend for a live ASPEN simulation requires implementing one TypeScript class. No component changes. No type changes. The interface was built for this.