在工厂里，PLC、传感器、上位机、MES系统来自不同厂家，各说各的"方言"，怎么让它们互相听得懂？OPC就是工业界制定的"普通话"标准，让不同品牌、不同类型的设备能通过统一接口交换数据。今天就把OPC这件事从原理到实际应用说透。

先搞清楚OPC是什么。OPC全称是OLE for Process Control，翻译过来叫"用于过程控制的OLE"。最早是1996年由微软和几家自动化厂商一起搞的，基于当时的COM/DCOM技术。简单说就是：不管你的设备是西门子的、三菱的、还是国产的，只要装了OPC Server，就能通过统一的OPC接口把数据提供给任何支持OPC的客户端软件——组态软件、MES系统、数据采集平台都能直接读。

OPC有两个大版本：OPC Classic和OPC UA。OPC Classic又分三个规范：OPC DA（Data Access，数据访问，最常用）、OPC AE（Alarms and Events，报警事件）、OPC HDA（Historical Data Access，历史数据访问）。OPC DA是实时读数据的，比如读PLC的寄存器值、传感器的当前读数。OPC AE用来订阅设备的报警消息，比如温度超限报警、设备故障通知。OPC HDA用来查询历史数据曲线。

OPC UA是2006年发布的升级版，跟Classic完全不一样。Classic基于COM/DCOM，只能在Windows上跑，跨平台差，而且DCOM的防火墙配置能把人逼疯。OPC UA用的是TCP/IP或者HTTPS，能在Windows、Linux、嵌入式系统上跑，而且加了安全层（加密、签名、认证），适合跨网段甚至跨互联网的远程监控。另外OPC UA的数据模型更丰富，不仅能传简单变量，还能传复杂结构、方法调用，甚至能直接读设备的型号、固件版本这些元数据。现在新项目基本都用OPC UA了。

实际用的时候怎么选？新项目果断OPC UA，原因很简单：安全、跨平台、能远程。老项目如果已经有OPC Classic设备了，也不用全换，可以加一个OPC UA网关把Classic的数据转成UA格式往上送。很多厂商的PLC现在自带OPC UA服务器功能，比如西门子S7-1200/1500、三菱FX5U，不需要额外装软件就能直接被OPC UA客户端读写。

搭OPC系统的典型架构是这样的：底层设备（PLC、传感器）→ OPC Server（可以是设备自带的，也可以是独立软件，比如Matrikon OPC Server、KEPServerEX）→ OPC Client（组态软件如WinCC/iFix、SCADA系统、Python脚本、Node-RED）→ 上层业务系统（MES、ERP、数据湖）。OPC Server是核心，它负责跟各种硬件设备通信（走Modbus、Profibus、EtherCAT这些设备原生协议），然后把数据转换成OPC标准格式对外提供。

自己写OPC客户端也不难。Python有免费的opcua库，几行代码就能连上OPC UA服务器读数据：from opcua import Client; c = Client("opc.tcp://服务器IP:4840"); c.connect(); node = c.get_node("ns=2;s=温度传感器1"); print(node.get_value()); c.disconnect()。OPC Classic的Python库也有，但因为依赖Windows COM组件，只能在Windows上跑，而且要装Pywin32和olefile这些依赖，配置稍微麻烦一点。

聊几个实际踩过的坑。第一个是DCOM权限配置——OPC Classic跨机器通信时，客户端要访问远程DCOM对象，Windows默认不让，得在"组件服务"里给"ANONYMOUS LOGON"用户加启动权限。这个配置步骤多、容易忘，导致很多OPC Classic跨机器通信不通，排查起来费时间。OPC UA不需要配置DCOM，只要开端口就行，省心太多。第二个是点位命名不规范——不同工程师加的点位命名风格不一样，有的叫"Temp1"，有的叫"Line1_Temp_Sensor_A"，到后期维护找点位能把人累死。建议提前定好命名规范：产线号+设备类型+编号+参数，比如"Line1_TempSensor_01_CurrentValue"。第三个是数据更新频率——PLC数据变化快，OPC Server默认是变化才推送（COV），但有些上位机要求固定间隔刷新，这时候要在OPC Client里设好订阅参数，别等系统上线了才发现数据更新跟不上。

总结一下：OPC就是工业界的数据"普通话"，让不同设备能互相通信。新项目用OPC UA，老项目可以Classic+UA网关过渡。搭系统时重点关注命名规范和数据刷新机制，这两个是后期维护最头疼的地方。