MODELADO BASADO EN COMPONENTES DE SISTEMAS DISTRIBUIDOS DE CONTROL INDUSTRIAL

E. Estvez I. Torre, U. Gangoiti, M. Marcos, J. Portillo, D. Orive, I. Cabanes Escuela Superior de Ingenieros de Bilbao (Universidad del Pas Vasco) Alameda Urquijo s/n 48013 Bilbao Telfono: 34 94 601 4049; Fax: 34 94 601 4187 e-mail: elisabet.estevez@ehu.es

Resumen
En el presente artculo se define una metodologa para la construccin 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 metodologa 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 estructuracin y reutilizacin de este tipo de aplicaciones. Como caso de estudio se presenta el modelo del sistema de control para la aplicacin industrial de una lnea de tratamiento en caliente, que se ha implementado con la herramienta CASE ARTISAN RtS. Palabras Clave: Controladores Lgicos Programables, modelado de sistemas de control distribuido, modelado basado en componentes, UML.

estos sistemas. Existen herramientas propietarias de los diferentes fabricantes para disear, programar y configurar sus sistemas, pero es difcil 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 integracin de herramientas COTS para que colaboren en las distintas fases del ciclo de vida del sistema. El tipo de aplicaciones industriales de inters se caracteriza por el gran nmero de seales de proceso que se controlan y/o monitorizan. Muchas de ellas son seales binarias que se utilizan para conducir la operacin secuencial de las diferentes subsistemas que conforman la aplicacin. Por ello, el dispositivo de control ms comnmente utilizado es el Controlador Lgico Programable (PLC), equipamiento dedicado que nacin para procesar cclicamente la lgica de control de la aplicacin. Sin embargo, hoy en da han evolucionado de forma espectacular aumentando su potencialidad y sus posibilidades de programacin. Cuando la aplicacin lo requiere las entradas/ salidas se distribuyen utilizando como sistemas de comunicacin los llamados buses de campo que transmiten gran cantidad de mensajes a frecuencias relativamente altas pero de pequea longitud, y PLCs como elementos de control. En la actualidad, este tipo de aplicaciones se caracterizan por la integracin de PLCs con otros sistemas y dispositivos, precisando, adems, que dichos controladores sean lo suficientemente flexibles como para ser capaces de adaptar rpidamente las estrategias de control a los cambios que requiera el proceso. Como consecuencia, se requieren sistemas abiertos que se puedan integrar tanto en clulas de produccin como en sistemas computacionales de un nivel superior en la pirmide de automatizacin. As mismo, la aplicacin de estndares tambin tiene un gran impacto en el rpido crecimiento del mercado de la instrumentacin y control de procesos industriales.

INTRODUCCIN

La reduccin de los precios de los microprocesadores y los rpidos avances tecnolgicos 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 lgicos programables (PLCs) o los computadores en tarjeta han mejorado de forma espectacular. Tambin se han producido grandes mejoras en el campo de la instrumentacin como, por ejemplo, la oferta de sensores y actuadores inteligentes. Estos avances abren grandes posibilidades para la implantacin 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 integracin de

En este sentido, la International Electrotechnical Commission (IEC) ha publicado varios estndares promoviendo sistemas abiertos e intercambiables. En particular, el estndar IEC 61131-3 [8], [9] proporciona lenguajes y mtodos estandarizados que permiten resolver un amplio rango de problemas tecnolgicos como, por ejemplo, los que se derivan del software propietario. En este contexto, tambin se pueden encontrar organizaciones internacionales como PLCopen [15] asociacin mundial independiente de fabricante y de producto cuya misin es ser lder en la resolucin de problemticas as como promocionar el uso de estndares abiertos relacionados con la programacin de PLCs. PLCopen tiene diferentes comits tcnicos (TCs) que se encargan de los diferentes temas de inters. No obstante, en la medida que la industria alcanza un mayor grado de madurez, es necesaria la consolidacin de una metodologa de modelado para la construccin de este tipo de sistemas de control. Evidentemente, tal metodologa debe beneficiarse de las ventajas que ofrecen los lenguajes de modelado, los cuales permiten describir y simular los sistemas previamente a su construccin. Hoy en da, el lenguaje de modelado industrialmente estandarizado es UML (Unified Modelling Language) [4]. Se trata de un lenguaje de modelado de propsito general, evolucionado a partir de varios mtodos orientados a objetos de segunda generacin [3], [7], [10], soportado por distintas herramientas CASE, abierto y totalmente extensible. Estos son los principales motivos que han conducido a la eleccin de este lenguaje de modelado para la especificacin, visualizacin, construccin y documentacin 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 aplicacin y situacin 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 aadir las caractersticas 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 metodologa de modelado. En el apartado 4 se propone un modelado formal a travs de perfiles UML para las aplicaciones distribuidas de control industrial. Por ltimo, el apartado 5 ilustra la

utilizacin dichos perfiles UML en el caso de estudio del proyecto FLEXICON como es una Lnea de Tratamiento en Caliente.

REQUISITOS DE LAS APLICACIONES A MODELAR

Normalmente, una parte importante del sistema de control corresponde a los dispositivos que controlan las componentes mecnicos bsicos que forman la planta. Lgicamente, adems existirn mdulos 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 razn la definicin del sistema de una forma modular y jerrquica presenta grandes ventajas. Esto permitira definir el sistema de control global de la planta en base mdulos que representan el control de un conjunto de componentes de un nivel inferior. Por otro lado, en todos los campos de aplicacin de sistemas de control industrial existen partes de las aplicaciones que presentan poca variacin en cuanto a la estructura modular de su funcionalidad. Es por ello por lo que otro de los requisitos es la reutilizacin de aplicaciones ya desarrolladas o de parte de ellas. Ms concretamente, en la mayora de los casos se podr reutilizar la especificacin de la funcionalidad de forma parcial o total. Por otro lado, y a ms bajo nivel, muchas de las funciones bsicas que ejecuta un PLC son reutilizables en gran parte de las aplicaciones. En este sentido, la utilizacin de estndares como el ya mencionado para la programacin de PLCs, el estndar IEC 61131-3, proporciona lenguajes y mtodos estandarizados que permiten la reutilizacin de software de forma independiente al PLC en el que finalmente se ejecute la aplicacin. En este sentido, es aconsejable la utilizacin de los componentes que define el modelo software del estndar para describir la implementacin del sistema de control. En lo referente a la arquitectura hardware y tal y como ya se ha comentado, la implementacin de este tipo de aplicaciones se realiza con equipamiento de control especfico. Adems, la mayora de las aplicaciones instaladas utilizan controladores propietarios y por tanto las caractersticas y configuracin 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 ms potentes y ofrecen mayor funcionalidad. Si la aplicacin es distribuida, el sistema de control se extiende con segmentos de red o segmentos de bus de campo. Esto requiere introducir tarjetas de comunicacin en PLC que le permitan comunicarse con los sensores, actuadores de la planta o con otros controladores.

Estas caractersticas de la arquitectura hardware hacen que las aplicaciones estn constituidas por los mismos elementos pero programacin, configuracin y operacin puede diferir dependiendo del suministrador. Por tanto, se pueden resumir como principales requisitos de las aplicaciones de inters los siguientes: Especificacin modular y jerrquica de la funcionalidad del sistema de control Especificacin de la implementacin en trminos del modelo software del estndar IEC 61131-3 Especificacin del hardware en funcin de fabricante y gama de producto.

diferentes fabricantes, PLCs abiertos, redes industriales as como nodos entrada / salida. La ltima fase consiste en la extensin de la implementacin o PSM con objeto de la generacin de cdigo para los equipos. En el caso de las aplicaciones de control industrial, y objeto de este trabajo, esta fase concluye con la generacin del proyecto de automatizacin para una herramienta propietaria de programacin de PLCs. Por tanto en esta fase tambin son necesarias una serie de transformaciones para adaptar el cdigo IEC 61131-3 al que realmente siga la herramienta debido a que actualmente prcticamente ninguna herramienta sigue este estndar al cien por cien.

METODOLOGA MODELADO

DE

Para la definicin del todo el sistema de control distribuido cumpliendo lo requisitos comentados en el apartado anterior, se propone basar el modelado en la metodologa MDA [13]. Esta metodologa ha sido propuesta por el Object Management Group, y define una aproximacin para la especificacin de sistemas cuyo principio es la separacin de la funcionalidad del sistema de los aspectos dependientes de la plataforma destino. Es decir, separar el cmo implementar la aplicacin de su funcionalidad. Por tanto, siguiendo esta metodologa, el modelo de una aplicacin est formado por tres partes: Platform Independent Model (PIM): Se corresponde a una especificacin 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 especificacin jerrquica funcional. Platform Specific Model (PSM): contempla la implementacin de la especificacin funcional en cuanto a una arquitectura hardware y software se refiere, e.d define cmo implementar la especificacin funcional definida en el PIM. En este sentido, una misma especificacin 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 estndar IEC 61131-3 (que es independiente de las caractersticas de los fabricantes), y la arquitectura hardware incluye los PLCs de

Una vez identificados y caracterizados las diferentes partes a modelar en las aplicaciones de control industrial, el siguiente paso consiste en la definicin de una metodologa que gue el modelado del sistema siguiendo adems la separacin de conceptos propuesta por la metodologa MDA. En este sentido, el modelado basado en componentes es lo suficientemente potente para el diseo de sistemas intensivos en software [5]. Los elementos bsicos usados para modelar el sistema son los componentes y conectores. Por tanto, el modelo de cada parte de la aplicacin se compone de un conjunto de componentes conectados a travs de conectores. El modelado por partes (funcionalidad e implementacin) se completa teniendo en cuenta que ambas representan el mismo sistema y que por lo tanto estn relacionadas tal y como se ilustra en la Figura 1.
qu tiene que hacer el sistema
Comp. Comp. Comp. Comp. Comp. Comp.

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

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

cmo se implementa

dnde se ejecuta

Figura 1: vista de dominio de las aplicaciones Resaltar que el significado semntico de los atributos de los componentes y conectores va a depender de la vista en cuestin, funcionalidad, hardware y software respectivamente. La utilizacin del modelado basado en componentes permite realizar diseos reutilizando aplicaciones o

parte de ellas diseadas previamente (componentes). Por otro lado, tambin garantiza el mantenimiento y mejora a travs de reemplazar y personalizar los componentes que la definen. Los siguientes sub-apartados definen la semntica concreta tanto de los componentes y conectores para cada una de las partes (sub-modelos) propuestos para las aplicaciones de control industrial. 3.1 ESPECIFICACIN FUNCIONAL

conector conexin
Port Port

conector

Componente Componente

Port Port

Figura 2: Elementos especificacin funcional

en

el

componente

de

La especificacin de la funcionalidad se debe corresponder a una especificacin jerrquica de alto nivel del sistema de control. Est modelada a travs de componentes funcionales conexiones y conectores. El componente funcional se corresponde a una caja negra que agrupa parte de la funcionalidad de la aplicacin 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 jerarqua. Por tanto, estos componentes estn caracterizados por el nivel jerrquico al que pertenecen. Las conexiones representan dos tipos de informacin. Por un lado se utilizan para definir la informacin procedente o con destino al proceso (sensores y actuadores), Interfaz Hombre Mquina (HMI) y /o pupitre de operador, i.e. seales de campo. Por otro lado, tambin se pueden usar con objeto de comunicar componentes funcionales del mismo nivel jerrquico. El nmero de seales de campo involucradas en las aplicaciones de control industrial vara de decenas a cientos. Con objeto de proporcionar una representacin ms estructurada y compacta, se han definido dos nuevos elementos para modelar la especificacin 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 conexin. En este sentido los conectores actan 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.

Con objeto de distinguir las conexiones heredadas (diseo top-down o bottom-up) de aquellas correspondientes a la comunicacin 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 jerrquico. Esta definicin permite modelar una especificacin jerrquica con suficiente detalle y de la misma manera permite representar grficamente la especificacin funcional independientemente del nmero de componentes y conexiones presentes en la aplicacin. La siguiente figura ilustra un ejemplo.
Componente
Componente Componente Componente Componente

Componente Componente

vertical

horizontal

Figura 3: puertos verticales y horizontales de los componentes funcionales 3.2 IMPLEMENTACIN DE SISTEMAS DISTRIBUIDOS CONTROL INDUSTRIAL LOS DE

La parte correspondiente a la implementacin se detalla en trminos de arquitectura hardware y software. La primera parte debe informar sobre las caractersticas 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 estndar IEC 61131-3. El estndar IEC 61131 permite disear aplicaciones de control de forma jerrquica utilizando los elementos bsicos de programacin 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:

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 caractersticas as como configuracin del equipo hardware es dependiente del fabricante y en muchos casos incluso de la grama del producto. Es por eso, que se propone la creacin de repositorios organizados por fabricante y gama de producto que deben contener informacin actualizada correspondiente al componente. Los conectores se corresponden a los segmentos de bus que se caracterizan por el protocolo de aplicacin. Finalmente, como ambas arquitecturas modelan el mismo sistema de control es claro que existe una relacin 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, tambin es necesario establecer la relacin entre variables globales con direccin fsica y el dispositivo I/O de la arquitectura hardware.

Configuration Configuration
Resource Resource
Task Task Config global and direct Var

Resource Resource
Task
Program FB FB

Program Program 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 mquina virtual de una configuracin. Task: Identifica la unidad mnima de planificacin dentro de un recurso. Las tareas se asocian con un recurso particular y se considera que se ejecutarn bajo el control de ese recurso. A cada tarea se le asigna una prioridad y un periodo de ejecucin. Como se aprecia en la figura, el estndar IEC 61131 permite asignar los programas y bloques funcionales diseados a diferentes tareas para ajustar los periodos de su ejecucin. POU: Elemento principal de reutilizacin de cdigo ya que se disea (programa) una vez y puede ser utilizado tantas veces como sea necesario y adems en diferentes aplicaciones. Existen tres tipos: Function, Function Block y Program [8]. El ms utilizado para asegurar la reutilizacin del software es el Function Block Variables: que se definen por su visibilidad. Se pueden tener por tanto, variables globales a nivel de configuracin y/o recurso y de la misma manera variables locales a programa. En el caso de tener aplicaciones de control distribuidas, tambin se pueden tener variables de tipo Access que contienen la informacin intercambiable entre las diferentes configuraciones que componen la aplicacin. Estas variables se caracterizan de la misma forma que las variables de los lenguajes de programacin del alto nivel, i.e. tipo y valor.

MODELADO FORMAL DE SISTEMAS DE SISTEMAS DE CONTROL INDUSTRIAL

El trabajo desarrollado tiene como objetivo modelar tanto la especificacin (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 caractersticas propias de los sistemas de tiempo real. Para ello incorpora nuevos diagramas UML como son el de arquitectura y concurrencia. Estas caractersticas se adaptan a la construccin de sistemas software para sistemas operativos multitarea, pero no son directamente transportables al modelo software que define el estndar IEC 61131-3. Por tanto ha sido necesaria la definicin de nuevos perfiles que permitan modelar las caractersticas 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 especficos como son los stereotypes y tagged values [11] que permiten definir la gramtica que se tiene que seguir para especificar un determinado tipo de modelos. En la definicin 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 definicin de un nuevo perfil es que en l se representan de una forma estndar los datos necesarios para la definicin 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 especificacin jerrquica 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 ESPECIFICACIN FUNCIONAL

etiquetar un elemento Package se tiene que rellenar el nivel jerrquico.

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 aadiendo este estereotipo a los elementos Packages. En la siguiente figura se presentan las caractersticas a rellenar por el usuario para definir un puerto en UML.

En este apartado se describen los elementos que componen el perfil Specification_Profile que representa en UML la funcionalidad de la aplicacin. En la definicin de este perfil se han definido tantos estereotipos como elementos necesarios para modelar la especificacin funcional de estas aplicaciones. En la siguiente figura se presenta una visin general del perfil desarrollado.

Figura 7: Puertos Como se puede apreciar en la Figura 7 un puerto se va a caracterizar por su direccin (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. 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 seales de campo o bien a enlaces de comunicacin entre componentes del mismo nivel jerrquico. Pueden ser caracterizados como conexin las Clases UML. En la siguiente figura se presenta

Figura 5: Perfil especificacin 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 especificacin jerrquica funcional. Por tanto al

las caractersticas a rellenar por los usuarios al definir una clase como una conexin.

Figura 10: Conexin digital Figura 8: Conexin Como ilustra la Figura 8, una clase conexin est definida por su type que puede tener dos valores: Internal en el caso de que se trate de una conexin para comunicar componentes del mismo nivel, o External cuando se trate de seales de campo. Otra caracterstica es la procedencia o destino de dicha conexin la cual viene dada por el taggedValue fromOrTo. Esta caracterstica es opcional, y slo tiene sentido cuando se trate de una seal de campo. En este caso tiene tres posibles valores: Process, HMI, Desk. Para concluir con la definicin de las conexiones, en el caso de que se dirijan o provengan del/al proceso pueden ser adems caracterizadas como analgicas o digitales. Es decir, al mismo elemento UML (en este caso una clase) se le aade un nuevo estereotipo: Specification_Profile.Digital o Specification_Profile.Analogue. En la siguiente figura se presentan las caractersticas a rellenar cuando se aade a una conexin la caracterstica de analgica. Finalmente, para concluir con el modelado de la especificacin 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 ms detalle en el caso de estudio. 4.2 PERFIL PARA LA IMPLEMENTACIN SOFTWARE

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

Figura 11: Perfil especificacin software 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 generacin 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 segn el modelo SW IEC 61131-3.

Figura 9: Conexin analgica De la misma manera se presentan las caractersticas a rellenar cuando se el aade la etiqueta de digital.

Como se puede apreciar, hay un estereotipo por cada elemento. IEC_Profile.Configuration: representa una configuracin. Caracteriza a elementos Packages UML. IEC_Profile.Resource: representa un recurso. Los recursos tienen asociadas caractersticas 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 podra asignar a las clases. En la siguiente figura se presenta las caractersticas 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). Tambin por un tipo: Type, en caso de que sea un tipo IEC 61131-3 bsico o newType cuando se trate de un tipo definido por el usuario. Resaltar que en ambos caso se puede tener un valor de inicializacin (DefaultValue). Para concluir con el modelado de la arquitectura software indicar que para establecer la relacin 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 IMPLEMENTACIN HARDWARE

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 ms usados. Esta caracterstica se puede asignar a las clases UML. En la siguiente figura se presentan las caractersticas a rellenar para caracterizar una clase etiquetada como programa o bloque funcional.

La parte correspondiente a la arquitectura hardware como se ha comentado al principio del documento es la parte ms dependiente del fabricante. Aunque el equipamiento de control en este tipo de aplicaciones tiene la misma funcionalidad y elementos, la construccin, configuracin y operacin es funcin de fabricante y gama de producto. Es por ello por lo que se propone el modelar la arquitectura hardware basndose en repositorios que deberan suministrar los fabricantes. De esta forma, seran los propios fabricantes los que podran mantener las caractersticas, configuracin y operacin de sus productos. Todos los fabricantes deberan partir de un perfil genrico y adaptarlo a las caractersticas de sus productos. En la siguiente figura se presenta los stereotypes y tagged values definidos para formar dicho perfil base.

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 caractersticas a rellenar.

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 caractersticas a rellenar por el usuario cuando asigna dicha etiqueta.

Figura 17: direcciones fsicas seales 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 caractersticas de los nodos. Como se puede apreciar en la Figura 17 se tiene que indicar la direccin del nodo que contenga la tarjeta de entrada/salida (SlaveAddress). La posicin fsica de la tarjeta (physicalPosition) as como la direccin relativa de la seal 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.

CASO DE ESTUDIO: LINEA DE TRATAMIENTO EN CALIENTE

Esta seccin ilustra la metodologa de modelado propuesta aplicada al control distribuido de una Lnea 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 definicin. En particular, puede tener tarjetas de comunicacin (HW_Profile.CommunicationBoard), tarjetas de entrada salida (HW_Profile.IOBoard), procesadores (HW_Profile.Processor), tarjetas de memoria (HW_Profile.MemoryCard) . Todas ellas estarn caracterizadas en funcin del fabricante. Los buses de comunicacin, estn caracterizados por su protocolo de aplicacin y su velocidad. Esta etiqueta se podr asignar a los elementos MultiDrop Bus del perfil RT. La Figura 18 muestra una tpica Lnea 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: Lnea de tratamiento en caliente

Se va a aplicar la metodologa de modelado propuesta a 2 sistemas representativos de la lnea 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 regulacin de temperatura se realiza en cada una de las cuatro zonas, donde la temperatura debera mantenerse sobre los 850C. 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 diseo de la funcionalidad del sistema de control para la lnea completa implica cuatro niveles jerrquicos: 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 combustin de quemadores, el control del ventilador de zona, el control del ventilador de combustin, la regulacin de temperatura y el control de movimientos.

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

Figura 20: Especificacin jerrquica funcional Entre otras posibilidades, supongamos que por exigencias del cliente se quiere distribuir la implementacin 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 configuracin 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).

ETHERNET NETWORK

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.
S7300
PROFIBUS DP2

QNX
PROFIBUS DP1 Slave_13 Slave_14 Slave_11

Slave_12

DI/DO

AI/AO

DI/DO

AI/AO

DI/DO

AI/AO

DI/DO

AI/AO

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 estndar IEC 61131-3: el de arquitectura y el de generacin de cdigo. La Figura 23 ilustra la arquitectura software de una de las configuraciones que contiene dos recursos para el horno de austenizado. Adems, 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 grficamente la relacin entre todos los recursos del sistema distribuido. Es decir, los enlaces de comunicacin entre los nodos inteligentes que forman el sistema.

Sensors/Actutators

Heat Treatment Line Heat Treatment Line

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:

Figura 22: Diagrama de arquitectura UML

Figura 23: Diagrama de concurrencia industrial. Se han descrito los dos perfiles UML desarrollados para modelar la especificacin funcional del sistema de control distribuido as como la arquitectura hardware y software. Esta ltima, incorpora adems la posibilidad de modelar el software de la aplicacin conforme al estndar IEC 61131-3. Esta metodologa de modelado se ha

CONCLUSIONES

En este artculo se ha validado la utilizacin de lenguajes orientados a objetos y modelado basado en componentes para modelar aplicaciones de control

aplicado a una Lnea de Tratamiento en Caliente en el proyecto subvencionado por la UE FLEXICON IST-2001-37269. Este proyecto tiene como objetivo la integracin y colaboracin 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 artculo y validarlo mediante la co-simulacin de las herramientas. Posteriormente, una vez validado el diseo, el entorno permitir la generacin automtica de cdigo. 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. Metodologa 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. Estvez, U. Gangoiti, I. Sarachaga, J. Barandiarn. 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.