Overview
Functions serve as the bridge between system requirements and safety analysis. They define what the system does and enable systematic identification of failure modes that could compromise safety-critical operations. Key Characteristics:- Used in both SFMEA (system-level failure analysis) and FHA (functional hazard assessment)
- Can have failure modes linked via the ‘failures’ relationship
- Can have failure conditions derived from their failure modes
- Support hierarchical decomposition within subsystems
- Subject to DAL allocation through parent system elements
Work Item Type Definition
| Property | Value |
|---|---|
| Type ID | function |
| Type Name | Function |
| Icon | Default work item icon |
| Sort Order | 4 (within architecture types) |
| Description | System functions analyzed for failure modes in SFMEA/FHA |
| Primary Use | ARP 4761 safety assessment, functional decomposition |
| Related Standards | ARP 4761, ARP 4754A, DO-178C |
Custom Fields
Function work items do not define custom fields. All attributes are captured through:- Standard Polarion fields (ID, title, description, status)
- Traceability links to related work items
- Document-level context (subsystem, system element allocation)
Application-specific attributes (e.g., performance requirements, failure rate thresholds) may be stored in description fields or related characteristic work items. Consult the Aerospace Safety Solution UI for function-specific properties.
Relationships and Traceability
Functions participate in the following traceability relationships:| Relationship | Direction | Target Type | Purpose |
|---|---|---|---|
| failures | Outbound | FailureMode | Links function to FMEA failure modes |
| parent | Bidirectional | Function or SystemElement | Hierarchical decomposition within subsystem |
| allocated-to | Outbound | SystemElement | Allocates function responsibility to system element |
| supports | Outbound | SystemRequirement | Satisfies system-level requirement |
| realizes | Outbound | SystemRequirement | Implements customer/system requirement |
Example Traceability Chain
- SystemRequirement: “Maintain stable flight control” ↓ realizes
- Function: “Compute control surface deflections” ↓ failures
- FailureMode: “Incorrect control surface command” ↓ causes
- FailureCondition: “Loss of pitch control”
Usage in Analysis Documents
In SFMEA (System FMEA)
Functions are the primary analysis subjects in system-level FMEA:- Each row in an SFMEA risksheet typically represents a function or function failure
- Failure modes are identified by asking “What could prevent this function from operating correctly?”
- Severity and occurrence rates are assessed for each failure mode
- Risk Priority Number (RPN) is calculated from severity, occurrence, and detection
- Function: “Receive pilot control input”
- Failure Mode: “Loss of control input signal”
- Severity: 9 (Hazardous)
- Occurrence: 4 (Remote)
- Detection: 3 (Occasional)
- RPN: 108 (high risk)
In FHA (Functional Hazard Assessment)
Functions identify functional hazards that lead to failure conditions:- Functions are decomposed into sub-functions
- Potential functional failures are identified (loss of function, erroneous function, intermittent function)
- Failure conditions are derived from combinations of functional failures
- Severity classification (Catastrophic, Hazardous, Major, Minor, No Safety Effect) is assigned per ARP 4761
- Function: “Generate landing gear control signal”
- Functional Failure: “Fail to generate signal”
- Failure Condition: “Landing gear fails to extend”
- Severity: Hazardous
- Allocated DAL: C
Function Hierarchy
Functions may be organized hierarchically within a subsystem:
- System-level SFMEA analyzes top-level functions
- Subsystem SFMEA provides detailed analysis of sub-functions
- Each level identifies failure modes appropriate to its scope
Integration with System Elements
Functions are allocated to system elements to establish design responsibility:| System Element Type | Typical Function Allocation |
|---|---|
| System | High-level system functions (e.g., “Provide flight control”) |
| Subsystem | Major subsystem functions (e.g., “Process sensor inputs”) |
| Assembly | Component-level functions (e.g., “Digitize analog signal”) |
| Component | Lowest-level functions performed by single LRU |
Data Model Context
From the Aerospace Safety Solution RTM model: Entity Type: FunctionPurpose: Central to ARP 4761 safety assessment
Features: Links to both FailureModes (FMEA) and FailureConditions (FHA) Functions enable traceability from system decomposition through safety analysis to design implementation:
Creating and Managing Functions
Function creation workflow, numbering conventions, and document organization are defined in the Aerospace Safety Solution. Consult the Create Your First Functional Hazard Assessment tutorial and How-To Guides for step-by-step procedures.
- Systems Engineering Phase — Initial functional decomposition from requirements
- Safety Analysis Phase — Refinement during FHA/SFMEA based on identified hazards
- Detailed Design Phase — Final allocation to design elements and components
Related Pages
- System Element (systemElement) — Container for function allocation
- Failure Mode (failureMode) — Failure analysis of each function
- Failure Condition (failureCondition) — Safety outcomes from functional failures
- Characteristic (characteristic) — Design implementation of functions
- How-To: Identify System Failure Modes (SFMEA) — Function-based failure analysis
- Getting Started: V-Model Walkthrough — Function role in development process
Sources: Extracted from Aerospace Safety Solution RTM domain model (function entity type) and PowerSheet configurations (Function expressions, work item trees). Function-specific custom fields and application UI behavior should be verified in the running system.
Source References (dev)
Source References (dev)
Code:
.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.45) · .polarion/tracker/fields/workitem-type-enum.xml (0.41) · .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.39) · .polarion/nextedy/models/rtm.yaml (0.37)