Why Multiple Standards?
Automotive functional safety projects rarely comply with just one standard. Instead, they must satisfy a constellation of standards that address different lifecycle phases, risk methodologies, and industry domains:
| Standard | Scope | Key Requirements |
|---|
| ISO 26262 | Functional Safety | ASIL classification, V-model traceability, HARA to Safety Goals |
| AIAG-VDA FMEA | Failure Mode Analysis | Action Priority, Risk Reduction, Design + Process FMEA |
| IATF 16949 / APQP | Production Part Approval | Control Plans, Process Flow, SC/CC classification |
| ISO 14971 | Medical Device Risk Mgmt | HAZID/Risk Matrix, Residual Risk Evaluation |
| ISO 21448 (SOTIF) | Safety of Intended Functionality | Known/Unknown scenarios, Sensor performance limits |
Engineers often assume compliance means implementing standards sequentially (finish ISO 26262, then FMEA, then APQP). TestAuto2’s compliance model proves standards are concurrent: the same failure mode appears in ISO 26262 DFMEA, AIAG-VDA Action Priority analysis, and IATF control plans simultaneously.
How Standards Map to Work Item Types
The compliance model achieves standards integration by mapping regulatory clauses to specific work item types and custom fields:
ISO 26262 Functional Safety Mapping
| ISO 26262 Clause | Work Item Type | Custom Fields | Risksheet/PowerSheet |
|---|
| Part 3-7 (HARA) | hazard, harm, safetyGoal | haraSeverity, haraExposure, haraControllability, asil | HARA Risksheet |
| Part 4 §6 (System Requirements) | sysReq | asilInheritance, verifiedBy | System Verification PowerSheet |
| Part 5 §6 (Hardware Design) | designReq, characteristic | subType, scccClassification, targetValue | Characteristics PowerSheet |
| Part 6 §6 (Software Requirements) | designReq (subType=Software) | softwareLevel, verifiedBy | Design Verification PowerSheet |
| Part 4-6 §7 (FMEA) | failureMode, riskRecord, riskControl | severity, occurrence, detection, actionPriority | DFMEA Risksheet |
AIAG-VDA FMEA Mapping
| FMEA Element | Work Item Type | Custom Fields | Risksheet Config |
|---|
| System/Function | systemElement, function | elementType, functionCategory | SFMEA Risksheet |
| Failure Mode | failureMode | failureEffect, failureCause | DFMEA Risksheet |
| Risk Assessment | riskRecord | severity, occurrence, detection, actionPriority | Embedded in Failure Mode |
| Prevention Control | riskControl (type=Prevention) | controlType, controlDescription | Risk Control Plan Risksheet |
| Detection Control | riskControl (type=Detection) | controlType, controlDescription | Risk Control Plan Risksheet |
| Post-Mitigation | Same work items | postmitigationSeverity, postmitigationOccurrence, postmitigationDetection, postmitigationAP | Post-Mitigation columns |
IATF 16949 / APQP Mapping
| APQP Element | Work Item Type | Custom Fields | Risksheet Config |
|---|
| Process Step | processStep | processDescription, machine, method | Process Flow Risksheet |
| Characteristic | characteristic | scccClassification, targetValue, upperTolerance, lowerTolerance | Characteristics PowerSheet |
| Process FMEA | processFailureMode | pfmSeverity, pfmOccurrence, pfmDetection, pfmRPN | PFMEA Risksheet |
| Control Plan Item | controlPlanItem | measurementMethod, sampleSize, sampleFrequency, reactionPlan | Control Plan Risksheet |
Compliance Verification Architecture
TestAuto2’s compliance model doesn’t just store compliance data—it verifies compliance through automated metrics computed by Velocity macros:
Example: ISO 26262 Part 4 Compliance Calculation
The Safety Readiness Scorecard computes ISO 26262 Part 4 compliance as:
Overall = AVG(Requirements%, Traceability%, Verification%, FMEA%)
Where:
- Requirements% =
sysReq items with at least one outgoing link ÷ total sysReq items
- Traceability% =
sysReq items with ANY link (refines, verifiedBy, assesses) ÷ total
- Verification% =
sysReq items with backlinked test cases (via verifiedBy) ÷ total
- FMEA% =
failureMode items with postmitigationAP value ÷ total failure modes
Every compliance metric on the Safety Readiness Scorecard is clickable—it generates a Lucene query showing exactly which work items cause the gap. For example, “Verification% = 83%” links to the 17% of system requirements missing test case verification.
Standards Alignment Matrix
Different standards have overlapping but not identical lifecycle coverage. The compliance model explicitly maps which standards apply to which lifecycle phases:
| Lifecycle Phase | ISO 26262 | AIAG-VDA | IATF 16949 | ISO 14971 | SOTIF |
|---|
| Concept (Hazard Analysis) | ✅ Part 3 (HARA, ASIL) | ❌ | ❌ | ✅ (HAZID, Risk Matrix) | ✅ (Known scenarios) |
| System Design (Requirements) | ✅ Part 4 (Safety Reqs) | ✅ (System FMEA) | ❌ | ✅ (Risk Controls) | ✅ (Performance limits) |
| Hardware Design (Components) | ✅ Part 5 (HW Reqs) | ✅ (DFMEA) | ✅ (Characteristics, SC/CC) | ✅ (Design Controls) | ❌ |
| Software Design (SW Modules) | ✅ Part 6 (SW Reqs) | ✅ (DFMEA) | ❌ | ✅ (SW Controls) | ❌ |
| Production (Manufacturing) | ❌ | ✅ (PFMEA) | ✅ (Control Plan, PPAP) | ✅ (Process Controls) | ❌ |
| Verification (Testing) | ✅ Parts 4-6 §7 | ✅ (Detection Controls) | ✅ (Control Plan Item) | ✅ (Verification Evidence) | ✅ (Scenario validation) |
- A
failureMode work item satisfies ISO 26262 Part 5 §7 (HW FMEA), AIAG-VDA DFMEA, and ISO 14971 hazardous situation analysis
- A
riskControl work item satisfies ISO 26262 Part 4 (risk treatment), AIAG-VDA prevention control, and ISO 14971 risk control measure
- A
characteristic work item satisfies ISO 26262 Part 5 (HW specification), IATF 16949 SC/CC classification, and ISO 14971 design input
While work items serve multiple standards, each standard has unique field requirements. For example, ISO 26262 requires asil field, AIAG-VDA requires actionPriority field, IATF requires scccClassification. The compliance model uses conditional field visibility in form layouts to show only relevant fields per document type.
How to Use the Compliance Model
Understanding the compliance model helps you:
- Navigate dashboards — Know which dashboard shows which standard’s metrics (Standards Compliance Overview)
- Create compliant documents — Choose the right risksheet template per standard (see Create a HARA Document vs Create Design FMEA Document)
- Interpret gap reports — Understand why a gap exists and which standard it violates (Interpret Compliance Metrics)
- Establish traceability — Know which link roles satisfy which standard (Establish Traceability Links)
- Configure custom fields — Understand which fields are mandatory per standard (Custom Fields Reference)
For practical application of compliance workflows, see:
