ASTERIX CAT021 Integration: Preserving Time, Quality and Report Context

ASTERIX Category 021, usually called CAT021, is a format for exchanging ADS-B target reports. Integrating it requires more than extracting an aircraft position. The receiving system must retain what each timestamp describes, how quality indicators should be interpreted and which station supplied the report. Losing that context can produce a plausible map entry with an incorrect date, an unjustified accuracy claim or an unclear source.

This article examines those decisions using SynapseCommand's published adapter as a bounded implementation example. The CAT021 implementation reference remains the support reference; the focus here is how an engineering team should interpret and accept the resulting data.

At a glance

The edition and implementation boundaries above come from the pinned CAT021 manifest, read alongside the EUROCONTROL publication record. The evidence baseline is synapse-cdm v3.3.0, reviewed on 11 October 2026. This is an analysis of existing support, not an announcement of a new adapter.

Pin the edition before interpreting the report

“CAT021 supported” is an incomplete interface contract. The category number does not establish the edition, supported expansion fields or interpretation of every optional item. EUROCONTROL's Edition 2.6 specification explicitly excludes backward compatibility with Edition 2.1 and earlier. It also describes partial ADS-B Version 3 coverage and points to the Reserved Expansion Field for much of that work.

The newer Edition 2.7 specification is a separate standards baseline. Its publication does not upgrade software that declares Edition 2.6. An integration team needs an agreed producer and consumer profile before interpreting a successful parse as evidence of compatibility.

There are two different version questions here: the CAT021 document edition and the ADS-B MOPS version represented in a report. MOPS means Minimum Operational Performance Standards. Confusing them can lead to applying the right field layout with the wrong quality vocabulary.

The ASTERIX family overview places CAT021 among other categories. The earlier raw ADS-B integration analysis addresses the feed-selection question. Once CAT021 is the agreed input, the problem shifts to preserving the semantics of the processed report.

One report can contain several different times

The published adapter distinguishes position applicability, position reception, velocity applicability, velocity reception and report transmission. Its preferred observation time follows that order when the relevant items are present. Position applicability describes a different event from a ground station sending the assembled report; treating both as an undifferentiated “timestamp” hides that distinction.

The time-selection implementation records which item supplied the observation time. When no supported time item is present, it uses receipt time and records that the source supplied no observation time. That fallback should remain visible to downstream consumers.

CAT021 supplies time of day without a calendar date. This adapter considers that time on the receipt date, the previous day and the following day, then selects the nearest instant. The receipt reference comes from an injected clock. This makes the date decision reproducible when the same clock context is supplied; it does not recover a missing historical date from the payload.

That limitation matters for replay. An archived report processed against today's receipt clock can be assigned today's nearby date. The replay system must supply the appropriate historical context. A successful parse cannot establish that the inferred date matches the original observation.

The adapter also rejects the ordinary time-of-day value when it reaches or exceeds 86,400 seconds instead of silently wrapping it. Its published time and rollover tests include both midnight directions, missing context distinctions and precision preservation. These are inspected test definitions, not a new execution reported by this article.

Quality indicators need a vocabulary, not a percentage

A quality field is useful only if its quantity is known. In this implementation, the primary quality subfield is interpreted using the MOPS version item: the relevant alternatives include NUCr versus NACv and NUCp versus NIC. When the version is absent, the adapter retains the bits and records the interpretation as undetermined.

The same adapter source explains why it does not turn these categories or containment bounds into `Position.accuracy_m` or `Entity.confidence`. A bound is not automatically a one-standard-deviation error estimate, and position quality is not confidence in an object's identity.

Range-check failures illustrate the division of responsibility. The adapter carries the report and its flag rather than suppressing the object inside translation. The receiving application must decide how the flag affects display, storage or further processing. Retaining a report is not a recommendation to treat it as valid.

For implementers, the architecture overview helps locate that consumer decision beyond the adapter boundary. The canonical data model documentation provides the complementary model context. Neither makes an absent quality interpretation safe to invent.

Aircraft identity and station identity answer different questions

An aircraft address identifies the reported subject within a stated address scheme. The SAC/SIC pair identifies the reporting data source. Keeping only one of these loses a different part of the report's meaning.

The adapter places genuine ICAO 24-bit aircraft addresses in the same identity namespace used by the raw ADS-B adapter. That allows the same address to derive the same entity identifier across those formats. It does not, by itself, authenticate the aircraft, correlate independent observations or resolve duplicate-address problems.

Address type changes the interpretation. The source routes duplicate, surface-vehicle, anonymous and reserved address types into a separate non-ICAO namespace. The field coverage document and adapter tests make these choices reviewable. An identifier that looks familiar should not override the descriptor that says what it means.

For newly synthesised output, station identity is also a configuration requirement. The adapter can reuse source station codes already carried by a CAT021-derived object. Otherwise, it requires a supplied station pair; it does not invent one. It likewise requires an appropriate source address rather than manufacturing an aircraft identity from an unrelated canonical identifier.

Preserving a report is different from updating it

The implementation keeps original item octets alongside the canonical view. This supports byte-preserving re-emission of ingested fixture reports, including precision and spare-bit details that would not survive reconstruction from normalised values alone.

There is an important consequence in the egress implementation. When an entity still carries the parked CAT021 items and field specification, egress restores that representation. Changing a canonical coordinate alone therefore does not establish that the outgoing record will contain the edited coordinate.

A team should distinguish original-report replay from synthesis of a changed report. Decide which representation is authoritative and test that chosen path. Do not describe byte-preserving replay as a general-purpose canonical editing workflow, and do not remove provenance casually to force the other path.

Track output raises a related time issue. A track can become multiple records in one block, carrying each sample's time of day. The calendar dates still do not travel in those fields. Re-emitting a historical track requires a receiving replay convention; preserving the clock values alone cannot communicate the original dates.

A synthetic midnight handover

Consider a deliberately synthetic report with position applicability time 23:59:58.500 UTC. Its injected receipt instant is 16 October at 00:00:01.100 UTC. The nearest-date rule assigns the observation to 15 October, 2.6 seconds before receipt, and records that basis.

Now suppose the same report contains quality bits but no MOPS version item. The date can be resolved under the supplied clock context while the quality vocabulary remains undetermined. One resolved field does not make the whole record fully interpreted.

If a range-check failure is also present, translation preserves that indication. The handover needs three separate decisions: whether the replay clock is appropriate, how unresolved quality is represented, and what policy governs the flagged report. None follows automatically from the presence of a position.

Replaying those same bytes a month later with a different clock context demonstrates the limitation: the original calendar date cannot be recovered from time of day alone. The example describes the inspected selection rule; it is not a measured deployment result or a claim about a receiving system's operational behaviour.

What the published evidence establishes

SynapseCommand's open integration package makes the implementation and evidence available for inspection. In the pinned release, the CAT021 manifest declares **L3**, despite reporting successful byte-level fixture round trips. Its explanation is specific: field preservation relies on a value-presence heuristic, without the path-bound mapping ledger needed for its L4 declaration.

That is a statement about the inspected release manifest, not a maturity upgrade inferred from one passing test. The validation harness separately reports translation, schema, preservation, provenance, repeatability and round-trip checks. No independent external-system exercise is recorded in the inspected declaration.

Structural acceptance is also bounded. The adapter checks block length, record structure and defined fields; it does not authenticate the sender or establish transport integrity. The source notes that an altered value inside a structurally valid fixed-length field can still parse. Format validity and trustworthy measurement are different claims.

The broader adapter catalogue contains separate declarations for other formats. This article does not extend CAT021 evidence to them. The trust and assurance boundary likewise remains separate from claims of certification or operational acceptance.

Make context part of the acceptance contract

An integration review should specify what the receiving system must preserve and how unresolved information is handled. A concise handover can make those responsibilities testable.

This is an engineering synthesis, not a standards-mandated checklist. Its purpose is to prevent a translation success from hiding an unresolved handover decision. A useful CAT021 integration leaves the next component able to explain where the report came from, what its time and quality mean, and which judgements still belong to the consumer.