| 编辑推荐: |
文章讨论了自动驾驶系统可能会检测到故障，如何避免错误的发生，以及对未来在功能安全方面的畅想，希望对您能有所帮助。
本文来自于auto-testing，由火龙果软件Luca编辑、推荐。 |
|
自动驾驶技术的变革，需要时俱进的AUTOSAR基础软件的配合随着自动驾驶功能的爆炸式增长，自动驾驶系统对软、硬件的可靠性提出了越来越高的要求。尤其是，现有的
自动驾驶技术的变革，需要时俱进的AUTOSAR基础软件的配合
随着自动驾驶功能的爆炸式增长，自动驾驶系统对软、硬件的可靠性提出了越来越高的要求。尤其是，现有的软件架构和开发方法在自动驾驶系统功能安全的支持方面显得越发捉襟见肘，未来的safety
case对论据、策略和佐证提出了怎样的要求？而这又将对AUTOSAR基础软件提出怎样的要求呢？
一辆车以60英里每小时的速度在高速公路上行驶，司机没有专注于驾驶，而是在泡一杯咖啡，而车辆可以自己保持安全的行驶状态。以上描述的场景现在听起来像是天方夜谭，但是我们有理由相信，这将在不久的将来成为现实。要实现以上描述的自动驾驶，车辆系统需要做出改变：需要装载更多的传感器以便更精确地感知车辆周围的环境，电子控制单元（简称ECU）之间的大数据传输需要依托于更高速率更高带宽的总线形式。但是需要做出的改变仅仅如此吗？自动驾驶技术会对软件开发提出怎样的要求呢？我们还可以延用之前的开发方法吗？
目前，多数的车载系统开发是基于单通道的设计思路，这意味着在整个感知、控制回路中的每个单元，例如任意传感器或者执行器的故障会导致整个系统的错误。冗余设计通过备份传感器或备份控制器来监控整个回路可能出现的故障，以提高系统的可靠性。通常来讲，当检测到错误时，ECU需要重新启动，自动驾驶系统会被关闭进而需要通知驾驶员来重新掌控整个车辆的驾驶行为，例如在紧急情况下驾驶员需要操控车辆停车。自动驾驶系统的重新启动或者关闭被认为是将车辆保持在安全状态，这样的系统通常被称为fail-safe系统。
Fail-safe系统需要保证在规定的时间内检测到软、硬件发生的故障。通常情况下，对特定软件模块的超时监测、对于接收数据的完整性和实时性校验（端对端保护，E2E）等机制会被用到。
在故障状态下继续保证正常运行
驾驶员此刻可能正在十分悠闲地品尝着咖啡，显然不适合作为整个车辆系统安全驾驶的最后保障。自动驾驶系统必须拥有一套电子的最终安全屏障（图1）。设计这样的系统有一个先决条件，那就是每个通道都要具备自我故障监测的功能。假如一条通道发现了故障并关闭，那么另外一条通道要立刻接管车辆的控制（图2A）。这样的系统通常被称为fail-operational系统。
在系统设计和硬件设计时，我们已经意识到在任何时刻，系统的每个部分都存在着一定的故障概率，为了计算这种概率，我们需要建立各种数学模型，基于这些模型和方法，我们可以计算并评估系统在何种情况下可以被认为处在安全状态。而精确的数学模型是实现这种计算的关键性因素。在接下来的文章里，我们将以两种类型的故障为例，来描述这种概率计算方法的瓶颈。
图1. 设计冗余通道以保证故障发生时由备份通道接管控制– fail-operational系统的可能架构
第一种是相同模块的故障。考虑到控制系统的复杂程度和预算，我们认为每个通道至少有一部分的软件实现是一致的，所以，这些相同模块的故障率会显著增加，而这样的故障一旦发生，将会同时对这两个独立通道产生影响（图2B），从而导致整个系统的运行出现问题。为了解决这一问题，需要引入多样的实施方案，例如，采用来自不同供应商的软件。然而，为了保证这种真正的“多样性”实现，需要经过复杂的验证过程。然而现实是，由于技术上和商务上的限制，很多时候，真正的“多样性”实现是很难达到的，甚至在有些情况下，确实没有第二种实现方式可供选择。另外一个可以作为功能安全论据的是相同模块同时发生相同故障的概率是足够低的，但是很难有合理的数学模型来给出证明。
第二种是关联性故障。我们假设以下的场景：一辆自动驾驶汽车运行良好，但突然，正在运行的通道上检测到了一个随机错误，系统随即做出了正确响应并关闭了这条通道，与此同时，备份通道准备接手并控制车辆。但是由于这种突然的变更，软件中负责运行通信的任务执行超时，从而导致了通信丢失。这个关联故障立即被系统检测到了，然而由于系统中没有针对这一故障的响应决策，导致了系统的复位。而所有控制车辆需要用到的状态信息都在复位操作中丢失了，而重新收集信息所需要的时间往往是正在泡咖啡的驾驶员所不能接受的。
图2. 不同类型的错误及其影响
有的读者可能会认为，上面的例子只会出现在某些极端的情况下，它实际会发生的概率太小从而可以被忽略。然而，对于这种由关联故障所导致的潜在风险是必须在开发阶段有所考虑的（图2C）。满足ASIL
D（Automotive Safety Integrity Level）要求的系统需要有能力检测90%以上的潜在故障。但是这种对故障的定量评估在软件上真的可实现吗？
从软件的角度来避免错误的发生
所有的软件错误都是系统错误。迄今为止，我们还不能为系统故障建立起一个普遍可接受的模型。所以，为了避免系统级别上的故障，我们必须从最开始就采用避免错误的实现方式。回到前面的场景上，驾驶员依赖于整个系统在有故障发生的情况下继续正确控制车辆，而如果只能实现故障监测功能，显然不能满足驾驶员的这一需求。
然而，如何避免复杂软件系统的故障呢？只有合适的开发流程才能避免系统错误的发生。功能安全规范ISO26262
为开发方法定义了最低标准，相比较于fail-safe系统，在fail-operational系统中，越来越多故障监测功能之外的软件模块被定义为与功能安全相关。对于AUTOSAR基础软件来说，通信和其他基础软件模块也会有功能安全要求。一般来说，功能安全相关软件的开发流程中，50%以上的精力被用在了测试验证部分，所以，很容易预计到，开发fail-operational系统所需要的精力将会大幅度增加。此外，软件的很多特性难以被测试覆盖到，例如：最坏情况下的执行时间。类似的，为了避免并发动态行为导致的race
condition，需要做到很深层次的系统分析。而这两种分析都需要借助于非常先进的工具来实现。此外，为了支持我们已经做了足够多的工作而将系统的初始风险减低到了可接受程度这一论据，需要借助于ISO26262
提出的控制流和数据流分析。
图3 MICROSAR Safe – 为功能安全相关ECU提供的AUTOSAR基础软件
未来的功能安全软件
由Vector公司开发的全模块通过功能安全ASILD等级认证的AUTOSAR基础软件（图3）已经在市场上应用多年，它可以为fail-safe系统的开发提供支持。通过深入的数据流和控制流分析以及符合ISO26262要求的测试，MICROSAR已经实现了功能模块间的Freedom
From Interface（免干扰）。端对端保护机制可以为fail-safe系统检测到通信故障。相比较于仅仅基于内存分区设计的系统，这样的系统更适合来满足fail-operational系统提出的要求。
然而，想要完全地避免系统错误，显然需要更多的分析工作。例如，在MICROSAR操作系统中，尽可能地控制最大运行时间、保障系统的确定性行为。初步分析表明我们还需要制定一个现实的上限，用于并发现象和race
condition的分析。
搭载了当前软件和技术的系统将可以在未来的道路上自动运行，然而，对于整车厂、一级供应商和软件供应商来说，还有很长的路要走。在自动驾驶技术真正成熟之前的多年时间里，驾驶员还需要掌控方向盘，而不仅是坐在车里享受一杯咖啡。
|
