Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AAVSP-04
Engineers and manufacturers designing or integrating discrete signal interfaces on NATO aircraft
AAVSP-04 sets the electrical characteristics for four types of discrete signal interface used between avionics equipment on NATO aircraft, so equipment from different designers interoperates on the same wiring.
AAVSP-04, the Allied Avionics Systems Publication on discrete signal interfaces, is NATO's electrical specification for how avionics equipment exchanges signals that carry only two states, a mode flag, a fault warning, a lamp command, a status report. It does not define what any of those signals mean, and it does not lay down a communications protocol. It defines the electrical envelope, voltage behaviour, timing and cabling, that a transmitter and a receiver have to share so equipment built by different designers, in different nations, interoperates correctly on the same aircraft wiring. Edition A, version 1, was promulgated in February 2017, and nothing in the document names an earlier edition it supersedes.
AAVSP-04 does not stand alone. It requires the aircraft's own electrical supply to already meet STANAG 3456, aircraft electrical power system characteristics, wherever an interface draws power from it, and it is explicit that it does not replace or override STANAG 3837, the separate agreement covering aircraft/store electrical interconnection: the two sit side by side rather than one requiring the other. Two UK national documents are also named, UK Def Stan 59-41 on electromagnetic compatibility and UK Def Stan 00-18 (Part 1) Section 4, a guide to the discrete signal interfaces standard, though neither is a NATO agreement.
The document groups discrete signalling into four categories, each detailed in its own annex, and every one of them repeats the same point: it specifies the electrical interface, not the protocol or the function a signal performs. Choosing which type fits a given signal is a design decision the document leaves to the engineer.
Critical timing signalling (Annex A) covers functions where timing matters and rise time is significant, the document names event signalling and audio blanking as typical uses, using a balanced two-wire transmission scheme. The annex sets the transmitter's differential and common-mode voltage behaviour and output waveform, the receiver's threshold and common-mode rejection, and the cable's construction, a twisted, screened pair. It is a dedicated point-to-point link: where a signal has to reach more than one receiver, the annex calls for separate links rather than one transmitter feeding several.
Non-critical timing signalling (Annex B) applies where a response time in the tens of milliseconds is acceptable, and the document positions it as meeting most requirements where flexibility matters more than speed, mode selection, permanent flags, fault warning flags, status reporting and limit switches are its examples. An impedance-switching transmitter, built from contacts, logic gates or transistors, drives an active receiver, and up to three receivers can share one transmitter.
Low power switching (Annex C) is used where a signal also has to carry power, driving a lamp, a relay or an electromechanical indicator. It switches current from the aircraft supply to the load, and the annex covers fault propagation suppression and protection against the transients an inductive load produces. The document is unusually candid here: it expects future issues, of this or other standards, to specify a more complete range of power switching interfaces, treating this annex as a starting point rather than the final word.
Fault detecting, non-critical timing signalling (Annex D) adds the ability to detect a fault in the interface itself, on top of the same timing tolerance as Annex B. A sensor element and a switch element work together to produce separate SIGNAL and FAULT outputs, with up to three sensor elements able to share one switch element, one acting as master and the rest as slaves. The whole implementation has to meet national electromagnetic compatibility requirements.
None of the specific voltages, thresholds or timing values that make each interface work are reproduced here. They are the substance a design engineer opens the document for, and they sit in the annexes themselves, keyed to the test circuits each annex describes.
AAVSP-04 names no certification scheme, no accredited body and no audit or inspection regime. What it provides is a set of test circuits, one for the transmitter and one for the receiver in each annex, that define how a given electrical characteristic is measured. Whether those measurements feed a design qualification, a first-article acceptance test or ongoing production testing is decided by whatever contract or programme has invoked the standard, not by the document itself.
AAVSP-04 is an engineering interface specification, and the compliance work it describes, choosing the right interface type for a signal, designing the transmitter, receiver and cable run to meet it, and running the test circuits it defines, happens in hardware design and test, not in software. What ComplyTrain does is hold the evidence trail an avionics programme needs around that work: the design decision recording which of the four interface types was used for a given signal and why, the test records generated against an annex's test circuits, the configuration history when an interface choice changes partway through a programme, and the training record showing which engineers were briefed on the standard before design started. Where a customer's quality clause calls up AAVSP-04 alongside STANAG 3456 or STANAG 3837, ComplyTrain gives a programme one place to hold that evidence instead of scattering it across engineering files.
ComplyTrain does not design, test or certify a discrete signal interface, and it makes no claim to. Which interface type, and which of AAVSP-04's companion agreements, actually apply on a given programme is set by the contract and the customer's quality clause, not by this page. The standards explorer shows what sits alongside AAVSP-04 in the wider avionics and aircraft-electrical set; talk to us about the evidence trail your programme needs to hold.
Tell us how you need to work with AAVSP-04 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
Not by itself. Like other Allied Publications, it acquires force through the agreement that covers it, carried through national ratification, and reaches a supplier because a contract, a tender or an interface control document names it. Whether it applies on a given programme is a matter for the contract and the customer's quality clause.
They cover different things and neither replaces the other. AAVSP-04 sets the electrical characteristics of discrete signal interfaces in general; STANAG 3837 covers the aircraft/store electrical interconnection system specifically. AAVSP-04's own scope clause states that it does not replace or override STANAG 3837.
No. The document names no certification, audit or inspection scheme, and no body is described as checking compliance against it. Conformance is demonstrated through the test circuits the document defines, as part of whatever qualification or acceptance process a programme runs.
AAVSP-04 does not decide that for you. It defines four electrical interface types, critical timing, non-critical timing, low power switching, and fault detecting non-critical timing, and leaves the choice of which fits a given signal function to the designer.
No. It is limited to discrete signals, ones that carry only two states over dedicated point-to-point or shared electrical connections. It does not define protocols and does not cover multiplexed digital data buses.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.