简介在工业物联网与工厂信息化改造中设备数据采集与集成是核心环节。地磅仪表通过串口通信输出重量数据车牌识别相机提供结构化车辆信息而海康威视摄像头则借助ISAPI协议完成现场抓拍存证。如何将这些异构设备统一接入业务系统并实现稳定称重、自动识别、防作弊校验是物流园、搅拌站等场景的共性需求。本文基于Java与Spring Boot详细讲解了一套称重过磅系统的架构设计、串口解析、重量稳定判断、设备联调及异常排查方法覆盖从硬件接入到部署交付的全流程为工业物联网项目的快速落地提供工程参考。 干过工厂、物流园、废品回收站的朋友应该都有体会称重过磅是每天绕不开的环节。以前是人工读数、手写磅单效率低不说高峰期门口排长队事后对账也容易扯皮。这套基于Java的称重过磅系统设计源码核心就是把地磅仪表的数据采集、车牌识别、相机抓拍这三件事串起来摄像头这块集成了海康威视和芊熠两个品牌整条链路跑通之后车辆上磅、自动识别车牌、稳定称重、抓拍存证、生成过磅记录一气呵成。这篇就把我在实际搭建和联调过程中的完整思路、关键代码、踩坑经验都写出来给准备做同类项目的朋友做个参考。这套东西适合谁看呢一类是工厂、搅拌站、物流园内部做信息化改造的技术人员另一类是接工业物联网项目的外包团队。不管哪类只要手头有地磅、有车牌识别相机、有海康摄像头想把这几个设备串成一套自动过磅系统那这篇文章对你就有直接价值。1. 称重过磅系统的整体设计与架构思路1.1 这套系统到底解决了什么问题先说场景。一个标准的汽车衡过磅点配置通常是一台地磅带称重仪表、一个车牌识别相机、一个或者两个监控抓拍相机。传统模式下车辆上磅之后司磅员看仪表读数、手写车牌号、填毛重皮重、打印磅单一天上百辆车下来不仅累还容易出错。更麻烦的是对账问题。月底一翻台账发现某个车皮的重量和发货单对不上查起来基本靠回忆没有任何现场证据。所以这套系统的第一个核心目标就是把整个称重过程数字化留痕车牌号、重量数据、现场照片、过磅时间全部自动关联存到数据库随时可查可追溯。第二个目标是提效。车辆上磅后地感线圈或者视频检测触发车牌识别系统拿到车牌号后开始采集仪表重量等重量稳定后自动抓拍照片、保存记录整个过程不需要司机下车也不需要司磅员手动输入单车过磅时间能从原来的两三分钟压缩到几十秒。第三个目标是堵漏洞。人工过磅最大的问题是可以“做手脚”车上藏人、不完全上磅、换车牌、重复过磅。通过自动识别车牌、重量稳定判断、全景相机抓拍这几道措施大部分作弊手段基本都能被堵住。1.2 系统架构与模块划分整个系统从物理上分四层硬件设备层、通信接入层、业务逻辑层、展示对接层。硬件设备层包括地磅仪表、芊熠车牌识别相机、海康威视网络摄像头、工控机以及交换机、串口服务器等辅助设备。通信接入层是最关键的一层也是这类项目里坑最多的地方它负责把各种不同协议的设备统一接入到系统里。地磅仪表走串口RS232芊熠相机走HTTP接口回调海康摄像头走ISAPI协议或者SDK。业务逻辑层负责整理数据、控制流程、防作弊校验、生成记录。这里用Spring Boot来实现模块划分很清晰称重服务模块、车牌识别模块、抓图服务模块、记录管理模块。展示对接层就是前端页面和对外接口。前端功能包括实时过磅界面、历史记录查询、报表统计、车辆档案管理对外接口主要是给ERP或者发货系统对接用的过磅完成后把净重数据推送出去。选Java和Spring Boot来做这套系统说实话不是因为Java在工业领域有多先进而是它足够稳、生态足够好。串口通信有现成的库HTTP调用随手就写数据库操作用MyBatis-Plus非常顺手部署也就是一个Jar包扔到工控机上。另外Java对国产设备的SDK支持也算友好海康官方就有Java的Demo省去很多自己折腾底层的时间。1.3 为什么选择“海康威视 芊熠”的组合方案很多朋友会问车牌识别和海康摄像头能不能二选一这个问题要拆开看。芊熠摄像头是嵌入式车牌识别一体机它内部内置了车牌识别算法直接输出结构化数据车牌号、车牌颜色、置信度、抓拍图片地址你不需要在PC端再跑一套识别模型。这对于过磅场景来说太合适了识别速度快稳定可靠连补光灯都是标配。海康摄像头在这里主要负责全景监控和过磅过程的图像存证。也就是说车牌识别相机负责“看车牌”海康相机负责“看现场”——车是什么样、车上装了什么、有没有异常人员这些都要靠全景照片或者录像留底。所以这两个不是替代关系是典型的互补组合。也有一些方案用海康相机二次开发做车牌识别但那样需要在后端部署算法模型对工控机的性能要求高开发周期也长综合算下来不如一体机方案划算。2. 核心模块原理解析与设备接入细节2.1 地磅仪表的串口通信与重量数据采集称重仪表是本系统的数据源头所有业务都围绕着“重量”两个字展开。仪表通常提供RS232串口输出常见协议有两种连续发送模式和命令应答模式。连续发送模式是仪表主动往串口上持续发送重量数据命令应答是上位机先发指令、仪表再回应一帧数据。实际项目里我用过的大多数国产仪表都支持连续发送模式调试起来也最简单。打开串口就能不断收到数据每帧数据通常以ASCII码形式出现典型格式是STX 0 0 5 0 0 . 0 kg ETX也就是帧头加重量字符串加单位再加帧尾的结构。有些仪表会在重量前带正负号负数表示仪表处于负秤状态。解析的时候把ASCII字节按字符处理过滤掉帧头帧尾提取中间的数值部分即可。串口通信的Java实现我推荐用jSerialComm这个库比老牌的RXTX好用太多没有繁琐的系统路径配置Maven直接引依赖就行。核心代码如下import com.fazecast.jSerialComm.SerialPort; SerialPort comPort SerialPort.getCommPort(COM3); comPort.setBaudRate(9600); comPort.setNumDataBits(8); comPort.setNumStopBits(1); comPort.setParity(SerialPort.NO_PARITY); comPort.openPort(); comPort.setComPortTimeouts(SerialPort.TIMEOUT_READ_BLOCKING, 1000, 0); byte[] buffer new byte[64]; int bytesRead comPort.readBytes(buffer, buffer.length); if (bytesRead 0) { String raw new String(buffer, 0, bytesRead, StandardCharsets.US_ASCII); // 解析 raw提取重量值 }这里要注意几个细节。第一是波特率、数据位、停止位、校验位必须和仪表说明书一致常见的配置是9600、8、1、无校验。第二是编码问题很多仪表输出的是ASCII码但部分设备会在帧头帧尾里带十六进制控制字符直接以字符串处理时会看到乱码所以解析时最好一个字节一个字节地看按十六进制过滤控制字符。数据解析只是第一步真正重要的逻辑是重量稳定判断。仪表显示的重量值在车辆上磅后会有几秒的剧烈跳动如果系统在跳动的过程中就抓数记下来的重量很可能不准。常用的判断策略是“连续N次采样差值法”在同一状态下连续读取5次重量如果这5次的最大值和最小值之差小于设定阈值比如10公斤就认为重量已经稳定。这个阈值不能设得太小也不能太大。太小的话稍有风吹草动系统就永远等不到稳定太大又可能在大车压磅还没完全停稳时就误判稳定。根据我的经验对于60吨到120吨的汽车衡10到20公斤的阈值比较合适具体的可以根据现场仪表的跳动情况微调。2.2 芊熠车牌识别相机的结构化数据接入车牌识别这块芊熠的方案非常讨巧。相机本身集成了识别算法你只需要通过Web管理页面配置好参数它就会在识别到车辆后主动往你指定的HTTP接口推数据这就是常说的“HTTP回调”模式。首先在芊熠相机的Web配置页面上需要设置几项关键参数相机IP和端口、识别区域ROI、图像触发方式视频触发还是线圈触发、补光灯模式、上传服务器地址。上传服务器地址就是你的后端接口URL比如http://192.168.1.100:8080/api/device/qianyi/callback相机推送到这个地址的数据是一段JSON标准字段大致长这样{ plateNo: 苏A12345, plateColor: blue, confidence: 96, time: 2025-01-15 09:30:00, imageUrl: http://192.168.1.65/capture/20250115093000.jpg, smallImageUrl: http://192.168.1.65/capture/20250115093000_s.jpg }后端接收到这组数据后先校验车牌号格式再关联当前过磅流程。这里有一个业务逻辑要注意车牌照识别次数不是一次就完车辆上磅后芊熠相机会连续触发多次识别推送多条重复数据。后端需要做去重处理最简单的做法是同一车牌号在短时间窗口内比如5秒只处理第一条后续到达的直接丢弃或者跟踪当前流程状态只接收“等待上磅”状态下的首个识别结果。还有一点芊熠相机的plateColor字段识别的是车牌颜色常见值是 blue、yellow、green、white、black。新能源车牌是渐变绿色燃油车多半是蓝色或者黄色。这个小字段在后续做车辆类型辅助判断时很有用比如某些区域的运输车辆要求必须是新能源车这里就可以做个校验拦截。2.3 海康威视摄像头抓图与ISAPI协议集成海康摄像头的接入方式有两种主流方案官方SDKHCNetSDK和ISAPI协议。SDK功能最全支持实时预览、录像回放、对讲、报警订阅等但它有两个问题一是依赖DLL文件只能在Windows环境的JDK下通过JNA调用跨平台部署比较头疼二是SDK初始化流程繁琐DLL版本不匹配就容易抛异常。如果项目部署在Linux服务器上或者你只需要抓图和简单的录像查询功能我强烈建议直接用ISAPI协议。ISAPI是海康的HTTP风格接口本质就是RESTful API任何语言都能调用不需要额外的SDK依赖。ISAPI抓图的核心请求是这样的GET /ISAPI/Streaming/channels/101/picture Host: 192.168.1.64 Authorization: Basic base64(用户名:密码)通道号101表示第一路通道的主码流。如果你想要子码流的低分辨率图片可以换成102。抓图接口返回的是JPEG二进制数据可以直接写入本地文件。Java实现代码也不复杂import java.net.HttpURLConnection; import java.net.URL; import java.util.Base64; import java.io.InputStream; import java.io.FileOutputStream; String cameraIp 192.168.1.64; String username admin; String password your_password; String urlStr http:// cameraIp /ISAPI/Streaming/channels/101/picture; URL url new URL(urlStr); HttpURLConnection conn (HttpURLConnection) url.openConnection(); conn.setRequestMethod(GET); conn.setConnectTimeout(3000); conn.setReadTimeout(5000); String auth username : password; String encoded Base64.getEncoder().encodeToString(auth.getBytes()); conn.setRequestProperty(Authorization, Basic encoded); try (InputStream in conn.getInputStream(); FileOutputStream out new FileOutputStream(capture.jpg)) { byte[] buf new byte[4096]; int len; while ((len in.read(buf)) ! -1) { out.write(buf, 0, len); } }这段代码里的超时时间非常重要。海康相机在高分辨率下抓图如果网络有点波动耗时会从几百毫秒飙升到几秒没有超时控制的话称重线程会被拖死。另外抓图操作不能放在请求处理的主线程里同步执行最好用线程池异步抓图先把称重记录落库图片随后慢慢补。这一点在车辆连续过磅、业务繁忙的时候特别关键。3. 实操过程从零搭建一套可运行的过磅系统3.1 环境准备与工程结构规划先说软件环境。JDK 1.8或者11都行我建议用JDK 8因为部分国产设备的SDK对JDK 9以上的模块化机制支持不太友好。构建工具用Maven框架用Spring Boot 2.7.x数据库用MySQL 5.7。前端这块如果追求快速交付直接用Thymeleaf模板加Bootstrap界面就够了如果后续要做复杂的数据大屏再单独搭Vue工程也不冲突。硬件环境方面调试阶段最基础的配置是一台工控机普通Windows电脑也行但最好带串口、一台支持串口输出的称重仪表、一台芊熠车牌相机、一台海康网络摄像头、一个交换机。这些设备全部通过网络连接到同一个局域网仪表通过串口线接到工控机上。工程结构可以按模块分包我的习惯是这样的com.example.weigh ├── controller // 页面请求接口、设备回调接口 ├── service // 业务逻辑层 │ ├── WeighService.java │ ├── PlateService.java │ └── CaptureService.java ├── device // 设备接入层 │ ├── scale // 称重仪表串口通信 │ ├── qianyi // 芊熠相机接入 │ └── hikvision // 海康相机接入 ├── entity // 数据库实体 ├── mapper // MyBatis-Plus Mapper ├── config // 配置类串口、线程池、存储路径 └── common // 工具类与常量定义device 分包的好处是以后如果换了一台不同协议的仪表或者换了一个品牌的相机只需要在这一层替换实现类上层的业务代码完全不用动。设计模式里这叫策略模式在设备接入项目里非常实用。3.2 称重数据采集与稳定判断的代码实现串口数据采集这块我建议写成一个独立的服务启动时自动打开串口然后在一个循环线程里持续读取。读取到的数据经过解析、稳定判断后把最新重量放到一个内存变量里业务层通过 getWeight() 方法随时获取。这样仪表的数据读取和业务处理完全解耦互不阻塞。稳定判断的代码逻辑概括如下public class WeightStabilizer { private static final int SAMPLE_COUNT 5; private static final int STABLE_THRESHOLD_KG 15; private final LinkedListInteger samples new LinkedList(); public boolean pushAndCheck(int weightKg) { samples.addLast(weightKg); if (samples.size() SAMPLE_COUNT) { samples.removeFirst(); } if (samples.size() SAMPLE_COUNT) { return false; } int max samples.stream().max(Integer::compareTo).get(); // 最大值 int min samples.stream().min(Integer::compareTo).get(); // 最小值 return (max - min) STABLE_THRESHOLD_KG; } }这里每次收到仪表数据就往队列里塞一个重量值队列满5个之后计算最大值和最小值的差值。差值在15公斤以内就认为稳定同时把最后一次读取到的重量作为稳定重量返回。实际操作中有一个容易被忽略的细节仪表在显示稳定后发送的数据里会有一个专门的稳定标志位。有些仪表是在数据帧前面加一个“”或者“S”字符有些是用一个单独的十六进制位表示。如果你的仪表支持这个标志位我建议把“标志位为稳定”和“连续采样差值小”这两个条件同时满足才判定为稳定双保险效果最好。3.3 视频抓拍与车牌识别的整体联动把抓图和车牌识别串到同一个流程里整个闭环才算完整。我这里贴一段核心业务Service代码展示过磅流程的处理思路Service public class WeighService { public void handleCarArrive(CarArriveEvent event) { String plateNo event.getPlateNo(); // 1. 判断本车是否在“等待上磅”状态 WeighRecord record weighRecordMapper.findLastIncomplete(plateNo); if (record null) { record createNewRecord(plateNo); // 新过磅流程毛重环节 } // 2. 开始采集稳定重量 Integer stableWeight weightCollector.waitStableWeight(30, TimeUnit.SECONDS); if (stableWeight null) { record.setStatus(WEIGHT_TIMEOUT); // 记录超时状态 return; } // 3. 抓拍海康全景照片 captureService.captureAsync(record.getId()); // 4. 根据流程状态写入毛重或皮重 if (record.getWeighType() GROSS) { record.setGrossWeight(stableWeight); } else if (record.getWeighType() TARE) { record.setTareWeight(stableWeight); record.setNetWeight(record.getGrossWeight() - record.getTareWeight()); } weighRecordMapper.updateById(record); } }这里面的关键点是waitStableWeight方法。它需要在一段时间内不断从WeightStabilizer里获取状态同时要处理超时、称重过程中车辆中途离开等异常情况。比如车辆在磅上停了半分钟又开走了重量一直是0这时候系统要能判断出“车辆已离磅”取消当前流程否则下一个车来的时候流程状态就乱了。判断方法很简单连续读取到的重量持续为0或者远小于空车重量就认为车辆已经离磅。3.4 过磅记录与防作弊校验设计数据库表的设计是这类业务系统的地基。核心的过磅记录表我会保留以下关键字段CREATE TABLE weigh_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, plate_no VARCHAR(20) NOT NULL, weigh_type TINYINT NOT NULL COMMENT 1毛重 2皮重, gross_weight DECIMAL(10,2) DEFAULT 0, tare_weight DECIMAL(10,2) DEFAULT 0, net_weight DECIMAL(10,2) DEFAULT 0, image_path VARCHAR(255) COMMENT 海康全景照片路径, plate_image_path VARCHAR(255) COMMENT 芊熠车牌照片路径, confidence INT DEFAULT 0 COMMENT 车牌识别置信度, weigh_time DATETIME NOT NULL, operator VARCHAR(50) DEFAULT system, status TINYINT DEFAULT 0 COMMENT 0进行中 1完成 2异常, INDEX idx_plate_time (plate_no, weigh_time) );防作弊校验是这个系统里比较重要的一层。几个我实际用到的校验规则第一最少称重间隔。同一车牌两次过磅时间的间隔不能小于30秒防止车辆在磅上反复碾压制造虚假重量。第二重量范围校验。每辆车建立档案时登记车辆自重范围实时称得的皮重如果和档案中的自重偏差超过20%系统发出提示。第三异常重量波动检测。车辆上磅后如果重量在短时间内出现剧烈波动比如超过车辆自重的10%则认为是有人在磅上跳动或者故意压磅系统自动标记该记录为人工复核。这些校验规则的实现其实不复杂核心是状态机的正确流转。我遇到过不少项目业务逻辑看着都实现了就是状态管理一塌糊涂车辆重来过磅时数据就串了。设计的时候一定要把“等待上磅 - 毛重完成 - 等待皮重 - 皮重完成 - 净重计算完成”这个状态流转理清楚每一步写清楚允许从哪个状态迁移到哪个状态。4. 设备联调中的典型问题与排查经验4.1 串口通信不稳定的排查与解决串口这种老技术虽然简单但现场问题最多。我遇到的第一个典型问题是程序启动后读不到任何数据但用串口调试助手能正常看到仪表输出。这个问题的根源一般是串口被占用。Windows下工控机如果装了称重仪表的厂商管理软件那个软件启动时会独占串口你的Java程序自然拿不到数据。排查方法很直接关掉所有可能占用串口的软件再启动程序如果还是不行就用jSerialComm提供的方法列出所有可用串口确认程序打开的是不是正确的COM口号。第二个常见问题是数据能收到但解析出来的重量值不对频繁出现乱码或者漏帧。这时候先用串口助手看一眼原始数据如果发现帧与帧之间混入了奇怪的十六进制字符多半是仪表配置的校验位或者数据位与程序不一致重新核对仪表的串口参数设置就行。第三个问题是持续运行一段时间后串口“假死”程序还在运行但再也收不到数据。这通常是没有正确处理串口超时异常导致读取线程卡死或者流关闭。解决办法是在异常捕获后重新打开串口并对读取循环加一个异常自愈机制连续读取失败超过10次就主动关闭串口并重新初始化。4.2 海康相机ISAPI抓图失败的全方位排查ISAPI接口虽然简单但出了问题往往不好查因为海康返回的错误信息比较有限。根据我的经验最常见的原因就三种。第一种是接口路径错误。很多朋友写/ISAPI/Streaming/channels/101/picture时把channels误写成channel或者把图片接口误记成/ISAPI/Streaming/channels/101/httpPreview。这两种写法海康都不会返回正常图片建议先用浏览器的开发者模式或者Postman直接调试接口确认URL可通再集成到代码里。第二种是认证问题。部分版本的摄像头固件要求先发送一个未认证请求接收401响应后再携带Authorization头重试这就是标准的HTTP Basic认证流程。如果你的代码里没有处理这种“先401后重试”的逻辑抓图就会失败。另外还要注意海康默认的管理员账号admin可能设置了复杂的密码策略如果密码里有特殊符号拼接Basic认证串时要确保Base64编码的是原始的“用户名:密码”格式。第三种是网络原因。工控机和摄像头之间的交换机如果启用了端口隔离或者VLAN隔离ISAPI请求会超时。还有特别要注意的摄像头的IP地址和工控机IP地址最好设置为同一个网段跨网段访问虽然能通但抓图延迟会明显增加影响车辆连续过磅时的响应速度。4.3 车牌识别不准或漏识别的原因分析芊熠相机在出厂默认配置下识别率通常可以达到95%以上但现场环境复杂出现漏识别也不奇怪。我排除问题时习惯按下面的顺序排查首先要检查相机安装位置。车牌识别相机的安装高度一般在1.2米到1.5米之间和地磅秤台的距离保持3米到6米。安装角度不能太大相机轴线与车辆行驶方向的夹角最好在15度以内否则车牌倾斜角度过大会导致识别失败。这个光照条件也是大问题强逆光环境下车牌反光会让识别算法直接罢工需要确认补光灯是否正常开启识别区域是否避开了大面积高反光区域。其次是检查识别区域ROI的配置。很多项目为了追求近距离识别把ROI画得特别大结果路边的树影、地磅的栏杆都被圈了进去这些干扰物会频繁触发识别算法但输出结果置信度很低。正确的做法是把ROI收敛到车牌必然经过的狭窄区域既能提高识别率也能减少无效识别次数。再一个因素是触发方式。视频触发虽然部署简单但在车流量大的情况下容易出现前后车连续触发导致识别结果张冠李戴。如果现场有条件优先使用地感线圈触发线圈信号能准确告诉相机“有一辆车进入识别区域了”配合上低位视频触发识别的准确性会高很多。4.4 多辆车连续过磅时的并发处理经验日常运营中过磅站经常出现几辆车连续排队的情况。如果系统设计成“单线程顺序处理”一旦前一辆车的抓图或者识别出现延迟后面的车全得等着。解决思路是让每一个过磅流程内部落库操作保持串行但图片抓取和车牌识别异步化。我在系统里用一个ExecutorService线程池来处理海康抓图任务线程池大小设置为4抓图任务提交后立即返回只有落库和状态更新操作在业务流程里同步执行。这样即使某一张图抓取失败也不会阻塞后续车辆的称重流程。还要注意数据库层面要设置好唯一约束。比如weigh_record表里对于“进行中”的记录同一车牌只能存在一条。这一步可以在插入时用数据库唯一索引兜底也可以靠业务逻辑加锁控制。我建议两个都做业务锁保证常规场景下的正确性数据库唯一索引兜底处理极端并发下的数据重复问题。这两个措施缺一个都可能撞出意想不到的脏数据。5. 从代码到交付部署经验与二次开发扩展5.1 现场部署的最佳实践这套系统在开发环境跑通了离真正上线还有一段不短的距离。工业现场的部署环境和开发环境差异很大我这里分享几个踩过坑才总结出来的经验。第一硬件端的电源和接地一定要检查。地磅称重仪表对电源干扰特别敏感偶尔会收到波动很大的重量数据这通常不是程序问题而是现场电源不稳定或者地线没接好。有条件的话给仪表、工控机、交换机各配一个稳压电源能省掉大量排查时间。第二网络拓扑尽量简单。我见过一些工厂的信息化改造把过磅设备接入了办公局域网结果办公网络广播风暴一起摄像头的图像延迟直接飙到十几秒。稳妥的做法是单独拉一台交换机把称重仪表、相机、工控机组成一个独立的物理子网只有工控机通过双网卡或者路由器和上层网络连接。第三做好开机自启动和异常自愈。工控机在工业现场经常断电重启Spring Boot应用做成Windows服务或者systemd服务确保断电恢复后系统能自动起来。摄像头和仪表也要盯住程序里要加心跳检测比如定时去Ping海康相机的IP如果连续几次不通就主动报警并尝试重启对应的设备连接。5.2 常见问题速查表问题现象可能原因排查思路串口收不到仪表数据串口号错误、串口被占用、线序不对先用串口助手验证确认COM口号关闭占用软件重量数据解析出乱码波特率/校验位配置不一致、编码问题核对仪表串口参数按十六进制查看原始数据重量一直不稳定车辆未完全上磅、仪表跳动异常检查稳定阈值检查秤台和称重传感器状态海康抓图超时网络不通、ISAPI路径错误、认证失败使用Postman直接调试接口检查网络连通性芊熠推送重复数据视频触发连续识别在业务层增加时间窗口去重车牌识别率低ROI设置过大、角度过大、逆光调整相机参数检查补光灯适当缩小识别区域车辆过磅后状态卡住流程状态机异常、离磅检测失败增加离磅判断逻辑增加超时手动复位机制5.3 后续可扩展的方向这套系统跑通之后可以延伸的方向其实挺多的。如果需要和发货系统打通可以开发一个接口发货单生成后自动锁定对应的车辆车牌号车辆过磅时校验发货单号数据直接回传ERP整个物流链条的数据就闭环了。如果现场有LED显示屏通过串口或者网口驱动大屏实时显示当前重量和车牌号司机不用下车看仪表体验会好很多。再往后想做一些数据分析比如按日期、供应商、物料类型统计过磅数据生成日报月报这些在现有表结构基础上都很容易扩展。做这种工业软件项目我的一个很深的体会是代码本身往往不是最难的部分真正考验人的是和现场各种不听话的设备打交道。串口线虚接、相机镜头脏了、仪表参数被人改了、交换机供电不稳这些才是项目中真正的拦路虎。所以无论你是自己造轮子还是二次开发这套源码都建议先花时间把硬件链路彻底摸透再动手写业务代码。设备都通了后面的逻辑写起来其实非常顺畅。本文还有配套的精品资源点击获取 基于Java的称重过磅系统设计：从串口通信到设备联调实战
简介在工业物联网与工厂信息化改造中设备数据采集与集成是核心环节。地磅仪表通过串口通信输出重量数据车牌识别相机提供结构化车辆信息而海康威视摄像头则借助ISAPI协议完成现场抓拍存证。如何将这些异构设备统一接入业务系统并实现稳定称重、自动识别、防作弊校验是物流园、搅拌站等场景的共性需求。本文基于Java与Spring Boot详细讲解了一套称重过磅系统的架构设计、串口解析、重量稳定判断、设备联调及异常排查方法覆盖从硬件接入到部署交付的全流程为工业物联网项目的快速落地提供工程参考。 干过工厂、物流园、废品回收站的朋友应该都有体会称重过磅是每天绕不开的环节。以前是人工读数、手写磅单效率低不说高峰期门口排长队事后对账也容易扯皮。这套基于Java的称重过磅系统设计源码核心就是把地磅仪表的数据采集、车牌识别、相机抓拍这三件事串起来摄像头这块集成了海康威视和芊熠两个品牌整条链路跑通之后车辆上磅、自动识别车牌、稳定称重、抓拍存证、生成过磅记录一气呵成。这篇就把我在实际搭建和联调过程中的完整思路、关键代码、踩坑经验都写出来给准备做同类项目的朋友做个参考。这套东西适合谁看呢一类是工厂、搅拌站、物流园内部做信息化改造的技术人员另一类是接工业物联网项目的外包团队。不管哪类只要手头有地磅、有车牌识别相机、有海康摄像头想把这几个设备串成一套自动过磅系统那这篇文章对你就有直接价值。1. 称重过磅系统的整体设计与架构思路1.1 这套系统到底解决了什么问题先说场景。一个标准的汽车衡过磅点配置通常是一台地磅带称重仪表、一个车牌识别相机、一个或者两个监控抓拍相机。传统模式下车辆上磅之后司磅员看仪表读数、手写车牌号、填毛重皮重、打印磅单一天上百辆车下来不仅累还容易出错。更麻烦的是对账问题。月底一翻台账发现某个车皮的重量和发货单对不上查起来基本靠回忆没有任何现场证据。所以这套系统的第一个核心目标就是把整个称重过程数字化留痕车牌号、重量数据、现场照片、过磅时间全部自动关联存到数据库随时可查可追溯。第二个目标是提效。车辆上磅后地感线圈或者视频检测触发车牌识别系统拿到车牌号后开始采集仪表重量等重量稳定后自动抓拍照片、保存记录整个过程不需要司机下车也不需要司磅员手动输入单车过磅时间能从原来的两三分钟压缩到几十秒。第三个目标是堵漏洞。人工过磅最大的问题是可以“做手脚”车上藏人、不完全上磅、换车牌、重复过磅。通过自动识别车牌、重量稳定判断、全景相机抓拍这几道措施大部分作弊手段基本都能被堵住。1.2 系统架构与模块划分整个系统从物理上分四层硬件设备层、通信接入层、业务逻辑层、展示对接层。硬件设备层包括地磅仪表、芊熠车牌识别相机、海康威视网络摄像头、工控机以及交换机、串口服务器等辅助设备。通信接入层是最关键的一层也是这类项目里坑最多的地方它负责把各种不同协议的设备统一接入到系统里。地磅仪表走串口RS232芊熠相机走HTTP接口回调海康摄像头走ISAPI协议或者SDK。业务逻辑层负责整理数据、控制流程、防作弊校验、生成记录。这里用Spring Boot来实现模块划分很清晰称重服务模块、车牌识别模块、抓图服务模块、记录管理模块。展示对接层就是前端页面和对外接口。前端功能包括实时过磅界面、历史记录查询、报表统计、车辆档案管理对外接口主要是给ERP或者发货系统对接用的过磅完成后把净重数据推送出去。选Java和Spring Boot来做这套系统说实话不是因为Java在工业领域有多先进而是它足够稳、生态足够好。串口通信有现成的库HTTP调用随手就写数据库操作用MyBatis-Plus非常顺手部署也就是一个Jar包扔到工控机上。另外Java对国产设备的SDK支持也算友好海康官方就有Java的Demo省去很多自己折腾底层的时间。1.3 为什么选择“海康威视 芊熠”的组合方案很多朋友会问车牌识别和海康摄像头能不能二选一这个问题要拆开看。芊熠摄像头是嵌入式车牌识别一体机它内部内置了车牌识别算法直接输出结构化数据车牌号、车牌颜色、置信度、抓拍图片地址你不需要在PC端再跑一套识别模型。这对于过磅场景来说太合适了识别速度快稳定可靠连补光灯都是标配。海康摄像头在这里主要负责全景监控和过磅过程的图像存证。也就是说车牌识别相机负责“看车牌”海康相机负责“看现场”——车是什么样、车上装了什么、有没有异常人员这些都要靠全景照片或者录像留底。所以这两个不是替代关系是典型的互补组合。也有一些方案用海康相机二次开发做车牌识别但那样需要在后端部署算法模型对工控机的性能要求高开发周期也长综合算下来不如一体机方案划算。2. 核心模块原理解析与设备接入细节2.1 地磅仪表的串口通信与重量数据采集称重仪表是本系统的数据源头所有业务都围绕着“重量”两个字展开。仪表通常提供RS232串口输出常见协议有两种连续发送模式和命令应答模式。连续发送模式是仪表主动往串口上持续发送重量数据命令应答是上位机先发指令、仪表再回应一帧数据。实际项目里我用过的大多数国产仪表都支持连续发送模式调试起来也最简单。打开串口就能不断收到数据每帧数据通常以ASCII码形式出现典型格式是STX 0 0 5 0 0 . 0 kg ETX也就是帧头加重量字符串加单位再加帧尾的结构。有些仪表会在重量前带正负号负数表示仪表处于负秤状态。解析的时候把ASCII字节按字符处理过滤掉帧头帧尾提取中间的数值部分即可。串口通信的Java实现我推荐用jSerialComm这个库比老牌的RXTX好用太多没有繁琐的系统路径配置Maven直接引依赖就行。核心代码如下import com.fazecast.jSerialComm.SerialPort; SerialPort comPort SerialPort.getCommPort(COM3); comPort.setBaudRate(9600); comPort.setNumDataBits(8); comPort.setNumStopBits(1); comPort.setParity(SerialPort.NO_PARITY); comPort.openPort(); comPort.setComPortTimeouts(SerialPort.TIMEOUT_READ_BLOCKING, 1000, 0); byte[] buffer new byte[64]; int bytesRead comPort.readBytes(buffer, buffer.length); if (bytesRead 0) { String raw new String(buffer, 0, bytesRead, StandardCharsets.US_ASCII); // 解析 raw提取重量值 }这里要注意几个细节。第一是波特率、数据位、停止位、校验位必须和仪表说明书一致常见的配置是9600、8、1、无校验。第二是编码问题很多仪表输出的是ASCII码但部分设备会在帧头帧尾里带十六进制控制字符直接以字符串处理时会看到乱码所以解析时最好一个字节一个字节地看按十六进制过滤控制字符。数据解析只是第一步真正重要的逻辑是重量稳定判断。仪表显示的重量值在车辆上磅后会有几秒的剧烈跳动如果系统在跳动的过程中就抓数记下来的重量很可能不准。常用的判断策略是“连续N次采样差值法”在同一状态下连续读取5次重量如果这5次的最大值和最小值之差小于设定阈值比如10公斤就认为重量已经稳定。这个阈值不能设得太小也不能太大。太小的话稍有风吹草动系统就永远等不到稳定太大又可能在大车压磅还没完全停稳时就误判稳定。根据我的经验对于60吨到120吨的汽车衡10到20公斤的阈值比较合适具体的可以根据现场仪表的跳动情况微调。2.2 芊熠车牌识别相机的结构化数据接入车牌识别这块芊熠的方案非常讨巧。相机本身集成了识别算法你只需要通过Web管理页面配置好参数它就会在识别到车辆后主动往你指定的HTTP接口推数据这就是常说的“HTTP回调”模式。首先在芊熠相机的Web配置页面上需要设置几项关键参数相机IP和端口、识别区域ROI、图像触发方式视频触发还是线圈触发、补光灯模式、上传服务器地址。上传服务器地址就是你的后端接口URL比如http://192.168.1.100:8080/api/device/qianyi/callback相机推送到这个地址的数据是一段JSON标准字段大致长这样{ plateNo: 苏A12345, plateColor: blue, confidence: 96, time: 2025-01-15 09:30:00, imageUrl: http://192.168.1.65/capture/20250115093000.jpg, smallImageUrl: http://192.168.1.65/capture/20250115093000_s.jpg }后端接收到这组数据后先校验车牌号格式再关联当前过磅流程。这里有一个业务逻辑要注意车牌照识别次数不是一次就完车辆上磅后芊熠相机会连续触发多次识别推送多条重复数据。后端需要做去重处理最简单的做法是同一车牌号在短时间窗口内比如5秒只处理第一条后续到达的直接丢弃或者跟踪当前流程状态只接收“等待上磅”状态下的首个识别结果。还有一点芊熠相机的plateColor字段识别的是车牌颜色常见值是 blue、yellow、green、white、black。新能源车牌是渐变绿色燃油车多半是蓝色或者黄色。这个小字段在后续做车辆类型辅助判断时很有用比如某些区域的运输车辆要求必须是新能源车这里就可以做个校验拦截。2.3 海康威视摄像头抓图与ISAPI协议集成海康摄像头的接入方式有两种主流方案官方SDKHCNetSDK和ISAPI协议。SDK功能最全支持实时预览、录像回放、对讲、报警订阅等但它有两个问题一是依赖DLL文件只能在Windows环境的JDK下通过JNA调用跨平台部署比较头疼二是SDK初始化流程繁琐DLL版本不匹配就容易抛异常。如果项目部署在Linux服务器上或者你只需要抓图和简单的录像查询功能我强烈建议直接用ISAPI协议。ISAPI是海康的HTTP风格接口本质就是RESTful API任何语言都能调用不需要额外的SDK依赖。ISAPI抓图的核心请求是这样的GET /ISAPI/Streaming/channels/101/picture Host: 192.168.1.64 Authorization: Basic base64(用户名:密码)通道号101表示第一路通道的主码流。如果你想要子码流的低分辨率图片可以换成102。抓图接口返回的是JPEG二进制数据可以直接写入本地文件。Java实现代码也不复杂import java.net.HttpURLConnection; import java.net.URL; import java.util.Base64; import java.io.InputStream; import java.io.FileOutputStream; String cameraIp 192.168.1.64; String username admin; String password your_password; String urlStr http:// cameraIp /ISAPI/Streaming/channels/101/picture; URL url new URL(urlStr); HttpURLConnection conn (HttpURLConnection) url.openConnection(); conn.setRequestMethod(GET); conn.setConnectTimeout(3000); conn.setReadTimeout(5000); String auth username : password; String encoded Base64.getEncoder().encodeToString(auth.getBytes()); conn.setRequestProperty(Authorization, Basic encoded); try (InputStream in conn.getInputStream(); FileOutputStream out new FileOutputStream(capture.jpg)) { byte[] buf new byte[4096]; int len; while ((len in.read(buf)) ! -1) { out.write(buf, 0, len); } }这段代码里的超时时间非常重要。海康相机在高分辨率下抓图如果网络有点波动耗时会从几百毫秒飙升到几秒没有超时控制的话称重线程会被拖死。另外抓图操作不能放在请求处理的主线程里同步执行最好用线程池异步抓图先把称重记录落库图片随后慢慢补。这一点在车辆连续过磅、业务繁忙的时候特别关键。3. 实操过程从零搭建一套可运行的过磅系统3.1 环境准备与工程结构规划先说软件环境。JDK 1.8或者11都行我建议用JDK 8因为部分国产设备的SDK对JDK 9以上的模块化机制支持不太友好。构建工具用Maven框架用Spring Boot 2.7.x数据库用MySQL 5.7。前端这块如果追求快速交付直接用Thymeleaf模板加Bootstrap界面就够了如果后续要做复杂的数据大屏再单独搭Vue工程也不冲突。硬件环境方面调试阶段最基础的配置是一台工控机普通Windows电脑也行但最好带串口、一台支持串口输出的称重仪表、一台芊熠车牌相机、一台海康网络摄像头、一个交换机。这些设备全部通过网络连接到同一个局域网仪表通过串口线接到工控机上。工程结构可以按模块分包我的习惯是这样的com.example.weigh ├── controller // 页面请求接口、设备回调接口 ├── service // 业务逻辑层 │ ├── WeighService.java │ ├── PlateService.java │ └── CaptureService.java ├── device // 设备接入层 │ ├── scale // 称重仪表串口通信 │ ├── qianyi // 芊熠相机接入 │ └── hikvision // 海康相机接入 ├── entity // 数据库实体 ├── mapper // MyBatis-Plus Mapper ├── config // 配置类串口、线程池、存储路径 └── common // 工具类与常量定义device 分包的好处是以后如果换了一台不同协议的仪表或者换了一个品牌的相机只需要在这一层替换实现类上层的业务代码完全不用动。设计模式里这叫策略模式在设备接入项目里非常实用。3.2 称重数据采集与稳定判断的代码实现串口数据采集这块我建议写成一个独立的服务启动时自动打开串口然后在一个循环线程里持续读取。读取到的数据经过解析、稳定判断后把最新重量放到一个内存变量里业务层通过 getWeight() 方法随时获取。这样仪表的数据读取和业务处理完全解耦互不阻塞。稳定判断的代码逻辑概括如下public class WeightStabilizer { private static final int SAMPLE_COUNT 5; private static final int STABLE_THRESHOLD_KG 15; private final LinkedListInteger samples new LinkedList(); public boolean pushAndCheck(int weightKg) { samples.addLast(weightKg); if (samples.size() SAMPLE_COUNT) { samples.removeFirst(); } if (samples.size() SAMPLE_COUNT) { return false; } int max samples.stream().max(Integer::compareTo).get(); // 最大值 int min samples.stream().min(Integer::compareTo).get(); // 最小值 return (max - min) STABLE_THRESHOLD_KG; } }这里每次收到仪表数据就往队列里塞一个重量值队列满5个之后计算最大值和最小值的差值。差值在15公斤以内就认为稳定同时把最后一次读取到的重量作为稳定重量返回。实际操作中有一个容易被忽略的细节仪表在显示稳定后发送的数据里会有一个专门的稳定标志位。有些仪表是在数据帧前面加一个“”或者“S”字符有些是用一个单独的十六进制位表示。如果你的仪表支持这个标志位我建议把“标志位为稳定”和“连续采样差值小”这两个条件同时满足才判定为稳定双保险效果最好。3.3 视频抓拍与车牌识别的整体联动把抓图和车牌识别串到同一个流程里整个闭环才算完整。我这里贴一段核心业务Service代码展示过磅流程的处理思路Service public class WeighService { public void handleCarArrive(CarArriveEvent event) { String plateNo event.getPlateNo(); // 1. 判断本车是否在“等待上磅”状态 WeighRecord record weighRecordMapper.findLastIncomplete(plateNo); if (record null) { record createNewRecord(plateNo); // 新过磅流程毛重环节 } // 2. 开始采集稳定重量 Integer stableWeight weightCollector.waitStableWeight(30, TimeUnit.SECONDS); if (stableWeight null) { record.setStatus(WEIGHT_TIMEOUT); // 记录超时状态 return; } // 3. 抓拍海康全景照片 captureService.captureAsync(record.getId()); // 4. 根据流程状态写入毛重或皮重 if (record.getWeighType() GROSS) { record.setGrossWeight(stableWeight); } else if (record.getWeighType() TARE) { record.setTareWeight(stableWeight); record.setNetWeight(record.getGrossWeight() - record.getTareWeight()); } weighRecordMapper.updateById(record); } }这里面的关键点是waitStableWeight方法。它需要在一段时间内不断从WeightStabilizer里获取状态同时要处理超时、称重过程中车辆中途离开等异常情况。比如车辆在磅上停了半分钟又开走了重量一直是0这时候系统要能判断出“车辆已离磅”取消当前流程否则下一个车来的时候流程状态就乱了。判断方法很简单连续读取到的重量持续为0或者远小于空车重量就认为车辆已经离磅。3.4 过磅记录与防作弊校验设计数据库表的设计是这类业务系统的地基。核心的过磅记录表我会保留以下关键字段CREATE TABLE weigh_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, plate_no VARCHAR(20) NOT NULL, weigh_type TINYINT NOT NULL COMMENT 1毛重 2皮重, gross_weight DECIMAL(10,2) DEFAULT 0, tare_weight DECIMAL(10,2) DEFAULT 0, net_weight DECIMAL(10,2) DEFAULT 0, image_path VARCHAR(255) COMMENT 海康全景照片路径, plate_image_path VARCHAR(255) COMMENT 芊熠车牌照片路径, confidence INT DEFAULT 0 COMMENT 车牌识别置信度, weigh_time DATETIME NOT NULL, operator VARCHAR(50) DEFAULT system, status TINYINT DEFAULT 0 COMMENT 0进行中 1完成 2异常, INDEX idx_plate_time (plate_no, weigh_time) );防作弊校验是这个系统里比较重要的一层。几个我实际用到的校验规则第一最少称重间隔。同一车牌两次过磅时间的间隔不能小于30秒防止车辆在磅上反复碾压制造虚假重量。第二重量范围校验。每辆车建立档案时登记车辆自重范围实时称得的皮重如果和档案中的自重偏差超过20%系统发出提示。第三异常重量波动检测。车辆上磅后如果重量在短时间内出现剧烈波动比如超过车辆自重的10%则认为是有人在磅上跳动或者故意压磅系统自动标记该记录为人工复核。这些校验规则的实现其实不复杂核心是状态机的正确流转。我遇到过不少项目业务逻辑看着都实现了就是状态管理一塌糊涂车辆重来过磅时数据就串了。设计的时候一定要把“等待上磅 - 毛重完成 - 等待皮重 - 皮重完成 - 净重计算完成”这个状态流转理清楚每一步写清楚允许从哪个状态迁移到哪个状态。4. 设备联调中的典型问题与排查经验4.1 串口通信不稳定的排查与解决串口这种老技术虽然简单但现场问题最多。我遇到的第一个典型问题是程序启动后读不到任何数据但用串口调试助手能正常看到仪表输出。这个问题的根源一般是串口被占用。Windows下工控机如果装了称重仪表的厂商管理软件那个软件启动时会独占串口你的Java程序自然拿不到数据。排查方法很直接关掉所有可能占用串口的软件再启动程序如果还是不行就用jSerialComm提供的方法列出所有可用串口确认程序打开的是不是正确的COM口号。第二个常见问题是数据能收到但解析出来的重量值不对频繁出现乱码或者漏帧。这时候先用串口助手看一眼原始数据如果发现帧与帧之间混入了奇怪的十六进制字符多半是仪表配置的校验位或者数据位与程序不一致重新核对仪表的串口参数设置就行。第三个问题是持续运行一段时间后串口“假死”程序还在运行但再也收不到数据。这通常是没有正确处理串口超时异常导致读取线程卡死或者流关闭。解决办法是在异常捕获后重新打开串口并对读取循环加一个异常自愈机制连续读取失败超过10次就主动关闭串口并重新初始化。4.2 海康相机ISAPI抓图失败的全方位排查ISAPI接口虽然简单但出了问题往往不好查因为海康返回的错误信息比较有限。根据我的经验最常见的原因就三种。第一种是接口路径错误。很多朋友写/ISAPI/Streaming/channels/101/picture时把channels误写成channel或者把图片接口误记成/ISAPI/Streaming/channels/101/httpPreview。这两种写法海康都不会返回正常图片建议先用浏览器的开发者模式或者Postman直接调试接口确认URL可通再集成到代码里。第二种是认证问题。部分版本的摄像头固件要求先发送一个未认证请求接收401响应后再携带Authorization头重试这就是标准的HTTP Basic认证流程。如果你的代码里没有处理这种“先401后重试”的逻辑抓图就会失败。另外还要注意海康默认的管理员账号admin可能设置了复杂的密码策略如果密码里有特殊符号拼接Basic认证串时要确保Base64编码的是原始的“用户名:密码”格式。第三种是网络原因。工控机和摄像头之间的交换机如果启用了端口隔离或者VLAN隔离ISAPI请求会超时。还有特别要注意的摄像头的IP地址和工控机IP地址最好设置为同一个网段跨网段访问虽然能通但抓图延迟会明显增加影响车辆连续过磅时的响应速度。4.3 车牌识别不准或漏识别的原因分析芊熠相机在出厂默认配置下识别率通常可以达到95%以上但现场环境复杂出现漏识别也不奇怪。我排除问题时习惯按下面的顺序排查首先要检查相机安装位置。车牌识别相机的安装高度一般在1.2米到1.5米之间和地磅秤台的距离保持3米到6米。安装角度不能太大相机轴线与车辆行驶方向的夹角最好在15度以内否则车牌倾斜角度过大会导致识别失败。这个光照条件也是大问题强逆光环境下车牌反光会让识别算法直接罢工需要确认补光灯是否正常开启识别区域是否避开了大面积高反光区域。其次是检查识别区域ROI的配置。很多项目为了追求近距离识别把ROI画得特别大结果路边的树影、地磅的栏杆都被圈了进去这些干扰物会频繁触发识别算法但输出结果置信度很低。正确的做法是把ROI收敛到车牌必然经过的狭窄区域既能提高识别率也能减少无效识别次数。再一个因素是触发方式。视频触发虽然部署简单但在车流量大的情况下容易出现前后车连续触发导致识别结果张冠李戴。如果现场有条件优先使用地感线圈触发线圈信号能准确告诉相机“有一辆车进入识别区域了”配合上低位视频触发识别的准确性会高很多。4.4 多辆车连续过磅时的并发处理经验日常运营中过磅站经常出现几辆车连续排队的情况。如果系统设计成“单线程顺序处理”一旦前一辆车的抓图或者识别出现延迟后面的车全得等着。解决思路是让每一个过磅流程内部落库操作保持串行但图片抓取和车牌识别异步化。我在系统里用一个ExecutorService线程池来处理海康抓图任务线程池大小设置为4抓图任务提交后立即返回只有落库和状态更新操作在业务流程里同步执行。这样即使某一张图抓取失败也不会阻塞后续车辆的称重流程。还要注意数据库层面要设置好唯一约束。比如weigh_record表里对于“进行中”的记录同一车牌只能存在一条。这一步可以在插入时用数据库唯一索引兜底也可以靠业务逻辑加锁控制。我建议两个都做业务锁保证常规场景下的正确性数据库唯一索引兜底处理极端并发下的数据重复问题。这两个措施缺一个都可能撞出意想不到的脏数据。5. 从代码到交付部署经验与二次开发扩展5.1 现场部署的最佳实践这套系统在开发环境跑通了离真正上线还有一段不短的距离。工业现场的部署环境和开发环境差异很大我这里分享几个踩过坑才总结出来的经验。第一硬件端的电源和接地一定要检查。地磅称重仪表对电源干扰特别敏感偶尔会收到波动很大的重量数据这通常不是程序问题而是现场电源不稳定或者地线没接好。有条件的话给仪表、工控机、交换机各配一个稳压电源能省掉大量排查时间。第二网络拓扑尽量简单。我见过一些工厂的信息化改造把过磅设备接入了办公局域网结果办公网络广播风暴一起摄像头的图像延迟直接飙到十几秒。稳妥的做法是单独拉一台交换机把称重仪表、相机、工控机组成一个独立的物理子网只有工控机通过双网卡或者路由器和上层网络连接。第三做好开机自启动和异常自愈。工控机在工业现场经常断电重启Spring Boot应用做成Windows服务或者systemd服务确保断电恢复后系统能自动起来。摄像头和仪表也要盯住程序里要加心跳检测比如定时去Ping海康相机的IP如果连续几次不通就主动报警并尝试重启对应的设备连接。5.2 常见问题速查表问题现象可能原因排查思路串口收不到仪表数据串口号错误、串口被占用、线序不对先用串口助手验证确认COM口号关闭占用软件重量数据解析出乱码波特率/校验位配置不一致、编码问题核对仪表串口参数按十六进制查看原始数据重量一直不稳定车辆未完全上磅、仪表跳动异常检查稳定阈值检查秤台和称重传感器状态海康抓图超时网络不通、ISAPI路径错误、认证失败使用Postman直接调试接口检查网络连通性芊熠推送重复数据视频触发连续识别在业务层增加时间窗口去重车牌识别率低ROI设置过大、角度过大、逆光调整相机参数检查补光灯适当缩小识别区域车辆过磅后状态卡住流程状态机异常、离磅检测失败增加离磅判断逻辑增加超时手动复位机制5.3 后续可扩展的方向这套系统跑通之后可以延伸的方向其实挺多的。如果需要和发货系统打通可以开发一个接口发货单生成后自动锁定对应的车辆车牌号车辆过磅时校验发货单号数据直接回传ERP整个物流链条的数据就闭环了。如果现场有LED显示屏通过串口或者网口驱动大屏实时显示当前重量和车牌号司机不用下车看仪表体验会好很多。再往后想做一些数据分析比如按日期、供应商、物料类型统计过磅数据生成日报月报这些在现有表结构基础上都很容易扩展。做这种工业软件项目我的一个很深的体会是代码本身往往不是最难的部分真正考验人的是和现场各种不听话的设备打交道。串口线虚接、相机镜头脏了、仪表参数被人改了、交换机供电不稳这些才是项目中真正的拦路虎。所以无论你是自己造轮子还是二次开发这套源码都建议先花时间把硬件链路彻底摸透再动手写业务代码。设备都通了后面的逻辑写起来其实非常顺畅。本文还有配套的精品资源点击获取