第4章：功能定义与规范
各位工程师朋友，今天我们来聊聊SOTIF里最基础、也最容易出问题的一环——功能定义与规范。
说实话，我见过太多项目在后期才发现功能定义有漏洞。那时候再改，成本就高了。所以这一章，我想把我在实际项目中踩过的坑、总结的经验，都跟你聊聊。
4.1 系统功能定义
系统功能定义，说白了就是回答一个问题：这个系统到底要干什么？
听起来简单，但做起来真不容易。我参与过一个L2级辅助驾驶项目，功能定义写了整整80页，结果到了测试阶段，还是发现有些场景没覆盖到。
为什么会这样？因为功能定义不能只写「正常情况」，还得考虑各种边界。
功能定义的核心要素：
- 功能目标：系统要完成什么任务？比如「自适应巡航」的目标是保持安全跟车距离。
- 功能场景：在什么环境下工作？白天、夜晚、雨天、隧道？
- 功能行为：系统如何响应？加速、减速、转向、报警？
- 功能限制：什么情况下系统不工作？比如传感器被遮挡、GPS信号丢失。
我个人习惯，在写功能定义时，会先画一张功能架构图。把输入、输出、控制逻辑、安全机制都标清楚。这样后面做验证时，才知道要测什么。
4.2 功能边界与性能限制
功能边界，就是系统能做什么、不能做什么的「分界线」。性能限制，则是系统能做到什么程度。
举个例子：一个自动紧急制动（AEB）系统，它的功能边界可能是「车速在10-80km/h范围内有效」。性能限制可能是「最大减速度不超过0.8g」。
我的经验：边界条件往往是事故的高发区。我曾经遇到一个项目，AEB在白天表现很好，但到了黄昏时分，因为光线变化，传感器误触发了好几次。这就是典型的「边界条件没定义清楚」。
定义功能边界时，我建议从以下几个维度考虑：
| 维度 | 示例 | 说明 |
|---|---|---|
| 环境边界 | 光照、天气、温度 | 系统在什么环境下能正常工作？ |
| 操作边界 | 车速、加速度、转向角 | 系统在什么操作范围内有效？ |
| 感知边界 | 探测距离、视场角 | 传感器能「看到」多远、多宽？ |
| 执行边界 | 制动能力、转向力矩 | 执行器能「做到」什么程度？ |
性能限制这块，我特别想强调一点：不要过度承诺。有些团队为了追求指标好看，把性能限制写得很高。结果测试时发现根本达不到，还得回头改规范。你想想看，这多浪费时间？
4.3 功能不足的识别方法
功能不足，就是系统在某些场景下表现不够好，甚至可能引发危险。这是SOTIF要重点解决的问题。
识别功能不足，我常用的方法有这几种：
4.3.1 基于场景的分析
把系统可能遇到的所有场景列出来，然后逐个分析。场景可以分为：
- 正常场景：系统应该能完美处理的场景。
- 边缘场景：系统可能表现不佳的场景。
- 危险场景：系统可能引发事故的场景。
我记得有一次，我们分析一个自动泊车系统。正常场景都通过了，但边缘场景里有一个「车位旁边有消防栓」的情况。系统把消防栓识别成了障碍物，结果一直不敢停。这就是一个典型的功能不足。
4.3.2 基于数据的分析
如果你有实车测试数据，那是最好的。分析数据中系统表现不佳的片段，找出共性问题。
我曾经处理过一个案例：某款车的车道保持系统，在高速上表现很好，但一到城市道路就频繁退出。后来分析数据发现，是因为城市道路的车道线磨损严重，系统识别不到。嗯，这就是一个典型的「感知能力不足」。
避坑指南：我曾经犯过一个错误——只分析「成功」的数据，忽略了「失败」的数据。后来发现，那些失败的数据里，藏着大量功能不足的线索。所以，一定要把失败案例当成宝贝。
4.3.3 基于仿真的分析
有些场景很难在实际道路上复现，比如极端天气、罕见交通状况。这时候，仿真就派上用场了。
我建议在仿真中设置一些「压力测试」场景：
- 传感器噪声增大
- 目标物突然出现
- 多目标交叉运动
- 通信延迟增大
这些场景能帮你发现系统在「极限状态」下的表现。
4.3.4 基于安全分析的方法
STPA（系统理论过程分析）和HAZOP（危险与可操作性分析）是两种常用的安全分析方法。它们能帮你系统性地找出功能不足。
我个人比较喜欢STPA，因为它能分析「控制动作」是否恰当。比如：
- 控制动作是否缺失？
- 控制动作是否错误？
- 控制动作是否时机不对？
- 控制动作是否停止过早或过晚？
一个实际案例：
某款车的自适应巡航系统，在跟车时如果前车突然变道，系统会误以为前方没有障碍物，然后加速。这就是一个典型的「控制动作错误」——系统没有正确理解前车变道后的场景。
通过STPA分析，我们发现了这个问题，并在功能规范中增加了「前车变道后的目标切换逻辑」。
4.4 功能规范的文档化
最后，我想聊聊功能规范的文档化。再好的分析结果，如果写不清楚，后面的人也没法用。
我建议功能规范包含以下内容：
- 功能概述：一句话说清楚功能是什么。
- 功能场景：列出所有支持和不支持的场景。
- 功能行为：每个场景下，系统应该怎么做。
- 功能限制：明确写出系统的边界和限制。
- 功能不足：列出已知的功能不足，以及应对措施。
- 验证要求：每个功能点需要怎么验证。
写规范时，我有个小习惯：用「必须」「应该」「可以」来区分要求的严格程度。
- 必须：不满足就不能发布。
- 应该：尽量满足，但可以协商。
- 可以：可选功能，有更好，没有也行。
这样写，后面做验证时，优先级就清楚了。
好了，这一章的内容就到这里。功能定义与规范，看似基础，但真的决定了后续所有工作的成败。下一章，我们会聊聊验证策略的制定，到时候再跟大家分享更多实战经验。