Skip to main content

​
Why a Hierarchy Matters

Aerospace certification standards do not treat a system as a monolithic artifact. ARP 4754A requires requirements to be decomposed level by level, with DAL allocated at each stage. ARP 4761 mandates that failure analysis proceed from the system level (FHA) down through subsystems (SFMEA) to individual components (DFMEA). DO-178C and DO-254 tie software and hardware assurance objectives to specific design elements. Without a formal hierarchy, these analyses would have no anchor. The System Element Hierarchy provides that anchor: a shared structural reference that all documents, analysis artifacts, and compliance records point back to. Think of it like the skeleton of the project. Every muscle (failure analysis), organ (requirements spec), and nerve (traceability link) attaches to a specific bone. The hierarchy is those bones.

​
The Five-Level Decomposition

The Aerospace Safety Solution defines five element types, forming a strict parent-child tree: diagram Not every project will use all five levels. The reference Flight Control Computer architecture uses three active levels — System, Subsystem, and Component — producing 12 total elements: one FCC system, three subsystems (Sensor Interface Module, Processing Core Module, Actuator Bus Interface Module), and eight components distributed across those subsystems. Assembly and Subassembly exist for programs that need to capture intermediate hardware packaging levels, such as a line-replaceable module that contains multiple components with their own DAL assignments.

​
The Two Core Fields

Each system element work item carries two fields that drive downstream behavior throughout the entire toolchain: elementType — classifies the element within the five-level hierarchy. This field controls which document types can be associated with the element and how it appears in navigation trees and dashboards. An element classified as Component will be offered DFMEA document links; one classified as System will surface FHA and System FMEA associations. dal — the Design Assurance Level assigned to this element, ranging from DAL A (most critical) to DAL E (no safety effect). DAL does not flow down automatically — it is a deliberate assignment made during safety analysis, based on the FHA failure condition severity allocated to that element. Once set, the DAL drives compliance objective scope for all DO-178C and DO-254 work associated with the element.
A common misconception is that DAL is automatically derived from the hierarchy position. It is not. DAL results from the FHA process: a failure condition at the system level is classified by severity, and the resulting DAL is then allocated to the subsystem or component responsible for preventing or detecting that failure. Setting elementType to Component does not assign a DAL — that is a separate, deliberate step.

​
Document Allocation by Level

The hierarchy determines which documents belong where. This is not merely organizational convention — it reflects the layered analysis structure mandated by ARP 4754A and ARP 4761:
Element LevelTypical Document Types
SystemSystem Requirements Specification, FHA, PSSA, SSA, System FMEA
SubsystemSubsystem Requirements Specification, Subsystem FMEA, Functions
ComponentDesign Requirements Specification, DFMEA, Characteristics, Test Specs
In the reference FCC project, this allocation produces 40 documents across 12 system elements. The Home dashboard Document Inventory Tree renders this allocation as a navigable tree, making document coverage gaps immediately visible — for instance, a component with no associated DFMEA stands out without any additional reporting.

​
Lifecycle Status

System elements move through a seven-state workflow: Draft → In Progress → In Review → Pending Approval → Approved, with Rejected and Obsolete as terminal exception states. Each state carries a distinct color code — green for Approved, red for Rejected, yellow shades for review stages — enabling rapid visual scanning across document inventory tables and dashboard views without reading individual status labels.
The system element lifecycle mirrors the standard Polarion work item workflow used across all artifact types in the project. Safety engineers, design leads, and program managers who have worked with other work item types will find the same approval mechanics apply here.

​
How It Connects to Safety Analysis

System elements are not isolated records. They are the root nodes from which safety analysis branches outward:
  • Failure Conditions (FHA/PSSA/SSA level) are associated with system-level and subsystem-level elements
  • Failure Modes (FMEA level) are associated with component-level elements, tracing upward to their parent failure conditions
  • Security Threats (DO-326A analysis) use the three-column hierarchy — System Element → Threat Category → Attack Scenario — with the element field drawn from this same registry
  • Requirements are allocated to system elements via the allocatedTo link role, making the element the bridge between functional specification and physical realization
This means that changing or restructuring the system element hierarchy is a significant operation with cascading effects across all associated documents. The hierarchy should be stabilized early in the project lifecycle, before failure analysis and requirements allocation begin in earnest.
This page is based primarily on configuration file analysis and UI walkthrough data. Exact form layouts, workflow transition rules, and system element creation screens should be verified in the live Polarion application before finalizing project setup guidance.
For practical steps on creating and configuring system elements in a new project, see the guides section when available.
Code: .polarion/tracker/fields/systemElementType-enum.xml, systemElement-status-enum.xml (0.62) · 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.62) · .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.61) · .polarion/nextedy/models/rtm.yaml (0.57) · .polarion/pages/spaces/_default/Data Model/attachments/diagram_1771111587_documents.mxg.svg, diagram_1771111587_risk.mxg.svg, diagram_1771111587_traceability.mxg.svg, modules/Requirements/SYSTEM-ELEMENTS/attachments/diagram_20260215-0024.44000.mxg.svg (0.55) · .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.51) · .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.50) · modules/RiskTemplates/DFMEATemplate/attachments/risksheetTopPanel.vm, SubSystem-FMEATemplate/attachments/risksheetTopPanel.vm, System-FMEATemplate/attachments/risksheetTopPanel.vm, PFMEATemplate/attachments/risksheetTopPanel.vm, HazardTrackingTemplate/attachments/risksheetTopPanel.vm, DFMEATemplate/attachments/risksheetPdfExport.vm, SubSystem-FMEATemplate/attachments/risksheetPdfExport.vm, System-FMEATemplate/attachments/risksheetPdfExport.vm, PFMEATemplate/attachments/risksheetPdfExport.vm (0.49) · .polarion/pages/spaces/_default/Home/page.xml (0.45) · .polarion/pages/scripts/velocity/nextedy_solutions.vm (0.42)