PERFIL UML PARA ESPECIFICACIÓN Y ARQUITECTURA HARDWARE Y SOFTWARE PARA SISTEMAS DE CONTROL

BASADOS EN IEC1131-3

E. Estévez, U. Gangoiti, M. Marcos, J. Portillo, I. Cabanes, I. Sarachaga, D. Orive, S. Calvo

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: jtpmamum@bi.ehu.es

J. Barandiarán

Director de SPG Automatismos, SPG Asesores, S.A.

Resumen En el presente artículo se define una metodología para la construcción de sistemas de control distribuido basados en IEC1131, la cual está concebida bajo el enfoque de los lenguajes de modelado; concretamente, UML (Unified Modelling Language). Esta metodología se basa en dos perfiles UML con objeto de modelar la especificación funcional, así como la arquitectura hardware y software. 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: PLC, UML, IEC1131, POU, PIM, PSM. 1 INTRODUCCIÓN La mayoría de los sectores industriales emplean PLCs (Programmable Logic Controller) para realizar el control de su sistema productivo. En los últimos años estamos asistiendo a importantes avances tecnológicos en estos controladores que son cada vez más demandados para mejorar la fabricación y optimizar el proceso, al tiempo que se reducen los costes. Las aplicaciones presentes y futuras se caracterizan por la integración de los PLCs con otros sistemas y dispositivos, precisando, además, que dichos controladores sean los suficientemente flexibles 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 aparición del estándar de programación IEC1131-3 [6] proporciona lenguajes y métodos estandarizados que permiten resolver un amplio rango de problemas tecnológicos como elementos software no propietarios. 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) [3]. 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 [2] [7] [5], 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 [4], [1]. En el presente artículo se describe la aplicación de UML para especificar funcionalmente el sistema de control distribuido de una planta industrial. Posteriormente, se define el modelo de arquitectura y se asocian los componentes funcionales a la

arquitectura hardware y software definida. El objetivo final será generar el código IEC1131-3 de la aplicación modelada en UML. Para ello se ha definido una librería de templates asociados a los distintos bloques funcionales utilizados en la aplicación. Como caso de estudio se presenta el modelo del sistema de control para la aplicación industrial Línea de Tratamiento en Caliente (Heat Treatment Line, HTL), que consiste en una línea continua en la que el material a producir recibe el tratamiento térmico adecuado. La exposición del trabajo se organiza en 6 apartados: tras la introducción, en el apartado 2 se presenta la funcionalidad de la aplicación. En el apartado 3 se describen las características principales del estándar IEC1131-3. En el resto de apartados se definen los Perfiles UML desarrollados para modelar la especificación del sistema de control, así como la arquitectura. Por último, se desarrolla el modelo de la aplicación en UML usando la herramienta CASE ARTISAN RtS. La ventaja de utilizar esta herramienta es que ofrece la posibilidad de modelar sistemas con requisitos temporales. En el último apartado se presentan las conclusiones obtenidas. 2 DESCRIPCIÓN FUNCIONAL DE

LÍNEA DE TRATAMIENTO EN CALIENTE

En este apartado se hace una breve descripción de la aplicación industrial que constituye el caso de estudio: HTL, representada en la figura 1:

Horno de austenizado

Z 1 Z 2 Z 3

Horno de revenido

Z 1

Tanque de temple

Sistema de lavado

Sistema de carga

Z 4 Z 2 Z 3 Z 4

Figura 1: Componentes de la aplicación

Este tipo de aplicaciones se definen funcionalmente con una jerarquía de 4 niveles: Nivel 0: constituye la planta completa. Nivel 1: describe los subsistemas independientes

de la planta e.g. horno de austenizado. Nivel 2: describe el conjunto de elementos

funcionales asociados al subsistema del nivel 1 e.g. el horno de austenizado que contiene: control del tren de gas, control de quemadores, control de

ventilador de combustión y de zonas, control de temperatura y control de movimientos. Nivel 3: contiene componentes funcionales

elementales asociados a cada elemento de nivel 2 e.g el control del tren de gas contiene: la purga, electroválvula principal y la válvula de barboteo.

Cada nivel está formado por un conjunto de componentes básicos funcionales (Functional Basic Component, FBC). De esta forma, todos los FBCs, salvo los de nivel 3 contienen a su vez un conjunto de FBCs de nivel inferior. Estos FBCs tienen como objetivo realizar tanto el control de los bucles como las funciones de seguridad de la planta. Concretamente la detección de fallos se realiza por medio de enclavamientos y sensores replicados (también llamados de seguridad). En este sentido, las entradas y salidas asociadas a los FBCs, también conocidas como conexiones, están agrupadas dependiendo de su funcionalidad de la siguiente forma:

Entradas a FBCs: o Seguridades: señales de alarma o Enclavamientos: condiciones que se

deben cumplir para que se pueda ejecutar el bloque.

o Comandos de Operador o Datos de Operador: datos introducidos

por el operador o Datos de proceso: señales de campo o Datos externos: datos procedentes de

otros sistemas independientes. Salidas de FBCs:

o Señalización: lámparas o indicadores de sonoros.

o Datos de proceso: señales de campo. Por lo tanto, como se puede ver en la figura 2, cada FBC se caracteriza por sus entradas, salidas, parámetros de configuración y datos internos. Esta especificación jerárquica facilita la reutilización de FBCs en diferentes aplicaciones.

ComponenteBásico

Funcional

Señalizaciones

Seguridades

Enclavamientoss

Comandos de Operador

Datos de Operador

Datos de ProcesoDatos externos

Datos de Procesoconexiones

Parámetros deconfiguración

datosinternos

conexiones

Figura 2: Caracterización de un FBC

En la figura 3 se presenta la funcionalidad del FBC de nivel 1 que representa al horno de austenizado.

Gas Train

Control

On purge

Purge done

Zonez fan start button pressed

Zonez fan stop button pressed

The automatic switch of the zone zfan motor is not shoot

Thermal protection of the zone zfan motor is not shoot

Zone fan Control

Zone z alarm temperature low

Zone z alarm temperature highTemperature regulation zone z input value

RSP zonez temperature

Zonez output forcedPIDz Loca/Remote

TemperatureControl

BurnerComb . Control

Burnery start button pressed

The combustion motor is connectedLow pressure of air is correctLow pressure of gas is correctHigh pressure of gas is correctThe servomotors are completely openedAlarm burners not start up

MovementsControl

Activate the conveyor

The movement system of austenizingtank is not stopped

Fail in the frequency driver of conveyor

SP Conveyor

Conveyor movement detection limit switchRSP ConveyorConveyor motor automatic switch is not shoot

Conveyor start button pressedConveyor stop button pressed

Push button alarm acknoledgementFlame detection burner y zonezMain electrovalve is connected limit switch

The termperature of zone z is correct

Open servovalve completely

Active main electrovalve

Alarm burners not start up and purge done

Activate bubbling electrovalve

Activate burner y electrovalve

Burnery ignition transformer

Burnery on

Connect the zone z fan

Combustion fan start button pressed

Combustion fan stop button pressed

The automatic switch of the combustionfan motor is not shoot

Thermal protection of the combustionfan motor is not shoot

Comb .Fan

ControlConnect the CombustionFan

Zone z alarm SP Low

Zone z alarm SP High

Conveyor Stopped

Horno de Austenizado

z : Número de zonass=>1,2,3 y 4 y: Número de quemadores por zona=> 1 y 2

PIDz Manual/Automatic

LSP zonez temperature

LSP Conveyor

Conveyor Local/Remote

Zone z air servovalve

Figura 3: Horno de Austenizado (FBC de Nivel1)

3 MODELO SOFTWARE IEC1131 El estándar IEC1131 [6] permite diseñar aplicaciones de control de forma jerárquica utilizando los elementos básicos de programación conocidos como POUs (Program Organisation Units). De esta forma, la especificación funcional jerárquica ya comentada, puede ser directamente utilizada para definir la estructura software asociando FBCs a POUs. Las características principales que ofrece IEC1131 se pueden resumir en las siguientes:

Datos fuertemente tipados. Permite que diferentes partes del programa se

puedan ejecutar con una frecuencia diferente. Soporta el diseño de comportamientos

secuenciales complejos mediante el lenguaje Sequential Function Chart.

Permite la definición de estructuras de datos. Posibilita la programación en diferentes

lenguajes, concretamente ofrece tres lenguajes gráficos y dos textuales para expresar distintas partes del control de la aplicación.

IEC1131-3 proporciona lenguajes estandarizados así como métodos de ejecución de programas, que permiten la programación de diferentes sistemas de control como elementos software independientes de fabricante. 3.1 MODELO SOFTWARE El modelo software está compuesto por los elementos que aparecen en la siguiente figura:

Configuration

Resource

Access path

Task

Program Program

FB

Task

FB

Resource

Task

Program Program

FB

Task

FB

..

Config.GlobalAndDirectvar

FB Function Block

variable

Configuration

Resource

Access path

Task

Program Program

FB

Task

Configuration

Resource

Access path

Task

Program

Task

Program Program

FB

Task

Program

FB

Program

FB

Task

FB

Resource

Task

Program Program

FB

Task

FB

..

Config.GlobalAndDirectvar

FB Function Block

variable

Figura 4: Modelo software IEC1131-3

Configuration: hardware del control de una aplicación concreta e.g. PLC. Cada configuración tiene asociada la arquitectura software que define el orden de ejecución de los programas. Resource: Por cada configuración hay uno o varios recursos. Un recurso proporciona soporte para todas las características requeridas en la ejecución de los

programas. Un programa IEC no puede ejecutarse si previamente no se ha cargado el recurso que lo contiene. También es el responsable de facilitar una interfaz entre un programa y los canales de entrada/salida de un PLC. Un recurso contiene programas (Programs) y tareas (Tasks). Program: Es la unidad de ejecución. Su funcionalidad puede ser definida en cualquiera de los 5 lenguajes que define el estándar. Task: Una tarea puede asociarse a uno o varios programas y/o bloques funcionales que serán ejecutados de forma periódica. Están caracterizadas por su período y prioridad. Functional Block: Su funcionalidad puede ser definida en cualquiera de los 5 lenguajes que define el estándar. 3.2 UNIDADES DE ORGANIZACIÓN DE

PROGRAMAS (POUs) El estándar IEC1131 describe los programas, funciones y bloques funcionales como diferentes tipos de POUs. El concepto de POU proporciona la capacidad de reutilización, ya que una vez definidos pueden ser reutilizados en diferentes partes del control de la aplicación. Esta reutilización es debida a que en cada una de esas partes se usa una instancia diferente del POU definido una sola vez. En la siguiente tabla se presenta los tipos de POUs que se pueden definir según el estándar IEC1131. Tipo POU Implementación comentarios Tipo Programa Programa instancia Máximo nivel de re-

utilización

Tipo Bloque Funcional

Bloque Funcional instancia

Permiten la descomposición de un algoritmo de control complejo en algoritmos simples que pueden ser reutilizados e.g. PID

Tipo Función Función Para manipulación de

datos Tabla 1: Tipo de POUs

Como se ha comentado previamente, esta estructura jerárquica que promueve IEC1131 es muy conveniente para definir la arquitectura concreta del sistema de control asociando FBCs a POUs. Conviene resaltar que para una misma especificación funcional (Platform Independent Model, PIM) es posible obtener diferentes arquitecturas (Platform Specific Model, PSM) asociando la especificación a diferentes POUs. Esta asociación puede variar en los niveles superiores de la jerarquía, pero todas las PSMs tienen en común que los FBCs del nivel más bajo son POUs de tipo functional block.

4 PERFILES UML DESARROLLADOS 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 CASE UML. 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 para la definición del modelo software que define el estándar IEC. 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 estereotipos y tagged values [8] 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 diseño de la HTL se han definido dos perfiles. Uno de ellos para representar la funcionalidad de la aplicación de forma jerárquica según unos requisitos iniciales, y otro para reproducir en UML la arquitectura software de esta aplicación que se encuentra implementada con PLCs. 4.1 PERFIL UML PARA LA

ESPECIFICACIÓN DEL SISTEMA DE CONTROL

En este apartado se describen los elementos que componen el perfil Specification_Profile que representa en UML la especificación del sistema de control para las aplicaciones de control industrial. Como ya se ha comentado, se trata de una especificación jerárquica de 4 niveles en el caso de las aplicaciones de SPG Automatismos. Sin embargo el perfil desarrollado permite ser utilizado en una especificación jerárquica de N niveles. Por tanto este perfil debe representar tanto los componentes básicos

funcionales, comentados en el apartado 2, como las conexiones entre ellos. Para ello se utilizan una serie de estereotipos caracterizados por tagged values. Concretamente, para representar en UML un componente básico funcional se ha generado el estereotipo Specification_Profile.functional_basic_ _component y como se trata de una especificación jerárquica está caracterizado con el tagged value Specification_Profile.functional_basic_componentLevel. Este último podrá tener valores comprendidos entre 0 y 3, indicando así el nivel jerárquico que representa. Este estereotipo puede ser asignado tanto a clases como a paquetes. De hecho, los niveles jerárquicos superiores se representan en UML por medio de un paquete y el nivel más bajo por una clase. En este mismo perfil también se caracterizan las conexiones, para lo cual se ha generado el estereotipo Specification_Profile.connection y para caracterizarlas se le han asociado dos tagged values: Specification_Profile.connectionType: caracteriza

el tipo de conexión. Este tipo contiene como valor el tipo de la conexión: booleana (caso de señales generadas por pulsar un botón..), word (consignas remotas), reales (consignas locales), enteras... Specification_Profile.connectionDirection:

representa el destino de la señal caracterizada. Este tagged value puede tener como valor: input en caso de que la señal venga de proceso o output en caso de que la señal vaya hacia el proceso.

En la figura 5 se presenta el perfil UML diseñado para la especificación del control de la HTL.

Figura 5: UML Specification_Profile

Figura 6: Estructura de los modelos que hagan uso del perfil de especificación

Specification_Profile se puede importar a cualquier modelo UML y todos ellos tendrán la estructura que se presenta en la figura 6. 4.2 PERFIL UML PARA EL MODELO SOFTWARE DEL ESTÁNDAR IEC1131 El perfil IEC_Profile representa los elementos software del modelo comentado en el apartado 3. Concretamente está compuesto por los siguientes estereotipos que representan cada uno de los elementos del modelo software IEC1131-3 de la figura 4:

IEC_Profile.configuration: representa una configuración.

IEC_Profile.Resource: representa un recurso. Los recursos tienen asociadas características temporales. Por ello se han estereotipado los elementos Task que proporciona Artisan en su perfil RT. Estos elementos tienen como atributos lo necesario para caracterizar un recurso.

IEC_Profile.Program: representa un programa.

IEC_Profile.Functional_Block: representa un Bloque Funcional. Este estereotipo tiene asociado un tagged value para indicar el tipo de POU.

La figura 7 representa el perfil UML IEC_Profile así como la relación que existe entre los elementos del modelo software. Este perfil al igual que el de la especificación se puede importar a cualquier modelo UML. Este perfil permite representar la parte de la arquitectura software de un modelo concreto que

define los elementos. Para completarla es necesario describir la funcionalidad de los programas así como su orden de ejecución dentro de un recurso. Para ello, se hace uso de los diagramas de secuencia estándar que proporciona cualquier herramienta UML. La figura 8 ilustra la funcionalidad de un programa de la aplicación HTL identificando los bloques funcionales, y en la figura 9 se puede observar la secuencia de ejecución de los programas que contiene un recurso. 5 MODELO UML PARA LA LÍNEA

DE TRATAMIENTO EN CALIENTE

En este apartado se describe el modelo UML implementado para la aplicación HTL. En primer lugar, se ha desarrollado la funcionalidad de esta aplicación. Para ello, se ha usado el perfil Specification_Profile. Esta implementación constituye el modelo independiente de la plataforma. Posteriormente se hace uso del los diagramas de arquitectura y concurrencia que proporciona ARTISAN RtS complementados con el perfil IEC_Profile para diseñar la arquitectura concreta de la aplicación (PSM). En primer lugar se define la arquitectura software y posteriormente se asocia al diagrama de arquitectura. Finalmente, se asocian los elementos generados en la funcionalidad a los elementos definidos en la arquitectura. En los siguientes sub-apartados se detalla cada uno de los pasos citados así como la relación entre ellos.

Figura 7: Perfil IEC1131-3

Figura 8: Funcionalidad del programa Movements_Control

Figura 9: Orden de ejecución de los programas de Resource1

5.1 DIAGRAMAS DE LA ESPECIFICACIÓN

(PIM) Para representar la funcionalidad de la HTL se hace uso del perfil Specification_Profile. En la figura 10 se ilustra la especificación para el horno de austenizado. En ella se puede observar la especificación jerárquica. 5.2 ARQUITECTURA (PSM) 5.2.1. Arquitectura SW y mapeo de componentes La arquitectura software de la aplicación HTL consta de una configuración que contiene dos recursos. El primero de ellos se ejecuta de forma cíclica, ya que realiza la parte lógica del control de la planta. El segundo de forma periódica, ya que contiene los bucles de regulación de la temperatura del horno de austenizado. Cada uno de estos recursos contiene una serie de programas y bloques funcionales. En la figura 11 se presenta la arquitectura software completa que incluye tanto el control como la monitorización de la aplicación. Para ello, se utiliza el diagrama de concurrencia que consta de tres tareas: dos de ellas representan los recursos y la tercera, la monitorización de la aplicación. El intercambio de información entre los recursos se

especifica haciendo uso del tipo channel que proporciona ARTISAN RtS El Resource1 del diagrama de concurrencia contiene los siguientes programas:

Zone_Fan_Control Program Combution_Fan_Control_Program Gas_Train_Control_Program Burner_Combustion_Control_Program Movements_Control_Program

Y el Resource2, que se ejecuta de forma periódica, los siguientes:

Zone1_Temperature_Regulation_Program Zone2_Temperature_Regulation_Program Zone3_Temperature_Regulation_Program Zone4_Temperature_Regulation_Program

Cada FBC de nivel 2 se ha asociado a un programa. Para describir su funcionalidad de cada uno de ellos, se le asocia un diagrama de secuencia. Por ejemplo, la figura 12 representa el diagrama de secuencia que define la funcionalidad del programa Gast_Train_Control_Program. Con estos diagramas se especifica una serie de llamadas a bloques funcionales.

.

.

Figura 10: Parte de la especificación de la HTL

Figura 11: Diagrama de concurrencia para HTL

Figura 12: Funcionalidad del programa Gas_Train_Control_Program

Cada uno de estos bloques funcionales (asociado a un FBC de nivel 3) dispone de un método de activación en el diagrama de secuencia, el cual tiene unos parámetros de entrada y/o salida que representan las conexiones asociadas al FBC correspondiente. A modo de ejemplo, en la figura 13 se presenta el método del bloque funcional purge.

Por último, es necesario indicar el orden de ejecución de los programas dentro de un recurso. Para ello, se utiliza un diagrama de secuencia. En la figura 9 se aprecia el orden de ejecución de los programas que contiene Resource1.

void Call (in The_Temperature_Of_Furnace_Is_Correctthe_Temperature_Of_Furnace_Is_Correct, in Low_Pressure_Of_Air_Is_Correctlow_Pressure_Of_Air_Is_Correct, in Low_Pressure_Of_Gas_Is_Correctlow_Pressure_Of_Gas_Is_Correct, in High_Pressure_Of_Gas_Is_Correcthigh_Pressure_Of_Gas_Is_Correct, in Alarm_Burners_Not_Started_Upalarm_Burners_Not_Started_Up, in The_Combustion_Motor_Is_Connectedthe_Combustion_Motor_Is_Connected, out On_Purge on_Purge, out Purge_Done purge_Done)

void Call (in The_Temperature_Of_Furnace_Is_Correctthe_Temperature_Of_Furnace_Is_Correct, in Low_Pressure_Of_Air_Is_Correctlow_Pressure_Of_Air_Is_Correct, in Low_Pressure_Of_Gas_Is_Correctlow_Pressure_Of_Gas_Is_Correct, in High_Pressure_Of_Gas_Is_Correcthigh_Pressure_Of_Gas_Is_Correct, in Alarm_Burners_Not_Started_Upalarm_Burners_Not_Started_Up, in The_Combustion_Motor_Is_Connectedthe_Combustion_Motor_Is_Connected, out On_Purge on_Purge, out Purge_Done purge_Done)

Figura 13: Método del bloque funcional Purge

Figura 14: Diagrama de arquitectura de la HTL

Figura 15: Entradas digitales Digital_Input_Board1

5.2.2 Arquitectura HW y mapeo de componentes La distribución del hardware de la aplicación se representa en UML mediante un diagrama de arquitectura. En la figura 14 se presenta la arquitectura hardware diseñada para esta aplicación. El diagrama consta de dos partes bien diferenciadas: la monitorización, que viene representada en la parte superior de la figura, y la parte de control de la aplicación. Ambos subsistema UML se comunican mediante el protocolo TCP/IP. El control de la aplicación se ejecuta en un nodo Profibus-DP que es el maestro del segmento PROFIBUS_DP con dos nodos de entrada y salida. Ambos esclavos contienen las siguientes tarjetas:

PS-307: fuente de alimentación IM-1531: cabecera

El esclavo profibus Slave1 también consta de 5 tarjetas de entradas digitales (tipo SM321) y dos de salidas digitales (tipo SM322). Slave2 también dispone de 2 tarjetas entradas analógicas (tipo SM331) y otras dos de salidas analógicas (tipo SM332).

Las tarjetas SMxxx tienen asociado un diagrama de clases UML, en el que se representa la asociación de las conexiones lógicas a las físicas. En la figura 15 se presenta la asociación del primer byte de la tarjeta Digital_Input_Board1. El diseño de la arquitectura de la aplicación finaliza asociando la arquitectura software a la hardware, tal y como se observa en la figura 16.

Figura 16: Mapeo entre Resource1 y dispositivos hardware

6 CONCLUSIONES En este artículo se ha validado la utilización de lenguajes orientados a objetos 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 IEC1131. 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 por la UE en el marco del proyecto FLEXICON IST-2001-37269. Referencias [1] 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.

[2] Booch, G., (1994) “Object-oriented analysis and

design with applications”. Benjamin/Cummings Publishing Company.

[3] Booch, G., Rumbaugh, J., Jacobson, I.. (1999)

“El lenguaje Unificado de Modelado”. Addison Wesley.

[4] 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.

[5] Jacobson, I., Christerson, M., Jonsson, P.,

Övergaard, G., (1992) “Object - oriented software engineering. A use case driven approach”. Addison-Wesley.

[6] Lewis, R.W., (1997) “Programming Industrial

Control Systems using IEC 1131-3”. IEE Control Engineering series 50. ISBN-0 85296 950 3.

[7] Rumbaugh, J., Blaha, M., Premerlan, W., Eddy, F.,Lorensen, W., (1996) “Modelado y dise?o orientados a objetos. Metodología OMT”. Prentice Hall.

[8] Powel Douglas, B. (1998) “Real Time UML

developing efficient objetcs for embedded systems”. Addison Wesley. ISBN- 0201 325799.