Functional Safety (ISO 26262)

▸ Item definition content requirements (ISO 26262-3 Clause 5.4): functional description: what the item does (not how); item boundaries: physical (ECU pin list), functional (I/O signals), system (external items); operational states: power-on, normal operation, reduced function, off; assumptions of use (AoU): environmental (operating temperature -40 to 125°C), mechanical (vibration 10–2000 Hz), electrical (supply 6–18V, load dump 40V); item context: vehicle level functions provided by item; example EPS item definition: "EPS Module provides power-assisted steering based on driver torque input and vehicle speed; interfaces: CAN (vehicle speed 0–250 km/h, requested torque ±10 Nm), LIN (column motor feedback), ADC (torque sensor 0–5V)"

▸ Operational scenarios & driving situations: ISO 26262-3 Clause 6.4.3 requires systematic enumeration of operating scenarios; scenario attributes: situation description, vehicle speed range, probability of occurrence (E0–E4), driver expected behavior; example scenarios for EPS: S1 = normal driving on highway (100–130 km/h, driver alert, exposure E3=medium); S2 = parking < 5 km/h (daily, E4=very high); S3 = evasive maneuver (rare, E2=low but high severity if EPS fails); S4 = wet road cornering (E3); S5 = trailer towing (reduced speed, E2); tool: scenario matrix in Excel or IBM DOORS table; traceability: each scenario → HARA row → Hazard ID → Safety Goal → FSR

▸ Functional description & I/O interface specification: item functional block diagram: driver torque input → torque sensor (SPI, 1 kHz update) → EPS ECU → motor driver (3-phase PWM at 20 kHz) → EPS motor; input signals: C_VehicleSpeed (CAN, km/h, 10ms cycle), C_SteeringAngle (CAN, deg), C_IgnStatus (KL15), S_TorqueSensor1/2 (SPI, dual redundant); output signals: M_MotorCurrent (PWM), M_StatusFeedback (CAN), D_FaultLamp (GPIO); non-functional requirements: response time ≤ 10 ms for torque control loop; availability: item available in 99.99% of vehicle operation time; ASIL allocation at item level: ASIL D (before decomposition)

▸ Item definition quality criteria: completeness check: all ECU inputs/outputs listed; all operating modes covered; supplier-specific external items identified; assumptions of use documented; common mistakes: (1) listing internal software as item boundary (wrong - item boundary is the physical connector); (2) omitting failure modes of external items (e.g., CAN bus stuck dominant); (3) not specifying environmental conditions → FMEDA incorrect derating; example DIA clause referencing item definition: "Tier-1 guarantees EPS ECU behavior as specified in Item Definition v1.3; OEM guarantees CAN message encoding per DBC v2.1"; item definition reviewed at PDR (Preliminary Design Review) milestone; tools: IBM DOORS, PTC Integrity, Polarion - create baseline of item definition before HARA starts

▸ HARA process steps (ISO 26262-3 Clause 6): Step 1: Identify hazardous events - for each item function × operational scenario → what malfunctions can cause harm?; Step 2: Rate Severity (S0–S3), Exposure (E0–E4), Controllability (C0–C3); Step 3: Determine ASIL = S×E×C matrix (ISO 26262-3 Table 4); Step 4: Define Safety Goal for each ASIL ≥ A hazardous event; Step 5: Assign ASIL, safe state, FTTI, warning to each Safety Goal; HARA table columns: Hazard ID, Item Function, Malfunction, Operational Situation, Hazardous Event, Severity, Exposure, Controllability, ASIL, Safety Goal ID, Safety Goal Description, Safe State, FTTI

▸ Severity rating (S0–S3): S0 = no injuries; S1 = light/moderate injuries (AIS 1–2); S2 = severe life-threatening injuries, survival probable (AIS 3–5); S3 = life-threatening or fatal injuries (AIS 6); example EPS: unintended full-left lock at 100 km/h → loss of vehicle control → S3; unintended 2° steering at parking → minor collision risk → S1; ISO 26262 Annex B: S3 examples include loss of vehicle stability, uncontrolled acceleration >5 m/s²; S0 assigned when: item function failure has no physical harm potential; S rating does NOT consider probability of harm - only severity IF harm occurs; Severity argumentation must be documented with supporting analysis (AIS reference, Euro NCAP test data)

▸ Exposure & Controllability rating: Exposure (E0–E4): E0 = incredible (< once per year); E1 = very low (a few times per year); E2 = low (monthly); E3 = medium (weekly); E4 = high (daily or nearly every drive); example: highway driving > 120 km/h → E3 for European driver; parking → E4; exposure based on statistical driving data (German: Kraftfahrtbundesamt); Controllability (C0–C3): C0 = controllable in general; C1 = simply controllable (≥99% drivers can avoid harm); C2 = normally controllable (≥90%); C3 = difficult to control (<90%); example: gradual EPS reduction → C1 (driver can steer manually); sudden full-lock → C3; C rating determined by vehicle dynamics simulations or expert judgment; ASIL = max of S×E×C from Table 4: S3×E4×C3 = ASIL D

▸ Safety Goals & HARA output: Safety Goal attributes: ASIL (A/B/C/D); Safe State (e.g., "Motor torque = 0 within FTTI=50ms"); FTTI (Fault Tolerant Time Interval); Warning & Degradation Indication (e.g., "EPS warning lamp on within 1 s of safe state entry"); example SGs: SG1="EPS shall not apply unintended steering torque > 3 Nm", ASIL-D, Safe State=torque=0, FTTI=50ms; SG2="EPS shall not prevent manual steering", ASIL-C, Safe State=de-clutch motor, FTTI=200ms; HARA review checklist: all item functions covered × all scenarios; S/E/C ratings justified; ASIL consistent with industry reference (ISO 26262 Annex B); Safety Goals precise and testable; HARA reviewed by independent FuSa engineer before FSC development; tool: medini analyze HARA module with automatic ASIL calculation

▸ ASIL determination matrix (ISO 26262-3 Table 4): rows = S1/S2/S3; columns = E1/E2/E3/E4; cells = C1/C2/C3; ASIL D = S3+E4+C3; ASIL C = S3+E4+C2 or S3+E3+C3; ASIL B = S3+E4+C1 or S3+E3+C2 or S2+E4+C3; ASIL A = lower risk combinations; QM = quality management only; S0 or E0 → always QM regardless; ASIL D requires most rigorous: formal verification, independence level 3, MC/DC coverage; ASIL B: independence level 2, modified condition/decision coverage; QM: no formal FuSa process beyond normal quality

▸ Severity classification (S0–S3): S0 = no injuries; S1 = AIS 1–2, light/moderate (whiplash, minor bruising); S2 = AIS 3–5, severe life-threatening, survival probable (broken bones, internal bleeding); S3 = AIS 6, fatal (direct collision at high speed, fire); automotive S3 examples: unintended full braking at 130 km/h, unintended steering into oncoming traffic; S2: airbag non-deployment; S1: seatbelt pretensioner failure; S rating must cite AIS source or vehicle dynamics simulation results; S rating does NOT account for probability - only worst-case harm if event occurs

▸ Exposure classification (E0–E4): E0 = less than 1 hour per million op hours; E1 = rare (few times per year, <1% of time); E2 = occasional (1–10% of time, monthly); E3 = moderate (10–100%, weekly); E4 = high (essentially every drive); data sources: KBA German driving statistics, SHRP2 naturalistic driving study, OEM fleet telematics; examples: highway >120 km/h = E3 (~15% German driving time); parking maneuvers = E4; tire blowout = E1; automated valet parking (2024 market) = E1; exposure documented with statistical reference in HARA justification column

▸ Controllability (C0–C3) & ASIL examples: C0 = controllable by nearly all; C1 ≥ 99% can avoid harm; C2 ≥ 90%; C3 < 90%; C factors: human reaction time 150–1500 ms, vehicle physics; C3 examples: sudden 90° steering input at 100 km/h (physics prevents correction), sudden full brake application on ice; C2: partial braking failure; C1: gradual EPS torque reduction (driver compensates manually); L2+ ADAS: if system in control, driver C may be C3 even for mild faults → drives ASIL-D; EPS example: SG1 = unintended torque > 3 Nm at 130 km/h: S3+E3+C3 = ASIL-D; SG2 = prevention of manual steering: S3+E3+C2 = ASIL-C

▸ Safety Goal definition rules: Safety Goals are top-level safety requirements derived from HARA; they are at vehicle function level (not technical implementation); format: "The [item] shall not [hazardous event]"; ASIL, safe state, FTTI, and warning attribute must be assigned; example SGs: SG1 = "EPS shall not apply unintended lateral steering moment exceeding 50 Nm at vehicle speed > 10 km/h", ASIL-D, Safe State=motor de-energized, FTTI=50ms, Warning=EPS lamp ON; SG2 = "EPS shall not prevent the driver from manually overriding the steering", ASIL-C, Safe State=mechanical de-clutch, FTTI=200ms; SG3 (parking): "EPS shall not apply unintended full-lock at vehicle speed < 10 km/h", ASIL-A, Safe State=torque=0; Safety Goals are technology-independent - they do NOT reference SW or HW

▸ Safe State definition & transitions: Safe State = operating mode where risk is tolerable; types: (1) Torque = 0 (motor de-energized): for EPS main failure - driver steers manually, high effort; (2) Reduced assistance mode: partial failure - 50% torque → acceptable risk reduction; (3) Full stop (for automated driving): vehicle brakes to controlled stop; (4) Park lock engaged: prevent vehicle from moving; Safe state transition time = FTTI; FTTI components: FDTI (Fault Detection) + FRTI (Fault Reaction) = FTTI; example EPS: FTTI = 50 ms → FDTI = 30 ms (fault detection by plausibility check every 10 ms cycle × 3 = 30 ms) + FRTI = 20 ms (PWM disable, MOSFET gate drive off) = 50 ms ✓; safe state must itself be safe: torque=0 during high-speed cornering is NOT safe for all scenarios → FTTI derived per scenario

▸ Emergency operation (degraded mode) vs. safe state: ISO 26262 allows emergency operation interval before safe state; example: EPS enters 50% torque mode for max 30 s, then full shutdown; degraded mode allows gradual warning to driver; warning requirements: visual (warning lamp, instrument cluster), auditory (chime), haptic (steering vibration); timing: warning must be activated within (FTTI - driver reaction time); driver reaction time ≈ 700 ms for auditory stimulus; Functional Safety Concept (FSC) documents: which faults → which safe state; transition diagram; example FSC state machine: Normal → [fault detected] → Degraded (50% torque, warning ON) → [30s timeout or second fault] → Safe State (torque=0) → [IGN cycle] → Normal

▸ Safety Goal traceability: each SG derived from HARA row (1:1 or 1:N traceability); DOORS: SG attributes: ASIL, Safe State, FTTI, HARA_ID link, FSR links (downstream); Functional Safety Requirements (FSRs) refine SGs into allocatable requirements: example from SG1: FSR-001 = "EPS ECU shall detect torque sensor failure within 20 ms" (ASIL-D, allocated to HW+SW); FSR-002 = "EPS ECU shall de-energize motor within 10 ms of fault detection" (ASIL-D, allocated to HW); Safety Goal completeness check: every ASIL-bearing hazardous event in HARA has exactly one SG; every SG has at least one FSR; FSRs allocated to system/HW/SW elements; traceability verified by FuSa confirmation review

▸ ASIL decomposition rules (ISO 26262-9 Clause 5): decomposition splits an ASIL-X requirement into two independent channels; valid decompositions: ASIL-D → ASIL-D(D)+ASIL-D(D) or ASIL-C(D)+ASIL-A(D) or ASIL-B(D)+ASIL-B(D); ASIL-C → ASIL-C(C)+ASIL-C(C) or ASIL-B(C)+ASIL-A(C); ASIL-B → ASIL-B(B)+ASIL-B(B) or ASIL-A(B)+ASIL-A(B); notation: ASIL-B(D) = ASIL-B requirement derived from decomposed ASIL-D; critical condition: channels must be INDEPENDENT - different SW components, different HW circuits, no shared power/clock, different developers; DFA must confirm independence

▸ Decomposition in practice - EPS example: SG1 = ASIL-D "no unintended torque > 3 Nm"; decompose into: Channel 1 = "Torque Sensor Monitoring function" (ASIL-B(D) - SW monitor compares sensor1 vs sensor2); Channel 2 = "Torque Limiter HW circuit" (ASIL-B(D) - analog comparator independently limits motor current); independence argument: SW on CPU-A, HW comparator separate ASIC, different power supply rails, different developers, DFA shows no common cause; result: ASIL-B(D) for each channel instead of ASIL-D for single channel - reduces SW development cost significantly; tool: medini analyze Decomposition module; DOORS: SG1-ASIL-D → [decompose] → SR-HW-001-ASIL-B(D) + SR-SW-001-ASIL-B(D)

▸ ASIL tailoring - QM elements in safety items: elements not contributing to safety functions: ASIL QM (no safety requirements); example: EPS HMI display SW = QM (only shows EPS warning, doesn't control motor); freedom from interference (FFI): QM element must not corrupt ASIL-D element; FFI mechanisms: OS memory protection (MPU), separate partitions, time partitioning; AUTOSAR: OS MemoryProtection, ApplicationType (trusted/non-trusted); ISO 26262-6 Clause 7.4.7: if mixed-ASIL SW on same CPU - must demonstrate FFI; ASIL tailoring approval: deviation from standard ASIL requirements requires documented rationale reviewed by FuSa confirmation reviewer; over-specification prohibited: ASIL-D where ASIL-A sufficient wastes resources without safety benefit

▸ Coexistence of ASIL levels in one ECU: multi-ASIL ECU: ASIL-D torque control + ASIL-B CAN communication + ASIL-A fault logging + QM diagnostics on same MCU; hardware isolation options: Cortex-M MPU regions per ASIL level, AUTOSAR OS scalability class 3 or 4; SW architecture: ASIL-D tasks in trusted OS application with MPU protection; ASIL-B tasks in separate application; QM in non-trusted partition; runtime: ASIL-D tasks at highest RTOS priority; stack monitoring for each task; compiler: separate compilation units with MISRA compliance per ASIL level; separate code review: ASIL-D code reviewed by independent reviewer; documentation: SW Architecture Specification lists ASIL allocation per SW component, confirmed by FuSa confirmation review

▸ Lab setup - ADAS Forward Collision Warning (FCW) item: item = FCW ECU (radar front sensor + camera + FCW SW); functions: F1=detect vehicle ahead, F2=calculate TTC (Time To Collision), F3=issue driver warning at TTC < 2.5s; I/O: radar (CAN, 50ms cycle, range 0–200m), camera (Ethernet GMSL2, 30fps), speaker (PWM), brake HMI lamp (GPIO); operational scenarios: S1=motorway at 130 km/h (E3), S2=city stop-and-go 30 km/h (E4), S3=pedestrian crossing (E3), S4=tunnel entry (E2, radar/camera degraded), S5=rain/fog (E3, sensor noise); item context: FCW triggers visual/audio warning only (no brake actuation); driver always in control

▸ HARA table completion - FCW hazard identification: function F3 malfunctions: (M1) False positive warning: warning issued when no hazard → driver brakes unnecessarily → potential rear-end collision; (M2) Missing warning: no warning issued when collision imminent → driver not alerted → collision; (M3) Late warning: TTC < 1.5s when warning issued → insufficient reaction time; scenario S1+M2: motorway 130 km/h, no warning when TTC = 2s → collision at high speed; Severity: S3 (fatal); Exposure: E3 (motorway driving ~15%); Controllability: C3 (driver already focused forward but missed hazard - no additional braking initiated); ASIL = S3+E3+C3 = ASIL-C for SG1="FCW shall issue warning within 1 s when TTC ≤ 2.5 s at speeds > 60 km/h"; S1+M1: false positive at E4+S2+C2 = ASIL-B for SG2="FCW shall not issue false warnings more than 0.01/hour"

▸ Safety Goals & FSC for FCW: SG1: "FCW shall not fail to warn driver when TTC ≤ 2.5s at v ≥ 60 km/h", ASIL-C, Safe State=continuous warning + reduce FCW availability, FTTI=3s; SG2: "FCW shall not generate nuisance warnings > 1 per 100 hours", ASIL-B; FSR derivation from SG1: FSR-001="FCW shall compute TTC within 100ms from radar input" (ASIL-C, SW); FSR-002="FCW shall sound alarm within 500ms of TTC threshold crossing" (ASIL-C, HW+SW); FSR-003="FCW shall detect radar failure within 500ms" (ASIL-C, SW diagnostics); ASIL-C decomposition: FCW main channel ASIL-B(C) + redundant TTC check ASIL-A(C); independence: main path on CPU-A core, redundant check on CPU-B core (lock-step or independent)

▸ HARA validation checklist: ✓ all 5 scenarios × all 3 functions = 15 combinations analysed; ✓ S/E/C ratings justified with references (KBA stats for E, Euro NCAP for S); ✓ no S3+E4+C3 combination left at QM (would require ASIL-D); ✓ Safety Goals are technology-free and testable at vehicle level; ✓ FTTI values validated by vehicle dynamics team; ✓ HARA reviewed by independent FuSa engineer; common pitfalls: (1) rating C1 for C3 scenario to lower ASIL → non-compliant; (2) omitting rare but high-S scenarios (tunnel, rain); (3) safety goal referencing internal function (wrong level); expected output: HARA report v1.0 with 15+ rows, 2 Safety Goals at ASIL-C and ASIL-B, reviewed and baselined in DOORS

▸ FMEA types in ISO 26262: FMEA (SW): ISO 26262-6 Annex B - systematic identification of SW failure modes and their effects; FMEA (HW): ISO 26262-5 Clause 8 - HW component failure modes; FMEDA (Failure Modes Effects and Diagnostic Analysis): extends FMEA with diagnostic coverage - used to calculate SPFM, LFM, PMHF; FMEA structure: Item (component), Function, Failure Mode, Effect (local, next higher, end effect), Cause, Detection mechanism, Diagnostic Coverage, Severity, Failure Rate (FIT = Failures In Time = failures per 10⁹ hours), ASIL; tool: medini analyze, IQ-FMEA, PTC Windchill FMEA module, Excel (VDA FMEA template)

▸ HW FMEA - EPS ECU example: Component: Torque Sensor Signal Conditioning IC; Function: Convert raw SPI data to torque value; Failure Mode 1: Output stuck at 0 Nm; Local Effect: ECU receives 0 torque request; End Effect: No EPS assistance → high steering effort → driver discomfort; Detection: Plausibility check vs. sensor 2 (DC ≈ 99%); Failure Rate: 50 FIT (from component datasheet or SN 29500 estimate); Failure Mode 2: Output stuck at maximum value (10 Nm); End Effect: Unintended full steering assistance → vehicle veers → ASIL-D hazardous event; Detection: Current limiter HW circuit (DC ≈ 90%); FMEDA results: safe faults, single point faults (SPF), residual faults, latent faults - classified per ISO 26262-5 Clause 8.4

▸ SW FMEA structure: SW unit: TorqueCalculation_Module.c; function: compute_steering_assistance(torque_sensor_value, vehicle_speed); failure modes: (FM1) wrong torque calculation due to integer overflow (effect: saturate at max assist, ASIL-D); (FM2) stale data used (timer not reset, effect: wrong torque at speed transition, ASIL-B); (FM3) division by zero if vehicle_speed=0 (effect: undefined behavior, ASIL-D); detection: FM1 - range check after calculation (detect); FM2 - timestamp freshness check (detect); FM3 - pre-condition check (prevent); SW FMEA feeds SW safety requirements: SR-SW-101 = "TorqueCalculation shall perform range check (0–10 Nm) after computation", ASIL-D; traceability: SW FMEA row → SW Safety Requirement → Unit Test Case

▸ FMEA review & common mistakes: VDA FMEA 2019 methodology: Structure tree → Function net → Failure net → Risk analysis → Optimization; RPN (Risk Priority Number) = Severity × Occurrence × Detection: DEPRECATED in ISO 26262 (not used for ASIL determination) but still used for optimization prioritization; ISO 26262 uses S/E/C from HARA, not RPN; FMEA common mistakes: (1) confusing failure mode with cause (failure mode = "output stuck high", cause = "MOSFET gate driver short circuit"); (2) assuming 100% DC for all faults without justification; (3) missing latent fault column (latent = fault not detected during normal operation, only manifests when second fault occurs); DC justification: safety mechanism test coverage verified by test case; acceptance criteria: all single-point faults of ASIL-D item covered by ≥97% diagnostic coverage (SPFM ≥ 97%)

▸ FTA fundamentals: top-down deductive analysis; starts with Undesired Top Event (UTE = hazardous event from Safety Goal); decomposes into causes using Boolean logic gates; gates: AND (all sub-events required), OR (any sub-event sufficient), NOT (negation); basic events: component failures with FIT rates; Minimal Cut Sets (MCS): smallest set of basic events sufficient to cause UTE; single-point failures = MCS of size 1 → must be eliminated for ASIL-D; double-point failures = MCS of size 2 → acceptable for ASIL-D if probability sufficiently low; tool: medini analyze FTA module, Isograph FaultTree+, OpenFTA; FTA complements FMEA: FMEA = bottom-up (component → effect), FTA = top-down (hazard → cause)

▸ FTA construction - EPS example: Top Event (TE): "Unintended EPS torque > 3 Nm"; Level 1 AND gate: "TE" = "Motor receives excessive current" AND "Motor current limiter fails"; Level 1 OR gate: "Motor receives excessive current" = ("PWM signal stuck high" OR "Gate driver output stuck on" OR "SW torque command saturated"); basic events: "PWM stuck high" FIT = 15 FIT (from HW datasheet); "Gate driver short" FIT = 10 FIT; "SW command > range" FIT = 1 FIT (from SW FMEA); MCS analysis: {PWM stuck high, Current limiter fail} = double MCS → FIT = 15 × 5 = 75 FIT per 10⁹ h; for ASIL-D PMHF requirement ≤ 10 FIT → need additional safety mechanism; solution: add HW comparator as additional cut in AND gate

▸ Quantitative FTA for PMHF calculation: PMHF (Probabilistic Metric for random Hardware Failures): ISO 26262-5 Clause 9.4; ASIL-D: PMHF < 10⁻⁸ per hour = 10 FIT; ASIL-C: < 10⁻⁷ = 100 FIT; ASIL-B: < 10⁻⁶ = 1000 FIT; calculation: P(TE) = sum of P(all MCS); P(MCS1) = λ₁ × DC₁ × (exposure time); single point fault contribution: λ_SPF × (1 - DC_SPF); double point fault contribution: λ₁ × λ₂ × latent_exposure_time; β-factor for common cause failures: typically β = 0.02–0.1 for automotive; example: if SPF = 20 FIT at 90% DC → residual = 2 FIT; if DP = 50 FIT at 60% DC → latent = 20 FIT × 1000h latent = 20 × 1000 / 10⁹ = 2×10⁻⁵; PMHF tools compute this automatically

▸ FTA quality criteria & tooling: completeness: all failure modes from FMEA referenced in FTA; all basic events have FIT rates from datasheets or SN 29500/IEC TR 62380; Boolean reduction verified; coverage: all Safety Goals have corresponding FTA; MCS of size 1 confirmed not present for ASIL-D; review checklist: ✓ Top Event matches Safety Goal exactly; ✓ Gate types correctly assigned (AND vs OR); ✓ FIT rates sourced and cited; ✓ β-factor applied for common cause; ✓ PMHF meets ASIL requirement; common errors: using OR where AND intended (over-estimates risk), not applying DC reduction (under-estimates residual risk), missing beta-factor for redundant identical components; medini analyze: automatic PMHF computation from FMEDA; output: FTA report with fault tree diagram, MCS list, PMHF computation table

▸ DFA purpose & ISO 26262 requirement: DFA = systematic analysis to identify if independent redundant elements can fail together due to a common cause or cascading failure; required for ASIL-C and ASIL-D per ISO 26262-9 Clause 7; two types: (1) Common Cause Failure (CCF): single external event causes multiple elements to fail simultaneously (e.g., power surge destroying both redundant MCUs); (2) Cascading Failure (CF): failure in element A causes failure in element B; DFA scope: applies to all elements claimed independent in ASIL decomposition; DFA analyst must be independent of element designers; DFA triggers β-factor in PMHF quantification: β = 0.02 (good independence), 0.05 (moderate), 0.1 (poor)

▸ DFA analysis method - independence arguments: for ASIL-B(D)+ASIL-B(D) decomposition to be valid: DFA must confirm independence of both channels; independence checklist: ✓ Different SW modules (no shared code, separate compilation units); ✓ Different hardware blocks (no shared transistors, no shared PCB power planes); ✓ Different power supply rails (separate LDOs, separate fuses); ✓ Different clock sources (no shared crystal oscillator); ✓ Different developers (teams physically separated, no code sharing); ✓ Different tools/compilers (if possible); ✓ Different reset circuits; spatial separation (separate connectors, separate PCB areas); FMEA β-factor for shared power: if both channels on same 5V rail → β = 0.05 (5% of CCF rate applied as common cause)

▸ DFA table structure: columns: Element A (e.g., Torque Monitor SW), Element B (e.g., Torque Limiter HW), Potential Common Cause or Cascade, Independence Measure, Residual Risk; example rows: Row 1 - A=SW Monitor, B=HW Limiter, CCF=same 5V supply failure, Measure=separate power domains with independent LDO for HW limiter, Residual=negligible; Row 2 - A=MCU core1, B=MCU core2, CCF=same die (lockstep only partially independent), Measure=lockstep cross-checking, Residual=MCU-level CCF β = 0.02; Row 3 - A=SPI Sensor1, B=SPI Sensor2, CCF=same EMC event disrupts both SPI buses, Measure=separate PCB routing, ferrite beads, Residual=low; DFA table reviewed by FuSa confirmation reviewer

▸ DFA for HW safety mechanisms: hardware redundancy DFA: dual torque sensors (sensor1 + sensor2) - are they truly independent? CCF sources: shared PCB trace (moisture bridges both); shared ADC reference voltage; same temperature coefficient causing simultaneous drift; DFA measures: sensors on separate I2C buses, separate ADC channels, separate PCB area; EMC: both sensors same antenna sensitivity? → separate EMC shield; process variation: same die manufacturing batch → β-factor 0.01; DFA for SW: code review independence - if developer A writes both channels using same algorithm → β = 0.1 (not independent); mitigation: use different algorithms (e.g., channel 1 uses summation, channel 2 uses range check); N-version programming; DFA output: DFA report signed by FuSa engineer, confirming each independence claim or documenting residual CCF probability for PMHF calculation

▸ FFI definition & ISO 26262 requirement: Freedom from Interference (FFI) ensures that elements of different ASIL levels or QM elements running on shared hardware/SW cannot corrupt higher-ASIL elements; required per ISO 26262-6 Clause 7.4.7 for mixed-ASIL SW; ISO 26262-9 Clause 6.4 for system level; interference types: (1) memory corruption (QM writes to ASIL-D data area); (2) timing interference (QM task starves ASIL-D task); (3) communication interference (QM message corrupts ASIL-D CAN buffer); (4) power domain interference (QM-driven load collapses supply for ASIL-D circuit); FFI must be demonstrated by analysis or test, not just assumed

▸ SW FFI mechanisms - memory protection: ARM Cortex-M MPU (Memory Protection Unit): 8 or 16 regions, each with: base address, size (min 32 B), permissions (RO/RW/NX per privileged/unprivileged); AUTOSAR OS MemoryProtection: trusted/non-trusted OS applications; ASIL-D app in privileged mode with MPU protection; QM app in non-trusted mode - MPU exception on illegal access; stack monitoring: stack canary pattern (0xDEADBEEF) + MPU guard region at stack boundary; memory layout: ASIL-D RAM region 0x20000000–0x20004000 (MPU Region 0, privileged RW only); QM RAM 0x20004000–0x20008000 (MPU Region 1, unprivileged RW, no access to Region 0); runtime: AUTOSAR OS task switch → MPU reconfigured per application

▸ SW FFI mechanisms - time partitioning: AUTOSAR OS Scalability Class 3/4: time-triggered scheduling; budget monitoring: each task has execution time budget; OS monitors via WCET (Worst Case Execution Time) analysis; violation → OS hook OsHook_ProtectionHook() → terminate task or application; rate monotonic scheduling: ASIL-D tasks at highest priority, shortest period (e.g., 1 ms); QM tasks lowest priority (100 ms); time budget: TorqueControl_Task 1ms budget = 0.8ms; if exceeded → OsHook; TIMING-PROTECTION-ENABLED = TRUE in AUTOSAR OS config; communication interference: AUTOSAR COM IOC (Inter-OS-Application Communication): type-safe, access-controlled; QM app cannot directly write to ASIL-D signal buffer; IOC provides copy-semantics

▸ HW FFI mechanisms & FFI analysis: HW FFI: separate voltage regulators for ASIL-D and QM circuits; VR1 → MCU core (ASIL-D), VR2 → peripheral ICs (QM); power monitoring IC on ASIL-D supply; EMC isolation: separate PCB areas, ground planes; FFI analysis documentation: identify all shared resources (MCU, CAN bus, power, clock); for each: analyze interference path; assign mitigation; determine residual risk; example: shared CAN transceiver (QM) and ASIL-D SW uses same CAN controller → FFI mitigation: AUTOSAR COM gateway layer validates all incoming CAN messages before routing to ASIL-D module; HW FFI confirmation: lockstep MCU (e.g., TC397: dual-core lockstep, CPU0 = master, CPU1 = checker) provides ECC protection on all caches and buses; FFI report: work product reviewed by independent FuSa engineer

▸ Workshop setup - EPS Motor Driver subsystem: item = H-bridge gate driver IC (DRV8432 or similar) + bootstrap capacitors + current sense resistor; FMEA scope: HW component failure modes affecting torque output; tools: Excel with VDA FMEA 2019 template + medini analyze import; failure rate data: Infineon datasheet FIT rates, IEC TR 62380 PCB environment, SN 29500 passive components; columns in FMEA table: Component, Function, Failure Mode, Local Effect, End Effect, Severity, Cause, Detection Mechanism, DC %, Failure Rate (FIT), ASIL contribution

▸ FMEA exercise - gate driver failure modes: FM1: high-side MOSFET gate stuck HIGH → motor phase always on → unintended high torque → End Effect: SG1 violation (ASIL-D); Cause: gate oxide breakdown; Detection: overcurrent sense + software current monitoring (DC ≈ 90%); FIT = 8 FIT (from datasheet); FM2: gate driver output oscillating (EMC event) → motor torque jitter → End Effect: driver discomfort (ASIL-B); Detection: current ripple monitor (DC ≈ 60%); FM3: current sense resistor open → ECU misreads zero current → undetected runaway torque → End Effect: ASIL-D; Detection: cross-check with torque sensor output (DC ≈ 97%); FMEDA result for FM3: residual FIT = 8 × (1-0.97) = 0.24 FIT (safe fault contribution)

▸ FTA exercise - top event analysis: Top Event: "Unintended EPS torque > 3 Nm persists > 50ms"; OR gate Level 1: (A) "Motor driver outputs unintended current" OR (B) "Torque control SW sends wrong command"; AND gate under A: (A1) "Gate driver stuck high" AND (A2) "Overcurrent protection fails"; basic events: A1 FIT = 8, DC(A2_detects_A1) = 90% → residual A1 = 0.8 FIT; A2 FIT = 5 FIT; MCS {A1,A2} combined = 8 × 5 × (1/10⁹) per hour × latent window (if A2 latent: 1000h) = very small; FTA tool: input basic event FIT + DC → automatic MCS + PMHF; verify: PMHF contribution from gate driver < 2 FIT (vs. ASIL-D budget 10 FIT total)

▸ Validation checklist & common errors: FMEA checklist: ✓ all failure modes identified (stuck-at-high, stuck-at-low, short-to-supply, open circuit, intermittent); ✓ FIT rates from approved source (datasheet, IEC TR 62380, SN 29500); ✓ DC values justified by test evidence; ✓ ASIL consistency with HARA; ✓ latent fault column completed; FTA checklist: ✓ Top Event matches Safety Goal; ✓ all basic events covered in FMEA; ✓ MCS size 1 absent for ASIL-D; ✓ PMHF < 10 FIT (ASIL-D); common errors: (1) DC = 100% claimed without justification → reject; (2) missing failure mode "stuck-at-wrong-value" for sensors; (3) FIT rates from wrong environment (automotive vs. ground fixed → factor 10 difference); (4) FTA top event too vague ("EPS fails" instead of specific hazardous event); expected output: FMEA table 20+ rows, FTA with 3 levels, PMHF calculation, medini analyze report

▸ SPFM (Single Point Fault Metric): ISO 26262-5 Clause 9.4.2; measures coverage of single-point faults by safety mechanisms; SPFM = 1 - (Σ λ_SPF_residual) / (Σ λ_SPF_total); ASIL-D target: SPFM ≥ 99%; ASIL-C: ≥ 97%; ASIL-B: ≥ 90%; ASIL-A: ≥ 60%; single-point fault = fault of a single element that leads directly to violation of safety goal without requiring another fault; residual fault = portion of SPF not covered by safety mechanism; DC = Diagnostic Coverage = fraction of failures detected; residual = λ × (1 - DC); example: torque sensor FIT = 50, DC = 97% → residual = 1.5 FIT; SPFM = 1 - (1.5 FIT) / (50 FIT) = 97% - meets ASIL-C but not ASIL-D

▸ LFM (Latent Fault Metric): ISO 26262-5 Clause 9.4.3; measures coverage of latent faults by safety mechanisms; latent fault = fault that is not immediately detected and not perceived by driver during normal operation; ASIL-D: LFM ≥ 90%; ASIL-C: ≥ 80%; ASIL-B: ≥ 60%; LFM = 1 - (Σ λ_LF_residual) / (Σ λ_LF_total); latent faults discovered by: periodic self-test (e.g., startup BIST), slow background diagnosis (check redundant sensor every 10ms), OBD diagnostic test case; latent exposure window: max time between detection opportunities; ASIL-D latent fault window: ≤ operating hours between repairs (e.g., 1000h for passenger car between services); if latent test interval = 10ms → effectively detected; if no test → latent window = vehicle lifetime

▸ PMHF (Probabilistic Metric for random Hardware Failures): overall metric combining SPF, RF, and DP contributions; PMHF = Σ(all fault categories) over lifetime exposure; ASIL-D: PMHF < 10⁻⁸ /h = 10 FIT; ASIL-C: < 10⁻⁷ /h = 100 FIT; ASIL-B: < 10⁻⁶ /h = 1000 FIT; PMHF components: (1) SPF residual: λ_SPF × (1-DC_SPF); (2) Residual faults (RF): faults that cannot be detected; (3) Dual-point faults: λ_DP = λ₁ × λ₂ × T_latent; T_latent = latent exposure time (hours); (4) Perceived faults (driver notices, no accident): not included; PMHF budget allocation: if item has 10 components each contributing to ASIL-D goal: allocate ≤ 1 FIT per component; total = 10 FIT ≤ limit

▸ Evaluation approach & common challenges: evaluation methods (ISO 26262-5 Clause 9.4.1): Method 1a = hardware architectural metrics (SPFM + LFM, quantitative); Method 1b = probabilistic metric (PMHF); both required for ASIL-D; either sufficient for ASIL-A/B; challenge 1: FIT rate sources - use IEC TR 62380 (automotive profile) not MIL-HDBK-217 (military → 10x different); challenge 2: DC justification - DC value must be supported by test evidence (unit test, fault injection); DC = 60% (low), 90% (medium), 99% (high) per ISO 26262-5 Table D.4; challenge 3: latent window definition - requires maintenance schedule input from OEM; challenge 4: mixed-ASIL items - calculate metrics separately per ASIL level; tool: medini analyze FMEDA module computes SPFM/LFM/PMHF automatically from component failure rate database; output: HW Evaluation Report signed by HW Safety Engineer and reviewed by FuSa

▸ Memory safety mechanisms: ECC (Error Correcting Code) on RAM/Flash: SECDED (Single Error Correct Double Error Detect) - detects all 2-bit errors, corrects all 1-bit; implemented in S32K, TC3xx, RH850; ECC error counters: correctable (CEs) logged, uncorrectable (UEs) → trap/exception; CRC on NvM: CRC-16 or CRC-32 on every NvM block (AUTOSAR NvM uses CRC); RAM mirror: critical variables stored at two addresses, compared before use; Flash integrity: background CRC running in idle; example: AUTOSAR OS hook for ECC UE: OsHook_Exc_MemFault → enter safe state; S32K344: ECC on TCM (0.1% performance overhead); Renesas RH850 P1x-C: ECC on both code and data flash

▸ Watchdog timers & CPU monitoring: independent hardware watchdog (external WD, e.g., TPS3823): ECU must send heartbeat pulse within 1.6s window; missing pulse → WD asserts RESET pin; question-answer watchdog (Q&A): ECU sends answer = f(question, seed); WD evaluates correctness; prevents SW emulating simple toggle; deadline monitoring: OS Task Deadline Monitor - task must complete within period; alive counter: safety module increments counter each cycle, safety supervisor checks for change; program flow monitoring: checkpoints at critical code sections; FC_A() → FC_B() → FC_C() expected sequence; AUTOSAR WDG: WdgM_SetMode(), WdgM_CheckpointReached(), WdgM_PerformReset(); SPI watchdog (e.g., MC33988): AUTOSAR WdgIf layer abstraction

▸ Voltage, temperature & clock monitoring: voltage monitoring: SBC (System Basis Chip, e.g., UJA1168): monitors VBAT (6–18V), VCC 5V (4.75–5.25V), VCORE 3.3V; undervoltage → reset; overvoltage → LIMP mode; ADC self-test: Vref high/low stimuli test channels; temperature monitoring: die temperature sensor (on-chip) + NTC thermistor (external); temperature DEM event: if T > 150°C → enter thermal protection mode; clock monitoring: external crystal oscillator fail detection (CMU - Clock Monitoring Unit, e.g., S32K3 CMU); CMU compares MCU clock against reference; clock deviation > 5% → CMU interrupt → safe state; AUTOSAR MCU: McuInternal_OscMonitor(), Clock_GetStatus(); cross-check of oscillator against internal RC oscillator

▸ Redundancy & output monitoring: redundant sensors: dual torque sensors (2 × SPI), compared each cycle; deviation > 0.5 Nm → fault; redundant communication: CAN1 + CAN2 for safety-relevant signals; voting: 2-of-2 (AND) for sensor agreement, 2-of-3 (majority vote) for 3-sensor systems; output monitoring: motor current feedback compared against requested torque command; discrepancy > 10% for > 5 ms → fault reaction; hardware disable path: independent of SW - MOSFET gate driver EN pin connected to external WD output (SW can't override); actuation monitoring: if SW commands 5 Nm but motor sensor shows 0 → actuator fault; feedback comparison in AUTOSAR FiM (Function Inhibition Manager): FiM_GetFunctionPermission(FID_TorqueControl) returns FALSE if DEM event active → torque = 0 immediately

▸ DC definition & ISO 26262-5 Table D.4: Diagnostic Coverage = fraction of failure rate covered by safety mechanism; DC = Σ(λ_detected) / Σ(λ_total); DC levels: Low = 60%, Medium = 90%, High = 99%; ISO 26262-5 Annex D provides reference DC values for common mechanisms: ECC on RAM = 99% (high); functional redundancy plausibility check = 90% (medium); range check only = 60% (low); DC must be justified by test - fault injection test or analytical argument; DC claim without evidence rejected by FuSa reviewer; DC applies per failure mode: a torque sensor may have DC=90% for "stuck at 0" but DC=60% for "intermittent glitch" - combine properly

▸ DC estimation methods: (1) Fault injection testing: inject fault (short pin to GND/VCC, inject bit flip via test tool) → verify safety mechanism responds within FDTI; failure to detect = failure of SM; DC = detected_faults / total_injected_faults; (2) Analytical: use ISO 26262-5 Annex D reference table + engineering judgment; (3) Simulation: SPICE fault simulation for analog circuits; scope: DC estimated for each failure mode × each safety mechanism; not all failure modes detectable: "drift over lifetime" → DC = 0 (no online SM) → classified as safe fault if effect below harm threshold; example: CAN transceiver stuck-dominant → detected by Bus-Off handler in ≤ 128 bit error periods → DC ≈ 97%

▸ FMEDA DC worksheet: columns: Component, FM_ID, Failure Mode, FM Rate (FIT), Safety Mechanism, DC%, Safe FIT, Residual FIT, Latent FIT, Fault Category (SPF/RF/DP/SF); safe fault = failure mode that does not violate safety goal even undetected; total SPF residual = Σ(FIT_SPF × (1-DC)); FMEDA tool: medini analyze, Excel with FMEDA template; example row: IC_PowerReg | FM01 | Output overvoltage | 5 FIT | Overvoltage comparator hardwired (HW) | 97% | - | 0.15 FIT SPF residual | - | RF; example row: Resistor_R5 | FM03 | Open circuit | 2 FIT | No SM (safe fault - opens motor disable path, torque = 0) | - | 2 FIT | - | - | SF; FMEDA review: all FM categories assigned, DC justified, no FM with DC=0 classified as SPF for ASIL-D

▸ Latent fault DC & multi-point fault handling: latent fault DC: SM must detect the fault before the latent window expires; periodic self-test (e.g., microcontroller BIST on startup or every 100 ms background): detects latent CPU register faults; DC_latent = fraction of latent faults detected within latent window; for ASIL-D LFM ≥ 90%: if 10 latent FIT total, need ≤ 1 FIT undetected; dual-point fault (DP): two independent latent faults combining to cause hazard; DP contribution to PMHF: λ_DP1 × λ_DP2 × T_latent; reduce T_latent by increasing SM test frequency; AUTOSAR BIST: inverted RAM test every 1ms using MBIST; MISRA-required test coverage ensures DC estimates valid; output: FMEDA Excel/medini report reviewed by HW Safety Engineer and FuSa confirmation reviewer

▸ Architectural metric calculation formulas (ISO 26262-5 Clause 9.4): SPFM = 1 - [Σλ_SPF_residual + Σλ_RF] / [Σλ_total_SP + Σλ_total_RF]; LFM = 1 - [Σλ_LF_residual] / [Σλ_total_LF]; PMHF = Σλ_SPF_residual + Σλ_RF + Σ(λ_DP1×λ_DP2×T_latent); fault classification: Safe Fault (SF): no violation even undetected; Single Point Fault (SPF): direct violation, no redundancy; Residual Fault (RF): SPF not covered by SM; Dual Point Fault (DP): requires two independent faults; Latent Fault (LF): not detected by SM in latent window; ASIL-D targets: SPFM ≥ 99%, LFM ≥ 90%, PMHF < 10 FIT

▸ Worked example - EPS ECU HW metrics: components contributing to ASIL-D SG1 (torque > 3 Nm): (1) Torque sensor IC: λ=50FIT, SM=plausibility check DC=97%, SPF_residual=1.5 FIT, RF=0; (2) Motor driver IC: λ=30FIT, SM=current monitor DC=90%, SPF_residual=3 FIT, RF=0; (3) MCU: λ=20FIT, SM=lockstep DC=99%, SPF_residual=0.2 FIT, RF=0; (4) Voltage regulator: λ=8FIT, SM=undervoltage reset DC=95%, SPF_residual=0.4 FIT, RF=0; SPFM = 1 - (1.5+3+0.2+0.4) / (50+30+20+8) = 1 - 5.1/108 = 95.3% → FAILS ASIL-D (need ≥99%); action: improve motor driver SM from 90% to 99% → SPF_residual = 0.3 FIT → SPFM = 1 - 2.4/108 = 97.8% → still fails; need dual-channel for motor driver

▸ Latent fault & PMHF calculation: latent fault contributors (MCU core register fault undetected until crash): λ_LF = 5 FIT per MCU; SM = BIST test every 1000h (latent window); DC_latent = 60% (covers stuck-at register, not timing faults); LF_residual = 5 × 0.4 = 2 FIT; LFM = 1 - 2/(Σ λ_LF_total) = varies per full FMEDA; DP fault example: Fault A = current sensor drift (λ_A=10FIT, latent for T_latent=500h) × Fault B = SW current monitor bug (λ_B=2FIT, latent T=500h); DP_PMHF = 10 × 2 × 500 / 10⁹ = 10×10⁻⁶ (too high!) → action: reduce T_latent to 10h via more frequent SM test → DP_PMHF = 2×10⁻⁷ (acceptable); PMHF total: SPF_residual + RF + DP contributions = must be < 10 FIT

▸ Metrics review process & tool use: medini analyze FMEDA tab: import component list, assign DC, compute SPFM/LFM/PMHF automatically; iteration: if metrics fail target → identify top contributors → improve DC or add redundancy → recalculate; sensitivity analysis: vary DC of top-3 components → identify which SM improvements most effective; review checklist: ✓ all components in scope listed; ✓ FIT rates from approved source; ✓ DC justified (Annex D or test); ✓ latent window defined and agreed with OEM; ✓ metrics meet ASIL targets; ✓ FMEDA reviewed by independent HW Safety Engineer; traceability: FMEDA → HW Safety Requirements (each SM → HW safety requirement in DOORS); HW evaluation report approved by FSM before system design freeze

▸ Lab setup: target item = simplified ABS (Anti-lock Braking System) ECU with: wheel speed sensor (Hall effect, 30 FIT), brake pressure sensor (piezo, 20 FIT), solenoid valve driver IC (25 FIT), MCU S32K144 (15 FIT), SBC power supervisor (8 FIT); ASIL-D safety goal SG1 = "ABS shall not prevent brake pressure build-up during emergency braking"; lab exercise: build FMEDA in medini analyze (or Excel template); identify all failure modes per component using FMEA; assign DC based on ISO 26262-5 Annex D; classify faults (SF/SPF/RF/DP/LF); calculate SPFM, LFM, PMHF; target: SPFM ≥ 99%, LFM ≥ 90%, PMHF < 10 FIT

▸ FMEDA exercise step-by-step: Component 1 - Wheel Speed Sensor (30 FIT): FM1="output stuck low" (wheel speed appears 0 → ABS activates unnecessarily → nuisance braking, ASIL-B not ASIL-D); FM2="output stuck high" (wheel speed always high → ABS never activates → SG1 violation, SPF); SM for FM2: cross-check vs. other 3 wheel sensors; DC=90%; SPF_residual=3 FIT; classify FM2 as SPF with 3 FIT residual; Component 2 - Solenoid Valve Driver (25 FIT): FM1="output stuck closed" (valve blocks pressure → SG1 violation, SPF); SM: valve position feedback + current monitoring; DC=95%; residual=1.25 FIT; FM2="output stuck open" (ABS releases pressure → reduced braking, ASIL-C); SM: position feedback; DC=90%; SPFM contribution = 3+1.25+... add all; compute total

▸ Iteration exercise - failing metrics: after first calculation: SPFM = 96.5% (fails ASIL-D ≥ 99%); top contributor: wheel speed sensor FM2 (3 FIT residual); solution A: improve SM DC from 90% to 99% (add comparison with reference model); new SPF_residual = 0.3 FIT; recalculate SPFM = 98.8% (still fails!); solution B: add redundant wheel speed sensor (second sensor, independent supply); decompose SG1 into two independent channels ASIL-B(D)+ASIL-B(D); each channel now at ASIL-B target (≥90%); SPFM per channel: 90.1% (passes ASIL-B); LFM calculation: identify latent faults (MCU register: 5 FIT, latent window 1000h); add BIST every 100ms → DC_latent=90%; LFM = 1 - 0.5/5 = 90% (barely passes); PMHF: after improvements = 8.7 FIT (passes ASIL-D < 10 FIT)

▸ Validation checklist & expected output: ✓ FMEDA has ≥ 25 rows covering all 5 components; ✓ each FM has FIT rate from approved source (IEC TR 62380 Table 2 for capacitors, IEC TR 62380 Table 7 for ICs); ✓ DC values cite ISO 26262-5 Annex D reference; ✓ all SPFs identified and classified; ✓ latent window defined (T_latent = 1000 h agreed with OEM); ✓ SPFM ≥ 99%, LFM ≥ 90%, PMHF < 10 FIT; ✓ iteration documented showing improvement from initial metrics; expected output: FMEDA spreadsheet/medini report with metrics dashboard (green/red status per metric); HW Evaluation Report v1.0 (SPFM: 99.1%, LFM: 90.5%, PMHF: 8.7 FIT) - signed by HW Safety Engineer, reviewed by external FuSa reviewer

▸ SW safety requirements derivation: SW safety requirements (SwSR) derived from: (1) Technical Safety Requirements (TSR) from TSC; (2) HW-SW interface specification (timing constraints, signal ranges); (3) SW architectural design decisions; derivation example: TSR-001 = "EPS ECU shall detect torque sensor plausibility fault within 20 ms" → SwSR-001 = "TorqueMonitor_Task shall compare TorqueSensor1 and TorqueSensor2 every 10 ms; if |S1-S2| > 0.5 Nm for 2 consecutive cycles → set DEM event FBL_E_TORQUE_SENSOR_PLAUSIBILITY"; ASIL allocation: SwSR-001 ASIL-D; SwSR attributes: ID, Text, ASIL, Verification method (test/review/analysis), SW component allocation, Status; tool: IBM DOORS NG with SW Safety module

▸ SW safety requirement types: functional requirements: define SW behavior for safety function (e.g., "torque limiter shall clamp output to ≤ 8 Nm"); non-functional requirements: timing (worst-case execution time ≤ 0.8 ms for 1ms task), memory (stack usage ≤ 512 bytes per task), data integrity (CRC-32 on all NvM safety data blocks); safe state requirements: "SW shall set motor PWM duty cycle to 0% within 10 ms of detecting DEM event ASIL-D_CRITICAL"; diagnostic requirements: "TorqueMonitor shall report DTC 0xC0100 (ASIL-D) on 3 consecutive plausibility failures"; ASIL D SW requirements: every SwSR-ASIL-D must be verifiable by test case with MC/DC coverage; traceability: SwSR ← TSR ← FSR ← SG (bottom-up): DOORS bidirectional link

▸ HW-SW interface (HSI) specification: ISO 26262-4 Clause 7.3 & Part 6 Clause 7.2.2.5; HSI defines: all HW registers accessible by SW (base addresses, bit fields, reset values, timing); safety-relevant HSIs: ADC register for torque sensor (ADCR0 = 0x40004000, 12-bit result, LSB = 1.22 mV, valid range 0.5V–4.5V = 409–3686 counts); fault register bits (FSTAT, error flags); watchdog service register (WDTS, must write 0x5A then 0xA5 within 20 ms window); PWM duty cycle register (FTM0_C0V); timing: ADC conversion complete interrupt latency ≤ 2 μs; HSI reviewed and signed by both HW and SW engineers; HSI violations (SW writing outside valid range) → MISRA rule violation + unit test boundary value check

▸ SW safety requirements quality criteria: completeness: all ASIL-bearing TSRs have corresponding SwSRs; all SwSRs have ASIL attribute; consistency: no conflicting timing requirements between SW components; non-ambiguity: "detect failure" → replace with "detect fault within FDTI of 20 ms by comparing S1 vs S2"; testability: each SwSR has at least one test case in SW test specification; traceability: complete upward (SwSR → TSR → FSR → SG) and downward (SwSR → SW Architecture element → Code unit → Test case); ASIL decomposition in SW: if TSR-001 decomposed to SwSR-ASIL-B(D)+SwSR-ASIL-B(D) → FFI analysis required for both SW components; review: SwSR reviewed by SW Safety Engineer + confirmation review by independent FuSa engineer; baseline in DOORS before SW architecture design starts

▸ AUTOSAR safety architecture patterns: SWC (Software Component) partitioning by ASIL: ASIL-D SWCs in trusted OS Application (runnable with MemProt); ASIL-B in separate non-trusted partition; QM in third partition; CommunicationGroup isolation: AUTOSAR IOC for inter-partition signal passing; OS Scalability Class 3/4: MemoryProtection + TimingProtection; AUTOSAR FiM (Function Inhibition Manager): safety monitor sets inhibit conditions - FiM_GetFunctionPermission(FID) returns FALSE when fault active → calling SWC skips safety function and enters safe state; AUTOSAR Dem: stores DTC, provides API Dem_SetEventStatus() for SW to report faults; AUTOSAR WdgM: watchdog manager with supervised entities and checkpoints; Rte_Call / Rte_Write: typed communication preventing direct cross-partition memory writes

▸ Defensive programming patterns for ASIL-D: invariant assertion: SAFETY_ASSERT(torque_cmd >= 0 && torque_cmd <= MAX_TORQUE, SAFE_STATE_ENTRY); range check on every input: if (sensor_voltage < 0.5f || sensor_voltage > 4.5f) → fault reaction; software diversity: two independent torque calculation algorithms in parallel (SW-ASIL-B(D) channel 1 + SW-ASIL-B(D) channel 2, different developer); cross-comparison of results: if |result1 - result2| > threshold → fault; data store checksum: CRC-16 on safety-critical global variables, verified each cycle; stack overflow canary: 0xDEADBEEF at stack bottom, verified in OS periodic hook; flow control monitoring: SW_CHECK_A, SW_CHECK_B, SW_CHECK_C sequenced flags, compared against expected sequence at task end; patterns documented in SW Architecture Specification reviewed by independent FuSa engineer

▸ Safe state design patterns: safe state machine pattern: enum SafeState { NORMAL, DEGRADED, SAFE, EMERGENCY_OFF }; transition triggers: fault severity mapped to target state; global safe state variable protected by CRC; SafeStateManager_Enter(SAFE): (1) Dem_SetEventStatus(SAFETY_VIOLATION); (2) FiM inhibits torque SWC; (3) output driver PWM = 0; (4) WDG refresh stopped → WDG reset in T_reset ms; (5) FaultLamp = ON; idempotent: calling SafeStateManager_Enter() from any context is always safe (no re-entrancy issues); warm vs. cold restart: warm = RAM preserved, FBL check flag set, re-init FuSa SWCs; cold = full power cycle; AUTOSAR EcuM RunState machine integrates safe state into shutdown sequence: EcuM_GoDown(0) → CommunicationManager OFF → all SWCs terminate → MCU reset

▸ SW architectural independence for ASIL decomposition: two-channel SW design: Channel 1 = main torque calculation (TorqueCalc.c, TorqueCalc.h, ASIL-B(D)); Channel 2 = independent torque range monitor (TorqueMonitor.c, TorqueMonitor.h, ASIL-B(D)); independence requirements: different developers, different algorithms, separate build artifacts, separate OS tasks with different priorities, separate stack areas (MPU regions), no shared global variables; inter-channel communication: only via IOC typed interface (no direct pointer sharing); FFI argument: MPU prevents Channel 1 from writing Channel 2 stack; OS budget monitoring prevents Channel 1 starvation of Channel 2; code review: Channel 1 and Channel 2 reviewed by different reviewers; compiler independence: use different compiler flags or two-pass compilation to detect algorithmic correlation; architecture reviewed by FuSa, confirmation review at architecture freeze milestone

▸ MISRA C:2012 structure: 143 rules (27 mandatory, 116 required, 10 advisory); mandatory = no deviation; required = deviation with documented Deviation Record; key mandatory rules: R10.3 (no implicit type conversion of complex expression), R13.6 (sizeof operands shall not have side effects), R17.2 (no recursion - stack depth unpredictable); required rules for safety: R8.9 (no dead code), R14.3 (no invariant controlling expressions), R21.3 (no dynamic memory allocation - no malloc/free); advisory: R15.7 (avoid goto); ASIL-D mandate: MISRA C:2012 all mandatory + required rules; tools: PC-lint Plus, Polyspace Bug Finder, LDRA Testbed, Parasoft C/C++test, CodeSonar

▸ MISRA compliance workflow: step 1: configure static analysis tool with MISRA C:2012 ruleset (e.g., Polyspace: misra_c_2012_all_required); step 2: run on every check-in (CI/CD pipeline); step 3: for each violation: fix code OR create Deviation Record (justification + safety impact + reviewer approval); Deviation Record attributes: Rule ID, File, Line, Justification, Approved By, Safety Impact; example deviation: R21.6 (no printf in production) - "printf used only in DEBUG_MODE build, excluded from production binary by #ifdef DEBUG; no safety impact on release" - Approved by SW Safety Eng; step 4: zero non-deviation MISRA violations required before SW unit test; tools generate compliance report: summary of violations by rule, deviation count, coverage percentage

▸ CERT C standard for security-critical code: CERT C:2016 = C rules focused on vulnerabilities (buffer overflow, integer overflow, format string); key rules for automotive: INT30-C (no unsigned integer wrap), INT32-C (check signed integer overflow), ARR38-C (ensure library functions do not form invalid pointers), FIO37-C (do not assume character data is terminated with '\0'); CERT vs MISRA overlap: both forbid dynamic memory, both require explicit types; CERT additionally: STR31-C (guarantee null-terminated strings), MEM30-C (no dangling pointer dereference); ISO 26262-6 Clause 9.4.2 (ASIL-D): defensive implementation techniques: assertions, range checks, defined initialization of variables; tools: Coverity, Klocwork, CodeSonar combine MISRA + CERT rule checking

▸ MISRA enforcement in practice: code review checklist: ✓ all variables initialized at declaration; ✓ all function return values checked; ✓ no bit manipulation of signed integers; ✓ no undefined behavior (UB) patterns (e.g., signed overflow, null dereference); ✓ all casts explicit; compile-time checks: -Wall -Wextra -Werror in GCC for ASIL-D code; Polyspace Code Prover: formal verification to prove absence of run-time errors (RTE: overflow, divide-by-zero, out-of-bounds); Polyspace generates: Proved Green (no RTE possible), Orange (possible RTE, needs review), Red (definite RTE); all Red findings must be fixed; all Orange findings reviewed and justified; output: MISRA compliance report + Polyspace RTE summary included in SW safety case evidence; reviewed by SW Safety Engineer before code freeze

▸ Unit testing requirements by ASIL (ISO 26262-6 Clause 9.4.3): ASIL-D: MC/DC (Modified Condition/Decision Coverage) ≥ 100% for all safety-relevant units; ASIL-C: branch + condition coverage ≥ 100%; ASIL-B: branch coverage ≥ 100%; ASIL-A: statement coverage ≥ 100%; MC/DC definition: every condition in a decision independently affects the outcome; example: if (a && b) → test cases {T,T}=T, {T,F}=F, {F,T}=F → all combinations that independently change outcome tested; tools: VectorCAST (automatic MC/DC coverage computation + test generation), LDRA Testbed (structural coverage), Parasoft C/C++test; coverage measured on target hardware or PC-based harness; target: 100% MC/DC for safety-critical functions before SW unit test report signed

▸ Unit test case design - safety functions: test case structure: ID, requirement traceability (SwSR-ID), preconditions, inputs, expected outputs, pass/fail criteria; equivalence class testing: valid range [0.5V–4.5V] = one class, below/above = two invalid classes; boundary value analysis: test 0.49V, 0.50V, 4.50V, 4.51V; fault injection test: stub torque sensor → return stuck-at-max value → verify DEM event set within 20 ms, verify safe state entered; negative test cases: SW should handle all invalid inputs gracefully (no crash, no UB); example: test_TorqueMonitor_PlausibilityFault(): set TorqueSensor1 = 5.0V, TorqueSensor2 = 0.5V (delta = 4.5V >> 0.5V threshold); verify: after 2 cycles (20ms) → DEM_SetEventStatus(FBL_E_TORQUE_PLAUS, FAILED) called; verify: SafeStateManager_Enter(SAFE) called; verify: PWM = 0

▸ Integration testing (ISO 26262-6 Clause 10): SW integration = combine SW units and test interfaces between them; test level: SW unit → SW component → full SW; integration test cases: interface tests: verify Rte_Read/Rte_Write between SWCs; timing tests: measure actual execution time of task → compare vs. WCET analysis; error propagation: inject DEM event → verify FiM inhibits dependent SWC; regression: full integration test suite run on CI/CD pipeline (Jenkins); HIL integration: connect ECU to hardware-in-loop simulator; test vectors replayed via CANoe simulation; AUTOSAR RTE integration: verify inter-runnable variable (IRV) values correct across runnable sequence; example: TorqueCalc runnable sets Rte_IrvWrite(TorqueOutput, 5.0f); TorqueMonitor runnable reads Rte_IrvRead(TorqueOutput) and verifies consistency

▸ Test environment & reporting: VectorCAST setup: unit test harness stub generation; stub: replace hardware-dependent functions (ADC_GetValue → stub returning test vector); test execution: on PC (fast, 1000 tests/min) or on target (slower but validates HW); coverage report: VectorCAST HTML/XML report: coverage per function, per branch, per condition; pass/fail counts; traceability: each test case → requirement ID → coverage element; SW unit test report content: scope, test environment (compiler version, target MCU), coverage summary per ASIL, pass/fail results, open issues; sign-off: SW unit test report reviewed by independent SW safety reviewer before SW integration test starts; regression: any code change → re-run affected unit tests; CI pipeline: gcc compile → VectorCAST unit test → coverage check (fail if <100% MC/DC for ASIL-D) → Polyspace → MISRA check

▸ Lab: implement ASIL-B torque range monitor: task: implement TorqueRangeMonitor_Check(float torque_Nm) for ASIL-B EPS system; SwSR-020: "function shall detect if torque_cmd outside [-10.0, +10.0] Nm and set DEM fault within one call"; implementation: /* MISRA C:2012 compliant */ static bool_t fault_latched = FALSE; Std_ReturnType TorqueRangeMonitor_Check(float32 torque_Nm) { if ((torque_Nm < TORQUE_MIN) || (torque_Nm > TORQUE_MAX)) { (void)Dem_SetEventStatus(DEM_EVENT_TORQUE_RANGE, DEM_EVENT_STATUS_FAILED); fault_latched = TRUE; return E_NOT_OK; } else { if (fault_latched == FALSE) { (void)Dem_SetEventStatus(DEM_EVENT_TORQUE_RANGE, DEM_EVENT_STATUS_PASSED); } return E_OK; } }; review: all types explicit (float32), return value cast, no recursion, DEM call result cast to void (intentional)

▸ MISRA compliance check exercise: run PC-lint Plus on TorqueRangeMonitor.c with MISRA C:2012 ruleset; expected violations to find and fix: (1) if Dem_SetEventStatus() return not checked → MISRA R17.7; fix: (void) cast explicitly to show intentional ignore; (2) if TORQUE_MIN defined as signed int and torque_Nm is float → R10.8 mixed arithmetic; fix: define as 10.0f; (3) uninitialized local variable → R9.1; fix: initialize at declaration; after fixes: zero MISRA violations; write Deviation Record for any justified deviations; Polyspace: mark outputs: Green = proved safe (no UB), Orange = review → add SAFETY_ASSERT for each; target: zero Red findings in safety function before unit test

▸ VectorCAST unit test exercise: import TorqueRangeMonitor.c into VectorCAST; auto-generate test harness; write test cases: TC001: torque=5.0 → E_OK, fault not set; TC002: torque=10.1 → E_NOT_OK, DEM called with FAILED; TC003: torque=-10.1 → E_NOT_OK; TC004: torque=-10.0 → E_OK (boundary); TC005: torque=10.0 → E_OK (boundary); TC006: torque=NaN → behavior defined by range check? → add pre-condition check; run coverage: expect 100% MC/DC on if-condition; verify both sides of (torque < TORQUE_MIN) and (torque > TORQUE_MAX) independently covered by TC001+TC002+TC003+TC004+TC005; traceability: map TC001–TC005 to SwSR-020; export VectorCAST HTML coverage report

▸ CI/CD pipeline integration & final checklist: Jenkins pipeline stages: (1) gcc arm-none-eabi-gcc -mcpu=cortex-m4 -Wall -Wextra -Werror; (2) PC-lint MISRA check → fail on violations; (3) VectorCAST → fail if MC/DC < 100%; (4) Polyspace → fail on Red finding; (5) DOORS traceability check: all SwSRs linked to test cases; pipeline result: PASS/FAIL per stage; safety workflow checklist: ✓ SwSR reviewed and baselined; ✓ Code implements all SwSRs (traceability in DOORS); ✓ MISRA C:2012 compliant (zero non-deviation violations); ✓ Polyspace: zero Red findings; ✓ VectorCAST: 100% MC/DC (ASIL-B); ✓ Unit test report signed by SW Safety Engineer; ✓ Confirmation review completed by independent reviewer; expected output: complete SW unit development package: code + MISRA report + Polyspace report + VectorCAST coverage report + unit test report

▸ Safety validation vs. verification: verification = confirming that work products satisfy requirements (spec compliance); validation = confirming the item fulfills its intended use (safety goal satisfaction) in the intended environment; ISO 26262-4 Clause 10 defines safety validation at vehicle level; safety validation tests are derived directly from Safety Goals (SGs), not from technical requirements; example: SG1 = "EPS shall not apply unintended torque > 3 Nm at v > 10 km/h" → validation test = inject torque sensor fault on real vehicle, measure steering response at 80 km/h, verify torque = 0 within FTTI = 50 ms; validation evidence must demonstrate that SG is satisfied in a representative operational scenario

▸ Safety validation test planning: Safety Validation Plan (SVP) content: test objectives per SG; test environment (vehicle, HIL, track); test methods: fault injection on target, driving scenario simulation, formal analysis; test conditions: vehicle speed, temperature (-20°C to +85°C), voltage (10.5V, 13.8V, 16V); required evidence per test: measured fault reaction time vs. FTTI; recorded DEM event activation; warning lamp activation timing; safe state entry confirmed; traceability: SVP → SG → HARA; sample test case for SG2 = "EPS shall not prevent manual override": inject motor jam (block rotor) → measure driver steering force → verify <15 Nm override force via torque sensor; verify mechanical de-clutch activates within FTTI = 200 ms

▸ Validation methods: (1) Track testing: real vehicle on proving ground; fault injection via calibration tool (INCA/CANape) or dedicated fault injection harness; camera + GPS data recording; (2) HIL validation: dSPACE SCALEXIO with vehicle dynamics model; realistic sensor signal generation; automated fault injection via test automation framework; faster, repeatable, cheaper than track; (3) Mixed: SIL for algorithm validation, HIL for timing/FTTI, track for final confirmation; regression: automated HIL validation suite runs on every SW release; pass criteria: all SG validation tests PASS; FTTI measured ≤ budget; no unexpected safe state entries during normal operation; output: Safety Validation Report (SVR) with test results, open issues, deviation rationale; SVR signed by FSM

▸ Safety validation report & acceptance criteria: SVR structure: (1) references (SVP, SGs, HARA); (2) test environment description; (3) test results table: SG_ID, Test_ID, Test_Date, Pass/Fail, Measured_FTTI, Expected_FTTI, Open_Issues; (4) coverage analysis: all SGs tested; (5) conclusion: item validates functional safety requirements; acceptance criteria: (a) all validation tests pass; (b) measured FTTI ≤ specified FTTI for all SGs; (c) all DEM events fire correctly; (d) no unintended safe state transitions; (e) all open issues justified or resolved; failure handling: if validation test fails → root cause analysis → HW/SW change → re-run affected tests; change management: record change in CM tool, update affected work products; SVR reviewed by external FuSa assessor (TÜV) for ASIL-C/D items before SOP approval

▸ Confirmation measures overview (ISO 26262-2 Clause 5.4.7): three types: (1) Confirmation Review: check that each safety work product satisfies its objectives; performed by qualified reviewer not responsible for the work product; work products reviewed: HARA, FSC, TSC, FMEDA, Safety Case; (2) Functional Safety Audit: assess conformance of safety activities to Safety Plan; check process adherence, work product completeness, tool qualification status; (3) Functional Safety Assessment: holistic evaluation of safety case by independent body; confirms that ASIL goals are met; required for ASIL-C/D before SOP; independence levels: Level 1 = different person, same team; Level 2 = different team or department; Level 3 = external organization; ASIL-D requires Level 3 for FSA; ASIL-C: Level 2 minimum

▸ Confirmation Review process: reviewer qualifications: ISO 26262 Part 2 Annex A; HARA reviewer: ≥ 3 years FuSa experience, HARA training, not involved in HARA development; HARA review checklist: ✓ item definition complete and unambiguous; ✓ all functions identified; ✓ all scenarios identified (at minimum 5 representative); ✓ S/E/C ratings justified with references; ✓ ASIL derivation consistent with ISO 26262-3 Table 4; ✓ no ASIL-bearing hazard without Safety Goal; ✓ Safety Goals technology-independent; ✓ FTTI values defined; ✓ Safe states defined; review findings: classified Major (must resolve before next phase), Minor (improvement recommended), Observation (informational); review record: reviewer name, date, findings list, resolution status; confirmed by reviewer signature

▸ Functional Safety Audit: ISO 26262-2 Clause 5.4.7.2; auditor: internal FuSa team or external (TÜV, Bureau Veritas, DEKRA); audit scope: does development process conform to Safety Plan? Is evidence complete per phase?; audit questions: "Show me the traceability matrix between HARA and FSC" → FuSa engineer demonstrates DOORS links; "Is tool qualification complete for your code generator?" → TCL-3 tool qualification report reviewed; "Are all ASIL-D SW components covered by MC/DC tests?" → VectorCAST coverage reports reviewed; audit report: finding ID, severity, evidence required, due date, responsible person; CAR (Corrective Action Report) for each Major finding; closed findings re-audited; audit compliance rate target: 95% findings resolved before SOP

▸ Functional Safety Assessment (FSA): ISO 26262-2 Clause 5.4.7.3; assessor: qualified external organization (e.g., TÜV SÜD, TÜV Rheinland, SGS-TÜV); assessor independence: no involvement in development; FSA phases: Planning → Assessment → Report; assessment activities: review Safety Case structure and completeness; verify all work products exist and are consistent; verify ASIL assignment correct; confirm confirmation reviews completed; check tool qualifications; perform spot-check of evidence quality; FSA report: confirms item developed per ISO 26262 (Conformant) or lists open gaps (Conditional/Non-Conformant); Conformant FSA required for: ASIL-D items shipped to OEM; regulatory compliance (UN R155/R156); product liability protection; FSA certificate valid for specific HW/SW version; re-assessment required on significant changes; cost: TÜV assessment ~50–150k EUR depending on item complexity

▸ Safety Case definition & purpose: ISO 26262-2 Clause 6.4.12: Safety Case = structured argument + evidence that item achieves functional safety; argument structure: Safety Goal X is satisfied because: (1) HARA correctly identified all hazards; (2) Safety measures implemented (design, safety mechanisms); (3) Safety measures verified to satisfy safety requirements; (4) Residual risk is acceptable; formats: Goal Structuring Notation (GSN) - graphical argument diagram; Claims-Arguments-Evidence (CAE) in Word/Confluence; assurance case tool: Adelard ASCE, IBM DOORS Safety Case module, Clarizo; safety case is a living document: updated at each lifecycle phase; final Safety Case = all evidence assembled and approved before SOP

▸ Safety Case structure - GSN diagram: Goal (G): "EPS meets functional safety requirements per ISO 26262 ASIL-D"; Strategy (S): "Argue by compliance with ISO 26262 lifecycle phases"; Sub-Goals: G1="HARA correctly identified all hazards" → Evidence: E1=HARA Report v2.0 reviewed by TÜV; G2="Safety measures implemented" → Evidence: E2=FMEDA showing SPFM 99.1%, E3=SW Safety Requirements implemented and tested; G3="Safety measures verified" → Evidence: E4=Unit Test Report (100% MC/DC), E5=HIL Validation Report, E6=Safety Validation Report; G4="Residual risk acceptable" → Evidence: E7=PMHF calculation (8.7 FIT < 10 FIT), E8=DFA report; Assumptions: "OEM CAN messages transmitted correctly per DBC v2.1" → context for DIA; Safety Case completeness: every SG has argument chain to evidence

▸ Evidence management & traceability: all evidence documents referenced in Safety Case must be: under configuration management (baseline version); reviewed (confirmation review record on file); dated and version-controlled; work product list tracked in safety plan; evidence traceability: Safety Goal → FSR → TSR → SwSR → Test Case → Test Result → Test Report → Safety Case evidence entry; DOORS: bidirectional traceability matrix automatically generated; safety case template shows missing links (red) and covered links (green); Safety Case content checklist: ✓ Item definition; ✓ HARA report; ✓ FSC; ✓ TSC; ✓ HW evaluation report (SPFM/LFM/PMHF); ✓ FMEDA; ✓ DFA; ✓ SW Safety Architecture; ✓ MISRA compliance report; ✓ Unit test report; ✓ Integration test report; ✓ Safety validation report; ✓ Confirmation review records

▸ Safety Case review & approval: internal review: FSM reviews Safety Case completeness at each milestone gate; milestone gates: Concept (HARA complete), System Design Freeze, HW Design Freeze, SW Freeze, SOP; Safety Case "draft" → "reviewed" → "approved" states in CM tool; external assessment: TÜV assessor reviews Safety Case at Final phase; common deficiencies found: (1) missing traceability link: SwSR not linked to test case; (2) FMEDA DC values not justified; (3) tool not qualified (TCL-2 tool used without qualification record); (4) HARA confirmation review not signed; (5) HSI not formally reviewed; repair actions: assign owner + due date + re-verification; final Safety Case approved by FSM + TÜV conformance statement attached; shipped to OEM as part of Development Interface Agreement fulfillment

▸ ISO 26262 Part 7 - Production requirements: manufacturing process must maintain functional safety properties of the item; production controls: incoming inspection (100% electrical test of safety-relevant components), AOI (Automated Optical Inspection) for solder quality, ICT (In-Circuit Test) for open/short detection, FCT (Functional Circuit Test) for ECU end-of-line; calibration: measurement equipment calibration traceable to national standard; ESD protection: ASIL-D PCBs in ESD packaging throughout production; safety-relevant special characteristics (SCC): must be tracked on traveler card (e.g., "Torque sensor IC alignment critical ±0.1 mm"); production release: safety case includes production process qualification evidence; first-off confirmation by quality engineer

▸ Field monitoring & feedback: operation phase: collect field data to monitor actual vs. assumed failure rates; DTC field return rate: analyze by DTCGroup (e.g., C0100=torque sensor fault rate = 0.5% fleet in first 2 years); compare against FMEDA assumed FIT rates; if actual rate > predicted → update FMEDA → re-evaluate SPFM; feedback loop: DTC analysis → FMEDA update → HW evaluation report update → safety case update; OTA DTC upload: telematics reads DTC via J1979/OBD → uploads to OEM fleet management system; safety monitoring plan: documented in Safety Plan (ISO 26262-7 Clause 6); triggers for field action: DTC rate ≥ 10× predicted FIT rate, or field safety incident (injury due to ASIL function failure) → mandatory OEM recall process

▸ Change management in operation: ISO 26262-8 Clause 8: impact analysis required for every ECU software update or HW change; change categories: Category 1 = no safety impact (e.g., cosmetic code change, calibration value within range); Category 2 = potential safety impact → re-run HARA, update affected work products, re-run relevant tests; regression test policy: Cat 1 → unit test re-run; Cat 2 → full safety validation re-run; OTA software updates: safety-relevant updates must go through FBL secure update (anti-rollback, signature verification); UN R156 requirement: OTA update process must be documented and authorized; SUMS (Software Update Management System): audit trail of all OTA campaigns (VIN, old version, new version, campaign result); change record in CM tool: change ID, impact analysis, test evidence, approver, date

▸ Decommissioning & end-of-life: ISO 26262-7 Clause 6.4: decommissioning plan: how to safely retire the item from service; safety-relevant activities: (1) inhibit OTA updates for decommissioned platform; (2) archive safety case for product liability (10 years minimum in EU); (3) communicate known safety issues to service network; (4) field action if residual risk found post-decommission; data protection: VIN-linked DTC data deleted per GDPR after service; HSM keys: invalidate provisioned keys to prevent reuse of decommissioned ECUs; lessons learned: debrief after each product lifecycle - identify gaps in HARA, FMEDA, validation process; input to next product safety plan; ISO 26262 Part 7 Annex B: decommissioning checklist ensures no residual risk in field; sign-off: FSM signs decommissioning report