简介面向 Java 平台 openSCADA 与 OPC 相关开发者的完整依赖资源包集中解决开发环境缺少 jar 包、依赖散落难找的问题。压缩包共 480 个文件整体约 30.92MB其中包含 129 个 jar 依赖、339 个 class 编译产物以及 xml、properties、classpath 等工程配置文件既有可直接引入的第三方库也有编译后的核心类适合排查构建路径、运行环境配置或反编译参考。其中的项目元数据与配置信息能帮助导入 IDE 后快速对齐模块结构。目前已有 686 人学习/下载适用于具备一定 Java 基础、正在搭建 openSCADA 网关或 OPC 通讯模块的开发者。整个资源包围绕 openSCADA 开发链路整理解压后即可对照使用省去逐一下载依赖和手工梳理配置的重复劳动可显著提速工业数据采集与 SCADA 二次开发联调。1. 拿到 openSCADA 的 jar 包只是开始先搞清楚它凭什么能跑起来做 Java 版 openSCADA 的人多半都经历过同一个场景从同事或某次项目交接里拿到一整个“lib 目录”里面几十个 jar 码得整整齐齐可一执行启动脚本就报 ClassNotFoundException然后开始满世界找依赖。这套 jar 其实不是随便攒出来的——OPC 通信要 DCOM 运行时数据采集要协议驱动数据落地要 JDBC 驱动任缺一环整个链路都断。这篇文章我把“openSCADA 所需的 jar”按职责拆开讲告诉你哪几个是核心中的核心、缺了会出现什么症状再给一套能直接抄的启动与自检方法适用于刚接手这类老工程、准备从零搭一套可运行环境的从业者。2. 拆开 lib 目录三类 jar 各管什么为什么少一个都不行2.1 OPC 通信层openSCADA 和外部系统对话的咽喉老一代 Java SCADA 系统里OPC 通信层从来不是 JDK 自带的必须靠一堆专门处理 DCOM 和 OPC 协议的 jar 撑着。这一层通常包含三部分OPC DA 的通用接口封装、RMI/DCOM 桥接、以及平台相关的运行库。openSCADA 要订阅现场 DCS、PLC 或者第三方 OPC Server 的数据本质上走的就是这条链路——Java 进程通过桥接库调用 Windows 上的 OPC Server然后把实时值拉回自己的数据模型里。选型理由看起来简单实操里坑不少。常见的做法是用 jinterop 这类开源桥接库做 DCOM 穿透再配一层“da-core”之类的核心封装库。你要是只接 OPC UA 设备那 DCOM 桥接 jar 可以省可大多数老工厂现状还是 OPC DA 为主所以这套依赖基本是必选。判断一个 jar 是不是 OPC 相关的直接看包名和 jar 内部的组织路径凡是带 da、opc、rpc、jinterop 字样的大概率归在这一类。缺了这层依赖时症状也非常典型进程能启动日志也打了但一旦发起 OPC 连接就抛 ClassNotFoundException或者直接挂在“正在连接 OPC Server”这步动不了。我见过最隐蔽的一种情况是桥接 jar 版本新旧混着放DCOM 调用能建立但数据读回来全是 0 和 1 的跳变查了半天发现是两个 jar 里的 RPC 协议实现互相覆盖了。2.2 数据采集与存储层协议驱动、数据库驱动和工具库OPC 层负责把现场数据“够”进来但 openSCADA 不可能全靠 OPC——很多网口仪表、Modbus 网关、MQTT 上报设备走的完全是另一套协议。所以 lib 目录里往往还会躺着一批采集扩展 jarModbus TCP/RTU 的协议解析器、MQTT 客户端、S7 通信库之类。数据进来之后要落库、要报警、要出趋势这就轮到 JDBC 驱动和工具库上场。常见的是 MySQL、PostgreSQL 对应的驱动 jar负责把实时数据写进历史表其次是 JSON/XML 解析库用来处理配置文件、接口报文再就是日志框架的桥接包slf4j、log4j 这些。要说哪一类最容易被忽略我觉得是数据库驱动——很多人只盯着 OPC 那一堆 jar启动不报错就以为自己配好了等到历史数据存不进去打开日志才发现 mysql-connector 根本没进类路径。工具库里还容易漏的是系统信息采集类的 jar比如 sigar 那一类用于读取 CPU、内存、磁盘状态。这个不是运行必需但很多 openSCADA 界面上的主机监控面板依赖它缺了之后程序不报错只是面板一片空白排查起来特别容易绕远路。2.3 一份可对照的依赖核对表为了方便你拿到 jar 包后快速核对自己缺什么我把常见依赖按类别整理成一张表。注意这里不写具体版本号因为不同项目拷贝出来的 lib 目录差异极大以你手里的实际包为准——重点看的是“职责是否齐全”。类别典型 jar 名称片段是否必选缺失时常见症状OPC DA 通信opc-da-core、jinterop、rpc 相关接 DA 时必选连接 OPC Server 时 ClassNotFound 或超时OPC UA 通信opc-ua-stack 等接 UA 时必选握手失败、证书异常协议采集modbus、mqtt、s7 等按现场设备选设备数据不刷新日志无采集中记录JDBC 驱动mysql-connector、postgresql 驱动数据入库必选历史查询报错数据不落库系统监控sigar 等可选监控面板空白JSON/XMLjackson、dom4j 等多数必选配置文件解析异常日志框架slf4j、logback 等必选启动即 NoClassDefFoundError拿到一套 jar 之后我建议你先把这张表对着 lib 目录过一遍缺什么补什么。比一上来就执行启动脚本高效得多——启动脚本顶多告诉你有问题而这张表告诉你问题大概率长在哪。3. 把 jar 正确装进运行环境Java 版本、启动脚本与 JVM 参数3.1 先定 JDK 版本再谈“跑起来”我拆过不少这样的工程头号翻车点根本不是 jar 本身而是 JDK 版本和 jar 编译目标对不上。老一些的 SCADA 工程基于 Java 8 开发你用高版本的 JDK 去跑启动时大概率直接报“不支持 major version”一类错误。反过来某些用了新语法的新版工程放到 JDK 8 下也会立刻哑火。我一般会先做两件事第一看 lib 目录里核心 jar 的 MANIFEST 文件里面通常写有 Build-Jdk 或 Created-By 之类信息第二用 javap -verbose 看某个核心类文件的 major version52 对应 Java 855 对应 Java 1161 对应 Java 17。确定目标版本后把 JAVA_HOME 指到对应版本的 JDK再开跑。这一步千万别省很多后续的玄学问题都是版本错配引起的。3.2 一份能直接改的 Linux 启动脚本拿到 jar 之后比较规范的启动姿势是用通配符把 lib 目录整体加进 classpath然后在启动脚本里固定好工作目录、配置目录和日志输出。下面是一份我常用的启动脚本骨架#!/usr/bin/env bash # openSCADA 启动脚本按实际路径修改后可直接使用 export JAVA_HOME/usr/local/jdk # 改成你机器上的 JDK 路径 export PATH$JAVA_HOME/bin:$PATH APP_HOME/opt/openscada # 工程根目录 LIB_DIR$APP_HOME/lib # jar 统一放这里 CONF_DIR$APP_HOME/conf # 配置文件目录 LOG_DIR$APP_HOME/logs # 运行日志目录 mkdir -p $LOG_DIR JVM_OPTS-server -Xms256m -Xmx1024m -Dfile.encodingUTF-8 # 注意-classpath 后面的引号不能去掉lib/* 通配符由 JVM 展开 # 把命令行里的启动类换成你包里的实际入口类一般以 org.openscada 开头 nohup java $JVM_OPTS \ -Duser.dir$APP_HOME \ -classpath $LIB_DIR/* \ org.openscada.boot.Main \ -config $CONF_DIR/openscada.xml \ $LOG_DIR/console.log 21 echo openSCADA started, pid$!逻辑说明LIB_DIR/*这种写法能让 JVM 自动把 lib 下所有 jar 都加入类路径不用逐个列出也不受 jar 数量增减影响。-Duser.dir是为了保证相对路径的配置文件能正确找到-Dfile.encoding设为 UTF-8 是很关键的一步否则中文乱码会从日志一路乱到监控页面。nohup和配合重定向保证程序在终端退出后还能继续跑并且日志不会丢。参数说明-Xms256m是初始堆大小-Xmx1024m是最大堆。SCADA 这类常驻进程我建议至少给 1G如果你现场点位很多、历史查询频繁直接给到 2G 以上也不过分。启动类名务必替换成你 lib 目录里真实存在的入口类这个没法一刀切打开工程主 jar 的 MANIFEST 看一眼 Main-Class 就行。3.3 让 JVM 留好“诊断口”GC 日志与远程监控参数跑现场的系统最怕出问题时候没日志。我通常在启动脚本里再加两段参数一段输出 GC 日志一段开放 JMX 端口限定内网访问。这样内存异常时有数据可查线程卡死时能用 jstack 直接抓现场线程栈。JVM_OPTS$JVM_OPTS -Xloggc:$LOG_DIR/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps JVM_OPTS$JVM_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port9010 JVM_OPTS$JVM_OPTS -Dcom.sun.management.jmxremote.sslfalse -Dcom.sun.management.jmxremote.authenticatefalse加这两段之后每次启动都会在 logs 目录留下 GC 记录你可以随时用 JConsole 或 VisualVM 连到 9010 端口看堆内存占用。需要注意JMX 端口只该在调试期开放而且必须绑内网别图省事暴露到公网。跑稳定之后把这两行注释掉减小不必要的 IO 开销。4. 避坑记录从 ClassNotFound 到 OPC 闪断五条实战踩坑4.1 现象启动直接 ClassNotFoundException但 jar 明明在 lib 里有一次在某个现场部署明明看到 jar 文件躺在 lib 目录下启动却一直报某个类找不到。原因折腾了很久才想明白IDE 构建时把 lib 排除出了编译路径打出来的发布包里根本没有这几个 jar我检查的却是本地的 lib 目录。解决方法是重新打包发布物并且用压缩包工具打开发布包确认 lib 目录真的存在不要只看需求单。4.2 现象OPC 连接能通但数据订阅总是无规律闪断连接能建立说明 DCOM 桥接和 OPC 核心 jar 都加载成功了闪断就说明不是缺依赖而是运行时环境问题。检查下来原因是 DCOM 的默认超时时间太短现场网络抖动稍大就断线重连。解决方法是到 Windows 的组件服务里把 DCOM 超时参数调大同时给 JVM 加-Dsun.rmi.transport.tcp.responseTimeout参数来控制 RMI 超时。从那以后我再遇到闪断问题都会先看这两处而不是一头扎进代码里找原因。4.3 现象历史数据不落库控制台也不报错程序跑得稳稳当当点历史查询就是没数据。翻日志才发现根本没有数据库相关的初始化记录原因是驱动 jar 被单独放在了外部目录而启动脚本只扫描了 lib 目录。解决方法是把驱动 jar 也拷进 lib或者在启动脚本的 classpath 里把外部目录一并加上。从那以后我会特别注意“jar 放了但不在 classpath 范围内”这种低级但高频的坑。4.4 现象现场机器 32 位 JDK启动报“无法访问”或 UnsatisfiedLinkError这类问题常出现在带本地库的 jar 上。Sigar、串口通信库都要加载 .dll 或 .so 文件JDK 是 32 位就只能加载 32 位版本的本地库版本不匹配直接 UnsatisfiedLinkError。曾经在工控机上为一个串口驱动的本地库折腾了一整天最后换了 64 位 JDK 才彻底解决。现在每到一个新机器我都会先检查java -version和系统位数一致再动别的。4.5 现象运行一周后内存缓慢上涨最终 OOMSCADA 系统长时间运行后内存上涨常见的不是业务代码写炸了而是历史数据在堆里堆积。openSCADA 这类系统的实时缓存默认配置往往偏保守点位多的项目要手动调大缓存刷新周期。解决方法是把配置文件里的历史存储策略从“实时写”改成“批量写”同时把堆最大值往上提并配合 GC 日志观察 Full GC 频次确认内存是真的被业务占用了而不是泄漏。5. 按需补 jar 与依赖自检让“缺包”在启动前就暴露5.1 jar 补到哪个目录是有讲究的很多人拿到一包 jar 就直接全部丢进 lib但这其实不是好习惯。核心的开源依赖可以放 lib而像数据库驱动、现场私有协议驱动这种“环境相关”的 jar我更建议单独放一个lib-ext目录在启动脚本里用$LIB_DIR/*:$EXT_DIR/*一起引入。这么做的好处是将来升级驱动时不用去核心 lib 里翻找也避免同包名不同版本的 jar 互相覆盖。5.2 写一个只读扫描脚本按“类路径”核验 jarjar 放在 lib 里不等于一定会被加载尤其是存在多个 jar 内包含同名类文件的时候。我一般会写一个简单的 Python 脚本读取清单里该有的类路径然后逐个 jar 检查是否存在对应 class 文件。这能抓出“目录里 jar 看着齐全但核心类已经被覆盖或丢失”的问题。#!/usr/bin/env python3 # 依赖自检脚本按内部类路径核对 lib 目录里的 jar # 用法python3 check_jars.py [lib目录] import os import sys import zipfile lib_dir sys.argv[1] if len(sys.argv) 1 else lib # 每一项jar 名称关键字 - 必须存在的类文件路径 required { opc-da-core: org/openscada/da/core/Activator.class, jinterop: org/jinterop/dcom/core/JIComServer.class, mysql-connector: com/mysql/jdbc/Driver.class, slf4j-api: org/slf4j/Logger.class, } def scan_jar(jar_path, target_class): 检查单个 jar 内部是否包含指定 class 文件 try: with zipfile.ZipFile(jar_path) as zf: return target_class in zf.namelist() except zipfile.BadZipFile: print(f损坏的 jar: {jar_path}) return False result {} for key, cls in required.items(): found False for fname in os.listdir(lib_dir): if key in fname and fname.endswith(.jar): if scan_jar(os.path.join(lib_dir, fname), cls): found True break result[key] found print(f[{OK if found else MISSING}] {key}: {cls}) if not all(result.values()): print(存在缺失依赖请先补齐再启动) sys.exit(1) else: print(核心依赖完整可以继续)逻辑说明脚本遍历 lib 目录按 jar 文件名关键字找到可能的候选包再用zipfile.namelist()直接检查 jar 内部的 class 文件路径是否存在。这比只看 jar 文件名要靠谱得多——文件名对不代表内容对内容对才算依赖真的在。参数说明required字典里的 key 要和实际 jar 文件名的关键字一致value 是类文件路径你可以按自己工程里的核心类替换。5.3 Modbus 串口类扩展 jar 的“边界依赖”串口通信在工控现场非常常见但串口 jar 有个特殊之处它通常还依赖一个本地串口库文件。很多人在 lib 里加了 jar却忘了把对应平台的本地库放到java.library.path指定的目录结果启动时报“no rxtxSerial in java.library.path”。解决方法是把 .dll 或 .so 文件放到工程的 native 目录启动脚本加上-Djava.library.path$APP_HOME/native让 JVM 启动时就能找到。这类边界依赖最容易在跨平台部署时翻车务必先确认目标系统的位数和本地库是否匹配。6. 最后一个技巧用 -verbose:class 验证核心类到底被谁加载与其猜某个 jar 对不对不如让 JVM 亲口告诉你。-verbose:class参数会在 JVM 加载每个类时打印一行日志内容包含“类名来自哪个 jar”。对于 openSCADA 这种类路径复杂的工程这是最有性价比的验证手段。# 在启动命令中加入 verbose:class然后过滤核心关键字 java -verbose:class $JVM_OPTS -classpath $LIB_DIR/* org.openscada.boot.Main -config conf/openscada.xml 21 | grep org.openscada正常启动时你会看到类似[Loaded org.openscada.da.core.Activator from file:/opt/openscada/lib/opc-da-core.jar]这样的行。这能同时确认三件事类被加载了、类加载自哪个 jar、以及有没有同一个类被多个 jar 重复加载。如果发现同包同类来自两个不同 jar就要高度警惕版本冲突保留和工程最初编译环境一致的那个另一个移出去。还有一个习惯值得养成每次启动脚本改完先把 GC 日志和 verbose 日志各留一份等系统跑稳定了再删。这样将来排查问题时你知道这套 jar 在“正常状态”下加载了哪些类、GC 频率多高出现异常时才有对照基准。从前我也觉得这些日志多余直到一次现场问题排查中靠一份启动早期的 verbose 日志定位出了“某个 jar 被替换过”的真相之后每次接手新环境我都强制自己先跑一遍这套验证流程再交付。希望帮到你。本文还有配套的精品资源点击获取