集中式E/E架构的安全设计
1.引言
现代道路车辆的复杂性与日俱增。为了保持竞争力，汽车必须满足客户对功能和性能的期望，而这些期望本身又与连接性、电气化、泛在技术、通信、即时访问等趋势息息相关。这种趋势增加了车辆的复杂性，并反过来推动汽车E/E（电动和/或电子）架构的演变，从传统的基于总线的分散式架构，由几十个ECU（电子控制单元）组成，发展到集中式架构。集中式架构由车辆领域（域控制架构）或域组（跨域架构）专用的计算集群组成，并由一个强大的ECU独立控制。
集中式架构还包括区域架构，在区域架构中，车辆级别的单个计算机集群可以实现车辆的主要功能。在本文中，我们主要考虑了域和跨域的架构。域和跨域架构利用强大的、价格相对较高的顶级ECU，分别称为域控制器（DC）或跨域控制器（CDC），而控制域的其他ECU，本身相对便宜。在本文中，我们将使用DC来表示域控制器和跨域控制器。
在每个领域（或域的组合）中，DC是最要紧的单点失效。因此，当一个车辆领域仅由一个强大的DC控制时，最大的担忧之一是在该控制器完全丢失的情况下会发生什么。更确切地说，我们更关心的是DC的不可恢复的故障，如功率损失、液体进入DC等。
在DC中，通常会实现许多功能安全的概念和功能，如E-Gas监测概念、锁步核等。但是这些机制并不能解决诸如DC内所有微控制器或者ASIC的电源损失等问题。传统的功能安全方案（例如，三模冗余）可以用来解决此类故障，但它们涉及到ECU层面的DC冗余，这会增加成本以及空间和电力需求。因此，我们寻求其他选择来处理DC的灾难性故障，这些选择可以与DC运行时已实施的安全规定结合起来使用。
在本文中，我们提出了一种安全架构，专门针对这种情况，我们认为这种架构可以最大限度地减少与功能安全专用硬件相关的成本，并充分利用集中式架构的基本通用性。我们建议，在DC发生灾难性故障的场景中，应该在受影响领域内剩余的ECU中实施一个分布式控制方案，让其接管故障DC的部分功能。虽然理论上这样的方案可以实现DC的全部功能，但这并不是该方案的目的。在其基本功能形式中，这种后备体系结构不需要任何其他硬件，只需要集中的领域中的硬件。
不可否认的是，它增加了智能执行器所需的计算资源，必须仔细规划以适应后备功能。虽然我们的架构像经典的安全架构一样利用了冗余，但它有望成为一个更经济的解决方案，因为它使用现有的硬件资源，而不是像更传统的架构那样，依赖于冗余的ECU或微控制器的更昂贵的解决方案。据我们所知，我们提出的架构在这方面是独一无二的。必须指出的是，我们的提议只是涵盖了集中式车辆领域完整安全架构的一个方面。其余的，如域内通信功能安全方面，则不在本文的讨论范围内。
本文的其余部分结构如下。在第Ⅱ节我们介绍了相关工作。第III节介绍了一个典型的集中式架构。在第IV节中介绍了安全架构。第IV节则总结了未来工作的路径。
2.相关工作
DC的损失问题可以通过利用经典的硬件冗余方案来解决。例如，MooN（M-out-of-N通道架构）是一个基于多数投票系统的简单静态冗余方案。这种架构的一个广泛使用的实例是2-out-of-three（2oo3）通道架构，也被称为三模冗余（TMR），三个独立模块计算输出，然后多数投票系统产生一个输出。TMR架构在各个行业都很适用，包括汽车行业（例如，Sari和Reuss的工作成果）。
当然还存在其他通用的硬件冗余方案，其中一个模块提供输出，一个故障检测单元检测模块是否出现故障。在检测到故障模块后，系统会进行重新配置，以切换到健康单元。例如，由两个双工（1oo2或2oo2）系统组成的duo-duplex架构，被用于汽车的线控驱动系统，以及诸如空中客车公司等的航空电子设备。两个版本的duo-duplex架构，对称2oo2DFS和非对称2oo2DFS，已经被用于汽车底盘领域。
这些方案的基础都是经典硬件冗余。同样的方法也可以用于保障汽车应用中DC的容错和功能安全。换句话说，先前简单讨论过的冗余方案同样可以应用于集中式E/E架构的DC，以实现集中式汽车领域的功能安全，如动力系统或运动和安全。然而，虽然对于汽车、航空电子、航天等安全关键应用的DC来说，硬件冗余看起来是一个可行的解决方案，但这种类型的方法不是安全关键应用的普遍解决方案—主要是因为需要额外成本、额外的空间和额外功耗。对于大批量、成本敏感型的汽车应用来说，这种类型的方法在许多情况下是非常昂贵的。此外，ISO 26262没有明确要求上述的硬件冗余方案用于安全关键应用。
一般来说，专门针对集中式E/E架构的功能安全的工作不多，尤其是我们在本文中讨论的情况。然而，还是可以找到一些参考建议的。Sommer等人提出了一个带有以太网骨干网络的车辆区域结构。中央计算机集群由若干台“车辆控制计算机”组成，这些计算机可以是双工控制计算机(dcc)，也可以是单工控制计算机。一个DCC有两条执行路径，两条路径上的相关输出都被监控和比较：如果观察到错误，结果就会被丢弃，第二个冗余的DCC就会接手。此处可以有多个冗余DCC。在正好有两个DCC的情况下，这种结构实际上成为duo-duplex架构。汽车以太网网络是环形的，有两条独立的路径。在这种情况下，该方法也是基于硬件冗余的。然而，汽车应用所需要的是能够以远低于硬件冗余的成本提供故障操作功能。
3.集中式动力系统E/E架构
图1. 集中域动力系统
图1所示的集中式动力系统架构是在之前提出的。这张图展示了电动汽车动力系统E/E架构的原型，但这个概念很容易扩展到混合动力电动汽车，甚至传统汽车。它是一个领域控制架构，有一个强大的中央控制器和外围控制器（智能执行器）。DC实现了该领域的大部分功能，同时包含了不同车辆变体的差异性（例如，提供的功能、动力系统配置等方面的差异）。
另一方面，智能执行器是一个低成本的控制器，能实现基本的执行器功能。此外，该领域还包括一个网关，在DC和车辆的其他部分之间路由所有硬件信号，包括数字信号和模拟I/O信号，以及现场总线信号。图1中的图表使用以太网进行域内通信，作为一种新兴的高速汽车网络技术，但域内的控制器也可以根据需要使用典型的现场总线(CAN、CAN FD、LIN、FlexRay)连接到DC上。域间连接（未显示）通常是处于高速的，如汽车以太网。
由于E/E架构的集中化仍处于相对早期的阶段，我们有理由假设在汽车环境中，只有部分E/E架构是集中的，比如一个或两个域。我们的方案的设计是这样的，它可以促进传统的分散式E/E架构向集中式架构，一次一个领域的渐进式转变。这可能是实验或概念验证工作的情况。我们用一个集中化的领域，即动力系统领域，来解释集中化的想法并展示我们的方法。但我们提出的方法既可以用于完全集中的E/E架构，也可以用于部分集中的E/E架构。前面提到的领域网关有助于在这种混合的E/E架构中使用我们的方法。
4.后备控制策略
在本节中，我们将介绍我们所提出的安全架构，将其与传统的安全架构进行比较，并讨论该架构的一些重要方面。
A. 安全架构
我们假设一个DC的灾难性损失的情况。对于这种情况，我们提出了一个后备方案，在该方案中，关键的DC功能是以分布式的方式，在域内每个可用的子域ECU或整个车辆的余量资源中实现的。这里的余量是指已知可供使用的ECU的资源，如未使用的RAM、闪存和空闲的CPU时间。在DC完全丢失的情况下，分散的后备实现将控制受影响的域，将该方案置于“故障-可操作”类别中。该方案如图2所示。如前所述，我们专注于动力总成领域，但我们的建议实际上是通用的，可以用于任何安全关键的车辆领域，或跨领域集中的情况下的域组合。
图2. 将后备组件分配到域ECU
图2所示的动力系统域由一个DC、三个智能执行器和该动力系统域与车辆其他部分之间的域网关组成。当DC无响应时，这些分布式组件可以共同协调并接管对域的控制。硬件信号通过网关以相同的方式进出于实现的各个参与者。唯一的区别是，在这种情况下，信息不是流经一个（DC），而是流经多个节点（实施后备策略的智能执行器）。网关必须管理这种信息的路由，由基于以太网的域骨干网络的IP层提供所有必要的识别信息。
图3. 域内余量CPUC利用率示例
通常情况下，每个子域的ECU都会有一定的执行余量（如图3）。这种余量也存在于ECU的闪存和内存上。这种情况通常是由于特定ECU软件的硬件要求与市场上具有不同功能的ECU之间的不完全匹配造成的。让我们假设部署在ECU-EM上的软件正好需要1.5MB的闪存，最大内存1MB的RAM和最高速度为2.5MHz的CPU。但市场上最接近的产品有2MB的闪存，1.5MB的RAM和最高可达2.5MHz的CPU。
对于ECU-EM的应用，将选择这个产品，可以提供上面提到的0.5MB的额外闪存，0.5MB的额外RAM和一个比要求快1.6倍的CPU。这个例子是为了强调这种余量的潜力，但在实践中，即使市场上有完美适配的产品，通常也会选择具有余量的ECU硬件，因为必须考虑到ECU软件未来可能会有变化。此外，在DC失效的情况下，最大的CPU利用率可能会小于额定值，因为当DC消失时，子域ECU不需要再履行某些功能，或者不需要达到与之相等的水平。这可以进一步增加可用的执行余量。
与DC相比，这些ECU相对便宜，因此，另一种情况是，设定额外的余量以适应后备策略，这样应该只需要很小的边际成本。根据子域ECU上可用的总余量，DC的全部能力可以在备用方案得到体现，但最有可能的是部分功能无法实现，即实现"跛行模式"功能。
域网关(ECU-GW)是我们的方案很重要的一部分。它将所有的硬件信号，包括I/O线，LIN，CAN等，从车辆的各个部分输出和输入，由于前面提到的原因，这些部分不能转化为智能执行器。这意味着没有硬件I/O（模拟或数字）或LIN，或者任何其他低电平信号直接在DC和车辆硬件之间传输。这个网关是一个智能执行器，与该领域中其他的智能执行器一样，其唯一的功能是连接不属于智能执行器的硬件。我们正在进行的工作中有一个重要的例子，就是加速踏板。
在正常操作下，领域网关必须促进DC和硬件之间的某些交互，而这些硬件是没有被抽象为智能执行器的。这些交互包括CAN和LIN通信计划的执行，模拟信号、数字信号和PWM信号的读取和发射等。因此，域网关本质上必须充当DC和与之相连的硬件之间的信息路由器，同时总体上尽量减少引入的延迟，以确保在任何关键情况下都能满足时序要求。在备用操作下，当DC丢失时，网关必须促成同样的互动，但现在，就网关而言，任何智能执行器都可以充当DC，因为所有这些参与者现在必须与DC一样访问硬件。当然，这可能取决于后备软件的分区方式，但一般来说，上述操作是符合事实的。因此，很明显，需要一个非常严谨的路由协议来操作后备策略。初步调查显示，这样的协议可以在基于以太网的域骨干网的情况下实施。
我们之所以不允许除骨干以太网连接之外的任何连接到DC，是因为如果DC发生故障，上面提到的其他I/O连接仍然可以用于域。如果这些信号在DC故障时仍然可用，那么就有可能实施我们所提出的分散式后备策略，并且不需要任何特定的信号线的重复。尽管在这样的体系结构中，网关就像DC一样是单点故障，但需要注意的是，网关机制可以在比DC本身更简单、更便宜的ECU上实现。重复网关ECU成为解决这一缺点的经济而有效的安全措施。
B. 与经典方案的比较
本文所提出的回退策略提供了一个故障操作容错解决方案，不需要重复DC。因此，它比基于硬件冗余的解决方案更严谨、更节能、更便宜。由于它本质上是一个分布式架构，它的开发可以在各方面都受益于分散式E/E架构开发的技术水平。
另一方面，虽然硬件冗余在概念上和实践上都很简单，但我们提出的方法，其设计和实施基本上需要两个平行但协同的开发工作，一个是集中式E/E架构，另一个是叠加在其上的分散式后备方案。由于我们所提议的备用方案是分散式的，因此必须谨慎设计，使其保持简单，并且在不同车型之间不轻易发生变化，以避免集中化所面对的首要问题。由功能安全分析可知，由于在后备方案中不太可能需要DC的全部功能，因此必须实现最小的功能集。
5.结论
在本文中，我们提出了一个关于集中式E/E架构的安全模式的早期建议。为了了解该方法的适用性，还需要进一步分析和评估，作者正在就几个方面进行研究。例如，必须根据ISO 26262标准对智能执行器控制器和控制软件同时执行的备用元素进行分区。
尽管存在诸如虚拟化等商业解决方案，但可能一个更简单的定制分区方案就足够了。同样与标准有关的是，该方案引入了使用ASIL分解，以减少中心化领域的开发工作和成本。必须开发切换到后备控制方案的决断、同步和重新配置逻辑。在我们的示例中，域网关是一个必要的设计元素，但考虑到它在后备策略设计中的关键作用，我们将进一步研究如何使用这种网关作为集中式E/E架构设计的原则。
图片使用申明：原创文章图片源自‘Canva可画’平台免费版权图片素材；引用文章源自引用平台文章中所使用的原图。