企业官网建设流程全解析

简介：IEC 104协议是电力系统远动通信的重要标准，广泛应用于变电站自动化与电网调度领域，贯穿设备调试与运行维护等环节。面向电力自动化工程师、协议开发与测试人员，这套完整的104主站仿真软件工具包内含ProIEC104Client客户端及配套调试模拟工具，可模拟主站功能，用于子站设备兼容性验证、报文解析、错误检测及通信链路调试，覆盖遥测、遥信、遥控、遥调等业务场景，帮助降低协议实施复杂度。压缩包共93个文件、4.18MB，主体为pco报文记录32个、dll动态库30个、xml配置文件14个、pol规约文件10个，另有exe可执行程序与pdf使用说明；其中pco记录保存了多组IEC104与IEC101历史通信报文，便于离线回放和对比分析，xml用于配置通道参数与选择集，pol则收录了IEC104、部颁CDT、MODBUS等多种规约模板，结合规约模板可快速适配不同厂商子站设备。包内集成IEC60870、IEC61850等动态库，具备主站报文发送与子站响应监控能力，而众多历史报文样本还可用于回归测试与故障场景复现，配套说明文档则能缩短上手周期。已有1421人学习下载，适合工程师开展设备调试、故障排查及协议学习。

1. 104主站仿真软件：调度联调前最值得投入的规约测试工具

新到的保护测控装置在实验室用104主站仿真软件一跑，总召唤直接丢了一半遥信。这在以前要到变电站现场联调才会暴露，现在能提前一个小时就定位到装置侧公共地址配错。104主站仿真软件，就是为支持IEC 60870-5-104规约的从站设备（RTU、测控装置、保护装置）提供一个模拟调度主站环境，解决“协议看起来没问题，一到联调就不通”的假性合规问题。它适合电力自动化产品研发、出厂测试和现场调试的工程师，也是让规约一致性从黑匣子变成白盒子的落地工具。下面我按自己的使用习惯，把仿真原理、参数设置和典型坑一次讲透。

2. 104主站仿真的核心原理：从U帧握手到总召唤的完整链路

2.1 链路建立阶段：U帧、S帧、I帧各做什么

104规约跑在TCP之上，默认端口是2404。要理解主站仿真软件，先得把APCI层的三类帧分清。U帧（Unnumbered帧）负责链路控制，典型的有STARTDT act、STOPDT act、TESTFR act；S帧（Supervisory帧）专门做确认；I帧（Information帧）才是携带ASDU的数据帧。

常见的错误是把U帧当心跳用。U帧里TESTFR act是测试链路用的，但很多从站并不主动发TESTFR，主站仿真软件应该在空闲超过t3参数时主动发TESTFR act，并从站必须回TESTFR con。这就是链路保活。而STARTDT act是主站进入数据传输状态的门票，发送后收到STARTDT con，仿真软件才能发起总召唤、遥控这类业务。

主站仿真软件的核心工作就是维护这个状态机：TCP连接建立后，先通过U帧握手激活链路，然后按需发I帧，同时接收从站主动上送的遥信变位和SOE（事件顺序记录）。如果仿真软件把测试帧当成数据帧处理，或者收到S帧后不做状态更新，后续序号就会错位，然后出现大量重复帧或断言错误。

2.2 主站仿真软件的职责划分与常见选型

一个能真正用于生产的104主站仿真软件，至少要具备四块能力。第一是连接管理，包括TCP重连、超时处理、多从站并发。第二是ASDU解析，能正确识别遥信、遥测、遥控、总召唤、时钟同步等类型标识，并把原始字节转成点号、时间和品质位。第三是点表映射，把信息体地址（IOA）映射到内部数据库，否则用户看到的是裸地址不是设备名称。第四是主动测试能力，手动遥控、按计划自动总召唤、故障模拟脚本。

选型上常见有三条路。用成熟的商业测试仪，好处是现场顺手、抓包分析一体化，缺点是点表导入格式经常要转换。用开源库如lib60870、j60870做二次开发，适合研发团队做自动化回归，缺点是得自己写界面或脚本。自己用socket裸写，只适合临时验证链路，不适合做完整测试。我一般会根据场景混用：量产测试用开源库二次开发的工具，现场消缺用便携式商业测试仪。

2.3 为什么必须先建点表再跑流程

主站仿真不是把报文收下来看一眼就完事，核心价值在于把从站上送的ASDU内容映射成“什么时间、哪个点、什么状态、品质如何”。如果点表没建对，哪怕报文完全合规，显示出来的数据也会错位。比如某次测试，从站把遥信点映射到了0x4010，仿真软件却按0x4001解析，结果状态和点位全部错开，测试时间浪费在“数据乱”而不是“规约错”上。

所以仿真软件通常会提供点表导入功能，支持Excel或CSV，字段至少包括信息体地址、点号、名称、类型。导入后最好先做一次“点表一致性核对”，就是让从站上送全部数据，仿真软件自动生成未匹配点清单。这一步基本成了我的固定动作，比事后抓包分析报文省力得多。

3. 搭建104主站仿真环境：从点表配置到总召唤的5个步骤

3.1 测试环境组成与连接关系

搭环境之前先明确设备关系。仿真软件装在PC上，PC的网口通过直连线或交换机接到从站装置网口；如果需要抓手包，就在交换机上做镜像口，或者直接在PC侧用Wireshark。PC网卡IP必须和从站装置在同一个网段，注意有些装置默认网关不能配错，否则TCP连接能建但数据回不来。

连接关系上我习惯把PC和从站放在一个独立测试网段，比如192.168.1.0/24，PC固定为192.168.1.2，装置设为192.168.1.100。端口统一用2404，不需要改。如果装置支持双主站冗余，仿真软件要配置成主备地址；但大部分测试场景只连一个主站。

3.2 点表参数映射表：ASDU地址、信息体地址、类型标识

点表配置是主站仿真的第一个门槛，也是最容易出错的部分。下表列出了我在工程里常用到的基础参数，仿真软件里通常对应“公共地址”和“类型标识”两栏。注意公共地址也叫ASDU地址，是从站装置的站址，不是TCP端口。

信息体地址（IOA）通常由厂方提供点表。仿真软件里需要把IOA范围和点号一一对应，不要只填一个起止范围，尽量精确到每个点。宁可多配几个空点，也不要漏掉装置实际会发上来的点。

3.3 用仿真器发起总召唤的最小配置

以最常见的仿真软件为例，连接前先建立一份配置文件。下面这个JSON示例几乎包含了所有必填项，字段名称不同软件略有差异，但含义一致。

{ "simulator": { "src_ip": "192.168.1.2", "src_port": 2404, "dst_ip": "192.168.1.100", "dst_port": 2404, "common_address": 1, "t0": 10, "t1": 15, "t2": 10, "t3": 20, "k": 12, "w": 8 }, "pointmap": [ { "ioa": 1, "name": "间隔1遥信", "type": "DI" }, { "ioa": 100, "name": "间隔1遥测A相", "type": "AI" }, { "ioa": 201, "name": "间隔1遥控分闸", "type": "DO" } ] }

src_ip和dst_ip是PC和装置的地址，注意src_port默认2404，不要和dst_port混淆。t0到t3是链路超时参数，k和w是滑动窗口参数。common_address必须和从站装置配置一致，这是总召唤能否触发的最关键参数。

配置完成后，启动连接软件会先建立TCP链路，然后自动发送STARTDT act。收到STARTDT con后，软件界面上的“总召唤”按钮才会变成可用状态。点击总召唤后，正常情况下软件会收到从站返回的C_IC_NA_1激活确认（COT=7），然后收到全量遥信遥测数据。如果只看到连接成功，总召唤按钮置灰，说明链路还没激活，去查TCP或U帧。

3.4 用脚本模拟主站报文做快速验证

有些时候从站丢在现场，或者仿真软件还没来得及导点表，想快确认链路通不通，我会用Python socket快速发一个STARTDT act。这个办法只验证链路，不做业务解析，非常适合黑盒状态。

import socket def start_dt_test(ip, port, timeout=3): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) s.connect((ip, port)) s.sendall(bytes.fromhex("68 04 07 00 00 00")) resp = s.recv(1024) s.close() if resp.hex() == "68040b000000": print("STARTDT成功：链路已激活") else: print("链路异常，响应为:", resp.hex()) start_dt_test("192.168.1.100", 2404)

代码里68 04 07 00 00 00是STARTDT act的十六进制，固定6字节；从站如果回68 04 0b 00 00 00就是STARTDT con。这里只做检测，不做I帧，因此不需要处理序号。脚本里的timeout设为3秒，如果从站处理慢或链路丢包，加大到5秒再试，避免误判。

4. 104主站仿真软件的必调参数：超时阈值、K/W窗口与重连策略

4.1 四类超时参数t0/t1/t2/t3怎么设

104规约的可靠性很大程度靠超时参数控制。t0是TCP连接建立的超时时间，网络好时设10秒足够，但经过多级交换机时往往需要放大到15秒。t1是主站发送完一个APDU后等待确认（S帧或I帧）的最大时间，默认15秒。t2是接收方在无数据可发时主动确认的周期，通常设为10秒。t3是链路空闲时发送测试帧的周期，默认20秒。

这里最容易翻车的是t1。总召唤时从站数据量大，从站要到最后一帧发送完才回S帧，如果t1设太短，主站会误以为链路超时，然后发TESTFR甚至重连。我见过把t1设成5秒的配置，总召唤超过10万点直接触发重连，报文反复从第一帧开始，永远收不完。实际使用中，数据量超过5000点就把t1放到20秒。

4.2 K/W滑动窗口与防丢帧设置

K是主站侧最大发送未确认帧数，W是最大接收未确认帧数。在104规约里，K=12、W=8是常见值。主站仿真软件作为发送方时，K值限制它最多连续发多少个I帧而不用等确认；作为接收方时，W值规定它累积收到多少个I帧后必须回一个S帧确认。

如果K设得太大，比如K=20，从站又没跟上，主站连续发遥控和总召唤会造成从站缓冲区溢出。如果W设得太小，比如W=2，接收方每收到两帧就回一个确认，网络流量增加，但在高延迟链路上能降低重传压力。仿真软件一般默认W=8，我建议先在默认值下跑一轮，如果抓包看到大量D帧重传，再把W调小、t1调大。

4.3 针对不同从站装置的兼容性参数组合

规约一致性测试经常碰到老装置，这些装置对参数的要求很“挑剔”。比如某批RTU只接受K=5、W=3，超过了会主动断开链路；还有的装置在收到总召唤时不区分数据帧和确认帧，导致主站窗口迅速填满。遇到这种从站，主站仿真软件必须允许参数覆盖。我一般会先问厂方拿一致性测试报告，按报告里的参数设，没有报告就先从保守值K=5、W=3开始试，再逐步放大。

另一个容易忽视的是重连策略。从站重启后TCP链路会断开，仿真软件要能够自动重新建立连接并再次STARTDT。如果仿真软件只支持手动重连，中途从站断电恢复后测试过程就得人工干预。在自动化测试里，我会把重连次数和重连间隔放在脚本触发逻辑里，而不是简单依赖仿真软件的自愈机制。

5. 104主站仿真常见问题排查：连接失败、总召唤丢数据、遥控不反馈

5.1 TCP连接已建立但总召唤无响应的排查

现象：仿真软件TCP连接显示已建立，但发送总召唤后一直没有对应响应，界面始终停在“等待数据”。原因多数是链路握手没完成，或者公共地址不匹配。

原因：TCP连接成功只代表端口通，不代表104链路激活。主站发了STARTDT act后，从站如果没有回STARTDT con，业务帧不会处理。另外，公共地址不一致时，从站会直接拒收ASDU，有时候连COT=8（激活终止）都不回。

解决：先用上面的Python脚本U帧测试确认STARTDT con是否存在；收不到就用抓包看从站是否回了TCP Reset。再检查仿真软件里的common_address是否和装置一致，以及装置的实际站址是否被人误改过。我碰到过某从站默认站址是0，仿真软件配了1，结果所有I帧全被丢弃，这种问题不抓包根本看不出。

5.2 总召唤只回部分数据：常见原因与定位方法

现象：总召唤触发了，确认帧也收到了，但数据列表里遥信只回了一部分，遥测全没出现。原因集中在点表不完整或装置侧的召唤限定词处理不一致。

原因：从站回传数据时会把总召唤的召唤限定词当作过滤条件。标准总召唤限定词是0x00，表示全站数据；有些装置派生型号支持按地区召唤（限定词非0），仿真软件写了非0限定词，从站就只回部分数据点。

解决：把仿真软件总召唤命令里的召唤限定词强制设为0x00。再看点表里对应的IOA是否越界。我建议在仿真软件上开“未匹配点告警”，从站上送的所有IOA如果不在点表里，就单独列出来。这样既能发现仿真点表缺失，也能反向核对从站实际配置。

5.3 遥控执行成功却收不到确认帧：品质位与时标问题

现象：仿真软件下发遥控开入，从站机构动作了，但仿真软件侧一直显示“超时未确认”。原因常常不在序号，而在传输原因和品质位。

原因：遥控命令的COT（传输原因）必须是6（激活），从站确认用7（激活确认）。如果主站把遥控命令的COT填成其他值，从站虽然执行，但不会回激活确认。另外，遥控反馈的ASDU里如果品质位是无效（低品质），仿真软件出于防误判会过滤掉这条确认。

解决：检查遥控命令帧里的COT，确保是0x06；再检查反馈ASDU的品质字节QDS。有些从站遥控执行后会先上送一个“遥信变位预览”，品质位还处于无效状态，仿真软件如果过早判定就会报超时。更稳的办法是让仿真软件支持“等待变位而非等待确认”，遥控开出后一旦检测到对应遥信点状态翻转，就判定成功，但需要在点表里预先绑定DO和DI的联动关系。

5.4 时钟同步无效：时标格式与同步确认的坑

现象：仿真软件下发时钟同步，从站回确认，但之后再上送SOE事件里的时标还是错的，偏差很大。原因是主站仿真软件发送的CP56Time2a时标字节序不对，或者没有按规约要求先冻结时间。

原因：104规约的时标是CP56Time2a，总共7个字节，包含毫秒、秒、分、时、日、月、年。常见错误是把毫秒和秒的字节序按小端发，但IEC 104里毫秒和秒是低位先传，很多人按习惯转成网络序后整个反了。

解决：抓包对照时标字节。若从站上报SOE的时标和仿真软件本地时间差几分钟，基本就是字节序问题。还有一种情况是时钟同步命令后，从站在收到总召唤前不会重新读取RTC缓存，所以仿真软件做完时钟同步后应该紧接着发一次总召唤，把缓存里的时标刷新。没有这一步，SOE里的旧时标会被当成新时标，看起来就像同步失败。

5.5 仿真软件自身丢帧：W窗与内存缓冲的边界

现象：数据量大时，从站上送遥信变位，仿真软件抓包能看到报文，但业务列表里就是丢点。原因往往不是从站问题，而是仿真软件没及时回S帧，窗口被填满。这是主站仿真软件最隐蔽的丢帧方式。

原因：K/W窗口参数决定接收方必须回S帧的节奏。当W=8时，接收方每收到8个I帧应回一个S帧。如果仿真软件内部用了同步串行处理，解析ASDU耗时较长，第9、10帧都到了但S帧还没发出去，从站默认本方窗口已满，停止再发。此时抓包看到的是从站反复重传同序号帧，不是新数据。

解决：先降低从站侧发送速率，确认仿真软件能否消化；然后优化CSV点表加载或日志输出，避免在数据接收路径里做耗时IO。如果软件支持异步处理，把ASDU解析丢到线程池。参数上可以把W调大，比如W=12，但这只延后问题，最终还是要优化接收吞吐。我在做上千点SOE涌流测试时，习惯把W调到16并关闭实时日志，测完再回放报文，否则实时打印会拖垮解析速度。

6. 进阶用法：用抓包校验仿真结果，并把主站仿真塞进自动化回归

6.1 用抓包工具对照报文序列

主站仿真软件自身有报文显示，但不要迷信它。我每次都会开Wireshark，过滤条件写成tcp.port == 2404。仿真软件显示收到一条总召唤数据，我就去找对应的时间戳和帧序号，直接核对APCI控制域的N(S)、N(R)是否连续，ASDU的类型标识和COT是否符合预期。这个习惯帮我抓到过好几次仿真软件隐藏的解析偏差。

6.2 把主站仿真脚本接入CI流程

对研发团队来说，主站仿真可以做成自动化冒烟测试。常见做法是把点表、用例参数、期望结果全部放到配置目录里，每天晚上自动连上从站，执行总召唤、时钟同步、30条遥控序列，然后比对响应时间、重复帧数和丢点率。一旦发现从站固件回归，仿真软件会立刻输出失败用例清单。我现在的习惯是：每套装置测试前，先用主站仿真软件做一次10分钟的一致性巡检，再开始正式用例；如果巡检发现丢点或帧序号错位，直接打回上一环节，省去后面所有无效劳动。希望帮到你。

本文还有配套的精品资源，点击获取