DLMS/COSEM 蓝皮书解读四十二S-FSK Reporting system listclass_id 56—— S-FSK 的发现清单谁发过 DiscoverReport 还没被建档系列说明本系列基于 DLMS UA《Blue Book蓝皮书第 16 版 · 第 2 部分》一个接口类一篇。第 41 篇IEC 61334-4-32 LLC setup(55) 管 S-FSK 的 LLC 子层暴露哪些 L-SAP 还有 RDR 没读。本篇class_id 56继续待在 S-FSK 的即插即用机制里但视角换到发现与建档一台新表上电后怎么让集中器知道我来了。上篇回顾第 41 篇解决了server 端数据怎么回、主站怎么知道有 RDR 没读。但在这之前还有一步——新表刚入网集中器(NANAP/CIASE)根本不知道它的 system-title 是谁。本篇的S-FSK Reporting system list就是集中器侧那张待建档发现清单谁发过 DiscoverReport、还没注册全列在这儿。0. 为什么需要这个类 —— PLC 抄表也要即插即用集中器(NANAP)下挂着几十上百台 S-FSK 表。新表出厂、轮换、补装不可能每台都靠人工把 system-title 预先录进主站。S-FSK 设计了一套发现 注册流程新表(server) ──DiscoverReport CI_PDU──▶ 集中器(CIASE) 集中器 把 system-title 记进 reporting_system_list本篇 集中器 ──Register CI_PDU──▶ 新表 新表 完成注册 → 集中器从 reporting_system_list 删掉该 system-title没有S-FSK Reporting system list这种对象集中器就没有标准地方去暂存我看到但还没建档的表现场运维要么盲扫、要么靠私有表——集成就乱了。它是 S-FSK 自动发现 / 自动建档的标准落点。蓝皮书原文S-FSK Reporting system list, Overview“An instance of the ‘S-FSK Reporting system list’ IC holds the list of reporting systems.”1. 类蓝图S-FSK Reporting system list 0…n class_id 56, version 0属性静态/动态数据类型MinMaxDefShort namelogical_namestaticoctet-string———xreporting_system_listdyn.array———x 0x08Specific methodsm/oS-FSK Reporting system list该类无方法。说明本类只有一个数据属性reporting_system_list外加logical_name结构很简单但怎么被维护的规则不少见 §2.2。2. 属性逐条解读2.1 logical_name蓝皮书原文S-FSK Reporting system list, attribute description“Identifies the ‘S-FSK Reporting system list’ object instance.”示例 OBIS0.0.26.6.0.255非蓝皮书原文实际以设备对象列表为准。2.2 reporting_system_listdyn, array of system-title蓝皮书原文S-FSK Reporting system list, attribute description“Holds the MIB variable reporting-system-list (variable 16) specified in IEC 61334-4-32, 5.7.”system-title :: octet-string元素含义存放已经发过 DiscoverReport 请求、但还没被注册的 server 系统的 system-title。列表特性原文逐条有限大小finite size不是无限增长按到达排序sorted upon arrival最新到的排最前the first element is the newest one满了就替换最旧的Once full, the oldest ones are replaced by the new ones。蓝皮书原文更新规则 1 —— 收到 DiscoverReport“when a DiscoverReport CI_PDU is received by the server system (whatever its state: non configured or configured): the CIASE adds the reporting system-title at the beginning of the list, and verifies that it does not exist anywhere else in the list, if so it destroys the old one. A system-title can only be present once in the list;”蓝皮书原文更新规则 2 —— 收到 Register“when a Register CI_PDU is received by the server system (whatever its state: non configured or configured): the CIASE checks the reporting-system list. If a system-title is present in the reporting-system-list and in the Register CI-PDU, the CIASE deletes the system-title in the reporting-system-list: this system is no more considered as a reporting system.”要点归纳触发事件对 reporting_system_list 的影响收到 DiscoverReport不论本机是否已配置把该 system-title插到表头若表里已有删旧留新 →同一 system-title 只出现一次收到 Register且 system-title 同时出现在清单与 Register 里从清单删除该 system-title“不再是 reporting system”列表已满又来新的挤掉最旧的那条注意对象归属原文说这些更新动作由server system 的 CIASECOSEM Interface Access Service Entity执行。也就是说这张清单是被发现的 server 一侧维护的——它记录有哪些系统在找我/给我发了发现请求。这和第 41 篇的 RDR 一样是 server 本地生成的动态状态主站通过 GET 来读。3. 方法无蓝皮书原文Specific methods m/o该类 methods 列为空——S-FSK Reporting system list没有方法。没有方法意味着清单的增删改不靠主站 ACTION而由 server 在收到 DiscoverReport / Register CI_PDU 时自动维护。主站只能GET这张清单去看现在谁在待建档然后据此去发起 Register 把表正式纳管。4. 【实战举例】示例 1reporting_system_list 的 A-XDR 编码示例值假设 server 收到过 3 个系统的 DiscoverReportarray (长度 3) ├─ octet-string 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 // 最新到的表头 ├─ octet-string 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 └─ octet-string 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 // 最旧的说明system-title是octet-stringDLMS 中常见为 8 字节示例取 8 字节非蓝皮书原文的长度断言实际以 IEC 62351 / 设备规范为准数组按新→旧排序。示例 2DiscoverReport 触发插入时序工程示意[新表 A 上电] → 发 DiscoverReport CI_PDU 给集中器 集中器 CIASE 收到 → reporting_system_list 表头插入 A 的 system-title 主站 GET reporting_system_list → 看到 [A] 主站 据此对 A 发起 Register → A 正式建档、可被常规抄读示例 3重复 DiscoverReport 去重同一台表 A 因重传发了两次 DiscoverReport或 Period 内反复公告第一次 DiscoverReport → 插入 A表头 第二次 DiscoverReport → 发现表里已有 A → 删旧、再把 A 插到表头 结果表里 A 仍然只有一条且位置回到表头这正是原文a system-title can only be present once。示例 4Register 触发删除主站决定纳管 A发 Register CI_PDU且里面带的 system-title 正是 A收到 Register含 A → 检查 reporting_system_listA 在清单里也在 Register 里 → 从清单删除 A 主站 再次 GET → A 已不在清单不再是 reporting system示例 5列表满后的 FIFO 替换容量由实现定假设实现规格规定最多存 8 条当前已 8 条A~HA 最新、H 最旧。又来一台新表 I插入 I 到表头 → 列表 9 条超限 → 删最旧 H 最终[I, A, B, C, D, E, F, G]说明容量上限为工程示意非蓝皮书原文规定值实际看设备实现规格。排障时查不到某表可能是被 FIFO 挤掉了——别急着判它没发过发现。示例 6误把在清单里当已建档清单里的表 “发过发现、还没注册”。若主站读到 A 在清单里就以为 A 已纳管去抄会失败——A 还没走 Register。正确做法清单是待办Register 之后才算已建档。示例 7与第 41 篇的衔接新表入网DiscoverReport → reporting_system_list本篇集中器侧待建档 主站建档Register → 从 reporting_system_list 删除 日常抄读server 把回数据放进 RDR → reply_status_list第 41 篇主站侧可见有数据待读发现(本篇) 与 应答(第 41 篇) 是 S-FSK 入网 通信的前后脚。示例 8列表有限大小对运维的影响集中器下若频繁有表重启/重发发现比如某片区电源不稳表反复上下电reporting_system_list会被刷屏真正想建档的新表可能被 FIFO 挤掉。运维对策稳定电源避免表反复重发 DiscoverReport主站高频轮询本对象如每几分钟一次及时把发现的表 Register 掉容量上限看实现规划时留足余量。示例 9已配置表再发 DiscoverReport 也会进清单原文说不论本机状态non configured / configured收到 DiscoverReport 都插入。意味着已建档的表重启后发发现也会出现在清单里——主站看到熟悉的 system-title 在清单中应判断它是重连/重启而非新表避免重复建档。示例 10Register 之后为什么还要确认已删主站发 Register 后应再 GET 一次reporting_system_list确认该 system-title 已不在——因为删除动作依赖system-title 同时出现在清单和 Register 里。若 Register 里的 title 写错如字节错位就不会删表里会残留。这是建档闭环的必备校验。示例 11system-title 的唯一性即表的身份证system-title是 server 的身份标识。清单靠它去重同一 title 只出现一次。若两台表不小心配了相同 system-title工程事故发现流程会乱一台的发现会顶掉另一台的记录建档也串台。出厂/烧号环节必须保证 system-title 全局唯一。示例 12集中器侧 vs 表侧的对象归属澄清注意原文清单由server system 的 CIASE维护。在 S-FSK 拓扑里server是被抄的表CIASE 是表内的接入服务实体。所以这张发现清单实际是表自己记录的’有哪些系统在找我’——主站通过 GET 读这张表从而知道哪个集中器/system-title 在尝试发现我。和第 41 篇 RDR 一样是 server 本地动态状态。示例 13与第 41 篇的端到端视图[发现] 新表 DiscoverReport → reporting_system_list(56, 本篇) [建档] 主站 Register → 从 56 删除 [通信] 日常 GET → server 回数据进 RDR → reply_status_list(55, 第 41 篇) [读取] 主站轮询 55 → 读走 RDR56 是入网门票55 是日常通道一套 S-FSK 生命周期。5. 工程上容易踩的坑清单是 server 本地动态状态只能 GET不能 SET也没有方法去增删——增删由 DiscoverReport/Register 自动触发。“在清单里” ≠ “已建档”清单是待办发过发现未注册Register 之后才真正纳管别提前去抄。同 system-title 只出现一次重复 DiscoverReport 会去重并挪到表头别误以为收到 N 次发现 N 条记录。排序是新→旧表头最新轮询时优先处理表头元素但注意满后最旧被挤掉老候选可能消失。容量有限、FIFO 回收实现规格若容量小高频发现的网络里老表会被覆盖长周期审计要用Profile generic(7) 周期抓取本对象落库。DiscoverReport 不论本机状态都处理原文说whatever its state: non configured or configured——已配置的表再发发现也会进清单别以为只有全新表才会出现。Register 删除是双向匹配只有当 system-title 同时出现在清单和 Register 里才删Register 带了清单里没有的 title不影响清单。system-title 是身份标识长度看实现元素为octet-stringDLMS 常见 8 字节但别在代码里硬编码长度以设备规范为准。6. 小结 下期预告本篇要点S-FSK Reporting system list(56) 是 S-FSK 的发现清单存发过 DiscoverReport 还没注册的 server 的 system-title有限大小、新→旧排序、满则 FIFO 替换同一 system-title只出现一次重复发现会去重收到DiscoverReport插入表头、收到Register且匹配删除——由 server 的 CIASE 自动维护该类无方法主站只能 GET据此发起 Register 完成建档。下一篇第 43 篇ISO/IEC 8802-2 LLC Type 1 setupclass_id 57—— 离开 S-FSK转到 ISO/IEC 8802-2 定义的 LLC 三种操作类型Type 1无连接、不确认。它只有一个配置项max_octets_ui_pdu是 Type 2/Type 3 的入门篇。参考资料DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》S-FSK Reporting system list(class_id 56, version 0) 章节文中属性、数据类型、Short name 偏移、更新规则与引文均与原文一致示例中的 system-title 取值、字节、容量、时序为帮助理解而构造标注示例/非蓝皮书原文实际以设备对象列表及项目配套规范为准。
DLMS/COSEM 蓝皮书解读四十二S-FSK Reporting system listclass_id 56—— S-FSK 的发现清单谁发过 DiscoverReport 还没被建档系列说明本系列基于 DLMS UA《Blue Book蓝皮书第 16 版 · 第 2 部分》一个接口类一篇。第 41 篇IEC 61334-4-32 LLC setup(55) 管 S-FSK 的 LLC 子层暴露哪些 L-SAP 还有 RDR 没读。本篇class_id 56继续待在 S-FSK 的即插即用机制里但视角换到发现与建档一台新表上电后怎么让集中器知道我来了。上篇回顾第 41 篇解决了server 端数据怎么回、主站怎么知道有 RDR 没读。但在这之前还有一步——新表刚入网集中器(NANAP/CIASE)根本不知道它的 system-title 是谁。本篇的S-FSK Reporting system list就是集中器侧那张待建档发现清单谁发过 DiscoverReport、还没注册全列在这儿。0. 为什么需要这个类 —— PLC 抄表也要即插即用集中器(NANAP)下挂着几十上百台 S-FSK 表。新表出厂、轮换、补装不可能每台都靠人工把 system-title 预先录进主站。S-FSK 设计了一套发现 注册流程新表(server) ──DiscoverReport CI_PDU──▶ 集中器(CIASE) 集中器 把 system-title 记进 reporting_system_list本篇 集中器 ──Register CI_PDU──▶ 新表 新表 完成注册 → 集中器从 reporting_system_list 删掉该 system-title没有S-FSK Reporting system list这种对象集中器就没有标准地方去暂存我看到但还没建档的表现场运维要么盲扫、要么靠私有表——集成就乱了。它是 S-FSK 自动发现 / 自动建档的标准落点。蓝皮书原文S-FSK Reporting system list, Overview“An instance of the ‘S-FSK Reporting system list’ IC holds the list of reporting systems.”1. 类蓝图S-FSK Reporting system list 0…n class_id 56, version 0属性静态/动态数据类型MinMaxDefShort namelogical_namestaticoctet-string———xreporting_system_listdyn.array———x 0x08Specific methodsm/oS-FSK Reporting system list该类无方法。说明本类只有一个数据属性reporting_system_list外加logical_name结构很简单但怎么被维护的规则不少见 §2.2。2. 属性逐条解读2.1 logical_name蓝皮书原文S-FSK Reporting system list, attribute description“Identifies the ‘S-FSK Reporting system list’ object instance.”示例 OBIS0.0.26.6.0.255非蓝皮书原文实际以设备对象列表为准。2.2 reporting_system_listdyn, array of system-title蓝皮书原文S-FSK Reporting system list, attribute description“Holds the MIB variable reporting-system-list (variable 16) specified in IEC 61334-4-32, 5.7.”system-title :: octet-string元素含义存放已经发过 DiscoverReport 请求、但还没被注册的 server 系统的 system-title。列表特性原文逐条有限大小finite size不是无限增长按到达排序sorted upon arrival最新到的排最前the first element is the newest one满了就替换最旧的Once full, the oldest ones are replaced by the new ones。蓝皮书原文更新规则 1 —— 收到 DiscoverReport“when a DiscoverReport CI_PDU is received by the server system (whatever its state: non configured or configured): the CIASE adds the reporting system-title at the beginning of the list, and verifies that it does not exist anywhere else in the list, if so it destroys the old one. A system-title can only be present once in the list;”蓝皮书原文更新规则 2 —— 收到 Register“when a Register CI_PDU is received by the server system (whatever its state: non configured or configured): the CIASE checks the reporting-system list. If a system-title is present in the reporting-system-list and in the Register CI-PDU, the CIASE deletes the system-title in the reporting-system-list: this system is no more considered as a reporting system.”要点归纳触发事件对 reporting_system_list 的影响收到 DiscoverReport不论本机是否已配置把该 system-title插到表头若表里已有删旧留新 →同一 system-title 只出现一次收到 Register且 system-title 同时出现在清单与 Register 里从清单删除该 system-title“不再是 reporting system”列表已满又来新的挤掉最旧的那条注意对象归属原文说这些更新动作由server system 的 CIASECOSEM Interface Access Service Entity执行。也就是说这张清单是被发现的 server 一侧维护的——它记录有哪些系统在找我/给我发了发现请求。这和第 41 篇的 RDR 一样是 server 本地生成的动态状态主站通过 GET 来读。3. 方法无蓝皮书原文Specific methods m/o该类 methods 列为空——S-FSK Reporting system list没有方法。没有方法意味着清单的增删改不靠主站 ACTION而由 server 在收到 DiscoverReport / Register CI_PDU 时自动维护。主站只能GET这张清单去看现在谁在待建档然后据此去发起 Register 把表正式纳管。4. 【实战举例】示例 1reporting_system_list 的 A-XDR 编码示例值假设 server 收到过 3 个系统的 DiscoverReportarray (长度 3) ├─ octet-string 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 // 最新到的表头 ├─ octet-string 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 └─ octet-string 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 // 最旧的说明system-title是octet-stringDLMS 中常见为 8 字节示例取 8 字节非蓝皮书原文的长度断言实际以 IEC 62351 / 设备规范为准数组按新→旧排序。示例 2DiscoverReport 触发插入时序工程示意[新表 A 上电] → 发 DiscoverReport CI_PDU 给集中器 集中器 CIASE 收到 → reporting_system_list 表头插入 A 的 system-title 主站 GET reporting_system_list → 看到 [A] 主站 据此对 A 发起 Register → A 正式建档、可被常规抄读示例 3重复 DiscoverReport 去重同一台表 A 因重传发了两次 DiscoverReport或 Period 内反复公告第一次 DiscoverReport → 插入 A表头 第二次 DiscoverReport → 发现表里已有 A → 删旧、再把 A 插到表头 结果表里 A 仍然只有一条且位置回到表头这正是原文a system-title can only be present once。示例 4Register 触发删除主站决定纳管 A发 Register CI_PDU且里面带的 system-title 正是 A收到 Register含 A → 检查 reporting_system_listA 在清单里也在 Register 里 → 从清单删除 A 主站 再次 GET → A 已不在清单不再是 reporting system示例 5列表满后的 FIFO 替换容量由实现定假设实现规格规定最多存 8 条当前已 8 条A~HA 最新、H 最旧。又来一台新表 I插入 I 到表头 → 列表 9 条超限 → 删最旧 H 最终[I, A, B, C, D, E, F, G]说明容量上限为工程示意非蓝皮书原文规定值实际看设备实现规格。排障时查不到某表可能是被 FIFO 挤掉了——别急着判它没发过发现。示例 6误把在清单里当已建档清单里的表 “发过发现、还没注册”。若主站读到 A 在清单里就以为 A 已纳管去抄会失败——A 还没走 Register。正确做法清单是待办Register 之后才算已建档。示例 7与第 41 篇的衔接新表入网DiscoverReport → reporting_system_list本篇集中器侧待建档 主站建档Register → 从 reporting_system_list 删除 日常抄读server 把回数据放进 RDR → reply_status_list第 41 篇主站侧可见有数据待读发现(本篇) 与 应答(第 41 篇) 是 S-FSK 入网 通信的前后脚。示例 8列表有限大小对运维的影响集中器下若频繁有表重启/重发发现比如某片区电源不稳表反复上下电reporting_system_list会被刷屏真正想建档的新表可能被 FIFO 挤掉。运维对策稳定电源避免表反复重发 DiscoverReport主站高频轮询本对象如每几分钟一次及时把发现的表 Register 掉容量上限看实现规划时留足余量。示例 9已配置表再发 DiscoverReport 也会进清单原文说不论本机状态non configured / configured收到 DiscoverReport 都插入。意味着已建档的表重启后发发现也会出现在清单里——主站看到熟悉的 system-title 在清单中应判断它是重连/重启而非新表避免重复建档。示例 10Register 之后为什么还要确认已删主站发 Register 后应再 GET 一次reporting_system_list确认该 system-title 已不在——因为删除动作依赖system-title 同时出现在清单和 Register 里。若 Register 里的 title 写错如字节错位就不会删表里会残留。这是建档闭环的必备校验。示例 11system-title 的唯一性即表的身份证system-title是 server 的身份标识。清单靠它去重同一 title 只出现一次。若两台表不小心配了相同 system-title工程事故发现流程会乱一台的发现会顶掉另一台的记录建档也串台。出厂/烧号环节必须保证 system-title 全局唯一。示例 12集中器侧 vs 表侧的对象归属澄清注意原文清单由server system 的 CIASE维护。在 S-FSK 拓扑里server是被抄的表CIASE 是表内的接入服务实体。所以这张发现清单实际是表自己记录的’有哪些系统在找我’——主站通过 GET 读这张表从而知道哪个集中器/system-title 在尝试发现我。和第 41 篇 RDR 一样是 server 本地动态状态。示例 13与第 41 篇的端到端视图[发现] 新表 DiscoverReport → reporting_system_list(56, 本篇) [建档] 主站 Register → 从 56 删除 [通信] 日常 GET → server 回数据进 RDR → reply_status_list(55, 第 41 篇) [读取] 主站轮询 55 → 读走 RDR56 是入网门票55 是日常通道一套 S-FSK 生命周期。5. 工程上容易踩的坑清单是 server 本地动态状态只能 GET不能 SET也没有方法去增删——增删由 DiscoverReport/Register 自动触发。“在清单里” ≠ “已建档”清单是待办发过发现未注册Register 之后才真正纳管别提前去抄。同 system-title 只出现一次重复 DiscoverReport 会去重并挪到表头别误以为收到 N 次发现 N 条记录。排序是新→旧表头最新轮询时优先处理表头元素但注意满后最旧被挤掉老候选可能消失。容量有限、FIFO 回收实现规格若容量小高频发现的网络里老表会被覆盖长周期审计要用Profile generic(7) 周期抓取本对象落库。DiscoverReport 不论本机状态都处理原文说whatever its state: non configured or configured——已配置的表再发发现也会进清单别以为只有全新表才会出现。Register 删除是双向匹配只有当 system-title 同时出现在清单和 Register 里才删Register 带了清单里没有的 title不影响清单。system-title 是身份标识长度看实现元素为octet-stringDLMS 常见 8 字节但别在代码里硬编码长度以设备规范为准。6. 小结 下期预告本篇要点S-FSK Reporting system list(56) 是 S-FSK 的发现清单存发过 DiscoverReport 还没注册的 server 的 system-title有限大小、新→旧排序、满则 FIFO 替换同一 system-title只出现一次重复发现会去重收到DiscoverReport插入表头、收到Register且匹配删除——由 server 的 CIASE 自动维护该类无方法主站只能 GET据此发起 Register 完成建档。下一篇第 43 篇ISO/IEC 8802-2 LLC Type 1 setupclass_id 57—— 离开 S-FSK转到 ISO/IEC 8802-2 定义的 LLC 三种操作类型Type 1无连接、不确认。它只有一个配置项max_octets_ui_pdu是 Type 2/Type 3 的入门篇。参考资料DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》S-FSK Reporting system list(class_id 56, version 0) 章节文中属性、数据类型、Short name 偏移、更新规则与引文均与原文一致示例中的 system-title 取值、字节、容量、时序为帮助理解而构造标注示例/非蓝皮书原文实际以设备对象列表及项目配套规范为准。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
