基于Adaptive AUTOSAR平台的OTA解决方案

随着软件定义汽车时代的来临，AUTOSAR技术正不断发展进步以适用汽车智能化，网联化等普遍需求，特别是Adaptive AUTOSAR技术的产生更是让这些需求落地成为了可能，再加上汽车OTA升级需求对于各主机厂而言日趋迫切，因此如果能够基于Adaptive AUTOSAR平台来实现一套OTA解决方案将变的很有指导性意义。

前不久，由AUTOSAR 中国用户组成员单位牵头便共同开发了一套车用计算机网络 OTA 演示系统，使用了 AUTOSAR 的开发方 法和软件架构，应用了自适应平台（Adaptive Platform, AP）和经典平台（Classic Platform, CP）的基础软件。

通过联合开发来进一步了解了AUTOSAR软件开发的标准流程，同时也为OTA升级系统的设计提供了诸多的指导性方法，本文将摘取原文中精彩内容简要描述下各演示系统的设计思路和实现过程。

整个系统由系统总体设计，OTA平台，智能天线，车用防火墙，座舱域控制器，ADAS域控制器，网关，ADAS摄像头等组成。

---

系统设计

基于多域控制的 OTA 功能是实现智能网联汽车快速迭代的基本条件，也是未来汽车发展的一种必然趋势。通过 实现车载网络各系统的 OTA 的升级，可以降低系统的维护成本，也可以通过 OTA 为客户提供千人千面的个性 化服务，满足不同客户的需求，提升用户对车辆的粘度和满意度。国内外很多主机厂都实现了 CAN 控制器的 OTA 升级，但随着智能网联汽车的发展，CAN 总线已经无法满足控制器的升级要求，车载以太网总线势在必 行。车用计算机网络 OTA 演示系统实现了对采用了 AUTOSAR 自适应平台和经典平台的节点的 OTA 软件刷 写，初步验证了与 AUTOSAR 标准相结合的 OTA 升级流程、OTA 策略等，如下图1所示：

图1 演示系统

OTA 演示系统功能示意如图2所示，系统包含网关、智能天线、车用防火墙、ADAS 摄像头、ADAS 域控制 器、座舱域控制器、以及 OTA 平台。
OTA 平台端具备车辆管理、车型管理、软件版本管理以及任务的发布和推送的能力。平台端也具备管理的属 性，包括账号体系、权限体系等，支持 OEM 的不同部门、不同科室、不同职能工程师在平台上实施 OTA 相关 操作，并查看 OTA 任务执行情况。其中推送的软件包的格式采用 UCM 定义的格式。
智能天线通过车载以太网、BT、BLE、Wi-Fi、3G/4G 实现了车身控制、远程控制、远程诊断、OTA 功能。在 AUTOSAR OTA Demo 系统中，智能天线负责与 OTA 云端认证、通信；负责所有控制器升级文件下载、验 签、备份；负责所有控制器升级条件检测、升级策略执行；负责控制器升级文件解析。

图2 演示系统功能示意图

车用防火墙执行网络安全隔离，禁止越权访问；车载防火墙策略管理、动态更新；对域间数据交互提供安全防护 机制；边界入侵防御检测等功能。
座舱域控制器中的 HMI 界面用于整个系统升级流程的人机交互即升级控制操作和升级状态信息显示。座舱域控 制器中的升级应用程序，与 AUTOSA 自适应平台架构中的 CM（通讯管理）、DM（诊断管理）、UCM（更新 配置管理）模块相配合完成系统中各模块升级的管控。
ADAS 摄像头传感器，接收网关转发的 UDS 报文，解析加密升级包，执行 CRC 校验，并支持断点续传升级。 ADAS 域控制器通过 OTA 持续升级，优化不在法律法规范围内行人/车辆表现、新增商用车车型及新交通标志的
感知识别、优化功能控制逻辑及增加新的自动驾驶特性等。
网关负责将座舱域控制器、ADAS 域控制器、车用防火墙组成以太网相结合的局域网络，保证了各模块之间安全 可靠的数据通信，并将以太网数据与 CAN 报文进行协议转换，连接车用防火墙与 ADAS 摄像头。
整个系统的升级逻辑过程如下图3所示:

图3 OTA升级流程示意图

网络拓扑结构设计如下图4所示，OTA 平台与智能天线之间采用 4G 网络通讯。智能天线与网关通过以太网进行连接， 通讯协议采用 SOME/IP 及 DoIP 协议。以太网使用 100Base-T1 的车载以太网标准。网关使用了 1 路 CAN 接 口和 3 路 Ethernet 接口，其中 CAN 总线的通讯速率为 500Kbit/s，以太网总线的通讯速率为 100Mbit/s。其 中 CAN 总线连接网关与 ADAS 摄像头。网关通过将智能天线的 DoIP 诊断报文转换为 UDS on CAN 诊断报 文，来对 ADAS 摄像头进行刷新。

图4 OTA演示系统网络拓扑图

OTA平台

AUTOSAR OTA Demo 项目中构建了一个固件、APP、分区、配置等升级方案，通过平台端配置软件包，推送 给到车端。接收到软件包后，车端将自动执行平台配置的升级策略，从而实现对不同 ECU 上的软件进行安装管 理。AUTOSAR AP 上的 UCM 标准定义，规范了软件包的格式、管理以及发布流程。艾拉比凭借自身平台端的 特点和 AP 的优点，对方案进行了整合，对平台端的软件包的格式和车端的软件安装管理流程做了重新的改造， 构建了一套能够适应 AUTOSAR 的软件升级流程。整合后，艾拉比的方案可以同时适应 AUTOSAR 和非 AUTOSAR 的平台。

图5 OTA平台架构示意图

OTA 平台架构如图 5 所示，包括车辆管理、车型管理、软件版本管理以及任务的发布和推送的能力。平台端 也具备管理的属性，包括账号体系、权限体系等，支持 OEM 的不同部门、不同科室、不同职能工程师在平台上 实施 OTA 相关操作，并查看 OTA 任务执行情况。
车云间的管道借助 4G、HTTPS、MQTT、CDN 等互联网领域的成熟通信技术，一方面确保通讯符合信息安全 规范；另一方面借助高带宽、网络分发技术，提高软件包触达到每一辆车的概率，确保辆车都能得到 OTA 服 务。
OTA 升级可以分为三个阶段，即生成更新包、传输更新包、安装更新，整个阶段通过网络通信链接，最终实现 终端代码和数据的更新，进而改善终端的功能和服务。其中，更新包采用 AUTOSAR 自适应平台的 UCM 中的 规范。
UCM 输入的安装单位是软件包，如图 6 所示。该软件包包含（Container）一个或多个可执行文件。除了应 用程序和配置数据外，每个软件包都包含一个软件包 Manifest，该 Manifest 提供源数据，例如软件包名称、版 本、依赖关系以及特定的供应商信息，以便用户根据该信息制定特殊的处理方式。

图6 软件包信息描述（AUTOSAR）

智能天线

由赫千科技提供的智能天线是基于 Broad-Reach 技术开发的智能以太网鲨鱼鳍天线模块, 集成了 Tuner、 GPS、3G/4G/5G、BT、Wi-Fi、BLE、RKE、TPMS 射频模块。智能天线把射频数据转换为数字信号，重新编码 后通过车载以太网与车内各 ECU 通信，为各节点设备提供包括收音机服务、定位/惯导服务、远程控制服务、 4G/5G、V2X 等多种接入服务。
在 OTA Demo 系统中，智能天线基于 AUTOSAR 自适应平台开发 OTA Client、UCM、CM、DM 等软件功能 模块，进而实现对系统中各模块的升级管理。智能天线控制器软件架构如图 7。

图7 智能天线软件架构图

OTA Client 是升级的主控者，其一方面与 OTA 云服务器连接获取升级信息和升级包，一方面与 UCM、CM、 DM 配合进行升级流程的管控。

图8 SOME/IP 通信

CM 模块主要用来实现智能天线与座舱域控制器之间的升级命令和升级状态信息的传输。CM 是基于 SOA 的 AUTOSAR 自适应平台的一个核心功能模块，负责分布式实时嵌入式环境中应用程序之间通信的方方面面，实现 AUTOSAR 自适应平台平台应用各级之间面向服务的通信，包括进程内、进程间和 ECU 间的进程通信。CM 的 主要功能有提供 Service、Method、Event、Field 的相关 API，ECU 之间采用 SOME/IP 通信，如图 8 所示。
UCM 是 Update and Configuration Management 的缩写，在 AUTOSAR AP 上属于服务类型（平台基础服 务），主要提供软件升级和配置管理功能，通过 ara::com 提供软件升级服务的访问接口。

图9 UCM组件图

UCM 内部由一个或多个类组成，如图9 所示，协同完成某一类的操作。
PackageManager 是 UCM 服务的核心构件，负责实现 Spec 定义的各个功能接口，实现和客户端的各种业务 交互逻辑。其它组件是 PackageManager 的工具组件，被 PackageManager 使用以实现相应的基础操作。
Receiver 是 UCM PackageManager 用来完成升级包接收的组件，实现了升级包接收过程中的资源申请、传输 控制、数据缓存、包完整性校验。
Extractor 是 PackageManager 用来实现对压缩包进行提取的工具。Extractor 向 PackageManager 提供抽象 接口，可实现对 zip 压缩包的提取功能。
Parser 是 PackageManager 用来解析 Manifest 文件内容，获取软件的依赖、版本、名称、校验和，引用等。 Parser 同时用来解析平台已安装应用的版本、名字等信息、软件包信息、供客户端获取已安装应用列表、软件 包列表等。Parser 从软件安装路径 (/opt/function/) 中读取 application.json 文件，组织成 SoftClusterInfo。 Storage 是 PackageManager 用来处理存储相关的操作的工具构件，主要用于将缓存数据固化到 NVM，在软
件固化操作中不删除原有数据，而是采用覆盖方式。
Transaction 用于实现安装后的激活和回退操作。在软件安装或升级后，重新启动可能会遇到各种原因的错误， 这时客户端可以采取回退操作，将系统回退到安装或升级之前的状态。UCM 在客户端调用 Activate 接口后，首 先需要检查应用的依赖，依赖检查通过之后，调用 EM 接口依次启动本次升级涉及的应用（该信息保存在升级包 的 manifest 文件中），根据 EM 的返回值判断升级是否成功。在这个过程中只要有一个应用启动出错，UCM 认为此次升级失败，并将出错信息报告给 Client。如果软件激活全部成功，则激活完成，UCM 报告升级成功。 DM （Diagnostic Management） 作为一个服务模块，为 AUTOSAR AP 平台提供诊断服务，对外通过 DoIP 与诊断仪交互，对内通过 ara::com 为需要被诊断的应用提供服务。DM 主要分成 DCM，DEM 两个模块。其中 DCM（Diagnostic Communication Management）主要负责诊断通信管理，也就是 UDS 相关命令的处理。 DEM（Diagnostic Event Management）即诊断事件管理，主要负责软件平台内部事件的处理。
在 AUTOSAR OTA Demo 系统中，使用 DM 进行升级包的诊断传输对其他设备进行升级，主要包括车辆发 现，建立连接，UDS 诊断三个过程，其实现细节如下：
1）车辆发现
车辆发现流程的目的是将节点的 DoIP 属性告诉给当前局域网内其它 DoIP 节点。其它 DoIP 节点可根据自己的 业务需求，决定是否与其建立连接通讯。Server 有两种方式将自己的 DoIP 属性告诉给 Client：
a) 上电后，主动发送 3 次 vehicle announcement message，在消息中携带逻辑地址、VIN、EID 等信息， 如图10 中 a 处所示；
b) 由 Client 在适当时机以广播方式发送 vehicle identification request，收到该消息的 Server 以单播的形 式回复 vehicle identification response 消息，其中携带逻辑地址、VIN、EID 等信息。如图10 中 b、 c 处所示。

图10 车辆发现

2）建立连接

图11 建立连接

Client 与 Server，只有建立连接后，才能够进行 UDS 通信，建立连接分为 3 个步骤：
a) Client 主动与 Server 建立 TCP 连接，如图11 中 a 处所示；
b) Client 发送 routing activation request 消息请求激活路由，Server 根据实际情况同意或者拒绝激活请 求，激活结果通过发送 routing activation response 消息告知 Client，如图 2-11 中 b 处所示；
c) 若 Client 与 Server 之前长时间没通信，Server 会主动发送 alive check request 消息，检测 Client 是 否还正常工作，若 Client 没有发送 alive check response 消息，Server 将断开与 Client 建立好的连接， 如图 2-11 中 c 处所示。

如需阅读完整全文精彩内容，敬请关注公众号“ADAS与ECU之吾见”，扫描关注！

公众号后台回复关键字“加群”，便可免费加入AUTOSAR技术交流群，共同探讨CP，AP，SOA，信息与功能安全等前言热点话题！

公众号后台回复“OTA”关键词即可获取完整PDF原文！**