Communication Protocols for Defense and Automotive Embedded Systems

Determinism and bandwidth are always in tension. Every protocol is a different answer to that tradeoff — and the domain you're building for determines which answer is right.

In defense and automotive embedded systems, protocol selection isn't a low-level implementation detail. It's a platform architecture decision that determines your certification path, your failure mode design, your integration complexity, and your upgrade ceiling — often for the next two or three decades.

The protocols covered here operate at the network level: how subsystems, LRUs, ECUs, and compute nodes communicate across a platform. That's where the consequential decisions live.

CAN FD: The Automotive Backbone and Its Ceiling

Bosch designed CAN for automotive reliability in 1983. Its architecture — message-priority arbitration, built-in error detection and confinement, multi-master operation — remains the right answer for most vehicle network topologies today. These aren't conveniences. In a safety-critical multi-ECU network, they're load-bearing properties.

Classic CAN tops out at 1 Mbps with 8-byte payloads. CAN FD raises the data phase to 8 Mbps and extends the payload to 64 bytes. For the majority of automotive ECU networks — powertrain, chassis, body control — CAN FD provides enough headroom to stay on a familiar, well-certified architecture.

‍

Where CAN FD Runs Out

A single high-resolution radar node can saturate a CAN FD bus on its own. Platforms with radar, camera, and LiDAR fusion don't have a CAN FD answer — they have an Ethernet migration problem. If that's where your platform is headed, the time to design the transition is during concept, not integration.

For ISO 26262-compliant development, CAN also has a significant certification advantage: decades of established practice, tooling, and safety analysis precedent. Switching to Ethernet-based architectures mid-program introduces qualification work that teams consistently underestimate.

ARINC 429 and ARINC 664: Two Generations of Avionics

In aerospace you don't choose between these based on preference. You choose based on what generation of platform you're building and what legacy systems you're integrating with. The architectural difference between them is fundamental.

ARINC 429 is unidirectional and point-to-point. One transmitter, up to 20 receivers, fixed 12.5 kbps or 100 kbps. Its determinism is inherent — there's no shared medium, no arbitration, no contention. That simplicity is also why it's still flying on aircraft designed in the 1970s. Fault isolation is a natural property of the architecture: a failed transmitter affects only its bus.

ARINC 664 — also known as AFDX (Avionics Full-Duplex Switched Ethernet) — replaces that simplicity with a switched Ethernet fabric operating at 10 or 100 Mbps per link. The bandwidth gain is substantial. But Ethernet is not inherently deterministic, and avionics certification demands determinism. The standard's answer to this is Virtual Links: logical connections with bounded bandwidth allocation and maximum latency guarantees, enforced by the network switches.

ARINC Comparison

• Architecture
  • ARINC 429: Unidirectional, point-to-point
  • ARINC 664: Switched Ethernet fabric
• Data Rate
  • ARINC 429: 12.5 kbps / 100 kbps
  • ARINC 664: 10/100 Mbps per link
• Determinism
  • ARINC 429: Inherent
  • ARINC 664: Virtual Links
• Fault Isolation
  • ARINC 429: Natural
  • ARINC 664: Requires redundancy design
• Wiring
  • ARINC 429: High
  • ARINC 664: Lower

New platform: design to ARINC 664 from day one. Integrating with legacy LRUs: plan for 429 gateway nodes — you'll almost certainly need them.

MIL-STD-1553: Still Earning Its Place

1553B is a command/response, half-duplex bus. A single Bus Controller owns every transaction — no Remote Terminal transmits without being asked. Every word is 20 bits with Manchester II encoding, which gives inherent noise immunity.

The Bus Controller is the most important thing to understand about 1553 architecture. It is a single point of control — and potentially failure.

Where 1553 Belongs
Stores management, weapons interfaces, and legacy airframes — anywhere determinism and fault tolerance matter more than bandwidth.

Ethernet and DDS: The Distributed Compute Layer

Autonomous platforms, sensor fusion engines, high-bandwidth defense systems — this is where CAN and 1553 run out of road.

Ethernet gives you 100 Mbps to 10 Gbps, IP-based routing, and a modern tooling ecosystem.

For distributed compute systems, DDS (Data Distribution Service) provides:

• publish/subscribe architecture
• QoS control (latency, reliability, durability)
• scalability across compute nodes

Before You Commit: Six Questions

1. What is the required bandwidth — now and future?
2. Is hard real-time required?
3. What happens if the bus fails?
4. What does the system already mandate?
5. What is the certification burden?
6. Will this protocol scale long-term?

Quick Architecture Guide

• Automotive safety-critical → CAN FD
• Avionics backbone → ARINC 664
• Military integration → 1553
• High-bandwidth compute → Ethernet + DDS

The interface decision you make in the concept phase will still be present — in harness weight, integration risk, and gateway complexity — at the end of the program.

These aren't wires and packets. They're the nervous system of the platform.

Written for embedded systems architects working in defense, avionics, and automotive

‍