MISRA C:2012 深度 — 基线 159 guidelines(143 Rule + 16 Directive)+ 3 级别 + ASIL D 强制 + Deviation 流程

MISRA C 不是"风格建议",而是把一门定义了大量未定义行为的语言,裁成一个"每条违反都能被工具指出"的子集。下图把 3 级别 + 规则分组 + ASIL D 高频陷阱一次说清:

三个必须记牢的数字与观察:

• 基线(2013)= 159 条 = 16 Directive + 143 Rule;其中约 10 条 Mandatory
• 维护版(基线 + AMD1 2016 安全指南 + AMD2 2020 C11/C18)= 175 条,分级 16 Mandatory / 120 Required / 39 Advisory(数据取自工具分类矩阵,如 GrammaTech CodeSonar 7.3)
• Mandatory 是唯一"绝不允许 deviation"的级别;工作量的绝大部分落在 Required,因为它才是"可 deviation 但必须走完整流程"的那一档

ISO 26262-6:2018 §5.4 Table 1「Topics to be covered by modelling and coding guidelines」是一张"编码/建模指南须覆盖哪些主题"的清单,每个主题按 ASIL 标 ++(highly recommended)/ +(recommended)/ o(no recommendation)。MISRA C 对应其中的「use of language subsets」这一主题——注意标准表只按 ASIL A-D 列,不含 QM(QM 无 ASIL 方法要求)。关键几行的分级如下(与本 wiki ISO 26262-6 软件页 Table 1 同源):

也就是说「使用语言子集」在 ASIL A 起就是 ++——它不是 ASIL D 才收紧,而是全等级 highly recommended。标准本身不点名 MISRA,但要求团队选一个"能被证明可降低 systematic fault 频率"的子集,MISRA C 是事实上的默认答案。FSAR / 功能安全评审拒签的 root cause 之一,就是 MISRA 不合规且 deviation 缺 justification。

分级决定了"违反后要付出多少流程代价",这是理解 MISRA 落地成本的第一入口。除了级别,MISRA 还给每条标了两个正交属性:Decidable / Undecidable(工具能否静态判定,§6.5)与 Single Translation Unit / System(单文件可查还是需全局链接期分析,§6.4)——后者决定了增量式 CI 能否覆盖它。

MISRA C:2012 把 guideline 组织成 4 组 Directive + 22 章 Rule(共 26 个分组)。Directive 与 Rule 的本质区别:Rule 只看 C 源码就能判定(可静态检查);Directive 关乎源码之外的信息(需求、编译配置、设计文档),工具只能部分辅助。

电驱控制器(EDU/主逆变器)ASIL D 软件里,以下 5 类违反出现频率最高,且都直接对应一个 systematic 失效模式。

把上面的 Rule 11.x 落到一颗真芯片上。Infineon AURIX TC375(TC3xx 家族,32-bit TriCore,带 lockstep core,ASIL-D ready)的 GPIO 端口是 memory-mapped SFR:Port P00 基址 0xF003A000,其中 OUT 寄存器在偏移 0x00(即 P00_OUT = 0xF003A000,见 AURIX TC3xx User Manual Part 2 · Ports 章)。要点亮一个接在 P00.0 的 LED,必须写这个物理地址——而"把整数地址当指针解引用"正是 Rule 11.4。

裸写法(违反且不可维护):

/* 直接把物理地址 cast 成 volatile 指针 —— 命中 Rule 11.4 (integer->object pointer) */
#define P00_OUT  (*(volatile uint32_t *)0xF003A000u)

void led_on(void)
{
    P00_OUT |= 0x1u;   /* 还顺带命中 Rule 10.x essential-type: 0x1u 与 uint32_t 混算 */
}

工程做法:把这唯一一处 cast 收敛进 vendor 层(AURIX iLLD 的 MODULE_P00 宏本身就是 (*(Ifx_P *)0xF003A000u)),业务代码只调 IfxPort_setPinState(&MODULE_P00, 0, IfxPort_State_high),不再自己 cast。对 iLLD header 里那一处 cast 写一条集中 deviation:

/* deviation 锚点:寄存器基址必须由硬件手册固定,无法用 MISRA-conforming 写法表达 */
/* PRQA S 0303 1  // Helix QAC 抑制 Rule 11.4，关联 deviation record DVR-EDU-011 */
#define MODULE_P00  (*(Ifx_P *)0xF003A000u)

对应的 deviation record(MISRA Compliance:2020 字段):

这条 worked design 说明 MISRA 落地的核心不是"消灭所有违反",而是把不可避免的违反收敛到最小面、一次性论证、可追溯。

Deviation 不是"随手加个注释抑制告警",而是 MISRA Compliance:2020 定义的正式产物。每条 Required 违反走 5 步:

1. 识别违反 — 静态分析工具输出(Polyspace / Helix QAC / LDRA)
2. 写 deviation record — 规则 ID + category + justification + 替代方案 + 风险评估(字段见 §6)
3. 独立评审 — Safety Engineer + Architecture Lead(maker≠checker,提出人不能自评)
4. 批准 — Safety Manager 签字
5. 记录与追溯 — Polarion / DOORS deviation list,安全案例与 FSAR 必引用

MISRA Compliance:2020 还定义了三个关键状态与两份产物,评审时常被查:

• Compliant / Deviation / Disapplied:一条 guideline 要么合规,要么有已批准 deviation,要么在项目里被正式 disapplied(仅少数、需论证)
• Guideline Enforcement Plan(GEP):声明每条 guideline 由哪个工具/复核环节强制,以及 Advisory 是否重定级
• Guideline Compliance Summary(GCS):全项目逐条合规状态汇总,是"我们确实 MISRA 合规"的顶层证据

Justification 通常归 4 类:Hardware(寄存器访问)/ Performance(如 inline asm)/ Legacy/Third-party(既有库)/ Tool limitation(工具误报)。

Polyspace 是主驱线常见的 MISRA + 形式化组合(Bug Finder 快扫 + Code Prover 证明)。启用 MISRA C:2012 检查:

% Polyspace Bug Finder —— 启 MISRA C:2012 全集
proj = polyspace.Project;
proj.Configuration.CodingRulesCodeMetrics.EnableMisraC3 = true;
proj.Configuration.CodingRulesCodeMetrics.MisraC3Subset = 'all';   % all / mandatory-required / SQO-subset

报告与 CI 集成两点:

• 报告:HTML/PDF 输出,按规则 + 文件分类;deviation 用源码内注释(polyspace-comment / PRQA S)锚定并关联 record ID
• CI/CD:Jenkins / GitLab CI 每 PR 跑增量分析;Mandatory 违反直接 build fail,Required 违反除非有已批准 deviation 否则 fail;Advisory 按项目 GEP 决定阻断与否

主驱线常见三家工具各有定位。价格不公开(均为按 seat/项目谈判、六位数美元量级),故这里只比能力定位而不写虚假报价:

国产替代现状(去掉具体料号/报价以免误导):国产静态分析工具正在补 ISO 26262 工具链认证,但截至 2025 EV 主驱 ASIL D 仍以 Polyspace / LDRA / Coverity 为主。任何工具(含国产)进 ASIL D 工具链,都要先按 ISO 26262-8:2018 §11 做 tool qualification(TCL 评估 + TVS/output comparison),否则其 MISRA 结论不能作为合规证据——这才是国产工具进主驱链的真正门槛,而非功能覆盖率。

评审前对照这 5 项自查,任何一项缺失都是 FSAR 拒签风险:

• Mandatory 100% 通过 — 零 violation,无 deviation 通道
• Required 100% 处理 — 要么合规,要么有已批准 deviation record(含独立评审签字)
• Advisory 按 GEP 处理 — 选择性采纳/重定级,决定写进 Guideline Enforcement Plan
• Guideline Compliance Summary — 逐条状态汇总产物存在且与工具输出一致
• 可追溯闭环 — deviation list → 安全案例 → FSAR §5 引用完整

MISRA C 的版本关系常被记乱,这里按事实澄清:

• MISRA C:2012(2013):基线 159 条(143 Rule + 16 Directive)
• + Amendment 1(2016):新增 14 条安全指南(13 Rule + Dir 4.14)→ 173 条
• + Amendment 2(2020):支持 C11/C18 core(如新增 Rule 21.21 禁 system())→ 维护版约 175 条
• + Amendment 3 / 4 + TC:补 C90/C99 遗漏与 concurrency(Dir 5.x)
• MISRA C:2023(2023-04,第三版第二修订):把 AMD 与 TC 合并成一册,共 221 条(约 200 Rule + 21 Directive)——与本 wiki software-safety 页口径一致
• MISRA C:2025(2025-03):在 2023 上做策略性增补,共 223 条(22 Mandatory / 153 Required / 47 Advisory / 1 Disapplied,新引入 Disapplied 第 4 态),仍面向 C99/C11/C18,为下一版 C 标准铺路

工程现实:2026 年在跑的 EV 主驱项目多数仍以 MISRA C:2012(含 AMD)为合规基线——因为工具链 qualification、既有 deviation 库、供应商约定都锚在 2012;向 2023/2025 迁移是有计划的动作,不是自动升级。且 ASIL D 主驱通常仍限 C99/C11 保守子集(编译器/工具对 C11 原子与线程支持不齐)。

以下 7 个是评审/交付阶段真正咬人的坑,多数不是"写错代码"而是"合规姿势错"。

1. 把 Rule 1.1 / 2.1 当 Mandatory：二者其实是 Required。误记会让团队对真正的 16 条 Mandatory(9.1/17.4/22.2…)放松 —— 而 Mandatory 才是零容忍、无 deviation 通道的那档。
2. 用注释抑制告警当成 deviation：PRQA S / polyspace-comment 只是"抑制",不等于 deviation record。没有 justification + 独立评审签字 + 追溯,审计一律判 NCR(对齐 software-safety 页 G5)。
3. Advisory 默认忽略：很多 Advisory 在 ASIL D 项目里已被 GEP 升为 Required(如 11.4)。不查 GEP 就按"Advisory 可不管"处理,交付时集中爆雷。
4. Undecidable 规则指望工具 100% 查全：如 Rule 9.1(读前未写)是 Undecidable,静态工具只能保守报,漏报/误报都有;需靠设计约束 + 复核,不能把"工具没报"当"合规证明"。
5. System 级规则漏在增量 CI：跨翻译单元的规则(Single Translation Unit vs System 属性)在只跑单文件增量分析时查不到,必须周期性跑全量链接期分析补齐。
6. non-volatile 寄存器/双检被编译器优化掉:寄存器映射漏 volatile,或安全双重检查的中间变量非 volatile,被 CSE 合并——MISRA 不直接报,但破坏 safety 意图(与 software-safety 页 G2 同源)。
7. essential type 混算悄悄改变符号/宽度:Rule 10.x 体系下,uint8_t 与带符号字面量混算会隐式提升,位运算结果符号位翻转;工具会报 10.x,但工程师常误 deviation 掉,埋下数值 bug。

三个"规则字面通过但工程语义存疑"的边界,评审时值得单独盯。

• Disapplied 的滥用：MISRA Compliance:2020 允许把某条 guideline 在项目里正式 disapplied(如某平台确无该风险)。边界在于:disapplied 需与 deviation 同等论证并进 GCS,若被当"批量关规则"的捷径用,等于悄悄缩小了 subset——评审要核每条 disapplied 的理由。
• 自动生成代码的类别切换:MISRA C:2012 Appendix E 指出,部分 guideline 对自动生成代码(Simulink/Embedded Coder + MISRA AC)的 category 与手写不同。混合工程里同一条规则在手写模块和生成模块判定级别不一致,合规矩阵必须分别标注,否则统计口径打架。
• Mandatory 与硬件/编译器现实冲突:极少数情况下 Mandatory 的字面要求与某 target 的必要写法冲突(如特殊 startup 代码)。因为 Mandatory 无 deviation 通道,唯一合规出路是把该片段隔离到非 MISRA 声明的边界(如汇编/受控封装)并在 Dir 1.1 记录,而不是硬写 deviation——写了也不被接受。

MISRA C:2012 = ASIL D 软件强制门票 — 基线 159 条(143 Rule + 16 Directive),含 AMD1/2 维护版 175 条,分级 16 Mandatory(绝不 deviation)/ 120 Required(须完整 deviation 流程)/ 39 Advisory(GEP 可重定级)。ISO 26262-6 Table 1「use of language subsets」在 ASIL A-D 全 ++。5 大陷阱:Rule 11.x cast(寄存器,见 AURIX TC375 worked design)/ Rule 21.3+Dir 4.12 动态内存 / Rule 17.2 递归 / Rule 18.1 越界 / Rule 16.4 switch default。主流工具 Polyspace(Bug Finder + Code Prover)/ LDRA / Coverity + CI 阻断 + deviation record(MISRA Compliance:2020)闭环 → FSAR §5。别记错:Rule 1.1/2.1 是 Required 不是 Mandatory;下一版是 MISRA C:2023(221)/ 2025(223) 而非"2025 加 C11"。