简介lib60870-2.0.1是IEC60870标准的开源C语言实现库面向电力自动化、SCADA及智能电网通信开发者可直接集成101、102、104协议支持主站/子站双向通信省去从零实现复杂协议栈的代价。资源包共114个文件压缩后仅186KB以C源文件39个和头文件34个为核心实现另含makefile构建脚本、adoc用户指南、readme说明及测试用txt等便于编译、阅读与调试。已有2489人学习下载适合需要快速接入IEC60870协议或深入理解协议报文编码细节的工程师。通过阅读源码与示例可掌握CS101/CS104链路层、ASDU编解码、连接管理等核心机制并利用提供的测试代码与构建配置快速搭建主站或子站应用降低协议集成门槛。1. IEC60870到底是什么为什么电力自动化离不开它1.1 一个协议家族不止是104做电力自动化、SCADA、变电站监控或者分布式光伏接入的朋友对IEC60870这套协议应该都不陌生。它不是一个单独的标准而是一整个协议家族日常接触最多的是IEC 60870-5-101和IEC 60870-5-104。简单说101走串口常见于RS232/RS485链路适合带宽小、实时性要求高的本地通信104走TCP/IP网络把101的应用数据搬到以太网上适合主站与子站之间的远动通信端口固定是2404。这套协议在国内电力行业几乎是无处不在。调度自动化、配网自动化、变电站综合自动化、新能源电站远动信息上传底层基本都是104或101。它定义的模型很清晰信息体地址IOA、公共地址、类型标识一层层把遥信、遥测、遥控、遥调数据组织起来主站和从站之间只要按这个格式交互设备厂商不同也能顺利对接。如果你接触过电力项目大概率遇到过跟不同厂家联调时的糟心事——协议不一致、点位表理解偏差、规约实现有差异。这时候如果能有一个稳定可靠的开源实现库做参照甚至直接作为项目基础代码能省掉大量重复开发和联调时间。这也是我今天想聊的重点IEC60870的开源实现库到底怎么选、怎么用、有哪些坑。1.2 为什么说开源实现库是刚需有人可能会问IEC104协议本身并不复杂自己照着标准写一套不行吗说实话能写但没必要。协议的核心难点不在正常流程而在各种边界情况和对端设备的非标实现。举个例子同一个遥信变位报文有的厂家用M_SP_NA_1类型标识1单点遥信有的厂家用M_SP_TB_1带时标如果你只实现了前者联调时就会遇到数据能上送但时间戳对不上的问题。这类细节标准文档里都有但实际踩一遍坑的成本很高。更关键的是IEC60870涉及电厂、变电站这类对稳定性要求极高的场景代码里一个时序问题就可能造成误遥信或遥控失败。开源实现库的好处在于核心逻辑经过了大量项目验证社区里各种边界问题基本都被踩过了你拿到手可以直接用遇到问题还能翻issue、看commit记录比自己从零开始写要靠谱得多。2. 开源库选型lib60870、j60870怎么选2.1 主流开源库横向对比目前电力圈子里用得多、口碑也比较稳定的IEC60870开源实现库主要有这么几个库名称语言协议支持授权方式适用场景lib60870C/C101/104GPLv3/商用授权嵌入式终端、从站、高性能主站j60870Java104GPLv2/商用授权Java系SCADA主站、后台服务openmucJava101/104Apache 2.0科研、教育、内部工具node-red-contrib-iec60870JavaScript104MIT快速原型、轻量接入qinghuaIEC104各厂自研C/C/Java104不定企业内自用如果你的项目是嵌入式设备比如用STM32、ARM9跑一个采集终端那基本绕不开lib60870因为它是C语言的资源占用可控交叉编译也方便。如果是在服务端做数据汇聚主站后台、规约转换器这类Java系的j60870或者openmuc更顺手开发效率高接数据库、接消息中间件都方便。我自己的习惯是终端侧一律用lib60870后台服务优先找Apache许可证的库避免授权风险。openmuc的Apache 2.0对商业项目很友好但因为某些原因它在国内信息更新比较慢用之前需要确认你需要的功能是否都覆盖了。2.2 许可证与商用合规提醒这里必须多说一句因为很多人容易在这里栽跟头。lib60870本体是GPLv3授权的也就是说如果你的项目对外分发并且用了lib60870的代码那么你的整个项目就有义务开源。对很多做产品、做方案的团队来说这可能是致命的。MZ Automation官方提供商业授权价格需要邮件咨询但如果你是做非商用项目、学习研究、或者在甲方内部系统使用而不对外分发那GPLv3的约束就没有那么敏感。还有个容易忽略的点lib60870有多个分支和forkGitHub上搜IEC60870会出来一大堆有些是老版本有些是社区魔改版选的时候要认准MZ Automation官方仓库或者看star数和最近commit时间别迷迷糊糊拿了个三年前的fork当主线跑到最后发现协议栈有bug还找不到人修。3. 手把手基于lib60870把104从站跑起来3.1 编译准备与工程结构先说说环境。我用的是Ubuntu 20.04/22.04交叉编译到ARM平台也做过流程基本一致。先把代码拉下来git clone https://github.com/mz-automation/lib60870.git cd lib60870lib60870的工程组织比较清晰核心源码在lib60870-C目录下包含src和inc两个子目录。编译有两种方式一是直接用CMake构建整个库二是把源码直接加进你的工程一起编。嵌入式场景我更推荐后者因为裁剪灵活编译选项一目了然。CMake方式mkdir build cd build cmake .. make编译完成后会生成静态库和一堆示例程序。看示例代码是快速上手的最好方式比如examples/cs104_server_example.c就是最典型的104从站程序examples/cs104_client_example.c是主站程序。这两个例子覆盖了90%的基础场景直接改改就能用。3.2 从站核心代码与参数解析下面直接看从站怎么实现。我简化了官方示例留下最核心的部分#include cs104_slave.h static void connectionHandler(CS104_Connection connection, CS104_PeerConnectionState state, void *parameter) { if (state CS104_PEER_CONNECTION_STATE_OPENED) { printf(连接建立对端地址%s\n, CS104_Connection_getPeerAddress(connection)); } } int main(void) { CS104_Slave slave CS104_Slave_create(100, 10); // 参数1: 最大同时连接数, 参数2: 启动事件队列大小 /* 设置公共地址这里用1必须与主站配置一致 */ CS104_Slave_setCommonAddress(slave, 1); /* 设置连接事件回调 */ CS104_Slave_setConnectionHandler(slave, connectionHandler, NULL); /* 启动从站服务监听0.0.0.0:2404 */ CS104_Slave_start(slave); /* 模拟循环定期刷新遥测值 */ while (1) { float temperature 25.6; CS104_Slave_setFloatValue(slave, CS104_InformationObject_create(4001, M_ME_NC_1), temperature); Thread_sleep(1000); } CS104_Slave_destroy(slave); return 0; }这段代码看着简单关键参数我展开说一下CS104_Slave_create(100, 10)第一个参数是允许的最大客户端连接数。实际调度系统里经常会有主备双主站甚至地调、县调同时接入所以这个值不能设得太小。第二个参数是启动事件总召、单点命令等的队列长度一般1020就够。setCommonAddress这就是前面说的公共地址。在配置点表时主站端填写的公共地址必须和这里一致否则整个ASDU会被直接丢弃表现出来就是连接正常但一条数据都没有。信息体地址4001这是点表规划的关键。国内电力系统约定俗成的做法是遥测从4001开始编号遥信从1开始遥控从6001开始不同区域会有差别但核心原则是主站与从站必须完全对应。从站的信息体读取还有个常见写法就是通过回调函数按需返回数据而不是像我上面那样在主循环里定时刷新。回调方式适合点位数量大、数据动态变化的场景static bool readSinglePointHandler(void *parameter, int address, bool *value) { if (address 1) { *value getBreakerStatus(); /* 从你自己的数据源拿开关状态 */ return true; } return false; } CS104_Slave_setReadSinglePointHandler(slave, readSinglePointHandler, NULL);这种方式的好处是主站发起总召或者单个对象查询时库会自动回调你的处理函数不需要自己管理定时上报逻辑也避免在主循环里反复遍历所有点位。3.3 主站连接与调试写完从站还得有个主站来验证。官方示例的客户端代码还可以再精简#include cs104_connection.h static void connectionHandler(void *parameter, CS104_Connection connection, CS104_ConnectionEvent event) { switch (event) { case CS104_CONNECTION_EVENT_CONNECTED: printf(已连接到从站\n); break; case CS104_CONNECTION_EVENT_STARTDT_CONFIRM: printf(STARTDT确认可以传输数据\n); break; default: break; } } int main(void) { CS104_Connection con CS104_Connection_create(192.168.1.100, 2404); CS104_Connection_setConnectionHandler(con, connectionHandler, NULL); /* 建立TCP连接并启动数据传输模式 */ CS104_Connection_connect(con); CS104_Connection_sendStartDT(con); /* 发送总召命令类型标识100 (C_IC_NA_1) */ CS104_Connection_sendInterrogationCommand(con, CS101_COT_ACTIVATION, 1, 0); /* 让程序跑一会儿观察回调 */ Thread_sleep(5000); CS104_Connection_destroy(con); return 0; }主站连接以后要主动sendStartDT这是因为IEC104有一个启动握手流程客户端发STARTDT激活命令服务端确认后双方才能开始传输应用数据。我见过不少刚开始用这个库的人TCP连接是通了但忘了发STARTDT结果一条数据也收不到。主站端接收遥测数据需要注册ASDU接收回调static void asduReceivedHandler(void *parameter, CS104_Connection connection, CS101_ASDU asdu) { if (CS101_ASDU_getTypeID(asdu) M_ME_NC_1) { InformationObject io CS101_ASDU_getElement(asdu, 0); float val CS101_InformationObject_getFloatValue(io); int ioa CS101_InformationObject_getObjectAddress(io); printf(遥测: IOA%d, 值%f\n, ioa, val); } CS101_ASDU_destroy(asdu); }注意接收回调里的ASDU需要自己调用CS101_ASDU_destroy释放否则长时间跑必然内存泄漏。这个在官方文档里有写但很多人会漏。4. 现场实战常见故障与排错清单4.1 连接层问题用这套开源库做了不少项目现场调试时遇到最多的问题集中在连接建立阶段。第一个常见现象是TCP能通但连接建了又断、反复重连。这种情况八成是t0、t1、t2、t3超时参数不匹配。IEC104定义了四个关键超时t0是建立TCP连接的超时默认10秒t1是发送或测试APDU后的确认超时默认15秒t2是接收APDU后的确认延迟默认10秒t3是链路空闲时的测试帧周期默认20秒。如果对端设备设的t3特别短而你的库默认t3比较长就会触发对端主动断开。解决办法是在创建连接或从站后显式设置这些参数CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T0, 10000); CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T1, 15000); CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T2, 10000); CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T3, 20000);第二个常见问题是端口填错。IEC104固定是2404有的设备会改端口但很多调试人员习惯性地用101协议里的串口参数思维忘了检查TCP端口抓包一看SYN发出去对端根本不回应最后发现是对端监听端口不是2404。4.2 应用层与数据问题连接正常、但数据不对这种情况更让人头疼。优先级最高的排查手段是Wireshark。IEC104的dissector是内置的抓包以后能看到APCI和ASDU的详细字段比看代码日志高效得多。举几个典型的例子公共地址不一致现象是所有报文都有响应但从站就是不回数据。抓包可以看到主站发送的总召请求里带的是公共地址1而从站配置的公共地址是2此时从站直接丢弃该ASDU不做任何应答。信息体地址错位比如从站IOA是从1开始排的遥信主站配置的遥信表从0或者从1001开始就会导致数据串位。这种问题靠抓包特别容易定位对照点表一条条看IOA即可。类型标识不匹配主站请求总召所有遥信从站回的是带时标的版本或者数据类型不对主站解析不出来。多见于只实现了部分类型标识的简化版设备。另外有个非常容易踩的坑浮点数的传输格式。IEC104里的浮点遥测默认用的是32位IEEE754小端序但有些保护装置、测控装置出自不同的历史背景会用短浮点或者定点数传输。如果你发现遥测值差好几个数量级、或者小数点位置不对优先怀疑这个别急着改业务代码。4.3 项目收尾建议最后分享几个我做项目时养成的习惯都是折腾出来的经验第一不管时间多紧先把点表明确再动代码。IEC104的联调几乎全是点表问题点位编号、类型、单位、死区、变化上送条件这些必须跟对端负责人一条条核对清楚。点表做扎实了联调能快一半。第二保留抓包习惯。跑通以后不要立刻关掉Wireshark保存一份完整交互记录至少包含启动握手、总召、正常上送、遥控命令这几类报文。后面出了问题这份抓包文件就是最有力的证据。第三给自己的实现库打个内部版本号记录修改过哪些源码。开源库虽说稳定但难免要根据项目微调比如修改默认最大ASDU长度、调整缓冲区大小。如果你不记录版本变更三个月后出了bug你可能完全想不起来改过哪里。第四遥控和遥调命令一定要加确认机制。使用开源库时命令发送的API调用本身很快但现场设备是否真正执行必须通过COI传输原因和执行结果的回执来判断。代码里不要只发命令不监听确认否则事故回放时你会非常被动。我的经验是IEC60870的开源实现库最大的价值不是省掉那几千行代码而是把一个经过大量现场验证的协议状态机交到你手里让你可以集中精力去处理业务逻辑和对接问题。但协议栈只是基础真正决定项目成败的还是点表规划、异常处理和现场联调的细致程度。本文还有配套的精品资源点击获取
IEC60870开源库选型与实战：lib60870从站/主站开发及排错指南
简介lib60870-2.0.1是IEC60870标准的开源C语言实现库面向电力自动化、SCADA及智能电网通信开发者可直接集成101、102、104协议支持主站/子站双向通信省去从零实现复杂协议栈的代价。资源包共114个文件压缩后仅186KB以C源文件39个和头文件34个为核心实现另含makefile构建脚本、adoc用户指南、readme说明及测试用txt等便于编译、阅读与调试。已有2489人学习下载适合需要快速接入IEC60870协议或深入理解协议报文编码细节的工程师。通过阅读源码与示例可掌握CS101/CS104链路层、ASDU编解码、连接管理等核心机制并利用提供的测试代码与构建配置快速搭建主站或子站应用降低协议集成门槛。1. IEC60870到底是什么为什么电力自动化离不开它1.1 一个协议家族不止是104做电力自动化、SCADA、变电站监控或者分布式光伏接入的朋友对IEC60870这套协议应该都不陌生。它不是一个单独的标准而是一整个协议家族日常接触最多的是IEC 60870-5-101和IEC 60870-5-104。简单说101走串口常见于RS232/RS485链路适合带宽小、实时性要求高的本地通信104走TCP/IP网络把101的应用数据搬到以太网上适合主站与子站之间的远动通信端口固定是2404。这套协议在国内电力行业几乎是无处不在。调度自动化、配网自动化、变电站综合自动化、新能源电站远动信息上传底层基本都是104或101。它定义的模型很清晰信息体地址IOA、公共地址、类型标识一层层把遥信、遥测、遥控、遥调数据组织起来主站和从站之间只要按这个格式交互设备厂商不同也能顺利对接。如果你接触过电力项目大概率遇到过跟不同厂家联调时的糟心事——协议不一致、点位表理解偏差、规约实现有差异。这时候如果能有一个稳定可靠的开源实现库做参照甚至直接作为项目基础代码能省掉大量重复开发和联调时间。这也是我今天想聊的重点IEC60870的开源实现库到底怎么选、怎么用、有哪些坑。1.2 为什么说开源实现库是刚需有人可能会问IEC104协议本身并不复杂自己照着标准写一套不行吗说实话能写但没必要。协议的核心难点不在正常流程而在各种边界情况和对端设备的非标实现。举个例子同一个遥信变位报文有的厂家用M_SP_NA_1类型标识1单点遥信有的厂家用M_SP_TB_1带时标如果你只实现了前者联调时就会遇到数据能上送但时间戳对不上的问题。这类细节标准文档里都有但实际踩一遍坑的成本很高。更关键的是IEC60870涉及电厂、变电站这类对稳定性要求极高的场景代码里一个时序问题就可能造成误遥信或遥控失败。开源实现库的好处在于核心逻辑经过了大量项目验证社区里各种边界问题基本都被踩过了你拿到手可以直接用遇到问题还能翻issue、看commit记录比自己从零开始写要靠谱得多。2. 开源库选型lib60870、j60870怎么选2.1 主流开源库横向对比目前电力圈子里用得多、口碑也比较稳定的IEC60870开源实现库主要有这么几个库名称语言协议支持授权方式适用场景lib60870C/C101/104GPLv3/商用授权嵌入式终端、从站、高性能主站j60870Java104GPLv2/商用授权Java系SCADA主站、后台服务openmucJava101/104Apache 2.0科研、教育、内部工具node-red-contrib-iec60870JavaScript104MIT快速原型、轻量接入qinghuaIEC104各厂自研C/C/Java104不定企业内自用如果你的项目是嵌入式设备比如用STM32、ARM9跑一个采集终端那基本绕不开lib60870因为它是C语言的资源占用可控交叉编译也方便。如果是在服务端做数据汇聚主站后台、规约转换器这类Java系的j60870或者openmuc更顺手开发效率高接数据库、接消息中间件都方便。我自己的习惯是终端侧一律用lib60870后台服务优先找Apache许可证的库避免授权风险。openmuc的Apache 2.0对商业项目很友好但因为某些原因它在国内信息更新比较慢用之前需要确认你需要的功能是否都覆盖了。2.2 许可证与商用合规提醒这里必须多说一句因为很多人容易在这里栽跟头。lib60870本体是GPLv3授权的也就是说如果你的项目对外分发并且用了lib60870的代码那么你的整个项目就有义务开源。对很多做产品、做方案的团队来说这可能是致命的。MZ Automation官方提供商业授权价格需要邮件咨询但如果你是做非商用项目、学习研究、或者在甲方内部系统使用而不对外分发那GPLv3的约束就没有那么敏感。还有个容易忽略的点lib60870有多个分支和forkGitHub上搜IEC60870会出来一大堆有些是老版本有些是社区魔改版选的时候要认准MZ Automation官方仓库或者看star数和最近commit时间别迷迷糊糊拿了个三年前的fork当主线跑到最后发现协议栈有bug还找不到人修。3. 手把手基于lib60870把104从站跑起来3.1 编译准备与工程结构先说说环境。我用的是Ubuntu 20.04/22.04交叉编译到ARM平台也做过流程基本一致。先把代码拉下来git clone https://github.com/mz-automation/lib60870.git cd lib60870lib60870的工程组织比较清晰核心源码在lib60870-C目录下包含src和inc两个子目录。编译有两种方式一是直接用CMake构建整个库二是把源码直接加进你的工程一起编。嵌入式场景我更推荐后者因为裁剪灵活编译选项一目了然。CMake方式mkdir build cd build cmake .. make编译完成后会生成静态库和一堆示例程序。看示例代码是快速上手的最好方式比如examples/cs104_server_example.c就是最典型的104从站程序examples/cs104_client_example.c是主站程序。这两个例子覆盖了90%的基础场景直接改改就能用。3.2 从站核心代码与参数解析下面直接看从站怎么实现。我简化了官方示例留下最核心的部分#include cs104_slave.h static void connectionHandler(CS104_Connection connection, CS104_PeerConnectionState state, void *parameter) { if (state CS104_PEER_CONNECTION_STATE_OPENED) { printf(连接建立对端地址%s\n, CS104_Connection_getPeerAddress(connection)); } } int main(void) { CS104_Slave slave CS104_Slave_create(100, 10); // 参数1: 最大同时连接数, 参数2: 启动事件队列大小 /* 设置公共地址这里用1必须与主站配置一致 */ CS104_Slave_setCommonAddress(slave, 1); /* 设置连接事件回调 */ CS104_Slave_setConnectionHandler(slave, connectionHandler, NULL); /* 启动从站服务监听0.0.0.0:2404 */ CS104_Slave_start(slave); /* 模拟循环定期刷新遥测值 */ while (1) { float temperature 25.6; CS104_Slave_setFloatValue(slave, CS104_InformationObject_create(4001, M_ME_NC_1), temperature); Thread_sleep(1000); } CS104_Slave_destroy(slave); return 0; }这段代码看着简单关键参数我展开说一下CS104_Slave_create(100, 10)第一个参数是允许的最大客户端连接数。实际调度系统里经常会有主备双主站甚至地调、县调同时接入所以这个值不能设得太小。第二个参数是启动事件总召、单点命令等的队列长度一般1020就够。setCommonAddress这就是前面说的公共地址。在配置点表时主站端填写的公共地址必须和这里一致否则整个ASDU会被直接丢弃表现出来就是连接正常但一条数据都没有。信息体地址4001这是点表规划的关键。国内电力系统约定俗成的做法是遥测从4001开始编号遥信从1开始遥控从6001开始不同区域会有差别但核心原则是主站与从站必须完全对应。从站的信息体读取还有个常见写法就是通过回调函数按需返回数据而不是像我上面那样在主循环里定时刷新。回调方式适合点位数量大、数据动态变化的场景static bool readSinglePointHandler(void *parameter, int address, bool *value) { if (address 1) { *value getBreakerStatus(); /* 从你自己的数据源拿开关状态 */ return true; } return false; } CS104_Slave_setReadSinglePointHandler(slave, readSinglePointHandler, NULL);这种方式的好处是主站发起总召或者单个对象查询时库会自动回调你的处理函数不需要自己管理定时上报逻辑也避免在主循环里反复遍历所有点位。3.3 主站连接与调试写完从站还得有个主站来验证。官方示例的客户端代码还可以再精简#include cs104_connection.h static void connectionHandler(void *parameter, CS104_Connection connection, CS104_ConnectionEvent event) { switch (event) { case CS104_CONNECTION_EVENT_CONNECTED: printf(已连接到从站\n); break; case CS104_CONNECTION_EVENT_STARTDT_CONFIRM: printf(STARTDT确认可以传输数据\n); break; default: break; } } int main(void) { CS104_Connection con CS104_Connection_create(192.168.1.100, 2404); CS104_Connection_setConnectionHandler(con, connectionHandler, NULL); /* 建立TCP连接并启动数据传输模式 */ CS104_Connection_connect(con); CS104_Connection_sendStartDT(con); /* 发送总召命令类型标识100 (C_IC_NA_1) */ CS104_Connection_sendInterrogationCommand(con, CS101_COT_ACTIVATION, 1, 0); /* 让程序跑一会儿观察回调 */ Thread_sleep(5000); CS104_Connection_destroy(con); return 0; }主站连接以后要主动sendStartDT这是因为IEC104有一个启动握手流程客户端发STARTDT激活命令服务端确认后双方才能开始传输应用数据。我见过不少刚开始用这个库的人TCP连接是通了但忘了发STARTDT结果一条数据也收不到。主站端接收遥测数据需要注册ASDU接收回调static void asduReceivedHandler(void *parameter, CS104_Connection connection, CS101_ASDU asdu) { if (CS101_ASDU_getTypeID(asdu) M_ME_NC_1) { InformationObject io CS101_ASDU_getElement(asdu, 0); float val CS101_InformationObject_getFloatValue(io); int ioa CS101_InformationObject_getObjectAddress(io); printf(遥测: IOA%d, 值%f\n, ioa, val); } CS101_ASDU_destroy(asdu); }注意接收回调里的ASDU需要自己调用CS101_ASDU_destroy释放否则长时间跑必然内存泄漏。这个在官方文档里有写但很多人会漏。4. 现场实战常见故障与排错清单4.1 连接层问题用这套开源库做了不少项目现场调试时遇到最多的问题集中在连接建立阶段。第一个常见现象是TCP能通但连接建了又断、反复重连。这种情况八成是t0、t1、t2、t3超时参数不匹配。IEC104定义了四个关键超时t0是建立TCP连接的超时默认10秒t1是发送或测试APDU后的确认超时默认15秒t2是接收APDU后的确认延迟默认10秒t3是链路空闲时的测试帧周期默认20秒。如果对端设备设的t3特别短而你的库默认t3比较长就会触发对端主动断开。解决办法是在创建连接或从站后显式设置这些参数CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T0, 10000); CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T1, 15000); CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T2, 10000); CS104_Connection_setParameter(con, CS104_PARAM_TIMEOUT_T3, 20000);第二个常见问题是端口填错。IEC104固定是2404有的设备会改端口但很多调试人员习惯性地用101协议里的串口参数思维忘了检查TCP端口抓包一看SYN发出去对端根本不回应最后发现是对端监听端口不是2404。4.2 应用层与数据问题连接正常、但数据不对这种情况更让人头疼。优先级最高的排查手段是Wireshark。IEC104的dissector是内置的抓包以后能看到APCI和ASDU的详细字段比看代码日志高效得多。举几个典型的例子公共地址不一致现象是所有报文都有响应但从站就是不回数据。抓包可以看到主站发送的总召请求里带的是公共地址1而从站配置的公共地址是2此时从站直接丢弃该ASDU不做任何应答。信息体地址错位比如从站IOA是从1开始排的遥信主站配置的遥信表从0或者从1001开始就会导致数据串位。这种问题靠抓包特别容易定位对照点表一条条看IOA即可。类型标识不匹配主站请求总召所有遥信从站回的是带时标的版本或者数据类型不对主站解析不出来。多见于只实现了部分类型标识的简化版设备。另外有个非常容易踩的坑浮点数的传输格式。IEC104里的浮点遥测默认用的是32位IEEE754小端序但有些保护装置、测控装置出自不同的历史背景会用短浮点或者定点数传输。如果你发现遥测值差好几个数量级、或者小数点位置不对优先怀疑这个别急着改业务代码。4.3 项目收尾建议最后分享几个我做项目时养成的习惯都是折腾出来的经验第一不管时间多紧先把点表明确再动代码。IEC104的联调几乎全是点表问题点位编号、类型、单位、死区、变化上送条件这些必须跟对端负责人一条条核对清楚。点表做扎实了联调能快一半。第二保留抓包习惯。跑通以后不要立刻关掉Wireshark保存一份完整交互记录至少包含启动握手、总召、正常上送、遥控命令这几类报文。后面出了问题这份抓包文件就是最有力的证据。第三给自己的实现库打个内部版本号记录修改过哪些源码。开源库虽说稳定但难免要根据项目微调比如修改默认最大ASDU长度、调整缓冲区大小。如果你不记录版本变更三个月后出了bug你可能完全想不起来改过哪里。第四遥控和遥调命令一定要加确认机制。使用开源库时命令发送的API调用本身很快但现场设备是否真正执行必须通过COI传输原因和执行结果的回执来判断。代码里不要只发命令不监听确认否则事故回放时你会非常被动。我的经验是IEC60870的开源实现库最大的价值不是省掉那几千行代码而是把一个经过大量现场验证的协议状态机交到你手里让你可以集中精力去处理业务逻辑和对接问题。但协议栈只是基础真正决定项目成败的还是点表规划、异常处理和现场联调的细致程度。本文还有配套的精品资源点击获取