第二章 数字钥匙系统架构：整体架构、UWB角色与通信流程
好，咱们进入正题。数字钥匙这个系统，说白了就是把你的手机变成车钥匙。但这里面的门道，比传统钥匙复杂得多。我当年刚接触这个项目时，第一反应也是「不就是蓝牙连接一下嘛」——后来才发现，事情远没那么简单。
2.1 数字钥匙整体架构
先看一张宏观的图（嗯，在我脑子里）。数字钥匙系统通常分为三层：
- 云端层：钥匙管理、权限下发、日志记录
- 手机端：APP + 安全芯片 + UWB/蓝牙硬件
- 车端：蓝牙模块、UWB锚点、BCM（车身控制模块）
这三层之间，通过一套标准化的协议通信。我个人习惯把架构画成「三明治」——中间是通信协议，上下两层是业务逻辑。
关键点：数字钥匙不是简单的「手机-车」点对点通信。它必须支持分享、撤销、过期等操作。所以云端是必不可少的。
举个例子：你老婆要开车，你通过APP把钥匙分享给她。这个操作流程是：
- 你在手机端发起分享请求
- 云端生成新的密钥，绑定到你老婆的手机ID
- 车端同步更新授权列表
- 你老婆的手机靠近车辆时，自动解锁
我在项目中遇到过一个问题：分享钥匙后，原车主手机没电了怎么办？嗯，这就要靠云端做「离线授权」机制了。具体后面会讲。
2.2 UWB在数字钥匙中的角色
蓝牙负责连接和握手，UWB负责定位。这是最核心的分工。
你想想看，蓝牙的定位精度大概在1-5米，而且容易受多径干扰。但UWB不一样——它的精度可以做到10-30厘米。为什么？因为UWB用的是纳秒级的脉冲，时间分辨率极高。
UWB在数字钥匙里具体干三件事：
- 测距：通过TOF（飞行时间）算出手机到车门的距离
- 定位：结合多个锚点，算出手机在车周围的精确位置
- 防中继攻击：这是UWB的杀手锏。传统无钥匙系统容易被「信号放大器」攻击，但UWB因为测距精度高，能检测到信号是否被中继
避坑指南：我曾经在项目里踩过一个坑——UWB和蓝牙的天线布局没协调好。蓝牙天线在车顶，UWB锚点在车门，结果信号互相干扰。后来我们强制规定：蓝牙和UWB的工作频段必须错开，而且天线间距至少20cm。
说白了，UWB就是数字钥匙的「眼睛」。没有它，你只能知道手机在车附近，但不知道是在驾驶位还是后备箱。有了它，你可以实现「走到驾驶门自动解锁，走到后备箱自动弹开」这种体验。
2.3 系统通信流程
整个通信流程，我习惯分成四个阶段：
| 阶段 | 触发条件 | 主要动作 | 耗时 |
|---|---|---|---|
| 1. 蓝牙扫描 | 手机进入蓝牙范围（约10米） | 手机广播、车端扫描、建立BLE连接 | 0.5-2秒 |
| 2. 身份认证 | BLE连接建立后 | 手机发送证书、车端验证、交换会话密钥 | 0.3-1秒 |
| 3. UWB测距 | 认证通过后 | 手机和车端UWB模块开始双向测距 | 0.1-0.5秒 |
| 4. 动作执行 | 位置确认后 | 根据位置触发解锁/上锁/后备箱开启 | 0.1秒 |
这里有个细节：为什么UWB测距要在认证之后？因为UWB本身不加密，如果先测距再认证，攻击者可以伪造测距结果。所以标准流程是：先通过蓝牙做安全握手，再用UWB做物理测距。
我记得有一次调试，发现手机靠近车辆时，解锁反应特别慢。查了半天，原来是蓝牙扫描阶段用了「被动扫描」模式，手机要等车端广播。后来改成「主动扫描」，手机主动发请求，延迟从2秒降到了0.5秒。
注意：UWB测距过程中，手机和车端必须保持时间同步。如果时钟偏差超过1ppm，测距误差就会超过30cm。所以实际项目中，我们会在每次测距前先做一次「时钟校准」——说白了就是互相发几个包，算出差值。
最后说一句：整个通信流程的设计，核心原则是「安全优先，体验次之」。你想想看，如果为了快0.5秒而牺牲安全性，那这个数字钥匙就形同虚设了。我在项目评审会上经常说一句话：「宁可慢一点，也要让车知道来的是主人，而不是小偷。」
嗯，这一章就到这里。下一章我们深入UWB测距算法的细节——那才是真正烧脑的地方。