Ingeniero en Informática Ingeniero en Organización Industrial ...

210
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

Transcript of Ingeniero en Informática Ingeniero en Organización Industrial ...

Ingeniero en InformáticaIngeniero en Organización IndustrialInformatikako IngeniariaIndustri Antolaketako Ingeniaria

Proyecto fin de carreraKarrera amaierako proiektua

Diseño e implementación de la plataformaBoole-WebLab-Deusto para el prototipadorápido de sistemas digitales mediante el uso delaboratorios 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 usandolaboratorios 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 EnhancedLearning, tiene dos grandes objetivos:

El primero es integrar el software educativo de diseño electrónico Boole-Deusto con lainfraestructura de laboratorios remotos WebLab-Deusto, de tal modo que sea posible -enminutos- diseñar un sistema digital e inmediatamente probarlo remotamente en un siste-ma 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 te-ner que configurarlo, evita tener que disponer de un sistema de prototipos y evita tenerque gestionar el proceso de grabación. Todo este proceso es transparente tanto para elprofesor como para el alumno.

El segundo, donde radica gran parte de la naturaleza innovadora del proyecto, es dotar aWebLab-Deusto de una infraestructura de realidad aumentada, que superponga modelosvirtuales sobre experimentos electrónicos con dispositivos hardware reales. Utilizandovisión artificial para interpretar las salidas, los modelos virtuales interactuarán en ambossentidos con el hardware. Esta capacidad permite la creación de experimentos prácticos(conmodelos virtuales de sistemas reales), económico (una sola placa controladora físicapermite muchos experimentos distintos) y al mismo tiempo realistas (el foco sigue siendoun dispositivo físico absolutamente real).

El sistema en estemomento es ya totalmente funcional y se han publicado varios artículosrelacionados en revistas y conferencias científicas.

Descriptores

experimentación remota, technology enhanced learning, electrónica digital, realidad au-mentada, laboratorio remoto

iii

Índice general

1 Introducción 1

1.1 Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Contexto 5

2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Tecnologías y estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Technology Enhanced Learning . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Laboratorios remotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Realidad aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.4 Visión artificial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Software y entornos de partida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1 Boole-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Weblab-Deusto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Objetivos del proyecto 19

3.1 Descripción del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.1 Integración Boole-Weblab-Deusto . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Modelos virtuales en experimentos electrónicos reales . . . . . . . . . . . . . 21

3.2 Visión general del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.1 Diseño y generación de código (Boole-Deusto) . . . . . . . . . . . . . . . . . 253.2.2 Sintetización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3 Modelización Virtual y Realidad Mixta . . . . . . . . . . . . . . . . . . . . . 27

3.3 Productos finales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 Principales requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 293.4.2 Principales requisitos no funcionales. . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Método de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.6 Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6.1 Fase 1: Diseño preliminar del sistema . . . . . . . . . . . . . . . . . . . . . . 323.6.2 Fase 2: Mejoras y ampliaciones de Boole-Deusto . . . . . . . . . . . . . . . . 323.6.3 Fase 3: Implementación de conectividad Boole-Deusto – Weblab-Deusto . . . . 333.6.4 Fase 4: Implementación de experimentos electrónicos mediante realidad aumen-

tada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.5 Fase 5: Pruebas, usabilidad e integración . . . . . . . . . . . . . . . . . . . . 353.6.6 Fase 6: Implantación en producción . . . . . . . . . . . . . . . . . . . . . . . 36

v

3.7 Tareas principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.8 Estimación de tiempos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.9 Programación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Tecnologías 45

4.1 Boole-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.2 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1.3 Sistemas combinacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.4 Sistemas secuenciales (autómatas) . . . . . . . . . . . . . . . . . . . . . . . . 514.1.5 Caracteristicas técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2 Weblab-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2.2 Características generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.3 Facilidades aportadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.4 Características técnicas hardware . . . . . . . . . . . . . . . . . . . . . . . . 574.2.5 Características técnicas software . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3 Tecnologías hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.1 VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.2 BITSTREAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.3 UCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3.4 Xilinx ISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3.5 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Tecnologías software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4.1 Borland C++ Builder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4.2 VCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4.3 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4.5 GWT (Google Web Toolkit) . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.6 AJAX (Asynchronous JavaScript and XML) . . . . . . . . . . . . . . . . . . 654.4.7 jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4.8 HTML5 Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.9 WebGL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.4.10 ThreeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4.11 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4.12 Sphinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Desarrollo 71

5.1 Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.1.1 Eclipse for Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.1.2 PyDev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.1.3 Microsoft Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.4 Notepad++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.1.5 Vim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.1.6 Git y TortoiseGit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

vi

5.1.7 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.1.8 Blender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2 Detalles del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2.1 Boole-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2.2 WebLab-Deusto: Sintetización de VHDL . . . . . . . . . . . . . . . . . . . . 815.2.3 WebLab-Deusto: Infraestructura de creación de servidores de experimentos en

JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2.4 WebLab-Deusto: Infraestructura de creación de clientes de experimentos en Ja-

vaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.5 WebLab-Deusto: Infraestructura de modelos virtuales en JavaScript y ThreeJS . 885.2.6 WebLab-Deusto: Modelo virtual de tanque de agua para WebLab-Deusto-FPGA 915.2.7 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6 Problemas e incidencias 95

6.1 Antigüedad del entorno de desarrollo original de Boole-Deusto . . . . . . . . . . . . . 956.1.1 Necesidad de un entorno virtual . . . . . . . . . . . . . . . . . . . . . . . . . 956.1.2 Capacidades del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.1.3 Interfaz anticuada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.2 Soporte de WebGL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7 Manuales 99

7.1 Guía de usuario de Boole-Weblab-Deusto . . . . . . . . . . . . . . . . . . . . . . . . 997.1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.1.2 Circuitos Combinacionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.1.3 Creando y probando un sistema combinacional . . . . . . . . . . . . . . . . . 1027.1.4 Autómatas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7.2 Guía del experimento FPGA Watertank . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2.2 Funcionamiento de un modelo virtual . . . . . . . . . . . . . . . . . . . . . . 1127.2.3 Tanque de agua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137.2.4 Otros detalles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.2.5 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.3 Guía de desarrollo de Boole-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167.3.1 Entorno de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167.3.2 Sistema de lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.4 Guía de desarrollo de clientes de experimentos en JavaScript . . . . . . . . . . . . . . 1197.4.1 Qué desarrollar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197.4.2 API JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

8 Conclusiones y trabajo futuro 125

8.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.2 Comparación con objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278.3 Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

vii

9 Posible plan de negocio 131

9.1 Resumen ejecutivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1319.2 Descripción general de la compañía . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

9.2.1 Misión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329.2.2 Visión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329.2.3 Metas y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

9.3 Filosofía del negocio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1349.4 Productos y servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359.5 Plan de marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

9.5.1 Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379.5.2 Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389.5.3 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1399.5.4 Nicho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419.5.5 Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

9.6 Plan operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439.6.1 Producción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439.6.2 Ubicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439.6.3 Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449.6.4 Inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449.6.5 Proveedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449.6.6 Política de créditos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Bibliografía 147

A Acrónimos 151

B Glosario 153

C Agradecimientos 157

D Publicaciones 159

D.1 Publicaciones incluidas en los anexos . . . . . . . . . . . . . . . . . . . . . . . . . . 159D.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 Laboratorio remoto de propósito específico [31] . . . . . . . . . . . . . 72.2 Sistema de gestión de laboratorios remotos (RLMS) [31] . . . . . . . . 82.3 Realidad aumentada. Muebles virtuales en una habitación real. [43]. 102.4 Google Glasses: Gafas para la realidad aumentada . . . . . . . . . . . 112.5 Realidadmixta: Personas reales y virtuales juntas, en un entorno real.

[12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Coche sin conductor de Google. Parcialmente basado en visión arti-

ficial. [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 Una de las pantallas principales de Boole-Deusto (diseño de sistemas

combinacionales) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.8 Experimento FPGA estándar, en WebLab-Deusto, ejecutando una ló-

gica ya grabada provista por un usuario. . . . . . . . . . . . . . . . . . 14

3.1 Flujo de trabajo Boole-WebLab-Deusto . . . . . . . . . . . . . . . . . . 203.2 Placa FPGA con 4 de los 8 LEDs que actúan como salida, encendidos . 213.3 Visión general del sistema de modelos virtuales (realidad mixta) . . . 223.4 Elementos principales del sistema desde el punto de vista del usuario 243.5 Diagrama conceptual básico del proceso de sintetización en los ser-

vidores de WebLab-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . 263.6 Tanque de agua virtual: Ejemplo de un posible modelo (sólo el mo-

delo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.7 Fases planificadas para el proyecto. . . . . . . . . . . . . . . . . . . . . 323.8 Trabajo estimado para cada tarea . . . . . . . . . . . . . . . . . . . . . 413.9 Horas de trabajo previstas para cada grupo de tareas (fases) . . . . . 423.10 Diagrama de Gantt aproximado del proyecto . . . . . . . . . . . . . . 43

4.1 Estadisticas de descarga de Boole-Deusto . . . . . . . . . . . . . . . . . 464.2 Clasificación de los circuitos digitales . . . . . . . . . . . . . . . . . . . 464.3 Boole-Deusto. Pantalla de diseño de sistemas combinacionales . . . . 474.4 Proceso para el diseño de sistemas combinacionales . . . . . . . . . . 484.5 Boole-Deusto. Diagrama de Karnaugh. . . . . . . . . . . . . . . . . . . 494.6 Boole-Deusto: Diagrama de circuito NAND generado . . . . . . . . . . 494.7 Boole-Deusto: Diagrama de circuito AND/OR generado . . . . . . . . 504.8 Boole-Deusto. Pantalla de diseño de autómatas . . . . . . . . . . . . . 514.9 Boole-Deusto. Circuito generado para un autómata . . . . . . . . . . 52

ix

4.10 Ubicación física de algunos de los experimentos de WebLab, conte-nidos en cajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.11 WebLab-Deusto. Pantalla de selección de experimentos de un usua-rio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.12 Arquitectura de los servidores de WebLab [44]. . . . . . . . . . . . . . 554.13 Diagrama de la federación en WebLab-Deusto [11] . . . . . . . . . . . 564.14 WebLab-Deusto, integrado en Facebook [11] . . . . . . . . . . . . . . . 574.15 Caja para FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.16 Logotipo de Xilinx Inc. [23] . . . . . . . . . . . . . . . . . . . . . . . . . 604.17 Dispositivo FPGA de Xilinx [23] . . . . . . . . . . . . . . . . . . . . . . . 604.18 Logotipo de Python [38] . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.19 Logotipo de GWT (Google Web Toolkit) [18] . . . . . . . . . . . . . . . 634.20 GWT Designer (Editor WYSIWYG para GWT) [18] . . . . . . . . . . . . 644.21 Logotipo de jQuery [24] . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.22 Logotipo de HTML5 [45] . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.23 Ejemplo de aplicación WebGL, ejecutándose en Chrome [4] . . . . . . 684.24 Logotipo de node.js[30] . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.1 Logotipo de PyDev [37] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.2 Logotipo de Visual Studio 2012 . . . . . . . . . . . . . . . . . . . . . . . 725.3 Microsoft Visual Studio 2012. . . . . . . . . . . . . . . . . . . . . . . . . 735.4 Github. Repositorio del proyecto WebLab . . . . . . . . . . . . . . . . 755.5 Vista principal de Blender, con el depósito de agua desarrollado du-

rante este proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.6 Entorno Windows XP virtual utilizado para la modificación y exten-

sión de Boole-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.7 Experimento FPGA-Watertank . . . . . . . . . . . . . . . . . . . . . . . 92

7.1 Pantalla principal de diseño de Sistemas Combinacionales . . . . . . . 1007.2 Botón para abrir Weblab-FPGA en el navegador por defecto . . . . . 1017.3 Control de activación del modo WebLab . . . . . . . . . . . . . . . . . 1027.4 Asignación de entradas y salidas compatibles con WebLab . . . . . . 1037.5 Especificación de las tablas de verdad de un sistema combinacional . 1037.6 Botón para la generación de código VHDL . . . . . . . . . . . . . . . . 1047.7 Botón para la apertura de WebLab-FPGA en el navegador por defec-

to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.8 Selección del VHDL a grabar en WebLab-FPGA. . . . . . . . . . . . . . 1057.9 Sintetización y grabación del VHDL en la placa FPGA . . . . . . . . . . 1067.10 Experimento FPGA activo con la placa grabada y en ejecución . . . . 1067.11 Diseño de autómatas. Opciones de generación de código VHDL com-

patible con WebLab-Deusto . . . . . . . . . . . . . . . . . . . . . . . . . 1087.12 Diseño de autómatas. Posibles relojes de WebLab-Deusto-FPGA . . . 1097.13 Diseño de autómatas. Controles de Boole-Weblab-Deusto, incluido

el botón de “Start Weblab” . . . . . . . . . . . . . . . . . . . . . . . . . 1117.14 Interfaz del experimento FPGA-Watertank (tanque de agua) . . . . . 113

x

8.1 FPGA-Watertank, ejecutándose en un tablet . . . . . . . . . . . . . . . 127

9.1 Search volume for Coursera (red) and MOOC (blue), as reported byGoogle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

xi

Índice de Listados

5.1 Parte del código VHDL autogenerado por Boole-Deusto para un au-tómata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.2 Configurando en el cliente dos nuevos experimentos JavaScript . . . . 875.3 Parte del archivo de definición de escena (world.js) de FPGAWatertank 90

7.1 Código VHDL de un sistema controlador del depósito de agua. . . . . 1147.2 Definiendo el valor de las salidas . . . . . . . . . . . . . . . . . . . . . . . 1157.3 Referenciando WeblabJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207.4 WeblabJS API (Weblab class) . . . . . . . . . . . . . . . . . . . . . . . . . . 1217.5 Ejemplo de uso de WeblabJS . . . . . . . . . . . . . . . . . . . . . . . . . . 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 marchadel 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 tra-dicionalmente 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 realidadsuele existir un problema. Mientras que los cuatro primeros suelen ser secuenciales ypueden ser llevados acabo en un aula cualquiera o un entorno similar, los requisitos delquinto paso (pruebas reales del sistema) son mayores.

Por una parte, es necesario contar físicamente con un laboratorio provisto de equipa-miento especializado para poder trabajar. Para probar un diseño FPGA, por ejemplo, senecesitarán generalmente ordenadores equipados con software de Xilinx o un fabricantesimilar, con placas de prototipado de FPGAs, etc.

Aparte de la necesidad de disponer de estos equipos, y mantenerlos en correcto funcio-namiento, existe también un problema práctico. Desde las cuatro primeras etapas a laquinta, habrá en general un periodo de tiempo intermedio, que interrumpe el proceso deaprendizaje.

El proyecto de diseño y desarrollo de la plataforma Boole-WebLab-Deusto reduce oelimina totalmente estos inconvenientes, y además ofrece múltiples ventajas adiciona-les.

En parte por ésto, se enmarca dentro del Technology Enhanced Learning, ya que se basaen la utilización de las TIC para mejorar el proceso de aprendizaje, y podemos afirmarque 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ápidode un sistema digital en sólo unos minutos. El sistema digital a crear se diseña en Boole-Deusto, e inmediatamente después puede probarse en hardware físico real (una placaFPGA) a través de WebLab-Deusto.

Esto implica que los estudiantes no necesitan acceso físico a equipamiento especiali-zado, 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 suficientepara 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 queen ocasiones los experimentos resultan demasiado sencillos y distantes de la prácticareal.

Mientras que en la realidad los dispositivos electrónicos se utilizan para controlar sistemascomplejos como una línea de producción, por limitaciones prácticas, los ejercicios de losestudiantes 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 lasalida hace que sean a veces poco inmersivos, y que los estudiantes no lo considerencomo un reto.

Gran parte del carácter innovador de este proyecto se debe a la capacidad que se haañadido de extender los experimentos electrónicos reales con realidad aumentada.

Figura 1.1.: Experimento FPGA real controlan-do un tanque de agua virtual

Utilizando estas técnicas, es posible colo-car en el experimento un modelo virtual,sobre la vista de la placa FPGA física real.De este modo, podemos tener, por ejem-plo, un sistema relativamente complejo,visual e interesante como un tanque deagua.

El reto de tales experimentos, por supues-to, consiste en controlar mediante la placaFPGA (que es física y absolutamente real)el modelo virtual.

Para hacer ésto posible, el sistema per-mite, valiéndose en parte de técnicas devisión artificial, la interacción en ambos sentidos entre modelo virtual y placa físicareal.

El proyecto se basa en parte en los resultados obtenidos durante los cuatro años de micolaboració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 enconferencias y revistas.

1.1 PRESENTACIÓN

El presente documento describe el plan de trabajo del proyecto realizado en nueve capí-tulos.

2

PROYECTO FIN DE CARRERA

En primer lugar se describe brevemente el contexto en el que se desarrolla. Se con-sideran los diferentes campos del conocimiento involucrados y se introducen las dosherramientas en torno a las que gira el proyecto, el laboratorio remoto WebLab-Deusto yel software de diseño electrónico Boole-Deusto.

En segundo lugar el documento de objetivos describe desde un punto de vista másformal la planificación (estimada) del proyecto, sus objetivos y alcance, las fases en lasque 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áspráctica Boole-Deusto, WebLab-Deusto, y las demás tecnologías hardware y softwareque tienen un papel importante en el proyecto.

Después, el desarrollo describe el entorno técnico utilizado, así como, desde una pers-pectiva 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 describiraquellas limitaciones y complicaciones técnicas más notables que han aparecido duranteel 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 di-señar y probar un sistema digital mediante Boole-WebLab-Deusto. El segundo, la guíapara utilizar el experimento FPGAWatertank, y aprovechar las características que ofrecepara programar un controlador para el modelo virtual (un tanque de agua).

Tras esto, en conclusiones y trabajo futuro pueden conocerse los resultados que sehan obtenido, la comparación que puede hacerse con los objetivos iniciales, y las líneasde trabajo futuras que podrían seguirse.

El último capítulo se dedica a un posible plan de negocio, que propone una empresa ba-sada 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, entreotros documentos, diversos artículos publicados durante los cuatro años de colaboracióncomo parte del equipo de WebLab-Deusto.

3

PROYECTO FIN DE CARRERA

2. CONTEXTO

2.1 INTRODUCCIÓN

Este proyecto se ha realizado en el ámbito del proyecto de investigación de laboratoriosremotos WebLab-Deusto [46] de la Universidad de Deusto, con cuyo equipo el autor hacolaborado durante cuatro años.

El proyecto supone, por una parte, una labor de integración entre el software de labora-torios remotos WebLab-Deusto y el software de diseño electrónico Boole-Deusto, parafacilitar 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 pro-yecto, el proyecto implica la creación de una infraestructura de realidad aumentada capazde añadir sobre las placas físicas reales de los experimentos un modelo virtual. De estemodo, dichas placas físicas pueden ser programadas por los usuarios, controlando conellas el modelo virtual. Para lograr que sea posible la interacción en ambos sentidos, serecurre a técnicas de visión artificial.

En ambos casos, podemos afirmar que se trata de una contribución dentro del campo delaprendizaje mejorado con tecnología (Technology Enhanced Learning).

Como una fase anterior al proyecto en sí mismo, se estudiará muy brevemente la natu-raleza y estado del arte de los campos involucrados, incluyendo el aprendizaje mejoradocon tecnología, los laboratorios remotos, la realidad aumentada, la visión artificial, y eldiseñ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 sucolaboració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 referidosimplemente como eLearning, que es un término en general más inclusivo. Ambos ca-sos describen tecnologías orientadas a dar alguna clase de soporte al aprendizaje o ala 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 respectoa 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 posterioresde este documento, permiten a estudiantes o usuarios acceder desde cualquier lugardel globo a experimentos que físicamente se ubican en la universidad o en otro lugardistante.

Otra familia de tecnologías relacionadas que hoy en día está experimentando un gran cre-cimiento 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 gratuitade miles de personas, a través de la Web. En general, los formatos de los MOOC imitan alos de una curso tradicional, y están basados en vídeos, resolución de problemas, lectu-ras, y otros materiales. Se considera probable que en el futuro la influencia de los MOOCssobre el aprendizaje y la enseñanza continue creciendo, y su potencial se aplique en losdiversos ámbitos del saber, incluyendo las ciencias de la salud [29][19].

Finalmente, otro campo relacionado que es importante destacar es el de la realidad vir-tual.

La realidad virtual se basa en ofrecer al usuario un entorno virtual (generado digitalmentepor 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 unlugar real del mundo, puede ser totalmente imaginario, o puede ser una mezcla de ambascosas.

A pesar de que las aplicaciones de la realidad virtual son múltiples, una de las más co-munes es precisamente el aprendizaje. Las aplicaciones en este ámbito son extremada-mente numerosas. Se ha utilizado, por ejemplo, para crear sistemas de entrenamientopara paracaidistas [21], que permiten practicar la actividad sin riesgo. También se ha uti-lizado 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 Tech-nology Enhanced Learning.

Un laboratorio remoto es un conjunto de software y de hardware que permite a estudian-tes o usuarios en general el acceso remoto a experimentos (equipamiento físico real) queestá 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 acce-so a internet, puede experimentar con equipamiento hardware que esté ubicado en unauniversidad a miles de kilómetros.

6

PROYECTO FIN DE CARRERA

La tecnología de laboratorios remotos no es tan reciente como podría pensarse. A finalesde los 90, apareció ya unos de los primeros laboratorios accesibles por Internet, en tornoal proyecto europeo PEARL [6]. Sin embargo, en torno al año 2000 comenzó la apariciónde 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 soportanal 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óloexperimento concreto. Es decir, un laboratorio remoto ofrecería por ejemplo únicamentesoporte a la creación de pequeños circuitos electrónicos. Esta clase de laboratorios seconocen 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 sonsistemas muy complejos, y tienden a soportar tal propósito de una manera excelente. Unejemplo sería VISIR [17].

En la Fig. 2.1 podemos ver un diagrama que representa la estructura de un SPRL. Comopodemos ver, lo fundamental es el hecho de que, a través generalmente de un simplenavegador y de acceso a Internet, proporcionan acceso a equipamiento que puede estarubicado 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ósitoespecífico, sino que son sencillamente facilidades genéricas que todo laboratorio remototiene necesidad de soportar. Cada laboratorio de propósito específico se ve por tantoobligado a reimplementar tales características.

Las consecuencias negativas de ésto son varias:

Los desarrolladores de laboratorios de propósito específico deben reimplementardiversas funcionalidades que verdaderamente no pertenecen a su propósito espe-cífico.

La calidad de dichas funcionalidades secundarias pero necesarias termina siendovariable.

La interfaz y funcionalidades soportadas son muy distintas para cada laboratorio,lo que perjudica a la experiencia del usuario.

Paramejorar la situación a este respecto, han surgido los sistemas de gestión de laborato-rios remotos, conocidos como Remote Laboratory Management Systems (RLMS).

Estos sistemas son, en definitiva, laboratorios remotos de propósito general. Proveen di-versas características comunes, como autenticación, administración, un estilo de interfazde usuario, escalabilidad, etc. Proveen también experimentos específicos, y facilitan eldesarrollo de experimentos nuevos.

Existen unos cuantos RLMS. Algunos de éstos son, por ejemplo, MIT iLabs [20], LabshareSahara [27], VLCAP [39] y el propio WebLab-Deusto [32], que se describirá en detalle ensecciones posteriores de este trabajo.

Figura 2.2.: Sistema de gestión de laboratorios remotos (RLMS) [31]

8

PROYECTO FIN DE CARRERA

Las ventajas de los RLMS son múltiples. Aparte de simplificar el proceso de desarrollode nuevos experimentos, proveen uniformidad al usuario. Además, puesto que múltiplescaracterísticas son comunes a todos los experimentos, dichas características tienden aestar mejor soportadas que en laboratorios remotos de propósito específico. Al añadiruna característica transversal nueva, además, automáticamente pasa a estar disponiblea 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 diversosexperimentos 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 discu-sión sobre su utilidad en aplicaciones industriales queda fuera del ámbito de este traba-jo).

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 eltiempo. Con un número limitado de equipos distintos puede servirse a un númeromayor de usuarios que un laboratorio tradicional.

Comodidad y conveniencia: Los estudiantes pueden conectarse desde cualquierlugar y a cualquier hora. Esto facilita su aprendizaje y la tarea del profesor, que nor-malmente necesitaría planificar y reservar una sesión en un laboratorio tradicional,etc.

Eficiencia en el aprovechamiento del tiempo: Los estudiantes y los profesores nonecesitan perder tiempo desplazándose a un laboratorio real, preparando el equi-pamiento para las pruebas o recogiéndolo al terminar. Los experimentos remotosestán listos para ser usados, en el mismo momento en el que se accede remota-mente.

Distancia: Pueden ser ofrecidos a estudiantes que se encuentren en cualquier lugardel globo. Esta característica, con el auge de los MOOC (Massive Open OnlineCourse) 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 es-tudiantes, se facilita el mantenimiento y se evita la necesidad de personal supervisoral no tener que ofrecer un laboratorio tradicional físicamente accesible por grandesgrupos de estudiantes. El hecho de que el equipamiento no esté expuesto a acci-dentes, y que no se requiera montaje y desmontaje constante de los equipos, comoen 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 deun entorno real. Dicho entorno real es “aumentado” o “extendido” mediante elementosaudiovisuales generados por ordenador.

Si bien el desarrollo de la realidad aumentada es especialmente notable hoy en día, ya enlos 90 existían un gran número de aplicaciones, desde aplicaciones para el entrenamientode cirujanos hasta aplicaciones de entrenamiento militar [1].

En la Fig. 2.3 podemos ver un buen ejemplo de realidad aumentada. En la figura, apareceuna habitación real en la que se encuentra un conjunto de muebles virtuales, que porsupuesto no existen realmente en la habitación. En este caso se trata de un softwarede diseño de interiores, pero las posibles aplicaciones de la realidad aumentada sonextremadamente numerosos y variados. Ejemplos son sistemas de gestión de procesosde construcción [13] y muchas otras aplicaciones que se han llevado acabo durante losúltimos años [50].

10

PROYECTO FIN DE CARRERA

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 losavances 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 menosconocida.

Mientras que la realidad aumentada se refiere al “aumento” de la realidad con elementosvirtuales, la realidad mixta se refiere a la mezcla de elementos virtuales y elementosreales para crear un entorno nuevo, formado tanto por elementos virtuales como porelementos reales, que interaccionan entre sí y en tiempo real.

En ocasiones, no es evidente dónde empieza la realidad aumentada y dónde la realidadmixta. A lo largo de este documento se hablará más frecuentemente de realidad aumen-tada, 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 deaplicaciones útiles presentes y futuras.

Su objetivo principal es el desarrollar métodos y técnicas para poder analizar y entenderuna 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ásrecientes son sistemas para la navegación de robots [8], o incluso diversos proyectos encurso para la creación de vehículos sin conductor [26][15] (realmente, usan un sistemacomplejo 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 elde poder saber qué está haciendo el usuario en su experimento. Esto permite conocercuá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 delbuen estado del experimento.

2.3 SOFTWARE Y ENTORNOS DE PARTIDA

El proyecto se basa en la integración y mejora de dos software preexistentes: Weblab-Deusto (sistema de gestión de laboratorios remotos) y Boole-Deusto (un software edu-cativo de diseño electrónico). A continuación, se incluirá un breve resumen de sus ca-racterí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 losdetalles relevantes de ambos.

12

PROYECTO FIN DE CARRERA

2.3.1 Boole-Deusto

Boole-Deusto [52][51] es una herramienta software para el diseño de circuitos electróni-cos digitales. Es una herramienta de código abierto, desarrollada por profesores y estu-diantes 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 suscaracterísticas más notables está el diseño de sistemas tanto combinacionales como se-cuenciales (autómatas), y la generación automática de diagramas para dichos circuitosy de código VHDL.

Figura 2.7.: Una de las pantallas principales de Boole-Deusto (diseño de sistemas combinacio-nales)

2.3.2 Weblab-Deusto

Weblab-Deusto [32] es un laboratorio remoto de código abierto [46] desarrollado en laUniversidad de Deusto. En concreto, puede ser considerado un RLMS (Remote Labo-ratory Management System), ya que está diseñado como un framework genérico, quesoporta cualquier tipo de experimento remoto y que no se limita a un tipo de experimen-tos específico o a un solo campo. En la actualidad, si bien predominan los experimentoselectrónicos, se soportan otros más relacionados con biociencias y otros campos, y esrelativamente 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 grabarremotamente 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 in-teractuar con ella mediante botones e interruptores virtuales (que no obstante, producenuna entrada física real en la placa).

Figura 2.8.: Experimento FPGA estándar, en WebLab-Deusto, ejecutando una lógica ya gra-bada provista por un usuario

En la Fig. 2.8 se muestra la versión estándar del experimento WebLab-Deusto-FPGA. Elprograma ya ha sido enviado por el usuario y grabado por WebLab en la placa física, quepuede verse através de la Webcam. Dicha webcam muestra la placa FPGA en tiemporeal, permitiendo observar su salida gracias a los LEDs que dicha placa tiene. En la ima-gen 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 interruptoresen 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 deWebLab-Deusto he participado en distintas publicaciones. Algunas de éstas tratan direc-tamente sobre el proyecto. Otras se centran en diferentes aspectos del laboratorio remotoWebLab-Deusto, y de forma indirecta han llevado a la consecución de éste proyecto. Seincluye a continuación una lista de ambos grupos (y se incluyen las más relevantes enlos anexos).

1. Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Pablo Orduña, Olga Dz-biabenko. Integration of a Remote Lab in a Software Tool for Digital Electronics.

14

PROYECTO FIN DE CARRERA

(2013). Submitted for publication.

2. Javier Garcia-Zubia, Luis Rodriguez-Gil, Pablo Orduña, Ignacio Angulo, Olga Dz-biabenko. Boole-WebLab-Deusto: Integration of a remote lab in a tool for digitalcircuits design. (2013). Submitted for publication.

3. Javier Garcia-Zubia, Luis Rodriguez-Gil, Pablo Orduña, Ignacio Angulo, Unai Her-nandez, Olga Dziabenko, Mari Luz Guenaga. An Integrated Solution for Basics Di-gital Electronics: Boole-DEUSTO and WebLab-DEUSTO. REV2013: 10th Inter-national 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. Sha-ring Remote Labs: A Case Study. International Journal of Online Engineering - iJOE9(Special Issue: REV2012 Exhibition). 26 – 27. 2013.

5. Pablo Orduña, Xabier Larrakoetxea, David Buján, Aitor Gómez-Goiri, Ignacio An-gulo, Olga Dziabenko, Luis Rodriguez-Gil, Diego López-de-Ipiña, Javier Garzia-Zubia. WebLab-Deployer: exporting remote laboratories as SaaS through federationprotocols. REV2013: 10th International Conference on Remote Engineering and Vir-tual Instrumentation. Sydney, Australia, 6 - 8 February 2013.

6. Javier García-Zubía, Pablo Orduña, Ignacio Angulo, Unai Hernández, Olga Dziaben-ko, Luis Rodríguez, María Luz Güenaga, Ingvar Gustavsson. Remote Laboratories:Opportunities and Challenges. The World of Sustainable Laboratories, WOSLAB2012. 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ópez-de-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. Sha-ring the remote laboratories among different institutions: a practical case. RemoteEngineering & Virtual Instrumentation. REV2012. Bilbao, Spain. July 2012.

9. Pablo Orduña, Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Olga Dzia-benko, Diego López-de-Ipiña. Exploring students collaboration in remote laboratoryinfrastructures. 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. Ad-vanced integration of OpenLabs VISIR (Virtual Instrument Systems in Reality) withWeblab-Deusto. Remote Engineering & Virtual Instrumentation. REV2012. Bilbao,Spain. July 2012.

11. Javier Garcia-Zubia, Bruno Campos, Pablo Orduña, Luis Rodriguez, Ignacio An-gulo, Olga Dziabenko. Easily Deployable Low-Cost Remote Lab Platform.. Remote

15

2. CONTEXTO

Engineering & Virtual Instrumentation. REV2012. Bilbao, Spain. July 2012.

12. Pablo Orduña, Javier García-Zubia, Fabricio Gazzola, Luis Rodriguez-Gil, JaimeIrurzun, Diego López-de-Ipiña. Using LabVIEW Remote Panel in Remote Labora-tories: advantages and disadvantages. IEEE EDUCON 2012. Marrakesh, Morocco,April 2012. Page(s): 1 - 7. DOI: 10.1109/EDUCON.2012.6201134. ISBN: 978-1-4673-1457-2.

13. Pablo Orduña, Jaime Irurzun, Luis Rodriguez-Gil, Javier Garcia-Zubia, FabricioGazzola, Diego López-de-Ipiña. Adding New Features to New and Existing RemoteExperiments through their Integration in WebLab-Deusto. International Journal ofOnline Engineering (iJOE) (ISSN: 1861-2121). 2011.

14. Javier Garcia-Zubia, Ingvar Gustavsson, Unai Hernandez-Jayo, Pablo Orduña, Igna-cio 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 Dzia-benko, Luis Rodriguez-Gil and Diego López-De-Ipiña. WebLab-Deusto-CPLD: APractical Experience. 1st Experiment@ International Conference (expat2011). 2011.

16. Javier Garcia-Zubia, Pablo Orduña, Ignacio Angulo, Unai Hernandez, Olga Dziaben-ko, Diego Lopez-de-Ipiña, Luis Rodriguez-Gil. Application and User Perceptions ofUsing the WebLab-Deusto-PLD in Technical Education. 41st ASEE/IEEE Frontiersin 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 Lopez-de-Ipiña Reusing requirements among remote experiments for their development andintegration under WebLab-Deusto. REV 2011: 8th International Conference on Re-mote Engineering and Virtual Instrumentation. Brasov, Romania, July 2011.

18. Javier Garcia-Zubia, Ingvar Gustavsson, Pablo Orduña, Diego Lopez-de-Ipina, UnaiHernandez, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil Using VISIR atthe University of Deusto: experiments, subjects and students. REV 2011: 8th Inter-national 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. Rodriguez-Gil. Justificación, propósito y ventajas de un laboratorio remoto. III Foro Interna-cional sobre Innovación Docente. Bilbao, Julio 2011.

20. Pablo Orduña, Javier García-Zubia, Jaime Irurzun, Diego López-de-Ipiña, Luis Rodriguez-Gil. 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/EDU-CON.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

PROYECTO FIN DE CARRERA

is expected from a remote lab? REV2010. Stockholm, Sweden. 2010. ISBN: 978-3-89958-540-7, 34-38 pp.

17

PROYECTO FIN DE CARRERA

3. OBJETIVOS DEL PROYECTO

En este capítulo se indicará en cierto detalle en qué consistirá el proyecto, cuáles sonsus objetivos, y qué resultados pretenden obtenerse.

3.1 DESCRIPCIÓN DEL PROYECTO

El proyecto consta de dos grandes objetivos diferentes pero relacionados. En primer lu-gar, se busca integrar el software de código abierto de diseño electrónico Boole-Deustocon la infraestructura de laboratorios remotos Weblab-Deusto. En segundo lugar, se bus-ca desarrollar una infraestructura que permita ampliar los experimentos electrónicos deWebLab-Deusto con modelos virtuales (realidad mixta) de aplicaciones prácticas. Sedesarrollará también al menos un nuevo experimento electrónico utilizando tal infraes-tructura.

3.1.1 Integración Boole-Weblab-Deusto

En la actualidad, como se ha explicado anteriormente, y se detallará en secciones pos-teriores, Boole-Deusto es un software de código abierto de diseño electrónico, utilizadopara 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 ex-perimentos que soporta es la grabación remota de programas en dispositivos hardwa-re.

En estos experimentos los usuarios pueden, remotamente, grabar un programa que ha-yan previamente sintetizado o compilado en un dispositivo físico remoto real. Hecho ésto,pueden observar cómo funciona dicho dispositivo a través de unaWebcam e incluso inter-actuar con él. Dicha interacción se produce a través de controles virtuales que se traducenen señales físicas. En la mayoría de experimentos electrónicos actuales estos controlesvirtuales toman la forma de interruptores. Puede verse uno de estos experimentos enfuncionamiento (en concreto, con un dispositivo FPGA) en la Fig. 2.8.

Uno de los dos grandes objetivos de este proyecto es integrar ambos sistemas (Boole-Deusto y WebLab-Deusto), realizando las modificaciones y extensiones oportunas paraque puedan ser usados juntos, en un sólo flujo de trabajo integrado, sencillo y eficien-te.

Es decir, el objetivo es que el usuario pueda comenzar diseñando un sistema digital (yasea combinacional, ya sea secuencial) en Boole-Deusto. Una vez diseñado, inmediata y

19

3. OBJETIVOS DEL PROYECTO

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 explicadoarriba. El proceso parte de la especificación de un sistema digital. La complejidad de talespecificació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 unautó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á elsistema que ha creado, y verificará que funciona correctamente. El flujo de trabajo, comose 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 modificacionesmanuales para hacerlo compatible con Weblab-Deusto (que espera entradas y salidasespecíficas, etc).

Asimismo, en el momento de escribir esto, Weblab-Deusto tiene la capacidad de grabarprogramas ya sintetizados en placas físicas, pero no tiene la capacidad de sintetizar losprogramas a partir de código. Para sintetizar dichos programas, se requiere softwareespecializado. 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 gigabytesde tamaño [23].

Para logar dicha integración, por tanto, será necesario, primero, realizar diversas modifi-caciones y extensiones a Boole-Deusto (que se verán complicadas debido a la antigüe-dad de dicho software). Dichas modificaciones añadirán los elementos necesarios a lainterfaz para diseñar sistemas compatibles con Weblab-Deusto, incluyendo la elecciónapropiada de nombres para salidas y entradas, los controles necesarios para abrir au-tomáticamente Weblab-Deusto y generar código apropiado, etc. Será también necesariorediseñar el sistema de generación de código VHDL, de tal modo que siga permitien-do la generación de código VHDL genérico, y añadiendo la generación de código VHDLdirectamente compatible con Weblab-Deusto.

Será también necesario extender Weblab-Deusto, añadiendo la capacidad de sintetizar

20

PROYECTO FIN DE CARRERA

código VHDL, produciendo así por sí sólo los archivos binarios requeridos para la gra-bación en las placas. De este modo, los usuarios finales podrán probar su código sinnecesidad de instalar en sus ordenadores software especializado (que en muchos ca-sos es totalmente inviable, debido a la complejidad y tamaño de dicho software, y a lanecesidad 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 enmarcha, los usuarios podrán, en sólo unos minutos y sin necesitar ningún software espe-cial, diseñar un sistema digital con Boole-Deusto, y, con apenas dar a un botón, hacer quesu sistema digital se grabe automáticamente en una placa hardware física real, mediantela cual podrán probar de forma remota que se comporta (o no) como esperan.

3.1.2 Modelos virtuales en experimentos electrónicos reales

Figura 3.2.: Placa FPGA con 4 de los 8LEDs que actúan como sa-lida, encendidos

En la actualidad, los experimentos electrónicos engeneral consisten en una placa física, que remota-mente puede grabarse con un programa. Una vez elprograma está grabado, los usuarios pueden inter-actuar con la placa a través de interruptores, y pue-den observar su salida a través de LEDs, que tienela propia placa (ver Fig. 3.2). Si bien los LEDs sonenmuchos casos muy prácticos para conocer la sa-lida del sistema (son visibles a través de la Web-cam), son en ocasiones demasiado simples.

Lo ideal sería que pudieran existir elementos de sa-lida distintos (por ejemplo, un motor, un tanque deagua, una línea de producción o incluso elementosmás exóticos como el embalse de una central hidro-eléctrica). De este modo, los experimentos serían no sólo más interesantes y motivantespara 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, elexperimento pasa a ser muy concreto. La placa podrá utilizarse para ese ejerciciodeterminado (por ejemplo, controlar un motor), y para pocos más. Esto supone unelevado coste adicional con respecto a una placa genérica, que puede ser utilizadapara cualquier experimento.

Los elementos de salida en sí mismos pueden ser caros, directamente impracti-cables o incluso peligrosos. El mantenimiento de un tanque de agua, por ejemplo,sería notablemente complejo, especialmente porque deberían buscarse modos degestionar los desbordamientos, de que no existan escapes, etc. El coste de una

21

3. OBJETIVOS DEL PROYECTO

línea de producción o de una central hidroeléctrica, aunque fuesen a escala y paraexperimentación, sería probablemente prohibitivo.

Como solución intermedia, con un grado de realismo aceptable y sin embargo un costemuy bajo, en este proyecto se propone realizar experimentos que, basados en una placafísica real, estén dotados de realidad mixta. Es decir, que consten de un modelo virtualsobre 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 tanquede agua. Podrá grabar dicho sistema en una placa FPGA, y dicha placa actuará directa-mente 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 experi-mentos con modelos virtuales que este proyecto propone. Vemos que tales experimentostendrían, en primer lugar, la placa controladora, absolutamente real, con la que cuentanla mayoría de experimentos electrónicos de WebLab. Ésta placa puede ser remotamenteprogramada por el usuario remoto. Cuenta con LEDs como salidas integradas, que semantendrían. La clave, sin embargo, es que además de actuar sobre los LEDs, la placaactuará sobre la simulación de algún sistema, tal como un depósito de agua. Dicha inter-acción funciona en ambos sentidos. La simulación puede también actuar sobre la placafísica, por ejemplo, determinando con sensores virtuales el valor de sus entradas.

22

PROYECTO FIN DE CARRERA

Si bien un modelo virtual de un tanque de agua es evidentemente menos realista que unverdadero tanque de agua, el coste que supone es extremadamente bajo en compara-ció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 absolutamen-te real, y por tanto, en la mayor parte de aspectos, el sistema se comportará como secomportaría uno real en un entorno práctico. Sencillamente, la placa física real en vez decontrolar 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 quevaríe el modelo virtual pero no el hardware).

El nivel de realismo que se consigue es aceptable y sigue siendo mucho mayorque el de cualquier simulación completa, ya que la placa controladora en sí siguesiendo 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 lossistemas que este Proyecto propone y la infraestructura software de la que se parte, tantoWeblab-Deusto como Boole-Deusto.

Una descripción más técnica del funcionamiento de cada característica se encontrará ensecciones posteriores. Para que el ámbito del proyecto sea más abarcable y compren-sible, este apartado se divide en tres distintos, que no obstante están muy relacionadosentre sí.

23

3. OBJETIVOS DEL PROYECTO

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 relacionadoscon el proyecto. Considerando que la implementación es notablemente compleja, estediagrama general se limita a mostrar el funcionamiento de los sistemas desde un puntode vista cercano al usuario. Asimismo, para facilitar su comprensión podemos dividir elsistema en tres áreas:

Diseño y generación de código: La que involucra a Boole-Deusto, al diseño con élde sistemas digitales, y la generación de código VHDL compatible con WebLab.

24

PROYECTO FIN DE CARRERA

Sintetización a partir del código VHD: Lo que, en WebLab-Deusto, supone la gene-ración del archivo binario BITSTREAM (grabable en la placa física) a partir simple-mente del código VHDL.

Modelización Virtual: Lo que respecta, en WebLab-Deusto, a la creación de la in-fraestructura 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 comien-za, en principio, en Boole-Deusto. Es importante remarcar que si bien un flujo de tra-bajo completo comenzaría en efecto aquí, WebLab-Deusto y las facilidades referentesa sintetización de archivos y experimentación remota con placas físicas pero modelosvirtuales pueden ser sin ningún problema utilizadas independientemente. Es decir, losusuarios pueden codificar a mano el archivo VHDL, sin utilizar Boole-Deusto, y utilizarloen Weblab-Deusto.

Como podemos observar, el usuario comenzaría diseñando un sistema digital en Boole-Deusto. Las facilidades de diseño de sistemas digitales de Boole-Deusto, en general, norecibirán modificaciones notables por parte de este proyecto.

Una vez que el sistema digital esté diseñado, el usuario podrá generar automáticamenteel código VHDL correspondiente, compatible con Weblab. Esta es una capacidad queactualmente 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 Boole-Deusto el control suficiente sobre el proceso.

Éstas suponen, principalmente:

Capacidad en sistemas combinacionales de asignar entradas y salidas con nom-bres específicos, correspondientes al experimento de Weblab-Deusto (necesariopara 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 usua-rio no tendrá necesidad de conocer o recordar nombres para que sus programasfuncionen.

Capacidad en sistemas combinacionales de generar código VHDL compatible conel experimento Weblab-Deusto-FPGA, que se limite a las entradas y salidas ante-riormente mencionadas y que incluya el encabezamiento necesario para que no serequieran modificaciones manuales del código.

Capacidad en sistemas secuenciales (autómatas) de elegir el reloj a utilizar. EnWeblab-Deusto-FPGA existen varios relojes disponibles, incluyendo un reloj in-terno, un reloj externo, y un reloj controlado manualmente por un interruptor (paradepuración).

Capacidad en sistemas secuenciales (autómatas) de generar código VHDL compa-tible con el experimento Weblab-Deusto-FPGA, que convierta de forma automática

25

3. OBJETIVOS DEL PROYECTO

las entradas / salidas típicas de un autómata a entradas compatibles, y que incor-pore al código directivas propias específicas que permitan al servidor distinguir eltipo 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 llevedirectamente al experimento enWeblab-Deusto. Por lo que a Boole-Deusto respecta, sólorestará entonces seleccionar el archivo VHDL que se ha generado y reservar con él elexperimento del laboratorio remoto que se muestre en el navegador. Con esto, podemosconsiderar que las responsabilidades de la parte de Boole-Deusto habrán acabado (porsupuesto, el usuario podrá seguir modificando y probando libremente el sistema, pero enlo 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 laFig. 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 aca-bo. Cuando Weblab-Deusto-FPGA reciba un archivo VHDL, procederá a sintetizarlo. Elproceso de sintetización es aquel en el cual, partiendo del código fuente, se obtiene trasvarios pasos un archivo BITSTREAM, que es una descripción binaria de bajo nivel delsistema, y que puede ser grabada directamente en una placa hardware.

En este proceso interviene también un archivo UCF (User Constraints File). Este archivodefine la correspondencia entre entradas y salidas lógicas (descritas en el VHDL) y en-tradas y salidas físicas (pines en la placa hardware en la que será grabado el programasintetizado). Como vemos en la Fig. 3.4 y en la Fig. 3.5, será Weblab-Deusto el que pro-vea el UCF adecuado, que podrá ser uno u otro dependiendo de las circunstancias (quese detallan en la sección técnica).

Figura 3.5.: Diagrama conceptual básico del proceso de sintetización en los servidores deWebLab-Deusto

En este proceso, el servidor de Weblab-Deusto hará uso de herramientas provistas porXilinx. Podemos diferenciar dos conjuntos de herramientas. Las primeras, de sintetiza-ció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

PROYECTO FIN DE CARRERA

las necesarias para una vez que se tiene el BITSTREAM, grabarlo en la placa física. Elsegundo grupo funciona ya enWeblab-Deusto. El primero será integrado durante el desa-rrollo de este proyecto, añadiendo con ello a Weblab-Deusto la capacidad de sintetizarVHDL por su cuenta.

Para esto, será necesario:

Diseñar e implementar una interfaz de integración que permita a los servidores deWebLab-Deusto-FPGA controlar los programas de línea de comando de Xilinx, detal forma que sea a la vez seguro y confiable.

Desplegar las herramientas de Xilinx de línea de comandos en los servidores deWeblab-Deusto-FPGA, de tal modo que la capa de integración pueda hacer uso deellas.

Realizar las modificaciones oportunas a Weblab-Deusto-FPGA, para que permitaañadir un paso anterior completamente nuevo a su flujo de trabajo (el proceso desintetización).

Una vez realizados los pasos anteriores, el sistema tendrá la capacidad de no sólo grabaren la placa física archivos BITSTREAM, sino generar los propios BITSTREAM a partir desólo código.

Las ventajas de esto son múltiples para los usuarios. El proceso de generación de unBITSTREAM compatible con las placas concretas de Weblab-Deusto es complicado. Re-quiere software de Xilinx específico, con unos requisitos notablemente altos (ocupa másde 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 pasaa ser absolutamente transparente. Sólo necesitan crear el código fuente VHDL. Todo lodemá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 placafísica. Es aquí donde entran las características de realidad mixta que también proponeeste proyecto.

Durante este proyecto, se dotará a WebLab-Deusto de las infraestructuras genéricasque requiere para poder crear fácilmente experimentos electrónicos con la capacidad demostrar, además de la placa física real, un modelo virtual, con el que la placa puedeinteractuar.

Para ello, serán necesarias bastantes extensiones a la infraestructura existente. Comose detallará más adelante, se añadirá en primer lugar soporte para crear experimentosbasados en JavaScript en HTML5. De este modo, será posible crear experimentos que

27

3. OBJETIVOS DEL PROYECTO

hagan uso de tecnologías como WebGL para mostrar los gráficos requeridos y ser losuficientemente inmersivos.

Figura 3.6.: Tanque de agua virtual: Ejemplode un posible modelo (sólo el mo-delo)

Asimismo, se añadirán facilidades paraque dichos experimentos puedan ser crea-dos de forma consistente, sin necesidad(o limitando al máximo) de recompilacio-nes.

Una vez que estén incorporadas las infra-estructuras genéricas necesarias, se pro-cederá al diseño e implementación de unexperimento concreto. Es decir, de una va-riación de Weblab-Deusto-FPGA median-te la que el usuario pueda definir un pro-grama que se ejecute en una placa realy que pueda controlar con ella un mo-delo virtual. Muy probablemente, este pri-mer experimento consistirá en un depósi-to de agua, como el que se muestra en laFig. 3.6. Cabe notar que dicha figura sólomuestra el modelo, no todo el experimento1.

El usuario controlará mediante la placa dos bombas de agua que alimenten el depósitode agua. Asimismo, el depósito dispondrá de una salida de agua, que representará lademanda. Dicha demanda será variable, y parcialmente aleatoria, simulando así un sis-tema 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 variossensores de nivel, con el objetivo de mantener el nivel de agua constante dentro de unrango adecuado. (Evitando un nivel demasiado bajo, y evitando al mismo tiempo desbor-damientos).

Una vez creadas las infraestructuras genéricas necesarias y el primer experimento, elobjetivo es, sin embargo, que sea notablemente más sencilla la creación de experimentosadicionales. Si bien, por supuesto, será inevitable que siga siendo necesario crear losmodelos 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óncon WebLab-Deusto, la generación de código VHDL directamente compatible, el

1La clave del sistema es precisamente que existe un componente real (la placa FPGA) y un componentevirtual (el modelo), que interactúan en ambos sentidos. Puede verse en la Fig. 3.3.

28

PROYECTO FIN DE CARRERA

modo WebLab para elegir entre la lista de entradas/salidas, etc.

WebLab-Deustomejorado con las capacidades descritas. Entre otras, la capacidadde sintetizar código VHDL, de soportar servidores de experimentos en JavaScript,de soportar clientes de experimentos en JavaScript, así como la infraestructura ne-cesaria para crear experimentos con realidad mixta de forma sencilla, utilizandonuevas tecnologías Web como WebGl.

Experimento FPGA-Watertank, primer experimento con realidad aumentada, queutiliza la infraestructura anteriormente creada, y que puede servir de base para eldesarrollo de experimentos posteriores.

Productos documentales:

Guía de usuario de Boole-WebLab-Deusto: Descripción de cómo usar Boole-WebLab-Deusto, describiendo la manera de crear y probar tanto autómatas comosistemas 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 nuevosdesarrolladores de Boole-Deusto, que recopile los problemas y soluciones encon-trados durante éste proyecto (durante el cual no existía documentación de Boole-Deusto disponible).

Otros:

Plan de negocio: Posible plan de negocio para una empresa basada en proporcio-nar 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 lanaturaleza 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 unmodoWebLab, 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á desactivadose generará código VHDL genérico pero sintácticamente correcto.

3. En la parte combinacional de Boole-Deusto si el modo WebLab está activado segenerará código VHDL directamente compatible con WebLab-Deusto.

4. En la parte combinacional de Boole-Deusto, puede abrirse WebLab-Deusto-FPGAen un navegador con una sola operación.

29

3. OBJETIVOS DEL PROYECTO

5. En la parte secuencial (autómatas) de Boole-Deusto el sistema permitirá generarcódigo VHDL directamente compatible con WebLab.

6. En la parte secuencial (autómatas) de Boole-Deusto el sistema permitirá elegir elreloj entre los siguientes: Interno, WebLab, Interruptor, Switch.

7. En la parte secuencial (autómatas) de Boole-Deusto podrá abrirseWebLab-Deusto-FPGA en un navegador con una sola operación.

8. Boole-Deusto permitirá acceder a ayuda específica tanto en el modo secuencialcomo en el combinacional.

9. Los servidores de WebLab-Deusto podrán sintetizar código VHDL a partir de lafuente VHDL y de un archivo UCF.

10. El experimento WebLab-Deusto-FPGA admitirá como entrada código VHDL, ade-más de seguir admitiendo un archivo binario BITSTREAM.

11. El experimento WebLab-Deusto-FPGA y todos los basados en Xilinx guardarán elestado de los interruptores, y soportarán comandos que permitan al cliente obte-nerlos.

12. El experimento WebLab-Deusto-FPGA y todos los basasados en Xilinx permitiráncambiar programáticamente las entradas a la placa, de tal forma que sea posibletransmitir con ello la información de los sensores virtuales de los modelos virtuales.

13. El experimento WebLab-Deusto-FPGA se modificará para permitir la cohexistenciacon modelos virtuales, cuyo estado sea obtenible a los clientes de experimentos através del comando VIRTUALWORLD_STATE.

14. Se soportará Javascript como nueva tecnología para crear experimentos en el ladodel cliente.

15. Se permitirá definir un nuevo experimento cliente en JavaScript a través de un ar-chivo JS o de un simple HTML.

16. El sistema dispondrá de una API WeblabJS para ser utilizada en los clientes Ja-vaScript, y que encapsule toda la comunicación con WebLab.

17. El sistema dispondrá de una infraestructura basada en ThreeJS que permita definirfácilmente (a través de una definición basada en JSON) una escena tridimensional.

18. Se ofrecerán controles JavaScript comunes (LEDs, interruptores, botones…) parapoder 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 LEDsfísicos de la placa, y permitirá su consulta a los clientes.

21. El sistema ofrecerá un experimento FPGA-Watertank, que permita al usuario con-trolar un tanque de agua virtual con la placa física real.

30

PROYECTO FIN DE CARRERA

22. El sistema permitirá definir servidores de experimento en JavaScript utilizando No-deJS.

3.4.2 Principales requisitos no funcionales

1. Boole-Deusto debe ser capaz de soportar al menos los idiomas español, inglés yeuskera.

2. Boole-Deusto en todas sus interfaces debe ser capaz de soportar sin problemas losnuevos nombres de entradas y salidas, notablemente largos.

3. En la parte combinacional de Boole-Deusto el sistema cambiará del modo WebLabal modo estándar sin pérdida de información.

4. Tanto en la parte secuencial como en la combinacional, al tratar de abrir WebLab-Deusto-FPGA, se advertirá si previamente no ha sido generado código VHDL com-patible, 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 ex-perimento JavaScript.

6. No se requerirán compilaciones en el servidor para crear o configurar un nuevoexperimento basado en JavaScript y NodeJS.

7. Se permitirá definir el tamaño por defecto del iframe de los experimentos JavaScripten la configuración del cliente.

8. Se soportará pantalla completa en los clientes de experimentos JavaScript (utili-zando HTML5) mejorando así la experiencia del usuario.

9. Se permitirá aceleración gráfica 3D (utilizandoWebGL) en los experimentos JavaS-cript, para permitir gráficos complejos con rendimiento aceptable.

10. Se permitirá gráficos basados en Canvas (compatible con más plataformas, perono acelerado) en los experimentos JavaScript, para permitir realizar experimentoscompatibles con más sistemas.

3.5 MÉTODO DE DESARROLLO

Como puede observarse, el proyecto es relativamente complejo. Para facilitar su desarro-llo y seguimiento, se dividirá en fases. Esto se ve favorecido por el hecho de que, si biensu ámbito es extenso, se puede dividir de forma conveniente en partes relacionadas perobastante independientes en cuanto a funcionamiento. Aunque dichas fases no tendríanpor qué ser necesariamente secuenciales, y con el equipo adecuado algunas de ellaspodrí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. OBJETIVOS DEL PROYECTO

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íanpodido ser definidos en detalle, y no están recogidos en esta sección sino en capítulosposteriores.

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 desarro-llos que definirán el proyecto, así como la forma general mediante la cual serán llevadasa 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í, proba-blemente no será aun conocida totalmente la extensión de los errores a solucionar enBoole-Deusto. Tampoco, el diseño preciso de los experimentos electrónicos con realidadaumentada que se pretenden desarrollar y añadir a WebLab-Deusto, o siquiera las tec-nologías que serán elegidas para ciertas tareas (posibles librerías de procesamiento deimagen, 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óndel 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 Boole-Deusto.

Se pondrá especial énfasis en aquellas áreas de Boole-Deusto que muestren actualmen-te ciertas deficiencias, así como en rediseñar aquellas áreas que vayan a ser necesariasen 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ñadopara solucionar ciertos errores conocidos y poder ser extendido en fases posteriores condiferentes tipos de VHDL compatible con WebLab-Deusto).

32

PROYECTO FIN DE CARRERA

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 relacionadoscon el proyecto, Boole-Deusto y WebLab-Deusto.

El objetivo concreto de esta fase es que el flujo de trabajo en ambos sistemas quedeintegrado de forma satisfactoria para el usuario (en el ámbito de los experimentos elec-trónicos con relación a Boole-Deusto). Se aplicarán durante esta fase aquellas mejoras ydesarrollos necesarios para que un circuito lógico en Boole-Deusto pueda, de forma sen-cilla y tan automática como sea posible, ser grabado físicamente en un FPGA o similar yprobado 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 Boole-Deusto mediante cualquiera de los métodos que éste ofrece. Se soportarán los dos ti-pos disponibles de circuitos: combinacionales y secuenciales. Una vez construido, podrá,desde el mismo Boole-Deusto, generar el código VHDL que corresponde al circuito paraun dispositivo FPGA. Dicho código VHDL estará perfectamente adaptado a WebLab, detal modo que no se requiera ninguna modificación manual.

Una vez generado el VHDL el usuario podrá, desde Boole-Deusto, pasar al experimentocorrecto de WebLab-Deusto, que recibirá su código VHDL. WebLab-Deusto entoncessintetizará el código VHDL que ha recibido, generando una descripción binaria (.bit), queprocederá a grabar en la placa FPGA. El usuario podrá entonces interactuar con esaplaca, como lo haría de forma normal en WebLab-Deusto.

Para lograr esto, durante esta fase se realizarán modificaciones y extensiones tanto aBoole-Deusto como aWebLab-Deusto. En concreto, dichasmodificaciones y extensionesincluyen, pero no se limitan a:

Extensiones de la interfaz de Boole-Deusto para soportar las nuevas funcionalida-des de conectividad. o Al modo combinacional: selección de nombres de entradasy salidas, generación de código, etc. o Al modo secuencial: selección de tipo dereloj para el autómata, generación de código, etc.

Extensiones de Boole-Deusto para soportar la conectividad con WebLab-Deusto, yser 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 elexperimento apropiado (FPGA o similar) y enviar el código VHDL generado porBoole-Deusto para ser grabado.

Extensiones a WebLab-Deusto para soportar las peticiones por parte de Boole-Deusto. A determinar durante esta fase qué clase de modificaciones son necesa-rias. Se espera que sean pocas.

Extensiones aWebLab-Deusto para soportar la compilación de archivos VHDL (consu correspondiente archivo UCF) a los archivos BITSTREAM grabables en los dis-positivos. Para ello, se necesitará utilizar e interactuar con software de Xilinx.

33

3. OBJETIVOS DEL PROYECTO

3.6.4 Fase 4: Implementación de experimentos electrónicos mediante realidad au-mentada

Como ha sido mencionado en apartados anteriores de este documento, un tipo común ymuy utilizado de experimento en WebLab-Deusto es aquel que permite al usuario grabarun programa de alguna clase en una placa con un dispositivo, interactuar con dicha placay por tanto con el programa que ha grabado, y observar los resultados de su interacciónen tiempo real a través de una Webcam.

Dichas placas contienen dispositivos tales comomicroprocesadores PIC, dispositivos FP-GA (Field Programmable Gate Array) o dispositivos PLD. Suelen también contener inte-rruptores y pulsadores como entradas, controlables remotamente (para poder interactuarde alguna forma con la placa), y LEDs como salida (para poder ver los resultados de dichainteracción a través de la Webcam).

Durante esta fase se añadirán experimentos que utilicen técnicas de realidad aumentadapara 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 elementosvirtuales, 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 unaentrada (por ejemplo, una entrada que le dice que accione una bomba de agua). El mode-lo virtual a su vez podrá actuar como entrada a la placa reemplazando a los interruptorescontrolables 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 deagua, 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 unaplaca real, ejecutado en un dispositivo físico, pueda resolver problemas e interaccionaren general con elementos virtuales potencialmente complejos y variados.

De este modo, si el modelo virtual representa, por ejemplo, un tanque de agua, el usuariopodrá diseñar el sistema que lo controle. Dicho sistema se ejecutará en condiciones total-mente realistas (en una placa hardware real), pero dicha placa no controlará un depósitoreal sino el depósito virtual.

Esto permite soportar de forma notablemente realista (el modelo es una simulación, perola placa controladora es absolutamente real) experimentos complejos muy cercanos aaplicaciones reales (como podrían ser un depósito de agua, una línea de producción oel embalse de una central hidroeléctrica), que por motivos prácticos y económicos se-rían a menudo inviables de otro modo. En esta fase se diseñará y creará la arquitecturanecesaria 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 faseno es aun conocido, y se llevará a cabo al inicio de la fase. Posiblemente, si en dichafase de diseño se considera apropiado y se desarrolla la idea, se incluirán experimentostales como el del control del nivel de agua de un depósito, mencionado anteriormente. Ental experimento, el usuario programaría el comportamiento del controlador del depósitoen el FPGA. De este modo, el usuario resolvería el problema en una realidad mixta. El

34

PROYECTO FIN DE CARRERA

controlador (la placa con el FPGA o similar) sería absolutamente real (el programa segrabarí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, esun FPGA real), y al mismo tiempo es económico (un experimento que permita el controlde un depósito de agua real sería mucho más costoso, demasiado específico en cuantoa su propósito, e incluso algo limitado, ya que posiblemente en ningún caso se podríapermitir, de forma segura, el desbordamiento del depósito, o el uso de las bombas enciertas 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 norequieren equipamiento físico adicional, y las placas FPGA pueden ser utilizadas paracualquier tipo de experimento y compartidas por cualquier modelo virtual en el que esténbasados).

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 experimen-tos.

Asimismo, existirá al menos un ejemplo de un experimento de esta clase, utilizando reali-dad mixta. Muy probablemente, será una variación del experimento actual FPGA, utili-zando esta misma placa y los LEDs de salida como entrada para el sistema virtual. Lanaturaleza exacta y diseño de dicho experimento, será determinada durante esta mismafase.

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 rea-lizadas 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 ysatisfactoria el flujo de trabajo propuesto.

Si bien las pruebas exactas serán determinadas durante la misma fase, las pruebas in-cluirán al menos, aunque no se limite sólo a ello, un usuario que parta de una tabla deverdad diseñada en papel, que deberá ser reconocida por Boole-Deusto (según mejorasde fase 2), pasada automáticamente a WebLab-Deusto y compilada (fase 3) y aplicadaen un experimento dotado de realidad aumentada como el descrito anteriormente (fase4).

Si se encontrasen fallos o carencias de diseño, programación o usabilidad serían corre-gidos durante esta fase.

35

3. OBJETIVOS DEL PROYECTO

3.6.6 Fase 6: Implantación en producción

En esta fase se actualizarán los servidores de WebLab-Deusto en producción, aplicandolos cambios y aportaciones del proyecto. Se modificará además su configuración de talforma que los nuevos experimentos con realidad mixta o aumentada provistos pasen aestar disponibles a los usuarios y estudiantes.

Se incluirán en este apartado aquellas tareas de prueba orientadas a garantizar el correc-to funcionamiento en producción del sistema en general y de los nuevos experimentosen particular, así como las subsiguientes correcciones, en caso de probarse necesa-rias.

3.7 TAREAS PRINCIPALES

En esta sección se detallarán las diferentes tareas que conformarán el proyecto. Se de-tallará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 pro-yecto.

1.2. Seguimiento: Control del desarrollo del proyecto, con el propósito de detectarrápidamente los problemas e imprevistos que puedan surgir y solucionarlos sintardanza.

2. Requisitos del sistema

2.1. Análisis de necesidades y requisitos: Teniendo en cuenta el estado de Boole-Deusto y las capacidades deWebLab-Deusto, se definirán los requisitos del siste-ma que sean apropiados para los objetivos del proyecto, y que sean alcanzablescon el tiempo y recursos disponibles.

2.2. Elaboración del documento de requisitos: Conocidos los requisitos del sis-tema, se definirán formalmente a grandes rasgos para formar el documento derequisitos.

3. Diseño preliminar

3.1. Revisión de requisitos: Se revisarán los requisitos, corrigiendo aquellos erro-res 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 enactividades posteriores.

4. Correcciones, cambios y mejoras a Boole-Deusto

36

PROYECTO FIN DE CARRERA

4.1. Detección de errores y carencias de Boole-Deusto: Se revisará Boole-Deustoen detalle, encontrando aquellos errores que sean relevantes para el proyecto. Secomprobará el flujo de trabajo propuesto por el proyecto, y se verificará si existencarencias, defectos o posibles mejoras al respecto.

4.2. Análisis del entorno de desarrollo de Boole-Deusto: Se analizará cuán anti-guo es el entorno de desarrollo de Boole-Deusto (que fue creado en una versiónparticularmente antigua de Borland C++ Builder). En caso de que el entorno origi-nal presente posibles problemas para la posterior codificación de mejoras (comoparece ser el caso) se considerarán posibles entornos más modernos a los cualesactualizar Boole-Deusto. Por regla general, cuanto más moderno sea el entornoobjetivo más difícil será actualizarlo, pero más sencillo y conveniente será des-pués el desarrollo en dicho entorno. En este análisis, se tratará de encontrar elentorno objetivo más adecuado, teniendo en cuenta estos hechos.

4.3. Actualización de Boole-Deusto a un entorno de desarrollo más moderno: Seactualizará el código de Boole-Deusto, para hacerlo compatible con un entornomás moderno (como podría ser una versión más moderna de Borland C++ Buil-der, o una versión, aun más moderna, de Embarcadero C++ Builder). La versiónobjetivo adecuada se habrá decidido en actividades precedentes.

4.4. Corrección de errores de Boole-Deusto: Se codificarán las soluciones a loserrores encontrados, y se solucionarán, dentro de lo posible, las carencias encon-tradas en el flujo de trabajo.

4.5. Actualización del sistema de traducciones: En el momento actual, el sistemade traducciones no funciona, ya sea por el uso de un sistema operativo modernoo porque la única versión del código disponible no es la correcta. Se restauraráo reconstruirá el sistema de traducciones, para permitir incorporar traduccionesnuevas tras realizar las modificaciones descritas en este proyecto.

4.6. Pruebas (Boole-Deusto): Se comprobará que le funcionamiento de Boole-Deusto, tras aplicar sus actualizaciones, mejoras y nuevas características, sea elque se espera. En caso de no serlo, se corregirán los errores o carencias encon-trados.

4.7. Documentación deUsuario (Boole-Deusto): Se actualizará el manual de usua-rio de Boole-Deusto incorporando instrucciones para poder conocer y hacer usode las nuevas características.

4.8. Documentación de Desarrollador (Boole-Deusto): Actualmente, no existe nin-guna documentación orientada a desarrolladores de Boole-Deusto. Se creará unapequeña documentación introductoria, de tal forma que en el futuro se facilite elposible mantenimiento o extensiones adicionales, poniendo especial énfasis enaquellos aspectos, como el sistema de lenguaje, que debidos a la antigüedad delsistema 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

3. OBJETIVOS DEL PROYECTO

dows y Linux que permitan la compilación programática (mediante línea de co-mandos) de fuentes VHDL para dispositivos específicos. Se documentarán losprogramas y comandos necesarios para lograr este cometido.

5.2. Diseño y codificación de sistema remoto de compilación de archivos VHDLpara WebLab-Deusto: Utilizando la información obtenida mediante actividadesprecendentes, y los programas provistos por Xilinx, se diseñará y codificará bajola infraestructura de WebLab-Deusto un sistema que haga posible que WebLab-Deusto reciba un archivo VHDL y lo compile, usando un archivo UCF propio, alformato BITSTREAM. Esto permitirá la posterior grabación en un dispositivo talcomo un FPGA.

5.3. Modificación de la interfaz de usuario de Boole-Deusto: Se modificará la in-terfaz de usuario de Boole-Deusto para que sea posible (y cómodo para el usua-rio) probar los circuitos lógicos en WebLab-Deusto, de manera tan automática ytransparente como sea posible. Se tendrá muy en cuenta la usabilidad.

5.4. Codificación de la conectividad Boole-Deusto – WebLab-Deusto: Se codifi-carán aquellos cambios y mejoras al código de Boole-Deusto que sean precisaspara implementar la funcionalidad que las nuevas funcionalidades requieren. Sedeterminará si se requieren también modificaciones a este respecto en el códigode WebLab-Deusto. En caso afirmativo, se codificarán también dichas modifica-ciones.

5.5. Pruebas (Conectividad): Se comprobará que las modificaciones realizadastanto a Boole-Deusto como a WebLab-Deusto no hayan introducido errores, fun-cionen como se espera, y posean una alta usabilidad desde la perspectiva delusuario. En caso de encontrarse errores o carencias, se solventarán tomando lasmedidas necesarias.

5.6. Documentación (Conectividad): Se modificará la documentación (manual deusuario) de Boole-Deusto para incluir las nuevas capacidades del programa. Semodificará también la documentación de desarrollo de WebLab-Deusto, en casode ser preciso, así como la documentación de usuario de WebLab-Deusto (unawiki) 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áfi-cos: Se analizarán las tecnologías y librerías actualmente disponibles. Se evitaránen cualquier caso tecnologías y librerías de pago, favoreciendo aquellas con licen-cias libres. Se tratará de encontrar la tecnología o librería más adecuada para lospropósitos del proyecto. Idealmente, la tecnología que finalmente resulte elegidadeberá ser lo suficientemente madura para ser usada en un entorno de produc-ción, lo suficientemente bien diseñada y documentada para que su empleo searelativamente sencillo para los desarrolladores y para que se minimice el tiempode desarrollo, y lo suficientemente potente como para ofrecer las características(afortunadamente no demasiado avanzadas) que el proyecto requiere.

38

PROYECTO FIN DE CARRERA

6.2. Diseño e implementación infraestructura de modelización virtual: Se diseña-ra e implementará la infraestructura necesaria para poder implementar de formasencilla experimentos dotados de modelización virtual y realidad mixta. Dicha in-fraestructura será tan genérica y reutilizable como sea posible, de tal modo quepartiendo de ella resulte sencillo crear diversos experimentos, con modelos virtua-les distintos. Para esto, se implementará una infraestructura que permita la crea-ción rápida de experimentos mediante JavaScript, tanto para el lado del clientecomo para el lado del servidor, o en tecnologías similares.

6.3. Diseño conceptual de nuevo experimento con realidad mixta: Se diseñará unnuevo experimento basado en el dispositivo FPGA, que se base en una realidadmixta. El diseño se adaptará a las capacidades que la tecnología de realidadaumentada 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 medianteuna placa FPGA real.

6.4. Diseño de implementación de nuevo experimento con realidad mixta: Se di-señará la implementación del experimento con realidad mixta diseñado concep-tualmente en actividades precedentes. Dicho diseño será tan genérico como seaposible, de tal forma que sea al menos en parte reutilizable para experimentosfuturos de características similares.

6.5. Codificación (de experimento): Se codificará la infraestructura genérica deWebLab-Deusto requerida para la creación de experimentos con realidad mixta,diseñada en actividades precedentes. A continuación, se codificará el experimen-to concreto diseñado también en actividades precedentes, que haga uso de dichainfraestructura genérica y que además de ser útil por sí mismo pueda servir comoejemplo y prueba de concepto para posteriores desarrollos relacionados.

6.6. Documentación (de realidad mixta): Se documentará la nueva infraestructurade realidad mixta, para facilitar el futuro desarrollo de experimentos relacionadosque la utilicen. Se documentará, asimismo (por separado, en la wiki de usuariode WebLab-Deusto) el funcionamiento del nuevo experimento.

6.7. Pruebas (de realidad mixta): Se comprobará que la nueva infraestructura derealidad mixta funcione adecuadamente, y esté diseñada e implementada correc-tamente, 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ána cabo las correcciones oportunas, que deberán ser reflejadas adecuadamenteen la documentación.

7. Pruebas, usabilidad e integración

7.1. Pruebas técnicas del flujo de trabajo del usuario: Se realizará el recorridocompleto por las características que el proyecto añade, desde la lectura de tablasde verdad en papel mediante Boole-Deusto, hasta la conectividad con WebLab-Deusto, y su uso en relación a el o los experimentos de realidad mixta creados. Encaso de encontrar errores o comportamientos indefinidos o inesperados, se toma-

39

3. OBJETIVOS DEL PROYECTO

rán las medidas adecuadas para corregirlos, realizando los cambios apropiadosa la documentación que corresponda.

7.2. Pruebas de usabilidad: Se comprobará que el sistema completo posea unausabilidad adecuada desde el punto de vista del usuario. Se tratarán de realizarpruebas de usabilidad con usuarios reales, y se tendrá en cuenta el feedback queproporcionen. Se aplicarán las medidas oportunas para mejorar la usabilidad, encaso de encontrar deficiencias.

7.3. Verificación de la documentación: Se comprobará que la documentación ela-borada o modificada (ya sea la referente al manual de usuario de Boole-Deusto, ladocumentación de desarrollo de WebLab-Deusto, o la documentación de usuariode experimentos de WebLab-Deusto) sea adecuada. Se extenderá o corregirá encaso 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 servidoresde WebLab-Deusto a la nueva versión que incluya todos los cambios y nuevascaracterísticas realizados durante el proyecto.

8.2. Pruebas (producción): Se comprobará que, tras la actualización, el sistemaexistente de WebLab-Deusto siga funcionando de la manera esperada. A pesarde estar presentes en el código, las nuevas características no habrán sido aunconfiguradas, y por tanto los usuarios no notarán (o no deberán notar) aun ningunadiferencia con versiones anteriores de WebLab-Deusto, ni podrán aun acceder alos nuevos experimentos.

8.3. Configuración de nuevos experimentos: Se añadirán los nuevos experimen-tos a la configuración de producción de WebLab-Deusto. Esta actividad incluye elañadir los nuevos experimentos a la configuración del servidor deWebLab-Deustoy a la configuración del cliente de WebLab-Deusto. Incluye también el añadir elexperimento, así como los permisos relacionados necesarios, a la base de datosy a los usuarios adecuados (entre los que posiblemente se encuentre el usuariode pruebas – accesible de manera pública).

8.4. Prueba de nuevos experimentos: Se comprobará que los nuevos experimen-tos hayan sido correctamente configurados, sean accesibles de la forma esperadaa aquellos usuarios o grupos de usuarios con los permisos requeridos, y se com-porten de la forma esperada. En caso de detectarse anomalías, se tomarán lasmedidas oportunas.

8.5. Pruebas extendidas: Estando los experimentos ya disponibles a la mayoríade usuarios de WebLab (ya que, en principio, al menos uno de los experimentosserá públicamente accesible mediante el usuario de demostración) se observaráel comportamiento de los usuarios con el experimento, y se tratará de averiguarsu grado de satisfacción y opinión con respecto a los nuevos experimentos. Encaso de detectarse deficiencias, o en caso de ser propuestas mejoras razonables,se tomarán las medidas oportunas.

40

PROYECTO FIN DE CARRERA

3.8 ESTIMACIÓN DE TIEMPOS

Figura 3.8.: Trabajo estimado para cada tarea

41

3. OBJETIVOS DEL PROYECTO

Figura 3.9.: Horas de trabajo previstas para cada grupo de tareas (fases)

42

PROYECTO FIN DE CARRERA

3.9 PROGRAMACIÓN TEMPORAL

Figura 3.10.: Diagrama de Gantt aproximado del proyecto

43

PROYECTO FIN DE CARRERA

4. TECNOLOGÍAS

En esta sección se describirán aquellas tecnologías que intervienen en el desarrollo deeste proyecto. Dichas tecnologías incluyen especialmente, en primer lugar, al softwarede 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á engran 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 deforma más detallada y técnica. En caso de requerirse información adicional, se puedenconsultar también los anexos.

En esta sección también se describirán de forma breve las tecnologías hardware y soft-ware involucradas.

4.1 BOOLE-DEUSTO

4.1.1 Introducción

Boole-Deusto es un software para diseño electrónico. Ha sido desarrollado por estudian-tes y profesores de la Universidad de Deusto como código abierto, y su primera versiónpublicada data del año 2000.

Está diseñado como herramienta educativa. No obstante, a pesar de esto, abarca todo elproceso 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 profesio-nales (como Proteus [36] o Electronics WorkBench [10]) ya que éstas suelen estar másenfocadas 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 dediseño. No es posible usar Boole-Deusto para ver cómo un sistema evoluciona a travésdel tiempo. Todo lo relacionado con simulación ya está cubierto en profundidad por otrasherramientas.

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ácti-camente 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á portanto ciertamente mayor.

4.1.2 Características

Los sistemas digitales pueden ser clasificados en dos grandes tipos, que son los queBoole-Deusto soporta. Estos dos grandes tipos son: sistemas combinacionales y siste-mas secuenciales.

Los sistemas combinacionales se caracterizan por ser más simples. No disponende memoria. Tienen un número definido de entradas y de salidas, y el valor delas 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 tradicio-nalmente como autómatas. Conservan y dependen de un estado, que varía segúnun reloj y según las entradas que recibe tras cada pulso.

Figura 4.2.: Clasificación de los circuitos digitales

46

PROYECTO FIN DE CARRERA

Dependiendo de la complejidad de los circuitos, los circuitos digitales pueden alternativa-mente ser divididos en circuitos a nivel de bit, y circuitos a nivel de palabra. Boole-Deustoestá totalmente orientado a los primeros (circuitos a nivel de bit). En la Fig. 4.2 pode-mos 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 pa-labra.

Es remarcable el hecho de que para proveer un soporte adecuado, Boole-Deusto es-tá dividido en dos grandes modos. El primero está totalmente dedicado a los sistemascombinacionales, y permite realizar el diseño completo, partiendo generalmente de unatabla 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 deeste cuadro de diálogo. No obstante, el proceso de creación de un sistema combinacionalcomenzará generalmente dando un nombre al sistema y definiendo las entradas, lassalidas, 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 unsistema combinacional con Boole-Deusto. Se observa que se parte de una definición desolución a un problema. Es decir, de una especificación de lo que se quiere obtener. Apartir de esta especificación, el usuario diseñará una tabla de verdad. Una vez diseñadadicha tabla, Boole-Deusto la convertirá a un conjunto de diagramas de Karnaugh.

Dichos diagramas se utilizan para simplificar la expresión booleana que corresponde ala tabla. Una vez obtenida la expresión booleana simplificada, es ya posible generar elcircuito digital. Boole-Deusto es capaz de generar el diagrama de un circuito (construidocon puertas lógicas) o de generar código VHDL o Verilog que especifica igualmente talcircuito.

48

PROYECTO FIN DE CARRERA

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 simplifi-cación, y realizarla ellos mismos si lo desean.

Fig. 7. Boole-Deusto: Diagrama de circuito generado por Boole-Deusto, en versión AN-D/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 dosdiagramas son la implementación de la lógica especificada según las tablas de verdaddefinidas previamente y la expresión booleana simplificada. Aunque ambos diagramasson diferentes, su efecto es equivalente. En el primer caso es un diagrama implementadocon puertas AND y OR, mientras que el segundo tipo de diagramas utiliza únicamentepuertas NAND.

50

PROYECTO FIN DE CARRERA

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 sistemasde tipo secuencial (es decir, de autómatas). Puede verse que la interfaz para el diseño deeste 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 laimagen podemos ver un sistema ya diseñado. Tras diseñarlo, el usuario puede obtenerautomáticamente (si así lo desea) las tablas de verdad. Por supuesto, también puedemodificarlas 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 lossistemas 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 abiertocuyo 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ác-ticamente todo el código, hace uso de VCL (Visual Components Library), la librería decomponentes de Borland.

Si bien C++ en sí mismo es un estándar, la versión concreta implementada por Borlandtiene muchas peculiaridades, y la librería VCL en concreto es totalmente propietaria. Estohace 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óna 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 consi-derablemente antiguo. Borland como empresa, de hecho, ha desaparecido. Existen de-rivados modernos del entorno, como Embarcadero C++ Builder, pero tienen diferenciasnotables.

52

PROYECTO FIN DE CARRERA

Todo esto hace que desafortunadamente, Boole-Deusto sea notablemente complicadode modificar. En secciones posteriores se describirán en más detalle problemas encon-trados. Otro aspecto remarcable de Boole-Deusto es su sistema de localización (quehace uso de una característica de Borland C++ Builder), que le permite estar traducido avarios idiomas.

4.2 WEBLAB-DEUSTO

4.2.1 Introducción

Figura 4.10.: Ubicación física de algunos de losexperimentos de WebLab, conte-nidos en cajas

Weblab-Deusto es un laboratorio remo-to creado por la Universidad de Deusto.Ha sido desarrollado y publicado como unsoftware de código abierto, y se encuen-tra en un proceso de constante desarrolloy mejora.

Un laboratorio remoto es, en definitiva, unaplataforma formada por hardware y porsoftware que tiene como objetivo permitir aestudiantes u otros usuarios experimentarremotamente a través de Internet, permi-tiéndoles acceder a equipamiento que fí-sicamente está ubicado en la universidad,escuela o centro de investigación, emulan-do en la mayoría de los casos a laboratorios clásicos presenciales.

Existen diferentes tipos de sistemas de laboratorios remotos. Existen, por ejemplo, la-boratorios remotos orientados a la educación, y laboratorios remotos orientados a otrospropósitos (por ejemplo industriales). En este caso, Weblab-Deusto es un laboratorio re-moto educativo.

También es remarcable que existen laboratorios remotos de dominio específico, que es-tán orientados a soportar un tipo de experimento concreto. Es decir, tienen un ámbitolimitando, permitiendo en general experimentar con una sola actividad concreta. Existentambién otros laboratorios, como el propio Weblab-Deusto, que son no son de dominioespecífico, sino que están orientados a cualquier tipo de experimento, y aportan una in-fraestructura genérica común que puede ser aprovechada por todos ellos.

Dicha infraestructura genérica aporta ciertas facilidades base, como puede ser gestión deusuarios, gestión de experimentos, gestión de autenticación, balanceo de carga, o fede-ración. A partir de dicha infraestructura, experimentos concretos proveen tipos concretosde 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 relacio-nados 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 deWeblab-Deusto.

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 unaplaca FPGA e interactuar con ella, y que serán descritos en más detalle más adelan-te).

Podemos ver también experimentos PIC, que permiten grabar programas en un una placadotada de un microcontrolador.

Existen además experimentos más .exóticos”, como pueden ser los acuáticos, que per-miten observar y monitorizar un acuario real, así como controlar (de forma limitada) laalimentación e iluminación de los peces, o como la incubadora, que permite monitorizarel 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 la-boratorios 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 so-portan cualquier navegador (Chrome, Explorer, Mozilla, Opera, Safari…). Pueden tam-bién ser usados desde cualquier sistema operativo (Linux, Windows…) e incluso desdeprácticamente cualquier dispositivo (ordenadores de sobremesa, portátiles, tablets, mó-viles…).

Para la mayoria de experimentos los usuarios no necesitan instalar nada en sus disposi-tivos, y gracias a ello no hay problemas de seguridad para los usuarios. Weblab-Deustoestá diseñado para ser fácilmente extensible. Es decir, por diseño, trata de que sea ra-zonablemente sencilla la creación de nuevos experimentos.

54

PROYECTO FIN DE CARRERA

Un “experimento” de Weblab-Deusto se compone de dos grandes partes. Un cliente, yun servidor. El cliente en general será Web, si bien se soporta prácticamente cualquiertecnología. El cliente de la mayoría de experimentos actualmente disponibles está creadoen GWT (Google Web Toolkit).

Otras opciones son, por ejemplo, usar Adobe Flash o Java Applets. Tras la realizacióndel proyecto que en este documento se describe, será también posible usar directamenteJavaScript nativo.

El servidor de experimento puede ser desarrollado también en diversas tecnologías. Lohabitual es desarrollarlo en Python. Sin embargo, existen librerías que dan soporte aotras tecnologías. Es posible, por ejemplo, utilizar C#, Java o, tras la realización de esteproyecto, 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 microserverde 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 infraestructurade laboratorios remotos comoWeblab-Deusto es aportar ciertas características genéricasque 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 ya la vez delicado. Por eso, se hace necesario restringir en ocasiones el acceso, o al menoslimitarlo. Weblab-Deusto se encarga de gestionar los usuarios, reconociendo diversostipos, tales como usuarios registrados explícitamente en la base de datos, usuarios de launiversidad (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 ciertaseguridad. Dependiendo del tipo de usuario, la autenticación será de un modo u otro. Enel 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ónmediante 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 hardwaretambién se incrementa. Weblab-Deusto facilita la escalabilidad, soportando clústers for-mados por un número básicamente ilimitado de equipos individuales, y distribuyendo alos usuarios entre ellos de forma apropiada, y compartiendo los recursos físicos (talescomo 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 esespecialmente cierto cuando el sistema es utilizado, por ejemplo, en una clase convencio-nal. En algunos experimentos el uso simultáneo será posible, en otros no. En algunos delos primeros, el número de usuarios simultáneos estará limitado. Todo esto hace necesa-rio un sistema considerablemente complejo de gestión de colas, del cual Weblab-Deustose 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ónpermite, principalmente, acceder a experimentos que están alojados en una instancia dellaboratorio remoto diferente. Por ejemplo, mediante federación, el laboratorio remoto dela Universidad de Deusto podría acceder a un experimento hospedado por el laboratorioremoto del MIT.

56

PROYECTO FIN DE CARRERA

También resuelve otro problema. Weblab-Deusto es código abierto, y cualquier personao institución es libre de crear su propia instancia. Sin embargo, en la práctica, el coste decrear experimentos y de mantenerlos puede ser elevado, ya que además del manteni-miento convencional de los servidores se tiende a requerir equipamiento hardware paracada experimento.

Para muchas instituciones de tamaño pequeño o medio, el tener un laboratorio remotopropio, con su hardware correspondiente, está en la práctica fuera de su alcance. Esposible, 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 supropia 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 otrosentornos, incluyendo LMS (Learning Management Systems) como puede ser Moodle.Mediante esta característica, cualquier experimento de Weblab-Deusto pasa a ser auto-máticamente accesible desde Facebook u otros (suponiendo por supuesto que el usuariotenga 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 comoWindows. 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 dependientedel experimento concreto.

57

4. TECNOLOGÍAS

Por ejemplo, un experimento FPGA requiere:

Una placa FPGA, provista de LEDs y de los mecanismos necesarios para hacerlaprogramable remotamente.

Una placa controladora PIC, que se utiliza para gestionar la grabación, trasladar lasentradas 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 ala 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 es-pecíficamente para hospedar experimentos. Esta caja, que ha ganado premios, se hadesplegado en varias universidades, incluyendo el MIT (EE.UU.).

Si bien el hardware concreto dependerá del experimento, si que existen ciertos elementosque tienden a utilizarse en varios.

Uno de éstos es la propia caja, que debido a sus especiales características resulta útilpara muchos experimentos, particularmente aquellos basados en placas electrónicas.En prácticamente cualquier experimento también tendremos una o varias Webcam, quepermitan visualizarlo remotamente, y un FitPC o similar, que permita controlar el experi-mento.

58

PROYECTO FIN DE CARRERA

4.2.5 Características técnicas software

En el desarrollo deWeblab-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ándesarrollados en Python.

El cliente, por el contrario, está desarrollado en GWT (Google Web Toolkit). Los clientesespecíficos de los experimentos utilizan también en su mayor parte GWT, aunque hayalgunos 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 deun modo u otro han intervenido en el desarrollo de este proyecto o que tienen relacióndirecta con él, y que son por tanto relevantes.

4.3.1 VHDL

VHDL es un acrónimo de (VHSIC Hardware Description Language). Como su nombreindica, es un lenguaje de descripción de hardware. Se utiliza para describir la lógica desistemas digitales (o de señal mixta). Se suele utilizar como alternativa a Verilog (otrolenguaje de descripción de hardware) en dispositivos tales como FPGAs (Field Program-mable Gate Array).

VHDL es el lenguaje que esperan recibir experimentos tales comoWeblab-Deusto-FPGA,directamente relacionados con el proyecto descrito en este documento. Los archivosVHDL tienden a tener la terminación VHD.

4.3.2 BITSTREAM

BITSTREAM hace referencia a un formato binario de archivo, que contiene una descrip-ció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ógicautilizando un lenguaje de relativo alto nivel, como VHDL o Verilog. Posteriormente, a par-tir de dichos archivos fuente y de un archivo de restricciones (UCF), sintetizan un archivoBITSTREAM.

Los archivos BITSTREAM contienen tanto la lógica como el mapeo de puertos (vincula-ción de cada entrada y salida física a sus equivalentes lógicos) y puede ser directamentegrabado 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 contienenrestricciones. En la práctica, las restricciones más notables son aquellas que vinculan lasentradas 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

Figura 4.16.: Logotipo deXilinx Inc. [23]

Xilinx ISE (Integrated Software Environment) es una herra-mienta software desarrollada por Xilinx para crear y sinteti-zar diseños HDL. Permite, entre otras muchas funcionalida-des, traducir de la lógica de alto nivel en VHDL al archivoBITSTREAM que puede ser grabado físicamente en las pla-cas.

El software tiene un tamaño considerablemente grande (másde 6 gigabytes), y requiere de registro para su uso.

Contiene utilidades de línea de comandos, que permiten su utilización programática. Trasla finalización de este proyecto, Weblab-Deusto contendrá dichas herramientas en unode sus servidores, y las utilizará para sintetizar código VHDL provisto por usuarios remo-tos, que después grabará automáticamente en una placa física para su posterior prue-ba.

4.3.5 FPGA

Figura 4.17.: DispositivoFPGA de Xilinx[23]

Un FPGA (Field Programmable Gate Array) es un circuito in-tegrado configurable tras su manufactura (de donde le vieneel nombre). Es decir, su configuración puede ser especifi-cada mediante un lenguaje de definición de hardware, y, dehecho, por regla general puede ser especificada varias ve-ces.

Tienen la ventaja de que son por esto muy flexibles. Puestoque su comportamiento puede especificarse, resultan másbaratos que un dispositivo diseñado para un propósito es-pecífico, como son los ASIC (application-specific integratedcircuit). Gracias a su diseño, sin embargo, su eficiencia tiende a ser superior a la de unmicrocontrolador, y comparable a la de dichos dispostitivos ASIC.

Esto los hace idóneos y económicos para muchos procesos de control, o para la fabrica-ción de prototipos.

Uno de los experimentos más notables de Weblab-Deusto es Weblab-Deusto-FPGA, unexperimento que precisamente está basado en una placa FPGA. En dicho experimento,

60

PROYECTO FIN DE CARRERA

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 compo-nentes, unos LEDs que actúan como salidas), e interactuar con ella, todo a través de unaWebcam 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 compi-lador. 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 mo-dernos como Visual Studio.

Desafortunadamente, debido al uso de VCL (que se detallará más adelante), no es po-sible la utilización de uno de estos entornos con Boole-Deusto, sin cambios extremada-mente 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 (RapidApplication Development), orientados al desarrollo rápido de aplicaciones con ventanashaciendo 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 Borlandcomo tal ya no existe, si bien existen versiones más o menos modernizadas de sus he-rramientas y de la VCL (que desafortunadamente, tampoco son realmente compatiblescon Boole-Deusto).

4.4.2 VCL

VCL (Visual Components Library) es una librería de componentes propietaria de Bor-land.

Tanto su producto de original de Delphi, como su producto derivado C++ Builder, hacenuso 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 conceptualmentesemejantes, como pueden ser Winforms (de Microsoft), WPF (también de Microsoft) oincluso Qt.

Originalmente, VCL competía con MFC (Microsoft Foundation Classes), que tampoco esdemasiado utilizada en la actualidad.

VCL se utiliza para toda la interfaz de Boole-Deusto, y sus clases tienen también presen-cia 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 granparte de la lógica del programa), y hace que visualmente esté necesariamente algo limi-tado con respecto a programas más modernos.

4.4.3 Python

Figura 4.18.: Logotipo de Python [38]

Python es un lenguaje de programación de propó-sito general, de muy alto nivel. Soporta diversos pa-radigmas, incluyendo la programación orientada aobjetos, y es un lenguaje dinámico.

Pone especial énfasis en su legibilidad, permitien-do en general expresar la lógica del programa encomparativamente pocas líneas, y siendo de él ca-racterístico el hecho de que los espacios y la indentación tienen significado (se utilizanpara separar sentencias, definir el ámbito, etc).

Tradicionalmente ha sido utilizado mucho como lenguaje de scripts, pero se utiliza tam-bién en muchos otros contextos.

Existen varias implementaciones de Python, basadas en distintos entornos. La imple-mentación más común es CPython, desarrollada en C.

Otras implementaciones populares son IronPython, desarrollada para el entorno .NET, oJython, desarrollada para la máquina virtual de Java.

El núcleo deWeblab-Deusto (el servidor) está íntegramente desarrollado en Python.

4.4.4 JavaScript

JavaScript es un lenguaje de programación dinámico, generalmente interpretado. Es tra-dicionalmente un lenguaje propio de los navegadores. Esto hace que en la actualidadsea quizás el lenguaje de programación más ubicuo (prácticamente cualquier máquinaactual 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, quemediante scripts en el lado del cliente fueran capaces de interactuar con el usuario, crean-do 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 ellenguaje de programación C. Puede ser, sin embargo, considerado un lenguaje multi-paradigma, 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 muchasaplicaciones como lenguaje de scripting, e incluso como lenguaje de scripting en el ladodel servidor a través de entornos como node.js, que será también reseñado en apartadosposteriores de ésta sección.

62

PROYECTO FIN DE CARRERA

Con respecto al lenguaje en sí, uno de los aspectos más notables es probablemente quetiende a ser totalmente asíncrono.

Es decir, por diseño, al margen de optimizaciones internas de los intérpretes, las funcio-nes JavaScript siempre se ejecutan al menos conceptualmente en un solo hilo. Aque-llas tareas que requieren de un tiempo de ejecución se manejan siempre mediante call-backs.

La popularidad de JavaScript en los últimos tiempos ha ido en aumento, y los intérpreteshan ido mejorando progresivamente. En el momento de escribir esto, los intérpretes másavanzados 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, paraser 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 delenguajes nativos.

Como parte de este proyecto, se añadirá a Weblab-Deusto la capacidad de crear deforma sencilla experimentos nuevos en JavaScript, tanto en cliente como en servidor.La creación de experimentos en JavaScript supondrá ventajas considerables, que sedetallarán en otras secciones de este documento, entre las que se encuentran el hechode no necesitar recompilar para añadir o probar experimentos nuevos.

4.4.5 GWT (Google Web Toolkit)

Figura 4.19.: Logotipo deGWT (GoogleWeb Toolkit)[18]

GWT (Gooble Web Toolkit) es un conjunto de herramientasde código abierto que permite la creación de aplicacionesweb 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 sernativamente ejecutado por los navegadores.

Esto tiene teóricamente varias ventajas, aunque también sehan observado inconvenientes.

4.4.5.1 Ventajas

∎ 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 lenguajeestático, para programas grandes tiende a ser más fácil de mantener, y tiende a ser máscomplicado cometer errores.

63

4. TECNOLOGÍAS

∎ Optimización

Puesto que el código Javascript es generado automáticamente, no tiene por qué ser le-gible. El código que genera GWT está optimizado para el navegador específico en el quese ejecute, y su propio comportamiento es independiente del navegador. El programadorno tiene que preocuparse (o tiene que preocuparse menos) de las diferencias entre nave-gadores. Se llevan acabo ciertos trucos que permiten una optimización adicional, comopuede ser el incrustar imágenes en el propio código Javascript para garantizar una cargamás rápida de las páginas.

∎ Herramientas

Además, GWT cuenta con una serie de herramientas adicionales que facilitan el desa-rrollo. Estas incluyen depuradores y “profilers”, que facilitan la medida del rendimientode las aplicaciones Web, e incluso editores gráficos para la interfaz Web, que permitendiseñ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 unnavegador, e inmediatamente se ejecutará. El proceso con GWT es notablemente máslento. A pesar de que provee herramientas que permitan cargar también directamente lapágina sin necesidad de compilarla previamente, el generar código JavaScript sobre lamarcha es un proceso costoso, y en la práctica lleva un tiempo considerablemente máslargo.

64

PROYECTO FIN DE CARRERA

∎ Dificultad de depuración

Si bien GWT no contiene un gran número de errores, como prácticamente cualquier soft-ware, no es perfecto. Cuando ocurre un error, puesto que termina apareciendo en unacapa de JavaScript autogenerado, tiende a ser considerablemente difícil e depurar, in-cluso 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 espe-cificación de código nativo JavaScript dentro del código fuente Java. Sin embargo, dichainterfaz es notablemente compleja de utilizar, y tiene ciertas limitaciones. Esto hace queen la práctica sea un proceso considerablemente costoso el mezclar JavaScript nativocon GWT, y por tanto, es un factor limitante cuando se desean añadir característicasJavaScript relativamente avanzadas.

Esto es particularmente cierto en aquellos casos en los que sea desea hacer uso de unalibrerí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 enJavaScript, y que tienen como objetivo facilitar la creación de aplicaciones Web asíncro-nas.

Se basa principalmente en la capacidad de realizar peticiones HTTP asíncronas, iniciadasdesde 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 nombresugeriría, por tanto, no está limitado a XML.

Esto permite a una aplicación Web cliente realizar peticiones al servidor y recuperar in-formación sobre la marcha, sin necesidad de recargar la página y por tanto de una formamucho más dinámica y eficiente.

Uno de los inconvenientes de AJAX es que si bien lo soporta cualquier navegador mo-derno de una forma u otra, no todos lo soportan de igual manera. Por eso (y por otrosmotivos) 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 esuna característica muy utilizada por WebLab, y es la tecnología que prácticamente todoslas aplicaciones cliente de los experimentos utilizan internamente para comunicarse conel servidor.

4.4.7 jQuery

65

4. TECNOLOGÍAS

Figura 4.21.: Logotipo de jQuery [24]

jQuery es una librería de JavaScript orientada a fa-cilitar en el lado cliente la creación de páginas Webdinámicas.

Entre sus características principales, están la de fa-cilitar la navegación, búsqueda y manipulación delDOM y la de facilitar el uso de AJAX.

Otra característica, quizás menos conocida pero notablemente útil y relevante para elproyecto descrito en este documento, es la de soportar “promesas”. Una “promesa” esun concepto utilizado en JavaScript y lenguajes similares que facilita la programaciónasíncrona.

En muchas ocasiones, cuando se realiza programación asíncrona, se desea encadenarcallbacks, o definir un callback que se ejecute una vez que otros callbacks hayan finali-zado.

Una “promesa” es un objeto que devuelve una función asíncrona, y que quiere decir queen el momento de retornar esa función, a pesar de que de momento su valor de retornono está disponible (ya que puesto que la función es asíncrona, aún probablemente nohaya 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 otroscallbacks 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ísticasde jQuery resultarán notablemente útiles en diversas partes, como en la creación de unalibrería que facilite la creación de experimentos Weblab basados en JavaScript, o comoen la infraestructura concreta para la creación de experimentos con modelos virtualesque también se desarrollará durante este proyecto.

4.4.8 HTML5 Canvas

Figura 4.22.: Logotipo deHTML5 [45]

El “canvas” es un elemento de HTML 5. Consiste principal-mente en un área fija de la página web, cuyo tamaño puedeser definido, en la que se puede dibujar dinámicamente através de JavaScript.

En principio, el canvas está orientado a gráficos 2D. Es po-sible dibujar formas, imágenes, etc.

También es posible utilizarlo para 3D, pero esencialmentese requiere para esto una librería 3D software, con los pro-blemas de rendimiento que esto implica.

Su utilidad principal es la de permitir gráficos relativamenteavanzados, con los que se pueden crear aplicaciones inter-

66

PROYECTO FIN DE CARRERA

activas y que pueden sustituir en gran medida a tecnologías como Flash, basadas enplugins y software propietario específico.

En el momento de escribir esto, las versiones actuales de todos los navegadores Webprincipales soportan Canvas, incluyendo a Chrome, Firefox, Opera, Safari, Internet Ex-plorer, e incluso los navegadores modernos de Android.

4.4.9 WebGL

WebGL (Web Graphics Library) es una API en JavaScript orientada a permitir gráficosinteractivos en 2D y 3D dentro de los navegadores y sin necesidad de plugins. Dichosgráficos están acelerados por hardware (por la GPU). Esto hace por tanto posibles losgrá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, seasegura de que la mayor parte de su trabajo se realice en la GPU.

Basado en OpenGL, soporta incluso características gráficas avanzadas como shadersGLSL. Si bien es una tecnologíamuy potente, es cierto que tiene algunos problemas.

Probablemente por ser bastante nueva, su soporte aun no es perfecto en todos los na-vegadores. En el momento de escribir esto, el navegador con mejor soporte es proba-blemente Chrome. También lo soportan bien Firefox, Safari y Opera, aunque InternetExplorer por defecto (sin plugins) no lo soporta aún. En principio, parece que la versión11 de IE sí añadirá soporte.

En cuanto a navegadores móviles, son menos los que de momento lo soportan. Conrespecto a Android, el navegador por defecto sólo lo soporta en ciertos fabricantes. Losoporta también la última versión de Google Chrome (aunque debe habilitarse explícita-mente) 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, yse espera que en muy poco tiempo sea soportado casi completamente por casi cualquiernavegador.

En este proyecto, WebGL será la tecnología que se utilice principalmente para la crea-ción de los modelos virtuales en los experimentos electrónicos con realidad mixta quese 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 estrictamentenecesario (aunque sí muy útil, ya que para cualquier simulación compleja Canvas sinaceleració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 unalibrería ligera, de baja complejidad.

La librería soporta varios renderers distintos, incluyendo Canvas y WebGL. El primerotiene la ventaja, como ha sido descrito anteriormente, de que lo soporta prácticamentecualquier navegador, pero no es acelerado por hardware y por tanto es notablementelento para 3D. El segundo tiene la ventaja de que es mucho más rápido y eficiente (losgráficos son acelerados por hardware y se utiliza directamente la GPU), pero no lo so-portan todos los navegadores.

En el proyecto aquí descrito, se utilizará ThreeJS en la creación de la infraestructura ne-cesaria 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 mode-los virtuales (realidad mixta) específicos.

4.4.11 Node.js

Figura 4.24.: Logotipo denode.js[30]

Node.js es un sistema basado en JavaScript que permite lautilización de éste como lenguaje de scripts en el lado servi-dor.

Basado en el motor de JavaScript V8, de Google, es nota-blemente eficiente. Una de sus características más notableses que contiene su propio servidor HTTP, de tal forma queal contrario que otras tecnologías, no depende de un servidor Web como Apache. Estoen muchas ocasiones facilita el desarrollo y despliegue y mejora la eficiencia. Siguien-do la filosofía JavaScript en la que está basado, los programas de node.js tienden a serasíncronos, basados en callbacks y eventos.

68

PROYECTO FIN DE CARRERA

A pesar de lo que inicialmente podría pensarse, node.js es notablemente eficiente y es-calable.

En el transcurso de este proyecto, se añadirá a Weblab-Deusto la capacidad de desa-rrollar servidores de experimento (lado del servidor) basados en node.js. Puesto quetambién se añadirá la capacidad de desarrollar clientes en JavaScript, esto hará que seaposible crear un experimento completo usando únicamente JavaScript, y sin necesidadde 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 docu-mentación.

69

PROYECTO FIN DE CARRERA

5. DESARROLLO

5.1 ENTORNO DE DESARROLLO

En esta sección se describen aquellas herramientas que han ayudado e intervenido enel desarrollo de este proyecto.

5.1.1 Eclipse for Java

Eclipse es un entorno de desarrollo integradomultilenguaje. De código abierto, está desa-rrollado principalmente en Java, tiene su propio compilador (ECJ), y está tradicionalmen-te orientado a desarrolladores de Java. No obstante, actualmente existen plug-ins pa-ra 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 partedel trabajo realizado en el núcleo del cliente de Weblab-Deusto, que está desarrollado enlenguaje Java en GWT (Google Web Toolkit).

Cabe notar que GWT consta de su propio plug-in de Eclipse, que permite, entre otrascosas, depurar la aplicación GWT si necesidad de realizar una compilación completa (elcódigo Java de GWT se compila a JavaScript).

5.1.2 PyDev

Figura 5.1.: Logotipo de Py-Dev [37]

PyDev es uno de esos plug-ins o entornos derivados deEclipse. En este caso, PyDev está orientado al desarrollode aplicaciones en Python.

PyDev es uno de los entornos de desarrollo Python másavanzados. Soporta mejor que la mayoría característicasque típicamente están bastante limitadas en lenguajes di-námicos, como son el autocompletado o la documentaciónen 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ándary condicionales), y la vigilancia de variables y expresiones.

En este proyecto, se ha utilizado PyDev para el desarrollo del trabajo realizado en losservidores 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 lacreación (en el lado del servidor) de las simulaciones que aportan realidad mixta a losexperimentos.

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 diver-sos lenguajes, entre los que se incluyen C, C++, lenguajes del entorno .NET como puedenser 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 suscapacidades de desarrollo JavaScript, siendo hoy en día uno de los entornosmás avanza-dos a este respecto: se distribuye con su propio intérprete parcial de propósito específicode JavaScript. Esto permite que su “IntelliSense”, la denominación de Microsoft para lascapacidades de auto-completado de su entorno, sea particularmente informativo, útil, ypreciso.

Por este motivo, Visual Studio ha sido el entorno elegido en el proyecto para la realizaciónde aquellas partes que involucrasen a JavaScript.

Estas partes son, entre otras:

La librería de Weblab en JavaScript para el desarrollo de clientes de experimentoen JavaScript nativo.

La librería de Weblab en JavaScript y node.js para el desarrollo de servidores deexperimento en JavaScript.

La infraestructura para la realización de modelos virtuales y simulaciones con Th-reeJS (formada principalmente por WorldLoader.js, una pequeña librería que per-mite 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 realidadmixtaa los experimentos, como lo es la simulación 3D del tanque de agua.

72

PROYECTO FIN DE CARRERA

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 enScintilla, está escrito en C++.

Pretende a ser una versión mucho más potente de “notepad”, pero manteniendo el máxi-mo 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 losque abrir o utilizar un entorno de desarrollo completo no se ha considerado necesario, yera más simple editar el archivo sencillamente utilizando un editor de texto como Note-pad++.

Entre muchos otros usos menores, destacan:

La creación de documentación y manuales, realizada en archivos locales con Note-pad++. Dicha documentación ha sido originalmente creada con Sphinx, que utilizauna 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ácticamen-te cualquier entorno UNIX o basado en UNIX.

Los servidores en producción deWeblab 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 laconfiguración de las mejoras y modificaciones realizadas.

Esto incluye parte de la instalación del entorno basado en Xilinx que permitiese sintetizararchivos VHDL en el servidor, así como la edición de los múltiples archivos de configura-ció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 sibien es en general evitable en el entorno de producción, ha resultado en unas pocasocasiones necesaria.

Ha sido también utilizado como la herramienta principal para la consulta de logs y regis-tros 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 com-plejidad como es el propio kernel de Linux.

Hoy en día Git se ha desarrollado hasta ser uno de los sistemas de control de versionesmás populares, considerado en general como una alternativa superior a sistemas deversiones 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 probablementeTortoiseGit. El propio Eclipse tiene también su propio Plugin de Git con interfaz gráfica. Enel desarrollo del proyecto Git ha tenido particular importancia. El repositorio de Weblab esen la actualidad un repositorio Git, basado en Github. Todas las modificaciones realizadasa Weblab se han hecho sobre ese repositorio (interviniendo por supuesto un fork local yuno 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 Boole-Deusto, que originalmente estaba hospedado en un repositorio Svn sin información his-tórica real de versiones.

74

PROYECTO FIN DE CARRERA

5.1.7 GitHub

GitHub es un servicio web orientado a hospedar proyectos de software que usan Git comosistema de control de versiones. A pesar de que desafortunadamente, GitHub en sí noes libre (de código abierto), sí que favorece a tales proyectos, siendo los repositorios ylas cuentas para ellos gratuitas. En los últimos tiempos se ha convertido de hecho en unode 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 unrepositorio Git, es la fácil consulta online de los cambios recientes y commits, de losusuarios que han intervenido en el desarrollo, de estadísticas, etc. También integra unsistema 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 deeste proyecto, también ha pasado a ser hospedado en GitHub [3].

Podemos concluir, por tanto, que todo el trabajo realizado durante este proyecto, ya seaaplicado a Weblab-Deusto o a Boole-Deusto, se ha realizado sobre uno de los dos repo-sitorios 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 algunosde 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 con-creto, 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 lapresencia de scripts de todo tipo orientados a tareas específicas.

Si bien en entornos de diseño gráfico profesionales existen herramientas más frecuen-temente utilizadas, como 3D Studio o Maya, la calidad y funcionalidad de Blender esbastante comparable (y de hecho, se ha utilizado también en ciertas películas de anima-ció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 satisfac-toriamente para crear de forma relativamente sencilla modelos de calidad suficiente. Enconcreto, se ha utilizado para crear prácticamente todo el entorno 3D del experimentocon la simulación virtual de un tanque de agua, y se espera que sea utilizado en el futuropara la creación de otros entornos virtuales.

Cabe notar que para la exportación de modelos a un formato más adecuado a ThreeJSse 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 esteproyecto

76

PROYECTO FIN DE CARRERA

5.2 DETALLES DEL DESARROLLO

En esta sección se describirá con cierto detalle y desde una perspectiva técnica el proce-so de desarrollo de los elementos y componentes principales que ha tenido lugar duranteel proyecto.

Puesto que el proyecto involucra a varios elementos relativamente independientes entresi, se divide esta sección en subsecciones, dedicadas cada una a uno de esos elemen-tos.

5.2.1 Boole-Deusto

5.2.1.1 Introducción

Como se ha mencionado en secciones anteriores de este documento, Boole-Deusto esun software relativamente antiguo. Desarrollado como un proyecto de código abierto utili-zando Borland C++ Builder, su primera versión fue publicada en el año 2000. Esto implicaque, 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 serlocalizados) ni versiones anteriores a la usada ni documentación de desarrollo.

Puesto que para llevar acabo los objetivos de este proyecto se han requerido modifica-ciones significativas a Boole-Deusto, estos dos últimos hechos han conllevado ciertasdificultades.

5.2.1.2 Dificultades de migración del entorno

Para poder realizar las extensiones y modificaciones requeridas con una cierta comodi-dad se considero la posibilidad de actualizar el entorno a uno más moderno, como podríaser Embarcadero C++ Builder.

Desafortunadamente, surgieron dos problemas que lo impidieron:

Boole-Deusto utiliza un sistema de localizaciones basado en DLLs. Las traduccio-nes se definen en la IDE utilizando diversas herramientas, y automáticamente secrea un proyecto Borland DLL para cada lenguaje a traducir. Tras la carga del pro-grama en su lenguaje base, automáticamente se carga el DLL correspondiente auno 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 noestá disponible, puesto que el enfoque conllevaba varias limitaciones y era en lamayoría de los casos poco conveniente. Hoy en día, se sugiere utilizar otros tiposde métodos para internacionalizar las aplicaciones.

Reescribir el sistema de localizaciones requeriría una cantidad de tiempo y esfuerzonotable, demodo 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 soportelimitado de UNICODE. Posiblemente por este motivo, su versión de la VCL, lascadenas, macros, etc. están por defecto orientadas a ASCII.

En las versiones modernas, por el contrario, UNICODE ha pasado a ser la opciónpor defecto, y se han producido numerosos cambios relacionados.

Debido al alto número de operaciones relacionadas con estos métodos que se lle-van acabo en Boole-Deusto, el tiempo requerido para actualizar estos aspectoshubiera sido considerablemente elevado.

Boole-Deusto depende de una versión antigua del framework de construcción deintérpretes ANTLR.

Cambiar de entorno hubiera implicado también conseguir una versión moderna detal framework y realizar las adaptaciones oportunas.

Si bien hubiera sido factible, de nuevo hubiera supuesto una cantidad de tiempoconsiderable.

Por todos estos motivos, se ha considerado más apropiado a las circunstancias del pro-yecto conservar el entorno original de desarrollo, optando por resolver de otras formaslos 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 actualizarel entorno a uno moderno.

Sin embargo, Borland C++ Builder, ejecutado sobre un Windows 7 trabajando sobreBoole-Deusto, causaba problemas significativos:

Errores al inicio

Tan sólo iniciar Borland Builder es suficiente para que aparezca una cierta canti-dad de errores sobre archivos no encontrados. Si bien el entorno en si se cargasatisfactoriamente 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únla documentación de Borland y según capturas de pantalla), ejecutándose ahorano estaban. Unos de estos menús eran los relacionados con traducciones, particu-larmente importantes para Boole-Deusto.

Tras fracasar los intentos habituales de solucionar estos errores, como pueden ser ins-talar y ejecutar la aplicación en modo administrador o probar los diversos ”modos decompatibilidad”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

PROYECTO FIN DE CARRERA

De estemodo, se consiguieron resolver todos los problemas listados anteriormente.

La mayor parte del desarrollo de Boole-Deusto que se ha realizado durante este proyectose ha llevado acabo sobre esta máquina virtual.

Figura 5.6.: Entorno Windows XP virtual utilizado para la modificación y extensión de Boole-Deusto

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ódi-go VHDL tenían ciertas carencias o fallos menores. Se ha comenzado arreglando talesfallos.

La funcionalidad de Boole-Deusto está dividida en dos modos. El modo combinacional yel modo secuencial.

∎ Modo combinacional

Con lo que respecta a la interfaz, éste ha sido el modo que más trabajo ha requeri-do.

Se ha añadido un modo Weblab. Cuando está activo, la forma de seleccionar entradas ysalidas 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 deuna 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 elusuario desea probar su programa, generar el código VHDL especifico paraWeblab (paralo cual deberá encontrarse precisamente en modo Weblab) y para abrir el experimentoFPGA en un navegador.

∎ Modo secuencial

La interfaz de usuario del modo secuencial ha requerido menos extensiones. Puestoque en este modo hemos considerado más conveniente que los nombres de entradas ysalidas sean fijos y sean asignados automáticamente, sólo ha sido necesario proveer losmecanismos necesarios para seleccionar un reloj.

El reloj es un elemento necesario de un autómata. Con cada flanco de reloj, el estado delautó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 producirflancos 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 aquellosrelacionados con la generación de código.

Si bien Boole-Deusto ha sido originalmente capaz de generar código VHDL tanto paraun sistema combinacional como para una autómata, dicho código VHDL es genérico yno puede ser realmente usado tal cual.

Para satisfacer las necesidades de este proyecto era necesario que Boole-Deusto fuesecapaz de generar código VHDL del circuito en cuestión que fuese directamente grabableen una placa hardware real de Weblab-Deusto.

Con vistas a ésto, se ha rediseñado parcialmente el sistema de generación de códi-go.

El modo anterior se ha mantenido. Ahora se soporta también, sin embargo, la genera-ción de código VHDL específico para Weblab-Deusto. Este código, que tiende a ser algomás complejo que el código genérico, no requiere de ninguna modificación manual parafuncionar.

Para que esto sea posible, se utiliza un encabezado predefinido que incluye todas lasentradas y salidas de Weblab-Deusto-FPGA. Estas entradas se corresponden con las de

80

PROYECTO FIN DE CARRERA

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 originalmenterecibir como entrada inicial del usuario un archivo BITSTREAM. Esto es un archivo bina-rio, obtenido tras un proceso de síntesis3 notablemente complejo a partir de un VHDL yun UCF.

Tradicionalmente, los usuarios llevaban acabo este procedimiento de síntesis en sus pro-pias máquinas. Para ello, cada usuario debía instalar la suite de software Xilinx ISE, con-figurarla 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 ventajasde WebLab-Deusto, que es la de gracias a su arquitectura Web poder ser utilizadodesde cualquier sitio necesitando tan solo un navegador.

El software Xilinx ISE no es un software menor. En su versión estándar ocupa alre-dedor de 6 gigas. Si bien las conexiones a Internet hoy en día tienden a ser relati-vamente rápidas, sigue siendo un requisito de descarga y de espacio en disco muyalto.

El software Xilinx ISE requiere registro y licencia. A pesar de ser gratuito para lamayor parte de usuarios, añade más pasos aún a un proceso de instalación ya depor si largo.

Se requiere configuración específica. Xilinx ISE está orientado a muchos dispositi-vos distintos. El usuario no puede sencillamente crear un proyecto nuevo y esperarque funcione con la placa específica de Weblab. Debe configurar diversos paráme-tros, no funcionando correctamente si no lo hace.

Se necesita un archivo UCF. Para generar un BITSTREAM, se necesita el VHDLque describe la lógica, y el UCF que define cómo se aplica la lógica a la placa es-pecífica. Si el BITSTREAM lo genera el propio usuario, también debe contar con elUCF, y por tanto deberá previamente descargarlo aparte de algún sitio, y configurarsu proyecto para usarlo.

1User Constraints File. Estos archivos de restricciones son necesarios para sintetizar VHDL, ya quemapeanlas entradas/salidas lógicas, definidas en el VHDL, con las entradas/salidas físicas (los pines) de la placahardware.

2En el propio servidor de Weblab-Deusto existen varios UCF predefinidos. Dependiendo de ciertas circuns-tancias, como el reloj elegido, se selecciona uno u otro. El UCF no llega a estar nunca en el cliente, sóloen el servidor, ya que sólo es requerido para la compilación. Esto aporta seguridad adicional.

3El proceso de síntesis es aquel mediante el cual el comportamiento definido para un circuito de formaabstracta se convierte en un diseño hardware real, implementado mediante puertas lógicas o en algunoscasos componentes especiales adicionales.

81

5. DESARROLLO

Es poco seguro para WebLab. El UCF, sobre el cual el usuario tiene control, es elque define el mapeo de pines de la placa física. Si el mapeo es incorrecto, espe-cialmente si se hace a propósito, podría llegar a ser posible causer daños físicos ala placa.

Hace que el uso de Weblab-Deusto-FPGA sea imposible en móviles, tablets y dis-positivos similares.

Por todos estos motivos, durante la ejecución de este proyecto se ha añadido a WebLab-Deusto-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 XilinxISE esté en el servidor y sea controlable por WebLab. Puesto que Xilinx ISE proveé unconjunto de herramientas de consola, ésto ha sido razonablemente sencillo.

Se ha procedido a crear un sistema capaz de interactuar con dichas herramientas bajopetición de WebLab, sintetizando código arbitrario (que en el caso concreto aportará elusuario 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 apro-piada para WebLab.

Además, se han creado varios archivos UCF específicos con la placa física de We-bLab.

El motivo de que exista más de un UCF es el número de relojes disponible. Como seha especificado en secciones anteriores, el usuario debe poder elegir entre cuatro re-lojes diferentes (interno, externo, interruptor, botón). Cada UCF contiene restriccionesligeramente 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 unVHDL como entrada, el sistema no tendría en principio forma de conocer qué reloj deseael usuario utilizar y por tanto qué archivo UCF utilizar.

Este problema se ha solucionado implementando soporte para un comando específico depreprocesado dentro del VHDL. Cuando WebLab-Deusto recibe un archivo VHDL, buscainteriormente en su código dicho comando. Si lo encuentra, tal comando es el que indicael reloj a utilizar.

Este comando puede ser introducido a mano por el usuario, pero también es introducidoautomá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 esun comando especial incluido dentro de un comentario VHDL.

1 -- @@@CLOCK:WEBLAB@@@2 library IEEE;3 use IEEE.STD_LOGIC_1164.ALL;

82

PROYECTO FIN DE CARRERA

4 use IEEE.STD_LOGIC_ARITH.ALL;5 use IEEE.STD_LOGIC_UNSIGNED.ALL;6

7 entity base is8 Port (9

10 inicio : in std_logic;11 clk : in std_logic;12

13 led0 : inout std_logic;14 led1 : inout std_logic;15 led2 : inout std_logic;16

17 -- [...]18

19 swi7 : in std_logic;20 swi8 : in std_logic;21 swi9 : in std_logic22 );23 end base;24

25 architecture behavioral of base is26

27 begin28 led0 <= swi6;29 led1 <= swi5;30 led2 <= swi4;31 led3 <= 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 experimentosen JavaScript

5.2.3.1 Motivación

En la actualidad, la mayor parte de servidores de experimento están creados en Pyt-hon.

El motivo principal de ésto es, probablemente, que los servidores de WebLab (el núcleode 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 comuni-carse 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 lacreación de servidores de experimento mediante JavaScript.

5.2.3.2 Implementación

A pesar de que JavaScript es tradicionalmente un lenguaje orientado a navegadoresWeby por tanto a aplicaciones cliente, en la actualidad está ganando una gran popularidadcomo lenguaje de lado servidor.

Para ésto, se ha utilizado en este proyecto (y suele utilizarse en general) la tecnologíaNodejs.

Nodejs está basado en el motor V85 de Google. Es notablemente ligero y eficiente, con-tiene su propio servidor HTTP y está orientado a la programación asíncrona.

La librería deWeblab-NodeJS desarrollada durante este proyecto hace uso de XML-RPCpara proveer a los desarrolladores de experimentos una interfaz totalmente funcional ysencilla y conveniente de utilizar.

5.2.4 WebLab-Deusto: Infraestructura de creación de clientes de experimentos enJavaScript

5.2.4.1 Precedentes

Otro de los objetivos del proyecto ha sido mejorar el potencial de los experimentos deWebLab-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 AdobeFlash.

∎ GWT (Google Web Toolkit)

Puesto que el cliente de WebLab-Deusto (su núcleo) está creado en GWT, este ha sidotradicionalmente el método más recomendado para crear experimentos nuevos. Esto im-plica crear el experimento en Java, que es eventualmente compilado por las herramientasGWT a JavaScript.

4XML-RPC es un estándar que describe una tecnología de llamada a procedimiento remoto. Se caracterizapor estar orientada a procedimientos y no a objetos, por ser particularmente sencilla, por estar basadaen XML, y por existir librerías que la soportan en la mayor parte de lenguajes y entornos.

5V8 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ónJust In Time, de tal modo que antes de ejecutarse su código suele compilarse a código nativo. Esto lohace comparable en velocidad con lenguajes nativos como C. Se detalla más información en la secciónde tecnologías.

84

PROYECTO FIN DE CARRERA

La ventaja de éste método es que la integración con el resto de WebLab es muy alta, yque, puesto que eventualmente se compila a JavaScript, si está bien hecho el resultadodesde el punto de vista del usuario es bueno, siendo un código JavaScript particualrmenteeficiente, y siendo utilizable desde cualquier navegador, sin necesidad de plugins.

Tiene sin embargo ciertas desventajas para el desarrollador. A pesar de ser una tecno-logía de Google, no es particularmente conocida. Ciertamente, entre la comunidad dedesarrolladores Web es mucho menos conocido que el propio JavaScript que genera. Enocasiones, además, desarrollar en Java, y especialmente en un Java bastante especialcomo es el de GWT (debido a las limitaciones que supone el tener que ser eventualmen-te compilado a JavaScript) el proceso de desarrollo puede ser lento y poco satisfactorio.También existen dificultades integrando las aplicaciones GWT con JavaScript, con libre-rías preexistentes o con otras tecnologías.

∎ Adobe Flash

Desde hace relativamente poco tiempo, WebLab-Deusto soporta también Adobe Flashcomo uno de sus métodos para crear experimentos. Existen algunos experimentos nota-bles que dependen de Adobe Flash, como puede ser VISIR.

Adobe Flash en algunos entornos es una tecnología muy conocida, de modo que esadecuada para ciertos desarrolladores. Sin embargo, a partir de la aparición de HTML5,está perdiendo rápidamente popularidad, ya que conllevamú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 serequiere 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 sencillamenteno desean instalar plugins en su navegador, por motivos de seguridad, conveniencia, uotras preferencias.

5.2.4.2 Motivación

La capacidad de poder crear experimentos en JavaScript nativo ventajas notables conrespecto a otros métodos.

Es importante tener en cuenta, además, que los dos métodos anteriores siguen por su-puesto estando disponibles. Es elección del desarrollador de un experimento el utilizarun 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, es-pecialmente desarrolladores Web, e incluso en caso de no ser conocido en pro-fundidaz es un lenguaje relativamente sencillo, y puede ser aprendido de formarelativamente rápida.

85

5. DESARROLLO

JavaScript es extremadamente ubicuo. Todo ordenador con acceso a Internettiende a disponer de al menos un navegador Web, y todos los navegadores Webprincipales soportan JavaScript. No se requieren plugins adicionales, y generalmen-te está habilitado por defecto. Funciona en cualquier dispositivo, incluyendomóvilesy tablets.

Existe un gran número de librerías JavaScript. Desde frameworks e interfacespara aplicaciones Web, hasta motores gráficos. Los experimentos en JavaScriptnativo pueden acceder directamente a dichas librarías.

JavaScript, al contrario que tecnologías como Flash o GWT, no necesita com-pilación. El desarrollo por tanto tiende a ser más rápido. Sólo con recargar el nave-gador es suficiente para probar cualquier cambio. Además, prácticamente cualquiernavegador dispone de herramientas avanzadas para depuración de código JavaS-cript, como las DevTools de Chrome, o FireBug de Firefox.

Ha existido también una ventaja concreta más para este proyecto. Uno de sus objeti-vos era la creación de experimentos dotados de realidad mixta. Esto es, experimentoscapaces de mostrar un modelo de simulación idealmente tridimensional.

Para ésto, GWT o Flash claramente no eran opciones adecuadas. Se han consideradobrevemente 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 supe-riores, JavaScript y HTML5 han sido considerados como la mejor opción, por algunos delos motivos anteriormente listados. Están disponibles en cualquier dispositivo, los gráfi-cos son de calidad muy aceptable (especialmente conWebGL), y no se requieren pluginsni aplicaciones aparta, lo que aumenta la conveniencia y la seguridad.

5.2.4.3 Implementación

∎ Vista general

El núcleo del cliente de WebLab-Deusto es GWT. A partir de él están implementadas lamayoría de las demás tecnologíasWeb soportadas, incluidos Flash y Java Applets.

El objetivo de este diseño es que los experimentos en este tipo de tecnologías puedanser independientemente desarrollados. Es decir, que sea posible crear el experimento yluego integrarlo en el sistema sin necesidad de recompilar GWT.

Para crear un experimento Flash, por ejemplo, sólo es necesario, primero, crear el SWFque contiene el experimento. Una vez hecho ésto, recompilar el cliente GWT no hacefalta. Basta con configurar el experimento, especificando en un archivo de configuraciónel 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 desa-rrollador del experimento, es el que se ha seguido con JavaScript.

86

PROYECTO FIN DE CARRERA

Tal y como se ha implementado, para crear un experimento JavaScript sólo hace falta unHTML 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 experimentoFlash, y el experimento es mostrado por WebLab en un iframe, que sencillamente refe-rencia al HTML especificado (o, en el caso del archivo JavaScript, lo incluye dentro deun archivo HTML creado ex-profeso).

1 "js" : [2 {3 "experiment.name" : "jsdummy",4 "experiment.category" : "Dummy experiments",5 "experiment.picture" : "/img/experiments/java.jpg",6 "width" : 500,7 "height" : 350,8 //"js.file" : "test.js",9 "provide.file.upload" : true,

10 // If we use an html.file as base, we cannot use a js.file.11 // (Though of course, we may include that js file from our html ⤦

Ç file).12 "html.file" : "jstest.html"13 },14 {15 "experiment.name" : "jsfpga",16 "experiment.category" : "FPGA experiments",17 "experiment.picture" : "/img/experiments/xilinx.jpg",18 "width" : 800,19 "height" : 600,20 "provide.file.upload" : true,21 "html.file" : "jsxilinx/jsxilinx.html"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 elexperimento en HTML/JavaScript, y añadirlo como se muestra.

∎ API de WebLab-JavaScript

Por supuesto, el experimento que cree el desarrollador del experimento necesitará inter-actuar 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 uncomando de texto, y recibe una respuesta.

Enviar archivo: El cliente del experimento envía al servidor del experimento un ar-chivo, y recibe una respuesta.

Recibir notificación de comienzo de experimento: El cliente del experimento se car-ga 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 in-formación inicial que dependiendo del experimento se requiera.

Recibir notificación de tiempo restante: El cliente del experimento deberá conocercuánto tiempo queda de experimento. Esto suele recibirse al comienzo de un expe-rimento, y depende generalmente de los privilegios del usuario que esté utilizandoel experimento.

Recibir notificación de finalización de experimento: El cliente del experimento debesaber cuándo el experimento ha terminado, y por tanto no pueden ser enviadosmá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 ca-pacidad de hacer que un experimento termine antes de tiempo.

En realidad, esta interacción está codificada en el cliente GWT. Para que sea accesiblea los experimentos JavaScript durante el desarrollo de este proyecto se ha hecho losiguiente:

En GWT, se ha creado una sencilla interfaz JSNI6 que publica tal funcionalidad. Lasfunciones que publica son de difícil acceso y uso.

Para permitir un uso cómodo a los desarrolladores de experimentos, se ha creadouna pseudoclase7 JavaScript que encapsula toda la comunicación con WebLab-Deusto. Esta API ha recibido el nombre de WeblabJS.

5.2.5 WebLab-Deusto: Infraestructura de modelos virtuales en JavaScript y Th-reeJS

5.2.5.1 Motivación

Uno de los grandes objetivos de este proyecto es dotar a WebLab de las capacidadesnecesarias para poder incorporar a algunos de sus actuales experimentos actuales (ocrear experimentos nuevos) realidad mixta. Es decir, incorporar a estos experimentos unmodelo virtual.

Este modelo virtual será en general distinto dependiendo del experimento y su compleji-dad 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 unalínea de producción.

En todos estos casos, el usuario del experimento definiría la lógica para una placa FP-GA que actuaría como controladora. Dicha placa sería real, y sin embargo controlaría elmodelo virtual.6JavaScript 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.

7JavaScript no soporta clases de primer nivel, pero existen diferentes sistemas para emular clases. En estecaso, se ha utilizado un sistema de clases basadas en closures.

88

PROYECTO FIN DE CARRERA

De este modo, el usuario, por ejemplo, definiría un programa VHDL que se asegurase deque un tanque de agua se mantuviese siempre lleno, utilizando unas bombas de aguacomo entrada y teniendo una demanda de agua variable y aleatoria como salida. Des-pués, WebLab-Deusto grabaría tal programa en una placa FPGA real, y esa placa FPGAreal 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 contro-lador físico real sobre un modelo virtual añade variedad a los experimentos de formamuy económica, y es a la vez práctico (aplicaciones reales) y razonablemente realista (elcontrolador 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 realidadmixta, con su correspondiente modelo virtual. Sin embargo, se espera que en el futurose creen varios experimentos adicionales, con un modelo distinto pero basados en elmismo concepto. No resulta ésto particularmente difícil, ya que el hardware físico que serequiere es el mismo. Una sola placa FPGA puede dar servicio a un número ilimitado desimulaciones distintas (por supuesto, no al mismo tiempo).

Por este motivo, era extremadamente importante que las facilidades desarrolladas du-rante este proyecto fuesen todo lo genéricas y reutilizables como sea posible.

5.2.5.2 Implementación

La tecnología que se ha elegido para crear las simulaciones ha sido ThreeJS, una libreríagráfica Web que soporta WebGL. Cabe notar que también soporta Canvas. Sin embar-go, por sí sólo no es suficientemente eficiente como para gestionar de forma eficientesimulaciones tridimensionales complejas.

ThreeJS tiene como ventaja el hecho de que es una librería relativamente popular y ma-dura, 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 ensí 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 delmodelo 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 clasede JavaScript, de modo que resulta particularmente potente.

8El estándar JSON tiene ciertas limitaciones. No permite, por ejemplo, números hexadecimales ni por su-puesto 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 sencillocomo 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 {2 "metadata":3 {4 "format" : "myWorld",5 "formatVersion" : 1.06 },7

8 "objects":9 [

10 {11 "name" : "watertank",12 "model" : "models/watertank.js",13 "scale" : [100, 100, 100],14 "position" : [600, 0, 0]15 },16 {17 "name" : "water",18 "model" : function() { return new THREE.CylinderGeometry(95, 95, ⤦

Ç 200, 50, 50, false); },19 "initialTranslation" : [0, 100, 0],20 "scale" : [.95, .1, .95],21 "position" : [597, -95, 0],22 "material" : function() { return new THREE.MeshBasicMaterial({ ⤦

Ç color: 0x0000FF }); },23 },24 {25 "name" : "waterfallRight",26 "model" : "models/waterfall.js",27 "initialTranslation" : [-0.311444, 0, 0],28 "scale": [100, 100, 100],29 "position": [700, 0, 0],30 "material" : function() { return new ⤦

Ç THREE.MeshBasicMaterial({color:0x0000FF}); }31 },32 {33 "name" : "pipe",34 "model" : "models/pipe.js",35 "scale" : [100, 100, 100],36 "position": [470, -80, 0]37 },38 {39 "name" : "mediumMarkerFront",40 "model" : function() { return new THREE.SphereGeometry(5, 10, ⤦

Ç 10); },41 "material" : function() { return new THREE.MeshBasicMaterial({ ⤦

Ç color: 0xFF0000 }); },42 "position" : [600, 0, -94]43 },44

45 ],46

47 "pointlights":

90

PROYECTO FIN DE CARRERA

48 [49 {50 "name" : "light1",51 "position" : [10, 250, 130],52 "color": "0xFFFFFF"53 }54 ],55

56 "ambientlight":57 {58 "color" : "0xFFFFFF"59 },60

61

62 "onLoad" :63 function() {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 quepuede hacerse sin necesidad de cambiar la estructura, gracias al formato JSONextendidoen el que se basa el sistema.

5.2.6 WebLab-Deusto:Modelo virtual de tanque de agua paraWebLab-Deusto-FPGA

5.2.6.1 Motivación

Anteriormente, se han creado infraestructuras genéricas para facilitar la creación de to-do tipo de experimentos con realidad mixta, orientadas principalmente a experimentoselectrónicos que consten de un modelo virtual con un elemento a controlar.

Como primer experimento, que demuestre el potencial de dichas infraestructuras y permi-ta mejorarlas, se ha optado por desarrollar un experimento basado en WebLab-Deusto-FPGA.

Tal experimento consiste en la placa FPGA física y además en un modelo virtual de untanque 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 laplaca FPGA física. La placa FPGA física será capaz de controlar las bombas de agua, yademás, recibirá como entrada la señal de los sensores de nivel virtuales que tendrá elmodelo virtual. De estemodo, el usuario podrá, de formamás omenos realista, trabajar ensu controlador para el tanque de agua, observando los resultados e incluso interactuandocon 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 deinterruptores, pero realmente son señales que el propio servidor de WebLab puede hacervariar.

Esto es posible porque la placa FPGA física está unida a una placa PIC de control, quees la que se encarga de asuntos tales como grabar el programa, resetearlo cuando esnecesario, o controlar las entradas.

Esto hace posible determinar desde el servidor de WebLab las entradas que recibe laplaca.

En los experimentos con modelo virtual, estas entradas, que normalmente son interrup-tores, representarán los sensores.

En nuestro caso, tenemos tres sensores virtuales de nivel. Se ha modificado el códigobase del experimento de tal forma que estos tres sensores virtuales del modelo se reflejanen 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 placafísica, y en algunos casos puede incluso permitir la interacción del usuario con laplaca o el entorno.

Servidor. Es donde realmente tiene lugar la simulación del modelo. El servidor cal-cula el estado de la simulación en base las entradas (los LEDs). Además, el servidorse encarga de definir el estado de los sensores virtuales, y de hacer que el valor

92

PROYECTO FIN DE CARRERA

que reciba la placa física se corresponda. También es el que serializa el estado dela simulación para que el cliente pueda recibirla, interpretarla y mostrarla.

93

PROYECTO FIN DE CARRERA

6. PROBLEMAS E INCIDENCIAS

El resultado del proyecto ha sido definitivamente satisfactorio. No obstante, durante eltranscurso del desarrollo han surgido ciertas dificultades, posiblemente motivadas porel hecho de que el proyecto involucre un número alto de entornos y tecnologías muydistintas.

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 ante-riores.

6.1 ANTIGÜEDADDELENTORNODEDESARROLLOORIGINALDE BOOLE-DEUSTO

Boole-Deusto fue desarrollado originalmente en Borland C++ Builder 5. Esta versión delentorno 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, desafortunadamen-te Boole-Deusto en concreto depende totalmente de la librería VCL (Visual ComponentsLibrary) 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 ligeramentemá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 consi-derables inconvenientes, que han multiplicado el tiempo que normalmente hubiera sidonecesario para realizar las extensiones y modificaciones que se han llevado a cabo du-rante 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 deWindows, como Windows Vista, Windows 7 o Windows 8.

Para el desarrollo, tras numerosos intentos de solucionar los problemas que surgían, seha tenido que optar por instalar un entorno virtual basado en VirtualBox y Windows XPpara poder realizar el desarrollo. Este entorno puede verse en la Fig. 5.6.

Si bien en este entorno Borland C++ Builder 6 funcionaba adecuadamente, desarrollaren 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 paratransferir 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 entornosRAD (Rapid Application Development). Por aquel entonces, se le consideraba a la alturadel Visual Studio de la época.

En los últimos 13 años, sin embargo, los entornos de desarrollo han mejorado extrema-damente, y se puede afirmar que los entornos modernos, como Visual Studio 2012, sonmuy 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 no-tablemente. La interfaz basada en la VCL de Boole-Deusto como consecuencia no es nipuede 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 DEWEBGL

A este respecto, la causa de los problemas es esencialmente la inversa de el caso deBorland.

WebGL es una tecnología muy novedosa, y ciertos aspectos no están aun demasiadoestá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 implementarcierta característica que aparentemente funcionaba de forma satisfactoria, se ha des-cubierto que en algún navegador concreto o alguna versión concreta no funcionaba delmismo 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 elentorno móvil.

Los navegadores principales de móvil tienden a soportarlo en sus versiones más recien-tes, pero en ocasiones, como en el caso de Chrome, se requiere activarlo manualmen-te.

Además, de todos modos, una gran parte de usuarios de móviles no actualizan su nave-gador con frecuencia, por lo que estos usuarios no podrán usar la aplicación, en algunoscasos, o experimentarán un comportamiento incorrecto.

96

PROYECTO FIN DE CARRERA

De todos modos, considerando el éxito que WebGL ha tenido, es de prever que en pocotiempo 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, planeanofrecerlo en el futuro cercano en sus nuevas versiones.

97

PROYECTO FIN DE CARRERA

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ís-ticas de integración añadidas a Boole-Deusto hacen que sea posible y sencillo diseñar uncircuito combinacional o un autómata, y probarlo prácticamente al momento en un equiporeal 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 unouna sección distinta de esta guía.

7.1.2 Circuitos Combinacionales

7.1.2.1 Introducción

La mayor parte de características relacionadas con la creación de circuitos combinacio-nales 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 relacionadoscon Weblab a la parte superior izquierda de la ventana.

En las secciones posteriores se describirá brevemente el propósito de estos nuevos con-troles, y se incluirá una guía rápida paso a paso para crear y probar un sistema combi-nacional.

7.1.2.2 Controles de Weblab

Los controles añadidos a Boole-Deusto son dos, cuyo propósito se describirá brevementea continuación.

∎ Activación / desactivación de Weblab

Este control sirve para activar o desactivar el modo weblab. El modo weblab puede seractivado o desactivado en cualquier momento. Cuando está desactivado, Boole-Deustose comporta exactamente como el Boole-Deusto original. Cuando está activado, sin em-bargo, se producen los siguientes efectos:

Las tablas de entradas / salidas permiten elegir los nombres correctos, que se co-rresponden con las entradas / salidas en Weblab.

El código VHDL que Boole-Deusto genere será diferente al que normalmente gene-raría, ya que tendrá diversos cambios orientados a hacerlo directamente compatiblecon el experimento FPGA de Weblab.

100

PROYECTO FIN DE CARRERA

Advertencia: El sistema permite, al igual que el Boole-Deusto original, pero inclusoen modo weblab, asignar nombres arbitrarios de entradas y salidas, o incluso repetirnombres 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)conWeblab-Deusto. Por eso, para facilitar el uso conjunto, se recomienda utilizar siemprenombres de la lista de entradas/salidas y nunca repetirlos.

Advertencia: En este momento existe un bug conocido que impide en ocasiones, estadoenmodo weblab, que aparezcan las sugerencias de entradas / salidas deWeblab. Debidoa ciertos motivos, esto tiende a suceder siempre que se hace click por primera vez en laprimera celda de la tabla de entradas y de salidas. Para evitarlo, se recomienda hacersiempre 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 de-fecto, y generalmente tras dar al usuario la posibilidad de autenticarse, accederá directa-mente al experimento FPGA, lo que permitirá al usuario subir inmediatamente el códigoVHDL que genere y probarlo de forma rápida y sencilla.

Nota: En este momento, el experimento Weblab-FPGA, que es el utilizado para probar elcódigo VHDL, requiere un usuario registrado en Weblab que tenga ciertos privilegios. Sindichos privilegios no será posible probar el código. En caso de que se necesiten obtenertales privilegios, se recomienda ponerse en contacto con el equipo de Weblab-Deusto, ocon 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 sistemacombinacional, que después probaremos directamente en WebLab utilizando las nuevascaracterísticas de integración.

Para esta guía, se asume que el usuario está algo familiarizado con los sistemas combi-nacionales, 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 lasiguiente figura, y que nos permitirá asignar fácilmente los nombres necesarios delas 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 eneste caso será XOR-AND, ya que, como veremos enseguida, calcular el XOR y elAND 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 impor-tante que los nombres utilizados sean exactamente los sugeridos por Boole-Deustoal estar en modoWeblab, ya que es el nombre el que los relacionará posteriormentecon los componentes físicos reales (switches, leds, etc) de los que consta Weblab.Queda así:

102

PROYECTO FIN DE CARRERA

Figura 7.4.: Asignación de entradas y salidas compatibles con WebLab

5. Hecho esto, definiremos normalmente la tabla de verdad para nuestro sistema. Esimprescindible 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 lasmúltiples características que ofrece Boole-Deusto, tales como visualizar el circuitoo 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 degenerar el código, el modo Weblab esté habilitado. El código que se genera pordefecto (en el modo estándar) no es directamente compatible. Para generarlo, comoen el Boole-Deusto tradicional, deberemos utilizar el botón que se observa en lafigura 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 sistemacombinacional. Si lo deseamos, podemos echar un vistazo al código que hemosgenerado, o incluso modificarlo, siempre que respetemos ciertas reglas impuestaspor Weblab(principalmente, relacionadas con los nombres de entradas y salidas).Para probarlo, haremos click en el botón “Open Weblab-FPGA”, que abrirá un na-vegador:

104

PROYECTO FIN DE CARRERA

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 ex-perimento Weblab-FPGA, en la cual deberemos elegir el archivo VHDL que hemospreviamente 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 experi-mento. Dependiendo del estado de Weblab-Deusto, y de la la existencia o no deuna cola de usuarios, transcurrirá más o menos tiempo antes de que la reservaconcluya. 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 sintetizandoel código VHDL, o programando la placa. Puesto que especialmente la sintetizaciónes un proceso lento, pueden llegar a transcurrir variosminutos antes de que termine.Si la barra se detuviese con un error, se recomienda consultar la advertencia que seincluye al final de esta sección. El resto de la guía asume que tanto la sintetizacióncomo la programación son correctas.

12. Una vez que el programa ha sido correctamente sintetizado, y la placa correcta-mente 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 po-demos ver la placa física, que está actualmente ejecutando nuestro sistema com-

106

PROYECTO FIN DE CARRERA

binacional. Podemos ver también los leds, que actúan como salidas, y diversosinterruptores virtuales, que actúan como entrada física real a la placa, y median-te los cuales podemos interactuar. En este caso, vemos que con los interruptoresa “0-1” está encendido el segundo LED, y apagado el primero, tal y como hemosdefinido en nuestra tabla de verdad.

14. Disponemos de un tiempo limitado para probar el sistema. Una vez que el tiempoexpire, el sistema automáticamente volverá a la pantalla de reserva. Si necesitamosrealizar más pruebas, deberemos reservar de nuevo.

Nota: Los leds (Leds<0-8>), los interruptores (Switches<0-9>) y los botones (Buttons<0-3>) se ordenan de derecha a izquierda. Esto implica, por ejemplo, que el Switch<0> enBoole-Deusto se corresponde con el interruptor de más a la derecha, mientras que elSwitch<1> sería el inmediatamente a su izquierda.

Advertencia: Si la barra se detuviese con un “compiling error” o con un “programmingerror”, significaría, en el primer caso, que el proceso de sintetización ha fallado (quizásdebido a un error de sintáxis), y en el segundo, que el proceso de programación de laplaca 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 deentradas y salidas de Weblab, y que por tanto no se han incluido entradas/salidascon nombres originales, ni entradas/salidas con nombres repetidos.

Comprobar que no se hayan realizado modificaciones manuales al VHDL, o que encaso de que se hayan realizado, no contengan errores.

Si con las diversas comprobaciones anteriores no se consigue resolver el problema, o siel 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 conWebLab-Deusto

7.1.4.1 Introducción

El segundo tipo de circuito con el que Boole-Deusto puede trabajar son los autómatas. Es-ta característica, que ya existía en el boole-deusto original, ha sido extendida añadiendocapacidad de integración inmediata con Weblab-Deusto y en concreto sus experimentosFPGA. 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ísicoreal 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 requie-re (ni permite) elegir las correspondencias entre las salidas y entradas de los estados, ylas salidas y entradas de Weblab-Deusto. En vez de eso, se ha de saber que la corres-pondencia entre entradas y salidas siempre es la misma:

Las entradas son siempre los interruptores. De este modo, si tenemos por ejemplo un es-tado S0 que “recibe” dos entradas, estas dos entradas se corresponderán con los últimosdos interruptores (los de más a la derecha).

Las salidas son siempre los LEDs. De este modo, si tenemos un estado S0 que tiene dossalidas, estas dos salidas se corresponderán con los últimos dos LEDs (los de más a la

108

PROYECTO FIN DE CARRERA

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 VHDLcompatible 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 inmedia-tamente compatible con el experimento FPGA de Weblab-Deusto. Para conseguir estacompatibilidad, el código generado utilizará nombres de entradas y salidas compatiblescon las de Weblab-Deusto (definidas en un UCF).

Podemos observar que existen varias opciones para generar el código. Cada una de esasopciones corresponde a un tipo de reloj diferente, que utilizará el autómata. Los relojesdisponibles 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 hacepoco adecuado para aquellos casos en los que el comportamiento del autómatarequiera 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 sufrecuencia puede ser controlada de forma limitada, mediante un slider en el propioexperimento.

Reloj Interruptor (Switch Clock)El último interruptor (el de más a la izquierda) actúa como reloj. Esto lo hace muyadecuado para aquellos casos en los que se desee probar el autómata teniendo unabsoluto control sobre el reloj. Esto podría incluir, por ejemplo, aquellos casos enlos 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. Denuevo, muy adecuado para aquellos casos en los que se desee probar el autómatateniendo un absoluto control sobre el reloj.

Advertencia: Debido a limitaciones presentes ya en el Boole-Deusto original, se re-comienda 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 respon-der.

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 modifica-ciones.

Nota de implementación: En la práctica, el reloj a utilizar no lo determina el VHDL ensí, sino el archivo de restriccines (UCF) que se utilice. Boole-Deusto añade una direc-tiva como comentario al VHDL, como por ejemplo%%%CLOCK:SWITCH%%%‘. Estadirectiva, en absoluto original de Xilinx, es detectada por el propio Weblab-Deusto, quesintetizará el VHDL provisto utilizando un UCF u otro. Cuando se utiliza Weblab-DeustoFPGA también es posible usar dichas directivas en código VHDL escrito manualmen-te.

110

PROYECTO FIN DE CARRERA

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 de-fecto, y generalmente tras dar al usuario la posibilidad de autenticarse, accederá directa-mente al experimento FPGA, lo que permitirá al usuario subir inmediatamente el códigoVHDL que genere y probarlo de forma rápida y sencilla.

Nota: En este momento, el experimentoWeblab-FPGA, que es el utilizado para probar elcódigo VHDL, requiere un usuario registrado en Weblab que tenga ciertos privilegios. Sindichos privilegios no será posible probar el código. En caso de que se necesiten obtenertales privilegios, se recomienda ponerse en contacto con el equipo de Weblab-Deusto, ocon quien corresponda.

7.2 GUÍA DEL EXPERIMENTO FPGAWATERTANK

En esta sección se describe el funcionamiento del experimento FPGA Watertank, y seexplica 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 tienecomo 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 unaplaca 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 delprograma y la correspondencia de cada entrada/salida con los pines de la placa. Losarchivos BITSTREAM deben sintetizarse previamente utilizando las herramientasXilinx ISE.

Archivo VHDL: Archivo fuente terminado en .vhd que contiene código fuente queespecifica la lógica del sistema. Para ser válido debe cumplir ciertas restricciones encuanto a los nombres y presencia de las entradas/salidas. Pueden ser generadospor 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 untanque de agua.

El objetivo del experimento es, precisamente, controlar el tanque de agua utilizando comocontrolador la placa FPGA real.

7.2.2 Funcionamiento de un modelo virtual

Los experimentos con modelo virtual combinan una placa controladora real con elmodelo virtual. En este caso, la placa controladora es una FPGA. El objetivo suele sercrear 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 elvolumen 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 vir-tuales del modelo virtual deben llegar de algún modo a la placa controladora real, y almismo tiempo, la placa controladora real debe de algún modo poder dar órdenes o afec-tar al modelo virtual de alguna forma.

La solución ha sido utilizar los LEDs de la placa como señales al modelo, y los interrup-tores 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 programaVHDL grabado en la placa.

De forma similar, si la placa quiere enviar una señal positiva al modelo virtual, puedehacerlo utilizando los LEDs. Por ejemplo, poniendo led0 a uno surtirá efecto en algunosmodelos virtuales (incluyendo el del tanque de agua).

La especificación exacta del modelo del tanque de agua se explica a continuación.

112

PROYECTO FIN DE CARRERA

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 aguatradicional.

El modelo, en este caso, tiene una demanda de agua variable. Esto quiere decir que sino hay una entrada de agua, con el tiempo se vaciará. La demanda cambia periódica-mente, y se determina de forma aleatoria.

Para poder llenar el tanque, existen dos bombas de agua. Estas bombas de agua soncontrolables 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 sensoresvirtuales.

La altura de dichos sensores es del 20%, del 50% y del 80% respectivamente. La placarecibe 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.

Sensor de altura 50% → swi1.

Sensor de altura 80% → swi2.

7.2.4 Otros detalles

El experimento tiene un modo pantalla completa. Para activarlo, hacer click en elcontrol reservado al efecto.

Hay interruptores disponibles. La salida de dichos interruptores se transmite direc-tamente a la placa.

En la parte superior derecha puede verse el aparente estado de los LEDs. Puestoque el estado de los LEDs es obtenido por el servidor utilizando técnicas de visiónartificial y existe además una latencia, es posible que el estado de los LEDs en unmomento dado no coincida con la realidad.

7.2.5 Ejemplos

El siguiente ejemplo de programa VHDL enciende la primera bomba cuando el depósitoestá por debajo de la mitad, y enciende las dos bombas cuando el depósito está pordebajo del 20%.

1 -- @@@CLOCK:WEBLAB@@@2 library IEEE;3 use IEEE.STD_LOGIC_1164.ALL;4 use IEEE.STD_LOGIC_ARITH.ALL;5 use IEEE.STD_LOGIC_UNSIGNED.ALL;6

7 entity base is8 Port (9

10 inicio : in std_logic;11 clk : in std_logic;12

13 led0 : inout std_logic;14 led1 : inout std_logic;15 led2 : inout std_logic;16 led3 : inout std_logic;17 led4 : inout std_logic;18 led5 : inout std_logic;19 led6 : inout std_logic;20 led7 : inout std_logic;21

22 ena0 : inout std_logic;23 ena1 : inout std_logic;24 ena2 : inout std_logic;

114

PROYECTO FIN DE CARRERA

25 ena3 : inout std_logic;26

27 seg0 : inout std_logic;28 seg1 : inout std_logic;29 seg2 : inout std_logic;30 seg3 : inout std_logic;31 seg4 : inout std_logic;32 seg5 : inout std_logic;33 seg6 : inout std_logic;34

35 dot : inout std_logic;36

37 but0 : in std_logic;38 but1 : in std_logic;39 but2 : in std_logic;40 but3 : in std_logic;41

42 swi0 : in std_logic;43 swi1 : in std_logic;44 swi2 : in std_logic;45 swi3 : in std_logic;46 swi4 : in std_logic;47 swi5 : in std_logic;48 swi6 : in std_logic;49 swi7 : in std_logic;50 swi8 : in std_logic;51 swi9 : in std_logic52 );53 end base;54

55 architecture behavioral of base is56

57

58 begin59 led1 <= not swi1;60 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 encuenta que prácticamente toda la parte perteneciente a definiciones de entradas/salidases fija, y está presente en todo programa VHDL para WebLab-FPGA.

La parte más notable del programa sería por tanto:

1 led1 <= not swi1;2 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 sensorvirtual de nivel 50% no está activado. La segunda, activa el led0, y por tanto enciende laprimera 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 noestaba disponible) documentación alguna sobre el desarrollo de Boole-Deusto. Tampocoversiones del código anteriores a la creación del repositorio GIT de código, creado parael proyecto.

La información contenida en este breve documento, por tanto, está formada principal-mente por asunciones, y puede esperarse que contenga ciertas imprecisiones y omisio-nes.

No obstante, puesto que Boole-Deusto es un sistema relativamente antiguo y existenciertas complejidades relacionadas con su desarrollo y su entorno, se espera que el do-cumento pueda ser particularmente útil, en caso de que se requieran modificaciones enel futuro.

7.3.1 Entorno de programación

El programa Boole-Deusto está desarrollado en Borland C++ Builder. En concreto, pa-rece que la última versión que es razonablemente compatible es Borland C++ Builder6. Depende absolutamente de la VCL (Visual Components Library) de Borland, y por lotanto no puede ser fácilmente portado a entornos diferentes, más modernos.

Existen versiones más recientes de C++ Builder, tales como Embarcadero C++. Aunquese ha considerado portarlo a una de estas versiones antes de comenzar el proyecto, seha 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 si-guientes:

Las versionesmodernas tienenmuchos cambios con respecto a soporte de UNICO-DE, que ha pasado en ciertos ámbitos a ser la opción por defecto. Esto ha implicadodiversos cambios a la API de la VCL. Debido al código de Boole-Deusto en gene-ral, y en concreto al sistema de lenguajes, adaptarlo implicaría cambios bastantesignificativos.

Las versiones modernas no soportan el sistema de traducciones y localización queel proyecto utiliza. Actualizarlo supondría posiblemente utilizar un sistema de loca-lizaciones nuevo, teniendo posiblemente que añadir a mano todas las traduccionesque 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 (sibien teóricamente debería convertirse, parece ser que para proyectos no trivialesestá prácticamente garantizado el tener que crear uno nuevo). Aunque esto supon-dría un trabajo mucho menor que, por ejemplo, el punto anterior, sigue siendo unainconveniencia seria.

116

PROYECTO FIN DE CARRERA

Existe una dependencia externa de una versión concreta de la librería ANTLR. Po-siblemente actualizar a una versión más moderna implicaría actualizar también ladependencia externa, y realizar los cambios necesarios.

Han existido muchos problemas a la hora de elegir y adaptar un entorno de desarrolloadecuado. La versión que más se ajusta, Borland C++ Builder 6, no es totalmente com-patible con las versiones modernas de sistemas operativos. En concreto, hay numerososproblemas con Windows 7, y, asumo, con Windows Vista y Windows 8. La falta de com-patibilidad no es completa (hay errores sueltos, se cuelga, y el sistema de lenguajes enconcreto no funciona bien, pero las características principales, al menos ejecutando comoadministrador, sí que funcionan, de modo que quizás sea usable, con suficiente cuidadoy evitando los bugs). Personalmente, he instalado Borland en una máquina virtual conWindows XP. Esto soluciona directamente diversos errores, principalmente, relativos alTranslation Manager y sistema de lenguajes en general, y alguno más. Es por tanto elenfoque recomendado.

7.3.2 Sistema de lenguajes

El sistema de localización que utiliza el proyecto es un sistema bastante extraño, queaparentemente ya no se soporta en versiones modernas, identificable como ResourceDLLs.

El entorno de Borland genera de manera semi-automática un proyecto diferente paracada lenguaje extra. Este proyecto, que contiene básicamente archivos relativos a losformularios y otra información de traducción, al compilar genera un DLL con extensióndependiente 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 corres-pondiente.

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 expon-drá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 gruposde proyecto), hace referencia al proyecto principal (boole.bpr) y a los proyectosde 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 archivosde lenguaje. Para que funcione cada lenguaje, se ha de compilar cada proyecto, queproduce 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 queen Borland no aparezca tal opción. Puede tratar de solucionarse reinstalando Bor-land, reinstalándolo en un Sistema Operativo más antiguo, ejecutando el Borlandcomo 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, deberecompilarse 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 adi-cional de cambios, no basta con utilizar el Translation Manager para que los DLLsde lenguajes se actualicen correctamente. En tales casos, hay que utilizar el “Up-date Resource DLLs”. Esta opción está (o debiera estar) disponible en: Project->Languages->Update Resource DLLs. De nuevo, puede ocurrir, por fallo, que talopción no esté visible.

Cuando se actualizan los lenguajes tras un Update Resource DLLs hacen falta pa-sos adicionales para conseguir que los lenguajes vuelvan a funcionar como se es-pera, debido principalmente a ciertos errores con la generación que hay que solu-cionar manualmente. Estos errores se indican a continuación. Si por ser un cambiomenor (que no afecta a los formularios) no ha sido necesario hacer el Update, po-siblemente los pasos a continuación sean prescindibles.

El directorio de salida de los proyectos de lenguajes es incorrecto. A través del Pro-ject 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, quehace referencia a los diversos formularios. En un inicio, aparecen errores de linkeral tratar de hacer referencia a .OBJs, porque los paths que se encuentran en estearchivo 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 auto-generado, y hacer un search-replace de “\çon “\\”. Tras ésto, el proyecto deberíacompilar con éxito.

Existe un mensajes.rc, que contiene una tabla de cadenas presente en un men-sajes.inc. En cada lenguaje existe una copia diferente de estos dos archivos. Aun-que el mensajes.rc parece que puede actualizarse para cada lenguaje a través delTranslation Manager, se necesitará añadir a mano cada entrada al mensajes.inc.Puesto que el mensajes.inc generalmente será realmente el mismo para todos loslenguajes, posiblemente copiar y pegar el mensajes.inc principal en cada lenguajetambié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 lade los “locales” de Winnt.h. Por ejemplo, para Euskera Borland genera un archivoboole.EUS. Por algún motivo no determinado, sin embargo, Borland al cargar elLANG_BASQUE intenta encontrar el boole.EUQ. La “solución” que de momento seha aplicado es, sencillamente, renombrar manualmente el boole.EUS generado porboole.EUQ.

El boole.cpp del proyecto principal (boole.exe) es el que decide qué lenguaje se car-ga. Si bien parece haber código mezclado de diferentes métodos, en la actualidad elque se encuentra activo lo que hace es leer un archivo ”boole.lang”, y dependiendo

118

PROYECTO FIN DE CARRERA

de su contenido cargar el DLL correspondiente a un locale u otro. En el momentode escribir ésto, los lenguajes bien soportados son el por defecto (Castellano), in-glés (en), euskera (eu). Están parcialmente soportados (pueden cargarse, pero nohay apenas traducciones) el catalán (ca) y el portugúes (pt). El boole.lang puedepor tanto contener una de las siguientes cadenas: ( es|en|eu|ca|pt ). Esto deberíatenerse en cuenta en el caso de querer añadir un nuevo lenguaje.

7.4 GUÍADEDESARROLLODECLIENTESDEEXPERIMENTOSEN 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 pesarde que de este modo no se tiene acceso a ciertos widgets GWT que ya están implemen-tados, y a pesar de que implica que el desarrollador deberá implementar la mayor partedel 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 interfazcon el servidor.

No implica ninguna dependencia, aparte de un simple JavaScript (la librería ante-riormente 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 desplegaro ejecutar antes WebLab. Puede sencillamente abrirse el archivo HTML con unnavegador.

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 particularexperimento. Se comunica con WebLab y el servidor de experimento a través de una APImuy 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 reco-mendable 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 unjslightbulb.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í quesié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 experim-nento para controlar remotamente una bombilla), podría querer añadir, quizás, la salidade 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 oframework para facilitar su trabajo.

Actualmente, sin embargo, nuestro experimento de la bombilla no se conecta realmente aWebLab. Posiblemente se pregunte, por tanto, cómo realmente decirle a la bombilla quese apague o se encienda cuando el usuario presione su botón JavaScript. Esto es, cómoenviar un comando al servidor de experimento (que, se entiende, controlará directamenteel 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

PROYECTO FIN DE CARRERA

A continuación, se incluyen los prototipos de las funciones de WeblabJS:

1 //! Sends a command to the experiment server.2 //!3 //! @param text Text of the command.4 //! @param successHandler Callback that will receive the response for the ⤦

Ç command.5 //! Takes a single string as argument.6 //! @param errorHandler Callback that will receive the response for the command.7 //! Takes a single string as argument.8 //!9 this.sendCommand = function (text, successHandler, errorHandler)

10

11

12 //! Sets the callback that will be invoked when the experiment finishes. ⤦Ç Generally,

13 //! an experiment finishes when it runs out of allocated time, but it may also14 //! be finished explicitly by the user or the experiment code, or by errors and15 //! and disconnections.16 //!17 this.setOnEndCallback = function (onEndCallback)18

19 //! Sets the callbacks that will be invoked by default when a sendfile request20 //! finishes. The appropriate callback specified here will be invoked if no21 //! callback was specified in the sendFile call, or if the sendFile was done22 //! from GWT itself and not through this API.23 //!24 //! @param onSuccess Callback invoked when the sendFile request succeeds. Takes25 //! the return message as argument.26 //! @param onError Callback invoked when the sendFile request fails. Takes the27 //! return message as argument.28 this.setFileHandlerCallbacks = function (onSuccess, onError)29

30 //! Sets the startInteractionCallback. This is the callback that will be invoked31 //! after the Weblab experiment is successfully reserved, and the user can start32 //! interacting with the experiment.33 this.setOnStartInteractionCallback = function (onStartInteractionCallback)34

35 //! Sets the setTime callback. This is the callback that Weblab invokes when ⤦Ç it defines

36 //! the time that the experiment has left. Currently, the Weblab system only ⤦Ç invokes

37 //! this once, on startup. Hence, from the moment setTime is invoked, the ⤦Ç experiment

38 //! can take for granted that that is indeed the time it has left. Unless, of ⤦Ç course,

39 //! the experiment itself chooses to finish, or the user finishes early.40 //!41 //! @param onTimeCallback The callback to invoke when Weblab sets the time ⤦

Ç left for42 //! the experiment.43 //!44 this.setOnTimeCallback = function (onTimeCallback)45

46 //! Sets the three Weblab callbacks at once.47 //!

121

7. MANUALES

48 //! @param onStartInteraction Start Interaction callback.49 //! @param onTime On Time callback.50 //! @param onEnd On End callback.51 //!52 //! @see setOnStartInteraction53 //! @see setOnTimeCallback54 //! @see setOnEndCallback55 this.setCallbacks = function (onStartInteraction, onTime, onEnd)56

57 //! Retrieves a configuration property.58 //!59 //! @param name Name of the property.60 this.getProperty = function (name)61

62 //! Retrieves a configuration property.63 //!64 //! @param name Name of the property.65 //! @param def Default value to return if the configuration property66 //! is not found.67 this.getPropertyDef = function (name, def)68

69 //! Retrieves an integer configuration property.70 //!71 //! @param name Name of the property.72 this.getIntProperty = function (name)73

74 //! Retrieves an integer configuration property.75 //!76 //! @param name Name of the property.77 //! @param def Default value to return if the configuration property78 //! is not found.79 this.getIntPropertyDef = function (name, def)80

81 //! Finishes the experiment.82 //!83 this.clean = function ()84

85 //! Returns true if the experiment is active, false otherwise.86 //! An experiment is active if it has started and not finished.87 //! That is, if the server, supposedly, should be able to receive88 //! commands.89 //!90 this.isExperimentActive = function ()91

92 //! Checks whether this interface is actually connected to the real93 //! WebLab client.94 //!95 //! @return True, if connected to the real WL client. False otherwise.96 this.checkOnline = function ()97

98 //! This method is for debugging purposes. When the WeblabJS interface is used ⤦Ç stand-alone,

99 //! offline from the real Weblab client, then the response to SendCommand will ⤦Ç be as specified.

100 //!101 //! @param response Text in the response.

122

PROYECTO FIN DE CARRERA

102 //! @param result If true, SendCommand will invoke the success handler.103 //! @param result If false, SendCommand will invoke the failure handler.104 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 Weblab.sendCommand( "LIGHTBULB ON",2 function(response) {3 console.log("Light turned on successfully");4 },5 function(response) {6 console.error("Light failed to turn on");7 }8 );

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, porejemplo, es conveniente ser capaz de ejecutar la interfaz en HTML por sí sola, sinWeblab.Para poder hacer que el experimento se comporte en este caso de una forma similar ala habitual, se pueden usar las funciones de depuración para simular respuestas quenormalmente daría el servidor, o para usos similares.

123

PROYECTO FIN DE CARRERA

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 enqué 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 especialmen-te 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 hasido bueno. Los experimentos con modelos virtuales creados durante el desarrollo delproyecto son, como se esperaba, prácticos y a la vez usables, satisfaciendo así las ex-pectativas.

La integración entre Boole-Deusto y WebLab-Deusto ha demostrado ser particularmentepotente. Los usuarios tan sólo necesitan el propio Boole-Deusto, un navegador de Inter-net y una conexión. Con ésto, pueden, en tan sólo unos minutos, diseñar desde cero unsistema digital (ya sea un autómata o un circuito combinacional), probarlo con apenasunos 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 espera-da.

Todo el proceso está altamente integrado, y es posible llevarlo acabo en sólo unos minu-tos. Con sistemas tradicionales, dependiendo de placas físicas no remotas y de softwareespecializado que el propio usuario debería instalar en su máquina, el mismo proceso re-quiere en la mayoría de los casos horas, y está sujeto a diversos fallos y complejidadesadicionales.

La curva de aprendizaje, además, es notablemente baja. La complejidad viene dada úni-camente por el sistema digital a diseñar y por el modelo virtual a controlar (en caso deelegir tal opción). Por ello, el sistema es útil y se adapta a un rango muy amplio de estu-diantes y usuarios.

Dicho rango podría incluir:

Estudiantes de colegios, aprendiendo los conceptos básicos sobre sistemas di-gitales, que diseñarían y probarían con apoyo de Boole-Deusto sistemas digitalesbásicos, probablemente combinacionales.

125

8. CONCLUSIONES Y TRABAJO FUTURO

Estudiantes más avanzados, de los primeros cursos de carreras universitariastécnicas, que diseñarían esos mismos sistemas digitales, y también sistemas digi-tales más complejos, como autómatas, apoyados también por Boole-Deusto.

Estudiantes avanzados o profesores, que con o sin apoyo de Boole-Deusto di-señen sistemas de control en VHDL, arbitrariamente complejos (posiblemente, es-cribiendo o modificando manualmente el VHDL, en vez de generarlo automática-mente).

Profesionales trabajando en el diseño de sistemas de control reales, que deseenutilizar WebLab-Deusto para probar su sistema de forma sencilla y rápida en unentorno físico real, ahorrándose el tiempo y recursos necesarios que normalmenterequerirí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 sidoposible aislar una gran parte de funcionalidad común y encapsularla en un frameworkgené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 experimentosrelacionados.

También es particularmente satisfactorio el hecho de que con las infraestructuras creadasdurante el desarrollo del proyecto, es ahora posible la creación de experimentos comple-tos íntegramente en JavaScript, sin necesitar de compilar WebLab-Deusto y sin dependerde ninguna tecnología o librería adicional.

El lado cliente del experimento es JavaScript estándar y se comunica con WebLab me-diante una simple librería JavaScript, y el lado servidor del experimento es posible graciasa NodeJS.

126

PROYECTO FIN DE CARRERA

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, yFPGA-Watertank en concreto, pueden ya hoy ejecutarse incluso en tablets, lo que suponegrandes 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 satisfactoria-mente. Hace falta un sólo click para que el experimento correcto se abra en unnavegador.

127

8. CONCLUSIONES Y TRABAJO FUTURO

Los usuarios no necesitan ningún software aparte del propio Boole-Deusto (y porsupuesto un navegador) para diseñar un sistema y probarlo en un sistema real. Esposible realizar el proceso completo en tan sólo unos minutos.

WebLab-Deusto-FPGA es ahora capaz de compilar archivos VHDL. Tanto VHDLgenerados por Boole-Deusto, como VHDLs creados manualmente por usuarios in-dependientes de WebLab-Deusto.

Es ahora posible crear experimentos utilizando sólo JavaScript, tanto en lo querespecta a servidor como en lo que respecta a cliente.

Existe la infraestructura necesaria para crear fácilmente un experimento conmodelovirtual, dotado de realidad mixta, de forma sencilla. Se puede utilizar un formato dedeclaración de escenas propio, bassado en JSON pero más potente, gracias a susoporte para eventos y callbacks.

Se ha creado un experimento utilizando dicha infraestructura de realidad mixta. Enconcreto, un experimento de tipo FPGA mediante el que el usuario puede definirla 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 satis-factorios, y que se han cumplido las expectativas. El proyecto ha sido amplio y se hanmejorado de forma notable las capacidades de Boole-Deusto y deWebLab-Deusto.

Sin embargo, los buenos resultados dejan patente, de hecho, el gran potencial que tienenconceptos 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 modelovirtual (que sería prohibitivo de implementar físicamente)

La creación de experimentos remotos, cliente y servidor incluidos, utilizando sóloJavaScript

Podemos afirmar, por tanto, que hay muchas líneas futuras abiertas, y mucho espaciopara 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 casoconcreto de Boole-WebLab-Deusto, sería posible por ejemplo automatizar aun másel proceso, haciendo que la generación y subida del código VHDL se una en unmismo paso, y que el usuario, si no lo desea, no llegue a conocer la generacióndel código, sino que éste se grabe en la placa física de WebLab-Deusto de formatransparente.

128

PROYECTO FIN DE CARRERA

Otra línea de trabajo podría ser la integración de WebLab-Deusto con un softwa-re distinto. Este software podría variar desde otros software educativos de diseñoelectró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, po-siblemente 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 granparte el trabajo en tales entornos. Esto podría hacer posible, por ejemplo, diseñaren 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 trabajoque hacer.

Las infraestructuras genéricas que han sido creadas hacen que sea relativamentesencillo crear modelos virtuales nuevos, de forma que es de esperar que en el futurose desarrollen un gran número de simulaciones distintas. En concreto, las simula-ciones que probablemente se implementen en un futuro cercano son una simulaciónpara el sistema de control de control de calidad de una línea de producción, y parael 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 paraWebLab no ha sido un trabajo sencillo. En general,los desarrolladores externos al propio weblab tenían dificultades porque el métodomejor soportado tradicionalmente ha sido GWT (cliente) y Python (servidor).

Esto es frecuentemente poco conveniente por dos motivos. Primero, son dos tec-nologías distintas, de modo que en general, los desarrolladores para crear un sóloexperimento se veían obligados a aprender ambas. Además, especialmente GWT,no es una tecnología particularmente conocida, de modo que las posibilidades deestar familiarizado desde un inicio son escasas. Segundo, GWT requiere compi-lación, en general, junto con el resto del cliente de WebLab, lo que es un tantoincómodo a la hora de desarrollar un experimento que realmente no involucra aninguna 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 lenguajees particularmente conocido y a la vez simple, prácticamente cualquier programa-dor Web en particular lo habrá utilizado, aunque haya sido superficialmente. Per-mite, en definitiva, desarrollar un experimento nuevo con la facilidad con la que sedesarrollaría una página web sencilla.

129

PROYECTO FIN DE CARRERA

9. POSIBLE PLAN DE NEGOCIO

En este capítulo, se ha desarrollado un posible plan de negocio basado en las tecnologíasde Laboratorios Remotos desarrolladas por la Universidad de Deusto en torno al proyectoWebLab-Deusto.

Con respecto a la configuración de dicho Plan de Negocio, se ha seguido principalmenteel modelo propuesto por SCORE [41]. Se han omitido ciertas secciones que normalmenteaparecerían en un Plan de Negocio por no considerarse apropiadas en este trabajo, opor 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 experi-mentació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óna distancia y de losMOOC (Cursos OnlineMasivos y Abiertos), que en los últimos tiemposha experimentado un crecimiento exponencial.

En la actualidad, la experimentación remota podría ser útil a muchos centros formativosy 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 elec-trónica, la programación de microcontroladores, la física, la biología, etc. Gracias a unlaboratorio remoto, es posible mejorar la oferta formativa mejorando la eficiencia de usode los equipos, facilitando el acceso, reduciendo costes, etc.

Sin embargo, para desplegar y gestionar con éxito un laboratorio remoto se requierenmuchos recursos, y sobre todo, personal especializado, con gran experiencia y conoci-miento técnico.

Esto hace que sin ayuda los laboratorios remotos sean prohibitivos para prácticamentecualquier institución pequeña o mediana, y que sólo estén realmente al alcance de unaspocas universidades. Generalmente, sólo de aquellas que realizan investigación relacio-nada con el área.

Por este motivo, la Empresa cuenta con una gran ventaja competitiva, al disponer de añosde experiencia en la creación, desarrollo y uso de laboratorios remotos en un entornoacadémico, estando directamente relacionada con el desarrollo de una de las principalesinfraestructuras de laboratorios remotos del mundo, WebLab-Deusto.

En estas circunstancias, el objetivo de la Empresa es ofrecer a sus clientes sus propioslaboratorios remotos, encargándose de gestionar todo el proceso, que incluye compra de

131

9. POSIBLE PLAN DE NEGOCIO

equipos, montaje, despliegue, pruebas, etc.

Los servidores y demás equipamiento, además, serán hospedados en instalaciones de lapropia empresa. De éste modo, el cliente final queda exento de cualquier responsabilidadté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 otrimestral) un centro formativo tal como un colegio, un centro de formación profesionalo una universidad, podrá tener su propio laboratorio remoto, con las ventajas que éstoaporta.

9.2 DESCRIPCIÓN GENERAL DE LA COMPAÑÍA

9.2.1 Misión

Proporcionar a instituciones educativas y empresas servicios y productos de experimen-tación remota efectivos, asequibles económica y técnicamente, generalizando así cono-cimientos y facilidades que anteriormente estaban reservados a unas pocas universida-des.

Aprovechar el conocimiento adquirido durante años de investigación en el campo de laexperimentación remota para consolidarse y mantenerse como una empresa líder.

Promover el desarrollo del campo de la experimentación remota, mejorando la tecnologíay creando conocimiento.

9.2.2 Visión

Los laboratorios remotos son una tecnología relativamente reciente. Hasta ahora, hanestado 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 solucio-nes.

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 deexperimentación remota, tecnología que hasta hace poco ha estado reservada sólo aunos pocos.

Un futuro en el que la educación de todos sea más cómoda, más práctica, más efectivay 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 queaporta, dentro del ámbito educativo nacional.

132

PROYECTO FIN DE CARRERA

9.1. Objetivo: Establecer relaciones con un número significativo de colegios delentorno de Bilbao. Dar a conocer la existencia de los sistemas de experimenta-ción remota y de sus ventajas a responsables de éstos centros, y al menos a unospocos profesores que impartan asignaturas con particular potencial para benefi-ciarse de dichas tecnologías en el futuro inmediato. Esto incluye actualmente aaquellos profesores que impartan asignaturas relacionadas con electrónica digital,circuitos electrónicos, informática básica, programación de microcontroladores yfísica. Los esfuerzos se centrarán principalmente en el ámbito de la electrónicadigital básica y de física (circuitos básicos).

9.2. Objetivo: Establecer relaciones con un número significativo de centros deformación profesional del entorno de Bilbao. Dar a conocer la existencia de lossistemas de experimentación remota y de sus ventajas a responsables de éstoscentros, y al menos a unos pocos profesores que impartan asignaturas con par-ticular potencial para beneficiarse de dichas tecnologías en el futuro inmediato.Esto incluye actualmente a aquellos profesores que impartan asignaturas relacio-nadas con electrónica digital, circuitos electrónicos, informática básica, programa-ción de microcontroladores y física. Los esfuerzos se centrarán principalmente enel ámbito de la programación de microcontroladores, de la electrónica digital y delos circuitos electrónicos.

10. Meta: Desarrollar un modelo de servicio que permita a los clientes acceder a facilida-des de experimentación remota sin necesidad de contar con personal técnico de ningunaclase, y sin necesidad de gestionar técnicamente su laboratorio remoto.

10.1. Objetivo: Aprovechar las capacidades de federación existentes del Labo-ratorio Remoto (y extenderlas si es necesario) para que el equipo de la empre-sa pueda fácilmente crear y gestionar laboratorios remotos para los clientes, quepuedan ser hospedados y gestionados técnicamente en instalaciones de la propiaempresa. Evitar que se requiera cualquier clase de infraestructura en las depen-dencias de los clientes.

10.2. Objetivo: Continuar mejorando las capacidades e interfaces de adminis-tración del Laboratorio Remoto (WebLab-Deusto) de tal modo que los clientespuedan, sin necesidad de conocimientos técnicos, administrar su laboratorio re-moto de forma efectiva, y minimizando la necesidad de requerir ayuda específicade personal de la empresa.

10.3. Objetivo: Gestionar todo el proceso de creación y gestión de los laborato-rios. El cliente sólo necesitará especificar qué experimentos requiere su labora-torio. La empresa llevará acabo las operaciones requeridas, incluyendo compray montaje de servidores y equipos de experimentación específicos, instalación yprueba de software, despliegue y gestión técnica del laboratorio.

10.4. Objetivo: Hospedar todos los laboratorios en la empresa, evitando que elcliente necesite mantener ninguna clase de infraestructura o equipamiento en suspropias dependencias (a no ser que por cualquier circunstancia especial requieralo contrario).

133

9. POSIBLE PLAN DE NEGOCIO

11. Meta: Extender a nuevas áreas el alcance de la experimentación remota ofrecida porla empresa, de acuerdo a las necesidades aún no satisfechas de los clientes.

11.1. Objetivo: Averiguar campos nuevos que pueden hacer uso de experimenta-ció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 satisfacernecesidades insatisfechas detectadas en nuevas áreas.

12. Meta: Desarrollar un modelo de colaboración con los centros educativos para la crea-ció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 desa-rrollo de experimentos nuevos que requieran en sus cursos. Dichas iniciativas se-rán financiadas en parte por la empresa y en parte por dichos centros, dependien-do de cada caso específico y de las prospectivas o acuerdos que se establezcanpara proporcionarles posteriormente servicios relacionados.

9.3 FILOSOFÍA DEL NEGOCIO

La Empresa está comprometida a mejorar la educación, tanto tradicional como a distan-cia, a través de tecnologías y servicios de experimentación remota, esforzándose pa-ra poner al alcance del mayor público posible equipamiento al que de otro no tendríanacceso, posibilitando una formación práctica que de otro modo sólo habría podido serteórica.

Se dará a conocer la experimentación remota a centros educativos nacionales, incluyen-do colegios, centros de formación profesional y universidades, pero, si las circunstanciaslo permiten, se realizarán también esfuerzos orientados a aumentar el ámbito internacio-nalmente.

La experimentación remota es un mercado muy nuevo. Hasta hace poco limitado al ámbi-to académico, y de naturaleza muy experimental. No obstante, podemos esperar un grancrecimiento. El auge de la formación a distancia y el actual éxito de los MOOC (CursosOnline Masivos y Abiertos) es innegable. Las empresas y los estudiantes demandan a loscentros educativos formación cada vez más práctica y especializada. El entorno, en defi-nitiva, garantiza un interés y potencial creciente en los laboratorios y la experimentaciónremota.

La Empresa, directamente relacionada con la Universidad de Deusto y con el desarrollode la infraestructura de laboratorios remotos WebLab-Deusto, está en una posición únicapara aprovechar el crecimiento de este mercado. Los años de experiencia en experimen-tación remota y desarrollo de experimentos, que han situado a WebLab-Deusto comouno de los mejores laboratorios remotos del mundo, garantizan una posición en la cimade este mercado emergente.

134

PROYECTO FIN DE CARRERA

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 experimen-tación remota:

13. Hardware

13.1. Servidores: De diversos tipos. Se necesita uno o varios servidoresWeb, servidores para los experimentos, etc.

13.2. Red: Se necesita una potente infraestructura de red, capaz de dar unservicio de calidad y fiable a los usuarios del laboratorio, que acceden a élnecesariamente por éste medio, y capaz de dar soporte a las necesidadesde comunicación interna del laboratorio.

13.3. Equipamiento habitual de experimento: La mayor parte de experi-mentos 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: Lamayor parte de experimentos necesitanalguna clase de equipo específico, que es el foco del experimento. Porejemplo, los experimentos FPGA necesitan, lógicamente, una placa FPGAsobre la que experimentar.

14. Software

14.1. Básico: Software de uso general, incluyendo bases de datos, servi-dores Web, entornos de ejecución, etc.

14.2. Laboratorio Remoto: Software base del laboratorio remoto, como elnú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 deexperimento) propia.

Dada la naturaleza y complejidad de un laboratorio remoto, la adquisición del equipa-miento descrito no es suficiente por sí sóla.

En el empleo real de un laboratorio remoto están involucradas muchos procesos y acti-vidades:

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

9. POSIBLE PLAN DE NEGOCIO

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, yamplios conocimientos técnicos.

La mayor parte de usuarios potenciales de laboratorios remotos, es decir, institucioneseducativas de tamaño pequeño o medio, no disponen de los recursos necesarios paraadquirir todos los servidores y equipos, y mucho menos del conocimiento y experienciarequerida para el despliegue con éxito de un laboratorio.

Tales conocimientos han estado, hasta ahora, reservados a un pequeño número de uni-versidades con proyectos de investigación abiertos en el área.

Una de éstas universidades es, de hecho, la Universidad de Deusto, cuyo laboratorioremoto de código abierto WebLab-Deusto es uno de los primeros del mundo, y la basede los servicios ofrecidos por esta empresa.

El fin de la empresa es, por tanto, proporcionar a sus clientes (centros educativos) labo-ratorios 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é tipode experimentos requiere en su laboratorio (WebLab-Deusto soporta ya de por sí muydistintos 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 experi-mento que el cliente requiera, así como de su número, y del número de usuarios quenecesite soportar. En general, el cliente deberá correr con ese gasto, aunque la Empresagestionará la compra. En ocasiones, si el equipamiento es genérico y el cliente aceptaque pertenezca a la Empresa (como servidores, etc) la empresa correrá con una partedel gasto, ya que en caso de que las relaciones con dicho cliente terminen, podrá serreutilizado 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 clientede 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 conceptostales como la provisión del espacio necesario para el equipo, la energía consumida, elmantenimiento, la gestión técnica, las actualizaciones, etc.

136

PROYECTO FIN DE CARRERA

9.5 PLAN DE MARKETING

9.5.1 Mercado

El mercado de la experimentación remota es muy nuevo. Si bien los laboratorios remo-tos existen desde hace tiempo, su ámbito ha sido en general muy reducido, limitándosea dar soporte a un sólo tipo de experimento y estando sólo al alcance de unas pocasinstituciones (generalmente, las que han desarrollado el laboratorio específico).

Hoy en día, sin embargo, cohexisten varios factores que sugieren que la ExperimentaciónRemota 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 favo-recen el desarrollo de la Experimentación Remota.

Por un lado, el acceso a Internet puede considerarse hoy en día como prácticamenteuniversal en los países desarrollados. Esto permite a prácticamente cualquier personaacceder a un Laboratorio Remoto. Los posibles usuarios o clientes de tales laboratoriosserían, por tanto, extremadamente numerosos.

Por otro lado, los avances tecnológicos específicos en Laboratorios Remotos son tambiénmuy significativos. Hoy en día existen laboratorios remotos genéricos, como WebLab-Deusto, con diversas características clave que garantizan su potencial:

Genéricos:Diseñados para soportar cualquier clase de experimento [32]. Desde experimentoselectrónicos, a experimentos físicos o biológicos. La flexibilidad que esto aportahace que puedan ser útiles en prácticamente cualquier campo del conocimientoque implique experimentación.

Escalables y multiplataforma:Un framework genérico de Laboratorios Remotos comoWebLab-Deusto puede hoyen día soportar un gran número de usuarios, y permite el desarrollo de experimentosen múltiples tecnologías y plataformas [33].

Interoperables:Existen varios frameworks de laboratorios remotos distintos. Este hecho tradicio-nalmente ha obstaculizado el compartir experimentos entre instituciones distintas,limitando seriamente el potencial de la experimentación remota, ya que dichas ins-tituciones tienden a tener recursos limitados a la hora de implementar experimen-tos. El no poder compartirlos, además, implica en general que estarán en mayoro menor medida infrautilizados. Sin embargo, en la actualidad se están realizandoesfuerzos para la interoperabilidad [49][28]. WebLab-Deusto, en concreto, sopor-ta interoperabilidad con otro de los principales laboratorios remotos: iLabs, de MIT[34].

137

9. POSIBLE PLAN DE NEGOCIO

9.5.1.2 Nuevas tendencias

Figura 9.1.: Search volume for Cour-sera (red) and MOOC(blue), as reported byGoogle

Se han identificado dos nuevas tendencias muy re-lacionadas con el campo de la Experimentación Re-mota, que auguran un rápido crecimiento para és-ta.

∎ Auge de los MOOCs y la formación a distan-cia

Los denominados MOOC, Cursos Online Masivosy Abiertos, son cursos gratuitos impartidos a tra-vés de una plataforma educativa en Internet. Enla actualidad, están experimentando un enormedesarrollo. El más conocido es quizás Coursera[7].

Es de esperar que el desarrollo de la formación adistancia y de la MOOCs en concreto promueva asu vez la popularidad de los laboratorios remotos,ya que ésta es una manera adecuada (y de hecho,en general, la única) de añadir experimentación reala un curso MOOC.

9.5.2 Producto

En secciones posteriores se describió el servicio principal de la empresa desde su propiaperspectiva. 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 La-boratorio Remoto, siguiendo las especificaciones del cliente en cuanto a tipos ynú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 expe-rimentos nuevos.

Todo el equipamiento se ubica en dependencias de la Empresa.

La Empresa gestiona técnicamente el Laboratorio y asegura su correcto funciona-miento.

El cliente mantiene control sobre su laboratorio a través de un panel de administra-ción.

138

PROYECTO FIN DE CARRERA

El servicio supone numerosos beneficios para el cliente. Algunos se derivan del hechode 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 modoestarí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 necesidadesde más usuarios, ya que su uso se distribuye en el tiempo.

Eficaz y realista: Es equipamiento real, controlado remotamente, de forma que pue-de ser tan eficaz como un laboratorio presencial.

No supervisado: No es necesario tener personal supervisando constantemente eluso 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 experi-mentos o modificar experimentos existentes.

No es necesario personal con conocimientos técnicos para el mantenimiento de losservidores 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 lanecesidad de desplazamientos.

El coste de mantener localmente, sin ayuda, un Laboratorio Remoto, sería prohibi-tivo para la mayor parte de instituciones (que no cuentan con recursos técnicos nihumanos apropiados).

9.5.3 Clientes

Podemos identificar varios segmentos de clientes:

Colegios

Centros de Formación Profesional

Universidades

Industria

139

9. POSIBLE PLAN DE NEGOCIO

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ásnumeroso. 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ónremota en concreto, está limitada a un conjunto pequeño de las asignaturas que impar-ten.

Además, el área concreta en la que WebLab-Deusto (y la mayor parte de LaboratoriosRemotos actuales) sobresalen es la electrónica y campos relacionados con ésta. En laactualidad los colegios imparten pocas asignaturas de estas características.

No obstante, es un sector numeroso y sigue existiendo un potencial notable, de modo seorientarán esfuerzos significativos a este sector, y se promoverá el desarrollo de nuevosexperimentos 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 decolegios. 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 suproceso formativo. Esto hace que el potencial de los laboratorios remotos en su ámbitosea especialmente significativo.

Además, los centros suelen ser de tamaño pequeño, de modo que en general no tienendemasiados recursos o personal técnico disponible, necesario para comprar y mante-ner equipamiento en general, y una infraestructura de laboratorios remotos en concre-to.

El empleo de laboratorios remotos les permitiría ahorrar costes compartiendo hardwarey equipos entre diferentes centros.

Recurriendo a los servicios de la Empresa, un centro de formación profesional puedeacceder a las ventajas de un laboratorio remoto de forma económica, sin necesidad depreocuparse de mantener infraestructuras y sin prácticamente dificultades.

Por estosmotivos, 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 quelos colegios o que los centros de formación profesional. Por este motivo, tendrían, en

140

PROYECTO FIN DE CARRERA

principio, una mayor capacidad para mantener una infraestructura propia de LaboratoriosRemotos.

Sin embargo, sin el conocimiento especializado y experiencia en el campo de la experi-mentación remota de los que sólo un pequeño número de universidades dispone, resultamuy improbable lograr con un esfuerzo razonable un despliegue exitoso de un laboratorioremoto.

Para tales universidades, resulta mucho más práctico, económico y viable llegar a acuer-dos 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 Em-presa. Asimismo, es posible que dichas universidades estén dispuestas a dedicar ciertosesfuerzos de investigación para el desarrollo de nuevos experimentos, lo que beneficiaríatanto a dicha universidad, como a la Empresa, y como al campo de la experimentaciónremota en general.

9.5.3.4 Industria

Existen diversas empresas que podrían beneficiarse de experimentación remota, ya seapormotivos formativos o por necesidades industriales específicas. Sin embargo, el ámbitode 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, yexisten diferencias muy notables con respecto a los otros segmentos, de momento quedafuera de los objetivos inmediatos de la empresa el ofrecer servicios orientados a estesegmento.

A largo plazo, sin embargo, se tratarán de analizar y comprender mejor las necesidadesde este segmento, y se evaluará en qué medida es posible a la Empresa satisfacerlascon 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ónde servicios de Experimentación Remota con fines educativos a tres segmentos similaresde clientes:

Colegios

Centros de Formación Profesional

Universidades

141

9. POSIBLE PLAN DE NEGOCIO

9.5.5 Estrategia

9.5.5.1 Promoción

Considerando la naturaleza business-to-business de la Empresa, y la naturaleza de losservicios que presta, la mayor parte de la promoción será directa.

Se contactará con responsables de los centros educativos o con profesores de éstosque impartan asignaturas que puedan beneficiarse de experimentación remota, segúnse considere más adecuado dependiendo del caso.

Actualmente la tecnología de experimentación remota es novedosa, y sus capacidadesson en general poco conocidas. Por ésto, se incidirá particularmente en transmitir infor-mació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 ex-perimentación remota en eventos tales como ferias o conferencias relacionadas con laeducació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, paraque los potenciales clientes comprendan sus beneficios y puedan demandar losservicios de la Empresa

Promover los servicios de la Empresa como adecuados a las necesidades formati-vas 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 ser-vicio dependerán en cada caso, de modo que los precios exactos serán también distin-tos.

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 deequipamiento, las gestiones iniciales, el montaje, la instalación, el despliegue del labora-torio y en su caso, modificaciones al código de experimentos pre-existentes o desarrollode experimentos nuevos.

El importe periódico será abonado por el cliente en principio con periodicidad mensual otrimestral. Dicho importe cubre el espacio ocupado por los equipos, los gastos y esfuerzosde 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 Remo-tos son un sector emergente. La experiencia de los potenciales clientes (centros forma-

142

PROYECTO FIN DE CARRERA

tivos) con ellos es limitada. Por éste motivo, en general no estarán dispuestos a realizargrandes inversiones al respecto.

Se tratará deminimizar lo más posible el importe inicial, para que éste no disuada a los po-tenciales clientes. En su caso, la Empresa financiará parte de los equipos, especialmentesi dichos equipos pudieran ser reutilizados en otros proyectos. En ocasiones, además,laboratorios pertenecientes a distintos clientes podrán compartir parte del equipo, comociertos servidores. Si esto es posible, se sugerirá tal opción, de forma que se reduzca elimporte inicial.

En el importe periódico no existirán tales restricciones. Por lo novedoso del sector, si ellaboratorio remoto cumple con las expectativas, el cliente estará dispuesto a pagar unprecio razonablemente alto por los servicios prestados. Esto será especialmente ciertoen aquellos casos en los que el cliente haya conseguido un ahorro de costes significativogracias 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 clientesen los tipos de centros que se han descrito anteriormente. Se encargará también degestionar la relación con los clientes existentes, atendiendo sus posibles peticiones ysugerencias y solucionando sus posibles problemas.

El área de desarrollo se encargará de continuar mejorando la tecnología de laboratoriosremotos, creando características nuevas para la infraestructura WebLab-Deusto, desa-rrollando nuevas tecnologías relacionadas, creando nuevos experimentos, o mejorandolos actuales.

El tercer área se encargará de proporcionar a los clientes el servicio principal, que esla creación, mantenimiento y gestión de los laboratorios. En éste área se encuentranlas 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 quese necesitará un espacio adecuado para ello.

143

9. POSIBLE PLAN DE NEGOCIO

Los equipos serán principalmente servidores, equipos de red, dispositivos específicos yequipos específicos para cada experimento.

Se necesitará, por tanto:

Entorno a temperatura adecuada. Particularmente, debería existir refrigeración, pa-ra contrarrestar el calor producido por los equipos.

Suministro eléctrico de suficiente potencia, estable, y con dispositivos para la pre-vención de picos de voltaje. Idealmente, con un SAI (Sistema de Alimentación Inin-terrumpida), que prevenga que posibles fallos en el suministro afecten al serviciode los laboratorios.

Acceso a Internet de grado servidor, capaz de dar servicio a un gran número delaboratorios remotos, con necesidades altas de ancho de banda.

El espacio que se reservará será bastante amplio, ya que ciertos experimentos tienenrequisitos significativos de espacio.

Las necesidades para el resto de áreas de la empresa serán las usuales, necesitando unespacio de oficina estándar bien equipado para las actividades de gestión, desarrollo yrelació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 remo-tos.

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 re-querido por los laboratorios remotos.

A no ser que se trate de equipamiento específico, se tratará en general de que el equi-pamiento 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 consi-derado WebLab-Deusto. Es un proyecto de código abierto, relacionado de forma directacon la Empresa, y por tanto no tiene un coste.

144

PROYECTO FIN DE CARRERA

Con respecto a los equipamientos, tales como servidores y otro tipo de software, se re-currirá 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. Eneste momento, por ejemplo, muchos de los experimentos electrónicos están basadosen tecnologías de Xilinx Inc., tales como los experimentos FPGA o los experimentosCPLD.

Considerando estas características, no se espera que surjan particulares problemas conrespecto 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 clientestengan que realizar, con el objetivo de que una inversión inicial significativa no actúe paraellos como elemento disuasorio.

Por eso, en vez de créditos, la Empresa correrá con los gastos iniciales de equipamientode un cliente, o con una parte de éstos. En tales casos, la propiedad de tales equipamien-tos se mantendrá en la empresa. Si el cliente se mantiene en el tiempo, con los pagosperiódicos se terminará recuperando la inversión. Si no se mantiene, el equipamientopodrá ser utilizado para otros propósitos o para otros clientes.

El pago periódico por los servicios será mensual o trimestral.

145

PROYECTO FIN DE CARRERA

BIBLIOGRAFÍA

[1] Ronald T Azuma et al. A survey of augmented reality. Presence-Teleoperators andVirtual Environments, 6(4):355–385, 1997.

[2] A Baccigalupi, C De Capua, and A Liccardo. Overview on development of remoteteaching laboratories: from labview to web services. In Instrumentation and Measu-rement Technology Conference, 2006. IMTC 2006. Proceedings of the IEEE, pages992–997. IEEE, 2006.

[3] Boole-Deusto GitHub Repository [online]. URL: https://github.com/zstars/booledeusto/.

[4] Chrome Experiments [online]. URL: http://www.chromeexperiments.com/.

[5] Benjamin Coifman, David Beymer, PhilipMcLauchlan, and JitendraMalik. A real-timecomputer vision system for vehicle tracking and traffic surveillance. TransportationResearch Part C: Emerging Technologies, 6(4):271–288, 1998.

[6] Martyn Cooper. Remote controlled teaching experiments, in science and engineeringsubjects, accessible over the world-wide-web: the pearl project. In World Conferen-ce 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 naviga-tion: 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, registrationand specification for mixed reality systems. In Proceedings of the ACM symposiumon 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 4-dimensional augmented reality model for automating construction progress moni-toring data collection, processing and communication, 2009.

147

BIBLIOGRAFÍA

[14] Luís Gomes and Javier Garcia Zubía. Advances on remote laboratories and e-learning experiences. Universidad de Deusto, 2008.

[15] Google Driverless Car [online]. URL: http://en.wikipedia.org/wiki/Google_driverless_car/.

[16] C. Gravier, J. Fayolle, B. Bayard, M. Ates, and J. Lardon. State of the art aboutremote laboratories paradigms-foundations of ongoing mutations. iJOE, 4(1), 2008.

[17] I. Gustavsson, J. Zackrisson, L. Håkansson, I. Claesson, and T. Lagö. The visirproject–an open source software initiative for distributed online laboratories. In Pro-ceedings 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 Jour-nal, 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 infrastructureto 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 missionrehearsal. 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 andEducation (ICDLE), 2010 4th International Conference on, pages 170–173. IEEE,2010.

[26] Claude Laurgeau. Present and future of intelligent transportation systems. In Pro-ceedings of ICAT 2008, international conference on automotive technologies, 2008.

[27] D. Lowe, T. Machet, and T. Kostulski. Uts remote labs, labshare, and the saharaarchitecture. Using Remote Labs in Education: Two Little Ducks in Remote Experi-mentation, page 403, 2012.

[28] D. Lowe and H. Yeung. Remote laboratory systems interoperability standard: Inter-face definitions. RFC of the Technical Committee of the Global Online LaboratoryConsortium, 2011.

[29] P Murray. Will ‘free’and ‘open’rule the day as the future of online education. OnlineJournal of Nursing Informatics (OJNI), 16(3), 2012.

148

PROYECTO FIN DE CARRERA

[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 experi-ment 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ópez-de Ipiña. Adding new features to new and existing remote experiments through theirintegration 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 LHardison, Kimberly DeLong, and V Judson Harward. Achieving interoperabilityamong educational remote laboratories. In 5th World Summit on the KnowledgeSociety, 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. In-ternational 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 contro-lling laboratory real devices: A new trend in teaching and learning in engineering.ITHET2000, Istanbul, July3-5, 2000.

[41] SCORE Business Plan Template [online]. URL: http://www.score.org/resources/business-plan-startup-pdf.

[42] Neal E Seymour, Anthony G Gallagher, Sanziana A Roman, Michael K O’Brien, Vi-pin K Bansal, Dana K Andersen, and Richard M Satava. Virtual reality training im-proves 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 designand development. Design Studies, 31(2):118–145, 2010.

[44] WebLab-Deusto: Descripción Técnica [online]. URL: https://weblabdeusto.readthedocs.org/en/latest/technical.html.

[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 Technologyand Management Engineering, 2009. FITME’09. Second International Conferenceon, 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, andMark Billinghurst. Trends in augmented realitytracking, interaction and display: A review of ten years of ismar. In Proceedings ofthe 7th IEEE/ACM International Symposium onMixed and Augmented Reality, pages193–202. IEEE Computer Society, 2008.

[51] J García Zubia, J Sanz Martínez, and Borja Sotomayor. Boole-deusto, la aplicaciónpara sistemas digitales, 2001.

[52] Javier García Zubía. Educational software for digital electronics: Boole-deusto. InMi-croelectronic Systems Education, 2003. Proceedings. 2003 IEEE International Con-ference on, pages 20–22. IEEE, 2003.

150

PROYECTO FIN DE CARRERA

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

PROYECTO FIN DE CARRERA

B. GLOSARIO

AJAX (Asynchronous JavaScript and XML):Grupo de técnicas de desarrollo web utilizadas para la creación de aplicaciones webasíncronas.

Bitstream:Tipo de archivo utilizado para describir la información de configuración de un dispositivoFPGA o similar. La información de configuración es, en esencia, la lógica que dichodispositivo 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). Desa-rrollado en la Universidad de Deusto. Se describe en más detalle en la sección deAntecedentes del presente documento.

Borland C++ Builder:Entorno de desarrollo en C++ creado por Borland, empresa que en el momento deescribir esto ya no existe como tal. Es un RAD (entorno de desarrollo rápido), e incluyelibrerí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 lasimplementaciones son compatibles entre sí y algunas añaden funcionalidades y libreríasque 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 puedenacceder, observar e interactuar. Los experimentos más comunes en la actualidad sonelectrónicos. Un experimento puede ser, por ejemplo, una placa con un dispositivoFPGA, 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 experimentosentre diferentes “instancias” de WebLab-Deusto, o incluso con otros laboratorios remotosdiferentes.

FitPC:Modelos de ordenadores personales fabricados por la empresa CompuLab caracteríza-dos por tener las características básicas de un portátil o equipo de sobremesa estándarpero 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 determinado el proceso de manufactura. Su configuración suele especificarse medianteun lenguaje de descripción de hardware. Frecuentemente son reconfigurables (puedenser configurados más de una vez), como es el caso de los FPGA utilizados comoexperimento en WebLab-Deusto.

GWT (Google Web Toolkit):Tecnología de Google que permite describir un cliente Web en Java y compilarlo aJavaScript para que sea verdaderamente utilizable en un navegador. WebLab-Deustoutiliza 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 deproducción de Deusto. También pueden considerarse instancias las implantacioneslocales 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íasWeb 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 generadospor ordenador. De este modo, la tecnología de realidad aumentada complementa larealidad.

154

PROYECTO FIN DE CARRERA

Modelo virtual:Simulación por software de algún sistema real, tal como un depósito de agua, o unalínea de montaje. En este trabajo, las simulaciones hacen referencia a sistemas que noexisten físicamente en la realidad (son creaciones gráficas tridimensionales), pero cuyoestado lo determina un controlador real, y cuyas salidas tienen efecto en ese mismocontrolador 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ñadecaracterí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 estetrabajo, se tratará principalmente sobre sistemas digitales binarios. Se dividen en dosgrupos: 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. Facilitala 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 describirsistemas digitales y de señal mixta, como circuitos integrados o FPGAs (ver FPGA). Losarchivos 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ásdetalle en la sección de Antecedentes del presente documento.

Xilinx:Compañía tecnológica americana. Es uno de los principales fabricantes de dispositivosló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

PROYECTO FIN DE CARRERA

C. AGRADECIMIENTOS

Para concluir este proyecto, me gustaría agradecer brevemente a todas las personas quede 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 enWebLab-Deusto, por la tutela, apoyo y confianza queme ha proporcionado durante los cuatro añosque he colaborado con el equipo, y por supuesto, por haber dirigido con entusiasmo esteproyecto.

Se merece también mi más sincero agradecimiento Pablo Orduña. Durante estos cua-tro años, siempre ha encontrado tiempo para ayudarme, aconsejarme y para compartirconmigo su -muy amplio- conocimiento y experiencia. Una de las personas más capacesque 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, porel apoyo y el gran trabajo que han hecho.

Por último -pero no menos importante- me gustaría agradecer especialmente a mi familiay a mis amigos la confianza, compañía y apoyo que me han prestado.

157

PROYECTO FIN DE CARRERA

D. PUBLICACIONES

Tal y como se ha mencionado en el capítulo de Contexto, el autor de éste documento, alo largo de sus cuatro años de colaboración con el equipo de investigación de WebLab-Deusto, ha participado en diversas publicaciones. Algunas de éstas tratan directamentesobre Boole-WebLab-Deusto, mientras que otras se centran en diferentes aspectos dellaboratorio remoto WebLab-Deusto, y de forma más indirecta han llevado a la consecu-ció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 deldocumento:

1. Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Pablo Orduña, Olga Dz-biabenko. 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 Dz-biabenko. Boole-WebLab-Deusto: Integration of a remote lab in a tool for digitalcircuits design. (2013). Submitted for publication.

3. Javier Garcia-Zubia, Luis Rodriguez-Gil, Pablo Orduña, Ignacio Angulo, Unai Her-nandez, Olga Dziabenko, Mari Luz Guenaga. An Integrated Solution for Basics Di-gital Electronics: Boole-DEUSTO and WebLab-DEUSTO. REV2013: 10th Inter-national 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. Ad-vanced integration of OpenLabs VISIR (Virtual Instrument Systems in Reality) withWeblab-Deusto. Remote Engineering & Virtual Instrumentation. REV2012. Bilbao,Spain. July 2012.

5. Pablo Orduña, Jaime Irurzun, Luis Rodriguez-Gil, Javier Garcia-Zubia, Diego Lopez-de-Ipiña Reusing requirements among remote experiments for their development andintegration under WebLab-Deusto. REV 2011: 8th International Conference on Re-mote Engineering and Virtual Instrumentation. Brasov, Romania, July 2011.

6. Pablo Orduña, Jaime Irurzun, Luis Rodriguez-Gil, Javier Garcia-Zubia, FabricioGazzola, Diego López-de-Ipiña. Adding New Features to New and Existing RemoteExperiments through their Integration in WebLab-Deusto. International Journal ofOnline 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 elcontexto del equipo de investigación de WebLab-Deusto que no se han incluido comoanexos pero que resulta relevante listar son:

1. Pablo Orduña, Luis Rodriguez-Gil, Diego López-de-Ipiña, Javier Garcia-Zubia. Sha-ring Remote Labs: A Case Study. International Journal of Online Engineering - iJOE9(Special Issue: REV2012 Exhibition). 26 – 27. 2013.

2. Pablo Orduña, Xabier Larrakoetxea, David Buján, Aitor Gómez-Goiri, Ignacio An-gulo, Olga Dziabenko, Luis Rodriguez-Gil, Diego López-de-Ipiña, Javier Garzia-Zubia. WebLab-Deployer: exporting remote laboratories as SaaS through federationprotocols. REV2013: 10th International Conference on Remote Engineering and Vir-tual Instrumentation. Sydney, Australia, 6 - 8 February 2013.

3. Javier García-Zubía, Pablo Orduña, Ignacio Angulo, Unai Hernández, Olga Dziaben-ko, Luis Rodríguez, María Luz Güenaga, Ingvar Gustavsson. Remote Laboratories:Opportunities and Challenges. The World of Sustainable Laboratories, WOSLAB2012. 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ópez-de-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. Sha-ring the remote laboratories among different institutions: a practical case. RemoteEngineering & Virtual Instrumentation. REV2012. Bilbao, Spain. July 2012.

6. Pablo Orduña, Javier Garcia-Zubia, Luis Rodriguez-Gil, Ignacio Angulo, Olga Dzia-benko, Diego López-de-Ipiña. Exploring students collaboration in remote laboratoryinfrastructures. Remote Engineering & Virtual Instrumentation. REV2012. Bilbao,Spain. July 2012.

7. Javier Garcia-Zubia, Bruno Campos, Pablo Orduña, Luis Rodriguez, Ignacio An-gulo, Olga Dziabenko. Easily Deployable Low-Cost Remote Lab Platform.. RemoteEngineering & Virtual Instrumentation. REV2012. Bilbao, Spain. July 2012.

8. Pablo Orduña, Javier García-Zubia, Fabricio Gazzola, Luis Rodriguez-Gil, JaimeIrurzun, Diego López-de-Ipiña. Using LabVIEW Remote Panel in Remote Labora-tories: advantages and disadvantages. IEEE EDUCON 2012. Marrakesh, Morocco,April 2012. Page(s): 1 - 7. DOI: 10.1109/EDUCON.2012.6201134. ISBN: 978-1-4673-1457-2.

9. Javier Garcia-Zubia, Ingvar Gustavsson, Unai Hernandez-Jayo, Pablo Orduña, Igna-cio 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

PROYECTO FIN DE CARRERA

10. Javier García-Zubía, Pablo Orduña, Unai Hernández, Ignacio Angulo, Olga Dzia-benko, Luis Rodriguez-Gil and Diego López-De-Ipiña. WebLab-Deusto-CPLD: APractical Experience. 1st Experiment@ International Conference (expat2011). 2011.

11. Javier Garcia-Zubia, Pablo Orduña, Ignacio Angulo, Unai Hernandez, Olga Dziaben-ko, Diego Lopez-de-Ipiña, Luis Rodriguez-Gil. Application and User Perceptions ofUsing the WebLab-Deusto-PLD in Technical Education. 41st ASEE/IEEE Frontiersin 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, UnaiHernandez, Ignacio Angulo, Olga Dziabenko, Luis Rodriguez-Gil Using VISIR atthe University of Deusto: experiments, subjects and students. REV 2011: 8th Inter-national 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. Rodriguez-Gil. Justificación, propósito y ventajas de un laboratorio remoto. III Foro Interna-cional sobre Innovación Docente. Bilbao, Julio 2011.

14. Pablo Orduña, Javier García-Zubia, Jaime Irurzun, Diego López-de-Ipiña, Luis Rodriguez-Gil. 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/EDU-CON.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: whatis expected from a remote lab? REV2010. Stockholm, Sweden. 2010. ISBN: 978-3-89958-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]

Pablo Orduna (IEEE member), Olga Dziabenko

Deusto Institute of Technology

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 bit-level 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

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 Boole-Deusto [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 Boole-Deusto 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).

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

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

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. 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. 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”

Fig. 8. Moore Finite State Machine

After drawing the FSM, the student can minimize it or obtain the truth tables (Fig. 9).

Fig. 9. FSM truth tables

The next step is to obtain the digital circuit (Fig. 10).

Fig. 10. FSM digital circuit with JK flip-flops

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

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.

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.

The inputs (switches, buttons and clock) are controlled with a PIC Microcontroller of Microchip.

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 WebLab-Deusto-Box was awarded in ICELIE/IECON 2009 for Best Educational Tool [15] has been deployed in different universities, including the MIT (USA).

Fig. 12. WebLab-Deusto-Box for FPGA

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.

Fig. 13. WebLab Mode for combinational systems

When users are in WebLab Mode they may then assign, for instance, switches as inputs and leds or seven_seg (seven-segment displays) as outputs. After this, users should:

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.

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. 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 seven-segment 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

with 0000 as input, the led output is off because 0000 is a BCD combination.

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

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

Fig. 23 shows the lit led after introducing four 1s in through the Switch 0.

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

Fig. 23. Boole-Deusto and Weblab-Deusto integration

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, Boole-Deusto 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 Boole-Deusto 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] http://www.labcenter.com/index.cfm

[2] http://www.interactiv.com/

[3] http://www.electronics-lab.com/

[4] http://k-map.sourceforge.net/

[5] 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.

[6] Gomes, L.; Bogosyan, S. “Current trends in remote laboratories”, Trans. on Industrial Electronics, VOL. 56, Issue. 12, pp: 4744 – 4756, 2009.

[7] 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

[8] 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

[9] Azad, A.; Auer, M.; Harward, J. Internet Accessible Remote Laboratories, Ed. IGI Global, 645 pp, 2012.

[10] http://weblab.deusto.es/boole/BOOLE_RELEASE_EN.zip

[11] Boole-Deusto project page: https://github.com/zstars/booledeusto

[12] http://www.weblab.deusto.es

[13] Garcia-Zubia, J. “Educational software for digital electronics: Boole-Deusto”, Proc. of IEEE Int. Conf. on Microelectronic Systems Education, pp:20 – 22, 2003.

[14] 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.

[15] 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.

[16] 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) 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

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

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.

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

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

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

No. 518987-LLP-1-2011-1-ES-KA3-KA3MP funded with support from the Lifelong Learning Programme (KA3 - ICT) from European Union

(FSM) and finishes with the digital circuit implemented with flip-flops (Fig. 3).

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

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. 6. BCD-ERROR system in WebLab-Deusto, running properly.

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] Garcia-Zubia, J. “Educational software for digital electronics: Boole-

Deusto”, Proc. of IEEE Int. Conf. on MSE, pp: 20 – 22, 2003. [2] paginaspersonales.deusto.es\zubia

1

An Integrated Solution for Basics Digital Electronics: Boole-DEUSTO and WebLab-

DEUSTO 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 Faculty of Engineering - University of Deusto, Bilbao, Spain 2 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 BOOLE-DEUSTO 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).

II. 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.

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.

2

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

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 4. AND-OR and NAND digital circuits

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 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. RELATION BETWEEN INPUTS/OUTPUTS AND PINS OF THE CPLD&FPGA BOARDS

Inputs FPGA pin

CPLD pin

Outputs FPGA pin

CPLD pin

switch 5 E15 P66 led 5 N12 P6

switch 4 E16 P67 led 4 P13 P5

switch 3 F15 P68 led 3 N14 P4

switch 2 G15 P69 led 2 L12 P3

switch 1 G16 P71 led 1 P14 P2

switch 0 H15 P70 led 0 K12 P1

The UCF with the assignation for the BCD error

detector is in Fig. 6. It is a very simple txt file.

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.

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 8. FSM's descriptions: digital circuit and VHDL program

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].

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 9. WebLab-Deusto web page with the experiments available

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.

4

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 BOOLE-DEUSTO 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 WebLab-Deusto-FPGA (or the JEDEC file for the WebLab-Deusto-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.

BOOLE-DEUSTO

weblab.deusto.es

VHDL file

ucf file

ISE Xilinx bit/jedecfile

BOOLE-DEUSTO

weblab.deusto.es

VHDL file

ucf file

ISE Xilinx bit/jedecfile

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 WebLab-Deusto, 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 projector- all 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 WebLab-DEUSTO 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 WebLab-DEUSTO. 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.

5

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 WebLab-DEUSTO 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-KA3-KA3MP). 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] http://paginaspersonales.deusto.es/zubia/ [2] Garcia-Zubia, J. 2003. “Educational software for digital

electronics: BOOLE-DEUSTO”, IEEE Int. Conf. Microelectronics Systems Education, MSE 2003, Anaheim (USA).

[3] http://www.xilinx.com/support/download/index.htm [4] http://www.digilentinc.com [5] http://www.weblab.deusto.es [6] http://code.google.com/p/weblabdeusto/ [7] Garcia-Zubia, J. and Alves, G. eds. 2011. Using remote labs in

education. Ed. University of Deusto, ISBN: 978-84-9830-335-3 [8] Gomes, L. and Bogosyan, S. 2009. “Current trends in remote

laboratories”. Trans. On Industrial Electronics, VOL. 56, Nr. 12, pp: 4744 – 4756.

[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, Faculty of Engineering, Avda de las Universidades 24, 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, Faculty of Engineering, Avda de las Universidades 24, 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]).

OLAREX project. No. 518987-LLP-1-2011-1-ES-KA3-KA3MP funded with support from the Lifelong Learning Programme (KA3 - ICT) from European Union

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 1 Faculty of Engineering, University of Deusto, Bilbao, Spain

2 DeustoTech – Deusto Institute of Technology, University of Deusto, Bilbao, Spain

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

Deusto, 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.

Index Terms— remote-labs, integration, VISIR

I. INTRODUCTION Nowadays, Remote Laboratory Management Systems

such as MIT iLabs [1], Labshare Sahara [2] or Weblab-Deusto [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

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.

VISIR, as a domain-specific laboratory, implements several layers of functionality that are actually common to all remote laboratories, such as user management,

Figure 1. VISIR’s hardware and equipment server. Through this means, circuits are physically built through the use of relays. [5]

REV2012 04 - 06 July, Bilbao

www.rev-conference.org 291

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

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.

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 real-time and move it around.

Figure 3. One of WebLab-Deusto robotics experiments (on a mobile phone, at night, video stream provided by an infrared

camera).

Figure 2. VISIR architecture. Organization of the online

laboratories. [5]

REV2012 04 - 06 July, Bilbao

www.rev-conference.org 292

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.

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 Weblab-Deusto, 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 Weblab-Deusto, 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.

Figure 4. WebLab-Deusto architecture. Experiment servers are

hosted in the Laboratory servers.

REV2012 04 - 06 July, Bilbao

www.rev-conference.org 293

The first table lists the three approaches that we have considered: Shallow integration, authentication-only integration, and deep integration.

The second table specifies which features are supported

by each approach, and which are not.

The third table lists which of the four VISIR

components need to be modified to implement each approach.

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 re-implement 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

TABLE I. CONSIDERED APPROACHES

Approach Involves A Shallow Embedding the whole, standard VISIR website. B Auth-only Replacing the authentication procedure of VISIR

(implemented in the VISIR web layer). C Deep

(chosen) Replacing the whole web layer and proxying all communication through the RLMS.

TABLE II. SUPPORTED FEATURES

A B C Accessible through the RLMS a Yes Yes Yes Smooth user experience No Yes Yes Logging & auditing No No Yes Full experiment control b No No Yes

Extended features c No No Yes

a Remote Laboratory Management System. Weblab-Deusto, in our case. b 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.

TABLE III. CHANGES REQUIRED TO VISIR (COMPLEXITY)

A B C Web layer (minor changes) No Yes Yes Web layer (major changes) No Yes Yes Flash client No No Yes Other components a No No No

a Particularly, the equipment and measurement servers. None of the methods requires to changes to those.

REV2012 04 - 06 July, Bilbao

www.rev-conference.org 294

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 Weblab-Deusto 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

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.

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.

Figure 5. VISIR and the circuits list, on the lower left.

REV2012 04 - 06 July, Bilbao

www.rev-conference.org 295

Through the interceptor, for instance, we intercept “library.xml” requests in order to dynamically provide a library.xml depending on the experiment. Thus, Weblab-Deusto 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 WebLab-Deusto database.

Through WebLab-Deusto, it is now even possible to access VISIR from Facebook or through LMSs such as Moodle.

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] 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. 931-950, 2008.

[2] R. Sarukkalige, E. Lindsay, and A. Anwar, “Laboratory demonstrators perceptions of the remote laboratory implementation of a fluid mechanics laboratory,” 2010.

[3] 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 weblab-deusto,” International Journal of Online Engineering (iJOE), vol. 7, no. S2, pp. pp–33, 2011.

[4] D. Garbi Zutin, A VISIR Lab Server for the iLab Shared Architecture. International Journal of Online Engineering (iJOE). 7(5). 2011.

[5] 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.

Figure 6. VISIR running in Facebook through Weblab-Deusto.

REV2012 04 - 06 July, Bilbao

www.rev-conference.org 296

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 (e-mail: [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]).

REV2012 04 - 06 July, Bilbao

www.rev-conference.org 297

1

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 VISIR

1 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 laboratories

2. 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 Sahara

5

platform has been developed, and it has recently created the LabShare Institute

6 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 (GOLC

8) 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 WebLab-Deusto, 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

3 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/

2

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

DEUSTO

A. Introduction WebLab-Deusto

9 is an Open Source

10 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/

10 http://code.google.com/p/weblabdeusto/

• 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.

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

Figure 1: FPGA experiment running in WebLab-Deusto

3

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 7-segment display that students will see through the webcam.

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.

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 WebLab-Deusto, 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.

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/

Figure 4: Managed and unmanaged experiments in WebLab-

Deusto platform

Figure 3: Virtual Machine managed by WebLab-Deusto, showing

a dummy LabVIEW experiment

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)

4

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 WebLab-Deusto, 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 Service

12–) 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

5

As any rig management framework, WebLab-Deusto

clearly separates the experiment management from the experiment development, which tends to be domain-specific.

In terms of management, WebLab-Deusto is extensively used with students. Therefore, there was the need to create administration tools, both in Command-Line 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

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.

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].

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 application

13, two options are shown: creating a new

account and using the existing credentials of WebLab-Deusto. Once this step is performed, the Facebook account is linked with the WebLab-Deusto account. From

13

http://apps.facebook.com/weblab-deusto/

Figure 7 CPLD experiment running in Facebook through

WebLab-Deusto

Figure 5: Administration panel of WebLab-Deusto showing

the use of the experiments by students

Figure 6 A concrete experiment running in a Desktop and in an

Android mobile phone

6

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.

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 WebLab-Deusto 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_website.pdf

[7] A. Mujkanovic, D. Lowe. Policy-Based Remote Laboratory Multi-User 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.

Figure 8 VISIR experiment running in Facebook through

WebLab-Deusto

7

[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, University of Deusto, Avda. Universidades 24, 48007, Bilbao, Spain. (e-mail: [email protected]).

D. López-de-Ipiña., is with the Faculty of Engineering, University of Deusto, Avda. Universidades 24, 48007, Bilbao, Spain. (e-mail: [email protected]).

���������������������� �� ������������� ���� �������� ���������������� ���������������� ������� �� �������������������� ���������� ��!� ��������"� �������#!����"$���#��� ��%�!��%��%�������������!�������&��&���� �!�%��$'((�")�!�)!��(*+),--*(�.!�)/0��1)*002��)����3�*4�5)�����6��*4��)��!������6���7*4�5)����89��:�&��*4��)���66!7�14��)��;$�6�����$�3�*�*���/�� ��<�!=���� �!4���7&�!4��$����1�������7��� �������!=���������������4�����4��7!����;$!7� 4���6�7����>?@ABCDAEFGHIJKLMNOLPQRMLSOTQSOULOVVWHMRLNQXOLYOOJLZQSOLIJLMNOLSOXOPW[ZOJMLQJSL[GYPIRNIJKLWVLHOZWMOLO\[OHIZOJMRLVWHLOSGTQMIWJQPL[GH[WROR]LJLWHSOHLMWLHOSGTOLMNOLSG[PITIM_LWVLWHaLQJSLMWLIZ[HWXOLMNOLTWZZWJLHObGIHOZOJMRLMNQMLQHOLRNQHOSLY_LSIVVOHOJMLHOZWMOLPQYWHQMWHIORULHOZWMOLO\[OHIZOJMLZQJQKOZOJML[PQMVWHZRLNQXOLYOOJLSOXOPW[OSULRGTNLQRLc dLIeQYRULeQYfNQHOLfQNQHQLWHLgOYeQYhFOGRMW]LJLMNIRL[Q[OHULOLSORTHIYOLNWLMNOLSOXOPW[ZOJMLWVLO\[OHIZOJMRLIRLNQJSPOSLIJLgOYeQYhFOGRMWULRG[[WHMIJKLYWMNLZQJQKOSLiSOXOPW[OSLGROSLMNOLjkRL[HWXISOSLY_LgOYeQYhFOGRMWlLQJSLGJZQJhQKOSLO\[OHIZOJMRLiGRIJKLmIHMGQPLcQTNIJORLWHLeQYmnglULQJSLTWZ[QHIJKLYWMNLQ[[HWQTNOR]LMLQPRWLRNWRLMNOLHORGPMRLWVLIJMOKHQMIJKLHOZWMOLO\[OHIZOJMRLGJSOHLMNIRLR_RMOZULIMNLMNOLGROLTQROLWVLmfoULMNOLOPOTMHWJITRLHOZWMOLPQYWHQMWH_LSOXOPhW[OSLIJLpdq]LrstuvwxuBy@EHOZWMOhPQYRULQHTNIMOTMGHOULSIRMHIYGMOSL�)z� ������ ��%��� ��!=���#!�����&!���!��� �� �$����8�7��7<�� �=�7��!����< )����8���%����8�����!�4���#!�����& ����&7�� ������� ��!���#!��7<��88� ��"$���#��� ��%�8%�����$%< �8�77<�7!8���������%�����/�� ��<4� !� ������ �8���&�����%!#��!������������!��7�7�&����� ��%�7��� �����"$���#��� )��%��{��7��<�!=��%���"$���#����8���&���#$�!/���&<��%�����������!��!=��%����#!�����&!���!�<����!�%���������7�7���������!!7 4�!����%��8�����%����#!���8!77�&!����!�)�����%��#!��4��%��8! � �!=��%���"$���#��� �8���&������8�����/����%���������!=� %�������#!��� ������ ��%���8���&���8%��/����%����%�<�����{������#�8%��� �����%���������������!��7�7�&!���!�<)���� �##��<4����������!��7�7�&!���!�<�� �������!��� ���!=���!����$%�8�7�������#$!��7���{����#��� ��%�������#!�����&!����!�<�8����/!��4��������#��<�&���=�� ��!��%� ��/!����8�)��!��/��4���#!�����&!���!��� �%�/��$�� ����=���%���&���=�� )��!#$7�"��"$���#��� � �8%�� �|����*�%�/��&����&��7���}*~4�&����� !� �88� =�7��%���|�����%� �&�������$7!<�����������!$�������/�� ���� �����%����#��!=��%� ���������4��7!������%�!�%�����$7!<#��� � 8%���7������� ��4�����!�%������/�� ���� �8!� �#���������#!��7<)� ����$$�!�8%� �%�/��=!8� ���!��#����������� <��!���$7!<��"$���#��� ��}1~������/���#�������%�#�#!&�7���},~)��������# �!=� �$$!�������/�8� 4��%��������%� �&�����#�$�!/����}2~4� �$$!������#�7�����������%���#!�����& )�����%� �7���4���==�������$$�!�8%� �%�/��&����������=!����/�7�!$������#!�����&!���!��� �����#�������%�#��/��7�&7�����%!�����{�������$7����� �����%����&�&�!� ���!�����7���������������������������������������������������������������*�%��$'((!$��7�& )&�%) �(� ���%�=�����77 )��%�<������#�.!�7<����7< �������}�~4�������==��������!�$ �%�/���!�����!����&� ������� � !7���!� ��&� ���!���5���� ��8��1++���}�~��!��!����< ��}0~)��%��������!=���#!���7�&!���!��� ����������7�� � !�������}�~��%����!!7 ��!�����"�������{�����������==!�� ��!�8����������#����������%� ������"� �%�/��&����$7�8��4� �8%�� ���&1�!��}-~)��%���#!����!=��� ���8%�7��� ����%�����#!�����&!���!��� �%� �&�����"��������!���87����{��7��<�!=�7���������}*+~4��/����"� ������!�� %!$ �=!8� ���!���%�����8���!��7�!��8!#� �!=���#!���7�&!���!��� 1)��%� ��!��8!#� �%�/��&����$�����8�7��7<������ ���&<��%�� ��/�<���/�7!$���� �$����!=��%����&�%����$�!.�8���}**~)��%���������7 !��==!�� ��!�8!� ������%��� ���!=���!�$�=!�#���!�����%����%��8!���"��!=���#!���7�&!���!��� ��}*1~)��%� ���8��� ���������� ��!����#!�����&!���!��� �%� �����������&����==!�� ��!� %������ !��8� ��#!�����==���������/�� ���� )��%�������� ��%�����$�!/��������/�� ��<�8��� %�����"$���#��� ��%������� �� �������%��� � ������ 4� !� ������� �!=���8!� �#������/�� ��<�8���� ���%�#)���%���������& ����#,�� �$�!���������%� �=��7�4�%�/���� %�����&��8%��"$���#��� ��#!�����==���������/�� ���� � ��8��1++2��}*2~4�����������8��/���"$���#��� � ��8��1++���}*,~)��%�����& ������%��#! ��$!$�7�����#!���7�&!���!��� �$7��=!�#4�&������ ��������==������8!������ ��#!����%��=�/��8!������� )�����%�� �#��7���4��%����&�%����$�!.�8�2������ ���7���� ���$�&7�87<�=������$�!.�8��=!8� ���!��&��7�����������!���!=���#!���7�&!���!��� )�� �$����!=��%� �$�!.�8�4��%����%�����$7��=!�#�%� �&������/�7!$��4��������%� ���8���7<�8��������%����&�%������ ��������� ����!��=!��$�!=���!�����6���!���%�����77�&���������$������� ��/�8��&�!����$�!#!����4�#����������������/���%! �������#!���7�&!���!��� )�0������!$�4��%�������$�!.�8�����&���<�!=���& ���� �8��������=!8� ���!��$�!/�������%�������$!���7��%�8%�#����� �&!�%�/�����7�������#!����"$���#��� )��==!�� ��!���� ��%�����������!��!=��%� ���==!�� ��%�!��%������!$���&�7��<�&����� �%�/��&����$7�8��4�� ������7�������}*�~�=!�����& ����%���%���)����=�8�4��%���7!&�7��7������&!���!�<��!� !����#���������� ���8���7<�8��������!�$�!#!����%����/�7!$#�������� %������!=���#!���7�&!���!������������������������������������������������������������1�����1+**'��#$�!/������&!���!�<������������8!#� �,�%��$'((�7�&)#��)���(���&���/�8���!���(�2�%��$'((���)7�& %���)���)��($�!.�8����%��$'((7�& %���� �%���) !��8�=!���)���(���%��$'((���)7�& %���)���)��(�0�%��$'((���)7�7��$�!.�8�)!��(���%��$'((���)!�7����7�&)!��(���������������������������������������������������� ����� ¡¡

���������������������� �� ������������� ���� �������� ���������������� ���������������� ������� �� ����������������������������� !���"�"#����$%�"$�&�$%�&������&�'&�(���!�����#�!��'�������'��"�"#����$%���#�'#��� �&$��!������#�!����&����)')��*����$%�&����$�������'�������������&���%���!�$%���"$&���'#$�'&$��������&�����+�"'�'+�"��&�%�'"��$�,��$����"$&���'#$�'&$�-�)�'&%$�"���������'���%$� ��!�$��&���"'�'+��"��&�$%�&����$""$����. ���"��&��$%�&�����"$&���'#$�'&$�����*���(��-���"$&���'#$�'&$�-��'��'���&�$%���. ���"��&��&�'&��'��#���� ��!�'"$�+�$&�����'#$�'&$����*��$�����&'�����"$�&���"$&���'#$�'&$�������. �����$"��,��!�$%�����! ����+/��$"����"$&���'#���������. ����'��'���!'���$��& !��&��#$$,�'����&'���"$"��&�&$� ���&����0)���"��&��������$&������"$&���'#��������'�!���&����&��$ +��'�. � ��$%� ����*�� &���&��'&�$��1'����&��+�&�'&�&��� ���������$���'�"��&$�#�2�'�!�' &�$��3'&�$��1'����&��+�&���)��"����$���$%�&��� ������ ���'����'&��0)���"��&���'��� �2�'���$&�������'���0'"�)����$%���. ���"��&���$""$��&$�!�%%����&��'#$�'&$�������������&�!$����$&�"'&&����%�&����0)���"��&����'������&�$������0)���"��&�$��'���0)���"��&�$%�)�-�����&$��'�!���' &����&��'&�$��'�!�' &�$��3'&�$�*����&'�!'�$�����"$&���'#$�'&$�-��'��# ��!�'���&�����%�'& ����%�$"����'&���%$��&�'&��)���%���!$"'������&�$ &� ���+�'���+�"'�'+�"��&�%�'"��$�,*�4��������'���0'")���$%�&���/��&����'�!$"'����)���%��������&�$�������0)���"��&��# &��&��'�!����' &���&��'&�$���' &�$��3'&�$�������! ���+�� ����&�'�,��+����� ��&-���$"" ���'&�$�����&�*�����)�$#��"�$%�&����'))�$'������&�'&��&���. �����&����0)���"��&�!�(��$)�����&$�,��)�'�!�"'��&'���'���&������'-����$%��$%&�'��*�����$))$��!�&$�&����'))�$'����'���0)���"��&��$ �!�#���")��"��&�!� ���+�&���&$$���)�$(�!�!�#-�'���+�"'�'+��"��&�%�'"��$�,*���&��&����'))�$'����'��&�����+�"'�'+��"��&�%�'"��$�,�) #�����������(����$����&����0)���"��&�' &$"'&��'��-�� ))$�&������%�'& ����!�(��$)�!�#-�&���)'�&�� �'��%�'"��$�,*��$�����&'������%�!�(��$)����$%�&�����+�"'�'+�"��&�%�'"��$�,�!�(��$)�'�����' &���&��'&�$������"��� ���'��)������&����0)���"��&������#��'������#���&��$ +��)����*���&�$ &� ���+�'���+�"'�'+�"��&�%�'"���$�,��&����0)���"��&�!�(��$)�����$ �!����!�&$��")���"��&�&����� ))$�&�%$��&�����)'�&�� �'���0)���"��&*������)')����0)�$����&���&������'���$(��&����$%�&������#�'#��� �&$���+�"'�'+�"��&�%�'"��$�,�����&��� ����&�(����$��15*6�72��'('��'#���%$��'�-��0)���"��&�!�(��$)�!���&����&�����#�'#��� �&$�'����&��& ����879:*���*;��4����� ������������ ��������������������<=>?@ABCDEFAGC@H��#�'#��� �&$I����'��)����$ ���76���"$&���'#$�'�&$�-�)�'&%$�"��87J:�$����+�"'�'+�"��&�%�'"��$�,��!�(���$)�!����&�����(����&-�$%��� �&$*��&��'��#���� ��!���&���& !��&��'��)'�&�$%�&������$ �������������#� '�-�K66L�&��$ +��!�%%����&�(����$���$%�&����-�&�"*��&�"'�'+�����+��$��&$)�$%��������0)���"��&�������#��� �*�����!�(��$)"��&�$%��0)���"��&���'��� ����&�-�#��!��(��$)�!� ���+�&�$�!�%%����&�'))�$'����/�M;�'�'+�!��0)���"��&��M;�"'�'+�!��0)���"��&�������������������������������������������������������������I��&&)/NN���*��#�'#*!� �&$*��N�76��&&)/NN�$!�*+$$+��*�$"N)N��#�'#!� �&$N� O=>PQ@QRSDHSTUSBGVS@AWH����"$&���'#$�'&$�-���� � '��-��$")$��!�#-�&�$��$")$���&�/��M;�����&/��&�� ������'���#�#�$�����$�����&����& !��&X��!��,&$)*�������'&�&��� ������������������'&�&��������&���$��*������%$����&��������&�"'�'+���'���&�����&��'��&�$����&��&����& !��&��&�'���'&��+�&���'�&�$���$%�&��� ������&$�"���'+���&�'&������#�����&�&$�&������(��*��0�'")����$%������&���$ �!�#��Y'('��))��&����!$#����'���'))���'&�$���$��&���������$!��&�'&������#����$������&�����#�#�$����*��&�����$"�&�"�����%����!�'��Z��+������&[*�M;���(��/��&�� ���'&&'���!�&$�&����'�!�'���&�'&������#�� ��!�#-�&����& !��&���$�'&�!����&��� ��(����&-*�������'�!�'���"�+�&�#��'������&�$�����#$'�!��'��$#$&���'�"��$��'�-�!�(����&�'&�'�����$�����!�*��������(����$!������������(����. ��&��%�$"�&��������&�'�!�������$�&�$��&�����&��'�&�$����&��&����'�!�'����'($�!��+��'�"% ����. ��&���%�)$���#��*��&��'��#��!�(��$)�!����'�-�&-)��'��&����$�$+-��� ���'��Y'('��* �����-&�$����\\���&�*��&�����$"�&�"�����%����!�'��Z��+����(��[����&�����&��'& ��*����#�'#��� �&$��"#�'����&�������'�������&����(���'�����&��& ��������'&��&��'����Z"'�'+�!��0)���"��&�[*��&�)�$(�!�����#�'�����#$&�����&��������&���!��'�!�&������(�����!��&$��'��!����$"" ���'&�$���'�!��&�'��$�)�$(�!����$%&�'����$")$����&��&�'&������#�����&���"�!!���#�&����������&�'�!����(��*�������'-���&���� ����&�'&�'�� �' &�$��3�!������&��'���$&�)��%$�"���. ��&��&$�&�����+����(����������&����$%&�'����$"�)$���&��)�'��!����&���"�!!������������,�&�'&�&��������&������$���'�"��&$�#�*�������#�'#��� �&$����(�����������'���)'�&�$%�&����$%&�'����$")$���&��&�'&�'������&���"�!!���������,��)�'�&�'�,�$%�'���&����$""'�!�����&�'�!������(�!�%�$"�&����0)���"��&*�� �&���"$����������&���'�& '���$"�" ���'&�$���#�&����������&�'�!����(���'���)��%$�"�!�&��$ +��&������$%&�'����$")$���&�����#�'#��� �&$�)�$�(�!���'���� ����$�,�&���'-���&$�'($�!�&����0)���"��&��$!��&$��'�!�������-)&�$����� ��*���(���&�'&�'���&����$"�" ���'&�$����'�!�&����%$�����(��'����� ��&-�'�!�&�'�,��+�'�)��&���'����'�!��!�#-�&���)�'&%$�"��&���%��&����&-)��$%��0)���"��&�����'���!�Z"'�'+�![��������&��-�'���% ��-�"'��'+�!�#-���#�'#��� �&$*����'���0'")���$%�"'�'+�!��0)���"��&�������+ ���7�'�������0)���"��&�� ����+������#�'#��� �&$��'��#��')�)����'&�!*������& !��&���'(���$++�!����&����-�&�"��������&�!��������0)���"��&�&��-��'�&�&$�� ��1��������&�����'��2���'�&�!����'�. � ��1�%�&����������$&�����& !��&�� ���+�&���'('��'#�����+�2��'�!����&�'�%����&�'&������#��)�$+�'""�!����&���������&��-����������&����)'����&$��$�&�$��&���!�(���*���(��'��# &&$���'�!����&�����'���'('��'#����'�!��& !��&�����������&������ �&�$%�&�����'�&�$������&���!�(���������&�����#�'"���$���&������ �&�����&���!��)�'-�*����$�!���&$�!�(��$)�&����"'�'+�!��0)���"��&��'�)'���$%������&�'�!����(����$%&�'����$")$���&��" �&�#��!�(��$)�!*���$�!�(��$)�&��������&��$")$���&����#�'#��� �&$�)�$�(�!�����#�'�����%$��Y'('����)&���!$#����'���'�!�Y'('��)�)��&�*���&��&�������#�'������&��������&�$��-����!��&$�)��%$�"��$"���'����&$�'��$""$������&$����!�'�!������(���$"�"'�!��'�!�%�����&$�&������(��*����&����'���$%�&���������0)���"��&���&��������$��&���# &&$�������&�����'�!�&�����#�'"����&�����#�)'+�*��&������'��$�!�%����&�'&������'����&������)�����!��'��$""'�!������#�����&�&��$ +��&���)�$(�!�!�������$�&'����+�'��&���+�� ���'��]_ aHbc?deHfHgah*��ij kllmnoopppqrstuvquwx

���������������������� �� ������������� ���� �������� ���������������� ���������������� ������� �� ����������������������������������� �!��"�"�#�$"�������%&�$�'�(%���&��)���*���&�$&���)��������%�����%&�$�%���+����#��,,#�-$�$#�* ��#��'���"�����$&.���*���%�� �!��"�"��(%����$���$������+�!���������$��(%���&�� $������$ ���%!��$� �!!$"�����+%���%����"�*������������%���/�� ��������$"���������� �!!$"���$"��0�"��$���$�������������"��#�(�% ��(%���&����� ������$0$%"�%"����� �%�"�*��"����� $����+���������#������������(%��� �� 1�23456789:3;<7=7>6?�$"��(%�����$"��$���%�����$��%0%�$���%0"$����"��������������$��$"�%"�)�#�$"����%�������(%�����$ ����%"0���!���%"0�%"�����@���0!�"���%���$'���$����)��"���(%�����������)0������(�&� $!*���������%�����%&�$�'�%"����� �%�"���%���(%���!$"$0�������"����%�� �!!$"�����������&�$&���)�����������#�(�% ��(%�������$0$���%����������/���%!�"����������" �����'��$�����$ 1���%��$"���$�%�$������$������)�����$�����!%��%�"����)���%�*�������%����� ����%����$"��$��"��+��������/���%!�"������������*���%�����%����� ����!$'����!���$��%��$����$�&%0��$���" '#�%���$��&��"�!�$�)����$"��%��%��1������(#�$�����("�%"��%0)���A#�$����)0��%������"����"����� �"+%0)�$�%�"�)���*������+���#�����)����+�����!$"$0����/���%!�"���$�����$ ��+$ %�%�$���������������!�"���+��� )����/���%!�"�����$�� $"�)���������(����+�(�&�$���% $�%�"�#����%�"$��'�(%���)����B)%�%"0�$"'���)0�%"�$"����)��&�%"0�$&������&��)�������"�+��!�!�&%������% ��*��)�����!���#��%" �����&�$&���)����!$"$0���$������� �!!)"% $�%�"������)0����$"�$�������C�����������#�"��%��)��(%���$�%�����0$��%"0���������/%������%"��%�)�%�"$��+%��($���*�;DE4FGHFHIJK7JLMJNOGJFPQ7��%�������!$"$0����/���%!�"���$����$ ��+$ %�%�$���������������!�"���+��/���%!�"��#��/���%!�"���������������%���"��������������� ���*������+���#��������"0%"�����(���$����/������%"�������!$%"��+������/���%!�"���&)��"���%"�(�&��������!�"��(%���+%"��%���%++% )�������������������/���%�!�"��*��"�����������$ 1�����%�����&��!#���&�$&���)������$������)�����%"0�R)"!$"$0����/���%!�"��S*��%��%"���&�$&���)���#�)"!$"$0����/���%!�"���$���������(����� �!!)�"% $�%�"��$���"����$"������%�� ��'�&'�������$�+��!*���%�������$)���"�% $�%�"#�$)����%T$�%�"#�� ���)�%"0#���$��&$�$" �%"0�$"��&$�% �)������$ 1%"0�%����%����$"�����&'�������$�+��!#����� �%�"��(%��� �"�$ �������������&'�%����("#�(%���)�����'�%"0��"�������&�$&���)�����%&�$�%��*����$"��/$!���#��%0)���U����(��$�.%��)$���$ �%"��V.�W��)""%"0�$��$&.�����/���%!�"�*����"�$�)�������B)�����$"��/���%!�"�#���&�$&���)����(%�����$��$�.%��)$���$ �%"��$"��(%���0�$"������)����$ ���������%��.%��)$���$� �%"�*���%��$ ����(%���&�����+��!�������)0��. �#����������!�������1���#�)�%"0�$���� %+% � �%�"�����$"�$������(%��%"�����(�&�$���% $�%�"*��"���������������%�#���&�$&���)������$����$�.��)�%"0�.%��)$���/XX#���$��%"0�+��!�$��$��% )�$���"$������������) ��������$��)���%!�����+�(��� �"��*����"#���&�$&���)����0�"��$����$��$"��!��$��(����$"��(%��� �"+%0)���%��%"�����.�*����!���%��!�!�"�#�����.����$����$���(%"0� �""� ��%�"��(%�����$���$��(���*���&�$&���)����(%�����"����%���$��(����������� �%�"�#����%�� $"���$���$� �""� �%�"��������.%��)$���$ �%"�*��������!�!�"���+���%��(�%�%"0#�(���)��������� )���������V���W�$"��. ��%"��%")/�.���$"��. ��$"����!�������1����%"��% ����+��.��*������������������������������������������������������������XX�����YCC(((*�%��)$�&�/*��0C� ��%0)���XY�������/���%!�"���)""%"0�%"���&�$&���)���� ��%0)���AY��$��" '�$�����&'�������$�+��!�$��%�%�"$��'��������"��(��1��$��" '�(��"���"�%"0�$�+%��#�!�$�)����%"��� �"���VZ�$/%�W�$"��%"�")!�&����+� �" )���"����)��"���V��$/%�W� ��%0)���UY�.%��)$���$ �%"��!$"$0���&'���&�$&���)���#����(%"0�$��)!!'��$&.�����/���%!�"�����[\] __abcdef_gh_ijfk[lc_mnndf_o_pq aorssph_]ktbufv_orss wx

���������������������� �� ������������� ���� �������� ���������������� ���������������� ������� �� ������������������������� ���!����"��#���$�%��� ����"��"��������&�����"���""�'%�����(�)�%����*��������"������+�(�",������ ����%�-+������'��'���$"��.��!�����*����������"�(�)�%���(�$"��-�������'#����$"��������!� �/����"��*��������� ���'���$���������#���$�%��� ����.��"�%��-��"�����#���$�%���� ���������-�"��������(&���� ���� ����"� ���� �%+/������*���������&�%%��$�.�"��-�����"���������� �/��������*��������"�'�"�(������'#���������������%�����'���-��(����(��"�"��&�������-$���0���(�����"� $�����%+��*���������%.�������� �%���"�'����(�)�%���(�'��&������'��'���$"�����(���'#���/�"�����%��("�����.)�������$"�����"������""���"�����*� $��.��-���/�" ��($%��-/��$������ �����/��$�����1�����/���(�$"������ ,��-��������(%�(�'+���'��'���$"����$������ �%%+/�"�������*���������(�)�%�������%+����("����,��&���'#���.���&�)��/����� ���$�� �����"/��"�"��&�������-$���2/������������(%�(�����$-����'��'���$"��.����%����������(��%+�-�������(���""&��(����#�"����"� ���������'#�����"�"��������$-����'��'���$"���"� $��%+/��%%�����# �3���3���������",���3�����������%� ���� ������"�����-�(�(��� �%+.������!���/����&��,����'%��"�"$ ���"�!���&�%%"�'%� ,��-���������"�40566�!���# �/�77�!������/�8895�!������������",���:�&�%%����"�.����&�%%��%"������'����""�'%������$�����"���*��������"�!������"���$����"�$"��-��� ��������������*+/�"�� �����"�� ���� ����"�&�%%����'�'%+�'��!��'�((��.�����"� $���+��!����"������� �%"� ����%"��'� ���������'�%��.����%��������(����������",��������� �%"����� ���"�(���(�"� $���'+�(�"�-�/�# ���"�����"� $���'+�(�!�$%�.�����%%+/�����!� ����������"�� ���$�� �����"���������!����(��$�"�(��������'��'���$"����%��!������,�"����(�!!� $%�����(��%�+�����%��'%��$"������ ,��-�"+"���/���� �������"���&������������(�)�%���(������������-�(��*���������"/�&������)��+� �����(���(���"���"���"�"����(���(� ���'��� �""�(�'+���� ���"/��(����"������"���(���"��� ����".����%�����"�"�%$������"�&��"���������"��!�"� $���+/����������� �/����$"������ ,��-�"�� �������;$���"�"�)���%�����"����'���������(���(��� �� ���� �����&��������%�'������+�"��)�������� �$%(�'��"��!!�(/�����(�)�%��������!��*���������'�� ���"�!�����"����"�� ������(�)�%����� ���$"����+��� ���%��-+.������!���/�����"�������"���-����,����'���������� ��".�����������������!�)��&��!���'��'���$"���(�)�%����"/�����$"���!�$�����-�(��*��������"�"��$%(�'���)��(�(��!���""�'%�/�-�)���������"$%�"��������"��!���%+��-�����%$-���"���(�����"������ ���-�������� ��!%� �".���&�)��/�&����)����*���������(�)�%����"�!��(����(�!!� $%������������($ ��)�����(��%�&����&�'��� ���%�-��"/�$�����-�(��*��������"�����)�(�������"+�"�%$�����!����*���������(�)�%������.�<=>?@ABCD@EF��'��'���$"������)�(�"�"�)���%�!���$��"���������*����������(�)�%����".���� �����"��!���$��"���������(������(����(���/����+� ���'����$"�(�����%%��+��"��!����������'��������"�(��%�+�(���������!���'��'���$"��.����"���!��%%/���'��'���$"�������-�"�$"����$������ ������.�������)�(�"�(�!!�������$������ ������" ����"����(��"�.������(����"��������!�����"+"���� ���"�%� ��&�� ��" ������"������������������!����� ��$"������-��$���!�$"��".�����!�%%�&��-�����������"�� �����%+�$"�(�" ����"�������'��'���$"��/�&�� �� �$��"�&��������������� ���%�*��$������� ������" ����"G� ���-$���2G�����-�(���(�$�����-�(��*��������"�������'��'���$"����%��!���� ����-$���0G���'#���������������%��$����-������'��'���$"���HI����'�"�G�������"��"���%���"�"�����-�����"���!�������""&��(������(���'�"�.��)��+��������$"���%�-"���/�����"+"����&�%%� �� ,��!�������"���!��������)�(�(���""�&��(��"�����"�����"�����"����(���"�����-������ �""��������"�$(���.�HI����G�-�)�������������������'������+��"���"��)� �����)�(�(�'+�����$��)��"��+/����"��$%(�'������-����(��"�"$ ����(���� ��)�(��"�"$ ��'+�"�$(���".��",��-�"�$�(���"������)��������� $%�����""&��(�!����������������'������+�'���,"����"���� ������.���)��"����"�$"$��%%+���)������������%%+�� �""�'%��(��� ���+�"��)� �.�������"�����$%�������� �%����� �""����"�(��� ���+�"��)� ����!����������"� �%%�(������4��-��&��-�������� ���+�� �""������ �%:.���'��'���$"���"$�����"���������)�%�(�������� ��(�����%"����)�(�(�'+�����"�$(�����-���"����-�)��������"��)��.���!!�����������"��)��"� ���'�� ��!�-$��(/���(��� ��"�$(����&�%%�'�� ��!�-$��(����'��)�%�(���(��-���"�������������JK LMMNOPPQQQRSTUVWRVXY

���������������������� �� ������������� ���� �������� ���������������� ���������������� ������� �� ������������������������������������������ ��!�"�#���� �$!% $���&'����%� ���������&��������(�%��'���� $�"�������)����*����� %%��������+� +���&��!����#�$$�+�� +$���!�&���������#�%��'���� $���,-.����/����!�'����!��� ����).���*�����#�����)���� $�&�����������"���������$���������0��1�.�����.�!��!%!$�����&..!���'������.�!��'���&��������(�% ��%�� ���$!% $$(� �����!2�&����� �'���� +$������ �����(�#�$$�+�� &������% ��'����!&�������.������������!2�����%!���&*���&��������(���������������&..!�������������*.$���%��*��0�&%�� �� $$������. �����&������������������� ��'����������'���������3��'������'�����(�������%�4531�#�$$�+�� +$���!�+�%!*��%!��&*���&���������������&�����*!��"����������� ��!��!2�������(���*����%��� ����� ������� � ��*�����(���*��0���1�+��%!*������(���*.$�������#���� ��* $$������!+6�%���������� ����+� +���&��!�#�$$���$(�!������� *������$���������������� �������� ������� � ��*�����(���*�����$2�����%!�'$("���+� +���&��!�* � ���������).���*���� &���!��7 ��!����������"����#�$$�%��%8�#��%��&������ ���.��*�����!���!��#��%���).���*����"�+ ��'�!��.!$�%���� ..$��'��!�����. ���%&$ ��&����!���!� ���!&.��!2�&���������� �(�����* � ��*����2� *�#!�8"���+� +���&��!�%$� �$(���. � ���������).���*����* � ��*����2�!*������).���*����'���$!.*���"�#��%�����'���!�+��'!* ����.�%�2�%��������*��!2�* � ��*���"���+� +���&��!�����)��������$(�&��'�#������&'�����������2!��"�������# ���������'��!�%�� ��� '*������ ��!���!!$�"�+!�������!** �'������������2 %��0���1� �'�#�+�+ ��'�0 ����!#��������&���91������� '*������ ��!���!!$�� ���%!**!��2!�� $$������).���*�����������2!��"�!�%������ '*������ �!�����2 *�$� ��#���������!!$�"�* � �����*!����).���*������������� $����%��������� �'$�'����!&�������� *���(���*���*!��������(.�% $�� �8���� ������ '*������ ��!���!!$��#�$$�� �'$�� �������* � ���*����!2���&'����� �'���!&.��!2���&'����"�.��*����!���!2���������&'����"���* �$��!��2�% ��!����!�������&'�����!2� �. ���%&$ ����!&."� �'��� %8��������&����!2� ���������&'�������� �'���������&������ %8���"� $$�����*��� ����������!������).���*���� �����!��'���� �' � + ��"�������.!���+$���!�8��.� �2������ ���'��� %8�!2�#� ��������&'����'�'����!�����%!**!��2� �&�����:&���'�+(� $$�������*!���� +!� �!�������������%��'&$����* � ��*����������*!���� +�"�&�& $$(� �����$��&����!�� �����$����!&.�!2�&�����#!�8�����!�������*&���+�� +$���!� %%���������).���*���� ������� *����*����2�!�����&'�������#!�8����!�� �$���!����� �.�(��% $�'���%�"����������!2���&'�������!&$'�# ���&���$��������&'����� ��2������'�+�2!���&����������).���*�����������2!��"�������*&���+�� �$!%8����*�%� ���*"�#������ %��&����$!%8�� �%��� �������#��$��������&����������).���*����!��#��$�������������.��. ����������).���*����!�������������%$� ������������!&�%�������!�'����!�� �'$�������.�!+$�*"���+� +���&��!�.�!��'��� ���)�����+$���%��'&$�����(����*"� ������*!*����+ ��'�!��.��!���(�:&�&�����������*!*����!2������#������"� ����������+� +���&��!�% ��+��&��'�+(�'�22�������(.���!2��).���*�������!������� �%�"������ *���$�%��!��%��'���%��%!&$'�+��&��'�2!��'�2�2������$���!���2!��'�22������%!&�������������� *����*�"� �������$���!��% ��+��+&�$��!���!.�!2�'�22�������(.���!2��������!*.&������������������&'��������������2�����%!&�����%!&$'�$� ����!#� ���*.$���'&% ��!� $�*�%�!.�!%���!��#!�8��������������������������������������������������������������45����./;;###���'�������;���;��'�)���*$���� ���%����������*.$���'&% ��!� $�*�%�!.�!%���!���'!��!���)���"�!���%!&$'�+&�$'����*���� �.�!�� ** +$��$!��%�'����%���&%�� �� ������!�� ��������!#����"������� ���!�����%!&�����#���������� �'������.�!�� **�������� &������!����#!&$'�+���������������� ����&'�����!2�����2�����(� ��&���<=>?<@� ������!�� ������#���� �� $�� '(�.�!��'�'��%��*��!2�������*.$��*�%�!.�!%���!�"�#��$�"� ������� *����*�"��������'��������&'�����% ��.��2!�*�*!���%!*.$�)�$���!���!������� *�������"� �'���&'�����$� �������!#��!�.�!�� *� ������% ��&������� � �$ +$�����������+� +���&��!��&..!�����������(.���!2�%!*.$�)��%��'&$�����%��*�"��&..!������������� ��������&'�����!2��������'��������� ��� ��������.��!���(����%������!�������&'�����% ��&��� ������!�� ���������� $�!��&..!����%!���%��$! '�+ $� �%����!2��).���*����"��!�'�22������%!.����!2������ *������% ��+��.�!��'�'��!���'&%��������7��!2�����:&�&����������*��!2�&���������2 %�"���+� +���&��!�&����������2 %��� ��+���� ' .��'��!�*!+�$��'���%�������$�������&.�.!���!2�*!+�$��'���%���!2�� %��. ���%&$ ���).���*����'��.��'��!��������%��!$!�(�&��'�+(������).���*����'���$�!.��"�������+� +���&��!�.�!��'����!!$���!�* 8���A���+ ��'� ..$�% ��!��� %%����+$�����!&���*!+�$��'���%���������% ��+�� ..��%� ��'�������&���B"�#���������� *���)�.���*�����&���#���� ����(���*�$ ��&���������2 %���������'��8�!.�#�+�+�!#����0$�2�1� �'��������*!+�$��#�+�+�!#����0�����1"� �'�������'�� �$�'�*!������'�� �$�����CDE�� ����&���9/��'*������ ��!��. ��$�!2���+� +���&��!���!#��������&���!2������).���*�����+(���&'����� ����&���B���%!�%������).���*�����&��������� ����8�!.� �'���� ����'�!�'�*!+�$��.�!��F���GHIJKLKMNOPQRKSTKUVRWGXOKYZZPRK[K\]JM[__\TKIWNaRbK[__ cS

���������������������� �� ������������� ���� �������� ���������������� ���������������� ������� �� ��������������������������������� !�"���#�$�� ���� �# �%�����&���� �&#� �%������$��!!'(���)��� "� ���$��!!'���**!# ���� "�+(,��-"�$"������*#! !$!�� !�*#!)�%���� "!#�.� �!��!��#��!�#$���*��$�%����#�/! ���� ��������������� !�� �# �%��� �&#� ��&�� ������! "�#��� "�� �$� �!���$"�/�(��"�������$��!!'����#��!&����� "����$��!!'������������ !��*�*��$� �!�01�� -!�!* �!����#���"!-�2�$#�� ��&�����-��$$!�� ���%�����&� "���3�� ��&�$#�%�� �����!4������������ !(��$�� "���� �*����*�#4!#/�%�� "����$��!!'��$$!�� �������'�%�-� "� "������������� !��$$!�� (��#!/� "���/!�/�� �����#��-����������� "����$��!!'��**��$� �!�� "!����3*�#�/�� �� "���"�%�*�#/����!��� !�������� "��#������������ !��$$!�� ���� �-� "��� "����$��!!'�-���� �������&������ !����� "��*#!)�%�%� !!���5$"� ��� $(6���������������&�#��7(��!-�)�#�� "��/!� ��/*!# �� �*!�� ��/!�&����� "����4��� �#������ "� ����/!#����#)�$�����%�4�� �#����#���� �&#� �%��������������� !�� "����#���� !/� �$�����*#!)�%�%� !����� "���3*�#�/�� ����������/�����-��(��!#���� ��$������ "���� �&#� �!��������#���&�����&�/�� ���� �/��-� "������������� !��/*#!)����8079�� "���3*�#�/�� ��-��������� !/� �$������� �&#� �%(����(:�;����� ���� �� ������� �������2�;�������<�����"��;�����*#!=�$ ��������$$���4������$ #!��$����/! �����!#� !#��%�)��!*�%���� "�������-"�$"�"��������%��*�!��%������)�#�����#!*�������)�#�� ���(��"�����#��� �#4�$�����$!/*!��%����������"��**��$� �!����%�%�44�#�� ���#)�#�����%� ����%�����809(��������)���� �!��!4� "��%���&��!4������������� !���� "!#�� #�� !��� �&#� �� "���3*�#�/�� ���� "�����$ �!�(������#�&���#�;����������!��� "������"�$���� �-�������%����� �!4�/����&�����%�*#!$���� "��#��*!����� "#!�&"���*������!$'� �!#���������#�>��� (��� "�"��*�!4� "��;����� ��/����! "�#�?*#! !$!�@�-����� #!%�$�%��-"�$"���� � "����/�����&��� "#!�&"� "������������� !�����"����#�#���(��$����� "����#)�#���%��� "��;�����/����#�/�� ���#)�#�#�$��)��� "����/��#�>��� �� "� �� �#�$��)��������#�&���#������!����!��!�$!%��/!%�4�$� �!��-���#�>��#�%� "�#�(��"�#�4!#���-� "�4�-�&����$!%����� "������"�$!//���$� �!�������#� "������ �/���%���#�&���#)�#� "� �*#!3��%� "��#�>��� �� !�;����A����#)�#�� "���� �&#� �!��-���#�����&������/���&�%��3*�#��/�� �-� "�������������� !(��"���-����� �%�� ��!4������������ !�����;���������� ���! "�#��3*�#�/�� ���� "����� �!4��3*�#�/�� �� "���"�)��*�#/����!��� !����(����$�� "���� "�� �$� �!����%��� "!#�.�� �!�����"��%��%� "#!�&"������������ !�� "��#�$#�%�� ������#��)���%� �%�-� "� "�������%�#�$ !#��!4� "�����)�#�� ��!#� "#!�&"�*��������$���� "����#��4!#��&��� �%�� �(����!�� ��$"��&�� �44� "� ���#��%����������������� !�-�������� "����/���%/���� #� �!�� !!������ "��#�� �!4��3*�#�/�� ��!4������������ !� !�"��%��� "��*�#/����!������%�&#!�*�/���&�/�� (��%%� �!������������������ !� #�$'������ "�������!4�;���������-����������� "��$!//��%����� ���%� "��#��*!�����&���#� �%����;��������%� ��$"�#��"�)���$$���� !� "�����4!#/� �!�(���# "�#/!#����������������&�#��B��;�����#������ "��4��� �#���*#!)�%�%��������������� !����$"���� "����$��!!'��� �&#� �!��%��$#���%���� "��*#�)�!�����$ �!�(������������������������������������������������������������01�" *2CC�**�(4�$��!!'($!/C-������%��� !C� ���&�#��7�������3*�#�/�� �#�����&������$��!!'� "#!�&"������������ !� ���&�#��B�;������3*�#�/�� �#�����&������$��!!'� "#!�&"������������ !��;(:� ���� ��� ���������D���� "���*�*�#�� "������$�$!�$�* ����"��%���#�&�/���&��/�� �4#�/�-!#'�!#�#�/! �����!#� !#��*�� 4!#/�-�#��*#����� �%(��"��*�# �$���#�$����!4������������ !��� ��%��&� !� "����**!# �%�%�)��!*/�� ��**#!�$"���5$����%�?/����&�%��3*�#�/�� �@���%�?��/���&�%��3*�#�/�� �@6���%�4�� �#���*#!)�%�%�5$!/*��3��� "�� �$� �!���$"�/�����$"�%����&��$"�/����/!�����%�)�$�����**!# ���%�4�$��!!'��� �&#� �!�6�-�#��%� ����%(������������ ������ "���� �&#� �!��!4� "��;�����*#!=�$ �������"!-$���� "� �$���������%��������)���� �!��!4� "��*#!�*!��%�%���&�(��/!�&� "��4� �#��-!#'�� "������������� !� ��/����$�##�� ���-!#'��&���� "#����#����%��$#���%���� "���*�*�#2�E:�!#��$!/*��3��$"�%����&��$"�/����4!$����&�!�� "��4�%�#� �!��!4��3*�#�/�� ���E:�� �#!*�#����� ��-� "�! "�#���/! ���������$"����������!#���"�#�(������� ����809:�(���� �)��!�(�� ���(�?�"��;�����*#!=�$ �����!*����!�#$���!4 -�#����� �� �)��4!#�%�� #��� �%�!���������!#� !#���(@��#!$��%��&��!4� "����;�+,,F��!�4�#��$����!# !���!# �&��(�8+9:<(���#$G��H������ ���(�?��������� �&#�����*�� 4!#/�4!#� "��%�*�!��/�� �!4�����/! �����!#� !#��4!#�/�$#!$!� #!���#�@(��������� �+,0,�5��� 2�BF7�0�I+II�JKF,�K6(�+,0,(�819:L(��������M�(���'�#!)M��(����&/���(�?�/�# ������4!#�#�/! ���3*�#�/�� � �!�����$!//���$� �!�� �$"�!�!&���@(��#!$��%��&��!4� "����;�+,00��!�4�#��$����#��!)���!/����(�8I9:�(�#%�N��� ���(�?�������&�/!������$$���� !���/! �����!#� !#���@(��������� �+,00�5��� 2�BF7�0�J0+7I�JI0�K6(��//����<!#�%�����*#���+,00(��OP QRRSTUUVVVWXYZ[\W[]

���������������������� �� ������������� ���� �������� ���������������� ���������������� ������� �� ���������������������������� !"#�$�����%!&�$�����'()*�%)��(#&�$�����+,)-���%%�)--�#./��0123��)��4(��2�#.�25)��)-#/.�01��)402)���"-����������.-���2#0.-�0.��.%!-2�#�+��+)�2�0.#�-����� 6�789:�77;<����6�=7�==7>?����877>�878<@<:��A0+!4)��<$��--!)�=8$��)���877>���/)B-C6;9�9���;9<9���<������������ !"��$�����'()*�%)��(#&�$�����%!&����03��%-������.0.#��+��0123��)����5#2)�2!�)�10���!+2#��),#�)��)"��"-����� �877�$�@=-2��..!�+��0.1)�).�)�01�25)�������.%!-2�#�+��+)�2�0.#�-��0�#)2D$���� 6�7�9:7@�>8�@$�((��8=;<�8=�=$� 0,)4")��877����9����� 0�.#/$�����5).$����+�ED+�.)D��F��������������5#2)�2!�)�10���)402)���"-G����0�))%#./-�01�25)���A�87==��0.1)�).�)$����-0,$��04�.#����:��������,#)�$������D0++)$������D��%$�����2)-��.%�������%0.$��2�2)�01�25)���2��"0!2��)402)���"0��20�#)-�����%#/4-����0!.%�2#0.-�01�./0#./��!2�2#0.-���.2)�.�2#0.�+��0!�.�+�01�.+#.)��./#.))�#./$�A0+�;$� 0�=�B877:C���>��������"#� !2#.$�����!)�$������#)�$���� #)%)�-2�22)�����"8/0�H����)(0-#20�D�20�+0��2)�)%!��2#0.�+�0.+#.)�+�"0��20�#)-����0�))%#./-�01�25)�������%!��2#0.��./#.))�#./��0.1)�).�)�B��� C�87=7���(�#+�87=7����%�#%$��(�#.���=7��������,#)�$������D0++)��I!�+#2D�01�+)��.#./6�!-#./���-)4�.2#��3)"��((�0��5�20�).5�.�)�+)��.)���0.2�0+�%!�#./��0++�"0��2#,)��)402)�+�"0��20�#)-���.2)�.�2#0.�+��0!�.�+�01��..0,�2#0.��.%��)��.#./$�,0+��<���(��<7<�<8;��877>��522(6??%J�%0#�0�/?=7�=�7;?�����877>�78<<;9��==�����E0-2!+-K#$�����!���D��F�5)� �2#0.�+��./#.))�#./���"0��20�D��!�,)D�H����),#)3�01�25)�%)+#,)�D�01�(���2#��+�+�"0��20�D�)%!���2#0.�#.��!-2��+#�.�!.%)�/��%!�2)�)./#.))�#./�(�0/��4-G���)�)4�")��87=7�����2�01�25)�0!2�04)-�01�25)���"�5��)���0L)�26��522(6??333�+�"-5��)�)%!��!?4)%#�?#4/?+�"-5��)M�)(0�2M(�.)+M3)"-#2)�(%1��=8������!LK�.0,#�$�����03)���0+#�D���-)%��)402)���"0��20�D��!+2#�-)�����)--���.�/)4).2����0�))%#./-�01�25)���A�B�)402)��.�/#.))�#./��.%�A#�2!�+��.-2�!4).2�2#0.C�87=7���20�K50+4$��3)%).����=@��������3��%$�)2��+��F#��"-6���-��+�"+)����5#2)�2!�)�10��-5��#./�0.+#.)�+�"0��20�#)-G���.2)�.�2#0.�+��0.1)�).�)�01��./#.))�#./��%!��2#0.��877;����#.)-,#++)$��+0�#%����20")��=<�8=$�877;����=;��������3��%$�)2��+��N�5)�#��"��5��)%����5#2)�2!�)6����)"��)�,#�)-��.1��-2�!�2!�)�20��!#+%��044!.#2#)-�01��.2)�.)2����)--#"+)���"0���20�#)-$N���0�))%#./-�01�25)������$�,0+�><$�.0�<$�((�>@=�>�7$��!.)�877:��522(6??%J�%0#�0�/?=7�==7>?�����877:�>8=<79� �=������O)!./�)2��+�$�F�.2)�0()��"#+#2D�01��)402)���"0��20�#)-��D-�2)4-$G��.2)�.�2#0.�+��0!�.�+�01�.+#.)��./#.))�#./�B#��C��A0+�<���()�#�+�#--!)���A87=7����=<������%!&��)2��+��F�)-#/.#./��J()�#4).2��/.0-2#���)402)���"0���20�#)-G���)402)��./#.))�#./��.%�A#�2!�+��.-2�!4).2�2#0.����#%/)�(0�2$���$������!.)�877>���=9��522(6??�0%)�/00/+)��04?(?3)"+�"%)!-20?���=:�������.��#-20"�+�)2��+���F�)�,#�)���"-6��)!-#./��)�,#�)-��.%���"0���20�#)-�1�04�().��)��.#./���.�/)4).2��D-2)4-G����877>���.�2)���2#,)��04(!2)���#%)%��)��.#./��A#++��5$��!-2�#�6��)(2)4")��8@�8�$�877>��� ������PQRSTUVWXYZQ�#-�3#25��)!-20�)�5�H��)!-20��.-2#2!2)�01��)�5.0+0/D$�.#,)�-#2D�01��)!-20$��,%��.#,)�-#%�%)-�8;$�;:779$��#+"�0$��(�#.�B(�"+0�0�%!.�[%)!-20�)-C���\Q]_UWYWaYb�#-�3#25��)!-20�)�5�H��)!-20��.-2#2!2)�01��)�5.0+0/D$�.#,)�-#2D�01��)!-20$��,%���.#,)�-#�%�%)-�8;$�;:779$��#+"�0$��(�#.�BL#�!�*!.[%)!-20�)-C��cY]dUeTXW]fY_a�#-�3#25�25)����!+2D�01��./#.))�#./$�.#,)�-#2D�01��)!-20$��,%���.#,)�-#%�%)-�8;$�;:779$��#+"�0$��(�#.�B+!#-��0%�#/!)*[�0().%)!-20�)-C���\Qg]_WUhQWijQklYR]Q$�#-�3#25�25)����!+2D�01��./#.))��#./$�.#,)�-#2D�01��)!-20$��,%���.#,)�-#%�%)-�8;$�;:779$��#+"�0$��(�#.��B*!"#�[%)!-20�)-C��mQRW]i]TUhQaaTSQ$�#-�3#25�25)����!+2D�01��./#.))�#./$�.#,)�-#2D�01��)!-20$��,%���.#,)�-#%�%)-�8;$�;:779$��#+"�0$��(�#.��1�"�#�#0�/�**0+�[/4�#+��04C��noUcpq_akX_kq]ZQ�$�#-�3#25�25)����!+2D�01��./#.))�#./$�.#,)�-#2D�01��)!-20$��,%���.#,)�-#%�%)-�8;$�;:779$��#+"�0$��(�#.��%#(#.�[%)!-20�)-C���5#-���2#�+)�#-��.�)J2).%)%�,)�-#0.�01���(�()��(�)-).2)%��2�25)��.2)�.��2#0.�+��0.1)�).�)�0.��)402)��./#.))�#./�r�A#�2!�+��.-2�!4).2�2#0.�B��A87==C$�5)+%��2����.-D+,�.#��.#,)�-#2D$����-0,$��04�.#�$��!.)�8:����!+D�=$�87==���)�)#,)%�@=��!+D�87==���!"+#-5)%��-��)-!"4#22)%�"D�25)��!250�-�8:��)(2)4")��87==��� stuvwxwyz{|}~w��w��~�s�{w���|~w�w��vy������wu��z�~�w���� ��