4、运行场景分析：运行场景的定义、场景参数（道路、环境、车辆状态）、场景库的构建方法
好，我们进入第四章。运行场景分析。
说实话，很多工程师做HARA时，最头疼的就是场景。为什么？因为场景太「虚」了。你想想看，一个场景到底包含什么？是天气？是路况？还是前面那辆车的刹车灯？
我个人习惯，把场景拆成三块来看：定义、参数、库。这三块搞清楚了，HARA的底子就稳了。
4.1 运行场景的定义
先问个问题：什么是运行场景？
官方定义很绕，我用自己的话说——运行场景就是车辆在特定时间段内，所处的所有外部条件和内部状态的集合。
举个例子：
- 「一辆车在高速公路上以120km/h行驶，天气晴朗，路面干燥」——这是一个场景。
- 「同一辆车，在市区拥堵路段，下着大雨，路面有积水」——这是另一个场景。
你看，场景变了，危险就不一样。高速上的120km/h急刹车，和市区拥堵时的急刹车，风险能一样吗？
我在项目中遇到过一件事：有个团队做AEB（自动紧急制动）的HARA，只考虑了「晴天干燥路面」的场景。结果呢？测试时发现，雨天湿滑路面上，AEB的触发逻辑完全不对，差点出事故。这就是场景定义不全的教训。
4.2 场景参数：道路、环境、车辆状态
场景参数怎么拆？我一般分三大类：道路、环境、车辆状态。这三类参数，基本能覆盖90%以上的场景变化。
4.2.1 道路参数
道路参数，说白了就是「车在什么路上跑」。
| 参数类别 | 具体参数 | 典型取值 |
|---|---|---|
| 道路类型 | 高速公路、城市道路、乡村道路、隧道、桥梁 | 高速、市区、郊区 |
| 车道结构 | 车道数、车道宽度、是否有中央隔离带 | 2车道、3车道、4车道 |
| 路面条件 | 干燥、湿滑、积雪、结冰、坑洼 | 干燥、湿滑、积雪 |
| 曲率与坡度 | 直道、弯道（曲率半径）、上坡、下坡 | 直道、R=200m弯道、5%坡度 |
| 交通设施 | 红绿灯、标志牌、护栏、路肩 | 有/无 |
嗯，这里要注意：道路参数不是越多越好。我见过有人列了50多个参数，结果分析时根本用不上。我的建议是——只选那些对功能安全有直接影响的参数。比如，弯道曲率会影响感知系统的视野范围，这个必须列；但路面颜色？除非你的摄像头对颜色特别敏感，否则可以忽略。
4.2.2 环境参数
环境参数，就是「天」和「光」。
| 参数类别 | 具体参数 | 典型取值 |
|---|---|---|
| 天气 | 晴天、阴天、雨、雪、雾、冰雹 | 晴天、小雨、大雨、大雾 |
| 光照 | 白天、夜晚、黄昏、黎明、隧道内 | 白天、夜晚、黄昏 |
| 温度 | 高温、低温、常温 | -20°C、25°C、50°C |
| 其他 | 风、沙尘、电磁干扰 | 强风、沙尘暴 |
我曾经在一个项目中，忽略了「黄昏」这个光照条件。结果呢？摄像头在黄昏时的动态范围不够，导致行人检测漏报。后来我们补上了这个场景参数，才把问题暴露出来。所以，环境参数一定要考虑极端和过渡状态。
4.2.3 车辆状态参数
车辆状态，就是「车自己怎么样」。
| 参数类别 | 具体参数 | 典型取值 |
|---|---|---|
| 车速 | 静止、低速、中速、高速 | 0km/h、30km/h、80km/h、120km/h |
| 加速度 | 匀速、加速、减速、急刹车 | 0m/s²、2m/s²、-4m/s² |
| 转向 | 直行、左转、右转、变道 | 直行、左转 |
| 传感器状态 | 正常、遮挡、故障、脏污 | 正常、摄像头遮挡 |
| 执行器状态 | 制动系统、转向系统、动力系统 | 正常、制动衰退 |
这里有个坑：很多人只考虑「正常」的车辆状态。但HARA要分析的，恰恰是「不正常」的状态。比如，制动系统衰退时，AEB还能不能安全停车？传感器被泥巴糊住了，系统怎么降级？
4.3 场景库的构建方法
场景参数搞清楚了，下一步就是建库。场景库，说白了就是把你分析过的所有场景，整理成一个可复用、可追溯的数据库。
我建议用三步法：
- 场景识别：基于功能定义和运行设计域（ODD），列出所有可能的场景组合。
- 场景分类：按危险程度、发生频率、功能相关性，把场景分成几类。
- 场景存储：用标准化的格式（比如表格或XML），把每个场景的参数、分析结果、安全措施都存下来。
4.3.1 场景识别
场景识别，我一般用「组合爆炸法」——把道路、环境、车辆状态的所有参数组合起来，然后筛选出有意义的组合。
举个例子：
- 道路：高速公路、城市道路
- 环境：晴天、雨天
- 车辆状态：高速巡航、低速跟车
组合起来就是：2×2×2=8个场景。但有些组合明显不合理，比如「高速公路+低速跟车」？这不太可能。所以，筛选后可能只剩5-6个有效场景。
我在项目中用过一种更高效的方法：基于功能触发条件来反推场景。比如，AEB的触发条件是「前方障碍物+相对速度差」，那我就只分析那些「有障碍物且速度差较大」的场景。这样能省不少时间。
4.3.2 场景分类
场景分类，我习惯用「风险矩阵」来分：
| 风险等级 | 描述 | 示例场景 |
|---|---|---|
| 高 | 可能导致严重伤害或死亡 | 高速公路上，前车急刹，AEB失效 |
| 中 | 可能导致轻伤或财产损失 | 市区拥堵，ACC误加速导致追尾 |
| 低 | 可能导致功能降级或不适 | 雨天摄像头遮挡，系统提示清洁 |
分类的目的是什么？优先处理高风险场景。你想想看，如果时间有限，你是先分析「高速急刹」还是「雨天摄像头脏了」？肯定是前者。
4.3.3 场景存储
场景存储，我推荐用标准化的模板。每个场景至少包含以下字段：
- 场景ID：唯一标识
- 场景描述：一句话说清楚
- 道路参数：类型、车道、路面等
- 环境参数：天气、光照等
- 车辆状态：车速、加速度、传感器状态等
- 危险事件：可能发生的危险
- 安全目标：对应的安全要求
- ASIL等级：评估结果
我见过有人用Excel存，也有人用专门的工具（比如IBM DOORS）。我个人习惯用Excel，因为灵活，而且方便和团队共享。但要注意版本控制，别改乱了。
4.4 小结
好了，这一章的内容就这些。总结一下：
- 运行场景是HARA的基础，定义要全面。
- 场景参数分道路、环境、车辆状态三类，选参数要「少而精」。
- 场景库的构建，三步走：识别、分类、存储。
下一章，我们会讲「危害识别与风险评估」，也就是HARA的核心步骤。到时候，你会看到场景分析的结果是怎么用的。
嗯，今天就到这里。有什么问题，欢迎随时交流。