背景介绍：
19世纪90年代，当时基于软件的自动化的使用迅速增加，依赖于WINDOW进行数据的显示，这意味着每一个自动化设备必须有特定的Windows驱动程序，以便于运行在PC上的HMI和SCADA软件交换自动化数据，结果产生了很多不同的协议和接口，这是一个问题，不仅自动化数据不容易获取，而且把信息传输到更高层也不容易，因此，一群自动化公司聚起来一起来解决这个问题，结果出现了OPC。
提供驱动从应用软件开发商变成了设备的制造商
也就是在驱动程序和HMI之间设置一个标准化接口，这样HMI能够通过标准化接口从任何类型的自动化设备访问数据，而不必知道具体的驱动细节，这个接口是一个OPC服务器，而HMI是一个OPC客户端，使用来自服务器的自动化数据，然后设备供应商将按照规范生产OPC服务器能够理解的驱动程序。
这时候碰巧微软已经有了一个通信框架，叫做组件对象模型，或COM，使得不同的应用程序在用一台PC上通信，还有DCOM让同一个网络下的不同设备上的程序通信。
用这个方法进行通信，因此搭建了三个接口
到现在，OPC是实现自动化数据从PLC和DCS流向SCADA和历史数据库的主渠道。但是服务器和客户端必须在window环境下才能通信，而且OPC不能用于互联网通信的实时清楚地表明，这种技术不能把我们带到工业通信的未来。
接来下OPC UA登场：
OPC UA 客服了对COM和DCOM的依赖并且要求所有OPC UA应用程序可以再不同的平台上部署包括PLC，嵌入书控制器，网关， web应用程序以及手机，同时OPC UA可以上网了并且防火墙友好，因为它使用https这样的协议，这确保了生产设备可以嵌入到Internet上安全无缝的交换信息的能力。
使用OPC你只能以最纯粹的形式公开自动化数据，例如压强的值，但是利用OPC UA的信息建模，允许以一种比仅使用单个值复杂得多的方式公开机器或传感器信息，以便给OPC UA客户一个机器或工厂信息的整体视图， 相比于Modbus用字节和比特传输，在OPC UA服务器中，一方发的形式公开服务，客户端通过这些方法进行访问信息。
自动化金字塔：
信息之前的向上传递一层一层，再过去并不容易实现，但是OPC UA是一个在这些所有阶段都很常见的信息载体，这个金字塔有些过时了，现在设备可以直接将数据传输到更高的层次，甚至更好。OPC UA使得从云运行不需要关键流程逻辑成为可能。
通常在OPC客户端中连接用于访问其他服务器的系统，和用于公开自己系统信息的服务器。
数据建模和传输机制是OPC UA的两大基本支柱，OPC UA定义了两种传输方式，第一种是使用二进制的TCP协议，它在需要高性能的场景中工作的很好，第二种是将传输映射到现有的互联网标准，如http，xml和web服务这对网络通信很有效，OPC UA是一个完整的数据建模规范，它定义了OPC UA应用程序开发人员在OPC UA服务器中公开复杂信息模型时必须遵循的规则。
简单来说，OPC UA当看到服务器能够详细描述底层物理资产信息的模型时，就有了信息交换的标准，并公开客户端可用于消费该信息的服务，客户端和服务器之间的数据交换是通过tcp和https协议进行的，服务器和客户端都可以部署在不同的计算平台上。
除了模型的客户端， OPC UA规范被扩展为一种发布订阅模式，其中OPC UA服务器将信息广播给订阅了该信息的许多客户端
OPC_UA协议：独立于特定的操作系统，支持诸如 Window、Linux、Apple OS X、实时操作系统或移动操作系统（Android 或 iOS）等，适合于跨层级数据交换，采用简单的客户端/服务器的机制进行通信
