自动驾驶统一评估框架

最新推荐文章于 2025-11-25 14:32:13 发布

原创最新推荐文章于 2025-11-25 14:32:13 发布 · 345 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#自动驾驶 # 评估框架 # 仿真测试 # 安全性 # 场景

自动驾驶车辆的统一评估框架

摘要

自动驾驶系统（ADS）安全性评估是部署在公共道路上之前的关键步骤。尽管为测试自动驾驶系统可靠性而确保 ADS安全性至关重要，但现有研究大多严重依赖单一的测试数据源（即道路上采集的测试数据、仿真或测试跑道）。每种数据源具有不同的保真度水平和能力，因此目前缺乏一种能够使所有数据源相互补充、实现源无关的端到端评估并支持不同测试目标的综合性解决方案。ADS评估被视为自动驾驶汽车开发生命周期中的必要步骤，亟需一种可靠且全面的方法。本文提出了一种源无关框架，可执行兼容多种测试来源的自动驾驶系统评估。我们的研究结果表明，这一综合性解决方案能够节省自动驾驶系统评估所消耗的时间、人力和成本。

Index Terms— 自动驾驶车辆，车辆安全性，评估。

一、引言

近年来，汽车原始设备制造商、供应商和科技公司已向自动驾驶汽车（AVs）投入了巨额资金。一些公司甚至声称，他们即将在公共道路上部署无需驾驶员在方向盘后的自动驾驶汽车（即SAE四级自动驾驶）。尽管自动驾驶系统的开发旨在提高道路安全性，但人们对它的安全性仍存在担忧。这些担忧已在报告和调查中显现出来，并且最近涉及自动驾驶系统的致命事故也进一步证实了这些担忧。此类事件以及公众认知对这项本可拯救生命、节省资金并保护环境的技术的大规模应用并不利。因此，应对自动驾驶系统进行系统性的测试和评估。

自动驾驶车辆是具有挑战性的安全性关键系统，在公共道路上部署之前需要进行严格的评估和测试[10]。确保自动驾驶系统的安全性是一项复杂的跨学科挑战，涉及车辆功能层次结构的各个层面[11]。

汽车行业一直依赖ISO 26262等标准来确保在不同开发阶段[12]汽车电子系统的安全性。然而，由于使用了机器学习系统[13]，该标准在自动驾驶系统方面存在不足。最近，预期功能安全（SOTIF）发布，它是新发布的ISO/PAS21448标准[14]的简称。它被认为作为对ISO 26262的补充，旨在弥补这些不足。然而，它仍然不够完善。因此，评估自动驾驶汽车性能的标准化方法仍然是一个未解决的问题。

评估可以在仿真、可控道路课程或真实道路上进行，每种方法都有其优缺点[15]。基于真实交通数据的评估虽然准确，但成本高昂且耗时。此外，由于无法控制现实世界中的各种因素，测试复杂情况十分困难。可能行驶数千英里都未遇到任何罕见的关键情况[16]。同样，私人测试场地仍过于昂贵，难以覆盖所有可能的驾驶场景。尽管仿真精度较低，但它能够合成各种挑战性场景，并以较低成本并行运行大量实验，且无需承担安全性风险。

场景和度量在评估自动驾驶系统性能时也可被视为两个关键参数[17]。根据ISO/PAS 21448，场景是验证活动的重要组成部分。一个场景需考虑周围环境和具体情况（例如其他车辆和行人的行为、道路和天气条件等）。度量是用来量化性能的标准，例如每1000英里脱离次数[18]，接近事故次数，或纵向/横向舒适性。为了确保自动驾驶系统具备在公共道路上部署的条件，应在其广泛的挑战性场景中进行测试，并通过有意义的指标进行评估[19]。为实现真实有效的评估，场景应包括极端案例以及正常常见情况。度量应反映运行设计域（ODD）的整体安全性与舒适性[20]。例如，如果自动驾驶系统旨在用于城市环境，则基于高速公路特定指标（如行驶的高速公路里程）的分析将产生误导。

一些工作已从仿真数据中进行评估，如百度的阿波罗仿真平台[21]。尽管它允许用户添加自己的场景和自动驾驶系统，但其评分系统（指标）存在局限性，并且其评估系统与其内置模拟器紧密耦合。因此，缺乏一个统一且独立于自动驾驶系统的评估框架。仅依赖单一数据来源是不够的。例如，某个模拟器可能在测试某项驾驶能力方面表现良好，但在其他方面却不如人意。此外，不同模拟器之间的场景结构和格式也各不相同。

本文提出了一种用于自动驾驶系统评估的统一框架，该框架兼容不同的测试数据源。该框架通过一系列内置指标进行评估（见第二节-D1）。此设计还支持用户自定义指标，以适应进一步的评估需求。

II. 提出的框架

示意图0

所提出的评估框架将自动驾驶系统（ADS）视为一个黑箱模块，包含以下三个基本理念：1）设计一个对数据资源无关的评估系统，通过统一状态表示来消除针对不同模拟器使用不同评估平台的需求。2）提供一组默认的指标和场景配置，用于评估自动驾驶系统（ADS）解决方案。3）为用户提供一个应用程序编程接口（API），以定义其自身的指标集合。

图2展示了所提出的框架，其中来自模拟器或现实世界的测试数据通过状态转换模块被转换为标准状态的连续数据流（见第II-A节）。这些状态可以写入存储，以便后续进行离线评估。草图板（见第II-C节）解释标准状态流并将其传递给指标评估。评估的结果和日志均会显示给用户，并存储到数据平台，以便进一步分析和可视化。

A. 状态表示

真实状态是描述被测车辆（自我车辆）周围感兴趣区域（FOI）环境状态的信息。该真实状态包括此感兴趣区域内所有物体的状态，例如运动物体（如车辆、行人、动物等）、静止物体、道路标线、车道、交通标志和交通信号灯等。如图2所示，存在一个状态转换器，负责将任意格式的状态表示（非典型数据）转换为我们的标准格式。该数据结构被称为评估包（EP），是一种带时间戳的结构化数据包，用于表示环境的真实状态。事件点序列（EPs）是使用protobuf消息序列化语言实现的结构化消息，该方法被视为围绕开放仿真接口真实状态[22]的封装，添加了必要的字段以表示来自感兴趣区域（FOI）所需的所有信息。

事件点序列（EPs）可以从模拟环境或实车道路测试期间收集的数据中生成。

B. ADS评估器

评估器是用于执行自动驾驶系统评估的模块。根据我们的设计，评估器可以被视为围绕两个子组件（草图板和度量）的逻辑框架。这种设计使得评估器具有灵活性和可扩展性，如图2所示。评估器由事件驱动，这些事件定义了值得关注的发生情况，并可能影响结果。

C. 时空画板

如第二节II-A中所述，事件点序列（EPs）表示环境在空间上和时间上的演变过程。为了提取有关感兴趣事件的有意义信息（例如多个物体的碰撞、车道边界穿越），在时空画板中重构状态。尽管它是对每个时间步系统状态的再现，但草图板与模拟器不同，它不会计算后续时间步的状态。其目的是基于给定时间步的环境状态来处理事件。例如，碰撞事件包含涉及的车辆、发生的时间戳、导致该事件的状态历史等上下文数据。

为了便于处理事件，草图板利用了游戏引擎（例如 Panda3D [23]）。这使得可以将环境状态表示为场景图并进行目标跟踪。当满足特定条件时，会触发相应的回调函数。例如，两个运动物体在草图板中以其包围盒作为碰撞节点表示。如果两个包围盒相交，则会触发一个碰撞事件。

示意图1

示意图2

D. 分析

为了研究所提出框架的有效性，需要考察一系列评估指标。此外，为了确定具体采用哪些指标，我们需要考虑涵盖自动驾驶系统评估相关方面的评估空间。因此，考虑了以下维度：

安全性 ，关注驾驶代理为驾驶员和其余交通参与者识别并执行稳定且安全计划的能力。
舒适性 ，关注驾驶代理识别和执行对驾驶员和交通友好的计划的能力。
可靠性 ，关注驾驶代理在合理时间内高效利用资源完成指定行程的能力。

1) 度量:

用于在评估空间中表示驾驶代理的定量度量。本文确定了多个度量，但仅包含其中一部分用于实验：

碰撞
1) 责任判定，通过了解碰撞中涉及的车辆的朝向和速度以及周围交通的状态来衡量。
2) 严重性计算，通过了解碰撞中涉及的车辆的运动学和速度来衡量。
车道违规
1) 不安全变道，通过检测变道过程中是否使用转向灯来衡量。此外，了解邻近交通的状态对于理解此类违规的严重程度至关重要。
2) 非法变道，通过结合地图/路线信息、车道边界并观察车道偏离事件来衡量。
3) 频繁跨越车道边界，通过结合车道边界并观察非预期车道偏离事件来衡量。
舒适性
1) 纵向（加加速度），通过了解驾驶代理的加减速模式进行测量。
2) 横向（晃动/转弯），通过了解驾驶代理的朝向和转向模式进行测量。
交通规则
1) 闯红灯，通过自车进入（或离开）交叉口时交通信号灯的状态来衡量。
2) 停车/让行标志违规，通过已知的静态道路规则以及车辆在接近交叉口时的行为（在自车通过时）来衡量。
3) 转弯车道违规，通过自车在转弯时所处的车道来衡量。

计算这些度量的确切方程不在本文的讨论范围内。

2) 场景:

场景是对用于评估特定驾驶代理的测试用例的表示。为了使场景具有意义，它们需要涵盖基础和极端驾驶情况以及各种情况。尽管已有努力致力于场景格式和含义的标准化[25]，然而，场景与数据源/数据之间存在解耦问题。

表示仍然是一个具有挑战性的问题。场景设计和标准化不是本文的重点，但已经创建了一些场景来验证实验。示例场景包括：

停车场
1) 在室外停车场内行驶并尝试垂直停车。
2) 在室内停车场（具有多层结构且传感器信号受限）内行驶并尝试垂直停车。
信号交叉口
1) 在交通信号灯控制交叉口进行无保护左转。
无信号交叉口
1) 驾驶通过各支路优先级不同的T型交叉口。
2) 驾驶通过三向或四向停车标志控制交叉口。
道路巡航
1) 在单车道道路上从A点驾驶到B点（包括车道内障碍物避让）。
2) 在多车道道路上从A点驾驶到B点（包括变道）。

3) 实验：

为了展示该框架的能力，确定并研究了四个用例。在第一个用例中，使用基于ROS的内部模拟器来研究自动驾驶系统在三向停车标志控制交叉口应对危险情况时的规划模块性能。在第二个用例中，使用相同的模拟器但采用不同场景，测试自动驾驶系统对交通信号灯控制交叉口的响应能力。在第三个用例中，在开源 CARLA模拟器[26]上测试了自动驾驶系统保持车道的能力。最后，该框架被用于通过采集的数据评估车辆在自动驾驶模式下的道路测试性能。图3描绘了用户如何通过模拟器服务运行一组实验。通过指定实验配置（指标、场景、自动驾驶系统和模拟器），模拟器服务的输出是一系列评估数据包，这些数据包由草图板处理，然后通过指标列表进行评估，形成实验结果。

a) 内部模拟器上的停车标志交叉口：

设计了一组实验，用于观察自车（由自动驾驶系统控制）在停车标志交叉口场景中与另一车辆（NPC车辆）交互时的行为，其中NPC车辆模拟“鲁莽驾驶者”，会忽略停车标志并以恒定速度通过交叉口。选择了三条轨迹和四种速度组合用于NPC车辆，该场景的道路布局如图5所示。目标是评估自车是否能在紧急情况下及时停车以避免碰撞，同时确保其遵守关于停车标志的道路规则。共运行了12个场景（3条轨迹 × 4速度）以及一个无NPC车辆的控制场景，结果如表I所示。

除了碰撞指标和责任分配指标外，还引入了纵向舒适度指标和停车标志违规指标，以便在成功避免碰撞的情况下提供更多的上下文信息。从表I可以看出，该自动驾驶系统在应对高速接近的NPC车辆时（无论方向如何）表现良好，但在应对某些情况下的NPC车辆时似乎存在困难。

在较低速度下，各种方法的表现有所不同。还值得注意的是，与北向南轨迹相对安全的情况相比，北向东轨迹似乎是该自动驾驶系统最危险的情况。

尽管有时会发生碰撞，但该自动驾驶系统仍以适当的方式遵守停车标志，如在全部12个数据点中均未出现停车标志违规行为所示。由于即使成功避免碰撞也需要强力制动，因此在所有未发生碰撞的情况下，纵向舒适度指标评分为2/5（发生碰撞时为不适用）。

b) 内部模拟器上的交通灯交叉口：

设计了一组不同的场景来测试自动驾驶系统对交通信号灯的反应，其中当自车接近交叉口时，交叉口处的交通信号灯会在不同距离处变为红色。实验分别在距交叉口25米、20米、10米和5米的距离下进行。图6显示了在模拟器上运行的其中一个实验的截图。

自动驾驶系统在红灯前停止的性能如表II所示。结果表明，自动驾驶系统完全能够在10米及以上的距离处停止，但在交叉口距红灯5米处停止时存在一些困难。

三、结论与未来工作

由于现有的评估方案缺乏来自不同测试来源的全面评估，我们的解决方案证明了其能够从不同的模拟器和实车道路测试中进行评估的能力。通过拥有良好的场景数据库和充足的实车道路数据，该框架可以被视为汽车 V模型标准中系统验证和确认步骤的一部分。

在未来的工作中，评估框架可以扩展以支持针对特定自动驾驶系统子系统（例如感知、定位、传感器融合、路径规划或控制）的测试。目前，该框架将自动驾驶系统作为一个黑箱处理其完整堆栈。在之前的工作中，我们假设除规划模块外的所有子系统均正常工作，因此仅评估了规划代理。为了实现更有意义的评估，我们计划研究更多可按子组件分类的指标和场景。

图表部分

示意图3 非玩家控制车辆从交叉口北侧接近并左转。(b) 非玩家控制车辆从交叉口南侧接近并直行。(c) 非玩家控制车辆从交叉口北侧接近并直行。)

表I：自动驾驶系统代理在停车标志场景下的实验结果

实验编号	1	2	3	4	5	6	7	8	9	10	11	12	13
场景（NPC速度）	控制 20	图5a 15 17.5 20 22.5	图5a 15 17.5 20 22.5	图5a 15 17.5 20 22.5	图5a 15 17.5 20 22.5	图5b 15 17.5 20 22.5	图5b 15 17.5 20 22.5	图5b 15 17.5 20 22.5	图5b 15 17.5 20 22.5	图5c 15 17.5 20 22.5	图5c 15 17.5 20 22.5	图5c 15 17.5 20 22.5	图5c 15 17.5 20 22.5
闯停车标志违规纵向舒适性距离 [m]	0 5 -	0 n/a 1	0 n/a 1	0 n/a 1	0 2 0	0 n/a 1	0 n/a 1	0 2 0	0 2 0	0 n/a 1	0 2 0	0 2 0	0 2 0