1. 车载底层操作系统

随着硬件架构逐步明确，车载软件架构也随之逐渐形成。狭义角度的操作系统提供标准操作系统的接口和能力，保持传统操作系统的功能。广义角度的操作系统基于传统操作系统封装了更多车载软件应用层所需的业务相关的接口和能力，便于应用层的开发和迭代。这也就形成了车载软件中间件。

AUTOSAR基础软件，将常用车载软件的功能做了封装，例如：执行管理、状态管理、健康管理、通讯管理、网络管理等，车载应用层软件可以直接使用基础软件平台提供的功能实现所需的应用业务逻辑，统一的接口定义便于应用层的升级和硬件的替换，做到了软硬解耦，也为软件先行提供了机会。

针对目前E/E架构变革，新的多核异构芯片，以及跨核跨域的协同需求，让车载基础软件面临新的挑战。AUTOSEMO建立的ASF（AUTOSEMO Service Framework）工作组，目标是将多核异构芯片的跨核、多控制器跨域的功能协同进行统一，对应用层暴露统一的接口，封装更多应用开发所需的功能。

AUTOSEMO整体技术框架是面向整车的软件平台，基于AUTOSAR标准的基础软件为底座，以SOA面向服务的设计思想进行软件分层，通过标准化接口实现跨平台的灵活部署。其中ASF作为面向域控制器构建整车系统功能的底座，车云一体是支撑上层整车智能化应用的核心平台。

AUTOSEMO ASF（2022版）框架

2.车载SOA软件架构

AUTOSAR-AP平台采用SOA方法论，主要涉及一种自适应软件产品的开发，是一套包括软件分析、设计、开发、部署在内的复杂工作流程。主要包括两个方面：工作流定义与成果物定义。具体描述如下：

（1）流程定义

AP平台的方法论作为CP平台的扩展，其引入了新的概念，AP平台软件的实例是在进程的上下文中执行。AP平台引入了“机器”（Machine）的概念，“机器”是虚拟化的ECU，一个可以部署软件的实体。它可以是真实存在的处理器，也可以是一个虚拟机，AP软件则运行在某一特定的“机器”上。

AP平台整体开发的主要任务及工作产品

（2）开发服务接口（Service Interface）

AP平台是一个面向服务的软件架构（SOA），基于AP平台的软件开发，首先需要进行服务接口的设计。服务接口可以由事件（Events）、方法（Methods）和字段（Fields）组成，是生成软件组件头文件的基础。

（3）开发通信结构（Communication Structure）

OEM在设计阶段需要指定预期“机器”（Machine）的通信结构以及相应的配置参数，包括机器的所有网络端点和服务发现地址端口等。这一步将产生一个可交付的“机器设计”（Machine Design），一个特定的“机器”模型将引用一个特定的“机器设计”模型。

（4）开发自适应应用软件（Adaptive Application Software）

自适应应用软件开发从软件组件（SW component）的设计开始，软件组件是通过其端口（Port）定义的，每个端口实现一个服务接口。基于服务接口描述，生成包含实现软件组件的头文件。开发人员在此基础上实现软件组件的核心功能。

（5）开发自适应平台软件（Adaptive Platform Software）

与应用级软件类似，平台级软件可以由基于标准化服务接口的软件组件组成，也可以直接实现而不需要软件组件模型。

（6）定义和配置机器

包括了功能组状态和每个状态超时的定义，进程到特定机器的映射，以及平台服务（例如NM、DoIP）和基础模块（例如日志）配置等。此过程会产生一个独立于服务实例或应用程序的机器清单（Machine Manifest）

（7）集成软件

软件的实现和编译完成后，需要集成到一个可执行文件（Executable）中。通过进程来定义特定机器上可执行文件的实例化，每一个进程会产生一个执行清单（Execution Manifest），其中包括了进程及其启动配置。

（8）定义和配置服务实例（Service Instance）

首先对服务接口进行部署，然后定义服务接口的实例，并决定是否提供或使用该服务实例。其次要建立服务实例到机器的映射，以及服务实例到端口的映射。此过程会产生进程所需的所有服务实例清单（Service Instance Manifest）

（9）生成软件包（Software Package）

将可执行文件及所需清单整合为软件包上传到机器上，而无需重新刷写。OEM可以将软件包存储在后端服务器中进行统一管理。

（10）成果物定义

由于AUTOSAR的工作流包含了整个汽车软件开发流程，涉及多个开发角色，因此需要各个开发角色之间有信息交互，为了保证信息不出现二义性，需要对各个环节的工作成果物规则进行定义。同时为了信息的保存、传输、交互的需求，需要定义这些成果物的载体，ARXML就是定义了不同流程成果物的载体，使用不同的标签来表示不同的信息及流程，这些标签的定义就是AUTOSAR的数据元模型，如下图。

元模型层次关系图

· M0: 使用M1级规则生成的可运行软件实体，例如车门控制的可自行软件组件

· M1：使用M2级规则定义软件组件，例如车门控制的软件组件，软件组件的表现形式可以是ARXML，C/C++语言或各类文档。一般情况下会使用工具链以ARXML的形式定义软件组件的框架，然后导入下游工具链生成目标语言。或直接生成目标语言框架，然后手写代码的形式完成整体的软件组件；

· M2：使用M3级规则定义使用AUTOSAR开发的元素、语法及规则，例如软件组件，port口，机器，清单等。该级别的元素与具体的功能无关，类似于各类开发语言的语法；

· M3：用于定义M2的元模型

· 车载 SOA 软件发展趋势

车内所有可以被调用的功能都是服务，不同功能提供不同的调用接口，接口分类如下：

▸API接口：各类函数的调用接口，提供在系统内功能实现函数被调用的能力，应用程序可调用相关的API接口，提供和使用功能服务；

▸文件方式：以配置文件或设备文件等方式，提供系统内调用能力，文件可通过配置自动生成，其中包含有效配置信息，在运行环境中能被特定的程序读取识别，实现特定的服务；

▸IPC接口：各类IPC机制提供系统内进程间的调用能力，包括socket、共享内存等进程间通信方式，及IPCF等特定的跨核通信方式；

▸系统原生服务：操作系统及基础类库提供的可操作能力，包括对系统CPU和内存使用情况的监测、应用程序的监控、系统资源的划分等，以及C++、boost等基础类库的调用。

▸协议栈接口：通过网络协议栈的方式提供跨平台的调用能力，包括SOMEIP，DDS，MQTT，HTTP等网络协议的调度服务，接口封装、及协议转换等。

服务类型

根据服务提供功能的特点，可以分为基础型服务与功能型服务，其中：

▸基础型服务：提供与业务无关的通用系统服务能力，包括操作系统、基础软件、通用中间件提供的功能。

▸功能型服务：提供具体业务功能相关的服务，包括与域控相关的专用中间件、应用层提供的功能

服务实现方式

根据服务的实现方式，可以分为静态服务与动态服务

▸静态服务：开发阶段定义服务提供的功能、运行机制或生命周期状态切换条件，一般为执行特定单一化操作或实现相对固定的业务功能，以及和电源管理，车辆状态管理等相关的状态同步。

▸动态服务：在运行阶段，根据外界（云端或其他智能终端）的输入，依赖现有静态服务提供的接口，动态定义新的服务。该方式非传统的程序更新手段，而是通过对静态服务进行编排，车端服务引擎可动态读取编排脚本，进而定义出新的功能场景，实现服务的个性化。

服务框架（ASF）

该部分是对通用基础软件的扩充，首先，需要在控制器内做到跨核协同，在基于不同种类的操作系统及基础软件平台之上提供系统级服务调用及整车级功能设计视图；其次，对AUTOSAR的服务管理框架进行扩展，向应用层提供更多基于服务开发需要的功能，最后，提供基于引擎的动态服务配置方法，基于预设的静态服务，通过云端对静态服务进行编排，实现更佳丰富的业务功能。

▸原子服务

不可拆分的服务，一般为执行单一操作的功能，例如获取一个物理数值或执行一个I/O的操作，不同功能节点可以提供针对业务的原子服务。

▸SOA+

基于AUTOSAR的服务框架扩展，向应用层提供更多基于服务开发需要的功能，其中包括服务转换，服务调试，服务同步，服务权限管理和基于android的SOA协议栈。

▸系统基础服务

系统可以提供的基础服务，体现该系统可以提供的能力。需要依赖通用基础软件提供的功能，可以通过API或服务的形式提供给上层，针对不同异构系统分别提供软件包。

▸整车级系统基础服务

整车角度需要多个控制器协同实现的功能。

▸动态服务

基于原子服务及系统服务提供的功能进行组合，实现服务的级联。包括

（1）动态服务配置接口：提供给调用者实现动态服务的可配置接口；

（2）动态服务引擎：根据配置接口的输入，执行动态服务的核心功能。

· 服务

基础型服务定义系统可以提供的功能，通用性较强，由操作系统、通用基础软件、通用中间件共同完成。

域控制器架构

以域控制为主的集成式EE架构下，每种功能节点提供的功能不同。

▸主域控制器：除了需要适配不同异构硬件及提供高算力高带宽之外，还需要与云端交互，控制域下面的其他节点。因此需要的基础型服务最全面。

▸区域控制器：主要终端节点的（网络，电源，IO）管理及网络转换，通用性较强

▸终端节点控制器：主要用于实现传感器控制或数据采集功能，需要的中间件功能不多。

定义具体功能节点相关的服务，对外体现该节点的可操作能力，通用性不如基础型服务。但随着域控制器EE架构的逐步标准化，该部分的服务也会随着标准化，之后划分到基础型服务中。

节点服务图

服务定义方式

静态服务一般需要借助开发工具链定义，功能设计成服务后，在配置工具中配置服务接口方式、服务接口数据类型、服务接口部署方式、服务部署实例化以及提供或使用服务的相关内容，包括Process、Executable、Swc和port等。配置成功后，生成标准化的ARXML文件，经过配置校验后生成框架代码，应用层完成业务逻辑代码编写后，编译生成可执行文件，部署到车端运行环境中，以服务的方式提供业务功能。

动态服务一般均为场景式服务，通过云端对动态服务进行定义与规划，并对已有静态服务进行编排和规划，最终生成服务编排脚本下载到车端，车端服务引擎可动态解析服务编排脚本，进而对静态服务进行调度，实现场景式服务的动态添加。

3.虚拟机监视层（Hypervisor)

Hypervisor是一种运行在基础硬件和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件。也可叫做VMM（ Virtual Machine Monitor ），即虚拟机监视器。Hypervisors是一种在虚拟环境中的“元”操作系统。他们可以访问所有的物理设备和虚拟机。当服务器启动并执行Hypervisor时，它会加载所有虚拟机客户端的操作系统同时会分配给每一台虚拟机适量的硬件资源如内存，CPU，网络和磁盘。

CAIC·MOS通过Hypervisor 主要实现两个基本功能：首先是识别、捕获和响应虚拟机所发出的 CPU 特权指令或保护指令；其次，它负责处理虚拟机队列和调度，并将物理硬件的处理结果返回给相应的虚拟机。即Hypervisor负责管理所有的资源和虚拟环境，Hypervisor可以看作一个为虚拟化而生的完整操作系统，掌控有所有资源（CPU、内存和 I/O 设备），承担管理资源的重任，还需向上提供虚拟机VM 用于运行 Guest OS，即虚拟环境的创建和管理。

中汽创智虚拟机管理（CAIC·MOS）

集成多种虚拟化技术和安全隔离方式，可以满足不同车用操作系统对实时性和安全性的要求，让具备开源灵活性的系统和遵循行业标准的系统并行运行且互不干涉。通过减少管理、同步、切换、路由等中间环节的开销，有效提高虚拟化的实时性。采用了无内核轻应用以及设备空间隔离等技术大大提高了系统的安全性。

同时，CAIC·MOS提供超轻量无内核虚拟化驱动和服务组件。该技术是借助虚拟化的部分OS属性，穿透EL1 system mode，由Hypervisor直接提供system call 模拟层，可省去了一层OS层，以提升系统的性能和空间优势。

CAIC·MOS具有以下特点：

1、Type 1型Hypervisor， 支持ARM64架构,支持快速启动

2、系统隔离（CPU, 设备IO, 内存，SMMU）

3、设计上满足功能安全ASIL D

4、向上可支撑多种Guest OS: Linux, Andriod, CAIC OS等

5、向下可支持多种芯片平台：TDA4系列, 芯驰X9H系列等

6、高效虚拟通信（虚拟网络，快速消息，内存零拷贝等）