7.3 安全 RTOS 与功能安全认证

7.3 安全 RTOS 与功能安全认证

本节摘要：当系统失效会伤人，开发对象就从「代码」扩展为「证据链」。本节分清功能安全与信息安全的语义，解释安全完整性等级的工程含义，梳理认证内核的来源与分工，并给出从普通项目升级到认证项目的流程件清单。

别以为「安全」只有一个意思，也不存在「通过了安全认证的黑客攻不进来」这类推理——这是两个独立的目标域。功能安全（safety）回答「系统失效时不伤人」，手段是冗余、诊断、确定性；信息安全（security）回答「有人蓄意破坏时怎么办」，手段是访问控制、加密、隔离。一个门锁做得再坚固（安全），也可能被人配了钥匙（信息安全）；反之亦然。本节的主角是前者，并把「认证」这个词拆成可以执行的工程动作。

标准地图：各行业的安全语法

功能安全不是单一标准，而是一族按行业分工的语法书。工业领域祖师爷是 IEC 61508，把风险化成安全完整性等级（SIL 一到四级）；汽车行业在其上派生 ISO 26262，等级换成 ASIL A 到 D；医疗器械用 IEC 62304 按软件安全分级；航空电子的 DO-178C 按失效影响分 A 到 E 级，最高级别要求最坏路径的数学证明。它们共享同一套底层逻辑：先评估失效的严重度与概率，得出目标等级，等级再决定开发流程的严格程度。等级越高，允许的失效概率越低，付出的流程代价呈指数增长。

等级到底管什么

以中等级别（SIL 二 / ASIL B 量级）为例，等级把下列事项从「建议」变成「强制」：需求到测试的双向可追溯（每条需求都能指出验证它的测试，反之亦然）；编码规范的强制执行（行业通行 MISRA C，禁用未定义行为相关构造）；静态分析零容忍；单元测试的语句与分支覆盖指标（最高级别要求修正条件判定覆盖）；验证活动的独立性（写代码的人不能独自完成验证）；开发与验证工具自身的置信度说明。到最高级别（SIL 三以上 / ASIL D / DO-178C A 级），还要加上形式化方法、多版本非相似冗余、以及独立评估机构的全过程审核。

对 RTOS 开发者的直接影响一句话：你要交付的不再只是固件，而是「固件加一条完整的证据链」——从危害分析到每行代码的测试报告，链条上任何一环缺失，产品就不能宣称满足该等级。

认证内核从哪来

从零自证一个内核合规，是数人年的工作量，行业的分工因此形成三种模式。第一，购买预认证内核：SafeRTOS、认证版 ThreadX 等商业内核随产品提供认证证书与安全手册，厂商为内核本身的正确性背书，开发者只需按安全手册的集成约束使用。第二，开源自证：FreeRTOS 与 SafeRTOS 同源，Zephyr 有持续进行的安全证明工作——用开源内核走认证，内核部分的管理责任（配置验证、版本固化、偏差跟踪）转移到集成方。第三，架构降险：把认证范围收窄——关键功能放进一个小的认证分区，复杂但无需认证的功能跑在普通分区，靠 5.3 节的隔离手段保证互不渗透。第三种「认证孤岛」模式在汽车与工业里越来越主流，因为它把最贵的流程代价框死在最小的代码面上。

从普通项目到认证项目：补什么

把差异整理成清单，按获取顺序排列：

这份清单对团队组织同样有影响：验证从「编码的附属工序」变成独立职能；配置管理从「拷贝归档」变成受控流程；文档第一次成为与代码同等重要的交付物。经验上，首次走认证的团队最不适应的正是最后一条——写文档不是负担，它就是产品。

实时性要求在认证语境下的变化

本教程的截止期主题在认证语境里升级为「时序证明」。第三章的响应时间分析从「工程实践」变成「必交证据」：任务参数的最坏值、分析假设（独立任务、无共享资源或已计入阻塞）、分析结果与测试测量的一致性，全部纳入文档。第二章裁剪内核得到的「精简配置」也有了新含义：配置即承诺——每一个开启的特性都要有对应的证据，于是「能关则关」从性能考量变成认证考量。第八章结尾的调试技术与第九章的验证方法，会在证据链语境下再次出场。

本节要点回顾

• 功能安全与信息安全目标独立、手段不同，论证时不可互相替代；
• 安全标准共享同一逻辑：风险定等级，等级定流程严格度；
• 等级的实质是把可追溯、覆盖度、独立性从建议变成强制；
• 认证内核三种来源：预认证商业内核、开源自证、认证孤岛架构；
• 流程件清单是升级认证项目的路线图，文档与代码同等是交付物；
• 截止期分析在认证语境下成为时序证明，内核裁剪即承诺收敛。

常见问题

问：等级是谁定的？ 危害分析与风险评估定出来的：识别系统的危害场景，按严重度与暴露概率对齐到标准的等级表。这一步在需求阶段完成，直接决定后面全部流程的重量级——等级定错（过高烧钱、过低违规），后面全盘返工。

问：开源内核走认证现实吗？ 现实但责任转移：内核版本要固化、配置要验证、补丁要评估，这些原本厂商背书的动作全部由集成方承接。本节的认证孤岛架构能大幅收窄这份责任的面。

问：认证后还能改代码吗？ 能，但每次变更走影响分析：改到什么范围、波及哪些证据、哪些测试要重跑。变更管理是认证项目的日常，没有「顺手改一下」这个词。

问：信息安全在功能安全项目里怎么安放？ 作为并行流程各自做各自的分析，但在架构层互相校验——比如加密任务的时间开销必须计入实时预算，安全启动的失败路径必须进入功能安全的失效分析。两份报告在架构评审会上碰头。

问：小团队做最低等级认证，最小代价路径是什么？ 收窄范围加复用资产：认证孤岛把关键功能框进最小分区；预认证内核省掉内核自证；验证活动优先自动化，覆盖率与回归的证据由流水线持续产出。等级再低，证据链的完整性也没有折扣价。

认证视角下回看全书

以认证的眼光重读本教程，很多机制的分量会变。第三章的响应时间分析从「好习惯」变成「必交证据」；第五章的静态分配从「稳妥选择」变成「可分析性声明」；第六章的中断纪律从「性能技巧」变成「时序证明的边界条件」。这个视角也解释了为什么行业里认证项目的代码看起来更「朴素」：不是能力不足，而是每一份精巧都要用证据换——把这一层想通，认证流程就从负担变成了设计纪律的自然延伸。若你的目标行业没有强制认证，这套纪律依然值得借走：证据链的本质是「承诺可复查」，它正是本书从第一页就建立的立场。