MODELADO BASADO EN COMPONENTES DE SISTEMAS DISTRIBUIDOS DE CONTROL INDUSTRIAL E. Estévez I. Torre, U. Gangoiti, M. Marcos, J. Portillo, D. Orive, N. Iriondo, I. Cabanes, I. Sarachaga, F. Artaza Escuela Superior de Ingenieros de Bilbao (Universidad del País Vasco) Alameda Urquijo s/n 48013 Bilbao Teléfono: 34 94 601 4049; Fax: 34 94 601 4187 e-mail: [email protected]

Resumen En el presente artículo se define una metodología para la construcción de sistemas de control distribuido basados en IEC 61131-3, la cual está concebida bajo el enfoque de modelado basado en componentes. El modelado propuesto se realiza en UML (Unified Modelling Language). La metodología define un conjunto de perfiles y las etapas necesarias para conseguir un modelado por partes de los sistemas distribuidos de control industrial que enfatiza la estructuración y reutilización de este tipo de aplicaciones. Como caso de estudio se presenta el modelo del sistema de control para la aplicación industrial de una línea de tratamiento en caliente, que se ha implementado con la herramienta CASE ARTISAN RtS. Palabras Clave: Controladores Lógicos Programables, modelado de sistemas de control distribuido, modelado basado en componentes, UML.

1

INTRODUCCIÓN

La reducción de los precios de los microprocesadores y los rápidos avances tecnológicos han permitido realizar grandes avances en el desarrollo de software comercial (herramientas “Comercial Off The Shelf”, COTS), así como en el equipamiento de control. Las prestaciones y la calidad que ofrecen los modernos controladores lógicos programables (PLCs) o los computadores en tarjeta han mejorado de forma espectacular. También se han producido grandes mejoras en el campo de la instrumentación como, por ejemplo, la oferta de sensores y actuadores inteligentes. Estos avances abren grandes posibilidades para la implantación de sistemas de control distribuido, abiertos, flexibles y de altas prestaciones. La dificultad que sigue existiendo es la falta de herramientas que den soporte a la integración de

estos sistemas. Existen herramientas propietarias de los diferentes fabricantes para diseñar, programar y configurar sus sistemas, pero es difícil reutilizar el trabajo en otros equipos, por lo que muchas labores se realizan ad hoc para cada proyecto concreto. Un paso necesario para hacer la realidad el paradigma de los sistemas distribuidos abiertos es la integración de herramientas COTS para que colaboren en las distintas fases del ciclo de vida del sistema. El tipo de aplicaciones industriales de interés se caracteriza por el gran número de señales de proceso que se controlan y/o monitorizan. Muchas de ellas son señales binarias que se utilizan para conducir la operación secuencial de las diferentes subsistemas que conforman la aplicación. Por ello, el dispositivo de control más comúnmente utilizado es el Controlador Lógico Programable (PLC), equipamiento dedicado que nación para procesar cíclicamente la lógica de control de la aplicación. Sin embargo, hoy en día han evolucionado de forma espectacular aumentando su potencialidad y sus posibilidades de programación. Cuando la aplicación lo requiere las entradas/ salidas se distribuyen utilizando como sistemas de comunicación los llamados buses de campo que transmiten gran cantidad de mensajes a frecuencias relativamente altas pero de pequeña longitud, y PLCs como elementos de control. En la actualidad, este tipo de aplicaciones se caracterizan por la integración de PLCs con otros sistemas y dispositivos, precisando, además, que dichos controladores sean lo suficientemente flexibles como para ser capaces de adaptar rápidamente las estrategias de control a los cambios que requiera el proceso. Como consecuencia, se requieren sistemas abiertos que se puedan integrar tanto en células de producción como en sistemas computacionales de un nivel superior en la pirámide de automatización. Así mismo, la aplicación de estándares también tiene un gran impacto en el rápido crecimiento del mercado de la instrumentación y control de procesos industriales.

En este sentido, la International Electrotechnical Commission (IEC) ha publicado varios estándares promoviendo sistemas abiertos e intercambiables. En particular, el estándar IEC 61131-3 [8], [9] proporciona lenguajes y métodos estandarizados que permiten resolver un amplio rango de problemas tecnológicos como, por ejemplo, los que se derivan del software propietario. En este contexto, también se pueden encontrar organizaciones internacionales como PLCopen [15] asociación mundial independiente de fabricante y de producto cuya misión es ser líder en la resolución de problemáticas así como promocionar el uso de estándares abiertos relacionados con la programación de PLCs. PLCopen tiene diferentes comités técnicos (TCs) que se encargan de los diferentes temas de interés. No obstante, en la medida que la industria alcanza un mayor grado de madurez, es necesaria la consolidación de una metodología de modelado para la construcción de este tipo de sistemas de control. Evidentemente, tal metodología debe beneficiarse de las ventajas que ofrecen los lenguajes de modelado, los cuales permiten describir y simular los sistemas previamente a su construcción. Hoy en día, el lenguaje de modelado industrialmente estandarizado es UML (Unified Modelling Language) [4]. Se trata de un lenguaje de modelado de propósito general, evolucionado a partir de varios métodos orientados a objetos de segunda generación [3], [7], [10], soportado por distintas herramientas CASE, abierto y totalmente extensible. Estos son los principales motivos que han conducido a la elección de este lenguaje de modelado para la especificación, visualización, construcción y documentación de los sistemas de control basados en IEC1131-3. De hecho, ya existen autores que han utilizado UML para modelar componentes IEC del sistema de control [6], [2], [16], [17], [18]. Uno de los inconvenientes de uso de este lenguaje de modelado, viene derivado de su potencialidad. La gran variabilidad de diagramas y elementos que permiten modelar cualquier tipo de aplicación y situación hace que sea lo suficientemente complejo para ser utilizado en entornos industriales. Con la finalidad de acotar los diagramas así como elementos UML, surgen los llamados Perfiles de UML que son muy útiles para añadir las características necesarias y en este caso limitarlas a las particularidades de las aplicaciones a modelar. En el apartado 2 se describen los requisitos cumplen las aplicaciones a modelar. El apartado 3 se presenta una metodología de modelado. En el apartado 4 se propone un modelado formal a través de perfiles UML para las aplicaciones distribuidas de control industrial. Por último, el apartado 5 ilustra la

utilización dichos perfiles UML en el caso de estudio del proyecto FLEXICON como es una Línea de Tratamiento en Caliente.

2

REQUISITOS DE LAS APLICACIONES A MODELAR

Normalmente, una parte importante del sistema de control corresponde a los dispositivos que controlan las componentes mecánicos básicos que forman la planta. Lógicamente, además existirán módulos de comunicaciones entre estos dispositivos y los controladores existentes en la planta. Estas comunicaciones se realizan normalmente mediante buses de campo o redes de planta. Por esta razón la definición del sistema de una forma modular y jerárquica presenta grandes ventajas. Esto permitiría definir el sistema de control global de la planta en base módulos que representan el control de un conjunto de componentes de un nivel inferior. Por otro lado, en todos los campos de aplicación de sistemas de control industrial existen partes de las aplicaciones que presentan poca variación en cuanto a la estructura modular de su funcionalidad. Es por ello por lo que otro de los requisitos es la reutilización de aplicaciones ya desarrolladas o de parte de ellas. Más concretamente, en la mayoría de los casos se podrá reutilizar la especificación de la funcionalidad de forma parcial o total. Por otro lado, y a más bajo nivel, muchas de las funciones básicas que ejecuta un PLC son reutilizables en gran parte de las aplicaciones. En este sentido, la utilización de estándares como el ya mencionado para la programación de PLCs, el estándar IEC 61131-3, proporciona lenguajes y métodos estandarizados que permiten la reutilización de software de forma independiente al PLC en el que finalmente se ejecute la aplicación. En este sentido, es aconsejable la utilización de los componentes que define el modelo software del estándar para describir la implementación del sistema de control. En lo referente a la arquitectura hardware y tal y como ya se ha comentado, la implementación de este tipo de aplicaciones se realiza con equipamiento de control específico. Además, la mayoría de las aplicaciones instaladas utilizan controladores propietarios y por tanto las características y configuración del equipamiento hardware es dependiente del fabricante. De hecho, los fabricantes ofrecen diferentes tipos de producto desde gamas bajas, para controlar aplicaciones simples, a producto de altas gamas que son mucho más potentes y ofrecen mayor funcionalidad. Si la aplicación es distribuida, el sistema de control se extiende con segmentos de red o segmentos de bus de campo. Esto requiere introducir tarjetas de comunicación en PLC que le permitan comunicarse con los sensores, actuadores de la planta o con otros controladores.

Estas características de la arquitectura hardware hacen que las aplicaciones estén constituidas por los mismos elementos pero programación, configuración y operación puede diferir dependiendo del suministrador. Por tanto, se pueden resumir como principales requisitos de las aplicaciones de interés los siguientes: • Especificación modular y jerárquica de la funcionalidad del sistema de control • Especificación de la implementación en términos del modelo software del estándar IEC 61131-3 • Especificación del hardware en función de fabricante y gama de producto.

3

METODOLOGÍA MODELADO

DE

Para la definición del todo el sistema de control distribuido cumpliendo lo requisitos comentados en el apartado anterior, se propone basar el modelado en la metodología MDA [13]. Esta metodología ha sido propuesta por el Object Management Group, y define una aproximación para la especificación de sistemas cuyo principio es la separación de la funcionalidad del sistema de los aspectos dependientes de la plataforma destino. Es decir, separar el cómo implementar la aplicación de su funcionalidad. Por tanto, siguiendo esta metodología, el modelo de una aplicación está formado por tres partes: •

•

diferentes fabricantes, PLCs abiertos, redes industriales así como nodos entrada / salida. •

La última fase consiste en la extensión de la implementación o PSM con objeto de la generación de código para los equipos. En el caso de las aplicaciones de control industrial, y objeto de este trabajo, esta fase concluye con la generación del proyecto de automatización para una herramienta propietaria de programación de PLCs. Por tanto en esta fase también son necesarias una serie de transformaciones para adaptar el código IEC 61131-3 al que realmente siga la herramienta debido a que actualmente prácticamente ninguna herramienta sigue este estándar al cien por cien.

Una vez identificados y caracterizados las diferentes partes a modelar en las aplicaciones de control industrial, el siguiente paso consiste en la definición de una metodología que guíe el modelado del sistema siguiendo además la separación de conceptos propuesta por la metodología MDA. En este sentido, el modelado basado en componentes es lo suficientemente potente para el diseño de sistemas intensivos en software [5]. Los elementos básicos usados para modelar el sistema son los componentes y conectores. Por tanto, el modelo de cada parte de la aplicación se compone de un conjunto de componentes conectados a través de conectores. El modelado por partes (funcionalidad e implementación) se completa teniendo en cuenta que ambas representan el mismo sistema y que por lo tanto están relacionadas tal y como se ilustra en la Figura 1. “qué” tiene que hacer el sistema

Platform Independent Model (PIM): Se corresponde a una especificación funcional independiente de la plataforma, es decir, en esta fase se define qué es lo que tiene que hacer. En particular, en caso de las aplicaciones de control industrial descritas previamente, se corresponde con una especificación jerárquica funcional. Platform Specific Model (PSM): contempla la implementación de la especificación funcional en cuanto a una arquitectura hardware y software se refiere, e.d define cómo implementar la especificación funcional definida en el PIM. En este sentido, una misma especificación funcional puede ser implementada de diferentes maneras. En lo referente a las aplicaciones de control industrial la arquitectura software se hará siguiendo el modelo software propuesto por el estándar IEC 61131-3 (que es independiente de las características de los fabricantes), y la arquitectura hardware incluye los PLCs de

Comp. Comp. Comp. Comp. Comp. Comp.

Comp. Comp.

Comp. Comp. Comp. Comp.

Comp. Comp.

“cómo” se implementa

Comp. Comp. Comp. Comp.

“dónde” se ejecuta

Figura 1: vista de dominio de las aplicaciones Resaltar que el significado semántico de los atributos de los componentes y conectores va a depender de la vista en cuestión, funcionalidad, hardware y software respectivamente. La utilización del modelado basado en componentes permite realizar diseños reutilizando aplicaciones o

parte de ellas diseñadas previamente (componentes). Por otro lado, también garantiza el mantenimiento y mejora a través de reemplazar y personalizar los componentes que la definen. Los siguientes sub-apartados definen la semántica concreta tanto de los componentes y conectores para cada una de las partes (sub-modelos) propuestos para las aplicaciones de control industrial. 3.1

ESPECIFICACIÓN FUNCIONAL

La especificación de la funcionalidad se debe corresponder a una especificación jerárquica de alto nivel del sistema de control. Está modelada a través de componentes funcionales conexiones y conectores.

conector conexión

conector Port Port

Figura 2: Elementos especificación funcional

Componente Componente

en

el

Port Port

componente

de

Con objeto de distinguir las conexiones heredadas (diseño top-down o bottom-up) de aquellas correspondientes a la comunicación entre componentes del mismo nivel, se han considerado necesarios dos tipos de puertos: vertical y horizontal. El primero de ellos se usa para aquellos conectores que contienen conexiones heredadas y el segundo, para aquellos conectores que contienen conexiones que comunican diferentes componentes del mismo nivel jerárquico.

El componente funcional se corresponde a una caja negra que agrupa parte de la funcionalidad de la aplicación de control que está siendo modelada. En particular, puede contener un componente funcional que, a su vez, puede estar formado por componentes de un nivel inmediatamente inferior en la jerarquía. Por tanto, estos componentes están caracterizados por el nivel jerárquico al que pertenecen.

Esta definición permite modelar una especificación jerárquica con suficiente detalle y de la misma manera permite representar gráficamente la especificación funcional independientemente del número de componentes y conexiones presentes en la aplicación.

Las conexiones representan dos tipos de información. Por un lado se utilizan para definir la información procedente o con destino al proceso (sensores y actuadores), Interfaz Hombre Máquina (HMI) y /o pupitre de operador, i.e. señales de campo. Por otro lado, también se pueden usar con objeto de comunicar componentes funcionales del mismo nivel jerárquico.

Componente

La siguiente figura ilustra un ejemplo.

Componente Componente Componente Componente

Componente Componente

vertical

El número de señales de campo involucradas en las aplicaciones de control industrial varía de decenas a cientos. Con objeto de proporcionar una representación más estructurada y compacta, se han definido dos nuevos elementos para modelar la especificación funcional. Estos elementos son los conectores y los puertos. Los conectores permiten agrupar un conjunto de conexiones que vienen o van al mismo componente. Todo conector debe contener al menos una conexión. En este sentido los conectores actúan como canales que agrupan conexiones. Los puertos representan el punto donde los conectores se relacionan con los componentes. Por tanto, un componente al menos tiene un puerto de entrada y otro de salida. De la misma forma, un puerto contiene al menos un conector. La Figura 2 presenta los elementos que caracterizan a un componente funcional.

horizontal

Figura 3: puertos verticales y horizontales de los componentes funcionales 3.2

IMPLEMENTACIÓN DE SISTEMAS DISTRIBUIDOS CONTROL INDUSTRIAL

LOS DE

La parte correspondiente a la implementación se detalla en términos de arquitectura hardware y software. La primera parte debe informar sobre las características de los componentes hardware que son utilizados para implementar el sistema (controladores e.g. PLCs, redes industriales,…). La parte correspondiente a la arquitectura software debe ser modelada siguiendo el modelo software propuesto por el estándar IEC 61131-3. El estándar IEC 61131 permite diseñar aplicaciones de control de forma jerárquica utilizando los elementos básicos de programación conocidos como Program Organisation Units (POUs). Estos elementos se caracterizan porque su uso es independiente de fabricante.

El modelo software está compuesto por los elementos que aparecen en la siguiente figura:

Configuration Configuration Resource Resource Task

Task

Program Program

Config global and direct Var

Resource Resource Task Program FB

FB

FB

FB

Access Path

Figura 4: Modelo software IEC 61131-3 Como se aprecia en la figura anterior está compuesta por los elementos: • • •

•

•

Configuration: Identifica cada uno de los nodos (PLC, Controladores abiertos) del sistema distribuido. Resource: Identifica cada CPU ó máquina virtual de una configuración. Task: Identifica la unidad mínima de planificación dentro de un recurso. Las tareas se asocian con un recurso particular y se considera que se ejecutarán bajo el control de ese recurso. A cada tarea se le asigna una prioridad y un periodo de ejecución. Como se aprecia en la figura, el estándar IEC 61131 permite asignar los programas y bloques funcionales diseñados a diferentes tareas para ajustar los periodos de su ejecución. POU: Elemento principal de reutilización de código ya que se diseña (programa) una vez y puede ser utilizado tantas veces como sea necesario y además en diferentes aplicaciones. Existen tres tipos: Function, Function Block y Program [8]. El más utilizado para asegurar la reutilización del software es el Function Block Variables: que se definen por su visibilidad. Se pueden tener por tanto, variables globales a nivel de configuración y/o recurso y de la misma manera variables locales a programa. En el caso de tener aplicaciones de control distribuidas, también se pueden tener variables de tipo Access que contienen la información intercambiable entre las diferentes configuraciones que componen la aplicación. Estas variables se caracterizan de la misma forma que las variables de los lenguajes de programación del alto nivel, i.e. tipo y valor.

Por tanto, en lo referente al modelado de la arquitectura software los componentes se corresponden a instancias de los POUs y las conexiones son las variables IEC 61131-3. Como se ha comentado previamente, la arquitectura hardware se define por medio de un conjunto de componentes (nodos de procesamiento, controladores y dispositivos entrada / salida) que son conectados por medio de segmentos de red. Por tanto se pueden distinguir dos tipos de componentes: nodos de procesamiento y nodos I/O. Gran parte de las aplicaciones instaladas usan controladores propietarios por lo que las características así como configuración del equipo hardware es dependiente del fabricante y en muchos casos incluso de la grama del producto. Es por eso, que se propone la creación de repositorios organizados por fabricante y gama de producto que deben contener información actualizada correspondiente al componente. Los conectores se corresponden a los segmentos de bus que se caracterizan por el protocolo de aplicación. Finalmente, como ambas arquitecturas modelan el mismo sistema de control es claro que existe una relación entre ambas. En este sentido, se tiene que indicar en qué nodo de procesamiento se descargará el software que es asociado a cada elemento IEC 61131-3 Configuration. De la misma forma, también es necesario establecer la relación entre variables globales con dirección física y el dispositivo I/O de la arquitectura hardware.

4

MODELADO FORMAL DE SISTEMAS DE SISTEMAS DE CONTROL INDUSTRIAL

El trabajo desarrollado tiene como objetivo modelar tanto la especificación (PIM) como la arquitectura (PSM) en un mismo lenguaje. Como ya se ha comentado, el lenguaje remodelado seleccionado ha sido UML utilizando la herramienta ARTiSAN RtS [1]. Esta herramienta se caracteriza porque tiene incorporado un perfil que permite especificar características propias de los sistemas de tiempo real. Para ello incorpora nuevos diagramas UML como son el de arquitectura y concurrencia. Estas características se adaptan a la construcción de sistemas software para sistemas operativos multitarea, pero no son directamente transportables al modelo software que define el estándar IEC 61131-3. Por tanto ha sido necesaria la definición de nuevos perfiles que permitan modelar las características de las aplicaciones de control industrial comentadas. Los Perfiles UML tienen como objeto definir las particularidades de los modelos que se pretenden

implementar. Para ello, UML dispone de elementos específicos como son los stereotypes y tagged values [11] que permiten definir la gramática que se tiene que seguir para especificar un determinado tipo de modelos. En la definición de un perfil se acota el uso de esos estereotipos a determinados elementos UML, como pueden ser por ejemplo: clases, actores etc. La ventaja de la definición de un nuevo perfil es que en él se representan de una forma estándar los datos necesarios para la definición de cualquier modelo que haga uso de ese perfil. Para el modelado de las aplicaciones de control industrial se han definido tres perfiles: uno para la especificación jerárquica funcional, otro para la arquitectura software y un tercero para la arquitectura hardware. Cada uno de ellos se va a detallar en los siguientes sub-apartados. 4.1

PERFIL PARA LA ESPECIFICACIÓN FUNCIONAL

En este apartado se describen los elementos que componen el perfil Specification_Profile que representa en UML la funcionalidad de la aplicación.

etiquetar un elemento Package se tiene que rellenar el nivel jerárquico.

Figura 6: Componente funcional Specification_Profile.Port: Todo componente tiene que tener al menos un puerto de entrada y otro de salida. En UML estos puertos se van a definir añadiendo este estereotipo a los elementos Packages. En la siguiente figura se presentan las características a rellenar por el usuario para definir un puerto en UML.

En la definición de este perfil se han definido tantos estereotipos como elementos necesarios para modelar la especificación funcional de estas aplicaciones. En la siguiente figura se presenta una visión general del perfil desarrollado.

Figura 7: Puertos Como se puede apreciar en la Figura 7 un puerto se va a caracterizar por su dirección (direction) que puede ser Input o Output. Y por otro lado por su tipo (portType), que como se ha comentado anteriormente, los verticales permiten comunicar un componente con sus predecesores (vertical salida o Up) así como con sus sucesores (vertical entrada o Down). Por otro lado, los horizontales (Horizontal) tienen como finalidad comunicar componentes del mismo nivel.

Figura 5: Perfil especificación funcional Como se puede apreciar en la Figura 5, tenemos los siguientes estereotipos: Specification_Profile.Component: Para caracterizar a los elementos UML “Packages” como componente de la especificación jerárquica funcional. Por tanto al

Specification_Profile.Connector: Tiene como finalidad contener un conjunto de conexiones.Únicamente los elementos Packages UML pueden estar caracterizados con este estereotipo. Specification_Profile.Connection: Las conexiones representan bien a señales de campo o bien a enlaces de comunicación entre componentes del mismo nivel jerárquico. Pueden ser caracterizados como conexión las Clases UML. En la siguiente figura se presenta

las características a rellenar por los usuarios al definir una clase como una conexión.

Figura 10: Conexión digital Figura 8: Conexión Como ilustra la Figura 8, una clase conexión está definida por su type que puede tener dos valores: Internal en el caso de que se trate de una conexión para comunicar componentes del mismo nivel, o External cuando se trate de señales de campo. Otra característica es la procedencia o destino de dicha conexión la cual viene dada por el taggedValue fromOrTo. Esta característica es opcional, y sólo tiene sentido cuando se trate de una señal de campo. En este caso tiene tres posibles valores: Process, HMI, Desk. Para concluir con la definición de las conexiones, en el caso de que se dirijan o provengan del/al proceso pueden ser además caracterizadas como analógicas o digitales. Es decir, al mismo elemento UML (en este caso una clase) se le añade un nuevo estereotipo: Specification_Profile.Digital o Specification_Profile.Analogue.

Finalmente, para concluir con el modelado de la especificación funcional, resaltar que únicamente son necesarios el uso de diagrama de clases. Será por medio de estos diagramas como se relacionará cada uno de los componentes definidos. Se verá con más detalle en el caso de estudio. 4.2

PERFIL PARA LA IMPLEMENTACIÓN SOFTWARE

En la siguiente figura se presenta el perfil IEC_Profile desarrollado para modelar la arquitectura software de este tipo de aplicaciones.

En la siguiente figura se presentan las características a rellenar cuando se añade a una conexión la característica de analógica.

Figura 11: Perfil especificación software

Figura 9: Conexión analógica De la misma manera se presentan las características a rellenar cuando se el añade la etiqueta de digital.

Como se puede apreciar en la Figura 11 está formado por dos partes diferenciadas por carpetas. La primera de ellas, IEC_61131-3_CodeGeneration, contiene la los estereotipos necesarios para la generación de la funcionalidad de los POUs programados en el lenguaje Structured Text (ST) [12]. La segunda, contiene los estereotipos asociados a los elementos de la arquitectura software según el modelo SW IEC 61131-3.

Como se puede apreciar, hay un estereotipo por cada elemento. IEC_Profile.Configuration: representa una configuración. Caracteriza a elementos Packages UML. IEC_Profile.Resource: representa un recurso. Los recursos tienen asociadas características temporales. Caracteriza a elementos Packages UML. IEC_Profile.Task Caracteriza a los elementos Task que proporciona el perfil Real Time de la herramienta. En caso de que la herramienta no disponga este perfil se podría asignar a las clases. En la siguiente figura se presenta las características a rellenar.

Figura 12: Tarea IEC 61131-3 Como puede apreciarse las tareas caracterizadas por su periodo y prioridad.

vienen

IEC_Profile.Program IEC_Profile.Functional_Block: representan los tipos de POUs más usados. Esta característica se puede asignar a las clases UML. En la siguiente figura se presentan las características a rellenar para caracterizar una clase etiquetada como programa o bloque funcional.

Figura 13: bloque funcional IEC_Profile.Variable: etiqueta que caracteriza a las clases UML como variables IEC 61131-3. En la siguiente figura se presentan las características a rellenar.

Figura 14: Variables IEC 61131-3 Como se ha comentado en el apartado anterior y se presenta en la Figura 14, estas variables se definen por su visibilidad (InWhichConfiguration, InWhichResource). También por un tipo: Type, en caso de que sea un tipo IEC 61131-3 básico o newType cuando se trate de un tipo definido por el usuario. Resaltar que en ambos caso se puede tener un valor de inicialización (DefaultValue). Para concluir con el modelado de la arquitectura software indicar que para establecer la relación entre los diferentes elementos descritos, se hace uso de diagramas de clases y de un diagrama que proporciona el perfil RT de la herramienta como es el de concurrencia. En el caso de estudio se verá un ejemplo. 4.3

PERFIL PARA LA IMPLEMENTACIÓN HARDWARE

La parte correspondiente a la arquitectura hardware como se ha comentado al principio del documento es la parte más dependiente del fabricante. Aunque el equipamiento de control en este tipo de aplicaciones tiene la misma funcionalidad y elementos, la construcción, configuración y operación es función de fabricante y gama de producto. Es por ello por lo que se propone el modelar la arquitectura hardware basándose en repositorios que deberían suministrar los fabricantes. De esta forma, serían los propios fabricantes los que podrían mantener las características, configuración y operación de sus productos. Todos los fabricantes deberían partir de un perfil genérico y adaptarlo a las características de sus productos. En la siguiente figura se presenta los stereotypes y tagged values definidos para formar dicho perfil base.

Para concluir con los elementos de la arquitectura hardware, quedan las entradas / salidas de las tarjetas IO de los nodos. Para ello se ha definido la etiqueta HW_Profile.IOAddress que va a poder ser asignada a las clases UML. En la siguiente figura se presentan las características a rellenar por el usuario cuando asigna dicha etiqueta.

Figura 17: direcciones físicas señales Figura 15: Perfil arquitectura hardware La arquitectura hardware de este tipo de aplicaciones se basa fundamentalmente en nodos (Node) que se encuentran conectados a segmentos de bus (Bus). En la siguiente figura se presenta las características de los nodos.

Como se puede apreciar en la Figura 17 se tiene que indicar la dirección del nodo que contenga la tarjeta de entrada/salida (SlaveAddress). La posición física de la tarjeta (physicalPosition) así como la dirección relativa de la señal en dicha tarjeta (address). Finalmente, aclarar que para un completo modelado de la arquitectura hardware, es necesario nuevamente el perfil RT de la herramienta de modelado UML. En particular es necesario el diagrama de arquitectura y por consiguiente los elementos que pueden aparecer en él. En el caso de estudio se presenta un ejemplo.

5

CASO DE ESTUDIO: LINEA DE TRATAMIENTO EN CALIENTE

Esta sección ilustra la metodología de modelado propuesta aplicada al control distribuido de una Línea de Tratamiento en Caliente. Figura 16: Nodos de la arquitectura HW Cuando se trate de un nodo con capacidad de procesamiento (type = ProcessingNode) el Subsistema o Package UML etiquetado puede contener tarjetas (Boards del perfil RT) para su definición. En particular, puede tener tarjetas de comunicación (HW_Profile.CommunicationBoard), tarjetas de entrada salida (HW_Profile.IOBoard), procesadores (HW_Profile.Processor), tarjetas de memoria (HW_Profile.MemoryCard)… . Todas ellas estarán caracterizadas en función del fabricante. Los buses de comunicación, están caracterizados por su protocolo de aplicación y su velocidad. Esta etiqueta se podrá asignar a los elementos MultiDrop Bus del perfil RT.

La Figura 18 muestra una típica Línea de Tratamiento en Caliente que se compone de los siguientes subsistemas: un sistema de carga, un horno de austenizado, un tanque de temple, un sistema de lavado y un horno de revenido. Horno de austenizado

Sistema de lavado

Horno de revenido

Sistema de carga

Tanque de temple

Figura 18: Línea de tratamiento en caliente

Se va a aplicar la metodología de modelado propuesta a 2 sistemas representativos de la línea completa: el sistema de carga y el horno de austenizado. La Figura 19 muestra el horno de austenizado con cuatro zonas y dos quemadores por zona. La regulación de temperatura se realiza en cada una de las cuatro zonas, donde la temperatura debería mantenerse sobre los 850ºC. Una cinta transportadora mueve las piezas a lo largo de todo el horno. La velocidad de la cinta depende del tratamiento de calor requerido.

El diseño de la funcionalidad del sistema de control para la línea completa implica cuatro niveles jerárquicos: • •

•

Nivel 0: la planta. Nivel 1: los componentes correspondientes a cada uno de los subsistemas independientes de la planta. Para este caso, el sistema de carga y el horno de austenizado. Nivel 2: cada componente de nivel 1 está formado por un conjunto de componentes de nivel 2. Por ejemplo, el horno de austenizado, componente de nivel 1, incluye 6 componentes de nivel 2: el control del tren de gas, el control de la combustión de quemadores, el control del ventilador de zona, el control del ventilador de combustión, la regulación de temperatura y el control de movimientos.

La siguiente figura ilustra esta funcionalidad modelada en UML: Figura 19: Horno de austenizado

Figura 20: Especificación jerárquica funcional Entre otras posibilidades, supongamos que por exigencias del cliente se quiere distribuir la implementación de esta funcionalidad en dos PLCs diferentes cada uno de los cuales está conectado a un segmento PROFIBUS-DP en el que se encuentran los esclavos que proporcionan las entradas y salidas del sistema de control. La Figura 21 ilustra la

configuración hardware en la que se debe realizar. Concretamente, está compuesta por un PLC abierto (plataforma PC con S.O. QNX) y un PLC propietario (PLC de Siemens).

En este caso, como ya se ha comentado previamente, la herramienta UML utilizada es ARTiSAN RtS. Por ello, los templates de fabricante utilizan el perfil RT que incorpora el diagrama de arquitectura.

ETHERNET NETWORK

QNX

S7300

PROFIBUS DP1

PROFIBUS DP2 Slave_13

DI/DO

Slave_14

AI/AO

DI/DO

Slave_11

AI/AO

DI/DO

AI/AO

Slave_12

DI/DO

AI/AO

Sensors/Actutators

HeatTreatment TreatmentLine Line Heat Figura 21: Arquitectura hardware El modelado de esta arquitectura hardware utilizando los perfiles de fabricante para los distintos componentes se muestra en la siguiente figura:

El siguiente paso del modelado es definir la arquitectura software de cada nodo de procesamiento. Para ello, se han utilizado los dos perfiles definidos para el estándar IEC 61131-3: el de arquitectura y el de generación de código. La Figura 23 ilustra la arquitectura software de una de las configuraciones que contiene dos recursos para el horno de austenizado. Además, uno de ellos contiene los reguladores de temperatura de las zonas, por lo que tendrá asociado un elemento task cuyo periodo será el de los controladores. El diagrama de concurrencia (proporcionado por el perfil RT de la herramienta) permite describir gráficamente la relación entre todos los recursos del sistema distribuido. Es decir, los enlaces de comunicación entre los nodos inteligentes que forman el sistema.

Figura 22: Diagrama de arquitectura UML

Figura 23: Diagrama de concurrencia

6

CONCLUSIONES

En este artículo se ha validado la utilización de lenguajes orientados a objetos y modelado basado en componentes para modelar aplicaciones de control

industrial. Se han descrito los dos perfiles UML desarrollados para modelar la especificación funcional del sistema de control distribuido así como la arquitectura hardware y software. Esta última, incorpora además la posibilidad de modelar el software de la aplicación conforme al estándar IEC 61131-3. Esta metodología de modelado se ha

aplicado a una Línea de Tratamiento en Caliente en el proyecto subvencionado por la UE FLEXICON IST-2001-37269. Este proyecto tiene como objetivo la integración y colaboración de las herramientas Matlab/Simulink, ISaGRAF Enhanced y ARTISAN RtS. De esta forma, el conjunto de herramientas permite modelar el sistema de control tal y como se ha descrito en este artículo y validarlo mediante la co-simulación de las herramientas. Posteriormente, una vez validado el diseño, el entorno permitirá la generación automática de código. Agradecimientos Este trabajo se ha sido subvencionado en parte por la UE en el marco del proyecto FLEXICON IST-200137269 así como por MCYT&FEDER DPI 20032399. Referencias [1] ARTiSAN Real-Time Studio. http://www.artisansw.com/products/professional _overview.asp [2] Bonfé, M., Fantuzzi, C. (2000) “Mechatronic Objects encapsulation in IEC 1131-3 Norm“. Proceedings of the 2000 IEEE International Conference on Control Applicat., pp.598-603. [3] Booch, G., (1994) “Object-oriented analysis and design with applications”. Benjamin/Cummings Publishing Company. [4] Booch, G., Rumbaugh, J., Jacobson, I.. (1999) “El lenguaje Unificado de Modelado”. Addison Wesley. [5] Crnkovic, I., Schmidt, H., Stafford, J., Wallnau, K. (2005) “Automated Component-Based Software Engineering “.Journal of Systems and Software, 1,1. [6] Heverhagen, T., Tracht, R. (2001) “Integrating UML-RealTime and IEC 61131-3 with Function Block Adapters”. Proceedings of the IEEE International Symposium on Object-Oriented Real-Time Distributed Computing. [7] Jacobson, I., Christerson, M., Jonsson, P., Övergaard, G., (1992) “Object - oriented software engineering. A use case driven approach”. Addison-Wesley. [8] John, K-H and Tiegelkamp, M., (2001) “IEC 61131-3: Programming Industrial Automation Systems”. Springer. [9] Lewis, R.W., (1998) “Programming Industrial Control Systems using IEC 1131-3”. IEE Control Engineering Series. [10] Rumbaugh, J., Blaha, M., Premerlan, W., Eddy, F.,Lorensen, W., (1996) “Modelado y dise?o orientados a objetos. Metodología OMT”. Prentice Hall.

[11] Powel Douglas, B. (1998) “Real Time UML developing efficient objetcs for embedded systems”. Addison Wesley. ISBN- 0201 325799. [12] M. Marcos, E. Estévez, U. Gangoiti, I. Sarachaga, J. Barandiarán. “UML Modelling of Industrial Distributed Control Systems“, CONTROLO 2004, Faro, Portugal (2004). [13] Millar J, Mukerji J.,Model Driven Architecture (MDA). OMG, ormsc/2001-07-01, Architecture Board ORMSC1, 2001. [14] OMG (2002). OMG IDL Syntax and Semantics. IDL specification. [15] PLCopen (2003), Overview IEC 61131-3 www.plcopen.org/ [16] Thramboulidis, K. and C. Tranoris (2001). An Architecture for the Development of Function Block Oriented Engineering Support Systems. CIRA 2001. [17] Thramboulidis, K. (2003). An Architecture to Extend the IEC 61499 Model for Distributed Control Applications. 7th Conference on Automation Technology (Automation 2003). [18] Thramboulidis, K. (2004). Developing a CASE tool for distributed control Application. Int J Adv Manuf Technol (2004). 24: 24-31.