Files
dev-process/vorlagen/MISRA-Deviation-Permit-vorlage.md
T
Stefan Lohmaier 6e458ae76f Initial commit: slohmaier Dev Process v1.0
ASPICE 4.0 / ISO 26262 Entwicklungsprozess fuer kleine Teams.

Inhalte:
- README mit hybrider Format-Strategie (Word + Markdown)
- Toolstack (Gitea, Doorstop, Cppcheck, gcov, CppUTest, pandoc)
- Markdown-Vorlagen fuer Requirements + Architektur (SA, SWA)
- Markdown-Vorlagen fuer formelle Dokumente (PID, PM-Plan, QA-Plan,
  SWE-Plan, Test-Plan, Reviews, Non-Conformity, MISRA Permits/Records)
- Word-Master-Template (slohmaier-doc-template.docx) mit ISO-9001-
  konformer Document Control, Formatvorlagen, Auto-Verzeichnissen
- Build-Scripts (build_word_template.py, generate_word_vorlagen.sh)
- gitea-aspice-setup.md, V-Modell-Infografik
2026-05-11 13:40:51 -07:00

3.6 KiB

MISRA Deviation Permit

Feld Wert
Permit-ID PER-[XXX]
Datum [YYYY-MM-DD]
Erstellt von [Name]

1. Regelbereich

Feld Wert
Regel-Nummer [z.B. Rule 11.3]
Kategorie [Required / Advisory]
Regeltext [Exakter Text der MISRA-Regel]
Standard [MISRA C:2012 / MISRA C:2023]

2. Scope

Dieses Permit gilt fuer:

Aspekt Geltungsbereich
Code-Bereich [z.B. src/hal/*.c — alle Hardware-Abstraction-Layer Dateien]
Modul / Komponente [z.B. HAL, CAN-Treiber]
Kontext [z.B. Register-Zugriffe auf Memory-Mapped I/O]

Einschraenkung: Dieses Permit gilt ausschliesslich fuer den oben definierten Scope. Abweichungen ausserhalb dieses Bereichs erfordern einen eigenen Deviation Record oder ein separates Permit.

3. Begruendung

[Warum ist die Abweichung von dieser Regel im definierten Kontext vertretbar?]

Beispiel: "Rule 11.3 verbietet Casts zwischen Pointer-Typen. Im HAL sind Casts von uint32_t* auf Register-Structs notwendig, da die Hardware ueber Memory-Mapped I/O angesprochen wird. Die Register-Adressen und Layouts sind durch das Datenblatt definiert und statisch. Eine regelkonforme Alternative existiert nicht."

Begruendung: [Hier ausfuellen]

4. Risikobewertung und Alternativen

Risikobewertung

Aspekt Bewertung
Sicherheitsrelevanz [Keine / Gering / Mittel / Hoch]
Fehlerpotenzial [Beschreibung]
Absicherung [z.B. Unit Tests pruefen korrekte Register-Zugriffe, Code Review Pflicht fuer HAL-Code]
Restrisiko [Bewertung]

Geprufte Alternativen

Alternative Bewertung
[z.B. Generische Zugriffsfunktionen] [z.B. Nicht praktikabel, da hunderte Register]
[z.B. Compiler-Erweiterung] [z.B. Nicht portabel]

5. Freigabe

Feld Wert
Freigegeben von [Name, Rolle]
Datum [YYYY-MM-DD]
Nachweis [GitLab-Issue / Wiki-Verweis / Unterschrift]

6. Gueltigkeit

Feld Wert
Gueltig ab [YYYY-MM-DD]
Gueltig bis [YYYY-MM-DD oder "bis auf Widerruf"]
Widerrufsbedingung [z.B. Bei Aenderung der Zielplattform neu bewerten]

Dieses Permit wird im GitLab-Wiki unter MISRA-Deviation-Permits abgelegt und aus Deviation Records referenziert.