System Elements are mandatory for ISO 26262 Part 4 (System Design Level) decomposition. Each system element must be identified, characterized by its element type, and traced to safety goals and failure modes for complete functional safety analysis.
Core Properties
| Name | Type | Default | Description |
|---|
| ID | String | Auto-generated | Unique identifier for the system element (e.g., SE-001, SE-AEB-01). Used in traceability reports and risksheets. |
| Title | String | Required | Name of the system element (e.g., “AEB Sensor Unit”, “ECU Processing Subsystem”). Appears in system hierarchy diagrams and PowerSheets. |
| Description | Text (large) | Empty | Detailed description of the system element’s purpose, functionality, and scope within the system architecture. |
| Status | Enum | Draft | Workflow state: Draft, In Progress, In Review, Pending Approval, Approved, Rejected, Obsolete. Approved elements are baselined and protected from uncontrolled modification. |
| Assignee | User | Unassigned | Person responsible for system element definition and maintenance. Typically an architecture or systems engineer. |
| Created | Timestamp | Auto | Creation date and time. |
| Modified | Timestamp | Auto | Last modification date and time. |
| Priority | Enum | Normal | Work priority: Low, Normal, High, Critical. Used for scheduling and resource allocation in system engineering. |
Custom Fields
| Name | Type | Default | Description |
|---|
| elementType | Enum | System | Classifies the system element in the architectural hierarchy. Values: System, Subsystem, Component, HardwareComponent, SoftwareComponent, Sensor, Actuator, ECU, ComputationalModule, Interface. Constrains valid parent-child relationships and affects FMEA analysis scope. |
| parentElement | ItemLink | None | Link to the parent system element in the hierarchy (e.g., Component links to Subsystem; Subsystem links to System). Enforces valid system decomposition and enables hierarchical PowerSheet views. |
| childElements | ItemLink (multi) | None | Links to child system elements (inverse of parentElement). Populated automatically when child items link to this element as parent. Enables tree navigation and hierarchical DFMEA risksheets. |
| functions | ItemLink (multi) | None | Links to Function work items allocated to this system element. Each function describes an operational capability or behavior. Used in FMEA to identify failure modes and in system verification to trace behavior requirements. |
| failureModes | ItemLink (multi) | None | Links to Failure Mode work items that assess this system element. Automatically linked during DFMEA analysis. Used for failure mode aggregation and risk control allocation. |
| characteristics | ItemLink (multi) | None | Links to Characteristic work items that define measurable properties of this system element. Examples: temperature rating, response time, power consumption. Used in design requirements and control plans. |
| safetyGoals | ItemLink (multi) | None | Links to Safety Goal work items that are allocated to this system element. Used to trace ISO 26262 safety objectives through system decomposition. |
| designRequirements | ItemLink (multi) | None | Links to Design Requirement work items that specify implementation details for this system element. Enables traceability from architecture to detailed design. |
| riskControls | ItemLink (multi) | None | Links to Risk Control work items that mitigate failure modes associated with this system element. Tracks risk reduction implementation across the architecture. |
| systemElementId | String | Empty | Optional external identifier for integration with CAD, architecture, or simulation tools. Example: “AEB-01-001” for subsystem-level identification in external systems. |
| decompositionLevel | Integer | Auto-calculated | Numeric hierarchy level: 0 = System, 1 = Subsystem, 2 = Component. Auto-calculated from parent element linkage. Used for risksheet level filtering and PowerSheet grouping. |
| elementDescription | Text (medium) | Empty | Narrative description of element scope, including interfaces with other elements, key responsibilities, and operational context. Used in system architecture documentation and design reviews. |
| implementationType | Enum | Hardware | Classification of how the element is implemented: Hardware, Software, Firmware, Hybrid, Sensor, Actuator, Interface, PowerSupply, Communication. Affects design requirement constraints and verification scope. |
| reliabilityRequirement | String | Empty | Quantified reliability target for this system element (e.g., “99.5%”, “MTTF > 100,000 hours”). Used in FMEA severity assessment and risk control effectiveness evaluation. |
| redundancyStrategy | Enum | None | Redundancy approach for risk mitigation: None, SingleChannel, DualChannel, TripleChannel, NMooN (N-out-of-N). Used in ASIL allocation and safety goal derivation. |
| asilAllocation | Enum | QM | ASIL classification of this system element: QM, A, B, C, D. Inherited from parent system element or explicitly assigned. Constrains failure mode severity assessment in DFMEA. |
| verificationMethod | Enum | Testing | Primary verification approach: Testing, Analysis, Inspection, Demonstration, Review. Used in verification test case linking and V-Model traceability. |
| traceabilityStatus | Enum | Unreviewed | Status of traceability completeness: Unreviewed, Complete, Gaps Identified, In Review, Approved. Used in Safety Readiness Scorecard and dashboard KPIs. |
| lastReviewDate | Date | Empty | Date of most recent formal design review. Used for compliance tracking and process governance. |
Relationships
Outgoing Links
| Link Role | Target Type | Cardinality | Description |
|---|
| parentElement | systemElement | 1 | Points to parent in hierarchy (Subsystem → System, Component → Subsystem). Enforces tree structure. |
| allocatedTo | function | M:M | Allocates functions to this system element. Each function describes one capability or behavior the element realizes. Used to construct functional hierarchy and FMEA analysis scope. |
| assesses | failureMode | 1:M | System element is assessed by failure modes in DFMEA analysis. Failure modes describe how this element can fail. Automatically linked during DFMEA work item creation. |
| satisfies | safetyGoal | 1:M | System element contributes to satisfaction of one or more safety goals. Used to trace ISO 26262 safety architecture through system decomposition. |
| refines | designRequirement | 1:M | System element is detailed by design requirements that specify implementation constraints. Enables traceability from architecture to design specification. |
Incoming Links
| Link Role | Source Type | Cardinality | Description |
|---|
| childElements | systemElement | M:1 | Children of this system element (inverse of parentElement). Automatically maintained. Enables hierarchical queries in DFMEA risksheets. |
| allocatedFrom | function | M:M | Functions allocated to this element (inverse of allocatedTo). Read-only computed relationship. |
System Element Hierarchy Structure
System Elements must follow a hierarchical decomposition pattern aligned with ISO 26262 architectural analysis requirements:
- System elements cannot have a parent element (decompositionLevel = 0)
- Subsystem elements must have a System as parent (decompositionLevel = 1)
- Component elements must have a Subsystem as parent (decompositionLevel = 2)
- Cross-level linking (e.g., Subsystem → Subsystem) is not permitted
Element Type Taxonomy
The elementType custom field constrains how system elements can be organized:
| Element Type | Description | Typical Parent | Typical Children | DFMEA Usage |
|---|
| System | Top-level system being analyzed for functional safety | None | Subsystem | System FMEA root item; grouping for HAZID |
| Subsystem | Major functional or physical subsystem | System | Component | Subsystem FMEA parent; grouping for system-level decomposition |
| Component | Discrete component or module | Subsystem | None | Component DFMEA analysis; leaf node for failure analysis |
| HardwareComponent | Physical electronic or mechanical component | Subsystem | None | Analyzed in hardware DFMEA (Part 5 compliance); includes ICs, sensors, actuators |
| SoftwareComponent | Logical software module or function | Subsystem | None | Analyzed in software design DFMEA; constraint analysis for Part 6 compliance |
| Sensor | Data input device (camera, radar, lidar) | Subsystem | None | Sensor fusion failure modes; input reliability assessment |
| Actuator | Control output device (motor, solenoid, valve) | Subsystem | None | Actuation reliability; control system effectiveness |
| ECU | Electronic Control Unit | Subsystem | Component, SoftwareComponent | Computational failure modes; main processor or co-processor |
| ComputationalModule | Software algorithm or firmware block | SoftwareComponent | None | Algorithm correctness and robustness failures |
| Interface | Communication or connection boundary | Subsystem | None | Interface protocol and signal integrity failures |
Allocation to Functions
System Elements allocate Functions to define the functional decomposition of the system:
-
System Element: Camera Module
- Allocated Function: Object Detection
- Allocated Function: Image Processing
- Allocated Function: Scene Analysis
-
Each function analyzed for failure modes:
- Object Detection
- FM: Delayed detection (5s latency)
- FM: Intermittent loss of detection
- FM: False positive detection
Functions linked via the allocatedTo relationship enable:
- DFMEA Analysis: Failure Mode work items assess allocated functions and the system element that realizes them
- Functional Traceability: Link from Customer Requirements → Use Steps → Functions → System Elements → Design Requirements
- Verification Scope: Test cases verify functions allocated to system elements at appropriate V-Model levels
Usage in DFMEA Risksheets
System Element is the Level 1 grouping in component-level DFMEA risksheets. Each DFMEA document focuses on one or more system elements:
| DFMEA Document | System Element | Component | Failure Modes |
|---|
| Camera Module DFMEA | Camera Module | Image Processor IC, Lens Assembly, Power Supply | 24 failure modes |
| Radar Module DFMEA | Radar Module | RF Transceiver IC, Antenna, Power Supply | 18 failure modes |
| ECU Processing DFMEA | Safety Co-Processor | CPU, RAM, ROM, Power Management | 7 failure modes |
levels:
- level: 1
name: System Element
fieldType: itemLink
linkTypes: [systemElement]
linkRole: assesses
collapseTo: title
Safety Goal Allocation
System Elements can be allocated one or more Safety Goals that must be satisfied through the element’s design and implementation:
-
System Element: Sensor Fusion ECU
- Safety Goal: SG-02 — Ensure obstacle detection reliability (ASIL B)
- Safety Goal: SG-03 — Maintain timely braking response (ASIL B)
- Safety Goal: SG-04 — Ensure sensor fusion availability (ASIL A)
-
Design Requirements for Sensor Fusion ECU:
- Diagnostic coverage >= 90% for ECU computational failures
- Response time <= 50 ms for sensor input processing
- Fault tolerance: Single-point failure tolerance >= 98.5% (ASIL B)
The satisfies link role establishes traceability from system architecture to ISO 26262 safety objectives, enabling:
- ASIL Inheritance: Component ASIL is constrained by allocated Safety Goal ASIL
- Design Requirement Scoping: Design requirements must address all allocated safety goals
- Verification Planning: Test cases must verify safety goal satisfaction at system element level
Characteristics and Measurable Properties
System Elements are characterized by Characteristic work items that define measurable quality attributes:
-
System Element: Power Management IC
- Characteristic: Operating Temperature Range (-40 C to +105 C)
- Characteristic: Supply Current Draw (<= 2.5A @ 12V)
- Characteristic: Quiescent Current (<= 100uA in standby)
- Characteristic: Efficiency (>= 95% at nominal load)
-
Each Characteristic is:
- Refined by Design Requirements (implementation specs)
- Assessed by Failure Modes (e.g., thermal runaway, brownout)
- Monitored by Control Plan Items (manufacturing)
Characteristics enable:
- Design Specification: Quantified targets and tolerances for procurement and design
- FMEA Analysis: Failure modes assess how characteristics can degrade
- Control Planning: Control methods verify characteristic conformance in manufacturing (SC/CC classification)
- Verification Test Cases: Tests verify characteristic achievement at subsystem and system levels
Status Lifecycle and Review Workflow
System Element status progresses through the system engineering review process:
| Status | Description | Transition Trigger | Can Be Modified |
|---|
| Draft | Initial creation; under development | Save as new work item | Yes |
| In Progress | Active work on definition/specifications | Assign to engineer | Yes |
| In Review | Undergoing peer or technical review | Submit for review | Controlled |
| Pending Approval | Passed review; awaiting formal sign-off | Review completion | Controlled |
| Approved | Formally approved and baselined | Approval authority signature | No (change control) |
| Rejected | Failed review; requires rework | Review rejection | Yes |
| Obsolete | No longer valid due to redesign/scope change | Manual deprecation | No |
Once a System Element reaches Approved status, it becomes part of the functional safety baseline. Subsequent modifications require formal change control and traceability to change request work items. This enforces ISO 26262 Part 8 Clause 11 (Change Management) requirements.
Decomposition Level Calculation
The decompositionLevel custom field is automatically calculated from the parent element hierarchy:
// Formula: count parent element links
if (parentElement == null) {
return 0; // System level
} else if (parentElement.decompositionLevel == 0) {
return 1; // Subsystem level (parent is System)
} else {
return 2; // Component level (parent is Subsystem)
}
- Level-based Filtering: PowerSheets filter to specific decomposition levels (e.g., show all Components under selected Subsystem)
- DFMEA Scoping: Risksheets filter rows by decompositionLevel
- Dashboard KPIs: System Readiness Scorecard reports statistics by level (System-level SFMEA vs. Component-level DFMEA)
Integration with PowerSheet Views
System Element appears in multiple PowerSheet configurations:
System Structure Navigator
- section: System Elements
fieldType: itemLink
linkTypes: [systemElement]
displayColumns:
- name
- elementType
- status
- assignee
- decompositionLevel
Component RTM PowerSheet
System Elements form the left section grouping for RTM (Requirements Traceability Matrix) views at component level:
- section: System Elements
fieldType: itemLink
linkTypes: [systemElement]
collapseTo: title
color: darkblue
Characteristics PowerSheet
System Elements organize characteristics by component:
- section: System Element
fieldType: itemLink
linkTypes: [systemElement]
multiItem: true
- section: Characteristics
fieldType: itemLink
linkTypes: [characteristic]
scope: systemElement
Cross-Product References
For related PowerSheet and RTM configuration details:
Example: Creating a System Element
A typical system element creation workflow:
- Create new System Element work item: “Camera Module” with elementType = HardwareComponent
- Link Parent: parentElement → “Sensor Housing Subsystem”
- Allocate Functions: allocatedTo → { “Object Detection”, “Scene Analysis” }
- Define Characteristics: Create or link Characteristic work items for temperature, power, response time
- Create DFMEA: New DFMEA document with this system element as Level 1 grouping
- Define Design Reqs: Create Design Requirement work items that refine this element
- Submit for Review: Change status to In Review → Pending Approval → Approved
| Property | Value |
|---|
| Work Item Type | systemElement |
| Module Folder | Design |
| First Available | TestAuto2 v1.0 |
| Last Modified | v2.1 |
| Polarion Compatibility | 2022.2+ |
