- tags
- [IoT, 嵌入式, 协议, 设备影子, 物模型, 架构]
- created
- 2026-04-24
- updated
- 2026-04-24
- sources
- [raw/snippets/bk7258-build/iot-architecture-onboarding.md]
定义¶
IoT 平台基础知识层:用互联网后台世界的概念做类比,把 IoT 体系里"和后台不对应的几件事"讲清楚——配网、物模型、设备影子、设备生命周期、MQTT 长连接、Flash 持久化、嵌入式资源约束。这是 sentino-iot 系列概念页(mqtt-device-protocol / ble-provisioning / device-lifecycle / agora-rtsa-sdk)的"上位上下文页"——后台背景的工程师读 Sentino IoT 任何具体技术页之前,应该先在这里建立类比直觉。
后台 vs IoT 概念对照(核心知识资产)¶
| 后台世界 | IoT 世界 |
|---|---|
| 用户 | 设备 (device) |
| 注册账号 username/password | 设备三元组 pid + uuid + secret(涂鸦体系是 MAC + UUID + AuthKey,详见 tuya-triplet) |
| 登录拿 JWT | 设备启动用 secret 算 HMAC-SHA1 作为 MQTT password |
| HTTP request/response | MQTT publish/subscribe(长连接 + topic) |
| 数据库表 schema | 物模型 (Thing Model):声明设备属性、命令、事件 |
| REST 字段 | DP 点 (Data Point):物模型里的具体属性 |
| OAuth 授权 | 配网 (Provisioning):APP 通过蓝牙下发 WiFi + 用户绑定(详见 ble-provisioning) |
| 服务发现/注册中心 | 厂测时动态注册 + 设备启动时的 引导服务器查询 |
| Spring DI | import callback 注入(详见 embedded-firmware-layering) |
| Hexagonal/Ports & Adapters | 嵌入式 import/export 适配层等价物 |
→ 这套对照是后台工程师快速进入 IoT 工程的最短路径。
端-边-管-云四层模型¶
应用层 (APP / 小程序 / SaaS / 大屏)
↑
云平台层 (设备接入 + 影子 + 规则 + OTA + 数据存储)
↑
管 (WiFi / 4G / 5G / NB-IoT / BLE / Zigbee)
↑
边 (家庭网关 / 边缘盒子) ← 可选,WiFi 设备一般不需要
↑
端 (MCU 固件 + 传感器/执行器)
sentino-iot 走的是"端 ↔ 管(WiFi) ↔ 云"直连模型,最简单。4G 形态见 iot-device-bootstrap。
IoT 行业按场景的五大类(决定技术栈)¶
| 类别 | 例子 | 联网方式 | 实时性 | 单价 |
|---|---|---|---|---|
| 消费 IoT | 智能音箱、扫地机、玩具、灯泡 | WiFi+BLE | 秒级 | 几十~几百 |
| 工业 IoT (IIoT) | 工厂传感器、PLC | 以太网/4G | 毫秒~秒 | 几百~几千 |
| 车联网 (V2X) | 车机、T-Box | 4G/5G | 毫秒级 | 几千 |
| LPWAN | 共享单车锁、水表、燃气表 | NB-IoT/LoRa | 分钟~小时 | 几十 |
| 蓝牙 mesh/Zigbee | 家居开关、温控器 | 短距 mesh | 秒级 | 几十 |
Sentino BK7258 + AI 玩具属于消费 IoT - WiFi 直连云方案。
设备影子(Device Shadow):IoT 解决"设备经常断线"的标准答案¶
APP 写云端 shadow.desired
↓
云端转 MQTT 推到设备(在线立刻执行,离线消息暂存)
↓
设备执行后上报 shadow.reported
↓
APP 读云端,永远有响应
→ 最终一致性,跟分布式后台一个套路。
含义:APP 不直接读设备,永远读云端;云端是 source of truth。这一条是 Sentino IoT 平台 REST API(rest-api-iot)"App 调云、不直连设备"的底层架构原因。
协议栈分类¶
设备 ↔ 云¶
| 协议 | 性质 | 用在哪 | 特点 |
|---|---|---|---|
| MQTT | 长连接 pub/sub | 90% 消费 IoT(Sentino) | 轻量、QoS 0/1/2、遗嘱消息 |
| MQTT-SN | UDP 上的 MQTT | LoRa/NB-IoT 弱网 | 不维护 TCP 状态 |
| CoAP | UDP + REST | 受限设备 | RFC 7252,"UDP 上的 HTTP" |
| LwM2M | CoAP 之上 | 运营商 NB-IoT | 自带设备管理对象模型;详见 iot-device-bootstrap 方案 E |
| HTTP(S) | 短连接 | OTA 固件下载 | 不适合常态消息,适合大文件 |
| Modbus / OPC-UA | 工业总线 | IIoT、PLC | 工业领域绕不开 |
详见 mqtt-device-protocol(Sentino 的 MQTT 5.0 具体实现)。
业务层协议是另一回事¶
MQTT 只解决"传输",消息体格式由厂商定:
- 腾讯云 topic:$thing/up/property/{ProductID}/{DeviceName}
- 阿里云 topic:/sys/{productKey}/{deviceName}/thing/event/property/post
- Sentino 自定义 rlink event/command code
→ 后台熟悉的 OpenAPI / Protobuf schema,对应到 IoT 是物模型。
设备生命周期(IoT 的"DevOps")¶
详见 device-lifecycle。本页只点出配网 (Provisioning) 是 IoT 最特殊的环节——后台没对应概念。三种主流流派: 1. SoftAP 配网(早期主流,体验差) 2. BLE 配网(最主流,Sentino 用这个,详见 ble-provisioning) 3. 一键配网(SmartConfig/AirKiss)
安全模型:威胁与对策¶
设备物理可触达 → 攻击面比 web 大得多。
| 威胁 | 对策 |
|---|---|
| 假设备伪造身份连云 | 三元组 + HMAC 签名 |
| 中间人窃听 | TLS(MQTT 8883 端口) |
| 固件被刷恶意版本 | OTA 包签名校验、Secure Boot |
| Flash 被读出三元组 | 安全芯片 / eFuse / 硬件加密 |
| 配网过程被劫持 | 蓝牙配对 + APP 端校验 |
| 大规模僵尸网络 | 平台禁默认密码、强制证书 |
典型事故:2016 年 Mirai 僵尸网络利用 IP 摄像头默认密码(root/xc3511 / admin/admin 等 62 组),通过 Telnet 23/2323 端口扫描感染 60 万台 IoT 设备,9 月打挂 Krebs on Security(620 Gbps)+ OVH(1 Tbps),10 月通过 Dyn DNS 拖垮 GitHub/Twitter/Reddit/Netflix 半个北美互联网。
→ Mirai 之后 IoT 厂商被迫强制初次激活改密、设备证书替代默认凭证、平台扫描默认密码——IoT 安全标准从这次事件之后才被认真对待。
主流生态格局¶
国际¶
- AWS IoT Core / Azure IoT Hub
- Matter(Apple/Google/Amazon 共推标准)
国内¶
- 腾讯云 IoT Explorer(Sentino IoT 平台底层用的就是它)
- 阿里云 IoT (Link)
- 华为云 IoT
- 涂鸦智能 (Tuya):消费 IoT 的"代工厂"——Sentino IoT 走的是终端直调(rest-api-iot),是 Tuya 模式而非 AWS 模式
- 小米 IoT、百度天工
芯片厂软硬一体方案¶
- 乐鑫 ESP32 + ESP-IDF(最流行的开源 WiFi MCU)
- 博通集成 BK7258 + ARMINO(Sentino 选型,详见 bk7258-firmware)
- Realtek RTL87xx、联发科 MT76xx
嵌入式与后台的 7 条关键差异(后台同学最容易踩坑)¶
- 没有请求-响应,全是事件——MQTT 是长连接,下一条消息什么时候来不知道,处处是 callback + 消息队列
- 资源极度有限——栈 8KB、堆几百 KB、Flash 几 MB。"先加个缓存""日志全打"在这里要审慎
- Flash 是唯一的持久化——没数据库,重启数据靠 KV 存到 Flash 分区。三元组、配网信息、物模型都是这套路
- 任务 (Task) ≈ goroutine——但内存极有限,stack 都按 KB 算
- 消息队列 ≈ chan——是任务间通信主力(纯内存 FIFO,不是 Kafka)
- "重启就解决问题"是合法手段——配网超时直接
Rino_System_Reset()。这在后台是 anti-pattern,在嵌入式是标准做法 - 多任务共享同一片内存空间(不像 Linux 进程隔离),所以 mutex / 信号量必须用对——出错就是踩内存
→ 这 7 条决定了为什么 IoT 工程的代码风格、错误处理、状态管理与后台代码看起来"格格不入"。第 6 条尤其反直觉:在后台世界"自动重启 = 故障",在嵌入式世界"自动重启 = 健康自愈"。
在 Sentino 知识库中的位置¶
本页是 IoT 系列页面的上位上下文页——后台背景的人读 Sentino IoT 任何具体技术页(MQTT / BLE / 设备生命周期 / RTSA SDK)之前应先建立这一层类比直觉。同时本页与两个项目实战类新 concept 配对: - embedded-firmware-layering — 把上述"嵌入式没有 Spring DI / 类比 Hexagonal"具体到固件四层架构 + import/export 命名约定 - iot-device-bootstrap — 把上述"配网是 IoT 最特殊环节"延伸到 4G 设备没有蓝牙时的 5 种方案 + 信任根问题
相关概念¶
- sentino-iot — 本页是其后台视角入门
- embedded-firmware-layering — 嵌入式固件分层架构(import/export = Hexagonal)
- iot-device-bootstrap — 设备启动后第一个连谁(5 种 MQTT 接入点方案)
- mqtt-device-protocol — Sentino MQTT 5.0 具体实现
- ble-provisioning — Sentino BLE 配网具体实现
- device-lifecycle — 设备从出厂到日常的六阶段
- tuya-triplet — 设备三元组在涂鸦体系的具体形式
- bk7258-firmware — Sentino 选型的芯片厂软硬一体方案
- rest-api-iot — Tuya 模式(终端直调)的 App 端 API