4、协同设计的必要性：传统V模型开发中的安全孤岛问题、系统复杂性与耦合性带来的挑战
好，咱们今天聊点实在的。为什么非得把预期功能安全（SOTIF）和功能安全（FuSa）放在一起搞？说白了，就是传统那套V模型开发，已经快撑不住了。
我入行那会儿，功能安全和预期功能安全还是两条平行线。做功能安全的盯着随机硬件失效，做预期功能安全的盯着算法和场景。大家各干各的，井水不犯河水。结果呢？项目后期一联调，问题全炸了。嗯，这就是典型的“安全孤岛”。
4.1 传统V模型中的安全孤岛问题
传统V模型，你想想看，左边是需求、设计、实现，右边是测试、集成、验证。看起来挺完美，对吧？但问题在于，功能安全和预期功能安全的活动，往往被塞进了不同的“格子”里。
- 需求阶段就分家：功能安全工程师写HARA（危害分析与风险评估），预期功能安全工程师写场景分析。两个文档，两套术语，两个评审会。我见过一个项目，HARA里定义的“危险事件”和场景分析里的“关键场景”根本对不上号。
- 设计阶段各玩各的：功能安全搞冗余架构、故障容错机制。预期功能安全搞感知算法、决策逻辑。两个团队几乎不交流。我记得有一次，功能安全团队要求加一个“传感器故障检测”模块，结果预期功能安全团队已经用算法做了类似的功能，两边重复造轮子。
- 测试阶段互相甩锅：系统出问题了，功能安全说“这是算法没考虑边界场景”，预期功能安全说“这是硬件没扛住随机失效”。最后扯皮扯了两个月，项目延期。
核心问题：传统V模型把安全活动按“专业领域”切分，而不是按“系统行为”整合。这导致安全分析不完整、设计冗余、测试遗漏。
为什么会这样？我个人的理解是，大家习惯了“各扫门前雪”。功能安全工程师盯着ISO 26262，预期功能安全工程师盯着ISO 21448。两个标准本身没有强制要求协同，但实际系统是同一个啊！你想想看，一个L3级自动驾驶系统，它的感知、决策、执行是耦合在一起的。你单独分析功能安全，不考虑算法退化；单独分析预期功能安全，不考虑硬件故障——这不就是盲人摸象吗？
4.2 系统复杂性与耦合性带来的挑战
好，咱们再往深了挖。现在的汽车电子系统，尤其是自动驾驶系统，复杂到什么程度？我举个例子：一个典型的城市NOA系统，涉及摄像头、毫米波雷达、激光雷达、高精地图、V2X、多域控制器……光传感器就有十几种。这些模块之间怎么交互？依赖关系有多复杂？
我建议你画一张系统架构图，把每个模块的输入、输出、依赖关系标出来。你会发现，这根本就是一张蜘蛛网。而这张网里，任何一个节点的失效（不管是硬件故障还是算法退化），都可能引发连锁反应。
避坑指南：我曾经在一个项目中，只分析了“摄像头被遮挡”这一种预期功能安全场景。结果呢？实际路测时，摄像头被遮挡后，毫米波雷达的数据融合算法也出错了，因为融合算法假设摄像头数据永远可用。这就是耦合性带来的“隐性失效”。
系统复杂性和耦合性，给安全设计带来了三个核心挑战：
- 失效传播路径难以穷举：一个模块的失效，可能通过数据流、控制流、甚至时序关系传播到其他模块。传统FMEA（失效模式与影响分析）根本分析不过来。
- 安全机制相互干扰：功能安全的安全机制（比如降级策略）可能触发预期功能安全的边界条件。举个例子：功能安全要求“当制动系统故障时，切换到冗余制动”。但冗余制动的响应时间比主制动慢，这可能导致预期功能安全中的“最小风险策略”失效。
- 验证与确认成本爆炸：你想想看，如果功能安全和预期功能安全分开测试，你需要两套测试用例、两套测试环境、两套评价标准。而且，很多测试场景是重叠的（比如“传感器故障+恶劣天气”），分开测试就是浪费。
下面这张图，是我自己总结的“安全孤岛与耦合挑战”的逻辑关系。你可以看到，传统V模型把安全活动切成了碎片，而系统耦合性又把碎片粘在了一起——结果就是，碎片之间的缝隙里，全是坑。
4.3 协同设计的核心价值
那怎么办？答案就是协同设计。说白了，就是把功能安全和预期功能安全当成一个整体来搞，而不是两个独立的专业。
我个人习惯，在项目启动阶段就拉一个“安全协同工作坊”。功能安全团队、预期功能安全团队、系统架构团队、软件团队、测试团队，所有人坐在一起。干什么？
- 统一安全目标：把HARA和场景分析的结果对齐。同一个危险事件，功能安全怎么处理，预期功能安全怎么处理，必须有一致的安全策略。
- 共享安全架构：系统架构里，哪些模块负责功能安全，哪些模块负责预期功能安全，哪些模块两者都涉及。边界要清晰，接口要明确。
- 联合测试策略：测试用例要覆盖功能安全和预期功能安全的交叉场景。比如“传感器故障+算法退化”这种组合场景，必须联合测试。
注意：协同设计不是简单的“开会沟通”。它需要从流程、工具、方法三个层面进行整合。流程上，要建立联合评审机制；工具上，要使用统一的需求管理平台；方法上，要引入系统理论安全分析（如STPA）来补充传统FMEA的不足。
我举个例子。之前做一个L2+的ADAS项目，我们采用了协同设计。功能安全团队和预期功能安全团队共用一套“安全场景库”。功能安全团队识别出“制动系统失效”的场景，预期功能安全团队识别出“目标识别丢失”的场景。然后我们联合分析，发现“制动系统失效+目标识别丢失”这个组合场景，会导致系统完全失控。于是我们设计了一个“最小风险策略”：当检测到制动系统失效时，立即触发声光报警，并请求驾驶员接管；如果驾驶员无响应，则自动执行紧急制动（利用冗余制动系统）。这个策略，既考虑了功能安全（制动失效），也考虑了预期功能安全（目标识别丢失）。
你看，这就是协同设计的力量。它让安全不再是“补丁”，而是系统设计的一部分。
好，这一章就聊到这儿。下一章，咱们具体讲讲协同设计的方法论——怎么从流程、工具、方法上落地。
公众号:蓝海资料掘金营，微信deep3321