集中式E/E架构的安全设计

发布时间：2023-12-15 03:10:26 所属栏目：应用来源：DaWei

导读： 现代道路车辆的复杂性与日俱增。为了保持竞争力，汽车必须满足客户对功能和性能的期望，而这些期望本身又与连接性、电气化、泛在技术、通信、即时访问等趋势息息相关。这种趋势增加了车辆的

现代道路车辆的复杂性与日俱增。为了保持竞争力，汽车必须满足客户对功能和性能的期望，而这些期望本身又与连接性、电气化、泛在技术、通信、即时访问等趋势息息相关。这种趋势增加了车辆的复杂性，并反过来推动汽车E/E（电动和/或电子）架构的演变，从传统的基于总线的分散式架构，由几十个ECU（电子控制单元）组成，发展到集中式架构。集中式架构由车辆领域（域控制架构）或域组（跨域架构）专用的计算集群组成，并由一个强大的ECU独立控制。

集中式架构还包括区域架构，在区域架构中，车辆级别的单个计算机集群可以实现车辆的主要功能。在本文中，我们主要考虑了域和跨域的架构。域和跨域架构利用强大的、价格相对较高的顶级ECU，分别称为域控制器（DC）或跨域控制器（CDC），而控制域的其他ECU，本身相对便宜。在本文中，我们将使用DC来表示域控制器和跨域控制器。

在每个领域（或域的组合）中，DC是最要紧的单点失效。因此，当一个车辆领域仅由一个强大的DC控制时，最大的担忧之一是在该控制器完全丢失的情况下会发生什么。更确切地说，我们更关心的是DC的不可恢复的故障，如功率损失、液体进入DC等。

在本文中，我们提出了一种安全架构，专门针对这种情况，我们认为这种架构可以最大限度地减少与功能安全专用硬件相关的成本，并充分利用集中式架构的基本通用性。我们建议，在DC发生灾难性故障的场景中，应该在受影响领域内剩余的ECU中实施一个分布式控制方案，让其接管故障DC的部分功能。虽然理论上这样的方案可以实现DC的全部功能，但这并不是该方案的目的。在其基本功能形式中，这种后备体系结构不需要任何其他硬件，只需要集中的领域中的硬件。

不可否认的是，它增加了智能执行器所需的计算资源，必须仔细规划以适应后备功能。虽然我们的架构像经典的安全架构一样利用了冗余，但它有望成为一个更经济的解决方案，因为它使用现有的硬件资源，而不是像更传统的架构那样，依赖于冗余的ECU或微控制器的更昂贵的解决方案。据我们所知，我们提出的架构在这方面是独一无二的。必须指出的是，我们的提议只是涵盖了集中式车辆领域完整安全架构的一个方面。其余的，如域内通信功能安全方面，则不在本文的讨论范围内。

一般来说，专门针对集中式E/E架构的功能安全的工作不多，尤其是我们在本文中讨论的情况。然而，还是可以找到一些参考建议的。Sommer等人提出了一个带有以太网骨干网络的车辆区域结构。中央计算机集群由若干台“车辆控制计算机”组成，这些计算机可以是双工控制计算机(dcc)，也可以是单工控制计算机。一个DCC有两条执行路径，两条路径上的相关输出都被监控和比较：如果观察到错误，结果就会被丢弃，第二个冗余的DCC就会接手。此处可以有多个冗余DCC。在正好有两个DCC的情况下，这种结构实际上成为duo-duplex架构。汽车以太网网络是环形的，有两条独立的路径。在这种情况下，该方法也是基于硬件冗余的。然而，汽车应用所需要的是能够以远低于硬件冗余的成本提供故障操作功能。

由于E/E架构的集中化仍处于相对早期的阶段，我们有理由假设在汽车环境中，只有部分E/E架构是集中的，比如一个或两个域。我们的方案的设计是这样的，它可以促进传统的分散式E/E架构向集中式架构，一次一个领域的渐进式转变。这可能是实验或概念验证工作的情况。我们用一个集中化的领域，即动力系统领域，来解释集中化的想法并展示我们的方法。但我们提出的方法既可以用于完全集中的E/E架构，也可以用于部分集中的E/E架构。前面提到的领域网关有助于在这种混合的E/E架构中使用我们的方法。

对于这种情况，我们提出了一个后备方案，在该方案中，关键的DC功能是以分布式的方式，在域内每个可用的子域ECU或整个车辆的余量资源中实现的。这里的余量是指已知可供使用的ECU的资源，如未使用的RAM、闪存和空闲的CPU时间。在DC完全丢失的情况下，分散的后备实现将控制受影响的域，将该方案置于“故障-可操作”类别中。该方案如图2所示。如前所述，我们专注于动力总成领域，但我们的建议实际上是通用的，可以用于任何安全关键的车辆领域，或跨领域集中的情况下的域组合。

当DC无响应时，这些分布式组件可以共同协调并接管对域的控制。硬件信号通过网关以相同的方式进出于实现的各个参与者。唯一的区别是，在这种情况下，信息不是流经一个（DC），而是流经多个节点（实施后备策略的智能执行器）。网关必须管理这种信息的路由，由基于以太网的域骨干网络的IP层提供所有必要的识别信息。

这种余量也存在于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成为解决这一缺点的经济而有效的安全措施。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!