定义¶

设备三元组（涂鸦口径是 MAC + UUID + AuthKey，本项目口径是 PID + UUID + SECRET + MAC）"什么时候到设备 / 谁负责烧 / 烧到哪里"有三种主流工程范式：编译期硬编码 / 量产烧录 / 动态注册。三种各有适用场景，本页梳理三者技术对比 + 业界标杆 + Sentino BK7258 项目的选型推导。

三种范式速查¶

→ 三条路径并存，编译期硬编码当总开关 TRIPLE_TEST 决定走路径 1 还是 2/3，路径 2 vs 3 由设备扫到的厂测 AP SSID 决定。详见 Sentino BK7258 项目的实际实现 段。

范式 A：编译期硬编码¶

#define TUYA_DEVICE_UUID "5dhe05fCWFzd10tc"
#define TUYA_DEVICE_AUTHKEY "5e79e1ad1dc6394b..."

• 谁烧：开发者 / 烧录工具 / tyutool
• 粒度：要每片不同，必须每片重编固件——不可能
• 实际用途：只用于开发期 + 测试三元组——一份开发版固件配一份测试三元组，给一小批工程板用
• 成本：极低，但只支持一两片，不能量产
• Sentino 当前：项目里 TRIPLE_TEST 走的就是这条路径，开发期专用

→ 这条范式不解决量产问题，但是开发期通用入口。所有 IoT 项目都从这里起步，再演进到 B 或 C。

范式 B：量产烧录（行业主流）¶

云端三元组池                          PCBA 治具阶段
     │                                       │
     │ 1. 云端预先生成 N 个三元组             │
     │    （ProductKey 共享 + DeviceName/Secret 唯一）
     │                                       │
     ▼                                       ▼
  PC 治具工具 ──acquire── 拿出 1 个 ──UART AT── BK7258
                                              │
                                              │ 2. 固件执行 AT+TRIPLE 把 KV 写到 EasyFlash
                                              ▼
                                          Flash 持久化
                                              │
                                              │ 3. 治具 reset + AT+QUERY 验证回读
                                              ▼
  PC 治具工具 ──activate── 销账 + 标记此码已烧 + 回填 USB ID/时间/结果

• 谁烧：代工厂治具操作员 + PC 工具
• 粒度：每片一码
• 失败处理：UART 通信失败 / Flash 写入失败 / 回读不一致 → 治具标 NG，码不销账，下次重试
• 核心特征：云端是三元组的 source of truth，工厂只持有"烧入"能力不持有"颁发"能力——这是行业标准

业界标杆 1：阿里云一机一密（独立核查 2026-05）¶

• 平台为每台设备颁发唯一密钥（DeviceSecret）
• 控制台支持两种激活码生成方式：
• 自动生成：平台生成 N 个 DeviceName + DeviceSecret，烧录到设备
• 批量上传：用 MAC / SN / IMEI 当 DeviceName，平台为每个生成 DeviceSecret
• 单产品上限 50 万台
• 阿里官方推荐方案，安全性最高，但要求对产线工具改造——每片烧不同凭证

业界标杆 2：涂鸦 PMS（独立核查 2026-05）¶

• 涂鸦智慧生产管理系统（Production Management System）
• 生产凭证（Token）：产测授权工具读取，自动抓取指定数量授权码，随固件一起逐个写入设备
• 授权码清单：每个 UUID + 信息的表单形式，自行逐个写入
• acquire / activate 流程：云模组工具实时从云端 acquire → 烧 → activate 销账
• 两种工位区分：开发期用"原厂工具一次授权重复烧"；发布期用"生产凭证 + 一片一码"

→ 共同套路：云端三元组池 + PC 治具工具 + 治具 UART + 自定义 AT 协议 + 失败回收

范式 C：动态注册¶

设备出厂只烧 ProductKey + ProductSecret（产品级共享）
     │
     │ 首次上电 + 联网
     ▼
  设备 ──TLS HTTPS── 云端动态注册 API
                          │
                          │ 平台核对 ProductKey + 预注册的 DeviceName（如 MAC/SN/IMEI）
                          ▼
                     下发 DeviceSecret
     │
     ▼
  设备把 DeviceSecret 持久化到 Flash
     │
     ▼
  之后用三元组正常 MQTT 连接

• 谁烧：设备自己（在 Flash 里"长出来"）
• 优点：产线只需烧产品级凭证，所有设备共用一份固件——产线复杂度最低
• 缺点：
• 必须用 TLS——设备端无 TLS 能力直接出局
• 产品级密钥泄露风险高（一个泄露 = 全产品被仿冒）
• 阿里要求所有设备完成激活后手动关闭动态注册开关避免持续被攻击
• 必须预注册每台设备的 DeviceName（MAC/SN/IMEI），不能完全裸激活
• 代表：阿里云一型一密预注册、AWS IoT Fleet Provisioning by Claim

阿里云一型一密的两个变种（独立核查 2026-05）¶

重要警告：一型一密关闭后已按一型一密烧录的设备无法再激活联网——产线方案一旦定下来不能轻易切换。

AWS IoT Fleet Provisioning by Claim¶

• 设备出厂烧一个 claim cert（产品级，所有设备共享）
• 首次连用 claim cert 申请独立 cert，5 分钟内换证
• 与阿里一型一密同源思路，但 AWS 更强调"短窗口换证"防护

Sentino BK7258 项目的实际实现¶

2026-05-11 修正说明：本节首版误把"AT+TRIPLE 路径"当作下一步、把范式 C 当作远期。代码核查后的事实是：三种范式都已实现，下文按实际代码改写。详见 mass-production-actual-implementation-2026-05-11。

代码里有三条并行路径，当前默认走路径 1（最近 commit "暂用犀云平台固定三元组测试" 印证）。

路径 1（范式 A）：编译期硬编码 — 当前默认¶

总开关：projects/beken_genie_plush_toy/main/rino_iot_process.h:23 #define TRIPLE_TEST。当前选 AI_TRIPLE_USE = 3（毛绒 2 / 犀云平台测试三元组），rino_iot_process.h:40, 49-53：

#define AI_TRIPLE_USE   3
#elif (AI_TRIPLE_USE == 3)//毛绒2 犀云平台
#define UUID_DEFAULT    "rn01CfeF467cA4fa"
#define SECRET_DEFAULT  "64b6e1807071418282bca87af114f69e"
#define MAC_DEFAULT     "444AD60C228F"

注入点：rino_iot_process.c:679-688 在 Rino_Iot_Sdk_Task 把这三个值塞进 test_tripl，调 Rino_Iot_System_Init(..., &test_tripl)。落盘：rino_dev_info.c:483-502 Rino_Load_Dev_Info() 比对 FLASH 里的旧三元组，不一致就 Rino_Save_Triple_Info_To_Flash() 覆盖。

→ 当前烧的是犀云平台测试三元组、不是 Sentino 自家三元组——临时测试态，连 Sentino 自家三元组的烧录链路都还没在跑。

路径 2（范式 B）：厂测 AP + UDP/MQTT 下发 — 已实现¶

宏关掉 TRIPLE_TEST 即启用。设备启动后扫 SSID !FT@IOT1#（pwd 31415926，factory_test.h:16-17）连厂测 AP，不是用自定义 AT+TRIPLE 命令。

厂测工具通过两种方式下发三元组（factory_test.h:30-31）：

• UDP：广播端口 40000、服务端监听端口 40001
• 厂测 MQTT：用户名 admin / 密码 LBy0LmKyg17NWtJ8，消息类型 thing.testing.burn

处理：factory_test.c:183-218 Factory_Set_Burn_Info_Callback： 1. PID 一致性校验（不一致拒绝） 2. FLASH 里已有有效三元组就拒绝覆盖（factory_test.c:198），避免重烧污染 3. 写入 → 应答 → Rino_System_Reset() 重启

路径 3（范式 C）：云端动态注册 — 2026-01-31 v1.0.5 已实现¶

设备扫到 !FT@IOT0#（factory_test.h:15）走动态注册分支。factory_dynamic_register.c 用设备唯一 ID 连云端动态注册 MQTT，向云请求三元组，云端下发后同样走 burn callback 落盘。

MQTT 接入点（factory_test.h:20-26）：

#if (CONFIG_VND_CAL_PROJECT == 1)//台湾板子域名
#define DEFAULT_MQTT_HOST                       "mqtt-iot.sentino.jp"
#define DEFAULT_MQTT_PORT                       1883
#else
#define DEFAULT_MQTT_HOST                       "mqtt.cetus-ai.com"
#define DEFAULT_MQTT_PORT                       2883
#endif

版本溯源：rino_iot_process.h:18 #define DEV_VERSION "1.0.5" //20260131 新增动态注册，优化产测。真实驱动力：宣德产线生产 Blisoo 产品时发现工厂 WiFi 无法连接外网（路径 3 当时也连不通），所以加了"白板首次激活"分支以备未来对接其他能联网的产线。

SSID 切换的工程含义¶

→ 0 / 1 后缀的工程含义就是"白板 vs 烧过的板"两种工位区分。产线只需根据物料状态选 SSID，固件自动走对应分支。

真正的产品缺口：离线烧录通道¶

3 条路径全部要在线：

• 路径 1：编译期不要在线，但每片烧固件就覆盖身份，不实用做量产
• 路径 2：要厂测 PC + 厂测 MQTT/UDP 服务在线（产线侧 LAN 内即可，但 broker 也要起来）
• 路径 3：要外网到 mqtt-iot.sentino.jp:1883

而宣德工厂 WiFi 不能连外网 → 路径 3 直接不可用，路径 2 要工厂内自己起 MQTT 服务。

→ 真正缺的是离线烧录通道：譬如治具串口直接喂三元组到固件、固件本地校验后写 FLASH，不需要任何网络（既不需要 WiFi 也不需要外网 MQTT）。这是 beken-at-server 框架未来可能的应用场景，但当前没实现。

设计三元组烧录方案的常见错误¶

相关概念¶

• iot-mass-production — 量产工位 + 治具物理形态（本页是其"凭证灌入"细节）
• beken-at-server — 范式 B 的具体技术通道（自定义 AT 命令 + EasyFlash KV）
• tuya-triplet — 涂鸦体系的三元组定义（MAC + UUID + AuthKey，PID 不在三元组内）
• iot-device-bootstrap — "首次上电连谁"，与范式 C 动态注册路径同源
• device-lifecycle — "出厂"环节的具体填充（生命周期 6 阶段第 1 阶段）
• iot-platform-fundamentals — 量产 / 烧录在 IoT 体系的位置
• sentino-iot — 量产链路接通是 Sentino IoT 走向 OEM 客户的关键缺口
• bk7258-firmware — 目标芯片