Download módulo de comunicaciones para una aplicación de control

Universidad de Zaragoza. Centro Politécnico Superior
Departamento de Informática e Ingeniería de Sistemas
MÓDULO DE COMUNICACIONES
PARA UNA APLICACIÓN DE
CONTROL DISTRIBUIDO
EN UNA CÉLULA DE MANUFACTURA
PROYECTO FIN DE CARRERA
INGENIERÍA DE TELECOMUNICACIÓN
Autor: Carlos Mediavilla Martí
Director: Ramón Piedrafita Moreno
Ponente: José Luis Villarroel Salcedo
Zaragoza, Julio de 2006
ÍNDICE GENERAL
1. INTRODUCCIÓN ................................................................................................................................................... 1
2. TECNOLOGÍA JAVA ............................................................................................................................................ 3
2.1. TIEMPO REAL EN JAVA ........................................................................................................................................ 3
2.2. COMUNICACIONES REMOTAS CON RMI............................................................................................................... 4
3. LA CÉLULA DE FABRICACIÓN ........................................................................................................................ 6
3.1. DESCRIPCIÓN GENERAL ....................................................................................................................................... 6
3.2. BUS DE CAMPO INTERBUS ................................................................................................................................... 7
3.3. COMUNICADORES ETHERNET .............................................................................................................................. 7
3.4. IDENTIFICADOR DE PRODUCTOS .......................................................................................................................... 8
4. REDES DE PETRI .................................................................................................................................................. 9
4.1. DESCRIPCIÓN BÁSICA .......................................................................................................................................... 9
4.2. IMPLEMENTACIÓN SOFTWARE ........................................................................................................................... 10
4.3. CREACIÓN DE REDES DE PETRI - PNML ............................................................................................................ 11
5. ARQUITECTURA DE CONTROL ..................................................................................................................... 12
5.1. EJECUCIÓN DE UNA RED DE PETRI..................................................................................................................... 12
5.2. CAPA DE COMUNICACIONES .............................................................................................................................. 14
5.3. TÉCNICA DE CONTROL DESCENTRALIZADA ....................................................................................................... 16
5.4. CONTROL DISTRIBUIDO ..................................................................................................................................... 18
5.5. TOMA DE MEDIDAS ............................................................................................................................................ 19
6. APLICACIONES DE CONTROL Y SUPERVISION REMOTO A TRAVES DE INTERNET ................... 22
6.1. ARQUITECTURA CLIENTE-SERVIDOR ................................................................................................................. 22
6.2. CONTROL DE LA PRODUCCIÓN ........................................................................................................................... 23
6.3. INTERFAZ GRÁFICO JAVA Y VISUALIZACIÓN DE REDES DE PETRI ....................................................................... 24
6.4. APLICACIÓN WEB ............................................................................................................................................. 25
7. CONCLUSIONES.................................................................................................................................................. 29
7.1. APLICACIÓN REAL, PROTOTIPO LABORATORIO DEPARTAMENTO IIS.................................................................. 29
7.2. AMPLIACIONES Y MEJORAS ............................................................................................................................... 29
7.3. COMENTARIOS PERSONALES ............................................................................................................................. 30
8. BIBLIOGRAFIA.................................................................................................................................................... 31
ANEXO A. LA CÉLULA DE FABRICACIÓN ...................................................................................................... 33
A.1. TIPOS DE PIEZAS ............................................................................................................................................... 33
A.2. ZONA DE FABRICACIÓN .................................................................................................................................... 36
A.3. IDENTIFICADOR DE PRODUCTOS ....................................................................................................................... 39
ANEXO B. BUS DE CAMPO INTERBUS.............................................................................................................. 42
B.1. CARACTERÍSTICAS BÁSICAS ............................................................................................................................. 42
B.2. TOPOLOGÍA ...................................................................................................................................................... 42
B.3. INTERFAZ DE USUARIO...................................................................................................................................... 44
B.4. RESUMEN DE LAS CAPACIDADES DE INTERBUS ................................................................................................. 45
B.5. LA TARJETA CONTROLADORA DE INTERBUS CIF50-IBM. ................................................................................ 46
B.6. CONFIGURACIÓN DE LA TARJETA MEDIANTE SYCON........................................................................................ 47
B.7. LIBRERÍAS PARA LA COMUNICACIÓN CON INTERBUS. ....................................................................................... 49
ANEXO C. DISPOSITIVOS ETHERNET.............................................................................................................. 52
C.1. COMUNICADORES ETHERNET. MÓDULOS MOMENTUM E/S.............................................................................. 52
C.2. AUTÓMATAS – MÓDULOS ETHERNET ............................................................................................................... 55
C.3. MODBUS TCP-IP.............................................................................................................................................. 56
I
ANEXO D. REDES DE PETRI ................................................................................................................................ 60
D.1. INTRODUCCIÓN ................................................................................................................................................ 60
D.2. PRINCIPIOS FUNDAMENTALES .......................................................................................................................... 60
D.3. DEFINICIONES BÁSICAS .................................................................................................................................... 61
D.4. REDES EDITOR PIPE .......................................................................................................................................... 64
ANEXO E. TECNOLOGÍA JAVA .......................................................................................................................... 69
E.1. ¿QUÉ ES JAVA? ................................................................................................................................................. 69
E.2. ORIENTACIÓN A OBJETOS.................................................................................................................................. 70
E.3. CONCURRENCIA ................................................................................................................................................ 71
E.4. RMI (REMOTE METHOD INVOCATION)............................................................................................................. 72
E.5. MÉTODOS NATIVOS. JNI ................................................................................................................................... 78
ANEXO F. SERVIDOR WEB .................................................................................................................................. 86
F.1. INSTALANDO TOMCAT ...................................................................................................................................... 86
F.2. CONFIGURACIÓN ............................................................................................................................................... 87
F.3. ESTRUCTURA DE DIRECTORIOS ......................................................................................................................... 89
F.4. TRABAJAR CON SERVLETS ................................................................................................................................. 90
F.5. PAGINAS JSP..................................................................................................................................................... 92
ANEXO G. APLICACIONES (MANUAL DE USUARIO) ................................................................................... 93
G.1. CONTROL INDEPENDIENTE DE LA ESTACIÓN 1 .................................................................................................. 98
G.2. CONTROL INDEPENDIENTE DE LA ESTACIÓN 3 .................................................................................................. 99
G.3. CONTROL INDEPENDIENTE DE LA ESTACIÓN 4 ................................................................................................ 101
G.4. CONTROL Y SUPERVISIÓN DE LA CÉLULA DE FABRICACIÓN ............................................................................ 102
G.5. MÓDULOS MOMENTUM ETHERNET ................................................................................................................ 107
G.6. COMUNICACIÓN CON AUTÓMATAS ................................................................................................................. 108
ANEXO H. IMPLEMENTACION JAVA - API ................................................................................................... 112
H.1. APLICACIONES ............................................................................................................................................... 113
H.2. COMUNICACIONES.......................................................................................................................................... 115
H.3. CONTROL ....................................................................................................................................................... 117
H.4. CONTROL.CENTRALIZADO .............................................................................................................................. 118
H.5. CONTROL.DESCENTRALIZADO ........................................................................................................................ 119
H.6. CONTROL.DISTRIBUIDO .................................................................................................................................. 120
H.7. ESTACIONES ................................................................................................................................................... 121
H.8. PRODUCCIÓN .................................................................................................................................................. 122
H.9. PUERTOSERIE ................................................................................................................................................. 123
H.10. REDPETRI ..................................................................................................................................................... 123
ANEXO I. CONTENIDO DEL CD ........................................................................................................................ 125
II
ÍNDICE DE FIGURAS
FIGURA 1.1 LA CÉLULA DE FABRICACIÓN FLEXIBLE ..........................................................................1
FIGURA 2.1 ARQUITECTURA COMUNICACIÓN RMI............................................................................5
FIGURA 2.2 PILA PROTOCOLOS TECNOLOGÍA JAVA RMI ...................................................................5
FIGURA 3.1 DISPOSICIÓN DE LA CÉLULA Y LA RED DE COMUNICACIONES IMPLICADOS EN EL
PROYECTO .................................................................................................................................6
FIGURA 4.1 VISTA PARCIAL DE LA RED DE PETRI PARA EL CONTROL DE LA ESTACIÓN 3 ...................9
FIGURA 4.2 ARCHIVO XML GENERADO POR EL EDITOR DE REDES DE PETRI ...................................11
FIGURA 5.1 ALGORITMO PARA LA EJECUCIÓN DE UNA RED DE PETRI ..............................................13
FIGURA 5.2 ROL DE LA CAPA DE COMUNICACIONES ........................................................................14
FIGURA 5.3 ARQUITECTURA DE CONTROL MEDIANTE COORDINADORES CONCURRENTES ................16
FIGURA 5.4 IDENTIFICADOR IMPLEMENTADO COMO LUGAR DE COMUNICACIÓN..............................17
FIGURA 5.5 COMUNICACIÓN RMI ENTRE LUGARES DISTRIBUIDOS ..................................................19
FIGURA 5.6 TIEMPOS ESTADÍSTICOS ACCESO ETHERNET A: SIN TRÁFICO; B Y C: CON TRÁFICO ........20
FIGURA 6.1 ARQUITECTURA CLIENTE-SERVIDOR DE LAS APLICACIONES .........................................22
FIGURA 6.2 INTERFAZ GRÁFICO JAVA PARA EL CONTROL GLOBAL DE LA CÉLULA ...........................24
FIGURA 6.3 ESQUEMA DEL FUNCIONAMIENTO BÁSICO DE LA APLICACIÓN WEB ..............................26
FIGURA 6.4 PANTALLA DE LA APLICACIÓN WEB PARA EL CONTROL DE LA ESTACIÓN 3 ..................27
FIGURA A.1. DISPOSICIÓN ESPACIAL DE LA CÉLULA DE FABRICACIÓN ............................................33
FIGURA A.2. TIPOS DE PIEZAS .........................................................................................................34
FIGURA A.3. ESQUEMA DE UNA PIEZA .............................................................................................34
FIGURA A.4. COMPONENTES DE LAS PIEZAS ....................................................................................35
FIGURA A.5. UN PALET EN EL TRANSPORTE.....................................................................................36
FIGURA A.6. RECORRIDOS EN EL MÓDULO DE FABRICACIÓN ...........................................................36
FIGURA A.7. ESTACIÓN 1 ................................................................................................................37
FIGURA A.8. ESTACIÓN 2 ................................................................................................................37
FIGURA A.9. ESTACIÓN 3 ................................................................................................................38
FIGURA A.10. ESTACIÓN 4 ..............................................................................................................38
FIGURA A.11. IDENTIFICADOR DE PRODUCTOS ................................................................................39
FIGURA A.12. CABEZAL DE LECTURA/ESCRITURA ...........................................................................39
FIGURA A.13. PROTOCOLO PUERTO SERIE: CÁLCULO DEL CHECKSUM .............................................41
FIGURA B.1. TOPOLOGÍA DE RED DEL BUS INTERBUS ......................................................................43
FIGURA B.2. MÓDULO DE ENTRADAS-SALIDAS INTERBUS ...............................................................44
FIGURA B.3. ESQUEMA DE LA TARJETA INTERBUS...........................................................................46
FIGURA B.4. TARJETA INTERBUS CIF-50 HILSCHER .......................................................................47
FIGURA B.5. CONFIGURACIÓN DE LA TARJETA CON EL SOFTWARE SYCON ......................................48
FIGURA C.1. MÓDULO DE ENTRADAS-SALIDAS TSX MOMENTUM ..................................................52
FIGURA C.2. TSX MOMENTUM CON ADAPTADOR DE COMUNICACIÓN ETHERNET TCP-IP..............54
FIGURA C.3. AUTÓMATA DE LA CÉLULA CON MÓDULO ETHERNET..................................................55
FIGURA C.4. PILA PROTOCOLO MODBUS TCP-IP............................................................................56
FIGURA C.5. TRANSACCIÓN EN PROTOCOLO MODBUS ....................................................................57
FIGURA C.6. ESTRUCTURA BÁSICA DE TRAMAS EN PROTOCOLO MODBUS ......................................57
FIGURA D.1. REPRESENTACIÓN GRÁFICA DE LUGARES, ARCOS Y TRANSICIONES .............................61
FIGURA D.2. RED DE PETRI EJEMPLO...............................................................................................62
FIGURA D.3. RED DE PETRI CONFORME ..........................................................................................63
FIGURA D.4. RED DE PETRI NO BINARIA ..........................................................................................64
FIGURA D.5. RED DE PETRI NO VIVA ...............................................................................................64
FIGURA D.6. VISTA PARCIAL DE LA RDP DE LA ESTACIÓN 3 EN EL EDITOR PIPE ..............................66
III
FIGURA D.7. VISTA PARCIAL DE LA RDP REDBORRARDESCENTRALIZADA.XML ............................ 67
FIGURA D.8. VISTA PARCIAL DE LA RDP REDEST1.XML ................................................................. 68
FIGURA E.1. MODELO DE CAPAS DEL MIDDLEWARE RMI ............................................................... 72
FIGURA E.2. JAVA, C Y JNI............................................................................................................. 78
FIGURA E.3. PASOS PARA TRABAJAR CON JNI ................................................................................ 79
FIGURA E.4. NOMENCLATURA DE MÉTODOS JNI 1.......................................................................... 80
FIGURA E.5. NOMENCLATURA DE MÉTODOS JNI 2.......................................................................... 81
FIGURA E.6. DEFINICIONES DE LAS VARIABLES DE SALIDA DEL PROGRAMA ................................... 82
FIGURA E.7. DEFINICIONES DE LAS VARIABLES DE ENTRADA DEL PROGRAMA ................................ 83
FIGURA G.1. INICIALIZACIÓN DE LA TARJETA INTERBUS................................................................. 94
FIGURA G.2. COMPROBACIÓN FUNCIONAMIENTO DE LA TARJETA INTERBUS .................................. 94
FIGURA G.3. COMUNICACIÓN VÍA SERIE CON EL IDENTIFICADOR DE PRODUCTOS ........................... 95
FIGURA G.4. INTERFAZ GRÁFICO PARA EL CONTROL DE LA ESTACIÓN 1.......................................... 98
FIGURA G.5. VENTANA DIRECCIÓN IP DEL SERVIDOR ..................................................................... 99
FIGURA G.6. INTERFAZ GRÁFICO PARA EL CONTROL DE LA ESTACIÓN 3.......................................... 99
FIGURA G.7. VISUALIZACIÓN DE LA RED DE PETRI DE LA ESTACIÓN 3 .......................................... 100
FIGURA G.8. VISUALIZACIÓN DE LA RED DE PETRI DE LA ESTACIÓN 4 .......................................... 101
FIGURA G.9. CONTROL ACCESO APLICACIÓN WEB ....................................................................... 102
FIGURA G.10. CONTROL MANUAL DESDE PÁGINA WEB ................................................................ 103
FIGURA G.11. VISUALIZACIÓN DEL ESTADO DE ENTRADAS Y SALIDAS ......................................... 104
FIGURA G.12. PANTALLA WEB PARA EL CONTROL AUTOMÁTICO DE LA CÉLULA .......................... 105
FIGURA G.13. PANTALLA WEB PARA EL CONTROL DE LA PRODUCCIÓN ........................................ 106
FIGURA G.14. ESTADOS DE UN PEDIDO ......................................................................................... 107
FIGURA G.15. PANTALLA DE LA APLICACIÓN MOMENTUM ETHERNET ........................................... 107
FIGURA G.16. PANTALLA APLICACIÓN AUTÓMATAS .................................................................... 109
FIGURA G.17. DETALLE DE BITS DE UNA VARIABLE ...................................................................... 111
FIGURA G.18. VISUALIZACIÓN DE LA TABLA DE SÍMBOLOS .......................................................... 111
FIGURA H.1. ENTORNO DE DESARROLLO ECLIPSE......................................................................... 112
FIGURA H.2. DIAGRAMA DE LA CLASE ETHERNET ......................................................................... 117
FIGURA H.3. DIAGRAMA DE LA CLASE COORDINADOREST3 .......................................................... 119
FIGURA H.4. CLASES RELACIONADAS CON LA CLASE ESTACION.................................................... 122
FIGURA H.5. CLASES RELACIONADAS CON LA CLASE PRODUCCION .............................................. 122
FIGURA H.6. CLASES RELACIONADAS CON LA CLASE PUERTOSERIE ............................................. 123
FIGURA H.7. CLASES RELACIONADAS CON LA CLASE RED ............................................................ 124
IV
Introducción
1. INTRODUCCIÓN
El Departamento de Informática e Ingeniería de Sistemas de la Universidad de Zaragoza posee una
célula de fabricación flexible que es una plataforma de experimentación para nuevas técnicas de control.
Esta instalación, situada en el laboratorio 0.06 del edificio Ada Byron, constituye un sistema distribuido
heterogéneo compuesto por autómatas programables, controladores específicos y computadores ejerciendo
labores de control y supervisión.
Figura 1.1 La célula de fabricación flexible
El objetivo final de este proyecto es la realización de una aplicación de control y supervisión en tiempo
real basada en Redes de Petri (RdP) y la plataforma de programación Java. Las RdP son el formalismo
elegido para modelar el control mientras que Java es el lenguaje de implementación. Se habrá observado
que el objetivo del proyecto se ha ampliado respecto a la propuesta original, no solo se desarrollará el
módulo de comunicaciones sino que se realizará una aplicación completa.
El presente proyecto se enmarca en una línea de investigación sobre implementación de algoritmos de
control sobre Java para sistemas de eventos discretos con RdP realizados en la Universidad de Zaragoza
[1], [2], [3] y [4]. En los más recientes se abordaba la implementación centralizada de RdP en Java sin
requerimientos de tiempo real. Se pretende avanzar en las técnicas de control en tiempo real con RdP de
sistemas complejos e implementar diferentes formas de gestionar la ejecución de las RdP, desarrollando
implementaciones descentralizadas y distribuidas (varias CPUs en diferentes PCs), así como realizar
también una evaluación del lenguaje Java como plataforma de implementación para estas técnicas.
En contraposición al típico control automatizado basado en autómatas programables [5], en este
proyecto la plataforma hardware para el sistema de control estará basada en uno o varios computadores
con varias tarjetas de comunicaciones que permitan el acceso a los módulos de entrada/salida de las
máquinas que componen la célula. La parte software del sistema de control estará basada en un programa
Java en tiempo real con varias tareas encargadas de la ejecución de varias RdP concurrentemente. El
software de control se ejecutará en un sistema operativo Linux sobre la plataforma Jamaica para cumplir
los requisitos de tiempo real. La máquina virtual Jamaica es una implementación de la especificación de
tiempo real RTSJ (Real Time Specification Java) para Java.
Carlos Mediavilla Martí
1
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Para la puesta en práctica de las arquitecturas de control realizadas, será necesario el desarrollo del
middleware que permita la comunicación entre los computadores responsables del control y los diferentes
dispositivos de la célula (autómatas, módulos I/O y el identificador de productos). El middleware deberá
soportar comunicaciones sobre Ethernet, sobre el bus de campo Interbus y sobre líneas de comunicación
serie para el conjunto de nodos del sistema. Se realizará una toma de medidas para establecer las latencias
de las comunicaciones y poder hacer un análisis temporal de las diferentes aplicaciones de control.
Finalmente se realizará una plataforma de experimentación y desarrollo consistente en la
automatización de un proceso de fabricación con varias aplicaciones de control y supervisión que
involucren a la célula. En ella se pondrán en práctica las diversas investigaciones realizadas en el
proyecto. Las aplicaciones tendrán una arquitectura cliente-servidor, la ejecución del control se realizará
en uno o varios ordenadores servidores, mientras que los clientes (remotos) serán los responsables de
generar la interfaz gráfica de usuario. Uno de los programas cliente será una aplicación Web que
permitirá la supervisión y control remoto de la célula a través de un navegador Web.
Este documento esta estructurado de la siguiente manera:
o
En el capítulo 2, las características más relevantes de la plataforma Java para su uso en sistemas
de control en tiempo real son analizadas, así como una breve descripción de las tecnologías Java
más importantes que se utilizarán en este proyecto.
o
La célula de fabricación flexible y su red de comunicaciones se describen en el capítulo 3.
o
En el siguiente capítulo, el cuarto, se explican conceptos básicos de las redes de Petri y se revisan
las posibles técnicas de control.
o
En el capítulo 5 se presenta la estructura de la arquitectura de control propuesta, incidiendo en las
comunicaciones con el sistema controlado y entre los diversos componentes del control
distribuido.
o
El diseño de las aplicaciones de control y supervisión remotos, que ponen en práctica lo
desarrollado en capítulos anteriores, es descrito en el capítulo 6, aunque los detalles de la
implementación del software desarrollado (el código Java de las aplicaciones) han sido
trasladados al Anexo H.
o
Finalmente, en el capítulo 7 se presentan algunas de las valoraciones obtenidas más relevantes y
se listan una serie de posibles ampliaciones para futuros proyectos.
Carlos Mediavilla Martí
2
20/07/06
Tecnología Java
2. TECNOLOGÍA JAVA
La implementación software que modele el comportamiento de la célula y permita su control mediante
el uso de Redes de Petri se realizará en la plataforma Java. Java es un lenguaje de programación
orientado a objetos, en contraposición a la tradicional programación estructurada. Un objeto, también
llamado clase, agrupa tanto los datos como las funciones (llamadas métodos) para tratar con esos datos.
Típicamente el código que se escribe en una clase encapsula una funcionalidad específica, de esta manera
se puede desarrollar un programa de forma ordenada y modular. Java, aparte de ser un buen lenguaje de
programación [6], se ha elegido para llevar a cabo este proyecto por varias razones:
•
•
•
•
•
•
•
Capacidades de red robustas y fáciles de usar.
Esta pensado para construir sistemas distribuidos.
Concurrencia integrada en el lenguaje.
Bibliotecas de clases (APIs) muy útiles, desarrollo rápido.
La posibilidad de ejecutar el mismo código en diferentes plataformas.
Efectuar una comparación con implementaciones previas realizadas en Ada.
Se quiere investigar un lenguaje que está en las primeras etapas de su aplicación al desarrollo de
sistemas de control en tiempo real y sistemas empotrados.
2.1. Tiempo real en Java
Un sistema de tiempo real es un sistema informático en el que el tiempo en que se producen sus
acciones es significativo. Las acciones del sistema deben ser correctas desde el punto de vista lógico o
algorítmico, y además deben producirse dentro de un intervalo de tiempo determinado [7]. Java posee
algunas de las características necesarias para implementar aplicaciones de control, entre ellas la ejecución
concurrente de threads. Pero de todas maneras, la definición original de Java puede no ser suficiente para
tiempo real por los siguientes motivos:
•
•
•
•
•
•
•
•
Es un lenguaje interpretado, esto implica que es más lento que lenguajes compilados.
La planificación de actividades concurrentes esta mal definida.
Los mecanismos de sincronización son inadecuados.
La gestión dinámica de memoria introduce indeterminismo.
La medida del tiempo no es suficientemente precisa.
Los programas en Java enlazan las clases dinámicamente, existiendo así la posibilidad de que la
máquina virtual tenga que descargar clases remotas retardando la ejecución de los programas.
Se dedica un thread de prioridad máxima a realizar la tarea de recolección de basura.
El planificador de Java usa prioridades fijas pero no garantiza que el thread con mayor prioridad
este ejecutándose. El planificador de procesos puede elegir un thread de menor prioridad para
evitar el monopolio. La prioridad de los threads solo afectan a la política de planificación en tema
de eficiencia.
La primera característica solo afecta al rendimiento en tiempo de ejecución, pero las demás
características suponen un grado de impredecibilidad temporal en la ejecución de un programa multiflujo.
Existen varias propuestas de modificaciones para usar Java en sistemas de tiempo real. La especificación
RTSJ [8] es una de ellas. RTSJ (Real Time Specification for Java) es un grupo de interfaces que permiten
la programación en tiempo real en el lenguaje de programación Java. RTSJ fue desarrollado como
resultado del proceso de la comunidad de Java, que aprobó el nuevo estándar en noviembre de 2001.
Carlos Mediavilla Martí
3
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
El desarrollo de una aplicación en tiempo real requiere de una máquina virtual Java especial que
implemente dicha especificación. TimeSys es la implementación de referencia pero su licencia no es nada
económica y además se basa en la versión 1.2 de Java; Existe otra implementación llamada jRate, el
problema es que es una plataforma muy limitada (no permite el uso de JNI y es necesario compilar la
aplicación a código máquina para poder ejecutarla) y tiene un entorno de desarrollo complejo. Así que se
tuvo que buscar una solución alternativa. Para el presente proyecto se ha elegido Jamaica por estar más
desarrollada y tener mayor funcionalidad que las anteriores.
La máquina virtual JamaicaVM [9] es una implementación de la especificación de la máquina virtual
Java. Es un sistema de ejecución para aplicaciones escritas en el entorno de desarrollo J2SE. Esta
orientada a sistemas de tiempo real y al desarrollo de software para sistemas empotrados. Jamaica no
soporta Windows como sistema operativo, así que se tuvo que desarrollar el proyecto en un sistema Linux
[10]. Esta plataforma ofrece:
•
•
•
•
Planificador expulsivo basado en prioridades estáticas.
Bibliotecas para desarrollo de aplicaciones cuyo tiempo de ejecución está acotado.
o “RealtimeThread”, periódicos, aperiódicos y esporádicos.
o Clases para el tratamiento de eventos asíncronos y la transferencia asíncrona del control.
o Relojes de tiempo real de alta resolución.
o “NoHeapRealtimeThread”, se pueden ejecutar siempre antes que el recolector de basura.
La posibilidad de compilar a código máquina, aumentando la velocidad de ejecución.
Soporta la carga de librerías dinámicas (JNI) necesarias para el control del bus Interbus.
JamaicaVM no resuelve el hecho de que Java sea interpretado, pero dispone de una herramienta que
permite compilar el código a la plataforma deseada, aunque sea a costa de perder la portabilidad. Todas
estas características proporcionan a Java la predecibilidad temporal necesaria para la ejecución de
aplicaciones de control en tiempo real.
2.2. Comunicaciones remotas con RMI
Existen numerosos middleware que permiten comunicar aplicaciones distribuidas escondiendo los
detalles de heterogeneidad de las mismas. Ejemplos de middleware son RMI de Java, CORBA, etc.; pero
finalmente se ha elegido RMI porque aporta ventajas con respecto a los métodos más tradicionales para el
procesamiento distribuido, de modo que se pueden aprovechar las grandes posibilidades de la
programación orientada a objetos como el polimorfismo y la ligadura dinámica. La invocación de métodos
en objetos remotos es transparente a los programadores e independiente de los objetos. Además, las
interfaces empleadas en RMI facilitan la modularidad, extensibilidad y reusabilidad de los desarrollos.
Así pues, el API Java RMI [11] (Remote Method Invocation) se convierte en una de las herramientas
más importantes en este proyecto. La comunicación entre los diferentes componentes del control
distribuido y la arquitectura cliente-servidor de todas las aplicaciones harán uso de esta tecnología.
El sistema de Invocación Remota de Métodos (RMI) de Java permite a un objeto que se está
ejecutando en una Máquina Virtual Java (VM) llamar a métodos de objetos remotos (residentes en otros
elementos de la red, o en otros procesos de un mismo ordenador aislado) de la misma forma que las
llamadas a métodos de objetos locales que residen en el mismo espacio de direcciones del objeto llamante.
Las aplicaciones RMI normalmente comprenden dos programas separados: un servidor y un cliente.
Una aplicación servidor típica crea un montón de objetos remotos, hace accesibles unas referencias a
dichos objetos remotos, y espera a que los clientes llamen a estos métodos u objetos remotos. Una
aplicación cliente típica obtiene una referencia remota de uno o más objetos remotos en el servidor y llama
a sus métodos [ver Anexo E.4]. RMI proporciona el mecanismo por el que se comunican y se pasan
Carlos Mediavilla Martí
4
20/07/06
Tecnología Java
información del cliente al servidor y viceversa, es decir actúa como un middleware que permite comunicar
aplicaciones distribuidas escondiendo los detalles de heterogeneidad de las mismas, ver figura 2.1.
Figura 2.1 Arquitectura comunicación RMI
Como se puede ver en la tabla de la figura 2.2, la capa de aplicación del cliente traduce su invocación a
una llamada al objeto Stub, que se traduce a JRMP, después a TCP, hasta llegar al nivel de hardware del
cliente, que la envía al hardware donde está el objeto remoto. Aquí se recorre en orden inverso, desde el
hardware hasta la capa de aplicación. Esta arquitectura mantiene la flexibilidad, podemos reemplazar una
capa sin afectar a la eficacia del conjunto. Por ejemplo, podemos usar UDP (User Datagram Protocol) en
lugar de TCP.
CLIENTE
OBJETO REMOTO
OSI
Cliente invocando método
en el objeto remoto
Objeto remoto ofrece
servicio
Aplicación
Stub
Skeleton
Presentación
JRMP
JRMP
Sesión
TCP/UDP
TCP/UDP
Transporte
IP
IP
Red
Interface hardware
Interface hardware
Medio físico
Figura 2.2 Pila protocolos tecnología Java RMI
Carlos Mediavilla Martí
5
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
3. LA CÉLULA DE FABRICACIÓN
3.1. Descripción general
El desarrollo práctico de la aplicación de control será realizado sobre la célula de fabricación flexible
instalada en un laboratorio del Departamento de Informática e Ingeniería de Sistemas. La célula esta
formada por un conjunto de estaciones que permiten la producción y almacenamiento de cilindros
neumáticos con diferentes colores y tapas. La célula esta diseñada para funcionar como ayuda para el
estudio de un proceso de fabricación real sin tener que recurrir a un sistema de producción industrial real a
escala completa [ver Anexo A].
La célula se divide en dos partes: la zona de producción, constituida por las estaciones 1, 2, 3 y 4 y el
transporte 1, y la zona de expedición de pedidos con las estaciones 6, 7 (almacén), el robot y el transporte
2. La estación 5 es el módulo de almacenamiento intermedio que actúa como enlace entre los dos módulos
En este proyecto, el control de la célula de fabricación flexible se va a limitar a la zona de expedición
de piezas de la célula, incluyendo esto al identificador de productos pero dejando fuera el control de la
estación 2 por su complejidad. De este modo, el proyecto final consistirá en la automatización de un
proceso de fabricación donde se coordinará la operación, para ser exactos, de la estación 1, estación 3,
estación 4 y el transporte con el identificador de productos (Ver figura 3.1)
Switch
Módulo Inline
Estación 4
Tsx Momentum
Estación 3
155.210.154.216
PC Linux
Identificador
de Productos
RS-232
Módulo Inline
Estación 1
Tsx Momentum
Transporte
155.210.154.217
CIF-50 PCI
Figura 3.1 Disposición de la célula y la red de comunicaciones implicados en el proyecto
El primer sistema de control implantado en la célula consistió en dotar a cada estación de un autómata
programable, interconectados con una red industrial en tiempo real (bus de campo Fipway).
Posteriormente se decidió instalar un sistema de control alternativo mediante el bus de campo Interbus. El
Carlos Mediavilla Martí
6
20/07/06
La célula de fabricación
bus Interbus esta implantado actualmente en las estaciones 1 y 4. En ambas estaciones se han colocado
módulos Interbus Inline completamente modularizables. Este tipo de configuración permite una gran
flexibilidad a la hora de cablear los sensores y accionadores de las estaciones. La estación 3 y el transporte
1 disponen de módulos I/O TSX Momentum de Schneider Electric de 16 entradas y 16 salidas digitales,
esto tiene la ventaja de que la interfaz de comunicaciones es intercambiable, se puede colocar un
comunicador Interbus o un comunicador Ethernet, así que se ha optado por comunicadores Ethernet. Los
módulos de entradas / salidas están cableados a los accionadores, sensores y mandos de cada estación.
3.2. Bus de campo InterBus
En el ámbito de las redes para comunicaciones industriales uno de los medios más usados para la
transmisión de datos son los buses de campo, existe una gran variedad, FipIO, AS-i, Interbus, Profibus,
FieldBus, DeviceNet, busCan, ... En la célula hay implantados 2 de ellos, pero el que utilizamos es
Interbus [12]. Interbus es un bus de campo donde los dispositivos se conectan en una topología de anillo.
La señal pasa en un sentido solo. Cada dispositivo actúa como un repetidor y amplificador de señal antes
de pasarla al próximo dispositivo en el anillo. Si cualquier dispositivo falla el anillo se rompe. La red
Interbus proporciona un enlace serie capaz de transmitir datos de entrada/salida con velocidades de tiempo
real, esto significa que los datos son actualizados más rápidamente de lo que la aplicación pueda resolver
la lógica. Por otro lado, no se puede leer una entrada o escribir una salida individualmente, sino que la
lectura de todas las entradas y escritura de todas las salidas se realiza en la misma operación por la tarjeta
maestra del bus [ver Anexo B].
La comunicación con la red Interbus se lleva a cabo mediante una tarjeta controladora de bus
Interbus Hilscher CIF-50 PCI [13]. La tarjeta fue instalada en uno de los PCs con sistema operativo Linux
del laboratorio. Esta tarjeta actúa como interfaz remoto entre el bus Interbus y el programa de control. La
tarjeta realiza una tarea cíclica de lectura y escritura en el bus. Los valores que lee se guardan en una
memoria de la tarjeta, los valores que escribe en el bus también se cogen de dicha memoria. Una vez
conectados todos los dispositivos al bus Interbus y con la tarjeta controladora estando conectada también
al bus Interbus, se configuró ésta mediante el software SyCon que provee Hilscher.
El fabricante de la tarjeta maestra del bus suministra un conjunto de rutinas (inicialización y
finalización del bus, proceso cíclico de lectura/escritura de datos, etc...) que pueden usarse para desarrollar
un programa de control de los componentes del bus mediante un lenguaje de alto nivel. Dicha biblioteca
esta escrita en el lenguaje de programación C, por lo que en principio existe un conflicto, ya que nuestra
aplicación es Java. Sin embargo gracias al API Java JNI [14], la cual permite llamar a funciones escritas
en otros lenguajes, se puede usar la funcionalidad encapsulada en la biblioteca escrita en C para acceder a
los datos del bus en nuestro programa en Java.
3.3. Comunicadores Ethernet
Por otro lado, la estación 3 (155.210.154.216) y el transporte 1 (155.210.154.217) de la célula disponen
de módulos TSX Momentum de 16 entradas/salidas digitales y 2 entradas/salidas analógicas con conexión
de red Ethernet [ver Anexo C.1], que ofrecen una manera alternativa de comunicación con el ordenador de
control por medio del protocolo ModBus TCP/IP [15] [16]
Ethernet se esta imponiendo frente a los buses de campo como plataforma de comunicación en los
entornos industriales. Ethernet es un estándar, rápido (hasta 1Gbit/s), económico y flexible. TCP/IP es un
protocolo universal, simple, robusto, es suministrado como estándar con la mayoría de sistemas
operativos, es independiente de la topología (Ethernet, Token-ring) y por supuesto es el protocolo
utilizado por Internet.
Carlos Mediavilla Martí
7
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Hay que tener en cuenta que las redes Ethernet tienen características que pueden no ser adecuadas para
todas las aplicaciones de control. El tráfico existente en la red, el tamaño de los mensajes, la frecuencia
con la que se generan los paquetes, el método de acceso a la red utilizado (CSMA/CD Carrier Sense
Multiple Access with Collision Detection) y el routing, son todos elementos variables y por lo tanto
impredecibles. Estas características pueden aumentar la congestión y las colisiones de mensajes en la red.
Cuando se produce una colisión, un nodo espera una cantidad de tiempo variable antes de retransmitir el
mensaje. Por lo tanto, una predecibilidad absoluta no se puede garantizar en redes con mucho tráfico.
Para minimizar los efectos adversos que Ethernet podría provocar en la aplicación de control que
requiere tiempo real, podemos separar el tráfico generado por los sistemas de información (datos
comunes) de los datos de control. Esto puede conseguirse teniendo la red de control separada físicamente
del resto (dominios de colisión) o usar puentes, switches y routers para segmentar la red, aislando el
tráfico normal del de control. Teniendo esto en cuenta, la red LAN del laboratorio tiene una estructura en
estrella donde el elemento central es un switch al cual se conectan a través de cables de par trenzado sin
blindaje UTP Categoría 5 (la longitud de los cables nunca supera los 20 m) los diferentes dispositivos
Ethernet de la célula (módulos Momentum, autómatas, robots y terminales de explotación Magelis HMI) y
diversos ordenadores de control y supervisión. Aunque en el prototipo del laboratorio no hay, la red
también podría ser de fibra óptica, sería lo ideal en un entorno industrial por su inherente inmunidad a la
inducción e interferencias electromagnéticas.
3.4. Identificador de productos
La información de los palets, que discurren por el transporte trasladando las piezas de una estación a
otra, es almacenada en una pequeña memoria que ellos mismos poseen. Al principio de la operación en
una estación de la célula, el programa debe leer la memoria del palet que llega a la estación para
determinar la operación que se debe realizar. Al final de la operación de fabricación se debe actualizar la
memoria del palet. Según el proceso realizado en cada una de ellas se escribirá una determinada
información en el disco magnético situado en la parte inferior del palet que podrá ser utilizada por las
siguientes estaciones cuando el palet llegue a ellas para actuar de forma coherente con el contenido del
mismo. Esto se consigue a través del identificador de productos instalado en la célula [ver Anexo A.3].
Cada una de las estaciones de la célula dispone de un cabezal de lectura/escritura de la memoria de los
palets donde se realiza la producción, estos cabezales están conectados a un módulo identificador de
productos IVI-KHD2-4HRX de Pepperl&fuchs [17]. Dado que este identificador aún no esta conectado a
la red Interbus del laboratorio, la opción alternativa para su control es a través del puerto serie mediante el
protocolo RS-232. El identificador es un recurso compartido por todas las estaciones y deberá ser
protegido para gestionar accesos simultáneos.
Carlos Mediavilla Martí
8
20/07/06
Redes de Petri
4. REDES DE PETRI
4.1. Descripción básica
Una Red de Petri (RdP) [18] es una herramienta gráfica y matemática que nos va a servir para modelar
el comportamiento de un sistema de eventos discretos como es el caso de la célula de manufactura [ver
Anexo D]. Las RdP son grafos bipartidos que constan de dos tipos de nodos: los lugares y las transiciones.
Los lugares son representados mediante circunferencias y las transiciones mediante segmentos rectilíneos.
Los lugares y las transiciones están unidos mediante arcos orientados. Un lugar se puede unir mediante un
arco con una transición, y una transición se puede unir con un lugar también mediante un arco. Pero nunca
se podrán unir mediante un arco dos lugares o dos transiciones. Un lugar puede contener un número
positivo o nulo de marcas. La distribución de marcas en los lugares se conoce como marcado y representa
el estado del sistema. En el caso de la aplicación de las RdP a la descripción funcional de
comportamientos en los sistemas de eventos discretos se puede considerar que:
•
Un lugar representa una parte del estado a la que puede llegar el sistema. Si un lugar está marcado,
significa que es una parte del estado en la que está el sistema en ese momento.
•
A las transiciones se les asocian los eventos. El disparo de una transición indica la ocurrencia de
un evento que cambia el estado del sistema (el marcado de la RdP)
Figura 4.1 Vista parcial de la Red de Petri para el control de la estación 3
Carlos Mediavilla Martí
9
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Cuando se utiliza una RdP para el control de sistemas, se incorpora una interpretación que suele
consistir en la asociación de:
•
Acciones impulsionales al disparo de transiciones (cambios en el valor de una señal de control,
ejecución de un código, …)
•
Generación de señales de control asociadas al marcado de lugares (si un lugar está marcado cierta
señal estará en nivel alto)
•
Predicados que condicionan el disparo de las transiciones sensibilizadas. Estos predicados son
función de las entradas al sistema de control o de variables internas.
Una RdP con esta interpretación se le denomina Red de Petri sincronizada (con su entorno), o
interpretada para control (su aplicación más difundida)
La implementación Java, o sea, el diseño y código Java de las clases que modelan la estructura de una
red de Petri se puede ver en el correspondiente capítulo de los anexos. Además uno de los componentes
gráficos más interesantes realizados en el proyecto es la visualización en tiempo real de una RdP en
ejecución [ver apartado 6.3].
4.2. Implementación software
Una implementación programada de una Red de Petri (RdP) es un programa o algoritmo que ejecuta el
disparo de las transiciones de la RdP, respetando las reglas de evolución del modelo. Las
implementaciones se pueden clasificar como compiladas o interpretadas, secuenciales o concurrentes y
como centralizadas o descentralizadas.
Una implementación es interpretada si la estructura de la red y el marcado son codificados como
estructuras de datos. Estas estructuras de datos son usadas por una o más tareas llamadas intérpretes
encargadas de hacer evolucionar el estado de la red. Los intérpretes son independientes de la red que se
desea controlar. Una implementación compilada esta basada en la generación de una o más tareas donde el
control de flujo corresponde a la evolución de la red.
Una implementación secuencial esta basada en una sola tarea. Esta clase de implementación es común
en aplicaciones compuestas por acciones inmediatas sin un tiempo de ejecución significativo, como en el
caso de los controladores lógicos programables (autómatas). Una implementación concurrente esta
compuesta por un conjunto de tareas de número igual o superior a la concurrencia real de la red.
En una implementación centralizada, la evolución de la red es realizada por una sola tarea llamada
coordinador. Las acciones asociadas pueden ser distribuidas en varias tareas que garanticen la
concurrencia intrínseca de la red. En una implementación descentralizada la red original se descompone
en varias subredes que representan estructuras secuenciales. Cada una de estas subredes es controlada por
un coordinador diferente. En este caso serán necesarias primitivas de comunicación y sincronización entre
las diferentes tareas. Los coordinadores son tareas encargadas de hacer evolucionar una red de Petri,
disparando las transiciones sensibilizadas y actualizando el estado de la red.
En la implementación desarrollada en este proyecto, la red responsable del control de la célula ha sido
divida en varias subredes siguiendo criterios de control, además el programa carga la estructura de las
redes desde un archivo XML generado por un editor de Redes de Petri. Por lo tanto esta implementación
es independiente de la red, es una implementación interpretada y descentralizada.
Carlos Mediavilla Martí
10
20/07/06
Redes de Petri
4.3. Creación de redes de Petri - PNML
Una importante ventaja que presenta una implementación interpretada es que no hace falta cambiar el
código (y recompilar) cada vez que se hace una modificación en la red de Petri. Para ello es necesario el
uso de algún editor gráfico (ver figura 4.1) que permita exportar una RdP a un formato que pueda ser
aceptable por la aplicación.
El editor de Redes de Petri elegido [19] ofrece una interfaz gráfica en la que se puede dibujar la red
deseada y editar parámetros básicos como el número de marcas iniciales en los estados o el tiempo de las
transiciones temporizadas, pero lo mas interesante es la posibilidad de exportar la red construida a un
fichero en formato PNML (Petri Net Markup Language)
PNML [20] es un lenguaje de marcas basado en XML que permite la representación de cualquier tipo
de redes de Petri y cualquier extensión de estas. Las redes de Petri representadas mediante PNML pueden
así ser trasmitidas de una manera estándar a diversas aplicaciones y servicios para su uso posterior, como
por ejemplo en la representación gráfica de las RdP y de su evolución en tiempo real gracias a la
información gráfica de los elementos de la red que contiene (sus coordenadas gráficas). Las etiquetas
válidas, sus posibles valores y la combinación posible de valores en PNML están definidos por el DTD
Petri Net Type Definition (PNTD), a continuación se ofrece un extracto de la red correspondiente a la
estación 3 en dicho formato:
<?xml version="1.0" encoding="iso-8859-1"?>
<pnml>
<net id="Net-One" type="P/T net">
<labels x="259" y="64" width="149" height="22" border="false">
<text>Modo_automat_integrado</text>
</labels>
<place id="P0">
<graphics><position x="240.0" y="45.0"/></graphics>
<name><value>P8</value><graphics/></name>
<initialMarking><value>1</value><graphics><offsetx="0.0"y="0.0"/></graphics></initialMarking>
</place>
<transition id="T0">
<graphics><position x="240.0" y="90.0"/></graphics>
<name><value>T10</value><graphics/></name>
<orientation><value>90</value></orientation>
<rate><value>1.0</value></rate>
<timed><value>false</value></timed>
</transition>
<arc id="P0 to T0" source="P0" target="T0">
<graphics/><inscription><value>1</value><graphics/></inscription>
<arcpath id="000" x="250" y="70" curvePoint="false"/>
<arcpath id="001" x="250" y="95" curvePoint="false"/>
</arc>
</net>
</pnml>
Figura 4.2 Archivo XML generado por el editor de Redes de Petri
El programa de control será capaz de leer y analizar dichos archivos mediante un parser XML y
componer la estructura de la red correspondiente. Esto permite que la puesta en marcha del controlador se
realice de una forma más flexible y rápida que en el caso de definir explícitamente la RdP en un programa
en Java. Esta operación se realizará al inicio del programa porque consume un tiempo no despreciable y
no es recomendable que se haga una vez iniciada la ejecución de alguno de los coordinadores.
Carlos Mediavilla Martí
11
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
5. ARQUITECTURA DE CONTROL
Una de las principales tareas de este proyecto es la definición y desarrollo de una arquitectura de
control basada en Redes de Petri. La arquitectura que se propone se puede dividir en una parte de control
propiamente dicho y otra parte de gestión de las comunicaciones independiente, esto quiere decir que
aunque el control se base en alguna técnica diferente a las redes de Petri, la capa de comunicaciones no se
verá afectada.
En vez de distribuir el control local de cada subsistema de la célula de manufactura (estaciones de
producción, transportes, almacén, etc.) en varios autómatas, se ha optado por centralizar el control en un
computador (o varios en el caso de control distribuido). Aunque hay que tener en cuenta que los
subsistemas de entrada/salida de la célula están distribuidos en varios módulos conectados al bus Interbus
o a la red Ethernet del laboratorio.
5.1. Ejecución de una Red de Petri
La parte de control realiza la evolución de la red de Petri (RdP) que modela el sistema controlado (la
célula de fabricación) La parte software encargada de ello se denomina coordinador. Dado el carácter
cíclico del control, el coordinador será una tarea periódica (como hilo de ejecución independiente)
encargada de recorrer la red en cada iteración y de controlar el disparo de las transiciones de la RdP según
un modelo de conflictos para actualizar el estado de la red. Un conflicto estructural se produce cuando dos
o más transiciones sensibilizadas descienden de un mismo lugar y éste no dispone de un número de
marcas suficientes para dispararlas simultáneamente. La funcionalidad básica de un coordinador será:
•
Efectuar las acciones durante el mantenimiento del marcado de un estado.
•
Encontrar las posibles transiciones a disparar, es decir aquellas que estén sensibilizadas. Una
transición esta sensibilizada cuando todos sus lugares de entrada están marcados (red binaria)
•
Evaluar la condición de disparo de las transiciones sensibilizadas.
•
Conocer y controlar el tiempo de marcado de un lugar
•
Implementar el disparo efectivo de las transiciones. Los pasos a seguir son: desmarcado de lugares
de entrada, marcado de lugares de salida y ejecución del código asociado a la activación o
desactivación de dichos lugares.
En resumen, en cada ciclo del coordinador se disparan todas las transiciones sensibilizadas y que
cumplan su condición de disparo. El problema que surge es que transiciones que originalmente estaban
sensibilizadas, pueden quedar desensibilizadas si la transición disparada esta en conflicto con ellas. Por
eso, para tratar los conflictos cada transición tiene asociada una prioridad, si hay varias candidatas a
disparar siempre se escoge la de mayor prioridad, y luego se eliminan de la lista de transiciones
sensibilizadas aquellas en conflicto que hayan quedado desensibilizadas, ver figura 5.1.
Carlos Mediavilla Martí
12
20/07/06
Arquitectura de control
Ejecutar la acción
continua de los
estados marcados
Test sensibilización
¿Quedan
transiciones
sensibilizadas?
SI
¿Condición
de disparo?
Coger transición con
mayor prioridad
NO
SI
Ejecutar la acción
posterior de los
estados de entrada
¿Es
conflictiva?
NO
Disparar transición
SI
Ejecutar la acción
previa de los estados
de salida
Eliminar transiciones en
conflicto de la lista
transiciones sensibilizadas
Eliminar transición de
la lista transiciones
sensibilizadas
Figura 5.1 Algoritmo para la ejecución de una Red de Petri
Para poder hacer evolucionar el estado de la RdP en sincronía con el sistema controlado, es necesario:
•
Leer las distintas entradas provenientes de los sensores de la célula (respondiendo a eventos que
se produzcan en el sistema físico) para poder determinar la condición de disparo de las
transiciones.
•
Realizar las acciones sobre el sistema físico ejecutando el código asociado a la activación o
desactivación de los accionadores de las máquinas de las estaciones.
•
Leer y escribir en la memoria de los palets para saber si una estación debe producir o no.
La funcionalidad requerida se consigue a través de la capa de comunicaciones.
Carlos Mediavilla Martí
13
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
5.2. Capa de comunicaciones
Las comunicaciones con el sistema controlado se podrían implementar con los coordinadores
accediendo directamente a la red de comunicaciones para leer o escribir cada vez que necesitarán
interactuar con la célula. Esta estrategia no sería muy eficiente porque aun que se quiera escribir o leer una
sola variable de las estaciones implica una escritura o lectura completa del bus. Así que esa tarea se ha
dejado a la capa de comunicaciones y los coordinadores acceden a los datos que necesitan a través de
monitores que garantizarán la exclusión mutua en el acceso a las variables. De esta manera la
implementación de la capa de control es independiente del sistema empleado para comunicarse
físicamente con los dispositivos de la célula, ver figura 5.2.
La capa de control tiene acceso a las variables tanto de entrada como de salida de las estaciones de la
célula gracias de los monitores de cada estación. En ellos, la parte software que da soporte para
comunicarse con los módulos de entrada – salida almacena los valores provenientes de los diferentes
sensores y recoge los valores que serán enviados a los accionadores de las máquinas de las estaciones.
APLICACIÓN CONTROL Y SUPERVISIÓN
CAPA DE CONTROL - COORDINADORES
MONITORES
RS - 232
Ethernet
InterBus
Ethernet
CAPA DE COMUNICACIONES
I. productos
Autómatas
Módulos I/O
CELULA DE FABRICACIÓN
Figura 5.2 Rol de la capa de comunicaciones
INTERBUS
Por una parte se ha desarrollado el programa que permite comunicarse con las estaciones conectadas al
bus Interbus. Este se implementa como una tarea periódica encargada de leer todas las variables de
entrada del bus y escribir las variables de salida en el bus, esta tarea se realiza cada 10 ms, suficiente dada
la dinámica del sistema controlado. El programa hace uso del driver (funciones nativas escritas en código
C accedidas a través de JNI - Java Native Interface) ofrecido por el fabricante de la tarjeta maestra PCI del
bus [ver Anexos B.5 y E.5]. Realmente no se escribe o lee directamente del bus, sino en una imagen de la
memoria de dicha tarjeta.
Los valores leídos por la función nativa, que corresponden directamente a los valores booleanos de los
sensores y botoneras situados en las estaciones de la célula, son almacenados en el monitor de la estación
correspondiente dejándolos disponibles para el proceso de control. Por otra parte el proceso de control
almacena en esos mismos monitores los valores booleanos que serán enviados a los accionadores de las
máquinas.
Carlos Mediavilla Martí
14
20/07/06
Arquitectura de control
ETHERNET
Por otro lado, para establecer la comunicación con los módulos I/O Momentum Ethernet de la estación
3 y el transporte se ha escrito un código similar al desarrollado para Interbus. El fabricante de dicho
dispositivo también proporciona una biblioteca de comunicaciones [21], ésta dispone de funciones para
escribir y leer los valores almacenados en los registros de memoria RAM del procesador Momentum M1E
por medio del protocolo ModBus TCP/IP [ver Anexo C.3]. Los valores escritos o leídos en los registros
pueden ser de tipo booleano o palabras de 16 bits. Esta vez, la biblioteca esta escrita en el lenguaje Java,
así que se podrá usar directamente en nuestro código sin necesidad de usar JNI.
A diferencia de Interbus, que en una sola operación realiza las lecturas y escrituras en todas las
estaciones, las operaciones con Ethernet son individuales para cada estación, por lo tanto Ethernet parece
el medio de comunicación más adecuado para utilizar en una aplicación de control distribuido. De hecho,
si todas las estaciones estuvieran conectadas a la red Interbus, no sería posible un control distribuido ya
que la tarjeta maestra del bus es única y solo puede estar en un PC.
Mencionar también que Ethernet es una manera alternativa para comunicarse con la estación 3 y el
transporte, ya que dichas estaciones se podrían integrar en el anillo Interbus, gracias a la versatilidad de
los módulos Momentum.
PUERTO SERIE
Finalmente, también hay que desarrollar el programa para conseguir la comunicación con el
identificador de productos y poder así controlar la producción. Sun proporciona una librería de
comunicaciones Java para las aplicaciones que necesitan comunicarse con algún dispositivo mediante una
línea de comunicación serie [22].
Debido a que la máquina virtual Java que se usa en el proyecto no soporta el modelo de eventos para el
puerto serie, se estudiaron las siguientes posibilidades para acceder al identificador de productos:
a) Realizar un controlador escrito en C y acceder a sus métodos por medio de llamadas nativas JNI.
b) Implementar una aplicación para el puerto serie que se ejecuta en la máquina virtual estándar y se
comunica con el servidor de la aplicación principal (Jamaica) por medio de RMI. Existen dos variantes de
esta opción, dependiendo de si la aplicación principal puede hacer de cliente (1) o no (2)
1- La aplicación principal envía la información (destinada al identificador de productos) a la aplicación
que hace de servidor del puerto serie, esta es la encargada de gestionar la comunicación con el
identificador vía puerto serie, esta llamada sería no-bloqueante, esto quiere decir que la aplicación
principal continúa con sus tareas. Cuando el identificador de productos responde al servidor del puerto
serie, éste avisa y envía la trama recibida a la aplicación principal mediante el uso de RMI.
2- En esta opción, la mini-aplicación responsable de la comunicación con el puerto serie, pregunta cada
cierto tiempo (polling) a la aplicación principal si tiene algo para enviar al identificador de productos, y si
es así, recoge la trama de la aplicación principal, la envía al identificador y cuando le llega la respuesta se
la envía a la aplicación principal de manera similar al método anterior. La opción finalmente
implementada es esta última, ver figura G.3.
Carlos Mediavilla Martí
15
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
5.3. Técnica de control descentralizada
Como la red de Petri necesaria para el control completo de la célula sería enorme (más de un centenar
de estados y transiciones) y además no permitiría un control distribuido, se ha creado una red para cada
uno de los subsistemas de la célula. La subdivisión del sistema global para el control de la célula en varias
subredes se realiza con criterios de control y de entrada/salida [ver Anexo D.4]. Esto permitirá una mayor
facilidad de cambios y modificaciones en el programa. Así pues, las diferentes subredes se encargarán de
modelar el comportamiento de una parte de la célula de fabricación: de la operación local en una estación
[RedEstacion1, RedEstacion3 y RedEstacion4], del control del movimiento físico del
transporte, de la puesta en marcha y paro global de la célula de fabricación [RedCelula] y de la
inicialización de los palets [RedBorrar].
Cada una de las subredes que conforman el control de la célula será ejecutada por un coordinador
diferente. Los múltiples coordinadores serán lanzados en concurrencia (varios hilos de ejecución
funcionando simultáneamente), realizando cada uno de ellos la ejecución de la subred de Petri encargada
de controlar una de las estaciones de la célula hasta que se llega al final de la producción, ver figura 5.3.
Comúnmente, cada una de las tareas en las que se descompone la parte de control, actúa sobre una red
secuencial.
Lugar Comunicación
Lugar Comunicación
Lugar Comunicación
RedEstacion4
Lugar Comunicación
RedEstacion3
RedEstacion1
RedBorrar
Monitor
Estación 4
RedCelula
Monitor
Estación 3
T=20 ms
Monitor
Estación 1
Comunicaciones
Figura 5.3 Arquitectura de control mediante coordinadores concurrentes
Carlos Mediavilla Martí
16
20/07/06
Arquitectura de control
La descomposición de una red de Petri en una o más subredes, dará lugar a la aparición de lugares
pertenecientes a varias redes a la vez. Los lugares con esta característica son denominados lugares de
comunicación. Si un lugar es compartido se definirá como un objeto protegido con métodos de marcado y
desmarcado sincronizados para garantizar la exclusión mutua en el acceso a sus métodos. La
comunicación entre los diferentes coordinadores se realiza a través de los lugares de comunicación. Por
ejemplo, cuando se inicia el coordinador global de la célula (que controla la red RedCelula) marca un
estado (P140) que a su vez también pertenece a la red RedBorrar (controlada por el
CoordinadorBorrar) de este modo el CoordinadorBorrar puede comenzar el proceso de
borrado de los palets, cuando acaba, marca otro estado (P141) que también pertenece a la RedCelula
devolviendo el control al coordinador global de la célula, ver figura D.7.
En esta implementación aparecen los conflictos externos, que se dan cuando un lugar de comunicación
tiene varias transiciones de salida repartidas en varias subredes diferentes. Para la resolución de este tipo
de conflictos no sirve la estrategia comentada anteriormente para conflictos internos. En este caso, se ha
resuelto el conflicto como una subasta donde la transición con más prioridad es la que se disparará (se
puede ver el código comentado en el CD adjunto)
Dentro del presente proyecto existe una parte claramente condicionada por la concurrencia: el acceso
al identificador de productos. Esta situación se produce cuando las estaciones intentan acceder al
identificador de productos para leer o escribir los palets. Dado que el identificador de productos sólo
puede atender a una de ellas cada vez, debe de implementarse algún sistema que permita el control de
quién y cómo accede al recurso. Esto se puede resolver de manera sencilla definiendo un estado
(compartido por todas las estaciones) que simbolice el identificador de productos, una marca en el estado
significará que esta libre, cuando un coordinador necesite acceso al identificador necesitara disparar una
transición, la cual solo estará sensibilizada si existe una marca en el estado que simula el identificador,
cuando acabe la operación devolverá la marca y otros coordinadores tendrán acceso al identificador (ver
figura 5.4)
Identificador
Productos
Red Estación x
Red Estación y
Figura 5.4 Identificador implementado como lugar de comunicación
Finalmente, mencionar que a cada coordinador (que realmente son threads) se le puede asignar una
prioridad que el planificador de la máquina virtual Jamaica utilizará para gestionar el acceso al
procesador. Típicamente se puede asignar una prioridad baja a los coordinadores que controlan las
estaciones, mientras que el coordinador global de la célula podría tener una prioridad media. Prioridades
más altas deben reservarse para las tareas de emergencia y comunicaciones con la célula.
Carlos Mediavilla Martí
17
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
5.4. Control distribuido
En este proyecto se va a interpretar el control distribuido como una instalación modular y una
descentralización de la inteligencia [23]. Lo primero ya esta conseguido, los comunicadores de entradasalida se hayan dispersos por toda la célula, lo segundo se realizará ejecutando uno o más de los
coordinadores que controlan una estación en un computador diferente (cada estación podría ser controlada
por un PC diferente). La descentralización de la inteligencia puede estar motivada por varios factores,
principalmente:
•
Se requiere que varios procesos de control se ejecuten concurrentemente (y sólo se dispone de
sistemas monoprocesador)
•
Existen tareas de ejecución que tienen que ser realizadas en un computador específico.
•
Limitaciones físicas hacen que se requieran más de dos computadores para el control. Por
ejemplo, cuando existan varios buses de campo con sus tarjetas maestras en diferentes PCs.
En este proyecto la razón es simplemente por extender la técnica de control descentralizado a varios
computadores y estudiar las posibilidades de comunicación entre las aplicaciones. La ejecución de las
redes correspondientes al control de las estaciones 1 y 4 tiene que realizarse en el mismo computador que
posee la tarjeta de comunicaciones Interbus, no pueden distribuirse. Para conseguir distribuir por completo
el control sería necesario que cada estación dispusiera de un comunicador Ethernet. Así pues, como una
aproximación a un control distribuido se ha decidido realizar el control de la estación 3 en otro
computador. La técnica de control es similar a la anterior, con la singularidad de que uno de los
coordinadores se ejecuta en un computador diferente. En esta implementación, una aplicación (la
principal) actúa como servidor y las demás (en este caso particular solo la aplicación que se encargará del
control de la estación 3) actúan como clientes.
Existen dos estrategias a la hora de distribuir el control de la estación 3. En la red actual que se utiliza
para el control descentralizado de la estación 3 hay dos partes claramente diferenciadas, en una se gestiona
la entrada y salida del palet y se accede al identificador de productos para saber si la pieza es buena o no y
la segunda parte se encarga del control de la estación propiamente dicho. La opción A, consiste en
trasladar el control de dicha red integra fuera, mientras que en la opción B, el ordenador remoto solo
ejecutaría la parte de producción. La ventaja de esta segunda opción es que la necesidad de comunicación
entre los PCs es menor que si se utiliza la primera donde habrá una mayor interacción entre las dos partes
de la aplicación distribuida. En el presente proyecto se han realizado las dos versiones.
Independientemente de la estrategia elegida, el principal problema que nos encontramos es como
comunicar a nivel de aplicación los diversos computadores involucrados en la tarea de control.
Por un lado hay que comunicar los lugares compartidos distribuidos, es decir aquellos lugares que
pertenecen a dos subredes que no se están ejecutando en el mismo computador. Esto se ha resuelto
definiendo dichos lugares como objetos remotos en el servidor principal, mientras que en el ordenador
remoto el coordinador realiza llamadas RMI al servidor principal cuando necesita realizar acciones sobre
un lugar compartido distribuido, ver figura 5.5. Recordar que RMI permite que varios programas Java
ejecutándose en máquinas virtuales diferentes (incluidas máquinas virtuales en PCs remotos) se puedan
comunicar entre ellos. El código desarrollado tiene especial cuidado en caso de conflicto distribuido (una
o más transiciones de diferentes subredes descienden de un mismo lugar de comunicación). Si ambas
transiciones son disparadas en instantes de tiempo lo suficientemente cercanos podrían provocar el
desmarcado de un lugar que ya ha sido desmarcado. RMI crea sockets que establecen conexiones sobre
TCP/IP, si el tráfico en la red es pesado o la comunicación tiene que pasar a través de muchos nodos el
tiempo antes indicado aumentará, provocando situaciones de este tipo.
Carlos Mediavilla Martí
18
20/07/06
Arquitectura de control
Lugar de
comunicación
distribuido
Red x
Marcar()
Desmarcar()
Red y
RMI
Computador B (remoto)
Computador A (principal)
Figura 5.5 Comunicación RMI entre lugares distribuidos
Por otro lado, en la opción A, otras partes del código en el coordinador remoto también necesitarán
acceder a objetos que contienen información sobre el estado de la producción (pedidos y palets) o a las
entradas/salidas del transporte que se encuentran el servidor principal. De la misma forma que para los
lugares compartidos distribuidos se pueden definir métodos remotos para acceder a la información
necesaria para la ejecución de la red de Petri y la aplicación en general en el computador remoto.
Esta arquitectura abierta y modular hace que aunque se amplíe y aumente la complejidad de la
instalación (añadiendo alguna nueva estación por ejemplo), la actualización del conjunto no ofrecerá
complicación alguna.
5.5. Toma de medidas
Se han tomado medidas de los tiempos de actualización de las variables en la red Interbus y en la red
Ethernet, se ha medido el tiempo que cuesta una petición RMI en el control distribuido y también se
observaron los tiempos de la ejecución de un coordinador.
INTERBUS
Los tiempos medidos nunca superaban el milisegundo, muy pronto se descubrió que realmente se
estaba midiendo el tiempo de la llamada a la función nativa, no el tiempo real de la transmisión de datos
entre la tarjeta del bus y los módulos de entrada / salida. El tiempo de transmisión de los datos, que
realmente es el tiempo de ciclo del refresco de los datos en la tarjeta, en una red Interbus es determinista y
se puede conocer utilizando la fórmula que da el fabricante, que en nuestro caso es de 1.6 ms
aproximadamente (ver Anexo B.3)
ETHERNET
Los tiempos obtenidos experimentalmente para las comunicaciones Ethernet se pueden ver en la
siguiente figura. Se puede observar que el tiempo de ciclo (lectura de entradas y escritura de salidas) es
ligeramente más lento que en Interbus. Realmente la gráfica refleja solo el tiempo de acceso para una
estación, si tenemos en cuenta que con Interbus se accede a todas la variables de las estaciones que están
conectadas a la red Interbus, la diferencia de tiempo es significativa. También es interesante apreciar que
Ethernet no es determinista, al contrario que Interbus (figura 5.6)
Carlos Mediavilla Martí
19
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Figura 5.6 Tiempos estadísticos acceso Ethernet a: sin tráfico; b y c: con tráfico
CONTROL DISTRIBUIDO
Las llamadas RMI para marcar, desmarcar o conocer el número de marcas de un estado, consumen un
tiempo variable (de acuerdo a las características de Ethernet) pero nunca sobrepasan 5ms como se puede
ver en la salida de consola que se muestra:
Tiempo de lookup LugarComunicacion 144: 149 ms
Tiempo de lookup LugarComunicacion 301: 95 ms
ServidorEstacion3 distribuido B OK
COMIENZA EJECUCION COORDINADOR: estacion 3 MEDIANTE TRANSICIONES SENSIBILIZADAS
…
Disparo Transicion T3
-----------------Tiempo acceso marcar(int tokens) remoto: 4 ms
Disparo Transicion T5
…
Disparo Transicion T28
-----------------Tiempo acceso getVariableEntrada(Transporte) remoto: 3 ms
Disparo Transicion T29
Disparo Transicion T30
Disparo Transicion T31
-----------------Tiempo acceso marcar(int tokens) remoto: 3 ms
Disparo Transicion T0
…
Disparo Transicion T3
-----------------Tiempo acceso marcar(int tokens) remoto: 5 ms
Disparo Transicion T4
COORDINADORES
Aunque no se puede decir nada a priori del tiempo que puede costar la ejecución de la lógica de un
ciclo del coordinador porque dependerá del número de transiciones que se disparen, los tiempos medidos
experimentalmente muestran un tiempo claramente inferior al milisegundo.
Carlos Mediavilla Martí
20
20/07/06
Arquitectura de control
RESUMEN
Todas estas medidas nos pueden ayudar a la hora de determinar el mínimo periodo con el que un
coordinador puede ejecutarse. Para la aplicación que controla la estación 3, en el peor de los casos los
tiempos que hay que tener en cuenta son: 1ms por el tiempo de resolución de un ciclo, más 5ms por el
acceso a un lugar distribuido, más 6ms de acceso a Ethernet nos dan un tiempo de 12ms. En el caso de la
aplicación principal tenemos 4 coordinadores ejecutándose simultáneamente (4ms) y el acceso Ethernet al
transporte (6ms), lo que suma 10ms. Todos estos tiempos son meramente orientativos pero se puede decir
que un tiempo de ciclo de 20ms asegurará que todo funcione correctamente.
Hay que tener en cuenta que las prestaciones en tiempo real están limitadas a las capacidades del S.O.
subyacente y de los procesos que se estén ejecutando en background. Uno de los procesos que más
recursos consume es el interfaz gráfico, si se ejecuta la aplicación que realiza el control en tiempo real sin
arrancar el interfaz gráfico de Linux (solo consola) los tiempos antes mostrados mejoran ligeramente.
Carlos Mediavilla Martí
21
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
6. APLICACIONES DE CONTROL Y SUPERVISION
REMOTO A TRAVES DE INTERNET
Aunque la aplicación principal del proyecto tenga como objetivo final el control completo de la célula,
se han desarrollado otras diversas aplicaciones de control y/o supervisión (que se describen en el Anexo).
Estas han servido para comprobar el correcto comportamiento de la implementación Java de las redes de
Petri, la técnica de control descentralizada, la comunicación con los módulos de comunicaciones Interbus
y Ethernet, resolver la problemática con el identificador de productos y comprobar el funcionamiento de
las estaciones de manera independiente [ver Anexo G. Aplicaciones]. Posteriormente se diseñó la
aplicación del control distribuido de la célula de fabricación con la experiencia y progresos recogidos en
las anteriores aplicaciones prototipo.
6.1. Arquitectura cliente-servidor
Se ha decidido diseñar las aplicaciones siguiendo una arquitectura cliente-servidor (separando la parte
de control del interfaz gráfico) motivado principalmente por que la máquina virtual que implementa la
especificación de tiempo real ofrece un soporte a gráficos limitado, considerándolo insuficiente para
nuestros propósitos. Además se considera que una aplicación de estas características tenga múltiples
usuarios que deban acceder a ella desde diversas localizaciones.
Los clientes pueden ser implementados como un programa Java que crea una interfaz gráfica
tradicional o como una aplicación que se ejecuta dentro de un servidor Web. En ambos casos, el cliente
utiliza RMI [ver Anexo E.4] para conectarse con el servidor de la aplicación y adquirir los datos que
necesita para generar la interfaz e interactuar con el proceso de control, ver figura 6.1. La tarea de
actualización de los datos de visualización se realiza periódicamente cada 500 ms, suficiente para un
proceso de supervisión con un operador humano.
RMI
RMI
Cliente Gráfico
Local RMI
Servidor
Web
Cliente RMI
Cliente Gráfico
Remoto RMI
RMI
Control Tiempo Real
Jamaica VM
Servidor RMI
RMI
HTTP
Navegador Web
Cliente RMI
Cliente HTTP
Estación
Control
Tiempo Real
LINUX
Estación
Visualización
Remota
WINDOWS
LINUX
Figura 6.1 Arquitectura cliente-servidor de las aplicaciones
Carlos Mediavilla Martí
22
20/07/06
Aplicaciones de control y supervisión
Gracias a la portabilidad entre diferentes sistemas operativos que ofrece Java, el hecho de que la parte
de control de la aplicación se ejecute en un sistema Linux no implica que los clientes que presentan la
interfaz de usuario solo puedan ejecutarse en PCs con el mismo S.O., sino que pueden ser PCs con otro
sistema operativo como Windows.
Las aplicaciones creadas en un puesto servidor resultan accesibles desde los puestos cliente remotos,
tanto para controlar el proceso como para realizar simples funciones de vigilancia. Esta arquitectura
multipuesto se puede utilizar en redes locales (Intranet) y también en Internet ya que RMI se basa en
sockets sobre TCP/IP. Se trata de un traslado completo del acceso a las aplicaciones, desde los puestos
cliente se pueden utilizar todas las funciones que ofrece la aplicación.
Los programas que realizan el control en tiempo real cargan las RdP correspondientes a cada una de las
estaciones y la de los coordinadores global y borrar, crean los monitores para cada estación, inicializan la
comunicación con el bus Interbus y los comunicadores Ethernet y también arrancan la ejecución de los
coordinadores. Además, también efectúan el papel de servidor de datos de la aplicación, registrándose
como servidores RMI permitiendo la comunicación con el cliente. En sus clases se han programado una
serie de métodos para que las aplicaciones clientes RMI puedan consultar el estado de la RdP en ejecución
y métodos para efectuar la lectura remota de datos.
Por otro lado, en la versión de la aplicación con control distribuido, la parte de control también tiene
una estructura cliente-servidor. El programa principal, que además controla el transporte y las estaciones 1
y 4 es el servidor y el programa que controla la estación 3 es cliente del anterior servidor (obviamente el
programa de la aplicación principal se debe arrancar primero y luego los posibles clientes)
6.2. Control de la producción
Para el control completo de la célula, como en cualquier proceso automatizado de producción
industrial, también se tiene que gestionar la creación y seguimiento de pedidos. Como ya se ha comentado
con anterioridad, el módulo de fabricación de la célula consta de cuatro estaciones por las que va pasando
un palet con la pieza en producción hasta que se produce su salida al almacén intermedio. Para el control
global del proceso de producción es necesario saber que tipo de pieza se va a realizar y cual es
exactamente el contenido de cada palet. Por eso existe un cabezal de lectura en cada estación encargado de
leer y escribir en dicho palet. La aplicación esta configurada para almacenar en la memoria de un palet la
siguiente información:
•
Identificación del pedido que se va a realizar sobre dicho palet.
•
Fecha de la última modificación de los datos, ya sea de lectura o de escritura.
•
Estado de la pieza producida.
Las aplicaciones que tratan con el control global de la célula, tienen un pantalla donde se lleva el
control de los pedidos pudiéndose lanzar nuevos pedidos especificando el tipo de pieza que se quiere
construir o eliminar pedidos existentes defectuosos. Adicionalmente contienen una lista donde se puede
ver el histórico de pedidos o información detallada de los pedidos actuales.
La producción se gestiona de la siguiente manera: la estación 1 esperará la llegada de un palet vacío
antes de comprobar si existe algún pedido pendiente, si es así sacará la correspondiente camisa del
almacén al palet y actualizará la memoria de dicho palet. A continuación la pieza se dirigirá hacia la
estación 2 para seguir con el proceso de producción. Si la pieza fuera con tapa, existe un desvío intermedio
que hace que la pieza se dirija directamente a la estación 4 (la última estación de esta parte de la célula) La
Carlos Mediavilla Martí
23
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
aplicación tiene en cuenta posibles errores que se pudieran cometer y permite que las piezas inacabadas
vuelvan a la estación 1 para reiniciar el proceso de producción. También gestiona los conflictos que se
puedan producir cuando un palet se dirige hacia la estación 4 desde el desvío intermedio y otro que viene
desde la estación 3, evitando un choque entre ambos. Al final de la producción en la estación 4, se borran
los palets completados. La aplicación tiene en cuenta que se puede dar la situación de que varias
estaciones quieran acceder a la memoria de sus palets al mismo tiempo. El identificador de productos es
un recurso compartido por todas las estaciones. Se ha protegido el acceso a este recurso mediante un
monitor que garantiza la exclusión mutua en su uso por las diversas RdP que controlan las estaciones.
6.3. Interfaz gráfico Java y visualización de redes de Petri
Para crear las interfaces gráficas con función HMI (Human Machine Interface), Java ofrece la API
Swing [24] y AWT. Estas bibliotecas permiten construir aplicaciones gráficas a partir de objetos gráficos
(paneles, botones, ventanas, cuadros de diálogo, menús, etc...) y gestionar los típicos eventos que se
puedan producir en un entorno gráfica (teclado, ratón, etc...) Las aplicaciones desarrolladas, permiten al
operador enviar órdenes de mando para controlar la producción en la célula y supervisar cualquier aspecto
de la ejecución de los coordinadores de forma remota y de manera intuitiva. Los interfaces de las
aplicaciones creadas consisten en pantallas con diversas funcionalidades:
•
Supervisión: En estas pantallas se puede observar el estado de los sensores y accionadores de
cualquier estación de la célula en tiempo real y otros parámetros como alarmas, mantenimiento...
•
Control manual: Estas pantallas permiten controlar de modo manual las estaciones de la célula.
Figura 6.2 Interfaz gráfico Java para el control global de la célula
Carlos Mediavilla Martí
24
20/07/06
Aplicaciones de control y supervisión
•
Control automático: Estas pantallas se encargan del funcionamiento automático de las
estaciones. Disponen de pulsadores para lanzar, detener o continuar la ejecución del
coordinador correspondiente. Se pueden ver datos sobre el estado de la estación y lanzar la
visualización de la red de Petri en ejecución. Los botones de emergencia permiten parar la
producción si algo va mal
Todas las aplicaciones desarrolladas utilizan un panel de visualización de redes de Petri como
mecanismo de supervisión, ver figura 6.4. El diseño de este componente gráfico ha permitido la
visualización en tiempo real del estado de ejecución de una red de Petri. Este puede ser incrustado como
un panel en la ventana de la aplicación, ser lanzado en una ventana independiente o ser visualizado en un
navegador Web como un applet. Sea como fuere, la red de Petri es dibujada y se pueden ver datos muy
útiles para el seguimiento de la ejecución, como por ejemplo, el número de marcas que cada estado tiene
en un determinado momento, el tiempo que lleva activo cada lugar, las transiciones sensibilizadas, el lugar
representativo de cada transición, el valor del timeout de una transición Time, los tiempo mínimos y
máximo de ejecución de una transición Code, etc... Además cuenta con una útil herramienta de zoom,
barras de desplazamiento y botones de configuración de la visualización para no perder detalle.
DISTRIBUCIÓN DE LA APLICACIÓN
Existen dos opciones para que los clientes puedan disponer de las aplicaciones. Típicamente una
aplicación Java contiene una serie de clases encapsuladas junto con los demás recursos necesarios en un
archivo *.jar. Si un cliente quiere usar dicha aplicación necesitará tener instalado el entorno de ejecución
Java y unos conocimientos básicos de su funcionamiento, además será necesario adquirir de nuevo el
software cada vez que aparece una nueva versión.
Sin embargo una nueva tecnología (Java Web Start) permite distribuir aplicaciones Java gráficas de
manera más eficaz. Una aplicación Java Web Start es lanzada desde un navegador Web, el usuario no se
tiene que preocupar de manejar comandos Java o estar atento a las actualizaciones porque la aplicación
que se ejecuta siempre será la última versión. Para prepararla hay que depositar el archivo *.jar en un
servidor Web (aprovecharemos el que tenemos instalado) y preparar un fichero descriptor en formato
JNLP (Java Network Launch Protocol)
Las aplicaciones gráficas, EthernetGui y AutomataGui, aprovechan esta característica y se encuentran
disponibles como un elemento más del menú en la aplicación Web creada
(http:/155.210.154.239:8080/WebCelula/jnlp/EthernetGui.jnlp y AutomataGui.jnlp ).
6.4. Aplicación Web
La especificación J2EE (Java 2 Enterprise Edition) [25] define varios servicios que permiten utilizar
Java para desarrollar aplicaciones que se ejecutan dentro de un servidor Web, y por lo tanto ser accesibles
desde cualquier computador que posea un simple navegador Web. De manera similar a RMI, HTTP
permite transferir mensajes entre diversos ordenadores repartidos en una red TCP/IP definiendo la manera
en que el cliente Web interactúa con el servidor Web en una comunicación basada en un mensaje de
solicitud y un mensaje de respuesta.
El primer paso para crear y poner en funcionamiento una aplicación Web es instalar y configurar un
servidor, se ha decidido usar Tomcat [26] por ser la implementación de referencia de la especificación
J2EE.
El siguiente paso será escribir el código de la aplicación como clases independientes (Servlets) o
incrustado dentro de los archivos HTML (páginas JSP). Ambos son perfectamente compatibles y de hecho
Carlos Mediavilla Martí
25
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
serán usados conjuntamente, típicamente los servlets implementan la lógica de negocio y las páginas JSP
la lógica de presentación o vista.
Un Servlet [27] no es más que una clase Java que implementa la interfaz HttpServlet del API Java
Servlet. Esta interfaz define un conjunto de métodos cíclicos que pueden sobreescribirse para proporcionar
respuestas dinámicas a solicitudes HTTP. El servidor de aplicación Tomcat proporciona a los servlets un
entorno en el que residir y administrar las solicitudes entrantes [ver Anexo F].
Una página JSP [28] [29] suele ser una página HTML con etiquetas especiales para añadir código
Java. La página se compila dinámicamente en un servlet (en segundo plano) y se ejecuta como tal, ver
figura 6.3. Esto hace posible escribir HTML para el diseño de la página Web (y utilizar herramientas
como Dreamweaver) y escribir la lógica de negocio (código Java) más adelante de manera independiente.
Figura 6.3 Esquema del funcionamiento básico de la aplicación Web
La funcionalidad que ofrece la aplicación Web es muy similar a la anterior, pero en este caso el interfaz
lo crea el propio navegador Web. El servidor Web es programable en Java y mediante RMI consulta los
datos del servidor RMI de la aplicación de control en tiempo real. Para el diseño [30] se han utilizado
componentes HTML, hojas de estilo, páginas JSP y applets java [ver Anexo F.5]. Para facilitar la
navegación por la aplicación, la página Web cuenta con una serie de menús que permiten acceder a las
diversas secciones de control, supervisión y gestión de la célula.
Básicamente las diferentes páginas JSP funcionan de la misma forma: la página JSP llama al servlet
responsable de adquirir o actualizar las variables de la estación correspondiente. Con la información de la
respuesta, la página JSP presenta los datos al cliente (navegador Web)
Los applets se utilizan cuando se requiere un refresco continuo de la información gráfica o las etiquetas
HTML no son suficientes para generar gráficos, por ejemplo cuando se quiere visualizar el estado de la
Red de Petri que se esta ejecutando en el computador remoto. La desventaja es que el navegador Web
Carlos Mediavilla Martí
26
20/07/06
Aplicaciones de control y supervisión
debe tener instalado el plug-in de Java. Una página que se tiene que refrescar cada cierto tiempo implica
una nueva petición HTTP al servidor, dependiendo del navegador la carga repetitiva de una página puede
tener un efecto negativo de parpadeo (aunque con Netscape el efecto es mucho menor), por ello el tiempo
de refresco se ha hecho configurable.
Algunos de los applets tienen que ser firmados ya que acceden a recursos del sistema.
Cuando un navegador Web se conecta con el servidor Web, la comunicación se produce mediante el
protocolo HTTP, pero cuando el applet de visualización en tiempo real de la ejecución de la red de Petri se
ejecuta en el navegador, la comunicación con la aplicación de control se realiza en protocolo RMI
directamente con su servidor (ver figura 6.1)
Figura 6.4 Pantalla de la aplicación Web para el control de la estación 3
La seguridad es una cuestión importante en cualquier aplicación Web, un acceso malintencionado
puede ser causa de muchos problemas. En este proyecto se ha intentado ser consciente de ello y se han
implementado unas mínimas medidas como mecanismo de seguridad que se describen a continuación:
•
Se ha configurado un acceso por contraseña: únicamente los usuarios que introduzcan el nombre
del usuario y la contraseña correcta podrán ver y modificar los datos de las páginas Web
protegidas. Este control se hace a nivel de aplicación en cada página JSP (no se utiliza el servicio
de seguridad de Tomcat) Una pantallita debajo del menú principal ofrece datos como el número de
clientes conectados y detalles sobre las conexiones.
Carlos Mediavilla Martí
27
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
•
También existe un control de acceso basado en roles. Será frecuente que muchas personas tengan
que acceder a una aplicación de este tipo, pero esta claro que no todas deberían tener los mismos
privilegios de acceso. Se han implementado 4 roles: total, control, supervisión y producción.
•
Tiempo de sesión limitado a 10 minutos.
•
Otra manera de añadir seguridad sería configurando el acceso mediante el protocolo HTTPS, Con
Tomcat se puede, pero consume muchos recursos y queda fuera de los objetivos del proyecto.
•
La aplicación esta pensada para su uso en una Intranet, si se permite a los usuarios visitar el sitio
Web mediante Internet, habría que pensar en otros elementos como un cortafuegos. Un
cortafuegos es un gateway desde Internet al servidor Web y se debería utilizar para restringir o
denegar el acceso a la aplicación Web.
Carlos Mediavilla Martí
28
20/07/06
Conclusiones
7. CONCLUSIONES
7.1. Aplicación real, prototipo laboratorio departamento IIS
Se ha conseguido desarrollar una aplicación práctica que cumple con los objetivos planteados y se
encuentra actualmente en funcionamiento: el control de una célula de fabricación flexible. Se han creado
una serie de clases Java que implementan la comunicación entre un PC y una serie de accionadores y
captadores a través del bus Interbus y Ethernet, se ha realizado la implementación de un conjunto de
clases que modelan una RdP y juntando ambas implementaciones se han creado una serie de aplicaciones
de control sobre la célula. Las aplicaciones desarrolladas permiten controlar de forma correcta y efectiva
la célula de fabricación por medio de Redes de Petri (RdP) implementadas en lenguaje Java. También
constituye una plataforma de desarrollo y ensayo para de RdP donde estudiar nuevas técnicas de control.
La arquitectura de control desarrollada es abierta y modular, esto hace que aunque se amplíe y aumente
la complejidad de la instalación (por ejemplo, añadiendo alguna estación), la actualización del conjunto no
ofrecerá complicación alguna pudiéndose adaptar a diversas aplicaciones de procesos industriales.
En lo que respecta a la realización de la aplicación distribuida, se ha comprobado que la tecnología
RMI permite distribuir aplicaciones de forma sencilla y transparente, ocultando todo el manejo de
transporte de datos.
Las aplicaciones en tiempo real son las más exigentes en lo que se refiere a sistemas de adquisición de
datos, ya que requieren que los datos en tiempo real estén disponibles allí donde se utilicen. El método de
acceso a la red utilizado por Ethernet (CSMA/CD Carrier Sense Multiple Access with Collision Detection)
nos hacía cuestionarnos si sería lo suficiente rápida y determinista para aplicaciones de control en tiempo
real. Aunque teóricamente pueda tener peor eficiencia que Interbus debido a los bytes de cabecera, se ha
comprobado experimentalmente que una red de comunicaciones Ethernet puede ser utilizada
perfectamente en aplicaciones de control, sustituyendo a los buses de campo, siendo una alternativa más
económica, flexible, fácil de instalar y de configurar.
También se pudo comprobar que la aplicación del puerto serie se comunica sin problemas con el
identificador de productos a pesar de las múltiples fuentes de ruido existentes.
Por otro lado, se ha desarrollado una aplicación que implementa el control de la célula respetando el
cumplimiento de tiempos tal como se lleva a cabo en sistemas de tiempo real. Esto ha sido posible gracias
a la máquina virtual de tiempo real Jamaica. En este sentido, en el proyecto se ha hecho una aproximación
a la especificación RTSJ que sirve para sentar las bases que serán utilizadas en futuros proyectos que
traten con la implementación de Redes de Petri con tiempo (TPNs) en Java para Tiempo Real.
7.2. Ampliaciones y mejoras
Durante el proceso de elaboración de este documento se han detectado posibilidades que se podrían
mejorar o ampliar en el futuro. Se destacan algunas de las líneas que se prevén puedan tener continuidad
por su importancia:
•
El sistema operativo Linux no es el ideal para realizar sistemas de tiempo real porque no tiene un
comportamiento determinista (prioridades fijas con desalojo) y no permite garantizar los tiempos
de respuesta (medida de tiempos y ejecución periódica) Se propone la migración a un sistema
operativo de tiempo real, como por ejemplo RT-Linux y así poder aprovechar al máximo las
especificaciones para tiempo real.
Carlos Mediavilla Martí
29
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
•
•
•
•
•
•
•
•
•
RMI puede acabar siendo insuficiente para soportar con garantías las comunicaciones en tiempo
real de sistemas distribuidos. Sin embargo RT CORBA, que extiende RMI, si implementa
características de tiempo real, por lo que podría ser una opción más interesante que sería necesario
evaluar como otra posibilidad más robusta para la implementación una aplicación distribuida en
entornos de tiempo real. Actualmente también se está trabajando en la creación de una
especificación para la versión distribuida de Java (RT-RMI o Real Time RMI).
La implementación de las clases que permiten la comunicación con los comunicadores Ethernet
han sido desarrolladas con una biblioteca perteneciente al fabricante del comunicador. Se propone
el uso de la biblioteca abierta Jamod [31] como alternativa a bibliotecas propietarias.
El control de la producción actual no guarda la información en ningún tipo de soporte cuando la
aplicación se cierra. Sería conveniente utilizar una base de datos para gestionar los pedidos.
El control de la estación 2 no es posible realizarlo a través del módulo de E/S por su complejidad.
Sin embargo, utilizando el midleware desarrollado para conectar con los autómatas si sería
posible.
Aplicación de algoritmos para la descomposición de una red de Petri de manera automática, para
implementaciones descentralizadas y distribuidas.
Jamaica ofrece una alternativa a JNI para acceder a funciones nativas. La mejora consistiría en
implementar la comunicación con Interbus usando Jamaica JBI.
Expansión del cableado de Interbus a toda la célula de fabricación, para su posterior control.
Comunicación a través de la tarjeta vía protocolo PCP y así poder extender el control sobre otros
dispositivos.
Integrar el bus CanBus en la red de comunicaciones de la célula.
7.3. Comentarios personales
Este trabajo ha sido el resultado del proyecto Fin de Carrera como estudiante del Centro Politécnico
Superior de la Universidad de Zaragoza. Para hacerse una idea de la complejidad del proyecto baste decir
que se ha tenido que diseñar y codificar una aplicación Java con más de 20.000 líneas de código, aunque
la orientación a objeto del lenguaje ha facilitado el desarrollo de la aplicación de control. También se
puede asegurar que sin la ayuda de herramientas como Eclipse [32] hubiera sido realmente arduo el
desarrollo del proyecto.
Además, la aplicación realizada en tiempo real no ha sido nada trivial, los compiladores y las máquinas
virtuales para Java de tiempo real están en sus comienzos y eso requiere de un esfuerzo extra para
conseguir que las cosas funcionen como deberían. Desgraciadamente la máquina virtual disponible
(Jamaica) no ofrece una documentación exhaustiva, haciendo que algunas partes del desarrollo en tiempo
real hayan sido muy laboriosas.
La razón de la elección de este proyecto se debió a mi interés por realizar algo útil, no el típico
proyecto teórico o un diseño que se queda en papel constituyendo un mero trámite para conseguir el título.
Por otro lado, este tema presenta gran interés y es de evidente actualidad por tratarse de tecnologías
relativamente nuevas, debido al auge que actualmente están experimentando las aplicaciones clienteservidor y por el reto que representa la realización de un trabajo de esta envergadura. Por otro lado, hubo
una especial preocupación por que los resultados obtenidos se pudieran aprovechar en futuros proyectos y
trabajos de esta índole.
Carlos Mediavilla Martí
30
20/07/06
Bibliografía
8. BIBLIOGRAFIA
[1] Oscar García Flores. “Control de la célula de fabricación mediante bus Interbus e implementación
de Redes de Petri en Java”. Junio 2005.
[2] Ramón Piedrafita Moreno, José Luis Villarroel Salcedo. “Implementación programada de Redes de
Petri en Java. Control de una célula de fabricación flexible”. I Congreso español de informática.
Simposio de Sistemas de Tiempo Real. Granada 13 al 19 de septiembre de 2005.
[3] Alberto Gran Tejero. “Implementación de sistemas de control mediante lenguaje Java y con
Tiempo Real”. Septiembre 2005
[4] Ramón Piedrafita Moreno, José Luis Villarroel Salcedo. “Redes de Petri con Tiempo.
Implementación programada en Java para Tiempo Real”. IX Jornadas de Tiempo Real. Valladolid, 9-10
de Febrero de 2006.
[5] Ramón Piedrafita Moreno. “Ingeniería de la automatización industrial”. Ra-ma Editorial, 1999.
[6] Cay S. Horstmann & Gary Cornell. “Java 2, Volumen 1. Fundamentos”. Pearson Educación, 2003.
[7] Héctor Sánchez Santamaría. “Sistemas de Tiempo Real”. Universidad de Extremadura, 2005.
http://cum.unex.es/profes/profes/sasah/STR
[8] The Real-Time for Java Expert Group. “The Real-Time specification for Java”.
https://rtsj.dev.java.net/ Sun Microsystems. Addison-Wesley, 2000.
[9] Aicas GmbH. “JamaicaVM - User Documentation”. http://www.aicas.com/jamaica.html
[10] Manuel Alberto Ricart. “Linux desmitificado”. Prentice Hall, 2003.
[11] Ann Wollrath & Jim Waldo. “The Java Tutorial. Trail: RMI”. © 2005 Sun Microsystems.
http://java.sun.com/docs/books/tutorial/rmi/index.html
[12] Bus Interbus. Interbus Club. http://www.interbusclub.com/
[13] Tarjeta CIF-50 Interbus. “Linux CIF device driver”. http://www.hilscher.com/
[14] Java Native Interface. “Java Native Interface Tutorial”. © 2003 Sun Microsystems.
http://java.sun.com/j2se/1.4.2/docs/guide/jni/index.html
[15] Protocolo ModBus. http://www.modbus.org/
Carlos Mediavilla Martí
31
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
[16] Guía de referencia del protocolo Modbus: PI_MBUS_300-RevJ-Sp0.pdf (CD adjunto)
[17] IVI-KHD2-4HRX DataSheet. http://www.pepperl-fuchs.com (CD adjunto)
[18] Manuel Silva. “Las Redes de Petri en la Informática y en la Automática”. AC, Madrid, 1985
[19] J. Bloom. Platform Independent Petri Net Editor. http://pipe2.sourceforge.net/
[20] Especificación PNML. http://www2.informatik.hu-berlin.de/top/pnml/about.html
[21] Biblioteca de comunicaciones Java. “Schneider Momentum PLCIO”.
http://www.modicon.com/PLCIO/momentum/index.htm
[22] Sun Microsystems Biblioteca Java comunicaciones serie. http://java.sun.com/products/javacomm/
[23] M.L. Liu. “Computación distribuida, fundamentos y aplicaciones”. Pearson Educación, 2004.
[24] Sun Microsystems. Interfaz gráfica Java.
http://java.sun.com/docs/books/tutorial/uiswing/index.html
[25] Java Enterprise Edition J2EE. http://java.sun.com/javaee/ © 2005 Sun Microsystems.
[26] Vivek Chopra, Amit Bakore, ... “Profesional Apache Tomcat 5”. Anaya, 2005.
[27] Jason Hunter. “Java Servlet Programming”. O'Reilly, 2001.
[28] Jayson Falker, Ben Galbraith, ... “Desarrollo web con JSP”. Anaya, 2002.
[29] Andrew Patzer. “JSP, ejemplos prácticos”. Anaya, 2002.
[30] Thomas A. Powell, “Diseño de sitios web”. McGrawHill, 2001.
[31] Biblioteca Java para ModBus. http://jamod.sourceforge.net/
[32] Entorno de desarrollo Java. http://www.eclipse.org/
[33] Página Web de la célula de fabricación. http://automata.cps.unizar.es/celula.html
Carlos Mediavilla Martí
32
20/07/06
Anexo A. La célula de fabricación
ANEXO A. LA CÉLULA DE FABRICACIÓN
La célula de fabricación, y en particular célula de fabricación de cilindros, se compone de dos módulos
principales y de una estación de unión de ambas. El módulo 1, llamado de expedición, se encarga de la
producción y verificación de cilindros, el módulo de la unión de ambas se encarga de la identificación y
clasificación así como del almacenamiento y suministro de pedidos hacia el segundo módulo, llamado de
almacenado y encargado del montaje de estos pedidos y de su almacenado final. Esto simula un proceso
de fabricación real, disponiéndose de una instalación que ayuda a todo aquel interesado en la
automatización de un proceso industrial, donde la topología física de las estaciones es la que sigue:
Zona de Expedición
Zona de Producción
Estación 3
Estación 4
Estación 5
Transporte 1
Estación 2
Transporte 2
Estación 1
Estación 7
Estación 6
Figura A.1. Disposición espacial de la célula de fabricación
Hay que tener siempre presente que se trata de una maqueta, no de máquinas reales, con lo cual se
presentarán problemas que no son los de máquinas reales, sino más propios de réplicas a pequeña escala o
juguetes.
La célula de fabricación simula un proceso productivo completo. La finalidad de todas las estaciones es
la fabricación y expedición de una determinada mercancía constituida por un conjunto de tres cilindros
neumáticos sobre una determinada base. Por lo tanto podríamos decir que la célula en conjunto constituye
una pequeña fábrica destinada a la producción y expedición de unas determinadas piezas.
A.1. Tipos de piezas
En lo referente a los diversos tipos de piezas que es posible fabricar, podemos dividirlas en dos grupos
diferentes. Por un lado están aquellas piezas que figuran ser cilindros neumáticos y por otro las que
figuran ser cilindros cerrados (también denominadas piezas con tapa). En el cuadro resumen mostrado en
la figura A.2 podemos observar la forma de cada una de las piezas.
Igualmente, tal y como podemos ver en dicha figura, dentro de un mismo tipo de piezas tenemos 3
posibilidades dependiendo del color de la camisa. Hay camisas de color negro, rojo o metálico. Por lo
tanto, existen seis tipos de piezas diferentes. El proceso de fabricación de las piezas dependerá del tipo
seleccionado.
Carlos Mediavilla Martí
33
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
COLOR DE LA CAMISA
Negra
Roja
Metálica
PIEZAS CON TAPA
PIEZAS SIN TAPA
(cilindros
neumáticos)
Figura A.2. Tipos de piezas
PIEZAS SIN TAPA
Ya se ha comentado que las piezas sin tapa simulan cilindros neumáticos de simple efecto. Así cada
una de estas estará formada por los siguientes elementos:
Figura A.3. Esquema de una pieza
•
CAMISA. Constituye la parte exterior o carcasa del cilindro neumático a fabricar. Este será el
soporte del resto de las piezas a colocar en el proceso de producción.
•
ÉMBOLO. Es el encargado de provocar el desplazamiento del eje al inyectar aire comprimido
sobre el orificio destinado a tal efecto en la camisa. El diseño de los mismos evitará que el aire se
escape a la atmósfera gracias a una junta que posee en su interior.
•
MUELLE. Dado que los cilindros neumáticos a fabricar son de simple efecto, deberemos de
provocar el retorno del émbolo a su posición de origen una vez cortado el flujo de aire
comprimido. Así la misión del muelle es la proporcionar esta fuerza de retorno del émbolo para
que éste se recoja.
•
TAPA. La camisa del cilindro neumático deberá de ser cerrada para que las piezas internas no
abandonen el interior de la camisa al inyectar aire comprimido al cilindro neumático. Esta función
se lleva a cabo por medio de la colocación de la tapa.
Carlos Mediavilla Martí
34
20/07/06
Anexo A. La célula de fabricación
Cada uno de los tres tipos de piezas a fabricar tiene unas características que las hacen diferentes entre
sí. Así tenemos diferencias en lo referente a los colores y tamaños de los elementos que las forman o
constituyen. A continuación vamos a comentar cada una de estas características de cada tipo de pieza.
El diámetro de todas las piezas es el mismo, en cambio la altura de ellas no. Debe mencionarse que las
camisas de color negro tienen una altura menor que las rojas y las metálicas. Por lo tanto en las piezas
negras deberemos de instalar unos émbolos con una longitud más corta que las otras piezas. Los émbolos
de menor longitud son de color metálico, mientras que los émbolos largos son de color negro.
Así, para poder realizar la fabricación de ambos tipos de piezas deberemos de disponer de los dos tipos
de émbolos para colocárselos a las piezas adecuadas.
En lo referente a los muelles no tenemos ningún tipo de diferencia para cada una de las piezas
fabricadas. La diferencia existente en la altura de las diferentes piezas únicamente diferirá en la
compresión del muelle dentro de cada una de las camisas.
En la figura siguiente podemos ver la relación de elementos de cada una de las piezas a fabricar.
Pieza
Negra
Roja
Metálica
Muelle
Estándar
Estándar
Estándar
Culata
Estándar
Estándar
Estándar
Camisa
Émbolo
Figura A.4. Componentes de las piezas
PIEZAS CON TAPA
El otro grupo de piezas que se pueden fabricar mediante la célula de fabricación flexible son las
denominadas “con tapa”. Estas piezas están formadas únicamente por la camisa y una tapa que no posee
orificio para la extensión del émbolo.
En estas piezas no será necesaria la colocación de los elementos mencionados en el apartado anterior,
ya que con la camisa se encuentra sólidamente colocada la tapa de la camisa y por lo tanto tenemos una
pieza compacta.
El proceso continúa posteriormente con el almacenado intermedio de las piezas para su posterior
colocación en palets de 3 piezas.
La descripción del proceso de almacenaje intermedio y expedición de pedidos no se dará aquí ya que
este proyecto sólo controlará la parte de fabricación. Puede encontrarse información sobre ella en
cualquiera de los muchos proyectos existentes dedicados a su control.
Carlos Mediavilla Martí
35
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
A.2. Zona de Fabricación
En esta zona tenemos situadas las estaciones necesarias para llevar a cabo el ensamblado de los
diferentes elementos que componen la pieza a fabricar en cada momento. Así tenemos las siguientes
estaciones1:
•
Transporte: Además de las estaciones también controlaremos el módulo que se encarga de
gestionar las cintas y enclavamientos de las estaciones. Consta de 11 entradas digitales y 11
salidas digitales. Es el encargado del traslado de las piezas de una estación a otra por medio de
una cinta sobre la que hay colocada un palet. Son accionados por motores de corriente
continua, por eso será recomendable no realizar muchos arranques y paradas para evitar caídas
de tensión en las fuentes de alimentación debido a los arranques de los motores. Hay que tener
en cuenta también que, si dos palets están pegados uno al otro el tiempo entre que el tope de la
estación al subir no golpea al palet saliente y el palet siguiente aún puede ser parado al
levantarse el palet es muy reducido. Si levantamos el tope antes de tiempo, golpeamos o
incluso evitamos que el primer palet salga. Si tardamos demasiado, el segundo palet aún no
habrá podido alcanzar la posición en que se realiza el correcto enclavamiento de la misma. Esta
segunda opción es aun más peligrosa que la primera ya que implica que la lectura y escritura
del palet ya no van a ser correctas.
Figura A.5. Un palet en el transporte
Figura A.6. Recorridos en el módulo de fabricación
1
Para mayor información se puede consultar la página Web http://automata.cps.unizar.es/celula.html
Carlos Mediavilla Martí
36
20/07/06
Anexo A. La célula de fabricación
•
Estación 1: Encargada de la colocación de la camisa deseada en el palet de la cinta
transportadora. La estación 1 es la estación de verificación de camisas. Para su control se
definen 19 variables digitales de entrada y 8 de salida.
Figura A.7. Estación 1
•
Estación 2: Por medio de esta estación podremos colocar el émbolo y el muelle en las piezas
que así lo requieran. La colocación del émbolo se realiza de forma acorde al tipo de pieza
tratada en cada momento.
Figura A.8. Estación 2
Carlos Mediavilla Martí
37
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
•
Estación 3: Esta estación coloca y rosca la tapa a las piezas que así lo requieran, es decir, en las
piezas con tapa no realiza ninguna operación. La estación 3 es la estación de montaje de las
culatas. Para su control se tienen 13 entradas digitales y 7 salidas digitales.
Figura A.9. Estación 3
•
Estación 4: La estación 4 es la de verificación final del producto. Consta de 16 entradas
digitales, 11 salidas digitales y una entrada analógica (sensor que comprueba la presión en la
inyección de aire). Antes de dar por finalizada la fabricación de una determinada pieza se
realiza un test para comprobar que la pieza ha sido fabricada correctamente. Esta estación se
encarga de tal función desechando las que son defectuosas y permitiendo el resto de proceso
para las piezas fabricadas correctamente.
Figura A.10. Estación 4
Carlos Mediavilla Martí
38
20/07/06
Anexo A. La célula de fabricación
A.3. Identificador de productos
Como ya se ha comentado el módulo de fabricación de la célula de fabricación consta de cuatro
estaciones por las que va pasando un palet con la pieza producida hasta que se produce su salida al
almacén intermedio. Pero para el control global del proceso de producción es necesario saber que tipo de
pieza se va a realizar y cual es exactamente el contenido de cada palet. Es por esto que la célula dispone de
un identificador de productos modelo IVI-KHD2-4HRX, como el de la figura A.11.
Figura A.11. Identificador de productos
Este identificador permite la colocación de hasta cuatro cabezales de lectura/escritura, que se colocan
en cada estación. Según el proceso realizado en cada una de ellas se escribirá una determinada
información en el disco magnético situado en la parte inferior del palet que podrá ser utilizada por las
siguientes estaciones cuando el palet llegue a ellas para actuar de forma coherente con el contenido del
mismo.
Figura A.12. Cabezal de lectura/escritura
El identificador de productos IVI se utiliza para leer y escribir en los cabezales magnéticos de los
palets de la célula. Para controlar el identificador de productos existen varias posibilidades, Ethernet,
Interbus y puerto serie. Dado que este identificador aún no está conectado a la red Interbus del laboratorio
la opción más factible en este proyecto es su control directo a través del puerto serie mediante protocolo
RS232.
Carlos Mediavilla Martí
39
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
El estándar de comunicación serie asíncrona RS-232 que se utiliza para comunicar el identificador de
productos con el computador de control, se ha utilizado ampliamente en la industria aunque en la
actualidad se emplea para transductores industriales. El identificador cuenta con un conector sub-D de 9
pines. Las interferencias limitan la longitud máxima a unos 15 metros y una velocidad de transmisión de
hasta 115Kb. Siguiendo la descripción formal de la norma, el identificador es un DCE (Equipo de
comunicaciones de datos)
Protocolo de comunicaciones
Para la comunicación entre el PC y el identificador de productos se deberá usar un protocolo definido
en el manual de usuario del identificador de productos. El IVI-KHD2-4HRX permite la conexión directa
mediante protocolo RS232 a través de un cable de conexión de 9 pines. Dado que la lectura y escritura de
palets va a ser un proceso que se realizará pocas veces en comparación con la lectura o escritura de
entradas o salidas de las estaciones seleccionamos el modo de funcionamiento más sencillo: el basic
read/write operating mode. En este modo se pueden enviar órdenes al identificador de dos tipos:
o
Lectura/escritura.
o
Comandos del sistema.
Todas las órdenes (escritura, lectura y borrado) que se le envían al identificador deben tener una
estructura de datos fija: por ejemplo, para escribir un número de bytes en un cabezal determinado, la
instrucción a enviar sería:
Comando
Cabezal
Inicio
Longitud
Datos
Checksum
ETX
El primer byte (en formato ASCII) representa la instrucción, puede ser una de las siguientes:
LEER = 0x77; // w
ESCRIBIR = 0x6B; // k
LEERSIMPLE = 0x61; // a
TESTMEMORIA = 0x63; // c
QUIT = 0x71; // q
RESTART = 0x6F; // o
SETDATACARRIER = 0x69;
El siguiente byte es el número de la cabeza de lectura/escritura. Los dos posteriores indican la
dirección de inicio y el tamaño de los datos. Los siguientes son los datos que hay que pasarles, siendo el
número de estos, dependiente de la instrucción que se le pase. Después se calcula el checksum de todos los
valores y se añade el símbolo de fin de trama ETX. El checksum es la suma de todos los valores de la
trama menos el fin de trama y se usa como comprobación de la corrección de la misma.
Mención aparte merece el cálculo del checksum. Se calcula como la suma de todos los bytes de la
Carlos Mediavilla Martí
40
20/07/06
Anexo A. La célula de fabricación
trama excepto el carácter de fin de trama ETX. Si el valor final de esta suma es mayor de tres dígitos se
trunca el más significativo, según se puede ver en la siguiente figura:
Figura A.13. Protocolo puerto serie: cálculo del checksum
La trama que aparece a continuación es la respuesta que debemos recibir del identificador.
Comando
Estado
Carlos Mediavilla Martí
DB Checksum
ETX
41
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
ANEXO B. BUS DE CAMPO INTERBUS
B.1. Características básicas
Interbus es una red de sensores/accionadotes distribuidos para sistemas de fabricación y control de
procesos continuos. Es un sistema abierto de altas prestaciones con topología en anillo.
El concepto básico de un bus abierto es permitir un intercambio de informaciones entre dispositivos
producidos por diferentes fabricantes. Las informaciones intercambiadas comprenden datos de proceso
(entradas / salidas) y parámetros (datos de configuración, programas, datos de monitorización). El formato
de las informaciones está definido mediante un perfil estándar por el cual operan los dispositivos. En
Interbus se dispone de perfiles estándar para servomotores, encoders, controladores de robot,
controladores de posición, paneles de control y operación, entradas / salidas digitales, entradas / salidas
analógicas, termopares, contadores, variadores de frecuencia, robots, controles de soldadura, sistemas de
identificación, etc. El protocolo INTERBUS, DIN 19258, es el estándar de comunicación para estos
perfiles. Es un estándar abierto para redes de E-S en aplicaciones industriales.
Interbus no está respaldado por los grandes fabricantes de autómatas. Sin embargo, alrededor de 700
desarrolladores de dispositivos de campo lo soportan. Sacando al mercado continuamente nuevos
desarrollos técnicos y productos. En la actualidad hay instalados mas de 1’5 millones de dispositivos de
campo.
Un sistema basado en Interbus está compuesto por una tarjeta de control, instalada en un PC industrial
o en un autómata programable, que comunica con un conjunto de dispositivos distribuidos de entrada /
salida. El protocolo de transmisión de datos es de alta eficiencia con el objetivo de cumplir los
requerimientos de alta velocidad de transmisión en los sistemas de control.
La comunicación entre los dispositivos se realiza mediante el protocolo Interbus, el cual está reflejado
en la norma DIN 19258. En Alemania, siguiendo los deseos de los usuarios, las funciones clave de
Interbus están estandarizadas por la DKE (Deutsche Elektrrotechnische Kommission: German
Elechtrotechnical Comision for DIN and VDE). En 1993 se publica la norma DIN E 19 258. Esta norma
fija los protocolos de transmisión y los servicios necesarios para la transmisión de datos. Las
especificaciones de los parámetros de comunicación fueron publicadas en el DIN Report 46 en el año
1995. Todas estas normas fueron homologadas en el ámbito europeo en 1997 en la norma EN 50 254 con
el título “High Efficiency Communication Subsystem for Small Data Packages”.
Interbus utiliza el método de comunicación maestro-esclavo, donde el maestro de bus del bus
simultáneamente funciona como conexión o interfaz con el bus de nivel superior. El Protocolo Interbus
utiliza la tecnología de trama suma: Un único telegrama actualiza simultáneamente todas las entradas y
todas las salidas de los dispositivos físicos conectados al bus. Los niveles del modelo OSI que están
implementados son: 1 (Físico), 2 (Enlace), y 7 (Aplicación).
B.2. Topología
La topología adoptada de Interbus es el anillo. Todos los dispositivos están conectados en un sistema
de comunicación en bucle cerrado. Desde los dispositivos conectados al anillo principal, liderado por el
maestro, se pueden conectar subanillos que estructuran el sistema completo. Las conexiones entre los
anillos se realizan mediante módulos especiales denominados terminales de bus.
Carlos Mediavilla Martí
42
20/07/06
Anexo B. Bus de campo Interbus
Un detalle que distingue Interbus de otros sistemas en anillo es que ambas líneas, la línea de envío y la
línea de retorno de datos, pertenecen al mismo cable que pasa a través de todos los dispositivos físicos
conectados al bus. Esto conlleva que tenga la misma apariencia física que una estructura en forma de
árbol. El nivel físico de Interbus está basado en el estándar RS 485. La interfaz RS 485 utiliza el método
de transmisión por voltaje diferencial sobre un par trenzado. Debido a la estructura en anillo y a la
necesidad de llevar la masa lógica a todos los dispositivos, Interbus requiere la conexión de cinco hilos de
señal en el cable que conecta dos dispositivos. La transmisión de datos se puede realizar a una velocidad
de 500 KBits a una distancia máxima de 400 m. entre los dispositivos. Como cada dispositivo actúa como
repetidor de señal permite que Interbus alcance una distancia superior a los 13 Km. El máximo número de
dispositivos conectados al bus es de 512, con un máximo de 4096 puntos de entrada / salida.
Figura B.1. Topología de red del bus Interbus
La estructura punto a punto de comunicación de Interbus y su división en anillo principal y subanillos
se adecua perfectamente a la incorporación de diferentes y modernos sistemas de transmisión como la
fibra óptica. El sistema de transmisión se puede convertir en fibra óptica, o en sistemas de transmisión por
infrarrojos, o bien a otros sistemas utilizando convertidores estándar disponibles en el mercado. La
utilización por medio de fibra óptica supone que la transmisión de datos está libre de interferencias.
La estructura en forma de anillo añade al sistema dos ventajas fundamentales. Primero, en contraste
con las redes en línea, el anillo permite el envío y la recepción de datos simultánea. Segundo, la función de
autodiagnóstico del bus se ve mejorada con la estructura de anillo. Si se produce un cortocircuito en el bus
de comunicación, al disponer de una estructura en anillo es posible la localización del fallo dado que la
comunicación sólo se interrumpe en un segmento de bus, lo cual no sucede en una estructura en línea.
Interbus incorpora el diagnóstico centralizado o descentralizado de los dispositivos del bus, el
diagnóstico se puede realizar por medio de funciones o por registros de datos. El bus efectúa el
reconocimiento automático de los dispositivos participantes y del perfil asociado a ellos. En caso de fallo
se produce la desconexión automática del dispositivo donde se localiza el fallo, y se permite el cambio de
dispositivos y de la topología del bus online.
Carlos Mediavilla Martí
43
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Figura B.2. Módulo de entradas-salidas Interbus
B.3. Interfaz de usuario
El protocolo y la topología característica de Interbus aseguran la integración del transporte cíclico de
los datos de entrada / salida y de los mensajes no cíclicos en un solo sistema, donde se tienen en cuenta y
se colman las demandas y las necesidades del campo de los sensores y accionadotes industriales. Éstos son
los prerrequisitos necesarios para realizar una red de transmisión uniforme en este campo.
También deberá estar garantizado para el usuario un fácil acceso a los datos del bus. En definitiva los
datos del proceso deben ser fácilmente accesibles para la aplicación de control en autómata o PC
Industrial. Una tarea cíclica en el maestro del bus actualiza continuamente los datos de entrada / salida y
los suministra al sistema de control en forma de una memoria de imágenes de entrada / salida.
El tiempo de transmisión se puede calcular con la siguiente fórmula dada por el fabricante:
Tciclo = [13*(6+n) + 2*m]*Tbit + Tsw + Tph
n = Número de Bytes utilizados.
m = Número de esclavos instalados.
Tbit = Tiempo de transmisión de un bit. 2 microseg a 500 Kbits/seg
Tsw = Tiempo del Firmware 0.2 mseg
Tph = Tiempo de transmisión en el medio. 0,006*L (longitud del cable en Km)
Tciclo = [13*(6+36) + 2*30]*0.000002 + 0.0002 + 0.006*0.025 = 1.6ms
Los datos de proceso pueden ser utilizados en un programa de autómata de forma idéntica a las
entradas / salidas digitales clásicas.
En el caso de programación de aplicaciones de control en plataforma PC, los datos de proceso son
accesibles por medio de interfaces de software estándar (DDE, OPC, Open Control)
Cuando se accede a los datos de proceso, el usuario no nota ninguna diferencia entre los datos
accedidos vía serie (bus de campo), o los datos de proceso provenientes de un cableado tradicional. El
usuario del bus no tiene que estar familiarizado con las complejas formas de comunicación del bus. Se
han desarrollado tarjetas maestras de Interbus para autómatas Siemens, Telemecanique, Allen-Bradley,
Hitachi, ABB, Bosch, etc.
Carlos Mediavilla Martí
44
20/07/06
Anexo B. Bus de campo Interbus
Entre las herramientas de programación disponibles cabe citar el software CMD, que permite la
configuración, monitorización y diagnóstico del bus y el software PCWORX que permite programar
aplicaciones de control en plataforma PC conforme a la norma UEC 1131. Además existen drivers para
Visual Basic, C++ y Delphy.
B.4. Resumen de las capacidades de Interbus
INTERBUS, es un bus en anillo interno que permite:
•
Tratamiento paralelo de la información (diseñado para sensores / actuadores)
•
Tiempo de scan determinado (fijo, corto, calculable)
•
Desconexión automática de utillajes (Ej.: robots)
•
No requiere ajustes de velocidad, direccionamiento de módulo ni atender a las resistencias de
cierre.
•
Preprocesado de señales.
•
Abierto a diferentes CPU’s de distintos fabricantes
•
Alta eficiencia de la transmisión.
•
Diagnóstico potente de identificación de fallos y su localización:
o
o
o
en módulos.
en cableados y conexiones.
en periferia.
•
Más alta gama de productos y fabricantes del mundo
•
Normalizado a nivel mundial (IEC 61158)
Interbus es una aproximación de sistemas abiertos a una red de dispositivos distribuidos, basada en
anillo de alto rendimiento para fabricación y procesos de control. Interbus es un protocolo altamente
eficiente para los requerimientos de control de alta velocidad actuales. Un sistema Interbus consiste en una
placa controladora instalada en una computadora (PC, VME, etc...) o autómata programable que se
comunica con una variedad de dispositivos de entrada-salida. Interbus es operativo con la mayoría de
paquetes estándar de software y sistemas operativos. Interbus es permitido por más de 300 fabricantes de
dispositivos de todo el mundo.
El protocolo de Interbus proporciona el alto rendimiento demandado por los requerimientos de entradasalida de red actuales. Los datos de E-S se transmiten en marcos que proporcionan actualizaciones
simultáneas y predecibles de todos los dispositivos de la red. Las transmisiones seguras son aseguradas
mediante la capacidad de comprobación de errores del protocolo CRC. Además, el diagnostico exhaustivo
permite localizar las causas y lugares de los errores. Esto proporciona un mayor tiempo de funcionamiento
de la red. El protocolo de mensajería incorporado permite enviar parámetros complejos y mensajes de
datos a lo largo de la red Interbus.
El concepto básico de un sistema de bus abierto es permitir un intercambio similar de información
Carlos Mediavilla Martí
45
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
entre dispositivos producidos por diferentes fabricantes. La información incluye comandos y datos de E-S
que han sido definidos como un perfil estándar por el cual operan los dispositivos. Los perfiles estándar
están disponibles para drivers, encoders, controladores robóticos, válvulas neumáticas, etc. El protocolo
Interbus, DIN 19258, es el estándar de comunicación para estos perfiles. Es un estándar abierto para redes
de E-S en aplicaciones industriales.
La red Interbus (IBS) proporciona un enlace serie capaz de transmitir datos de E-S con velocidades en
tiempo real. Tiempo real significa aquí que los datos de E-S son actualizados muchas veces más rápido de
lo que la aplicación puede resolver la lógica.
B.5. La tarjeta controladora de Interbus CIF50-IBM.
Como hemos dicho, este proyecto se lleva a cabo en un Sistema Operativo Linux. En principio para
controlar el bus se pensó en una tarjeta controladora de Interbus PCI ISA SC/I-T de Phoenix Contact, sin
embargo estas tarjetas solo están diseñadas para controlar Interbus dentro de Sistemas Operativos
Windows. Después de conocer esto y buscar una tarjeta que se amoldara a nuestras necesidades de control
dentro de Linux, se encontró la tarjeta controladora de Interbus CIF50 de Hilscher. La familia de la
tarjetas para PC CIF de Hilscher son todas compatibles con las demás de la familia y usan la common API
(application interface) y software configuration utility (SYCON) los cuales están incluidos con las
tarjetas. Un CD con SYCON, Windows 95/98/2000/NT/XP y los drivers para el OPC y una
documentación completa y ejemplos que son incluidos con la tarjeta en el CD que la acompaña. La tarjeta
PCI tiene un tamaño de 134x107x20mm (CIF50), con una temperatura de operación de entre 0-50º C,
inmunidad a EN50082-2, RS232C, puerto de diagnostico no protegido. Con un voltaje de operación de 5V
/ max. 500mA - 650mA. +12V / max. 50mA, -12V / max. 50mA. Dispone de unos parámetros para el bus
Interbus de Interbus Master 128 Slaves, 1024 Byte I/O Data, PCP Channel, InterBus Loop, Generation 4.
Figura B.3. Esquema de la tarjeta Interbus
Carlos Mediavilla Martí
46
20/07/06
Anexo B. Bus de campo Interbus
Como se puede ver en la figura B.3., la tarjeta dispone de dos puertos de 9 pines. El puerto de Interbus
Interface que se conecta directamente a la estructura de anillo Interbus, en nuestro caso para ser exactos a
la estación 1. El puerto de Diagnostic Interface que como mas adelante se comentará con más detalle de
funcionamiento, se conectará con el puerto serie COM de un PC Windows. Los cuatro indicadores
luminosos de la zona inferior de la imagen que corresponden a las indicaciones de funcionamiento de la
tarjeta, Ready, Run, Error, Stand.
Figura B.4. Tarjeta Interbus CIF-50 Hilscher
Esta tarjeta realiza la comunicación mediante el manejo de la información entre la red Interbus
conectada y el PC. La información esta disponible como imagen de proceso dentro de la memoria del de la
tarjeta CIF (dual-port). El intercambio de datos es manejado por medio del mailbox dentro de la memoria
dual-port. En nuestro caso, el acceso a esta información, ya sea la imagen de proceso o la mailbox, se
realizará mediante el CIF Device Driver. Si se usa Linux como sistema operativo, las funciones necesarias
para crear un programa están documentadas en el Device Driver Manual (Linux CIF Device Driver).
Antes de crear la aplicación para comunicarse con la red Interbus conectada a la tarjeta, será necesario
llevar a cabo la configuración de la red Interbus en la tarjeta, tarea que será realizada por el Software
SYCON que va dentro del CD que acompaña a la tarjeta tal como indica a continuación.
B.6. Configuración de la tarjeta mediante SyCon.
Las siglas SyCon provienen de System Configurator que en base es lo que nosotros queremos hacer,
configuración y puesta a punto de la tarjeta de modo que la estructura de la red Interbus quede almacenada
en ésta. SyCon es un software que permite una configuración interactiva e independiente, la operación y el
diagnóstico de todos los dispositivos conectados a la red Interbus. El manual de la instalación esta
disponible en el documento ib_cd.pdf pag 25. La configuración del bus puede realizarse de forma manual,
añadiendo los componentes que se sabe que están conectados en la red, o bien permitiendo al software que
autoconfigure el bus leyendo los componentes que se encuentran disponibles.
El único problema de este software es que solamente puede ser instalado en sistemas operativos
Windows. Como el sistema con el que trabajamos es Linux tuvimos que adaptarnos a la situación y adoptar
la solución de instalar el software SyCon en Windows y vía puerto serie conectarnos con el puerto diag.
(Diagnostic Interface) de la tarjeta controladora CIF-50 tal como se ve en la configuración física del
cableado, ver figura B.3.
Existen dos formas de configurar la estructura de la red Interbus: la configuración manual, con la que
debemos conocer de antemano los módulos que contiene cada estación y la configuración automática, en
la que es el propio software el que lee los componentes que están conectados al bus. Dado que en nuestro
caso la conexión a la célula no presenta ningún problema se ha optado por esta segunda solución, siendo
siempre la más recomendable excepto en el caso de que sea imposible físicamente la conexión del
Carlos Mediavilla Martí
47
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
ordenador con el sistema a controlar. La operación se llevó a cabo con el PC Windows conectado vía
puerto serie a la tarjeta controladora vía puerto de diagnostico de la tarjeta, estando esta conectada al anillo
Interbus. Dicha auto configuración generó la estructura actual de la red Interbus del laboratorio tal como
se ve a continuación.
Figura B.5. Configuración de la tarjeta con el software Sycon
Si nos fijamos en cada uno de los módulos podemos observar la disposición de cada una de las
estaciones en nuestra distribución de anillo. Siendo el primer modulo “Master” el correspondiente a
nuestra tarjeta controladora, y los siguientes correspondientes a las estaciones 1 y 4 respectivamente.
A continuación se muestra la parametrización de cada una de las estaciones.
Estación 1:
La estación 1 es la estación de verificación de camisas. Para su control se definen 19 variables digitales
de entrada y 8 de salida. La configuración del bus es la que se muestra en la figura B.5, y se compone de
una cabecera de bus, un módulo de 8 entradas digitales, seguido de 8 módulos de salidas digitales, y 2
módulos más de 8 entradas digitales, por lo que van a usarse todos los módulos de salidas y van a quedar
libres 5 entradas digitales del último módulo.
Carlos Mediavilla Martí
48
20/07/06
Anexo B. Bus de campo Interbus
Estación 3: (cuando esta conectado a Interbus)
La estación 3 es la estación de montaje de las culatas. Para su control se tienen 13 entradas digitales y 7
salidas digitales. Para el control mediante Interbus de la estación 3 se dispone de un módulo Momentum de
16 entradas y salidas digitales, que también incluye una cabecera de bus. Este módulo ofrece un ahorro de
espacio respecto a los módulos individuales pero pierde en cuanto a facilidad de mantenimiento, ya que en
caso de error es más fácil sustituir el módulo defectuoso. El formato en que aparece el dispositivo es
diferente de los que aparecen en la figura de la estación 1. A efectos prácticos esto no influye sobre el
fichero de configuración producido.
Estación 4:
La estación 4 es la de verificación final del producto. Consta de 16 entradas digitales, 11 salidas
digitales y una entrada analógica. Al igual que la estación 1 esta estación está formada por módulos
independientes, en este caso una cabecera de bus, un módulo de 8 entradas digitales, 8 módulos de salidas
digitales, seguidos de otro módulo de 8 entradas y otros 5 módulos de salidas, para finalizar con un
módulo de entrada-salida analógico.
Transporte: (cuando esta conectado a Interbus)
Además de las estaciones también se puede controlar el módulo que se encarga de gestionar las cintas y
enclavamientos de las estaciones. Consta de 11 entradas digitales y 11 salidas digitales. Para su control, al
igual que para el de la estación 3, se dispone de un módulo Momentum de 16 entradas y salidas digitales.
B.7. Librerías para la comunicación con Interbus.
A diferencia de un proyecto anterior, en este proyecto no se ha podido aprovechar un software como el
CMD para crear unas librerías en lenguaje de programación que realicen la comunicación con cada una de
las entradas y salidas. Por ello, a diferencia del proyecto anterior, el control del bus Interbus se puede
realizar de modo mas profundo ya que se pueden tratar los posibles errores que surjan a la hora de tratar
las entradas y salidas pudiendo localizar los errores en estos ámbitos de forma más fácil para su posterior
depuración.
Como ya se ha visto en la sección anterior, la configuración de la tarjeta controladora del bus Interbus
se ha realizado a través de otro PC con sistema operativo Windows conectado a la tarjeta CIF-50 instalada
en el PC Linux, ya que el software SyCon no es soportado por el sistema operativo Linux. A partir de aquí
y con la tarjeta configurada para esta disposición, se necesitaba crear un programa que nos permitiera
comunicarnos con cada una de las entradas y las salidas de la red Interbus. Para llevar a cabo la
comunicación se eligió el lenguaje C, ya que es el utilizado en la biblioteca del fabricante para llevar a
cabo la comunicación, suministrando una serie de funciones. Al manual correspondiente se puede acceder
desde la sección de bibliografía.
Con esto veremos que pautas se han tenido en cuenta a la hora de realizar estas librerías. Su
programación se ha llevado a cabo teniendo en cuenta la arquitectura de programación posterior realizada
en Java, la cual lleva a cabo toda la lógica de las redes de Petri, de modo que el código C que se ha
programado consiste en una simple activación – desactivación de salidas y en una lectura de entradas.
Teniendo en cuenta el hecho de que la arquitectura creada por el software SyCon a partir de la
estructura del bus Interbus se cargó en la tarjeta controladora CIF-50. Esta configuración de las entradassalidas esta almacenada en la tarjeta controladora de modo que para acceder al bus Interbus es necesario
utilizar las funciones dadas por el fabricante. Con esto hay que decir que para una configuración de
Interbus diferente a la que se ha utilizado en este proyecto, el orden dentro de la función que hace el
intercambio de información “DevExchangeIO” con el bus Interbus cambiaría. Para ser exactos cambiaría
Carlos Mediavilla Martí
49
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
tanto la estructura del vector tIOSendData para las salidas y tIORecvData para las entradas, los cuales son
enviados como parámetro a la función. Si la configuración Interbus fuera modificada, la aplicación creada
podría ser aprovechada cambiando las variables de entrada y salida del bus Interbus.
Para comunicarnos, la estructura de cada vector (Send - Recv) se divide en módulos que son las
diferentes salidas - entradas de las diferentes estaciones respectivamente. Como se puede ver para una
estructura de la red Interbus, los vectores se establecen tal como esta comentado en el código C
(codicoCom2.c). Vemos por ejemplo que en la estación 3 no existe cableado en el segundo octeto de
salidas, lo cual se puede ver físicamente en la propia estación 3 la no existencia de cableado en el modulo
de salidas. Para el primer octeto de salidas de la estación 3 tal como esta comentado se ve que para un
valor de 2 dentro del vector de tIOSendData[1] equivale a un ‘cinta retrocede’ dentro de la estación.
Cualquiera que se fije en estos valores podrá darse cuenta que siguen una pauta binaria 2 elevado a 0, 2
elevado a 1, 2 elevado a 2, 2 elevado a 3..., siendo para 8 (módulos de 8 salidas digitales) el máximo de
cada módulo, 2 elevado a 7 que equivale al entero 128. Con ello se puede decir que la cadena (0000 1000)
corresponde con el ‘pinza_sube’ de la estación 3, observando que también corresponde con la posición
física de la salida dentro del primer modulo de salidas ‘pinza_sube’. Con esto se ve la correspondencia que
existe a la hora de enviar los datos al bus Interbus desde la aplicación en el cual se le ha dado valores
enteros para facilitar la programación, pero hay que tener en cuenta lo que realmente se envía, que es una
cadena cuya posición corresponde con la salida a escribir físicamente, lo cual en posteriores
modificaciones ayudará a entender la filosofía utilizada en la aplicación y la de la propia comunicación
con el bus Interbus.
Este es el único programa que se utiliza para comunicarse con el bus Interbus. En un principio para
realizar la comunicación con la tarjeta y posteriormente con el bus Interbus es necesario una apertura del
driver mediante la función DevOpenDriver(), cuya operación en el programa esta recogida dentro de la
función short AperturaDriver(); posteriormente es necesario realizar una inicialización de la tarjeta
mediante la función DevInitBoard(numeroTarjeta), la cual inicia la tarjeta estando esta función en el
programa dentro de InicializaTargeta(), cabe señalar que tal como esta instalada la tarjeta controladora
dentro del PC ocupa la posición 0, situación que debería ser modificada en caso de existir algún problema
a la hora de comunicarse con la tarjeta desde esta misma función.
Posteriormente esta la declaración de los vectores de entradas y salidas que son utilizados por la
función DevExchangeIO, y la función de inicialización del las salidas. Tras esto esta el vector de escritura
de salidas, en los cuales solo hay que señalar que consisten en la escritura dentro del vector tIOSendData
que corresponde a las salidas en la actualización de la variable dependiendo del parámetro booleano que le
haya sido pasado a la función, también cabe señalar que tanto el vector de entradas como el de salidas
tienen que tener lo que se podría llamar memoria del proceso de modo que a la hora de activar una salida
opuesta a la que esta activada hay que realizar una resta sobre la posición correspondiente dentro del
vector de salidas. Sea el ejemplo de pinza ‘sube-baja’ de la estación 3 donde se activa con el valor entero
8, para llevar a cabo una desactivación de esta salida es necesario realizar una resta de 8 sobre la posición,
en este caso 2, del vector tIOSendData: tIOSendData[2] = tIOSendData[2] – 8;. De aquí la decisión
anterior, con el objetivo de facilitar la comprensión de esta operación, de coger valores enteros a la hora de
especificar cada una de las salidas y por extensión de las entradas. Para todas las funciones de escritura se
ha realizado la misma estructura, a diferencia de que no se escribe y solo se lee, pero de forma que hay
que desfraccionar el resultado de la lectura ya que en la mayoría de los casos no tendremos solo una
entrada activada sino más, por lo cual el resultado de la lectura normalmente deberá dividirse en mas de
una entrada activada, determinación que se lleva a cabo en la operación estaActivadaLaEntrada(char
entradasActivas, char entradaAEstudiar).
Para cada una de las salidas del bus Interbus se podría crear una función que active o desactive cada
una de las salidas individualmente. Al igual que para las salidas, también se podrían crear otras funciones
para leer todas las entradas del Interbus. Hay que tener en cuenta que en una aplicación Java, tras finalizar
la llamada a un método nativo y devolver el control a Java, se destruyen los datos creados en ese
programa, así que no es posible una actuación individual sobre cada una de las entradas y salidas del bus
Carlos Mediavilla Martí
50
20/07/06
Anexo B. Bus de campo Interbus
Interbus. La configuración de la estructura del bus Interbus queda almacenada en la tarjeta y permite
acceder a ella a través de un vector de ‘unsigned char’ tanto a sus entradas como a sus salidas, y es ahí
donde esta el problema, ya que ese vector de salidas principalmente contiene toda la información de las
salidas, el cual se destruye tras devolver el control a Java. Se podría pensar que con solo realizar la
modificación de la salida a activar es suficiente, ya que así no se enviaría un vector incorrecto o mas bien
desconocido a la tarjeta, pero hay que tener en cuenta tal como esta especificado, que hay módulos dentro
de este vector que se envía a la tarjeta, que se componen de 8 salidas digitales a las cuales hay que
enviarles un valor y que este valor en una posterior llamada no será tenido en cuenta, por ello se optó por
la solución de crear una generación total del estado del bus Interbus desde Java, es decir será el programa
Java quien tenga conocimiento de los estados de las salidas - entradas del bus Interbus y no el programa
escrito en lenguaje C y quien se encargue de enviar toda esta trama al programa escrito en C, ver Anexo
E.5.
Carlos Mediavilla Martí
51
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
ANEXO C. DISPOSITIVOS ETHERNET
C.1. Comunicadores Ethernet. Módulos Momentum E/S
Algunos de los módulos de entradas / salidas distribuidas que hay en la célula de fabricación son
módulos TSX Momentun de Schneider Electric de 16 entradas/salidas digitales y 2 entradas/salidas
analógicas, estos pueden llevar un comunicador Ethernet (170ENT11000) que permita su acceso a través
de redes TCP/IP. A continuación se describe de manera más general este tipo de módulos de entradasalida.
El sistema Modicon TSX Momentum incluye 4 componentes fundamentales que se conectan
fácilmente entre sí en diversas combinaciones para crear sistemas o subsistemas de control versátiles. Los
4 elementos fácilmente adaptables son:
• Bases de E/S.
• Adaptadores de comunicación.
• Adaptadores procesador.
• Adaptadores opcionales.
Bases de E/S:
Las bases de E/S Modicon TSX Momentum soportan el resto del sistema de control (adaptadores de
comunicación, procesadores y adaptadores opcionales) que se conectan a la base de E/S. Una amplia gama
de bases de E/S disponible, incluyendo E/S analógicas, E/S discretas en tensiones de 24 VCC, 110 VAC y
220 VAC, bases con salidas a relé, bases de E/S combinadas, bases con funciones específicas (contaje,
control de motores paso a paso), etc. E/S Modicon TSX Momentum disponen además de borneras de fácil
conexión pudiendo ser usadas como borneras frontera. El montaje puede ser sobre riel DIN estándar de 35
mm o bien a tornillo sobre la bandeja del tablero. Este módulo ofrece un ahorro de espacio respecto a los
módulos individuales y en cuanto a facilidad de mantenimiento, ya que en caso de error es más fácil
sustituir el módulo defectuoso.
Figura C.1. Módulo de entradas-salidas TSX Momentum
Carlos Mediavilla Martí
52
20/07/06
Anexo C. Dispositivos Ethernet
Adaptadores de Comunicación:
Modicon TSX Momentum está diseñado para independizar las comunicaciones de la base de E/S,
creando un sistema de E/S realmente abierto que se puede adaptar a cualquier bus de campo. Al montar
sobre la base de E/S Modicon TSX Momentum un adaptador de comunicación, obtenemos una base remota
de E/S que se conecta directamente con cualquier bus de campo y respondiendo al administrador de la red.
Las E/S Modicon TSX Momentum pueden ser utilizadas en distintos tipos de arquitecturas; sistemas de
control centralizados, distribuidos, controles basados en PC, como complemento para controladores
programables de diferentes proveedores y como complemento de otros procesadores Modicon TSX
Momentum.
Procesadores:
Cuando se necesita una inteligencia local distribuida en el punto de control, Modicon TSX Momentum
es la respuesta adecuada. Los adaptadores procesadores Modicon TSX Momentum M1 equipados con CPU,
RAM y memoria Flash, son compatibles con los PLC Quantum, Compact y 984 de Modicon y se conectan
en las bases de E/S Modicon TSX Momentum igual que los adaptadores de comunicación.
Adaptadores opcionales:
El adaptador opcional va acompañado siempre de un adaptador procesador y le proporciona nuevas
capacidades de red, reloj calendario y batería de seguridad para la memoria de datos. El adaptador
opcional también se conecta a la base de E/S, en la parte superior.
Adaptadores y Procesadores con puerto Ethernet:
La familia TSX Momentum se integra a la plataforma Transparent Factory a través de los adaptadores
de comunicación Ethernet y los procesadores (CPUs) con puerto de comunicación Ethernet y páginas
WEB embebidas (incorporadas)
Adaptadores de comunicación Ethernet:
Los adaptadores de comunicación 170 ENT 110 00 y 170 ENT 110 01 permiten la conexión a la red
Ethernet de la familia completa de bases de entradas y salidas TSX Momentum. Esta conectividad
posibilita la comunicación con todos los dispositivos de control compatibles con Ethernet TCP/IP (PLCs,
controles de movimiento, PCs industriales, etc) lo que convierte a la familia TSX Momentum en un
poderoso sistema de entradas/salidas distribuidas dialogando en un protocolo universal y abierto (servicio
I/0 Scanning).
El sistema de direccionamiento IP permite un número ilimitado de bases de E/S TSX Momentum
conectadas a la red. Utilizando hubs, routers, bridges, switches, el rendimiento y longitud de la red
Ethernet puede ser adecuadamente ajustada a las necesidades de casi cualquier aplicación de control.
El adaptador de comunicación Ethernet utiliza la estructura estandarizada de mensajes y comandos de
control de Modbus sobre el protocolo TCP/IP, lo cual simplifica la implementaci6n de control y al mismo
tiempo posibilita que la información pueda estar disponible en una red estandarizada y mundialmente
aceptada como Ethernet.
Carlos Mediavilla Martí
53
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Los adaptadores de comunicación Ethernet modelo 170 ENT 110 0x cuentan con:
•
•
•
Conector RJ 45 normalizado para la conexión a la red 10base T ó 100base TX según el
modelo.
Espacio para etiqueta.
LEDs indicadores del estado comunicador.
Procesadores M1E:
Los procesadores M1E ofrecen control en tiempo real y acceso abierto a la información a través de su
puerto de comunicación Ethernet, acorde a la filosofía de la plataforma Transparent Factory. Sus
principales beneficios son:
•
•
•
Conectividad a Ethernet con el protocolo Modbus TC/IP (Velocidad 10 Mbps)
Control de Entradas/Salidas remotas de alto rendimiento sobre Ethernet (I/O Scanning) que
permite implementar sistemas distribuidos.
Páginas WEB embebidas (incorporadas con memoria FLASH de 128 K bytes) que permiten
acceder desde un explorador de Internet (browser) a las siguientes herramientas:
o Pantallas de estado de la CPU.
o Estado de las Entradas/Salidas.
o Estadísticas de la red Ethernet.
o Página de soporte.
o También se pueden descargar páginas web (a través de la utilidad WebLoader)
desarrolladas por el usuario. La memoria es limitada y el servidor solo permite páginas
estáticas y applets de supervisión o control manual.
Los procesadores TSX Momentum M1 o M1E cuentan con:
•
•
•
•
Puerto Modbus o Ethernet.
Segundo puerto opcional (Modbus o I/O bus).
LEDs indicadores del estado de procesador.
Etiqueta.
Figura C.2. TSX Momentum con adaptador de comunicación Ethernet TCP-IP
Carlos Mediavilla Martí
54
20/07/06
Anexo C. Dispositivos Ethernet
C.2. Autómatas – Módulos Ethernet
Algunos de los autómatas industriales integrados en la célula (como el de la estación 5) disponen de
módulos de conexión a Ethernet (y dirección IP). Como ya se ha comentado anteriormente, la arquitectura
de control de este proyecto no se basa en autómatas, pero si se ha desarrollado un pequeño programa Java
[Anexo G.6] que permite a un PC conectarse a los autómatas con conexión Ethernet que permitan ampliar
el control y supervisión de la célula. Aunque el resto de autómatas no tengan acceso a la red Ethernet,
gracias al puente Ethernet / Fipway que posee la estación 5 se puede acceder indirectamente a los
diferentes autómatas a través de dicha red Fipway. Un PLC puede actuar también como bridge o router
para varios niveles de red. Este hecho amplía notablemente las posibilidades de comunicación con la
célula de fabricación, dado que nos podremos conectar a cualquier autómata de la misma por medio de la
red Internet.
El acceso al autómata de la estación 5 y el hecho de que su tabla de variables sea compartida por el
resto de autómatas de la célula ofrece una alternativa al control por PC descrito en la memoria. Esta
opción consistiría en un control mixto donde el PC solo realizaría control indirecto a través de la estación
5.
Figura C.3. Autómata de la célula con módulo Ethernet
El autómata de la estación 5 es de tipo TSX Premium, eso quiere decir que su módulo Ethernet TCP/IP
es un ETY. Los módulos de comunicación TSX ETY 410/510 permiten la comunicación en una
arquitectura Ethernet. Contienen una vía de comunicación que proporciona las siguientes funcionalidades:
•
Conexión a una red Ethernet TCP/IP.
•
Comunicación en modalidad Half y Full Duplex por reconocimiento automático.
•
Velocidad de transmisión de 10 o 100 Mbits/s por reconocimiento automático.
•
Conexión a la red por cable de cobre a través de un conector RJ45.
Carlos Mediavilla Martí
55
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Estos módulos permiten realizar las siguientes funciones:
•
Servicio de mensajería X-WAY UNI-TE y Modbus a través de TCP/IP.
•
Servicio I/O Scanning y Global Data.
•
Servicio SNMP.
•
Páginas Web de diagnóstico integradas.
•
Servidor Web (HTTP y FTP) con 8 Mbytes de memoria libre. El usuario puede añadir páginas
Web personalizadas y applets para aplicaciones específicas.
•
Servidor/cliente Bootp y servidor DHCP.
Los módulos TSX ETY 410/510 son módulos de formato simple que se insertan en un emplazamiento
de un rack principal de una estación autómata Premium. La dirección MAC (000054xxxxxx) del módulo
Ethernet es el identificador de hardware único que se asigna a un dispositivo en una red Ethernet por el
fabricante del equipo, se puede encontrar en una etiqueta en el panel frontal. La dirección IP, perteneciente
a la red local del laboratorio (155.210.154.xxx) se establece inicialmente a partir de la dirección MAC,
pero se puede cambiar mas adelante.
C.3. Modbus TCP-IP
La comunicación entre los PCs de control y/o supervisión con los autómatas de la célula y los
procesadores Momentum M1E se realiza a través de una red Ethernet sobre el protocolo ModBus TCP/IP
(puerto 502).
A continuación se ofrece una breve descripción del protocolo Modbus:
Básicamente ModBus es un protocolo en la capa de aplicación del modelo ISO/OSI (ver figura C.4)
adecuado en entornos de control en tiempo real que permite comunicaciones punto a punto entre
controladores lógicos programables (PLCs) y otros dispositivos, principalmente para intercambiar datos en
redes en el ámbito industrial con gran velocidad en la transmisión de datos (1Mbaudio)
7
6
5
4
3
2
1
Aplicación
Presentación
Sesión
Transporte
Red
Enlace
Física
MODBUS
TCP 502
IP
ETHERNET
Figura C.4. Pila protocolo ModBus TCP-IP
En este nivel, ModBus es un protocolo cliente-servidor sin estado (muy parecido a HTTP), basado en
transacciones, las cuales consisten en una petición (lanzada por el cliente) y una respuesta (lanzada por el
servidor). En el ámbito donde este protocolo es usado normalmente, típicamente existe una configuración
en la que algunos dispositivos son maestros (PC) y otros esclavos (autómata). Para evitar confusiones
denominaremos maestros a los clientes y esclavos a los servidores, ver figura C.5.
Carlos Mediavilla Martí
56
20/07/06
Anexo C. Dispositivos Ethernet
Figura C.5. Transacción en protocolo ModBus
Esta comunicación sin estado esta basada en una simple trama, llamada Protocol Data Unit (PDU). La
especificación del protocolo define tres tipos de PDUs (ver figura C.6):
•
PDU de petición, que consiste en:
o
o
•
PDU de respuesta (ACK), que consiste en:
o
o
•
El código que especifica la función a realizar (Function Code, 1 byte)
Los datos específicos necesarios para realizar esa función (Function Data)
El código de la función correspondiente a la petición realizada (Function Code, 1 byte)
Los datos de la respuesta (Response Data, número variable de bytes)
PDU de error (Exception Response) (NACK), que consiste en:
o
o
El código de función correspondiente a la petición + 0x80 (128), (Error Code, 1 byte)
Y un código que especifica la excepción (Exception Code, 1 byte)
Figura C.6. Estructura básica de tramas en protocolo ModBus
La especificación ModBus define un cierto número de funciones, cada una de las cuales tiene asociada
un código de función único. Los códigos son números enteros en el rango del 1 al 127, mientras que los
códigos de error comprenden del 129 (1+128) al 255 (127+128). Mientras que la primera versión de la
especificación publicada definía diferentes clases de funciones (clase 0, clase 1, clase 2), la especificación
más actual define categorías de códigos de función:
•
Públicas: Son funciones únicas y bien definidas con documentación disponible. Tienen que ser
validadas por la comunidad y pasar un test de conformidad.
•
Definidas por el usuario: Por lo que sus códigos pueden no ser únicos. La especificación reserva
los rangos 65-72 y 100-110 para dichas funciones.
•
Reservadas: Actualmente usadas por algunas compañías para implementar funciones privadas.
Carlos Mediavilla Martí
57
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
El protocolo de comunicaciones Modbus fue Diseñado por Modicon para el uso con sus Controladores
de Lógica Programable (PLCs). Se ha convertido en un protocolo de comunicaciones estándar para la
industria, puesto que representa uno de los medios más comúnmente usados para conectar casi cualquier
dispositivo electrónico industrial, que permite grandes ahorros en costes del cableado. Una de las
principales razones del uso extenso de Modbus en vez de otros protocolos de comunicaciones, son el
hecho de que están publicados abiertamente, producto de ello las diversas variantes y mejoras del original
Modbus. Permiten la administración de una red de dispositivos, por ejemplo de un sistema que registre
temperatura y humedad y almacene resultados en un ordenador. Las versiones para el puerto serie y
Ethernet están disponibles, así como el software, tanto propietario como libre.
Los controladores programables Modicon pueden comunicar con sus homólogos y con otros
dispositivos sobre una variedad de redes. Entre las redes soportadas se incluyen las redes
industriales Modbus y Modbus Plus de Modicon y redes estándar como MAP y Ethernet. Se accede a las
redes por puertos integrados en los controladores o por medio de adaptadores de red, módulos opcionales
y pasarelas que están disponibles desde Modicon. Para OEM están disponibles programas ‘asociados’
ModConnect de Modicon, para integrar correctamente redes como Modbus Plus en el diseño de productos
propietarios.
El lenguaje común utilizado por todos los controladores Modicon es el protocolo Modbus. Este
protocolo define una estructura de mensaje que los controladores reconocerán y usarán, con independencia
del tipo de redes sobre la que comuniquen. Describe el proceso que usa un controlador para pedir acceso a
otro dispositivo, cómo responderá a las peticiones desde otros dispositivos y cómo se detectarán y
notificarán los errores. Establece un formato común para la disposición y contenido de los campos de
mensaje.
El protocolo Modbus proporciona el estándar interno que los controladores Modicon usan para el
análisis de los mensajes. Durante la comunicación sobre una red Modbus, el protocolo determina cómo
cada controlador conocerá su dirección de dispositivo, reconocerá un mensaje direccionado a él,
determinará el tipo de acción a tomar y extraerá cualquier dato u otra información contenida en el
mensaje. Si se requiere una repuesta, el controlador construirá el mensaje respuesta y lo enviará utilizando
el protocolo Modbus.
Sobre otras redes, los mensajes del protocolo Modbus están integrados en la trama o estructura de
paquetes utilizadas sobre la red. Por ejemplo, los controladores de red Modicon para ModbusPlus o MAP.
Con software de aplicación asociado – drivers y librerías - se proporciona la conversión entre el mensaje
de protocolo Modbus y las tramas específicas de los protocolos que esas redes utilizan para comunicar
entre sus dispositivos nodo.
Esta conversión también alcanza a la resolución de direcciones de nodos, caminos de
enrutamiento y métodos de comprobación de error específicos para cada tipo de red. Por ejemplo, las
direcciones de dispositivo Modbus contenidas en el protocolo Modbus serán convertidas en direcciones de
nodo, previamente a la transmisión de los mensajes. Los campos de comprobación de error también
serán aplicados a los paquetes del mensaje, de manera consistente con el protocolo de cada red. De
cualquier modo, en el destinatario – por ejemplo un controlador -, el contenido del mensaje integrado,
escrito utilizando el protocolo Modbus, define la acción a tomar.
Los controladores comunican usando una técnica maestro – esclavo, en la cual sólo un
dispositivo (el maestro) puede iniciar transacciones (llamadas ‘peticiones’ – ‘queries’). Los otros
dispositivos (los esclavos) responden suministrando al maestro el dato solicitado, o realizando la
acción solicitada en la petición. Entre los dispositivos maestros típicos se incluyen los procesadores
centrales y los paneles de programación. Esclavos típicos son los PLC’s (controladores
programables). El maestro puede direccionar esclavos individualmente o puede generar un mensaje en
modo difusión a todos los esclavos. Los esclavos devuelven un mensaje (llamado ‘respuesta’) a las
Carlos Mediavilla Martí
58
20/07/06
Anexo C. Dispositivos Ethernet
peticiones que les son direccionadas individualmente. No se devuelven respuestas a peticiones en modo
difusión enviadas desde el maestro. El protocolo Modbus establece el formato para la petición del
maestro, colocando en ella la dirección del dispositivo esclavo (0 en caso de ‘difusión’), un código de
función que define la acción solicitada, cualquier dato que haya de enviarse y un campo de comprobación
de error. El mensaje de respuesta del esclavo está también definido por el protocolo Modbus. Contiene
campos confirmando la acción tomada, cualquier dato que haya de devolverse y un campo de
comprobación de error. Si el mensaje recibido por el esclavo es defectuoso o el esclavo es incapaz de
realizar la acción solicitada, construirá un mensaje de error y lo enviará como respuesta.
Carlos Mediavilla Martí
59
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
ANEXO D. REDES DE PETRI
D.1. Introducción
Los sistemas de eventos discretos (SED) se componen de varios tipos de nodos que interactúan entre sí.
Cada nodo puede ser a la vez un sistema por sí mismo y un componente de un SED. Estos componentes
pueden operar concurrentemente, es decir, un componente puede estar realizando una de sus funciones al
mismo tiempo que otro. Considérese el caso de un cajero automático conectado a una red de un banco.
Varias personas pueden estar realizando operaciones sobre sus cuentas al mismo tiempo sin interferir unas
con otras. Pero pongámonos en el caso de una pareja que posee una cuenta conjunta que trata de acceder a
su cuenta desde dos cajeros distintos al mismo tiempo, uno de ellos para hacer un ingreso y el otro para
sacar dinero. Aparecen entonces problemas de sincronización, al no haber un orden predeterminado para
los dos eventos, la salida y el ingreso. El orden en que se realicen puede llevar a resultados diferentes; los
bancos han desarrollado unas normas detalladas que tienen en cuenta el tiempo y la secuencia de los
ingresos y las salidas. ¿Pero cómo se pueden describir estos problemas de una manera precisa, sin ningún
tipo de ambigüedad?
La necesidad de resolver esta pregunta llevó a Carl Adam Petri a introducir en su tesis doctoral en 1962
una clase especial de grafos o redes llamados hoy en día Redes de Petri. Son una herramienta de modelado
y análisis especialmente adaptada para el estudio de sistemas de eventos discretos. El uso de redes de Petri
lleva a una descripción matemática de la estructura del sistema que puede ser investigada analíticamente.
Este proyecto pretende implementar un sistema de control mediante redes de Petri en lenguaje Java.
Por lo tanto el código se presentará como consecuencia directa de las definiciones.
D.2. Principios fundamentales
Dado que una RdP es un tipo especial de grafo, debe comenzarse su explicación mediante unas pocas
nociones de teoría de grafos. Un grafo consta de nodos y líneas, y la manera en que están interconectados.
Si el par de nodos conectados por una línea está ordenado, entonces la línea es dirigida y se coloca una
flecha en su extremo para indicar la dirección. Si todas las líneas de un sistema tienen una orientación,
entonces el grafo se denomina grafo orientado. Dos nodos conectados por una línea se llaman nodos
adyacentes. La representación de un nodo puede hacerse de diversas maneras: como un círculo, un
rectángulo, u otro símbolo conveniente. Cuando un grafo contiene líneas paralelas, por ejemplo, líneas que
conectan el mismo par de nodos, y que si son dirigidas tienen la misma dirección, se llama un multigrafo.
Las redes de Petri son multigrafos, considerando solamente redes de Petri ordinarias. En muchas
aplicaciones las propiedades como multigrafo de las redes de Petri pueden ser una gran ventaja. Sin
embargo, introducen una gran complejidad en notación y otros aspectos que pueden ser tratados mejor
mediante extensiones de las redes de Petri ordinarias tales como las redes de Petri coloreadas.
Una segunda característica de las redes de Petri en tanto que grafos es que son grafos bipartidos. Esto
significa que hay dos tipos de nodos. Para distinguir entre ellos se usarán diversos símbolos. Por
convención, el primer tipo de nodo se denomina estado (o lugar) y se representa mediante un círculo o
elipse. El segundo tipo se llama transición y se representa mediante una barra sólida, o un rectángulo. Las
líneas de una RdP se llaman arcos y son siempre dirigidas. Los símbolos se muestran en la siguiente
figura.
Carlos Mediavilla Martí
60
20/07/06
Anexo D. Redes de Petri
Figura D.1. Representación gráfica de lugares, arcos y transiciones
Un grafo bipartido tiene una propiedad especial: una línea sólo puede conectar dos nodos que sean de
tipos diferentes; es decir, sólo puede haber un arco desde una transición a un estado o viceversa pero
nunca de un estado a otro o de una transición a otra.
D.3. Definiciones básicas
Una red de Petri (RdP) es un grafo bipartido orientado representado por la cuádrupla R = (P, T, α, β)
tal que:
•
P es un conjunto finito y no vacío de lugares.
•
T es un conjunto finito y no vacío de transiciones.
•
α = P × T →ℕ es la función de incidencia previa.
•
β = T × P →ℕ es la función de incidencia posterior.
Una RdP se representa gráficamente por un grafo bipartido orientado. Existe un arco que va del lugar pi
a la transición tj si α(pi, tj) ≠ 0. Análogamente, existe un arco que va de la transición tk al lugar pi si β (tk,
pi) ≠ 0. Cada arco se etiqueta con un número natural, α(p, t) o β(t, p) que se denomina peso del arco. Por
convenio, un arco no etiquetado posee un peso unitario. Para facilitar la legibilidad, todo arco cuyo peso
sea superior a la unidad se dibuja normalmente con un trazo grueso, o con dos o más trazos paralelos.
Una RdP se representa matricialmente por medio de dos matrices. Sea | P | = n (número de lugares de
la red) y sea | T | = m (número de transiciones de la red). Se denomina matriz de incidencia previa a la
matriz
C- = [c-ij]n x m,
en la que c-ij = α(pi, tj). Se denomina matriz de incidencia posterior a la matriz
C+ = [c+ij]n x m,
en la que c+ij = β (tk, pi).
Es decir, en las matrices de incidencia los lugares numera las filas (i) y las transiciones las columnas
(j), y cada elemento (i, j) expresa la incidencia que el lugar i tiene sobre la transición j.
Carlos Mediavilla Martí
61
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Una red es ordinaria si sus funciones de incidencia sólo pueden tomar los valores 0 y 1, es decir, que
todos los arcos de la red tienen peso 1:
α(p, t) ∈ { 0 , 1}
β(t, p) ∈ { 0 , 1}
Una red es pura si ninguna transición contiene un lugar que sea simultáneamente de entrada y de
salida.
∀ tj ∈ T, ∀ pi ∈ P α(pi, tj) β (tj, pi) = 0
La representación matricial de una red pura se simplifica definiendo una única matriz, C, denominada
matriz de incidencia.
C = C+ - C- ⇒ cij = { β (tj, pi) si es no nula , -α(pi, tj) si es no nula , 0 en cualquier otro caso}
De esta forma, en la matriz C un elemento positivo indica incidencia posterior y uno negativo señala
incidencia previa. Un elemento nulo en C indica que la transición y lugar correspondientes no están
conectados directamente a través de un arco.
Pongamos el siguiente ejemplo. Sea la red de Petri de la figura:
Figura D.2. Red de Petri ejemplo
Sus matrices de incidencia serán (dado que es una red pura):
matriz de incidencia previa
0
-1
-1
0
0
0
0
0
-1
0
0
0
0
0
-1
-1
0
0
0
0
Carlos Mediavilla Martí
matriz de incidencia posterior
1
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
1
1
62
matriz de incidencia
( 1 0 0 -1 )
(-1 1 0 0 )
(-1 0 1 0 )
( 0 -1 0 1 )
( 0 0 -1 1 )
20/07/06
Anexo D. Redes de Petri
El marcado M de una red R es una aplicación de P en ℕ, es decir, la asignación de un número natural
(número de marcas) a cada lugar. En el grafo asociado a R, el marcado M se representa por una
distribución, en los lugares, de objetos denominados marcas. Una marca se representa gráficamente por un
punto en el interior de la circunferencia que define el lugar que la contiene. Si | P | = n entonces un
marcado se representa, en forma matricial, por un vector de n elementos: M(pi) (vector de marcado).
Una red de Petri marcada es el par (R, M0) en el que R es una red de Petri y M0 es un marcado inicial.
La evolución del marcado le confiere a la RdP marcada un comportamiento dinámico que permite modelar
evoluciones simultáneas de sistemas discretos.
Una transición t ∈ T está sensibilizada por el marcado M si cada uno de sus lugares de entrada posee al
menos α(p, t) marcas. Es decir, se exige que para todo lugar p perteneciente al conjunto de lugares de
entrada de una transición t M(p) ≥ α(p, t).
Regla de evolución del marcado: Disparar una transición sensibilizada o habilitada t es la operación
que consiste en eliminar α(p, t) marcas a cada lugar de entrada de t y añadir β(t, p) marcas a cada lugar de
salida de t. El marcado Mi evolucionará a otro marcado Mj.
Volviendo a la red de Petri del ejemplo el marcado inicial puede ser representado por el vector (1 0 0 0
0 ), por tanto solamente la transición T0 está habilitada para ser disparada. Si se produce el disparo se
quitará una marca de P0 y se añadirán una marca a P1 y P2, estados de salida. El nuevo marcado será (0 1
1 0 0) y tanto T1 como T2 estarán habilitadas.
Una transición es viva, para un marcado M0, si para todo marcado M que se pueda alcanzar a partir del
marcado inicial M0 existe un marcado M’ sucesor de M a partir del cual se puede disparar esa transición.
Una RdP es viva para un marcado dado si todas sus transiciones son vivas para ese marcado. Si una RdP
es no viva para un marcado puede sospecharse que el modelado del sistema objeto de estudio es
incorrecto.
Para un marcado inicial dado, una RdP es binaria si cualquier marcado alcanzable es tal que ningún
lugar posee más de una marca. En una RdP binaria todo lugar estará marcado con una marca o no estará
marcado.
Para un marcado inicial dado, se dice que una RdP es conforme si es binaria y viva. Debido a su
marcado inicial una RdP puede ser conforme, no binaria o no viva.
Figura D.3. Red de Petri Conforme
Carlos Mediavilla Martí
63
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Figura D.4. Red de Petri no binaria
Figura D.5. Red de Petri no viva
Dos o más transiciones simultáneamente sensibilizadas están en conflicto si descienden de un mismo
lugar y éste no dispone de un número de marcas suficientes para dispararlas simultáneamente. Un
conflicto se hace efectivo si los eventos asociados a las transiciones en conflicto se verifican
simultáneamente.
D.4. Redes editor Pipe
Las redes de Petri necesarias para el control automático de la célula se han creado con el editor de
redes de Petri Pipe. Los archivos *.xml finalmente generados que modelan cada uno de los subsistemas en
los que se ha dividido la célula son los siguientes:
Carlos Mediavilla Martí
64
20/07/06
Anexo D. Redes de Petri
Red PNML (xml)
Tarea
Tamaño
RedCelula
Gestión global de la célula en la
implementación centralizada
Gestión global de la célula en el control
descentralizado o distribuido
Gestión global de la célula en la
implementación distribuida (opción A)
Borrado de los palets de la célula en la
implementación centralizada
Borrado de los palets de la célula en el
control descentralizado o distribuido
Control de la estación 1 en la
implementación centralizada
Control de la estación 1 en la realización
descentralizada o distribuida
32 estados y
transiciones
27 estados y
transiciones
28 estados y
transiciones
39 estados y
transiciones
39 estados y
transiciones
44 estados y
transiciones
45 estados y
transiciones
26 estados y
transiciones
17 estados y
transiciones
17 estados y
transiciones
29 estados y
transiciones
29 estados y
transiciones
16 estados y
transiciones
39 estados y
transiciones
39 estados y
transiciones
23 estados y
transiciones
RedCelulaDescentralizada
RedCelulaDistribuida
RedBorrar
RedBorrarDescentralizada
RedEst1
RedEst1Descentralizada
RedEst1Ind
Control de la estación 1 independiente
RedEst2
Control de la estación 2 en la
implementación centralizada
RedEst2Descentralizada
Control de la estación 2
RedEst3
Control de la estación 3 en la
implementación centralizada
Control de la estación 3 en la realización
descentralizada o distribuida
RedEst3Descentralizada
RedEst3Ind
Control de la estación 3 independiente
RedEst4
Control de la estación 4 en la
implementación centralizada
Control de la estación 4 en la realización
descentralizada o distribuida
RedEst4Descentralizada
RedEst4Ind
Control de la estación 4 independiente
28
22
29
38
38
50
50
31
18
17
33
32
18
41
40
25
Debe tenerse en cuenta que una red de Petri creada con el editor Pipe no puede contener absolutamente
toda la información sobre el sistema que define, lo que provoca pequeños problemas. Por ejemplo, un
lugar de la red de Petri puede activar una salida cuando está marcado (acción previa) pero dependiendo de
si la salida es del tipo todo o nada (por ejemplo, las salidas pinza-sube-baja) o con dos variables
complementarias para una misma salida (por ejemplo, cinta-adelante y cinta-atrás) la desactivación de la
salida podrá realizarse cuando se desactive el lugar (acción posterior) o en otro lugar de la red de Petri.
En las figuras siguientes se presentan ejemplos de las redes de Petri con las que se ha trabajado.
•
En la figura D.6 se puede observar el interfaz del editor Pipe, la red de Petri mostrada se
corresponde con la del control de la estación 3.
•
En la figura D.7 se representa la red responsable del borrado de los palets en el visualizador Java
desarrollado, se puede apreciar que los lugares P140 y P141 se pintan de diferente forma que los
demás, esto es porque representan lugares de comunicación.
•
Por último en la figura D.8 se puede ver la red correspondiente al control de la estación 1 en la
pantalla creada en Java para permitir visualizar la evolución de una red de Petri en tiempo real. Se
ha omitido la visualización de las etiquetas por claridad pero también pueden ser visualizadas.
Carlos Mediavilla Martí
65
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Figura D.6. Vista parcial de la RdP de la estación 3 en el editor Pipe
Carlos Mediavilla Martí
66
20/07/06
Anexo D. Redes de Petri
Figura D.7. Vista parcial de la RdP RedBorrarDescentralizada.xml
Carlos Mediavilla Martí
67
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Figura D.8. Vista parcial de la RdP RedEst1.xml
Carlos Mediavilla Martí
68
20/07/06
Anexo E. Tecnología Java
ANEXO E. TECNOLOGÍA JAVA
El lenguaje de programación Java surgió en 1991 del trabajo de un pequeño grupo de personas
liderados por James Gosling que anticiparon que en el futuro los pequeños electrodomésticos se habrían
de conectar entre sí y con un ordenador para crear una red “doméstica”. Para programarlos buscaban un
lenguaje que permitiera que un mismo código funcionara igual independientemente del dispositivo o
plataforma en que se ejecutara. Y aunque el mundo del pequeño electrodoméstico no estaba preparado
para este salto de calidad, si lo estaba Internet. Mediante la introducción de la tecnología Java en el
navegador Netscape Communicator en 1995 comenzó lo que con el tiempo ha sido uno de los más rápidos
desarrollos en la historia de la informática, debido principalmente a las dos principales características de
Java: su portabilidad (puede ejecutarse un mismo código en muy diversas plataformas) y su seguridad
(Java se concibió como un lenguaje de alto nivel orientado a objetos para aprovechar las características de
encapsulamiento y ocultación de información entre objetos inherentes a este tipo de lenguajes)
E.1. ¿Qué es Java?
Java es un lenguaje de programación, un sistema de tiempo de ejecución, un juego de herramientas de
desarrollo y una interfaz de programación de aplicaciones (API)
Un desarrollador de software escribe programas en el lenguaje Java que emplean paquetes de software
predefinidos de la interfaz para programación de aplicaciones de Java (API). Luego compila sus
programas mediante el compilador Java y el resultado de todo ello es lo que se denomina un bytecode
compilado. El bytecode está en una forma que puede ser ejecutado en la máquina virtual Java, que es el
núcleo del sistema de tiempo de ejecución de Java. Esta máquina virtual puede representarse como un
microprocesador implementado en software que funciona utilizando las capacidades que le presta su
sistema operativo y el hardware de su computador. Ahora bien, puesto que la máquina virtual Java no es
un microprocesador real, el bytecode Java es interpretado más que ejecutado directamente en las
instrucciones de la máquina nativa del computador principal. El JRE (Java Runtime Environment) o
sistema de tiempo de ejecución en Java se compone pues de la máquina virtual y del software adicional
con bibliotecas de enlace dinámico, necesarios para implementar la API de Java.
Las claves de la portabilidad de Java son su sistema de tiempo de ejecución y su API. El primero es
sumamente compacto, pues deriva de anteriores esfuerzos de la empresa Sun para crear una plataforma de
software para electrodomésticos. Esta plataforma no se diseñó a partir de un microprocesador ya existente,
sino que arrancó de cero con el propósito de ser simple y eficaz. La naturaleza simple, eficaz, compacta y
de arquitectura neutra del JRE es lo que confiere su gran portabilidad y le hace alcanzar unas prestaciones
notables.
Los potentes recursos para el trabajo en ventanas y redes incluidos en el API de Java facilitan a los
programadores el desarrollo de un software que resulte a la vez atractivo e independiente de cualquier
plataforma. Existen lenguajes de programación, como Ada, que están notablemente estandarizados y son
aptos para la mayoría de sistemas operativos. Sin embargo, las aplicaciones de Ada no son precisamente
muy portables porque el lenguaje no cuenta con una API común que admita el trabajo en ventanas y redes
en todas las plataformas. Java se diferencia de Ada y de todos los lenguajes de programación en que
dispone de una API apta para todos los sistemas operativos más utilizados: Windows, Linux y Solaris,
además de contar con extensiones para móviles, bases de datos, etc...
Como ya se ha dicho, Java surgió durante el año 1991 en el seno de Sun Microsystems como un intento
de crear una plataforma de software barata e independiente del hardware mediante C++. Por una serie de
razones técnicas se decidió C++ y crear un nuevo lenguaje de programación basado en él, llamado Oak,
que superara las deficiencias del C++, tales como la herencia múltiple, la conversión automática de tipos,
Carlos Mediavilla Martí
69
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
el uso de punteros y la gestión de la memoria. El lenguaje Oak se usó para crear un pequeño dispositivo
electrónico llamado *7. Pero el proyecto llevó asimismo a la creación de numerosos elementos que fueron
precursores de los componentes de Java. Hubo ciertos intentos de aplicar esta tecnología a cierto número
de aplicaciones de consumo, pero lo cierto es que estaba demasiado adelantado a su tiempo y no tuvo la
salida esperada.
En 1994 se produjo el nacimiento de Internet; Oak fue rebautizado como Java y sus creadores
decidieron utilizarlo como base para un navegador Web, que llamaron WebRunner. A principios de 1995
HotJava, Java y la documentación y código fuente pudieron ser obtenidos vía red en su versión alfa.
Inicialmente Java se presentó para Sparc Solaris y, a continuación, para Windows 95 y Linux. En otoño
del mismo año se publicó la versión beta 1 de Java en la página de Sun, al tiempo que el navegador
Netscape 2.0 introducía la compatibilidad con Java.
En diciembre de 1995 se dio a conocer la versión beta 2 de Java, y Sun y Netscape anunciaron la
aparición de JavaScript. El éxito de Java fue ya inevitable cuando a principios de ese mismo mes
Microsoft e IBM dieron a conocer su intención de solicitar licencia para aplicar la tecnología de Java. El
23 de enero de 1996 se publicó oficialmente la versión 1.0, que podía obtenerse desde la página Web.
Actualmente Java está en su versión 5.0, aunque en este proyecto la utilizada es la 1.4.
Esta memoria no puede pretender ser un manual detallado de programación en Java. Sin embargo si
que resulta conveniente dar algunas nociones acerca de este lenguaje para clarificar algunas decisiones
tomadas a lo largo de la realización del proyecto.
E.2. Orientación a objetos
Java es un lenguaje orientado a objetos. El paradigma de la programación orientada a objetos surgió en
contraposición a la tradicional programación estructurada. En la programación estructurada primero se
examina el problema a resolver, se divide en tantas partes como sea necesario, y se implementa la solución
mediante funciones. Lenguajes clásicos como C o Pascal se enmarcan dentro de esta categoría.
Sin embargo los lenguajes de programación orientados a objetos parten de que para resolver un
problema lo primero es descomponerlo en los objetos que lo forman. Por ejemplo, si quisiéramos
programar un sistema de gestión de un zoológico según el método de programación estructurada
cogeríamos todo lo que hay que hacer en un zoo (alimentar a los animales, gestión de las taquillas, etc...) y
crearíamos los procedimientos necesarios. En la programación orientada a objetos lo primero que hay que
preguntarse es qué objetos componen el sistema. En este caso un posible modelado podría contener a los
animales, los empleados, las jaulas, las tiendas, etc... Una vez hecho esto hay que asignar unas
funcionalidades a cada objeto y pensar en cómo se comunican entre ellos. Por ejemplo, los empleados
tendrán la función de limpiar las jaulas, los animales tendrán una jaula asignada, etc...
La programación orientada a objetos posee ciertas características que hacen de la programación un
proceso más eficiente que la programación estructurada: la herencia, el polimorfismo y el ocultamiento de
la información. Por ejemplo, para modelar nuestro zoo podríamos crear un objeto animal al que le
asignaríamos una jaula a cada uno y una determinada cantidad de alimentos. Después cada animal
individual con sus propias características sólo tendría que “sobrescribir” según sus necesidades la cantidad
de alimentos. Esto es lo que se llama herencia: aprovechar las funcionalidades de un objeto ya creado
(llamado comúnmente padre) para, añadiendo alguna nueva si es necesario, crear un nuevo objeto
(llamado hijo). También así un empleado que se encargará de alimentar a los animales no tendría que tener
un método específico para alimentar a cada tipo de animal; tendrá un método “alimentaAnimal” que según
el animal a alimentar hará una cosa u otra. A esta capacidad se le llama polimorfismo. El ocultamiento de
la información consiste en que una clase no tiene por qué conocer la forma en que otra implementa un
determinado método: Siguiendo con nuestro ejemplo, el león no necesita saber como es alimentado por el
cuidador, mientras este lo alimente correctamente.
Carlos Mediavilla Martí
70
20/07/06
Anexo E. Tecnología Java
El software diseñado con esta metodología se dice que es reutilizable. En programación estructurada se
tomaba cada tarea como un todo, por lo que en cuanto surgían problemas particulares se hacía muy difícil
el aprovechar código ya existente para un problema similar (por ejemplo, dos zoos con diferentes tipos de
animales). Si por algo se ha impuestos la programación orientada a objetos es porque permite más
fácilmente la reutilización del código: si quisiéramos hacer otro zoo ya contaríamos con la mayoría del
sistema descrito por los objetos, y en caso de que hubiera animales nuevos en vez de empezar de cero ya
contaríamos con la clase animal de la que hacerlos descender. Esto permite una mayor rapidez en el
desarrollo del software a la vez que una menor probabilidad de errores de programación, junto con un
diseño más eficiente. Características que son las que las empresas de desarrollo de aplicaciones, como
cualquier otra empresa, busca finalmente para sus productos.
Aplicando esta metodología en este proyecto lo primero en que se pensó fue en los objetos que
habríamos de tener: estados, transiciones, coordinadores, redes, estaciones, variables de entrada y salida,
etc... Una vez se tiene esto los métodos de cada uno surgen de manera lógica. Para comprobar la bondad
del método basta con echar un vistazo a la implementación programada de RdP en Ada existente y al
código creado para este proyecto: de un código casi ilegible, y por tanto difícil de modificar y mantener, se
ha pasado a un código perfectamente estructurado en el que cada clase posee una funcionalidad específica
que hace que posibles fallos o modificaciones sean más fáciles de localizar y realizar.
E.3. Concurrencia
La programación concurrente es aquella en la que están involucrados varios hilos de ejecución
funcionando simultáneamente. Esta situación se produce normalmente cuando varios objetos intentan
acceder a un recurso común limitado. Para poner un ejemplo de este mismo proyecto, esto sucede cuando
las estaciones intentan acceder al identificador de productos para leer o escribir los palets. Dado que el
identificador de productos sólo puede atender a una de ellas cada vez debe de implementarse algún
sistema que permita el control de quién y cómo accede al recurso.
El lenguaje Java desde sus origines ha dado soporte para la programación multihilo a través de la clase
Thread. Un Thread representa un hilo de ejecución de una aplicación. Una aplicación puede tener un gran
número de hilos ejecutándose simultáneamente; por ejemplo, el garbage collector es un hilo que se
encarga de borrar de la memoria los objetos que han sido asignados para ello. Hasta la versión 1.4.2 del
JDK Java implementaba la concurrencia mediante las llamadas a los métodos wait(), notify() y notifyAll()
y la sentencia synchronized.
El método wait() provoca que un hilo deje de ejecutarse y espere en estado “latente”. El hilo
“despertará” cuando otro hilo llame a uno de los métodos notify() o notifyAll(). La sentencia synchronized
implica que la porción de código o el método al que afecta no puede ser accedido a la vez por más de un
hilo; es decir, cuando un hilo llega a una porción de código o a un método marcado como synchronized
adquiere la “llave” o lock del objeto donde está el código o método. A partir de este momento y hasta que
se libere el lock ningún otro hilo podrá acceder a métodos o variables de ese objeto.
Primitivas de multihilado de bajo nivel, tales como bloques synchronized, Object.wait y Object.notify,
son insuficientes para muchas tareas de programación. Como resultado los programadores de aplicaciones
se ven forzados a menudo a implementar sus propias funciones de concurrencia. Esto conlleva una enorme
duplicación del esfuerzo. Además, estas funciones son difíciles de conseguir y aún más de optimizar. Las
funciones de concurrencia escritas por programadores de aplicaciones son a menudo incorrectas o
ineficaces. Ofreciendo un conjunto estandarizado de funciones de concurrencia se puede ayudar en la tarea
de escribir una amplia variedad de aplicaciones multihilo y se mejorará la calidad de las aplicaciones que
las usen.
Carlos Mediavilla Martí
71
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
E.4. RMI (Remote Method Invocation)
RMI (Java Remote Method Invocation) es el mecanismo ofrecido en Java que permite a un
procedimiento (también llamado método) poder ser invocado remotamente. Una de las ventajas al diseñar
un procedimiento con RMI es interoperabilidad, ya que RMI forma parte de todo JDK, por ende, cualquier
plataforma que tenga acceso a un JDK también tendrá acceso a estos procedimientos, esto a diferencia del
clásico CORBA que requiere de otros criterios.
Por medio de RMI, un programa java, al que llamaremos servidor, pone uno de los objetos que
instancia accesible desde red, de forma que otros programas java en red, que llamaremos clientes, pueden
invocar métodos de este objeto. De ahí el nombre de "Remote Method Invocation, RMI"
Cuando un cliente java le pide al servidor un objeto e invoca a uno de sus métodos, el código de dicho
método se ejecuta en el servidor. El código del cliente queda en espera de que el servidor termine de
ejecutar el método y devuelva un resultado.
La arquitectura RMI puede verse como un modelo de cuatro capas:
Aplicación servidor
Aplicación cliente
Capa proxy
Figura E.1. Modelo de capas del middleware RMI
•
La primera capa es la de aplicación y se corresponde con la implementación real de las
aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar
objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su
acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda
java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente
accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto
puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete
java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del
mismo paquete.
•
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la
capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y
retorno de objetos tienen lugar en esta capa.
Carlos Mediavilla Martí
72
20/07/06
Anexo E. Tecnología Java
•
La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las
invocaciones remotas. También es responsable de la gestión de la replicación de objetos y
realización de tareas específicas de la implementación con los objetos remotos, como el
establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de
conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented
connection) desde la capa de transporte.
•
La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del
transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es
JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.
A continuación se va exponer de forma práctica el proceso para crear y poner en funcionamiento uno
de los servidores de la aplicación desarrollada.
Vamos a ver qué clases necesitamos para hacer nuestros clientes y servidores de RMI, sin extendernos
demasiado. Luego veremos cada uno de estos puntos por detallado.
•
InterfaceRemota. Es una interface java con todos los métodos que queramos poder invocar de
forma remota, es decir, los métodos que queremos llamar desde el cliente, pero que se ejecutarán
en el servidor.
•
ObjetoRemoto. Es una clase con la implementación de los métodos de InterfaceRemota. A esta
clase sólo la ve el servidor de RMI.
•
ObjetoRemoto_Stubs. Es una clase que implementa InterfaceRemota, pero cada método se
encarga de hacer una llamada a través de red al ObjetoRemoto del servidor, esperar el resultado y
devolverlo. Esta clase es la que ve el cliente y no necesitamos codificarla, java lo hace
automáticamente para nosotros a partir de ObjetoRemoto.
Necesitamos también un fichero de política de seguridad. En este fichero se indica al servidor de RMI
y al cliente de RMI, qué conexiones pueden o no establecerse. Debe haber un fichero de política de
seguridad en el Servidor de RMI y otro en el Cliente.
En el pc/máquina servidor de RMI deben correr dos programas:
•
rmiregistry. Este es un programa que nos proporciona java. Una vez arrancado, admite que
registremos en él objetos para que puedan ser invocados remotamente y admite peticiones de
clientes para ejecutar métodos de estos objetos.
•
Servidor. Este es un programa que debemos hacernos nosotros. Debe instanciar el ObjetoRemoto
y registrarlo en el rmiregistry. Una vez registrado el ObjetoRemoto, el servidor no muere, sino que
queda vivo. Cuando un cliente llame a un método de ObjetoRemoto, el código de ese método se
ejecutará en este proceso.
En el pc/máquina del cliente debe correr el programa:
•
Cliente. Este programa debemos hacerlo nosotros. Pide al rmiregistry del pc/máquina servidor
una referencia remota al ObjetoRemoto. Una vez que la consigue (en realidad obtiene un
ObjetoRemoto_Stub), puede hacer las llamadas a sus métodos. Los métodos se ejecutarán en el
Servidor, pero Cliente quedará bloqueado hasta que Servidor termine de ejecutar el método.
Carlos Mediavilla Martí
73
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
La interfaz de la clase remota:
Lo primero que tenemos que hacer es una interface con los métodos que queremos que se puedan
llamar remotamente. Esta interface sería como la siguiente:
import java.rmi.Remote;
public interface InterfaceRMICelula extends Remote
{
boolean isEmergencia(int estacion) throws RemoteException;
void lanzarCoordinador(boolean borrar) throws RemoteException;
void addPedido(byte tipoPieza) throws RemoteException;
…
}
Tiene que heredar de la interface Remote de java, si no el objeto no será remoto. Se añaden además los
métodos que se necesiten, pero todos ellos deben lanzar la excepción java.rmi.RemoteException, que se
producirá si hay algún problema con la comunicación entre los dos ordenadores o cualquier otro problema
interno de RMI.
Todos los parámetros y valores devueltos de estos métodos deben ser tipos primitivos de java o bien
clases que implementen la interface Serializable de java. De esta forma, tanto los parámetros como el
resultado podrán "viajar" por red del cliente al servidor y al revés.
El objeto remoto:
Hay que hacer una clase que implemente esa InterfaceRemota, es decir, que tenga los métodos que
queremos llamar desde un cliente RMI. El servidor de RMI se encargará de instanciar esta clase y de
ponerla a disposición de los clientes. Esa clase es la que llamamos objeto remoto.
Esta clase remota debe implementar la interface remota que hemos definido (y por tanto
implementará también la interface Remote de java), pero también debe hacer ciertas cosas bien. Debe
definir métodos como hashCode(), toString(), equals(), etc de forma adecuada a un objeto remoto.
También debe tener métodos que permita obtener referencias remotas, etc. Es decir, una serie de cosas
más o menos complejas y de las que afortunadamente no tenemos que preocuparnos. La forma sencilla de
hacer esto es hacer que la clase herede de UnicastRemoteObject. Sería más o menos la siguiente:
import java.io.Serializable;
public class ServidorCelulaDes extends UnicastRemoteObject implements
InterfaceRMICelula
{
…
public void lanzarCoordinador(boolean opcion)
{
produccion.setResetearPalets(opcion);
if (!coordinadorCelula.isFuncionando())
{
coordinadorCelula.start();
}
}
…
}
Carlos Mediavilla Martí
74
20/07/06
Anexo E. Tecnología Java
Otra opción es no hacerlo heredar de UnicastRemoteObject, pero luego la forma de registrarlo varía un
poco y además debemos encargarnos de implementar adecuadamente todos los métodos indicados (y
algunos más). En el presente proyecto se ha preferido esta segunda opción debido a que la anterior da
problemas cuando se utiliza con la máquina virtual Jamaica.
import java.io.Serializable;
public class ServidorCelulaDes implements InterfaceRMICelula
{
public ServidorCelulaDes() throws RemoteException
{
super();
UnicastRemoteObject.exportObject(this);
}
…
public void lanzarCoordinador(boolean opcion)
{
…
}
…
}
La clase de stubs:
Una vez compilado y que obtenido el fichero ServidorCelulaDes.class, se necesita crear la
"clase de stubs". ¿Qué es esto? Para que desde un programa en un ordenador se pueda llamar a un método
de una clase que está en otro ordenador, está claro que de alguna manera se debe enviar un mensaje por
red de un ordenador a otro, indicando que se quiere llamar a determinado método de determinada clase y
además pasar los parámetros de dicha llamada. Una vez ejecutado el método, el ordenador que lo ha
ejecutado debe enviar un mensaje con el resultado. La clase de stubs es una clase con los mismos métodos
que ServidorCelulaDes, pero en cada uno de esos métodos está codificado todo el tema del envío del
mensaje por red y recepción de la respuesta.
Afortunadamente para el programador, no se tiene que codificar la implementación de los protocolos
de mensajes de ida y vuelta. Java nos proporciona una herramienta llamada rmic a la que le pasamos la
clase ServidorCelulaDes y nos devuelve la clase de stubs ServidorCelulaDes_stub. Sólo
tenemos que ejecutar rmic de la siguiente manera:
$ rmic control.descentralizado.ServidorCelulaDes
Esto generará un ServidorCelulaDes_stub.class y un ServidorCelulaDes_Skel.class. El
primero debe estar visible tanto por el cliente como por el servidor, es decir, deben aparecer en el
CLASSPATH de ambos. Eso implica que debe estar situado en el servidor en un sitio público al que el
cliente
tenga
acceso
o
que
se
debe
suministrar
una copia
al
cliente.
El
ServidorCelulaDes_Skel.class se genera por defecto y sólo es útil para clientes con java anterior a
la versión 1.2. Para las versiones Java más modernas no tiene utilidad.
El fichero de política de seguridad:
Se debe crear un fichero de permisos. Este fichero de permisos le dirá al servidor de RMI qué
conexiones debe o no aceptar o al cliente qué conexiones puede o no establecer. El fichero de permisos se
llamará rmi.policy y estará tanto en el computador que lanza el servidor como en el cliente de RMI. El
fichero tiene el siguiente contenido:
Carlos Mediavilla Martí
75
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
grant {
permission java.net.SocketPermission "*:1024-65535", "connect,accept";
permission java.net.SocketPermission "*:8080", "connect";
};
Para evitar problemas de permisos porque al ejecutar el programa no se encuentre este fichero. Una
forma de obligar a que coja el fichero que se quiere es cambiar la propiedad "java.security.policy" de la
siguiente manera:
System.setProperty("java.security.policy","/home/carlos/workspace/rmi.policy");
Lanzar rmiregistry:
Antes de registrar el objeto remoto, se debe lanzar, desde una shell de Linux el programa rmiregistry.
Este programa viene con java y está en el directorio bin de donde este instalado java y simplemente se
tiene que arrancar sin parámetros. Es importante al arrancarlo que la variable CLASSPATH no tenga
ningún valor que permita encontrar los objetos remotos de nuestra aplicación, por lo que se aconseja
borrarla antes de lanzar rmiregistry. Si rmiregistry esta en el PATH de búsqueda de ejecutables (o nos se
está situado en el directorio en el que está), se lanzará de la siguiente manera:
$ unset CLASSPATH
$ rmiregistry
Una vez arrancado rmiregistry, podemos registrar en él los objetos remotos de la aplicación.
Nuestro Servidor de RMI:
Lo siguiente que se tiene que hacer es ejecutar un programa java que instancie y registre el objeto
remoto. Este programa java debe hacer lo siguiente
Indicar cual es el path en el que se puede encontrar la clase correspondiente al objeto remoto. En el
caso actual, el path en el que se puede encontrar ServidorCelulaDes.class. Dicho path se da en
formato URL, por lo que no admite espacios ni caracteres extraños (Quizás admita los típicos %20% que
se ven en el navegador cuando hay espacios en la url, pero no lo he probado). En este proyecto se dejan
las clases ServidorCelulaDes.class, InterfaceRMICelula.class y ServidorCelulaDes
_Stubs.class en la carpeta objetosRemotos del servidor Web. El path, en formato URL, puede ser así
"http://localhost:8080/WebCelula/objetosRemotos". En vez de localhost puede ponerse la dirección IP.
El código para indicar esto es el siguiente:
System.setProperty("java.rmi.server.codebase", "http://" + ServidorCelula.IP +
":8080/WebCelula/objetosRemotos/");
Carlos Mediavilla Martí
76
20/07/06
Anexo E. Tecnología Java
Consiste en fijar una propiedad de nombre java.rmi.codebase con el path donde se encuentran los
ficheros .class remotos.
Hay que asegurarse que hay un gestor de seguridad. Para ello se comprueba si existe y si no hay, se
añade. El código para ello es este:
if (System.getSecurityManager() == null)
{
System.setSecurityManager(new RMISecurityManager());
}
Por último, instanciar una clase remota y luego registrarla en el servidor de RMI. Eso es sencillo:
try
{
InterfaceRMICelula servidorCelula = new ServidorCelulaDes();
Naming.rebind("//localhost/ServidorCelula", servidorCelula);
}
catch (Exception e)
{
e.printStackTrace();
}
La instanciación no tiene problemas. Para registrarla hay que llamar al método estático rebind() de la
clase Naming. Se le pasan dos parámetros. Un nombre para poder identificar el objeto y una instancia del
objeto. El nombre que hemos dado debe conocerlo el cliente, para luego poder pedir la instancia por el
nombre. El método rebind() registra el objeto. Si ya estuviera registrado, lo sustituye por el que acabamos
de pasarle.
Ya está todo lo que tiene que hacer el programa que registra el objeto.
El Cliente de RMI:
Ahora sólo se tiene que hacer el programa que utilice este objeto de forma remota. Los pasos que
debe realizar este programa son los siguientes:
Pedir el objeto remoto al servidor de RMI. El código para ello es sencillo:
InterfaceRMICelula servidorCelula = (InterfaceRMICelula)Naming.lookup ("//localhost/
ServidorCelula ");
Simplemente se llama al método estático lookup() de la clase Naming. Se le pasa a este método la URL
del objeto. Esa URL es el nombre (o dirección IP) del host donde está el servidor de RMI (en mi caso
localhost) y por último el nombre con el que se registró anteriormente el objeto (en mi caso
ServidorCelula)
Este método devuelve un Remote, así que se debe hacer un "cast" a InterfaceRMICelula para poder
utilizarlo. El objeto que se recibe aquí es realmente un ServidorCelulaDes _Stub.
Carlos Mediavilla Martí
77
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Usar el objeto remoto. Por ejemplo llamando al método de lanzarCoordinador():
servidorCelula.lanzarCoordinador(true);
Para que el código del cliente compile necesita ver en su classpath a InterfaceRMICelula.class. Para
que además se ejecute sin problemas necesita además ver a ServidorCelulaDes_Stubs.class, por lo que
estas clases deben estar accesibles desde el servidor o bien tener copias locales de ellas.
E.5. Métodos nativos. JNI
Aunque la potencia de la API de Java es más que suficiente para casi todo tipo de aplicaciones, algunas
de ellas necesitan utilizar la potencia específica de una plataforma en concreto, por ejemplo para conseguir
un poco más de velocidad y eficiencia. Java permite incorporar en sus programas fragmentos de código
nativo es decir, código compilado para una determinada plataforma, generalmente escrito en C/C++. Así
se puede utilizar código específico de una plataforma o bibliotecas ya escritas en otro lenguaje.
El JNI es la herramienta que posee Java para aprovechar métodos realizados en otro lenguaje de
programación. Aunque esto pueda parecer un contrasentido es una situación que se da más veces de las
que podría suponerse. Por ejemplo, existen algoritmos matemáticos en C que al ser pasados a Java
aumentaban extraordinariamente su tiempo de ejecución. O librerías de drivers que sólo están disponibles
en determinados lenguajes, como es el caso que nos ocupa, ver figura E.2.
Para ello Java cuenta con el JNI (Java Native Invocation). Hay que tener en cuenta que una aplicación
que utilice este tipo de métodos estará violando las directrices de seguridad de la máquina virtual Java,
motivo por el que no se permite incluir métodos nativos en applets de Java.
Dado que Java surgió a partir de C++ la implementación de métodos nativos más sencilla es la
realizada en C o C++. El procedimiento a seguir se explicará más detalladamente en el próximo apartado.
Hay que resaltar que todo método nativo llamado desde Java, tras devolver el control al lenguaje Java,
pierde todos los valores de las variables contenidos en el a no ser que dichas variables sean almacenadas
en soporte no volátil. Suceso que ha de tomar alta importancia a la hora de tomar decisiones cuando se
trabaja con métodos nativos.
Tarjeta Interbus
Programa de
Control Java
Biblioteca de
comunicaciones
JNI
Figura E.2. Java, C y JNI
Para este PFC se propuso trabajar con el lenguaje de programación Java dado que contiene una
especificación para tiempo real que se puede explotar desde Linux. Visto esto y que nuestra tarjeta trabaja
solo con funciones en C se opto por utilizar esta especificación que permite Java que es el JNI o Java
Native Interface.
Carlos Mediavilla Martí
78
20/07/06
Anexo E. Tecnología Java
El proceso para utilizar código nativo (que es como designaremos de ahora en adelante al código C)
dentro de un programa Java se puede resumir en la siguiente figura, que resume el proceso de creación de
la típica aplicación de ejemplo Hola Mundo:
1 - Escribir el código Java.
2 - Usar javac para compilar el código.
3 - Usar javah –jni para generar un fichero de cabecera.
4 - Escribir la implementación del método nativo.
5 - Compilar el código nativo en una librería compartida y cargarla.
Figura E.3. Pasos para trabajar con JNI
A continuación se resumen los pasos necesarios:
Carlos Mediavilla Martí
79
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Paso 1: Escribir el código Java:
Tenemos que crear una serie de clases Java que nos permitan controlar las estaciones. Para ello se ha
creado una clase por cada estación, en la que se han definido las variables de entrada y salida de la
estación (ver Anexo H.7). Esta clase contiene el valor booleano de cada variable así como un número que
la identifica dentro del conjunto de variables de la lista. Para evitar un acceso continuo a la tarjeta y de
este modo permitiendo una mayor velocidad de escritura lectura de datos se ha creado una única función
que realiza la escritura y lectura de salidas y entradas al mismo tiempo además de las que inicializan y
finalizan la estación todas ellas contenidas en las clases de comunicaciones, con los siguientes métodos:
public native synchronized int [] Interbus (int [] bufferSalidas);
public native void InicializaEstacion();
public native void FinalizaEstacion();
La etiqueta native proporciona al compilador la información acerca de que la implementación de las
funciones se define en un archivo en otro lenguaje de programación.
Paso 2: Compilar el código Java:
Para compilar las clases Java se usa la aplicación javac con lo que resultan los archivos.class.
Paso 3: Crear el archivo *.h:
Los archivos con la extensión .h son archivos de cabecera (en inglés header) que proporcionan
información al programador acerca de las funciones de un programa independientemente de su
implementación. Mediante la aplicación javah (o jamaicah) se crea un archivo que contiene el
nombre y los parámetros que debe tener la función nativa para que sea comprensible para el programa
Java. Así por ejemplo al ejecutar la aplicación en la clase Interbus se obtiene el siguiente resultado:
jamaicah -o interbus.h –cp /home/carlos/jdom1.0/build/jdom.jar:/home/carlos/workspace/PFC2006/bin:/home/carlos/xerces1_4_4/xerces.jar:/home/carlos/workspace/PFC2006/classes comunicaciones.Interbus
JNIEXPORT jintArray JNICALL Java_comunicaciones_Interbus_Interbus (JNIEnv *env,
jobject obj, jintArray salidas);
JNIEXPORT jboolean JNICALL Java_comunicaciones_Interbus_inicializaCelula(JNIEnv *,
jobject obj);
JNIEXPORT void JNICALL Java_comunicaciones_Interbus_finalizaCelula(JNIEnv *, jobject);
Este proceso es similar para todas las funciones nativas que se quieran utilizar en un programa. El
nombre de las funciones se divide en varias partes, según se describe en la figura siguiente:
Figura E.4. Nomenclatura de métodos JNI 1
Carlos Mediavilla Martí
80
20/07/06
Anexo E. Tecnología Java
Además, cada función nativa, independientemente del número de parámetros que contenga, tendrá
también los parámetros JNIEnv* env, jobject obj. env es un puntero que apunta a una tabla
de punteros los cuales apuntan a funciones, funciones que usaremos para acceder a los datos Java de JNI.
obj depende de si es un método de instancia o de clase (estático). Si es de clase, se trata de una referencia
jclass a un objeto que representa la clase en la cual están definidos los métodos estáticos. Si es un método
de instancia se trata de un jobject que actúa como puntero this al objeto Java.
Paso 4: Escribir la implementación del método nativo:
Para escribir la implementación del método nativo solo es necesario copiar estas cabeceras generadas
en el .h y pegarlas en nuestro código C que creamos. Lo más importante es que las definiciones del
nombre de la función Java coincidan con las de la función C, para lo cual deberemos valernos del archivo
.h generado en el paso anterior (codigocom2.h). Así la siguiente figura muestra como debe hacerse la
conversión:
Figura E.5. Nomenclatura de métodos JNI 2
La implementación final de las funciones queda como sigue:
JNIEXPORT jintArray JNICALL Java_comunicaciones_Interbus_Interbus (JNIEnv *env,
jobject obj, jintArray salidas)
{
int i;
short sRet;
jintArray entradas;
jsize lon = (*env)->GetArrayLength(env, salidas);
entradas = (*env) ->NewIntArray (env, lon);
jint *S = (*env)->GetIntArrayElements(env, salidas, 0);
jint *E = (*env)->GetIntArrayElements(env, entradas, 0);
if (lon <= 0) {
printf ("Se recibio un vector nulo desde Java");
exit(-1);
} else {
for (i=0; i<lon; i++) {
tIOSendData[i] = S[i];
}
sRet = DevExchangeIO
(numeroTargeta,0,sizeof(tIOSendData),&tIOSendData,0,sizeof(tIOSendData),&tIORecvData,1
0L);
//usleep(10000);
if (sRet != DRV_NO_ERROR) {
printf ("Error en la escritura/lectura del buffer de la targeta : %d\n", sRet);
exit(-1);
}
for (i=0; i<lon; i++) {
E[i] = tIORecvData[i];
}
(*env)->ReleaseIntArrayElements(env, salidas, S, JNI_ABORT); //MUY NECESARIO
(*env)->ReleaseIntArrayElements(env, entradas, E, 0); //MUY NECESARIO
return entradas;
}
}
Carlos Mediavilla Martí
81
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
El vector generado en Java debe corresponde totalmente para el correcto funcionamiento con el vector
en C que será enviado a la tarjeta correspondiéndose cada una de las salidas que se quieren enviar y
entradas que se quieren recibir con el esquema siguiente:
/*------------------------------------------------------------------------------------*/
/*
SALIDAS DEL INTERBUS
*/
/*------------------------------------------------------------------------------------*/
/*tIOSendData[0] = 0;
Estacion 3 segundo octeto Salidas NO CABLEADO*/
/*tIOSendData[1] = 0;
/*
/*
/*
/*
/*
/*
/*
Estacion 3 primero octeto Salidas */
"1" Cinta_avanza */
"2" Cinta_retrocede */
"4" Roscar */
"8" Pinza subebaja */
"16" Culata */
"32" Fijar */
"64" Pinza */
/*tIOSendData[2] = 0;
/*
/*
/*
/*
/*
/*
/*
Transporte 2 octeto salidas */
"1" Tope en estacion 4 */
"2" Tope en la zona del medio */
"4" NO CABLEADO */
"8" Avanza cinta Estaciones 1 y 2 y la transversal superior */
"16" Avanza cinta Estaciones 3 y 4 y las dos transversales */
"32" NO CABLEADO */
"64" NO CABLEADO */
/*tIOSendData[3] = 0;
/*
/*
/*
/*
/*
/*
/*
/*
Transporte 1 octeto salidas */
"1" Enclavamiento de palets estacion 1 */
"2" Enclavamiento de palets estacion 2 */
"4" Enclavamiento de palets estacion 3 */
"8" Enclavamiento de palets estacion 4 */
"16" Encarrilado de palets hacia la cinta del medio*/
"32" Tope en estacion 1 */
"64" Tope en estacion 2 */
"128" Tope en estacion 3 */
/*tIOSendData[4] = 0;
/*tIOSendData[5] = 0;
/*tIOSendData[6] = 0;
/*tIOSendData[7] = 0;
/*tIOSendData[8] = 0;
/*tIOSendData[9] = 0;
/*tIOSendData[10] = 0;
/*tIOSendData[11] = 0;
Estacion
Estacion
Estacion
Estacion
Estacion
Estacion
Estacion
Estacion
/*tIOSendData[12] = 0;
/*tIOSendData[13] = 0;
nada ...?*/
nada ...?*/
/*tIOSendData[14]
/*tIOSendData[15]
/*tIOSendData[16]
/*tIOSendData[17]
/*tIOSendData[18]
/*tIOSendData[19]
/*tIOSendData[20]
/*tIOSendData[21]
=
=
=
=
=
=
=
=
0;
0;
0;
0;
0;
0;
0;
0;
Estacion
Estacion
Estacion
Estacion
Estacion
Estacion
Estacion
Estacion
/*tIOSendData[22]
/*tIOSendData[23]
/*tIOSendData[24]
/*tIOSendData[25]
=
=
=
=
0;
0;
0;
0;
Estacion
Estacion
Estacion
Estacion
/*tIOSendData[26] = 0;
1
1
1
1
1
1
1
1
primer
primer
primer
primer
primer
primer
primer
primer
modulo
modulo
modulo
modulo
modulo
modulo
modulo
modulo
primera salida, Cinta avanza*/
segunda salida, Cinta retrocede*/
tercera salida, Pinza fuera*/
cuarta salida, Pinza dentro*/
quinta salida, Pinza sube/baja*/
sexta salida, Cargador*/
septima salida, Pinza*/
octava salida, Lector*/
4
4
4
4
4
4
4
4
primer
primer
primer
primer
primer
primer
primer
primer
modulo
modulo
modulo
modulo
modulo
modulo
modulo
modulo
primera salida, girar izp */
segunda salidas, girar drcha */
tercera salidas, cilindro sube */
cuarta salida, verificador sube*/
quinta salida, inyecta*/
sexta salida, expulsa*/
septima salida, vacio pinza*/
octava salida, vacio en pieza*/
4
4
4
4
segundo
segundo
segundo
segundo
modulo
modulo
modulo
modulo
primera salida, marcha, saca*/
segunda salida, expulsar pieza*/
tercera salida, vascular*/
cuarta salida, manual automatico*/
Estacion 4 segundo modulo quinta salida, pinza fuera*/
Figura E.6. Definiciones de las variables de salida del programa
Carlos Mediavilla Martí
82
20/07/06
Anexo E. Tecnología Java
/*
ENTRADAS DEL INTERBUS
*/
/*------------------------------------------------------------------------------------*/
/*
tIORecvData[0] = 0; */ /* Estacion 3 segundo octeto entradas */
/* "1" Emergencia*/
/* "2" Marcha*/
/* "4" Ind_Int*/
/* "8" Borrar/Reset*/
/* "16" Manual_automatico*/
/*
tIORecvData[1] = 0; */ /* Estacion 3 primer octeto entradas */
/* "1" Cinta_atras */
/* "2" Cinta_adelante */
/* "4" Gira_izq */
/* "8" Gira_drcha */
/* "16" Pinza_arriba */
/* "32" Pinza_abajo */
/* "64" Cargador */
/*
tIORecvData[2] = 0; */ /* Transporte segundo octeto entradas */
/* "1" Palet_estacion1 */
/* "2" Palet_estacion2 */
/* "4" Palet_estacion3 */
/* "8" Palet_estacion4 */
/* "16" Desvio */
/* "32" Paro_intermedio */
/* "64" Emergencia */
/*
tIORecvData[3] = 0; */ /* Transporte primer octeto entradas */
/* "1" Marcha */
/* "2" Ind_int */
/* "4" Borrar */
/* "8" Manual_Automatico */
/* "16" NO CABLEADO */
/* "32" NO CABLEADO */
/* "64" NO CABLEADO */
/* "128" NO CABLEADO */
/*
tIORecvData[4] = 0; */ /* Estacion 1 primer modulo */
/* "1" Cinta_atras */
/* "2" Cinta_adelante */
/* "4" Pinza izq */
/* "8" Pinza drcha */
/* "16" Pinza arriba */
/* "32" Pinza abajo */
/* "64" Cargador adelante */
/* "128" Cargador atras */
/*
tIORecvData[5] = 0; */ /* Estacion 1 segundo modulo */
/* "1" Emergencia */
/* "2" Marcha */
/* "4" Manual automatico */
/* "8" Ind int */
/* "16" Borrar/Reset */
/* "32" Capacitivo camisa */
/* "64" Optico camisa */
/* "128" Inductivo camisa */
/*
tIORecvData[6] = 0; */ /* Estacion 1 tercer modulo */
/* "1" Lector adelante */
/* "2" Lector atras */
/* "4" Optico lector */
/*
tIORecvData[9] = 0; */ /* Estacion 4 primer modulo */
/* "1" Verificador_abajo */
/* "2" Verificador_arriba */
/* "4" Gira_drcha */
/* "8" Gira_izq */
/* "16" Cilindro_arriba */
/* "32" Cilindro_abajo */
/* "64" Vacio_pinza */
/* "128" Emergencia */
/*
tIORecvData[10] = 0; */ /* Estacion 4 segundo modulo */
/* "1" Marcha */
/* "2" Borrar */
/* "4" Ind_int */
/* "8" Manual_automatico */
/* "16" Pinza_fuera */
/* "32" Sacar_Pieza */
/* "64" Vacio_Pieza */
/* "128" Vascula_pieza */
/*
tIORecvData[12] = 0; */ /* Medidor analogico del bastago */
Figura E.7. Definiciones de las variables de entrada del programa
Carlos Mediavilla Martí
83
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Ahora se revela claramente el porque de asignar un número a cada variable. Dicho número sirve para
hacer coincidir la variable Java con la variable C, que en realidad no es una variable booleana “tal cual”,
sino una variable del tipo T_IBS_BOOL definido en las librerías del fabricante de la tarjeta. Por tanto es
imprescindible para un correcto funcionamiento del programa la correspondencia total entre la asignación
de números en la clase Java y en la función C. De igual forma se implementan las funciones específicas de
la finalización e inicialización:
JNIEXPORT jboolean JNICALL Java_comunicaciones_Interbus_inicializaCelula(JNIEnv *env,
jobject obj)
{
short num;
num = AperturaDriver();
if (num != DRV_NO_ERROR)
{
printf ("Error en la apertura del driver%5d\n", num);
return false;
}
num = InicializaTargeta();
if (num != DRV_NO_ERROR)
{
printf ("Error en la inicializacion de la targeta%5d\n", num);
return false;
}
Inicializa_vector_Salidas();
return true;
}
JNIEXPORT void JNICALL Java_comunicaciones_Interbus_finalizaCelula(JNIEnv *env,
jobject obj)
{
short num;
Inicializa_vector_Salidas();
num = DevExitBoard(numeroTargeta);
if (num != DRV_NO_ERROR)
{
printf ("Error en la finalizacion de la targeta%5d\n", num);
}
num = DevCloseDriver();
if (num != DRV_NO_ERROR)
{
printf ("Error en el cierre del driver%5d\n", num);
}
}
El programa hace uso de funciones C definidas e implementadas dentro de las librerías que suministra
el fabricante y no es necesario saber nada acerca de su funcionamiento interno. Estas funciones se hacen
accesibles a través de las etiquetas:
#include
#include
#include
#include
#include
#include
#include
"./codigocom2.h"
<stdlib.h>
<stdio.h>
<string.h>
<fcntl.h>
"/usr/java/jdk1.5.0_05/include/jni.h"
<linux/kd.h>
Carlos Mediavilla Martí
84
20/07/06
Anexo E. Tecnología Java
El programa C debe contener al menos estos enlaces: un enlace a las librerías jni, un enlace al fichero
de cabecera correspondiente (que hemos conseguido en el paso 3) y el enlace a la librería de funciones del
fabricante de la tarjeta que son la que realizarán todo el trabajo interno de gestión de las comunicaciones
entre la tarjeta y la estación.
Las funciones nativas que se usan en el código se basan en las funciones que suministran las
bibliotecas del fabricante, y la implementación interna que proporcionan dicha bibliotecas es la que
gestiona las comunicaciones entre la tarjeta y los módulos.
Paso 5: Crear una librería compartida:
Una vez se ha terminado la implementación de las funciones en C (codigocom2.c) se debe compilar el
resultado dentro de una librería dinámica, es decir, un archivo .so con un prefijo lib para Linux, primero se
compila a código objeto *.o y a partir de él la librería. Los comandos para la creación de una librería a
partir del archivo.o y que incluye librerías dentro de los paths que siguen con una –I son los siguientes:
gcc –c *.c => generación archivo *.o
gcc –o lib*.so –shared –Wl –I/usr/local/java/include/ -I/usr/local/java/include/linux/
archivo.o –static –lc => generación archivo *.so
Este archivo es el que se carga en la clase Java al ejecutarse y se genera a partir de nuestro código .c
con el cual generamos el archivo .o y además hay que añadir la API de la tarjeta CIF-50 llamada cif_api.o.
/* Carga de la librería dinámica que contiene la implementación de los
métodos nativos y de las funciones especificas de control de la tarjeta,
incluida con el software HLI
*/
static
{
System.loadLibrary("Interbus");
}
libInterbus.so es el archivo resultante de la compilación del archivo en que están contenidas las
implementaciones de las funciones nativas. Es muy importante tener en cuenta que solo se debe cargar la
librería una sola vez, aunque en otras clases de la aplicación también se utilicen funciones definidas en
esta biblioteca.
Carlos Mediavilla Martí
85
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
ANEXO F. SERVIDOR WEB
El objetivo de este anexo es explicar como montar el servidor Web con soporte para Servlets de Java y
páginas JSP. Se ha elegido la combinación Tomcat sobre un sistema Linux (Red Hat 9 en concreto)
Las versiones usadas han sido los siguientes:
•
Tomcat 5.0.12 Beta.
•
Linux Red Hat 9 (Aunque supongo que lo explicado valdrá en cualquier Linux, incluso en
cualquier sistema operativo para el que esté disponible Tomcat)
Se presupone que el SDK de java ya se encuentra instalado en el sistema. Si no es el caso, se puede
instalar de la siguiente forma:
Descargar el SDK oficial en http://java.sun.com/j2se/1.4.2/download.html. Después añadir el directorio
bin de la instalación de java al path del sistema. Para ver si todo está correcto, comprobar que el shell
reconoce el comando java.
F.1. Instalando Tomcat
Lo primero que tenemos que hacer es bajarnos el Tomcat de la página oficial de Apache
(http://jakarta.apache.org/site/binindex.cgi) en la cual deberemos buscar la última versión del Tomcat y
bajárnoslo (Hay que tener en cuenta que en dicha página vienen los descargables de todos los proyectos de
Jakarta, hay que buscar hasta encontrar la última versión de Tomcat). Si se quiere compilar a partir del
código fuente, la dirección es: (http://jakarta.apache.org/site/sourceindex.cgi )
Una vez descargado, copiamos el archivo al directorio donde vayamos a instalar Tomcat. Yo lo copié
al directorio /home/carlos, pero se puede copiar donde se quiera. Descomprimir el archivo y le cambiamos
el nombre al directorio que se haya creado por otro más manejable, por ejemplo tomcat (no es necesario,
es por comodidad). A partir de ahora llamaré a dicho directorio $CATALINA_HOME, por seguir la
documentación oficial de Tomcat (CATALINA_HOME = directorio de instalación de Jakarta-Tomcat)
Ahora hay que añadir la variable JAVA_HOME al sistema, apuntando al directorio donde este instalado
el java (Para que el Tomcat sepa donde buscar el java). Después hay que ir al directorio
$CATALINA_HOME/bin. En este directorio están los scripts para arrancar (startup.sh) y parar
(shutdown.sh) el servidor. También se encuentran los ejecutables para Windows (los .exe y los .bat), que
se puedan borrar directamente (Si por alguna razón se esta usando Windows, pues entonces se borran los
.sh). Para comprobar que todo ha ido correctamente, se puede ejecutar el script startup.sh y acceder a
http://localhost:8080/ desde cualquier navegador:
[root@servidor1 bin]# ./catalina.sh run
Using CATALINA_BASE:
/usr/local/tomcat
Using CATALINA_HOME:
/usr/local/tomcat
Using CATALINA_TMPDIR: /usr/local/tomcat/temp
Using JAVA_HOME:
/usr/local/jdk
Si todo ha ido bien, se debería ver la página principal de Tomcat (puede que el Tomcat tarde un poco
en arrancar. Si inicialmente no se conecta al puerto 8080, hay que darle a recargar en el navegador y
probar de nuevo)
Carlos Mediavilla Martí
86
20/07/06
Anexo F. Servidor Web
F.2. Configuración
Server.xml es el archivo principal de configuración para Tomcat, al igual que otros archivos de
configuración para productos empleados en servidor puede contener una gran variedad de parámetros, sin
embargo, este resumen se concentrará en los parámetros principales.
Validación, <!-- --> y valores "Default":
El archivo server.xml es un archivo en XML, el cual de no contener una estructura conforme a XML,
se indicará al arranque de Tomcat; dicho archivo se encuentra bajo el directorio /home/carlos/tomcat/conf
donde /home/carlos/tomcat es el directorio definido en CATALINA_HOME.
Como cualquier otro documento en XML todo contenido entre <!-- --> es considerado un comentario,
y por lo tanto cualquier parámetro que se encuentre entre estos caracteres no es utilizado por "Tomcat";
aquellos parámetros que no sean definidos dentro de server.xml son asignados un valor "Default" por
Tomcat.
<Server> - </Server>:
<Server> es el elemento principal del archivo server.xml y todas las demás secciones deben encontrarse
entre estos nodos; el atributo port indica el puerto TCP donde se espera la señal de cierre (shutdown) de
Tomcat, el cual rara vez es modificado.
<Listener>:
A través de los elementos <Listener> se configuran las extensiones JMX ("Java Management
Extensions") que serán utilizadas por Tomcat, dichos elementos toman dos atributos: className que indica
la clase diseñada para escuchar sobre eventos JMX y debug para especificar el nivel de "debug" generado
al tiempo de ejecución.
<GlobalNamingResources> , <Resource> y <ResourceParams>:
Anidado dentro de los elementos <GlobalNamingResources> es posible definir recursos JNDI para ser
utilizados globalmente en Tomcat. Lo anterior evita que estos recursos tengan que ser declarados a nivel
de WAR de manera individual.
A través de <Resource> es como define el tipo de recurso JNDI que será utilizado y mediante
<ResourceParams> se especifican los parámetros específicos que tomará el recurso en dicha instancia de
Tomcat.
<Service> - </Service>:
Este parámetro permite configurar Tomcat para diferentes modalidades de ejecución, en el archivo
server.xml "Default" se definen dos modalidades a través del atributo name; la definición asignada
name="Catalina" es empleada para ejecutar Tomcat individualmente.
<Connector>:
El elemento Connector representa las conexiones (Puertos TCP) que serán abiertas por Tomcat al
arranque, a su vez dentro de cada elemento Connector se definen diversos atributos los cuales dan más
detalles acerca de la conexión.
El elemento Connector más importante es aquel que define la clase: HttpConnector.
Carlos Mediavilla Martí
87
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
<Connector port="8080"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />
La declaración anterior indica que Tomcat esta dispuesto a dar respuesta a requisiciones que lleguen en
el puerto 8080 del "Host" donde esta instalado Tomcat; si recuerda la ejecución y pruebas de Tomcat a
esto se debió el agregar el fragmento :8080.
Para ambientes de producción en los cuales toda requisición será atendida por Tomcat el parámetro port
de este elemento debe ser modificado al valor de 80, este puerto es el ampliamente conocido puerto TCP
80 con el que intenta comunicarse cualquier Navegador ("Netscape", "Explorer", "Opera" u otro) en
Internet.
Otras declaraciones para Connectors son aquellas para utilizar encriptación (HTTPS) y los conectores
AJP; la configuración de HTTPS es un tanto extensa y no se describirán los detalles, sin embargo, los
conectores AJP son aquellos utilizados para la comunicación entre Apache y Tomcat y son los siguientes:
<Connector port="8009"
enableLookups="false" redirectPort="8443" debug="0"
protocol="AJP/1.3" />
Esta declaración indica que el puerto 8009 estará recibiendo conexiones bajo AJP13, lo anterior es solo
de interés si utiliza Apache en conjunción con Tomcat.
<Engine> - </Engine>:
Los elementos <Engine> los cuales deben encontrarse anidados dentro de <Service> representan el
mecanismo que atenderá toda solicitud llegada Tomcat, esto es, toda solicitud recibida por las definiciones
Connectors será procesada por <Engine>, los atributos de este elemento son los siguientes:
<Engine name="Catalina" defaultHost="localhost" debug="0">
defaulthost representa el nombre del servidor Tomcat mientras debug indica el nivel de "debug" generado
al tiempo de ejecución.
<Logger> - </Logger>:
Los elementos Logger le indican a Tomcat hacia donde deben ser enviados los registros "Logs":
<Logger className="org.apache.catalina.logger.FileLogger"
directory="logs" prefix="localhost_log." suffix=".txt"
timestamp="true"/>
Lo anterior indica que los registros de Tomcat deben ser enviados al archivo localhost_log.txt; la
ubicación de este registro ("log") puede ser modificada al nivel de los elementos Host los cuales permiten
definir Virtual Hosts.
Carlos Mediavilla Martí
88
20/07/06
Anexo F. Servidor Web
<Host> - </Host>:
Los elementos Host permiten definir varios Hosts "Virtuales" para Tomcat, esto es, a través del
elemento <Engine> se define un sitio (localhost) para atender solicitudes, a través de Host es posible
definir diversos sitios "Virtuales", su configuración es la siguiente:
<Host name="desarrollo.servidorprueba.com" debug="0" appBase="webapps"
unpackWARs="true">
Lo anterior indica que el sitio desarrollo.servidorprueba.com contiene las aplicaciones (Archivos WARS)
bajo el directorio $CATALINA_HOME/webapps, donde $CATALINA_HOME es /home/carlos/tomcat; el
atributo unpackWARs le indica a Tomcat que debe descomprimir los archivos WAR's al arranque.
Como ya fue mencionado, dentro de estos elementos <Host> es posible utilizar <Logger> para generar
registros ("logs") por cada sitio virtual.
Context:
Context es un elemento utilizado para indicar la ubicación de las aplicaciones ejecutadas en Tomcat, en
su configuración "Default" estas aplicaciones se encuentran dentro del directorio webapps bajo el directorio
raíz de Tomcat ( /home/carlos/tomcat ). El entrar en los detalles de Context seria un tanto prematuro ya que
aún no se ha descrito que es una aplicación en Tomcat.
<Context path="/WebCelula" reloadable="true"
docBase="/home/carlos/workspace/WebCelula"
workDir="/home/carlos/workspace/WebCelula/work" />
Una aplicación en Tomcat o cualquier Servlet Engine (Web-Container) es un conjunto de "JSP's (Java
Server Pages)" y/o "Servlets" agrupados con ciertos parámetros de arranque y seguridad, este conjunto de
archivos / aplicación en todo Servlet Engine es conocido como un WAR (Web-Archive)
F.3. Estructura de directorios
La aplicación web desarrollada se encuentra en el directorio /webapps con el nombre webCelula. Esto
quiere decir que puede ser accedida a través de la siguiente URL: http://155.210.154.239:8080/webCelula
La estructura de la aplicación en Tomcat es la siguiente:
•
/ *.html *.jsp *.css: Este directorio base contiene los elementos que comúnmente son utilizados en
el sitio, documentos en HTML , JSP's , CSS ("Cascading Style Sheets") y otros elementos.
•
/WEB-INF/web.xml: Contiene elementos de seguridad de la aplicación así como detalles sobre
parámetros de los Servlets que serán utilizados dentro de la misma.
•
/WEB-INF/classes/ : Contiene las clases Java adicionales a las del JDK que serán empleadas en
los JSP's y Servlets
•
/WEB-INF/lib/ : Contiene los JAR's que serán utilizados por la aplicación.
Este tipo de estructura permite portabilidad a las diversas aplicaciones que son desarrolladas en Java.
Carlos Mediavilla Martí
89
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
F.4. Trabajar con servlets
Ahora vamos a crear un Servlet que sirve de ejemplo para los desarrollados en la aplicación de control
de la célula. Primero tenemos que añadir al CLASSPATH de java las bibliotecas de Servlets que nos
proporciona el Tomcat. Para eso añadimos el directorio $CATALINA_HOME/common/lib/servlet-api.jar a
la variable de entorno anteriormente mencionada (ojo, $CATALINA_HOME, representa el directorio
donde este instalado el Tomcat). Una vez preparado todo, pasamos a escribir nuestro ejemplo, que será el
típico HolaMundo. El código concreto es:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HolaMundo extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("");
out.println("");
out.println("Prueba");
out.println("");
out.println(" ¡Hola mundo! ");
out.println("");
}
}
Se compila el fichero HolaMundo.java y se obtiene el .class. Ahora hay que montar la estructura de
directorios propia de un Servlet, acorde a la especificación oficial de SUN. Dicha estructura es la
siguiente:
o
Nombre_de_la_aplicación (webCelula)
• META-INF (en este proyecto no se usa)
• WEB-INF (Aquí incluimos el archivo web.xml, del que ya hablaremos)
ƒ classes (para guardar los archivos compilados)
ƒ src (opcional, para guardar las fuentes)
ƒ lib (contendrá los .jar externos. No lo usaremos)
Esta estructura básica la crea por defecto Eclipse cuando se crea un proyecto Web. Posteriormente
tenemos que editar el archivo web.xml, que dijimos antes. Este archivo es el que describe a nuestra
aplicación. En nuestro caso (este ejemplo) debe ser el siguiente:
<?xml version="1.0" encoding="ISO-8859-15"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<servlet>
<servlet-name>prueba</servlet-name>
<servlet-class>HolaMundo</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>prueba</servlet-name>
<url-pattern>hola</url-pattern>
</servlet-mapping>
</web-app>
Carlos Mediavilla Martí
90
20/07/06
Anexo F. Servidor Web
En servlet-name se indica el nombre de la aplicación y se hace coincidir con el directorio donde la
tenemos guardada (aquel cuyo contenido estamos creando ahora). En servet-class ponemos la clase
principal de nuestra aplicación y en url-pattern la dirección desde la cual accederemos al servlet. Para más
información consultar la documentación oficial.
El contenedor Web puede abrir y administrar múltiples servlets dentro de la misma máquina virtual
Java. Una vez se ha abierto un servlet, administra cada solicitud entrante generando un nuevo thread para
realizar su tarea. Esto permite al servidor de aplicación atender un elevado número de solicitudes sin una
degradación significativa de su rendimiento.
Reiniciamos el Tomcat (usando los scripts shutdown.sh y startup.sh comentados antes). Para
comprobar que todo va bien accedemos a http://localhost/prueba/hola (Si se ha usado otro url-pattern u
otro servlet-name la dirección general es “http://localhost/$servlet-name/$url-pattern“). Si todo ha ido
bien, se debería ver el consabido “ ¡ Hola Mundo ! ”.
LISTADO DE SERVLETS DEL PROYECTO:
Jerarquía de clases:
o
java.lang.Object
o
javax.servlet.GenericServlet (implements java.io.Serializable, javax.servlet.Servlet,
javax.servlet.ServletConfig)
o
javax.servlet.http.HttpServlet (implements java.io.Serializable)
o
servlets.AutoEstacion3Servlet
o
servlets.AutomaticoServlet
o
servlets.LoginServlet
o
servlets.LogoutServlet
o
servlets.ManualServlet (implements gui.comun.DatosGraficos)
o
servlets.PedidosServlet
o
servlets.SupervisionServlet (implements gui.comun.DatosGraficos)
Resumen de clases
AutoEstacion3Servlet
Servlet encargado de procesar las peticiones para el control automático de la
estación 3.
AutomaticoServlet
Servlet encargado de procesar las peticiones para el control global de la célula.
LoginServlet
Servlet responsable de la autenticación de usuario.
LogoutServlet
Servlet responsable de ejecutar acciones de limpieza al salir de la aplicación.
ManualServlet
Servlet encargado de procesar las peticiones para el control manual de la célula.
PedidosServlet
Servlet encargado de procesar las peticiones para la gestión de pedidos.
SupervisionServlet
Servlet encargado de procesar las peticiones para la supervisión de las estaciones
de la célula.
Carlos Mediavilla Martí
91
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
F.5. Paginas JSP
JSP (JavaServer Pages) es una tecnología que permite incluir código Java en páginas web. El
denominado contenedor JSP (que sería un componente del servidor web) es el encargado de tomar la
página, sustituir el código Java que contiene por el resultado de su ejecución, y enviarla al cliente. Así, se
pueden diseñar fácilmente páginas con partes fijas y partes variables.
Para ejecutar una página JSP basta con colocarla en una aplicación web (por ejemplo, en Tomcat,
dentro de webapps/ROOT). No es necesario que sea en un directorio específico como ocurre con los
servlets, sino que puede ir en cualquier directorio en el que se colocaría normalmente un HTML.
Aunque JSP y servlets parecen a primera vista tecnologías distintas, en realidad el servidor web traduce
internamente el JSP a un servlet, lo compila y finalmente lo ejecuta cada vez que el cliente solicita la
página JSP. Por ello, en principio, JSPs y servlets ofrecen la misma funcionalidad, aunque sus
características los hacen apropiados para distinto tipo de tareas. Los JSP son mejores para generar páginas
con gran parte de contenido estático. Un servlet que realice la misma función debe incluir gran cantidad de
sentencias del tipo out.println() para producir el HTML. Por el contrario, los servlets son mejores en tareas
que generen poca salida, datos binarios o páginas con gran parte de contenido variable. En proyectos más
complejos, lo recomendable es combinar ambas tecnologías: los servlets para el procesamiento de
información y los JSP para presentar los datos al cliente.
LISTADO DE PÁGINAS JSP DEL PROYECTO:
Página JSP
Descripción
Estructura del diseño de la aplicación para el control automático de la
estación 3
automaticoEstacion3_control Pantalla principal para el control automático de la estación 3
Estructura del diseño de la aplicación para el control automático
automaticoGlobal
global de la célula
Página de introducción
bienvenida
Página con datos de los clientes conectados a la aplicación
conexión_clientes
Pantalla con detalles del estado del servidor
conexión_detalles
Página con información detallada de la estación 3
detalleEstacion
Página para la presentación de errores en tiempo de ejecución
error
Pantalla que muestra el estado de una estación en el modo automático
estacion
Pantalla de mando para el control automático de la célula
globalTop
Página de autenticación de usuario
login
Página de salida de la aplicación
logout
Página para el control manual de una estación
manual
Pantalla con el menú de opciones para la aplicación
menú
Estructura del diseño de la página de pedidos
pedidos
Pantalla para la gestión de pedidos (creación , cancelación, …)
pedidos_control
Pantalla que muestra con detalle el pedido seleccionado
pedidos_detalle
Pantalla que muestra una lista con todos los pedidos de la célula
pedidos_lista
Estructura del diseño de la aplicación global
principal
Estructura del diseño de los elementos de la parte izquierda
principal_izda
Pie de página de la aplicación
principal_pie
Encabezado de página de la aplicación
principal_top
Estructura del diseño de la página de supervisión
supervisión
Pantalla que muestra el estado de los sensores y salidas de una
supervisionCentro
estación
Pantalla para la gestión de los tiempos de actualización
supervisionTop
automaticoEstacion3
Carlos Mediavilla Martí
92
20/07/06
Anexo G. Aplicaciones
ANEXO G. APLICACIONES (MANUAL DE USUARIO)
Aunque la aplicación principal del proyecto sea el control global de la célula de fabricación, para su
realización ha sido necesario implementar una serie de pequeñas aplicaciones, ya sea como prototipo para
una aplicación más compleja o para probar funcionalidades problemáticas de la célula, tales como el
identificador de productos o el funcionamiento individual de cada estación. Muchas de ellas poseen un
cierto interés por lo que se va a presentar un breve resumen de ellas a continuación.
El listado de las aplicaciones de control en tiempo real desarrolladas (del lado del servidor) y los
scripts (que lanzan el intérprete jamaica) necesarios para ejecutarlas son las siguientes:
Script (*.sh)
Aplicación
servidorEstacion1IndJamaica
Control automático de la estación 1
servidorEstacion3IndJamaica
Control automático de la estación 3
servidorEstacion4IndJamaica
Control automático de la estación 4
servidorCelulaCenJamaica
Control centralizado de la célula
servidorCelulaDesJamaica
Control descentralizado de la célula
servidorCelulaDisLocalAJamaica
Control distribuido
opción A)
Control distribuido
opción B)
Control distribuido
opción A)
Control distribuido
opción B)
servidorCelulaDisLocalBJamaica
servidorEstacion3DisAJamaica
servidorEstacion3DisBJamaica
de la célula (servidor principal
de la célula (servidor principal
de la célula (servidor estación 3
de la célula (servidor estación 3
Darse cuenta que la ejecución de la aplicación de control global de la célula se puede configurar de 3
maneras: centralizada, descentralizada y distribuida.
Para ello, los programas que realizan el control en tiempo real cargan las RdP correspondientes a cada
una de las estaciones y la de los coordinadores global y borrar, crean los monitores para cada estación,
inicializan la comunicación con el bus Interbus y los comunicadores Ethernet y también arrancan la
ejecución de los coordinadores. Además, también efectúan el papel de servidor de datos de la aplicación,
registrándose como servidores RMI permitiendo la comunicación con el cliente, que puede ser otro
programa Java o la aplicación que esta ejecutándose en el servidor web.
Hay que tener cuidado sobre todo con tener muy claro donde tenemos todos los componentes
necesarios para que el programa funcione, ya que es muy sencillo que el programa no se ejecute debido a
que la máquina virtual Jamaica no encuentra alguno de los archivos o clases necesarios para el buen
funcionamiento del programa.
Antes de arrancar cualquiera de las aplicaciones hay que realizar una serie de comprobaciones:
•
Que los módulos de entradas / salidas de las estaciones estén adecuadamente conectados a una
de las redes (Interbus o Ethernet) de la célula.
•
Conectar el cable que viene del identificador de productos de la célula al puerto serie COM1.
•
Para un correcto funcionamiento de la aplicación hay que desconectar el autómata 5 de la red
Ethernet, sino dicho autómata permanece como ‘maestro’ de los comunicadores Ethernet
Carlos Mediavilla Martí
93
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
interfiriendo con el programa de control.
•
Para el caso concreto del bus Interbus es además necesario inicializarlo y comprobar que
funciona, esto se hace en dos pasos, primero hay que cargar en memoria la librería dinámica
que contiene las funciones nativas para comunicarse con Interbus:
o
Ejecutar ./cif_load el cual esta situado en /home/carlos/cif-v2.100/drv
o
Después hay que arrancar el programa de configuración, ejecutando ./drvSu el cual
esta situado en /home/carlos/cif-v2.100/test, aparece la siguiente pantalla:
Figura G.1. Inicialización de la tarjeta Interbus
o
Pinchar en la etiqueta: Board 0 para inicializar la tarjeta y luego comprobar que todo va bien y
no aparece ningún error (típicamente el error -21) en la pestaña de Exchange I/O, como se ve
en la siguiente figura donde cada par de cifras representa un octeto del módulo de entradas /
salidas correspondiente:
Figura G.2. Comprobación funcionamiento de la tarjeta Interbus
Carlos Mediavilla Martí
94
20/07/06
Anexo G. Aplicaciones
•
Cuando se quiere ejecutar la aplicación distribuida, primero hay que arrancar el servidor
principal y luego el servidor de la estación 3 correspondiente.
•
Después de arrancar cualquiera de las aplicaciones de control de la célula, también hay que
arrancar el programa que accede al puerto serie con el script puertoSerie.sh. Esto es debido a
que la máquina virtual Jamaica no soporta los eventos del puerto serie, ver figura G.3
RMI
Control Tiempo Real
Jamaica VM
Servidor RMI
javax.comm
Puerto serie
Sun VM
Cliente RMI
RS-232
Identificador
Productos
Estación
Control
Tiempo Real
LINUX
Figura G.3. Comunicación vía serie con el identificador de productos
tiger:~/workspace/PFC2006Client/ ./puertoSerie.sh
aplicacion.ServidorCelulaCen_Stub
Tiempo de lookup: 373
Puerto serie abierto... /dev/ttyS0
Canales de salida y entrada OK
setSerialPortParams ok
No hay nada que enviar al puerto serie
…
•
export
export
export
export
export
export
export
Si el programa se traslada a otra máquina, hay que definir las siguientes variables de entorno:
PATH=$PATH:/usr/java/jdk1.5.0_05/bin
JAVA_HOME=/home/carlos/jre1.5.0_05
CATALINA_HOME=/home/carlos/tomcat
JAMAICA_HOME=/usr/local/jamaica
JAMAICAVM_NUMTHREADS=30
JAMAICA_BUILDER_HEAPSIZE=164M
LD_LIBRARY_PATH=/home/carlos/commapi/lib
La mayoría de las aplicaciones del proyecto generan una serie de salidas en la ventana de comandos
que permiten comprobar la correcta ejecución de la aplicación, entre ellas destacan el proceso de creación
de las redes de Petri, la evolución de la ejecución de una red de Petri y tiempos de ciclo de los
coordinadores, como se puede observar en las siguientes capturas.
Carlos Mediavilla Martí
95
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Salida por consola del inicio de la ejecución de servidorEstacion3DisBJamaica:
RED CONSTRUIDA...............
Connecting to '155.210.154.216'
Successfully connected to '155.210.154.216' <155.210.154.216>
servidorCelula.getClass().getName(): aplicacion.ServidorCelulaDisLocalB_Stub
Tiempo de lookup ServidorCelula: 265
servidorCelula.getClass().getName(): control.distribuido.LugarComunicacionLocal_Stub
Tiempo de lookup LugarComunicacion 144: 149
servidorCelula.getClass().getName(): control.distribuido.LugarComunicacionLocal_Stub
Tiempo de lookup LugarComunicacion 301: 95
ServidorEstacion3 distribuido B OK
COMIENZA EJECUCION COORDINADOR: estacion 3 MEDIANTE TRANSICIONES
SENSIBILIZADAS
…
Información sobre el proceso de lectura/escritura del identificador de productos:
…
Identificador ADQUIRIDO
Disparo Transicion T7
Casi fin de enviarTrama. Imprimo la trama almacenada:
119 49 48 48 49 53 110 3
Identificador leyendo en estacion 1
El cliente del puerto serie se lleva la trama...
Datos del palet recibidos:
119 48 48 50 51 53 52 49 50 50 52 48 53 50 48 48 54 -1 70 70 70 70 70
70 62 3
Última modificación del palet: 24 de Junio de 2006 a las 12:54:23
Características:
Camisa: false
Pieza con tapa: false
Embolo: false
Culata: false
Muelle: false
Identificador LIBERADO
Palet leido del identificador por coor estacion 1
Disparo Transicion T6
…
Informe de tiempos cuando termina la ejecución de las redes de Petri:
…
Disparo Transicion T34
Coordinador Celula detenido
Coordinador Borrar detenido
Coordinador Estacion 1 detenido
Coordinador Estacion 3 detenido
Coordinador Estacion 4 detenido
FINAL DEL COORDINADOR: Celula
Numero de ciclos ejecutados: 703
Duracion acumulada de todos los ciclos: 41 ms
Duracion media de un ciclo del coordinador 0.05
FINAL DEL COORDINADOR: Estacion 1
Numero de ciclos ejecutados: 404
Duracion acumulada de todos los ciclos: 22 ms
Duracion media de un ciclo del coordinador 0.05
FINAL DEL COORDINADOR: Estacion 3
Numero de ciclos ejecutados: 226
Duracion acumulada de todos los ciclos: 7 ms
Duracion media de un ciclo del coordinador 0.03
FINAL DEL COORDINADOR: Estacion 4
Numero de ciclos ejecutados: 55
Duracion acumulada de todos los ciclos: 2 ms
Duracion media de un ciclo del coordinador 0.03
Carlos Mediavilla Martí
96
ms
ms
ms
ms
20/07/06
Anexo G. Aplicaciones
Hay que tener especial consideración en la configuración de la maquina virtual Jamaica. Por ejemplo,
para establecer prioridades estrictas hay que añadir estas líneas en el script deseado:
export
JAMAICAVM_PRIMAP=1..11=1,12..14=2,15..17=2,18..20=3,21..23=4,24..26=5,27..29=6,30..32
=7,33..35=8,36..38=9,39=10;
export JAMAICA_SCHEDULING=FIFO
Las siguientes variables de entorno también juegan un papel importante en el comportamiento de la
máquina virtual Jamaica:
CLASSPATH: Ruta donde busca los archivos de clases.
JAMAICA_SCHEDULING: Política de planificación de los hilos nativos:
OTHER –- Planificador por defecto
RR
-- Round Robin
FIFO -- FIFO
JAMAICAVM_HEAPSIZE: Tamaño del ‘heap’ en bytes (e. g., 1M). Por defecto: 62914560
JAMAICAVM_JAVA_STACKSIZE: Tamaño de la pila de Java en bytes (e. g., 5k). Por
defecto: 65536
JAMAICAVM_NATIVE_STACKSIZE: Tamaño de la pila native en bytes (e. g., 5k). Por
defecto: 65536
JAMAICAVM_NUMTHREADS: Máximo número de Java threads. Por defecto: 30
JAMAICAVM_PRIMAP: Correspondencia de mapeo desde threads de Java a hilos natives.
JAMAICAVM_IMMORTALSIZE: Tamaño de la memoria inmortal. Por defecto: 32768
JAMAICAVM_LAZY: Carga las clases dinamicamente (1) o carga/enlace todas las clases en
el arranque (0). Por defecto: 1
JAMAICAVM_STRICTRTSJ: Usar la especificación RTSJ estricta (1) o las reglas relajadas
de Jamaica (0). Por defecto: 0
Uno de los errores más comunes que pueden aparecer a la hora de ejecutar el programa es el siguiente,
que ocurre cuando el library path de Java no está bien configurado:
java.lang.UnsatisfiedLinkError: no Interbus in shared library path
at java.lang.Runtime.loadLibrary(Runtime.java)
at java.lang.System.loadLibrary(System.java)
at java.lang.Thread.init(Thread.java)
Para solucionarlo hay que conseguir que aparezcan en el library path los directorios donde se
almacenan las clases java y la librería dinámica.
Para evitar que la pantalla se llene de errores se pueden introducir todos los errores producidos en el
lanzamiento de un programa en java al archivo a un archivo de errores:
servidorCelulaDisLocalAJamaica 2> errors.txt
Carlos Mediavilla Martí
97
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
G.1. Control independiente de la estación 1
El cliente gráfico para la aplicación de control automático y manual de la estación 1 se arranca con el
siguiente script:
¾
clienteEstacion1.sh
Nada más ejecutarla aparece la siguiente pantalla gráfica:
Figura G.4. Interfaz gráfico para el control de la estación 1
El programa que genera la interfaz de usuario Java crea un panel de control desde donde se puede
manejar la ejecución de la red de Petri: se puede lanzar la ejecución del coordinador, detenerlo,
continuarlo y lanzar la visualización de la red de Petri en ejecución. Además existen paneles adicionales
de supervisión que permiten conocer en tiempo real:
•
•
•
•
El valor de cada uno de los sensores de la estación (entradas)
El estado de los accionadores de la estación (salidas)
La red de comunicaciones empleada para acceder al módulo I/O de la estación.
El estado general de la estación:
o Funcionado. Cuando el coordinador correspondiente se esta ejecutando.
o Produciendo. Cuando el coordinador esta en la parte de producción.
o Emergencia. Si existe alguna emergencia.
Adicionalmente, en el caso de esta estación, existe un selector que permite elegir la pieza que se va a
producir.
Carlos Mediavilla Martí
98
20/07/06
Anexo G. Aplicaciones
G.2. Control independiente de la estación 3
En este caso se han desarrollado los dos clientes: Java y Web. La pantalla de la aplicación Web se
puede ver en la figura 6.4 de la memoria y tiene una funcionalidad similar a la interfaz Java que se
presenta aquí. Todas las funciones se utilizan de forma intuitiva y facilitan el control de los procesos.
El cliente para la aplicación de control de la estación 3 se arranca con el siguiente script:
¾
clienteEstacion3.sh
Nada más ejecutarla aparece una ventana que pide la dirección IP donde se esta ejecutando el servidor:
Figura G.5. Ventana dirección IP del servidor
Posteriormente se presenta la pantalla principal de la aplicación:
Figura G.6. Interfaz gráfico para el control de la estación 3
Carlos Mediavilla Martí
99
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
La funcionalidad es exactamente similar a la de la aplicación para la estación 1. Al igual que sucedía en
la anterior aplicación, cuando se pulsa el botón ‘ver red de Petri’ aparece la red de Petri de la estación
correspondiente dibujada sobre un panel:
Figura G.7. Visualización de la red de Petri de la estación 3
Se pueden ver datos muy útiles para el seguimiento de la ejecución, como por ejemplo, el número de
marcas que cada estado tiene en un determinado momento (representadas por puntos de color azul), el
tiempo que lleva activo cada lugar (en milisegundos), las transiciones sensibilizadas (remarcadas de color
verde), el lugar representativo de cada transición (deshabilitado por defecto), etc. Además cuenta con una
útil herramienta de zoom (que permite para ver la red en su totalidad o detalles de la misma), barras de
desplazamiento y botones de configuración de la visualización para no perder detalle.
Carlos Mediavilla Martí
100
20/07/06
Anexo G. Aplicaciones
G.3. Control independiente de la estación 4
El cliente para la aplicación de control de la estación 4 se arranca con el siguiente script:
¾
clienteEstacion4.sh
Después de la ventana que pide la IP del servidor aparece la pantalla de la aplicación principal:
Figura G.8. Visualización de la red de Petri de la estación 4
La funcionalidad es muy similar a la de la aplicación para la estación 4. En el panel de entradas se
muestra el estado de cada uno de los sensores de la máquina, si el sensor esta activo se representa con el
símbolo , y si esta inactivo con . El panel de salidas, además de contener un conjunto de botones con
los que se pueden activar o desactivar los accionadores de la máquina, también sirve como supervisor del
estado de las salidas, ya que las salidas activas se marcan con fondo azul mientras que las inactivas
permanecen en color gris.
También recordar que presionando el botón Interbus o Ethernet se abrirá una nueva ventana con el
informe de tiempos gráfico que se presentó en la figura 5.6 de la memoria. El botón CANOpen esta
reservado para futuras ampliaciones de la aplicación.
Carlos Mediavilla Martí
101
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
G.4. Control y supervisión de la célula de fabricación
En este caso también se han desarrollado los dos clientes para la aplicación de control de la célula: Java
y Web. La pantalla de la aplicación Java (que se arranca con el script: clienteCelula.sh) se puede ver en la
figura 6.2 de la memoria y tiene una funcionalidad similar al interfaz Web que se presenta aquí.
La aplicación desarrollada, permite al usuario controlar la producción en la célula y supervisar
cualquier aspecto de la ejecución de los coordinadores de forma remota.
La aplicación web diseñada (que es cliente del servidor RMI) es relativamente interesante, útil y todas
las funciones se utilizan de forma intuitiva. Para el diseño se han utilizado componentes html, hojas de
estilo y applets java. Los applets se utilizan cuando se requiere un refresco continuo de la información
gráfica o las etiquetas html no son suficientes para generar gráficos. La desventaja es que el navegador
web debe tener instalado el plug-in de Java. La página se refresca cada cierto tiempo (típicamente < 1
segundo) lo que implica una petición http al servidor. Dependiendo del navegador la carga repetitiva de
una página puede tener un efecto negativo de parpadeo, con Netscape el efecto es mucho menor.
La primera pantalla que se ve nada más introducir la dirección de la aplicación Web es la siguiente,
donde se pide un nombre de usuario y una contraseña (que permitirá o no, el acceso a la aplicación):
Figura G.9. Control acceso aplicación Web
Si la comprobación resulta exitosa se envía al usuario a la página de inicio (página por defecto).
Aparecerá la pantalla de bienvenida con un menú a la izquierda. Para facilitar la navegación por la
aplicación, la página Web cuenta con una serie de menús que permiten acceder a diferentes partes de
control, supervisión y gestión de la célula.
•
Supervisión: Este enlace contiene un submenú para cada una de las estaciones de la célula,
incluyendo al transporte. En cada una de las páginas se puede observar el estado de los sensores
(entradas) y actuadores (salidas) de la estación seleccionada de la célula en tiempo real (el tiempo
de refresco es configurable)
•
Manual: Este enlace contiene un submenú para cada una de las estaciones de la célula,
incluyendo al transporte. Cada una de las páginas permite controlar de modo manual cualquiera de
las estaciones de la célula.
•
Automático: Aquí se gestiona el control completo de la célula de fabricación, se puede lanzar la
ejecución del coordinador global o detenerla. Un applet se encarga de mostrar el estado de cada
una de las estaciones, los botones de emergencia permiten parar la producción si algo va mal y
además existen varios enlaces que llevan a otras páginas de supervisión.
•
Producción: En esta pantalla se lleva el control de los pedidos, pudiéndose crear nuevos pedidos
o eliminar pedidos existentes defectuosos. Contiene una lista donde se puede ver el histórico de
pedidos o información detallada de los pedidos actuales.
Carlos Mediavilla Martí
102
20/07/06
Anexo G. Aplicaciones
Obviamente vamos a poder controlar la célula de dos maneras: producción automática y producción
manual. El control de usuario no solo sirve para permitir el acceso a la aplicación, sino que también
funciona como un gestor de roles, esto quiere decir que determinadas pantallas solo estarán disponibles
para determinados usuarios. Las funciones definidas son: control, supervisión y producción y cada uno de
los roles puede tener 1 o más funciones. Según la manera de control deseado pulsaremos uno u otro menú.
Figura G.10. Control manual desde página Web
En el modo manual de control de la célula podremos controlar todas las salidas de las estaciones y el
transporte, a la vez que se tiene un panel indicador del estado de las salidas que va cambiando en tiempo
real. Esto se consiguió leyendo periódicamente el estado de las salidas de la célula al igual que se hizo a la
hora de implementar el coordinador.
En la figura G.10 puede verse concretamente la pantalla de control manual del transporte, Se puede ver
un listado de todas las salidas de la estación, estando activadas las salidas: Enclavamiento_estacion1,
Cinta_12 y Cinta_345 (resaltadas con tipo de letra en negrita). Si se desea controlar las otras estaciones
sólo hay que navegar mediante los enlaces de la parte superior izquierda. Los pulsadores
y
activan
o desactivan respectivamente la salida de la estación correspondiente. Además la pantalla ofrece una breve
descripción de la función de cada una de las salidas.
Aunque no sería coherente que mientras utilizáramos el modo manual se siguieran ejecutando los
coordinadores del modo automático, en esta aplicación si se permite ya que resulta muy útil pausar el
coordinador y pasar al modo manual para efectuar un control manual y resolver el problema surgido.
Carlos Mediavilla Martí
103
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
En el modo de supervisión de la célula podremos visualizar el estado todas las entradas y salidas de las
estaciones y el transporte en tiempo real. Esto se consiguió leyendo periódicamente el estado de las
entradas de la célula al igual que se hizo a la hora de implementar el coordinador. Si el indicador esta
significa que el sensor (entrada) / accionador (salida) esta activo, mientras que si es
la correspondiente
variable esta desactivada.
Figura G.11. Visualización del estado de entradas y salidas
Estas variables de memoria se han colocado en los monitores correspondientes, y el coordinador
correspondiente es el que modifica su valor. Las distintas clases gráficas leen de estos monitores para
actualizar sus valores.
La pantalla muestra las entradas/salidas de la estación actualizadas automáticamente cada cierto
tiempo. Este tiempo se puede configurar entre 0.5 y 5 segundos según los requerimientos de supervisión
del proceso.
Si quisiéramos pasar del modo automático al modo manual o viceversa podrían producirse resultados
indeseados. Por ello una pantalla informa al usuario de esta posibilidad recordándole que debe resetear
todas las salidas.
Por otro lado, en la pantalla de la parte inferior izquierda, se puede observar información muy útil
sobre el estado de los servidores de aplicación en funcionamiento, en concreto sirve para tener en cuenta
cual de las aplicaciones esta funcionando: la de control de la estación 3 individual o la de la célula global.
Carlos Mediavilla Martí
104
20/07/06
Anexo G. Aplicaciones
Por supuesto la pantalla más importante de la aplicación web es la pantalla desde donde se puede
supervisar el control automático de la estación. Uno de los elementos más interesantes es el applet que
permite visualizar el estado de las redes de Petri que se están ejecutando en el computador remoto, a él se
accede a través de los enlaces ‘Grafo de Petri’ que hay en el panel de cada estación.
Figura G.12. Pantalla Web para el control automático de la célula
En la imagen puede observarse la composición de la pantalla. En primer lugar, en la parte superior
existen una serie de botones que controlan el coordinador de la célula: lanzar/finalizar, detener/continuar y
emergencia/rearme. El primero lanza el coordinador o lo para estableciendo la red de Petri a su valor
inicial si está ejecutándose. Existe una opción (que por defecto esta desmarcada) que sirve para indicar si
antes de iniciarse el coordinador global se deben borrar los palets, si es así provocará que la aplicación
comience a ejecutar el proceso de borrado de palets. Una vez realizado el borrado la aplicación, el
coordinador global de la célula comenzará su ejecución. El segundo botón pausa la ejecución del
coordinador, pero no anula las salidas existentes de la célula, es decir, podemos detener el coordinador y
continuarlo después sin que el proceso de control se vea afectado. La emergencia detiene el coordinador y
además provoca la anulación de las salidas de las estaciones. En la parte central se puede ver el valor de
determinados parámetros del proceso de fabricación en cada estación dentro del modo automático de
fabricación.
Carlos Mediavilla Martí
105
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
La pantalla de producción de la aplicación se encarga de la gestión y lanzamiento de pedidos. En ella el
usuario introduce el tipo de pieza que desea fabricar, pidiéndosele después una confirmación para lanzar
un nuevo pedido. Todos los pedidos lanzados pasan pues a formar parte de una lista de pedidos que el
coordinador gestionará hasta su finalización. La parte inferior izquierda de la pantalla la ocupa la tabla con
la información acerca de los pedidos. En ella puede seguirse el proceso que lleva cada pedido desde que es
lanzado hasta que finaliza la producción en la estación 4. Existe un enlace que permite ver más detalles
del pedido seleccionado.
del pedido seleccionado y otro que permite la cancelación
Figura G.13. Pantalla Web para el control de la producción
Como guarda ante posibles fallos provocados por la manipulación indebida de los palets se ha
implementado el coordinador de la célula de modo que cuando un palet llega a una estación lo primero
que se hace es comprobar si ese palet es el que debería haber llegado a la estación.
La producción se gestiona de la siguiente manera: la estación 1 esperará la llegada de un palet vacío
antes de comprobar si existe algún pedido pendiente, si es así sacará la correspondiente camisa del
almacén al palet y actualizará la memoria del palet. A continuación la pieza se dirigirá hacia la estación 2
para seguir con el proceso de producción. Si la pieza fuera con tapa, existe un desvío intermedio que hace
que la pieza se dirija directamente a la estación 4 (la última estación de esta parte de la célula) La
aplicación tiene en cuenta posibles errores que se pudieran cometer y permite que las piezas inacabadas
vuelvan a la estación 1 para reiniciar el proceso de producción. También gestiona los conflictos que se
puedan producir cuando un palet se dirige hacia la estación 4 desde el desvío intermedio y otro que viene
desde la estación 3, evitando un choque entre ambos. Al final de la producción en la estación 4, se borran
los palets completados.
Carlos Mediavilla Martí
106
20/07/06
Anexo G. Aplicaciones
Los posibles estados por los que puede pasar un pedido son los siguientes:
ESTACION1
MOV_EST1_EST2
ESTACION2
MOV_EST4_EST1
MEDIO
MOV_EST2_EST3
CANCELADO
FINALIZADO
ESTACION4
MOV_EST3_EST4
ESTACION3
Figura G.14. Estados de un pedido
G.5. Módulos Momentum Ethernet
Aparte de las aplicaciones para el control automático de la célula, se ha creado una aplicación
independiente [EthernetGui.java] con interfaz gráfico que permite al usuario conectarse al comunicador
Momentum deseado para realizar tareas de supervisión (lectura de entradas) o realizar un control manual.
La comunicación con los comunicadores Momentum de Schneider Electric se consigue gracias a la
biblioteca Java “SACommLite” proporcionada por el fabricante2. Esta librería contiene clases que permiten
crear applets o aplicaciones Java para comunicarse con los módulos de entrada-salida por medio del
protocolo ModBus TCP-IP. Dispone de toda la funcionalidad necesaria para escribir y leer valores
almacenados en los registros de memoria RAM del procesador Momentum. Los valores escritos o leídos
pueden ser de tipo booleano o palabras de 16 bits.
Figura G.15. Pantalla de la aplicación Momentum Ethernet
2
Developer's Guide for 'SA Comm Lite' Communications Library. 2001 Schneider Electric.
Carlos Mediavilla Martí
107
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Para los campos registro lectura y registro escritura los mnemónicos disponibles para el protocolo
ModBus en el contexto de utilización de la variable son:
•
00001+i para las variables de formato bits internos y bits de salida con: 0<=i<=65535
•
10001+i para las variables de formato bit de entrada con: 0<=i<=65535
•
30001+i para las variables de formato registro de entrada con: 0<=i<=65535
•
40001+ij para las variables de formato bit con: 0<=i<=65535, 0<=j<=0xF (hexadecimal)
•
40001+i para las variables de formato palabra, doble palabra, cadena o flotante con:
0<=i<=65535
Los tipos de direcciones permitidas para lectura de los diferentes tipos de datos son:
• (0x) Salidas 1 bit.
• (1x) Entradas 1 bit.
• (3x) Entradas registros 16 bits.
• (4x) Salidas registros 16 bits.
Adicionalmente se permite escribir en las direcciones de tipo (0x) y (4x).
G.6. Comunicación con autómatas
Los autómatas de las estaciones 1 (TSX Micro) y 5 (TSX Premium) disponen de un módulo Ethernet.
Que en el caso de la estación 5, actúa además como una pasarela entre Ethernet TCP/IP y la red FipWay
de la célula de fabricación. La red FipWay es un bus de campo que interconecta todos los autómatas del
laboratorio.
Para poder comunicarnos vía Ethernet habría que realizar unas primitivas básicas utilizando funciones
de entrada-salida, llamadas a funciones nativas y sockets, y además implementar el protocolo
correspondiente al dispositivo (en este caso ModBus TCP-IP), ello requiere un trabajo considerable que en
si mismo puede constituir un proyecto por si solo. Por eso es necesaria la ayuda de bibliotecas que
encapsulan las tareas más arduas y presentan al programador una interfaz de programación más funcional
y práctica.
La comunicación con los autómatas Micro, Premium y Quantum del fabricante Schneider Electric se
consigue a través del kit de desarrollo de software (SDK) FactoryCast (Version 2.2.2). Gracias al SDK
podremos escribir applets o aplicaciones Java que se comuniquen con estos controladores (PLCs) vía
Ethernet TCP/IP.
FactoryCast 3es un paquete de software que contiene las siguientes utilidades:
3
•
Librería de comunicaciones para Java, que detallaremos a continuación.
•
Editor gráfico. Es un applet que permite a un usuario (vía navegador Web) crear objetos gráficos
(displays, mandos,...) dinámicamente (Java Beans) y probarlos en tiempo de ejecución con los
datos del PLC.
FactoryCast User's Guide. For Quantum, Premium and Micro. 2001 Schneider Electric.
Carlos Mediavilla Martí
108
20/07/06
Anexo G. Aplicaciones
•
Soporte para “widgets”. Son objetos gráficos ya preparados para su uso en applets o aplicaciones
(botones, indicadores digitales, deslizadores, rotatorios, luces, medidores analógicos, selectores,
...) Se pueden utilizar para personalizar un sitio en el servidor Web incorporado en el autómata.
La librería de comunicaciones necesaria se encuentra contenida en el archivo JAR FactoryCast.jar.
El archivo JAR “FactoryCast.jar” contiene todas las clases Java que se necesitan para compilar un
applet Java o una aplicación que use la librería de comunicación FactoryCast (FCL) Existen varios
paquetes dentro de la librería:
•
com.schneiderautomation.factorycast: Todas las clases de este paquete están implementadas como
Java Beans, pero pueden ser utilizadas en aplicaciones Java. Los métodos de las clases de este
paquete proveen de toda la funcionalidad que una aplicación cliente típica necesita para
comunicarse con los autómatas.
•
com.schneiderautomation.factorycast.comm: Contiene clases de soporte para la comunicación con
los autómatas Quantum o Premium, y acceso a la información de las variables en un programa
PL7. Estas clases permiten leer y escribir en las variables del autómata en tiempo de ejecución,
además de poder monitorizar de forma continua los valores de dichas variables (comunicando a la
aplicación cliente cualquier cambio inmediatamente) Esta capa es transparente para el
programador ya que son los métodos del paquete anterior los encargados de llamar a las métodos
de comunicación adecuados.
•
com.schneiderautomation.factorycast.comm.xbf: Contiene el código específico para cada
plataforma (Quantum/Concept vs. Premium/PL7) que implementa el protocolo usado para acceder
a los valores de las variables en tiempo de ejecución. Existe una versión para cada tipo de
autómata. El programador solo se tiene que preocupar de usar el archivo SAComm.jar adecuado
para la plataforma destino de la aplicación.
Haciendo uso únicamente de la librería Java de comunicaciones suministrada por el fabricante con
funciones para la comunicación con los autómatas, algunas de las cuales permiten leer y escribir en su
tabla de símbolos (variables del programa del autómata). Se ha desarrollado una aplicación independiente
gráfica [AutomataGui.java] (no un applet) con las siguientes características:
Figura G.16. Pantalla aplicación Autómatas
Carlos Mediavilla Martí
109
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Las características más destacadas de la aplicación son las siguientes:
•
•
•
•
•
Conexión TCP/IP con uno de los dos autómatas existentes con servidor Web (155.210.154.21 o
154.210.154.218)
Operaciones de lectura/escritura en variables del autómata.
Monitorización de variables del autómata.
Consulta de la tabla de símbolos del autómata.
Consola con mensajes de estado.
Al pulsar el botón ‘Conectar’ se realiza una conexión TCP/IP con el autómata. Las direcciones IP
disponibles están limitadas a las que aparecen en el selector. A continuación se muestra la salida por
consola de una conexión exitosa.
Connecting to '155.210.154.21'
Successfully connected to '155.210.154.21' <155.210.154.21>
Disconnected from '155.210.154.21'
Connecting to '155.210.154.21'
Successfully connected to '155.210.154.21' <155.210.154.21>
Disconnected from '155.210.154.21'
Connecting to '155.210.154.21'
Reading Symbol Table from 155.210.154.21
Successfully connected to '155.210.154.21' <155.210.154.21>
Symbol Table is unavailable or inconsistent with program.
Program is: STATION:0.0
XWAY source (PBF) : network 5, station 62
XWAY destination (ETY) : network 5, station 4
Hay que tener en cuenta que para leer o escribir en una variable del autómata hay que especificar el
nombre de la variable y su tipo.
Para el campo ‘Nombre variable’ los mnemónicos disponibles para el protocolo ModBus en el contexto
de utilización de la variable son:
•
%MWi.j para las variables de formato bit con: 0<=i<=65535, 0<=j<=0xF (hexadecimal)
•
%MWi para las variables de formato palabra o cadena con: 0<=i<=65535
•
%MDi para las variables de formato doble palabra con: 0<=i<=65535
•
%MFi para las variables de formato flotante con: 0<=i<=65535
•
%Mi para las variables de formato bits internos y bits de salida con: 0<=i<=65535
•
%Ii para las variables de formato bit entrada con: 0<=i<=65535
•
%IWi para las variables de formato registro de entrada con: 0<=i<=65535
Para el parámetro ‘tipo de datos’ las opciones disponibles son:
•
•
•
•
“UINT” – Entero sin signo.
“INT” – Entero con signo.
“REAL” – Punto flotante. Realmente ocupa 2 registros de memoria en el autómata.
“BOOL” – Valor booleano.
Carlos Mediavilla Martí
110
20/07/06
Anexo G. Aplicaciones
Una vez rellenados los campos adecuadamente se puede ver el detalle de los valores del registro si se
pincha en el botón ‘ver’:
Figura G.17. Detalle de bits de una variable
El mapa de memoria (tabla de símbolos) de la estación 5 contiene variables de todas las demás
estaciones, es una tabla de memoria compartida y serviría para controlar las demás estaciones a través
únicamente de la conexión a la estación 5. De esta forma el control de la estación 2 se podría realizar
localmente con el autómata disponible reutilizando el código empleado para desarrollar esta aplicación
Figura G.18. Visualización de la tabla de símbolos
Carlos Mediavilla Martí
111
20/07/06
Modulo de comunicaciones para una aplicación de control distribuido
ANEXO H. IMPLEMENTACION JAVA - API
PLATAFORMA DE DESARROLLO
Como se ha comentado anteriormente, Java es un lenguaje orientado a objetos, así pues se ha
estructurado todo el código de la aplicación en clases que a su vez se agrupan en paquetes. Como en
cualquier aplicación Java, el código se encapsula en una serie de clases que contienen una funcionalidad
específica, y a su vez, un conjunto de clases que realizan tareas relacionadas se suelen agrupar en un
mismo paquete. En los capítulos siguientes se detallan los paquetes desarrollados en este proyecto que ha
sido desarrollado utilizando el entorno de desarrollo Eclipse (edición, compilación [versión 1.4],
depuración y ejecución), ver figura H.1.
Figura H.1. Entorno de desarrollo Eclipse
En el diseño de la aplicación se ha intentado aprovechar las oportunidades que da Java para hacer una
aplicación modular y robusta, de esta manera futuras modificaciones en la aplicación podrán ser realizadas
rápida y eficazmente.
En esta sección se va a hacer un repaso de las clases implementadas y utilizadas durante este proyecto.,
explicando cual es la función de cada clase. Para conocer más detalles de la implementación, se pueden
consultar los abundantes comentarios que se encuentran a lo largo del código fuente, en el CD adjunto a
este documento. La organización básica que se ha seguido ha sido la siguiente:
Carlos Mediavilla Martí
112
20/07/06
Anexo H. Implementación Java
•
Aplicaciones: El paquete aplicaciones contiene las aplicaciones finales del proyecto y constituyen
el conjunto de clases definitivas tanto para el control manual como automático de la célula y
pequeñas aplicaciones de control manual y automático de las estaciones. El contenido principal
consta de los programas de la parte servidor de las aplicaciones y los interfaces necesarios para la
comunicación remota con RMI.
•
Comunicaciones: Contiene las clases que permiten la comunicación con el sistema controlado
(módulos de entrada-salida y autómatas) a través de Interbus o Ethernet. Las implementaciones
hacen uso fundamentalmente de bibliotecas Java suministradas por Schneider Electric. Se pueden
crear clases que permitan un control manual de la célula, pero para el control automático hace
falta el siguiente paquete.
•
Control: Dispone de las clases básicas de control automático que van a ser necesarias en la mayor
parte de aplicaciones del proyecto.
•
Control_centralizado: Implementa la técnica centralizada para el control mediante redes de Petri.
Entre otras clases, contiene los coordinadores responsables de ejecutar cada una de las redes de
Petri que conforman el sistema de la célula.
•
Control_descentralizado: Implementa la técnica descentralizada para el control de redes de Petri.
Entre otras clases, contiene los coordinadores responsables de ejecutar cada una de las redes de
Petri que conforman el sistema de la célula.
•
Control_distribuido: Implementa la técnica distribuida para el control de redes de Petri. Entre
otras clases, contiene los coordinadores responsables de ejecutar cada una de las redes de Petri que
conforman el sistema de la célula.
•
Estaciones: Monitores que contienen el valor de los sensores y accionadores de cada estación.
•
Producción: Permite el control de la producción de la célula mediante la gestión de pedidos y
palets.
•
PuertoSerie: Contiene las clases que gestionan la comunicación con el identificador de productos
a través del puerto serie del PC. Aunque estas clases se han pensado para comunicar con el
identificador de productos a través del puerto serie, una mejora inmediata de la aplicación es
gestionar el identificador como un dispositivo PCP a través de Interbus.
•
RedPetri: Modelo de datos para representar los lugares, transiciones y estructura de una red de
Petri que será ejecutado por uno de los coordinadores del paquete Control.
•
Gui: Son las clases para la creación del entorno grafico de usuario. Se definen las clases
necesarias para la visualización gráfica de uso común para las aplicaciones del proyecto,
aplicaciones de control manual y automático de la misma.
H.1. Aplicaciones
El paquete aplicaciones contiene las aplicaciones finales del proyecto y constituyen el conjunto de
clases definitivas tanto para el control manual como automático de la célula y pequeñas aplicaciones de
control manual y automático de las estaciones. El contenido principal consta de los programas de la parte
servidor de las aplicaciones y los interfaces necesarios para la comunicación remota con RMI.
Carlos Mediavilla Martí
113
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Resumen de Interfaces
InterfaceRMICelula
Definimos los metodos que la aplicacion de control de la celula debe
implementar para las comunicaciones remotas con RMI.
InterfaceRMICelulaDistribuido
Definimos metodos adicionales que la aplicacion distribuida (lado del
servidor) de la celula debe implementar para las comunicaciones remotas
con RMI.
InterfaceRMIEstacion
Definimos los metodos que una aplicacion para el control independiente de
una estacion debe implementar para comunicarse mediante RMI.
InterfaceRMIEstacion1
Definimos metodos adicionales que una aplicacion independiente de la
estacion 1 debe implementar para comunicarse mediante RMI
InterfaceRMIGrafoPetri
Definimos los metodos que cualquier aplicacion debe implementar para la
visualizacion remota de redes de petri mediante RMI.
Resumen de clases
ServidorCelula
Clase abstracta que sirve de base para crear aplicaciones para el control de la
celula.
ServidorCelulaCen
Aplicacion para el control centralizado de la celula.
ServidorCelulaDes
Aplicacion para el control descentralizado de la celula.
ServidorCelulaDisLocal
Clase abstracta que sirve de base para crear aplicaciones distribuidas para el
control de la celula.
ServidorCelulaDisLocalA
Aplicacion para el control distribuido de la celula (opción A)
Esta aplicacion actua como servidor principal, realiza el control de todas las
estaciones excepto la 3.
ServidorCelulaDisLocalB
Aplicacion para el control distribuido de la celula (opción B) Esta aplicacion actua
como servidor principal, realiza el control de todas las estaciones excepto la 3.
ServidorEstacion
Clase abstracta que sirve de base para crear aplicaciones para el control
individual de estaciones.
ServidorEstacion1
Clase abstracta que sirve de base para crear aplicaciones para el control de la
estacion 1
ServidorEstacion1Ind
Aplicacion para el control independiente de la estacion 1 de forma remota.
ServidorEstacion3
Clase abstracta que sirve de base para crear aplicaciones para el control de la
estacion 3
ServidorEstacion3DisA
Aplicacion para el control distribuido de la celula (opción A) Esta aplicacion actua
como servidor remoto, realiza el control de la estacion 3.
ServidorEstacion3DisB
Aplicacion para el control distribuido de la celula (opción B) Esta aplicacion actua
como servidor remoto, realiza el control de la estacion 3.
ServidorEstacion3Ind
Aplicacion para el control independiente de la estacion 3 de forma remota.
ServidorEstacion4
Clase abstracta que sirve de base para crear aplicaciones para el control de la
estacion 4
ServidorEstacion4Ind
Aplicacion para el control independiente de la estacion 4 de forma remota.
UtilidadesGraficas
Clase que contiene la implementacion de los metodos remotos:
getDatosGraficosCreacion(Red red) y
getDatosGraficosCreacion(Red red) necesarios para la visualizacion
remota de redes de Petri
UtilidadesRMI
Clase que contiene metodos comunes para trabajar con RMI
Carlos Mediavilla Martí
114
20/07/06
Anexo H. Implementación Java
Jerarquía de clases
o
java.lang.Object
o
o
aplicacion.ServidorCelula
o
aplicacion.ServidorCelulaCen (implements aplicacion.InterfaceRMICelula)
o
aplicacion.ServidorCelulaDes (implements aplicacion.InterfaceRMICelula)
o
aplicacion.ServidorCelulaDisLocal
o
aplicacion.ServidorCelulaDisLocalA (implements
aplicacion.InterfaceRMICelula)
o
aplicacion.ServidorCelulaDisLocalB (implements
aplicacion.InterfaceRMICelulaDistribuido)
aplicacion.ServidorEstacion
o
aplicacion.ServidorEstacion1
o
o
o
aplicacion.ServidorEstacion1Ind (implements aplicacion.InterfaceRMIEstacion1)
aplicacion.ServidorEstacion3
o
aplicacion.ServidorEstacion3DisA (implements
aplicacion.InterfaceRMIEstacion)
o
aplicacion.ServidorEstacion3DisB (implements
aplicacion.InterfaceRMIEstacion)
o
aplicacion.ServidorEstacion3Ind (implements aplicacion.InterfaceRMIEstacion)
aplicacion.ServidorEstacion4
o
aplicacion.ServidorEstacion4Ind (implements aplicacion.InterfaceRMIEstacion)
o
aplicacion.UtilidadesGraficas
o
aplicacion.UtilidadesRMI
Jerarquía de interfaces
o
java.rmi.Remote
o
aplicacion.InterfaceRMIGrafoPetri
o
aplicacion.InterfaceRMICelula
o
o
aplicacion.InterfaceRMICelulaDistribuido
aplicacion.InterfaceRMIEstacion
o
aplicacion.InterfaceRMIEstacion1
H.2. Comunicaciones
Contiene las clases que permiten la comunicación con el sistema controlado (módulos de entrada-salida
y autómatas) a través de Interbus o Ethernet. Las implementaciones hacen uso fundamentalmente de
bibliotecas Java suministradas por Schneider Electric. Se pueden crear clases que permitan un control
manual de la célula, pero para el control automático hace falta el paquete Control.
Carlos Mediavilla Martí
115
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Resumen de interfaces
Comunicaciones
Define los metodos que las clases responsables de la comunicacion con la celula deben
implementar.
Resumen de clases
AutomataGui
Aplicacion grafica que utiliza la libreria de comunicaciones SAComm (FactoryCast)
de Schneider Automation,
permite conectarse a un automata (con modulo Ethernet) para monitorizar y
escribir en sus registros de memoria en tiempo real.
Ethernet
Clase abstracta con metodos basicos para gestionar la comunicacion con los
comunicadores Momentum Ethernet, la biblioteca (SACommLite) que sumunistra el
fabricante del dispositivo implementa el protocolo ModBus TCP-IP.
EthernetClasico
Realiza la comunicacion con los dispositivos Momentum Ethernet sin
requerimientos de tiempo real, se implementa como una tarea periodica que se
encarga de leer y escribir los valores contenidos del bus.
EthernetEstacion3
Comunicacion con la estacion 3 mediante comunicador Momentum Ethernet,
segun se desee cumplir requerimientos de tiempo real, esta clase debera extender
de EthernetClasico o EthernetRT
EthernetGui
Aplicacion con interface grafico que permite al usuario conectarse al comunicador
Momentum Ethernet deseado para leer y/o escribir en su módulo de entradas /
salidas.
EthernetRT
Realiza la comunicacion con los dispositivos Momentum Ethernet con
requerimientos de tiempo real, se implementa como una tarea periodica que se
encarga de leer y escribir los valores contenidos del bus.
EthernetTransporte
Comunicacion con el transporte mediante comunicador Momentum Ethernet,
segun se desee cumplir requerimientos de tiempo real, esta clase debera extender
de EthernetClasico o EthernetRT
Interbus
Clase abstracta para la gestion de la comunicacion con la celula mediante el bus
Interbus, esta clase encapsula la inicialización, finalización, lectura y escritura del
bus, encargada de leer y escribir el bus y actualizar los valores de los monitores.
InterbusClasico
Comunicacion con la celula mediante el bus Interbus sin requerimientos de
tiempo real,
se implementa como una tarea periodica que se encarga de leer y escribir el bus y
actualizar los valores contenidos en los monitores.
InterbusRT
Comunicacion con la celula mediante el bus Interbus con requerimientos de
tiempo real,
se implementa como una tarea periodica que se encarga de leer y escribir el bus y
actualizar los valores contenidos en los monitores.
Jerarquía de clases
o
java.lang.Object
o
comunicaciones.AutomataGui
o
comunicaciones.Ethernet (implements comunicaciones.Comunicaciones)
o
comunicaciones.EthernetClasico (implements
com.schneiderautomation.lcomm.TimerListener)
o
o
comunicaciones.EthernetRT
o
Carlos Mediavilla Martí
comunicaciones.EthernetTransporte
comunicaciones.EthernetEstacion3
116
20/07/06
Anexo H. Implementación Java
o
comunicaciones.EthernetGui
o
comunicaciones.Interbus
o
o
comunicaciones.InterbusClasico (implements comunicaciones.Comunicaciones)
o
comunicaciones.InterbusRT (implements comunicaciones.Comunicaciones)
java.lang.Thread (implements java.lang.Runnable)
o
o
javax.realtime.RealtimeThread (implements javax.realtime.Schedulable)
o
comunicaciones.EthernetRT.TareaActualizacion
o
comunicaciones.InterbusRT.TareaActualizacion
java.util.TimerTask (implements java.lang.Runnable)
o
comunicaciones.InterbusClasico.TareaActualizacion
Diagrama de clases
Figura H.2. Diagrama de la clase Ethernet
H.3. Control
Dispone de las clases básicas de control automático que van a ser necesarias en la mayor parte de
aplicaciones del proyecto.
Resumen de clases
Coordinador
Implementación del control de un sistema modelado por una Red de Petri, un
coordinador se encarga de gestionar la ejecucion de una Red de Petri, la evolucion de
la RdP se lleva a cabo mediante el disparo de sus transiciones actualizando los valores
de las marcas de los estados, esta clase es independiente del sistema que se quiera
controlar y del algoritmo utilizado para hacer evolucionar la Red de Petri.
CoordinadorClasico
Extension de la clase Coordinador sin requerimientos de tiempo real
CoordinadorRT
Extension de la clase Coordinador con requerimientos de tiempo real
Emergencia
Implementacion de las emergencias mediante una tarea, la tarea comprueba cada
cierto tiempo el estado del bit emergencia de la estacion correspodiente y actua en
consecuencia.
Jerarquía de clases
o
java.lang.Object
o
control.Coordinador
o
control.CoordinadorClasico
o
control.CoordinadorRT
Carlos Mediavilla Martí
117
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
o
java.lang.Thread (implements java.lang.Runnable)
o
javax.realtime.RealtimeThread (implements javax.realtime.Schedulable)
o
o
control.CoordinadorRT.TareaCoordinador
java.util.TimerTask (implements java.lang.Runnable)
o
control.CoordinadorClasico.TareaCoordinador
o
control.Emergencia
H.4. Control.centralizado
Implementa la técnica centralizada para el control mediante redes de Petri. Entre otras clases, contiene
los coordinadores responsables de ejecutar cada una de las redes de Petri que conforman el sistema de la
célula.
Resumen de clases
CoordinadorBorrar
Coordinador específico que gestiona el control del borrado de los palets de la célula de
fabricación.
CoordinadorCelula
Coordinador específico que gestiona el control general de la célula de fabricación.
CoordinadorEst1
Coordinador encargado de la ejecucion de la red correspondiente al control de la
estacion 1, implementa las condiciones que deben cumplir las transiciones sensibilizadas
para ser disparadas y el código asociado al establecimiento, mantenimiento y
finalización de un estado.
CoordinadorEst2
Coordinador encragado de la ejecucion de la red de Petri correspondiente al control de
la estacion 2,
implementa las condiciones que deben cumplir las transiciones sensibilizadas para ser
disparadas y el código asociado al establecimiento, mantenimiento y finalización de un
estado.
CoordinadorEst3
Coordinador encargado de la ejecucion de la red correspondiente al control de la
estacion 3,
implementa las condiciones que deben cumplir las transiciones sensibilizadas para ser
disparadas y el código asociado al establecimiento, mantenimiento y finalización de un
estado.
CoordinadorEst4
Coordinador encargado de la ejecucion de la red correspondiente al control de la
estacion 4,
implementa las condiciones que deben cumplir las transiciones sensibilizadas para ser
disparadas y el código asociado al establecimiento, mantenimiento y finalización de un
estado.
CoordinadorTS
Clase que contiene el algoritmo de Transiciones Sensibilizadas, se encarga de disparar
las transiciones actualizando los valores de las marcas de los estados.
Jerarquía de clases
o
java.lang.Object
o
control.Coordinador
o
control.CoordinadorClasico
o
control.CoordinadorRT
o
control.centralizado.CoordinadorTS
o
Carlos Mediavilla Martí
control.centralizado.CoordinadorBorrar
118
20/07/06
Anexo H. Implementación Java
o
control.centralizado.CoordinadorCelula
o
control.centralizado.CoordinadorEst1
o
control.centralizado.CoordinadorEst2
o
control.centralizado.CoordinadorEst3
o
control.centralizado.CoordinadorEst4
Diagrama de clases
Figura H.3. Diagrama de la clase CoordinadorEst3
H.5. Control.descentralizado
Implementa la técnica descentralizada para el control de redes de Petri. Entre otras clases, contiene los
coordinadores responsables de ejecutar cada una de las RdP que conforman el sistema de la célula.
Resumen de clases
CoordinadorBorrarDes
Coordinador específico para la ejecucion de la red de Petri descentralizada
que controla el borrado de los palets de la célula de fabricación.
CoordinadorCelulaDes
Coordinador específico para la red de Petri que gestiona el control general
de la célula de fabricación en las implementaciones descentralizadas o
distribuidas.
CoordinadorEst1Des
Coordinador encargado de la ejecucion de la red correspondiente al control
de la estacion 1 en las implementaciones descentralizadas o distribuidas.
CoordinadorEst2Des
Encargado de la ejecucion de la red de Petri correspondiente al control de
la estacion 2 en las implementaciones descentralizadas o distribuidas.
CoordinadorEst3Des
Coordinador encargado de la ejecucion de la red correspondiente al control
de la estacion 3 en las implementaciones descentralizadas o distribuidas
(solo opcion A).
CoordinadorEst4Des
Coordinador encargado de la ejecucion de la red correspondiente al control
de la estacion 4 en las implementaciones descentralizadas o distribuidas.
CoordinadorTSDescentralizado
Extiende la clase CoordinadorTS para implementaciones descentralizadas y
distribuidas.
LugarComunicacion
Clase que modela un Lugar de comunicacion basado en subasta.
PeticionDisparo
Clase auxiliar que encapsula la peticion de disparo realizada por una
transicion.
Carlos Mediavilla Martí
119
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Jerarquía de clases
o
java.lang.Object
o
control.Coordinador
o
control.CoordinadorRT
o
control.centralizado.CoordinadorTS
o
o
control.descentralizado.CoordinadorTSDescentralizado
o
control.descentralizado.CoordinadorBorrarDes
o
control.descentralizado.CoordinadorCelulaDes
o
control.descentralizado.CoordinadorEst1Des
o
control.descentralizado.CoordinadorEst2Des
o
control.descentralizado.CoordinadorEst3Des
o
control.descentralizado.CoordinadorEst4Des
redPetri.Estado
o
control.descentralizado.LugarComunicacion
o
control.descentralizado.LugarComunicacion.ComparadorPrioridad (implements
java.util.Comparator)
o
control.descentralizado.PeticionDisparo
H.6. Control.distribuido
Implementa la técnica distribuida para el control de redes de Petri. Entre otras clases, contiene los
coordinadores responsables de ejecutar cada una de las redes de Petri que conforman el sistema de la
célula.
Resumen de interfaces
InterfaceRMILugarComunicacionLocal
Interface RMI para lugares de comunicacion distribuidos.
Resumen de clases
CoordinadorCelulaDis
Coordinador específico para la red de Petri que gestiona el control general de
la célula de fabricación en la implementacion distribuida (opcion A)
CoordinadorEst3Dis
Coordinador responsable de la ejecucion de la red correspondiente a control
de la estacion 3 en la implementacion distribuida (opcion B).
LugarComunicacionLocal
Lugar de comunicacion para implementaciones distribuidas (servidor
principal).
LugarComunicacionRemoto
Lugar de comunicacion para implementaciones distribuidas (servidor remoto)
Carlos Mediavilla Martí
120
20/07/06
Anexo H. Implementación Java
Jerarquía de clases
o
java.lang.Object
o
control.Coordinador
o
control.CoordinadorRT
o
control.centralizado.CoordinadorTS
o
o
control.descentralizado.CoordinadorTSDescentralizado
o
control.distribuido.CoordinadorCelulaDis
o
control.distribuido.CoordinadorEst3Dis
redPetri.Estado
o
control.descentralizado.LugarComunicacion
o
o
control.distribuido.LugarComunicacionLocal (implements
control.distribuido.InterfaceRMILugarComunicacionLocal)
control.distribuido.LugarComunicacionRemoto
Jerarquía de interfaces
o
java.rmi.Remote
o
control.distribuido.InterfaceRMILugarComunicacionLocal
H.7. Estaciones
Monitores que contienen el valor de los sensores y accionadores de cada estación.
Resumen de clases
Estacion
Clase que modeliza una estacion generica de la celula de fabricacion, encapsula el acceso a
las variables e información del estado de la estación,
todos los métodos se declaran synchronized para evitar posibles problemas derivados del
acceso simultaneo de varios coordinadores a una variable.
Estacion1
Monitor de la estacion 1 (carga camisas de cilindros) Define el orden y nombre de las
variables de entrada y salida.
Estacion2
Monitor de la estacion 2 (ensamblaje muelles y embolos) Define el numero y nombre de las
variables de entrada y salida.
Estacion3
Monitor de la estacion 3 (montaje de culatas) Define el numero y nombre de las variables de
entrada y salida.
Estacion4
Monitor de la estacion 4 (verificador de conjuntos) Define el numero y nombre de las
variables de entrada y salida.
Transporte
Monitor del transporte, define el numero y nombre de las variables de entrada y salida.
Jerarquía de clases
o
java.lang.Object
o
estaciones.Estacion
o
Carlos Mediavilla Martí
estaciones.Estacion1
121
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
o
estaciones.Estacion2
o
estaciones.Estacion3
o
estaciones.Estacion4
o
estaciones.Transporte
Figura H.4. Clases relacionadas con la clase Estacion
H.8. Producción
Permite el control de la producción de la célula mediante la gestión de pedidos y palets.
Resumen de clases
ControlProduccion
Clase para la gestion de pedidos y palets en la celula de fabricacion.
Palet
Clase que modela un palet (de 1 hueco) de la celula de fabricacion, contiene las
caracteristicas actuales de la pieza que hay sobre el palet, tales como tipo de pieza,
color, tapa, etc...
Pedido
Implementa un pedido de una pieza de la célula, los pedidos estan caracterizados por:
el tipo de pieza que se tiene que fabricar, un numero de orden, estado actual del pedido
y fecha en que se creo.
Jerarquía de clases
o
java.lang.Object
o
produccion.ControlProduccion
o
produccion.Palet (implements java.io.Serializable)
o
produccion.Pedido (implements java.io.Serializable)
Figura H.5. Clases relacionadas con la clase Produccion
Carlos Mediavilla Martí
122
20/07/06
Anexo H. Implementación Java
H.9. PuertoSerie
Contiene las clases que gestionan la comunicación con el identificador de productos a través del puerto
serie del PC. Aunque estas clases se han pensado para comunicar con el identificador de productos a
través del puerto serie, una mejora inmediata de la aplicación es gestionar el identificador como un
dispositivo PCP a través de Interbus
Resumen de clases
IdentificadorProductos
Clase que modeliza el identificador de productos de la celula de fabricacion,
mediante el cual leemos y escribimos los cabezales magnéticos de los palets de la
célula.
PaletPuertoSerie
Provee los metodos necesarios para pasar la informacion contenida en un palet a
una trama enviable al identificador de productos y viceversa.
Trama
La clase Trama encapsula la cadena de bytes que hay que mandar al identificador
de productos vía puerto serie,
se proporcionan metodos que implementan el protocolo que se comunica mediante
RS-232 con el identificador de productos.
PuertoSerie
Esta clase se encarga de gestionar la comunicacion por el puerto serie entre el PC y
el identificador de productos.
Jerarquía de clases
o
java.lang.Object
o
puertoSerie.IdentificadorProductos
o
puertoSerie.PaletPuertoSerie
o
puertoSerie.Trama
o
puertoSerie.PuertoSerie (implements javax.comm.SerialPortEventListener)
Diagrama de clases
Figura H.6. Clases relacionadas con la clase PuertoSerie
H.10. RedPetri
Modelo de datos para representar los lugares, transiciones y estructura de una red de Petri que será
ejecutado por uno de los coordinadores del paquete Control.
Resumen de clases
ArcoGrafico
Clase que modela un arco de una red de Petri.
ComparadorPrioridad
Compara dos transiciones segun su prioridad.
ComparadorTiempo
Compara dos transiciones segun el tiempo que les queda para el siguiente disparo.
Carlos Mediavilla Martí
123
20/07/06
Módulo de comunicaciones para una aplicación de control distribuido
Estado
Un estado o lugar representa, junto con el marcado, el estado en que se encuentra
una RdP, obviamente según la definición, un lugar o estado de una RdP se
caracteriza por el número de marcas.
Etiqueta
Texto informativo para la representacion visual de las redes de Petri.
Punto
Clase que implementa un punto geometrico.
Red
Modelado de una red de Petri, la RdP con la que vamos a trabajar es la
representación gráfica y analítica de un sistema, contiene información acerca de la
estructura de la RdP, quedará definida por una lista de estados y transiciones y por
las matrices de incidencia previa y posterior y la matriz de pesos.
Transicion
Clase que modeliza una transición de una Red de Petri, en este modelo las
transiciones representan condiciones que se cumplen (o no)
Dispone de dos listas que contienen los lugares de entrada y salida de la transición, a
partir de dichas listas se conforma la estructura de la red
Una transición puede estar sensibilizada o no sensibilizada dependiendo de si sus
lugares de entrada están marcados o no
El campo prioridad permite al coordinador determinar en caso de conflicto que
transición debe ser disparada, cuanto más alta sea la prioridad, más probabilidad
tendrá la transición de ser la que se dispara.
TransicionSyco
Clase que modeliza una transición Syco.
Jerarquía de clases
o
java.lang.Object
o
redPetri.ArcoGrafico (implements java.io.Serializable)
o
redPetri.ComparadorPrioridad (implements java.util.Comparator)
o
redPetri.ComparadorTiempo (implements java.util.Comparator)
o
redPetri.Estado
o
redPetri.Etiqueta (implements java.io.Serializable)
o
redPetri.Punto (implements java.io.Serializable)
o
redPetri.Red
o
redPetri.Transicion
o
redPetri.TransicionSyco (implements java.io.Serializable)
Diagrama de clases
Figura H.7. Clases relacionadas con la clase Red
Carlos Mediavilla Martí
124
20/07/06
Contenido del CD
ANEXO I. CONTENIDO DEL CD
•
Documentos:
o
o
o
o
Memoria.pdf: memoria del proyecto.
Anexo.pdf: anexos del proyecto.
Portada.pdf: portada del proyecto.
Manuales: los principales manuales, hojas de características y documentos de utilidad que
se han recopilado a lo largo del proyecto.
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
•
Identificador de productos: IVI-KHD2-4HRX.pdf
Bus Interbus: interbus_basics_en.pdf
Interbus y automatización basada en PC.pdf
Tarjeta Interbus: cif_drv.pdf
Comunicadores Ethernet: TSX Momentum 170 INT 110.pdf
Tiempo Real Java: rtj-final-drat.pdf
Protocolo Modbus: PI_MBUS_300-RevJ-Sp0.pdf
Modbus_Messaging_Implementation_Guide_V1_0a.pdf
Desarrollos:
o
Java: contiene el código Java del proyecto, los fuentes en los directorios src y las clases ya
compiladas en el directorio classes:
ƒ
ƒ
ƒ
o
PFC2006: Clases principales del proyecto. Corresponden a los programas que se
ejecutan en la máquina virtual Jamaica en el computador que hace de servidor.
PFC2006Cliente: Clases para el cliente gráfico Java y el puerto serie.
WebCelula: Clases para la aplicación Web. Incluye las páginas JSP, html, hojas de
estilo y applets necesarios para hacer la aplicación Web.
C: implementa el código nativo para la comunicación con Interbus, contiene los siguientes
archivos:
ƒ Archivo de cabecera: codigocom2.h
ƒ Código del programa: codigocom.c
ƒ Librería dinámica: libInterbus.so
ƒ Driver de la tarjeta: cif_api2.o
•
Documentación Java. API:
o PFC2006: Documentación en formato html de este proyecto.
o PFC2006Cliente: Documentación en formato html de este proyecto.
o WebCelula: Documentación en formato html de este proyecto.
•
Tomcat: Contiene el archivo Server.xml para la configuración del servidor web.
•
Redes: Contiene las redes de Petri creadas con el editor Pipe en formato PNML usadas para
definir el comportamiento de la célula.
Carlos Mediavilla Martí
125
20/07/06