汽车边缘节点如何实现 OTA 升级？LIN OTA 方案解析

什么是 OTA？OTA（空中升级技术）是通过无线网络（如蓝牙、Wi-Fi、蜂窝网络）为设备远程更新程序的一种技术，无需连接电脑或专用工具即可完成软件升级。

如今，OTA 已从消费电子逐渐扩展到汽车等领域，车辆 ECU 可以通过 OTA 完成功能优化、问题修复或新增功能。随着 OTA 技术在汽车电子中的不断普及，OTA 能力也开始从域控制器扩展到各类边缘节点设备。

本文以汽车执行器节点为例，介绍基于NSUC1610的 LIN OTA 实现方案，并解析相关的软件架构与关键技术。

01 OTA 背后的“黄金搭档”Bootloader 与 UDS 协议

1.1. Bootloader：设备的启动引导程序

类似于电脑开机时首先加载系统引导程序，再启动 Windows 或 macOS，Bootloader 就是设备的启动引导程序。它在设备上电后首先运行，负责初始化硬件、检查系统状态，并加载应用程序（例如手机操作系统或汽车控制软件）。在 OTA 升级过程中，Bootloader 还承担着执行程序更新的重要角色。

如果没有 Bootloader，设备就无法识别新的升级包，也无法完成程序替换。因此，Bootloader 的稳定性和可靠性直接关系到 OTA 升级能否顺利完成。

1.2. UDS 协议：设备与外部系统的通信协议

要向设备发送升级指令，需要一套统一的通信协议。UDS（Unified Diagnostic Services，统一诊断服务）是一套国际通用协议。它定义了设备（如汽车 ECU、智能家居主控板）与外部系统（如 OTA 服务器或诊断工具）之间的通信规则，包括升级请求、身份验证以及数据传输等关键流程。

UDS 协议支持多种通信接口，例如 CAN 总线、LIN 总线和以太网等。在汽车系统中，UDS 指令通常通过 CAN 总线进行传输，而在一些物联网或智能家居设备中，也可以通过 Wi-Fi 或蓝牙等方式实现UDS 交互。

SID (服务ID)	名称	作用
0x10	Diagnostic Session Control （诊断会话控制服务）	主要系统刷写模式控制，包括APP与Bootloader的程序跳转。
0x27	Security Access（安全访问服务）	主要用于在刷写前进行安全访问解锁，以确保刷写过程的安全性。具体安全校验算法通常由各 OEM 自行定义，不同厂商之间差异较大。
0x22	Read Data By Identifier （根据标识符读数据服务）	主要用于读取ECU的参数，一般0x22服务后面会跟上16 bit DID（数据标识ID），告诉ECU要读取什么参数，常见参数包括软件版本号、硬件版本号等。
0x2E	Write Data By Identifier （根据标识符写数据服务）	主要用于写入ECU的参数，一般0x2E服务后面会跟上16 bit DID (数据标识ID) 以及参数内容，告诉ECU要写入什么参数和参数内容，常见参数包括刷写日期信息、刷写者ID等。
0x31	Routine Control （例程控制服务）	主要用于一些刷写过程控制，比如请求Flash擦除，请求数据完整性校验，请求软件兼容性校验。

0x34	Request Download （请求下载服务）	主要用于在程序数据下载前告诉ECU：接下来要进行数据下载，并指定下载地址及数据块大小等信息。
0x36	Transfer Data （数据传输服务）	主要用于数据传输服务，在传输 Flash 数据时，ECU 在接收完成后通常会按照既定流程执行数据写入或编程操作。
0x37	Request Transfer Exit （请求退出数据传输）	主要用于完成一个数据块的数据传输服务后，退出数据传输。
0x11	ECU Reset（ECU 复位服务）	主要用于完成整个程序更新过程，ECU复位后跳转至更新后的APP代码执行应用程序。

02 OTA 升级的“安全密码”：从数据校验到身份认证

OTA 升级并非简单的文件传输，还需要确保升级过程的安全性与可靠性。系统既要防止升级包在传输过程中被篡改，也要避免未经授权的设备伪装成服务器发送升级指令。为此，OTA 升级通常会引入多种安全机制，主要包括数据完整性校验与身份认证。

2.1 数据完整性校验：CRC32 与 SHA256

CRC32 ：通过计算数据的循环冗余校验值，对传输数据进行完整性校验，用于检测升级包在传输过程中是否发生损坏或数据错误。

SHA256 ：一种常见的哈希算法，可将任意长度的数据生成固定长度的 256 位哈希值。只要原始数据有 1 比特变化，哈希值就会完全不同，能有效识别恶意篡改。

2.2 身份认证：RSA 加密与数字签名

RSA2048 + PSS 签名：OTA 服务器使用私钥对升级包进行数字签名，设备接收到升级包后通过对应的公钥进行验签。只有签名验证通过后，设备才会执行升级操作，从而确保升级包来源可信。

安全访问服务（UDS SID 0x27）：在执行升级操作前，设备通常会通过 UDS 的安全访问服务进行权限验证。服务器需要提供相应的安全凭证（如密钥或挑战响应数据），验证通过后系统才会开放刷写权限，防止未授权设备强制刷写。

实现算法相关要求	LIN时序相关要求
采用MASK+AES128+CRC32三段式安全访问算法 RSA2048+PSS实现软件验签 传输数据时完成SHA256哈希算法的预计算	功能寻址仅执行服务不回复，物理寻址回复且执行服务 功能寻址帧插入物理寻址多帧中需要忽略功能寻址帧，保留物理寻址帧的解析执行 LIN多帧时序超时要求NCr=1000ms，Nas=1000ms 其他LIN要求参考LIN 2.1标准相关规范

*表：来自主机厂的 LIN OTA 需求

03 OTA 如何适配不同设备？三大移植注意事项

对于汽车的不同零部件，OTA 需要适配差异较大的硬件环境。工程师在移植 OTA 方案时，通常需要重点关注以下几个方面：

3.1 硬件资源适配

不同设备的内存、Flash 容量差异巨大。例如，一些资源受限的嵌入式设备通常需要采用分块方式传输升级包，而性能更高的汽车 ECU 则可以支持整包下载。

3.2 通信接口兼容

需根据设备的通信方式（CAN/LIN 总线、Wi-Fi、蓝牙）对 UDS 协议实现进行适配，以保证升级指令和数据传输的稳定性。例如，在 LIN 总线设备中，通常需要对长帧数据进行拆分处理，以避免通信过程中的数据丢失。

3.3 版本管理与回滚机制

记录设备当前软件版本，仅允许接收更高版本或官方指定版本的升级包。

预留回滚机制：当升级过程中出现异常（如断电或硬件兼容问题）时，Bootloader 可以自动恢复到上一稳定版本，避免设备无法正常启动。

纳芯微的NovoGenius®系列包含嵌入式电机控制系列，氛围灯驱动系列等，可应用于汽车边缘节点感知、智能执行器以及氛围灯控制等场景。

基于NSUC1610实现主机厂 LIN OTA 软件框架：

软件框架特点

采用自上而下的分层架构实现各项功能；

模块间通过回调和互斥锁机制实现任务同步；

UDS APP主要通过轮询 UDS 服务配置表处理诊断服务消息，同时对 LIN 配置识别服务表进行处理。由于 0x7E 功能寻址无需回复，因此在 UDS APP 组件中进行相关处理；

FLASH APP组件主要负责 Flash 的擦除、编程等操作。相关操作通过状态机运行，并与 UDS 任务进行异步协同：UDS 触发 Flash 操作任务，而 Flash APP 通过状态机完成实际的擦写过程；

SHA256和RSA APP组件主要执行哈希计算和数字签名验证任务，这些任务同样由 UDS APP 异步触发执行；

TP APP主要负责 LIN 传输层任务，在完成组帧后异步通知 UDS APP 进行处理；当收到解帧请求时，则运行解帧状态机完成数据解析。

联系我们

从手机到汽车，从智能家居到工业设备，OTA 技术正在不断改变产品的生命周期管理方式。它让硬件不再是“出厂即固定”的产品，而是可以通过软件持续升级与优化，逐步提升功能与用户体验。

当设备提示“有新版本可用”时，背后往往涉及 Bootloader 的升级管理、UDS 协议的通信机制以及 RSA 等安全技术的保障。正是这些技术的协同工作，使设备能够安全、稳定地完成远程升级。

如需算法实现或技术支持，请联系[e-mail]；如需样品及开发板支持，请联系[e-mail]。更多产品信息与技术资料，敬请访问www.novosns.com。

审核编辑 黄宇