Skip to main content

​
Why a Unified Safety Platform?

Aerospace certification programmes suffer from a fundamental coordination problem. Safety engineers run FHAs in spreadsheets. Systems engineers manage requirements in one tool. Software teams track DAL objectives in another. Verification engineers maintain test records separately. When an auditor asks “show me the chain from customer need to verified requirement to closed failure condition”, assembling the answer takes weeks. The Aerospace Safety Solution solves this by treating every safety artifact — requirements, failure modes, failure conditions, hazards, security threats, risk controls, test cases — as first-class work items connected by typed traceability links. The audit chain is not assembled after the fact; it exists continuously as the project evolves.
The solution does not replace standards — it enforces their structure. Every work item type, link role, and classification enum maps directly to a defined concept in ARP 4761, ARP 4754A, DO-178C, or MIL-STD-882E. There is no proprietary abstraction layer between the data model and the standard.

​
The Three-Tier System Decomposition

Aerospace safety analysis always begins with system structure. The solution organises every project around a three-tier systemElement hierarchy: diagram The reference Flight Control Computer project demonstrates this with one system, three subsystems (Sensor Interface Module, Processing Core Module, Actuator and Bus Interface Module), and eight components (ADCI, IRU, PCIM, MFP, NVM, BITE Monitor, PSU, ARINC 429 / MIL-STD-1553B Bus Interface). Every risk document, requirements specification, and analysis sheet anchors to one node in this hierarchy via a systemElementId — except system-level analyses such as the FHA and Compliance Matrix, which are intentionally project-scoped.

​
The 22-Type Data Model

The solution defines twenty-two work item types organised into four discipline clusters:
ClusterTypesPurpose
RequirementscustomerRequirement, sysReq, desReqThree-tier decomposition from stakeholder need to implementation detail
ArchitecturesystemElement, function, characteristicPhysical structure, behavioural functions, and design parameters
Safety analysisfailureMode, failureCondition, hazard, securityThreat, commonCauseEventFMEA, FHA/PSSA/SSA, MIL-STD-882E, DO-326A, and CCA respectively
Verification and changetestCase, safetyRequirement, riskControl, complianceObjective, and othersClosure evidence and change tracking
failureMode and failureCondition are distinct types with distinct purposes. A failureMode belongs to FMEA analysis at component or system level and carries Severity/Occurrence/Detection scoring. A failureCondition belongs to FHA/PSSA/SSA analysis and carries a five-level ARP 4761 classification (Catastrophic, Hazardous, Major, Minor, No Safety Effect) with an automatically derived Design Assurance Level. The two are connected by a causeOf link — failure modes escalate into failure conditions through that typed relationship.
DAL classification on a failureCondition is not a field you fill in manually. When the ARP 4761 classification is set, the solution applies a fixed formula: Catastrophic → DAL A, Hazardous → DAL B, Major → DAL C, Minor → DAL D, No Safety Effect → DAL E. Overriding this computed value is intentionally prevented.

​
The Traceability Chain

Twenty link roles connect work items into a directed graph that mirrors the certification evidence chain. The most architecturally important links are:
  • assesses — connects safety analysis types (failureMode, failureCondition, securityThreat, hazard) to the function or system element being analysed. This is the entry point of all safety analysis.
  • causeOf — escalates a failureMode to a failureCondition, creating the FMEA-to-FHA cascade.
  • allocatesTo — connects failureCondition to derived safetyRequirement, and functions or failure modes to system elements.
  • refines — traces requirements downward: customer → system → design.
  • verifies — connects testCase to any requirement or risk control, providing closure evidence.
The resulting network means that a single query — “what failure conditions affect this subsystem, and which test cases close them?” — traverses only typed edges in an already-maintained graph, rather than requiring manual cross-referencing.

​
Six Analysis Document Types

The solution structures all risk analysis into six document types, each with a dedicated Risksheet template:
  1. System SFMEA / Component DFMEA — failure mode analysis using RPN scoring (Severity × Occurrence × Detection, 1–125 scale). Post-mitigation RPN thresholds: >30 High, 11–30 Medium, ≤10 Low.
  2. Functional Hazard Assessment (FHA) — ARP 4761 system-level analysis of failure conditions with classification-to-DAL mapping and derived safety requirements.
  3. PSSA / SSA — preliminary and final system safety assessments building on FHA outputs.
  4. Common Cause Analysis (CCA) — Zonal Safety Analysis, Particular Risk Analysis, and Common Mode Analysis via the commonCauseEvent type.
  5. Hazard Tracking (MIL-STD-882E) — independent hazard register with severity and status tracking.
  6. Security Threat Analysis (DO-326A) — threat assessment using the securityThreat type.
The Compliance Matrix is a seventh document type that operates differently: it tracks 48 complianceObjective items across all seven covered standards, providing a live certification readiness view rather than an analysis artefact.

​
What This Enables

For a project of the Aero1 Flight Control Computer’s scale — 260 failure modes, 18 failure conditions, 71 requirements across three levels, 33 test cases — the solution provides continuous answers to certification questions that would otherwise require assembling evidence manually:
  • Which requirements lack test coverage? (Requirements Traceability report)
  • Which failure modes have not been scored post-mitigation? (Certification Readiness Scorecard)
  • Which DO-178C software assurance objectives are open? (Compliance Matrix)
  • What is the complete cause chain from component failure mode to safety requirement? (trace via causeOf → allocatesTo)
For deeper exploration of individual analysis methods, see the concept pages on ARP 4761 Safety Assessment Coverage, ARP 4754A System Development Assurance, DAL Classification, and the V-Model Traceability Chain.
Code: modules/Risks/COMPLIANCE-001/module.xml, modules/Risks/MIL-STD-882E-HTS-001/module.xml, modules/Risks/SEC-THREAT-001/module.xml, modules/Risks/SFMEA-SUB-001/module.xml, modules/Risks/SFMEA-SUB-002/module.xml, modules/Risks/SFMEA-SUB-003/module.xml (0.64) · .polarion/tracker/fields/workitem-type-enum.xml (0.62) · .polarion/nextedy/models/rtm.yaml (0.56) · .polarion/tracker/fields/workitem-link-role-enum.xml (0.54) · 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.52) · .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.49) · modules/RiskTemplates/FHATemplate/attachments/risksheet.json (0.48) · .polarion/pages/spaces/_default/Safety Assessment Summary/page.xml, Common Cause Analysis Report/page.xml, Security Threat Assessment/page.xml, Hara Risk Matrix Report/page.xml (0.48) · modules/RiskTemplates/ComplianceTemplate/attachments/risksheet.json (0.47) · .polarion/nextedy/sheet-configurations/ARP 4761 Safety Assessment Traceability.yaml (0.47)