2. 危害识别基础：危害的定义与分类、功能不足与触发条件、危害识别的方法论
各位同学，欢迎来到第二章。上一章我们聊了SOTIF的整体框架，今天咱们要扎进去，聊聊最基础、也是最关键的一步——危害识别。
说实话，我见过不少团队，一上来就急着做风险评估，结果连“危害”到底是什么都没搞清楚。这就好比你要盖房子，却连地基的土质都没看。今天这堂课，咱们就把“危害”这回事儿掰开揉碎了讲清楚。
2.1 危害的定义与分类
先问大家一个问题：什么是危害？
在SOTIF语境下，危害是指由车辆系统行为引起的、可能导致人员受伤或死亡的潜在来源。注意，这里强调的是“潜在”。危害本身不是事故，而是事故发生的可能性。
我个人习惯把危害分成两大类：
- 直接危害：比如刹车失灵、突然加速、转向失控。这些是系统功能不足直接导致的。
- 间接危害：比如传感器被遮挡、算法误判、系统降级后驾驶员不知所措。这些往往跟触发条件有关。
你想想看，一个典型的L2级辅助驾驶系统，如果摄像头在隧道出口突然被强光照射，导致车道线识别丢失——这算不算危害？算。但它是间接的，因为系统并没有完全失效，只是功能不足。
核心要点：危害识别不是找“故障”，而是找“系统行为与预期之间的偏差”。
2.2 功能不足与触发条件
好，接下来咱们聊聊两个关键概念：功能不足和触发条件。
功能不足，说白了就是系统“能力不够”。比如：
- 传感器在雨雾天气下性能下降
- 算法对罕见场景（比如路上有个大坑）没有训练过
- 系统对某些边缘工况（比如前车突然急刹）反应时间不够
触发条件，则是让功能不足“暴露出来”的外部因素。比如：
- 天气：大雨、大雾、强光
- 道路：施工区、急弯、无车道线路段
- 交通参与者：行人突然横穿、非机动车逆行
- 系统状态：传感器脏污、计算资源过载
我在项目中遇到过这样一个案例：某款车的AEB系统，在晴天测试时表现完美。但一到下雨天，就频繁误触发。后来一查，原来是雨滴被雷达误判为障碍物。你看，这就是典型的“功能不足+触发条件”组合。
我的建议：做危害识别时，不要只盯着系统本身。多想想“什么情况下系统会表现不好”。我曾经吃过这个亏，后来每次做HARA，都会先列一个“触发条件清单”，再逐一匹配功能不足。
2.3 危害识别的方法论
那么，具体怎么识别危害呢？我总结了一套方法论，咱们一步步来看。
2.3.1 基于场景的识别
这是最常用的方法。先定义典型场景，比如：
- 高速巡航场景
- 城市拥堵场景
- 十字路口场景
- 泊车场景
然后针对每个场景，问自己三个问题：
- 系统在这个场景下应该做什么？
- 系统可能做错什么？
- 做错了会有什么后果？
2.3.2 基于功能的分析
这个方法更系统化。把系统功能拆解成一个个子功能，比如：
- 感知功能：目标检测、车道线识别
- 决策功能：路径规划、行为预测
- 执行功能：转向控制、制动控制
然后分析每个子功能可能出现的不足。我记得有一次，我们团队分析“目标检测”功能时，发现了一个很隐蔽的危害：系统对静止车辆的检测能力远低于运动车辆。这个发现后来直接影响了我们的传感器配置方案。
2.3.3 基于数据的驱动
这个方法比较新，但很实用。通过分析路测数据、仿真数据、甚至事故数据，找出系统表现不佳的“热点”。比如：
- 哪些场景下系统频繁接管？
- 哪些场景下系统出现误判？
- 哪些场景下驾驶员抱怨最多？
这些数据往往能帮你发现一些“意想不到”的危害。
注意：数据驱动方法虽然好，但不要完全依赖它。因为数据只能反映“已经发生过”的问题，而SOTIF要解决的是“可能发生”的问题。所以，三种方法要结合使用。
2.4 知识体系框架图
为了让大家更直观地理解本章的知识结构，我画了一张图：
2.5 实战中的避坑指南
最后，分享几个我踩过的坑：
- 别把“故障”当“危害”：故障是系统内部的问题，危害是系统行为对外的后果。比如“传感器失效”是故障，“车辆无法检测前方障碍物”才是危害。
- 别忽略“正常工况”下的危害：很多人只关注极端场景，但有些危害恰恰发生在“看起来正常”的情况下。比如，系统在晴天、直道上突然误刹车——这种危害往往更难排查。
- 别一个人闷头做：危害识别最好是团队协作。我建议至少拉上系统工程师、算法工程师、测试工程师一起讨论。不同视角能发现不同的问题。
一个小技巧：每次做完危害识别，我都会问自己一个问题：“如果明天就要量产，我最担心什么？”这个问题往往能帮我找到最关键的遗漏。
好了，这一章的内容就到这里。记住，危害识别不是一次性的工作，而是贯穿整个开发过程的。随着系统迭代、场景扩展，危害清单也要不断更新。下一章，咱们聊聊如何对这些危害进行风险评估。
公众号:蓝海资料掘金营，微信deep3321