PERFIL UML PARA ESPECIFICACIÓN Y ARQUITECTURA HARDWARE Y SOFTWARE PARA SISTEMAS DE CONTROL BASADOS EN IEC1131-3

Transcripción

1 PERFIL UML PARA ESPECIFICACIÓN Y ARQUITECTURA HARDWARE Y SOFTWARE PARA SISTEMAS DE CONTROL BASADOS EN IEC 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 Bilbao Teléfono: ; Fax: 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 IEC [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 IEC 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

2 arquitectura hardware y software definida. El objetivo final será generar el código IEC 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 IEC 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: Sistema de carga Horno de austenizado Horno de revenido Z 1 Z 2 Z 3 Z 4 Z 1 Z 2 Z 3 Z 4 Tanque de temple Sistema de lavado 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. conexiones Seguridades Enclavamientoss Comandos de Operador Datos de Operador Datos de Proceso Datos externos Parámetros de configuración Componente Básico Funcional datos internos Señalizaciones Datos de Proceso Figura 2: Caracterización de un FBC conexiones En la figura 3 se presenta la funcionalidad del FBC de nivel 1 que representa al horno de austenizado.

3 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 Alarm burners not start up Horno de Austenizado Gas Train Control On purge Purge done Open servovalve completely Active main electrovalve 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 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 Comb. Fan Control Connect the CombustionFan 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 Temperature Control Zone z alarm temperature high 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 Fail in the frequency driver of conveyor The movement system of austenizing tank is not stopped LSP Conveyor Movements Control Activate the conveyor SP Conveyor Conveyor Stopped z : Número de zonass=>1,2,3 y 4 y: Número de quemadores por zona=> 1 y 2 Figura 3: Horno de Austenizado (FBC de Nivel1)

4 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. IEC 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: Task Program Resource Task Program FB FB Configuration Config. Global And Direct var.. Access path Task Program Resource Task Program FB FB Figura 4: Modelo software IEC FB Function Block variable 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 Máximo nivel de reutilización Programa instancia Programa 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 Función Para manipulación de Función 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.

5 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

6 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 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 IEC 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.

7 Figura 7: Perfil IEC Figura 8: Funcionalidad del programa Movements_Control

8 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) 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.

9 .. Figura 10: Parte de la especificación de la HTL Figura 11: Diagrama de concurrencia para HTL

10 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

11 Figura 14: Diagrama de arquitectura de la HTL

12 Figura 15: Entradas digitales Digital_Input_Board 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

13 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 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. [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 Agradecimientos Este trabajo se ha sido subvencionado por la UE en el marco del proyecto FLEXICON IST Referencias [1] Bonfé, M., Fantuzzi, C. (2000) Mechatronic Objects encapsulation in IEC Norm. Proceedings of the 2000 IEEE International Conference on Control Applicat., pp [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 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 IEE Control Engineering series 50. ISBN