2. 合规性基础：MISRA C合规等级、偏差许可与合规声明

好，咱们进入第二章。这一章讲的是MISRA C的“游戏规则”——合规等级、偏差怎么申请、合规声明怎么写。说白了，就是告诉你什么必须改、什么可以商量、最后怎么交差。

我在好几个项目里都见过这种情况：团队花了大半年改代码，最后客户问“你们的合规声明呢？”结果拿不出来，或者写得不规范，又得返工。所以这块内容，我建议你一开始就搞清楚。

2.1 合规等级：Required 与 Advisory

MISRA C的规则分两个等级：Required（强制）和 Advisory（建议）。

很多人以为Advisory就可以不管，其实不是。我见过一个项目，团队觉得“建议嘛，不一定要做”，结果客户审计时一条条对，所有Advisory违规都被列成了观察项，最后整改花了两周。

等级	含义	合规要求	我的经验
Required	必须遵守	无偏差即违规	这是硬杠杠，没商量
Advisory	建议遵守	不遵守需说明理由	最好也遵守，省得审计麻烦

举个例子。规则10.1（Required）说“不得对布尔类型进行算术运算”，这没得商量，写了就改。规则11.5（Advisory）说“建议不要将指针转换为非整型”，如果你确实需要这么做，可以在合规声明里说明“因为硬件寄存器映射需要”。

2.2 偏差许可（Deviation）流程

偏差许可，说白了就是“我确实违反了规则，但我有充分理由”。

我曾经在一个航空项目中遇到一个情况：某个底层驱动必须用指针类型转换来访问硬件寄存器，这违反了规则11.5。我们走了一遍偏差流程，花了三天准备材料，最后客户批准了。

偏差流程一般分这几步：

1. 识别违规——静态分析工具跑一遍，找出所有违规点
2. 评估影响——这个违规会不会导致安全问题？有没有替代方案？
3. 编写偏差申请——写明规则编号、违规位置、理由、风险分析
4. 审批——通常是项目技术负责人或安全经理签字
5. 记录归档——偏差申请要纳入项目文档，供审计查阅

我建议你建立一个偏差登记表，记录每个偏差的详细信息。格式可以参考下面这样：

偏差ID	规则编号	文件/行号	理由	审批人	状态
DEV-001	11.5	drv_uart.c:127	硬件寄存器映射需要	张三	已批准
DEV-002	14.3	task_sched.c:89	性能优化，无安全影响	李四	待审批

2.3 合规声明（Compliance Statement）的撰写

合规声明是整个合规工作的“成绩单”。客户、审计方、认证机构看的最后交付物就是这个。

我记得第一次写合规声明时，以为就是把工具报告附上去就行。结果客户退回来说：“你们有没有逐条说明每个规则的合规情况？”从那以后，我每次写合规声明都按下面这个模板来。

一份完整的合规声明应该包含：

• 项目信息——项目名称、版本、日期
• MISRA C版本——比如MISRA C:2012
• 合规等级声明——声明项目达到了哪个等级的合规
• 规则合规清单——逐条列出所有规则的状态（合规/偏差/不适用）
• 偏差清单——所有已批准的偏差及其理由
• 工具信息——使用的静态分析工具及其版本
• 签名——技术负责人和项目经理的签字

下面是一个合规声明的示例片段：

合规声明

项目名称：车载ECU控制软件 v2.3
MISRA C版本：MISRA C:2012
合规等级：Required规则100%合规，Advisory规则99%合规

规则合规清单（节选）：
| 规则编号 | 等级     | 状态   | 备注                     |
|----------|----------|--------|--------------------------|
| 1.1      | Required | 合规   |                          |
| 1.2      | Advisory | 合规   |                          |
| 2.1      | Required | 偏差   | DEV-001，硬件寄存器映射  |
| 2.2      | Required | 不适用 | 项目不使用汇编代码       |

偏差清单：见附件A
工具信息：PC-lint Plus v2.1
签名：_________________ 日期：2024-03-15

2.4 知识结构图

下面这张图把本章的核心逻辑串起来了。你可以看到，从规则等级出发，到偏差流程，最后落到合规声明，是一条完整的链路。

2.5 避坑指南

最后，分享几个我踩过的坑：

• 别把Advisory当空气——审计时Advisory违规也会被记录，积少成多会影响整体评价
• 偏差理由别写“为了性能”——这种理由太笼统，审计方会追问“具体什么性能？有没有数据支撑？”
• 合规声明别拖到最后写——我见过一个项目，代码改完了才想起写声明，结果发现偏差记录不全，又花了两周补材料
• 工具报告不能替代合规声明——工具报告是原始数据，合规声明是经过人工审核后的结论，两者都要保留