简介面向 Java 工业自动化开发者的 openSCADA 依赖合集聚焦 SCADA 系统搭建与 OPC 通信场景适合需要快速补齐第三方库、排查版本冲突的初中级开发者。压缩包共 480 个文件、约 30.92MB其中 129 个 jar 构成核心运行与扩展依赖339 个 class 覆盖编码序列化、客户端与服务器会话通道及应用入口等实现另含 xml、properties、classpath 等配置文件和少量说明文档可用于对照工程结构与环境参数。已有 691 人学习下载。整体目录按依赖类别组织能省去逐项检索与版本比对的时间也便于在离线环境快速还原可运行工程对想理解 openSCADA 模块划分、OPC 数据交互与序列化机制的读者class 与配置样本可作为调试和二次开发的参考降低环境搭建与联调门槛。1. 从一堆 jar 开始openSCADA 的 Java 运行底包到底缺在哪拿到一个名为 openSCADA 所需的 jar 的压缩包时很多人第一反应是解压后直接丢进 lib然后双击启动脚本。真正卡住 Java 侧 openSCADA 启动的往往不是少了某个大包而是 OPC 采集链路里某一层依赖没对齐核心容器能起来插件加载到通信层就报NoClassDefFoundError或者 OPC UA 连接刚建好就被证书信任链拦下。这套资源解决的是“依赖底包”问题不是教你怎么从零写一个 SCADA。它适合手上已有 openSCADA 工程、需要补齐 Java 运行库、准备接 OPC UA/OPC DA 设备、又不想在几十个 jar 里逐个猜缺失项的从业者。新手可以按目录和启动脚本先跑通最小采集熟手可以直接看依赖分层和冲突排查。2. 依赖分层把 openSCADA 的 jar 按运行链路拆成四层2.1 先画运行链路从启动器到 OPC 采集Java 版 openSCADA 的启动链路通常是JVM 加载启动器 jar启动器拉起核心容器核心容器再扫描插件或模块目录模块初始化通信层通信层里的 OPC 客户端去连设备。链路上任何一层缺 jar表现都不一样。启动器缺包JVM 直接ClassNotFoundException核心容器缺包日志停在容器初始化OPC 客户端缺包往往要等模块启动才爆现场看起来像“SCADA 起来了但采集不动”。我一般先把依赖按“谁加载、谁可见”分而不是按文件名分。共享给核心容器和所有模块的包放 lib只给某个插件用的包放插件自己的目录JNI 桥接库放 native配置文件放 conf。这样后面排查时看到NoClassDefFoundError就能先判断是类路径没拼上还是类加载器隔离导致父加载器看不到。依赖分层不是为了好看是为了把“缺包”变成可定位的问题。比如 OPC UA 客户端 jar 被放进插件目录插件自己能用但核心容器里的连接池初始化时找不到同一个类就会在启动后半段报错。把共享通信包上移到 lib问题立刻消失。这类现象在只贴 jar 清单的资源里很少写但实际落地时最容易翻车。2.2 四层依赖的选型理由与缺失表现下面这张表是我拆这类 jar 包时常用的分层方式。具体文件名可以不同但类别和缺失表现基本对得上。层级典型 jar 类别作用缺失或错放时的表现排查入口基础运行层日志 API、日志实现、基础工具、集合扩展支撑容器和模块的日志、配置读取、线程池启动即报ClassNotFoundException或日志只输出到控制台启动脚本 classpath、-verbose:classSCADA 核心层容器、事件总线、数据模型、权限、调度提供 openSCADA 的运行骨架容器初始化到一半停住插件扫描不继续核心日志最后一行、插件加载顺序OPC 通信层OPC UA 客户端、OPC DA JNI 桥、证书与安全工具连接设备、订阅点位、读写标签模块启动成功但采集为空或连接超时OPC 模块日志、endpoint 配置、native 目录辅助与诊断层监控、健康检查、诊断输出、脚本引擎运行期观测和排错不影响启动但出问题没有指标和堆栈诊断开关、JMX 或日志级别选型上OPC UA 和 OPC DA 要分开看。OPC UA 是跨平台协议Java 客户端通常以纯 Java jar 为主依赖相对干净OPC DA 依赖 Windows 平台的 COM/DCOMJava 侧一般要通过 JNI 桥接库接入除了 jar 还要有对应的 native 动态库。把 DA 的桥接 jar 当成普通 Java 包丢进 lib启动可能不报错第一次读点位才报 native 库找不到这就是典型的“黑匣子”现场。缺失表现也要分清。ClassNotFoundException多半是类路径没包含NoClassDefFoundError可能是类初始化失败或被类加载器隔离NoSuchMethodError通常是同一库多版本打架。三种错误看起来都是“缺 jar”处理方式完全不同。先看异常类型再决定是补包、移包还是删旧版。2.3 用依赖树命令锁定传递依赖如果手上还有工程源码或 pom先跑依赖树不要靠jar tf一个个翻。下面这段命令只保留 OPC 和 SCADA 相关坐标输出到文件后再看重复版本。# 只查看 OPC / UA / SCADA 相关依赖及其传递路径 mvn -q dependency:tree -Dincludes*:*opc*,*:*ua*,*:*scada* opc-tree.txt # 按 artifactId 统计出现次数快速找同一库的多版本 grep -E opc|ua|scada opc-tree.txt | sort | uniq -c | sort -nr-Dincludes支持groupId:artifactId通配*:*opc*表示任意 groupId 下 artifactId 含 opc 的依赖-q只输出依赖树本身减少噪音重定向到文件是为了保留传递路径后面看某个包是从哪个上层依赖带进来的。grep和uniq -c只是粗筛真正要删版本时还得回到树里看路径。如果只有 jar 没有工程文件就用jdeps或jar tf做静态检查。jdeps --multi-release能看模块依赖jar tf能看包名和类名。命令不能告诉你版本冲突的全部真相但能确认“这个 jar 里到底有没有 OPC 客户端类”。参数上jdeps的-recursive会递归分析依赖适合在隔离目录里跑不要直接对生产 lib 做写操作。提示依赖树里同一个库出现两个版本时不要只看版本号高低先看哪个是直接依赖、哪个是传递带进来的。删错传递依赖编译能过运行期照样报NoSuchMethodError。3. 落地目录与类路径把 jar 放进 openSCADA 能认的位置3.1 目录约定lib、plugins、conf 各自放什么拿到 jar 包后第一步不是启动而是按目录归位。我习惯用下面这套约定具体名称可以跟着工程走但职责不要混。目录放什么不要放什么原因lib核心容器、日志、共享 OPC 客户端、基础工具只给某个插件用的私有包父加载器可见避免核心初始化时找不到类plugins业务模块、设备驱动、只在模块内使用的扩展核心容器启动就需要的共享包插件类加载器隔离核心层不一定看得到confendpoint、安全策略、节点映射、日志配置jar 包和 native 库配置与二进制分离替换时不影响依赖nativeOPC DA 桥接动态库、JNI 依赖纯 Java jarjava.library.path只认 native 目录最容易出错的是把共享 OPC 客户端 jar 放进 plugins。插件自己加载没问题但核心容器里的连接管理、线程池或诊断组件如果也引用了同一个类就会在启动后半段报NoClassDefFoundError。现场日志看起来像“插件启动失败”实际是类加载器可见性问题。另一个常见误区是把所有 jar 平铺在根目录然后用-cp *一把梭。Java 的 classpath 通配符不递归子目录顺序也不稳定同名类出现在两个 jar 里时谁先被加载取决于文件系统顺序这种玄学问题很难复现。目录约定加上显式循环至少能把顺序固定下来。3.2 启动脚本与 classpath 拼接下面这个启动脚本只做三件事拼 classpath、指定 native 目录、把应用 home 传进去。启动类名用占位符落地时替换成工程里的实际入口。#!/usr/bin/env bash set -euo pipefail APP_HOME$(cd $(dirname $0) pwd) # 配置目录放最前确保本地 conf 覆盖 jar 内默认配置 CP$APP_HOME/conf # 只把 lib 下 jar 拼进 classpath顺序按文件名稳定排序 for j in $APP_HOME/lib/*.jar; do CP$CP:$j done # OPC DA 的 JNI 库放 native避免运行期找不到动态库 exec java -Xms512m -Xmx2g \ -Djava.library.path$APP_HOME/native \ -Dscada.home$APP_HOME \ -cp $CP com.example.scada.Bootstrap $set -euo pipefail让脚本在变量未定义、管道失败时尽早退出避免拼出半个 classpath 还继续启动。APP_HOME用脚本所在目录反推不依赖当前工作目录。CP先放 conf再循环追加 lib 下所有 jar文件名排序是稳定的至少同一套包每次启动顺序一致。-Djava.library.path指向 native 目录OPC DA 桥接库和 JNI 依赖都放这里。-Dscada.home是应用自己的 home 参数日志和临时文件通常会读它。-Xms、-Xmx按现场数据量调采集点多、历史缓存大时不要只给 512 MB。如果启动类不在com.example.scada.Bootstrap只改最后一段不要把 classpath 拼接逻辑打散。脚本里不要用java -jar除非这个 jar 的 MANIFEST 已经写好了完整 classpath多数 openSCADA 依赖包不是一个 fat jar-jar会忽略-cp现场很容易误判。3.3 用脚本做 jar 完整性检查压缩包在传输过程中被截断或者解压不完整启动时报的错和缺包一模一样。先做静态完整性检查比直接看日志快。#!/usr/bin/env bash set -euo pipefail JAR_DIR${1:-lib} # 1) 检查每个 jar 能否被 zip 工具完整读取截断包会在这里暴露 for f in $JAR_DIR/*.jar; do unzip -tqq $f /dev/null || echo 损坏: $f done # 2) 列出包含 OPC / UA / JNI 关键包名的 jar确认通信层没漏 for f in $JAR_DIR/*.jar; do if jar tf $f | grep -qiE opc|ua|jni; then echo OPC 相关: $f fi doneJAR_DIR默认是 lib也可以传插件目录。unzip -tqq只做测试不输出解压内容失败时打印文件名如果没有unzip用jar tf也能发现明显截断但对 zip 尾部损坏不如unzip -t直接。第二个循环用jar tf列出 jar 内条目grep -qiE opc|ua|jni忽略大小写匹配关键词。这个检查不能替代依赖树但能快速确认“OPC 通信层到底在不在 lib 里”。注意jar tf需要 JDK 的jar命令。只有 JRE 的环境里可以临时用unzip -l代替但不要把检查脚本放到生产启动链路里它只用于交付前验证。4. OPC 接入Java 侧连接参数与 jar 的对应关系4.1 OPC UA 与 OPC DA 的 jar 差异OPC UA 和 OPC DA 在 Java 侧的依赖形态差别很大选型时先确认设备侧支持哪种协议。OPC UA 走 TCP跨平台Java 客户端通常是纯 Java 库jar 齐全后在 Linux 上也能跑OPC DA 依赖 Windows 的 COM/DCOMJava 侧一般通过 JNI 桥接除了 jar 还要有 native 动态库部署环境基本限定在 Windows 或带桥接服务的跳板机。对比项OPC UAOPC DA传输TCP跨平台COM/DCOM平台依赖强Java 依赖纯 Java 客户端 jar 为主JNI 桥接 jar native 动态库证书与安全证书、信任列表、安全策略是必配项多依赖 DCOM 权限和本地账户配置常见缺失表现连接超时、证书被拒native 库找不到、COM 初始化失败落地建议新项目优先依赖包可随应用一起交付存量设备接入单独准备 Windows 运行环境如果设备同时支持 UA 和 DA我一般优先 UA。不是 DA 不能做而是 DA 的排错链条更长DCOM 权限、账户、防火墙、native 库、位数匹配每一层都能让采集卡住。UA 的坑主要集中在 endpoint、安全策略和证书信任至少日志能直接告诉你哪一步没过。jar 层面也要注意位数。OPC DA 的 native 桥接库分 32 位和 64 位JDK 是 64 位native 库却是 32 位启动时可能只报一句“找不到依赖库”实际是位数不匹配。UA 的纯 Java 包一般没这个问题但证书库和加密套件可能依赖额外的安全 jar缺了会在握手阶段报安全策略不支持。4.2 连接配置项endpoint、安全策略、节点 IDOPC 连接配置不要散落在代码里集中到 conf 下替换环境时只改配置。下面这些参数是 Java 侧接入时最常调的。参数示例占位作用调错后的现象endpointopc.tcp://127.0.0.1:4840OPC UA 服务地址连接超时或立即拒绝securityPolicyBasic256Sha256等安全策略握手失败日志提示策略不支持messageSecurityModeSignAndEncrypt等消息安全模式能连上但读写被拒username/password按现场账户身份认证匿名可连、认证后失败certificate/trustList客户端证书与服务端信任列表证书信任链BadCertificateUntrustednodeIdns2;sTagName点位标识连接正常但读不到值samplingInterval1000毫秒订阅采样周期数据刷新慢或重复publishingInterval1000毫秒发布周期队列堆积或实时性差endpoint的协议前缀必须是opc.tcp://端口按服务端实际配置不要照抄示例。securityPolicy和messageSecurityMode要和服务端一致现场最常见的翻车是客户端用加密、服务端只开签名或者反过来。nodeId里的ns索引不是固定值服务端命名空间表变了原来的ns2可能指向另一个命名空间采集就会读到空值或错误点位。采样周期不要小于设备刷新周期。设备 500 毫秒刷新一次客户端订阅 100 毫秒只会拿到重复值还增加网络和服务端队列压力。我一般先按设备刷新周期设观察一段时间后再调。发布周期和采样周期也不要拍脑袋采集点多时先保稳定再谈实时性。4.3 一个最小采集循环的 Java 代码骨架下面这段是骨架不是直接可运行的 SDK 调用。OpcConnection、OpcSubscription都是占位接口落地时替换成实际 OPC 客户端库的 API。保留这个结构是为了说明参数从哪来、异常在哪一层处理。// 占位骨架替换为实际 OPC 客户端 SDK 的连接与订阅 API public class OpcProbe { public static void main(String[] args) throws Exception { String endpoint System.getProperty(opc.endpoint, opc.tcp://127.0.0.1:4840); String nodeId System.getProperty(opc.node, ns2;sDemo.Tag); long sampling Long.getLong(opc.sampling, 1000L); // 1) 建立连接安全策略、证书信任链必须与服务端匹配 OpcConnection conn OpcConnection.open(endpoint); // 2) 创建订阅采样周期不要小于设备刷新周期 OpcSubscription sub conn.subscribe(sampling, value - { System.out.println(tag value.nodeId() , value value.value()); }); sub.addNode(nodeId); // 3) 保持运行生产环境要加断线重连和退出钩子 Thread.sleep(60_000); sub.close(); conn.close(); } }opc.endpoint、opc.node、opc.sampling都从系统属性读方便启动脚本覆盖不要把现场地址写死在代码里。OpcConnection.open这一步要处理证书和策略异常不要只捕获Exception后打印“连接失败”至少把服务端返回的状态码带出来。subscribe的回调里不要做重业务采集回调线程被阻塞后续点位会排队。Thread.sleep只是骨架里的保活生产代码要用线程池或事件循环并加断线重连。这段代码的价值在于验证依赖是否齐能编译、能启动、能连上、能收到一个点位值说明 OPC 通信层 jar 基本对齐。连不上时先换最小客户端测不要直接在 openSCADA 容器里猜。容器日志长最小客户端日志短定位快得多。5. 避坑排查OPC 连不上与 jar 冲突的五个现场记录5.1 启动期类找不到与版本打架记录一核心容器启动到 OPC 模块就报NoClassDefFoundError。现象是日志停在“初始化通信模块”异常指向 OPC 客户端类。原因多半是 OPC 客户端 jar 被放进了 plugins插件自己的类加载器能看见核心容器看不见。解决是把共享 OPC 客户端 jar 上移到 lib或者把模块依赖声明为父加载器可见再用java -verbose:class看这个类到底从哪个 jar 加载。记录二同一个包出现NoSuchMethodError。现象是启动能过第一次调用连接方法就崩异常里的方法签名和当前代码对不上。原因是 lib 里同时存在两个版本的 OPC SDK启动脚本按文件名排序先加载了旧版。解决是用依赖树收敛版本删掉旧 jar固定一个版本没有工程文件时用jar tf比对两个包里同一个类的路径和大小不要只看文件名。记录三日志框架报ClassNotFoundException或启动后日志重复输出。现象是控制台出现多套日志格式或者某个模块日志完全不输出。原因是日志 API 和日志实现多套共存桥接 jar 重复。解决是只保留一套日志 API 加一个绑定实现排除传递依赖里的旧桥接包改完后用启动日志确认绑定的是哪一个实现。5.2 运行期OPC 连接超时与证书报错记录四OPC UA 连接一直超时。现象是模块启动成功采集线程反复重连日志只有 timeout。原因可能是 endpoint 端口或路径写错也可能是安全策略不匹配导致握手阶段被断开。解决是先用最小客户端连同一个 endpoint确认网络和端口再核对securityPolicy、messageSecurityMode与服务端是否一致。防火墙和 NAT 场景下不要只测 ICMP要测 TCP 端口。记录五证书被拒日志出现BadCertificateUntrusted。现象是 TCP 能通握手到证书阶段失败。原因是客户端证书没加入服务端信任列表或者服务端证书没进客户端 trustList。解决是导出 der 格式证书分别加入两端信任列表重启连接不要图省事关掉安全策略长期跑后面换环境还会再翻车。证书主题和有效期也要看过期证书同样会被拒。这五条记录里前三条是类路径和版本问题后两条是连接配置问题。排查顺序我一般反着来先确认最小客户端能连再回到 openSCADA 容器看类加载。容器里变量太多最小客户端能把“网络与证书”和“jar 与类加载”分开。血泪经验是不要一上来就改代码先把日志里的异常类型和第一个出错类名抄下来再决定动哪一层。6. 验证与技巧用三组命令确认这份 jar 包真的能用6.1 静态验证清单、哈希、依赖收敛拿到包后先别启动。把 lib 复制到临时目录跑一遍 3.3 的完整性检查再用sha256sum对关键 jar 做一次哈希记录。依赖收敛用第 2 章的依赖树命令没有工程文件就用jar tf找重复类。静态验证的目标不是证明“包没问题”而是把明显损坏和明显多版本排掉。6.2 动态验证启动日志与最小采集点启动时加-verbose:class只用于排查不要长期开着。先看启动日志最后一行停在哪再看 OPC 模块有没有打印连接成功。最小采集点选一个不要一上来全量点表。能收到一个值再逐步加订阅。采样周期先设大一点稳定后再压。6.3 一个习惯先跑隔离 classpath 再上生产我现在拿到这种依赖包习惯先把 lib 复制到临时目录用隔离 classpath 跑最小采集确认 OPC 连接、证书、native 库都过一遍再谈替换生产 lib。生产环境最怕“看起来启动了”采集却是空的。从那以后我每次换 jar 包都强制走一遍静态检查加最小采集不再直接覆盖。希望帮到你。本文还有配套的精品资源点击获取