4. 运行场景分析：车辆运行模式、环境条件、人为因素、系统状态分析
好，咱们接着聊HARA分析。前面我们把危害事件和风险都理清楚了，接下来这一步，我个人觉得是整个HARA里最考验「工程直觉」的部分——运行场景分析。
说白了，就是搞清楚一件事：这个危害到底会在什么情况下冒出来？
你想想看，一个功能在实验室里跑得稳稳当当，一上路就出问题，为什么？因为路上的场景太复杂了。ISO 26262要求我们把这些场景拆开来看，分成四个维度：车辆运行模式、环境条件、人为因素、系统状态。咱们一个一个过。
核心观点：场景分析不是走形式，它是后续ASIL等级评定的基础。场景漏了，风险等级就可能定低了，后果很严重。
4.1 车辆运行模式分析
车辆不是只有「开」和「停」两种状态。我见过不少新手工程师，写运行模式就写两行：「行驶中」和「停车时」。这哪够啊？
我个人习惯把运行模式拆成至少这几种：
- 启动/熄火阶段：这时候电源不稳定，ECU刚上电，很多自检逻辑在跑。我曾经遇到一个案例，某个ADAS功能在启动瞬间误触发，就是因为没考虑这个模式。
- 静止但发动机/电机运行：比如等红灯、堵车蠕行。这时候有些功能（比如自动驻车）是激活的，但驾驶员注意力可能分散。
- 低速行驶：0-30km/h，典型场景是停车场、小区道路。行人突然窜出来，AEB要不要触发？触发力度多大？
- 中高速行驶：30-100km/h，城市快速路或国道。这时候对转向、制动的响应要求更高。
- 高速行驶：100km/h以上，高速公路。嗯，这里要注意，高速下任何一个小偏差都可能放大成大事故。
- 倒车：这个模式经常被忽略。倒车时驾驶员视野受限，对后向感知功能的依赖度极高。
- 特殊模式：比如越野模式、拖车模式、洗车模式。这些模式下某些传感器可能被遮挡或禁用。
小技巧：我建议你在做HARA时，先拉一张表格，把车辆所有可能的运行模式列出来。然后针对每个危害事件，逐一打勾——这个模式会不会出现？如果会，风险等级要不要调整？
4.2 环境条件分析
环境条件这块，说白了就是「天时地利」。我刚开始做功能安全时，总觉得环境因素差不多就行了。直到有一次，一个毫米波雷达在暴雨天性能下降，导致AEB没刹住...嗯，从那以后我再也不敢轻视环境分析了。
环境条件至少要考虑这些维度：
| 环境维度 | 具体场景 | 对功能的影响 |
|---|---|---|
| 光照 | 白天、夜晚、黄昏、隧道入口/出口、逆光 | 摄像头性能下降，车道线识别失效 |
| 天气 | 晴天、雨天、雪天、雾天、冰雹 | 传感器衰减，路面附着系数变化 |
| 路面 | 干燥、湿滑、结冰、碎石、坑洼 | 制动距离变化，车辆稳定性受影响 |
| 温度 | 极寒(-40°C)、高温(85°C)、温度骤变 | 电子元件性能漂移，电池输出受限 |
| 电磁环境 | 高压线附近、充电桩、无线电干扰 | 通信中断，传感器噪声增大 |
| 地理环境 | 隧道、高架桥下、山区弯道、地下车库 | GNSS信号丢失，雷达多径效应 |
你可能会问：「这么多组合，我怎么分析得完？」
我的经验是：先抓最恶劣的组合。比如「夜晚+雨天+湿滑路面」，这个组合对视觉感知和车辆动力学都是极限考验。如果这个场景下功能还能安全运行，那其他场景大概率也没问题。
4.3 人为因素分析
人，永远是系统里最不可控的一环。ISO 26262里对人为因素的要求，说白了就是两件事：驾驶员会不会误操作？驾驶员能不能及时接管？
我总结了几类典型的人为因素：
- 误操作：比如把油门当刹车踩、不小心按了某个开关。我记得有个项目，驾驶员在高速上误触了电子手刹开关...嗯，后果你可以想象。
- 分心/疲劳：看手机、打瞌睡、跟乘客聊天。这时候驾驶员对系统报警的响应时间会大大延长。
- 过度信任：这是L2/L3系统的通病。驾驶员觉得「车自己能搞定」，于是完全放松警惕。我曾经在测试中遇到过，驾驶员在L2激活后直接双手离开方向盘看视频去了。
- 生理限制：反应时间、视野范围、听力障碍。比如老年人反应慢，或者驾驶员个子矮看不到仪表盘报警灯。
- 预期差异：驾驶员以为系统会这么做，但系统实际是那么做的。这种「人机预期差」最容易导致事故。
避坑指南：我曾经犯过一个错误——在HARA分析时假设「驾驶员永远正确」。后来发现，很多事故恰恰是因为驾驶员做了「合理但错误」的操作。比如在系统提示「请接管」后，驾驶员没有立即接管，而是先看了一眼后视镜...这1秒钟的延迟，可能就是生与死的区别。
4.4 系统状态分析
系统状态，指的是车辆电子电气系统本身所处的状态。这个维度经常被忽略，但恰恰是功能安全的核心——因为很多故障就发生在状态切换的时候。
我建议你关注这几个系统状态：
- 正常状态：所有功能正常运行，无故障。
- 降级状态：某个传感器或执行器失效了，系统进入降级模式。比如摄像头被遮挡，系统自动切换到仅依赖雷达的模式。
- 故障状态：系统检测到严重故障，进入安全状态。比如制动系统失效，车辆自动减速并靠边停车。
- 初始化/自检状态：车辆刚上电，系统还在自检。这时候某些功能可能还没准备好。
- 休眠/唤醒状态：车辆长时间停放后唤醒，或者从休眠模式恢复。这时候通信总线可能还没稳定。
- OTA升级状态：这个越来越常见了。升级过程中系统功能可能部分或全部不可用。
你想想看，如果一个危害事件发生在「降级状态」下，那它的风险等级是不是应该比「正常状态」更高？因为系统本身已经有一部分能力丧失了。
我的做法：在做HARA时，我会针对每个危害事件，单独列一栏「系统状态影响」。如果某个危害在降级状态下风险显著升高，我会考虑增加额外的安全机制，或者在ASIL等级上做补偿。
4.5 场景组合与优先级
好了，四个维度都讲完了。但实际分析时，它们不是孤立的——一个完整的运行场景是这四个维度的组合。
举个例子：
危害事件：ACC在高速行驶时突然失去前向目标
运行模式：高速行驶（120km/h）
环境条件：夜晚+小雨
人为因素：驾驶员正在看导航，注意力分散
系统状态：前向摄像头被雨滴遮挡，进入降级模式你看，这个场景一组合起来，风险就非常清晰了。ACC丢失目标，驾驶员没注意到，系统又在降级模式——这妥妥的高风险场景。
我个人习惯的做法是：先列出所有可能的单维度场景，然后做笛卡尔积，最后筛选出最关键的10-20个组合场景。不用贪多，贪多嚼不烂。关键是每个组合场景都要有工程意义，不能为了凑数而凑数。
总结一下：运行场景分析不是纸上谈兵。它决定了你的安全目标定得够不够全面，安全机制设计得够不够到位。我见过太多项目，HARA做得漂漂亮亮，但一上路就暴露问题——十有八九是场景分析漏了。
好，这一章就到这里。下一章我们聊聊「安全目标的制定」，那是把场景分析结果转化成具体安全需求的关键一步。到时候见。