2. IoT设备资产建模
设备资产建模的本质，是把物理世界中一台台形态各异的 IoT 设备，抽象成平台能够统一识别、检索、关联和治理的数据对象。如果建模做得粗糙，后续的标签管理、固件升级、故障定位、库存盘点都会失去可靠的数据基础。本节围绕资产属性的设计与数据字典规范展开，重点解决三个问题：一台设备应该被记录哪些属性、每个属性如何定义取值与约束、这些属性如何支撑生命周期状态流转。
一、资产属性的分层结构
IoT 设备资产属性不宜平铺罗列，而应按“身份标识—物理规格—软件版本—运行状态—管理归属”分层组织。身份标识解决“这台设备是谁”，物理规格解决“它是什么设备”，软件版本解决“它运行什么”，运行状态解决“它现在处于什么阶段”，管理归属解决“它归谁管、装在哪里”。
其中，设备类型、厂商、型号、序列号构成设备的最小身份四元组。设备类型是粗粒度分类，如“智能电表”“温湿度传感器”“工业网关”；厂商是生产或供应主体；型号是厂商内部的规格编号；序列号是单台设备的唯一标识。四者组合后，可以唯一定位一台物理设备。需要特别强调的是，序列号必须作为全局唯一键，不能仅靠“厂商+型号”代替，因为同型号设备可能批量部署成千上万台。
固件版本属于软件维度，通常采用语义化版本号，如 v2.3.1，并建议拆分为主版本、次版本、修订号三个字段存储，便于比较和筛选。生命周期状态则描述设备从入库到报废的阶段，常见取值包括：待激活、在用、停用、维修中、已报废。状态不是静态标签，而是由业务事件驱动的流转结果。
二、数据字典规范：让每个字段可定义、可校验
属性设计完成后，必须落到数据字典中，明确字段名、数据类型、约束规则、取值示例和业务说明。数据字典不是文档装饰，而是后续接口校验、数据库建表、标签规则引擎的共同依据。以下给出一份可直接参考的字段定义示例。
| 字段名 | 数据类型 | 约束规则 | 取值示例 | 说明 |
|---|---|---|---|---|
| device_type | 枚举 | 必填，预定义枚举 | smart_meter | 设备类型编码 |
| vendor | 字符串 | 必填，长度≤64 | Huawei | 厂商名称 |
| model | 字符串 | 必填，长度≤64 | HW-SM-2000 | 厂商型号 |
| serial_number | 字符串 | 必填，全局唯一 | SN-2024-000871 | 设备唯一标识 |
| firmware_version | 字符串 | 必填，语义化版本 | v2.3.1 | 固件版本号 |
| lifecycle_status | 枚举 | 必填，状态机约束 | active | 生命周期状态 |
| install_location | 字符串 | 选填，长度≤128 | A栋3层配电间 | 安装位置 |
三、生命周期状态机与事件驱动
生命周期状态不能随意修改，必须由明确的事件触发。例如：设备完成注册并首次上线，状态由“待激活”变为“在用”；设备上报故障或人工报修，状态变为“维修中”；维修完成后可回到“在用”，若判定无法修复则进入“已报废”。每一次状态变更都应记录变更时间、操作人和变更原因，形成可追溯的状态流水。
serial_number 设为唯一索引，将 lifecycle_status 设为枚举类型并配合状态机校验。固件版本字段建议额外拆出 major、minor、patch 三个整型字段，便于按版本区间筛选设备，例如“找出所有主版本低于 2 的网关设备”。
四、建模落地时的常见问题
实际项目中，最容易出现的问题有三类。第一，序列号重复或缺失，导致同一台设备被重复录入；第二，固件版本格式不统一，有的写 2.3.1，有的写 V2.3.1，有的写 2.3.1-release，导致版本比较失效；第三，生命周期状态被当作普通标签随意修改，缺少状态流转校验，最终无法判断设备真实可用性。
解决思路是：在数据字典中明确每个字段的格式约束，在入库接口中做强制校验，在状态变更时走统一的状态机服务。只有把属性定义、字典规范和状态流转三者绑定在一起，设备资产模型才具备长期可维护性，也才能为后续的标签管理、批量升级和资产盘点提供可信的数据底座。