What is the sensor-to-shooter data path in surface warfare C2?

The sensor-to-shooter data path is the chain of systems and processes that converts a sensor detection into an authorized weapon release. In surface warfare C2 it runs: radar sensor → track management (fusion, classification, quality assessment) → threat evaluation and weapon assignment (TEWA) → engagement authorization (commanding officer or designated weapons officer) → fire-control system → weapon launch. The C2 software automates the sensor-to-track and track-to-TEWA steps, but authorization remains a human step at the engagement stage. Data link integration means the track fed to the TEWA module may originate from any unit in the task group, not only the launching ship's own sensors — the sensor that detected the threat and the ship that fires the weapon are not necessarily the same unit.

C2 Systems

Maritime command and control software for surface warfare operations

By Corvus Intelligence Engineering Team · About the team →

June 25, 2026 12 min read

Surface warfare is one of the most information-dense environments a C2 system can be asked to manage. In the Combat Information Center of a modern frigate or destroyer, dozens of tracks — surface contacts, air threats, subsurface signatures, friendly units, helicopters, and unmanned vehicles — are updated continuously from organic sensors and data links, each demanding classification, prioritization, and a real-time check against active weapons engagement zones. The software that manages this is not simply a map application with sensor feeds: it is a layered architecture of fusion engines, data link protocol stacks, weapons coordination modules, and cryptographically separated networks, all running on hardware that must survive at sea for extended deployments without a patch window. This article is a technical examination of how maritime C2 software is architected for surface warfare, covering the tactical picture, data link integration, WEZ management, ASW C2, patrol aircraft coordination, and the cybersecurity constraints that shipboard environments impose. For a broader perspective on military C2 architecture, see our complete guide to military C2 systems.

Maritime C2 scope: from CIC automation to fleet C2

Naval command and control is not a single system but a stack of three distinct functional layers, each with different latency requirements, data volumes, and operator roles. Confusing them at the architecture stage produces a design that satisfies none of them adequately.

The ship-level CIC automation layer is the fastest and most operationally immediate. It fuses organic sensors — shipboard radar, ESM receivers, sonar, electro-optical systems — with data link contributions into a single track database, manages weapons systems, and provides the watch officer and commanding officer with the display consoles they need to direct an engagement in real time. Update rates here are measured in seconds; latency from sensor detection to operator display must be below three seconds for the tactical picture to be actionable. This layer runs inside the Combat Information Center on a classified, physically isolated network and must remain operational regardless of communication link status with higher echelons.

The task group C2 layer coordinates multiple ships. A surface action group or carrier strike group operates as an integrated unit, sharing a composite tactical picture across all hulls, coordinating weapons engagement zones so one ship's missile engagement volume does not overlap another ship's patrol helicopter flight path, and deconflicting fires across the group. The software at this layer aggregates the individual ships' track pictures via data link, resolves duplicates where the same contact appears on multiple ships' sensors, and distributes coordinated WEZ updates back to every hull. Update rates here are measured in tens of seconds; the task group picture is somewhat less granular than a single ship's organic picture but covers a much larger geographic area.

The fleet command layer is concerned with operational planning and strategic track distribution. It receives aggregated summaries from task groups, issues movement orders and rules of engagement, and maintains the operational-level picture used for campaign planning. This layer operates over longer-range communications, tolerates higher latency, and is typically hosted ashore or in a dedicated command ship rather than on every combatant. The multi-domain C2 architecture that governs modern joint operations typically connects the fleet command layer to the joint common operational picture, making the maritime picture visible to land and air command elements.

These three layers must be designed with clean interfaces between them. A CIC automation layer that exposes its internal sensor-fusion message bus to the task group layer will scale poorly; a task group C2 that polls individual CIC systems for raw sensor data will overwhelm the CIC's processing capacity. The correct boundary is a standardized track-export interface: the CIC publishes its authoritative track list on a well-defined schedule using a standard message format, and the task group C2 subscribes to those exports without touching the CIC internals.

Tactical picture compilation for maritime operations

The tactical picture in a maritime CIC is a fused, multi-domain track database. It contains surface contacts, subsurface tracks, air tracks, and friendly unit positions in a single coordinate system, each with a classification, an engagement status, a track quality assessment, and a contributing-source list. Maintaining this picture accurately under the data rates generated by modern sensors is the core engineering challenge of CIC software.

Surface track management starts with raw radar returns from the ship's surface-search radar and any additional surface-surveillance sensor. The radar provides range and bearing to each detected contact; the CIC software converts these to geographic coordinates, applies clutter filtering to suppress sea clutter and land returns, and initiates a track for each sustained contact. Tracks are updated on each radar scan — typically every two to six seconds — using a Kalman filter that estimates position, course, and speed from the sequence of positional measurements. When a data link contribution arrives for a contact that the radar already tracks, the fusion engine correlates the link report with the organic track and merges them into a single authoritative track that now has both sensor confirmation and any identity information the data link carried.

Track quality assessment is a continuous process. Each track is maintained at one of several quality states — firm, probable, or tentative — based on the number of contributing sensors, the consistency of reports across sources, and the time since the last supporting observation. A firm track has been confirmed by two or more independent sources and has been updated within a short tolerance window. A tentative track has only a single source, or has not been updated recently, and is shown to operators with reduced confidence. When a track has not been updated for a configurable timeout, it is dropped from the tactical picture rather than persisted indefinitely — stale tracks in the CIC are more dangerous than no track at all, because they occupy the operator's attention and can produce invalid engagement recommendations.

Contact classification is the assignment of a standard hostile/unknown/neutral/friendly (HUNF) designation to each track. Classification draws on ESM data (identifying the contact's radar and communication emitters against a known emitter library), visual identification from the ship's optical or infrared sensor suite, AIS correlation for surface contacts, and IFF responses for air contacts. Classification is never fully automatic — it is a recommendation presented to the watch officer who makes the final designation — but the software provides the evidence base that allows an experienced watch officer to classify a contact in seconds rather than minutes.

Key principle: Track quality and source tagging are not display features — they are input data for the threat evaluation and weapon assignment (TEWA) module. A TEWA recommendation based on a tentative, single-source track that has not been updated in forty-five seconds is operationally meaningless. The software must propagate track quality into the engagement logic, not just the operator display.

Data link integration in maritime environments

Maritime C2 software operates in a layered data link environment that has accumulated over decades of naval development. Each link carries different information, operates on different frequency bands, and has different range and reliability characteristics. The CIC software must maintain a composite track picture compiled from all active links and organic sensors, presenting a single de-duplicated track list to the operator regardless of how many underlying sources contributed to it.

Link 16, carried over Multifunctional Information Distribution System Low Volume Terminals (MIDS-LVT), is the primary tactical data link for modern surface combatants. It distributes the joint tactical picture via J-series messages: surface, subsurface, and air tracks (J3.x), precise participant location and identification (J2.x), weapons coordination (J7.x and J9.x), and network management (J0.x). Link 16 is a time-division multiple access network with assigned time slots, which means every participant must be time-synchronized and assigned a slot allocation before the network can operate — a configuration step that must be completed during the operations order process before the task group gets underway. For a detailed treatment of the Link 16 message set and integration architecture, see our article on Link 16 tactical data link integration.

Link 22 extends the tactical data link picture to over-the-horizon ranges using HF frequency bands and a different message protocol (NILE). While Link 16 is primarily line-of-sight or satellite-relay-dependent for long ranges, Link 22 propagates over the horizon via HF skywave, giving a task group beyond-the-horizon contact data without requiring a relay ship or satellite bandwidth. The CIC software maintains separate track contributions from Link 16 and Link 22 before merging them into the composite picture, because the two links can carry the same contact with different track numbers assigned by different units.

Link 11 (TADIL-A) remains installed on older frigates and patrol vessels that have not yet migrated to Link 16. Link 11 operates in a roll-call polling mode in which a net control station polls each participant in sequence — a significantly slower update cycle than Link 16's continuous broadcast. In a mixed task group, a Link 16 unit typically acts as a relay, bridging Link 11 tracks into the Link 16 picture for units that cannot receive Link 11 directly. The CIC software on the relay ship must apply duplicate resolution when a contact appears on both links with different track numbers.

The composite track management logic that underlies all data link integration follows the same principle used in sensor fusion: one canonical track per real-world contact, regardless of how many links report it. The association engine predicts each existing track forward to the incoming link report's timestamp, gates the report against the predicted position using the link's declared positional accuracy, and associates if the report falls within the gate. The canonical track then absorbs the link report, updating its position estimate and adding the link as a contributing source. An incoming link track that does not associate with any existing track initiates a new track, flagged as data-link-only until an organic sensor or a second link confirms it.

Weapons engagement zone management

Weapons engagement zone management is the process by which a task group establishes, distributes, and enforces the geographic areas in which each weapon system or unit is authorized to engage. Without coordinated WEZ management, a missile fired by one ship could enter the engagement airspace of another, or a helicopter operating a low-altitude ASW pattern could be inside a surface-to-air missile engagement volume. In a multi-ship task group conducting simultaneous surface warfare, air defense, and ASW operations, WEZ conflicts are not edge cases — they are a routine coordination problem that the software must solve continuously.

WEZ definitions in the C2 database are geometric objects: polygon or circular boundaries, a zone type, a designating authority, a validity period, and a broadcast flag. Zone types include:

Weapons free — all identified hostile contacts within the zone may be engaged without further authority from the designating commander.
Weapons tight — only contacts that have been positively identified as hostile may be engaged; unknown contacts are not to be engaged without additional authorization.
Weapons safe — no engagement is authorized within the zone regardless of track classification; used to protect helicopters, patrol aircraft, and UUVs operating in a defined area.

The C2 software continuously evaluates each track's geographic position against all active zones. When a track crosses a zone boundary, the system updates the engagement constraints on that track, alerts the weapons officer, and, if the track is under active TEWA evaluation, recalculates the engagement recommendation. This position-to-zone check must run in real time — a track moving at thirty knots covers nearly sixteen meters per second, and a zone boundary is not a tolerance band.

Zone broadcast across the task group uses Link 16 track and management messages to distribute current WEZ definitions to every ship in the group. The receiving ships merge incoming zone definitions into their own WEZ database using the same type of correlation logic used for tracks — a zone received from the task group commander supersedes any locally defined zone covering the same area. This ensures that every ship's engagement logic operates under the same rules, even when communication is intermittent.

Conflict detection between zones is a distinct function. A weapons-free zone that overlaps a weapons-safe zone covering a helicopter operating area is a fatal planning error; the C2 software should detect and alert on this conflict before it is broadcast, not after a helicopter enters what it believes to be a safe area. Conflict detection evaluates all zone pairs for spatial overlap and highlights cases where the combination of zone types would produce contradictory engagement rules on the same contact.

Anti-submarine warfare (ASW) C2

ASW C2 is architecturally distinct from surface warfare C2, but it shares the same track database and must be deconflicted with the surface and air pictures. The ASW module manages a different class of sensors — sonobuoys, hull-mounted sonar, towed-array sonar — and operates on time scales and geographic scales that differ from surface contact tracking.

Sonobuoy field management is the operational foundation of airborne ASW. The CIC software maintains a database of every deployed sonobuoy: its geographic position (known at drop time and drifting with current thereafter), its type (passive LOFAR, active DIFAR, range-only), its battery life remaining, and its current detection status. When a sonobuoy produces an acoustic bearing line, the CIC software correlates that bearing against existing subsurface tracks and updates them, or initiates a new tentative track. Multiple bearing lines from different buoys in the field are triangulated to produce a position estimate for the contact.

Acoustic track management is substantially harder than surface track management. Acoustic detections are ambiguous in range and bearing, and the track's depth — which can range from periscope depth to several hundred metres — affects both its detectability and its threat geometry. The ASW track manager maintains subsurface tracks with larger position uncertainty ellipses than surface tracks, and the Kalman filter's motion model must account for the full three-dimensional manoeuvring capability of a submarine rather than the essentially two-dimensional motion of a surface contact.

The coordinated prosecution workflow ties the sensor management to the weapons coordination picture. Once a subsurface contact is classified as hostile and prosecution is authorized, the ASW module computes an optimal search pattern for cooperating helicopters, generates buoy-reposition tasking to narrow the position estimate, and maintains a prosecution log that records every detection and platform action. When the contact is sufficiently localized, the module presents a torpedo solution to the weapons officer for authorization, with the engagement geometry displayed on the same tactical picture that shows the surface and air tracks — so the commanding officer can simultaneously assess the submarine threat and the surface and air situation before authorizing an engagement.

Maritime patrol aircraft and UUV coordination

Modern surface warfare units operate with organic helicopters and, increasingly, with fixed-wing maritime patrol aircraft assigned to the task group. The CIC must coordinate sensor tasking, picture sharing, and airspace management for all of these platforms simultaneously.

Maritime patrol aircraft coordination centres on the bilateral data link picture. The P-8 Poseidon, for example, participates in the task group's Link 16 network, contributing its own radar and sensor tracks as J-series messages that merge into the composite CIC picture. The CIC returns the task group surface picture to the aircraft so the crew can see the tactical situation during low-altitude approaches. Voice coordination — on designated UHF or HF frequencies — handles the prosecution workflow that requires real-time dialogue: buoy reposition requests, contact classification updates, and weapons release coordination when a torpedo engagement is authorized.

The ASW C2 module generates formal digital tasking for the MPA: a barrier search pattern defined by geographic waypoints, the types of buoys to deploy at each position, the passive-listen periods between active-transmission cycles, and the reporting format for acoustic detections. This tasking is transmitted as a structured digital message rather than free-text voice, so the CIC can track which instructions were acknowledged, when each buoy was deployed, and how long before each buoy's battery expires.

Helicopter coordination from the CIC follows the same pattern but with lower latency, since the organic helicopter is in continuous UHF voice contact and the shorter distances allow faster data link updates. The CIC tracks the helicopter as a friendly air contact, maintains its weapons-safe zone around the aircraft, and receives sonobuoy data as a continuous feed rather than periodic reporting. The weapons-safe zone management for the helicopter is one of the most operationally critical WEZ functions — a surface-to-air missile system that does not know the ship's own helicopter is in its engagement volume is a fratricide hazard.

Unmanned underwater vehicles introduce a telemetry-driven coordination model that the CIC software must support as a distinct interface. Mission tasking is transmitted to the UUV as a pre-planned mission file — a sequence of waypoints, sensor operating modes, and reporting triggers — and the UUV executes autonomously. The CIC receives position and sensor reports as telemetry messages at configured intervals, populating the UUV's position on the tactical display and merging its acoustic detections into the ASW track picture. Real-time re-tasking is possible but bandwidth-limited; the CIC software must manage the communication schedule to balance UUV monitoring against the data link bandwidth needed for the rest of the tactical picture.

Cybersecurity for shipboard C2 systems

Shipboard C2 cybersecurity is driven by constraints that do not apply to equivalent shore-based systems: physical isolation at sea, extreme operational continuity requirements, TEMPEST emission controls, and patching processes that must account for months-long deployments without reliable connectivity to update infrastructure.

Network segmentation on a modern warship is enforced by physical separation, not solely by firewall rules. A frigate typically operates four distinct network segments: a Top Secret/Sensitive Compartmented Information (TS/SCI) segment for the most sensitive intelligence feeds and communications; a Secret segment carrying the tactical picture, weapons coordination data, and Link 16 traffic; an unclassified segment for administrative, logistics, and crew welfare traffic; and a platform-management network for propulsion control, damage control, and ship systems monitoring. Physical separation means each segment runs on separate cabling, separate switching infrastructure, and separate workstations — a user at an administrative console cannot reach the CIC network by traversing a misconfigured firewall because there is no firewall between them; there is no path at all.

Cross-domain data flows are managed by approved data diodes and cross-domain guards at the precise points where information must move between classification levels. A data diode is a one-way optical link — data can flow in one direction only by physical construction, not policy configuration. A cross-domain guard is a more capable device that evaluates messages crossing the boundary against a strict format schema and content policy, rejecting any message that does not conform. Both types of device must be approved against national or allied standards for the classification levels they bridge.

TEMPEST requirements mandate that equipment in the CIC emits electromagnetic radiation below the levels at which an adversary could reconstruct classified information from the emanations. This has direct implications for hardware selection: commercially available workstations and servers are almost never TEMPEST-certified at the level required for TS/SCI or Secret CIC segments. Programmes must procure from the narrow set of ruggedized, TEMPEST-certified platforms validated for shipboard use, accepting higher unit cost and longer procurement lead times in exchange for compliance. The CIC compartment itself — its cabling, power filtering, and physical shielding — must also be designed to meet the applicable TEMPEST standard and validated before commissioning.

Patching shipboard C2 software is operationally constrained in ways that have no parallel in enterprise IT. The ship may be at sea for six to nine months; the CIC network has no routine connectivity to a vendor patch server; and the tactical picture cannot be taken offline for patching while the ship is in a threat area. The standard approach involves three elements. First, a pre-deployment update package is built and regression-tested against the specific hardware and software configuration of the platform class before the ship deploys, then applied in port. Second, configuration control is maintained across the deployment so that the exact state of every CIC system component is known at all times, enabling forensic analysis if an anomaly occurs. Third, a critical-vulnerability exception process permits emergency patches to be transmitted over a satellite link when a vulnerability is being actively exploited against the platform class — these patches go through a compressed but mandatory regression cycle before transmission rather than being pushed directly from a vendor advisory.

/* Example: CIC network segment boundary check at a cross-domain guard */

CICMessage msg = receivedFromClassifiedSegment();

// Schema validation: reject messages with unstructured text fields
if (!msg.conformsToSchema(ALLOWED_MESSAGE_TYPES)) {
    guard.reject(msg, "Schema violation: unstructured field detected");
    return;
}

// Direction check: data only flows Secret → Unclassified
if (msg.destinationClassification() > SECRET) {
    guard.reject(msg, "Upward flow violation");
    return;
}

// Content policy: only declassified track summaries permitted
if (msg.containsRawSensorData() || msg.containsKeyingMaterial()) {
    guard.reject(msg, "Content policy violation");
    return;
}

guard.forward(msg, unclassifiedSegment);

Integrity monitoring rounds out the shipboard cybersecurity posture. Every CIC executable, configuration file, and data file is hashed on deployment and the hash values stored in a tamper-evident log. The monitoring system re-hashes files on a continuous schedule and alerts if any discrepancy is detected — the signal that a file has been modified outside an authorized patch window. In a shipboard environment where external intrusion is difficult but insider threat and supply-chain compromise are realistic risks, integrity monitoring is a primary detection mechanism rather than a secondary one.

Build your naval C2 picture on a proven fusion architecture

Corvus HEAD provides the multi-sensor fusion engine, data link integration, and weapons coordination layer that surface combatants need — with the network architecture and operational continuity characteristics the shipboard environment demands.

Explore Corvus HEAD → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical C2 and ISR software for defense and government organizations. Learn about our team →

Frequently Asked Questions

What is maritime command and control software?

Maritime C2 software is the integrated system that manages the tactical picture, sensor fusion, weapons coordination, and communications aboard a warship or within a naval task group. It encompasses the Combat Information Center (CIC) automation layer on individual ships, the task group C2 that coordinates multiple hulls, and the fleet command layer that directs strategic movements. The software maintains a fused surface, subsurface, and air picture compiled from organic ship sensors and data links, and provides the commanding officer with the decision-support tools needed to manage weapons engagement zones, coordinate fires, and communicate with other units in the task group.

How does surface track management work in naval C2?

Surface track management is the process of ingesting raw radar detections and sensor plots from shipboard radar, ESM, and data links, then fusing them into a single authoritative track per real-world contact. The fusion engine assigns each track a unique track number, classifies it using available sensor data and data link reports, and continuously updates its position, course, and speed using a Kalman filter. Track quality is assessed on the basis of contributing sensors, report frequency, and the interval since the last observation. Tracks degrade through quality states — firm, probable, tentative — until dropped if unsupported for a configurable time. Each track carries a hostile, unknown, neutral, or friendly classification and an engagement status.

What is a weapons engagement zone in naval operations?

A weapons engagement zone (WEZ) is a defined area in which a specific weapon system or unit is authorized to engage hostile contacts. Naval WEZ management distinguishes free-fire zones (engage without further authority), weapons-tight zones (engage only positively identified hostiles), and weapons-safe zones (do not engage). WEZ boundaries are geometric — typically circular or polygon areas keyed to geographic coordinates — and the C2 software continuously checks each track's position against all active zones, alerting the weapons officer and automatically setting engagement constraints on the fire-control system when a track enters or exits a zone. Zone definitions are broadcast across the task group via data link so every ship operates under the same engagement rules.

What data links does maritime C2 software integrate?

The primary tactical data link for modern surface warfare is Link 16, carried over MIDS-LVT terminals, which distributes the joint tactical picture, precision participant location, and weapons coordination messages (J-series message set). Link 22 extends Link 16 reach in high-frequency mode for over-the-horizon communication between ships. Link 11 (TADIL-A) remains in service on legacy platforms and must be bridged into the composite track picture by a relay ship. The C2 software maintains a composite track database compiled from all active link sources and organic sensors, resolving duplicates where the same contact appears on multiple links using correlation logic identical to sensor fusion.

How is ASW C2 integrated into shipboard C2 software?

Anti-submarine warfare C2 is integrated as a specialist module within the ship's CIC software. It manages the sonobuoy field — tracking which buoys are active, their battery life, and their geographic positions — and correlates acoustic detections from sonobuoys, the ship's hull-mounted sonar, and towed array into subsurface tracks. The ASW C2 module provides a prosecution workflow: once a subsurface contact is classified, the module computes search patterns, tasks cooperating helicopters with buoy reposition instructions, and coordinates weapons release authority with the surface warfare picture so a torpedo engagement does not conflict with friendly surface units.

How do maritime patrol aircraft coordinate with a ship's CIC?

Maritime patrol aircraft such as the P-8 Poseidon share their sensor picture with the ship's CIC via Link 16 and UHF/HF voice. The CIC receives the aircraft's track contributions as data link messages that merge into the composite tactical picture. For ASW coordination, the CIC tasks the aircraft with specific sonobuoy barrier patterns and receives acoustic detections as formatted digital reports that feed the ASW track management module. The ship also sends the aircraft its local picture — including surface contacts, weapons zones, and the current threat assessment — so the crew can deconflict their low-altitude flight path against active engagement areas. UUVs follow a parallel architecture: mission tasking is sent as a digital command, and position and sensor reports return as telemetry messages that populate the CIC tactical display.

What are TEMPEST requirements for shipboard C2 systems?

TEMPEST (Telecommunications Electronics Material Protected from Emanating Spurious Transmissions) requirements mandate that shipboard C2 systems emit electromagnetic radiation below levels that would allow an adversary to reconstruct classified information from the emanations. On warships this means the CIC equipment must meet the relevant national or allied TEMPEST standard (NATO SDIP-27 Level A or equivalent), and the physical compartment design, cabling, and power filtering must be validated before commissioning. TEMPEST certification significantly constrains which commercial-off-the-shelf hardware can be used in the classified CIC segment and drives the use of approved ruggedized computing platforms with known emission profiles.

How is network segmentation implemented on a warship?

A modern warship operates several physically separated networks at different classification levels: a Top Secret/SCI network for the most sensitive intelligence feeds, a Secret network carrying the tactical picture and weapons data, an unclassified network for administrative and logistics traffic, and a platform-management network for propulsion, damage control, and ship systems. These segments are enforced by physical separation and cross-domain guards or data diodes at the points where information must flow between levels — for example, where a declassified track extract is passed from the Secret CIC network to the unclassified ship's intranet. Guards enforce both the data format (no unstructured text across a boundary) and the direction of flow (a diode is one-way by construction).

What constraints do shipboard environments impose on C2 software patching?

Shipboard C2 software faces patching constraints that do not apply to shore-based systems. The ship may be at sea for months, limiting connectivity to the update infrastructure. The CIC systems cannot be taken offline for patching while the ship is in a threat area — the tactical picture must remain available continuously. Patches must be validated against the specific hardware and software configuration of each platform class, because a patch that affects timing or interrupt handling in the sensor-fusion pipeline can degrade track quality. Programmes address this through pre-deployment update packages that are applied in port after regression testing, and through critical-vulnerability exception processes that allow emergency patches via satellite link when a vulnerability is actively exploited.

How does littoral surface warfare differ from blue-water C2?

Littoral operations in coastal and archipelago waters present fundamentally different C2 challenges compared to open-ocean blue-water warfare. The radar clutter returns from coastlines and islands saturate surface-track management with false contacts, requiring aggressive clutter-map maintenance and higher track-initiation thresholds. The high density of civilian vessels requires rapid classification and intent assessment rather than the assumption that any contact is hostile. Shallow water compresses the ASW geometry and limits sonobuoy effectiveness. Electronic warfare is more complex in littoral environments because of the higher density of emitters. The C2 software's track quality and engagement rule logic must be tuned separately for littoral and blue-water operational profiles — a single default configuration performs poorly in both.