⚙️ Function represents an operational capability or behavior of a System Element. Functions form the basis of functional decomposition in ISO 26262 and serve as the parent entity in Design FMEA (DFMEA) analysis hierarchies.
Overview
Functions describe what a system element does, independent of how it does it. In the TestAuto2 — Automotive Safety Solution data model, Functions enable:
- Functional decomposition — Breaking down system capabilities into subsystem and component functions
- DFMEA hierarchies — Organizing failure mode analysis at multiple decomposition levels (system function → subsystem function → component function)
- Characteristic allocation — Linking design characteristics to the functions they implement
- Verification planning — Tracing verification test cases to functional requirements
Functions are typically created during the system design phase (ISO 26262 Part 5) and refined through design decomposition. Each function links to exactly one parent system element and can contain multiple child functions (for hierarchical decomposition) and failure modes (for FMEA analysis).
Standard Properties
| Name | Type | Default | Description |
|---|
objectId | String | Auto-generated | Unique persistent identifier (e.g., TA-F-001). Assigned by Polarion’s outline numbering system. Read-only. |
title | String | Required | Function name (e.g., “Sensor Fusion Processing”, “CAN Message Reception”). Appears in all traceability and reporting views. |
description | String | Optional | Functional specification detailing what the function does, input/output interfaces, timing constraints, or operational modes. Use for clarity when title is ambiguous. |
status | Enum | draft | Work item lifecycle state. Valid values: draft, inProgress, inReview, pendingApproval, approved, rejected, obsolete. See Workflow Lifecycle. |
assignee | User | Unassigned | Owner responsible for defining and validating the function. Required before transitions to inProgress or review states. |
priority | Enum | medium | Function importance for scheduling and resource allocation. Values: low, medium, high, urgent. Does not affect ASIL or safety classification. |
category | Text | Optional | Free-form tags for organization (e.g., “sensor-processing”, “safety-critical”). Useful for filtering in PowerSheets and reports. |
Relationship Properties
| Link Role | Target Type | Cardinality | Description |
|---|
allocatedFrom | System Element | 1..1 | Parent system element that owns this function. Every function must be allocated to exactly one system element. Cannot be changed after creation. |
contains | Function | 0..* | Child functions representing lower-level functional decomposition. Enables hierarchical refinement: system function → subsystem functions → component functions. |
analyzedBy | Failure Mode | 0..* | Failure modes that describe how this function can fail. Backward link from failure modes via analyzesFun relationship. Each failure mode is analyzed for one or more functions. |
allocatesToFun | Characteristic | 0..* | Design characteristics that realize this function’s requirements. Back-link from characteristics via refines relationship. Links functions to measurable design parameters. |
verifiedBy | Verification Test Case | 0..* | Verification test cases confirming the function meets its specification. Back-link from test cases. Used in verification coverage reporting. |
Custom Fields
| Name | Type | Default | Description | Usage |
|---|
functionId | String | Optional | Business identifier distinct from objectId (e.g., “FUNC-SENSOR-001”). Useful for cross-system traceability or legacy system mapping. Leave blank to use objectId. | |
functionType | Enum | Required | Classification of function scope. Valid values: system, subsystem, component. Must match the parent system element’s elementType. Used in DFMEA Risksheet hierarchy configuration. | |
safetyRelevant | Boolean | false | Marks functions that directly contribute to safety goals (ISO 26262). When true, all failure modes of this function inherit ASIL classification from linked Safety Goals. Used in safety readiness scorecard calculations. | |
functionalSafety | Enum | notApplicable | Indicates whether this function implements a safety requirement. Valid values: notApplicable, functionalSafety, sotif (ISO 21448). Affects verification planning and standards compliance reporting. | |
description_fr | String | Optional | French-language function description. Localization field for multinational projects. | |
businessArea | Enum | Optional | Organizational context: sensing, processing, actuation, communication, power, control. Useful for cross-functional team filtering. | |
Workflow Lifecycle
Functions follow the standard seven-state lifecycle:
Key state transitions for functions:
| From | To | Requires | Clears | Use Case |
|---|
draft | inProgress | Assignee | — | Begin functional specification |
inProgress | inReview | Assignee | — | Peer review of function definition |
inReview → pendingApproval | Formal approval signatures | — | Freeze function before decomposition | |
pendingApproval → approved | ≥1 approved, 0 disapproved | — | Function baseline approved | |
Any → obsolete | Resolution field | All signatures | Function superseded by another | |
DFMEA Hierarchy Configuration
Functions enable multi-level Design FMEA organization. The Risksheet hierarchy is configured to respect function decomposition:
| Level | Entity Type | Parent Relationship | Risksheet Collapse Behavior |
|---|
| L1 (Analysis Scope) | Function | allocatedFrom system element | Collapse L1 hides all subsystem functions |
| L2 (Subsystem Detail) | Function | contains parent subsystem function | Collapse L2 hides component-level failure modes |
| L3 (Component Detail) | Failure Mode | analyzesFun link from DFMEA row | No collapse; rows are atomic |
System: AEB System
└─ Function: Sensor Fusion Processing (SYSTEM type)
├─ Failure Mode: Incorrect fusion output → Risk Control, AP=M
└─ Function: Camera Data Processing (SUBSYSTEM type)
├─ Failure Mode: Frame timeout in processing pipeline → Task, AP=H
└─ Function: Image Preprocessing (COMPONENT type)
└─ Failure Mode: Bayer color decoding error → Risk Control, AP=M
{
"levels": [
{ "type": "Function", "collapseProperty": "contains", "sortBy": "id" },
{ "type": "Failure Mode", "collapseProperty": "analyzedCauses", "sortBy": "severity" }
]
}
Characteristics and Verification Tracing
Functions connect design characteristics to lower-level requirements via the functional decomposition tree:
When creating Characteristics for ISO 26262 Part 5 (Hardware) or Part 6 (Software), link them to the lowest-level component function:
- Design Requirement: “SoC clock frequency precision +/-5%”
- Characteristic: “Crystal oscillator frequency 24 MHz +/-1.2%”
- [allocatesToFun] System-on-Chip (SoC) > Component Function: “Timing Reference Generation”
- Verification Test Case: “TCLOCK-002: Measure crystal frequency stability”
This traceability enables the Safety Readiness Scorecard to compute SC/CC Design Req → Characteristic → Failure Mode coverage (see System Element Hierarchy for design workflow details).
Safety Classification and ASIL Inheritance
When a function is marked safetyRelevant = true, all failure modes analyzed against it inherit ASIL classification from linked Safety Goals:
- Identify functions that implement safety goals (e.g., “Sensor Fusion Processing” implements SG-02 “Ensure obstacle detection reliability”)
- Mark
safetyRelevant = true on the function
- Link the function to the corresponding Safety Goal via custom field or RTM relationship
- Create failure modes for the function — they automatically inherit ASIL from the safety goal
- Verify post-mitigation — DFMEA workflow tracks pre-mitigation AP and post-mitigation AP after risk controls are defined
ASIL does not flow through functions; it flows from safety goals. The function serves as the traceability link between the safety goal (top-level requirement) and the failure modes (design analysis). A single function can contribute to multiple safety goals (e.g., if several failure modes impact different goals), so DFMEA columns must allow multiple AP values.
Functional Decomposition Best Practices
Multi-Level Decomposition
Create at least three levels for complex systems:
- System Function — Overall capability (e.g., “Automatic Emergency Braking Activation”)
- Subsystem Functions — Decomposed by architecture (e.g., “Sensor Fusion”, “Decision Logic”, “Brake Command Generation”)
- Component Functions — Technology-specific implementations (e.g., “CAN Message Reception”, “ASIL B SoC Processing”)
Each level should have at least 2–3 child functions to justify decomposition.
Naming Convention
Use action verbs and nouns to make function titles self-documenting:
- ✅ Good: “Process Camera Frame Data”, “Generate AEB Activation Command”, “Monitor Sensor Validity”
- ❌ Poor: “Processing”, “Command”, “Sensor”
Verification Linking
For each function, ensure at least one verification test case confirms functional correctness:
- System functions verified by system verification test cases (end-to-end tests)
- Component functions verified by design verification test cases (unit/integration tests)
ASIL Consistency
Do not mix ASIL A and ASIL D functions in the same subsystem without clear decomposition. If one component function is ASIL D and another is ASIL A, consider separate design variants or document the rationale (e.g., “Sensor input ASIL D; low-level preprocessing ASIL A”).
Integration with PowerSheet
Functions appear in the Subsystem Functions PowerSheet view, which displays:
- Function metadata: ID, title, classification (SC/CC), description
- Failure modes as linked rows: ID, description, Action Priority, severity/occurrence/detection ratings
- Workflow state indicators: color-coded cell backgrounds for draft/inProgress/approved statuses
Use this sheet to:
- Define and review function specifications before DFMEA
- Allocate characteristics to functions
- Verify DFMEA coverage — ensure every function has at least one failure mode analyzed
- Track approval — workflow state column shows which functions are baselined
Reporting and Metrics
Functions contribute to multiple safety readiness metrics:
| Report | Metric | Calculation |
|---|
| System Structure Navigator | Function Count | Total functions per system element |
| FMEA Coverage Report | DFMEA Coverage % | (Functions with ≥1 failure mode) / (Total functions) |
| Safety Readiness Scorecard | Functional Decomposition | Ratio of component-level functions analyzed in DFMEA |
| Requirements Traceability Report | Verification Coverage | (Functions with ≥1 verification test case) / (Total functions) |
Functions without linked failure modes or characteristics are flagged as “uncovered” in FMEA and verification coverage reports. Before publishing safety documentation, ensure every function has at least one of: failure mode, characteristic, or verification test case link.
See Also
