Files
demo-epb/docs/safety-md/Tool-Qualification-Cppcheck.md
T
Stefan Lohmaier fb2c083551
Validate / build-test (macos-latest) (push) Failing after 3s
Validate / build-test (windows-latest) (push) Failing after 15s
Validate / build-test (ubuntu-latest) (push) Successful in 17s
Validate / reports (push) Successful in 50s
Release / release (push) Successful in 50s
feat(i18n): full English translation of demo-epb
Phase 2 of the English translation:

Word documents (filled, EPB-specific):
- 8 plans (PID, PM, QA, SWE, Test, Project Manual, CM, RM)
- 6 safety docs (HARA, Safety Case, FMEDA, MISRA Compliance,
  Verification Report, Tool Qualification Cppcheck)
- 2 manuals (User, Service)
- 3 audit artefacts (Review minutes, NC-001, MISRA-REC-001)
- All regenerated via pandoc from English markdown sources

Code, tests, headers:
- All file headers, struct comments, function docstrings in English
- All test names (TEST_BEGIN strings) translated
- Inline comments translated
- 46 tests still green after translation

CI workflows:
- All step names in English
- Step descriptions, comments, release notes template in English

README.md fully rewritten in English with proper guided tour.

Phase 3 (still pending): dev-process repo templates + toolstack/setup docs.
2026-05-12 03:37:51 -07:00

128 lines
5.5 KiB
Markdown

---
doc-id: SLM-EPB-TQ-Cppcheck-001
version: 1.0
status: Released
date: 2026-05-12
---
# Tool Qualification — Cppcheck + MISRA addon
| Field | Value |
|---------------|----------------------------------------|
| Tool | Cppcheck with MISRA addon |
| Version | 2.7+ (Linux apt) / 2.20.0 (Windows/macOS) |
| Vendor | Daniel Marjamäki et al. (open source) |
| Licence | GPLv3 |
| Use | Static analysis, MISRA C:2012 check |
| Standard | ISO 26262 Part 8 §11 |
---
## 1. Purpose
This report qualifies Cppcheck with the MISRA addon for use in demo-epb development. Tool qualification per ISO 26262-8 §11 is mandatory when:
- The tool can influence the safety level of the software (TI > 1)
- The tool lacks off-the-shelf certification
## 2. Tool classification
### 2.1 Use cases
| UC-ID | Use case | Output verified? |
|-------|-----------------------------------|----------------------------|
| UC-01 | Static analysis during build | Via review (CI log) |
| UC-02 | MISRA C:2012 compliance evidence | Via deviation records |
| UC-03 | Bug identification | Findings are reviewed |
### 2.2 Tool Impact (TI)
Definition per ISO 26262-8 §11.4.5.1:
| Question | Answer |
|------------------------------------------------------------------------|-----------|
| Can a tool error lead to a violation of a safety requirement? | Yes (the tool may miss bugs) |
| Can a tool error prevent detection of a bug? | Yes |
**TI = TI2** (the tool can influence safety)
### 2.3 Tool Error Detection (TD)
Definition per ISO 26262-8 §11.4.5.4:
| Question | Answer |
|------------------------------------------------------------------------|--------------|
| Is the tool output verified by other measures? | Partially: redundant via clang-tidy + code review + unit tests |
| Are bugs detected by downstream reviews / tests? | Yes |
**TD = TD2** (medium detection probability)
### 2.4 Tool Confidence Level (TCL)
With TI2 + TD2 we obtain per ISO 26262-8 Table 4: **TCL2**.
### 2.5 Qualification method
For TCL2 + ASIL-D, a **tool qualification** is required (Table 5). Applicable methods:
- Increased confidence from use (§11.4.7) — available for Cppcheck
- Evaluation of the tool development process (§11.4.8)
- Validation of the software tool (§11.4.9)
In this project: **Increased Confidence from Use**.
## 3. Increased Confidence from Use — evidence
### 3.1 Maturity / adoption
| Criterion | Assessment |
|----------------------------------------|------------------------------------------|
| Tool age | > 15 years of development |
| Active community | > 100 contributors on GitHub |
| Releases per year | ~6 stable releases |
| Known automotive users | Documented users including several OEMs |
| Bug tracker | Public (GitHub Issues) |
| Test suite | Own self-test suite, > 5000 tests |
### 3.2 Prior use in project context
Cppcheck has been used since 2023 in slohmaier projects for static-analysis builds (anecdotally: ControlNav, BrailleKit). No known cases where Cppcheck missed a real safety violation that wasn't subsequently caught by code review.
### 3.3 Validation tests in project
Each build performs the following validation checks against Cppcheck:
| Test | Expected behaviour | Result |
|--------------------------------------------|----------------------------------|-----------|
| Built-in test case `tests/validation_cppcheck.c` with intentionally injected bug | Cppcheck detects it | OK |
| Cppcheck output is deterministic | Repeated runs == identical | OK |
| MISRA rules checked against reference set | Detection ≥ 95% required rules | OK |
## 4. Known limitations
| Limitation | Mitigation |
|------------------------------------------|---------------------------------------------|
| MISRA addon does not implement all 175 rules completely | Manual review checklists for missing rules |
| Lower detection rate for heap bugs | No heap usage in this project (MISRA 21.3) |
| False positives on complex pointer aliasing | Per-instance deviation records |
## 5. Qualification verdict
Cppcheck with the MISRA addon is **qualified** for use in demo-epb at TCL2 ASIL-D, based on "Increased Confidence from Use".
This qualification applies to version 2.7+ on Linux (CI) and version 2.20.0 on macOS/Windows (developer workstations). On tool update the validation must be repeated (regression suite).
## 6. Scope
This tool qualification applies **only** to:
- Project: demo-epb
- ASIL: up to D
- Use: static analysis + MISRA check (CI + local)
- Tool versions: 2.7+ Linux / 2.20.0 macOS+Windows
## 7. Revision history
| Version | Date | Change | Author |
|---------|-------------|---------------------|------------|
| 1.0 | 2026-05-12 | First release | S. Lohmaier|