夜雨聆风ISO 26262 Part 6：软件层产品开发，这篇文章够了
Part 6 把软件层产品开发拆成了一条清晰的链路，从安全要求怎么来，到代码怎么写、怎么验证，再到软硬件怎么配合，一步步该做什么、做到什么程度，都给了明确的框架。
这篇文章目标很简单：让你看完能直接拿去项目里用。
第一章：安全要求从哪来
软件安全要求不是凭空想出来的，它的源头是 HARA（危害分析与风险评估）。
HARA 分析完成后会输出 Safety Goal（安全目标），这个目标交给系统层分解，得到 TSR（技术安全要求），TSR 再进一步细化，才得到软件层面的安全要求——SWRSS（Software Safety Requirements Specification）。这是软件层拿到手的第一个正式输入。
SWRSS 要回答三类问题：
第一，安全功能本身要做什么。 比如"扭矩监控功能必须在 100ms 内触发降扭"——这条要求来自上面的 TSR，软件要做的是把它拆成具体的实现方案。
第二，安全机制怎么落地。 看门狗多久没喂算失效？失效后软件应该进入什么状态？状态转换的超时时间是多少？这些细节都要在 SWRSS 里写清楚。
第三，时间约束怎么分解。 这里要区分两个概念：FTTI 是系统级的时间预算，指的是从故障发生到系统进入安全状态的总时间；而"100ms 内触发降扭"是 FTTI 在软件层面的具体分解——两者不是一回事，FTTI 是车辆级的时间窗口，软件响应时间是窗口内的子任务。
每一条 SWRSS 都要能回溯到对应的 TSR，每一条 TSR 要能回溯到 HARA 中的危害场景。ASIL 等级同样继承，软件安全要求至少继承对应项的 ASIL 等级，不能降级。
工程上最容易踩的坑： SWRSS 是软件和硬件团队共同写的，不是软件团队自己闭门造车。软件层面的安全响应取决于硬件能提供什么诊断能力——硬件有没有看门狗、能不能提供错误标志位、ADC 的自检覆盖了多少——这些决定了软件能做什么、不能做什么。两者脱节是项目里最常见的问题，而且往往是后期最贵的那个坑。
第二章：架构设计说什么
架构设计阶段要回答一个问题：软件打算怎么组织，才能满足分配过来的这些安全要求？
Part 6 把架构层面的要求分成了两堆：必须满足的强制性属性（认证的门槛）和推荐采用的工程原则（行业最佳实践）。这两个不是一个层次，混在一起说容易让人误会。
强制性属性里最核心的两条是：防止对安全相关元件的干扰，以及正确处理内部故障和错误。说白了，你的架构得保证安全相关的东西不被其他区域拖下水，出错了也知道怎么兜住。
推荐性原则就比较接近我们平时说的架构设计规范了：
关注点分离——安全功能和非安全功能最好物理隔离，至少逻辑上要隔开。比如动力域里，巡航控制的标定参数和一个安全关键的扭矩限制功能，前者出问题了不能影响后者。这不是架构洁癖，是成本最低的 fault containment 手段。
模块化——模块边界清晰、接口明确。改一个模块不会意外波及另一个模块，特别是安全相关的模块，边界要划得格外清楚。
故障响应链——架构层面要把故障处理的路径写出来：检测到了怎么办、响应策略是什么、系统怎么过渡到安全状态。软件能自己处理的就自己处理，需要硬件配合的要把接口写清楚，不能留白。
软件分区——当不同 ASIL 等级的组件跑在同一颗 MCU 上时，分区机制是关键。高 ASIL 的组件不能被低 ASIL 的干扰，内存空间、CPU 时间片、中断优先级都要有隔离保护，不然就等着级联失效吧。
架构阶段的输出是一份正式的文档，建议配上图形化表示（层图、框图都行），这套东西是后续单元设计和验证的基准。基准错了，后面全错。
第三章：代码怎么写
单元是软件最小可验证单位，通常对应一个函数或者一组紧耦合的函数。单元设计是架构和代码之间的桥梁——架构说模块干什么，单元说具体怎么实现。
设计阶段最好用形式化或半形式化的方式表达。状态转移逻辑清晰的功能用状态机描述，数据流和控制流复杂的功能用数据流图或控制流图。设计文档要和代码实现一一对应，"设计一套、实现一套"是认证审核里经常查出来的典型问题。
第四章：验证怎么算过关
软件验证要回答的问题很直接：你凭什么说软件满足安全要求？
验证不是随便跑几个测试用例就完事了。Part 6 定义了一个完整的验证体系，分四个层次：
- 静态分析：检查代码规范符合性、潜在缺陷，工具扫描为主
- 单元测试：验证每个单元的功能正确性，重点在接口和边界
- 集成测试：验证模块间接口、数据流、通信协议是否正确
- 系统测试：软硬件集成后的整车级功能和安全行为验证
不同 ASIL 等级对结构化覆盖率的要求是不同的：
- ASIL A：语句覆盖就够了
- ASIL B 及以上：MCDC 覆盖是必须的——Modified Condition/Decision Coverage，每个条件分支的独立影响都要被至少一个测试用例触发
- ASIL D：要求最高，MCDC 是标配
ASIL A 和 ASIL B 的要求差距不小，很多人误以为 ASIL B 只需要分支覆盖，实际不是这样。ASIL B 开始就要求 MCDC 了，这是一个需要清醒认识的测试策略边界。
背靠背测试是模型驱动开发的标配验证手段。 从 MIL（模型在环）到 SIL（软件在环）到 PIL（处理器在环）再到 HIL（硬件在环），每一级都在验证模型和代码实现的一致性有没有被破坏。实际项目里 SIL 到 PIL 这一步经常出问题——仿真环境和真实目标环境的浮点精度差异是常见根因，模型跑得好好的，上了目标板反而出事，这块不能省。
回归测试不可跳过。 每次软件变更后，安全相关的测试用例必须全部重新跑。新增功能不能破坏已有的安全机制——这条在认证审核时不会妥协。
验证记录是安全档案的核心组成部分。测试执行记录、结果、偏差处理，全部要归档。审核员来查的时候，拿不出记录就等于没做。
第五章：软硬件之间那些事
软件不可能脱离硬件谈安全。HSI（Hardware-Software Interface，软硬件接口规范） 是连接两者的纽带，越早定义越好。
HSI 要写清楚几件事：硬件抽象层的接口边界、寄存器映射和位定义、中断配置和优先级、软件对硬件安全特性的依赖（比如硬件看门狗、ADC 自检、内存 ECC 这些）。
软件安全度量的结果要反馈到硬件 FMEDA 里去。 软件能提供多少诊断覆盖率，直接决定了硬件故障被软件侧检测到的比例。这个数字进了 FMEDA 才会影响残余故障率的计算，最终影响硬件的量化指标是否达标。所以软件团队要给硬件团队一个清晰的输入：我的安全机制能覆盖多少种硬件故障模式，分别是什么类型的。
时序要求是安全软件的底线。安全相关任务的执行时间、最大抖动、调度确定性，这些在架构阶段必须明确下来。ECU 实时性不达标，安全机制等于形同虚设——功能逻辑再好，执行窗口不对，所有设计就全废了。
写在最后
Part 6 讲的是一条环环相扣的链路：安全要求导不出来，后续架构就是空中楼阁；架构设计分区策略没做好，单元实现再好也无法独善其身；验证不充分，认证审核就是一句空话。
可追溯性是贯穿整个过程的那条线。从 HARA 到 SWRSS，从架构到单元，从单元到测试用例，每一步都要能对上。这条线断了，认证就没法证明你做了该做的事。
最后，Part 6 不是孤岛。软件工程师如果不了解它在标准体系里的位置，做出来的东西就会有盲区。Part 2 给出了概念阶段的方法论，Part 4 把 ASIL 等级和安全要求分配到系统层面，Part 5 决定了软件能依赖哪些硬件特性。软件是系统的软件——关起门来只写代码的人，做不出真正的功能安全。
