2. 协同开发的价值：为什么需要协同？功能安全与SOTIF在自动驾驶系统中的互补关系
说实话，我见过太多团队把功能安全和SOTIF当成两件事来做。安全团队搞功能安全，系统团队搞SOTIF，两边各干各的。结果呢？项目后期发现一堆冲突，改来改去，成本翻倍。
今天我就跟你聊聊，为什么这两者必须协同。说白了，它们就像人的左右手，缺一个都不行。
2.1 功能安全与SOTIF的本质差异
先搞清楚它们各自管什么。
| 维度 | 功能安全 (ISO 26262) | SOTIF (ISO 21448) |
|---|---|---|
| 关注对象 | 系统故障（硬件/软件） | 功能不足、场景局限 |
| 触发原因 | 元器件失效、软件bug | 传感器感知局限、算法边界 |
| 典型场景 | 刹车踏板断裂、内存溢出 | 强光下摄像头失效、暴雨中雷达误判 |
| 应对策略 | 冗余、诊断、安全机制 | 场景覆盖、ODD限制、性能提升 |
你看，一个管「坏了怎么办」，一个管「本来就不够好怎么办」。我做过一个项目，功能安全把ASIL D的冗余架构都设计好了，结果上路测试发现——摄像头在隧道出口被强光晃瞎了。这不是故障，是功能不足。SOTIF就是来解决这类问题的。
2.2 为什么必须协同？三个核心原因
2.2.1 风险是交织的，不是孤立的
你想想看，一个传感器故障（功能安全）和一个传感器感知局限（SOTIF），在系统层面会叠加。我记得有个案例：毫米波雷达在暴雨中性能下降（SOTIF问题），同时软件刚好有个内存泄漏的bug（功能安全问题）。两个问题单独看都不致命，但叠加在一起，系统直接宕机了。
嗯，这就是我常说的「风险耦合」。你分开分析，永远看不到全貌。
2.2.2 安全机制可能引入新风险
这一点很多人会忽略。功能安全要求加冗余，比如双摄像头。但冗余本身会带来新的SOTIF问题——两个摄像头如果标定不一致，融合算法反而会出错。
关键认知：功能安全的安全机制，可能成为SOTIF的风险源。反之亦然。
我曾经在一个项目中，为了满足ASIL B要求，给感知模块加了一个看门狗定时器。结果看门狗复位时机不对，导致车辆在高速上突然降级。你说这是功能安全问题还是SOTIF问题？其实都是。
2.2.3 开发效率的硬道理
说白了，分开搞就是浪费钱。你想想看：
- 功能安全要定义安全目标，SOTIF要定义功能不足场景。这两个其实是同一件事的两面。
- 功能安全要做FMEA，SOTIF要做HARA。很多输入是共享的。
- 功能安全要验证安全机制，SOTIF要验证场景覆盖。测试用例可以复用。
我建议你从一开始就把两个流程合并。别问我怎么知道的——我见过一个项目，功能安全团队做了三版FMEA，SOTIF团队又做了两版HARA，最后发现80%的输入是重复的。浪费了三个月。
2.3 协同开发的核心模型：互补关系
怎么理解这个互补关系？我画个简单的图给你看：
┌─────────────────────────────────────────────┐
│ 自动驾驶系统安全 │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 功能安全 │ │ SOTIF │ │
│ │ (系统故障) │ │ (功能不足) │ │
│ │ │ │ │ │
│ │ • 硬件冗余 │ │ • 场景覆盖 │ │
│ │ • 软件诊断 │ │ • ODD定义 │ │
│ │ • 安全机制 │ │ • 性能边界 │ │
│ │ • 故障响应 │ │ • 人机交互 │ │
│ └────────┬─────────┘ └────────┬─────────┘ │
│ │ │ │
│ └─────────┬───────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ 协同接口 │ │
│ │ • 安全目标 │ │
│ │ • 场景库 │ │
│ │ • 验证策略 │ │
│ │ • 度量指标 │ │
│ └─────────────┘ │
└─────────────────────────────────────────────┘你看，它们不是上下级关系，也不是并列关系。它们是互补的——一个管「内部故障」，一个管「外部局限」。只有两者都覆盖了，系统才是真正安全的。
2.4 实战中的协同切入点
说了这么多理论，来点实际的。我在项目中总结出三个最有效的协同切入点：
2.4.1 安全目标与ODD的协同
功能安全定义安全目标时，一定要参考SOTIF的ODD定义。举个例子：
- 功能安全说：「车速超过120km/h时，制动系统必须能在3秒内响应」
- SOTIF说：「我们的ODD只覆盖到100km/h」
你看，这不就冲突了吗？协同的做法是：先确定ODD，再基于ODD定义安全目标。或者反过来，安全目标决定了ODD的边界。
我的习惯：每次定义安全目标前，先拉上SOTIF团队过一遍ODD。花半天时间，省后面三个月返工。
2.4.2 场景库的共享
这个最直接。功能安全需要故障场景，SOTIF需要功能不足场景。但很多场景是共用的：
- 传感器被遮挡 → 既是故障（硬件失效）也是功能不足（感知局限）
- 通信延迟 → 既是故障（网络问题）也是功能不足（性能边界）
- 算法误判 → 既是故障（软件bug）也是功能不足（算法局限）
我建议你建立一个统一的场景库，打上标签：「功能安全相关」「SOTIF相关」「两者相关」。这样测试用例可以复用，分析工作也能合并。
2.4.3 验证策略的整合
功能安全验证的是「故障注入后系统是否安全」，SOTIF验证的是「在未知场景下系统是否安全」。这两个验证活动可以共用测试平台和测试数据。
我记得有个项目，功能安全团队做了1000个故障注入测试，SOTIF团队又做了2000个场景测试。后来我们发现，有300个测试用例是重复的。如果一开始就整合，至少省两周时间。
2.5 避坑指南
我曾经踩过的坑：
- 坑1：功能安全和SOTIF分开做文档。结果两个文档互相矛盾，评审时被客户怼得哑口无言。
- 坑2：功能安全团队做完安全机制，SOTIF团队才介入。结果安全机制引入了新的SOTIF风险，又要改架构。
- 坑3：两个团队用不同的工具链。功能安全用Medini，SOTIF用Simulink，数据对不上，沟通成本翻倍。
我的建议：从项目第一天就把两个团队拉在一起，共用工具、共用场景库、共用评审流程。别等到后期再整合，那时候成本已经失控了。
2.6 小结
功能安全和SOTIF不是二选一，也不是谁替代谁。它们是自动驾驶安全的两条腿，缺一条都站不稳。
你想想看，如果只做功能安全，系统在正常工况下很安全，但遇到极端场景就抓瞎。如果只做SOTIF，系统能应对各种场景，但一个硬件故障就全盘崩溃。只有两者协同，才能真正做到「故障时安全，正常时可靠」。
下一章我会具体讲怎么搭建协同开发流程。嗯，那才是真正的硬核内容。