Simulador para Control y Automatizacion Utilizando Un Entorno Virtual 3D Interactivo y Configurab PDF

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 7
1.1 INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 ESTRUCTURA DEL DOCUMENTO . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 INTRODUCCION TEORICA 12
2.1 SITUACION DE PARTIDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 DESCRIPCION DE LA APLICACIÓN OBJETIVO . . . . . . . . . . . . . . . . . 12
2.2.1 Conexión mediante Server OPC . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Conexión mediante puerto USB . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 TECNOLOGIAS Y HERRAMIENTAS DE DESARROLLO . . . . . . . . . . . . . 14
2.3.1 INTRODUCCIÓN A C# Y XNA . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 ENTORNOS DE MODELADO 3D. INTRODUCCION A AC3D. . . . . . . 18
2.3.3 OPC (OLE FOR PROCESS CONTROL) . . . . . . . . . . . . . . . . . . . 20
3 DISEÑO E IMPLEMENTACION DEL SIMULADOR 24

3.1 MOTOR FÍSICO Y SISTEMA DE COLISIONES . . . . . . . . . . . . . . . . . . 24
3.2 ESTRUCTURA DE LA APLICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 PROGRAMA PRINCIPAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 CLASES PARA LOS ELEMENTOS INDUSTRIALES . . . . . . . . . . . . . . . . 31
3.4.1 CINTA TRANSPORTADORA . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 PLATAFORMA GIRATORIA + CINTA . . . . . . . . . . . . . . . . . . . 37
3.4.3 GRÚA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.4 RAMPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.5 DESTRUCTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.6 PISTON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.7 SENSORES DE BARRERA . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.8 MONTACARGAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.9 ROBOT 5 GRADOS DE LIBERTAD . . . . . . . . . . . . . . . . . . . . . 55
3.4.10 CONEXION CLIENTE OPC - SERVIDOR OPC - PLC . . . . . . . . . . . 61
3.4.11 CUADRO DE CONTROL Y OPCIONES . . . . . . . . . . . . . . . . . . . 64
4 ESCENARIO PROTOTIPO Y EDITOR DE ESCENARIOS 67

4.1 ESCENARIO DESARROLLADO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2 EDITOR DE ESCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 MANUAL DE USUARIO 71
5.1 INSTALACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 CONFIGURACIÓN DE UNITY PRO . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 CONFIGURACIÓN OPC OFS 3.31 . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4 DESCRIPCIÓN DEL SIMULADOR . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5 OBJETIVOS DEL ESCENARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6 DESCRIPCIÓN DE LOS ACTUADORES Y SENSORES DEL ESCENARIO . . 77
5.7 NORMAS PARA LA IMPLEMENTACIÓN DEL PROGRAMA DE CONTROL EN
UNITY PRO XL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.8 CONEXIÓN Y EJECUCIÓN PLC-OPC-SIMULADOR . . . . . . . . . . . . . . . 81
5.9 MODIFICACIONES DEL PROYECTO EN UNITY PRO . . . . . . . . . . . . . . 83
5.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 Figuras
1 Usuarios de Half-Life 2 interactuando con objetos del escenario. . . . . . . . . . . 7
2 Imagenes de varios escenarios de ITS PLC. a) Almacen automatizado. b) Mezclado
de pintura. c) Selección y empaquetado de piezas. . . . . . . . . . . . . . . . . . . 8
3 Imagen mostrando la asignación estática de los sensores y actuadores en un escenario
de ITS PLC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Captura de pantalla de una parte del modelo 3D de la grúa en AC3D. . . . . . . . 19
5 Captura de pantalla de la texturización de un modelo en AC3D . . . . . . . . . . . 20
6 Esquema de conexión mediante OPC Server. . . . . . . . . . . . . . . . . . . . . . 20
7 Esquema de conexión, entradas/salidas e interfaces. . . . . . . . . . . . . . . . . . . 21
8 Ejemplos de uso de Bullet Physics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9 Ejemplos de uso de JigLibX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10 Contacto entre 2 objetos penetrando . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11 Objetos con composición geométrica simple a), y compuesta b). . . . . . . . . . . . 28
12 Estructura del proyecto JigLibX en Visual Express C#. . . . . . . . . . . . . . . . 28
13 Estructura de la aplicación. Diagrama de flujo. . . . . . . . . . . . . . . . . . . . . 29
14 Estructura del proyecto de la aplicación en Visual Express C#. . . . . . . . . . . . 29
15 Ejemplo de código en C# de la declaración de las variables para incluir mesas
giratorias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16 Código en C# de la carga de contenidos 3D. . . . . . . . . . . . . . . . . . . . . . 30
17 Código C# de uso repetitivo para inicializar un elemento. . . . . . . . . . . . . . . 31
18 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 de
modelos 3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
19 Estructura de métodos de la clase Elemento Industrial. . . . . . . . . . . . . . . . 32
20 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. . . . . . . . . . . . . . . . . . . . . . . . . . 32
21 Imágenes pruebas de transporte de un objeto físico por la cinta transportadora. . . 33
22 Imágenes de la Cinta transportadora parcialmente texturizada. a) Imagen en reposo.
b) Imagen transportando objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
23 Imágenes del modelado final de la cinta transportadora y la zona de caída de cajas. 35
24 Imágenes del renderizado de los objetos físicos que realizan la simulación de la cinta
transportadora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
25 Código en C# que describe el movimiento de la cinta giratoria mediante las variables
de velocidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
26 Imágenes del renderizado de los modelos físicos y 3D de la plataforma giratoria. . . 39
27 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. . . . . . . . . . . . . . . . . . . . 39
28 Código en C# del método “Update2” de la plataforma giratoria que se ejecutará
tras el paso por el motor físico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
29 Imagen del modelo completo de la grúa del proyecto, garra abierta y bajada. . . . 40
30 Imagen del modelo completo de la grúa del proyecto, garra abierta y subida. . . . . 41
31 Imagen del modelo físico que simulará el funcionamiento de la grúa. . . . . . . . . 41
32 Imagen del modelo físico que simulará el funcionamiento de la grúa. . . . . . . . . 42
33 Imagen de la grúa sosteniendo una caja. . . . . . . . . . . . . . . . . . . . . . . . . 42
34 Imagen de la grúa soltándo una caja en movimiento. . . . . . . . . . . . . . . . . . 43
35 Código C# que se encarga del funcionamiento de la garra mediante detección de
colisiones añadidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
36 Imágenes de los modelos a) 3D , b) físico de la rampa. . . . . . . . . . . . . . . . . 45
37 Código en C# de la declaración e inicialización de un elemento Rampa. . . . . . . 46
38 Imágenes del renderizado 3D de un Destructor. . . . . . . . . . . . . . . . . . . . . 46
39 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 otros
objetos del escenario y eliminarlos encaso positivo. . . . . . . . . . . . . . . . . . . 47
42 Código en C# donde se declaran las variables de objetos físicos. . . . . . . . . . . . 48
41 Imágenes del Pistón. a) Modelo 3D pistón recogido b) Modelo 3D pistón extendido. 49
43 Código en C# para la simulación del movimiento del pistón. . . . . . . . . . . . . 50
44 Imagen del pistón doble en resposo sobre la cinta transportadora. . . . . . . . . . . 50
45 Imagen del pistón doble empujando una caja. . . . . . . . . . . . . . . . . . . . . . 51
46 Imagen del Sensor de barrera. Modelo 3D del Sensor con rayo. . . . . . . . . . . . 51
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. . . . . . . . . . . . . . . . 52
48 Código C# que muestra como se detecta la colisión con el segmento y la
comprobación de ID’s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
49 Imagen del modelado 3D del montacargas detenido. . . . . . . . . . . . . . . . . . 53
50 Imagen del modelado 3D del montacargas subiendo un objeto. . . . . . . . . . . . . 54
51 Imagen de la estructura física que conforma el montacargas. . . . . . . . . . . . . . 54
52 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. . . . . . . . . . . . . . . 55
54 Imágenes de los modelos físicos del brazo de 5 grados. 4 elementos más la garra. . 56
53 Imágenes del brazo en 3 posiciones diferentes. . . . . . . . . . . . . . . . . . . . . 57
55 Código en C# de los objetos físicos y otras variables del brazo. . . . . . . . . . . . 58
56 Código en C# de la inicialización y adición al motor físico de los objetos. . . . . . 59
57 Código en C# del control de la primera sección del brazo. La sección 0 es la base. 59
58 Código en C# del control de la segunda sección del brazo. . . . . . . . . . . . . . . 60
59 Código en C# del control de la tercera sección del brazo. . . . . . . . . . . . . . . 60
60 Código en C# del control de la garra sección del brazo. . . . . . . . . . . . . . . . 61
61 Captura de pantalla del formulario de conexión Cliente - Servidor OPC. . . . . . . 62
62 Código del método para la lectura de actuadores del servidor. . . . . . . . . . . . . 63
63 Código del método de escritura de sensores no prioritarios en el servidor OPC. . . 63
65 Código de la declaración de variables que contendrán las imágenes para los elementos
del cuadro de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
64 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. . . . . . . . . . . . . . . . . . . 65
66 Código para posicionar los elementos en el mismo lugar sin importar el tamaño de
la ventana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
67 Código para la detección de pulsado de botones en la aplicación. En este caso se
comprueban los 15 primeros actuadores. . . . . . . . . . . . . . . . . . . . . . . . . 66
68 Captura de la planta de clasificado de cajas. Vista superior. . . . . . . . . . . . . . 67
69 Captura de la planta de clasificado de cajas. . . . . . . . . . . . . . . . . . . . . . . 68
72 Capturas de pantalla del Editor de Escenarios. . . . . . . . . . . . . . . . . . . . . 70
73 Captura de pantalla creación de un dispositivo en OFS . . . . . . . . . . . . . . . . 72
74 Captura de pantalla creación de un dispositivo en OFS . . . . . . . . . . . . . . . . 73
75 Captura de pantalla parámetros de un dispositivo en OFS . . . . . . . . . . . . . . 73
76 Escenario del Simulador. Pestaña Actuadores y cuadro de control. . . . . . . . . . 74
77 Rampa de salida para las cajas grandes (DANGER escrito en laterales) . . . . . . 75
78 Rampa de salida para las cajas pequeñas . . . . . . . . . . . . . . . . . . . . . . . . 76
79 Posiciones y sensores de la grúa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
80 Sensores de la Plataforma giratoria. . . . . . . . . . . . . . . . . . . . . . . . . . . 78
81 Sensores de barrera prioritario llegada y clasificación de cajas. . . . . . . . . . . . . 80
82 Sensores de barrera para el envío de cajas a sus respectivas salidas. . . . . . . . . . 80
83 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 produce
resultados que permiten prevenir errores en los sistemas reales. Mediante el uso de un simulador
para entornos industriales se reduciría el tiempo de programación y depuración de las mismas. Pero
se puede ir más allá de estos conceptos si se habla en materias de educación y prácticas mediante el
desarrollo de una plataforma de simulación de maquinaria industrial, mediante realidad virtual en
3D, 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 medida
que pasan los años, los videojuegos mejoran en calidad gráfica, jugabilidad, interactividad con el
usuario etc. El volumen de ventas de videojuegos crece con los años y esto repercute directamente
en 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 juegos
generan importantes ingresos anualmente, 631M€ en España en 2010 obtenida de [6], para este
proyecto interesan especialmente los FPS. Éstos son juegos en primera persona en los cuales el
usuario se introduce en la piel del personaje en un mundo virtual con ciertos objetivos. El primer
FPS apareció en el año 1973 de la mano de Steve Colley bajo el nombre Maze Wars. A medida
que pasaron los años, los FPS mejoraron en varios aspectos y aunque el primero de ellos fue la
calidad gráfica, en la actualidad no es el único en desarrollo y mejora. Actualmente los aspectos
más valorados son la conectividad, interactividad con el entorno y la calidad del sistema físico del
videojuego.
En los videojuegos actuales los usuarios interactuan con los objetos de su entorno; pueden
cogerlos, tirarlos y empujarlos para sus propios propositos. Un ejemplo de esto se da en Half-Life
2, la secuela de Half-Life, lanzado al mercado en 2004 y que permite una gran interacción con el
entorno, ver Figura 1. Llegados a este punto, surge la cuestión: si a los videojuegos se les incluye
un sistema físico muy realista para hacerlos más atractivos, ¿por qué no hacer lo mismo con los
simuladores industriales y diseñarlos en 3D? Una simulación de entornos industriales realista con
los objetos del propio sistema sería útil para la programación y prevención de fallos que pudieran
ocurrir 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 de

pintura. c) Selección y empaquetado de piezas.
1.2 ESTADO DEL ARTE
Existen actualmente propuestas comerciales que, en un entorno interactivo en 3D, incluyen un

sistema físico realista, como es el caso de “ITS PLC ” de Realgames (www.realgames.pt). La
conectividad de este simulador se realiza mediante una tarjeta de entradas y salidas y conexión
mediante 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. Éstos

pretenden simular plantas industriales sencillas de procesado de distinto tipo. Pone a disposición
del 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 no
se pueden modificar, ver figura 3.
Proporciona un cuadro de mandos para que el usuario pueda detener, pausar, resetear y cambiar
de 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 sensor
tiene 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 los
elementos de los escenarios.

1 INTRODUCCIÓN
Figura 3: Imagen mostrando la asignación estática de los sensores y actuadores en un escenario de

ITS PLC.
Aunque la aplicación es muy realista respecto a la física de los objetos y la sección de creación
de 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ás
completa y con mejor calidad observada, además de haberse utilizado por el autor del documento
en el laboratorio.
1.3 OBJETIVOS
En este documento se presenta el desarrollo de una plataforma 3D que permitirá la simulación de

entornos industriales.
La decisión de realizar esta plataforma como Proyecto Final de Carrera viene tras haber
comprobado las carencias de las aplicaciones existentes en el ámbito de la educación en control y
automatización. Es decir, el objetivo de este proyecto es el de obtener una aplicación que incluya
todas posibilidades que se creen necesarias para que la experimentación en laboratorio con PLC’s
y 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 ha

realizado utilizando aplicaciones de libre distribución y de código libre. Incluyendo la parte de
programación de la aplicación, este proyecto también incluye una parte de integración de otros
elementos necesarios para llevar a cabo su desarrollo. Además gozará de todas las carencias que
puedan 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 3D
e incluirá un sistema físico.
2. Editor de escenarios.
Esta aplicación, aunque secundaria, es la clave para que la plataforma goce de una gran
escalabilidad a nivel de usuario. Con esta herramiento un usuario podrá diseñar un simulador
mediante el uso de los elementos industriales disponibles. Ofrecerá al usuario la posibilidad
de 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ía
anglosajona 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 de
PLC. Para esto se han barajado diferentes opciones:
• La primera sería realizar una conexión física con un PLC comercial mediante los puertos
USB 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 una
buena opción ya que es una solución abierta y flexible al clásico problema de los drivers
propietarios, con la ventaja añadida que la mayoría de los grandes fabricantes incluyen OPC
en sus productos.
Algunos fabricantes de PLC’s suministran una aplicación que simula el comportamiento del
PLC [9] y al ejecutarse constituye un proceso independiente que utiliza los drivers propios para
comunicar con el entorno de programación. Esto permite contar con la ventaja de no necesitarse
un PLC comercial para realizar la programación del simulador. Con todo esto un usuario sería
capaz 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 de
este software, que serán tratados en los siguientes apartados, son el sistema físico, el sistema de
colisiones y el desarrollo de maquinaria industrial.

1 INTRODUCCIÓN
Aunque los objetivos principales se han descrito, queda un último objetivo que se va a comenzar
en 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á la
tarea de modificar la solución para que la plataforma pueda ser ampliada y mejorada por personas
ajenas 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 del
resto 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 entrando
directamente 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 un
correcto 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ón
de 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ía
de la aplicación pero no muy bien como realizarla.
Inicialmente, como en todo proyecto, se buscaron las posibilidades para poder diseñar y
programar la plataforma 3D. Se indagó en el mundo de los videojuegos, pues el autor ya conoce
algunos juegos que incluyen algunos constructores muy utilizados por los usuarios, como es el
caso de “Garry’s MoD”. De esta forma se iban recogiendo diferentes posibilidades de lenguajes
de programación para el desarrollo de la aplicación en cuestión. También se investigó un poco el
contenido 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. Ésto
aceleró 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 vez
se decidieron tanto el lenguaje de programación como la base para el desarrollo de objetos en 3D, el
avance 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 desarrollo
en 3D.
• 1 mes para comenzar a tener los primeros resultados viables en cuanto a elementos
industriales.
A partir del comienzo del tercer mes todo fue fluido y se desarrollaron sin demasiados problemas
otros elementos industriales que se detallarán más adelante.
Aproximadamente al comienzo del quinto mes ya se disponía de un escenario funcional que

incluí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 desarrollados

y dotarlos de una estética 3D más realista, así como el planteamiento y la creación de nuevos
elementos 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. Hay
que razonar como de lejos se prentede llegar con esta plataforma y ver como sería la plataforma
si ya estuviera realizada. Ésto conlleva un problema. Es posible que se exija demasiado y no se
pueda llevar a cabo. Aunque dadas las características de los lenguajes de programación orientados
a objetos, se concluyó que la mejor opción de conseguir el software deseado era de la forma que
se ha planteado. Decidir el alcance que va a tener la aplicación es fundamental pues a la hora de
realizar 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 del
código ya existente para optimizar e incluir nuevas funcionalidades.
Siguiendo este planteamiento se comienza determinando que debe ofrecer la aplicación al

usuario. Debe poder ser escalable. La aplicación no puede quedarse estancada en un número
determinado de escenarios de simulación como ocurre en ITS PLC. Y el usuario debería ser capaz
de 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 un
dispositivo, como por ejemplo una cinta transportadora, el usuario debería ser capaz de configurar
su comportamiento. Las cintas no son todas iguales, ni en forma, tamaño o dinámica. Aquí entra
en juego el término configuración. El usuario podrá incluir la función de transferencia que modela
la dinámica de la cinta transportadora. En este caso podría ser la función de transferencia de los
motores que mueven la cinta. De esta forma con un único dispositivo programado en la aplicación el
usuario 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ón

está referida a elementos o dispositivos que se utilicen a nivel industrial y necesiten de una
programación separada de la del PLC, como puede ser un brazo robótico para la seleción de
piezas, soldaduras, ensamblajes etc. Poniendo como ejemplo el SCORBOT, y usándolo como base
para un posible dispositivo del simulador, se incluirá en el simulador la herramienta necesaria
para realizar la programación de las acciones que deba hacer el brazo ante las señales de entrada
procedentes del PLC. La programación se realizará con un pequeño conjunto de las instrucciones
del lenguaje ACL.
Dado que se está hablando de diseñar una plataforma para el entrenamiento con PLC’s es muy
importante pensar en como se va a hacer la conexión con el PLC. Aquí se tienen varias posibilidades
de 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 real
y un PC que contenga el simulador y un cliente OPC. El servidor OPC será el intermediario para
el intercambio de datos entre ambos equipos. Para la conexión de los equipos solo haría falta una
red 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 puede
hacer 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 de
simulación de PLC’s. En pocas palabras, se puede tener en un mismo PC las tres aplicaciones para
establecer una conexión local interna y poder realizar la simulación y el control sin la necesidad de
usar 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 debido
a un mal uso por parte del usuario es inexistente. Otra ventaja añadida de no usar PLC’s, es el
número de puestos de trabajo que se pueden utilizar. Ahora solo son necesarios PC’s, pudiendose
ampliar a un costo menor el número de estaciones disponibles para el alumnado. El único requisito
de 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 el
simulador, 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 utilizados
para 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ón
adecuado es fundamental. Aunque en principio se podría utilizar cualquier lenguaje orientado
a objetos actual tales como JAVA, C++, C# o Lua, éste último muy utilizado en el desarrollo
de videojuegos, se optó por indagar cuál de ellos sería un lenguaje óptimo para el desarrollo del
simulador dado que se comenzaba este proyecto desde cero.
Inicialmente y dado que no se sabía programar en JAVA, se descartó inicialmente dejándolo

como última opción. Sin embargo una opción viable de lenguaje a utilizar es Lua. Lua es un
lenguaje de extensión, suficientemente compacto para usarse en diferentes plataformas. En Lua las
variables no tienen tipo, sólo los datos y pueden ser lógicos, enteros, números de coma flotante o
cadenas. Estructuras de datos como vectores, conjuntos, tablas hash, listas y registros pueden ser
representadas utilizando la única estructura de datos de Lua: la tabla. La semántica de Lua puede
ser 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 lo
anterior, 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 normalmente
transparente al usuario y se realiza en tiempo de ejecución, pero puede hacerse con anticipación
para aumentar el rendimiento y reducir el uso de la memoria al prescindir del compilador. También
es 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 ganado
seguidores 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 lenguaje
de 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 como
lenguaje se desechó, no porque no ofreciera las características necesarias, sino por la renderización
en 3D. Paralelamente a la busqueda del lenguaje de programación también se realizó la busqueda
de librerías que permitieran programar el renderizado en 3D para el simulador. Se encontró un
framework desarrollado por Microsoft para el desarrollo de juegos independientes para la consola
de videojuegos XBox. Con este framework los programadores independientes podían desarrollar
videojuegos y colgarlos gratuitamente o de pago en la comunidad de jugadores online. Este
framework es XNA y permite el renderizado en 3D incluyendo una buena documentación. Dado
que el disponer de una buena documentación es importante y tras observar algunos de los resultados
que obtenian los programadores utilizando XNA, se decidió que sería la librería para realizar la
programación 3D del simulador. Debido a que está implementada utilizando C# y que tanto XNA
como C# gozaban de las características necesarias para la implementación del simulador en 3D
deseado, 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 por

Microsoft como parte de su plataforma .NET, que después fue aprobado como un estándar por
la ECMA (ECMA-334) e ISO (ISO/IEC 23270). C# es uno de los lenguajes de programación
diseñ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és
sharp) indica que la nota (C es la nota do en inglés) es un semitono más alta, sugiriendo que
C# 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# es
un lenguaje de programación independiente diseñado para generar programas sobre dicha
plataforma. 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) y
que se pasa por valor al método la referencia , pero el espacio reservado para la lista es
comú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 por
valor 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 a
inicializar la variable antes de pasar el parámetro.
• Cuando ref y out modifican un parámetro de referencia, la propia referencia se pasa por
referencia.

• El modificador params sirve para definir un número variable de argumentos los cuales
se 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álidas
como tipos de valores devueltos).
• C# implementa sobrecarga de métodos, dos o más métodos pueden tener el mismo
nombre 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ósito

general.
• Inclusión de principios de ingeniería de software tales como revisión estricta de los tipos
de datos, revisión de límites de vectores, detección de intentos de usar variables no
inicializadas, y recolección de basura automática.
• Capacidad para desarrollar componentes de software que se puedan usar en ambientes
distribuidos.
• 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 administrado

proporcionado 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 " y
traer diferentes aspectos de la producción de juego en conjunto a un único sistema. XNA es
una herramienta que se anunció el 24 de marzo de 2004, en la Game Developers Conference en
San José, California. La primera comunidad Technology Preview de XNA Build fue lanzada
el 14 de marzo de 2006. XNA Game Studio 2.0 fue lanzado en diciembre de 2007, seguido
de XNA Game Studio 3.0 en 30 de octubre de 2008.
XNA actualmente abarca secciones de Microsoft Game Development Sections, incluyendo el

está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 para
el 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 marco
se ejecuta en una versión de Common Language Runtime que se ha optimizado para que los
juegos de azar proporcionar un entorno de ejecución administrado. El tiempo de ejecución
está disponible para Windows XP, Windows Vista y Xbox 360. Dado que XNA Games están
programados para el tiempo de ejecución, que se ejecuten en cualquier plataforma que admite
el XNA Framework con mínima o ninguna modificación. Juegos que se ejecutan en el marco
técnicamente pueden escribirse en cualquier lenguaje compatible con .NET, pero oficialmente
se admiten sólo C# y XNA Game Studio Express IDE y todas las versiones de Visual Studio
2005.
El XNA Framework por lo tanto encapsulado bajo nivel tecnológicos detalles relacionados
en un juego de codificación, asegurándose que el propio marco se encarga de la diferencia
entre plataformas cuando los juegos son portados desde una plataforma compatible a otra
lo que permite que los desarrolladores de juegos para concentrarse más en el contenido y la
experiencia de juego. XNA Framework se integra con una serie de herramientas, tales como
la plataforma múltiple audio creación herramienta (XACT), para ayudar en la creación de
contenido. XNA Framework proporciona apoyo para la creación de juego 2D y 3D y permite
el uso de los controladores de Xbox 360 y vibraciones. Sólo los juegos de marco XNA
actualmente destinadas a la plataforma Xbox se pueden ser distribuidos a los miembros de
Club de la Microsoft XNA Creator que lleva un $ 99/año suscripción. Desktop applications
pueden 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 Studio
2.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 Live
en Windows y Xbox 360 y mejor dispositivo manipulación.
• XNA Game Studio 3.0 (para Visual Studio 2008 o para free Visual C# 2008 Express
Edition).
Permite la producción de juegos de la plataforma de Zune y agrega soporte de la

comunidad de Xbox Live. Una versión beta del conjunto de herramientas de se lanzó en
septiembre de 2008. La versión final fue lanzada el 30 de octubre de 2008. XNA Game
Studio 3.0 ahora es compatible con C# 3.0, LINQ y la mayoría de las versiones de Visual
Studio 2008. También hay varias características nuevas de más de XNA Game Studio
3.0, tales como un modo de prueba se agrega a XNA Game Studio 3.0 que permitirá a los
creadores agregar fácilmente la función de prueba necesario para sus juegos, funciones
de varios jugadores XBOX LIVE como en el juego invita, crear juegos de plataformas
que 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 de
DreamSpark de Microsoft por parte de los alumnos.
Es lo que dará la competencia directa con el iPod de Apple ya que permite desarrollar
juegos 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 inteligente
pueden comprar o probar las aplicaciones, como se ha visto en el Xbox 360. Cabe
destacar la adicion de México para el mercado y que este estará disponible para uso en
30 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 simulador
y realizar el renderizado 3D de los objetos mediante C# y XNA. No obstante, es necesario diseñar
los objetos 3D antes de poder renderizarlos por pantalla. Para poder hacer ésto se necesita un
software 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áficos
y animación 3D desarrollado por Autodesk, en concreto la división Autodesk Media &
Entertainment (anteriormente Discreet). Creado inicialmente por el Grupo Yost para
Autodesk, 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 3D
más utilizado, especialmente para la creación de video juegos, anuncios de televisión, en
arquitectura 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, con
un 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 importantes
sobre éstas, como la configuración personalizada de la distribución de los menús y vistas de
cámara.
Tanto 3ds Max, como Blender son programas excesivamente complejos y requieren de numerosas
horas de estudio para el diseño de modelos 3D. Por lo que se buscaron otras opciones para realizar
los modelos 3D que se incluirán en el simulador.

Tras buscar otros programas que permitieran el modelado 3D se encontró uno que incluía
muchas de las opciones de 3ds Max y Blender, con una interfaz gráfica muy parecida, pero con una
simplicidad de implementación de modelos mediante menús intuitivos que hacen de este software
una 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 se
ha 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 y
esféricos. De esta forma el diseño de un elemento nuevo en 3D en el AC3D se llevará a cabo de
forma rápida y sencilla. El programa dispone de funciones básicas booleanas para aplicar entre 2
objetos 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 textura
destino en un formato de dibujo, png, jpeg etc, y se asignarán las diferentes texturas a las diferentes
superficies según el objeto. A los modelos desarrollados se les aplicará una optimización de vértices
y 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. En
este proyecto se ha realizado el diseño para una conexión directa entre un simulador de PLC y el
simulador 3D. La conexión directa se refiere a una conexión interna en el mismo ordenador donde
se ejecutarán todas las aplicaciones, con lo que se realizan conexiones locales. Todo se ejecuta en
el mismo PC, lo que permitirá que un usuario pueda llevarse el trabajo a casa. De esta forma
no será necesario el uso de un PLC real para poder llevar a cabo la programación del autómata
y la programación de la planta simulada. Para realizar la conexión entre el simulador de PLC y
el 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 control
y supervisión de procesos industriales. De ésta forma la conexión establecida tendra un sistema
intermedio que será el servidor OPC que se encargará del intercambio de datos entre simulador de
PLC 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 que
permite que componentes software individuales interaccionen y compartan datos. La comunicación
OPC se realiza a través de una arquitectura Cliente-servidor. El servidor OPC es la fuente de
datos (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 una
solución abierta y flexible al clásico problema de los drivers propietarios. Prácticamente todos los
mayores fabricantes de sistemas de control, instrumentación y de procesos han incluido OPC en
sus productos.
El propósito principal del estándar OPC es proporcionar a las aplicaciones una forma común
de acceder a los datos de cualquier fuente, como un dispositivo o una base de datos. Gracias a esta
forma común de acceso a datos que proporciona OPC los fabricantes de hardware sólo tienen que
hacer un conjunto de componentes de programa para que los clientes los utilicen en sus aplicaciones
y 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. Distintas
aplicaciones podrán coger datos de aparatos físicos y llevarlo a SCADA o DCS, o de un servidor
SCADA 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 OPC
proporcionados por uno o más fabricantes. De esta forma no existe restricción por cuanto a tener
un Software Cliente para un Software Servidor, lo que es un problema de interoperabilidad que
hoy en día se aprecia con sistemas del tipo propietario. Sistemas de control supervisorio como lo
son SCADA o DCS pueden comunicarse con un Servidor OPC y proveer a este, información de
los dispositivos de campo asociados. De esta forma, aplicaciones cliente OPC de otros fabricantes
tendrán acceso a estos datos por medio del servidor.
Tipos de servidores OPC:

1. Servidor de Acceso a Datos OPC
A un alto nivel, está compuesto por los objetos:
• Servidor: Mantiene la información sobre sí mismo, y unifica los Datos dentro de un
Grupo.
• Grupo: Dota de un mecanismo que contiene en forma lógica los ítemes. Se clasifican en
público o local.
• Ítem: Es un valor, una condición y permanece o varía en el tiempo. Es una dirección
específica de los datos y no la fuente de datos.
2. Servidor de Alarmas, Condiciones y Eventos OPC
Provee de Interfaces, donde Clientes OPC son notificados de Sucesos. Estos mecanismos se
definen 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 de
aplicaciones de acceso a datos. Características: Arquitectura de comunicación abierta y
eficaz, concentrada en el acceso a datos y no en los tipos de datos. Propósito: Permite que
aplicaciones (MS Office, Objetos WWW) accedan a datos de un dispositivo o un banco de
datos “In process”. Facilita el desarrollo de aplicaciones sin sacrificar la funcionalidad de la
Interfaz Cliente.
4. Intercambio de Datos OPC (OPC DX)
Define un conjunto de interfaces que permiten el intercambio de datos, así como la
comunicación "server to server" entre dispositivos y controladores conectados a Ethernet,
que utilizan distintos protocolos. OPC-DX permite a los servidores OPC-DA intercambiar
directamente datos sin la exigencia de un cliente OPC intermedio. La mejor manera de
pensar en un servidor OPC-DX es como un servidor OPC-DA que se puede configurar para
intercambiar 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 aplicaciones
de empresa y son cada vez más un proceso de control de entornos. OPC XML-DA salió a la luz
en 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 escritas
en Java, Perl, Python, y otros idiomas que soporta SOAP. SOAP y XML Web Services utiliza
Protocolo 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 de
rendimiento posible, OPC XML-DA es poco probable que se utilice para aplicaciones en
tiempo real, a pesar de que normalmente se usa de puente entre la empresa y la red de
control.
6. Arquitectura Unificada OPC (OPC UA)
Refleja el objetivo de Microsoft de retirar DCOM en favor de .NET y arquitecturas orientadas
a 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 de
dos transportes: SOAP / HTTP (S) y un mensaje binario codificado en la parte superior
de TCP. Es prematuro evaluar la seguridad de OPC UA en relación con DCOM, ya que la
API OPC UA de seguridad aún está en desarrollo. Sin embargo, dado que ahora existe una
mayor conciencia en la OPC Foundation, proveedores OPC, y Microsoft para la necesidad
de 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 en
plataformas que no sean de Microsoft.
7. Seguridad
Existen tres niveles de seguridad OPC:
• Seguridad Inválida: Libre acceso entre Cliente/Servidor.

• Seguridad DCOM: Clientes seleccionados tienen acceso limitado a servidores OPC. No

hay un control total sobre sistemas operativos como Linux, Unix.
• Seguridad OPC: El Servidor OPC sirve como un regulador de control de acceso a
fabricantes de sistemas operativos como Linux y Unix sobre objetos específicos de acceso
restringido 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 existen

objetos que se mueven e interaccionan con otros. La simulación de la física es una disciplina muy
amplia, este trabajo se centra principalmente en la física de objetos rígidos. Debido a que se
trabajará en un entorno en 3D se tendrán vectores con tres componentes que permitirán manejar
lo 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 de
movimiento de Newton, que describen el comportamiento de una masa puntual. La primera ley
de Newton expresa que un objeto con velocidad uniforme, sobre el cual no existen fuerzas, no
cambiará su velocidad. Aunque en el mundo real siempre existe algún tipo de fuerza que sufren
los objetos en movimiento, como la producida por rozamiento. La segunda ley de Newton es la
que relaciona la fuerza con aceleración.
   
px vx
p =  py  v =  vy  (1)
pz vz
F = ma = mp̈ (2)
1
p̈ = F (3)
m
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, se
simulará la fuerza de gravedad de la tierra, por lo que se aplicará (5). Donde se aproximará la
constante g con un valor de 9,8 sm2 ,10,0 sm2 , para realizar cálculos rápidos [7].
m1 m2
F =G (4)
r2
F = mg (5)
La aceleración de la gravedad que se aplicará a los objetos será por tanto, un vector.
   
0 Fx
g =  −g  F =  Fy  (6)
0 Fz
Los objetos podrán estar tanto en reposo como en movimiento. En movimiento cualquier objeto
sufre rozamiento. La fuerza de rozamiento viene dada por la ecuación (7), donde Fr es la fuerza
de rozamiento, N la normal y µ el coeficiente de rozamiento. Aunque se deben tener en cuenta los
dos tipos de coeficientes de rozamiento, el estático y el dinámico µs y µk . Estos coeficientes son
característicos para cada par de materiales que se encuentran en conctacto y dependen de otros
factores 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.57
Aluminium Steel 0.61 0.47
Copper Steel 0.53 0.36
Rubber Concrete 1 0.8
Wood Wood 0.25-0.5 0.2
Glass Glass 0.94 0.4
Waxed wood Wet snow 0.14 0.1
Waxed wood Dry snow - 0.04
Metal Metal 0.15 0.06
Ice Ice 0.1 0.03
Teflon Teflon 0.04 0.04
Synovial Joints
- 0.01 0.003
in Humans
Table 1: Valores aproximados de los coeficientes de rozamiento dinámico µk y estático µs . Pares

de materiales en contacto.
Otro aspecto importante a tener en cuenta para la simulación de objetos rígidos será el momento
de 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 e
Izy .
ˆ
I= ρr2 dV (8)
V
Para procesar todas las fuerzas que están actuando sobre un mismo objeto en el simulador se
utilizará 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 a
partir del conjunto de fuerzas [4]. Se hará la suma vectorial de fuerzas a las que está sometido
un objeto para obtener una única fuerza total, ver (9). Otras características como el centro de
masas, orientación (ángulos de Euler), momentos de inercia y de fuerza o par deberán aplicarse
para conseguir realismo en la simulación.
X
F = Fi (9)
i
Para el desarrollo de la aplicación se ha utilizado un motor físico de propósito general. Se

buscaba un motor que fuera gratuito y de código libre que además incluyera las características
má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 la
aplicació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 muy
similares como para hacer una elección y dado que no se disponía de tiempo para realizar un
examen exhaustivo del código para hacer la elección del idóneo se escogío JigLibx tras ver algunas
de 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. Como
está completamente escrita en C# es particularmente ajustable a su uso con XNA. El motor físico
posee un sistema de colisiones, física de objetos rígidos y es gratuito y de código abierto. Por lo
que 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 una
colisión entre objetos, cómo ha sido y qué consecuencias conlleva. En base al trabajo del sistema
de 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 un
sistema de simulación en 3D y por tanto objetos modelados en base a polígonos, se debe hacer
distinción entre colisiones punto-punto, arista-arista, arista-cara, cara-cara. Uno de los problemas
al 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 que
ocurrirá es que penetrarán el uno en el otro, ver figura 10. Esto se resolvería separando los objetos
en 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 la
profundidad de penetración definida como la distancia de traslación mínima requerida para separar
dos objetos en intersección [2]. En este método se permite la interpenetración entre objetos y para
realizar la separación se opta por aplicar fuerzas proporcionales a la cantidad de penetración. Al
resolver la colisión se tendrán en cuenta todas las magnitudes de los objetos involucrados, velocidad
lineal, angular, fuerzas etc. Al producirse en una colisión entre dos objetos debe cumplirse el
principio de conservación en el momento del choque y que viene expresado por (10). Dos objetos a
velocidades de choque va y vb , con masas ma y mb , tras el choque adquirirán una nueva velocidad
en otras direcciones y sentidos. La conservación ocurrirá en el momento justo del choque, tras el
cual el movimiento de los objetos deberá responder al resto de fuerzas externas como la fuerza de
rozamiento.
ma va + mb vb = ma va0 + mb vb0 (10)
El sistema de colisiones deberá comprobar si existen colisiones entre cada par de objetos del
simulador. Comprobar una colisión supone conocer la geometría de cada objeto y obtener todos
los puntos de colisión existentes entre dos objetos. Si existen muchos objetos, esta comprobación
puede consumir demasiado tiempo de procesado y ralentizar la simulación. Una solución a este
problema es utilizar dos tipos de detectores de colisiones. El primero de ellos haría una localización
de los objetos con posibilidad de contacto sin entrar en detalles. El segundo recibiría la lista de
objetos y realizaría un chequeo más exacto hallando las colisiones y la información necesaria para
que sean tratadas por el motor físico. De las posibles colisiones también se eliminarían aquellas
colisiones que se producen entre un par de objetos que no poseen velocidad alguna y se encuentran
en reposo. Es decir, sólo se tendrán en cuentan las posibles colisiones entre objetos reposo-activo
y activo-activo [5].
En general se debe introducir en el sistema un conjunto básico de figuras geométricas ya que

los cuerpo físicos tendrán una forma que será una figura geométrica o en casos más complejos una
combinación. En la figura 11 se pueden observar ambos casos. Entre las formas básicas destacan
el 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, no

deformables. El uso de este tipo de objetos, no realistas, presenta algunas desventajas. En primer
lugar en la simulación de un choque entre dos objetos nuncan se dará una amortiguación por
deformación. Aún así la elasticidad se puede incluir en el modelo mediante un coeficiente junto
con los coeficientes de rozamiento, como se ha comentado anteriormente. En segundo lugar el uso
de 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 con
consideraciones de elasticidad del material consumiría demasiado tiempo de procesador y daría
lugar 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 de
detener 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 del
contenido 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á dividida
en varios métodos, de los cuales algunos se ejecutarán una única vez, y otros en cada paso de
ejecució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 del

programa comentada en el apartado anterior. Al empezar el proyecto se pretendía que fuera
sencillo añadir nuevos elementos a medida que se fuesen desarrollando ahora o en un futuro. Que
sea sencillo no implica que no haya que introducir código nuevo. No obstante la forma de introducir
el 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 una
porción de código donde se observan las variables necesarias para introducir “5” cintas giratorias
en 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 va
a necesitar, ver figura 16. En el método Initialize se inicializarán los parámetros necesarios básicos
y 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 y
Draw. En el método Update, se llamará mediante un bucle “for” al método Update de cada una de
las Cintas transportadoras que existan en el escenario. De la misma manera, en el método Draw
se llamará al método Draw de cada una de las cintas mediante un bucle “for”. De esta forma si se
pretende añadir una nueva cinta, solo hay que aumentar el valor “num_Cintas2 ”, y copiar/pegar
la 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 nueva
cinta 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ón
de 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 planta
piloto en pruebas del simulador 3D. Cada una de ellas se encapsula en una clase con unos métodos
obligatorios y otros opcionales como se ha descrito anteriormente. Ésto hará que el desarrollo de
nuevos elementos y su adición al programa principal sea más rápido, sencillo y seguro ante fallos
de compilación y ejecución.
Cuando se habla de métodos opcionales, se está haciendo referencia a un método extra que es
necesario ejecutar una vez que el motor físico ha realizado su pasada, cosa que ocurre al final del
método Update del programa principal en “Simulador.cs”. Este método extra puede ser necesario
para truncar o mejorar el rendimiento del motor físico. Debido a que vamos a simular elementos
mecánicos basados en objetos diferentes que interacturan entre sí pero que no están gobernados
por ninguna mécanica entre ellos más que la física clásica, la reorientación, ajuste de velocidades
y/o detección extra de colisiones pueden llegar a ser necesarios tras el paso de los objetos por el
motor físico. Así pues se deja esta opción en caso de ser necesitada, y se ejecutaría siempre al final
del 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 y
Cinta2, 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 es

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

Una vez que se había estudiado el motor físico y su comportamiento ya era posible comenzar
con el desarrollo de un dispositivo industrial muy común en las plantas industriales, la cinta
transportadora. Aunque las cintas trasnportadoras las hay de muchos tipos y tamaños, la que se
ha 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ón
para diseñar los dispositivos es basarlo en las figuras geométricas más básicas, cubo, esfera y
cilindro. 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 funcionamiento

para que la implementación sea lo más sencilla y rápida posible. Es por eso que se ha tomado
la cinta transportadora como “algo que mueve objetos de un punto a otro”. En este punto no
importa que exista un motor que proporciona la fuerza necesaria para que unos engranajes hagan
girar 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 la
cinta. Un material que mueve objetos que están sobre él. Es por eso que en una primera versión
de la cinta en pruebas se tomarán objetos cúbicos que descansaban sobre una superficie fija y
estática. A estos objetos cúbicos, uno junto a otro, se les dotaba de una velocidad lineal que
se actualizaba en cada paso. Estos objetos son dinámicos, es decir, incluidos en el motor físico
y sobre los cuales actuan fuerzas y velocidades pero que también producen fuerzas sobre otros
objetos. No obstante en cada paso de ejecución se eliminaba la posibilidad de fuerzas ejercidas
sobre ellos por otras causas para que el funcionamiento fuera correcto, pues aunque es cierto que
los objetos que transportarán ejercerán fuerzas sobre ellos y por lo tanto un desgaste natural y
otras perturbaciones o errores de maquinaria, ésto se puede hacer de forma ajena al motor físico
sin necesidad de incluirlo. Lo importante es obtener un comportamiento lógico y realista de lo
que sería un objeto siendo transportado por la cinta. En la figura 21 se pueden ver capturas del
primer prototipo de cinta que se está comentando. En esta primera versión se observa un modelo
muy tosco, sin texturizar ni optimizar pero que cumplía su objetivo. Mover un objeto cúbico de
un 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 incluir
los objetos físicos cúbicos necesarios para tener una cinta transportadora completa. La dinámica
de la cinta es lineal. Una vez activada va de 0 a 0.5m/s de forma lineal. Todavía no se han incluido
las opciones de funciones de transferencia personalizadas pues será en el editor de plantas donde se
configurarán estas opciones. En la figura 22 se puede observar el primer prototipo, parcialmente
texturizado, del primer prototipo de cinta transportadora. Aunque sigue siendo algo tosco, ya se
han 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úbicos
fí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 de
un punto a otro, funcionaba correctamente, el consumo computacional y gráfico era algo elevado
incluso estando parcialmente texturizado. Se fueron reduciendo el número de objetos que formaban
la cinta y aumentando su tamaño para seguir cubriendo toda la longitud de la cinta. También se
eliminaron objetos 3D que realmente eran innecesarios para mejorar el rendimiento gráfico, llegando
a una solución más optimizada que la versión anterior y con un funcionamiento prácticamente
idéntico.
En la figura 23 se puede observar como se ha mejorado el apartado gráfico incluyendo algunos

elementos decorativos como el cuadro eléctrico. Como se ha comentado anteriormentee, la cinta
constará 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 cinta
transportadora.

Obviando el modelo 3D pues no tiene efecto físico en la simulación, se va a explicar como se ha

programado el funcionamiento de la cinta. El modelo físico completo de la cinta está compuesto
por 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 cada
paso 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, dentro
de la clase, forzando a su movimiento.
3. El objeto dinámico se moverá una distancia determinada. Al recorrer esta distancia, el objeto
volverá a su posicion inicial, mediante un forzado de la variable de posición pero manteniendo
la misma velocidad.
4. Esto provocará que el efecto sea el de una cinta. El objeto moverá cualquier otro objeto que
tenga en su superficie una determinada distancia, volverá a la posición inicial, pero si ese
objeto sigue sobre su superficie, aunque en otra zona distinta ahora, seguirá desplazandolo
igual.
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 se
presentará 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 Cinta

transportadora. Está basada 2 únicos objetos físicos que se muestran en la figura 25. El objeto
rectangular es estático y soporta al objeto dinámico que será el que simule realmente la mesa
giratoria. Este objeto deberá ser capaz de moverse de 0 a 90º, y linealmente en los dos sentidos
para darle a la mesa mayor funcionalidad.
La clase detectará si se ha pulsado el actuador correspondiente y pondrá en marcha la función

correspondiente. Sea cual sea la función escogida, el procedimiento es el mismo. Al objeto dinámico
se le asignará una velocidad, en x, z o en ambos en caso de movimiento circular, mediante las
variables que tendrá en cuenta el motor físico para hacer la simulación de colisiones y aplicar las
ecuaciones físicas:

Figura 25: Código en C# que describe el movimiento de la cinta giratoria mediante las variables
de velocidad.
El movimiento lineal, aparte de lo ya comentado, sigue la misma rutina que en el caso de la

cinta transportadora. Avanzará una pequeña cantida de espacio y se reposicionará el objeto cuando
alcance ese espacio en su posición original sin cambiar el vector de velocidad para no alterar la
fí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 que
los rodillos del modelo en 3D que se observa en la Figura 26, deberán actualizar su posición en
el espacio y ángulo dependiendo de la velocidad angular y lineal del objeto dinámico para lo cual
habrá 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 en
funció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 del
reposicionamiento y reorientación del elemento dinámico para evitar errores en la simulación de la
mesa. Ésto es debido a que en realidad el objeto dinámico no está unido a ningún otro elemento
como 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 sobre
la mesa, lineal/angular, e inevitablemente el motor físico lo tendrá en cuenta y se producirán
movimientos no deseados en los ejes x, z. Estos errores deben ser corregidos al comienzo del
método Update. Existe la posibilidad de realizar esto último mediante el método opcional del que
se 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á tras
el 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 en
las 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 la
grúa y por los cuales se mueve, formada por varios cuerpos físicos estáticos. La estructura principal
nunca se moverá, será estática durante toda la simulación, no adquirirá velocidad, aceleración o
fuerza 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 principio
inamovibles pero que cambiarán al imprimirle movimiento. Estos dos cuerpos forman un único
objeto en el simulador. Se puede mover linealmente en dos sentidos y subir/bajar. El brazo debe
poder interactuar con el resto de objetos del simulador sin que éstos tengan efectos sobre su posición
y velocidad pero si al contrario. Para ello se dota al brazo de una masa elevada, de esta forma si
un objeto choca con el brazo no repercutirá en su estado. El último de los elementos es la garra
que 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 del
movimiento necesario entre garra y objeto. En el momento en que exista una colisión en ambas
partes de la garra, se comprueba que el objeto definitivamente se encuentra en una posición en la
que es posible sujetarlo físicamente. Si éste es el caso, se procede a declarar al objeto inamovible
y 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 objeto
seguirá a la grúa en el recorrido que haga sin moverse de su posición relativa a la grúa. Una vez
que 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 hace
es un barrido por cada una de las cajas. Se comprueban las “ID’s” de colisión y si existe una
colisió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ún
el avance de la garra tal y como sucedería en la realidad. En el momento de la colisión doble, si
la orientación de la caja es cercana a la orientación de la garra, el objeto se podrá agarrar. En
otro caso, supongamos que la caja estuviera a 45º, las garras al cerrarse expulsarán el objeto por
rozamiento.

Figura 35: Código C# que se encarga del funcionamiento de la garra mediante detección de
colisiones 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 las
salidas, en este caso los destructores, que serían paso a otras zonas de la planta. Están formadas
por varios objetos y poseen unos coeficientes de rozamiento adecuados para simular una superficie
metálica pulida que permitirá a las cajas deslizarse facilmente por su superficie. En la figura 36 se
presenta 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 se
puede ver lo más relevante de la clase “Rampa.cs”. Se observa que tan solo es una declaración de
objetos y su posicionamiento en el escenario mediante las variables correspondientes a cada cuerpo
o “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 un
elemento que sea capaz de “destruirlas”. Es decir, si una caja ya no es necesaria en el escenario, si
que será necesario liberar o destruir dicha caja para liberar recursos de la ejecución. En las figuras
38 y 39 se pueden observar tanto el modelo 3D como el modelo físico que detecta las colisiones
mediante 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 el
mismo. En ese caso se comprobará la ID del objeto en colisión y se liberarán los recursos de dicho
objeto. El código que gobierna las colisiones es similar al caso de la garra en la grúa y se muestra
en la figura 40.
Figura 40: Código en C# para chequear las colisiones del objeto físico del Destructor con otros
objetos 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 escenario

en 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 en

imagenes en la figura 41.
La estructura programada es simple. Varios objetos físicos estáticos y un único bloque

dinámico/estático. Cuando se dice dinámico/estático es debido a que el bloque no es realmente
dinámico, sino estático pero al moverse se comporta como dinámico cuando se ejecuta el sistema de
colisiones. 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 el
pistó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ón
mediante las variable correspondiente. Tras la actualización de posiciones del elemento, se hace
pasar por el motor físico y sistema de colisiones. El truco que se ha utilizado para que se comporte
dinámicamente siendo estático y que no se caiga el objeto físico cúbico por gravedad tiene que ver
con el propio sistema de colisiones.
En el apartado 3.1 se explicó que el sistema de colisiones se basaba en profundidad de

penetración y un movimiento proporcional a la penetración. El objeto es estático, luego en realidad
no importa que se le apliquen velocidades, aceleraciones y/o fuerzas, pues el motor físico lo detecta
como estático y no aplicará fuerzas, velocidades ni aceleraciones sobre él. La velocidad que se le
aplica 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 de
ejecución y se calcula aproximadamente la cantidad de espacio que debe recorrer en cada uno de
los pasos. Es decir que entre un paso y otro se fuerza la posición del objeto. Si existe otro objeto
dinámico, como una caja, cercano al pistón y se fuerza la posición del pistón , éste penetrará en
la caja. Esta situación será detectada por el sistema de colisiones que se encargará de hacer los
movimientos correspondientes al objeto dinámico, en este caso la caja. De esta forma se consigue
el 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 incorporados

reutilizando el código del pistón. En las figuras 44 y 45 se muestran los modelos del piston de
doble 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 faltar
es el sensor de barrera. Aunque son sensores muy simples, son muy utilizados y darán mucho juego
en el simulador para practicar con PLC’s.
La implementación final del sensor de barrera con la que se obtuvieron los mejores resultados
fue mediante el uso de un segmento de colisión. Este segmento, de longitud igual a la separación
entre los elementos que forman el sensor será el implicado en la detección de los objetos. En cada
iteración de la aplicación se comprueba si este segmento ha intersectado con alguno de los objetos
físicos del escenario. En el caso de obtener una intersección, el sensor se activa cambiando a true
el 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ón
de ID’s.
En la figuras 46 y 47 se muestran capturas de pantalla del modelado 3D y funcionamiento del

sensor para objetos con diferentes posiciones. La porción de código relacionada con la detección
se muestra en la figura 48.
Dado que en el simulador desarrollado en este proyecto los únicos objetos dinámicos que existen
son las cajas, al detectarse una colisión se comprobará a que caja corresponde la “ID” del objeto
que 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 en
la figura 48.
3.4.8 MONTACARGAS
Este elemento no se ha terminado de desarrollar completamente, aunque está practicamente

finalizado. Se ha programado con un objeto físico cúbico que será el responsable de la subida
y bajada de elementos. El modelado 3D y físico se muestran en las figuras 49, 50 y 51. Recordando
que no existen uniones mecánicas que mantengan los elementos unidos unos a otros, hay que tener
en cuenta que el objeto que debe subir y bajar carga estará inevitablemente bajo la fuerza de la
gravedad 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 tiene
porque 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 en
cada una de las iteraciones. Al ejecutarse el método Update del montacargas, se anulan las posibles
fuerzas, aceleraciones y velocidades, que se han grabado en sus variables internas, productos del
paso por el motor físico y sistema de colisiones. Asimismo se reorienta el elemento y se le vuelve
a asignar la velocidad que debería tener. De esta manera se mantiene el realismo de la acción de
subida y bajada de la carga. En la figura 52 se muestra la parte del código relacionada con la
activació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 las
distintas 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 desarrollar

completamente, aunque está practicamente finalizado. Lo único que falta por terminar de
programar es el mecanismo de agarre, aunque ya se ha planteado usar el mismo método que
en el caso de la grúa, al fin y al cabo en este caso la garra no deja de ser una pinza al igual que
en la grúa. En la figura 53 se muestran capturas del brazo en 3D en diferentes posturas, y en la
figura 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úbico
fí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 forma
teórica, donde los ejes están en las articulaciones, en los extremos de los elementos. El problema es
que en el motor físico, los ejes de los elementos están en el centro por lo que habría que trasladar
este punto hacia los extremos. En vez de realizar la conversión se decide programar la posición de
cada 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 de

cada 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 aplicar
una masa elevada a cada una de las partes del brazo es porque se va a utilizar el mismo método
que en el caso del pistón. Debido a que los movimientos de cada una de las partes tendrán varias
componentes, se hace dificil el control de la posición sin que ocurran efectos parásitos debido a
la falta de unión mecánica fija, a la fuerza de la gravedad y resto de elementos del escenario. El
movimiento del brazo está totalmente basado en movimiento articular. Mediante cambios en las
variables 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 y

consecuentemente su parte correspondiente, hasta llegar a la garra. Se realizan los cálculos, según
el 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 poder
posicionarla en ese punto. En las figuras 57, 58, 59 y 60 se muestra el código de los cálculos que
se 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 ninguna
dinámica por el momento, al igual que con el resto de elementos. En cada iteración la cantidad
de 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 del
bloque físico.
Una vez calculada la posición, simplemente se sitúa el elemento en dicha posición y se recalculan
las posiciones de los elementos superiores en función de la variable inferior. En caso de estar
activado algún otro actuador superior se realizaría la misma operación, pero eliminando los cálculos
inferiores.
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 una
conexión no física. Es decir, para realizar la simulación de la planta 3D con un programa escrito
para el PLC, no será necesario el uso de un PLC real. Se utilizará el simulador de PLC que incluye
el software Unity Pro XL de Schneider Electric. Este simulador se conectará de forma local en
el mismo PC con el servidor de OPC de Schneider OFS. La conexión con el OFS se realizará a
través del menú de pestañas que incluye el simulador 3D. El cliente OPC que se ha integrado en la
solución, está escrito en C#. Para ahorrar tiempo en el desarrollo de la aplicación se ha utilizado
un cliente OPC libre de licencias en C#.
Aunque existen diversos clientes OPC escritos en este lenguaje, se descartaron por no
proporcionar el código fuente o ser de pagos y no es el objetivo de este proyecto. En un futuro
se podría utilizar el conjunto de librerías de la OPC Foundation para el desarrollo de clientes
OPC optimizados para el simulador 3D. Durante la conexión del cliente con el servidor OPC, se
muestran el listado de variables que están incluidas en los archivos de la programación realizada
para el PLC con Unity Pro. Actualmente todas las variables que se permiten en el simulador 3D
son boolenas, true/false o 0/1 según se prefiera. Lo comentado no implica que el OFS no admita
variables analógicas. Para éste escenario no se han implementado aunque si se implementarán en
futuras modificaciones de la aplicación.
Para la conexión con el servidor OPC de Schneider, OFS (OPC Factory Server), se utilizará un
cliente OPC escrito en C# que se ha integrado en la solución. El cliente esta basado DA o “Direct
Access” 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 la
conexió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 de

variables. Se ha tenido que modificar parte del código para que la escritura/lectura se realice
desde métodos internos que serán llamados utilizando hilos pseudoparalelos desde el programa
principal. 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 una
variable en concreto dentro del servidor OPC, para la escritura o lectura de una variable. En
este proyecto los actuadores se llamaran Axx y los sensores Sxx y Pxx. El significado y numeración
de éstos aparecen en el manual de usuario.
Existirán hilos de escritura y lectura, así como hilos prioritarios y secundarios, ver figuras 62
y 63. La creación de hilos diferentes se basa en que variables se están leyendo o escribiendo. Se
comprobó tras varias pruebas que la lectura/escritura individual de actuadores y sensores en el
servidor OPC era lenta, en especial en el caso de la escritura en el OPC. La solución escogida
que mejor resultado ofreció fue la lectura en bloque y la escritura individual. La lectura de todo
un conjunto de 20 actuadores lleva un tiempo aproximado de 30-40ms. Mientras que la escritura
individual de 1 único sensor en el OPC puede llevar unos 15ms. El OPC utilizado parece ser
bastante 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 algun
cambio en algún sensor. Entonces se toman todos los sensores que han cambiado de estado y se
escriben uno a uno.
En el simulador existen sensores prioritarios que corresponden a los sensores de barrera. Dado
que estos sensores son críticos pues dependen del paso de objetos dinámicos que cambian de
posición, se deberán escribir inmediatamente en el OPC para que el PLC reciba los datos y actue
la programación de la planta en el PLC en consecuencia. En este caso la escritura del resto de
sensores se detendrá para proceder a escribir los prioritarios, tras lo cual se volverá a escribir por
donde 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 una
interfaz amigable formada por un cuadro de control dividida en pestañas. En cada una de las
pestañas se encuentran diferentes controles, actuadores, sensores y conexión de OPC, ver figura
64. En el cuadro de operación a la derecha se encuentran los controles de activación de modo
manual/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 en

cada paso de ejecución. Las texturas corresponden al cuadro en sí y a los botones. Cada uno de
los botones se posiciona en base a los ejes que forman el formulario general donde está embebido el
simulador. En función de las características de ancho/alto de la ventana de la aplicación la situación
de los botones se mantiene siempre en el mismo sitio, es decir, no importa que se aumente el tamaño
de 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 ha

realizado el click de ratón. Cotejando la posición del click con las posiciones de los botones se
detectará una coincidencia o no, y si es así se cambiará el estado del botón y su imagen. Con
respecto a los sensores solo hay que detectar de forma interna cambios en las variables booleanas
de 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 elementos
del cuadro de control.

a)
b) c)
Figure 64: 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.

Figura 66: Código para posicionar los elementos en el mismo lugar sin importar el tamaño de la
ventana.
Figura 67: Código para la detección de pulsado de botones en la aplicación. En este caso se
comprueban 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 los
dispositivos 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. La

clasificación se realiza por tamaño y para ello se hará uso de un conjunto de sensores de barrera a
diferentes alturas para su clasificado. El objetivo de la Grúa es tomar las cajas medianas y pasarlas
de una cinta transportadora a otra, mientas que las cajas grandes y pequeñas pasarán por la cinta
giratoria que las enviará a sus correspondientes rampas de destino.
El escenario es conceptualmente simple, pero en el que se puede realizar una programación

del PLC suficientemente compleja por los alumnos como para obtener un rendimiento óptimo del
funcionamiento de la planta. En este rendimiento se puede considerar, por ejemplo, número de
cajas procesadas por hora, número de cajas procesadas correctamente, errores producidos, tiempos
de 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 y
las 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 configurable
como sea posible. El desarrollo de todo el proyecto ha sido programado teniendo en cuenta que el
objetivo final es obtener un editor de escenarios.
El propósito del editor es que el usuario pueda diseñar diferentes plantas industriales según
sea necesario. Por lo tanto, el software desarrollado proporcionaría una característica muy
interesante de escalabilidad. El editor también incluirá todos los parámetros y opciones que son
interesantes cuando se realiza la simulación de elementos industriales, tales como el tiempo de uso
de dispositivos, el error, la probabilidad de fallo, el tiempo medio entre reparaciones, etc. Todos
estos parámetros serán configurables por el usuario y permitirá un uso más eficiente y alargará la
vida del software.
El editor está en desarrollo, aunque que ya se ha obtenido los primeros resultados. La figura
72 muestra capturas de pantalla del editor. La programación del editor es relativamente simple ya
que 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 de
Windows 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 muchos

añ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 educativos
como para el desarrollo comercial de aplicaciones para el control, la automatización y procesos de
optimización.
Figure 72: Capturas de pantalla del Editor de Escenarios.

5 MANUAL DE USUARIO
5 MANUAL DE USUARIO
5.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 viene
incluido 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 el
programa 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 de
comunicaciones 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 como
Windows 7 Home Premium se ha realizado una instalación correcta de los programas
comentados anteriormente. Es posible que no se pueda instalar el paquete .NetFramework
1.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 Windows
7(32bits).
5.2 CONFIGURACIÓN DE UNITY PRO
Antes 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 2020

CPU 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 de
la 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 muestran
en la imagen de la figura 3.
4. En el apartado “Symbol Table File” se debe indicar el fichero del programa *.STU que se ha
creado en Unity PRO XL para realizar la automatización de la planta. El archivo *.STU se
crea 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, para
incluirlo 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 de

las cuales actualmente solo se utilizaran 3, Actuadores, Sensores y OPC. En la pestaña OPC
encontramos 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 varios
controles, como Play, Stop, Pause, Reboot, Emergency y el activador de Automatico/Manual. En
esta 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 modo
Manual y se pueden utilizar los actuadores para activar los dispositivos del escenario. En caso
contrario, se encuentra en modo ON, y será cuando esté conectado al servidor OPC, y por tanto
no 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 hacer
girar la camara a voluntad del usuario. También se dispone de una serie de vistas predefinidas a
las 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 siguientes
elementos:

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 cajas
grandes por la rampa que se indica en la figura 5, las cajas pequeñas por la rampa que se indica en
la figura 6, y las medianas deben ser recogidas por la grua y soltadas en la segunda cinta. Haciendo
uso de los sensores dispuestos para la clasificación deberá programarse una serie de actuaciones
sobre los elementos de la tabla teniendo en cuenta los retrasos debido a la comunicación, la cual
es 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 Funcionamiento

A00 Activador Cinta Tranpostadora 1 ON/OFF
A01 Activador Cinta Tranpostadora 2 ON/OFF
A02 Activador Angular Plataforma Giratoria ON/OFF
A03 Activador Lineal 1 Plataforma Giratoria ON/OFF
A04 Activador Lineal 2 Plataforma Giratoria ON/OFF
A05 A06 Ir a posición

OFF OFF 1
OFF ON 2
A05, A06 Activadores Grúa Horizontal
ON ON 3
ON OFF -
Ver Imagen 8
A07 Activador Subir Grúa ON/OFF

A08 Activador Bajar Grúa ON/OFF
A09 Activador Cerrar Garra Grúa ON/OFF
A10 Activador Abrir Garra Grúa ON/OFF
A11 Activador Piston Simple 1 ON/OFF
A12 Activador Piston Simple 2 ON/OFF
A13 Activador Piston Doble Empujar ON/OFF
A14 Activador Piston Doble Subir/Bajar ON/OFF
ON/OFF
(Para soltar más
A15 Activador Añadir Caja al Escenario de una caja hay
que pasar antes
por 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:

S00 Plataforma Giratoria en posición 1 ON/OFF
S01 Plataforma Giratoria en posición 2 ON/OFF
S02 Grúa en posición 3 ON/OFF
S05 Grua en posición Arriba/Abajo ON/OFF
S06 Garra Cerrada/Abierta ON/OFF
S07 Pistón 1 Extendido ON/OFF
S08 Pistón 1 Recogido ON/OFF
S09 Pistón 2 Extendido ON/OFF
S10 Pistón 2 Recogido ON/OFF
S11 Pistón Doble Extendido ON/OFF
S12 Pistón Doble Recogido ON/OFF
S13 Pistón Doble Extendido (Abajo) ON/OFF
S14 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):

P00 Sensor de Barrera 1 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 DE

CONTROL EN UNITY PRO XL
Se recomienda que antes de empezar a programar en Unity Pro, se familiarice con el simulador
3D mediante el uso de los actuadores, para tener en cuenta que pasa por ejemplo al pulsar 2
actuadores que tengan relación directa, como es el caso de Abrir y Cerrar Grúa. Una vez se vean
las 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 “STP
y RUN ”. Todas las variables serán de la clase “BOOL”. Estas son las variables con las que se
comunicarán el PLC y el Simulador. No obstante se pueden utilizar todas las variables auxiliares
que 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 por
paso 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 en
otras variables o estados del PLC inmediatamente.
Los sensores con nomenclatura “SXX ”, permanecen siempre en un estado a lo largo del tiempo
hasta que se activan/desactivan y cambien de estado. No son críticos, como el caso de los
prioritarios. El actuador Automatico/Manual no se programa en el PLC, pues es exclusivo del
simulador.
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ón
correspondiente, cuando se ha estado simulando junto con el servidor y el PLC un periodo de
tiempo largo. En caso de ocurrir, basta con cerrar la aplicación y el Servidor OPC, y volver a
simular.
5.8 CONEXIÓN Y EJECUCIÓN PLC-OPC-SIMULADOR

Una 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 el
PLC. 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 pulsar
sobre el boton que se indica en la imagen a) de la figura 4 y aparecerá un formulario como
se observa en la imagen b). Se escogerá el servidor que se ha instalado “Schneider-Aut OPC
Factory Server”, y posteriormente, el dispositivo que se haya creado con el OFS Configuration
Tool.

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 hayan
aparecido 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 es
obligatorio 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 hayan
necesitado. Es posible que parezca que se ha quedado colgado el OFS. Aunque no se ha
llegado a observar este comportamiento, si tras un par de minutos siguen sin aparecer las
variables, 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 programa
cargado en el simulador de PLC de Unity Pro.
7. Para que el simulador 3D empiece a recibir datos, se debe pasar de manual a automatico
mediante el boton indicado en la figura 12. Se recomienda, a la hora de implementar el
programa en el PLC, utilizar las variables “RUN” y “STP” como entradas en el PLC, para
recibir 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, se
prodecerá como se ha comentado en el apartado anterior. Será necesario realizar pruebas para
comprobar si la solución es correcta. En caso de hacerse una prueba y no obtener el resultado
deseado, la solución deberá ser modificada. Para ello habrá que desconectar primero el simulador
del Servidor OPC mediante el botón adecuado. Se comprueba que en el Servidor OPC el número de
clientes conectados es cero. Tras desconectar simulador 3D y Servidor OPC, pararemos la ejecución
del 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 que
se hayan creado.
5.10 VIDEO DE EJEMPLO DE CONEXION Y FUNCIONAMENTO DE LA
PLANTA
Aunque nunca existe una única forma de programar una planta, en el video “Demo Planta” que
se adjunta, se muestra como debería ser aproximadamente el funcionamiento de la planta. En el
video demostrativo también se incluye la conexión al servidor y la puesta en marcha
del 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 de

maquinaria industrial en 3D, integrando en el mismo un sistema físico para poder observar el
resultado 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 de
dinámica de colisiones es el responsable de simular la interacción entre los diferentes objetos de
un escenario. Se han elaborado los elementos fundamentales para el desarrollo de una plataforma
didáctica interactiva, sobre software libre. Actualmente solo se dispone de los elementos descritos
en este proyecto y de una planta simulada. Es por lo que se plantea la posible continuación de
este trabajo para desarrollar nuevos elementos y terminar los dos dispositivos que se encuentran
inacabados, 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 aprendizaje
de 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 en
Sevilla 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 profesionales
de 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 de
Automática (Ja 2011). XXXII Jornadas de Automática (Ja 2011). Sevilla. Universidad de
Sevilla. 2011.
• del Pozo, A.S.; Escano, J.M.; Bordons, C. “Simulator for control and automation using
an interactive and configurable 3D virtual environment”. Proceedings of SICE Annual
Conference 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 Fluid
Mechanics, 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 Depth
Computation 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 Automatizacion Utilizando Un Entorno Virtual 3D Interactivo y Configurab PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Simulador para Control y Automatizacion Utilizando Un Entorno Virtual 3D Interactivo y Configurab PDF

Cargado por

Copyright:

Formatos disponibles

SIMULADOR PARA CONTROL Y

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

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

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

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

3 DISEÑO E IMPLEMENTACION DEL SIMULADOR 24

4 ESCENARIO PROTOTIPO Y EDITOR DE ESCENARIOS 67

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

Simulador para control y automatización. 7 de 86

Figura 2: Imagenes de varios escenarios de ITS PLC. a) Almacen automatizado. b) Mezclado de

1.2 ESTADO DEL ARTE

Existen actualmente propuestas comerciales que, en un entorno interactivo en 3D, incluyen un

Éste software dispone de 5 escenarios. Algunas imágenes se muestran en la figura 2. Éstos

Simulador para control y automatización. 8 de 86

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

• Fallo. El dispositivo deja de funcionar completamente.

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

Simulador para control y automatización. 9 de 86

A diferencia de otros, el software desarrollado es Open Source (Código Libre), pues se ha

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

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

Simulador para control y automatización. 10 de 86

1.4 ESTRUCTURA DEL DOCUMENTO

2. Una parte de diseño de la plataforma.

Simulador para control y automatización. 11 de 86

2.1 SITUACION DE PARTIDA

Aproximadamente al comienzo del quinto mes ya se disponía de un escenario funcional que

El quinto més y el sexto se dedicaron a optimizar la programación de los elementos desarrollados

2.2 DESCRIPCION DE LA APLICACIÓN OBJETIVO

Simulador para control y automatización. 12 de 86

Siguiendo este planteamiento se comienza determinando que debe ofrecer la aplicación al

Una opción muy interesante es la de incluir programación en el simulador. Esta programación

2.2.1 Conexión mediante Server OPC

Simulador para control y automatización. 13 de 86

2.2.2 Conexión mediante puerto USB

2.3 TECNOLOGIAS Y HERRAMIENTAS DE DESARROLLO

2.3.1 INTRODUCCIÓN A C# Y XNA

Inicialmente y dado que no se sabía programar en JAVA, se descartó inicialmente dejándolo

• Wolfenstein: Enemy Territory.

Simulador para control y automatización. 14 de 86

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

C# es un lenguaje de programación orientado a objetos desarrollado y estandarizado por

Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma .NET,

Algunas características de C# son:

Simulador para control y automatización. 15 de 86

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ósito

Microsoft XNA es un conjunto de herramientas con un entorno de ejecución administrado

XNA actualmente abarca secciones de Microsoft Game Development Sections, incluyendo el

Simulador para control y automatización. 16 de 86

Incluye un amplio conjunto de bibliotecas de clases, específicas para el desarrollo de juegos,

Las versiones que ha lanzado Microsoft son las siguientes:

• XNA Game Studio 2.0

Permite la producción de juegos de la plataforma de Zune y agrega soporte de la

• XNA Game Studio 3.1

Se anunció en la Game Developers Conference en San Francisco el 24 de marzo de 2009.

Simulador para control y automatización. 17 de 86

• XNA Game Studio 4.0

2.3.2 ENTORNOS DE MODELADO 3D. INTRODUCCION A AC3D.

Entre los más utilizados están: