Skip to main content
In the Aerospace Safety Solution, characteristics are central to design FMEA (DFMEA) analysis — each failure mode in a DFMEA is linked to a characteristic via the “assesses” relationship, capturing how a failure affects the design property being evaluated.

​
Overview

PropertyValue
Work Item Type IDcharacteristic
Icontype_characteristic.gif
Sort Order5
Typical ModuleDesign space (characteristicsSpecification documents)
Primary RelationshipsAssessed by failureMode (DFMEA), supports desReq (design requirements)
Key StandardsARP 4754A (system architecture), ARP 4761 (DFMEA analysis)
Characteristics form a critical node in the aerospace RTM domain model. They decompose design requirements into specific measurable properties, and serve as the focal point for DFMEA analysis where each failure mode assesses one or more characteristics.

​
Custom Fields

Characteristics have 3 custom fields that define their engineering specification and safety classification:
Field NameTypeEnum Values / ConstraintsDescription
classificationEnumsc (Safety-Critical), cc (Criticality Classified)Safety classification inherited from or aligned with parent design requirements. SC/CC designation flows down from requirements decomposition per ARP 4754A.
targetValueString (plain text)No constraintsThe nominal or target value for this design characteristic. Example: “3.2 VDC ± 0.1V” or “50 MHz clock frequency”. Used for specification tracking and tolerance bands.
toleranceString (plain text)No constraintsAllowable variation range around the target value. Example: “±5%” or “±0.1 mm”. Documents the engineering tolerance for manufacturing and verification.
The classification field should be consistent with the parent design requirement’s classification. If a design requirement is SC, all characteristics supporting that requirement should typically be SC. Verify alignment during design decomposition reviews.

​
Lifecycle and States

Characteristics follow the standard Polarion work item workflow:
  • Draft — Under development, not yet reviewed
  • In Review — Awaiting technical review
  • Pending Approval — Reviewed, awaiting formal approval
  • Approved — Baseline characteristic, locked for traceability
  • Rejected — Not approved; rework required
  • Obsolete — Superseded or no longer applicable
Characteristics should be approved before DFMEA analysis begins. Approved characteristics are immutable in the RTM, preventing mid-analysis changes that would break failure mode linkages.

​
Relationships and Traceability

​
Inbound Relationships

SourceRolePurpose
Design Requirement (desReq)supportsA characteristic supports one or more design requirements. The relationship maps detailed measurable properties to their parent requirement.
Failure Mode (failureMode)assessesA failure mode assesses a characteristic. This is the key DFMEA relationship — each failure mode in a DFMEA document links to a characteristic to specify which design property is being analyzed.

​
Outbound Relationships

TargetRolePurpose
Test Case (testCase)linked via PowerSheetCharacteristics are traced to test cases through PowerSheet expansion (Design Verification Sheet and component-level characteristics PowerSheets). Test cases verify the characteristic’s target value and tolerance.
System Element (systemElement)implicit scopingA characteristic belongs to or is associated with a system element (component or subsystem) through document scoping. Component DFMEA documents contain component-level characteristics.

​
Usage in DFMEA Analysis

Characteristics are the primary objects of failure analysis in Design FMEA: 
Design Requirement (e.g., "Output voltage shall be 3.2 VDC ± 0.1V")
    ↓ supports
Characteristic (e.g., "Output Voltage", targetValue: "3.2 VDC", tolerance: "±0.1V", classification: "SC")
    ↑ assessed by
Failure Mode (e.g., "Output voltage drifts to 2.8 VDC")
    ↓ may cause
Failure Condition (e.g., "Loss of flight control input")
In a DFMEA risksheet, each row represents a failure of a characteristic. The analyst:
  1. Selects a characteristic (or group of characteristics) to analyze
  2. Identifies all ways that characteristic could fail (failure modes)
  3. Assesses the severity, occurrence, and detectability of each mode
  4. Calculates the Risk Priority Number (RPN: Severity × Occurrence × Detection)
  5. Recommends mitigation actions for high-RPN items
  6. Re-scores post-mitigation
A typical DFMEA row structure is: System Element → Characteristic → Failure Mode → Cause → Effect → S/O/D/RPN → Action → Post-Mitigation S/O/D/RPN.

​
Document Allocation

Characteristics are organized at the component and subsystem level:

​
Component-Level Characteristics

Each component (ADCI, IRU, MFP, etc.) has its own characteristicsSpecification document listing all measurable design properties specific to that component. Example:
  • Air Data Computer Interface (ADCI): 8 characteristics (signal conditioning, filtering, resolution)
  • Main Flight Processor (MFP): Power supply voltage stability, clock frequency, memory access timing
  • Non-Volatile Memory Module (NVM): Data retention time, endurance cycles, error correction

​
Subsystem-Level Characteristics

Subsystems aggregate characteristics from their child components and define subsystem-level properties:
  • Sensor Interface Module: Sensor input filtering, conversion accuracy, sampling rate
  • Processing Core Module: Processing latency, memory bandwidth, built-in test coverage
The exact count and organization of characteristics per system element can be viewed in the aero1 project’s characteristicsSpecification documents or the component-level PowerSheets (e.g., “Air Data Computer Interface (ADCI) - Design Characteristics”).

​
Example Characteristics (Flight Control Computer)

The following table illustrates real characteristics from the aero1 Flight Control Computer project:
System ElementCharacteristic NameTarget ValueToleranceClassificationAssociated Failure Mode
Main Flight Processor (MFP)CPU Clock Frequency50 MHz±1%SCClock phase drift
Main Flight Processor (MFP)L1 Cache Hit Rate92%±3%SCExcessive cache misses
Non-Volatile Memory Module (NVM)Data Retention Time10 yearsAs per MIL-STDSCLoss of stored parameters
Power Supply Unit (PSU)Output Voltage (3.3V rail)3.3 VDC±5%SCUnder-voltage condition
Power Supply Unit (PSU)Ripple & Noise50 mVpp<100 mVppCCEMI coupling to sensitive circuits
ARINC 429 Bus InterfaceBus Propagation Delay5 µs±0.5 µsSCTiming synchronization loss
Inertial Reference Unit Interface (IRU)Sensor Input Impedance10 kΩ±10%CCSignal attenuation

​
Classification Alignment

The classification field on a characteristic must align with its parent design requirement and ultimately trace back to customer requirements and system requirements: 
Customer Requirement (Safety-Critical)
    ↓ refines to
System Requirement (Safety-Critical)
    ↓ refines to
Design Requirement (Safety-Critical)
    ↓ supports
Characteristic (SC classification)
    ↑ assessed by
Failure Modes in DFMEA (SC severity)
A characteristic marked as SC (Safety-Critical) indicates that failure of that design property could result in unsafe operation. DFMEA analysis of SC characteristics must include comprehensive failure mode identification and mitigation planning. A characteristic marked as CC (Criticality Classified) indicates that the property is not directly safety-critical but is classified for traceability due to its relationship to safety requirements or manufacturing constraints.
Always verify that characteristic classifications are consistent with their parent design requirements. Misaligned classifications can lead to incomplete DFMEA coverage or over-analysis of non-critical properties. Use the ARP 4754A System Development Assurance PowerSheet to validate classification flow-down.

​
Integration with PowerSheet

Characteristics appear in several PowerSheet configurations for traceability and verification:
PowerSheetPurposeKey Columns
Component RTMComponent-level requirements traceabilityDesign Req ID → Characteristic → Function
Design Verification SheetDesign req to test case mappingDesign Req → Characteristic → Test Case
Component CharacteristicsComponent-specific property listingSystem Element → Characteristic → Target Value → Test Case
DO-160G EnvironmentalEnvironmental qualification traceabilityDesign Req → Characteristic (as env spec) → Test Case
When viewing a component’s characteristics PowerSheet (e.g., “Air Data Computer Interface (ADCI) - Design Characteristics”), each row represents one characteristic with columns for target value, tolerance, SC/CC classification, and linked test cases.

​
Custom Field Examples

​
Classification Field

Value: sc
Display: Safety-Critical

Value: cc
Display: Criticality Classified

​
Target Value Field

Examples of valid target values:
  • Electrical: “3.3 VDC ± 5%”, “50 MHz”, “200 mA max”
  • Mechanical: “2.5 kg ± 0.1 kg”, “50 mm diameter”, “M6 thread, class 6g”
  • Thermal: “-40°C to +85°C”, ”< 75°C junction temp”
  • Performance: ”< 500 µs latency”, “99.99% availability”

​
Tolerance Field

Examples of valid tolerance specifications:
  • Percentage: “±5%”, “±0.5%”
  • Absolute: “±0.1 V”, “±0.01 mm”
  • Range: “50 MHz to 52 MHz”
  • Statistical: “3σ control limit”
  • Manufacturing: “Per AS9102 Form 1”
Target value and tolerance should be specific enough for both design validation and manufacturing verification. Vague specifications (e.g., “good performance”) lead to ambiguous DFMEA analysis and test case design.

​
Grounding and Verification

The complete set of characteristics for each system element can be reviewed in the aero1 project by navigating to:
  • Design space → characteristicsSpecification documents
  • Component RTM PowerSheet (component-specific characteristics view)
  • Component characteristics PowerSheets (one per system element)
The integration of characteristics with DFMEA analysis can be seen in the DFMEA risksheets (e.g., “Air Data Computer Interface (ADCI) - Component DFMEA”), where each row links to a characteristic and defines the modes by which that characteristic can fail.
Last Updated: February 2026
Standards: ARP 4754A (System Development Assurance), ARP 4761 (Safety Assessment), DO-178C (Software), DO-254 (Hardware)
Code: .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.59) · .polarion/tracker/fields/workitem-type-enum.xml (0.54) · .polarion/documents/fields/document-type-enum.xml (0.51) · .polarion/pages/spaces/_default/Data Model/page.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.51) · .polarion/nextedy/models/rtm.yaml (0.50) · .polarion/tracker/fields/severity-enum.xml, status-enum.xml, priority-enum.xml, implementationStatus-enum.xml, riskSpecification-document-status-enum.xml (0.50) · .polarion/polarion-project.xml, .polarion/context.properties, .polarion/security/user-roles.xml, .claude/PROJECT.md, TODO.md (0.48) · .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.47) · .polarion/tracker/fields/workitem-link-role-enum.xml (0.45)