slohmaier/demo-epb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

feat: Vollstaendige Demo-Doku — Safety, Manuals, Reports, API-Doc
Validate / build-test (macos-latest) (push) Failing after 4s
Details
Validate / build-test (windows-latest) (push) Failing after 15s
Details
Validate / build-test (ubuntu-latest) (push) Failing after 15s
Details
Validate / reports (push) Has been skipped
Details
Release / release (push) Successful in 50s
Details

Browse Source 
Neue Word-Dokumente (alle aus Markdown via pandoc):

Safety (docs/safety/):
- HARA.docx — Hazard Analysis & Risk Assessment, leitet ASIL-D ab
- Safety-Case.docx — Argumentation pro Safety Goal (GSN-Stil)
- FMEDA.docx — Pro-Komponente Failure Modes + Diagnostic Coverage
- MISRA-Compliance-Statement.docx — formaler MISRA-Nachweis
- Verification-Report.docx — V-Modell rechte Seite Zusammenfassung
- Tool-Qualification-Cppcheck.docx — Tool-Qual (TCL2/ASIL-D)

Manuals (docs/manuals/):
- User-Manual.docx — Fahrerhandbuch-Auszug
- Service-Manual.docx — Werkstatt-Doku mit UDS-DTCs

CI-Erweiterungen:
- Doxyfile + `make docs` — API-Dokumentation aus src/
- tools/generate_test_report.py + `make test-report` — Test-Summary HTML
- validate.yml: Doxygen + Test-Report als CI-Artefakte
- release.yml: alle Word-Docs + Engineering-Artefakte ins Release-Bundle

README:
- Komplette Tour durch alle Artefakte
- Repo-Struktur-Diagramm aktualisiert
This commit is contained in:
Stefan Lohmaier
2026-05-12 00:55:37 -07:00
parent 84fab72f23
commit c54a9c55d2
21 changed files with 1396 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/safety-md/FMEDA.md
+119
View File
@@ -0,0 +1,119 @@
---
doc-id: SLM-EPB-FMEDA-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
---
# Failure Mode Effects and Diagnostic Analysis (FMEDA)
| Feld | Wert |
|--------------|----------------------------------------|
| Projekt | demo-epb |
| Dokument-ID | SLM-EPB-FMEDA-001 |
| Version | 1.0 |
| Status | Freigegeben |
| Datum | 2026-05-12 |
| Norm | ISO 26262 Part 5 §8 + Part 10 |
---
## 1. Zweck
Bottom-up-Analyse der Hardware- und Software-Fehlermoeglichkeiten der EPB,
Quantifizierung der Diagnostic Coverage (DC) und Berechnung der Single-Point
Fault Metric (SPFM) und Latent Fault Metric (LFM). Wird zur Bewertung der
Hardware-Architektur-Metriken nach ISO 26262-5 benoetigt.
In dieser Demo wird der **Software-Anteil** behandelt; der Hardware-FMEDA
ergeht separat (Komponenten-Hersteller).
## 2. Methodik
Pro Software-Komponente werden mogliche Failure Modes aufgelistet, ihre
Effekte beschrieben, Detection-Mechanismen identifiziert und die
Diagnostic Coverage abgeschaetzt.
DC-Klassen nach ISO 26262-5 §C.2:
| DC-Klasse | DC % | Bedeutung |
|-----------|-------|--------------------------------------|
| Low | < 60% | Schwache Diagnose |
| Medium | 60-90%| Mittlere Diagnose |
| High | > 90% | Starke Diagnose |
## 3. FMEDA-Tabelle pro Komponente
### 3.1 SWA-002 Apply Controller (ASIL-D)
| FM-ID | Failure Mode | Effekt | Detection | DC | Safe State erreicht? |
|-------|---------------------------------------|--------------------------------------|---------------------------------|-------|----------------------|
| FM-01 | State-Machine bleibt in APPLYING haengen | Bremse nie applied | Timeout 30*50ms -> ERROR | High | Ja (ERROR-State) |
| FM-02 | Falscher State-Uebergang APPLIED->RELEASED ohne Bedingung | Wegrollen | Vorbedingungs-Check (`release_preconditions_ok`) | High | Ja |
| FM-03 | Watchdog-Counter ueberlaeuft | Watchdog feuert false-positive | Wrap-safe Subtraktion in Watchdog (NC-001) | High | Ja (Reset) |
| FM-04 | Hold-Loop regelt nicht nach | Klemmkraftverlust unerkannt | Periodische Pruefung alle 50ms + force-tolerance | High | Ja (Re-Apply) |
| FM-05 | NULL-Pointer-Dereferenzierung Input | Crash | Early-Exit Check | High | Ja (Letzter Zustand bleibt) |
Aggregierte DC fuer Apply Controller: **96 %** (High).
### 3.2 SWA-003 Actuator Driver (ASIL-B)
| FM-ID | Failure Mode | Effekt | Detection | DC |
|-------|------------------------------------------|--------------------------------------|---------------------------------|-------|
| FM-06 | PWM-Wert ausserhalb 0..100 | Hardware-Schaden | Parameter-Check, return EINVAL | High |
| FM-07 | ISR misst zu hohen Strom kontinuierlich | Motor-Brand | Overcurrent-Cutoff > 8A > 100ms | High |
| FM-08 | ISR misst zu niedrigen Strom (Sensor-Fehler) | Klemmkraft falsch geschaetzt | Cross-Check beider Aktoren | Medium |
| FM-09 | Beide Aktoren gleichzeitiger Cutoff | EPB inoperativ | DTC + Service-Mode bleibt zugaenglich | Medium |
Aggregierte DC fuer Actuator Driver: **85 %** (Medium).
### 3.3 SWA-001 Safety Manager (ASIL-D)
| FM-ID | Failure Mode | Effekt | Detection | DC |
|-------|------------------------------------------|--------------------------------------|---------------------------------|-------|
| FM-10 | Auto-Apply-Timer feuert nicht | Fahrzeug rollt nach Motor-Aus | Watchdog Safety-Manager | High |
| FM-11 | Hill-Hold-Uebergabe verzoegert | Rollen am Berg | Bremspedal-Signal-Verfolgung | High |
| FM-12 | False-Positive Hill-Hold-Aktivierung | Unnoetiges Apply | Filter-Tiefpass Inclinometer | Medium |
| FM-13 | Grade-Filter Saturation | Hill-Hold verpasst | Plausibilitaets-Check (Range) | Medium |
Aggregierte DC fuer Safety Manager: **88 %** (Medium-High).
### 3.4 SWA-004 Wheel Speed Plausibilisierung (ASIL-B)
| FM-ID | Failure Mode | Effekt | Detection | DC |
|-------|------------------------------------------|--------------------------------------|---------------------------------|-------|
| FM-14 | Stuck-At-Zero auf einem Rad | Falscher Stillstand erkannt | Spreizung > 3 km/h Check + DTC | High |
| FM-15 | Alle 4 Sensoren ausgefallen | Stillstand unerkannt | Komplettausfall-DTC + Vorlast-Annahme | High |
DC: **95 %** (High).
## 4. Aggregierte Metriken (Software)
| Metrik | Wert | Anforderung ASIL-D |
|------------------------------|---------|------------------------|
| SPFM (Single-Point Fault) | 95 % | >= 99 % (Software allein nicht ausreichend, HW erforderlich) |
| LFM (Latent Fault) | 90 % | >= 90 % |
| Aggregated DC | 92 % | High |
**Hinweis:** Die hier berichteten Software-DC-Werte sind keine ASIL-D-Hardware-
Metriken. ASIL-D-konforme SPFM/LFM benoetigen quantitative Hardware-FIT-Raten,
die auf HW-Ebene berechnet werden (Tier-1-Aktoren, ECU-Hardware).
## 5. Diagnose-Massnahmen (Inventar)
| Mechanismus | Komponente | Trigger |
|------------------------------|-----------------------|----------------------------------------|
| Timeout-Watchdog | Apply Controller | 30*50ms im APPLYING |
| Klemmkraft-Hold-Check | Apply Controller | alle 50ms |
| Overcurrent-Cutoff | Actuator Driver | 8A > 100ms |
| Sensor-Spreizungs-Check | Wheel Speed Plausi | jede 10ms-Periode |
| Inclinometer-Range-Check | Inclinometer Filter | jede 10ms |
| Watchdog Safety Manager | Safety Manager | 100ms Liveness |
| Diagnostic Manager UDS DTCs | Diag Manager | Aufruf von `diag_set_dtc()` |
## 6. Aenderungshistorie
| Version | Datum | Aenderung | Autor |
|---------|-------------|-------------------------|----------------|
| 0.1 | 2026-05-11 | Initialer Entwurf | S. Lohmaier |
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |
docs/safety-md/HARA.md
+154
View File
@@ -0,0 +1,154 @@
---
doc-id: SLM-EPB-HARA-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
---
# Hazard Analysis & Risk Assessment (HARA)
| Feld | Wert |
|----------------|------------------------------------------------|
| Projekt | demo-epb (Elektrische Parkbremse) |
| Dokument-ID | SLM-EPB-HARA-001 |
| Datum | 2026-05-12 |
| Version | 1.0 |
| Status | Freigegeben |
| Norm | ISO 26262 Part 3 (Concept Phase) |
| Erstellt von | Stefan Lohmaier |
| Geprueft von | (Tech Lead, im Realprojekt unabhaengig) |
| Freigegeben von| (Safety Manager, im Realprojekt unabhaengig) |
---
## 1. Zweck
Identifikation und Klassifikation aller relevanten Hazards der Elektrischen
Parkbremse (EPB) gemaess ISO 26262-3. Aus den Hazards werden Sicherheitsziele
abgeleitet und ein Automotive Safety Integrity Level (ASIL) zugewiesen.
## 2. Item-Definition
Die EPB ist ein elektromechanisches System, das die hinteren Bremssaettel mit
zwei kleinen Elektromotoren festklemmt und wieder loest. Item-Boundary
(ISO 26262-3 §5):
- **Innerhalb:** EPB-ECU, beide Caliper-Motoren, EPB-Schalter, Status-LED
- **Aussen:** ESP, Motormanagement, Bremssystem (hydraulisch), Lenkung
- **Schnittstellen:** CAN-Bus, Wheel-Speed-Sensoren, Inclinometer
## 3. Operational Situations & Hazards
Die folgenden Betriebssituationen und Hazards wurden im Concept-Workshop
(2026-05-11) identifiziert:
### 3.1 Hazard-Liste
| H-ID | Hazard | Betriebs-Situation |
|-------|------------------------------------------------------|------------------------------------|
| H-01 | Ungewolltes Loesen der Parkbremse im Stillstand | Fahrzeug parkt am Hang, Fahrer aus|
| H-02 | Ungewolltes Festklemmen waehrend der Fahrt | Fahrt > 10 km/h |
| H-03 | Keine Apply-Reaktion auf Fahrer-Anforderung | Stillstand, Fahrer betaetigt Schalter |
| H-04 | Verlust der Klemmkraft im Hold-Zustand | Parkphase laenger als 1 h |
| H-05 | Motorschaden durch Ueberstrom | Aktor-Mechanik blockiert |
| H-06 | Falsche Hill-Hold-Uebergabe (Rollen am Berg) | Anfahrt am Berg |
| H-07 | Keine Release-Reaktion bei Anfahrt | Stillstand, Fahrer will losfahren |
| H-08 | LED-Anzeige falsch | beliebig |
### 3.2 Severity / Exposure / Controllability
Klassifikation nach ISO 26262-3 §6:
| Severity | Bedeutung |
|----------|------------------------------------------------------------|
| S0 | Keine Verletzungen |
| S1 | Leichte / moderate Verletzungen |
| S2 | Schwere Verletzungen (Ueberleben wahrscheinlich) |
| S3 | Lebensgefaehrliche Verletzungen (Ueberleben fraglich) |
| Exposure | Bedeutung |
|----------|------------------------------------------------------------|
| E0 | Sehr unwahrscheinlich |
| E1 | Sehr seltene Situation |
| E2 | Seltene Situation |
| E3 | Mittlere Wahrscheinlichkeit |
| E4 | Haeufige Situation |
| Controllability | Bedeutung |
|------------------|------------------------------------------------------|
| C0 | Allgemein beherrschbar |
| C1 | Einfach beherrschbar (>99% der Fahrer) |
| C2 | Normal beherrschbar (>90% der Fahrer) |
| C3 | Schwer beherrschbar oder unbeherrschbar |
### 3.3 ASIL-Determination
| H-ID | Beschreibung | S | E | C | ASIL |
|-------|-------------------------------------------|----|----|----|-------|
| H-01 | Ungewolltes Loesen, Parkphase | S3 | E4 | C3 | **D** |
| H-02 | Ungewolltes Festklemmen waehrend Fahrt | S3 | E4 | C3 | **D** |
| H-03 | Keine Apply-Reaktion auf Anforderung | S2 | E4 | C2 | B |
| H-04 | Klemmkraftverlust im Hold | S3 | E4 | C3 | **D** |
| H-05 | Motorschaden durch Ueberstrom | S1 | E3 | C2 | A |
| H-06 | Hill-Hold-Versagen (Rollen am Berg) | S3 | E3 | C3 | C |
| H-07 | Keine Release-Reaktion | S1 | E4 | C2 | A |
| H-08 | LED-Anzeige falsch | S0 | -- | -- | QM |
ASIL-Matrix laut ISO 26262-3 Table 4 angewandt. H-06 wurde im Review von
ASIL-D auf ASIL-C zurueckgestuft, da Hill-Hold-Ausfall auf trockener Strasse
durch Fahrerreaktion noch beherrschbar (C2-C3-Grenzfall, konservativ C3).
## 4. Sicherheitsziele (Safety Goals)
Aus den Hazards werden folgende Safety Goals abgeleitet:
| SG-ID | Sicherheitsziel | ASIL | Abgedeckte Hazards |
|-------|--------------------------------------------------------------------|-------|----------------------|
| SG-01 | EPB darf sich im Stillstand nicht ungewollt loesen | D | H-01, H-04 |
| SG-02 | EPB darf nicht ungewollt waehrend der Fahrt festklemmen | D | H-02 |
| SG-03 | EPB muss Schutz gegen Aktor-Ueberstrom bieten | A | H-05 |
| SG-04 | Hill-Hold muss zuverlaessig an Apply Controller uebergeben | C | H-06 |
| SG-05 | EPB muss auf Fahreranforderung in spezifizierter Zeit reagieren | B | H-03, H-07 |
## 5. Safe State
Definitionen aus ISO 26262-3 §7.4.2.5:
| Item / Funktion | Safe State |
|------------------------|------------------------------------------------------------|
| Apply-Phase | Aktor stoppen, Status auf APPLIED setzen |
| Hold-Phase | Klemmkraft beibehalten (passiv) |
| Release-Phase | Auf Apply zurueckkehren, Klemmkraft halten |
| Bei Hardware-Fehler | APPLIED-Zustand erzwingen (verhindert Wegrollen) |
Der ueber alle Faelle "konservative" Safe State ist **APPLIED**: lieber zu
viel klemmen als zu wenig.
## 6. FTTI (Fault Tolerant Time Interval)
| Hazard | FTTI | Begruendung |
|--------|---------|-----------------------------------------------------------|
| H-01 | 5 s | Wegrollen am Berg startet typ. nach 1-2 s, Hand-Aktion mglich nach ca. 5 s |
| H-02 | 100 ms | Stoss-Verlangsamung bei 50 km/h muss innerhalb 100 ms erkannt werden |
| H-04 | 30 s | Klemmkraftverlust akkumuliert langsam, periodische Pruefung alle 50ms reicht |
| H-06 | 500 ms | Hill-Hold-Uebergabe muss vor Rollbeginn (< 500ms) abgeschlossen sein |
## 7. Funktionale Sicherheitsanforderungen (FSR)
Aus den Safety Goals werden in `reqs/sys/` die SYS-Anforderungen abgeleitet
(siehe Traceability-Matrix). Mapping:
| SG-ID | SYS-Anforderungen |
|-------|----------------------------------------------------|
| SG-01 | SYS-001, SYS-004 |
| SG-02 | SYS-002 (Apply-Plausibilisierung), SYS-005 |
| SG-03 | SYS-007 |
| SG-04 | SYS-005, SYS-006 |
| SG-05 | SYS-002, SYS-003 |
## 8. Aenderungshistorie
| Version | Datum | Aenderung | Autor |
|---------|-------------|-------------------------|----------------|
| 0.1 | 2026-05-11 | Initialer Entwurf | S. Lohmaier |
| 1.0 | 2026-05-12 | Erstfreigabe nach Review| S. Lohmaier |
docs/safety-md/MISRA-Compliance-Statement.md
+130
View File
@@ -0,0 +1,130 @@
---
doc-id: SLM-EPB-MISRA-COMP-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
---
# MISRA C:2012 Compliance Statement
| Feld | Wert |
|--------------|----------------------------------------|
| Projekt | demo-epb |
| Dokument-ID | SLM-EPB-MISRA-COMP-001 |
| Datum | 2026-05-12 |
| Standard | MISRA C:2012 (inkl. Amendment 1) |
| Compiler | GCC 11.2 (Linux CI) / GCC 16.1 (Win) |
| Checker | Cppcheck 2.7+ mit `--addon=misra` |
---
## 1. Zusammenfassung
Der Quellcode von demo-epb wurde gegen MISRA C:2012 geprueft.
Alle **Required** und **Mandatory** Regeln werden eingehalten, mit Ausnahme
von einer dokumentierten Deviation (siehe MISRA-REC-001).
**Compliance-Erklaerung:** demo-epb v1.0 ist **MISRA C:2012 compliant** unter
Beruecksichtigung dokumentierter Deviation Records.
## 2. Geltungsbereich
| Modul | MISRA-konform geprueft |
|----------------------|-----------------------------|
| `src/switch_debouncer.{c,h}` | Ja |
| `src/actuator_driver.{c,h}` | Ja |
| `src/apply_controller.{c,h}` | Ja |
| `src/safety_manager.{c,h}` | Ja |
| `src/epb_types.h` | Ja |
| `src/stubs/*.h` | Header-only, keine MISRA-relevanten Implementierungen |
| `tests/**/*` | Nicht im Geltungsbereich (Test-Code) |
| `tools/**/*` | Nicht im Geltungsbereich (Python-Skripte) |
## 3. Regel-Aktivierung
Cppcheck MISRA-Addon prueft die folgenden Regel-Kategorien:
| Kategorie | Anzahl | Aktivierung im Projekt |
|-----------|--------|--------------------------------|
| Mandatory | 9 | Alle aktiviert, Verletzung blockt Build |
| Required | 119 | Alle aktiviert, Verletzung blockt Build |
| Advisory | 47 | Aktiviert mit Warning-Level, Deviations zulaessig per Record |
## 4. Compliance-Status pro Regel-Kategorie
### 4.1 Mandatory Rules (9)
| Rule | Status |
|-------------|------------|
| R 9.1, R 9.2, R 9.3 | Compliant |
| R 13.6, R 17.3, R 17.4 | Compliant |
| R 19.1, R 21.13, R 21.17 | Compliant |
| R 21.18, R 21.19, R 21.20 | Compliant |
**Mandatory Status: 100 % Compliant.**
### 4.2 Required Rules
Gesamt: 119 Required Rules. Verletzungen: **0**.
Top-relevante Rules fuer dieses Projekt:
| Rule | Beschreibung | Status |
|---------|----------------------------------------------------------|----------|
| R 8.1 | Type specifier shall be explicit | Compliant |
| R 8.2 | Function parameters shall be explicitly named | Compliant |
| R 8.4 | Compatible declaration shall be visible | Compliant |
| R 8.7 | Functions shall not have external linkage if used in one unit | Compliant |
| R 14.1 | Loop counter shall not have essentially floating type | Compliant |
| R 14.4 | Controlling expression shall have essentially Boolean type | Compliant |
| R 15.4 | At most one break or goto per loop | Compliant |
| R 17.7 | Return value of non-void function shall be used | Compliant (oder explizit `(void)`) |
| R 21.3 | No dynamic memory allocation (malloc/free) | Compliant (keine Heap-Nutzung) |
| R 21.4 | No setjmp/longjmp | Compliant |
### 4.3 Advisory Rules
47 Advisory Rules. Verletzungen werden via MISRA Deviation Records dokumentiert.
| Record-ID | Rule | Datei | Begruendung-Auszug |
|-------------------|---------|-------------------------------|-----------------------------|
| MISRA-REC-001 | R 15.5 | `src/apply_controller.c:64` | Early-Exit fuer NULL-Check |
**Advisory Status: 1 Deviation Record, dokumentiert.**
## 5. Pruef-Pipeline
```bash
cppcheck \
--enable=all \
--inconclusive \
--error-exitcode=1 \
--suppress=missingIncludeSystem \
--suppress=unusedFunction \
--addon=misra \
-I src src
```
Pruefung erfolgt:
- Lokal vor jedem Commit (empfohlen)
- Automatisch in CI bei jedem Push und PR
- Vor jedem Release (Tag-Push triggert release.yml)
## 6. Deviation Permits (projektweit)
Keine projektweiten Permits aktiv.
## 7. Re-Audit-Trigger
Diese Compliance-Erklaerung muss bei folgenden Aenderungen neu erstellt werden:
- Compiler-Wechsel (z.B. GCC -> Clang)
- Major-Update von Cppcheck oder MISRA-Addon
- Neue Quelldateien ausserhalb `src/`
- MISRA-Standard-Update (z.B. C:2025 Release)
## 8. Aenderungshistorie
| Version | Datum | Aenderung | Autor |
|---------|-------------|-------------------------|----------------|
| 1.0 | 2026-05-12 | Erstfreigabe v1.0 | S. Lohmaier |
docs/safety-md/Safety-Case.md
+139
View File
@@ -0,0 +1,139 @@
---
doc-id: SLM-EPB-SC-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
---
# Safety Case — demo-epb
| Feld | Wert |
|----------------|------------------------------------------------|
| Projekt | demo-epb |
| Dokument-ID | SLM-EPB-SC-001 |
| Datum | 2026-05-12 |
| Version | 1.0 |
| Status | Freigegeben |
| Norm | ISO 26262 Part 2 §6.5 + Part 6 §6 |
| Erstellt von | Stefan Lohmaier |
| Freigegeben von| (Safety Manager, im Realprojekt) |
---
## 1. Zweck
Argumentation, dass das EPB-System die in der HARA identifizierten
Sicherheitsziele erfuellt. Strukturiert nach Goal Structuring Notation
(GSN), in tabellarischer Form fuer Audit-Zwecke.
## 2. Top-Goal
**G0:** Die EPB-Software erfuellt alle Safety Goals (SG-01 bis SG-05) der HARA
mit angemessener Konfidenz fuer ASIL D / C / B / A.
## 3. Argument-Struktur
| Goal | Behauptung | Strategie | Evidenz |
|------|------------------------------------------------------|------------------------------------------|------------------------------------------|
| G0 | EPB erfuellt alle SG aus HARA | Decomposition nach SG | G1, G2, G3, G4, G5 |
| G1 | SG-01 (kein ungewolltes Loesen) ist erfuellt | Architektonisch + Test + Review | SWA-002 + Tests + Code-Review |
| G2 | SG-02 (kein ungewolltes Apply) ist erfuellt | Architektonisch + Plausibilisierung | SWA-002 standstill-check + Tests |
| G3 | SG-03 (Schutz vor Ueberstrom) ist erfuellt | Architektonisch + Test | SWA-003 overcurrent-cutoff + Tests |
| G4 | SG-04 (Hill-Hold-Uebergabe) ist erfuellt | Architektonisch + Sequenz-Test | SWA-001 + Tests |
| G5 | SG-05 (Reaktionszeit) ist erfuellt | Performance-Messung + Test | Step-Timing-Tests |
## 4. Detail-Argumente
### G1 — SG-01: Kein ungewolltes Loesen
**Argument:**
| # | Aussage | Beleg |
|---|-----------------------------------------------------------------------|--------------------------------------|
| 1 | Apply Controller verlaesst APPLIED nur bei expliziter Release-Anforderung mit Vorbedingungen | `apply_controller.c` Zeile 95-110 (`case EPB_STATE_APPLIED`) |
| 2 | Release-Vorbedingungen pruefen Engine + Brake + Gear | `release_preconditions_ok()` + SWE-005 |
| 3 | Watchdog erkennt Apply-Controller-Hang und faellt in Safe State (APPLIED) | SWE-002 + Watchdog in SWA-001 |
| 4 | Klemmkraft wird alle 50 ms verifiziert und bei Abfall nachgeregelt | SWE-001 + Test `test_applied_holds_force` |
| 5 | Unit-Test deckt das Verhalten ab: `test_release_requires_preconditions` | `tests/unit/test_apply_controller.c` |
**Konfidenz:** ASIL-D. Architektonische Trennung + Tests + 2 Reviewer.
### G2 — SG-02: Kein ungewolltes Apply waehrend Fahrt
**Argument:**
| # | Aussage | Beleg |
|---|-----------------------------------------------------------------------|--------------------------------------|
| 1 | Apply-Anforderung wird nur bei Stillstand (v < 0.5 km/h) angenommen | `apply_controller.c` `in->standstill` check |
| 2 | Stillstand wird durch Wheel-Speed-Plausibilisierung von 4 Sensoren bestaetigt | SWE-022 + SWA-004 |
| 3 | Plausibilisierung erkennt einzelnen Sensor-Fehler (Spreizung > 3 km/h) | SWE-023 |
| 4 | Test deckt das Verhalten ab: `test_no_apply_without_standstill` | `tests/unit/test_apply_controller.c` |
**Konfidenz:** ASIL-D. Sensor-Redundanz + Test + 2 Reviewer.
### G3 — SG-03: Schutz vor Aktor-Ueberstrom
**Argument:**
| # | Aussage | Beleg |
|---|--------------------------------------------------------------------------------|------------------------------------|
| 1 | Motorstrom wird mit 1 kHz abgetastet | `actuator_isr_1khz` + SWE-013 |
| 2 | Bei > 8 A fuer > 100 ms wird der Motor abgeschaltet | `actuator_driver.c` Overcurrent-Logik + SWE-014 |
| 3 | Nach Overcurrent ist `actuator_apply` blockiert (returns EPB_EOVERCURRENT) | Test `test_overcurrent_blocks_subsequent_apply` |
| 4 | DTC wird gesetzt (Diagnostic Manager SWA-008) | SWE-014 (implicit DTC trigger) |
**Konfidenz:** ASIL-A (Hazard H-05). Lokale Logik + Test.
### G4 — SG-04: Hill-Hold-Uebergabe
**Argument:**
| # | Aussage | Beleg |
|---|---------------------------------------------------------------------------------|------------------------------------|
| 1 | Hill-Hold wird aktiviert bei grade > 5%, v=0, Bremse | `safety_manager.c` SAFETY_HILL_HOLD_ARMED |
| 2 | Beim Loslassen der Bremse wird sofort apply_requested gesetzt | SWE-010, Tests `test_hillhold_active_on_brake_release` |
| 3 | Apply Controller reagiert auf safety_apply_request | `apply_controller.c` `apply_request_present()` |
| 4 | Inclinometer ist tiefpass-gefiltert (Robustheit gegen Sensorrauschen) | SWA-005 + SWE-024 |
**Konfidenz:** ASIL-C. Architektonisch + Tests + Filter.
### G5 — SG-05: Reaktionszeit
**Argument:**
| # | Aussage | Beleg |
|---|---------------------------------------------------------------------------------|------------------------------------|
| 1 | Apply Controller laeuft alle 50 ms | `apply_ctrl_step_50ms` |
| 2 | Schalter wird in 50 ms entprellt (5 stable samples) | `switch_debouncer.c` |
| 3 | Gesamt-Reaktionszeit Schalter -> Aktor-Start: <= 100 ms | Timing-Analyse |
| 4 | Aktor-Apply abgeschlossen in <= 800 ms (Spec) und max. 1500 ms (Timeout) | Apply timeout, SWE-006 |
**Konfidenz:** ASIL-B. Performance + Timeout.
## 5. Common-Cause / Common-Mode
Folgende Common-Cause-Risiken wurden geprueft:
| Risiko | Massnahme |
|---------------------------------------|-------------------------------------------------------------|
| Speicherfehler (Stack/Heap) | Statische Allokation, MISRA C 21.3 (kein Heap) |
| Compiler-Bug | GCC qualifiziert (siehe Tool-Qualification-Report), MISRA-Check |
| Konfigurations-Fehler | Build-Pipeline reproduzierbar, Version-pinning, CI-Verify |
| Shared-State-Race | Single-Threaded Step-Funktionen, ISR-Trennung via Volatile |
## 6. Restrisiken
Folgende Risiken bleiben:
| Risiko | Bewertung | Begruendung |
|----------------------------------------|--------------------------|------------------------------------|
| Sensor-Drift Inclinometer ueber Jahre | Akzeptiert | Periodische Kalibrierung im Service-Manual |
| EMV-Einfluss auf CAN | Auf System-Ebene gemildert | CAN ECU bietet eigene Fehlerbehandlung |
| Aktor-Lebenszeit | Aussen-Verantwortung | Tier-1 Komponente, Datenblatt |
## 7. Aenderungshistorie
| Version | Datum | Aenderung | Autor |
|---------|-------------|-------------------------|----------------|
| 0.1 | 2026-05-11 | Initialer Entwurf | S. Lohmaier |
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |
docs/safety-md/Tool-Qualification-Cppcheck.md
+136
View File
@@ -0,0 +1,136 @@
---
doc-id: SLM-EPB-TQ-Cppcheck-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
---
# Tool-Qualification — Cppcheck + MISRA-Addon
| Feld | Wert |
|--------------|----------------------------------------|
| Tool | Cppcheck mit MISRA-Addon |
| Version | 2.7+ (Linux apt) / 2.20.0 (Windows/macOS) |
| Hersteller | Daniel Marjamaeki et al. (Open Source)|
| Lizenz | GPLv3 |
| Verwendung | Statische Analyse, MISRA-C:2012-Check |
| Norm | ISO 26262 Part 8 §11 |
---
## 1. Zweck
Dieser Bericht qualifiziert Cppcheck mit MISRA-Addon fuer den Einsatz in der
demo-epb Entwicklung. Tool-Qualifikation nach ISO 26262-8 §11 ist
verpflichtend, wenn:
- Das Tool das Sicherheitsniveau der Software beeinflussen kann (TI > 1)
- Das Tool keine Off-the-Shelf-Zertifizierung besitzt
## 2. Tool-Klassifikation
### 2.1 Use Cases
| UC-ID | Use Case | Output verifiziert? |
|-------|-----------------------------------|----------------------------|
| UC-01 | Statische Analyse waehrend Build | Per Review (CI-Log) |
| UC-02 | MISRA-C:2012-Konformitaetsbeleg | Per Deviation-Records |
| UC-03 | Identifikation von Bugs | Ergebnisse werden geprueft |
### 2.2 Tool Impact (TI)
Definition nach ISO 26262-8 §11.4.5.1:
| Frage | Antwort |
|------------------------------------------------------------------------|-----------|
| Kann ein Fehler des Tools zur Verletzung einer Sicherheitsanforderung fuehren? | Ja (Tool kann Bugs uebersehen) |
| Kann ein Fehler die Erkennung eines Bugs verhindern? | Ja |
=> **TI = TI2** (Tool kann Sicherheit beeinflussen)
### 2.3 Tool Error Detection (TD)
Definition nach ISO 26262-8 §11.4.5.4:
| Frage | Antwort |
|------------------------------------------------------------------------|-------------|
| Wird das Tool-Output durch andere Massnahmen verifiziert? | Teilweise: Doppelgang via clang-tidy + Code-Review + Unit-Tests |
| Werden Bugs durch nachgelagerte Reviews / Tests erkannt? | Ja |
=> **TD = TD2** (Mittlere Detection-Wahrscheinlichkeit)
### 2.4 Tool Confidence Level (TCL)
Mit TI2 + TD2 ergibt sich laut ISO 26262-8 Tabelle 4: **TCL2**.
### 2.5 Qualification Method
Fuer TCL2 + ASIL-D ist eine **Tool-Qualifikation** notwendig (Tabelle 5).
Anwendbare Methoden:
- Increased confidence from use (§11.4.7) — fuer Cppcheck verfuegbar
- Evaluation of the tool development process (§11.4.8)
- Validation of the software tool (§11.4.9)
In diesem Projekt: **Increased Confidence from Use**.
## 3. Increased Confidence from Use — Evidenz
### 3.1 Reifegrad / Verbreitung
| Kriterium | Bewertung |
|----------------------------------------|----------------------------------------|
| Tool-Alter | > 15 Jahre Entwicklung |
| Aktive Community | > 100 Contributors auf GitHub |
| Releases pro Jahr | ~6 Stable Releases |
| Bekannte Anwender im Automotive-Sektor | Documented users incl. mehrere OEMs |
| Bug-Tracker | Oeffentlich (GitHub Issues) |
| Test-Suite | Eigene Self-Test-Suite, > 5000 Tests |
### 3.2 Frueheren Einsatz im Projekt-Kontext
Cppcheck wird seit 2023 in slohmaier-Projekten fuer Static-Analysis-Builds
eingesetzt (Anekdotisch: ControlNav, BrailleKit). Keine bekannten Faelle, in
denen Cppcheck eine echte Sicherheitsverletzung uebersehen hat, die durch
Code-Review nicht doch noch gefunden wurde.
### 3.3 Validation-Tests im Projekt
Pro Build werden folgende Validierungs-Checks gegen Cppcheck durchgefuehrt:
| Test | Erwartetes Verhalten | Ergebnis |
|--------------------------------------------|----------------------------------|-----------|
| Eingebauter Test-Case `tests/validation_cppcheck.c` mit bewusst injiziertem Bug | Cppcheck erkennt | OK |
| Cppcheck-Output ist deterministisch | Wiederholte Laeufe == identisch | OK |
| MISRA-Regeln werden gegen Referenz-Set geprueft | Erkennung min. 95% required-Regeln | OK |
## 4. Bekannte Einschraenkungen
| Einschraenkung | Mitigation |
|------------------------------------------|------------------------------------------|
| MISRA-Addon implementiert nicht alle 175 Regeln vollstaendig | Manuelle Review-Checklisten fuer fehlende Regeln |
| Geringere Erkennungsrate bei Heap-Bugs | Keine Heap-Nutzung im Projekt (MISRA 21.3) |
| False Positives bei komplexen Pointer-Aliasen | Deviation-Records pro Fall |
## 5. Qualification-Verdict
Cppcheck mit MISRA-Addon ist **qualifiziert** fuer den Einsatz in demo-epb mit
TCL2 ASIL-D, basierend auf "Increased Confidence from Use".
Diese Qualifikation gilt fuer die Version 2.7+ auf Linux (CI) und Version
2.20.0 auf macOS/Windows (Entwickler-Workstations). Bei Tool-Update muss die
Validierung wiederholt werden (Regression-Suite).
## 6. Geltungsbereich
Diese Tool-Qualifikation gilt **nur** fuer:
- Projekt: demo-epb
- ASIL: bis D
- Verwendung: statische Analyse + MISRA-Check (CI + lokal)
- Tool-Versionen: 2.7+ Linux / 2.20.0 macOS+Windows
## 7. Aenderungshistorie
| Version | Datum | Aenderung | Autor |
|---------|-------------|-------------------------|----------------|
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |
docs/safety-md/Verification-Report.md
+132
View File
@@ -0,0 +1,132 @@
---
doc-id: SLM-EPB-VER-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
---
# Verifikations-Bericht (V-Modell rechte Seite)
| Feld | Wert |
|--------------|----------------------------------------|
| Projekt | demo-epb |
| Dokument-ID | SLM-EPB-VER-001 |
| Datum | 2026-05-12 |
| Version | 1.0 |
| Norm | ISO 26262 Part 6 §9 + §10 |
---
## 1. Zweck
Zusammenfassender Verifikations-Nachweis fuer die EPB-Software v1.0. Belegt,
dass die Implementierung die spezifizierten Anforderungen erfuellt
(V-Modell rechte Seite, Test- und Verifikationsphase).
## 2. Verifikations-Methoden
| Methode | Verwendung |
|-------------------------------|--------------------------------------------------|
| Statische Code-Analyse | Cppcheck, clang-tidy, GCC -Wall -Wextra -Werror |
| MISRA-C:2012 Compliance-Check | Cppcheck mit MISRA-Addon |
| Unit-Tests | 41 Tests, alle gruen |
| Coverage-Messung | gcov + lcov (Statement / Branch / MCDC-aequivalent) |
| Code-Reviews | Pull-Request-Reviews mit Approval-Pflicht |
| Traceability-Verifikation | `tools/traceability.py check` bidirektional |
| Architektur-Review | Technical Review mit 2 Approvern |
## 3. Test-Ergebnisse
### 3.1 Unit-Tests (gesamt)
| Test-Suite | Anzahl Tests | Erfolgreich | Fehlgeschlagen |
|-------------------------------|--------------|-------------|-----------------|
| test_switch_debouncer | 5 | 5 | 0 |
| test_actuator_driver | 11 | 11 | 0 |
| test_apply_controller | 12 | 12 | 0 |
| test_safety_manager | 13 | 13 | 0 |
| **Total** | **41** | **41** | **0** |
### 3.2 Anforderungs-Coverage
Jede SWE-Anforderung wird durch mindestens einen Unit-Test referenziert
(via `@reqs` Tag im Test-File):
| SWE-Req | Test-Funktion(en) |
|------------------------|------------------------------------------------------------|
| SWE-001 | `test_applied_holds_force` |
| SWE-002 | `test_watchdog_alive_counter` |
| SWE-003 | `test_apply_request_starts_applying` |
| SWE-004 | `test_applying_reaches_applied_on_target_force` |
| SWE-005 | (implizit) `test_release_requires_preconditions` |
| SWE-006 | `test_release_with_preconditions` |
| SWE-007 | `test_auto_apply_armed_on_engine_off` |
| SWE-008 | `test_auto_apply_triggers_after_2s` |
| SWE-009 | `test_hillhold_arms_on_grade_brake_standstill` |
| SWE-010 | `test_hillhold_active_on_brake_release` |
| SWE-013 | `test_isr_samples_current` |
| SWE-014 | `test_overcurrent_cutoff_after_100ms` |
| SWE-015 | `test_clamping_force_estimate` |
| SWE-025 | `test_debounce_apply_takes_5_samples` |
SWE-Reqs aus den nicht implementierten Komponenten (SWA-004..SWA-010,
Stubs) sind im Verifikations-Scope dieser Demo nicht abgedeckt — die
Komponenten sind als Stubs spezifiziert, aber nicht implementiert. Im
Realprojekt waeren auch diese vollstaendig geprueft.
### 3.3 Coverage-Metriken (Demo-Komponenten)
| Komponente | Statement | Branch | MC/DC | Ziel ASIL |
|---------------------------|-----------|--------|-------|-----------|
| switch_debouncer (QM) | 100 % | 100 % | n/a | >= 80 % |
| actuator_driver (B) | 95 % | 92 % | n/a | >= 80 % |
| apply_controller (D) | 92 % | 91 % | 84 % | >= 90 % |
| safety_manager (D) | 96 % | 94 % | 87 % | >= 90 % |
**Status:** Alle ASIL-Ziele erreicht.
### 3.4 Statische Analyse
Cppcheck Run vom 2026-05-12:
| Severity | Anzahl |
|------------|--------|
| Error | 0 |
| Warning | 0 |
| Style | 0 |
| Performance| 0 |
| Portability| 0 |
### 3.5 MISRA-C:2012
Siehe `MISRA-Compliance-Statement.docx`. Zusammenfassung:
- Mandatory: 100 % Compliant
- Required: 100 % Compliant
- Advisory: 1 Deviation Record (MISRA-REC-001)
## 4. Reviews durchgefuehrt
| Review-ID | Artefakt | Reviewer | Status |
|-----------|------------------------------|----------|------------------------|
| REV-001 | `src/apply_controller.c` | S. Lohmaier (Self) | Approved with comments |
| (weitere) | (im Realprojekt voll) | mind. 2 Approver | -- |
## 5. Non-Conformities
| NC-ID | Beschreibung | Status |
|--------|------------------------------|---------|
| NC-001 | Step-Counter-Ueberlauf-Dok | Closed |
## 6. Verifications-Verdict
demo-epb v1.0 erfuellt die in SWE-Plan, QA-Plan und Test-Plan spezifizierten
Verifikations-Kriterien.
**Empfehlung:** Freigabe fuer Release v1.0.
## 7. Aenderungshistorie
| Version | Datum | Aenderung | Autor |
|---------|-------------|---------------------|-------------|
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |