前几篇文章讲述的是TCP/IP 模型中的网络接口层、网络层、传输层、应用层部分协议，这里到了第四层应用层的 MQTT协议。都是物联网常用的应用层协议。这里写到了重头戏 OPC 框架。

  前几篇文章讲述的是TCP/IP 模型中的网络接口层、网络层、传输层、应用层部分协议，这里到了第四层应用层的 MQTT协议。都是物联网常用的应用层协议。这里写到了重头戏 OPC 框架。

  OPC 框架，OLE for Process Control，用于过程控制的 OLE，是针对现场控制管理系统的一个工业标准接口，是工业控制和生产自动化领域中使用的硬件和软件的接口标准。并非传统意义上的单纯应用层协议。

  OPC 标准于 1996 年首次发布，实现把 PLC 特定的协议（如 Modbus、Profibus 等）抽象成为标准化的接口，作为“中间人”的角色把其通用的“读写”要求转换成具体的设备协议。

  PLC 和 PC 上的 SCADA 系统或者 HMI软件（称为 OPC Client）进行数据交换的驱动程序不一致，通信协议和接口不一致。且向更上一层传递数据也不容易。

  电脑上要安装 3 个驱动程序，安装 3 套组态软件。数据标准也不一样，不能整合到一起自己用，也不能很好的把数据在交给上一层的应用。

  电脑上安装 1 个驱动程序，安装 1 个 SCADA 系统，就能访问所有数据。统一监控、调度，统一数据分析、上传，都得到了很好的解决。硬件厂家生产的硬件和驱动程序，一定要符合 OPC 规范，把数据发送到 OPC 服务端，通过 OPC 客户端，有一套标准的读取数据、解析数据的方法。

  不需要这么多驱动程序了，大家都说中文，就不要翻译了，就是这一个意思。严谨一点，这里驱动程序1、2、3 还要的，但是我们电脑能不用过度关心他们了。

  正好微软系统中就有这么一个沟通工具框架 OLE，啥是 OLE ？Object Link Embeded，在程序之间链接和嵌入对象数据。解决的是程序与程序之间的通信问题（可以是不同电脑之间的程序）。

  微软在 OLE2.0 中建立了一个称为COM（Component Object Model，即组件对象模式）的新规范。为满足 Internet 战略，微软把OLE 换成了 ActiveX。通俗来说，OLE / COM / ActiveX 技术，就是让我们在 word 文档中调用 Excel 的能力插入表格，插入之后双击还能调用 Excel 能力进行编辑，是一种跨应用程序相互调用的一种能力规范。

  在 PLC 和 HMI 中间增加一个标准化接口就是 OPC Server，而不用知道每个驱动程序的细节。他有以下能力：

  既然 OPC （DA）有问题，那他就要升级到 OPC UA。接下来介绍一下这两种规范的差异：

  OPC UA 是为了顺应标准化以及跨平台的发展的新趋势，也还是为了能更好地推广 OPC，OPC 基金会于近些年来在先前 OPC DA 成功应用的基础上推出了一项全新的 OPC 标准，即 OPC UA。

  OPC UA 接口协议涵盖了之前的 A&E、DA、OPC XML DA 或者 HDA，仅通过一个地址空间就能访问先前所有的对象，并且不会受到 WINDOWS 平台的限制，这是因为它是从传输层 Scoket 及以上进行定义的。

  消除了对 COM / DCOM 技术的依赖，要求 OPC UA 应用可以在不同平台部署（PLC、嵌入式控制器、网关、Web 应用程序、智能手机、Windows、Linux、）。

  ①数据高度结构化：能够详细地定义和组织各种复杂的工业对象和数据。②丰富的语义表达：可以准确地传达对象的属性、关系和行为等信息。简单说就是不只传了一个值、值得质量、时间戳，还包括他的单位、设定值、传感器的类型、配置参数、它在总系统架构中的位置、他与别的设备组件的关系。

  主站从站不是传输比特或字节（对，这里 cue 的就是 Modbus，传输的是 bit 或者 byte，用户不友好型）。OPC UA Server 提供了读、写、配置等等服务供 Client 端调用。可读性强、可复用性强、可维护性强。这里采用了面向服务的设计，可以调用很多标准的方法来用。可能之前写的是 一堆二进制代码，现在可以用人能看得懂的英文来编程了。

  之前数据是这样传递的：传感器–PLC 逻辑控制器–SCADA/HMI 系统–MES 智能制造系统–ERP 系统。

  通过 OPC UA，这样传递数据：传感器–PLC 逻辑控制器–OPC 服务器–ERP 系统。他的野心和大，能实现PLC 逻辑控制器–SCADA/HMI 系统–MES 智能制造系统–ERP 系统这几两个项目之间的俩俩通信，为工业 4.0 打好基础。

  强大的信息建模(IM)是OPC UA的核心。OPC UA定义了基本模块和通用规则，并使用它们构建面向对象的模型（看上面的图，也就知道 OPC 为啥不单纯是应用层协议了）：

  二进制通讯协定是 opc.tcp://Server；二进制传输效率高，资源需求少，可以穿透防火墙。

  OPC UA客户端-服务器通信采用面向服务的体系结构（SOA），服务定义了信息模型的访问方式。不同于传统的Web服务，传统Web服务使用基于XML的WSDL来描述服务，这种方法存在提供商间互操作性差异的问题。

  相比之下，OPC UA预先定义了通用的标准化服务，确保所有实现都兼容。由于服务的标准化，OPC UA不需要像WSDL那样的特定定义，这确保了所有实现的兼容性和互操作性，使调用者无需了解特定的服务结构或行为细节。

  PubSub 模式为数据和事件通知提供了一种替代机制，与传统的客户端-服务器通信不同，它优化了多对多的交互。在PubSub模型中，多个客户端可以同时接收广播通知，这些通知以“一触即发”的方式发送。

  使用PubSub，OPC UA应用程序不直接交换请求和响应。相反，发布者将消息发送到面向消息的中间件，而无需知道订阅者的具体身份。同样，订阅者能够最终靠订阅感兴趣的数据或事件，而发布者不必须了解到具体哪些订阅者存在。

  PubSub和客户端-服务器模式都基于OPC UA的信息模型。通常情况下，OPC UA服务器充当发布者，而OPC UA客户端充当订阅者。本地的OPC UA客户端-服务器通信能够适用于配置和管理PubSub组件。

  OPC Server 提供数据采集、协议转换、数据管理服务。支持数据采集与下控，下控还是推荐用 IO server。

  通俗来说，OPC是个中介，OPC包括一整套接口、属性和方法的标准集，用于过程控制和制造业自动化系统。必须依赖Windows系统，就是说 OPC Server 必须部署在 Windows 服务器上，以为他依赖了 Windows 的 COM 技术（不太严谨哈，OPC UA就致力于跨系统服务）。