企业官网建设流程全解析

DLMS/COSEM 蓝皮书解读（二十八）：Push setup（class_id = 40）—— 让电表主动"推"数据，而不是等主站来问

系列说明：本系列基于 DLMS UA《Blue Book（蓝皮书）第 16 版 · 第 2 部分》，一个接口类一篇。第 27 篇讲了COSEM data protection（class_id = 30），它解决"数据本身怎么加密/签名"。本篇的Push setup（class_id = 40）则是把"通信 + 调度 + 数据保护"拧到一起：让电表在定时/告警/外部触发时，主动把一组数据推给主站或第三方。

上篇回顾：第 27 篇的Data protection提供了"保护参数"这套机制；本篇Push setup直接复用了同款理念——它的push_protection_parameters属性"offers the same options as the Data Protection IC"。可以说 Push 是"带保护的数据主动出门"。

0. 为什么需要这个类 —— 轮询 vs 推送

主站每天挨个表 GET 数据，在表多、通信贵（如 4G 按流量计费）时成本很高，而且异常发生时要等下一个轮询周期才被发现。Push 反过来：

蓝皮书原文（Push setup, Overview）：
“The push is started when the push method is invoked, triggered by a Push ?Single action schedule? object, by an alarm ?Register monitor? object, by a dedicated internal event or externally.”

也就是说，推送可由四种方式触发：手动调push方法、定时（Single action schedule）、越限告警（Register monitor）、内部事件/外部事件。推完还能按通信窗口、随机延时、重试策略执行——一整套"出门逻辑"都在这一个类里。

1. 类蓝图（四版本对照）

Push setup有四版（0/1/2/3），属性数量逐版增加，下面分列。所有版本0...n。

版本 0（version = 0）

方法：push (data) m x + 0x38（仅此一个，无 reset）

版本 1（version = 1）

在 v0 基础上新增数据保护，属性扩到 10 个：

方法：push (data) m x + 0x58

版本 2（version = 2）

再新增 3 个属性、repetition_delay变结构、新增reset方法，属性共 13 个：

方法：push (data) m x + 0x68、reset (data) o x + 0x70

版本 3（version = 3）

属性布局与 v2 完全相同（13 个），差异在send_destination_and_method/port_reference扩展了 CoAP 传输（transport_service新增 9/10）。

方法：push (data) m x + 0x38、reset (data) o x + 0x70

诚实标注（v3 方法短名）：本版概述块里push的 Short name 原文写作x + 0x38，与 v2 的x + 0x68不一致——这大概率是蓝皮书概述段复制遗留（属性布局仍是 13 个）。实现时以设备对象列表的实际偏移为准；本系列照原文呈现，特此说明。

四版演进总表

蓝皮书原文（version 2 Overview）：
“a new column selection mechanism allows explicitly selecting columns of Profile generic object buffer attributes; the repetition_delay attribute now provides an exponential formula… a new push_operation_method attribute… a new confirmation_parameters attribute… a new last_confirmation_date_time attribute…”

2. 属性逐条解读

2.1 push_object_list（要推哪些数据）

定义被推送的属性引用列表。随版本演进结构不同：

• v0：元素object_definition { class_id, logical_name, attribute_index, data_index }（无restriction/columns）。
• v1：元素加restriction（object_definition + restriction_element）。
• v2/v3：元素再补columns（push_object_definition { class_id, logical_name, attribute_index, data_index, restriction, columns }）。

对Profile generic缓冲，三种互斥的条目选择机制：

1. 相对当前时间（relative to current date/time）；
2. 相对末次确认条目（relative to last confirmed entry，v2+）；
3. 绝对区间（absolute，由restriction指定）。

两种互斥的列选择机制（v2+）：① 从列 1 起连续 N 列（data_indexMS 字节低半字节指定）；② 显式列清单（columns指定，data_index低半字节置 0）。

蓝皮书原文（push_object_list NOTE 1）：
“If the push_object_list array is empty, the push operation is disabled.”

——push_object_list为空即"禁用推送"，这是常用的软开关。

2.2 send_destination_and_method（推到哪、怎么推）

send_destination_and_method ::= structure { transport_service: transport_service_type, destination: octet-string, message: message_type }

transport_service_type枚举（各版）：

• v0：0 TCP / 1 UDP / 2 reserved FTP / 3 reserved SMTP / 4 SMS / 5 HDLC / 6 reserved M-Bus / 7 reserved ZigBee / (200–255) 厂商
• v1/v2：在上基础上加8 DLMS Gateway
• v3：再加9 Reliable CoAP / 10 Unreliable CoAP

message_type：0 = A-XDR 编码 xDLMS APDU，1 = XML 编码，128–255 厂商自定义。

蓝皮书原文（send_destination_and_method）：
“Each ?Push setup? object instance specifies a single destination. If it is required to push data to several destinations, several ?Push setup? objects have to be instantiated.”

——一个 Push setup 实例只能有一个目的地；要推多处就得建多个实例。

2.3 communication_window（通信窗口）

array of window_element { start_time: octet-string, end_time: octet-string }，定义推送窗口起止。

蓝皮书原文：
“If no communication windows are defined (array [0]) the push operation is always possible.”

窗口结束前已开始推送会完成；窗口外则等下一个窗口（配合随机延时）。

2.4 randomisation_start_interval

首次推送的最大随机延迟（秒），避免海量表同时推。为 0 则关闭。

蓝皮书原文：
“the random delay is applied when the communication windows opens… The randomisation_start_interval is only active for the first push attempt.”

——随机延时只作用于首次尝试，重试不再随机。

2.5 number_of_retries

最大重试次数（unsigned）。成功后不再重试，直到再次被触发。

2.6 repetition_delay（重试间隔）

• v0/v1：long-unsigned，固定秒数。
• v2/v3：structure { repetition_delay_min: long-unsigned, repetition_delay_exponent: long-unsigned, repetition_delay_max: long-unsigned }，支持指数增长（min起、exponent控制增长、max封顶）。

蓝皮书原文（NOTE 2）：
“The push data is not stored in an intermediate buffer. In the case of push retries, the current values of the attributes may change with every push retry attempt.”

——推送数据不进中间缓冲，重试时取的是当时最新值，可能和首次不同。

2.7 port_reference / push_client_SAP（v1+）

• port_reference：引用某通信端口 setup 对象（选具体通道），不需要可留空octet-string[0]；CoAP 场景可带 UDP 端口：<CoAP setup object>[:<CoAP client UDP port>]。
• push_client_SAP：推送所在的客户端 SAP，安全上下文由该 SAP 关联的Association SN/LN引用的Security setup决定。

2.8 push_protection_parameters（v1+）

与第 27 篇Data protection同款的array of protection_parameters_element（认证/加密/签名 + key_info）。把保护"绑死"在push_object_list这批数据上。

2.9 push_operation_method / confirmation_parameters / last_confirmation_date_time（v2+）

• push_operation_method（enum）：0 未确认+支撑层失败重试 / 1 未确认+缺确认重试 / 2 已确认+缺确认重试。
• confirmation_parameters：structure { confirmation_start_date: date-time, confirmation_interval: double-long-unsigned }，限制"末次确认条目"可选择的时间跨度（interval=0关闭）。
• last_confirmation_date_time（dyn.）：最近一次收到DataNotification.confirm（Result==CONFIRMED）的时间。

3. 方法

• push (data)：触发推送。入参data ::= integer(0)。v0/v1/v2/v3 均为必选（m）。
• reset (data)：把推送过程复位到初始态。data ::= integer(0)。仅v2/v3提供（可选 o）。

蓝皮书原文（push）：
“Activates the push process leading to an attempt to send a DataNotification APDU carrying the push data.”

4. 【实战举例】

示例 1：每天 02:00 定时推日冻结曲线

用Push setup+Single action schedule（第 19 篇）联动：

• Single action schedule的execution_time设02:00，script_logical_name指向本Push setup的push方法。
• Push setup：communication_window设02:00–02:30；randomisation_start_interval = 300（5 分钟内随机错峰）；number_of_retries = 3。
• 触发后数据推到主站 IP（见示例 3）。

示例 2：push_object_list 引用 Profile generic 做"最近 1 天"相对选择

某 15 分钟负荷曲线（class_id=7，OBIS1-0:99.1.0.255），要推最近 96 个条目：

push_object_definition { class_id = 7, logical_name = 01 00 63 01 00 FF, attribute_index = 2, -- buffer data_index = 0x10 60, -- MS高半字节=1(相对当前时间) 低半字节=0(全列) LS=0x60=96条目 restriction = (0) none, columns = [] -- 全列时为空数组 }

（示例，非蓝皮书原文；data_index编码以蓝皮书 Table 9 为准。）

示例 3：send_destination_and_method 各传输示例

CoAP URI 格式（v3）：coap://host[:port][path]，host 不可空，缺省端口 5683。

示例 4：repetition_delay 指数退避（v2/v3）

设repetition_delay_min=60、exponent=2、max=600。第 n 次重试延迟（示意，原文公式未渲染文字）：

• 第 1 次 ≈ 60s，第 2 次 ≈ 60×2=120s，第 3 次 ≈ 240s……超过 600s 封顶在 600s。
  网络越差退得越慢，避免雪崩。

示例 5：Register monitor 越限自动上报

第 18 篇的Register monitor越限后触发脚本，脚本里调用本Push setup的push——于是"电压越限"即时推送给运维平台，无需主站轮询。

示例 6：相对"末次确认条目"推送（v2/v3 独有）

Profile generic缓冲很大、网络又不稳定时，用"relative to last confirmed entry"避免重复推旧数据：

push_object_list 元素: attribute_index = 2, -- buffer data_index = 0x20 60, -- MS高半字节=2(相对末次确认) 低半字节=0(全列) LS=0x60(96条目) restriction = (0) none confirmation_parameters: confirmation_start_date = 2026-01-01 00:00:00 confirmation_interval = 86400 -- 只选最近 1 天内的未确认条目

每次收到DataNotification.confirm（Result==CONFIRMED），last_confirmation_date_time更新，下次推送自动从"上次确认之后"续推。配合push_operation_method=2（确认重试），做到"至少送达一次、不重复"。

蓝皮书原文（last confirmed entry）：
“If relative selective access related to last confirmed entry is used, the last confirmed entry is updated when the DataNotification.confim service primitive is invoked with Result == CONFIRMED.”

5. 工程上容易踩的坑

1. 版本差异是头号坑：v0 没有port_reference/push_client_SAP/push_protection_parameters，也没有reset方法；要保护/多目的地安全上下文必须用 v1+。对接老设备先确认版本。
2. 一个实例一个目的地：推多处要建多个Push setup实例，别指望一个实例填多个地址。
3. push_object_list为空 = 禁用：常用作软开关，但联调"为啥不推"时先查它是不是空数组。
4. 随机延时只首次生效：重试不会错峰，设计重试风暴时别依赖它。
5. 推送值不进缓冲、重试会变：重试拿的是当时最新值，若业务要求"与首次一致"，需另存快照。
6. transport_service只对登记值有效：0–10 + 200–255 合法，其余保留；CoAP 只有 v3 才有（9/10）。
7. 安全上下文跟push_client_SAP走：推的数据用哪个Security setup保护，由该 SAP 关联的 AA 决定，配错 SAP 会推不出去或推错密钥。
8. CoAP 的port_reference可带 UDP 端口：当客户端端点与服务端端点不共享端口时，必须写成<CoAP setup object>:<UDP port>，否则落到服务端端口。
9. v3 的push短名存疑：如 1 节标注，v3 概述块写作x + 0x38，以设备对象列表为准。
10. confirmation_parameters.interval = 0关闭：用"末次确认条目"选择时，记得设confirmation_start_date与interval，否则可能一直选到很旧的数据。
11. 版本选型速查：需要"推带保护的数据 / 指定端口 SAP / 多目的地安全上下文"→ 至少 v1；需要"只推若干列 / 按末次确认续推 / 指数退避 / 可 reset"→ 至少 v2；要用 CoAP 传输 → 必须 v3。新项目无历史包袱直接用 v3。

6. 小结 & 下期预告

本篇要点：

1. Push setup（40）让电表主动推送数据，触发源有 4 种（手动/Single action schedule/Register monitor/内外事件）。
2. 四版演进：v0 基础；v1 加数据保护+端口/SAP；v2 加列选择/指数退避/确认参数/reset；v3 加 CoAP 传输。
3. push_object_list用data_index/restriction/columns精确选条目与列；send_destination_and_method定"推到哪+怎么推"。
4. communication_window+randomisation_start_interval+repetition_delay+number_of_retries构成完整出门重试策略。
5. push_protection_parameters复用第 27 篇Data protection同款保护机制。

下一篇（第 29 篇）：TCP-UDP setup（class_id = 41）—— Push 的transport_service选了 TCP/UDP，那"端口号、MSS、最大并发连接、空闲超时"由谁定？就是这个类。它正是 IEC 62056-47 包装层（Wrapper，IANA 端口 4059）在 DLMS 对象模型里的落点。

参考资料：DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》，Push setup (class_id = 40, version = 0/1/2/3) 章节。文中属性、数据类型、Short name 偏移、方法与引文均与原文一致；示例中的 OBIS、配置值、data_index 编码、CoAP URI 为帮助理解而构造（实际以设备对象列表为准）。v3push方法 Short name 与 v2 不一致处已在文中标注。