【相关】 DL/T 698.45协议（简称“698协议”）是我国电力行业面向智能电表与采集终端的**核心通信标准**，其总功率（即“总有功功率”或“正向有功功率”）采集并非通过传统固定指令码实现，而是基于**面向对象服务模型（Object-Oriented Service Model）**，以标准化APDU（Application Protocol Data Unit）构造`GetRequestNormal`读请求为核心机制。该机制在[ref_1]标题中虽未显式出现“总功率”三字，但其明确指向“DLT645 698采集指令”，且正文完整描述了698采集指令格式、执行流程及数据域含义；更重要的是，[ref_2][ref_4][ref_5][ref_6]均系统性覆盖698.45协议的对象寻址、OAD定义、APDU构造、采集任务配置等关键环节，共同构成对“总功率采集指令”的完整技术支撑体系。因此，所有参考资料均具备强相关性，以下回答将综合引用[ref_1]至[ref_6]。 --- ### 一、协议本质：从“指令”到“服务”的范式升级 DL/T 698.45彻底摒弃了DL/T 645协议中“功能码+数据标识”的硬编码指令模式，转而采用**面向对象的数据建模**。其核心抽象是“对象”（Object），每个计量参数（如电压、电流、功率）被封装为一个具有唯一身份的对象，通过**对象标识符（Object Address Descriptor, OAD）**进行定位。总功率即对应一个预定义的OAD，其读取操作统一由`GetRequestNormal`服务承载，实现了“一套服务、万种数据”的高内聚低耦合设计[ref_2][ref_4]。 | 维度 | DL/T 645 协议 | DL/T 698.45 协议 | 技术演进意义 | | :--- | :--- | :--- | :--- | | **数据寻址方式** | 固定数据标识码（如`00 00 00 00 00 FF`表示当前正向有功总电能） | **5字节OAD**（如`02 00 02 00 00`代表正向有功功率瞬时值） | 支持复杂嵌套结构（如三相分量、需量、事件记录），扩展性达10⁵级[ref_4] | | **通信模型** | 主-从问答式，一次指令仅读一个数据项 | **服务化请求-响应**，单次`GetRequestNormal`可并发读取多个OAD | 通信效率提升70%以上，显著降低信道负载[ref_5] | | **安全机制** | 无原生加密支持，依赖物理层保护 | 内置**国密SM4/AES加密通道**与MAC校验，支持安全模式字（Security Mode Word）控制[ref_5] | 满足《电力监控系统安全防护规定》等强制性要求[ref_5] | | **工程部署** | 需手动维护海量数据标识码映射表 | 通过**采集档案配置**自动加载OAD清单，支持图形化拖拽式方案编排[ref_2] | 运维效率提升3倍，新装调试周期缩短至2小时内[ref_5] | > ✅ **关键结论**：所谓“698协议总功率采集指令”，实质是**符合DL/T 698.45-2017规范的、以OAD=`02 00 02 00 00`为目标的`GetRequestNormal`服务请求报文**，其正确性取决于OAD解析、APDU构造、链路层封装及安全模式配置四重协同[ref_2][ref_4][ref_5]。 --- ### 二、核心指令报文：从OAD到可执行帧的全栈构造 #### 1. OAD精确定义与语义解析 总功率在698协议中对应**正向有功功率瞬时值**（Active Power, Forward Instantaneous），其标准OAD为 `02 00 02 00 00`，遵循“类-属性-索引”五字节结构： - `02`: 类标识（Class ID），代表“测量类（Metering Class）” - `00 02`: 属性ID（Attribute ID），代表“有功功率（Active Power）” - `00 00`: 索引（Index），代表“总功率（Total）”，非分相值[ref_4] > 📌 注：部分厂商扩展OAD `02 00 02 00 01` 表示“A相有功功率”，`02 00 02 00 02` 表示“B相”，此为协议兼容性实践，主站需根据电表档案动态适配[ref_2]。 #### 2. `GetRequestNormal` APDU构造（Python代码示例） 以下代码生成符合[ref_4]定义的APDU，并集成[ref_5]的SM4加密逻辑（简化版）： ```python from Crypto.Cipher import SM4 # 需安装 pycryptodome import struct def build_get_request_normal(oa_list: list) -> bytes: """ 构造 GetRequestNormal APDU oa_list: [(oad_bytes, data_selection), ...], e.g. [(b'\x02\x00\x02\x00\x00', b'\x00')] ref: [ref_2], [ref_4] """ apdu = bytearray() apdu.append(0x01) # PIID: GetRequestNormal (0x01) apdu.append(0x01) # Service ID (Sequence Number) apdu.append(len(oa_list)) # Object Count for oad, ds in oa_list: apdu.extend(oad) # 5-byte OAD apdu.extend(ds) # Data Selection Descriptor (1 byte) return bytes(apdu) def encrypt_apdu(apdu: bytes, key: bytes, iv: bytes) -> bytes: """ SM4-CBC加密APDU（国密算法，ref: [ref_5]） """ cipher = SM4.new(key, SM4.MODE_CBC, iv) # PKCS#7填充 pad_len = 16 - (len(apdu) % 16) padded = apdu + bytes([pad_len] * pad_len) return cipher.encrypt(padded) # 示例：采集总功率 + 当前电压 oad_total_power = b'\x02\x00\x02\x00\x00' # 总有功功率 oad_voltage = b'\x02\x00\x01\x00\x00' # 总电压 apdu_raw = build_get_request_normal([ (oad_total_power, b'\x00'), (oad_voltage, b'\x00') ]) # 加密（使用国网标准密钥与IV） sm4_key = bytes.fromhex("2B7E151628AED2A6ABF7158809CF4F3C") sm4_iv = bytes.fromhex("000102030405060708090A0B0C0D0E0F") apdu_encrypted = encrypt_apdu(apdu_raw, sm4_key, sm4_iv) print(f"Raw APDU (hex): {apdu_raw.hex()}") print(f"Encrypted APDU (hex): {apdu_encrypted.hex()}") ``` #### 3. 完整链路层帧封装（RS485场景） 依据[ref_1]与[ref_3]，完整帧需包含物理层头尾与校验： ```c // 示例：地址为01 00 00 00 00 01的电表，发送加密后APDU 68 1A 00 1A 00 68 // 帧头：68 + L=0x1A + L + 68 08 // 控制域C：主站→终端，启动帧 01 00 00 00 00 01 // 地址域A（6字节） 01 // 应用层控制域ACD（带确认） 01 // 服务标识SI（GetRequestNormal） <apdu_encrypted> // 此处填入上一步生成的加密APDU（长度=0x1A-7=23字节） XX XX // 校验和CS（异或校验） 16 // 结束符 ``` > 🔑 **安全要点**：若电表启用了安全模式（Security Mode Word = `0x03`），则必须启用SM4加密；否则返回`0x84`（安全访问拒绝）错误[ref_5]。 --- ### 三、工程落地：从单次召测到全生命周期管理 在实际电力采集系统中，“总功率采集”绝非孤立指令，而是嵌入**采集任务生命周期**的标准化流程： | 阶段 | 关键操作 | 参考资料依据 | | :--- | :--- | :--- | | **1. 档案配置** | 在主站录入电表资产信息，绑定698.45协议类型，并在“采集方案”中勾选OAD `02 00 02 00 00`作为必采项，设置采集周期（如15分钟）[ref_2] | [ref_2] | | **2. 任务下发** | 主站生成`TaskDownload`服务请求，将采集方案推送到集中器/DTU网关（如ZL400DTU）[ref_3] | [ref_3] | | **3. 数据召测** | 运维人员通过“一键召测”功能触发`GetRequestNormal`，网关自动完成APDU构造、加密、帧封装、重传等，结果实时回传至主站[ref_5] | [ref_5] | | **4. 数据解析** | 主站接收到响应APDU后，按[ref_4]定义的A-XDR编码规则解码：`02 00 02 00 00`后跟随`0x06`（Long型）+ `4字节值`，再结合对象字典中的单位（kW）、小数位（2位）换算为`123.45 kW` | [ref_4] | | **5. 异常闭环** | 若响应中`Result Code ≠ 0x00`（如`0x04`=对象不存在），系统自动触发“搜表”或“参数下发”流程，重新同步电表对象字典[ref_6] | [ref_6] | > 🌐 **典型场景验证**：某工业园区部署的迷你主站（[ref_6]）实测显示，对1000台698电表发起总功率批量召测，平均单表响应时间≤800ms，数据完整率99.99%，故障自愈率超95%[ref_6]。 --- ### 四、避坑指南：高频错误与权威解决方案 | 错误现象 | 根本原因 | 解决方案（引用来源） | | :--- | :--- | :--- | | **返回`0x81`（服务不支持）** | 电表固件版本过低，未实现`GetRequestNormal`服务 | 升级电表至DL/T 698.45-2017兼容固件，并通过`ParameterDownload`服务下发新OAD字典[ref_2] | | **返回`0x84`（安全访问拒绝）** | 未启用加密或密钥不匹配 | 使用[ref_5]所述“一键加密工具”，自动计算SM4密钥与MAC，支持离线密钥灌装与在线密钥协商 | | **数据值恒为0或溢出** | 小数点位配置错误，或未按A-XDR规则解析 | 查阅[ref_4]附录B的“OAD数据类型映射表”，确认`02 00 02 00 00`的Scale Factor为`10⁻²`，需右移2位 | | **批量召测丢包严重** | DTU网关缓存不足，无法处理多OAD并发请求 | 选用支持“APDU流水线处理”的ZL400DTU（[ref_3]），其内置双核MCU可并行处理32路698请求 | --- 综上，DL/T 698.45协议下的总功率采集，是一套融合**对象建模、服务化通信、国密安全、工程化配置**的完整技术体系。开发者须跳出“指令思维”，深入理解OAD语义、APDU构造规范与主站-终端协同流程，方能在智能电网数字化转型中构建高可靠、高安全、高效率的用电信息采集能力[ref_2][ref_4][ref_5][ref_6]。