自动驾驶诊断迈向五级

从四级到五级：通过自动驾驶中的诊断摆脱安全驾驶员

斯特凡·奥尔夫、马克·雷内·佐夫卡和 J. 马里乌斯·佐勒

摘要

近年来，自动驾驶已从科学研究的主要课题逐步发展到按需公共交通等实际和商业应用。随着这一发展，新用例不断涌现，使得整个系统的可靠性和鲁棒性变得比以往更加重要。在开发与运行过程中涉及众多不同利益相关方，以及独立的认证和准入机构，带来了额外的挑战。通过提供和采集与主要驾驶任务无关的运行系统附加信息（例如通过组件自检或性能观察），可提升车辆的整体鲁棒性、可靠性和安全性。本文探讨了现代真实生活用例中自动驾驶所面临的挑战，并定义了诊断系统为应对这些挑战所需具备的特性。此外，作者针对基于组件的自动驾驶架构中的异构软件环境及其特有的复杂性与困难，提出了一种诊断概念。

一、引言

自动驾驶正变得越来越重要。过去，自动驾驶研究领域曾呈现出多样化的特点，并通过学术竞赛（如 DARPA城市挑战赛[2], 、大型协同驾驶挑战赛[5],等）推动发展；而如今，通过单个车辆、自动接驳车以及自动化配送交通等方式，其可行性得到了更进一步的展示。像贝尔塔·本茨驾驶[17]这样的演示表明，车辆已经能够在特定场景下实现自主操作。然而，目前仍缺乏基本概念，使自动驾驶车辆能够对其自身能力和当前状况进行自我评估，从而以注重安全性和风险意识的方式进行决策与行动。特别是从SAE等级4级向5级迈进的过程中，这种自我评估能力[7],变得尤为必要。这种自我评估与判断超出了当前安全性判定的概念和方法，因为现有的安全性评估通常需要作为第三方系统集成，以提供独立且可靠的判断结果。

现代日益发展的自动驾驶应用给自主系统带来了诸多挑战。让公众能够使用自动驾驶技术的同时也带来了新的复杂用例。非专业管理员或自动驾驶车辆的乘客可能希望获得关于故障及车辆潜在响应的抽象信息。例如，如果车辆将执行意外的驾驶操作（如紧急停止，见图1 a），提前向乘客发出警告显然非常重要。大型自动驾驶车辆车队在发生故障时需要通知运营商，以避免声誉受损。远程支持可能是一种解决方案，但要求远程操作员具备关于故障的适当技术洞察（图1b）。这些情况表明，对于现代自动驾驶而言，车辆健康状态的信息至关重要。加之复杂的软件环境以及系统对快速动态适应的需求，提升安全性、可靠性和鲁棒性的复杂性正在迅速增加。因此，需要一个诊断系统来提供有关系统功能的深入信息。本文提出了一种自主系统的通用诊断概念。

本文的结构如下：第I节阐述动机后，第II节介绍了当前的方法。第III节解释了此类系统的必要性背景并推导出具体需求，而第IV节展示了主要挑战。第V节阐明了自动驾驶中的诊断，并在第V‐B节中引入了诊断概念。第VI节总结了论文的主要论述，并指出了自动驾驶诊断领域的未来研究问题，以此作为全文的结论。

II. 相关工作

自动驾驶中的诊断系统自自动驾驶早期就已存在。例如，在[10],中描述了一种用于在压力测试期间诊断车辆的系统，此类测试通常由人类驾驶员完成。该诊断系统旨在取代人类驾驶员，且仅限于在测试条件下检测被测车辆自身的故障。[16],中提出了人类驾驶员行为的异常检测，该方法基于离线大规模车辆数据提供了一种诊断方法。

针对诊断系统的软件架构，已开展多项研究（例如 [11]）。关于嵌入式智能网络诊断功能需求的研究（[1]）将适应性确定为该架构的关键目标。同样，[3]提供了一种用于远程实时车辆诊断的参考架构，重点在于开发与实施。在[12]中提出了一种自动驾驶的参考架构，该架构将性能评估纳入系统组件中。一般自动驾驶的软件架构表明基于组件的设计是典型方法，如[13],[14]或 [12]所示。

除了自动驾驶之外，诊断还出现在其他研究领域。配电网络和发电厂需要进行诊断（例如[9]）。列车控制系统是另一个涉及诊断的研究领域（例如[4]）。也存在不限于特定应用的诊断研究（例如[15]）。在[8]中描述了一种基于模型的故障检测与诊断方法。

尽管所有这些方法都提出了针对现代自动驾驶特定挑战和需求的诊断方法与技术，但仍缺乏一种整体化、可适应的诊断架构。因此，本文首先旨在阐明复杂现代自动驾驶的独特挑战；其次，将针对已识别的挑战，提出面向自动驾驶的诊断方案及相应的架构概念。

III. 自动驾驶生态系统

自动驾驶在从开发到运营的生命周期中表现出一些显著特征。如今，越来越多的新用例和应用致力于将自动驾驶推向公共领域。随着自动驾驶汽车在公共道路上的部署，准入流程 suddenly play a big role。本节将介绍现代自动驾驶的背景及其生态系统。

A. 现代自动驾驶

近年来，自动驾驶出现了新的应用和用例。除了面向个人用户的具备自动驾驶功能的传统汽车外，还涌现出一系列新的应用和用例。不仅主要的汽车制造商在自动驾驶汽车的研究上投入了大量精力，公共交通机构也在致力于开发其专业领域的应用。目前存在大量的评估自动驾驶在公共交通领域优势的项目数量众多。这些项目通过提供自动驾驶汽车或少量座位的小型穿梭巴士作为按需服务，为居民提供新的服务。此外，还有通过自动驾驶汽车配送包裹或日常消费品的想法。通过在这些用例中利用自动驾驶汽车，减少了对专职人力人员 （如出租车/公交车司机或配送员工）的需求。

这些新用例和应用有一个共同点，即单个公司或机构部署大量自主无人车辆。虽然这减少了人力消耗，但需要为大规模车辆编队部署控制策略。

B. 准入流程

在大多数国家，参与公共交通的车辆需遵守或多或少严格的法规和法律。这些法律不仅可能规范交通参与者的行为，例如通行权，以确保道路安全，而且通常还需要一个准入流程。由于完全自动驾驶车辆尚未向公众提供，此类流程尚未建立。

例如在德国，自动驾驶研究车辆要参与公共道路交通，需要获得通用准入规则的豁免。为了获得此类豁免，必须对车辆的软硬件进行检查。基于此专家意见，地区管理机构可针对个别情况颁发豁免。在大规模生产中，该过程是在车辆开发期间完成的。这两个例子都涉及专家意见和安全分析。自动驾驶这一复杂领域进一步加剧了该流程的难度。

由于目前尚无针对自动驾驶车辆功能的既定批准和发布机制及程序，由专门的第三方组件根据领域专家的意见，遵循普遍可理解且标准化的流程来提供此类功能是合理的。标准化诊断为验证系统并使其满足准入要求提供了一种途径。

C. 软件设计

在自动驾驶汽车的软件方面，通常采用基于组件的设计方法（[13],[14],[12]）。这一概念由所涉及的不同任务（如定位、路径规划、目标检测等）的明确划分而得以确立。在基于组件的设计中，每个组件通过定义好的接口提供功能，同时隐藏其实现细节。基于组件的架构使得多方能够独立开发，从而实现快速开发。松耦合组件设计提供了可互换性，并摆脱了对单一物理和非物理平台的限制。

在机器人研究中广泛应用的、采用松散耦合的基于组件的设计方法的软件框架示例是Robot OperatingSystem(ROS) [6]。

IV. 挑战

过去几年已开展了大量研究，使自动驾驶成为可能。从早期车辆仅能在理想条件下识别和跟随车道标记，到如今改进的传感器硬件、传感器融合以及复杂的软件组件的开发，自动驾驶汽车在应对复杂且困难的真实世界场景时，其行为表现已几乎与人类驾驶员无异。尽管已能处理复杂的环境和情况，但要将自动驾驶推广至大众，下一步还需应对开发者必须面对的更广泛情境。这一情境的特点是涉及法规、经济因素以及变革后的开发流程。因此，不仅需要解决安全性问题、鲁棒性以及环境复杂性，还需应对由多方相关方（图2）、独特的软件开发环境、经济因素、法规流程以及扩展的用例所带来的新挑战。下文作者将识别并讨论在迈向将自动驾驶汽车推向公众的下一步过程中所出现的主要附加挑战。

A. 多方参与方

在现代自动驾驶汽车从开发到运行的生命周期中，涉及多方参与方。由于成功驾驶自动驾驶汽车需要广泛的功能任务，因此涵盖了各种人工智能技术、方法以及不同的硬件组件开发，涉及众多专家。甚至不同的公司或制造商也可能参与这一过程。所有开发方必须就统一的软件架构和通用接口达成一致，而这在很大程度上制约了软件的复用。

此外，单个组件故障可能会影响其他组件，并且需要在软件的多个部分进行处理。而且，未识别的软件故障通常出现在边缘情况中，难以发现。因此，在自动驾驶汽车软件的开发过程中，识别整个软件中的边缘情况至关重要。

为了成功实现准入，需要独立专家来验证车辆软件的安全性和完整性（参见第III节‐B）。此外，还需解决由于不同软件组合或不匹配的接口导致的完全或部分软件故障事件，这些事件可能仅在罕见的边缘情况下出现。而且，专门用于监控此类情况的基础设施通常并不存在。这带来了巨大的工作量，并且需要类似于开发过程的不同专家参与。尽管可以通过利用基于组件的设计优势，通过批准单个组件来降低工作量，但整体系统仍需作为整体进行验证。这样一个复杂的准入流程即使可行，所需时间也远远超过通常可用的时间。

在运行过程中，人们非常关注单辆或整个自动驾驶汽车车队的当前状况。这一点对于迄今为止仍必不可少的安全驾驶员或值守人员尤为重要。一方面，值守人员必须能够识别出车辆的个别软件故障以及安全性下降的情况，以便采取适当的应对措施来确保乘客的安全。例如，应对措施包括手动将车辆转入安全状态，如驶向路边。同样，从控制中心监控车辆状态的远程监管员在必要时也能进行干预。另一方面，大型车辆编队的运营商则希望获得抽象化的总体状态信息，以最大化经济效益。

在运行过程中，还有其他交通参与者，他们显然也关心自动驾驶汽车的安全性和可靠运行。通常认为，自动驾驶汽车在安全性方面始终处于正常功能状态。但在出现软件缺陷的情况下，其他交通参与者可能无法分辨其异常。

自动驾驶软件的多样化格局以及各种用例使得不同参与者之间的协作尤为困难。显然，参与者将受益于一种通用基础设施，该设施能够监控状态和故障，同时通过抽象不必要的实现细节，为底层软件系统提供洞察。

B. 软件开发格局

自动驾驶中的软件架构如上所述（第III‐C节），以基于组件的方法为特征。异构组件通常通过复杂的依赖关系相互松散耦合。从感知和传感功能到决策再到执行的各种独立任务被封装成具有专用接口[13]的组件。这些任务本身及其中间依赖关系极为复杂。因此，来自不同领域的专家需要协作并就通用接口达成一致。因此，开发与测试不仅可以围绕单个组件进行，还可以围绕整个系统展开。此外，这种协作很少集中在故障和故障上，而是集中在自动驾驶任务本身。自动驾驶汽车软件的复杂性使得评估故障对整个系统的影响变得更加困难。

组件可能会被单独更新和更改，这也会导致软件普遍容易老化。组件协作可能受到影响，安全可靠的执行可能无法再得到保障。接口定义不充分（例如由于功能变更或修改后的需求）会加剧这一问题。为了应对这一挑战，需要跟踪单个组件变更的影响，并采取适当的应对措施。这一点在开发阶段以及运行期间均适用，因为边缘情况可能仅在运行时出现。

C. 安全与可靠性

自动驾驶当然需要确保安全性。在任何情况下，都必须排除对乘客或其他交通参与者造成伤害甚至死亡的风险。这一点对于早期自动驾驶和现代自动驾驶均适用。不同的是此类事故带来的后果。现代自动驾驶由大型企业运营，尽管这项业务可能盈利，但一旦发生事故，即便自主系统并非责任方，也可能导致声誉受损。因此，完全无人驾驶车辆的安全性是绝对必要的。可靠性同样如此。如果车辆因故障而导致用户自身或外界出现令人困扰的行为，则可能遭到用户抵制。否则运营商将不可避免地面临声誉损害。因此，自动驾驶系统的无故障运行至关重要。

D. 复杂用例

随着自动驾驶技术逐渐向大众普及，新的用例不断涌现。这些用例不同于早期的单一任务应用，因其融合了多种功能，使得现代自动驾驶更加复杂。例如，公共交通领域的应用不仅局限于驾驶任务，还提供门到门的按需出行服务。在运行时调整路线、识别接载乘客的可能停靠点等，如今都已成为自动驾驶任务的一部分。城市甚至可能要求自动驾驶汽车连接至智能基础设施。不难想象，这种复杂性的急剧增加会对自主系统的安全与可靠性构成威胁。因此，为应对这些复杂性，对驾驶任务适应性的深入洞察变得至关重要。

V. 自动驾驶中的诊断

在开发和运行中涉及不同参与者的复杂且异构的自动驾驶环境中，新型用例不断涌现，并且对监控以及协调大型车队同时提高正常运行时间和可用性的需求日益增长，因此迫切需要一种独立、整体性的增强鲁棒性的解决方案。第IV节中指出的挑战表明，此类解决方案需要收集和处理整体系统的状态信息，这一领域通常被称为诊断。下文将通过首先根据自动驾驶场景的特征定义和分类诊断，来描述此类诊断系统的概念。诊断的基础是系统报告或从中获取的状态信息，这些信息经过处理后可提供整体健康检查。随后将讨论不同类型的状态信息及其获取方式。同时，还提出了处理这些信息以用于进一步用途的需求。基于这些基础，我们提出了一种多功能学习型诊断系统架构的概念，以应对上述挑战。接下来的逻辑步骤是利用状态信息主动且自动地减轻错误的影响，我们称之为自动修复。因此，我们还讨论了在自动驾驶中将自动修复机制与诊断相结合的需求和可能性。

A. 分类

自动驾驶架构通常由具有独立功能的不同异构部分组成（参见第III‐C节）。结合新的复杂用例、从开发到运行的各个参与者，以及第IV节中确定的其他挑战，推导出自主系统的健康状态或适应性至关重要。

分析和推导系统健康状态的任务通常被称为诊断，即检查、分析并对对象的状态做出判断的过程。在自动驾驶应用的特征中，我们将诊断定义为：通过分析组件自身状态并间接观察其行为，以获取与驾驶任务无关的额外信息，从而支持系统元参数改进（如鲁棒性和可用性）和/或修复技术，对异构的、基于组件的软件系统进行独立检查的任务。

B. 状态

在基于组件的软件架构中，诊断信息通过状态消息传递。这些状态可直接报告组件或其子部分的执行情况。但其他信息可能需要先进行解释，才能用于系统诊断。此外，在自动驾驶系统的动态发展中，可用的诊断信息可能会不断进步。因此，诊断状态不应局限于特定的状态空间或类型。多功能诊断框架提供了处理各种可用信息的可能性，从而推断系统的健康状态。

简单的状态消息可能会直接报告组件的功能。这通常是通过离散的方式完成的状态空间。此类离散状态的示例可能包括[“正常”,“警告”,“错误”]，或诸如[0, 1, 2, 3]之类的运行能力等级。连续状态空间也是可能的，其中状态以例如[0.0… 1.0]或[0… 100]的形式给出。复杂的数据，例如传感器输出，也可能被视为诊断相关的信息。此外，与驾驶任务无直接关联的元信息，如消息频率、响应时间或CPU负载，也可被利用。这些示例的共同点在于，为了判断组件的健康状态，需要对状态进行解释。例如，在连续状态空间的情况下，可以使用阈值，当状态值高于阈值时，表示该组件运行正常。显然，此类解释高度依赖于具体应用，并可能随时间变化。因此，诊断系统需要具备分析与适应机制。

获取状态消息的方法可能根据系统的特性而有所不同（见图3）。大多数组件可以通过向诊断系统报告，直接提供自身的状态甚至其子任务的状态。但如果某个特定功能未提供状态信息，诊断系统也可能通过观察某些参数来推导出状态。这些参数可以是与驾驶任务本身相关的元参数或消息。

对于随时间变化的分析，需要关联来自同一来源的状态消息。来源、时间戳和ID属性可用于实现此类深入分析。随后，状态消息也可被分配到不同的状态通道。此外，在基于消息的环境中，诊断系统需要意识到状态消息的缺失并不一定意味着故障。根据消息传递基础设施的可靠性，状态信息也可能无法及时送达。例如，某些在执行驾驶任务时遇到困难的组件（可能由于复杂的驾驶操作）可能不会持续报告。

C. 诊断概念

处理系统状态需要一个诊断架构，以应对不同类型的状态消息、它们的状态空间及其获取（第V‐B节）。获取的状态消息以及组件自身进行的状态评估也可能容易出现错误或基于错误的假设。由于诊断机制依赖于可能不可靠的基础设施，可能会发生消息时序问题和消息丢失。面对这些不确定性，诊断架构需要评估单个状态报告的可靠性。此外，可能无法观察整体系统或其部分的状态。依赖“黑箱”组件提供的状态存在导致部分评估的风险。由于系统的复杂性或缺少接口，系统的某些方面也可能无法直接观测。因此，实现完整状态报告和观测的情况很少见，必须通过推断隐藏状态来揭示系统未知的信息。另一个方面是，系统的复杂依赖关系也可能反映在状态消息之间的相互依赖关系上。对这些依赖关系的分析能够揭示系统状态的有用信息。因此，接下来我们将提出一种诊断概念，以应对自动驾驶领域（第 III节）中存在的上述假设及其独特挑战（第IV节）。

我们假设，对于高度自动化驾驶而言，必须采用整体诊断方法，以同时监控整个驾驶功能，涵盖从感知、情境感知与解释到规划和车辆执行的各个功能。该架构（图4）由五个部分组成，旨在处理系统提供的各种交付和直接观测到的状态消息，并对状态和聚合的未来发展进行预测，从而深入理解故障机制。首先评估输入状态消息的可靠性，然后计算依赖关系和隐含状态。基于这些信息，生成状态发展的预测以及所有已知状态的聚合。经过处理的状态信息可进一步用于其他用途，例如自动修复机制，或帮助参与者进行故障处理。状态的可靠性、依赖关系和隐含状态的推断由概率模型指导。为了应对变化的系统、新用例和未预见的情况，这些模型在运行时自动更新，从而提高系统的鲁棒性。各个模块描述如下：

1) 状态分析 ：状态消息本身可能不可靠。因此，需要首先对各个状态进行分析，如图4左下角所示。该分析基于此状态通道上消息的时间序列，为每个观察到的状态消息分配一个可靠性值。传入的状态消息会根据其来源和ID进行记录和关联。在自适应概率状态模型的基础上，还会考虑后续诊断处理的洞察结果。因此，得到的可靠性值衡量了该消息相对于所有诊断消息过去和当前变化的发生可能性。该可靠性值随后被用于进一步诊断处理中。

2) 依赖关系和隐含状态 ：在基于组件的自动驾驶架构中，信息在多个组件之间进行处理和共享。当发生故障时，这种关系会导致其他组件出现级联故障效应。通常情况下，单个组件的故障会导致系统其他部分所必需的消息缺失。当然，这种行为也会反映在系统诊断中。一个组件故障的迹象会传播到系统其他部分的状态更新变化中。因此，状态信息彼此高度依赖。但这些依赖关系很难预先获知，且可能存在隐藏的依赖关系。由于观察到的状态消息仅捕捉了系统健康状态的一部分，这些依赖关系也可能由隐含状态引起。因此，诊断系统的任务是确定这些依赖关系以及隐含状态（见图4）。这一过程也由在运行时不断更新的模型驱动，而这些模型反过来又依赖于学习到的状态变化和预测机制。

一方面，依赖信息有助于预测其他组件中的故障，而隐含状态的信息则可用于另一方面的聚合任务。然后，这些信息可由后续模块使用，例如应用早期修复机制以减轻故障的影响。

3) 状态预测 ：诊断系统的一个目标是在故障导致运行损坏甚至安全问题之前，提供采取适当应对措施所需的必要信息。实现这一目标的关键在于生成所观测状态的预测，进而可用于推断各个组件未来健康状态的结论。诊断架构利用上一步推断出的状态之间的依赖关系，来预测所有观测到的状态和隐含状态的可能变化。该过程在运行时还依赖于自适应预测模型。

4) 聚合 ：快速获取相关信息对运营商、安全驾驶员或技术人员至关重要。远程操作员主要关注大规模车队的概览信息，而安全驾驶员和技术人员可能需要深入了解故障情况。这些情况的共同点是用户期望诊断系统提供指导。这种指导可以通过基于用户定义的视图对状态进行聚合来实现。例如，一个简单的视图可通过将传感器和算法状态分组并推导出该组的总体状态，从而轻松区分传感器和算法状态。同样，也可为整车分配单一状态，而整车状态通常无法直接观测。不同的聚合方式随后也可被其他模块用于增强系统的鲁棒性和可靠性。

5) 自适应模型 ：系统的变化和未见过的边缘用例使得诊断系统必须进行适应性调整。设想一下复杂用例，其中不同的运行模式需要按顺序执行。以接驳巴士为例，自动驾驶汽车不仅需要行驶，还必须确保在站点时车门开启，并对路线调整做出响应。在继续行驶前，车门必须关闭，否则将存在重大安全问题。显然，开发人员可以提前处理此类示例性问题，但随着系统的复杂性和灵活性增加，很难事先解决所有此类问题。因此，诊断系统必须能够适应各种可能的变化，以提供有关系统功能的最合适信息，从而提高在未知情况下的鲁棒性和可靠性。该概念通过调整概率模型来应对这些变化，这些模型用于分析和预测状态、推断它们之间的依赖关系以及识别隐含状态。通过紧密耦合这些模型，可以实现更深入的理解。例如，状态变化的预测与已识别的依赖关系密切相关。

D. 自动修复

为了使深入诊断发挥积极作用，所提供的洞察需要被处理，以提高自动驾驶系统的安全性、可靠性和鲁棒性。远程人工操作员可能会利用这些信息在发生故障时进行干预或协助。但更优的方案是一种架构，能够基于可用诊断自动维持系统处于安全可靠状态。

诊断信息。在发生故障时，这可能包括防止某些驾驶操作或激活紧急轨迹。从组件层面来看，单点故障可能会影响其他组件，从而影响驾驶任务本身，因为必要的消息可能不再生成。此时，自动修复机制将激活其他能够部分完成缺失任务的组件。此场景如图5所示。通过提供所需的功能，系统便能够继续安全运行。修复机制的关键在于尽早了解故障及其影响，而这些信息由诊断系统提供。

VI. 结论

本文阐述了诊断功能的必要性。结合现代自动驾驶的典型用例，推导出相应的需求，并在此基础上提出了一种跨系统诊断的抽象概念，该概念包含五个组件：对状态消息及其随时间变化的个体分析、推断这些状态之间的依赖关系并识别隐含状态、预测未来状态变化以及相关信息的聚合。作者还指出，自动修复机制可以利用所生成的信息，从而推动自动驾驶从4级迈向5级。

从当前的概念性工作可以推导出以下关键研究问题：

• 应提取哪些诊断信号，才能有利于整个系统的安全、鲁棒性和可靠性？
• 能否通过诊断识别系统的原子单元，以及这是否为增加可靠性和鲁棒性的冗余设计提供了潜力？
• 诊断概念的哪些方面需要学习才能提供最大的灵活性？

这些问题将在基于本文的未来研究工作中得到解决。