DLMS/COSEM 蓝皮书解读（五）：Demand register 类（class_id = 5）—— 自己会算数的“需量寄存器“

DLMS/COSEM 蓝皮书解读五Demand register 类class_id 5—— 自己会算数的需量寄存器系列说明本系列基于 DLMS UA《Blue Book蓝皮书第 16 版 · 第 2 部分》一个接口类一篇。第 4 篇讲了Extended register值 时刻 状态。本篇的Demand register是四个寄存器兄弟里属性最多9 个、也是唯一自己会算数的一个。上篇回顾Register/Extended register存的都是某个量现在是多少。但计费场景里更常见的问题是过去 15 分钟的平均功率是多少这就是需量demand也是本篇的主角。0. 什么是需量为什么不能主站自己算需量demand通俗讲就是一段时间内的平均功率。电力计费里之所以看需量是因为电网容量成本取决于用户瞬时占用的最大功率而不只是总用电量。一个用户的月用电量可能不高但如果他每天都有一小段时间把功率拉满电网仍必须按这个峰值给他预留容量 —— 所以要按最大需量收费。那问题来了主站能不能自己拿两个电量读数相减除以时间算出需量能但不好原因有三精度与同步需要精确对齐窗口边界主站抄表时刻漂移会直接引入误差网络代价要算 15 分钟需量就得高频抄电量比如每分钟一次通信量爆炸责任边界结算数据应当由表计自己冻结并签名/标记状态主站算的数没有法律效力。所以 DLMS 把需量计算放进表计里Demand register对象自己累加、自己除、自己更新结果主站只需读结果。蓝皮书原文Demand register, Overview“This IC allows modelling a demand value with its associated scaler, unit, status and time information. A ‘Demand register’ objectmeasures and computes a current_average_value periodicallyand it stores a last_average_value. The time interval T over which the demand is calculated is defined by specifying number_of_periods and period.”一句话定位Demand register会自己做累计 ÷ 时长的寄存器输出两个结果正在跑的current和上一窗口已结算的last。1. 类蓝图Demand register 0...n class_id 5, version 0属性静态/动态数据类型MinMaxDefShort namelogical_name(static)octet-stringxcurrent_average_value(dyn.)CHOICE0x 0x08last_average_value(dyn.)CHOICE0x 0x10scaler_unit(static)scal_unit_typex 0x18status(dyn.)CHOICEx 0x20capture_time(dyn.)octet-stringx 0x28start_time_current(dyn.)octet-stringx 0x30period(static)double-long-unsigned1x 0x38number_of_periods(static)long-unsigned11x 0x40方法必选/可选(m/o)Short namereset (data)ox 0x48next_period (data)ox 0x509 个属性、2 个方法是四个寄存器兄弟里最重的一个。可以看出它复用了前几个类的成果scaler_unit、status的类型直接引用Register/Extended register的规格但因为前面多了current_average_value、last_average_value两个属性偏移整体后移scaler_unit从x0x10变成x0x18。2. 属性逐条解读2.1current_average_value与last_average_value—— 核心的两个数这是理解整个类的钥匙。current_average_value运行中需量Provides the current value (running demand) of the energy accumulated since start_time, divided by number_of_periodsperiod.*即从start_time_current开始累计的能量除以(number_of_periods × period)。它是一个还在长的数—— 随着当前周期推进累计能量增加这个值也在变。last_average_value上一窗口需量Provides the value of the energy accumulated (over the last number_of_periodsperiod) divided by number_of_periodsperiod.The energy of the current (not terminated) period is not considered by the calculation.即最近一个完整窗口的平均值。关键在于当前这个还没结束的周期不计入—— 所以它是已结算的确定值适合直接用于计费。两者的关系current_average_valuelast_average_value含义正在跑的需量上一窗口已结算的需量是否变化随当前周期推进而增长每个周期更新一次是否含未结束周期✅ 含❌ 不含适合用于计费❌还在变✅确定值Def.00蓝皮书还补了一句“If a quantity other than energy is measured, other calculation methods may apply (for example for calculating average values of voltage or current).”即需量不只能算功率 —— 算电压、电流的平均值时算法可能是算术平均而非能量÷时间。这类细节取决于建模的量。数据类型 CHOICE与Register的value相同原文“For data types, see ‘Register’ value attribute.”。2.2scaler_unit/statusscaler_unit“See the specification of IC ‘Register’.”—— 与第 3 篇完全一致structure { scaler, unit }真值 value × 10^scaler。需量的unit通常是27 (W)有功功率无功需量用29 (var)视在需量用28 (VA)。status“For data types, see ‘Extended register’ IC status attribute.”—— 与第 4 篇相同的 9 种 CHOICE语义同样由实例/厂商定义。2.3capture_time—— 注意它与Extended register的含义不同“Provides the date and timewhen the last_average_value has been calculated.”对比一下类capture_time的含义Extended register(4)value被采集/冻结的时刻Demand register(5)last_average_value被计算出来的时刻同样是capture_time语义随类而变 —— 这是读蓝皮书时很容易混淆的地方。主站校验需量数据的新鲜度时就看这个值。2.4start_time_current“Provides the date and timewhen the measurement of the current_average_value has been started.”即当前这个运行中需量是从什么时候开始累计的。有了它主站可以自己验证当前时间 − start_time_current是否接近period从而判断表计的周期推进是否正常。2.5periodstatic—— 需量窗口的一格有多长Period is the interval between two successive updates of the last_average_value. (number_of_periodsperiod) is the denominator for the calculation of the demand.*“double-long-unsigned, Measuring period in seconds.”单位秒Min 1典型值90015 分钟、180030 分钟部分国家、601 分钟(number_of_periods × period)就是需量窗口的总长度也就是计算公式的分母。⚠️ 蓝皮书明确“The behaviour of the meterafter writing a new value to this attribute shall be specified by the manufacturer.”改period之后表计会怎样立即生效下周期生效清空当前累计——蓝皮书不管由厂商定义。所以别指望写进去就能立刻按新周期算。2.6number_of_periodsstatic—— 决定区间需量还是滑动需量这是本篇最需要讲清楚的一个属性“The number of periods used to calculate the last_average_value. number_of_periods 1.”“number_of_periods 1indicates that the last_average_value represents‘sliding demand’,”“number_of_periods 1indicates that the last_average_value represents‘block demand’.”两种需量机制用文本图说明设period 900 s即 15 分钟① block demand区间需量number_of_periods 1窗口不重叠每 15 分钟结算一次窗口之间边界对齐|--- 窗口1 ---|--- 窗口2 ---|--- 窗口3 ---|--- 窗口4 ---| 00:00 00:15 00:30 00:45 01:00 ↑ 结算 ↑ 结算 ↑ 结算 ↑ 结算每个窗口独立计算结算后last_average_value更新为该窗口的平均值。中国、欧洲大部分电表用这种。② sliding demand滑动需量number_of_periods 3窗口长度为3 × 900 s 45 分钟但每 15 分钟推进一次窗口互相重叠窗口 A: |--------- 45 min ---------| 窗口 B: |--------- 45 min ---------| 窗口 C: |--------- 45 min ---------| 推进: 00:45 01:00 01:15 01:30每推进一格就丢掉最老的 15 分钟、加入最新的 15 分钟。北美如 ANSI C12 系列常用这种。block demandsliding demandnumber_of_periods 1 1窗口长度periodnumber_of_periods × period窗口是否重叠否是更新间隔periodperiod常见地区中国、欧洲北美3. 方法resetvsnext_period—— 别搞混两个方法都会结束当前周期但对last_average_value的处理完全不同。reset (data)“the current period is terminated; the current_average_value and the last_average_value are set to their default values; the capture_time and the start_time_current are set to the time of the execution of reset (data).”next_period (data)“This method is used to trigger theregular termination (and restart)of a period. Closes (terminates) the current measuring period. Updates capture_time and start_time andcopies current_average_value to last_average_value, sets current_average_value to its default value. Starts the next measuring period.”对比表动作resetnext_period结束当前周期✅✅current_average_value→ 默认值→ 默认值last_average_value→默认值被丢弃←复制自 current_average_value被保留capture_time/start_time_current设为 reset 执行时刻更新为本周期结束时刻开始下一周期✅✅语义强制清零异常/维护正常周期推进常规结算一句话next_period是正常收工reset是推倒重来。想读上一周期需量就该等next_period发生通常是表计自动触发而不是去调reset—— 调了就把结果清掉了。一条很重要的 REMARK“The old last_average_value (and capture_time) can be read during the time ‘period’. The old current_average_value is not available any more at the interface.”意思是next_period之后旧的last_average_value会保留一个period的时间供你读取但旧的current_average_value立刻就取不到了。工程意义主站必须在下一个period之内把last_average_value读走否则数据被覆盖。这也决定了抄表任务的周期上限。4. 【实战举例】示例 115 分钟区间需量手算一遍配置period 900 15 分钟单位秒 number_of_periods 1 block demand scaler_unit { scaler 0, unit 27 } unit 27 W某个 15 分钟窗口内表计累计用电1,5 kWh累计能量 E 1,5 kWh 1500 Wh 窗口时长 T number_of_periods × period 1 × 900 s 900 s 按蓝皮书定义 demand E / T 1500 Wh / 900 s 1,6667 Wh/s 换算成功率单位Wh/s → W乘以 3600 1,6667 Wh/s × 3600 s/h 6000 W 6 kW因为scaler_unit {0, 27}last_average_value (value) 6000 真值 6000 × 10^0 6000 W 6 kW如果厂商把scaler_unit配成{ scaler 3, unit 27 }用 scaler 撑量级value 6 真值 6 × 10^3 6000 W 6 kW注意单位陷阱unit 30 (Wh)表示这个数是能量unit 27 (W)表示功率。需量是功率用 27如果你看到某个需量对象的 unit 是 30那它可能是窗口内的累计能量而非平均功率 —— 一定要读scaler_unit确认。示例 2滑动需量怎么算number_of_periods 3period 900 15 分钟 number_of_periods 3 sliding demand 窗口总长 3 × 900 2700 s45 分钟每 15 分钟推进一次。假设最近 45 分钟三个子窗口的用电分别是子窗口时段用电量最老即将被丢弃00:00–00:151,2 kWh中间00:15–00:301,8 kWh最新刚结束00:30–00:451,5 kWhlast_average_value (1,2 1,8 1,5) kWh / 2700 s 4,5 kWh / 2700 s 4500 Wh / 2700 s 1,6667 Wh/s × 3600 6000 W 6 kW再过 15 分钟00:45–01:00 用了 0,9 kWh窗口滑动一格丢掉最老的 1,2 kWh新的 last_average_value (1,8 1,5 0,9) / 2700 s 4,2 kWh / 2700 s 4200 / 2700 × 3600 5600 W 5,6 kW对比 block demand如果是number_of_periods 1这一格的结果只反映 00:45–01:00 这 15 分钟的 0,9 kWh0,9 kWh / 900 s 900 / 900 × 3600 3600 W 3,6 kW可以看到滑动需量平滑、区间需量陡峭—— 这正是两种机制在计费曲线上的差异来源。示例 3next_period的时间线含 REMARK 的实际影响period 900 s15 分钟 00:00:00 周期开始 start_time_current 00:00:00 current_average_value 从 0 开始增长 … 00:15:00 表计自动调用 next_period或外部触发 ├─ last_average_value ← current_average_value6 kW ├─ capture_time 00:15:00 ├─ start_time_current 00:15:00 ├─ current_average_value → 默认值0 └─ 开始下一周期 00:15:00 ~ 00:30:00 ← 这 15 分钟内可以读到旧的 last_average_value6 kW 00:30:00 再次 next_period last_average_value 被新值覆盖旧值 6 kW 消失主站抄表策略如果抄表间隔 period就必然丢数据。所以抄表周期必须 ≤ period或依赖Profile generic把每次需量结果存进历史见第 7 篇。示例 4SN 寻址偏移属性Short namelogical_namexcurrent_average_valuex 0x08last_average_valuex 0x10scaler_unitx 0x18statusx 0x20capture_timex 0x28start_time_currentx 0x30periodx 0x38number_of_periodsx 0x40方法resetx 0x48方法next_periodx 0x50注意current和last两个值占了x0x08和x0x10导致后面所有属性比Extended register整体后移了 0x08。SN 寻址下改类就要改偏移不能想当然。5. 工程上容易踩的坑用reset代替next_period会把last_average_value一起清掉等于把结算结果丢了。last_average_value只在period时间内可读REMARK抄表间隔必须 ≤ period否则丢窗口。改period/number_of_periods的行为是厂商自定义的蓝皮书不保证立即生效写入后要实测验证。混淆 block 与 slidingnumber_of_periods 1才是区间需量1 是滑动需量。搞反了会导致需量曲线对不上计费规则。capture_time语义不同这里是last_average_value 计算时刻不是value 采集时刻后者是Extended register的语义。单位混淆Wh vs W需量是功率通常unit 27 (W)若看到 30 (Wh)说明对象建模的是窗口内能量别当成平均功率。status依然是厂商自定义与Extended register相同不可跨厂商移植。6. 小结 下期预告本篇要点Demand registerclass_id 5有9 个属性 2 个方法是唯一**自己计算累计 ÷ 时长**的寄存器类current_average_value是运行中需量还在变last_average_value是上一完整窗口的需量已结算用于计费period秒Min1配合number_of_periodsMin1, Def1决定窗口1是block demand1 是sliding demand计算公式蓝皮书定义demand 累计能量 / (number_of_periods × period)再按scaler_unit换算单位Wh/s → W 需 ×3600next_period 正常收工current 复制给 lastreset 推倒重来两个值都清且旧last_average_value只在period时间内可读。下一篇第 6 篇Register activationclass_id 6。前面这些寄存器都是存数的而Register activation是管哪些寄存器当前生效的 —— 也就是费率结构切换的开关。我们会用一个峰谷电表的真实例子峰 / 谷 / 平三个电量寄存器 三张掩码讲清楚register_assignment、mask_list、active_mask是怎么配合工作的以及它通常如何被Activity calendarclass_id 20Script tableclass_id 9自动驱动。参考资料DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》Demand register (class_id 5, version 0) 章节。文中属性、Min/Max/Def、数据类型、Short name 偏移、方法定义与引文均与该章节原文一致示例中的用电量与窗口配置为帮助理解而构造计算过程遵循原文定义的公式。