IEC104主站源码解析：APCI/ASDU、总召与遥测实现

简介这份资源是面向电力自动化、SCADA 系统开发者与工控通信学习者的 IEC 60870-5-104 主站协议实现源码适合已具备网络编程与 C/C 基础、希望深入理解 104 主站通信细节的中高级开发者。压缩包共 28 个文件、约 302KB以 cpp 与 h 源文件为核心另含 o 目标文件、vcproj/sln/dsw 等工程文件、linux 与 hpux 平台的 mak 编译脚本及 ReadMe 说明工程可直接在 Windows 与类 Unix 环境下打开与构建。源码围绕主站职责展开链接管理模块负责 TCP 连接建立、心跳维持与断线重连ASDU 与协议模块完成报文组装、解析及类型标识处理另含应用层基础与通道编码处理等模块可对照学习数据请求、遥控命令下发、时间同步与错误处理的设计思路。已有 835 人学习便于按模块检索、逐层调试快速建立对 104 主站通信流程的整体认识。1. 从一条停住的遥测曲线说起iec104主站源码到底能干什么凌晨两点某现场的遥测曲线突然停在上一小时值班的人先怀疑通道实际是 104 主站把总召响应当成普通遥测塞进了缓存。这类故障在 iec104主站源码 里很典型帧收到了序号也对业务点表却没更新。这份源码解决的就是这件事用一个 TCP 客户端把 104 主站的启停、总召、时钟同步、遥测遥信解析和遥控下发串起来适合做采集网关、协议转换器或测试工具。只要你会改 C 结构体和配置文件就能把它接进自己的点表。2. 骨架与选型104 主站的协议分层、目录结构和配置项104 主站本质上是一个 TCP 客户端主动连到子站的 2404 端口然后靠 APCI 控制域维持链路靠 ASDU 承载业务数据。源码包如果按 C/C 工程整理核心不会绕开三件事TCP 收发的粘包处理、I/S/U 三种帧的序号与确认、ASDU 里类型标识和信息对象地址的解析。把这三件事拆开看目录就不会乱。常见做法是分五层链路层负责 connect、断线重连和 socket 可读事件APCI 层负责 0x68 起始字节、长度、控制域和序号ASDU 层负责类型标识、传送原因、公共地址、信息对象地址点表层负责把 IOA 映射成业务测点应用层负责总召、时钟同步、遥控这种动作。主站是主动方所以 STARTDT 激活、总召命令、测试帧都由主站先发子站回确认。这个方向搞反了后面所有日志都会看着别扭。2.1 协议栈分层与线程模型一份可维护的 104 主站源码通常不会给每个连接开一堆线程。更常见的是单线程 poll/epoll 事件循环收到完整 APDU 后解析业务回调投递到队列再由工作线程写数据库或转发。这样序号状态只在一个线程里改少了锁也少了“两个线程同时加 send_seq”这种玄学问题。下面这段是事件循环的骨架重点看link_readable和timer_tick的位置for (;;) { int n poll(fds, nfds, 1000); /* 1 秒超时顺带跑定时器 */ if (n 0) { if (errno EINTR) continue; /* 被信号打断不当作链路错误 */ break; } if (n 0) { timer_tick(now_ms()); /* t1/t2/t3 超时检查 */ continue; } for (int i 0; i nfds; i) { if (fds[i].revents POLLIN) { if (i link_fd) link_readable(g_link); /* 收 TCP 字节流 */ } } timer_tick(now_ms()); /* 有事件也要检查定时器 */ }poll的超时不是随便写的。104 的 t1 是发送后等确认的超时t2 是无数据时回 S 帧的超时t3 是链路空闲时发 TESTFR 的超时。超时时间通常放在配置里事件循环只负责到点触发。link_readable里不要直接解析业务先往环形缓冲区塞字节再循环取完整 APDU否则 TCP 拆包会把一帧 104 报文切成两半解析器会误判长度。2.2 目录结构逐个文件对号入座不同源码包的文件名可能不一样但职责基本能按下面这张图对上。拿到包后先找main、link、apci、asdu、point这几个词找不到就按“谁处理 socket、谁处理控制域、谁处理类型标识”去翻。iec104-master/ ├── src/ │ ├── main.c # 参数解析、配置加载、启动事件循环 │ ├── link.c # TCP 连接、重连、收发缓冲 │ ├── apci.c # 0x68/长度/I/S/U 帧/序号 │ ├── asdu.c # 类型标识、COT、CA、IOA、信息体 │ ├── point.c # 点表映射、值缓存、回调 │ └── log.c # 带链路上下文的日志 ├── include/ │ ├── iec104.h # APDU/ASDU 结构体与常量 │ └── point.h # 测点回调和点表接口 ├── conf/ │ └── master.ini # 子站地址、CA、超时、总召开关 ├── test/ │ └── mock_slave.py # 本地模拟子站先跑通再接现场 └── CMakeLists.txtlink.c只认字节流不认 104 语义apci.c只认控制域不认遥测asdu.c才认类型标识和 IOA。这样拆的好处是现场出现“连上了但没数据”时你先看link的 connect 和 STARTDT再看apci的序号最后才进asdu查类型。反着查会把一个 TCP 连接问题误判成点表问题。2.3 配置文件与运行参数104 主站的配置项不多但几个时间参数必须可改。不同子站的 t1、t3 和 k/w 窗口不一样写死在代码里换一个现场就要重新编译。常见配置如下[link] ip 192.168.10.20 port 2404 t0 30 ; 连接建立超时秒 t1 15 ; 发送后等确认超时秒 t2 10 ; 无数据时回 S 帧超时秒 t3 20 ; 空闲测试帧超时秒 k 12 ; 未确认 I 帧最大数量 w 8 ; 收到多少 I 帧后必须回 S 帧 reconnect_ms 3000 [station] ca 1 ; 公共地址多站点时按它过滤 auto_interrogation 1 interrogation_delay_ms 500参数常见值作用t030sTCP 连接建立阶段超时t115s发 I 帧后等对端确认的超时t210s没有 I 帧可回时最迟多久回 S 帧t320s链路空闲多久发 TESTFRk12最多允许多少个未确认 I 帧w8收到多少个 I 帧后回一次 S 帧ca1公共地址点表按站号隔离k和w不是装饰参数。主站发得太快、子站回得太慢未确认帧堆到k还不回 S 帧子站会停发w设得太小S 帧满天飞日志很热闹吞吐却上不去。我一般先按 12/8 跑现场有大量总召数据时再看是否调到 12/10 或 8/8调完必须抓包确认 N(R) 在推进。3. 把工程跑起来编译、连接、总召与日志判读先别急着接真实子站。104 主站的第一次运行最稳的办法是本地起一个模拟子站让 STARTDT、总召、遥测上送、S 帧确认都走一遍。很多“源码跑不起来”的问题其实是直接连现场子站不响应日志又只打了“connect ok”根本看不出卡在哪一步。3.1 环境准备与编译命令Linux 下常见依赖就是编译器、CMake 和 make。源码包如果带CMakeLists.txt按下面这套命令走如果只带 Makefile就把cmake两步换成make。可执行文件名以构建脚本里的 target 为准别照着文章硬敲。# 安装基础构建工具已经有的可以跳过 sudo apt install -y build-essential cmake # 在源码根目录生成构建目录Release 版本减少调试符号 cmake -S . -B build -DCMAKE_BUILD_TYPERelease # 并行编译-j 后面跟 CPU 核心数 cmake --build build -j # 查看帮助确认参数名和配置文件路径 ./build/iec104_master --helpcmake -S . -B build的-S是源码目录-B是构建目录源码和产物分开后面清理直接删build。CMAKE_BUILD_TYPERelease会打开优化但调试阶段可以改成Debug方便在apci.c里打断点看控制域。Windows 下如果用 Visual Studio打开生成的 solution 编译即可注意 socket 初始化和WSAGetLastError的差异别把 Linux 的errno日志直接搬过去。3.2 启动参数与连接配置启动前把conf/master.ini里的ip、port、ca改成模拟子站的值。模拟子站可以监听 127.0.0.1:2404主站连上去后先发 STARTDT再发总召。下面这条命令假设可执行文件支持-c指定配置# 前台启动日志直接打到终端方便看第一轮交互 ./build/iec104_master -c conf/master.ini # 如果源码支持日志级别调试时开到 debug ./build/iec104_master -c conf/master.ini -l debug配置文件里auto_interrogation 1表示连接并激活后自动发总召。第一次跑建议打开省得手工敲命令等链路稳定了再关掉改由业务侧定时总召。interrogation_delay_ms 500是 STARTDT 确认后等多久发总召给子站一点准备时间太小容易在模拟子站上看到“总召发出去但回确认很慢”。3.3 首次连接、总召与日志判读一次正常的首次交互日志顺序应该能看出四段TCP 连接成功、U 帧 STARTDT 激活确认、I 帧总召激活、总召确认与数据上送。下面是一段简化日志字段名可能和你的源码不同但顺序可以对[104] connect 192.168.10.20:2404 ok [104] U STARTDT act - con [104] I tx ns0 nr0 type100 cot6 ca1 ioa0 [104] I rx ns0 nr1 type100 cot7 ca1 ioa0 [104] I rx ns1 nr1 type1 cot20 ca1 ioa0x0001 value1 [104] I rx ns2 nr1 type13 cot20 ca1 ioa0x4001 value12.5 [104] I rx ns3 nr1 type100 cot10 ca1 ioa0type100 cot6是总召激活cot7是总召激活确认cot10是总召激活终止。中间cot20是响应总召的突发数据类型 1 是单点遥信类型 13 是短浮点遥测。看到cot7但一直没有cot10通常是子站数据多、主站没回 S 帧或者点表解析在中途抛错。看到cot10却没有遥测先查公共地址ca和点表 IOA别先怀疑浮点字节序。抓包是最后的黑匣子。连接阶段直接抓 2404 端口看有没有68 07 07 00 00 00这种 STARTDT 激活帧以及子站有没有回68 07 0b 00 00 00。如果连 STARTDT 都没有问题在link.c的连接状态机如果 STARTDT 有了但总召没发问题在应用层定时器如果总召发了但没回先看子站是否要求先时钟同步再看 CA 是否匹配。4. 核心链路拆解APCI 控制域、ASDU 头和总召报文怎么落代码104 主站的代码量不大难点在细节。APCI 只有 6 个字节的头ASDU 头也只有 6 个字节加 3 字节 IOA但每一个字节的位都有含义。下面按“收一帧、拆一帧、发一帧总召、解析一个遥测”的顺序拆代码是示意字段名可以按你的工程改。4.1 APCI 三字段与 I/S/U 帧处理APDU 以0x68开头第二个字节是长度长度包含 4 字节控制域和后面的 ASDU不包含0x68和长度本身。控制域四个字节决定是 I 帧、S 帧还是 U 帧I 帧最低位是 0S 帧第一个字节最低位是 1U 帧第一个字节最低两位都是 1。先把这个结构体定义清楚后面解析就不会到处魔数。#define IEC104_START 0x68 #define IEC104_MAX_APDU 253 typedef struct { uint8_t start; /* 固定 0x68 */ uint8_t len; /* 4 字节控制域 ASDU 长度 */ uint8_t ctrl[4]; /* I/S/U 控制域 */ uint8_t asdu[249]; /* 最大 ASDU 长度 */ size_t asdu_len; } iec104_apdu_t; /* 返回值消耗的字节数-1 非 104 帧-2 数据还没收全-3 长度非法 */ int iec104_parse_apdu(const uint8_t *buf, size_t n, iec104_apdu_t *out) { if (n 2 || buf[0] ! IEC104_START) return -1; uint8_t len buf[1]; if (len 4 || len IEC104_MAX_APDU) return -3; if (n (size_t)len 2) return -2; /* TCP 粘包等下一次读 */ out-start buf[0]; out-len len; memcpy(out-ctrl, buf 2, 4); out-asdu_len len - 4; memcpy(out-asdu, buf 6, out-asdu_len); return (int)(len 2); /* 头部 2 字节 len */ }len的下限是 4因为至少要有控制域上限 253 是 104 单帧 APDU 的常见上限。n len 2时不能报错只能返回“还没收全”由外层环形缓冲区继续等。解析函数不要自己recv也不要自己关闭连接它只做字节到结构体的转换。外层收到完整帧后再判断 I/S/U这样 TCP 拆包和协议解析就分开了。I 帧的序号是 15 位send_seq和recv_seq分别左移一位放进控制域最低位留给帧类型。发送成功后send_seq加一并对0x7FFF取模收到 I 帧后把recv_seq更新为对端N(S)1。下面这段是发 I 帧的骨架static int send_i_frame(session_t *s, const uint8_t *asdu, size_t asdu_len) { uint8_t buf[6 249]; if (asdu_len 249) return -1; buf[0] IEC104_START; buf[1] (uint8_t)(asdu_len 4); /* 控制域 4 字节 ASDU */ uint16_t ns (uint16_t)(s-send_seq 1); uint16_t nr (uint16_t)(s-recv_seq 1); buf[2] (uint8_t)(ns 0xFF); buf[3] (uint8_t)(ns 8); buf[4] (uint8_t)(nr 0xFF); buf[5] (uint8_t)(nr 8); memcpy(buf 6, asdu, asdu_len); if (tcp_send_all(s-fd, buf, asdu_len 6) ! 0) return -2; s-send_seq (uint16_t)((s-send_seq 1) 0x7FFF); return 0; }tcp_send_all必须处理短写不能假设一次send就把 6asdu_len 字节全发出去。send_seq只在发送成功后加一失败就保持原值等重连后从 0 开始。nr填的是“我期望对端下一次发的序号”不是“我刚收到的序号”这两个差一会让 S 帧确认错位现场表现就是子站收着收着不发了。U 帧不参与序号STARTDT、STOPDT、TESTFR 都靠控制域第一个字节区分。常见处理是if ((ctrl[0] 0x03) 0x03) { /* U 帧 */ switch (ctrl[0]) { case 0x07: send_u_frame(s, 0x0B); break; /* STARTDT act - con */ case 0x13: send_u_frame(s, 0x23); break; /* STOPDT act - con */ case 0x43: send_u_frame(s, 0x83); break; /* TESTFR act - con */ default: break; } return; }这里最容易翻车的是只发 STARTDT 不处理确认。主站发0x07子站回0x0B后链路才算激活如果主站没等到0x0B就发总召有的子站直接丢弃。TESTFR 也一样收到0x43要回0x83不回的话子站会认为链路死了过一会主动断开。4.2 ASDU 头、信息对象地址与类型标识ASDU 头依次是类型标识 1 字节、可变结构限定词 1 字节、传送原因 2 字节、公共地址 2 字节然后才是信息对象地址 3 字节和信息体。传送原因的低 6 位是原因值最高位 T 表示测试次高位 P/N 表示肯定或否定。公共地址和信息对象地址都是小端IOA 三个字节拼起来。typedef struct { uint8_t type; /* 类型标识如 1/3/13/100 */ uint8_t vsq; /* 最高位 SQ低 7 位对象数量 */ uint8_t cot; /* 传送原因低 6 位 */ uint8_t origin; /* 源发地址 */ uint16_t ca; /* 公共地址小端 */ uint32_t ioa; /* 信息对象地址3 字节小端 */ } asdu_head_t; int parse_asdu_head(const uint8_t *p, size_t len, asdu_head_t *h) { if (len 6) return -1; h-type p[0]; h-vsq p[1]; h-cot p[2] 0x3F; h-origin p[3]; h-ca (uint16_t)(p[4] | (p[5] 8)); if (len 9) return -2; h-ioa (uint32_t)p[6] | ((uint32_t)p[7] 8) | ((uint32_t)p[8] 16); return 9; }vsq的最高位是 SQ低 7 位是信息对象数量。SQ0 表示每个对象都带 3 字节 IOASQ1 表示只有第一个对象带 IOA后续对象地址连续递增。很多简化版源码只处理 SQ0遇到总召里的连续遥测就解析错位表现是第一个点对、后面全错。下面这段分发只演示 SQ0遇到 SQ1 直接返回等补齐连续地址逻辑再放开static void handle_asdu(session_t *s, const uint8_t *a, size_t len) { if (len 6) return; uint8_t type a[0]; uint8_t vsq a[1]; uint8_t cot a[2] 0x3F; uint16_t ca (uint16_t)(a[4] | (a[5] 8)); if (ca ! s-cfg.ca) return; /* 多站点时按 CA 过滤 */ if (vsq 0x80) return; /* SQ1 需要连续 IOA 处理 */ int count vsq 0x7F; size_t off 6; for (int i 0; i count; i) { if (off 3 len) return; uint32_t ioa (uint32_t)a[off] | ((uint32_t)a[off 1] 8) | ((uint32_t)a[off 2] 16); off 3; if (type 13) { /* M_ME_NC_1短浮点 QDS */ if (off 5 len) return; float v; memcpy(v, a off, 4); /* 不要直接强转指针避免对齐问题 */ point_update(ca, ioa, type, v); off 4 1; /* 4 字节浮点 1 字节品质 */ } else if (type 1 || type 3) { /* 单点/双点遥信 QDS */ if (off 1 len) return; uint8_t v a[off]; point_update(ca, ioa, type, v); off 1; /* 品质描述 */ } else { return; /* 未知类型先不猜长度避免带偏后续点 */ } } }type13是短浮点遥测信息体 4 字节 IEEE754 加 1 字节品质type1是单点遥信1 字节 SIQ最低位是值type3是双点遥信1 字节 DIQ低两位是状态。point_update里再做 IOA 到业务点号的映射别把点表逻辑塞进handle_asdu否则以后加类型会改到崩溃。未知类型不要“猜一个长度继续走”直接返回并打日志宁可丢这一帧也不要把后面的点全部错位。4.3 总召、时钟同步与遥测遥信回调总召是主站最常用的主动命令类型标识 100传送原因 6 表示激活信息对象地址填 0信息体 1 字节 QOI20 表示站总召。发送前要确保 STARTDT 已经确认发送后等cot7激活确认数据上送完等cot10激活终止。下面这段拼 ASDU 的代码可以直接对照你的源码static int send_station_interrogation(session_t *s, uint16_t ca) { uint8_t a[16]; size_t n 0; a[n] 100; /* C_IC_NA_1站总召 */ a[n] 0x01; /* SQ0信息对象数量1 */ a[n] 6; /* COT激活 */ a[n] 0; /* 源发地址主站一般填 0 */ a[n] (uint8_t)(ca 0xFF); a[n] (uint8_t)(ca 8); a[n] 0x00; /* IOA0总召固定 */ a[n] 0x00; a[n] 0x00; a[n] 20; /* QOI20站总召 */ return send_i_frame(s, a, n); }ca必须和子站配置一致多站点环境下不能全填 0。QOI20是站总召QOI21~36是分组总召现场如果只关心某几组可以改 QOI但子站要支持。总召发出后不要立刻重发t1内等确认超时后先检查链路是否还在再决定重发一次还是断开重连。连续重发总召会把子站打挂日志里会看到一堆cot6没有对应的cot7。时钟同步是类型 103传送原因同样是 6/7信息体是 7 字节 CP56Time2a。很多主站源码把时钟同步做成可选项因为不是所有子站都要求。需要做时注意秒和毫秒的编码CP56Time2a 的秒字节低 6 位是秒高两位是毫秒高位后面才是毫秒低 8 位直接按普通struct tm填会差出几秒。遥控和遥调更复杂要先选后执行传送原因和 P/N 位都要对第一次改建议先把总召和遥测跑稳再碰遥控。5. 避坑与排查104 主站最容易翻车的四个现场104 主站的日志看起来都差不多都是“收 I 帧、发 S 帧”但故障点分布很集中。下面四条是现场最容易遇到的按“现象 → 原因 → 解决”记比背协议条文管用。5.1 连接成功但一条数据都没有现象TCP 三次握手成功日志打了connect ok之后安静得像断网子站侧也看不到总召。原因主站没有发 STARTDT或者发了0x07但没处理子站回的0x0B链路一直停在“TCP 通了、104 没激活”的状态。还有一种是端口连错连到了子站的管理端口TCP 能通但不讲 104。解决连接成功后第一件事发 STARTDT 激活收到0x0B再置link_active1总召和时钟同步都挂在link_active之后。抓包看有没有68 07 07 00 00 00和68 07 0b 00 00 00。如果只有前者没有后者查子站是否要求先设置某个参数或者 CA 是否配错如果两者都没有查link.c的状态机是不是把发送动作漏了。5.2 总召只回一半后面遥测全断现象总召开始时能收到几十帧突然停了主站还在收但子站不再发过一会 TCP 断开重连。原因主站没有按w回 S 帧或者N(R)填错。子站发到未确认窗口上限就不发了主站以为子站在慢慢发实际是确认号没推进。另一种是recv_seq在收到 I 帧后没有加一S 帧一直确认同一个序号。解决收到 I 帧后更新recv_seq (N(S)1) 0x7FFF累计收到w帧或t2到期就发 S 帧。S 帧格式是68 04 01 00 nr_low nr_high控制域第一个字节固定0x01后面两个字节填recv_seq 1。下面这段可以直接对照static int send_s_frame(session_t *s) { uint8_t f[6] {0x68, 0x04, 0x01, 0x00, 0x00, 0x00}; uint16_t nr (uint16_t)(s-recv_seq 1); f[4] (uint8_t)(nr 0xFF); f[5] (uint8_t)(nr 8); s-last_ack_ms now_ms(); /* 记下确认时间t2 重新计时 */ return tcp_send_all(s-fd, f, 6); }发完 S 帧把last_ack_ms更新t2定时器从这一刻重新算。k窗口也要管未确认 I 帧达到k时暂停发新帧等 S 帧或 I 帧里的 N(R) 推进。只加w不管k总召数据量一大还是会卡。5.3 遥测值变成 0、负数或者巨大数现象遥信对遥测全是 0或者本来 12.5 显示成 1.2e-38换一个子站又正常。原因类型标识和字节序没对上。类型 9 是归一化值类型 11 是标度化值类型 13 才是短浮点把 9 当 13 读4 字节里混进了品质位浮点就成玄学数。还有一种是指针强转float *读未对齐地址在某些平台上直接崩或者读出错值。解决先按类型标识打印原始字节确认type13再用memcpy读 4 字节浮点读完跳过 1 字节品质。类型 9 按 2 字节有符号整数除以 32768 处理类型 11 按 2 字节有符号整数处理不要混。浮点字节序一般是小端但现场如果发现字节颠倒先确认子站实现再决定是否做ntohf类转换不要全局改。5.4 断线重连风暴日志刷满现象主站每隔两三秒重连一次子站连接数暴涨业务侧一条数据都拿不到。原因只做了 TCP 重连没做 104 链路保活。t3 到期没发 TESTFR或者收到0x43没回0x83子站主动断开主站立刻重连形成循环。还有一种是t1超时后把“发送失败”当成“连接失败”直接关 socket。解决t3 到期发 TESTFR 激活0x43收到确认0x83后刷新链路活跃时间收到对端0x43必须回0x83。重连加退避第一次 3 秒连续失败就 5 秒、10 秒别用本文还有配套的精品资源点击获取