DLMS/COSEM 蓝皮书解读四十一IEC 61334-4-32 LLC setupclass_id 55—— S-FSK 的 LLC 子层参数本帧长上限 RDR 待读清单系列说明本系列基于 DLMS UA《Blue Book蓝皮书第 16 版 · 第 2 部分》一个接口类一篇。第 37~40 篇把 S-FSK 这一组讲完了大半PhyMAC 参数(50)、Active initiator(51)、MAC 同步超时(52)、MAC 计数器(53)——都是MAC 层的配置 / 状态 / 统计。本篇class_id 55和紧接的 56/57 进入链路层之上的LLC 子层与发现机制。上篇回顾第 40 篇把 S-FSK 的发了几帧、CRC 错多少、同步/失同步几次量化成了账本——这些数字发生在MAC 层。但 MAC 之上还有一层LLCIEC 61334-4-32 定义的业务特定汇聚子层 SSCS它负责把应用数据封装成 LLC 帧、并管理 S-FSK 特有的应答请求(RDRReply Data on Request)缓冲。本篇的IEC 61334-4-32 LLC setup就是配置这层参数、并暴露哪些 L-SAP 还有 RDR 没被读走的对象。0. 为什么需要这个类 —— PLC 协议栈里MAC 之上还得有人管帧和缓冲先把 S-FSK PLC 的协议分层摆清楚工程视角非逐字译文应用层 (xDLMS / COSEM IC) │ LLC / SSCS ← 本篇管这层IEC 61334-4-32 │ MAC ← 第 37~39 篇S-FSK MAC │ PHY ← 第 38 篇也涉及物理层增益等对每一种 DLMS/COSEM 通信 profile都要有下层 setup对象来配置和暴露状态HDLC 有IEC HDLC setup(23)TCP/UDP 有TCP-UDP setup(41) IPv4 setup(42)S-FSK PLC 则有本篇的IEC 61334-4-32 LLC setup(55)。没有它你会面临两个具体问题问题没有 LLC setup 会怎样帧长上限未知设备不知道 LLC 帧最大多少字节缓冲怎么分、要不要分段全靠猜S-FSK 上帧太长是会撑爆子帧调度的RDR 待读清单不可见S-FSK 的server 按需回数据靠 RDR 缓冲实现到底哪些 L-SAP 攒了数据还没读主站看不见就会以为回了其实没读走蓝皮书原文IEC 61334-4-32 LLC setup, Overview“An instance of the ‘IEC 61334-4-32 LLC setup’ IC holds parameters necessary to set up and manage the LLC layer as specified in IEC 61334-4-32.”蓝皮书原文S-FSK IEC 61334-4-32 LLC setup, Overview“An instance of the ‘S-FSK IEC 61334-4-32 LLC setup’ IC holds parameters necessary to set up and manage the LLC layer as specified in IEC 61334-4-32.”注意这个类有version 0名字带 “S-FSK” 前缀明确是 S-FSK profile 专用和version 1更通用的 “IEC 61334-4-32 LLC setup”两个版本差异主要在max_frame_length的 Min/Max/Def 是否进表。下面对比呈现。1. 类蓝图IEC 61334-4-32 LLC setup 0…n class_id 55, version 1 S-FSK IEC 61334-4-32 LLC setup 0…n class_id 55, version 0属性适用的版本静态/动态数据类型MinMaxDefShort namelogical_name0, 1staticoctet-string———xmax_frame_length1staticlong-unsigned———x 0x08max_frame_length0staticunsigned26242134x 0x08reply_status_list0, 1dyn.array———x 0x10Specific methodsm/oIEC 61334-4-32 LLC setup该类无方法。版本差异说明非译文工程提醒version 1 的蓝图表里max_frame_length只写了long-unsigned、没有列 Min/Max/Def但 version 1 的属性说明里明确写道对 S-FSK PLC profileminimum / default / maximum 分别是 26 / 134 / 242 字节。version 0 则直接在蓝图表里把 26 / 134 / 242 列了出来。两者语义一致只是表格呈现不同。2. 属性逐条解读2.1 logical_name蓝皮书原文IEC 61334-4-32 LLC setup, attribute description“Identifies the ‘IEC 61334-4-32 LLC setup’ object instance.”OBIS 取值应遵循蓝皮书的设备/通信设置约定空间示例可用0.0.26.5.0.255非蓝皮书原文实际以设备对象列表为准。2.2 max_frame_length蓝皮书原文IEC 61334-4-32 LLC setup, attribute description“Holds the length of the LLC frame in bytes. … For the S-FSK PLC profile, the minimum / default / maximum values are 26 / 134 / 242 bytes respectively.”蓝皮书原文version 0S-FSK IEC 61334-4-32 LLC setup“In the case of the S-FSK profile … the maximum value is 242, but lower values may be chosen due to performance considerations.”含义LLC 帧的最大长度字节。它决定发送缓冲怎么分、一次能往 MAC 塞多大块。S-FSK 的三档值来自原文说明两版本一致最小26字节默认134字节version 0 表里 Def 134最大242字节。原文特别点明最大可以往小调“lower values may be chosen due to performance considerations”——信道差、子帧调度紧张时把帧长压小反而更稳。其它下层 profile 的对应值原文只说见相关规范的对应取值本类不强制。2.3 reply_status_listdyn, array of reply_status蓝皮书原文IEC 61334-4-32 LLC setup, attribute description“Holds the MIB variable reply-status-list (variable 11) specified in IEC 61334-4-32, 5.4. Lists the L-SAPs that have a not empty RDR (Reply Data on Request) buffer, which has not already been read. … The variable is locally generated by the LLC sub layer.”reply_status :: structure { L_SAP_selector: unsigned, // 哪个 L-SAP length_of_waiting_L_SDU: unsigned // 待读 L-SDU 的大小子帧数 }这是 S-FSK server 按需回数据机制的窗口某个 L-SAP 的 RDR 缓冲里有数据、且还没被主站读走就会被记进这张清单。length_of_waiting_L_SDU在 S-FSK profile 下以子帧(sub-frame)数计有效值1 ~ 7原文“valid values are 1 to 7”。该变量由 LLSC 子层本地生成不是配置项所以不能 SET。3. 方法无蓝皮书原文Specific methods m/o该类表格下 methods 列为空——IEC 61334-4-32 LLC setup没有方法。没有方法意味着你不能一键清这张清单也不能让它重算。主站只能通过GETreply_status_list来轮询谁还有 RDR 没读然后去对应 L-SAP 把数据读走读走之后 LLSC 子层自己把这条从清单移除。4. 【实战举例】示例 1reply_status_list 的 A-XDR 编码示例值假设 LLC 子层检测到两个 L-SAP 有未读 RDRarray (长度 2) ├─ structure { L_SAP_selector: unsigned 0x01, length_of_waiting_L_SDU: unsigned 2 } // L-SAP 1 有 2 个子帧待读 └─ structure { L_SAP_selector: unsigned 0x03, length_of_waiting_L_SDU: unsigned 5 } // L-SAP 3 有 5 个子帧待读说明字节为示意非蓝皮书原文。L_SAP_selector/length_of_waiting_L_SDU都是unsignedlength_of_waiting_L_SDU取值 1~7 才合法。示例 2max_frame_length 取 134默认值下的帧预算默认 134 字节 LLC 帧扣除 LLC 头S-FSK LLC 头约若干字节具体见 IEC 61334-4-32剩余给 L-SDU / APDU。对一帧带一个完整 GET-Response的常规抄表足够若单帧装不下如大Profile generic读出要么靠上层分段要么调大max_frame_length上限 242。说明134/242 是原文值扣除多少头为工程示意实际以 IEC 61334-4-32 头格式为准。示例 3信道差时把 max_frame_length 从 134 压到 80工程调优非蓝皮书原文某片区 S-FSK 误帧率偏高可联动第 40 篇 CRC 计数器长帧更容易整帧出错、重传成本高。现场把max_frame_lengthSET 为 80SET IEC 61334-4-32 LLC setup / max_frame_length unsigned 80单帧变小 → 出错范围小、重传代价低但吞吐量下降。这是原文lower values may be chosen due to performance considerations允许的做法。示例 4主站轮询 RDR 的标准动作时序工程示意主站 GET reply_status_list → 返回 [ {L-SAP3, len5}, {L-SAP1, len2} ] 主站 对 L-SAP3 发起 GET读该 L-SAP 上挂的 COSEM 对象 → server 把 RDR 缓冲读空 主站 再次 GET reply_status_list → 返回 [ {L-SAP1, len2} ] // L-SAP3 已不在清单要点清单是待读快照读走即消失别凭清单消失就判断通信失败——可能是刚被读走。示例 5length_of_waiting_L_SDU 7 的含义与风险length_of_waiting_L_SDU最大 7意味着某个 L-SAP 最多攒了 7 个子帧的回复还没读。若长期停在 7说明主站没来读或读得太慢——要么主站轮询周期太长要么该 L-SAP 的回数据被上层卡住。这是server 端数据积压的告警信号。示例 6version 0 vs version 1 选哪个工程选型设备只跑 S-FSK、且你想在蓝图表里直接看到26/134/242 三档 → 用version 0S-FSK IEC 61334-4-32 LLC setup。设备未来可能跑多种 PLC profile、想要更通用的 LLC setup 对象 → 用version 1IEC 61334-4-32 LLC setup三档值靠属性说明约束。两者max_frame_length语义相同切换时不改业务含义只是表呈现差异。示例 7与第 37~40 篇的协作关系一张图Profile generic(7) 读出测量值 → 经 LLC 封装本篇 max_frame_length 限制帧大小 → 经 S-FSK MAC第37/38/39篇成帧/中继/同步 → 主站 GET 时server 把回数据放进 RDR 缓冲本篇 reply_status_list 可见 → 主站轮询 reply_status_list读走 RDR → MAC 层计数第 40 篇 CRC_*/transmissions_*记录这一过程排 S-FSK 端到端问题本篇和 37~40 要一起看。示例 8子帧sub-frame在 S-FSK 里的角色工程示意非本类原文逐字S-FSK 物理层把 LLC 的 L_SDU 拆成若干子帧在信道上编码发送。reply_status_list的length_of_waiting_L_SDU记录待读 L_SDU 占了多少个子帧所以它是子帧数而非字节数——一个 L_SDU 可能跨多个子帧这正是该字段用子帧计数的原因原文valid values 1 to 7。示例 9max_frame_length 触顶时的分段决策工程示意某次 GET-Response 的 APDU 超过max_frame_length信息段容量如默认 134 字节上层 xDLMS 支持分段 → 拆成多帧每帧 ≤ 134不支持 → 请求失败需调大max_frame_length上限 242或减小单次读取量如缩小Profile generic(7) 的 capture 范围。说明134/242 为原文值分段/缩小读取为工程处置示意。示例 10RDR 与 xDLMS 的对应工程视角上层 GET(某 COSEM 对象) → server 把响应 APDU 放进 LLC 的 RDR 缓冲 → reply_status_list 记录该 L-SAP 有未读length_of_waiting_L_SDU 子帧数 → 主站轮询 reply_status_list 发现它 → 主站发实际 GET 读出受 max_frame_length 约束可能多帧 → RDR 清空 → 该条从 reply_status_list 移除这是 S-FSK server 不主动推、主站按需拉的典型模式与 TCP 的 push 相反。示例 11两个版本能否共存工程选型同一台设备通常不会同时建 version0 和 version1 的IEC 61334-4-32 LLC setup——选一个即可。若固件从 version0 迁到 version1max_frame_length语义不变仍是 26/134/242 的 S-FSK 取值对象列表里改 class_id55 的 version 字段、属性对照迁移应用层不用改。示例 12和发现/建档的衔接指向第 42 篇本篇管已建链后的 LLC 帧与 RDR第 42 篇S-FSK Reporting system list(56) 管入网前的发现。两者都属于 S-FSK “链路层之上”先靠 56 发现建档再靠本篇(55)做日常 LLC 收发与 RDR 读取。5. 工程上容易踩的坑reply_status_list是 dyn、本地生成只能 GET不能 SET也别指望有什么方法去清它清它的唯一办法是去对应 L-SAP 读走 RDR。length_of_waiting_L_SDU单位是子帧不是字节有效 1~7排数据积压时别把它当字节数理解。max_frame_length三档只在 S-FSK profile 成立26/134/242 是 S-FSK 的取值换其它下层 profile 要看对应规范别直接套 242 当上限。两版本语义一致、表呈现不同version 1 蓝图没列 Min/Max/Def但说明里给了 26/134/242别误以为 version 1 “没有上限”。max_frame_length往小调是允许的信道差时压帧长是正经优化原文明示但会牺牲吞吐要权衡。清单消失≠通信失败RDR 被读走后条目自然移除别把轮询时不见了当成掉线。L_SAP_selector取值要结合本设备 L-SAP 规划读reply_status_list后要去对应 L-SAP读数据L-SAP 编号搞错会读不到。与 G3-PLC / PRIME 区分本类是 IEC 61334-4-32S-FSK的 LLCG3-PLC、PRIME 各有自己的 MAC/PhL setup 类文档后续有 G3-PLC、PRIME 章节别混用。6. 小结 下期预告本篇要点IEC 61334-4-32 LLC setup(55) 管 S-FSK 的LLC 子层有 version 0带 “S-FSK” 前缀和 version 1通用两版max_frame_length在 S-FSK 下三档为26 / 134 / 242 字节默认 134可往小调以优化弱信道reply_status_list是动态、本地生成的RDR 待读 L-SAP 清单length_of_waiting_L_SDU以子帧数计、有效 1~7该类无方法只能 GETRDR 读走即出清单。下一篇第 42 篇S-FSK Reporting system listclass_id 56—— 把哪些新表发过 DiscoverReport 还没注册记成一张发现清单和本篇的 RDR 机制一起构成 S-FSK 的即插即用 / 自动建档底座。参考资料DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》IEC 61334-4-32 LLC setup(class_id 55, version 0 / 1) 章节文中属性、数据类型、Short name 偏移、结构与引文均与原文一致示例中的 OBIS、取值、字节、时序为帮助理解而构造标注示例/非蓝皮书原文实际以设备对象列表及项目配套规范为准。