简介：面向 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 目录里往往还会躺着一批采集扩展 jar：Modbus 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 之后，我建议你先把这张表对着 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 version，52 对应 Java 8，55 对应 Java 11，61 对应 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.encoding=UTF-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" 2>&1 & 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.port=9010" JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

加这两段之后，每次启动都会在 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 现象：运行一周后内存缓慢上涨，最终 OOM

SCADA 系统长时间运行后内存上涨，常见的不是业务代码写炸了，而是历史数据在堆里堆积。openSCADA 这类系统的实时缓存默认配置往往偏保守，点位多的项目要手动调大缓存刷新周期。解决方法是把配置文件里的历史存储策略从“实时写”改成“批量写”，同时把堆最大值往上提，并配合 GC 日志观察 Full GC 频次，确认内存是真的被业务占用了，而不是泄漏。

5. 按需补 jar 与依赖自检：让“缺包”在启动前就暴露

5.1 jar 补到哪个目录，是有讲究的

很多人拿到一包 jar 就直接全部丢进 lib，但这其实不是好习惯。核心的开源依赖可以放 lib；而像数据库驱动、现场私有协议驱动这种“环境相关”的 jar，我更建议单独放一个lib-ext目录，在启动脚本里用$LIB_DIR/*:$EXT_DIR/*一起引入。这么做的好处是将来升级驱动时，不用去核心 lib 里翻找，也避免同包名不同版本的 jar 互相覆盖。

5.2 写一个只读扫描脚本，按“类路径”核验 jar

jar 放在 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 2>&1 | 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 被替换过”的真相，之后每次接手新环境，我都强制自己先跑一遍这套验证流程再交付。希望帮到你。

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