Overview The data model is organized around three primary traceability chains:
Requirements Decomposition — Customer Requirement → System Requirement → Design Requirement → Test CaseSafety Analysis — Failure Mode / Failure Condition → Risk Control → VerificationSystem Architecture — System Element (hierarchical) with associated specifications, functions, and characteristics
The model supports aerospace standards including ARP 4754A (system development assurance), ARP 4761 (safety assessment), DO-178C (software), DO-254 (hardware), DO-160G (environmental), MIL-STD-882E (system safety), and DO-326A (airborne security).
Entity Types and Cardinality Requirements Entities Entity Type ID Pattern Primary Fields Cardinality Customer Requirement CUST-* title, description, classification, systemDecomposition Parent: none; Children: sysReq (1:M) System Requirement SYSREQ-* title, description, DAL, systemElement (link), characteristic Parent: customerRequirement (M:1); Children: desReq (1:M) Design Requirement DESREQ-* title, description, DAL, function (link), testCase (link) Parent: sysReq (M:1); Children: none Function FUNC-* name, description, systemElement (link) Parent: systemElement (M:1); Children: none Characteristic CHAR-* name, type (enum), value, systemElement (link), desReq (link) Parent: systemElement (M:1); Linked: desReq (M:M)
Safety Analysis Entities Entity Type ID Pattern Primary Fields Cardinality Failure Mode FM-* description, severity (1-5), occurrence (1-5), detection (1-5), RPN, systemElement (link) Parent: none; Child: failureCondition (1:M) Failure Condition FC-* description, classification (Catastrophic/Hazardous/Major/Minor/No Effect), DAL Parent: failureMode (M:1); Linked: hazard, sysReq Hazard HAZ-* description, flightPhase, effect, probability Parent: none; Linked: failureCondition, harm (1:M) Risk Control RC-* title, type (enum: Design/Procedural/Monitoring/etc.), status, verification Linked: failureMode, failureCondition (M:M) Risk Record RISK-* P1 (Probability), P2 (Probability), risk (text), benefit (text) Meta: tracks risk acceptance decisions
Verification Entities Entity Type ID Pattern Primary Fields Cardinality Test Case TEST-* title, procedure, expected_result, VAL-* or VER-* prefix Linked: desReq (M:M); Linked: sysReq (M:M) Test Specification TSPEC-* description, scope, environment, acceptance_criteria Linked: testCase (1:M)
System Architecture Entities Entity Type ID Pattern Primary Fields Cardinality System Element SE-* name, type (System/Subsystem/Component), parentSystemElement, DAL Parent: systemElement (M:1); Children: systemElement (1:M); Linked: sysReq, desReq, function, characteristic
Configuration & Compliance Entities Entity Type ID Pattern Primary Fields Cardinality Compliance Objective CO-* standard (ARP 4761/DO-178C/etc.), objective (text), status Linked: artifact (test case, design doc, etc.) Security Threat THREAT-* threatType (STRIDE category), description, SAL, mitigationControl Linked: riskControl
Document Types and Spaces Each document type is stored in a Polarion space and contains work items organized by section:
Document Type Space ID Prefix Content Tool Functional Hazard Assessment (FHA) Risks FHA Failure conditions by flight phase and effect Risksheet Preliminary System Safety Assessment (PSSA) Risks PSSA System-level failure modes and risk controls Risksheet System FMEA (SFMEA) Risks SFMEA System failure modes linked to subsystem DFMEAs Risksheet Design FMEA (DFMEA) Risks DFMEA Component failure modes, RPN, and risk controls Risksheet Fault Tree Analysis (FTA) Risks FTA Top-level hazards decomposed to root causes Risksheet Common Cause Analysis (CCA) Risks CCA Shared failure mechanisms across components Risksheet Customer Requirement Spec Requirements CUST User needs and high-level requirements Document System Requirement Spec Requirements SYSREQ System-level decomposition of customer needs Document Design Requirement Spec Design DESREQ Design-level specifications for components Document Functions Specification Design FUNC Functional decomposition of system elements PowerSheet Characteristics Specification Design CHAR Physical and performance characteristics PowerSheet Test Specification Testing TEST Test procedures and acceptance criteria Document Compliance Matrix Documentation COMP Objective-to-evidence mapping per standard Risksheet Security Threat Assessment Documentation SEC DO-326A STRIDE threats and mitigations Risksheet Hazard Tracking Documentation HAZTRACK MIL-STD-882E hazard log Risksheet
Relationships and Links The data model uses standardized link roles to express traceability:
Decomposition Links Link Role Source Target Meaning Direction decomposedBy customerRequirement sysReq Customer need refined to system requirement 1:M decomposedBy sysReq desReq System requirement refined to design requirement 1:M decomposedBy systemElement systemElement System element hierarchy (parent→child) 1:M allocatedTo sysReq / desReq systemElement Requirement assigned to system element M:1
Traceability Links Link Role Source Target Meaning verifiedBy sysReq / desReq testCase Test case provides evidence of compliance tracedFrom testCase sysReq / desReq Inverse: requirement verified by test implementedBy desReq function / characteristic Design requirement realized by function/characteristic classifiedWith failureCondition sysReq Failure condition classified against requirement
Safety Analysis Links Link Role Source Target Meaning causedBy failureMode failureCondition Failure mode identified for condition mitigatedBy failureMode / failureCondition riskControl Risk control addresses hazard cascadesTo failureMode (SFMEA) failureMode (DFMEA) System failure mode traced to component DFMEA linkedToHazard failureCondition hazard Failure condition identified as hazard
Custom Fields by Entity Type This section documents custom fields observed in the Aero1 FCC reference project. Additional custom fields may exist per project.
Failure Mode Fields Field Type Default Description severityEnumeration (1-5) — ARP 4761 severity: 1=Minor, 5=Catastrophic occurrenceEnumeration (1-5) — Probability of failure occurrence detectionEnumeration (1-5) — Likelihood of detection before impact RPN (pre-mitigation)Computed severity × occurrence × detection Risk Priority Number before control postMitigationRPNComputed severity × occurrence × detection (post control) RPN after risk control implementation
Requirement Fields Field Type Default Description DALEnumeration (A-E) — Design Assurance Level per ARP 4754A classificationEnumeration — ARP 4761 classification (Catastrophic/Hazardous/Major/Minor/No Effect) systemDecompositionLink — Parent requirement for traceability systemElementLink — System element to which requirement is allocated
System Element Fields Field Type Default Description elementTypeEnumeration (System/Subsystem/Component) — Hierarchy level parentSystemElementLink — Parent system element DALEnumeration (A-E) — Inherited from highest-impact requirement
Document Fields Field Type Default Description systemElementIdLink — System element for which document is created templateDocString — SFMEA, DFMEA, FHA, PSSA, SSA, FTA, CCA (risksheet template identifier) workflowEnumeration Draft Document state: Draft → In Review → Approved → Published
Data Model Architecture The diagram below shows the complete entity relationship structure across requirements, design, safety analysis, and verification:
Risksheet Column Structure Risksheet documents organize failure analysis data in columns grouped by analysis phase:
FHA (Functional Hazard Assessment) Columns Column Group Columns Data Type Identification Failure Condition, Flight Phase, Effect Description text Classification ARP 4761 Classification (5-level), Probability Target enumeration, numeric DAL Allocation Design Assurance Level (A-E) enumeration Safety Requirements SR ID, Title, DAL link, text, enumeration Verification Evidence Status enumeration
SFMEA (System FMEA) Columns Column Group Columns Data Type Identification Customer Requirement / Failure Mode link, text Potential Failure Effects, Causes, Downstream Risks (link to DFMEA) text, link Risk Ranking Severity (1-5), Occurrence (1-5), Detection (1-5), RPN, Action Priority enumeration, computed Risk Control Control ID, Title, Status, Implementation Evidence link, text, enumeration, link
DFMEA (Design FMEA) Columns Column Group Columns Data Type Design Element Component, Function / Characteristic link, text Failure Analysis Failure Mode, Effects, Causes text Occurrence Assessment Severity, Occurrence, Detection (current design) enumeration, computed Current Risk Current RPN, Current Action Priority computed, enumeration Risk Control Recommended Controls, Verification Method, Target RPN text, enumeration, computed Post-Mitigation Post-Mitigation Severity, Occurrence, Detection, RPN, Status enumeration, computed, enumeration
Reference Architecture — Flight Control Computer (FCC) The Aero1 FCC reference project demonstrates the complete data model in practice:
Project Statistics:
12 System Elements (1 System, 3 Subsystems, 8 Components)
71 Requirements (25 Customer, 31 System, 15 Design)
260 Failure Modes tracked across 12 DFMEA documents
18 Failure Conditions identified in FHA
214 Risk Controls allocated to failure modes
33 Test Cases providing verification evidence
63 Characteristics defining design intent
Standards Mapping Each requirement, failure mode, and risk control is classified against applicable standards:
Standard Primary Entity Types Key Fields Evidence Documents ARP 4754A System/Design Requirement DAL (A-E), classification System & Design Requirement Specs ARP 4761 Failure Condition, Risk Control Classification (5-level), DAL FHA, SFMEA, DFMEA, PSSA, SSA DO-178C Design Requirement, Test Case DAL, verification method Design Spec, Test Spec DO-254 Design Requirement, Characteristic DAL, design assurance Design Spec, Characteristics Spec DO-326A Security Threat, Risk Control SAL (I-V), STRIDE category Security Threat Assessment MIL-STD-882E Hazard, Risk Control Hazard severity, probability Hazard Tracking document
Work Item Type Enumeration Values Severity (Failure Mode) Value Definition 1 Minor — No safety impact 2 Low — Minor safety impact with low probability 3 Medium — Moderate safety impact 4 High — Significant safety impact 5 Catastrophic — Loss of critical function
Occurrence (Failure Mode) Value Probability Range Definition 1 < 10⁻⁵ Remote — unlikely to occur 2 10⁻⁵ to 10⁻³ Low probability 3 10⁻³ to 10⁻¹ Medium probability 4 10⁻¹ to 0.5 High probability 5 > 0.5 Very high probability
Detection (Failure Mode) Value Definition 1 Very High — Always detected before impact 2 High — Usually detected 3 Medium — Detected about 50% of the time 4 Low — Rarely detected 5 Very Low — Almost never detected
Risk Priority Number (RPN) Severity RPN Range Classification Priority > 30 High Red — Immediate action required 11–30 Medium Yellow — Action required soon ≤ 10 Low Green — Monitor, defer action
ARP 4761 Classification Classification Impact DAL Target Probability Target Catastrophic Loss of all safety functions DAL A Extremely Improbable (< 10⁻⁹) Hazardous Severe degradation of safety DAL B Extremely Remote (< 10⁻⁷) Major Significant degradation DAL C Remote (< 10⁻⁵) Minor Minor degradation DAL D Reasonably Probable No Effect No impact DAL E N/A
Document Workflow States State Definition Approver Draft Initial creation, under development Author In Review Submitted for peer/management review Reviewer Approved Formally approved, ready for baseline Project Lead Published Released, in production baseline CM
Data Flow Example: Requirements to Test Verification The following sequence illustrates how a requirement traces through the data model to verification:
Configuration Interactions Custom field values and enumeration constraints may vary by project. Consult the project’s .polarion/documents/fields/custom-fields.xml and .polarion/nextedy/models/ configuration for definitive field specifications.
DAL Propagation: When a Failure Condition is classified at a particular DAL level, all parent requirements automatically inherit that DAL or higher. The system enforces that lower requirements (sysReq, desReq) meet or exceed the DAL of safety-critical failure conditions.RPN Computation: Risk Priority Number is calculated as Severity × Occurrence × Detection. When risk controls are implemented, post-mitigation RPN is recalculated with updated Occurrence and Detection values. Controls reducing RPN below 30 (high severity) threshold change Action Priority from urgent to routine.Traceability Constraints: Every Design Requirement must have at least one Test Case. Every Failure Mode must have either a Risk Control or documented justification (e.g., “no control needed — acceptable risk”). Test Cases must map back to at least one System or Design Requirement for requirements-based validation.See Also
Code: .polarion/pages/spaces/_default/Home/page.xml (0.46) · .polarion/pages/spaces/Requirements/Home/page.xml, Design/Home/page.xml, Risks/Home/page.xml, Testing/Home/page.xml, Risks/FMEA Reports/page.xml, Documentation/Home/page.xml, Documentation/Powersheet Help Redirect/page.xml, RiskTemplates/Home/page.xml (0.45) · 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.42) · .polarion/pages/spaces/_default/Program Manager Dashboard/page.xml, Safety Engineer Dashboard/page.xml, Design Engineer Dashboard/page.xml, VandV Engineer Dashboard/page.xml, Config Manager Dashboard/page.xml (0.40) · .polarion/pages/spaces/_default/Data Model/page.xml (0.39)
