Ingeniero en Informática Ingeniero en

Transcripción

Ingeniero en Informática
Ingeniero en Organización Industrial
Informatikako Ingeniaria
Industri Antolaketako Ingeniaria
Proyecto fin de carrera
Karrera amaierako proiektua
Diseño e implementación de la plataforma
Boole-WebLab-Deusto para el prototipado
rápido de sistemas digitales mediante el uso de
laboratorios remotos y realidad aumentada
Luis Rodríguez Gil
Director: Javier García Zubía
Bilbao, mayo de 2013
Resumen
El proyecto Boole-WebLab-Deusto tiene como propósito mejorar el aprendizaje usando
laboratorios remotos y otros recursos TIC en el área de la electrónica digital y las FPGA.
El proyecto, con un marcado carácter investigador en el área de Technology Enhanced
Learning, tiene dos grandes objetivos:
El primero es integrar el software educativo de diseño electrónico Boole-Deusto con la
infraestructura de laboratorios remotos WebLab-Deusto, de tal modo que sea posible -en
minutos- diseñar un sistema digital e inmediatamente probarlo remotamente en un sistema físico real. Boole-Weblab-Deusto es capaz de gestionar todo el proceso de diseño,
especificación y pruebas reales. El usuario evita instalar software especializado, evita tener que configurarlo, evita tener que disponer de un sistema de prototipos y evita tener
que gestionar el proceso de grabación. Todo este proceso es transparente tanto para el
profesor como para el alumno.
El segundo, donde radica gran parte de la naturaleza innovadora del proyecto, es dotar a
WebLab-Deusto de una infraestructura de realidad aumentada, que superponga modelos
virtuales sobre experimentos electrónicos con dispositivos hardware reales. Utilizando
visión artificial para interpretar las salidas, los modelos virtuales interactuarán en ambos
sentidos con el hardware. Esta capacidad permite la creación de experimentos prácticos
(con modelos virtuales de sistemas reales), económico (una sola placa controladora física
permite muchos experimentos distintos) y al mismo tiempo realistas (el foco sigue siendo
un dispositivo físico absolutamente real).
El sistema en este momento es ya totalmente funcional y se han publicado varios artículos
relacionados en revistas y conferencias científicas.
Descriptores
experimentación remota, technology enhanced learning, electrónica digital, realidad aumentada, laboratorio remoto
iii
Índice general
1 Introducción
1
1.1 Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Contexto
2.1 Introducción . . . . . . . . . . . . . .
2.2 Tecnologías y estado del arte . . . . .
2.2.1 Technology Enhanced Learning
2.2.2 Laboratorios remotos . . . . .
2.2.3 Realidad aumentada . . . . . .
2.2.4 Visión artificial. . . . . . . . .
2.3 Software y entornos de partida. . . . .
2.3.1 Boole-Deusto . . . . . . . . .
2.3.2 Weblab-Deusto. . . . . . . . .
2.4 Publicaciones . . . . . . . . . . . . .
2
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Objetivos del proyecto
3.1 Descripción del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Integración Boole-Weblab-Deusto . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Modelos virtuales en experimentos electrónicos reales . . . . . . . . . . . . .
3.2 Visión general del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Diseño y generación de código (Boole-Deusto) . . . . . . . . . . . . . . . . .
3.2.2 Sintetización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Modelización Virtual y Realidad Mixta . . . . . . . . . . . . . . . . . . . . .
3.3 Productos finales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Principales requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Principales requisitos no funcionales. . . . . . . . . . . . . . . . . . . . . . .
3.5 Método de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Fase 1: Diseño preliminar del sistema . . . . . . . . . . . . . . . . . . . . . .
3.6.2 Fase 2: Mejoras y ampliaciones de Boole-Deusto . . . . . . . . . . . . . . . .
3.6.3 Fase 3: Implementación de conectividad Boole-Deusto – Weblab-Deusto . . . .
3.6.4 Fase 4: Implementación de experimentos electrónicos mediante realidad aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.5 Fase 5: Pruebas, usabilidad e integración . . . . . . . . . . . . . . . . . . . .
3.6.6 Fase 6: Implantación en producción . . . . . . . . . . . . . . . . . . . . . . .
5
5
5
6
10
12
12
13
13
14
19
19
19
21
23
25
26
27
28
29
29
31
31
32
32
32
33
34
35
36
v
3.7 Tareas principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 Estimación de tiempos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Programación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Tecnologías
45
4.1 Boole-Deusto . . . . . . . . . . . . . . . . . . . .
4.1.1 Introducción . . . . . . . . . . . . . . . . .
4.1.2 Características . . . . . . . . . . . . . . . .
4.1.3 Sistemas combinacionales . . . . . . . . . .
4.1.4 Sistemas secuenciales (autómatas) . . . . . .
4.1.5 Caracteristicas técnicas . . . . . . . . . . .
4.2 Weblab-Deusto . . . . . . . . . . . . . . . . . . .
4.2.1 Introducción . . . . . . . . . . . . . . . . .
4.2.2 Características generales . . . . . . . . . . .
4.2.3 Facilidades aportadas . . . . . . . . . . . .
4.2.4 Características técnicas hardware . . . . . .
4.2.5 Características técnicas software . . . . . . .
4.3 Tecnologías hardware . . . . . . . . . . . . . . . .
4.3.1 VHDL . . . . . . . . . . . . . . . . . . . .
4.3.2 BITSTREAM . . . . . . . . . . . . . . . .
4.3.3 UCF . . . . . . . . . . . . . . . . . . . . .
4.3.4 Xilinx ISE . . . . . . . . . . . . . . . . . .
4.3.5 FPGA . . . . . . . . . . . . . . . . . . . .
4.4 Tecnologías software . . . . . . . . . . . . . . . .
4.4.1 Borland C++ Builder. . . . . . . . . . . . .
4.4.2 VCL . . . . . . . . . . . . . . . . . . . . .
4.4.3 Python . . . . . . . . . . . . . . . . . . . .
4.4.4 JavaScript . . . . . . . . . . . . . . . . . .
4.4.5 GWT (Google Web Toolkit) . . . . . . . . .
4.4.6 AJAX (Asynchronous JavaScript and XML)
4.4.7 jQuery . . . . . . . . . . . . . . . . . . . .
4.4.8 HTML5 Canvas . . . . . . . . . . . . . . .
4.4.9 WebGL. . . . . . . . . . . . . . . . . . . .
4.4.10 ThreeJS . . . . . . . . . . . . . . . . . . .
4.4.11 Node.js . . . . . . . . . . . . . . . . . . . .
4.4.12 Sphinx . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Desarrollo
5.1 Entorno de desarrollo . . . . . . . .
5.1.1 Eclipse for Java . . . . . . .
5.1.2 PyDev . . . . . . . . . . . .
5.1.3 Microsoft Visual Studio 2012
5.1.4 Notepad++ . . . . . . . . . .
5.1.5 Vim . . . . . . . . . . . . .
5.1.6 Git y TortoiseGit . . . . . . .
vi
36
41
43
45
45
46
47
51
52
53
53
54
55
57
59
59
59
59
60
60
60
61
61
61
62
62
63
65
65
66
67
68
68
69
71
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
71
71
72
73
74
74
5.1.7 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.8 Blender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Detalles del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Boole-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 WebLab-Deusto: Sintetización de VHDL . . . . . . . . . . . . . . . . . . . .
5.2.3 WebLab-Deusto: Infraestructura de creación de servidores de experimentos en
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 WebLab-Deusto: Infraestructura de creación de clientes de experimentos en JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5 WebLab-Deusto: Infraestructura de modelos virtuales en JavaScript y ThreeJS .
5.2.6 WebLab-Deusto: Modelo virtual de tanque de agua para WebLab-Deusto-FPGA
5.2.7 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Problemas e incidencias
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Manuales
8 Conclusiones y trabajo futuro
83
84
88
91
92
95
6.1 Antigüedad del entorno de desarrollo original de Boole-Deusto .
6.1.1 Necesidad de un entorno virtual . . . . . . . . . . . . .
6.1.2 Capacidades del entorno . . . . . . . . . . . . . . . . .
6.1.3 Interfaz anticuada . . . . . . . . . . . . . . . . . . . .
6.2 Soporte de WebGL. . . . . . . . . . . . . . . . . . . . . . . .
7.1 Guía de usuario de Boole-Weblab-Deusto . . . . . . . . . . .
7.1.1 Introducción . . . . . . . . . . . . . . . . . . . . . .
7.1.2 Circuitos Combinacionales. . . . . . . . . . . . . . .
7.1.3 Creando y probando un sistema combinacional . . . .
7.1.4 Autómatas . . . . . . . . . . . . . . . . . . . . . . .
7.2 Guía del experimento FPGA Watertank . . . . . . . . . . . .
7.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . .
7.2.2 Funcionamiento de un modelo virtual . . . . . . . . .
7.2.3 Tanque de agua . . . . . . . . . . . . . . . . . . . .
7.2.4 Otros detalles . . . . . . . . . . . . . . . . . . . . .
7.2.5 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Guía de desarrollo de Boole-Deusto . . . . . . . . . . . . . .
7.3.1 Entorno de programación . . . . . . . . . . . . . . .
7.3.2 Sistema de lenguajes . . . . . . . . . . . . . . . . . .
7.4 Guía de desarrollo de clientes de experimentos en JavaScript .
7.4.1 Qué desarrollar. . . . . . . . . . . . . . . . . . . . .
7.4.2 API JavaScript . . . . . . . . . . . . . . . . . . . . .
75
76
77
77
81
95
95
96
96
96
99
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
99
102
108
111
111
112
113
114
114
116
116
117
119
119
120
125
8.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.2 Comparación con objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.3 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
vii
9 Posible plan de negocio
9.1 Resumen ejecutivo. . . . . . . . . .
9.2 Descripción general de la compañía .
9.2.1 Misión . . . . . . . . . . . .
9.2.2 Visión . . . . . . . . . . . .
9.2.3 Metas y objetivos . . . . . .
9.3 Filosofía del negocio. . . . . . . . .
9.4 Productos y servicios . . . . . . . .
9.5 Plan de marketing . . . . . . . . . .
9.5.1 Mercado . . . . . . . . . . .
9.5.2 Producto . . . . . . . . . . .
9.5.3 Clientes . . . . . . . . . . .
9.5.4 Nicho . . . . . . . . . . . .
9.5.5 Estrategia . . . . . . . . . .
9.6 Plan operativo . . . . . . . . . . . .
9.6.1 Producción . . . . . . . . . .
9.6.2 Ubicación . . . . . . . . . .
9.6.3 Personal . . . . . . . . . . .
9.6.4 Inventario . . . . . . . . . .
9.6.5 Proveedores . . . . . . . . .
9.6.6 Política de créditos . . . . . .
Bibliografía
131
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
131
132
132
132
132
134
135
137
137
138
139
141
142
143
143
143
144
144
144
145
147
A Acrónimos
151
B Glosario
153
C Agradecimientos
157
D Publicaciones
159
D.1 Publicaciones incluidas en los anexos . . . . . . . . . . . . . . . . . . . . . . . . . . 159
D.2 Publicaciones no incluidas en los anexos . . . . . . . . . . . . . . . . . . . . . . . . 160
viii
Índice de figuras
1.1
Experimento FPGA real controlando un tanque de agua virtual. . . .
2
2.1
2.2
2.3
2.4
2.5
Laboratorio remoto de propósito específico [31] . . . . . . . . . . . . .
Sistema de gestión de laboratorios remotos (RLMS) [31] . . . . . . . .
Realidad aumentada. Muebles virtuales en una habitación real. [43].
Google Glasses: Gafas para la realidad aumentada . . . . . . . . . . .
Realidad mixta: Personas reales y virtuales juntas, en un entorno real.
[12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Coche sin conductor de Google. Parcialmente basado en visión artificial. [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Una de las pantallas principales de Boole-Deusto (diseño de sistemas
combinacionales) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Experimento FPGA estándar, en WebLab-Deusto, ejecutando una lógica ya grabada provista por un usuario. . . . . . . . . . . . . . . . . .
7
8
10
11
20
21
22
24
3.7
3.8
3.9
3.10
Flujo de trabajo Boole-WebLab-Deusto . . . . . . . . . . . . . . . . . .
Placa FPGA con 4 de los 8 LEDs que actúan como salida, encendidos .
Visión general del sistema de modelos virtuales (realidad mixta) . . .
Elementos principales del sistema desde el punto de vista del usuario
Diagrama conceptual básico del proceso de sintetización en los servidores de WebLab-Deusto . . . . . . . . . . . . . . . . . . . . . . . . .
Tanque de agua virtual: Ejemplo de un posible modelo (sólo el modelo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fases planificadas para el proyecto. . . . . . . . . . . . . . . . . . . . .
Trabajo estimado para cada tarea . . . . . . . . . . . . . . . . . . . . .
Horas de trabajo previstas para cada grupo de tareas (fases) . . . . .
Diagrama de Gantt aproximado del proyecto . . . . . . . . . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Estadisticas de descarga de Boole-Deusto . . . . . . . . . . . . . .
Clasificación de los circuitos digitales . . . . . . . . . . . . . . . .
Boole-Deusto. Pantalla de diseño de sistemas combinacionales .
Proceso para el diseño de sistemas combinacionales . . . . . . .
Boole-Deusto. Diagrama de Karnaugh. . . . . . . . . . . . . . . .
Boole-Deusto: Diagrama de circuito NAND generado . . . . . . .
Boole-Deusto: Diagrama de circuito AND/OR generado . . . . .
Boole-Deusto. Pantalla de diseño de autómatas . . . . . . . . . .
Boole-Deusto. Circuito generado para un autómata . . . . . . .
2.6
2.7
2.8
3.1
3.2
3.3
3.4
3.5
3.6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
13
14
26
28
32
41
42
43
. 46
. 46
. 47
. 48
. 49
. 49
. 50
. 51
. 52
ix
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
5.1
5.2
5.3
5.4
5.5
5.6
5.7
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
x
Ubicación física de algunos de los experimentos de WebLab, contenidos en cajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebLab-Deusto. Pantalla de selección de experimentos de un usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arquitectura de los servidores de WebLab [44]. . . . . . . . . . . . . .
Diagrama de la federación en WebLab-Deusto [11] . . . . . . . . . . .
WebLab-Deusto, integrado en Facebook [11] . . . . . . . . . . . . . . .
Caja para FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logotipo de Xilinx Inc. [23] . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivo FPGA de Xilinx [23] . . . . . . . . . . . . . . . . . . . . . . .
Logotipo de Python [38] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logotipo de GWT (Google Web Toolkit) [18] . . . . . . . . . . . . . . .
GWT Designer (Editor WYSIWYG para GWT) [18] . . . . . . . . . . . .
Logotipo de jQuery [24] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logotipo de HTML5 [45] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo de aplicación WebGL, ejecutándose en Chrome [4] . . . . . .
Logotipo de node.js[30] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logotipo de PyDev [37] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logotipo de Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . . .
Microsoft Visual Studio 2012. . . . . . . . . . . . . . . . . . . . . . . . .
Github. Repositorio del proyecto WebLab . . . . . . . . . . . . . . . .
Vista principal de Blender, con el depósito de agua desarrollado durante este proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entorno Windows XP virtual utilizado para la modificación y extensión de Boole-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Experimento FPGA-Watertank . . . . . . . . . . . . . . . . . . . . . . .
Pantalla principal de diseño de Sistemas Combinacionales . . . . . . .
Botón para abrir Weblab-FPGA en el navegador por defecto . . . . .
Control de activación del modo WebLab . . . . . . . . . . . . . . . . .
Asignación de entradas y salidas compatibles con WebLab . . . . . .
Especificación de las tablas de verdad de un sistema combinacional .
Botón para la generación de código VHDL . . . . . . . . . . . . . . . .
Botón para la apertura de WebLab-FPGA en el navegador por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selección del VHDL a grabar en WebLab-FPGA. . . . . . . . . . . . . .
Sintetización y grabación del VHDL en la placa FPGA . . . . . . . . . .
Experimento FPGA activo con la placa grabada y en ejecución . . . .
Diseño de autómatas. Opciones de generación de código VHDL compatible con WebLab-Deusto . . . . . . . . . . . . . . . . . . . . . . . . .
Diseño de autómatas. Posibles relojes de WebLab-Deusto-FPGA . . .
Diseño de autómatas. Controles de Boole-Weblab-Deusto, incluido
el botón de “Start Weblab” . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaz del experimento FPGA-Watertank (tanque de agua) . . . . .
53
54
55
56
57
58
60
60
62
63
64
66
66
68
68
71
72
73
75
76
79
92
100
101
102
103
103
104
105
105
106
106
108
109
111
113
8.1
FPGA-Watertank, ejecutándose en un tablet . . . . . . . . . . . . . . . 127
9.1
Search volume for Coursera (red) and MOOC (blue), as reported by
Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
xi
Índice de Listados
5.1
5.2
5.3
Parte del código VHDL autogenerado por Boole-Deusto para un autómata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Configurando en el cliente dos nuevos experimentos JavaScript . . . . 87
Parte del archivo de definición de escena (world.js) de FPGA Watertank 90
7.1
7.2
7.3
7.4
7.5
Código VHDL de un sistema controlador del depósito de agua.
Definiendo el valor de las salidas . . . . . . . . . . . . . . . . . . .
Referenciando WeblabJS . . . . . . . . . . . . . . . . . . . . . . . . .
WeblabJS API (Weblab class) . . . . . . . . . . . . . . . . . . . . . .
Ejemplo de uso de WeblabJS . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 114
. 115
. 120
. 121
. 123
xiii
PROYECTO FIN DE CARRERA
1. INTRODUCCIÓN
En esta sección se describirá de forma breve en qué ha motivado la puesta en marcha
del proyecto, qué se espera lograr con él y en qué consistirá.
El proceso de aprendizaje de diseño de circuitos electrónicos digitales ha implicado tradicionalmente un proceso de varios pasos:
1. Especificación del problema
2. Diseño analítico
3. Diseño detallado
4. Conversión de diseño a circuito físico (puertas lógicas o descripción hardware)
5. Pruebas reales del sistema
Aunque conceptualmente el proceso es sencillo y de naturaleza secuencial, en la realidad
suele existir un problema. Mientras que los cuatro primeros suelen ser secuenciales y
pueden ser llevados acabo en un aula cualquiera o un entorno similar, los requisitos del
quinto paso (pruebas reales del sistema) son mayores.
Por una parte, es necesario contar físicamente con un laboratorio provisto de equipamiento especializado para poder trabajar. Para probar un diseño FPGA, por ejemplo, se
necesitarán generalmente ordenadores equipados con software de Xilinx o un fabricante
similar, con placas de prototipado de FPGAs, etc.
Aparte de la necesidad de disponer de estos equipos, y mantenerlos en correcto funcionamiento, existe también un problema práctico. Desde las cuatro primeras etapas a la
quinta, habrá en general un periodo de tiempo intermedio, que interrumpe el proceso de
aprendizaje.
El proyecto de diseño y desarrollo de la plataforma Boole-WebLab-Deusto reduce o
elimina totalmente estos inconvenientes, y además ofrece múltiples ventajas adicionales.
En parte por ésto, se enmarca dentro del Technology Enhanced Learning, ya que se basa
en la utilización de las TIC para mejorar el proceso de aprendizaje, y podemos afirmar
que se trata de un proyecto de investigación de carácter innovador.
Para lograr la mejora expuesta, el Boole-WebLab-Deusto permite el prototipado rápido
de un sistema digital en sólo unos minutos. El sistema digital a crear se diseña en BooleDeusto, e inmediatamente después puede probarse en hardware físico real (una placa
FPGA) a través de WebLab-Deusto.
Esto implica que los estudiantes no necesitan acceso físico a equipamiento especializado, y que no hay un retraso entre el diseño y las pruebas, lo que facilita la tarea a
1
1. INTRODUCCIÓN
estudiantes y profesores. Acceso a un ordenador con conexión a Internet es suficiente
para llevar acabo el proceso que anteriormente requería acceso a un laboratorio electrónico.
Las mejoras a la experimentación electrónica del proyecto, sin embargo, no se limitan a
ésto. Otro inconveniente del sistema clásico de aprendizaje que se ha detectado es que
en ocasiones los experimentos resultan demasiado sencillos y distantes de la práctica
real.
Mientras que en la realidad los dispositivos electrónicos se utilizan para controlar sistemas
complejos como una línea de producción, por limitaciones prácticas, los ejercicios de los
estudiantes suelen limitarse a actividades como el control de unos LEDs.
A pesar de que el valor educativo de tales ejercicios se innegable, la simplicidad de la
salida hace que sean a veces poco inmersivos, y que los estudiantes no lo consideren
como un reto.
Gran parte del carácter innovador de este proyecto se debe a la capacidad que se ha
añadido de extender los experimentos electrónicos reales con realidad aumentada.
Utilizando estas técnicas, es posible colocar en el experimento un modelo virtual,
sobre la vista de la placa FPGA física real.
De este modo, podemos tener, por ejemplo, un sistema relativamente complejo,
visual e interesante como un tanque de
agua.
El reto de tales experimentos, por supuesto, consiste en controlar mediante la placa
FPGA (que es física y absolutamente real)
el modelo virtual.
Para hacer ésto posible, el sistema per- Figura 1.1.: Experimento FPGA real controlando un tanque de agua virtual
mite, valiéndose en parte de técnicas de
visión artificial, la interacción en ambos sentidos entre modelo virtual y placa física
real.
El proyecto se basa en parte en los resultados obtenidos durante los cuatro años de mi
colaboración con el proyecto WebLab-Deusto, trabajando como becario en el soporte,
desarrollo y mejora del sistema.
Tal colaboración ha resultado también en la publicación de diversas contribuciones en
conferencias y revistas.
1.1 PRESENTACIÓN
El presente documento describe el plan de trabajo del proyecto realizado en nueve capítulos.
2
En primer lugar se describe brevemente el contexto en el que se desarrolla. Se consideran los diferentes campos del conocimiento involucrados y se introducen las dos
herramientas en torno a las que gira el proyecto, el laboratorio remoto WebLab-Deusto y
el software de diseño electrónico Boole-Deusto.
En segundo lugar el documento de objetivos describe desde un punto de vista más
formal la planificación (estimada) del proyecto, sus objetivos y alcance, las fases en las
que se ha dividido, y la descripción de la realización y condiciones de ejecución.
Tras esto, se dedica el capítulo de tecnologías a describir desde una perspectiva más
práctica Boole-Deusto, WebLab-Deusto, y las demás tecnologías hardware y software
que tienen un papel importante en el proyecto.
Después, el desarrollo describe el entorno técnico utilizado, así como, desde una perspectiva técnica, el proceso que se ha seguido para la ejecución del proyecto.
Posteriormente, se dedica el capítulo problemas e incidencias para recoger y describir
aquellas limitaciones y complicaciones técnicas más notables que han aparecido durante
el desarrollo.
A continuación, manuales contiene dos manuales orientados a los usuarios. El primero,
la guía de usuario de Boole-WebLab-Deusto, que describe el proceso a seguir para diseñar y probar un sistema digital mediante Boole-WebLab-Deusto. El segundo, la guía
para utilizar el experimento FPGA Watertank, y aprovechar las características que ofrece
para programar un controlador para el modelo virtual (un tanque de agua).
Tras esto, en conclusiones y trabajo futuro pueden conocerse los resultados que se
han obtenido, la comparación que puede hacerse con los objetivos iniciales, y las líneas
de trabajo futuras que podrían seguirse.
El último capítulo se dedica a un posible plan de negocio, que propone una empresa basada en la provisión de servicios de experimentación remota a centros formativos.
Para terminar, se proporcionan también diferentes anexos de interés, que incluyen, entre
otros documentos, diversos artículos publicados durante los cuatro años de colaboración
como parte del equipo de WebLab-Deusto.
3
2. CONTEXTO
2.1 INTRODUCCIÓN
Este proyecto se ha realizado en el ámbito del proyecto de investigación de laboratorios
remotos WebLab-Deusto [46] de la Universidad de Deusto, con cuyo equipo el autor ha
colaborado durante cuatro años.
El proyecto supone, por una parte, una labor de integración entre el software de laboratorios remotos WebLab-Deusto y el software de diseño electrónico Boole-Deusto, para
facilitar así el proceso de aprendizaje de diseño de sistemas electrónicos digitales.
Por otra parte, y donde radica gran parte del contenido innovador e investigador del proyecto, el proyecto implica la creación de una infraestructura de realidad aumentada capaz
de añadir sobre las placas físicas reales de los experimentos un modelo virtual. De este
modo, dichas placas físicas pueden ser programadas por los usuarios, controlando con
ellas el modelo virtual. Para lograr que sea posible la interacción en ambos sentidos, se
recurre a técnicas de visión artificial.
En ambos casos, podemos afirmar que se trata de una contribución dentro del campo del
aprendizaje mejorado con tecnología (Technology Enhanced Learning).
Como una fase anterior al proyecto en sí mismo, se estudiará muy brevemente la naturaleza y estado del arte de los campos involucrados, incluyendo el aprendizaje mejorado
con tecnología, los laboratorios remotos, la realidad aumentada, la visión artificial, y el
diseño de sistemas digitales.
También se introducirán los principales softwares y entornos de partida del proyecto:
WebLab-Deusto y Boole-Deusto.
Finalmente, se listarán las publicaciones del autor relacionadas con el proyecto y con su
colaboración en WebLab-Deusto.
2.2 TECNOLOGÍAS Y ESTADO DEL ARTE
2.2.1 Technology Enhanced Learning
El aprendizaje mejorado por la tecnología (TEL) es un campo amplio, a veces referido
simplemente como eLearning, que es un término en general más inclusivo. Ambos casos describen tecnologías orientadas a dar alguna clase de soporte al aprendizaje o a
la enseñanza. El Technology Enhanced Learning y el eLearning suelen definirse como
“pedagogía posibilitada por la tecnología digital” [25][48].
5
2. CONTEXTO
En general, éstas tecnologías aportan alguna clase de ventaja significativa con respecto
a las técnicas tradicionales de aprendizaje. Muchas veces esta ventaja es, simplemente,
la educación a distancia, pero no tiene por qué limitarse a esto.
Una de las tecnologías que han surgido en este ámbito son los laboratorios remotos
[14][2]. Estos laboratorios, que serán descritos en más detalle en secciones posteriores
de este documento, permiten a estudiantes o usuarios acceder desde cualquier lugar
del globo a experimentos que físicamente se ubican en la universidad o en otro lugar
distante.
Otra familia de tecnologías relacionadas que hoy en día está experimentando un gran crecimiento en desarrollo y popularidad [35] son los MOOC (Massively Online Open Course).
Este término hace referencia a cursos online, orientados a la participación libre y gratuita
de miles de personas, a través de la Web. En general, los formatos de los MOOC imitan a
los de una curso tradicional, y están basados en vídeos, resolución de problemas, lecturas, y otros materiales. Se considera probable que en el futuro la influencia de los MOOCs
sobre el aprendizaje y la enseñanza continue creciendo, y su potencial se aplique en los
diversos ámbitos del saber, incluyendo las ciencias de la salud [29][19].
Finalmente, otro campo relacionado que es importante destacar es el de la realidad virtual.
La realidad virtual se basa en ofrecer al usuario un entorno virtual (generado digitalmente
por ordenador), tratando de lograr una experiencia inmersiva y realista. El mundo virtual,
por el que el usuario puede navegar y con el que puede interactuar, puede simular un
lugar real del mundo, puede ser totalmente imaginario, o puede ser una mezcla de ambas
cosas.
A pesar de que las aplicaciones de la realidad virtual son múltiples, una de las más comunes es precisamente el aprendizaje. Las aplicaciones en este ámbito son extremadamente numerosas. Se ha utilizado, por ejemplo, para crear sistemas de entrenamiento
para paracaidistas [21], que permiten practicar la actividad sin riesgo. También se ha utilizado con éxito en el sector de la medicina para la práctica de operaciones de cirugía
[42].
2.2.2 Laboratorios remotos
2.2.2.1 Evolución
El campo de los laboratorios remotos está muy relacionado con el eLearning y el Technology Enhanced Learning.
Un laboratorio remoto es un conjunto de software y de hardware que permite a estudiantes o usuarios en general el acceso remoto a experimentos (equipamiento físico real) que
está ubicado en una universidad u otro lugar semejante. Esto quiere decir, por ejemplo,
que una persona en cualquier lugar del globo, con solamente un ordenador con acceso a internet, puede experimentar con equipamiento hardware que esté ubicado en una
universidad a miles de kilómetros.
6
La tecnología de laboratorios remotos no es tan reciente como podría pensarse. A finales
de los 90, apareció ya unos de los primeros laboratorios accesibles por Internet, en torno
al proyecto europeo PEARL [6]. Sin embargo, en torno al año 2000 comenzó la aparición
de laboratorios remotos en contextos universitarios [40].
Figura 2.1.: Laboratorio remoto de propósito específico [31]
2.2.2.2 Laboratorios remotos de propósito específico
Los laboratorios remotos son muy distintos entre sí, pero en general todos ellos soportan
al menos ciertas características:
Autenticación
Control y limitación de acceso (para garantizar uso exclusivo si es necesario)
Registro de eventos o actividad
Administración
Especialmente en el pasado, los laboratorios remotos se han enfocado hacia un sólo
experimento concreto. Es decir, un laboratorio remoto ofrecería por ejemplo únicamente
soporte a la creación de pequeños circuitos electrónicos. Esta clase de laboratorios se
conocen como specific purpose remote laboratories (SPRL), y existen muchos ejemplos
[16].
Cabe notar que a pesar de estar orientados hacia un sólo propósito, algunos de ellos son
sistemas muy complejos, y tienden a soportar tal propósito de una manera excelente. Un
ejemplo sería VISIR [17].
En la Fig. 2.1 podemos ver un diagrama que representa la estructura de un SPRL. Como
podemos ver, lo fundamental es el hecho de que, a través generalmente de un simple
navegador y de acceso a Internet, proporcionan acceso a equipamiento que puede estar
ubicado en lugares distantes.
7
2. CONTEXTO
2.2.2.3 Sistemas de gestión de laboratorios remotos
Aunque los laboratorios remotos de propósito específico pueden sin duda ser efectivos,
tienen ciertos inconvenientes.
Muchas de las características que soportan no son realmente propias de su propósito
específico, sino que son sencillamente facilidades genéricas que todo laboratorio remoto
tiene necesidad de soportar. Cada laboratorio de propósito específico se ve por tanto
obligado a reimplementar tales características.
Las consecuencias negativas de ésto son varias:
Los desarrolladores de laboratorios de propósito específico deben reimplementar
diversas funcionalidades que verdaderamente no pertenecen a su propósito específico.
La calidad de dichas funcionalidades secundarias pero necesarias termina siendo
variable.
La interfaz y funcionalidades soportadas son muy distintas para cada laboratorio,
lo que perjudica a la experiencia del usuario.
Para mejorar la situación a este respecto, han surgido los sistemas de gestión de laboratorios remotos, conocidos como Remote Laboratory Management Systems (RLMS).
Estos sistemas son, en definitiva, laboratorios remotos de propósito general. Proveen diversas características comunes, como autenticación, administración, un estilo de interfaz
de usuario, escalabilidad, etc. Proveen también experimentos específicos, y facilitan el
desarrollo de experimentos nuevos.
Existen unos cuantos RLMS. Algunos de éstos son, por ejemplo, MIT iLabs [20], Labshare
Sahara [27], VLCAP [39] y el propio WebLab-Deusto [32], que se describirá en detalle en
secciones posteriores de este trabajo.
Figura 2.2.: Sistema de gestión de laboratorios remotos (RLMS) [31]
8
Las ventajas de los RLMS son múltiples. Aparte de simplificar el proceso de desarrollo
de nuevos experimentos, proveen uniformidad al usuario. Además, puesto que múltiples
características son comunes a todos los experimentos, dichas características tienden a
estar mejor soportadas que en laboratorios remotos de propósito específico. Al añadir
una característica transversal nueva, además, automáticamente pasa a estar disponible
a todos los experimentos. Un ejemplo de ésto sería integración en Facebook o LMSs
(Learning Management Systems) [33].
En la Fig. 2.2 podemos ver la estructura de un RLMS, y cómo el sistema pone diversos
experimentos al alcance de los usuarios.
2.2.2.4 Ventajas de un laboratorio remoto
Los laboratorios remotos son herramientas muy potentes para la formación (la discusión sobre su utilidad en aplicaciones industriales queda fuera del ámbito de este trabajo).
Algunas de las ventajas más significatias que aporta son las siguientes:
Eficiencia en el uso de equipos: Los usuarios pueden repartirse fácilmente en el
tiempo. Con un número limitado de equipos distintos puede servirse a un número
mayor de usuarios que un laboratorio tradicional.
Comodidad y conveniencia: Los estudiantes pueden conectarse desde cualquier
lugar y a cualquier hora. Esto facilita su aprendizaje y la tarea del profesor, que normalmente necesitaría planificar y reservar una sesión en un laboratorio tradicional,
etc.
Eficiencia en el aprovechamiento del tiempo: Los estudiantes y los profesores no
necesitan perder tiempo desplazándose a un laboratorio real, preparando el equipamiento para las pruebas o recogiéndolo al terminar. Los experimentos remotos
están listos para ser usados, en el mismo momento en el que se accede remotamente.
Distancia: Pueden ser ofrecidos a estudiantes que se encuentren en cualquier lugar
del globo. Esta característica, con el auge de los MOOC (Massive Open Online
Course) y de la educación a distancia es de importancia creciente hoy en día.
Soporte a discapacitados: Independientemente de la discapacidad del estudiante,
los experimentos están controlados por ordenador y son muy fácilmente accesibles,
desde cualquier lugar, y utilizando software de ayuda específico si es necesario.
Ventajas económicas: Es necesario menos equipos para el mismo número de estudiantes, se facilita el mantenimiento y se evita la necesidad de personal supervisor
al no tener que ofrecer un laboratorio tradicional físicamente accesible por grandes
grupos de estudiantes. El hecho de que el equipamiento no esté expuesto a accidentes, y que no se requiera montaje y desmontaje constante de los equipos, como
en un laboratorio tradicional, suele aumentar la vida útil del equipamiento.
9
2. CONTEXTO
2.2.3 Realidad aumentada
Figura 2.3.: Realidad aumentada. Muebles virtuales en una habitación real. [43]
La realidad aumentada (Augmented Reality) es una visualización directa o indirecta de
un entorno real. Dicho entorno real es “aumentado” o “extendido” mediante elementos
audiovisuales generados por ordenador.
Si bien el desarrollo de la realidad aumentada es especialmente notable hoy en día, ya en
los 90 existían un gran número de aplicaciones, desde aplicaciones para el entrenamiento
de cirujanos hasta aplicaciones de entrenamiento militar [1].
En la Fig. 2.3 podemos ver un buen ejemplo de realidad aumentada. En la figura, aparece
una habitación real en la que se encuentra un conjunto de muebles virtuales, que por
supuesto no existen realmente en la habitación. En este caso se trata de un software
de diseño de interiores, pero las posibles aplicaciones de la realidad aumentada son
extremadamente numerosos y variados. Ejemplos son sistemas de gestión de procesos
de construcción [13] y muchas otras aplicaciones que se han llevado acabo durante los
últimos años [50].
10
Figura 2.4.: Google Glasses: Gafas para la realidad aumentada
Como la Fig. 2.4 deja de manifiesto, la realidad aumentada es un campo en desarrollo,
cuya importancia posiblemente continue creciendo en el futuro cercano, gracias a los
avances tecnológicos de los últimos tiempos.
2.2.3.1 Realidad mixta
Figura 2.5.: Realidad mixta: Personas reales y virtuales juntas, en un entorno real. [12]
La realidad mixta está relacionada directamente con la realidad aumentada, y es menos
conocida.
Mientras que la realidad aumentada se refiere al “aumento” de la realidad con elementos
virtuales, la realidad mixta se refiere a la mezcla de elementos virtuales y elementos
reales para crear un entorno nuevo, formado tanto por elementos virtuales como por
elementos reales, que interaccionan entre sí y en tiempo real.
En ocasiones, no es evidente dónde empieza la realidad aumentada y dónde la realidad
mixta. A lo largo de este documento se hablará más frecuentemente de realidad aumentada, por ser un término más conocido y utilizado. En ciertas ocasiones, sin embargo,
sería posiblemente más estricto hablar de realidad mixta.
11
2. CONTEXTO
2.2.4 Visión artificial
Figura 2.6.: Coche sin conductor de Google. Parcialmente basado en visión artificial. [15]
La visión artificial es un campo relativamente maduro, con una cantidad muy alta de
aplicaciones útiles presentes y futuras.
Su objetivo principal es el desarrollar métodos y técnicas para poder analizar y entender
una imagen o serie de imágenes, extrayendo de ellas información relevante.
Existen ya en 1998, por ejemplo, sistemas para vigilancia de tráfico [5]. Sistemas más
recientes son sistemas para la navegación de robots [8], o incluso diversos proyectos en
curso para la creación de vehículos sin conductor [26][15] (realmente, usan un sistema
complejo de sensores y no sólo visión artificial).
En el ámbito de los laboratorios remotos, uno de los usos de la visión artificial es el
de poder saber qué está haciendo el usuario en su experimento. Esto permite conocer
cuál es el resultado qué obtiene, registrarlo en la base de datos de forma conveniente,
comprobar si el resultado del experimento ha sido el correcto, o incluso asegurarse del
buen estado del experimento.
2.3 SOFTWARE Y ENTORNOS DE PARTIDA
El proyecto se basa en la integración y mejora de dos software preexistentes: WeblabDeusto (sistema de gestión de laboratorios remotos) y Boole-Deusto (un software educativo de diseño electrónico). A continuación, se incluirá un breve resumen de sus características, que facilite la comprensión de este trabajo. En apartados posteriores de
éste documento se describirán en más detalle y desde una perspectiva más técnica los
detalles relevantes de ambos.
12
2.3.1 Boole-Deusto
Boole-Deusto [52][51] es una herramienta software para el diseño de circuitos electrónicos digitales. Es una herramienta de código abierto, desarrollada por profesores y estudiantes de la Universidad de Deusto, y su primera versión fue publicada en el año 2000.
Está principalmente orientada a un ámbito educativo (para diseño de circuitos electrónicos digitales profesionales ya existen otras herramientas muy completas). Entre sus
características más notables está el diseño de sistemas tanto combinacionales como secuenciales (autómatas), y la generación automática de diagramas para dichos circuitos
y de código VHDL.
Figura 2.7.: Una de las pantallas principales de Boole-Deusto (diseño de sistemas combinacionales)
2.3.2 Weblab-Deusto
Weblab-Deusto [32] es un laboratorio remoto de código abierto [46] desarrollado en la
Universidad de Deusto. En concreto, puede ser considerado un RLMS (Remote Laboratory Management System), ya que está diseñado como un framework genérico, que
soporta cualquier tipo de experimento remoto y que no se limita a un tipo de experimentos específico o a un solo campo. En la actualidad, si bien predominan los experimentos
electrónicos, se soportan otros más relacionados con biociencias y otros campos, y es
relativamente sencillo el desarrollo de experimentos nuevos.
Uno de los experimentos de Weblab-Deusto es Weblab-Deusto-FPGA, que tendrá parti-
13
2. CONTEXTO
cular relevancia para este proyecto. Weblab-Deusto-FPGA permite a sus usuarios grabar
remotamente un programa VHDL en una placa física real. Una vez grabado el programa,
pueden visualizar la placa física de forma remota mediante una Webcam, e incluso interactuar con ella mediante botones e interruptores virtuales (que no obstante, producen
una entrada física real en la placa).
Figura 2.8.: Experimento FPGA estándar, en WebLab-Deusto, ejecutando una lógica ya grabada provista por un usuario
En la Fig. 2.8 se muestra la versión estándar del experimento WebLab-Deusto-FPGA. El
programa ya ha sido enviado por el usuario y grabado por WebLab en la placa física, que
puede verse através de la Webcam. Dicha webcam muestra la placa FPGA en tiempo
real, permitiendo observar su salida gracias a los LEDs que dicha placa tiene. En la imagen puede verse a uno de ellos encendido. Podemos ver también, en el espacio inferior,
la fila de interruptores, mediante los que se envían señales a la placa. Los interruptores
en sí son virtuales, pero la placa recibe señales reales.
2.4 PUBLICACIONES
En el contexto de mi colaboración de cuatro años con el equipo de investigación de
WebLab-Deusto he participado en distintas publicaciones. Algunas de éstas tratan directamente sobre el proyecto. Otras se centran en diferentes aspectos del laboratorio remoto
WebLab-Deusto, y de forma indirecta han llevado a la consecución de éste proyecto. Se
incluye a continuación una lista de ambos grupos (y se incluyen las más relevantes en
los anexos).
1. Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Pablo Orduña, Olga Dzbiabenko. Integration of a Remote Lab in a Software Tool for Digital Electronics.
14
(2013). Submitted for publication.
2. Javier Garcia-Zubia, Luis Rodriguez-Gil, Pablo Orduña, Ignacio Angulo, Olga Dzbiabenko. Boole-WebLab-Deusto: Integration of a remote lab in a tool for digital
circuits design. (2013). Submitted for publication.
3. Javier Garcia-Zubia, Luis Rodriguez-Gil, Pablo Orduña, Ignacio Angulo, Unai Hernandez, Olga Dziabenko, Mari Luz Guenaga. An Integrated Solution for Basics Digital Electronics: Boole-DEUSTO and WebLab-DEUSTO. REV2013: 10th International Conference on Remote Engineering and Virtual Instrumentation. Sydney,
Australia, 6 - 8 February 2013.
4. Pablo Orduña, Luis Rodriguez-Gil, Diego López-de-Ipiña, Javier Garcia-Zubia. Sharing Remote Labs: A Case Study. International Journal of Online Engineering - iJOE
9(Special Issue: REV2012 Exhibition). 26 – 27. 2013.
5. Pablo Orduña, Xabier Larrakoetxea, David Buján, Aitor Gómez-Goiri, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil, Diego López-de-Ipiña, Javier GarziaZubia. WebLab-Deployer: exporting remote laboratories as SaaS through federation
protocols. REV2013: 10th International Conference on Remote Engineering and Virtual Instrumentation. Sydney, Australia, 6 - 8 February 2013.
6. Javier García-Zubía, Pablo Orduña, Ignacio Angulo, Unai Hernández, Olga Dziabenko, Luis Rodríguez, María Luz Güenaga, Ingvar Gustavsson. Remote Laboratories:
Opportunities and Challenges. The World of Sustainable Laboratories, WOSLAB
2012. Book of Abstracts, The World of Sustainable Laboratories, WOSLAB 2012,
ISBN: 978-84-87543-22-7, pp:63-64. 2012.
7. Javier García Zubía, Ignacio Angulo, Pablo Orduña, Unai Hernández, Diego Lópezde-Ipiña, Luis Rodriguez, Olga Dziabenko, Veronica Canivell. WebLab-Deusto-CPLD:
A Practical Experience. International Journal of Online Engineering - iJOE 8(S1):
17-18 (2012).
8. Pablo Orduña, Javier Garcia-Zubia, Luis Rodriguez-Gil, Diego López-de-Ipiña. Sharing the remote laboratories among different institutions: a practical case. Remote
Engineering & Virtual Instrumentation. REV2012. Bilbao, Spain. July 2012.
9. Pablo Orduña, Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Olga Dziabenko, Diego López-de-Ipiña. Exploring students collaboration in remote laboratory
infrastructures. Remote Engineering & Virtual Instrumentation. REV2012. Bilbao,
Spain. July 2012.
10. Luis Rodriguez-Gil, Pablo Orduña, Javier Garcia-Zubia, Diego López-de-Ipiña. Advanced integration of OpenLabs VISIR (Virtual Instrument Systems in Reality) with
Weblab-Deusto. Remote Engineering & Virtual Instrumentation. REV2012. Bilbao,
Spain. July 2012.
11. Javier Garcia-Zubia, Bruno Campos, Pablo Orduña, Luis Rodriguez, Ignacio Angulo, Olga Dziabenko. Easily Deployable Low-Cost Remote Lab Platform.. Remote
15
2. CONTEXTO
12. Pablo Orduña, Javier García-Zubia, Fabricio Gazzola, Luis Rodriguez-Gil, Jaime
Irurzun, Diego López-de-Ipiña. Using LabVIEW Remote Panel in Remote Laboratories: advantages and disadvantages. IEEE EDUCON 2012. Marrakesh, Morocco,
April 2012. Page(s): 1 - 7. DOI: 10.1109/EDUCON.2012.6201134. ISBN: 978-1-46731457-2.
13. Pablo Orduña, Jaime Irurzun, Luis Rodriguez-Gil, Javier Garcia-Zubia, Fabricio
Gazzola, Diego López-de-Ipiña. Adding New Features to New and Existing Remote
Experiments through their Integration in WebLab-Deusto. International Journal of
Online Engineering (iJOE) (ISSN: 1861-2121). 2011.
14. Javier Garcia-Zubia, Ingvar Gustavsson, Unai Hernandez-Jayo, Pablo Orduña, Ignacio Angulo, Luis Rodriguez-Gil, Diego López-de-Ipiña. Using VISIR: Experiments,
Subjects and Students. International Journal of Online Engineering (iJOE) (ISSN:
1861-2121). 2011.
15. Javier García-Zubía, Pablo Orduña, Unai Hernández, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil and Diego López-De-Ipiña. WebLab-Deusto-CPLD: A
Practical Experience. 1st Experiment@ International Conference (expat2011). 2011.
16. Javier Garcia-Zubia, Pablo Orduña, Ignacio Angulo, Unai Hernandez, Olga Dziabenko, Diego Lopez-de-Ipiña, Luis Rodriguez-Gil. Application and User Perceptions of
Using the WebLab-Deusto-PLD in Technical Education. 41st ASEE/IEEE Frontiers
in Education Conference (FIE 2011) - GOLC Session. Rapid City, South Dakota,
United States, October 2011.
17. Pablo Orduña, Jaime Irurzun, Luis Rodriguez-Gil, Javier Garcia-Zubia, Diego Lopezde-Ipiña Reusing requirements among remote experiments for their development and
integration under WebLab-Deusto. REV 2011: 8th International Conference on Remote Engineering and Virtual Instrumentation. Brasov, Romania, July 2011.
18. Javier Garcia-Zubia, Ingvar Gustavsson, Pablo Orduña, Diego Lopez-de-Ipina, Unai
Hernandez, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil Using VISIR at
the University of Deusto: experiments, subjects and students. REV 2011: 8th International Conference on Remote Engineering and Virtual Instrumentation. Brasov,
Romania, July 2011. ISBN: 978-3-8958-555-1, pp: 244-247.
19. J. García-Zubia, P. Orduña, I. Angulo, U. Hernández, O. Dziabenko, L. RodriguezGil. Justificación, propósito y ventajas de un laboratorio remoto. III Foro Internacional sobre Innovación Docente. Bilbao, Julio 2011.
20. Pablo Orduña, Javier García-Zubia, Jaime Irurzun, Diego López-de-Ipiña, Luis RodriguezGil. Enabling mobile access to Remote Laboratories IEEE EDUCON 2011 (ISBN:
978-1-61284-641-5). Amman, Jordan, April 2011. pp. 312 - 318. DOI: 10.1109/EDUCON.2011.5773154.
21. Javier García-Zubia, Andreas Pester, Pablo Orduña, Jaime Irurzun, J.M. González,
Ignacio Angulo, Unai Hernández, Luis Rodriguez. One Lesson from TARET: what
16
is expected from a remote lab? REV2010. Stockholm, Sweden. 2010. ISBN: 978-389958-540-7, 34-38 pp.
17
3. OBJETIVOS DEL PROYECTO
En este capítulo se indicará en cierto detalle en qué consistirá el proyecto, cuáles son
sus objetivos, y qué resultados pretenden obtenerse.
3.1 DESCRIPCIÓN DEL PROYECTO
El proyecto consta de dos grandes objetivos diferentes pero relacionados. En primer lugar, se busca integrar el software de código abierto de diseño electrónico Boole-Deusto
con la infraestructura de laboratorios remotos Weblab-Deusto. En segundo lugar, se busca desarrollar una infraestructura que permita ampliar los experimentos electrónicos de
WebLab-Deusto con modelos virtuales (realidad mixta) de aplicaciones prácticas. Se
desarrollará también al menos un nuevo experimento electrónico utilizando tal infraestructura.
3.1.1 Integración Boole-Weblab-Deusto
En la actualidad, como se ha explicado anteriormente, y se detallará en secciones posteriores, Boole-Deusto es un software de código abierto de diseño electrónico, utilizado
para diseñar sistemas digitales de dos tipos distintos: combinacionales y secuenciales
(autómatas).
Weblab-Deusto, por su parte, es una infraestructura genérica de laboratorios remotos.
Soporta muchos tipos de experimentos, y es fácilmente extensible. Una clase de experimentos que soporta es la grabación remota de programas en dispositivos hardware.
En estos experimentos los usuarios pueden, remotamente, grabar un programa que hayan previamente sintetizado o compilado en un dispositivo físico remoto real. Hecho ésto,
pueden observar cómo funciona dicho dispositivo a través de una Webcam e incluso interactuar con él. Dicha interacción se produce a través de controles virtuales que se traducen
en señales físicas. En la mayoría de experimentos electrónicos actuales estos controles
virtuales toman la forma de interruptores. Puede verse uno de estos experimentos en
funcionamiento (en concreto, con un dispositivo FPGA) en la Fig. 2.8.
Uno de los dos grandes objetivos de este proyecto es integrar ambos sistemas (BooleDeusto y WebLab-Deusto), realizando las modificaciones y extensiones oportunas para
que puedan ser usados juntos, en un sólo flujo de trabajo integrado, sencillo y eficiente.
Es decir, el objetivo es que el usuario pueda comenzar diseñando un sistema digital (ya
sea combinacional, ya sea secuencial) en Boole-Deusto. Una vez diseñado, inmediata y
19
fácilmente, a partir del propio Boole-Deusto podrá probar su diseño (e interactuar con él)
en hardware real a través de Weblab-Deusto.
Figura 3.1.: Flujo de trabajo Boole-WebLab-Deusto
En la Fig. 3.1 se puede observar el flujo de trabajo completo habitual, similar al explicado
arriba. El proceso parte de la especificación de un sistema digital. La complejidad de tal
especificación, por supuesto, variará mucho dependiendo del sistema. A continuación,
el usuario procederá a diseñar el sistema. El caso mostrado en las imágenes es de un
autómata. Hecho esto, la tercera etapa será la de obtener la implementación del sistema,
es decir, del circuito o código VHDL que lo describe. Finalmente, el usuario probará el
sistema que ha creado, y verificará que funciona correctamente. El flujo de trabajo, como
se observa, es lineal y sencillo.
Boole-Deusto ya posee cierta capacidad para generar código VHDL, actualmente el código VHDL generado no sólo contiene errores, sino que requiere serias modificaciones
manuales para hacerlo compatible con Weblab-Deusto (que espera entradas y salidas
específicas, etc).
Asimismo, en el momento de escribir esto, Weblab-Deusto tiene la capacidad de grabar
programas ya sintetizados en placas físicas, pero no tiene la capacidad de sintetizar los
programas a partir de código. Para sintetizar dichos programas, se requiere software
especializado. En el momento de escribir esto, la versión estándar de dicho software,
provisto por Xilinx, requiere la descarga de una suite de desarrollo de unos 6 gigabytes
de tamaño [23].
Para logar dicha integración, por tanto, será necesario, primero, realizar diversas modificaciones y extensiones a Boole-Deusto (que se verán complicadas debido a la antigüedad de dicho software). Dichas modificaciones añadirán los elementos necesarios a la
interfaz para diseñar sistemas compatibles con Weblab-Deusto, incluyendo la elección
apropiada de nombres para salidas y entradas, los controles necesarios para abrir automáticamente Weblab-Deusto y generar código apropiado, etc. Será también necesario
rediseñar el sistema de generación de código VHDL, de tal modo que siga permitiendo la generación de código VHDL genérico, y añadiendo la generación de código VHDL
directamente compatible con Weblab-Deusto.
Será también necesario extender Weblab-Deusto, añadiendo la capacidad de sintetizar
20
código VHDL, produciendo así por sí sólo los archivos binarios requeridos para la grabación en las placas. De este modo, los usuarios finales podrán probar su código sin
necesidad de instalar en sus ordenadores software especializado (que en muchos casos es totalmente inviable, debido a la complejidad y tamaño de dicho software, y a la
necesidad instalación y registro).
El software especializado residirá por tanto en los propios servidores de Weblab-Deusto,
siendo su uso absolutamente transparente para los usuarios remotos.
En conclusión, una vez que dichas extensiones hayan sido implementadas y puestas en
marcha, los usuarios podrán, en sólo unos minutos y sin necesitar ningún software especial, diseñar un sistema digital con Boole-Deusto, y, con apenas dar a un botón, hacer que
su sistema digital se grabe automáticamente en una placa hardware física real, mediante
la cual podrán probar de forma remota que se comporta (o no) como esperan.
3.1.2 Modelos virtuales en experimentos electrónicos reales
En la actualidad, los experimentos electrónicos en
general consisten en una placa física, que remotamente puede grabarse con un programa. Una vez el
programa está grabado, los usuarios pueden interactuar con la placa a través de interruptores, y pueden observar su salida a través de LEDs, que tiene
la propia placa (ver Fig. 3.2). Si bien los LEDs son
en muchos casos muy prácticos para conocer la salida del sistema (son visibles a través de la Webcam), son en ocasiones demasiado simples.
Lo ideal sería que pudieran existir elementos de salida distintos (por ejemplo, un motor, un tanque de Figura 3.2.: Placa FPGA con 4 de los 8
LEDs que actúan como saagua, una línea de producción o incluso elementos
lida, encendidos
más exóticos como el embalse de una central hidroeléctrica). De este modo, los experimentos serían no sólo más interesantes y motivantes
para los usuarios, sino más realistas y prácticos, ya que las placas se estarían usando,
como en un entorno real, para controlar un dispositivo y no sólo unos LEDs. No obstante,
en la práctica disponer de elementos de salida distintos supone varios problemas:
Si en vez de LEDs se conecta una placa física a otro tipo de elemento de salida, el
experimento pasa a ser muy concreto. La placa podrá utilizarse para ese ejercicio
determinado (por ejemplo, controlar un motor), y para pocos más. Esto supone un
elevado coste adicional con respecto a una placa genérica, que puede ser utilizada
para cualquier experimento.
Los elementos de salida en sí mismos pueden ser caros, directamente impracticables o incluso peligrosos. El mantenimiento de un tanque de agua, por ejemplo,
sería notablemente complejo, especialmente porque deberían buscarse modos de
gestionar los desbordamientos, de que no existan escapes, etc. El coste de una
21
línea de producción o de una central hidroeléctrica, aunque fuesen a escala y para
experimentación, sería probablemente prohibitivo.
Como solución intermedia, con un grado de realismo aceptable y sin embargo un coste
muy bajo, en este proyecto se propone realizar experimentos que, basados en una placa
física real, estén dotados de realidad mixta. Es decir, que consten de un modelo virtual
sobre el que la placa física real pueda actuar.
De este modo, el usuario podrá diseñar, por ejemplo, el sistema de control de un tanque
de agua. Podrá grabar dicho sistema en una placa FPGA, y dicha placa actuará directamente sobre un modelo virtual de un tanque de agua.
Figura 3.3.: Visión general del sistema de modelos virtuales (realidad mixta)
En el diagrama de la Fig. 3.3 podemos observar la base conceptual del sistema de experimentos con modelos virtuales que este proyecto propone. Vemos que tales experimentos
tendrían, en primer lugar, la placa controladora, absolutamente real, con la que cuentan
la mayoría de experimentos electrónicos de WebLab. Ésta placa puede ser remotamente
programada por el usuario remoto. Cuenta con LEDs como salidas integradas, que se
mantendrían. La clave, sin embargo, es que además de actuar sobre los LEDs, la placa
actuará sobre la simulación de algún sistema, tal como un depósito de agua. Dicha interacción funciona en ambos sentidos. La simulación puede también actuar sobre la placa
física, por ejemplo, determinando con sensores virtuales el valor de sus entradas.
22
Si bien un modelo virtual de un tanque de agua es evidentemente menos realista que un
verdadero tanque de agua, el coste que supone es extremadamente bajo en comparación. El realismo y dinamismo que aporta, sin embargo, no se ve perjudicado demasiado.
La placa FPGA controladora sobre la que trabaja el usuario sigue siendo absolutamente real, y por tanto, en la mayor parte de aspectos, el sistema se comportará como se
comportaría uno real en un entorno práctico. Sencillamente, la placa física real en vez de
controlar un depósito de agua real, controlará uno virtual, tridimensional.
Las ventajas, por tanto, pueden resumirse:
Aumenta la variedad, dinamismo e inmersión de los experimentos.
Los experimentos son más realistas y prácticos.
Resulta sencilla y muy económica la creación de experimentos nuevos (en los que
varíe el modelo virtual pero no el hardware).
El nivel de realismo que se consigue es aceptable y sigue siendo mucho mayor
que el de cualquier simulación completa, ya que la placa controladora en sí sigue
siendo absolutamente real.
3.2 VISIÓN GENERAL DEL SISTEMA
En esta sección se describirá a grandes rasgos, desde una perspectiva de alto nivel,
el funcionamiento del sistema. Dicha descripción mostrará asimismo la relación entre los
sistemas que este Proyecto propone y la infraestructura software de la que se parte, tanto
Weblab-Deusto como Boole-Deusto.
Una descripción más técnica del funcionamiento de cada característica se encontrará en
secciones posteriores. Para que el ámbito del proyecto sea más abarcable y comprensible, este apartado se divide en tres distintos, que no obstante están muy relacionados
entre sí.
23
Figura 3.4.: Elementos principales del sistema desde el punto de vista del usuario
En la Fig. 3.4 se muestra un diagrama que refleja los elementos principales relacionados
con el proyecto. Considerando que la implementación es notablemente compleja, este
diagrama general se limita a mostrar el funcionamiento de los sistemas desde un punto
de vista cercano al usuario. Asimismo, para facilitar su comprensión podemos dividir el
sistema en tres áreas:
Diseño y generación de código: La que involucra a Boole-Deusto, al diseño con él
de sistemas digitales, y la generación de código VHDL compatible con WebLab.
24
Sintetización a partir del código VHD: Lo que, en WebLab-Deusto, supone la generación del archivo binario BITSTREAM (grabable en la placa física) a partir simplemente del código VHDL.
Modelización Virtual: Lo que respecta, en WebLab-Deusto, a la creación de la infraestructura necesaria para incorporar realidad mixta a experimentos electrónicos,
y a la creación de tales experimentos.
3.2.1 Diseño y generación de código (Boole-Deusto)
Vemos en la parte superior de la Fig. 3.4 que el flujo de trabajo del usuario comienza, en principio, en Boole-Deusto. Es importante remarcar que si bien un flujo de trabajo completo comenzaría en efecto aquí, WebLab-Deusto y las facilidades referentes
a sintetización de archivos y experimentación remota con placas físicas pero modelos
virtuales pueden ser sin ningún problema utilizadas independientemente. Es decir, los
usuarios pueden codificar a mano el archivo VHDL, sin utilizar Boole-Deusto, y utilizarlo
en Weblab-Deusto.
Como podemos observar, el usuario comenzaría diseñando un sistema digital en BooleDeusto. Las facilidades de diseño de sistemas digitales de Boole-Deusto, en general, no
recibirán modificaciones notables por parte de este proyecto.
Una vez que el sistema digital esté diseñado, el usuario podrá generar automáticamente
el código VHDL correspondiente, compatible con Weblab. Esta es una capacidad que
actualmente Boole-Deusto no posee, y que deberá ser incorporada durante el proyecto.
También se incorporarán las modificaciones necesarias, que den al usuario de BooleDeusto el control suficiente sobre el proceso.
Éstas suponen, principalmente:
Capacidad en sistemas combinacionales de asignar entradas y salidas con nombres específicos, correspondientes al experimento de Weblab-Deusto (necesario
para la compatibilidad del código generado con el UCF interno del experimento –
esto se describe en más detalle en secciones posteriores). De este modo el usuario no tendrá necesidad de conocer o recordar nombres para que sus programas
funcionen.
Capacidad en sistemas combinacionales de generar código VHDL compatible con
el experimento Weblab-Deusto-FPGA, que se limite a las entradas y salidas anteriormente mencionadas y que incluya el encabezamiento necesario para que no se
requieran modificaciones manuales del código.
Capacidad en sistemas secuenciales (autómatas) de elegir el reloj a utilizar. En
Weblab-Deusto-FPGA existen varios relojes disponibles, incluyendo un reloj interno, un reloj externo, y un reloj controlado manualmente por un interruptor (para
depuración).
Capacidad en sistemas secuenciales (autómatas) de generar código VHDL compatible con el experimento Weblab-Deusto-FPGA, que convierta de forma automática
25
las entradas / salidas típicas de un autómata a entradas compatibles, y que incorpore al código directivas propias específicas que permitan al servidor distinguir el
tipo de reloj que el usuario desea.
Una vez que Boole-Deusto ha generado el código VHDL compatible con Weblab-Deusto,
el usuario podrá pulsar el botón adecuado, y se abrirá un navegador web que les lleve
directamente al experimento en Weblab-Deusto. Por lo que a Boole-Deusto respecta, sólo
restará entonces seleccionar el archivo VHDL que se ha generado y reservar con él el
experimento del laboratorio remoto que se muestre en el navegador. Con esto, podemos
considerar que las responsabilidades de la parte de Boole-Deusto habrán acabado (por
supuesto, el usuario podrá seguir modificando y probando libremente el sistema, pero en
lo referente al sistema descrito por este proyecto, el proceso será exactamente el mismo).
En este punto, podemos considerar que nos encontramos en el punto intermedio de la
Fig. 3.4. Tenemos ya un archivo VHDL, y podemos subirlo a Weblab-Deusto.
3.2.2 Sintetización
En la Fig. 3.5 se muestra el proceso básico que los servidores de WebLab llevarán acabo. Cuando Weblab-Deusto-FPGA reciba un archivo VHDL, procederá a sintetizarlo. El
proceso de sintetización es aquel en el cual, partiendo del código fuente, se obtiene tras
varios pasos un archivo BITSTREAM, que es una descripción binaria de bajo nivel del
sistema, y que puede ser grabada directamente en una placa hardware.
En este proceso interviene también un archivo UCF (User Constraints File). Este archivo
define la correspondencia entre entradas y salidas lógicas (descritas en el VHDL) y entradas y salidas físicas (pines en la placa hardware en la que será grabado el programa
sintetizado). Como vemos en la Fig. 3.4 y en la Fig. 3.5, será Weblab-Deusto el que provea el UCF adecuado, que podrá ser uno u otro dependiendo de las circunstancias (que
se detallan en la sección técnica).
Figura 3.5.: Diagrama conceptual básico del proceso de sintetización en los servidores de
WebLab-Deusto
En este proceso, el servidor de Weblab-Deusto hará uso de herramientas provistas por
Xilinx. Podemos diferenciar dos conjuntos de herramientas. Las primeras, de sintetización, son las necesarias para realizar todos los pasos que convierten de .VHD (VHDL)
a .BIT (BITSTREAM), usando el UCF., Las segundas, de grabación, son sencillamente
26
las necesarias para una vez que se tiene el BITSTREAM, grabarlo en la placa física. El
segundo grupo funciona ya en Weblab-Deusto. El primero será integrado durante el desarrollo de este proyecto, añadiendo con ello a Weblab-Deusto la capacidad de sintetizar
VHDL por su cuenta.
Para esto, será necesario:
Diseñar e implementar una interfaz de integración que permita a los servidores de
WebLab-Deusto-FPGA controlar los programas de línea de comando de Xilinx, de
tal forma que sea a la vez seguro y confiable.
Desplegar las herramientas de Xilinx de línea de comandos en los servidores de
Weblab-Deusto-FPGA, de tal modo que la capa de integración pueda hacer uso de
ellas.
Realizar las modificaciones oportunas a Weblab-Deusto-FPGA, para que permita
añadir un paso anterior completamente nuevo a su flujo de trabajo (el proceso de
sintetización).
Una vez realizados los pasos anteriores, el sistema tendrá la capacidad de no sólo grabar
en la placa física archivos BITSTREAM, sino generar los propios BITSTREAM a partir de
sólo código.
Las ventajas de esto son múltiples para los usuarios. El proceso de generación de un
BITSTREAM compatible con las placas concretas de Weblab-Deusto es complicado. Requiere software de Xilinx específico, con unos requisitos notablemente altos (ocupa más
de 6 gigabytes, y necesita registro), y además se necesita una configuración específica,
adaptada al modelo concreto de placa que utiliza WebLab-Deusto.
Tras implementar las características aquí descritas, el proceso para los usuarios pasa
a ser absolutamente transparente. Sólo necesitan crear el código fuente VHDL. Todo lo
demás lo realiza WebLab-Deusto.
3.2.3 Modelización Virtual y Realidad Mixta
Una vez generado el archivo BITSTREAM, Weblab-Deusto, como ha sido mencionado,
graba el programa en la placa física y permite al usuario ver e interactuar con dicha placa
física. Es aquí donde entran las características de realidad mixta que también propone
este proyecto.
Durante este proyecto, se dotará a WebLab-Deusto de las infraestructuras genéricas
que requiere para poder crear fácilmente experimentos electrónicos con la capacidad de
mostrar, además de la placa física real, un modelo virtual, con el que la placa puede
interactuar.
Para ello, serán necesarias bastantes extensiones a la infraestructura existente. Como
se detallará más adelante, se añadirá en primer lugar soporte para crear experimentos
basados en JavaScript en HTML5. De este modo, será posible crear experimentos que
27
hagan uso de tecnologías como WebGL para mostrar los gráficos requeridos y ser lo
suficientemente inmersivos.
Asimismo, se añadirán facilidades para
que dichos experimentos puedan ser creados de forma consistente, sin necesidad
(o limitando al máximo) de recompilaciones.
Una vez que estén incorporadas las infraestructuras genéricas necesarias, se procederá al diseño e implementación de un
experimento concreto. Es decir, de una variación de Weblab-Deusto-FPGA mediante la que el usuario pueda definir un programa que se ejecute en una placa real
y que pueda controlar con ella un modelo virtual. Muy probablemente, este primer experimento consistirá en un depósito de agua, como el que se muestra en la Figura 3.6.: Tanque de agua virtual: Ejemplo
de un posible modelo (sólo el moFig. 3.6. Cabe notar que dicha figura sólo
delo)
1
muestra el modelo, no todo el experimento .
El usuario controlará mediante la placa dos bombas de agua que alimenten el depósito
de agua. Asimismo, el depósito dispondrá de una salida de agua, que representará la
demanda. Dicha demanda será variable, y parcialmente aleatoria, simulando así un sistema real. El cometido del usuario sería, evidentemente, diseñar un sistema para FPGA,
en VHDL, para controlar dicho depósito, recibiendo como entrada el estado de varios
sensores de nivel, con el objetivo de mantener el nivel de agua constante dentro de un
rango adecuado. (Evitando un nivel demasiado bajo, y evitando al mismo tiempo desbordamientos).
Una vez creadas las infraestructuras genéricas necesarias y el primer experimento, el
objetivo es, sin embargo, que sea notablemente más sencilla la creación de experimentos
adicionales. Si bien, por supuesto, será inevitable que siga siendo necesario crear los
modelos gráficos para dichos experimentos, así como la lógica de cada simulación.
3.3 PRODUCTOS FINALES
Tras el desarrollo del proyecto se obtendrán:
Productos del desarrollo:
Versión de Boole-Deusto con las capacidades descritas. Entre otras, la integración
con WebLab-Deusto, la generación de código VHDL directamente compatible, el
1
La clave del sistema es precisamente que existe un componente real (la placa FPGA) y un componente
virtual (el modelo), que interactúan en ambos sentidos. Puede verse en la Fig. 3.3.
28
modo WebLab para elegir entre la lista de entradas/salidas, etc.
WebLab-Deusto mejorado con las capacidades descritas. Entre otras, la capacidad
de sintetizar código VHDL, de soportar servidores de experimentos en JavaScript,
de soportar clientes de experimentos en JavaScript, así como la infraestructura necesaria para crear experimentos con realidad mixta de forma sencilla, utilizando
nuevas tecnologías Web como WebGl.
Experimento FPGA-Watertank, primer experimento con realidad aumentada, que
utiliza la infraestructura anteriormente creada, y que puede servir de base para el
desarrollo de experimentos posteriores.
Productos documentales:
Guía de usuario de Boole-WebLab-Deusto: Descripción de cómo usar BooleWebLab-Deusto, describiendo la manera de crear y probar tanto autómatas como
sistemas combinacionales.
Guía del experimento FPGA Watertank: Explica cómo usarlo, en qué consiste,
cuáles son sus entradas y salidas, etc.
Guía de desarrollador de Boole-Deusto: Breve guía dirigida a orientar a nuevos
desarrolladores de Boole-Deusto, que recopile los problemas y soluciones encontrados durante éste proyecto (durante el cual no existía documentación de BooleDeusto disponible).
Otros:
Plan de negocio: Posible plan de negocio para una empresa basada en proporcionar a centros formativos servicios de experimentación remota.
3.4 REQUISITOS
En esta sección se especificarán los requisitos más importantes del sistema. Dada la
naturaleza del proyecto, dicha lista no pretende ser necesariamente exhaustiva.
3.4.1 Principales requisitos funcionales
1. En la parte combinacional de Boole-Deusto se permitirá al usuario cambiar a un
modo WebLab, donde pueda definir las entradas y salidas de su sistema fácilmente,
según una lista de entradas y salidas predefinidas compatibles.
2. En la parte combinacional de Boole-Deusto si el modo WebLab está desactivado
se generará código VHDL genérico pero sintácticamente correcto.
3. En la parte combinacional de Boole-Deusto si el modo WebLab está activado se
generará código VHDL directamente compatible con WebLab-Deusto.
4. En la parte combinacional de Boole-Deusto, puede abrirse WebLab-Deusto-FPGA
en un navegador con una sola operación.
29
5. En la parte secuencial (autómatas) de Boole-Deusto el sistema permitirá generar
código VHDL directamente compatible con WebLab.
6. En la parte secuencial (autómatas) de Boole-Deusto el sistema permitirá elegir el
reloj entre los siguientes: Interno, WebLab, Interruptor, Switch.
7. En la parte secuencial (autómatas) de Boole-Deusto podrá abrirse WebLab-DeustoFPGA en un navegador con una sola operación.
8. Boole-Deusto permitirá acceder a ayuda específica tanto en el modo secuencial
como en el combinacional.
9. Los servidores de WebLab-Deusto podrán sintetizar código VHDL a partir de la
fuente VHDL y de un archivo UCF.
10. El experimento WebLab-Deusto-FPGA admitirá como entrada código VHDL, además de seguir admitiendo un archivo binario BITSTREAM.
11. El experimento WebLab-Deusto-FPGA y todos los basados en Xilinx guardarán el
estado de los interruptores, y soportarán comandos que permitan al cliente obtenerlos.
12. El experimento WebLab-Deusto-FPGA y todos los basasados en Xilinx permitirán
cambiar programáticamente las entradas a la placa, de tal forma que sea posible
transmitir con ello la información de los sensores virtuales de los modelos virtuales.
13. El experimento WebLab-Deusto-FPGA se modificará para permitir la cohexistencia
con modelos virtuales, cuyo estado sea obtenible a los clientes de experimentos a
través del comando VIRTUALWORLD_STATE.
14. Se soportará Javascript como nueva tecnología para crear experimentos en el lado
del cliente.
15. Se permitirá definir un nuevo experimento cliente en JavaScript a través de un archivo JS o de un simple HTML.
16. El sistema dispondrá de una API WeblabJS para ser utilizada en los clientes JavaScript, y que encapsule toda la comunicación con WebLab.
17. El sistema dispondrá de una infraestructura basada en ThreeJS que permita definir
fácilmente (a través de una definición basada en JSON) una escena tridimensional.
18. Se ofrecerán controles JavaScript comunes (LEDs, interruptores, botones…) para
poder crear rápidamente clientes JavaScript de experimentos.
19. El sistema ofrecerá un cliente JavaScript de WebLab-Deusto-FPGA.
20. WebLab-Deusto-FPGA reconocerá mediante visión artificial el estado de los LEDs
físicos de la placa, y permitirá su consulta a los clientes.
21. El sistema ofrecerá un experimento FPGA-Watertank, que permita al usuario controlar un tanque de agua virtual con la placa física real.
30
22. El sistema permitirá definir servidores de experimento en JavaScript utilizando NodeJS.
3.4.2 Principales requisitos no funcionales
1. Boole-Deusto debe ser capaz de soportar al menos los idiomas español, inglés y
euskera.
2. Boole-Deusto en todas sus interfaces debe ser capaz de soportar sin problemas los
nuevos nombres de entradas y salidas, notablemente largos.
3. En la parte combinacional de Boole-Deusto el sistema cambiará del modo WebLab
al modo estándar sin pérdida de información.
4. Tanto en la parte secuencial como en la combinacional, al tratar de abrir WebLabDeusto-FPGA, se advertirá si previamente no ha sido generado código VHDL compatible, y en tal caso se dará la opción de generarlo.
5. No se requerirán compilaciones en el cliente para crear o configurar un nuevo experimento JavaScript.
6. No se requerirán compilaciones en el servidor para crear o configurar un nuevo
experimento basado en JavaScript y NodeJS.
7. Se permitirá definir el tamaño por defecto del iframe de los experimentos JavaScript
en la configuración del cliente.
8. Se soportará pantalla completa en los clientes de experimentos JavaScript (utilizando HTML5) mejorando así la experiencia del usuario.
9. Se permitirá aceleración gráfica 3D (utilizando WebGL) en los experimentos JavaScript, para permitir gráficos complejos con rendimiento aceptable.
10. Se permitirá gráficos basados en Canvas (compatible con más plataformas, pero
no acelerado) en los experimentos JavaScript, para permitir realizar experimentos
compatibles con más sistemas.
3.5 MÉTODO DE DESARROLLO
Como puede observarse, el proyecto es relativamente complejo. Para facilitar su desarrollo y seguimiento, se dividirá en fases. Esto se ve favorecido por el hecho de que, si bien
su ámbito es extenso, se puede dividir de forma conveniente en partes relacionadas pero
bastante independientes en cuanto a funcionamiento. Aunque dichas fases no tendrían
por qué ser necesariamente secuenciales, y con el equipo adecuado algunas de ellas
podrían llevarse a cabo en paralelo, en la práctica se realizarán secuencialmente.
El objetivo es, tras cada fase, disponer de un resultado tangible útil. 31
3.6 FASES DEL PROYECTO
Se describe en esta sección cada fase, tal y como se planificaron al inicio del proyecto.
Cabe notar que en el momento de realizar tal planificación ciertos aspectos aun no habían
podido ser definidos en detalle, y no están recogidos en esta sección sino en capítulos
posteriores.
Figura 3.7.: Fases planificadas para el proyecto
3.6.1 Fase 1: Diseño preliminar del sistema
Durante esta fase se diseñarán, de forma no demasiado detallada, las mejoras y desarrollos que definirán el proyecto, así como la forma general mediante la cual serán llevadas
a cabo. Durante la fase se definirán también los requisitos del sistema final.
En este momento, aun no se contará con demasiada información. Siendo así, probablemente no será aun conocida totalmente la extensión de los errores a solucionar en
Boole-Deusto. Tampoco, el diseño preciso de los experimentos electrónicos con realidad
aumentada que se pretenden desarrollar y añadir a WebLab-Deusto, o siquiera las tecnologías que serán elegidas para ciertas tareas (posibles librerías de procesamiento de
imagen, de gráficos, de realidad aumentada, etc).
Por este motivo, es importante resaltar que esta fase sólo implicará un diseño preliminar,
a grandes rasgos, del sistema, que será posteriormente detallado durante la ejecución
del proyecto.
3.6.2 Fase 2: Mejoras y ampliaciones de Boole-Deusto
Durante esta fase se aplicarán las actualizaciones y correcciones de errores a BooleDeusto.
Se pondrá especial énfasis en aquellas áreas de Boole-Deusto que muestren actualmente ciertas deficiencias, así como en rediseñar aquellas áreas que vayan a ser necesarias
en fases posteriores. Esto incluye especialmente el sistema de lenguajes y traducciones
(que deberá ser actualizado) y el sistema de generación de código (que será rediseñado
para solucionar ciertos errores conocidos y poder ser extendido en fases posteriores con
diferentes tipos de VHDL compatible con WebLab-Deusto).
32
3.6.3 Fase 3: Implementación de conectividad Boole-Deusto – Weblab-Deusto
Durante esta fase se dotará de una mayor conectividad a los dos software relacionados
con el proyecto, Boole-Deusto y WebLab-Deusto.
El objetivo concreto de esta fase es que el flujo de trabajo en ambos sistemas quede
integrado de forma satisfactoria para el usuario (en el ámbito de los experimentos electrónicos con relación a Boole-Deusto). Se aplicarán durante esta fase aquellas mejoras y
desarrollos necesarios para que un circuito lógico en Boole-Deusto pueda, de forma sencilla y tan automática como sea posible, ser grabado físicamente en un FPGA o similar y
probado por el usuario, mediante las facilidades que aporta WebLab-Deusto.
De esta forma, al terminar esta fase, el usuario podrá construir su circuito lógico en BooleDeusto mediante cualquiera de los métodos que éste ofrece. Se soportarán los dos tipos disponibles de circuitos: combinacionales y secuenciales. Una vez construido, podrá,
desde el mismo Boole-Deusto, generar el código VHDL que corresponde al circuito para
un dispositivo FPGA. Dicho código VHDL estará perfectamente adaptado a WebLab, de
tal modo que no se requiera ninguna modificación manual.
Una vez generado el VHDL el usuario podrá, desde Boole-Deusto, pasar al experimento
correcto de WebLab-Deusto, que recibirá su código VHDL. WebLab-Deusto entonces
sintetizará el código VHDL que ha recibido, generando una descripción binaria (.bit), que
procederá a grabar en la placa FPGA. El usuario podrá entonces interactuar con esa
placa, como lo haría de forma normal en WebLab-Deusto.
Para lograr esto, durante esta fase se realizarán modificaciones y extensiones tanto a
Boole-Deusto como a WebLab-Deusto. En concreto, dichas modificaciones y extensiones
incluyen, pero no se limitan a:
Extensiones de la interfaz de Boole-Deusto para soportar las nuevas funcionalidades de conectividad. o Al modo combinacional: selección de nombres de entradas
y salidas, generación de código, etc. o Al modo secuencial: selección de tipo de
reloj para el autómata, generación de código, etc.
Extensiones de Boole-Deusto para soportar la conectividad con WebLab-Deusto, y
ser en concreto capaz de conectarse a un usuario (por decidir durante esta fase,
si se requerirá autenticación del usuario, o si esta será sólo opcional), reservar el
experimento apropiado (FPGA o similar) y enviar el código VHDL generado por
Boole-Deusto para ser grabado.
Extensiones a WebLab-Deusto para soportar las peticiones por parte de BooleDeusto. A determinar durante esta fase qué clase de modificaciones son necesarias. Se espera que sean pocas.
Extensiones a WebLab-Deusto para soportar la compilación de archivos VHDL (con
su correspondiente archivo UCF) a los archivos BITSTREAM grabables en los dispositivos. Para ello, se necesitará utilizar e interactuar con software de Xilinx.
33
3.6.4 Fase 4: Implementación de experimentos electrónicos mediante realidad aumentada
Como ha sido mencionado en apartados anteriores de este documento, un tipo común y
muy utilizado de experimento en WebLab-Deusto es aquel que permite al usuario grabar
un programa de alguna clase en una placa con un dispositivo, interactuar con dicha placa
y por tanto con el programa que ha grabado, y observar los resultados de su interacción
en tiempo real a través de una Webcam.
Dichas placas contienen dispositivos tales como microprocesadores PIC, dispositivos FPGA (Field Programmable Gate Array) o dispositivos PLD. Suelen también contener interruptores y pulsadores como entradas, controlables remotamente (para poder interactuar
de alguna forma con la placa), y LEDs como salida (para poder ver los resultados de dicha
interacción a través de la Webcam).
Durante esta fase se añadirán experimentos que utilicen técnicas de realidad aumentada
para potenciar clases de interacción más complejas. De este modo, las salidas físicas,
que en la actualidad son simples LEDs, pasarán a poder afectar también a elementos
virtuales, que a su vez tendrán también la capacidad de afectar a las entradas.
De este modo, un LED encendido podrá ser interpretado por el modelo virtual como una
entrada (por ejemplo, una entrada que le dice que accione una bomba de agua). El modelo virtual a su vez podrá actuar como entrada a la placa reemplazando a los interruptores
controlables por el usuario remoto de los que dichas placas ya disponen. De este modo,
el modelo virtual podrá disponer, por ejemplo, de varios sensores virtuales de nivel de
agua, que físicamente introducirán su valor en la placa hardware como entradas.
Esto permitirá crear una realidad mixta, en la que el usuario, mediante un programa y una
placa real, ejecutado en un dispositivo físico, pueda resolver problemas e interaccionar
en general con elementos virtuales potencialmente complejos y variados.
De este modo, si el modelo virtual representa, por ejemplo, un tanque de agua, el usuario
podrá diseñar el sistema que lo controle. Dicho sistema se ejecutará en condiciones totalmente realistas (en una placa hardware real), pero dicha placa no controlará un depósito
real sino el depósito virtual.
Esto permite soportar de forma notablemente realista (el modelo es una simulación, pero
la placa controladora es absolutamente real) experimentos complejos muy cercanos a
aplicaciones reales (como podrían ser un depósito de agua, una línea de producción o
el embalse de una central hidroeléctrica), que por motivos prácticos y económicos serían a menudo inviables de otro modo. En esta fase se diseñará y creará la arquitectura
necesaria para dar soporte a este tipo de experimentos, y facilitar su creación.
El diseño de los experimentos concretos que serán también implementados en esta fase
no es aun conocido, y se llevará a cabo al inicio de la fase. Posiblemente, si en dicha
fase de diseño se considera apropiado y se desarrolla la idea, se incluirán experimentos
tales como el del control del nivel de agua de un depósito, mencionado anteriormente. En
tal experimento, el usuario programaría el comportamiento del controlador del depósito
en el FPGA. De este modo, el usuario resolvería el problema en una realidad mixta. El
34
controlador (la placa con el FPGA o similar) sería absolutamente real (el programa se
grabaría en la placa físicamente), pero las salidas (LEDs, normalmente) y las entradas
(los interruptores) afectarían a un modelo virtual de un depósito de agua.
Este experimento (y similares) permite un gran nivel de realismo (ya que el controlador,
que es la parte más significativa desde el punto de vista del aprendizaje de control, es
un FPGA real), y al mismo tiempo es económico (un experimento que permita el control
de un depósito de agua real sería mucho más costoso, demasiado específico en cuanto
a su propósito, e incluso algo limitado, ya que posiblemente en ningún caso se podría
permitir, de forma segura, el desbordamiento del depósito, o el uso de las bombas en
ciertas circunstancias).
Mediante realidad mixta, en definitiva, se pueden implementar experimentos variados,
prácticos, interesantes para el profesor y el estudiante, y a la vez económicos (ya que no
requieren equipamiento físico adicional, y las placas FPGA pueden ser utilizadas para
cualquier tipo de experimento y compartidas por cualquier modelo virtual en el que estén
basados).
Al final de esta fase, WebLab-Deusto estará dotado de facilidades genéricas (clases,
librerías, ejemplos, etc) para poder añadir la realidad mixta descrita a los experimentos.
Asimismo, existirá al menos un ejemplo de un experimento de esta clase, utilizando realidad mixta. Muy probablemente, será una variación del experimento actual FPGA, utilizando esta misma placa y los LEDs de salida como entrada para el sistema virtual. La
naturaleza exacta y diseño de dicho experimento, será determinada durante esta misma
fase.
3.6.5 Fase 5: Pruebas, usabilidad e integración
Llegada a esta fase, la mayor parte del desarrollo habrá sido realizada, y habrán sido realizadas ya pruebas satisfactoriamente de las fases de implementación anteriores.
Durante esta fase, se probará el flujo de trabajo que aporta el proyecto como un todo.
Es decir, se comprobará que un usuario puede recorrer de forma completa, usable y
satisfactoria el flujo de trabajo propuesto.
Si bien las pruebas exactas serán determinadas durante la misma fase, las pruebas incluirán al menos, aunque no se limite sólo a ello, un usuario que parta de una tabla de
verdad diseñada en papel, que deberá ser reconocida por Boole-Deusto (según mejoras
de fase 2), pasada automáticamente a WebLab-Deusto y compilada (fase 3) y aplicada
en un experimento dotado de realidad aumentada como el descrito anteriormente (fase
4).
Si se encontrasen fallos o carencias de diseño, programación o usabilidad serían corregidos durante esta fase.
35
3.6.6 Fase 6: Implantación en producción
En esta fase se actualizarán los servidores de WebLab-Deusto en producción, aplicando
los cambios y aportaciones del proyecto. Se modificará además su configuración de tal
forma que los nuevos experimentos con realidad mixta o aumentada provistos pasen a
estar disponibles a los usuarios y estudiantes.
Se incluirán en este apartado aquellas tareas de prueba orientadas a garantizar el correcto funcionamiento en producción del sistema en general y de los nuevos experimentos
en particular, así como las subsiguientes correcciones, en caso de probarse necesarias.
3.7 TAREAS PRINCIPALES
En esta sección se detallarán las diferentes tareas que conformarán el proyecto. Se detallarán asimismo las responsabilidades del equipo del proyecto.
1. Organización y control
1.1. Organización: Actividad para definir y preparar la planificación y lanzar el proyecto.
1.2. Seguimiento: Control del desarrollo del proyecto, con el propósito de detectar
rápidamente los problemas e imprevistos que puedan surgir y solucionarlos sin
tardanza.
2. Requisitos del sistema
2.1. Análisis de necesidades y requisitos: Teniendo en cuenta el estado de BooleDeusto y las capacidades de WebLab-Deusto, se definirán los requisitos del sistema que sean apropiados para los objetivos del proyecto, y que sean alcanzables
con el tiempo y recursos disponibles.
2.2. Elaboración del documento de requisitos: Conocidos los requisitos del sistema, se definirán formalmente a grandes rasgos para formar el documento de
requisitos.
3. Diseño preliminar
3.1. Revisión de requisitos: Se revisarán los requisitos, corrigiendo aquellos errores o carencias que se encuentren.
3.2. Elaboración del diseño preliminar: Se diseñará a grandes rasgos el sistema,
y la forma (sin detalles) mediante la que se lograrán los objetivos especificados.
Puesto que en el momento de llevar esto a cabo la información disponible será
incompleta, no será un diseño detallado. El diseño detallado se llevará a cabo en
actividades posteriores.
4. Correcciones, cambios y mejoras a Boole-Deusto
36
4.1. Detección de errores y carencias de Boole-Deusto: Se revisará Boole-Deusto
en detalle, encontrando aquellos errores que sean relevantes para el proyecto. Se
comprobará el flujo de trabajo propuesto por el proyecto, y se verificará si existen
carencias, defectos o posibles mejoras al respecto.
4.2. Análisis del entorno de desarrollo de Boole-Deusto: Se analizará cuán antiguo es el entorno de desarrollo de Boole-Deusto (que fue creado en una versión
particularmente antigua de Borland C++ Builder). En caso de que el entorno original presente posibles problemas para la posterior codificación de mejoras (como
parece ser el caso) se considerarán posibles entornos más modernos a los cuales
actualizar Boole-Deusto. Por regla general, cuanto más moderno sea el entorno
objetivo más difícil será actualizarlo, pero más sencillo y conveniente será después el desarrollo en dicho entorno. En este análisis, se tratará de encontrar el
entorno objetivo más adecuado, teniendo en cuenta estos hechos.
4.3. Actualización de Boole-Deusto a un entorno de desarrollo más moderno: Se
actualizará el código de Boole-Deusto, para hacerlo compatible con un entorno
más moderno (como podría ser una versión más moderna de Borland C++ Builder, o una versión, aun más moderna, de Embarcadero C++ Builder). La versión
objetivo adecuada se habrá decidido en actividades precedentes.
4.4. Corrección de errores de Boole-Deusto: Se codificarán las soluciones a los
errores encontrados, y se solucionarán, dentro de lo posible, las carencias encontradas en el flujo de trabajo.
4.5. Actualización del sistema de traducciones: En el momento actual, el sistema
de traducciones no funciona, ya sea por el uso de un sistema operativo moderno
o porque la única versión del código disponible no es la correcta. Se restaurará
o reconstruirá el sistema de traducciones, para permitir incorporar traducciones
nuevas tras realizar las modificaciones descritas en este proyecto.
4.6. Pruebas (Boole-Deusto): Se comprobará que le funcionamiento de BooleDeusto, tras aplicar sus actualizaciones, mejoras y nuevas características, sea el
que se espera. En caso de no serlo, se corregirán los errores o carencias encontrados.
4.7. Documentación de Usuario (Boole-Deusto): Se actualizará el manual de usuario de Boole-Deusto incorporando instrucciones para poder conocer y hacer uso
de las nuevas características.
4.8. Documentación de Desarrollador (Boole-Deusto): Actualmente, no existe ninguna documentación orientada a desarrolladores de Boole-Deusto. Se creará una
pequeña documentación introductoria, de tal forma que en el futuro se facilite el
posible mantenimiento o extensiones adicionales, poniendo especial énfasis en
aquellos aspectos, como el sistema de lenguaje, que debidos a la antigüedad del
sistema presenten características y limitaciones poco previsibles.
5. Conectividad entre Boole-Deusto y WebLab-Deusto
5.1. Análisis de tecnologías Xilinx: Se analizarán las tecnologías Xilinx para Win-
37
dows y Linux que permitan la compilación programática (mediante línea de comandos) de fuentes VHDL para dispositivos específicos. Se documentarán los
programas y comandos necesarios para lograr este cometido.
5.2. Diseño y codificación de sistema remoto de compilación de archivos VHDL
para WebLab-Deusto: Utilizando la información obtenida mediante actividades
precendentes, y los programas provistos por Xilinx, se diseñará y codificará bajo
la infraestructura de WebLab-Deusto un sistema que haga posible que WebLabDeusto reciba un archivo VHDL y lo compile, usando un archivo UCF propio, al
formato BITSTREAM. Esto permitirá la posterior grabación en un dispositivo tal
como un FPGA.
5.3. Modificación de la interfaz de usuario de Boole-Deusto: Se modificará la interfaz de usuario de Boole-Deusto para que sea posible (y cómodo para el usuario) probar los circuitos lógicos en WebLab-Deusto, de manera tan automática y
transparente como sea posible. Se tendrá muy en cuenta la usabilidad.
5.4. Codificación de la conectividad Boole-Deusto – WebLab-Deusto: Se codificarán aquellos cambios y mejoras al código de Boole-Deusto que sean precisas
para implementar la funcionalidad que las nuevas funcionalidades requieren. Se
determinará si se requieren también modificaciones a este respecto en el código
de WebLab-Deusto. En caso afirmativo, se codificarán también dichas modificaciones.
5.5. Pruebas (Conectividad): Se comprobará que las modificaciones realizadas
tanto a Boole-Deusto como a WebLab-Deusto no hayan introducido errores, funcionen como se espera, y posean una alta usabilidad desde la perspectiva del
usuario. En caso de encontrarse errores o carencias, se solventarán tomando las
medidas necesarias.
5.6. Documentación (Conectividad): Se modificará la documentación (manual de
usuario) de Boole-Deusto para incluir las nuevas capacidades del programa. Se
modificará también la documentación de desarrollo de WebLab-Deusto, en caso
de ser preciso, así como la documentación de usuario de WebLab-Deusto (una
wiki) de nuevo, en caso de ser preciso.
6. Experimentos electrónicos con realidad aumentada en WebLab-Deusto
6.1. Análisis de tecnologías y librerías relevantes de realidad aumentada y gráficos: Se analizarán las tecnologías y librerías actualmente disponibles. Se evitarán
en cualquier caso tecnologías y librerías de pago, favoreciendo aquellas con licencias libres. Se tratará de encontrar la tecnología o librería más adecuada para los
propósitos del proyecto. Idealmente, la tecnología que finalmente resulte elegida
deberá ser lo suficientemente madura para ser usada en un entorno de producción, lo suficientemente bien diseñada y documentada para que su empleo sea
relativamente sencillo para los desarrolladores y para que se minimice el tiempo
de desarrollo, y lo suficientemente potente como para ofrecer las características
(afortunadamente no demasiado avanzadas) que el proyecto requiere.
38
6.2. Diseño e implementación infraestructura de modelización virtual: Se diseñara e implementará la infraestructura necesaria para poder implementar de forma
sencilla experimentos dotados de modelización virtual y realidad mixta. Dicha infraestructura será tan genérica y reutilizable como sea posible, de tal modo que
partiendo de ella resulte sencillo crear diversos experimentos, con modelos virtuales distintos. Para esto, se implementará una infraestructura que permita la creación rápida de experimentos mediante JavaScript, tanto para el lado del cliente
como para el lado del servidor, o en tecnologías similares.
6.3. Diseño conceptual de nuevo experimento con realidad mixta: Se diseñará un
nuevo experimento basado en el dispositivo FPGA, que se base en una realidad
mixta. El diseño se adaptará a las capacidades que la tecnología de realidad
aumentada y de gráficos elegida en actividades precedentes ofrezca. Se tratará
de que el experimento diseñado no sea excesivamente complejo. En principio,
dicho experimento consistirá en un tanque de agua virtual controlable mediante
una placa FPGA real.
6.4. Diseño de implementación de nuevo experimento con realidad mixta: Se diseñará la implementación del experimento con realidad mixta diseñado conceptualmente en actividades precedentes. Dicho diseño será tan genérico como sea
posible, de tal forma que sea al menos en parte reutilizable para experimentos
futuros de características similares.
6.5. Codificación (de experimento): Se codificará la infraestructura genérica de
WebLab-Deusto requerida para la creación de experimentos con realidad mixta,
diseñada en actividades precedentes. A continuación, se codificará el experimento concreto diseñado también en actividades precedentes, que haga uso de dicha
infraestructura genérica y que además de ser útil por sí mismo pueda servir como
ejemplo y prueba de concepto para posteriores desarrollos relacionados.
6.6. Documentación (de realidad mixta): Se documentará la nueva infraestructura
de realidad mixta, para facilitar el futuro desarrollo de experimentos relacionados
que la utilicen. Se documentará, asimismo (por separado, en la wiki de usuario
de WebLab-Deusto) el funcionamiento del nuevo experimento.
6.7. Pruebas (de realidad mixta): Se comprobará que la nueva infraestructura de
realidad mixta funcione adecuadamente, y esté diseñada e implementada correctamente, de tal forma que pueda ser usada para desarrollos futuros relacionados.
En caso de encontrarse deficiencias en su diseño o implementación, se llevarán
a cabo las correcciones oportunas, que deberán ser reflejadas adecuadamente
en la documentación.
7. Pruebas, usabilidad e integración
7.1. Pruebas técnicas del flujo de trabajo del usuario: Se realizará el recorrido
completo por las características que el proyecto añade, desde la lectura de tablas
de verdad en papel mediante Boole-Deusto, hasta la conectividad con WebLabDeusto, y su uso en relación a el o los experimentos de realidad mixta creados. En
caso de encontrar errores o comportamientos indefinidos o inesperados, se toma-
39
rán las medidas adecuadas para corregirlos, realizando los cambios apropiados
a la documentación que corresponda.
7.2. Pruebas de usabilidad: Se comprobará que el sistema completo posea una
usabilidad adecuada desde el punto de vista del usuario. Se tratarán de realizar
pruebas de usabilidad con usuarios reales, y se tendrá en cuenta el feedback que
proporcionen. Se aplicarán las medidas oportunas para mejorar la usabilidad, en
caso de encontrar deficiencias.
7.3. Verificación de la documentación: Se comprobará que la documentación elaborada o modificada (ya sea la referente al manual de usuario de Boole-Deusto, la
documentación de desarrollo de WebLab-Deusto, o la documentación de usuario
de experimentos de WebLab-Deusto) sea adecuada. Se extenderá o corregirá en
caso de ser preciso. Para ello, se pedirá la opinión a usuarios reales.
8. Implantación en producción
8.1. Actualización de producción a nueva versión: Se actualizarán los servidores
de WebLab-Deusto a la nueva versión que incluya todos los cambios y nuevas
características realizados durante el proyecto.
8.2. Pruebas (producción): Se comprobará que, tras la actualización, el sistema
existente de WebLab-Deusto siga funcionando de la manera esperada. A pesar
de estar presentes en el código, las nuevas características no habrán sido aun
configuradas, y por tanto los usuarios no notarán (o no deberán notar) aun ninguna
diferencia con versiones anteriores de WebLab-Deusto, ni podrán aun acceder a
los nuevos experimentos.
8.3. Configuración de nuevos experimentos: Se añadirán los nuevos experimentos a la configuración de producción de WebLab-Deusto. Esta actividad incluye el
añadir los nuevos experimentos a la configuración del servidor de WebLab-Deusto
y a la configuración del cliente de WebLab-Deusto. Incluye también el añadir el
experimento, así como los permisos relacionados necesarios, a la base de datos
y a los usuarios adecuados (entre los que posiblemente se encuentre el usuario
de pruebas – accesible de manera pública).
8.4. Prueba de nuevos experimentos: Se comprobará que los nuevos experimentos hayan sido correctamente configurados, sean accesibles de la forma esperada
a aquellos usuarios o grupos de usuarios con los permisos requeridos, y se comporten de la forma esperada. En caso de detectarse anomalías, se tomarán las
medidas oportunas.
8.5. Pruebas extendidas: Estando los experimentos ya disponibles a la mayoría
de usuarios de WebLab (ya que, en principio, al menos uno de los experimentos
será públicamente accesible mediante el usuario de demostración) se observará
el comportamiento de los usuarios con el experimento, y se tratará de averiguar
su grado de satisfacción y opinión con respecto a los nuevos experimentos. En
caso de detectarse deficiencias, o en caso de ser propuestas mejoras razonables,
se tomarán las medidas oportunas.
40
3.8 ESTIMACIÓN DE TIEMPOS
Figura 3.8.: Trabajo estimado para cada tarea
41
Figura 3.9.: Horas de trabajo previstas para cada grupo de tareas (fases)
42
3.9 PROGRAMACIÓN TEMPORAL
Figura 3.10.: Diagrama de Gantt aproximado del proyecto
43
4. TECNOLOGÍAS
En esta sección se describirán aquellas tecnologías que intervienen en el desarrollo de
este proyecto. Dichas tecnologías incluyen especialmente, en primer lugar, al software
de diseño electrónico Boole-Deusto y al laboratorio remoto Weblab-Deusto.
Como se ha explicado en apartados anteriores de este documento, el proyecto está en
gran medida basado en estos dos software, y se compone principalmente de mejoras,
modificaciones y extensiones a éstos.
Si bien han sido descritos brevemente en secciones anteriores, en ésta se describirán de
forma más detallada y técnica. En caso de requerirse información adicional, se pueden
consultar también los anexos.
En esta sección también se describirán de forma breve las tecnologías hardware y software involucradas.
4.1 BOOLE-DEUSTO
4.1.1 Introducción
Boole-Deusto es un software para diseño electrónico. Ha sido desarrollado por estudiantes y profesores de la Universidad de Deusto como código abierto, y su primera versión
publicada data del año 2000.
Está diseñado como herramienta educativa. No obstante, a pesar de esto, abarca todo el
proceso de diseño. Al contrario que la mayoría de herramientas de estas características,
no se limita sólo a una parte específica.
De todos modos, Boole-Deusto no debería ser comparado con herramientas profesionales (como Proteus [36] o Electronics WorkBench [10]) ya que éstas suelen estar más
enfocadas en los circuitos finales a conseguir, y no tanto en el propio proceso.
Un aspecto reseñable de Boole-Deusto es que se centra únicamente en el proceso de
diseño. No es posible usar Boole-Deusto para ver cómo un sistema evoluciona a través
del tiempo. Todo lo relacionado con simulación ya está cubierto en profundidad por otras
herramientas.
Boole-Deusto, gracias probablemente a su facilidad de uso y a su potencial educativo,
ha sido descargado desde el 2003 miles de veces, por personas procedentes de prácticamente cualquier parte del mundo.
45
4. TECNOLOGÍAS
Figura 4.1.: Estadisticas de descarga de Boole-Deusto
En la Fig. 4.1 podemos ver las estadísticas de descarga de la web oficial de Boole-Deusto,
desde 2007 (no se disponen de datos anteriores). Además, existen páginas alternativas,
incluyendo, entre otras, la página del proyecto. La cuenta real de descargas será por
tanto ciertamente mayor.
4.1.2 Características
Los sistemas digitales pueden ser clasificados en dos grandes tipos, que son los que
Boole-Deusto soporta. Estos dos grandes tipos son: sistemas combinacionales y sistemas secuenciales.
Los sistemas combinacionales se caracterizan por ser más simples. No disponen
de memoria. Tienen un número definido de entradas y de salidas, y el valor de
las salidas depende directamente de las entradas (las salidas son, por tanto, una
“combinación” de las entradas).
Los sistemas secuenciales son más complejos. Son lo que se entiende tradicionalmente como autómatas. Conservan y dependen de un estado, que varía según
un reloj y según las entradas que recibe tras cada pulso.
Figura 4.2.: Clasificación de los circuitos digitales
46
Dependiendo de la complejidad de los circuitos, los circuitos digitales pueden alternativamente ser divididos en circuitos a nivel de bit, y circuitos a nivel de palabra. Boole-Deusto
está totalmente orientado a los primeros (circuitos a nivel de bit). En la Fig. 4.2 podemos observar un diagrama con la clasificación de los circuitos digitales. Boole-Deusto,
como se ha mencionado, soporta todos ellos, a excepción de los circuitos a nivel de palabra.
Es remarcable el hecho de que para proveer un soporte adecuado, Boole-Deusto está dividido en dos grandes modos. El primero está totalmente dedicado a los sistemas
combinacionales, y permite realizar el diseño completo, partiendo generalmente de una
tabla de verdad, pasando El segundo está dedicado a los sistemas secuenciales (autómatas).
4.1.3 Sistemas combinacionales
Figura 4.3.: Boole-Deusto. Pantalla de diseño de sistemas combinacionales
En la Fig. 4.3 podemos ver la interfaz base de Boole-Deusto para el diseño de sistemas de
47
4. TECNOLOGÍAS
tipo combinacional. Vemos que existe un gran número de opciones disponibles a partir de
este cuadro de diálogo. No obstante, el proceso de creación de un sistema combinacional
comenzará generalmente dando un nombre al sistema y definiendo las entradas, las
salidas, y sus nombres.
Figura 4.4.: Proceso para el diseño de sistemas combinacionales
En la Fig. 4.4 podemos ver el flujo de trabajo habitual que se sigue en el diseño de un
sistema combinacional con Boole-Deusto. Se observa que se parte de una definición de
solución a un problema. Es decir, de una especificación de lo que se quiere obtener. A
partir de esta especificación, el usuario diseñará una tabla de verdad. Una vez diseñada
dicha tabla, Boole-Deusto la convertirá a un conjunto de diagramas de Karnaugh.
Dichos diagramas se utilizan para simplificar la expresión booleana que corresponde a
la tabla. Una vez obtenida la expresión booleana simplificada, es ya posible generar el
circuito digital. Boole-Deusto es capaz de generar el diagrama de un circuito (construido
con puertas lógicas) o de generar código VHDL o Verilog que especifica igualmente tal
circuito.
48
Figura 4.5.: Boole-Deusto. Diagrama de Karnaugh
En la Fig. 4.5 se muestran uno de los diagramas de Karnaugh que se ha mencionado.
Como puede verse, los estudiantes pueden ver gráficamente cómo se realiza la simplificación, y realizarla ellos mismos si lo desean.
Fig. 7. Boole-Deusto: Diagrama de circuito generado por Boole-Deusto, en versión AND/OR y NAND.
Figura 4.6.: Boole-Deusto: Diagrama de circuito NAND generado
49
4. TECNOLOGÍAS
Figura 4.7.: Boole-Deusto: Diagrama de circuito AND/OR generado
En la Fig. 4.6 y la Fig. 4.7 puede verse el resultado del proceso de diseño. Los dos
diagramas son la implementación de la lógica especificada según las tablas de verdad
definidas previamente y la expresión booleana simplificada. Aunque ambos diagramas
son diferentes, su efecto es equivalente. En el primer caso es un diagrama implementado
con puertas AND y OR, mientras que el segundo tipo de diagramas utiliza únicamente
puertas NAND.
50
4.1.4 Sistemas secuenciales (autómatas)
Figura 4.8.: Boole-Deusto. Pantalla de diseño de autómatas
En la Fig. 4.8 podemos ver la interfaz base de Boole-Deusto para el diseño de sistemas
de tipo secuencial (es decir, de autómatas). Puede verse que la interfaz para el diseño de
este tipo es muy diferente a la interfaz para el diseño de circuitos de tipo combinacional.
En este caso, naturalmente, se comienza diseñando gráficamente el autómata. En la
imagen podemos ver un sistema ya diseñado. Tras diseñarlo, el usuario puede obtener
automáticamente (si así lo desea) las tablas de verdad. Por supuesto, también puede
modificarlas libremente una vez obtenidas.
51
4. TECNOLOGÍAS
Figura 4.9.: Boole-Deusto. Circuito generado para un autómata
En la Fig. 4.9 podemos ver el circuito correspondiente a un autómata que se ha generado,
una vez diseñado el sistema y una vez generadas las tablas de verdad correspondientes.
Observamos que en este caso los circuitos son más complejos que los combinacionales,
y que constan de hecho de dos biestables de tipo JK (puesto que al contrario que los
sistemas combinacionales, los secuenciales necesitan mantener estado).
4.1.5 Caracteristicas técnicas
Boole-Deusto, como se ha mencionado anteriormente, es un software de código abierto
cuyo desarrollo es anterior al año 2000. Es por tanto considerablemente antiguo.
Fue originalmente desarrollado en el entorno de programación Borland C++ Builder 5,
en la implementación del lenguaje de programación C++ de Borland. La interfaz, y prácticamente todo el código, hace uso de VCL (Visual Components Library), la librería de
componentes de Borland.
Si bien C++ en sí mismo es un estándar, la versión concreta implementada por Borland
tiene muchas peculiaridades, y la librería VCL en concreto es totalmente propietaria. Esto
hace que no sea compatible con ningún otro entorno de C++.
Dada la complejidad de la VCL, utilizada para la creación de toda la interfaz, su migración
a un entorno nuevo más actual requeriría una cantidad notablemente alta de trabajo:
básicamente, toda la interfaz tendría que ser creada de nuevo.
Otra complicación técnica relacionada con esto es que Borland C++ Builder 5 es considerablemente antiguo. Borland como empresa, de hecho, ha desaparecido. Existen derivados modernos del entorno, como Embarcadero C++ Builder, pero tienen diferencias
notables.
52
Todo esto hace que desafortunadamente, Boole-Deusto sea notablemente complicado
de modificar. En secciones posteriores se describirán en más detalle problemas encontrados. Otro aspecto remarcable de Boole-Deusto es su sistema de localización (que
hace uso de una característica de Borland C++ Builder), que le permite estar traducido a
varios idiomas.
4.2 WEBLAB-DEUSTO
4.2.1 Introducción
Weblab-Deusto es un laboratorio remoto creado por la Universidad de Deusto.
Ha sido desarrollado y publicado como un
software de código abierto, y se encuentra en un proceso de constante desarrollo
y mejora.
Un laboratorio remoto es, en definitiva, una
plataforma formada por hardware y por
software que tiene como objetivo permitir a
estudiantes u otros usuarios experimentar
remotamente a través de Internet, permiFigura 4.10.: Ubicación física de algunos de los
tiéndoles acceder a equipamiento que fíexperimentos de WebLab, contesicamente está ubicado en la universidad,
nidos en cajas
escuela o centro de investigación, emulando en la mayoría de los casos a laboratorios clásicos presenciales.
Existen diferentes tipos de sistemas de laboratorios remotos. Existen, por ejemplo, laboratorios remotos orientados a la educación, y laboratorios remotos orientados a otros
propósitos (por ejemplo industriales). En este caso, Weblab-Deusto es un laboratorio remoto educativo.
También es remarcable que existen laboratorios remotos de dominio específico, que están orientados a soportar un tipo de experimento concreto. Es decir, tienen un ámbito
limitando, permitiendo en general experimentar con una sola actividad concreta. Existen
también otros laboratorios, como el propio Weblab-Deusto, que son no son de dominio
específico, sino que están orientados a cualquier tipo de experimento, y aportan una infraestructura genérica común que puede ser aprovechada por todos ellos.
Dicha infraestructura genérica aporta ciertas facilidades base, como puede ser gestión de
usuarios, gestión de experimentos, gestión de autenticación, balanceo de carga, o federación. A partir de dicha infraestructura, experimentos concretos proveen tipos concretos
de experimentación.
En la actualidad, Weblab-Deusto ofrece multitud de experimentos. Muchos (la mayoría)
de ellos son de naturaleza electrónica, pero soporta también otros experimentos relacionados con otros campos, como la física y la biología.
53
4. TECNOLOGÍAS
Figura 4.11.: WebLab-Deusto. Pantalla de selección de experimentos de un usuario
En la Fig. 4.11 pueden verse la pantalla principal de selección de experimentos de WeblabDeusto.
Como puede verse, existe una variedad bastante amplia de experimentos (y de hecho,
existen más que no se muestran).
Podemos ver, por ejemplo, experimentos FPGA (que permiten grabar y controlar una
placa FPGA e interactuar con ella, y que serán descritos en más detalle más adelante).
Podemos ver también experimentos PIC, que permiten grabar programas en un una placa
dotada de un microcontrolador.
Existen además experimentos más .exóticos”, como pueden ser los acuáticos, que permiten observar y monitorizar un acuario real, así como controlar (de forma limitada) la
alimentación e iluminación de los peces, o como la incubadora, que permite monitorizar
el desarrollo de huevos de gallina.
4.2.2 Características generales
Desde una perspectiva algo más técnica, WebLab-Deusto es una infraestructura de laboratorios remotos.
En concreto, podemos considerarlo un RLMS (Remote Laboratory Management System).
Por regla general, los experimentos de WebLab-Deusto están basados en la Web, y soportan cualquier navegador (Chrome, Explorer, Mozilla, Opera, Safari…). Pueden también ser usados desde cualquier sistema operativo (Linux, Windows…) e incluso desde
prácticamente cualquier dispositivo (ordenadores de sobremesa, portátiles, tablets, móviles…).
Para la mayoria de experimentos los usuarios no necesitan instalar nada en sus dispositivos, y gracias a ello no hay problemas de seguridad para los usuarios. Weblab-Deusto
está diseñado para ser fácilmente extensible. Es decir, por diseño, trata de que sea razonablemente sencilla la creación de nuevos experimentos.
54
Un “experimento” de Weblab-Deusto se compone de dos grandes partes. Un cliente, y
un servidor. El cliente en general será Web, si bien se soporta prácticamente cualquier
tecnología. El cliente de la mayoría de experimentos actualmente disponibles está creado
en GWT (Google Web Toolkit).
Otras opciones son, por ejemplo, usar Adobe Flash o Java Applets. Tras la realización
del proyecto que en este documento se describe, será también posible usar directamente
JavaScript nativo.
El servidor de experimento puede ser desarrollado también en diversas tecnologías. Lo
habitual es desarrollarlo en Python. Sin embargo, existen librerías que dan soporte a
otras tecnologías. Es posible, por ejemplo, utilizar C#, Java o, tras la realización de este
proyecto, también JavaScript, a través de NodeJS.
Figura 4.12.: Arquitectura de los servidores de WebLab [44]
En la Fig. 4.12 puede verse la arquitectura de los servidores. El experiment microserver
de la figura es el servidor de experimento referido anteriormente.
4.2.3 Facilidades aportadas
Como se ha explicado en apartados anteriores, uno de los objetivos de una infraestructura
de laboratorios remotos como Weblab-Deusto es aportar ciertas características genéricas
que pueden ser utilizadas por cualquier experimento. Algunas de ellas, las más notables,
se detallarán a continuación.
4.2.3.1 Gestión de usuarios
Los experimentos remotos suelen requerir hardware, que en algunas ocasiones es caro y
a la vez delicado. Por eso, se hace necesario restringir en ocasiones el acceso, o al menos
limitarlo. Weblab-Deusto se encarga de gestionar los usuarios, reconociendo diversos
tipos, tales como usuarios registrados explícitamente en la base de datos, usuarios de la
universidad (con cuenta en el sistema LDAP de la universidad) u otros.
55
4. TECNOLOGÍAS
4.2.3.2 Autenticación
Por los mismos motivos que en el caso anterior, un laboratorio remoto debe proveer cierta
seguridad. Dependiendo del tipo de usuario, la autenticación será de un modo u otro. En
el momento de escribir esto, Weblab-Deusto soporta diversos métodos de autenticación.
Algunos de éstos son, por ejemplo, autenticación simple por contraseña, autenticación
mediante OpenID, autenticación por IP, o incluso autenticación por Facebook.
4.2.3.3 Escalabilidad, distribución de carga y compartición de recursos
Según aumenta el número de usuarios y/o de experimentos, la demanda de hardware
también se incrementa. Weblab-Deusto facilita la escalabilidad, soportando clústers formados por un número básicamente ilimitado de equipos individuales, y distribuyendo a
los usuarios entre ellos de forma apropiada, y compartiendo los recursos físicos (tales
como hardware de experimentos) siempre que sea posible.
4.2.3.4 Gestión de colas
Frecuentemente, el número de usuarios simultáneos del sistema será elevado. Esto es
especialmente cierto cuando el sistema es utilizado, por ejemplo, en una clase convencional. En algunos experimentos el uso simultáneo será posible, en otros no. En algunos de
los primeros, el número de usuarios simultáneos estará limitado. Todo esto hace necesario un sistema considerablemente complejo de gestión de colas, del cual Weblab-Deusto
se encarga.
4.2.3.5 Federación
Figura 4.13.: Diagrama de la federación en WebLab-Deusto [11]
La federación es una de las características avanzadas de Weblab-Deusto. La federación
permite, principalmente, acceder a experimentos que están alojados en una instancia del
laboratorio remoto diferente. Por ejemplo, mediante federación, el laboratorio remoto de
la Universidad de Deusto podría acceder a un experimento hospedado por el laboratorio
remoto del MIT.
56
También resuelve otro problema. Weblab-Deusto es código abierto, y cualquier persona
o institución es libre de crear su propia instancia. Sin embargo, en la práctica, el coste de
crear experimentos y de mantenerlos puede ser elevado, ya que además del mantenimiento convencional de los servidores se tiende a requerir equipamiento hardware para
cada experimento.
Para muchas instituciones de tamaño pequeño o medio, el tener un laboratorio remoto
propio, con su hardware correspondiente, está en la práctica fuera de su alcance. Es
posible, sin embargo, que una entidad más grande provea una instancia propia a otra.
Esto se utiliza en la actualidad, por ejemplo, en el colegio Urdaneta, que dispone de su
propia instancia de Weblab-Deusto hospedada en la Univesidad de Deusto.
4.2.3.6 Integración en Facebook, LMSs, y otros entornos
Figura 4.14.: WebLab-Deusto, integrado en Facebook [11]
Otra posibilidad de Weblab-Deusto es la integración automática en Facebook y otros
entornos, incluyendo LMS (Learning Management Systems) como puede ser Moodle.
Mediante esta característica, cualquier experimento de Weblab-Deusto pasa a ser automáticamente accesible desde Facebook u otros (suponiendo por supuesto que el usuario
tenga los privilegios necesarios para ello).
4.2.4 Características técnicas hardware
El núcleo de Weblab-Deusto se ejecuta sobre servidores tradicionales. En la actualidad,
son todos servidores Linux, si bien también se soportan otros sistemas operativos como
Windows. Dada su naturaleza, sin embargo, también se requiere, para cada experimento,
software específico. No es posible generalizar éste software, ya que es muy dependiente
del experimento concreto.
57
4. TECNOLOGÍAS
Por ejemplo, un experimento FPGA requiere:
Una placa FPGA, provista de LEDs y de los mecanismos necesarios para hacerla
programable remotamente.
Una placa controladora PIC, que se utiliza para gestionar la grabación, trasladar las
entradas especificadas por el servidor a entradas físicas reales, etc. En definitiva,
se encarga de vincular la placa FPGA al servidor de experimento.
Una Webcam, para poder visualizar remotamente la placa FPGA.
Un FitPC, para hospedar el servidor de experimento. Dicho FitPC está conectado a
la placa controladora PIC, y a través de ambos se realizan las gestiones oportunas.
Una caja, dotada de iluminación, donde ubicar todos los componentes.
Figura 4.15.: Caja para FPGA
En la Fig. 4.10 y la Fig. 4.15 podemos ver dichas cajas, diseñadas y construidas específicamente para hospedar experimentos. Esta caja, que ha ganado premios, se ha
desplegado en varias universidades, incluyendo el MIT (EE.UU.).
Si bien el hardware concreto dependerá del experimento, si que existen ciertos elementos
que tienden a utilizarse en varios.
Uno de éstos es la propia caja, que debido a sus especiales características resulta útil
para muchos experimentos, particularmente aquellos basados en placas electrónicas.
En prácticamente cualquier experimento también tendremos una o varias Webcam, que
permitan visualizarlo remotamente, y un FitPC o similar, que permita controlar el experimento.
58
4.2.5 Características técnicas software
En el desarrollo de Weblab-Deusto intervienen muy diversas tecnologías. A continuación,
se especifican algunas de las más importantes.
El servidor de Weblab como tal (no necesariamente los servidores de experimento) están
desarrollados en Python.
El cliente, por el contrario, está desarrollado en GWT (Google Web Toolkit). Los clientes
específicos de los experimentos utilizan también en su mayor parte GWT, aunque hay
algunos que utilizan otras tecnologías como Adobe Flash.
4.3 TECNOLOGÍAS HARDWARE
En este apartado se describen de forma breve aquellas tecnologías hardware que de
un modo u otro han intervenido en el desarrollo de este proyecto o que tienen relación
directa con él, y que son por tanto relevantes.
4.3.1 VHDL
VHDL es un acrónimo de (VHSIC Hardware Description Language). Como su nombre
indica, es un lenguaje de descripción de hardware. Se utiliza para describir la lógica de
sistemas digitales (o de señal mixta). Se suele utilizar como alternativa a Verilog (otro
lenguaje de descripción de hardware) en dispositivos tales como FPGAs (Field Programmable Gate Array).
VHDL es el lenguaje que esperan recibir experimentos tales como Weblab-Deusto-FPGA,
directamente relacionados con el proyecto descrito en este documento. Los archivos
VHDL tienden a tener la terminación VHD.
4.3.2 BITSTREAM
BITSTREAM hace referencia a un formato binario de archivo, que contiene una descripción de bajo nivel de la lógica de un dispositivo tal como un FPGA. Por regla general,
entornos de desarrollo hardware como el de Xilinx permiten la especificación de la lógica
utilizando un lenguaje de relativo alto nivel, como VHDL o Verilog. Posteriormente, a partir de dichos archivos fuente y de un archivo de restricciones (UCF), sintetizan un archivo
BITSTREAM.
Los archivos BITSTREAM contienen tanto la lógica como el mapeo de puertos (vinculación de cada entrada y salida física a sus equivalentes lógicos) y puede ser directamente
grabado en una placa hardware.
59
4. TECNOLOGÍAS
4.3.3 UCF
UCF (User Constraints File) hace referencia a un formato de archivo. Los UCF contienen
restricciones. En la práctica, las restricciones más notables son aquellas que vinculan las
entradas y salidas lógicas de una fuente VHDL a las entradas y salidas físicas (los pines)
de un dispositivo hardware.
4.3.4 Xilinx ISE
Xilinx ISE (Integrated Software Environment) es una herramienta software desarrollada por Xilinx para crear y sintetizar diseños HDL. Permite, entre otras muchas funcionalidades, traducir de la lógica de alto nivel en VHDL al archivo
BITSTREAM que puede ser grabado físicamente en las plaFigura 4.16.: Logotipo
cas.
de
Xilinx Inc. [23]
El software tiene un tamaño considerablemente grande (más
de 6 gigabytes), y requiere de registro para su uso.
Contiene utilidades de línea de comandos, que permiten su utilización programática. Tras
la finalización de este proyecto, Weblab-Deusto contendrá dichas herramientas en uno
de sus servidores, y las utilizará para sintetizar código VHDL provisto por usuarios remotos, que después grabará automáticamente en una placa física para su posterior prueba.
4.3.5 FPGA
Un FPGA (Field Programmable Gate Array) es un circuito integrado configurable tras su manufactura (de donde le viene
el nombre). Es decir, su configuración puede ser especificada mediante un lenguaje de definición de hardware, y, de
hecho, por regla general puede ser especificada varias veces.
Tienen la ventaja de que son por esto muy flexibles. Puesto
que su comportamiento puede especificarse, resultan más Figura 4.17.: Dispositivo
FPGA de Xilinx
baratos que un dispositivo diseñado para un propósito es[23]
pecífico, como son los ASIC (application-specific integrated
circuit). Gracias a su diseño, sin embargo, su eficiencia tiende a ser superior a la de un
microcontrolador, y comparable a la de dichos dispostitivos ASIC.
Esto los hace idóneos y económicos para muchos procesos de control, o para la fabricación de prototipos.
Uno de los experimentos más notables de Weblab-Deusto es Weblab-Deusto-FPGA, un
experimento que precisamente está basado en una placa FPGA. En dicho experimento,
60
el usuario puede especificar remotamente el comportamiento de un FPGA (grabando en
él un BITSTREAM generado a partir de un código VHDL).
Tras su grabación, el usuario puede ver la placa FPGA (que tiene, entre otros componentes, unos LEDs que actúan como salidas), e interactuar con ella, todo a través de una
Webcam y una interfaz remota virtual.
4.4 TECNOLOGÍAS SOFTWARE
4.4.1 Borland C++ Builder
Borland C++ Builder es un entorno de desarrollo en C++, que contiene su propio compilador. Es el entorno en el que ha sido desarrollado Boole-Deusto. Desafortunadamente,
es un entorno considerablemente antiguo, muy por detrás de entornos mucho más modernos como Visual Studio.
Desafortunadamente, debido al uso de VCL (que se detallará más adelante), no es posible la utilización de uno de estos entornos con Boole-Deusto, sin cambios extremadamente extensos.
Originalmente, Borland C++ Builder estaba diseñado a partir del entorno de Delphi. Delphi
(y por consiguiente Borland C++ Builder) fueron de los primeros entornos RAD (Rapid
Application Development), orientados al desarrollo rápido de aplicaciones con ventanas
haciendo uso de una interfaz visual, basada en el “arrastrar y soltar”.
Para esto, las aplicaciones en Borland C++ Builder tienden a depender de la librería VCL,
la librería de componentes de Borland que comparte con Delphi. Cabe notar que Borland
como tal ya no existe, si bien existen versiones más o menos modernizadas de sus herramientas y de la VCL (que desafortunadamente, tampoco son realmente compatibles
con Boole-Deusto).
4.4.2 VCL
VCL (Visual Components Library) es una librería de componentes propietaria de Borland.
Tanto su producto de original de Delphi, como su producto derivado C++ Builder, hacen
uso de ésta librería. Si bien en su tiempo probablemente fuera razonablemente avanzada,
en la actualidad desafortunadamente está muy por detrás de librerías conceptualmente
semejantes, como pueden ser Winforms (de Microsoft), WPF (también de Microsoft) o
incluso Qt.
Originalmente, VCL competía con MFC (Microsoft Foundation Classes), que tampoco es
demasiado utilizada en la actualidad.
VCL se utiliza para toda la interfaz de Boole-Deusto, y sus clases tienen también presencia en gran parte de su lógica, que está muy mezclada con dicho código.
61
4. TECNOLOGÍAS
Esto hace impracticable cambiar de librería (al menos, sin rehacer toda la interfaz y gran
parte de la lógica del programa), y hace que visualmente esté necesariamente algo limitado con respecto a programas más modernos.
4.4.3 Python
Python es un lenguaje de programación de propósito general, de muy alto nivel. Soporta diversos paradigmas, incluyendo la programación orientada a
objetos, y es un lenguaje dinámico.
Pone especial énfasis en su legibilidad, permitiendo en general expresar la lógica del programa en Figura 4.18.: Logotipo de Python [38]
comparativamente pocas líneas, y siendo de él característico el hecho de que los espacios y la indentación tienen significado (se utilizan
para separar sentencias, definir el ámbito, etc).
Tradicionalmente ha sido utilizado mucho como lenguaje de scripts, pero se utiliza también en muchos otros contextos.
Existen varias implementaciones de Python, basadas en distintos entornos. La implementación más común es CPython, desarrollada en C.
Otras implementaciones populares son IronPython, desarrollada para el entorno .NET, o
Jython, desarrollada para la máquina virtual de Java.
El núcleo de Weblab-Deusto (el servidor) está íntegramente desarrollado en Python.
4.4.4 JavaScript
JavaScript es un lenguaje de programación dinámico, generalmente interpretado. Es tradicionalmente un lenguaje propio de los navegadores. Esto hace que en la actualidad
sea quizás el lenguaje de programación más ubicuo (prácticamente cualquier máquina
actual posee un navegador web, y con él un intérprete JavaScript).
Su propósito original era la de permitir la creación de páginas Web más dinámicas, que
mediante scripts en el lado del cliente fueran capaces de interactuar con el usuario, creando efectos avanzados y modificando el documento mostrado según se requiriese.
Se le considera un lenguaje basado en prototipo, y tiene una sintaxis inspirada en el
lenguaje de programación C. Puede ser, sin embargo, considerado un lenguaje multiparadigma, ya que, no sin en ocasiones cierto esfuerzo, soporta orientación a objetos,
programación funcional, etc.
En la actualidad no sólo se utiliza en navegadores, sino que se utiliza también en muchas
aplicaciones como lenguaje de scripting, e incluso como lenguaje de scripting en el lado
del servidor a través de entornos como node.js, que será también reseñado en apartados
posteriores de ésta sección.
62
Con respecto al lenguaje en sí, uno de los aspectos más notables es probablemente que
tiende a ser totalmente asíncrono.
Es decir, por diseño, al margen de optimizaciones internas de los intérpretes, las funciones JavaScript siempre se ejecutan al menos conceptualmente en un solo hilo. Aquellas tareas que requieren de un tiempo de ejecución se manejan siempre mediante callbacks.
La popularidad de JavaScript en los últimos tiempos ha ido en aumento, y los intérpretes
han ido mejorando progresivamente. En el momento de escribir esto, los intérpretes más
avanzados soportan tecnología JIT (Just In Time). Esto implica que antes de ejecutarse,
los programas JavaScript (o partes de ellos) se compilan a código máquina nativo, para
ser ejecutados lo más rápidamente posible. Estos intérpretes (como Google Chrome V8)
son capaces de producir código cuya eficiencia rivaliza (dentro de lo que cabe) con la de
lenguajes nativos.
Como parte de este proyecto, se añadirá a Weblab-Deusto la capacidad de crear de
forma sencilla experimentos nuevos en JavaScript, tanto en cliente como en servidor.
La creación de experimentos en JavaScript supondrá ventajas considerables, que se
detallarán en otras secciones de este documento, entre las que se encuentran el hecho
de no necesitar recompilar para añadir o probar experimentos nuevos.
4.4.5 GWT (Google Web Toolkit)
GWT (Gooble Web Toolkit) es un conjunto de herramientas
de código abierto que permite la creación de aplicaciones
web en el lado cliente mediante Java.
Esto es posible porque las herramientas de GWT generan,
a partir del código Java, código Javascript que puede ser
nativamente ejecutado por los navegadores.
Esto tiene teóricamente varias ventajas, aunque también se
han observado inconvenientes.
4.4.5.1 Ventajas
Figura 4.19.: Logotipo
de
GWT (Google
Web Toolkit)
[18]
∎ Desarrollo en Java
El desarrollo en Java es frecuentemente más conveniente que el desarrollo en Javascript.
Los programadores frecuentemente conocen mejor Java. Además, siendo un lenguaje
estático, para programas grandes tiende a ser más fácil de mantener, y tiende a ser más
complicado cometer errores.
63
4. TECNOLOGÍAS
∎ Optimización
Puesto que el código Javascript es generado automáticamente, no tiene por qué ser legible. El código que genera GWT está optimizado para el navegador específico en el que
se ejecute, y su propio comportamiento es independiente del navegador. El programador
no tiene que preocuparse (o tiene que preocuparse menos) de las diferencias entre navegadores. Se llevan acabo ciertos trucos que permiten una optimización adicional, como
puede ser el incrustar imágenes en el propio código Javascript para garantizar una carga
más rápida de las páginas.
∎ Herramientas
Además, GWT cuenta con una serie de herramientas adicionales que facilitan el desarrollo. Estas incluyen depuradores y “profilers”, que facilitan la medida del rendimiento
de las aplicaciones Web, e incluso editores gráficos para la interfaz Web, que permiten
diseñarla mediante un esquema WYSIWYG (What You See is What You Get).
Figura 4.20.: GWT Designer (Editor WYSIWYG para GWT) [18]
4.4.5.2 Inconvenientes
∎ Desarrollo lento
Una página basada en JavaScript es muy sencilla de probar. Sólo hace falta abrirla en un
navegador, e inmediatamente se ejecutará. El proceso con GWT es notablemente más
lento. A pesar de que provee herramientas que permitan cargar también directamente la
página sin necesidad de compilarla previamente, el generar código JavaScript sobre la
marcha es un proceso costoso, y en la práctica lleva un tiempo considerablemente más
largo.
64
∎ Dificultad de depuración
Si bien GWT no contiene un gran número de errores, como prácticamente cualquier software, no es perfecto. Cuando ocurre un error, puesto que termina apareciendo en una
capa de JavaScript autogenerado, tiende a ser considerablemente difícil e depurar, incluso a pesar de las características que GWT ofrece para facilitar dicha tarea.
∎ Limitaciones prácticas
GWT soporta lo que denomina JSNI (JavaScript Native Interface), que permite la especificación de código nativo JavaScript dentro del código fuente Java. Sin embargo, dicha
interfaz es notablemente compleja de utilizar, y tiene ciertas limitaciones. Esto hace que
en la práctica sea un proceso considerablemente costoso el mezclar JavaScript nativo
con GWT, y por tanto, es un factor limitante cuando se desean añadir características
JavaScript relativamente avanzadas.
Esto es particularmente cierto en aquellos casos en los que sea desea hacer uso de una
librería nativa JavaScript desde GWT.
4.4.6 AJAX (Asynchronous JavaScript and XML)
AJAX es un conjunto de tecnologías web relacionadas basadas en el lado cliente y en
JavaScript, y que tienen como objetivo facilitar la creación de aplicaciones Web asíncronas.
Se basa principalmente en la capacidad de realizar peticiones HTTP asíncronas, iniciadas
desde JavaScript y sin necesidad de recargar la página.
Cabe notar que dichas peticiones pueden ser utilizadas para cargar cualquier clase de página, independientemente de su contenido. Desde archivos XML, hasta archivos JSON,
hasta scripts JavaScript completos, incluyendo imágenes. En contra de lo que el nombre
sugeriría, por tanto, no está limitado a XML.
Esto permite a una aplicación Web cliente realizar peticiones al servidor y recuperar información sobre la marcha, sin necesidad de recargar la página y por tanto de una forma
mucho más dinámica y eficiente.
Uno de los inconvenientes de AJAX es que si bien lo soporta cualquier navegador moderno de una forma u otra, no todos lo soportan de igual manera. Por eso (y por otros
motivos) para facilitar su uso suele utilizarse a través de librerías JavaScript como jQuery,
que abstraen su uso, facilitándolo y haciéndolo independiente del navegador. AJAX es
una característica muy utilizada por WebLab, y es la tecnología que prácticamente todos
las aplicaciones cliente de los experimentos utilizan internamente para comunicarse con
el servidor.
4.4.7 jQuery
65
4. TECNOLOGÍAS
jQuery es una librería de JavaScript orientada a facilitar en el lado cliente la creación de páginas Web
dinámicas.
Entre sus características principales, están la de facilitar la navegación, búsqueda y manipulación del
DOM y la de facilitar el uso de AJAX.
Figura 4.21.: Logotipo de jQuery [24]
Otra característica, quizás menos conocida pero notablemente útil y relevante para el
proyecto descrito en este documento, es la de soportar “promesas”. Una “promesa” es
un concepto utilizado en JavaScript y lenguajes similares que facilita la programación
asíncrona.
En muchas ocasiones, cuando se realiza programación asíncrona, se desea encadenar
callbacks, o definir un callback que se ejecute una vez que otros callbacks hayan finalizado.
Una “promesa” es un objeto que devuelve una función asíncrona, y que quiere decir que
en el momento de retornar esa función, a pesar de que de momento su valor de retorno
no está disponible (ya que puesto que la función es asíncrona, aún probablemente no
haya terminado su ejecución), en algún momento sí lo estará (de ahí la promesa).
Con un objeto “promesa” es posible comprobar su estado (para ver si ha finalizado),
recuperar su valor en caso de que sí que haya finalizado, o incluso especificar otros
callbacks que deberán ser ejecutados cuando esa promesa (o una lista de promesas)
haya sido cumplida.
En lo que respecta al proyecto descrito en este documento, todas éstas características
de jQuery resultarán notablemente útiles en diversas partes, como en la creación de una
librería que facilite la creación de experimentos Weblab basados en JavaScript, o como
en la infraestructura concreta para la creación de experimentos con modelos virtuales
que también se desarrollará durante este proyecto.
4.4.8 HTML5 Canvas
El “canvas” es un elemento de HTML 5. Consiste principalmente en un área fija de la página web, cuyo tamaño puede
ser definido, en la que se puede dibujar dinámicamente a
través de JavaScript.
En principio, el canvas está orientado a gráficos 2D. Es posible dibujar formas, imágenes, etc.
También es posible utilizarlo para 3D, pero esencialmente
se requiere para esto una librería 3D software, con los problemas de rendimiento que esto implica.
Su utilidad principal es la de permitir gráficos relativamente
avanzados, con los que se pueden crear aplicaciones inter-
66
Figura 4.22.: Logotipo
de
HTML5 [45]
activas y que pueden sustituir en gran medida a tecnologías como Flash, basadas en
plugins y software propietario específico.
En el momento de escribir esto, las versiones actuales de todos los navegadores Web
principales soportan Canvas, incluyendo a Chrome, Firefox, Opera, Safari, Internet Explorer, e incluso los navegadores modernos de Android.
4.4.9 WebGL
WebGL (Web Graphics Library) es una API en JavaScript orientada a permitir gráficos
interactivos en 2D y 3D dentro de los navegadores y sin necesidad de plugins. Dichos
gráficos están acelerados por hardware (por la GPU). Esto hace por tanto posibles los
gráficos tridimensionales avanzados en el navegador, sin necesidad de plugins externos,
y en principio, con seguridad.
WebGL dibuja sobre un Canvas de HTML5, pero, al contrario que éste por sí sólo, se
asegura de que la mayor parte de su trabajo se realice en la GPU.
Basado en OpenGL, soporta incluso características gráficas avanzadas como shaders
GLSL. Si bien es una tecnología muy potente, es cierto que tiene algunos problemas.
Probablemente por ser bastante nueva, su soporte aun no es perfecto en todos los navegadores. En el momento de escribir esto, el navegador con mejor soporte es probablemente Chrome. También lo soportan bien Firefox, Safari y Opera, aunque Internet
Explorer por defecto (sin plugins) no lo soporta aún. En principio, parece que la versión
11 de IE sí añadirá soporte.
En cuanto a navegadores móviles, son menos los que de momento lo soportan. Con
respecto a Android, el navegador por defecto sólo lo soporta en ciertos fabricantes. Lo
soporta también la última versión de Google Chrome (aunque debe habilitarse explícitamente) y las versiones de Firefox Mobile a partir de la 4.
Cabe notar, sin embargo, que el desarrollo de WebGL ha sido y está siendo muy rápido, y
se espera que en muy poco tiempo sea soportado casi completamente por casi cualquier
navegador.
En este proyecto, WebGL será la tecnología que se utilice principalmente para la creación de los modelos virtuales en los experimentos electrónicos con realidad mixta que
se implementen. Puesto que se hará uso de la librería ThreeJS (descrita más adelante)
que soporta también Canvas no acelerado, WebGL posiblemente no sea estrictamente
necesario (aunque sí muy útil, ya que para cualquier simulación compleja Canvas sin
aceleración será demasiado lento).
67
4. TECNOLOGÍAS
Figura 4.23.: Ejemplo de aplicación WebGL, ejecutándose en Chrome [4]
4.4.10 ThreeJS
Three.js es una librería 3D basada en JavaScript. Por diseño, sus objetivo es ser una
librería ligera, de baja complejidad.
La librería soporta varios renderers distintos, incluyendo Canvas y WebGL. El primero
tiene la ventaja, como ha sido descrito anteriormente, de que lo soporta prácticamente
cualquier navegador, pero no es acelerado por hardware y por tanto es notablemente
lento para 3D. El segundo tiene la ventaja de que es mucho más rápido y eficiente (los
gráficos son acelerados por hardware y se utiliza directamente la GPU), pero no lo soportan todos los navegadores.
En el proyecto aquí descrito, se utilizará ThreeJS en la creación de la infraestructura necesaria para facilitar el diseño e implementación de experimentos con modelos virtuales.
Se utilizará también consecuentemente para la creación de los experimentos con modelos virtuales (realidad mixta) específicos.
4.4.11 Node.js
Node.js es un sistema basado en JavaScript que permite la
utilización de éste como lenguaje de scripts en el lado servidor.
Basado en el motor de JavaScript V8, de Google, es notablemente eficiente. Una de sus características más notables Figura 4.24.: Logotipo de
node.js[30]
es que contiene su propio servidor HTTP, de tal forma que
al contrario que otras tecnologías, no depende de un servidor Web como Apache. Esto
en muchas ocasiones facilita el desarrollo y despliegue y mejora la eficiencia. Siguiendo la filosofía JavaScript en la que está basado, los programas de node.js tienden a ser
asíncronos, basados en callbacks y eventos.
68
A pesar de lo que inicialmente podría pensarse, node.js es notablemente eficiente y escalable.
En el transcurso de este proyecto, se añadirá a Weblab-Deusto la capacidad de desarrollar servidores de experimento (lado del servidor) basados en node.js. Puesto que
también se añadirá la capacidad de desarrollar clientes en JavaScript, esto hará que sea
posible crear un experimento completo usando únicamente JavaScript, y sin necesidad
de compilar nada ni de usar ninguna otra tecnología.
4.4.12 Sphinx
Sphinx es un conjunto de herramientas basadas en Python, para la creación de documentación.
69
5. DESARROLLO
5.1 ENTORNO DE DESARROLLO
En esta sección se describen aquellas herramientas que han ayudado e intervenido en
el desarrollo de este proyecto.
5.1.1 Eclipse for Java
Eclipse es un entorno de desarrollo integrado multilenguaje. De código abierto, está desarrollado principalmente en Java, tiene su propio compilador (ECJ), y está tradicionalmente orientado a desarrolladores de Java. No obstante, actualmente existen plug-ins para desarrollo en muchos más lenguajes, incluyendo C/C++, PHP, Python, JavaScript,
etc.
Eclipse funciona además en prácticamente cualquier plataforma (Windows, Linux...).
En este proyecto, se ha utilizado Eclipse principalmente para el desarrollo de una parte
del trabajo realizado en el núcleo del cliente de Weblab-Deusto, que está desarrollado en
lenguaje Java en GWT (Google Web Toolkit).
Cabe notar que GWT consta de su propio plug-in de Eclipse, que permite, entre otras
cosas, depurar la aplicación GWT si necesidad de realizar una compilación completa (el
código Java de GWT se compila a JavaScript).
5.1.2 PyDev
PyDev es uno de esos plug-ins o entornos derivados de
Eclipse. En este caso, PyDev está orientado al desarrollo
de aplicaciones en Python.
PyDev es uno de los entornos de desarrollo Python más
avanzados. Soporta mejor que la mayoría características
Figura 5.1.: Logotipo de Pyque típicamente están bastante limitadas en lenguajes diDev [37]
námicos, como son el autocompletado o la documentación
en línea.
Es también un entorno que facilita particularmente la depuración de programas Python,
soportando su depurador características típicas como son los puntos de ruptura (estándar
y condicionales), y la vigilancia de variables y expresiones.
En este proyecto, se ha utilizado PyDev para el desarrollo del trabajo realizado en los
servidores de Weblab (escritos en Python), y en las modificaciones y mejoras hechas a
71
5. DESARROLLO
Weblab-Xilinx-FPGA, cuyo servidor es también Python. Se ha utilizado, además, para la
creación (en el lado del servidor) de las simulaciones que aportan realidad mixta a los
experimentos.
5.1.3 Microsoft Visual Studio 2012
Figura 5.2.: Logotipo de Visual Studio 2012
Microsoft Visual Studio es un entorno de desarrollo integrado de Microsoft. Soporta diversos lenguajes, entre los que se incluyen C, C++, lenguajes del entorno .NET como pueden
ser C#, Visual Basic y F#, y lenguajes Web como JavaScript, HTML y CSS.
En su versión del 2012, particularmente, ha recibido mejoras muy significativas en sus
capacidades de desarrollo JavaScript, siendo hoy en día uno de los entornos más avanzados a este respecto: se distribuye con su propio intérprete parcial de propósito específico
de JavaScript. Esto permite que su “IntelliSense”, la denominación de Microsoft para las
capacidades de auto-completado de su entorno, sea particularmente informativo, útil, y
preciso.
Por este motivo, Visual Studio ha sido el entorno elegido en el proyecto para la realización
de aquellas partes que involucrasen a JavaScript.
Estas partes son, entre otras:
La librería de Weblab en JavaScript para el desarrollo de clientes de experimento
en JavaScript nativo.
La librería de Weblab en JavaScript y node.js para el desarrollo de servidores de
experimento en JavaScript.
La infraestructura para la realización de modelos virtuales y simulaciones con ThreeJS (formada principalmente por WorldLoader.js, una pequeña librería que permite definir un “mundo” virtual en un archivo de formato simple derivado de JSON,
con soporte de eventos).
Los propios modelos virtuales y simulaciones realizadas, que añaden realidad mixta
a los experimentos, como lo es la simulación 3D del tanque de agua.
72
Figura 5.3.: Microsoft Visual Studio 2012
5.1.4 Notepad++
Notepad++ es un editor de texto orientado a la edición de código fuente. Basado en
Scintilla, está escrito en C++.
Pretende a ser una versión mucho más potente de “notepad”, pero manteniendo el máximo rendimiento y una interfaz simple y usable. Soporta pestañas, coloreado de sintaxis,
búsqueda y remplazo utilizando expresiones regulares, etc.
En el proyecto se ha utilizado para aquellas tareas y para aquellos momentos en los
que abrir o utilizar un entorno de desarrollo completo no se ha considerado necesario, y
era más simple editar el archivo sencillamente utilizando un editor de texto como Notepad++.
Entre muchos otros usos menores, destacan:
La creación de documentación y manuales, realizada en archivos locales con Notepad++. Dicha documentación ha sido originalmente creada con Sphinx, que utiliza
una sintaxis sencilla, similar a la de las “wiki”.
La edición de algunos archivos de configuración durante el desarrollo.
73
5. DESARROLLO
5.1.5 Vim
Vim es una versión avanzada del entorno Vi, tradicionalmente disponible en prácticamente cualquier entorno UNIX o basado en UNIX.
Los servidores en producción de Weblab están todos ellos actualmente basados en Linux,
y por motivos de eficiencia y seguridad, no disponen de un entorno gráfico.
Durante el proyecto, por tanto, se ha utilizado principalmente Vim para el despliegue y la
configuración de las mejoras y modificaciones realizadas.
Esto incluye parte de la instalación del entorno basado en Xilinx que permitiese sintetizar
archivos VHDL en el servidor, así como la edición de los múltiples archivos de configuración que los experimentos de Weblab requieren para ser desplegados.
También incluye en ocasiones la edición de código por motivos de depuración, que si
bien es en general evitable en el entorno de producción, ha resultado en unas pocas
ocasiones necesaria.
Ha sido también utilizado como la herramienta principal para la consulta de logs y registros en estos mismos servidores, así como para otros propósitos menores.
5.1.6 Git y TortoiseGit
Git es un sistema de versiones distribuido. Diseñado originalmente por Linus Torvalds,
uno de sus propósitos era facilitar la gestión de versiones en un proyecto de gran complejidad como es el propio kernel de Linux.
Hoy en día Git se ha desarrollado hasta ser uno de los sistemas de control de versiones
más populares, considerado en general como una alternativa superior a sistemas de
versiones más antiguos no distribuidos como Svn.
Cabe notar que pese a su aparente vinculación con el entorno Linux, es multiplataforma.
Existe versión para Windows, y existen de hecho numerosas interfaces gráficas.
En entornos Windows, la más popular de éstas interfaces gráficas es probablemente
TortoiseGit. El propio Eclipse tiene también su propio Plugin de Git con interfaz gráfica. En
el desarrollo del proyecto Git ha tenido particular importancia. El repositorio de Weblab es
en la actualidad un repositorio Git, basado en Github. Todas las modificaciones realizadas
a Weblab se han hecho sobre ese repositorio (interviniendo por supuesto un fork local y
uno remoto, como es típico en los flujos de trabajo con Git).
También durante el desarrollo del proyecto se ha creado un repositorio Git para BooleDeusto, que originalmente estaba hospedado en un repositorio Svn sin información histórica real de versiones.
74
5.1.7 GitHub
GitHub es un servicio web orientado a hospedar proyectos de software que usan Git como
sistema de control de versiones. A pesar de que desafortunadamente, GitHub en sí no
es libre (de código abierto), sí que favorece a tales proyectos, siendo los repositorios y
las cuentas para ellos gratuitas. En los últimos tiempos se ha convertido de hecho en uno
de los servicios más populares para esta clase de proyectos.
Entre las características que ofrece, aparta de evidentemente la gestión básica de un
repositorio Git, es la fácil consulta online de los cambios recientes y commits, de los
usuarios que han intervenido en el desarrollo, de estadísticas, etc. También integra un
sistema de tickets, bugs e incidencias, que utiliza el propio proyecto de Weblab.
El repositorio Weblab (y por tanto, el desarrollo correspondiente durante este proyecto)
se encuentra actualmente allí hospedado [47]. Boole-Deusto, durante el desarrollo de
este proyecto, también ha pasado a ser hospedado en GitHub [3].
Podemos concluir, por tanto, que todo el trabajo realizado durante este proyecto, ya sea
aplicado a Weblab-Deusto o a Boole-Deusto, se ha realizado sobre uno de los dos repositorios hospedados en GitHub.
Figura 5.4.: Github. Repositorio del proyecto WebLab
En la Fig. 5.4 se muestra la vista de commits del repositorio WebLab [47], con algunos
de los commits de este proyecto en pantalla.
75
5. DESARROLLO
5.1.8 Blender
Blender es una herramienta bastante diferente a las anteriormente descritas. Es, en concreto, un software de modelado y animación 3D de código abierto.
Está desarrollado en C y utiliza Python como lenguaje de scripts. Esto último favorece la
presencia de scripts de todo tipo orientados a tareas específicas.
Si bien en entornos de diseño gráfico profesionales existen herramientas más frecuentemente utilizadas, como 3D Studio o Maya, la calidad y funcionalidad de Blender es
bastante comparable (y de hecho, se ha utilizado también en ciertas películas de animación y para algunos videojuegos y simulaciones profesionales).
La creación de modelos y entornos 3D de calidad profesional, si bien posible con Blender,
queda fuera del ámbito de este proyecto. Sin embargo, se ha utilizado Blender satisfactoriamente para crear de forma relativamente sencilla modelos de calidad suficiente. En
concreto, se ha utilizado para crear prácticamente todo el entorno 3D del experimento
con la simulación virtual de un tanque de agua, y se espera que sea utilizado en el futuro
para la creación de otros entornos virtuales.
Cabe notar que para la exportación de modelos a un formato más adecuado a ThreeJS
se ha utilizado un plug-in para blender provisto por la propia librería ThreeJS.
Figura 5.5.: Vista principal de Blender, con el depósito de agua desarrollado durante este
proyecto
76
5.2 DETALLES DEL DESARROLLO
En esta sección se describirá con cierto detalle y desde una perspectiva técnica el proceso de desarrollo de los elementos y componentes principales que ha tenido lugar durante
el proyecto.
Puesto que el proyecto involucra a varios elementos relativamente independientes entre
si, se divide esta sección en subsecciones, dedicadas cada una a uno de esos elementos.
5.2.1 Boole-Deusto
5.2.1.1 Introducción
Como se ha mencionado en secciones anteriores de este documento, Boole-Deusto es
un software relativamente antiguo. Desarrollado como un proyecto de código abierto utilizando Borland C++ Builder, su primera versión fue publicada en el año 2000. Esto implica
que, en el momento de escribir ésto, tiene más de 13 años.
Si bien se ha conservado el código fuente, no están disponibles (o no han podido ser
localizados) ni versiones anteriores a la usada ni documentación de desarrollo.
Puesto que para llevar acabo los objetivos de este proyecto se han requerido modificaciones significativas a Boole-Deusto, estos dos últimos hechos han conllevado ciertas
dificultades.
5.2.1.2 Dificultades de migración del entorno
Para poder realizar las extensiones y modificaciones requeridas con una cierta comodidad se considero la posibilidad de actualizar el entorno a uno más moderno, como podría
ser Embarcadero C++ Builder.
Desafortunadamente, surgieron dos problemas que lo impidieron:
Boole-Deusto utiliza un sistema de localizaciones basado en DLLs. Las traducciones se definen en la IDE utilizando diversas herramientas, y automáticamente se
crea un proyecto Borland DLL para cada lenguaje a traducir. Tras la carga del programa en su lenguaje base, automáticamente se carga el DLL correspondiente a
uno de los lenguajes, que hace que se carguen diálogos y mensajes traducidos.
En versiones modernas de los entornos Borland y derivados este sistema ya no
está disponible, puesto que el enfoque conllevaba varias limitaciones y era en la
mayoría de los casos poco conveniente. Hoy en día, se sugiere utilizar otros tipos
de métodos para internacionalizar las aplicaciones.
Reescribir el sistema de localizaciones requeriría una cantidad de tiempo y esfuerzo
notable, de modo que este hecho por si sólo impide la migración a un entorno actual.
77
5. DESARROLLO
La versión de Borland Builder en la que Boole-Deusto está basada tiene un soporte
limitado de UNICODE. Posiblemente por este motivo, su versión de la VCL, las
cadenas, macros, etc. están por defecto orientadas a ASCII.
En las versiones modernas, por el contrario, UNICODE ha pasado a ser la opción
por defecto, y se han producido numerosos cambios relacionados.
Debido al alto número de operaciones relacionadas con estos métodos que se llevan acabo en Boole-Deusto, el tiempo requerido para actualizar estos aspectos
hubiera sido considerablemente elevado.
Boole-Deusto depende de una versión antigua del framework de construcción de
intérpretes ANTLR.
Cambiar de entorno hubiera implicado también conseguir una versión moderna de
tal framework y realizar las adaptaciones oportunas.
Si bien hubiera sido factible, de nuevo hubiera supuesto una cantidad de tiempo
considerable.
Por todos estos motivos, se ha considerado más apropiado a las circunstancias del proyecto conservar el entorno original de desarrollo, optando por resolver de otras formas
los problemas que ésto conlleva.
5.2.1.3 Entorno basado en VirtualBox
Como se ha explicado en la sección anterior, no ha sido considerado factible actualizar
el entorno a uno moderno.
Sin embargo, Borland C++ Builder, ejecutado sobre un Windows 7 trabajando sobre
Boole-Deusto, causaba problemas significativos:
Errores al inicio
Tan sólo iniciar Borland Builder es suficiente para que aparezca una cierta cantidad de errores sobre archivos no encontrados. Si bien el entorno en si se carga
satisfactoriamente a pesar de los errores, no es un hecho positivo.
Opciones y menús ausentes
Se observó que diversos menús y opciones que deberían haber aparecido (según
la documentación de Borland y según capturas de pantalla), ejecutándose ahora
no estaban. Unos de estos menús eran los relacionados con traducciones, particularmente importantes para Boole-Deusto.
Tras fracasar los intentos habituales de solucionar estos errores, como pueden ser instalar y ejecutar la aplicación en modo administrador o probar los diversos ”modos de
compatibilidad”se optó por instalar el entorno en una máquina virtual.
Se procedió a instalar una versión de Windows XP en una máquina virtual VirtualBox.
Hecho esto, se instaló Borland Builder sobre dicha máquina.
78
De este modo, se consiguieron resolver todos los problemas listados anteriormente.
La mayor parte del desarrollo de Boole-Deusto que se ha realizado durante este proyecto
se ha llevado acabo sobre esta máquina virtual.
Figura 5.6.: Entorno Windows XP virtual utilizado para la modificación y extensión de BooleDeusto
5.2.1.4 Errores, interfaz y funciones básicas
Al comenzar el proyecto, ciertas áreas de Boole-Deusto como la generación de código VHDL tenían ciertas carencias o fallos menores. Se ha comenzado arreglando tales
fallos.
La funcionalidad de Boole-Deusto está dividida en dos modos. El modo combinacional y
el modo secuencial.
∎ Modo combinacional
Con lo que respecta a la interfaz, éste ha sido el modo que más trabajo ha requerido.
Se ha añadido un modo Weblab. Cuando está activo, la forma de seleccionar entradas y
salidas cambia. Se ha diseñado de tal modo que al estar activo dicho modo, el usuario,
al hacer click, pueda sencillamente elegir una de las entradas o salidas predefinidas de
una lista.
79
5. DESARROLLO
Cabe notar que es posible cambiar de un modo a otro sin pérdida de información.
Se han añadido también por supuesto los controles necesarios para, una vez que el
usuario desea probar su programa, generar el código VHDL especifico para Weblab (para
lo cual deberá encontrarse precisamente en modo Weblab) y para abrir el experimento
FPGA en un navegador.
∎ Modo secuencial
La interfaz de usuario del modo secuencial ha requerido menos extensiones. Puesto
que en este modo hemos considerado más conveniente que los nombres de entradas y
salidas sean fijos y sean asignados automáticamente, sólo ha sido necesario proveer los
mecanismos necesarios para seleccionar un reloj.
El reloj es un elemento necesario de un autómata. Con cada flanco de reloj, el estado del
autómata (potencialmente) cambia.
Se ha añadido soporte para varios tipos de reloj:
Interno: Se utiliza un reloj interno de 5 MHz incluido en la propia placa FPGA.
Externo: Se utiliza un reloj de Weblab. Su frecuencia es parcialmente configurable
(aunque el mínimo es bastante alto, por lo que no sirve realmente para depuración.
Interruptor/Botón: Un interruptor actúa como reloj. Esto permite al usuario producir
flancos cuando lo desea, y puede ser utilizado para depuración.
5.2.1.5 Generación de código
Los añadidos más notables con respecto a Boole-Deusto son probablemente aquellos
relacionados con la generación de código.
Si bien Boole-Deusto ha sido originalmente capaz de generar código VHDL tanto para
un sistema combinacional como para una autómata, dicho código VHDL es genérico y
no puede ser realmente usado tal cual.
Para satisfacer las necesidades de este proyecto era necesario que Boole-Deusto fuese
capaz de generar código VHDL del circuito en cuestión que fuese directamente grabable
en una placa hardware real de Weblab-Deusto.
Con vistas a ésto, se ha rediseñado parcialmente el sistema de generación de código.
El modo anterior se ha mantenido. Ahora se soporta también, sin embargo, la generación de código VHDL específico para Weblab-Deusto. Este código, que tiende a ser algo
más complejo que el código genérico, no requiere de ninguna modificación manual para
funcionar.
Para que esto sea posible, se utiliza un encabezado predefinido que incluye todas las
entradas y salidas de Weblab-Deusto-FPGA. Estas entradas se corresponden con las de
80
un archivo UCF1 que selecciona posteriormente2 Weblab-Deusto.
5.2.2 WebLab-Deusto: Sintetización de VHDL
5.2.2.1 Motivación
El experimento FPGA de WebLab-Deusto (WebLab-Deusto-FPGA) puede originalmente
recibir como entrada inicial del usuario un archivo BITSTREAM. Esto es un archivo binario, obtenido tras un proceso de síntesis3 notablemente complejo a partir de un VHDL y
un UCF.
Tradicionalmente, los usuarios llevaban acabo este procedimiento de síntesis en sus propias máquinas. Para ello, cada usuario debía instalar la suite de software Xilinx ISE, configurarla apropiadamente y utilizarla para generar el BITSTREAM.
Este proceso conlleva o conllevaba inconvenientes significativos:
El usuario debe instalar software en su equipo. Esto contraviene una de las ventajas
de WebLab-Deusto, que es la de gracias a su arquitectura Web poder ser utilizado
desde cualquier sitio necesitando tan solo un navegador.
El software Xilinx ISE no es un software menor. En su versión estándar ocupa alrededor de 6 gigas. Si bien las conexiones a Internet hoy en día tienden a ser relativamente rápidas, sigue siendo un requisito de descarga y de espacio en disco muy
alto.
El software Xilinx ISE requiere registro y licencia. A pesar de ser gratuito para la
mayor parte de usuarios, añade más pasos aún a un proceso de instalación ya de
por si largo.
Se requiere configuración específica. Xilinx ISE está orientado a muchos dispositivos distintos. El usuario no puede sencillamente crear un proyecto nuevo y esperar
que funcione con la placa específica de Weblab. Debe configurar diversos parámetros, no funcionando correctamente si no lo hace.
Se necesita un archivo UCF. Para generar un BITSTREAM, se necesita el VHDL
que describe la lógica, y el UCF que define cómo se aplica la lógica a la placa específica. Si el BITSTREAM lo genera el propio usuario, también debe contar con el
UCF, y por tanto deberá previamente descargarlo aparte de algún sitio, y configurar
su proyecto para usarlo.
1
User Constraints File. Estos archivos de restricciones son necesarios para sintetizar VHDL, ya que mapean
las entradas/salidas lógicas, definidas en el VHDL, con las entradas/salidas físicas (los pines) de la placa
hardware.
2
En el propio servidor de Weblab-Deusto existen varios UCF predefinidos. Dependiendo de ciertas circunstancias, como el reloj elegido, se selecciona uno u otro. El UCF no llega a estar nunca en el cliente, sólo
en el servidor, ya que sólo es requerido para la compilación. Esto aporta seguridad adicional.
3
El proceso de síntesis es aquel mediante el cual el comportamiento definido para un circuito de forma
abstracta se convierte en un diseño hardware real, implementado mediante puertas lógicas o en algunos
casos componentes especiales adicionales.
81
5. DESARROLLO
Es poco seguro para WebLab. El UCF, sobre el cual el usuario tiene control, es el
que define el mapeo de pines de la placa física. Si el mapeo es incorrecto, especialmente si se hace a propósito, podría llegar a ser posible causer daños físicos a
la placa.
Hace que el uso de Weblab-Deusto-FPGA sea imposible en móviles, tablets y dispositivos similares.
Por todos estos motivos, durante la ejecución de este proyecto se ha añadido a WebLabDeusto-FPGA la capacidad de aceptar como entrada del usuario un simple archivo VHDL,
y a partir de él generar en el propio servidor el BITSTREAM.
5.2.2.2 Implementación
Para permitir el proceso de síntesis en el lado del servidor es necesario que el propio Xilinx
ISE esté en el servidor y sea controlable por WebLab. Puesto que Xilinx ISE proveé un
conjunto de herramientas de consola, ésto ha sido razonablemente sencillo.
Se ha procedido a crear un sistema capaz de interactuar con dichas herramientas bajo
petición de WebLab, sintetizando código arbitrario (que en el caso concreto aportará el
usuario remoto) y permitiendo la extracción de un BITSTREAM ya compilado.
Para hacer la sintetización posible, se ha configurado un proyecto Xilinx de forma apropiada para WebLab.
Además, se han creado varios archivos UCF específicos con la placa física de WebLab.
El motivo de que exista más de un UCF es el número de relojes disponible. Como se
ha especificado en secciones anteriores, el usuario debe poder elegir entre cuatro relojes diferentes (interno, externo, interruptor, botón). Cada UCF contiene restricciones
ligeramente distintas, que configuran como reloj del sistema uno u otro.
Sin embargo, puesto que el usuario es quien decide el reloj, y el sistema sólo toma un
VHDL como entrada, el sistema no tendría en principio forma de conocer qué reloj desea
el usuario utilizar y por tanto qué archivo UCF utilizar.
Este problema se ha solucionado implementando soporte para un comando específico de
preprocesado dentro del VHDL. Cuando WebLab-Deusto recibe un archivo VHDL, busca
interiormente en su código dicho comando. Si lo encuentra, tal comando es el que indica
el reloj a utilizar.
Este comando puede ser introducido a mano por el usuario, pero también es introducido
automáticamente por el código generado por Boole-Deusto.
Cabe notar que la presencia del comando no afecta a la corrección del VHDL, ya que es
un comando especial incluido dentro de un comentario VHDL.
1
2
3
-- @@@CLOCK:WEBLAB@@@
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
82
4
5
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
6
7
8
entity base is
Port (
9
inicio : in std_logic;
clk : in std_logic;
10
11
12
led0 : inout std_logic;
13
14
15
16
-- [...]
17
18
19
20
21
22
23
swi7 : in std_logic;
swi8 : in std_logic;
swi9 : in std_logic
);
end base;
24
25
architecture behavioral of base is
26
27
28
29
30
31
begin
led0 <=
led1 <=
led2 <=
led3 <=
swi6;
swi5;
swi4;
swi3;
32
33
end behavioral;
Listado 5.1: Parte del código VHDL autogenerado por Boole-Deusto para un autómata
5.2.3 WebLab-Deusto: Infraestructura de creación de servidores de experimentos
en JavaScript
5.2.3.1 Motivación
En la actualidad, la mayor parte de servidores de experimento están creados en Python.
El motivo principal de ésto es, probablemente, que los servidores de WebLab (el núcleo
de WebLab) están integramente desarrollados en Python.
En realidad, se soportan múltiples tecnologías. Existen librerías disponibles para:
C
C#
C++
Java
83
5. DESARROLLO
Además, puesto que estos servidores de experimento utilizan XML-RPC4 para comunicarse con el núcleo de WebLab, resulta sencillo crear estas librerías.
Durante el desarrollo del proyecto se ha creado una librería adicional que permite la
creación de servidores de experimento mediante JavaScript.
A pesar de que JavaScript es tradicionalmente un lenguaje orientado a navegadores Web
y por tanto a aplicaciones cliente, en la actualidad está ganando una gran popularidad
como lenguaje de lado servidor.
Para ésto, se ha utilizado en este proyecto (y suele utilizarse en general) la tecnología
Nodejs.
Nodejs está basado en el motor V85 de Google. Es notablemente ligero y eficiente, contiene su propio servidor HTTP y está orientado a la programación asíncrona.
La librería de Weblab-NodeJS desarrollada durante este proyecto hace uso de XML-RPC
para proveer a los desarrolladores de experimentos una interfaz totalmente funcional y
sencilla y conveniente de utilizar.
5.2.4 WebLab-Deusto: Infraestructura de creación de clientes de experimentos en
JavaScript
5.2.4.1 Precedentes
Otro de los objetivos del proyecto ha sido mejorar el potencial de los experimentos de
WebLab-Deusto, y facilitar la creación de experimentos nuevos.
Los dos métodos más populares para ésto en los últimos tiempos han sido GWT y Adobe
Flash.
∎ GWT (Google Web Toolkit)
Puesto que el cliente de WebLab-Deusto (su núcleo) está creado en GWT, este ha sido
tradicionalmente el método más recomendado para crear experimentos nuevos. Esto implica crear el experimento en Java, que es eventualmente compilado por las herramientas
GWT a JavaScript.
4
XML-RPC es un estándar que describe una tecnología de llamada a procedimiento remoto. Se caracteriza
por estar orientada a procedimientos y no a objetos, por ser particularmente sencilla, por estar basada
en XML, y por existir librerías que la soportan en la mayor parte de lenguajes y entornos.
5
V8 es el nombre que recibe el motor JavaScript de Google. Es el motor utiliado por el navegador Chrome.
En el momento de escribir ésto, es considerado el motor de JavaScript más eficiente. Soporta compilación
Just In Time, de tal modo que antes de ejecutarse su código suele compilarse a código nativo. Esto lo
hace comparable en velocidad con lenguajes nativos como C. Se detalla más información en la sección
de tecnologías.
84
La ventaja de éste método es que la integración con el resto de WebLab es muy alta, y
que, puesto que eventualmente se compila a JavaScript, si está bien hecho el resultado
desde el punto de vista del usuario es bueno, siendo un código JavaScript particualrmente
eficiente, y siendo utilizable desde cualquier navegador, sin necesidad de plugins.
Tiene sin embargo ciertas desventajas para el desarrollador. A pesar de ser una tecnología de Google, no es particularmente conocida. Ciertamente, entre la comunidad de
desarrolladores Web es mucho menos conocido que el propio JavaScript que genera. En
ocasiones, además, desarrollar en Java, y especialmente en un Java bastante especial
como es el de GWT (debido a las limitaciones que supone el tener que ser eventualmente compilado a JavaScript) el proceso de desarrollo puede ser lento y poco satisfactorio.
También existen dificultades integrando las aplicaciones GWT con JavaScript, con librerías preexistentes o con otras tecnologías.
∎ Adobe Flash
Desde hace relativamente poco tiempo, WebLab-Deusto soporta también Adobe Flash
como uno de sus métodos para crear experimentos. Existen algunos experimentos notables que dependen de Adobe Flash, como puede ser VISIR.
Adobe Flash en algunos entornos es una tecnología muy conocida, de modo que es
adecuada para ciertos desarrolladores. Sin embargo, a partir de la aparición de HTML5,
está perdiendo rápidamente popularidad, ya que conlleva múltiples inconvenientes.
Perteneciendo a Adobe, en la práctica para su desarrollo se requiere de Adobe Flash,
que es software propietario y relativamente caro. Además, para su misma ejecución se
requiere del plugin de Adobe. Aunque es gratuito, tiene que ser instalado por los usuarios,
y de hecho en muchos sistemas móviles no está disponible. Otros usuarios sencillamente
no desean instalar plugins en su navegador, por motivos de seguridad, conveniencia, u
otras preferencias.
5.2.4.2 Motivación
La capacidad de poder crear experimentos en JavaScript nativo ventajas notables con
respecto a otros métodos.
Es importante tener en cuenta, además, que los dos métodos anteriores siguen por supuesto estando disponibles. Es elección del desarrollador de un experimento el utilizar
un método u otro, según más convenga.
Las ventajas principales son las siguientes:
JavaScript es un lenguaje conocido por la mayoría de desarrolladores, especialmente desarrolladores Web, e incluso en caso de no ser conocido en profundidaz es un lenguaje relativamente sencillo, y puede ser aprendido de forma
relativamente rápida.
85
5. DESARROLLO
JavaScript es extremadamente ubicuo. Todo ordenador con acceso a Internet
tiende a disponer de al menos un navegador Web, y todos los navegadores Web
principales soportan JavaScript. No se requieren plugins adicionales, y generalmente está habilitado por defecto. Funciona en cualquier dispositivo, incluyendo móviles
y tablets.
Existe un gran número de librerías JavaScript. Desde frameworks e interfaces
para aplicaciones Web, hasta motores gráficos. Los experimentos en JavaScript
nativo pueden acceder directamente a dichas librarías.
JavaScript, al contrario que tecnologías como Flash o GWT, no necesita compilación. El desarrollo por tanto tiende a ser más rápido. Sólo con recargar el navegador es suficiente para probar cualquier cambio. Además, prácticamente cualquier
navegador dispone de herramientas avanzadas para depuración de código JavaScript, como las DevTools de Chrome, o FireBug de Firefox.
Ha existido también una ventaja concreta más para este proyecto. Uno de sus objetivos era la creación de experimentos dotados de realidad mixta. Esto es, experimentos
capaces de mostrar un modelo de simulación idealmente tridimensional.
Para ésto, GWT o Flash claramente no eran opciones adecuadas. Se han considerado
brevemente alternativas, como un cliente C++ o un cliente C#.
Sin embargo, y pese a que los gráficos que tales tecnologías pueden mostrar son superiores, JavaScript y HTML5 han sido considerados como la mejor opción, por algunos de
los motivos anteriormente listados. Están disponibles en cualquier dispositivo, los gráficos son de calidad muy aceptable (especialmente con WebGL), y no se requieren plugins
ni aplicaciones aparta, lo que aumenta la conveniencia y la seguridad.
∎ Vista general
El núcleo del cliente de WebLab-Deusto es GWT. A partir de él están implementadas la
mayoría de las demás tecnologías Web soportadas, incluidos Flash y Java Applets.
El objetivo de este diseño es que los experimentos en este tipo de tecnologías puedan
ser independientemente desarrollados. Es decir, que sea posible crear el experimento y
luego integrarlo en el sistema sin necesidad de recompilar GWT.
Para crear un experimento Flash, por ejemplo, sólo es necesario, primero, crear el SWF
que contiene el experimento. Una vez hecho ésto, recompilar el cliente GWT no hace
falta. Basta con configurar el experimento, especificando en un archivo de configuración
el archivo donde encontrarlo (el URI del archivo SWF), así como los parámetros de inicio,
su tamaño visualmente, y algún parámetro adicional de configuración.
Puesto que este método es particularmente sencillo, cómodo y conveniente para el desarrollador del experimento, es el que se ha seguido con JavaScript.
86
Tal y como se ha implementado, para crear un experimento JavaScript sólo hace falta un
HTML o incluso un archivo JavaScript que defina la lógica del cliente.
Hecho ésto, se configura de manera muy similar a la que se configuraría un experimento
Flash, y el experimento es mostrado por WebLab en un iframe, que sencillamente referencia al HTML especificado (o, en el caso del archivo JavaScript, lo incluye dentro de
un archivo HTML creado ex-profeso).
1
2
"js"
: [
{
"experiment.name"
: "jsdummy",
"experiment.category" : "Dummy experiments",
"experiment.picture" : "/img/experiments/java.jpg",
"width"
: 500,
"height"
: 350,
//"js.file"
: "test.js",
"provide.file.upload" : true,
// If we use an html.file as base, we cannot use a js.file.
// (Though of course, we may include that js file from our html ⤦
Ç file).
"html.file"
: "jstest.html"
3
4
5
6
7
8
9
10
11
12
},
{
13
14
"experiment.name"
: "jsfpga",
"experiment.category" : "FPGA experiments",
"experiment.picture" : "/img/experiments/xilinx.jpg",
"width"
: 800,
"height"
: 600,
"provide.file.upload" : true,
"html.file"
: "jsxilinx/jsxilinx.html"
15
16
17
18
19
20
21
}
22
23
],
Listado 5.2: Configurando en el cliente dos nuevos experimentos JavaScript
Como puede verse, es particularmente sencillo añadir un nuevo experimento JavaScript.
Con lo que respecta al cliente, prácticamente lo único que es necesario hacer es crear el
experimento en HTML/JavaScript, y añadirlo como se muestra.
∎ API de WebLab-JavaScript
Por supuesto, el experimento que cree el desarrollador del experimento necesitará interactuar con WebLab.
Existen sólo unos pocos tipos de interacción. Los principales son éstos:
Enviar comando: El cliente del experimento envía al servidor del experimento un
comando de texto, y recibe una respuesta.
Enviar archivo: El cliente del experimento envía al servidor del experimento un archivo, y recibe una respuesta.
Recibir notificación de comienzo de experimento: El cliente del experimento se carga antes de que el usuario adquiera realmente una reserva. Deberá por tanto de
87
5. DESARROLLO
ser notifiado cuando el experimento comienza realmente, recibiendo además la información inicial que dependiendo del experimento se requiera.
Recibir notificación de tiempo restante: El cliente del experimento deberá conocer
cuánto tiempo queda de experimento. Esto suele recibirse al comienzo de un experimento, y depende generalmente de los privilegios del usuario que esté utilizando
el experimento.
Recibir notificación de finalización de experimento: El cliente del experimento debe
saber cuándo el experimento ha terminado, y por tanto no pueden ser enviados
más comandos al servidor (y quizás, algunos recursos deban ser liberados).
Forzar finalización del experimento: El cliente del experimento tiene además la capacidad de hacer que un experimento termine antes de tiempo.
En realidad, esta interacción está codificada en el cliente GWT. Para que sea accesible
a los experimentos JavaScript durante el desarrollo de este proyecto se ha hecho lo
siguiente:
En GWT, se ha creado una sencilla interfaz JSNI6 que publica tal funcionalidad. Las
funciones que publica son de difícil acceso y uso.
Para permitir un uso cómodo a los desarrolladores de experimentos, se ha creado
una pseudoclase7 JavaScript que encapsula toda la comunicación con WebLabDeusto. Esta API ha recibido el nombre de WeblabJS.
5.2.5 WebLab-Deusto: Infraestructura de modelos virtuales en JavaScript y ThreeJS
5.2.5.1 Motivación
Uno de los grandes objetivos de este proyecto es dotar a WebLab de las capacidades
necesarias para poder incorporar a algunos de sus actuales experimentos actuales (o
crear experimentos nuevos) realidad mixta. Es decir, incorporar a estos experimentos un
modelo virtual.
Este modelo virtual será en general distinto dependiendo del experimento y su complejidad dependerá totalmente del desarrollador.
Algunos posibles modelos que se han considerado durante el desarrollo de este proyecto,
por ejemplo, han sido un tanque de agua, el embalse de una central hidroeléctrica o una
línea de producción.
En todos estos casos, el usuario del experimento definiría la lógica para una placa FPGA que actuaría como controladora. Dicha placa sería real, y sin embargo controlaría el
modelo virtual.
6
JavaScript Native Interface. Es el nombre que recibe el sistema de GWT de interacción con JavaScript.
Permite utilizar JavaScript nativo, aunque está sujeto a bastantes restricciones.
7
JavaScript no soporta clases de primer nivel, pero existen diferentes sistemas para emular clases. En este
caso, se ha utilizado un sistema de clases basadas en closures.
88
De este modo, el usuario, por ejemplo, definiría un programa VHDL que se asegurase de
que un tanque de agua se mantuviese siempre lleno, utilizando unas bombas de agua
como entrada y teniendo una demanda de agua variable y aleatoria como salida. Después, WebLab-Deusto grabaría tal programa en una placa FPGA real, y esa placa FPGA
real actuaría sobre el modelo virtual, a la vista del usuario.
La interacción con el modelo virtual puede ir en ambos sentidos.
Las ventajas de este enfoque se han detallado ya en secciones anteriores: Un controlador físico real sobre un modelo virtual añade variedad a los experimentos de forma
muy económica, y es a la vez práctico (aplicaciones reales) y razonablemente realista (el
controlador sigue siendo real, a pesar de que el modelo no lo sea).
Durante la ejecución de este proyecto se creará al menos un experimento con realidad
mixta, con su correspondiente modelo virtual. Sin embargo, se espera que en el futuro
se creen varios experimentos adicionales, con un modelo distinto pero basados en el
mismo concepto. No resulta ésto particularmente difícil, ya que el hardware físico que se
requiere es el mismo. Una sola placa FPGA puede dar servicio a un número ilimitado de
simulaciones distintas (por supuesto, no al mismo tiempo).
Por este motivo, era extremadamente importante que las facilidades desarrolladas durante este proyecto fuesen todo lo genéricas y reutilizables como sea posible.
La tecnología que se ha elegido para crear las simulaciones ha sido ThreeJS, una librería
gráfica Web que soporta WebGL. Cabe notar que también soporta Canvas. Sin embargo, por sí sólo no es suficientemente eficiente como para gestionar de forma eficiente
simulaciones tridimensionales complejas.
ThreeJS tiene como ventaja el hecho de que es una librería relativamente popular y madura, siempre teniendo en cuenta lo especialmente reciente que es la tecnología WebGL.
Es una librería bastante simple, lo que en ciertos aspectos supone una ventaja, y en otros,
ante la necesidad de escribir uno mismo ciertas funcionalidades, un inconveniente.
Una de las funcionalidades más notables que se han añadido (no tanto a ThreeJS en
sí sino a la infraestructura de WebLab en general) es el sistema de carga del modelo.
Denominado WorldLoader, el sistema permite definir con detalle las características del
modelo de forma descriptiva y no procedimental utilizando una variación de JSON.
De este modo, la variación de JSON8 permite de forma muy sencilla especificar qué
elementos existen en la escena.
Además, pese a su sencillez de uso, permite callbacks y prácticamente cualquier clase
de JavaScript, de modo que resulta particularmente potente.
8
El estándar JSON tiene ciertas limitaciones. No permite, por ejemplo, números hexadecimales ni por supuesto funciones JavaScript. En este caso, la variación utilizada por el WorldLoader sí lo permite.
89
5. DESARROLLO
De este modo, crear un modelo virtual para un experimento es prácticamente tan sencillo
como crear el contenido, crear el archivo JSON que describe la escena del modelo virtual,
y definir la lógica y comunicación con el servidor de experimento de WebLab.
1
{
"metadata":
{
"format" : "myWorld",
"formatVersion" : 1.0
},
2
3
4
5
6
7
"objects":
[
{
8
9
10
"name" : "watertank",
"model" : "models/watertank.js",
"scale" : [100, 100, 100],
"position" : [600, 0, 0]
11
12
13
14
},
{
15
16
"name" : "water",
"model" : function() { return new THREE.CylinderGeometry(95, 95, ⤦
Ç 200, 50, 50, false); },
"initialTranslation" : [0, 100, 0],
"scale" : [.95, .1, .95],
"position" : [597, -95, 0],
"material" : function() { return new THREE.MeshBasicMaterial({ ⤦
Ç color: 0x0000FF }); },
17
18
19
20
21
22
},
{
23
24
"name" : "waterfallRight",
"model" : "models/waterfall.js",
"initialTranslation" : [-0.311444, 0, 0],
"scale": [100, 100, 100],
"position": [700, 0, 0],
"material" : function() { return new ⤦
Ç THREE.MeshBasicMaterial({color:0x0000FF}); }
25
26
27
28
29
30
},
{
31
32
"name" : "pipe",
"model" : "models/pipe.js",
"scale" : [100, 100, 100],
"position": [470, -80, 0]
33
34
35
36
},
{
37
38
"name" : "mediumMarkerFront",
"model" : function() { return new THREE.SphereGeometry(5, 10, ⤦
Ç 10); },
"material" : function() { return new THREE.MeshBasicMaterial({ ⤦
Ç color: 0xFF0000 }); },
"position" : [600, 0, -94]
39
40
41
42
},
43
44
],
45
46
"pointlights":
47
90
[
48
{
49
"name" : "light1",
"position" : [10, 250, 130],
"color": "0xFFFFFF"
50
51
52
}
53
],
54
55
"ambientlight":
{
"color" : "0xFFFFFF"
},
56
57
58
59
60
61
"onLoad" :
function() {
}
62
63
64
65
}
Listado 5.3: Parte del archivo de definición de escena (world.js) de FPGA Watertank
En el listado anterior, puede verse que definir una escena es en efecto sencillo. Además,
incluso cuando es necesario generar proceduralmente materiales o objetos, vemos que
puede hacerse sin necesidad de cambiar la estructura, gracias al formato JSON extendido
en el que se basa el sistema.
5.2.6 WebLab-Deusto: Modelo virtual de tanque de agua para WebLab-Deusto-FPGA
5.2.6.1 Motivación
Anteriormente, se han creado infraestructuras genéricas para facilitar la creación de todo tipo de experimentos con realidad mixta, orientadas principalmente a experimentos
electrónicos que consten de un modelo virtual con un elemento a controlar.
Como primer experimento, que demuestre el potencial de dichas infraestructuras y permita mejorarlas, se ha optado por desarrollar un experimento basado en WebLab-DeustoFPGA.
Tal experimento consiste en la placa FPGA física y además en un modelo virtual de un
tanque de agua, con dos bombas de agua y una salida variable.
El reto para el usuario consistirá por tanto en crear un VHDL que será grabado en la
placa FPGA física. La placa FPGA física será capaz de controlar las bombas de agua, y
además, recibirá como entrada la señal de los sensores de nivel virtuales que tendrá el
modelo virtual. De este modo, el usuario podrá, de forma más o menos realista, trabajar en
su controlador para el tanque de agua, observando los resultados e incluso interactuando
con el tanque de agua.
91
5. DESARROLLO
5.2.7 Implementación
Figura 5.7.: Experimento FPGA-Watertank
La placa FPGA física consta de LEDs como salidas, y de interruptores como entradas.
Los interruptores son virtuales. Es decir, en el experimento tradicional toman la forma de
interruptores, pero realmente son señales que el propio servidor de WebLab puede hacer
variar.
Esto es posible porque la placa FPGA física está unida a una placa PIC de control, que
es la que se encarga de asuntos tales como grabar el programa, resetearlo cuando es
necesario, o controlar las entradas.
Esto hace posible determinar desde el servidor de WebLab las entradas que recibe la
placa.
En los experimentos con modelo virtual, estas entradas, que normalmente son interruptores, representarán los sensores.
En nuestro caso, tenemos tres sensores virtuales de nivel. Se ha modificado el código
base del experimento de tal forma que estos tres sensores virtuales del modelo se reflejan
en la primera, segunda y tercera entrada de la placa.
Un experimento con modelo virtual consta de dos componentes principales:
Cliente. Muestra la simulación 3D con su correspondiente modelo virtual, la placa
física, y en algunos casos puede incluso permitir la interacción del usuario con la
placa o el entorno.
Servidor. Es donde realmente tiene lugar la simulación del modelo. El servidor calcula el estado de la simulación en base las entradas (los LEDs). Además, el servidor
se encarga de definir el estado de los sensores virtuales, y de hacer que el valor
92
que reciba la placa física se corresponda. También es el que serializa el estado de
la simulación para que el cliente pueda recibirla, interpretarla y mostrarla.
93
6. PROBLEMAS E INCIDENCIAS
El resultado del proyecto ha sido definitivamente satisfactorio. No obstante, durante el
transcurso del desarrollo han surgido ciertas dificultades, posiblemente motivadas por
el hecho de que el proyecto involucre un número alto de entornos y tecnologías muy
distintas.
En las secciones siguientes, se resaltarán algunas de las dificultades más relevantes,
algunas de las cuales se han mencionado de forma menos explícita en secciones anteriores.
6.1 ANTIGÜEDAD DEL ENTORNO DE DESARROLLO ORIGINAL
DE BOOLE-DEUSTO
Boole-Deusto fue desarrollado originalmente en Borland C++ Builder 5. Esta versión del
entorno de desarrollo rápido de Borland fue publicada en el año 2000.
A pesar de que el lenguaje base, C++, sea un estándar internacional, desafortunadamente Boole-Deusto en concreto depende totalmente de la librería VCL (Visual Components
Library) y en la práctica no resulta factible migrarlo a entornos modernos.
Sí que ha sido posible migrarlo a Borland C++ Builder 6, que es una versión ligeramente
más moderna que Borland C++ Builder 5 (fue publicada en el 2002).
El hecho de tener que utilizar un software de estas características ha supuestos considerables inconvenientes, que han multiplicado el tiempo que normalmente hubiera sido
necesario para realizar las extensiones y modificaciones que se han llevado a cabo durante el proyecto.
Los inconvenientes principales han sido:
6.1.1 Necesidad de un entorno virtual
Borland C++ Builder 6 no es verdaderamente compatible con versiones modernas de
Windows, como Windows Vista, Windows 7 o Windows 8.
Para el desarrollo, tras numerosos intentos de solucionar los problemas que surgían, se
ha tenido que optar por instalar un entorno virtual basado en VirtualBox y Windows XP
para poder realizar el desarrollo. Este entorno puede verse en la Fig. 5.6.
Si bien en este entorno Borland C++ Builder 6 funcionaba adecuadamente, desarrollar
en un entorno virtual ralentiza el proceso y es considerablemente incómodo, ante las
95
6. PROBLEMAS E INCIDENCIAS
dificultades de rendimiento, los límites de la tecnología utilizada, ciertas dificultades para
transferir archivos, etc.
6.1.2 Capacidades del entorno
Se podría decir que en su día Borland C++ Builder lideró la aparición de los entornos
RAD (Rapid Application Development). Por aquel entonces, se le consideraba a la altura
del Visual Studio de la época.
En los últimos 13 años, sin embargo, los entornos de desarrollo han mejorado extremadamente, y se puede afirmar que los entornos modernos, como Visual Studio 2012, son
muy superiores en su calidad, capacidades y usabilidad.
6.1.3 Interfaz anticuada
En 13 años, el estilo de las interfaces ha mejorado (o al menos cambiado) también notablemente. La interfaz basada en la VCL de Boole-Deusto como consecuencia no es ni
puede ser tan moderna visualmente como se desearía.
A pesar de que esto no supone en general un obstáculo para su usabilidad, sí que puede,
en un inicio, dar una impresión a los usuarios peor de lo que debiera.
6.2 SOPORTE DE WEBGL
A este respecto, la causa de los problemas es esencialmente la inversa de el caso de
Borland.
WebGL es una tecnología muy novedosa, y ciertos aspectos no están aun demasiado
estándarizados o documentados.
El resultado es que el comportamiento ha sido a menudo diferente entre navegadores.
Este hecho ha dificultado bastante el desarrollo, ya que en ocasiones, tras implementar
cierta característica que aparentemente funcionaba de forma satisfactoria, se ha descubierto que en algún navegador concreto o alguna versión concreta no funcionaba del
mismo modo.
El uso de ThreeJS, de todos modos, ha conseguido evitar en parte este problema.
Otra limitación actual de WebGL es el hecho de que no esté aun apenas presente en el
entorno móvil.
Los navegadores principales de móvil tienden a soportarlo en sus versiones más recientes, pero en ocasiones, como en el caso de Chrome, se requiere activarlo manualmente.
Además, de todos modos, una gran parte de usuarios de móviles no actualizan su navegador con frecuencia, por lo que estos usuarios no podrán usar la aplicación, en algunos
casos, o experimentarán un comportamiento incorrecto.
96
De todos modos, considerando el éxito que WebGL ha tenido, es de prever que en poco
tiempo esté soportado en todos los sistemas.
Según parece, incluso sistemas que originalmente se oponían a WebGL (generalmente,
por preferir alternativas propietarias propias), como puede ser Internet Explorer, planean
ofrecerlo en el futuro cercano en sus nuevas versiones.
97
7. MANUALES
7.1 GUÍA DE USUARIO DE BOOLE-WEBLAB-DEUSTO
7.1.1 Introducción
En esta guía se describe cómo utilizar Boole-Deusto con Weblab-Deusto. Las características de integración añadidas a Boole-Deusto hacen que sea posible y sencillo diseñar un
circuito combinacional o un autómata, y probarlo prácticamente al momento en un equipo
real provisto por Weblab-Deusto.
Boole-Deusto soporta dos tipos distintos de circuitos:
Circuitos combinacionales
Autómatas
Puesto que existen diferencias significativas entre ambos tipos, se dedicará a cada uno
una sección distinta de esta guía.
7.1.2 Circuitos Combinacionales
La mayor parte de características relacionadas con la creación de circuitos combinacionales no ha sufrido cambios con respecto al Boole-Deusto original.
El Boole-Deusto modificado tiene este aspecto:
99
7. MANUALES
Figura 7.1.: Pantalla principal de diseño de Sistemas Combinacionales
Como puede observarse, principalmente se han añadido algunos controles relacionados
con Weblab a la parte superior izquierda de la ventana.
En las secciones posteriores se describirá brevemente el propósito de estos nuevos controles, y se incluirá una guía rápida paso a paso para crear y probar un sistema combinacional.
7.1.2.2 Controles de Weblab
Los controles añadidos a Boole-Deusto son dos, cuyo propósito se describirá brevemente
a continuación.
∎ Activación / desactivación de Weblab
Este control sirve para activar o desactivar el modo weblab. El modo weblab puede ser
activado o desactivado en cualquier momento. Cuando está desactivado, Boole-Deusto
se comporta exactamente como el Boole-Deusto original. Cuando está activado, sin embargo, se producen los siguientes efectos:
Las tablas de entradas / salidas permiten elegir los nombres correctos, que se corresponden con las entradas / salidas en Weblab.
El código VHDL que Boole-Deusto genere será diferente al que normalmente generaría, ya que tendrá diversos cambios orientados a hacerlo directamente compatible
con el experimento FPGA de Weblab.
100
Advertencia: El sistema permite, al igual que el Boole-Deusto original, pero incluso
en modo weblab, asignar nombres arbitrarios de entradas y salidas, o incluso repetir
nombres existentes. Si bien el sistema en general funcionará de forma predecible al hacer
ésto, los programas generados no serán compatibles (al menos, sin previa modificación)
con Weblab-Deusto. Por eso, para facilitar el uso conjunto, se recomienda utilizar siempre
nombres de la lista de entradas/salidas y nunca repetirlos.
Advertencia: En este momento existe un bug conocido que impide en ocasiones, estado
en modo weblab, que aparezcan las sugerencias de entradas / salidas de Weblab. Debido
a ciertos motivos, esto tiende a suceder siempre que se hace click por primera vez en la
primera celda de la tabla de entradas y de salidas. Para evitarlo, se recomienda hacer
siempre click primero en otra celda. Es decir, en una celda que no sea la primera.
∎ Control de apertura de Weblab
Figura 7.2.: Botón para abrir Weblab-FPGA en el navegador por defecto
El botón “Open Weblab” abrirá una ventana del navegador que esté configurado por defecto, y generalmente tras dar al usuario la posibilidad de autenticarse, accederá directamente al experimento FPGA, lo que permitirá al usuario subir inmediatamente el código
VHDL que genere y probarlo de forma rápida y sencilla.
Nota: En este momento, el experimento Weblab-FPGA, que es el utilizado para probar el
código VHDL, requiere un usuario registrado en Weblab que tenga ciertos privilegios. Sin
dichos privilegios no será posible probar el código. En caso de que se necesiten obtener
tales privilegios, se recomienda ponerse en contacto con el equipo de Weblab-Deusto, o
con quien corresponda.
101
7. MANUALES
7.1.3 Creando y probando un sistema combinacional
En el transcurso de esta breve guía, crearemos con Boole-Deusto un nuevo sistema
combinacional, que después probaremos directamente en WebLab utilizando las nuevas
características de integración.
Para esta guía, se asume que el usuario está algo familiarizado con los sistemas combinacionales, y con el Boole-Deusto original.
1. Comenzamos la creación de un sistema combinacional.
2. Ahora, activaremos el modo Weblab, habilitando el control que se aprecia en la
siguiente figura, y que nos permitirá asignar fácilmente los nombres necesarios de
las entradas/salidas, así como generar código VHDL compatible con Weblab.
Figura 7.3.: Control de activación del modo WebLab
3. Con el modo Weblab habilitado, procedemos a dar un nomber al sistema, que en
este caso será XOR-AND, ya que, como veremos enseguida, calcular el XOR y el
AND será su tarea.
4. Definimos dos entradas y dos salidas, y les asignamos en la tabla los nombres.
En nuestro caso, las entradas se corresponderán con los dos primeros “switches”,
mientras que las salidas se corresponderán con los dos primeros “leds”. Es importante que los nombres utilizados sean exactamente los sugeridos por Boole-Deusto
al estar en modo Weblab, ya que es el nombre el que los relacionará posteriormente
con los componentes físicos reales (switches, leds, etc) de los que consta Weblab.
Queda así:
102
Figura 7.4.: Asignación de entradas y salidas compatibles con WebLab
5. Hecho esto, definiremos normalmente la tabla de verdad para nuestro sistema. Es
imprescindible hacer click en “evaluar” tras definirla. La tabla que utilizaremos será
la siguiente:
Figura 7.5.: Especificación de las tablas de verdad de un sistema combinacional
6. Una vez definida la tabla de verdad, podemos, si así lo deseamos, hacer uso de las
múltiples características que ofrece Boole-Deusto, tales como visualizar el circuito
o los diagramas que le corresponden.
7. Para poder probar nuestro sistema combinacional en Weblab-Deusto, deberemos
103
7. MANUALES
primero generar el código VHDL. Es imprescindible asegurarse de que antes de
generar el código, el modo Weblab esté habilitado. El código que se genera por
defecto (en el modo estándar) no es directamente compatible. Para generarlo, como
en el Boole-Deusto tradicional, deberemos utilizar el botón que se observa en la
figura siguiente. Podemos nombrar al archivo VHDL como deseemos.
Figura 7.6.: Botón para la generación de código VHDL
8. Con el código generado, ya estamos prácticamente listos para probar el sistema
combinacional. Si lo deseamos, podemos echar un vistazo al código que hemos
generado, o incluso modificarlo, siempre que respetemos ciertas reglas impuestas
por Weblab(principalmente, relacionadas con los nombres de entradas y salidas).
Para probarlo, haremos click en el botón “Open Weblab-FPGA”, que abrirá un navegador:
104
Figura 7.7.: Botón para la apertura de WebLab-FPGA en el navegador por defecto
9. Una vez abierto el navegador en la página de Weblab, si no lo hemos hecho ya,
deberemos autenticarnos. Una vez autenticados, llegaremos a la pantalla del experimento Weblab-FPGA, en la cual deberemos elegir el archivo VHDL que hemos
previamente generado, de tal forma:
Figura 7.8.: Selección del VHDL a grabar en WebLab-FPGA
10. Tras seleccionar el archivo, deberemos darle a “reserve”, que reservará el experimento. Dependiendo del estado de Weblab-Deusto, y de la la existencia o no de
una cola de usuarios, transcurrirá más o menos tiempo antes de que la reserva
concluya. La figura a continuación es la pantalla que veremos una vez realizada la
105
7. MANUALES
reserva.
Figura 7.9.: Sintetización y grabación del VHDL en la placa FPGA
11. Mientras esté presente la barra de progreso, el sistema estará, o bien sintetizando
el código VHDL, o programando la placa. Puesto que especialmente la sintetización
es un proceso lento, pueden llegar a transcurrir varios minutos antes de que termine.
Si la barra se detuviese con un error, se recomienda consultar la advertencia que se
incluye al final de esta sección. El resto de la guía asume que tanto la sintetización
como la programación son correctas.
12. Una vez que el programa ha sido correctamente sintetizado, y la placa correctamente grabada, veremos algo similar a lo siguiente:
Figura 7.10.: Experimento FPGA activo con la placa grabada y en ejecución
13. Finalmente, vemos que disponemos en primer lugar de una webcam, por la que podemos ver la placa física, que está actualmente ejecutando nuestro sistema com-
106
binacional. Podemos ver también los leds, que actúan como salidas, y diversos
interruptores virtuales, que actúan como entrada física real a la placa, y mediante los cuales podemos interactuar. En este caso, vemos que con los interruptores
a “0-1” está encendido el segundo LED, y apagado el primero, tal y como hemos
definido en nuestra tabla de verdad.
14. Disponemos de un tiempo limitado para probar el sistema. Una vez que el tiempo
expire, el sistema automáticamente volverá a la pantalla de reserva. Si necesitamos
realizar más pruebas, deberemos reservar de nuevo.
Nota: Los leds (Leds<0-8>), los interruptores (Switches<0-9>) y los botones (Buttons<03>) se ordenan de derecha a izquierda. Esto implica, por ejemplo, que el Switch<0> en
Boole-Deusto se corresponde con el interruptor de más a la derecha, mientras que el
Switch<1> sería el inmediatamente a su izquierda.
Advertencia: Si la barra se detuviese con un “compiling error” o con un “programming
error”, significaría, en el primer caso, que el proceso de sintetización ha fallado (quizás
debido a un error de sintáxis), y en el segundo, que el proceso de programación de la
placa ha fallado. Si el error es del primer tipo (compiling error) se recomienda:
Comprobar que se ha seleccionado el VHDL correcto.
Comprobar que el VHDL se ha generado en modo Weblab.
Comprobar que todas las entradas y salidas utilizan nombres válidos de la lista de
entradas y salidas de Weblab, y que por tanto no se han incluido entradas/salidas
con nombres originales, ni entradas/salidas con nombres repetidos.
Comprobar que no se hayan realizado modificaciones manuales al VHDL, o que en
caso de que se hayan realizado, no contengan errores.
Si con las diversas comprobaciones anteriores no se consigue resolver el problema, o si
el error es de programación (grabación), se recomienda:
Esperar un tiempo, y volver a intentarlo más tarde.
Contactar con los administradores de Weblab-Deusto.
107
7. MANUALES
7.1.4 Autómatas
Figura 7.11.: Diseño de autómatas. Opciones de generación de código VHDL compatible con
WebLab-Deusto
El segundo tipo de circuito con el que Boole-Deusto puede trabajar son los autómatas. Esta característica, que ya existía en el boole-deusto original, ha sido extendida añadiendo
capacidad de integración inmediata con Weblab-Deusto y en concreto sus experimentos
FPGA. Tras esta extensión, es ahora posible diseñar y definir un autómata gráficamente,
e inmediatamente observarlo en funcionamiento (e interactuar con él) en un FPGA físico
real en Weblab-Deusto.
7.1.4.2 Aspectos básicos con Weblab-Deusto
En su versión actual, para promover la simplicidad, esta parte de Boole-Deusto no requiere (ni permite) elegir las correspondencias entre las salidas y entradas de los estados, y
las salidas y entradas de Weblab-Deusto. En vez de eso, se ha de saber que la correspondencia entre entradas y salidas siempre es la misma:
Las entradas son siempre los interruptores. De este modo, si tenemos por ejemplo un estado S0 que “recibe” dos entradas, estas dos entradas se corresponderán con los últimos
dos interruptores (los de más a la derecha).
Las salidas son siempre los LEDs. De este modo, si tenemos un estado S0 que tiene dos
salidas, estas dos salidas se corresponderán con los últimos dos LEDs (los de más a la
108
derecha). Si la salida del estado es por ejemplo “01”, el LED de más a la derecha estará
encendido, y el LED inmediatamente a su izquierda apagado.
Existe un botón que devuelve al autómata a su estado inicial. Este botón es siempre el
último botón de Weblab (el de más a la derecha).
7.1.4.3 Controles de Weblab
Figura 7.12.: Diseño de autómatas. Posibles relojes de WebLab-Deusto-FPGA
Podemos ver en la Fig. 7.13 los controles que han sido añadidos a Boole-Deusto.
Se diferencian dos tipos:
Apertura de Weblab: Abrirá Weblab-Deusto-FPGA en un navegador.
Generación de código VHDL con reloj específico: Permite generar código VHDL
compatible con WebLab-Deusto que utilice un reloj determinado.
7.1.4.4 Exportación a código Weblab-VHDL
Mediante el uso de estas opciones, es posible generar código VHDL que sea inmediatamente compatible con el experimento FPGA de Weblab-Deusto. Para conseguir esta
compatibilidad, el código generado utilizará nombres de entradas y salidas compatibles
con las de Weblab-Deusto (definidas en un UCF).
Podemos observar que existen varias opciones para generar el código. Cada una de esas
opciones corresponde a un tipo de reloj diferente, que utilizará el autómata. Los relojes
disponibles son los siguientes:
109
7. MANUALES
Reloj Interno (Internal Clock)
Utiliza el reloj interno de la FPGA. Su frecuencia es bastante alta, lo que lo hace
poco adecuado para aquellos casos en los que el comportamiento del autómata
requiera de alguna clase de sincronización de las entradas y salidas con el reloj.
Reloj Weblab (Weblab Clock)
Algo más lento que el reloj interno. Está provisto por el propio Weblab-FPGA, y su
frecuencia puede ser controlada de forma limitada, mediante un slider en el propio
experimento.
Reloj Interruptor (Switch Clock)
El último interruptor (el de más a la izquierda) actúa como reloj. Esto lo hace muy
adecuado para aquellos casos en los que se desee probar el autómata teniendo un
absoluto control sobre el reloj. Esto podría incluir, por ejemplo, aquellos casos en
los que es necesario sincronizar las entradas con él.
Reloj Botón (Button Clock)
Similar al anterior, en este caso el botón de más a la izquierda actúa como reloj. De
nuevo, muy adecuado para aquellos casos en los que se desee probar el autómata
teniendo un absoluto control sobre el reloj.
Advertencia: Debido a limitaciones presentes ya en el Boole-Deusto original, se recomienda comprobar el autómata antes de intentar generar el código. Ciertos errores,
como el no asignar salidas a un estado, pueden hacer que el programa deje de responder.
Advertencia: Si se utiliza la generación de código VHDL estándar de Boole-Deusto
(la que no hace mención sobre relojes, ni sobre Weblab), el VHDL generado NO será
compatible con Weblab-Deusto. Al menos, sin aplicar manualmente grandes modificaciones.
Nota de implementación: En la práctica, el reloj a utilizar no lo determina el VHDL en
sí, sino el archivo de restriccines (UCF) que se utilice. Boole-Deusto añade una directiva como comentario al VHDL, como por ejemplo %̀ % %CLOCK:SWITCH % % %‘. Esta
directiva, en absoluto original de Xilinx, es detectada por el propio Weblab-Deusto, que
sintetizará el VHDL provisto utilizando un UCF u otro. Cuando se utiliza Weblab-Deusto
FPGA también es posible usar dichas directivas en código VHDL escrito manualmente.
110
7.1.4.5 Apertura de Weblab
Figura 7.13.: Diseño de autómatas. Controles de Boole-Weblab-Deusto, incluido el botón de
“Start Weblab”
El botón “Open Weblab” abrirá una ventana del navegador que esté configurado por defecto, y generalmente tras dar al usuario la posibilidad de autenticarse, accederá directamente al experimento FPGA, lo que permitirá al usuario subir inmediatamente el código
VHDL que genere y probarlo de forma rápida y sencilla.
Nota: En este momento, el experimento Weblab-FPGA, que es el utilizado para probar el
código VHDL, requiere un usuario registrado en Weblab que tenga ciertos privilegios. Sin
dichos privilegios no será posible probar el código. En caso de que se necesiten obtener
tales privilegios, se recomienda ponerse en contacto con el equipo de Weblab-Deusto, o
con quien corresponda.
7.2 GUÍA DEL EXPERIMENTO FPGA WATERTANK
En esta sección se describe el funcionamiento del experimento FPGA Watertank, y se
explica cómo crear y probar un programa VHDL para el controlador.
7.2.1 Introducción
FPGA Watertank es un experimento de la familia de los experimentos FPGA que tiene
como objetivo controlar un depósito de agua virtual (utiliza realidad mixta).
Como en la mayoría de los demás experimentos de esta clase, permite grabar en una
placa FPGA física (totalmente real) un programa.
111
7. MANUALES
Este programa puede venir de dos formas:
Archivo BITSTREAM: Archivo binario terminado en .bit que especifica la lógica del
programa y la correspondencia de cada entrada/salida con los pines de la placa. Los
archivos BITSTREAM deben sintetizarse previamente utilizando las herramientas
Xilinx ISE.
Archivo VHDL: Archivo fuente terminado en .vhd que contiene código fuente que
especifica la lógica del sistema. Para ser válido debe cumplir ciertas restricciones en
cuanto a los nombres y presencia de las entradas/salidas. Pueden ser generados
por Boole-Deusto, en cuyo caso estas restricciones se cumplen automáticamente.
En el experimento, encima de la placa física, hay un modelo virtual tridimensional de un
tanque de agua.
El objetivo del experimento es, precisamente, controlar el tanque de agua utilizando como
controlador la placa FPGA real.
7.2.2 Funcionamiento de un modelo virtual
Los experimentos con modelo virtual combinan una placa controladora real con el
modelo virtual. En este caso, la placa controladora es una FPGA. El objetivo suele ser
crear un programa que será grabado en la placa, y que deberá controlar el modelo virtual.
En el caso del tanque de agua, por ejemplo, el objetivo generalmente será mantener el
volumen de agua en un rango determinado.
Para que el experimento tenga sentido, la placa controladora y el modelo virtual deben,
por supuesto, ser capaces de interactuar en ambos sentidos. Es decir, los sensores virtuales del modelo virtual deben llegar de algún modo a la placa controladora real, y al
mismo tiempo, la placa controladora real debe de algún modo poder dar órdenes o afectar al modelo virtual de alguna forma.
La solución ha sido utilizar los LEDs de la placa como señales al modelo, y los interruptores de la placa como entradas a la placa.
Esto quiere decir que si en el modelo virtual un determinado sensor virtual está activado,
en la placa física uno de los interruptores, por ejemplo swi0 se activará. Los interruptores
(y por tanto los sensores virtuales) pueden por supuesto ser accedidos desde el programa
VHDL grabado en la placa.
De forma similar, si la placa quiere enviar una señal positiva al modelo virtual, puede
hacerlo utilizando los LEDs. Por ejemplo, poniendo led0 a uno surtirá efecto en algunos
modelos virtuales (incluyendo el del tanque de agua).
La especificación exacta del modelo del tanque de agua se explica a continuación.
112
7.2.3 Tanque de agua
Figura 7.14.: Interfaz del experimento FPGA-Watertank (tanque de agua)
El tanque de agua pretende imitar el comportamiento de un tanque de suministro de agua
tradicional.
El modelo, en este caso, tiene una demanda de agua variable. Esto quiere decir que si
no hay una entrada de agua, con el tiempo se vaciará. La demanda cambia periódicamente, y se determina de forma aleatoria.
Para poder llenar el tanque, existen dos bombas de agua. Estas bombas de agua son
controlables por el usuario.
Para activar la primera bomba, será necesario activar el led0 de la placa controladora.
Para activar la segunda, será necesario activar el led1.
Es posible conocer el nivel del tanque de agua. Para ésto, cuenta con tres sensores
virtuales.
La altura de dichos sensores es del 20 %, del 50 % y del 80 % respectivamente. La placa
recibe sus señales en el swi0, swi1 y swi2 respectivamente.
En resumen, la especificación técnica del tanque de agua:
Demanda (salida) de agua variable en el tiempo y aleatoria. No controlable.
113
7. MANUALES
Bomba 1. Se activa con led0.
Bomba 2. Se activa con led1.
Sensor de altura 20 % → swi0.
7.2.4 Otros detalles
El experimento tiene un modo pantalla completa. Para activarlo, hacer click en el
control reservado al efecto.
Hay interruptores disponibles. La salida de dichos interruptores se transmite directamente a la placa.
En la parte superior derecha puede verse el aparente estado de los LEDs. Puesto
que el estado de los LEDs es obtenido por el servidor utilizando técnicas de visión
artificial y existe además una latencia, es posible que el estado de los LEDs en un
momento dado no coincida con la realidad.
7.2.5 Ejemplos
El siguiente ejemplo de programa VHDL enciende la primera bomba cuando el depósito
está por debajo de la mitad, y enciende las dos bombas cuando el depósito está por
debajo del 20 %.
1
2
3
4
5
-- @@@CLOCK:WEBLAB@@@
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
6
7
8
entity base is
Port (
9
inicio : in std_logic;
clk : in std_logic;
10
11
12
led0
led1
led2
led3
led4
led5
led6
led7
13
14
15
16
17
18
19
20
:
:
:
:
:
:
:
:
inout
inout
inout
inout
inout
inout
inout
inout
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
21
ena0 : inout std_logic;
22
23
24
114
25
26
27
28
29
30
31
32
33
seg0
seg1
seg2
seg3
seg4
seg5
seg6
:
:
:
:
:
:
:
inout
inout
inout
inout
inout
inout
inout
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
34
35
dot : inout std_logic;
36
37
38
39
40
but0
but1
but2
but3
:
:
:
:
in
in
in
in
std_logic;
std_logic;
std_logic;
std_logic;
swi0
swi1
swi2
swi3
swi4
swi5
swi6
swi7
swi8
swi9
);
end base;
:
:
:
:
:
:
:
:
:
:
in
in
in
in
in
in
in
in
in
in
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic;
std_logic
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
architecture behavioral of base is
56
57
58
59
60
begin
led1 <= not swi1;
led0 <= not swi0;
61
62
end behavioral;
Listado 7.1: Código VHDL de un sistema controlador del depósito de agua.
El código puede parecer complicado debido a su longitud. Sin embargo, se ha de tener en
cuenta que prácticamente toda la parte perteneciente a definiciones de entradas/salidas
es fija, y está presente en todo programa VHDL para WebLab-FPGA.
La parte más notable del programa sería por tanto:
1
2
led1 <= not swi1;
led0 <= not swi0;
Listado 7.2: Definiendo el valor de las salidas
La primera línea activa el led1, y por tanto enciende la segunda bomba, cuando el sensor
virtual de nivel 50 % no está activado. La segunda, activa el led0, y por tanto enciende la
primera bomba, cuando el sensor virtual de nivel 20 % no está activado.
115
7. MANUALES
7.3 GUÍA DE DESARROLLO DE BOOLE-DEUSTO
En el momento de comenzar el desarrollo de Boole-WebLab-Deusto, no existía (o no
estaba disponible) documentación alguna sobre el desarrollo de Boole-Deusto. Tampoco
versiones del código anteriores a la creación del repositorio GIT de código, creado para
el proyecto.
La información contenida en este breve documento, por tanto, está formada principalmente por asunciones, y puede esperarse que contenga ciertas imprecisiones y omisiones.
No obstante, puesto que Boole-Deusto es un sistema relativamente antiguo y existen
ciertas complejidades relacionadas con su desarrollo y su entorno, se espera que el documento pueda ser particularmente útil, en caso de que se requieran modificaciones en
el futuro.
7.3.1 Entorno de programación
El programa Boole-Deusto está desarrollado en Borland C++ Builder. En concreto, parece que la última versión que es razonablemente compatible es Borland C++ Builder
6. Depende absolutamente de la VCL (Visual Components Library) de Borland, y por lo
tanto no puede ser fácilmente portado a entornos diferentes, más modernos.
Existen versiones más recientes de C++ Builder, tales como Embarcadero C++. Aunque
se ha considerado portarlo a una de estas versiones antes de comenzar el proyecto, se
ha llegado a la conclusión de que no es factible hacerlo en un tiempo moderado.
Los motivos princiaples por los que se ha descartado (podrían existir más), son los siguientes:
Las versiones modernas tienen muchos cambios con respecto a soporte de UNICODE, que ha pasado en ciertos ámbitos a ser la opción por defecto. Esto ha implicado
diversos cambios a la API de la VCL. Debido al código de Boole-Deusto en general, y en concreto al sistema de lenguajes, adaptarlo implicaría cambios bastante
significativos.
Las versiones modernas no soportan el sistema de traducciones y localización que
el proyecto utiliza. Actualizarlo supondría posiblemente utilizar un sistema de localizaciones nuevo, teniendo posiblemente que añadir a mano todas las traducciones
que existen hoy, y realizar numerosos cambios a la interfaz y al sistema en general,
para que soporte la carga de traducciones en este hipotético nuevo formato.
No parece factible convertir el propio archivo de proyecto de forma automatizada (si
bien teóricamente debería convertirse, parece ser que para proyectos no triviales
está prácticamente garantizado el tener que crear uno nuevo). Aunque esto supondría un trabajo mucho menor que, por ejemplo, el punto anterior, sigue siendo una
inconveniencia seria.
116
Existe una dependencia externa de una versión concreta de la librería ANTLR. Posiblemente actualizar a una versión más moderna implicaría actualizar también la
dependencia externa, y realizar los cambios necesarios.
Han existido muchos problemas a la hora de elegir y adaptar un entorno de desarrollo
adecuado. La versión que más se ajusta, Borland C++ Builder 6, no es totalmente compatible con las versiones modernas de sistemas operativos. En concreto, hay numerosos
problemas con Windows 7, y, asumo, con Windows Vista y Windows 8. La falta de compatibilidad no es completa (hay errores sueltos, se cuelga, y el sistema de lenguajes en
concreto no funciona bien, pero las características principales, al menos ejecutando como
administrador, sí que funcionan, de modo que quizás sea usable, con suficiente cuidado
y evitando los bugs). Personalmente, he instalado Borland en una máquina virtual con
Windows XP. Esto soluciona directamente diversos errores, principalmente, relativos al
Translation Manager y sistema de lenguajes en general, y alguno más. Es por tanto el
enfoque recomendado.
7.3.2 Sistema de lenguajes
El sistema de localización que utiliza el proyecto es un sistema bastante extraño, que
aparentemente ya no se soporta en versiones modernas, identificable como Resource
DLLs.
El entorno de Borland genera de manera semi-automática un proyecto diferente para
cada lenguaje extra. Este proyecto, que contiene básicamente archivos relativos a los
formularios y otra información de traducción, al compilar genera un DLL con extensión
dependiente del lenguaje. Por ejemplo, para inglés genera un boole.ENU. El programa,
en su carga, puede cargar el DLL con la función LoadResourceDLL y el Locale correspondiente.
Ha sido notablemente complicado conseguir que el sistema de lenguajes funcionase, y,
de hecho, se nesita tener en cuenta ciertas consideraciones específicas, que se expondrán a continuación, sin seguir un orden concreto.
El archivo de proyecto “correcto”, de los muchos que en el momento de escribir
ésto hay, es boole_grp.bpg. Este archivo de proyecto (realmente, archivo de grupos
de proyecto), hace referencia al proyecto principal (boole.bpr) y a los proyectos
de Resource DLL de cada lenguaje. Por regla general, para el desarrollo, deberá
siempre partirse de éste grupo.
Al hacer build del proyecto boole.exe, se compila únicamente el .exe, no los archivos
de lenguaje. Para que funcione cada lenguaje, se ha de compilar cada proyecto, que
produce un DLL con diferente extensión (.ENU etc).
Puede accederse al gestor de traducciones (Translation Manager) a través de View>Translation manager. Bajo ciertas circunstancias, puede ocurrir y ha ocurrido que
en Borland no aparezca tal opción. Puede tratar de solucionarse reinstalando Borland, reinstalándolo en un Sistema Operativo más antiguo, ejecutando el Borland
como Administrador, etc.
117
7. MANUALES
El Translation Manager se utiliza para realizar las traducciones de cada lenguaje.
Al salir no se genera nada por sí sólo. Para que se apliquen las traducciones, debe
recompilarse cada DLL y ser colocado en el lugar correcto (generalmente junto al
.exe de Boole-Deusto).
Si se han producido cambios a los formularios, o posiblemente alguna clase adicional de cambios, no basta con utilizar el Translation Manager para que los DLLs
de lenguajes se actualicen correctamente. En tales casos, hay que utilizar el “Update Resource DLLs”. Esta opción está (o debiera estar) disponible en: Project>Languages->Update Resource DLLs. De nuevo, puede ocurrir, por fallo, que tal
opción no esté visible.
Cuando se actualizan los lenguajes tras un Update Resource DLLs hacen falta pasos adicionales para conseguir que los lenguajes vuelvan a funcionar como se espera, debido principalmente a ciertos errores con la generación que hay que solucionar manualmente. Estos errores se indican a continuación. Si por ser un cambio
menor (que no afecta a los formularios) no ha sido necesario hacer el Update, posiblemente los pasos a continuación sean prescindibles.
El directorio de salida de los proyectos de lenguajes es incorrecto. A través del Project Manager, debería es recomendable especificar ../exe como directorio de salida.
En cualquier caso, aunque se seleccione otro, es necesario que exista previamente.
Todos los proyectos de lenguaje tienen un archivo boole.cpp autogenerado, que
hace referencia a los diversos formularios. En un inicio, aparecen errores de linker
al tratar de hacer referencia a .OBJs, porque los paths que se encuentran en este
archivo son incorrectos. El error es sencillamente que utilizan una sóla barra (“\”)
en vez de dos. Para arreglarlo, basta con acceder a cada archivo boole.cpp autogenerado, y hacer un search-replace de “\çon “\\”. Tras ésto, el proyecto debería
compilar con éxito.
Existe un mensajes.rc, que contiene una tabla de cadenas presente en un mensajes.inc. En cada lenguaje existe una copia diferente de estos dos archivos. Aunque el mensajes.rc parece que puede actualizarse para cada lenguaje a través del
Translation Manager, se necesitará añadir a mano cada entrada al mensajes.inc.
Puesto que el mensajes.inc generalmente será realmente el mismo para todos los
lenguajes, posiblemente copiar y pegar el mensajes.inc principal en cada lenguaje
también sería suficiente (si bien no se ha probado).
En ocasión la terminación asignada por Borland a los DLLs no se corresponde con la
de los “locales” de Winnt.h. Por ejemplo, para Euskera Borland genera un archivo
boole.EUS. Por algún motivo no determinado, sin embargo, Borland al cargar el
LANG_BASQUE intenta encontrar el boole.EUQ. La “solución” que de momento se
ha aplicado es, sencillamente, renombrar manualmente el boole.EUS generado por
boole.EUQ.
El boole.cpp del proyecto principal (boole.exe) es el que decide qué lenguaje se carga. Si bien parece haber código mezclado de diferentes métodos, en la actualidad el
que se encuentra activo lo que hace es leer un archivo ”boole.lang”, y dependiendo
118
de su contenido cargar el DLL correspondiente a un locale u otro. En el momento
de escribir ésto, los lenguajes bien soportados son el por defecto (Castellano), inglés (en), euskera (eu). Están parcialmente soportados (pueden cargarse, pero no
hay apenas traducciones) el catalán (ca) y el portugúes (pt). El boole.lang puede
por tanto contener una de las siguientes cadenas: ( es|en|eu|ca|pt ). Esto debería
tenerse en cuenta en el caso de querer añadir un nuevo lenguaje.
7.4 GUÍA DE DESARROLLO DE CLIENTES DE EXPERIMENTOS
EN JAVASCRIPT
Nota: La versión original de este manual, en inglés, está disponible online [9].
Una forma sencilla de desarrollar un experimento es utilizar JavaScript estándar. A pesar
de que de este modo no se tiene acceso a ciertos widgets GWT que ya están implementados, y a pesar de que implica que el desarrollador deberá implementar la mayor parte
del experimento y la interfaz, tiene ciertas ventajas:
Es sencillo. Simplemente se desarrolla un archivo HTML, sin ninguna restricción.
Se referencia un JavaScript que el propio WebLab provee para hacer de interfaz
con el servidor.
No implica ninguna dependencia, aparte de un simple JavaScript (la librería anteriormente mencionada).
Pueden desarrollarse nuevos experimentos sin necesidad de compilar nada.
Puede hacerse uso de cualquier librería o framework de JavaScript.
Es posible desarrollar y probar experimentos offline, sin necesidad de desplegar
o ejecutar antes WebLab. Puede sencillamente abrirse el archivo HTML con un
navegador.
7.4.1 Qué desarrollar
Para crear un nuevo experimento, esencialmente se necesita:
Un servidor de experimento
Un cliente de experimento
Esta sección, como se ha indicado, se dedica al último caso (un cliente de experimento).
Un cliente de experimenot rpovee la interfaz y lógica cliente necesaria para su particular
experimento. Se comunica con WebLab y el servidor de experimento a través de una API
muy sencilla.
Una buena forma de comenzar, sin embargo, es sencillamente crear un nuevo directorio,
con un archivo HTML vacío. Si bien tiene cierta libertad sobre dónde ponerlo, es recomendable que se coloque dentro del directorio “public” del cliente estándar de WebLab.
119
7. MANUALES
Por ejemplo, si su experimento fuera a controlar una bombilla remota, podría crear un
jslightbulb.html, en la dirección siguiente:
src/es/deusto/weblab/public/lightbulb/jslightbulb.html
El directorio público automáticamente se exporta cuando se despliega WebLab, así que
siéntase libre de poner cualquier número de archivos HTML, JavaScripts, o imágenes (o,
de hecho, cualquier tipo de archivo) dentro del directorio.
Este HTML que acaba de crear contendrá la interfaz de su experimento. Se mostrará
dentro de WebLab-Deusto como un iframe. Si seguimos el ejepmlo anterior (un experimnento para controlar remotamente una bombilla), podría querer añadir, quizás, la salida
de una webcam al HTML (para poder ver la bombilla) y quizás algún botón en JavaScript
(para poder encender y apagar la bombilla).
Debido a que se trata simplemente de HTML estándar, puede usar cualquier librería o
framework para facilitar su trabajo.
Actualmente, sin embargo, nuestro experimento de la bombilla no se conecta realmente a
WebLab. Posiblemente se pregunte, por tanto, cómo realmente decirle a la bombilla que
se apague o se encienda cuando el usuario presione su botón JavaScript. Esto es, cómo
enviar un comando al servidor de experimento (que, se entiende, controlará directamente
el hardware de la bombilla).
Esto se hace a través de la API JavaScript, que se describe a continuación.
7.4.2 API JavaScript
La API WebLabJS es relativamente sencilla. Las funciones más notables que provee,
que son todas las que realmente se necesitan, son las siguientes:
Enviar un comando.
Enviar un archivo.
Recibir una notificación de tiempo-restante.
Recibir una notificación de comienzo de experimento.
Recibir una notificación de fin de experimento.
Obligar al experimento a terminar antes de tiempo.
Para JavaScript, esta API puede encontrarse aquí:
src/es/deusto/weblab/public/jslib/jsweblab.js
Es posible simplemente referenciarla desde su HTML. Por ejemplo, si su HTML está
dentro de public/jslightbulb/jslightbulb.html, puede, dentro de <head>:
1
<script src="../jslib/weblabjs.js"></script>
Listado 7.3: Referenciando WeblabJS
120
A continuación, se incluyen los prototipos de las funciones de WeblabJS:
1
2
3
4
5
6
7
8
9
//! Sends a command to the experiment server.
//!
//! @param text Text of the command.
//! @param successHandler Callback that will receive the response for the ⤦
Ç command.
//! Takes a single string as argument.
//! @param errorHandler Callback that will receive the response for the command.
//! Takes a single string as argument.
//!
this.sendCommand = function (text, successHandler, errorHandler)
10
11
12
13
14
15
16
17
//! Sets the callback that will be invoked when the experiment finishes. ⤦
Ç Generally,
//! an experiment finishes when it runs out of allocated time, but it may also
//! be finished explicitly by the user or the experiment code, or by errors and
//! and disconnections.
//!
this.setOnEndCallback = function (onEndCallback)
18
19
20
21
22
23
24
25
26
27
28
//! Sets the callbacks that will be invoked by default when a sendfile request
//! finishes. The appropriate callback specified here will be invoked if no
//! callback was specified in the sendFile call, or if the sendFile was done
//! from GWT itself and not through this API.
//!
//! @param onSuccess Callback invoked when the sendFile request succeeds. Takes
//! the return message as argument.
//! @param onError Callback invoked when the sendFile request fails. Takes the
//! return message as argument.
this.setFileHandlerCallbacks = function (onSuccess, onError)
29
30
31
32
33
//! Sets the startInteractionCallback. This is the callback that will be invoked
//! after the Weblab experiment is successfully reserved, and the user can start
//! interacting with the experiment.
this.setOnStartInteractionCallback = function (onStartInteractionCallback)
34
35
36
37
38
39
40
41
42
43
44
//! Sets the setTime callback. This is the callback that Weblab invokes when ⤦
Ç it defines
//! the time that the experiment has left. Currently, the Weblab system only ⤦
Ç invokes
//! this once, on startup. Hence, from the moment setTime is invoked, the ⤦
Ç experiment
//! can take for granted that that is indeed the time it has left. Unless, of ⤦
Ç course,
//! the experiment itself chooses to finish, or the user finishes early.
//!
//! @param onTimeCallback The callback to invoke when Weblab sets the time ⤦
Ç left for
//! the experiment.
//!
this.setOnTimeCallback = function (onTimeCallback)
45
46
47
//! Sets the three Weblab callbacks at once.
//!
121
7. MANUALES
48
49
50
51
52
53
54
55
//! @param onStartInteraction Start Interaction callback.
//! @param onTime On Time callback.
//! @param onEnd On End callback.
//!
//! @see setOnStartInteraction
//! @see setOnTimeCallback
//! @see setOnEndCallback
this.setCallbacks = function (onStartInteraction, onTime, onEnd)
56
57
58
59
60
//! Retrieves a configuration property.
//!
//! @param name Name of the property.
this.getProperty = function (name)
61
62
63
64
65
66
67
//! Retrieves a configuration property.
//!
//! @param def Default value to return if the configuration property
//! is not found.
this.getPropertyDef = function (name, def)
68
69
70
71
72
//! Retrieves an integer configuration property.
//!
this.getIntProperty = function (name)
73
74
75
76
77
78
79
//! Retrieves an integer configuration property.
//!
//! @param def Default value to return if the configuration property
//! is not found.
this.getIntPropertyDef = function (name, def)
80
81
82
83
//! Finishes the experiment.
//!
this.clean = function ()
84
85
86
87
88
89
90
//! Returns true if the experiment is active, false otherwise.
//! An experiment is active if it has started and not finished.
//! That is, if the server, supposedly, should be able to receive
//! commands.
//!
this.isExperimentActive = function ()
91
92
93
94
95
96
//! Checks whether this interface is actually connected to the real
//! WebLab client.
//!
//! @return True, if connected to the real WL client. False otherwise.
this.checkOnline = function ()
97
98
99
100
101
//! This method is for debugging purposes. When the WeblabJS interface is used ⤦
Ç stand-alone,
//! offline from the real Weblab client, then the response to SendCommand will ⤦
Ç be as specified.
//!
//! @param response Text in the response.
122
102
103
104
//! @param result If true, SendCommand will invoke the success handler.
//! @param result If false, SendCommand will invoke the failure handler.
this.dbgSetOfflineSendCommandResponse = function (response, result)
Listado 7.4: WeblabJS API (Weblab class)
Usar la API es muy fácil. Una vez que el script ha sido incluido, puede simplemente:
1
2
3
4
5
6
7
8
Weblab.sendCommand( "LIGHTBULB ON",
function(response) {
console.log("Light turned on successfully");
},
function(response) {
console.error("Light failed to turn on");
}
);
Listado 7.5: Ejemplo de uso de WeblabJS
Cabe notar que, como se puede ver arriba, hay ciertas funciones que comienzan con
“dbg”. Estas funciones tienen como propósito ayudar a la depuración. En ocasiones, por
ejemplo, es conveniente ser capaz de ejecutar la interfaz en HTML por sí sola, sin Weblab.
Para poder hacer que el experimento se comporte en este caso de una forma similar a
la habitual, se pueden usar las funciones de depuración para simular respuestas que
normalmente daría el servidor, o para usos similares.
123
8. CONCLUSIONES Y TRABAJO FUTURO
En este apartado se tratará sobre los resultados obtenidos por el proyecto.
Se compararán además dichos resultados con los objetivos iniciales, para considerar en
qué grado han sido satisfechos.
La sección concluirá con el trabajo futuro.
8.1 RESULTADOS
Los resultados del proyecto han sido muy satisfactorios. A pesar de que especialmente en un inicio las dificultades relacionadas con Boole-Deusto fueron bastante grandes,
finalmente fue posible resolver todos los problemas graves que se encontraron.
Igualmente, a pesar de la relativa novedad de WebGL, el resultado de la tecnología ha
sido bueno. Los experimentos con modelos virtuales creados durante el desarrollo del
proyecto son, como se esperaba, prácticos y a la vez usables, satisfaciendo así las expectativas.
La integración entre Boole-Deusto y WebLab-Deusto ha demostrado ser particularmente
potente. Los usuarios tan sólo necesitan el propio Boole-Deusto, un navegador de Internet y una conexión. Con ésto, pueden, en tan sólo unos minutos, diseñar desde cero un
sistema digital (ya sea un autómata o un circuito combinacional), probarlo con apenas
unos pocos clicks en una placa física real a través de WebLab-Deusto, y, si lo desean,
observar si la placa real es capaz de controlar un modelo virtual de la forma esperada.
Todo el proceso está altamente integrado, y es posible llevarlo acabo en sólo unos minutos. Con sistemas tradicionales, dependiendo de placas físicas no remotas y de software
especializado que el propio usuario debería instalar en su máquina, el mismo proceso requiere en la mayoría de los casos horas, y está sujeto a diversos fallos y complejidades
adicionales.
La curva de aprendizaje, además, es notablemente baja. La complejidad viene dada únicamente por el sistema digital a diseñar y por el modelo virtual a controlar (en caso de
elegir tal opción). Por ello, el sistema es útil y se adapta a un rango muy amplio de estudiantes y usuarios.
Dicho rango podría incluir:
Estudiantes de colegios, aprendiendo los conceptos básicos sobre sistemas digitales, que diseñarían y probarían con apoyo de Boole-Deusto sistemas digitales
básicos, probablemente combinacionales.
125
Estudiantes más avanzados, de los primeros cursos de carreras universitarias
técnicas, que diseñarían esos mismos sistemas digitales, y también sistemas digitales más complejos, como autómatas, apoyados también por Boole-Deusto.
Estudiantes avanzados o profesores, que con o sin apoyo de Boole-Deusto diseñen sistemas de control en VHDL, arbitrariamente complejos (posiblemente, escribiendo o modificando manualmente el VHDL, en vez de generarlo automáticamente).
Profesionales trabajando en el diseño de sistemas de control reales, que deseen
utilizar WebLab-Deusto para probar su sistema de forma sencilla y rápida en un
entorno físico real, ahorrándose el tiempo y recursos necesarios que normalmente
requeriría el adquirir un sistema de prototipos, construir su sistema de pruebas, etc.
Además, en cuanto a los experimentos con modelo virtual, cabe destacar que ha sido
posible aislar una gran parte de funcionalidad común y encapsularla en un framework
genérico, sencillo y rápido de utilizar pero al mismo tiempo de gran potencia y flexibilidad.
Cabe por tanto esperar que sea muy útil para los futuros desarrolladores de experimentos
relacionados.
También es particularmente satisfactorio el hecho de que con las infraestructuras creadas
durante el desarrollo del proyecto, es ahora posible la creación de experimentos completos íntegramente en JavaScript, sin necesitar de compilar WebLab-Deusto y sin depender
de ninguna tecnología o librería adicional.
El lado cliente del experimento es JavaScript estándar y se comunica con WebLab mediante una simple librería JavaScript, y el lado servidor del experimento es posible gracias
a NodeJS.
126
Figura 8.1.: FPGA-Watertank, ejecutándose en un tablet
Vemos además, como muestra la Fig. 8.1, que los experimentos WebGL en general, y
FPGA-Watertank en concreto, pueden ya hoy ejecutarse incluso en tablets, lo que supone
grandes posibilidades para el futuro.
8.2 COMPARACIÓN CON OBJETIVOS
No sin cierto esfuerzo, todos los objetivos iniciales del proyecto han sido cumplidos.
Los objetivos han sido los siguientes:
La interfaz de Boole-Deusto permite una relación intuitiva con WebLab-Deusto.
Boole-Deusto genera código VHDL directamente compatible con WebLab-Deusto,
tanto para los autómatas como para los sistemas combinacionales.
Boole-Deusto y WebLab-Deusto pueden utilizarse de forma conjunta satisfactoriamente. Hace falta un sólo click para que el experimento correcto se abra en un
navegador.
127
Los usuarios no necesitan ningún software aparte del propio Boole-Deusto (y por
supuesto un navegador) para diseñar un sistema y probarlo en un sistema real. Es
posible realizar el proceso completo en tan sólo unos minutos.
WebLab-Deusto-FPGA es ahora capaz de compilar archivos VHDL. Tanto VHDL
generados por Boole-Deusto, como VHDLs creados manualmente por usuarios independientes de WebLab-Deusto.
Es ahora posible crear experimentos utilizando sólo JavaScript, tanto en lo que
respecta a servidor como en lo que respecta a cliente.
Existe la infraestructura necesaria para crear fácilmente un experimento con modelo
virtual, dotado de realidad mixta, de forma sencilla. Se puede utilizar un formato de
declaración de escenas propio, bassado en JSON pero más potente, gracias a su
soporte para eventos y callbacks.
Se ha creado un experimento utilizando dicha infraestructura de realidad mixta. En
concreto, un experimento de tipo FPGA mediante el que el usuario puede definir
la lógica de control de un tanque de agua, y donde dicho tanque de agua, virtual,
interactua en ambos sentidos con el programa del usuario.
8.3 TRABAJO FUTURO
Tras el desarrollo del proyecto, podemos afirmar que los resultados han sido muy satisfactorios, y que se han cumplido las expectativas. El proyecto ha sido amplio y se han
mejorado de forma notable las capacidades de Boole-Deusto y de WebLab-Deusto.
Sin embargo, los buenos resultados dejan patente, de hecho, el gran potencial que tienen
conceptos como:
La integración de software educativo de diseño electrónico con WebLab-Deusto
La extensión de un experimento electrónico con una base física real con un modelo
virtual (que sería prohibitivo de implementar físicamente)
La creación de experimentos remotos, cliente y servidor incluidos, utilizando sólo
JavaScript
Podemos afirmar, por tanto, que hay muchas líneas futuras abiertas, y mucho espacio
para mejorar y trabajar sobre dichos conceptos.
Integración de software de diseño electrónico en WebLab-Deusto
En este ámbito, en el futuro se podría aumentar el nivel de integración. En el caso
concreto de Boole-WebLab-Deusto, sería posible por ejemplo automatizar aun más
el proceso, haciendo que la generación y subida del código VHDL se una en un
mismo paso, y que el usuario, si no lo desea, no llegue a conocer la generación
del código, sino que éste se grabe en la placa física de WebLab-Deusto de forma
transparente.
128
Otra línea de trabajo podría ser la integración de WebLab-Deusto con un software distinto. Este software podría variar desde otros software educativos de diseño
electrónico, hasta software orientado al diseño profesional, como Proteus.
También sería interesante la creación de nuevo software de diseño electrónico, posiblemente con un ámbito reducido, orientado por ejemplo a usuarios de colegios.
Dicho software podría ser compatible con móviles y tablets, lo que facilitaría en gran
parte el trabajo en tales entornos. Esto podría hacer posible, por ejemplo, diseñar
en un tablet un sistema de control digital (definiendo en el tablet la tabla de verdad),
y en el mismo probarlo en la placa física real, e incluso en un modelo virtual.
Experimentos con modelo virtual
En el ámbito de los experimentos de realidad mixta, existe también mucho trabajo
que hacer.
Las infraestructuras genéricas que han sido creadas hacen que sea relativamente
sencillo crear modelos virtuales nuevos, de forma que es de esperar que en el futuro
se desarrollen un gran número de simulaciones distintas. En concreto, las simulaciones que probablemente se implementen en un futuro cercano son una simulación
para el sistema de control de control de calidad de una línea de producción, y para
el sistema de control del embalse de una central hidroeléctrica.
Experimentos en JavaScript
JavaScript es en la actualidad una de las tecnologías más ubicuas. Originalmente,
el desarrollar experimentos para WebLab no ha sido un trabajo sencillo. En general,
los desarrolladores externos al propio weblab tenían dificultades porque el método
mejor soportado tradicionalmente ha sido GWT (cliente) y Python (servidor).
Esto es frecuentemente poco conveniente por dos motivos. Primero, son dos tecnologías distintas, de modo que en general, los desarrolladores para crear un sólo
experimento se veían obligados a aprender ambas. Además, especialmente GWT,
no es una tecnología particularmente conocida, de modo que las posibilidades de
estar familiarizado desde un inicio son escasas. Segundo, GWT requiere compilación, en general, junto con el resto del cliente de WebLab, lo que es un tanto
incómodo a la hora de desarrollar un experimento que realmente no involucra a
ninguna parte del núcleo del cliente.
Pudiendo desarrollar ambas partes sólo en JavaScript, se evitan ambos problemas.
Los desarrolladores sólo deben familiarizarse con un lenguaje. Además, el lenguaje
es particularmente conocido y a la vez simple, prácticamente cualquier programador Web en particular lo habrá utilizado, aunque haya sido superficialmente. Permite, en definitiva, desarrollar un experimento nuevo con la facilidad con la que se
desarrollaría una página web sencilla.
129
9. POSIBLE PLAN DE NEGOCIO
En este capítulo, se ha desarrollado un posible plan de negocio basado en las tecnologías
de Laboratorios Remotos desarrolladas por la Universidad de Deusto en torno al proyecto
WebLab-Deusto.
Con respecto a la configuración de dicho Plan de Negocio, se ha seguido principalmente
el modelo propuesto por SCORE [41]. Se han omitido ciertas secciones que normalmente
aparecerían en un Plan de Negocio por no considerarse apropiadas en este trabajo, o
por no considerarse apropiadas para este posible Plan de Negocio específico.
9.1 RESUMEN EJECUTIVO
Este plan de negocio propone una iniciativa para la prestación de servicios de experimentación remota a centros formativos.
El sector de los laboratorios remotos y la experimentación remota es un sector nuevo,
pero su crecimiento está prácticamente garantizado, motivado por el auge de la formación
a distancia y de los MOOC (Cursos Online Masivos y Abiertos), que en los últimos tiempos
ha experimentado un crecimiento exponencial.
En la actualidad, la experimentación remota podría ser útil a muchos centros formativos
y en muchos contextos. Los laboratorios remotos de hoy en día, como WebLab-Deusto,
soportan un gran número de experimentos de diferentes campos, tales como la electrónica, la programación de microcontroladores, la física, la biología, etc. Gracias a un
laboratorio remoto, es posible mejorar la oferta formativa mejorando la eficiencia de uso
de los equipos, facilitando el acceso, reduciendo costes, etc.
Sin embargo, para desplegar y gestionar con éxito un laboratorio remoto se requieren
muchos recursos, y sobre todo, personal especializado, con gran experiencia y conocimiento técnico.
Esto hace que sin ayuda los laboratorios remotos sean prohibitivos para prácticamente
cualquier institución pequeña o mediana, y que sólo estén realmente al alcance de unas
pocas universidades. Generalmente, sólo de aquellas que realizan investigación relacionada con el área.
Por este motivo, la Empresa cuenta con una gran ventaja competitiva, al disponer de años
de experiencia en la creación, desarrollo y uso de laboratorios remotos en un entorno
académico, estando directamente relacionada con el desarrollo de una de las principales
infraestructuras de laboratorios remotos del mundo, WebLab-Deusto.
En estas circunstancias, el objetivo de la Empresa es ofrecer a sus clientes sus propios
laboratorios remotos, encargándose de gestionar todo el proceso, que incluye compra de
131
equipos, montaje, despliegue, pruebas, etc.
Los servidores y demás equipamiento, además, serán hospedados en instalaciones de la
propia empresa. De éste modo, el cliente final queda exento de cualquier responsabilidad
técnica, y no necesita dedicar recursos o personal técnico al laboratorio remoto.
Así, con sólo un relativamente modesto pago inicial, y un pago periódico (mensual o
trimestral) un centro formativo tal como un colegio, un centro de formación profesional
o una universidad, podrá tener su propio laboratorio remoto, con las ventajas que ésto
aporta.
9.2 DESCRIPCIÓN GENERAL DE LA COMPAÑÍA
9.2.1 Misión
Proporcionar a instituciones educativas y empresas servicios y productos de experimentación remota efectivos, asequibles económica y técnicamente, generalizando así conocimientos y facilidades que anteriormente estaban reservados a unas pocas universidades.
Aprovechar el conocimiento adquirido durante años de investigación en el campo de la
experimentación remota para consolidarse y mantenerse como una empresa líder.
Promover el desarrollo del campo de la experimentación remota, mejorando la tecnología
y creando conocimiento.
9.2.2 Visión
Los laboratorios remotos son una tecnología relativamente reciente. Hasta ahora, han
estado al alcance solamente de unas pocas instituciones de gran tamaño, que tendían,
con un coste en dinero y capital humano significativo, a desarrollar sus propias soluciones.
Prevemos un futuro en el que cualquier colegio, universidad o organización en general,
sin importar su tamaño, pueda proporcionar a sus estudiantes acceso a un sistema de
experimentación remota, tecnología que hasta hace poco ha estado reservada sólo a
unos pocos.
Un futuro en el que la educación de todos sea más cómoda, más práctica, más efectiva
y más satisfactoria y no se vea limitada por la falta de recursos o infraestructura.
9.2.3 Metas y objetivos
9. Meta: Dar a conocer la experimentación remota, sus capacidades y las ventajas que
aporta, dentro del ámbito educativo nacional.
132
9.1. Objetivo: Establecer relaciones con un número significativo de colegios del
entorno de Bilbao. Dar a conocer la existencia de los sistemas de experimentación remota y de sus ventajas a responsables de éstos centros, y al menos a unos
pocos profesores que impartan asignaturas con particular potencial para beneficiarse de dichas tecnologías en el futuro inmediato. Esto incluye actualmente a
aquellos profesores que impartan asignaturas relacionadas con electrónica digital,
circuitos electrónicos, informática básica, programación de microcontroladores y
física. Los esfuerzos se centrarán principalmente en el ámbito de la electrónica
digital básica y de física (circuitos básicos).
9.2. Objetivo: Establecer relaciones con un número significativo de centros de
formación profesional del entorno de Bilbao. Dar a conocer la existencia de los
sistemas de experimentación remota y de sus ventajas a responsables de éstos
centros, y al menos a unos pocos profesores que impartan asignaturas con particular potencial para beneficiarse de dichas tecnologías en el futuro inmediato.
Esto incluye actualmente a aquellos profesores que impartan asignaturas relacionadas con electrónica digital, circuitos electrónicos, informática básica, programación de microcontroladores y física. Los esfuerzos se centrarán principalmente en
el ámbito de la programación de microcontroladores, de la electrónica digital y de
los circuitos electrónicos.
10. Meta: Desarrollar un modelo de servicio que permita a los clientes acceder a facilidades de experimentación remota sin necesidad de contar con personal técnico de ninguna
clase, y sin necesidad de gestionar técnicamente su laboratorio remoto.
10.1. Objetivo: Aprovechar las capacidades de federación existentes del Laboratorio Remoto (y extenderlas si es necesario) para que el equipo de la empresa pueda fácilmente crear y gestionar laboratorios remotos para los clientes, que
puedan ser hospedados y gestionados técnicamente en instalaciones de la propia
empresa. Evitar que se requiera cualquier clase de infraestructura en las dependencias de los clientes.
10.2. Objetivo: Continuar mejorando las capacidades e interfaces de administración del Laboratorio Remoto (WebLab-Deusto) de tal modo que los clientes
puedan, sin necesidad de conocimientos técnicos, administrar su laboratorio remoto de forma efectiva, y minimizando la necesidad de requerir ayuda específica
de personal de la empresa.
10.3. Objetivo: Gestionar todo el proceso de creación y gestión de los laboratorios. El cliente sólo necesitará especificar qué experimentos requiere su laboratorio. La empresa llevará acabo las operaciones requeridas, incluyendo compra
y montaje de servidores y equipos de experimentación específicos, instalación y
prueba de software, despliegue y gestión técnica del laboratorio.
10.4. Objetivo: Hospedar todos los laboratorios en la empresa, evitando que el
cliente necesite mantener ninguna clase de infraestructura o equipamiento en sus
propias dependencias (a no ser que por cualquier circunstancia especial requiera
lo contrario).
133
11. Meta: Extender a nuevas áreas el alcance de la experimentación remota ofrecida por
la empresa, de acuerdo a las necesidades aún no satisfechas de los clientes.
11.1. Objetivo: Averiguar campos nuevos que pueden hacer uso de experimentación remota, considerando, entre otros, áreas de la biología, la física, la ingeniería,
etc.
11.2. Objetivo: Desarrollar sistemas (equipos y software) que permitan satisfacer
necesidades insatisfechas detectadas en nuevas áreas.
12. Meta: Desarrollar un modelo de colaboración con los centros educativos para la creación de experimentos específicos que aporten valor a su oferta educativa.
12.1. Objetivo: Establecer acuerdos con centros educativos para el diseño y desarrollo de experimentos nuevos que requieran en sus cursos. Dichas iniciativas serán financiadas en parte por la empresa y en parte por dichos centros, dependiendo de cada caso específico y de las prospectivas o acuerdos que se establezcan
para proporcionarles posteriormente servicios relacionados.
9.3 FILOSOFÍA DEL NEGOCIO
La Empresa está comprometida a mejorar la educación, tanto tradicional como a distancia, a través de tecnologías y servicios de experimentación remota, esforzándose para poner al alcance del mayor público posible equipamiento al que de otro no tendrían
acceso, posibilitando una formación práctica que de otro modo sólo habría podido ser
teórica.
Se dará a conocer la experimentación remota a centros educativos nacionales, incluyendo colegios, centros de formación profesional y universidades, pero, si las circunstancias
lo permiten, se realizarán también esfuerzos orientados a aumentar el ámbito internacionalmente.
La experimentación remota es un mercado muy nuevo. Hasta hace poco limitado al ámbito académico, y de naturaleza muy experimental. No obstante, podemos esperar un gran
crecimiento. El auge de la formación a distancia y el actual éxito de los MOOC (Cursos
Online Masivos y Abiertos) es innegable. Las empresas y los estudiantes demandan a los
centros educativos formación cada vez más práctica y especializada. El entorno, en definitiva, garantiza un interés y potencial creciente en los laboratorios y la experimentación
remota.
La Empresa, directamente relacionada con la Universidad de Deusto y con el desarrollo
de la infraestructura de laboratorios remotos WebLab-Deusto, está en una posición única
para aprovechar el crecimiento de este mercado. Los años de experiencia en experimentación remota y desarrollo de experimentos, que han situado a WebLab-Deusto como
uno de los mejores laboratorios remotos del mundo, garantizan una posición en la cima
de este mercado emergente.
134
9.4 PRODUCTOS Y SERVICIOS
La Empresa ofrece, principalmente, laboratorios remotos como servicio.
Un laboratorio remoto es un conjunto de hardware y software que permite la experimentación remota:
13. Hardware
13.1. Servidores: De diversos tipos. Se necesita uno o varios servidores
Web, servidores para los experimentos, etc.
13.2. Red: Se necesita una potente infraestructura de red, capaz de dar un
servicio de calidad y fiable a los usuarios del laboratorio, que acceden a él
necesariamente por éste medio, y capaz de dar soporte a las necesidades
de comunicación interna del laboratorio.
13.3. Equipamiento habitual de experimento: La mayor parte de experimentos requieren de una o varias webcam, de un servidor de experimento
(generalmente un ordenador pequeño, como un FitPC), etc.
13.4. Equipamiento específico: La mayor parte de experimentos necesitan
alguna clase de equipo específico, que es el foco del experimento. Por
ejemplo, los experimentos FPGA necesitan, lógicamente, una placa FPGA
sobre la que experimentar.
14. Software
14.1. Básico: Software de uso general, incluyendo bases de datos, servidores Web, entornos de ejecución, etc.
14.2. Laboratorio Remoto: Software base del laboratorio remoto, como el
núcleo de WebLab-Deusto (tanto servidor como cliente).
14.3. Servidores y clientes de experimentos: Cada experimento específico no sólo requiere de equipamiento propio, sino que también tendrá
generalmente un cliente Web (o de otra clase) y una lógica (servidor de
experimento) propia.
Dada la naturaleza y complejidad de un laboratorio remoto, la adquisición del equipamiento descrito no es suficiente por sí sóla.
En el empleo real de un laboratorio remoto están involucradas muchos procesos y actividades:
1. Adquisición del equipamiento y hardware
2. Despliegue de servidor web, base de datos, etc.
3. Despliegue del laboratorio.
4. Montaje, instalación y despliegue de los experimentos específicos.
5. Configuración del laboratorio remoto.
135
6. Mantenimiento del laboratorio remoto.
a) Administración.
b) Mantenimiento de servidores y experimentos.
En la actualidad, todos estos procesos requieren de tiempo, una amplia experiencia, y
amplios conocimientos técnicos.
La mayor parte de usuarios potenciales de laboratorios remotos, es decir, instituciones
educativas de tamaño pequeño o medio, no disponen de los recursos necesarios para
adquirir todos los servidores y equipos, y mucho menos del conocimiento y experiencia
requerida para el despliegue con éxito de un laboratorio.
Tales conocimientos han estado, hasta ahora, reservados a un pequeño número de universidades con proyectos de investigación abiertos en el área.
Una de éstas universidades es, de hecho, la Universidad de Deusto, cuyo laboratorio
remoto de código abierto WebLab-Deusto es uno de los primeros del mundo, y la base
de los servicios ofrecidos por esta empresa.
El fin de la empresa es, por tanto, proporcionar a sus clientes (centros educativos) laboratorios remotos propios, encargándose de todos los procesos anteriormente descritos,
excepto del de administración.
El centro educativo que decida contratar los servicios de la Empresa especificará qué tipo
de experimentos requiere en su laboratorio (WebLab-Deusto soporta ya de por sí muy
distintos tipos de experimentos, incluyendo diversos tipos de experimentos electrónicos,
físicos, biológicos, etc).
Para crear el laboratorio se necesitará adquirir equipo, dependiendo del tipo de experimento que el cliente requiera, así como de su número, y del número de usuarios que
necesite soportar. En general, el cliente deberá correr con ese gasto, aunque la Empresa
gestionará la compra. En ocasiones, si el equipamiento es genérico y el cliente acepta
que pertenezca a la Empresa (como servidores, etc) la empresa correrá con una parte
del gasto, ya que en caso de que las relaciones con dicho cliente terminen, podrá ser
reutilizado para otros propósitos.
Los servidores y todo el equipamiento será instalado en dependencias de la Empresa,
que garantizará una gestión y mantenimiento correctos, y que liberará con ello al cliente
de responsabilidades que no tiene la capacidad o el deseo de asumir.
El cliente deberá abonar una determinada cantidad mensual (que variará en cada caso)
por los servicios prestados por la empresa. En esta cantidad irán incluidos conceptos
tales como la provisión del espacio necesario para el equipo, la energía consumida, el
mantenimiento, la gestión técnica, las actualizaciones, etc.
136
9.5 PLAN DE MARKETING
9.5.1 Mercado
El mercado de la experimentación remota es muy nuevo. Si bien los laboratorios remotos existen desde hace tiempo, su ámbito ha sido en general muy reducido, limitándose
a dar soporte a un sólo tipo de experimento y estando sólo al alcance de unas pocas
instituciones (generalmente, las que han desarrollado el laboratorio específico).
Hoy en día, sin embargo, cohexisten varios factores que sugieren que la Experimentación
Remota va a crecer de manera muy significativa en los próximos años.
Los factores más notables se describen a continuación.
9.5.1.1 Avances tecnológicos
Actualmente, se han producido importantes avances tecnológicos que permiten y favorecen el desarrollo de la Experimentación Remota.
Por un lado, el acceso a Internet puede considerarse hoy en día como prácticamente
universal en los países desarrollados. Esto permite a prácticamente cualquier persona
acceder a un Laboratorio Remoto. Los posibles usuarios o clientes de tales laboratorios
serían, por tanto, extremadamente numerosos.
Por otro lado, los avances tecnológicos específicos en Laboratorios Remotos son también
muy significativos. Hoy en día existen laboratorios remotos genéricos, como WebLabDeusto, con diversas características clave que garantizan su potencial:
Genéricos:
Diseñados para soportar cualquier clase de experimento [32]. Desde experimentos
electrónicos, a experimentos físicos o biológicos. La flexibilidad que esto aporta
hace que puedan ser útiles en prácticamente cualquier campo del conocimiento
que implique experimentación.
Escalables y multiplataforma:
Un framework genérico de Laboratorios Remotos como WebLab-Deusto puede hoy
en día soportar un gran número de usuarios, y permite el desarrollo de experimentos
en múltiples tecnologías y plataformas [33].
Interoperables:
Existen varios frameworks de laboratorios remotos distintos. Este hecho tradicionalmente ha obstaculizado el compartir experimentos entre instituciones distintas,
limitando seriamente el potencial de la experimentación remota, ya que dichas instituciones tienden a tener recursos limitados a la hora de implementar experimentos. El no poder compartirlos, además, implica en general que estarán en mayor
o menor medida infrautilizados. Sin embargo, en la actualidad se están realizando
esfuerzos para la interoperabilidad [49][28]. WebLab-Deusto, en concreto, soporta interoperabilidad con otro de los principales laboratorios remotos: iLabs, de MIT
[34].
137
9.5.1.2 Nuevas tendencias
Se han identificado dos nuevas tendencias muy relacionadas con el campo de la Experimentación Remota, que auguran un rápido crecimiento para ésta.
∎
cia
Auge de los MOOCs y la formación a distan-
Los denominados MOOC, Cursos Online Masivos
y Abiertos, son cursos gratuitos impartidos a través de una plataforma educativa en Internet. En
la actualidad, están experimentando un enorme
desarrollo. El más conocido es quizás Coursera
[7].
Es de esperar que el desarrollo de la formación a
Figura 9.1.: Search volume for Courdistancia y de la MOOCs en concreto promueva a
sera (red) and MOOC
su vez la popularidad de los laboratorios remotos,
(blue), as reported by
Google
ya que ésta es una manera adecuada (y de hecho,
en general, la única) de añadir experimentación real
a un curso MOOC.
9.5.2 Producto
En secciones posteriores se describió el servicio principal de la empresa desde su propia
perspectiva. En esta sección, se describirá desde la perspectiva de los clientes.
El producto principal de la empresa es el servicio integrado de Laboratorios Remotos.
Tiene las siguientes características:
La Empresa realizará la compra de todo el equipo software necesario para el Laboratorio Remoto, siguiendo las especificaciones del cliente en cuanto a tipos y
número de experimentos, capacidad, etc.
La Empresa realizará el montaje, instalación y despliegue del laboratorio.
Se soportan numerosos tipos de experimentos, y es posible añadir soporte a experimentos nuevos.
Todo el equipamiento se ubica en dependencias de la Empresa.
La Empresa gestiona técnicamente el Laboratorio y asegura su correcto funcionamiento.
El cliente mantiene control sobre su laboratorio a través de un panel de administración.
138
El servicio supone numerosos beneficios para el cliente. Algunos se derivan del hecho
de usar un laboratorio remoto. Otros son específicos del servicio ofrecido.
Los derivados de usar un laboratorio remoto son los siguientes:
Pueden mejorar la oferta educativa, permitiendo experimentación que de otro modo
estaría fuera del alcance por motivos prácticos o económicos.
Puede ser usado desde cualquier lugar.
Puede ser usado a cualquier hora.
Disminuyen los requisitos temporales (puede ser usado más tiempo).
Eficiencia de recursos: Se necesitan menos recursos para cubrir las necesidades
de más usuarios, ya que su uso se distribuye en el tiempo.
Eficaz y realista: Es equipamiento real, controlado remotamente, de forma que puede ser tan eficaz como un laboratorio presencial.
No supervisado: No es necesario tener personal supervisando constantemente el
uso del laboratorio.
Los derivados del servicio concreto son los siguientes:
No es necesario personal con conocimientos técnicos para desplegar el laboratorio.
No es necesario personal con conocimientos técnicos para crear nuevos experimentos o modificar experimentos existentes.
No es necesario personal con conocimientos técnicos para el mantenimiento de los
servidores y del laboratorio en general.
No se necesita mantener servidores y equipamiento, con los gastos de espacio,
energía, seguridad, gestión y mantenimiento que implica.
Los problemas técnicos pueden ser fácilmente resueltos, eliminando o limitando la
necesidad de desplazamientos.
El coste de mantener localmente, sin ayuda, un Laboratorio Remoto, sería prohibitivo para la mayor parte de instituciones (que no cuentan con recursos técnicos ni
humanos apropiados).
9.5.3 Clientes
Podemos identificar varios segmentos de clientes:
Colegios
Centros de Formación Profesional
Universidades
Industria
139
Cada segmento se discutirá en más detalle a continuación.
9.5.3.1 Colegios
El sector conformado por los colegios de educación primaria y secundaria es el más
numeroso. Se calcula que existen unos 26.000 colegios en el estado [22].
Un inconveniente del sector es que la formación que imparten es bastante generalista.
Por este motivo, la utilidad de la experimentación en general, y de la experimentación
remota en concreto, está limitada a un conjunto pequeño de las asignaturas que imparten.
Además, el área concreta en la que WebLab-Deusto (y la mayor parte de Laboratorios
Remotos actuales) sobresalen es la electrónica y campos relacionados con ésta. En la
actualidad los colegios imparten pocas asignaturas de estas características.
No obstante, es un sector numeroso y sigue existiendo un potencial notable, de modo se
orientarán esfuerzos significativos a este sector, y se promoverá el desarrollo de nuevos
experimentos que sean de interés para él.
9.5.3.2 Centros de Formación Profesional
El número de centros de formación profesional en España es mucho menor que el de
colegios. Se calcula que existen unos mil.
Estos centros están orientados a proporcionar una formación especializada y práctica,
de modo que por su naturaleza, las prácticas y la experimentación son claves en su
proceso formativo. Esto hace que el potencial de los laboratorios remotos en su ámbito
sea especialmente significativo.
Además, los centros suelen ser de tamaño pequeño, de modo que en general no tienen
demasiados recursos o personal técnico disponible, necesario para comprar y mantener equipamiento en general, y una infraestructura de laboratorios remotos en concreto.
El empleo de laboratorios remotos les permitiría ahorrar costes compartiendo hardware
y equipos entre diferentes centros.
Recurriendo a los servicios de la Empresa, un centro de formación profesional puede
acceder a las ventajas de un laboratorio remoto de forma económica, sin necesidad de
preocuparse de mantener infraestructuras y sin prácticamente dificultades.
Por estos motivos, este segmento resulta particularmente atractivo para la Empresa.
9.5.3.3 Universidades
Las universidades son relativamente pocas, pero en general mucho más grandes que
los colegios o que los centros de formación profesional. Por este motivo, tendrían, en
140
principio, una mayor capacidad para mantener una infraestructura propia de Laboratorios
Remotos.
Sin embargo, sin el conocimiento especializado y experiencia en el campo de la experimentación remota de los que sólo un pequeño número de universidades dispone, resulta
muy improbable lograr con un esfuerzo razonable un despliegue exitoso de un laboratorio
remoto.
Para tales universidades, resulta mucho más práctico, económico y viable llegar a acuerdos con otras universidades que dispongan de experiencia en el ámbito, o, en su caso,
de recurrir a los servicios de la Empresa.
Por estos motivos, este segmento resulta también notablemente atractivo para la Empresa. Asimismo, es posible que dichas universidades estén dispuestas a dedicar ciertos
esfuerzos de investigación para el desarrollo de nuevos experimentos, lo que beneficiaría
tanto a dicha universidad, como a la Empresa, y como al campo de la experimentación
remota en general.
9.5.3.4 Industria
Existen diversas empresas que podrían beneficiarse de experimentación remota, ya sea
por motivos formativos o por necesidades industriales específicas. Sin embargo, el ámbito
de la experimentación remota industrial es distinto del académico.
Puesto que la experiencia con la que cuenta la Empresa en este ámbito es limitada, y
existen diferencias muy notables con respecto a los otros segmentos, de momento queda
fuera de los objetivos inmediatos de la empresa el ofrecer servicios orientados a este
segmento.
A largo plazo, sin embargo, se tratarán de analizar y comprender mejor las necesidades
de este segmento, y se evaluará en qué medida es posible a la Empresa satisfacerlas
con los recursos, experiencia y conocimiento de los que dispone.
9.5.4 Nicho
Tal y como se deduce de secciones anteriores, el nicho de la empresa será la provisión
de servicios de Experimentación Remota con fines educativos a tres segmentos similares
de clientes:
Colegios
Centros de Formación Profesional
Universidades
141
9.5.5 Estrategia
9.5.5.1 Promoción
Considerando la naturaleza business-to-business de la Empresa, y la naturaleza de los
servicios que presta, la mayor parte de la promoción será directa.
Se contactará con responsables de los centros educativos o con profesores de éstos
que impartan asignaturas que puedan beneficiarse de experimentación remota, según
se considere más adecuado dependiendo del caso.
Actualmente la tecnología de experimentación remota es novedosa, y sus capacidades
son en general poco conocidas. Por ésto, se incidirá particularmente en transmitir información sobre las características y ventajas de los laboratorios remotos.
Además, se seguirá promoviendo el conocimiento y la exposición del campo de la experimentación remota en eventos tales como ferias o conferencias relacionadas con la
educación, la innovación y las nuevas tecnologías.
Los objetivos principales serán por tanto:
Promover el conocimiento e interés en el área de la experimentación remota, para
que los potenciales clientes comprendan sus beneficios y puedan demandar los
servicios de la Empresa
Promover los servicios de la Empresa como adecuados a las necesidades formativas actuales, económicos, sencillos para el cliente y efectivos.
9.5.5.2 Precio
La Empresa ofrece principalmente un servicio. Las características exactas de dicho servicio dependerán en cada caso, de modo que los precios exactos serán también distintos.
Sin embargo, en un servicio intervendrán dos precios:
Importe inicial
Importe periódico
El importe inicial será el que se pague en un inicio, y su objetivo será cubrir la compra de
equipamiento, las gestiones iniciales, el montaje, la instalación, el despliegue del laboratorio y en su caso, modificaciones al código de experimentos pre-existentes o desarrollo
de experimentos nuevos.
El importe periódico será abonado por el cliente en principio con periodicidad mensual o
trimestral. Dicho importe cubre el espacio ocupado por los equipos, los gastos y esfuerzos
de mantenimiento, el gasto en electricidad, los gastos de gestión, etc.
Con respecto a la fijación de los precios, es importante notar que los Laboratorios Remotos son un sector emergente. La experiencia de los potenciales clientes (centros forma-
142
tivos) con ellos es limitada. Por éste motivo, en general no estarán dispuestos a realizar
grandes inversiones al respecto.
Se tratará de minimizar lo más posible el importe inicial, para que éste no disuada a los potenciales clientes. En su caso, la Empresa financiará parte de los equipos, especialmente
si dichos equipos pudieran ser reutilizados en otros proyectos. En ocasiones, además,
laboratorios pertenecientes a distintos clientes podrán compartir parte del equipo, como
ciertos servidores. Si esto es posible, se sugerirá tal opción, de forma que se reduzca el
importe inicial.
En el importe periódico no existirán tales restricciones. Por lo novedoso del sector, si el
laboratorio remoto cumple con las expectativas, el cliente estará dispuesto a pagar un
precio razonablemente alto por los servicios prestados. Esto será especialmente cierto
en aquellos casos en los que el cliente haya conseguido un ahorro de costes significativo
gracias al empleo de laboratorios remotos.
9.6 PLAN OPERATIVO
9.6.1 Producción
La empresa dividirá sus actividades en tres grandes áreas:
Relación con clientes y captación de nuevos clientes
Desarrollo
Creación, mantenimiento y gestión de laboratorios
El primer área se encargará de la captación, contactando con potenciales nuevos clientes
en los tipos de centros que se han descrito anteriormente. Se encargará también de
gestionar la relación con los clientes existentes, atendiendo sus posibles peticiones y
sugerencias y solucionando sus posibles problemas.
El área de desarrollo se encargará de continuar mejorando la tecnología de laboratorios
remotos, creando características nuevas para la infraestructura WebLab-Deusto, desarrollando nuevas tecnologías relacionadas, creando nuevos experimentos, o mejorando
los actuales.
El tercer área se encargará de proporcionar a los clientes el servicio principal, que es
la creación, mantenimiento y gestión de los laboratorios. En éste área se encuentran
las actividades encaminadas a asegurar el buen funcionamiento de los laboratorios, así
como aplicar posibles actualizaciones o cambios pedidos por los clientes.
9.6.2 Ubicación
Los laboratorios se ubicarán físicamente en instalaciones de la empresa, de modo que
se necesitará un espacio adecuado para ello.
143
Los equipos serán principalmente servidores, equipos de red, dispositivos específicos y
equipos específicos para cada experimento.
Se necesitará, por tanto:
Entorno a temperatura adecuada. Particularmente, debería existir refrigeración, para contrarrestar el calor producido por los equipos.
Suministro eléctrico de suficiente potencia, estable, y con dispositivos para la prevención de picos de voltaje. Idealmente, con un SAI (Sistema de Alimentación Ininterrumpida), que prevenga que posibles fallos en el suministro afecten al servicio
de los laboratorios.
Acceso a Internet de grado servidor, capaz de dar servicio a un gran número de
laboratorios remotos, con necesidades altas de ancho de banda.
El espacio que se reservará será bastante amplio, ya que ciertos experimentos tienen
requisitos significativos de espacio.
Las necesidades para el resto de áreas de la empresa serán las usuales, necesitando un
espacio de oficina estándar bien equipado para las actividades de gestión, desarrollo y
relación con clientes.
9.6.3 Personal
Prácticamente todo el personal de la empresa deberá ser altamente cualificado.
En su mayor parte estará formado por ingenieros, que llevarán acabo:
Tareas de compra, montaje, despliegue, prueba y gestión de los laboratorios remotos.
Desarrollo de WebLab-Deusto y las tecnologías base de experimentación remota.
Desarrollo de nuevos experimentos y mejora de los actuales.
9.6.4 Inventario
El inventario de la empresa estará formado en su mayor parte por el equipamiento requerido por los laboratorios remotos.
A no ser que se trate de equipamiento específico, se tratará en general de que el equipamiento pertenezca a la Empresa, y simplemente se ceda su uso a los clientes.
9.6.5 Proveedores
El proveedor de software para la infraestructura de laboratorios remotos puede ser considerado WebLab-Deusto. Es un proyecto de código abierto, relacionado de forma directa
con la Empresa, y por tanto no tiene un coste.
144
Con respecto a los equipamientos, tales como servidores y otro tipo de software, se recurrirá en general a proveedores generalistas, y por tanto el más adecuado dependerá
de cada caso.
Algunos experimentos actualmente requieren productos de fabricantes específicos. En
este momento, por ejemplo, muchos de los experimentos electrónicos están basados
en tecnologías de Xilinx Inc., tales como los experimentos FPGA o los experimentos
CPLD.
Considerando estas características, no se espera que surjan particulares problemas con
respecto a los proveedores.
9.6.6 Política de créditos
Por regla general, no se permitirá a los clientes la contratación a crédito de servicios.
Sin embargo, sí que se tratará de reducir al máximo la inversión inicial que dichos clientes
tengan que realizar, con el objetivo de que una inversión inicial significativa no actúe para
ellos como elemento disuasorio.
Por eso, en vez de créditos, la Empresa correrá con los gastos iniciales de equipamiento
de un cliente, o con una parte de éstos. En tales casos, la propiedad de tales equipamientos se mantendrá en la empresa. Si el cliente se mantiene en el tiempo, con los pagos
periódicos se terminará recuperando la inversión. Si no se mantiene, el equipamiento
podrá ser utilizado para otros propósitos o para otros clientes.
El pago periódico por los servicios será mensual o trimestral.
145
BIBLIOGRAFÍA
[1] Ronald T Azuma et al. A survey of augmented reality. Presence-Teleoperators and
Virtual Environments, 6(4):355–385, 1997.
[2] A Baccigalupi, C De Capua, and A Liccardo. Overview on development of remote
teaching laboratories: from labview to web services. In Instrumentation and Measurement Technology Conference, 2006. IMTC 2006. Proceedings of the IEEE, pages
992–997. IEEE, 2006.
[3] Boole-Deusto GitHub Repository [online].
booledeusto/.
URL: https://github.com/zstars/
[4] Chrome Experiments [online]. URL: http://www.chromeexperiments.com/.
[5] Benjamin Coifman, David Beymer, Philip McLauchlan, and Jitendra Malik. A real-time
computer vision system for vehicle tracking and traffic surveillance. Transportation
Research Part C: Emerging Technologies, 6(4):271–288, 1998.
[6] Martyn Cooper. Remote controlled teaching experiments, in science and engineering
subjects, accessible over the world-wide-web: the pearl project. In World Conference on Educational Multimedia, Hypermedia and Telecommunications, volume 2000,
pages 1296–1297, 2000.
[7] Coursera [online]. URL: http://www.coursera.org.
[8] Guilherme N. DeSouza and Avinash C. Kak. Vision for mobile robot navigation: A survey. Pattern Analysis and Machine Intelligence, IEEE Transactions on,
24(2):237–267, 2002.
[9] Weblab JS documentation [online]. URL: https://weblabdeusto.readthedocs.
org/en/latest/remote_lab_development.html.
[10] Electronics Workbench [online]. URL: http://www.interactiv.com/.
[11] WebLab-Deusto: Federación [online]. URL: https://weblabdeusto.readthedocs.
org/en/latest/federation_for_external_tools.html.
[12] Russell Freeman, Anthony Steed, and Bin Zhou. Rapid scene modelling, registration
and specification for mixed reality systems. In Proceedings of the ACM symposium
on Virtual reality software and technology, pages 147–150. ACM, 2005.
[13] M Golparvar-Fard, F Peña-Mora, and S Savarese. Application of d4ar–a 4dimensional augmented reality model for automating construction progress monitoring data collection, processing and communication, 2009.
147
BIBLIOGRAFÍA
[14] Luís Gomes and Javier Garcia Zubía. Advances on remote laboratories and elearning experiences. Universidad de Deusto, 2008.
[15] Google Driverless Car [online].
driverless_car/.
URL: http://en.wikipedia.org/wiki/Google_
[16] C. Gravier, J. Fayolle, B. Bayard, M. Ates, and J. Lardon. State of the art about
remote laboratories paradigms-foundations of ongoing mutations. iJOE, 4(1), 2008.
[17] I. Gustavsson, J. Zackrisson, L. Håkansson, I. Claesson, and T. Lagö. The visir
project–an open source software initiative for distributed online laboratories. In Proceedings of the REV 2007 Conference, Porto, Portugal, 2007.
[18] GWT [online]. URL: https://developers.google.com/web-toolkit/.
[19] Ben Harder. Are moocs the future of medical education? BMJ: British Medical Journal, 346, 2013.
[20] V.J. Harward, J.A. del Alamo, S.R. Lerman, P.H. Bailey, J. Carpenter, K. DeLong,
C. Felknor, J. Hardison, B. Harrison, I. Jabbour, P.D. Long, Tingting Mao, L. Naamani,
J. Northridge, M. Schulz, D. Talavera, C. Varadharajan, Shaomin Wang, K. Yehia,
R. Zbib, and D Zych. The ilab shared architecture: A web services infrastructure
to build communities of internet accessible laboratories. Proceedings of the IEEE,
96(6):931–950, 2008.
[21] Jeffrey R Hogue, R Wade Allen, Jerry MacDonald, Cliff Schmucker, Steve Markham,
and Arvid Harmsen. Virtual reality parachute simulation for training and mission
rehearsal. AIAA-2001-2061, pages 381–388, 2001.
[22] Instituto Nacional de Estadística [online]. URL: http://www.ine.es.
[23] Xilinx ISE [online].
URL: http://www.xilinx.com/products/design-tools/
ise-design-suite/ise-webpack.htm.
[24] jQuery [online]. URL: http://www.jquery.com/.
[25] KS Kumaran and VM Nair. Future trends in e-learning. In Distance Learning and
Education (ICDLE), 2010 4th International Conference on, pages 170–173. IEEE,
2010.
[26] Claude Laurgeau. Present and future of intelligent transportation systems. In Proceedings of ICAT 2008, international conference on automotive technologies, 2008.
[27] D. Lowe, T. Machet, and T. Kostulski. Uts remote labs, labshare, and the sahara
architecture. Using Remote Labs in Education: Two Little Ducks in Remote Experimentation, page 403, 2012.
[28] D. Lowe and H. Yeung. Remote laboratory systems interoperability standard: Interface definitions. RFC of the Technical Committee of the Global Online Laboratory
Consortium, 2011.
[29] P Murray. Will ‘free’and ‘open’rule the day as the future of online education. Online
Journal of Nursing Informatics (OJNI), 16(3), 2012.
148
[30] NodeJS webpage [online]. URL: http://nodejs.org/.
[31] Pablo Orduña. Transitive and Scalable Federation Model for Remote Laboratories.
PhD thesis, University of Deusto, 2013.
[32] P. Orduña, J. Garcia-Zubia, J. Irurzun, E. Sancristobal, S. Martín, M. Castro,
D. López-de Ipiña, U. Hernández, I. Angulo, and JM González. Designing experiment agnostic remote laboratories. Remote Engineering and Virtual Instrumentation.
Bridgeport, CT, USA, 2009.
[33] P. Orduña, J. Irurzun, L. Rodriguez-Gil, J. Garcia-Zubia, F. Gazzola, and D. Lópezde Ipiña. Adding new features to new and existing remote experiments through their
integration in weblab-deusto. International Journal of Online Engineering (iJOE),
7(S2):pp–33, 2011.
[34] Pablo Orduna, Javier Garcıa-Zubia, Diego López-de Ipina, Philip H Bailey, James L
Hardison, Kimberly DeLong, and V Judson Harward. Achieving interoperability
among educational remote laboratories. In 5th World Summit on the Knowledge
Society, 2012.
[35] Laura Pappano. The year of the mooc. The New York Times, 4, 2012.
[36] Proteus Design Suite [online]. URL: http://www.labcenter.com/.
[37] PyDev IDE [online]. URL: http://pydev.org/.
[38] Python [online]. URL: http://www.python.org/.
[39] Raghu Raman, Prema Nedungadi, Krishnashree Achuthan, and Shyam Diwakar.
Integrating collaboration and accessibility for deploying virtual labs using vlcap. International Transaction Journal of Engineering, Management, & Applied Sciences &
Technologies, 2(5), 2011.
[40] H Saliah, M Saad, and C De La Teja. Virtually and remotely accessing and controlling laboratory real devices: A new trend in teaching and learning in engineering.
ITHET2000, Istanbul, July3-5, 2000.
[41] SCORE Business Plan Template [online].
resources/business-plan-startup-pdf.
URL: http://www.score.org/
[42] Neal E Seymour, Anthony G Gallagher, Sanziana A Roman, Michael K O’Brien, Vipin K Bansal, Dana K Andersen, and Richard M Satava. Virtual reality training improves operating room performance: results of a randomized, double-blinded study.
Annals of surgery, 236(4):458, 2002.
[43] Y Shen, SK Ong, and AYC Nee. Augmented reality for collaborative product design
and development. Design Studies, 31(2):118–145, 2010.
[44] WebLab-Deusto: Descripción Técnica [online].
readthedocs.org/en/latest/technical.html.
URL: https://weblabdeusto.
[45] W3 [online]. URL: http://www.w3.org.
149
BIBLIOGRAFÍA
[46] WebLab-Deusto webpage [online]. URL: https://www.weblab.deusto.es/web/.
[47] WebLab GitHub Repository [online]. URL: https://github.com/weblabdeusto/
weblabdeusto/.
[48] Chen Xin. E-learning applications and challenges. In Future Information Technology
and Management Engineering, 2009. FITME’09. Second International Conference
on, pages 580–583. IEEE, 2009.
[49] H. Yeung, D. Lowe, and S. Murray. Interoperability of remote laboratories systems.
International Journal of Online Engineering (iJOE), 6(5):pp–71, 2010.
[50] Feng Zhou, Henry Been-Lirn Duh, and Mark Billinghurst. Trends in augmented reality
tracking, interaction and display: A review of ten years of ismar. In Proceedings of
the 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, pages
193–202. IEEE Computer Society, 2008.
[51] J García Zubia, J Sanz Martínez, and Borja Sotomayor. Boole-deusto, la aplicación
para sistemas digitales, 2001.
[52] Javier García Zubía. Educational software for digital electronics: Boole-deusto. In Microelectronic Systems Education, 2003. Proceedings. 2003 IEEE International Conference on, pages 20–22. IEEE, 2003.
150
A. ACRÓNIMOS
AJAX: Asynchronous Javascript And Xml.
API: Application Programming Interface.
CPLD: Complex Programmable Logic Device.
CSS: Cascading Style Sheets.
DOM: Domain Object Model.
E/S: Entrada/Salida.
FPGA: Field-programmable Gate Array.
GWT: Google Web Toolkit.
HTML: HyperText Mark-up Language.
HTTP: HyperText Transfer Protocol.
HTTPS: Secure HyperText Transfer Protocol.
JRE: Java Runtime Environment.
LDAP: Lightweight Directory Access Protocol.
LED: Light-emitting Diode.
LMS: Learning Management System.
MOOC: Massive Open Online Course (Curso Online Masivo y Abierto).
OpenGL: Open Graphics Library.
PLD: Programmable Logic Device.
RLMS: Remote Laboratory Management System
RPC: Remote Procedure Call.
SPRL: Specific Purpose Remote Laboratory
TCP/IP: Transmission Control Protocol / Internet Protocol.
TEL: Technology Enhanced Learning
UML: Unified Modeling Language.
VCL: Visual Components Library.
VHDL: VHSIC Hardware Description Language.
151
A. ACRÓNIMOS
WebGL: Web Graphics Library.
XHTML: Extensible HyperText Mark-up Language.
XML: Extensible Mark-up Language.
XML-RPC: Extensible Mark-up Language - Remote Procedure Call.
152
B. GLOSARIO
AJAX (Asynchronous JavaScript and XML):
Grupo de técnicas de desarrollo web utilizadas para la creación de aplicaciones web
asíncronas.
Bitstream:
Tipo de archivo utilizado para describir la información de configuración de un dispositivo
FPGA o similar. La información de configuración es, en esencia, la lógica que dicho
dispositivo implementará. Los archivos Bitstream suelen utilizar la extensión bit.
Boole-Deusto:
Software principalmente educativo para análisis y diseño lógico (electrónico). Desarrollado en la Universidad de Deusto. Se describe en más detalle en la sección de
Antecedentes del presente documento.
Borland C++ Builder:
Entorno de desarrollo en C++ creado por Borland, empresa que en el momento de
escribir esto ya no existe como tal. Es un RAD (entorno de desarrollo rápido), e incluye
librerías de componentes específicas (ver VCL). Boole-Deusto se ha creado utilizando
éste entorno. Existen versiones similares derivadas modernas (ver Embarcadero C++
Builder).
C++:
Lenguaje de programación multiparadigma. Si bien existe como estándar, no todas las
implementaciones son compatibles entre sí y algunas añaden funcionalidades y librerías
que dificultan más dicha compatibilidad.
Embarcadero C++ Builder:
Entorno de desarrollo en C++ perteneciente a Embarcadero. Es una versión moderna,
muy modificada, del que fuera Borland C++ Builder.
Experimento:
Un experimento de WebLab-Deusto es un conjunto de lógica (software) y hardware,
identificado con un nombre, que los usuarios con los privilegios apropiados pueden
acceder, observar e interactuar. Los experimentos más comunes en la actualidad son
electrónicos. Un experimento puede ser, por ejemplo, una placa con un dispositivo
FPGA, que el usuario puede programar, y con la que puede después interactuar.
153
B. GLOSARIO
Federación:
Con respecto a WebLab-Deusto, federación es la capacidad de compartir experimentos
entre diferentes “instancias” de WebLab-Deusto, o incluso con otros laboratorios remotos
diferentes.
FitPC:
Modelos de ordenadores personales fabricados por la empresa CompuLab caracterízados por tener las características básicas de un portátil o equipo de sobremesa estándar
pero colocado dentro de una caja de muy reducido tamaño, que generalmente poseé
refrigeración sin ventilador y muy alta eficiencia energética.
FPGA (Field Programmable Gate Array):
Circuito integrado diseñado para ser configurado por un cliente o diseñador después de
terminado el proceso de manufactura. Su configuración suele especificarse mediante
un lenguaje de descripción de hardware. Frecuentemente son reconfigurables (pueden
ser configurados más de una vez), como es el caso de los FPGA utilizados como
experimento en WebLab-Deusto.
GWT (Google Web Toolkit):
Tecnología de Google que permite describir un cliente Web en Java y compilarlo a
JavaScript para que sea verdaderamente utilizable en un navegador. WebLab-Deusto
utiliza esta tecnología para su cliente Web.
Instancia de WebLab-Deusto:
Instancia es el nombre que recibe una implantación específica de WebLab-Deusto.
Puesto que es código abierto, pueden existir numerosas instancias, aparte de la de
producción de Deusto. También pueden considerarse instancias las implantaciones
locales para desarrollo.
LED (Light Emitting Diode):
Componente electrónico capaz de emitir luz. Utilizados en varios experimentos electrónicos de WebLab-Deusto como salida visible mediante Webcam.
MOOC (Massive Online Open Course - Curso Online Masivo y Abierto:
Cursos no presenciales gratuitos y abiertos a todo el mundo, que utilizan las tecnologías
Web para hacer accesible el conocimiento a un alto número de estudiantes.
Realidad aumentada:
Vista de un entorno físico real que se combina con imágenes, gráficos o vídeo generados
por ordenador. De este modo, la tecnología de realidad aumentada complementa la
realidad.
154
Modelo virtual:
Simulación por software de algún sistema real, tal como un depósito de agua, o una
línea de montaje. En este trabajo, las simulaciones hacen referencia a sistemas que no
existen físicamente en la realidad (son creaciones gráficas tridimensionales), pero cuyo
estado lo determina un controlador real, y cuyas salidas tienen efecto en ese mismo
controlador real.
PIC:
Familia de microcontroladores construidos por Microchip Technology.
PLD (Programmable logic device):
Componente electrónico utilizado para construir circuitos digitales reconfigurables.
Realidad mixta: Partiendo de una vista de un entorno físico real, la realidad mixta añade
características totalmente virtuales, con las que el usuario puede también interactuar.
Sistema digital:
Conjunto de dispositivos orientados al procesamiento de señales digitales. En este
trabajo, se tratará principalmente sobre sistemas digitales binarios. Se dividen en dos
grupos: sistemas digitales combinacionales (las salidas dependen sólo de las entradas)
y sistemas secuenciales (autómatas).
VCL (Visual Components Library):
Librería de componentes vinculada al entorno de desarrollo Borland C++ Builder. Facilita
la creación de interfaces gráficas de usuario. Utilizada por Boole-Deusto.
VHDL (VHSIC Hardware Description Language):
Lenguaje de descripción de hardware utilizado en diseño electrónico para describir
sistemas digitales y de señal mixta, como circuitos integrados o FPGAs (ver FPGA). Los
archivos VHDL suelen utilizar la extensión vhd.
WebLab-Deusto:
Framework genérico de laboratorios remotos desarrollado en la Universidad de Deusto.
Ofrece diversos tipos de experimentos utilizables remotamente. Se describe en más
detalle en la sección de Antecedentes del presente documento.
Xilinx:
Compañía tecnológica americana. Es uno de los principales fabricantes de dispositivos
lógicos programables como FPGAs.
Xilinx ISE:
Conjunto de herramientas de software producidas por Xilinx, para la síntesis, análisis,
simulación y grabación de diseños lógicos a aplicar a dispositivos lógicos programables.
155
C. AGRADECIMIENTOS
Para concluir este proyecto, me gustaría agradecer brevemente a todas las personas que
de una forma u otra han contribuido al desarrollo de este trabajo.
Me gustaría, primero, dar las gracias a Javier García Zubia, por introducirme en WebLabDeusto, por la tutela, apoyo y confianza que me ha proporcionado durante los cuatro años
que he colaborado con el equipo, y por supuesto, por haber dirigido con entusiasmo este
proyecto.
Se merece también mi más sincero agradecimiento Pablo Orduña. Durante estos cuatro años, siempre ha encontrado tiempo para ayudarme, aconsejarme y para compartir
conmigo su -muy amplio- conocimiento y experiencia. Una de las personas más capaces
que conozco, sin su trabajo WebLab-Deusto -y este proyecto- no existirían.
También querría dar las gracias a Ignacio Angulo y al resto del equipo de WebLab, por
el apoyo y el gran trabajo que han hecho.
Por último -pero no menos importante- me gustaría agradecer especialmente a mi familia
y a mis amigos la confianza, compañía y apoyo que me han prestado.
157
D. PUBLICACIONES
Tal y como se ha mencionado en el capítulo de Contexto, el autor de éste documento, a
lo largo de sus cuatro años de colaboración con el equipo de investigación de WebLabDeusto, ha participado en diversas publicaciones. Algunas de éstas tratan directamente
sobre Boole-WebLab-Deusto, mientras que otras se centran en diferentes aspectos del
laboratorio remoto WebLab-Deusto, y de forma más indirecta han llevado a la consecución de este proyecto.
D.1 PUBLICACIONES INCLUIDAS EN LOS ANEXOS
Las publicaciones que se listan a continuación han sido incluidas como anexo al final del
documento:
1. Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Pablo Orduña, Olga Dzbiabenko. Integration of a Remote Lab in a Software Tool for Digital Electronics.
(2013). Submitted for publication.
2. Javier Garcia-Zubia, Luis Rodriguez-Gil, Pablo Orduña, Ignacio Angulo, Olga Dzbiabenko. Boole-WebLab-Deusto: Integration of a remote lab in a tool for digital
circuits design. (2013). Submitted for publication.
3. Javier Garcia-Zubia, Luis Rodriguez-Gil, Pablo Orduña, Ignacio Angulo, Unai Hernandez, Olga Dziabenko, Mari Luz Guenaga. An Integrated Solution for Basics Digital Electronics: Boole-DEUSTO and WebLab-DEUSTO. REV2013: 10th International Conference on Remote Engineering and Virtual Instrumentation. Sydney,
Australia, 6 - 8 February 2013.
4. Luis Rodriguez-Gil, Pablo Orduña, Javier Garcia-Zubia, Diego López-de-Ipiña. Advanced integration of OpenLabs VISIR (Virtual Instrument Systems in Reality) with
Weblab-Deusto. Remote Engineering & Virtual Instrumentation. REV2012. Bilbao,
Spain. July 2012.
5. Pablo Orduña, Jaime Irurzun, Luis Rodriguez-Gil, Javier Garcia-Zubia, Diego Lopezde-Ipiña Reusing requirements among remote experiments for their development and
integration under WebLab-Deusto. REV 2011: 8th International Conference on Remote Engineering and Virtual Instrumentation. Brasov, Romania, July 2011.
6. Pablo Orduña, Jaime Irurzun, Luis Rodriguez-Gil, Javier Garcia-Zubia, Fabricio
Gazzola, Diego López-de-Ipiña. Adding New Features to New and Existing Remote
Experiments through their Integration in WebLab-Deusto. International Journal of
Online Engineering (iJOE) (ISSN: 1861-2121). 2011.
159
D. PUBLICACIONES
D.2 PUBLICACIONES NO INCLUIDAS EN LOS ANEXOS
Otras publicaciones en las que ha participado el autor del presente documento en el
contexto del equipo de investigación de WebLab-Deusto que no se han incluido como
anexos pero que resulta relevante listar son:
1. Pablo Orduña, Luis Rodriguez-Gil, Diego López-de-Ipiña, Javier Garcia-Zubia. Sharing Remote Labs: A Case Study. International Journal of Online Engineering - iJOE
9(Special Issue: REV2012 Exhibition). 26 – 27. 2013.
2. Pablo Orduña, Xabier Larrakoetxea, David Buján, Aitor Gómez-Goiri, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil, Diego López-de-Ipiña, Javier GarziaZubia. WebLab-Deployer: exporting remote laboratories as SaaS through federation
protocols. REV2013: 10th International Conference on Remote Engineering and Virtual Instrumentation. Sydney, Australia, 6 - 8 February 2013.
3. Javier García-Zubía, Pablo Orduña, Ignacio Angulo, Unai Hernández, Olga Dziabenko, Luis Rodríguez, María Luz Güenaga, Ingvar Gustavsson. Remote Laboratories:
Opportunities and Challenges. The World of Sustainable Laboratories, WOSLAB
2012. Book of Abstracts, The World of Sustainable Laboratories, WOSLAB 2012,
ISBN: 978-84-87543-22-7, pp:63-64. 2012.
4. Javier García Zubía, Ignacio Angulo, Pablo Orduña, Unai Hernández, Diego Lópezde-Ipiña, Luis Rodriguez, Olga Dziabenko, Veronica Canivell. WebLab-Deusto-CPLD:
A Practical Experience. International Journal of Online Engineering - iJOE 8(S1):
17-18 (2012).
5. Pablo Orduña, Javier Garcia-Zubia, Luis Rodriguez-Gil, Diego López-de-Ipiña. Sharing the remote laboratories among different institutions: a practical case. Remote
6. Pablo Orduña, Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Olga Dziabenko, Diego López-de-Ipiña. Exploring students collaboration in remote laboratory
infrastructures. Remote Engineering & Virtual Instrumentation. REV2012. Bilbao,
Spain. July 2012.
7. Javier Garcia-Zubia, Bruno Campos, Pablo Orduña, Luis Rodriguez, Ignacio Angulo, Olga Dziabenko. Easily Deployable Low-Cost Remote Lab Platform.. Remote
8. Pablo Orduña, Javier García-Zubia, Fabricio Gazzola, Luis Rodriguez-Gil, Jaime
Irurzun, Diego López-de-Ipiña. Using LabVIEW Remote Panel in Remote Laboratories: advantages and disadvantages. IEEE EDUCON 2012. Marrakesh, Morocco,
April 2012. Page(s): 1 - 7. DOI: 10.1109/EDUCON.2012.6201134. ISBN: 978-1-46731457-2.
9. Javier Garcia-Zubia, Ingvar Gustavsson, Unai Hernandez-Jayo, Pablo Orduña, Ignacio Angulo, Luis Rodriguez-Gil, Diego López-de-Ipiña. Using VISIR: Experiments,
Subjects and Students. International Journal of Online Engineering (iJOE) (ISSN:
1861-2121). 2011.
160
10. Javier García-Zubía, Pablo Orduña, Unai Hernández, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil and Diego López-De-Ipiña. WebLab-Deusto-CPLD: A
Practical Experience. 1st Experiment@ International Conference (expat2011). 2011.
11. Javier Garcia-Zubia, Pablo Orduña, Ignacio Angulo, Unai Hernandez, Olga Dziabenko, Diego Lopez-de-Ipiña, Luis Rodriguez-Gil. Application and User Perceptions of
Using the WebLab-Deusto-PLD in Technical Education. 41st ASEE/IEEE Frontiers
in Education Conference (FIE 2011) - GOLC Session. Rapid City, South Dakota,
United States, October 2011.
12. Javier Garcia-Zubia, Ingvar Gustavsson, Pablo Orduña, Diego Lopez-de-Ipina, Unai
Hernandez, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil Using VISIR at
the University of Deusto: experiments, subjects and students. REV 2011: 8th International Conference on Remote Engineering and Virtual Instrumentation. Brasov,
Romania, July 2011. ISBN: 978-3-8958-555-1, pp: 244-247.
13. J. García-Zubia, P. Orduña, I. Angulo, U. Hernández, O. Dziabenko, L. RodriguezGil. Justificación, propósito y ventajas de un laboratorio remoto. III Foro Internacional sobre Innovación Docente. Bilbao, Julio 2011.
14. Pablo Orduña, Javier García-Zubia, Jaime Irurzun, Diego López-de-Ipiña, Luis RodriguezGil. Enabling mobile access to Remote Laboratories IEEE EDUCON 2011 (ISBN:
978-1-61284-641-5). Amman, Jordan, April 2011. pp. 312 - 318. DOI: 10.1109/EDUCON.2011.5773154.
15. Javier García-Zubia, Andreas Pester, Pablo Orduña, Jaime Irurzun, J.M. González,
Ignacio Angulo, Unai Hernández, Luis Rodriguez. One Lesson from TARET: what
is expected from a remote lab? REV2010. Stockholm, Sweden. 2010. ISBN: 978-389958-540-7, 34-38 pp.
161
Boole-WebLab-Deusto: Integration of a Remote Lab
in a Tool for Digital Circuits Design
Javier García-Zubía (IEEE Senior Member), Ignacio
Angulo, Luis Rodríguez-Gil
Faculty of Engineering
University of Deusto, Avd. Universidades 24
48007 Bilbao, Spain
[email protected]
Abstract—This paper describes the integration of a remote
lab in a tool for educational digital circuits. Boole-Deusto is an
educational software tool featuring truth tables, Karnaugh maps,
Boolean expressions, finite-state machines and digital circuits.
After creating the design through Boole-Deusto, the user can
implement the circuit in a remote lab (WebLab-Deusto) with
only a few mouse clicks. The user does not need the technical
knowledge, time, hardware equipment and specialized software
that would normally be required. These conveniences benefit
teachers and students alike, especially those involved in basic
courses in digital electronics, both at the university and high
school levels.
Keywords—remote labs, digital electronics, software design
tools
I.
INTRODUCTION
Current lessons on digital electronics are usually based on
books, exercises, and lab practices. The learning process starts
with theory. Then students design some exercises and finally
some of these are implemented using different technologies
(74XX IC, VHDL/Verilog, CPLD, FPGA...). With this
approach, students learn how to design and implement different
digital circuits.
Simulators and other educational software tools help
teachers and students. However, professional tools like Proteus
[1], Pspice [2] or Electronics WorkBench, EWB [3] do not
always cover all the educational requirements. Some areas
(such as Karnaugh maps) are often neglected. On the other
hand, educational tools tend to cover those neglected areas, but
to have a very narrow scope. An example of such a tool is the
Karnaugh Map Minimizer [4]. Though Boole-Deusto is also an
educational software tool, it tries to cover a larger base of
educational requirements, including the full design of basic bitlevel digital circuits. Nonetheless, Boole-Deusto should not be
compared with professional tools, as their focus tends to be on
the circuits rather than the design process itself.
Whether they are using simulators or not, students should
eventually implement the digital circuit using 74XX IC,
VHDL/Verilog, etc. To do this this, students and teachers
Pablo Orduna (IEEE member), Olga Dziabenko
Deusto Institute of Technology
University of Deusto, Avd. Universidades 24
48007 Bilbao, Spain
[email protected]
would typically move to a purposely-equipped laboratory to
carry out this experience. However, for several years, there has
been another possibility: to use a remote laboratory. These labs
have been considered as part of the “Five Major Shifts in 100
Years of Engineering Education” [5].
There is a high amount of remote labs for digital electronics
[6 - 9], but most often they are intended for a single, particular
device such as a FPGA, CPLD or microcontroller, but without
a more general, educational approach.
The main objective of this work is to integrate BooleDeusto [10][11] with the WebLab-Deusto [12] remote lab, both
Open Source projects. Through this integration, teachers and
students can design a basic digital circuit under the educational
approach provided by Boole-Deusto (involving truth tables,
Karnaugh maps, Boolean expressions…), and after this they
can implement it in a remote lab with only a few mouse clicks,
and requiring only Boole-Deusto and an Internet connection.
The process is very straightforward, and no wiring, particular
technical knowledge or hardware such as board programmers
is needed, nor specialized software such as development
studios.
The paper describes in Section II the Boole-Deusto
software for combinational and sequential bit-level digital
systems. Section III is devoted to a general perspective on the
WebLab-Deusto remote laboratory. The integration of BooleDeusto and WebLab-Deusto is illustrated with examples in
Section IV. The paper finishes with the conclusions and future
work in Section V.
II.
BOOLE-DEUSTO SOFTWARE TOOL FOR DIGITAL
ELECTRONICS DESIGN
Digital electronics circuits can be classified in two groups:
combinational circuits and sequential circuits, depending on
whether they have memory (and are hence sequential) or not.
Depending on the complexity of the circuits, they can be
divided in bit-level and word-level circuits (see Fig. 1). In the
first case the circuit is described bit by bit using a truth table
(combinational circuits) or a Finite State Machine (sequential
circuits).
Since 2003, Boole-Deusto has been downloaded thousands
of times [14]. Fig. 3 shows the download statistics from the
official Boole-Deusto web page (since 2007 only – more
download sources exist, so the full download count would be
significantly higher).
Fig. 1. Digital circuits classification
The Boole-Deusto open-source tool was deployed for the
first time in 2000 [13] for designing bit-level digital circuits,
both of the combinational and sequential types. The design of
these circuits can be seen as a transformation along different
representations of the system. These representations can be of
textual, numerical, logical, graphical or mathematical nature.
In the design of a combinational circuit (see Fig. 2), the
student reads the statement and after understanding it, fills the
truth table. It is then converted to Karnaugh maps that are
solved to obtain minimized Boolean expressions. These
Boolean expressions are converted to digital circuits that can
be implemented using AND-OR (or NAND/NOR) logic gates
in 74xx IC or using a VHDL/Verilog approach.
Fig. 3. Statistics of the Boole-Deusto downloads.
A. Combinational circuit example with Boole-Deusto
Figs 4-7 describe the design of a combinational circuit
through its different representations. The description statement
is: “Design the circuit that switches on a led if the four bits of
the input are not a BCD combination”.
The combinational circuit has four inputs (BCD) and one
output (LED).
Fig. 4. Name, inputs and outputs of the example
Fig. 2. Design process of a bit-level combinational circuit.
The process with bit-level sequential circuits is similar.
Students will start by reading the problem statement and
obtaining a FSM. After using an algorithm they will minimize
that FSM. It will then be transformed into a truth table from
which the K maps will be obtained. Based in the K maps, the
minimized Boolean expressions will be obtained to be
implemented with logic gates or in VHDL/Verilog.
Boole-Deusto focuses only on the design process. A
student cannot use Boole-Deusto to see how a digital circuit
evolves through time. Simulation is already covered in depth
by tools such as Proteus, EWB, etc. Boole-Deusto helps
freshmen in digital electronics to design and implement real
and basic digital circuits. Boole-Deusto was developed as an
Open Source project [11] by the University of Deusto after
being unable to find an existing educational tool of this kind.
The truth table in Fig.5 shows that the led must be on when
the inputs are 1010 – 1111. 0000 – 1001 are proper BCD, so
the led will be off.
Fig. 5. Truth table of the system
When the student has filled the truth table, the Karnaugh
map and the solved Karnaugh map become available. This map
can be solved automatically by Boole-Deusto (Fig. 6), or the
student can instead try to solve it manually using the Learning
Mode.
Fig. 9. FSM truth tables
The next step is to obtain the digital circuit (Fig. 10).
Fig. 6. Solved Karnaugh map for the BCD-ERROR problem
Finally, the student can obtain the matching digital circuit
in both the AND-OR and the NAND/NOR versions.
Fig. 10. FSM digital circuit with JK flip-flops
Fig. 7. AND/OR and NAND digital circuits
B. Sequential circuit, Finite State Machine
In this case, the student can draw the Moore or Mealy FSM
using a graphical interface, displayed in Fig. 8.
The statement for this example is a sequence detector:
“Design the FSM that switches on the led in the output, if three
or more 1s are received in the input signal”
Finally, the student can obtain and download the VHDL
program of the FSM.
C. Boole-Deusto Characteristics
Boole-Deusto allows the student to control the step-by-step
design of bit-level digital circuits. The student will manage
FSM, truth tables, K maps, digital circuits, VHDL code, etc.
When comparing Boole-Deusto with other software tools,
the main difference is that Boole-Deusto takes the user through
each step in the design process. Other tools focus only on the
final result, neglecting aspects which are important from an
educational perspective but not so much from a practical one.
For instance, Proteus software, though certainly complete and
professional, does not give students the opportunity of solving
the Karnaugh maps themselves.
III.
Fig. 8. Moore Finite State Machine
After drawing the FSM, the student can minimize it or
obtain the truth tables (Fig. 9).
WEBLAB-DEUSTO REMOTE LAB
WebLab-Deusto is a remote lab created by the University
of Deusto and released and developed as an Open Source
project. A remote lab is a hardware & software platform that
allows students to experiment remotely through the Internet as
if they were in a classical lab.
WebLab-Deusto offers different remote experiments.
Though WebLab-Deusto is a generic framework, currently the
majority of them are related to electronics. There are also
several which are connected to physics and biology (See Fig.
11).
Fig. 11. WebLab-Deusto experiments
Fig. 12. WebLab-Deusto-Box for FPGA
It is noteworthy that WebLab-Deusto supports several
generic advanced capabilities [16], which are shared by all
experiments. These include but are not limited to federation
(experiments and hardware can be shared among different
WebLab-Deusto instances, in different institutions and
universities), escalation and load-balancing (the number of
servers can be increased very easily) and optional integration
with different technologies, such as Facebook or LMSs such as
Moodle.
From a technical point of view, WebLab-Deusto
experiments support any web browser (Chrome, Explorer,
Mozilla, Opera, Safari…) in any OS (Linux, Windows…) and
any device (tablet, laptop, smart phone…). Users do not need
to install anything on their devices, and thus there are no local
security issues. Some experiments are currently restricted and
the user will require a user/password combination. For others,
no registration is required.
IV.
BOOLE-WEBLAB-DEUSTO
The main objective of this paper is to show readers the
potential of the connection between Boole-Deusto and
WebLab-Deusto. Fig. 13 shows the checkbox to tick when
implementing in Boole-Deusto a system for WebLab-Deusto.
A. Bit-level combinational circuits
Fig. 13 shows the checkbox that should be checked by
users when they wish to create a WebLab-compatible system
easily.
A. WebLab-Deusto-FPGA hardware description
WebLab-Deusto offers different experiments. One of them
is a FPGA:
 The experiment is based in a FPGA Digilent Board.
Fig. 13. WebLab Mode for combinational systems
 The inputs (switches, buttons and clock) are controlled
with a PIC Microcontroller of Microchip.
When users are in WebLab Mode they may then assign, for
instance, switches as inputs and leds or seven_seg (sevensegment displays) as outputs. After this, users should:
 A webcam and a lighting system are included to
provide the user with a video stream of the behavior of
the digital circuit.
 A FIT PC (small computer) and a modem are also
included, on which the web service which interfaces
with the remote laboratory framework is deployed.
All these parts are integrated in a compact, purpose-built
professional box.
Fig. 12 shows the WebLab-Deusto-Box where the FPGA
experiment is deployed. The same type of box is used to
deploy other experiments, such as a CPLD. This WebLabDeusto-Box was awarded in ICELIE/IECON 2009 for Best
Educational Tool [15] has been deployed in different
universities, including the MIT (USA).
 Define the system: name, inputs and outputs (see Fig.
14).
 Describe the system using the truth table or the
Karnaugh maps (or other means).
 Save the system to VHDL code.
 Click in “Open WebLab-FPGA” (see Fig. 13).
After this, Boole-Deusto will reach WebLab-Deusto
through the Internet, directing your default web browser to the
right WebLab-Deusto page. A user/pass combination for
authentication is required, though it is only necessary to login
once per session.
with 0000 as input, the led output is off because 0000 is a BCD
combination.
Fig. 14. WebLab-Deusto access web page
Comment for the reviewer: please use fie2013/fie2013 as
the user/pass combination.
After accessing WebLab-Deusto by this means, users will
be prompted to upload a file. This file should be the .VHD file
they generated previously.
Fig. 17. BCD-ERROR system in the WebLab-Deusto
If the inputs are: 1010, then the led will be on because the
combination 1010 is not BCD, as shown in Fig. 18.
Fig. 15. Uploading the VHDL code to WebLab-Deusto
Then, WebLab-Deusto will synthesize the VHDL code
with an internally provided UCF (User Constraints File) to
obtain the BIT (BITSTREAM) file that will be loaded into the
FPGA (see Section III.A). It is noteworthy that it generally
does not matter for students if the designed system is
implemented in a FPGA, a CPLD or even a microcontroller.
What matters to students is to see the system running, with its
inputs (switches and buttons) and outputs (leds and sevensegment displays).
During the uploading process, users will see a process bar
as shown in Fig. 16.
Fig. 16. Synthesizing VHDL in WebLab-Deusto
When the process finishes, users will have full control of
the switches, buttons and clock. In Fig. 16 it can be seen that
Fig. 18. BCD-ERROR system in the WebLab-Deusto
The Figs. 19 and 20 show the truth table of a BCD-seven
segment decoder and the remote experience with it for the
input 0011.
Fig. 19. BCD to seven segment decoder truth table
Fig. 23 shows the lit led after introducing four 1s in through
the Switch 0.
Fig. 20. BCD to seven segment decoder remote experimentation
Using this approach any basic combinational circuit can be
designed and experimented with through a remote lab in just a
few minutes.
B. Bit-level sequential circuits: Finite State Machine
With a sequential circuit, users start the process with a FSM
(see Fig. 8). After this, they must save the FSM to VHDL code.
In this case users have four options depending on the clock
they selected (see Fig. 21):
Fig. 22. FPGA board through the experiment’s webcam
Other sequential systems can be designed and implemented
in few minutes following the same order: FSM design, VHDL
code generation, and WebLab-Deusto.
C. Boole-Deusto and WebLab-Deusto Integration
 Internal clock. The FPGA will be controlled by its
internal clock of 50 MHz.
 WebLab clock. The FPGA will be controlled by a clock
offered in the web page. Its frequency can be specified
within a range that goes from 100 Hz to 10 KHz.
 Switch and Button clock. The FPGA will be controlled
by a clock connected to a switch (switch 9) or to a
button (Button 3).
The first two options leave the system to run automatically,
and the other two let the user control the speed of the system to
witness its evolution in detail. The selection will depend on the
particular needs of the student or teacher.
Fig. 23. Boole-Deusto and Weblab-Deusto integration
Fig. 21. Clock options
After saving the VHDL code, the user will repeat the
process: Access to the WebLab-Deusto web page, upload the
VHDL code, synthesize the VHDL, and finally load the bit file
into the FPGA. After this, the user will interact with the system
using the provided switches and buttons.
As previously described, the aim has been to integrate
WebLab-Deusto and Boole-Deusto in a single, mostly
seamless workflow. To achieve this, certain challenges had to
be overcome. Fig. 23 shows how it has been implemented and
deployed. This section will explain the most significant
technical aspects in further detail.
Back when Boole-Deusto was created, remote
experimentation support was not an anticipated feature.
Throughout this project, several additions to Boole-Deusto
have been done. The most noteworthy is probably the
capability to generate specialized VHDL code compatible with
Weblab-Deusto, for both combinatorial and sequential circuits.
Weblab-compatible VHDL code has certain requirements.
Main one is a determined set of inputs and outputs which
matches the physical setup of Weblab-Deusto FPGA boards, as
described in UCF files (which, for security reasons, are fixed
and located on the Weblab server itself).
Also, in order to support different kinds of clocks, BooleDeusto includes specific keywords within the generated VHDL
code, which Weblab-Deusto can understand. According to
these keywords, Weblab-Deusto selects the appropriate clock
by synthesizing the provided code against a matching UCF file.
As fig. 23 shows, once the VHDL code for a certain design
has been generated, eventually the VHDL file reaches the
Xilinx Synthesizing Tools within the WebLab-Deusto servers.
Though WebLab-Deusto has long had the capability of
experimenting with FPGA or CPLD boards remotely by
providing a BITSTREAM (.BIT) file, this was not enough for
this use-case, due to several reasons. Firstly, obtaining a
BITSTREAM file from VHDL is not a trivial process,
especially for an inexperienced user. Specialized development
software is required, and it has to be set up appropriately for
the specific board that the remote experiment uses. And
secondly, in order to obtain a BITSTREAM a UCF file is also
required, linking the logical inputs and outputs to the physical
ones (which depend on the physical setup of the board).
Apart from an inconvenience, allowing users to provide
their own UCF files can be a security issue. Wrongly
specifying inputs and outputs can lead to physical damage to
the experiment’s hardware board.
To prevent these issues and to make the process less
cumbersome for the final users, the natural solution was for the
WebLab servers to be able to synthesize provided VHDL code
themselves. This code is automatically synthesized on the
servers themselves into a BIT file using the Xilinx
Synthesizing command-line Tools and automatically linking it
against the correct UCF file, which the server chooses after
finding (or not) certain specific preprocessor switches on the
VHDL. If the process succeeds, a BIT file is obtained and
programmed on the physical board. If it fails, the synthesize
errors are reported to the experiment user.
As depicted on fig. 23, once the physical board has been
programmed by the Xilinx board-programming tools, remote
experimentation may begin. The board, which will be running
the designed system, is now displayed and can be controlled.
V.
CONCLUSIONS AND FUTURE WORK
The combination of Boole-Deusto and WebLab-Deusto
allows the user to design a bit-level digital circuit following an
educational approach (provided by Boole-Deusto) and to
rapidly (only a few clicks required) implement it in a remote
lab (WebLab-Deusto) without requiring any particular
technical knowledge, hardware, or software (beyond BooleDeusto itself and a browser).
Boole-WebLab-Deusto can be used by teachers in a
classroom environment to present them with the whole
process: design, implementation and real-word testing (through
remote experimentation). Students can create their own designs
easily through understandable software, thus promoting
creativity and autonomous work.
We believe the use of Boole-WebLab-Deusto should not be
restricted to universities. From our point of view it should be
just as effective in secondary and high schools because it is not
only powerful, but can also be particularly easy to use.
In the future, our goal is to include augmented reality in
remote experiments, so as to improve the learning experience
of the student by improving the quality, interest, and variety of
experiments in a cost-effective way.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
http://www.labcenter.com/index.cfm
http://www.interactiv.com/
http://www.electronics-lab.com/
http://k-map.sourceforge.net/
Froyd, J.; Wankat, P.; Smith K.,“Five Major Shifts in 100 Years of
Engineering Education” Proceedings of the IEEE, Special Centenial
Issue, VOL:100, pp:1344 – 1360, 2012.
Gomes, L.; Bogosyan, S. “Current trends in remote laboratories”, Trans.
on Industrial Electronics, VOL. 56, Issue. 12, pp: 4744 – 4756, 2009.
Gomes, L.; Garcia-Zubia, J. (eds) Advances on Remote Laboratories
and e-learning Experiences, Ed. University fo Deusto, 300 pp. 2007.
Available https://www.weblab.deusto.es/Advances_on_remote_labs.pdf
Garcia-Zubia, J.; Alves, G. (eds) Using Remote Labs in Education, Ed.
University
of
Deusto,
464
pp,
2011.
Available
in
http://www.weblab.deusto.es/web/weblab.content/using_remote_labs_in
_education.pdf
Azad, A.; Auer, M.; Harward, J. Internet Accessible Remote
Laboratories, Ed. IGI Global, 645 pp, 2012.
http://weblab.deusto.es/boole/BOOLE_RELEASE_EN.zip
Boole-Deusto project page: https://github.com/zstars/booledeusto
http://www.weblab.deusto.es
Garcia-Zubia, J. “Educational software for digital electronics: BooleDeusto”, Proc. of IEEE Int. Conf. on Microelectronic Systems
Education, pp:20 – 22, 2003.
Garcia-Zubia, J.; Orduña, P.; Alves, G. “Addressing Software Impact in
the Design of Better Remote Labs”, Trans. on Industrial Electronics,
VOL. 56, Issue 12, pp: 4757 – 4767, 2009.
Garcia-Zubia, J et al, “Innovative Autonomous Hardware for Remote
Experimentation with Microcontrollers” Proc. IEEE Int. Conf.
International Conference on E-learning in Industrial Electronics, ISBN:
978-1-4244-4654-4, 2 pp, 2009.
P. Orduna, J. Irurzun, L. Rodriguez-Gil, J. Garcia-Zubia, F. Gazzola,
and D. Lopez-de Ipiña, “Adding new features to new and existing
remote experiments through their integration in weblabdeusto,”
International Journal of Online Engineering (iJOE), vol. 7, no. S2, pp.
pp–33,
2011.
Integration of a Remote Lab in a Software Tool for
Digital Electronics
Authors Name/s per 1st Affiliation (Author)
Authors Name/s per 2nd Affiliation (Author)
line 1 (of Affiliation): dept. name of organization
line 2-name of organization, acronyms acceptable
line 3-City, Country
line 4-e-mail address if desired
*IMPORTANT – Author name should NOT be filled
line 1 (of Affiliation): dept. name of organization
line 2-name of organization, acronyms acceptable
line 3-City, Country
line 4-e-mail address if desired
Abstract—The combination of Boole-Deusto (software tool for
digital electronics design) and WebLab-Deusto-FPGA (remote
lab) allows teachers and students to complete the full design cycle
in a computer in only a few minutes: from the truth table or FSM
to the real implementation in a FPGA. The system described is
oriented towards a first year course in digital electronics.
implements its solution. This follows a methodological
process. Firstly, the problem statement is translated into a truth
table. Secondly, the Karnaugh maps are obtained (from the
truth table) to minimize the Boolean equation. Finally, the
resulting equation is transformed into either a logic gates based
digital circuit or a VHDL program (Fig. 1).
Keywords—remote laboratories, digital electronics
I.
INTRODUCTION
It is very common in the field of digital electronics to teach
using software tools for the analysis and design stage, and then
laboratories to implement the designed circuits. But from the
point of view of teachers and students, not all approaches are
equally effective.
This demo paper presents the Boole-Deusto software tool.
This tool takes students through the design process first (truth
table, K maps, etc.) and then also through the implementation
process, using a remote laboratory: WebLab-Deusto-FPGA.
Boole-Deusto-FPGA allows users (teachers or students) to go
through the whole process, from the description to the physical
implementation and testing, in just a few minutes.
Boole-Deusto-FPGA is part of the OLAREX project to
promote and to facilitate science and technology among young
people in secondary schools.
II.
BOOLE-DEUSTO
The Boole-Deusto software tool was developed and
released for the first time around 2000 [1]. Its main objective
was to help teachers and students in the teaching and learning
process of digital electronics, especially for introductory
courses (first year).
Digital electronics can be divided in two types. Bit-level
digital systems, which are based on logic gates (AND, OR,
NOT) and flip-flops (D, J-K), and word-level digital systems,
which are based on integrated circuits (adders, encoders,
multiplexers, counters, etc). Boole-Deusto focuses on bit-level
systems.
The creation of a combinational digital system starts with
the problem statement and finishes with the digital circuit that
No. 518987-LLP-1-2011-1-ES-KA3-KA3MP funded with support from
the Lifelong Learning Programme (KA3 - ICT) from European Union
Fig. 1. Design process of a bit-level combinational circuit.
In general, professional software tools like Proteus,
LogicSim, etc. do not help the teachers and students in all the
steps, because their focus is only in the result: the digital
circuit. Through Boole-Deusto, however, users can be taken
through all the process step by step, providing them with full
control, allowing them to modify the system at any stage.
Fig. 2 describes the process of designing a BCD error
detector: if the input (four switches) is not a BCD code, then
the output (one led) will be 1.
Fig. 2. BCD error detector in Boole-Deusto.
The same approach is used with sequential digital systems.
In this case the process starts with the Finite State Machine
(FSM) and finishes with the digital circuit implemented with
flip-flops (Fig. 3).
through virtual switches and buttons, as well. For instance, if
we have implemented the BCD error detector that we
mentioned previously, and users introduce 1010 with the
switches, they will soon see the LED turn on.
Fig. 3. Sequential digital system in Boole-Deusto.
Currently, Boole-Deusto, which is an Open Source project,
has been downloaded thousands of times (see Fig. 4 for
downloads since 2007) [2].
Fig. 6. BCD-ERROR system in WebLab-Deusto, running properly.
Fig. 4. Statistics of the Boole-Deusto downloads.
After the design process, students can either print a diagram
of the circuit or obtain the VHDL program which describes it.
Then, they should move to a laboratory to implement that
circuit and analyze if it runs properly or not. Generally, as
stated, the design is made in a standard classroom or at home,
whereas the implementation is made in an electronics
laboratory with specialized equipment. The aim of this new
approach has been to connect Boole-Deusto with a remote
laboratory (WebLab-Deusto), in order for students to be able to
remotely test their designs. This is often easy, straightforward
and convenient, because no wiring or specialized equipment is
required. An internet connection is enough to get the designed
system implemented in a real, physical board, and to interact
with it and check its response.
III.
CONNECTING BOOLE-DEUSTO TO WEBLAB-DEUSTO
Once users finish the design process users can click on the
WebLab-Deusto button to directly access a FPGA controlled
by WebLab-Deusto.
Fig. 5. WebLab Mode for combinational systems
When this is done, a browser will be opened. Once the
VHDL file that Boole-Deusto generates has been uploaded, the
code is automatically synthesized and programmed into the
remote FPGA board. Once this process has finished, users will
not only be able to see how the system runs, but interact with it
The next step involves improving the user experience and
increasing the educational potential of the experiments through
augmented reality. A virtual model of a system is shown
alongside the FPGA board. Then, the FPGA board can be used
to control that virtual model, just as if it was being used to
control a real appliance, resembling more closely a real-life
scenario.
Fig. 7. FPGA watertank experiment running in WebLab-Deusto.
As Fig. 7 shows, the FPGA Watertank experiment displays
a virtual water tank over the webcam stream of the board.
Watertank control is a potential use of a FPGA. In this case, we
have three level-sensors available (represented as small red
spheres), two water pumps, and an output (whose flow varies
randomly, representing water demand). The aim of the VHDL
code to program in the FPGA would be to keep the water level
of the deposit between a certain threshold, never overflowing
and never going too low.
Technically, the virtual model takes the LEDs as inputs,
which lets users control the water pumps easily through VHDL
code. The virtual sensor inputs are also readily available to the
VHDL code, replacing some of the switches that can normally
be controlled manually (which are seen below).
REFERENCES
[1]
[2]
Garcia-Zubia, J. “Educational software for digital electronics: BooleDeusto”, Proc. of IEEE Int. Conf. on MSE, pp: 20 – 22, 2003.
paginaspersonales.deusto.es\zubia
An Integrated Solution for Basics Digital
Electronics: Boole-DEUSTO and WebLabDEUSTO
J. García-Zubía1, L. Rodríguez-Gil1, P. Orduña2, I. Angulo1, U. Hernandez-Jayo1, O. Dziabenko2, ML.
Güenaga2, R. Artiach3
1
2
Faculty of Engineering - University of Deusto, Bilbao, Spain
DeustoTech Learning – University of Deusto, Bilbao, Spain
3
Urdaneta School, Bilbao, Spain
Abstract—The software BOOLE-DEUSTO is oriented to the
design of digital electronic circuits from the student point of
view. On the other hand, WebLab-DEUSTO is a well known
remote laboratory, and one of the implemented experiments
is focused on CPLD and digital electronics. The objective of
this paper is to describe the results of connecting BOOLEDEUSTO and WebLab-DEUSTO. Under this common
approach, a novel student can design a digital circuit using
K maps, truth tables, Boolean expressions, etc. and then,
automatically, he/she can implement, download and see the
real circuit in the remote lab.
Index Terms — remote experiments, digital electronics.
I.
INTRODUCTION
From a methodological point of view, to design a
digital circuit at the bit-level consists on transforming
every representation into the next one. In a bit-level
combinational digital circuit, the different representations
are: text, truth table, V-K maps, Boolean expressions and
digital circuits using AND, OR and NOT logic gates (or
NAND/NOR gates). In a bit-level sequential digital circuit
(Finite State Machine), the different representations are:
text, FSM diagram (Moore or Mealy), truth table, Boolean
expressions and digital circuit using J-K or D flip-flops.
This process is followed step by step by
teachers/students. The next step in this process is the
implementation of the digital circuit. To do this the
teacher/students can follow two main directions: 74XX
integrated
circuits
and
programmable
devices
(microcontrollers, CPLD, FPGA, etc.). It is very popular
to use CPLD/FPGA devices to implement digital circuits.
Under this approach, the student must obtain a new
representation of the system using the VHDL
programming language in a complex design environment
(ISE Xilinx, etc.).
This paper shows how to connect these representations;
truth table, V-K diagrams, digital circuit… (what is more
related with the students and the classroom) with the real
devices (CPLD/FPGA) in the laboratory. This process is
implemented connecting BOOLE-DEUSTO (a software
tool for digital circuits design) and WebLab-DEUSTO
(remote laboratory).
BOOLE-DEUSTO SW FOR DIGITAL
ELECTRONICS
The software BOOLE-DEUSTO [1] is a Boolean
calculator for the students and its first version was
designed in 2000. They are able to design step by step a
digital circuit using the same method as the one used in
the classroom.
In general, the design process of a digital circuit at bit
level is made up of different steps. After reading the
statement, the teacher/student will obtain the truth table,
the V-K map, the minimized Boolean expression and the
digital circuit using AND-OR, NAND or NOR gates.
In Boole-Deusto, the user writes a name for the system
and shows the number of inputs and outputs. After doing
this, Boole-Deusto offers the user different ways to
describe the system (Fig. 1): truth table, V-K maps, etc.
II.
Figure 1. Description of a combinational digital circuit
Fig. 2 shows the truth table of a BCD error detector. It
shows that the combinations 1010–1111 activate the
output.
1
Figure 2. Truth table of the BCD error detector
At this moment the student can see the V-K map or
even he or she can modify it. And after this, Boole-Deusto
can show the solved V-K map with the loops and the
Boolean expressions (Fig. 3).
The main difference between BOOLE-DEUSTO and
other professional software tools (Proteus, OrCAD, etc.) is
that BOOLE-DEUSTO is educational software and
oriented to learning outcomes, while Proteus is focused to
industrial companies to obtain real circuits [2]. But the
two points of view are needed:
 Boole-Deusto is more centered in the process of
obtaining of the digital circuit, for example V-K
maps.
 Proteus is more centered in the results than in the
process.
After this process, if the student wants to see the digital
circuit in real operation, he or she has two options (at least
two options): to make the circuit with cables and
integrated circuits or to use a programmable device like
CPLD/FPGA or a microcontroller.
BOOLE-DEUSTO offers the users the possibility of
obtaining a VHDL file with the description of the system.
Fig. 5 shows the VHDL description of the BCD error
detector.
Figure 3. The solved V-K map of the BCD error detector
Finally, the student can see the digital circuit
implemented with AND-OR , NAND or NOR logic gates.
The circuits shown in Fig. 4 can not be simulated, they are
only images.
Figure 5. VHDL file with the system description.
Additionally the user must assign to each input and
output one pin of the FPGA or CPLD board in a file. To
obtain the UCF file (user constrains file), the user needs to
know where the pins are. Table 1 shows the pins assigned
to six switches and leds.
TABLE I.
Inputs
switch 5
switch 4
switch 3
switch 2
switch 1
switch 0
RELATION BETWEEN INPUTS/OUTPUTS AND PINS OF
THE CPLD&FPGA BOARDS
FPGA
pin
E15
E16
F15
G15
G16
H15
CPLD
pin
P66
P67
P68
P69
P71
P70
Outputs
led 5
led 4
led 3
led 2
led 1
led 0
FPGA
pin
N12
P13
N14
L12
P14
K12
CPLD
pin
P6
P5
P4
P3
P2
P1
The UCF with the assignation for the BCD error
detector is in Fig. 6. It is a very simple txt file.
Figure 4. AND-OR and NAND digital circuits
2
The VHDL program can be implemented using a FPGA
or CPLD device and a software environment. In the
University of Deusto we use Xilinx devices and the ISE
WebPack Free environment [3].
Figure 6. UCF for the BCD error detector
This software tool can be used for combinational (logic
gates) and for sequential (Finite State Machines) digital
circuits.
Fig. 7 shows the use of the Boole-DEUSTO to
implement a Moore FSM that detects in the input
sequence three or more 1s.
III. WEBLAB-DEUSTO REMOTE LAB
At this moment, the Faculty of Engineering of the
University of Deusto offers students a classical laboratory
for digital electronics based in Digilent FPGA educational
boards and it also offers the WebLab-Deusto. The two
options are freely managed by the student. He or she can
design and implement his or her systems using a real
board or the remote lab. Even the students can buy these
educational boards because they are cheap (around $ 50
for a CPLD board and $ 150 for a FPGA board). Digilent
is the best well known company [4] in CPLD&FPGA
educational boards. From our point of view there is not a
competition among the different options, we do not have
to decide which is the best option, simply we offer all of
them to the students. They will decide depending on their
needs, and this election can change week by week. It is up
the students.
To sum up, the major advantage of a remote lab is that
it can be used everywhere and at any time by the student,
and he or she only needs an Internet connection. On the
other hand, with a real board, the student improves the
sense of reality and can interact with other students.
WebLab-Deusto [5] is a remote lab that allows users to
make real experiments using the Internet connection. It
includes different devices and experiments: PIC
microcontroller, microbot, a toy submarine, Xilinx CPLD,
Xilinx FPGA, VISIR LXI and an experiment with logic
gates. Fig. 9 shows the WebLab-Deusto Web page with
the different offered experiments.
Figure 7. FSM of the sequence detector “111”.
Again, the student can obtain the digital circuit and the
VHDL description, as it is shown in Fig. 8.
Figure 9. WebLab-Deusto web page with the experiments available
Figure 8. FSM's descriptions: digital circuit and VHDL program
WebLab-Deusto is an Open Source (GNU GPL) [6]
platform for remote experimentation. The remote
experiments offered by Weblab-Deusto can be accessed
using any Web browser and any operating system through
a PC, laptop, tablet, smart phone, etc. WebLab-Deusto
offers administration tools like access control, login, etc.
and supports federation and load balance of remote
experiments. It is being used since 2004.
There are more platforms for remote experimentation
like iLAB or labShare [7] and there are also others
implementations of FPGA/CPLD remote labs [8, 9].
Attending the CPLD and FPGA devices and the VHDL
programs, the remote lab WebLab-DEUSTO allows users
to upload a file (.bit for FPGA and .jed for CPLD) to
control inputs, and to see the outputs through a webcam.
3
Fig. 10 shows the Weblab-DEUSTO interface for a CPLD
[10].
Figure 10. WebLab-DEUSTO remote experiment with a CPLD
Continuing with the process started in Section II, after
the obtaining of the VHDL code, the last step is to connect
the VHDL file obtained by the student in the BOOLEDEUSTO environment with the remote experiment
implemented by the WebLab-DEUSTO. This process is
controlled more or less automatically (see Fig. 11):
 If the student has experience with ISE WebPack
(Xilinx), he or she can follow the process by his
own: open a new project, add the VHDL source
given by Boole-Deusto, integrate it with the UCF file
and synthetize-implement the project to obtain the
BIT file that will be uploaded in the WebLabDeusto-FPGA (or the JEDEC file for the WebLabDeusto-CPLD). But surely in this situation the
student will prefer to design his project without the
Boole-Deusto, programming it directly in VHDL.
 On the other hand, the novel student will write the
truth table or will draw the FSM in Boole-Deusto
and the proposed automatic process will create in
ISE WebPack the project, will add the UCF file and
finally will obtain the BIT file. In this case the
student is involved in the description (the behavior),
but not in the implementation.
VHDL file
BOOLE-DEUSTO
ISE Xilinx
ucf file
bit/jedec
file
weblab.deusto.es
Figure 11. Integration of BOOLE-DEUSTO and WebLab-DEUSTO
In the second scenario, the ISE environment will be in
the server side, so in this case the student will upload the
VHDL code (generated by the Boole-Deusto) and the
UCF file, and the proposed system will obtain
automatically the BIT file, and after this the FPGA will be
programmed. After two minutes, the student will see the
interface of Fig. 9 and he or she will control the inputs (10
switches and 4 buttons) and will see the outputs through
the webcam (six leds and one 7-segments). At present,
there is a prototype of this automated process, but the final
version is still under design.
With the combination of Boole-Deusto and WebLabDeusto, the user can follow step by step the design and
implementation of a digital circuit.
From the teacher point of view, he or she can design
and implement in the classroom a digital circuit in front of
the students. During this process –using a video projectorall the students will see at the same time the system
running, so the teacher can analyze the system through a
real experiment, not with a simulation or something
similar. This strategy can be a powerful tool for teachers,
not only in the university, but also in the schools.
IV. OLAREX PROJECT
The combination of Boole-DEUSTO and WebLabDEUSTO is being developed in the OLAREX project
funded by the EU to enhance and modernize STEM
curricula, foster student´s creativity and motivation, and
develop professional e-didactic and technology
competences and skills (see Fig. 12).
Figure 12. OLAREX Project: learning modules
One part of the project is to train participants, and after
this they will:
(1) improve e-didactic competences;
(2) know the basic theory of remote experiments,
how to access a remote laboratory;
(3) be able to create new e-learning materials,
courses, and remote experiments.
One module is related with digital electronics and it is
being implemented with Boole-DEUSTO and WebLabDEUSTO. This module will be used in the subject
“Technology” in the last semester of the secondary school
with students 16 - 17 years old. It will be used in Urdaneta
School (Bizkaia, Spain).
The main objective of this part of the subject is to learn
about the basis of digital electronics: Boolean algebra,
logic gates, integrated circuits, etc. The system proposed
will allow the teacher and the students to implement real
digital circuits to reinforce the theoretical concepts
introduced.
4
In general it is very difficult for secondary schools to
create and maintain laboratories in the field of digital
electronics (it is not their main focus), but with the system
proposed students and teachers can implement real
systems without economic and technological efforts, they
should only be concentrated in the description of the
digital circuit, not in the technical side.
At this moment this module is under development
together with URDANETA School in Bilbao (Spain), and
after its use in the classroom the results will be analyzed.
V. CONCLUSIONS AND FUTURE WORK
The integration of BOOLE-DEUSTO and WebLabDEUSTO allows the student to design and test a real
digital circuit in an easy way.
Under this approach, the student not only can improve
his autonomous work, but also he or she can work in a real
scenario (the remote lab is a real laboratory connected
through Internet) without being observed by the teacher.
This combination can be used by teachers to teach, and
by students to learn in autonomous way.
ACKNOWLEDGMENT
This work has been performed within the project
“OLAREX: Open Learning Approach with Remote
Experiments”. The project is supported by European
Union within KA3 (ICT) activity of Lifelong Learning
Programme (project No. 518987-LLP-1-2011-1-ES-KA3KA3MP). The opinions expressed by the authors do not
necessarily reflect a position of the European
Community, nor does it involve any responsibility on its
part.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
http://paginaspersonales.deusto.es/zubia/
Garcia-Zubia, J. 2003. “Educational software for digital
electronics: BOOLE-DEUSTO”, IEEE Int. Conf. Microelectronics
Systems Education, MSE 2003, Anaheim (USA).
http://www.xilinx.com/support/download/index.htm
http://www.digilentinc.com
http://www.weblab.deusto.es
http://code.google.com/p/weblabdeusto/
Garcia-Zubia, J. and Alves, G. eds. 2011. Using remote labs in
education. Ed. University of Deusto, ISBN: 978-84-9830-335-3
Gomes, L. and Bogosyan, S. 2009. “Current trends in remote
laboratories”. Trans. On Industrial Electronics, VOL. 56, Nr. 12,
pp: 4744 – 4756.
OLAREX project. No. 518987-LLP-1-2011-1-ES-KA3-KA3MP funded
with support from the Lifelong Learning Programme (KA3 - ICT) from
European Union
[9]
Azad, K.; Auer, M.; Harward, J. 2012. Internet Accessible Remote
Laboratories: Scalable E-Learning Tools for Engineering and
Science Disciplines. Ed. IGI Global. ISBN 978-1-61350-186-3,
USA.
[10] Garcia-Zubia, J. et al. 2012. “WebaLba-Deusto-CPLD: A practical
experience” Int. Journal of Engineering Education, iJOE, VOL 8,
special issue exp.at’11 pp: 17-18.
AUTHORS
J. Garcia Zubia, is with the University of Deusto,
Faculty of Engineering, Avda de las Universidades 24,
48007 Bilbao, Spain (e-mail: [email protected]).
L. Rodríguez-Gil, is with the University of Deusto,
48007 Bilbao, Spain (e-mail:
[email protected]).
P. Orduna is with the University of Deusto, Deusto Tech
Internet, Avda de las Universidades 24, 48007 Bilbao,
Spain (e-mail: [email protected]).
I. Angulo is with the University of Deusto, Deusto Tech
Mobility, Avda de las Universidades 24, 48007 Bilbao,
Spain (e-mail: [email protected]).
U. Hernández-Jayo is with the University of Deusto,
48007 Bilbao, Spain (e-mail: unai.hernandez@ deusto.es).
O. Dziabenko is with the University of Deusto, Deusto
Tech Learning, Avda de las Universidades 24, 48007
Bilbao, Spain (e-mail: olga.dziabenko@ deusto.es).
ML. Güenaga is with the University of Deusto, Deusto
Tech Learning, Avda de las Universidades 24, 48007
Bilbao, Spain (e-mail: mlguenaga@ deusto.es).
R. Artiach is with the Urdaneta School, Lauroeta
Etorbidea, 6 48180 Loiu, Spain las Universidades 24,
48007 Bilbao, Spain (e-mail:
[email protected]).
5
REV2012
04 - 06 July, Bilbao
Advanced integration of OpenLabs VISIR
(Virtual Instrument Systems in Reality) with
Weblab-Deusto
L. Rodriguez-Gil1, P. Orduña2, J. García-Zubia1, D. López-de-Ipiña2
Faculty of Engineering, University of Deusto, Bilbao, Spain
DeustoTech – Deusto Institute of Technology, University of Deusto, Bilbao, Spain
1
2
Abstract—During the last years, VISIR (Virtual Instrument
Systems in Reality) has proved itself a useful tool for
electronics remote experimentation, having been deployed
in several different universities. As a domain-specific remote
laboratory, VISIR offers those features which are required
for its stand-alone usage, such as authentication, scheduling,
user management, etc. Though for certain purposes this
may be adequate, often it is more appropriate to offer
VISIR as one kind of experiment among many, under a
generic remote laboratories framework, such as WebLabDeusto, MIT iLabs or Labshare Sahara. These frameworks
provide integrated access to several different kinds of
experiments, such as electronics, robotics, etc. Through this
integration, a smooth experience can be provided to the
user, and VISIR can benefit from all the functionality that
the generic framework provides (common authentication,
load-balancing, scheduling, etc). Efforts are currently being
made to integrate VISIR with various laboratories. In this
paper, we describe what the integration of VISIR with
Weblab-Deusto involves; how certain VISIR-specific
functionalities that depended on its original framework
were handled, and how through Weblab-Deusto VISIR can
easily gain certain new features. Some of those are the
integration with different environments such as Facebook,
or with Learning Management Systems such as Moodle.
Another feature is collaboration among VISIR users, which
makes it possible to share a VISIR circuit in real time.
Furthermore, through this association VISIR gains new
possibilities, such as federation.
experiments only need to worry about implementing their
experiment-specific
code.
User
management,
authentication, authorization, etc, and even more advanced
features such as load-distribution, logging, user tracking,
replication or federation is already provided by the
framework.
On the other hand, domain-specific remote laboratories
tend to focus on providing access to what we could
consider a single, but very complex experiment. That is
the case with VISIR.
Created in the BTH and used by several other
universities, VISIR is a system which provides a remote
electronics laboratory. This laboratory is meant to be as
similar to a traditional electronic laboratory as possible.
Thus, it lets users (generally students) graphically design
a circuit through a web-based Adobe-Flash interface.
Through a relays system, the VISIR hardware can then
physically “build” an equivalent of that circuit. Real
physical measurements can then be provided to the user
through the realistic user interface that the web client
provides, which includes tools such as oscilloscopes or
multimeters, commonly found on local laboratories. The
hardware is capable of rapidly switching circuits,
transparently serving and providing real physical
measurements for many users (and their circuits) at once.
It is important to remark that those measurements are not
simulations; the circuit is physically wired, and the
measurements taken.
Index Terms— remote-labs, integration, VISIR
I.
INTRODUCTION
Nowadays, Remote Laboratory Management Systems
such as MIT iLabs [1], Labshare Sahara [2] or WeblabDeusto [3] coexist with domain-specific ones such as
VISIR (Virtual Instrument Systems in Reality).
The former aim to provide a powerful, reusable and
scalable framework that can be shared among a number of
very different experiments. For instance, besides VISIR
itself, some experiments that are currently available for
Weblab-Deusto are several robotics experiments, some
electronics experiments with Pic microcontrollers and
FPGA (Field Programmable Gate Array) devices, etc.
These remote laboratory frameworks can typically be
extended easily with new experiments, because they
already provide most of the core functionality that a
remote laboratory requires. Hence, the developers of new
www.rev-conference.org
Figure 1. VISIR’s hardware and equipment server. Through this
means, circuits are physically built through the use of relays. [5]
VISIR, as a domain-specific laboratory, implements
several layers of functionality that are actually common to
all remote laboratories, such as user management,
291
REV2012
authentication and authorization, and the user interface
required for these.
The provision of these basic layers is at times very
convenient, because through them VISIR can be offered
as a stand-alone solution that does not depend on
sometimes more cumbersome Remote Laboratory
Management Systems. However, because these basic
layers are for them a requirement, but not really their
focus, most often they lack certain advanced features that
their more generic counterparts do provide, and they tend
to present some significant issues and limitations.
Also, often the institution that wishes to host a VISIR
instance will also be interested in offering several other
experiments through a generic remote laboratory
framework such as Weblab-Deusto. If VISIR is offered
through its stand-alone framework, the users will have to
access it through a completely different interface than
every other experiment, with a different web-page, a
different “login” screen, a different experiment queue, etc.
Frequently, even if no other experiments are offered,
using a more advanced, specialized remote laboratory
framework is desirable, due to the additional features that
it offers. For instance, VISIR does not support
authentication mechanisms using Single Sign On, neither
federation, which are provided by these Remote
Laboratory Management Systems.
In this context, efforts are being placed to support
VISIR in other Remote Laboratory Management Systems,
such as MIT iLabs [4].
In this paper, we will describe the steps that we took to
integrate VISIR with such a framework (Weblab-Deusto),
and the difficulties we overcame.
II.
RELATED WORK
Figure 2. VISIR architecture. Organization of the online
laboratories. [5]
Additionally, a few specific functionalities of the Flash
client are also dependent on the Web layer.
It might be noteworthy that, as we will discuss in later
sections of this paper, this layer is not really necessary
when VISIR is to be integrated in a RLMS, and one key
step of the integration process will be removing the
dependency on it.
B. WebLab-Deusto
WebLab-Deusto is a Remote Laboratory Management
System. As such, it provides the generic (authentication,
user management, etc) and advanced (federation) features
discussed in previous sections.
Through WebLab-Deusto students can access
experiments. An example of an experiment is, for
instance, a robot. Students can start the experiment and
then, through the interface provided by the experiment (in
this case, buttons and a video-stream) see the robot in realtime and move it around.
A. VISIR architecture
VISIR [5], which is Open Source software, is made of
four different, mostly independent components:
 Equipment server
 Measurement server
 Flash client
 Openlabs Web layer
The equipment server deals with the hardware and the
circuit-wiring robot. The measurement server works with
the equipment server to provide the real-time
measurements that are meant to be provided to the client.
The flash client, connected to the measurement server,
provides the experiment user-interface, easily accessible
through most browsers. Finally, the Openlabs Web
provides the aforementioned basic remote experimentation
layers, including the initial web-pages, user authentication
and authorization, access to the different laboratories, etc.
This layer also includes a database, used to store users,
circuits and other information.
Figure 3. One of WebLab-Deusto robotics experiments (on a
mobile phone, at night, video stream provided by an infrared
camera).
292
REV2012
In the general case there are essentially three main
components to a WebLab-Deusto experiment.
First, an experiment needs the actual hardware behind
it. Following the previous example, this hardware would
be the robot (and, in practice, the hardware necessary to
send the actual commands to the robot).
Second, an experiment needs a user interface, which we
will refer to as the experiment client. This would be the
web interface with the buttons and the video-stream to
control the robot, and the logic behind it. It might be
worthwhile to remark that each experiment has its own
client, interface, and client-side logic, and they will thus
tend to be very different from one another. In fact,
WebLab-Deusto supports several different technologies
for its clients, such as GWT (plain web), Adobe Flash or
Java Applets, or even non-web-based technologies such as
C# (.NET) or C++.
Third, an experiment needs a server-side component to
define its specific logic and behavior. This is what we
know as the experiment server. In the robot example,
when the student requests the robot to move (through the
experiment client) a message is sent to the experiment
server. The experiment server will then process that
message, and take the appropriate action. In this case, a
lower-level message will be sent to the board that
physically controls the robot, and it will then move.
Figure 4. WebLab-Deusto architecture. Experiment servers are
hosted in the Laboratory servers.
III. APPROACH
As explained in more detail in the previous sections, the
VISIR software is made essentially of four different parts:
The flash web client, the web interface, the measurement
server, and the equipment server. We want to provide
fully functional integration into Weblab-Deusto, so that
we can leverage what such an integration offers.
Nonetheless, at the same time we want to minimize
modifications to VISIR itself. For this, we have had to
consider several different approaches. We will discuss
those approaches we have discarded first, and explain the
one we have finally chosen afterwards.
A. Shallow integration
The first strategy we may consider could be to simply
‘embed’ the standard VISIR web interface within WeblabDeusto, without further modifications. This could be done,
for instance, by using an iframe. It would be particularly
fast and straightforward to implement. However, it would
not really meet our requirements. Users would indeed
access VISIR through Weblab-Deusto, but they would
still have to navigate through the VISIR web interface
itself, and they would have to authenticate to both
Weblab-Deusto and VISIR. Thus, the user experience
would not be smooth at all, which was actually one of our
main goals. Besides, from such a shallow integration, we
would not get any of the advantages mentioned in
previous sections (scalability, auditing, etc). We can hence
discard this too simplistic approach.
B. Authentication replacement
As a more complicated variation of this, we could
consider embedding only the standard VISIR flash client,
and not the whole VISIR web interface. Though contrary
to the previous approach, certain modifications to VISIR
would be required, these modifications would be limited
to the web interface. The flash client (and of course, the
other two VISIR components) would remain untouched.
Also, the changes required to the web layer would not be
too many. Replacing the user authentication code (so that
users need only authenticate once with Weblab-Deusto
itself) would be the most significant change. Additional
work would also be required for circuit listing and
selection.
This approach would be significantly more effective
than the previous. The experience would be seamless to
the end-user, and we could at least to some extent leverage
many of the advantages that Weblab-Deusto provides,
such as scalability, load-balancing, scheduling or even
other more specific features such as federation or
automatic facebook and LMS integration. Unfortunately,
certain limitations exist. First, even though we replaced
the authentication scheme, the system is still fully
dependent on the VISIR PHP web layer and on its
database. This is somewhat inconvenient and hinders
maintainability because most often remote laboratory
frameworks such as Weblab-Deusto will have their own
database and often will use different server technologies
(and will thus be unwilling to depend on PHP). Second,
though this could be made mostly transparent to the user,
the VISIR client is not fully integrated with WeblabDeusto, and does not work the way standard experiments
do. The flash client communicates directly with the
measurement server. Thus, Weblab-Deusto has no control
over the actual experiment. Unlike with standard
experiments, it is not possible to audit the actual activity
of the user, or to access his or her results.
C. Our approach (Deep integration)
Due to the reasons exposed above, we have chosen a
different approach, which is more complete though also
slightly more complicated. In this approach, we will
completely replace the VISIR web layer. Thus, we will
not be dependent on PHP or on the VISIR database
anymore. Also, we will route all VISIR traffic through
Weblab-Deusto itself, in order to obtain full auditing
capabilities and full control over the experiment. Though
this does indeed require certain modifications to the
VISIR client, thanks to the client’s modular design those
modifications are scarce.
D. Summary
As discussed in further detail in the previous section,
several approaches were available. Out of them, we chose
the one which probably involves the most work, but also
the most features. We will next summarize advantages and
characteristics of each approach through three tables.
293
REV2012
The first table lists the three approaches that we have
considered: Shallow integration, authentication-only
integration, and deep integration.
TABLE I.
CONSIDERED APPROACHES
A
B
C
Approach
Shallow
Auth-only
Deep
(chosen)
Involves
Embedding the whole, standard VISIR website.
Replacing the authentication procedure of VISIR
(implemented in the VISIR web layer).
Replacing the whole web layer and proxying all
communication through the RLMS.
The second table specifies which features are supported
by each approach, and which are not.
TABLE II.
SUPPORTED FEATURES
A
Yes
B
Yes
C
Yes
Full experiment control b
No
No
No
Yes
No
No
Yes
Yes
Yes
Extended features c
No
No
Yes
Accessible through the RLMS a
Smooth user experience
Logging & auditing
a
Remote Laboratory Management System. Weblab-Deusto, in our case.
Ability to start and stop the experiment, thus being able to control the
number of users and their use of the experiment, etc.
c Features such as supporting several different VISIR instances, control
over the components definition file, circuit publishing, etc.
b
The third table lists which of the four VISIR
components need to be modified to implement each
approach.
TABLE III.
CHANGES REQUIRED TO VISIR (COMPLEXITY)
Web layer (minor changes)
Web layer (major changes)
Flash client
Other components a
A
No
No
No
No
B
Yes
Yes
No
No
C
Yes
Yes
Yes
No
a
Particularly, the equipment and measurement servers. None of the
methods requires to changes to those.
We can easily appreciate an incremental pattern in both
tables. The approaches can be ordered in terms of features
and complexity, and then each one is in fact a subset of
the next according to either criteria.
IV.
IMPLEMENTATION
A. Basic integration
As previously discussed, we chose a powerful but
relatively complicated approach for our integration,
which required major changes to the web layer (it will be
replaced altogether) and relatively minor changes to the
VISIR Flash client.
We have divided the integration process in several
stages. After this first stage is completed, authentication
will be working through Weblab-Deusto, and all
communication to VISIR will be proxied through the
RLMS (and hence, all users, their commands and their
results logged). All basic VISIR features will be working,
except for some features which depend on the now-gone
VISIR web-layer, and except for some additional features
which are extensions to the original VISIR.
The VISIR client originally supports two different
“transports”. These transports are the channels through
which it can communicate with the measurement server.
Their names are specifically TransportHTTP and
TransportXMLSocket. As they suggest, the first one
communicates through HTTP while the second
communicates through sockets.
We have developed a new transport, TransportWeblab.
Through this new transport, we accomplish the goal of
routing all communication through Weblab-Deusto.
Internally, this is achieved through the use of a Javascript
interface that Weblab-Deusto provides.
Using this approach, we were able to get most VISIR
functionalities working through Weblab-Deusto.
Additionally, this integration provides several
advantages:
 Coherent user interface
 Load-balancing
 Logging & auditing capabilities
 Scheduling
 User management & authentication
 Control over the experiment & command
interception capabilities
There are still, however, certain limitations. As we
mentioned in previous sections, we have chosen to no
longer have the VISIR Web layer (unless we installed it,
which is not what we want). There are certain features of
the VISIR flash client which depend on it. Hence, without
further changes, those features will not be available
anymore. An additional effort will be required to reimplement these features. Sometimes, in fact, we will
even be able to improve and extend these features, or even
add altogether new ones. These matters will be discussed
in later sections. We will next discuss which features were
no longer working due to their web-layer dependency, and
the steps we took to resolve those issues.
B. Circuit list
In VISIR, a “circuit” is the current layout of the wires
and components. It includes both a layout in the
breadboard and the set of components that are available to
the user.
The most noticeable feature which the original VISIR
web layer provided is probably the ability to choose a
circuit among a list.
This is a particularly useful feature, because by means
of this system, teachers can accomplish two goals:
 Provide a starting point
 Limit the choice of components
294
REV2012
original VISIR, the base circuit is specified through the
“flashvars” parameter. This parameter, common to all
Flash applications, is passed to the application on startup,
on the HTML itself. Weblab-Deusto was originally not
fully prepared for that kind of requirement, so we made
certain modifications. It is now possible to dynamically
reload the flash application upon request (in our case, with
a new flashvar parameter, defining the chosen circuit).
This is done transparently, and the CTransportWeblab is
also re-initialized as required.
Figure 5. VISIR and the circuits list, on the lower left.
Though it would be possible for teachers to simply let
users start with a blank breadboard, and to let them choose
any component they wish, this is often inconvenient. It is
often more appropriate to start with several components
and wires already placed, so that the student can focus
only on those parts relevant to his specific course or
experiment, and not waste time building the circuit from
scratch. Likewise, limiting the choice of components is
often a good choice, because having the whole list
available adds unneeded complexity. It is often more
convenient to only expose the student to those
components which are relevant to the specific course or
experiment.
In the standard version of VISIR, this feature depends
on the Web layer for the interface and logic, and on its
database (which is where the circuits are stored). As
explained in previous sections, when integrating VISIR in
Weblab-Deusto we do not want to depend on the (php)
Web layer, nor on its database.
This is therefore one of set of functionalities that we
have had to reimplement.
The web-based graphical user interface is, essentially, a
simple list, so there were no issues at that respect. The
main issues were storing and defining the circuits, and
loading these circuits upon selection. We can either embed
the circuit within our VISIR “experiment” configuration,
or just, in this same configuration, point the experiment to
a folder, from which it will load all circuits. This is a
particularly powerful approach. First, because WeblabDeusto supports having any number of VISIR
“experiments”, each of which can thus have, very easily, a
different configuration and set of available circuits. And
second, because being able to simply load the experiments
from a folder lets us, for instance, point the experiment to
a shared Dropbox folder, which the teachers themselves
can easily manage.
The circuits are thus “served” by our VISIR
experiment, once requested remotely from the client upon
clicking on the list. It is noteworthy that it is requested
through exactly the same channel that the VISIR flash
client uses to communicate with the VISIR experiment,
and through it with the measurement server.
It is maybe noteworthy that we had to tackle certain
issues for supporting on-line circuit reloading. In the
C. Saving a circuit
As explained in the section before, it is, once again,
possible to select a circuit. However, yet another feature
that depends upon the Web layer is the “save” button.
Through the “save” button, the VISIR client originally
carried out an HTTP POST request to a PHP script, which
essentially generated a circuit file, ready for being
downloaded by the user. To be able to support this feature
(and the circuit loading one, which will be explained in
later sections), we have implemented in Weblab-Deusto a
proxy, capable of intercepting file requests. Thus, when
the VISIR flash client requests a standard, static file such
as “loader.swf”, this interceptor will simply examine the
request, read the file from disk, and provide the file, as a
typical HTTP server would do. However, under other
circumstances, this interceptor will be able to provide
additional functionalities. These functionalities, at times,
go beyond simply integrating VISIR features, and through
it, VISIR can even be extended with new features.
Circuit saving is done in VISIR through a post request
to the a “/save” folder, which was originally handled by a
PHP script. These requests are now handled by our
interceptor, which will do what the PHP file used to. That
is, extract the circuit data, and provide it as an HTTP
download to the requesting user.
D. Loading a circuit
Another feature that depends on the Web layer is the
one provided by the “Load” button. This button lets the
user choose a local circuit file, which can then be loaded.
In the original VISIR, there is a set of PHP scripts which
let the user upload the circuit, save that circuit as a
temporary file to a temporaries folder, and then report to
the Flash client the URL of that new temporary file
containing the circuit. The Flash client is prepared to then
automatically load that circuit. In Weblab-Deusto, we,
once again, intercept that upload request. We then, too,
save the file to a temporary folder. However, to gain
additional safety and flexibility (which is in our case
particularly important, because we can actually have
several different instances of VISIR experiments), the
URL that we provide to the client is not the real URL to
the temporary file. Instead, it is an identifier. When the
client then requests the file through that identifier, the
interceptor, once again, intercepts the request, and is able
to serve the right file, without actually disclosing the
location of our temporary folder (and thus supporting, in
fact, any number of temporary folders).
V. IMPROVEMENTS AND EXTENDED FEATURES
As mentioned before, through the Weblab-Deusto
integration VISIR itself can actually gain new features.
295
REV2012
Through the interceptor, for instance, we intercept
“library.xml” requests in order to dynamically provide a
library.xml depending on the experiment. Thus, WeblabDeusto can host at the same time several VISIR
experiment instances, each with a different library.xml.
Another very interesting feature, which will be explored
in further detail in the future, is collaboration. Through
Weblab-Deusto and the circuit-selection and reloading
system, it is possible for one user to “publish” his current
circuit. This circuit will then be temporarily stored in the
experiment server’s memory. Then, the other users which
may be concurrently using VISIR can gain access to the
experiment the user published, and load it in seconds, just
as they would load a standard configured circuit.
It might be noteworthy that to make this possible, it was
necessary to implement, in the VISIR Flash client itself, a
new ActionScript method, SaveExperiment, which is
analogue to the pre-existing LoadExperiment. While the
later loads an experiment taking the XML string
describing it as input, the former returns the string
describing the current experiment. Thus, we gain access to
the current circuit through JavaScript (and hence through
WebLab).
VI. CONCLUSIONS
The approach we have chosen has taken a significant
effort to implement. However, it has proven itself
effective.
Teachers and students at the University of Deusto are
already using VISIR through WebLab-Deusto.
Essentially, all features supported by the original VISIR
are now supported as well, and a smooth experience is
provided to the users, who can seamlessly access VISIR
along with the other experiments that WebLab-Deusto
provides.
Furthermore, these users are already enjoying some of
the additional features (not supported by the original
VISIR) that are now made possible through the
integration.
Thanks to the new circuit listing and loading system,
teachers are now easily managing the circuits list through
Dropbox (a shared folder service).
Through the federation support that is provided by
WebLab-Deusto, other institutions such as the Colegio
Urdaneta school have gained access to Deusto’s VISIR
instance. (See Figure [3]).
Also, it is now possible to better control and schedule
access to VISIR, as it is possible to limit concurrent access
to a certain number of users, all while making use of
WebLab-Deusto advanced scheduling and prioritizing
capabilities.
Moreover, all this is done securely, as it is possible to
log and to analyze VISIR usage, as usage information,
including every command and result sent to and from
VISIR, is now being recorded and stored in the WebLabDeusto database.
Through WebLab-Deusto, it is now even possible to
access VISIR from Facebook or through LMSs such as
Moodle.
Figure 6. VISIR running in Facebook through Weblab-Deusto.
VII. FUTURE WORK
Circuit publishing is currently working experimentally.
As of now, VISIR users can indeed share their current
circuits with other users. However, this feature is in a very
early stage and can’t be used in a practical way yet.
Particularly, there are many security, design and usability
issues which are still left to tackle.
Efforts are already being dedicated (and will continue
in the future) to improve these features, and to improve
collaboration capabilities of Weblab-Deusto in general,
and of VISIR through Weblab-Deusto in particular.
REFERENCES
[1]
[2]
[3]
[4]
[5]
V. J. Hardward, J. A. del Alamo, S. R. Lerman, P. H. Bailey, J.
Carpenter, K. DeLong, C. Felknor, J. Hardison, B. Harrison, I.
Jabbour et al., “The ilab shared architecture: A web services
infrastructure to build communities of internet accessible
laboratories,” Proceedings of the IEEE, vol. 96, no. 6, pp. 931950, 2008.
R. Sarukkalige, E. Lindsay, and A. Anwar, “Laboratory
demonstrators
perceptions
of
the remote
laboratory
implementation of a fluid mechanics laboratory,” 2010.
P. Orduna, J. Irurzun, L. Rodriguez-Gil, J. Garcia-Zubia, F.
Gazzola, and D. Lopez-de Ipiña, “Adding new features to new and
existing remote experiments through their integration in weblabdeusto,” International Journal of Online Engineering (iJOE), vol.
7, no. S2, pp. pp–33, 2011.
D. Garbi Zutin, A VISIR Lab Server for the iLab Shared
Architecture. International Journal of Online Engineering (iJOE).
7(5). 2011.
I. Gustavsson, J. Zackrisson, L. Håkansson, I. Claesson and T.
Lagö, “The VISIR project – an Open Source Software Initiative
for Distributed Online Laboratories”, Proceedings of the REV
2007 Conference, Porto, Portugal, June 25 – 27, 2007.
296
REV2012
AUTHORS
L. Rodriguez-Gil is with the Faculty of Engineering,
University of Deusto, Avda. Universidades 24, 48007
Bilbao, Spain (e-mail: [email protected]).
P. Orduña, is with the Internet Unit of the Deusto
Institute of Technology, DeustoTech, University of
Deusto, Avda. Universidades 24, 48007 Bilbao, Spain (email: [email protected]).
J. Garcia-Zubia is with the Faculty of Engineering,
University of Deusto, Avda. Universidades 24, 48007
Bilbao, Spain (e-mail: [email protected]).
D. López-de-Ipiña, is with the Internet Unit of the
Deusto Institute of Technology, DeustoTech, University
of Deusto, Avda. Universidades 24, 48007 Bilbao, Spain
(e-mail: [email protected]).
297
Reusing requirements among remote experiments
for their development and integration under
WebLab-Deusto
P. Orduña1, J. Irurzun1, L. Rodriguez-Gil 2, J. García-Zubia2, D. López-de-Ipiña2
1
DeustoTech – Deusto Institute of Technology, University of Deusto, Bilbao, Spain
2 Faculty of Engineering, University of Deusto, Bilbao, Spain
Abstract—During the last decade, efforts have been made in
the development and publishing of remote experiments for
educational purposes. In order to reduce the duplicity of
work and to improve the common requirements that are
shared by different remote laboratories, remote experiment
management platforms have been developed, such as MIT
iLabs, LabShare Sahara or WebLab-Deusto. In this paper,
we describe how the development of experiments is handled
in WebLab-Deusto, supporting both managed (developed
used the APIs provided by WebLab-Deusto) and
unmanaged experiments (using Virtual Machines), and
comparing both approaches. It also shows the results of
integrating remote experiments under this system, with the
use case of VISIR, the electronics remote laboratory
developed in BTH.
Index Terms— remote-labs, architecture, distributed
I.
INTRODUCTION
The use of Remote Laboratories is particularly useful
nowadays. Since their creation, Remote Labs enable
students to remotely access experiments which are
physically located in the university, so students can be at
home or in traditional libraries while using experiments.
The quality of the experiment can be improved by the
integration of the Remote Laboratory in other digital
learning tools, or enhancing the remote collaboration.
Furthermore, the costs of the experiments can be reduced
given the degree of sharing among students that can be
achieved when they are queued much easier than in a
traditional laboratory. In summary, a traditional laboratory
is tied to a set of geographical and temporal requirements
that a Remote Laboratory can avoid, adding many benefits
to this avoidance.
However, Remote Laboratories have pursued further
benefits. Complex experiments such as VISIR1 have been
built [1], being so successful that VISIR has been
deployed in 6 European universities at the time of this
writing, along with other deployments scheduled in Asia,
and other universities consuming it remotely. In terms of
supported devices, the range has been improved [2],
supporting m-learning with Remote Labs. The range of
remote laboratories in general is so wide [3] that tools to
index are required and efforts to create and maintain these
indexes have been placed, such as Lab2go [4]. The
amount of research lines within Remote Laboratories has
1
http://openlabs.bth.se/
been extended to include quality of learning [5], even
existing workshops focused on the educational outcomes
of remote laboratories2. These outcomes have been
particularly addressed by the survey developed as part of
the LabShare project [6]. There are also efforts to consider
the issue of group formation within the context of remote
laboratories [7].
This increasing interest on Remote Laboratories has
generated big efforts to share resources among different
universities. The idea is that a provider university can
share experiments that it is using with its students, so
students of a consumer university can use them.
The MIT iLabs team3 is pioneer in this field, having
shared batch experiments among different universities
since 2004 [9], and interactive experiments since 2008 [8].
The iLabs are the most popular remote laboratories
platform, being used in different countries among the five
continents.
In the same line, the LabShare project4 in Australia is a
publicly funded project focused on building a network of
remote laboratories. As part of this project, the Sahara5
platform has been developed, and it has recently created
the LabShare Institute6 as a not-for-profit organization that
will be an independent service broker promoting,
maintaining and even hosting remote laboratories.
In Europe, the LiLa project7 (Library of Labs) was
created focused on providing the LiLa portal which
manages both virtual and remote experiments.
Efforts towards the integration of these efforts through
interoperability bridges have been placed, as detailed in
[10] for iLabs with Sahara. In fact, the Global Online
Laboratory Consortium (GOLC8) was recently created to
promote the development and sharing of remote
laboratories, which includes members of most of the
initiatives described, as well as members of WebLabDeusto, described in this paper.
One of the core research lines in the field of Remote
Laboratories is the rig management frameworks or remote
laboratory platforms, which are focused on the
2
GOLC 2011: Improving Laboratory Learning Outcomes
http://ilab.mit.edu/iLabServiceBroker/
4
http://www.labshare.edu.au/project
5
http://labshare-sahara.sourceforge.net/
6
http://www.labshare.edu.au/
7
http://www.lila-project.org/
8
http://www.online-lab.org/
3
1
management of the common requirements of the remote
laboratories.
Every Remote Laboratory has a set of requirements that
can be reused among other laboratories. For instance,
most Remote Laboratories require some kind of
scheduling: some Remote Labs will require a calendar so
students book a certain moment to use the experiment,
while other Remote Labs will handle this through a queue
of users. Authentication (asserting that the user is who
claims to be) and authorization (asserting the permissions
of the user, such as what experiments can run) are other
clear examples of requirements common to different
laboratories, since it does not matter if the experiment is
an electronics experiment or an experiment of physics to
handle authentication and authorization.
A standalone Remote Laboratory can build all these
features from scratch for that specific domain, without
using a rig management framework. VISIR is an example
of this: it is a domain specific -electronics- experiment,
but it handles authentication, authorization, scheduling,
user tracking, security, communications, etc. The problem
of this approach is that it requires the experiment
developers to keep and maintain all these layers of
software.
As opposed to this approach, an experiment could be
implemented using the tools provided by a rig
management framework. With this approach, as the rig
management framework publishes new versions, the
experiment automatically supports new features developed
by the particular framework. For instance, if developers of
the rig management framework develop a new
authentication scheme such as OpenID, the experiment
will be accessible through OpenID. Without using a rig
management framework, the experiment developers
would need to implement this support for their particular
experiment.
This paper explores the technical novelties of the
WebLab-Deusto rig management framework in its current
version (4.0M1), available for any experiment developed
within the WebLab-Deusto architecture [11].
II.
DEVELOPMENT OF EXPERIMENTS WITH WEBLABDEUSTO
A. Introduction
WebLab-Deusto9 is an Open Source10 remote
laboratory platform [12] or rig management framework,
developed in the University of Deusto. It has been used
with students as part of their courses since February 2005
through different versions of the system. It manages rigs
on top of which experiments will be run.
The development of experiments can currently be
developed using two different approaches:
• Managed experiments
• Unmanaged experiments
B. Managed experiments
A Remote Laboratory is usually composed by two
components:
9
http://www.weblab.deusto.es/
http://code.google.com/p/weblabdeusto/
10
•
•
Client: it runs in a web browser or in the student’s
desktop. All what the user will see is what the
client shows. Therefore, the client manages all the
interaction with the student, translating the actions
of the user into messages that will be sent to the
server. Examples of clients would be Java Applets,
Adobe Flash applications or the HTML code that
will be shown in the web browser. It is sometimes
referred as “rig client”.
Server: it runs attached to the hardware that will be
used by the student, located in the university. This
hardware might be an electronics board, a robotic
arm, or any device that a lesson needs. The server
code will receive requests from the client and will
control the interaction with the hardware, avoiding
harmful requests if possible. It can be developed in
any typical technology, such as Java, .NET,
Python, C++, etc. It is sometimes referred as “rig
server” in the literature.
Figure 1: FPGA experiment running in WebLab-Deusto
WebLab-Deusto embraces this clear client-server
architecture in what it calls “managed experiments”. It
provides libraries both in the client side and the server side
to handle communications and it also provides software
components that will be in the middle between client and
server. This way, it ensures that an unauthorized client can
not perform requests to the rig server, since the software
components placed in the middle will check that the client
is who claims to be. The WebLab-Deusto servers, which
are part of the software components that are in the middle,
will keep a track of all the commands sent and received
from the experiment. Furthermore, since the actual
communications between client and server are performed
through these software components, WebLab-Deusto
provides a Secure Sockets Layer to avoid the experiment
code to handle encryption issues. Given that all the
communications, and therefore several security and
tracking aspects, are handled by the platform itself, this
type of experiment is called “managed”, since they are
fully managed by WebLab-Deusto.
As an example of managed experiment, in Figure 1 a
FPGA experiment running in WebLab-Deusto can be
appreciated. Once students have logged in the system,
selected which experiment they want to run (FPGA in this
case), waited in a queue (if there were other students using
the available rigs), and sent a file that will be programmed
2
in the FPGA, they will see this panel to control the device.
Several buttons and switches are available, and students
will see the result of their actions in the device when the
webcam shows the results in the displays.
In order to develop this managed experiment, a pair of
client and server software components must be developed.
To develop the client component, WebLab-Deusto
provides libraries for JavaScript, Adobe Flash and Java
Applets. With these libraries, the client only needs to
perform some calls to a common API to send and receive
commands and files to the server. In the case of the FPGA
experiment, it will show the buttons, switches and the
webcam in the web page. It will also define that when a
switch is pressed, a command will be sent through the
provided API, containing a string such as “TURN
SWITCH 1 ON”.
To develop the server component, another library will
be used. WebLab-Deusto provides libraries for C, C++,
Java, .NET, Python or LabVIEW. This component will
have a set of methods that will be called each time a
command or file is sent. The server is expected to handle
those commands and generate a proper response, which
will be processed again in the client. In the case of the
FPGA, the server will check “TURN SWITCH 1 ON” and
will translate it to a digital signal sent to the FPGA as an
input, and this FPGA will react doing something in the 7segment display that students will see through the
webcam.
Figure 3: Virtual Machine managed by WebLab-Deusto, showing
a dummy LabVIEW experiment
C. Unmanaged experiments
While the managed experiments approach facilitates the
development of experiments, experiment developers still
need to develop code. Therefore, those engineers who are
experts in the domain of the experiments but not in web
development will find it difficult to develop the
experiments.
In order to tackle this problem, WebLab-Deusto started
supporting “unmanaged experiments”. Within WebLabDeusto, unmanaged experiments are those whose
communications are not handled directly by the platform.
While the authentication, authorization, scheduling, load
balancing and basic user tracking is still handled by the
platform, the client will contact the server by its own,
without relying on the WebLab-Deusto libraries.
As an example, Figure 3 shows a Virtual Machine
(VM) running a LabVIEW experiment. When a user
requests an experiment, WebLab-Deusto will load a
Virtual Machine and will grant the user access to this
Virtual Machine. This access will be performed through
VNC, SSH or Remote Desktop, using a specific client or
an applet within the web application.
Figure 2: Latency added by the platform additionally to the
network latency when sending a file, measured in seconds (Y
axis) and in number of concurrent students (X axis)
The provided library in the client side will manage to
send this command to the WebLab-Deusto servers, which
will propagate it to the experiment server once they have
tracked it and validated that the user has permission to use
it. All this process is transparent for the experiment
developer. While this process may seem that it adds a big
latency, it has been measured and it is kept low, as shown
in Figure 2, although it depends on the configuration used.
Therefore, the use of the managed experiments
approach facilitates the development of secure
experiments that can use the power of web applications,
optionally without requiring any plug-in and thus being
able to be used even from mobile devices. Furthermore,
since WebLab-Deusto manages all the communications
through standard HTTP/HTTPs ports, no issue will arise
regarding HTTP proxies or institutional firewalls.
Figure 4: Managed and unmanaged experiments in WebLabDeusto platform
In order to do this, WebLab-Deusto starts a VM using
VirtualBox11, starting from a particular snapshot to reduce
the startup time to few seconds. Then, WebLab-Deusto
generates a random password and will configure it in the
VM. From this moment, the VM starts allowing
11
http://www.virtualbox.org/
3
connections with that password. WebLab-Deusto will
send this password to the client, so it can start a
connection to the Virtual Machine. At the moment of this
writing, we support Secure Shell (SSH) and VNC in
Linux VMs and VNC and Remote Desktop in Microsoft
VMs.
The importance of these Virtual Machines is that now it
is possible to develop experiments in any desktop
technology in WebLab-Deusto. If an experiment is
developed using the LabVIEW user interface, this
experiment can be run on the Virtual Machine. As long as
the Virtual Machine manages the hardware connections
correctly, the experiment will run.
Using the same approach, other experiments based on
LabVIEW Remote Panel as used in [13] or in existing
web applications could easily be adapted as “unmanaged
experiments”.
However, the communications, as shown in Figure 4,
are not handled through WebLab-Deusto. While the
randomly generated password is sent through WebLabDeusto, all the VNC/SSH/Remote Desktop connection is
managed directly. Therefore, network problems such as
firewalls blocking the ports (5900 for VNC, 22 for SSH,
3389 for Remote Desktop) will arise. It will also not be
possible to run these experiments from institutions using a
common HTTP proxy, since these connections will
probably be forbidden.
The security of these protocols can also become a
problem. While SSH and Remote Desktop protocols are
considered secure by design, VNC is not secure by
default.
Finally, the fact that these communications are
performed outside the WebLab-Deusto platform makes it
difficult to deploy a reliable user tracking system, in
comparison with the one developed in the managed
experiments, where every command and response is
stored and can be accessed by teachers, administrators and
researchers.
While this solution is worse in terms of security,
maintenance, or user tracking since it requires several
ports to be open and a direct connection with the
laboratory server that could be sniffed, the development of
experiment becomes far easier since the developer can use
any technology. Therefore, it is interesting to keep both
approaches.
From the point of view of WebLab-Deusto developers,
the use of unmanaged experiments should be avoided if
possible, given the results in terms of relying on plug-ins
and ports that can generate conflicts. However, wherever
experiment developers find it difficult or not productive to
deal with web technologies, unmanaged experiments
provide an easy solution for experiment development.
D. Features
WebLab-Deusto provides several features to the
experiment developers. Since these features are not
domain dependent, they can be reused in all types of
Remote Laboratories deployed on top of WebLab-Deusto.
First of all, WebLab-Deusto manages user
authentication. It provides different authentication
schemes to do so. The administrator of the system can
select which scheme is more appropriate for each user or
group of users. The following are the most commonly
used schemes in WebLab-Deusto, which counts with other
more complex authentication schemes:
• Database: the most simple is storing a hash of the
password in a database. Every time a user logs in,
the system will check if the hash of the provided
password is the same as the stored hash to grant
access to the student.
• LDAP: given that a Remote Laboratory is a service
provided by the university, it should be integrated
as such and perceived as such by students. Asking
students to have a particular password for the
Remote Laboratory breaks this perception.
Universities usually have an internally accessible
directory service. The most popular protocol to
access this directory service information is called
LDAP (Lightweight Directory Access Protocol).
WebLab-Deusto supports LDAP to validate the
credentials provided by the student against a given
LDAP server. Different LDAP servers can be
configured, and each student will be configured to
be validated against one or no LDAP server. With
this integration, when a local student changes his
university credentials, the next time he accesses
WebLab-Deusto he will be able to use the new
credentials.
• OpenID: in order to share experiments with
external universities, the Single Sign-On (SSO)
OpenID protocol is supported. The provider
university can create locally a set of users and
establish that they will be authenticated through the
OpenID server of the consumer university.
Universities supporting this simple scheme (such
as all the Spanish universities integrated in the
RedIRIS SIR –RedIRIS Identity Service12–) will be
able
to
become
consumer
universities.
Furthermore, the integration of this system in
certain Learning Management Systems (LMS)
becomes very simple even with a small SCORM
object given that WebLab-Deusto will rely on the
same Single Sign-On server as the Learning
Management System itself.
Secondly, WebLab-Deusto manages the experiment
authorization. This is, it will check which users have
permissions on which experiments, based on policies
applied to the particular user or to a groups of users.
12
http://www.rediris.es/sir/index.html.en
4
taught. So it would be interesting that students of the first
year use either a CPLD or a FPGA with an already
provided scheme of the simple microprocessor, while, at
the same time, higher degree students can perform more
complex lessons on the same CPLDs, and students
learning how to program a FPGA can use the available
FPGAs. WebLab-Deusto supports these types of complex
scheduling scheme, supporting even that the students of
higher degrees have a higher priority since the other
students can use a CPLD or a FPGA. It also supports
correct load balancing of experiments, so different copies
of the same rig can be provided to reduce the size of the
queues.
Figure 5: Administration panel of WebLab-Deusto showing
the use of the experiments by students
As any rig management framework, WebLab-Deusto
clearly separates the experiment management from the
experiment development, which tends to be domainspecific.
In terms of management, WebLab-Deusto is
extensively used with students. Therefore, there was the
need to create administration tools, both in CommandLine Interface (CLI) and web based (as shown in Figure
5). This administration tools are common for all the
experiments. Therefore, once the administrator is familiar
with the tools, managing more experiments is trivial since
it is handled through the same system. Among the typical
tasks that the administration tools will handle are the
management of students and groups of students,
permissions of these students, e-mail notifications to the
students of a particular group, and tracking the uses of a
given student. Regarding this user tracking, all the
messages sent to the experiment are stored in a database, it
is possible to keep a fine grained track of what the student
did.
Another common feature required by all the Remote
Laboratories is the scheduling management. In Remote
Labs, usually a single user or a single group of users
working together must be able to access the experiment at
the same time. If one student is working on a lesson in a
physical device, the rest of students should wait until this
student has finished before using the experiment.
Therefore, there must be a locking mechanism, where
each user locks a certain rig while he is using the
experiment or while the rig is preparing the experiment or
the rig is cleaning the resources. In order to handle this
problem, WebLab-Deusto provides an extensible
scheduling system, at the moment based on priority
queues.
At the moment of this writing, a rig in WebLab-Deusto
can be used by different types of experiments. For
instance, the same electronics device could be used for
different lessons for different courses. At the same time, a
given lesson can be built on top of different types of rigs.
Computer engineering students in their first courses could
learn how a simple educational microprocessor works.
Since these simple educational microprocessors do not
exist, one could build them in a programmable logic
device such as a CPLD or a FPGA. However, there are
other courses where CPLD and FPGA programming is
Figure 6 A concrete experiment running in a Desktop and in an
Android mobile phone
In terms of user interface, WebLab-Deusto user
interface has been adapted to mobile devices. While the
support of mobile devices of each particular experiment
depends on the technology used by the experiment
developer, the WebLab-Deusto provides tools to make
AJAX based applications accessible through mobile
devices. This can be appreciated in Figure 6, where the
same experiment runs with a very similar user interface in
the desktop web browser (left) and in the mobile web
browser (right), and it is detailed more in detail in [2].
Figure 7 CPLD experiment running in Facebook through
WebLab-Deusto
Finally, WebLab-Deusto has recently started being
integrated in Facebook. Given that Facebook supports
OAuth 2.0, which is a protocol to provide authorization on
resources placed in remote sites, WebLab-Deusto started
integrating it as another authentication scheme. When a
Facebook user logs in the Facebook WebLab-Deusto
application13, two options are shown: creating a new
account and using the existing credentials of WebLabDeusto. Once this step is performed, the Facebook
account is linked with the WebLab-Deusto account. From
13
http://apps.facebook.com/weblab-deusto/
5
this moment, users will see in the Facebook application
those experiments they had permissions to use in their
WebLab-Deusto account, but within the Facebook
website, being able to use the provided tools (chat, etc.),
as seen in Figure 7.
However, the most important point among all these
features is that as more services and features are integrated
in WebLab-Deusto, they are automatically provided to all
the experiments in a seamless way. For instance, as the
integration in Learning Management Systems with
WebLab-Deusto improves [14], the experiments will be
automatically integrated.
III.
EVALUATION OF AN INTEGRATION EXAMPE: VISIR
PROJECT
The VISIR project is a successful electronics Remote
Laboratory developed in the BTH, which has been
deployed in several european universities. The user
interface is composed by a Flash application and different
servers as detailed in [1]. As an evaluation of the design of
WebLab-Deusto, authors try to integrate the experiment in
this section.
In a regular VISIR session, the Flash client will send a
set of messages and process the responses through a plain
socket or an HTTP request. With help of the VISIR team,
another “protocol” was introduced, which sent these
messages through the WebLab-Deusto Flash libraries.
Once in the server side, the VISIR measurement server
receives the same requests that it receives in a regular
session, so no code modification was required there.
Therefore, with few glue code in the Flash
communications layer the system and a rig server that
proxied the requests to VISIR’s server, the integration was
running as a managed experiment within WebLab-Deusto.
Figure 8 VISIR experiment running in Facebook through
WebLab-Deusto
This way, certain students of WebLab-Deusto see
VISIR as yet another experiment in the list of experiments
they have permissions to use. Since the authentication and
authorization is handled through WebLab-Deusto, their
credentials are validated with the LDAP directory of the
university or through OpenID in case they are foreign
students. Also, teaching staff that already use WebLabDeusto will use the same administration tools as the rest
of experiments of WebLab-Deusto to handle the
permissions, and group management. Additionally,
WebLab-Deusto tracks all the uses of VISIR, as well as all
the commands sent and the responses generated by VISIR,
and teachers have access to this information.
Furthermore, as seen in Figure 8, VISIR reuses the
features provided by WebLab-Deusto, such as the
Facebook integration described in the previous section.
IV. CONCLUSIONS AND FUTURE WORK
In this paper, the basic concepts behind a rig
management framework or remote laboratory platform
were presented. The particular case of WebLab-Deusto,
attending to the supported development approaches
(called “managed experiments” and “unmanaged
experiments”) and features provided (complex
authentication schemes, scheduling schemes, mobile
devices support and facebook integration) were detailed.
Finally, it uses the integration of the VISIR project as a
showcase that can be used as an evaluation of the
proposed design.
Among the future work, the WebLab-Deusto team is
currently working in three areas described in this paper:
• More complex scheduling schemes, focusing on
the federation of experiments
• Interoperability with other Remote Labs such as
iLabs or Sahara.
• Provide proper support of LabVIEW Remote Panel
as another type of unmanaged experiment within
WebLab-Deusto.
REFERENCES
[1]
I. Gustavsson. et al. “The VISIR project--an open source software
initiative for distributed online laboratories.” Proceedings of the
REV 2007 Conference, Porto, Portugal.
[2] P. Orduña et al. “Enabling mobile access to Remote Laboratories”.
IEEE EDUCON 2011 (ISBN: 978-1-61284-641-5). Amman,
Jordan, April 2011.
[3] C. Gravier, J. Fayolle, B. Bayard, M. Ates and J. Lardon, State of
the Art About Remote Laboratories Paradigms - Foundations of
Ongoing Mutations. International Journal of Online Engineering,
Vol 4, No 1 (2008).
[4] D. Garbi-Zutin, M. Auer, C. Maier, M. Niederstatter. Lab2go – a
repository to locate educational online laboratories. Proceedings of
the IEEE Education Engineering Conference (EDUCON) 2010.
April 2010. Madrid, Spain.
[5] C. Gravier, J. Fayolle. Quality of learning: using a semantic web
approach to enhance learner control during collaborative remote
laboratories. International Journal of Innovation and Learning, vol.
6. Pp. 606-624. 2009.
[6] T. Kostulski, S. Murray. “The National Engineering Laboratory
Survey – A review of the delivery of practical laboratory
education in Australian undergraduate engineering programs”.
December 2010. Part of the outcomes of the LabShare Project:
http://www.labshare.edu.au/media/img/labshare_report_panel_we
bsite.pdf
[7] A. Mujkanovic, D. Lowe. Policy-Based Remote Laboratory MultiUser Access Management. Proceedings of the REV (Remote
Engineering and Virtual Instrumentation) 2010. Stockholm,
Sweden.
[8] J. Harward, et al. “iLabs: A scalable architecture for sharing online
laboratories”. International Conference of Engineering Education.
2004. Gainesville, Florida. October 16-21, 2004.
[9] J. Harward, et al. "The iLab Shared Architecture: A Web Services
Infrastructure to Build Communities of Internet Accessible
Laboratories," Proceedings of the IEEE , vol.96, no.6, pp.931-950,
June 2008.
[10] H. Yeung et al., “Interoperability of Remote Laboratories
Systems,” International Journal of Online Engineering (iJOE). Vol
6. Special issue REV2010.
[11] P. Orduña et al. “Designing Experiment Agnostic Remote
Laboratories”. Remote Engineering and Virtual Instrumentation.
Bridgeport, CT, USA. June 2009.
6
[12] http://code.google.com/p/weblabdeusto/
[13] R. Bragós, et al. “A Remote Laboratory to Promote the Interaction
between University and Secondary Education”. Proceedings of the
IEEE Education Engineering Conference (EDUCON) 2010. April
2010. Madrid, Spain.
[14] E. Sancristobal et al. “Service-Labs: Reusing Services and
Laboratories from Open Learning Management Systems”
ICL2009. Interactive Computer aided Learning. Villach, Austria:
September 23-25, 2009.
AUTHORS
P. Orduña is with DeustoTech – Deusto Institute of
Technology, University of Deusto, Avda Universidades
24,
48007,
Bilbao,
Spain
(e-mail:
[email protected]).
J. Irurzun is with DeustoTech – Deusto Institute of
Technology, University of Deusto, Avda. Universidades
24, 48007, Bilbao, Spain (e-mail: [email protected]).
L. Rodriguez is with the Faculty of Engineering,
University of Deusto, Avda. Universidades 24, 48007,
Bilbao, Spain (e-mail: luis.rodriguez@ opendeusto.es).
J. García-Zubia., is with the Faculty of Engineering,
Bilbao, Spain. (e-mail: [email protected]).
D. López-de-Ipiña., is with the Faculty of Engineering,
Bilbao, Spain. (e-mail: [email protected]).
7
0123456893
01512
542825
2092524042922124209
244254942652
09
58!2"
#!2"$#%!%%4!
&6&!
%$'((")!)!(*+),--*(.!)/001)*002
1)93*45)46*46)!*67*45)89:&*48)66!714)6;$64$3*
/<!=!47&!40$
>?@ABCDAEFGHIJKLMNOLPQRMLSOTQSOULOVVWHMRLNQXOLYOOJLZQSOLIJL %=77)%<#.!7<7<
}~4
MNOLSOXOPW[ZOJMLQJSL[GYPIRNIJKLWVLHOZWMOLO\[OHIZOJMRLVWHL ==!$%/!!&!7!
OSGTQMIWJQPL[GH[WROR]L^JLWHSOHLMWLHOSGTOLMNOLSG[PITIM_LWVL &!55581++
}~!!<}0~)%
`WHaLQJSLMWLIZ[HWXOLMNOLTWZZWJLHObGIHOZOJMRLMNQMLQHOL !=#!7&!!7!
}~%
RNQHOSLY_LSIVVOHOJMLHOZWMOLPQYWHQMWHIORULHOZWMOLO\[OHIZOJML !!7!"{==!!8#
ZQJQKOZOJML[PQMVWHZRLNQXOLYOOJLSOXOPW[OSULRGTNLQRLc^dL %"%/&$7848%6&1!
}-~)
IeQYRULeQYfNQHOLfQNQHQLWHLgOYeQYhFOGRMW]L^JLMNIRL[Q[OHUL %#!!=8%7%#!6&!!
ÒLSORTHIYOLNW`LMNOLSOXOPW[ZOJMLWVLO\[OHIZOJMRLIRLNQJSPOSL %&"!87{7<!=7
}
*
+
~
4
/
IJLgOYeQYhFOGRMWULRG[[WHMIJKLYWMNLZQJQKOSLiSOXOPW[OSL "!%!$=!81!%8!7!8!#
GROSLMNOLjk^RL[HWXISOSLY_LgOYeQYhFOGRMWlLQJSLGJZQJh !=#!7&!! )%!8!#%/&$
QKOSLO\[OHIZOJMRLiGRIJKLmIHMGQPLcQTNIJORLWHLeQYm^nglUL 877< &<%/</7!$$!=%
QJSLTWZ[QHIJKLYWMNLQ[[HWQTNOR]L^MLQPRWLRNW`RLMNOLHORGPMRLWVL 6&0%$!.8
}**~)%7!==!!8!
IJMOKHQMIJKLHOZWMOLO\[OHIZOJMRLGJSOHLMNIRLR_RMOZULÌMNLMNOL %!=!$
=!#!%%8!"!=#!
GROLTQROLWVLm^fôULMNOLOPOTMHWJITRLHOZWMOLPQYWHQMWH_LSOXOPh 7&!!
}
*
1
~
)
W[OSLIJLpdq]L
%8!#!6&!!%
&==!!%!8#!==
rstuvwxuBy@EHOZWMOhPQYRULQHTNIMOTMGHOULSIRMHIYGMOSL
/)%%$!//<8
%"$#%%4!
!=8!#/,<8%#)
4)z49
349
46&# $!%=74%/
%!=#!6&!!$877<=7 %%
8%"$##!==/
!<)08%8!4#!6&&7 81&
}*2~48/"$#81++
!#!7<88 "$#%8%$%<877< }*,~)%++26
$!$7#!7&!!
7!8%/<4!8&%!#! $7=!#4&&%#!
=
=
8!#!%=/
!77&%7"$#)%{7< 8!)
!=%"$#8&#$!/&<%!!=
%#!6&!!<!%77!!74! 4%#74%6&0%$!.8257
%8%#!8!77&!!)8%#!4% $&787<=$!.8=!8!&7!!=
8!!=%"$#8&8/% #!7&!!)5 $!=%$!.84%0%
!=%#!%8&8%/%%< $7=!#%&/7!$4%87<8
{#8%%!77&!!<)4 %6&0%4!=!$!=!6!
##<4!77&!!<!!=! %77&$/8&!$!#!4
$%87#$!7{#%#!6&! #/%!0#!7&!!)
!<8/!4#<&=!%/!8) 42!$4%66$!.86&<!=6&8
!/4#!6&!!%/$=% =!8!$!/%66$!7%8%#
&=)3!#$7""$#8%|404*%/& &!%/7#!"$#)
&7}*~4&!88 =7%|404%& =!!%!!=%==!%!%
$7!<2!$/%#!=% 2=
7<&%/&$7847
47!%!%$7!<#8%75 4 }*~!=$!&6
&%0%)4=84%7!&797
!%/8!##!7<)$$!8% 6&!!<3!
#963 87<8!
%/=!8!#<!$7!<"$#}1~ $!#!%/!7!$#
%!=#!7&!!
/#%##!&7},~)
4# !=$$!/84%%&#
1+**'4#$!/6&!!<698!#
$!/}2~4$$!#7%#!6&)4 1,963
!(
%74==$$!8%%/&=!/7 %$'((7&)#7)&%(6)&0)/($8!
.8
!$#!6&!!#%#/7&7 2%%$$''(((()
&%%)!8=!)(
%!{$7%&&! !7 0%$'((7)
7&%))(
%
$
'
(
(
)
7
7$!.8)!(
*

%$'((!$7&)&%)(
%$'(()!77&)!(
1
874!=0344803487!;$!7467

¡¡
0123456893
01512
542825
2092524042922124209
244254942652
09
!""#$%"$&$%&&'&(
!#!''""#$%#6'#&$!
#!&)')*
9$%&$'&%!$%"$&
6'#$'&$&+"''+"&%'"$,$"$&
'#$'&$-)'&%$"'%$!$&"''+
"&$%&$""$."&$%&"$&'#$'&$
*
2(-"$&6'#$'&$-''&$%."&&'&
'#!'"$+$&'#$'&$*8$&'
"$&"$&6'#$'&$.$",!$%!
+/$""$&6'#.''!'$&!&
#$$,'&'"$"&&$&0)"&$&
"$&6'#'!&&$+'.$%*
5 &&'&$1'&+&'&&$'"&$#2
'!'&$3'&$1'&+&)"$$%&
''&0)"&'2'$&'0'"
)$%."&$""$&$!%%&'#$'&$
&!$$&"'&&%&0)"&'&$
0)"&$'0)"&$%)-&$'!'&
&'&$'!'&$3'&$*
5&'!'$"$&6'#$'&$-'#!'&
%'&%$"'&%$&'&)%!$"'&$&
+'+"''+"&%'"$,*4404'0'")
$%&/&'!$"')%&$0)"&
#&&'!'&&'&$'&$3'&$!+
&',+&-$"" '&$&*)$#"
$%&'))$'&'&&.&0)"&!($)
&$,)'!"'&''&'-$%$%&'*
5$))$!&$&'))$''0)"&$!#
")"&!+&&$$)$(!!#-'+"''+
"&%'"$,*&&'))$''&+"''+
"&%'"$,)#($&0)"&
'&$"'&'-))$&%'&!($)!#-&
)'&'%'"$,*8$&'%!($)$%&+
"''+"&%'"$,!($)''&&'&$
"'9)4&0)"&#'#
&$+9)4*&$&+'+"''+"&%'"
$,&0)"&!($)$!!&$")
"&&))$&%$&)'&'0)"&*
)')0)$&&'$(&$%&
#6'#&$+"''+"&%'"$,&&
($15*672'(''#%$'-0)"&!($)!
&&#6'#&$'&&879:*
44*;2426912982124204265
2
09
<=>?@ABCDEFAGC@HI
#6'#&$'9)0$76"$&'#$'
&$-)'&%$"87J:$+"''+"&%'"$,!(
$)!&
(&-$%&$*4&'#!&
&!&')'&$%&$8#'-K66L
&$+!%%&($$%&-&"*4&"''++
$&$)$%0)"&#*
!($)"&$%0)"&'&-#!
($)!+&$!%%&'))$'/
M;''+!0)"&
M;
"''+!0)"&
&&)/NN*#'#*!&$*N
&&)/NN$!*+$$+*$"N)N#'#!&$N
I
76
ij
O=>PQ@QRSDHSTUSBGVS@AWH
5"$&6'#$'&$- '-$")$!#-&$
$")$&/
M;3&/&'##$$&&!&X
!,&$)*5'&&'&&&
$*%$&&"''+'&&'
&$&&&!&&''&+&'&$$%&
&$"'+&'&#&&$&(*20
'")$%&$!#Y'('5))&5!$#
8''))'&$$&6$!&'&#
$&##$*4&$"&"%!
'Z+&[*
M;0(/&'&&'!&$&'!'&'&#
!#-&&!&$'&!&(&-*
'!'"+&#'&$#$'!'$#$&
'"$'-!(&'&'$!*(
$!(.&%$"&&'!
$&$&&'&$&&'!''($!+
'"%.&%)$#*4&'#!($)!
'-&-)'&$$+-'Y'('*21-&$
3\\&*4&$"&"%!'Z+([
&&'&*
#6'#&$"#'&'&('
&&'&&'Z"''+!0)"&[*4&)$(!
#'#$&&&!'!&(!&$'
!$"" '&$'!&'$)$(!$%&'$")$
&&'&#&"!!#&&'!(*
'-&&'&''&$3!&'$&
)%$".&&$&+(&$%&'$"
)$&)'!&"!!,&'&&&
$'"&$#*#6'#&$('
)'&$%&$%&'$")$&&'&'&"!!
,)'&',$%'&$""'!&'!(!
%$"&0)"&*8&"$&'&'$"
" '&$#&&'!(')%$"!
&$+&$%&'$")$&#6'#&$)$
(!'00$,&6'-&$'($!&0)"&
$!&$'!-)&$*(&'&'&$"
" '&$'!&%$('&-'!&',+
')&''!!#-&)'&%$"&%&&-)$%
0)"&'!Z"''+![&-'%-"'
'+!#-#6'#&$*
5'0'")$%"''+!0)"&8+7'
8150)"&+#6'#&$'#')
)'&!*9&!&'($++!&-&"
&!0)"&&-'&&$1815&
'2'&!'.1%&$&&!&+
&'(''#+2'!&'%&'&#)$+'""!
&815&-&)'&$$&$&!(*
0('#&&$'!&''(''#'!&!&
&&$%&'&$&!(&
#'"$&&&!)'-*
4$!&$!($)&"''+!0)"&')'$%
&'!($%&'$")$&" &#!($)!*
$!($)&&$")$&#6'#&$)$
(!#'%$Y'('0)&5!$#8''!Y'('5)
)&*&&#'&&$-!&$)%$"
$"'&$'$""$514&$!'!($"
"'!'!%&$&(*4&'$%&815
0)"&&$&#&&$&'!&
#'"&#)'+*4&'$!%&'&'
&)!'$""'!#&&$+&
)$(!!514$&'+'&+']^_`aH
bc?^deHfHgah*
kllmnoopppqrstuvquwx
0123456893
01512
542825
2092524042922124209
244254942652
09
!""#$"%&$'(%
&)*&6$&)%%&$%+3#3,,#
-$$#*2#1'"6$&.42*%!""(%
$$+!$(%&$$%!$
!!$"+%%"*%/$"
!!$"$"0"$$"#(%
(%&$0$%"%"%"*4"$+
815#(%123456789:3;<7=7>6?$"
(%$"$%$%0%$%0"$"815$$"
%")#$"%815(%$%"0!%"0%"@
0!"%$'$)"(%)0(&
$!*
%%&$'%"%"%(%!$"$0
"%!!$"&6$&)#(%
(%$0$%/%!""'$
$1%$"$%$$)$!%%")
%*5%%$"$"+/%!"
*%%!$'!$%$$&%0$
"'#%$&"!$)$"%%1(#$("%"
8%0)A#$)0%"""+%0)$%")*
+#)+!$"$0/%!"$
$+$%%$!"+)/%!"
$$")(+(&$%$%"#%"$'
(%)B)%%"0$"')0%"$")&%"0$&&
)"+!!&%%*8)!#%"
&6$&)!$"$0$!!)"%$%")0
$"$1C1#"%)(%$%0$%"0
1/%%"%)%"$+%($*
;DE4FGHFHIJK7JLMJNOGJFPQ7
%!$"$0/%!"$$+$%%$
!"+/%!"#/%!"%
"*+#"0%"($
/%"!$%"+/%!"&)"%"(&
!"(%+%"%%++%)/%
!"*
4"$1%&!#&6$&)$
)%"0R)"!$"$0/%!"S*%%"&6$&
)#)"!$"$0/%!"$(!!)
"%$%"$"$"%'&'$+!*%
$)"%$%"#$)%T$%"#)%"0#$&$$"
%"0$"&$%)$1%"0%%$"&'$+!#
%"(%"$&'%("#(%)'
%"0"&6$&)%&$%*
5$"/$!#8%0)U($.%)$$%"
V.W)""%"0$6$&.42/%!"*"$)
B)$"/%!"#&6$&)(%$$.%)$
$%"$"(%0$")$ %.%)$$
%"*%$ (%&+!)0.3#00
!1#)%"0$%+%%"$"$
(%%"(&$%$%"*
4"%#&6$&)$$.)%"0
.%)$/XX#$%"0+!$$%)$"$)
$)%!+("*"#&6$&)
0"$$$"!$($"(%"+%0)%%"
.*8!%!!"#.$$(%"0""
%"(%$$(*&6$&)(%"%
$(%"#%$"$$""%"
.%)$$%"*5!!"+%(%%"0#()
0)0V00W$".3%"6%")/.$"
.3$"!1%"%+.*
YCC(((*%)$&/*0C
XX
[\]^_`_abcdef_gh_ijfk[lc_mnndf_o_pq^aorssph_]ktbufv_orss
8%0)XY815/%!")""%"0%"&6$&)
8%0)AY6$"'$&'$+!$%%"$'"(1
$"'(""%"0$+%#!$)%""VZ$/%W$"%"")!
&+")")"V$/%W
8%0)UY.%)$$%"!$"$0&'&6$&)#(%"0$
)!!'6$&.42/%!"
wx
0123456893
01512
542825
2092524042922124209
244254942652
09
!"#$%""&
"""'%()%*"+(",
%-+'6'$".4!*"()%(
$"-6'#42$"!/"*'
$#$%.5"%-"#$%
-"(&"%+/
*&%%$.
"-"/*"'"(
6'#421%'-((""&
8-$0("$%+*%.5%"
'()%('&'6'$"(6'#42/
"%(".)$"""""*$.
5-/"($%-/$/$1/($"
,-(%('+'6'$"$%%+/"
*()%%+(",&6'#42.
&)/$"/""&8-$2/
(%($-'6'$".%
(%+-(""&(#""6'#42
""$-'6'$""$%+/%%
#33003",31%"
-((%+.!/&,'%""$"
!&%%"'%,-"40566!#3/77!00/
8895!",:&%%".4&%%%"'
""'%$"*"!"$"$"-
1*+/"" "&%%
''%+'!'((.
"$+!"%"%"''
%.%00(",%"
"(("$'+("-/#3""$'+(!$%.
8%%+/!"$"
!($"('6'$"%!,"
(!!$%(%+%'%$",-"+"/
"&()%(-(*
"/&)+((""""((
' ""('+"/(""("
".
%""%$"&""!"$+/
/$",-";$"")%"
'((&%'+")
$%('"!!(/()%!*'
"!""()%$"+%
-+.!/""-,'".
8!)&!'6'$"()%"/
$"!$-(*""$%(')((!
""'%/-)"$%""!%+-%$-"
("-!%".&)/&)
*()%"!((!!$%($)
(%&&'%-"/$-(*"
)("+"%$!*()%.
<=>?@ABCD@EF
'6'$")("")%!$"*
()%".0"!$"(
((/+'$"(%%+"!
6'"(%+(!'6'$".
8"!%%/'6'$"-"$"$
.4)("(!!$""(".
("!"+""%&"
"!$"-$!$"".
!%%&-"%+$"(""
'6'$"/&$"&%*$
""G
JK
8-$2G-(($-(*"
'6'$"%!
8-$0G6'#421%$-'6'$"
HI'"G""%""-"!
""&(('".2)+$"%-"/
"+"&%%,!"!)((""
&(""""("- ""
"$(.
HI651G-)6'+"")
)(('+$)"+/"$%('-("
"$()(""$'+"$(".5",-"$
(")$%""&(!
6'+',"".
)""$"$
%%+)%%+ ""'%(+").
"$%% """(+
")!"%%(65146-&-
+5 ""1%:.'6'$""$"
651)%((%")(('+
"$(-"-)651").!!
651")"'!-$(/("$(
&%%'!-$(')%((-"
LMMNOPPQQQRSTUVWRVXY
0123456893
01512
542825
2092524042922124209
244254942652
09
651!"#$!%$
&'%&(%'$")
*%%+6+&!#$$++$!
&#%'$
,-9.4/!'!).*#)$
&"0$09000919.4.!
!%!$&..!'.!'&(%%
$!%$$(!2&'+$(#$$+
&%'!&9.4!2%!
&*&(
&..!*.$
%*0&%$$0.&
4'5'440043'4404'(0
% 31#$$++$!+%!*%!&*&
8&*!"!!2(*
%6 *0(*0601+
%!*(*.$#* $$039!+6%
+6+&!#$$$(!*
0$096 *
0(*$2
0%!'$("+6+&!* ).*&
!7!"#$$%%8#%&.*
!!#%).*"+'!.!$%..$'!
.%&$&!!!&.!2&
5(* *2*#!8"+6+&!
%$$(.).** *2!*
).*'$!.*"#%'!+'!* .%2%
4*!2* *"+6+&!)
$(&'#&'2!"# '!
%'*!!!$"+!3!** '64
2%03641'#++'0!#8&91
'*!!!$%!**!2!$$).*
2!"!%'*!2*$#
!!$"* *!).*$%
'$'!&*(*5*!(.%$8
'*!!!$#$$'$* *!2&''!&.!2&'".*!!2
&'"* $!2%!!&'!2
.%&$!&."'%8&!2&'
'&%8"$$*!
).*!''+".!+$!8.
2'%8!2#&'''
5!%!**!2&:&'+($$*!
6+!!%'&$* *4*!
6+"&&$$($&!$!&.!2&
#!8!*&++$!%%).*
**42!&'#!8!$!
.(%$'%"!2&'!&$'# &$
&'2'+2!&).*
2!"*&+$!%8*%*"#%&
$!%8%#$&).*!
#$..).*!
%$!&%4!'!'$.!+$*"
+6+&!.!')+$%'&$(
*"*!*+'!.!(:&&
5*!*!2#"+6+&!
%+&'+('22(.!2).*8!
%"*$%!%'%%!&$'+&'2!'2
2$!2!'22%!&5**"
$!%++&$!!.!2'22(.!2
3!*.&&'2%!&%!&$'
$!#*.$'&%!$*%!.!%!#!8
45
./;;###';;')*$
0%*.$'&%!$*%!.!%!'!!
)"!%!&$'+&$'*.!** +$$!%'
%&%316!815!#"!
%!&#316'815.!**&
0!#!&$'+&'!22(&
<=>?<@316!815#$'(.!''
%*!2*.$*%!.!%!"#$"*
*"'&'%.2!**!%!*.$)
$!!*316"'&'$!#!
.!*815%&$+$815+6+
&!&..!(.!2%!*.$)%'&$
%*"&..!&'!2'
.!(%!&'%
&316!8154$!&..!%!%$!'+$
%!2).*"!'22%!.!2*
%+.!''!'&%7!2:&&
4*!2&2%"+6+&!&
2%+'.'!*!+$'%$&.
.!!2*!+$'%!2%.%&$).*'
.'!%!$!(&'+().*'$
!."+6+&!.!'!!$!* 85A5
+' ..$%! %%+$!&*!+$'%
%+..%'8&B"#*)
.*&#(*$&2%
'8!.#++!#0$21'*!+$#++!#
01"''$'*!'$CDE
8&9/5'*!.$!2+6+&!!#&!2
).*+(&'
8&B5%!%).*&8!.'5'!'
*!+$.!F
GHIJKLKMNOPQRKSTKUVRWGXOKYZZPRK[K\]JM[^__\TKIWǸaRbK[^__
cS
0123456893
01512
542825
2092524042922124209
244254942652
09
86!"#$#%&
&#%8$!!'()"8$!!'**!#
95"+(,-"$"*#!!$!!*#!)%"!#.!!
#!#$*$%#/!6!#%
&#&!"#"$!$"/("
8$!!'01#!&"8$!!'6!*
*$! -!!*!#"!-2$#&-$$!
%&"3&$#%!46!(
9$"**#4!#/%"8$!!'$$!
'%-""6!$$!(8#!/"/!
/#-"8$!!'**$!"!
3*#/""%*#/!!"#6
!$$!-""8$!!'-&
!"*#!)%%!!5$"$(68&#
7(
!-)#"/!/*!#*!/!&"4
#"/!##)$%4##&#%
6!"#!/$*#!)%%!
"3*#//-(8!#$"
&#!6#&&/0/-"
6!/*#!)8079"3*#/-
!/$&#%(
444(:2;56
5499854254925122;404
19<23
";404*#!=$$$4$#!$/!
6!#!#%)!*%"-"$""%
*!%)##!*)#("##4$
$!/*!%8"**$!%%44##)#
%%809(5)!!4"%&!4
6!"!##!&#"3*#/
"$!(
4#&#;404!"8"$-%
!4/&%*#!$"#*!"#!&"*
!$'!#1#>(""*!4";404/
!"#?*#!!$!@-#!%$%-"$""/
&"#!&""6!8"##(9$
"#)#%";404/#/#)##$)
"/#>"#$)#&#!!
!$!%/!%4$!-#>#%"#("#4!#-"
4-&$!%"8"$!//$!#"
/%#&#)#"*#!3%"#>!;404A
#)#"&#!-#&/&%3*#
/-"6!(
"-%!46!;404
!"#3*#/"!43*#/"")
*#/!!(0$""$!%"!#.
!"%%"#!&"6!"#$#%
#)%%-""651%#$!#!4")#!#
"#!&"9*4$"#4!#&%(5!
$"&44"#%6!-
"/%/#!!!"#!43*#/!4
6!!"%"*#/!%&#!*
/&/(5%%!6!#$'"
!4;404-"$!//%%"
#*!&#%;404%$"#")$$
!"4!#/!(
8#"#/!#8&#B;404#"4
#*#!)%%6!$""8$!!'
&#!%$#%"*#)!$!(
"*2CC**(4$!!'($!/C-%!C
01
OP
8&#73163*#/#&8$!!'"#!&"6
!
8&#B;4043*#/#&8$!!'"#!&"6
!
4;(:3936
049058
29D
4"**#"$$!$*"%#&/&
/4#/-!#'!##/!!#!#*4!#/-#*#
%("*#$#$!46!%&
!"**!#%%)!*/**#!$"5$%?/
&%3*#/@%?/&%3*#/@6%
4#*#!)%%5$!/*3"$!$"/
$"%&$"//!%)$**!#%4$!!'
&#!6-#%%(
8"&#!!4";404*#!=$
"!-$"$%)!!4"*#!
*!%%&(
5/!&"4#-!#'"6!/
$##-!#'&"##%$#%"**#2
E:!#$!/*3$"%&$"/4!$&!"
4%#!!43*#/
E:4#!*#-"!"#/!6$"
6!#0"#(
2822320
809:4()!((?";404*#!=$!*!#$!4-#
)4!#%#%!!#!#(@1#!$%&!4"
2;+,,F3!4#$1!#!1!#&(
8+9:<(#$GH(?24&#*4!#/4!#"%*!
/!4/!6!#!#4!#/$#!$!#!#@(4222
2
39+,0,5402BF70I+IIJKF,K6(+,0,(
819:L(6M9('#!)M(6&/(?0/#64!##/!
3*#/!$!//$!$"!!&@(1#!$%&!4
"2;+,003!4#$#!)!/(
8I9:1(9#%N(?2&/!$$!/!6!#!#@(
42222
39+,005402BF70J0+7IJI0K6(5//<!#
%5*#+,00(
QRRSTUUVVVWXYZ[\W[]^
0123456893
01512
542825
2092524042922124209
244254942652
09
!"#$19%!&$6'()*%)4(#&$5+,)-5%%)--
#./00123)44(2#.25))-#/.01)402)6"-4222.-
2#0.-0.4.%!-2#+2+)20.#-4006789:77;<946
=7==7>?42877>878<@<:A0+!4)<$4--!)=8$)877>
1/)B-C6;99;9<9
< !"$6'()*%)4(#&$19%!&03%-3
.0.#+00123)55#2)2!)10!+2#),#))"6"-4239
877$@=-25..!+30.1)).)0125)42224.%!-2#+2+)20.#-
00#)2D$40679:7@>8@$((8=;<8==$0,)4")877
90.#/$035).$95+ED+.)DF52051455#2)2!)10
)402)6"-G10))%#./-0125)2A87==30.1)).)$-0,$
04.#
:3,#)$8D0++)$D%$52)-.%6%0.$022)01
25)525"0!2)402)6"020#)-1%#/4-80!.%2#0.-01
9./0#./!22#0.-4.2).2#0.+0!.+019.+#.)2./#.))#./$
A0+;$0=B877:C
>"#!2#.$5!)$3#)$#)%)-222)6"8/0H
)(0-#20D20+02))%!2#0.+0.+#.)+"020#)-10))%#./-01
25)42222%!2#0.2./#.))#./30.1)).)B2
39C87=7
5(#+87=7%#%$0(#.
=73,#)$8D0++)I!+#2D01+).#./6!-#./-)4.2#3)"
((0520).5.)+).)0.20+%!#./0++"02#,))402)
+"020#)-4.2).2#0.+0!.+014..0,2#0..%6).#./$,0+
<1(<7<<8;877>522(6??%J%0#0/?=7=7;?446877>78<<;9
==E0-2!+-K#$0!DF5)2#0.+2./#.))#./6"020D
0!,)DH5),#)30125)%)+#,)D01(2#++"020D)%!
2#0.#.5!-2+#.!.%)/%!2))./#.))#./(0/4-G))4
")87=7120125)0!204)-0125)6"05)10L)26
522(6??333+"-5))%!!?4)%#?#4/?+"-5)M)(02M(.)+M3)
"-#2)(%1
=85!LK.0,#$603)10+#D-)%)402)6"020D!+2#
-)5)--./)4).210))%#./-0125)2AB)402)2.
/#.))#./.%A#2!+4.-2!4).22#0.C87=7020K50+4$03)%).
=@3%$)2+F#6"-65-+"+)5#2)2!)10-5#./0.+#.)
+"020#)-G4.2).2#0.+30.1)).)012./#.))#./2%!2#0.
877;#.)-,#++)$8+0#%920")=<8=$877;
=;3%$)2+N5)#6"05)%55#2)2!)65)"0),#)-
4.1-2!2!)20!#+%3044!.#2#)-014.2).)25)--#"+)6"0
20#)-$N10))%#./-0125)4222$,0+><$.0<$((>@=>7$!.)
877:522(6??%J%0#0/?=7==7>?193877:>8=<79
=O)!./)2+$F4.2)0()"#+#2D01)402)6"020#)-0D-
2)4-$G4.2).2#0.+0!.+019.+#.)2./#.))#./B#92CA0+<
0()#+#--!)2A87=7
=<19%!&)2+F)-#/.#./2J()#4).25/.0-2#)402)6"0
20#)-G)402)2./#.))#./.%A#2!+4.-2!4).22#0.#%/)
(02$3$
05!.)877>
=9522(6??0%)/00/+)04?(?3)"+"%)!-20?
=:20.#-20"+)2+F0),#)6"-6)!-#./0),#)-.%6"0
20#)-1049().6).#././)4).20D-2)4-G436877>4.
2)2#,)304(!2)#%)%6).#./A#++5$5!-2#60)(2)4")
8@8$877>
5
90
PQRSTUVWXYZQ#-3#25)!-20)5H)!-204.-2#2!2)
01)5.0+0/D$
.#,)-#2D01)!-20$5,%
.#,)-#%%)-
8;$;:779$#+"0$0(#.B("+00%!.[%)!-20)-C
\Q]^_U`WYWaYb#-3#25)!-20)5H)!-204.-2#2!2)
01)5.0+0/D$
.#,)-#2D01)!-20$5,%
.#,)-#
%%)-8;$;:779$#+"0$0(#.BL#!*!.[%)!-20)-C
cY]dUeTXW]fY_a#-3#2525)8!+2D012./#.))#./$
.#,)-#2D01)!-20$5,%
.#,)-#%%)-8;$;:779$
#+"0$0(#.B+!#-0%#/!)*[0().%)!-20)-C
\Qg]_WUhQWijQklYR]Q$#-3#2525)8!+2D012./#.))
#./$
.#,)-#2D01)!-20$5,%
.#,)-#%%)-8;$
;:779$#+"0$0(#.B*!"#[%)!-20)-C
mQRW]i]TUhQaaTSQ$#-3#2525)8!+2D012./#.))#./$
.#,)-#2D01)!-20$5,%
.#,)-#%%)-8;$;:779$
#+"0$0(#.1"##0/**0+[/4#+04C
noUcpq_akX_k`q]ZQ$#-3#2525)8!+2D012./#.))#./$
.#,)-#2D01)!-20$5,%
.#,)-#%%)-8;$;:779$
#+"0$0(#.%#(#.[%)!-20)-C
5#-2#+)#-.)J2).%)%,)-#0.01(()()-).2)%225)4.2).
2#0.+30.1)).)0.)402)2./#.))#./rA#2!+4.-2!4).22#0.
B2A87==C$5)+%2.-D+,.#
.#,)-#2D$-0,$04.#$!.)8:
!+D=$87==))#,)%@=!+D87==1!"+#-5)%-)-!"4#22)%"D25)
!250-8:0)(2)4")87==
stuvwxwyz{|}~ww~s{w|~wwvywuz~w

Ingeniero en Informática Ingeniero en

Transcripción

Documentos relacionados

Física para pasarlo bien

Remote Mouse - Joe Fernandez

Integración de un microbot en Second Life bajo