ASTERIX CAT023 Integration: Reading Ground Station and Service Health

ASTERIX Category 023, usually called CAT023, carries ground station and service status reports for communications, navigation, surveillance and air traffic management infrastructure. It describes the systems producing information, rather than an aircraft's position. Integrating these reports means preserving the difference between station status, individual service health, reporting configuration and statistics. A translated status message does not, on its own, establish that a downstream feed is fresh, complete or suitable for use.

SynapseCommand's published adapter provides a concrete example of those boundaries. Its CAT023 implementation reference documents support; this article examines the consumer decisions that remain after translation.

At a glance

EUROCONTROL's publication record lists Edition 1.3, published on 28 September 2021. The pinned adapter manifest declares that edition. This analysis uses synapse-cdm v3.3.0, reviewed on 11 October 2026; it is not a new-product or deployment announcement.

Separate the station, the service and the target

The Edition 1.3 specification distinguishes three report types. Ground station status concerns the station. Service status concerns a particular service. Service statistics carries counters associated with a service. Their required data-item sets differ, so one generic status object can hide which question the source actually answered.

In the inspected implementation, a conforming station-status record produces a station Entity and a status-change Event. Service-status and service-statistics records also produce a service Entity. The adapter source connects the event to the relevant station and service objects rather than turning each counter into a target observation.

Service identifiers are local to a station. Service 3 at one station must not become the same entity as service 3 at another. The identity therefore combines the station's System Area Code and System Identification Code, commonly SAC/SIC, with the service identifier. Conversely, separate services at one station remain separate objects even when they share infrastructure.

This differs from the CAT021 target-report reference, whose subject is the reported target. The preceding CAT021 report-context analysis addresses target-report time and quality. CAT023 adds infrastructure context, but its translator does not automatically join that context to a stream of target reports.

The ASTERIX family overview also distinguishes Category 034, which has its own monoradar status contract. Similar-looking binary containers do not make these categories interchangeable. The CAT023 wire codec documents why a superficially compatible field-specification layout can still assign entirely different meanings to the bytes.

A status code does not replace the source flags

The service-status vocabulary distinguishes unknown, failed, disabled, degraded, normal and initialisation. The adapter maps these to canonical severities, while preserving the original status and the basis for that mapping. Those severity choices are implementation decisions, not a replacement for the source vocabulary or a universal operational policy.

The published adapter tests make the distinctions explicit. Failed maps to CRITICAL; degraded and disabled map to WARNING; normal and initialisation map to INFO; unknown maps to ADVISORY. A disabled service is not silently relabelled as a failed service. All remain status-change events in this mapping.

NOGO is especially important. It indicates that the station's data is not released for operational use. The translator preserves this indication but does not raise event severity from NOGO alone. A consumer that looks only at severity can therefore miss a consequential restriction carried in the source attributes. This is a reason to define a consumer policy explicitly, not to discard the flag because the event appears routine.

The same source distinguishes processing overload from transmission overload. It also preserves a station-reported spoofing indication without reclassifying it as a GNSS-interference event. Neither a severity label nor a broad “healthy/unhealthy” field can carry all of those distinctions faithfully.

Reporting periods are not validity deadlines

Three reporting-period concepts appear in this small category: the ground station status reporting period, the service status reporting period and the configured period for CAT021 reports. They refer to different outputs. Using one as a universal timeout would apply a source statement beyond what it describes.

The field coverage document and codec distinguish their units and special values. In the CAT021 report-period field, zero denotes data-driven mode. It is not a zero-second interval. The ground station and service status periods use a different scale and exclude zero from their valid ranges.

The adapter leaves `valid_to` unset, including where a reporting period is present. It does not infer when an observation expires or when the consumer should declare a service unavailable. An application can implement a freshness policy, but that policy needs its own treatment of delayed delivery, missing reports and changes of mode.

Time itself also needs context. The implementation resolves CAT023 time of day against an injected receipt clock because the field carries no calendar date. The specification permits omission when all timestamping sources fail; the adapter records the absence and uses receipt time as its fallback. A supplied time-source-validity flag is retained separately rather than silently erasing the reported time.

For a receiving system, observation time, receipt time, source-clock condition and locally chosen expiry are four distinct facts. The architecture overview places translation within a wider integration boundary; the canonical data model documentation provides the model context for implementing that distinction.

Counters need their own reference period

A service-statistics record can contain several counters. In this adapter, they remain an ordered list, including duplicate counter types. Converting the list into a dictionary keyed only by type could overwrite information the source actually sent.

Each counter also carries its own reference: from midnight or from the last report. A single record can therefore contain counters with different reference periods. The statistics implementation preserves that per-counter distinction and documents why the encoded reference takes precedence over broader wording in the specification's item description.

The translator does not turn a message count into the same number of detections. It also does not calculate a rate by dividing a count by a convenient reporting-period field. That field might describe a different feed, and the counter's accumulation basis might differ from the assumed interval.

If downstream analytics needs rates or trends, its contract should identify the counter type, reference basis, elapsed interval and handling of resets or discontinuities. Those are analytical requirements proposed here, not additional capabilities attributed to the adapter. Keeping the raw counters available allows such decisions to be reviewed later.

Operational range does not locate a station

CAT023 has no coordinate item. Its operational-range field therefore cannot, by itself, produce a geographic footprint. A distance without a centre is insufficient to draw a coverage circle, and the existence of a station identifier does not supply a location.

The adapter consequently emits no entity position, event geometry or kinematics. It does not look up coordinates in a previous Category 034 message or accept an injected station position. This boundary is explicit in the source and tests, rather than an undocumented omission.

The maximum encoded operational range has another qualification: it means that value or above. The implementation retains the numeric value with that limitation. Treating it as an exact measured edge would invent precision the source did not provide.

A separate, authoritative station inventory could support a downstream geographic association. That would introduce another source, its identity rules and its update history. It must be described as enrichment outside this adapter, not as a location decoded from CAT023 or proof of actual coverage throughout a region.

A synthetic service-health handover

Consider an explicitly synthetic sequence for one station and service 3. A station-status record carries NOGO. A separate service-status record reports “normal” and specifies data-driven CAT021 reporting. A subsequent statistics record contains one counter accumulated from midnight and another accumulated since the last report.

These statements should remain separate. “Normal” does not cancel the station's operational-release restriction. Data-driven mode does not imply a zero-second reporting interval. The two counters do not acquire a common accumulation period merely because they occupy one statistics record.

The receiving application must also decide whether its records are current enough to combine. The adapter does not maintain the cross-record state needed to apply one station's latest restriction to every later target report. That association belongs in the consumer, with explicit handling for missing, delayed or superseded status information.

This example is an engineering synthesis of the published mapping, not a recorded incident or a claim about an installed system. It demonstrates why preserving fields is necessary but insufficient: the application must still define which evidence governs its current view of a service.

What bidirectional support and evidence mean here

The open integration package provides source and reproducible test material. For CAT023, egress reconstructs records from the source-derived station Entity carrying the necessary representation. A service Entity alone is insufficient. A generic sensor object or a Track does not become a valid CAT023 block merely because it exists in the canonical model.

Derived times, scaled distances and canonical severities are views of the source, not general-purpose wire-authoring fields. Editing such a view does not establish that a corresponding changed value will be emitted. The relevant egress tests assess reconstruction of the supported source-derived representation.

The fixture provenance records identify synthetic inputs. The inspected manifest declares L3 and reports byte-level fixture round-trip success, while retaining heuristic field-preservation limits. It does not declare L4 or record an independent external-system exercise. This article inspected the published code and tests; it did not rerun them.

Structural checks cover category, block length, field structure and required items, with specified exceptions and preserved anomalies. They are not authentication of the sender or proof of a service's true condition. The adapter catalogue and trust and assurance boundary should be read with the same distinction between implementation evidence and accepted system behaviour.

Agree the consumer policy before accepting the feed

This is a proposed engineering handover, not a standards-mandated checklist. Its purpose is to ensure that the application can explain both what the station reported and what the application decided. CAT023 becomes more useful when those two layers remain distinguishable, including when information is missing or its meaning is unresolved.