ARINC 825-4 in Plain Terms

Why Aviation Runs a Bus Built for Cars

CAN started in automotive control and industrial systems in the 1980s. Aircraft borrowed it for the reason carmakers did. One shared twisted pair links many sensors and actuators, which cuts wiring weight and count. On an aircraft, CAN usually carries lower and medium bandwidth traffic and sits beneath faster networks rather than replacing them.

What ARINC 825 Adds on Top of CAN

Classic CAN, defined in ISO 11898, covers only the lower layers. It sets how bits move on the wire and how frames form, then stops. It says nothing about how an aircraft should organize messages, addresses, or priorities. The AEEC published ARINC 825 in 2007 to close that gap, building it on CAN 2.0B. The standard fixes the conventions that used to vary from program to program: 11-bit and 29-bit identifiers, logical communication channels, and modes like one-to-many and peer-to-peer. Equipment from different suppliers can then share one bus without each vendor writing its own scheme. Engineers comparing airborne buses often read it next to a more traditional standard, and this MIL-STD-1553B IP core selection checklist gives that contrast.

What Changed in Supplement 4

The big addition in ARINC 825-4 is CAN FD, short for Flexible Data-rate. A CAN FD node switches to a faster bit rate during the data part of a frame and carries a larger payload than classic CAN allows. In the ARINC 825-4 context, that data phase runs up to 4 Mb/s, four times the 1 Mb/s ceiling of classic CAN. Supplement 4 also added guidance the earlier versions skipped: manufacturer compliance, bit-timing configuration, monitoring counters, and security considerations for the bus.

The Core Ideas a Beginner Needs

Two ideas carry most of the weight. CAN is multi-master and message-oriented, so any node can talk when the bus is quiet, and each message’s identifier sets its priority. The most important traffic wins arbitration. CAN also confines faults, which means a node that misbehaves backs itself off the bus instead of dragging the network down. That fault behavior is a big part of why safety-relevant systems trust it, especially for B2B companies that depend on uptime, reliability, and predictable communication. One more habit separates the engineers who ship clean CAN designs from the ones who fight them. You design the message set, not the wiring, and agreeing identifiers, rates, and timing up front is the demanding, valuable work. 

Security Is Now Part of the Job

Classic CAN has no built-in authentication, so any node on the bus can send a frame that looks legitimate. On an aircraft, that gap matters. The ARINC 825-4 security appendix reflects the shift, and it’s the part of CAN Bus (CAN FD) solutions we’ve put the most work into. A standard CAN controller moves data. Our secure cores also watch the bus they sit on, authenticating every node, white-listing message IDs, and flagging spoofing and denial-of-service attempts as they happen. The patented “SnS” (Safe and Secure) option runs that check at the physical layer, and the same sensor locates wire faults by passive TDR, reporting distance-to-fault across cable, stubs, connectors, LRUs, and termination.

“We’ve spent more than two decades fielding databus links in places that punish mistakes, from orbit to active theaters. The lesson that stuck is simple. The fault that grounds a platform is almost never the obvious one. It’s the spoofed frame a controller waved through, or the intermittent short that hid from every tester on the bench. That’s why our CAN cores authenticate each node and locate wire faults at the physical layer, so the bus flags the problem instead of a technician hunting it for days.”

Essential Resources

Specifying a CAN, CAN FD, or ARINC 825-4 design means weighing protocol fundamentals, certification, and real cyber risk. These seven sources are the ones we point engineers and program leads to, and every link here was checked.

1. ARINC 825 standard overview: the standard’s own primer on scope, history, and how CAN is positioned for the aircraft.

2. ARINC IA official ARINC 825-4 listing: the publisher’s page for Supplement 4, the place to confirm scope and revision status.

3. Accuris standards store: where to obtain the full ARINC 825-4 document when you need the authoritative text.

4. Kvaser ARINC reference: a vendor explainer covering ARINC 825 and how CAN FD reached the standard.

5. CSS Electronics CAN FD guide: a clear walk through CAN FD framing, bit rates, and efficiency for anyone new to it.

6. Bosch Semiconductors CAN protocols: straight from CAN’s originator, covering CAN FD and the licensing that governs it.

7. ISO 11898-1 catalogue page: the international standard that defines both classic CAN and CAN FD frame formats.

Supporting Statistics

Three numbers explain why Supplement 4 earned its place. Each links to its source.

Eight times the payload. CAN FD carries up to 64 bytes per frame, eight times the 8-byte limit of classic CAN, per CAN in Automation.

A three to eight times bandwidth gain. In real networks, CAN FD moves three to eight times the data of classic CAN, according to Kvaser.

Past the 1 Mb/s wall. Classic CAN caps at 1 Mb/s, while CAN FD’s data phase runs well beyond it, up to 8 Mb/s in general implementations, as Softing notes.

These statistics show why Supplement 4 matters: CAN FD gives ARINC 825-4 networks eight times the payload, three to eight times more real-world bandwidth, and a data phase beyond the classic 1 Mb/s limit, while a data bus fault isolation tester helps teams validate and troubleshoot that higher-capacity bus before integration issues reach the aircraft. 

Final Thoughts and Opinion

ARINC 825-4 asks a CAN design to do a few things at once: move data reliably, prove it can be certified, and defend the platform it rides on. After 25-plus years of fielding databus products, here’s where we land.

• Speed is the easy part. Reaching 4 Mb/s on CAN FD is table stakes. The harder, more valuable work is authenticating every node and finding a wire fault before it strands an aircraft.

• Certifiability belongs on the buying checklist. A core that’s DO-254 certifiable up to DAL A saves a program the months of rework a faster-but-uncertifiable part would cost.

• Physical-layer security holds up. Perimeter defenses get bypassed. A bus that authenticates its own traffic and reports its own electrical health is far harder to fool.

If your roadmap touches avionics, defense ground vehicles, or automotive control, the question isn’t whether to secure the CAN bus, but how early you build that security in.