ASTERIX CAT034 Integration: Radar State Is Not a Coverage Map

ASTERIX Category 034, usually called CAT034, carries monoradar service messages: information a radar station sends about its own state and operation. Integrating that information requires a clear distinction between the station, its reported configuration and any geographical interpretation added downstream. A station coordinate and a polar window do not automatically establish a coverage map, and a service message is not an aircraft detection.

SynapseCommand's published adapter makes those boundaries inspectable. The CAT034 implementation reference documents support; this article examines the interpretation and acceptance decisions that remain with the receiving system.

At a glance

EUROCONTROL describes CAT034 as a monoradar service-message category. The inspected adapter manifest declares Edition 1.29. The evidence baseline was reviewed on 11 October 2026. This is an analysis of existing implementation scope, not an announcement of a new integration or deployment.

A service message describes the radar, not a target

The Edition 1.29 specification defines seven message types, including north-marker, sector-crossing, geographical-filtering and several interference-related reports. These messages carry different item combinations. Treating every record as a generic target update loses both its subject and its purpose.

The inspected adapter produces a sensor Entity and an Event for each record. Station identity derives from the System Area Code and System Identification Code, or SAC/SIC, using the ASTERIX station namespace. The adapter source preserves this identity across records from the same station without claiming to assemble a stateful radar history.

An antenna-sector value illustrates the semantic risk. It describes the antenna's orientation context; it is not the station's course of travel. The implementation therefore leaves kinematics unset. Likewise, configuration flags and per-revolution counts do not become a numerical confidence in the station's identity.

The ASTERIX family overview separates this category from target-report formats. The preceding CAT023 service-health analysis concerns ground station services and their status. CAT034 adds a different contract, with radar-specific message types, configuration and polar information. Similar infrastructure subjects do not justify sharing all their interpretation rules.

A station position is not an automatic cross-feed join

Unlike CAT023, CAT034 can carry the station's own WGS-84 position. In this implementation, that position becomes a field on the Entity produced from the record containing it. The adapter does not maintain a station-location cache or pass the coordinate automatically to another adapter.

That matters when using the CAT048 target-report reference. A target report's positioning contract remains separate. Finding a plausible station coordinate elsewhere in the input stream does not establish that the integration has selected the correct coordinate, at the correct time, under an agreed interpretation.

The published CAT034 tests explicitly check that ingesting the station position does not resolve the documented CAT048 positioning gap. This is an implementation boundary, not evidence that combining information is impossible in a larger system.

A downstream association can be designed and reviewed separately. It needs an identity rule, a choice of authoritative position source and a policy for changes or conflicting observations. These are proposed integration responsibilities, not features attributed to this adapter. The architecture overview is the relevant bridge from payload translation to those wider responsibilities.

Why the polar window remains a polar window

A CAT034 generic polar window supplies range and azimuth limits relative to the radar. Drawing a geographical polygon would require a station location and an explicit geometric interpretation. In the pinned edition's item-presence table, the station-position item and polar-window item are not permitted together in any of the seven defined message types.

The field coverage document explains the consequence for this implementation: a conforming window record would need position information from another record before a geographical conversion could be attempted. The translator therefore preserves the four source values and their scaled views without producing event geometry.

It also declines to derive geometry when a nonconforming record supplies both items. Otherwise, malformed input would gain a geographical interpretation that conforming input does not receive. Retaining unexpected source content is different from allowing it to authorise additional calculations.

A window's purpose matters as much as its coordinates. A geographical-filtering message describes filtering scope; it is not automatically a measured sensor-performance boundary. The adapter also records that a filter without a polar window applies throughout the stated coverage scope. That absence is not the same as a filter being switched off, nor does it supply the shape of a coverage polygon.

If an application adds geometry, it should retain the original window, the separate position evidence and the transformation decision. Calling the result a “coverage map” would require an additional basis for that label. This article proposes that distinction as an acceptance requirement; it does not claim the public adapter performs that enrichment.

Configuration and processing mode describe different facts

System configuration and status describe a different aspect of the radar from its processing mode during the last antenna revolution. The adapter preserves them under separate keys. Flattening both into one “radar mode” field makes it harder to establish whether a value describes selected configuration or reported processing behaviour.

The same source implementation shows why even identical bit patterns need their subfield context. A channel-selection pattern can mean diversity operation for one radar component and an invalid combination for another. A shared label would erase that difference.

The processing reduction steps are particularly easy to overstate. The published mapping preserves the step value; the relationship between that step and an actual reduction measure is not standardised in the cited item. “Step 3” cannot safely become a percentage merely because a dashboard needs a number.

Collimation error is another distinct quantity: it concerns the reported difference between primary and secondary radar target-position calculations. The adapter does not place it in `Position.accuracy_m`. The canonical data model documentation provides the model context, but a destination field's availability does not make a source quantity equivalent to it.

Message labels do not justify stronger event claims

In the inspected mapping, the three jamming-strobe message types become ALERT events with WARNING severity. Other defined types become status-change events with INFO severity, including the solar-storm message. These are the adapter's documented classifications, not a universal judgement of operational significance.

The source explicitly avoids converting a radar jamming report into a GNSS-interference event. A category-specific indication does not establish the frequency, mechanism, location or attribution of an interference source. The article draws no conclusions about those matters and describes no procedure for acting on them.

An undefined message type remains visible as unresolved information, with an advisory classification. It is not silently treated as a known routine message. This is especially relevant when a producer and consumer have different edition assumptions: accepting the record structurally does not mean understanding its message type.

Source flags also remain important alongside event classification. For example, the operational-use restriction carried by NOGO is preserved rather than used by this adapter to raise severity. Consumers must inspect the retained meaning instead of assuming a non-alert event authorises use of associated target data. The tests document that preservation boundary; a complete receiving-system policy still needs separate acceptance.

Edition and time context belong in the interface contract

The implemented baseline is Edition 1.29. During this review, EUROCONTROL's category publication page offered that edition as its newest listed download. The repository's document pin and availability record separately records references to Edition 1.30 in sibling specifications and distinguishes those citations from obtaining the document itself.

The precise statement is therefore the useful one: this adapter is written against 1.29, and this review did not establish a downloadable 1.30 text. A citation alone does not justify claiming support for its contents. Nor does the absence of a download on one page prove that the edition has never been published elsewhere.

Time has a similarly explicit boundary. CAT034 time of day contains no calendar date. The implementation resolves it using an injected receipt clock, records its basis and retains a receipt-time fallback where the source time is absent. Its item rules recognise the timestamping-failure exception rather than treating every missing time as malformed input.

An antenna rotation period does not cause the adapter to populate a validity deadline. Archived replay still needs appropriate clock context, while downstream freshness decisions need their own policy. Those distinctions should survive both storage and later review.

A synthetic two-record handover

Consider an explicitly synthetic example. A north-marker record carries a station position. A later geographical-filtering record from the same SAC/SIC carries a polar window and a defined data-filter value. The records have distinct source times.

The translator produces separate station-related observations. The first can contain the supplied position. The second retains the filter and window but no event geometry. A repeated station identifier supports consistent identity derivation; it does not mean the adapter has decided which earlier coordinate remains authoritative for the later record.

A consuming application that wants a map overlay must make that association explicit. It must also label what it displays: filter scope derived under recorded assumptions is not automatically validated radar coverage. If the earlier position is missing, stale under the application's policy or disputed, that uncertainty should not disappear merely because the drawing routine accepts a centre point.

This example is editorial synthesis, not recorded traffic or a deployment result. It shows where translation ends and an additional interpretation begins. The value of keeping both layers is that a reviewer can distinguish source content from the decisions used to display it.

What the evidence and acceptance contract should establish

The open integration package exposes source and test material. CAT034 egress reconstructs the required source-derived representation; it does not synthesise arbitrary service messages from generic canonical objects. Derived coordinates or scaled views are not a promise of a general editing-and-emission workflow.

The fixture provenance records identify synthetic inputs. The pinned manifest declares L3 despite successful byte-level fixture round trips, because field-preservation evidence remains heuristic rather than path-ledger based. It records no independent external-system exercise. This article inspected the source and tests without rerunning them.

The adapter catalogue contains separate declarations for other formats. The trust and assurance boundary should likewise remain distinct from deployed-system acceptance. Structural parsing checks do not authenticate the sender or independently verify a radar's reported condition.

This is a proposed engineering handover, not a standards-mandated checklist. Its purpose is to keep radar statements, adapter mappings and application decisions distinguishable. That distinction lets an integration explain what its map or event stream means without making the underlying source claim more than it actually reports.