为软件定义车辆基础设施平台铺平道路

当前的驾驶员辅助功能，例如高速公路的自动停车或交通拥堵辅助和车道偏离警告系统，是迈向自动驾驶的第一步。但就未来几年预期的驱动功能而言，今天的系统架构已经达到了极限。控制设备日益增长的互连性及其日益复杂的功能需要在开发和跨功能、跨车辆软件平台方面采用集成系统方法。

许多驾驶员辅助功能今天已经可用。但根据法律，司机仍然不能完全依赖这个系统。如果发生错误（例如，传感器发生故障），他们必须能够立即重新获得控制权。

未来的驾驶员辅助功能将为驾驶员提供新的自由，因为车辆操作员将能够转移他们对交通的注意力并倾向于其他活动。他们将被允许松开方向盘，激活辅助功能，还可以在交通拥堵时进行视频通话，而不是全神贯注于交通。

奥迪宣布其 2017 款车型的交通拥堵辅助系统等系统将为驾驶员提供更多时间来控制车辆，因为最初驾驶员将有长达 10 秒的时间重新指挥他们的车辆。但是，这也意味着驾驶员可以在辅助功能激活时关注其他事情，这意味着如果发生系统故障，他们将无法使用。在此期间，车辆将负责避免或处理危险情况，因为在完全控制权交还给驾驶员之前，它无法在出现错误时简单地关闭。相反，他们必须保持最低水平的功能，以保证车辆和车内人员的安全，所以，事实上，

【图1 | 实现自动驾驶汽车的各个阶段都需要改变系统架构。］

转变始于发展

虽然车辆基础设施、硬件和软件都必须经过精心设计，即使在系统出现错误的情况下也能正常工作，但在向自动驾驶紧急功能过渡的初始过渡中，可能会有一个初步的范围——例如，进入保险箱、带有警告信号闪光灯的慢停。这种“安全状态”在交通拥堵的情况下已经足够了，但在正常交通情况下，系统必须安全地开车到最近的紧急休息区或从下一个出口安全停车。

根据发生错误时所需的功能范围，必须涉及许多子功能和相关的传感器、执行器和软件计算。为了能够实现具有自动驾驶所需的可用性和可靠性的功能，需要修改系统架构。

控制设备暂时仍将是经典开发，因为驾驶员辅助功能的实现是静态的并且遵循特定的模式：导入传感器数据、计算控制设定点、控制执行器。然而，在未来，开发团队将被迫在系统级别实施越来越多的解决方案。单个控制设备将离开中心舞台，整个系统将成为焦点，因为如果原始执行硬件发生故障，通信路径必须能够改变并且软件功能必须由其他硬件实时执行。

实现实际系统级辅助功能的要求越来越严格，传感器和执行器在网络中的复杂性也在增加。对能够实时执行复杂计算的高性能处理器的需求不断增长，软件元素还必须满足严格的安全要求，最高可达汽车安全完整性等级 D （ASIL D），即汽车的最高软件安全等级。

在最佳情况下，汽车行业利用的计算机架构将以一种使功能独立于硬件的方式实现，因此安全关键软件不必经过特殊调整即可在充当驾驶员执行平台的异构控制器架构上运行未来的辅助系统。理想情况下，开发人员不需要知道他们的共享功能将在何处以及如何执行。

修改后的系统架构

这种平台的一个例子是 NVIDIA DRIVE PX，它由两个 Tegra K1 处理器作为性能控制器，一个英飞凌 Aurix 处理器作为安全控制器，并支持 Elektrobit 的 EB tresos 软件环境。EB tresos 基于称为 AUTOSAR 自适应平台的汽车开放系统架构 （AUTOSAR） 标准的变体，并为 Tegra 处理器上的动态操作系统（在本例中为 Linux）形成运行时环境。

Elektrobit 开发的驾驶员辅助应用程序框架是在该系统上运行的应用程序。该框架实现了用于融合传感器数据、轨迹规划和控制的模块，以及用于同步和协调多个驾驶员辅助功能的标准机制，作为“情况和决策”模块的一部分。在框架中运行的辅助功能（例如自动停车功能）依赖于底层 EB tresos 基础设施提供的安全机制，因此功能管理和合规性监控软件以及错误处理可以不受干扰地运行安全控制器本身。这保证了可靠的操作，并且还可以在控制设备上运行具有高 ASIL 等级的软件，同时具有高性能，

【图2 | 软件层与高性能硬件平台（例如 NVIDIA DRIVE PX）相结合，是集成系统方法的基础。］

借助 DRIVE PX 上的 EB tresos 环境等动态软件平台，各个功能之间的通信路径是透明且灵活的。应用程序是使用经典的 AUTOSAR 运行时与控制设备上的环境进行通信，还是通过适当的软件层动态建立和取消与随机发送器和接收器的通信，这与未来的应用程序无关。这种通信灵活性支持“故障运行”系统所需的冗余机制，例如，通过实现热备用功能。热备用意味着可以在其他硬件环境中使功能成为冗余，这些硬件环境处于备用状态，并且仅当功能在主环境中发生故障时才激活。这些额外的硬件环境将 CPU 时间和内存等资源用于特定功能，因此并行运行。这导致快速切换能力，从而传感器和执行器信号根据功能运行的位置动态重新路由。

【图3 | 动态控制设备架构保证了专用功能范围的可靠性。］

集成开发和“整车操作系统”

在允许所描述的动态行为的控制设备架构中，您可以通过在系统级别智能连接多个此类控制设备来保证专用资源的可用性，以便功能可靠地执行，而与发生的错误或硬件故障无关。然而，这样做的挑战在于，它还需要一种系统范围的软件基础架构方法，以便实时动态地管理整个系统。在这样的实施中，必须集中有关各个控制设备的信息，例如硬件状态和运行时完整性，以决定如何最好地重新配置系统。

如果将新技术添加到故障操作要求中，例如车辆与其周围环境之间的永久、持久连接，则此处的需求变得更加明显。像这样的在线连接需要修改架构以满足严格的安全要求，以及提供防火墙、访问控制和入侵检测工具，以便监控和预防对安全关键系统的潜在威胁。

其中许多要求可以通过具有中央控制和分配机制的面向服务的架构 （SOA） 来满足，但是需要一个新的软件基础设施，即“整车操作系统”，将自动驾驶汽车的所有维度集成到未来几年。使用当今的开发方法实现自动驾驶系统所需的硬件和软件将是困难的，因为车辆目前由仅与本地功能通信的“孤独的战士”控制设备组成。其中一些设备是相互独立定义的，由汽车制造商的不同部门指定，并由不同的供应商开发。这些设备的软件部分基于 AUTOSAR 等标准，但通用平台是未来的解决方案。

向软件定义车辆的转变

将自己视为非传统汽车制造商的新玩家和各种电动汽车初创公司以及主要的 IT 供应商具有为驾驶员辅助等新兴系统领域启动新结构开发流程的优势。因此，他们将能够加速汽车系统架构的变革，促使汽车制造商、一级供应商和软件开发商随着时间的推移改变实践。这是设计全新系统架构的唯一方法，为未来的软件定义车辆基础设施平台铺平道路。

审核编辑：郭婷