Zonal & Central Compute Safety

A zonal architecture regroups electronics by location instead of by function: zone controllers in each physical region terminate whatever sensors and actuators are nearby, and a shared high-bandwidth backbone carries traffic to one or a few central computers where the heavy software runs. The safety consequence is that functions stop mapping one-to-one onto boxes. Mixed criticality becomes the default rather than the exception, the backbone and the power distribution become shared elements of many items at once, and the failure of one physical thing can threaten several functions simultaneously.

It is a second, smaller subsystem on the same die as the high-throughput performance domain, with a degree of logical or physical separation. Depending on the device it can provide lockstep real-time cores, protected local memory, monitors, selected peripherals and a reset domain distinct from the performance domain, and it typically performs platform supervision, fault collection and configured reactions. Its actual independence and fault-response capability come from the device safety documentation and the integrated design rather than from the label, and clock, power, interconnect, package and thermal dependencies can remain.

Three things, and the guide asks for all of them at every claimed boundary. A detection mechanism that actually notices the fault side has gone wrong within a bounded time; a defined and owned reaction that transitions the system to a justified state, because detection without reaction is telemetry; and an independence argument showing the boundary mechanism is sufficiently independent for the faults it claims to stop. A memory protection unit nobody configured to fault, a monitor whose alarm goes to a log read at the next service, and a watchdog clocked from the oscillator it is meant to catch each look convincing on a block diagram and fail the stated fault hypothesis.

Because sharing is the entire point of the architecture, and every fail-operational claim rests on an independence argument. The guide sorts the sharing into six families: shared silicon and package, shared software lineage, shared network paths and configuration, shared power routing and connectors, shared physical environment, and shared lifecycle including the update campaign that can flash both channels the same night. Identical redundancy can cover some random hardware faults without addressing shared systematic ones, and diversity can reduce some common causes while introducing new interfaces and failure modes of its own.

Not by stapling. Each piece of evidence carries a scope, assumptions and an intended use, so composition needs traceable assumption matching, evidence at every interface, and system-level verification and validation on the integrated configuration. The practical management tool is a living register recording each safety-relevant assumption of use, its named consumer, its status and its fulfillment evidence, where the open list rather than the matched list is the real project status. The classic failure is not a missing document but a document nobody reconciled, where both sides can point at internally correct paperwork.

The course has 13 chapters: from ECUs to zones, the anatomy of a zonal vehicle, items and boundaries across shared elements, safety islands and mixed criticality, containment boundaries from silicon to street, zone power distribution, network and gateway failures, central versus local monitoring, reset and recovery domains, dependent failure analysis, vehicle-level degradation, evidence aggregation, and a worked example with the recurring pitfalls and a design review prompt for each chapter.