Skip to main content

​
Overview

Documents in Aerospace Safety Solution use five core custom fields to establish context and configuration. These fields are critical integration points: they link documents to system architecture, determine which analysis templates and data views are available, and enable dashboards to organize documents by system element and responsible teams.
This reference documents custom fields present in the .polarion/documents/fields/custom-fields.xml configuration file. Field behavior, defaults, and validation rules may vary depending on your project configuration and Polarion version.

​
Document-Level Custom Fields

Field NameTypeDefaultDescription
systemElementIdString(empty)Part ID linking the document to a specific system element in the architecture hierarchy. Used by Home dashboard and space dashboards to organize document inventory per system element. Critical for filtering documents by subsystem or component.
templateDocEnum (@document)(empty)Reference to a template document (e.g., “SFMEA Template”). Determines which risksheet.json schema and top panel are inherited by this document. Controls available columns, formulas, and views in risk analysis sheets.
nextedySheetConfigEnum (@NextedySheetConfigs)(empty)Name of the PowerSheet YAML configuration. Links PowerSheet documents to their column layout, view definitions, and cell formatters. Used for RTM, function, characteristic, and compliance tracking sheets.
versionString(empty)Document version identifier (e.g., “1.0”, “2.1-draft”). Free-text field for release tracking and change management.
teamMulti-Select Enum (@user[project_user])(empty)Assigned team members responsible for the document. Multi-select allows multiple owners and reviewers. Used for dashboards and report filtering by team.

​
Field Dependencies and Integration Points

​
systemElementId → Document Inventory

The systemElementId field is the primary integration point between documents and the system architecture:
  • Home Dashboard: Groups all documents by system element, showing counts per subsystem and component
  • Space Dashboards: Filters document inventory to show only items relevant to that system element
  • RTM Views: Cross-references documents to traced requirements, organized by element
  • Reports: System decomposition reports query this field to build traceability trees
Example usage: A document with systemElementId = "ADCI" (Air Data Computer Interface) appears in:
  • Home dashboard under “ADCI” in the System Elements section
  • Design space dashboard filtered to show only ADCI-related documents
  • Component RTM sheets scoped to ADCI

​
templateDoc → Risksheet Schema and Views

The templateDoc field determines which analysis type a document uses:
TemplateRisksheet TypeColumnsViewsUsed For
SFMEA TemplateSystem FMEA20 columns: Function, Failure Mode, Effects, Severity, Occurrence, Detection, RPN, etc.5 views: All Items, High RPN, Open Controls, Gap Analysis, by SubsystemSystem-level failure mode analysis per ARP 4761
DFMEA TemplateDesign FMEA20 columns: Design Item (characteristic), Failure Mode, Design Effects, Severity, Occurrence, Detection, RPN, etc.5 views: All Items, High RPN, Open Controls, Gap Analysis, by ComponentComponent-level design failure analysis per ARP 4761
FHA TemplateFunctional Hazard Assessment15 columns: Function, Hazard, Failure Condition, Severity, Probability, Mitigation, Status, etc.3 views: All Hazards, Unmitigated, by FunctionARP 4761 functional hazard analysis
Compliance TemplateCompliance Matrix9 columns: Standard, Section, Requirement, Status, Evidence, Owner, Due Date, etc.4 views: All Items, Gaps, By Standard, By DAL LevelGeneric standards compliance (ARP 4754A, DO-178C, DO-254, DO-326A, ARP 4761)
When a document’s templateDoc field is set, the risksheet inherits:
  • Column definitions and merge groups
  • Cell formatting rules (color coding, formula fields)
  • Available workflow views
  • Top panel configuration (buttons, status fields, filters)
Example: Setting templateDoc = "SFMEA Template" enables the 20-column system FMEA layout with RPN auto-calculation and severity×occurrence×detection matrix visualization.

​
nextedySheetConfig → PowerSheet Layout

The nextedySheetConfig field binds a PowerSheet document to its YAML configuration:
ConfigurationScopeColumnsUsed For
RTM-WholeSystemsProject-wideCustomer Req → System Req → Design Req → Test Case traceabilityEnd-to-end requirements traceability matrix
RTM-DesignVerificationDesign-to-TestDesign Req → Characteristic → Test Case verificationDesign verification matrix
Functions-SubsystemPer-subsystemFunction ID, Type, Inputs, Outputs, Performance, ConstraintsFunctional decomposition and performance spec
Characteristics-ComponentPer-componentCharacteristic ID, Type, Target Value, Tolerance, Classification, UnitDesign specification and DFMEA assessment basis
ComplianceMatrix-DO178CDO-178C scopeObjective ID, COTS/I-COTS/Custom, DAL Assignment, Verification Method, StatusDO-178C software assurance objectives
ComplianceMatrix-DO254DO-254 scopeObjective ID, Hardware Type, DAL Assignment, Verification Method, StatusDO-254 hardware design assurance
Setting nextedySheetConfig = "RTM-WholeSystems" loads the multi-level requirements traceability column layout with progressive disclosure views for auditors and managers.

​
Custom Fields by Work Item Type

Beyond document-level fields, Aerospace Safety Solution defines custom fields on individual work items within those documents. These fields are organized by work item type and purpose.

​
Hazard Work Item Fields

Hazard items (used in FHA and hazard tracking documents) include:
FieldTypePurpose
hazardCategoryEnumMIL-STD-882E category (e.g., Malfunction, External, Environmental)
operationalPhaseEnumFlight phase when hazard may occur (Preflight, Takeoff, Cruise, Descent, Landing)
hazardDescriptionTextDetailed description of the hazard condition
hazidCauseTextRoot cause analysis of the hazard
hazidConsequenceTextPotential consequences if hazard occurs
initialSeverityEnumPre-mitigation severity (MIL-STD-882E: Catastrophic, Critical, Marginal, Negligible)
initialProbabilityEnumPre-mitigation probability (Level A–E)
initialRiskEnumComputed initial risk level (High, Medium, Low)
residualSeverityEnumPost-mitigation severity (same scale)
residualProbabilityEnumPost-mitigation probability (same scale)
residualRiskEnumComputed residual risk level
acceptanceAuthorityEnumAuthority approving risk acceptance (Program Manager, Safety, Chief Engineer)
acceptanceStatusTextFree-text acceptance justification or waiver rationale
Key pattern: Initial and residual fields use identical enum types, enabling before-and-after comparison and effectiveness tracking of risk controls.

​
Test Case Custom Fields

Test cases link verification activities to DO-160G environmental categories:
FieldTypePurpose
verificationMethodEnumInspection, Test, Analysis, Demonstration
testLevelEnumUnit, Integration, System, Acceptance
expectedResultTextPlaintext description of expected outcome
passFailCriteriaTextPlaintext objective criteria for pass/fail determination
environmentalCategoryEnumDO-160G category (Temperature, Altitude, Humidity, Vibration, Shock, etc.)
The environmentalCategory field enables qualification tracking — linking test execution to specific environmental qualification sections and supporting DAL-appropriate environmental test planning.

​
Design Requirement Custom Fields

Design requirements bridge requirements to safety classification and environmental testing:
FieldTypePurpose
classificationEnumSC (Safety-Critical) or CC (Common), ARP 4754A classification
environmentalCategoryEnumDO-160G category (same as testCase)
subTypeEnumDesign discipline (Avionics, Mechanical, Electrical, Software, Power Distribution)
The classification field on design requirements flows down from system requirement decomposition — the Classification Consistency Report validates alignment across levels.

​
Characteristic Custom Fields

Characteristics represent measurable product features assessed in DFMEA:
FieldTypePurpose
classificationEnumSC or CC, inherited from parent design requirement
targetValueStringNominal or target specification value
toleranceStringAllowable deviation (e.g., “±0.5%”, “10–20 μm”)
Each DFMEA failure mode links to a characteristic via the assesses link role, establishing the design item under analysis.

​
System Element Custom Fields

System elements define the architecture hierarchy with minimal custom metadata:
FieldTypePurpose
elementTypeEnumType in hierarchy: System, Subsystem, Component, COTS, Assembly (5-level)
dalEnumDesign Assurance Level (A, B, C, D, E) assigned per element
The dal field on system element determines required certification activities — all documents associated with that element inherit the DAL for compliance objective tracking.

​
Risk Control Custom Fields

Risk controls track mitigation strategies:
FieldTypePurpose
riskControlTypeMulti-Select EnumISO 14971 categories: Design, Protective Device, Warning, Training (multi-select: one control may serve multiple strategies)
implementationStatusEnum4-state tracking: Planned, In Progress, Implemented, Verified
The multi-select riskControlType field allows a single control to satisfy multiple risk reduction strategies — for example, a design change that also serves as a protective device.

​
Compliance Requirement Custom Fields

Compliance requirements support standards-agnostic compliance tracking:
FieldTypePurpose
standardNameStringName of standard (ARP 4754A, DO-178C, DO-254, DO-326A, MIL-STD-882E, ARP 4761, DO-160G, etc.)
sectionNumberStringSection or paragraph reference (e.g., “6.4.2.1”)
requirementTextTextFull text of the compliance requirement
complianceStatusEnumCompliant, Partial, Nonc Compliant, Not Applicable
evidenceTypeEnumDocument, Test, Analysis, Waiver, Exemption
Unlike complianceObjective (which is DO-178C/DO-254 specific with per-DAL status), complianceRequirement is standard-agnostic — works for any aerospace standard or customer requirement.

​
Common Cause Event Custom Fields

Common Cause Analysis (CCA) events track correlated failures:
FieldTypePurpose
analysisTypeEnumAnalysis type: ZSA (Zonal Safety Analysis), PRA (Particular Risk Assessment), CMA (Common Cause Monitoring)
affectedFunctionsTextPlaintext list of affected functions (not links)
The affectedFunctions field is text (not work item links) — serves as documentation of impact scope without requiring formal traceability links.

​
Risk Record Custom Fields (ISO 14971 Pattern)

Risk records implement a three-factor risk model (medical device pattern adapted for aerospace):
FieldTypePurpose
preHazardProbability / postHazardProbabilityEnumHazard occurrence probability (1–5)
preHarmProbability / postHarmProbabilityEnumHarm occurrence probability, given hazard
preControlProbability / postControlProbabilityEnumControl efficacy probability
preRisk / postRiskEnumComputed risk level (High, Medium, Low)
benefitTextRisk-benefit analysis text
riskBenefitResultEnumResidual acceptable, Residual unacceptable, Benefit outweighs
additionalControlsPossibleEnumYes, No (feasibility assessment)
hazardousSituationTextDescription of the hazardous situation
finalRiskEnumFinal risk determination after all controls
This three-factor model (P1 × P2 × control) differs from FMEA (severity × occurrence × detection) and MIL-STD-882E (severity × probability) — useful for cross-domain risk management (e.g., HARA for automotive/medical subsystems integrated with aerospace analysis).

​
Process Step Custom Fields

Process steps for PFMEA (Process Failure Mode Effects Analysis) link to system elements:
FieldTypePurpose
processInputsTextDescription of inputs to the process step
processOutputsTextDescription of outputs from the step
processEquipmentTextEquipment or tools required
processVerificationTextControl or verification method
linkedSystemElementWorkItem (systemElement)Typed link to the system element this process supports
The linkedSystemElement uses Polarion’s typed workitem reference (different from the document-level systemElementId which is a string) — enables PFMEA process analysis scoped to a specific system element.

​
Visual Field Dependency Map

diagram

​
Configuration Example

Here is a minimal document configuration showing how custom fields integrate: 
<!-- .polarion/documents/fields/custom-fields.xml -->
<customFields>
  <customField id="systemElementId" name="System Element ID" type="string">
    <description>Part ID linking document to system architecture</description>
  </customField>
  
  <customField id="templateDoc" name="Template Document" type="enum">
    <enumValues>
      <enumValue id="SFMEA_Template" label="SFMEA Template"/>
      <enumValue id="DFMEA_Template" label="DFMEA Template"/>
      <enumValue id="FHA_Template" label="FHA Template"/>
      <enumValue id="Compliance_Template" label="Compliance Template"/>
    </enumValues>
  </customField>
  
  <customField id="nextedySheetConfig" name="PowerSheet Configuration" type="enum">
    <enumValues>
      <enumValue id="RTM-WholeSystems" label="RTM - Whole Systems"/>
      <enumValue id="Functions-Subsystem" label="Functions per Subsystem"/>
      <enumValue id="Characteristics-Component" label="Characteristics per Component"/>
    </enumValues>
  </customField>
  
  <customField id="team" name="Responsible Team" type="multi-enum">
    <enumReference ref="project_user"/>
  </customField>
</customFields>
For deeper guidance on using these fields in practice, see:
Field defaults, enum values, and validation rules should be verified against your project’s .polarion/documents/fields/custom-fields.xml configuration file. Custom project configurations may add, remove, or customize enum values and field behavior.
Code: .polarion/documents/fields/custom-fields.xml (0.54) · .polarion/tracker/fields/hazard-custom-fields.xml (0.42) · .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.41) · .polarion/tracker/fields/complianceRequirement-custom-fields.xml (0.40) · .polarion/tracker/fields/riskRecord-custom-fields.xml (0.38)