Definición y visualización de los lenguajes gráficos de IEC , basada en tecnologías XML

Transcripción

1 Definición y visualización de los lenguajes gráficos de IEC , basada en tecnologías XML E. Estévez, F. López, E. Irisarri, D. Orive, F. Pérez, M. Marcos, {elisabet.estevez, fabian.lopez, edurne.irisarri, dario.orive, federico.perez, 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. Características necesarias para adaptarse rápidamente a un mercado cada vez más cambiante y competitivo. La estandarización es un objetivo clave a alcanzar en la integración y la reutilización en este tipo de aplicaciones. Los esfuerzos de estandarización internacionales han llevado a la definición del estándar IEC La parte 3 de este estándar define un modelo de software para especificar proyectos de automatización haciendo énfasis en la reutilización de software. Actualmente una gran parte de los principales fabricantes de Controladores Lógicos Programables (PLC) ofrecen herramientas de programación que siguen el estándar. Sin embargo, la verdadera reutilización se alcanzaría mediante la interoperabilidad entre herramientas. Este trabajo propone un formato de definición basado en la separación de contenido y visualización del código gráfico. El formato de contenido puede ser utilizado para alcanzar la interoperabilidad entre herramientas mientras que el de visualización permite la generación de documentación. Palabras Clave: IEC , lenguajes gráficos, interoperabilidad, tecnologías XML. 1 INTRODUCCIÓN Los sistemas de control y medida de procesos industriales se utilizan habitualmente para resolver problemas de control y automatización en la mayoría de los sectores industriales, siendo el Controlador Lógico Programable (PLC) el principal de los equipos de control utilizados. Durante muchos años estos equipos únicamente han podido utilizar los lenguajes de programación proporcionados por el fabricante haciéndose necesaria la estandarización también en este campo. En 1993, la Comisión Electrotécnica Internacional (IEC) publicó el estándar internacional para la programación de controladores conocido como IEC [8]. Este estándar especifica tanto al modelo software como los lenguajes de programación para los PLCs [10], [9]. Actualmente la mayor parte de los fabricantes de software para estos dispositivos ofrecen herramientas de programación que siguen el estándar. PLCopen [12] es una organización internacional independiente de fabricante y de producto, está organizada en diferentes comités técnicos entre los que se encuentra el TC6 [15] que tiene entre sus objetivos el especificar formatos XML para poder intercambiar programas, librerías y proyectos de automatización. Por otro lado, no se han encontrado trabajos relacionados con la visualización de los programas de PLC escritos en lenguajes gráficos. En [3], [4] se analiza la necesidad de disponer de un formato estándar para almacenar la información tanto del proyecto de automatización como del código fuente de los lenguajes gráficos. [11] es una patente USA que define un conjunto de schemas XML y Document Type Definitions (DTD) para expresar el código fuente de los lenguajes gráficos tal como se muestra en pantalla. En resumen, hay una serie de trabajos orientados a la definición de un formato para expresar los lenguajes gráficos de programación de PLCs que se basan en la utilización de tecnologías XML, con el propósito de lograr la interoperabilidad entre herramientas de programación. Este trabajo propone una alternativa al formato propuesto por PLCopen, basada en la separación de aspectos: por un lado, el contenido (funcionalidad del POU) se expresa en un formato XML [17] [16], que sigue un schema XML en el que sólo se caracterizan los elementos del lenguaje gráfico tal como los enuncia el estándar. La información gráfica relativa al POU se expresa en otro archivo en un lenguaje gráfico XML, Scalable Vector Graphics (SVG) [13]. El primero de ellos podría ser transferido entre herramientas, logrando la interoperabilidad. El segundo puede ser generado a partir del primero con objeto de visualizar el código gráfico o para generar la documentación como una imagen que puede ser insertada en un documento. En un trabajo previo de los autores [7] se propone la utilización de SVG para visualizar la arquitectura de software de un proyecto de automatización, para ello se asocia a cada elemento del modelo software IEC un icono gráfico. En este artículo se amplía ese trabajo y

2 utiliza las mismas tecnologías XML para expresar el código escrito en lenguajes gráficos. La sección 2 resume las características principales de los lenguajes gráficos del estándar IEC y presenta los aspectos principales del schema XML propuesto por PLCopen TC6. En la sección 3 se presenta la nueva aproximación basada en la separación de la funcionalidad y su visualización. Por último, se presentan algunas conclusiones que remarcan los posibles usos del enfoque propuesto. 2 LOS LENGUAJES GRÁFICOS DEL ESTÁNDAR IEC La parte 3 del IEC especifica la gramática, sintaxis y semántica, de un total de cinco lenguajes de programación de controladores programables. En concreto, dos de ellos son textuales y tres gráficos. En lo referente a los textuales, el lenguaje Instruction List (IL) es un lenguaje textual de bajo nivel, similar al ensamblador y el lenguaje Structured Text (ST), en cambio, es un lenguaje de alto nivel que se utiliza habitualmente en aplicaciones de automatización de procesos complejos. En cuanto a los lenguajes gráficos, el estándar establece tres: Diagrama de Contactos (LD), basado en símbolos gráficos dispuestos en redes (networks), de manera similar a los diagramas lógicos de relés en escalera. Está orientado fundamentalmente a aplicaciones con señales Booleanas. Los Diagramas de Bloques Funcionales (FBD) se utilizan para programar procedimientos complejos mediante objetos gráficos o bloques que representan funciones, bloques funcionales o programas, tal como se hace en los diagramas de circuitos electrónicos. Es ampliamente utilizado en la industria de procesos. Los Diagramas de Funciones Secuenciales (SFC) estructuran las tareas secuenciales de una aplicación de automatización a través de programas y bloques funcionales. Se puede programar tanto en modo textual como gráfico. El estándar establece determinados elementos comunes para los lenguajes gráficos: redes (Networks), identificadas por su etiqueta (Label), que se componen a su vez por líneas (Lines) que representan el flujo de las señales que interconectan los elementos propios del lenguaje. Los bloques (Blocks) definen operaciones dentro de las Funciones y los Bloques Funcionales (FB). Por último, los conectores (Connectors), identificados por su etiqueta, permiten expandir las líneas. En relación con el control de la ejecución, se definen dos nuevos elementos: el salto (Jump), que puede realizarse desde una salida Booleana de Función o FB, permite transferir el control del programa a una red identificada por su la etiqueta. El elemento Return, en caso de que la entrada Booleana asociada sea activa, devuelve el control a la entidad desde la que se ha efectuado la llamada. La Figura 1 ilustra un ejemplo muy sencillo de una función (InRange) escrita en lenguaje FBD. Concretamente, analiza si el contenido de una variable está entre un valor máximo y uno mínimo. Figura 1: Ejemplo sencillo en FBD Este ejemplo se utiliza en los siguientes apartados con objeto de resaltar las diferencias entre las dos aproximaciones. 2.1 PLCOPEN TC6 XML PLCopen es una organización compuesta por más de 100 miembros, entre los que se encuentran fabricantes de PLCs, compañías dedicadas a generar software y otras instituciones independientes. Su objetivo general es promocionar la aplicación del estándar de automatización en la industria. Los formatos de interfaz propuestos por el TC6 [15] se especifican a través de schemas XML [16], que definen tanto las características de los elementos que conforman la estructura del proyecto de automatización como la funcionalidad de los POUs. Además de sus características contienen información gráfica, como por ejemplo, anchura y altura de un bloque, sus coordenadas de posición en la pantalla o el trazado de las líneas de conexión entre bloques.

3 Graphical Parte gráfica dependent part Figura 2: Fichero XML de la Función InRange, según el schema de PLCopen La Figura 2 representa el fichero XML obtenido a partir del POU de la Figura 1, exportado por una herramienta de programación de PLCs con interfaz PLCopen TC6 XML. Como se puede apreciar, este fichero XML contiene además de la funcionalidad, información relativa a la representación gráfica de los diferentes elementos de los lenguajes. Esto es debido a que su objetivo es transferir lo que se ve en la pantalla entre herramientas que soporten este interfaz. Como se puede observar en el schema propuesto por el TC6 la información gráfica se define a veces como atributo de un elemento XML (por ejemplo, un bloque tiene como atributos la anchura y la altura), y otras veces como un nuevo elemento del schema como por ejemplo la posición (position). En ningún caso, estas características corresponden al lenguaje definido en el estándar IEC En resumen, el formato propuesto por PLCopen TC6 permite lograr la interoperabilidad sólo entre aquellas herramientas que sigan dicho interfaz visualizando el código gráfico de la misma forma que en la herramienta original. Además, introduce características gráficas de representación a los elementos no contempladas en el estándar. Asimismo, la definición que hace de la estructura y de los elementos no es restrictiva lo que posibilita la interoperabilidad entre herramientas de diferentes fabricantes, dando cabida a las particularidades de cada una. Ahora bien, no comprueba la corrección del código, se da por supuesto que el código transferido es correcto y se confía en que dicha verificación se efectuará en la herramienta destino. Esto imposibilita la interoperabilidad no sólo con herramientas de programación de PLCs que no soportan el interfaz (aunque siguen el estándar IEC ), sino también con herramientas de otro tipo por ejemplo de configuración o modelado. 3 UNA ALTERNATIVA BASADA EN LA SEPARACIÓN DE ASPECTOS Como se ha comentado anteriormente, la propuesta de este artículo está basada en disponer de una gramática XML schema que defina de manera estricta el léxico y la sintaxis de todos y cada uno de los lenguajes gráficos según el estándar IEC Mediante este schema se especifica la funcionalidad de un programa, función o FB, a través del conjunto de elementos que definen su código y sus relaciones (estilo arquitectónico). A partir de esa información y utilizando tecnologías XML es posible generar la correspondiente imagen que se muestra en la pantalla de la herramienta de programación. En cierto modo, es el mismo proceso que utiliza cualquier herramienta para generar el código gráfico en la pantalla: El estándar especifica los elementos, su sintaxis y la semántica, para cada lenguaje. Cada fabricante de software de PLC aplica un determinado tipo de algoritmo de visualización de los diferentes elementos (Network, Block, Jump, Return, Connector) en la pantalla. Los siguientes sub-apartados separan el contenido, mediante la definición de un nuevo schema para los lenguajes gráficos, de la información gráfica, que se define a través del formato SVG de cada elemento. Finalmente, se presenta el empleo de tecnologías XML para generar ambos ficheros a partir de archivos que siguen el estándar TC6 XML de PLCopen.

4 3.1 FUNCIONALIDAD DE LOS POUs La representación de la funcionalidad de los POUs incorpora información relativa a sus elementos (operadores, bloques estándar, funciones, bloques funcionales, programas, variables, constantes y otros objetos del código gráfico) así como la relación entre ellos que define el orden de ejecución. En primer lugar se caracterizan en XML schema los elementos comunes a todos los lenguajes gráficos. Posteriormente, en la definición de cada de las gramáticas de los lenguajes, se personalizan las características de estos elementos y se añade el léxico del lenguaje IEC a caracterizar. Cada elemento del lenguaje se define como un elemento XML schema, cuyos atributos hacen referencia a características de la funcionalidad y no a su representación en pantalla. La gramática XML queda completamente definida cuando se le define el estilo arquitectónico que debe seguir el lenguaje gráfico representado. La gramática correspondiente al lenguaje FBD se representa en la Figura 3. Tal como se muestra, un POU escrito en el lenguaje FBD está formado por al menos un elemento red (network) que tiene asociado un identificador (id) y opcionalmente un comentario y una etiqueta (label) que será el destino de los saltos jump y connector. Cada network puede contener blocks, jumps, returns y/o connectors. Los bloques se definen como elementos del schema XML caracterizados por un conjunto de atributos: un identificador (id), su tipo de bloque (typename) y para el caso de los bloques funcionales es necesario indicar el nombre de instancia (instancename). Por último, es también necesario indicar el orden de ejecución en la network. Cada bloque puede tener entradas (inputs), salidas (outputs) y entradas-salidas (inout). Estos parámetros se caracterizan en el schema por su orden y si son negados o no. Para expresar la relación del bloque con otros componentes del POU, se asocia a cada entrada/salida el atributo identificador (refid). Concretamente, las relaciones entre bloques se indican en sus entradas, mientras que las relaciones de un bloque con una variable se pueden especificar tanto en las entradas como en las salidas. El elemento return indica el final de una red y los elementos jump y connector la relación entre redes. Figura 3: Schema propuesto para el lenguaje FBD Figura 4: Schema propuesto para el lenguaje LD

5 Asimismo, se ha definido la gramática correspondiente al lenguaje LD tal como se representa en la Figura 4. Un POU programado en lenguaje gráfico LD está constituido por una serie de elementos comunes a los lenguajes gráficos: network, blocks, jumps, returns y connectors antes descritos, con sus correspondientes características recogidas en los atributos. Así, en la propuesta de schema XML que se presenta, un POU en lenguaje LD está formado al menos por una red de contactos o contactnetwork, situada entre dos elementos que representan las líneas de alimentación. El elemento XML correspondiente a la línea izquierda es leftpowerrail y rightpowerrail la derecha, que es, según establece el estándar, de representación opcional, reflejado en el atributo hidden del elemento. Para la composición de la red de contactos se ha definido el elemento segment, conjunto de contacts y blocks, agrupados tanto en serie como en paralelo. Toda red de contactos termina con la conexión de los segmentos bien a la línea derecha de alimentación a través de una bobina (coil), o bien finaliza en un jump, return o connector. Los contactos (contacts), elementos propios del lenguaje LD, están caracterizados por una serie de atributos: un identificador (id), el tipo (type), y la variable de entrada a la que se asocia (refvariable). Se definen a su vez, como elementos hijos, las entradas y las salidas. Entre las primeras se establecen elementos que hacen referencia a otros objetos del lenguaje, como son: refleftpowerrail, refcontact, refblock y refconnector. Las salidas presentan como elementos aquellos con los que se pueden conectar, como son refrightpowerrail, refcoil, refjump, refreturn, refconnector, refblock y refcontact. De igual modo, se definen los elementos bobina (coil), con un conjunto de atributos análogo al de los contactos, y las entradas y salidas como elementos hijo, haciendo referencia a otros elementos gráficos de los que pueden proceder así como elementos destino en el caso de las salidas. 3.2 VISUALIZACIÓN : SVG La tecnología SVG es un estándar de gráficos del World Wide Web Consortium (W3C) [13] basado en XML. Se diseñó con el objeto de convertirse en un formato vectorial estándar, del mismo modo que GIFs y JPEGs se han convertido en los formatos bitmap estándar en la Web. A diferencia de los bitmaps, los gráficos vectoriales SVG no pierden calidad al hacer ampliaciones puesto que se redibujan en la nueva escala a partir de su descripción textual y generalmente ocupan mucho menos tamaño que las imágenes en mapas de bits. Asimismo, dado que los gráficos SVG se definen en XML, son fácilmente integrables en documentos XHTML. Por lo tanto, desde dos puntos de vista diferentes, el empleo de SVG proporciona varias ventajas: SVG como gráficos vectoriales: el tamaño de las imágenes en SVG es considerablemente menor que en otro formato. La calidad de la imagen no disminuye al usar el zoom. Existe, además, un formato comprimido de SVG (ZSVG). La combinación del SVG con un lenguaje de programación como JavaScript permite al usuario manipular directamente la imagen. SVG como tecnología XML: es un código abierto y por tanto se puede editar y manipular desde cualquier editor de texto. Existen herramientas de libre distribución para visualizar gráficos SVG, como son, por ejemplo, Adobe SVG viewer [1], Batik SVG viewer [2] y otros. SVG se puede utilizar conjuntamente con otras tecnologías W3C como son las hojas de estilo XSLT [18] y DOM [6], [14]. Esta última permite al programador modificar el documento asociado SVG mediante un Application Program Interface (API). Un documento SVG se puede crear desde cero o a partir de un documento XML. En este último caso, se precisa de una hoja de estilo xml2svg.xsl. Por último, si se parte de una aplicación Web, el DOM de SVG junto con un lenguaje de programación resulta muy útil de cara a extraer información de un fichero de entrada y enviar los resultados a un fichero SVG. SVG define tres tipos de objetos gráficos: vectoriales, (líneas, elipses, rectángulos, etc.) que pueden ser agrupados, formateados, transformados y compuestos para ser visualizados. También permite enlazar imágenes (.GIF,.JPEG, etc) y añadir texto. En lo que respecta a los lenguajes gráficos de IEC , sólo se necesita un conjunto limitado de elementos SVG, tal como se muestran en la Figura 5, junto con sus expresiones en SVG. SVG como tecnología XML <rect x="170" y="36" ="90" ="84" fill="rgb(209,209,255)" stroke="rgb(0,0,128)" -stroke="1.5"/> <text x="205" y="46" fill="rgb(0,0,128)" font-size="10" font-family="arial">textlabel</text> <polyline fill="none" stroke="rgb(0,0,128)" stroke-="1.5" points="350,54 330, , , ,54"/> <circle id="negated" cx="85" cy="80" r="5" stroke="rgb(0,0,128)" fill="#ffffff"/> SVG como gráfico vectorial Figura 5: Elementos SVG de los lenguajes gráficos

6 Elementos para el lenguaje FBD Bloque FBD entradas salidas instancename typename NombreVariable NombreVariable NombreVariable Elementos para el lenguaje LD Rail Izquierdo segmentname Rail Derecho contacto variablename Bobina variablename Figura 6: Características gráficas de los lenguajes FBD y LD Para cada lenguaje se ha definido un fichero SVG genérico donde se recogen los gráficos asociados a los elementos que puedan aparecer. En la Figura 6 se presentan parte de los iconos gráficos asociados a los elementos de los lenguajes FBD (en la parte superior de la figura) y LD (en la parte inferior). Para visualizar el código gráfico de un POU hace uso de estos elementos que se pueden trasladar y escalar [5]. Por ejemplo para utilizar un determinado elementografico, manteniendo su proporción y trasladándolo a las coordenadas (20, 40) se utilizarán la siguiente sentencias SVG: <use xlink:href="#elementografico" transform="scale(1 1) translate(20 40)"/> En la parte izquierda de la Figura 7 se muestra el uso de gráficos básicos del LD y cómo se trasladan a diferentes posiciones x,y. Por otro lado en la parte derecha ilustra cómo se visualizaría. La información necesaria para generar el SVG del POU gráfico, escrito en FBD o LD, se puede extraer de un archivo XML que siga la gramática de la Figura 3 ó Figura 4, respectivamente. Para ello, se hace uso de la tecnología XML hoja de estilo (XSL) [18]. Con esta tecnología no sólo se extrae la información de las instancias de bloques, las variables de entrada/salida, sino que también se pueden aplicar algoritmos de dimensionamiento y posicionamiento para generar la imagen (como hace cualquier herramienta de programación de PLC). De esta forma utilizando hojas de estilo XSL se puede generar el correspondiente gráfico SVG para cada uno de los POUs gráficos. Como se ha comentado, un archivo que sigue el interfaz XML de PLCopen contiene ambas informaciones: el contenido y la información gráfica de los POUS gráficos. En el siguiente subapartado se muestran las hojas de estilo utilizadas para extraer tanto el contenido o funcionalidad del POU (archivo XML) como la información gráfica (archivo SVG). SVG como tecnología XML SVG como gráfico vectorial: <svg xmlns=" xmlns:xlink=" <defs> <! los gráficos del SVG básico --> </defs> <use xlink:href="#leftpowerright" transform="scale(1 1) translate(0 40)"/> <text x="20" y="40" text-anchor="middle" fill="rgb(0,0,128)" font-size="18"> 001</text> <use xlink:href="#leftpowerright" transform="scale(1 1) translate(0 120)"/> <use xlink:href="#rightpowerright" transform="scale(1 1) translate(940 40)"/> <use xlink:href="#contact" transform="scale(1 1) translate(40 70)"/> <text x="115" y="60" text-anchor="middle" fill="rgb(0,0,128)" font-size="18"> C000</text> <use xlink:href="#contact" transform="scale(1 1) translate(190 70)"/> <text x="265" y="60" text-anchor="middle" fill="rgb(0,0,128)" font-size="18"> C001</text> </svg> Figura 7: Uso y visualización de elementos LD en SVG

7 3.3 SEPARACIÓN DE ASPECTOS DEL INTERFAZ XML DE PLCOPEN La Figura 8 muestra el escenario general a seguir para alcanzar este objetivo a partir de un fichero XML que conforme el schema de PLCopen. PLCOpen.xml 2FBD.xsl XSLT 2SVG.xsl FBD.xml FBD.svg FBD.xsd Figura 8: Escenario general para la separación de aspectos Concretamente en esta figura se presenta el escenario para la separación de aspectos de un POU que se encuentre programado en el lenguaje FBD. Un ejemplo podría ser el representado en la Figura 2. Se utiliza la tecnología de hojas de estilo XSL para filtrar la información del archivo de entrada XML. XSL distingue dos tipos de plantillas: template match que contiene el procesamiento que se va a aplicar a un elemento XML particular del documento de entrada. El segundo tipo de plantilla conocidas como name está más enfocado a modularizar y organizar el procesamiento. <xsl:template match="po:variable" mode="input"> <xsl:element name="input"> <xsl:attribute name="negated"><xsl:value-of select="@negated"/></xsl:attribute> <xsl:attribute name="order"><xsl:value-of select="position()"/></xsl:attribute> <xsl:apply-templates select="po:connection" mode="input"/> </xsl:template> <xsl:template match="po:connection" mode="input"> <xsl:element name="connection"> <xsl:variable name="id"><xsl:value-of select="@reflocalid"/></xsl:variable> <xsl:if test="@formalparameter"> <xsl:element name="refblock"> <xsl:attribute name="refid"> <xsl:value-of select="concat(//po:block[@localid=$id]/@typename,'_',$id)"/> </xsl:attribute> <xsl:attribute name="order"><xsl:value-of select="1"/></xsl:attribute> </xsl:if> <xsl:if test="not(@formalparameter)"> <xsl:element name="refvariable"> <xsl:attribute name="refid"> <xsl:value-of select="//po:invariable[@localid=$id]/po:variable"/> </xsl:attribute> </xsl:if> </xsl:template> Figura 9: Dos plantillas de 2FBD.xsl En concreto, se han desarrollado dos hojas de estilo XML: 2FBD.xsl (ver Figura 9) que extrae la información relacionada con la funcionalidad del código escrito en lenguaje FBD. El archivo generado sigue la gramática XML del FBD del schema de la Figura 3. La transformación se realiza mediante un juego de plantillas (templates) XSL. La figura 9 muestra dos plantillas utilizadas en el tratamiento de los parámetros de entrada del bloque. La segunda, 2SVG.xsl (ver Figura 10) extrae sólo la información gráfica y la salida que genera es un archivo SVG que contiene la imagen asociada. <xsl:template match="po:variable" mode="input"> <xsl:element name="input"> <xsl:attribute name="negated"><xsl:value-of select="@negated"/></xsl:attribute> <xsl:attribute name="order"><xsl:value-of select="position()"/></xsl:attribute> <xsl:apply-templates select="po:connection" mode="input"/> </xsl:template> <xsl:template match="po:connection" mode="input"> <xsl:element name="connection"> <xsl:variable name="id"><xsl:value-of select="@reflocalid"/></xsl:variable> <xsl:if test="@formalparameter"> <xsl:element name="refblock"> <xsl:attribute name="refid"> <xsl:value-of select="concat(//po:block[@localid=$id]/@typename,'_',$id)"/> </xsl:attribute> <xsl:attribute name="order"><xsl:value-of select="1"/></xsl:attribute> </xsl:if> <xsl:if test="not(@formalparameter)"> <xsl:element name="refvariable"> <xsl:attribute name="refid"> <xsl:value-of select="//po:invariable[@localid=$id]/po:variable"/> </xsl:attribute> </xsl:if> </xsl:template> Figura 10: Dos plantillas de 2SVG.xsl La Figura 11 muestra parte del fichero SVG obtenido (fichero textual) para el ejemplo sencillo de la Figura 2 (función InRange). Asimismo se ilustra el resultado de su visualización mediante Adobe SVG viewer [1]. <svg xmlns=" xmlns:xlink=" ="100%" ="100%"> <g> <title>inrange</title> <rect x="170" y="36" ="90" ="84" fill="rgb(209,209,255)" stroke="rgb(0,0,128)" -stroke="1.5"/> <text x="205" y="46" fill="rgb(0,0,128)" font-size="10" font-family="arial">lt</text> <text x="60" y="54" fill="rgb(0,0,128)" font-size="10" font-family="arial">value</text> <polyline fill="none" stroke="rgb(0,0,128)" stroke-="1.5" points="110,54 170,54"/> <text x="40" y="78" fill="rgb(0,0,128)" font-size="10" font-family="arial">maximum</text> <polyline fill="none" stroke="rgb(0,0,128)" stroke-="1.5" points="110,78 170,78"/> </g> </svg> Figura 11: InRange.svg Para el mismo ejemplo, la Figura 12 muestra parte del fichero XML resultante.

8 Figura 12: POU InRange siguiendo el schema FBD.xsd sin la información gráfica En él se definen 3 bloques con su correspondiente atributo identificador (instancename) que hace referencia al tipo de bloque (e.g. LT_11) junto con los atributos typename, línea y orden en la línea (e.g. LT_11 está en la primera posición de la línea 0). Las referencias entre bloques se encuentran en las entradas del bloque AND_12: la primera entrada está relacionada con la primera salida del bloque LT_11 y la segunda entrada con la primera salida del bloque GT_13. Finalmente las relaciones entre bloques sólo se muestran en las entradas de los bloques. 4 CONCLUSIONES Se ha propuesto un nuevo enfoque para la definición y representación de los lenguajes gráficos definidos en el estándar IEC , mediante tecnologías XML. Se ha utilizado un schema XML para definir estrictamente el código gráfico del POU, caracterizando los elementos de lenguaje como elementos XML del schema y el estilo arquitectónico de cada lenguaje. La visualización del POU gráfico se define aplicando la tecnología SVG para representar cada elemento de lenguaje con un icono expresado en SVG, conteniendo tanto información gráfica de los elementos individuales como las conexiones entre ellos y las variables. Esta separación de aspectos permite tanto la interoperabilidad entre herramientas a través del fichero XML así como la visualización de los POUs gráficos (a través del fichero SVG). De este último caso se puede generar una imagen imprimible (.PDF,.GIF,.JPEG), susceptible de ser utilizada para la generación automática de documentación de todo el proyecto de automatización. Agradecimientos Este trabajo ha sido subvencionado por MCYT&FEDER en el proyecto DPI Referencias [1] Adobe SVG viewer, [2] Batik SVG viewer, [3] Bani Younis M. and Frey G., Formalization of existing PLC programs: a survey in Proc. of CESA 2003, Lille (France), Paper No. S2- R , July [4] Bani Younis M. and Frey G., Visualization of PLC programs using XML in Proc. of American Control Conference (ACC 2004), Boston (USA), pp , July [5] David Eisenberg J., SVG Essentials,. Ed. O REILLY. (2002). [6] DOM [7] Estevez E., Marcos M., Iriondo N., Orive D., Graphical Modeling of PLC-based Industrial Control Applications. Aceptado para su publicación en Proc. Of the 2007 American Control Conference. [8] International Electrotechnical Commission. IEC International Standard IEC :2003, Programmable Controllers, Part 3: Programming Languages, [9] John, K-H and Tiegelkamp, M., IEC : Programming Industrial Automation Systems. Springer [10] Lewis, R.W Programming Industrial Control Systems using IEC IEE Control Engineering Series [11] Nicolle P., Tuccinardi C. and Bories, B., Programming station generating a program in single language and automation equipment using such a program, United States Patent, Patent No. US B2, March [12] PLCopen home-page: [13] SVG: [14] SVG DOM [15] TC6 XML de PLCOpen [16] Van der Vlist, E. XML Schema,. Ed. O REILLY.2002 [17] XML, available at: [18] XSLT