4. 功能与系统规范：定义系统功能、识别功能不足与触发条件、制定安全目标和安全措施
好，咱们进入第四讲。这一讲，说白了就是SOTIF落地的第一步，也是最容易踩坑的一步。很多团队一上来就写代码、做测试，结果发现功能定义都没搞清楚，后面全白干。我个人习惯，做SOTIF一定要先把“功能”这堵墙砌结实了。
4.1 定义系统功能：你到底想让车干什么？
定义系统功能，不是写一句“本车具备自动紧急制动功能”就完事了。你得把功能边界、使用场景、性能指标全说清楚。我见过一个项目，AEB功能定义里只写了“能刹车”，结果测试时发现它在晴天表现很好，一下雨就乱来——因为没定义“雨天场景下的性能降级”。
这里我建议用功能描述模板来规范输出：
| 要素 | 内容示例 |
|---|---|
| 功能名称 | 自动紧急制动（AEB） |
| 触发条件 | 自车速度 > 10 km/h，目标为车辆/行人 |
| 预期行为 | 在碰撞前1.5秒发出警告，0.8秒开始部分制动 |
| 性能指标 | 白天干燥路面：避免碰撞速度差 ≤ 40 km/h |
| 运行设计域 | 结构化道路，光照 > 100 lux，无遮挡 |
| 功能降级策略 | 传感器失效时，降级为仅警告，不制动 |
4.2 识别功能不足与触发条件：找到那些“看不见的坑”
功能不足，说白了就是系统在特定条件下表现不如预期。这不是故障，而是能力边界问题。举个例子，你的AEB系统在白天能识别行人，但到了晚上，行人穿深色衣服时识别率从99%掉到60%——这就是功能不足。
识别功能不足，我习惯从三个维度入手：
- 传感器局限：比如摄像头在逆光、雨雾、隧道出入口的表现
- 算法局限：比如目标检测模型对罕见车型、异形物体的漏检
- 系统局限：比如多传感器融合时的时延不同步、决策冲突
触发条件就是“什么情况下功能不足会被激活”。我建议用触发条件矩阵来系统化梳理：
| 功能不足 | 触发条件 | 严重度 | 可控性 |
|---|---|---|---|
| 行人检测漏检 | 夜间、行人穿深色衣服、背景有强光源 | 高 | 低 |
| 车道线识别丢失 | 路面有积雪、车道线磨损严重、强光直射 | 中 | 中 |
| 雷达多径反射 | 隧道内、大型金属护栏旁 | 高 | 低 |
| GPS定位漂移 | 高楼林立的城市峡谷、地下停车场 | 中 | 高 |
4.3 制定安全目标：把“不安全”翻译成“可验证的要求”
安全目标，就是把“别撞人”这种模糊要求，变成可量化、可测试、可验证的工程指标。我个人的经验是，安全目标要满足三个条件：具体、可测、有边界。
举个例子：
- ❌ 模糊目标：“AEB系统要足够安全”
- ✅ 合格目标：“在白天干燥路面，自车速度40 km/h时，AEB应避免与前方静止车辆发生碰撞”
- ✅ 优秀目标：“在白天干燥路面，自车速度40 km/h时，AEB应避免与前方静止车辆发生碰撞；在夜间潮湿路面，自车速度30 km/h时，AEB应将碰撞速度降低至10 km/h以下”
安全目标通常用SOTIF安全目标表来管理：
| 安全目标编号 | 安全目标描述 | 关联功能不足 | 验证方法 |
|---|---|---|---|
| SG-001 | 在白天干燥路面，自车速度≤40 km/h时，AEB应避免与前方静止车辆碰撞 | 行人检测漏检（夜间） | 实车测试、仿真测试 |
| SG-002 | 在夜间潮湿路面，自车速度≤30 km/h时，AEB应将碰撞速度降低至10 km/h以下 | 车道线识别丢失（积雪） | 实车测试、HIL测试 |
| SG-003 | 在隧道内，AEB不应因多径反射而误触发制动 | 雷达多径反射 | 仿真测试、场地测试 |
4.4 制定安全措施：把目标变成可落地的方案
安全措施，就是用来实现安全目标的具体手段。它可以是硬件改进、软件算法优化、系统架构调整，甚至是用户手册里的警告说明。嗯，这里要注意，安全措施要跟安全目标一一对应，不能漏项。
我常用的安全措施分类：
- 检测措施：比如增加传感器冗余、改进目标检测算法、加入自检功能
- 响应措施：比如降级策略、安全停车、限制功能可用范围
- 验证措施：比如增加测试场景、引入仿真验证、建立持续监控机制
举个例子，针对“夜间行人检测漏检”这个功能不足，安全措施可以这样设计：
| 安全目标 | 安全措施 | 措施类型 | 验证方式 |
|---|---|---|---|
| SG-001：夜间避免碰撞行人 | 增加红外摄像头，提升夜间行人检测率 | 检测措施 | 实车对比测试 |
| SG-001：夜间避免碰撞行人 | 当光照低于阈值时，自动降低最高车速至30 km/h | 响应措施 | 仿真测试 |
| SG-001：夜间避免碰撞行人 | 在用户手册中明确标注“夜间功能受限” | 验证措施 | 用户调研 |
4.5 本章知识体系总览
下面这张图，是我自己梳理的本章核心逻辑。你把它打印出来贴在工位上，做SOTIF的时候随时瞄一眼，思路会清晰很多。
你看，整个流程是环环相扣的。从定义功能开始，到识别不足和触发条件，再到制定目标和措施，最后还要通过验证来闭环。我个人的经验是，千万别跳步——跳过任何一步，后面都会加倍还回来。
- 功能定义要具体到场景、性能、边界条件
- 功能不足要从传感器、算法、系统三个维度找
- 触发条件要关注组合场景，单一条件往往不够
- 安全目标要可量化、可测试、有场景边界
- 安全措施要精准，避免过度设计导致复杂度失控
好了，这一讲就到这里。记住，SOTIF不是纸上谈兵，每一行定义、每一个目标，最后都要落到实车测试和用户实际体验上。下一讲我们会聊怎么把这些定义转化成可执行的测试用例——嗯，到时候见。
公众号:蓝海资料掘金营，微信deep3321