汽车软件主要分为应用软件和基础软件。应用软件和业务形态高度关联，不同控制器的应用软件之间差异较大。

基础软件介于应用软件和硬件之间，用于屏蔽硬件特性、支撑应用软件。可有效地实现应用软件与硬件之间解耦，非常适合平台化最终形成基础软件平台。

根据中国汽车基础软件发展白皮书3.0所描述，车用基础软件平台分为车用基础软件开发平台和车用基础软件验证平台。

其中，基础软件开发平台包含内核、虚拟化模块，中间件，功能软件以及与之相配套的开发工具链，用于支撑应用软件的快速迭代开发。基础软件验证平台通过调试、分析、仿真、测试等手段验证设计和实现的一致性。

1.安全车控基础软件平台

安全车控基础软件开发平台主要面向车辆经典控制领域，如动力系统、底盘系统和车身系统等，该类基础软件开发平台对实时性和安全性的要求极高。

目前，主流的安全车控基础软件开发平台兼容 OSEK/ VDX 或 Classic AUTOSAR 标准，其功能安全等级需要达到 ASIL-D。

2.自动驾驶基础软件平台

自动驾驶基础软件开发平台主要面向智能驾驶领域，用于智能驾驶辅助，以及全自动驾驶功能的控制器上。目前智能驾驶控制器主要使用的底层操作系统有 QNX 以及 Linux。

（1）与安全车控基础软件开发平台相比，对智能驾驶基础软件开发平台的要求主要体现在： 强大的计算能力，以满足图像识别和决策计算的要求；

（2）强大的数据吞吐能力，以满足多传感器数据的实时接入和处理要求；

（3）高度的灵活性、扩展性、可编程性，以满足多种算法模型的需要；

（4）易用性，以满足 ADAS 和自动驾驶算法所需调试、调优、调测的需要。

当前异构分布硬件各单元所要求的功能安全等级有所不同，AI 单元需要达到 QM 至 ASIL-B，计算单元需要达到 QM 至 ASIL-D。

3.信息娱乐基础软件平台

车载信息娱乐基础软件开发平台主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多源信息交互的必要运行环境。

车载信息娱乐基础软件开发平台对于实时性、安全性、可靠性的要求处于中等水平，既可以使用 Android、Linux 等非实时操作系统，也可以使用 QNX、VxWorks 等实时操作系统。

为便于应用程序移植，当 前越来越多的车载信息娱乐基础软件开发平台采用 Android Automotive OS 或其他类 Linux 系统。

随着车辆由单纯的交通工具向智能移动终端转变，车载信息娱乐基础软件开发平台需要满足如下要求：

（1）支持多样化应用，满足支付、娱乐、导航、信息服务等多样化功能需求；

（2）支持多生态资源，将手机端庞大的信息娱乐服务生态资源，通过采用相同或类似的操作系统，快速移植到车辆智能终端，避免重复开发；

（3）安全，通过深度定制达到车辆信息安全和功能安全的标准。

4.面向信号的软件架构

随着汽车电子电气架构向中央计算-域控制器的方向演进，甚至向车云一体化的方向迈进，适用于汽车的软件平台也需要进行相应的进化。

在传统的观念中，座舱域即娱乐域，座舱软件架构即运行在座舱域控制器上，主要处理各种娱乐系统的信息，为汽车用户提供丰富多彩且方便可用的娱乐信息系统。

与之相对应的，是基于信号架构的座舱软件体系。

5.软件架构演进

面向信号的软件架构，匹配的是分布式ECU的电子电气架构。但随着EE架构的演进，自动驾驶域，车身控制域，智能座舱域逐步融合成统一的中央计算平台。

此时的智能座舱软件系统已经不仅仅承载娱乐域功能，还将融合车身控制HMI，车内外通信，ADAS信息显示等一系列的功能。

与之所匹配的软件架构，需要演进到面向服务的软件体系架构。座舱软件不是一个独立的域控制器软件体系，而是面向服务的整车软件架构中的一环。

参考一个以用户为中心的融合式智能服务场景，如下：

图片来源：汽车软件全景图(2022)

针对上述汽车软件的演进趋势，面向服务的基础软件架构逐渐成为业界共识。相比面向信号的软件架构，面向服务的软件架构主要增加了信息分发和基础服务框架等中间件内容。

其中一个正在进行的范例是ASF软件架构。

ASF是AUTOSEMO Service Framework的缩写，AUTOSEMO (中国汽车基础软件生态委员会)联盟携手行业内主流车企和零部件企业， 针对整车通用基础服务研制的整车服务框架规范。

通过该规范统一服务和接口，实现高效的整车控制器 设计、开发，让跨厂商集成更便捷、可靠。

图片来源：中国汽车基础软件发展白皮书3.0

ASF 是一组为功能服务开发、使用和集成而设计的通用化中间件服务集群，服务集群可以被所有的功能服务调用，用于对功能服务在整车平台的能力进行扩展，并实现整车各系统之间的协同，保证整车软件平台的整体性并进行统一管控。

ASF 主要可分为原子服务、SOA 增强型服务、系统级基础服务、整车级基础服务。软件架构设计师需基于各服务类型进行服务定义、设计，使 ASF 分层和功能定义更加清晰。在服务设计过程中遵循以下原则：

（1）SOA 增强型服务具有通用性：即可为所有的应用服务提供通用功能，应用服务基于服务自身需求可使用该类服务，如数据存储、服务信号转换、服务调试等诸如此类的通用化功能。

（2）系统级基础服务，具有一定范围的（如某操作系统或控制器之上）通用性，且具有抽象性：即对基础软件开发平台（如 AUTOSAR Adaptive/Classic、Android 等）提供的通用化功能进行抽象，并提供给应用服务使用，如健康管理服务、网络管理服务、时钟服务、电源管理服务等。

（3）整车级系统服务具有全局性：即该类服务的设计更多关注的是整车层面对车内所有系统的通用化功能进行协同和管控，该层服务是对系统基础服务在整车层面的抽象和管控，即通过该层服务可以配置和控制系统基础服务，如整车健康管理服务、整车网络管理服务、整车时钟服务、整车电源 管理服务等。

（4）动态服务具有动态配置性：即应用服务在运行过程中可对服务进行配置，并基于配置输入执行动态服务的功能。

（5）原子服务具有独立性：即其设计应与硬件配置和实现无关，与上层功能服务层和下层的硬件驱动层解耦，完全独立。

（6）原子服务具有原子性：即设计的服务不可再拆分，作为服务的最小单位和执行实体，为功能服务提供最基础的执行或采集等功能

SOA 增强型服务

SOA 增强服务是在国际共同讨论的基础平台进行服务框架扩展，封装通用化的基础功能。应用服务调用此类服务的接口更加方便完善其功能软件逻辑、便于系统集成和敏捷测试。

该类服务为一组服务集群，以 Lib 库的形式集成在应用服务中，并提供满足国际共同讨论的自适应 性标准的服务接口，使接口标准完整统一。

主要包含模块：服务调试、服务转换、服务权限、服务同步、 SOA For Android、日志管理、动态数据收集、诊断管理。

系统级基础服务

系统级基础服务描述车端各类域控及网关节点，基于通用基础软件提供的底层支持，进行相应的封 装和扩展，实现各类通用化服务功能和框架及在此基础上形成的面向上层应用的各类服务接口（SDK接口、 API 接口、IPC 接口、RPC 接口等）。

系统基础服务包括通用支撑类服务和公共框架类服务。通用支撑类服务包括服务治理（服务发布及发现）及服务容器、服务访问及限流降级、数据订阅及发布、集群管理、消息总线等。

公共框架类服务包 括升级管理服务、健康管理服务、网络配置服务、资源管理服务、时钟同步服务、安全管理服务、测试服 务、电源管理服务、日志服务、诊断服务、数据收集等。

整车级系统基础服务

整车级系统基础服务是将各控制器节点的能力，通过跨域、跨核组合成整车级别的业务功能，以对应用层提供整车级统一的调用。

整车级系统基础服务包含整车电源管理服务、整车健康管理服务、整车时钟 服务、整车诊断 Master、整车版本管理服务、整车数据采集服务、整车日志管理服务。

动态服务

动态服务工作流通常由车云一体的云端平台（ 比如：开发者平台）提供工具链支持，对接技术生态 及运营，从而在运行态具备灵活更新的能力。动态服务开发流程以逻辑组合建模为主，因此工具链需要 支持可视化 UML 建模，输出模型脚本，并与车端建立同步机制。

动态服务开发面对的角色，不再局限于传统的 OEM/ 供应商角色，而是拓展面向第三方开发者，甚 至是车主。

原子服务

原子服务是执行单一操作功能的服务，具有硬件功能上的不可拆分性。例如获取一个数值或者执行 一个I/O操作。

通过将域控制器的硬件功能，拆分为最小功能的原子服务，并统一定义原子服务的访问接口， 从而实现软硬件的完全隔离。

软硬件隔离后，车载硬件不再绑定特定的功能，应用软件得以自由使用车 载硬件，实现更加灵活多样化的功能。例如方向盘在正常行驶过程中，用于控制车辆的转向，当车辆处 于非驾驶模式时，又可以成为中控大屏游戏应用的控制手柄。

6.面向服务的智能座舱软件架构

根据上述的描述，我们可以抽象得出面向服务的座舱软件架构，如下：

红色部分主要是从SOA的角度，在座舱软件的中间件部分增加相关服务框架和信息分发机制。

一个较详细的分解可以参考汽车软件全景图文档。

图片来源：汽车软件全景图(2022)

SOA Framework目前已经是行业内各厂家正在主攻的方向，随着中央计算-区域控制架构的逐步实现，SOA 中间件将发挥出重要的作用。