PNX 技术白皮书 v1.0

摘要 #

PNX（Phone · Near · eXecute）是一种基于BLE低功耗蓝牙的解耦式无钥匙进入技术。本白皮书定义了PNX的技术架构、实现规范、测试标准与授权体系，旨在为行业提供一种可靠、低成本、可后装的数字钥匙解决方案。

PNX的核心思想是将数字钥匙流程中的"身份验证"和"执行开锁"解耦：验证自动完成，执行手动触发。用户携带手机靠近车辆时，系统自动完成身份识别与近场确认，但车门的最终开启需由用户主动按下车门微动开关来触发。这一设计保留了BLE方案低成本、高覆盖的核心优势，同时通过引入物理确认层，有效解决了传统BLE感应模式在复杂环境下的误触、罚站、抢锁等体验瓶颈。

本白皮书面向汽车后市场方案商、智能硬件开发者、车企配套部门及技术研究人员，提供从理论定义到工程实现的完整参考。

第一章 行业背景与问题定义 #

1.1 汽车数字钥匙技术演进 #

汽车钥匙的演进史，是一部"便利性持续提升、安全性动态平衡"的技术发展史。从物理钥匙到遥控钥匙，再到智能钥匙，每一次迭代都在减少用户操作负担。而数字钥匙——用手机替代实体钥匙——正成为行业公认的下一代标准。

当前主流数字钥匙技术路线包括三条：

• UWB（超宽带）：通过飞行时间测距实现厘米级定位，体验最佳，但硬件门槛高
• NFC（近场通信）：贴靠刷卡，可靠性高，但便利性不足
• BLE（低功耗蓝牙）：基于信号强度估算距离，车机原生支持，后装成本低

三条路线各有适用场景，不存在绝对的优劣之分。PNX基于BLE，定位是"在BLE生态内实现更可靠的解锁体验"，而非取代其他技术路线。

1.2 UWB数字钥匙：体验标杆与覆盖盲区 #

UWB数字钥匙是当前行业体验标杆。其技术原理基于ToF（飞行时间）测距，配合车内4-5个锚点天线，可实现分米级甚至厘米级的定位精度。基于这一精度，UWB方案能够支持自动迎宾、无感进入等高端体验，车辆在用户靠近到特定距离时自动解锁，进入驾驶舱后自动上电，全程无需掏出手机。

UWB的体验优势建立在以下前提之上：

• 车内预埋UWB锚点天线阵列
• 车机支持UWB协议栈
• 手机端具备UWB芯片

问题在于：以上三点对存量车型均为硬性门槛。UWB锚点天线需要在车辆生产阶段预埋，老车型无法后装；车机协议支持同样受限于出厂配置。以比亚迪为例，2024年发布的UWB数字钥匙适配列表仅覆盖汉EV创世版、唐DMP、海豹等新款高配，21款宋Plus DMI、22款汉DM-i等数百万存量车型均不在支持范围内。

换车不是一个现实的解决方案。UWB是未来的标准，但未来尚未覆盖今天的大多数车主。

1.3 BLE感应数字钥匙：普及方案与体验瓶颈 #

BLE低功耗蓝牙自2016年起逐步写入车机协议，目前主流车企的车机系统均已原生支持。BLE数字钥匙的后装方案采用OBD接口取电，即插即用，安装时间约10分钟，覆盖超过95%的车型。这一特性使BLE成为存量市场数字钥匙普及的最可行路径。

BLE感应模式的技术原理是基于单点RSSI（接收信号强度指示）信号强度来估算用户与车辆的距离。RSSI值越大（信号越强），判定距离越近；当RSSI超过设定阈值时，系统自动执行开锁。

但RSSI测距存在固有波动。以下因素会显著影响信号稳定性：

• 手机端因素：线程调度、后台程序抢占、熄屏休眠策略、系统省电模式、不同品牌蓝牙芯片功率差异
• 环境因素：地下车库电磁干扰、充电桩变频器、WiFi路由器同频段干扰、金属车身对信号的反射与吸收
• 人体因素：人体含水量高，对2.4GHz信号有明显衰减作用；手机放在裤袋与拿在手中，信号强度可能相差10dBm以上

在信号稳定的环境下，BLE感应模式体验流畅；但在信号波动时，系统无法可靠决策，导致三种典型问题：

• 罚站：用户已站在车边，但RSSI未达到阈值，车门不开启
• 误触：用户路过车辆三米外，RSSI因环境反射突然增强，车辆误解锁
• 抢锁：用户下车未远离，RSSI短暂下降，车辆提前上锁

1.4 问题本质：验证与执行的耦合 #

BLE感应模式的问题本质，在于验证层与执行层的深度耦合。

一个完整的无钥匙进入流程包含三个环节：

1. 身份验证：确认"你是谁"——系统识别手机UUID，验证车主身份
2. 存在确认：确认"你在哪里"——系统通过RSSI判断用户与车的距离
3. 执行开锁：执行"开门"——系统向车身控制域发送开锁指令

在感应模式中，以上三个环节全部由系统自动判断和串联。当信号稳定时，这一全自动链条运转流畅；但当信号波动时，系统在"存在确认"环节出现误判，进而导致"执行开锁"环节产生错误结果。

更关键的是，用户在这一链条中没有插手的节点。系统误触时用户无法阻止，系统罚站时用户只能等待。执行权完全交给了信号波动。

1.5 PNX的提出：解耦式无钥匙进入 #

PNX的提出，正是为了解决上述耦合问题。

核心思想极其简洁：验证自动、确认自动、执行手动。

具体来说：

• 身份验证（Phone）和存在确认（Near）仍由系统自动完成——这是BLE的既有能力，无需改变
• 但执行开锁（eXecute）从"系统自动"改为"用户手动"——通过车门微动开关，由用户物理按下后触发

这一解耦设计的好处是：信号波动只影响前两层（验证和确认的速度与精度），但不再影响第三层（执行的可靠性）。因为执行由用户主动触发，与信号波动无关。

PNX的目标不是超越UWB，而是在BLE生态内，用最低的成本、最高的兼容性，实现"可控的可靠体验"。

第二章 PNX技术定义与架构 #

2.1 PNX命名释义 #

PNX由三个字母组成，分别对应技术架构的三个层级：

• P = Phone（手机验证）：手机作为数字身份令牌。蓝牙连接建立后，模块通过UUID验证手机身份，确认"你是授权用户"。这一过程无感完成，无需掏手机、无需亮屏、无需打开APP。
• N = Near（近场确认）：系统通过蓝牙RSSI信号强度判断用户与车辆的物理距离。只有RSSI值进入预设阈值范围，系统才判定用户"在场"，并为执行层做准备。未进入范围则不具备开锁资格。
• X = eXecute（手动执行）：验证和确认均自动完成后，执行权交到用户手中。用户按下门把手微动开关，系统才正式向车身控制域发送开锁指令。

X同时承载两层延展含义：

• eXact（精确）：精确控制，不误触、不罚站，精确到用户按下的那一刻
• eXplore（探索）：手机靠近，无限可能。PNX不仅是一把钥匙，更是智慧出行的入口

在对外传播中，首屏主推eXecute；技术拆解板块中，eXact和eXplore作为X的丰富内涵自然带出，不喧宾夺主。

2.2 三层架构模型 #

PNX的技术实现基于三层架构模型，每层有明确的职责边界和数据流方向。见图2-1。

Layer 1：身份验证层（Phone）

• 输入：手机BLE广播信号
• 处理：模块扫描附近BLE设备，匹配UUID白名单
• 输出：验证通过/不通过
• 时序特征：通常在1-3秒内完成，取决于手机蓝牙响应速度

Layer 2：存在确认层（Near）

• 输入：已验证手机的实时RSSI值
• 处理：持续监测RSSI，与预设阈值比较
• 输出：进入有效范围（微动开关带电）/ 未进入（微动开关不带电）
• 阈值设定：开锁阈值建议-65dBm（典型值），上锁阈值建议-80dBm（典型值）

Layer 3：执行触发层（eXecute）

• 输入：微动开关的物理按下信号
• 前提：Layer 1验证通过且Layer 2确认在场
• 处理：边沿检测开关信号，消抖处理后发送开锁指令
• 输出：车身控制域执行开锁/上电
• 时序特征：从按下到执行，典型延迟≤200ms

三层之间的耦合关系：Layer 3的执行以Layer 1和Layer 2的通过为前提，但Layer 3的触发不依赖于持续的RSSI稳定性。一旦用户按下开关，即使此时RSSI短暂波动，执行指令也会正常发出。

2.3 PNX与现有技术的关系 #

需要明确的是，PNX不是独立的通信协议。PNX基于BLE协议栈，在BLE的链路层之上构建了应用层的交互范式。这意味着：

• PNX不替代BLE，而是基于BLE
• PNX不定义新的无线电通信规范，而是定义"何时允许用户手动触发"
• PNX与UWB、NFC、BLE感应模式并列，属于应用层解锁方式的一种

2.4 核心设计原则 #

PNX的设计遵循三条核心原则：

默认安全（Secure by Default）

系统的默认状态是"不连接、不应命、不开锁"。只有明确满足三层条件时，才允许进入下一步。任何一层失败，系统退回安全状态。

用户主权（User Sovereignty）

执行开锁的最终决定权始终由用户物理动作触发。系统可以建议、可以准备，但不能代替用户按下开关。这一原则确保了用户对车辆的绝对控制权。

向后兼容（Backward Compatible）

PNX不强制取代感应模式。用户可通过APP一键切换"感应模式"与"PNX模式"，或在PNX模式下关闭感应、纯用微动。这种兼容设计尊重了不同用户的习惯差异。

第三章 技术实现规范 #

3.1 硬件要求 #

BLE模块

• 协议版本：BLE 5.0及以上（向下兼容4.2）
• 工作频段：2.400–2.4835 GHz（ISM频段）
• 发射功率：建议可调，典型值0–8 dBm

增益天线

• 类型：外置PCB天线或陶瓷天线
• 增益：典型值2–3 dBi
• 建议位置：模块置于车内隐蔽处，天线朝向车门方向，避免金属遮挡

微动开关接口定义

OBD取电与车身信号检测规范

• 供电电压：DC 12V（车辆电瓶电压，典型范围10.5V–14.5V）
• 典型工作电流：模块待机≤10mA；蓝牙广播峰值≤80mA（典型值，持续时间<100ms）
• 接口标准：符合OBD-II 16针D型接口，取常电引脚（Pin 16）与接地（Pin 4/5）
• 车身信号检测：并线检测车机开关锁状态，电压范围建议0V–12V，采用高阻输入（≥10kΩ），避免影响原车电路

3.2 软件协议 #

蓝牙配对与UUID验证流程

1. 模块上电后进入BLE广播状态，广播间隔建议100ms–500ms（可配置）
2. 授权手机靠近后，用户手动发起系统蓝牙配对
3. 配对完成后，模块记录该手机的UUID至白名单存储区
4. 后续使用中，模块持续扫描白名单UUID；匹配成功后建立连接，进入Layer 1验证通过状态
5. 模块建议支持8–10组UUID白名单（典型值），满足家庭多用户场景

RSSI阈值设定规范

需要说明的是，RSSI与物理距离的映射关系并非绝对。开阔地面上-65dBm可能对应1.5米，但在地库中可能对应1米或2米。因此阈值应以实际测试结果为准，建议值仅供参考。

感应距离档位

• 档位范围：1–15档
• 档位含义：对应模块蓝牙发射功率等级，非物理距离绝对值
• 建议日常使用：6–8档（平衡感应灵敏度与功耗）
• 地库/强干扰环境：可适当调高至10–12档
• 开阔地面/远距离停车：6–7档即可

微动模式触发逻辑

• 前提条件：蓝牙已连接且UUID验证通过（Layer 1通过）
• 触发方式：开关信号边沿检测，可配置为下降沿触发（低电平有效）或上升沿触发（高电平有效）
• 独立机制：微动触发不依赖Layer 2的RSSI阈值判断。只要Layer 1满足，微动即可响应。这意味着即使RSSI因波动短暂低于阈值，已连接状态下的微动仍然有效
• 响应时序：从物理按下到向车身控制域发送开锁指令，典型延迟≤200ms

3.3 安全机制 #

设备绑定：UUID白名单

模块仅响应白名单内UUID的蓝牙连接请求。白名单存储于模块非易失性存储器中，掉电不丢失。建议最大支持8–10组UUID（典型值），满足家庭多用户场景。

通信加密

BLE链路层采用AES-128加密，符合蓝牙核心规范5.0及以上版本要求。配对过程中的密钥交换通过标准BLE配对流程完成。

防重放攻击

每次关键通信（如参数修改指令）附带时间戳与随机数（Nonce）。模块校验：

• 时间窗口：建议±30秒，超出窗口的指令拒绝执行
• Nonce唯一性：模块记录最近收到的Nonce列表，重复Nonce的指令拒绝执行

异常处理

• 信号丢失：蓝牙断开连接超过3秒（典型值），系统自动撤销微动待命状态，已带电的微动开关恢复断电
• 多次错误触发：连续5次无效按下（如在未连接状态下误触），模块锁定微动检测5秒，防止恶意试探
• 设备全部脱离：当白名单内所有设备均远离至RSSI低于上锁阈值，系统自动执行关锁并下电

3.4 小程序/APP接口规范 #

蓝牙名规范

蓝牙广播名称必须为纯英文或数字组合，最大长度15字节，不允许包含中文、空格或特殊符号（如@、#、&等）。原因是部分手机蓝牙栈对非ASCII字符存在兼容性问题，可能导致搜索不到设备。

密码规范

配对密码必须为6位纯数字。密码修改后需写入非易失性存储器，并建议模块重启后生效。忘记密码的恢复方式：短接芯片特定焊点进行硬件重置。

参数配置接口

小程序/APP通过BLE GATT Characteristic进行参数读写。可配置参数包括：

• 蓝牙广播名称
• 配对密码
• 开锁/关锁动作模式（点动模式/常通模式）
• 开锁/关锁点动时间（单位：毫秒）
• 关锁延时执行时间（单位：毫秒）
• 蓝牙连接距离（1–15档）
• 开锁距离阈值（0–100）
• 关锁距离阈值（0–100）
• 感应模式开关（启用/禁用）

BLE单一通道规则

系统蓝牙配对连接与小程序BLE连接占用同一射频通道，二者互斥。因此每次进入小程序修改参数前，必须先断开系统蓝牙配对；保存参数后退出小程序，重新在系统蓝牙中配对，才能恢复正常使用。这一流程虽增加一步操作，但避免了通道冲突导致的连接失败。

第四章 场景验证与测试标准 #

4.1 标准测试环境定义 #

为保证测试结果的可复现性，PNX测试需在以下四种标准环境中进行：

• 开阔地面停车场：无遮挡、无强电磁干扰源，作为基准测试环境
• 地下多层车库（B2/B3）：典型电磁干扰环境，包含充电桩、变压器、通信基站、金属结构密集反射
• 雨天/高湿度环境：测试湿度对2.4GHz信号的传播影响，以及模块密封防护等级（建议IP54及以上）
• 多车并排场景：相邻车辆均安装BLE设备，测试蓝牙信号串扰与UUID误判概率

4.2 测试项目与通过标准 #

以下测试项目与通过标准均为建议值，实际测试应根据具体车型和安装条件调整。

4.3 PNX vs BLE感应模式对比测试数据 #

建议采用以下对比测试方法：同车型、同环境、同手机，分别运行BLE感应模式与PNX模式各100次，记录关键指标。

记录指标包括：

• 成功率：靠近后成功开锁的次数占比
• 误触率：未意图开锁时发生开锁的次数占比
• 平均响应时间：从进入有效范围到车门解锁的平均耗时
• 用户主观评分：测试员对可控感、可靠性的1–5分评价

典型预期分析（非实测数据）：

• 在成功率维度，PNX模式与BLE感应模式应接近，二者均依赖BLE连接建立，差异不大
• 在误触率维度，PNX模式理论上应显著优于BLE感应模式，因为误触需要"误触发RSSI+用户按下"同时发生，概率极低
• 在用户主观可控感评分维度，PNX模式因执行权在用户手中，预期评分显著高于BLE感应模式

以上预期需通过实际测试验证。本白皮书不声称任何未经测试验证的性能指标。

4.4 用户场景验证 #

场景A：日常通勤（高频使用）

用户每天多次使用，对响应速度和一致性要求最高。测试重点：连续7天、每天4次以上的长期使用稳定性，监测是否存在偶发罚站或响应延迟增加。

场景B：商场地库（复杂电磁环境）

地库中存在充电桩变频器、监控摄像头、WiFi路由器等同频段或谐波干扰源。测试重点：在RSSI波动较大的环境下，PNX微动模式是否能稳定触发，感应模式是否需关闭以避免误触。

场景C：临时下车（不熄火、车上有人）

用户下车买水，车门未关严，车上仍有乘客。测试重点：关闭感应模式，纯用微动模式，验证人未远离时车辆不会自动上锁，乘客不会被锁在车内。

场景D：代客泊车/洗车（钥匙移交）

用户将车辆交给代驾或洗车工。测试重点：多设备管理——车主手机保持白名单，临时授权代驾手机，验证临时授权的有效期管理与撤销机制。

第五章 PNX生态与授权体系 #

5.1 硬件兼容标准 #

PNX认证设备需满足以下硬件兼容标准：

• BLE模块支持5.0及以上协议版本
• 支持外置增益天线或可外接天线接口
• 微动开关接口符合第三章电压/信号/时序规范
• OBD取电或等效12V常电供电能力
• 非易失性存储器容量≥32KB（用于存储UUID白名单与参数）

与第三方OBD设备的兼容性要求：若车辆已安装其他OBD设备（如行车记录仪、胎压监测），PNX模块的OBD取电线应具备足够的机械兼容性，避免物理冲突。

5.2 软件接口开放规范 #

小程序SDK接入标准（规划中）

PNX计划开放标准化小程序SDK，提供以下接口：

• 设备搜索与蓝牙连接管理
• UUID白名单增删改查
• 参数读写（阈值、档位、模式）
• 固件OTA升级

参数配置协议文档

基于标准BLE GATT服务定义，Characteristic UUID公开文档。开发者可使用任意标准BLE调试工具（如nRF Connect、LightBlue）直接读写参数，无需专用SDK。具体UUID定义与数据格式将在配套技术文档中发布。

5.3 品牌授权 tiers #

PNX授权体系分为三个层级，满足不同合作方的需求：

Tier 1：产品贴牌

• 适用对象：已有硬件生产能力的厂商
• 授权内容：使用PNX标识于产品包装与宣传物料
• 费用框架：建议按出货量阶梯定价，量级越大单价越低
• 支持内容：品牌标识使用规范、技术白皮书、基础技术支持（邮件/文档）

Tier 2：技术集成

• 适用对象：方案商、集成商、汽车后市场服务商
• 授权内容：接入PNX协议栈，开发兼容产品
• 费用框架：年费 + 按出货量比例分成（建议年费覆盖基础支持成本，分成比例根据产品形态协商）
• 支持内容：协议文档、参考设计原理图、远程技术支持、认证测试辅导

Tier 3：OEM合作

• 适用对象：车企配套部门、大型汽车电子厂商
• 授权内容：深度定制开发，可包括独家区域授权或独家车型授权
• 费用框架：根据目标区域/车型的市场规模单独议定，通常包含一次性开发费 + 年度授权费 + 单件授权费
• 支持内容：定制固件开发、联合实车测试、专属技术客服、产品迭代优先权

5.4 认证与标识 #

"PNX Compatible"标识

通过PNX兼容性测试的设备可获得"PNX Compatible"认证标识使用权。标识使用规范包括：

• 标识尺寸：最小高度不低于8mm（印刷品）或24px（数字界面）
• 标识颜色：主色#1565C0，反白版本用于深色背景
• 最小留白：标识四周留白不小于标识高度的1/4
• 禁止行为：不得拉伸变形、不得改变配色、不得在未认证产品上使用

认证流程

1. 提交硬件规格书与固件版本说明
2. 协议一致性测试（实验室环境）
3. 实车场景验证（至少覆盖开阔地面与地下车库两种环境）
4. 颁发认证证书，纳入PNX官网兼容设备列表

第六章 路线图与版本规划 #

6.1 技术路线图 #

PNX标准的发展遵循"稳定核心、渐进扩展"的原则。以下是2026-2028年的技术路线图：

6.2 版本历史 #

第七章 常见问题 FAQ #

Q1：PNX与BLE感应模式有什么区别？

BLE感应模式是"全自动"——系统根据RSSI自动判断并执行开锁。PNX是"半自动"——系统自动完成身份验证和近场确认，但执行开锁需要用户手动按下微动开关。PNX将执行权从信号波动交还给用户，消除误触和罚站。

Q2：PNX需要改装车辆吗？

PNX后装方案通过OBD接口取电，并线连接车门微动开关，不破坏原车线束。典型安装时间约10分钟，可由专业汽配店完成，也可自行安装（需一定动手能力）。

Q3：所有车型都支持PNX吗？

只要车辆具备OBD-II接口且车机支持BLE协议（2016年后的大部分车型），即可安装PNX方案。目前覆盖超过95%的存量车型。具体适配情况因车型年份和配置而异。

Q4：PNX会影响原车质保吗？

PNX为后市场配件，安装不破坏原车线束，不影响原车功能。但各车企质保政策不同，建议安装前咨询当地4S店或查阅质保条款。

Q5：PNX的安全性如何？

PNX采用BLE链路层AES-128加密，配合UUID白名单、防重放攻击机制、异常处理策略。执行层需物理按下开关，即使信号被截获也无法远程开锁。

Q6：可以同时使用PNX和原车钥匙吗？

可以。PNX与原车钥匙完全独立，互不影响。用户可根据场景选择使用方式。

Q7：PNX的功耗如何？会影响电瓶吗？

模块待机电流≤10mA，远低于车辆静态功耗（典型值20-50mA）。长期停放建议关闭模块电源或使用电瓶保护器。

Q8：如何参与PNX生态建设？

DIY爱好者可在GitHub提交实现案例；方案商可申请技术集成授权；车企可联系OEM深度合作。详见认证体系页面。

第八章 开发者资源 #

8.1 开源仓库

PNX官方GitHub仓库：github.com/blekey/pnx

仓库包含以下内容：

• PNX技术白皮书 Markdown 源文件
• 参考设计原理图（PDF）
• 示例固件代码（Arduino/ESP32框架）
• 兼容性测试用例与数据记录模板
• 社区贡献指南

8.2 开发工具推荐

• nRF Connect：Nordic官方BLE调试工具，支持GATT服务浏览与数据读写
• LightBlue：跨平台BLE调试工具，适合快速验证
• ESP32开发板：低成本BLE 5.0开发平台，适合原型验证
• 逻辑分析仪：用于捕获微动开关信号时序，验证消抖逻辑

8.3 社区支持

• GitHub Issues：技术问题、Bug报告、功能建议
• 技术博客：pnx.cn/blog 发布技术深度文章
• 邮件联系：dev@pnx.cn（开发者专用通道）

8.4 贡献指南

欢迎通过以下方式参与PNX标准建设：

• 提交Issue：报告问题或提出改进建议
• 提交PR：改进文档、补充测试数据、分享实现案例
• 撰写博客：分享PNX使用经验或技术分析
• 参与认证：将你的硬件方案提交兼容性测试

附录 #

附录A：术语表 #

附录B：参考文献 #

• Bluetooth SIG. Bluetooth Core Specification v5.3. 2021.
• IEEE. IEEE Std 802.15.4z-2020: Low-Rate Wireless Networks Amendment.
• CCC (Car Connectivity Consortium). Digital Key Release 3.0 Technical Specification.
• 中国汽车工业协会. 汽车数字钥匙技术发展白皮书. 2024.

附录C：版本历史 #

附录D：联系与反馈 #

• 官方网站：pnx.cn / blekey.com
• 技术合作咨询：请通过官网联系方式或邮件联系
• 白皮书反馈：欢迎通过官网提交勘误与建议，我们将在后续版本中致谢