ASTERIX CAT062 Integration: Track Freshness and Fusion Provenance

ASTERIX Category 062, usually called CAT062, carries system-track messages from a surveillance data processing system. A newly received CAT062 message is not proof that every contributing observation is equally recent. Track time, update ages, coasting indicators and calculated values describe different parts of an upstream processing result. Reliable integration preserves those distinctions and identifies which system made each judgement.

The SynapseCommand CAT062 implementation reference describes the adapter's support. This article examines the freshness and provenance questions an integrating team must resolve before treating a processed track as a current observation.

At a glance

These implementation statements use the release-pinned manifest as their baseline. EUROCONTROL's CAT062 publication page lists base Edition 1.21, published on 5 June 2025. The expansion-field edition requires a separate check, discussed below.

A system track carries an upstream judgement

CAT062 is a processed surveillance product. Its record may describe a monosensor or multisensor track, and can carry information about amalgamation, contributing sensors, estimated accuracy and processing status. The existence of a system track does not establish that multiple independent sensors corroborated every field.

The inspected adapter source collects the upstream system's processing statements under `fusion_provenance`, with the emitting system's SAC/SIC identifiers. Contributing-sensor lists remain source statements. They do not become additional entities, authenticated source relationships or joins to other feeds.

This boundary is useful when comparing categories through the ASTERIX family overview. Receiving a CAT062 track alongside CAT048 reports does not automatically establish which particular reports created that track. The source may provide association context, but reconstructing and evaluating the relationship remains separate work.

Even when several records arrive together, the adapter emits individual Entity/Event pairs. It does not assemble an observed trajectory or produce a canonical Track. The distinction separates translating a processor's output from implementing another tracker inside the translator.

Track time and update age answer different questions

A track-state timestamp describes the state vector's time. Receipt time records when the adapter receives the data under its supplied clock. Neither makes every underlying input equally fresh.

CAT062 can carry update ages by surveillance technology in I062/290 and ages for individual track-data parameters in I062/295. Those fields allow one record to contain several different age statements. A recently updated track may still retain information whose source update is older. The preceding CAT021 time-and-quality analysis covers report-level time distinctions; CAT062 adds the context of an upstream processor combining and maintaining state.

The adapter preserves raw ages and their scaled seconds, together with their definitions. It records the source formula for update age but does not convert those ages into independently asserted observation instants. The adapter tests explicitly check this separation.

Saturation needs particular care. The inspected tests include an update-age value of 63.75 seconds flagged as the maximum or above. That value is a lower bound in that field's context, not proof of an exact age. Two consecutive saturated values do not establish that age stopped increasing. A consumer that drops the qualifier changes the meaning while leaving the number intact.

Coasting flags need the emitting system’s context

A freshness flag can appear binary while still depending on information outside the record. The adapter preserves the source's coasting and technology-specific staleness indications. It does not use them to suppress values or apply its own universal expiry rule.

For the relevant staleness bits, the source describes thresholds as system-dependent. A zero/default value also needs context: the meaning differs depending on whether the emitting system supports the technology. The implementation therefore does not invert a clear bit into an unconditional claim that the technology contributed recently.

The field-coverage notes document the separation between preserved processing flags and downstream decisions. A receiving application needs the producer's interface information to interpret supported technologies and local conventions. It then needs its own documented handling of stale, absent or qualified data.

There is also a difference between a flight-plan correlation and a track created or updated with flight-plan data when surveillance information was unavailable. CAT062 can state that distinction, and the adapter retains it. A current-looking position on a display can therefore require a provenance explanation rather than being presented as a new sensor measurement.

Measured, calculated and predicted values must remain distinct

CAT062 can place calculated state, measured information and aircraft-derived data beside one another. They are not interchangeable observations of equal authority.

The adapter obtains canonical geographic position from I062/105, the calculated WGS-84 position item, and marks it estimated. It does not convert the separate Cartesian position item through an assumed reference point. Where the WGS-84 item is absent, it does not substitute a zero coordinate. The retained source representation preserves information that has no corresponding canonical position.

Altitude illustrates why the mapping needs more than a “best value” rule. Canonical altitude is taken from the geometric-altitude item with the appropriate ellipsoidal-height meaning. The tracker's relative-reliability flag does not cause the adapter to substitute pressure altitude into that field. Other altitude statements remain available separately. This is a datum-aware mapping choice, not an independent assessment of which sensor is right.

Measured information needs additional caution. The repository's specification pin and interpretation record records the specification's delegation of implementation-dependent meanings to the emitting system's Interface Control Document. In particular, a “last report” may mean the latest used or latest measured information. Comparing those values across systems without their interface definitions can compare different things.

Predicted trajectory points are also retained as intent, without being turned into event geometry or a flown path. The canonical data model documentation helps identify the output fields, but the integration must preserve whether each value was measured, calculated, predicted or left unresolved.

A source statement is not an application policy

Translation does not remove every implementation choice. It makes those choices inspectable. For example, the adapter does not turn a confirmed/tentative flag into a numerical identity-confidence score. Canonical confidence remains unset, rather than assigning an unsupported percentage.

Conversely, the inspected code does implement an explicit emergency-severity selection rule. A populated supported PS3 indication takes precedence; otherwise, the more severe of the available core emergency statements is selected. Source statements and detected severity disagreement are retained. This is a declared mapping policy, so “no additional fusion” should not be expanded into a claim that the adapter performs no selection or derivation anywhere.

Identity has its own boundary. An available Mode S address supplies the address-based identity. Without it, the fallback is report-scoped and includes the emitting system, raw track time, track number and record index. It does not promise continuity across updates. The CAT048 report-identity analysis develops the related distinction between a local track reference and permanent aircraft identity.

The architecture overview provides the broader integration context. Decisions such as display expiry, downstream association and treatment of inconsistent values need an explicit consumer policy. They should not be inferred from successful parsing, a populated position or a project verification label.

Base and expansion editions need separate checks

An integration specification that says only “CAT062 supported” leaves a material question unanswered. The base category and its Reserved Expansion Field have separate edition histories.

The inspected release declares base Edition 1.21 and Appendix A Edition 1.3. EUROCONTROL's current Appendix A publication page lists Edition 1.4, published on 5 June 2025, alongside the older 1.3. The newer document's availability is not evidence that this implementation supports it.

This matters when a base-specification note points to expansion content outside the adapter's pinned appendix. The correct acceptance question is whether the sender's actual encoding is covered by the declared parser and mapping. It is not enough to compare category numbers or assume that every referenced expansion container is implemented. The article's claims remain bounded to the inspected release; adopting a newer appendix would require its own implementation and evidence review.

A synthetic freshness handover

Consider a synthetic example in which a recently received system-track message carries a current track-state time, an older parameter age and an update age flagged as saturated. A later record also carries a coasting indication. These are illustrative conditions, not observations from a deployment.

A consumer that uses only message arrival time could display every retained value as fresh. A consumer that converts a saturated age into an exact timestamp could imply more precision than the source supplies. A consumer that silently drops the coasting flag could conceal the upstream system's own qualification.

The adapter's role is to preserve the relevant statements and their origin. An acceptance exercise should inspect the canonical output and retained context, then check the receiving application's documented presentation and expiry behavior. It should establish that the application can distinguish absent age, an exact decoded age and a qualified lower bound.

No universal timeout follows from this example. The producer's interface contract and the receiving application's requirements determine the relevant policy. The useful result is a reviewable connection between source meaning and consumer behavior, with any derived interpretation identified as such.

What an acceptance contract should retain

The open integration package supplies inspectable source and tests. This analysis uses synapse-cdm v3.3.0; source and tests were reviewed, but no new test run or external endpoint exchange was performed.

The pinned manifest declares L3 and heuristic preservation, together with published byte-roundtrip fixture results. The fixture provenance identifies synthetic material. Egress reconstructs the required CAT062-origin representation. It does not encode an arbitrary canonical Track or prove that an application interpreted the upstream track correctly.

Reproducible interpretation needs the same date/clock context as well as the same bytes, because time-of-day fields do not supply a calendar date. Fixture roundtrips alone do not establish operational freshness or independent interoperability. Other entries in the adapter catalogue have their own declarations, and the trust and assurance boundary remains separate from this source-level evidence.

The integration succeeds when a consumer can tell what the upstream processor stated, which parts remain qualified and what the receiving application decided. That is the practical value of keeping freshness and fusion provenance attached to a system track.