DLMS/COSEM 蓝皮书解读五十Parameter monitorclass_id 65—— 配置被谁改了version 1 用一个哈希值回答系列说明本系列基于 DLMS UA《Blue Book蓝皮书第 16 版 · 第 2 部分》一个接口类一篇。第 49 篇的Security setupclass_id 64管的是通信怎么保护。本篇的Parameter monitorclass_id 65管的是另一件事配置参数本身有没有被人改过——尤其是被另一个主站/现场手持设备改过。它有 version 0 与 version 1 两个版本version 1 用参数哈希把这件事变得极其轻量。上篇回顾Security setup保护的是信道上的数据但它回答不了上次巡检到这次巡检之间表里的费率配置是不是被现场人员用手持设备改过。这类改动往往是合法客户端做的安全策略拦不住但主站必须知道——否则用旧配置去解析新数据就会出错。Parameter monitor就是为这个配置变更可追溯而生的。0. 为什么需要这个类 —— 配置漂移是隐形故障源先描述问题原文说得很清楚蓝皮书原文Parameter monitorversion 1“Each client that has access to the server has to be aware of the current parametrisation in order to be able to correctly exchange data with servers. The parameters may be grouped and each group may have a name. Although the parametrisation may be known initially, it may change during the lifetime of the meter, for example it may be changed by another client such as a field service device.”三种应对方式代价差别很大做法代价问题每次通信前把配置全读一遍高原文“This is not efficient and in the case of push operation it is not practical.”不管假设配置不变低配置漂移会导致数据解析错误且错误很隐蔽Parameter monitorversion 1极低读一个摘要只比对哈希不一致再细查version 1 的精髓在原文这段“To achieve this, version 1 of the Parameter monitor IC specifies new attributes to hold: the parameter_list_name; the hash_algorithm_id; the parameter_value_digest; and the parameter values.”“When a client configures the server, it can retrieve these attributes and share them with other clients. When a client starts a data exchange with the server, it can read the parameter_value_digest attribute and compare it to the value it has stored. If they match, the configuration is as expected, if not, the client can read the parameter_values attribute to identify which one(s) have changed.”这就是配置指纹配置时记下指纹之后每次通信先比指纹。指纹一致 → 放心用缓存配置指纹不一致 → 再读parameter_values定位到底哪个参数变了。1. 类蓝图1.1 version 1Parameter monitor 0…n class_id 65, version 1#属性数据类型Short name1logical_name(static) octet-stringx2changed_parameterstructurex 0x083capture_timedate-timex 0x104parameter_listarrayx 0x185parameter_list_nameoctet-stringx 0x206hash_algorithm_idenumx 0x287parameter_value_digestoctet-stringx 0x308parameter_valuesstructurex 0x38#方法必选/可选(m/o)Short name1add_parameter (data)ox 0x482delete_parameter (data)ox 0x50说明原文 version 1 的属性表中仅logical_name标注了(static)其余属性未标注静态/动态原文表格如此本文照录不作推断。Min/Max/Def 列原文未给出。1.2 version 0Parameter monitor 0…n class_id 65, version 0属性数据类型Short namelogical_name(static) octet-stringxchanged_parameterstructurex 0x08capture_timedate-timex 0x10parameter_listarrayx 0x18方法必选/可选(m/o)Short nameadd_parameter (data)ox 0x20delete_parameter (data)ox 0x281.3 版本差异维度version 0version 1属性数48新增 parameter_list_name、hash_algorithm_id、parameter_value_digest、parameter_values能否检测配置是否变化只能事后看changed_parameter最近一次变化可主动比对摘要parameter_value_digest且能读出全部当前值方法偏移x0x20 / x0x28x0x48 / x0x50分组命名无有parameter_list_name2. 属性逐条解读2.1 logical_name“Identifies the ‘Parameter monitor’ object instance.”2.2 changed_parameter —— 最近一次变化的参数蓝皮书原文Parameter monitor, changed_parameter“Holds the identifier and the value of the most recently changed parameter.”structure { class_id: long-unsigned, logical_name: octet-string, attribute_index: integer, attribute_value: CHOICE -- CHOICE as specified in the ‘Data’ interface class }即是哪个对象的哪个 attribute变成了什么值。注意attribute_value用的是Data(1) 里那个 CHOICE——所以它可以是任意 COSEM 数据类型这点在原文 NOTE 2 里有呼应。2.3 capture_time —— 变化发生的时间“Provides data and time information showing when the value of the changed_parameter attribute has been captured.”date-time is formatted as specified in ...2.4 parameter_list —— 监视清单parameter_list :: array parameter_list_element parameter_list_element :: structure { class_id: long-unsigned, logical_name: octet-string, attribute_index: integer }原文 NOTEversion 0 与 version 1 都有“The list of parameters monitored may be changed by using the add_parameter or delete_parameter methods or writing this attribute.”三种改法两个 method或直接写这个 attribute。2.5 parameter_list_nameversion 1“Holds the name given to the list of parameter as defined by the parameter_list attribute.”对应 §0 原文里那句“The parameters may be grouped and each group may have a name”——不同用途的参数可以分成不同的组每组一个Parameter monitor对象、一个名字。为什么分组原文 NOTE 2 解释了“As the various parameters may be of different type and length, the entries in the profile column holding the parameters will be also of different type and length. This can be managed by capturing different kind of parameters into different Parameter list Profile generic objects and parameter logs.”参数类型五花八门有的是long-unsigned、有的是octet-string塞进同一个Profile generic的同一列会很难处理——所以按类型/用途分组各建各的日志。2.6 hash_algorithm_idversion 1enum (0) SHA-256, (1) SHA-384, (2) Last 16 bytes of SHA-256, (3) Last 8 bytes of SHA-256, (4) Last 4 bytes of SHA-256注意 (2)(3)(4)不是新算法而是截断的 SHA-256——分别取最后 16 / 8 / 4 字节。这是为窄带信道准备的摘要越短比对越省字节代价是碰撞概率上升。取值摘要长度适用(0) SHA-25632 字节默认最稳(1) SHA-38448 字节与 suite 2 的 SHA-384 对齐时(2)16 字节窄带但要求较低碰撞率(3)8 字节极窄带(4)4 字节极限省字节2.7 parameter_value_digestversion 1—— 本篇的主角蓝皮书原文Parameter monitor, parameter_value_digest“Result of the digest calculation according to the algorithm specified by the hash_algorithm_id attribute. The digest is calculated on all the parameter list values as defined by attribute parameter_list in the order they are placed in the array. To calculate the digest, the whole set of parameter_list attribute values is first transformed into an octet-string. Rules for this transformation are defined , 9.2.3.4.3. Data conversion, for all the data types which are not an octet-string.”计算流程三步严格按原文① 按 parameter_list 数组中元素的顺序取每个参数的当前值 ② 把这一整组值转换成一个 octet-string 非 octet-string 类型的转换规则见 9.2.3.4.3 Data conversion ③ 用 hash_algorithm_id 指定的算法对 ② 的结果算摘要。两个必须注意的点顺序敏感——“in the order they are placed in the array”。清单顺序变了摘要就变了即使值没变。所以改parameter_list会导致摘要变化别误判成参数被改了。转换规则不在本类里——在文档的 9.2.3.4.3Data conversion。实现时两端必须用同一套转换规则否则摘要对不上。2.8 parameter_valuesversion 1“Holds a copy of the values of the attributes referenced in parameter_list attribute. It is a structure that holds the A-XDR encoded value of each attribute in the order of the parameter_list array.”是当前全部参数值的一份副本每个值是A-XDR 编码的顺序同parameter_list。配合摘要使用摘要不一致 → 读parameter_values→ 逐个与本地记录比对 → 定位是哪个变了。3. 方法add_parameter 与 delete_parameter3.1 add_parameter (data)“Adds one parameter to the parameter_list. data :: parameter_list_element”NOTE“A parameter can be logged as soon as it is added to the list. Adding an element to the list does not affect the buffer of the ‘Profile generic’ object capturing the changed_parameter attribute.”3.2 delete_parameter (data)“Deletes one parameter from the parameter_list. data :: parameter_list_element”NOTE“When a parameter is deleted from the parameter list, its changes will not be logged any more. Removing an element from the list does not affect the buffer of the ‘Profile generic’ object capturing the changed_parameter attribute.”两个 method 的 NOTE 都明确了一件事增删清单元素不会影响正在捕获changed_parameter的那个Profile generic的 buffer。也就是说✅ 缓冲区里已有的历史记录不受影响❌ 被删掉的参数之后的变化不再入日志。4. 【实战举例】说明以下 OBIS、取值、字节均为帮助理解而构造的示例非蓝皮书原文实际以设备对象列表与项目配套规范为准。示例 1建一个费率配置监视组Parameter monitor 对象 logical_name 0-0:16.2.0.255 示意 OBIS parameter_list_name TARIFF_CFG -- 分组名version 1 hash_algorithm_id 0 -- SHA-256 parameter_list [ { class_id 20, logical_name 0-0:13.0.0.255, attribute_index 2 }, -- Activity calendar name active { class_id 10, logical_name 0-0:11.0.0.255, attribute_index 2 }, -- Schedule passive { class_id 3, logical_name 1-0:13.7.0.255, attribute_index 3 } -- Register scaler_unit ]主站配置完成后读一次parameter_value_digest存进自己的数据库比如a3f1…c92b32 字节。示例 2每次通信前的指纹校验GET parameter_value_digest → 0x A3F1…C92B32 字节 与本地记录比对 一致 → 配置未变继续用缓存配置解析数据 不一致 → 读 parameter_values逐个定位开销对比假设 3 个参数方式读取字节量示意每次读全部配置参数需要 3 次或 GET-WITH-LIST描述符 完整值只读parameter_value_digest1 个 attribute32 字节SHA-256若用hash_algorithm_id 4Last 4 bytes of SHA-256只要 4 字节——一次 GET 就能确认配置没动过。示例 3定位哪个参数变了摘要不一致后读parameter_valuesstructure顺序同parameter_listparameter_values { A-XDR 0-0:13.0.0.255 attr2 SUMMER2024, -- 变化原为 WINTER2024 A-XDR 0-0:11.0.0.255 attr2 unchanged, A-XDR 1-0:13.7.0.255 attr3 { -1, 30 } -- 未变 }逐个与本地记录比对 → 发现是 Activity calendar name 从WINTER2024换成了SUMMER2024季节切换属正常变更。示例 4changed_parameter capture_time 留下变更痕迹某次参数被改changed_parameter { class_id 20, logical_name 0-0:13.0.0.255, attribute_index 2, attribute_value octet-string SUMMER2024 } capture_time 2024-04-01 02:00:00原文“If the value of an attribute changes and this attribute is present in the parameter_list attribute, the identifier and the value of that attribute is automatically captured to the changed_parameter attribute.”——只有清单内的参数变化才会被捕获。示例 5用 Profile generic 做参数变更日志把changed_parameter和capture_time交给Profile generic(7)Profile generic 的 capture_objects [ { class_id 65, logical_name 0-0:16.2.0.255, attribute_index 3, data_index 0 }, -- capture_time { class_id 65, logical_name 0-0:16.2.1.255, attribute_index 2, data_index 0 } -- changed_parameter ]原文 NOTE 3“The ‘Profile generic’ object holding the parameter change log may capture other suitable object attributes, such as the time attribute of the Clock object and any other relevant values.”于是形成一张时间 变更内容的审计表。原文 NOTE 1 的提醒“In the case of simultaneous or quasi simultaneous parameter changes the order of capturing and logging the changed parameters has to be managed by the application.”——几乎同时发生的多个变更其捕获顺序由应用自己管理标准不保证顺序。示例 6add_parameter 的即刻生效ACTION add_parameter (data { class_id 8, logical_name 0-0:1.0.0.255, attribute_index 2 })原文 NOTE“A parameter can be logged as soon as it is added to the list.”—— 加入即可入日志。连带影响加了元素 →parameter_list变了 → 摘要计算输入变了 →parameter_value_digest会变。这是合法变化不是配置漂移主站需要重新记录基线。示例 7delete_parameter 之后不再记录ACTION delete_parameter (data { class_id 3, logical_name 1-0:13.7.0.255, attribute_index 3 })该参数之后的变化不再入日志不影响已有Profile generic的 buffer原文两处 NOTE 都强调了。示例 8多主站共享配置指纹version 1 的设计初衷原文场景“When a client configures the server, it can retrieve these attributes and share them with other clients.”① 主站 A 配置设备 → 读下 parameter_list_name / hash_algorithm_id / parameter_value_digest ② 主站 A 把这套指纹共享给主站 B走后台系统不走 DLMS ③ 主站 B 与主站 C 之后只需比对指纹即可确认配置一致这在多主站环境营销系统 采集系统 现场运维里价值最大谁改了配置所有主站下一次通信时都能立刻发现。示例 9把摘要也捕获进 Profile generic原文“The attributes can also be captured into Profile generic object buffer attributes to assure the validity of the data captured. The resulting overhead can be minimized by the use of null-data encoding.”在负荷曲线的capture_objects里加一列parameter_value_digest{ class_id 65, logical_name 0-0:16.2.1.255, attribute_index 7, data_index 0 }这样每条曲线记录都带着当时的配置指纹事后核查时能证明这条数据是用哪套配置产生的。开销可用null-data编码压缩指纹没变时不必重复存。5. 工程上容易踩的坑以为改了parameter_list摘要不变摘要是对清单顺序敏感的增删参数会让摘要变化——要重新记录基线别误报配置被改。两端数据转换规则不一致摘要计算依赖 9.2.3.4.3 的 Data conversion 规则实现必须对齐否则永远对不上。用截断摘要2/3/4却不评估碰撞率4 字节摘要碰撞概率不低只适合粗筛真不一致还要读parameter_values复核。指望changed_parameter能记录所有变化只有parameter_list内的参数变化才会被捕获。指望标准保证并发变更的顺序原文 NOTE 1 明确说顺序由应用自己管理。把不同类型的参数塞进同一个监视组原文 NOTE 2 建议按类型/用途分组否则日志列的类型和长度会很混乱。以为增删参数会清掉 Profile generic 的 buffer原文 NOTE 明确说不影响。version 0 设备上找parameter_value_digest只有 version 1 有version 0 只能靠changed_parameter做事后发现。把parameter_values当成历史它是当前值的一份副本历史要靠Profile generic捕changed_parameter。忽略了parameter_list_name的分组价值不分组的话哪一组配置变了这件事本身就分不清。6. 小结 下期预告本篇要点Parameter monitor(65) 监视一组配置参数任何清单内参数变化都会自动捕获到changed_parametercapture_timeversion 1 新增四个 attributeparameter_list_name分组名、hash_algorithm_id、parameter_value_digest配置指纹、parameter_values当前值副本hash_algorithm_id支持 SHA-256 / SHA-384 和SHA-256 的截断16/8/4 字节窄带场景可省到 4 字节一次比对摘要按parameter_list顺序计算值先整体转为octet-string规则见 9.2.3.4.3add_parameter/delete_parameter增删清单元素不影响捕获changed_parameter的Profile genericbuffer典型用法配置时记指纹 → 每次通信比指纹 → 不一致再读parameter_values定位配合Profile generic可做参数变更审计日志。下一篇第 51 篇Measurement data monitoring objectsclass_id 66—— 从配置监视转向波形捕获触发点前后各留多少采样点、采样率怎么定以及怎么把一段波形塞进Profile generic。参考资料DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》Parameter monitor(class_id 65, version 0 与 version 1) 章节文中属性名与顺序、数据类型、Short name 偏移、方法 m/o、hash_algorithm_id 枚举、摘要计算规则与引文均与原文一致示例中的 OBIS、取值与字节为帮助理解而构造非蓝皮书原文实际以设备对象列表及项目配套规范为准。