 AUTOSAR 中国用户组成员单位共同开发了车用计算机网络OTA 演示系统，使用了AUTOSAR 的开发方法和软件架构，应用了自适应平台（Adaptive Platform, AP）和经典平台（Classic Platform, CP）的基础软件。通过联合开发工作将各方的零部件集成到一个适合新一代汽车量产的网络架构中，实现了OTA 远程软件升级演示功能，对基于AUTOSAR 标准的软件开发工作加深了理解。

本文作者

荆喆，博世；陈柱，耿尚，赫千科技

蔡建兵，艾拉比； 张仕玉，福瑞泰克

周凯伦，东软睿驰； 范志容，东风汽车

01

概述

AUTOSAR 中国用户组成员单位共同开发了车用计算机网络OTA 演示系统，使用了AUTOSAR 的开发方法和软件架构，应用了自适应平台（Adaptive Platform, AP）和经典平台（Classic Platform, CP）的基础软件。通过联合开发工作将各方的零部件集成到一个适合新一代汽车量产的网络架构中，实现了OTA 远程软件升级演示功能，对基于AUTOSAR 标准的软件开发工作加深了理解。本文介绍演示系统的设计思路和实现过程，虽然没有定义具体的性能指标，但是网络架构和技术元素贴近新一代汽车量产项目，在本文中各参与方对完成的工作内容和积累的技术经验进行描述和分享，希望能为广大读者带来基于AUTOSAR 标准进行软件开发工作的一些经验，并激发灵感。

02

演示系统的设计和实现

2.1 系统设计

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

图2-1 演示系统实拍图

2.1.1 系统功能设计

OTA 演示系统功能示意如图2-2 示，系统包含网关、智能天线、车用防火墙、ADAS 摄像头、ADAS 域控制器、座舱域控制器、以及OTA 平台。

OTA 平台端具备车辆管理、车型管理、软件版本管理以及任务的发布和推送的能力。平台端也具备管理的属性，包括账号体系、权限体系等，支持OEM 的不同部门、不同科室、不同职能工程师在平台上实施OTA 相关操作，并查看OTA 任务执行情况。其中推送的软件包的格式采用UCM 定义的格式。

智能天线通过车载以太网、BT、BLE、Wi-Fi、3G/4G 实现了车身控制、远程控制、远程诊断、OTA 功能。在AUTOSAR OTA Demo 系统中，智能天线负责与OTA 云端认证、通信；负责所有控制器升级文件下载、验签、备份；负责所有控制器升级条件检测、升级策略执行；负责控制器升级文件解析。

图2-2 演示系统功能示意图

车用防火墙执行网络安全隔离，禁止越权访问；车载防火墙策略管理、动态更新；对域间数据交互提供安全防护机制；边界入侵防御检测等功能。

座舱域控制器中的HMI 界面用于整个系统升级流程的人机交互即升级控制操作和升级状态信息显示。座舱域控制器中的升级应用程序，与AUTOSA 自适应平台架构中的CM（通讯管理）、DM（诊断管理）、UCM（更新配置管理）模块相配合完成系统中各模块升级的管控。

ADAS 摄像头传感器，接收网关转发的UDS 报文，解析加密升级包，执行CRC 校验，并支持断点续传升级。

ADAS 域控制器通过OTA 持续升级，优化不在法律法规范围内行人/车辆表现、新增商用车车型及新交通标志的感知识别、优化功能控制逻辑及增加新的自动驾驶特性等。

网关负责将座舱域控制器、ADAS 域控制器、车用防火墙组成以太网相结合的局域网络，保证了各模块之间安全可靠的数据通信，并将以太网数据与CAN 报文进行协议转换，连接车用防火墙与ADAS 摄像头。

整个系统的升级逻辑过程如下图2-3 所示。

图2-3 OTA 升级流程示意图（艾拉比）

2.1.2 网络拓扑设计

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

图2-4 OTA 演示系统网络拓扑示意

2.2 OTA 平台

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

图2-5 OTA 平台架构示意图（艾拉比）

OTA 平台架构如图2-5 所示，包括车辆管理、车型管理、软件版本管理以及任务的发布和推送的能力。平台端也具备管理的属性，包括账号体系、权限体系等，支持OEM 的不同部门、不同科室、不同职能工程师在平台上实施OTA 相关操作，并查看OTA 任务执行情况。

车云间的管道借助4G、HTTPS、MQTT、CDN 等互联网领域的成熟通信技术，一方面确保通讯符合信息安全规范；另一方面借助高带宽、网络分发技术，提高软件包触达到每一辆车的概率，确保辆车都能得到OTA 服务。

OTA 升级可以分为三个阶段，即生成更新包、传输更新包、安装更新，整个阶段通过网络通信链接，最终实现终端代码和数据的更新，进而改善终端的功能和服务。其中，更新包采用AUTOSAR 自适应平台的UCM 中的规范。

UCM 输入的安装单位是软件包，如图2-6 所示。该软件包包含（Container）一个或多个可执行文件。除了应用程序和配置数据外，每个软件包都包含一个软件包Manifest，该Manifest 提供源数据，例如软件包名称、版本、依赖关系以及特定的供应商信息，以便用户根据该信息制定特殊的处理方式。

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

2.3 智能天线

由赫千科技提供的智能天线是基于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 等软件功能模块，进而实现对系统中各模块的升级管理。智能天线控制器软件架构如图2-7。

图2-7 智能天线软件架构图

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

图2-8 SOME/IP 通信

CM 模块主要用来实现智能天线与座舱域控制器之间的升级命令和升级状态信息的传输。CM 是基于SOA 的AUTOSAR 自适应平台的一个核心功能模块，负责分布式实时嵌入式环境中应用程序之间通信的方方面面，实现AUTOSAR 自适应平台平台应用各级之间面向服务的通信，包括进程内、进程间和ECU 间的进程通信。CM 的主要功能有提供Service、Method、Event、Field 的相关API，ECU 之间采用SOME/IP 通信，如图2-8 所示。

UCM 是Update and Configuration Management 的缩写，在AUTOSAR AP 上属于服务类型（平台基础服务），主要提供软件升级和配置管理功能，通过ara::com 提供软件升级服务的访问接口。

图2-9 UCM 组件图

UCM 内部由一个或多个类组成，如图2-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 等信息，如图2-10 中a 处所示；

b) 由Client 在适当时机以广播方式发送vehicle identification request，收到该消息的Server 以单播的形式回复vehicle identification response 消息，其中携带逻辑地址、VIN、EID 等信息。如图2-10 中b、c 处所示。

图2-10 车辆发现

2）建立连接

图2-11 建立连接

Client 与Server，只有建立连接后，才能够进行UDS 通信，建立连接分为3 个步骤：

a) Client 主动与Server 建立TCP 连接，如图2-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 处所示。

3） UDS 诊断

Client 已经通过车辆发现，获得了当前局域网内所有DoIP 节点的信息，并且与所有的DoIP 节点都已经建立好连接，Client 可通过逻辑ID、VIN、EID 以提前定义好的UDS 升级流程对网络中的某个节点发起升级包传输请求，如图2-12 所示。

图2-12 诊断

不管CAN 控制器还是Ethernet 控制器，软件刷写流程相同，参见图2-13。

1. 进入扩展诊断会话（$10 03）：诊断设备通过功能寻址，以3s 的周期发送扩展模式请求报文（$10 03），使CAN 网络中所有电控单元进入扩展诊断会话。

2. 刷写条件检查（$31）：诊断设备通过物理寻址，发送例程控制服务（$31 01 02 03），检查目标控制器是否满足刷写前提条件。

3. 禁止记录DTC（$85）：诊断设备通过功能寻址，使用DTC 设置服务（$85），禁止CAN 网络中的电控单元记录DTC。

4. 关闭通信（$28）：诊断设备通过功能寻址，使用通信控制服务（$28），禁止CAN 网络中的电控单元发送和接收非诊断报文。

5. 进入编程会话（$10 02）：诊断设备通过物理寻址，使电控单元进入编程会话。当应用程序在运行时，电控单元可以从应用程序跳转至引导加载程序。

F：功能寻址P：物理寻址

图2-13 刷写流程图

6. 安全访问（$27）：诊断设备通过物理寻址，对电控单元进行安全访问（$27），所有可刷写的电控单元应支持安全访问服务。

下列之一的条件发生，电控单元将被锁住：

接收到另外一个安全访问请求（不论请求格式、内容、安全级别等是否有效）。
电控单元切换到另外一个诊断会话，或电控单元切换到相同的诊断会话。
解锁电控单元之前，下述服务需要被禁止：
写入数据。
请求下载。

7. 写入指纹信息（$2E F1 84）：诊断设备通过物理寻址写入指纹信息到电控单元。

8. （可选）Flash 驱动刷写：刷写Flash 驱动至电控单元中指定的RAM 地址。刷写序列由请求下载（$34），数据传输（$36）和请求退出传输（$37） 3 个服务请求组成。如果电控单元不需要刷写Flash 驱动，请跳至步骤10 执行。

9. （可选）软件CRC32 校验（$31）：如果电控单元不需要刷写Flash 驱动，请跳至步骤10 执行。刷写Flash 驱动完成后，诊断设备通过例程控制服务（$31）启动校验，诊断设备将电控单元计算的校验值与设备端的校验值相比较。若两者相等，证明数据刷写成功。

10. 擦除存储器相应区域（$31 FF 00）：该功能使用例程控制服务（$31）执行存储器擦除程序。该例程被调用前，请求擦除的逻辑块的有效状态位必须设为无效，防止刷写过程没有成功结束而意外执行应用程序步骤。

11. 应用程序刷写：刷写应用程序至电控单元中指定的非易失性存储器地址。刷写序列由请求下载（$34），数据传输（$36）和请求退出传输（$37） 3 个服务请求组成。

12. 软件CRC32 校验（$31），详情见步骤9。

13. 刷写兼容性检查完成应用程序刷写后，电控单元应执行刷写兼容性检查，并根据检查结果更新软件兼容性状态参数。

14. 电控单元重启（$11）：电控单元通过硬件复位，擦除RAM 中的Flash 驱动代码，并使应用程序生效。

15. 进入扩展会话（$10）：诊断设备使用功能寻址，通过会话控制服务使所在CAN 网络的电控单元进入扩展会话。

16. 打开通信（$28）：诊断设备通过功能寻址，使用通信控制服务（$28）使所在CAN 网络的电控单元恢复正常通信。

17. 打开记录DTC 功能（$85）：诊断设备通过功能寻址，打开记录DTC 功能。允许CAN 网络中连接的电控单元记录DTC。

18. 进入默认会话（$10）：诊断设备使用功能寻址，通过会话控制服务使所在CAN 网络的电控单元进入默认会话。

2.4 车用防火墙

随着车载网络技术的迅速发展，伴随而来的网络攻击也日益严重，车用防火墙作为一道网络安全的屏障，可有效抵御来自外部的网络攻击。车用防火墙具备如下功能：

网络安全隔离，禁止越权访问
车载防火墙策略管理、动态更新
对域间数据交互提供安全防护机制
边界入侵防御检测

车用防火墙是基于由东软睿驰自主研发的Neusar aCore 基础软件开发的。NeuSAR aCore 是一套面向自动驾

驶、V2X 等应用能够满足高性能计算和高带宽通讯的基础软件，全面支持AUTOSAR 自适应平台标准。图2-14展现了车用防火墙的软件架构。

图2-14 NeuSAR aCore 基础软件架构示意图

在OTA demo 系统中，各域控制器采用的升级方案都是基于AUTOSAR 自适应平台实现的。车用防火墙的OTA 升级策略是通过诊断传输升级包+UCM 的技术实现的。车用防火墙首先会接收到来自网关的车辆识别请求，然后将自身信息（逻辑地址、VIN 等）反馈给网关，网关就会保存和车用防火墙之间的连接信息。接下来网关会发送一系列用于准备升级的诊断请求，比如切换到编程会话下，检查域控制器是否满足刷写条件，安全访问验证等。在一切准备工作做好之后，开始传输升级包，NeuSAR aCore 主要处理3 种服务请求：

0x38RequestFileTransfer 服务，将和升级有关的信息发送给域控制器，并等待域控制器反馈升级信息；
0x36TransferData 服务，负责传输升级数据；
0x37RequestFileTransfer 服务，负责校验数据传输是否完成。完成升级传输之后，还会对升级文件的正确性和依赖性进行检查。升级文件放置在特定位置，并通知UCM 客户端使用此文件进行更新；UCM 客户端识别升级文件之后，会使用标准服务接口PackageManagement 将软件包传输给UCM 服务端，并控制和管理UCM 服务端的升级流程；UCM 服务端接收升级包后，在UCM 客户端的指导下，进行升级包的升级校验、处理、激活等步骤。

图2-15 NeuSAR aCore 诊断模块功能框图

如上所述，OTA 升级主要涉及两大技术模块：升级和配置管理（UCM）和诊断（DM）。Neusar aCore 中的UCM 功能集群用于安装、更新和删除应用程序。UCM 功能集群包括三个终端：升级包制作端、UCM 服务端和UCM 客户端。升级包制作端在编译环境上，首先使用上位机配置升级包内容，然后在编译环境上制作出对应升级包，最后将升级包上传到UCM 客户端（OTA 平台）。UCM 客户端负责控制和管理UCM 服务端的升级流程，实现软件升级，并获取软件包和升级过程的相关信息。UCM 服务端负责进行软件升级的具体操作。NeuSAR aCore 中的诊断模块使用基于车载以太网的诊断技术Diagnostics over Internet Protocol（DoIP）和统一诊断服务Unified Diagnostic Services（UDS）两种协议。DoIP 协议就是通过网络协议进行诊断通信，规定了测试设备与域控制器之间的诊断通信交互方式和报文格式。UDS 协议规定了一系列的诊断服务，比如读取DID、例程控制和域控制器刷写等服务，方便售后和产线人员查找和解决问题。图2-15 展示了NeuSAR aCore 中诊断模块的功能框架。

2.5 座舱域控制器与屏幕

OTA Demo 系统中，座舱域控制器中开发了HMI 界面用于整个系统升级流程的人机交互即升级控制操作和升级状态信息显示。座舱域控制器中的升级应用程序，与AUTOSAR 自适应平台中的CM、DM、UCM 模块相配合完成系统中各模块升级的管控。

图2-16 座舱域控制器软件架构图

升级应用程序通过CM 模块与智能天线中的OTA Client 进行通信，实现升级应用程序向OTA Client 发起升级相关的控制命令，同时获取相应的状态信息用于显示在HMI 中，智能天线中运行SOME/IP 客户端，域控制器中运行SOME/IP 服务端，两者之间通信的详细过程如下：

1) 建立服务连接

服务发现的目的是将SOME/IP 节点所提供服务的服务ID、实例ID、端口号、IP 地址告知组播网络里的其它SOME/IP 节点。其它SOME/IP 节点，可根据自己的业务需求选择是否跟该节点进行SOME/IP 通信。Server 有两种方式将服务ID、实例ID 等信息告知Client：

Server 以固定间隔时间，周期性的发送offer service 消息，该消息中携带服务ID、实例ID、端口号、IP 地址等信息，如图2-17 中a 处所示。kWxednc
由Client 在适当时机以组播方式发送request server 消息，收到该消息的Server 以单播的形式回复offer service 消息，其中携带逻辑地址、VIN、EID 等信息。如图2-17 中b、c 处所示。kWxednc

图2-17 建立服务连接

2) 检查更新

首先IVI 需要先订阅该event 所在事件组，如图2-18 中a 处所示，然后IVI 通过method 向Smart Antenna 发起检查更新请求，Smart Antenna 从OTA Server 获取是否有更新、更新包大小、版本号、发布描述信息等，并将这些信息通过event 发送给IVI，如图2-18 中b、c 处所示。

图2-18 检查更新

3) 请求下载更新包

首先IVI 需要先订阅该event 所在事件组，如图2-19 中a 处所示，然后IVI 通过method 向Smart Antenna 发起下载更新包请求，Smart Antenna 从OTA Server 下载更新包，并将下载状态与进度通过event 实时发送给IVI，如图2-19 中b、c、d、e 处所示。

图2-19 请求下载更新包

4) 请求安装更新包

首先IVI 需要先订阅该event 所在事件组，如图2-20 a 处所示，然后IVI 通过method 向Smart Antenna 发起安装更新包请求，Smart Antenna 通过DM 和UCM 功能模块对各个模块进行升级，并将安装状态与进度通过event 发送给IVI，如图2-20 中b、c、d、e 处所示。

图2-20 安装更新包

升级应用程序通过DM 模块从OTA Client 接收升级包，并将升级包传输给UCM 模块做具体的升级动作。座舱域控制器使用UCM 的Update 功能实现程序更新，其升级流程分为三个阶段：数据包传输，数据包处理，激活。其各阶段各状态细节如下：

1. 升级应用程序调用TransferStart 接口发起软件包传输，进入到Transferring。这一过程UCM 为升级应用程序分配代表本次传输任务的ID 识别码，为接收软件包预先申请资源，做好接收准备。TransferStart 接口要求客户端传入要传输的软件包的大小。

2. 在Transferring 状态，升级应用程序调用TransferData 接口传输数据，由于软件包体积一般比较大，无法一次传输，所以需要将数据包分解成数据块，TransferData 接口要求升级应用程序传入该次传输的数据块计数（1,2,3…）。

3. 升级应用程序调用TransferExit 结束传输，如果此时UCM 接收到的数据总和等于软件包大小，则成功结束此次传输，进入到Transferred 状态，其它情况均为出错，进入Error 状态。

4. 在Transferred 状态，升级应用程序可以调用DeleteTransfer 将软件包删除。

5. 在Transferred 状态，升级应用程序可以调用ProcessSwPackage 接口发起软件包处理任务，进入到Processing 状态，在此状态下客户端可以调用GetProcessProgress 接口查询处理进度。软件包的处理内容包括对软件包进行解压缩，读取manifest 内容，获取软件安装的相关配置信息，将正在运行中的相关应用关闭，将相关的文件（包括应用文件、配置数据、标定文件、manifest 等）拷贝到相应的路径或从相关路径移除，软件包中由厂商提供的metadata 指明了在该阶段UCM 需要执行的操作。在软件包处理完毕之后进入到Processed 状态。在Uninstall 操作中，需要检查依赖完整性，即如果有依赖于要卸载的程序的应用时，则报错，不能进行卸载作业。

6. 在Processed 阶段升级应用程序可以调用Revert-ProcessSwPackages 接口将处理软件包造成的系统文件的改变恢复到处理前的状态Transferred，也可以调用Activate 接口将所有的处理激活，此时将进入到 Activating 状态。

7. 在激活过程如果出现任何错误将会回到Processed，升级应用程序也可以调用Rollback 接口，将系统恢复到激活之前的状态。激活过程首先进行依赖完整性检查，所有的依赖都满足之后重启应用或系统。

8. 激活完成之后（升级的应用处于运行状态），升级应用程序可以调用Finish 接口，UCM 在此时会清理升级过程中的中间数据、缓存数据、软件包等，本次升级作业结束。

2.6 ADAS 域控制器

作为被升级端的ADAS 域控制器，福瑞泰克基于AUTOSAR 自适应平台，通过DoIP 总线，在控制器中 ARA:DIAG 服务处理函数中实现了0x38,0x36,0x37 基于以太网协议栈的诊断服务。

当0x37 指令传输完软件升级包时，会触发UCM Client 实例，UCM Client 实例通过控制器内部总线SOME/IP去调用UCM 的各个服务。在UCM 服务中，Activation/Verification 会判断软件包的有效性，如果软件包无效，程序流回滚，如果有效，则完成升级。

图2-21 ADAS 域控制器软件架构图

图2-22 福瑞泰克域控制器OTA 升级流程图

图2-23 福瑞泰克域控制器Package Manager 状态图

2.7 网关

AUTOSAR OTA Demo 项目中，网关负责将智能天线、座舱域控制器、ADAS 域控制器、ADAS 摄像头、车用防火墙组成CAN 与以太网相结合的局域网络，保证了各模块之间安全可靠的数据通信。硬件上采用了NXP 公司的基于MPC5748G 芯片的开发板进行实现。它提供了8 路CAN 接口，5 路以太网（百兆）接口，使用优化技术后以太网速率可达6Gbps。

CAN 功能实现主要包括三个部分：物理层、数据链路层和网络层。物理层通过电路设计，实现CAN 信号差分电压，保证CAN 信号数据的正确传输；数据链路层需保证CAN 信号数据的正常收发，即将CAN 电路信号转换为对应的CAN 数据，此部分工作是由MCU 内部CAN 控制端口实现的，而软件层次上则需要开发相应的CAN 驱动程序，保证CAN 控制端口的正常工作；网络层是根据ISO 15765-2 规范定义进行开发的，实现了CAN 数据包的分帧、组包以及流控制功能。

以太网功能实现基于物理层电路设计，开发了网络端口驱动层程序，保证了以太网数据的正常传输。根据网关功能实现的需要，在驱动层的基础上移植了LwIP 协议栈，实现对IPv4 和IPv6 等协议的支持，同时开发了DoIP 服务端用以保证安全稳定的完成升级流程。

2.8 ADAS 摄像头

作为被升级端的ADAS 摄像头传感器，福瑞泰克基于AUTOSAR 经典平台架构，通过传统的DoCAN 方式，接收网关转发的UDS 报文，解析加密升级包，执行CRC 校验，并支持断点续传升级。

图2-24 ADAS 摄像头传感器软件架构示意图

03

结束语

近年来，随着汽车功能的不断增强，尤其是自动驾驶和智能座舱系统的更高要求，人们对于汽车软件的关注度持续提高。AUTOSAR 组织也为了应对这些新的挑战而推出了新的标准平台Adaptive Platform （AP）。在中国企业对AUTOSAR 标准使用程度越来越高的背景下，几家公司走到一起，在AUTOSAR 中国用户组演示系统子组中合作开发，实现了对实际量产项目有参考意义的车用计算机网络OTA 演示系统。通过这个过程，各参与方对于OTA技术与AUTOSAR 标准相结合的系统和软件开发都有了更深刻的理解。并且为各方的产品符合新的AUTOSAR 标准打下了一定基础。

文章来源及版权属于汽车电子与软件，EDN电子技术设计仅作转载分享，对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。如有疑问，请联系Demi.xia@aspencore.com

你可能可能
1'"
-1 OR 2+98-98-1=0+0+0+1 --

阅读全文，请先

汽车电子与软件

进入专栏

汽车电子

上一篇： 拆解：智壳四合一无线充电器Z4 下一篇： 让车企交出灵魂的英伟达Orin开发平台DRIVE Hyperion 8.1分析

微信扫一扫
一键转发
最前沿的电子设计资讯
请关注“电子技术设计微信公众号”

热门评论
最新评论

换一换

杂志声明

车用计算机网络OTA 演示系统的设计和实现

01

概述

02

演示系统的设计和实现

03

结束语