| Requirement | Description | Practical Implementation |
|---|---|---|
| Production process compliance | Manufacturing process shall not compromise safety goals | Process FMEA for production; supplier audit; statistical process control (SPC) for safety-critical components |
| ESD and handling controls | Safety-critical components sensitive to ESD damage | ESD wriststraps; controlled environments; incoming inspection of safety MCUs |
| Programming traceability | Every ECU must have traceable SW version and key provisioning | Serial number → SW version → signing key → flash timestamp in NvM (fingerprint) |
| EOL functional test | Each ECU must pass functional safety test before shipment | EOL tester checks ASIL-D diagnostic paths; validates CRC; confirms safe state transitions |
| Non-conforming parts | Detection and handling of defective ECUs | Quarantine; root cause analysis; DRBFM (Design Review Based on Failure Mode) |
ISO 26262 Part 7: Production Phase
Field Monitoring and Incident Reporting
| Activity | Trigger | Action | ISO 26262 Reference |
|---|---|---|---|
| DTC field monitoring | High rate of specific DTC in fleet | Root cause analysis; corrective action | Part 7 Clause 7.5 |
| Crash data analysis | Vehicle involved in incident with ASIL system active | Extract EDR data; determine if safety mechanism acted correctly | Part 7 Clause 7.5 |
| Customer complaint analysis | Reports of unexpected braking, steering, etc. | DRBFM; field return analysis; corrective action | Part 7 Clause 7.5 |
| Safety recall | Confirmed safety defect; regulatory requirement | RAPEX/NHTSA notification; recall campaign; OTA fix if possible | Part 7 Clause 7.6 |
| SOTIF monitoring | Unexpected ADAS behaviour in edge cases | Update ODD; retrain model; update safety case | ISO 21448 |
Safety Impact of OTA Changes
Markdownota_safety_impact.md
# Safety Impact Assessment: OTA Software Update
## Change Description
SW patch v3.5.2 → v3.5.3: fix for CAN timeout counter wraparound bug (SSR-AEB-002)
## Safety Impact Analysis
### 1. Identify Affected Safety Requirements
- SSR-AEB-002: radar CAN timeout detection
- SSR-AEB-003: safe state transition on timeout
- Safety Goal: SG-01 (no unintended AEB activation)
### 2. Assess Impact
Bug fix: counter wraparound caused timeout detection to temporarily disable itself
at counter = 65536 (every ~1.8 days of runtime).
Impact: during 2ms window, radar timeout not detected → safety mechanism inactive.
ASIL impact: ASIL-D — temporary reduction in diagnostic coverage.
### 3. Required Activities Before OTA Deployment
☐ Updated unit tests for wraparound case (TC-AEB-010a, TC-AEB-010b)
☐ MC/DC re-verification for modified module (tool: VectorCAST)
☐ Regression test: all SSR-AEB-* test cases pass
☐ MISRA re-scan: 0 new mandatory violations
☐ Updated FMEA: DC re-confirmed at 97%
☐ Hardware metrics re-run: SPFM still ≥ 99%
☐ Change review (I1): SW Safety Engineer sign-off
☐ Safety plan update: change record added
☐ Safety case update: SC-042, SC-044 updated with new test results
### 4. OTA Deployment Safety Gate
All above activities complete before OTA campaign deployment.
Rollback plan: revert to v3.5.2 if new field reports emerge post-deployment.Summary
The production and operation phase is often underestimated in safety planning — it is not the end of safety responsibilities but the beginning of real-world validation. Field monitoring data is the most valuable feedback loop for improving safety analysis: a DTC appearing in 0.1% of the fleet may indicate a failure mode that was not identified in the pre-production FMEA. OTA software updates in production must be treated as safety-relevant changes requiring a full safety impact assessment — the same rigour as development-phase changes, because the safety case must remain valid for the entire vehicle lifetime. UNECE R155/R156 (cybersecurity and software update regulations) add regulatory teeth to this requirement.
🔬 Deep Dive — Core Concepts Expanded
This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.
Key principles to reinforce:
- Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
- Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
- Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.
🏭 How This Topic Appears in Production Projects
- Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
- Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
- Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.
⚠️ Common Mistakes and How to Avoid Them
- Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
- Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
- Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
- Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.
📊 Industry Note
Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.