广告
SOTIF：自动驾驶汽车测试和验证的挑战
2020-07-20 17:41:03· 来源：上海控安/轩辕实验室
软件测试常常只是一个简单的BUG搜索，而不是一个经过深思熟虑的确保质量的实践。要大规模部署安全的自动驾驶车辆，需要一种比简单的系统级测试-故障补丁-测试周
软件测试常常只是一个简单的BUG搜索，而不是一个经过深思熟虑的确保质量的实践。要大规模部署安全的自动驾驶车辆，需要一种比简单的系统级测试-故障补丁-测试周期更有条理的方法。ISO26262开发V流程建立了一个框架，将每种类型的测试与相应的设计或需求文档联系起来，但在适应处理自动驾驶汽车面临的各种新测试问题时，会遇到一些挑战。根据自动驾驶车辆V模型，提出了自动驾驶车辆测试的主要挑战：驾驶员不再参与控制、复杂需求、非确定性算法、归纳学习算法和故障操作系统。在这些不同的挑战领域中，通用的解决方案似乎效果很好，包括：使用相继放松的操作场景的分阶段部署，使用监视器/执行器对来将最复杂的自动功能与简单的安全功能分离，以及将故障注入作为执行更有效的边缘情况测试的一种方式。为了提供高水平自主，虽然安全认证类型算法方面仍存在重大挑战，但似乎可以将体系结构及其随附的设计过程构造为能够采用现有的软件安全方法。
1 简 介
尽管自动驾驶汽车最近成为了一个热门话题，但其背后的技术已经发展了几十年，可以追溯到自动公路系统项目[1]以及之前。从那些早期的演示开始，该技术已经成熟到先进的驾驶员辅助系统(ADAS)，如自动车道保持和智能巡航控制是许多车辆的标准配置。除此之外，还有许多处于不同发展阶段的完全自主汽车项目，包括多车车队的扩展道路测试。
如果你相信权威人士的说法，那么全自动汽车(通常被称为自动驾驶汽车)的全面普及指日不远了。然而，正如传统汽车行业所熟知的那样，制造几辆汽车，让它们在有专业安全驾驶员的合理良性环境中运行，与制造数百万辆汽车，让它们在一个没有约束的世界中运行，两者之间存在巨大差异。有人说，成功的测试和几千公里(甚至几十万公里)的驾驶经验意味着，自动驾驶技术基本上已经准备好全面部署。但是，很难看出仅仅这样的测试就足以确保足够的安全性。实际上，至少一些开发人员似乎在做更多的工作，但问题是还需要做多少工作，以及我们如何知道最终的工具在部署时是非常安全的。
在这篇文章中，我们探索了一些开发者的挑战，这些开发者正试图获得完全自主，以及NHTSA级别4[2]车辆大规模部署的资格。因此，我们跳过了潜在的半自动化方法来处理那些驾驶员完全不负责车辆安全操作的系统。我们进一步限制范围来考虑如何在ISO 26262 v框架内设计和验证这样的车辆。这个限制的原因是，这是一个确保安全的可接受的做法。基于计算机的系统应该被认为是不安全的，除非有令人信服的其他理由，这是一个公认的安全原则(即，安全必须表现出来，而不是假设)。因此，自动驾驶汽车不能被认为是安全的，除非和直到他们被证明符合或映射到ISO 26262或其他一些适当的，广泛接受的软件安全标准。
完全测试不可行
车辆水平的测试不足以确保安全。人们早就知道，对系统进行足够彻底的测试以确保系统运行的可靠性是不可行的
例如，假设有100万辆汽车，每天运行一小时(即每天106小时运作时间)。如果安全目标是每1000天发生一次灾难性计算故障，那么安全目标是109小时的平均灾难性故障时间，这与飞机的允许故障率[3]相当。请注意，这承认了在车队的生命周期中，由于计算机缺陷或故障而导致的几次灾难性故障发生的可能性。但是，如果与手动驾驶车辆相比，由于驾驶员失误而导致灾难性事故的发生率大大降低，那么这一目标可能是合理的。(这只是一个失败率的例子。人们可能会为这个比率的高低提出论据，但它被选为一个合理的比率，说明了实现安全方面的一些困难。)
为了验证车辆的灾难性故障率为每109小时一次，一个人必须进行至少109车辆操作小时的测试(十亿小时)[4]，事实上必须测试几倍的时间，可能会重复多次这样的测试来实现统计学意义。即使这样，也假定测试环境是真实部署的高度代表，并且导致灾难的环境是以随机、独立的方式出现的。在不危及公众安全的情况下，建立一支能在典型测试环境下运行数十亿小时的大型实体车队似乎是不切实际的。可能包括仿真、形式证明、故障注入、引导的基础上稳步增加车队规模、获得非关键角色的组件技术的现场经验和人员审查等方法。(组件级测试也起作用，但是为物理硬件设备积累109个小时的预部署测试仍然是不切实际的。)当人们考虑到自动系统的测试甚至比日常软件系统的测试更困难时，情况会变得更糟，下面将对此进行讨论。
也就是说，对于相对非关键的计算系统，可以使用测试作为验证适当安全级别的主要基础。这是因为涉及低严重程度和低暴露的故障可能比灾难性故障的发生率更高。例如，如果特定类型的故障每1000小时发生一次是可以接受的(因为这种故障会导致最低成本的事件或轻微的中断)，那么通过数千小时的测试可以可靠地验证该故障率。这并不是说所有的软件质量过程可以放弃这样的系统， 而是如果平均故障间隔时间要求相对宽松，那么适当的测试和故障监视策略可能可以验证具有适当质量的组件实际上达到了可接受的低故障率。
以V模型为起点
因为系统级测试无法完成这项工作，所以需要更多的测试。这正是拥有一个更健壮的开发框架来创建安全关键软件的关键所在。
软件开发V模型在汽车上的应用由来已久。它是20多年前纳入MISRA指南的发展参考模型之一[5，6]。最近，它被提升为形成ISO26262[7]基础的参考模型。
通常，V模型(图1)表示一个有方法的创建过程，然后是验证和确认。V模型的左侧工作方式是从需求到设计再到实现。在每个步骤中，系统通常被分解为并行处理的子系统(例如，有一组系统需求，但是每个子系统的设计是独立的)。当系统从小型组件恢复到系统级评估时，V的右边迭代地验证和验证越来越大的系统块。尽管ISO 26262对该模型进行了详细的阐述，但我们仍然保持通用性，以讨论高级思想。
尽管ISO 26262及其V框架通常反映了确保汽车安全的公认做法，但在将汽车的技术映射到V模型方面，全自动汽车面临着独特的挑战。
图1 一个通用的V模型
2 驾驶员不参与控制
对于全自动驾驶汽车来说，最明显的挑战可能是，关键在于驾驶员不再真正驾驶汽车。这意味着，根据定义，在[2]操作期间，司机不能再为车辆提供控制输入。
可控性的挑战
对于低完整性装置的典型汽车安全论证可能取决于人类驾驶员施加控制的能力。例如，在一个高级的驾驶员辅助系统(ADAS)中，如果一个软件故障导致了一个潜在的危险情况，那么这个驾驶员可能被期望越过那个软件功能并恢复到一个安全的状态。司机们也有望从严重的车辆机械故障中恢复过来，比如轮胎爆裂。换句话说，在有人驾驶的车辆中，驾驶员负责采取正确的纠正措施。驾驶员没有能力采取纠正措施的情况被认为是缺乏可控性，因此必须设计到更高的汽车安全完整性水平，即ASIL[8]。
有了全自动驾驶汽车，驾驶员就不能指望处理特殊情况了。相反，计算机系统必须承担主要异常处理程序的角色，处理错误、故障和超出指定的操作条件。与ADAS系统相比，让计算机负责异常处理似乎可能会极大地增加自动化的复杂性。ADAS系统的组合，如车道保持和智能巡航控制，似乎诱人地接近于完全自主操作。然而，一辆全自动汽车必须要有额外的复杂性来处理所有可能出错的情况，因为当事情出错时，没有司机来抓方向盘和刹车。
自主体系结构方法
在ISO 26262的背景下，让计算机负责提出了评估风险的两种策略。一种策略是将风险评估[8]的可控性部分设置为难以控制或无法控制的C3。如果严重程度和暴露程度很低，这可能是一个可行的选择，因此可以指定较低的ASIL。但是，在中度或高度严重和暴露的情况下，该系统必须设计到一个高的汽车安全完整性水平(ASIL)。(有些人可能会说，应该有一个更高的可控性分类C4，因为自动化系统有时候不仅不能提供安全功能，还有可能主动采取危险积极行动。但我们假设现有的C3就足够了。)
另一种处理高ASIL自治功能的方法是通过结合监视器/执行器架构和冗余来使用ASIL分解[9]。监测/执行器架构是这样一种架构，其中主要功能由一个模块(执行器)执行，一个成对的模块(监视器)执行验收测试[5，10]或其他行为验证。如果执行器动作不正确，监视器将关闭整个功能(两个模块)，导致故障-沉默系统(任何故障都会导致一个沉默组件，有时也称为故障-停止或故障-安全。)
如果监视器/执行器对(图2)设计正确，只要监视器具有非常高的ASIL并检测到监视器中所有可能的故障，执行器就可以设计为一个低ASIL (此外，还需要检测监视器中的潜在故障，以避免因执行器故障而导致监视器损坏) 。如果监视器能够比执行器简单得多，减少高ASIL监视器的尺寸，并允许大部分功能复杂性被放置到一个低ASIL执行器中，那么这种结构模式将是特别有利的。
图2监控器/执行器概念图
监视器/执行器对的优点和缺点都是创建了一个故障-沉默模块(如果有故障就会关闭)。使用异构冗余(两个模块：监视器和执行器)是为了防止发生故障的执行器发出危险的命令。但是，如果出现故障，也会导致执行器功能丧失，这对于故障后必须操作的功能（例如在行驶中的车辆中转向）是一个问题。
至少，提供失败的操作行为需要更多的冗余(不止一个监视器/执行器对)，并且很有可能设计多样性，这样普通模式的软件设计失败就不会导致系统失败。这是很重要的，以避免损失的情况，如阿丽亚娜5号航班501，这是由于主系统和备份系统经历了相同的未处理异常(组件设计未预料到的)操作条件而以相同的方式故障所导致的。
应该注意的是，实现多样性并不一定是简单的，因为在同一套用于简化不同组件(例如，[12])的高级需求中存在缺陷的脆弱性等问题。然而，这种情况也适用于非自动软件。还应该注意，监视器/执行器对故障沉默的要求是基于故障独立性的假设，但这同样适用于非自动系统。
高水平自动驾驶汽车的一个关键观点是，需要有一种方法来检测自动功能何时不能正常工作(无论是由于硬件故障、软件故障还是需求缺陷)，并且在通过故障操作降级模式自动功能检测到此类故障时，以某种方式使系统处于安全状态。
3 复杂的需求
开发的V模型的一个基本特征是，V的右侧提供了一种可跟踪的方法来检查左侧的结果(验证和校验)。然而，这种检查的概念是基于这样一个假设，即需求实际上是已知的、正确的、完整的、明确指定的。这一假设对自动驾驶汽车提出了挑战。
需求挑战
如前所述，从控制系统中移除驱动程序意味着软件必须处理异常，包括天气、环境危害和设备故障。其中可能有很多不同类型，从恶劣的天气(洪水、雾、雪、吸烟，龙卷风)，到违反交通规则(错误行驶方向，其他司机闯红灯等)到当地的驾驶习惯，再到动物危害(鹿、犰狳和偶尔的蝗灾)。
任何一个开了很长时间车的人都可能遇到行驶路上的各种怪事。一个规模很大的车队，总的来说，可能会经历所有这些类型的事件，或者更多。更糟糕的是，不良事件和行车条件的组合可能会发生，其数量之多简直无法用书面需求来描述。如果结果可能是无害的，也许不需要覆盖所有这些极其罕见的组合，但是需求应该清楚地说明系统设计范围内的内容，以及哪些内容不属于系统设计范围。因此，从列举所有系统需求的文档开始的经典V流程，不太可能以严格的方式扩展到自动车辆异常处理，至少在不久的将来是这样。
操作概念方法
管理需求复杂性的一种方法是约束操作概念，并参与需求的阶段性扩展。开发人员已经在这样做了，他们可能会专注于特定地理区域的道路测试(例如，只在硅谷的分道公路上进行日间驾驶，那里降水有限，几乎没有冰冻天气)。然而，使用操作概念的想法可以在许多方向上扩展。
可以用来限制操作概念的例子包括：
•道路接入：有限接入高速公路、HOV车道、农村道路、郊区、封闭校园、城市街道等。
•能见度：昼、夜、雾、霾、烟、雨、雪等。
•车辆环境：在封闭的车库中进行自动停车，没有其他车辆行驶，只有自动车道，非自动车辆上有标志应答器等。
•外部环境：基础设施支持、预先测绘的道路、配备人力驾驶的汽车
•速度：较低的速度可能导致更低的故障后果和更大的恢复裕度
虽然上面提到的自由度仍然有很多组合(当然还有更多可以想象的)，但是从可能的操作概念中进行选择的目的并不是要增加复杂性，而是要减少复杂性。降低需求复杂性的方法是，只在完全理解需求的特定有限的情况下(并确保对这些有效的操作条件的识别是正确的)允许自主。
因此，限制操作概念成为一种引导策略，用于在日益复杂的操作环境(例如，[14，15])中依次部署更复杂的技术能力。一旦对特定的操作概念的需求有了充分的了解，就可以随着时间的推移添加其他类似的操作概念，以扩展允许的自动化场景的范围。它不会完全消除复杂需求的问题，但是它可以帮助减少需求和异常的组合爆炸。
安全需求和不变性
即使使用了受限的操作概念，使用传统的与安全相关的需求方法似乎也是不合适的。这种方法或多或少是这样进行的。首先创建功能需求。然后，在执行了一些风险评估过程之后，对与安全相关的需求进行了注释。然后，将这些安全相关需求分配给安全关键子系统。然后，设计满足分配需求的安全关键子系统。最后，通过重复该循环来标识和减轻未预料到的紧急子系统交互。
对于自治应用程序来说，安全关键需求的注释可能是不切实际的，至少有两个原因。原因之一是许多需求可能只与部分安全性相关，并且与功能性能不可避免地交织在一起。例如，当汽车移动时操作停车制动的许多条件可能是一组启动条件。然而，只有这些需求的某些方面实际上是安全关键的，而这些方面在很大程度上是其他功能相互作用的紧急后果。以驻车制动为例，当驻车制动以速度施加时的减速特性是所期望的功能之一，并且可能由许多功能需求来描述。但是，简化后，减速模式中唯一的安全关键方面可能是其他需求的紧急交互必须避免在减速过程中锁定车轮。
用于识别安全相关需求的需求注释可能失败的第二个原因是，当使用机器学习技术时，这甚至可能不可能。这是因为需求(尽管它们是)采用一组训练数据的形式，列举一组输入值和正确的系统输出。这些往往不是传统需求的形式，因此需要对需求管理和验证采用不同的方法。(参见本文后面关于机器学习的部分)。
与其试图在安全子系统和非安全子系统之间分配功能需求，不如创建一个单独的、与严格安全相关的[16]的需求并行集。这些需求往往以不变量的形式指定安全所需的系统状态(必须为真才能安全，必须为假才能安全)。这种方法可以解决性能和优化问题(最短的旅行路径是什么?)或者最优燃油消耗的速度是多少?)从安全的角度(我们会撞到什么东西吗?)
使用这种方法将需求集划分为V模型的两部分。第一组需求将一组non-safety-related功能需求，这可能是在传统的格式或一种非传统的格式如机器学习训练集。然而，根据定义这些潜在的非传统的需求并不安全，所以它可能是可以接受的，如果跟踪和验证有充足但不完美的报道。
第二组需求是一组纯粹的安全需求，它完全而明确地定义了系统的安全含义，相对独立于最佳系统行为的细节。对于不同的操作模式，这些需求可以采取安全操作信封的形式，系统可以在[17]操作信封内自由地优化其性能。很明显，这样的信封至少可以在某些情况下使用(例如，强制限速或设置最小跟随距离)。这个概念承诺相当普遍，但要证明它仍然是未来的工作。
采用一组与功能需求正交的安全需求的一个令人信服的理由是，这种方法干净地映射到监视器/执行器架构。功能需求可以分配到一个低ASIL执行器功能块，而安全需求可以分配到一个高ASIL监视器。多年来，该思想一直被非正式地用作监视器/执行器设计模式的一部分。我们建议将此方法提升为设计自动驾驶车辆设计、需求和安全案例的主要策略，而不是将其降级为详细的实现冗余策略。
4 非确定性和统计算法
自动驾驶汽车使用的一些技术本质上是统计性质的。一般来说，它们趋向于不确定(不可重复)，并且可能只对某些概率给出正确的答案——如果某个概率可以被赋值的话。验证这样的系统所面临的挑战是传统的确定性汽车控制系统所没有的。
随机系统的挑战
非确定性计算包括一些算法，如计划器，它们可能通过对大量随机选择的候选对象的结果进行排序来工作(例如，概率路线图计划器[18])。由于该算法的核心操作是基于候选对象的随机生成，所以很难进行复制。虽然在单元测试中使用可重复的伪随机数流等技术是有用的，但在集成系统中创建完全确定的行为可能是不实际的，特别是在初始条件的微小变化导致系统行为发散的情况下。这意味着，尽管试图使用名义上相同的测试用例，但每一次车辆水平测试都可能导致不同的结果。
成功的感知算法也往往是概率性的。例如，证据网格框架[19]将来自个体的、不确定的传感器读数的不同证据累积到一个机器人周围环境的越来越模糊和详细的地图中。这种方法产生一种可能性，即有一个物体存在，但从不完全可靠。此外，这些算法是基于先前的传感器物理模型(例如，多路径返回)和噪声(例如，在雷达报告范围内的高斯噪声)，它们本身是概率性的，并且对环境条件的微小变化很敏感。
除了对周围环境的几何建模外，其他算法还从感知到的数据中提取标签。突出的例子包括行人检测[20]。这样的系统可以表现出潜在的不可预测的故障模式，即使是在很大程度上无噪声的数据。例如，视觉系统可能在消除由阴影引起的颜色变化的歧义上有困难，以及在大型反射面存在时，确定物体位置的经验差异。(平心而论，这些都是人类目前面临的挑战。)此外，任何分类过程都表现出假阴性和假阳性之间的权衡，其中一种情况的减少必然导致另一种情况的增多。它的测试含义是这样的算法不会在100%的情况下工作，并且根据构造它们可能报告一个特定的情况为真，而实际情况为真的概率只有中等大小。
非确定性测试
在测试中处理非确定性是困难的，至少有两个原因。第一个问题是，在特定的边缘情况下很难进行操作。这是因为，只有当系统接收到来自外界的一个非常特殊的输入序列时，它才会以激活边缘情况的方式运行。由于前面讨论过的因素，例如计划者对输入的微小变化的响应可能存在巨大差异，所以很难设计出一种情况，在这种情况下，世界将可靠地提供正确的条件来运行特定的期望测试用例。
举个简单的例子，汽车可能更喜欢在宽阔的马路上绕行，而不是在狭窄的小巷里抄近路。为了评估在狭窄的巷道中行驶的性能，测试人员需要设计一种情况，使宽阔的巷道对计划人员没有吸引力。但是，这样做需要对测试计划进行额外的关注，并且可能(手动)将车辆移动到它通常不会进入的环境中来强制执行所需的响应。测试车辆在两条几乎同样不吸引人的道路中选择更好的一条而不动摇的能力可能更加困难。
测试中与非确定性的第二个区别是，评估测试结果是否正确是不同的，因为对于给定的测试用例没有唯一正确的系统行为。因此，正确性标准可能必须采用与前面讨论的安全信封类似的形式，在安全信封中，如果最终系统状态在可接受的测试通过信封中，则测试通过。一般来说，可能需要多个测试来建立系统将总是在测试通过信封中结束的信心。
概率系统行为对验证提出了类似的挑战，因为通过一次测试并不意味着每次都通过测试。事实上，对于概率行为，可以预期至少某些类型的测试在某些情况下会失败。因此，测试的目的可能不是确定行为是否正确，而是验证行为的统计特征是准确指定的(例如，假阴性检出率不大于伴随的安全参数中假定的率)。这可能需要比简单的功能验证多得多的测试，特别是如果所涉及的行为是安全关键的，并且预期失败率极低。
要从概率系统中获得极高的性能，可能需要多个子系统，而在复合系统中，由于具有完全独立的故障，因此假定这些子系统能够提供较低的总体故障率。例如，可以将复合雷达和视觉系统组合起来，以确保在极低的概率范围内不会遗漏任何障碍物。该方法不仅适用于传感模式，也适用于规划和执行中的其他各种算法方案。如果这种方法是成功的，那么很可能导致失败的概率非常低，因此验证复合性能的测试是不可行的。例如，如果两个系统必须在十亿次探测中有一次错过障碍物，那么必须进行数十亿次有代表性的测试来验证这种性能。验证复合不同算法的非常低的故障率可以通过单独验证每个算法的更频繁的允许故障率来尝试。但这是不合理的。人们还必须验证故障之间独立的假设，这可能除了测试之外，还必须基于分析。
5 机器学习系统
只有正确地做出一系列复杂的监测和控制决策，自动驾驶汽车才有可能做出正确的行为。实现这一目标通常需要对参数进行适当的调整，包括从每个相机镜头的校准模型到为避开高速公路上的障碍物而转弯和停车的风险权重的调整。这里的挑战是找到校准模型或权值之比，使某些误差函数最小化。近年来，大多数机器人应用已经转向机器学习来完成这一任务[21，22]，因为多维优化的复杂性使得手工工作不太可能产生期望的性能水平。
机器学习方法的细节有很多，例如从演示中学习、主动学习、监督与非监督方法。然而，所有这些方法都涉及到归纳学习，在归纳学习中使用训练实例来推导模型。
例如，考虑在单目图像中检测行人的情况。通过使用一组大型训练图像，分类器可以学习一个决策规则，最小化行人在单独的验证图像集中被检测到的概率。对于我们的目的，一个基本元素训练集实际上是系统的需求集，而规则是最终的系统设计。(机器学习算法本身和分类器算法都更适合传统的验证技术。然而，这些都是通用的软件引擎，最终的系统行为是由用于学习的训练数据决定的。)
人们可以通过建立一套收集训练数据的要求来避免训练集数据形成事实需求的问题。但这最终只是把同样的挑战推到了抽象的一个层次上。需求不是系统本身的一组功能需求的典型V模型，而是一组训练数据的形式或收集训练数据集的计划。如何验证训练数据是一个开放的问题，可以通过对数据的特征描述以及数据生成或数据收集过程进行组合来解决。
验证归纳学习的挑战
归纳学习方法的性能可以通过从已收集的整体数据集中保留一些样本并使用这些样本进行验证来测试。假设如果将训练集用作系统需求（V模型的左边），则可以使用独立的验证数据集来确保满足需求（形成相应的V模型右边）。训练数据不能与期望行为无关，否则系统将变得“过度拟合”。类似地，除了所需的特性之外，验证数据必须与训练数据在各个方面都是独立和不同的，否则在验证期间将不会检测到过拟合问题。目前还不清楚，如何证明机器学习系统没有被作为安全论证的一部分过度拟合。
机器学习在实践中的一个重要限制是，如果使用带标签的数据，每个数据点都可能很昂贵。(创建标签必须由某人或某事完成。无监督学习技术也是可能的，但需要一个聪明的映射来解决特定的问题。)此外，如果发现了训练集（一个需求缺陷）或规则学习（一个设计缺陷）的问题并进行了纠正，那么就必须收集更多的验证数据并用于验证更新后的系统。这是很有必要的，因为即使是对训练数据的一个小的改变也会产生一个非常不同的学习规则集。
由于自治系统需求的复杂性，学习问题很可能会在少数情况下出现。然而，由于它们的稀缺性，收集描述这种不寻常情况的数据的成本可能很高，而且难以衡量。(模拟和合成数据可以帮助解决这一问题，但同时也存在模拟数据存在偏倚的风险，以及过度过渡到模拟工件的风险。)
验证机器学习的另一个问题是，一般来说，人类不能直观地理解过程的结果。例如，卷积神经网络[23]的内部结构可能无法直观的告诉人类观察者关于所学习的决策规则。虽然可能会有一些特殊的情况，但机器学习的易读性问题[24、25]在能够以人类的方式解释系统行为方面是无法解决的。除了昂贵的蛮力测试之外，很难预测其他技术如何应用于机器学习系统的验证。(也许有些组织确实有资源来进行广泛的蛮力测试。但是，即使在这种情况下，训练数据的准确性、有效性和代表性也必须作为基于机器学习系统正确性的安全论证的一部分进行证明。
由于机器学习系统的易读性普遍较差，而且过度拟合的危险是真实存在的，所以在这样的系统中存在着能够显著地影响安全性的故障模式。特别值得关注的是在训练集数据中出现的意外相关性，但是没有被人工审阅人员注意到。例如，考虑使用经过训练的可变形部分模型在图像中检测行人的方法，该方法已被证明在真实的数据集[26]中非常有效。如果训练数据集中没有(或很少)出现坐轮椅的行人的图像，那么这个系统很可能会错误地将行人的标签与用两条腿走路的人联系起来。
归纳学习的解决方案
众所周知，由于黑天鹅问题(black swan problem)[27]，确认归纳学习是非常困难的。通常，黑天鹅问题指的是一个人(或一个系统)很容易相信普遍的观察结果是正确的，而由于大量的数据点相互关联，可能会得出错误的结论。故事是这样的。在18世纪晚期之前，欧洲所有被观察到的天鹅都是白色的，因此，使用归纳逻辑的观察者会得出所有天鹅都是白色的结论。然而，这个观察者在访问澳大利亚的时候，会经历这种信念上的打击，那里有大量的黑天鹅。换句话说，如果系统没有看到一个特殊的情况，它就不能学习那个情况。这是一个基本的限制，归纳学习方法是不容易治愈的[28]。此外，随着机器学习的发展，这个问题会因为可读性的缺乏而变得更加复杂，所以人类评论者很难或不可能想象在这样的系统中，一个类似于黑天鹅的偏见会形成什么样的形式。
验证归纳学习系统似乎是一个极具挑战性的问题。可以使用广泛的测试，但是需要验证黑天鹅数据随机独立到达率的假设，并对相应大小的数据集进行测试。如果有足够的资源，这可能是可行的，但总会有新的黑天鹅，因此必须对大量的操作场景和输入值进行概率评估，以确保系统故障处于可接受的低水平。(如果有足够的资源以一种合理的方式来做这件事，这可能会形成V过程的右边。)
将基于低ASIL诱导的算法与基于高ASIL演绎的监控相结合，是验证高ASIL诱导学习系统是否适用于高ASIL水平的另一种选择。这将回避执行算法的大部分验证问题，因为控制执行器的归纳算法的故障将由基于演绎生成的安全包络线等概念的无感监控器捕获。因此，执行器算法故障将是一个可用性问题(系统安全关闭，假设有足够的故障转移能力)，而不是一个安全问题。
6 关键任务运行要求
作为一个最终的技术领域，我们回到前面讨论的一点，最终控制车辆的是计算机而不是人。这意味着，至少车辆有一部分系统必须是故障-运行，而不是故障-停止。
故障-运行系统的设计挑战
故障-运行系统的设计已经在航空航天和其他领域成功地进行了几十年，但由于几个原因仍然存在差异。第一个原因很明显，必须提供冗余，以便当一个组件发生故障时，另一个组件可以接管。
实现这一点需要至少两个独立的、冗余的子系统来实现故障停止行为。反过来，实现一个故障运行系统需要至少三个冗余的任意故障组件，以便在它发出错误输出而不是在组件级别[29]故障停止的情况下，可以确定这三个组件中的哪个失败了。对于必须容忍任意故障的系统，可能需要一个包含四个冗余组件的拜占庭容错系统[30]，具体取决于相关的故障模型。
冗余的结构根据设计方法不同而有所不同，可能包括配置，如带有投票者的三倍冗余系统，或对[29]中的四台计算机的双—双冗余系统使用故障-停止。除了这些方法带来的明显开销之外，还存在一个测试问题，以确保故障检测和恢复工作，确保故障的独立性，并确保在驱动任务开始时所有冗余组件都是无故障的。冗余似乎不太可能被避免，但它可能会降低复杂性和费用提供足够的冗余，以确保安全。
故障转移
在典型的故障运行系统中，例如飞机，所有的冗余部件基本上是相同的，并且能够执行扩展的任务。例如，商用飞机通常配置两个喷气发动机，每个喷气发动机至少有一个双冗余计算机控制。如果一个引擎上的计算机对由于通过持续交叉检测到的故障而关闭，就会有另一个独立的引擎来保持飞机的飞行。即便如此，对发动机可靠性的要求还是非常严格的，因为飞机在发动机第一次故障后可能要飞行几个小时才能到达最近的机场，而发动机可能会第二次出现故障。它对每台发动机都提出了很高的可靠性要求，因此增加了部件成本。
虽然汽车的成本敏感性是出了名的高，但它们确实有一个优势，那就是故障转移所需时间可能很短(例如，将车停在路边，或者在必要时在行车道上停车)，故障转移任务的持续时间以秒而不是小时计算。此外，与完全自主运行相比，停止车辆的故障转移任务可能具有的功能要少得多。它可以简化需求复杂性、计算冗余、传感器需求和可靠性需求。(作为一个简单的例子，故障转移任务控制系统可能不支持变道，这极大地简化了传感器需求和控制算法。一些复杂的方法可能比完全自主汽车更简单。)因此，设计具有故障停止主控制器和更简单的故障运行、故障转移控制器的自动驾驶汽车，在硬件成本和设计/验证成本方面都很有吸引力。
也有可能，安全论证不是基于完全自治系统的完美，而是基于完全自治系统有一个探测器，当它出现故障或遇到需求缺口时，它能意识到。这将使故障检测器本身具有高ASIL，但可能允许正常的自主功能具有低ASIL。这种方法可以很好地映射到主自治系统的监视器/执行器架构。故障转移自治还必须以安全的方式设计，并根据其复杂性和计算出的可靠性需求采用适当的体系结构方法。如果在仅持续几秒的短故障转移任务期间发生故障的可能性非常低，甚至可以使用单通道故障转移系统。
7 非技术因素
在部署自主权方面的一些挑战是非技术性的，比如经常提到的责任问题(当发生事故时由谁来负责?)以及法律通常如何对待车辆的所有权、运营、维护和其他方面。
对这个主题的深入研究超出了本文的范围。然而，解决非技术挑战很可能会对技术解决方案产生影响。例如，对于事故重建数据的自治系统可能会有法医要求。需要对这些数据的来源进行仔细分析，以确保正确使用这些数据。举个简单的例子，假设一个雷达的探测概率是95%，那么它的输出可能仍然会被记录在系统中，根据是否探测到一个障碍物，这意味着探测的确定性。重要的是要确保法医分析考虑到，仅仅因为雷达没有检测到行人并不意味着行人不在那里(例如，95%的检测可能意味着20个行人中有1个实际上不会被检测到)。
由于自动驾驶汽车固有的复杂性，以及无法通过测试证明任何接近完美的东西，因此开发人员很有可能以保证案例的形式创建一个安全保证论点(例如，根据[31])。这样的保证论证对于维护和解释系统的完整性是必要的，并且能够可信地解释系统对围绕不可避免的事故所发生的事件的响应。应该解决的一个特殊问题是，确保证据的完整性，以确定事故是否由于其环境而合理地不可避免。其他重要的问题将是，事故是否可以认为是由系统需求中的缺陷(例如，培训数据中的缺口)、合理可预见和可避免的设计缺陷、简单的心理缺陷或其他可归因于汽车制造商的原因引起的
8 故障注入
从前面的讨论中可以明显看出，传统的功能测试在运行一个完整的系统时会遇到困难，尤其是在不寻常的操作条件下，很难运行异常的组合。虽然测试人员可以防御一些不符合标准的测试用例，但是由于异常、操作场景和其他相关因素的组合爆炸，测试的可伸缩性是有问题的。此外，研究表明，即使是非常优秀的设计师也常常会在相对简单的软件系统[32]中发现盲点，从而错过一些特殊的情况。
故障注入和鲁棒性测试是比较成熟的评估系统在[33]异常条件下性能的技术，可以帮助设计人员和测试人员在测试异常条件响应时避免盲点。传统的故障注入包括将位翻转插入内存和通信网络。最近的技术已经提高了抽象级别，包括基于数据类型的故障字典[32]，并确保了故障的代表性[33]。这种技术已经成功地用于自动驾驶车辆[35]缺陷的发现和表征。
帮助验证自治特性的一个很有前途的方法是在组件的抽象级别上执行错误注入，这是试图伪造安全[36]声明的策略的一部分。这不仅涉及到模拟初级传感器输入的对象，还涉及到插入异常条件来测试系统的健壮性(例如，将无效数据插入到地图中)。进行这种故障注入的目的不是验证功能，而是探测可能在不可预见的情况下被激活的弱点。这种故障注入可以在ISO 26262 v模型的范围内进行。
9 总结
根据V模型开发安全的自动驾驶汽车的挑战是重大的。然而，确保车辆安全仍然需要遵循ISO 26262 V模型，或者证明一套同样严格的过程和技术实践已经得到应用。假设应用了V模型，有三种通用的方法看起来很有前途。
分阶段部署
开发和部署一辆能够在不受限制的真实环境(包括特殊情况)中处理所有可能的场景组合的自动驾驶汽车似乎是不切实际的。相反，正如汽车系统中常见的那样，基于当前开发人员实践的分阶段部署方法似乎是一种合理的方法。
将阶段部署绑定到V流程可以通过识别指定良好的操作概念来限制操作范围，从而限制必要的需求范围来完成。它将包括环境、系统健康状况和操作约束方面的限制，必须满足这些限制才能进行自主操作。确认这些操作约束是强制的，这将是确保安全性的一个重要部分，并且必须作为一组操作需求、验证和潜在的运行时强制机制出现在V流程中。例如，运行时监控不仅可能需要监控系统状态是否允许自治权，而且假设关于安全的操作场景参数实际上是被满足，以及是否操作场景的系统实际上是它认为。
需要特别注意的受限操作概念的一个方面是，确保在操作场景突然失效(例如，由于意外天气事件或基础设施故障)时维护安全性。从可接受的操作概念体系中进行的此类异常转换将要求成功地执行系统恢复或故障转移任务，即使系统偏移超出了允许的自治操作场景的假设。
目前还不清楚分阶段部署方法是否会提供一条通往完全自治的道路。但是，至少这种方法提供了一种取得进展和获得自治的一些好处的方法，同时可以更好地理解不同的边界情况和随着系统更多地暴露于现实世界条件而出现的未预料到的场景。
监控器/执行器架构
一种可能有助于减轻自动驾驶汽车安全的许多挑战的常见方法是使用监视器/执行器架构。正如前面所讨论的，这种架构风格可以帮助解决需求复杂性(只有监控器需要是非常完美的)和归纳算法的部署(通过限制对执行器的使用，并使用基于演绎的监控器)。
此外，故障转移任务策略的使用可以允许主自治系统监视器检测主系统故障，而不必确保故障操作行为。一个更简单、高度完整的自动故障转移系统可以使车辆进入安全状态。这样的系统可能具有足够短的故障转移任务，因此需要最小的故障转移操作冗余，只要能够确保在启动故障转移任务时系统是无故障的。
故障注入
为了确保系统的超可靠性，单独进行测试是不可行的。自动驾驶汽车只会让这个问题变得更加困难，因为它会自动地对高度复杂的环境心理状况做出反应，还会引入机器学习等技术，而这些技术测试起来既复杂又昂贵。此外，由于大部分的自动驾驶能力必须有较高的ASIL由于缺乏人类驾驶监督，它似乎很难做足够的普通系统测试，以获得甚至一个合理的水平的保证。
作为验证策略的一部分，故障注入可以发挥有用的作用，该策略还包括传统的测试和非基于测试的验证。如果将故障注入应用于多个抽象级别，而不是仅应用于固定的电子连接器级别，则尤其如此。
未来的工作
本文讨论了在基于ISO 26262的V框架下实现自动驾驶汽车安全保障的方法。但是，使用诸如监视器/执行器方法之类的体系结构模式和通过故障注入可能实现的验证的实际限制将对操作性能造成限制。换句话说，自动驾驶汽车的功能可能需要受到限制，以适应可行验证技术的约束。放松这些限制将需要在一些领域取得进展，例如与预期的操作环境相比，确定机器学习培训数据的覆盖范围，对特殊驾驶条件下的安全要求有足够的信心，能够验证冗余感应型系统故障的独立性。
广告
广告
编辑推荐
最新资讯
-
纽北（Nürburgring Nordschleife）赛道介
2024-11-22 09:17
-
虚拟验证先行丨集成多学科方法，让电池生产
2024-11-22 09:10
-
新品上市 | Fusion-LN 数据采集的下一个飞
2024-11-22 09:08
-
车规级V2X芯片- 汽车移动通信功能核心
2024-11-22 09:03
-
BEV端到端视觉论文合集|从不同的视角解析BE
2024-11-22 09:00
广告
广告
