第14章 物模型设计：属性、服务与事件
玩转工业物联网平台 · 章节 14/30 · 40 学时
14.1 采集模型（物模型）概述
采集模型管理是数晰IOT平台的核心功能之一，用于定义设备的抽象数据模型，也就是"物模型"。物模型是对物理设备的数字化抽象，将设备的功能、参数、事件标准化定义，使平台能够统一理解和管理不同类型、不同品牌的设备。
💡 为什么需要物模型？
工业现场设备品牌众多、协议各异，每个设备的数据格式和含义都不一样。如果没有统一的模型，平台需要为每个设备单独开发适配程序，成本高、维护难。
物模型的作用就是将不同设备的功能抽象为统一的标准定义：不管是什么品牌的空压机，它的"排气温度"在物模型中都是一个float类型的属性，单位是℃。这样平台上层应用（仪表盘、告警、数据分析）只需要基于物模型开发，不需要关心底层设备的差异，大大降低了开发和维护成本。
14.2 物模型的三要素
数晰IOT平台的物模型包含三种类型的功能定义，对应设备的三种能力：
| 类型 | 英文 | 说明 | 典型示例 |
|---|---|---|---|
| 属性 | Property | 设备的状态和参数，可读取或可设置 | 温度、压力、电流、功率、设备运行状态、运行模式 |
| 服务 | Service | 设备可执行的操作，可被调用 | 启动设备、停止设备、重启、参数设置、校准、复位 |
| 事件 | Event | 设备主动上报的事件信息 | 告警事件、故障事件、状态变化、数据上报 |
14.2.1 属性（Property）
属性是设备最基本的功能，表示设备的某个状态或参数。属性分为：
- 只读属性（r）：只能读取，不能修改，如温度、压力、电流等测量值
- 读写属性（rw）：既可以读取也可以修改，如设备运行模式、设定温度、告警阈值等
属性的数据类型支持：
- int：整数（有符号/无符号，8/16/32/64位）
- float：浮点数（单精度/双精度）
- bool：布尔值（true/false，0/1）
- string：字符串
- enum：枚举值（如运行状态：0=停止，1=运行，2=故障）
- struct：结构体（多个属性的组合）
- array：数组（同一类型的多个值）
每个属性还可以配置：
- 单位：℃、kPa、m³/h、kW、kWh、A、V等
- 取值范围：最小值、最大值，用于异常值判断
- 步长：数值变化的最小步长
- 描述：属性的详细说明
14.2.2 服务（Service）
服务表示设备可以执行的操作，由平台或应用调用，设备执行后返回结果。
服务的定义包括：
- 服务名称：如"启动设备"、"设置温度"
- 服务标识符：唯一标识，如"start"、"setTemperature"
- 输入参数：调用服务时需要传入的参数，如设置温度需要传入目标温度值
- 输出参数：服务执行后返回的结果，如执行成功/失败、返回值
- 描述：服务的详细说明
典型服务示例：
- start：启动设备，无输入参数，输出执行结果
- stop：停止设备，无输入参数，输出执行结果
- setTemperature：设置目标温度，输入参数为目标温度（float），输出执行结果
- reset：复位设备，无输入参数，输出执行结果
- calibrate：校准传感器，输入参数为校准值，输出执行结果
14.2.3 事件（Event）
事件是设备主动上报的信息，通常在特定条件下触发，不需要平台轮询。
事件的定义包括：
- 事件名称：如"温度过高告警"、"设备故障"
- 事件标识符：唯一标识，如"highTempAlarm"、"deviceFault"
- 事件类型：信息（info）、告警（alert）、故障（fault）
- 输出参数：事件携带的数据，如告警值、告警时间、故障代码
- 描述：事件的详细说明
典型事件示例：
- highTempAlarm：温度过高告警，事件类型=告警，输出参数包括当前温度、阈值
- deviceFault：设备故障，事件类型=故障，输出参数包括故障代码、故障描述
- statusChange：状态变化，事件类型=信息，输出参数包括旧状态、新状态
- dataReport：数据上报，事件类型=信息，输出参数包括一批采集数据
📋 实战案例：空压机的物模型设计
以一台工业螺杆式空压机为例，设计它的物模型：
属性（Property）：
| 名称 | 标识符 | 数据类型 | 读写 | 单位 | 范围 |
|---|---|---|---|---|---|
| 运行状态 | runStatus | enum | r | - | 0=停止,1=运行,2=故障,3=待机 |
| 运行模式 | runMode | enum | rw | - | 0=本地,1=远程,2=自动 |
| 排气温度 | dischargeTemp | float | r | ℃ | 0~150 |
| 排气压力 | dischargePressure | float | r | MPa | 0~1.6 |
| 运行电流 | current | float | r | A | 0~200 |
| 累计运行时间 | totalRunTime | int | r | 小时 | 0~999999 |
| 加载时间 | loadTime | int | r | 小时 | 0~999999 |
| 目标压力 | targetPressure | float | rw | MPa | 0.6~1.2 |
| 高温告警阈值 | highTempThreshold | float | rw | ℃ | 80~120 |
服务（Service）：
| 名称 | 标识符 | 输入参数 | 输出参数 |
|---|---|---|---|
| 启动 | start | 无 | result(bool), message(string) |
| 停止 | stop | 无 | result(bool), message(string) |
| 设置目标压力 | setTargetPressure | pressure(float) | result(bool), message(string) |
| 复位故障 | resetFault | 无 | result(bool), message(string) |
事件（Event）：
| 名称 | 标识符 | 类型 | 输出参数 |
|---|---|---|---|
| 高温告警 | highTempAlarm | 告警 | temp(float), threshold(float), time(datetime) |
| 设备故障 | deviceFault | 故障 | faultCode(int), faultDesc(string), time(datetime) |
| 状态变化 | statusChange | 信息 | oldStatus(enum), newStatus(enum), time(datetime) |
物模型设计完成后，平台就可以基于这个模型：
- 自动生成设备实时数据展示页面
- 配置告警规则（如排气温度>100℃告警）
- 搭建仪表盘（展示温度、压力、电流趋势图）
- 远程控制设备（启动/停止、设置参数）
- 数据分析和报表生成
14.3 物模型设计方法论
14.3.1 设计原则
- 标准化：尽量使用行业标准定义，参考OPC UA、ISA-95等标准模型，避免自定义不规范的模型
- 完整性：覆盖设备的所有关键功能和参数，不要遗漏重要的测点
- 简洁性：不要定义无用的属性和服务，保持模型简洁，减少维护成本
- 可扩展性：预留扩展空间，设备升级增加新功能时可以方便地扩展模型
- 语义清晰：属性和服务的命名要清晰、准确，让人一看就知道含义
- 分层设计：复杂设备可以采用分层模型，如"设备→部件→测点"的层级结构
14.3.2 设计步骤
- 需求分析：明确设备的用途、需要监控的参数、需要执行的控制、需要上报的事件
- 设备调研：收集设备手册、通信协议表、寄存器表，了解设备的所有功能和参数
- 属性定义：列出所有需要采集的参数，定义数据类型、读写权限、单位、范围
- 服务定义：列出所有需要远程执行的操作，定义输入输出参数
- 事件定义：列出所有需要主动上报的事件，定义事件类型和输出参数
- 模型评审：与设备厂家、运维人员、业务人员评审，确认模型完整准确
- 创建模型：在平台中创建采集模型，录入所有定义
- 测试验证：用实际设备测试模型，验证数据读取、服务调用、事件上报是否正常
14.3.3 常见设计错误
- 属性定义不全：遗漏关键测点，导致后期需要修改模型，影响已有数据
- 数据类型错误：如将浮点数定义为整数，导致精度丢失；将枚举值定义为字符串，导致无法比较
- 单位不统一：同类属性使用不同单位（如有的用℃有的用℉），导致数据无法对比
- 命名不规范：使用拼音、缩写、无意义的命名，导致其他人无法理解
- 读写权限错误：将只读属性定义为可写，可能导致误操作修改设备参数
- 模型过于复杂：定义了大量无用的属性和服务，增加维护成本和系统负载
14.4 采集模型管理操作
14.4.1 创建采集模型
- 进入"采集模型管理"→点击"新建模型"
- 填写模型基本信息：
- 模型名称：如"螺杆式空压机"
- 模型编号：唯一标识，如"MODEL-AIRCOMP-001"
- 设备类型：选择设备分类（压缩机、泵、风机、机床等）
- 所属厂商：设备生产厂家
- 型号：设备具体型号
- 描述：模型的详细说明
- 定义属性：点击"添加属性"，逐个录入属性定义（名称、标识符、数据类型、读写权限、单位、范围、描述）
- 定义服务：点击"添加服务"，录入服务定义（名称、标识符、输入参数、输出参数、描述）
- 定义事件：点击"添加事件"，录入事件定义（名称、标识符、事件类型、输出参数、描述）
- 点击"保存"创建模型
- 模型创建后，可以被多个设备引用（同型号的设备共用一个模型）
14.4.2 模型版本管理
采集模型支持版本管理，模型修改后会生成新版本：
- 版本号：采用语义化版本号（如v1.0、v1.1、v2.0）
- 版本说明：每次修改记录变更内容（新增了哪些属性、修改了哪些定义）
- 版本回滚：可以回滚到历史版本
- 设备绑定：设备绑定到特定版本的模型，模型升级后可以选择是否升级设备绑定的版本
⚠️ 模型修改注意事项：
- 模型修改会影响所有绑定该模型的设备，修改前要评估影响范围
- 不要删除已有的属性（会导致历史数据无法解析），可以标记为"已废弃"
- 修改数据类型可能导致历史数据解析错误，建议新增属性而不是修改已有属性
- 模型升级后要测试验证，确认设备数据正常后再批量升级设备绑定
- 重要修改要在业务低峰期执行，避免影响正常生产
14.4.3 模型模板与复用
- 平台预制了常见设备类型的模型模板（空压机、水泵、风机、机床、电表等），可以直接使用或在此基础上修改
- 支持将自定义模型导出为模板，分享给其他厂区或项目使用
- 支持模型继承，子模型可以继承父模型的所有定义，并在此基础上扩展
- 集团企业可以建立标准模型库，统一各厂区的设备模型定义，便于数据汇总和对比分析
14.5 物模型与数据采集的关系
物模型定义了设备"有什么数据"，数据采集配置定义了"怎么获取这些数据"。两者的关系：
- 先定义物模型：在采集模型管理中定义设备的属性、服务、事件
- 再配置数据采集：在标签管理/接口管理中，将物模型的每个属性映射到具体的协议数据点（如Modbus寄存器地址、OPC UA节点ID、MQTT消息字段）
- 数据采集执行：平台根据采集配置，从设备读取原始数据，按照物模型定义的数据类型、单位、换算倍率进行解析，得到标准化的数据
- 数据存储和展示：标准化后的数据按照物模型定义存储，上层应用（仪表盘、告警、分析）基于物模型使用数据
💡 物模型的核心价值：
物模型将"设备协议差异"和"上层应用"解耦。上层应用不需要知道设备用的是Modbus还是OPC UA，也不需要知道数据在哪个寄存器，只需要基于物模型的标准定义开发即可。
这意味着：更换设备品牌时，只需要修改数据采集映射，不需要修改上层应用；新增设备类型时，只需要定义新的物模型，上层应用可以快速适配。这大大降低了系统的开发和维护成本，提高了系统的灵活性和可扩展性。
14.6 行业模型标准参考
在设计物模型时，可以参考以下行业标准和规范：
| 标准/规范 | 说明 | 适用场景 |
|---|---|---|
| OPC UA | 开放平台通信统一架构，定义了工业设备的信息模型标准 | 工业设备建模、设备互操作 |
| ISA-95 | 企业控制系统集成标准，定义了企业层和控制层的对象模型 | 制造企业设备和生产建模 |
| RAMI 4.0 | 德国工业4.0参考架构模型，定义了工业4.0组件的模型 | 工业4.0系统设计和建模 |
| IoT平台物模型规范 | 各大云厂商（阿里云、华为云、AWS）定义的物模型规范 | 物联网平台设备建模 |
| 行业设备规范 | 各行业的设备数据模型规范（如电力行业的DL/T、水务行业的CJ/T） | 特定行业设备建模 |
对于初学者，建议：
- 先学习数晰IOT平台的物模型定义方法，掌握属性、服务、事件三要素
- 参考平台预制的设备模型模板，理解常见设备的建模方式
- 在实际项目中，先从简单设备开始建模，逐步积累经验
- 有一定基础后，可以学习OPC UA、ISA-95等行业标准，提升建模的规范性和专业性
14.7 本章小结
本章详细介绍了采集模型管理（物模型设计）。要点回顾：
- 采集模型（物模型）是对物理设备的数字化抽象，将设备的功能、参数、事件标准化定义，使平台能够统一理解和管理不同类型的设备。
- 物模型包含三要素：属性（设备状态和参数，可读写）、服务（设备可执行的操作，可调用）、事件（设备主动上报的信息）。
- 属性支持多种数据类型（int、float、bool、string、enum、struct、array），分为只读和读写两种权限。
- 服务定义包括名称、标识符、输入参数、输出参数；事件定义包括名称、标识符、事件类型、输出参数。
- 物模型设计遵循标准化、完整性、简洁性、可扩展性、语义清晰、分层设计原则，按照需求分析→设备调研→属性定义→服务定义→事件定义→模型评审→创建模型→测试验证的步骤进行。
- 采集模型支持版本管理、模板复用、模型继承，便于模型的维护和推广。
- 物模型定义了设备"有什么数据"，数据采集配置定义了"怎么获取这些数据"，两者配合完成设备数据的标准化采集。
- 物模型的核心价值是将"设备协议差异"和"上层应用"解耦，降低系统开发和维护成本，提高灵活性和可扩展性。
- 设计物模型时可以参考OPC UA、ISA-95、RAMI 4.0等行业标准。
下一章我们将讲解数据点配置与数据上报调试，学习如何将物模型的属性映射到具体的协议数据点，并验证数据采集是否正常。
📝 本章练习（5题）
答案与解析请在 互动学习看板 中作答查看。
📚 玩转工业物联网平台 课程目录（30 章）
- 第1章 什么是工业物联网（IIoT）
- 第2章 工业物联网与消费物联网的区别
- 第3章 工业物联网的核心价值与典型应用场景
- 第4章 工业物联网四层技术架构详解
- 第5章 数晰IOT物联平台概览与核心功能
- 第6章 工业数据采集的基本概念与重要性
- 第7章 常见工业传感器详解（温度/压力/流量/振动）
- 第8章 工业通信协议入门（Modbus/OPC UA/MQTT）
- 第9章 数据采集网关的作用、选型与配置
- 第10章 数晰IOT平台数据采集配置实战
- 第11章 数据采集常见问题与排查方法论
- 第12章 平台注册登录与界面导览
- 第13章 设备管理：添加设备、分组与标签
- 第14章 物模型设计：属性、服务与事件
- 第15章 数据点配置与数据上报调试
- 第16章 数据可视化：仪表盘搭建与图表配置
- 第17章 告警规则配置与多渠道通知
- 第18章 历史数据查询、导出与分析
- 第19章 OpenAPI接口与第三方系统对接
- 第20章 实战项目一：设备运行状态监控系统
- 第21章 实战项目二：工厂能耗数据采集与分析
- 第22章 实战项目三：生产环境温湿度监测系统
- 第23章 实战项目四：设备预测性维护基础应用
- 第24章 工业物联网与MES/ERP系统集成方案
- 第25章 工业物联网项目实施全流程方法论
- 第26章 工业物联网安全基础与最佳实践
- 第27章 设备运维与常见故障排查
- 第28章 数据质量保障与数据治理基础
- 第29章 工业物联网岗位图谱与能力要求
- 第30章 学习路径规划与职业发展建议