Late change on an ASIL D torque path and the confirmation measures
Five months before SOP, the ASIL D steering-torque path in an EPS ECU changes: a filter coefficient is altered and one plausibility check moves from the 10 ms task to the 5 ms task. The change is made under a change request, is unit-tested (statement coverage 100 % on the touched units), and integration tests pass. The FMEDA still carries the pre-change failure rates, and the safety case does not mention the change. The project plans to run the functional safety assessment in three weeks and asks you, as the independent assessor, to 'sign the delta as verified'. The change also affects a shared AUTOSAR runnable that is used by the parking function, which is developed by another team that was not informed. The change request does not list affected work products.
1. Which confirmation measures apply and in what order, and why is 'unit tests pass' not sufficient evidence?
Read the worked answer
The confirmation measures are confirmation reviews, functional safety audit and functional safety assessment, all performed by people independent of the development, and they apply in that progression as the work products mature. A change to an ASIL D path restarts part of that chain: it triggers an impact analysis across the safety lifecycle, an updated failure analysis, and verification planned to the ASIL of the affected requirements.
Unit tests at 100 % statement coverage on the touched units prove the modified code executes. They say nothing about:
- whether the diagnostic coverage claimed for the plausibility check still holds when it runs on a 5 ms instead of a 10 ms cycle, and whether the fault handling time interval is still met;
- whether the filter coefficient change alters the transient response so that the plausibility window is exceeded in normal driving, which is a false-positive path;
- whether the shared AUTOSAR runnable still behaves within its execution contract for the parking function.
That is why the change request must list affected work products, and it currently does not.
2. What is your assessment verdict and what do you require before you sign anything?
Read the worked answer
Verdict: not demonstrated safe, so I do not sign. Write it that way, with the reason, so the project can act on it.
Requirements before signature:
- A documented impact analysis that names every affected work product: requirements, design, code, test, FMEDA, safety case, and the parking function's specification.
- A re-evaluated FMEDA for the moved check, including whether the new task period is schedulable and whether the fault handling time interval still holds under worst-case load.
- A statement on the coefficient change with evidence, for example a step-response analysis or a test sweep showing the plausibility window is not brushed in transients.
- Confirmation from the parking team that interface, run-time and re-entrancy behaviour of the shared runnable is unchanged, or re-verification of their function.
- Review of the changed code by someone independent of the author, plus regression at the appropriate integration level.
Give a date for reassessment and escalate if the schedule cannot hold; an assessor who signs on schedule pressure is not independent.
3. The team argues the change is 'just a coefficient' and a task move. How do you structure the argument that decides whether it is safety-relevant?
Read the worked answer
Significance is decided by the effect on the safety goal, not by the size of the diff.
Ask three questions and answer each with evidence rather than discussion:
- Does the coefficient change shift the filter's step response enough that the torque signal exceeds the plausibility window during a real transient? Answer with a signal-level test or analysis across the operating envelope, not a unit test.
- Does moving the check to a 5 ms task change the worst-case latency between fault occurrence and reaction, and therefore the fault handling time interval? Answer with a timing analysis including task jitter and CPU load, plus a fault injection at the moving check.
- Does the diagnostic coverage claimed in the FMEDA depend on the task period or on the check's execution frequency? If yes, the FMEDA number is now an assumption without support.
Decision rule: if any of the three cannot be shown unchanged, the change is safety-relevant and needs full ASIL-appropriate verification. 'It is only a coefficient' fails at question one unless evidence answers it.