简介这份白皮书聚焦智能驾驶行为安全评价面向自动驾驶安全研究人员、测试工程师与行业决策者系统阐述以“合理可预见且可避免”为核心的安全评价方法。内容涵盖功能安全、预期功能安全、行为安全、交规符合性、ODD/ODC合理性、人机交互安全等十余个维度并对行为安全从技术、法律伦理、用户体验三个层面展开阐释提供场景枚举方法、交互场景参数化流程及封闭道路低速场景参数化实践案例可作为构建自动驾驶安全评价体系与测试验证方案的参考。资源为1个PDF文档共10.5MB包含白皮书完整正文、目录及参编单位信息适合对照研读与团队分享。已有132人学习尤其适合需要系统理解智能驾驶安全概念框架并落地行为安全评价方法的读者。1. 智能驾驶行为安全评价为什么碰撞记录不能回答安全问题路测工程师老张给我看过一段数据车辆在高速上被加塞系统急减速又急打方向测试员在后排吓出一身汗。回放日志里没有碰撞没有故障码系统自检一切正常。但所有人都觉得“这个行为有问题”却拿不出一个数字来证明它。智能驾驶行为安全评价方法解决的就是这个问题——把“这个行为是否安全”从感觉变成可计算、可对比的指标。它的核心不是看结果有没有撞而是看过程跟车距离、转向剧烈度、驾驶员有没有介入。适合做自动驾驶路测评价、主动安全系统标定、事故重建分析的人。这套方法在 ODD 框架下定义行为边界再用 TTC、THW、横向偏移等指标给每一段驾驶行为打分评价结论能直接指导参数标定。2. 行为安全评价的指标体系从 TTC 到驾驶员状态的五个维度2.1 为什么不能只看碰撞事故从结果导向到过程导向传统安全评价依赖事故统计百万公里事故率、碰撞速度、气囊弹出记录。这套体系在有人驾驶时代够用因为驾驶员的行为意图可以从事故后果倒推。但智能驾驶系统是黑匣子同样的 ODD 条件下不同版本软件的行为差异巨大。一个没有碰撞的测试里程里可能藏着几十次潜在危险行为——前车急刹时最小间距只剩 0.5 米变道时横向速度超过 3 m/s。这些行为不记录、不评价等真的出事故就晚了。过程导向的评价逻辑是把一段连续驾驶切片成行为单元每个单元用可量化的指标打分。指标分两层纵向跟车、刹停和横向变道、弯道。中间再加一层驾驶员状态维度——系统要求接管到驾驶员实际接管之间的时间差这是评价人机共驾安全的关键。2.2 核心指标的定义与计算逻辑行为安全评价里最常用的是下面这组指标它们不是随便选的每个都对应一个具体的危险机理。TTC碰撞时间度量纵向紧急度THW车头时距度量稳态跟车距离DRAC减速避免碰撞率度量减速需求是否在车辆能力范围内横向偏移速率度量变道稳定性方向盘转角速度度量转向平顺性。指标定义典型危险阈值数据来源TTC当前相对速度下两车预计碰撞时间 3s 警告 1.5s 危险前向毫米波雷达/视觉融合THW车头时距 间距 / 自车速度 1.0s 过近同上DRAC避免碰撞所需减速 / 路面附着允许最大减速 0.8 危险自车速度、前车速度、间距横向偏移速率车道中心线偏移的微分 0.8 m/s 异常车道线识别 车辆横摆角速度方向盘转角速度转向执行器的角速度城市 120°/s高速 80°/s方向盘转角传感器DRAC 的计算需要路面附着系数估计值常见做法是取默认干沥青 0.85雨雪天气按 ODD 查询表下调。TTC 和 THW 的阈值不是死的车速越高允许的 TTC 越大因为同样的碰撞时间在高车速下意味着更长的制动距离。2.3 数据来源不是所有车的日志都够用做行为安全评价的前提是能拿到三类数据环境感知目标物列表、车道线、红绿灯状态、车辆状态车速、加速度、方向盘转角、横摆角速度、驾驶员状态接管请求、实际接管、脚/手是否在位上。这三类数据在量产车日志里不一定齐全尤其是驾驶员状态很多日志系统只记录“是否接管”不记录接管前 2 秒的驾驶行为。如果缺驾驶员状态数据评价维度要相应缩水——先做环境与车辆两维度评价驾驶员维度留空。但缩水后的结论要标注置信区间因为同样的 TTC 值驾驶员注意力在线和离线的危险性完全不同。2.4 用一段 Python 函数演示 TTC 计算拿到感知融合输出的时刻做法是每个控制周期算一次 TTC存入环状缓冲区。下面是最简实现def compute_ttc(distance, ego_speed, target_speed, dt0.1): 计算碰撞时间 TTC :param distance: 自车与目标车纵向距离 (m) :param ego_speed: 自车速度 (m/s) :param target_speed: 目标车速度 (m/s) :param dt: 计算周期 (s) :return: TTC 值负值表示无碰撞风险 rel_speed ego_speed - target_speed if rel_speed 0: return -1.0 # 自车比前车慢无追尾风险 if distance 0: return 0.0 # 已经撞上 ttc distance / rel_speed return round(ttc, 2)逻辑说明只有当自车速度大于目标车速度时才计算 TTC否则返回 -1 标记无碰撞风险。distance 是感知模块输出的纵向相对距离不做横向补偿。返回值按 0.1 秒精度截断够评价用。参数说明dt 在函数里只作为注释保留因为 TTC 是瞬时量不需要积分。如果要做预测式 TTC考虑前车未来 2 秒加速度需要换成恒定加速度模型公式变成 ttc (-rel_speed sqrt(rel_speed² 2 * rel_acc * distance)) / rel_acc其中 rel_acc 是相对加速度。实测里恒定加速度模型误报率更低但需要目标车加速度观测值感知模块容易丢。3. 把 ODD 写进评价流程场景边界、参数映射与权重调整3.1 ODD 为什么不能只写在文档里ODD设计运行域定义了自动驾驶系统能跑的条件道路类型、速度区间、天气、光照、交通流密度。问题在于很多团队把 ODD 写在需求文档里评价时却脱离 ODD——不管场景直接算指标结果出现大量的低分片段其实是因为车辆跑出了设计范围。正确的做法是三层结构ODD 描述成为机器可读的 json/yaml→ 场景分类把 ODD 反解成具体场景片段→ 指标权重映射不同场景用不同指标组合。ODD 里写“高速路段限速 120”只是文本把它拆成“车道数 ≥ 2 且隔离带完整”评价脚本才能判断当前片段是否在 ODD 内。3.2 ODD 参数到评价指标的映射表不同 ODD 片段下同一套指标阈值要有不同取值。高速和城市对横向稳定性的容忍度差异很大城市变道频繁方向盘转角速度 120°/s 是正常的高速同频率转向就是不稳定。ODD 片段主要风险优先指标次要指标权重建议高速巡航追尾、偏离车道TTC、THW横向偏移速率纵向 0.6横向 0.4城市交叉路口碰撞、闯红灯DRAC、停止线距离驾驶员接管频率纵向 0.5横向 0.5匝道汇入冲突、压线横向偏移速率、TTCDRAC横向 0.6纵向 0.4泊车刮擦、慢速碰撞横向误差、速度超限方向盘转角速度横向 0.7纵向 0.3雨雪天气附着下降、感知降级DRAC、TTC衰减全部指标加权 0.7纵向 0.7横向 0.3权重不是拍脑袋来自事故重建样本。用过去一年的事故样本反向计算——如果事故前 3 秒 TTC 普遍小于 1s就把 TTC 权重上调。权重调整后要回归验证拿历史安全样本跑一遍确认不出现大面积误报。3.3 天气和光照作为调节因子ODD 里的天气参数不能只作为“是否允许运行”的开关它应该作为评价指标的衰减因子。雨雪天气下传感器检测距离缩短同一物理距离的 TTC 计算值会偏大因为感知延迟导致目标位置刷新滞后。常见做法是给 TTC 乘一个天气衰减系数干燥路面 1.0中雨 0.85大雪 0.6。光照偏低时车道线识别置信度下降横向偏移速率波动变大。评价脚本里要读取整车时间同步后的光照传感器数据光照低于 3000 lux 时横向指标阈值放宽 20%。否则会误判“系统在傍晚的匝道汇入时横向不稳”。3.4 场景切分方法把轨迹切成评价单元连续驾驶数据必须切成片段才能逐段评价。切分规则常见做法是当场景标签变化如匝道转入高速主路或纵向加速度连续 2 秒绝对值超过 0.3g就切一个片段。片段最短 5 秒最长 60 秒。短片段评价容易漏掉渐变的危险如缓慢压线长片段会把多个行为混在一起。切分后每个片段记录四元组ODD 场景、指标向量、危险等级、时间戳区间。这四元组就是后续评价报告的基础。4. 评价流程实操数据对齐、指标计算与危险片段挖掘4.1 第一步先做时间对齐CAN 和感知日志经常差几百毫秒实测数据里最常见的坑是时间戳不同步。CAN 总线时间基于车辆上电时间感知模块时间基于 GNSS 时钟两者可能差 300ms 以上。如果不对齐TTC 算出来要么偏大要么负值整个评价失去意义。对齐方法分两步。第一步粗对齐用整车时间戳和 GNSS 时间戳的差值取中位数做整体偏移。第二步细对齐利用加速度信号——CAN 里纵向加速度突然跳变时感知模块检测到前车相对距离突变两个信号的相关性最大点就是精确偏移量。import numpy as np def align_timestamps(can_accel, perception_dist, can_ts, perc_ts, max_offset0.5): 通过加速度与距离信号的互相关计算传感器时间偏移 :param can_accel: CAN 纵向加速度序列 :param perception_dist: 感知模块前车距离序列 :param can_ts: CAN 时间戳 :param perc_ts: 感知时间戳 :param max_offset: 最大允许偏移秒数 :return: 最优时间偏移 (感知相对 CAN 的延迟秒) sample_rate int(1.0 / np.median(np.diff(can_ts))) max_offset_idx int(max_offset * sample_rate) # 粗略检测加速度突变点 accel_jerk np.diff(can_accel) jerk_peak_time np.argmax(np.abs(accel_jerk)) / sample_rate dist_jump np.abs(np.diff(perception_dist)) dist_peak_time np.argmax(dist_jump) / sample_rate offset dist_peak_time - jerk_peak_time if abs(offset) max_offset: return None # 超出允许范围需要手动检查日志 return round(offset, 3)逻辑说明加速度的跳变jerk和感知距离的跳变应该同时发生例如急刹车会导致自车加速度突变和前车距离突变。通过找两个序列突变点的位置差得到时间偏移。这个方法比全序列互相关计算量小得多实测精度在 ±50ms 内。参数说明max_offset 取 0.5 秒。超过这个值的日志基本可以判定感知源或 CAN 源自身有延迟故障不能靠对齐修正要回到数据源头排查。sample_rate 假设两路信号采样率一致实际如果 CAN 是 100Hz、感知是 20Hz需要用插值统一到 20Hz 再处理。4.2 滑动窗口扫描危险片段对齐后就可以算指标了。为了不遗漏短时危险我用滑动窗口扫描窗口 3 秒、滑步 0.5 秒。每个窗口算一次最小 TTC、平均 THW、最大方向盘转角速度。窗口内任一指标越过阈值就记录一个“嫌疑片段”。这里要特别注意嫌疑片段之间可能有重叠。同一段危险驾驶行为会被多次记录需要做合并——两个嫌疑片段起点间隔小于 1 秒且连续存在危险指标合并为一条事件。def scan_dangerous_fragments(records, ttc_threshold3.0, window3.0, step0.5): 滑动窗口扫描危险片段 :param records: 时间对齐后的评价记录 [(timestamp, ttc, thw, steer_rate)] :param ttc_threshold: TTC 危险阈值 :param window: 窗口长度 :param step: 滑动步长 :return: 危险片段列表 [(start_ts, end_ts, min_ttc)] dangerous [] i 0 while i len(records): start_ts records[i][0] end_ts start_ts window window_records [r for r in records if start_ts r[0] end_ts] if not window_records: i int(step / (records[1][0] - records[0][0])) continue min_ttc min(r[1] for r in window_records) if min_ttc ttc_threshold: dangerous.append((start_ts, end_ts, min_ttc)) i int(step / (records[1][0] - records[0][0])) return merge_overlapping(dangerous, gap1.0) def merge_overlapping(fragments, gap1.0): merged [] for frag in fragments: if not merged: merged.append(list(frag)) continue if frag[0] - merged[-1][1] gap: merged[-1][1] max(merged[-1][1], frag[1]) merged[-1][2] min(merged[-1][2], frag[2]) else: merged.append(list(frag)) return [tuple(f) for f in merged]逻辑说明窗口内只要有记录 TTC 低于阈值就标记这个窗口为危险。merge_overlapping 把间隔小于 1 秒的连续危险窗口合并成同一个事件避免一次急刹车被拆成三条记录。参数说明ttc_threshold 默认 3 秒是预警级实际项目里“危险”阈值建议取 1.5 到 2 秒预警级用 3 秒。window 取 3 秒是平衡——太长会稀释短时危险2 秒急刹被 5 秒窗口平均掉太短会频繁触发。step 取 0.5 秒是经验值再小计算量翻倍但不会多检测出事件。4.3 从片段聚合到评价结论得到危险事件列表后不做聚类就输出结论是常见错误。聚类维度事件类型追尾风险/变道风险/压线风险、ODD 场景、车速区间。不同维度下的聚合统计会暴露系统性问题追尾风险事件在 80-100km/h 频发 → 高速跟车策略问题变道风险集中在匝道 → 匝道横向规划问题压线风险集中在夜间 → 视觉感知夜间退化问题聚合后输出三个层级的评价总体安全指数加权平均、场景分类得分、单事件明细。总体安全指数只用于汇报调参依据要看场景分类得分。评价等级TTC 最小阈值横向偏移速率驾驶员接管输出动作正常≥ 3.0s 0.8 m/s无接管继续监测轻度预警2.0~3.0s0.8~1.2 m/s无接管记录日志中度危险1.5~2.0s1.2~2.0 m/s1 次接管告警并上传严重危险 1.5s 2.0 m/s多次接管高优先级上传5. 避坑与常见问题评价结果翻车的五个真实原因5.1 时间戳对不齐导致 TTC 跳变现象评价脚本跑出来大量 TTC 为 0.2 秒的“严重危险”事件人工核对片段发现是正常车距根本没有碰撞风险。原因感知模块的时钟比 CAN 总线慢 400 毫秒对齐前相对距离和时间戳错位导致相对速度计算异常TTC 被低估。解决按 4.1 节方法做二次对齐。对齐后如果仍有个别跳变检查感知模块是否在遮挡后重新初始化了时钟。5.2 平均指标掩盖危险片段现象整车平均 THW 显示 2.1 秒一切正常。但分布图上能看到 5% 的时间 THW 小于 0.7 秒。原因平均化把危险瞬态抹平了。THW 的分布是长尾的危险藏在尾部。解决评价指标全部用分位数而不是平均值。THW 看 P5第 5 百分位、TTC 看最小值、方向盘转角速度看 P95。报告里同时给出均值和 P5/P95防止汇报时只看均值误判。5.3 ODD 定义和实车能力脱节现象ODD 文档写“支持雨量 10mm/h 以下运行”实测评价里 8mm/h 中雨片段大量触发横向危险事件系统表现远差于预期。原因ODD 写的是工程师期望值不是实测值。感知模块在雨量 6mm/h 时车道线检测已经间歇性丢失。解决先把 ODD 描述和传感器能力表对照能力表里有“感知降级条件”的要标注。评价脚本读 ODD 时把“支持”改成“能力边界内/外”两档能力边界外的片段单独统计不参与缺陷率计算。5.4 用单一固定阈值跨场景评价现象同样的变道行为高速路段评价为“安全”城市路段评价为“严重危险”两个场景阈值一刀切导致高速风险被掩盖。原因横向偏移速率和方向盘转角速度在不同速度下的危险性不同。高速下同样的横向速度意味着更大的横向加速度危险度高。解决按 ODD 场景配置阈值表不同场景独立阈值。代码里把阈值配置抽成 json不要散落在脚本里。5.5 忽略驾驶员接管前 2 秒的行为现象某片段评价为“正常”但后续测试员反馈“差点撞上”。原因系统在危险边缘触发了接管请求驾驶员接管后避开了碰撞。指标只算到接管时刻没算接管前 2 秒的系统行为。解决接管请求触发时冻结前 2 秒和后 1 秒的数据单独成片段标“驾驶员干预事件”。干预事件的指标不参与安全指数计算但要单独列在报告里——它是“系统接近失败”的信号。6. 用交叉验证校准评价阈值复现率与误报率的平衡6.1 人工复核样本的构造方法阈值定得再合理也要用真实数据验证。做法是抽一段已评价的数据200 个片段包含 100 个“危险”和 100 个“正常”先不告诉评价脚本结果让两个工程师分别人工打分。人工打分按三级危险/临界/正常。然后用评价脚本的结果和人工结果对比算一致率。一致率 (脚本危险人工危险 脚本正常人工正常) / 总片段数。一致率 ≥ 90% 说明阈值合理低于 80% 就要重新标定。6.2 复现率与误报率的定义与平衡复现率 评价脚本标为危险且人工也标为危险的样本数 / 人工标为危险的样本总数。误报率 评价脚本标为危险但人工标为正常的样本数 / 人工标为正常的样本总数。理想情况是高复现率、低误报率但两者在安全评价里本质矛盾——阈值越低复现率越高误报率也跟着涨。工程上先定下限复现率 ≥ 85%在这个前提下尽量压低误报率。如果复现率达不到不是单纯调阈值而是要增加指标——比如只靠 TTC 达不到就加 DRAC 联合判断。参数标定的常用套路先按第 2 章的参考阈值跑一遍记录复现率和误报率。然后画 ROC 曲线不同阈值下的两个指标挑曲线上距离左上角最近的点作为正式阈值。从那以后我每次拿到新车型的数据都会先跑一遍人工复核和 ROC 曲线确认阈值没有漂移再往下做正式评价。这个习惯帮我挡掉了好几次“新车型软件版本升级导致指标分布整体改变”的坑。希望这套流程对你的项目也有用。本文还有配套的精品资源点击获取