perfil uml para especificaciÓn y arquitectura hardware y software para sistemas de .../file/... ·...
TRANSCRIPT
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: [email protected]
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 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 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 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.