ASTERIX: which categories are implemented, and in which direction

ASTERIX, the All Purpose Structured EUROCONTROL Surveillance Information Exchange, is not one format. It is a family of categories, each defined by its own specification document, sharing a common data block envelope of category octet, length and a field specification bitmap followed by data items.

Categories are allocated by purpose rather than by vendor. Category 021 carries ADS-B target reports as a ground station has already processed them, category 048 carries monoradar target reports from a single radar, category 034 carries the service messages a radar sends about itself, category 062 carries system track data from a tracker, and category 023 carries ground station status.

Because a data block is a tiled sequence of records with no checksum, structural conformance is the only integrity gate the format offers. A block that does not tile exactly, a field specification bit that names an undefined field reference number, or an item that runs past the record boundary are all defects that a lenient reader would silently absorb.

ASTERIX is the exchange format most European air surveillance infrastructure already speaks. A recognised air picture assembled from radar, multilateration and ADS-B ground stations is very often an ASTERIX stream before it is anything else.

For a decision-support layer, that matters because the alternative to reading ASTERIX is reading a downstream system's private rendering of it, which means inheriting that system's judgements about quality, identity and time without being able to see them.

The categories SynapseCommand implements cover both what a sensor detected and what the sensor said about itself. Sensor health is a decision input: a track thinning out because a radar is in a test mode is a different situation from a track thinning out because the target changed behaviour.

Each category has its own adapter module, and they deliberately share no translation code. A single generic ASTERIX reader would create the appearance of a common basis where the specifications do not provide one, so each category is implemented against its own pinned document.

Ingest turns one data block into one Entity and one Event per record, in block order. A block legitimately carries several records naming several aircraft, and each is a report in its own right.

Egress re-emits from the parsed integers rather than from any derived floating point value, which is what makes byte exact output possible for records that came from the same category.

The full field by field mapping for every category is published as FORMAT_COVERAGE.md in the repository. That document is the specification the code is written against, and a test resolves every canonical path in it against the models so the two cannot drift apart.