基于ISO 14229 UDS协议的嵌入式设备远程诊断系统设计与实现

升级流程：

诊断仪发送 0x10 0x02 进入编程会话；
发送 0x27 0x01/0x02 通过Seed-Key安全访问解锁；
发送 0x34 请求下载，携带目标内存地址、数据格式（0x00=未压缩未加密）、数据长度；
循环发送 0x36 传输固件分块，每块最大等于传输层允许的最大长度（CAN TP下为4095字节）；
发送 0x37 退出传输，设备校验CRC32；
发送 0x31 0x01 0xFF 0x01 启动完整性检查例程；
发送 0x11 0x01 硬复位，跳转新固件。

/* 0x34 请求下载处理核心逻辑 */
UDS_ErrCode UDS_Handle_RequestDownload(uint8_t *req, uint16_t req_len, uint8_t *resp, uint16_t *resp_len) {
    uint8_t dataFormatId = req[1];      /* 0x00 = 未压缩未加密 */
    uint8_t addrLenFormat = req[2];     /* 高4bit=内存地址长度, 低4bit=数据长度字节数 */
    uint8_t memAddrLen = (addrLenFormat >> 4) & 0x0F;
    uint8_t memSizeLen = addrLenFormat & 0x0F;

    uint32_t memAddr = 0, memSize = 0;
    for (int i = 0; i < memAddrLen; i++) memAddr = (memAddr << 8) | req[3 + i];
    for (int i = 0; i < memSizeLen; i++) memSize = (memSize << 8) | req[3 + memAddrLen + i];

    /* 地址合法性校验：仅允许写入Bootloader预留区 */
    if (memAddr < APP_START_ADDR || (memAddr + memSize) > FLASH_END_ADDR) {
        return UDS_NRC_REQUEST_OUT_OF_RANGE;  /* 0x31 */
    }

    /* 计算最大块长度（考虑CAN TP首帧占1字节） */
    uint16_t maxBlock = TAL_GetMaxTxLen() - 2;  /* 减去SID+blockSequence */
    resp[0] = 0x74;          /* 0x34 + 0x40 = 肯定响应SID */
    resp[1] = 0x10;          /* 长度格式标识符 */
    resp[2] = (maxBlock >> 8) & 0xFF;
    resp[3] = maxBlock & 0xFF;
    *resp_len = 4;

    g_download_state.addr = memAddr;
    g_download_state.remaining = memSize;
    g_download_state.block_seq = 1;
    return UDS_OK;
}

4.7 否定响应处理（NRC）

UDS的否定响应机制（Negative Response Code, NRC）是调试与问题定位的关键。服务器收到无效请求时，回复 0x7F + 原请求SID + NRC。

工业设备必须支持的NRC及典型触发场景：

NRC码	名称	触发场景	处理建议
0x10	generalReject	服务内部异常	记录日志，复位诊断任务
0x11	serviceNotSupported	请求了未实现的服务SID	诊断仪检查服务支持列表
0x12	subFunctionNotSupported	子功能不支持	如0x10 0x05请求了未实现的会话
0x13	incorrectMessageLengthOrInvalidFormat	请求消息长度错误或格式无效	检查数据包长度与格式标识符
0x22	conditionsNotCorrect	前置条件不满足	如编程会话下未解锁安全访问
0x31	requestOutOfRange	请求超出范围	DID/DTC/内存地址非法
0x33	securityAccessDenied	安全访问被拒绝	需先执行0x27解锁
0x78	responsePending	请求已接收，响应尚未准备好	长任务处理中，诊断仪需等待

4.8 轻量级协议栈资源占用实测

本方案在STM32F103C8T6（Cortex-M3, 72MHz, 64KB Flash, 20KB RAM）上的实测资源占用如下：

模块	Flash占用	RAM占用	说明
UDS应用层核心	18.2KB	1.8KB	含8项服务、DTC管理、会话状态机
CAN TP传输层	4.5KB	0.6KB	ISO 15765-2完整多帧传输
UART传输层	1.2KB	0.3KB	自定义帧格式+CRC16
NVM管理层	2.1KB	0.2KB	EEPROM模拟/DTC持久化
安全访问（0x27）	1.4KB	0.1KB	Seed-Key算法（AES-128简化）
Bootloader集成	3.8KB	0.4KB	跳转逻辑、固件校验
合计（CAN方案）	27.2KB	3.1KB	Flash余量36.8KB供业务应用
合计（UART方案）	23.9KB	2.8KB	更省Flash，适合低成本MCU

4.9 远程诊断云平台对接架构

将UDS诊断能力扩展至远程场景，需要在上位机与设备之间增加"诊断网关"层：

云端诊断平台
     |
     | HTTPS / MQTT
     v
边缘诊断网关（Linux/工控机） —— UDSonIP封装
     |                          将CAN/UART UDS帧
     |                          封装为TCP/JSON报文
     v
现场设备（STM32 + CAN/UART） —— UDS协议栈

网关层关键功能：

协议转换：将云端JSON诊断请求转换为UDS原始帧，通过CAN/UART发送至设备；
会话保持：网关维持与设备的诊断会话，避免云端连接抖动导致会话中断；
DTC上报：设备周期性（如每小时）主动上报confirmed DTC列表，网关存入时序数据库；
远程OTA：云端推送固件至网关，网关通过UDS 0x34~0x37服务分块下发至设备。

五、部署验证与实测数据

本方案已在沧州艾诺威为某消防电源监控厂商定制的RTU终端上完成验证，核心测试数据如下：

设备平台：STM32F103RET6 + CAN2.0B + RS-485 + 4G模块；
DTC覆盖：定义了23个DTC，涵盖主电欠压（P0562）、备电故障（P0563）、通信超时（U0100）、温度超限（P0117）等；
诊断响应延迟：单帧请求平均响应2.8ms（CAN 500kbps），多帧（4KB固件块）传输耗时185ms；
OTA升级实测：64KB固件通过4G+CAN链路远程升级，总耗时约4分20秒，CRC32校验通过率100%；
连续运行测试：72小时连续诊断压力测试（每秒1次0x22轮询），无丢帧、无会话异常。

六、总结

ISO 14229 UDS协议并非汽车电子专属——其分层服务架构、标准化DTC体系与完善的安全访问机制，同样是工业物联网设备远程诊断与固件升级的最优技术底座。通过传输层抽象裁剪与协议栈轻量化设计，UDS可在资源受限的STM32 MCU上以28KB Flash、3KB RAM的代价完整运行，实现从现场总线到云端平台的标准化诊断链路。对于正在构建设备运维体系的物联网厂商而言，采用UDS替代私有诊断协议，是降低长期维护成本、提升设备可服务性的关键决策。

本文基于 OEM UDS Service Required 技术规范与沧州艾诺威工业现场项目实践整理优化。

还想接着看

UDS诊断协议CAN总线分层实现——从ISO 15765传输层到ECU诊断服务的分层解析。
OEM UDS诊断规范工程落地指南——DTC状态字节与会话时序的ECU实现细节。
CAN总线协议与STM32 bxCAN实战——远程诊断系统底层的CAN控制器工程。