简介这是一款面向电力自动化、SCADA 系统及远程终端单元开发者的 IEC 60870 国际标准开源实现库对应 lib60870 库的 2.0.1 版本。IEC 60870-5 系列定义了变电站与调度中心之间的通信规范该库完整支持 101、102、104 三种常用协议可快速构建主站或子站应用避免从零编写复杂通信协议栈特别适合智能电网、变电站自动化等场景。资源包共 114 个文件、约 186KB核心由 39 个 C 语言源文件和 34 个头文件组成另附 12 个文本说明、多个 makefile 构建脚本以及证书文件便于开发者理解代码结构、编译集成和配置参考。目前已有 2495 人学习下载适合具备一定电力通信基础的嵌入式或上位机开发者。通过该库可获得协议报文编码解码、链路层控制、错误检测与恢复、主站/子站模式切换等现成模块能够显著降低开发成本并提高系统兼容性与互操作性是电力自动化领域软件开发的实用参考。1. IEC60870开源实现库从串口老规约到TCP/IP落地先想清楚这三件事电力远动通信里IEC60870开源实现库是很多储能站、光伏场站、变电站接入调度或集控平台时绕不开的选择。这个标准家族里实际工程中用得最多的是IEC 60870-5-101串口和IEC 60870-5-104网络而开源实现库帮你把报文编解码、链路握手、帧序号管理这些脏活做了封装省掉采购商业协议栈的成本。但它不是装上就能用的黑匣子公共地址怎么配、点表怎么注册、遥控为什么总失败这些坑几乎人人都会踩一遍。这篇笔记按“协议选型 → 最小跑通 → 避坑排查 → 验证技巧”推进适合做电力系统集成、自动化网关、配电终端的软硬件工程师也适合想快速评估协议栈可行性的架构师。读完之后你应该能在本地搭建一对主站和从站并清楚生产环境里哪些参数必须对齐。2. 认识IEC 60870-5-101/104协议分层与开源库选型2.1 101与104一条规约的两种载体别选错IEC 60870是远动设备通信的标准族工程上真正高频出现的是其中的IEC 60870-5-101和IEC 60870-5-104。101走串口RS-232/RS-485链路层自带一套帧确认机制适用于变电站到调度的专线、现场串口通道104是把101的ASDU应用层数据搬到TCP/IP上默认端口2404传输控制由APCI完成。二者共享同一套ASDU结构和点表思想所以“会104的人看101不陌生”但配置和抓包方法完全不同。104在APCI里引入了I帧、S帧、U帧。I帧带发送序号和接收序号负责承载用户数据S帧只做接收确认不带数据U帧负责启动/停止链路典型的就是STARTDT_ACT启动数据传输和TESTFR_ACT测试帧。这套带序号的机制保证数据不会因为TCP重传而重复或丢失但也是新手上手时最容易蒙圈的地方——你发出去的可能是U帧对方回的是S帧抓包看起来“啥也没有”实际链路已经通了。下面这张表是我做选型时经常贴给同事看的对比。对比项IEC 60870-5-101IEC 60870-5-104传输载体RS-232/RS-485 串口TCP/IP默认端口2404链路层自带链路规约有地址确认TCP APCI传输控制帧类型链路帧 ASDUU帧/S帧/I帧 ASDU典型场景变电站专线、串口通道、现场总线调度主站、储能/光伏站、集控平台实施复杂度需要串口服务器、地址分配规范走IP网络部署相对简单参数关注点链路地址、串口波特率、超时公共地址、K/W窗口、t0~t3超时2.2 开源库选型的五个维度选开源库我一般先问五个问题语言生态、主站还是从站、协议范围、维护活跃度、许可协议。语言这里没有绝对答案只看你的部署环境。嵌入式装置比如配电终端优先选C/C实现方便交叉编译进单板边缘网关和集控服务用Java或Go更顺手部署就是扔一个二进制纯验证和测试用Python最省事改改脚本就能模拟主站行为。主站还是从站这是最容易看走眼的。很多开源库只实现了主站客户端从站服务端是残缺的。你明明是要把设备接入调度得跑从站角色结果库文档里只有主站示例后面全是自己补。协议范围要看它支持到哪个部分基础四遥遥信、遥测、遥控、遥调够不够支持不支持时钟同步、总召、SOE事件有没有做TLS加密的扩展许可也要留个心眼GPL类的库用在商业产品里要评估开源义务我吃过这个亏后来养成先看LICENSE的习惯。活跃度很难量化但有个土办法看最近一年的commit和issue响应。一个两年不更新的库哪怕功能再全也意味着新编译环境、新安全要求都没人跟进生产环境慎用。2.3 协议栈与业务逻辑的边界库不帮你做的事开源库做的是“协议栈”不是“业务”。它能把ASDU编解码、TCP重连、帧序号管理、总召响应这些规约内部的事做好但点表映射IOA对应哪个测点、遥测死区处理、SOE事件排队、遥控安全闭锁、历史数据缓存这些都要你在库之上自己写。我见过团队把期望全押在库上结果发现点表管理、启动流程全要自己搭工期翻倍。为了避免把协议栈用成黑匣子我习惯在库外面包一层adapter把库的回调接口翻译成内部数据模型比如DigitalInputValue{ IOA, value, quality, timestamp }。这样将来换库、换版本业务层不用动同时把库的TRACE日志接进我们自己的日志系统方便现场排障。选库的时候也可以留意一下它有没有暴露ASDU解析日志没有的话排错会很痛苦。提示别让库直接穿透到业务层。协议栈边界划清楚换库、升级、砍掉某段协议特性成本都更可控。3. 最小跑通用开源实现把104主站与从站拉起来3.1 环境准备与编译拿到代码先看这三样不管是C还是Java实现拿到源码后先看三样东西README里的依赖清单、example目录、构建脚本。我一般先确认编译器和构建工具版本很多报错其实卡在依赖版本上而不是库本身。# 以某开源C实现为例编译前确认三个依赖 cmake --version # 建议 3.10 以上 g --version # 需要支持 C11 及以上 openssl version # 若开启TLS选项才需要基础版可不依赖 # 拉取开源仓库代码域名换成你实际使用的仓库地址 git clone https://example.invalid/ieclite.git cd ieclite mkdir build cd build cmake .. -DIECLITE_BUILD_EXAMPLESON make -j4这段命令里-DIECLITE_BUILD_EXAMPLESON是建议打开的它会把example一起编出来你能直接跑示例验证库本身没问题。-j4按CPU核数调整机器核多可以加到-j8。如果库用了CMake编译失败的常见原因集中在openssl头文件路径找不到这种情况不要硬改源码优先检查系统里有没有装libssl-dev这一类开发包。用Go库的话更简单go mod tidy go build就结束了但要注意模块代理网络策略内网环境经常卡在拉依赖这一步。3.2 从站侧注册点表、监听2404端口验证阶段我更喜欢用Python库改起来快逻辑也直观。下面用“某Python开源库”演示从站启动。先说明从站服务端的角色是模拟一个电力设备监听2404端口等主站来连接然后响应总召、上报遥信变位、执行遥控。# 示例启动一个104从站并注册点表 import ieclite # 创建从站服务监听2404端口公共地址common address设为1 server ieclite.Server(port2404, common_address1) # 注册遥信点单点信息 M_SP_NA_1, TI1IOA范围 1001~1004 for ioa in range(1001, 1005): server.add_digital_input(ioa) # 注册遥测点浮点测量值 M_ME_NC_1, TI13IOA 2001~2003 server.add_float_measurement(2001, init_value22.5) server.add_float_measurement(2002, init_value100.0) server.add_float_measurement(2003, init_value0.0) # 注册遥控点单点命令 C_SC_NA_1, TI45IOA 3001开启SBO选择执行 server.add_single_command(3001, select_before_operateTrue) server.start()这段代码里port2404是104规约的注册端口不能随便换换了你得在两边同时改但调度那边一般固定2404。common_address1是公共地址主站配置必须和它一致很多“连上了但没数据”的怪问题都出在这里。点表的IOA不一定要从1开始实际项目里常按区间规划遥信用1000段遥测用2000段遥控用3000段这样看报文能快速知道是哪种数据类型。select_before_operateTrue表示开启选择执行流程也就是遥控前必须有一个选择帧生产环境为了防误动一般都会开。3.3 主站侧总召、遥控与时钟同步的最小命令主站侧脚本承担调度或集控的角色。关键动作有三个建立TCP连接、启动数据传输U帧、发总召。总召的目的是让从站把全站数据都上送一遍这是主站初始化时必做的。import ieclite # 创建主站客户端连接本机从站公共地址要对齐 client ieclite.Client(127.0.0.1, port2404, common_address1) client.connect() # 发送U帧 STARTDT_ACT通知从站开始传输数据 client.start_communication() # 发送总召 C_IC_NA_1 (TI100)从站会回全数据 client.send_total_call() # 发送时钟同步 C_CS_NA_1 (TI103)时间戳格式为CP56Time2a client.send_clock_sync() # 遥控先选择再执行SBO流程必须两步走 client.select_command(3001, onTrue) client.execute_command(3001, onTrue) client.close()start_communication()对应U帧里的STARTDT主站不发这个从站不会主动上送数据。send_total_call()触发从站回一个总召确认帧然后是逐点数据。遥控这里用了两步先select_command再execute_command如果你在从站侧把select_before_operate设成False主站就可以单步执行但我不建议在演示阶段就这么干先把标准流程跑通再简化。时钟同步的时间戳格式是CP56Time2a共7字节各个库的实现可能有细微差异出现“时间同步失败”时优先怀疑这里。3.4 用抓包验证协议栈不是黑匣子跑通以后别急着高兴先抓包看一眼确认链路层是真的按104在走。在本地回环口抓2404端口的流量过滤条件用tcp.port 2404。抓包重点看几个点Connection启动时有没有U帧总召后从站回的第一帧是I帧还是S帧ASDU里的类型标识TI是不是100。如果主站发了总召从站回的是S帧而不是带数据的I帧说明从站压根没收到总召或内部没注册对应点。报文内容帧类型说明68 04 07 00 00 00U帧 STARTDT_ACT主站请求启动传输68 04 0b 00 00 00U帧 STARTDT_CON从站确认启动68 14 02 00 02 00 …I帧数据帧ASDU在载荷里68 04 01 00 00 00S帧接收序号确认无数据注意公共地址在报文的ASDU头部直接可见抓包一旦发现从站回的数据里公共地址不是你想的那个基本就是两边配置不一致不需要往深了查。4. 避坑与排查五个高频问题的现象、原因与解决4.1 总召没响应公共地址与点表注册现象主站U帧启动成功S帧也有来有回但发了总召TI100之后从站只回了S帧确认没有任何I帧数据上来。原因最常见是两个一是ASDU公共地址对不上。主站配的是common_address1从站内部配了地址长度2字节编码出来是01 00解析上就错位了。二是从站点表根本没注册总召指令到了从站但从站遍历点表为空自然没有数据可回。解决先在从站回调里打印收到的ASDU类型和公共地址确认总召确实到达。代码里加一行日志是最快的# 在从站回调里打印收到的ASDU信息用于快速定位 def on_asdu(asdu): print(type_id%d, common_address%d, ioa_count%d % (asdu.type_id, asdu.common_address, len(asdu.ioas))) server.set_asdu_callback(on_asdu)type_id100才是总召如果打印出来是别的值说明主站发的不是总召帧检查主站代码里的TI枚举。公共地址打印出来如果和主站不一致去统一两边的公共地址和地址长度配置。点表为空就把2.2节里的注册代码跑一遍确认IOA和类型都对。4.2 遥测数值乱跳品质位、死区与字节序现象主站收到的遥测数值在正常范围内跳动或者出现明显不合理的数比如电压12000V、频率50Hz这种量级没问题但偶发几百万的尖峰有时候数值正确但主站告警“无效数据”。原因分两层。第一层是品质位quality descriptor没看一些库在数值溢出或传感器断线时会把品质位置成IVinvalid或OVoverflow主站如果只看数值不看品质位就会把无效值当真。第二层是浮点字节序问题104里遥测浮点常用IEEE 754单精度但每个厂商的字节序不一定一致主站配了大端从站发小端解出来就是天文数字。解决主站侧所有遥测上送前必须检查品质位quality 0x01为1就是无效数据直接丢弃或置质量位。字节序问题在demo阶段就要两边对齐抓包看原始字节比如3f 80 00 00是1.0的小端00 00 80 3f是大端。死区问题属于策略层面——很多从站库默认不处理变化遥测阈值你需要自己设置死区比如电压超过0.5V才上送变化不然一次波动刷一屏报文调度那边直接觉得你有问题。4.3 遥控不执行SBO选择执行流程没对齐现象主站下发遥控命令从站返回“不接受”或直接无响应但抓包看APCI层是正常的TCP也没断。原因从站开启了SBO流程主站却只发了执行帧没有先发选择帧。104的SBO要求先选择select后执行execute选择帧的S/E位为0执行帧的S/E位为1。另外有些从站库对控制对象做了安全校验比如遥控点未在点表注册、IOA不属于控制类、操作员权限未校验都会拒绝执行。解决把3.3节的select_command和execute_command两步都跑一遍先确认选择帧回的是确认而不是拒绝。如果从站侧是第三方库检查它是否在execute回调里做了额外的防抖或校验逻辑比如要求同一个操作必须在选择后10秒内执行。临时绕过SBO的办法是把从站的select_before_operate设False但这只能用于联调生产不建议关。4.4 断线重连风暴与超时参数现象主站和从站之间网络闪断一次之后主站疯狂重连从站端口出现大量TCP连接堆积甚至把从站库的连接句柄耗尽整个装置卡死。原因104协议在主站主动断开后TCP四次挥手没走完端口处于TIME_WAIT状态主站立即重连会失败然后它不等待直接再次重连形成风暴。更隐蔽的是从站库没有清理旧连接上下文TCP新连接进来了但旧连接的接收协程还活着。解决主站侧实现指数退避重连第一次失败等3秒第二次6秒最大间隔30秒没有“立即重连”。从站侧把104的连接参数按标准值设好t0连接建立超时10秒、t1发送/接收APDU超时15秒、t2无数据确认超时10秒、t3测试帧周期20秒。很多开源库的默认值是对的但工程上会因为现场网络质量差而调大t1和t3注意别调太过超过调度主站侧的容忍值照样踢你下线。参数含义标准参考值t0建立TCP连接的超时10st1发送或接收APDU的超时15st2接收方无数据时发送S帧确认的超时10st3发送TESTFR测试帧的周期20sK发送方未确认I帧的最大数量12W接收方最多接收W个I帧后必须确认84.5 排错三步法先TCP、再APCI、最后ASDU这是我最想分享的排错习惯。很多人在104联调出问题时直接在应用代码里打日志看半天也不知道是库的问题还是自己业务的问题。我的顺序永远是从下往上先TCP、再APCI、最后ASDU。TCP层看连接能不能建立、有没有RSTAPCI层看U帧启动是否成功、I帧序号有没有回退ASDU层才看类型标识、公共地址、IOA、品质位。哪一层不过就修哪一层不要越级排查。比如你ASDU解析出来的值不对但TCP和APCI都正常那就不要再去改主站的重连参数了回头查字节序。异常现象定位层级重点检查项连不上、连接被重置TCP端口、防火墙、对端地址启动传输无响应APCIU帧格式、链路状态机收到S帧但没有I帧数据APCI/ASDU总召是否到达、点表是否为空数据上来了但数值不对ASDU类型标识、字节序、品质位5. 进阶用法把开源库用稳的三个验证技巧5.1 帧级回环测试绕过网络直接喂字节联调环境不稳定时我习惯先做帧级回环测试构造一段104报文字节流直接塞给库的解析器看它能不能正确解出ASDU。这个方法不依赖网络、不依赖对端能最快隔离“库的编解码问题”和“网络时序问题”。import ieclite # 构造一个总召ASDU的字节流APCI(长度34, 发送序号02, 接收序号02) ASDU frame bytes.fromhex( 68 22 02 00 02 00 # APCI头长度0x2234字节 64 01 06 00 00 00 00 # ASDU: 类型100(总召), 公共地址1, IOA0 ) parser ieclite.ASDUParser(common_address1) asdu parser.parse(frame) assert asdu.type_id 100 # 断言解出来的是总召 assert asdu.common_address 1 # 断言公共地址正确这段代码里68 22 02 00 02 00是104的APCI固定写法68是起始符22是后面长度02 00是发送序号02 00是接收序号。ASDU部分的64是TI10001是公共地址06 00 00 00是传输原因总召激活。把这段塞进回归测试每次库升级、编译环境变化先跑它跑不过就不用上真机了。5.2 四连测回归脚本每次改版先跑一遍我每次改完点表或协议配置都会跑一遍“四连测”连接、总召、单点遥控、时钟同步。四个动作全部成功才算这次改动没破坏基础功能。用脚本把这个固化下来比手动操作可靠得多。# 每次改版后跑一遍四连测连接-总召-遥控-时钟同步 ./run_regression.sh master_config.xml脚本内部就是依次调用3.3节的那几个方法每步都做断言。遥控我建议测一个真实点但不要动真实设备DEMO环境里遥控点后面接一个模拟继电器就行。这个脚本最大的价值是让你敢改代码——改坏了跑一遍就知道而不是等现场报障。5.3 TLS与双链路冗余的取舍调度侧现在越来越倾向要求104走TLS加密但开源库对TLS的支持参差不齐。如果库原生支持TLS优先开启如果只能自己包一层要明确加密发生在TCP之上、104协议内部的apci层还是传一个额外的TLS隧道这直接影响对端能不能解。双链路冗余双主站连接也要留意很多库默认只允许一个TCP连接第二个连接会直接拒绝或踢掉第一个。如果现场要求一主一备双链路得确认库有没有原生的双连接支持或者自己做连接优先级管理。我最早做104接入时习惯把点表写死在从站demo里觉得这样“最快”结果每次现场改点都要重新编译部署被现场工程师吐槽了两三次之后才改成外部配置加载。从那以后凡是点表、公共地址、超时参数一律外部化代码里不出现任何现场相关的值。这个习惯一直保留到现在。希望帮到你。本文还有配套的精品资源点击获取