When building a safety-critical system—whether for an ECU in automotive, a flight controller in aerospace, or a train signaling system—one of the earliest architectural decisions can have massive downstream impact:
Is it really hard to implement Cybersecurity in automotive?
European OEMs and TIERsX are subject of compliance with the ISO21434:2021 and ISO24089:2023 (only in the case of OEMs), in particular if the target market is any of the 68 countries of the UNECE Agreement of 1958. Considering the implications of implementing the requirements of the ISO 1434, we will see that in case of mature organizations it may not be that challenging of implementation if a pragmatic approach is considered.
The Black Box Trap
It’s tempting to treat your MCU or SoC as a single component in your SYS.1/SYS.2 architecture:
It simplifies your block diagrams.
It reduces the number of interfaces to analyze.
It “contains” the complexity in one place.
But here’s the problem: when you treat a multi-core SoC as one indivisible unit, you lose visibility into the fault containment regions (FCRs), freedom from interference (FFI), and safety mechanism boundaries that ISO 26262 expects you to consider.
What’s the consequence?
ASIL propagation: You can’t argue that a QM core is independent from an ASIL D one because you haven’t modeled that separation.
Diagnostic blow-up: You have to apply high DC/PMHF coverage to everything, including blocks that don’t need it.
Decomposition blockers: You can’t show the architectural independence needed for safety goal decomposition.
The result: a higher system ASIL, conservative hardware metrics, and longer (often painful) DFA and audit discussions.
A Smarter Approach: Granular Modeling
Instead, consider breaking the MCU/SoC into internal building blocks during your safety architecture phase:
Cores: Core A (ASIL-D), Core B (QM), Safety Island
Memory areas: Flash, RAM, ROM with ECC support
Peripherals: CAN, LIN, SPI, etc.
Clock & power domains: Often separate and independently diagnosable
Safety mechanisms: WDG, LBIST, MBIST, error injectors, SMU, etc.
This level of detail allows you to:
☑ Claim freedom from interference between blocks
☑ Allocate different ASIL levels within the same chip
☑ Justify decomposition based on independence (ISO 26262-9, clause 5)
☑ Reuse vendor safety mechanisms to reduce PMHF/SPFM burden
☑ Improve safety mechanism mapping and avoid duplication
☑ Target diagnostics precisely (less testing, better performance)
Yes, this means more effort in the early SYS.1/SYS.2 stages.
But the benefits downstream—in SYS.3, HWFM/HWTF, software safety, and tool qualification—often outweigh the upfront cost.
A Real-World Example
At Kentia, we helped a client working on a domain controller for EVs. Initially, their architecture treated the SoC (a multi-core Renesas RH850 with safety island) as a single block. This led to:
ASIL D propagation to all software
PMHF > 200 FIT
Unjustified DFA assumptions
After refactoring the model to split the SoC into individual cores, memories, and safety functions, and establishing FFI via the SMU and memory protection units (MPUs), the system was able to:
Assign ASIL QM to the OTA module
Allocate partial diagnostics to vendor SMs
Reduce PMHF by 40%
Achieve successful decomposition of safety goals into parallel architectural paths
Final Thoughts
Modeling is never just about diagrams. It’s a strategy for managing risk, cost, and certification effort.
When it comes to the MCU or SoC, don’t just draw a black box and move on.
Take the time to understand and model its internal architecture—you’ll save weeks of rework, reduce your safety case complexity, and gain more flexibility in decomposition and reuse.
Because in functional safety, simplifying too early often means complicating too late.
