Sistema OPC para automatización mediante redes de estado

1 Equation Chapter 1 Section 1 Trabajo Fin de Master Master Universitario en Automática, Robótica y Telemática (R.D.1393/07) Sistema OPC para automatización mediante redes de estado. Autor: Antonio Tamairón Pérez Tutor: Iván Maza Alcañiz Dep. de Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2016 2 3 Trabajo Fin de Master Master Universitario en Automática, Robótica y Telemática. Sistema OPC para automatización mediante redes de estado. Autor: Antonio Tamairón Pérez Tutor: Iván Maza Alcañiz Profesor titular Dep. de Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2016 4 5 Trabajo Fin de Master: Sistema OPC para automatización mediante redes de estado. Autor: Antonio Tamairón Pérez Tutor: Iván Maza Alcañiz El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2016 El Secretario del Tribunal 6 7 A mi madre, a mi padre, Indistintamente… “La tristeza es un don del cielo, el pesimismo es una enfermedad del espíritu” (Amado Nervo) 8 9 Resumen xisten numerosas soluciones software basadas en redes de estado, que permiten modelar sistemas definidos en términos de causa-evento, para entender de manera sencilla como estos funcionan y evolucionan (entendiendo el concepto de proceso como un conjunto de fases sucesivas de un fenómento o hecho complejo). Si estos procesos los trasladamos al campo de la automatización, se puede ver que la mayoría del software existente, de este tipo, no está orientado a dar soluciones en este aspecto, y al final carecen de las herramientas necesarias para implementar y simular un automatismo del tipo que sea, y aun mas, conseguir que este finalmente interactue con el entorno real (con el conjunto de sensores y actuadores). Por otro lado, el interfaz de usuario que poseen, deja mucho que desear al no estar orientado para el y no siendo nada adecuado para el trabajo de implementación del sistema. Todo esto concluye en tener herramientas que convierten una tarea supuestamente más sencilla, en una tediosa tarea de implementación con una ingrata experiencia para el usuario y con una acusada falta de soluciones para conectar con el mundo real. Partiendo entonces de esta problemática, se planteó la idea de crear un software de desarrollo que subsanara dichas deficiencias, y de alguna manera sacase partido a la idea de implementar automatismos con la sencilla acción de unir elementos entre sí, con alguna que otra configuración rápida y además se pudiera visualizar el proceso de manera gráfica y su evolución, cuando este estuviese siendo ejecutado/procesado. Por otro lado, aportar un valor añadido a dicha herramienta y permitir que pudiera interactuar con entornos de control reales, aumentando su utilidad. Este documento pretende describir dicho proyecto antes brevemente definido, sobre este software de implementación mediante interfaz gráfico, que permite automatizar procesos, ya sean de entorno industrial, domótico u otros entornos que puedan ser automatizados a alto nivel (partiendo de que los sensores y actuadores ya están direccionados en un controlador y es posible interactuar con ellos mediante un servidor OPC) construyendo estructuras de elementos estado-transición interconectadas, y haciendo uso del estándar OPC. El objetivo final es obtener un conjunto de herramientas contendidas en un interfaz gráfico muy orientado al usuario, que permita formar estructuras complejas de elementos activos interconectados (elementos que pueden realizar acciones, cálculos, operaciones de E/S OPC, etc.), permitiendo de manera sencilla automatizar procesos y poder interpretarlos (ver como evoluciona en tiempo de ejecución, gracias a un runtimer (1) ) y tener la posibilidad de hacer que interactue con el mundo real, gracias al estandar OPC. Es OPCSM VAI (OPCSM – Virtual Automation Interpreter) el software que reúne dichas condiciones, producto del desarrollo de este proyecto y que será descrito con mas detalle en este documento. (1) Motor de ejecución basado en eventos de un temporizador con base de tiempo T, que reproduce en cada flanco las acciones de aquellos elementos del sistema seleccionados para ser procesados. E Sistema OPC para automatización mediante redes de estado 16 mediante un controlador preparado con solamente el direccionamiento hacia los sensores y actuadores, realizar toda la fase de programación y ejecución desde este entorno. Aquí es entonces cuando nace OPCSM VAI. Buscando por la red, podemos ver que existen una infinidad de aplicaciones para simular redes de Petri (ya que no se alejan de esa idea) pero la mayoría no se acercan a la posibilidad de servir como herramienta de ayuda en sistemas reales y mucho menos orientados al aprendizaje en el campo de la automatización. Quizás una de las herramientas más cercanas a esta filosofía podría ser Petri.NET, pero su interfaz gráfico no parece muy amigable y no parece estar orientado al usuario, y aunque posee herramientas de implementación el entorno no es tan intuitivo como cabría esperar. No tiene una jerarquía de desarrollo orientada a proyecto, y múltiples documentos para organizar la implementación, su filosofía está basada en usar bloques, que contienen subsistemas, con lo cual al final se pierde esa visión general. Por otro lado, un detalle muy importante es que la integración OPC no es tan directa, necesitando de un desarrollo más complejo mediante Python, para poder comunicarse con el servidor OPC, aunque si es cierto que esta última característica lo hace más versátil, pero al final se convierte en un entorno de programación perdiendo la idea inicial de crear sistemas para automatizar procesos industriales de manera sencilla y rápida. 1.2 Introducción al estándar OPC OPC es un estándar para intercambio seguro y fiable de datos en el sector de la automatización industrial y otras industrias. Es una plataforma independiente que asegura un flujo de información entre múltiples fabricantes aun con sus distinciones en cuanto a tecnologías, protocolos, etc. El estándar OPC es una serie de especificaciones desarrolladas por los fabricantes del sector industrial, los usuarios finales y los desarrolladores de software. Estas especificaciones definen el interfaz entre servidor/cliente así como entre servidor/servidor, incluyendo acceso en tiempo real a los datos, monitorizado de alarmas y eventos, acceso al histórico de datos y otras aplicaciones. Cuando el estándar fue lanzado por primera vez en 1996, se propuso abstraer los protocolos específicos de PLCs, como Modbus, Profibus, etc en un interfaz estándar permitiendo a los sistemas HMI/SCADA tener un interfaz controlado por el hombre, que convertiría las solicitudes genéricas de L/E en solicitudes específicas que cada dispositivo entendiese y viceversa. Como resultado, surgió toda una industria artesanal de productos basados en esta idea, permitiendo al usuario final implementar sistemas de calidad que interactuaban perfectamente con OPC. Inicialmente, el estándar OPC fue restringido al sistema operativo Windows, de hecho el acrónimo OPC nació de OLE para Control de Procesos (OLE for Process Control). Estas especificaciones, las cuales son conocidas como OPC Clásico, y han sido utilizadas con gran aceptación en múltiples industrias, incluidos el sector de la producción, fabricantes de automatismos, refinerías, gaseoductos, energías renovables y muchas otras. Con la introducción de las arquitecturas orientadas a servicios en los sistemas de producción, se introducen cambios y se plantean nuevos retos en seguridad y modelado de los datos. La fundación OPC desarrolló las especificaciones OPC UA para cubrir estas necesidades a la misma vez proporcionar una tecnología de futuro, con una arquitectura de plataforma abierta que permite mejorar, escalar y extenderse con el paso del tiempo. Estas son solo algunas de las razones por las que algunos miembros y organizaciones tecnológicas (Colaboradores) están actualizándose a OPC UA. En este proyecto trataremos solo el estándar OPC Clásico. 1.2.1 Estándar OPC Clásico. El estándar OPC Clásico está especificado para plataforma Microsoft Windows haciendo uso de COM/DCOM (Distributed Component Object Model) para el intercambio de datos entre componentes del software. Las especificaciones proporcionan definiciones separadas para el proceso de acceso a los datos, alarmas e históricos, que OPC cubre con OPC DA, OPC AE y OPC HDA. A continuación se puede ver una breve descripción de estos. Este proyecto solo hace uso de OPC DA. Sistema OPC para automatización mediante redes de estado 17 1.2.1.1 OPC Data Access (OPC DA) Define el intercambio de datos incluyendo valores, momento (tiempo) y calidad de información. Actualmente se encuentra en la versión 3.0 de la especificación, y cubre los siguientes aspectos:  Conceptos de la tecnología OPC Cliente/Servidor y definición de datos.  Actividades generales incluyendo definición de un espacio de direcciones y de su explorador, lector, escritor y subscriptor para las notificaciones de aquellos datos modificados.  Descripción detallada del interfaz, métodos, parámetros y comportamiento esperado.  Descripción detallada de los tipos de datos y estructuras.  Código de ejemplo (OPC Server) que contiene definición de interface y códigos de error. 1.2.1.2 OPC Alarms and Events (OPC AE) Define el intercambio de alarma y mensajes de información de tipo eventos también estado de variables y gestión de estado. Esta especificación describe el comportamiento de un servidor OPC que puede monitorizar áreas y notificaciones de clientes referente a condiciones de alarma. No han evolucionado desde la versión 1.1. Las especificaciones cubren:  Propósito de las alarmas y tecnología de eventos  Resumen de la arquitectura general y metodología de alarmas, eventos, acuses de recibo, consultas y áreas.  Descripción detallada del interfaz, métodos, parámetros y comportamiento esperado.  Descripción detallada de los tipos de datos y estructuras.  Código de ejemplo (OPC Server) que contiene definición de interface y códigos de error. 1.2.1.3 OPC Historical Data Access (OPC HDA) Define los métodos de consulta y analíticos que pueden aplicarse al historial y la trazabilidad de los datos. La especificación describe el comportamiento del servidor OPC referente al almacenaje de la información en una especie de BBDD, y como los clientes pueden recuperar dicha información usando OPC. Las especificaciones en su versión 1.2, cubren:  Visión general y propósito de la tecnología del histórico de datos.  Visión general de la arquitectura y metodología.  Descripción detallada del interfaz, métodos, parámetros y comportamientos esperados.  Descripción detallada de las funciones agregadas con ejemplos de consulta y resultados de cada uno.  Descripción detallada de los tipos de datos y estructuras.  Código de ejemplo de servidor OPC conteniendo el interfaz y el control de errores. 1.3 Servidor OPC Un servidor OPC es una aplicación de software (driver) que cumple con una o más especificaciones definidas por la OPC Foundation. El Servidor OPC hace de interfaz comunicando por un lado con una o más fuentes de datos utilizando sus protocolo nativos (típicamente PLCs, DCSs, básculas, Módulos I/O, controladores, etc.) y por el otro lado con Clientes OPC (típicamente SCADAs, HMIs, generadores de informes, generadores de Sistema OPC para automatización mediante redes de estado 18 gráficos, aplicaciones de cálculos, etc.). En una arquitectura Cliente OPC/ Servidor OPC, el Servidor OPC es el esclavo mientras que el Cliente OPC es el maestro. Las comunicaciones entre el Cliente OPC y el Servidor OPC son bidireccionales, lo que significa que los Clientes pueden leer y escribir en los dispositivos a través del Servidor OPC. Una de las principales funciones de los servidores OPC es la traducción de datos/mapping, es decir la función de un Servidor OPC es el traducir datos nativos de la fuente de datos en un formato OPC que sea compatible con una o más especificaciones OPC mencionadas anteriormente (ejemplo: OPC DA para datos en tiempo real). Las especificaciones de la OPC Foundation solo definen la porción OPC de las comunicaciones del Servidor OPC, así que la eficiencia y calidad de traducción del protocolo nativo a OPC y de OPC al protocolo nativo dependen enteramente de la implementación del desarrollador del Servidor OPC. Otra característica de los servidores OPC es que, comunican nativamente con las fuentes de datos, por ejemplo: dispositivos, controladores y aplicaciones. Las especificaciones de la OPC Foundation no especifican como el Servidor OPC se debe comunicar con la fuente de datos porque hay una gran variedad de fuentes de datos disponibles en el mercado. Cada PLC, DCS, controlador, etc. tiene su propio protocolo de comunicación o API que a su vez permiten la utilización cualquier cantidad de conexiones físicas (serial RS485 o RS232, Ethernet, wireless, redes propietarias, etc.) Dos ejemplos comunes de cómo se comunican los Servidores OPC con la Fuente de Datos son:  A través de una interfaz de programación de aplicaciones (API) para un driver personalizado escrito específicamente para la Fuente de Datos.  A través de un protocolo que puede o no ser propietario, o basado en un estándar abierto (por ejemplo utilizando el protocolo Modbus. (MatrikonOPC Server para Modbus) Entonces todo esto lo resuelve también el desarrollador, es la parte de adaptación formada por el protocolo de comunicaciones, adaptación de datos, etc, pero no queda definida por el estándar, obviamente por la diversidad. Uno de los servidores OPC mas completos que se ha podido probar, bajo experiencia propia es ServerEx del desarrollador Kepware. ServerEx posee una multitud de drivers y protocolos, para poder mantener una fluidez de datos entres casi cualquier controlador, PLC, etc. existente. 1.3.1 Direcciones OPC. TAG. Sin entrar en mayor detalle en los servidores OPC, sí que conviene entender el formato para acceder a los datos en el servidor. Estos están direccionados según una ruta que es simplemente un punto de dato y según la especificación OPC del tipo de servidor y del desarrollador del servidor se tendrá un direccionamiento concreto. Para el caso de Servidores OPC DA (Que es justamente lo que OPCSM VAI utiliza), el TAG identifica un acceso a una variable concreta, que puede ser un registro en un PLC, o un dispositivo concreto, o un canal en un controlador. El TAG es la última parte de la ruta. La ruta está formada por varias secciones (2 o 3, según el desarrollador del servidor), por ejemplo, en un servidor de Kepware la dirección está formado por tres partes “A”.”B”.”C”, donde A) Es el canal “Channel_1” B) Es el dispositivo “Omron_PC2” C) La variable o registro del PLC, por ejemplo Re1 que puede ser, R0.0, D0001, etc. Entonces la ruta quedaría “Channel_1.Omron_PC2.Re1” Conviene entender este direccionamiento ya que OPCSM VAI, al conectar a un servidor, extrae todos sus TAGs para poder ser asignados mediante elementos OPC, InOPC o OutOPC y realizar lecturas/escrituras. 19 21 2 ARQUITECTURA SOFTWARE l proyecto constituye un entorno de desarrollo visual de sistemas basados en diagramas de estado con un motor de ejecución (que interpreta los diagrama de estados de manera sincronizada procesando elementos que poseen un testigo) y un interfaz OPC, que permite dar vida a los sistemas implementados. El objetivo principal de dicho proyecto, además del valor añadido dado por OPC, es conseguir un entorno de desarrollo versátil, que permitiese facilitar al usuario la implementación de sus proyectos de automatización, facilitando el desarrollo de los distintos diagramas de estado, la organización de los elementos y gestión del proyecto. Esta idea, conlleva dar al usuario una serie de herramientas de edición visual, mediante objetos que ayude en todas las tareas de creación del sistema, además de utilidades y ayudas en la ejecución/depuración del desarrollo final. El primer paso antes de nada era saber en que línea debía ser resuelto el proyecto, con que tecnología de desarrollo, y la respuesta a todas estas premisas clamaban solucionar el problema mediante tecnología software orientada a objetos, ya que los propios requisitos dejaban ver que la única manera de mantener cierta organización era construir el software de manera modular, y que entre dichos módulos (objetos) existiese desde el más bajo al más alto en la jerarquía una comunicación. Por lo tanto el proyecto era adecuado para será ser implementado mediante objetos. Así pues, se hace necesario tener varios objetos base, elementos, con sus propiedades, métodos y funciones para realizar acciones entre ellos y que permitan en conjunto formar un entorno completo, estructurado y jerárquico. El producto final sería, un entorno para agilizar las tareas de edición y simulación de cara al usuario y poder ir extendiendo poco a poco, en cuanto a su funcionalidad, etc. Para conseguir todo esto, hay detrás una compleja programación, llevada a cabo en plataforma Microsoft Windows 7, bajo el entorno de desarrollo Microsoft Visual Studio .NET 2015 y lenguaje C#, que da vida a OPCSM VAI. El proyecto está compilado con una versión 4.6 del framework .NET En los distintos apartados que se podrán ver a continuación, se describirá con mayor detalle aspectos relevantes del desarrollo que darán una idea al lector, de la complejidad que supone realizar un entorno con estas características, para facilitar las tareas de desarrollo al usuario y conseguir una satisfactoria experiencia final cuando trabaja con OPCSM VAI. E No se equivoquen, la sencillez solo se logra a través del trabajo duro. - Clarice Lispector - Sistema OPC para automatización mediante redes de estado 22 OPCSM VAI - Entorno 2.1 Arquitectura de la aplicación Toda la aplicación está basada en programación orientada a objetos. Desde este instante se debe tener en cuenta este aspecto para entender cómo funciona todo. Para comenzar, se muestra un diagrama simple que permite proporcionar al lector un concepto general de la implementación de OPCSM VAI. Fig. 2.1-1 – Arquitectura del entorno OPCSM VAI En la figura 2.1-1, se puede interpretar que el entorno de edición de OPCSM VAI necesita de otros objetos (módulo Proyecto, módulo documento, objetos elementos) para que el usuario pueda crear un “Proyecto OPCSM” (Para el automatizado de procesos mediante diagrama de estados y estándar OPC). El “entorno” interactúa a través del “proyecto” con los distintos “documentos” y estos a su vez con los “elementos” que contiene, los cuales forman finalmente un sistema de diagramas de estados, para automatizar un proceso. Cada objeto (Proyecto, documento, elemento) posee una serie de métodos y propiedades necesarias a la hora de realizar sobre ellos acciones o que necesiten interacción entre ellos (Ya que hay una comunicación constante entre dichos objetos). Gracias a todo esto, es posible un “entorno” de desarrollo que proporcione al usuario toda la funcionalidad disponible de estos elementos. 2.2 Módulos 2.2.1 Objeto proyecto El objeto proyecto, (Librería cProjectOSM) es el objeto de más alto nivel en la jerarquía de objetos que posee el programa. Es el contenedor de todos los documentos que el usuario generará, para automatizar un proceso concreto. El objeto proyecto posee información pertinente acerca del proyecto real que se lleva a cabo, datos necesarios para su desarrollo y simulación, así como punteros a los distintos documentos creados. Posee una serie de métodos y propiedades, al igual que el resto de objetos, cuyo objetivo es permitir que una vez creada una instancia de este objeto, se pueda interactuar con él. Por sí solo, el objeto proyecto no posee entorno gráfico para el usuario, ya que esa parte se ha dejado absolutamente dedicada a los objetos documento, con lo cual se debe entender a este objeto como un almacén organizado de objetos documento. El objeto proyecto proporciona además a los documentos un elemento muy importante a la hora de realizar una ejecución del diagrama de estado, un especio de memoria compartido para todos los documentos del proyecto. Este espacio de memoria, se genera para que todos los elementos que posee un documento tengan donde almacenar sus datos, y puedan acceder a los datos de otros elementos, dando igual en que documento estén. Es una solución sencilla para permitir que los elementos puedan interactuar a la hora de ejecutar un diagrama de estados. Proyecto OPCSM Runtimer (Interprete) Documento Mem Sistema OPC para automatización mediante redes de estado 23 La parte de comunicación OPC se ha centralizado aquí también, así como las propiedades de la simulación. Con lo cual un proyecto posee información del servidor OPC al que conectarse, datos del tiempo base de reloj para la simulación, etc. Por otro lado, el proyecto también posee información sobre los datos del proyecto, como título, dirección en disco de los ficheros que lo componen, etc. 2.2.2 Objeto Documento 2.2.2.1 Descripción breve del objeto documento. El objeto documento, (Librería cDocumentOSM) es un objeto compuesto por dos partes, una parte visual (formulario) y una instancia de código no visual. Es el segundo nivel dentro de la jerarquía de elementos de un proyecto OPCSM, es quizás el más importante de todos, ya que posee toda la funcionalidad de edición para el usuario, pero no podría funcionar solo sin estar contenido en un proyecto, ya que se quedaría aislado del resto de documentos. Al crear una instancia del objeto documento, se crea una hoja de edición en entorno gráfico, sobre la cual se pueden ejecutar acciones con el ratón y el teclado. De cara al usuario se muestra una especie de hoja tipo plano, con un cajetín predefinido que es posible cumplimentar mediante acciones sobre el documento. El tamaño de la hoja, el espaciado de la cuadrícula, entre otras propiedades son configurables, así pues este objeto es bastante moldeable para ajustarse a la necesidad del proyecto que se esté implementando. Fig. 2.2-1 – Objeto documento. Por otro lado posee métodos para ayudar al usuario en la edición de los diagramas de estado, permite mover, copiar, cortar, borrar, seleccionar, hacer zoom, imprimir, etc. acciones que se pueden llevar a cabo referidas a los elementos contenidos en el documento. La otra parte inseparable del objeto documento, contiene el motor de métodos y propiedades del “documento”, entre otras funciones necesarias. Esta parte es un contenedor de elementos que siguen al documento en la jerarquía de la estructura del software, que son los elementos que forman los diagramas de estado. Al igual que el proyecto contenía documentos, estos contienen elementos. Sistema OPC para automatización mediante redes de estado 24 El sistema gráfico no es más que un lienzo vacío en el que se van agregando elementos dibujados. La técnica de invalidado de área gráfica y el redibujado con doble-buffer, dan vida a este entorno. Ejemplo, si se desea mover un elemento pasando por encima de otros, no es necesario borrar estos cada vez y volverlos a redibujar, tan solo se vuelven a redibujar todos los elementos del área visible cada vez que algún elemento sea modificado e interfiera en el resto, de este modo se genera un efecto muy nítido y suave de movimiento. Para solicitar un redibujado de los elementos en pantalla, existe la acción de invalidar, indicando que el área ya no es adecuado y hay que redibujar todo el contenido del documento visible, en el área gráfica. 2.2.2.2 Serialización de elementos. La serialización es el proceso de convertir un objeto en una secuencia de bytes para conservarlo en memoria, una base de datos o un archivo. Su propósito principal es guardar el estado de un objeto para poder crearlo de nuevo cuando se necesita. El proceso inverso se denomina deserialización. El objeto se serializa en una secuencia que, además de los datos, contiene información sobre el tipo de objeto, como la versión, referencia cultural y nombre de ensamblado. Esa secuencia se puede almacenar en una base de datos, un archivo o en memoria. (Fig. 2.2-2) Fig. 2.2-2 – Esquema de una serialización La serialización permite al desarrollador guardar el estado de un objeto y volver a crearlo cuando es necesario, y proporcionar almacenamiento de objetos e intercambio de datos. A través de la serialización, un desarrollador puede realizar acciones como enviar un objeto a una aplicación remota por medio de un servicio de red, pasar un objeto a disco directamente sin más, etc. Todos los elementos contenidos en el documento están serializados, esto quiere decir que a la hora de realizar acciones tan simples desde el punto de vista del usuario, como copiar, cortar, pegar o guardar, y muy complejas desde el punto de vista de la programación, gracias a la serialización, todos los objetos que lo son, están preparados para ser gestionados en memoria fácilmente ya que al fin y al cabo, dichas acciones se basan en ayudarse de un espacio de memoria para poder realizar el duplicado y recuperación, o la salvaguarda de datos en disco, etc. A la hora de serializar los objetos para este proyecto, se codifican en XML. Esto permite además obtener ficheros en disco fácilmente editables desde fuera del entorno de desarrollo OPCSM VAI, si en algún caso se necesita corregir alguna propiedad puntual de algún elemento, ya sea del propio proyecto o documento. 2.2.2.3 Acciones y propiedades del objeto documento. Antes se ha comentado que el documento posee una serie de métodos, funciones y propiedades que pueden ser usadas para que el usuario pueda realizar la edición de un proyecto OPCSM. Este interfaz, formado por un conjunto de acciones que se llevan a cabo sobre el documento, existen gracias a un complicado motor de decisiones implementado en la parte visual del objeto documento. Este motor funciona en base a eventos sobre el ratón y el teclado que son interpretados dependiendo de unos estados, que van cambiando dependiendo de Sistema OPC para automatización mediante redes de estado 25 las acciones de edición. De esta manera se puede ir deduciendo que es lo que el usuario quiere hacer en cada momento y facilitarle el trabajo, así pues es la aplicación la que se adapta al usuario y no al revés (Como puede ocurrir en otros entornos gráficos de desarrollo, donde la tarea de diseño se hace muy complicada para el usuario) Para entenderlo, véase el ejemplo a continuación, teniendo en cuenta el siguiente entorno: “Se desea mover un elemento contenido en el documento desde una posición a otra de la pantalla, teniendo en cuenta que también es posible realizar acción de selección de grupo de elementos en el documento.” Fig. 2.2-3 – Ejemplo del motor de decisiones. Para el ejemplo propuesto el motor de decisiones del objeto documento necesita conocer en qué momento de la edición se encuentra el usuario, es decir que estado está activo cada vez; Donde está el ratón, que botón se ha pulsado, sobre que elemento se ha pulsado, si se mueve con un botón pulsado, etc. Se puede entender el motor de decisiones como un autómata con distinto estados excitados por los eventos de teclado y ratón. (Ver fig. 2.2-3) A continuación se hará una descripción de las acciones más relevantes del objeto documento, para ver las herramientas que se ponen a disposición del usuario en la tarea de implementación.  Acción CREAR Es una acción esencial en la edición de un diagrama, permite añadir al documento elementos activos (Que se verán más adelante) para ir conformando el contenido del proyecto OPCSM. Esta acción, genera una instancia del elemento seleccionado, le da unas propiedades y lo almacena en el contenedor del documento, además le asigna un espacio de memoria. Una vez esto, el objeto aparecerá físicamente en el entorno gráfico del documento.  Acción ELIMINAR Es otra de las acciones básicas, al contrario que la acción crear, esta elimina un elemento seleccionado del entorno gráfico, y posteriormente del contenedor de elementos del documento. A su vez, si este elemento está enlazado con otros, sus enlaces también son eliminados para no dejar residuos.  Acción SELECCIONAR Permite decirle al interfaz de desarrollo que elemento o elementos se desean marcar para editar. Cuando se marca un elemento con el ratón y este es detectado como tal, se selecciona. También ocurre una selección, si se arrastra el ratón sobre el documento y se capturan aquellos que están dentro del recuadro formado, entonces estos serán seleccionados como un grupo. Esto se denomina SELECCIÓN MULTIPLE. Estado de reposo Sobre objeto Mover objeto Sobre docum Click sostenido Mover ratón Click sostenido Mover ratón Select box Sistema OPC para automatización mediante redes de estado 32 2.2.3.11 Salida OPC Librería: cOPCoutOSM | Tipo base: Estado Este elemento permite escribir el valor de la “Variable source” en la ruta del servidor OPC definido por “OPC tag”. Enviar un valor desde el sistema al servidor OPC. 2.2.3.12 Entrada OPC Librería: cOPCinOSM | Tipo base: Estado Este elemento permite escribir el valor obtenido de la ruta del servidor OPC definido por “OPC tag”, y almacenarlo en la variable interna. Entrada de un valor desde un servidor OPC hacia el sistema. 2.2.3.13 Objetos interactivos. Estos objetos tienen un funcionamiento asíncrono, ya que pueden ser actuados en cualquier instante, aunque el valor que envían al ser actuados, está sincronizado con el reloj de ejecución. Uno de los elementos básicos es el botón, que se describe a continuación. Librería: cButtonOSM | Tipo base: Estado Este elemento envía un “1” a su variable interna, cuando es actuado por el usuario y mientras está activo. En el momento que no está actuado, está almacenando un “0”. Si se aplica un doble-click al botón se produce el anclado del botón a “1” sin necesidad de seguir pulsándolo. 2.2.3.14 Objetos de indicación. Permiten representar el valor de “Variable source”, mediante objeto gráfico. Librería: cDisplayOSM | Tipo: Interactivo Este elemento posee varias propiedades descritas a continuación, que permiten personalizar la representación del dato que muestra. Propiedad Valores / Campos Descripción Mode Binary Multivalue Numerical Binary: Representa “ON” con “1” y “OFF” con “0” Multivalue: (No definido aun) Numerical: Representa valores numéricos mas una unidad a la derecha del número. Ejemplo: 120 Kg Sistema OPC para automatización mediante redes de estado 33 Num. Type Decimal Integer Engineer Binary8 Binary16 Binary32 Binary64 Binary128 Binary256 Hexadecimal Time String Tipos para representar un valor en modo “Numerical”. NOTA: El tipo “Hexadecimal” no está aun definido. Unit Cadena de caracteres que representa una unidad de medida definida por el usuario. Value Valor absoluto representado en el indicador Font size Tamaño de la fuente del indicador 2.2.3.15 Objeto gráfico Permite representar valores de la variable source en una gráfica a lo largo del tiempo. Librería: cGraphicsOSM | Tipo: Interactivo Este elemento posee varias propiedades descritas a continuación, que permiten personalizar el objeto gráfico. Sección Propiedad Descripción Graphic Autoscale Actualiza la escala del eje Y de manera automática Main title Título superior del gráfico Max value scale Valor máximo del eje Y, cuando autoscale = false Min value scale Valor mínimo del eje Y, cuando autoscale = false Y-axis unit Unidad para mostrar en el eje Y Sistema OPC para automatización mediante redes de estado 34 2.2.3.16 Objetos de etiquetado. Estos objetos no realizan ninguna función durante la ejecución, son elementos únicamente de etiquetado, para poner texto en el sistema. No necesitan mayor mención en este documento. Text_label_0 Librería: cTextOSM | Tipo: Interactivo Este elemento posee varias propiedades descritas a continuación, que permiten personalizar la etiqueta. Sección Propiedad Descripción Color Background color Color para el fondo de la etiqueta Text color Color para el texto de la etiqueta Design Show background Indica si se visualiza el color de fondo o no Show border Indica si se visualiza el borde de la caja Font Font name Fuente elegida Font size Tamaño de la fuente Text Align Tipo de alineado del texto en la caja Text Texto a mostrar en la etiqueta 2.2.4 Sistema de intercambio de datos OPCSM VAI hace uso de un sistema de memoria compartida entre todos los documentos, esta memoria es un contenedor de variables tipo cadena, que apuntan a cada elemento activo del proyecto (Elementos como estados, transiciones, expresiones, contadores, etc). Gracias a esta memoria compartida, todos los elementos pueden leer y escribir de/en cualquier elemento de cualquier documento, de manera muy sencilla. Fig. 2.2-5 – Esquema del sistema de memoria compartida. Al crear un proyecto se genera automáticamente esta memoria de intercambio y a medida que se van creando elementos en el documento se genera en ella un espacio asignado a cada uno de estos. A dicha asignación de memoria se denomina “variable interna” y que se puede encontrar en las propiedades del elemento como “My Variable”. v1Counter v2Expression Documento 1 Documento 2 Contador Expresion define {v1Couner} function { v1Counter * 2} Sistema OPC para automatización mediante redes de estado 35 La memoria de intercambio es otro objeto, formado por propiedades y métodos. El objetivo es hacer sencillo la lectura y escritura de información en dicha memoria. Para ello entre otras funciones existen dos comandos, “write” y “read”, a los cuales se le pasa como parámetro el nombre de la variable de la cual queremos leer o en la cual queremos escribir. Librería: cMemOSM Funcion Parámetros Descripción Write (Nombre variable, Dato) Nombre variable Dato Escribe “Dato” en la memoria asignada a “Nombre variable” Read (Nombre variable) Nombre variable Devuelve el dato leído de la memoria asignada a “Nombre variable” 2.2.5 Entorno de desarrollo Todo el conjunto de objetos descritos en los apartados anteriores, por si solos no tienen utilidad, ya que deben estar integrados en un software para poder hacer uso de su funcionalidad y permitir que puedan interactuar en conjunto. Para ello se ha desarrollado OPCSM VAI, un entorno que contiene una serie de herramientas para facilitar la labor de implementación del proyecto OPCSM. Este es entonces el programa principal desde el punto de vista del usuario, para crear proyectos, añadir documentos al proyecto, añadir elementos a los documentos, preparar el sistema en cuanto a etiquetado, editarlo, ejecutarlo, depurarlo, etc. En los apartados siguientes se dará a conocer el entorno para familiarizarse con él y entender cómo funciona, aunque ya se ha hecho un análisis en mayor detalle en apartados anteriores de los módulos que conforman dicho software, en esta sección da una visión de todos los módulos conectados. 2.2.5.1 Área de edición En el momento que se crea un proyecto, se habilita el área de edición y se añade un documento para comenzar a trabajar. En este instante proyecto, documento y elementos están enlazados para poder implementar los sistemas de estado. El área de edición es puramente un contenedor MDI (Multi-Document Interface) que permite ir agregando ventanas hijas a la ventana padre (Definida por el programa principal), esta forma de contener los documentos del proyecto permite tener organizado todo el conjunto de ventanas de una forma más adecuada. Fig. 2.2-6 – Área de edición – OPCSM VAI En el área de edición (figura 2.2-6) se llevan a cabo acciones sobre los documentos. Toda la funcionalidad la proporciona el interfaz gráfico de dicho documento ya que el área de edición no es más que eso, un contenedor que agrupa todos los documentos del proyecto en curso. Area de edición Sistema OPC para automatización mediante redes de estado 36 El programa principal interactúa con el documento activo, el documento activo es aquel que el usuario tiene en el nivel superior de la vista, y para hacerlo activo es tan simple como hacer click en la ventana. Cuando es detectado se pueden realizar sobre acciones de edición, como interactuar con los elementos de su interior, agregar nuevos elementos, guardar el documento, imprimir, ver sus propiedades, etc. Todo este interfaz adaptado a las condiciones establecidas en cada momento, permite facilitar al usuario la tarea de edición, frente a otros programas para los que no se puede intuir el funcionamiento, y entonces eso hace complicar su uso. Esta premisa ha sido muy tenida en cuenta en el desarrollo del software, porque la experiencia final del usuario es importante, tanto como la utilidad de la herramienta y lo versátil que pueda llegar a ser. Fig. 2.2-7 – Representación de varios documentos y el documento activo. En la figura 2.2-7 se puede observar el documento activo marcado en rojo (La marca es una indicación de este documento, no aparece visible en el programa) 2.2.5.2 Módulos extras El área de edición queda complementada con un conjunto de ventanas que añaden utilidad al conjunto ya disponible de herramientas de las que dispone el entorno para el desarrollo de los proyectos OPCSM. Estos elementos concretamente son:  La ventana de propiedades  El editor de código  La ventana de depuración  La ventana de errores. Entre ellas la ventana propiedades es concretamente un objeto propio del entorno .NET, multipropósito que permite directamente mostrar las propiedades que han sido definidas en un objeto a nivel de código, previo formateo de los datos que se desea mostrar, es posible obtener una sencilla herramienta con la cual caracterizar los elementos y de fácil uso, evitando tener que programar un objeto específicamente diseñado para tal labor. A continuación es posible ver en detalle dicha ventana, además de la ventana de edición de código, las cuales merecen una especial mención, pues quizás son las de mayor frecuencia de uso. Barra de estado Sistema OPC para automatización mediante redes de estado 37 Ventana de propiedades – Muestra todas las propiedades de un elemento del documento o las propiedades comunes de un grupo de elementos. También muestra las propiedades del propio documento o del proyecto. De esta manera se puede editar el objeto fácilmente y cambiar sus propiedades, acercándose al estilo propio de un entorno de desarrollo software con el que quizás se esté más familiarizado. Editor de código – El editor de código permite definir funciones matemáticas y expresiones lógicas para los elementos “expression” y “condition”. 2.2.5.3 Motor de ejecución El motor de ejecución es una herramienta importante dentro del software, ya que permite ejecutar el sistema de estados que se ha creado. El funcionamiento de este motor está basado en un reloj, cuyo periodo queda configurado en las propiedades del proyecto. Por cada flanco de reloj se ejecuta una rutina que hace avanzar un testigo en base a unas premisas que dependen de la conexión entre nodos y de las condiciones de avance (Por ejemplo como el caso del elemento “condition” que dejará pasar el testigo si la expresión lógica resulta en “1”) El motor de ejecución es un intérprete, ya que no compila a código nativo el sistema implementado antes de ejecutarlo, tan solo lo va interpretando sobre la marcha. El motor de ejecución no es un sistema de tiempo real, principalmente porque se ejecuta sobre una plataforma que no cumple las premisas de un sistema en tiempo real. En futuras mejoras se puede crear un motor sobre otra plataforma y permitir ejecutar el sistema con condiciones de tiempo real, esto por supuesto llevará entonces una fase de compilado, pero de este modo podrá ser ejecutado en un microcontrolador, sistema Linux/Unix, etc. Sistema OPC para automatización mediante redes de estado 38 El motor de ejecución del intérprete de OPCSM VAI posee dos modos de funcionamiento:  Modo Normal – Por cada flanco de reloj se disparan los nodos tipo estado (State, Expression, Counter, Variable, etc) que poseen el testigo y avanzarán si la expresión lógica de los elementos tipo transición “hijos” (Colgados de él) da como resultado “1”  Modo Petri – Por cada flanco de reloj se disparan todas las transiciones y solo se deja pasar el testigo cuando la expresión lógica de la transición resulta en “1” El motor de ejecución en modo Normal, 1. Se realiza una preparación previa del sistema de estados. Se hace una “foto” del estado de partida, que nodos poseen testigo, etc. Comienza la ejecución (Por cada flanco de reloj) 2. Se escanean todos los nodos del documento, y todos los documentos del proyecto, en busca de aquellos que poseen un testigo de ejecución (marcador). 3. Se lanza un trigger sobre dichos elementos (método que poseen todos los elementos activos) 4. Se espera el resultado de procesar el trigger y ver si es satisfactorio o por el contrario hay un error. 5. En el caso de ser satisfactorio, se localiza el/los nodos hijos enganchados al nodo que posee el testigo, y se avanza el testigo hasta ellos, a la espera del siguiente flanco de reloj. 6. Se para el proceso si hay algún elemento “END” en otro caso se continua otra vez por el punto (2) Cuando se detiene el programa, se vuelve a la configuración inicial (Guardada por la “foto” realizada al principio de la ejecución) Al no ser un sistema en tiempo real, no se asegura un tiempo de ejecución máximo hasta el próximo flanco de reloj, es decir, esto es lo que ocurre en la ejecución (Ver imagen abajo) Fig. 2.2-8 – Representación en tiempo del disparo de un elemento STATE y un elemento EXPRESSION. Expression T Expression Sistema OPC para automatización mediante redes de estado 39 Se define en el diagrama de la figura 2.2-8 en color burdeos el disparo y ejecución de un elemento “STATE” y en color verde el disparo y ejecución de un elemento “EXPRESSION” con una expresión matemática compleja. Se puede observar que la ejecución del elemento “STATE” se hace antes de llegar el siguiente flanco de reloj, pero vemos que el elemento “EXPRESSION” sin embargo usa mas de un flanco de reloj además depende de la complejidad de la expresión matemática definida y de los valores para los que calcularla, con lo que no es posible asegurar que la ejecución de la expresión se pueda hacer en un tiempo configurado fijo, es decir no se sabe con exactitud cuándo acabará la ejecución.  Ejemplo de funcionamiento paso a paso del motor de ejecución, Paso 1 El motor de ejecución es activado por un flanco de reloj. Toma una foto del estado actual del sistema. En este caso se almacena que S0 tiene inicialmente el testigo. Paso 2 El motor de ejecución es activado por un flanco de reloj. Se recorren todos los nodos, y se disparan (Lanza un comando trigger) los nodos que llevan el testigo. Una vez ejecutado se le quita el testigo y se pasa a la transición que cuelga del nodo. En este caso la transición a la que debe pasar es T1. Sistema OPC para automatización mediante redes de estado 40 Paso 3 El motor de ejecución es activado por un flanco de reloj. El motor de ejecución recorre todas las transiciones y dispara (Lanza un comando trigger) aquellas que llevan el testigo. Una vez ejecutado se le quita el testigo y se pasa al nodo que cuelga de la transición. En este caso es el nodo S2 el que adquiere el testigo 41 48 49 4 USO DE LA APLICACIÓN n anteriores capítulos se ha empleado tiempo en describir aspectos técnicos y funcionales del proyecto, en parte interesantes para conocer el software, sus componentes, etc. En este capítulo se dedicarán algunos párrafos al conocimiento del software desde el punto de vista práctico, dando a conocer las pautas para crear y ejecutar un proyecto OPCSM completo con conexión a un servidor OPC. Los apartados siguientes componen una guía de uso habitual con una explicación detallada de todas las funciones que incorpora esta primera versión funcional del entorno de desarrollo. 4.1 Instalación 4.1.1 Requisitos del sistema Para la ejecución de OPCSM VAI es necesario disponer de un PC con plataforma Microsoft Windows 7 o superior, procesador mínimo Intel Core i3 o similar, con al menos 4 GB de RAM. Se debe tener instalado el paquete Microsoft .NET Framework v4.6 4.1.2 OPC Foundation Core Components. Antes de arrancar el programa también es necesario tener instalado el pack “core components” en versión 32 bits desde OPC Foundation. Este pack proporciona las librerías necesarias para listar servidores (OPCENUM.exe) y el wrapper para comunicar con ellos. Este pack puede ser descargado desde su propio site accediendo a la siguiente dirección de internet, https://opcfoundation.org/developer-tools/developer-kits-classic/core-components/#not-archived Para llevar a cabo la descarga es necesario registrarse en la web. NOTA: La versión 3.0.106 del OPC core components, está incluida en el paquete de instalación de OPCSM VAI E Sistema OPC para automatización mediante redes de estado 50 4.2 Consideraciones en el texto A lo largo del texto se encontrarán abreviaturas relacionadas con acciones que el usuario puede llevar a cabo. En este apartado se dan a conocer para tenerlas en cuenta. Click-[izquierdo/derecho] Click con el botón izquierdo ó derecho del ratón. Click-[izquierdo/derecho]-mantenido Click con el botón izquierdo ó derecho del ratón pulsado y mantenido. Arrastre-de-ratón Mover ratón con el botón que se haya indicado, manteniéndolo pulsado Tecla-xxx-mantenida Tecla “xxx” del teclado, pulsada sin soltar hasta indicarlo. ESC Anular acción AÑADIR OBJETO STATE SHIFT Acción extendida con ratón o teclado AÑADIR OBJETO TRANSITION F4 Propiedades F5 Ejecutar F8 Editor de código CURSORES Mover objetos seleccionados con precisión Sistema OPC para automatización mediante redes de estado 51 4.3 Teclas de accesos rápido Muestra la ventana de propiedades del objeto seleccionado, grupo o documento activo. Ejecuta el diagrama de estados implementado en todos los documentos del proyecto, en modo de ejecución NORMAL. Ejecuta el diagrama de estados implementado en todos los documentos del proyecto, en modo de ejecución PETRI. Muestra la ventana de edición de código del objeto con capacidad de scripting. Añade un objeto STATE al documento activo Añade un objeto TRANSITION al documento activo + Añade un objeto EXPRESSION al documento activo + Añade un objeto CONDITION al documento activo Mueve los objetos seleccionados con precisión, en el documento activo. Anula la acción activada. Deselecciona los objetos seleccionados. + Copiar los elementos seleccionados al portapapeles. + Pegar los elementos que están en el portapapeles, en el documento activo. + Copiar los elementos seleccionados al portapapeles, y eliminarlos del documento activo. Eliminar los objetos seleccionados. (Tecla DELETE o SUPR) Tecla “+”, aumentar zoom Tecla “-”, disminuir zoom Sistema OPC para automatización mediante redes de estado 52 4.4 Generalidades del entorno. El software se compone de un entorno común, formado por un área de edición, una barra de menú, una barra de herramientas y una barra de estado en la parte inferior. Fig. 4.3-1 – Programa principal – OPCSM VAI  Barra de menú – Compone el conjunto de menús con las opciones de edición, herramientas y controles de ejecución necesarios para el desarrollo del proyecto.  Barra de herramientas – Contiene una serie de enlaces rápidos a las herramientas y comandos más habituales, para agilizar el trabajo.  Barra de estado – Indica el estado de edición, ejecución, errores, etc.  Área de edición – Es el área de diseño, donde se localizan los documentos que se agregan al proyecto. 4.5 Crear un Sistema de estados OPC. 4.5.1 Crear un proyecto nuevo Antes de iniciar un nuevo desarrollo es necesario generar un proyecto OPCSM. (fig. 4.3-1 y 4.3-2) Para ello se accede al menú File  New proyect, esto mostrará una ventana de diálogo para configurar los parámetros esenciales para crear el proyecto.  Project title – (Opcional) Es el título que describe el proyecto, es un campo de descripción.  Path of the Project – Ruta donde se almacenará el directorio del proyecto y todos los documentos. Por defecto se genera configura en la ruta “Mis documentos” de Windows.  Directory name – Directorio que contiene el fichero del proyecto y los ficheros de los documentos.  Filename Project – Nombre del fichero de proyecto. Por defecto se genera uno automáticamente, pero puede ser modificado. Barra de herramientas Area de edición Barra de estado Barra de menú Sistema OPC para automatización mediante redes de estado 53 Fig. 4.4-1 – Detalle del menú FILE Fig. 4.4-1 – Detalle de la ventana de generación de nuevo proyecto. Una vez finalizada la configuración de los parámetros del proyecto OPCSM, se debe pulsar CREATE para generar en el entorno el proyecto, así como el directorio y los ficheros en disco (En la ruta especificada). Con esto el entorno queda listo para comenzar a desarrollar un nuevo sistema con diagrama de estados. Se puede acceder al resto de propiedades del proyecto, mediante el menú Project  Properties que mostrará todas las propiedades del proyecto y las cuales pueden ser modificadas a excepción del nombre del fichero de proyecto y la ruta de almacenamiento NOTA: Para cambiar el nombre del fichero y la ruta del proyecto, debe hacerse fuera del entorno de desarrollo a través del sistema operativo renombrando el fichero y cambiando la ruta manualmente. Esto no debe aplicarse a los documentos, ya que estos SI PUEDEN ser cambiados de nombre dentro del entorno) Cuando se abra el fichero de proyecto, automáticamente el programa detecta la nueva ruta y extrae de ella el resto de documentos. En la figura 4.3-3 se puede ver la ventana de propiedades del proyecto con mayor detalle. Sistema OPC para automatización mediante redes de estado 54 Fig. 4.4-3 – Detalle de la ventana de propiedades del proyecto Se pueden observar las propiedades del proyecto en las que destacaremos,  OPC Server – Información del servidor OPC al que se conecta el sistema  OPC Server IP/Port – IP del servidor en red, donde están los servidores OPC instalados.  Description – Campo de información resumen del proyecto (Opcional)  Name – Nombre del proyecto  Title – Título del proyecto (Opcional)  Master timer interval [ms] – Configura la base de tiempo del reloj de simulación. 4.5.2 Crear un sistema 4.5.2.1 Configuración del documento El siguiente paso en el desarrollo del proyecto, es crear el sistema. Este se organizará dentro de documentos que no son más que hojas donde se agregan elementos interconectados. El proyecto puede estar formado por todos los documentos que sean necesarios, con el objetivo de organizar el sistema lo mejor posible. Cuando se ha generado por primera vez el proyecto, se crea automáticamente una hoja nueva (documento), lista para comenzar a insertar elementos e interconectarlos. Esta hoja se puede configurar para caracterizarla, agregando información en su cajetín, como es, título del proyecto, firma, fecha de creación, autor, logotipo, etc. Para ello se hará click con el botón derecho del ratón encima de una zona libre del documento, y se debe seleccionar la opción Properties del menú desplegable, esta acción mostrará las propiedades del proyecto (figura 4.3-4) Sistema OPC para automatización mediante redes de estado 55 Fig. 4.4-4 – Detalle de la ventana de propiedades del documento En la ventana propiedades se pueden observar los siguientes campos que pueden configurarse para caracterizar el documento.  Caption – Configura el sufijo que identifica la ventana en la ventana de exploración del proyecto.  Grid size – Configura el tamaño de la grid del documento.  ISO paper size – Configura el tamaño del papel del documento ajustándolo a la norma ISO seleccionada.  Path – Indica la ruta donde el fichero .xml del documento, está contenido, es un campo de solo lectura. En las secciones Sheet y Sheet – image se pueden ver campos relativos a los datos que se muestran en el cajetín. La configuración del documento puede hacerse indistintamente en el momento que se desee, no es necesario para poder comenzar a desarrollar el sistema. 4.5.2.2 Inserción y edición de elementos para el sistema En este paso se comenzará a insertar elementos que compondrán el sistema, en el documento. Para ello se dispone de varias posibilidades, mediante teclas de acceso rápido, barra de menú o menú contextual. Además el área de documento posee un interfaz muy versátil para realizar la edición del sistema durante su implementación, pudiendo realizar acciones con el ratón y teclado conjuntamente, que será detallado en sucesivos apartados. Sistema OPC para automatización mediante redes de estado 56 Para la inserción de elementos puede hacerse mediante,  Barra de herramientas Mediante el botón Objects se puede acceder a varios grupos de elementos que han sido descritos en el capítulo 2 desde el punto de vista más técnico, pero que da una idea de su posible uso. Desde este botón es posible agregar elementos al documento activo en ese momento.  Menú contextual Otro modo es mediante el menú contextual, haciendo click con el botón derecho sobre una zona libre del documento y seleccionando la opción, Add objects… que permitirá desplegar igualmente un grupo con los tipos de elementos y a su vez acceder a los elementos de cada tipo, de manera similar al caso anterior.  Teclado Existen teclas de acceso rápido a los elementos más importantes, se pueden observar en la tabla siguiente. Tecla Descripción S ó Shift + S Agrega un elemento STATE T ó Shift + T Agrega un elemento TRANSITION Shift + E Agrega un elemento EXPRESSION Shift + C Agrega un elemento CONDITION Sistema OPC para automatización mediante redes de estado 57 Una vez el elemento está insertado, aparecerá en el documento y es posible realizar acciones de edición sobre él; Seleccionarlo, moverlo, cambiar su tamaño, modificar sus propiedades. Es posible copiarlo, cortarlo y pegarlo, eliminarlo, etc.  Selección simple Para seleccionar un elemento, simplemente se hace click sobre él. En programa lo detecta y lo sombrea. En el elemento aparecerá además el testigo rojo para cambio de tamaño. NOTA: Para deseleccionar un elemento, basta con hacer click en una zona libre del documento o pulsar la tecla ESC. Fig. 4.4-5 – Detalle de elemento no seleccionado (izquierda) y seleccionado (derecha) En la figura 4.3-5 se puede observar la selección simple de un elemento (lado derecho), el elemento queda sombreado y rodeado de un área punteada. Cuando un elemento está seleccionado se pueden hacer varias operaciones sobre el:  Cambio de tamaño Hacer click-izquierdo-mantenido sobre el testigo rojo y Arrastre-de-ratón hacia abajo para agrander o hacia arriba para achicar.  Mover Hacer click-izquierdo-mantenido encima del objeto y arrastre-de-ratón, para mover el objeto.  Movimiento de precisión. Mediante las teclas cursores cuando el objeto está seleccionado.  Copiar, Cortar, Marcar, Eliminar y ver Propiedades. Estas acciones pueden realizarse desde el menú contextual (Click-derecho sobre el objeto seleccionado) mediante la barra de menús, con el menú Edit o mediante el teclado. fig. 4.3-6 Fig. 4.4-6 – Detalle de opciones de edición. Sistema OPC para automatización mediante redes de estado 64 Fig. 4.4-12 – Detalle de la conexión con el servidor OPC. 4.5.6 Ejecutar el sistema. Esta sería la fase final del desarrollo, para comprobar que el sistema funciona acorde a las premisas que se le hayan establecido. La acción de ejecución se realiza mediante la barra de botones superior o mediante las teclas de función F5, F6 y SHIFT+F5. Hay varios modos de ejecución, modo normal y modo Petri. Fig. 4.4-13 – Detalle del menú ejecución. Para ejecutar el sistema en modo normal, basta con pulsar la tecla de función F5 o la opción de menú “Start with edition”, para el caso de ejecutar el sistema de estados con la filosofía de las redes de Petri, se pulsará la tecla de función F6 o selección de la opción “Start on Petri mode”. Pausar Parar Ejecutar Paso a paso Reset de marcadores Paso a paso Petri Sistema OPC para automatización mediante redes de estado 65 También es posible para el sistema, o pausarlo. Existen también el modo de ejecución paso a paso, y la ejecución con o sin depuración. Fig. 4.4-14 – Detalle del menú ejecución. Para activar el modo depuración basta acceder al menú “Simulator” y pulsar la opción “Debug mode”. Cuando el modo debug está activado, es posible trazar la ejecución de un sistema mediante la ventana “Debug console” del menú “Window”. Fig. 4.4-15 – Detalle del modo debug y la ventana de depuración. 4.5.6.1 Modos de ejecución. En este apartado se explicará cada uno de los funcionamientos. Modo Normal – En este caso el motor de ejecución disparará los elementos que contienen el marcador. Si se observa la fig. 4.4-13 el elemento S0 esta sombreado en color verde, esto significa que el motor de ejecución lanzará dicho elemento en un flanco de reloj. Cuando un elemento es lanzado o disparado, se realiza una Sistema OPC para automatización mediante redes de estado 66 ejecución de la función que tiene programada realizar, por ejemplo el elemento de la fig. 4.4-13 al ser disparado pondrá en su variable interna un valor constante definido o en otro caso el valor “1”, cuando está marcado; En caso de no estar marcado, será “0”. Cuando un elemento se ha ejecutado después de ser disparado, pasa el testigo a los elementos siguientes según el sentido de la flecha, a los que está conectados. En el ejemplo de la fig. 4.4-13, una vez ejecutado el testigo pasará a la transición T1, y será disparado. Así sucesivamente durante la ejecución del sistema. Modo Petri – En este modo se sigue la filosofía de ejecución de redes de Petri, disparando las transiciones que están habilitadas para ser ejecutadas. Una transición está habilitada cuando los elementos tipo estado conectados a ella, poseen el testigo. El modo de ejecución Petri se ha implementado para compatibilizar el entorno con sistemas basados en redes de Petri. 67 68 5 CONCLUSIONES El proyecto descrito en este documento presenta una herramienta de desarrollo basada en un interfaz gráfico útil para implementar procesos automáticos, agilizando su desarrollo gracias a las herramientas de edición que posee y mejorando la compresión del sistema, ya que la presentación en nodos y el seguimiento de la ejecución por paso de testigo, permiten ver como el sistema está trabajando en todo momento. A lo largo de la implementación del proyecto se han encontrado numerosas dificultades, dado que conseguir que una aplicación tenga un interfaz amigable para el usuario y que permita simplificar las tareas de implementación y edición, supone tener detrás una compleja programación. En ocasiones los distintos componentes del proyecto han tenido que ser re-especificados y re-escritos cuando la funcionalidad comenzó a aumentar y se deseaba proporcionar un interfaz más ágil cada vez. Uno de las partes impactadas por este hecho, fue el motor de decisiones que lidera la funcionalidad del interfaz gráfico, para conocer en cada momento cual es la intención del usuario, de ahí la sencillez de edición conseguida. Pese al gran esfuerzo que ha supuesto llevar a cabo esta herramienta, bien planificada en un principio llega a ser gratificante y da belleza al resultado final, pues permite conseguir funcionalidad muy precisa, y ser mejorada sin una excesiva complejidad. En definitiva puede decirse que el desarrollo de este proyecto ha permitido adquirir una experiencia más profunda no solo en el sentido de la programación, si no en el concepto de ergonomía y aspectos relacionados con la experiencia del usuario que a veces se olvida en herramientas de ingeniería con un carácter tan técnico y especializado. Para finalizar se plasman a continuación posibles líneas futuras, que podrían seguirse partiendo de este software que aumentarían y mejorarían tanto su funcionalidad como utilidad. - Mejorar el entorno gráfico basándolo en DirectX, para acelerarlo mediante tarjeta gráfica, ya que se ha hecho uso del GDI+ que carece de este aspecto. - Mejorar el entorno de ejecución e implementación, añadiendo nuevos tipos de datos, como array, tratamiento de cadenas, etc. - Añadir más elementos interactivos, slides, depositos, válvulas, etc para hacer más real el sistema implementado. - Hacer uso de OPC UA, más avanzado que OPC Clásico. - Permitir conectar con varios servidores OPC a la vez, asignando a los elementos InOPC y OutOPC, a donde realizar sus operaciones. - Crear un motor de ejecución en plataforma que permita implementar un sistema de tiempo real. Esto podría ser implementado en sistemas operativos Linux/Unix. - Crear un compilador para poder ejecutar el programa desarrollado de manera autónoma en otra plataforma, esto eliminaría la característica de seguimiento de testigo, pero permitiría ejecutar los sistemas desarrollados como un autómata. Esto por ejemplo da la idea de generar un compilador para Arduino, dado que es un hardware de bajo coste y poder ejecutar el diagrama de estados generado directamente, consiguiendo automatismos de bajo coste, para soluciones en los que se pueda aplicar. - Crear un OPCSM BOX (Hardware con motor OPCSM) para ejecutar directamente el sistema implementado en él y creando una centralita de E/S, OPC con múltiples conexiones WiFi, discretas, etc. para control domótico, industrial de bajo coste. - Añadir elementos para control remoto y mediante una aplicación en Android poder interactuar con el sistema implementado. 69 70 6 REFERENCIAS 1. OPC Foundation – The industrial interoperability standard - https://opcfoundation.org/ 2. Mathos parser .NET library – Mathematical Expression Parser – Ethan Dagner – United State - https://mathosparser.codeplex.com/ 3. FastColoredTextBox .NET library – Fast Colored TextBox for Syntax Highlighting. The text editor component for .NET – Pavel Torgashop - https://github.com/PavelTorgashov/FastColoredTextBox 4. OPC Data Access Wrapper class – Sourceforge – Developer site - https://sourceforge.net/projects/opcdawrapper/ 5. Stack overflow – Developers Site - http://stackoverflow.com/ 6. MSDN Library – Microsoft Developer Network - https://msdn.microsoft.com/ 7. OPCConnect.com – OPC Connect site - http://www.opcconnect.com/dotnet.php 8. Kepware ServerEX – Kepware – Servidor OPC - http://www.kepserverexopc.com/kepware-kepserverex-features/ 9. GrayBox Simulator – Graybox Software – Free OPC Server - http://www.graybox.net/download_graysim.php 71 72 7 ANEXO 7.1 Principales mapas del código 7.1.1 OPCSM.exe y librería principal OPCStateMatic.dll Sistema OPC para automatización mediante redes de estado 73 7.1.2 Conjunto de objetos que forman OPCStateMatic