ASTERIX CAT048 Integration: Preserving Radar Report Identity

ASTERIX Category 048, usually called CAT048, carries monoradar target reports. Reliable CAT048 integration must distinguish the identity of a report, a station's local track number and an aircraft address. Those identifiers serve different purposes. Reusing a track number does not establish permanent aircraft identity, and ending a track record does not mean an aircraft has ceased to exist.

SynapseCommand's CAT048 implementation reference describes its adapter support. The engineering question examined here is what that implementation preserves, what it derives and what an integrating application must still decide.

At a glance

The release-pinned manifest is the evidence baseline for these implementation statements. EUROCONTROL's CAT048 publication page lists Edition 1.32, published on 2 July 2024. The base specification and the adapter's declared coverage remain separate things.

Keep report identity separate from aircraft identity

A surveillance record can contain several identifiers without supplying one universally reliable answer to “which object is this?” Source station, aircraft address, aircraft identification and local track number describe different relationships. Applications that collapse them into one unqualified key can accidentally merge records or discard continuity information.

In the inspected adapter source, the presence of the I048/220 aircraft address selects an ICAO24-based identity. Its namespace is shared with the project's ADS-B and CAT021 handling. That makes equivalent address values comparable; it does not implement cross-feed correlation, verify that the sender is entitled to use the address or resolve conflicting reports.

The distinction matters when comparing the CAT021 implementation reference with this adapter. A common key representation is useful infrastructure, but an integrating system still needs an explicit association policy. The CAT048 implementation also retains a caveat for a reported duplicate or illegal Mode S address. An address-derived identifier should therefore not be presented as proof of a unique physical airframe.

CAT048's role is also narrower than “all radar data.” The ASTERIX family overview separates category responsibilities. A target report, a radar service message and a system track should not inherit one another's semantics merely because they share a transport or a common data model.

A local track number does not establish permanent identity

Without an aircraft address, the adapter constructs a CAT048 report identity from station identifiers, raw time-of-day and polar measurement context where available, plus the record index. It deliberately does not use I048/161, the local track number, as the canonical identity key. That number is station-scoped and can be recycled.

This choice avoids treating a recycled number as a permanent aircraft identifier. It also creates a real limitation: repeated reports with the same local track number can become different canonical entities. The adapter tests explicitly exercise two scans with the same track number and different entity identities. The number remains available in preserved attributes, but the canonical identity alone does not carry the local track's continuity.

The report identifier includes time-of-day context rather than an independently verified calendar date. It should not be advertised as an unlimited historical deduplication key. A receiving application needs to document its own retention, replay and association assumptions. The architecture overview provides the broader system context; the adapter's identity construction does not itself supply that application policy.

End of track is a lifecycle statement about a track record

An end-of-track indication concerns a record within a track file. It is not a declaration that the represented aircraft has disappeared permanently. In this implementation, the flag is preserved and the entity's `valid_to` remains unset.

There is an additional identity complication. Edition-dependent presence rules allow certain Mode S items to be absent on an end-of-track record. The Edition 1.32 specification provides the normative item and presence definitions; the adapter implements the relevant exception rather than inventing an omitted aircraft address.

Consequently, an earlier address-bearing report and a later track-ending record without that address need not arrive with the same canonical identity. Consumers cannot safely equate “close this local track” with “retire this globally identified aircraft” merely by reading the entity identifier. Any association back to earlier reports must use an explicit downstream rule and retained source context. That requirement is an integration responsibility, not a claim that the adapter contains a tracker.

Classification and confidence need their own evidence

Identity errors are not the only way to overstate a target report. Classification and confidence can become misleading if preserved source fields are treated as stronger conclusions than the implementation makes.

The adapter retains report descriptors and relevant classification information, but does not turn every classification code into a refined canonical entity type. Flags or codes concerning reflections, sidelobe replies, birds or other phenomena are not an implemented general-purpose clutter-discrimination service. Likewise, preserved quality components are not automatically a numerical probability that an aircraft identity is correct.

The release's field-coverage notes and adapter source describe these mapping boundaries. Affiliation remains unknown rather than being adjudicated from surveillance data. Canonical confidence and track-quality fields are not populated with an invented score.

The practical handover is to distinguish a field that was decoded, a value that was preserved and a conclusion that was derived. A user interface should retain that distinction instead of displaying absent confidence as zero, or a source classification as independently verified identity. The canonical data model documentation is the place to check the receiving fields and their intended meanings.

Position depends on declared configuration and source context

The default adapter configuration does not supply a sensor position. Without that site context, it preserves the source's polar measurement while leaving geographic entity position absent. Merely parsing range and azimuth does not provide a latitude and longitude.

Position derivation requires suitable inputs and configuration. The inspected implementation accepts a caller-supplied site position, including height referenced to mean sea level. It prefers the available geometric-height item and can use pressure flight level as a declared approximation. Missing usable height can still prevent position derivation even when the site has been supplied. The adapter source also handles range-boundary conditions that prevent a derived position.

Where the implementation produces latitude and longitude, the position is marked estimated. It does not automatically populate a canonical altitude or horizontal accuracy, and it does not create event geometry. Calculated local Cartesian coordinates are not simply promoted into a geographic position either. These are specific mapping choices, not evidence of validated global positioning accuracy.

The preceding CAT034 radar-state analysis explains why a station-position message is not an automatic positioning update for another category. This CAT048 adapter does not consume CAT034 records to maintain a site cache. The integrating application supplies the context.

That makes configuration part of reproducibility: identical report bytes processed with different site settings can yield different canonical position views. Time-of-day interpretation similarly needs its date/clock basis recorded. A byte-perfect replay alone cannot prove that either contextual interpretation was correct.

Preserved extension bytes are not interpreted fields

CAT048 has a separately published Reserved Expansion specification. EUROCONTROL's Appendix A publication page lists Edition 1.13, published on 4 December 2024. The existence of that specification must not be confused with this adapter's semantic coverage.

The inspected adapter preserves Reserved Expansion bytes opaquely. It does not interpret those bytes as implementation support for every field in Appendix A. Preserving a payload can protect information for a later consumer while leaving its meaning unresolved in the canonical model.

The same distinction applies to egress. The adapter reconstructs CAT048 from the required source-derived representation, including retained item bytes and field-presence information. It is not a general-purpose encoder for arbitrary canonical entities or tracks. Editing a derived geographic position does not establish a supported operation for authoring a new radar measurement on the wire.

A synthetic two-scan handover

Consider a synthetic integration example with two reports from one station. Neither contains an aircraft address. Both carry local track number 199, while their measurement times or positions differ. A subsequent end-of-track record refers to that local track.

The first two reports can receive different canonical identities because their report contexts differ. An application that expects one persistent entity per local track would therefore need additional association behavior. The preserved number provides context for that decision; it does not by itself specify the decision. The ending record then concerns the track's lifecycle without authorising the deletion of a physical-aircraft identity.

A useful acceptance exercise checks three separate outputs: the decoded source attributes, the canonical identity and the consumer's explicitly documented handling of continuity. If only the final screen is inspected, a visually continuous symbol can conceal a heuristic association. If only byte roundtrips are inspected, a downstream continuity gap can remain invisible.

This example is editorial synthesis grounded in the inspected tests. It is not a report of an operational deployment, a benchmark or a prescribed tracking algorithm.

What the evidence and acceptance contract establish

The open integration package makes the implementation inspectable. For this article, the baseline is synapse-cdm v3.3.0. Source and tests were inspected; no new test execution or external endpoint exchange was performed for this analysis.

The pinned manifest declares L3 and heuristic preservation, with byte-roundtrip fixture results. The fixture provenance identifies synthetic material. These are useful implementation checks, but they do not establish independent external-system interoperability, correct aircraft association or operational acceptance.

The adapter catalogue gives other formats their own declarations; a result for one adapter does not transfer automatically to another. The trust and assurance boundary remains relevant when moving from inspectable software evidence to a deployment decision.

A sound CAT048 handover therefore preserves both the report and the limits of its interpretation. It makes identity, continuity, position context and track lifecycle reviewable before an application turns them into a persistent view of the world.