IoT 接入与数据架构
约 4603 字大约 15 分钟
2026-10-27
IoT 能力把设备通信转换为产品、物模型、状态、历史和可执行动作,再向应用、自动化、可视化与 AI 提供统一业务接口。架构中需要同时理解接入上报、数据消费和下行控制三条链路。
设备接入成功说明通信链路具备了条件;历史可查、规则被触发、控制已执行等结果,还需要沿各自业务流程确认。
放大查看 SVG ↗ · 下载 SVG · 下载高清 PNG
1. 核心对象如何组织
| 对象 | 职责 | 与其他对象的关系 |
|---|---|---|
| 产品 | 定义一类设备的共同能力和接入约定 | 关联物模型、协议及相应产品配置 |
| 设备 | 表达一个实际接入对象及其身份 | 归属产品,并与项目、区域等业务范围关联 |
| 物模型 | 描述属性、事件、行为及参数结构 | 为上报校验、查询和控制提供业务语义 |
| 项目与区域 | 组织现场资源和授权范围 | 设备访问、列表、统计和控制沿用相应权限 |
| 协议适配 | 处理设备原生通信与平台语义的差异 | 在实际接入路径中完成身份、报文或指令转换 |
| 状态与历史 | 分别承接当前事实和时间序列记录 | 为界面、查询、规则与业务分析提供数据 |
| 命令与回执 | 关联下行请求和实际反馈 | 区分受理、设备应答、超时和状态变化 |
物模型给“这条消息意味着什么”提供共同定义。例如,一个数值在不同产品上可能具有不同字段、单位和含义。应用与 AI 应依据实际物模型和接口结果理解数据,不能只凭字段名称猜测业务含义。
2. 三种接入方式的边界
原生平台协议
能够按平台协议工作的设备,使用对应 MQTT / HTTP 接入入口。平台依据产品与设备身份处理认证、主题访问和标准消息,再进入设备业务流程。
第三方设备与独立协议服务
第三方设备可能具有专有连接、认证、报文和指令格式。独立协议服务按具体协议处理这些差异,再将设备消息映射为平台业务语义。现场网关与云云接入也需要使用其实际支持的通信方式和对象映射。
已接入载荷的协议脚本
协议脚本适合在已进入相应链路后完成字段、编码或载荷转换。建立连接、维持会话、完成专有认证和识别设备等工作,要由对应接入实现承担。选择脚本还是完整网关,应从通信差异出发。
| 需要处理的问题 | 主要观察位置 |
|---|---|
| 连接建立与断开 | 对应 Broker、HTTP 入口或协议服务 |
| 凭据与设备身份 | 产品、设备和实际认证路径 |
| 订阅或发布某个主题 | Broker 主题访问检查 |
| 原始载荷与平台字段不一致 | 对应协议适配与脚本处理 |
| 物模型参数或业务范围不满足 | 设备业务服务与授权检查 |
当前默认部署使用内置 MQTT;外接 EMQX 按配置选择。不同 Broker 路径的认证、订阅、发布和消息转发应分别核验,不能将 EMQX Webhook 视为所有设备的统一必经环节。
多协议接入与消息处理流程
多协议接入通过不同的接入实现,将设备身份、报文含义和控制动作对齐到同一套设备业务合同。通信差异由接入侧处理,物模型与数据业务由 dmsvr 承接。现场边缘网关先采集、汇聚子设备,再按它对外使用的协议进入相应分支。
放大查看 SVG ↗ · 下载 SVG · 下载高清 PNG
| 接入场景 | 谁管理连接或请求 | 在哪里适配 | 如何进入设备业务 |
|---|---|---|---|
| 原生 MQTT / HTTP | 对应内置接入入口 | 按标准身份与消息规范解析 | 通过内置消息路径交给设备业务,具体投递方式随配置装配 |
| 原厂 MQTT 协议 | Broker 与第三方 MQTT 协议服务分工 | 协议服务提供相应认证、主题授权、订阅与载荷转换 | 协议 SDK 封装设备消息,经事件通路进入 dmsvr |
| 私有 TCP / UDP | 对应协议服务 | 监听、建连、拆帧、校验、设备识别和指令编码 | 转为统一身份与标准消息后上报 |
| 工业规约与现场网关 | 采集服务或现场网关 | 通信规约、寄存器或点位、值类型、子设备映射 | 按实际对外协议选择原生接入或独立适配 |
| 云云对接 | 云云协议服务 | 云端授权、外部产品与设备 ID、回调或订阅、控制 API | 将云端事件转为设备消息,将平台控制转为外部云调用 |
图中没有把所有入口都接到一个必经的 NATS 节点。原生路径可以使用内置投递;独立协议服务通过 SDK 的事件通路上报和接收下发。默认与外接 Broker 的具体装配见部署架构与组件选型。摄像头媒体流还需要相应媒体链路,不能把视频数据理解为普通属性消息经总线存储。
协议服务如何与平台协作
- 登记协议与运行状态:协议服务启动时登记协议定义,持续报告服务状态;提供配置页的服务一并报告相应入口。协议已经出现在列表中,并不代表设备已通过认证或已有数据。
- 绑定产品、设备与配置:产品选择对应协议,配置连接、认证、采集或云端参数;协议适配建立外部对象与平台产品、设备的对应关系。网关场景另需维护网关、子设备和点位关系。
- 标准化上报:适配侧将原始数据转换为包含
ProductID、DeviceName、ProtocolCode、消息类别与载荷的设备消息。协议 SDK 的DevPubMsg写入协议标识并经事件通路发布,设备业务再按类型处理。 - 接收对应下行:协议服务通过 SDK 注册下行处理器,订阅与自身
ProtocolCode对应的下行主题,将标准控制转换为设备报文或外部云 API 调用。协议标识错误、订阅未启动或服务不可用,都会使指令无法到达正确实现。
这些职责可以由同一个协议服务实现,也可以按现场与云端边界组合。脚本负责已接入消息的转换和扩展,不替代 TCP 会话、专有登录、云端授权续期或设备重连管理。
普通 MQTT 设备如何认证和取得主题权限
当前内置 Broker 直接调用设备认证能力。普通设备首先尝试原生设备认证,未通过时,再向已登记且已经建立连接的第三方 MQTT 认证服务尝试认证;第三方尝试可以并发进行,任一成功即可通过。没有服务认可这组凭据时拒绝连接。内部受信服务具有单独的身份路径,不作为普通设备接入方式使用。
登录成功只确认连接身份,不能代替主题授权。发布与订阅还按主题及动作检查;原生访问检查未通过时,也会尝试对应第三方访问认证。外接 EMQX 使用它自身配置的认证、授权和转发入口,不能把上图解释为所有部署都必须经过 apisvr Webhook。第三方设备也不一定进入平台的内置 Broker:若连接原厂 Broker,则由协议服务按原厂方式订阅和访问。
协议脚本插在什么位置
| 位置 | 处理时机 | 常见用途 | 结果边界 |
|---|---|---|---|
UpBeforeTrans | 进入相应设备业务处理之前 | 字段重命名、二进制或 JSON 转换、单位与倍率计算 | 输出仍需符合对应设备消息和物模型约定 |
UpAfterTrans | 相应上报处理之后异步执行 | 联动、通知与后续扩展 | 异步副作用不等于设备主消息处理结果 |
DownBeforeTrans | 下发消息选择并进入对应通道之前 | 将业务参数转换为设备载荷 | 需要保持目标身份和协议路由正确 |
DownAfterTrans | 下发路径成功返回之后异步执行 | 记录、联动等扩展 | 此时不能据此判定设备已执行成功 |
脚本需要启用并绑定到对应产品或设备,还要符合消息匹配与触发条件。产品与设备脚本会按实际优先级组织执行;未配置脚本的设备不必经过一次人为编写的转换。协议网关与脚本的选择、绑定和开发分别见第三方协议接入、协议网关开发和协议脚本使用。
3. 从产品定义到设备可用
一类设备投入业务前,需要完成产品和物模型定义、设备身份准备、接入配置与业务归属,并用真实报文确认字段和反馈。
这是能力准备顺序,具体操作仍按设备接入指引完成。设备已经上线后,应继续检查上报值、类型、时间及项目范围,再进入业务使用。
4. 上行:从设备报文到业务事实
当前链路由 dmsvr 组织设备管理、消息处理、MQTT 宿主及对应状态与时序仓储。接入路径交付设备身份和消息,业务处理再按消息类型完成转换、校验和数据操作。
当前状态描述设备最近可用的事实,历史仓储保存按查询语义组织的时间记录,两者各有用途。业务事件又是独立消费通路:有历史记录,不等于某个订阅者已收到通知;当前界面有数值,也不意味着所需历史范围已完整保存。
各类型消息的写入、事件发布和异常处理顺序,以对应处理流程为准。跨仓储与消息机制的一致性需要按实际实现确认,不能从一张流程图推断统一事务。
5. 数据查询、实时订阅与业务分析
设备业务接口根据当前企业、项目、区域和对象范围读取状态或历史。历史查询还涉及字段、时间范围、聚合与单位等业务条件。具体接口是否支持某种聚合,应以它自己的合同为准。
一次查询返回空记录时,至少需要核对目标设备与字段、时间范围、数据是否已采集,以及当前访问范围。空结果不等于零值;超时或仓储错误也不能转写为“设备没有数据”。
WebSocket 用于接收相应频道的实时变化。客户端应处理订阅确认、重连和项目切换,将实时结果应用到当前范围。历史查询与实时订阅可共同服务界面,但使用不同的结果与生命周期。
AI 通过获准工具调用这些实际业务接口。需要解释现场趋势时,可以结合知识资料;具体设备记录仍来自设备业务查询,不由模型补造。
6. 下行:从控制请求到反馈
设备控制首先检查当前身份、对象范围、操作动作和物模型参数,再进入命令与协议路径。实际设备能力决定是否提供应答、执行状态或后续属性上报。
| 状态 | 已经确认什么 | 还需观察什么 |
|---|---|---|
| 接口已受理 | 当前请求通过相应业务处理并被接收 | 是否成功下发及设备是否反馈 |
| 已下发 | 指令进入相应接入或协议链路 | 设备是否收到、理解并执行 |
| 设备已应答 | 收到对应设备反馈 | 应答语义及实际状态是否符合目标 |
| 状态已变化 | 观察到相应属性或状态反馈 | 是否达到本次操作的业务预期 |
| 超时或错误 | 在当前条件下未得到预期结果 | 根据记录核对设备、网络与后续处置 |
批量控制需要逐个验证目标设备与获准字段。重试也应结合命令语义判断:查询、设置一个状态和触发一次动作,重复执行的影响可能不同。
7. 自动化、告警与专项能力
| 能力 | 消费或管理什么 | 与设备主链路的关系 |
|---|---|---|
| 规则与场景联动 | 配置的触发条件、判断与动作 | 按对应事件或数据触发后续业务 |
| 告警与通知 | 告警条件、对象、记录及通知 | 区分告警产生、通知发送与人员处理 |
| OTA | 固件、模块、升级任务和进度结果 | 设备按协议下载与执行,平台观察任务反馈 |
| 音视频 | 对应终端、媒体协议和控制配置 | 媒体通路与设备业务授权分别管理 |
| 物联卡 | 相应卡片资料、状态与业务操作 | 按所集成服务与模块使用 |
| 可视化与业务分析 | 设备状态、历史、统计与场景数据 | 通过获准接口和实时通道消费数据 |
专项能力按产品、设备和部署范围启用。某台设备支持属性上报,不代表它也支持 OTA、媒体交互或所有控制行为。
8. 分段判断问题落在哪里
| 现象 | 建议沿链路核对 |
|---|---|
| 无法连接 | 网络、设备凭据、Broker 或协议入口配置 |
| 能连接但消息不被处理 | 主题访问、协议订阅、报文格式、设备映射与物模型校验 |
| 第三方控制无法到达设备 | 产品与消息的 ProtocolCode、对应下行订阅、协议服务状态及设备连接 |
| 当前值存在但历史查不到 | 历史写入路径、字段、时间、仓储与访问范围 |
| 数据写入后界面未更新 | 业务事件、订阅授权、推送、连接和前端刷新 |
| 控制受理后无反馈 | 命令关联、协议下发、设备应答与超时记录 |
| 自动化没有执行 | 实际触发数据、规则条件、动作权限及执行结果 |
设备消息与控制合同继续阅读设备消息开发,权限模型见SaaS 与权限架构,组件选择见部署架构。
架构专题导航
平台总体架构 · 后端运行架构 · SaaS 与权限架构 · AI 与工具执行架构 · 前端与客户端架构 · 云边协同架构 · 部署架构与组件选型
更新日志
2026/10/27 13:22
查看所有更新日志
c4a4b-docs(架构): 独立平台架构分组并更新架构文图于93dfc-docs(架构): 独立平台架构分组并更新架构文图于
