简介DLMS协议是电能表与抄表系统间通信的国际标准这份C#源代码实现电能表数据采集功能主要面向需要集成多品牌电表、开发上位机采集程序的.NET开发人员。压缩包共13个文件以11个C#源码文件为核心覆盖HDLC链路层、字节转换、FCS校验、DLMS助手及PduType、BerType等协议类型定义另含1个JSON配置文件和1个项目文件包体仅14KB结构紧凑。已有527人学习下载适合具备基础C#能力、希望快速搭建DLMS客户端原型的开发者参考。源码实现了从链路层到应用层的完整调用链包含APDU编解码、连接管理、数据读写、异常处理及安全认证框架可直接基于项目文件编译运行并根据具体电表型号与通信场景调整配置。开发过程中需注意LN/SN两种标识模式的选择同时结合数据保护法规进行安全加固。1. DLMS/COSEM协议采集C#开发者的第一个门槛在哪一提到“DLMS协议采集C#源代码”很多人第一反应是终于有个现成的C#客户端源码可以直接抄了。但真正拿到手才发现DLMS/COSEM不是Modbus那种“读几个寄存器”的简单规约它是IEC 62056系列里一套完整的电能表通信体系。C#采集源代码要做的事情非常具体通过TCP或串口把智能电表里的电量、电压、电流、功率因数、最大需量、负荷曲线读回来交给上位机、能耗平台或数字孪生系统。适合谁做C#上位机、工厂能源管理、充电桩计量、光伏监控的开发者。第一个门槛不是你C#语法不行而是不理解电表数据如何映射成对象OBIS码、接口类、属性这三样搞明白了写采集程序就是流水线作业。2. 先理解DLMS协议栈从电能表到C#对象的映射关系2.1 DLMS/COSEM的基本通信模型客户端、服务器、HDLC与TCPDLMS/COSEM不是单一协议而是分层的通信体系。物理层有RS485、红外、TCP/IP数据链路层通常采用HDLC帧应用层则是ASN.1编码的请求/响应。电表端是“服务器”C#采集端是“客户端”。整个采集过程不是“发一帧读一次”那么简单必须走完下面四个阶段建立通信介质连接TCP连接或打开串口HDLC链路层握手客户端发SNRM命令电表回UA帧应用层关联客户端发AARQ请求电表回AARE响应完成“会话建立”发送Get-Request读取指定OBIS对象解析响应最后释放连接。这四个阶段里最容易被忽略的是第2步和第3步是分开的。我见过不少同事把AARQ字节硬编码在SNRM前面结果电表完全不回包。因为电表端还处于链路层未建立状态不会理睬应用层内容。更合理的方式是在C#中用状态机把“物理连接、HDLC连接、应用连接、读取数据”四步分开后面我会给出状态机代码。DLMS和Modbus在工程上的差异也直接决定你怎么写C#代码。Modbus的寄存器地址是厂商自定义的你的程序必须跟着电表厂的点表走换个牌子就要重新调映射。DLMS反过来电表数据建模标准化同一个“正向有功总电能”几乎都是OBIS码1.0.1.8.0.255。这意味着你的采集程序可以做成配置驱动换表型通常只改OBIS配置不用改协议代码。下表是一个对比维度DLMS/COSEMModbus RTU/TCP数据模型标准COSEM对象厂商自定义寄存器连接管理HDLC握手应用层关联无状态直接读寄存器读取单点数据Get-RequestRead Holding Registers认证与安全LLS、HLS支持加密一般无开发复杂度高编码/长度规则多简单适用场景智能电表、国际项目现场仪表、PLC、传感器这里要记住一个结论DLMS的最大优势不是“抄表”而是“数据模型统一”。你在C#里创建一个ObisPoint列表就相当于把一整类电表的数据模型全部建模了。这也是后面把DLMS采集做成通用模块的基础。2.2 关键概念OBIS码、接口类、属性与方法的编解码DLMS把所有有用数据封装成“COSEM对象”。每个对象有一个逻辑名也就是OBIS码格式是A-B:C.D.E.F六段数字。举个例子1.0.1.8.0.255A1表示电能B0表示无通道C1表示“计量类”D8表示电能值E0表示总费率F255表示当前默认存储区。这个编码在所有DLMS电表上基本一致。每个COSEM对象还属于某个接口类接口类定义了这个对象有哪些属性和方法。比如最常用的“寄存器”接口类Class ID1它的属性有属性1逻辑名也就是OBIS码本身属性2当前值这是采集程序最常读的属性属性3标度Scale用于换算倍数属性4单位Wh、kWh、V、A等。读取的时候你要告诉电表三个信息OBIS码、接口类ID、属性ID。电表返回的数据是带类型的值可能是有符号整数、无符号整数、浮点数、八位串或结构体。在C#里我习惯先建一个点位模型来映射它public class ObisPoint { public string Code { get; set; } // 1.0.1.8.0.255 public byte ClassId { get; set; } // 接口类ID例如1 public byte AttributeId { get; set; } // 属性ID例如2 public string DataType { get; set; } // LongUnsigned / DoubleLong / OctetString public double Scale { get; set; } // 0.001 public string Unit { get; set; } // kWh public string Description { get; set; } // 正向有功总电能 }这段代码的逻辑很直接ClassId和AttributeId决定读哪个对象的哪个属性DataType决定解析时用BinaryReader读Int32还是读DoubleScale是原始寄存器值到业务值的换算系数。比如很多电表内部存的是Wh业务表用kWhScale就是0.001。你以为这么简单就完了实际还有电表内部寄存器值是“0.001Wh”的情况Scale会变成1甚至是0.000001。所以Scale和Unit必须做成可配置项不要写死在代码里。2.3 选型直接用开源库还是自己按协议栈写现在网上一搜“DLMS协议采集C#源代码”能翻到不少代码片段但大多数不完整。真正能落到生产项目的路子有三条一是直接用开源库比如Gurux.DLMS二是参考开源C/C协议栈用C#重写核心部分三是自己照着IEC 62056标准硬啃全链路自研。我的建议是一个选型决策表项目情况建议工期紧要对接多种电表用成熟开源库快速做原型嵌入式环境不能有外部依赖参考开源实现精简自研纯学习想搞透协议自己实现最小闭环再扩展生产环境高安全要求必须用经过验证的库不要自造加密轮子不少团队一开始雄心勃勃要“手写DLMS协议”最后在HDLC的FCS校验和BER长度编码上卡了两周。DLMS最难的不是读数据而是高级认证HLS里面有哈希、加密、系统标题等复杂流程自研很容易埋坑。所以我的常见做法是先用开源库把整条链路跑通把OBIS配置、超时重试、任务调度这些业务逻辑写好再根据需求替换底层APDU编码模块。代码结构是自己的协议栈用成熟库风险最小收益最大。3. 搭建C#采集工程最小可运行的DLMS客户端实现3.1 通信层串口/TCP连接与HDLC帧打包DLMS采集程序的C#实现核心是让“通信层”和“协议层”解耦。通信层只做连接和收发字节流协议层负责编解码。如果是RS485串口用SerialPort如果是TCP用TcpClient。电表TCP默认端口常见是4059但也有4058、8000等必须做成配置项。先看TCP连接和收发的最小代码public class DlmsConnection : IDisposable { private TcpClient _tcp; private NetworkStream _stream; public async Task ConnectAsync(string ip, int port, int timeoutMs 3000) { using var cts new CancellationTokenSource(timeoutMs); _tcp new TcpClient(); await _tcp.ConnectAsync(ip, port, cts.Token); _stream _tcp.GetStream(); _stream.ReadTimeout timeoutMs; _stream.WriteTimeout timeoutMs; } public async Taskbyte[] SendReceiveAsync(byte[] frame) { await _stream.WriteAsync(frame); using var ms new MemoryStream(); var buf new byte[4096]; while (_tcp.Available 0) { int n await _stream.ReadAsync(buf.AsMemory(0, buf.Length)); if (n 0) break; ms.Write(buf, 0, n); } return ms.ToArray(); } public void Dispose() { _stream?.Dispose(); _tcp?.Dispose(); } }这段代码有几个工程经验ConnectAsync里必须设置超时否则IP不对时连接会挂很久。SendReceiveAsync里用_tcp.Available 0判断是否有数据继续到达而不是只读一次。因为DLMS的HDLC帧偶尔会拆成多个TCP包一次性读可能只读到半个帧。缓冲区大小4096足够若电表开启长帧分段要改成循环接收并拼接。HDLC帧打包是通信层另一个关键点。HDLC帧以0x7E开头和结尾中间包括帧格式、地址、HCS、信息字段、FCS。如果数据字节里出现0x7E还需要做0x7D 0x5E转义否则接收方会把数据里的0x7E错认成帧尾。下面是一个聚焦结构的HDLC帧组装方法省略了CRC计算细节public static class HdlcFrameBuilder { public static byte[] BuildFrame(byte control, byte[] payload, byte clientAddr, byte serverAddr) { using var ms new MemoryStream(); ms.WriteByte(0x7E); // 起始标志 ms.WriteByte(0x00); // 帧格式高位示意值 ms.WriteByte(0x08); // 帧格式低位类型/序列示意值 ms.WriteByte(serverAddr); // 目的地址 ms.WriteByte(clientAddr); // 源地址 ms.WriteByte(control); // 控制字段SNRM0x93UA0x73 ms.Write(payload, 0, payload.Length); // HCS/FCS与转义省略生产环境必须按标准实现 ms.WriteByte(0x7E); return ms.ToArray(); } }这个方法虽然不能直接用于生产但它展示了帧的组装顺序。control字段决定帧类型0x93是SNRM0x73是UA0x53是其他命令。实际项目中HCS和FCS的CRC算法、帧格式字段的位定义必须用标准里的定义或抓到的电表报文来验证。如果你在这块不严谨后面连接是否成功就成玄学了。3.2 建立应用层连接C#中的AARQ/AARE交互链路层握手成功之后进入应用层连接。这一步的一个坑是电表有连接数上限。如果上一次连接没有正常关闭新连接会一直等待甚至直接被拒绝。所以我会在C#里用状态机管理DLMS会话的生命周期。public enum DlmsSessionState { Disconnected, LinkConnected, AppConnected, Reading, Failed }然后看完整的打开连接流程public async Taskbool OpenAsync(string password) { try { // 1. 链路层SNRM - UA var snrm HdlcFrameBuilder.BuildFrame(0x93, Array.Emptybyte(), _clientAddr, _serverAddr); var ua await SendReceiveAsync(snrm); if (!IsUaResponse(ua)) return false; _state DlmsSessionState.LinkConnected; // 2. 应用层AARQ - AARE var aarq BuildAarq(password); var aare await SendReceiveAsync(aarq); if (!IsAareOk(aare)) return false; _state DlmsSessionState.AppConnected; return true; } catch (Exception ex) { _state DlmsSessionState.Failed; _lastError ex.Message; return false; } }这个代码块里的关键点是BuildFrame只负责把控制字段和payload包成HDLC帧BuildAarq负责生成应用层APDU。我把这两层拆开是因为换表型时大概率只需要改应用层编码链路层不用动。IsUaResponse和IsAareOk是两个简单的响应校验函数判断响应标签和结果码。比如UA响应的控制字段是0x73AARE中结果标签为0xA2时还要解析结果值。一个重要参数是password。DLMS低级安全LLS认证里密码是明文配在AARQ中的高级安全HLS认证则要预置系统标题、身份标识、算法版本、挑战值等只传一个字符串不够。如果电表启用了HLS我会把Authentication枚举拆成None、Low、High代码里分别走三套分支免得混在一起。3.3 读取电表数据Get Request与Parse响应的代码骨架连接建立后读取数据就是“发Get、收Response、解析”的循环。下面是读取一个寄存器点位的骨架public async Taskobject ReadAttributeAsync(ObisPoint point, CancellationToken token) { var req BuildGetRequest(point.ClassId, point.AttributeId, point.Code); var resp await SendReceiveAsync(req); return ParseGetResponse(resp, point.DataType); }BuildGetRequest负责把OBIS码和属性ID组装成应用层PDU。一个简化写法private byte[] BuildGetRequest(byte classId, byte attributeId, string obis) { var o ObisParser.Parse(obis); // 返回6个字节 var pdu new Listbyte { 0xC0, // Get-Request PDU标签 0x01, // invoke-id 0x01, // COSEM attribute descriptor标签 classId, // 接口类ID o[0], o[1], o[2], o[3], o[4], o[5], attributeId }; return HdlcFrameBuilder.BuildFrame(0x53, pdu.ToArray(), _clientAddr, _serverAddr); }这里要说明两点。第一0xC0是Get-Request的PDU标签0x01后的invoke-id是事务号同一连接上并发请求多时需递增或循环识别响应。很多电表同一时间只支持一个请求所以固定为1问题不大。第二BER编码里容器标签后必须带长度字段我这个代码为了突出结构省略了长度计算。实际开发中这部分要么用开源库的编码器要么严格按BER长度规则写否则响应会解析错。解析响应的关键在于跳过响应头定位到数据值private object ParseGetResponse(byte[] resp, string dataType) { int pos FindTag(resp, 0x01); // 简化定位到数据标签 byte type resp[pos]; int len ReadBerLength(resp, ref pos); return dataType switch { LongUnsigned ReadLongUnsigned(resp, pos, len), DoubleLong ReadDoubleLong(resp, pos, len), OctetString Encoding.ASCII.GetString(resp, pos, len), _ throw new NotSupportedException($未支持的数据类型: {dataType}) }; }这里要注意dataType跟你读表前配置是否一致。DLMS的数据类型标签有0x06八位串、0x09字符串、0x0F时间等不同标签对应C#里的不同读取方式。如果电表返回的是Struct类型那解析就更复杂要一层层拆。第一次接陌生电表时我建议先把原始响应用Convert.ToHexString打印出来对照文档确认类型再写解析逻辑不要凭猜。4. 把DLMS数据落库OBIS映射与批量采集任务调度4.1 定义OBIS清单与数据模型用JSON配置点位生产项目里电表不止读一个电量还要读电压、电流、功率因数、四象限电能、负荷曲线。把点位清单写死在代码里换个项目就得重新编译。我一般会把整个点位清单放到JSON配置文件里用C#的System.Text.Json反序列化成ListObisPoint。这样跟DLMS协议栈解耦运营人员也能维护。配置示例[ { Code: 1.0.1.8.0.255, ClassId: 1, AttributeId: 2, DataType: LongUnsigned, Scale: 0.001, Unit: kWh, Description: 正向有功总电能 }, { Code: 1.0.32.7.0.255, ClassId: 1, AttributeId: 2, DataType: LongUnsigned, Scale: 0.001, Unit: V, Description: A相电压 }, { Code: 1.0.31.7.0.255, ClassId: 1, AttributeId: 2, DataType: LongUnsigned, Scale: 0.001, Unit: A, Description: A相电流 } ]在C#里加载这个配置public ListObisPoint LoadPoints(string jsonPath) { var json File.ReadAllText(jsonPath); var options new JsonSerializerOptions { PropertyNameCaseInsensitive true, ReadCommentHandling JsonCommentHandling.Skip }; return JsonSerializer.DeserializeListObisPoint(json, options); }这里有个C# JSON匹配配置的坑PropertyNameCaseInsensitive必须开因为我们经常会在JSON里写ClassId大小写不一致不开这个选项就会少点。ReadCommentHandling JsonCommentHandling.Skip可以允许配置文件里写注释运维同事非常需要。另外还要注意DataType建议用字符串而非枚举因为不同DLMS库和不同电表会有自定义类型字符串最容易扩展。4.2 采集任务的并发、重试与超时控制C#线程模型怎么接一个大项目通常要采几十块表、每块表几十个点位。最笨的办法是一块表一个线程无限并发但DLMS电表并发连接数一般只有2~4个开多了直接拒绝。正确思路是用信号量限制并发数配合任务队列。下面这段代码就是用一个SemaphoreSlim把并发压到2private readonly SemaphoreSlim _gate new(2, 2); public async Task CollectAsync(ListMeterInfo meters, CancellationToken ct) { var tasks meters.Select(async meter { await _gate.WaitAsync(ct); try { using var dlms new DlmsConnection(); await dlms.OpenAsync(meter.Password); foreach (var point in meter.Points) { ct.ThrowIfCancellationRequested(); var value await dlms.ReadAttributeAsync(point, ct); await SavePointAsync(meter, point, value); } } catch (Exception ex) { _logger.Error($表[{meter.Name}]采集失败: {ex.Message}); } finally { _gate.Release(); } }); await Task.WhenAll(tasks); }为什么用SemaphoreSlim而不是Parallel.ForEachAsync因为DLMS操作本身是异步IO瓶颈不在CPU而在电表连接数。用信号量把并发度控在2既不会让电表忙死也不会让线程池爆掉。这2是经验值我在多款电表上验证过如果现场是集中器可以放宽到4~8但一定要做压测。SemaphoreSlim构造参数(2,2)中的2是初始可用槽位和最大槽位都设为2这样任何时刻最多2个任务进入采集区。重试逻辑我建议放在ReadAttributeAsync外层不放在连接类内部。这样业务层可以按点数动态决定重试次数。public async Taskobject? ReadWithRetryAsync(ObisPoint point, int retryCount 2) { for (int i 0; i retryCount; i) { try { return await ReadAttributeAsync(point, CancellationToken.None); } catch (DlmsTimeoutException) { if (i retryCount) throw; await Task.Delay(200 * (i 1)); } } return null; }重试次数最好不要超过3。电表数据有周期比如15分钟一轮错过了这轮下一轮会补上。重试太多会把故障表卡死导致后续任务全部积压。重试间隔用递增退避200ms、400ms、600ms足够别用固定1秒。4.3 解析结果与错误码映射DLMS的电表除了不回包还会在应用层返回错误码。错误码的语义和Modbus不同下面是一张常见映射表错误码含义C#处理建议0x01Hardware Fault记录日志跳过该点0x02Temporary Unavailable延时重试0x03Object Undefined检查OBIS码配置0x04Object Class Undefined检查接口类ID0x05Unavailable电表端被禁用0x07Address Unknown表地址与通信参数不匹配0x0AData Access Denied检查认证权限在代码里解析响应前先检查错误标签private void ThrowIfErrorResponse(byte[] pdu) { if (pdu.Length 4) throw new InvalidDlmsFrameException(响应太短); if (pdu[2] 0xC7) // Get-Response的错误标签 { byte errCode pdu[3]; throw new DlmsActionException(errCode, $DLMS错误码0x{errCode:X2}); } }这里0xC7是Get-Response的错误类标签。注意Set-Response和Action-Response的错误标签是另外的值不要一律套用。我把错误码封装成DlmsActionException这样上层可以按错误码决定是跳过、重试还是报警。存储到数据库时我习惯把RawValue、Value、Unit、CollectTime一起存这样后面发现数据不对还能拿原始寄存器的值回来复盘。5. DLMS采集C#开发避坑连接超时/帧长/时钟异常排查5.1 现象HDLC链路握手失败卡在SNRM发出去后没有响应现场环境最常见的问题是发SNRM后一直无响应。我排查的顺序是先看物理链路再看地址参数。DLMS的HDLC帧里有客户端地址和服务端地址电表默认服务端地址可能是0x10、0x00或厂商自定义值。TCP模式下还有逻辑设备地址很多时候默认是1。如果地址对不上SNRM帧就发给了错误的“收件人”电表当然不回。解决方法是把ServerAddress和ClientAddress做成配置用几个常见值轮询。我遇到过最玄学的一次是RS485接线AB反了SNRM发出去完全没反应把两根线换回来就好。还有一次是TCP端口被网关改成了4059以外的端口。不要假设出厂默认值一定正确现场一定要带一张电表通信参数截图。排查手段也很重要在SendReceiveAsync里把SNRM帧打成十六进制看发出去内容和电表厂商调试软件的报文是否一致。如果地址、控制字段、CRC都对了那就重点检查物理链路。5.2 现象能连上链路但AARQ后返回认证失败这种情况通常是“链路握手已经成功应用层关联被拒”。返回信息可能是“Application context not supported”或“Authentication failure”。原因一般是电表启用了LLS或HLS认证但客户端AARQ里的认证字段不对或者电表只接受HLS而你的代码还在用LLS。解决的第一步是去电表面板或管理软件确认认证方式。如果是LLS密码通常是一个十六进制字符串比如1234567890ABCDEF如果是HLS客户端必须预置系统标题、身份标识和认证密钥。很多电表出厂默认是无认证但现场为了安全会打开HLS。在没有拿到正确密钥之前最好先请厂里把表临时配成无认证跑通流程再做安全增强。5.3 现象读取成功但电量值大得离谱或小了1000倍这是DLMS采集老司机也容易翻车的点。电表返回的原始值是12345678你以为单位是kWh结果直接存成12345678 kWh而实际电表液晶屏上是12,345.678 kWh。原因就是原始单位是WhScale应该是0.001。有的电表返回的是“0.001kWh”的整数Scale又要改为1。解决时要同时读取四个属性逻辑名、值、标度、单位。把Scale和Unit做成配置项不要写死在协议层。另外读电压电流时有些表返回的是八位串有些返回整数解析器必须按DataType分支。我吃过一次亏A相电压返回值用Int16解析变成负值后来发现数据是OctetString需要转成ASCII再做decimal.Parse。5.4 现象串口采集程序跑一个小时后停止响应内存越占越多原因多半是句柄泄漏。C#的SerialPort和TcpClient如果不及时释放底层句柄不会随GC立即回收。尤其在一个循环里反复创建连接最终把句柄和线程池耗尽。此外有些代码只Close了NetworkStream没有Dispose底层Socket导致电表端也认为连接还活着。解决方法是统一用using作用域或在IDisposable.Dispose里同时处置NetworkStream和TcpClient。所有异步接收都要传CancellationToken防止读操作无限阻塞。还要注意串口分包一次Read读完一帧是运气不是常态。正确做法是维护接收缓冲区按0x7E帧尾切帧而不是依赖单次Read的字节数。5.5 现象电表连接数占满新任务等待旧任务不释放DLMS电表一般只允许2~4个客户端连接。如果某个客户端异常退出没有发送ReleaseRequest、也没有断开TCP电表端会保持这个会话数分钟甚至更久。之后第二个客户端就再也连不上或者连接后AARQ被拒。解决程序退出、异常捕获、看门狗超时这些路径里都要调用连接释放逻辑尽量发一个RLRQ/RLRE完成应用层断开。采集任务加一个全局心跳看门狗如果某块表超过设定时间没响应直接强制关闭底层连接。不要小看这个开关很多“采集程序跑两小时就卡死”的工单最后都是这个原因。6. 实战技巧用C#实现多表规约适配与离线调试6.1 用模拟器把采集代码提前跑通现场电表只有一块约不到时间这时候DLMS模拟器就非常有用。模拟器能模拟SNRM、UA、AARQ、AARE和Get响应你可以在办公室把C#采集代码的通信流程、解析逻辑、超时重试全部验证过。到现场只需要核对电表地址、认证参数和OBIS配置。这一步能避免80%的现场反复调试。6.2 十六进制报文日志是定位问题的最后一根稻草在SendReceiveAsync里加一行日志Debug.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] TX: {BitConverter.ToString(frame).Replace(-, )}); Debug.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] RX: {BitConverter.ToString(resp).Replace(-, )});就这个小技巧帮我处理过大量“表读不出数据”的现场问题。拿到现场报文后第一件事是跟模拟器抓的报文做diff。哪个字段不同问题就在哪。我一直认为DLMS协议栈像一个黑盒子但报文日志必须透明否则出了问题只能靠猜。6.3 点位验收时要用标准源做交叉核对上线验收时最怕换了一种电表型号抄回来的数据和表上显示的不对。我的习惯是让运维人员记录电表液晶屏上的实时值再和系统采集值对比。如果偏差先别急着改Scale要确认数据时标是否一致。很多系统显示的是15:00的快照而表上已经是16:00的实时值两边自然有偏差。说个我自己的教训曾经把1.0.1.8.0.255默认当成“正向有功总电能”后来发现某个型号的电表把它定义成“组合无功总电能”读回来数据完全对不上。从那以后我拿到新表的第一件事永远是先读一遍“对象列表”接口把电表真实模型拉出来再写配置。希望这个习惯也能帮到你。本文还有配套的精品资源点击获取