Información detallada de opc (OLE estándar de la industria para control de procesos)

OPC (OLE for Process Control), OLE para control de procesos, es un estándar industrial. La organización internacional que gestiona este estándar es la OPC Foundation. Actualmente cuenta con más de 220 miembros. En todo el mundo, incluidas las principales empresas de sistemas de control de automatización, instrumentación y sistemas de control de procesos del mundo. Basado en las tecnologías OLE (ahora Active X), COM (Modelo de objetos componentes) y DCOM (Modelo de objetos componentes distribuido) de Microsoft. OPC incluye un conjunto estándar de interfaces, propiedades y métodos para su uso en sistemas de automatización de fabricación y control de procesos. Introducción básica Nombre extranjero: OLE para control de procesos Categoría: Aplicación de software Plataforma: Windows Características: Eficiencia, confiabilidad, apertura Definición y explicación, campos de aplicación, resolución de problemas, Definición y explicación El nombre completo de OPC es Vinculación e incrustación de objetos (OLE) para Control de procesos, su aparición ha establecido un puente entre las aplicaciones basadas en Windows y las aplicaciones de control de procesos en el sitio. En el pasado, para acceder a la información de datos desde dispositivos de campo, cada desarrollador de software de aplicación necesitaba escribir funciones de interfaz dedicadas. Debido a la gran variedad de dispositivos de campo y a la continua actualización de los productos, los usuarios y desarrolladores de software a menudo conllevan una enorme carga de trabajo. Por lo general, esto no puede satisfacer las necesidades reales del trabajo. Los integradores y desarrolladores de sistemas necesitan urgentemente un controlador de dispositivo plug-and-play que sea eficiente, confiable, abierto e interoperable. En este caso surgió el estándar OPC. El estándar OPC se basa en la tecnología OLE de Microsoft. Su formulación se completa proporcionando un conjunto de interfaces estándar OLE/COM que utiliza la tecnología OLE 2. El estándar OLE permite que varias computadoras intercambien documentos, gráficos y otros objetos. COM es la abreviatura de Component Object Model y es la base de todos los mecanismos OLE. COM es un estándar desarrollado para implementar objetos que son independientes de los lenguajes de programación. El estándar define objetos en Windows como unidades independientes a las que se puede acceder sin restricciones de programa. Este estándar permite que dos aplicaciones se comuniquen a través de interfaces basadas en objetos sin saber cómo se creó la otra parte. Por ejemplo, el usuario puede usar el lenguaje C++ para crear un objeto de Windows, que admite una interfaz a través de la cual el usuario puede acceder a varias funciones proporcionadas por el objeto. El usuario puede usar Visual Basic, C, Pascal, Smalltalk u otros lenguajes. escribir programas de acceso a objetos. En el sistema operativo Windows NT4.0, la especificación COM se ha ampliado para acceder a otros objetos fuera de la máquina local. Los objetos utilizados por una aplicación se pueden distribuir en la red. Esta extensión de COM se llama DCOM (COM distribuido). A través de la tecnología DCOM y los estándares OPC, es posible crear un software de sistema de control abierto e interoperable. OPC adopta el modelo cliente/servidor, asignando la tarea de desarrollar interfaces de acceso a los fabricantes de hardware o terceros fabricantes y proporcionándolas a los usuarios en forma de servidores OPC, lo que resuelve la contradicción entre los fabricantes de software y hardware y completa la integración del sistema. , mejorando la apertura y la interoperabilidad del sistema. Los servidores OPC suelen admitir dos tipos de interfaces de acceso, que proporcionan mecanismos de acceso para diferentes entornos de lenguajes de programación. Estas dos interfaces son: Interfaz de automatización; Interfaz personalizada. Las interfaces de automatización suelen ser interfaces estándar definidas en función de lenguajes de programación de scripts. Las aplicaciones del cliente para servidores OPC se pueden desarrollar utilizando lenguajes de programación como Visual Basic, Delphi y PowerBuilder. La interfaz personalizada es una interfaz estándar especialmente desarrollada para lenguajes de programación de alto nivel como C++. OPC se ha convertido ahora en la solución predeterminada para la interconexión de sistemas en el mundo industrial, brindando comodidad a la programación de monitoreo industrial. Los usuarios no tienen que preocuparse por los protocolos de comunicación.

Cualquier proveedor de soluciones de software de automatización que no pueda soportar completamente OPC será eliminado de la historia. 1. En el campo del control, los sistemas suelen estar compuestos por subsistemas dispersos y cada subsistema suele utilizar equipos y soluciones de diferentes fabricantes. Los usuarios deben integrar estos subsistemas y crear un sistema de monitoreo unificado en tiempo real. 2. Un sistema de monitoreo en tiempo real de este tipo debe resolver el problema del intercambio de datos entre subsistemas dispersos, y cada subsistema debe coordinar las instrucciones de control correspondientes de manera unificada. 3. Considere que los sistemas de monitoreo en tiempo real a menudo necesitan ser actualizados y ajustados. 4. Cada subsistema debe tener una interfaz abierta unificada. 5. La especificación OPC (OLE para control de procesos) es el producto de este pensamiento. 6. OPC se basa en la arquitectura de Aplicación Distribuida de Internet (DNA) y la tecnología de Modelo de Objetos Componentes (COM) de Microsoft, y está diseñado para una fácil escalabilidad. La especificación OPC define una interfaz estándar de la industria. 7. OPC utiliza el mecanismo OLE/COM como estándar de comunicación para aplicaciones. OLE/COM es un modelo cliente/servidor que tiene las ventajas de independencia del lenguaje, reutilización del código y fácil integración. OPC estandariza las funciones de la interfaz, sin importar la forma en que exista el dispositivo de campo, los clientes pueden acceder a él de manera unificada, garantizando así la transparencia del software para los clientes y liberando completamente a los usuarios del desarrollo de bajo nivel. 8. OPC define una interfaz abierta en la que los componentes de software basados ​​en PC pueden intercambiar datos. Se basa en la tecnología OLE de Windows: vinculación e incrustación de objetos, COM: modelo de objetos componentes (modelo de objetos componentes) y DCOM: COM distribuido (COM distribuido). Por lo tanto, OPC ofrece un método ideal para conectar aplicaciones industriales y programas de oficina con dispositivos de campo típicos en el nivel de automatización. Áreas de aplicación 1. Usuarios de soluciones de control industrial 2. Usuarios de soluciones de control de edificios 3. Fabricantes de soluciones de control industrial 4. Fabricantes de soluciones de control de edificios 5. Integradores de soluciones de control industrial 6. Integradores de soluciones de control de edificios 7. OPC en todos los campos de automatización es un estándar de interfaz de software para conectar fuentes de datos (servidores OPC) y usuarios de datos (aplicaciones OPC). La fuente de datos puede ser PLC, DCS, lector de códigos de barras y otros equipos de control. Dependiendo de la configuración del sistema de control, el servidor OPC como fuente de datos puede ser un servidor OPC local que se ejecuta en el mismo ordenador que la aplicación OPC o un servidor OPC remoto que se ejecuta en otro ordenador. La interfaz OPC es adecuada para HMI (Interfaz de supervisión de hardware)/SCADA (Control de supervisión y adquisición de datos), procesamiento por lotes, etc. que proporcionan los datos sin procesar del equipo de control de nivel más bajo al usuario de datos (aplicación OPC) a través de la red. Los programas automatizados, e incluso aplicaciones de nivel superior, como bases de datos históricas, también son adecuados para conexiones directas entre aplicaciones y dispositivos físicos. Por lo tanto, la interfaz OPC es un estándar de interfaz con alto espesor y flexibilidad adecuado para muchos sistemas. Resuelva el problema Antes del nacimiento de OPC, no existía un estándar unificado para la interfaz entre el controlador de hardware y el programa de aplicación conectado a él. Por ejemplo, en el campo de FA (Automatización de fábrica): automatización de fábrica, la conexión de equipos de control como PLC (Controlador lógico programable) y software SCADA/HMI requiere diferentes configuraciones del sistema de red FA. Según una encuesta, entre los costos de desarrollo de software de sistemas de control, el diseño de programas de aplicación para varias máquinas representa el 70% del costo, mientras que el desarrollo de interfaces de conexión entre máquinas y equipos representa el 30%. Además, en el campo de PA (Automatización de procesos) - automatización de procesos, cuando desee transferir todos los datos del proceso en el sistema de control distribuido (DCS - Sistema de control distribuido) al sistema de gestión de producción, debe seguir las especificaciones de cada proveedor. modelo de máquina Desarrollar interfaces específicas, por ejemplo, usar DLL en lenguaje C (Base de datos de enlace dinámico) para conectarse al servidor DDE (Intercambio dinámico de datos) o usar texto FTP (Protocolo de transferencia de archivos) para diseñar aplicaciones.

Por ejemplo, cuando un sistema se compone de cuatro tipos de equipos de control y tres aplicaciones conectadas a ellos: monitoreo, gráficos de tendencias y generación de informes, se debe dedicar mucho tiempo a desarrollar el monitoreo, los gráficos de tendencias y las aplicaciones correspondientes a los dispositivos A. , B, C y D respectivamente. Se utilizan un total de 12 controladores para el software de interfaz para aplicaciones de informes. Al mismo tiempo, debido a que el sistema almacena una variedad de controladores, también hace que sea más difícil mantener la estabilidad y confiabilidad del entorno operativo. OPC se propuso con el fin de estandarizar las interfaces de software entre dispositivos y aplicaciones de diferentes proveedores y simplificar el intercambio de datos entre ellos. Como resultado, los usuarios pueden recibir productos de componentes de software de control de procesos que se pueden combinar y utilizar libremente independientemente de los lenguajes y entornos de desarrollo específicos. Un sistema que utiliza OPC consta de un servidor OPC que proporciona servicios de recopilación de datos de acuerdo con los requisitos de una aplicación (programa cliente), una interfaz OPC necesaria para utilizar el servidor OPC y una aplicación OPC que recibe el servicio. El servidor OPC se desarrolla según el hardware de cada proveedor, de modo que pueda absorber las diferencias en el hardware y sistemas de cada proveedor, logrando así una configuración del sistema independiente del hardware. Al mismo tiempo, se puede utilizar un tipo de datos llamado Variant para proporcionar formatos de datos de acuerdo con los requisitos de la aplicación, independientemente del tipo de datos inherente al hardware. La estandarización de interfaces mediante OPC permite la selección de aplicaciones de monitoreo, tendencias y generación de informes independientemente de la estructura interna de cada dispositivo y su proveedor. ¿Por qué desarrollar un servidor OPC y un gateway OPC independientes? 1. Los altos precios de los fabricantes originales extranjeros 2. La inflexibilidad de los fabricantes originales extranjeros frente a los proyectos 3. La diversidad de subsistemas en los proyectos nacionales dificulta la provisión de DRIVER 4. El servidor OPC independiente busca estabilidad, tiempo real y velocidad. 5. Irregularidad de muchos subsistemas 6. Posibles inconsistencias en los proyectos de contratación general antes y después de la licitación 7. Software de servidor de plataforma original costoso 8. Si el contratista general ha invertido mucha mano de obra en el desarrollo 9. Compatibilidad de plataforma y subsistemas 10. Interoperabilidad establecida entre Plataformas y subsistemas OPC 11. Resolvió los problemas de los fabricantes e integradores en la integración del proyecto 12. Resolvió los problemas de los fabricantes e integradores que dispersan recursos para el desarrollo secundario 13. Resolvió los problemas de los fabricantes de subsistemas en el proyecto 14. Proporcionar un canal transparente para la comunicación de datos entre los niveles superior e inferior