eDSPlab+: Laboratorio remoto basado en Web Services

eDSPlab+: Laboratorio remoto basado en Web Services Sergio Gallardo, Federico Barrero, Sergio Toral Departamento de Ingeniería Electrónica Universidad de Sevilla – España [email protected]s Abstract— En la actualidad existen multitud de propuestas de laboratorios de instrumentación electrónica que dan solución a una amplia diversidad de disciplinas; la mayoría de éstas se basan en la utilización de herramientas comerciales que facilitan el diseño. Sin embargo, esto presenta algunas limitaciones desde el punto de vista de la ampliabilidad, la escalabilidad, la portabilidad, etc., a lo que se suma un elevado coste asociado a licencias y paquetes software adicionales. La propuesta de laboratorio remoto basado en la API JNI de JAVA en conjunción con la tecnología AJAX persigue dar solución a esta problemática, surgiendo así eDSPlab+. Keywords—Laboratorio remoto, JNI, Servicios Web, Java, AJAX, instrumentación, educación, QoE, QoS, Aceptación Tecnológica. I. INTRODUCCIÓN En la actualidad, podemos encontrar numerosas áreas de la ciencia, la industria y la sociedad que precisan de una amplia y continua cooperación y colaboración internacional. En muchos casos, esta cooperación impera cuando se precisa la accesibilidad a sofisticados equipos de instrumentación que, frecuentemente, es inasequible localmente, bien por su coste o bien por el conocimiento que requiere su utilización. Por tanto, el desarrollo y difusión de arquitecturas, técnicas y tecnologías que propicien acceso virtual, remoto y compartido a los sistemas de instrumentación supone un hito esencial de la Sociedad de la Información y del Conocimiento. La posibilidad de utilizar equipos de instrumentación independientemente de su localización física, contribuye a la equidad y unificación de comunidades industriales y científicas, abriendo nuevas oportunidades de negocio y conocimiento para la industria, la ciencia y la sociedad. Añadido a lo anterior, el impacto político y estratégico es vital, pues nos lleva hacia una sociedad más unificada [1], [2]. La identificación sistemática de instrumentos y de las correspondientes comunidades usuarias, la definición de sus requerimientos, así como el cuidadoso análisis de la sinergia de la instrumentación remota con redes de comunicación e infraestructura de alta velocidad de la próxima generación, serán la base para definir las recomendaciones para diseñar la próxima generación de Servicios de Instrumentación Remotos [1], [2]. Desde el punto de vista técnico, podemos afirmar que, al no utilizar software y hardware preestablecido, ingenieros y científicos obtienen máxima flexibilidad definida por el usuario. Si bien un instrumento convencional proporciona tanto software como circuitos de medición en un producto con funcionalidad fija utilizando el panel frontal del instrumento. Un instrumento virtual proporciona todo el software y hardware necesario para lograr la medición o tarea de control. Aunado a un instrumento virtual; ingenieros y científicos pueden ajustar la adquisición, análisis, almacenamiento, unión, y funcionalidad de presentación, reutilizando una aplicación en múltiples dispositivos y/o implementando múltiples aplicaciones en un único dispositivo [3]. Sumándose a lo anterior, numerosas empresas del sector de la instrumentación electrónica como, por ejemplo, National Instruments, están enfocando su actividad comercial en la adaptación y/o reutilización de arquitecturas y tecnologías de alta inversión de compañías como Microsoft, Intel, Analog Devices, Xilinx, etc. Apoyándose en la ingente inversión en sistemas operativos y herramientas de desarrollo de terceras compañías, caso de, por ejemplo, Microsoft, y aprovechando la inversión en hardware de conversión de otras como, por ejemplo, Analog Devices [3]. Este creciente interés por los sistemas de instrumentación virtuales es especialmente relevante en la comunidad de científicos e ingenieros que disponen en sus laboratorios una combinación tanto de instrumentos, ya sean los basados en tarjetas de adquisición como tradicionales. La utilización de los buses de comunicación presentes en la mayoría de los instrumentos tradicionales de hoy día son el punto de encuentro hacia la compatibilidad de estos, lo que es posible gracias al software de instrumentación virtual que proporciona los mecanismos necesarios para crear estas interfases de instrumentación [3]. II. BANCADA DE REFERENCIA PARA LA EXPERIMENTACIÓN Se ha partido de una bancada de referencia con objeto de poder poner de manifiesto la arquitectura y tecnología propuesta en el diseño de laboratorios de instrumentación remotas. El puesto del laboratorio de instrumentación remota (Fig. 1) estará formado por 3 partes claramente diferenciadas: El equipamiento de instrumentación, una placa de desarrollo del sistema DSP y un ordenador personal que actuará como interfaz con el cliente del mismo y los sistemas de instrumentación implicados. Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 153 Fig. 1. Fotografía del puesto de trabajo de la bancada El ordenador constituye una de las partes más sensibles del proyecto, puesto que en éste residen todas las aplicaciones encargas de la gestión tanto de la interfaz con el usuario remoto como la comunicación con los distintos equipos de instrumentación. Para establecer la comunicación con la instrumentación de medida, se ha dotado al mismo de una tarjeta GPIB de comunicación. El esquema general de conexionado de la bancada experimental es como se detalla en la Figura 2. Fig. 2. Conexionado de los diferentes elementos de la bancada experimental III. EDSPLAB - LABORATORIO DE REFERENCIA BASADO EN LABVIEW El diseño ha partido de un primer prototipo en el que el diseño LabVIEW (Fig. 3) únicamente se accedía a un conjunto de sistemas de instrumentación básica: Una fuente de alimentación, un generador de funciones y un osciloscopio [4]. Una vez comprobada la funcionalidad y efectividad técnica del sistema de control, se comenzó a estudiar y desarrollar la integración en el laboratorio remoto de un DSK de la familia TMS320C3x [5], al mismo tiempo que se analizó su integración dentro del contexto educativo, junto con otras herramientas multimedia desarrolladas en el seno del portal Web de una asignatura de la titulación de Ingeniería de Telecomunicación, “Complementos de Sistemas Electrónicos Digitales”, empleando la técnica de mapas conceptuales descrita en [6] y [7] para adecuar la metodología de enseñanza. Paralelamente se comenzó a aplicar un modelo de aceptación tecnológica (TAM) para no sólo medir el uso de la herramienta sino obtener también las variables externas con una influencia significativa en su uso, para poder planificar futuras mejoras de la misma [8]. De lo anterior se extrajeron algunas conclusiones relativas a la necesidad de mejorar aspectos relativos al laboratorio de instrumentación remoto implementado, como la necesidad de mejorar la interfaz y la forma en que los usuarios interactuaban con el sistema; decidiéndose incluir un nuevo sistema de desarrollo basado en el DSK TMS320C6000 que, por sus diferencias respecto al sistema anterior, implicarían una importante modificación de la implementación ya efectuada [9]. Fig. 3. Panel frontal que se ha implementado como interfaz gráfico IV. NUEVA PROPUESTA DE LABORATORIO DE INSTRUMENTACIÓN REMOTA: EDSPLAB+ A la hora de seleccionar un determinado entorno de programación para implementar un sistema de instrumentación debemos tener en consideración varios aspectos o figuras de mérito [10]. Entre ellas cabe destacar la facilidad de uso, la flexibilidad, el rendimiento y la funcionalidad, entre otros. El modelo de sistema de instrumentación que se propone con eDSPlab+ persigue mejorar algunas de estas figuras de mérito, tanto desde el punto de vista técnico y como por parte del usuario final [11]. eDSPlab+ desarrolla un nuevo modelo de control remoto vía Web de sistemas de instrumentación; dividido en dos bloques o capas principales: La aplicación Web, que gestionará la comunicación entre la interfaz del cliente final y el servidor, y el controlador remoto, cuya función es llevar a cabo los procesos necesarios para la comunicación entre la instrumentación y el servidor. El uso de tecnologías Web para el acceso a sistemas de instrumentación está adquiriendo un especial interés en los últimos años; encontrando incluso soluciones profesionales en otros campos como el de la automatización o la domótica donde los clásicos controladores están evolucionando hacia dispositivos conectables a redes LAN y con posibilidad de crear interfaces de monitorización y control tipo SCADA empleando como interfaz los propios navegadores Web; caso de los nuevos autómatas programables LOGO! De Siemens o el sistema inmótico basado en LonWorks Simon VITA, de la firma Simon [12],[13]. Para resolver el acceso al laboratorio de instrumentación virtual se ha dividido el problema en diferentes fases, resultando en un modelo de 5 capas, cada una de las cuales tendrá asociada una función concreta. Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 154 Para dar solución a las distintas capas que constituyen eDSPlab+ se ha decidido emplear un conjunto de herramientas gratuitas basadas en Java 1 . Existen distintos entornos de desarrollo gratuitos para este lenguaje, lo que implica un coste cero. Se trata de un lenguaje multiplataforma y portable, independizando el sistema operativo y la arquitectura hardware de la aplicación. Además, dispone de varios elementos que serán fundamentales para dar solución a las cuestiones que se deben resolver, como el acceso a la instrumentación, lo cual se ha conseguido gracias al uso de la API de Java JNI (Java Native Interface). A. Acceso a la instrumentación a través de la interfaz nativa JNI Uno de los primeros aspectos que debemos resolver en un sistema de instrumentación es cómo accede el servidor a dichos instrumentos. Los distintos instrumentos controlables remotamente, tales como osciloscopios, fuente de señal, analizadores de espectro, etc., suelen ir acompañados de librerías de funciones en forma de drivers o DLL 2 que son utilizadas por los entornos de alto nivel para comunicarse con los mismos. Tal es el caso de la instrumentación GPIB. Sin embargo el lenguaje Java no puede emplear directamente una DLL. Para resolver el problema de comunicación de la aplicación principal del servidor, basada en lenguaje Java, con los drivers de los instrumentos, se hace uso del Java Native Interface (JNI) [14], un framework de programación que posibilita que los lenguajes escritos en lenguaje Java puedan interactuar con programas escritos en otros lenguajes como C, C++ o el lenguaje ensamblador, entre otros, siguiendo la estructura reflejada en la figura 4. Fig. 4. Esquema de acceso al sistema de instrumentación empleando JNI B. Comunicación con la interfaz gráfica del cliente remoto La aplicación del servidor de eDSPlab+ se divide en dos bloques principales. Uno de ellos se encarga de la gestión de la comunicación con los instrumentos de medida y la tarjeta del DSK. Por otra parte, el segundo bloque será el responsable de presentar un flujo de información entre la interfaz Web del usuario remoto y el sistema local. 1 Si bien es cierto que será preciso hacer uso del lenguaje C en una parte del modelo, para poder acceder a las librerías que operan sobre la instrumentación GPIB y comunicarse con Java a través de JNI. 2 DLL es una denominación exclusiva a los sistemas operativos Windows, en el caso de sistemas operativos linux serían archivos “so”. Para facilitar la comunicación entre el servidor y el cliente remoto a través de una interfaz Web se crearán dos ficheros que actuarán como búferes o colas de entrada-salida; de esta forma se elimina la dependencia entre las tecnologías empleadas para diseñar el entorno gráfico del cliente para acceder al sistema y el propio servidor Java local. La aplicación principal del servidor se encontrará a la espera de los comandos recibidos por la interfaz Web de los clientes remotos. Cuando se reciba un comando por parte del cliente, el programa principal invocará a los métodos de los objetos asociados a las diferentes clases descritas en el anterior apartado, que gestionarán la comunicación con los instrumentos reales; traduciéndose en comandos GPIB. Cuando dichos comandos precisen de respuesta, la información devuelta por el bus será puesta a disposición de la interfaz Web del cliente remoto. El método de intercambio de información entre la interfaz Web del cliente remoto y el servidor local de control de la instrumentación se basa en la implementación de dos colas o búferes FIFO (First-In First Out), uno de entrada y otro de salida. En dichas colas, implementadas mediante el empleo de sendos ficheros de texto, los comandos procedentes de la interacción con un instrumento remoto de la interfaz Web se volcarán en la cola de entrada. Por otra parte, la respuesta a las peticiones realizadas a los equipos será volcada en el búfer de salida. La sintaxis de comunicación deberá ser conocida por ambas partes. C. Interfaz Web Para la comunicación del cliente remoto del sistema de instrumentación con el controlador local se propone el diseño de un modelo basado en “Aplicaciones Web” (Fig. 6). Las aplicaciones Web son herramientas que permiten la utilización de un navegador para que los usuarios accedan a los recursos de un servidor remoto a través de una red, normalmente, Internet. Es decir, son aplicaciones codificadas en lenguajes de programación soportados por los navegadores, a los que se les “confían” la ejecución de los mismos [15]. Cuando un usuario desea hacer uso del sistema de instrumentación, previa autentificación en el sistema, se llamaría a la URL de la página Web del laboratorio de instrumentación eDSPlab+, que se encuentra instalada en el servidor 3 . Cuando el cliente remoto interactúe con la página, los eventos producidos sobre la interfaz, que es implementada como un formulario, estarán asociados a funciones JavaScript que se comunicarán con los distintos Servlets del servidor. El servidor ejecutará el servlet asociado a la petición del extremo cliente y retornará los datos que se precisen en un formato XML. En el caso de que el evento que llega al servidor corresponda con un comando a ejecutar sobre un instrumento, el Servlet se encargará de escribir en el búfer de entrada que emplea la aplicación Java del controlador de instrumentación el comando en cuestión y, si fuese preciso recibir una respuesta, 3 El servidor Web instalado es Tomcat, el cual implementa las especificaciones de los servlets y de JSP de Sun Microsystems. Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 155 leería el búfer de salida para hacer llegar los datos a la aplicación cliente nuevamente. El servidor, implementado utilizando Tomcat, tendrá una doble misión, por una parte será el responsable de exportar la página Web para que ésta sea accesible por el cliente y, por otra, deberá monitorizar las posibles acciones del cliente remoto sobre la interfaz, llamando y ejecutando los servlets asociados a estas acciones que se comunicarán con el controlador remoto del sistema de instrumentación a través de los búferes de entrada/salida. Fig. 5. Estructura del principio de funcionamiento con la interfaz Web Para el diseño de las páginas Web de los clientes se ha decidido utilizar la tecnología AJAX debido a que esta tecnología nos permite realizar peticiones asíncronas que implican la recarga de zonas concretas de la página Web, no su totalidad, reduciendo el tráfico de red asociado al mismo tiempo que mejora el tiempo de respuesta del servidor. La interfaz HTML del cliente utilizará hojas de estilo CSS para separar el formato y estilo de las páginas del código HTML propiamente. Cada botón de la interfaz Web asociado a una acción tendrá una correspondencia con el comando contemplado en el archivo “properties” asociado al instrumento real sobre el que se quiera actuar. Finalmente, el empleo del lenguaje JavaScript implementará las diversas funcionalidades que dotarán de dinamismo a la interfaz, permitiendo la interacción entre el cliente, la página Web y el controlador de instrumentación remoto. D. Servidor Web La interfaz Web asociada a los clientes se basa en el diseño de páginas HTML que emplean la tecnología AJAX para implementar un canal de comunicación bidireccional asíncrono entre el cliente y el servidor. Dicho canal permite que, cuando el usuario actúa sobre un control se informe al servidor Web del comando o acción realizada y se comunique éste con los búferes de entrada-salida del sistema de instrumentación o del sistema de desarrollo, según sea el caso, pudiendo recibir una respuesta por parte del servidor y actualizar en la interfaz Web únicamente aquella parte de la misma que haya sufrido alguna modificación; caso de la actualización de la pantalla del osciloscopio, por ejemplo. Para la implementación de las aplicaciones responsables en el extremo del servidor de recibir las peticiones de los clientes, comunicarse con el controlador del sistema de instrumentación vía búferes, recibir la respuesta del mismo y remitirla a la interfaz, entre otras funciones, se ha decidido emplear la tecnología Java basada en los Servlets [15], [16]. La funcionalidad total del servidor se ha implementado dividiéndola en tres bloques claramente diferenciados, cada uno correspondiente a un Servlet que se ejecuta en el servidor. Un primer bloque, será el encargado atender las peticiones que el cliente Web realiza sobre el osciloscopio, el generador de funciones y la fuente de alimentación, es decir, sobre la instrumentación propiamente. En segundo lugar tenemos un segundo bloque responsable de gestionar la interfaz con el DSK en exclusiva, siendo responsable tanto de la subida de ficheros asociados a los proyectos en una carpeta asociada al usuario, previamente autentificado, como de hacer llegar la petición de comandos por parte del cliente Web al software Code Composer Studio, a través del búfer de entrada asociado, que será leído por el extremo del controlador. Por último, disponemos de un tercer bloque que se encarga de gestionar la autentificación de los usuarios que deseen hacer uso de eDSPlab+, comunicándose con la base de datos existente en el servidor. Este bloque también permitirá crear nuevos usuarios a través de la autentificación de un usuario administrador. Fig. 6. Esquema de funcionamiento del servidor Web del laboratorio de instrumentación V. ANÁLISIS DE PRESTACIONES Se ha perseguido poder evaluar algunos parámetros que, desde un punto de vista objetivo y subjetivo, nos permitan establecer la bondad del modelo de sistema de instrumentación eDSPlab+ propuesto; comparándolo con el modelo de referencia basado en LabVIEW, eDSPlab. Con objeto de poder evaluar las prestaciones del modelo de instrumentación propuesto, eDSPlab+, se propone un experimento base a realizar sobre el laboratorio de instrumentación, con un procedimiento a seguir y una serie de parámetros objetivos y subjetivos evaluables desde el punto de vista de la percepción del usuario final; del mismo modo que se procede en otros sistemas como el caso de la telefonía, [17]. Se ha definido un experimento base para comparar las dos implementaciones descritas consistente en la programación y volcado de un filtro FIR paso bajo de cuatro kilohercios sobre el sistema de desarrollo DSK que permitirá monitorizar el efecto del cambio de la frecuencia de una señal de entrada introducida en una entrada analógica del DSP sobre una salida analógica del mismo, estando ambas señales conectadas a los canales 1 y 2 del osciloscopio, respectivamente. La experiencia partirá de un proyecto que implementa el programa “Filtro FIR” que el usuario remoto deberá subir al servidor, previa autentificación en el mismo, para ello, ambos laboratorios se han integrado dentro del contexto de una plataforma LMS tipo Moodle. Una vez cargado el fichero, el usuario accionará la alimentación de la placa DSK a través de Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 156 la interfaz remota de la fuente de alimentación de la bancada. A continuación seleccionará desde el instrumento remoto el proyecto a cargar en el DSP, comenzando a ejecutarse sobre la placa. El usuario accederá al panel de control remoto del generador de funciones y programará la salida de una onda senoidal que irá variando desde dos kilohercios hasta seis kilohercios, finalmente ajustará los parámetros necesarios para monitorizar las señales de entrada y salida del DSK en la pantalla de la interfaz del osciloscopio. A. Métricas objetivas de medición de la QoE Las métricas objetivas que se han establecido para evaluar y comparar los dos modelos son: CPU time.- Parámetro que representa la cantidad de tiempo que los procesos envueltos en el acceso remoto usan la CPU. CPU usage.- Porcentaje de tiempo que los procesos utilizan la CPU. I/O Writes.- Número de operaciones de escritura de entrada/salida generada por el acceso remoto, incluyendo ficheros, red y dispositivos de entrada/salida. I/O Reads.- Número de operaciones de lectura de entrada/salida generada por el acceso remoto, incluyendo ficheros, red y dispositivos de entrada/salida. Bandwidth.- Ancho de banda ocupado por la conexión. Estas métricas afectan directamente a la forma en la que el usuario final percibe la rapidez con la que el sistema de instrumentación responde; pues se basan en estimar la carga de CPU y ancho de banda de la conexión, fundamentalmente. Se ha aplicado el experimento patrón a ambos laboratorios de instrumentación remota, repitiendo el procedimiento en diferentes momentos del día, midiendo las diferentes métricas descritas anteriormente, con los resultados que se describen a continuación, que constituyen un promedio de las experimentaciones realizadas: TABLE I. MÉTRICAS OBJETIVAS DE MEDICIÓN eDSPlab X eDSPlab X % eDSPlab X eDSPlab X eDSPlab X  Cliente Servidor Cliente Servid or Cliente Servidor timeCPU X 0:00:09 0:00:26 0:00:07 0:00:22 25,92 13,94 usageCPU X 2,00 14,92 0,71 8,75 64,59 41,36 writesOI X/ 13,79 10398,5 9,54 7825,6 30,82 24,74 readsOI X/ 7742,5 15,25 6938,14 13,38 10,39 12,21 inBW X 12386 447,99 3945,41 176,80 68,15 60,54 outBW X 447,99 12386,4 176,80 3945,4 60,54 68,15 Las métricas propuestas en la medición de parámetros objetivos arrojan algunos resultados de interés. Efectivamente la utilización de un modelo basado en tecnología AJAX para implementar la interfaz con el cliente libera considerablemente a la CPU del mismo; estimándose una mejora promedio del 26% y el 65% en los parámetros CPU time y CPU usage respecto de la solución basada en LabVIEW. Por otra parte, pese a que podría pensarse que el empleo de tecnologías basada en Java en el extremo servidor podría ralentizar el comportamiento del mismo; la sencillez de la implementación y el reducido número de procesos implicados también se manifiestan en una reducción de los parámetros asociados a la CPU, contando con una mejora del 14% y 41% en los parámetros CPU time y CPU usage en eDSPlab+. Los resultados anteriormente descritos también son manifiestos en los parámetros relacionados con el número de operaciones de escritura y/o lectura, aunque dicha mejora es menos significativa. Por último, el ancho de banda ocupado, tanto de entrada como de salida (BW in y BW out), ponen de manifiesto el cumplimiento de otro de los objetivos marcados en el presente trabajo, reducir el ancho de banda ocupado por el sistema de instrumentación; lo que se debe, principalmente, a la utilización de la tecnología de comunicación asíncrona clienteservidor implementada y el uso de AJAX en el diseño de la interfaz del cliente, lo que implica la actualización de, únicamente, aquellas partes de la interfaz estrictamente necesarias. Así, se observa una mejora del 68% en el ancho de banda de entrada y del 61% en el de salida en el extremo cliente. B. Evaluación subjetiva La evaluación subjetiva se basa en la percepción personal de la calidad del servicio que un sistema ofrece a un usuario. Si bien existen diversas normas que permiten definir procedimientos y escalas de medida para evaluar este parámetro en diversos sectores o aplicaciones, como la telefonía o los sistemas de vídeo; los sistemas de instrumentación remota no disponen de tales referencias. En el presente trabajo se propone como método de evaluación analizar la aceptación que tiene el uso de los laboratorios de instrumentación remota por parte de un usuario final en comparación con su análogo presencial. Para dicha evaluación, resulta imprescindible enmarcar el sistema de instrumentación dentro de un contexto (educativo, investigación o profesional, entre otros). Para poder evaluar desde el punto de vista del usuario final tanto el uso de la herramienta como las variables con una influencia relevante en su uso se han empleado los modelos de aceptación tecnológica (TAM), englobados dentro de la teoría de los sistemas de información. Este modelo ha sido aplicado a Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 157 eDSPlab [18]. Los resultados obtenidos muestran las principales fortalezas y debilidades del sistema propuesto. La utilización de los modelos TAM se basa en modelar el uso de nuevas tecnologías mediante la utilidad y facilidad de uso; a lo que se suman un conjunto de variables externas con influencia sobre éstas. Para ello partimos de un cuestionario que persigue medir aquel conjunto de dimensiones que son consideradas relevantes en relación a la influencia que pueden tener en el uso de un nuevo sistema o tecnología, en nuestro caso, el uso de eDSPlab [18], [19], [20]. El cuestionario empleado consta de cincuenta y nueve preguntas valoradas empleando una escala Likert de 1 a 7, en la que “1” expresa “fuertemente desacuerdo” y “7” fuertemente de acuerdo. Para poder distribuir el cuestionario a una población real de usuarios, el laboratorio eDSPlab ha sido implementado dentro del contexto de una asignatura de la titulación de Ingeniería de Telecomunicación de la Universidad de Sevilla, “Complementos de Sistemas Electrónicos Digitales” y ha sido distribuido a una población de alumnos para su evaluación. Las preguntas del cuestionario se agrupan por dimensiones a considerar en el modelo: formato, metodología, realimentación, adaptación al usuario, comunicatividad, difusión, interactividad y control, amigabilidad, fiabilidad, herramientas de usuario, facilidad de uso, utilidad, intención de uso y uso. Entre todas, las últimas cuatro se corresponden con las dimensiones reflejadas en el modelo TAM original propuesto por [19], mientras que las otras dimensiones son las variables externas con influencia en este modelo base. Con objeto de validar el presente cuestionario se ha utilizado el alfa de Cronbach, un índice frecuentemente empleado para determinar la fiabilidad con la que las distintas cuestiones o ítems que constituyen una dimensión miden la variable subyacente. Este coeficiente puede variar entre 0 y 1; estableciéndose un límite inferior mínimo de 0,7. Los datos obtenidos (Fig. 7) son procesados empleando los Modelos de Ecuaciones Estructurales [21], una técnica multivariante que combina aspectos de la regresión múltiple, examinando relaciones de dependencia y análisis factorial, que representa conceptos inmedibles – factores – con variables múltiples, a objeto de poder estimar un conjunto de relaciones de dependencia interrelacionadas de forma simultánea. Entre los posibles modelos existentes, se empleará PLS para obtener el modelo de la siguiente figura para eDSPlab. Fig. 7. Modelo de aceptación tecnológica de eDSPlab Podemos destacar la influencia de la accesibilidad sobre el uso, lo cual resulta intuitivamente evidente, pues una herramienta remota debe ser, ante todo, accesible, pues es uno de los objetivos que se persiguen cuando se ponen a disposición de la comunidad de usuarios. Gracias a la utilización de interfaces accesibles a través de Internet y la posibilidad de emplear el sistema de instrumentación a cualquier hora, la percepción subjetiva del usuario en relación a la accesibilidad se ve incrementada. Existen, a su vez, otras variables, como la difusión, que, a través de la accesibilidad, influyen en parte en el uso. La facilidad de uso también se ve influenciada por la amigabilidad y adecuación metodológica, aunque esta última tenga menos influencia que la primera, de lo que se deduce la necesidad de diseñar una interfaz más amigable, aspecto que se persigue en eDSPlab+. La utilidad es la que contribuye fundamentalmente a la intención de uso y, a su vez, observamos que surge una influencia que también resulta intuitiva desde el punto de vista de la percepción subjetiva del usuario final: la interactividad y el control. En el diseño de los sistemas de instrumentación remotos, este es uno de los aspectos a tener en consideración más importantes, pues la funcionalidad y control que ofrece la interfaz remota debe ofrecer la mayor semejanza posible con el sistema de instrumentación presencial; de tal manera que el usuario remoto pueda interactuar con el experimento (DUT) e intercambiar información con la interfaz “en tiempo real”; percibiéndolo del mismo modo que si estuviera físicamente en el laboratorio. Otra variable que se manifiesta como elemento influyente en el sistema es la realimentación, lo que implica que el laboratorio de instrumentación remota debe proveer al usuario final de información precisa que le permita determinar si está operando correctamente o no sobre el sistema; lo que le sugiere la sensación subjetiva de “control” sobre lo que está haciendo. En este sentido, las opciones que ofrece la tecnología empleada para la implementación de eDSPlab están muy limitadas; sin embargo, el uso de tecnologías propiamente orientadas al manejo y presentación de la información, como son las empleadas en eDSPlab+ facilita enormemente esta labor, existiendo infinidad de posibilidades de mejorar esta dimensión. Las variables asociadas a la fiabilidad, comunicatividad o el formato afectan a la personalización; aspecto influyente, especialmente, en la difusión. En resumen, desde el punto de vista del usuario final, eDSPlab presenta un aceptable grado de accesibilidad, manifestándose una deseable una mejora en los mecanismos de control e información en tiempo real; pese a lo cual le resulta un entorno amigable y fácil de usar. De los anteriores resultados se arroja que la utilización del laboratorio de instrumentación remota presenta una aceptación favorable a la población de estudiantes que lo ha utilizado. Se manifiesta una clara influencia en la facilidad de uso de la dimensión asociada a la amigabilidad de la plataforma, aspecto que se ha desarrollado en eDSPlab+ empleando tecnologías Web que permiten aumentar las prestaciones en cuanto a la Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 158 ligereza del cliente software necesario para controlar la aplicación, la reducción del tiempo de respuesta frente a los eventos solicitados por el usuario final y la mejora del diseño y apariencia más familiar. Por otra parte, también se refleja la necesidad de mejora en lo que a la realimentación se refiere, pues el usuario de la herramienta remota puede percibir subjetivamente una falta de control en la experimentación respecto de su análogo presencial. Las tecnologías Web permiten dotar a la interfaz cliente de infinidad de mecanismos que mejoran este aspecto. eDSPlab+ incorpora paneles de realimentación que permiten conocer exactamente el estado y proceso del entorno del DSK, la disponibilidad de controles de ayuda en línea, así como una infinidad de posibilidades relacionadas con la incorporación de otras tecnologías como aplicaciones multimedia [22] [23], integración dentro de entornos LMS como Moodle o, incluso, la integración de entornos de realidad virtual que permiten visualizar la interfaz del sistema en 3D [24], [25]. VI. DISCUSIÓN Y CONCLUSIONES El estudio del estado del arte y la técnica de los sistemas de instrumentación remota arroja que, desde años atrás, ha existido un gran interés en el desarrollo de este tipo de plataformas. Encontramos numerosas propuestas basadas en potentes paquetes de desarrollo comerciales que las firmas ponen a nuestra disposición, las cuales permiten un desarrollo rápido y sencillo, con multitud de posibilidades y opciones. Por otra parte, dado el carácter multidisciplinar de los sistemas de instrumentación remota, comienzan a desarrollarse nuevas propuestas y modelos que persiguen mejorar la facilidad de uso, la flexibilidad, el rendimiento y funcionalidad de estas arquitecturas. En este sentido aparecen necesidades constructivas como son la modularidad y la portabilidad, dos dimensiones que facilitan el ciclo de vida de las soluciones de instrumentación, al tiempo que aprovechar aquellos bloques reutilizables, reduciendo el coste de desarrollo. El presente trabajo ha pretendido desarrollar dos modelos de laboratorio de instrumentación remota basados en estas dos tendencias: Una asociada a las plataformas comerciales de desarrollo de aplicaciones de instrumentación remota; centrándonos en el paquete más utilizado actualmente, LabVIEW. Y una segunda propuesta que aprovecha la potencialidad de las nuevas tecnologías que acontecen a nuestro alrededor; especialmente las que a los servicios Web se refieren, presentando una arquitectura de sistema o laboratorio de instrumentación remota basado en tecnologías de entornos Web. En este sentido, cabe destacar que el uso de tecnologías como AJAX junto a los Servlets de Java y el Java Native Interface, fundamentalmente, han permitido desarrollar un nuevo modelo que mejora algunos aspectos importantes que afectan a cómo el usuario final percibe la herramienta. El primer desarrollo, eDSPlab, nos ha permitido crear una arquitectura que, comenzando por un acceso local a un sistema únicamente de instrumentación, ha convergido a un entorno “integrado” en una plataforma Web accedida a través de Internet (Fig. 8). Muchas son las virtudes arrojadas de este sistema; como la rapidez de diseño, el escaso conocimiento de programación necesario para llegar a soluciones finales, lo que hace muy sencillo su uso, al tiempo que las firmas comerciales auspician estas plataformas con complementos y paquetes adicionales que dan solución y soporte a las demandas de la comunidad de usuarios de la misma. No obstante, el desarrollo el laboratorio y su posterior evaluación desde el punto de vista del usuario final reflejaron la necesidad de algunas mejoras, algunas de ellas difícilmente alcanzables con el entorno comercial base. La integración con plataformas CMS o LMS también presenta dificultades y el modelo de comunicación cliente-servidor síncrono, basado en la utilización de un plug-in en el extremo cliente también supone algunos inconvenientes; algunos acotables con módulos adicionales que ofrece la empresa proveedora, en muchos casos, inalcanzable por muchas empresas, organismos y entidades dado el elevado coste de las mismas. Fig. 8. Detalle de nueva interfaz eDSPlab+ accedida mediante tablet La necesidad de mejora de eDSPlab supuso el planteamiento inicial de la nueva arquitectura, eDSPlab+, donde se pone de manifiesto la posibilidad de desarrollar plataformas de instrumentación remota con un reducido coste económico. La utilización de tecnologías multiplataforma orientada a objetos, como es Java, nos brinda una elevada capacidad de portabilidad y modularidad, el acceso al “escritorio” del servidor, es decir, al hardware del mismo, necesario para acceder a la tarjeta de control de la instrumentación, se resuelve con una tecnología muy útil pero poco conocida entre los programadores, el Java Native Interface. Los distintos problemas que se han ido presentando han sido explicados a lo largo del documento y se les ha dado solución; caso de la problemática de los distintos comandos entre equipos del mismo tipo, por ejemplo, lo que se ha solucionado empleando unos archivos asociados a cada dispositivo y aislando la petición del cliente al servidor del envío de comandos del controlador a la instrumentación. La necesidad de contemplar la existencia de multitud de nuevos dispositivos con necesidad de conexión al sistema supone perseguir dos objetivos, uno asociado a la utilización de tecnologías totalmente compatibles en el extremo cliente, con un modelo de cliente delgado que nos libere de la necesidad de descargar aplicaciones que se ejecuten sobre su máquina; lo que resulta imposible en los terminales de algunas empresas o instituciones; y por otro lado aislar la tecnología de acceso del cliente de la tecnología de gestión de peticiones en el extremo servidor. La solución aportada se basa en la utilización de búferes que actúan como interfaz de las peticiones y el uso de tecnologías Web potencialmente compatibles con la mayoría de los navegadores. Si bien es cierto que tecnologías como Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 159 Flash darían mayor interactividad a la interfaz gráfica, su uso se está abandonando debido a los problemas de compatibilidad, precisamente, con dispositivos móviles. Una tecnología que mejora este problema es AJAX, basado en el uso de HTML y JavaScript fundamentalmente; dos lenguajes que la mayoría de dispositivos soportan. En el documento se describe el conjunto de tecnologías que han puesto de manifiesto la posibilidad de desarrollar una interfaz ligera para el cliente y eficiente, al emplear el modelo de comunicación cliente-servidor asíncrono; en contraposición con el modelo de eDSPlab, al mismo tiempo que únicamente se actualiza aquellas partes de la interfaz estrictamente necesarias; reduciendo el ancho de banda utilizado y mejorando la rapidez de la misma, lo cual percibe como una bondad el usuario final. Finalmente, se han propuesto un conjunto de métricas para la evaluación de la calidad que ofrece este tipo de sistemas, obteniendo como resultado una mejora desde el punto de vista técnico de la implementación basada en tecnologías Web. Pese a que se esperaba un empeoramiento de la nueva propuesta en relación al uso de los recursos del servidor, dado que la ejecución de Java es descrita por muchos autores como poco eficiente, al precisar de la máquina virtual Java para su ejecución; los resultados arrojan una mejora tanto en el uso de los recursos hardware del cliente como del servidor y una reducción del ancho de banda. Esto se explica de la reducción de procesos necesarios para dar respuesta a las peticiones del cliente, al crear canales de comunicación con aquellas partes de la interfaz cliente que precisan actualizarse únicamente. Si bien se ha analizado la aceptación tecnológica de eDSPlab dentro de un contexto educativo; resultaría conveniente aplicar el nuevo diseño a una población de similares características y comparar los resultados obtenidos, del mismo modo que se ha procedido con las métricas objetivas; sin embargo dicho estudio queda fuera del ámbito del presente trabajo; resultados que pueden aportar, más allá de cuantas mejoras o innovaciones técnicas podamos proponer, que dimensiones son mejorables y tienen aportación desde el punto de vista de la percepción subjetiva que tiene el usuario final del uso. REFERENCES [1] www.ringrid.eu [2] The RINGrid project deliverable D4.3 “Final report” http://www.ringrid.eu/public/deliverables/RINGRID-WP4-D4_3-2008-02-13Final.pdf [3] http://zone.ni.com/devzone/cda/tut/p/id/5935 [4] Gallardo, S., Barrero, F., Toral, S.L., Virtual instrumentation laboratory based on labVIEW. A case study: A DSPs course. ICECE - International Conference On Engineering And Computer Education. 2005. Madrid, España. [5] Gallardo, S., Barrero, F., Toral, S.L. & Durán, M.J. eDSPlab: A remoteaccessed instrumentation laboratory for digital signal processors training based on the Internet. IECON 2006. The 32th annual conference of IEEE industrial electronics society. 2006. Paris, Francia. [6] Martínez-Torres, M.R., Barrero, F., Toral, S.L. & Gallardo, S. A digital signal processing teaching methodology using concept-mapping techniques. IEEE Transactions on Education. 2005. Volumen 48, pp. 422-429. [7] Toral, S.L., Barrero, F., Martínez-Torres, M.R., Gallardo, S. & Durán, M.J. An electronic engineering curriculum design based on concept-mapping techniques. International Journal of Technology and Design Education. 2007. volumen 17, pp. 341-356. [8] Toral, S.L., Martínez-Torres, M.R., Gallardo, S. & Barrero, F. Análisis de una herramienta educativa remota sobre Procesadores Digitales de Señal desde la perspectiva de los Modelos de Aceptación Tecnológica. PIXEL-BIT. REVISTA DE MEDIOS Y EDUCACION. 2007. Volumen 29, pp. 87-100. [9] Toral, S.L., Martínez-Torres, M.R., Barrero, F. & Gallardo, S. Desarrollo de un laboratorio remoto de procesadores digitales de señal basado en la familia TMS320C6000 y evaluación desde la perspectiva de los Modelos de Aceptación Tecnológica, Innovación y desarrollo de la calidad de la enseñanza universitaria - Experiencia de innovación universitaria, Instituto de Ciencias de la Educación, Universidad de Sevilla. 2009. Volumen I, Número 17, J.M. de Mesa, R. J. Castañeda, L. M. Villar. Editorial: Vicerrectorado de docencia: Sevilla-España, pp. 511-522. [10] Tooley, M. Pc Based Instrumentation And Control3rd Edition. Editorial Elsevier, 2005. [11] Gallardo, S. & Suardíaz, J. End user quality of service measurement on Web based labs. A case study: eDSPlab. III Congreso Iberoamericano sobre Calidad y Accesibilidad de la Formación Virtual - CAFVIR. 2012. MadridEspaña. [12] Gallardo, S. Configuración de instalaciones domóticas y automáticas, Madrid-España: Paraninfo, 2013. [13] Gallardo, S. Técnicas y procesos en instalaciones domóticas y automáticas, Madrid-España: Paraninfo, 2013. [14] Surhone, L.M. Java Native Interface, USA: VDM Publishing, 2010. [15] B. Aumaille, J2EE: Desarrollo de aplicaciones Web, Madrid-España: Ediciones ENI, 2002. [16] Hunter, J. & Crawford, W. Java Servlet Programming. 2001. USA: O'Reilly Media, Inc. [17] “Recomendación UIT-T P.800 - SERIE P: CALIDAD DE TRANSMISIÓN TELEFÓNICA - Métodos de determinación subjetiva de la calidad de transmisión”. ITU-T. 1996. [18] Toral, S.L., Barrero, F., Martínez-Torres, M. R., Gallardo, S. & Lillo, A. J. Implementation of a web-based educational tool for digital signal processing teaching using the technological acceptance model. IEEE Transaction on Education. 2005. Volumen 48. Número 3, pp. 632-641. [19] Davis, F.D. Perceived usefulness, perceived easy of use and user acceptance of information technology. MIS Quartely. 1989. Volumen 13, Número 3. [20] Wu, I.L. & Wu, K.L. A hybrid technology acceptance approach for exploring e-CRM adoption in organizations. Behaviour & Information Technology. 2005. Volumen 24. Número 4. [21] Chin, W.W., Marconlidez, G.A. The partial Least squares approach for structural equation modelling. Ed. Modern Methods for business research. 1998. Mahwah, NJ, Erlbaum, pp. 295-336. [22] Lillo, A.J., Gallardo, S., Toral, S.L., Barrero, F. Laboratorio multimedia de procesamiento digital de señal usando en TMS320C3X DSP Starter Kit. Tecnologías Aplicadas a la Enseñanza de la Electrónica. TAEE. 2004. Valencia, España. [23] Barrero, F., Gallardo, S., Lillo, A.J. & Toral, S.L. Herramienta multimedia de ayuda en la impartición de un laboratorio de procesadores digitales de señal (DSPS). PIXEL-BIT. REVISTA DE MEDIOS Y EDUCACION. 2005. Volumen.25, pp. 61-70. [24] Gallardo, S., Barrero, F. & Toral, S. L. Building a Web-based virtual laboratory with VRML. A case study: An electronic instrumentation subject. International Conference On Engineering And Computer Education. ICECE. 2005. Madrid, España. [25] Gallardo, S., Barrero, F. & Toral, S.L. Diseño de un entorno virtual de trabajo remoto basado en el modelado 3D de un laboratorio empleando VRML. Innovación y desarrollo de la calidad de la enseñanza universitaria - Experiencia de innovación universitaria, Instituto de Ciencias de la Educación, Universidad de Sevilla. 2008. Volumen I, Número 14, J.M. de Mesa, R. J. Castañeda, L. M. Villar. Editorial: Vicerrectorado de docencia: Sevilla-España, pp. 535-550. Actas TAEE 2016 ·ISBN 978-84-608-9298-4 ·P´agina 160