Situation Awareness and Multi-Source Data Fusion for Surface Formation Transits with Close-Following Vessels

1. Background: The Operational Pressure of Transiting Narrow Waterways

When a surface naval formation transits a strait, island chain, or congested coastal waterway, it typically faces multiple constraints: restricted navigable routes, dense traffic, and a complex electromagnetic environment. If other naval or small civilian vessels continuously trail the formation, intermittently close in, or repeatedly cross its track, the processing load on the situation awareness system increases significantly.

Compared with open-ocean conditions, close-following in narrow waterways presents several distinct characteristics:

1. Irregular target motion patterns: A trailing vessel may frequently change speed, alter course, disappear for short periods, or blend into a group of fishing boats. Tracking algorithms that rely solely on position extrapolation are prone to track breaks or mis-association.
2. Increased conflicts among multi-source data: Radar, electro-optical sensors, the Automatic Identification System (AIS), and electronic support measures operate with different update rates, coordinate frames, and confidence levels, making target identity correlation more difficult.
3. High cognitive workload for watch officers: Commanders must simultaneously monitor navigational safety, target intent, and formation coordination in a limited time. Traditional list-centric display layouts are inadequate for visualizing the dynamic evolution of the tactical situation.
4. Interference from low-observable targets: Small, fast vessels have small radar cross-sections and unstable detection probabilities in sea clutter, often generating fragmented short tracks.

These issues are not unique to any specific equipment or platform but represent persistent technical challenges in maritime situation awareness. The solution path lies in information processing and decision support, not in relying on any single sensor or algorithm.

2. The Layered Architecture of a Situation Awareness Pipeline

A situation awareness system designed for close-following scenarios can generally be abstracted into four processing layers:

1. Sensor access layer: This layer ingests data from various radar systems, electro-optical sensors, navigation radars, electronic support equipment, and AIS, while unifying the time and spatial reference frames.
2. Data governance layer: This layer performs coordinate transformation, error registration, outlier rejection, time interpolation, and data quality assessment to ensure consistency and usability of inputs for subsequent fusion.
3. Fusion and tracking layer: This layer handles plot-to-track association, track life-cycle management, maneuver detection, and integrated identity classification in a multi-target environment.
4. Situation display and decision support layer: This layer presents fused results through geographic mapping, relative motion vectors, threat alerts, and rule-based prompts to reduce operator cognitive load.

In these four layers, the core difficulties of close-following scenarios concentrate in the second and third layers. If data governance is inadequate, the fusion layer will continuously produce mis-associations. If the fusion layer is not robust, even the most intuitive display cannot compensate for distorted underlying information.

3. Core Issues in Multi-Sensor Track Association

A vessel trailing the formation may be detected simultaneously by multiple sensors or only intermittently by one sensor. The objective of track association is to determine whether local tracks generated by different sensors at different times refer to the same physical entity.

A typical engineering workflow is as follows:

1. Spatial alignment: Radar polar measurements, electro-optical bearing/elevation readings, and AIS latitude/longitude reports are all converted to a local Cartesian coordinate system centered at the formation reference point. For distant targets where the Earth’s curvature is significant, a geocentric coordinate conversion or local tangent plane projection should be used to avoid systematic errors introduced by simple planar approximations.
2. Temporal alignment: Different sensors have different sampling intervals; for example, a radar might operate at 2-second cycles, an electro-optical sensor at 1-second, and AIS at 6 seconds or longer. A common time grid is established, and each sensor’s data is extrapolated or interpolated using nearest-neighbor methods. The extrapolation duration is recorded to control its confidence weight.
3. Coarse association gating: A gate is established around the predicted position of an existing track. The gate size is determined by both the prediction error covariance and the target’s maximum maneuvering capability. Measurements falling inside the gate proceed to fine association; those outside trigger new-track initialization logic.
4. Fine association and conflict resolution: When multiple measurements compete for the same track, methods such as Global Nearest Neighbor (GNN) or Joint Probabilistic Data Association (JPDA) can be used. In engineering practice, GNN offers moderate computational cost and is straightforward to debug, but when association conflicts are prominent, a delayed decision mechanism based on Multiple Hypothesis Tracking (MHT) or a historical scoring matrix should be introduced.
5. Identity-assisted validation: AIS messages containing call signs, vessel types, and dimensions can serve as soft constraints for identity consistency. However, such information may be incomplete, inaccurate, or spoofed, and should not be used as the sole criterion.

4. Algorithm Selection for Maneuvering Target Tracking

Trailing targets often attempt to provoke reactions by changing speed or turning. Therefore, their motion model cannot be simplified as a straight-line constant-velocity course. A common practice is to use an Interacting Multiple Model (IMM) filter that simultaneously runs a constant-velocity (CV) model, a constant-acceleration (CA) model, and a coordinated-turn (CT) model.

A schematic state model is shown below:

State vector: x = [position X, velocity Vx, position Y, velocity Vy]
Model 1: Constant velocity
x(k+1) = F1 * x(k) + w1(k)
Model 2: Constant acceleration
x(k+1) = F2 * x(k) + w2(k)
Model 3: Coordinated turn
x(k+1) = F3(angular rate) * x(k) + w3(k)

The system dynamically adjusts model weights based on the current likelihood probability of each model. When the target sails straight, the CV model’s weight increases; when the target turns or accelerates, the corresponding maneuvering model’s weight rises. The critical point is that model-switching probabilities and process noise must reflect the actual maneuvering capabilities of maritime platforms, and should not directly copy parameters used for aerial targets. For small fast craft, the maximum acceleration limit is significantly higher than for large vessels; consequently, the process noise of the CA model should be increased accordingly.

For track management in close-following scenarios, a staged life-cycle approach is suitable:

• Confirmed track: Receives associated measurements for multiple consecutive cycles and enters a stable output state.
• Tentative track: Only a few measurements fall inside the gate; the track is retained and extrapolated pending further validation.
• Pending deletion track: Has no associated measurements for multiple consecutive cycles or repeatedly falls into clutter regions; its confidence should be lowered until it is deleted.

This tiered management mechanism reduces track breakage and re-numbering caused by short-term missing detections, which is critical for maintaining continuity in watch officers’ judgment.

5. Rule-Based Recognition and Alert Design for Close-Following Behavior

Outputting only target position and velocity does not answer the higher-level question: “Is the target shadowing the formation?” A rule-based reasoning layer must be superimposed on the fused tracks to convert raw motion parameters into interpretable situational judgments.

Commonly used decision features can be summarized as follows:

1. Range-keeping characteristic: The target maintains a relatively stable distance from a formation ship, with the range rate staying near zero over a long period.
2. Course correlation: The angle between the target’s course and the formation’s course remains small for an extended time, and after the formation turns, the target follows the turn within an acceptable delay.
3. Speed matching: The difference between the target’s speed and the formation’s speed is small, or the target adjusts its speed approximately in sync with changes in formation speed.
4. Sustained relative position: The target continuously remains in the stern sector of the formation, and even after crossing the formation’s track, it returns to the trailing sector.

Combining these features into a scoring mechanism reduces the impact of single-instant false judgments. For example, when a target satisfies the range-keeping, course correlation, and speed-matching conditions for 10 consecutive minutes, the system raises a “close-following tendency increased” prompt. When the target enters a preset alert distance and the score exceeds a threshold, a high-priority alarm is triggered.

Alert design should follow an “explainability first” principle. Each alert should provide not only the conclusion but also the supporting evidence, for example:

Alert type: Persistent close-following
Target ID: T023
Trigger reasons:
  - Duration in stern sector: 12 min 40 s
  - Mean range rate: 0.3 knots
  - Mean course difference: 8 degrees
  - Composite score: 0.82

This interpretable output allows watch officers to quickly verify the situation and supports post-event review and rule tuning.

6. Data Replay and After-Action Analysis

After a close-following event concludes, replaying and quantitatively analyzing the entire process is an important step for improving response capability. A data replay system should support synchronized, timeline-based playback of multi-source data and allow analysts to manually annotate track association errors, false alerts, or missed detection events.

A practical approach is to store raw measurements, pre-fusion local tracks, post-fusion global tracks, and alert events in separate layers. During replay, the fused global track serves as the main view, while raw measurements are overlaid to verify whether the system processing accurately reflects the external situation. For critical time segments, the system should support cycle-by-cycle stepping through gate sizes, association competition results, and model-switching states.

Replay metrics can include:

• Track continuity: The percentage of time during which the system’s track for a given target remains continuous from appearance to disappearance.
• Association accuracy: The proportion of measurements that are correctly assigned to the same track for a given physical target, as judged by manual review.
• Alert timeliness: The time required from when behavioral characteristics meet the alarm conditions to when the system actually issues the alert.

These metrics are not tied to any specific vendor implementation and can be computed by any data-processing system with replay capability.

7. Reliability Recommendations for Engineering Implementation

In actual deployment, the situation awareness and fusion processing chain requires explicit reliability design. The following aspects are recommended:

Redundancy and degraded operation: When a particular sensor class fails or its data quality deteriorates significantly, the system must continue operating without that source and should mark the change of data source on output track quality. For example, if AIS data is interrupted, the confidence of identity judgment should be automatically lowered without compromising radar-based position tracking.

Input quality monitoring: A data quality dashboard should be maintained for each sensor, monitoring update cycles, frame loss rates, position jump frequencies, and coordinate transformation residuals. If quality indicators continuously degrade, the system should notify the watch officer rather than silently outputting unreliable results.

Configurable rules and algorithm parameters: Alert rules, model noise, and gate sizes should be configurable items and switchable by scenario templates. The parameter requirements for open-ocean operations differ significantly from those for narrow waterways, so a single fixed parameter set is not suitable.

Logging and auditing: Critical decision steps should record input data, intermediate results, and decision rationale to facilitate post-event diagnosis of whether an issue originated from data sources, algorithms, or rule settings. Log structures should use unified field formats and consistent timestamp precision.

8. Extending Toward Cloud-Edge Collaboration

For fleet-level situation sharing and collaborative analysis, a cloud-side aggregation and model optimization capability can be introduced on top of single-ship processing. Shore-based or fleet command nodes can securely collect anonymized track summaries, alert events, and data quality statistics from each platform. The cloud then performs cross-platform track consistency analysis, behavioral pattern mining, and rule model updates.

It is important to emphasize that cloudification does not mean uploading all raw sensor data for centralized processing. Instead, an edge-first architecture should be adopted: each platform performs local fusion tracking and preliminary alert determination, then uploads only summarized results. The cloud’s responsibility includes:

• Re-validating cross-platform target identity;
• Accumulating a historical behavioral pattern library and matching similar scenarios;
• Generating and distributing new rules and parameter recommendations.

This approach places modest demands on communication bandwidth and avoids the risk of link instability affecting local real-time operations. Additionally, by analyzing track differences for the same target as seen from different platform perspectives, the cloud can help identify perception biases caused by single-platform sensor coverage gaps.

9. Common Misconceptions and Avoidance Strategies in Practical Applications

Believing that more data is always better: While multi-source data carries a greater volume of information, if alignment and conflict-resolution capabilities are insufficient, it introduces more mis-associations. The quality of single-source tracks should be guaranteed first, with fusion sources added incrementally.

Over-relying on identity reports: Cooperative information sources such as AIS are often assumed to be highly reliable. In reality, for non-cooperative targets, identity information may be missing or deliberately falsified. Such data should be treated as auxiliary attributes rather than decisive factors.

Alert thresholds being too sensitive or too lax: Improper threshold settings can generate a flood of false alerts or miss critical warnings, eroding operators’ trust in the system. Thresholds should be iteratively tuned against historical replay data and validated through controlled tests during a trial phase.

Treating close-following as a static rule-based judgment: The actual situation is dynamic. Rule-based reasoning should be based on persistent features within a time window rather than on a single instantaneous snapshot. Moreover, the rule library should be continuously updated according to actual missions and sea-area characteristics.

In summary, when a naval formation transits a narrow waterway and faces close-following threats, the core value of the technical system lies in converting fragmented, multi-source, and uncertain perception information into continuous, interpretable, and traceable situational awareness. Through layered design, robust fusion tracking, behavioral rule inference, and restrained cloud-side collaboration, a reliable and evolvable general-purpose technical solution can be built without dependence on any specific product ecosystem.