Vehicle Network Architecture And Gateways
Canonical definition: Vehicle network architecture is the documented arrangement of electronic control units, physical buses, protocol domains, gateways, diagnostic interfaces, audio transports, power and wake domains, and security boundaries through which vehicle functions communicate.
The Layer Stack
| Layer | Examples | Question |
|---|---|---|
| physical medium | twisted pair, single wire, fiber, coax, automotive Ethernet | What electrical or optical interface is actually present? |
| data link / transport | CAN, CAN FD, LIN, A2B, MOST, Ethernet AVB/TSN | How are frames, streams, timing, errors, and nodes managed? |
| gateway and security | domain gateway, diagnostic gateway, authenticated interface | Which traffic may cross between domains and under what authorization? |
| application | volume buttons, chimes, amplifier control, diagnostics, audio channels | What does this exact message or stream mean in this exact vehicle? |
| power state | off, standby, accessory, run, crank, retained power, sleep, wake | When is the module powered, listening, transmitting, muted, or asleep? |
One Vehicle May Contain Several Networks
Do not describe a vehicle as having “the CAN bus.” A single vehicle may contain multiple Classical CAN or CAN FD segments, LIN subnetworks, Ethernet, proprietary infotainment links, diagnostic gateways, and dedicated audio transports. A gateway can filter, translate, authorize, delay, or block communication between them.
switches / local actuators → LIN → body controller
powertrain / chassis ECUs → CAN or CAN FD → domain gateway
head unit / amplifier / microphones → A2B, MOST, Ethernet, or analog paths
diagnostic connector or remote service → gateway → permitted modules
aftermarket interface → one documented boundary onlyChoose The Integration Boundary
- Identify the exact vehicle, trim, factory-audio option, software, and required retained functions.
- Obtain service information and the approved interface documentation.
- Map source, controls, amplifier, microphones, chimes, calls, alerts, ANC, cameras, and sleep behavior.
- Prefer a vehicle-specific interface at a documented boundary over an undocumented direct network tap.
- Begin with read-only observation or isolated bench hardware.
- Verify every normal, transition, fault, and recovery state before release.
Gateway Questions
- Which side of the gateway is the connector on?
- Does the gateway expose raw frames, diagnostic services, translated signals, or only approved functions?
- Does access require a session, authentication, vehicle state, or licensed tool?
- Can the added device keep the gateway awake?
- What happens during update, low battery, module replacement, or service-tool connection?
Do not transmit, bridge, terminate, or splice an unknown vehicle network. Keep experimental audio control away from propulsion, braking, steering, restraint, security, and driver-assistance networks. Use reversible interfaces and a known-good service path.
Required Evidence
- vehicle and option identification
- network and gateway map
- interface hardware, firmware, configuration, and permissions
- electrical loading and parked-current results
- retained-function matrix
- key-cycle, sleep, wake, disconnect, fault, bypass, and recovery results
- approved release record