阿里云 IoT 平台物模型（TSL）中电机驱动器电流与温度属性的定义方式梳理
说明：本文基于阿里云 IoT 平台物模型（Thing Specification Language，TSL）官方文档整理，讨论电机驱动器电流、温度两类运行属性在物模型中的数据类型定义与上报格式。文中以 AQMD6020NS-E2B 驱动器作为示例设备，重点梳理 TSL 字段结构、数据类型选择与 MQTT 上报的 JSON 格式。具体接口以官方文档为准。
一、问题背景
电机驱动器接入云平台时，最先要解决的不是“连得上”，而是“数据怎么被云端理解”。同样一个电流值，如果物模型里定义成字符串，规则引擎就无法对它做数值比较；如果温度属性没有定义单位，应用侧拿到的 85 到底是摄氏度还是华氏度，只能靠猜。以艾思控驱动器 AQMD6020NS-E2B 为例，设备侧能读出的电流、温度、母线电压等参数有十几种，但哪些该进物模型、用什么类型进、上报频率怎么定，需要在接入前就想清楚。物模型的作用，就是把这批“设备私有数据”翻译成云端可识别、可计算、可检索的结构化定义。
二、物模型的数据类型与属性字段
阿里云 IoT 平台的物模型用 TSL 描述设备能力，核心分为属性（property）、服务（service）、事件（event）三类。对于驱动器运行监测场景，主要用到属性。
TSL 中属性的关键字段包括：
- identifier：属性标识符，设备上报时以此为 key，一旦定义不建议修改。
- dataType：数据类型，分为
int、float、double、bool、text、date、enum、struct、array等。 - accessMode：读写模式，
r表示只读（设备上报），rw表示可读写（可下发期望值）。 - unit：单位，如
A、℃、V。 - min / max：数值范围，用于云端校验。
以电流和温度两个属性为例，一份典型的 TSL 片段如下：
json
{
"identifier": "current",
"name": "母线电流",
"accessMode": "r",
"required": false,
"dataType": {
"type": "float",
"specs": {
"min": "0",
"max": "50",
"unit": "A",
"step": "0.01"
}
}
}
json
{
"identifier": "temperature",
"name": "驱动器温度",
"accessMode": "r",
"required": false,
"dataType": {
"type": "float",
"specs": {
"min": "-20",
"max": "120",
"unit": "℃",
"step": "0.1"
}
}
}
这里有两个选择需要说明。一是 float 与 double 的取舍：电流、温度这类物理量，float 的精度足够，double 会占用更多存储和带宽，除非做高精度计量，一般选 float。二是 int 的误用：如果电流定义成 int，设备侧上报 12.5A 时会被截断或拒绝，而驱动器电流采样本身是带小数的，所以电流、温度都应走浮点类型。
三、属性上报的 Topic 与 JSON 格式
物模型属性上报走的是设备到云端的自定义 Topic，格式为：
text
/sys/${ProductKey}/${DeviceName}/thing/event/property/post
设备将属性值按 TSL 的 identifier 组织成 JSON，通过该 Topic 发布。一次包含电流和温度的上报示例如下：
json
{
"id": "123456789",
"version": "1.0",
"params": {
"current": 12.5,
"temperature": 46.3
},
"method": "thing.event.property.post"
}
字段说明：
id：消息 ID，用于请求与响应的对应。version：协议版本，固定1.0。params：属性键值对，key 必须与 TSL 中的identifier完全一致，大小写敏感。method：固定为thing.event.property.post。
云端处理后会向设备返回一条响应 Topic 的消息，告知本次上报是否成功。如果某个属性的值超出 TSL 中定义的 min/max，或者类型不匹配（例如把 12.5 写成字符串 "12.5"），云端会返回错误码，该条属性不会入库。
上报频率的考虑：物模型本身不限制上报频率，但属性上报会消耗消息量。对于温度这类缓变量，可以按秒级或分钟级上报；电流在启停、堵转时变化剧烈，可按事件触发上报，而不是固定高频轮询。这一点需要在设备侧固件中做取舍，而不是在 TSL 里配置。
四、这套定义方式对驱动器场景的适用性
适合的部分：物模型把驱动器的私有寄存器地址翻译成云端统一的 identifier，应用侧不需要知道设备用的是 Modbus 还是 CAN，只需要按 current、temperature 取值。规则引擎、数据流转、可视化都能直接基于这些标识符做配置，这是物模型最大的价值。
需要注意的部分：第一，identifier 一旦定义并被设备上报使用，后续修改会影响历史数据的连续性，建议接入前把属性清单定全，避免边接边改。第二，单位必须写进 TSL，否则应用侧无法判断数值含义；同一产品下不同型号如果量程不同，要么拆成不同产品，要么在 TSL 中取最大范围并在设备侧做量程校验。第三，只读属性与可读写属性要分清：电流、温度是设备上报的，应为 r；如果某些参数需要云端下发，才设为 rw，并配合设备影子使用。
五、小结
物模型是驱动器数据上云的第一道结构化关口。电流、温度这类运行属性，用 float 类型、带单位和量程范围定义，按 TSL 的 identifier 组织 JSON 并通过属性上报 Topic 发布，是这套机制的标准用法。定义阶段把类型、单位、读写模式定准，后续规则引擎和数据存储才能稳定工作。
