OPC UA是什么？工业通信标准的架构与安全机制

OPC UA是OPC统一架构（OPC Unified Architecture），由OPC Foundation维护，是一套独立于操作系统和硬件平台的工业信息交换标准。它既规定数据怎样通信，也规定设备、变量和操作怎样表达，并提供身份认证、消息保护和访问控制机制。因此，它不只是一条传输数据的通道。

例如，生产系统收到“82.5”这个数值，还需要知道它来自哪台设备、代表什么温度、单位是什么、当前是否可用，以及能否修改对应设定值。OPC UA把这些信息和访问规则组织起来，使不同设备与软件有条件地共享信息；实际互通仍取决于双方实现的功能、模型和配置。

OPC UA的架构包含哪些部分？

理解OPC UA，可以把它看成相互配合的三部分。信息模型描述对象、数据及其关系；通信服务与通信模型提供浏览、读写、方法调用、订阅或数据集分发；安全机制约束谁与谁通信、消息怎样受保护，以及哪些操作被允许。底层还需要相匹配的编码、传输方式和网络连接。

平台无关意味着它不绑定某一种操作系统或厂商，并不意味着所有产品功能完全相同。一个PLC可能提供OPC UA服务器，一个边缘应用可能同时承担客户端和服务器角色；另一个设备则可能只实现所需的PubSub功能。不能从“支持OPC UA”四个字推导出它支持全部服务和通信方式。

与现场总线、工业以太网和无线连接之间的层次关系，可参见工业通信协议的分类与互通条件。OPC UA主要解决信息表达和交换问题，具体数据仍要经过设备接口与网络才能到达应用。

信息模型怎样描述一台设备？

在ClientServer架构中，服务器向客户端提供的对象及相关信息构成地址空间。对象、变量和方法等由节点表示，节点之间通过引用建立关系。它不仅是一个点位名称列表：客户端可以沿着关系找到某台设备的测量值、属性和可调用操作。

以下用一个假设的“温控工位01”说明。示例名称与功能用于教学，不是OPC UA为所有设备规定的固定模型。

模型要素	温控工位示例	表达的含义
对象	温控工位01	把属于这台工位的数据与功能组织在一起
变量	测量温度、目标温度、运行状态	分别提供可读取的数据；是否可写由变量能力及访问权限决定
方法	申请切换配方	客户端提交配方编号，服务器执行约定逻辑并返回结果；不只是修改一个数值
引用	工位拥有温度变量，变量关联工程单位属性	表示组成、属性、类型等关系，使信息能够按结构被发现
类型	同类温控工位采用共同类型定义	约定实例应具有的结构与语义，避免每台设备都使用完全不同的表达方式

事件表达发生的事情，例如传感器故障或配方切换完成。它不同于“当前温度”这样的持续变量：事件通知可携带事件类型、来源和时间等信息。OPC UA用EventType描述事件类型，EventType属于对象类型；不能把事件理解成一种独立节点类别，也不意味着每发生一次事件，地址空间中就增加一个可浏览节点。

类型定义让多个实例可以采用一致结构，行业配套规范还可以约定更具体的设备语义。不过，通用客户端能够浏览一个自定义节点，不等于它自动理解该节点的业务用途。若服务器把某个状态值定义为“等待装料”，消费数据的软件仍需支持该模型或完成对应映射。

温度数值、单位、时间戳和状态分别代表什么？

在这个假设模型中，温度变量的数值是82.5，工程单位属性说明单位为摄氏度。读取变量值时，OPC UA的DataValue结构还可以提供StatusCode以及源时间戳、服务器时间戳等信息。工程单位属于模型中的属性，不是把“℃”自动附加到每个DataValue中的固定字段。消费数据的软件需要读取或依据已知模型解释它。

按照OPC UA服务规范对DataValue的定义，StatusCode用于说明值的可用状况。Good表示相应数据质量状态良好，Uncertain表示存在不确定原因，Bad表示该值不可用。应用不应把Bad值继续当作正常温度参与计算；Good也不能证明传感器已经校准，更不能证明工件质量合格。

SourceTimestamp是数据源赋予该值或状态的时间；ServerTimestamp反映服务器收到该值或知道该值仍准确的时间，两者不一定相同。服务器再次提供一个值，不代表现场重新测量了一次。另一方面，源时间可能随数值或状态变化更新，温度稳定时不变也不必然表示断线。因此，判断数据是否足够新，要结合更新约定、状态和通信诊断，不能只看某个时间戳是否持续跳动。

ClientServer与PubSub怎样交换信息？

ClientServer：访问服务器信息并接收订阅通知

客户端向服务器提出请求：先通过浏览找到设备与变量，再读取温度；有权限时，可以写入允许修改的目标值，或者调用方法提交配方切换请求。服务器按服务、对象和权限执行，并返回结果。方法返回的含义由接口约定，例如“请求已接受”不能自动解释成“温度已经达到新目标”。

持续观察温度时，客户端可以创建监控项和订阅。服务器按相应采样、过滤与队列设置产生数据变化或事件通知，通过响应客户端的Publish请求返回通知。它减少了客户端反复发起普通读取的需要，但仍属于ClientServer交互，不能把这种订阅等同于PubSub。

订阅的采样间隔与发布间隔也不是同一件事：前者关系到服务器怎样观察数据变化，后者关系到通知怎样交付。底层设备实际更新可能更慢，服务器也可能调整请求的间隔。应用应依据实际支持的参数理解数据节奏，而不是认为填入一个很短的间隔就能捕获所有现场变化。

PubSub：发布约定数据集，由接收方解析消费

PubSub中，发布者把选定字段组织成数据集并发布消息，订阅者按匹配的配置接收和解释。例如，一个数据集可以包含工位标识、温度、运行状态及相应时间信息，分别供趋势记录和生产看板使用。接收方需要知道字段类型、结构及相关元数据，不能仅因为收到了消息就假定理解其中每个字段。

发布者不必为每个订阅者执行一次直接读请求。根据OPC UA PubSub规范，消息既可以通过不依赖消息代理的网络机制分发，也可以通过消息代理（Broker）转发，例如相应的UDP或MQTT映射。PubSub并非全部需要Broker，也不是把任意MQTT消息换个名称就变成OPC UA数据集。

因此，需要浏览设备结构、按需查询或调用具体操作时，可以使用相应的ClientServer服务；需要将约定的数据集分发给一个或多个消费端时，可以采用合适的PubSub方案。两种模型的选择还取决于产品支持、网络与应用需求，不能简单归纳为“旧版与新版”或“慢与快”。

OPC UA的安全机制分别保护什么？

应用证书与信任：确认连接的是哪个应用

以常见使用应用证书的ClientServer连接为例，应用实例证书关联应用身份与公钥，对方依据证书校验和配置的信任关系决定是否接受。信任列表可以包含被明确接受的证书或证书颁发机构；使用证书时还需验证相应有效性，而不是看到证书文件就自动接受。

这回答的是“是否信任这个客户端或服务器应用”。它与登录人员的身份、允许执行的操作不同：一台受到信任的数据采集应用，仍然可以只被允许读取温度，而不被允许修改目标温度。

签名、加密和安全策略：保护传输消息

消息签名用于验证消息来源并检测传输中的改动；加密用于保护内容，降低被旁观者直接读取的风险。二者目的不同，只签名不等于隐藏内容。安全策略规定所使用的算法组合等机制，消息安全模式则决定怎样启用消息保护。

OPC UA定义了None、Sign、SignAndEncrypt等消息安全模式：None不在该消息安全层提供签名和加密，Sign提供签名保护，SignAndEncrypt同时提供签名与加密。双方需要支持并实际使用匹配的安全策略和模式。产品具有这些能力，并不代表部署时无需配置信任、端点和访问规则就能达到预期保护。

用户认证与授权：区分身份和操作权限

用户认证识别当前访问者或服务账户，可能使用用户名凭据、用户证书等产品支持的方式；授权进一步决定该身份能浏览、读取、写入哪些数据，以及调用哪些方法。OPC UA安全模型将用户授权与应用认证分别描述，并支持通过角色等机制表达权限。

在温控工位例子中，趋势记录账户可以读取温度和订阅状态，却不能申请切换配方；获得相应授权的操作账户才可能调用该方法。即使方法有调用权限，工位程序仍要判断配方是否存在、当前工步是否允许切换。证书可信、用户登录成功、操作获得授权和工艺条件满足，是不同的判断。

PubSub：区分消息保护与代理链路保护

PubSub不能直接套用“每个订阅者都与发布者建立一个客户端安全通道”的解释。它可以对发布消息进行签名或签名加密，让授权订阅者验证、解密；相关密钥按安全组管理，可由安全密钥服务（SKS）分发给获准参与的应用。

消息代理链路上的TLS与这种发布者到订阅者的消息保护也不同。若只保护“发布者到Broker”和“Broker到订阅者”两段连接，Broker仍可能读取内容；不能据此声称已具备端到端的消息保密。实际采用哪种保护，取决于所选映射、产品能力和配置，需要与谁能取得密钥、谁能接收消息的规则一起考虑。

OPC UA在生产系统中承担什么任务？

典型任务包括把设备状态提供给监控软件、把生产数据交给MES或历史数据库，以及在设备之间交换约定信息。它的价值在于同一数据可以连同结构和访问规则供不同应用使用，而不只是把私有寄存器内容搬到另一个网络。

继续以假设温控工位为例：采集软件以获准身份建立连接，定位温度变量并读取单位，再订阅温度和运行状态。记录系统保留数值、时间和状态，并把它们与设备编号及当前批次关联。出现Bad状态时，记录为不可用数据并显示缺口；出现Uncertain时保留原因，按该应用的数据规则处理，不能只保存数字后继续画成正常趋势。

若生产看板改用PubSub接收同一工位的数据集，仍需匹配字段与元数据，并明确批次信息从哪里关联。两种通信模型可以服务类似的业务目标，但接入方式和数据消费逻辑并不完全相同。信息模型提供共同表达的基础，业务软件还要实现正确解释。

支持OPC UA并不自动具备硬实时控制保证。普通订阅或PubSub发布能否满足时限，取决于设备采样、软件调度、网络、传输映射和接收处理的完整路径。以UDP方式分发PubSub消息本身，也不保证按时送达。对轴运动等要求严格的任务，需要具体控制与通信方案支持并验证；不能仅凭“用了PubSub”就替代原有控制回路。

理解OPC UA的关键，是把模型、服务和权限联系起来：数据代表什么，应用怎样获取或操作它，以及什么身份能做什么事。只有这三者在实际系统中一致，信息交换才真正可用。

参考资料

• OPC Foundation：OPC Unified Architecture概述。
• OPC 10000-1：Overview and Concepts，系统概念与通信模型。
• OPC 10000-3：Address Space Model，对象、引用、类型、事件与方法。
• OPC 10000-4：Services，DataValue、监控项与订阅服务。
• OPC 10000-8：Data Access，模拟量变量类型与工程单位。
• OPC 10000-2：Security Model，应用认证、安全模式、用户认证与授权。
• OPC 10000-14：PubSub，数据集、消息分发与安全机制。