文化遗产（古建筑）构件检测数据集 | 古建筑构件 文化遗产 构件识别 文物保护 目标检测9216期
2026/10/21 11:36:40
DLMS/COSEM 蓝皮书解读（四十二）：S-FSK Reporting system list（class_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| 属性 | 静态/动态 | 数据类型 | Min | Max | Def | Short name |
|---|---|---|---|---|---|---|
| logical_name | static | octet-string | — | — | — | x |
| reporting_system_list | dyn. | array | — | — | — | x + 0x08 |
Specific methods（m/o）：S-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.”
示例 OBIS：0.0.26.6.0.255（非蓝皮书原文，实际以设备对象列表为准）。
2.2 reporting_system_list（dyn, 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 的 CIASE（COSEM 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. 【实战举例】
示例 1：reporting_system_list 的 A-XDR 编码（示例值）
假设 server 收到过 3 个系统的 DiscoverReport：
array (长度 = 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-string，DLMS 中常见为 8 字节（示例取 8 字节，非蓝皮书原文的长度断言，实际以 IEC 62351 / 设备规范为准）；数组按"新→旧"排序。
示例 2：DiscoverReport 触发插入（时序，工程示意）
[新表 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"。
示例 4：Register 触发删除
主站决定纳管 A，发 Register CI_PDU，且里面带的 system-title 正是 A：
收到 Register（含 A） → 检查 reporting_system_list：A 在清单里，也在 Register 里 → 从清单删除 A 主站 再次 GET → A 已不在清单（"不再是 reporting system"）示例 5：列表满后的 FIFO 替换（容量由实现定）
假设实现规格规定最多存 8 条，当前已 8 条（A~H，A 最新、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 在清单中，应判断"它是重连/重启"而非"新表"，避免重复建档。
示例 10：Register 之后为什么还要"确认已删"
主站发 Register 后，应再 GET 一次reporting_system_list确认该 system-title 已不在——因为删除动作依赖"system-title 同时出现在清单和 Register 里"。若 Register 里的 title 写错（如字节错位），就不会删，表里会残留。这是建档闭环的必备校验。
示例 11：system-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-string，DLMS 常见 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 setup（class_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 取值、字节、容量、时序为帮助理解而构造（标注"示例/非蓝皮书原文"，实际以设备对象列表及项目配套规范为准）。