4、运行场景分析：车辆运行场景、环境条件、人为因素、场景组合与覆盖

好，咱们进入HARA分析里最考验「想象力」的一环——运行场景分析。

说实话，我刚入行那会儿，觉得HARA最难的不是写ASIL等级，而是「我怎么知道这车会怎么开？」。你想想看，一辆车从出厂到报废，可能经历高原、暴雨、地库、高速、甚至被熊孩子乱按按钮。这些场景如果漏了，后面的安全目标就是空中楼阁。

4.1 车辆运行场景：别只盯着「正常开」

我个人习惯把运行场景分成三大类：

• 驾驶场景：直行、转弯、变道、倒车、泊车、上下坡
• 操作场景：启动、熄火、充电/加油、OTA升级、诊断模式
• 故障场景：单点故障、多点点故障、通信中断、电源跌落

我在项目中遇到过最典型的遗漏——某个ADAS项目，大家只分析了「高速巡航」和「城市跟车」，结果忽略了「车辆刚上电时摄像头未初始化」这个场景。后来测试发现，上电后3秒内如果前车急刹，系统根本来不及反应。嗯，这个场景后来被补进了HARA，ASIL等级直接给了C。

4.2 环境条件：天气、光照、路况、电磁

环境条件这块，我建议你按「物理环境」和「电磁环境」两个维度去拆。

环境维度	典型条件	对功能的影响
天气	晴天、雨、雪、雾、冰雹	传感器性能下降、路面附着系数变化
光照	白天、夜晚、隧道、逆光、强光	摄像头动态范围不足、眩光
路况	平坦、颠簸、湿滑、冰雪、砂石	车辆动力学变化、传感器振动
电磁	高压线附近、充电桩、无线充电	通信干扰、传感器误触发

我记得有一次做EPS（电动助力转向）的HARA，大家只考虑了干燥路面。结果后来客户投诉，说下雨天方向盘突然变重。一查，原来是湿滑路面下，EPS的扭矩限制策略被触发了，但HARA里根本没写这个场景。说白了，环境条件不是「背景板」，它是能直接改变系统行为的变量。

4.3 人为因素：驾驶员、乘客、维修人员、路人

人为因素，这是HARA里最容易被「想当然」的部分。很多人觉得「驾驶员肯定是清醒的、专注的、操作规范的」——你想想看，现实中有多少司机能做到？

我一般把人为因素分成四类：

• 正常操作：按手册操作，注意力集中
• 误操作：按错按钮、踩错踏板、挂错挡
• 异常状态：疲劳、分心、酒驾、突发疾病
• 恶意行为：故意关闭安全功能、篡改系统

我曾经吃过一个亏。某个自动泊车项目，我们假设「驾驶员会在系统提示后接管」。结果实车测试时，测试员故意在系统提示时玩手机——嗯，车直接撞上了柱子。后来我们在HARA里加了一条：「驾驶员未响应提示时，系统应自动执行最小风险策略」。这个场景的ASIL等级，我们给了B。

4.4 场景组合与覆盖：别让「组合爆炸」吓到你

好了，现在你有了运行场景、环境条件、人为因素。每个维度都有几十种可能。如果全排列组合，那就是天文数字。怎么办？

我的做法是三步走：

1. 先做单因素分析：每个维度单独列出所有可能值
2. 再做两两组合：找出「最危险」的组合。比如「雨夜+摄像头失效」比「晴天+摄像头失效」危险得多
3. 最后做专家评审：拉上系统、软件、硬件、测试、甚至售后的人，一起过一遍

举个例子，我之前做的一个线控制动项目，我们列出了这样的组合矩阵：

场景	环境	人为因素	是否覆盖	备注
高速巡航	晴天	正常驾驶	✅	基础场景
高速巡航	暴雨	正常驾驶	✅	湿滑路面+低能见度
高速巡航	暴雨	驾驶员分心	✅	最坏情况组合
自动泊车	地库	误踩油门	✅	来自售后投诉

你可能会问：「那剩下的组合怎么办？」我的回答是：覆盖不等于穷举。ISO 26262要求的是「合理的覆盖」，不是「100%覆盖」。你只要确保：

• 每个单因素都被覆盖到
• 最危险的组合被覆盖到
• 有明确的理由说明为什么某些组合被排除

4.5 实战建议：如何让场景分析不流于形式

最后，分享几个我自己的实战习惯：

• 用「故事板」代替「列表」：把场景写成一个小故事，比如「一个下雨的夜晚，司机刚加完班，疲劳驾驶，在高速上遇到前车急刹...」。这样更容易发现遗漏。
• 拉上测试工程师一起做：他们手里有大量实车测试的「奇葩场景」，比你自己想全面得多。
• 别忘了「售后数据」：我每次做新项目，都会去翻售后投诉记录。那些投诉里，藏着最真实的场景。

好了，运行场景分析就讲到这里。下一章我们会进入HARA的核心——「危害识别与风险评估」。到时候你会看到，今天分析的这些场景，会直接决定你的安全目标怎么写。