ASTERIX Category 034: the radar as the subject of the record
Category 034 is what a radar says about itself rather than about what it detected. SynapseCommand publishes a bidirectional Category 034 adapter, and it is the first adapter in the set whose primary canonical object is a sensor.
What CAT034 is
A Category 034 record is a service message: a north marker, a sector crossing, a change of operating mode, a status report, or the station's own position and configuration.
Because every record describes the station, the shape of the canonical output changes. The source address becomes a genuine source identifier rather than a parked attribute, the entity type is a sensor, and no kinematics are produced at all. A station does not move, and the one bearing in the category belongs to the antenna rather than to a course.
The category defines no checksum at block, record or item level, so structural conformance is the whole integrity gate: length must be satisfied, records must tile the block exactly, presence bits must name subfields that exist, and the items the specification makes mandatory for the record's own message type must be present.
Why this matters to a commander
Sensor state is decision-relevant. A gap in coverage caused by a radar in a test mode is a different fact from a gap caused by terrain or by an adversary, and only one of the three is under friendly control.
Recording sensor state alongside track data makes an after-action review answerable. A commander reviewing a decision can see what the sensing environment actually was at the moment it was taken.
In a contested electromagnetic environment, degradation reported by the sensor itself is early warning rather than housekeeping.
The exact behaviour, not a capability claim
Ingest produces one Entity and one Event per record, in block order, with the radar station as the Entity.
The station's own position, carried in the service message, becomes a position on the station Entity and is handed to nobody. Reading it out of a Category 034 record in order to interpret a Category 048 record would be cross-payload state, which is the fusion behaviour every adapter here refuses. The corresponding gap in the Category 048 mapping stays open and is documented rather than closed.
No geometry is derived from the polar window item, because the specification makes that item and the station position mutually exclusive across all message types. The position could therefore only ever come from a different record.
There is no injected sensor position argument on this adapter, because the station position is already on the wire and accepting one anyway would create a second, silent authority for the same fact.
Egress is deliberately narrow. Entities that came from Category 034 are re-emitted as one data block, byte exactly. Anything else is refused with a message naming what is missing.
- 01Direction inCategory 034 data block to canonical sensor Entity and Event per record.
- 02Direction outEntities that originated in Category 034, back to one byte exact data block. Other objects are refused.
- 03Station identityThe source address pair is filed under a family-wide namespace rather than a category-specific one, because the allocation is family-wide.
- 04Integrity gateStructural only. The category defines no checksum.
- 05TimeA count since midnight with no date; the date comes from the injected clock.
Which way the data actually moves
Into the canonical model
- CAT034 data blockService messages from one radar.
- Sensor Entity and EventOne pair per record, with the integrity basis recorded on every object.
Out of the canonical model
- Sensor EntityOnly objects that came from this category.
- CAT034 data blockByte exact re-emission.
Where this data is used
Sensor health on the picture
Operating mode changes and status reports become Events against the station, so the ISR Fusion Agent can qualify coverage rather than treating absence of detection as absence of activity.
Coverage assessment
Sector crossings and north markers describe the rhythm of the sensor. A stalled or irregular pattern is visible as data rather than as an operator's impression.
Evidence for review
Because the record carries the integrity basis that passed, an auditor can see which structural checks were satisfied at ingest.
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_cat034.
Source and fixtures
- Adapter sourcepackages/cdm/synapse_cdm/adapters/asterix_cat034.py
Ingest, byte exact egress and the refusal rules, each documented at its site.
- Codecpackages/cdm/synapse_cdm/adapters/cat034_codec.py
Item level decode and encode, separated from the canonical translation.
- Fixturespackages/cdm/synapse_cdm/fixtures/cat034/
Raw blocks, parsed twins and golden canonical output, including a midnight rollover case.
Test evidence
- Harness testtests/test_cdm_asterix_cat034_adapter.py
Replayed by the validation harness shipped in the same package, which runs six checks per fixture including a never-drop lossless check.
- Coverage document testtests/test_cdm_format_coverage.py
Asserts the written row set and the models agree in both directions.
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_cat034Maturity 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.
What is claimed, and what is not
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
- Egress refuses anything that did not originate in Category 034. There is no synthesis of a service message from unrelated canonical objects.
- The station position is never used to interpret another category's payload. The corresponding Category 048 geodesy gap stays open by design.
- No polar window geometry is derived, for the reason the specification itself supplies.
- One pinned edition. Differences in other editions are recorded rather than assumed.
Security boundary
- Sensor positions that appear in a customer payload stay in that customer's environment. Nothing in the published layer transmits, stores or forwards operational data.
- The repository contains no site configuration, no station registry and no deployment topology.
Public sources
Statements about what SynapseCommand® implements are drawn from the published repository rather than from these external sources.
Frequently asked
- Why does a decision support platform read radar service messages?
- Because sensor state changes the meaning of sensor data. A thinning picture caused by a radar entering a test mode is a different situation from a thinning picture caused by target behaviour, and a decision record that cannot tell them apart is incomplete.
- Is the egress byte exact?
- For Entities that came from Category 034, yes. Objects from any other source are refused rather than approximated, and the refusal names what is missing.
- Does the station position from Category 034 improve Category 048 positioning?
- No, and that is deliberate. Using a value from one payload to interpret another is cross-payload state, which belongs in an audited fusion layer rather than in a translator. The Category 048 site position is supplied by configuration instead.
Where to go next
Related standards
Related use cases
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.