auto-architecture-buses-and-autosarlisted

# Automotive Software: E/E Architecture, Buses and Networking, and AUTOSAR > **Part 1 of 5** of the *Automotive Software* reference (plugin `automotive-software`), covering §0–§4. Sibling skills: `auto-real-time-safety-and-cybersecurity` (§5–§7), `auto-diagnostics-ota-and-adas` (§8–§10), `auto-process-testing-domains-and-supply-chain` (§11–§14), `auto-reference` (§15–§20). Section numbers are shared across the set; a reference written as §N → `skill` points into that sibling skill. > > **Currency:** CAN, UDS, ASIL and the V-model are stable and decades old; the regulatory layer and the shift to zonal and central compute moved materially. See §17 → `auto-reference` for both, dated. > **Scope.** Complements an embedded-IoT reference (MCUs, RTOS, buses at the generic > level), a flight-software reference (the closest sibling discipline — much of §6 → `auto-real-time-safety-and-cybersecurity`'s > reasoning is shared), and a robotics-software reference (§14 there, and the autonomy > stack). **This is the vehicle-specific layer.** > > **⚠️ GOTCHA** boxes mark what kills people, fails an audit, or bricks a fleet. > > **The three facts that make automotive software its own discipline:** > 1. **⚠️ Software can kill, and the system knows it.** Steering, braking and propulsion > are safety-critical in the formal sense — ISO 26262 assigns them an ASIL, and that > rating dictates your architecture, your process, and your evidence (§6 → `auto-real-time-safety-and-cybersecurity`). >