车钥匙系统架构：PEPS、多模方案与功能安全

好，咱们进入第二章。这一章我打算聊聊车钥匙系统的整体架构。说实话，很多刚入行的朋友容易一上来就盯着UWB的测距算法看，结果忽略了整个系统是怎么协同工作的。我个人习惯是，先看全局，再抠细节。你想想看，一个车钥匙，它不只是个“能开锁的遥控器”，它背后是一整套PEPS系统在支撑。

PEPS系统架构：无钥匙进入的“大脑”

PEPS，全称是Passive Entry Passive Start，也就是被动进入、被动启动。说白了，就是你揣着钥匙靠近车门，门就开了；坐进车里，按个按钮车就启动了。整个过程你不需要掏出钥匙来按任何键。

那这个系统是怎么工作的呢？我画个简单的逻辑图给你看：

• 车端（基站）：车上装有多个天线（LF低频天线和UWB天线），它们负责发射和接收信号。
• 钥匙端（标签）：就是咱们做的这个UWB车钥匙，它是个移动节点。
• 通信流程：车端通过LF（125kHz）低频唤醒钥匙 → 钥匙被唤醒后，通过UWB或BLE回复 → 车端计算距离和位置 → 确认身份后执行开锁/闭锁动作。

这里有个关键点：LF唤醒。为什么用LF？因为低频信号穿透性好，而且功耗极低。钥匙平时处于深度睡眠，只有收到特定的LF唤醒帧才会启动。我在项目中遇到过一个问题，就是LF天线的匹配没做好，导致唤醒距离只有不到1米，车主走到车门边了还没唤醒，体验极差。嗯，这里要注意，LF天线的Q值（品质因数）和调谐电容一定要仔细算。

UWB + BLE + NFC 多模方案：为什么非要三个？

你可能会问：一个UWB不就够了吗？测距又准，还能防中继攻击。为什么还要加上BLE和NFC？

我刚开始做这个项目时也有同样的疑问。后来踩了坑才明白，每种技术都有自己的“舒适区”。

技术	优势	劣势	在车钥匙中的角色
UWB	厘米级定位、抗多径、防中继攻击（因为纳秒级时间戳）	功耗较高、成本高、穿透性一般	精确测距与定位（判断钥匙在车内/车外/左/右）
BLE	低功耗、连接建立快、手机兼容性好	测距精度差（米级）、易受干扰	低功耗连接、数据通信、RSSI粗定位
NFC	无源工作、绝对安全（近场通信）、兼容手机NFC	通信距离极短（<4cm）、速率低	应急开锁、手机模拟钥匙、无电模式

你看，这三个技术是互补的。举个例子：

• 平时钥匙在口袋里，BLE保持低功耗连接，车端知道“钥匙大概在附近”。
• 当车主走到车门边，UWB被唤醒，做一次精确测距，确认“钥匙在左侧车门30cm处”。
• 如果钥匙没电了，或者BLE/UWB都失效了，NFC就是最后的救命稻草——把钥匙贴在车门把手上的NFC感应区，就能开锁。

我曾经遇到过客户抱怨，说他们的车钥匙在停车场经常误开锁。后来一查，是BLE的RSSI阈值设得太低了，导致隔了好几辆车也能触发。解决方案就是：用UWB做最终判决，BLE只负责“粗筛”，UWB负责“精判”。

车钥匙功能安全等级要求：ISO 26262 与 ASIL

做消费电子和做车规产品，最大的区别就是功能安全。车钥匙虽然看起来是个小东西，但它直接关系到车辆的安全。如果钥匙在高速行驶时突然失效，或者被恶意攻击，后果不堪设想。

车钥匙的功能安全等级，通常参考ISO 26262标准。这个标准把安全等级分为ASIL-A到ASIL-D，D是最严格的。车钥匙一般要求ASIL-B或ASIL-A，具体看OEM的要求。

那ASIL-B对咱们的固件开发意味着什么？我列几个关键点：

• 单点故障容错：任何一个硬件或软件模块失效，都不能导致系统进入危险状态。比如，UWB模块坏了，钥匙必须能通过BLE或NFC完成开锁。
• 故障检测与响应：系统要能自我诊断。比如，我要求钥匙每100ms做一次“心跳检测”，如果连续3次没收到UWB的测距结果，就认为UWB模块故障，立即切换到BLE模式，并点亮一个故障指示灯。
• 安全机制：包括CRC校验、看门狗定时器、内存保护单元（MPU）等。我记得有一次，一个同事忘了在关键数据路径上加CRC，结果在EMC测试时，数据被干扰导致误判，差点没通过车规认证。

另外，还有一个容易被忽略的点：防中继攻击（Relay Attack）。传统的无钥匙进入系统很容易被中继器攻击——两个小偷拿着信号放大器，一个靠近车，一个靠近钥匙，就能把信号“接力”过去，把车开走。UWB之所以被选中，就是因为它能通过飞行时间（ToF）精确测量距离，中继器无法伪造时间戳。所以，在功能安全设计里，UWB的测距结果必须被当作“安全关键数据”来处理，任何篡改都要能被检测到。

好了，这一章的内容就这些。总结一下：PEPS是骨架，UWB+BLE+NFC是肌肉，功能安全是免疫系统。三者缺一不可。下一章，我会带你看看UWB的物理层和MAC层，咱们从最底层的信号开始聊。