企业官网建设流程全解析

DLMS/COSEM 蓝皮书解读（二十一）：IEC twisted pair (1) setup（class_id = 24）—— 载波双绞线介质（IEC 62056-3-1）的通信通道建模

系列说明：本系列基于 DLMS UA《Blue Book（蓝皮书）第 16 版 · 第 2 部分》，一个接口类一篇。第 20 篇讲了IEC HDLC setup（class_id = 23），它管内的是 HDLC 帧层的链路参数（波特率、收发窗口、信息字段长度等），但没回答"底层介质到底是什么、设备怎么被主站寻址"。本篇的IEC twisted pair (1) setup（class_id = 24）解决的就是"载波双绞线（twisted pair with carrier signalling，即 IEC 62056-3-1 介质）上的通信通道如何配置"——它是蓝皮书里"通信介质建模类"的第一块，后面还会依次遇到 M-Bus、PLC 等介质类。

上篇回顾：第 20 篇我们把通信链路参数收敛到了 HDLC 帧层；但如果底层用的是 IEC 62056-3-1 的载波双绞线（常见于欧洲水/气表，以及和 M-Bus 物理层类似的场景），光有 HDLC 还不够——还要告诉设备"用哪种载波 profile、跑多少波特、主站地址列表是什么、忘记地址时回哪个 TAB"。这正是本篇IEC twisted pair (1) setup的职责。

0. 为什么需要这个类

先把介质讲清楚。所谓twisted pair with carrier signalling（带载波信令的双绞线），是 IEC 62056-3-1 定义的一种计量通信介质：在普通双绞线上叠加载波信令来传数据。蓝皮书写得很直白——它的两大优点是安装方便和因载波信令带来的通信可靠性。这种介质有三种典型布点方式：

• 在LNAP（Local Network Access Point，本地网络接入点）和计量终端设备（M interface）之间；
• 在 LNAP 和NNAP（Neighbourhood Network Access Point，邻域网络接入点）之间；
• 以及HHU（手持单元）与计量终端设备之间的直接连接。

IEC 62056-3-1 规定了三种通信 profile：

1. without DLMS—— 纯载波协议，不带 DLMS；
2. with DLMS—— 载波上跑 DLMS；
3. with DLMS/COSEM—— 载波上跑完整的 DLMS/COSEM（最新、能力最强）。

蓝皮书原文（IEC twisted pair (1) setup, General）：
“The communication medium twisted pair with carrier signalling is widely used in metering. The main advantages of using this medium are the ease of installation and the reliability of communications due to carrier signalling.”

关键点在版本差异上：

蓝皮书原文（IEC twisted pair (1) setup, General）：
“The IC ‘IEC Twisted pair (1) set up’ (class_id = 24, version = 0) supports the first two communication profiles specified in . The new version 1 supports the DLMS/COSEM profile. With its introduction, the use of version 0 is deprecated.”

也就是说：version 0 只支持前两种 profile，version 1 才支持 DLMS/COSEM profile，且 version 0 已被弃用。为什么 DLMS/COSEM profile 值得专门出一个 version？因为它引入了一个Support Manager Layer（支持管理层）实体，负责：

• 总线的初始化（initialisation of the bus）；
• 发现管理（discovery management）；
• 告警管理（alarm management）；
• 通信速率协商（communication speed negotiation）；

并且 Transport Layer 支持分段与重组（segmentation and reassembly），最高可到9 600 Bd。

所以"为什么需要这个类"的答案是：当你要在载波双绞线介质上把设备接进 DLMS/COSEM 网络时，必须有一个对象来描述"这条载波通道怎么配置"——用哪个 profile、开多大波特、主站地址有哪些、丢失地址时回哪个 TAB；否则设备连"我是谁、我听谁的"都说不清。

1. 类蓝图

这个类没有方法（Specific methods 一栏为空，两版皆如此），全部是static属性，靠 GET/SET 配置。

版本 1（version = 1，推荐，支持 DLMS/COSEM profile）

蓝皮书原文（IEC twisted pair (1) setup, Overview）：
“Instances of this IC allow setting up data exchange over the medium twisted pair with carrier signalling as specified in . Several communication channels can be configured.”

IEC twisted pair (1) setup 0...n class_id = 24, version = 1

版本 0（version = 0，已弃用，仅支持前两种 profile）

IEC twisted pair (1) setup 0...n class_id = 24, version = 0

两版差异一句话：v1 用mode+comm_speed取代/补充了配置能力，去掉了 v0 的secondary_address和fatal_error属性；v1 下"从站地址（ADS）"改由独立的MAC address（class_id = 43, version = 0）对象承载，"致命错误"改由设备提供的独立fatal error register（Data 对象）承载。

蓝皮书原文（IEC twisted pair (1) setup, General）：
“The following COSEM interface objects are necessary to set up data exchange over the medium Twisted pair with carrier signalling: ‘IEC Twisted pair (1) setup’: class_id = 24, version = 1; ‘MAC address’: class_id = 43, version = 0; ‘Data’: class_id = 1, version = 0.”

2. 属性逐条解读

2.1 logical_name（两版相同）

标识本IEC twisted pair (1) setup对象实例。

蓝皮书原文（IEC twisted pair (1) setup, Attribute description）：
“Identifies the ‘IEC twisted pair setup’ object instance.”

6 字节 OBIS，static，Short name 基址x。

2.2 mode（仅 version 1）

接口的工作模式。

蓝皮书原文（IEC twisted pair (1) setup, mode）：
“This attribute specifies the working mode of this interface”

注：属性表里mode的 Min/Max 标为 0/1，而 enum 定义本身允许到 250（含厂商自定义段）。按原文忠实呈现：实现上标准模式只有 0、1，其余为保留/厂商段。

2.3 comm_speed（仅 version 1）

端口支持的通信速率。static，Short namex + 0x10，缺省值 (2) = 1200 baud。

蓝皮书原文（IEC twisted pair (1) setup, comm_speed）：
“Holds the communication speed supported by the port.”
且原文 NOTE：“IEC 62056-3-1:2021 supports baud rates from 1 200 to 9 600.”

踩坑预警：comm_speed表里允许到 38400，但 IEC 62056-3-1:2021 规范本身只支持 1200–9600。19200/38400 属于"类允许、标准介质不支持"的值，配了主站也不一定认——别盲目拉满速率。

2.4 primary_address_list（两版都有，类型不同）

保存本真实设备（作为从站 / secondary station）为每个逻辑设备所编程的**主站地址（ADP，Primary Station Address）**列表。

• v1：primary_address_list_type ::= array unsigned（元素是 unsigned，见 IEC 62056-3-1:2021, 5.2.4）；
• v0：primary_address_list_type ::= array primary_address_element，其中primary_address_element ::= octet-string，长度1 字节。

蓝皮书原文（v1, primary_address_list）：
“Holds the list of Primary Station Addresses (ADP) for which each logical device of the real equipment (the secondary station) has been programmed.”

2.5 tabi_list（两版都有）

"忘记站呼叫（forgotten station call）"场景下，从站被编程的TAB(i)列表。类型均为tabi_list_type ::= array tabi_element，tabi_element ::= integer。

蓝皮书原文（v1, tabi_list）：
“When using IEC 62056-3-1 profile with DLMS/COSEM, the tabi_list attribute is made of only one element of value 0, the value used for the discovery process.”

也就是说在 DLMS/COSEM profile 下，tabi_list固定只有一个元素、值为 0，专门用于发现过程。

2.6 secondary_address（仅 version 0）

保存从站地址 ADS（6 字节 octet-string）。v1 把它移到了MAC address（class_id = 43）对象里。

蓝皮书原文（v0, secondary_address）：
“Secondary_address memorizes the ADS of the secondary station that corresponds to the real equipment.”—“octet-string (SIZE(6))”

2.7 fatal_error（仅 version 0，dyn.）

最近一次致命错误的代码，初始值0x00，enum：

注：v1 下不再有此属性；改为由设备提供独立的fatal error register（见下）。

3. 没有方法：靠对象协作完成建模

本类Specific methods 一栏为空，没有 ACTION 方法。它纯粹是"配置容器"，所有设置通过 SET 属性完成。但 DLMS/COSEM profile（v1）要真正跑起来，需要三个对象协同，不是本类单打独斗：

1. IEC twisted pair (1) setup（class_id = 24, version = 1）—— 本类，描述通道参数；
2. MAC address（class_id = 43, version = 0）—— 承载 6 字节 ADS 从站地址；
3. Data（class_id = 1, version = 0）—— 承载fatal error register（致命错误寄存器）。

蓝皮书原文（IEC twisted pair (1) setup, Fatal error register）：
“Each device implementing the DLMS/COSEM communication profile specified in shall provide an error register holding the result of the last communication with the primary station.”

fatal error register 是一个bit-string（位串），逐位含义如下：

注意：Bit 2/3/5/6 标了"Not relevant for secondary station (server)"，即作为电表（服务器/从站）时这些位基本不会置位，它们描述的是主站（客户端）视角。排错时别看到这几个位是 0 就以为是异常。

附：MAC address 的 ADS 结构（class_id = 43，version = 0）

从站地址 ADS 固定6 字节，组成如下：

蓝皮书原文（EXAMPLE）：031267123456→
03: ITRON International；12: 制造年份 2012；67: 单相智能电表 LINKY；123456: 当年起始序列号。

4. 【实战举例】

示例 1：一块载波双绞线水表的标准对象配置（DLMS/COSEM profile，v1）

假设一个水表通过载波双绞线接入，逻辑设备地址 1。我们用三个对象建模（以下 OBIS/取值为示例，非蓝皮书原文，实际以设备对象列表为准）：

logical_name的 A-XDR 编码（0-0:23.0.0.255→ 6 字节00 00 17 00 00 FF，octet-string 标签0B）：

0B 06 00 00 17 00 00 FF

comm_speed = 5（9600 baud）作为 enum 的 GET 响应示意（enum 标签16，长度 1，值 5）：

16 01 05 （示例：A-XDR 编码示意，enum 标签以 0x16/22 为例）

示例 2：ADS / MAC 地址拆解

上面MAC address的 buffer 若取示例031267123456，逐字节展开：

• 03→ manufacturer_id = 03（ITRON）
• 12→ year_of_manufacture = 12（2012 年）
• 67→ equipment_id = 67（LINKY 单相表）
• 123456→ device_serial_number（BCD，3 字节）

这串 6 字节就是 ADS，世界唯一、出厂固化、终身有效（“shall be worldwide unique and assigned by the manufacturer … valid through the lifetime”）。

示例 3：SN 短名读取通道参数

以 v1 为例，base name 为x（由 logical_name 派生的 13 位短名）。想读comm_speed，直接 GET 短名x + 0x10；读primary_address_list用x + 0x18；读tabi_list用x + 0x20。注意attribute_index 的短名偏移是类内固定的，不能跨类套用——比如IEC HDLC setup（class_id = 23）的comm_speed偏移是x + 0x10，本类恰好同名同偏移纯属巧合，换类必须重新查表。

示例 4：从 version 0 升级到 version 1 的迁移清单

若旧设备用 v0，迁移到 v1 要做三件事：

1. 删掉secondary_address属性——它的 ADS 改存到新建的MAC address（class_id = 43）对象；
2. 删掉fatal_error属性——改由独立Data对象承载 fatal error register（bit-string）；
3. 补上mode（通常设 1 = always active）和comm_speed（建议 5 = 9600，贴合 IEC 62056-3-1:2021 上限）。

蓝皮书原文明确：“With its introduction, the use of version 0 is deprecated.”新项目直接用 v1。

示例 5：DLMS/COSEM profile 的发现过程（v1 特有）

v1 之所以要引入 Support Manager Layer，正是因为"发现"不再是简单的地址轮询。一个典型上电入网流程（流程为工程示意，非蓝皮书原文的步骤清单）：

1. 从站IEC twisted pair (1) setup设mode = 1（always active），tabi_list = [0]；
2. 主站发起发现（discovery），此时tabi_list的[0]就是发现过程用的 TAB；
3. 主站通过MAC address（class_id = 43）读到从站 6 字节ADS，确认"世界上这台设备是谁"；
4. Support Manager Layer 完成总线初始化 + 速率协商（最高到 9600 Bd），Transport Layer 开启分段/重组；
5. 此后正常 xDLMS 交互（GET/SET），异常时看Data对象里的fatal error register（bit-string）。

这里能看到 v1 相比 v0 的本质跃迁：v0 靠 secondary_address + fatal_error 属性就地解决；v1 把它们拆成 MAC address(43) + Data(1) 两个协作对象，并多了发现/协商/分段能力。

5. 工程上容易踩的坑

1. 波特率超规范：comm_speed允许到 38400，但 IEC 62056-3-1:2021 只认 1200–9600。配 19200/38400 类上合法、介质上不自洽，主站可能直接不通信。

2. v0 与 v1 地址承载方式不同：v0 把 ADS 放在secondary_address，v1 放在独立MAC address（class_id = 43）。主站发现逻辑要按版本分支，不能假设"地址一定在某属性里"。

3. fatal_error 的位语义要看角色：Bit 2/3/5/6 只对主站（客户端）有意义，作为电表（服务器/从站）时这些位不会置位；排错别误判。

4. tabi_list 在 DLMS/COSEM profile 下固定为 [0]：这是发现过程专用值，别当成"可自由填的 TAB 列表"去配业务 TAB。

5. primary_address_list 元素类型两版不一致：v0 是octet-string(1 字节)，v1 是unsigned。解析对象列表时按 version 选择元素类型，否则长度对不上。

6. 三个对象缺一不可：v1 下"twisted pair setup + MAC address + Data(fatal error register)"是成组出现的。只建 setup 对象、忘建 MAC address，从站身份就缺失，发现过程会失败。

7. profile 与类版本要匹配：version 0 不支持 DLMS/COSEM profile（没有 Support Manager Layer、不能到 9600 以上、没有分段重组）。要用 DLMS/COSEM 能力就必须 v1。

8. 注册服务依赖 Euridis 协会：原文指出使用 IEC 62056-3-1 规定的通信 profile 需要 Euridis 协会提供的注册服务（registration services）。涉及厂商 ID、设备 ID 的分配要走 Euridis 渠道，别自己编 manufacturer_id / equipment_id，否则 ADS 不合规、跨厂商互通会出问题。

6. 小结 & 下期预告

本篇要点：

1. IEC twisted pair (1) setup（class_id = 24）建模 IEC 62056-3-1 载波双绞线介质上的通信通道，无方法，全 static 属性；
2. v1 支持 DLMS/COSEM profile，v0 已弃用；v1 新增mode/comm_speed，把 ADS 和 fatal error 移到MAC address(43) 与Data(1) 对象；
3. comm_speed最高 38400，但介质规范只到 9600；primary_address_list/tabi_list两版类型略不同；
4. fatal error register 是 bit-string，部分位仅对主站有意义。

下一篇（第 22 篇）：M-Bus slave port setup（class_id = 25）—— 有线 M-Bus（从站侧）端口配置。本篇讲的是"载波双绞线"这种偏 Euridis 体系的介质；下一篇转到更常见的有线 M-Bus：它要建模的是"从站端口支持哪些波特率、总线地址怎么分配、上电后有没有被分配到地址"——和本篇的"载波通道"互为不同物理介质的对照，也都服务于"设备怎么被主站找到并通信"这个同一主题。

参考资料：DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》，IEC twisted pair (1) setup(class_id = 24, version = 0/1) 章节。文中属性名、数据类型、Short name 偏移、enum 取值、fatal error register 位定义、ADS 结构、引文均与原文一致；示例中的 OBIS、配置取值、A-XDR 字节为帮助理解而构造（实际以设备对象列表为准）。