用于失效操作的汽车E/E系统的架构研究

1背景介绍及现存挑战

目前，由于功能和应用的不断发展，汽车电子电气系统(E/E systems)的复杂性不断增加，对额外的电子控制单元(ECUs) 的需求也越来越大。安全相关的驾驶系统必然是确定的标准配置。对于用户来说，驾驶系统必须是可理解的，因此它应该越简单越好。与此相比，大量的增加新功能会导致出现较高系统失效率。因此，需要针对软件的复杂性进行相应的安全分析。

如制动或转向功能，传统的车辆功能及其的未来应用将逐步被没有机械后备(Fallback)的电子系统取代。自动驾驶和电子线控(X-by-Wire)便是这一趋势的产物。在车辆电子系统中，有一些是安全相关的，特别是动力和底盘功能系统，如果这些系统发生故障，就会引发整车层面的失效，从而造成一系列危险情况，如车辆非预期的加速。有鉴于此，ISO 26262中规定应通过明确的安全分析来导出相应的安全要求，以便实现基于硬件和软件的故障探测和控制机制。

在高度集成的多核系统中，交叉开关(Crossbar)过度争用可能是导致内核故障的原因。发生故障的内核连续阻塞整个系统请求接口(SRI)的交叉开关(Crossbar)的部分调度，受阻塞的调度继而影响其他内核的输入/输出(I/O)以及内存访问，这将潜在地导致执行速度大幅下降。另外，由于各个内核之间存在功能上的依赖关系，一个内核的故障也可能影响系统行为。如果AUTOSAR标准中规定的基础软件(Basic Software)在故障的内核上运行，则其他内核将无法访问外设。更有甚者，倘若与其他内核存在功能依赖关系的内核发生故障，这可能会造成系统部分或完全破坏。

本文的主要贡献在于提出了用于失效操作(fail-operational)的汽车E/E系统的架构。为此，许多整车制造商(OME)、半导体供应商、工具供应商以及大学致力于从概念层面改进软件实现和硬件架构。在这篇文章中，提出了重要的概念设计和想法。

2先前研究回顾

编码处理(Coded processing)方案可以通过在软件中增加冗余来减少硬件冗余。对于实现编码处理的失效安全(fail-safe)系统和fail-operational系统，可以估算平均故障时间(MTTF)的改进。这种方法可显著延长fail-safe系统的MTTF，但对fail-operational系统的MTTF影响不大，因此我们难以充分论证这种方法所需的算力损耗。

文章提出了一种新颖灵活的微控制器架构，可用于fail-safe与fail-operational系统。该微控制器架构符合IEC 61508和ISO 26262的相关规定，并通过预先认证的硬件故障监控器以降低成本。该方法要求半导体厂商优化硬件结构，使其符合功能安全要求。文章重点关注ECU的硬件架构，而我们的文章重点在软件概念，同时综合考虑了车辆的网络以及通信架构。

文章提出了另一种方法，即系统层面简单架构。通过硬件/软件协同设计，该架构能对逻辑应用层故障，以及如实时操作系统(RTOS)和微处理器等相关层的故障提供fail-operational保证。

文章回顾了应用于工业领域的故障容错(fault-tolerant)架构的相关研究，此外还提出了低成本的双锁步(lockstep)平台，可应用在要求单点fail-operational的单元或双点失效静默(fail-silent)通道。

文章同时概述了电子驾驶辅助系统以及具备或不具备机械后备(Fallback)的电子线控系统，作者充分考虑到不同冗余方式的fault-tolerance原则，从而产生了fail-operational、fail-silent和fail-safe系统。

3嵌入式系统的安全机制

在安全相关的嵌入式系统中，特别是车辆实时系统，制动和转向功能即使在系统发生局部故障失效时也必须得到保证。为避免系统失效或将系统失效降至最低，常规做法是风险最小化。一般来说，可以通过缩短操作时间或降低失效率来降低失效情况的发生概率。风险最小化的另一种方法是实现改进的控制策略，如安全关机，或者实现更高的容错性。安全关机应用于fail-silent或fail-safe系统，而高容错性系统主要应用于fail-operational系统。Fail-operational本身可以通过多样性或冗余来实现。

图1呈现了这些方法：

图1.最小化风险实现

A Fail-Safe

在Fail-Safe场景中，当检测到不可容忍故障时，E/E系统切换到系统安全状态。该系统存在两种不同的状态，即不受影响继续运行，或者是停止运行。此外，如果发生瞬态故障，系统停止运行后重启。在考虑失效系统时，需要采取额外措施使其具有容错性

在常见的多核处理器中，同时并行的运行同一组操作的锁步核有助于实现冗余系统。典型的车辆故障安全系统包括防抱死制动系统(ABS)，牵引力控制系统(ASR)，电子稳定控制系统(ESC)及制动辅助系统(BA)。

Fail-safe架构概述如图2所示：

图2.Fail-Safe架构

B Fail-Operational

与fail-safe系统对比，如果在发生故障时关闭Fail-Operational系统，由于关键的安全目标无法得到满足，会导致危险的系统行为。这种情况下，为了实现替代和安全执行，额外的fault-tolerance措施必不可少。

Fail-operational的行为可以通过设计多样性或冗余来实现(图1)。多样性意味着两种或更多不同的实现以完成同样的任务，功能等价，但算法、架构或实现不同。在冗余系统中，计算是由两个或多个等价的实例完成的。在下文中，我们将简要介绍fail-operational系统的可能实现方法。

2oo3架构

冗余故障操作架构的典型代表是2oo3决策，这也被称为具有表决功能的三模冗余(Triple Modular Redundancy, TMR)，是航空电子领域和多安全相关系统的代表性参考架构。在这种架构中，三个子系统独立计算各自的结果，然后，对三个子系统输出的结果进行比较，如果至少有两个结果相同，则输出为真(图3)。建议每个单元和表决单元使用独立的电源。如果考虑通信总线，这种方法是否适用于车辆系统严重依赖于通信速率。对于较慢的数据输出速率，实现的复杂性是可接受的。相比之下，对于高速以太网来说，它要复杂得多。

2oo3架构如图3所示：

图3.2oo3架构

2oo2DFS架构

2oo2 DFS架构将主系统分成两个子系统，它们可以是等价的，也可以是不同的。每个子系统被设计成fail-safe系统，并使用自己的监控概念检测其自身的错误(Fail-Safe (FS))。此外，该系统可以监测另外一个子系统，以便在失效情况发生时采取适当的措施(Diagnosis (D))。如图4所示，该架构意味着每个子系统具备独立的电源，展现了一种车辆系统fail-operational的方法。该系统既可以设计为全冗余系统，也可以设计为所谓的由主控制系统和备用系统组成的跛行系统(Limp-Home system)。具体架构方案可由每个通道中的软件设计，或由实现部分或完全冗余的输入拓扑达成。此外，如果架构方案不需要在同一个ECU上实现，可以使用两个独立控制器或主/从方法。

2oo2DFS系统架构如图4所示：

图4.2oo2DFS系统架构

4常用多核架构的安全特性

当代汽车ECU的功能高度集成化可以通过高性能多核处理器实现。然而，将它们整合到新的架构中是一项更加困难和富有挑战性的任务。

Fail-operational系统需要对应的ECU硬件设计，用于处理失效和系统的非预期行为。为实现这一点，半导体供应商提供了多种安全特性和全面的错误管理设计。锁步核可以检测CPU(中央处理器)的随机硬件故障，而内存和总线的瞬态故障可以通过纠错码(ECC, Error Correcting Codes)进行保护。

多核处理器的另一个优点是提供了架构上的隔离，因此，由于采用了独立的内核，它们具有额外的独立性。该架构允许两个软件实例在不同的内核上同时运行。同时，性能提高也使集成额外的安全特性成为可能。

虽然现代微控制器应用了许多硬件安全特性，如锁步核、纠错码等，但多核处理器也存在缺点。首先，与单核CPU相比，多核处理器更易出错。CMOS内比特翻转的概率会影响计算逻辑，并可能在长期运行中导致瞬时或永久故障。此外，时序行为的可预测性和混合关键性应用程序的隔离受到共享资源的共同使用的影响。大多数的MCU非常复杂，几乎不可能预测关键软件的时序。能够运行并行算法的多核CPU也会面临更高的同步工作量的影响，尤其是当运行在不同内核上的进程并发地访问同一资源时，就可能出现竞争情况。运行在所有ECU上的整个软件代码库的复杂性治理变得难以管理。这是除了(同构)冗余之外，多样性是必要的另一个原因。当2oo2架构由不同的MCU(代码和/或硬件基础)组成时，由于软件bug或同步问题导致两个ECU同时失效的概率远低于同构架构。此外，我们的目标是确保在一个内核持有另一个内核正在等待的资源时不会出现死锁。但结果却是两个内核都被阻塞，无法继续运行。

5未来硬件软件架构的概念

在过去，就单个ECU而言，fail-safe行为足以应对安全问题。对于fail-operational系统，焦点转移到系统层面。由于ECU的独立性只能在系统层面得到保证，没有明确系统边界的情况下，无法实现冗余或n取m决策(m-out-of-n)。如果我们觉得无法证实新ECU的存在价值，可以预见，冗余将通过把不同的功能集成到多个域控制单元(DCU)来实现，这一方面凸显了系统视角的重要性，另一方面将给汽车制造商带来新的挑战。

A 新软件层

失效操作(Fail-Operational)系统利用冗余计算资源实现其功能。整个系统必须知道不同子系统的状态才能采取相应的行动，这就需要一个安全的通信层，它不仅能够交换数据，还能够控制消息流。例如，如果一个子系统生成了错误的数据，为保持系统稳定性，就必须停止传播这一错误数据。最后，必须实现分布式逻辑来处理不同类型的故障。

通过使用更多域控制器来减少单个ECU数量的方法需要新的fail-operational概念，以便在一个控制器中实现冗余系统。下面的小节将我们将对硬件和软件架构设计的一些相关概念进行概述。

B 多核架构相关概念

未来的fail-operational系统需要改进的软件设计，下面的讨论中介绍了一些不同的方法。

用于自动驾驶汽车EPS的 2oo2 DFS架构

在这种方法中，所谓的自动驾驶ECU将两个独立的锁步MCU作为2oo2DFS架构的基础。两个输出信号代表EPS ECU的冗余输入信号，同时EPS ECU也被设计为2oo2DFS系统。每个ECU也可设计为仅支持跛行系统(Limp-Home)，例如一个仅提供基本功能的8位小CPU被用作备份系统。但是，MCU使用同一电路板上的两个物理隔离的CPU(图 5)。通常情况下，衡量系统可靠性的指标称为平均故障间隔时间(Mean Time Between Failures，MTBF)，它表示平均故障前时间(Mean Time To Failure，MTTF)和平均故障修复时间(Mean Time To Repair，MTTR)的总和。对于Fail-safe系统，针对瞬时故障采取系统重启等修复措施。2oo2DFS方法通过缩短MTBF提高了整个系统的可靠性。第二个子系统可以直接替换失效子系统的功能，从而缩短整个系统的MTTR。由于采用了fail-operational方案，延长了MTTF。同时，与fail-safe系统相比，该系统的容错能力更高。

自动驾驶汽车中的2oo2DFS架构如图5所示：

图5.自动驾驶汽车中的2oo2DFS架构

高度集成的多核ECU中的2oo2DFS架构

此架构类似于1)中提出的 2oo2DFS。相比之下，ECU利用单个多核芯片设计成冗余系统。该架构需要为多核CPU提供多个电源，例如，每个内核一个电源。此外，硬件架构必须能够支持每个内核的复位机制，以便在出现失效时重启(图6)。从软件层面看，应该尽可能只复位最小受影响部分，即故障数据或控制流处理器指令序列(control flow processor instruction sequence)，尽可能保持较高的整体可用性。如果ECU的其中一个内核发生故障，则必须由另一个内核检测到这一故障，剩余的内核才可以发挥备用系统的作用。因此，两个内核必须持续地相互监控。两个内核都通过芯内互连连接到总线接口。冗余总线连接能够确保传输数据到其他的ECU，为防止失效传播，失效的内核必须与系统隔离并断开连接，这就意味着要将失效的内核与芯片内部的互连断开，并关闭失效内核的电源。总而言之，这种方法大有可为，因为它不仅降低了现代车辆的成本和重量，同时提高了可靠性和可用性。图7呈现了一种更面向软件的方法。具有不同安全要求的应用程序封装在虚拟机(Virtual Machine, VM)中。(图7)显示了一个具有三个内核的示例，每个内核执行一个客户操作系统。客户操作系统使用不同的传感器信号，这些信号直接路由到对应的VM。为实现与外设及虚拟机间的通信，每个内核都配备虚拟机监视器(hypervisor)。两级2oo3表决器被用于VM输出(L1)的安全机制以及作为安全机制的监控(L2)。后者控制执行器。其优点之一便是，瞬时故障发生时，可以复位VM。此外，VM可以托管不同的、独立的且彼此完全隔离的操作系统。因此，当主系统在另一VM中执行时，Limp-Home功能能够在VM中运行。

高度集成电子控制装置中的2oo2DFS如图6所示：

图6.高度集成电子控制装置中的2oo2DFS

高度集成电子控制装置中的流程虚拟化如图7所示：

图7.高度集成电子控制装置中的流程虚拟化

6结语

对汽车工程师来说，从fail-safe到fail-operational的转变是一个长期存在且无法避免的巨大挑战。汽车多核处理器的通用硬件架构提供了大量的安全特性，这些特性是fail-operational实现的先决条件。在我们的合作工作中，我们开发了新概念来实现此类系统新功能，如自动驾驶和电子线控等。本文展示了一些有关如何设计未来的fail-operational架构的概念及想法。特别是，我们认为2oo2DFS架构应用灵活，具有广阔前景。

审核编辑：汤梓红