导读

    控制设备中出现的错误必须能被迅速地识别出来并进行纠正。本文重点介绍基本错误检测与纠正的概念，已被熟知的软件架构中的标准解决方案，并分析在实际项目中这些解决方案是如何被集成到 AUTOSAR 软件架构中的。

    近年来，汽车内部电子控制单元（ECU）数量以及它们所具备的功能急剧增加，以驾驶员辅助领域为代表的新技术的引入，意味着车载功能正变得更加复杂，对硬件性能的需求也在不断增加。过去 40 MHz 的单核处理器就够用了，而现在却要使用几百MHz的多核处理器。为了应对相关的复杂性，如 AUTOSAR 或 GENIVI 等标准化联盟开发了相关软件架构，基于这些软件架构开发的软件也已经运行在越来越多的汽车 ECU 上。例如 ISO 26262 和 IEC 61508 等功能安全标准，包含了按照功能安全标准进行控制单元开发的指导原则，但并没有规定具体的解决方案，以避免限制系统开发人员打造最优解决方案。

    不断增加的辅助功能，以及不断提升的复杂性，处理控制单元可能发生的故障或失效的需求也随之增加。目前，大多数系统基于故障安全（fail-safe）架构：如果在 ECU 内频繁发生某一错误，该功能就会关闭，并将全部控制权交还驾驶员，随之将这一情况通知驾驶员。

    因此在许多辅助系统的安全模式下，相关功能将被关闭，并向驾驶员发送警告。然后驾驶员就会采取适当的应对措施，例如手动驾驶，停车或进行维修。这种错误处理方式的确安全，但往往体验不佳，会导致汽车被视为不可靠产品。只要部分自动或全自动驾驶的功能受到影响，这种错误处理方式就无法再确保汽车驾乘人员的安全。在这种情况下，如果出现错误，系统应能够提供完整或降级后的功能来实现可靠运行。这种系统称为失效运行（fail-operational）系统。

    失效运行系统在核电站和航空等安全相关领域已经非常成熟，此类系统的设计主要由冗余系统部分，加上能够过滤或替代产生错误信息的通道的监测部分。第一步通常是简单的冗余，加上图 1 所示的投票机制。

    该系统实现两个冗余通道，投票机制可以检测到某个 ECU 出错，并触发切换到安全状态。但是，此类系统只能做到故障安全，因为投票机制只能检测到两个通道产生结果相异，无法定位发生故障的 ECU。

    第二种方法是三重模块冗余（ 2oo3 ）系统，如图 2 所示。

    此模式有三个冗余 ECU 以及一个表决器组成。如果只有一个 ECU 产生反对结果，则持有异议的 ECU 将被视为发生故障，但系统可以继续使用其余两个 ECU。在极为重视功能安全系统可靠性（如航天电子），或者系统故障是重要成本因素（如化工厂）的行业中，此类 2oo3 系统非常成熟。

    但是与每年制造和部署了数百万套系统的汽车领域相比，新部署的飞机或化工厂的数量较为有限。相比现在的故障保险系统，三重模块化冗余系统的开发和制造成本非常高，同时还需要考虑重量和功耗增加等其他因素。因此，人们需要找到一个更加合适的技术解决方案，这种方案应能够兼顾市场需求以及客户对失效可操作系统的价格及可靠性的期望。

    第三种方法是图 3 所示的 1oo2D 系统。

    这种模式基于双通道系统，每个通道都有很强的诊断能力，可以在大多数情况下检测并通知自身故障。在其他情况下，会为每一种情况定义一个主 ECU，表决器也运行在主 ECU 上。

    如果两个通道中的某一通道发生故障，系统可以关闭故障通道，暂时仅启用另一个通道继续运行。在只有一个通道的情况下，系统将失去失效后仍可运行的能力，需要尽快恢复此能力。其他外部监控系统需要为整个系统故障做好准备。在许多情况下，向驾驶员移交控制权可能就够了。

    可以使用例如 Markov 链等可靠性工程技术进行模拟，比较 1oo2D 系统与 2oo3 系统的可靠性。对比的关键因素是每个 ECU 的诊断覆盖水平。这适用于随机硬件故障，以及软件功能实施中的系统故障。

偏航：ADAS 系统的错误检测

    大多数驾驶员辅助系统，如车道辅助，会根据大量输入值（包括摄像头图像）来形成决策（图 4）。在此情况下，其决策形式包括驾驶员警告或主动转向干预。

    许多驾驶员辅助功能会处理大量数据，这些数据通常来自多个传感器系统。例如，出于功能安全理由，系统可能产生冗余路径。这些数据经过筛选、可行性检查后就会合并到功能之中。在图 4 中，处理或决策过程中的错误越靠右，它们就越关键，因为这里呈现了数据和决策冗余下降的趋势。错误检测机制和失效运行系统的机制相同对数据流进行校验、合理性测试、阈值分析或筛选瞬时值。此外，还有错误检测机制，它可以监测系统的完整性，根据需要在运行时执行系统测试。由于辅助和自动功能在驾驶环境中的使用增加，运行时间也随之增加，这意味着可能更加频繁地发生瞬时错误，所以很有必要执行这些系统测试。

安全状态和部分恢复

    正如上文所述，1oo2D 系统可以在短时间内以单通道模式继续运行。减少单通道运行时间的一个潜在解决方案就是，将确定的高可用性、功能安全相关软件的设计模式映射到多核处理器的各个核，或者使用其他 ECU 来接管各项功能。后者将需要改动现有 E/E 汽车架构：将功能动态地分布到多个控制单元，进行开启或关闭。重新配置此系统需要按需访问传感器和执行机构，例如作为服务提供给车辆网络中其他节点进行请求。重新配置既可以在使用静态 AUTOSAR 系统时进行静态的预先配置，或者在自适应系统中完全动态地进行配置。

    图 5 展示了一个包含替代功能的架构。正常状态下，功能 1 在控制单元 1 上激活。如果发生错误，功能将迁移到控制单元 2。这个功能可以是冷启动，也可以是一直运行在待机状态。如果需要，可以关闭控制单元2中不太重要的功能，如功能 4。这意味着可以有效地使用资源，不占用更多的计算能力。

    除了自身状态监控，当某一功能在不同控制单元之间进行切换时，进行切换动作的控制单元也需要被监控。这是 FailOp Manager 的职责，作用在于确保及时检测和快速切换，防止两个功能同时处于激活状态。

    AUTOSAR 软件架构，包括操作系统，都是静态配置的。为了将动态替换机制集成到静态架构中，这些功能需要具备连接与断开的能力，AUTOSAR 提供了多个选择：

·  RTE 模式切换

·  警告(alarm)的启动和停止

·  任务(task)的启动和停止

·  OS Application 的启动和停止

    要允许功能和监控独立运行，操作系统必须提供分区(partitioning)机制。EB tresos Safety OS Multi-Core 操作系统在此基础上也能提供分区的启动与停止功能，同时也通过了 ASIL-D 的认证。

关于自动驾驶

    目前的故障安全架构只能实现部分自动驾驶。如果发生错误，需要人为干预，汽车驾驶员仍然是汽车运行的一部分。我们实际上可以使用其他行业和汽车标准（如 AUTOSAR）的已有概念组合，找到开发高可用性控制单元的解决方案。此类解决方案可以基于 Elektrobit 在各个领域（如驾驶员辅助系统）的各种项目，以及包括 EB tresos Safety OS 产品上获得的经验，而无需在 AUTOSAR 等标准上进行妥协。这样的控制单元能够独立应对错误，保证系统继续执行，成为自动驾驶功能运行的基础。

本文作者：

欲下载该完整白皮书 PDF，请访问 Elektrobit 官网：https://www.elektrobit.cn/tech-corner/safe-state-architecture-and-degradation-mechanisms/

Elektrobit 针对汽车 ECU 的 AUTOSAR 软件产品和解决方案：

• Elektrobit 经典 AUTOSAR 基础软件、汽车操作系统和量身定制的工具环境：EB tresos

  www.elektrobit.cn/products/ecu/eb-tresos/

• Elektrobit 用于打造高性能计算平台（HPC）的自适应 AUTOSAR 基础软件、虚拟机监控程序（Hypervisor）、车规级操作系统和集成式开发环境：EB corbos

  www.elektrobit.cn/products/ecu/eb-corbos/

• Elektrobit 推出的业内首款能够实现安全、高性能车载网络通信的汽车以太网交换机固件：EB zoneo

  www.elektrobit.cn/products/ecu/eb-zoneo/

• Elektrobit 为汽车电子控制单元（ECU）提供的嵌入式安全解决方案：EB zentur

  www.elektrobit.cn/products/security/