DLMS/COSEM 蓝皮书解读（四）：Extended register 类（class_id = 4）—— 给数值加上“时刻“与“状态“

DLMS/COSEM 蓝皮书解读四Extended register 类class_id 4—— 给数值加上时刻与状态系列说明本系列基于 DLMS UA《Blue Book蓝皮书第 16 版 · 第 2 部分》一个接口类一篇。第 3 篇讲了Registerclass_id 3它解决了这个数是什么单位。本篇的Extended register再往前走一步解决这个数是哪一时刻的它还有效吗上篇回顾Register的三个属性是logical_name/value/scaler_unit能完整表达1 234,5 Wh。但它记录不了这个值是什么时候采下来的也记录不了这份数据是否可信。0. 为什么需要时刻 状态先看两个真实的工程痛点痛点一这个值是什么时候的主站凌晨 3 点读到1-0:1.8.0 1 234,5 kWh。这个值是此刻的实时值还是昨夜 24:00 冻结下来的结算值如果是实时值它每秒都在变主站读到的是读的那一刻的快照如果是冻结值它从冻结时刻起就不变了主站今天读、明天读都一样。Register分不清这两种情况 —— 它只有value。而在结算、计费、对账场景里这个值属于哪个时刻是刚需不能靠主站我读的时候是几点来推断因为可能抄表失败、补抄、数据延迟。痛点二这份数据还有效吗表计掉电、时钟被回拨、校验失败、数值溢出……这些情况下value依然会返回一个数字但这个数字不可信。怎么把不可信这件事告诉主站Extended register的答案就是多出来的两个属性capture_time这个value是在什么时刻被采集/冻结下来的status这份数据的状态是否有效、是否被改、是否溢出……。蓝皮书原文Extended register, Overview“This IC allows modelling a process value with its associated scaler, unit, status and capture time information.”一句话定位Extended registerRegister 采集时刻 数据状态。用于冻结值带状态的瞬时量这类需要自证时间与可信度的数据。1. 类蓝图Extended register 0...n class_id 4, version 0属性静态/动态数据类型Short namelogical_name(static)octet-stringxvalue(dyn.)CHOICEx 0x08scaler_unit(static)scal_unit_typex 0x10status(dyn.)CHOICEx 0x18capture_time(dyn.)octet-stringx 0x20方法必选/可选(m/o)Short namereset (data)o可选x 0x38对比Registerclass_id 3一眼就能看出来前三个属性完全一样连 Short name 偏移x/x0x08/x0x10都一致只是多挂了statusx0x18和capture_timex0x20。这个偏移复用不是巧合而是 COSEM 的设计习惯派生能力的新类会沿用父类的属性偏移保证 SN 寻址下主站的逻辑可复用。2. 属性逐条解读2.1value与scaler_unit直接继承Register蓝皮书在这两个属性上没有重复写规格而是直接指向Registervalue“See the specification of the IC ‘Register’.”scaler_unit“See the specification of the IC ‘Register’.”也就是说value的 CHOICE 数据类型表与Register完全一致16 种null-data[0] … float64[24]scaler_unit同样structure { scaler: integer, unit: enum }换算规则同样是真值 value × 10^scaler。所以换算出真值的代码可以完全复用这也是把Extended register视作Register的扩展的原因。2.2statusdyn., CHOICE—— 灵活但不标准化status的类型是另一个 CHOICE可选类型比value少去掉了有符号和浮点偏重标志位/枚举/字符串CHOICE { -- simple data types null-data [0], bit-string [4], double-long-unsigned [6], octet-string [9], visible-string [10], utf8-string [12], unsigned [17], long-unsigned [18], long64-unsigned [21] } Def. Depending on the status type definition.但蓝皮书紧接着给了一句非常关键的限定“Provides ‘Extended register’ specific status information. The meaning of the elements of the status shall be provided for each object instance. The data type and the encoding depend on the instantiation and possibly on the choice of the manufacturer.For the interpretation, extra information from the manufacturer may be necessary.”翻译成工程语言三层意思status 的含义是逐实例定义的—— 蓝皮书不规定第 0 位表示什么数据类型和编码取决于实例化方式且厂商有选择权要解释 status通常需要厂商额外提供的信息设备文档 / 对象字典。这一点务必记住status不是可移植的。同样是long-unsigned的状态字A 厂的 bit0 “时钟失效”B 厂的 bit0 可能 “数据被修改”。跨厂商集成时必须查厂商文档不能照搬。常见的两种编码方式行业惯例非蓝皮书强制bit-string/long-unsigned当作位域用每位一个标志数据有效 / 溢出 / 被人工修改 / 时钟回拨 …visible-string/enum当作枚举或文字状态用如 “OK” / “INVALID”。2.3capture_timedyn., octet-string—— 本篇最有价值的属性“Provides an ‘Extended register’ specific date and time information showing when the value of the attribute value has been captured. octet-string, formatted as specified in for date-time.”要点类型是octet-string但格式遵循蓝皮书的 date-time 定义不是随便一个字符串语义是value这个值是在什么时刻被采集/冻结的它是(dyn.)属性 —— 每次采集/冻结都会更新。DLMS 的date-time类型是12 字节的 octet-string字段排布如下这是 DLMS 通用定义字节字段类型说明1–2yearlong-unsigned如0x07E7 20230xFFFF表示未知3monthunsigned1–124day of monthunsigned1–315day of weekunsigned1–71 周一0 未指定6hourunsigned0–237minuteunsigned0–598secondunsigned0–599hundredthsunsigned0–9910–11deviationinteger与 UTC 的偏差单位分钟如0x003C 60 min12clock statusunsigned位 0与 UTC 是否同步等标志位说明上表是 DLMSdate-time的通用结构蓝皮书capture_time直接引用该定义。解析capture_time时按这 12 字节拆即可。3. 方法reset (data)—— 与Register的关键差异reset (data) data :: integer (0)Extended register的reset比Register多了一个动作“This method forces a reset of the object. By invoking this method, the attribute value is set to the default value. The default value is an instance specific constant.The attribute capture_time is set to the time of the reset execution.”对比一下动作Register.resetExtended register.resetvalue置为默认值实例特定常量✅✅capture_time置为reset 执行的时刻❌无此属性✅工程意义复位一个Extended register之后capture_time会变成刚才复位的时间。所以capture_time不仅能表示数据何时采集还能隐含表示上一次复位发生在什么时候。如果你发现某个冻结对象的capture_time是某个异常时刻很可能是被人复位过。4. 【实战举例】示例 1月结算冻结电能最典型场景假设一块电表每月 1 日 00:00:00 冻结一次正向有功总电能。用Extended register建模对象Extended register (class_id 4) logical_name 1-0:1.8.0 示例 OBIS实际由设备对象列表决定 value 1234567 long-unsigned scaler_unit { scaler -1, unit 30 } → 123456.7 Wh 123.4567 kWh capture_time 2023-02-01 00:00:00 12 字节 date-time status 0x00 bit-string/long-unsigned0 数据正常主站的抄表流程# 1. 读 capture_timeattribute 5→ 确认这个值属于哪个时刻 GET (4, 1-0:1.8.0, 5) → 07 E7 02 01 03 00 00 00 00 00 00 00 2023-02-01, 周三, 00:00:00, deviation0, status0 # 2. 读 scaler_unitattribute 3→ 拿到量纲 GET (4, 1-0:1.8.0, 3) → structure { -1, 30 } # 3. 读 valueattribute 2→ 拿到数值 GET (4, 1-0:1.8.0, 2) → 1234567 # 4. 读 statusattribute 4→ 确认数据可信 GET (4, 1-0:1.8.0, 4) → 0x00 # 5. 换算1234567 × 10^(-1) 123456.7 Wh对比如果用Register存这个冻结值会怎样Register没有capture_time主站只能知道我现在读到了 123456.7 kWh但无法证明这个值属于 2 月 1 日 00:00:00—— 万一表计冻结失败、主站读到的是上一次的值呢有了capture_time主站可以直接校验“我要的冻结时刻是 2 月 1 日你返回的 capture_time 是不是 2 月 1 日不是就丢弃。”示例 2status怎么用 —— 位域用法假设厂商定义status为long-unsigned位含义如下厂商自定义仅为示例bit含义0数据有效0 有效1 无效1数值溢出2数据被人工修改过3时钟曾失效数据时刻不可信4掉电期间数据不完整主站读到status 0x0A二进制0000 1010bit1 1 →数值溢出bit3 1 →时钟曾失效此时即使value和scaler_unit都正常这份数据也不应该用于结算—— 主站应记录异常并告警。再强调一次这张位表是示例真实含义必须查该型号的设备文档。蓝皮书只给了 CHOICE能用什么类型没给语义。示例 3reset之后capture_time会变# 复位前 capture_time 2023-02-01 00:00:00 # 主站在 2023-02-05 09:30:00 调用 resetx 0x38 ACTION (4, 1-0:1.8.0, 1) # reset 方法索引为 1 # 复位后 value 实例特定的默认值 # 注意不是 0 capture_time 2023-02-05 09:30:00 # ← 被设为 reset 执行时刻这个特性常被用来做审计如果某冻结对象的capture_time不是预期的整点/月初而是某个奇怪的时刻那就说明它被人动过。示例 4SN 寻址下的偏移属性Register(3)Extended register(4)logical_namexxvaluex 0x08x 0x08scaler_unitx 0x10x 0x10status—x 0x18capture_time—x 0x20方法resetx 0x28x 0x38注意reset的偏移从0x28变成0x38—— 因为中间多了 2 个属性各占 0x08方法区整体后移了 0x10。5. 四个寄存器兄弟横向对比这是第 3 篇预告的对比表把最容易混淆的四个类放在一起Data(1)Register(3)Extended register(4)Demand register(5)属性个数2359logical_name✅✅✅✅value✅✅✅❌拆成 current / last averagescaler_unit量纲❌✅✅✅status数据状态❌❌✅✅capture_time采集时刻❌❌✅✅需量计算能力❌❌❌✅period/number_of_periods解决的核心问题“装一个数”“这个数什么单位”“什么时候的、可信吗”“平均需量是多少”典型用途序列号、固件版本、配置参数电能、功率、电压、电流冻结值、带状态瞬时量最大需量、滑动需量选型口诀只是参数/标识没有单位→Data有物理单位值实时变化→Register有单位且需要知道时刻 / 判断有效性→Extended register要算一段时间内的平均值需量→Demand register6. 工程上容易踩的坑status跨厂商不可移植蓝皮书明确规定其含义逐实例定义、可能需要厂商额外信息。不要写死位含义。capture_time是采集时刻不是读取时刻两者可能相差很久比如补抄上个月冻结值。别把主站当前时间当 capture_time 用。复位会改capture_time审计时要注意。value的默认值不是 0与Register一样reset后是实例特定的默认值。不要为了status滥用Extended register如果这份数据不需要时刻和状态语义用Register就够了 —— 属性越少实现越简单、互操作性越好。capture_time的 year 0xFFFF 表示未知解析时要处理DLMS date-time 里 0xFFFF/0xFF 常表示未指定/未知。7. 小结 下期预告本篇要点Extended registerclass_id 4Registerstatuscapture_time前三个属性的类型与 Short name 偏移完全沿用Registercapture_time是 12 字节 date-time 格式的 octet-string表示value被采集/冻结的时刻—— 这是冻结值、结算值能自证归属时刻的关键status是 CHOICE9 种类型但语义由实例/厂商定义蓝皮书不标准化可能需要厂商文档才能解释它的reset除了把value置为实例特定默认值还会把capture_time设为复位执行时刻与Register.reset的关键差异四个寄存器兄弟的选型无单位→Data、有单位→Register、要时刻与状态→Extended register、要需量→Demand register。下一篇第 5 篇Demand registerclass_id 5—— 四个兄弟里属性最多9 个、也是唯一自己会算数的一个。它会周期性计算current_average_value运行中需量和last_average_value上一周期需量并且能区分区间需量block demand和滑动需量sliding demand。我们会用period 900 s15 分钟的真实例子手算一遍1,5 kWh / 15 min 6 kW是怎么来的并讲清reset与next_period两个方法的区别。参考资料DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》Extended register (class_id 4, version 0) 章节date-time 通用定义。文中属性、数据类型、Short name 偏移、方法定义与引文均与该章节原文一致示例 2 的 status 位表为帮助理解的示例非蓝皮书原文。