尧图网站开发 
简介这是一套基于Java开发的IEC 62056-21 C模式主站协议库面向能源计量、智能家居与市政管理领域的开发者用于通过串口或网络连接燃气表、水表、热量表、电表等计量装置读取符合国际标准的能源数据。协议库封装了底层通信细节开发者可专注业务逻辑适用于自动化抄表、远程监控与数据采集系统。资源包共25个文件约119KB包含java源码、gradle构建脚本、properties配置、xml与txt说明文档、jar依赖及LICENSE等目录结构清晰便于快速集成与二次开发。目前已有45人学习下载。通过该库可掌握IEC 62056-21 C模式的通信流程、串口与网络双通道实现方式及标准化数据模型为能源计量项目提供可复用的主站协议基础。1. 从一块燃气表的读数说起Java 主站协议库到底解决什么问题手头有一块燃气表RS485 接口说明书上写着支持 IEC 62056-21 协议。你拿 USB 转串口接上打开串口调试助手发一串十六进制过去回来的东西看不懂——有/XXX5\开头的有带括号和星号的还有一堆\x02、\x03控制字符。这就是很多人第一次接触 IEC 62056-21 的场景。它是一套国际电工委员会定义的抄表通信协议分模式 A 到模式 E其中 C 模式是应用最广的一种主站发一个带设备地址的请求帧从站回一个可变长度的数据帧里面用 OBIS 码标识每个数据项比如电量、流量、瞬时功率。标题里说的「Java 主站协议库」就是把这套帧格式、握手流程、数据解析封装成 Java 可调用的 API让你不用每次手写字节数组。它面向的是燃气表、水表、热量表、电表这些能源计量装置连接方式可以是串口也可以是网络比如串口服务器转 TCP。适合谁做能源管理系统、远程抄表平台、能耗监测后台的 Java 后端工程师以及需要把表计数据接进自己系统的集成人员。2. 拆解 IEC 62056-21 C 模式帧结构、握手与 OBIS 编码2.1 C 模式的三段式交互流程IEC 62056-21 的 C 模式交互分三个阶段唤醒与协商、数据读取、释放连接。主站先发一个「请求消息」格式是/ 设备地址 \ 命令 \r\n。设备地址可以是厂商自定义的也可以是?????做广播探测。命令里最常用的是P读数据和W写数据。从站收到后回一个「应答消息」以\x02开头后面跟数据体以\x03结尾最后跟一个校验字节 BCC。BCC 是从\x02之后到\x03之前所有字节的异或值。这个校验逻辑很简单但漏掉就会导致解析全乱。数据体内部是「数据块」的序列每个数据块由 OBIS 码、值、单位、状态组成。OBIS 码是 6 个字节的标识比如1.8.0表示正向有功总电能0.9.1表示当前时间。值可能是数字、字符串或复合结构。C 模式还支持「读一个数据块」和「读多个数据块」两种请求后者用R命令加 OBIS 列表。2.2 串口与网络两种连接的抽象差异串口连接的核心参数是波特率、数据位、停止位、校验位。IEC 62056-21 常见波特率是 300、9600、19200部分设备支持 115200。C 模式在握手阶段会协商波特率主站先以 300 波特发请求从站回应后双方切换到更高波特率。这个「波特率切换」是很多新手翻车的地方——切换时机不对后面全是乱码。网络连接通常是通过串口服务器如 Moxa、有人物联网的模块把 RS485 转成 TCP。对 Java 库来说底层从SerialPort换成Socket但协议层完全一样。区别在于网络连接有超时和重连问题串口连接有流控和缓冲区问题。库的设计上一般会抽象一个Connection接口串口和 TCP 各实现一份上层协议逻辑复用。2.3 OBIS 码的解析与单位换算OBIS 码的 6 个字节分别代表介质、通道、物理量、测量类型、 tariff、存储号。比如1.8.0中1是电8是正向有功0是总。燃气表常用3.0.0或3.6.0。解析时不能只按字符串切分因为有些设备返回的 OBIS 码带前导零或省略部分字节。稳妥做法是维护一个 OBIS 映射表把常见码和含义、单位、倍率对应起来。倍率很重要表计返回的可能是12345但实际值是123.45 kWh因为倍率是0.01。这个倍率通常写在设备参数里或者通过读0.2.0之类的 OBIS 获取。3. 用 Java 实现一个最小可用的主站协议库3.1 连接层串口与 TCP 的统一抽象先定义连接接口把「打开、关闭、读、写」四个动作抽象出来。串口用 jSerialComm 或 RXTXTCP 用java.net.Socket。下面是一个简化版接口和串口实现的核心代码。public interface Connection { void open() throws IOException; void close() throws IOException; void write(byte[] data) throws IOException; byte[] read(int timeoutMs) throws IOException; boolean isOpen(); } public class SerialConnection implements Connection { private SerialPort port; private final String portName; private final int baudRate; public SerialConnection(String portName, int baudRate) { this.portName portName; this.baudRate baudRate; } Override public void open() { // 8 数据位1 停止位无校验无流控 port SerialPort.getCommPort(portName); port.setComPortParameters(baudRate, 8, SerialPort.ONE_STOP_BIT, SerialPort.NO_PARITY); port.setComPortTimeouts(SerialPort.TIMEOUT_READ_SEMI_BLOCKING, 2000, 0); if (!port.openPort()) { throw new RuntimeException(串口打开失败: portName); } } Override public void write(byte[] data) throws IOException { port.getOutputStream().write(data); port.getOutputStream().flush(); } Override public byte[] read(int timeoutMs) throws IOException { // 简化按超时读取可用字节实际库中需处理帧边界 byte[] buf new byte[1024]; int len port.getInputStream().read(buf); if (len 0) return new byte[0]; byte[] out new byte[len]; System.arraycopy(buf, 0, out, 0, len); return out; } Override public void close() { if (port ! null port.isOpen()) port.closePort(); } Override public boolean isOpen() { return port ! null port.isOpen(); } }这段代码的关键点setComPortTimeouts的读超时设为 2000ms因为 C 模式从站响应可能慢read方法没有做帧完整性判断实际库中需要根据\x02和\x03来切帧。参数上波特率在握手阶段会变所以SerialConnection需要支持动态改波特率或者由上层重新打开。3.2 帧的组装与 BCC 校验请求帧的组装很直接/ 地址 \ 命令 \r\n。地址通常是 5 个字符不足补?或空格。命令P后面可以跟 OBIS 码比如P1.8.0。应答帧的解析要先找\x02再找\x03然后算 BCC。public class FrameCodec { public static byte[] buildRequest(String address, String command) { String frame / address \\ command \r\n; return frame.getBytes(StandardCharsets.US_ASCII); } public static byte[] extractData(byte[] raw) { int start -1, end -1; for (int i 0; i raw.length; i) { if (raw[i] 0x02) start i; if (raw[i] 0x03) { end i; break; } } if (start 0 || end 0 || end start) return null; byte[] data new byte[end - start - 1]; System.arraycopy(raw, start 1, data, 0, data.length); return data; } public static boolean checkBcc(byte[] raw) { int start -1, end -1; for (int i 0; i raw.length; i) { if (raw[i] 0x02) start i; if (raw[i] 0x03) { end i; break; } } if (start 0 || end 0) return false; byte bcc 0; for (int i start; i end; i) { bcc ^ raw[i]; } // 假设 BCC 在 \x03 之后一个字节 if (end 1 raw.length) return false; return bcc raw[end 1]; } }buildRequest里地址和命令之间用\分隔这是 C 模式的标准格式。extractData只取\x02和\x03之间的内容不含控制字符。checkBcc从\x02异或到\x03结果和\x03后一个字节比较。注意有些设备 BCC 计算不包含\x02这时需要按设备手册调整。参数上地址长度、命令大小写、结束符\r\n都可能因厂商而异库应该提供配置项。3.3 数据解析从 OBIS 到业务对象拿到数据体后按()和*切分。典型格式是1.8.0(12345*0.01*kWh)表示 OBIS 码1.8.0值12345倍率0.01单位kWh。解析时先按)分段再对每段提取 OBIS 和括号内容。public class DataParser { public static MapString, DataItem parse(byte[] data) { String text new String(data, StandardCharsets.US_ASCII); MapString, DataItem result new HashMap(); // 按 ) 分割每段形如 1.8.0(12345*0.01*kWh String[] parts text.split(\\)); for (String part : parts) { int idx part.indexOf((); if (idx 0) continue; String obis part.substring(0, idx).trim(); String body part.substring(idx 1); String[] fields body.split(\\*); DataItem item new DataItem(); item.obis obis; item.rawValue fields[0]; if (fields.length 1) item.scale Double.parseDouble(fields[1]); if (fields.length 2) item.unit fields[2]; result.put(obis, item); } return result; } }parse方法假设数据体是 ASCII 文本这是 C 模式最常见的情况。但有些设备返回二进制编码的数值这时需要按字节解析。split(\\))会丢掉最后一个)之后的内容如果数据体末尾有换行或校验不影响。scale和unit可能缺失所以做了长度判断。实际库中DataItem还应该包含时间戳、状态字以及一个getValue()方法把rawValue * scale算出来。4. 避坑与排查串口和网络连接下的 5 个血泪教训4.1 波特率切换后收不到数据现象300 波特发请求从站回应了切到 9600 后读不到任何字节。原因C 模式的波特率切换是在从站应答帧里带一个B命令主站收到后要立刻切换但很多串口库的setBaudRate会清空缓冲区导致后续数据丢失。解决切换前先读干净缓冲区切换后延时 50ms 再发下一帧。或者用「先关闭再以新波特率打开」的方式但这样会丢失从站状态。4.2 BCC 校验总是不对现象手动算 BCC 和从站返回的对不上。原因不同厂商对 BCC 的计算范围定义不同有的包含\x02有的不包含有的把\x03也算进去。解决先按标准\x02到\x03异或实现如果不对试「\x02之后到\x03之前」或「包含\x03」。最稳妥是抓一次正常通信的原始字节反推校验范围。4.3 串口被占用导致打开失败现象port.openPort()返回 false或者抛异常。原因Windows 下串口被其他程序占用比如串口调试助手没关Linux 下权限不足或 udev 规则没配。解决Windows 用「设备管理器」看端口占用或者用handle.exe查Linux 把用户加入dialout组并检查/dev/ttyUSB*权限。代码里加一个重试和友好提示。4.4 TCP 连接下帧边界错乱现象通过串口服务器读数据一次read拿到半帧或者两帧粘在一起。原因TCP 是流式协议不保证消息边界。串口服务器可能把多个串口帧合并成一个 TCP 包。解决在应用层做缓冲按\x02和\x03切帧。维护一个ByteArrayOutputStream每次读到数据就追加然后循环查找完整帧。超时时间内没凑齐就丢弃。4.5 OBIS 码带前导零导致匹配失败现象设备返回01.08.00但映射表里是1.8.0匹配不上。原因不同厂商对 OBIS 码的格式化不同有的补零到固定长度。解决解析时先规范化去掉每段的前导零再查表。或者用正则匹配。注意0.0.0这种全零的不要去掉。5. 进阶用虚拟串口做回归测试与协议库的边界验证真实表计不可能随时在手边回归测试怎么办我一般用 com0com 或 socat 建一对虚拟串口一端跑一个模拟从站的程序另一端跑主站库。模拟从站不需要完整实现协议只要按 C 模式回固定的字节序列就行。这样能覆盖正常读、超时、BCC 错误、波特率切换、多数据块。下面是一个用 Java 写的最小模拟从站跑在虚拟串口的一端。public class MockSlave { public static void main(String[] args) throws Exception { SerialPort port SerialPort.getCommPort(COM10); // 虚拟串口对的一端 port.setComPortParameters(300, 8, SerialPort.ONE_STOP_BIT, SerialPort.NO_PARITY); port.openPort(); InputStream in port.getInputStream(); OutputStream out port.getOutputStream(); byte[] buf new byte[256]; while (true) { int len in.read(buf); if (len 0) continue; String req new String(buf, 0, len, StandardCharsets.US_ASCII); if (req.startsWith(/)) { // 模拟应答\x02 数据 \x03 BCC String data 1.8.0(12345*0.01*kWh); byte[] dataBytes data.getBytes(StandardCharsets.US_ASCII); byte[] frame new byte[dataBytes.length 3]; frame[0] 0x02; System.arraycopy(dataBytes, 0, frame, 1, dataBytes.length); frame[frame.length - 2] 0x03; byte bcc 0; for (int i 0; i frame.length - 1; i) bcc ^ frame[i]; frame[frame.length - 1] bcc; out.write(frame); out.flush(); } } } }这个模拟从站只处理最简单的读请求返回一个固定数据块。参数上虚拟串口对的名字要对应比如 com0com 建COM10和COM11主站连COM11从站连COM10。波特率设 300 是为了匹配 C 模式初始握手实际测试时可以改成 9600。用这个方式我能在没有真实表计的情况下跑通 90% 的协议逻辑剩下的 10% 是厂商私有命令和异常码只能靠现场抓包。验证协议库是否健壮我习惯看三个指标帧解析成功率用模拟从站发 1000 帧看解析出多少、异常恢复时间拔掉串口再插上库能否自动重连、内存增长连续跑 24 小时看缓冲区有没有泄漏。这些比看代码覆盖率实在。最后说一个我自己的教训早期我图省事把 BCC 校验写成「可选」结果现场一批表计因为线路干扰返回错误帧库直接抛异常导致整个采集线程挂掉。后来改成「校验失败记录日志并跳过该帧」系统才稳下来。协议库这种东西容错比功能重要。希望帮到你。本文还有配套的精品资源点击获取 
简介这是一套基于Java开发的IEC 62056-21 C模式主站协议库面向能源计量、智能家居与市政管理领域的开发者用于通过串口或网络连接燃气表、水表、热量表、电表等计量装置读取符合国际标准的能源数据。协议库封装了底层通信细节开发者可专注业务逻辑适用于自动化抄表、远程监控与数据采集系统。资源包共25个文件约119KB包含java源码、gradle构建脚本、properties配置、xml与txt说明文档、jar依赖及LICENSE等目录结构清晰便于快速集成与二次开发。目前已有45人学习下载。通过该库可掌握IEC 62056-21 C模式的通信流程、串口与网络双通道实现方式及标准化数据模型为能源计量项目提供可复用的主站协议基础。1. 从一块燃气表的读数说起Java 主站协议库到底解决什么问题手头有一块燃气表RS485 接口说明书上写着支持 IEC 62056-21 协议。你拿 USB 转串口接上打开串口调试助手发一串十六进制过去回来的东西看不懂——有/XXX5\开头的有带括号和星号的还有一堆\x02、\x03控制字符。这就是很多人第一次接触 IEC 62056-21 的场景。它是一套国际电工委员会定义的抄表通信协议分模式 A 到模式 E其中 C 模式是应用最广的一种主站发一个带设备地址的请求帧从站回一个可变长度的数据帧里面用 OBIS 码标识每个数据项比如电量、流量、瞬时功率。标题里说的「Java 主站协议库」就是把这套帧格式、握手流程、数据解析封装成 Java 可调用的 API让你不用每次手写字节数组。它面向的是燃气表、水表、热量表、电表这些能源计量装置连接方式可以是串口也可以是网络比如串口服务器转 TCP。适合谁做能源管理系统、远程抄表平台、能耗监测后台的 Java 后端工程师以及需要把表计数据接进自己系统的集成人员。2. 拆解 IEC 62056-21 C 模式帧结构、握手与 OBIS 编码2.1 C 模式的三段式交互流程IEC 62056-21 的 C 模式交互分三个阶段唤醒与协商、数据读取、释放连接。主站先发一个「请求消息」格式是/ 设备地址 \ 命令 \r\n。设备地址可以是厂商自定义的也可以是?????做广播探测。命令里最常用的是P读数据和W写数据。从站收到后回一个「应答消息」以\x02开头后面跟数据体以\x03结尾最后跟一个校验字节 BCC。BCC 是从\x02之后到\x03之前所有字节的异或值。这个校验逻辑很简单但漏掉就会导致解析全乱。数据体内部是「数据块」的序列每个数据块由 OBIS 码、值、单位、状态组成。OBIS 码是 6 个字节的标识比如1.8.0表示正向有功总电能0.9.1表示当前时间。值可能是数字、字符串或复合结构。C 模式还支持「读一个数据块」和「读多个数据块」两种请求后者用R命令加 OBIS 列表。2.2 串口与网络两种连接的抽象差异串口连接的核心参数是波特率、数据位、停止位、校验位。IEC 62056-21 常见波特率是 300、9600、19200部分设备支持 115200。C 模式在握手阶段会协商波特率主站先以 300 波特发请求从站回应后双方切换到更高波特率。这个「波特率切换」是很多新手翻车的地方——切换时机不对后面全是乱码。网络连接通常是通过串口服务器如 Moxa、有人物联网的模块把 RS485 转成 TCP。对 Java 库来说底层从SerialPort换成Socket但协议层完全一样。区别在于网络连接有超时和重连问题串口连接有流控和缓冲区问题。库的设计上一般会抽象一个Connection接口串口和 TCP 各实现一份上层协议逻辑复用。2.3 OBIS 码的解析与单位换算OBIS 码的 6 个字节分别代表介质、通道、物理量、测量类型、 tariff、存储号。比如1.8.0中1是电8是正向有功0是总。燃气表常用3.0.0或3.6.0。解析时不能只按字符串切分因为有些设备返回的 OBIS 码带前导零或省略部分字节。稳妥做法是维护一个 OBIS 映射表把常见码和含义、单位、倍率对应起来。倍率很重要表计返回的可能是12345但实际值是123.45 kWh因为倍率是0.01。这个倍率通常写在设备参数里或者通过读0.2.0之类的 OBIS 获取。3. 用 Java 实现一个最小可用的主站协议库3.1 连接层串口与 TCP 的统一抽象先定义连接接口把「打开、关闭、读、写」四个动作抽象出来。串口用 jSerialComm 或 RXTXTCP 用java.net.Socket。下面是一个简化版接口和串口实现的核心代码。public interface Connection { void open() throws IOException; void close() throws IOException; void write(byte[] data) throws IOException; byte[] read(int timeoutMs) throws IOException; boolean isOpen(); } public class SerialConnection implements Connection { private SerialPort port; private final String portName; private final int baudRate; public SerialConnection(String portName, int baudRate) { this.portName portName; this.baudRate baudRate; } Override public void open() { // 8 数据位1 停止位无校验无流控 port SerialPort.getCommPort(portName); port.setComPortParameters(baudRate, 8, SerialPort.ONE_STOP_BIT, SerialPort.NO_PARITY); port.setComPortTimeouts(SerialPort.TIMEOUT_READ_SEMI_BLOCKING, 2000, 0); if (!port.openPort()) { throw new RuntimeException(串口打开失败: portName); } } Override public void write(byte[] data) throws IOException { port.getOutputStream().write(data); port.getOutputStream().flush(); } Override public byte[] read(int timeoutMs) throws IOException { // 简化按超时读取可用字节实际库中需处理帧边界 byte[] buf new byte[1024]; int len port.getInputStream().read(buf); if (len 0) return new byte[0]; byte[] out new byte[len]; System.arraycopy(buf, 0, out, 0, len); return out; } Override public void close() { if (port ! null port.isOpen()) port.closePort(); } Override public boolean isOpen() { return port ! null port.isOpen(); } }这段代码的关键点setComPortTimeouts的读超时设为 2000ms因为 C 模式从站响应可能慢read方法没有做帧完整性判断实际库中需要根据\x02和\x03来切帧。参数上波特率在握手阶段会变所以SerialConnection需要支持动态改波特率或者由上层重新打开。3.2 帧的组装与 BCC 校验请求帧的组装很直接/ 地址 \ 命令 \r\n。地址通常是 5 个字符不足补?或空格。命令P后面可以跟 OBIS 码比如P1.8.0。应答帧的解析要先找\x02再找\x03然后算 BCC。public class FrameCodec { public static byte[] buildRequest(String address, String command) { String frame / address \\ command \r\n; return frame.getBytes(StandardCharsets.US_ASCII); } public static byte[] extractData(byte[] raw) { int start -1, end -1; for (int i 0; i raw.length; i) { if (raw[i] 0x02) start i; if (raw[i] 0x03) { end i; break; } } if (start 0 || end 0 || end start) return null; byte[] data new byte[end - start - 1]; System.arraycopy(raw, start 1, data, 0, data.length); return data; } public static boolean checkBcc(byte[] raw) { int start -1, end -1; for (int i 0; i raw.length; i) { if (raw[i] 0x02) start i; if (raw[i] 0x03) { end i; break; } } if (start 0 || end 0) return false; byte bcc 0; for (int i start; i end; i) { bcc ^ raw[i]; } // 假设 BCC 在 \x03 之后一个字节 if (end 1 raw.length) return false; return bcc raw[end 1]; } }buildRequest里地址和命令之间用\分隔这是 C 模式的标准格式。extractData只取\x02和\x03之间的内容不含控制字符。checkBcc从\x02异或到\x03结果和\x03后一个字节比较。注意有些设备 BCC 计算不包含\x02这时需要按设备手册调整。参数上地址长度、命令大小写、结束符\r\n都可能因厂商而异库应该提供配置项。3.3 数据解析从 OBIS 到业务对象拿到数据体后按()和*切分。典型格式是1.8.0(12345*0.01*kWh)表示 OBIS 码1.8.0值12345倍率0.01单位kWh。解析时先按)分段再对每段提取 OBIS 和括号内容。public class DataParser { public static MapString, DataItem parse(byte[] data) { String text new String(data, StandardCharsets.US_ASCII); MapString, DataItem result new HashMap(); // 按 ) 分割每段形如 1.8.0(12345*0.01*kWh String[] parts text.split(\\)); for (String part : parts) { int idx part.indexOf((); if (idx 0) continue; String obis part.substring(0, idx).trim(); String body part.substring(idx 1); String[] fields body.split(\\*); DataItem item new DataItem(); item.obis obis; item.rawValue fields[0]; if (fields.length 1) item.scale Double.parseDouble(fields[1]); if (fields.length 2) item.unit fields[2]; result.put(obis, item); } return result; } }parse方法假设数据体是 ASCII 文本这是 C 模式最常见的情况。但有些设备返回二进制编码的数值这时需要按字节解析。split(\\))会丢掉最后一个)之后的内容如果数据体末尾有换行或校验不影响。scale和unit可能缺失所以做了长度判断。实际库中DataItem还应该包含时间戳、状态字以及一个getValue()方法把rawValue * scale算出来。4. 避坑与排查串口和网络连接下的 5 个血泪教训4.1 波特率切换后收不到数据现象300 波特发请求从站回应了切到 9600 后读不到任何字节。原因C 模式的波特率切换是在从站应答帧里带一个B命令主站收到后要立刻切换但很多串口库的setBaudRate会清空缓冲区导致后续数据丢失。解决切换前先读干净缓冲区切换后延时 50ms 再发下一帧。或者用「先关闭再以新波特率打开」的方式但这样会丢失从站状态。4.2 BCC 校验总是不对现象手动算 BCC 和从站返回的对不上。原因不同厂商对 BCC 的计算范围定义不同有的包含\x02有的不包含有的把\x03也算进去。解决先按标准\x02到\x03异或实现如果不对试「\x02之后到\x03之前」或「包含\x03」。最稳妥是抓一次正常通信的原始字节反推校验范围。4.3 串口被占用导致打开失败现象port.openPort()返回 false或者抛异常。原因Windows 下串口被其他程序占用比如串口调试助手没关Linux 下权限不足或 udev 规则没配。解决Windows 用「设备管理器」看端口占用或者用handle.exe查Linux 把用户加入dialout组并检查/dev/ttyUSB*权限。代码里加一个重试和友好提示。4.4 TCP 连接下帧边界错乱现象通过串口服务器读数据一次read拿到半帧或者两帧粘在一起。原因TCP 是流式协议不保证消息边界。串口服务器可能把多个串口帧合并成一个 TCP 包。解决在应用层做缓冲按\x02和\x03切帧。维护一个ByteArrayOutputStream每次读到数据就追加然后循环查找完整帧。超时时间内没凑齐就丢弃。4.5 OBIS 码带前导零导致匹配失败现象设备返回01.08.00但映射表里是1.8.0匹配不上。原因不同厂商对 OBIS 码的格式化不同有的补零到固定长度。解决解析时先规范化去掉每段的前导零再查表。或者用正则匹配。注意0.0.0这种全零的不要去掉。5. 进阶用虚拟串口做回归测试与协议库的边界验证真实表计不可能随时在手边回归测试怎么办我一般用 com0com 或 socat 建一对虚拟串口一端跑一个模拟从站的程序另一端跑主站库。模拟从站不需要完整实现协议只要按 C 模式回固定的字节序列就行。这样能覆盖正常读、超时、BCC 错误、波特率切换、多数据块。下面是一个用 Java 写的最小模拟从站跑在虚拟串口的一端。public class MockSlave { public static void main(String[] args) throws Exception { SerialPort port SerialPort.getCommPort(COM10); // 虚拟串口对的一端 port.setComPortParameters(300, 8, SerialPort.ONE_STOP_BIT, SerialPort.NO_PARITY); port.openPort(); InputStream in port.getInputStream(); OutputStream out port.getOutputStream(); byte[] buf new byte[256]; while (true) { int len in.read(buf); if (len 0) continue; String req new String(buf, 0, len, StandardCharsets.US_ASCII); if (req.startsWith(/)) { // 模拟应答\x02 数据 \x03 BCC String data 1.8.0(12345*0.01*kWh); byte[] dataBytes data.getBytes(StandardCharsets.US_ASCII); byte[] frame new byte[dataBytes.length 3]; frame[0] 0x02; System.arraycopy(dataBytes, 0, frame, 1, dataBytes.length); frame[frame.length - 2] 0x03; byte bcc 0; for (int i 0; i frame.length - 1; i) bcc ^ frame[i]; frame[frame.length - 1] bcc; out.write(frame); out.flush(); } } } }这个模拟从站只处理最简单的读请求返回一个固定数据块。参数上虚拟串口对的名字要对应比如 com0com 建COM10和COM11主站连COM11从站连COM10。波特率设 300 是为了匹配 C 模式初始握手实际测试时可以改成 9600。用这个方式我能在没有真实表计的情况下跑通 90% 的协议逻辑剩下的 10% 是厂商私有命令和异常码只能靠现场抓包。验证协议库是否健壮我习惯看三个指标帧解析成功率用模拟从站发 1000 帧看解析出多少、异常恢复时间拔掉串口再插上库能否自动重连、内存增长连续跑 24 小时看缓冲区有没有泄漏。这些比看代码覆盖率实在。最后说一个我自己的教训早期我图省事把 BCC 校验写成「可选」结果现场一批表计因为线路干扰返回错误帧库直接抛异常导致整个采集线程挂掉。后来改成「校验失败记录日志并跳过该帧」系统才稳下来。协议库这种东西容错比功能重要。希望帮到你。本文还有配套的精品资源点击获取