SIMULADOR PARA CONTROL Y AUTOMATIZACIÓN...

SIMULADOR PARA CONTROL Y

AUTOMATIZACIÓN UTILIZANDO UN

ENTORNO VIRTUAL 3D INTERACTIVO Y

CONFIGURABLE

Departamento de Sistemas y Automática. Escuela Superior de Ingenieros.

Universidad de Sevilla.

Diciembre 2012

PROYECTO FIN DE CARRERA

AUTOR: D. ADOLFO JUAN SÁNCHEZ DEL POZO FERNÁNDEZ

TUTOR: D. EDUARDO FERNÁNDEZ CAMACHO

CO-TUTOR: D. JUAN MANUEL ESCAÑO GONZÁLEZ

AGRADECIMIENTOS

A mi familia, en especial a mis padres y mis hermanas por estar siempre a mi

lado.

A mis amigos por aguantarme y a Juan Manuel por su apoyo y amistad.

Índice

1 INTRODUCCIÓN 71.1 INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 ESTRUCTURA DEL DOCUMENTO . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 INTRODUCCION TEORICA 122.1 SITUACION DE PARTIDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 DESCRIPCION DE LA APLICACIÓN OBJETIVO . . . . . . . . . . . . . . . . . 12

2.2.1 Conexión mediante Server OPC . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Conexión mediante puerto USB . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 TECNOLOGIAS Y HERRAMIENTAS DE DESARROLLO . . . . . . . . . . . . . 142.3.1 INTRODUCCIÓN A C# Y XNA . . . . . . . . . . . . . . . . . . . . . . . 142.3.2 ENTORNOS DE MODELADO 3D. INTRODUCCION A AC3D. . . . . . . 182.3.3 OPC (OLE FOR PROCESS CONTROL) . . . . . . . . . . . . . . . . . . . 20

3 DISEÑO E IMPLEMENTACION DEL SIMULADOR 243.1 MOTOR FÍSICO Y SISTEMA DE COLISIONES . . . . . . . . . . . . . . . . . . 243.2 ESTRUCTURA DE LA APLICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . 283.3 PROGRAMA PRINCIPAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4 CLASES PARA LOS ELEMENTOS INDUSTRIALES . . . . . . . . . . . . . . . . 31

3.4.1 CINTA TRANSPORTADORA . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.2 PLATAFORMA GIRATORIA + CINTA . . . . . . . . . . . . . . . . . . . 373.4.3 GRÚA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.4 RAMPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.5 DESTRUCTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.6 PISTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.7 SENSORES DE BARRERA . . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.8 MONTACARGAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.9 ROBOT 5 GRADOS DE LIBERTAD . . . . . . . . . . . . . . . . . . . . . 553.4.10 CONEXION CLIENTE OPC - SERVIDOR OPC - PLC . . . . . . . . . . . 613.4.11 CUADRO DE CONTROL Y OPCIONES . . . . . . . . . . . . . . . . . . . 64

4 ESCENARIO PROTOTIPO Y EDITOR DE ESCENARIOS 674.1 ESCENARIO DESARROLLADO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2 EDITOR DE ESCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 MANUAL DE USUARIO 715.1 INSTALACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2 CONFIGURACIÓN DE UNITY PRO . . . . . . . . . . . . . . . . . . . . . . . . . 715.3 CONFIGURACIÓN OPC OFS 3.31 . . . . . . . . . . . . . . . . . . . . . . . . . . 725.4 DESCRIPCIÓN DEL SIMULADOR . . . . . . . . . . . . . . . . . . . . . . . . . . 745.5 OBJETIVOS DEL ESCENARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.6 DESCRIPCIÓN DE LOS ACTUADORES Y SENSORES DEL ESCENARIO . . 775.7 NORMAS PARA LA IMPLEMENTACIÓN DEL PROGRAMA DE CONTROL EN

UNITY PRO XL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.8 CONEXIÓN Y EJECUCIÓN PLC-OPC-SIMULADOR . . . . . . . . . . . . . . . 815.9 MODIFICACIONES DEL PROYECTO EN UNITY PRO . . . . . . . . . . . . . . 835.10 VIDEO DE EJEMPLO DE CONEXION Y FUNCIONAMENTO DE LA PLANTA 84

6 CONCLUSIONES Y FUTURAS LINEAS DE TRABAJO 85

7 BIBLIOGRAFIA 86

Lista de Figuras1 Usuarios de Half-Life 2 interactuando con objetos del escenario. . . . . . . . . . . 72 Imagenes de varios escenarios de ITS PLC. a) Almacen automatizado. b) Mezclado

de pintura. c) Selección y empaquetado de piezas. . . . . . . . . . . . . . . . . . . 83 Imagen mostrando la asignación estática de los sensores y actuadores en un escenario

de ITS PLC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Captura de pantalla de una parte del modelo 3D de la grúa en AC3D. . . . . . . . 195 Captura de pantalla de la texturización de un modelo en AC3D . . . . . . . . . . . 206 Esquema de conexión mediante OPC Server. . . . . . . . . . . . . . . . . . . . . . 207 Esquema de conexión, entradas/salidas e interfaces. . . . . . . . . . . . . . . . . . . 218 Ejemplos de uso de Bullet Physics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Ejemplos de uso de JigLibX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2610 Contacto entre 2 objetos penetrando . . . . . . . . . . . . . . . . . . . . . . . . . . 2711 Objetos con composición geométrica simple a), y compuesta b). . . . . . . . . . . . 2812 Estructura del proyecto JigLibX en Visual Express C#. . . . . . . . . . . . . . . . 2813 Estructura de la aplicación. Diagrama de flujo. . . . . . . . . . . . . . . . . . . . . 2914 Estructura del proyecto de la aplicación en Visual Express C#. . . . . . . . . . . . 2915 Ejemplo de código en C# de la declaración de las variables para incluir mesas

giratorias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3016 Código en C# de la carga de contenidos 3D. . . . . . . . . . . . . . . . . . . . . . 3017 Código C# de uso repetitivo para inicializar un elemento. . . . . . . . . . . . . . . 3118 Código C# de la aplicación. a) Código repetitivo en bucle “for” para la actualización

de elementos de una misma clase. b) Código repetitivo para el renderizado demodelos 3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

19 Estructura de métodos de la clase Elemento Industrial. . . . . . . . . . . . . . . . 3220 Código en C# mostrando la llamada a métodos “Opcionales”, de las clases Grúa y

Cinta2, tras la llamada al motor físico. . . . . . . . . . . . . . . . . . . . . . . . . . 3221 Imágenes pruebas de transporte de un objeto físico por la cinta transportadora. . . 3322 Imágenes de la Cinta transportadora parcialmente texturizada. a) Imagen en reposo.

b) Imagen transportando objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3423 Imágenes del modelado final de la cinta transportadora y la zona de caída de cajas. 3524 Imágenes del renderizado de los objetos físicos que realizan la simulación de la cinta

transportadora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3625 Código en C# que describe el movimiento de la cinta giratoria mediante las variables

de velocidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3826 Imágenes del renderizado de los modelos físicos y 3D de la plataforma giratoria. . . 3927 Código en C# que calcula la posicion y ángulos de los modelos 3D de los rodillos

en función de la velocidad lineal del objeto físico. . . . . . . . . . . . . . . . . . . . 3928 Código en C# del método “Update2” de la plataforma giratoria que se ejecutará

tras el paso por el motor físico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4029 Imagen del modelo completo de la grúa del proyecto, garra abierta y bajada. . . . 4030 Imagen del modelo completo de la grúa del proyecto, garra abierta y subida. . . . . 4131 Imagen del modelo físico que simulará el funcionamiento de la grúa. . . . . . . . . 4132 Imagen del modelo físico que simulará el funcionamiento de la grúa. . . . . . . . . 4233 Imagen de la grúa sosteniendo una caja. . . . . . . . . . . . . . . . . . . . . . . . . 4234 Imagen de la grúa soltándo una caja en movimiento. . . . . . . . . . . . . . . . . . 4335 Código C# que se encarga del funcionamiento de la garra mediante detección de

colisiones añadidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4436 Imágenes de los modelos a) 3D , b) físico de la rampa. . . . . . . . . . . . . . . . . 4537 Código en C# de la declaración e inicialización de un elemento Rampa. . . . . . . 4638 Imágenes del renderizado 3D de un Destructor. . . . . . . . . . . . . . . . . . . . . 4639 Imágenes del renderizado del modelo físico de un Destructor. . . . . . . . . . . . . 47

40 Código en C# para chequear las colisiones del objeto físico del Destructor con otrosobjetos del escenario y eliminarlos encaso positivo. . . . . . . . . . . . . . . . . . . 47

42 Código en C# donde se declaran las variables de objetos físicos. . . . . . . . . . . . 4841 Imágenes del Pistón. a) Modelo 3D pistón recogido b) Modelo 3D pistón extendido. 4943 Código en C# para la simulación del movimiento del pistón. . . . . . . . . . . . . 5044 Imagen del pistón doble en resposo sobre la cinta transportadora. . . . . . . . . . . 5045 Imagen del pistón doble empujando una caja. . . . . . . . . . . . . . . . . . . . . . 5146 Imagen del Sensor de barrera. Modelo 3D del Sensor con rayo. . . . . . . . . . . . 5147 Imágenes del Sensor de barrera. a) Contacto límite entre objeto y sensor activandose.

b) Objeto cercano sin colisionar con el sensor de barrera. . . . . . . . . . . . . . . . 5248 Código C# que muestra como se detecta la colisión con el segmento y la

comprobación de ID’s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5249 Imagen del modelado 3D del montacargas detenido. . . . . . . . . . . . . . . . . . 5350 Imagen del modelado 3D del montacargas subiendo un objeto. . . . . . . . . . . . . 5451 Imagen de la estructura física que conforma el montacargas. . . . . . . . . . . . . . 5452 Código en C# del método Update de la grúa donde se controla el movimiento de

las distintas partes y se reajustan al comienzo del mismo. . . . . . . . . . . . . . . 5554 Imágenes de los modelos físicos del brazo de 5 grados. 4 elementos más la garra. . 5653 Imágenes del brazo en 3 posiciones diferentes. . . . . . . . . . . . . . . . . . . . . 5755 Código en C# de los objetos físicos y otras variables del brazo. . . . . . . . . . . . 5856 Código en C# de la inicialización y adición al motor físico de los objetos. . . . . . 5957 Código en C# del control de la primera sección del brazo. La sección 0 es la base. 5958 Código en C# del control de la segunda sección del brazo. . . . . . . . . . . . . . . 6059 Código en C# del control de la tercera sección del brazo. . . . . . . . . . . . . . . 6060 Código en C# del control de la garra sección del brazo. . . . . . . . . . . . . . . . 6161 Captura de pantalla del formulario de conexión Cliente - Servidor OPC. . . . . . . 6262 Código del método para la lectura de actuadores del servidor. . . . . . . . . . . . . 6363 Código del método de escritura de sensores no prioritarios en el servidor OPC. . . 6365 Código de la declaración de variables que contendrán las imágenes para los elementos

del cuadro de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6464 Imágenes del cuadro de actuadores de la aplicación. a) Cuadro de actuadores, b)

Cuadro de sensores y c) Cuadro de conexión OPC. . . . . . . . . . . . . . . . . . . 6566 Código para posicionar los elementos en el mismo lugar sin importar el tamaño de

la ventana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6667 Código para la detección de pulsado de botones en la aplicación. En este caso se

comprueban los 15 primeros actuadores. . . . . . . . . . . . . . . . . . . . . . . . . 6668 Captura de la planta de clasificado de cajas. Vista superior. . . . . . . . . . . . . . 6769 Captura de la planta de clasificado de cajas. . . . . . . . . . . . . . . . . . . . . . . 6870 Captura de la planta de clasificado de cajas. . . . . . . . . . . . . . . . . . . . . . . 6871 Captura de la planta de clasificado de cajas. . . . . . . . . . . . . . . . . . . . . . . 6972 Capturas de pantalla del Editor de Escenarios. . . . . . . . . . . . . . . . . . . . . 7073 Captura de pantalla creación de un dispositivo en OFS . . . . . . . . . . . . . . . . 7274 Captura de pantalla creación de un dispositivo en OFS . . . . . . . . . . . . . . . . 7375 Captura de pantalla parámetros de un dispositivo en OFS . . . . . . . . . . . . . . 7376 Escenario del Simulador. Pestaña Actuadores y cuadro de control. . . . . . . . . . 7477 Rampa de salida para las cajas grandes (DANGER escrito en laterales) . . . . . . 7578 Rampa de salida para las cajas pequeñas . . . . . . . . . . . . . . . . . . . . . . . . 7679 Posiciones y sensores de la grúa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7880 Sensores de la Plataforma giratoria. . . . . . . . . . . . . . . . . . . . . . . . . . . 7881 Sensores de barrera prioritario llegada y clasificación de cajas. . . . . . . . . . . . . 8082 Sensores de barrera para el envío de cajas a sus respectivas salidas. . . . . . . . . . 8083 a) Imagen de la pestaña de conexión OPC, b) Imagen de los formularios de conexión. 82

1 INTRODUCCIÓN

1 INTRODUCCIÓN

1.1 INTRODUCCIÓN

El uso de simuladores facilita en gran medida el trabajo de los especialistas. Su uso produceresultados que permiten prevenir errores en los sistemas reales. Mediante el uso de un simuladorpara entornos industriales se reduciría el tiempo de programación y depuración de las mismas. Perose puede ir más allá de estos conceptos si se habla en materias de educación y prácticas mediante eldesarrollo de una plataforma de simulación de maquinaria industrial, mediante realidad virtual en3D, para la realización de prácticas de programación de PLC’s (Programable Logic Controllers).

Año tras año, la industria de los videojuegos nos sorprende con sus lanzamientos. A medidaque pasan los años, los videojuegos mejoran en calidad gráfica, jugabilidad, interactividad con elusuario etc. El volumen de ventas de videojuegos crece con los años y esto repercute directamenteen el propio desarrollo de posteriores lanzamientos.

Actualmente existen diferentes tipos de videojuegos como los RTS (Real Time Strategy), FPS(First Person Shooter), RPG (Role Playing Game) etc. Pero si bien todos los tipos de juegosgeneran importantes ingresos anualmente, 631M€ en España en 2010 obtenida de [6], para esteproyecto interesan especialmente los FPS. Éstos son juegos en primera persona en los cuales elusuario se introduce en la piel del personaje en un mundo virtual con ciertos objetivos. El primerFPS apareció en el año 1973 de la mano de Steve Colley bajo el nombre Maze Wars. A medidaque pasaron los años, los FPS mejoraron en varios aspectos y aunque el primero de ellos fue lacalidad gráfica, en la actualidad no es el único en desarrollo y mejora. Actualmente los aspectosmás valorados son la conectividad, interactividad con el entorno y la calidad del sistema físico delvideojuego.

En los videojuegos actuales los usuarios interactuan con los objetos de su entorno; puedencogerlos, tirarlos y empujarlos para sus propios propositos. Un ejemplo de esto se da en Half-Life2, la secuela de Half-Life, lanzado al mercado en 2004 y que permite una gran interacción con elentorno, ver Figura 1. Llegados a este punto, surge la cuestión: si a los videojuegos se les incluyeun sistema físico muy realista para hacerlos más atractivos, ¿por qué no hacer lo mismo con lossimuladores industriales y diseñarlos en 3D? Una simulación de entornos industriales realista conlos objetos del propio sistema sería útil para la programación y prevención de fallos que pudieranocurrir debido a los mismos objetos. Además, implícitamente, se hace más atractiva visualmente.

Figura 1: Usuarios de Half-Life 2 interactuando con objetos del escenario.

Simulador para control y automatización. 7 de 86

1 INTRODUCCIÓN

a)

b) c)

Figura 2: Imagenes de varios escenarios de ITS PLC. a) Almacen automatizado. b) Mezclado depintura. c) Selección y empaquetado de piezas.

1.2 ESTADO DEL ARTE

Existen actualmente propuestas comerciales que, en un entorno interactivo en 3D, incluyen unsistema físico realista, como es el caso de “ITS PLC” de Realgames (www.realgames.pt). Laconectividad de este simulador se realiza mediante una tarjeta de entradas y salidas y conexiónmediante USB con el PC, lo que lo hace flexible a la hora de usar el controlador industrial.

Éste software dispone de 5 escenarios. Algunas imágenes se muestran en la figura 2. Éstospretenden simular plantas industriales sencillas de procesado de distinto tipo. Pone a disposicióndel usuario un total de 10 sensores y 8 actuadores para realizar la programación de la planta.Aunque los actuadores y sensores están preasignados a los diferentes elementos de la planta y nose pueden modificar, ver figura 3.

Proporciona un cuadro de mandos para que el usuario pueda detener, pausar, resetear y cambiarde manual a automático la ejecución de la planta.

Por último, se dispone de una sección de fallos. Se puede decidir si un actuador o un sensortiene un fallo, simulando de esta forma que los dispositivos de la planta se pueden estropear.

Sin embargo, está formado por un número determinado de plantas industriales preprogramadas.Otra limitación es el número de actuadores y sensores disponibles y su asignación rígida a loselementos de los escenarios.


1 INTRODUCCIÓN

Figura 3: Imagen mostrando la asignación estática de los sensores y actuadores en un escenario deITS PLC.

Aunque la aplicación es muy realista respecto a la física de los objetos y la sección de creaciónde fallos en los dipositivos de los escenarios, se limita a:

• Funcionamiento normal.

• Fallo. El dispositivo deja de funcionar completamente.

Aunque se ha encontrado otra aplicación parecida no se va a comentar, por ser ITS PLC la máscompleta y con mejor calidad observada, además de haberse utilizado por el autor del documentoen el laboratorio.

1.3 OBJETIVOS

En este documento se presenta el desarrollo de una plataforma 3D que permitirá la simulación deentornos industriales.

La decisión de realizar esta plataforma como Proyecto Final de Carrera viene tras habercomprobado las carencias de las aplicaciones existentes en el ámbito de la educación en control yautomatización. Es decir, el objetivo de este proyecto es el de obtener una aplicación que incluyatodas posibilidades que se creen necesarias para que la experimentación en laboratorio con PLC’sy su programación sea más completa.


1 INTRODUCCIÓN

A diferencia de otros, el software desarrollado es Open Source (Código Libre), pues se harealizado utilizando aplicaciones de libre distribución y de código libre. Incluyendo la parte deprogramación de la aplicación, este proyecto también incluye una parte de integración de otroselementos necesarios para llevar a cabo su desarrollo. Además gozará de todas las carencias quepuedan tener otras aplicaciones de pago como ITS PLC.

Las características principales y requisito esencial de la aplicación que se ha desarrollado son:

• Escalabilidad.

• Programabilidad.

• Configurabilidad.

• Conectividad.

La plataforma en cuestión estará formada por dos aplicaciones principales:

1. Simulador Principal.El simulador es la aplicación básica y la primera en desarrollarse. Será un simulador en 3De incluirá un sistema físico.

2. Editor de escenarios.Esta aplicación, aunque secundaria, es la clave para que la plataforma goce de una granescalabilidad a nivel de usuario. Con esta herramiento un usuario podrá diseñar un simuladormediante el uso de los elementos industriales disponibles. Ofrecerá al usuario la posibilidadde escoger de entre un listado de elementos, posicionarlos, orientarlos, añadir sensores etc.Básicamente será un constructor de mundos más comunmente llamado, en terminologíaanglosajona de videojuegos, “WorldBuilder”.

Posteriormente al diseño del escenario se generará un archivo que podrá utilizar en elsimulador.

El simulador obtenido deberá ser capaz de conectarse con un PLC o bien con un simulador dePLC. Para esto se han barajado diferentes opciones:

• La primera sería realizar una conexión física con un PLC comercial mediante los puertosUSB o Serie RS232C adaptando las señales mediante una tarjeta de adquisición de datos.

• La segunda opción para la conexión sería utilizar un OPC Server (Ole Process Control)como plataforma intermedia para el paso de datos entre PLC - Simulador. Parece ser unabuena opción ya que es una solución abierta y flexible al clásico problema de los driverspropietarios, con la ventaja añadida que la mayoría de los grandes fabricantes incluyen OPCen sus productos.

Algunos fabricantes de PLC’s suministran una aplicación que simula el comportamiento delPLC [9] y al ejecutarse constituye un proceso independiente que utiliza los drivers propios paracomunicar con el entorno de programación. Esto permite contar con la ventaja de no necesitarseun PLC comercial para realizar la programación del simulador. Con todo esto un usuario seríacapaz de diseñar, programar, compilar, ejecutar y comprobar los errores de una planta industrial,sin necesidad de acceso a la maquinaria real. Los aspectos más importantes para la realización deeste software, que serán tratados en los siguientes apartados, son el sistema físico, el sistema decolisiones y el desarrollo de maquinaria industrial.


1 INTRODUCCIÓN

Aunque los objetivos principales se han descrito, queda un último objetivo que se va a comenzaren este proyecto pero que no se va a desarrollar por completo por el tiempo que ello conllevaría.Éste último objetivo se desarrollará en la sección 6 “Futuras Líneas de Trabajo”. Se inciará latarea de modificar la solución para que la plataforma pueda ser ampliada y mejorada por personasajenas al proyecto de forma remota.

1.4 ESTRUCTURA DEL DOCUMENTO

El documento está dividido en varias secciones que se pueden dividir en tres partes fundamentales:

1. Una parte de introducción teórica.Donde se describirán aspectos teóricos generales necesarios para un buen entendimiento delresto del documento.

2. Una parte de diseño de la plataforma.En esta parte es donde se desarrollará como se ha realizado la aplicación entrandodirectamente en las partes más relevantes del código de programación utilizado.

3. Manual de Usuario.Se detallará todo lo necesario para la instalación y puesta en marcha del software para uncorrecto funcionamiento de la aplicación.


2 INTRODUCCION TEORICA


2.1 SITUACION DE PARTIDA

Como se ha comentado anteriormente, este proyecto se comenzó desde la iniciativa propia y la visiónde un software con unas posibilidades que no se encuentra en la actualidad de forma comercial.Debido a esto la situación de partida ha sido prácticamente desde cero. Se sabía lo que se queríade la aplicación pero no muy bien como realizarla.

Inicialmente, como en todo proyecto, se buscaron las posibilidades para poder diseñar yprogramar la plataforma 3D. Se indagó en el mundo de los videojuegos, pues el autor ya conocealgunos juegos que incluyen algunos constructores muy utilizados por los usuarios, como es elcaso de “Garry’s MoD”. De esta forma se iban recogiendo diferentes posibilidades de lenguajesde programación para el desarrollo de la aplicación en cuestión. También se investigó un poco elcontenido de ITS PLC por si se pudiera obtener alguna idea acerca de su estructura de archivos.Y así es como ocurrió. Se averiguó como estabá desarrollada la parte gráfica de ITS PLC. Éstoaceleró el trabajo de busqueda pues ya no se buscaba a ciegas sino algo más concreto.

Aunque al principio se pensó que el desarrollo de la aplicación llevaría mucho tiempo, una vezse decidieron tanto el lenguaje de programación como la base para el desarrollo de objetos en 3D, elavance de la aplicación fue bastante rápido. Aproximadamente la situación de partida se desarrollótemporalmente como sigue:

• 1 mes para la busqueda y aprendizaje del lenguaje de programación y la base de desarrolloen 3D.

• 1 mes para comenzar a tener los primeros resultados viables en cuanto a elementosindustriales.

A partir del comienzo del tercer mes todo fue fluido y se desarrollaron sin demasiados problemasotros elementos industriales que se detallarán más adelante.

Aproximadamente al comienzo del quinto mes ya se disponía de un escenario funcional queincluía cintas transportadoras, grúa, plataformas para trasladar objetos, sensores de barrera,pistones, rampas de carga y un modelado básico en 3D texturizado parcialmente.

El quinto més y el sexto se dedicaron a optimizar la programación de los elementos desarrolladosy dotarlos de una estética 3D más realista, así como el planteamiento y la creación de nuevoselementos y resolución de errores observados durante los tests de pruebas del prototipo.

2.2 DESCRIPCION DE LA APLICACIÓN OBJETIVO

Antes de empezar a programar la aplicación, hay que pensar cuidadosamente como va a ser. Hayque razonar como de lejos se prentede llegar con esta plataforma y ver como sería la plataformasi ya estuviera realizada. Ésto conlleva un problema. Es posible que se exija demasiado y no sepueda llevar a cabo. Aunque dadas las características de los lenguajes de programación orientadosa objetos, se concluyó que la mejor opción de conseguir el software deseado era de la forma quese ha planteado. Decidir el alcance que va a tener la aplicación es fundamental pues a la hora derealizar la programación del mismo se tendrán en cuenta las características, y el código se ajustaráa las funciones que tenga que realizar. De otra forma se tendría que ir modificando toda la solución.No obstante, las características que se comentarán son las básicas que debe tener la plataforma



en conjunto, siendo necesario a medida que avance la programación modificar o añadir parte delcódigo ya existente para optimizar e incluir nuevas funcionalidades.

Siguiendo este planteamiento se comienza determinando que debe ofrecer la aplicación alusuario. Debe poder ser escalable. La aplicación no puede quedarse estancada en un númerodeterminado de escenarios de simulación como ocurre en ITS PLC. Y el usuario debería ser capazde poder crear escenarios propios y ajustados a sus necesidades.

No solo debe ser escalable sino que también debe ser configurable. A la hora de incluir undispositivo, como por ejemplo una cinta transportadora, el usuario debería ser capaz de configurarsu comportamiento. Las cintas no son todas iguales, ni en forma, tamaño o dinámica. Aquí entraen juego el término configuración. El usuario podrá incluir la función de transferencia que modelala dinámica de la cinta transportadora. En este caso podría ser la función de transferencia de losmotores que mueven la cinta. De esta forma con un único dispositivo programado en la aplicación elusuario tiene posibilidades de adaptar su comportamiento y con ello obtener dispositivos diferentes.

Una opción muy interesante es la de incluir programación en el simulador. Esta programaciónestá referida a elementos o dispositivos que se utilicen a nivel industrial y necesiten de unaprogramación separada de la del PLC, como puede ser un brazo robótico para la seleción depiezas, soldaduras, ensamblajes etc. Poniendo como ejemplo el SCORBOT, y usándolo como basepara un posible dispositivo del simulador, se incluirá en el simulador la herramienta necesariapara realizar la programación de las acciones que deba hacer el brazo ante las señales de entradaprocedentes del PLC. La programación se realizará con un pequeño conjunto de las instruccionesdel lenguaje ACL.

Dado que se está hablando de diseñar una plataforma para el entrenamiento con PLC’s es muyimportante pensar en como se va a hacer la conexión con el PLC. Aquí se tienen varias posibilidadesde las cuales solo una de ellas es la que se realizará en este proyecto.

2.2.1 Conexión mediante Server OPC

Con un servidor OPC (Ole Proccess Control), se puede establecer una conexión entre un PLC realy un PC que contenga el simulador y un cliente OPC. El servidor OPC será el intermediario parael intercambio de datos entre ambos equipos. Para la conexión de los equipos solo haría falta unared ethernet pues actualmente los PLC’s disponen de puerto ethernet así como los PC’s.

Esta sería una conexión física posible. Pero si se hace uso de un servidor OPC, también se puedehacer una conexión no física entre los equipos. Se puede conseguir si se utilizan simuladores de PLC.Algunas compañías como Schneider Electric incluyen en el software de sus PLC’s herramientas desimulación de PLC’s. En pocas palabras, se puede tener en un mismo PC las tres aplicaciones paraestablecer una conexión local interna y poder realizar la simulación y el control sin la necesidad deusar un PLC real.

El hecho de no necesitar un PLC real implica un ahorro importante pues son dispositivos caros.Otro aspecto importante son las averías. Con esta forma de conexión el riesgo de avería debidoa un mal uso por parte del usuario es inexistente. Otra ventaja añadida de no usar PLC’s, es elnúmero de puestos de trabajo que se pueden utilizar. Ahora solo son necesarios PC’s, pudiendoseampliar a un costo menor el número de estaciones disponibles para el alumnado. El único requisitode los PC’s, que se comentará más adelante, es que dispongan de una buena tarjeta gráfica.



2.2.2 Conexión mediante puerto USB

A parte de poder establecer comunicación tanto por red como de forma local entre el PLC y elsimulador, también es conveniente tener la posibilidad de realizar una comunicación física directa.

Una de las opciones es hacerla por USB, mediante el uso de una tarjeta de adquisición de datos.

2.3 TECNOLOGIAS Y HERRAMIENTAS DE DESARROLLO

En éste apartado se describirán las herramientas que se han utilizado para desarrollar la aplicación.Entre otros, se detallan el lenguaje de programación, las librerías 3D y otros programas utilizadospara llevar a cabo este proyecto.

2.3.1 INTRODUCCIÓN A C# Y XNA

Debido a que este proyecto es el desarrollo de una aplicación escoger un lenguaje de programaciónadecuado es fundamental. Aunque en principio se podría utilizar cualquier lenguaje orientadoa objetos actual tales como JAVA, C++, C# o Lua, éste último muy utilizado en el desarrollode videojuegos, se optó por indagar cuál de ellos sería un lenguaje óptimo para el desarrollo delsimulador dado que se comenzaba este proyecto desde cero.

Inicialmente y dado que no se sabía programar en JAVA, se descartó inicialmente dejándolocomo última opción. Sin embargo una opción viable de lenguaje a utilizar es Lua. Lua es unlenguaje de extensión, suficientemente compacto para usarse en diferentes plataformas. En Lua lasvariables no tienen tipo, sólo los datos y pueden ser lógicos, enteros, números de coma flotante ocadenas. Estructuras de datos como vectores, conjuntos, tablas hash, listas y registros pueden serrepresentadas utilizando la única estructura de datos de Lua: la tabla. La semántica de Lua puedeser extendida y modificada redefiniendo funciones de las estructuras de datos utilizando metatablas.Lua ofrece soporte para funciones de orden superior, recolector de basura. Combinando todo loanterior, es posible utilizar Lua en programación orientada a objetos.

Los programas en Lua no son interpretados directamente, sino compilados a código bytecode,que es ejecutado en la máquina virtual de Lua. El proceso de compilación es normalmentetransparente al usuario y se realiza en tiempo de ejecución, pero puede hacerse con anticipaciónpara aumentar el rendimiento y reducir el uso de la memoria al prescindir del compilador. Tambiénes posible la compilación en tiempo de ejecución utilizando LuaJIT.

Debido a que Lua compilado es pequeño, veloz y tiene una licencia permisiva ha ganadoseguidores entre los desarrolladores de videojuegos. Algunos usos de Lua:

• World of Warcraft.

• S.T.A.L.K.E.R.: Shadow of Chernobyl.

• Wolfenstein: Enemy Territory.

• Mod de tipo sandbox para Half-Life 2 llamado Garry’s Mod.

• Mod para Half-Life 2 llamado Fortress Forever.



Tras conocer un poco sobre Lua, pasó a ser la primera de las opciones en cuanto a lenguajede programación. No obstante se continuó la busqueda viendo lo que ofrecía C#. C# si es,a diferencia de Lua, un lenguaje orientado a objetos. Finalmente la opción de usar Lua comolenguaje se desechó, no porque no ofreciera las características necesarias, sino por la renderizaciónen 3D. Paralelamente a la busqueda del lenguaje de programación también se realizó la busquedade librerías que permitieran programar el renderizado en 3D para el simulador. Se encontró unframework desarrollado por Microsoft para el desarrollo de juegos independientes para la consolade videojuegos XBox. Con este framework los programadores independientes podían desarrollarvideojuegos y colgarlos gratuitamente o de pago en la comunidad de jugadores online. Esteframework es XNA y permite el renderizado en 3D incluyendo una buena documentación. Dadoque el disponer de una buena documentación es importante y tras observar algunos de los resultadosque obtenian los programadores utilizando XNA, se decidió que sería la librería para realizar laprogramación 3D del simulador. Debido a que está implementada utilizando C# y que tanto XNAcomo C# gozaban de las características necesarias para la implementación del simulador en 3Ddeseado, se escogio el dúo C# - XNA para el desarrollo de este proyecto.

1. Lenguaje orientado a objetos C# (C sharp)

C# es un lenguaje de programación orientado a objetos desarrollado y estandarizado porMicrosoft como parte de su plataforma .NET, que después fue aprobado como un estándar porla ECMA (ECMA-334) e ISO (ISO/IEC 23270). C# es uno de los lenguajes de programacióndiseñados para la infraestructura de lenguaje común.

Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma .NET,similar al de Java, aunque incluye mejoras derivadas de otros lenguajes.El nombre C Sharp fue inspirado por la notación musical, donde ’#’ (sostenido, en ingléssharp) indica que la nota (C es la nota do en inglés) es un semitono más alta, sugiriendo queC# es superior a C/C++. Además, el signo ’#’ se compone de cuatro signos ’+’ pegados.

Aunque C# forma parte de la plataforma .NET, ésta es una API, mientras que C# esun lenguaje de programación independiente diseñado para generar programas sobre dichaplataforma. Ya existe un compilador implementado que provee el marco Mono - DotGNU,el cual genera programas para distintas plataformas como Windows, Unix, Android, iOS,Windows Phone, Mac OS y GNU/Linux.

Algunas características de C# son:

• Todo método debe ser parte de una clase, no existen métodos globales (funciones).• Por defecto, los parámetros se pasan por valor. (Notese que las listas y otras colecciones

son variables por referencia (referencias al espacio reservado para esa lista en la pila) yque se pasa por valor al método la referencia , pero el espacio reservado para la lista escomún, por lo que si elimina un elemento lo hace también de la original)

• El modificador ref fuerza a pasar los parámetros por referencia en vez de pasarlos porvalor y obliga a inicializar la variable antes de pasar el parámetro.

• El modificador out es similar al modificador ref, con la diferencia de que no se obliga ainicializar la variable antes de pasar el parámetro.

• Cuando ref y out modifican un parámetro de referencia, la propia referencia se pasa porreferencia.



• El modificador params sirve para definir un número variable de argumentos los cualesse implementan como una matriz.

• Un método debe tener como máximo un único parámetro params y éste debe ser elúltimo.

• Un método puede devolver cualquier tipo de dato, incluyendo tipos de clase.• Ya que en C# las matrices se implementan como objetos, un método también puede

devolver una matriz (algo que se diferencia de C++ en que las matrices no son válidascomo tipos de valores devueltos).

• C# implementa sobrecarga de métodos, dos o más métodos pueden tener el mismonombre siempre y cuando se diferencien por sus parámetros.

• El método Main es un método especial al cual se refiere el punto de partida del programa.

El estándar ECMA-334 lista las siguientes metas en el diseño para C#:

• C# es un lenguaje de programación orientado a objetos simple, moderno y de propósitogeneral.

• Inclusión de principios de ingeniería de software tales como revisión estricta de los tiposde datos, revisión de límites de vectores, detección de intentos de usar variables noinicializadas, y recolección de basura automática.

• Capacidad para desarrollar componentes de software que se puedan usar en ambientesdistribuidos.

• Portabilidad del código fuente.• Fácil migración del programador al nuevo lenguaje, especialmente para programadores

familiarizados con C, C++ y Java.• Soporte para internacionalización.• Adecuación para escribir aplicaciones de cualquier tamaño: desde las más grandes y

sofisticadas como sistemas operativos hasta las más pequeñas funciones.• Aplicaciones económicas en cuanto a memoria y procesado.

2. Microsoft XNA

Microsoft XNA es un conjunto de herramientas con un entorno de ejecución administradoproporcionado por Microsoft que facilita el desarrollo de juegos de ordenador y de gestión.Intento para liberar a los desarrolladores de juegos de la creación de "código repetitivo " ytraer diferentes aspectos de la producción de juego en conjunto a un único sistema. XNA esuna herramienta que se anunció el 24 de marzo de 2004, en la Game Developers Conference enSan José, California. La primera comunidad Technology Preview de XNA Build fue lanzadael 14 de marzo de 2006. XNA Game Studio 2.0 fue lanzado en diciembre de 2007, seguidode XNA Game Studio 3.0 en 30 de octubre de 2008.

XNA actualmente abarca secciones de Microsoft Game Development Sections, incluyendo elestándar Kit de desarrollo de Xbox y XNA Game Studio.

XNA Framework se basa en la implementación nativa de .NET Compact Framework 2.0 parael desarrollo de la Xbox 360 y .NET Framework 2.0 en Windows.



Incluye un amplio conjunto de bibliotecas de clases, específicas para el desarrollo de juegos,para promover la reutilización de código máximo a través de plataformas de destino. El marcose ejecuta en una versión de Common Language Runtime que se ha optimizado para que losjuegos de azar proporcionar un entorno de ejecución administrado. El tiempo de ejecuciónestá disponible para Windows XP, Windows Vista y Xbox 360. Dado que XNA Games estánprogramados para el tiempo de ejecución, que se ejecuten en cualquier plataforma que admiteel XNA Framework con mínima o ninguna modificación. Juegos que se ejecutan en el marcotécnicamente pueden escribirse en cualquier lenguaje compatible con .NET, pero oficialmentese admiten sólo C# y XNA Game Studio Express IDE y todas las versiones de Visual Studio2005.

El XNA Framework por lo tanto encapsulado bajo nivel tecnológicos detalles relacionadosen un juego de codificación, asegurándose que el propio marco se encarga de la diferenciaentre plataformas cuando los juegos son portados desde una plataforma compatible a otralo que permite que los desarrolladores de juegos para concentrarse más en el contenido y laexperiencia de juego. XNA Framework se integra con una serie de herramientas, tales comola plataforma múltiple audio creación herramienta (XACT), para ayudar en la creación decontenido. XNA Framework proporciona apoyo para la creación de juego 2D y 3D y permiteel uso de los controladores de Xbox 360 y vibraciones. Sólo los juegos de marco XNAactualmente destinadas a la plataforma Xbox se pueden ser distribuidos a los miembros deClub de la Microsoft XNA Creator que lleva un $ 99/año suscripción. Desktop applicationspueden ser distribuidas gratuitamente bajo licencia actual de Microsoft.

Las versiones que ha lanzado Microsoft son las siguientes:

• XNA Game Studio 2.0

XNA Game Studio 2.0 fue lanzado en 13 de diciembre de 2007.8 XNA Game Studio2.0 ofrece la posibilidad de que se utiliza con todas las versiones de Visual Studio 2005(incluido el free Visual C# 2005 Express Edition), una API de red usando Xbox Liveen Windows y Xbox 360 y mejor dispositivo manipulación.

• XNA Game Studio 3.0 (para Visual Studio 2008 o para free Visual C# 2008 ExpressEdition).

Permite la producción de juegos de la plataforma de Zune y agrega soporte de lacomunidad de Xbox Live. Una versión beta del conjunto de herramientas de se lanzó enseptiembre de 2008. La versión final fue lanzada el 30 de octubre de 2008. XNA GameStudio 3.0 ahora es compatible con C# 3.0, LINQ y la mayoría de las versiones de VisualStudio 2008. También hay varias características nuevas de más de XNA Game Studio3.0, tales como un modo de prueba se agrega a XNA Game Studio 3.0 que permitirá a loscreadores agregar fácilmente la función de prueba necesario para sus juegos, funcionesde varios jugadores XBOX LIVE como en el juego invita, crear juegos de plataformasque funcionan en Windows, Xbox 360 y Zune.


Se anunció en la Game Developers Conference en San Francisco el 24 de marzo de 2009.La API es incluir el soporte para la reproducción de vídeo, una API revisada de audio,



sistema de parte de Xbox Live y soporte para juegos utilizar la Xbox 360 Avatars.Esta versión del software está disponible para su descarga como parte del programa deDreamSpark de Microsoft por parte de los alumnos.


Es lo que dará la competencia directa con el iPod de Apple ya que permite desarrollarjuegos y aplicaciones para el Windows Phone 7 aparte de tener un mercado en línea,en donde los desarrolladores suben sus aplicaciones y los usarios del teléfono inteligentepueden comprar o probar las aplicaciones, como se ha visto en el Xbox 360. Cabedestacar la adicion de México para el mercado y que este estará disponible para uso en30 países.

2.3.2 ENTORNOS DE MODELADO 3D. INTRODUCCION A AC3D.

En este momento del proyecto se tienen los elementos principales para poder programar el simuladory realizar el renderizado 3D de los objetos mediante C# y XNA. No obstante, es necesario diseñarlos objetos 3D antes de poder renderizarlos por pantalla. Para poder hacer ésto se necesita unsoftware de diseño 3D.

Entre los más utilizados están:

• 3ds Max Studio.Autodesk 3ds Max (anteriormente 3D Studio Max) es un programa de creación de gráficosy animación 3D desarrollado por Autodesk, en concreto la división Autodesk Media &Entertainment (anteriormente Discreet). Creado inicialmente por el Grupo Yost paraAutodesk, salió a la venta por primera vez en 1990 para DOS.3ds Max, con su arquitectura basada en plugins, es uno de los programas de animación 3Dmás utilizado, especialmente para la creación de video juegos, anuncios de televisión, enarquitectura o en películas.

• Blender 3D.Blender es un programa informático multiplataforma, dedicado especialmente al modelado,animación y creación de gráficos tridimensionales.El programa fue inicialmente distribuido de forma gratuita pero sin el código fuente, conun manual disponible para la venta, aunque posteriormente pasó a ser software libre.Actualmente es compatible con todas las versiones de Windows, Mac OS X, Linux, Solaris,FreeBSD e IRIX.Tiene una interfaz gráfica de usuario muy peculiar , que es criticada como poco intuitiva,pues no se basa en el sistema clásico de ventanas; pero tiene a su vez ventajas importantessobre éstas, como la configuración personalizada de la distribución de los menús y vistas decámara.

Tanto 3ds Max, como Blender son programas excesivamente complejos y requieren de numerosashoras de estudio para el diseño de modelos 3D. Por lo que se buscaron otras opciones para realizarlos modelos 3D que se incluirán en el simulador.



Tras buscar otros programas que permitieran el modelado 3D se encontró uno que incluíamuchas de las opciones de 3ds Max y Blender, con una interfaz gráfica muy parecida, pero con unasimplicidad de implementación de modelos mediante menús intuitivos que hacen de este softwareuna herramienta fácil de utilizar. Este software es AC3D.

En la figura 4 se muestra una captura de pantalla del software con uno de los modelos que seha incluido en el simulador 3D desarrollado en este proyecto.

Figura 4: Captura de pantalla de una parte del modelo 3D de la grúa en AC3D.

Todos los modelos que se han desarrollado están formados por objetos cúbicos, cilíndricos yesféricos. De esta forma el diseño de un elemento nuevo en 3D en el AC3D se llevará a cabo deforma rápida y sencilla. El programa dispone de funciones básicas booleanas para aplicar entre 2objetos 3D como:

• Unión

• Intersección

• Substracción

• Cortar y Eliminar

La adición de texturas se hace de forma muy simple. Simplemente se agrega al objeto la texturadestino en un formato de dibujo, png, jpeg etc, y se asignarán las diferentes texturas a las diferentessuperficies según el objeto. A los modelos desarrollados se les aplicará una optimización de vérticesy superficies para no sobrecargar los modelos y que la renderización sea óptima.



Figura 5: Captura de pantalla de la texturización de un modelo en AC3D

2.3.3 OPC (OLE FOR PROCESS CONTROL)

Anteriormente se han comentado las posibilidades de conexión entre PLC y simulador 3D. Eneste proyecto se ha realizado el diseño para una conexión directa entre un simulador de PLC y elsimulador 3D. La conexión directa se refiere a una conexión interna en el mismo ordenador dondese ejecutarán todas las aplicaciones, con lo que se realizan conexiones locales. Todo se ejecuta enel mismo PC, lo que permitirá que un usuario pueda llevarse el trabajo a casa. De esta formano será necesario el uso de un PLC real para poder llevar a cabo la programación del autómatay la programación de la planta simulada. Para realizar la conexión entre el simulador de PLC yel simulador 3D mediante conexión directa se ha optado por la utilización de un servidor OPC.Se ha escodigo un servidor OPC por ser un estandar de comunicaciones en el campo del controly supervisión de procesos industriales. De ésta forma la conexión establecida tendra un sistemaintermedio que será el servidor OPC que se encargará del intercambio de datos entre simulador dePLC y simulador 3D.

Figura 6: Esquema de conexión mediante OPC Server.

OPC está basado en tecnología Microsoft, que ofrece un interfaz común para comunicación quepermite que componentes software individuales interaccionen y compartan datos. La comunicaciónOPC se realiza a través de una arquitectura Cliente-servidor. El servidor OPC es la fuente dedatos (como un dispositivo hardware a nivel de planta) y cualquier aplicación basada en OPC



puede acceder a dicho servidor para leer/escribir cualquier variable que ofrezca el servidor. Es unasolución abierta y flexible al clásico problema de los drivers propietarios. Prácticamente todos losmayores fabricantes de sistemas de control, instrumentación y de procesos han incluido OPC ensus productos.

El propósito principal del estándar OPC es proporcionar a las aplicaciones una forma comúnde acceder a los datos de cualquier fuente, como un dispositivo o una base de datos. Gracias a estaforma común de acceso a datos que proporciona OPC los fabricantes de hardware sólo tienen quehacer un conjunto de componentes de programa para que los clientes los utilicen en sus aplicacionesy los fabricantes de software no tienen que adaptar los drivers ante cambios de hardware.

OPC está diseñado principalmente para acceder a datos de un servidor en red. Distintasaplicaciones podrán coger datos de aparatos físicos y llevarlo a SCADA o DCS, o de un servidorSCADA o DCS a una aplicación.

Figura 7: Esquema de conexión, entradas/salidas e interfaces.

Una aplicación cliente OPC, puede conectarse, por medio de una red, a varios servidores OPCproporcionados por uno o más fabricantes. De esta forma no existe restricción por cuanto a tenerun Software Cliente para un Software Servidor, lo que es un problema de interoperabilidad quehoy en día se aprecia con sistemas del tipo propietario. Sistemas de control supervisorio como loson SCADA o DCS pueden comunicarse con un Servidor OPC y proveer a este, información delos dispositivos de campo asociados. De esta forma, aplicaciones cliente OPC de otros fabricantestendrán acceso a estos datos por medio del servidor.

Tipos de servidores OPC:

1. Servidor de Acceso a Datos OPCA un alto nivel, está compuesto por los objetos:

• Servidor: Mantiene la información sobre sí mismo, y unifica los Datos dentro de unGrupo.

• Grupo: Dota de un mecanismo que contiene en forma lógica los ítemes. Se clasifican enpúblico o local.

• Ítem: Es un valor, una condición y permanece o varía en el tiempo. Es una direcciónespecífica de los datos y no la fuente de datos.

2. Servidor de Alarmas, Condiciones y Eventos OPCProvee de Interfaces, donde Clientes OPC son notificados de Sucesos. Estos mecanismos sedefinen como:



• Alarma: Condición anormal de un sistema, por lo que es un caso especial de esta.• Condición: Estado nombrado evento por contener condiciones asociadas a una etiqueta

como HighAlarm, Normal, LowAlarm.• Evento: Ocurrencia perceptible, de importancia al servidor OPC, de los dispositivos que

representa o de sus dispositivos OPC.

3. Servidor de Acceso a Datos Históricos OPC (OPC HDA)Provee de una interfaz Cliente OPC de Acceso a Datos Históricos, que facilita el uso deaplicaciones de acceso a datos. Características: Arquitectura de comunicación abierta yeficaz, concentrada en el acceso a datos y no en los tipos de datos. Propósito: Permite queaplicaciones (MS Office, Objetos WWW) accedan a datos de un dispositivo o un banco dedatos “In process”. Facilita el desarrollo de aplicaciones sin sacrificar la funcionalidad de laInterfaz Cliente.

4. Intercambio de Datos OPC (OPC DX)Define un conjunto de interfaces que permiten el intercambio de datos, así como lacomunicación "server to server" entre dispositivos y controladores conectados a Ethernet,que utilizan distintos protocolos. OPC-DX permite a los servidores OPC-DA intercambiardirectamente datos sin la exigencia de un cliente OPC intermedio. La mejor manera depensar en un servidor OPC-DX es como un servidor OPC-DA que se puede configurar paraintercambiar datos con otros servidores OPC-DA. Como es el caso de otros servidores OPC,el cliente aún se utiliza para configurar, controlar y vigilar este intercambio de datos.

5. Acceso de Datos XML (OPC XML DA)Se está convirtiendo en el método estándar para el intercambio de datos entre las aplicacionesde empresa y son cada vez más un proceso de control de entornos. OPC XML-DA salió a la luzen 2003 tras varios años de desarrollo, y ofrece un interfaz Simple Object Application Protocol(SOAP) para los objetos OPC DA 2.0/3.0. Esto permite a las aplicaciones cliente ser escritasen Java, Perl, Python, y otros idiomas que soporta SOAP. SOAP y XML Web Services utilizaProtocolo de transferencia de hipertexto (HTTP) y los mecanismos de transporte y, además,proporciona una plataforma neutral más adecuado para el tráfico con base en Internet,en comparación con tecnologías como DCOM. Sin embargo, debido a las limitaciones derendimiento posible, OPC XML-DA es poco probable que se utilice para aplicaciones entiempo real, a pesar de que normalmente se usa de puente entre la empresa y la red decontrol.

6. Arquitectura Unificada OPC (OPC UA)Refleja el objetivo de Microsoft de retirar DCOM en favor de .NET y arquitecturas orientadasa servicio. OPC UA integra la funcionalidad de las anteriores especificaciones (OPC DA,OPC-HDA, OPC A & E, OPC-DX, etc). OPC UA abandona COM / DCOM en favor dedos transportes: SOAP / HTTP (S) y un mensaje binario codificado en la parte superiorde TCP. Es prematuro evaluar la seguridad de OPC UA en relación con DCOM, ya que laAPI OPC UA de seguridad aún está en desarrollo. Sin embargo, dado que ahora existe unamayor conciencia en la OPC Foundation, proveedores OPC, y Microsoft para la necesidadde seguridad, hay poca duda de que .NET proporcionará una base más segura que COM/ DCOM. También hacen mucho más sencillo el desarrollo de clientes y servidores OPC enplataformas que no sean de Microsoft.

7. SeguridadExisten tres niveles de seguridad OPC:

• Seguridad Inválida: Libre acceso entre Cliente/Servidor.



• Seguridad DCOM: Clientes seleccionados tienen acceso limitado a servidores OPC. Nohay un control total sobre sistemas operativos como Linux, Unix.

• Seguridad OPC: El Servidor OPC sirve como un regulador de control de acceso afabricantes de sistemas operativos como Linux y Unix sobre objetos específicos de accesorestringido que son expuestos por el Servidor OPC.


3 DISEÑO E IMPLEMENTACION DEL SIMULADOR


3.1 MOTOR FÍSICO Y SISTEMA DE COLISIONES

La simulación de la física se hace indispensable para visualización de un entorno donde existenobjetos que se mueven e interaccionan con otros. La simulación de la física es una disciplina muyamplia, este trabajo se centra principalmente en la física de objetos rígidos. Debido a que setrabajará en un entorno en 3D se tendrán vectores con tres componentes que permitirán manejarlo más básico de la física para objetos rígidos tales como posiciones, aceleraciones, fuerzas, etc.En (1) se muestran vectores de posición y velocidad. Los motores físicos parten de las leyes demovimiento de Newton, que describen el comportamiento de una masa puntual. La primera leyde Newton expresa que un objeto con velocidad uniforme, sobre el cual no existen fuerzas, nocambiará su velocidad. Aunque en el mundo real siempre existe algún tipo de fuerza que sufrenlos objetos en movimiento, como la producida por rozamiento. La segunda ley de Newton es laque relaciona la fuerza con aceleración.

p =

px

py

pz

v =

vx

vy

vz

(1)

F = ma = mp̈ (2)

p̈ = 1mF (3)

En el motor físico se obtendrá la aceleración de un objeto a partir de la fuerza que se le estéaplicando (3). Mediante integración se podrá conocer la velocidad y la aceleración. Los objetos,por tanto, poseerán las cuatro características básicas que son velocidad, aceleración, fuerza y masa.Además de las leyes de Newton, se debe simular la interacción de objetos y fuerzas. Por ejemplo,la fuerza de la gravedad estará presente en cualquier entorno de simulación. Normalmente, sesimulará la fuerza de gravedad de la tierra, por lo que se aplicará (5). Donde se aproximará laconstante g con un valor de 9,8 m

s2 ,10,0 ms2 , para realizar cálculos rápidos [7].

F = Gm1m2

r2 (4)

F = mg (5)

La aceleración de la gravedad que se aplicará a los objetos será por tanto, un vector.

g =

0−g0

F =

Fx

Fy

Fz

(6)

Los objetos podrán estar tanto en reposo como en movimiento. En movimiento cualquier objetosufre rozamiento. La fuerza de rozamiento viene dada por la ecuación (7), donde Fr es la fuerzade rozamiento, N la normal y µ el coeficiente de rozamiento. Aunque se deben tener en cuenta losdos tipos de coeficientes de rozamiento, el estático y el dinámico µs y µk. Estos coeficientes soncaracterísticos para cada par de materiales que se encuentran en conctacto y dependen de otrosfactores como la temperatura. Una opción sería usar valores aproximados para ciertos materiales,como los extraídos de [7] que se muestran en la tabla 1.

Fr = µN (7)



Material 1 Material 2 µs µk

Steel Steel 0.74 0.57Aluminium Steel 0.61 0.47Copper Steel 0.53 0.36Rubber Concrete 1 0.8Wood Wood 0.25-0.5 0.2Glass Glass 0.94 0.4

Waxed wood Wet snow 0.14 0.1Waxed wood Dry snow - 0.04

Metal Metal 0.15 0.06Ice Ice 0.1 0.03

Teflon Teflon 0.04 0.04Synovial Jointsin Humans

- 0.01 0.003

Table 1: Valores aproximados de los coeficientes de rozamiento dinámico µk y estático µs. Paresde materiales en contacto.

Otro aspecto importante a tener en cuenta para la simulación de objetos rígidos será el momentode inercia de un objeto de masa uniforme, el cual viene dado por (8). Para la simulación se haráuso de los tensores de inercia de un sólido rígidoIxx, Iyy e Izz y los productos de inercia Ixy, Ixz eIzy.

I =ˆ

V

ρr2dV (8)

Para procesar todas las fuerzas que están actuando sobre un mismo objeto en el simulador seutilizará el principio de DÁlambert. Este principio implica que si, en un sistema de partículas,se tiene un objeto sobre el cual actúan una serie de fuerzas, se puede obtener una única fuerza apartir del conjunto de fuerzas [4]. Se hará la suma vectorial de fuerzas a las que está sometidoun objeto para obtener una única fuerza total, ver (9). Otras características como el centro demasas, orientación (ángulos de Euler), momentos de inercia y de fuerza o par deberán aplicarsepara conseguir realismo en la simulación.

F =∑

i

Fi (9)

Para el desarrollo de la aplicación se ha utilizado un motor físico de propósito general. Sebuscaba un motor que fuera gratuito y de código libre que además incluyera las característicasmás básicas de la física que se han comentado para poder realizar la simulación de objetos rígidos.De esta forma no habría problema en añadir nuevas propiedades físicas en futuras mejoras de laaplicación.

Motores físicos que cumplen con estas condiciones son:

• JigLibX

• Jitter

• Bullet Physics



Figure 8: Ejemplos de uso de Bullet Physics.

Figure 9: Ejemplos de uso de JigLibX.

Dado que los motores encontrados tenían las características necesarias y todos eran muysimilares como para hacer una elección y dado que no se disponía de tiempo para realizar unexamen exhaustivo del código para hacer la elección del idóneo se escogío JigLibx tras ver algunasde las simulaciones realizadas con el mismo.

Como muchas otras librerías en C#, JigLibx es una librería portada a C# desde C++, JigLib.Aunque el objetivo principal de JigLibX Beta es conesguir que la librería se “más” .NET. Comoestá completamente escrita en C# es particularmente ajustable a su uso con XNA. El motor físicoposee un sistema de colisiones, física de objetos rígidos y es gratuito y de código abierto. Por loque se integrará bien en la aplicación de la que es objeto este proyecto.

El sistema de colisiones que implementa JigLibX está basado en profundidad de penetración.El sistema de colisiónes es la parte del simulador encargada de detectar si se ha producido unacolisión entre objetos, cómo ha sido y qué consecuencias conlleva. En base al trabajo del sistemade colisiones se podrán realizar las tareas de aplicación de ecuaciones físicas a los objetos.

La colisión entre objetos ocurre cuando existe un contacto entre éstos. Dado que se tiene unsistema de simulación en 3D y por tanto objetos modelados en base a polígonos, se debe hacerdistinción entre colisiones punto-punto, arista-arista, arista-cara, cara-cara. Uno de los problemasal desarrollar el sistema de colisiones es el tiempo de ejecución. En la vida real dos objetos chocan,



pero en una simulación de ordenador debido a que el tiempo es tratado de forma discreta, lo queocurrirá es que penetrarán el uno en el otro, ver figura 10. Esto se resolvería separando los objetosen direcciones opuestas a las que tenían inicialmente hasta que dejen de tocarse.

Figura 10: Contacto entre 2 objetos penetrando

Uno de los métodos más utilizados se denomina penalty-based method, donde usa laprofundidad de penetración definida como la distancia de traslación mínima requerida para separardos objetos en intersección [2]. En este método se permite la interpenetración entre objetos y pararealizar la separación se opta por aplicar fuerzas proporcionales a la cantidad de penetración. Alresolver la colisión se tendrán en cuenta todas las magnitudes de los objetos involucrados, velocidadlineal, angular, fuerzas etc. Al producirse en una colisión entre dos objetos debe cumplirse elprincipio de conservación en el momento del choque y que viene expresado por (10). Dos objetos avelocidades de choque va y vb , con masas ma y mb, tras el choque adquirirán una nueva velocidaden otras direcciones y sentidos. La conservación ocurrirá en el momento justo del choque, tras elcual el movimiento de los objetos deberá responder al resto de fuerzas externas como la fuerza derozamiento.

mava +mbvb = mav′a +mbv

′b (10)

El sistema de colisiones deberá comprobar si existen colisiones entre cada par de objetos delsimulador. Comprobar una colisión supone conocer la geometría de cada objeto y obtener todoslos puntos de colisión existentes entre dos objetos. Si existen muchos objetos, esta comprobaciónpuede consumir demasiado tiempo de procesado y ralentizar la simulación. Una solución a esteproblema es utilizar dos tipos de detectores de colisiones. El primero de ellos haría una localizaciónde los objetos con posibilidad de contacto sin entrar en detalles. El segundo recibiría la lista deobjetos y realizaría un chequeo más exacto hallando las colisiones y la información necesaria paraque sean tratadas por el motor físico. De las posibles colisiones también se eliminarían aquellascolisiones que se producen entre un par de objetos que no poseen velocidad alguna y se encuentranen reposo. Es decir, sólo se tendrán en cuentan las posibles colisiones entre objetos reposo-activoy activo-activo [5].

En general se debe introducir en el sistema un conjunto básico de figuras geométricas ya quelos cuerpo físicos tendrán una forma que será una figura geométrica o en casos más complejos unacombinación. En la figura 11 se pueden observar ambos casos. Entre las formas básicas destacanel cubo, cilindro y esfera. Con estas tres se podría modelar cualquier objeto de forma aproximada.



a) b)

Figura 11: Objetos con composición geométrica simple a), y compuesta b).

Como se ha comentado anteriormente, se usarán modelos de objetos rígidos, es decir, nodeformables. El uso de este tipo de objetos, no realistas, presenta algunas desventajas. En primerlugar en la simulación de un choque entre dos objetos nuncan se dará una amortiguación pordeformación. Aún así la elasticidad se puede incluir en el modelo mediante un coeficiente juntocon los coeficientes de rozamiento, como se ha comentado anteriormente. En segundo lugar el usode modelos mecánicos basados en objetos rígidos provoca que las velocidades sean discontinuas[8]. El uso de este modelo más simple está justificado ya que un modelo más completo conconsideraciones de elasticidad del material consumiría demasiado tiempo de procesador y daríalugar a una renderización ralentizada y, por tanto, una simulación inapropiada.

El proyecto JigLibX en Visual Express C# está formado por los siguientes elementos:

Figura 12: Estructura del proyecto JigLibX en Visual Express C#.

3.2 ESTRUCTURA DE LA APLICACIÓN

Como muchas aplicaciones, se basa en un bucle infinito que el usuario deberá poder ser capaz dedetener en cualquier momento. Al tratarse de una aplicación con renderizado en 3D se deberáactualizar el dibujado en pantalla en cada paso de ejecución. Los modelos 3D son parte delcontenido de la aplicación. Para ahorrar carga de trabajo, todos los modelos que serán necesarios



para la ejecución se cargarán al comienzo del programa. La estructura del programa está divididaen varios métodos, de los cuales algunos se ejecutarán una única vez, y otros en cada paso deejecución. La estructura es como sigue:

Figura 13: Estructura de la aplicación. Diagrama de flujo.

Figura 14: Estructura del proyecto de la aplicación en Visual Express C#.



3.3 PROGRAMA PRINCIPAL

El programa principal es la clase Simulador.cs, donde se encuentra la estructura principal delprograma comentada en el apartado anterior. Al empezar el proyecto se pretendía que fuerasencillo añadir nuevos elementos a medida que se fuesen desarrollando ahora o en un futuro. Quesea sencillo no implica que no haya que introducir código nuevo. No obstante la forma de introducirel nuevo código es sistemático de la forma que se ha desarrollado el programa principal.

Figura 15: Ejemplo de código en C# de la declaración de las variables para incluir mesas giratorias.

Al comienzo de la clase Simulador.cs se declaran todas las variables que se van a necesitar,así como las propias clases de elementos industriales que existen. En la figura 15 se muestra unaporción de código donde se observan las variables necesarias para introducir “5” cintas giratoriasen el simulador.

Figura 16: Código en C# de la carga de contenidos 3D.

Posteriormente, en el método LoadContent, se cargan todos los modelos 3D que dicha clase vaa necesitar, ver figura 16. En el método Initialize se inicializarán los parámetros necesarios básicosy son los siguientes, ver figura 17:

• Posición del elemento

• Nº de actuadores en el cuadro de actuadores

• Nº de sensores en el cuadro de sensores

Una vez que se tiene todo ésto, ya se puede empezar la ejecución de los métodos Update yDraw. En el método Update, se llamará mediante un bucle “for” al método Update de cada una delas Cintas transportadoras que existan en el escenario. De la misma manera, en el método Drawse llamará al método Draw de cada una de las cintas mediante un bucle “for”. De esta forma si sepretende añadir una nueva cinta, solo hay que aumentar el valor “num_Cintas2”, y copiar/pegarla porción de código de otra cinta cambiando sus parámetros de posición. Al aumentar el valor“num_Cintas2” ya se está incluyendo en los bucles “for” de los métodos Update y Draw la nuevacinta transportadora, luego el mecanismo de introducción de elementos es relativamente sencillo,ver figura 18.



Figura 17: Código C# de uso repetitivo para inicializar un elemento.

a)

b)

Figure 18: Código C# de la aplicación. a) Código repetitivo en bucle “for” para la actualizaciónde elementos de una misma clase. b) Código repetitivo para el renderizado de modelos 3D.

3.4 CLASES PARA LOS ELEMENTOS INDUSTRIALES

En este apartado se va a describir como se han desarrollado los elementos industriales para la plantapiloto en pruebas del simulador 3D. Cada una de ellas se encapsula en una clase con unos métodosobligatorios y otros opcionales como se ha descrito anteriormente. Ésto hará que el desarrollo denuevos elementos y su adición al programa principal sea más rápido, sencillo y seguro ante fallosde compilación y ejecución.

Cuando se habla de métodos opcionales, se está haciendo referencia a un método extra que esnecesario ejecutar una vez que el motor físico ha realizado su pasada, cosa que ocurre al final delmétodo Update del programa principal en “Simulador.cs”. Este método extra puede ser necesariopara truncar o mejorar el rendimiento del motor físico. Debido a que vamos a simular elementosmecánicos basados en objetos diferentes que interacturan entre sí pero que no están gobernadospor ninguna mécanica entre ellos más que la física clásica, la reorientación, ajuste de velocidadesy/o detección extra de colisiones pueden llegar a ser necesarios tras el paso de los objetos por elmotor físico. Así pues se deja esta opción en caso de ser necesitada, y se ejecutaría siempre al finaldel método Update de la clase “Simulador.cs”, después de la llamada al motor físico, ver figura 20.

La estructura de una clase será en general como se muestra en la siguiente figura:



Figura 19: Estructura de métodos de la clase Elemento Industrial.

Figura 20: Código en C# mostrando la llamada a métodos “Opcionales”, de las clases Grúa yCinta2, tras la llamada al motor físico.

3.4.1 CINTA TRANSPORTADORA

La cinta transportadora es el primer dispositivo industrial que se desarrolló y por lo tanto esel que más modificaciones ha sufrido. Debido a que fue el primer dispositivo, partes del códigode otros elementos están basados en ellas. Cuando se obtuvo una versión funcional de la cintatransportadora se pasó a diseñar nuevos dispositivos. No obstante a medida que se programabannuevos elementos se encontraban formas de optimizar tanto el código como el renderizado 3Dde las distintas partes que componen un dispositivo. Por lo cual se volvía siempre a la cintatransportadora para mejorarla tanto gráfica como computacionalmente.



Una vez que se había estudiado el motor físico y su comportamiento ya era posible comenzarcon el desarrollo de un dispositivo industrial muy común en las plantas industriales, la cintatransportadora. Aunque las cintas trasnportadoras las hay de muchos tipos y tamaños, la que seha diseñado es una cinta lineal rectilínea.

Dado que el motor físico integrado en la solución trabaja con cuerpos rígidos, la mejor opciónpara diseñar los dispositivos es basarlo en las figuras geométricas más básicas, cubo, esfera ycilindro. En base a estas tres figuras se desarrolla todo el modelo, tanto físico como 3D.

Al comenzar a diseñar un dispositivo es importante reducirlo a su más básico funcionamientopara que la implementación sea lo más sencilla y rápida posible. Es por eso que se ha tomadola cinta transportadora como “algo que mueve objetos de un punto a otro”. En este punto noimporta que exista un motor que proporciona la fuerza necesaria para que unos engranajes hagangirar unos rodillos que a su vez muevan una cinta, generalmente de materíal plastico o metálico,muevan los objetos que están sobre ellos. Éste es el punto clave para la programación de lacinta. Un material que mueve objetos que están sobre él. Es por eso que en una primera versiónde la cinta en pruebas se tomarán objetos cúbicos que descansaban sobre una superficie fija yestática. A estos objetos cúbicos, uno junto a otro, se les dotaba de una velocidad lineal quese actualizaba en cada paso. Estos objetos son dinámicos, es decir, incluidos en el motor físicoy sobre los cuales actuan fuerzas y velocidades pero que también producen fuerzas sobre otrosobjetos. No obstante en cada paso de ejecución se eliminaba la posibilidad de fuerzas ejercidassobre ellos por otras causas para que el funcionamiento fuera correcto, pues aunque es cierto quelos objetos que transportarán ejercerán fuerzas sobre ellos y por lo tanto un desgaste natural yotras perturbaciones o errores de maquinaria, ésto se puede hacer de forma ajena al motor físicosin necesidad de incluirlo. Lo importante es obtener un comportamiento lógico y realista de loque sería un objeto siendo transportado por la cinta. En la figura 21 se pueden ver capturas delprimer prototipo de cinta que se está comentando. En esta primera versión se observa un modelomuy tosco, sin texturizar ni optimizar pero que cumplía su objetivo. Mover un objeto cúbico deun punto a otro.

Figure 21: Imágenes pruebas de transporte de un objeto físico por la cinta transportadora.

Una vez que se comprobó que el sistema ideado y programado funcionaba, se procedió a incluirlos objetos físicos cúbicos necesarios para tener una cinta transportadora completa. La dinámicade la cinta es lineal. Una vez activada va de 0 a 0.5m/s de forma lineal. Todavía no se han incluidolas opciones de funciones de transferencia personalizadas pues será en el editor de plantas donde seconfigurarán estas opciones. En la figura 22 se puede observar el primer prototipo, parcialmentetexturizado, del primer prototipo de cinta transportadora. Aunque sigue siendo algo tosco, ya sehan incluido los elementos que conforman la cinta, las placas de la cinta, los engranajes que mueven



las placas y los soportes. Esta cinta está formada por aproximadamente unos 50 obejtos cúbicosfísicos sobre un soporte rígido y estático que basicamente forman la cinta transportadora.

a)

b)

Figure 22: Imágenes de la Cinta transportadora parcialmente texturizada. a) Imagen en reposo.b) Imagen transportando objetos.

El modelo final tras varias modificaciones se muestra en la figura 23. Aunque la versión anterior,que estaba formada por 50 objetos cúbicos que se encargaban de mover los objetos encima deun punto a otro, funcionaba correctamente, el consumo computacional y gráfico era algo elevadoincluso estando parcialmente texturizado. Se fueron reduciendo el número de objetos que formabanla cinta y aumentando su tamaño para seguir cubriendo toda la longitud de la cinta. También seeliminaron objetos 3D que realmente eran innecesarios para mejorar el rendimiento gráfico, llegandoa una solución más optimizada que la versión anterior y con un funcionamiento prácticamenteidéntico.

En la figura 23 se puede observar como se ha mejorado el apartado gráfico incluyendo algunoselementos decorativos como el cuadro eléctrico. Como se ha comentado anteriormentee, la cintaconstará de 2 modelos, el físico y el 3D. El modelo físico de la cinta se muestra en la figura 24,mostrado mediante figuras geométricas constituidas por segmentos.



a)

b)

Figure 23: Imágenes del modelado final de la cinta transportadora y la zona de caída de cajas.



a)

b)

Figure 24: Imágenes del renderizado de los objetos físicos que realizan la simulación de la cintatransportadora.



Obviando el modelo 3D pues no tiene efecto físico en la simulación, se va a explicar como se haprogramado el funcionamiento de la cinta. El modelo físico completo de la cinta está compuestopor los siguientes bloques, mostrados en la figura 24:

• 1 bloque cúbico estático

• 1 bloque cúbico dinámico

• 2 bloques cúbicos estáticos laterales

El funcionamiento es el siguiente:

1. Al activarse el actuador correspondiente (ON, variable bool a “true”), se le aplicarámovimiento lineal al bloque dinámico. El bloque dinámico descansa sobre el bloque estático.

2. Al aplicar movimiento, este bloque, que descansa sobre el estático, se deslizará aunque sufrirározamiento debido a que está actuando la fuerza de la gravedad sobre él, por lo que en cadapaso de ejecución habrá que corregir la velocidad para compensar este rozamiento no deseado.El movimiento se aplicará directamente sobre las variables de velocidad del objeto, dentrode la clase, forzando a su movimiento.

3. El objeto dinámico se moverá una distancia determinada. Al recorrer esta distancia, el objetovolverá a su posicion inicial, mediante un forzado de la variable de posición pero manteniendola misma velocidad.

4. Esto provocará que el efecto sea el de una cinta. El objeto moverá cualquier otro objeto quetenga en su superficie una determinada distancia, volverá a la posición inicial, pero si eseobjeto sigue sobre su superficie, aunque en otra zona distinta ahora, seguirá desplazandoloigual.

5. El movimiento que se aplica es de dinámica lineal. Partiendo de 0 m/s y llegando a 0.3m/s.Una velocidad que se ha visto razonable para el escenario que se ha dispuesto y que sepresentará en un apartado posterior de este proyecto.

3.4.2 PLATAFORMA GIRATORIA + CINTA

La plataforma giratoria o “TurnTable”, tiene una implementación muy parecida a la Cintatransportadora. Está basada 2 únicos objetos físicos que se muestran en la figura 25. El objetorectangular es estático y soporta al objeto dinámico que será el que simule realmente la mesagiratoria. Este objeto deberá ser capaz de moverse de 0 a 90º, y linealmente en los dos sentidospara darle a la mesa mayor funcionalidad.

La clase detectará si se ha pulsado el actuador correspondiente y pondrá en marcha la funcióncorrespondiente. Sea cual sea la función escogida, el procedimiento es el mismo. Al objeto dinámicose le asignará una velocidad, en x, z o en ambos en caso de movimiento circular, mediante lasvariables que tendrá en cuenta el motor físico para hacer la simulación de colisiones y aplicar lasecuaciones físicas:



Figura 25: Código en C# que describe el movimiento de la cinta giratoria mediante las variablesde velocidad.

El movimiento lineal, aparte de lo ya comentado, sigue la misma rutina que en el caso de lacinta transportadora. Avanzará una pequeña cantida de espacio y se reposicionará el objeto cuandoalcance ese espacio en su posición original sin cambiar el vector de velocidad para no alterar lafísica del sistema, pues para nosotros es como si no hubiera ocurrido nada.



Figure 26: Imágenes del renderizado de los modelos físicos y 3D de la plataforma giratoria.

El modelo en 3D debe seguir fielmente a la simulación física interna. Lo que nos lleva a quelos rodillos del modelo en 3D que se observa en la Figura 26, deberán actualizar su posición enel espacio y ángulo dependiendo de la velocidad angular y lineal del objeto dinámico para lo cualhabrá que hacer equivalencias de velocidades angulares con lineales, ver Figura 27.

Figura 27: Código en C# que calcula la posicion y ángulos de los modelos 3D de los rodillos enfunción de la velocidad lineal del objeto físico.

En las líneas de código presentadas en la Figura 28, se muestra un claro ejemplo delreposicionamiento y reorientación del elemento dinámico para evitar errores en la simulación de lamesa. Ésto es debido a que en realidad el objeto dinámico no está unido a ningún otro elementocomo lo estarían las partes que componen a un elemento así en la realidad por ejemplo mediante



engranajes. Es en realidad un objeto libre que se está controlando para que simule ciertas acciones.Cuando, por ejemplo, tiene una caja que está transportando, ésta está ejercienzo fuerzas sobrela mesa, lineal/angular, e inevitablemente el motor físico lo tendrá en cuenta y se produciránmovimientos no deseados en los ejes x, z. Estos errores deben ser corregidos al comienzo delmétodo Update. Existe la posibilidad de realizar esto último mediante el método opcional del quese comentó que se disponía, siendo necesario su uso en este caso.

Figura 28: Código en C# del método “Update2” de la plataforma giratoria que se ejecutará trasel paso por el motor físico.

3.4.3 GRÚA

El caso de la grúa es más complejo que los anteriores. El modelo completo en 3D puede verse enlas figuras 29 y 30. En este caso el modelo de la grúa tiene varias partes implicadas.

Figure 29: Imagen del modelo completo de la grúa del proyecto, garra abierta y bajada.



Figure 30: Imagen del modelo completo de la grúa del proyecto, garra abierta y subida.

La primera parte implicada es la estructura principal, los soportes sobre los que descansa lagrúa y por los cuales se mueve, formada por varios cuerpos físicos estáticos. La estructura principalnunca se moverá, será estática durante toda la simulación, no adquirirá velocidad, aceleración ofuerza alguna, ver figuras 31 y 32.

Figure 31: Imagen del modelo físico que simulará el funcionamiento de la grúa.



Figure 32: Imagen del modelo físico que simulará el funcionamiento de la grúa.

En segundo lugar está el brazo de la grúa, formado por dos cuerpos físicos, en principioinamovibles pero que cambiarán al imprimirle movimiento. Estos dos cuerpos forman un únicoobjeto en el simulador. Se puede mover linealmente en dos sentidos y subir/bajar. El brazo debepoder interactuar con el resto de objetos del simulador sin que éstos tengan efectos sobre su posicióny velocidad pero si al contrario. Para ello se dota al brazo de una masa elevada, de esta forma siun objeto choca con el brazo no repercutirá en su estado. El último de los elementos es la garraque está formada por dos cuerpos cúbicos que serán los encargados de interactuar con los objetos,ver figuras 33 y 34.

Figure 33: Imagen de la grúa sosteniendo una caja.



Figure 34: Imagen de la grúa soltándo una caja en movimiento.

Para realizar la simulación de la sujeción de un objeto se ha optado por usar “choque conjunto”.Si una de las dos partes de la garra colisiona con un objeto, el sistema físico se encarga delmovimiento necesario entre garra y objeto. En el momento en que exista una colisión en ambaspartes de la garra, se comprueba que el objeto definitivamente se encuentra en una posición en laque es posible sujetarlo físicamente. Si éste es el caso, se procede a declarar al objeto inamovibley a la grúa se le da la orden de aplicar al objeto sus mismas velocidades en cualquier dirección.Las líneas de código que gobiernan la garra se presentan en la figura 35. De ésta forma el objetoseguirá a la grúa en el recorrido que haga sin moverse de su posición relativa a la grúa. Una vezque se envié la orden de abrir la garra, la grúa devolverá el estado inicial al objeto, quedando asínuevamente expuesto a cualquier tipo de fuerza externa.

Para la detección de colisión se utiliza un método extra de colisiones entre objetos. Como losúnicos objetos dinámicos libres que actualmente existen en el simulador son cajas, lo que se hacees un barrido por cada una de las cajas. Se comprueban las “ID’s” de colisión y si existe unacolisión de los modelos físicos o “BoundingBox” de la caja con los objetos que forman la garra.Si se detecta una colisión se procede al movimiento de la caja para alinearla con la garra segúnel avance de la garra tal y como sucedería en la realidad. En el momento de la colisión doble, sila orientación de la caja es cercana a la orientación de la garra, el objeto se podrá agarrar. Enotro caso, supongamos que la caja estuviera a 45º, las garras al cerrarse expulsarán el objeto porrozamiento.



Figura 35: Código C# que se encarga del funcionamiento de la garra mediante detección decolisiones añadidas.

3.4.4 RAMPA

Las rampas no son más que objetos físicos estáticos que servirán para guiar las cajas hacia lassalidas, en este caso los destructores, que serían paso a otras zonas de la planta. Están formadaspor varios objetos y poseen unos coeficientes de rozamiento adecuados para simular una superficiemetálica pulida que permitirá a las cajas deslizarse facilmente por su superficie. En la figura 36 sepresenta el modelo en 3D y el modelo físico. Las rampas no disponen de actuadores, ni sensores.No tienen control alguno y están completamente gobernadas por el motor físico. En la figura 37 sepuede ver lo más relevante de la clase “Rampa.cs”. Se observa que tan solo es una declaración deobjetos y su posicionamiento en el escenario mediante las variables correspondientes a cada cuerpoo “Body”.



a)

b)

Figure 36: Imágenes de los modelos a) 3D , b) físico de la rampa.



Figura 37: Código en C# de la declaración e inicialización de un elemento Rampa.

3.4.5 DESTRUCTOR

Dado que para el escenario prototipo se han utilizado cajas de madera, es necesario crear unelemento que sea capaz de “destruirlas”. Es decir, si una caja ya no es necesaria en el escenario, sique será necesario liberar o destruir dicha caja para liberar recursos de la ejecución. En las figuras38 y 39 se pueden observar tanto el modelo 3D como el modelo físico que detecta las colisionesmediante su “BoundingBox”.

Figure 38: Imágenes del renderizado 3D de un Destructor.



Figure 39: Imágenes del renderizado del modelo físico de un Destructor.

El código del destructor es muy simple y solo se basa en unas “ID’s” que contienen las cajas.Un objeto cúbico físico simple se encargará de comprobar si se ha producido alguna colisión con elmismo. En ese caso se comprobará la ID del objeto en colisión y se liberarán los recursos de dichoobjeto. El código que gobierna las colisiones es similar al caso de la garra en la grúa y se muestraen la figura 40.

Figura 40: Código en C# para chequear las colisiones del objeto físico del Destructor con otrosobjetos del escenario y eliminarlos encaso positivo.

3.4.6 PISTON

Se ha desarrollado una simulación de un pistón neumático. Dado que el prototipo de escenarioen mente, al ir desarrollandose el proyecto, era una planta clasificadora de cajas, se pensó que



sería conveniente desarrollar un elemento de empuje. El modelado definitivo en 3D se muestra enimagenes en la figura 41.

La estructura programada es simple. Varios objetos físicos estáticos y un único bloquedinámico/estático. Cuando se dice dinámico/estático es debido a que el bloque no es realmentedinámico, sino estático pero al moverse se comporta como dinámico cuando se ejecuta el sistema decolisiones. El pistón permanecerá completamente estático pues sino caería por fuerza de gravedad.En la figura 42 se muestra una porción de código con la definición de los objetos que componen elpistón.

Figura 42: Código en C# donde se declaran las variables de objetos físicos.

Cuando los actuadores que gobiernan la activación del pistón son pulsados, ver figura 43,se modifica la posición del elemento dinámico/estático que se encuentra en el tope del pistónmediante las variable correspondiente. Tras la actualización de posiciones del elemento, se hacepasar por el motor físico y sistema de colisiones. El truco que se ha utilizado para que se comportedinámicamente siendo estático y que no se caiga el objeto físico cúbico por gravedad tiene que vercon el propio sistema de colisiones.

En el apartado 3.1 se explicó que el sistema de colisiones se basaba en profundidad depenetración y un movimiento proporcional a la penetración. El objeto es estático, luego en realidadno importa que se le apliquen velocidades, aceleraciones y/o fuerzas, pues el motor físico lo detectacomo estático y no aplicará fuerzas, velocidades ni aceleraciones sobre él. La velocidad que se leaplica al objeto se hace mediante desplazamiento de su posición.

Si se quiere una velocidad de 0.2m/s se hacen los calculos necesarios según el tiempo de paso deejecución y se calcula aproximadamente la cantidad de espacio que debe recorrer en cada uno delos pasos. Es decir que entre un paso y otro se fuerza la posición del objeto. Si existe otro objetodinámico, como una caja, cercano al pistón y se fuerza la posición del pistón , éste penetrará enla caja. Esta situación será detectada por el sistema de colisiones que se encargará de hacer losmovimientos correspondientes al objeto dinámico, en este caso la caja. De esta forma se consigueel comportamiento deseado.



a)

b)

Figure 41: Imágenes del Pistón. a) Modelo 3D pistón recogido b) Modelo 3D pistón extendido.



Figura 43: Código en C# para la simulación del movimiento del pistón.

Basandose en el pistón se ha desarrollado también un pistón con dos pistones incorporadosreutilizando el código del pistón. En las figuras 44 y 45 se muestran los modelos del piston dedoble actuación.

Figure 44: Imagen del pistón doble en resposo sobre la cinta transportadora.



Figure 45: Imagen del pistón doble empujando una caja.

3.4.7 SENSORES DE BARRERA

Dado que se está hablando de simular una planta industrial, un elemento básico que no debe faltares el sensor de barrera. Aunque son sensores muy simples, son muy utilizados y darán mucho juegoen el simulador para practicar con PLC’s.

La implementación final del sensor de barrera con la que se obtuvieron los mejores resultadosfue mediante el uso de un segmento de colisión. Este segmento, de longitud igual a la separaciónentre los elementos que forman el sensor será el implicado en la detección de los objetos. En cadaiteración de la aplicación se comprueba si este segmento ha intersectado con alguno de los objetosfísicos del escenario. En el caso de obtener una intersección, el sensor se activa cambiando a trueel valor de una variable booleana que se utilizará para otros propósitos en el escenario.

Figure 46: Imagen del Sensor de barrera. Modelo 3D del Sensor con rayo.



a) b)

Figure 47: Imágenes del Sensor de barrera. a) Contacto límite entre objeto y sensor activandose.b) Objeto cercano sin colisionar con el sensor de barrera.

Figura 48: Código C# que muestra como se detecta la colisión con el segmento y la comprobaciónde ID’s.

En la figuras 46 y 47 se muestran capturas de pantalla del modelado 3D y funcionamiento delsensor para objetos con diferentes posiciones. La porción de código relacionada con la detecciónse muestra en la figura 48.

Dado que en el simulador desarrollado en este proyecto los únicos objetos dinámicos que existenson las cajas, al detectarse una colisión se comprobará a que caja corresponde la “ID” del objetoque ha colisionado con el segmento. En las colisiones se modifican los valores de los colores del



rayo y las luces de control para una mejor visualización por parte del usuario como se muestra enla figura 48.

3.4.8 MONTACARGAS

Este elemento no se ha terminado de desarrollar completamente, aunque está practicamentefinalizado. Se ha programado con un objeto físico cúbico que será el responsable de la subiday bajada de elementos. El modelado 3D y físico se muestran en las figuras 49, 50 y 51. Recordandoque no existen uniones mecánicas que mantengan los elementos unidos unos a otros, hay que teneren cuenta que el objeto que debe subir y bajar carga estará inevitablemente bajo la fuerza de lagravedad del motor físico. Si se intentase hacer la simulación mediante la adición de velocidad,aceleración o fuerza en el eje vertical del objeto para que fuera capaz de subir y bajar un elemento,nos encontraríamos con situaciones no deseadas. El elemento encima de la plataforma no tieneporque estar necesariamente en el centro, luego nuestro objeto, que no es más que la plataforma,se inclinaría hacia los lados. No es un método que proporcione buenos resultados.

Figure 49: Imagen del modelado 3D del montacargas detenido.



Figure 50: Imagen del modelado 3D del montacargas subiendo un objeto.

Figura 51: Imagen de la estructura física que conforma el montacargas.



Tras varias pruebas se utilizó la velocidad lineal en el eje vertical para realizar la simulación.La clave para evitar inclinaciones y efectos parásitos en la carga fue resetear el elemento movil encada una de las iteraciones. Al ejecutarse el método Update del montacargas, se anulan las posiblesfuerzas, aceleraciones y velocidades, que se han grabado en sus variables internas, productos delpaso por el motor físico y sistema de colisiones. Asimismo se reorienta el elemento y se le vuelvea asignar la velocidad que debería tener. De esta manera se mantiene el realismo de la acción desubida y bajada de la carga. En la figura 52 se muestra la parte del código relacionada con laactivación del actuador correspondiente y la actualización de la posición de la plataforma.

Figura 52: Código en C# del método Update de la grúa donde se controla el movimiento de lasdistintas partes y se reajustan al comienzo del mismo.

3.4.9 ROBOT 5 GRADOS DE LIBERTAD

Al igual que en el caso del montacargas este elemento no se ha terminado de desarrollarcompletamente, aunque está practicamente finalizado. Lo único que falta por terminar deprogramar es el mecanismo de agarre, aunque ya se ha planteado usar el mismo método queen el caso de la grúa, al fin y al cabo en este caso la garra no deja de ser una pinza al igual queen la grúa. En la figura 53 se muestran capturas del brazo en 3D en diferentes posturas, y en lafigura 54 se puede observar el modelado físico que se implementa en el motor para las colisiones.

El brazo se ha diseñado siguiendo la estructura de una brazo real. Consta de un bloque cúbicofísico por cada una de las partes que lo componen, 4 más la garra. El brazo se podría haber



programado utilizando las matrices de traslación y la de rotación, al igual que se hace de formateórica, donde los ejes están en las articulaciones, en los extremos de los elementos. El problema esque en el motor físico, los ejes de los elementos están en el centro por lo que habría que trasladareste punto hacia los extremos. En vez de realizar la conversión se decide programar la posición decada una de las partes respecto de la anterior y partiendo desde cero.

Figure 54: Imágenes de los modelos físicos del brazo de 5 grados. 4 elementos más la garra.

En las figuras 55 y 56, se muestra el código de la declaración e inclusión en el motor físico decada una de los bloques físicos que componen el brazo. El brazo tendrá una mobilidad de 180º



a)

b) c)

Figure 53: Imágenes del brazo en 3 posiciones diferentes.



en cada una de las articulaciones. El modelado está basado en el Scorbot. El objetivo de aplicaruna masa elevada a cada una de las partes del brazo es porque se va a utilizar el mismo métodoque en el caso del pistón. Debido a que los movimientos de cada una de las partes tendrán variascomponentes, se hace dificil el control de la posición sin que ocurran efectos parásitos debido ala falta de unión mecánica fija, a la fuerza de la gravedad y resto de elementos del escenario. Elmovimiento del brazo está totalmente basado en movimiento articular. Mediante cambios en lasvariables articulares se aplicará la nueva posición de cada una de las partes.

Figura 55: Código en C# de los objetos físicos y otras variables del brazo.

Se parte siempre de la base y se va subiendo, modificando las variables articulares yconsecuentemente su parte correspondiente, hasta llegar a la garra. Se realizan los cálculos, segúnel valor de la variable de la articulación, cual será la nueva posición del elemento en cuestión.El punto que se está calculando es el punto central de la parte del brazo para después poderposicionarla en ese punto. En las figuras 57, 58, 59 y 60 se muestra el código de los cálculos quese realizan para cada elemento. Si el actuador de la articulación correspondiente está activado,la velocidad de movimiento será uniforme y siempre la misma. No se ha implementado ningunadinámica por el momento, al igual que con el resto de elementos. En cada iteración la cantidadde movimiento en la variable articular es constante. Como se conoce el aumento de cantidad,se puede conocer facilmente mediante relaciones trigonométricas cual será la nueva posición delbloque físico.

Una vez calculada la posición, simplemente se sitúa el elemento en dicha posición y se recalculanlas posiciones de los elementos superiores en función de la variable inferior. En caso de estaractivado algún otro actuador superior se realizaría la misma operación, pero eliminando los cálculosinferiores.

Lo que falta por programar en el brazo es el mecanismo de sujeción de la garra.



Figura 56: Código en C# de la inicialización y adición al motor físico de los objetos.

Figura 57: Código en C# del control de la primera sección del brazo. La sección 0 es la base.



Figura 58: Código en C# del control de la segunda sección del brazo.

Figura 59: Código en C# del control de la tercera sección del brazo.



Figura 60: Código en C# del control de la garra sección del brazo.

3.4.10 CONEXION CLIENTE OPC - SERVIDOR OPC - PLC

Para esta aplicación en pruebas, y como se ha comentado anteriormente, se ha optado por unaconexión no física. Es decir, para realizar la simulación de la planta 3D con un programa escritopara el PLC, no será necesario el uso de un PLC real. Se utilizará el simulador de PLC que incluyeel software Unity Pro XL de Schneider Electric. Este simulador se conectará de forma local enel mismo PC con el servidor de OPC de Schneider OFS. La conexión con el OFS se realizará através del menú de pestañas que incluye el simulador 3D. El cliente OPC que se ha integrado en lasolución, está escrito en C#. Para ahorrar tiempo en el desarrollo de la aplicación se ha utilizadoun cliente OPC libre de licencias en C#.

Aunque existen diversos clientes OPC escritos en este lenguaje, se descartaron por noproporcionar el código fuente o ser de pagos y no es el objetivo de este proyecto. En un futurose podría utilizar el conjunto de librerías de la OPC Foundation para el desarrollo de clientesOPC optimizados para el simulador 3D. Durante la conexión del cliente con el servidor OPC, semuestran el listado de variables que están incluidas en los archivos de la programación realizadapara el PLC con Unity Pro. Actualmente todas las variables que se permiten en el simulador 3Dson boolenas, true/false o 0/1 según se prefiera. Lo comentado no implica que el OFS no admitavariables analógicas. Para éste escenario no se han implementado aunque si se implementarán enfuturas modificaciones de la aplicación.

Para la conexión con el servidor OPC de Schneider, OFS (OPC Factory Server), se utilizará uncliente OPC escrito en C# que se ha integrado en la solución. El cliente esta basado DA o “DirectAccess” y se utiliza de forma directa en el mismo PC donde se encuentra tanto el servidor OPC



como el programa del PLC Unity Pro. Se disponen de dos botones en el cuadro de control para laconexión y desconexión con el OPC.

Figura 61: Captura de pantalla del formulario de conexión Cliente - Servidor OPC.

El cliente OPC inicialmente se manejaba desde un formulario para la escritura y lectura devariables. Se ha tenido que modificar parte del código para que la escritura/lectura se realicedesde métodos internos que serán llamados utilizando hilos pseudoparalelos desde el programaprincipal. En Unity Pro las variables se envian al servidor OPC con la descripción de item“Nombre_Proyecto!Nombre_variable”. Sabiendo ésto se puede localizar desde el cliente unavariable en concreto dentro del servidor OPC, para la escritura o lectura de una variable. Eneste proyecto los actuadores se llamaran Axx y los sensores Sxx y Pxx. El significado y numeraciónde éstos aparecen en el manual de usuario.

Existirán hilos de escritura y lectura, así como hilos prioritarios y secundarios, ver figuras 62y 63. La creación de hilos diferentes se basa en que variables se están leyendo o escribiendo. Secomprobó tras varias pruebas que la lectura/escritura individual de actuadores y sensores en elservidor OPC era lenta, en especial en el caso de la escritura en el OPC. La solución escogidaque mejor resultado ofreció fue la lectura en bloque y la escritura individual. La lectura de todoun conjunto de 20 actuadores lleva un tiempo aproximado de 30-40ms. Mientras que la escrituraindividual de 1 único sensor en el OPC puede llevar unos 15ms. El OPC utilizado parece serbastante lento en escritura y lectura. Por ello se necesitan hilos.



Figura 62: Código del método para la lectura de actuadores del servidor.

Figura 63: Código del método de escritura de sensores no prioritarios en el servidor OPC.



El hilo de lectura estará continuamente en ejecución. Este hilo se detiene cuando existe alguncambio en algún sensor. Entonces se toman todos los sensores que han cambiado de estado y seescriben uno a uno.

En el simulador existen sensores prioritarios que corresponden a los sensores de barrera. Dadoque estos sensores son críticos pues dependen del paso de objetos dinámicos que cambian deposición, se deberán escribir inmediatamente en el OPC para que el PLC reciba los datos y actuela programación de la planta en el PLC en consecuencia. En este caso la escritura del resto desensores se detendrá para proceder a escribir los prioritarios, tras lo cual se volverá a escribir pordonde se dejaron los sensores no prioritarios Sxx.

3.4.11 CUADRO DE CONTROL Y OPCIONES

Para el control de la aplicación, tanto en modo manual como automático, se ha diseñado unainterfaz amigable formada por un cuadro de control dividida en pestañas. En cada una de laspestañas se encuentran diferentes controles, actuadores, sensores y conexión de OPC, ver figura64. En el cuadro de operación a la derecha se encuentran los controles de activación de modomanual/automático y otros que se pueden utilizar junto con variables que se declaren en el PLC.

La programación es sencilla. Todo el cuadro está basado en texturas 2D que se renderizarán encada paso de ejecución. Las texturas corresponden al cuadro en sí y a los botones. Cada uno delos botones se posiciona en base a los ejes que forman el formulario general donde está embebido elsimulador. En función de las características de ancho/alto de la ventana de la aplicación la situaciónde los botones se mantiene siempre en el mismo sitio, es decir, no importa que se aumente el tamañode la ventana, el cuadro permanecerá con el mismo tamaño y en la misma posición, ver figura 66.

Para la detección de pulsado de botones se detecta la posición en la ventana donde se harealizado el click de ratón. Cotejando la posición del click con las posiciones de los botones sedetectará una coincidencia o no, y si es así se cambiará el estado del botón y su imagen. Conrespecto a los sensores solo hay que detectar de forma interna cambios en las variables booleanasde los sensores. El código para una parte de los actuadores se presenta en la figura 67.

Figura 65: Código de la declaración de variables que contendrán las imágenes para los elementosdel cuadro de control.



a)

b) c)

Figure 64: Imágenes del cuadro de actuadores de la aplicación. a) Cuadro de actuadores, b) Cuadrode sensores y c) Cuadro de conexión OPC.



Figura 66: Código para posicionar los elementos en el mismo lugar sin importar el tamaño de laventana.

Figura 67: Código para la detección de pulsado de botones en la aplicación. En este caso secomprueban los 15 primeros actuadores.


4 ESCENARIO PROTOTIPO Y EDITOR DE ESCENARIOS


4.1 ESCENARIO DESARROLLADO

La planta prototipo que se ha desarrollado para las primeras pruebas incluye algunos de losdispositivos más utilizados en la industria como pueden ser cintas transportadoras, grúa y pistones.En la Figuras 68, 69, 70 y 71 se muestran capturas del escenario.

El objetivo de la planta es la clasificación y transporte de 3 tipos diferentes de cajas. Laclasificación se realiza por tamaño y para ello se hará uso de un conjunto de sensores de barrera adiferentes alturas para su clasificado. El objetivo de la Grúa es tomar las cajas medianas y pasarlasde una cinta transportadora a otra, mientas que las cajas grandes y pequeñas pasarán por la cintagiratoria que las enviará a sus correspondientes rampas de destino.

El escenario es conceptualmente simple, pero en el que se puede realizar una programacióndel PLC suficientemente compleja por los alumnos como para obtener un rendimiento óptimo delfuncionamiento de la planta. En este rendimiento se puede considerar, por ejemplo, número decajas procesadas por hora, número de cajas procesadas correctamente, errores producidos, tiemposde funcionamiento de los dispositivos para calcular consumos, etc.

Figure 68: Captura de la planta de clasificado de cajas. Vista superior.



Figure 69: Captura de la planta de clasificado de cajas.





4.2 EDITOR DE ESCENARIOS

A lo largo del proyecto se ha hablado de las partes de la aplicación, los elementos desarrollados ylas técnicas utilizadas. Pero la parte más interesante se ha mencionado al comienzo del proyecto,cuando se comentó el “Worldbuilder”. Se pretende que la aplicación sea tan escalable y configurablecomo sea posible. El desarrollo de todo el proyecto ha sido programado teniendo en cuenta que elobjetivo final es obtener un editor de escenarios.

El propósito del editor es que el usuario pueda diseñar diferentes plantas industriales segúnsea necesario. Por lo tanto, el software desarrollado proporcionaría una característica muyinteresante de escalabilidad. El editor también incluirá todos los parámetros y opciones que soninteresantes cuando se realiza la simulación de elementos industriales, tales como el tiempo de usode dispositivos, el error, la probabilidad de fallo, el tiempo medio entre reparaciones, etc. Todosestos parámetros serán configurables por el usuario y permitirá un uso más eficiente y alargará lavida del software.

El editor está en desarrollo, aunque que ya se ha obtenido los primeros resultados. La figura72 muestra capturas de pantalla del editor. La programación del editor es relativamente simple yaque se se basa enteramente en el simulador desarrollado. Con esta otra aplicación el usuario serácapaz de seleccionar la posición y ajustar los parámetros deseados de los elementos de la planta.Esto proporcionará al usuario un entorno de programación basado en formularios de edición deWindows con una ventana principal donde se puede ver el resultado de lo que se está diseñando.



El concepto de editor de escenarios no es realmente nuevo. Se ha utilizado durante muchosaños en el mundo de los videojuegos para extender su vida y mantener a los jugadores activos.Pero creemos que es un concepto interesante en el desarrollo tanto de los simuladores educativoscomo para el desarrollo comercial de aplicaciones para el control, la automatización y procesos deoptimización.

Figure 72: Capturas de pantalla del Editor de Escenarios.


5 MANUAL DE USUARIO

5 MANUAL DE USUARIO5.1 INSTALACIÓN

Para la instalación de la aplicación se seguirán los siguientes pasos.

1. Instalar XNAredist.msi.

2. Instalador OFS v3.31 en modo DEMO. Para ello solo hay que escribir “DEMO” en el apartado“Part Number” cuando el programa de instalación lo requiera. Si no se tuviera instalado.NetFramwork 1.1, el instalador del OFS le pedirá que lo instale. Aunque el paquete vieneincluido en el OFS v3.31, también se puede hacer desde windowsupdate.

3. Copiar la carpeta Sim3DAC. La ubicación de esta carpeta es indiferente.

4. Instalación de Unity Pro XL. Rellenar los campos necesarios, nombre etc. Cuando elprograma solicite el número de referencia y serie, se escogerá de entre las posibilidades,la última de todas referente a updateUnity. No es necesario instalar los drivers decomunicaciones de Unity Pro pues son para conexiónes físicas.

Sistemas Operativos:

1. Win XP, Win Vista. (32bits)No se han encontrado incidencias en la ejecución de los programas mencionados.

2. Win 7 (32bits)Los siguientes archivos deben ejecutarse en modo “Compatibilidad con Windows XP SP2”.

• OFS Factory Server.• OFS Configuration Tool.• Unity Pro.

3. Win 7 (64bits)Se han visto errores en alguna distribución de Windows 7 64bits. Aunque en otras comoWindows 7 Home Premium se ha realizado una instalación correcta de los programascomentados anteriormente. Es posible que no se pueda instalar el paquete .NetFramework1.1 desde el instalador de OFS. En este caso se podría instalar via WindowsUpdate.

El modo de compatibilidad para los programas será el mismo que en el caso de Windows7(32bits).

5.2 CONFIGURACIÓN DE UNITY PROAntes de proceder a la configuracón del servidor OPC, se va a crear el proyecto en UNITY PRO,donde realizaremos la programación.

Al crear un nuevo proyecto, se seleccionará el dispositivo MODICON M340(BMX P34 2020CPU 340-20 Modbus Ethernet) que se muestra en la figura 1.


5 MANUAL DE USUARIO

Figure 73: Captura de pantalla creación de un dispositivo en OFS

Ahora se puede guardar el proyecto con el nombre que se desee, y pasar a la siguiente etapa dela guía. La guía de programación en UNITY PRO XL es otro documento aparte.

5.3 CONFIGURACIÓN OPC OFS 3.31

1. Ejecutar OFS Configuration TOOLS en la carpeta Schneider Electric\OFS\

2. Crear un nuevo dispositivo como se indica en la figura 2.

3. Una vez creado y nombrado el dispositivo se deberán aplicar las propiedades que se muestranen la imagen de la figura 3.

4. En el apartado “Symbol Table File” se debe indicar el fichero del programa *.STU que se hacreado en Unity PRO XL para realizar la automatización de la planta. El archivo *.STU secrea desde UNITY PRO, será el archivo donde realizaremos la programación, GRAFCET,LD, etc de la planta. Este archivo debe estar creado previamente, aunque esté vacio, paraincluirlo en las opciones de “Symbol Table File”.

5. Una vez se han terminado los pasos 1, 2 y 3, solo nos queda guardar la configuración con“Save Configuration” en la pestaña “File”.


5 MANUAL DE USUARIO

Figure 74: Captura de pantalla creación de un dispositivo en OFS

Figure 75: Captura de pantalla parámetros de un dispositivo en OFS


5 MANUAL DE USUARIO

Figure 76: Escenario del Simulador. Pestaña Actuadores y cuadro de control.

5.4 DESCRIPCIÓN DEL SIMULADOR

Para lanzar el Simulador 3D, ejecutar el archivo “Simulador.exe” dentro de la carpeta Sim3DAC.

El simulador como se ve en la figura 4 contiene un cuadro de control con varias pestañas delas cuales actualmente solo se utilizaran 3, Actuadores, Sensores y OPC. En la pestaña OPCencontramos 2 botones, para la conexión y desconexión del servidor OPC.

Junto al cuadro principal se encuentra un segundo cuadro donde se pueden observar varioscontroles, como Play, Stop, Pause, Reboot, Emergency y el activador de Automatico/Manual. Enesta versión en pruebas están disponibles los botones Play, Stop y el activador Automatico/Manual.Si el activador Automatico/Manual esta en posición OFF, el simulador se encuentra en modoManual y se pueden utilizar los actuadores para activar los dispositivos del escenario. En casocontrario, se encuentra en modo ON, y será cuando esté conectado al servidor OPC, y por tantono se permite un actuación directa sobre la planta mientras la está controlando el PLC.

La navegación por el simulador se realiza utilizando las teclas “W,S,A,D” (Delante, atras,izquierda y derecha) y con el boton derecho del raton pulsado y moviendo el raton se puede hacergirar la camara a voluntad del usuario. También se dispone de una serie de vistas predefinidas alas que se puede acceder con los botones flecha de la esquina superior derecha del simulador.

El escenario es un clasificador de cajas por tamaños. Esta compuesto por los siguienteselementos:


5 MANUAL DE USUARIO

1. 2 Cintas transportadoras de 1 sentido

2. 1 Plataforma giratoria con giro de 90 grados y movimiento de rodillos en ambos sentidos.

3. Grua con 3 posiciones horizontales, 2 verticales, y garra.

4. 3 Pistones para posicionar las cajas pertinenetes en el punto de extracción de la grua.

5. Rampas de salida y Zonas de envio.

6. Sensores de barrera para la detección y clasificación de cajas.

5.5 OBJETIVOS DEL ESCENARIO

Exiten 3 tipos de cajas. Grande, mediana y pequeña. El objetivo del escenario es enviar las cajasgrandes por la rampa que se indica en la figura 5, las cajas pequeñas por la rampa que se indica enla figura 6, y las medianas deben ser recogidas por la grua y soltadas en la segunda cinta. Haciendouso de los sensores dispuestos para la clasificación deberá programarse una serie de actuacionessobre los elementos de la tabla teniendo en cuenta los retrasos debido a la comunicación, la cuales complemtamente local en el PC.

Figure 77: Rampa de salida para las cajas grandes (DANGER escrito en laterales)


5 MANUAL DE USUARIO

Figure 78: Rampa de salida para las cajas pequeñas


5 MANUAL DE USUARIO

5.6 DESCRIPCIÓN DE LOS ACTUADORES Y SENSORES DEL ESCENARIO

Los actuadores disponibles para este escenario son los siguientes:

Actuador Descripción FuncionamientoA00 Activador Cinta Tranpostadora 1 ON/OFFA01 Activador Cinta Tranpostadora 2 ON/OFFA02 Activador Angular Plataforma Giratoria ON/OFFA03 Activador Lineal 1 Plataforma Giratoria ON/OFFA04 Activador Lineal 2 Plataforma Giratoria ON/OFF

A05, A06 Activadores Grúa Horizontal

A05 A06 Ir a posiciónOFF OFF 1OFF ON 2ON ON 3ON OFF -

Ver Imagen 8

A07 Activador Subir Grúa ON/OFFA08 Activador Bajar Grúa ON/OFFA09 Activador Cerrar Garra Grúa ON/OFFA10 Activador Abrir Garra Grúa ON/OFFA11 Activador Piston Simple 1 ON/OFFA12 Activador Piston Simple 2 ON/OFFA13 Activador Piston Doble Empujar ON/OFFA14 Activador Piston Doble Subir/Bajar ON/OFF

A15 Activador Añadir Caja al Escenario

ON/OFF(Para soltar másde una caja hayque pasar antespor OFF, ciclo

completo)

Table 2: Listado de Actuadores y descripción.


5 MANUAL DE USUARIO

Figure 79: Posiciones y sensores de la grúa.

Figure 80: Sensores de la Plataforma giratoria.


5 MANUAL DE USUARIO

Los sensores disponibles para este escenario son los siguientes:

Actuador Descripción FuncionamientoS00 Plataforma Giratoria en posición 1 ON/OFFS01 Plataforma Giratoria en posición 2 ON/OFFS02 Grúa en posición 3 ON/OFFS03 Grúa en posición 1 ON/OFFS04 Grúa en posición 2 ON/OFFS05 Grua en posición Arriba/Abajo ON/OFFS06 Garra Cerrada/Abierta ON/OFFS07 Pistón 1 Extendido ON/OFFS08 Pistón 1 Recogido ON/OFFS09 Pistón 2 Extendido ON/OFFS10 Pistón 2 Recogido ON/OFFS11 Pistón Doble Extendido ON/OFFS12 Pistón Doble Recogido ON/OFFS13 Pistón Doble Extendido (Abajo) ON/OFFS14 Pistón Doble Recogido (Arriba) ON/OFF

Table 3: Listado de Sensores Normales y descripción.

Los sensores que llamaremos “prioritario” disponibles para este escenario son los siguientes,(ver las figuras 9, 10):

Actuador Descripción FuncionamientoP00 Sensor de Barrera 1 ON/OFFP01 Sensor de Barrera 2 ON/OFFP02 Sensor de Barrera 3 ON/OFFP03 Sensor de Barrera 4 ON/OFFP04 Sensor de Barrera 5 ON/OFFP05 Sensor de Barrera 6 ON/OFFP06 Sensor de Barrera 7 ON/OFF

Table 4: Listado de Sensores Prioritarios y descripción.


5 MANUAL DE USUARIO

Figure 81: Sensores de barrera prioritario llegada y clasificación de cajas.

Figure 82: Sensores de barrera para el envío de cajas a sus respectivas salidas.


5 MANUAL DE USUARIO

5.7 NORMAS PARA LA IMPLEMENTACIÓN DEL PROGRAMA DECONTROL EN UNITY PRO XL

Se recomienda que antes de empezar a programar en Unity Pro, se familiarice con el simulador3D mediante el uso de los actuadores, para tener en cuenta que pasa por ejemplo al pulsar 2actuadores que tengan relación directa, como es el caso de Abrir y Cerrar Grúa. Una vez se veanlas características de los actuadores y los sensores, cuando se activan y cuando se desactivan, seráel momento para comenzar a programar el autómata.

Por la naturaleza de la versión de pruebas, así como de la programación y la comunicación,existen retrasos en la escritura y lectura de las variables en el servidor OPC.

En la programación del PLC en UNITY PRO XL, las variables se llamarán como en el simulador“AXX, SXX y PXX”. Las variables para usar los botones STOP y PLAY, se llamarán “STPy RUN”. Todas las variables serán de la clase “BOOL”. Estas son las variables con las que secomunicarán el PLC y el Simulador. No obstante se pueden utilizar todas las variables auxiliaresque se requieran para obtener un buen rendimiento en el funcionamiento de la planta.

Antes se ha hablado de sensores prioritarios. Se llaman así pues al ser sensores de activación porpaso de elementos, es crucial obtener su estado. Aunque de ésto no se tiene que preocupar el usuario.Solo se preocupará de su activación o desactivación, pero realizando los cambios pertinentes enotras variables o estados del PLC inmediatamente.

Los sensores con nomenclatura “SXX”, permanecen siempre en un estado a lo largo del tiempohasta que se activan/desactivan y cambien de estado. No son críticos, como el caso de losprioritarios. El actuador Automatico/Manual no se programa en el PLC, pues es exclusivo delsimulador.

El simulador está en fase de pruebas. Pueden encontrarse algunos errores con los modelos.Se ha detectado un fallo de desconexión del simulador con el servidor OPC, al pulsar el botóncorrespondiente, cuando se ha estado simulando junto con el servidor y el PLC un periodo detiempo largo. En caso de ocurrir, basta con cerrar la aplicación y el Servidor OPC, y volver asimular.

5.8 CONEXIÓN Y EJECUCIÓN PLC-OPC-SIMULADORUna vez se tiene un programa para el control de la planta, se realizarán los siguientes pasos:

1. Unity Pro debe estar ejecutandose antes que el servidor OFS.

2. Arrancar el simulador del PLC, generar/compilar el proyecto de Unity Pro y cargarlo en elPLC. Mantener el PLC en STOP, que no empiece la ejecución del programa cargado.

3. Ejecutar el servidor OPC OFS en modo prueba.

4. Ejecutar el simulador 3D.

5. Realizar la conexión del simulador con el OPC. Para realizar la conexión OPC solo pulsarsobre el boton que se indica en la imagen a) de la figura 4 y aparecerá un formulario comose observa en la imagen b). Se escogerá el servidor que se ha instalado “Schneider-Aut OPCFactory Server”, y posteriormente, el dispositivo que se haya creado con el OFS ConfigurationTool.


5 MANUAL DE USUARIO

a)

b)

Figure 83: a) Imagen de la pestaña de conexión OPC, b) Imagen de los formularios de conexión.

Una vez que se ha selecionado el dispositivo, creado en el OFS Configuration Tool, y hayanaparecido a la derecha las variables que se han creado en el proyecto *.STU en Unity Pro,como se muestra en la figura 5, se eliminará el formulario pulsando la tecla “Q”, esto esobligatorio para no tener ese formulario a la vista.


5 MANUAL DE USUARIO

Este paso puede tardar un poco según el PC, y el número de variables totales que se hayannecesitado. Es posible que parezca que se ha quedado colgado el OFS. Aunque no se hallegado a observar este comportamiento, si tras un par de minutos siguen sin aparecer lasvariables, entonces si se dará por hecho que se ha quedado colgado.

Figure 84: Imagen de una conexión establecida entre OPC y Simulador.

6. Tras establecer la conexión entre el Simulador y el OPC Server, solo resta ejecutar el programacargado en el simulador de PLC de Unity Pro.

7. Para que el simulador 3D empiece a recibir datos, se debe pasar de manual a automaticomediante el boton indicado en la figura 12. Se recomienda, a la hora de implementar elprograma en el PLC, utilizar las variables “RUN” y “STP” como entradas en el PLC, pararecibir en el PLC las ordenes de los botones PLAY y STOP del simulador.

5.9 MODIFICACIONES DEL PROYECTO EN UNITY PRO

En caso de hacerse una prueba de un programa realizado en Unity Pro con el simulador, seprodecerá como se ha comentado en el apartado anterior. Será necesario realizar pruebas paracomprobar si la solución es correcta. En caso de hacerse una prueba y no obtener el resultadodeseado, la solución deberá ser modificada. Para ello habrá que desconectar primero el simuladordel Servidor OPC mediante el botón adecuado. Se comprueba que en el Servidor OPC el número declientes conectados es cero. Tras desconectar simulador 3D y Servidor OPC, pararemos la ejecucióndel simulador mediante el boton “Stop” que ofrece Unity Pro en la barra de herramientas. Tras


5 MANUAL DE USUARIO

esto, se realiza la desconexión de Unity Pro con el simulador de PLC. A partir de aquí se podrámodificar la solución y volver a empezar con las pruebas. Siempre debe guardarse el proyecto*.STU antes de realizar la prueba para que el servidor OPC disponga de las nuevas variables quese hayan creado.

5.10 VIDEO DE EJEMPLO DE CONEXION Y FUNCIONAMENTO DE LAPLANTA

Aunque nunca existe una única forma de programar una planta, en el video “Demo Planta” quese adjunta, se muestra como debería ser aproximadamente el funcionamiento de la planta. En elvideo demostrativo también se incluye la conexión al servidor y la puesta en marchadel programa en el PLC.


6 CONCLUSIONES Y FUTURAS LINEAS DE TRABAJO

6 CONCLUSIONES Y FUTURAS LINEAS DE TRABAJO

Se ha mostrado el desarrollo de un software flexible y escalable para realizar simulaciones demaquinaria industrial en 3D, integrando en el mismo un sistema físico para poder observar elresultado de la simulación sobre los objetos con los que interaccionarán los elementos industriales.La simulación se realiza sobre objetos rígidos modelados mediante polígonos, donde un modelo dedinámica de colisiones es el responsable de simular la interacción entre los diferentes objetos deun escenario. Se han elaborado los elementos fundamentales para el desarrollo de una plataformadidáctica interactiva, sobre software libre. Actualmente solo se dispone de los elementos descritosen este proyecto y de una planta simulada. Es por lo que se plantea la posible continuación deeste trabajo para desarrollar nuevos elementos y terminar los dos dispositivos que se encuentraninacabados, así como finalizar el editor de escenarios. De esta forma la aplicación crecerápudiendose utilizar para crear nuevos escenarios por parte de los alumnos y un mejor aprendizajede las técnicas y módulos de la programación de PLC’s.

Como comentario adicional, este proyecto se ha utilizado para la presentación de dos artículos.El primer artículo se presentaró en las “XXXII Jornadas de Automática de la CEA” celebradas enSevilla los días 7, 8 y 9 Septiembre de 2011. El segúndo artículo fue aceptado y presentado en el“SICE 2012 Annual Conference” celebrado los días 21, 22 y 23 de Agosto de 2012 en Akita, Japón.Además se realizó una presentación del mismo en la sede de D+TEC, Asociación de profesionalesde la tecnología, el día 16 de Diciembre de 2012. (www.dmastec.org)

• Adolfo J. Sánchez del Pozo, Juan Manuel Escaño González, Luis Fernando Castaño Castaño:Realidad Virtual en 3D para Automatización y Control. Actas de las XXXII Jornadas deAutomática (Ja 2011). XXXII Jornadas de Automática (Ja 2011). Sevilla. Universidad deSevilla. 2011.

• del Pozo, A.S.; Escano, J.M.; Bordons, C. “Simulator for control and automation usingan interactive and configurable 3D virtual environment”. Proceedings of SICE AnnualConference 2012 (ISBN: 978-4-907764-40-1, IEEE Catalog Number: CFP12765-DVD),(2012/8/23, Akita, Japan), Page(s): 2268 - 2273.


7 BIBLIOGRAFIA

7 BIBLIOGRAFIA

[1] Crowe, C. T., Elger, D. F., Williams, B. C., Roberson, J. A.(2009): Engineering FluidMechanics, 9th Edition. John Wiley & Sons, Inc. Chapter 11. Sections 11.2, 11.3.

[2] Kim, Y. J., Otaduy, M. A., Lin, M. C., Manocha, D. (2002): Fast Penetration DepthComputation for Physically-based Animation. Symposium on Computer Animation - SCA , 2002.

[3] McCormick, B. W. (1979): Aerodynamics, Aeronautics, and Flight Mechanics. John Wiley& Sons, Inc., New York. pp. 168-178.

[4] Millington, I. (2007): Game Physics engine development. Morgan Kaufmann Publishers.Elsevier Inc. pp.69-71, 111-119.

[5] Mirtich, B. (2000): Timewarp rigid body simulation. In Proc. SIGGRAPH 2000, 193–200.[6] Nota de prensa. aDeSe. Balance económico de la industria del videojuego 2010. Gabinete

de prensa de aDeSe: Marta Frau / Juan Gabriel Corral.[7] Serway, R. A. , Jewett, J. W. (2004): Physics for Scientists and Engineers, 6th Edition, pp.

131-133.[8] Stewart, D. E. (2000): Rigid-body dynamics with friction and impact. SIAM Review Vol.

42, No. 1, 3–39.[9] Schneider Electric. Unity Pro. Program Languages and Structure. Reference Manual. April

2009


SIMULADOR PARA CONTROL Y AUTOMATIZACIÓN...

Documents

Transcript of SIMULADOR PARA CONTROL Y AUTOMATIZACIÓN...