第3章：引用标准与规范：AUTOSAR、ISO 26262、MISRA C等关键标准的引用方法
做ECU软件架构，最头疼的事之一，就是怎么把这些标准「请」进文档里。
我见过不少团队，文档里写「本设计符合AUTOSAR规范」，结果评审时一问，连AUTOSAR的哪个版本、哪个模块都没说清楚。说白了，这种引用等于没写。
这一章，我就聊聊我的做法。怎么引用标准，才能让评审专家点头，让开发团队不跑偏。
3.1 为什么引用标准要「讲究」？
你想想看，标准不是摆设。它是你和上下游、和客户、和认证机构之间的「共同语言」。
引用标准的目的有三个：
- 明确约束：告诉所有人，你的设计必须遵守哪些规则
- 提供依据：每个设计决策，都能找到标准里的出处
- 方便追溯：评审时，别人能快速定位到标准原文
我在项目中遇到过最尴尬的事，就是评审专家问「你这个安全机制的依据是ISO 26262的哪一条？」我翻遍文档，只写了「符合ISO 26262」，具体哪条没写。结果被要求重写。嗯，从那以后，我再也不敢偷懒了。
3.2 三大核心标准的引用方法
ECU开发绕不开三个标准：AUTOSAR、ISO 26262、MISRA C。我一个个说。
3.2.1 AUTOSAR的引用方法
AUTOSAR是个大框架，版本多、模块多。引用时不能只说「符合AUTOSAR」。我个人习惯，至少写清楚三件事：
- 版本号：比如AUTOSAR 4.4.0、AUTOSAR 4.2.2
- 模块名称：比如OS模块、COM模块、RTE模块
- 具体条款：比如SWS_Os_00012、SRS_Com_00123
正确示例：
本模块的调度策略遵循AUTOSAR 4.4.0规范中OS模块的要求。
具体条款：
- SWS_Os_00012：任务优先级定义
- SWS_Os_00034：时间片轮转机制注意：不要只写「符合AUTOSAR」。AUTOSAR 3.x和4.x差别很大，不写版本号，别人根本不知道你用的是哪个。
3.2.2 ISO 26262的引用方法
ISO 26262是功能安全标准，引用时最忌讳「笼统」。我建议按这个结构来：
| 要素 | 说明 | 示例 |
|---|---|---|
| ASIL等级 | 明确安全目标等级 | ASIL B、ASIL D |
| Part编号 | 引用第几部分 | ISO 26262-6:2018 |
| 条款编号 | 具体到条款 | Table 12、Clause 7.4.3 |
| 安全机制 | 对应的安全措施 | ECC、CRC、Watchdog |
举个例子，我在写某个安全监控模块时，文档里是这样写的：
本模块的安全机制依据ISO 26262-6:2018 Table 12的要求设计。
ASIL等级：ASIL C
具体措施：
- 采用双核锁步（DCLS）架构，满足Clause 7.4.3的冗余要求
- 每100ms执行一次自检，满足Clause 8.2.1的故障检测时间要求为什么要这么细？因为认证审核时，审核员会拿着你的文档，一条一条去对标准原文。你写不清楚，他就认为你没做到。
3.2.3 MISRA C的引用方法
MISRA C是编码规范，引用时重点在于「规则编号」和「偏离说明」。
我建议在文档中单独列一个表格，记录所有引用的MISRA规则：
| 规则编号 | 规则描述 | 遵守情况 | 偏离说明 |
|---|---|---|---|
| Rule 10.1 | 不允许对浮点类型进行位操作 | 遵守 | 无偏离 |
| Rule 14.3 | 控制表达式必须为布尔类型 | 遵守 | 无偏离 |
| Rule 18.4 | 不允许使用动态内存分配 | 部分遵守 | 启动时使用一次malloc，已通过安全评审 |
我的经验：MISRA C的偏离说明一定要写清楚「为什么偏离」和「怎么控制的」。我曾经见过一个项目，偏离了20多条规则，但偏离说明全是「性能优化」，结果评审时被质疑了整整两天。
3.3 引用标准的通用格式
不管引用哪个标准，我建议统一格式。这样文档看起来专业，也方便自动化工具提取。
我个人习惯的格式是：
[标准编号]:[版本号] [模块/Part编号] [条款编号] [描述]举个例子：
[AUTOSAR 4.4.0]:[OS Module] [SWS_Os_00012] [任务优先级定义]
[ISO 26262-6:2018]:[Part 6] [Table 12] [软件单元测试覆盖率要求]
[MISRA C:2012]:[Rule 10.1] [浮点位操作禁止]这样做的好处是，评审时别人一眼就能看懂。而且，如果你用文档管理工具，还能自动生成引用索引。
3.4 避坑指南
做这行久了，踩过的坑不少。我总结几个常见的：
- 坑1：引用过时的标准版本。比如还在引用AUTOSAR 3.x，但客户要求4.x。我建议在文档开头加一个「标准版本清单」，每次更新时同步检查。
- 坑2：只引用不解释。写了「符合MISRA C」，但没写具体规则。评审时别人没法验证。
- 坑3：偏离说明太敷衍。我曾经见过一个偏离说明写「为了性能」，结果被安全工程师怼回来：「性能提升多少？风险降低多少？」从那以后，我的偏离说明都包含「原因+风险分析+补偿措施」三部分。
重要提醒：标准引用不是「贴标签」。你引用了，就要在设计中真正落实。否则，文档写得再漂亮，评审时一查代码就露馅。
3.5 小结
引用标准这件事，说难不难，说简单也不简单。关键就三点：
- 具体到条款，别笼统
- 版本号写清楚，别含糊
- 偏离说明要完整，别敷衍
做到这三点，你的文档在评审时就能少挨很多骂。嗯，我吃过亏，所以特别在意这些细节。
下一章，我会聊聊「软件架构视图的设计方法」。到时候见。
公众号:蓝海资料掘金营，微信deep3321