{"id":51592,"date":"2026-04-17T20:29:23","date_gmt":"2026-04-17T19:29:23","guid":{"rendered":"https:\/\/maritimehub.co.uk\/?p=51592"},"modified":"2026-04-17T20:29:23","modified_gmt":"2026-04-17T19:29:23","slug":"arpa-target-tracking","status":"publish","type":"post","link":"https:\/\/maritimehub.co.uk\/arpa-target-tracking\/","title":{"rendered":"ARPA Target Tracking"},"content":{"rendered":"
\n

BRIDGE \u2192 Radar & AIS<\/p>\n

Position on the Bridge<\/strong><\/p>\n

System Group:<\/strong> Collision Avoidance<\/p>\n

Primary Role:<\/strong> Automated tracking of radar targets to derive CPA, TCPA, course, and speed \u2014 the computational backbone of collision avoidance decision-making.<\/p>\n

Interfaces:<\/strong> Radar transceiver, gyrocompass, speed log (water track or ground track), GPS, ECDIS, AIS, VDR. Feeds the OOW’s situational awareness and, increasingly, alert management systems.<\/p>\n

Operational Criticality:<\/strong> Absolute \u2014 ARPA outputs are the primary quantitative input to collision avoidance decisions on virtually every deep-sea vessel.<\/p>\n

Failure Consequence:<\/strong> Loss of computed vectors and CPA\/TCPA data across all tracked targets simultaneously. The OOW reverts to manual plotting or, more realistically, to nothing at all \u2014 because the skill has not been practised in years.<\/p>\n<\/div>\n

ARPA does not watch targets.
It processes echoes. The watching is supposed to be done by someone else.<\/em><\/p>\n

Introduction<\/h2>\n

The Automatic Radar Plotting Aid was introduced to mechanise a task that watchkeepers were already failing to do consistently by hand: maintaining a reliable plot of multiple targets under time pressure. It succeeded at that. What it also did, over four decades, was remove the manual plotting skill from the bridge almost entirely, replacing it with a dependency on a system whose internal logic is poorly understood by most of the people relying on it.<\/p>\n

ARPA is not a sensor. It is a processor. It takes raw radar returns and applies filtering, correlation, and smoothing algorithms to produce vectors and closest-point-of-approach data. Every output is a prediction, built on assumptions about target behaviour that may or may not hold. The system’s confidence in its own output is absolute. The operator’s confidence should not be.<\/p>\n

This article addresses how ARPA acquires and tracks targets, how its outputs are stabilised, why those outputs degrade under specific and predictable conditions, and what trial manoeuvres actually represent. It is written for watchkeepers who already use ARPA daily \u2014 and who may have stopped asking what the system is actually doing underneath the vectors on the screen.<\/p>\n

Contents<\/h2>\n
    \n
  • 1. Acquisition: Automatic and Manual<\/li>\n
  • 2. The Tracking Process \u2014 What the Algorithm Actually Does<\/li>\n
  • 3. Vector Stabilisation: Sea, Ground, and the Tideway Problem<\/li>\n
  • 4. Target Swap<\/li>\n
  • 5. Lost Targets and the Conditions That Cause Them<\/li>\n
  • 6. Trial Manoeuvres and Their Limits<\/li>\n
  • 7. Why ARPA Degrades When the Situation Gets Complex<\/li>\n
  • 8. Closing Reality<\/li>\n<\/ul>\n

    1. Acquisition: Automatic and Manual<\/h2>\n

    A radar echo must be acquired before it can be tracked. Acquisition is the act of telling the processor: this echo exists, follow it. It happens in two ways, and the difference between them matters more than most operators realise.<\/p>\n

    Automatic acquisition<\/strong> uses guard zones \u2014 operator-defined areas of the radar display within which any new echo meeting certain threshold criteria is acquired without intervention. The system scans each sweep for returns that appear in approximately the same position over successive antenna rotations. Once a return is correlated across a set number of sweeps (typically three to five), it is promoted from noise to target and tracking begins.<\/p>\n

    The appeal is obvious: no target can approach without the system noticing. The cost is equally obvious but less frequently acknowledged. Automatic acquisition generates a large number of tracked targets, many of which are not vessels. Rain cells, sea clutter breakthrough, sidelobe returns, and interference can all produce echoes that meet the correlation threshold. In congested waters with active precipitation, automatic acquisition can saturate the tracker, filling all available target channels with false or irrelevant tracks. Most ARPA processors handle between 40 and 100 simultaneous targets. When that limit is reached, new targets are not acquired at all.<\/p>\n

    This is a silent failure. There is no alarm that says: a real target just appeared but the system had no spare capacity to track it.<\/p>\n

    Manual acquisition<\/strong> requires the operator to place the cursor on an echo and command the system to track it. This demands that the watchkeeper has already detected the echo visually on the display, which in turn demands active radar watching \u2014 not passive monitoring. Manual acquisition is selective. It prioritises. It requires judgment about which targets matter.<\/p>\n

    The regulatory expectation under SOLAS is that both modes are available. The operational reality on most bridges is that automatic acquisition is left running permanently, manual acquisition is used rarely, and the resulting clutter of tracked targets is accepted as normal. The consequence is an operator who trusts the system to identify threats, rather than using the system to quantify threats already identified. The distinction is fundamental.<\/p>\n

    2. The Tracking Process \u2014 What the Algorithm Actually Does<\/h2>\n

    Once acquired, a target enters the tracking gate. This is a small area of the display, centred on the target’s last known position, within which the processor expects to find the same echo on the next antenna sweep. The gate’s size is dynamic: it expands if the target is accelerating or manoeuvring, and contracts once steady-state motion is established.<\/p>\n

    Each sweep, the processor measures the target’s range and bearing. These measurements are noisy. Raw radar returns jitter in position due to pulse resolution, beamwidth, sea state, and target aspect. The processor applies a smoothing filter \u2014 typically an alpha-beta filter or Kalman filter variant \u2014 to derive a best estimate of the target’s true position, course, and speed from the stream of noisy measurements.<\/p>\n

    This smoothing is the source of ARPA’s greatest strength and its most dangerous weakness.<\/p>\n

    Smoothing produces stable, credible-looking vectors even when the underlying measurements are poor. It also introduces latency. A target that alters course does not produce an immediate change in the displayed vector. The filter must receive several sweeps of data showing the new heading before it adjusts its output. With a 3-second antenna rotation and a filter requiring 15-20 sweeps to stabilise, a genuine course alteration may take 45 seconds to a minute to appear in the vector \u2014 and several minutes before CPA and TCPA values settle to anything reliable.<\/p>\n

    During this settling period, the displayed data is wrong. Not uncertain. Wrong.<\/p>\n

    The IMO performance standard (Resolution MSC.192(79)) requires that ARPA achieve a certain tracking accuracy within a defined time after acquisition \u2014 typically one minute for course and speed trend, three minutes for full accuracy. These figures describe ideal conditions: a single target, steady course and speed, good sea state, no clutter. They are the laboratory specification. They are not the Dover Strait at night in rain.<\/p>\n

    3. Vector Stabilisation: Sea, Ground, and the Tideway Problem<\/h2>\n

    Every ARPA vector has a reference frame. It is either sea-stabilised or ground-stabilised. This choice changes what the vector means, and selecting the wrong one for the situation produces systematically misleading collision avoidance information.<\/p>\n

    Sea-stabilised vectors<\/strong> show a target’s motion relative to the water. They are derived from own ship’s speed through the water (from the log) and the radar-measured relative motion of the target. A sea-stabilised true vector shows the target’s heading and speed through the water. This is what matters for the application of the COLREGs, which are written in terms of courses steered and aspects presented \u2014 water-referenced quantities.<\/p>\n

    Ground-stabilised vectors<\/strong> show a target’s motion over the ground. They are derived from own ship’s speed over the ground (from GPS or a ground-tracking Doppler log) and the same radar-measured relative motion. A ground-stabilised true vector shows the target’s course and speed made good.<\/p>\n

    In open water with negligible current, there is no practical difference. In a tideway, the difference is operationally critical.<\/p>\n

    Consider a vessel stemming a two-knot cross-tide in the English Channel. Her heading is 070, her course over ground is 080. A reciprocal vessel on the opposite side of the TSS is similarly offset. Sea-stabilised vectors show both vessels pointing along their respective headings \u2014 the picture that corresponds to what the eye sees and what the COLREGs address. Ground-stabilised vectors show both vessels crabbing across the display at angles that do not correspond to their headings. Aspect assessment becomes unreliable. The geometry of a crossing situation can appear to change character.<\/p>\n

    The problem deepens in rivers, estuaries, and approaches with strong tidal set. Ground-stabilised vectors on an anchored vessel will show it stationary \u2014 correct and useful for that specific assessment. Sea-stabilised vectors on the same vessel will show it moving through the water at the tide rate \u2014 also correct, but potentially confusing if the operator does not understand the stabilisation mode in use.<\/p>\n

    The critical failure is not choosing one mode over the other. It is not knowing which mode is active, or not understanding the implications. The stabilisation mode label on most radar displays is small, abbreviate, and easy to overlook. Many watchkeepers have never deliberately switched between modes and could not explain the difference under questioning.<\/p>\n

    In tidal waters, the mode must be a conscious selection, not a factory default.<\/p>\n

    4. Target Swap<\/h2>\n

    Target swap is a tracking failure in which the processor loses its association with one echo and begins following a different echo, while continuing to display what appears to be the same tracked target. The target number does not change. There is no lost-target alarm. The vector simply begins representing a completely different object.<\/p>\n

    It happens when two echoes pass close together on the display \u2014 two vessels on reciprocal courses, a vessel passing a navigation buoy, a vessel transiting close to a shoreline \u2014 and the tracking gate, expanding slightly to accommodate measurement uncertainty, captures the wrong echo on the next sweep.<\/p>\n

    The processor has no concept of identity. It does not know that Target 47 is a tanker. It knows only that Target 47 was at range 4.2, bearing 185 on the last sweep, and it expects to find an echo near that position on the next sweep. If two echoes are present within the gate, the processor selects one. There is no guarantee it selects correctly.<\/p>\n

    After swap, the vector for the tracked target rapidly diverges from reality. The displayed CPA and TCPA become meaningless. The operator, trusting the track continuity, may not notice for several minutes \u2014 by which time the actual target has moved significantly from its last tracked position without any collision avoidance computation being applied to it.<\/p>\n

    Target swap is most likely in precisely the conditions where tracking accuracy matters most: traffic separation schemes, port approaches, and any confined water where vessels pass at close range. It is also more likely in poor weather, where clutter broadens echoes and increases positional uncertainty.<\/p>\n

    There is no reliable automated defence against target swap. The defence is the operator comparing the radar picture to the ARPA output and noticing when they diverge. This requires looking at the raw echoes, not just the synthetic vectors overlaid on them.<\/p>\n

    5. Lost Targets and the Conditions That Cause Them<\/h2>\n

    A lost target is one the processor can no longer track. The echo has disappeared from the tracking gate for a sustained number of sweeps, and the system abandons the track. An audible and visual alarm is generated. In principle, this is a robust alert mechanism. In practice, it is degraded by several factors.<\/p>\n

    The first is alarm fatigue. In areas of clutter, automatic acquisition creates large numbers of tracks on non-vessel echoes. These tracks are inherently unstable and are lost frequently. The resulting stream of lost-target alarms teaches the watchkeeper to dismiss them. When a genuine vessel target is lost, the alarm carries no additional weight. It is the same sound, the same symbol, the same acknowledge action.<\/p>\n

    The second is the physical conditions that cause genuine target loss:<\/p>\n

      \n
    • Sea clutter:<\/strong> Heavy sea states raise the noise floor, particularly at short range. Small vessel echoes can be swallowed entirely. Excessive clutter suppression by the operator removes both clutter and weak targets simultaneously.<\/li>\n
    • Rain clutter:<\/strong> Precipitation cells attenuate the radar signal and mask echoes behind them. X-band is significantly more affected than S-band. A vessel in or behind a rain cell can disappear from the display entirely.<\/li>\n
    • Target aspect:<\/strong> A vessel presenting a narrow bow or stern aspect returns a much weaker echo than one beam-on. In marginal detection conditions, aspect change during a course alteration can drop the return below the tracking threshold.<\/li>\n
    • Blind sectors and shadow zones:<\/strong> Own ship’s structure creates permanent blind arcs. Targets passing through these arcs are lost and must be re-acquired on the other side. The tracking history is gone.<\/li>\n
    • Low radar cross-section:<\/strong> FRP hulls, small fishing vessels, and yachts produce weak echoes that are easily lost in any clutter environment.<\/li>\n<\/ul>\n

      A target that is lost is at least announced. The greater danger is the target that was never acquired \u2014 the echo that exists on the raw radar display but never met the automatic acquisition threshold, or sat in a guard zone gap, or appeared while all tracking channels were full.<\/p>\n

      ARPA cannot track what it does not acquire. The radar display always contains more information than the tracking overlay.<\/p>\n

      6. Trial Manoeuvres and Their Limits<\/h2>\n

      The trial manoeuvre function allows the operator to simulate a proposed change in own ship’s course and\/or speed and observe the predicted effect on all tracked targets’ CPA and TCPA values. It is a planning tool. It answers the question: if I alter to this course at this speed, what happens to the overall traffic picture?<\/p>\n

      It is useful. It is also dangerous when its assumptions are not understood.<\/p>\n

      A trial manoeuvre assumes that every tracked target maintains its current course and speed throughout the simulation. This is explicitly stated in every radar training manual and is explicitly forgotten on every bridge where the function is used under pressure. The ARPA models own ship’s proposed action against a static world. The world is not static.<\/p>\n

      In a multi-vessel encounter, the entire point of the manoeuvre is that other vessels are also likely to act. A give-way vessel altering to starboard changes the geometry for every other target in the vicinity. The trial manoeuvre cannot model this. It produces a prediction based on one vessel acting and all others holding course \u2014 a scenario that becomes less likely as the number of vessels increases.<\/p>\n

      The trial manoeuvre also assumes instantaneous execution. The simulation shows the effect of being on the new course at the new speed immediately. It does not model the turning circle, the acceleration or deceleration curve, or the time delay between ordering the manoeuvre and achieving it. For a large vessel at full speed, the difference between the trial manoeuvre’s instant course change and the reality of a three-minute turn through 40 degrees is significant. CPA values that looked comfortable in the simulation may not materialise in practice.<\/p>\n

      Furthermore, the trial manoeuvre is only as good as the tracking data it operates on. If a target’s vector has not yet settled \u2014 if the target has recently altered course and the filter is still converging \u2014 the trial manoeuvre bases its prediction on incorrect input data. Garbage in, garbage out, presented on a clean digital display with two decimal places of CPA.<\/p>\n

      Trial manoeuvres should inform decisions. They should not make them.<\/p>\n

      7. Why ARPA Degrades When the Situation Gets Complex<\/h2>\n

      This is the central paradox of automated tracking, and it deserves to be stated plainly.<\/p>\n

      ARPA tracking is at its most accurate and stable when there is a single target on a steady course in clear weather at moderate range. This is the situation in which the watchkeeper needs it least \u2014 because manual plotting, or even visual assessment alone, would suffice.<\/p>\n

      ARPA tracking degrades when:<\/p>\n

        \n
      • Multiple targets are present at close range (tracking gate conflicts, swap risk, channel saturation).<\/li>\n
      • Targets are manoeuvring (filter latency, vector inaccuracy during settling).<\/li>\n
      • Weather is poor (clutter masking, echo attenuation, false acquisition).<\/li>\n
      • Own ship is manoeuvring (rate-of-turn effects on all relative vectors, log input instability).<\/li>\n
      • The operating environment involves significant current (stabilisation mode confusion, vectors that do not match visual aspect).<\/li>\n<\/ul>\n

        Every one of these conditions is a characteristic of a complex, high-workload navigational situation \u2014 exactly the scenario in which the watchkeeper depends on ARPA most heavily.<\/p>\n

        This is not a design flaw. It is a physical and mathematical reality. Smoothing filters need time. Tracking gates need spatial separation. Radar needs a clear propagation path. None of these requirements are met in the situations where collision risk is highest.<\/p>\n

        The system gives its best performance when the demand is lowest, and its worst performance when the demand is highest.<\/p>\n

        The operator who does not understand this will trust the display at the moment it is least trustworthy. And that trust, combined with the loss of manual plotting skills across the industry, creates a gap between perceived situational awareness and actual situational awareness that has contributed to collisions for decades.<\/p>\n

        The vectors on the screen look clean. They look computed. They look authoritative.<\/p>\n

        They are a filtered estimate based on noisy measurements, processed through assumptions that may not hold, displayed with a latency that is invisible to the user.<\/p>\n

        8. Closing Reality<\/h2>\n

        ARPA is a computation layer on top of a radar picture. It does not improve the radar’s ability to detect targets. It does not guarantee that all targets are tracked. It does not respond to target manoeuvres in real time. It does not model the actions of other vessels in a trial manoeuvre. It does not warn when its own output has become unreliable due to filter latency or tracking ambiguity.<\/p>\n

        What it does is present processed data in a format that looks authoritative and complete. This appearance of completeness is the risk.<\/p>\n

        The raw radar picture \u2014 the echoes, the clutter, the gaps \u2014 contains truth that the ARPA overlay may obscure. A watchkeeper who watches only vectors and CPA readouts has delegated situational awareness to an algorithm. The algorithm does not look out of the window. It does not hear a fog signal. It does not sense that something about the traffic picture feels wrong.<\/p>\n

        ARPA is a tool. It is a good tool. It is not a replacement for the judgment it was designed to support.<\/p>\n

        The targets on the display are not ships. They are hypotheses.<\/p>\n","protected":false},"excerpt":{"rendered":"

        ARPA tracking degrades precisely when the navigational situation demands the most from it. Understanding why is not optional.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"fifu_image_url":"","fifu_image_alt":"","c2c-post-author-ip":"2a02:c7c:2ef8:2400:931:afb1:9971:4a62","footnotes":""},"categories":[10,1],"tags":[9080,9087,9076,1939,9079,9090,9092,9091],"class_list":["post-51592","post","type-post","status-publish","format-standard","hentry","category-bridge","category-latest","tag-arpa","tag-bridge-equipment","tag-collision-avoidance","tag-radar","tag-radar-plotting","tag-target-tracking","tag-trial-manoeuvre","tag-vector-stabilisation"],"acf":[],"_links":{"self":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts\/51592","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Fcomments&post=51592"}],"version-history":[{"count":1,"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts\/51592\/revisions"}],"predecessor-version":[{"id":51593,"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts\/51592\/revisions\/51593"}],"wp:attachment":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Fmedia&parent=51592"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Fcategories&post=51592"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Ftags&post=51592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}