UWB 数字钥匙开发实践：从芯片配置到位置可视化

——一个未量产但完整验证的嵌入式原型项目

作者：黄易学
时间：2025 年 4 月 – 2025 年 12 月
状态：技术可行性验证（DVT 阶段），未量产
目标读者：嵌入式开发者、汽车电子初学者、UWB 技术探索者

一、为什么做这个项目？

随着电车厂商的发展，超宽带（UWB）技术已开始成为汽车电子的标配。
我们团队启动预研项目，目标是验证：
✅ 能否在国产车规级平台上实现可靠的 UWB 测距且符合ICCE协议？
✅ 能否仅凭距离信息判断提供业务逻辑？

二、系统整体架构

整个系统由两部分组成：

角色 硬件平台 主要功能
Fob 端 NXP KW45 + NCJ29D5 BLE 配对 + UWB 测距响应
车端 NXP KW45 + NCJ29D5 主锚点控制 + 多锚点数据汇聚 + UWB 测距响应

🔹 我的工作范围：嵌入式软件开发 + 上位机效果验证

三、我负责的核心模块

1. 测距流程触发

  • 通过 FreeRTOS 事件组 接收来自 BLE 模块的“蓝牙连接”事件
  • 启动无感交互认证流程（验证ICCE协议）
  • 启动安全测距流程（调用芯片 SDK 提供的接口）
  • 会话密钥由安全团队通过外置 SE 芯片生成，我通过只读全局变量安全获取

2. UWB 模块配置

  • 通过 SPI 向 NCJ29D5 发送预定义指令数组
  • 配置内容包括：角色（Initiator/Responder）、发射功率、测距周期、MAC(Media Access Control)地址、URSK(UWB Ranging Security Key)
  • 配置成功后，UWB 模块自动开始测距，并返回 ToF 数据

💡 反思：当时采用硬编码指令序列，后期认为可抽象为“配置器”，但受限于 C 语言特性，未实施。

3. 数据汇聚与上报

  • 各从锚点通过 CAN FD 总线 将测距数据发送至主锚点
  • 主锚点汇集所有距离数据（Fob 到各锚点的距离）
  • 数据输出方式：
    • 模拟转发给整车中控（通过 CAN FD）
    • 通过串口实时上报给上位机（用于可视化验证）

4. 效果可视化（上位机）

  • 使用 Python + PyQt6 开发独立上位机,实现定位算法
  • 功能包括：
    • 二维坐标图（基于简化多边定位）
    • 距离折线图（观察稳定性）
    • 车内/车外状态指示（基于离线训练模型）
  • 模型仅使用距离特征，准确率约 98%（理想场景），车窗未关时降至 ～70%
  • 不同车型需要专门训练模型

⚠️ 注：ML 模型在 Cortex-M33 上做过部署验证，但未纳入最终交付。

四、关键挑战与收获

1. ICCE协议和加密

  • ICCE依赖于社区联盟的标准，存在一定门槛。
  • 加密的完整链路在实际使用中依赖车厂的云端服务器。

2. 错误处理是系统工程

  • 本地可检测 SPI 超时、配置失败等错误
  • 但全局恢复（如重启 BLE、重协商）需跨模块协作
  • 深刻体会到：可靠性 = 模块健壮性 × 团队响应机制

3. 架构设计的教训

  • 初期试图用宏兼容 Fob/主锚点代码，后因业务差异大而拆分
  • POC 阶段应优先验证功能，而非追求架构优雅

六、结语

感想

这个项目虽未走向量产，但它让我：

  • 深入理解了 UWB 在汽车场景的潜力与挑战
  • 积累了 BLE + UWB + CAN FD + SE 芯片的多模块协同经验
  • 学会了如何在资源受限设备上构建端到端验证系统
  • 国内外的UWB数字钥匙的指标区别较大，例如在欧洲选择的是CCC协议，且强制要求活体监测(CPD)
  • 国内的UWB数字钥匙的实现方案早在多年前就存在，最新的方案是ICCE协议，但目前主流似乎是推行配套星闪系统

附：技术栈清单

  • MCU：NXP KW45 (Cortex-M33)
  • UWB 芯片：NXP NCJ29D5
  • RTOS：FreeRTOS
  • 通信协议：SPI (UWB), CAN FD (锚点间), BLE (Fob 连接)
  • 上位机：Python 3.10 + PyQt6 + scikit-learn
  • 开发环境：MCUxPresso Studio, VS Code, Ubuntu VM (用于跨平台验证)