Skip to main content

​
Overview

System elements form a five-level decomposition hierarchy: diagram Each level serves a specific purpose in the safety analysis and requirements decomposition process. Functions are typically analyzed at the Subsystem level (SFMEA), while design characteristics and failure modes are analyzed at the Component level (DFMEA).

​
Element Type Enumeration

The systemElementType field defines five distinct element types in the hierarchy:
Element TypeLevelPurposeTypical Analysis
SystemLevel 1Top-level product definition (e.g., Flight Control Computer)System-level requirements, FHA, SSA
SubsystemLevel 2Major functional group (e.g., Sensor Interface Module)Subsystem requirements, SFMEA, PSSA
AssemblyLevel 3Physical grouping of components (e.g., sensor interface assembly)Component requirements allocation
SubassemblyLevel 4Intermediate assemblies for complex subsystemsComponent requirements allocation
ComponentLevel 5Lowest-level replaceable unit (e.g., Air Data Computer Interface)Design requirements, DFMEA, characteristics

​
System

The top-level system element represents the complete product or system being developed. All other elements decompose hierarchically from this root.
  • Typical example: Flight Control Computer (FCC), Engine Control Unit (ECU), Avionics System
  • Used in: System-level requirements specifications, FHA documents, system safety assessments
  • Links to: Customer requirements, system-level functions, failure conditions

​
Subsystem

Major functional or physical groupings that decompose the top-level system. Subsystems typically align with organizational responsibilities and development teams.
  • Typical example: Sensor Interface Module, Processing Core Module, Actuator Bus Interface Module
  • Used in: Subsystem requirements specifications, SFMEA analysis
  • Links to: System requirements (via refines), subsystem functions, SFMEA failure modes
  • Analysis level: SFMEA is typically performed at the subsystem level

​
Assembly

Physical groupings of components that support the subsystem structure. Assemblies help organize the bill-of-materials (BOM) and manufacturing structure.
  • Typical example: Inertial Measurement Assembly, Control Law Processor Assembly
  • Used in: Design requirements specifications, component traceability
  • Links to: Subsystem via part-of relationship, component elements

​
Subassembly

Intermediate assemblies used for complex systems with multiple levels of physical decomposition. Subassemblies provide finer-grained organization for large subsystems.
  • Typical example: Power Distribution Subassembly, Signal Conditioning Subassembly
  • Used in: Detailed design specifications, component allocation
  • Links to: Assemblies via part-of relationship, individual components

​
Component

The lowest-level replaceable unit in the hierarchy. Components represent the finest granularity of decomposition and are the target of design requirements and DFMEA analysis.
  • Typical example: Air Data Computer Interface (ADCI), Inertial Reference Unit Interface (IRU), Power Supply Unit (PSU)
  • Used in: Design requirements specifications, DFMEA analysis, design characteristics
  • Analysis level: DFMEA is typically performed at the component level
  • Links to: Design requirements, characteristics, failure modes, test cases

​
System Element Custom Fields

System elements are minimally configured with two key custom fields:
Field NameTypeDefaultDescription
elementTypeEnumeration (systemElementType)See applicationThe hierarchical level of this element: System, Subsystem, Assembly, Subassembly, or Component
dalEnumeration (dal)See applicationDesign Assurance Level assigned to this element (DAL A–E per ARP 4754A). DAL on a system element determines the required certification activities for all documents and analyses associated with that element.

​
elementType

The enumeration that specifies which level in the hierarchy this element occupies. This field is used throughout the application to:
  • Build the System Structure Navigator hierarchical tree view on dashboards
  • Constrain DFMEA document creation to the Component level
  • Constrain SFMEA document creation to the Subsystem level
  • Determine which specification documents apply (system-level specs link to System/Subsystem elements, design specs link to Component elements)

​
dal

Design Assurance Level classification flows downward from parent elements. The DAL assigned to a system element cascades to all requirements, functions, and risk analysis documents allocated to that element. DAL Levels (ARP 4754A):
DALClassificationDevelopment RigorTypical Application
ACatastrophic failure effectsMost rigorousCritical flight control, power distribution
BHazardous failure effectsHigh rigorMajor subsystems with potential severe effects
CMajor failure effectsModerate rigorSignificant functional subsystems
DMinor failure effectsBasic rigorSupport and utility subsystems
ENo safety effectMinimalNon-safety-critical functions
The specific DAL allocation rules and inheritance mechanisms depend on your project’s governance model. Consult your ARP 4754A development plan and DO-178C/DO-254 certification basis documentation for exact DAL assignment criteria per level.

​
System Element Lifecycle Status

System elements progress through a seven-state lifecycle that mirrors the standard Polarion work item workflow:
StatusColorMeaning
DraftBlue (#3366FF)Element is under development, not yet reviewed
In ProgressLight Yellow (#FFFF99)Element is actively being analyzed and documented
In ReviewLight Yellow (#FFFF99)Element documentation is under review by stakeholders
Pending ApprovalYellow (#FFFF33)Element awaiting formal approval before release
ApprovedGreen (#66FF66)Element formally approved for use in downstream analysis
RejectedRed (#FF3300)Element was rejected and must be reworked
ObsoleteGray (neutral)Element has been superseded or is no longer in use
Status colors enable rapid visual scanning of system structure across the System Structure Navigator dashboard and document views. The same lifecycle states apply to all work item types (requirements, functions, failure modes, etc.) for consistency.

​
Hierarchical Decomposition Example

Below is a typical system decomposition for a Flight Control Computer (FCC) project: diagram

​
Analysis by System Element Level

The appropriate analysis documents and activities for each hierarchy level are predefined:

​
System Level

  • Documents: System-level requirements specifications, FHA, System Safety Assessment (SSA)
  • Analysis: Functional hazard assessment, system-level failure condition identification
  • Characteristics: Typically analyzed at component level; system-level properties inherited from subsystems
  • RPN Scoring: Not applicable; failure conditions are classified by severity category instead

​
Subsystem Level

  • Documents: Subsystem requirements specifications, SFMEA, Preliminary System Safety Assessment (PSSA)
  • Analysis: System-level failure mode and effect analysis of functions
  • Functions: SFMEA typically targets subsystem functions
  • Characteristics: Component characteristics inherit from subsystem scope
  • DAL Flow: Subsystem DAL cascades to all child components

​
Component Level

  • Documents: Component design requirements specifications, DFMEA, design characteristics sheets
  • Analysis: Design failure mode and effect analysis at the lowest replaceable unit level
  • Characteristics: DFMEA failure modes assess component characteristics
  • RPN Scoring: Pre-mitigation and post-mitigation RPN calculated per failure mode
  • Design Details: Detailed specifications, part numbers, environmental classifications (DO-160G)
Ensure that SFMEA documents are created only for Subsystem-level elements and DFMEA documents only for Component-level elements. Cross-level analysis (e.g., DFMEA at subsystem level) violates ARP 4761 decomposition rules and may result in incomplete hazard coverage or duplicate analysis.

​
System Element in Risksheet and PowerSheet

​
Risksheet

The system element hierarchy is navigable through the System Structure Navigator dashboard, which displays an interactive tree of all elements with their associated documents:
  • FHA Risksheet: Allocated to System or Subsystem; failure conditions link to functions and system elements
  • SFMEA Risksheet: Documents allocated to Subsystem elements; failure modes link to subsystem functions
  • DFMEA Risksheet: Documents allocated to Component elements; failure modes assess component characteristics

​
PowerSheet

The Component RTM PowerSheet uses applyCurrentDocumentTo filtering to scope the traceability matrix to the current component’s design requirements: 
sources:
  - model: rtm
    from: SubsystemRequirement
    links:
      - refines: SystemRequirement  # back-link
      - decomposesTo: DesignRequirement  # forward expand
constraints:
  - applyCurrentDocumentTo: SubsystemRequirement
This ensures that design engineers see only the requirements and traceability relevant to their assigned component.

​
Hierarchical Constraints and Rules

The following constraints are common patterns; verify the specific implementation in your project’s configuration.
  1. Parent-Child Relationships: Each element (except System) must have exactly one parent element in the hierarchy. Parent elements typically represent organizational or physical groupings of child elements.
  2. DAL Inheritance: A child element’s DAL cannot be higher (more critical) than its parent element’s DAL. For example, a Component with DAL A must belong to a Subsystem with DAL A or higher criticality.
  3. Document Allocation: Documents are typically allocated to a single system element. FHA/SFMEA/DFMEA risksheets align to the appropriate hierarchy level (System/Subsystem/Component).
  4. Status Propagation: When a parent element transitions to Approved status, child elements’ status changes may be constrained or require workflow action.
  5. Traceability Consistency: Requirements at each level must trace to functions, characteristics, and failure modes appropriate for that level. Orphaned elements (requirements without parent or child links) are flagged in the Requirements Traceability report.

​
Sources

This page is derived from thin source coverage (code configuration only). For complete system element management guidance, consult:
  • ARP 4754A: System Development Assurance (section 4.3 — system decomposition and DAL allocation)
  • ARP 4761: Guidelines and Methods for Conducting the Safety Assessment Process (section 3.3 — functional decomposition levels)
  • Aerospace Safety Solution Configuration: .polarion/tracker/fields/systemElementType-enum.xml and .polarion/nextedy/models/rtm.yaml
Code: .polarion/tracker/fields/systemElementType-enum.xml, systemElement-status-enum.xml (0.84) · .polarion/tracker/fields/testCase-custom-fields.xml, desReq-custom-fields.xml, processStep-custom-fields.xml, characteristic-custom-fields.xml, systemElement-custom-fields.xml, commonCauseEvent-custom-fields.xml, riskControl-custom-fields.xml, task-custom-fields.xml, custom-fields.xml (0.64) · .polarion/nextedy/models/rtm.yaml (0.60) · .polarion/pages/scripts/velocity/nextedy_solutions.vm (0.53) · .polarion/pages/spaces/_default/Requirements Traceability Summary/page.xml, Verification Validation Summary/page.xml, Risk Control Effectiveness Report/page.xml, System Decomposition Report/page.xml, FMEA Coverage Report/page.xml, Classification Consistency Report/page.xml, System FMEA Report/page.xml, System Structure Navigator/page.xml (0.52) · .polarion/pages/spaces/_default/Data Model/page.xml (0.52) · .polarion/nextedy/sheet-configurations/DO-160G Environmental Qualification.yaml, Component RTM.yaml, Configuration Index.yaml, Design Verification Sheet.yaml, Interface Control Matrix.yaml, Problem Report Tracker.yaml, Process Steps.yaml, Review Action Item Tracker.yaml, SOI Stage Gate Dashboard.yaml, Use Steps Specification.yaml, User Need Validation Sheet.yaml, characteristics.yaml, component-characteristics.yaml, customer-requirements.yaml, design-requirements.yaml, subsystem-functions.yaml, subsystem-verification.yaml, system-elements.yaml, test-verification.yaml (0.51) · datasets/sol-aero-ui-walkthrough/summary.md, navigation.md, dashboards/home-dashboard.md, dashboards/role-dashboards.md, dashboards/standards-compliance.md, risksheet-views/risksheet-views.md, work-item-types/data-model.md (0.50) · .polarion/tracker/fields/designRequirement-subType-enum.xml, environmentalCategory-enum.xml, fta-gateType-enum.xml, cca-analysisType-enum.xml, controlType-enum.xml, riskControlType-enum.xml, verificationMethod-enum.xml, testLevel-enum.xml (0.50) · .polarion/tracker/workflow/systemElement-workflow.xml (0.47)