◆文/江苏 高惠民

(接2023年第9期)

(3)基础软件层

基础软件层主要与硬件相关，主要包括操作系统(operating system)和中间件(middleware)等。通过对基础软件层进行标准化，汽车厂商可专注于开发有竞争力的上层应用软件，而无须过多关注底层基础软件与硬件。根据功能的不同，基础软件层进一步可划分为服务层、ECU抽象层、微控制器抽象层和复杂驱动层，如图30所示。

图30 AUTOSAR层面示意图

①服务层由一系列基础软件组件构成，包括系统服务、存储器服务、通信服务等，主要提供操作系统、网络通信、内存管理、诊断、ECU状态管理模块等基础服务，对应用层功能提供辅助支持。

②ECU抽象层将ECU结构进行了抽象，主要提供ECU应用相关的服务。该层软件直接实现了ECU的应用层功能，可以读取传感器状态、执行控制器输出等。

③微控制器抽象层是实现不同硬件接口统一化的特殊层，是对ECU所使用的主控芯片的抽象，与芯片功能的实现紧密相关，是ECU软件的最底层部分，直接和主控芯片及外设芯片进行交互。微控制器抽象层软件模块主要由各个驱动程序构成，如CAN驱动程序、LIN驱动程序、MCU(microcontroller unit，微控制单元)驱动程序等，通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。

④复杂驱动层主要面向处理复杂硬件信号、执行复杂硬件动作的ECU，如发动机控制、ABS等，这些功能相关的软件很难抽象出来适用于所有类型ECU，它与ECU应用及其所使用的硬件紧密相关，是AUTOSAR中无法在不同ECU平台上移植的部分。

AUTOSAR的分层式设计，用于支持完整的软件和硬件模块的独立性，中间RTE作为虚拟功能总线VFB的实现，隔离了上层的应用层与下层的基础软件层，摆脱了以往ECU软件开发与验证时对硬件系统的依赖。硬件层仅与基础软件层直接相关，完全独立于应用软件层，既能促进位于RTE之下的基础软件层实现标准化，又方便汽车厂商无须特别关注基础软件层，只需专注于开发特定的上层应用软件；提高了系统整合能力，特别是标准化交互接口以及软件组件模型的定义提高了各层的软件复用能力，从而减少了开发成本，提高了系统集成与产品推出的速度。

自动驾驶汽车需要实时处理大量数据。其电子电气架构要求具备高性能计算的控制器控制器算力及通信带宽需进行巨大升级。实现高吞吐量、高通信带宽的高性能计算能力，除了需要硬件架构上，如异构多核处理器、GPU加速等的支持，也需要适配新的软件架构来支持跨平台的计算处理能力、高性能微控制器的计算以及远程诊断等。此外V2X通信涉及动态通信及大量数据的有效分配，例如及时获取交通路况需要第三方合作伙伴参与，因此需要新的软件架构支持云交互以及非AUTOSAR系统的集成。自动驾驶车辆云端互连还需要专用安全手段的支持，以确保云交互和车载系统的通信安全。AUTOSAR一般是指传统(Classic)平台，然而，AUTOSAR Classic架构无法适应上述新的需求，因此在其基础上又诞生了汽车自适应开放系统架构(AUTOSAR Adaptive)。AUTOSAR Adaptive体系架构主要包括应用层、运行层(AUTOSAR runtime for adaptive，ARA)、基础服务层，如图31所示。图32列举了一些AUTOSAR Classic与 AUTOSAR Adaptive的主要区别。

图31 AUTOSAR Adaptive体系架构

图32 AUTOSAR Classic与 AUTOSAR Adaptive的主要区别

与AUTOSAR Classic相比，AUTOSAR Adaptive面向高性能计算处理器架构，其硬件层的算力更高，具有更高的吞吐量AUTOSAR Classic是基于信号通信，发送者只负责将信号发送出去，接收者只需接收目标信号即可，这种方式适用于有限大小控制数据的应用场景。

AUTOSAR Adaptive基于服务通信，接收者作为客户端查找、订阅服务，发送者作为服务提供者按照需求为订阅者提供服务和信息，这种方式大大提高了通信效率而降低了负载，适用于自动驾驶等需要大量数据动态交互的场景。

AUTOSAR Classic支持高安全性和高实时性的应用场景，适用于部署运行深度嵌入式的软件功能。AUTOSAR Adaptive在保证安全等级、降低小部分实时性的情况下，能够满足非实时性的架构系统软件的需求，并大大增强了高性能计算处理能力，支持大数据的并行处理、智能互联应用功能的开发。因此，AUTOSAR Classic架构及AUTOSAR Adaptive架构针对不同的应用场景可实现二者的共存和协作。自动驾驶汽车将采用同时包含AUTOSAR Classic以及AUTOSAR Adaptive的异构软件架构，如图33所示，继承软件分层控制思想，实现软硬件解耦，注重应用软件标准化，并由车载操作系统为各类服务生态提供接口，掌控用户交互界面。

图33 包含AUTOSAR Classic以及AUTOSAR Adaptive异构软件架构

2.车用操作系统

车用操作系统(automotive operating system，AOS)是管理车载计算机硬件与软件资源的计算机程序，需要处理如管理与配置内存、决定系统资源供需的优先次序、控制输入设备与输出设备、操作网络与管理系统文件等基本事务。操作系统的性能和生态系统对于开发“软件定义汽车”所需的应用程序和软件平台是至关重要的，一个好的车用操作系统需要大型生态系统和可靠的架构支撑。车用操作系统要求如图34所示。

图34 车用车载系统要求

若车用操作系统功能欠佳，其代价不仅是工作效率低下，而且关乎生命安全，所以自动驾驶汽车的操作系统在监控支配汽车时的反应需要精确到微秒级，能够实时感知周围环境并规划出新的解决方案。

根据国家汽车标准化技术委员会在2019年10月发布的《车用操作系统标准体系》划分，车用操作系统按照应用功能细分为三类：安全车控操作系统，主要面向车辆动力系统、底盘系统、车身系统等传统控制领域，要求极高的实时性、可靠性、计算能力和(功能和信息)安全性；智能驾驶操作系统，主要面向智能驾驶(域控制器)领域，要求较高的安全性和可靠性；车载操作系统，体现人机交互功能。主要面向信息娱乐和智能座舱(中控系统)，对安全性和可靠性要求低于车控操作系统和智能驾驶操作系统。汽车制造商开发自主操作系统方式主要分为三种，如图35所示。

图35 三种操作系统应用

定制型操作系统是基于基础型操作系统，从系统内核到应用程序层进行深度重构，将硬件资源进行整合优化。ROM型操作系统是基于需求定制汽车服务及以上层级，下层则基于Android等系统自有架构。超级App是只在应用层调用系统已有接口相关功能，其余层级则完全沿用已有系统架构。定制型、ROM型、超级App，其内涵如图36所示。

图36 定制型、ROM型、超级App含义

(1)基础型操作系统：目前基础操作系统目前主要形成了以QNX为主，Linux次之的竞争格局，WinCE逐渐退出车载操作系统市场，未来在国际市场上，Android市场占有率将保持继续上升趋势。QNX、Linux、Android构成汽车操作系统三大阵营。基础操作系统特点对比分析如图37 所示。

图37 基础型三大阵型特点

(2)定制型操作系统:在基础型操作系统之上进行深度定制化开发而成，属于自主研发的独立操作系统。典型代表如大众VW.OS、特斯拉Version、Google车载Android、华为鸿蒙OS、阿里AliOS等，如图38所示。

图38 定制型操作系统应用的典型代表

(3)ROM型操作系统：国外传统车企的ROM型车载操作系统：底层操作系统一般基于QNX或Linux开发，如图39所示。由于国内Android应用生态更好，国内自主品牌和造车新势力大多基于Android定制汽车操作系统，例如比亚迪DiLink、吉利GKUI、小鹏Xmart OS等。

图39 国外传统车企基于QNX或Linux开发ROM型车载操作系统应用

(4)超级App：超级汽车App又称车机互联或手机映射系统，不是完全意义上的汽车操作系统；其借助手机的丰富功能映射到汽车中控，以满足车主对娱乐的需求。应用品牌如图40所示。由于容易实现并且成本较低，现阶段仍是车主的主流选择。

图40 超级汽车App应用

汽车操作系统作为硬件与软件的接口，分层架构如图41所示。成为企业核心竞争点。底层操作系统主要有QNX、Linux及Andriod；目前主要采用基于底层系统研发独立操作系统、基于ROM定制及在应用层开发超级App三种方案切入该领域。(未完待续)

图41 汽车操作系统硬件与软件的接口及其分层架构