本文主要内容：1、背景及趋势;2、AUTOSAR AP与CP;3、AP在域控中的应用;4、基于AP的应用开发;5、AP工具链;6、基于AP的产品和解析;7、基于AP的OTA。
1、背景及趋势
随着汽车电动化、智能化、网联化发展进程的加深，整车EEA正由传统分布式朝着域/中央集成发展，这一技术的变革致使传统的整车电子电气架构朝着智能化的新电子电气架构演变，在面向服务架构(SOA)下，深度嵌入式系统对计算能力的需求大大提高。同时基于以太网等更高带宽、更高算力的芯片平台被大规模应用，整车的功能开始多样化了，软件在汽车上的应用、更新迭代变得愈发复杂且频繁，这进一步推动了整车对于汽车软件的安全性、可持续更新性的要求。
图1 EEA平台发展趋势
为了应对日益变化的汽车功能，为此需有一款由全新架构支持的软件组件进行动态部署，并与非车载系统进行交互，以此来确保整车应用的灵活性，同时又能反映新的功能以及相关法规的要求。在这种趋势下，高度灵活、高性能且支持HPC、动态通信等特性的面向服务(SOA)架构的第二个软件标准平台Adaptive Platform AUTOSAR(AUTOSAR AP)基础软件平台于2017年诞生了。
在如今网联、智驾等先进功能成为整车标配的趋势之下，更高阶的自动驾驶、智能座舱等功能将进一步得到发展，为了应对技术革新，经过多年的发展与完善，AUTOSAR AP通过面向POSIX标准的操作系统以提供更好的技术支持，同时基于POSIX的AUTOSAR AP平台及相关工具链，可大大提升应用开发的效率。
2、AUTOSAR AP与CP
这里诸君需要注意一下，AP并非原有CP的升级版，而是运用了SOA架构的设计思想，是面对汽车更复杂功能需求而推出的新平台。相较之下，这两者具备如下差异点：
1)AP可适配64位及以上的高性能芯片，而CP只能适配32位及以下微控制器;
2)CP中的RTE仅支持静态通信，在程序发布时便已确定通信源和目标，并不支持通信的动态重新配置，AP支持服务发现、数据的动态发布/订阅机制;
3)CP的通信协议主要是“面向信号”的LIN/CAN架构，而AP中的通信模块ara::com为Application间的通信提供接口，并且自身包含的SOME/IP通信协议属于“面向服务”架构。
表1 AP与CP特性对比
项目AUTOSAR CPAUTOSAR AP
语言CC++
架构面向功能(FOA)面向服务(SOA)
通信方式基于信号基于服务
通信网络LIN/CAN等以太网
通信协议CAN/LINSOME/IP
操作系统OSEK标准POSIX可移植标准
实时性硬实时软实时
运行方式固化在ROM中静态运行加载在RAM中运行
3、AP在域控中的应用
在典型的域控软件架构中，软件整体可被分为四层：操作系统、基础平台、原子服务(应用)、应用组合服务。AUTOSAR AP处于基础平台层，该层还包含AUTOSAR CP、专用基础功能等不同模块软件，这些软件为整车提供基础的运行环境。
图2 典型域控软件架构
从上图的架构中我们可以看到AUTOSAR AP位于中间件的位置，它是通过服务和API为上层服务提供相关功能的，如下图所示：
图3 AUTOSAR AP在SOA架构中的位置
注：在上图的Non-AUTOSAR 环境中，系统已经实现了部分AUTOSAR AP标准组件，若有需要，只需再实现剩余部分组件即可满足AUTOSAR AP标准。
4、基于AP的应用开发
基于AP平台的应用程序开发大体需要经历：设计建模、软件开发、集成部署三个阶段，同时每个阶段又包含有不同的步骤，如下：
阶段一：架构设计。该阶段主要包含两个步骤：
步骤1：服务接口设计(Define Services)：主要是定义服务接口及数据类型，包括定义服务所包含的method、event、field、trigger 等通信元素以及数据类型详细说明等;
步骤2：配置设计(Configure Machine)：定义和配置机器的网络通信属性，包含网络连接、服务发现配置等信息。
阶段二：软件开发阶段。该阶段包含三个步骤：
步骤3：定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集;
步骤4：定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射;
步骤5：服务实例接口框架源码生成、软件集群源码开发及测试等。
阶段三：集成与部署。该阶段包含两个步骤：
步骤6：软件集群集成(Integrate Software)：配置可执行实例和进程的映射、定义和配置应用程序配置清单、定义和配置服务实例部署信息;
步骤7：ECU 集成(Machine Integrate)，定义应用程序执行清单(Execution Manifest)、定义平台程序的配置清单、诊断和进程之间的映射配置。
图4 基于 AP的应用开发流程
AUTOSAR AP标准化开发流程，是用于描述工作产品(如服务、应用程序、机器及其配置)、工作产品的交互等信息，以此来实现产品开发过程中不同角色之间所需的信息交换。
5、AP工具链
当前基于AP的开发工具链一般是基于Linux系统进行开发、编译和调试的，在用户端我们常能看到多种工具同时使用的情况，多工具的应用使得开发环境变得复杂且繁琐。为了简化用户的开发工作，提升便捷性，集成开发环境成为了未来发展的趋势。
当前状态下，结合不同开发阶段， AP工具链具备如下功能要求：
1)设计建模阶段：使用建模工具用于生成ARXML，完成Adaptive Application、Service Instance、Executable、Machine 等设计开发，配置SWC相关配置项，完成SWC端口及框架设计，最终导出AP平台的ARXML文件。产品工具应具备支持导入导出、解析、编辑ARXML 文件的能力。
2)软件开发阶段：使用工具用于实现组件API代码及Manifest配置文件的生成。输入是标准的ARXML文件，并生成源代码和Manifest配置文件，同时还需要包含应用层的代码编辑器和代码库管理，以实现源码编辑、编译链文件编写、代码库同步等功能。
3)集成部署阶段：使用集成编译调试以及部署工具，包含编译工具、可视化调试工具、部署工具、资源监控等工具，支持编译、调试、部署等功能。
工具链的应用是为了更好地支撑三个阶段的活动，以提高工作的效率及质量。
6、基于AP的产品和解析
(1)日志与调试
在AUTOSAR AP中，Log and Trace模块负责管理和记录AP平台的日志，既可以应用于开发过程也可以适用于量产过程。在架构上Log and Trace模块会与AP的时间同步及通信管理等模块交互。基于AP标准定义的LT协议，Log and Trace模块可以让AP 应用程序将信息记录到通信总线、控制台或文件系统上。同时DLT协议也提供了包括日志等级、日志ID等字段内容，日志客户端可以使用此信息来关联、排序或过滤接收到的日志帧，便于日志的解析查看以及日志相关功能的扩展。
图5 Log And Trace
上图示例中各模块任务如下：
1)App通过使用DLT接口将相应的操作步骤、状态监控、故障信息等内容发送至Daemon;
2)Daemon表示DLT守护进程，它接收并处理来自AP应用程序的日志信息，并根据配置对日志进行终端显示、文件存储、网络传输等操作;
3)Dlt-Viewer表示通过网络传输接收Daemon日志信息的客户端，对日志信息进行UI 展示，方便用户进行日志的查看和分析。
(2)日志记录分析
基于已有的日志信息，Dlt-Viewer可以提取出用户所关注的数据，如下图：
图6 日志数据
Dlt-Viewer提供相当多DLT日志处理功能，除了日志显示、日志导入/导出等功能外，还提供了强大的日志过滤、标记等功能。过滤器可以是某一字段，甚至是正则表达式。它提供了插件的开发接口，极大地提升了功能扩展的能力。
(3)系统启动监控
通过解析各功能模块产生的DLT日志，可以分析出整个系统上电启动过程，用户可以直观地观测各功能模块的启动过程，并根据观测结果调整各功能的启动策略，达到功能模块稳定、快速启动的目的。
7、基于AP的OTA
当前在整车的OTA过程中，云端服务器向车端推送相关升级任务，在得到用户确认后，HUT(终端信息展现单元Head Unit & Telematics)会通过网关向ECUs以UDS的形式发送升级指令及升级数据，ECU接收升级指令及数据后，在确保安全的情况下完成软件升级并向HUT反馈安装进度及安装结果，其流程如下图：
图7 OTA流程
在整个升级过程中系统会经历：数据传输与管理、软件升级、可追溯性验证以及安全性验证这些环节。
1)数据传输与管理
ECU内部分为OTA进程和UDS Server进程，UDS Server进程与HUT端交互，负责处理、转发指令和接收软件包，OTA进程处理软件包进行升级;
OTA使用专用的磁盘分区保证有足够的资源来存储软件包及相关数据，从而保证数据的安全性;
ECU会进行完整性校验以保证软件包的完整性;
OTA结束后，ECU会删除临时数据，最大限度节省空间。
2)软件升级
采用双分区机制，通过活跃分区去升级备份分区，升级成功后重启备份分区，完成备份分区和活跃分区的互相切换;
采用双分区机制，通过切换启动分区，可以实现ECU上所有软件及数据的快速回滚功能;
支持周边器件的升级;
内部维护状态机，状态变化实时落盘，可以支持在异常中断后恢复升级。
3)可追溯性
OTA提供获取当前软件版本号、安装进度、安装结果的接口;
OTA会记录升级过程中的日志，供HUT获取。
4)安全性
在升级前会使用强加密算法校验证书链与软件包签名，保证软件包的真实性及完整性;
在升级前会检查当前车速、温度、供电等情况，保证在安全的情况下进行软件升级;
OTA时会激活ECU心跳监控机制及分区损坏回滚机制，当切换到备份分区启动失败后，ECU不会给MCU发送心跳报文，MCU会认为ECU在OTA后变砖，会给ECU断电重启，切回原分区启动，保证车机可用。