# 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.*