STANAG 4586: telemetry ingest, and never vehicle control
STANAG 4586 defines the interfaces for interoperable control of uncrewed aircraft. The open integration layer implements one narrow part of it: reading air vehicle telemetry off the Data Link Interface. Nothing in the published layer emits a Data Link Interface message, so nothing in it can task, steer or command an air vehicle.
What STANAG 4586 is
The standard describes a control system architecture in which a control station and a vehicle specific module exchange numbered messages over the Data Link Interface. Some of those messages report vehicle state; others command it.
Each message is carried in a wrapper that names the message type, the source and destination identifiers, a sequence number, the interface document version and a checksum.
The source identifier is defined to identify any element in an arbitrarily composed system of control stations, air vehicles and data links, which makes it a usable basis for stable identity.
Why this matters to a commander
Uncrewed aircraft telemetry belongs in the same picture as everything else. A commander reasoning about airspace needs the friendly uncrewed platform in view alongside cooperative and non-cooperative traffic.
Because the position in the implemented message is inertially derived rather than satellite derived, it retains value in exactly the conditions where satellite navigation is being denied, which is the case the platform's positioning and navigation warning inputs are designed for.
Reading telemetry without emitting commands keeps the integration inside the platform's advisory boundary: the system can see an air vehicle without being able to act on it.
The exact behaviour, not a capability claim
Ingest takes one Data Link Interface datagram, which may wrap several messages, and produces one Entity per air vehicle named in it, plus a Track whose samples are that datagram's positioned observations in wire order.
Four messages are decoded: Inertial States, Vehicle Operating States, Air and Ground Relative States, and Body-Relative Sensed States.
Decoded fields are filed under their own message number rather than merged into one namespace, because two of these messages carry a similarly named rate quantity at scales that differ by a factor of fifty, and a flat namespace would let one silently overwrite the other.
Identity derives from the wrapper source identifier, so the same vehicle produces the same identifier across datagrams without the adapter remembering anything between them.
Position source is recorded as inertial, read off the name of the message that carries the position, because the format states no navigation source. The reasoning is written onto every object.
Affiliation is unknown. A control link usually runs to a friendly vehicle, but that inference comes from deployment context rather than from anything on the wire, and a relayed or recorded feed breaks it.
The implementation is written against Edition 3, which is pinned. Edition 4 could not be acquired, no sentence in the repository claims an Edition 3 decoder reads an Edition 4 feed, and a frame declaring a different interface document version decodes against Edition 3 tables with a defect recorded.
- 01Direction inOne Data Link Interface datagram to one Entity per air vehicle, plus a Track of that datagram's positioned observations.
- 02Direction outNone. The adapter has no egress path and no Data Link Interface message is ever produced.
- 03Messages implementedInertial States, Vehicle Operating States, Air and Ground Relative States, Body-Relative Sensed States.
- 04Command uplinkOut of scope by ruling. Flight mode commands, waypoint loading, payload steering and link management are not implemented and are enumerated as excluded.
- 05EditionEdition 3, pinned. Edition 4 compatibility is an open question and is stated as one.
Which way the data actually moves
Into the canonical model
- DLI datagramOne or more wrapped messages from an air vehicle.
- Entity and TrackOne Entity per vehicle, samples in wire order, with the wrapper parked whole.
Out of the canonical model
Not implemented, and not claimed.
Where this data is used
Friendly uncrewed traffic in the air picture
Telemetry becomes canonical objects that sit beside cooperative and radar derived tracks, so airspace reasoning includes the platforms the force is operating itself.
Positioning integrity
Because the position source is recorded as inertial rather than satellite derived, a jamming warning over an area does not automatically discredit these fixes, and the distinction is visible on the object.
Feed diagnosis
The wrapper is parked whole, including destination identifier, interface version and checksum verdict, so an operator investigating a bad feed has what the wire actually said.
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 stanag4586.
Source and fixtures
- Adapter sourcepackages/cdm/synapse_cdm/adapters/stanag4586.py
Ingest only, with the ingest ruling, the identity basis and the position source argument stated in place.
- Wire codecpackages/cdm/synapse_cdm/adapters/stanag4586_codec.py
Wrapper framing and the four implemented message specifications with their scaling.
- Fixturespackages/cdm/synapse_cdm/fixtures/stanag4586/
Datagrams and parsed twins, including a frame declaring a non Edition 3 interface version.
- Field by field coveragepackages/cdm/synapse_cdm/FORMAT_COVERAGE.md
The STANAG 4586 row set, including the excluded command messages and the edition ruling.
Test evidence
- Harness testtests/test_cdm_stanag4586_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 checktests/test_cdm_lossless.py
Confirms the parked wrapper and per-message fields survive translation.
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.
stanag4586Maturity L3Claim 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 translates the format into the canonical data model. No egress path is implemented, and none is claimed.
Last reviewed against the published implementation on 2026-09-06.
Limitations
- Ingest only. There is no egress path, and adding one would move the repository towards being a control system component, which is a scope question this work did not answer.
- Four messages are implemented. Everything else in the interface, including the entire command uplink, is out of scope and named as such.
- Edition 3 only. No claim is made about Edition 4 feeds, whose vehicle identifier list and message set are documented to have changed.
- Altitude is carried only for the one altitude type that could be a geodetic height, and the residual ambiguity in that type is stated on the object rather than resolved.
- Affiliation is always unknown; a deployment that knows better sets it in the fusion layer where the decision is visible.
Security boundary
- The published layer cannot command anything. There is no canonical object kind for an instruction to an actuator, and human authority over anything that acts is a platform level rule rather than an adapter level choice.
- No credentials, link parameters or vehicle configuration appear in the repository.
Public sources
Statements about what SynapseCommand® implements are drawn from the published repository rather than from these external sources.
Frequently asked
- Can SynapseCommand control an uncrewed aircraft over STANAG 4586?
- No. The published adapter is ingest only and emits no Data Link Interface message of any kind. The command uplink is out of scope by an explicit ruling, and there is no canonical object that represents an instruction to an actuator.
- Which edition is implemented?
- Edition 3, which is pinned in the repository. Edition 4 could not be acquired, and no claim is made that an Edition 3 decoder reads an Edition 4 feed. A frame declaring a different interface version still decodes against Edition 3 tables, with a defect recorded.
- Why is the position marked as inertial?
- Because the message carrying it is named for inertial states and the format states no navigation source. Marking it as satellite derived would cause it to be distrusted in exactly the conditions where an inertial fix remains useful.