Why System Element Hierarchy Matters
In automotive functional safety, you can’t analyze an entire vehicle as one monolithic entity. ISO 26262 Part 3 (Concept Phase) requires hazard analysis at the system level, Part 4 (System Design) requires safety requirements allocation across subsystems, and Part 5 (Hardware Design) demands component-level failure mode analysis. The system element hierarchy provides the structural framework that connects these analysis levels.
Think of it like a company organization chart: the CEO (system) sets strategic goals, department heads (subsystems) translate them into tactical plans, and individual contributors (components) execute specific tasks. If your org chart is wrong—reporting relationships are ambiguous or responsibilities overlap—the entire organization fails. The same principle applies to safety engineering: if your system decomposition is unclear, your FMEA coverage will have gaps, traceability links will break, and ASIL inheritance will be inconsistent.
Three-Level Decomposition Model
TestAuto2 implements a strict three-level hierarchy using the systemElement work item type with an elementType classification field:
System Level
The system is the top-level item under development—in TestAuto2’s case, the Automatic Emergency Braking (AEB) System. This is the scope boundary for ISO 26262 Part 3 HARA (Hazard Analysis and Risk Assessment). Hazards identified at this level represent vehicle-level unsafe behaviors: “unintended braking,” “failure to brake when obstacle detected,” “degraded AEB performance.”
The system element inherits the highest ASIL classification from any of its derived safety goals. If one safety goal is ASIL D and another is ASIL B, the system-level ASIL is D. This drives the development rigor for all downstream subsystems and components.
Subsystem Level
Subsystems are logical or functional groupings that decompose the system into manageable analysis units. In TestAuto2, subsystems include:
- Sensor & Housing Subsystem (camera, radar, sensor housing assembly)
- ECU & Processing Subsystem (SoC, safety co-processor, memory, PMIC)
- Vehicle Interface Subsystem (CAN transceivers, communication)
Each subsystem becomes the scope for a System FMEA (SFMEA) document. Functions allocated to a subsystem (e.g., “Object Detection,” “Sensor Fusion,” “Brake Actuation Command”) are analyzed for failure modes at the subsystem SFMEA level. ASIL ratings propagate from system-level safety goals to subsystem-level functional safety requirements through the refines link role.
Subsystems should align with organizational responsibilities (different engineering teams), physical interfaces (sensor unit vs. ECU unit), or ASIL decomposition boundaries. Poor subsystem boundaries lead to overlapping FMEA coverage and ambiguous failure mode ownership.
Component Level
Components are the physical building blocks: integrated circuits (SoC, safety co-processor), sensors (camera module, radar module), assemblies (sensor housing), or passive parts (memory, power management IC). Each component is the scope for a Design FMEA (DFMEA) document.
At this level, failure modes become very specific: “PMIC output voltage drops below 4.75V,” “Camera lens condensation,” “Radar false target detection.” These component-level failure modes are linked upward to subsystem functions via the assesses link role, enabling bottom-up traceability from component failures to system-level hazards.
How Hierarchy Drives FMEA Organization
TestAuto2 creates one FMEA document per system element. This 1:1 mapping is fundamental to the architecture:
| System Element | FMEA Document Type | Work Items | ASIL Inheritance |
|---|
| AEB System (system) | System SFMEA | 36 failure modes | ASIL D (from SG-02) |
| ECU & Processing (subsystem) | Subsystem SFMEA | 42 failure modes | ASIL D (inherited) |
| Sensor & Housing (subsystem) | Subsystem SFMEA | 36 failure modes | ASIL C |
| Vehicle Interface (subsystem) | Subsystem SFMEA | 28 failure modes | ASIL B |
| Camera Module (component) | Component DFMEA | 24 failure modes | ASIL D (via SG-02 refinement) |
| Radar Module (component) | Component DFMEA | 18 failure modes | ASIL C |
| SoC (component) | Component DFMEA | 22 failure modes | ASIL D |
| Safety Co-Processor (component) | Component DFMEA | 7 failure modes | ASIL D |
ASIL Propagation Through Hierarchy
ASIL ratings don’t stay at the system level—they flow down through the hierarchy via traceability links:
Hazard (ASIL D)
↓ derives
Safety Goal SG-02 (ASIL D) "Ensure obstacle detection reliability"
↓ refines
System Requirement SR-012 (ASIL D) "Camera shall detect obstacles >50m"
↓ refines
Design Requirement DR-034 (ASIL D) "Camera module HFOV ≥ 52°"
↓ assesses
Characteristic CH-089 (ASIL D) "Horizontal FOV = 52° ±2°"
↓ assesses
Failure Mode FM-234 (ASIL D) "Reduced FOV due to lens misalignment"
↓ allocatedTo
Component: Camera Module (ASIL D)
If a component has three failure modes—one ASIL D, one ASIL B, one QM—the component’s overall ASIL is D, not the sum or average. ASIL represents the highest rigor required for any aspect of that component’s development lifecycle.
Hierarchy in RTM Domain Model
The system element hierarchy is enforced by the RTM (Requirements Traceability Matrix) domain model configuration in rtm.yaml:
- name: SystemElement
polarionType: systemElement
fields:
description: true
outlineNumber: true
relationships:
- linkRole: parent # Hierarchical structure
targetEntity: SystemElement
cardinality: n:1
required: false
- linkRole: allocatedTo # Functions → Elements
targetEntity: Function
cardinality: n:m
required: false
- linkRole: allocatedTo # Failure Modes → Elements
targetEntity: FailureMode
cardinality: n:m
required: false
parent link role (the only link role with sameType: true) creates the tree structure. The allocatedTo relationship enables many-to-many mappings: one function can be allocated to multiple system elements (shared responsibility), and one element can implement multiple functions (multifunctional components).
Practical Implications for Engineers
For Safety Engineers
When creating a new HARA document, you define hazards at the system level. The system element hierarchy determines which subsystems inherit safety goals and which components require ASIL-rated development processes. Use the System Structure Navigator report to visualize the hierarchy and validate that every safety goal has a clear allocation path to implementing components.
For Design Engineers
When working on a component DFMEA, filter the risksheet by the allocatedTo field to show only failure modes assigned to your component. The hierarchy ensures that failure modes don’t “leak” across component boundaries—if a failure mode’s root cause is in the Camera Module, it should be analyzed in the Camera Module DFMEA, not the Radar Module DFMEA.
For V&V Engineers
Test cases verify requirements at specific decomposition levels. System-level test cases validate system requirements (linked via verifies role). Component-level test cases verify design requirements and characteristics. The hierarchy tells you where to execute each test and which verification methods are appropriate (analysis, inspection, test, review).
For Configuration Managers
The hierarchy defines document scope boundaries. Each FMEA module’s moduleFolder property in the RTM model specifies which Polarion folder it belongs to (Risks/System FMEA, Risks/Component DFMEA). When creating new documents, always link them to the correct system element in the hierarchy—this populates the document inventory tree on space dashboards and enables automated coverage reports.
Common Anti-Patterns to Avoid
Flat hierarchy (no subsystems): If you jump directly from system to 30+ components, subsystem-level SFMEA becomes impossible. You’ll be forced to analyze all functions in one massive system FMEA, making it unmanageable and reducing analytical depth.
Overlapping subsystem scope: If “Sensor Subsystem” includes the camera but “Processing Subsystem” also includes camera image preprocessing, failure mode ownership becomes ambiguous. Clear boundaries are essential.
Missing elementType classification: If you create system elements without setting the elementType field, PowerSheet queries won’t work correctly. The RTM model uses elementType to filter entities for hierarchical tree views and expansion paths.
Breaking 1:1 FMEA-to-element mapping: Don’t create multiple DFMEA documents for one component, or combine multiple components into one DFMEA. The coverage tracking macros (nxFmeaElementBlock, nxFindChildElements) assume strict 1:1 correspondence between system elements and FMEA modules.
Next Steps
