AUTOSAR Adaptive与智能汽车E/E架构发展趋势

在这里插入图片描述

AUTOSAR Adaptive是一个面向现代汽车应用需求的标准，特别适用于那些需要高计算能力和灵活性的应用。以下是AUTOSAR Adaptive的典型特性：

高计算能力：AUTOSAR Adaptive支持使用MPU（微处理器），这些处理器的性能与PC或智能手机中的处理器相当。这样的高计算能力是实现半自动驾驶和其他复杂功能所必需的。
动态更新和管理：AUTOSAR Adaptive的架构允许更动态地处理软件，这意味着可以更容易地进行空中更新和安装新软件。这对确保车辆软件的最新状态和功能至关重要。
模块化和灵活性：AUTOSAR Adaptive支持模块化设计，使得开发和更新变得更加灵活。各个模块可以独立开发和更新，而不需要对整个系统进行大规模的改动。
POSIX兼容操作系统：AUTOSAR Adaptive通常运行在POSIX兼容的操作系统上，这种操作系统能够更好地管理资源并提供更强的硬件抽象。这样，开发人员就可以专注于应用功能而不是底层硬件。
服务导向架构：AUTOSAR Adaptive推动了服务导向架构（SOA）的使用，这种架构使各个ECU之间的依赖性更低。这样，如果需要更改或更新某个ECU，可以最大限度减少对其他系统部分的影响。

在这里插入图片描述

总的来说，AUTOSAR Adaptive为实现现代汽车的复杂功能提供了一个强大且灵活的平台，支持高性能ECU的使用，确保系统的可扩展性和动态管理能力。

自动驾驶辅助系统、OTA以及后续的附加软件安装将很快成为许多车辆的标准配置。试想一下，未来汽车作为一个新的智能化终端设备，就像当年iPhone为首的智能手机对传统手机的冲击一样，会对传统汽车造成多大的震撼？也许我们的汽车在公路上行驶，遇到了另外一位驾驶智能汽车的小姐姐，我们再也不需要向传统方式一样想尽办法让对方停车互加微信，而是直接通过车车互联，类似IOS17两个设备一靠近就可以传递数据，用自己的爱车加对方的爱车好友，从此建立了联系，然后王子和公主过上了幸福的生活（纯属娱乐哈）……然而，如果没有新的架构和高性能ECU，这些复杂的电子功能是无法实现的。那么，新的软件标准AUTOSAR Adaptive在其中扮演了什么角色呢？

基于上述功能，车内软件的数量和复杂性持续快速增加。这一趋势并不新鲜。但目前，汽车行业的众多企业正在经历显著变化，以满足新的市场需求。这对汽车电子领域尤为如此。因为新任务所需的计算能力很高，微处理器在电子控制单元（ECU）中被越来越多地使用，以补充之前在汽车领域使用的MCU（微控制器）。这些微处理器，往往与微控制器结合在一起，形成所谓的高性能ECU。这些ECU中的微处理器与智能手机或PC中使用的非常相似，因此需要新的软件架构。这样一种架构的一个方面是POSIX兼容的操作系统，它们通常用于高效利用计算资源。这些操作系统允许对执行的软件进行更动态的处理，并比以前使用的实时操作系统更彻底地抽象硬件。为了将这些微处理器无缝集成到现有的车辆网络中，运行在操作系统之上的中间件基于AUTOSAR Adaptive标准。

车辆的E/E架构也在发生变化。域和中央服务器架构将上述高性能计算机集成到车辆中。在快速数据网络和强大处理器的支持下，重点不再是高效的数据传输，而是更强的单个ECU解耦。更改单个ECU应对系统的其余部分影响尽可能小。一个典型的做法是引入面向服务的架构。

新的E/E架构与中央服务器

除了解耦各个组件，提高硬件和软件的复用性也是一个重要目标。这意味着组件可以跨车辆甚至跨制造商使用。近年来的经典E/E架构无法满足这一需求。

在这里插入图片描述

图1a展示了一种ECU导向的架构。在这种架构中，一个功能由一个ECU实现，并配有一组相关的传感器和执行器，同时从车辆网络接收额外的数据。车辆的通信矩阵描述了这些ECU之间的必要通信通道。然而，这种设计限制了复用性。传感器和执行器直接连接到功能性ECU上。如果其他总线参与者需要使用这些数值，则需要更改通信矩阵。为了解决这个问题，就有了域控制器架构（见图1b）。

在这里插入图片描述

典型的域包括“车身域”、“动力域”和“信息娱乐域”等。该架构的基本思路是每个域使用一个强大的控制器，连接大部分必要的传感器/执行器。在该域内，它还协调后续的ECU。这极大地提高了在域内扩展功能的灵活性，因为调整通常只会导致域内的局部变化。但前面提到的使用场景无法直接分配到某个域。高度自动化的驾驶功能需要来自所有域的信息，并且还会将数据反馈给它们。

这种方法的下一步发展是中央服务器架构（见图1c）。

在这里插入图片描述

各个域被组合到一个大型高性能计算机或计算机集群中。然而，这与域架构有更多的区别。例如，不能再将传感器/执行器直接连接到中央控制单元，因为目前的处理器无法连接如此多的I/O外设。传感器/执行器现在被直接连接到网络，称为“智能传感器”和“智能执行器”，并执行机电任务。因此，它们变得与ECU和车辆无关，能够实现具有高重用潜力的模块化系统设计。然而，对低成本传感器来说，这种方式的成本收益比不理想。为了使用这些传感器，它们可以直接连接到图1.c中蓝色表示的集成节点。这些节点ECU还有另一个重要功能：它们充当传感器和执行器总线系统（如CAN、LIN、FlexRay和以太网)之间的网关。在这个网络中，以太网在朝中央计算机方向代表主要的总线系统。通过一个适当抽象的接口与传感器和执行器ECU进行连接，创建了一个模块化且功能可扩展的架构。

中央服务器的复杂架构

中央服务器或集成节点是复杂的ECU，它们通常由多个微控制器和微处理器组成。这种异构结构提供了一些优势，因为控制器和处理器在各自的属性上互为补充。一个例子是微控制器的启动时间较快。开机后，它可以迅速投入运行，从而参与与其他ECU的通信并执行其功能。此外，微控制器可以满足微秒范围内的最高定时要求，并且具有低抖动特性。如果实现的功能需要频繁中断，微控制器也是更好的选择。

微处理器在其他领域有其强项。最重要的当然是其性能。所使用的计算核心提供了更高的时钟频率，并带有许多功能，如高多标度性或跳转预测，这些都能提高平均性能。更大的缓存还能允许连接速度较慢但容量较大的外部存储设备。除了更多的资源容量外，微处理器还提供更好的硬件虚拟化支持，使得使用虚拟机管理程序（Hypervisor）技术变得更加容易。

微控制器和微处理器的异构设备在满足安全要求方面也有优势。根据ISO 26262，当前的处理器可以达到最高ASIL B的完整性等级。通过使用冗余，即使是高度自动化驾驶所需的ASIL D等级也可以实现。在这种系统中，额外的微控制器执行两个任务：一方面，它执行监控功能；另一方面，在发生故障时，它还能提供降级功能，使系统能够在高可靠性下继续运行。这是对失效操作系统（即在发生故障时必须继续运行的系统）所要求的重要特性（见图2）。

ECU配备多个可编程组件还有另一个方面：从外部看，它仍然是一个单一的ECU。然而，内部有许多独立的软件组件实现ECU的功能。这带来了技术和集成方面的挑战。从技术角度来看，这些组件必须能够相互通信以提供共同的功能。ECU制造商的任务是使用处理器间通信（IPC）连接这些组件并描述交换的数据。这是ECU制造商的新任务，因为在之前的工作流程中没有这一步。以前只需要描述ECU之间的数据交换。然而，这一责任现在完全由整车制造商承担。同样适用于诊断功能、软件更新和系统的网络管理：过去由一方定义的简单ECU现在需要分布式和协调的实现。

从集成角度来看，集成各种软件组件是一个日益增加的挑战。ECU的模块化设计和POSIX兼容的操作系统使得来自多个独立团队的软件集成变得更容易。然而，这也使得ECU集成者的角色变得越来越复杂。因此，支持ECU集成者的专业工具对于其复杂任务变得更加重要。

在这里插入图片描述

AUTOSAR Adaptive作为中央ECU的平台

如前所述，在微处理器上运行的软件组件通常不基于AUTOSAR Classic标准。相反，为了满足模块化、动态性和更新能力的要求，使用AUTOSAR Adaptive。这使得AUTOSAR Adaptive成为车载高性能计算平台的事实标准。AUTOSAR Adaptive中间件使用如Linux、PikeOS或QNX等POSIX兼容的操作系统，并为其补充了所有必要的汽车扩展功能。AUTOSAR Adaptive的主要功能之一是通信层ara::com。它不仅支持与其他AUTOSAR Adaptive应用程序的通信，还可以与车辆内的其他软件组件（SWC）进行通信（见图3）。

在这里插入图片描述

诊断、安全和保护功能补充了该平台的功能特性。这听起来很像AUTOSAR Classic基础软件，但两者在架构和技术上有很多不同之处。例如，ara::com是一种面向服务的中间件。这允许在运行时建立动态通信路径。这种动态性是支持在运行时安装应用软件的前提条件。而传统的通信矩阵需要调整才能将新内容发送到ECU。而采用面向服务的方法，信息可以通过订阅获取。

还有一些不那么明显的优势：硬件驱动程序和高级软件被更严格地分开。这样，车辆中的硬件无关应用变得高度可移植。这比AUTOSAR Classic ECUs能实现更大的资源优化。例如，在开发阶段，如果资源限制超出预算，软件可以轻松地在不同的ECU之间移动，以避免更改硬件设计。另一个优势是，软件组件在不同车型中的复用性提高了。

在AUTOSAR Adaptive项目中，软件和硬件的分离还带来了整车制造商和供应商之间全新的工作分配方式。以前，功能总是以物理设备的形式出现在车辆中，现在可以完全以软件形式采购。为实现这一点，每个AUTOSAR Adaptive应用程序现在都是一个独立的二进制文件。应用程序开发因此独立于ECU开发。车辆的驾驶员可以通过应用商店安装额外的应用程序，成为自己的集成者。

但如果系统在路上出现故障，谁来负责呢？车辆中可能安装了未经测试的应用组合。这种情况与AUTOSAR Classic ECUs中的典型集成方法相冲突，在后者中，每个配置都经过彻底测试。为了避免测试所有应用组合，必须保证应用之间的相互独立性。商用操作系统可以保证安全相关应用的内存限制不会被超越。他们为此提供硬实时调度方法。这需要定义内存限制和应用程序的最坏执行时间（WCET）。由于没有直接与硬件交互，由更改的中断负载引起的时间相关副作用不再显著。

当然，这种努力仅对安全相关的应用程序是必要的。使用虚拟机管理程序（Hypervisor）可以使不同动态性和安全等级的系统并行运行。质量管理（QM）应用可以位于系统中更动态和类似IT的分区中，这些分区可以使用开源软件。然而，在安全相关的分区中需要谨慎，因为软件错误和安全漏洞不能以必要的速度消除。使用开源软件在产品责任方面也存在风险。