AUTOSAR AP

2.2.1  技术形态

新四化（电动化，网联化，智能化，共享化）的变革驱使汽车软件系统变得更加灵活。汽车软件既要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及与非车载系统之间的交互。

今天的汽车 E/E 架构可划分为信息娱乐、底盘和车身控制等不同域，信息娱乐系统通常使用 Linux 或商业化的通用操作系统，车身控制则使用标准的 AUTOSAR CP。随着未来新技术及深度嵌入式系统对计算能力需求的不断增长，急需第三种控制器—— 域控制器，用于集成特定领域的功能特性（如车辆动力域、车身域等 )，形成域集中或跨域集中式电子电气架构。

在未来，随着汽车电子及软件功能的大幅增长，E/E 架构最终可能向基于中央计算平台的整车集中式电子电气架构，以及车云协同控制发展。在这种趋势下，需要高度灵活、高性能且支持 HPC、动态通信等特性的新软件架构平台—— Adaptive Platform AUTOSAR 平台（下文简称 AUTOSAR AP）。

1.  软件分层架构

典型的域控软件架构如图 2.2-1 所示，整体可被分为四层，即操作系统层、基础平台层、原子服务层、应用组合服务层。

AUTOSAR AP 在基础平台层，这一层包含了 AUTOSAR AP、AUTOSAR CP、专用基础功能等，主要为整车提供基础运行环境。

原子服务层是实现数据融合和控制逻辑的功能模块，作为服务的最小单位与单一执行实体，通过   API 为应用提供可按需编排的基础服务，实现一次开发多次复用，最大化提升开发效率。该层的设计目标是原子服务与平台解耦，提升软件复用性。

应用层基于原子服务实现对整车服务、应用、体验等进行定义和组合增强，构建差异化竞争力的业务应用，体现千车千面。

图 2.2-1 域控软件架构图

图2.2-2 AUTOSAR AP在软件架构中的位置

AUTOSAR AP 在域控软件架构中位于中间件的位置，通过服务和API 为上层服务提供功能，如图2.2-2 所示。

在 Non-AUTOSAR 环境中，系统已经实现了部分 AUTOSAR AP 标准组件，只需要实现剩余部分组件即可满足 AUTOSAR AP 的标准。比如在 Android Automotive OS 中，软件框架提供了进程管理、执行管理、Log、加密、生命周期管理等功能，基础软件供应商实现通信管理、诊断、升级、网络管理等功能， 即可满足 AUTOSAR AP 的标准。

2.  工具链

基于自适应平台的应用程序开发一般要经历三个阶段，分别是设计建模阶段、软件开发阶段、集成部署阶段，为了更好地支撑这三个阶段的活动，AP 工具链具备以下能力：

·  设计建模阶段使用建模工具，用于生成 ARXML，完成 Adaptive Application、Service Instance、Executable、Machine 等设计开发，配置 SWC（Software Component）相关配置项，完成 SWC 端口及框架设计 , 最终导出 AP 平台的 ARXML 文件。产品工具应具备支持导入导出、解析、编辑ARXML 文件的能力。

·  软件开发阶段：使用 AP 产品生成工具，用于实现组件 API 代码及 Manifest 配置文件的生成。输入是标准的 ARXML 文件，生成源代码和 Manifest 配置文件，另外需要包含应用层的代码编辑器和代码库管理，实现源码编辑，编译链文件编写，代码库同步等功能。

·  集成部署阶段：使用集成编译调试以及部署工具，包含编译工具、可视化调试工具、部署工具、资源监控等工具，支持编译、调试、部署等功能。

3.  开发方法论

为了支持 AP 平台下应用程序独立、敏捷、分布式的开发，需要在开发方法论上有一套标准化的方法。AUTOSAR AP 开发方法论涉及工作产品的标准化，用于描述工作产品（如服务、应用程序、机器及其配置）、工作产品应如何交互、以实现自适应平台产品开发过程中不同角色之间所需的信息交换。

图 2.2-3 简要展示了 AP 平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的软件集成入车辆中。

(1) 架构设计阶段

① 服务接口设计（Define Services）：主要是定义服务接口及数据类型，包括定义服务所包含的method、event、field、trigger 等通信元素以及数据类型详细说明等；

② 机器配置设计（Configure Machine）：定义和配置机器的网络通信属性，包含网络连接配置，服务发现配置等信息；

(2) 软件开发阶段

③ 定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集；

④ 定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射；

⑤ 服务实例接口框架源码生成；软件集群源码开发及测试等；

(3) 集成与部署阶段

⑥ 软件集群集成 (Integrate Software) ：配置可执行实例和进程的映射、定义和配置应用程序配置清单、定义和配置服务实例部署信息；

⑦ ECU 集成 (ECU(Machine) Integrate)，定义应用程序执行清单 (Execution Manifest)、定义平台程序的配置清单、诊断和进程之间的映射配置；

图2.2-3 AUTOSAR AP开发方法论

2.2.2  技术发展趋势

1.  架构发展趋势

(1) Adaptive AUTOSAR 的历史

Adaptive AUTOSAR 于 2017 年应运而生，主要为了提供高算力、高网络带宽下的基础软件开发平台标准。目前最新版本为 R21-11。

(2) Adaptive AUTOSAR 的发展趋势

① 技术趋势

在汽车行业， 智能网联、自动驾驶、V2X、OTA 等功能逐渐成为标配，Adaptive AUTOSAR 面向POSIX    标准的操作系统，可以更好支持这些功能。在最新的标准中为了更好的支持开发，在可用性及稳定性上做了如下提升：

a. 可用性：提升模块特性的合理性及便利性。支持更多的 SOA 通讯协议、通信失效模式的检测、灵活支持日志内容定义等。同时，针对域控制器的异构平台，新版本在 AP 与 CP 的共用特性及方法论上进行统一，定义了自动驾驶的传感器接口、整车级健康管理的架构与接口、针对整车 OTA 升级的流程等域控制器架构的使用功能等。

b. 稳定性：增加针对系统稳定的特性。如在 EM 细节中增加了配置进程错误码、功能组增加 unde- fined 状态、增加对进程意外终止的处理，PHM 中增加确定性执行的监控，UCM 中增加容错机制等。

同时在这些功能场景下，信息安全与功能安全成为不可或缺的关键机制。Adaptive AUTOSAR 针对这两项安全需求，定义了完善的特性：

a. 面向功能安全：新增了系统健康监控，主要用于系统协调健康状况 / 错误。主要包含以下内容：

• SHM Client 交流平台健康状况；

• SHM Master 确定健康指标；

• 根据健康指标进行的机器恢复（例如降级）；

• 增加了确定性同步的内容，描述了同步行为和周期性激活的要求，包括时间同步和数据同步。

  
  

b. 面向信息安全：增加了入侵检测系统管理，由标准化的接口来报告安全事件。通过标准化的过滤机制来传输合格的安全事件。

• 增加了 Crypto API 的描述；

• 软件和硬件解耦；

• 支持分离式非耦合开发；

• 应用程序独立于加密解决方案。

  
  

② 基础软件技术路线

随着各种域控制器方案陆续问世，各细分赛道由分散到集中，由独立到整合。目前整车域控制器， 例如智驾域控，中央域控，智能座舱域控等均需得到高性能 MPU 芯片的支撑，因此 POSIX 标准系统的搭载显得尤为必要。基于 POSIX 系统之上的 AUTOSAR Adaptive 平台及相关工具链，为应用开发过程中的效率带来显著提高，而座舱域控一般在 Linux 基础之上搭载安卓系统，在程序启动、状态切换、存储等方面有自己独立的生态，而诸如 SOA 通信、整车诊断、健康管理的方面需要参考 AUTOSAR AP 平台标准给予补齐和增强，工具链未来需要从整车视角实施统一化配置。

③ 新的分工趋势

受域控制器行业的蓬勃发展以及各项政策利好，越来越多的参与者以各种新的身份加入进来，整体 的行业角色将不再是 E/E 时代的 OEM、Tier1 及 Tier2 三种。随着产业链结构的变化，位于下游负责整车生产和组装的主机厂（即行业所说的 OEM），将不再通过系统与设备集成来获取价值增量，而会转向基于用户需求和自身产品定位，建立有效的梳理筛选机制，向上游 Tier1 及 Tier2 提出更多定制化的需求。

2.  工具链发展方向

工具链（tool chain）是在一套流程里面用到的所有工具和相关库组成的集合，上一个工具的输出或环境状态成为下一个工具的输入或启动环境。因此，工具链的效率决定了整个系统的开发效率。所以随着行业的发展成熟，工具链的发展将由现在分散的多工具相互切换配合形态，逐步升级到成熟开放的中间服务体系，来匹配整个产业的发展态势，在平衡各自的专业分工的前提下避免产生信息数据孤岛。

现行的工具链标准基本是在 AUTOSAR AP 规范所约定的框架内按照给定的方法论实现功能，各家比拼的是对 AP 服务模块的实现及理解。在第一阶段的服务实施提供后，要比拼的就是在整个产业上下游的环节中的规范度、可移植性及整体的效率提升。

从集成角度，基于 AP 的开发工具链一般是基于 Linux 系统进行开发、编译和调试，在用户桌面端往往出现多种开发工具同时使用的问题，因此亟需一套集成开发环境来简化用户桌面，为基于 AP 的应用开发提供便捷性。

2.2.3  关键技术解读

1.  面向服务的架构（SOA）

当前整车电子电气架构，功能不集中，分散到不同 ECU，使得功能和信号交互异常复杂，代码和逻辑冗余相当严重，而互联网开发思想不断涌入汽车行业，汽车电子电气开发也必须尽快适应变革。

面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务 之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种这类系统中的服务可以以一种统一和通用的方式进行交互。通过 引入 SOA 架构，不但可以使应用软件与硬件及应用软件与应用软件之间松耦合，还可以使车端软件、通信、信息安全能和云端环境产生很好的协同，实现一整套车云生态环境，因此车端采用基于服务的通信 SOA 是有效的落地方案。

2.  软硬分离

传统汽车控制器的开发模式是等硬件确定后，再进行软件的设计、开发、测试，软件的开发依赖于硬件，无法先行或同步开发，导致软硬件两个团队人员只能顺序完成工作，浪费时间。并且一旦硬件发生改变， 软件则需要大量的修改适配，重复工作量巨大。在新型整车集中式 E/E 架构下，功能服务化，接口统一化， 增加了中间件层，软硬分离成为可能。

3.  虚拟化

当前高算力芯片层出不穷，通过虚拟化技术，将芯片上所跑的各类业务分类进行隔离已经是目前很多车企的选择。同时，在软硬分离的背景下，在 x86 架构 PC 机上或云端通过虚拟化技术运行虚拟控制器进行服务设计的验证也是目前的主流软件先行方案。

2.2.4  典型应用案例

1.  基于 AP 的基础软件产品和解析

(1) 日志与调试

日志作为行为或状态详细描述的载体，提供可用于分析系统的活动和诊断问题的跟踪记录。在安全事件分析、事件回溯和取证过程中起着相当重要的作用。

在 AP AUTOSAR 中，Log and Trace 模块负责管理和记录 AP 平台的日志，既可以应用于开发过程， 也可以适用于量产过程。在架构上，Log and Trace 模块会与 AP 的时间同步及通信管理等模块交互。基于 AP AUTOSAR 标准定义的 LT 协议，Log and Trace 模块可以让 AP 应用程序将信息记录到通信总线、控制台或文件系统上。同时 DLT 协议也提供了包括日志等级、日志 ID 等字段内容，日志客户端可以使用此信息来关联、排序或过滤接收到的日志帧，便于日志的解析查看以及日志相关功能的扩展。

平台典型的日志系统架构图如图 2.2-4 所示：

图2.2-4 Log And Trace案例

其中，App 通过使用 DLT 接口将相应的操作步骤、状态监控、故障信息等内容发送至 Daemon；

Daemon 表示 DLT 守护进程，它接收并处理来自 AP 应用程序的日志信息，并根据配置对日志进行终端显示、文件存储、网络传输等操作；

Dlt-Viewer 表示通过网络传输接收 Daemon 日志信息的客户端，对日志信息进行 UI 展示，方便用户进行日志的查看和分析。

日志记录分析

上文介绍了从日志产生到日志数据流转的整个过程，基于已有的日志信息，Dlt-Viewer 可以提取出我们所关注的数据，如图 2.2-5 所示。

Dlt-Viewer 提供相当多 DLT 日志处理功能，除了日志显示、日志导入 / 导出等功能外，还提供了强大的日志过滤、标记等功能。过滤器可以是某一字段，甚至是正则表达式。它提供了插件的开发接口，极大地提升了功能扩展的能力。

图2.2-5 日志记录分析

(3) 系统启动监控

通过解析各功能模块产生的 DLT 日志，可以分析出整个系统上电启动过程，用户可以直观地观测各功能模块的启动过程，并根据观测结果调整各功能的启动策略，达到功能模块稳定、快速启动的目的。

2.  基于 AP 的应用场景介绍

本节主要介绍基于 AP 的智能域控制器（后续简称 IDC）OTA 升级场景及其实现方案。IDC 的 OTA 功能可以进行自身应用软件及系统软件、关联器件固件的升级，并在数据管理、软件升级、可追溯性、安全验证方面满足 AP 的相关要求。

在OTA 的功能实现过程中，IDC 与外界的数据交互如图2.2-6 所示。云端OTA 云服务器向车端HUT（终端信息展现单元 Head Unit & Telematics）推送升级任务，用户确认升级后，HUT 会通过网关向 IDC 及其他 ECU 以 UDS 的形式发送升级指令及升级数据，IDC 接收升级指令与数据后，在确保安全的情况下完成软件升级并向 HUT 反馈安装进度及安装结果。

图2.2-6 IDC与外界数据交互图

(1) 数据传输与管理

① IDC 内部分为 OTA 进程和 UDS Server 进程，UDS Server 进程与 HUT 端交互，负责处理、转发指令和接收软件包，OTA 进程处理软件包进行升级。

② OTA 使用专用的磁盘分区保证有足够的资源来存储软件包及相关数据，从而保证数据的安全性。

③ IDC 会进行完整性校验以保证软件包的完整性。

④ OTA 结束后，IDC 会删除临时数据，最大限度节省空间。

(2) 软件升级

① OTA 采用双分区机制，通过活跃分区去升级备份分区，升级成功后重启备份分区，完成备份分区和活跃分区的互相切换，轻松实现 IDC 上的应用软件、中间件、操作系统、配置数据的安装、更新、删除。

② OTA 采用双分区机制，通过切换启动分区，可以实现 IDC 上所有软件及数据的快速回滚功能。

③ OTA 支持周边器件的升级，如 MCU、相机等。

④ OTA 内部维护状态机，状态变化实时落盘，可以支持在异常中断后恢复升级。

(3) 可追溯性

① OTA 提供获取当前软件版本号、安装进度、安装结果的接口。

② OTA 会记录升级过程中的日志，供 HUT 获取。

(4) 安全性

① OTA 在软件升级前会使用强加密算法校验证书链与软件包签名，保证软件包的真实性及完整性。

② OTA 在软件升级前会检查当前车速、IDC 的温度、供电情况，保证在安全的情况下进行 IDC 软件升级。

③ OTA 时会激活 IDC 心跳监控机制及分区损坏回滚机制，当切换到备份分区启动失败后，IDC 不会给 MCU 发送心跳报文，MCU 会认为 IDC 在 OTA 后变砖，会给 IDC 断电重启，切回原分区启动，保证车机可用。

注：本章有关AUTOSAR 的内容是AUTOSEMO 会员单位的经验解读，仅供行业参考。