如果你穿越回 1874 年之前，想给远方的朋友寄一封信，得先翻遍各国手册：法国的邮资怎么算？德国的信封怎么写？俄国的邮票贴哪里？每换一个国家，规矩全变。直到万国邮政联盟成立，统一了国际邮件的信封规格、地址格式和邮资规则——从此，在任何一个成员国寄信，全世界都能看懂。今天的工业现场，正在上演同一出戏。走进车间，Modbus 电表用寄存器喊话，Profinet 伺服按 I/O 槽位传参，CANopen 机器人广播报文……它们像说着不同方言的部落，彼此听不懂。想互通？过去只能两两架设翻译网关，设备一多链路爆炸。OPC UA 就是工业界的“万国邮联”：它统一了数据描述（信息模型）、对话礼仪（客户端/服务端）、消息投递（发布订阅）和身份互信（安全证书）。学会这套“普通话”，任何设备都能和整个世界对话。接下来，我们就顺着“邮联”这条线，把 OPC UA 拆开讲透。

岗位关联

掌握 OPC UA，就掌握了工业互联的“通用语言”。无论做数字孪生、设备上云还是产线智能化，你都能让不同厂商的设备在同一语义世界里高效对话——这是方案工程师与系统集成商的核心竞争力。

目录
  1. 可视化演示
  2. 协议困局：巴别塔下的众声喧哗
  3. 信息模型：给每台设备办一张“标准户口本”
  4. 客户端与服务端：邮局柜台的外交礼仪
  5. 发布订阅：从挨家敲门到订阅报纸
  6. 安全与证书：护照、签证与防拆封邮包
  7. 协议横评：方言各有用途，谁能当世界语
  8. 网关与落地：先请翻译官，再教普通话
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

工业现场设备协议五花八门，OPC UA想用一套标准把它们统一接入，实现跨平台跨厂商互联。你会了解它的信息模型、... 切换模式查看不同维度。

本节配有交互动效（进入视口后自动加载，约 3KB）。

OPC UA：核心原理 动态展示关键流程与数据流动 交互控件调节参数实时渲染 f(x) = transform(x) 核心概念的可视化呈现

协议困局：巴别塔下的众声喧哗

在万国邮联成立之前，跨国寄信是一件令人头大的事：法国的邮资算法、德国的信封规格、俄国的邮票位置，每换一个国家就要重学一套规矩，寄一封信要翻三本手册。今天的工业现场，就是那个“前邮联时代”——Modbus 电表按寄存器号报数，Profinet 伺服按 I/O 槽位传参，CANopen 机器人按对象字典广播报文。它们各有各的“语法”，却谁也听不懂谁。

这些协议并非故意制造混乱：它们诞生于不同年代，服务不同需求。串口时代的 Modbus 追求简单可靠，总线时代的 Profinet 追求高速实时，分布式时代的 CANopen 追求灵活组网。矛盾在于，工厂一旦引入多家设备，它们之间就得“两两对话”，而每一对对话都需要一台专属翻译网关。5 台设备要 10 条链路，50 台设备要 1225 条——链路数量不是线性增长，而是平方级爆炸。

OPC UA 要做的，正是当年万国邮联做的事：与其维护 1225 条“私线”，不如让每台设备学会同一种国际信封规矩——只连一条线到统一邮局，剩下的事交给标准。

Cn2=n(n−1)2\displaystyle C_n^2 = \frac{n(n-1)}{2}
这个式子算的是“n 台设备互相通信需要多少条专用链路”：设备越多，链路爆炸得越快。6 台设备就需要 15 条。
  1. 组合数 \(C_n^2\)从 n 台设备中任选两台配对互联，所有“两两组合”的方案总数，读作“n 选 2”。
    Cn2C_n^2
  2. 分子 \(n(n-1)\)第一台设备有 n 种选择，第二台剩 n-1 种，先按有顺序的方式数出所有配对。
    n(n−1)n(n-1)
  3. 分母除以 2A 对 B 和 B 对 A 是同一条物理链路，去掉重复，得到最终链路数。
    n(n−1)2\frac{n(n-1)}{2}
  4. 代入实例6 台设备需要 15 条专用翻译链路，每一条都要单独维护地址映射和报文解析。
    C62=6×52=15C_6^2 = \frac{6 \times 5}{2} = 15

信息模型：给每台设备办一张“标准户口本”

邮联做的第一件大事，是把信封格式和地址写法统一起来。只要你按规矩写地址，哪怕投递员从没见过你，也能把信准确送达。在 OPC UA 的世界里，这套“信封规矩”叫信息模型——它规定了设备的数据应该长什么样、摆在哪里、怎么被读懂。

在 OPC UA 中，设备上的每一个数据点都被表达为一个“节点”（Node）。节点有四个关键要素：NodeId 是全局唯一的“身份证号”，BrowseName 是给人看的名字，NodeClass 标明它是对象、变量还是方法，References 则描述它与其他节点的关系。比如“1 号电机转速”就是一个变量节点，挂在“1 号电机”这个对象节点之下。

所有节点共同组成一棵庞大的“语义树”，叫地址空间（AddressSpace）。设备接入后，在自己的子树里挂上标准节点；上层应用只要顺着树浏览，就能知道“这个值是温度、单位是摄氏度、量程是 0 到 100”，完全不需要事先翻阅厂商手册。这就是跨厂商“语义互认”的基础。

有了这本“标准户口本”，上层应用再也不关心数据来自 Modbus 还是 Profinet——它看到的，是一本本格式完全相同的户口本，这就是信息模型的意义。

M:Ddevice→AUA\displaystyle \mathcal{M}: D_{\text{device}} \to A_{\text{UA}}
这个公式表示：设备原始数据集合 \(D\)，经过信息建模映射 \(\mathcal{M}\)，进入统一的 UA 地址空间 \(A\)。映射做得越完整，上层读到的语义就越准确。
  1. 设备数据域 \(D_{\text{device}}\)Modbus 寄存器、Profinet I/O 槽位、CANopen 对象字典等原始数据集合，只有编号没有语义。
    DdeviceD_{\text{device}}
  2. 映射规则 \(\mathcal{M}\)把原始数据“翻译并登记”成 UA 节点的规则，包括命名、类型、单位和引用关系。
    M\mathcal{M}
  3. UA 地址空间 \(A_{\text{UA}}\)所有映射后节点组成的统一语义网络，任何客户端都能浏览和定位数据。
    AUAA_{\text{UA}}

客户端与服务端：邮局柜台的外交礼仪

邮联不仅统一了信封，还统一了办事流程：取号、递单、盖章、回执。在 OPC UA 里，这套流程由客户端（Client）和服务端（Server）共同演绎，很像邮局柜台的“外交礼仪”。

所谓服务端，就是持有信息模型、等待被访问的一方——它像邮局柜台，把地址空间“摆”出来供人查阅；客户端则是主动发起访问的一方——它像寄件人，先取号（建立连接），再递单（发起请求），最后拿回执（接收响应）。角色分工非常严格：永远由客户端发起会话，服务端只负责应答。

连接建立后，双方进入“会话”（Session）状态。在会话中，客户端可以浏览地址空间（像翻看邮局的服务目录，发现有哪些节点）、调用服务（读、写、订阅数据）、接收变更通知。整个过程使用统一的消息格式，就像柜台前排队的每个人都拿着同一种单据，窗口不会“鸡同鸭讲”。

柜台礼仪一旦统一，任何“国家”的设备走进邮局都能顺畅办业务——这正是客户端/服务端架构想要达到的效果：不管你从哪里来，规矩只有一个。

T响应=T网络+T处理+T解析\displaystyle T_{\text{响应}} = T_{\text{网络}} + T_{\text{处理}} + T_{\text{解析}}
一次读写的总耗时由三部分构成：网络传输、服务端处理、客户端解析。优化任何一段，都能让“办业务”更快。
  1. 网络时延 \(T_{\text{网络}}\)请求与响应在链路上的传输时间，受距离、带宽和负荷影响。
    T网络T_{\text{网络}}
  2. 处理时延 \(T_{\text{处理}}\)服务端在地址空间中定位节点、执行读写服务所花的时间。
    T处理T_{\text{处理}}
  3. 解析时延 \(T_{\text{解析}}\)客户端把二进制报文解码为可读数据结构的开销。
    T解析T_{\text{解析}}

发布订阅：从挨家敲门到订阅报纸

邮局时代以前，想知道远方发生了什么事，只能派人跑腿去问；有了报纸和订阅制度，报社一出版就自动送上门。OPC UA 的发布订阅（Pub/Sub）机制，就是工业界的“订报”。

先说轮询的痛点。传统的客户端/服务端模式下，客户端每隔固定周期就要挨个问设备：“有数据变化吗？”——哪怕数值纹丝不动，也要来回跑一趟。设备一多、频率一高，网络被大量“无效问询”占满，响应还慢半拍。这就像每天派人挨家敲门问“今天的报纸来了吗”，又烦人又浪费。

发布订阅彻底改变了这个模式。设备作为发布者（Publisher），只在数据变化时“出版”一次；订阅者（Subscriber）事先登记兴趣，之后坐等推送。中间由消息代理（Broker）负责转发，一份消息可以同时送达多个订阅者。事件驱动的理念让通信从“被动被要”变成“主动送达”——消息量大幅下降，时效性反而提升，特别适合几百台设备的高频采集场景。

从“敲门问”到“订报纸”，消息从被动被取变成主动送达——这也是 OPC UA 能走出车间局域网、通向云端和海量设备的关键一步。

τ平均等待=T轮询周期2\displaystyle \tau_{\text{平均等待}} = \frac{T_{\text{轮询周期}}}{2}
轮询模式下，事件总在两次询问之间随机发生，平均要等半个周期才被发现；而发布订阅在事件发生的瞬间就推送，等待时间趋近于零。
  1. 轮询周期 \(T_{\text{轮询周期}}\)客户端每隔固定时间 T 询问一次设备，T 越小越及时、开销越大。
    T轮询周期T_{\text{轮询周期}}
  2. 平均等待 \(\tau_{\text{平均等待}}\)事件可能落在两次轮询之间的任意时刻，平均等待时长为半个周期。
    τ平均等待\tau_{\text{平均等待}}
  3. 发布订阅的等待事件触发即推送，等待时间趋近于零，且无需浪费无效问询。
    τpub≈0\tau_{\text{pub}} \approx 0

安全与证书：护照、签证与防拆封邮包

万国邮联之所以能让各国互信，靠的是互相承认的护照和签证。OPC UA 的安全体系，就是工业设备界的“护照系统”。

每一台支持 OPC UA 的设备都持有一张数字证书，相当于护照——上面写着“我是谁、属于哪家企业、由谁签发”。证书不是自己印的，而是由权威机构 CA（相当于签证处）签发。两台设备通信前先互验护照：A 信不信 B，取决于 A 是否信任签发 B 护照的那家 CA。这就是“证书信任链”。

验明正身之后，还有三道保护。第一是加密传输：数据进入信道前被装进“防拆封邮包”，路上被窃听也看不懂；第二是消息签名：收件人拆封前先验证封条，任何一位被改动都会报警；第三是访问控制：即使你持有护照进了邮局，也不代表能进金库——每个节点的读写权限由管理员单独配置。

有了护照、封条和金库门禁，工厂数据才敢放心地从车间一路送到云端——否则“统一通信”就等于把公司机密装进敞口邮包，谁都能顺手翻开。

Verify(PK,S,M)→{0,1}\displaystyle \text{Verify}(PK, S, M) \to \{0, 1\}
这条式子描述“验护照”的过程：接收方用公钥 \(PK\) 验证消息 \(M\) 的签名 \(S\)，结果要么是 1（可信），要么是 0（拒收）。
  1. 公钥 \(PK\)对方公开的钥匙，任何人都能拿到，但只有配对的私钥才能产生有效签名。
    PKPK
  2. 签名 \(S\)发送方用私钥对消息摘要加密生成的“防伪封条”，内容被改一丁点都验不过。
    SS
  3. 验证结果 \(\{0, 1\}\)验证函数输出 1 表示身份可信、内容完好；输出 0 则拒绝通信。
    Verify(PK,S,M)→1\text{Verify}(PK, S, M) \to 1

协议横评：方言各有用途，谁能当世界语

邮联的初衷不是消灭方言——村里人聊天照样说家乡话。它只提供一种“国际场合通用语”。OPC UA 同样不是来取代 Modbus 或 Profinet 的，而是让它们在各自岗位上干好活，再通过统一语言互通。

先看 Modbus。它像电报：报文极简、硬件便宜、二十年前的老设备里到处都是，可靠性经过数十年验证。但它的表达能力太弱——只有一个寄存器编号，没有“温度”“压力”这样的语义，而且采用轮询模式，接入设备一多，扫描周期急剧拉长。

再看 Profinet。它像铁路专线：带宽高、实时性好，特别适合伺服驱动这类需要精确定时的运动控制。但它是“专属轨距”的标准，跨厂商、跨系统的信息集成能力弱。OPC UA 则像邮联的通用信封：它不追求毫秒级实时，却最擅长在 OT（运营技术）与 IT（信息技术）的交汇处架桥——设备数据上云、数字孪生、MES/ERP 集成，都是它的主场。

结论很清楚：现场底层继续用电报和铁路专线保证实时控制，跨系统集成则交给邮联标准——选型不是比谁更强，而是看你在哪一层说话。

T扫描=N×(T帧+T应答)\displaystyle T_{\text{扫描}} = N \times (T_{\text{帧}} + T_{\text{应答}})
Modbus 是一台一台轮询的：扫描周期等于设备数乘以单台响应时间。设备越多，数据刷新越慢，这是它难以大规模扩展的数学根源。
  1. 设备数 \(N\)挂在 Modbus 链路上的从站数量，N 每增加一台，周期就线性变长。
    NN
  2. 单台耗时 \(T_{\text{帧}} + T_{\text{应答}}\)主站发一帧请求加上等待从站回复的总时间。
    T帧+T应答T_{\text{帧}} + T_{\text{应答}}
  3. 扫描周期 \(T_{\text{扫描}}\)依次轮询完所有设备需要的总时长，决定了数据刷新率的上限。
    T扫描T_{\text{扫描}}
  4. 代入数值100 台设备、单台 40 毫秒，一轮扫描要 4 秒钟——很多实时需求早就等不及了。
    T扫描=100×40 ms=4 sT_{\text{扫描}} = 100 \times 40\,\text{ms} = 4\,\text{s}

网关与落地：先请翻译官，再教普通话

邮联成立初期，不是所有人都立刻学会通用语——各国先雇翻译官过渡。工业现场也一样，存量设备大多不会“说” OPC UA，解决过渡问题的关键角色就是网关，那个忙前忙后的“翻译官”。

协议转换网关（例如 Modbus→OPC UA）要做两件事。第一是报文翻译：把 Modbus 的读寄存器请求，翻译成 OPC UA 的读服务调用。第二是信息建模：把寄存器 40001 映射成“温度”节点，带上单位和量程。这两步缺一不可——只做第一步，上层应用拿到的还是无意义的编号，只是换了口音继续喊电报码。

落地之路通常分四步：盘点是第一步，摸清现场有哪些协议、哪些设备需要接入；第二步选型，确定用网关还是直接换支持 OPC UA 的新设备；第三步建模，设计信息模型与地址空间，这是最费心思的环节；第四步部署与联调，配置证书权限，验证数据流。典型的落地场景包括产线数据上云、数字孪生底座搭建和设备预测性维护。

翻译官终究是过渡方案。长远来看，新设备原生支持 OPC UA 才是正道——就像新一代人直接学普通话，从此不再需要翻译。

x1≠x2⇒G(x1)≠G(x2)\displaystyle x_1 \neq x_2 \Rightarrow G(x_1) \neq G(x_2)
这句话说的是网关映射的“单射”要求：两台设备上传的不同原始数据，翻译之后绝不能撞成同一个值，否则上层会把两台设备的数据混为一谈。
  1. 源数据 \(x_1, x_2\)两台设备上传的原始报文，可能来自寄存器或 I/O 槽位。
    x1≠x2x_1 \neq x_2
  2. 映射函数 \(G\)网关执行的“翻译 + 建模”规则，把原始数据变换为 UA 节点值。
    G(x1), G(x2)G(x_1),\, G(x_2)
  3. 单射条件不同源数据必须映射到不同结果，这是网关数据保真的最低要求，映射表设计时要逐一核对。
    G(x1)≠G(x2)G(x_1) \neq G(x_2)

AI 应用场景

数字孪生的实时数据底座

阶段：数据采集与预处理

解决的问题：数字孪生要同时“喂养”几十类设备数据。传统做法是为每类设备写专属采集驱动，改一个型号就要重写一遍，数据到了模型里还各说各话。用 OPC UA 统一信息模型后，所有设备以标准节点暴露温度、振动、产量等数据，数字孪生平台按统一语义消费数据，新设备接入只需建模映射，不再动平台代码。

具体案例：某汽车工厂搭建产线数字孪生，原计划每种 PLC 写一个采集驱动，预计 90 天；改为边缘网关统一转成 OPC UA 后，40 天完成 15 条产线接入，温度、节拍、能耗在孪生界面实时联动。

设备上云与预测性维护

阶段：模型训练与在线推理的数据管道

解决的问题：预测性维护模型需要高频振动、温度等多源数据持续入池。直接用 Modbus 轮询上云，带宽和语义都撑不住。OPC UA 的发布订阅让设备“变化才上报”，证书机制保证数据从车间到云端一路可信，AI 平台拿到的是带单位、带时间戳的语义化数据。

具体案例：某风电集团把 200 台机组经协议网关接入 OPC UA，订阅齿轮箱振动特征值；云端 LSTM 模型用实时流做剩余寿命预测，误报率比原来“裸寄存器上报+靠猜单位”方案下降 60%。

存量产线智能化改造

阶段：边缘推理与系统集成

解决的问题：老产线设备不支持新协议，直接换设备成本太高。OPC UA 网关让“翻译官”上场：老 PLC 继续跑，网关做协议转换与建模，新上位的 MES/云平台通过统一接口取数，实现透明化生产。

具体案例：某注塑车间 30 台老旧注塑机通过 Modbus→OPC UA 网关接入 MES，换型时间、温度曲线实时可见，排产优化后单件能耗下降 12%。

Python 演示

python92 行
# -*- coding: utf-8 -*-# OPC UA gateway simulation: map devices from different protocols into one unified modelimport time  class ModbusDevice:    # old telegram-style device: data hidden in register addresses    def __init__(self, dev_id, registers):        self._dev_id = dev_id        self._registers = registers     def read_register(self, addr):        return self._registers.get(addr, 0)  class ProfinetDevice:    # dedicated-rail device: data located by IO slot number    def __init__(self, dev_id, io_data):        self._dev_id = dev_id        self._io_data = io_data     def read_input(self, slot):        return self._io_data.get(slot, 0)  class UANode:    # unified node: every data point gets a standard "household register"    def __init__(self, node_id, browse_name):        self.node_id = node_id        self.browse_name = browse_name        self.value = None     def write(self, value):        old = self.value        self.value = value        return old  class UAGateway:    # universal post office: register read functions, build unified address space    def __init__(self):        self._nodes = {}        self._sync_count = 0     def add_mapping(self, node_id, browse_name, read_fn):        # translate one device read action into one UA node        node = UANode(node_id, browse_name)        self._nodes[node_id] = (node, read_fn)        return node     def sync_all(self):        # poll every mapping, refresh changed nodes, return the change count        changed = 0        for node_id, (node, read_fn) in self._nodes.items():            new_val = read_fn()            if node.write(new_val) != new_val:                changed += 1        self._sync_count += 1        return changed     def read(self, node_id):        return self._nodes[node_id][0].value  def main():    mb = ModbusDevice(1, {40001: 35, 40002: 78})    pn = ProfinetDevice(2, {1: 220, 2: 380})    gw = UAGateway()     gw.add_mapping("ns=1;s=Line1/MB/Temp", "Line1_MB_Temp",                   lambda: mb.read_register(40001))    gw.add_mapping("ns=1;s=Line1/MB/Volt", "Line1_MB_Volt",                   lambda: mb.read_register(40002))    gw.add_mapping("ns=1;s=Line1/PN/Speed", "Line1_PN_Speed",                   lambda: pn.read_input(1))    gw.add_mapping("ns=1;s=Line1/PN/Power", "Line1_PN_Power",                   lambda: pn.read_input(2))     for i in range(3):        changed = gw.sync_all()        print("Round {}: temp={} volt={} speed={} power={} changed={}".format(            i + 1,            gw.read("ns=1;s=Line1/MB/Temp"),            gw.read("ns=1;s=Line1/MB/Volt"),            gw.read("ns=1;s=Line1/PN/Speed"),            gw.read("ns=1;s=Line1/PN/Power"),            changed))        time.sleep(0.3)  if __name__ == "__main__":    main()
目的：演示 OPC UA 网关的核心思想——把两类“方言设备”（Modbus 寄存器、Profinet I/O 槽位）的读取动作，映射成统一信息模型节点，上层只与“标准户口本”打交道。
  1. class ModbusDevice:定义“电报型”设备，数据藏在寄存器编号里，只能按地址抄录。
  2. def read_register(self, addr):模拟 Modbus 的读寄存器服务，返回一个整数值。
  3. def add_mapping(self, node_id, browse_name, read_fn):网关核心入口：把“设备读取动作”翻译登记成一个 UA 节点。
  4. self._nodes[node_id] = (node, read_fn)建好“户口本索引”：凭 NodeId 就能找到节点和它的取数函数。
  5. def sync_all(self):定时遍历所有映射，轮询各设备最新值，是网关的采集心脏。
  6. if node.write(new_val) != new_val:先写再看有无变化，返回变更计数，体现“只报变化”的订阅思路雏形。
  7. mb.read_register(40001)把 40001 寄存器“翻译”成语义节点的取数动作：这是信息建模，不只是抄数。
  8. changed = gw.sync_all()一次批量同步，返回本轮变更次数，模拟网关的周期采集。

常见误区

误区“OPC UA 不就是 OPC DA 换了新名字嘛，把接口从 COM 换一换就完事了，老项目随便迁移就行。”

正解OPC UA 是从底到顶重写的体系：不再依赖 Windows 的 COM/DCOM，能跨平台跑到 Linux 工控机和云服务器；自带信息模型、内建安全机制、支持发布订阅……它连“信封”和“邮局”都是新建的，而不是给旧信封换了个邮票。

为何常见：名字都以 OPC 开头，官方又强调兼容迁移路径，容易让人以为只是版本号变化。

误区“OPC UA 就是个替代组态软件的通信口，一台 PLC 对接一台电脑的数据采集，仅此而已。”

正解OPC UA 的地址空间和消息机制决定它可以端到端贯穿：传感器经网关接入、车间服务器汇聚、云端平台订阅，还能做数字孪生数据底座。它更像“国际邮联”而不只是一条邮路。

为何常见：早期教程多展示“上位机读 PLC”一个场景，造成视野局限。

误区“OPC UA 这么强大，把车间里所有实时控制都交给它就好了，还要 EtherCAT 干什么？”

正解标准 OPC UA 面向企业级与厂级通信，实时性弱于专用运动控制总线。它适合毫秒级采集与互操作；硬实时运动控制仍由 EtherCAT、Profinet IRT 等承担。彼此是分工关系，不是取代关系。

为何常见：看到发布订阅和时间敏感网络的报道，误以为 OPC UA 已具备工业级硬实时能力。

误区“拿个 Modbus 转 OPC UA 网关，把寄存器号抄过去就完事，上层自然就懂了。”

正解报文转换只是第一层。更关键的是信息建模：把 40001 寄存器映射成“温度”这个带单位、带语义的节点，并放入统一地址空间。否则上层应用仍看不懂，只是换了种口音继续喊编码。

为何常见：网关配置界面常只显示“寄存器映射表”，让人误以为数值搬运即完成全部工作。

面试题

Q1. OPC UA 在工业互联中的角色，最恰当的比喻是？

单选题 · easy

  • A.车间里的高速运货传送带
  • B.工业界的“万国邮联”标准← 正确答案
  • C.一种新的 PLC 编程语言
  • D.替代所有现场总线的硬件

答案：B。OPC UA 统一数据描述与通信规则，让不同协议的设备在同一个语义世界里互通，正如万国邮联统一国际邮件规则。传送带比喻强调速度，PLC 语言和硬件替代都不是它的定位。

Q2. OPC UA 信息模型中，用于唯一标识一个节点的字段是？

单选题 · easy

  • A.NodeId 节点编号← 正确答案
  • B.BrowseName 浏览名
  • C.Value 数值字段
  • D.Timestamp 时间戳

答案：A。NodeId 是节点在地址空间中的唯一“身份证号”，程序靠它定位数据；BrowseName 只是给人看的名字，允许重复；Value 和 Timestamp 是节点属性而非标识。

Q3. 在客户端/服务端架构中，谁主动发起会话连接？

单选题 · easy

  • A.由服务端主动发起
  • B.由客户端主动发起← 正确答案
  • C.双方同时发起即可
  • D.由网关仲裁决定

答案：B。在客户端/服务端架构中，客户端扮演“访客”，负责发起连接并调用读写信服务；服务端像“使馆”被动监听，永远等待客户端先开口。

Q4. 发布订阅相比轮询最核心的优势是？

单选题 · mid

  • A.网络开销一定降为零
  • B.数据变化后主动推送更及时← 正确答案
  • C.完全不需要任何网络连接
  • D.能替代全部的通信模式

答案：B。订阅像订报纸：数据一变化就主动推送，避免轮询的周期性空跑和平均半周期的等待。“开销为零”和“不需要网络”都不现实，订阅也不能取代请求响应，两者场景不同。

Q5. OPC UA 安全机制中，数字证书主要用于？

单选题 · mid

  • A.提高设备之间的传输速率
  • B.验证设备身份实现信任互认← 正确答案
  • C.压缩报文减少网络流量
  • D.为每个节点分配唯一编号

答案：B。证书就是设备的“护照”，由 CA 签发，通信双方先互验身份再谈业务。它不负责提速、压缩或编号——那些是网络层和信息模型的事。

Q6. 与 OPC Classic（OPC DA）相比，OPC UA 的本质区别是？

单选题 · mid

  • A.仅仅是连接端口的重新选择
  • B.重写体系并内建模型与安全← 正确答案
  • C.只是增加了发布订阅的能力
  • D.优化了 Windows 下的兼容性

答案：B。OPC UA 摒弃了 OPC Classic 依赖 Windows COM/DCOM 的老底子，从传输、建模到安全全面重写，能在 Linux 和云端运行。它不是换个端口或加个功能，而是一次体系级重构。

Q7. 使用网关把 Modbus 设备接入 OPC UA 时，仅做报文转换会遇到什么问题？

单选题 · hard

  • A.转换之后设备的响应必然减慢
  • B.寄存器编号丢失语义难以理解← 正确答案
  • C.串口设备无法进行任何数据转换
  • D.转换过程几乎不消耗任何资源

答案：B。寄存器 40001 只是“电报号码”，没有语义。只做报文转换，上层拿到编号仍不知道是温度还是压力；必须配合信息建模，把寄存器映射成语义节点，才能真正“读懂”。

Q8. 下列哪些属于 OPC UA 提供的安全能力？

多选题 · mid

  • A.设备证书的互相验证← 正确答案
  • B.应用层数据的加密传输← 正确答案
  • C.消息数字签名防篡改← 正确答案
  • D.自动清理网络中的垃圾数据

答案：ABC。证书互认解决“你是谁”，加密防止“路上被偷看”，签名保证“内容没被改”，三者构成完整信任链。清理网络垃圾不是 OPC UA 的职责。

Q9. 关于 OPC UA 安全机制，下列说法正确的有？

多选题 · extreme

  • A.应用证书互认建立设备身份信任← 正确答案
  • B.加密防止数据在信道上被窃听← 正确答案
  • C.签名保证消息内容没有被篡改← 正确答案
  • D.配好证书就可以省略访问控制

答案：ABC。证书解决身份信任，加密防窃听，签名防篡改，三位一体。D 是典型误区：证书解决“你是谁”，授权解决“你能做什么”，两者缺一不可。

Q10. 在一个 OPC UA 落地方案中，实施工程师需要完成哪些工作？

多选题 · hard

  • A.梳理现场设备的协议清单← 正确答案
  • B.设计统一信息模型与地址空间← 正确答案
  • C.部署证书并配置读写的权限← 正确答案
  • D.彻底替换现场的运动控制逻辑

答案：ABC。盘点协议、设计信息模型、部署证书权限是网关落地三步曲；OPC UA 负责统一通信，不替现场总线下达运动控制指令，D 把职责理解错了。