Zonal & Central Compute Safety
When functions stop mapping onto boxes: item boundaries, containment, monitoring and evidence for a vehicle whose safety-critical elements are shared by everything.
- Chapters
- 13
- Chapters
- Coupling families
- 6
- Coupling families
- Monitoring tiers
- 3
- Monitoring tiers
- Design review prompts
- 12
- Design review prompts
Quick answers
- What is a zonal architecture and why does it change the safety concept?
- 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.
- What is a safety island in an automotive SoC?
- 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.
Why it pays for itself
Boundaries you can defend in review
Consolidation breaks the habit of pointing at a box and calling it the item. The guide works the boundary decision in both directions, shows what each choice costs, and makes the assumptions on shared elements explicit rather than hidden.
Containment that is more than a block diagram
Every claimed boundary is put through the same test: what detects, what reacts, and why the mechanism is independent of what it contains. The fault versus error distinction keeps an argument from quietly claiming the stronger property.
Independence claims that survive the coupling walk
Six coupling families applied to real redundancy claims expose shared silicon, shared lineage, shared routing and the shared update night, so a fail-operational claim is treated on the harness drawing rather than on the schematic.
What you’ll be able to do
Draw Item Boundaries That Survive Consolidation
Define items from vehicle-level functionality, decide deliberately whether a shared platform element is inside the boundary or explicit external context, and state what the item assumes of that outside.
Place Workloads on Defensible Grounds
Use integrity needs, timing, compute appetite and independence from what a function monitors to argue why a workload runs on the island, in a protected partition, in a general-purpose partition, or out at a zone.
Build Containment Boundaries That Are Real
Apply the detection, reaction and independence test to every claimed boundary, and keep the distinction between containing a fault and containing the errors it produces.
Treat Power and Network as Safety Elements
Handle protection settings, switch configuration and traffic policing as safety-related data, and check that reconvergence and disconnection behavior fit the reaction budgets they support.
Run a Dependent Failure Analysis That Bites
Write down every independence claim, walk the six coupling families against the real harness and the real deployment, and treat each relevant coupling instead of naming diversity as a cure.
Compose Distributed Evidence Into One Case
Match exported assumptions of use to named fulfillments, keep the open list visible as the project status, and show integration and validation evidence for the configured vehicle rather than for isolated layers.
Chapter by chapter
- 01
From ECUs to Zones
Three generations of electrical and electronic architecture, the harness, software-defined vehicle and scalability drivers behind consolidation, and the three concrete shifts that consolidation forces on a safety concept.
- Distributed to domain to zonal
- Why the industry moved
- The safety turn
- 02
Anatomy of a Zonal Vehicle
The descriptive tour before any argument: what a zone controller actually contains, what sits inside a central computer, what the backbone between them looks like, and where each safety mechanism will later live.
- Zone controller blocks
- Heterogeneous central compute
- Backbone topologies
- 03
Items and Boundaries
The first genuinely conceptual chapter: why the item starts from vehicle-level functionality rather than from a box, what sharing does to an element, why reusable platforms live on assumptions of use, and how distributed development turns boundaries into agreements.
- Boundary as a design decision
- Shared-element ledger
- SEooC and assumptions
- Development interface agreements
- 04
Safety Islands and Mixed Criticality
Inside one possible central-compute design: a throughput-optimized performance domain alongside a smaller supervision-oriented domain, mixed criticality as the tenancy model, and the four questions that decide where a workload belongs.
- Two domains, one die
- Tenancy model
- Placement questions
- Residual shared causes
- 05
Containment Boundaries
The containment model the rest of the guide uses: what a containment region means here, the difference between containing faults and containing errors, the layered hierarchy from silicon to street, fault collection and reaction, and the three-part test any claimed boundary must pass.
- Fault versus error containment
- Layered hierarchy
- Fault collection pattern
- Detection, reaction, independence
- 06
Zone Power Distribution
Power distribution as a piece of safety architecture: eFuse banks and commanded load shedding, protection coordination and the current-time margin, fail-operational feeds and the isolation between them, and why trip thresholds and shed priorities are safety-related configuration data.
- From fuse box to eFuse
- Trip selectivity
- Redundant feeds and isolation
- Configuration under control
- 07
Network and Gateway Failures
The one element nearly every item shares. Failures sorted into physical, infrastructure and translation layers, the containment the switch class offers, why reconvergence time has to fit a reaction budget, and how a gateway transformation sits inside the safety path.
- Three failure layers
- Topology against partition
- Babbling-node containment
- Gateway transformation risk
- 08
Central versus Local Monitoring
Where detection and reaction should live. Reflex monitoring at the zone, platform supervision inside the central computer, vehicle health management above both, the heartbeat that cannot distinguish a dead node from a dead link, and who watches the watcher.
- Three tiers of watching
- Heartbeat ambiguity
- Protected monitoring traffic
- 09
Reset and Recovery Domains
Restart becomes an architecture question when boxes are shared. Reset scopes and their blast radii, staged escalation with bounded retries, the choreography of restarting a zone while the vehicle drives, and why a returning node must rejoin the present rather than the past.
- Scoped resets
- Restart while driving
- State declared lost, never guessed
- Confirmed authority handback
- 10
Dependent Failure Analysis
Consolidation actively works against independence, because sharing is the point of the architecture. Six coupling families, three redundancy claims examined for the dependencies that undercut them, the update pipeline as a common cause, and what the analysis owes the architecture.
- Six coupling families
- Redundancy claims under the lens
- Update as common cause
- Coupling walk per claim
- 11
Vehicle-Level Degradation
What the vehicle actually does while a piece of it is missing. The ladder as a design object rather than emergent behavior, capability contracts and the arbitration between them, the fast reaction phase against the longer degraded phase, and how continued operation is derived rather than assumed.
- Capability contracts
- Concentration risk matrix
- Two time scales
- Re-upgrade gate
- 12
Evidence Aggregation
Evidence arrives from several organizations and technical layers, and the joints between them are the argument. The evidence stack layer by layer, why certificates do not compose by stapling, the unmatched assumptions register as the real status, and building a modular case for reuse.
- Layered evidence stack
- Assumption matching
- Safety-relevant configuration data
- Modular reusable case
- 13
Worked Example and Pitfalls
One fictional function traced end to end through every mechanism the guide described, including the degraded branch after a central partition failure, then the architecture pitfalls that keep recurring and a design review prompt for each chapter.
- End-to-end walkthrough
- Degraded branch
- Recurring pitfalls
- Review prompts by chapter
Who this guide is for
- E/E architects moving a platform from domain controllers to zones and central compute
- Safety engineers writing item definitions where the platform is shared by every function
- Integrators reconciling supplier safety manuals, assumptions of use and certificate scopes
- Software and platform engineers placing mixed-criticality workloads on a heterogeneous SoC
- Anyone owning the backbone, the power net or the health manager that everything now depends on
Frequently Asked Questions
Common questions about Zonal & Central Compute Safety
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.