Skip to main content

​
Overview

System Elements represent the decomposition of your system into manageable architectural components. The custom fields control how these elements organize into hierarchies, link to functions and characteristics, and participate in FMEA and control planning workflows. Understanding these fields is essential for establishing a correct system architecture that supports ISO 26262 functional safety decomposition.

​
Core Custom Fields

NameTypeDefaultDescription
elementTypeEnum (systemElementType)nullClassifies the architectural level of this system element in the hierarchy. Values: SYSTEM (top-level product), SUBSYSTEM (mid-level grouping), COMPONENT (leaf-level physical part). Determines hierarchical relationships, RTM expansion patterns, and which FMEA documents apply. Required for PowerSheet hierarchical views and system structure navigation.

​
Field Details and Usage Patterns

​
elementType Field

Purpose: Establish architectural hierarchy and decomposition level The elementType field is the key architectural classifier for system elements. It controls:
  1. Hierarchical Organization — determines parent-child relationships in the system structure
    • SYSTEM elements are top-level and have no parents
    • SUBSYSTEM elements are children of SYSTEM or other SUBSYSTEM elements
    • COMPONENT elements are leaf nodes that represent physical/logical parts
  2. FMEA Mapping — determines which FMEA documents apply
    • System-level elements trigger System FMEA (SFMEA) documents
    • Subsystem elements are analyzed in Subsystem SFMEA documents
    • Component elements are analyzed in Design FMEA (DFMEA) documents
  3. PowerSheet Hierarchical Views — controls how elements display in:
    • System Structure Navigator (all 3 levels visible)
    • Characteristics sheets (grouped by element hierarchy)
    • Verification sheets (organized by system decomposition)
  4. RTM Expansion Patterns — determines traceability query scopes
    • System elements roll up coverage metrics from children
    • Component elements show direct traceability to design requirements and characteristics
Valid Values: 
SYSTEM      — Top-level product system (e.g., "AEB System")
SUBSYSTEM   — Mid-level logical/functional grouping (e.g., "Sensor Housing Subsystem")
COMPONENT   — Leaf-level physical component (e.g., "Camera Module")
Example Usage: 
<!-- System-level element -->
<customField name="elementType" value="SYSTEM"/>
<!-- ID: AEB-SYS-001, Title: AEB System -->

<!-- Subsystem element -->
<customField name="elementType" value="SUBSYSTEM"/>
<!-- ID: AEB-SUB-001, Title: ECU Processing Subsystem -->

<!-- Component element -->
<customField name="elementType" value="COMPONENT"/>
<!-- ID: AEB-CMP-003, Title: Camera Module -->

​
System Element Hierarchy Model

The following diagram illustrates the expected elementType hierarchy and how it maps to FMEA documents and PowerSheet views: diagram

​
Integration with RTM and PowerSheet

​
System Structure Navigator

When viewing the System Structure Navigator report, the elementType field controls the hierarchical display:
  • SYSTEM elements appear at indentation level 0 (leftmost)
  • SUBSYSTEM elements appear at indentation level 1 (indented)
  • COMPONENT elements appear at indentation level 2 (further indented)
The navigator uses the nxFmeaElementBlock and nxFindChildElements Velocity macros to traverse this hierarchy and display associated FMEA documents and failure mode statistics per element.

​
Characteristics PowerSheet

System Element hierarchy drives the grouping in Characteristics sheets:
  • System Element
    • Subsystem Element
      • Component Element
        • Characteristic 1 (classification: Special Characteristic)
        • Characteristic 2 (classification: Design Parameter)
        • Characteristic 3 (classification: Process Parameter)
The elementType field must be populated for PowerSheet queries to correctly organize and expand characteristics by component.

​
Verification PowerSheet

Similar hierarchical organization applies to verification sheets:
  • System-level verification groups all subsystem and component verification tests
  • Subsystem-level verification groups component tests for that subsystem
  • Component-level verification shows tests specific to that component

​
Standards Compliance Notes

​
ISO 26262 Functional Safety Decomposition

The elementType field supports ISO 26262 Part 4 (System Design) requirements for system decomposition:
The system architecture must be decomposed into interacting items. Each item shall be categorized as either a hardware element or a software element. The elementType field documents this decomposition hierarchy (SYSTEM → SUBSYSTEM → COMPONENT pattern).
System elements at the SYSTEM level represent the “system” in ISO 26262 terminology. SUBSYSTEM and COMPONENT levels represent the “items” or architectural building blocks.

​
AIAG-VDA FMEA Hierarchy

AIAG-VDA FMEA methodology requires multi-level FMEA (System FMEA → Design FMEA) with clear traceability:
  • System FMEA analyzes SYSTEM-level elements (entire AEB product)
  • Subsystem FMEA analyzes SUBSYSTEM elements (e.g., Sensor Housing, ECU Processing)
  • Design FMEA analyzes COMPONENT elements (e.g., Camera Module, SoC)
The elementType value determines which FMEA document template applies via the nxFmeaElementBlock macro that queries riskSpecification modules.

​
IATF 16949 / APQP Control Planning

Control planning in IATF 16949 requires traceability from product characteristics back to system elements: diagram The elementType hierarchy ensures that component-level characteristics are properly traced back to their parent system elements in the control plan.

​
Field Dependencies and Interactions

Changing elementType after the element is created may break:
  • Existing parent-child relationships (Polarion validates only valid element type combinations)
  • FMEA document queries that rely on elementType filtering
  • PowerSheet hierarchical expansion
Plan element hierarchy carefully during system architecture definition. Use the System Structure Navigator to validate completeness before FMEA analysis begins.
  1. Define your top-level system → set elementType: SYSTEM
  2. Identify major subsystems or functional groupings → set elementType: SUBSYSTEM
  3. Identify leaf-level physical/logical components → set elementType: COMPONENT
  4. Validate in System Structure Navigator that hierarchy appears correct
  5. Begin FMEA analysis — FMEA templates will auto-link based on elementType

​
Decision Matrix: Choosing elementType

ScenarioDecisionelementType Value
You are defining the top-level AEB productThis is the system boundarySYSTEM
You are grouping related components (e.g., “all sensor components”)This is a logical/functional groupingSUBSYSTEM
You are defining a specific physical part (e.g., Camera Module, ECU board)This is a leaf-level componentCOMPONENT
You have 10+ distinct physical parts, multiple suppliers, separate integration phasesCreate hierarchy: SYSTEM → SUBSYSTEM (per supplier or phase) → COMPONENT (per part)See hierarchy model above
You are unsure if something is SUBSYSTEM or COMPONENTAsk: “Is this a container that holds multiple parts?” If yes → SUBSYSTEM; If no → COMPONENTApply question iteratively