PERFIL UML PARA ESPECIFICACIÓN Y ARQUITECTURA

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.
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.
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.
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.
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
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.
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:
Sistema de
carga
Horno de
revenido
Horno de
austenizado
Z1 Z 2 Z 3 Z 4
Z1 Z 2 Z 3 Z 4
Tanque de
temple
Sistema de
lavado
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.
Parámetros de
configuración
datos
internos
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
Seguridades
Enclavamientoss
conexiones
Comandos de Operador
Datos de Operador
Componente
Básico
Funcional
Señalizaciones
Datos de Proceso
conexiones
Datos de Proceso
Datos externos
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.
The termperature of zone z is correct
The combustion motor is connected
Low pressure of air is correct
Low pressure of gas is correct
High pressure of gas is correct
The servomotors are completely opened
Horno de Austenizado
On purge
Gas
Train
Control
Purge done
Open servovalve completely
Active main electrovalve
Alarm burners not start up
Push button alarm acknoledgement
Flame detection burner y zonez
Alarm burners not start up and purge done
Main electrovalve is connected limit switch
Activate bubbling electrovalve
Activate burner y electrovalve
Burnery start button pressed
Burner
Comb .
Control
Burnery ignition transformer
Burnery on
Zonez fan start button pressed
Zonez fan stop button pressed
The automatic switch of the zone z
fan motor is not shoot
Zone fan
Control
Connect the zone z fan
Comb .
Fan
Control
Connect the CombustionFan
Thermal protection of the zone z
fan motor is not shoot
Combustion fan start button pressed
Combustion fan stop button pressed
The automatic switch of the combustion
fan motor is not shoot
Thermal protection of the combustion
fan motor is not shoot
Zone z air servovalve
Temperature regulation zone z input value
RSP zonez temperature
LSP zonez temperature
Zonez output forced
PIDz Loca/Remote
PIDz Manual/Automatic
Zone z alarm temperature high
Temperature
Control
Zone z alarm temperature low
Zone z alarm SP High
Zone z alarm SP Low
Conveyor Local/Remote
Conveyor start button pressed
Conveyor stop button pressed
Conveyor movement detection limit switch
RSP Conveyor
Conveyor motor automatic switch is not shoot
Activate the conveyor
Movements
Control
SP Conveyor
Conveyor Stopped
Fail in the frequency driver of conveyor
The movement system of austenizing
tank is not stopped
LSP Conveyor
z : Número de zonass=>1,2,3 y 4
y: Número de quemadores por zona=> 1 y
Figura 3: Horno de Austenizado (FBC de Nivel1)
2
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:
Resource
Task
Program
Task
Program
Program
FB
Task
Program
FB
FB
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
Máximo nivel de rePrograma instancia
utilización
Permiten
la
descomposición de un
Tipo Bloque Bloque Funcional algoritmo de control
Funcional
instancia
complejo en algoritmos
simples que pueden ser
reutilizados e.g. PID
Tipo
Para manipulación de
Función
Función
datos
Configuration
Task
Program: Es la unidad de ejecución. Su
funcionalidad puede ser definida en cualquiera de los
5 lenguajes que define el estándar.
Tipo
Programa
Resource
Config.
Global
And
Direct
var
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).
FB
..
Access path
Tabla 1: Tipo de POUs
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
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.
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_componentLe
vel. 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.
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
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
DIAGRAMAS DE LA ESPECIFICACIÓN
(PIM)
especifica haciendo uso del tipo channel que
proporciona ARTISAN RtS
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.
El Resource1 del diagrama de concurrencia contiene
los siguientes programas:
5.1
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
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_Correct
the_Temperature_Of_Furnace_Is_Correct, in Low_Pressure_Of_Air_Is_Correct
low_Pressure_Of_Air_Is_Correct, in Low_Pressure_Of_Gas_Is_Correct
low_Pressure_Of_Gas_Is_Correct, in High_Pressure_Of_Gas_Is_Correct
high_Pressure_Of_Gas_Is_Correct, in Alarm_Burners_Not_Started_Up
alarm_Burners_Not_Started_Up, in The_Combustion_Motor_Is_Connected
the_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.
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.
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).
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 ObjectOriented 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.