远程协助或远程驾驶： 操作设计领域对 ADS 支持系统选择的影响-计算机科学-人工智能-自动驾驶系统-远程操作.pdfVIP

远程协助或远程驾驶：

操作设计领域对ADS支持系统选择的影响

OleHansBenediktWalter

DepartmentofOperationalSafetyInstituteofAircraftDesign

VayTechnologyGmbHUniversityofStuttgart

Berlin,GermanyStuttgart,Germany

ole.hans@vay.iowalter@ifb.uni-stuttgart.de

本摘要—高级自动驾驶Systems(ADS)可以处理许多情况，其他交通参与者的不可预测行为而加剧。因此，这些限

但仍会遇到需要人工干预的情况。在车辆内有实际驾驶员的系统制对驾驶任务的全面自动化以及此类systems[2]的更广

译中，通常为SAELevel3系统，这种干预相对简单，并由车内驾泛社会接受构成了挑战。

中驶员处理。然而，对于Level4系统来说，复杂性增加，在大多数

为了解决ADS无法继续执行动态驾驶任务

1情况下，车内不再有实际驾驶员。应对这一挑战的两个常见行业

v解决方案是集成远程支持系统，如远程驾驶System(RDS)或Tasks(DDT)的潜在情况，这些系统配备了最小风险

7远程协助System(RAS)。虽然显然自动驾驶系统将需要其中Maneuver(MRM)能力，安全地停止车辆以达到最小

4

3一个系统，但对于特定ADS应用中如何评估任一系统的适用性风险Condition(MRC)。从那个MRC（最小风险状态）

4则不太清楚。当前的选择过程通常集中在系统架构及其设计和集开始，ADS通常能够恢复DDT（动态驾驶任务）。然

1

.成挑战上。此外，由于许多ADS开发者选择自行开发远程系统

7而，在某些情况下并非如此，这导致了ADS仍依赖支

0解决方案，因此采用更简单的方案来简化开发和集成工作是有利持系统来处理超出其自身能力范围的特定场景。常见的

5的。虽然这些决策点无疑相关，但这种方法忽视了最关键的因素：

2用例以及在操作设计域Domain(ODD)背景下ADS和远程解决方案包括集成远程驾驶System(RDS)和远程协助

:

v支持系统的互补性。本文提出了一种基于定义的操作设计域和用Systems(RAS)，尽管它们有相似之处，但往往基于系统

i

x例分析来选择RDS或RAS作为ADS支持系统的方法。为架构或短期可用性而非彻底评估其对特定ADS使用案

r

a此，文章应用PEGASUS框架系统地描述和分析操作设计域。例的适用性而被选择。这种方法经常导致产品级别的次

引入了结构化框架以根据明确的准则评估并选择最合适的远程支

优结果，某些关键使用案例仍然未得到解决。

持系统。

IndexTerms—自动驾驶系统，远程驾驶系统，远程协助，当前的机器人出租车项目如Zoox或Waymo选择了

运行设计域，远程操作，远程驾驶，脱离事件远程辅助解决方案。看来这种选择主要是出于两个原因：

I.介绍首先，RAS平滑地集成到现有的ADS中。远程操

作员的输入只是替换了感知输入。其余的ADS管

自动驾驶Systems(ADS)被广泛认为是改造交通行

道保持不变，输出仍然是由ADS生成的，而不是远

业的关键技术，因为它们有可能提高效率、安全性和驾