企业官网建设流程全解析

简介：在工业自动化与物联网系统中，数据采集是连接物理设备与上层信息系统的核心技术。OPC（OLE for Process Control）作为工业通信的事实标准，特别是OPC DA（数据访问）协议，长期以来是实现不同品牌PLC、仪表与上位软件之间数据互通的关键桥梁。其原理基于微软的COM/DCOM技术，在Windows平台上为实时数据读写提供了稳定接口。对于采用Java技术栈的后台服务而言，直接调用COM组件存在跨平台障碍，因此需要通过JNI（Java Native Interface）桥接方案进行封装。Utgard库正是这一领域的经典实现，它通过本地库封装了与OPC服务器的复杂交互，使Java程序能够稳定、高效地作为OPC DA客户端运行。该技术方案在兼容遗留工业系统、满足高实时性数据采集需求方面具有重要价值，广泛应用于MES、SCADA等需要将OT（运营技术）数据接入IT（信息技术）平台的应用场景，例如从西门子、三菱等PLC中采集温度、压力、设备状态等生产数据，并写入数据库或消息队列。

1. 项目概述：为什么选择Utgard连接OPC服务器？

在工业自动化领域，数据采集是第一步，也是最关键的一步。如果你做过工厂的MES（制造执行系统）或者SCADA（数据采集与监控系统）项目，肯定遇到过这样的场景：产线上跑着西门子、三菱、欧姆龙等不同品牌的PLC，上位机软件可能是WinCC、组态王或者力控，而你的任务是用Java写一个后台服务，把这些分散的、实时的生产数据（比如温度、压力、转速、设备状态）统一采集上来，存入数据库或者推送到消息队列，供上层的数据分析平台使用。这时候，OPC（OLE for Process Control）技术就成了连接不同设备和软件之间的“普通话”。

OPC DA（Data Access）是应用最广泛的标准，它基于微软的COM/DCOM技术，允许客户端（比如你的Java程序）从服务器（比如PLC的驱动软件）中读取和写入数据。然而，Java是跨平台的，天生与Windows平台的COM/DCOM“水土不服”。直接让Java去调用COM组件，就像让一个说中文的人直接去理解机器码，几乎不可能。因此，我们需要一个“翻译官”——这就是OPC基金会官方提供的Java OPC DA包装器，而Utgard正是其中历史悠久、稳定可靠的一个实现库。

简单来说，java使用Utgard方式调用opc服务器这个项目，核心就是解决Java程序在工业环境中作为OPC DA客户端，与各类OPC服务器进行稳定、高效通信的问题。它适合需要从工业现场采集数据到Java后端系统的开发者、系统集成工程师，或者任何希望将OT（运营技术）数据与IT（信息技术）系统打通的团队。如果你正在为如何用Java读取一台西门子S7-1200 PLC里的数据而发愁，那么Utgard很可能就是你要找的钥匙。

2. 核心思路与方案选型：Utgard的定位与替代方案

在决定使用Utgard之前，我们有必要理清工业数据采集的技术栈。为什么是Utgard，而不是其他方案？这背后是一系列技术和现实条件的权衡。

2.1 OPC通信的技术栈剖析

OPC DA通信本质是一个C/S架构。服务器端通常由硬件厂商（如西门子、罗克韦尔）提供的驱动软件充当，或者由第三方通用OPC服务器（如Kepware、Matrikon）实现。它们负责与底层PLC、仪表等设备通讯，并将数据以OPC接口的形式暴露出来。客户端则通过标准的OPC接口来访问这些数据。

对于Java客户端，有几种主流实现路径：

1. JNI桥接方式：代表就是Utgard。它的原理是，通过Java Native Interface（JNI）调用一个用C/C++编写的本地库（DLL），这个本地库再通过COM/DCOM去和OPC服务器交互。Java代码只和这个JNI层打交道，所有Windows和COM的复杂性都被封装在本地库中。这是早期最成熟、性能最好的方案。
2. 纯Java OPC UA：OPC UA是OPC基金会推出的新一代标准，独立于平台和Windows，使用TCP/IP等标准网络协议。有成熟的纯Java开源库，如Eclipse Milo、Prosys OPC UA Java SDK。这是未来的方向，但需要OPC服务器端也支持UA协议，许多老旧的设备或驱动可能只支持DA。
3. 商业中间件/网关：使用像Kepware、IoT Gateway这样的软件，它们本身作为强大的OPC服务器，同时提供丰富的客户端接口，包括REST API、MQTT、数据库写入等。Java程序通过HTTP或MQTT等标准IT协议与网关交互，完全避开了直接操作OPC的复杂性。这是系统架构升级时的优秀选择，但需要额外的软件授权费用。
4. JeasyOpc等简化封装：一些开源项目在Utgard等库之上做了更上层的封装，提供更简洁的API。它们降低了使用门槛，但底层依然依赖JNI和本地库。

2.2 为什么在这个场景下选择Utgard？

选择Utgard，通常是基于以下几个现实考量：

• 遗留系统兼容性：现场大量存在的依然是基于OPC DA的服务器和驱动。升级到OPC UA可能需要更换硬件、更新软件，成本高昂。Utgard能让你用Java技术栈无缝接入这些现有资产。
• 性能与实时性要求：对于需要高频（如100ms）采集大量数据点的场景，基于COM/DCOM的OPC DA在局域网内通常能提供比基于TCP/IP的OPC UA更低的延迟和更高的吞吐量。Utgard作为JNI桥接，性能损耗在可接受范围内。
• 技术可控性与成本：商业网关虽好，但有授权成本。纯Java OPC UA虽新，但对老旧设备无能为力。Utgard作为开源方案，提供了从底层到上层的控制力，对于需要深度定制或预算有限的团队是首选。
• 社区与稳定性：Utgard虽然已不是最活跃的项目，但其代码经过多年工业现场考验，足够稳定。网络上相关的解决方案、踩坑记录也最为丰富，遇到问题更容易找到参考。

注意：Utgard的核心依赖是opc-utgard-core-xxx.jar和对应的本地库（如win32-x86-64文件夹下的DLL）。它的强项是处理DA协议，对于UA协议则无能为力。如果你的项目面向未来，且服务器端支持UA，应优先评估Eclipse Milo等纯Java UA方案。

3. 环境准备与核心依赖解析

工欲善其事，必先利其器。用Utgard进行开发，远不止是引入一个Jar包那么简单，它涉及Java环境、Windows系统配置和依赖库的协同工作。这一步没做好，后面会步步维艰。

3.1 开发环境与工具链搭建

首先，你需要一个标准的Java开发环境。我推荐使用JDK 8或JDK 11，这两个是长期支持版本，在工业软件环境中兼容性最好。更高版本的JDK（如17+）在理论上可行，但可能需要处理模块化（JPMS）带来的一些额外配置，为避免不必要的麻烦，初期建议使用JDK 8。

IDE方面，IntelliJ IDEA或Eclipse均可。项目管理推荐使用Maven或Gradle来管理依赖，这比手动下载Jar包要方便和可靠得多。以下是一个典型的Mavenpom.xml中对于Utgard依赖的配置：

<dependencies> <!-- Utgard 核心库 --> <dependency> <groupId>org.openscada.utgard</groupId> <artifactId>org.openscada.opc.lib</artifactId> <version>1.7.0</version> <!-- 请注意检查最新版本 --> </dependency> <!-- 日志框架，Utgard内部使用slf4j --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.36</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.2.11</version> </dependency> </dependencies>

关键点解析：org.openscada.opc.lib这个artifact包含了Utgard的核心Java代码。但请注意，光有这个是不够的。这个库在运行时需要对应的本地库（Native Library）。Maven依赖通常不会自动包含这些DLL文件。你需要手动处理。

3.2 本地库（Native Library）的处理：最大的坑

这是Utgard配置中最关键、最容易出错的一步。本地库是JNI调用的桥梁，它包含了与Windows COM组件交互的所有C++代码。

如何获取本地库？

1. 从官方源码编译：从Utgard的源代码仓库（如GitHub）下载项目，其中会有一个jni目录，里面是C++源码。你需要用Visual Studio配置好JNI头文件路径，针对你的系统架构（x86或x64）进行编译，生成对应的.dll文件。这个过程对不熟悉Windows C++开发的Java工程师来说非常不友好。
2. 寻找预编译版本：更实际的做法是，在网络上搜索utgard dll或从一些历史项目、论坛中寻找已经编译好的win32-x86和win32-x86-64文件夹。一个完整的本地库包通常包含opcjerom.dll,jerom.dll,opcjerom64.dll等文件。
3. 使用包含本地库的“全家桶”Jar包：有些第三方打包版本，会将本地库打包进一个独立的Jar文件（如org.openscada.utgard.jerom-xxx.jar），并在其中通过Native.loadLibrary的变体来加载。这是最省事的方式，但需要确认其兼容性和来源可靠性。

如何配置本地库路径？获取到DLL文件后，你需要让Java运行时能够找到它们。有几种方法：

• 方法一：添加到java.library.path：这是最标准的方式。你可以通过JVM启动参数指定：-Djava.library.path=/path/to/your/dlls。或者在代码中设置：System.setProperty("java.library.path", "/path/to/your/dlls");（注意，需要在加载任何Utgard类之前设置，且修改后可能需要重置ClassLoader，不太推荐）。
• 方法二：直接放在系统PATH包含的目录：例如C:\Windows\System32（64位DLL）或C:\Windows\SysWOW64（32位DLL）。但污染系统目录不是好习惯。
• 方法三：使用特定加载器：如果使用“全家桶”Jar包，它内部可能会封装加载逻辑，你只需要确保该Jar在classpath中即可。

实操心得：我个人的做法是，在项目根目录下创建一个lib/native文件夹，将对应系统架构的DLL文件放进去。然后在IDE的运行时配置里，或者最终部署的启动脚本里，明确指定-Djava.library.path=./lib/native。这样清晰、可控，也便于版本管理。

3.3 Windows系统与DCOM配置要点

由于OPC DA基于DCOM，因此运行Java客户端程序的Windows机器需要进行正确的DCOM配置。很多连接失败的问题，根源都在这里。

服务器端（OPC Server所在机器）：

1. 用户权限：确保运行Java客户端程序的Windows账户在OPC服务器机器上具有足够的权限。通常需要将该用户添加到服务器的“DCOM用户”组，或者直接赋予“远程访问”和“启动/激活”权限。
2. DCOM配置：运行dcomcnfg打开组件服务。找到OPC服务器对应的应用程序（如OPC.SimaticNET），在其属性中，确保“安全”选项卡下的“启动和激活权限”、“访问权限”都添加了相应用户并赋予“允许”权限。在“身份验证级别”中，有时需要设置为“无”或“连接”以解决某些防火墙或域策略下的问题。
3. 防火墙：确保135端口（DCOM端口映射服务）以及OPC服务器使用的动态端口范围在防火墙中是开放的。

客户端（Java程序所在机器）： 虽然Utgard作为客户端，DCOM配置要求相对较低，但为了确保万无一失，特别是当OPC服务器和客户端不在同一台机器时，建议也将运行Java程序的账户配置为对OPC服务器有访问权限。

重要提示：DCOM配置非常繁琐且容易出错。在开发和测试初期，一个有效的简化策略是：让OPC服务器和Java客户端运行在同一台Windows机器上。这样可以规避绝大部分网络DCOM配置问题，先确保核心通信逻辑是正确的。等单机调试通后再考虑分布式部署。

4. 核心API详解与连接建立流程

环境配好了，我们开始写代码。Utgard的API设计相对直观，核心是几个类：Server，Group，Item。整个通信流程可以概括为：创建连接 -> 添加组 -> 添加项 -> 读写/订阅。

4.1 建立OPC服务器连接

首先，你需要一个Server对象来代表远端的OPC服务器。

import org.openscada.opc.lib.common.ConnectionInformation; import org.openscada.opc.lib.da.Server; public class OpcDaClient { public static void main(String[] args) throws Exception { // 1. 配置连接信息 ConnectionInformation ci = new ConnectionInformation(); ci.setHost("192.168.1.100"); // OPC服务器所在机器的IP，本地则为"localhost" ci.setDomain(""); // 域名，工作组环境通常为空 ci.setUser("Administrator"); // 有权限的用户名 ci.setPassword("your_password"); // 对应用户的密码 ci.setClsid("F8582CF2-88FB-11D0-B850-00C0F0104305"); // OPC服务器的ProgID对应的CLSID // 2. 创建Server对象 // 第二个参数是 `JarLoader`，用于加载本地库，如果使用系统路径或已配置java.library.path，这里可以传null Server server = new Server(ci, null); try { // 3. 连接服务器 server.connect(); System.out.println("成功连接到OPC服务器！"); // ... 后续操作 } catch (Exception e) { System.err.println("连接失败: " + e.getMessage()); e.printStackTrace(); } finally { // 4. 断开连接 server.dispose(); } } }

关键参数解析：

• setHost: OPC服务器的地址。这是最容易混淆的点。对于本机OPC服务器，填localhost或127.0.0.1。对于远程服务器，填其IP或主机名。
• setClsid: 这是OPC服务器的唯一标识符，一个GUID。如何获取它？有几个方法：
  1. 在OPC服务器软件的文档里找。
  2. 在本机运行dcomcnfg，在组件服务 -> DCOM配置中，找到你的OPC服务器应用程序，右键属性，在“常规”选项卡的“应用程序ID”里可以看到。
  3. 使用OPC客户端测试工具（如OPC Expert、Matrikon OPC Explorer）连接上服务器后，通常能显示出其CLSID。
  4. 对于一些知名服务器，有已知的CLSID，如OPC Simulation Server（一个常用的测试服务器）的CLSID就是上面代码中的F8582CF2-88FB-11D0-B850-00C0F0104305。

实操心得：连接失败时，不要只看Java抛出的异常。首先检查网络是否通畅（ping），然后检查DCOM配置和用户权限。可以先用一个图形化的OPC客户端工具（如免费的“OPC Quick Client”）尝试连接，如果工具能连上而你的程序连不上，那问题大概率出在你的程序配置或DCOM权限细节上；如果工具也连不上，那问题就在服务器端或网络配置上。

4.2 创建数据组（Group）与数据项（Item）

成功连接服务器后，我们需要创建“组”（Group）和“项”（Item）。组是项的容器，可以统一管理项的数据更新周期、激活状态等。

// 假设server已成功连接 // 1. 添加一个组 // 参数：组名，是否激活，更新周期（毫秒），死区（Deadband，对于模拟量有效，通常为0.0f） AutoReconnectController groupController = new AutoReconnectController(server); Group group = groupController.addGroup("MyGroup"); group.setActive(true); // 激活组，开始更新数据 // 2. 在组内添加数据项 // 参数：项名（Item ID），是否激活，项的客户端句柄（自定义，用于回调识别） String itemId = "Channel1.Device1.Tag1"; // 这是关键！需要从OPC服务器获取正确的Item ID Item item = group.addItem(itemId, true, 1); // 3. 同步读取一次项的值 ItemState state = item.read(false).get(); // get()会阻塞直到读取完成 System.out.println("Item值: " + state.getValue() + ", 质量: " + state.getQuality() + ", 时间戳: " + state.getTimestamp());

核心概念解析：

• Item ID：这是OPC服务器内部对某个具体数据点（如PLC的DB1.DBD0）的标识符。它没有统一标准，完全取决于OPC服务器的实现。对于西门子Simatic NET，可能是S7:[S7 connection_1]DB1,DBD0；对于Kepware，可能是Channel1.Device1.Tag1。获取正确Item ID的最佳方式是使用OPC客户端测试工具去浏览（Browse）服务器，找到你需要的点，复制它的ID。
• AutoReconnectController：这是一个非常实用的工具类。它包装了Group，提供了自动重连机制。在网络闪断或服务器重启时，它能尝试自动恢复组和项的订阅，大大增强了程序的健壮性。强烈建议在生产环境中使用它。
• 死区（Deadband）：仅对模拟量项有效。例如，死区设为0.1，表示只有当数据变化超过原值的±0.1%时，才会触发数据变更回调。这可以有效减少网络流量和CPU占用，对于变化缓慢的工艺参数（如室温）非常有用。

5. 数据读写与异步订阅模式实战

一次性读取（read）适用于配置或偶尔查询。对于实时监控，我们需要订阅（Subscribe）模式，让服务器在数据变化时主动通知我们。

5.1 异步订阅与回调处理

这是OPC DA客户端最核心的功能。Utgard通过添加ItemStateListener来接收数据变更通知。

// 为Item添加状态监听器 item.addItemStateListener(new ItemStateListener() { @Override public void itemStateChanged(Item item, ItemState state) { // 当Item的值、质量或时间戳发生变化时，此方法被回调 Object value = state.getValue(); short quality = state.getQuality(); Date timestamp = state.getTimestamp(); // 质量码解读：0xC0 (192) 表示“良好” if (quality == 0xC0) { System.out.println(String.format("[%s] %s = %s", new SimpleDateFormat("HH:mm:ss.SSS").format(timestamp), item.getId(), value)); // 在这里处理有效数据：存入数据库、发送消息等... } else { System.err.println(String.format("数据质量不佳: %s, 质量码: 0x%02X", item.getId(), quality)); // 处理坏质量数据，可能需要进行数据替代或报警 } } }); // 为了演示，让主线程等待一段时间 Thread.sleep(30000);

质量码（Quality）处理要点： OPC数据质量码是一个非常重要的概念，它告诉你这个数据值是否可靠。0xC0(Good) 是最常见的“良好”状态。其他常见状态如0x00(Bad)，0x04(Config Error)，0x08(Not Connected) 等。在生产代码中，必须对质量码进行判断，不能直接使用坏质量的数据，否则可能导致错误的业务逻辑。

5.2 同步写操作

除了读，我们有时也需要向PLC写入设定值或控制命令。

// 假设要写入一个布尔值（开关量） String writeItemId = "Channel1.Device1.DO1"; Item writeItem = group.addItem(writeItemId, true, 2); // 为写操作单独添加一个Item // 准备要写入的值 Object valueToWrite = true; // 可以是Boolean, Integer, Float, Double, String等 try { // 同步写入 WriteResult result = writeItem.write(valueToWrite).get(); if (result.getErrorCode() == 0) { System.out.println("写入成功"); } else { System.err.println("写入失败，错误码: " + result.getErrorCode()); } } catch (InterruptedException | ExecutionException e) { System.err.println("写入过程发生异常: " + e.getMessage()); }

写入注意事项：

1. 数据类型匹配：写入的值类型必须与OPC服务器中定义的Item数据类型兼容。如果不确定，可以先读取一次，看看返回值的类型。
2. 权限：确保OPC服务器和底层设备允许写入操作。有些Item可能是只读的。
3. 副作用：写入操作可能直接改变现场设备的状态（如启动电机），务必谨慎，最好有确认和联锁逻辑。

5.3 组的管理与优化

一个组可以管理多个Item。组的参数设置会影响组内所有Item的行为。

// 设置组属性 group.setActive(true); // 激活组，开始数据更新 group.setUpdateRate(500); // 设置客户端请求的更新周期为500ms（服务器可能不严格遵守） // group.setDeadband(0.05f); // 设置全组模拟量项的默认死区为0.05% // 批量添加Item Map<String, Integer> itemMap = new HashMap<>(); itemMap.put("Tag1", 101); itemMap.put("Tag2", 102); itemMap.put("Tag3", 103); Map<Item, Integer> addedItems = group.addItems(itemMap); // 批量移除Item group.removeItems(addedItems.keySet());

优化建议：

• 分组策略：将更新频率相近、业务关联性强的Item放在同一个组里。例如，所有1秒更新一次的工艺参数放一个组，所有10秒更新一次的设备状态放另一个组。
• 更新周期：setUpdateRate是客户端向服务器请求的周期，但服务器有自己的最小更新周期和内部处理逻辑。不要设置得过快（如小于100ms），以免给服务器造成不必要的负担。根据实际工艺需求合理设置。
• 适时激活/去激活：如果某个组的数据暂时不需要，可以将其设为setActive(false)，以节省服务器和网络资源。

6. 生产环境下的高级议题与稳定性设计

把Demo跑通只是第一步。要把Utgard用到7x24小时运行的生产系统中，我们必须考虑更多。

6.1 连接管理与自动重连

网络是不稳定的，服务器可能重启。一个健壮的客户端必须具备自动重连能力。AutoReconnectController已经为我们做了很多工作，但我们还需要在应用层进行封装。

public class RobustOpcClient { private Server server; private AutoReconnectController groupController; private ConnectionInformation ci; private ScheduledExecutorService scheduler; private volatile boolean running = false; public void start() { running = true; scheduler = Executors.newSingleThreadScheduledExecutor(); ci = new ConnectionInformation(); // ... 配置ci server = new Server(ci, null); groupController = new AutoReconnectController(server); // 启动一个定时任务，周期性检查连接状态并尝试重连 scheduler.scheduleAtFixedRate(this::checkAndReconnect, 30, 30, TimeUnit.SECONDS); try { server.connect(); initializeGroupsAndItems(); // 初始化组和项 } catch (Exception e) { log.error("初始连接失败，将在重试任务中处理", e); } } private void checkAndReconnect() { if (!running) return; // 这里可以检查server.getState()，或者通过一个心跳Item来判断连接是否存活 if (!isConnectionAlive()) { log.warn("连接丢失，尝试重连..."); try { // 先清理旧状态 groupController.clear(); if (server.getState() == ServerState.CONNECTED) { server.disconnect(); } Thread.sleep(2000); // 等待一会儿再重连 server.connect(); initializeGroupsAndItems(); // 重新初始化 log.info("重连成功"); } catch (Exception e) { log.error("重连失败", e); } } } private boolean isConnectionAlive() { // 实现一个简单的心跳检查，例如尝试读取一个特定的、总是存在的Item // 或者检查 server.getState() return server.getState() == ServerState.CONNECTED; } public void stop() { running = false; scheduler.shutdown(); groupController.clear(); server.disconnect(); server.dispose(); } }

6.2 异常处理与资源释放

OPC连接、Group、Item都是宝贵的资源，必须确保在程序关闭、连接断开时被正确释放。

• dispose()vsdisconnect()：Server对象有这两个方法。disconnect()断开网络连接，但可能保留一些内部状态。dispose()会彻底释放所有资源，包括JNI层面的资源。在程序最终退出时，应调用dispose()。
• 使用Try-with-Resources模式：虽然Utgard的核心类没有实现AutoCloseable，但我们可以自己封装，或者在finally块中确保调用stop()或dispose()方法。
• 监听连接状态：Server对象可以添加ServerStateListener，监听连接状态的变化（如断开、连接），以便及时更新UI或触发重连逻辑。

6.3 性能监控与调优

当采集点数成百上千时，性能变得关键。

• 线程模型：Utgard内部有自己的线程池来处理回调。注意，ItemStateListener的itemStateChanged方法是在Utgard的内部线程中调用的。不要在这个回调方法中执行耗时操作（如复杂的数据库插入），否则会阻塞其他数据的回调。应该将数据快速放入一个内存队列，由另一个工作线程异步处理。
• JVM内存：长时间运行、高频数据采集可能产生大量临时对象。确保JVM堆空间足够（-Xmx），并监控GC情况。考虑对采集到的数据进行批处理后再持久化。
• 网络流量：过多的Item和过快的更新速率会导致网络流量大增。合理使用死区（Deadband）是减少无效数据传输的最有效手段。

7. 常见问题排查与实战技巧实录

下面是我在多年项目中遇到的典型问题及解决方案，希望能帮你少走弯路。

7.1 连接类问题

7.2 数据读写类问题

7.3 稳定性与性能类问题

• 内存泄漏：长时间运行后内存持续增长。确保在移除Item、Group或断开连接后，没有其他地方持有对这些对象的强引用。特别是自定义的ItemStateListener，要在不需要时调用item.removeItemStateListener。
• CPU占用过高：检查更新周期是否设置过短，以及回调函数itemStateChanged中的处理逻辑是否太重。避免在回调中做同步IO操作。
• “僵尸连接”：网络异常断开后，服务器端可能认为连接还在。在客户端重连逻辑中，确保先调用disconnect()或dispose()清理旧连接。

一个关键的调试技巧：在启动JVM时，添加-Dorg.openscada.opc.lib.debug=true参数，可以让Utgard打印出非常详细的底层通信日志，对于排查复杂的连接和数据问题有奇效。不过日志量会很大，建议仅在调试时开启。

最后，我想再强调一下技术选型的思考。Utgard是解决Java与传统OPC DA服务器通信的利器，但它基于陈旧的COM/DCOM技术，配置复杂，跨网络问题多。对于新项目，如果条件允许，应极力推动使用OPC UA。OPC UA使用标准TCP/HTTP(s)，安全模型完善，跨平台支持好，是工业互联网和物联网的标准协议。Java有Eclipse Milo这样优秀的开源UA客户端库，学习和使用曲线比Utgard平滑得多。将Utgard作为接入遗留系统的过渡方案，同时规划向OPC UA迁移，是一个更可持续的技术策略。

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