01 · HslCommunication 与 iot-communication 横向对比与选型

本篇是「工业设备数据采集」知识体系第 06 篇的第 1 篇。定位：给你一个可执行的选型结论，而不是一份中立的功能清单。

前面 04、05 两篇已经分别把两个库拆开讲过一遍（内核、粘包、协议实现、工程特性）。本篇不再重复那些细节，只做横向对照 + 决策。凡是出现"详见 04 篇第 X 章 / 05 篇第 X 章"的地方，说明该结论的详细论证在那一篇。

本文所有数字与结论均来自两份实际源码：

_source/HslJavaLatest/              HslCommunication Java 版（294 个 .java 文件）
_source/iot-communication/          iot-communication v1.5.6（332 主 + 131 测试 .java 文件）

凡是我无法确定、或两家说法冲突的地方，一律标注 （需实测确认）。

本篇目录

第 1 章 两库档案表

1.1 基础档案

Star 数量级说明：上面数字为检索时快照，会随时间变化，请以仓库实时数据为准。此处只表达"HSL 高一个数量级"这一相对关系。

1.2 协议覆盖对比

结论：

• 纯 Modbus / S7 / MC 三协议场景：两者覆盖几乎等价，iot 甚至在西门子数控机床 828D、程序上下传、PLC 启停上更强。
• 多品牌大杂烩现场：HSL 是唯一选择，它的 Profinet/ 下有 19 个品牌目录。
• 视频流：iot 独有 RTSP/H264/MP4。

1.3 依赖与体积

关于"零依赖"的准确表述（这点常被写错）：

iot-communication 不是严格零依赖 —— 它有一个 compile 依赖：slf4j-api。
但 slf4j-api 只是日志门面（接口），不绑定任何实现，
运行时不引入任何额外 jar 也能工作（会用 NOP logger 静默）。
所以它"实质上接近零依赖"，但不能说"零依赖"。

HSL Java 版才是真正的零依赖 —— 没有任何外部 jar。

源码规模（实测）：

1.4 文档形态

iot 的"test 即文档"具体指什么：src/test/java/.../protocol/ 下有大量 Demo* 类（DemoS7Read、DemoS7Write、DemoS7Custom、DemoS7Control、DemoReadTest、McDemoReadTest）。它们不是断言型单测，而是带 main() 的可运行示例，逐个 API 演示一遍：

// _source/iot-communication/src/test/java/.../protocol/s7/service/DemoS7Read.java
S7PLC s7PLC = new S7PLC(EPlcType.S1200, "127.0.0.1");
boolean boolData = s7PLC.readBoolean("DB1.2.0");
List<Boolean> boolDatas = s7PLC.readBoolean("DB1.2.0", "DB1.2.1", "DB1.2.7");
int    intData   = s7PLC.readUInt16("DB14.0");
float  floatData = s7PLC.readFloat32("DB1.0");

我的评价：对"我要接一台 PLC"的工程师，test 即文档比官网文档更好用——能直接跑、能看到真实返回值。缺点是缺少系统性概念讲解（比如"为什么 S7 地址要 ×8"），这正是 03 协议篇补的。

第 2 章 授权与商用风险（重点，先读这一章）

这一章我花了最多时间去核实，因为网上关于 HSL 授权的说法大量互相矛盾。

2.1 事实清单（逐条来自源码/官方）

事实 A：随源码分发的 LICENSE 文件是 LGPL-3.0

_source/HslJava/LICENSE（165 行）

    GNU LESSER GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007

 Copyright (C) 2017 - 2019 Richard.Hu <http://fsf.org/>

注意版权年份是 2017 - 2019。

事实 B：作者在 2019 年 8 月停止开源，转向订阅制

README 原话（英文）："...So from August 2019, no longer open source, turn to the subscription model..."

事实 C：代码里内置授权校验模块，未激活限时 8 小时

_source/HslJavaLatest/HslCommunication/Authorization.java 中，类名与方法名经混淆（如 nzugaydgwadawdibbas()、asdniasnfaksndiqwhawfskhfaiw()），但中文注释是原文：

// 如果需要移除验证，这里返回true即可。
// return true;

/**
 * 商业授权则返回true，否则返回false
 * @return 是否成功进行商业授权
 */
public static boolean asdniasnfaksndiqwhawfskhfaiw( ) { ... }

官方 README 的 C# 调用示例更直白：

// 授权示例 调用一次即可
if(!HslCommunication.Authorization.SetAuthorizationCode( "你的激活码" )) {
    MessageBox.Show( "授权失败!当前程序只能使用8小时!" );
    return;
}

事实 D：官方授权页面区分"试用"与"商用"

试用授权: 加入技术支持VIP群 即可以获得激活码,支持长时间测试使用。
商用授权(赠送源代码): 公对公签订合同。公对公打款,开具增值税发票。
授权页面: hsltechnology.cn/Home/Licence?area=HslCommunication

2.2 我给出的判断（含不确定性）

⚠️ 给工程师的实操建议：这不是法律意见。如果 FastBee 这类项目要闭源商业化交付，在引入 HSL 之前，必须做一件事：发邮件给作者（hsl200909@163.com，官网公示）确认"Java 版用于商业闭源产品的授权口径与费用"，把回复留档。这一步的成本远低于事后被追责。

2.3 授权对比总表

第 3 章 架构对比

3.1 通信内核

HSL 的内核模型（详见 04 篇 §3）：

NetworkBase.ReceiveByMessage(socket, timeOut, netMessage)
        │
        ├─ 阶段 1：读 netMessage.ProtocolHeadBytesLength() 个字节
        │           ↓
        │     netMessage.setHeadBytes(headBytes)
        │           ↓
        ├─ 校验：netMessage.CheckHeadBytesLegal(token)
        │           ↓
        ├─ 阶段 2：contentLength = netMessage.GetContentLengthByHeadBytes()
        │          读 contentLength 个字节
        │           ↓
        └─ 返回 完整一帧 = headBytes + contentBytes

iot 的内核模型（详见 05 篇 §5）：

SocketUtils.read(socket, data, offset, length, maxLength, timeout, waitForMore)
        │
        └─ while (count < length) {
               int len  = (maxLength<=0) ? length-count : min(maxLength, length-count);
               int num  = in.read(data, off, len);
               if (num < 0) throw new SocketException("...disconnected");
               count += num;  off += num;
               if (!waitForMore && num < len) break;   // ← 读短即止
           }

关键差异在 waitForMore：

3.2 线程模型

两者共有的关键约束：因为都是同步阻塞 + 锁住整个往返，一个设备对象同一时刻只能有一个请求在飞。这对自研采集器的设计影响极大——见第 07 篇第 2 章的"设备串行"原则。

3.3 粘包处理方式

最大的一处工程差异：HSL 的 ModbusTcpMessage 里有一段手写的兜底逻辑（2025 年 7 月还在改）：

// _source/HslJavaLatest/HslCommunication/Core/IMessage/ModbusTcpMessage.java
// 从请求帧反推"期望的响应长度"，与 length 字段不一致时以请求为准
int readLength   = (SendBytes[10] & 0xff) * 256 + (SendBytes[11] & 0xff);
int expectLength = isBit ? (readLength - 1) / 8 + 2 : readLength * 2 + 1;
if (expectLength != remainLength && length == 6) {
    // 2025年7月23日 00:15:45  此处以读取的长度为准，剩余长度需要重新计算
    remainLength = expectLength;
}

这段代码的注释很直白——它是在给不规范的从站擦屁股。iot 没有这段，遇到写错 length 的从站会直接读错或超时。

• 遇到野鸡设备（length 字段写错、多回一个字节），HSL 更容易"莫名其妙地就能连上"。
• 但代价是：这段代码会把真实错误悄悄吞掉，让你以为设备是好的，直到某个边界条件才爆。
• iot 的做法更干净：报文不对就报错，逼你去修配置或换设备。

3.4 返回值范式（最核心的设计分歧）

代码对照：

// ============ HSL：必须显式判成功 ============
OperateResultExOne<Short> read = siemens.ReadInt16("M100");
if (read.IsSuccess) {
    short v = read.Content;
} else {
    log.warn("read failed: code={}, msg={}", read.ErrorCode, read.Message);
}

// ============ iot：正常路径就是一行 ============
try {
    short v = s7PLC.readInt16("M100");
} catch (S7CommException e) {
    log.warn("read failed: {}", e.getMessage());
}

我的判断（明确观点）：

HSL 的范式有个真实的坑：Java 没有 C# 的 out 参数，OperateResultExOne<T> 是唯一出路，于是调用方很容易写成 short v = dev.ReadInt16("M100").Content; —— 一行拿到值，但完全忽略了 IsSuccess，网络断了会得到上一次的残留值或默认值。这是现场最难查的 bug 之一。

// ⚠️ 危险写法：编译通过、看起来很优雅，但断网时静默返回垃圾值
short v = melsec.ReadInt16("D100").Content;

工程建议：如果用 HSL，在代码规范里明令禁止上面的写法；或封装一层强制检查的 helper。如果用 iot，注意别用 catch (Exception e) {} 把 McCommException 吞掉——两者是同一类错误的两种表现形式。

3.5 地址解析

一个关键差异：iot 的 S7 地址支持 DB1.2.0 这种"DB号.字节地址.位地址"三段式，而 HSL 的 DB1.2 第二段是字节地址还是位需要看上下文。这块最易踩坑，详见 03 篇 S7 §12。

3.6 序列化设计

代码对照（读取一个结构体）：

// ===== HSL：手写 parse（节选自 04 篇 §6.2）=====
public class TankData implements IDataTransfer {
    public float temperature;
    public short  pressure;

    @Override
    public void ParseSource(byte[] source) {
        temperature = byteTransform.TransFloat(source, 0);
        pressure    = byteTransform.TransInt16(source, 4);
    }
    @Override public byte[] ToSource() { /* 反向写回 */ }
}

// ===== iot：注解（节选自 05 篇 §4.2）=====
public class DemoBean {
    @S7Variable(address = "DB1.0", type = EDataType.INT16)  private short value;
    @S7Variable(address = "DB1.2", type = EDataType.FLOAT32) private float temperature;
}
DemoBean bean = s7Serializer.read(DemoBean.class);      // 一行搞定

我的判断：

• iot 的注解方案生产力更高，改点表不用改解析代码。
• 但反射有代价：每次 read() 都走一遍 Class.getDeclaredFields() + 注解解析。高频采集（100ms 周期）下必须缓存解析结果，否则 GC 压力明显。05 篇 §4.6 对此有评价。
• HSL 的手写方案在热路径上更快、更可控，但点表一改就要动代码。
• 推荐做法：用 iot 的注解做点表定义，但自己写一层解析结果缓存（元数据只解析一次，之后按偏移直接读）。第 07 篇第 2 章的自研采集器就是这么设计的。

第 4 章 API 易用性并排对比

下面三个任务，两库各自给完整可编译代码。

4.1 任务一：读 Modbus 保持寄存器 40001 开始的 4 个字

// ==================== HslCommunication ====================
import HslCommunication.ModBus.ModbusTcpNet;
import HslCommunication.Core.Types.OperateResultExOne;

public class HslModbusDemo {
    public static void main(String[] args) {
        ModbusTcpNet modbus = new ModbusTcpNet("192.168.1.100", 502, (byte) 1);
        // 站号=1，地址从 0 开始（isAddressStartWithZero 默认 true）
        modbus.setAddressStartWithZero(true);

        OperateResultExOne<byte[]> read = modbus.Read("40001", (short) 4);
        if (read.IsSuccess) {
            byte[] data = read.Content;                    // 8 字节
            for (byte b : data) System.out.printf("%02X ", b);
        } else {
            System.out.println("failed: " + read.Message);
        }
        modbus.ConnectClose();
    }
}

// ==================== iot-communication ====================
import com.github.xingshuangs.iot.protocol.modbus.service.ModbusTcp;
import com.github.xingshuangs.iot.utils.HexUtil;

public class IotModbusDemo {
    public static void main(String[] args) {
        ModbusTcp plc = new ModbusTcp(1, "192.168.1.100", 502);
        // 可选：原始报文回调，调试神器
        plc.setComCallback((tag, bytes) ->
            System.out.printf("%s[%d] %s%n", tag, bytes.length, HexUtil.toHexString(bytes)));

        byte[] data = plc.readHoldRegister(0, 4);           // 注意：地址从 0 开始
        for (byte b : data) System.out.printf("%02X ", b);

        plc.close();
    }
}

对比点评：

setComCallback 是 iot 最实用的一项设计，现场排查"为什么读不到"时能省掉 80% 的 Wireshark 时间。这是我给 iot 加分的第一个理由。

4.2 任务二：读西门子 DB1 中偏移 0 开始的 4 个字（8 字节）

// ==================== HslCommunication ====================
import HslCommunication.Profinet.Siemens.SiemensS7Net;
import HslCommunication.Profinet.Siemens.SiemensPLCS;
import HslCommunication.Core.Types.OperateResultExOne;

public class HslS7Demo {
    public static void main(String[] args) {
        SiemensS7Net siemens = new SiemensS7Net(SiemensPLCS.S1200, "192.168.1.110");

        OperateResult connect = siemens.ConnectServer();
        if (!connect.IsSuccess) {
            System.out.println("connect failed: " + connect.Message);
            return;
        }

        OperateResultExOne<byte[]> read = siemens.Read("DB1.0", (short) 8);
        if (read.IsSuccess) {
            byte[] data = read.Content;                    // 8 字节
            for (byte b : data) System.out.printf("%02X ", b);
        } else {
            System.out.println("read failed: " + read.Message);
        }
        siemens.ConnectClose();
    }
}

// ==================== iot-communication ====================
import com.github.xingshuangs.iot.protocol.s7.service.S7PLC;
import com.github.xingshuangs.iot.protocol.s7.enums.EPlcType;
import com.github.xingshuangs.iot.utils.HexUtil;

public class IotS7Demo {
    public static void main(String[] args) {
        S7PLC s7PLC = new S7PLC(EPlcType.S1200, "192.168.1.110");
        s7PLC.setComCallback((tag, bytes) ->
            System.out.printf("%s[%d] %s%n", tag, bytes.length, HexUtil.toHexString(bytes)));

        byte[] data = s7PLC.readByte("DB1.0", 8);             // DB1，偏移 0，8 字节
        for (byte b : data) System.out.printf("%02X ", b);

        s7PLC.close();
    }
}

DB 区与位地址写法两库一致：

siemens.Read("DB1.0", (short) 8);   // HSL：DB1，偏移 0，8 字节
s7PLC.readByte("DB1.0", 8);          // iot：同上

siemens.ReadBool("DB1.0.3");         // HSL：DB1，字节 0，位 3
s7PLC.readBoolean("DB1.0.3");        // iot：同上

siemens.ReadBool("M0.3");            // HSL：M 区字节 0 的位 3
s7PLC.readBoolean("M0.3");           // iot：同上

⚠️ 但要警惕：两库的 TSAP 默认值不同（HSL 用 0x0100 PG 连接，iot 用 0x0300 S7 单边），详见 03 篇 S7 §5.2。这是"同一台 PLC，换库后一边能连一边不能连"的头号原因。

4.3 任务三：读三菱 D100 开始的 10 个字

// ==================== HslCommunication ====================
import HslCommunication.Profinet.Melsec.MelsecMcNet;
import HslCommunication.Core.Types.OperateResultExOne;

public class HslMcDemo {
    public static void main(String[] args) {
        MelsecMcNet melsec = new MelsecMcNet("192.168.1.120", 6000);

        OperateResult connect = melsec.ConnectServer();
        if (!connect.IsSuccess) {
            System.out.println("connect failed: " + connect.Message);
            return;
        }

        OperateResultExOne<byte[]> read = melsec.Read("D100", (short) 10);
        if (read.IsSuccess) {
            short[] values = melsec.getByteTransform().TransInt16(read.Content, 0, 10);
            for (short v : values) System.out.println(v);
        } else {
            System.out.println("read failed: " + read.Message);
        }
        melsec.ConnectClose();
    }
}

// ==================== iot-communication ====================
import com.github.xingshuangs.iot.protocol.melsec.service.McPLC;
import com.github.xingshuangs.iot.protocol.melsec.enums.EMcSeries;
import com.github.xingshuangs.iot.utils.HexUtil;

public class IotMcDemo {
    public static void main(String[] args) {
        McPLC mcPLC = new McPLC(EMcSeries.Q_L, "192.168.1.120", 6000);
        mcPLC.setComCallback((tag, bytes) ->
            System.out.printf("%s[%d] %s%n", tag, bytes.length, HexUtil.toHexString(bytes)));

        byte[] bytes = mcPLC.readBytes("D100", 10);           // 返回 20 字节
        System.out.println(HexUtil.toHexString(bytes));

        mcPLC.close();
    }
}

注意：EMcSeries 决定了帧类型和软元件编码方式（03 篇 MC §3.3）。选错系列的典型症状是 PLC 回 0xC059（命令/子命令不正确）。HSL 则是用不同的类来区分（MelsecMcNet / MelsecMcRNet / MelsecA1ENet），这是两种建模思路的差别：

HSL  ：用「类」区分系列   → MelsecMcNet(QnA/3E) / MelsecMcRNet(iQ-R) / MelsecA1ENet(A/1E)
iot  ：用「枚举」区分系列 → new McPLC(EMcSeries.Q_L | QnA | IQ_R | A, ...)

4.4 API 风格总结

第 5 章 性能考量

5.1 先破除一个幻想

两个库都是 BIO（同步阻塞），都不使用 Netty。

✗ 不要期待"换一个库性能提升一个量级"——不可能
✗ 不要期待"一个线程管 1000 台设备"——不可能
✓ 真正的性能杠杆在：批量合并、轮询编排、连接复用

5.2 对比表

5.3 默认连接策略的差异（重要）

这是选型时最容易被忽略、但影响最大的一点。 如果你用 HSL 做 1 秒周期的 S7 采集且没开长连接，每秒会产生一次完整的 TCP 建连 + COTP CR/CC + Setup Communication，开销是"读一帧"的 3~4 倍。

// HSL 必须显式开长连接
siemens.SetPersistentConnection();

5.4 批量优化能力对比

第 6 章 工程化对比

6.1 新增一个协议的真实成本（估算）

关键差异：HSL 的 INetMessage 让"怎么处理粘包"这件事可复用——新协议只要回答"头多长""剩下多长"两个问题。iot 每个协议都要把这段循环再写一遍（虽然也就 10 行）。这也是 HSL 架构上唯一明显优于 iot 的地方。

6.2 日志方案评价

HSL 自带 LogNet 模块（文件/控制台，6 个等级）不依赖任何日志框架，但与 Spring Boot 的 logback 是两套体系，要额外配置才能统一；iot 只依赖 slf4j-api，天然融入 Spring Boot 日志体系（Spring Boot 默认就有 logback 实现）。对 FastBee 而言，iot 的选择更合适。

第 7 章 选型决策树

                           ┌──────────────────────────┐
                           │  你要接什么设备/协议？     │
                           └────────────┬─────────────┘
                                        │
            ┌───────────────────────────┼───────────────────────────┐
            │                           │                           │
            ▼                           ▼                           ▼
   ┌─────────────────┐        ┌──────────────────┐        ┌──────────────────┐
   │ Modbus / S7 /MC │        │ 欧姆龙/AB/基恩士 │        │ OPC UA / 非标    │
   │ 三协议之内       │        │ 机器人/电表 ...  │        │ 私有 TCP 协议     │
   └────────┬────────┘        └────────┬─────────┘        └────────┬─────────┘
            │                           │                           │
            ▼                           ▼                           ▼
   ┌─────────────────┐          ┌──────────────┐          ┌──────────────────┐
   │ 闭源商用交付？   │          │ 基本只能选    │          │ OPC UA → 用      │
   └────┬──────┬────┘          │ HslCommunic- │          │ Eclipse Milo     │
        │      │               │ ation        │          │ 私有 → Netty 自研 │
      是│      │否             └──────────────┘          └──────────────────┘
        ▼      ▼
  ┌─────────┐ ┌──────────────┐
  │ 选 iot- │ │ 设备规模？    │
  │ communi-│ └──┬───────┬───┘
  │ cation  │    │       │
  │ (MIT)   │ ≤200台   >200台 或
  └─────────┘    │       周期<200ms
                 ▼        ▼
        ┌────────────┐ ┌──────────────┐
        │两者皆可    │ │ 上 Netty     │
        │推荐 iot    │ │ 自研内核     │
        │(MIT+干净)  │ │ (见 07 篇)   │
        └────────────┘ └──────────────┘

7.1 各分支的展开说明

7.2 什么时候不该用这两个库

❌ 别用它们做 OPC UA        → Eclipse Milo（Java 事实标准）
❌ 别用它们做 MQTT 上行      → Eclipse Paho / HiveMQ MQTT Client
❌ 别用它们做高并发网关       → Netty
❌ 别用它们做硬实时控制       → 周期 < 10ms 的场合请上现场总线/运动控制器
❌ 别用它们做历史存储        → TDengine / InfluxDB / IoTDB

第 8 章 给 FastBee 的推荐结论

8.1 FastBee 采集器的现状与需求

项目：FastBee 物联网平台
采集器模块：fastbee-collector
协议需求：Modbus / S7 / MC（三种）
技术栈：Java / Spring Boot / Netty 或 BIO
上行：MQTT
存储：TDengine

三条硬约束：

8.2 我的推荐（分层结论）

┌───────────────────────────────────────────────────────────────┐
│  推荐：iot-communication 为主，HSL 为参考实现，SPI 隔离       │
└───────────────────────────────────────────────────────────────┘

具体分三层：

8.3 为什么是"SPI 隔离"而不是"直接用"

因为无论选哪个库，直接依赖都是错的：

// ❌ 反例：业务代码直接依赖第三方类型
//    一旦要换库 / 库有 bug / 授权出问题，全平台跟着改
private S7PLC s7PLC = new S7PLC(EPlcType.S1200, ip);

// ✅ 正解：定义自己的驱动接口
public interface ProtocolDriver {
    void connect(DeviceConfig cfg) throws DriverException;
    byte[] read(TagConfig tag) throws DriverException;
    void write(TagConfig tag, byte[] value) throws DriverException;
    void close();
}
// 实现类 S7Driver / ModbusDriver / McDriver 内部爱用什么用什么

好处：换库成本 = 换一个实现类（授权出问题可一周内换掉）；可混用（S7 用 iot、MC 用 HSL）；可自研（某个协议自己写不影响别的）；可测试（mock driver 就能测调度器）。

07 篇第 2 章会给出这个 SPI 的完整可编译代码。

8.4 什么时候 FastBee 该上 Netty

见 07 篇 §10 性能预估表。一句话结论：

单采集器 ≤ 200 台设备、采集周期 ≥ 500ms  → BIO 一设备一线程，够用，别折腾
超过这个规模                             → 内核换 Netty，驱动接口不动

因为接口层已经隔离了，换内核不影响上层——这正是 SPI 设计的价值兑现点。

第 9 章 迁移路径与风险清单

9.1 迁移真实成本与风险总表

成本分布（从便宜到昂贵）：

风险总表：

9.3 授权合规检查清单（给法务/技术负责人）

□ 1. 确认最终产品是否闭源交付？如果是 → HSL 需要书面授权
□ 2. 确认是否修改了库的源码？如果是 → LGPL 要求开放修改部分
□ 3. 确认是否只有 Java 版，还是 C# 主库也要用？→ 分别确认
□ 4. 发邮件给作者确认口径，留存回复
□ 5. 在项目 LICENSE/NOTICE 中声明依赖及其许可
□ 6. iot（MIT）：保留版权声明即可，记得加
□ 7. 建立依赖清单（SBOM），定期审计

第 10 章 小结

10.1 三句话结论

1. 授权是第一决策因素：iot-communication 是 MIT（注意：不是常见的 Apache-2.0 说法，实际是 MIT，已在 _source/iot-communication/LICENSE 与 pom.xml 双重核实）；HslCommunication 源码树里躺着 LGPL-3.0（2017-2019），但作者 2019 年 8 月起停止开源、现行口径为付费商用授权。闭源商业产品选 iot。

2. 架构上 HSL 更精巧，工程上 iot 更好用：HSL 的 INetMessage（33 个帧解析器）是可复用的定帧抽象，这是它唯一明显领先的地方；但 iot 的内置报文回调、注解序列化、131 个测试、标准 Maven 工程，在日常开发里收益更直接。

3. 对 FastBee：用 iot 做实现，用自研 SPI 做隔离。不要让任何第三方类型泄漏到业务层。这样授权风险、库 bug、性能瓶颈三者都变成了"换一个实现类"的问题。

10.2 一张速查卡

10.3 接下来读什么

本篇数据来源：_source/HslJavaLatest/（294 个 .java）、_source/iot-communication/（v1.5.6，332 主 + 131 测试）。Star/Fork 为检索时快照，以仓库实时数据为准。所有协议级数字（125 / 2000 / 123 / PDU-28 / 19 item / 960 字 / 7168 位）已在 03 协议篇三篇文档中逐条核对。

本文是《工业通信与数据采集》栏目第 19/22 篇 · 上一篇：基础设施与工程特性 ｜ 栏目总览 ｜ 下一篇：自研采集器设计实战