Air surveillanceImplementation status: BidirectionalInput supportedOutput supported

ASTERIX Category 023: ground station and service status, in and out

Category 023 is the smallest ASTERIX specification implemented in the open integration layer, and one of only two whose subject is the infrastructure producing surveillance data rather than the surveillance data itself. SynapseCommand publishes a bidirectional Category 023 adapter: data blocks become canonical objects, and objects that came from Category 023 re-emit as byte exact blocks.

About the standard

What CAT023 is

Category 023 carries reports from a CNS/ATM ground station about itself: whether the station is operational, what services it is providing, how those services are performing and how often they report. Nine data items make up the whole category.

The category distinguishes the station from the services it runs. A single ground station may provide several services, and the specification requires each service status to be reported independently, so a service is identified by the pair of the station address and the service identification allocated by that station.

It is the closest relative of Category 034, which does the same job for a monoradar. The two are implemented as separate adapters against separate documents, because a shared reader would imply a common basis the specifications do not provide.

Operational relevance

Why this matters to a commander

Sensor health is a decision input, not a maintenance concern. A thinning air picture caused by a degraded service is a different operational situation from a thinning air picture caused by changed target behaviour, and only the station's own status reports can tell the two apart.

Where an air picture is assembled from several ground stations, service level reporting says which parts of the picture are being maintained at their normal rate and which are running degraded, so confidence can be attributed to a region rather than assumed uniformly.

Carrying status through into the same canonical model as the tracks means an assurance record can show what the sensing infrastructure was reporting about itself at the moment a recommendation was produced.

What is implemented

The exact behaviour, not a capability claim

Ingest turns one data block into an Entity and an Event per record in block order. The station is the Entity, typed as a sensor, with no kinematics anywhere.

Two of the three report types describe a service rather than the station, and those records emit a second Entity for the service. Its identity is the pair of the station address and the service identification, because a service identification is allocated locally and means nothing across stations.

No object this adapter emits carries a position. The category contains no coordinate at all: its operational range item is a radius with no stated centre. Reading a station position out of a Category 034 record to locate a Category 023 station would be cross-payload state, and it is refused.

Times are counts since the previous midnight with no date, so the date comes from an injected clock and the adapter never reads the system wall clock.

Egress rebuilds a block from the parsed integers, so records that came from Category 023 re-emit byte exactly.

  • 01
    Direction in
    Category 023 data block, or its parsed dictionary equivalent, to a station Entity plus an Event per record, and a service Entity on the two service report types.
  • 02
    Direction out
    Objects that came from Category 023 to one byte exact data block. Anything else is refused with a statement of what is missing.
  • 03
    Report types
    Ground station status, service status and service statistics, each with its own mandatory item set enforced per record.
  • 04
    Position
    None. The category carries no coordinate, so entity position and event geometry are always absent and the reason is recorded on the object.
  • 05
    Integrity gate
    Structural only. The category defines no checksum, so length agreement, record tiling, defined field reference numbers, bounded extensions and non-zero repeat counts are the whole gate.
Direction of exchange

Which way the data actually moves

Into the canonical model

  1. CAT023 data block
    Category, length and one or more status records.
  2. Station and service Entities plus Events
    One Event per record; a second Entity on service reports.

Out of the canonical model

  1. Canonical objects from CAT023
    Only objects this adapter produced can be re-emitted.
  2. CAT023 data block
    Byte exact reconstruction from the parsed integers.
Workflows

Where this data is used

Sensor confidence in the recognised air picture

Station and service status arrive as canonical objects beside the tracks, so degraded service is visible in the same record as the picture it affects rather than in a separate maintenance channel.

Explaining a gap after the fact

Because status records are translated and retained like any other observation, a replay can show whether coverage changed because the infrastructure changed.

Round trip verification

An integration authority can take a shipped fixture, translate it in, translate it back out and compare the octets, using the published harness.

Implementation evidence

Every claim above has a file behind it

These paths are in the public repository, published under Apache 2.0. The adapter module for this page is asterix_cat023.

Source and fixtures

  • Adapter source
    packages/cdm/synapse_cdm/adapters/asterix_cat023.py

    Both directions, the per-report-type presence matrix and the position refusal at the site of the decision.

  • Wire codec
    packages/cdm/synapse_cdm/adapters/cat023_codec.py

    Item level decode and encode, kept separate from the translation.

  • Fixtures
    packages/cdm/synapse_cdm/fixtures/cat023/

    Raw blocks, parsed twins, golden canonical output and a refusals directory of malformed blocks that must not translate.

  • Field by field coverage
    packages/cdm/synapse_cdm/FORMAT_COVERAGE.md

    The Category 023 row set, written and reviewed before the adapter existed.

Test evidence

  • Harness test
    tests/test_cdm_asterix_cat023_adapter.py

    Replayed by the validation harness shipped in the same package, which runs six checks per fixture including a never-drop lossless check.

  • Lossless check
    tests/test_cdm_lossless.py

    Asserts that no leaf value present in a payload disappears without a declared reason.

Manifest-backed assurance

Maturity is declared in each generated adapter manifest and checked against suite eligibility. VERIFIED is a separate claim-status axis. Neither means external certification or integration with a named system.

  • asterix_cat023
    Maturity L4Claim VERIFIED
What these maturity levels mean

L3 means required provenance survives translation. L4 adds applicable roundtrip evidence. L5 would require every applicable public conformance gate to pass. L6 requires an independent real implementation or system and cannot be awarded from this repository's synthetic fixtures.

Status and limits

What is claimed, and what is not

Implementation status: Bidirectional

The published adapter implements both translation directions: the format into the canonical data model, and the canonical data model back out to the format. Both directions are replayed by the validation harness against shipped fixtures.

Last reviewed against the published implementation on 2026-09-06.

Limitations

  • This is one ASTERIX category and implies nothing about any other.
  • No position is produced under any circumstances, and no interface exists for supplying one.
  • The adapter is written against one pinned edition of the Category 023 specification.
  • There is no transport. Framing a network feed is the caller's job.

Security boundary

  • Only the translation contract is published. No station addresses, site data or deployment topology appear in the repository.
  • Every shipped fixture is synthetic and built by a published script from the pinned specification.

Public sources

Statements about what SynapseCommand® implements are drawn from the published repository rather than from these external sources.

Questions

Frequently asked

Why does a Category 023 record produce no position?
Because the category carries no coordinate. Its operational range item is a radius in nautical miles with no centre, and the station address is stated to be unambiguous without saying where the station is. An adapter that supplied a position would be stating a fact the format does not carry.
Why do some records produce two entities?
Two of the three report types are about a service rather than the station, and one station may provide several services whose status is reported independently. The service is a separate object identified by the station and service identification pair.
Is Category 023 egress byte exact?
For objects that came from a Category 023 block, yes. Anything else is refused with a statement of what is missing, rather than being approximated.
Related

Where to go next

Related C2 environments

Command environments in the compatibility catalogue whose published characteristics reference this standard. Each page states the current SynapseCommand integration status for that system.