01 系统功能设计

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

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

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

图1 系统功能示意图

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

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

ADAS 摄像头传感器，接收网关转发的 UDS 报文， 解析加密升级包， 执行 CRC 校验，并支持断点续传升级。ADAS 域控制器通过 OTA 持续升级， 优化不在法律法规范围内行人/车辆表现、 新增商用车车型及新交通标志的感知识别、优化功能控制逻辑及增加新的自动驾驶特性等。

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

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

图 2 OTA 升级流程示意图

02 网络拓扑设计

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

图 3 OTA 演示系统网络拓扑示意

03 OTA平台

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

图 4 OTA 平台架构示意图

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

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

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

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

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

04 智能天线

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

图 6 智能天线软件架构图

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

图7 SOME/IP 通信

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

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

图8 UCM 组件图

UCM 内部由一个或多个类组成，如图8所示，协同完成某一类的操作。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 等信息，如图9中 a 处所示；

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

图9 车辆发现

2） 建立连接

图 10 建立连接

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

a) Client 主动与 Server 建立 TCP 连接，如图 10 中 a 处所示；

b) Client 发送 routing activation request 消息请求激活路由， Server 根据实际情况同意或者拒绝激活请求，激活结果通过发送 routing activation response 消息告知 Client，如图10中 b 处所示；

c) 若 Client 与 Server 之前长时间没通信， Server 会主动发送 alive check request 消息，检测 Client 是否还正常工作，若 Client 没有发送 alivecheck response 消息， Server 将断开与 Client 建立好的连接，如图10中 c 处所示。

3） UDS 诊断

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

图11 诊断

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

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）：诊断设备通过物理寻址，使电控单元进入编程会话。当应用程序在运行时，电控单元可以从应用程序跳转至引导加载程序。

图12 刷写流程图

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 网络的电控单元进入默认会话。

05 车用防火墙

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

1、网络安全隔离，禁止越权访问

2、车载防火墙策略管理、动态更新

3、对域间数据交互提供安全防护机制

4、边界入侵防御检测

车用防火墙是基于由东软睿驰自主研发的 Neusar aCore 基础软件开发的。NeuSAR aCore 是一套面向自动驾驶、 V2X 等应用能够满足高性能计算和高带宽通讯的基础软件，全面支持 AUTOSAR 自适应平台标准。图 13展现了车用防火墙的软件架构。

图13 NeuSAR aCore 基础软件架构示意图

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

1、0x38RequestFileTransfer 服务， 将和升级有关的信息发送给域控制器，并等待域控制器反馈升级信息；

2、0x36TransferData 服务， 负责传输升级数据；

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

图14 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、例程控制和域控制器刷写等服务， 方便售后和产线人员查找和解决问题。图14展示了NeuSARaCore 中诊断模块的功能框架。

06 座舱域控制器与屏幕

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

图 15 座舱域控制器软件架构图

升级应用程序通过 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：

1、Server 以固定间隔时间，周期性的发送 offer service 消息，该消息中携带服务 ID、实例 ID、端口号、IP 地址等信息，如图16中 a 处所示。

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

图16 建立服务连接

2) 检查更新

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

图17 检查更新

3) 请求下载更新包

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

图18 请求下载更新包

4) 请求安装更新包

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

图19 安装更新包

升级应用程序通过 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 在此时会清理升级过程中的中间数据、 缓存数据、 软件包等，本次升级作业结束。

07 ADAS域控制器

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

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

图20 ADAS 域控制器软件架构图

图 21 福瑞泰克域控制器 OTA 升级流程图

图22 福瑞泰克域控制器 Package Manager 状态图

08 网关

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服务端用以保证安全稳定的完成升级流程。

09 ADAS摄像头

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

图 23 ADAS 摄像头传感器软件架构示意图