3、系统定义与危害分析：系统边界定义、功能描述、危害分析与风险评估（HARA）在SOTIF中的应用

各位工程师朋友，咱们今天聊聊SOTIF流程里最基础、也最容易翻车的一步——系统定义与危害分析。说实话，我见过不少项目，前期觉得“功能都清楚，边界也明白”，结果到了测试阶段才发现，一堆未知场景没覆盖到。嗯，这往往就是系统定义没做扎实。

3.1 系统边界定义：你得知道你的车“管到哪”

系统边界定义，说白了就是划地盘。你得明确：我的自动驾驶系统到底负责哪些事？哪些事是交给驾驶员、或者交给其他系统的？

我个人习惯，先画一张物理边界图。比如一个L2级的车道保持系统，它的传感器有哪些？摄像头装在哪？毫米波雷达覆盖多大角度？执行器是控制方向盘还是同时控制刹车？这些都得写清楚。

我记得有一次，一个团队做自动紧急制动（AEB）的SOTIF分析。他们定义的系统边界里，只写了“检测前方车辆并制动”。结果呢？测试时发现系统对横穿的行人完全没反应——因为边界定义里没写“行人”。这就是典型的边界遗漏。

系统边界定义通常包含以下几项：

• 物理边界：传感器类型、安装位置、探测范围；执行器类型、响应时间
• 功能边界：系统在什么条件下激活、什么条件下退出（比如雨雪天、隧道、夜间）
• 操作边界：ODD（运行设计域）的具体参数，比如车速范围、道路类型、光照条件
• 接口边界：系统与其他系统（如ESP、EPS、人机交互界面）的数据交互

3.2 功能描述：把“能做什么”说清楚

功能描述不是写作文，而是写说明书。你得让任何一个工程师看了，都知道这个系统到底怎么工作。

我建议用结构化方式描述功能。比如：

• 功能名称：自适应巡航控制（ACC）
• 触发条件：驾驶员设定目标车速，且车速>30km/h
• 系统行为：通过毫米波雷达检测前车距离，自动调整本车车速，保持设定时距
• 退出条件：驾驶员踩刹车、车速<20km/h、或传感器故障

你想想看，如果功能描述里只写“ACC能自动跟车”，那分析危害时根本找不到切入点。你得知道它什么时候加速、什么时候减速、什么时候退出，才能分析这些行为会不会导致危害。

3.3 HARA在SOTIF中的应用：从“功能安全”到“预期功能安全”

搞过功能安全的朋友对HARA（危害分析与风险评估）应该不陌生。但SOTIF里的HARA，侧重点不太一样。

传统功能安全的HARA，分析的是“系统故障”导致的危害。比如传感器坏了、软件跑飞了。而SOTIF的HARA，分析的是“系统在正常工作时，因为性能局限或未知场景导致的危害”。说白了，系统没坏，但它就是干不好活。

举个例子：一个摄像头在强光下逆光行驶，它没坏，但就是看不清前方障碍物。这就是SOTIF要管的事。

我在项目中遇到过最典型的案例：某L3级系统在隧道出口处，因为光照突变，摄像头短暂“失明”了大约0.5秒。系统没报故障，但就是没检测到前方静止的施工车辆。嗯，这就是SOTIF的HARA要提前识别出来的场景。

3.3.1 SOTIF中HARA的步骤

1. 识别危害事件：系统在什么场景下，可能因为性能局限导致危害？比如“夜间无路灯路段，摄像头检测不到深色衣物行人”
2. 分析危害后果：这个危害会导致什么？比如“车辆未减速，与行人碰撞”
3. 评估风险等级：结合场景发生概率和后果严重性，给风险定级
4. 确定可接受标准：什么样的风险是可以接受的？什么样的必须解决？

3.3.2 一个简化的HARA示例

咱们拿“自动变道辅助系统”举个例子：

危害事件	触发场景	后果	风险等级
变道时未检测到盲区车辆	雨天，毫米波雷达受雨衰影响，检测距离缩短	与盲区车辆发生侧碰	高
变道时误判目标车道车速	目标车道车辆突然加速，摄像头测速延迟	变道后与后车距离过近	中
变道过程中车道线消失	施工路段，车道线被覆盖	系统退出变道，车辆回到原车道	低

你看，这三个危害事件，系统都没坏。但就是因为传感器性能局限（雨衰、测速延迟）或者场景超出预期（施工路段），导致了潜在风险。

3.4 知识体系总览

下面这张图，是我自己总结的SOTIF系统定义与危害分析的核心逻辑。你可以把它当作一个检查清单，做项目时对着看，不容易漏项。

3.5 避坑指南

最后，分享几个我踩过的坑：

• 别把HARA做成一次性工作。 我曾经在一个项目里，HARA做完就扔那了。结果后来ODD改了（增加了夜间场景），原来的分析全得重来。HARA要跟着系统迭代走。
• 别只依赖专家经验。 专家再牛，也想不到所有边缘场景。我建议结合真实路采数据，看看系统在实际路上都遇到了什么“怪事”。
• 风险等级别拍脑袋。 我曾经见过一个团队，把“行人碰撞”的风险等级定为“中”，理由是“概率低”。但你想，后果是死亡，概率再低也是高。SOTIF里，严重性往往比概率更重要。