Skip to main content

​
Why a Multi-Type Data Model?

A common misconception is that a single “requirement” type with different tags or categories would be simpler to manage. In practice, aerospace programs span fundamentally different engineering disciplines — system decomposition, safety analysis, certification compliance, hardware assurance, and change management — each governed by distinct standards with distinct traceability obligations. The Aerospace Safety Solution models each artifact category as a distinct work item type so that:
  • Traceability is typed, not free-form. A testCase can only verifies a desReq; it cannot accidentally link to a failureCondition through the same role.
  • Fields are contextually appropriate. A failureCondition carries classification, flightPhase, and dalAllocation. A characteristic carries targetValue and tolerance. These fields are meaningless on other types.
  • PowerSheet and Risksheet views filter by type, surfacing only the entities relevant to the engineering activity at hand.
Think of the 22 types as occupying five functional zones: diagram

​
Requirements Zone (3 Types)

Requirements decompose through three levels of specificity, mirroring the V-model left side:
TypeRoleKey Fields
customerRequirementStakeholder intentConstrained to CUSTOMER-REQS module
sysReqSystem-level allocationLinks upward to customerRequirement via refines
desReqDesign-level specificationsubType (system/software/hardware) enables DO-178C vs DO-254 filtering
A fourth safety-derived type, safetyRequirement, exists outside the standard decomposition chain. It originates from FHA failureCondition analysis and carries its own dalLevel and allocatedSubsystem fields. The allocatesTo link role connects failure conditions to the safety requirements they generate — this separation from desReq is intentional. Safety requirements must remain independently traceable to their ARP 4761 source.

​
System Architecture Zone (3 Types)

  • systemElement represents a physical component in the hierarchy (Aircraft → System → Subsystem → LRU → Module, governed by the five-level elementType enum). Each element carries a dal field (A–E) that flows downstream to certification activities.
  • function captures the behaviors a system element must perform. Functions are the primary target of FHA failure condition analysis via the assesses link role.
  • characteristic records measurable design attributes (targetValue, tolerance) and carries the classification field (SC/CC) that feeds DFMEA assessment.

​
Safety Analysis Zone (5 Types)

This is the most differentiated zone, because the solution must support four distinct safety and security frameworks simultaneously.
  • ARP 4761: failureCondition (FHA/PSSA/SSA) ←causeOf── failureMode allocatesTo ▼ safetyRequirement MIL-STD-882E: hazard ──assesses──→ function/systemElement DO-326A: securityThreat ──assesses──→ function/systemElement
  • ARP 4761 CCA: commonCauseEvent (ZSA/PRA/CMA)
The failureMode type underpins FMEA workflows and carries pre- and post-mitigation severity, occurrence, and detection scores, from which RPN is derived. The causeOf link role connects a failure mode to the upstream failure condition it contributes to — this directional link is how the PSSA cascade from FHA is constructed. commonCauseEvent is a specialized type for Common Cause Analysis. Its analysisType enum (ZSA for Zonal Safety Analysis, PRA for Particular Risks Analysis, CMA for Common Mode Analysis) determines which CCA methodology applies. The affectedFunctions field is free text — it documents scope but does not create typed links to function entities.
These two types are frequently confused. A failureCondition is an ARP 4761 FHA artifact — the hazardous state experienced at the aircraft level (e.g., “Loss of pitch control in approach phase”). A failureMode is the physical mechanism causing or contributing to that state (e.g., “Actuator command signal open circuit”). One failure condition may be caused by many failure modes across different subsystems.

​
Compliance Zone (2 Types)

complianceObjective and complianceRequirement represent the objectives-based compliance structure of DO-178C, DO-254, ARP 4761, and related standards. These types exist so that certification auditors can navigate directly from a standard objective to the design artifacts demonstrating compliance, without searching through general requirements.
The exact relationship between complianceObjective and complianceRequirement, including which link roles connect them to desReq or testCase entries, should be verified in the Polarion UI. The configuration files confirm both types exist but do not fully define their link role matrix.
The 20 link roles in the model are not generic associations — each carries semantic meaning that the PowerSheet traceability views depend on. The most important roles for safety engineers to understand:
RoleDirectionMeaning
refinesbidirectional decompositionCustomer → System → Design requirements
assessesanalysis → subjectFailure mode/condition/threat → function or system element
causeOffailureMode → failureConditionFMEA-to-FHA propagation
allocatesTofailureCondition ↔ safetyRequirementFHA output becomes requirement
verifiestestCase → requirementV-model right side
mitigatesriskControl → failureModeRisk reduction evidence
The assesses role is the most versatile: it can originate from a failureMode, failureCondition, securityThreat, or hazard, and it can target either a function or a systemElement. This single role therefore supports ARP 4761, MIL-STD-882E, and DO-326A analysis within a unified traceability graph.

​
Common Status Model

Most work item types share a 6-state lifecycle: Draft → In Review → Pending Approval → Approved → Rejected / Obsolete. The riskControl type adds its own parallel implementationStatus field (Not Started / In Progress / Implemented / Verified) because a control can be approved in the document while still pending physical implementation. For deeper practical application of these types and relationships, see V-Model Traceability Chain, Failure Condition and Failure Mode Hierarchy, and DAL Classification.
Code: .polarion/pages/spaces/_default/Data Model/page.xml (0.51) · .polarion/tracker/fields/resolution-enum.xml, .polarion/tracker/fields/changerequest-resolution-enum.xml, .polarion/tracker/fields/changerequest-status-enum.xml, .polarion/tracker/fields/work-record-type-enum.xml, .polarion/tracker/fields/yesno-enum.xml (0.50) · .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.49) · .polarion/tracker/fields/workitem-type-enum.xml (0.48) · .polarion/tracker/fields/severity-enum.xml, status-enum.xml, priority-enum.xml, implementationStatus-enum.xml, riskSpecification-document-status-enum.xml (0.44) · .polarion/nextedy/models/rtm.yaml (0.43) · .polarion/tracker/fields/workitem-link-role-enum.xml (0.41) · .polarion/polarion-project.xml, .polarion/context.properties, .polarion/security/user-roles.xml, .claude/PROJECT.md, TODO.md (0.41) · modules/RiskTemplates/DFMEATemplate/module.xml, modules/Risks/DFMEA-CMP-PSU/module.xml, modules/_default/WholeRTMSheet/module.xml, modules/Requirements/CUSTOMER-REQS/module.xml (representative of ~50 module.xml files across all spaces and templates) (0.40) · .polarion/documents/fields/document-type-enum.xml (0.40)