Bulk approval of MISRA deviations in ASIL B code
A body-control-module code base of 480 kLOC C is checked against MISRA C:2012 plus 40 project rules. The nightly analysis reports 9,400 violations; triage leaves 1,200 formally recorded deviations, 380 of them in ASIL B functions. Each deviation record contains only the comment 'accepted by team'; there is no rationale, no approver, and no link to a hazard or to a verification activity. Three builds ago a second team joined and the violation count has risen by roughly 600 per week since. Separately, 22 functions in ASIL B code exceed a cyclomatic complexity of 30, and one of them is the single implementation of the watchdog refresh service. A customer review is in three weeks and the quality manager wants to 'clear the backlog' by bulk-approving all open deviations.
1. Assess the bulk-approval proposal. What does a defensible deviation record contain, and what do you do with the 380 deviations in ASIL B code?
Read the worked answer
Bulk approval converts an open finding into a closed one without adding any knowledge, so it is worse than leaving the deviations open: it creates a false record that a competent reviewer will use against the project.
A defensible deviation record contains: rule identifier, file and line with the code, the reason the rule cannot be followed here, an analysis of what the rule protects against and why that risk does not arise (no undefined behaviour, no masking of a fault), the compensating measure (review, targeted test, alternative analysis), an approver independent of the author, and a scope with a validity period.
For the 380 in ASIL B code: 380 is small enough to re-review completely, so do that. Sort them by what the rule protects. Any deviation that can produce undefined behaviour or hide a fault in a safety mechanism, for example implicit conversion feeding a plausibility check or a switch without default in a diagnostic path, must be fixed or escalated to the safety manager. Deviations in code not reachable from a safety goal can be re-scoped with a reachability argument, which is a legitimate justification if it is written down.
2. Is a cyclomatic complexity of 30 a MISRA violation? How do you use the finding on the watchdog refresh function, and which static techniques do you apply to it?
Read the worked answer
No. MISRA C:2012 does not mandate a complexity metric; if 30 breaches a limit it is because one of the 40 project rules says so. The underlying driver is the ISO 26262-6 design principle of limited size and complexity, which is a design-quality requirement rather than a coding-rule violation, and it is exactly the kind of finding that should not be argued away by pointing at a rule list.
The watchdog refresh is the wrong place to lose the argument twice, since it is a safety mechanism with a single implementation. Apply:
- Control-flow analysis: call graph, reachability, and whether the refresh call is on every path it must be on, including error paths.
- Data-flow analysis: definition-use chains of the refresh counter and the window registers, looking for a path where the counter is written twice or never.
- A structured inspection with a checklist derived from the refresh window timing, the failure mode where the refresh task itself hangs, and the conditions under which the watchdog is disabled during startup or flashing.
Then demand refactoring or a documented rationale, not a waiver.
3. The violation count is rising by about 600 per week since a second team joined. Design the process change that restores a usable signal from the nightly analysis.
Read the worked answer
An absolute violation count on a growing code base is not a control signal; it mixes legacy debt, new defects and false positives, and it will keep rising whatever anyone does.
- Freeze a baseline: snapshot all current findings and track them as recorded debt with an owner, not as failures.
- Gate on the delta, not the total: only findings in new or changed code block a merge. This is what makes the new team's impact visible within a day.
- Put the rule configuration and the suppression file under version control and review changes to them, otherwise a tool upgrade manufactures a 600-finding spike that nobody can explain.
- Classify false positives into a reviewed suppression list rather than editing code to silence the tool, and re-check suppressions at each tool version.
- Give each team a budget and report per team; a shared count with no owner produces exactly the bulk-approval proposal you are now fighting.
Design the gate so the answer to a finding is a decision, not a comment.