
任何一个设备管理平台都要回答同一个问题一类设备能采什么、能控什么、会报什么。行业的通行答案是物模型Thing Model以产品为单位聚合属性、服务与事件。IoT DC3 的答案是模板Profile表dc3_profile中的一行记录就是一份能力模板。两者是同级抽象但模板是加强版物模型能表达的模板都能表达反之未必。这一以模板为骨架、聚合位号/命令/事件、由设备单一绑定构成的完整建模体系DC3 命名为语义模板Semantic Profile。为什么需要模板想象接入 100 台同型号的温湿度传感器 ZS-100。如果每台设备都单独配置温度位号、湿度位号、校准命令Command与故障事件Event那就是 100 份重复劳动修改一处要改 100 次。模板把能力定义从设备实例中抽出来沉淀成一份可复用的模型位号、命令、事件定义在模板上设备只引用模板。100 台传感器共享同一份定义能力变更只发生在模板这一处。类比产品与实物模板像产品说明书、出厂规格设备像按这份规格出厂的实物。说明书写一遍实物可以造很多台规格升级后续出厂的实物自然带着新规格。模板与物模型同级抽象更强能力模板与物模型都回答一类设备有哪些能力差异在平台化能力的叠加维度物模型行业通用模板 ProfileDC3能力聚合属性 / 服务 / 事件结构固定位号 / 命令 / 事件复用范围通常按产品固定共享范围三档租户 / 驱动 / 用户版本演进一般无显式版本version 显式版本可查询、随更新递增扩展方式结构相对固定profileExt 弱结构化扩展创建来源—系统 / 驱动 / 用户三档设备绑定视实现而定恰好绑定一个单一外键几个更强都有对应的字段支撑。共享范围profileShareFlag分三档tenant 租户内共享、driver 驱动内共享、user 用户私有一份模板能被谁复用由此控制而不是被产品边界锁死。创建来源profileTypeFlag分三档system 系统内置、driver 驱动创建、user 用户创建驱动注册时可以自带模板。version 随每次更新自动递增并作为乐观并发控制的条件并发修改冲突会被拒绝版本号本身还可作为查询条件。profileExt 是 JSON 弱结构化扩展字段可承载类别、标签等附加信息不必为每类新诉求改表结构。模板承载的三类能力模板聚合位号、命令、事件三类能力分别回答能采什么、能控什么、会报什么。位号是数据面的能力挂在dc3_point表归属字段 profileId 必填位号编码在租户与模板内唯一。命令是动作面的能力挂在dc3_command表分自定义、配置、动作三类调用分同步与异步超时以秒为单位默认 30 秒输入输出参数在dc3_command_param表单独定义包括方向输入/输出、类型、是否必填与默认值。事件是上报面的能力挂在dc3_event表分信息、告警、故障、生命周期四类级别分低、中、高、严重四档事件参数在dc3_event_param表定义。三类能力的编码都在租户 模板范围内唯一。需要澄清的是聚合与拥有的区别模板不存储任何一类能力的数据它只是归属根——位号、命令、事件都是独立实体靠各自的 profileId 外键挂回模板。模板对象上没有位号列表这类字段查询这个模板有哪些能力要分别查三张表。位号的运行态数据更与模板无关位号值按设备与位号落库属于设备实例本系列位号篇。两种建模思路模板该建多大是设备建模的第一个设计决策。仍以电驱动机为例两种典型思路如下。方案一大而全模板。一个电驱动机模板装下全部七个位号位号编码名称单位额定值MOTOR_SPEED转速RPM3000MOTOR_VOLTAGE电压V400MOTOR_CURRENT电流A150MOTOR_TEMPERATURE温度℃85MOTOR_TORQUE扭矩Nm250MOTOR_VIBRATION振动mm/s3MOTOR_FAULT_CODE故障代码—E101再配上启动、停机、设速三条命令与故障、越限两类事件一台设备绑定即得全量能力。代价在设备异构时显现经济型电机不带扭矩传感器模板中的扭矩位号对它是永远读不到值的冗余定义看板上多出一列空数据。方案二按关注点拆分模板。为不同关注点各建一个小模板监控类装转速、温度、振动能耗计量类装电压、电流、扭矩安全类装故障代码位号与紧急停止命令状态类装累计运行时间与最近维护日期。每类模板只含该视角需要的能力定义精确、无冗余。维度大而全模板按关注点拆分绑定成本一次绑定全量继承按设备角色选模板冗余风险异构设备背上无用位号基本无冗余能力组合天然齐备一台设备只能选其一定义数量模板少、单模板大模板多、单模板小取舍的关键约束是单绑定现行模型中一台设备恰好归属一个模板能力不能跨模板叠加。按关注点拆分的正确用法是为不同关注点建不同的小模板、每台设备按自身角色选绑其一而不是给一台设备叠加多个模板。既有监控需求又有能耗需求的设备要么回到一个更大的模板要么在设备组织层面用分组与标签承载视角差异。早期版本曾支持设备绑定多个模板的多对多关系现行模型已收敛为单一外键位号集合只来自所绑定的模板不跨模板混取。这换来的是能力来源的确定性——看到设备就知道它的全部能力从哪里来。模板与设备的关系模板与设备是类与实例的关系模板定义一遍设备接入多台。绑定通过dc3_device表的 profileId 单一外键完成设备的位号、命令、事件集合经模板联接解析——查一台设备的能力平台按设备.模板 能力.模板的路径取出该模板下的全部定义。100 台设备指向同一个模板共享同一份能力定义。连接与语义在模型上是正交的两层。模板描述设备有什么能力驱动描述用什么协议怎么连接同一份模板下的设备可以分别接 Modbus 与 OPC UA 驱动。连接参数按设备自持驱动级属性地址、端口与位号级采集配置从站、功能码、偏移量都挂在设备维度模板对这些一无所知。改一处、全局生效由此成立位号定义是模板上的单行记录所有引用设备共享。给 ZS-100 模板的温度位号加一个上限约束只需修改模板这一处100 台传感器同时生效模板版本随之递增定义变更以元数据事件广播到各驱动实例驱动刷新本地缓存后按新定义采集。删除同样受引用保护仍有设备引用的模板删除请求会被拒绝避免引用它的设备在一夜之间失去能力定义。适用范围与限制单绑定是硬约束。一台设备恰好归属一个模板跨模板组合能力不可行确有组合需求时应把能力收敛进一个模板或按角色拆分设备模板变更影响全部引用设备。位号定义修改对所有引用设备立即生效生产环境变更前需评估影响面并以版本号记录演进轨迹新增能力需要逐设备补配置。模板新增位号后每台设备还要补齐该位号的采集配置否则新位号不参与采集。定义继承是批量的连接配置始终是设备级的模板不承载运行态数据。位号值、命令历史、事件历史都按设备维度落库模板上只有定义跨设备的聚合统计需要按位号编码自行组织。结语物模型解决了一类设备的能力说一遍就够模板在此基础上叠加共享范围、版本演进与弱结构化扩展把一份能力定义变成可治理的资产谁可复用、改到第几版、还有哪些设备在引用都有明确答案。理解模板是类、设备是实例、单绑定保证能力来源确定DC3 的设备建模即可展开建一份模板接百台设备改一处定义全局生效。模板与位号、命令、事件共同构成的这套体系即 DC3 的语义模板Semantic Profile。PROMO_CARDIoT DC3· GitHub | Gitee | 文档 docs.dc3.site | 在线书 book.dc3.site | 演示 demo.dc3.site | 官网 dc3.site