Recursos docentes - UIBbioinfo.uib.es/~joemiro/aenui/procJenui/Jen2005/Ponencias13.pdf · SimuProc...

Recursos docentes

Simula3MS: simulador pedagógico de un procesador

Raquel Concheiro, Marta Loureiro, Margarita Amor y Patricia GonzálezDtpo. Electrónica y Sistemas

Universidade da Coruña15071 A Coruña

Resumen

En este artículo se presenta un nuevo simulador peda-gógico, Simula3MS , de un procesador para su utili-zación en asignaturas de arquitectura y tecnología decomputadores en cualquiera de las titulaciones de in-formática. Se presentan los principales simuladoresde procesadores utilizados en universidades españo-las y se discuten sus ventajas e inconvenientes y elporqué de la necesidad de plantear este nuevo simu-lador.

1. Introducción

El objetivo de las primeras asignaturas de ar-quitectura y tecnología de computadores en lastitulaciones de informática es introducir y analizarlos principios básicos de la organización de loscomputadores clásicos o von Neumann. Centrándosefundamentalmente en el estudio de los bloquesfuncionales básicos que componen un sistemamonoprocesador: el procesador, la unidad de entra-da/salida, la memoria y el sistema de interconexión.Frecuentemente el funcionamiento del procesadores explicado a través de un procesador concretopara facilitar la adquisición de los conceptos, y seutiliza como elemento de apoyo un simulador delprocesador.

En este artículo analizamos las característicasbásicas que debe tener un simulador pedagógico deun procesador. Además, se muestran los simuladoresutilizados actualmente en docencia, así como susprincipales ventajas e inconvenientes, y la necesidadde plantear un nuevo simulador que cubra estascarencias.

El simulador que hemos desarrollado es elSimula3MS [13] que simula un procesador MIPSR2000 [12], uno de los procesadores más utilizadocomo ejemplo en el estudio del procesador. Estenuevo simulador es configurable, con diferentes

técnicas segmentadas y no segmentadas, que permiteaplicar los conceptos que se imparten en el estudiodel procesador. Este trabajo se ha desarrollado endos proyectos fin de carrera ([6], [11]) de IngenieríaTécnica en Informática de Sistemas. La partedesarrollada en estos proyectos se corresponde alsimulador de un procesador con configuracionesmonociclo, multiciclo y un procesador segmentadobásico.

Este trabajo forma parte de un proyecto globalmás amplio que comprende la realización de unsimulador más completo. Pretendemos ampliar estaherramienta añadiendo, entre otros, la unidad depunto flotante, y métodos de segmentación avanzada,como los algoritmos de Marcador y de Tomasulo.

En la sección 2 se presentan las características bá-sicas que debe tener un simulador pedagógico deun procesador y los principales simuladores utiliza-dos. La sección 3 presenta el nuevo simulador Simu-la3MS. En la sección 4 se describe la experiencia dela utilización del simulador en las prácticas de unaasignatura de Tecnología y Arquitectura de Compu-tadores durante el curso académico 2004-2005. Lasconclusiones y el trabajo futuro se presentan en lasección 5.

2. Simuladores de procesadores

El uso de simuladores [14, 16] en lugar de proce-sadores reales resulta bastante común en docenciadebido a que ofrecen un entorno de programaciónmás amigable que una máquina real. Además, enlos simuladores se pueden detectar más errores,ofrecen más posibilidades que un ordenador real yno modifican elementos físicos del computador.

Por otro lado, los simuladores son una herramientaútil para estudiar la arquitectura de los procesadoresy los programas que se ejecutan en ellos. Debidoa que están realizados en software y no en silicio,

490 Recursos docentes

los simuladores se pueden modificar fácilmentepara añadir nuevas instrucciones, construir nuevossistemas como multiprocesadores o simplementeofrecer más información.

Finalmente otra razón para usar un simulador enlugar de estaciones de trabajo es que estas no es-tán disponibles universalmente y además el constanteprogreso hacia máquinas cada vez más rápidas puededejar estas estaciones obsoletas.

2.1. Características de un simulador

Un simulador pedagógico de un procesador debepermitir observar la evolución de la memoria y delos registros durante la ejecución de las instrucciones.Esto también permite que los alumnos comprueben latraducción de las instrucciones en lenguaje máquina.También es conveniente una representación gráficadel camino de datos con la representación concretade cada instrucción. Así como la posibilidad de quese pueda ejecutar paso a paso cada instrucción.

Adicionalmente, la inclusión de un editor propioen el simulador facilita a los alumnos la elaboraciónde los programas ensamblador.

Finalmente, el simulador debería ser configurablecon diferentes técnicas segmentadas y no segmenta-das para que permita a los alumnos en un único si-mulador aplicar todos los conocimientos que se lesimparten. La presencia de las distintas implementa-ciones permitirá observar las diferencias de un mis-mo código según las características del procesador.

2.2. Ejemplos de simuladores pedagógicos

En la actualidad existen varios simuladoresde lenguaje ensamblador con características muydiferentes, los más utilizados son el Spim [4, 10] y elDLX [3]. Otros simuladores no tan utilizados son elSimuProc [1] y el Simplescalar [2, 5], más orientadoa investigación en arquitectura de computadores.

La principal ventaja del Spim [4, 10] radica enestar basado en un procesador real. Este simuladorpermite observar la evolución de la memoria yde los registros durante la ejecución de las ins-trucciones. Algunas de las principales carencias deeste simulador son la ausencia de una representacióngráfica del camino de datos sobre el que se pueda

visualizar la ejecución concreta de cada instrucción,o la imposibilidad de observar la ejecución de unainstrucción por pasos, o ver los posibles efectos dela segmentación sobre el mismo código. Además notiene un editor propio, lo que conlleva dificultadespara hacer cambios en el código y tener que cargarel fichero después de cada cambio.

Hay otro tipo de simuladores, como el DLX [3]o el SimuProc [1], que implementan un procesadorhipotético, es decir, su repertorio de instrucciones noestá basado en ningún procesador real.

El DLX es un simulador de un procesador seg-mentado que permite ver la representación de la eje-cución de cada instrucción sobre el camino de datos.Es uno de los más utilizados para docencia. Se pue-den configurar las características del procesador, es-cogiendo entre varias técnicas de segmentación: bási-co, Tomasulo y Marcador. La configuración, por par-te del usuario, de las características del simulador re-sulta poco amena y nada intuitiva. Uno de sus princi-pales inconveniente es que no incluye una represen-tación de la evolución del segmento de datos o de losregistros durante la ejecución del código. En su ver-sión para Windows, WinDLX incluye una represen-tación del valor de los registros en cada instrucción.

3. Simula3MS : Simulador Pedagógico

Simula3MS es un simulador cuya principal uti-lidad es su uso pedagógico por lo que el diseño y laimplementación de la herramienta ha intentado paliarlos defectos detectados en otras herramientas simila-res. Y aunque Simula3MS es ya un simulador útil,aún está en desarrollo.

3.1. Características básicas

Simula3MS es un simulador de un procesadorRISC (Reduced Instruction Set Computer) [15, 12],que implementa un subconjunto de instrucciones ba-sadas en el repertorio de instrucciones del procesadorMIPS [12]. La elección de un procesador RISC fren-te a uno CISC (Complex Instruction Set Computer)está basada en la mayor relevancia de este tipo dearquitectura. También cabe destacar que estos proce-sadores presentan una estructura y un repertorio deinstrucciones fácil de comprender. Usando una ar-

XI Jornadas de Enseñanza Universitaria de la Informática 491

quitectura RISC, los estudiantes aprenden los funda-mentos básicos del repertorio de instrucciones y dela programación en lenguaje ensamblador en menostiempo que utilizando un procesador CISC.

Simula3MS es un simulador de un procesadorconfigurable, que cuenta con un entorno de trabajosencillo que permite depurar fácilmente los progra-mas, observar la evolución de la memoria, así comola ejecución de las instrucciones sobre distintos cami-nos de datos como pueden ser monociclo, multicicloy segmentado. La interacción del usuario con la he-rramienta se hace por medio de una interfaz gráficaimplementada con Java [8, 9].Otro punto importante consiste en poder observar laevolución de todos estos componentes ciclo a ciclo(incluso paso a paso en el caso del procesador multi-ciclo) y tener también la opción de ejecutar conjunta-mente todas las instrucciones y observar únicamenteel efecto que produce la ejecución completa.

Consta de una primera parte que incluye un editory que permite cargar un programa ya existente en unfichero o editarlo desde cero en la propia herramien-ta. En esta herramienta se analizan sintácticamentelas instrucciones antes de pasar a la ejecución de lasmismas. En esta parte también se permite escoger en-tre las distintas opciones disponibles para la configu-ración de los distintos caminos de datos.

Una vez analizadas sintácticamente lasinstrucciones se puede seguir la evolución delsegmento de datos, así como de los registros y delresto del camino de datos.

3.1.1. Editor

La primera ventana que vemos al abrirSimula3MS (figura 1) es un editor.

La parte superior de esta ventana, engloba los me-nús y la barra de botones típicas de un editor, con lasalvedad del menú Configuración y el botón de Errorsiguiente. El menú Configuración permite elegir alusuario entre los diferentes procesadores implemen-tados (por defecto está seleccionado monociclo). Elbotón Error siguiente se activará en el caso de queuna vez analizado el código se produzca más de unerror sintáctico. Su función es ayudar al usuario enla corrección del código permitiendo avanzar al si-guiente error de forma sencilla.

La zona central es un área de texto destinada a la

Figura 1: Ventana del editor.

elaboración del código en lenguaje ensamblador, y lazona inferior será utilizada para destacar los erroresque se detecten al ensamblar el código.

Los botones, Ensamblar y Ejecutar aparecen de-sactivados en un principio. La finalidad de Ensam-blar es indicar si el código es, o no, sintácticamentecorrecto; si lo es, se activará el botón Ejecutar, y sino se mostrarán los errores en la parte inferior de lapantalla, indicando brevemente el motivo. Al pulsarEjecutar se pasará a la ventana que muestra el simu-lador, ésta será ligeramente diferente dependiendo dela configuración elegida.

3.1.2. Ventana de ejecución

Esta ventana presenta pequeñas variaciones segúnel tipo de camino de datos que se escoja. La figura 2se corresponde con un procesador monociclo.

Los registros se muestran en la parte superior iz-quierda y están divididos en tres partes: Registros es-peciales (como son PC, HI, LO...), Registros gene-rales, y los Registros de punto flotante.

En la parte superior derecha se puede ver el ca-mino de datos correspondiente a un procesador mo-nociclo sobre el que se representará la realizaciónconcreta de cada instrucción. En la implementaciónmonociclo (figura 3.a) y segmentado (figura 3.b)el color de esta representación dependerá del tipo de


Figura 2: Ventana del simulador para un procesador monociclo.

la instrucción. Mientras, en el caso del multiciclo va-riará dependiendo de la etapa en la que nos encontre-mos.

La realización segmentada incluye además eldiagrama multiciclo, figura 4, que se utiliza paradar una perspectiva general de diferentes situacionesdentro de la segmentación. Se considera que eltiempo avanza de izquierda a derecha, situación quese indica con el número de ciclo en la parte superiorde la imagen, y las instrucciones se desplazan de laparte superior a la inferior del panel.

El segmento de datos se puede dividir en doszonas: memoria y pila.

La memoria está dividida en dos partes, la primeracolumna, cuyo valor está entre corchetes es el valorde comienzo de la primera palabra de la línea. Lasotras cuatro columnas son los datos almacenados enla memoria de forma consecutiva.

La pila crece hacia direcciones inferiores dememoria. Igual que la memoria esta zona tambiénestá dividida en dos partes, la primera columna

indica la posición del puntero de pila y las restanteslos datos.

El segmento de texto contiene una lista deinstrucciones que componen el programa a ejecutar.Está dividido en tres columnas. En la primeracolumna se indica entre corchetes la dirección dememoria hexadecimal (PC) de la instrucción. Lasinstrucciones se almacenan a partir de la dirección0x0040000. La segunda columna es la codificaciónnumérica de la instrucción en hexadecimal, yla tercera columna es la instrucción en lenguajeensamblador.

Aquella instrucción que esté siendo ejecutado enese momento aparecerá resaltada en color azul. Si seha insertado algún punto de ruptura (breakpoint) lasinstrucciones posteriores aparecerán en gris y en cur-siva.

La parte inferior de la ventana contiene los si-guientes botones: Volver al editor, Ciclo anterior,Ciclo siguiente y Ejecutar que ejecuta la totalidaddel código o hasta el punto de ruptura. Además, en


(a) (b)

Figura 3: Caminos de datos (a) multiciclo (b) segmentado

la configuración multiciclo aparecen habilitados losbotones de Paso siguiente y Paso anterior.

Después de estos botones hay un botón de selec-ción (Breakpoint) que permite poner un punto deruptura en el código. Si se selecciona este botón seactivará el menú desplegable situado debajo de él pa-ra permitir elegir la situación del punto de ruptura en-tre las direcciones de las instrucciones desde la quese está ejecutando hasta la última del código. Por úl-timo, al final de la barra hay un número que indica elnúmero de ciclos que han sido ejecutados hasta esemomento.

4. Experiencia de uso

Simula3MS se ha usado durante este cursoen la asignatura Estructura de Computadores I[7] en las titulaciones de Ingeniería Informática eIngeniería Técnica en Informática de Sistemas enla Universidad de A Coruña. Esta asignatura nose imparte en Ingeniería Técnica en Informáticade Gestión. Estructura de Computadores I esuna asignatura cuatrimestral de 7,5 créditos (6teóricos y 1,5 prácticos) que se imparte en el primercuatrimestre del segundo curso. Los alumnos quellegan a esta asignatura han cursado en el segundocuatrimestre del primer curso la asignatura deTecnología de computadores donde se estudianlos circuitos lógicos básicos, tanto combinacionalescomo secuenciales. En el tercer curso los alumnoscompletarán sus conocimientos básicos de la arqui-tectura clásica con Estructura de Computadores II.

El objetivo de Estructura de Computadores Ies introducir y analizar los principios básicos de laorganización de los computadores. En esta asigna-tura se hace énfasis, principalmente, en los aspectosrelacionados con el procesador.

Las prácticas en esta asignatura se dividen ensesiones de una hora semanales. Es obligatoria laasistencia de los alumnos al 80 % de las sesionespara poder superar la parte práctica de la asignatura.Cada sesión está dedicada a un tema concreto,como pueden ser los saltos condicionales, el pasode parámetros en subrutinas, el uso de la pila,etc. En cada una de las sesiones se entrega a losalumnos un guión de prácticas donde se detallan lasinstrucciones de la práctica y se indica claramenteel objetivo de la misma. Además, estos guionesconstan de una serie de cuestiones cortas que debenir respondiendo durante el desarrollo de la prácticay entregar al profesor al finalizar la sesión. Estemétodo fomenta en los alumnos una actitud másactiva en el laboratorio, y permite que saquen mayorpartido de cada sesión.

La acogida por parte de los alumnos ha sidomuy buena, en especial por parte de aquellos queya tenían experiencia con otros simuladores de añosanteriores. Además, hemos constatado que en elexamen de prácticas han obtenido mejores resultadosque en los cursos precedentes. También hemosinvolucrado de forma indirecta a los alumnos en el


proceso de testeo de la herramienta, lo cual los hamotivado de cara a su uso.

5. Conclusiones y trabajo futuro

La principal utilidad de Simula3MS es su uso pe-dagógico por lo que el diseño y la implementación dela herramienta ha intentado paliar los defectos detec-tados en otras herramientas similares como Spim oDLX, que se venían usando hasta ahora.

Figura 4: Diagrama multiciclo

Simula3MS se caracteriza por dividirse en dospartes. La primera de ellas, novedosa con respecto alas herramientas anteriores, se corresponde a un edi-tor en el cual se analiza la corrección sintáctica delprograma a ejecutar. En la segunda parte se visuali-za el comportamiento del procesador que el usuariopuede elegir en la configuración, y la evolución delos registros, la pila y la memoria durante la ejecu-ción del programa. Las novedades en esta segundaparte son: la posibilidad de elegir el tipo de proce-sador, y la visualización del camino de datos y sec-ción de control. Simula3MS permite la configura-ción de tres caminos diferentes: monociclo, multici-clo y segmentado.

Como trabajo futuro se aumentarán las prestacio-nes de Simula3MS incluyendo, por ejemplo, unaunidad de punto flotante o distintas técnicas de seg-mentación como los algoritmos de Tomasulo y Mar-cador.

La herramienta está disponi-ble para su uso libre en el enlacehttp://www.des.udc.es/∼patricia/-Simula3MS.htm.

Referencias

[1] Simupro. http://www33.brinkster.com/vlaye-/software/simuproc/simuproc.html.

[2] Todd M. Austin. A Hacker‘s Guide to the Sim-plescalar Archiecture Research Tool Set. Te-chnical report, Intel Micro Computer ResearchLabs, 1996.

[3] Erich Boehm. DLX Distribu-tion Homepage. http://www.wu-wien.ac.at/usr/h93/h9301726/dlx.html, 1996.

[4] Robert L. Britton. MIPS Assembly LanguajeProgramming. Prentice Hall, 2004.

[5] Doug Burger and Todd M. Austin. The Sim-plescalar Tool Set, version 2.0. Technical re-port, Computer Science Departament, Univ. ofWisconsin, 1997.

[6] Raquel Concheiro. Simula3MS: Simulador deun procesador RISC multiciclo. Proyecto Finde Carrera, Facultad de Informátic de la Univ.da Coruña, 2004.

[7] Estructura de Computadores I.http://www.des.udc.es/∼patricia/ec1.htm.

[8] Cay S. Horstmann and Gary Cornell. Java2. Características avanzadas. Prentice Hall,2003.

[9] Cay S. Horstmann and Gary Cornell. Java 2.Fundamentos. Prentice Hall, 2003.

[10] James R. Larus. SPIM A MIPS R2000/R3000Simulator. http://www.cs.wisc.edu/-∼larus/spim.html.

[11] Marta Loureiro. Simula3MS: Simulador de unprocesador RISC segmentado. Proyecto Fin deCarrera, Facultad de Informátic de la Univ. daCoruña, 2004.

[12] David A. Patterson and John L. Hennessy. Es-tructura y diseño de computadores. Interficiecircuitería/programación. Reverté, S.A., 2000.

[13] Simula3MS. http://www.des.udc.es/∼patricia/-Simula3MS.htm.


[14] Fermín Sánchez. Características deseables enun procesador pedagógico parala enseñanza bá-sica de la arquitectura de computadores. Jorna-das de Enseñanza Universitaria de la Informá-tica (JENUI), 2002.

[15] William Stallings. Organización y arquitecturade computadores. Prentice Hall, 2000.

[16] Miguel A. Vega and Juan A. Gómez JuanM. Sánchez. Innovación docente en la Arqui-tectura de Computadores mediante el uso de Si-muladores. Jornadas de Enseñanza Universita-ria de la Informática (JENUI), 2000.

Guía visual y dinámica del funcionamiento de un procesador didáctico sencillo

Jon Cortés Ayala, Txelo Ruiz Vázquez, Izaskun Etxeberria Uztarroz Dpto. de Arquitectura y Tecnología de Computadores

Facultad de Informática, Universidad del País Vasco UPV-EHU 20018 Donostia - San Sebastián

e-mail: [email protected], [email protected], [email protected]

Resumen En este trabajo se presenta una aplicación gráfica cuyo objetivo es proporcionar una guía visual y dinámica del funcionamiento, a nivel de los com-ponentes hardware, de un procesador didáctico muy sencillo. Dicha aplicación puede ser utilizada tanto por el profesor en el aula, en lecciones ma-gistrales, como por los alumnos de manera autó-noma, para profundizar en la comprensión del funcionamiento del procesador. Por ello, cuenta con una interfaz visual atrayente y su utilización es fácil e intuitiva. Dispone también de ayuda on-line para resolución de dudas.

1. Motivación

Dentro de los tópicos que habitualmente se impar-ten dentro de una asignatura introductoria de Ar-quitectura de Computadores está el de la unidad de proceso o ruta de datos de un procesador relati-vamente sencillo [4] [5] [6]. La comprensión de su funcionamiento por parte del alumnado es fun-damental para la adquisición posterior de concep-tos más avanzados de Arquitectura de Computa-dores, como puede ser la segmentación de la ruta de datos. En nuestra Facultad, en una asignatura intro-ductoria de primer curso, denominada “Diseño de Sistemas Digitales” e impartida en el primer semestre, se presenta una versión reducida de un procesador sencillo [1] —diseñado por miembros de esta Facultad en base al procesador MIPS [4]— que es utilizado en asignaturas posteriores para introducir más conceptos de Arquitectura de Com-putadores. En dicha asignatura, planteada según un enfoque bottom-up [2], inicialmente se expo-nen los componentes básicos de un sistema digi-tal, trabajándose exhaustivamente tanto el análisis como la síntesis de sistemas sencillos, y se con-

tinúa con una introducción al diseño de sistemas síncronos con unidades de control cableadas basa-das en máquinas de estados finitas (algoritmos ASM). Como colofón de la misma, se realiza el diseño (guiado por el profesor) de un procesador sencillo, tipo RISC, con un reducidísimo conjunto de instrucciones (concretamente, cuatro) y sólo dos modos de direccionamiento: absoluto y direc-to de registro. Se diseñan tanto la Unidad de Pro-ceso como la Unidad de Control cableada (me-diante su especificación ASM). El objetivo fundamental de dicho proceso de diseño contempla dos facetas: por una parte, que los alumnos sean capaces de analizar exhaustiva-mente el funcionamiento del procesador, distin-guiendo todas las fases de ejecución de las ins-trucciones y dándose cuenta del funcionamiento concurrente de los componentes hardware; por otra parte, que adquieran la visión de conjunto necesaria para deducir qué componentes habría que añadir o modificar en la Unidad de Proceso para poder ampliar el conjunto de instrucciones del procesador con una instrucción determinada, así como cuáles serían los pasos de ejecución que debería realizar la Unidad de Control para obtener un funcionamiento correcto de la nueva instruc-ción añadida. Es obvio que la segunda faceta de-pende de la primera: si no se alcanza un conoci-miento satisfactorio del funcionamiento del proce-sador, difícil será modificar correctamente el di-seño dado para ampliar su funcionamiento. Para evaluar la adquisición de ambas compe-tencias, en el examen de la asignatura se plantea un ejercicio (habitualmente, con un peso de 2,5 puntos sobre 10) sobre el procesador sencillo, que recoge ambas facetas de manera independiente: por un lado, preguntas muy concisas y concretas sobre el funcionamiento del procesador, y, por otro, la realización de una nueva instrucción. Dada la falta de costumbre del alumnado de primer curso a la hora de comprender en profun-

498 Recursos docentes didad el funcionamiento a nivel hardware de un sistema digital de cierta complejidad, como es el sencillo procesador diseñado, surgía el problema de que un elevado número de alumnos no llegaba a alcanzar el nivel mínimo deseado, lo cual era un inconveniente en asignaturas posteriores. Dada la amplia utilización de simuladores en la enseñanza de materias de Arquitectura y Orga-nización de Computadores [8] [9] [3] y las venta-jas que en el proceso de enseñanza/aprendizaje reportan [7], en el momento en que se diseñó el procesador sencillo, se realizó también su simula-dor correspondiente [1]. Dicho simulador es utili-zado en la asignatura de primer curso “Lenguaje Máquina”, impartida en el segundo semestre, y es muy adecuado para trabajar los aspectos relacio-nados con la programación en lenguaje ensambla-dor, permitiendo visualizar los resultados obte-nidos en cada paso de ejecución —contenido del conjunto de registros y de memoria principal—, pero sin hacer hincapié en el funcionamiento del hardware, que es el aspecto que interesa recalcar en la asignatura de Diseño de Sistemas Digitales. Por ello, con el objetivo de paliar las defi-ciencias observadas, y con la idea de obtener me-jores resultados, se pensó que sería de gran ayuda didáctica el contar con un simulador específico del procesador sencillo, que hiciera hincapié en el funcionamiento de los componentes hardware (PC, IR, UAL, conjunto de registros,...) y que presentara una interfaz gráfica “amistosa” y sen-cilla, de manera que pudiera ser utilizado tanto por

el profesor en el aula durante sus lecciones magis-trales, como por los alumnos de manera autóno-ma, lo que les permitiría profundizar a su ritmo en la comprensión del funcionamiento del procesa-dor, sin presiones.

Al tratarse de un procesador específico, no era viable la utilización de simuladores ya existentes, sino que exigía el desarrollo de un simulador es-pecífico, para lo que se recurrió a plantear un pro-yecto fin de carrera (PFC). Dada la limitación de tiempo, inherente al PFC, para el desarrollo de un simulador completo, que permitiera la posibilidad de ejecución de diferentes programas, se decidió reducirlo, de manera que lo que se ha obtenido es la guía visual dinámica del funcionamiento del procesador sencillo que aquí se presenta.

2. Estructura del procesador sencillo

La unidad de proceso del procesador sencillo (figura 1) consta de un conjunto de 32 registros de propósito general (CR), una unidad aritmético-lógica sencilla (UAL), el contador de programa (PC), el registro de instrucción (IR), y una serie de registros y circuitería auxiliar (básicamente multi-plexores). Se considera una memoria principal de 64K x 16 bits. Los datos son de 16 bits, mientras que las instrucciones son de 32 bits (de ahí la di-visión del registro de instrucción, IR, en dos par-tes, IR1 e IR2, ya que se necesitan dos lecturas en memoria).

Figura 1. Estructura de la unidad de proceso del procesador sencillo (pantalla principal de la aplicación).


Figura 2. Resultado de hacer zoom sobre el algoritmo de control ASM.

En la figura 2 se puede ver el algoritmo ASM que refleja el funcionamiento de la unidad de con-trol del procesador, tal como lo muestra el progra-ma al hacer zoom sobre el recuadro de la parte in-ferior izquierda de la pantalla principal.

3. Características de la aplicación

La aplicación se ha desarrollado en el entorno Mi-crosoft Visual Basic 6.0, sobre una plataforma PC

y el sistema operativo Windows XP. Se puede eje-cutar en plataformas PC Pentium y en los sistemas operativos: Windows 9x, Milenium, NT 3.5 o su-periores, 2000/ XP. La pantalla principal (figura 3), permite ver el estado de cada componente de la unidad de proce-so mediante una interfaz gráfica intuitiva, propor-cionando toda la información necesaria para com-prender el funcionamiento de la misma: señales de control que se activan en un momento dado; esta-

Figura 3. Evolución de la información a través de la unidad de proceso en un instante dado.


Figura 4. Resultado de hacer zoom sobre la memoria principal.

do en el que se encuentra el algoritmo ASM de control; y el camino seguido por la información al circular entre diferentes componentes. Dicha información se va mostrando de manera dinámica, de forma que el usuario puede seguir in-tuitivamente todo el proceso de ejecución de cada instrucción y su efecto sobre la unidad de proceso. Además, haciendo zoom bien sobre la memo-ria principal o bien sobre el conjunto de registros, se puede ver su contenido en cualquier instante de la ejecución del programa (figuras 4 y 5).

En cuanto a su funcionamiento, se toma como base un programa ejemplo que multiplica dos nú-meros, escrito usando únicamente las cuatro ins-trucciones del conjunto de instrucciones. El usua-rio puede elegir entre tres modos de simulación: continua, ciclo a ciclo, o una instrucción comple-ta. Así, puede optar por el modo de simulación que mejor se adapta a su nivel de comprensión. En esta línea, se ofrece la posibilidad de modi-ficar la velocidad a la que evoluciona la informa-ción en la pantalla durante la simulación, así como

Figura 5. Resultado de hacer zoom sobre el conjunto de registros.


detenerla, para poder analizar detenidamente el re-sultado de alguna de las fases de ejecución, y pos-teriormente continuar con la simulación. En www.ehu.es/acwruvac/SIM/simc.htm se puede obtener la apicación (2,72 MB).

4. Conclusión

En este trabajo se ha presentado un programa que proporciona una guía visual dinámica de la unidad de proceso de un procesador didáctico muy sen-cillo. Este programa ha sido realizado como pro-yecto fin de carrera por un alumno de la titulación de Ingeniería Informática. La experiencia adquiri-da por el alumno al realizar esta aplicación ha sido muy enriquecedora, ya que no sólo se ha tenido que enfrentar al desarrollo de un programa de cierta envergadura, sino que también ha tenido que tener en cuenta las características de los posi-bles usuarios. Además, el índice de satisfacción del alumno ha sido alto, ya que ha comprobado que su trabajo es de utilidad para ayudar a otros alumnos y facilitar su aprendizaje. Por otra parte, la experiencia ha confirmado la validez de utilizar los proyectos fin de carrera co-mo generadores de recursos docentes ad hoc, to-talmente adaptados a las necesidades concretas de cada centro/asignatura/profesor, ya que se pueden tener en cuenta un sinfín de particularidades; en concreto, una de ellas es la posibilidad de que los recursos docentes estén en los idiomas utilizados por los alumnos (en el caso de la aplicación aquí presentada, está en castellano y en euskara).

La aplicación se utilizó por primera vez en la asignatura de Diseño de Sistemas Digitales duran-te el segundo semestre del curso 2003-04 y tam-bién en el primer semestre del curso 2004-05. El nivel de aceptación tanto del profesorado como del alumnado ha sido alto. Su utilización en el aula por parte del profesor se ha revelado como una potente ayuda de cara a la explicación dete-nida del funcionamiento del procesador, ya que permite hacer hincapié en los conceptos deseados: fases de ejecución de las instrucciones, funcio-namiento concurrente de los componentes hard-ware, etc., pudiendo el profesor detener la simula-ción en cualquier instante y continuar cuando desee. Antes de la utilización del simulador, se recurría a la realización manual, sobre transpa-

rencias, de cronogramas explicativos, lo que solía ser bastante engorroso, tanto desde el punto de vista del profesor, como desde el de seguimiento del alumnado.

En cuanto a resultados acerca de su influencia en el nivel de comprensión de los alumnos medido en una prueba objetiva, como es el examen, en comparación con los resultados del curso anterior cabe destacar que la nota media obtenida en el ejercicio correspondiente ha mejorado en un 30% aproximadamente. Por otra parte, se ha reducido en un 15% el número de alumnos que obtenían en dicho ejercicio una puntuación inferior a 0,5 pun-tos (sobre los 2,5 que vale el ejercicio).

Referencias

[1] Arbelaitz, O, Arregi, O., et alter. Nivel de len-guaje máquina: una aproximación. ATC-FISS. ISBN: 84-600-9519-3, 1999.

[2] Clements, A. The Undergraduate Curriculum in Computer Architecture. IEEE Micro Spe-cial Issue on Computer Architecture Educa-tion, Vol. 20, No. 3, pp. 13-22, May/June 2000.

[3] Djordjevic, J., et alter. An Integrated Environ-ment for Teaching Computer Architecture. IEEE Micro Special Issue on Computer Archi-tecture Education, Vol. 20, No. 3, pp. 66-74, May/June 2000.

[4] Patterson, D.A., Hennesy, J.L. Estructura y diseño de computadores. Interficie circuitería/ programación, Editorial Reverté, 2000.

[5] Stallings, W. Organización y Arquitectura de computadores, 5ª edición, Prentice Hall, 2000.

[6] Tanenbaum, A.S. Organización de computa-doras. Un enfoque estructurado, 4ª edición. Pearson Educación, 2000.

[7] Tangorra, F. The Role of the Computer Architecture Simulator in the Laboratory. SIGCSE Bulletin, Vol. 22, June 1990.

[8] Wolffe, G., et alter. Teaching Computer Orga-nization/Architecture With Limited Resources Using Simulators. Proc. of SIGCSE 2002.

[9] Yurcik, W., et alter. A Survey of Simulators Used in Computer Organization/Architecture Courses. Proc. of the Summer Computer Si-mulation Conference (SCSC), July 2001.

JAVATRACEIT!: software didáctico de apoyo a la docencia en Java

D. Glez-Peña, F. Fdez-Riverola, J.R. Méndez Dpto. de Informática Universidad de Vigo

32004 Ourense e-mail: { riverola, moncho.mendez }@uvigo.es

F. Díaz Dpto. de Informática

Universidad de Valladolid 40005 Ourense

e-mail: [email protected] Resumen

El objetivo de este trabajo es dar a conocer una nueva herramienta didáctica de apoyo a la docencia en asignaturas con contenidos curriculares que incluyan Java como lenguaje de programación. En concreto, JAVATRACEIT! proporciona un entorno integrado de desarrollo adaptado a Java, que permite la compilación y el análisis de código ejecutable gracias a la implementación de un sencillo depurador y optimizador, que permiten al alumno conocer el estado de un programa en todo momento.

1. Introducción y motivación

En los últimos años, Java se ha convertido en uno de los lenguajes de programación más usados por la comunidad de desarrolladores, tanto a nivel comercial como a nivel de software libre. Este hecho, se ve reflejado en su inclusión formando parte de los numerosos temarios de estudios de informática, ya sea en el mundo universitario, ciclos formativos de grado medio y superior, academias, etc. Para la docencia de Java, se ha de tener en cuenta que ningún lenguaje de programación se escapa a la máxima de programar se aprende programando, por lo que son bienvenidas las herramientas que den soporte a la enseñanza práctica de los lenguajes de programación orientados a objetos.

JAVATRACEIT! [1] surgió como experiencia piloto en la Escuela Superior de Ingeniería Informática de la Universidad de Vigo [2], a partir de la necesidad de disponer de una herramienta gratuita, potente y de fácil manejo para el desarrollo de programas Java por parte de los alumnos. El proyecto, que tuvo sus inicios en el curso académico 2002/2003, se utiliza con éxito hoy en día en las diferentes asignaturas que manejan conceptos de orientación a objetos y lenguajes de programación. La idea consistió en la construcción inicial y posterior implantación de

una herramienta de depuración y optimización de programas Java.

Los depuradores constituyen un componente presente en la mayoría de los entornos integrados de desarrollo (IDE), cuya misión es la de facilitar la búsqueda de errores de programación, principal causa de comportamientos no deseados en los programas desarrollados. Las funcionalidades generales que aportan los depuradores de propósito general, y más concretamente JAVATRACEIT!, son las siguientes:

• Ejecución, paso a paso, de las sentencias del

programa a nivel de código fuente. • Establecimiento de puntos de ruptura

(breakpoints) en el código fuente. • Visualización y modificación de los valores

de las variables y tipos no primitivos. Los optimizadores, también llamados profilers, proporcionan funciones destinadas a obtener información acerca de la ejecución de un programa para tratar de localizar puntos críticos donde el rendimiento no es el esperado, con la finalidad de mejorarlo y aumentar su eficiencia. Un ejemplo de información útil para lograr optimizar un programa es el uso que se hace de la memoria en un momento dado, analizando cuánta se usa y cómo se emplea.

JAVATRACEIT! proporciona un analizador de memoria que facilita las tareas de optimización. Cuenta además con un editor avanzado de código con funcionalidades como sintaxis resaltada, numeración de línea, visualización de paréntesis, etc. Con JAVATRACEIT! se consigue proporcionar a los alumnos una herramienta de apoyo a la programación que permite su iniciación y perfeccionamiento, teniendo disponible desde un principio los componentes más útiles de los grandes IDE comerciales. En este sentido, un depurador/optimizador no sólo sirve para detectar errores, es además muy útil para comprender el funcionamiento de cualquier lenguaje.

504 Recursos docentes 2. Arquitectura de JAVATRACEIT!

JAVATRACEIT! está implementado utilizando la plataforma JPDA (Java Platform debugger Architecture) [3] estructurada en tres capas: • JVMTI (Java Virtual Machine Tool

Interface) [4]. Especifica servicios a bajo nivel que proporciona la JVM (Java Virtual Machine) con el fin de ser utilizados por módulos nativos (librerías compartidas) que actúan a modo de cliente.

• JDWP (Java Debug Wire Protocol). Define un protocolo de comunicación vía sockets o memoria compartida entre el módulo nativo y un posible front-end.

• JDI (Java Debug Interface). Es una API 100% Java para el desarrollo de depuradores a modo de front-end.

Para desarrollar el depurador de JAVATRACEIT! se ha trabajado exclusivamente a nivel de JDI (capa superior), debido a que existe un módulo nativo JVMTI disponible en las distribuciones del JDK. Sin embargo, para el desarrollo del optimizador ha sido necesario trabajar con JVMTI, ya que JDI está orientado solamente a depuradores, no a tareas de optimización. Es por ello que se ha tenido que implementar un módulo nativo ad-hoc.

En resumen, JAVATRACEIT! puede verse como un front-end de depuración y optimización realizado en Java. Por lo tanto, durante la ejecución de la herramienta existen dos JVM: una para el programa a depurar/optimizar y otra para el propio JAVATRACEIT!. Los detalles de bajo nivel de la herramienta pueden consultarse en [5-6].

3. Utilización de JAVATRACEIT!

El aspecto que presenta la ventana de JAVATRACEIT! es similar a la que muestran los IDE comerciales (ver Figura 1).

JAVATRACEIT! proporciona un área de edición de código, además de varios paneles y herramientas para el alumno.

A continuación se describen brevemente las funcionalidades más comunes de JAVATRACEIT!, para su utilización por parte de un alumno de primer curso de una titulación de ciclo corto en informática.

Figura 1. Ventana principal de JAVATRACEIT!.

3.1. Tratamiento de ficheros fuente

Antes de poder depurar las aplicaciones de usuario es necesario abrir sus ficheros, o al menos el fichero que contiene el método de entrada. En este sentido, se proporcionan una serie de utilidades básicas para poder gestionar estos archivos. Entre estas utilidades se encuentran: nuevo fichero, abrir fichero, guardar, cerrar, etc. El usuario tiene la posibilidad de tener abiertos tantos ficheros fuente como desee. La Figura 2 muestra el editor de código con múltiples ficheros abiertos.

Figura 2. Editor de código de JAVATRACEIT!.

3.2. Ejecución paso a paso

La depuración paso a paso permite controlar la ejecución de un programa. Para ello, se proporcionan tres tipos de pasos o formas de avanzar por el código fuente en ejecución: step over, step into y step out.

Step over es el más sencillo de todos. Cuando se está en una situación de parada ante una línea de código, si se solicita un step over, se tratará de ejecutar la línea de código en su totalidad. Una vez ejecutada, se estará en una nueva situación de parada en la línea siguiente. Es por tanto, un salto


de una línea de código. La Figura 3 muestra la ejecución de este tipo de salto.

Figura 3. Step over en JAVATRACEIT!.

Step into avanza hacia el interior de la línea de código, es decir, busca la siguiente línea de código que se ejecuta internamente. Una sentencia puede incluir una o varias llamadas a otros métodos. Un step into provocará una nueva situación de parada inmediatamente antes de ejecutar la primera línea de código del primer método llamado en la sentencia exterior. Si la sentencia exterior no provoca llamadas a otros métodos, el efecto es el mismo que un step over. La Figura 4 muestra la ejecución de este tipo de salto.

Figura 4. Step into en JAVATRACEIT!.

Step out provoca que se continúe ejecutando el programa hasta que se salga del método actual, es decir, se busca el retorno al método que ha

llamado al actual. Es posible que no exista ninguno más externo, por lo que step out provocará la finalización del hilo que ejecuta dicho método, que si es el principal, finalizará la ejecución del programa. La Figura 5 muestra la ejecución de este tipo de salto.

Figura 5. Step out en JAVATRACEIT!.

3.3. Puntos de ruptura

Los puntos de ruptura o breakpoints permiten detener la ejecución del programa en una línea de código. Cuando se coloca un punto de ruptura, la ejecución se detendrá cuando cualquiera de los hilos de ejecución trate de ejecutar la sentencia donde se ha colocado el breakpoint, provocándose una nueva situación de parada.

JAVATRACEIT! permite colocar o descartar puntos de ruptura tanto antes de la ejecución, como durante ella, lo cual facilita mucho la tarea de depuración. Los puntos de ruptura en una línea de código se muestran en un tono rojizo, tal y como muestra la Figura 6.

Figura 6. Punto de ruptura en JAVATRACEIT!.

506 Recursos docentes 3.4. Gestión de variables en memoria

La gestión de las variables es una tarea muy importante en la depuración, ya que la mayoría de los errores se descubren observando los valores erróneos que toman las variables. Para navegar por estructura de la memoria, JAVATRACEIT! proporciona el árbol mostrado en la Figura 7.

Figura 7. Árbol de memoria de JAVATRACEIT!.

Cuando el programa a depurar se encuentra detenido, se muestra su árbol de memoria. El alumno puede navegar jerárquicamente por los objetos que se encuentren visibles desde la posición actual del programa. En el nivel superior se encuentran los hilos de ejecución, dentro de ellos, los registros de activación o pila de llamadas a métodos y, finalmente, los objetos o variables, que a su vez contienen más objetos hasta llegar a los tipos de datos primitivos. Es preciso destacar que JAVATRACEIT! también permite modificar el valor de las variables de tipo primitivo.

3.5. El optimizador de aplicaciones

JAVATRACEIT! dispone de un analizador de memoria para ayudar al alumno a realizar tareas de optimización o profiling. Con el analizador de memoria se puede ver el uso de memoria que hace el programa a optimizar en el sentido de que se muestra cada clase Java, el número de instancias actual de dicha clase y los bytes que ocupa. Con ello, se pueden detectar posibles usos innecesarios de memoria que provocan un mal funcionamiento de la aplicación. La Figura 8 muestra su uso.

Figura 8. Analizador de memoria de JAVATRACEIT!.

4. Conclusiones

En la presente comunicación se ha presentado una herramienta de apoyo a la docencia en Java, uno de los lenguajes con mayor calado en la actualidad. Existen soluciones que en la mayoría de los casos suponen un coste muy elevado frente al carácter gratuito de JAVATRACEIT!, además de ser muy pesadas y poco manejables en ambientes docentes. Esta herramienta se encuentra disponible para su descarga libre en la dirección http://javatraceit.siteinteresa.com.

Referencias

[1] JAVATRACEIT! http://javatraceit.siteinteresa.com

[2] ESEI: Escuela Superior de Ingeniería Informática de la Universidad de Vigo. http://www.ei.uvigo.es. 2005.

[3] Sun Microsystems. Java Platform Debugger Architecture (JPDA). http://java.sun.com/products/jpda/index.jsp.

[4] Sun Microsystems. JVM Tool Interface v.1.0. http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html.

[5] Glez-Peña, D., Fdez-Riverola, F. JavaTraceIt!, depurador y optimizador de aplicaciones Java. I Congreso JavaHispano. 2003.

[6] Glez-Peña, D., Fdez-Riverola, F. JVMTI, creación avanzada de profilers de aplicaciones con la nueva API de Tiger. II Congreso JavaHispano. 2004.

Aritmética en coma flotante y programación en ensamblador en las prácticas de Estructura de Computadores: Control de un

simulador de radar

P.A. Castillo Valdivieso, M. García Cruz, M.G. Arenas, G. Romero, A. Prieto Espinosa Dpto. de Arquitectura y Tecnología de Computadores

Universidad de Granada, 18071 Granada e-mail: [email protected]

Resumen La enseñanza del lenguaje ensamblador es complicada debido a la dificultad que supone a los alumnos enfrentarse a un lenguaje de bajo nivel. La experiencia nos dice que plantear unas prácticas atractivas al alumno les hace interesarse por dicho lenguaje y por la asignatura de Estructura de los Computadores I (en la que se estudia, en la Universidad de Granada). La programación de un control de radar puede ser una práctica atractiva a los alumnos, de forma que la programación en ensamblador resulte casi un juego conforme mejoran la programación del cálculo de las coordenadas.

1. Motivación

La asignatura de Estructura de los Computadores I, en la Universidad de Granada, estudia el lenguaje máquina, centrándose en la arquitectura de la familia 80x86. Las prácticas de esta asignatura se basan, principalmente, en el estudio del lenguaje ensamblador. A pesar de las ventajas que presenta este lenguaje en cuanto a poder realizar programas completamente adaptados a la máquina y por tanto optimizados en cuanto a velocidad y utilización de recursos [1,2], su estudio debe plantearse de forma que sea lo más atractivo y cómodo para el alumno. En este trabajo se presenta una herramienta software que simula un radar que debe ser controlado mediante un programa externo que calcule una coordenada a partir de un ángulo y una distancia. Esta práctica puede resultar atractiva a los alumnos, de forma que la programación en ensamblador sea más amena.

El radar realiza un barrido de 360 grados detectando de cuando en cuando, de forma aleatoria, objetivos que debemos capturar. El programa intercepta un objetivo a partir de la coordenada que le transmita nuestro programa de control externo. Para ello, ambos programas se sincronizan a través de dos ficheros de texto: el simulador escribe el valor del ángulo y la distancia al objeto detectado, y nuestro programa escribe la coordenada de intercepción. Además de la implementación de los accesos a los ficheros y de la sincronización de los programas, se deben realizar cálculos matemáticos en coma flotante para el cálculo de funciones trigonométricas. Para la práctica, el programa de control se debe desarrollar en lenguaje ensamblador, con objeto de que aprendan dicho lenguaje, y la arquitectura 80x86. El simulador ha sido desarrollado en C++, utilizando la biblioteca de programación gráfica gtkmm2 [3], de forma que puede ser compilado y utilizado fácilmente, tanto en Windows como en Linux/Unix. El resto del artículo está estructurado como sigue: en la siguiente sección se describe el simulador desarrollado; en la tercera sección se explica cómo usar el simulador en prácticas. La cuarta sección expone diferentes formas de calcular el seno y coseno para el cálculo de las coordenadas a partir de la distancia y ángulo. Por último, la quinta sección expone una serie de conclusiones.

2. El simulador

El sistema constará de dos programas (ver las Figuras 1 y 3): un simulador que muestra el radar (programa gráfico, a la izquierda), y otro programa que realiza el control del primero


Figura 1. Captura de pantalla bajo Windows en la que el programa-control (a la derecha) envía coordenadas al

simulador del radar (a la izquierda). En este caso, el radar muestra cinco objetivos, de los cuales el control ha interceptado a dos (a la derecha vemos las coordenadas a las que se ordena interceptar). Conforme el

detector del radar avanza, los objetivos que quedan más lejanos van desapareciendo.

(programa que se ejecuta en modo texto en una ventana de comandos, a la derecha). El sistema funciona de la siguiente forma:

1. La sincronización entre el programa-control y el simulador se hace a través de dos ficheros (S y A).

2. El simulador inicializa la ventana, dibuja el radar, y va haciendo avanzar el indicador de forma constante. A cada paso escribe en el fichero S el ángulo actual del indicador y la distancia a un objetivo detectado en ese momento (si no hubiera objetivo, escribe el valor 0 como distancia).

3. El programa-control, que estaba en un bucle de espera hasta que hubiera datos en el fichero S, lee los 2 valores. Se trata de acceder al fichero en modo de texto e ir leyendo carácter a carácter hasta encontrar un espacio, lo que indicará que se ha leído un número más. Seguiremos leyendo esa línea hasta haber leído los 2 números; después se pasan esas cadenas leídas a números enteros.

4. El control procesa esos dos valores para calcular la coordenada cartesiana (X,Y) donde debemos interceptar. Es posible que en alguna ocasión (si la distancia es 0, esto es, si no hay objetivo), el control

decida no actuar; en ese caso, los valores para X e Y deben ser igual a 0. En cualquier otro caso, las ecuaciones a utilizar serán las siguientes: X = 200 + distancia * cos(angulo) Y = 200 - distancia * sen(angulo)

5. Una vez calculada la coordenada a interceptar, se guardan los valores X e Y en el fichero A (en la primera línea, separados ambos números por un espacio). Para ello hay que pasar a cadena cada uno de los números, y escribirlos en el fichero como caracteres individuales (texto plano). Así, si la coordenada es (45,70) se guardaría como la secuencia de caracteres ‘4’, ’5’, ’ ‘, ’7‘, ’0‘, 13, 10 (el \n , en MSDOS, se cambia por los dos caracteres con códigos ASCII 13 y 10).

La sincronización por ficheros hace más fácilmente portable el sistema, y al tiempo delimita los aspectos que el alumno debe estudiar para hacer la práctica:

• E/S por pantalla • E/S por fichero • Estructuras de control complejas para la

sincronización


Figura 2. Controles del simulador para iniciar o detener su funcionamiento, para reiniciarlo, obtener información sobre

la versión del programa, o para terminar su ejecución.

• Cálculos matemáticos con números enteros y en coma flotante

• Formato IEEE-754 de representación de números reales

• Transformación de datos entre diversas representaciones

3. ¿Cómo usar el simulador en prácticas?

Hemos desarrollado una versión del simulador para Linux y otra para Win32, por lo que la práctica puede plantearse en ambos sistemas operativos. Las versiones del simulador para los diferentes sistemas pueden descargarse de la URL http://atc.ugr.es/~pedro/docencia/simuladores El programa simulador dispone de varios botones para iniciar o detener su funcionamiento, o reiniciarlo (ver Figura 2). Su función queda descrita a continuación: • “Parar” : detiene el simulador. El indicador

deja de girar y las comunicaciones se paran. • “Continuo” : comienza el funcionamiento del

radar. El indicador irá girando, y de cuando en cuando detectará nuevos objetivos. Las comunicaciones se llevarán a cabo continuamente con el programa de control.

• “Reiniciar” : si queremos probar diferentes programas-control, pulsaremos este botón, de forma que se reinicie el valor del número de objetivos y aciertos, y el indicador se sitúe en su posición inicial.

• “Ayuda” : muestra información sobre la versión del programa simulador.

• “Salir” : termina el programa.

Para sincronizar ambos programas a través de los dos ficheros, el bucle principal del programa-control (el programa que debemos realizar en ensamblador) debe ser similar al siguiente:

repetir abrir_fichero("S") mientras(no_hay_datos_en(“S”)){ cerrar_fichero hacer_pausa abrir_fichero("S")

fin_mientras // leer los datos angulo = leer_del_fichero distancia = leer_del_fichero cerrar_fichero //calcular coordenada x = calcular_coord_X y = calcular_coord_Y //escribir en “A” la coordenada


abrir_fichero(“A”) escribir_en_fichero x , y cerrar_fichero

fin_repetir

4. Cálculo del seno y coseno

Para realizar esta práctica es imprescindible utilizar números reales para el cálculo del seno y del coseno de un ángulo (ver el Apéndice I para una descripción de los cálculos en coma flotante usando el coprocesador matemático). En cuanto a posibles formas de calcular el seno y coseno de un ángulo, daremos varias posibilidades.

4.1. Desarrollo en serie

Podemos calcular el seno y coseno de un ángulo mediante los siguientes desarrollos en serie:

∑∞

=

−−

−−=

1

121

)!12()1()(

n

nn

nxxsen

∑∞

=

−−

−−=

1

221

)!22()1()cos(

n

nn

nxx

Las sumatorias las haremos con t términos, tal que la diferencia entre la suma desde 1 hasta t y la suma desde 1 hasta t+1 sea menor que una constante dada que determinará la precisión.

4.2. “Geometría recreativa”

La idea básica la tomamos de la página web: http://es.geocities.com/geometriarecreativa/geomrecreat05.htmlEn ella se nos explica cómo calcular ciertas funciones matemáticas de una forma un tanto “manual”, sin recurrir a tablas, calculadoras, ni nada.

Es cierto que con estos cálculos, el error cometido puede variar y ser algo más alto que con el método anterior, pero resulta mucho más sencillo de programar.

La idea básica que se expone es subdividir el primer cuadrante del círculo para ir calculando el seno de cada ángulo simplemente sumando una cantidad fija que podemos calcular por semejanza de triángulos. Según se explica en la página, podemos cometer errores de menos del 2% en el cálculo del seno de cualquier ángulo.

Pues bien, nosotros vamos a partir de los valores conocidos para ciertos ángulos, y vamos a obviar el porcentaje de error cometido para calcular los ángulos intermedios:

Sen(0) 0 Sen(15) 0,259 Sen(30) 0.5 Sen(45) 0.707 Sen(60) 0,866 Sen(75) 0,966 Sen(90) 1

Para ángulos intermedios sumaremos un valor calculado como (sen(a2)-sen(a1))/15 de forma que obtendremos un valor aproximado con un error aceptablemente pequeño.

De esta forma, y a partir de estos cálculos podemos obtener los valores correspondientes al seno de los ángulos de los restantes cuadrantes, y los correspondientes al coseno.

4.3. Construir la tabla completa

Una variación consiste en tener una tabla completa (360 entradas, para los 360º) para el cálculo del seno y otra diferente para el cálculo del coseno. De esta forma, para cada valor del ángulo sólo tenemos que ir a la posición de la tabla para obtener el valor ya calculado. En este trabajo no las vamos a poner, y de hecho se recomienda utilizar cualquiera de los otros métodos antes que éste.

4.4. Usar las instrucciones del coprocesador

La más rápida y sencilla de las opciones propuestas. El Apéndice I describe la forma de realizar cálculos en coma flotante usando el coprocesador matemático. Las instrucciones aritméticas que utilizaremos son las siguientes:

FCOS : calcula el coseno del valor contenido en la cima de la pila del coprocesador. Se supone expresado en radianes (habrá que transformar los ángulos leídos en grados a radianes, multiplicando por PI y dividiendo por 180). Se sustituye la cima de la pila por el valor calculado. FSIN : calcula el seno del número real contenido en la cima de la pila. Se supone expresado en radianes. Se sustituye la cima por el valor obtenido.


FSINCOS : halla el seno y el coseno del ángulo (en radianes) que hay en la cima de la pila, y deja ambos valores en la cima y en la siguiente posición de la pila.

5. Conclusiones

El aprendizaje del lenguaje ensamblador suele resultar complicado a los alumnos, así como llegar a hacerles ver la necesidad de su estudio. Sin embargo, plantearles unas prácticas amenas y atractivas puede motivarlos, evitando que les resulte tan engorroso el estudio a tan bajo nivel de la programación. Este trabajo presenta un simulador de radar desarrollado con esta idea. El alumno debe desarrollar un programa de control que recibe el valor de la distancia y ángulo del objetivo detectado, y le envía la coordenada cartesiana del objetivo a interceptar. El primer año en que se ha ofertado esta práctica varios alumnos han desarrollado programas de control siguiendo las diferentes opciones para el cálculo del seno y coseno. Les resultó estimulante y motivador comprobar cómo sus programas calculaban las coordenadas correctamente y acertaban en los objetivos.

Referencias

[1] RODRÍGUEZ-ROSELLÓ, M. A.: "8088-8086/8087. Programación ensamblador en entorno MSDOS". Anaya Multimedia, 1993

[2] BELTRÁN DE HEREDIA, Jon: "Lenguaje ensamblador de los 80x86" Anaya Multimedia. Colección Guías prácticas para programadores. ISBN: 84-7614-622-1

[3] http://gtkmm.sourceforge.net/gtkmm2 [4] STEVENSON, D.: "A Proposed Standard

for Binary Floating-Point Arithmetic: Draft 8.0 of IEEE Task P754." IEEE Comput. 14 51-62, 1981.

[5] A. Prieto Espinosa, A. Lloris Ruiz, J.C. Torres Cantero: "INTRODUCCIóN A LA INFORMáTICA 3ªed". Editorial McGraw-Hill. ISBN: 8448132173

Apéndice I. Arquitectura del coprocesador

El funcionamiento de los registros internos del coprocesador matemático es diferente al del 8086. No existen aislados ni con nombres distintos. Están estructurados en forma de pila cíclica de ocho elementos. Cada elemento de la pila es de 10 bytes de longitud (80 bits), y el formato de los datos es real temporal, de forma que el rango de valores representable va de 3.4E-4932 hasta 1.2E4932. La representación binaria interna sigue el formato IEEE754 [4,5]. El puntero de pila indica en todo momento cuál es el elemento que se encuentra en la cabecera de la pila (Stack Top). Puede valer entre 0 y 7, es decir, señala el número del elemento.

La mayor parte de las instrucciones del 8087 usan los registros de la pila. Así, las aritméticas utilizan uno o dos operandos de la pila y el resultado se deja también en la pila.

Todos los nombres simbólicos de las instrucciones empiezan por F. El conjunto de instrucciones se puede dividir en los siguientes tipos(ver [1,2] para obtener más detalles):

• de transferencia de datos. Sirven para mover

operandos entre los elementos de la pila y la memoria: FLD cargar real en la pila FST almacenar real en mem. FILD cargar entero en la pila FIST almacenar entero en mem.

• Aritméticas. Permiten hacer operaciones aritméticas. Los operandos pueden ser elementos de la pila o de memoria. El resultado se almacena en la pila: FADD sumar reales FIADD sumar num. enteros FSUB restar num. reales FISUB restar num. enteros FMUL multiplicar reales FIMUL multiplicar enteros FDIV dividir reales FIDIV dividir enteros FSQRT raíz cuadrada FABS valor absoluto

• de comparación. Sirven para comparar dos operandos. Para analizar el contenido del código de condición hay que transferir a memoria la palabra de estado: FCOM comparar dos valores reales FICOM comparar dos valores enteros


FXAM examina el tope de la pila, para determinar si contiene un valor normalizado, renormalizado, cero, infinito o vacío.

• de cálculo de funciones. Sirven para calcular funciones trigonométricas, logarítmicas y exponenciales: FPTAN tangente de un ángulo FCOS coseno de un ángulo FSIN seno de un ángulo FSINCOS seno y coseno de un ángulo

• relativas a constantes. Sirven para cargar una constante en la pila: FLDZ cargar 0.0 FLD1 cargar 1.0 FLDPI cargar PI

• de control del microprocesador. Corresponden a actividades internas del coprocesador (inicialización, cambiar modo de redondeo, permitir o inhibir interrupciones, etc): FINIT inicializar coprocesador FDISI desactivar ints FENI activar ints FSTSW almacenar palabra de estado FNOP no operación

Las del cálculo del seno y coseno corresponden al 80387, de forma que el 8087 no puede ejecutarlas.

A modo de ejemplo, veamos cómo realizar tres operaciones aritméticas sencillas y la comparación entre dos valores. No mostraremos todo el programa ensamblador, sino sólo las instrucciones que usaríamos para hacer el cálculo.

Z = Y – X * X

fld dword [x] ; st0=x ; st0=st0*st0 fmul st0 ; st0=x*x st1=x fld dword [y] ; st0=y st1=x*x st2=x ; st0=st1-st0 fsubrp st1 ; st0=y-x*x st1=y st2=x*x

fistp dword [z] ; z=st0

Z = sqrt( (X-Y) / Z )

fld dword [y] ; st0=y fld dword [x] ; st0=x st1=y fsubrp st1 ; st0=x-y st1=x st2=y fld dword [z] ; st0=z st1=x-y st2=x fdivp st1 ; st0=(x-y)/z st1=z . . . fsqrt ; st0=sqrt((x-y)/z) . . . fistp dword [Z] ; Z=st0

X = dist * cos(angulo)

fld dword [pidiv180] ; st0=PI/180 fld dword [ang] ; st0=ang st1=PI/180 fmul st1 ; st0=a=ang*PI/180 fcos ; st0=cos(a) st1=a fld dword [dist] ; st0=dist st1=cos(a) fmul st1 ; st0=dist*cos(a) st1=dist fistp dword [X] ; X=st0

Comparar X e Y

fldz ; st0= 0 fld dword [y] ; st0=y st1=0 fld dword [x] ; st0=x st1=y st2=0 ; comparer st0 con st1 (st0-st1) fcomp st1 ;cargar la palabra de estado en AX fnstsw ; si (st0<st1) entonces ah=???????1 (x<y) ; si (st0>st1) entonces ah=???????0 (x>y) and ah,00000001b jnz x_menor


… x_menor:

Figura 3. Captura de pantalla bajo Linux en la que el programa-control (abajo a la derecha) envía coordenadas al simulador del radar (arriba a la izquierda). En este caso, la pantalla del simulador muestra tres objetivos,

uno de los cuales ha sido interceptado.

LABNET: Laboratorio remoto para control de procesos

Nourdine Aliane

Departamento de Arquitectura de Computadores y Arquitectura [email protected]

Aída Martínez, Alberto Fraile, Jaime Ortiz

Área de Informática Universidad Europea de Madrid

Resumen En este trabajo, se presenta una herramienta didáctica para la realización de experimentos de control sobre maquetas de laboratorio de forma remota utilizando Internet. Las características más importantes de nuestra aplicación son: el acceso simultáneo a varias maquetas, la elección del tipo de realimentación (local o remota), la elección de un controlador predefinido y la generación automática de informes. Palabras Clave: Control Remoto, Laboratorios Remotos, Educación, Internet

1. Introducción

Dentro de la enseñanza del control automático, la realización de prácticas experimentales sobre sistemas reales es de suma importancia ya que, no solamente ayuda a los estudiantes a asimilar los conceptos teóricos, sino también desvela otros aspectos difíciles de abordar de forma teórica.

Desafortunadamente, varios factores dificultan la realización de prácticas [5] como el gran número de alumnos, la poca capacidad de los laboratorios, ya sea en medios o en espacio, lo que hace imprescindible la restricción del acceso a los laboratorios a ciertas horas prefijadas.

El acceso remoto a los laboratorios responde en gran medida a los problemas anteriores. Por un lado, permite incrementar el ratio de ocupación y la posibilidad de utilizar a tiempo compartido equipos costosos, y por otro, permite a los

alumnos realizar sus prácticas sin restricciones de horarios y un número ilimitado de veces.

Desde el punto de vista pedagógico, las prácticas realizadas de forma remota ofrecen una formación similar a las realizadas in–situ. Finalmente, hay que resaltar que para la formación de tipo semi-presencial o continuada, la flexibilidad que ofrece un sistema de acceso remoto a un laboratorio es de gran importancia.

La idea de compartir los equipos de un laboratorio usando Internet con fines educativos remonta a principio de los noventa y en el trabajo [1] se propone un esquema básico de acceso remoto a los sistemas de control de un laboratorio, así como compartirlos con otras universidades. En realidad, el artículo [2] se considera como el primer trabajo enfocado a la enseñanza del control automático a través de Internet, y desde entonces, se han llevado a la práctica varias aplicaciones relacionadas con los laboratorios remotos. En las referencias [4, 7, 8, 9], podemos encontrar todos los aspectos más importantes relacionados con los laboratorios remotos.

No se deben confundir un laboratorio virtual y un laboratorio remoto. Los laboratorios virtuales, en su mayoría, son sistemas basados en la simulación. En muchas ocasiones, estos laboratorios se instalan y se ejecutan de forma local y no requiere ningún componente externo [12]. En otras ocasiones, la ejecución de una simulación es remota. En este tipo de sistemas, el funcionamiento de la aplicación requiere los recursos de un servidor y la interacción se realiza a través de aplicaciones Web. Estas

516 Recursos docentes aplicaciones se conocen como laboratorios virtuales y remotos [3].

En los laboratorios remotos, los usuarios operan remotamente sobre ciertos dispositivos, sean didácticos como maquetas de laboratorio o industriales. El manejo del dispositivo puede ser una acción remota simple como el control de una maqueta de un tren [13], donde el control se limita a mandar ordenes. En otros casos, La acción puede tener una realimentación sobre el sistema, siendo ésta local o remota como en [6], [10] o [14]. En este caso, además de ofrecer capacidades de laboratorio virtual, los laboratorios requieren de servidores específicos que gestionan no solamente los usuarios, pero también las máquinas a tele-operar.

En la página Web de la revista “International Journal of Engineering Education” [15], así como la página del “Comité Español de Automática, CEA-IFAC”, [16], podemos acceder a varios trabajos relacionados con los laboratorios remotos o virtuales para la educación y directamente relacionados con las ingenierías como la robótica, visión por computador, la automatización, la instrumentación y el control de procesos. Finalmente, señalamos de la existencia de una red temática sobre laboratorios virtuales y remotos cuyo objetivo principal es el diseño de un portal con posibilidad de integrar varios laboratorios virtuales y ofrecer servicios de acceso a todo un banco de laboratorios virtuales y remotos.

En la actualidad, pocas universidades disponen realmente de un sistema fiable y con funcionalidades suficientes como para llevarlo a la práctica y satisfacer, así, todas las motivaciones que hemos señalado al principio.

En lo que queda del artículo, explicaremos la arquitectura y el funcionamiento de nuestro sistema. A continuación, se comentarán las funciones más destacadas del cliente y del servidor. Finalmente, se sacarán las conclusiones más importantes y se indicarán las posibles mejoras de nuestro sistema.

2. DESCRIPCIÓN DEL SISTEMA

2.1. Arquitectura del sistema

Nuestro sistema consiste en una aplicación orientada a la realización de experimentos de control con maquetas de laboratorio de forma remota utilizando la red Internet (o Intranet). La arquitectura del sistema sigue el modelo cliente/servidor, tal y como se muestra en la gráfica nº1.

Figura 1: Arquitectura del sistema El servidor es concurrente y permite gestionar hasta 4 un máximo de 4 maquetas controladas desde clientes diferentes. Esta limitación es, fundamentalmente, debida a las tarjetas de adquisición de datos utilizadas.

2.2. Modos de control

En lo referente a los experimentos de control, nuestro sistema nos permite dos configuraciones básicas: El control local y el control remoto. Control Local: En ésta configuración, el controlador está ubicado en lado servidor, como lo indica la figura nº2. La acción remota se limita a la configuración de los experimentos como la elección de la maqueta, el tipo de controlador, y el secuenciamiento de las órdenes como iniciar o parar un experimento. Finalmente, el cliente puede recibir los datos del experimento en tiempo real, o una vez finalizado el experimento.

Clientes

Maquetas

TCP/IP

Servidor

Laboratorio


Figura 2: Realimentación local

Control Remoto: En esta modalidad, el controlador está ubicado en lado del cliente tal y como lo indica la figura nº3. La realimentación se hace a través de la Internet. La inyección de los retardos de transmisión en el lazo de control afecta seriamente al comportamiento global del sistema. Estos retardos dependen de varios factores como: el protocolo utilizado (TCP, UDP), el medio utilizado para la transmisión de datos (el cable o la red inalámbrica), el tráfico en la red en el momento del experimento, etc.

Figura 3: Realimentación Remota.

2.3. Los controladores

En el control propiamente dicho, nuestro sistema cuenta con una serie de controladores predefinidos. Estos son:

• PID teórico, • PI-D filtrado • PID con Anti-Windup.

Estos tres controladores predefinidos son las más utilizadas en la industria y representan más del 95% de los controladores industriales.

2.4. Maquetas utilizadas

Nuestro sistema utiliza tres tipos de maquetas didácticas: una maqueta para el control de nivel, otra para el control de temperatura y un sistema de estabilización de barcos. En la figura nº4, podemos ver unas fotografías de las maquetas. En la Web de nuestro laboratorio [11], se pueden ver las características principales y el funcionamiento de cada una de las maquetas. Las tres maquetas admiten entradas y salidas normalizadas en voltajes y su rango de

linealidad es de 0 a 10v para las maquetas unipolares y de -10 a 10v para las bipolares. 3. LA HERRAMIENTA LABNET

Figura nº 4: Las maquetas de nivel, temperatura y

estabilizador de barcos. La herramienta LABNET se articula en 2 partes: el cliente y el servidor. En este apartado explicaremos las funcionalidades más destacadas de ambas partes.


3.1. EL CLIENTE

La aplicación cliente es el punto de entrada al sistema LABNET. Los usuarios se conectan al sistema con un usuario y de una password. El usuario tiene acceso a los servicios del sistema navegando por el sistema de menús.

Figura 5: Entorno GUI del cliente LABNET

La figura nº5 muestra el entorno GUI del cliente LABNET. Las funcionalidades más destacadas del cliente son:

• Configuración de un experimento • Visualización de datos e informes • Gestor de plantillas

Todas las ventanas del sistema tienen asociadas una ayuda breve y explicativa del elemento que se está configurando en cada momento.

3.1.1 Configuración de un experimento

Una vez ingresado en el sistema LABNET, el cliente puede activar las opciones que corresponden al experimento que se desee realizar. Las opciones más destacadas son:

• Elección de una maqueta • El tipo de control (local o remoto) • Elección de la señal de referencia • Elección de un PID (El teórico, con D-

filtrada o con Antiwindup) y sus diversos parámetros

En la figura nº 6 se puede ver el menú correspondiente a la elección de un controlador.

Figura 6: Elección del tipo de controlador

3.1.2 Visualización de datos e informes

Para visualizar los datos de los experimentos, el cliente dispone de una herramienta con las siguientes funcionalidades:

Visualización grafica: Esta opción, nos permite visualizar los datos de las variables elegidas como la salida del sistema, la señal de control, etc.

Exportación de los datos: Una vez finalizado el experimento, podemos exportar los datos a formatos más conocidos como (Excel, Matlab, html, jpeg, etc).

Generador de informes: Esta opción crea un documento de texto con los datos del usuario, los parámetros de configuración y una serie de enlaces a todos los archivos generados por el experimento. En la figura nº 7, podemos ver el modelo de un informe generado por el cliente LABNET.

Figura 7: Ejemplo de informe generado


3.1.3 Gestor de plantillas

El gestor de plantillas es una herramienta que consiste en guardar los datos de un experimento en un archivo plano. La carga de la plantilla de un experimento nos permite lanzarlo a ejecución de forma inmediata. Las plantillas de se pueden editar y modificar utilizando un editor de texto.

3.2. EL SERVIDOR

El servidor constituye un puente entre los clientes y las maquetas del laboratorio. Con su entorno GUI, el administrador puede acceder a todas las utilidades de administración de forma sencilla. Las funciones más desatacadas son:

• Administración de usuarios. • Administración de las maquetas • Administración de los experimentos • Administración de las conexiones

La figura nº8 nos muestra el aspecto del servidor

Figura 8: El servidor LABNET

3.2.1 Administración de las maquetas

Nuestro laboratorio cuenta con 9 maquetas y el sistema LABNET sólo puede gestionar un máximo de 4 maquetas.

La administración de las maquetas consiste en establecer la correspondencia exacta entre las maquetas reales y sus equivalentes virtuales definidas en el servidor, así como la especificación de los driver´s de las tarjetas de adquisición de datos.

La figura nº9 nos muestra la ventana correspondiente a la administración de las maquetas.

Figura 9: Administrador de las maquetas

El servidor lleva un modelo virtual de cada maqueta y tiene definidos varios modelos. El administrador decide que maquetas conectar al sistema, realizando la correspondencia exacta entre las entradas-salida del modelos virtual y la maqueta real.

El sistema lleva la cuenta de las maquetas activadas y los clientes disponen de esta información justo al acceder al sistema.

3.2.3 Administración de los experimentos

En la opción experimentos, el servidor nos muestra toda la información relativa a los experimentos activados en cada momento.

La información consiste en un registro de datos que identifican el usuario, la maqueta utilizada, el controlador utilizado, las señales utilizadas,

520 Recursos docentes los diversos parámetros y tiempos del experimento.

La figura nº10 nos muestra la utilidad de administración de los experimentos.

4. CONSIDERACIONES SOBRE LA IMPLEMENTACIÓN

El servidor se ejecuta sobre un PC Pentium-III con Windows 2000 y alberga 2 tarjetas de adquisición de datos PCLAB-816 para bus ISA de Advantech.

Figura 10: Administración de los experimentos

Para simplificar la configuración del sistema, se han definido modelos virtuales de entrada-salida de todas las maquetas utilizadas. Estos modelos virtuales guardan la información como la polaridad de las señales de control y de salida, sus escalas, rangos, etc. El administrador solo tiene que realizar un cableado entre las maquetas virtuales y las reales sin preocuparse de los detalles de ganancias de las tarjetas de adquisición de datos.

En cuanto a la implementación digital de los controladores PID, se ha utilizando un diseño basado en la conversión del diseño analógico utilizando la aproximación de Tustin. El modulo de los controladores está tanto en el cliente como en el servidor.

La gestión del tiempo se hace mediante el reloj multimedia de Windows. Es un reloj bastante preciso para periodos de muestreo mayores de 5 milisegundos. Un estudio estadístico del error, realizado sobre un solo temporizador nos muestra un error del 0,2% con una desviación estándar del orden de 0,05%.

Toda la implementación del sistema se ha codificado en Builder C++ y la concurrencia se ha llevado a cabo mediante los hilos de la API Win32.

5. EXPERIMENTOS Y PRUEBAS Durante la fase de desarrollo, hemos realizado varias pruebas parciales. Las más importantes son las pruebas sobre el reloj multimedia, el generador de señales, las pruebas sobre los controladores y finalmente los retardos debidos a la red

El temporizador

Las pruebas realizadas sobre el reloj de windows son de tipo estadístico y son diseñadas para evaluar la robustez y la regularidad de los temporizadores. La prueba consiste en programar un temporizador periódico que ejecute una rutina cada periodo de muestreo. Esta misma prueba se realiza un número elevado de veces y se comparan los tiempos exactos de los experimentos con los tiempos esperados.

Para periodos de muestreo del rango 5…50 milisegundos, y realizando la misma prueba 6000 veces, se ha obtenido un promedio de error del 0,2% y con una desviación estándar del orden de 0,05%. Esta prueba ha sido realizada solo para un temporizador y conviene generalizarla a varios temporizadores.

El generador de señales

Para comprobar el buen funcionamiento del generador de señales, se ha diseñado un plan de pruebas el cual consiste en generar una señal especificando los parámetros de amplitud y frecuencia, a continuación sacarla por un por un canal de salida de la tarjeta de adquisición. Esta misma señal se captura y se procesa con Matlab/Simulink. Esta prueba nos permite no


solamente comprobar la onda de la señal, sino su generación en el tiempo.

Los controladores

Las pruebas realizadas sobre los controladores son en lazo cerrado y en modo local. La prueba consiste en consiste en comparar las señales de control de PID implementado y del mismo PID, pero implementado en el Matlab/Simulink, pero tiene como entradas las mismas señales generadas por el sistema LABNET.

La figura nº11 muestra el aspecto de la respuesta de la maqueta de temperatura ante un escalón y controlada con un PID con D-filtrada.

Figura 11: La respuesta de la maqueta de temperatura

controlada con un PI-D-filtrada

El control remoto

En el caso de ejecución del algoritmo de control en la parte cliente, hemos evaluado los retardos que se añaden en la transmisión por la red dependiendo del tipo de conexión (cable o inalámbrica).

Tiendo en cuenta las condiciones experimentales (con poco tráfico en la LAN de nuestro Campus), hemos observado, en promedio, que por el cable tenemos un retardo que en todos los casos es menor de 1 milisegundo, mientras este se dispara hasta casi 42 milisegundos en el caso del acceso inalámbrico.

El efecto de los retardo sobre la calidad del control remoto es mínimo en el caso del cable, ya que las maquetas que estamos utilizando son sistemas lentos. Esto nos permite utilizar periodos de muestreo algo más elevados. En el caso de la red inalámbrica, el retardo es algo elevado, pero aun así, podemos elegir periodos

de muestreo más elevados ya que son sistemas lentos.

En todo caso, estamos añadiendo un retardo de 1 periodo de muestreo que es inherente a la implementación de un control digital.

6. CONCLUSIONES En este artículo, en un primer lugar, se han presentado los trabajos más importantes en los últimos años en el diseño de plataformas para el acceso a los laboratorios remotos. A continuación, se ha presentado nuestro sistema dando sus funcionalidades más importantes.

Nuestro sistema presenta ventajas en varios aspectos, en comparación con otros sistemas, como la posibilidad de controlar varias maquetas de forma concurrente, la posibilidad de experimentar una acción de control local o remoto, la generación de informes o la reutilización de plantillas. Estos aspectos hacen que nuestra aplicación sea funcional y productiva.

Sin embargo, pensamos que sistema LABNET es mejorable, en los siguientes aspectos: la posibilidad de cambio de los parámetros del regulador en tiempo real, la posibilidad de edición de las leyes de control, su descarga al servidor, la posibilidad de incrementar el número de maquetas de forma independiente del hardware.

Referencias [1] Aburdene, M. F., Mastascusa, et all “A

proposal for a remotely shared control systems laboratory”, Proceedings of the ASEE 1991 Frontiers in Education Conference, Session 24A3, 1991, pp. 589-592.

[2] Aktan, B, C.A. Bohus, “Distance Learning Applied to Control Engineering Laboratories”. IEEE Transactions on Education”, 1996 Vol 39(3), pp 320-326.

[3 ] J. Albino Méndez Pérez et all, Controlweb: una herramienta para el análisis y simulación de sistemas de


control en internet. XXIII jornadas de automática, Léon

[4] Control Systems Lab, The University of Tennessee at Chattanooga:

http://chem.engr.utc.edu/Webres/Stations/controlslab.html

[5] Daniel Gasa Fonollosa, et all, ”Laboratorio remoto de automática: plantas de variable discreta” XXIII jornadas de automática, Leon.

[6] Garcia, R. Murillo et all “Real-time Remote Network Control of an Inverted Pendulum Using ST-RTL”, 32nd ASEE/IEEE Frontiers in Education Conference, Boston, MA

[7] Henry, J. (1996). “Controls Laboratory Teaching via the World Wide Web”. In: Proceedings of the ASEE Annual Conference. Washington, USA, Session 3513

[8] Jamahl W. Overstreet & Anthony Tzes (1999) “Real-Time Control Engineering

Laboratory”. IEEE Control Systems Magazine, October 1999, pp 19-34.

[9] Johansson, M., Gäfvert, M. and Åström, K.J. “Interactive Tools for education in Automatic Contro”, IEEE Control Systems Magazine, June. 1998

[10] J. Sánchez and F. Morilla S. Dormido “Teleoperation of an inverted pendulum through the world wide Web“ in workshop on internet based control education. ibce’01, pages 12–14, madrid, Spain, 2001.

[11] www.esi.uem.es/laboratorios [12] http://control.ee.ethz.ch/~hybrid/tts/ [13] http://rr.informatik.tu-freiberg.de/ [14] http://www.ewh.ieee.org/soc/es/1999 [15] http://www.ijee.dit.ie/specialissues/ [16] http://www.cea-ifac.es/wwwgrupos/ [17] http://msdn.microsoft.com/library/

Empleo de Laboratorios Virtuales en el Espacio Europeo de Enseñanza

Lenin Lemus1, Alberto Llorens1, Mª. Belén Bollo1, José Manuel Gómez2

1Dpto. de Informática de Sistemas y Computadores 2Dpto. de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia 46022 Valencia

e-mail: [email protected], [email protected], [email protected], [email protected]

Resumen Desde hace dos años, la Universidad Politécnica de Valencia (UPV) está potenciando el desarrollo de “Proyectos de Adaptación al Espacio Europeo de Educación Superior” (PAEEES). Bajo este marco de trabajo, un grupo de profesores creó en el año 2004 el grupo de trabajo “Nuevas Tecnologías para el Aprendizaje Activo” (NTA2). Por otro lado, los laboratorios virtuales son una excelente herramienta para cumplir con algunos de los objetivos del Espacio Europeo de Enseñanza Superior (EEES). En esta ponencia se presentan los objetivos del grupo NTA2. A continuación, se describen los objetivos de un proyecto PAEEES propuesto por el grupo NTA2 y finalmente se describe con detalle una de las seis acciones que componen al proyecto PAEEES, en concreto nos referimos a la acción especial Laboratorios Virtuales.

1. Introducción

Desde hace dos años, la Universidad Politécnica de Valencia (UPV), dentro del marco de Integración en el EEES (“Espacio Europeo de la Enseñanza Superior”), ha potenciando la creación de grupos de trabajo encaminados a la mejora de la calidad de las asignaturas impartidas en su seno. En el año 2004, se crea el grupo de Innovación Educativa NTA2 (“Nuevas Tecnologías para el Aprendizaje Activo”), el cual pretende revisar y aplicar aquellas innovaciones tecnológicas que contribuyan a la convergencia hacia dicho Espacio Europeo derivado de la Declaración de Bolonia.

Para este fin, el grupo NTA2 propuso llevar a cabo un PAEEES (“Proyecto de Adaptación al Espacio Europeo de Educación Superior”) en donde los objetivos que se persiguen son tres:

1. Revisar y establecer un catálogo de los

trabajos relacionados con la aplicación de las

TIC (“Tecnologías de la Información y la Comunicación”) en el ámbito educativo de la UPV, tanto a nivel de ponencias o publicaciones como de proyectos y herramientas desarrolladas.

2. Estudiar y analizar la viabilidad de aplicar dichas tecnologías para dar soporte a metodologías de tipo activo, en diversos contextos tales como la docencia presencial, el aprendizaje a distancia o el trabajo en grupo, y teniendo en cuenta aspectos como los sistemas de evaluación, la realización de actividades prácticas, la gestión de proyectos o la resolución de problemas.

3. Realizar casos prácticos en asignaturas correspondientes a titulaciones de la UPV donde se primará el aprendizaje activo entre los alumnos que cursen dichas asignaturas. Para ello se utilizarán tecnologías como campus virtuales, acceso a laboratorios remotos, herramientas de evaluación, tutores inteligentes, libros electrónicos, entornos colaborativos, dispositivos móviles.

Por tal motivo se han creado seis acciones:

1. Docencia presencial. 2. Evaluación. 3. Aprendizaje Colaborativo. 4. Laboratorios Remotos. 5. Laboratorios Virtuales. 6. Gestión de Proyectos.

En esta ponencia se presentan los resultados de la acción correspondiente a Laboratorios Virtuales.

La ponencia está estructurada de la siguiente forma: • En la sección dos, se presenta la motivación

por la cual aparecen los laboratorios virtuales y se propone una definición del concepto “Laboratorio Virtual”. Ya al final del presente documento, en el Apéndice A, se facilita una revisión histórica de los


acontecimientos más importantes sucedidos en el ámbito de los laboratorios virtuales.

• En la tercera sección se presentan los criterios para establecer un catálogo de los laboratorios virtuales disponibles. Este apartado también se dedica al material didáctico que se presenta para que sea utilizado en las asignaturas de la UPV.

2. Laboratorios virtuales

En esta sección se define el término que en el proyecto PAEES NTA2 se le ha dado a “Laboratorio Virtual”. Cabe destacar, que algo tan trivial como presentar una definición no ha sido fácil, debido a que sus características han ido evolucionando de la mano de Internet, de manera que la idea de laboratorio virtual puede variar dependiendo del entorno en el cual se utilice.

Para llegar a esta definición, primero se establecen la motivación de los laboratorios virtuales, a continuación, se presentan las características aceptadas por la comunidad educativa para un laboratorio virtual y finalmente se presenta nuestra definición, que de ninguna manera trata de ser la única aceptable en las comunidades científica o educativa.

2.1. Motivación

En la sociedad moderna en la que nos encontramos, la educación a distancia requiere de sistemas de enseñanza más flexibles, accesibles y adaptativos.

Hasta hace unos años, el modelo educativo de educación a distancia se basó fundamentalmente en las tutorías por teléfono o en el correo ordinario. Actualmente, las nuevas tecnologías ofrecen: • Los sistemas hipermedia como forma de

estructurar la información • E Internet como soporte de dicha

información [1]. A pesar de que estas dos herramientas, pueden

ser suficientes, para la creación de sistemas de apoyo al aprendizaje de materias dotadas de una componente práctica no muy fuerte, la enseñanza de asignaturas tales como: el control automático, la arquitectura y tecnología de computadores, la física, etc., requiere de algo más. De un elemento

que permita al estudiante poner en práctica todos los conocimientos que vaya adquiriendo a lo largo del estudio de la materia y, esto, en algunos casos, requiere de la manipulación de equipo sofisticado.

En las enseñanzas tradicionales, este papel lo desempeñan las prácticas realizadas en los laboratorios. Tradicionalmente, este tipo de prácticas fueron pensadas para contar con la presencia física tanto del estudiante como del profesor.

El poder trasladar este entorno práctico a la enseñanza a distancia, requiere de la existencia de un sistema de apoyo: un laboratorio virtual.

2.2. Definición

En el apéndice A, se proporciona una revisión histórica de la evolución del concepto de laboratorio virtual. A partir de esta evolución, se puede ver que algunos autores conciben un laboratorio virtual como un programa de simulación [8]. Otros, consideran que un laboratorio virtual se encarga del control remoto de la instrumentación. Por otro lado, en el artículo [10] publicado en 1995 “The Virtual Laboratory: Using Networks to enable Widely Distributed Collaboratory Science”, los autores, establecen que un laboratorio virtual debe cumplir con los siguientes requisitos: • Control remoto y monitorización de los

experimentos. • Comunicaciones multimedia entre los

investigadores, a ser posible en multicast. • Un cuaderno de notas digital con todas las

facilidades para introducción de datos, ficheros, figuras, búsquedas, etc.

• Gestión de los recursos, para decidir adecuadamente que usuario o usuarios puede acceder a cada uno de los experimentos disponibles.

• Seguridad tanto en el aspecto de permitir y denegar acceso como en los recursos para gestionar posibles fallos del sistema.

• Diversos tipos de comunicación: Voz, imagen, datos, resultado de experimentos, estado de los experimentos.

• Ancho de banda: Adecuado para permitir las distintas comunicaciones de datos científicos como de imágenes o vídeo.


Si analizamos estas características, podemos

encontrar muchas similitudes con las funcionalidades básicas de un sistema de gestión de contenidos (CMS: Content Managent System).

De hecho, en el artículo “Introducción a los Sistemas de Gestión de Contenidos (CMS) de código abierto” [18] se explica que los CMS proporcionan un entorno que posibilita la actualización, mantenimiento y ampliación de la Web con la colaboración de múltiples usuarios. Y como sabemos, en cualquier entorno virtual ésta es una característica importante, que además puede ayudar a crear una comunidad cohesionada que participe más de forma conjunta.

El grupo de trabajo NTA2 ha tomado en cuenta esto y de hecho se estudian en profundidad los entornos para la gestión de proyectos y el aprendizaje colaborativo.

Por lo tanto, en nuestro caso concreto definiremos a un “Laboratorio Virtual” de la siguiente forma: 1. El objetivo primario de un “Laboratorio

Virtual” debe ser el de proporcionar una experiencia similar a la obtenida en un laboratorio de prácticas.

2. Un “Laboratorio Virtual” es un conjunto de recursos compartidos en la red con el fin de que los usuarios puedan poner en práctica los conocimientos teóricos adquiridos. Por lo que es recomendable que posea recursos para: • La simulación de sistemas. • El control remoto de sistemas. • La monitorización de los experimentos vía

WEB. • La gestión de dichos recursos.

3. La gestión de estos recursos es recomendable que se realice mediante un CMS, el cual debe proporcionar mecanismos para: • Dar de alta a los usuarios de los recursos y

agruparlos (investigadores, alumnos profesores).

• La creación de experimentos. • Control y monitorización de

experimentos. • Comunicaciones multimedia entre los

investigadores. • Un cuaderno de notas digital. • Gestión de los recursos. • Seguridad. • Diversos tipos de comunicación.

• El mayor ancho de banda posible 4. Mecanismos para evaluar el aprendizaje de los

usuarios, con el fin de validar el objetivo primario: ”Proporcionar una experiencia similar a la obtenida en un laboratorio de prácticas”.

3. Trabajo realizado en la acción “Laboratorios Virtuales”

En el proyecto PAEES, se acordó que cada acción realizara, como mínimo, los siguientes puntos: 1. Revisar y establecer un catálogo de los

trabajos relacionados con la aplicación de las TIC.

2. Estudiar y analizar la viabilidad de aplicar dichas tecnologías para dar soporte a metodologías de tipo activo.

3. Realizar casos prácticos en asignaturas correspondientes a titulaciones de la UPV.

En lo referente al punto número uno, se han realizado dos acciones: • Recopilación de los enlaces a laboratorios

virtuales que se proporcionan en Internet. (ver sección 3.1).

• El desarrollo un conjunto de herramientas software para gestionar los enlaces. (Ver sección 3.2).

En lo referente al punto número dos, se observó que mediante la utilización de un CMS y la creación de recursos didácticos era factible desarrollar laboratorios virtuales. Así pues, se han desarrollado dos recursos virtuales:

• Un osciloscopio Virtual. • Un generador de Funciones.

Estos recursos didácticos están disponibles a toda la comunidad bajo licencia GPL. En la sección 3.3 se presenta el osciloscopio Virtual. Finalmente, en lo que respecta al punto número 3, se está desarrollando un “Laboratorio Virtual” para la práctica de experiencias de Física. Este laboratorio está basado en los recursos didácticos del osciloscopio Virtual y del generador de funciones. Se está utilizando en la asignatura “Fundamentos Físicos de la Informática” impartida en las titulaciones ITIS e ITIG de la UPV.

526 Recursos docentes 3.1. Revisión y Catalogación

En primer lugar, se realizó una recopilación de los enlaces a Laboratorios Virtuales que se encuentran en Internet. En paralelo, se diseñó un catálogo de esos enlaces mediante la creación de una base de datos, en la cual se almacenan las características más importantes relativas a cada uno de los enlaces, como por ejemplo: título del laboratorio, descripción, tecnología empleada, universidad que lo desarrolla, etc.

Actualmente se tiene una base de datos con alrededor de 200 enlaces a Laboratorios Virtuales existentes en la red.

Ésta y otra información está disponible a la comunidad a través del servidor http://didas.disca.upv.es:8080/portal_recursos

Para la catalogación de dichos enlaces fue

necesario utilizar estándares de clasificación de las áreas del conocimiento. En nuestro caso particular, hemos utilizado la nomenclatura internacional de la UNESCO para los campos de la Ciencia y la Tecnología disponible en http://www.cica.es/aliens/otrius/otrius/CodUnesco/List_CodUnesco.htm. Con esto, se ha creado una base de datos con los códigos que dicha organización establece actualmente para las áreas científicas de ciencia y tecnología.

Adicionalmente se han implementado una serie de herramientas que nos permitirán mantener esas bases de datos de una manera más cómoda y sencilla.

3.2. Herramientas software

Para el mantenimiento de las bases de datos se han implementado dos herramientas con el objetivo de facilitar la realización de esta tarea a aquellos encargados de llevarla a cabo tanto actualmente, como en el futuro.

Distinguimos las herramientas en dos puntos relativos a cada una de las bases de datos que hemos creado. Así pues tenemos que: • Para la creación de la base de datos de los

códigos UNESCO, y puesto que previsiblemente se trataba de una base de datos extensa (ahora con más de 2200 registros) se creó una herramienta Web en JSP. Esta herramienta nos permitía insertar todos

esos registros en una base de datos Access y, al mismo tiempo, estructurar toda esa información en XML creando una serie de archivos XML clasificados por campos científicos. De esta manera, tenemos la oportunidad de guardar dos orígenes de datos estructurados para la obtención de dichos códigos.

• Para el mantenimiento de la base de datos de enlaces a Laboratorios Virtuales se ha implementado otra herramienta que nos permite, mediante una interfaz más agradable, poder llevar a cabo esta tarea de una manera cómoda y sencilla.

Con ayuda de la tecnología .NET se han desarrollado aplicaciones Web en ASP .NET, mediante las cuales se hace más visible el mantenimiento de la base de datos de enlaces a Laboratorios Virtuales. Estas herramientas permiten vía Web, modificar los enlaces almacenados en la base de datos y/o dar de alta los nuevos enlaces que aparezcan en Internet para continuar, de esta forma, nuestra recopilación de los trabajos relativos a laboratorios virtuales.

3.3. Material didáctico para las asignaturas de la UPV

Para crear un laboratorio virtual, se propone la utilización de un CMS que se encargue de gestionar: la creación de usuarios, la realización de experimentos y el acceso al material. En nuestro caso proponemos utilizar el CMS Plone. http://plone.org

Bajo este entorno, se ha dejado disponible un

recurso didáctico que es un osciloscopio virtual. El Osciloscopio Virtual (OV) es

fundamentalmente una herramienta didáctica, aunque también está pensada para ser utilizada como herramienta de trabajo. Presenta una interfaz muy elaborada que le proporciona un realismo asombroso (ver figura 1). Esta característica y la gran facilidad de interacción entre el usuario y el OV permiten estudiar y usar este aparato con suma facilidad. Se ha buscado el máximo parecido con un osciloscopio analógico real aunque se le ha dotado de ciertas características que permiten utilizarlo como herramienta de trabajo, esto nos ha llevado a


incluir una versión digital del instrumento, aunque muy simplificada.

Sus características principales son: • Una interfaz gráfica casi idéntica a la carátula

de los osciloscopios reales de doble traza, donde los botones se pueden pulsar, girar y encender utilizando el ratón.

• Un método de enseñanza y evaluación interactivos mediante tutoriales y preguntas que pudieran ser evaluadas a posteriori por el sistema de forma automática.

• Un buen visualizador de señales sintéticas y reales.

• Comunicación con otras aplicaciones a través de puertos de comunicaciones y LiveConnect.

• Interacción con un repositorio de tutoriales de diferentes idiomas y señales.

• Posibilidad de visualizar señales reales a través de largas distancias.

Una de las principales especificaciones del

OV es que se pudiera acceder a él desde cualquier sitio, utilizando la Web y un simple navegador. Así, el alumno no tendría que depender de ningún laboratorio o máquina especial. El alumno puede trabajar desde su casa o desde cualquier lugar con acceso a Internet. Los Applets de Java son programas que se pueden añadir a una página Web para dotar al navegador de mayor operatividad y poder realizar, de esta forma, complejas aplicaciones. Nuestro OV es un Applet de Java que funciona desde cualquier navegador que soporte Java.

El OV tiene dos modalidades de trabajo: una

modalidad analógica, orientada a la enseñanza, y otra digital, orientada a su uso práctico.

En la modalidad analógica del OV una señal

aparecerá como se mostraría dicha señal en un osciloscopio real según la configuración establecida de la simulación. De este modo, el usuario puede variar la posición de cualquiera de los mandos del instrumento y comprobar su efecto sobre la visualización de la señal de forma completamente interactiva. Esto puede ser especialmente útil en los conceptos de difícil asimilación como suelen ser los relacionados con la etapa de disparo.

Para fomentar el aspecto educativo de la herramienta se han incluido unos tutoriales que explican con detalle el funcionamiento del instrumento. El usuario es guiado en todo momento por medio de unos bocadillos, tal y como se aprecia en la Fig. 2. Los tutoriales vienen definidos por una serie de archivos de texto que permiten establecer diferentes configuraciones para cada paso del tutorial y así forzar a estar en un estado dado en algún momento del tutorial, aunque también se puede dejar libertad al usuario para que se vea forzado a seguir los pasos de la explicación si quiere terminar correctamente el tutorial.

Figura 1. Tutorial interactivo.

Una característica relevante del OV es que permite una evaluación automática de los conocimientos adquiridos por el alumno en el uso del osciloscopio. Es decir, que mediante una interfaz en LiveConnect de JavaScript se puede hacer una pregunta al alumno a través de un simple navegador Web para que el alumno modifique los valores de la simulación y después que el propio navegador, utilizando su interacción con el simulador, pueda indicar al alumno o al profesor de forma automática si el ejercicio se ha realizado correctamente. Así, junto con la pregunta, se establecerá los valores correctos que debe tener el OV cuando se termine el ejercicio y automáticamente el navegador preguntará al OV si está establecido correctamente o no y así evaluar al alumno. En la modalidad digital el OV pasa a tener un control más exhaustivo de la visualización de la señal ya que, mediante una barra de desplazamiento, se puede elegir qué porción de la señal aparece en pantalla. Además, al contrario que en el modelo analógico, la señal está detenida

528 Recursos docentes en la pantalla permitiendo ampliarla, reducirla y desplazarla verticalmente y horizontalmente.

Figura 2. Recurso didáctico, osciloscopio virtual.

Conclusiones

En esta ponencia se han presentado los resultados obtenidos en la acción Laboratorios Virtuales del proyecto PAEEES llevado a cabo por el grupo NTA2. Dichos resultados son: 1. En el portal del grupo NTA2

http://didas.disca.upv.es:8080/portal_recursos bajo la acción “Laboratorios Virtuales” se encuentran páginas WEB con los resultados obtenidos.

2. Una catalogación de las URLs de laboratorios virtuales.

3. Para la creación de nuevos laboratorios virtuales se cuenta con la herramienta que hemos creado: el OV, un recurso didáctico útil para aprender a utilizar un osciloscopio.

4. El recurso didáctico está a disposición de la comunidad bajo licencia GPL.

5. En la WEB del grupo NTA2 se encuentra un tutorial de utilización del OV.

Durante el presente curso (2004-2005) este recurso está siendo utilizado en la asignatura de “Fundamentos Físicos de la Informática”.

Finalmente, los autores del artículo encontramos útil la idea de agregar a un CMS recursos didácticos para crear laboratorios virtuales que faciliten la enseñanza bajo el marco del EEES.

Apéndice A. Antecedentes Históricos de Laboratorios Virtuales

Como hemos visto, la motivación de los laboratorios virtuales surge, básicamente, por la necesidad de crear sistemas de apoyo al estudiante para sus prácticas de laboratorio con el objetivo de optimizar el tiempo que éste emplea en la realización de dichas prácticas. Sin embargo, el concepto de laboratorio virtual se ha ido extendiendo a lo largo de las últimas dos décadas.

La tesis doctoral “Modelo de referencia de laboratorios virtuales y Aplicaciones a sistemas de Tele-educación” [2] recoge gran parte de la revisión histórica relativa a los laboratorios


virtuales y sus características principales. A continuación, basándonos en esta tesis trataremos de revisar las aportaciones más interesantes que han ido apareciendo a lo largo del tiempo.

1984: Aparece el concepto de instrumento virtual [3] como instrumento cuyas características vienen definidas por la programación.

1992: Aparece una de las primeras referencias a laboratorios en los que intervienen operadores a distancia bajo el apelativo de Laboratorio distribuido [4]. Además, aparece explícitamente el término laboratorio virtual [5], describiendo la programación orientada a objetos como sistema para el desarrollo de un laboratorio de simulación.

1993: Lo más interesante a destacar es la aparición de un nuevo concepto, que es el colaboratorio [6].

1994: Se presenta un estudio realizado por la Universidad de Vanderbilt en EE.UU. en el que se desarrolla un laboratorio virtual basado en simulación como apoyo a las prácticas tradicionales [7] y, que concluyó, con la necesidad de esta herramienta para aprender las habilidades básicas y el manejo de los equipos, lo cual optimizaba tanto el tiempo de los alumnos como el del personal de laboratorio.

Ese mismo año aparece un artículo [8] en el que se define explícitamente un laboratorio virtual como un programa de simulación.

Además, cabe destacar la aparición de una experiencia pionera en el campo del control remoto, ya no de instrumentación sino de robots [9] que permitía controlar remotamente un brazo robot. Dicha experiencia puede ser considerada actualmente un laboratorio virtual.

1995: Encontramos una descripción detallada de los requisitos que un laboratorio virtual debe cumplir [10], encontrando, a la vez, una serie de similitudes con las características de otra tecnología Web desarrollada en los últimos años.

1996: A lo largo de este año, encontramos diversos artículos que nos van indicando elementos necesarios para el éxito de un sistema de educación a distancia. En estos artículos se recalca que el aprendizaje activo es lo que debe predominar en las prácticas y por tanto un laboratorio que pretenda ofrecerse por control remoto debe facilitar: • Colaboración entre usuarios. • Presencia activa.

• Control completo sobre el entorno y libertad para realizar lo que se desee. 1997: En la conferencia del IMTC

encontramos un repaso de normas relativas a instrumentos virtuales [13].

Este mismo año, investigadores de la Universidad de Illinois presentan un completo laboratorio de instrumentación electrónica puesto a disposición de los usuarios a través de Internet. Este es el primer laboratorio virtual con control remoto de instrumentación electrónica en funcionamiento [14].

1998: Las referencias a laboratorios virtuales incrementan su número de forma considerable. Una de las más destacadas, es la conferencia de IMTC y la asociada ETIMVIS’98 donde se describe un modelo detallado de un laboratorio virtual de simulación [15], y una propuesta de laboratorio docente en el que los alumnos utilizan instrumentos virtuales para crear sus experimentos.

1999: Además de los consejos respecto al uso del Web en clases que recoge este artículo [16] y en el que se incluyen referencias a laboratorios virtuales de simulación y de control remoto, encontramos en el IMTC una detallada especificación [17] de cómo montar un laboratorio virtual con elementos comerciales disponibles, junto con los requisitos básicos que debe afrontar cualquiera que se plantee el diseño de un laboratorio virtual.

2000: Se van sucediendo artículos en conferencias y revistas donde se describen distintos laboratorios virtuales y donde se va entrando en detalle en los distintos métodos a utilizar en el desarrollo de laboratorios virtuales y se comentan posibles soluciones que mejoren o aumenten el rendimiento de éstos. La idea de utilizar la simulación como paso previo al uso de los instrumentos permitirá que se reduzca el tiempo necesario de uso del instrumento real y por tanto, del recurso más costoso.

Por último, solo cabe destacar las múltiples referencias en las que se presentan experiencias en distintos laboratorios distribuidos de distintas áreas experimentales que se han extendido por la red en los últimos años y, de los cuales se ha hecho una recopilación y catalogación en este trabajo.


Referencias

[1] Sánchez, José. Dormido, Sebastián. Morilla, F. Laboratorios virtuales y remotos para la práctica a Distancia de la Automática. Departamento de Informática y Automática, UNED.

[2] Rodrigo, Vicent M. Modelo de referencia de laboratorios virtuales y Aplicaciones a sistemas de Tele-educación, 2003.

[3] Goldberg, Harold. What is Virtual Instrumentation? IEEE Instrumentation & Measurement Magazine, 2000.

[4] Mercurio, Philip J., Elvins T.T., Young Stephen J., Cohen, Philip S., Fall, Kevin R., Ellisman, Mark H. The distributed laboratory: an interactive visualization environment for electron microscope and 3d imaging. Communications of the Association for Computing Machinery, 1992.

[5] Haden, G.L. An object Oriented Modelling and Simulation Component for Virtual Engineering Laboratories. Proceedings of 22nd annual conference Frontiers in Education, 1992.

[6] Cerfetal, V.G. National Collaboratories – Applying Information Technology for Scientific Research. Committee on a National Collaboratory, National Research Council. National Academy Press, Washington D.C. 1993.

[7] Mostermean, P.J. Donaldt, M.A.M. Campbell, J. Olin. Burow, C. Bouw, R. Brodersen A.J. Bourne J.R. Virtual Engineering Laboratories: Design and Experiments. Journal of Engineering Education, 1994.

[8] Mostermean, P.J. Campbell, J. Olin. Design and Implementation of an Electronics Laboratory Simulator. P.J. Mostermean, J. Olin Campbell, R. Brodersen A.J. Bourne J.R. IEEE Transactions on Education. 1996.

[9] Goldberg, Ken. Mascha, Michael. Gentner, Steven. Rossman, Juergen. Rothenberg, Nick. Sutter, Carl. Wiegley, Jeff. The Mercury project – Robotic tele-excavation. Beyond the Web: Excavating the Real World Via Mosaic. International WWW Conference. Chicago, 1994.

[10] Johnston, William E. Agarwal, Debora. The

Virtual Laboratory: Using Networks to enable Widely Distributed Collaboratory Science. Ernest Orlando Lawrence Berkeley National Laboratory, University of California, 1995.

[11] Hernández, A.M. Benlloch, J.V., Benet, G. Sistema de instrumentación programable multiusuario vía red local para el desarrollo de prácticas de laboratorio. II Congreso TAEE ’96, Sevilla 1996.

[12] Benlloch, J.V. Lemus, L. Buendía, F. García J.M. Bayo, J.L. Remote Data Acquisition over the Internet. Annual Conference on Education in Electrical and Information Engineering, 2000.

[13] Spoelder, H.J.W. Ullings, A.H. Groen, F.C.A Virtual Instrumentation: A survey of Standards and their Interrelation. IEEE Instrumentation and Measurement Technology Conference. Ottawa, Canada, 1997.

[14] Werges, Stephan C. Naylor, David L. A Networked Instructional Instrumentation Facility. Annual Meeting of the American Society for Engineering Education, Milwaukee, 1997.

[15] Ferrero, Alessandro. Piuri, Vincenzo. A Simulation Tool for Virtual Laboratory Experiments in a WWW Environment. IEEE IMTC. St. Paul, Minnesota, Mayo 1998. IEEE Transaction on Instrumentation and Measurement, 1999.

[16] IEEE Control System Magazine. Using the Web in Your Courses: What Can You Do? What Should You Do?, Febrero 1999.

[17] Benetazzo, L. Bertocco, M. Ferraris, F. Ferrero, A. Offelli, C. Parvis, M. and Piura, V. A Web-Based Distributed Virtual Educational laboratory. IEEE TIM, 2000.

[18] García, Xavier C. Alfonso, Julià M. Introducción a los Sistemas de Gestión de Contenidos (CMS) de código abierto. Departamento de Informática y Automática, UNED, 2004.

EIPMail: Una herramienta para la retroalimentación en evaluación continua vía correo electrónico.

Luis Martín, Borja Monsalve y Francisco Carrero Dpto. de Sistemas Informáticos

Escuela Superior Politécnica Universidad Europea de Madrid

28670 Villaviciosa de Odón, Madrid e-mail: {luis.martin, borja.monsalve, francisco.carrero}@uem.es

Resumen La herramienta que aquí se presenta pretende servir como sistema de apoyo a la retroalimentación de información al alumno en evaluación continua. Los libros Excel son un recurso utilizado por gran parte de los docentes para el control y seguimiento de la evaluación continua. EIPMail (Envío de Información Personalizada vía eMail) trabaja directamente sobre los datos almacenados en una hoja Excel, permitiendo la selección de los mismos y su envío formateado en un correo electrónico a cada alumno de forma personalizada. Este recurso docente ha gozado de una considerable aceptación entre el alumnado y quiere ser el primero de un conjunto de programas de apoyo a la docencia construidos en torno a libros Excel.

1. Introducción

Los nuevos modelos educativos conllevan metodologías de trabajo diferentes a las tradicionales. En evaluación continua se pretende premiar el esfuerzo continuado del alumno, pudiendo tener influencia directa en la nota final aspectos como la participación en clase o la asistencia. Todo esto supone que el alumno está recibiendo notas o valoraciones que afectan a su evaluación con una frecuencia mucho mayor que en evaluación global. La normativa de evaluación, además, se vuelve más compleja, lo que lleva asociado una dificultad añadida tanto para los estudiantes como para los profesores. Si se pretende que el sistema de evaluación continua funcione, la metodología de trabajo no

puede quedarse anclada en el sistema de evaluación global. Dado que el número de pruebas aumenta, y dado que cambia su naturaleza, se hace necesaria una capacidad de comunicación mayor entre el alumno y el profesor (nótese que se habla del alumno en singular). El requisito mínimo es establecer un procedimiento de retroalimentación de información al alumno sobre su evaluación de forma continuada. La frecuencia de esta retroalimentación debe ser proporcional, además, a la frecuencia de asignación de notas y valoraciones en evaluación continua. Para llevar a cabo la tarea de informar a los alumnos sobre su evaluación de manera periódica, en condiciones normales se hace imprescindible que el número de alumnos en un mismo grupo sea manejable [1]. En ocasiones la reducción de este número de alumnos no es viable por problemas relacionados con los recursos (humanos o materiales) de los departamentos, por lo que se deben idear soluciones alternativas para poder mantener estos esquemas de evaluación.

2. Motivación

Entre los principales objetivos de la Declaración de Bolonia [4][5], destacan la unidad y la cooperación. La implantación de metodologías activas en el aula que fomenten estos principios tiene un alto grado de importancia. Por ejemplo, una de las técnicas que está alcanzando gran popularidad es el Aprendizaje Cooperativo. Esta metodología puede aplicarse a la resolución de ejercicios prácticos en el aula: el profesor divide la clase en grupos reducidos de alumnos, a los cuales asigna ejercicios o problemas a resolver.

532 Recursos docentes Para la realización de esta tarea los estudiantes disponen de tiempo en el aula, pero la mayoría del trabajo lo realizan los grupos de forma autónoma fuera del horario de la asignatura. Tras esto se procede a la corrección, donde cualquier miembro del grupo puede ser requerido para resolver el problema, y la calificación obtenida es la que finalmente reciben todos los componentes del grupo. Toda esta metodología encaja dentro del sistema de evaluación continua seguido en una asignatura, donde el alumno obtiene también una calificación a partir de los distintos exámenes parciales que va realizando a lo largo del curso. La nota final de la materia sería el resultado de un reparto porcentual de los diferentes exámenes, notas de ejercicios de clase, notas de las prácticas de laboratorio y asistencia a las clases que el estudiante va obteniendo a lo largo del curso. Para que el alumno tenga conocimiento de su situación en la asignatura, se revela determinante el hecho de que pueda estar al tanto en cada momento el estado de su evaluación. En el caso que nos ocupa, y como se ha comentado con anterioridad, son varios los factores que influyen en lo que se convertirá en la calificación final del alumno. Se hace necesario informar al estudiante acerca de sus evoluciones (porcentaje de asistencia a clase, notas en los ejercicios, calificaciones de las prácticas, etc.), con una frecuencia acorde con el ritmo de la asignatura. El sistema de comunicación elegido ha sido el correo electrónico. Se ha escogido este medio por su carácter activo: el correo electrónico permite al profesor decidir el ritmo con el que un alumno recibe la información, viéndose así reforzada su labor de director de la asignatura en evaluación continua. Existen alternativas de comunicación basadas en tecnología web [2] que no permiten este tipo de control por parte del profesor, ya que queda a iniciativa del alumno la consulta de los datos. En este sentido, cabe resaltar también la contribución motivadora de una sabia gestión de la transmisión de información por parte del profesor. El correo electrónico ha sido utilizado como herramienta de comunicación en casos anteriores [3]. Todos los alumnos de la Universidad Europea de Madrid tienen acceso a una cuenta que les proporciona la propia universidad. Por el

momento se plantea el objetivo de hacer llegar a los alumnos determinada información objetiva sobre sus progresos en la asignatura. Se ha decidido desarrollar una aplicación que trabaja con los datos almacenados sobre los alumnos en una hoja Excel, y que es capaz de enviarlos por correo electrónico de forma automática y personalizada.

3. La asignatura

La asignatura “Estructuras de Datos y de la Información” (en adelante EDI) es una materia troncal, de segundo curso, impartida en las titulaciones del área de informática de la Escuela Superior Politécnica de la Universidad Europea de Madrid. Originalmente tiene asignados 12 créditos en el Boletín Oficial del Estado, de los cuales 9 son teóricos y 3 son prácticos. En la dinámica de la materia se distinguen claramente dos componentes: una teórica y otra práctica. La primera de ellas se desarrolla básicamente siguiendo una metodología de clase magistral, que se ve complementada con la realización de ejercicios para practicar y afianzar los conceptos explicados. Normalmente estos ejercicios se plantean al concluir cada tema. Para su realización se han implantado técnicas de aprendizaje cooperativo: los alumnos se organizan en grupos para la realización, corrección y calificación de los problemas. La asistencia se considera requisito indispensable para la evaluación continua, por lo que se aplica un coeficiente corrector sobre la nota del alumno dependiente de su porcentaje de faltas injustificadas. El apartado práctico se basa en la realización del curso “Estructuras de Datos y Algoritmos” de iCarnegie. Este curso, que consiste en la realización de cuestionarios y prácticas de programación en C++ (sobre una base teórica, que, en este caso, encaja perfectamente con el temario de EDI), es uno de de los diez ofertados por esta institución asociada a la Carnegie Mellon University. Los cursos ofertados por iCarnegie utilizan técnicas de formación a distancia a través de Internet.


Figura 1. Ejemplo de hoja Excel.

4. Herramienta

4.1. Funcionamiento

EIPMail utiliza como fuente de datos ficheros Excel donde se encuentra tabulada la información referente a la evaluación de los alumnos (Figura 1). Para su correcto funcionamiento, los ficheros Excel deberán estar registrados como origen de datos ODBC. Las funciones principales de la herramienta son las siguientes:

• Elegir el libro Excel que sirve como origen de

datos. • Consultar la información que se envía a los

alumnos mediante correo electrónico. • Ver la lista de direcciones obtenida tras la

consulta y seleccionar los destinatarios de los mensajes.

• Acceder a una vista previa del mensaje que le llegará al alumno.

• Enviar los mensajes de correo. También existen opciones de configuración tales como: • Almacenar configuraciones de consulta

personalizadas, para su posterior reutilización.

La información guardada incluye el nombre del fichero fuente, la hoja Excel que contiene los datos, y los campos seleccionados.

• Configurar los datos del correo electrónico del profesor.

Como única restricción para los archivos Excel, las hojas deberán contener los nombres de las columnas en la primera fila, y los datos a partir de la segunda. Una de las prioridades en el diseño y desarrollo de EIPMail ha sido conseguir una cierta facilidad de uso. Se ha intentado que todas las funcionalidades antes mencionadas se encuentren integradas y fácilmente accesibles desde la interfaz principal (Figura 2). El flujo normal de utilización de la herramienta consta de los siguientes pasos: • Crear una nueva configuración de consulta. • Elegir la hoja Excel que sirve como origen de

datos. • Una vez que la herramienta muestra los

nombres de las columnas disponibles, seleccionar aquéllas que quiere incluir en el correo electrónico.

• Enviar los mensajes de correo. Antes de realizar el envío, el usuario puede visualizar y modificar la lista de direcciones, así como acceder a una vista previa del mensaje generado.


El correo electrónico generado tiene un formato tabulado (Figura 3), facilitándose así la

comprensión de la información por parte del receptor

Figura 2. Captura de la pantalla principal de EIPMail.

4.2. Resultados

La herramienta ha comenzado a utilizarse en el año académico 2004/2005, con tres de los siete grupos de la asignatura. Aunque el curso aún no ha finalizado, se pueden realizar valoraciones sobre su acogida entre el alumnado. En general, los alumnos de los grupos de prueba muestran su satisfacción ante este sistema de envío de información personalizada. No sólo declaran conocer mejor su situación durante el curso, sino que además, en su opinión, tanto el funcionamiento como la finalidad del sistema de evaluación se entienden más claramente cuando existe una retroalimentación adecuada. Un elevado número de alumnos ha solicitado un aumento en la frecuencia de envío de la información. Esta petición puede ser abordada con facilidad utilizando EIPMail, quedando a servicio únicamente del criterio del profesor atender la demanda. Todo esto, además, sirve como estímulo

para que el alumno no abandone la asignatura en evaluación continua. Aunque los resultados no son concluyentes dada la altura del curso, se ha observado cómo el nivel de participación en evaluación continua para el presente año académico ha aumentado en comparación con el curso 2003/2004.

5. Conclusiones y trabajos futuros

EIPMail se ha revelado como un apoyo positivo a la docencia en evaluación continua. Se ha podido llevar a cabo una tarea que, sin la herramienta, hubiese supuesto una carga de trabajo prácticamente inabordable para los profesores. Los alumnos, por su parte, se muestran satisfechos con la información recibida y proponen mejoras y nuevas posibilidades. Por supuesto, la frecuencia con la que se envía la retroalimentación queda a elección del usuario de la herramienta.


Se pretende que la versión actual no sea más que el germen de todo un sistema de herramientas de apoyo a la evaluación en torno a los datos almacenados en libros Excel (o cualquier otro origen de datos de uso común). Entre los

principales proyectos de futuro se encuentra la construcción de herramientas de apoyo no sólo a la consulta, sino también a la modificación de datos en evaluación continua (por ejemplo,

Figura 3. Ejemplo de mensaje de correo recibido.

gestión de faltas de asistencia), el posible envío de información de apoyo al seguimiento de la evaluación (comentarios, valoraciones, etc…) así como de aplicaciones que faciliten la comunicación en el sentido opuesto a EIPMail, es decir, que posibiliten el envío de información por parte de los alumnos al profesor.

Referencias

[1] Cernuda del Río, Agustín. Retroalimentación a los alumnos tras los exámenes finales: Un caso práctico. X Jornadas de Enseñanza Universitaria de la Informática, 2004. Alicante.

[2] Dougiamas, M. Moodle: A Free Open Source Course Management System for Online Learning. www.moodle.org.

[3] Huang, A. Innovative Use of Email for Teaching. Communications of the ACM. Noviembre de 2001, Vol. 44, Nº 11. Págs. 29 a 32.

[4] Sorbonne Joint Declaration. Joint declaration on harmonisation of the architecture of the European higher education system, by the four Ministers in charge for France, Germany, Italy and United Kingdom. Paris, the Sorbonne, May 25, 1998.

[5] The Bologna Declaration of 19 June 1999. Joint declaration of the European Ministers of Education.

jsYASP: Un simulador de un procesador educativo en Javascript

Lluís Ribas Xirgo, David Rodríguez Jurado Departamento de Microelectrónica y Sistemas Electrónicos

Escuela Técnica Superior de Ingeniería (ETSE) – Universitat Autònoma de Barcelona (UAB) 08193 Bellaterra

e-mail: [email protected]

Resumen Los procesadores sencillos se emplean en la docencia de los fundamentos de los computadores para mostrar su funcionamiento. En este trabajo se presenta un simulador de una de estas máquinas elementales. Se ha realizado en Javascript para poder ser ejecutado desde cualquier plataforma sin necesidad de instalación. Como resultado adicional, la interfaz gráfica resulta muy simple y amigable y, además, el simulador es de código abierto. Con todo, el uso del simulador facilita un modelo docente complementario al presencial que resulta conveniente para el marco que se establece en el nuevo espacio europeo de educación superior.

1. Introducción

En las asignaturas que tratan de los fundamentos de los computadores se enseña cómo funciona un ordenador a partir de su arquitectura básica. Así pues, un computador es una máquina que toma datos del exterior, los procesa de acuerdo a un programa y obtiene unos resultados. En este modelo, el procesador dispone de una memoria en el que se almacenan datos e instrucciones (la llamada arquitectura de Von Neumann) y una unidad de procesado que las ejecuta con los datos correspondientes.

El procesador es pues, el elemento clave de los ordenadores y el que merece una atención especial en los programas docentes de las asignaturas de los temas correspondientes.

Dado que el empleo de procesadores reales (como los i808x) causa una cierta dispersión del aprendizaje, es recomendable emplear otros de más simples que mantengan las características básicas de la arquitectura de los mismos. Más aun, si se tiene en cuenta que, en la asignatura de Fundamentos de Computadores de la titulación de Informática de la UAB, el tiempo para la parte de rudimentos de arquitectura es de 4,5 créditos.

Con todo, la utilización de un simulador de una máquina elemental didáctica permite consolidar los conocimientos logrados en las clases teóricas, referentes a la estructura y funcionamiento de un computador. Estos simuladores deben de tener un manejo simple para evitar que los estudiantes pasen más tiempo entendiendo su uso que aprendiendo el funcionamiento de los procesadores que simulan. Más aun, atendiendo al hecho de que la implantación del espacio europeo de educación superior supondrá la revisión de los planes de estudio y de la metodología de la enseñanza, resulta conveniente disponer de herramientas que permitan centrar la programación docente en el aprendizaje del alumno.

El objetivo de este trabajo consiste en desarrollar un simulador de una máquina elemental que pueda ejecutarse en cualquier plataforma y cuyo uso sea muy simple.

El procesador es el mismo que ya se utiliza en la asignatura de Fundamentos de Computadores desde el año 2000 [3] y la interfaz gráfica se inspira en el simulador existente.

La independencia de plataforma supone, en la práctica, que los estudiantes puedan desarrollar el trabajo práctico fuera del laboratorio. Esto supone una mayor flexibilidad tanto para ellos como para los profesores. La simplicidad del uso permite que el alumno se centre en el procesador. Dado que éste último debe enfatizar los aspectos clave de la arquitectura de los computadores, este mismo hecho implica un aumento de la eficiencia educativa de la herramienta.

Este artículo se organiza como sigue. En el apartado siguiente se describen brevemente algunos procesadores educativos y, en especial, el empleado en nuestra universidad. A continuación se presenta el simulador y, finalmente, se destacan los puntos más importantes conseguidos con este trabajo en el apartado de conclusiones.

538 Recursos docentes 2. Procesadores didácticos

Todos los procesadores de orientación didáctica se basan en la arquitectura de Von Neumann, pues es la empleada en la mayoría de los procesadores actuales.

En esta arquitectura, el procesador ejecuta un programa que se almacena en su memoria principal. El modo de ejecución de este programa es totalmente secuencial: la unidad central de procesamiento (UCP) lee una instrucción de la memoria, la ejecuta y calcula qué instrucción deberá ejecutar a continuación. Este ciclo de ejecución de las instrucciones del programa almacenado en la memoria se repite indefinidamente.

Los distintos procesadores didácticos que existen lo desarrollan de maneras ligeramente diferentes.

Una de las más simples es Blue [1], que tiene un repertorio de sólo 16 instrucciones y únicamente dispone de direccionamiento directo para acceder a los datos de las instrucciones. Este procesador tiene una UCP con un camino de datos con los registros imprescindibles para la comunicación con la memoria (MAR y MBR) y el seguimiento del ciclo de ejecución de instrucciones (PC e IR), así como tres registros para datos (A, Y y Z). La memoria es de 4K-palabras de 16 bits. La comunicación con el exterior sólo puede hacerse mediante mapeo en memoria de los dispositivos correspondientes.

En cambio, la máquina rudimentaria [4] es un procesador que dispone de una memoria de 256 palabras de 16 bits, con un camino de datos que cuenta con un banco de 8 registros. Las

instrucciones pueden acceder a sus operandos mediante cuatro tipos de direccionamiento en memoria distintos: inmediato, directo, indexado y por registro. La comunicación con el exterior se supone que se produce mediante mapeo de los dispositivos periféricos en memoria.

Por otra parte, CODE-2 (o computador didáctico elemental [2]) dispone de una UCP más completa, con un camino de datos que incluye un banco de 16 registros y una unidad aritmético-lógica (ALU) con las operaciones básicas. Dado que toda la máquina es de 16 bits, la memoria tiene un tamaño de 64Kb. Dispone de dos instrucciones para acceder a los datos en memoria mediante direccionamiento directo o indexado. Así pues, se trata de un procesador que se inspira en los de arquitectura RISC. Por otra parte, dispone de instrucciones de llamada de funciones. La comunicación con el exterior se realiza mediante puertos de entrada/salida.

El procesador que se emplea en la asignatura de Fundamentos de Computadores de nuestra universidad es una versión algo más compleja que Blue, pero mucho menos que CODE-2. En el apartado siguiente se describe con un poco más de detalle.

2.1. El procesador didáctico YASP

YASP es el acrónimo de yet another simple processor y fue desarrollado en el Departamento de Informática de la UAB [3] para ilustrar el funcionamiento de un computador con arquitectura de Von Neumann. Su camino de datos incluye sólo los registros necesarios para efectuar la comunicación con la memoria, el

MB

MAR

A

PC

X

CommUnit

Communication Unit

IR

CU

Control Unit

ALU

Arithmetic-Logic Unit

Memory

(256x8)

Z

C

BusR BusM

BusW

8

ALUmicroinst5

Figura 1. Esquema de la máquina elemental YASP


seguimiento del ciclo de ejecución de instrucciones y la realización de las operaciones indicadas con un registro de propósito general, el acumulador. (Hay otro registro auxiliar que puede emplearse para datos.) La memoria es de 256 bytes, puesto que todos los registros son de 8 bits.

Su repertorio de instrucciones incluye las más comunes y dispone de 4 modos de direccionamiento: inmediato, directo, indexado e indirecto. Este último se incluye sólo para ilustrar su funcionamiento, aunque lo más común en procesadores simples sería una forma indirecta mediante registro. (En YASP no tiene sentido hacerlo así, pues sólo dispone de dos registros para datos.)

La comunicación con los periféricos de entrada y/o salida se realiza mediante puertos y líneas de petición y aceptación. Con ello, YASP se puede ver perfectamente como un procesador completo que puede aceptar datos del exterior y también proporcionarle resultados.

Las líneas de petición y de aceptación permiten ilustrar el funcionamiento de los protocolos asíncronos de comunicación. YASP no acepta interrupciones porque implicaría el uso de llamadas a subrutinas, que tampoco implementa. De todas maneras, las interrupciones pueden emularse mediante las líneas de aceptación.

La no inclusión de instrucciones de llamada/retorno de función se debe a que resulta habitual que los alumnos aun no hayan adquirido el conocimiento de estructuras de datos como la pila, necesarias para su implementación. Además, aumentaría mucho la complejidad de YASP.

3. Simuladores de procesadores docentes

Tal como se ha comentado en la introducción, estos simuladores deben de tener una interfaz de aspecto agradable y fácil de usar, y han de poder ejecutarse sin mayor problema en distintas plataformas.

Todos los procesadores que se han descrito en el apartado anterior disponen de simuladores que se ejecutan en plataformas de PC con alguna de las versiones del sistema operativo Microsoft Windows. Aunque no hay que olvidar que existen diferencias entre versiones de Windows que pueden dificultar la ejecución de algún simulador preparado para otra distinta de la que se emplea para su ejecución. A pesar de ser éstas las

plataformas de ejecución más comunes, también hay otras que se emplean cada vez más. En especial las derivadas de la iniciativa del software libre o de código abierto y, claro, del Linux como su sistema operativo.

Así pues, se plantea la necesidad de desarrollar un simulador para un procesador didáctico que pueda ejecutarse en varias plataformas. Con ello se simplifica enormemente la gestión de las versiones del propio simulador y su instalación. Además, se consigue una independencia de la plataforma existente en los laboratorios que permite tanto su actualización como que los alumnos realicen su trabajo en otros lugares y pudiendo organizar su tiempo de forma más adecuada a sus necesidades.

3.1. Simulador en Javascript de YASP

Con el requerimiento anterior, se pensó en emplear Javascript para desarrollar un simulador de la máquina elemental YASP que fuera multiplataforma y de código abierto.

De hecho, con disponer de un navegador de web compatible en cualquier plataforma, se podrá ejecutar el simulador. Así pues, dado que es el navegador el que ejecuta el simulador, éste se convierte en una aplicación multiplataforma de manera directa. Por otra parte, no es necesaria su instalación, si bien es cierto que también puede ejecutarse desde el mismo ordenador para no depender de la conexión a la red.

El código Javascript se incluye en la página que se descarga para ejecutar el simulador, por lo tanto, es de código abierto y puede ser modificado libremente por quién lo desee. Es posible añadir nuevas opciones al simulador, como también realizar cambios en el procesador.

Se descartaron otras tecnologías de desarrollo de programas con tecnología de la web como applets en Java o aplicaciones en Flash de Macromedia porque requieren de la instalación de la máquina virtual de Java o del plug-in de Flash, respectivamente.

Aun así, Javascript tampoco es totalmente independiente de plataforma, pues los distintos navegadores que existen en el mercado no lo implementan de igual forma. En algunos casos hay instrucciones que solo son válidas para un determinado navegador o métodos que funcionan de diferente forma. Para conseguir un correcto

540 Recursos docentes funcionamiento de jsYASP en la mayoría de navegadores posibles, se optó por utilizar los objetos y métodos que tienen una implementación común. Esto hizo que en alguna ocasión hubiese que renunciar a la eficiencia en detrimento de la compatibilidad.

La interfaz del simulador de la máquina elemental YASP, jsYASP, (véase la figura 2) se ha realizado con HTML, utilizando básicamente tablas y elementos de formulario, para conseguir la mayor homogeneidad posible en la visualización de YASP en los diferentes navegadores. Es muy simple e intuitiva. Todas sus funciones se engloban en una única superficie de trabajo organizada en subventanas: una para el código en ensamblador y otras para el procesador.

jsYASP se ha probado con Internet Explorer 5.0, Mozilla 1.7.3, Mozilla Firebird 1.0, Netscape 6.0 y otras versiones superiores de los navegadores ya citados.

4. Conclusión

Se ha presentado jsYASP, un simulador de un procesador educativo realizado con Javascript que es multiplataforma, de código abierto y con una interfaz amigable: Para ejecutar jsYASP sólo es necesario un navegador compatible. (Está

disponible en microelec.uab.es/ribas/edu/fc/yasp.) Está previsto su uso en el curso 2004/2005 en

sustitución del simulador compatible con Windows preexistente.

En un futuro se realizará una versión para que varios simuladores intercambien datos a través de los puertos de los procesadores.

Referencias

[1] Foster, C. Computer Architecture. NY: Van Nostrand Reinhold, 1976. [web.frm.utn.edu.ar/tecnicad2/tec_dig2/tools/te2blue.html]

[2] Prieto, A.; Pelayo, F.J.; Gómez-Mula, F.; Ortega, J.; Cañas, A.; Martínez, A.; Fernández, F.J. Un computador didáctico elemental (CODE-2). Actas de las VIII Jornadas de Enseñanza Universitaria de la Informática (JENUI'2002), pp. 117-124, Cáceres, 10-12 Julio 2002. [atc.ugr.es/intro_info_mcgraw/alumno/code2.htm]

[3] Ribas, Ll. Pràctiques de fonaments de computadors. Bellaterra: Serv. Pub. UAB, 2000.

[4] –. Estructura básica de un computador. Barcelona: UOC, 2002.

Figura 2. Ventana de ejecución

Date post:	13-Oct-2018
Category:	Documents
Upload:	nguyenthuan
View:	217 times
Download:	1 times

Recursos docentes - UIBbioinfo.uib.es/~joemiro/aenui/procJenui/Jen2005/Ponencias13.pdf · SimuProc...

Documents