Representación Gráfica de los lenguajes de Marcado en Automatización Industrial

Transcripción

1 Representación Gráfica de los lenguajes de Marcado en Automatización Industrial F. López, E. Irisarri, E. Estévez, D. Orive, M. Marcos Dpto. Ingeniería de Sistemas y Automática ETSI de Bilbao University of the Basque Country (Spain) {fabian.lopez, edurne.irisarri, elisabet.estevez, dario.orive, marga.marcos}@ehu.es Resumen Las aplicaciones industriales actuales demandan el diseño de sistemas más complejos, seguros, fiables, que exhiban un alto grado de flexibilidad y reutilización por lo que un objetivo prioritario es lograr un alto grado de integración de herramientas de desarrollo. Los Lenguajes de Marcado se están convirtiendo en la pieza clave para lograr esta integración pero requieren de personal experto para su interpretación, por ser lenguajes textuales. Se hace necesaria una representación gráfica no sólo de la descripción de la arquitectura del proyecto de automatización sino, de modo especial, de los programas desarrollados mediante lenguajes gráficos. Mediante el uso de tecnologías XML se puede realizar de modo automático una conversión entre la representación textual y una representación gráfica en base a gráficos vectoriales. Se propone una metodología basada en tecnologías XML para la definición de los elementos gráficos de un modelo y se muestra su aplicación en el caso de los lenguajes gráficos del estándar IEC Palabras Clave: Lenguajes de Marcado, representación gráfica, tecnologías XML 1 INTRODUCCIÓN En el campo de la automatización industrial, el proceso de ingeniería sigue siendo una amplia área a mejorar en cuanto a eficiencia. Muchas empresas padecen la situación de tener que trabajar en un entorno en el cual herramientas muy heterogéneas participan en las diferentes fases del proceso. Existe, por tanto, una necesidad evidente de alcanzar la interoperabilidad entre diferentes herramientas de manera que pueda reducirse la brecha que actualmente existe entre las diferentes fases del proceso de diseño. En este sentido, hay que destacar que el uso de Lenguajes de Marcado (MLs) está jugando un rol fundamental en el intercambio, reutilización y almacenamiento del contenido común a todo el proceso de ingeniería de automatización. Asimismo, ha sido imprescindible establecer un estándar abierto con alta aceptación en el mercado. En esta línea, en los campos de la Automatización y Robótica se están dedicando grandes esfuerzos en alcanzar una mejora de la producción, optimización del proceso y reducción de tiempo y costes. Hoy en día, la integración, reutilización, flexibilidad y optimización son características sin duda necesarias para adaptarse a un mercado cada vez más cambiante y competitivo. Esta situación ha provocado que la mayoría de los fabricantes, proveedores de servicios y usuarios, trabajen conjuntamente y lancen proyectos en común que conduzcan a una solución. En la automatización industrial, para obtener la interoperabilidad entre herramientas independiente de la plataforma y del fabricante, se utilizan actualmente como medio los MLs. En [4] se propone la utilización de XML para solucionar los problemas que surgen en la descripción de dispositivos en el entorno de buses de campo diferentes. En relación con los lenguajes de programación, el estándar más utilizado para programar las aplicaciones de automatización es el IEC [10]. Este estándar propone un modelo de software y unos lenguajes de programación para los sistemas de control y medida de procesos industriales. Por otra parte, PLCopen [13], asociación internacional independiente de fabricante y de producto, cuya misión es liderar la resolución de temas relacionados con la programación del control, tiene como principal objetivo apoyar la utilización de estándares internacionales en esta área. PLCopen está organizada en diferentes comités técnicos (TCs) entre los que se encuentra el TC6. En concreto, desde el TC6 para XML se ha propuesto un interfaz abierto entre los diferentes tipos de herramientas de software, definido como ML, que ofrece la posibilidad de transferir la información que está en pantalla a otras plataformas diferentes. Igualmente, el estándar IEC [19] amplía el concepto de Function Block (FB), presentado previamente por el estándar IEC de lenguajes de programación para Controladores Lógicos Programables [8]. Permite a los usuarios definir aplicaciones de control distribuido como un conjunto de redes de FBs conectadas a través de sus entradas y

2 salidas y define también un lenguaje de marcado para definir las aplicaciones distribuidas. Un ejemplo más ambicioso es el caso del proyecto denominado Lenguaje de Marcado de Automatización (Automation Markup Language, AutomationML TM ) [2] recientemente lanzado. Los participantes en este proyecto, iniciado en Octubre de 2006, son importantes compañías industriales del campo de la automatización, usuarios, proveedores de software y de servicio, así como universidades en calidad de investigadores. Su principal objetivo es reducir los esfuerzos de ingeniería, mejorando al mismo tiempo la calidad, mediante la interconexión de las diferentes herramientas que se utilizan a lo largo de todo el proceso de ingeniería. AutomationML TM incorpora estándares muy consolidados para cubrir desde la topología de la planta, su geometría y cinemática, hasta su lógica, y constituye un formato de información intermedio común a todas las fases de la ingeniería de la planta. Se ha planteado como un estándar abierto que combina formatos estándar perfectamente consolidados, implementados por sus propios ML cuyo valor y madurez ya han sido probados en el mercado. En la actualidad, AutomationML incorpora principalmente tres ML: CAEX (IEC 62424)[14] como formato de nivel superior para las propiedades y relaciones de los objetos dentro de su propia estructura jerárquica, COLLADA 1.5 [11] (Khronos Group) para los atributos gráficos e información 3D, y conexiones y dependencias entre objetos que dan apoyo al plan del movimiento y PLCopen XML para la lógica (secuencias de acciones, descripción del control, comportamiento interno de los objetos, y conexiones I/O) según el estándar IEC [12], [9]. Este último se encuentra en estos momentos en proceso de incorporación. Por tanto, se puede afirmar que XML se está estableciendo como la base del ML estándar para el campo de la automatización industrial. Sin embargo, el objetivo general es alcanzar la interoperabilidad entre herramientas. Este trabajo quiere ir aún más allá, dado que estos MLs representan modelos de dominio de la aplicación de automatización expresados en XML, se pretende utilizar tecnologías XML relacionadas para filtrar, procesar y formatear la información contenida con el fin de obtener su representación gráfica, generar documentación de la aplicación o diseñar repositorios de componentes. Esto es posible mediante la utilización de otras tecnologías XML, como XSL[21], lenguajes gráficos basados en XML [16] o bases de datos basadas en XML [7]. En concreto, este artículo trata sobre la visualización gráfica de los objetos de la aplicación. El esquema que se sigue en el artículo es el siguiente: el apartado 2 presenta brevemente las tecnologías XML que posibilitan el filtrado, procesamiento, y formateo de la información XML. En el apartado 3 se presenta la metodología a seguir para obtener la salida gráfica. Todo esto se ilustra mediante un caso de estudio que utiliza los lenguajes gráficos del estándar IEC TECNOLOGÍAS XML En este apartado se describen brevemente las tecnologías XML del World Wide Web Consortium (W3C) que permiten, utilizando Lenguajes de Marcado, describir proyectos genéricos de automatización mediante schema, y filtrar y procesar documentos XML que representa un proyecto específico, visualizando la información gráfica. 2.1 SCHEMAS El XML schema (.xsd) [20] recoge todas las restricciones léxicas y sintácticas que definen el nuevo lenguaje, y es compartido por todos los ficheros XML que se expresan en ese lenguaje. Define, por tanto, qué elementos puede contener otro documento XML, cómo están organizados, y qué atributos y de qué tipo pueden tener sus elementos. Un documento XML será válido si, además de estar bien formado, respeta la estructura y restricciones que le imponga su schema asociado. En particular se han utilizado los mecanismos de simpletype y complextype proporcionados por el schema de WC3 para definir en XML los elementos de los lenguajes teniendo en cuenta todas sus características y haciendo uso de atributos, restricciones y modelos de presentación. Otros elementos del schema de W3C, tales como sequence y choice se han utilizado para definir el estilo arquitectónico. Por otra parte se han utilizado elementos del esquema para definir restricciones (key/keyref) junto con reglas de schematron. 2.2 SCALABLE VECTOR GRAPHICS (SVG) Scalable Vector Graphics (SVG) es un estándar de gráficos basados en XML [6]. Se diseñó para convertirse en el estándar de los formatos gráficos vectoriales, así como GIF y JPEG se han convertido en los formatos estándar de los gráficos bitmaps en la Web. A diferencia de los bitmaps, los gráficos vectoriales se escalan según el tamaño de la ventana, sin sufrir ninguna distorsión, y son generalmente más pequeños que su equivalente bitmap. Dado que se definen mediante XML se pueden integrar fácilmente en documentos XHTML. Por tanto, el uso de gráficos SVG proporciona grandes ventajas, desde dos puntos de vista: SVG como gráfico vectorial: el tamaño es menor que el de cualquier otro formato. Además existe una

3 versión comprimida de SVG (ZSVG). La calidad de la imagen no disminuye al hacer zoom porque se vuelve a dibujar con la nueva escala a partir de su descripción textual. La combinación de SVG con un lenguaje de programación como JavaScript facilita al usuario final la manipulación directa de la imagen. SVG como tecnología XML: Se trata de código abierto, por lo que puede ser generado y manipulado mediante cualquier editor de texto. Hay buenas herramientas de libre disposición para su visualización, por ejemplo Adobe SVG viewer[1], Batik SVG viewer [3] y otros. 2.3 XML STYLESHEET LANGUAGE TRANSFORMATIONS (XSLT) Las hojas de estilo XML (XSL): permiten filtrar y procesar documentos XML mediante plantillas o templates. En XSL, se dispone de dos tipos de templates[17]. Las template match son utilizadas para el procesamiento de un elemento XML concreto. Este procesamiento se puede organizar mediante las llamadas templates name, que facilitan estructurar de la transformación. 2.4 XML INTERFACES Document Object Model (DOM) [5] y Simple API de XML (SAX) [15] son dos ejemplos de interfaces XML. Son independientes de plataforma y lenguaje, y muy útiles para los programadores, de cara a generar y manipular documentos XML junto con lenguajes de programación, como por ejemplo java. 3 METODOLOGÍA DE LA TRANSFORMACIÓN Esta sección presentan los pasos seguidos para definir y usar los elementos gráficos de un modelo expresado siguiendo un particular Lenguaje de Marcado. El LM utilizado es el definido por comité técnico TC6-XML de la organización PLCopen, en concreto, con el lenguaje FBD, uno de los lenguajes gráficos definidos en el estándar IEC La parte 3 del estándar IEC especifica la gramática, la sintaxis y la semántica, de cinco lenguajes de programación de PLCs. Concretamente, dos de ellos son textuales y tres gráficos. En relación con los tres lenguajes gráficos proporcionados por el estándar: El Gráfico Secuencial de Funciones (SFC) está centrado en la estructuración secuencial de las tareas de una aplicación automática mediante programas y bloques funcionales. El Diagrama de Contactos (LD) basado en la presentación gráfica de la lógica de relés. Está especialmente orientado a las señales booleanas. El Diagrama de Bloques Funcionales (FBD) se utiliza para la programación de procedimientos complejos, mediante objetos gráficos y bloques, como en los diagramas de circuitos electrónicos. Es muy utilizado en la industria de procesos. Además, el estándar define algunos elementos comunes a los tres lenguajes gráficos: segmentos (Networks), definidos mediante una etiqueta (Label), compuestos mediante línea (Lines) que representan el flujo de la señal y sirve para interconectar los elementos de los lenguajes gráficos. Los bloques (Blocks) que representan operaciones dentro de las funciones o los bloques funcionales (FB). Finalmente, los conectores (Connectors) permiten la extensión de las líneas. En relación al control de la ejecución del programa se definen dos elementos más: El elemento Jump, que se puede considerar como una salida booleana de un bloque; permite la transferencia del control del programa a un determinado segmento especificado mediante su etiqueta. El elemento Return transfiere retorna el control a la entidad invocante cuando su entrada booleanas es verdadera. El estándar IEC especifica los mecanismos de que dispone el usuario para definir gráficamente una aplicación, pero no precisa un formato de importación/exportación. Por ello, cada herramienta utiliza su propio formato de almacenamiento y normalmente ofrece un conjunto de funciones Application Program Interface (API) o bien una opción de importación/exportación. Con el fin de alcanzar la interoperabilidad entre herramientas el comité técnico TC6-XML de PLCopen ha definido un interfaz abierto para toda clase de herramientas software. Este interfaz permite transferir la información que está sobre la pantalla de una plataforma software a otra. El formato del interfaz es textual mediante schemas XML, formados por elementos XML que corresponden con los elementos del modelo software del estándar IEC El estilo arquitectónico se construye mediante los mecanismos de selección, secuencia y multiplicidad del schema W3C [20]. En cuanto a los lenguajes gráficos, algunos elementos son comunes a los tres lenguajes, mientras que otros son específicos se alguno de ellos. Por ejemplo, para el caso del FBD, los elementos Block, InVariable, OutVariable, Label, Jump y Return.

4 En el schema de PLCopen los elementos relativos a los objetos de los lenguajes gráficos contienen, además, información gráfica, como por ejemplo, la anchura y altura de los bloques, las coordenadas x e y de su posición en la pantalla, o las líneas de interconexión entre bloques. A veces, la información gráfica se define como atributos de un elemento XML (por ejemplo, los Bloques tienen como atributos la anchura y la altura) y otras veces como un nuevo elemento del schema (por ejemplo, un elemento hijo del Bloque es su posición en la pantalla). Para mostrar los pasos de esta metodología, vamos a utilizar un código FBD muy sencillo. La Figura 1 muestra una función muy simple (InRange) que comprueba si el contenido de una variable está entre dos valores Maximun y Minimum. Para ello se utilizan tres funciones estándar (LT, GT y AND). Figure 1: ejemplo sencillo en FBD La Figura 2 presenta el fichero XML correspondiente a la función InRange, siguiendo el schema PLCopen para el lenguaje FBD. En la imagen se ha resaltado la información gráfica (width, height y position). Graphical dependent part Figura 2: función InRange según el formato PLCopen El proceso de transformación de un fichero XML que sigue un Lenguaje de Marcado hasta obtener el fichero SVG que visualiza la información gráfica se puede implementar siguiendo una metodología bottom-up. Los pasos de la metodología se van a presentar para el caso particular del lenguaje FBD del estándar IEC expresado en el lenguaje de marcado propuesto por PLCopen. Como se ha indicado anteriormente el lenguaje de marcado propuesto por el comité técnico TC6-XML de PLCopen no sólo expresa la funcionalidad del programa, es decir, los componentes del programa y sus relaciones, sino que también incluye la información gráfica asociada (tamaño y posición). Por tanto, es necesario extraer del fichero XML que representa el código FBD tanto la funcionalidad (variables, bloques y conexiones) como sus dimensiones y posiciones relativas en la pantalla. Esta información se utilizará para obtener el fichero SVG. 3.1 PASO 1: DEFINICIÓN DE LOS ELEMENTOS DEL LENGUAJE Los elementos básicos de FBD son bloques, variables, conexiones, saltos, retornos, etc. que se pueden construir combinando elementos básico como Box, circlenegated, formalparameterinput, formalparameteroutput, etc. Los POUs se definen mediante una combinación de elementos básicos del lenguaje que se escalan y trasladan a posiciones concretas para representar la funcionalidad del POU. Concretamente, para definir los elementos del lenguaje se seguirán las siguientes subetapas Definición de los elementos gráficos básicos En primer lugar se definen los elementos gráficos básicos: box, negation, formal parameters, etc.

5 mediante el lenguaje SVG, tal como se ve en la Figura 3 que muestra el fichero SVG como tecnología XML. La Figura 4 representa la visualización de ese fichero como gráfico vectorial. <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns=" xmlns:po=" /xml/tc6.xsd" exclude -result-prefixes=" po"> <xsl:template name="plantillas"> <svg:g id="block" type ="Basic" fill="{$colorblock}" stroke="{$colorstrokeblock }" width-stroke="{$widthstroke }"> <svg:rect x="0" y="0" width="{$xfactor}" height ="{$yfactor}"/> </svg:g > <svg:g id="circlenegated" type="basic" stroke="{$colorstroke}" fill="white "> <svg:circle cx="0" cy="0" r="{$yfactor}" /> </svg:g > <svg:g id="jump" type ="Basic" stroke="{$colorstroke}" stroke-width="{$widthstroke}"> <svg:line x1="0" y1="0" x2="{1*$xfactor}" y2="{round(1.8*$yfactor)}" /> <svg:line x1="0" y1="{round(3.3*$yfactor )}" x2="{1*$xfactor }" y2="{round(1.8*$yfactor)}" /> <svg:line x1="{1*$xfactor}" y1="0" x2="{2*$xfactor}" y2="{round(1.8*$yfactor)}" /> <svg:line x1="{1*$xfactor}" y1="{round(3.3*$yfactor)}" x2="{2*$xfactor} y2="{round(1.8*$yfactor)}" /> </svg:g >... </xsl:template > </xsl:stylesheet> Figura 3: definición de los elementos Básicos Figura 4: visualización de los elementos Básicos Personalización de la representación gráfica Con objeto de permitir al usuario seleccionar características de la visualización gráfica, como colores, tipo de fuente, etc., se definen un conjunto de variables. Por ejemplo, para permitir el escalado de la imagen, se define la variables xfactor e yfactor, para configurar los textos, las variables FontFamily, fontsize y fontcolor o para determinar la distancia mínima entre POUS, la variable yfromlastvariable, etc. : <xsl:variable name="xfactor">8</xsl:variable> <xsl:variable name="yfactor">6</xsl:variable> <xsl:variable name="fontcolor">rgb(0,0,128)</xsl:variable> <xsl:variable name="fontfamily">arial</xsl:variable> Mediante el uso de estas variables de configuración, el código de un programa que utilice un lenguaje gráfico se puede visualizar de modos diferentes. definiciones del código SVG. Cada elemento de los lenguajes gráficos se define como una agrupación de elementos básicos a los que se les asigna características comunes (color, anchura de línea, tipo de fuente, etc). Por ejemplo, el elemento Return es una combinación de líneas junto con el texto RETURN: <g id="return" type="basic" stroke="{$colorstroke}" stroke-width="{$widthstroke}" fill="{$fontcolor}" font-size="{round(1.2*$fontsize)}" font-family="{$fontfamily}"> <line.. /> <line /> <text >RETURN</text> <line.. /> <line.. /> </g> En la definición de los elementos del lenguaje se utilizan las variables de configuración descritas en el la subetapa anterior, por ejemplo las que se refieren a los colores de la líneas o de relleno de los bloques, las fuentes de los textos, etc. En cuanto al posicionamiento de los elementos del lenguaje, cuando se definen se sitúan en el origen de coordenadas y cuando son utilizados para definir el código (la funcionalidad) se les referencia escalándoles y trasladándoles a la posición absoluta que ocupan en el gráfico. Por ejemplo, para dibujar un bloque que tiene una anchura de 10 y una altura de 28, situado en las coordenadas (20, 40), se debe referenciar el elemento block trasladándole y escalándole con sus valores absolutos mediante la siguiente sentencia SVG: <use href="#block" transform="scale(10, 18) translate (20,40)"/> 3.2 PASO 2: VISUALIZACIÓN DEL PROYECTO DE AUTOMATIZACIÓN Para obtener la representación gráfica del proyecto es necesario generar la funcionalidad de todos los POUs utilizados y en una fase posterior generar le fichero SVG que contenga el proyecto completo de automatización. La siguiente figura muestra el entorno general de esta transformación. FBD2svg_1 FBD2svg_ Elementos del lenguaje, como agrupación de elementos básicos PLCOpen.xml XSLT FBD_1.svg XSLT FBD_2.svg La definición en SVG de los elementos del lenguaje a partir de los elementos gráficos básicos se realiza mediante el elemento <g>, que tiene un atributo identificador, lo que permite ser referenciado cuando se vaya a utilizar, por ejemplo, desde la parte de confs_svg defs_svg confs_svg Figura 5: generación del gráfico del proyecto de automatización

6 3.2.1 Generación de la funcionalidad de los POUs La generación del gráfico que representa la funcionalidad de un POU se basa en la aplicación de la una hoja de estilo XML a un fichero XML. Como se ha indicado anteriormente el fichero XML inicial sigue la gramática de PLCopen. La hoja de estilo consiste en un conjunto de templates que buscan, en el fichero de entrada, cada uno de los elementos del lenguaje y sus relaciones, y procesan esta información generando el fichero SVG, para lo cual hacen uso de los elementos del lenguaje descritos en SVG y los parámetros de configuración (ver Figura 6). Iconos genéricos y configuración de la visualización Lista de templates (blocks, returns, jumps, etc.) hasta representar la funcionalidad del POU que está siendo analizado. <xsl:template name="pou"> <xsl:param name="yinitial"/> <xsl:param name="positionpou"/> <xsl:variable name="pounumber" select="count(.//po:pou)"/> <xsl:for-each select="//po:pou[position()=$positionpou]"> <svg:g id="{@name}" type="pou"> <xsl:variable name="networkname"><xsl:value-of select="@name"/> </xsl:variable> <svg:text x="{1*$xfactor}" y="{3*$yfactor}" fill="{$colormessage}" font-size="{round(1.6*$fontsize)}" font-family="{$fontfamily}"> <xsl:value-of select="concat ('(* ',$NetworkName, ' *)')"/> </svg:text> <svg:g transform="translate({1*$xfactor}, {3*$yFactor})"> <xsl:apply-templates select=".//po:block"/> <xsl:apply-templates select=".//po:return"/> <xsl:apply-templates select=".//po:jump"/> <xsl:apply-templates select=".//po:label"/> <xsl:apply-templates select=".//po:connector"/> <xsl:apply-templates select=".//po:continuation"/> </xsl:for-each> <xsl:if test="$positionpou < $POUNumber"> <xsl:call-template name="pou"> <xsl:with-param name="yinitial" select="($yinitial+$networkheight)"/> <xsl:with-param name="positionpou" select="($positionpou+1)"/> </xsl:call-template> </xsl:if> </xsl:template> Figura 7: template XSL pou La template block genera un gráfico SVG que está formado por un elemento básico box (<svg:rect>). Dentro de la caja se visualiza el nombre del POU que está siendo instanciado y, si el bloque corresponde a la instancia de un Bloque Funcional, se visualiza el nombre de la instancia encima de la caja. Los parámetros formales del POU también se pueden visualizar dentro de la caja. La Figura 8 muestra las transformaciones descritas. Figura 6: XSL para generar el fichero SVG En este sentido, la hoja de estilo XSL contiene tantas templates match como elementos gráficos tienen los lenguajes del estándar IEC En el caso del lenguaje FBD, se han codificado las siguientes templates: pou, block, variable, return, jump, label, connector y continuation. Para generar el fichero SVG final, el fichero XSL hace uso también de los elementos básicos definidos en el paso previo (defs_svg), y de los parámetros para configurar la visualización (confs_svg). La template principal de la hoja de estilo, llamada project, organiza la ejecución del resto de las templates. Esta template llama a la template pou, que aplica los algoritmos adecuados a la representación del la funcionalidad del POU en la gramática XML y la trasforman a su representación en SVG tal como se ve en la Figura 7. La template pou genera un nuevo elemento gráfico (<svg:g>.) por cada elemento POU del fichero de entrada XML. En este gráfico se tienen en cuenta los parámetros de configuración indicados anteriormente. Además la template pou llama a las diferentes templates que generan los elementos básicos <xsl:template match="po:block"> <xsl:variable name="xblock"> <xsl:value-of select="./po:position/@x"/></xsl:variable> <xsl:variable name="yblock"> <xsl:value-of select="./po:position/@y"/></xsl:variable> <xsl:variable name="refblock"> <xsl:value-of select="@localid"/> </xsl:variable> <xsl:element name="svg:g"> <xsl:attribute name="id"><xsl:value-of select="concat($refblock,'_',@typename)"/> </xsl:attribute> <xsl:attribute name="transform"><xsl:value-of select=" concat('translate(',$xblock*$xfactor,',',$yblock*$yfactor,')')"/></xsl:attribute> <svg:rect x="0" y="0" y2="{$yfactor*(@height+$yblock)}" width="{$xfactor*@width}" height="{$yfactor*@height}" fill="{$colorblock}" stroke="{$colorstrokeblock}" width-stroke="{$widthstroke}"/> Caja para instancia <xsl:call-template name="blocktypename"/> <xsl:call-template name="blockinstancename"/> de Función o Bloque Funcional <xsl:apply-templates select="./po:inputvariables/po:variable" mode="input"> </xsl:apply-templates> <xsl:apply-templates select="./po:outputvariables/po:variable" mode="output"> <xsl:with-param name="width" select="@width"/> </xsl:apply-templates> Parámetros formales de entrada y salida </xsl:element> <xsl:apply-templates select="./po:inputvariables/po:variable/po:connectionpointin/po:connection" mode="input"> <xsl:with-param name="xblock" select="$xblock"/> <xsl:with-param name="yblock" select="$yblock"/> </xsl:apply-templates> Parámetros reales de entrada y salida <xsl:apply-templates select="../po:outvariable"/> </xsl:template> Figura 8: template XSL block Finalmente esta template llama a las encargadas de visualizar las conexiones con los parámetros de entrada y salida. Conexiones que pueden provenir/dirigirse de/a parámetros de otros bloques o de/a otras variables. El proyecto de automatización que se está utilizando como ejemplo consta de tres POUs: un ejecutivo

7 cíclico (Main), una Función (InRange) y un programa (PLC_PRG) en el que se instancia la función: La funcionalidad del POU del ejemplo sencillo de la Figura 1, la función de InRange, se puede ver como: Tres variables de entrada (Value, utilizada dos veces, Maximum y Minimum) Una variable de salida (InRange) Tres bloques relacionados de una forma concreta (las entradas negadas del bloque AND son las salidas de los bloques LT y LG) del lenguaje como de los gráficos que representan la funcionalidad de los POUs. En el ejemplo: los POUs Main, InRange y PLC_PRG. Definiciones de elementos básicos Cuando se exporta, siguiendo el schema PLCopen, el fichero XML de salida contiene la descripción de la funcionalidad (elementos del lenguaje y las variables) junto con las relaciones entre ellos. El fichero también incluye tanto el tamaño de los elementos (altura y anchura de los bloques) como las posiciones en el plano (coordenadas x e y de los bloques, de los textos y de las líneas de conexión entre los elementos), tal como se ve en la Figura 2. Tras aplicar la hoja de estilo se obtiene un fichero SVG que contiene las definiciones de los bloques (nombre, identidad, tamaño, posición, etc.), las líneas de conexión entre bloques, las variables de entrad y de salida junto con sus conexiones a los bloques correspondiente. La figura 9 muestra el fichero SVG generado. <svg:g id="inrange" type="pou"> <svg:text x="8" y="18" fill="green" font-size="19" font-family="arial">(* InRange *)</svg:text> <svg:g transform="translate(8, 18)"> <svg:g id="0_gt" transform="translate(208,180)"> <svg:rect x="0" y="0" y2="264" width="72" height="84" fill="rgb(209,209,255)" stroke="rgb(51,51,153)" width-stroke="2"/> <svg:text x="36" y="12" fill="rgb(0,0,128)" text-anchor="middle" font-size="12" font-family="arial">gt</svg:text> <svg:g id="inputpin" type="element" transform="translate(0, 0)"> <svg:use xlink:href="#formalparameterinput" transform="translate(0, 18)"/> <svg:g id="inputpin" type="element" transform="translate(0, 0)"> <svg:use xlink:href="#formalparameterinput" transform="translate(0, 42)"/> <svg:g id="ouputpin" type="element" transform="translate(0, 0)"> <svg:use xlink:href="#formalparameteroutput" transform="translate(72, 18)"/> <svg:g id="connectionlinefromvariable" type="element"> <svg:text x="144" y="204" fill="rgb(0,0,128)" font-size="12" font-family="arial"> Value </svg:text> <svg:polyline fill="none" stroke="rgb(0,0,128)" stroke-width="2" points=" "/> <svg:g id="connectionlinefromvariable" type="element"> <svg:text x="128" y="228" fill="rgb(0,0,128)" font-size="12" font-family="arial"> Minimum </svg:text> <svg:polyline fill="none" stroke="rgb(0,0,128)" stroke-width="2" points=" "/> <svg:g id="connectionoutvariableandlinefrom" type="element"> <svg:g id="4_and" transform="translate(312,36)"> Función <svg:g id="8_lt" transform="translate(152,36)"> InRange Figura 9: gráfico de la función InRange Este paso, de la metodología propuesta, finaliza con un fichero SVG que contiene los POUs gráficos utilizado en el proyecto de automatización tal como se ve en el Figura 10. El fichero SVG resultante está formado por un conjunto de definiciones (<svg:defs>.</svg:defs) tanto de los gráficos correspondientes a los elementos POUs del Proyecto de Automatización Figura 10: Ejemplo de la definición de los gráficos del proyecto de automatización Una vez que se han generado los gráficos necesarios el paso final consiste en la generación de un fichero que muestra la funcionalidad de proyecto completo de automatización Generación de los gráficos del proyecto de automatización Para hacer esto se utiliza una template name que calcula las dimensiones de cada POU gráfico y los imprime en cascada. La aplicación crea una referencia a cada POU gráfico, y la escala y traslada. La siguiente figura muestra parte de la template que genera el fichero final (printingpous). <xsl:template name="printingpous"> <xsl:param name="yinitial"/> <xsl:param name="positionpou"/> <xsl:variable name="pounumber" select="count(//svg:defs/svg:g)"/> <xsl:for-each select="//svg:defs/svg:g[position()=$positionpou]"> <xsl:if test="./@type='pou'"> <xsl:element name="svg:g" > <xsl:attribute name="transform"> <xsl:value-of select="concat('scale(',$xscale,',',$yscale,')')"/> </xsl:attribute> <xsl:element name="svg:use"> <xsl:attribute name="xlink:href"> <xsl:value-of select="concat('#',@id)"/> </xsl:attribute> <xsl:attribute name="transform"> <xsl:value-of select="concat('translate(0,',$yinitial,')')"/> </xsl:attribute> </xsl:element> </xsl:element> </xsl:if> Crear gráfico de un POU </xsl:for-each> </xsl:template> Figura 11: template XSL para visualizar los POUs

8 Las Figuras 12 y 13 muestran el resultado de la transformación. La Figura 12 representa el fichero resultante, como tecnología XML, y la Figura 13 tal como es visualizado mediante un browser. final de generación automática de documentación. Se ha expuesto el uso de estas tecnologías para el caso particular de los lenguajes gráficos de estándar IEC , para programación de PLCs. Agradecimientos Este trabajo ha sido financiado por MCYT y FEDER a través de los proyectos DPI y DIPE Referencias Visualizar los POUs del proyecto de automatización Figura 12: Gráficos del proyecto de automatización ejemplo Figura 13: Visualización del fichero SVG 4 CONCLUSIONES El presente trabajo trata de mostrar otros usos de los numerosos Lenguajes de Marcados definidos en el entorno de la automatización industrial. Se han presentado las tecnologías XML que permiten filtrar, procesar y visualizar gráficos como una poderosa herramienta para la visualización de gráficos a partir de ficheros XML Estas tecnologías se puede integrar fácilmente con los Lenguajes de Marcado utilizados en el campo de la automatización industrial para obtener representaciones gráficas e incluso con un objetivo [1] Adobe SVG viewer: [2] AutomationML, Web del proyecto AutomationML en: [3] Batik SVG viewer, en [4] Birkhofer R.. XML for Automation Devices. XML Europe [5] DOM. Disponible en: [6] Eisenberg J. David (2002). SVG Essentials. Ed. O REILLY. [7] exist Available at: [8] IEC International Electrotechnical Commission. IEC International Standard: IEC , Function blocks Part-1. [9] IEC, International Electrotechnical Commission, IEC International Standard IEC :2003, Programmable Controllers. Part3: Programming Languages, [10] John, Karl-Heinz and Tiegelkamp, M., IEC : Programming Industrial Automation Systems. Springer [11] Khronos Group, Web del proyecto COLLADA en: [12] Lewis R.M, (1998) Programming Industrial Control Systems using IEC IEE Control Engineering Series [13] PLCopen, Website: [14] RWTH Aachen, Web de CAEX: d%3d [15] SAX Project, Disponible en: [16] SVG [17] Tidwell D., XSLT, O Reilly, [18] Van der Vlist E., XML Schema, O Reilly, [19] Vyatkin, Valeriy. IEC Function Blocks for Embedded and Distributed Control System Design, Ed. ISA O3NEIDA [20] XSD. XML Schema Part 0: Primer (Second Edition), W3C REC-xmlschema , Disponible en [21] XSLT