物联网平台基础：ThingsBoard核心概念及平台架构
在开始使用ThingsBoard接入Modbus设备之前，必须先理解平台的核心抽象模型。ThingsBoard将物理世界中的设备、业务逻辑和用户界面抽象为几个关键实体：设备（Device）、资产（Asset）、租户（Tenant）、规则链（Rule Chain）和仪表板（Dashboard）。这五个概念构成了平台的数据模型、权限边界、自动化处理逻辑和可视化呈现的完整闭环。本章将深入剖析这些核心概念的本质、它们之间的层级关系，以及平台的整体技术架构，为后续的Modbus设备接入打下坚实的认知基础。
2.1 核心概念的本质与职责边界
ThingsBoard的五个核心概念并非孤立存在，而是围绕物联网数据的生命周期（采集→处理→存储→展示→控制）设计的。理解每个概念的职责边界，是避免后续配置混乱的关键。
2.1.1 设备（Device）——物理实体的数字孪生
设备是ThingsBoard中最基本的实体，代表一个物理设备（如Modbus RTU温湿度传感器、PLC控制器）在平台中的虚拟映射。每个设备拥有唯一的设备名称和设备配置文件（Device Profile），后者定义了设备的传输协议类型、告警规则和默认属性。
设备的数据模型包含三类核心数据：
- 属性（Attributes）：静态或半静态信息，分为客户端属性（设备上报）、共享属性（平台下发）和服务端属性（平台内部管理）。例如Modbus设备的从站地址、波特率可存为服务端属性。
- 遥测（Telemetry）：时序数据，如温度、湿度、电压等随时间变化的测量值。遥测数据是规则链处理的主要对象。
- 告警（Alarms）：由规则链根据遥测数据或属性变化触发的异常事件，具有严重级别（CRITICAL/MAJOR/MINOR/WARNING/INDETERMINATE）和状态（ACTIVE/CLEARED）。
2.1.2 资产（Asset）——业务对象的抽象
资产用于表示非设备类的业务对象，如一条生产线、一栋楼宇、一辆工程车辆。资产本身不产生数据，但通过关联关系（Relation）与设备绑定。例如，将3个Modbus电表设备关联到"1号车间"资产下，即可在资产层面查看整体能耗。
资产与设备的关系是多对多的：一个设备可以关联多个资产（如一个PLC同时属于"1号产线"和"A车间"），一个资产也可以包含多个设备。这种灵活性使得平台能够适应复杂的业务层级。
2.1.3 租户（Tenant）——多租户隔离的边界
租户是ThingsBoard实现多租户架构的核心。每个租户拥有独立的设备、资产、规则链、仪表板空间，租户之间数据完全隔离。在工业场景中，一个租户通常对应一个企业或一个项目现场。租户下可以创建多个客户（Customer），用于进一步细分权限（如不同车间管理员只能看到自己车间的设备）。
2.1.4 规则链（Rule Chain）——平台的大脑
规则链是一个可视化编程组件，用于定义数据的处理逻辑。它由一系列节点（Node）通过连线组成，数据从根节点流入，经过过滤、变换、动作等节点处理后，流向不同的分支。规则链的核心能力包括：
- 数据持久化：将遥测数据写入Cassandra或PostgreSQL等数据库。
- 告警触发：当温度超过阈值时创建告警。
- 设备控制：向设备下发RPC指令（如写Modbus寄存器）。
- 外部集成：通过HTTP、Kafka、MQTT等插件将数据转发至第三方系统。
2.1.5 仪表板（Dashboard）——可视化的窗口
仪表板是面向最终用户的图形化界面，通过拖拽组件（图表、仪表盘、地图、表格）展示设备遥测数据、属性状态和告警信息。仪表板支持别名（Alias）机制，可以动态绑定设备或资产，实现一个仪表板模板复用于多个设备。
2.2 平台整体架构与技术栈
ThingsBoard采用微服务架构（Monolith或微服务两种部署模式），核心组件包括：
| 组件 | 职责 | 与Modbus接入的关系 |
|---|---|---|
| Transport Layer | 处理设备连接协议（MQTT/HTTP/CoAP/LwM2M） | Modbus网关通过MQTT或HTTP将数据推送到此层 |
| Core Service | 设备管理、权限控制、RPC请求处理 | 管理Modbus设备的注册、凭证、RPC下发 |
| Rule Engine | 执行规则链逻辑，处理消息流 | 解析Modbus数据格式、触发告警、数据清洗 |
| Data Storage | 时序数据存储（Cassandra/PostgreSQL/SQL） | 存储Modbus采集的温湿度、压力等时序数据 |
| UI Web UI | 仪表板渲染、管理控制台 | 配置Modbus设备、设计可视化仪表板 |
2.3 实战场景：从设备接入到仪表板展示的完整链路
为了将上述概念串联起来，我们模拟一个实际的Modbus接入场景：某工厂需要将一条产线上的5台Modbus RTU电表接入ThingsBoard，实现能耗监控。
- 租户与客户创建：在平台中创建租户"XX工厂"，并创建客户"1号产线"。
- 设备注册：在客户"1号产线"下注册5台设备，名称分别为"Power_Meter_01"至"Power_Meter_05"。每台设备的服务端属性中设置Modbus从站地址（如1-5）和波特率（9600）。
- 资产创建与关联：创建资产"1号产线"，并将5台设备通过"Contains"关系关联到该资产下。
- 规则链配置：创建一条规则链，包含以下节点：
- 消息类型过滤器：仅处理"Post telemetry"消息。
- 脚本变换节点：将Modbus原始数据（如寄存器值）转换为工程单位（如kW·h）。
- 持久化节点：将转换后的数据写入数据库。
- 告警节点：当功率超过100kW时触发MAJOR告警。
- 仪表板设计：创建仪表板，添加"能耗趋势图"（展示5台电表的实时功率曲线）、"累计电量表格"和"告警列表"组件。通过别名绑定资产"1号产线"，实现自动展示该资产下所有设备的能耗数据。
msg.metadata.deviceName获取设备名称，再通过getAttributes节点动态读取配置，避免为每台设备单独编写处理逻辑。
2.4 常见误区与设计复盘
在实际项目中，初学者常犯以下错误：
- 混淆设备与资产：将Modbus网关（物理设备）和它所连接的传感器（业务对象）都注册为设备。正确做法是：网关注册为设备，传感器数据通过网关上报，传感器本身可建模为资产或设备属性。
- 忽略租户隔离：在开发环境使用默认租户"Tenant"，导致后续生产环境迁移时权限配置混乱。建议从项目启动就规划好租户和客户结构。
- 规则链过度复杂：将所有处理逻辑放在一条规则链中，导致排障困难。建议拆分为多条规则链，通过"规则链关联"节点解耦。
- 仪表板性能问题：在仪表板中直接查询原始遥测数据，当数据量大时加载缓慢。应使用聚合函数（如AVG、MAX）或预聚合规则链节点。