Files
dev-process/templates/MISRA-Deviation-Permit-template.md
T
Stefan Lohmaier 247b8311f3 refactor(i18n): rename vorlagen/ -> templates/, *-vorlage -> *-template
Final German naming cleanup in dev-process:
- vorlagen/                            -> templates/
- vorlagen-word/                       -> templates-word/
- tools/generate_word_vorlagen.sh      -> tools/generate_word_templates.sh
- *-vorlage.md / *-vorlage.docx        -> *-template.md / *-template.docx
- Review-Protokoll-vorlage.*           -> Review-Minutes-template.*
- angebot-vorlage.*                    -> quote-template.*
- angebot-beispiel.html                -> quote-example.html

All references in README.md, toolstack/toolstack.md, build_word_template.py,
and generate_word_templates.sh updated. The master Word style template
(slohmaier-doc-template.docx) was already English-named.

The dev-process repo is now fully English in both content and structure.
2026-05-12 12:09:06 -07:00

3.5 KiB

MISRA Deviation Permit

Field Value
Permit ID PER-[XXX]
Date [YYYY-MM-DD]
Author [Name]

1. Rule

Field Value
Rule number [e.g. Rule 11.3]
Category [Required / Advisory]
Rule text [Exact text of the MISRA rule]
Standard [MISRA C:2012 / MISRA C:2023]

2. Scope

This permit applies to:

Aspect Scope
Code area [e.g. src/hal/*.c — all hardware-abstraction-layer files]
Module / component [e.g. HAL, CAN driver]
Context [e.g. register access to memory-mapped I/O]

Limitation: This permit applies exclusively to the scope defined above. Deviations outside this scope require a separate deviation record or a separate permit.

3. Rationale

[Why is deviation from this rule acceptable in the defined context?]

Example: "Rule 11.3 forbids casts between pointer types. In the HAL, casts from uint32_t* to register structs are necessary because the hardware is accessed via memory-mapped I/O. The register addresses and layouts are defined in the datasheet and are static. A rule-compliant alternative does not exist."

Rationale: [Fill in here]

4. Risk assessment and alternatives

Risk assessment

Aspect Assessment
Safety relevance [None / Low / Medium / High]
Fault potential [Description]
Mitigation [e.g. unit tests verify correct register access, code review required for HAL code]
Residual risk [Assessment]

Alternatives considered

Alternative Assessment
[e.g. generic accessor functions] [e.g. not practical due to hundreds of registers]
[e.g. compiler extension] [e.g. not portable]

5. Approval

Field Value
Approved by [Name, role]
Date [YYYY-MM-DD]
Evidence [Gitea issue / wiki link / signature]

6. Validity

Field Value
Valid from [YYYY-MM-DD]
Valid until [YYYY-MM-DD or "until revoked"]
Revocation trigger [e.g. re-evaluate if the target platform changes]

This permit is stored in the Gitea wiki under MISRA-Deviation-Permits and referenced from deviation records.