AI‑Powered Underwater Simulation: Autonomous Perception, Decision & Execution

Three‑Layer Decision Architecture

The intelligent decision‑making pipeline for an unmanned underwater vehicle (UUV) is organized into three layers that mirror human cognition:

Semantic Layer ("What the decision means") – receives a high‑level Decision Message (e.g., “carpet‑scan area A for pipeline leaks”). It performs:

Intent parsing with large‑model‑based structured semantic parsing to classify the decision, extract parameters and identify constraints.

Ontology reasoning using OWL or a graph database to map concepts, infer relationships and trigger rules.

Strategy generation that combines large‑model outputs with rule‑based logic to produce goal decomposition, path planning and resource‑matching plans.

Conflict detection that checks logical consistency, temporal feasibility and value compatibility.

Output: Semantic Execution Contract (SEC) containing formal goal descriptions, ordered high‑level strategies and global constraints. Typical scenarios: task planning & replanning to maximize coverage while minimizing energy consumption; multi‑objective priority ranking (e.g., formation keeping vs. temperature‑anomaly detection).

Dynamic Layer ("How the decision moves") – translates the SEC into an executable action schedule.

Behavior orchestration: decomposes strategies into atomic actions, orders dependencies and handles conditional branches.

Temporal coordination: timestamps plans, identifies parallel tasks, sets synchronization points and defines timeout policies.

Resource scheduling: acts as a resource manager and conflict arbitrator, allocating resources, resolving conflicts and managing reservations.

Anomaly prediction: builds risk models, generates fallback plans and defines degradation paths.

Output: Dynamic Execution Plan (DEP) with atomic action sequences, timing triggers, resource‑usage tables and exception branches. Typical scenarios: dynamic path planning around moving obstacles while exploiting favorable currents; target verification with sensor‑parameter adjustments.

Kinetic Layer ("How the decision becomes physical motion") – converts the DEP into low‑level control commands.

Kinematic conversion: trajectory generation, route interpolation and inverse dynamics solving.

Controller synthesis: generates PID, MPC or adaptive‑gain controllers based on parameters.

Real‑time feedback: state estimators and error calculators provide state estimation, error correction and disturbance compensation.

Safety hard protection: enforces hard limits on depth, speed and emergency braking.

Output: Physical Control Instruction (PCI) specifying thruster speeds/angles, rudder settings, buoyancy adjustments and sensor switch signals. Typical scenarios: millisecond‑level emergency surfacing or evasive maneuvers when obstacle distance falls below a safety threshold; precise trajectory tracking against ocean currents.

Human‑Machine Collaborative Decision System

Decision Quadrant Matrix

Decisions are classified by time urgency and information certainty into four quadrants:

Reflex layer (<10 ms, fully autonomous) – hard‑coded finite‑state machine (FSM).

Emergency layer (<100 ms, rule‑constrained autonomous) – boundary‑inside autonomy.

Tactical layer (seconds‑minutes, human‑in‑the‑loop) – AI recommendation + human authorization.

Strategic layer (minutes‑hours, human‑in‑the‑loop) – human‑led.

Six‑Level Human‑in‑the‑Loop Model

Each level defines the proportion of human involvement, AI authority and typical mission scenarios:

L0 – Fully Human‑Controlled : 100 % human, AI display‑only; e.g., final weapon‑release confirmation.

L1 – Human‑Dominated : pre‑decision confirmation, AI generates plans, human selects; e.g., mission planning and route approval.

L2 – Human‑in‑the‑Loop : real‑time supervision, interruptible; AI executes autonomously, human can veto; e.g., target tracking, area search.

L3 – Human‑on‑the‑Loop : post‑action review; AI decides autonomously, reports afterwards; e.g., avoidance, energy management, communication scheduling.

L4 – Supervised Autonomy : exception takeover; AI fully autonomous with alerts; e.g., fault reconstruction, emergency surfacing.

L5 – Fully Autonomous : no human involvement, full AI authority; e.g., emergency self‑destruct, survival‑first maneuvers.

Scenario‑based level mapping (selected examples):

Routine route planning (L3) : global path optimization (A*/RRT*) with human approval of the initial plan.

Real‑time obstacle avoidance (L4) : dynamic obstacle avoidance (VFH+/DWA) with post‑action audit.

Energy‑crisis handling (L4→L5) : dynamic power budgeting and early return without human input.

Emergency surfacing (L5) : hard‑logic survival‑first ascent.

Self‑destruct (L0/L1) : human‑confirmed execution only.

Intelligent Decision Conflict Resolution

Predictive Conflict Matrix

Trajectory prediction (0‑300 s, high certainty): kinematic model, accuracy > 0.9.

Behavior prediction (1‑10 min): HMM / neural network, accuracy 0.7‑0.9.

Task prediction (10‑60 min): template‑based, accuracy 0.5‑0.7.

Intent prediction (> 1 h): game‑theoretic / Bayesian, accuracy < 0.5.

Conflict Types and Difficulty

Competitive – two UUVs lock the same target (zero‑sum game). Difficulty: ★★★.

Resource – contention for communication windows, weapons or energy (constraint optimization). Difficulty: ★★☆.

Information – contradictory sensor data (cognitive inconsistency). Difficulty: ★★★★.

Strategy – divergent tactics such as encirclement vs. tracking (value‑function divergence). Difficulty: ★★★★★.

Physical – trajectory crossing or collision risk (spatio‑temporal overlap). Difficulty: ★★☆.

Communication – simultaneous acoustic channel contention (bandwidth competition). Difficulty: ★★☆.

Deadlock‑Avoidance Principles (Seven Rules)

Determinism first : prefer complete rule sets over negotiation; rules must fully cover cases and have explicit priority.

Unidirectional dependency : design task dependencies as a single‑direction chain; information flows upstream; command hierarchy is a tree.

Forced progress : limit negotiation rounds; each round must yield a substantive concession; after exhaustion, enforce a decision.

Information transparency : mandatory sharing of key data; forced arbitration on disagreements; all parties must accept the final ruling.

Role pre‑allocation : assign unique responsible roles before execution; immediate arbitration on conflict.

Value alignment : synchronize value functions before tasks; intersect to find common ground; if impossible, report to human.

Timeout fallback : every wait has a timeout; timeout triggers a defined fallback action; no return to the original negotiation.

Decision Message Structure & State Machine

Message Body (9 Modules)

Header – ID, type, sender, timestamp, TTL, priority, security level, signature.

Decision ontology – ID, type, name, target object, execution parameters, constraints.

Execution commands – sequence, type, target values, execution mode, trigger conditions, fallback commands.

Spatio‑temporal context – validity period, execution area, coordinate system, waypoints, time windows.

Resource requirements – energy budget, sensor/weapon/communication/computation needs.

Dependencies – prerequisite decisions, cooperating UUVs, information/environment dependencies, human authorizations.

Expected results – success criteria, completion judgment, information output, value assessment.

Exception handling – interrupt level, timeout handling, failure fallback, degradation mode, emergency abort.

Metadata – decision source, reasoning chain, confidence, alternative plans, version, audit log.

Decision Lifecycle State Machine

Core states:

PENDING → READY → RUNNING

Possible branches:

BLOCKED – waiting for a condition, resumes when satisfied.

SUSPENDED – state saved, later resumed.

PREEMPTED – higher‑priority decision overrides current one.

Termination paths:

COMPLETED – normal finish.

ABORTED – forced termination.

EXPIRED – timeout or validity loss.

Execution Interrupt Levels (I0‑I5)

I0 – Atomic non‑interruptible : never interruptible; full state saved; automatic recovery; e.g., weapon firing sequence, emergency surfacing.

I1 – Safety‑critical non‑interruptible : only higher‑safety level can pre‑empt; full state saved; automatic recovery; e.g., avoidance maneuver, bottom‑hold program.

I2 – Pause‑able, non‑preemptible : can pause and resume later; full state saved; automatic recovery; e.g., sensor calibration, communication handshake.

I3 – Preemptible with restore : can be preempted, must save state; conditional restore; e.g., area search, target tracking.

I4 – Preemptible, discardable : can be preempted, state discarded; re‑triggered later; e.g., routine inspection, data logging.

I5 – Always overridable : new decision overwrites without saving; restart from scratch; e.g., heading tweak, speed adjustment.

Semantic Map: From "How to Go" to "Why to Go"

A semantic map enriches raw sensor detections with meaning. Example: a sonar echo at 300 m is interpreted not merely as an obstacle but as a "hydrothermal vent"—a scientific target—prompting the UUV to approach rather than avoid. This enables mission‑aligned decisions such as using a thermocline as acoustic camouflage while navigating toward the vent.

Data Foundation and Technology Stack

Data Acquisition & Generation

Real data collection : Deploy multi‑sensor UUVs in controlled waters to gather synchronized multimodal data (sonar, camera, IMU, depth, chemical sensors) with ground‑truth labels; collaborate with research institutes, offshore wind farms and pipeline operators; apply domain transfer from land data to underwater fine‑tuning.

Simulation data generation : Use UE5, Isaac Sim, etc., to model underwater physics (optical attenuation, scattering, bioluminescence, acoustic propagation, multipath, reverberation, currents, turbulence). The simulator provides zero‑cost, automatically labeled massive datasets.

Data Processing & Annotation

Pre‑annotation with pretrained models.

Human‑machine collaborative refinement where operators correct and confirm pre‑annotations.

Cross‑ontology data migration for sensor‑configuration changes via transfer learning.

Cleaning (removing noisy or faulty samples) and augmentation (rotation, scaling, noise injection, lighting changes).

Data Management & Storage

Unified data lake with global namespace : All real and simulated data stored logically in a lake, accessed transparently across local servers, edge nodes and cloud, eliminating storage silos.

Scenario‑based dataset organization : Tag and classify by task (cable inspection, vent detection, dam inspection) and environmental difficulty (clear vs. turbid, strong currents).

Edge‑to‑cloud sync : Data collected on‑board is stored locally; after surfacing it is incrementally synced to the cloud where trained models are distributed back to edge devices.

Data Warehouse Architecture

Base data – Doris / RAG / MinIO for weapons, equipment, environment, tactics, semantic templates.

Ontology data – OWL for logical relationships in combat scenarios.

Simulation data – Protobuf for structured simulation payloads.

Graph data – Neo4j / LVC for relationship generation and updates.

Data Flow & Processing Pipeline

Raw data is partitioned by dimensions (time, space, entity, behavior, environment, result, perception, lineage, quality) and stored in Doris while simultaneously populating a graph knowledge base. Large models evaluate simulation outputs, self‑train, and update the ontology, forming a closed loop: "generate simulation → model evaluation → self‑training → ontology upgrade".

Ontology & Graph Data Architecture

Ontology‑Graph Relationship

OWL ontology layer : defines domain concepts, constraints and inheritance (e.g., Class:UUV ⊃ Class:Platform); designed once by experts and iterated via large‑model upgrades.

Neo4j graph instance layer : stores concrete simulation entities, states and events (e.g., (:UUV {name:"Explorer‑I"})‑[:HAS_SENSOR]→(:Sonar)); generated at runtime by the simulation engine.

Mapping: OWL Class → Neo4j Label, ObjectProperty → Relationship, DataProperty → Property, Individual → Node.

Four‑Layer Ontology Stack

Top layer : SpaceTime, Event, State.

Core layer : PhysicalEntity, EnvironmentFactor, Capability, Behavior, Information, Constraint.

Domain layer : MarineEnvironment, UnderwaterPlatform, Sensor, Weapon, Communication, Tactics.

Application layer : SimulationScenario, DataLineage, EvaluationMetric, ExperimentManagement.

Core Relationship Types

Top: OCCURS_AT, HAS_STATE, TRANSITION_TO.

Core: LOCATED_IN, INFLUENCED_BY, HAS_CAPABILITY, EXECUTES, GENERATES, CONSTRAINED_BY, DEPENDS_ON.

Domain: DEPLOYS_ON, CARRIES, EQUIPPED_WITH, COMMUNICATES_VIA, EMPLOYS, TARGETS.

Application: SCENARIO_FOR, PRODUCES, EVALUATED_BY, MANAGES, EVOLVES_FROM.

Ontology‑Driven Capabilities

Semantic interoperability across platforms.

Causal reasoning and counterfactual analysis for fault tracing.

Knowledge reuse and transfer learning across tasks and platforms.

Explainability and trust building via transparent decision provenance.

Resource optimization and multi‑agent coordination.

Anomaly detection and cognitive boundary awareness.

Long‑term evolution with version control and conflict detection.

Overall System Architecture

Simulation System Stack

Application display (PC UI).

Control & orchestration (MongoDB, MySQL for model management).

Data warehouse (domestic database products).

Communication layer (DDS discovery, RTI time sync, TCP data transport).

AI Product Stack (Cloud‑Native)

Solution layer: AI agents, intelligent office, decision, recommendation, Q&A.

Model‑as‑a‑Service (MaaS): ModelScope, Ollama, third‑party platforms.

PaaS: AI compute engines (BladeLLM, vLLM, SGLang) for pre‑training, fine‑tuning, inference.

IaaS: Cloud‑native compute, data‑warehouse compute (MaxCompute, EMR, Flink), heterogeneous servers (CPU/GPU), RDMA networking, distributed storage (CPFS, NAS, OSS), container service (ACK), elastic ECS, low‑PUE cooling facilities.

Model Service Architecture

Access layer: PC clients via API Gateway (auth, load balancing).

Gateway layer: LiteLLM gateway, load balancer, MCP gateway.

Model layer: Open‑source large models (Qwen‑3.7‑Max, DeepSeek‑V4, OceanGPT, etc.) and domain‑specific fine‑tuned models.

Storage layer: Doris, MinIO, RAG stores.

AI Engineering Systematization

Decision systematization : Leverage large‑model abilities (semantic parsing, logical reasoning, multimodal understanding) to generate actionable data aligned with business scenarios.

Technology stack systematization : Front‑end (Web, Java APP, low‑code Dify), knowledge base (RAG, AgentRAG, FlowRAG), intelligent agents (Dify, LangChain), inference engines (vLLM, Xinference, Ollama), infrastructure (K8s + KServer) for elastic scaling and unified monitoring.

Model stack systematization : Track model capabilities, select appropriate models for multimodal, embedded or general tasks, and maintain an evaluation‑iteration loop.

Model engineering : Apply prompt engineering, output constraints (Harness), human‑in‑the‑loop approval, workflow orchestration (Dify), long‑term memory, context compression to tame hallucinations.

Data engineering : Structure, version, and inject constraints, parameters and context; treat data as a lifecycle asset rather than a simple feed.

Training engineering : Layered training – RAG knowledge injection, pre‑training, domain fine‑tuning, reinforcement alignment – each tailored to model characteristics.

Self‑Evolution Mechanisms

Decision upgrade : Large models analyze workflow bottlenecks, adjust prompts and infer ontology‑based improvements, forming a closed‑loop upgrade.

Model upgrade : Automated data construction (llm‑graph‑builder), incremental fine‑tuning, seamless model replacement, parameter tuning.

Data upgrade : Large models and code autonomously enrich datasets; graph data refreshed frequently, ontology updated periodically.

Dynamic Scoring System

The system provides historical trend analysis and core stress‑test items, quantifying simulation outcomes across weapon effectiveness, tactic execution, collaborative performance and mission completion, thereby supplying data‑driven guidance for decision optimization.

Conclusion

The proposed framework emphasizes pragmatic validation: every architectural layer, algorithm and data element must operate reliably in real underwater conditions. From semantic understanding to physical actuation, from single‑vehicle intelligence to multi‑agent coordination, and from data collection to continuous model evolution, the architecture delivers a verifiable, evolvable intelligent decision system applicable to both military UUV missions and civilian domains such as underwater archaeology, oceanographic research and subsea infrastructure inspection.