🏠 home › concepts › iot-platform-fundamentals
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 安全标准从这次事件之后才被认真对待

主流生态格局

国际

国内

芯片厂软硬一体方案

嵌入式与后台的 7 条关键差异(后台同学最容易踩坑)

  1. 没有请求-响应,全是事件——MQTT 是长连接,下一条消息什么时候来不知道,处处是 callback + 消息队列
  2. 资源极度有限——栈 8KB、堆几百 KB、Flash 几 MB。"先加个缓存""日志全打"在这里要审慎
  3. Flash 是唯一的持久化——没数据库,重启数据靠 KV 存到 Flash 分区。三元组、配网信息、物模型都是这套路
  4. 任务 (Task) ≈ goroutine——但内存极有限,stack 都按 KB 算
  5. 消息队列 ≈ chan——是任务间通信主力(纯内存 FIFO,不是 Kafka)
  6. "重启就解决问题"是合法手段——配网超时直接 Rino_System_Reset()。这在后台是 anti-pattern,在嵌入式是标准做法
  7. 多任务共享同一片内存空间(不像 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 种方案 + 信任根问题

相关概念