Revista Iberoamericana de Tecnologías del/da Aprendizaje/Aprendizagem (Latin-American Learning Technologies Journal)

Una publicación de la Sociedad de la Educación del IEEE Uma publicação da Sociedade de Educação do IEEE A publication of the IEEE Education Society NOV. 2006 VOL. 1 NÚMERO/NUMBER 1 (ISSN 1932-8540)

Welcome IEEE-RITA…..……………………………………………….....................David A. Conner iBienvenida IEEE-RITA………………………………………………...……….........David A. Conner ii Bem-vinda, IEEE-RITA...……………………………………………...……….........David A. Conner iiiIEEE-RITA, una iniciativa modélica…………………………………………………..…….. E. Tovar iv IEEE-RITA, uma iniciativa exemplar..................................................…………………..….. E. Tovar vEditorial (en español)………………………………………..………………...M. Llamas y M. Castro vi Editorial (en português)……….………………………………………...……..M. Llamas y M. Castro viii ARTÍCULOS/ARTIGOS/PAPERS Integración internacional de plataformas de enseñanza a distancia de automatización con PLCs……...……………………Lluís Molas, Coia Ferrater, Oriol Gomis, Antoni Sudrià, Oriol Boix,

Israel Benítez, Ruben Sicchar, Marivan Gomes, Félix Roldán, Ksenia Arias y Luisa Villafruela 1 Desarrollo de un sistema ARS para enseñanza on-line………………………………………………… ……………………………………………………....Mario Muñoz Organero y Carlos Delgado Kloos 11 Construcción modular de robots móviles. Proyecto basado en portafolio para estudiantes de grado……………………………………………………Cecilio Angulo, Pere Ponsa y Cristóbal Raya 19

Especificación Metodológica de la Implementación y Desarrollo de Entornos de Experimentación…... …………..Rafael Pastor, Roberto Hernández, Salvador Ros y Manuel Castro 27

IEEE-RITA (http://webs.uvigo.es/cesei/RITA)

DOI (Digital Object Identifier) Pendiente

CONSEJO/CONSELHO EDITORIAL

Presidente (Editor Jefe): Martín Llamas Nistal, Universidad

de Vigo, España Vicepresidente:

Manuel Castro Gil, UNED, España

Miembros: Melany M. Ciampi, COPEC, Brasil Javier Quezada Andrade, ITESM,

México

Secretaría: Pedro Pimenta, Universidade do

Minho, Portugal Francisco Mur, UNED, España

COMITÉ CIENTÍFICO

Alfredo Fernández

Valmayor, Universidad Complutense de Madrid,

España Antonio J. López Martín,

Universidad Estatal de Nuevo Méjico, USA Antonio J. Méndez,

Universidad de Coimbra, Portugal

Arturo Molina, ITESM, México

Baltasar Fernández, Universidad Complutense

de Madrid, España Carlos Delgado,

Universidad Carlos III de Madrid, España

Carlos Vaz do Carvalho, INESP, Portugal

Claudio da Rocha Brito, COPEC, Brasil

Daniel Burgos, Universidad Abierta de Holanda,

Holanda

Edmundo Tovar, UPM, España

Fernando Pescador, UPM, España

Francisco Arcega, Universidad de Zaragoza,

España Francisco Azcondo,

Universidad de Cantabria, España

Francisco Jurado, Universidad de Jaen,

España Gustavo Rossi, Universidad

Nacional de la Plata, Argentina

Héctor Morelos, ITESM, México

Hugo E. Hernández Figueroa, Universidad de

Campinas, Brasil Inmaculada Plaza,

Universidad de Zaragoza, España

Jaime Sánchez, Universidad de Chile, Chile

Javier Pulido, ITESM, México

José Bravo, Universidad de Castilla La Mancha, España José Carpio, UNED, España

José Palazzo M. De Oliveira, UFGRS, Brasil

Juan Quemada, UPM, España

Luis Anido, Universidad de Vigo, España

Manuel Fernández Iglesias, Universidad de Vigo,

España Manuel Ortega,

Universidad de Castilla La Mancha, España

M.Felisa Verdejo, UNED, España

Maria José Patrício Marcelino, Universidad de

Coimbra, Portugal

Mateo Aboy, Instituto de Tecnología de Oregón,

USA Miguel Angel Sicilia Urbán,

Universidad de Alcalá, España

Miguel Rodríguez Artacho, UNED, España

Paloma Díaz, Universidad Carlos III de Madrid,

España Paulo Días, Universidade

do Minho, Portugal Rosa M. Vicari, UFGRS,

Brasil Víctor H. Casanova,

Universidad de Brasilia, Brasil

Vitor Duarte Teodoro, Universidade Nova de

Lisboa, Portugal Yannis Dimitriadis,

Universidad de Valladolid, España

Revisores

Addison Salazar

Afanador, Universidad Politécnica de

Valencia, España André Luís Alice

Raabe, Universidade do Vale do Itajaí,

Brasil Angel García Beltrán,

Universidad Politécnica de Madrid,

España Angel Mora Bonilla,

Universidad de Málaga, España

Angélica de Antonio Jiménez, Universidad Politécnica de Madrid,

España Basil M. Al-Hadithi, Universidad Alfonso X El Sabio, España

Cecilio Angulo Bahón, Universidad

Politécnica de Catalunya , España

César Alberto Collazos Ordóñez, Universidad del Cauca, Colombia

Crescencio Bravo Santos, Universidad de

Castilla-La Mancha, España

David Benito Pertusa, Universidad Publica de

Navarra, España Faraón Llorens Largo,

Universidad de Alicante, España

Gloria Zaballa Pérez, Universidad de Deusto,

España Gracia Ester Martín Garzón, Universidad de Almeria, España

Ismar Frango Silveira, Universidad de

Cruzeiro do Sul, Brasil Javier Areitio Bertolin, Universidad de Deusto,

España Joaquín Roca Dorda,

Universidad Politécnica de

Cartagena, España Jorge Alberto Fonseca

e Trindade, Escola Superior de

Tecnología y Gestión, Portugal

José Angel Martí Arias, Universidad de la

Habana, Cuba

José Javier López Monfort, Universidad

Politécnica de Valencia, España José Luis Guzmán

Sánchez, Universidad de Almeria, España José Luis Sánchez

Romero, Universidad de Alicante, España

Juan Carlos Soto Merino, Universidad

del Pais Vasco, España Juan Meléndez,

Universidad Pública de Navarra, España

Juan Suardíaz Muro, Universidad

Politécnica de Cartagena, España

Juan Vicente Capella Hernández, Universidad

Politécnica de Valencia, España Luis de la Fuente

Valentín, Universidad Carlos III, España

Luis Fernando Mantilla Peñalba, Universidad de

Cantabria, España

Luis Gómez Déniz, Universidad de Las

Palmas de Gran Canaria, España

Luis Zorzano Martínez, Universidad de La

Rioja, España Manuel Benito Gómez,

Universidad del Pais Vasco, España Manuel Caeiro

Rodríguez, Universidad de Vigo,

España Manuel Gromaz

Campos, Centro de Supercomputación de

Galicia, España Manuel Pérez Cota,

Universidad de Vigo, España

Maria Antonia Martínez Carreras,

Universidad de Murcia, España

Mario Muñoz Organero, Universidad de Carlos III, España

Marta Costa Rosatelli, Universidad Católica

de Santos , Brasil

Mercedes Caridad Sebastián, Universidad

Carlos III, España Miguel Angel Gómez

Laso, Universidad Pública de Navarra,

España Miguel Ángel

Redondo Duque, Universidad de

Castilla-La Mancha, España

Miguel Angel Salido, Universidad

Politécnica deValencia, España

Raúl Antonio Aguilar Vera, Universidad

Autónoma del Yucatán, México

Robert Piqué López, Universidad

Politécnica de Catalunya, España

Victoria Abreu Sernández,

Universidad de Vigo, España

Xabiel García Pañeda, Universidad de Oviedo,

España

Equipo Técnico: Ana Losada Pérez, Universidad de Vigo, España

IEEE-RITA, Vol 1, Num. 1, Nov. 2006 i

Welcome IEEE-RITA

David A. Conner, Fellow, IEEE I have the pleasure, as Editor-in-Chief, of the IEEE Transactions on Education to welcome IEEE-RITA to the IEEE Education Society publication fold. For the past two years, the IEEE Education Society has been exploring ways in which it could provide additional benefit to its members through its publications. In addition to the IEEE Transactions on Education (the Society’s archival education research journal), The Interface (the Society’s newsletter edited by William Sayle), and EdSoc News (an electronic newsletter edited by Rob Reilly), the Society AdCom (Administrative Committee) has been considering additional publication options. And, … IEEE-RITA, which was suggested by Manuel Castro Gil, became a natural choice given the large, combined Society membership having Spanish and Portuguese as a first language. The AdCom embraced the idea of an electronic publication targeted for this audience and authorized a pilot project to test the acceptance of such a publication by the Spanish and Portuguese community. You, as a reader, will play a large part in determining the future of IEEE-RITA. Since the publication will be electronic via a Web site, the Society will be able to keep track of the number of times the publication is accessed. If you tell your colleagues about this publication and if they access the publication on a regular basis, we will have vital data to demonstrate to IEEE that the IEEE-RITA is a publication that should become a permanent part of the IEEE publication arena. And, if you and your colleagues submit quality manuscripts for publication consideration, IEEE-RITA will have the ability to demonstrate long-term viability as a publication.

Over the next few years, as data is collected relative to the number of manuscripts submitted to RITA and the number of readers that access IEEE-RITA, the IEEE Education Society will begin to prepare its formal request to the IEEE Technical Activities Board and to the IEEE Publications, Services and Products Board for approval of RITA as a permanent, IEEE electronic publication. But remember, you, the reader, will be the determining factor relative to the future of IEEE-RITA. In closing, I am please to announce that, as the Education Society’s archival research journal, the IEEE Transactions on Education stands ready to consider for publication (in English) any published IEEE-RITA paper that contains the content expected in a Transactions’ paper. Interested authors can access manuscript preparation information at http://www.ewh.ieee.org/soc/es/ToE-manuscript.html David A. Conner, Ph.D., P.E., received the Bachelor of Electrical Engineering and Master of Science (in Electrical Engineering) degrees from Auburn University and the Doctor of Philosophy degree from the Georgia Institute of Technology. He has 45 years of engineering experience in academia, industry, and government. Dr. Conner served on the IEEE Board of Directors for four years, served as IEEE Treasurer of IEEE for two years, and has received numerous IEEE awards.

ISSN 1932-8540 © IEEE

IEEE-RITA Vol. 1, Num. 1, Nov. 2006 ii

Bienvenida IEEE-RITA

David A. Conner, Fellow, IEEE (Traducido por M. Llamas)

Tengo el placer, como editor en jefe de las IEEE Transactions on Education de dar la bienvenida a IEEE-RITA a la familia de publicaciones de la Sociedad de la Educación del IEEE. En los dos últimos años, la Sociedad de la Educación del IEEE (IEEE-ES) ha estado explorando nuevas vías para proporcionar beneficios adicionales a sus miembros a través de sus publicaciones. Además de las IEEE Transactions on Education (la revista de investigación en educación por excelencia de la IEEE-ES), The Interfaz (el boletín de la Sociedad editado por William Sayle), EdSoc News (un boletín electrónico editado por Rob Reilly), el Society AdCom (el comité administrativo) ha estado considerando opciones adicionales de publicación. Y … IEEE-RITA, sugerida por Manuel Castro Gil, se convirtió en la elección natural, dado el gran número de miembros del IEEE que tienen al español o al portugués como primera lengua. El AdCom abrazó la idea de una publicación electrónica dirigida a esta audiencia, y autorizó un proyecto piloto para probar la aceptación de este tipo de publicación por la comunidad de lengua española y portuguesa. Como lector, usted tendrá un papel importante en el futuro de IEEE-RITA. Puesto que la publicación será electrónica accedida via web, la Sociedad podrá tener constancia de las veces que la publicación es accedida. Si todos divulgamos esta publicación a nuestros colegas, y si ellos acceden a la publicación de una forma regular, tendremos entonces datos suficientes para demostrar al IEEE que la revista IEEE-RITA debe formar parte permanente del elenco de publicaciones del

IEEE. Y si el lectos y sus colegas envian manuscritos de calidad para su publicación, IEEE-RITA podrá demostrar su viabilidad como publicación a largo plazo. En los próximos años, a medida que se vayan teniendo datos sobre el número de manuscritos enviados a IEEE-RITA y el número de lectores que acceden a la revista, la Sociedad de la Educación del IEEE empezará a preparar su petición formal al Consejo del IEEE de Actividades Técnicas y al Consejo del IEEE de Productos, Servicios y Publicaciones para la aprobación de IEEE-RITA como una publicación electrónica permanente del IEEE. Pero el lector debe recordar que solamente él, como lector, es el factor determinante para el futuro de IEEE-RITA. Para terminar, tengo el placer de anunciar que el IEEE Transactions on Education, como revista de investigación en educación por excelencia de la IEEE-ES, está lista para considerar para su publicación (en inglés) cualquier artículo de IEEE-RITA que cumpla los patrones clásicos de un artículo del Transactions. Los autores interesados pueden acceder a la información de envio de manuscritos en http://www.ewh.ieee.org/soc./es/ToE-manuscrit.html David A. Conner, Ph.D., P.E., recibió el grado de Bachelor en Ingeniería Eléctrica y Master of Science (en Ingeniería Eléctrica) en la Universidad Auburn y el grado de Ph. Doctor en el Instituto de Tecnología de Georgia. Tiene 45 años de experiencia en ingeniería en la Universidad, en la Industria y en el Gobierno. Dr. Conner fue miembro de la Junta de Directores del IEEE durante cuatro años, Tesorero de la Junta del IEEE durante dos años, y ha recibido numerosos premios del IEEE.

ISSN 1932-8540 © IEEE

IEEE-RITA Vol. 1, Num. 1, Nov. 2006 iii

Bem-vinda, IEEE-RITA

David A. Conner, Fellow, IEEE (Traduzido por P. Pimenta)

Tenho o prazer, como Editor da IEEE Transactions on Education, de dar as boas-vindas a IEEE-RITA ao portofolio de edições da IEEE Education Society. Nos dois últimos anos, a IEEE Education Society tem vindo a reflectir como poderá dar benefícios adicionais aos seus membros através das suas publicações. Além de IEEE Transactions on Education (periódico do IEEE sobre investigação em educação), The Interface (a newsletter da IEEE editada por William Sayle), e EdSoc News (newsletter electrónica editada por Rob Reilly), o Comité Administrativo da IEEE (AdCom) tem vindo a considerar outras opções de publicações adicionais. E… IEEE-RITA, sugerida por Manuel Castro Gil, tornou-se uma escolha natural, dado o grande número de membros da IEEE que têm o Castelhano ou o Português como primeira língua. O AdCom acolheu com entusiasmo a ideia de uma publicação electrónica dirigida a esta audiência, e autorizou um projecto piloto para testar a aceitação de uma publicação deste género pelas comunidades de língua Castelhana e Portuguesa. Como leitor, terá um papel importante no futuro de IEEE-RITA. Sendo uma publicação electrónica acedida via web, a Sociedade terá como manter registos de quantas vezes a publicação é acedida. Se divulgar este periódico junto dos seus colegas, e estes acederem e utilizarem regularmente o site, teremos dados para demonstrar ao IEEE que IEEE-RITA é um periódico que deve tornar-se parte integrante do portofolio IEEE. E se o leitor e os seus colegas submeterem artigos de qualidade, IEEE-RITA poderá demonstrar a sua viabilidade a longo prazo.

Nos próximos anos, através dos números de artigos submetidos e do número de utilizadores de IEEE-RITA, a IEEE Education Society preparará o seu pedido formal ao IEEE Technical Activities Board e ao IEEE Publications, Services and Products Board para que IEEE-RITA seja aprovada como uma publicação electrónica permanente. Para terminar, tenho o prazer de anunciar que o IEEE Transactions on Education considera a publicação (em inglês) de qualquer artigo publicado em IEEE-RITA e que cumpra as padrões de um artigo de Transactions’. Os Autores interessados podem aceder às instruções de submissão em http://www.ewh.ieee.org/soc/es/ToE-manuscript.html David A. Conner, Ph. D., P.E., obteve os graus de Bachelor of Electrical Engineering e de Master of Science (em Electrical Engineering) na Auburn University, e o grau de PH. D., no Georgia Institute of Technology. Tem 45 anos de experiência na Universidade, na indústria e gestão. Dr. Conner foi membro do IEEE Board of Directors durante quatro anos e IEEE Treasurer durante dois anos, tendo recebido numerosas distinções IEEE.

ISSN 1932-8540 © IEEE

IEEE-RITA Vol.1, Num. 1, Nov. 2006 iv

IEEE-RITA, una iniciativa modélica

Edmundo Tovar, Senior member, IEEE

El Capítulo Español de la Sociedad de Educación de IEEE (CESEI) nace hace más de dos años bajo el liderazgo de Manuel Castro Gil con una clara vocación de servicio tanto a sus miembros como al profesorado de enseñanza técnicas en España y a la sociedad en general. La clave del éxito que perseguimos en esta aventura pienso que radica en lograr aunar el potencial y prestigio que la Sociedad de Educación de IEEE (IEEE ES) atesora con las necesidades tanto generales como específicas del profesorado español. Desde este punto de vista, los miembros del Capítulo tienen la posibilidad de participación desde una doble vertiente: disfrutar de servicios ofrecidos desde IEEE ES así como contribuir con iniciativas desarrolladas en estas mismas líneas de interés que beneficien a la sociedad. En este último caso, el Capítulo tiene la misión de “facilitador”, como plataforma de apoyo en la realización de dichas iniciativas. La experiencia de IEEE-RITA es modélica para el Capítulo en ambos sentidos, pues cubre una necesidad de educadores en el ámbito iberoamericano y ha canalizado adecuadamente el soporte que puede proporcionar IEEE ES. Pero, además, para poder sacar a la luz este primer número y contar con todas las ilusionantes expectativas que se nos abren ha sido imprescindible el esfuerzo de distintos protagonistas a los que no que no quiero dejar de mencionar, reconocer y agradecer: - En primer lugar, a su promotor, Martin

Llamas Nistal, miembro activo del Capítulo, y a su coeditor, Manuel Castro Gil, que han sabido entender los beneficios que revierten a nuestra comunidad iberoamericana la existencia de un foro de publicación electrónica de

Educación en Ingeniería con ambición de alcanzar rápidamente prestigio y relevancia.

- A los miembros del Consejo Editorial y Comité Científico de la revista, adheridos con entusiasmo en esta voluntaria actividad.

- Al Comité Administrativo de la Sociedad (AdCom de IEEE ES), que ha mostrado su receptividad y confianza en los promotores desde su primera propuesta autorizando, bajo experiencia piloto, la aparición de IEEE-RITA como revista de la Sociedad de Educación de IEEE.

No me cabe, por tanto, más que dar la bienvenida a IEEE-RITA y desearle los mejores augurios para su consolidación, e invitar al lector a su participación, también como autor de artículos de calidad. Espero que esta experiencia dé paso a otras muchas que puedan ser apoyadas por nuestro CESEI. Edmundo Tovar, Profesor de Ingeniería Informática es doctor en Informática (1994) y Licenciado en Informática (1986) por la Universidad Politécnica de Madrid(UPM). Es "Certified Software Development Professional" (CSDP) por IEEE Computer Society. Ha sido consultor en Aseguramiento de la Calidad para diversas insituciones y experto evaluador de la Agencia Nacional de Evaluación de la Calidad y Acreditación (ANECA). Ha participado como investigador en tareas de gestión de calidad de software en proyectos internacionales desde 1988, y proyectos educativos, coordinando algunos de ellos en el contexto del Espacio Europeo de Educación Superior para el Ministerio de Educación Español. Es director de la Unidad de Calidad de la Facultad de Informática, UPM. IEEE Senior Member, pertenece al Comité Administrativo de IEEE Education Society AdCom (2007-2009) y Chairman del Capítulo Español de IEEE Education Society.

ISSN 1932-8540 © IEEE

IEEE-RITA Vol. 1, Num. 1, Nov. 2006 v

IEEE-RITA, uma iniciativa exemplar

Edmundo Tovar, Senior member, IEEE (Traduzido por P. Pimenta)

O Capítulo Español de la Sociedad de Educación de IEEE (CESEI) nasceu há mais de dois anos sob a liderança de Manuel Castro Gil com uma clara vocação de serviço; tanto para os seus membros, como para os profesores de ensino técnico em Espanha, como para a sociedade em geral. A chave do êxito que perseguimos nesta aventura radica-se, a meu ver, em conseguir reunir o potencial e prestígio da IEEE Education Society (IEEE ES) com as necesidades, gerais e específicas, dos professores espanhóis. Nesta perspectiva, os membros do CESEI têm uma dupla possibilidade de participação – desfrutar dos serviços oferecidos pela IEEE ES assim como contribuir com iniciativas desenvolvidas nas mesmas linhas de interesse e que beneficiem a Sociedade. Neste último caso, o Captítulo (CESEI) tem a missão de “facilitador”, como plataforma de apoio na realização das ditas iniciativas. A experiencia de IEEE-RITA é exemplar para o CESEI em ambos os sentidos, pois cobre uma necessidade de educadores no âmbito iberoamericano e canalizou adequadamente o apoio que pôde receber da IEEE ES. Porém, além disso, para poder trazer à luz este primeiro número e apresentar todas as excepcionais expectativas que nos abre, foi imprescindível o esforço de vários protagonistas a quem não quero deixar de mencionar, reconhecer e agradecer: - Em primeiro lugar ao seu promotor,

Martin Llamas Nistal, membro activo do CESEI, e ao seu coeditor, Manuel Castro Gil, que souberam entender os benefícios, para a nossa comunidade iberoamericana, da existência de um

forum de publicação electrónica de Educação em Engenharia com ambição de alcançar rapidamente prestígio e relevância.

- Aos membros do Conselho Editorial e Comité Científico da revista, que aderiram com entusiasmo a esta actividade voluntária

- Ao IEEE Administrative Commitee (AdCom do IEEE), que mostrou a sua receptividade e confiança nos promotores desde a sua primeira proposta, autorizando, como experiencia piloto, o aparecimento de IEEE-RITA como revista da IEEE Education Society.

Nada mais me resta, portanto, que dar as boasvindas a IEEE-RITA e desejar-lhe os melhores augúrios para a sua consolidação, e convidar o leitor a participar, também, como autor de artigos de qualidade. Espero que esta experiência abra caminho a muitas outras que possam ser apoiadas pelo nosso CESEI. Edmundo Tovar, Professor de Engenharia de Computadores, tem os graus de Ph. D. (1994) e Bachelor (1986) em Computer Science atribuídos pela Universidad Politécnica de Madrid (UPM). É Certified Software Development Professional (CSDP) pela IEEE Computer Society. Foi consultor em Quality Assurance em várias instituições e perito avaliador na Spanish Agency for Quality Assessment and Accreditation (ANECA). Esteve envolvido como investigador em gestão da qualidade do software em projectos internacionais desde 1988, em projectos de educativos, no contexto do European Higher Education Area para o Spanish Education Ministry. Desempenhou as funções de Control Quality Unit Director, School of Computer Science, Universidad Politécnica de Madrid. É IEEE Senior Member, membro do IEEE Education Society AdCom (2007-2009) e Chairman do Spanish Chapter do IEEE Education Society.

ISSN 1932-8540 © IEEE

IEEE-RITA, Vol. 1, Num. 1, Nov. 2006 vi

Editorial

Martín Llamas y Manuel Castro, Senior members, IEEE

IEEE-RITA, Revista Iberoamericana de Tecnologías del Aprendizaje del IEEE, es una nueva publicación de la Sociedad de la Educación del IEEE que nace con el objetivo de servir de medio de intercambio científico de las distintas experiencias e investigaciones que se están llevando a cabo en el mundo iberoamericano (para ser más concreto, en los idiomas español y portugués en el mundo entero) dentro del campo de las Tecnologías del Aprendizaje. Esto incluye desde las aplicaciones tecnológicas a la educación, entendiendo desde su aplicación concreta a la enseñanza de disciplinas dentro de las áreas del IEEE (que suelen ser fundamentalmente las áreas de Ingeniería Eléctrica, la Tecnología Electrónica, Ingeniería de Telecomunicación e Ingeniería Informática), incluyendo experiencias y métodos pedagógicos, hasta la investigación y diseño de herramientas y materiales para la enseñanza y el aprendizaje. Creemos que en el ámbito de las Tecnologías del Aprendizaje, al igual que en muchos otros, existe un importante factor cultural en el mundo iberoamericano que hace que la compartición y comunicación de conocimiento en general se puede hacer mejor en los idiomas (español y portugués) originales. Nos proponemos también como objetivo introducir en la edición de esta revista todas aquellas aplicaciones de las nuevas tecnologías que faciliten y potencien la compartición y divulgación del conocimiento científico. En futuros números, y en la medida de nuestras posibilidades, iremos concretando este objetivo. Queremos agradecer a nuestros compañeros de la directiva del Capítulo

Español de la Sociedad de la Educación del IEEE todo el apoyo prestado para la puesta en marcha de esta revista, así como al Comité Técnico, de Acreditación y Evaluación de dicho Capítulo, y también al Consejo Editorial, al Comité Científico y a los revisores de IEEE-RITA. Especial agradecimiento a Rob Reilly y Dave Conner, quienes siempre han respondido rápida y eficazmente ante toda petición nuestra: gracias Rob y Dave. Al Ministerio Español de Educación y Ciencia, que a través de la acción complementaria TSI2005-24068-E, nos ha permitido poder lanzar esta idea de nueva revista. Y como no, a la Sociedad de la Educación del IEEE, por depositar su confianza en nosotros para esta nueva empresa. No queremos olvidarnos de todos aquellos investigadores que en el ámbito iberoamericano y a lo largo de estos años nos han animado a desarrollar foros científicos iberoamericanos. A ellos, a la comunidad iberoamericana, va dedicada esta revista, que deseamos se convierta entre todos en punto de referencia en la investigación y aplicación de las nuevas tecnologías en la enseñanza/aprendizaje de las ingenierías propias del IEEE. Martín Llamas Nistal es Ingeniero de Telecomunicación (1986) y Doctor Ingeniero de Telecomunicación (1994), ambos títulos por la Universidad Politécnica de Madrid. Desde 1987 es profesor en la ETSI de Telecomunicación de Vigo (de la que fue subdirector en el período 1994-1997); actualmente es profesor titular en el Departamento de Ingeniería Telemática de esa misma Universidad. Ha dirigido varios proyectos de investigación en el área de Telemática y es autor o co-autor de más de 100 publicaciones en revistas y congresos nacionales e internacionales. Desde Diciembre de 1998 a Septiembre de 2003 fue Director del Área de Tecnologías de la Información y las Comunicaciones

ISSN 1932-8540 © IEEE

IEEE-RITA, Vol. 1, Num. 1, Nov. 2006 vii

de la Universidad de Vigo. Miembro de ATI, de ACM y Senior Member del IEEE. Manuel Castro Gil es Doctor Ingeniero Industrial y Catedrático de Universidad. Ha sido Vicerrector de Nuevas Tecnologías de la UNED, así como Subdirector de Ordenación Académica y de Investigación en la Escuela de Ingenieros Industriales de la UNED, y Director del Centro de Servicios Informáticos de la UNED, siendo

actualmente Director de Departamento. Ha participado en numerosos proyectos de investigación como investigador, coordinador y director y ha publicado en revistas y congresos, tanto nacionales e internacionales. Ha publicado igualmente diversos libros y material multimedia dentro de sus líneas de investigación y docencia. Es Senior Member del IEEE así como miembro del Comité de Administración de la Sociedad de Educación del IEEE.

ISSN 1932-8540 © IEEE

IEEE-RITA, Vol. 1, Num. 1, Nov. 2006 viii

Editorial

Martín Llamas e Manuel Castro, Senior members, IEEE (Traduzido por P. Pimenta)

IEEE-RITA, Revista Iberoamericana de Tecnologías de Aprendizagem do IEEE, é uma nova publicação da Sociedade de Educação do IEEE que nasce com o propósito de servir de meio de intercambio científico das diversas experiencias e investigações em curso no mundo iberoamericano (mais concretamente, nas línguas espanhola e portuguesa, no mundo inteiro), no domínio das tecnologías da aprendizagem. Neste conceito incluem-se as aplicações tecnológicas ao serviço da educação, desde a sua aplicação concreta ao ensino das disciplinas da área do IEEE (fundamentalmente, as áreas da Engenharia Electrotécnica, Engenharia das Telecomunicações e Engenharia Informática), incluindo experiências e modelos pedagógicos, até à investigação e projecto de ferramentas e materiais de ensino e aprendizagem. Acreditamos que no âmbito das tecnologías de Aprendizagem, assim como em tantos outros, existe um importante factor cultural no mundo iberoamericano, que faz com que a partilha e comunicação de conhecimento em geral se possa fazer melhor nas línguas (espanhol e português) originais. Propomo-nos também como objectivo introduzir nesta revista todas aquelas aplicações das novas tecnologías que facilitem e potenciem a partilha e divulgação de conhecimento científico. No futuro, e à medida das nossas posibilidades, iremos concretizando este objectivo. Queremos agradecer aos nossos companheiros da direcção do Capítulo Español da Sociedade de la Educación do IEEE todo o apoio prestado para o arranque deste projecto, assim como ao Comité Técnico, de Acreditación y Evaluación do

referido Capítulo, e aos revisores de IEEE-RITA. Um agraqdecimento especial a Rob Reilly e Dave Conner, que sempre responderam rápida e eficazmente a todas as nossas solicitações: Obrigado Rob e Dave. Ao Ministerio Español de Educación y Ciencia, que através da sua acção complementar TSI2005-24068-E, nos permitiu lançar a ideia de uma nova revista e, por fim, à IEEE Education Society por depositar a sua confiança em nós, no momento de iniciar este projecto. Não queremos esquecer-nos de todos aqueles investigadores que no âmbito iberoamericano e ao longo dos anos nos incentivaram a desenvolver fora científicos iberoamericanos. A todos nós, comunidade iberoamericana, é dedicada esta revista, que desejamos se converta num ponto de referência para a investigação e aplicação de novas tecnologías no ensino/aprendizagem das temáticas do IEEE. Martín Llamas Nistal é Ingeniero de Telecomunicación (1986) e Doctor Ingeniero de Telecomunicación (1994), ambos os graus atribuídos pela Universidad Politécnica de Madrid. Desde 1987 é professor no ETSI de Telecomunicación de Vigo (de que foi subdirector no período 1994-1997); sendo actualmente profesor titular no Departamento de Ingeniería Telemática da mesma Universidade. Dirigiu vários projectos de investigação na área de Telemática e é autor / co-autor em mais de 100 publicações em revistas e congressos nacionais e internacionais. Desde Dezembro de 1998 a Setembro de 2003 foi Director da Área de Tecnologías de la Información y las Comunicaciones da Universidad de Vigo. Membro de ATI, de ACM e Senior Member do IEEE. Manuel Castro Gil é Doctor Ingeniero Industrial e Catedrático de Universidad. Foi Vicerrector de Novas Tecnologias da UNED, assim como Subdirector de

ISSN 1932-8540 © IEEE

IEEE-RITA, Vol. 1, Num. 1, Nov. 2006 ix

Ordenación Académica y de Investigación na Escuela de Ingenieros Industriales da UNED, e Director do Centro de Servicios Informáticos da UNED, sendo actualmente Director de Departamento. Participou em numerosos projectos de investigação como investigador, coordenador e

director, e publicou em revistas e congressos, tanto nacionais e internacionais. Publicado igualmente diversos livros e material multimédia no âmbito das suas linhas de investigação e docência. É Senior Member do IEEE e membro do Comité de Administración da IEEE Education Society.

ISSN 1932-8540 © IEEE

IEEE-RITA Vol. 1, Num. 1, Nov. 2006 x

ISSN 1932-8540 © IEEE

IEEE-RITA Vol. 1, Num. 1, Nov. 2006 1

Integracion internacional de plataformas deensenanza a distancia de automatizacion con PLCs

Lluıs Molas, Coia Ferrater, Oriol Gomis, Antoni Sudria, Oriol Boix, Israel Benıtez, Ruben Sicchar, MarivanGomes, Felix Roldan, Ksenia Arias y Luisa Villafruela

Abstract— Many teaching institutions worldwide have decidedto work firmly in distance learning applications. In this frame,remote laboratories enable the intensive use of the universitydevices and ease the work of professors and students. The presentwork introduces different platforms to be used in industrial au-tomation practises, developed in Barcelona, Manaus and Santiagode Cuba. The platforms are communicable through Internet,include programmable logic controllers programmable with theopen software CoDeSys and have different sensors and actuatorsusual in industrial installations.

Index Terms— virtual laboratories, remote control, pro-grammable logical controller, automation systems, sequentialcontrol system

I. INTRODUCCION

EL aumento de los sistemas industriales automatizados haobligado a los ingenieros a encontrar soluciones para

todas las disciplinas dentro del campo de la automatizacion.Este hecho ha motivado a las universidades a disponer delaboratorios polivalentes que puedan ayudar a los alumnosa desenvolverse en los diferentes campos. La ensenanza adistancia puede permitir que las universidades especializadasen determinados campos puedan compartir sus experienciascon otras universidades. La finalidad es que un alumnode cualquier universidad pueda automatizar accionamientoselectricos, neumaticos, hidraulicos, entre otros, conectandosea traves de Internet con los PLCs de las distintas plataformasque constituyen dichos laboratorios. Ası, en este artıculo sepresentan y se describen las aplicaciones y capacidades delos laboratorios remotos, cuyas plataformas estan situadas enBarcelona, Manaus y Santiago de Cuba.

Los laboratorios remotos son una buena alternativa a loslaboratorios presenciales. En [1] se describe un control remotode un robot a traves de internet, usando una arquitectura decliente-servidor. En [2] se describe el funcionamiento de unlaboratorio remoto para determinar la velocidad de la luz.En [3] se presenta un laboratorio remoto de automatica condiferentes accionamientos a controlar, todo a traves de internet.

Lluıs Molas, Coia Ferrater, Oriol Gomis, Antoni Sudria y Oriol Boix estanen el CITCEA-DEE-UPC Universidad Politecnica de Cataluna, Av. Diagonal647 Pavello A 08028, Barcelona, Espana. (email: oriol.gomis@upc.edu)

Israel Benıtez, Felix Roldan, Ksenia Arias y Luisa Villafruela estan enel Departamento de Control Automatico - Facultad de Ingenierıa Electrica -Universidad de Oriente (FIE-UO), Ave. Las Americas s/n 90400 Santiago deCuba, Cuba.

Israel Benıtez, Ruben Sicchar y Marivan Gomes estan en el Departamentode Mecatronica - Escuela Superior de Tecnologıa - Universidad del Estadode Amazonas (EST-UEA), Ave. Darcy Vargas 1200 69050-020, Manaus, AM,Brasil.

DOI (Digital Object Identifer) Pendiente

En [4] se citan diferentes experiencias y resultados obtenidosen la utilizacion de cinco laboratorios remotos con estudiantesde ingenierıa mecatronica. En [5] se presenta una plataformade practicas para un laboratorio basado en el control demotores brushless. En [6] se presenta una planta virtual para laformacion en automatas programables. En [7] se propone uncurso a traves de internet para la programacion de una celdade fabricacion flexible con automatas (PLCs, ProgrammableLogic Controller). El presente artıculo presenta la integracioninternacional de diferentes plataformas con plataformas quepermiten acceso remoto, con el objetivo de optimizar almaximo el aprovechamiento de cada uno de los laboratorios.

El software que se utiliza para la programacion de losautomatas es el CoDeSys [8]. CoDeSys es un software libreque incorpora bloques de programacion basado en el estandardIEC 61131-3 [9] para programacion de PLCs y control in-dustrial. Sus principales caracterısticas son la posibilidad deprogramar con los lenguajes que dicta la norma IEC 61131-3,la creacion de una interfıcie hombre-maquina (HMI, HumanMachine Interface) y trabajar en modo simulacion del procesoa controlar.

Para guiar al alumno en esta experiencia a distancia, cadauna de las siguientes plataformas tiene una web en un entornoMoodle [10] donde se pueden encontrar las practicas, elsoftware CoDeSys y su manual de utilizacion, entre otrascosas. El Moodle (Modular Object-Oriented Dynamic Learn-ing Environment) es un CMS (Course Management system),uno de los software libre y abierto mas orientado a gestionarel material de cursos que se imparten a traves de internet[11] y crear comunidades de aprendizaje online. Este softwarepermite a los educadores y profesores insertar, con muchafacilidad y altas prestaciones, el material didactico necessariopara guiar al alumno.

El artıculo esta organizado de la siguiente manera. En lasprimeras secciones se introducen las diferentes plataformas depracticas segun el siguiente orden: la plataforma de Barcelona,la de Manaus y la de Santiago de Cuba. Finalmente, semuestran las conclusiones.

II. PLATAFORMA BARCELONA

La plataforma Barcelona (Figura 1) ha sido disenada comoun conjunto de distintos accionamientos electricos, destinadaa ser utilizada para la ensenanza a distancia. La finalidad deesta no es conseguir una gran potencia en las aplicaciones, sinodisponer de un modelo compacto, simple y visual que permitaa los alumnos programar los automatas y trabajar con las

ISSN 1932-8540 © IEEE

2 IEEE-RITA Vol. 1, Num. 1, Nov. 2006

diferentes estaciones que forman este laboratorio remoto. Losunicos requerimientos para poder trabajar con la plataformason el software abierto de programacion CoDeSys y unaconexion a Internet para descargar el programa al automatay comprobar y supervisar el funcionamiento gracias a unacamara IP. Los elementos de que dispone la plataforma sedescriben a continuacion.

Fig. 1. Vista general de la plataforma

La ensenanza a distancia utilizando laboratorios remotosrequiere la plena disposicion de los equipos a cualquier horadel dıa. Para ello esta estacion permite la iluminacion (IL) de laplataforma durante las horas nocturnas mediante la activacionde una salida digital. La conexion de la lampara se realizamediante un interruptor estatico, que es activado directamentedesde una salida de cualquiera de los dos automatas.

A. Bloque 11) Cinta corredera accionada por un motor paso a paso

(MP1): Esta estacion de la plataforma esta constituida por unmotor paso a paso que acciona una cinta corredera que disponede un elemento metalico. Las bobinas del motor se alimentandirectamente de las cuatro salidas digitales del automata,a traves de cuatro resistencias limitadoras de corriente, ycuatro diodos de vıa libre para evitar las sobretensiones decommutacion de cargas inductivas.

Tres captadores inductivos tipo PNP detectan la posiciondel elemento metalico en el recorrido de la cinta. La finalidad

de esta estacion es que el alumno determine la secuencia defases del motor paso a paso para accionar la cinta en ambossentidos y aplique un control de posicion. En la Figura 2 semuestra un ejemplo de programacion del motor paso a paso.

2) Motor de corriente continua accionado por un conver-tidor DC/DC (MDC): Los elementos que constituyen estaestacion son un motor de corriente continua que disponede un reductor donde esta acoplado un disco con elementosmetalicos, a modo de encoder de baja resolucion. Un captadorinductivo detecta un total de seis pulsos por vuelta. Paracontrolar el motor desde el automata se ha disenado unconvertidor DC/DC reductor que coge como senal de consignael valor de la salida analogica del automata para determinar elciclo de trabajo del interruptor Mosfet que alimenta el motor.En la Figura 3 se muestra el control del ciclo de trabajo delMosfet. El elemento de control principal del convertidor es elcomponente SG3524. Este se utiliza como generador del ciclode trabajo para excitar la puerta del transistor Mosfet BUZ71,amplificando previamente la senal con una etapa de inversoresHC4049.

Fig. 3. Control del ciclo de trabajo del transistor MOSFET

El SG3524 compara una senal de rampa con una continuaregulable que controla la salida analogica del automata, conel objetivo de generar pulsos de duracion variable, pero defrecuencia prefijada. En la Figura 4 se presenta el esquemadel convertidor DC/DC.

Fig. 4. Convertidor DC/DC para la regulacion de velocidad del motor CC

B. Bloque 2

1) Motor paso a paso (MP2): Esta estacion esta constituidapor un motor paso a paso que dispone de un eje metalicoexcentrico. Las bobinas del motor se alimentan, de igualmanera que el motor de la primera estacion, de las salidasdigitales del automata a traves de un circuito intermedio

ISSN 1932-8540 © IEEE

MOLAS et al.: INTEGRACION INTERNACIONAL DE PLATAFORMAS 3

Fig. 2. Ejemplo de programacion de un motor paso a paso

limitador de corriente Un captador inductivo tipo NPN detectala excentricidad del eje, detectando un pulso por vuelta. Lafinalidad de esta estacion es que el alumno determine lasecuencia de fases del motor paso a paso, para que el motorgire en los dos sentidos, y que accione el motor en dosmodos de funcionamiento, paso completo y medio paso, paracomprobar las caracterısticas de par y velocidad de ambosmodos.

2) Motor de induccion con variador de frecuencia (MI):Esta parte de la plataforma acciona un motor de inducciontrifasico con un convertidor de frecuencia comercial. La salidaanalogica del automata de tension variable en el rango de 0-10V da la consigna de velocidad al convertidor. El diagramade bloques del sistema se muestra en la Figura 5. Esta estacionpretende mostrar al alumno la posibilidad de interconexion delos automatas a accionamientos disponibles en el mercado yacercar al alumno a una tıpica aplicacion industrial de controlde velocidad.

Fig. 5. Diagrama de bloques de accionamento del motor de induccion

3) Regulacion de temperatura (RT): Esta estacion esta con-stituida por una sonda de temperatura Pt-100, una resistenciade potencia y un ventilador. La sonda capta la temperatura dela resistencia de potencia. La senal generada por esta se adapta

a una senal de tipo 4-20mA mediante el circuito integradoXTR105, para introducirla a la entrada analogica del automata.El esquema del circuito de adaptacion se muestra en la Figura6.

Fig. 6. Circuito de adaptacion de senal de la sonda PT100

La resistencia se calienta por efecto Joule mediante laaplicacion de una tension variable. Para controlar la tensionse utiliza el troceador reductor (Figura 7), antes mencionado,que utiliza una salida analogica del automata para determinarel ciclo de trabajo del transistor Mosfet.

Fig. 7. Convertidor DC/DC para la regulacion de temperatura

La finalidad del montaje es mostrar al alumno el controlde un sistema de evolucion lenta, en este caso un control de

ISSN 1932-8540 © IEEE

4 IEEE-RITA Vol. 1, Num. 1, Nov. 2006

temperatura, para que se pueda apreciar la progresion de loscambios. En la Figura 8 se presenta el diagrama de bloquesdel sistema de control. Se introducira el concepto de controlcon un regulador tipo PID, implementado en un bloque deCoDeSys.

Fig. 8. Diagrama de bloques del sistema de control de temperatura

Para controlar la planta se utilizaran diferentes estrategias.Una de ellas, es utilizar el funcionamiento del troceador pararegular la temperatura, cambiando directamente la tensionmedia aplicada mediante la variacion del ciclo de trabajo. Otraestrategia es utilizar la accion del ventilador para evacuar elcalor de la resistencia.

Fig. 9. Placa disenada para las practicas

Un posible ejemplo de programa implementado conCoDeSys es el que se muestra en la Figura 10.

C. Supervision

La ensenanza a distancia a traves de laboratorios remotosrequiere un dispositivo de visualizacion para poder comprobarel correcto funcionamiento de las aplicaciones al descargar losprogramas a los automatas.

En la plataforma esta instalada una camara IP (Figura 11)que dispone de servidor propio, sin la necesidad de estarconectada a un PC, cuyo campo de vision se limita a losdistintos elementos de las estaciones, para desempenar lasfunciones de supervision del sistema de ensenanza.

Es recomendable disponer de una conexion rapida a Internetpara que el refrescamiento de pantalla permita observar el fun-cionamiento de los accionamientos a una velocidad aceptable.

Fig. 11. Vista de la plataforma a traves de la camara IP

En la Tabla I se adjuntan la relacion de entradas y sali-das digitales y analogicas de los dos PLCs que integran laplataforma indicando la estacion de trabajo.

III. PLATAFORMA MANAUS

La EST-UEA (Manaus, Brasil) fue la ultima universidad enincorporarse a esta red. No obstante se trabaja fuertemente(con el apoyo de las otras universidades, de los proyectos in-ternacionales CCD y ALFA (ALFA II-0341-A) y del regionalde la FAPEAM-CNPq) en la creacion de las instalaciones.El objetivo es abarcar los diferentes tipos de accionamien-tos y automatizaciones dentro del area de Mecatronica, esdecir, accionamientos electricos y neumaticos unidos a lacoordinacion de actividades con controladores de robots ymaquinas herramientas. Actualmente se dispone de 4 maquetasde accionamientos electroneumaticos (tres de Amatrol y unade Festo), un robot Saturno y una minifresadora con controlelectronico. Para su integracion al sistema de practicas deensenanza a distancia se utiliza un PLC Wago 750-841 y unPLC Telemecanique TSX3722 con modulo de Internet ETZ410. En este trabajo se presentan las practicas desarrolladascon el Wago y el software Codesys.

A. Bloque 1

Accionamiento electrico por PLCs. Los accionamien-tos electricos se pueden clasificar segun el tipo de motoreselectricos que gobiernan. Las caracterısticas de los contro-ladores cambian si los motores son de corriente continua (DC),corriente alterna (AC, principalmente de induccion) y motorespaso a paso.

En la Tabla IV se relacionan los componentes de la maquetade accionamiento electrico del motor paso a paso de la EST-UEA (desarrollado e instalado por los profesores de la UPCdentro del proyecto CCD).

En la Figura 12 se presenta una seccion del programa en elsoftware CodeSys del PLC Wago para el control del motorpaso a paso, desarrollado todo en lenguaje LD (ladder) olenguaje de contactos, donde se crea una senal pulsante para

ISSN 1932-8540 © IEEE

MOLAS et al.: INTEGRACION INTERNACIONAL DE PLATAFORMAS 5

Fig. 10. Ejemplo de programacion de la regulacion de temperatura

TABLA IRELACION DE ENTRADAS Y SALIDAS DEL PLC1

I/O Direccion Descripcion Estacion

DI %IX2.0 Sensor Inductivo Posicion 1 MP1DI %IX2.2 Sensor Inductivo Posicion 2 MP1DI %IX2.4 Sensor Inductivo Posicion 3 MP1DI %IX2.6 Sensor Inductivo Deteccion Pulsos MCCDO %QX2.0 Bobina 1 Motor Paso a Paso MP1DO %QX2.1 Bobina 2 Motor Paso a Paso MP1DO %QX2.2 Bobina 3 Motor Paso a Paso MP1DO %QX2.3 Bobina 4 Motor Paso a Paso MP1DO %QX2.7 Activacion Interruptor Estatico Luz IL1AO %QW0 Duty Cycle Convertidor DC/DC MDC

TABLA IIRELACION DE ENTRADAS Y SALIDAS DEL PLC2

I/O Direccion Descripcion Estacion

DI %IX2.0 Sensor Inductivo MP2DO %QX2.0 Bobina 1 Motor Paso a Paso MP2DO %QX2.1 Bobina 2 Motor Paso a Paso MP2DO %QX2.2 Bobina 3 Motor Paso a Paso MP2DO %QX2.3 Bobina 4 Motor Paso a Paso MP2DO %QX2.4 Sentido de Giro Positivo Motor Induccion MIDO %QX2.5 Activacion del Ventilador RTDO %QX2.6 Activacion Interruptor Estatico Luz IL2DO %QX2.7 Velocidad del Motor de Induccion MIAI %IW0 Sonda de temperatura RTAI %IW1 Consigna de Velocidad Motor de Induccion MIAO %QW0 Duty Cycle del Convertidor DC/DC resistencia RTAO %QW1 Consigna velocidad variador de frecuencia MI

ISSN 1932-8540 © IEEE

6 IEEE-RITA Vol. 1, Num. 1, Nov. 2006

TABLA IIIRELACION DE COMPONENTES MAQUETA MANAUS

Cantidad Componente

1 Motor de pasos PM 35L - 0481 Puente de Diodos4 Resistencias de potencia1 PLC Wago1 Fuente Telemecanique TBX SUP 10 (24 volts)

Fig. 12. Ejemplo programacion del motor paso a paso

repetir el ciclo y luego se divide en 4 partes con tempo-rizadores, esto establece un ciclo de 4 etapas utilizado parael sentido horario o antihorario. Este PLC tiene incorporadoen su CPU un servidor Ethernet que permite conectar el mismoa cualquier red LAN (sistema de transmision de datos) con unnumero IP como se hace con cualquier ordenador normal. Estafacilidad permite la programacion y el control remoto de lapractica de forma local y a distancia.

B. Bloque 2

Interfaz de programacion y control remoto de laspracticas desde una interfaz usuario en Internet. El es-tudiante de automatizacion tambien necesita conocer como sedisenan y programan sistemas de control remoto, por tanto lainterfaz de programacion y control remoto no solo es utilizadapara estudiantes a larga distancia, sino tambien para que losestudiantes locales aprendan el conocimiento (Know-How)de como son desarrollados estos sistemas. Para este fin, senecesita una arquitectura de comunicacion distribuida con trestipos de interfaz: la interfaz de comunicacion, entre el procesode los sistemas de control y el servidor de aplicaciones deprocesos; interfaz de servidor de aplicaciones y el servidorweb, y una ultima interfaz entre el servidor web y los usuarios.La primera interfaz se desarrolla en lenguaje java, en labviewy datasockets a fin de formar un servidor intermediario de basede datos que permite el acceso a la comunicacion y gestionarlos procesos del automata, desde la plataforma de software

intermedio Moodle (middleware, software que se encuentraentre el sistema operativo y las aplicaciones del sistema). Lasegunda interfaz se desarrolla tambien con lenguaje java, lab-view, datasockets y miniaplicaciones (servlets, programas quese ejecutan en el servidor) java que permiten el accionamientode los recursos de visualizacion grafica del sistema distribuido.La tercera interfaz se desarolla encima de programacion PHP(lenguaje del lado servidor de gran potencia y simplicidad),propia del Moodle, sin embargo cuenta con lenguaje java yminiaplicaciones (applets, programillas que se ejecutan en lamaquina cliente) java para garantizar la visualizacion graficade los comandos solicitados por el usuario.

Con la arquitectura de comunicacion distribuida se pretendeofrecer algunos recursos de visualizacion especıficos como lasimagenes en tiempo real de la ejecucion de las practicas, lassimulaciones de programas utilizando los distintos lenguajesde programacion y los graficos de los parametros de laspracticas implementadas. Todos estos procesos quedan abier-tos para el analisis de los estudiantes interesados al ser in-corporados como recursos didacticos para que los estudiantestomen ejemplos y desarrolle otras aplicaciones similares.

C. Supervision

La plataforma Manaus, por la misma razon que en laplataforma Barcelona, necesita algun recurso que permita alalumnado supervisar sus practicas cuando trabaja a traves deinternet, online. En Manaus se dispone de una webcam. Estase encuentra delante del sistema, permitiendo la visualizacionde todos los movimientos de la celula de fabricacion flexible.En la Figura 13 se muestra la imagen del sistema de trabajocaptada a traves de la webcam.

Fig. 13. Vista del sistema de trabajo a traves de la webcam

IV. PLATAFORMA SANTIAGO DE CUBA

Esta plataforma se encuentra instalada en la Universidad deOriente (UO) de Santiago de Cuba (Cuba) y es el resultadovarios anos de trabajo y colaboracion entre la UO y la UPC.

ISSN 1932-8540 © IEEE

MOLAS et al.: INTEGRACION INTERNACIONAL DE PLATAFORMAS 7

TABLA IVRELACION DE COMPONENTES EN LA MAQUETA DE CONTROL DE

VELOCIDAD DE UN MOTOR DE CORRIENTE CONTINUA

Cantidad Componente

1 Motor de pasos PM 35L - 0481 Taco generador1 Maqueta SAD 1001 PLC Wago1 Convertidor 0-10 V a 4-20 mA1 Fuente de alimentacion (24 volts)

A. Bloque 1

Control de Velocidad de un motor de DC empleandoel PLC Wago. Los sistemas de control encuentran un ampliocampo de aplicacion en el control de motores. Las practicas delaboratorio que se imparten con esta plataforma se basan en elcontrol de motores, en este caso, en el control de velocidad deun motor de corriente continua. Este sistema se compone por lamaqueta (Figura 13 donde esta montado el motor de corrientecontinua (DC), el tacogenerador y el freno, un sistema depotencia y un PLC Wago. Para controlar la velocidad dedicho motor se utiliza y implementa un controlador del tipoPI (proporcional y integrador) utilizando el gran potencial delprograma CoDeSys que integra en sus librerias este bloquefuncional.

Fig. 14. Instalacion: motor CD, freno y tacogenerador

El automata Wago tiene dos entradas analogicas de rangode 4 a 20 mA y dos salidas analogicas de rango de 0 a 10V.Estas variables se utilizan para interactuar con el sistema detrabajo, una entrada analogica se utiliza para leer la velocidadreal del motor y una de las salidas para mandar consignas develocidad al convertidor. Para adaptar la salida de la maquetacon la entrada del automata se ha disenado circuitos basados enamplificadores operacionales para la adaptacion de corriente yniveles de tension.

El objetivo de este sistema de trabajo es que los alumnosrealicen sus propios programas de control y los descarguen

al PLC a traves de Ethernet. En la Figura 15 se muestraparte del programa para el sistema realizado en lenguaje SFC(Sequential Function Chart).

Para la supervision se dispone de un sistema Web quepermite el acceso al estado de todas las entradas y salidasdel automata, ası como la informacion de la configuraciondel PLC, entre otras cosas. Con esta informacion los usuar-ios pueden verificar el funcionamiento de sus programasdescargados al automata. El link de la pagina de acceso delautomata se encuentra en la plataforma Moodle, junto conotros documentos e informacio de interes para la realizacionde las practicas. En la Figura 16 se muestra la pagina con lainformacion del automata WAGO utilizado por el alumno parasu supervision de las practicas.

Fig. 16. Informacion a cerca del PLC WAGO

Tal como se ha comentado anteriormente el softwareCoDeSys permite trabajar en modo simulacion. Este recursopermite que los estudiantes simulen sus programas antesde descargarlos al automata y ası verificar su correcto fun-cionameiento, corrigiendo los posibles errores de progra-macion. En la Figura 17 se muestra un ejemplo de un programapara el funcionamiento de un semaforo y su visualizacioncomo modo de supervision del sistema de control.

V. CONCLUSIONES

En este artıculo se presentan diferentes plataformas paradesarrollar practicas de automatas programables a traves deInternet. Se emplean automatas Wago y el software de progra-macion CoDeSys. El alumno puede desarrollar practicas cen-tradas en accionamientos de diversos tipos dentro del area demecatronica que le ayuden en su formacion, introduciendolesnuevas tecnologıas y metodologıas de estudio.

La experiencia practica de la puesta en marcha de loslaboratorios remotos y su integracion ha demostrado ser uncomplemento perfecto a las tradicionales practicas presen-ciales. Los alumnos han reforzado sus conocimientos y hanpodido hacer mas practicas de lo habitual. Ası, la expericienciade integrar diferentes plataformas de automatizacion ha sidoplenamente satisfactoria.

ISSN 1932-8540 © IEEE

8 IEEE-RITA Vol. 1, Num. 1, Nov. 2006

Fig. 15. Fragmento de codigo realizado en CoDeSys

Fig. 17. Ejemplo de programa para el funcionamiento de un semaforo

Los autores quieren subrayar el creciente potencial de for-macion a distancia y las grandes posibilidades que ofrece tantoa nivel teorico como practico. Este potencial es especialmenteimportante porque permite la implantacion de redes de labo-ratorios remotos donde se optimizan al maximo los recursos.Ası, un estudiante de cualquiera de las universidades de la redpodra acceder a las practicas de las otras. Para alcanzar estosobjetivos, existen ciertas cuestiones que se tienen que tener encuenta: la velocidad de la conexion a Internet (importante parala rapidez de carga y refresco del programa, de las pantallasde supervision y de la camara IP) y la gestion de usuarios paraacceder a los automatas.

RECONOCIMIENTO

Los autores agradecen el apoyo del CCD-UPC, proyectoAlfa II-0341-A y las empresas Schneider Electric y Wago.

REFERENCIAS

[1] B. Aktan, C. Bohus, L. Crowl, and M. Shor, “Distance learning appliedto control engineering laboratories,” IEEE Transactions on Education,vol. 39, no. 3, pp. 320–326, Aug 1996.

[2] C. Enloe, W. Pakula, G. Finney, and R. Haaland, “Teleoperation in theundergraduate physics laboratory-teaching an old dog new tricks,” IEEETransactions on Education, vol. 42, no. 3, pp. 174–179, Aug 1999.

[3] M. Casini, D. Prattichizzo, and A. Vicino, “The automatic controltelelab,” IEEE Control Systems Magazine, vol. 24, no. 3, pp. 36–44,Jun 2004.

[4] J. Trevelyan, “Lessons learned from 10 years experience with remotelaboratories,” in International Conference on Engineering Education andResearch Progress Through Partnership, Ostrava, 2004.

[5] D. Montesinos, S. Galceran, A. Sudria, and O. Gomis, “A laboratorytest bed for pm brushless motor control,” in EPE 2005 - EuropeanConference on Power Electronics and Applications, Dresden, Sept 2005,pp. 1–6.

[6] J. Miquel, F. X. Mestre, S. Galceran, and A. Sudria, “Planta virtual parala formacion en automatas programables,” in XIII Reunion de grupos deinvestigacion de ingenierıa electrica, Vigo, Spain, 2003.

[7] O. Gomis, D. Montesinos, S. Galceran, A. Sumper, and A. Sudria, “Adistance plc programming course employing a remote laboratory basedon a flexible manufacturing cell,” IEEE Transactions on Education,vol. 49, no. 2, pp. 278–284, May 2006.

[8] 3S - Smart Software Solutions - User Manual, Available: www.3s-software.com.

[9] IEC61131-3 Programmable controllers. Part 3. Programming lan-guages, 2nd ed. IEC International Electrotechnical Commission, 2003.

[10] Moodle, Available: http://moodle.org.[11] J. Garcia, O. Boix, I. Benıtez, and A. Sumper, “Criteria of selection and

comparative study of e-learning platforms,” in International ConferenceInteractive Computer Aided Learning, Villach, Austria, Sept 2005.

ISSN 1932-8540 © IEEE

MOLAS et al.: INTEGRACION INTERNACIONAL DE PLATAFORMAS 9

Lluıs Molas Balada obtuvo la diplomatura de In-geniero Tecnico Industrial especializado en elect-ricidad en junio de 2003 y la licenciatura de In-geniero Industrial en enero de 2006. Actualmentees estudiante de doctorado y becario del area deenergıa del CITCEA. Su trabajo se centra en eldiseno de plataformas remotas para e-learning, lamonitorizacion de subestaciones para un manten-imiento predictivo, el comportamiento dinamico deaerogeneradores y la calidad de subministro.

Coia Ferrater Simon nacio en Reus (Tarragona).Obtuvo la licenciatura de Ingeniera Industrial Supe-rior especialidad en automatica en enero de 2006.Actualmente es estudiante de doctorado y becariadel area de mecatronica del CITCEA. Su trabajose centra en el desarrollo hardware y software deconvertidores de frecuencia y diseno de plataformasremotas para e-learning.

Oriol Gomis Bellmunt nacio en Alio, Tarragona,Espana, en 1976. Obtuvo el tıtulo de ingenieroindustrial por la UPC en 2001. En 1999, se in-corporo a Engitrol, Barcelona, como ingeniero deproyectos en la industria de la automatizacion. En2003, desarrollo parte de su doctorado en el DLR(Centro aerospacial aleman), Braunschweig, Alema-nia. Desde 2004, es profesor ayudante en el depar-tamento de ingenierıa electrica, UPC y participa enel CITCEA-UPC. Sus areas de interes incluyen losactuadores inteligentes, las maquinas electricas, la

automatizacion industrial y la educacion.

Antoni Sudria Andreu nacio en Barcelona, Espana,en 1950. Obtuvo el tıtulo de ingeniero industrialcon especialidad electrica y el de doctor por laUniversidad Politecnica de Cataluna en 1979 y 2005respectivamente. En 1979, se incorporo al depar-tamento de ingenierıa electronica de la UPC. En1980, se incorporo a La Maquinista Terrestre yMarıtima (MTM), actualmente Alstom. Al mismotiempo, continuo como profesor a tiempo parcial enel departamento de ingenierıa electrica donde se es-tablecio como profesor a tiempo completo en 1985.

Es autor y coautor de mas de 100 publicaciones, incluyendo algunos libros. Hadirigido una gran cantidad de proyectos de investigacion y de transferenciade tecnologıa con empresas. En 2001 fundo el CITCEA-UPC (Centro deInnovacion Tecnologica en Convertidores Estaticos y Accionamientos).

Oriol Boix Aragones nacio en Barcelona (Espana).Obtuvo el tıtulo de ingeniero industrial con espe-cialidad electrica y el de doctor por la UniversidadPolitecnica de Cataluna en 1988 y 1997 respectiva-mente. Es profesor del Departamento de IngenierıaElectrica de la Universidad Politecnica de Cataluna.Sus areas de interes son la ensenanza a traves deinternet, los armonicos, la calidad del suministroelectrico y la automatizacion industrial.

Israel Benıtez Pina nacio el 1959 en Santiago deCuba, Cuba. Graduado en 1982 de Ingenierıa deControl Automatico en Universidad de Oriente (UO,Cuba). Desde 1982 fue Profesor del Departamentode Control Automatico de la UO e En 1999 terminasu Doctorado en Ciencias Tecnicas con el trabajode Programacion orientada a objeto de CLPs. Desde1994 impartio postgrado sobre Automatica Indus-trial, Algoritmos para control de CLPs, Lenguajesde Programacion, Modelado y control de sistemasde eventos discretos, Automatizacion Neumatica e

Hidraulica, Robotica industrial en universidades de Cuba, Mexico, Venezuela,Espana y Brasil. En el 2001 realiza un Post-doctorado en Mecatronica enla Escuela Politecnica de la Universidad de Sao Paulo, USP, Brasil. Desde1985 trabaja en diferentes proyectos de automatizacion industrial en Cuba.Desde 1994 participa en diferentes proyectos internacionales como Red deEdificios Inteligentes de CYTED (1998), ALFA de ensenanza a distanciade automatizacion industrial (No. II-0341-A del 2003), FAPEAM-CNPq demodelado y programacion de sistemas de manufactura flexible (2004). Realizainvestigaciones en las lıneas de Automatizacion de Procesos Industriales,Modelado y control de Sistemas de eventos discretos. Control de ProcesosIndustriales, Automatizacion Neumatica e hidraulica, Robotica, Programacionorientada a objetos, Sistemas tolerantes a fallas, Ensenanza a distancia.

Jose Ruben Sicchar Vilchez nacio el 1974 enIquitos, Peru. Estudio y se graduo en ingenieriaelectrica en la Universidade Federal do Amazonas,en Manaus, Brasil en 1999. Hizo post-grado en inge-nieria industrial (2000), ingenieria de mantenibilidad(2001) e ingenieria economica (2003). Desarrolloproyectos de distribuicion de enegia electrica dealta,mediana e baja tension en la concesionaria deenergia electrica Manaus Energia e CEAM, emManaus de 2000 a 2003. Dedicase desde 2003 ala docencia universitaria de ingenieria electrica y

mecatronica, en la Escola Superior de Tecnologia de la Universidade do Estadodo Amazonas y de ingenieria de telecomunicaciones del centro de ensenanzasuperior FUCAPI. Es miembro del grupo de investigacion cientıfica Placasdel CNPq y del grupo de investigacion internacional ALFA para sistemasde ensenanza a distancia de automatizacion por internet. Actualmente desar-rolla proyectos de automatizacion industrial y de sistemas de comunicaciondistribuidos aplicados al control de posicion de manipualdores roboticos conestimacion correctiva de filtros de Kalman, que es tema de su tesis de maestriaen ingenieria de telecomunicaciones, por la Universidade Federal do Para.

Marivan Silva Gomes e Professor Visitante doDepartamento de Engenharia da Computacao daUniversidade Estadual do Amazonas (UEA), Engen-heiro Pleno pela Universidade Federal do Amazonas(UFAM, 1996), Mestre em Engenharia Eletrica(UFRJ, 2005). Desde 1996 vem trabalhando comSistemas Embarcados e Automacao/Controle, sendodocente de disciplinas nesta area desde 1997 naUFAM/UEA. Atualmente e Coordenador do Pro-grama de Pos-Graduacao em Mecatronica Industrialna UEA (Especializacao).

ISSN 1932-8540 © IEEE

10 IEEE-RITA Vol. 1, Num. 1, Nov. 2006

Felix Vladimir Roldan Jimenez nacio en Moscu,URSS en 1978. Obtuvo el tıtulo de Ingeniero enAutomatica en la Universidad de Oriente en Juliodel 2002. En 2002 se incorporo como profesor alDepartamento de Control Automatico de la Facultadde Ingenierıa Electrica de la UO. Participa en elproyecto Alfa de la union europea para desarrollarun sistema a distancia de ensenanza de automati-zacion utilizando automatas y para la creacion deuna red de laboratorios remotos.

Ksenia Arias Granda nacio en Santiago de Cuba,Cuba en 1978. Obtuvo el titulo de Ingeniero enAutomatica en la Universidad de Oriente en Julio del2002. Inmediatamente despues de graduada se in-corporo como profesora al Departamento de ControlAutomatico de la Facultad de Ingenierıa Electrica dela propia universidad. Dentro de sus funciones comodocente ha tutorado tesis de grado y proyectos decursos. Es autora y coautora de varias publicaciones,ha participado en proyectos relacionados con el usode las TIC en la ensenanza.

Luisa Villafruela Loperena , Ingeniero en Tele-comunicaciones, Master en Automatica. ProfesoraAsistente. Imparte docencia de Automatica I en elDepartamento de Control Automatico. Investiga enel modelado de redes de comunicaciones industrialescomo parte de una automatizacion integrada.

ISSN 1932-8540 © IEEE

IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006 11

Desarrollo de un sistema ARS para enseñanza en línea

Mario Muñoz Organero, Carlos Delgado Kloos, Senior Member, IEEE

Abstract—Audio Response Systems (ARS) are currently used

as a mechanism to enhance face to face education in classrooms and the results are promising. These systems could also improve certain aspects in e-learning if designed appropriately. This paper presents a design and implementation of an ARS adapted to both face to face education and distance learning scenarios. We also show how this ARS system is deployed inside the Carlos III of Madrid University.

Index terms— Audience Response Systems, Classroom Response Systems, e-learning, m-learning.

I. INTRODUCCIÓN OS Sistemas de Respuesta de Audiencia permiten obtener información en forma de realimentación sobre la opinión

y/o conocimiento de la audiencia. Su utilización como soporte a la enseñanza presencial en los últimos años revela resultados interesantes como puede verse en el trabajo de P. B. Lowry et al. [1] y en el trabajo de D. W. Petr [2]. En el trabajo de P. B. Lowry et al. se utilizan los sistemas ARS como soporte a clases con gran número de alumnos como facilitadores de la interacción. En el trabajo de D. W. Petr [2] se usa un sistema ARS para permitir a los alumnos contestar preguntas en clase y el aprendizaje a través de las respuestas obtenidas a la vez que se permite al profesor obtener una realimentación de la asimilación de los contenidos presentados por parte de los alumnos.

Los sistemas ARS, por una parte, permiten aumentar la interactividad del alumno permitiendo su expresión de forma más fácil y ágil que mediante la tradicional interacción directa en clase y evitando el efecto negativo del miedo a hacer el ridículo. Por otra parte, se permite que los alumnos aprendan unos de otros mediante la formación de consensos. De igual forma permiten llevar algunas de las ventajas de clases pequeñas con pocos alumnos a clases con mayor número de alumnos en cuanto a la interactividad y dinamismo de la clase

se refiere así como al aprovechamiento del tiempo de la misma. Finalmente, y no menos importante, permiten obtener un conocimiento directo del estado de asimilación de los conocimientos impartidos al profesor posibilitando la adaptación instantánea del ritmo y forma de exposición. Estas ventajas pueden hacerse extensivas a la educación on-line si los sistemas ARS se diseñan apropiadamente. Ello requiere no solo la utilización de interfaces Web para la comunicación alumno-alumno y a alumno-profesor sino también el diseño de las capacidades del sistema de cara a facilitar el seguimiento en tiempo real de la clase así como su seguimiento en diferido. En este artículo presentamos el diseño y desarrollo de un sistema ARS (WSTIS o Wireless Student-Teacher Interaction System) adaptado tanto a entornos de enseñanza presencial como a distancia. Presentamos también como dicho sistema se ha concebido no solo para el e-learning sino también para el m-learning. Finalmente enmarcamos el sistema en el entorno concreto de la Universidad Carlos III de Madrid como marco de una experiencia concreta del sistema.

Mario Muñoz Organero es Profesor Titular del Departamento de Ingeniería

Telemática de la Universidad Carlos III de Madrid, Av. Universidad 30, 28911 Leganés, Madrid, España. Teléfono: (+34) 91-624-8801; fax: -8749; e-mail: munozm@it.uc3m.es.

Carlos Delgado Kloos es Catedrático del Departamento de Ingeniería Telemática de la Universidad Carlos III de Madrid, Av. Universidad 30, 28911 Leganés, Madrid, España. Teléfono: (+34) 91-624-8778; fax: -8749; e-mail: cdk@it.uc3m.es.

DOI (Digital Object Identifier) Pendiente

El artículo se organiza en 7 secciones. La primera, esta sección, es una introducción al resto del artículo y presenta la motivación del mismo. La segunda se dedica a hacer un repaso del estado del arte en cuanto al uso de los sistemas de respuesta de audiencia en lo referente a su utilización como soporte educativo. La tercera recoge los requisitos de diseño de un sistema de respuesta de audiencia on-line. Estos requisitos constituyen la pauta de diseño de la aplicación que se muestra en el presente artículo. La cuarta detalla la funcionalidad del sistema desarrollado. Se organiza la funcionalidad de acuerdo a los perfiles de uso del sistema. La quinta presenta el formato de exportación e importación de datos del sistema que permite la reusabilidad de contenidos. Se define para ello un schema XML. La sexta se dedica a detallar un caso de uso del sistema dentro del escenario concreto de la Universidad Carlos III de Madrid. Finalmente, la última sección se deja para sacar conclusiones del trabajo realizado.

II. USO DE SISTEMAS ARS COMO APOYO EN CLASE Los sistemas de respuesta de audiencia, también

denominados dependiendo de su escenario de aplicación como sistemas de respuesta electrónica (Electronic Response Systems), sistemas de comunicación en clase (Classroom Communication Systems), sistemas de interacción en clase (Classroom Interaction Systems), sistemas de rendimiento en

L

ISSN 1932-8540 © IEEE

12 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

clase (Classroom Performance Systems) o sistemas de respuesta personal (Personal Response Systems), por mencionar algunos de los más frecuentes, definen una familia de sistemas que utilizan equipos electrónicos conectados en red para permitir que los miembros de una audiencia puedan expresar su opinión. A lo largo de los años, la tecnología subyacente en estos sistemas ha ido pasando desde hardware propietario consistente normalmente en botoneras diseñadas a medida a sistemas programables como PCs de sobremesa, portátiles, tablet PCs, PDAs e incluso teléfonos móviles.

Los sistemas ARS son utilizados ya en los años 70 como experiencias educativas. J. Casanova realizó un experimento usando un sistema ARS en química orgánica, que publicó en 1971 [3], que permitía conocer si la asimilación de la clase era inferior al 50% en cuyo caso era necesaria la repetición de la materia. J. D. Brown publicó en 1972 [4] una experiencia similar aplicada a conceptos matemáticos en la que se permitía al instructor adaptar el ritmo de impartición en función de las respuestas de los alumnos. D. P. Grag por su parte, publicó en 1975 [5] un experimento en el que se permitía a los alumnos que opinaran sobre el ritmo de impartición de una clase usando un sistema ARS.

La bibliografía existente sobre el uso de los sistemas ARS como soporte a la impartición de una clase presencial nos muestra algunos entornos habituales de empleo de los mismos. En primer lugar encontramos el guiado de la velocidad de impartición de la clase como se muestra en [5]. En segundo lugar podemos ver su utilización para la obtención de información por parte del profesor sobre la asimilación de los conceptos explicados mediante las respuestas de cuestiones tipo test por parte de los alumnos [6]. Los sistemas ARS se usan también como elemento motivacional mediante la realización de competiciones entre alumnos por número de respuestas acertadas y su consiguiente impacto en la nota de la asignatura [7]. Otras referencias como [8] proponen el uso de los sistemas ARS incluso como entorno más complejo que permite a los alumnos introducir comentarios, completar información en las trasparencias del profesor o responder preguntas abiertas. En cuanto a lo que al tamaño de la clase se refiere, J. Doyle et al. [16] muestra la mejora que los sistemas ARS introducen en la interactividad de la clase cuanto más grande es el número de alumnos. La mejora de interactividad por el uso de sistemas ARS en clase también es estudiada por K. Siau et al [17] mostrando resultados positivos en esta línea.

Dejando de lado los sistemas hardware propietarios como [9] la mayoría de sistemas se basan en el uso por parte de los alumnos de un PC de sobremesa como en [7], un tablet PC [8], una PDA o un teléfono móvil [6]. Una solución basada en PC de sobremesa limita su uso a laboratorios docentes, normalmente usados en clases prácticas, donde se disponen de puestos con dichos dispositivos, aunque normalmente compartidos por un grupo de 2 alumnos. Una solución en el otro extremo basada en teléfonos móviles requiere el desarrollo de una aplicación en algún entorno común a la mayoría de los dispositivos en el mercado, normalmente en J2ME y requiere el uso en muchas ocasiones de conexiones

WAN como GPRS o UMTS lo que implica un coste para el alumno, sin mencionar las limitaciones existentes en la interfaz de usuario. Soluciones basadas en tablet PCs limitan su uso a la disponibilidad de dichos dispositivos y a la duración de la batería de los mismos que normalmente no podrán ser alimentados en clase si esta no dispone de suficientes tomas de alimentación eléctrica o se realiza la impartición de la clase en grupos pequeños. En este sentido, cuando se usan los sistemas ARS como soporte a una clase presencial una de las mejores soluciones es el uso de PDA que permite interfaces basados en tecnologías Web, conexiones tipo LAN como WiFi o Bluetooth y suficiente autonomía de baterías.

Cuando queremos usar los sistemas ARS en tele-educación, o en escenarios mixtos de apoyo a la enseñanza presencial y enseñanza on-line, aparecen nuevos requisitos. Pese a que, como se ha comentado, existen múltiples referencias al uso de estos sistemas como apoyo a las clases presenciales, no se han identificado referencias de interés para el caso de enseñanza on-line. El objetivo de este artículo es presentar primero los requisitos de un sistema ARS on-line y posteriormente la implementación de un sistema adaptado al caso concreto de la enseñanza dentro de la Universidad Carlos III de Madrid.

III. REQUISITOS DE UN SISTEMA ARS ON-LINE Antes de presentar el sistema WSTIS vamos a presentar los

requisitos del mismo de cara a su utilización en tele-educación. Estos requisitos pueden categorizarse en dos bloques principales atendiendo a aquellos que hacen referencia a la obtención de realimentación al profesor y aquellos que permiten obtener información al alumno. Cada uno de estos bloques principales puede a su vez dividirse en dos sub-bloques, el primero haciendo referencia a los requisitos del sistema como soporte en tiempo de impartición y el segundo haciendo referencia al soporte en diferido.

Analicemos primero los requisitos desde el lado del profesor. Como soporte en tiempo de impartición es interesante que el profesor pueda saber en todo momento si los alumnos remotos que están siguiendo la sesión van o no siguiendo la clase. Para ello es interesante tener información tanto sobre el ritmo de impartición de la clase como de la asimilación de los contenidos. En el primer caso es interesante conocer el porcentaje de alumnos que consideran que la clase se está impartiendo demasiado rápida o demasiado lenta. En el segundo caso es importante para el profesor disponer de la capacidad de enviar a los alumnos preguntas tipo test que estos puedan responder en breve espacio de tiempo. Es importante que estas preguntas puedan exportarse e importarse en un sistema de gestión de aprendizaje on-line de cara a su reutilización y para ello resulta interesante el uso de formatos en XML. Como soporte en diferido el profesor deberá poder recibir información también de las respuestas de los alumnos a medida que estos van revisando la exposición de la clase y tener accesibles, de forma cómoda, estadísticas finales e incluso la posibilidad de obtener información

ISSN 1932-8540 © IEEE

MUÑOZ ORGANERO Y DELGADO KLOOS: DESARROLLO DE UN SISTEMA ARS 13

personalizada para cada alumno que pueda ser tenida en cuenta a la hora de la calificación de la asignatura y, por tanto, ser usada como elemento motivacional a la participación en clase en un determinado momento. Los interfaces de acceso del profesor pueden suponerse accesibles mediante navegador Web de PC de cara al diseño de la presentación de la información.

Analicemos ahora los requisitos desde el lado del alumno. Como soporte en tiempo de impartición el alumno debe poder expresar en todo momento su opinión sobre el ritmo de impartición de la clase. Además debe disponer de un mecanismo sencillo para contestar a las preguntas del profesor. Es importante también que el alumno, una vez contestada la pregunta pueda aprender de las mismas. Para ello se le puede mostrar la respuesta del profesor o bien la respuesta (en porcentajes) del resto de sus compañeros. Esta última opción es interesante de cara al aprendizaje colaborativo y no aplica solo a las sesiones con profesor sino también a los trabajos en grupo. Como soporte en diferido es interesante que el alumno pueda también recibir las preguntas a medida que se visualiza la presentación así como las soluciones a las mismas. De cara a facilitar el aprendizaje ubicuo, en cualquier momento y en cualquier lugar, es importante diseñar la interfaz del alumno para que pueda visualizarse en dispositivos móviles como PDAs. Esto hace que el sistema pueda usarse también de forma presencial como soporte a la clase sin requerir que cada alumno tenga que usar un dispositivo de sobremesa sino tan solo un dispositivo móvil.

Presentamos en las siguientes secciones el diseño, desarrollo y contextualización del sistema WSTIS que ha sido implementado siguiendo estos requisitos.

IV. FUNCIONALIDAD DEL SISTEMA El sistema WSTIS se basa en una aplicación Web que

puede ser accedida según tres perfiles: Alumno, Profesor y Administrador. Cada perfil tiene unas acciones características, y a su vez, todos los perfiles comparten una serie de acciones comunes. Las acciones comunes son: 1) Validarse en la aplicación. El sistema se ha diseñado para

que la validación se pueda realizar contra información de una base de datos o bien mediante LDAP de cara a poder integrarse en plataformas de entidades que tengan la información de usuarios accesibles mediante dicho protocolo.

2) Salir de la aplicación. La aplicación pide confirmación de que realmente se quiere abandonar la sesión previamente a mostrar un mensaje de despedida.

3) Mostrar datos personales. Se permite visualizar el nombre y apellidos de los usuarios, sus datos de contacto así como su perfil.

4) Actualizar datos personales actualizables. No todos los datos de usuario se pueden modificar por éste. Algunos de ellos solo estarán accesibles al administrador. Básicamente, la aplicación permite cambiar los datos de

contacto de los usuarios y la contraseña de acceso a la aplicación.

El perfil del alumno presenta un menú con las siguientes

opciones: 1) Responder a la última pregunta. A medida que avanza la

clase el profesor puede ir introduciendo preguntas. El alumno solo podrá responder en cada momento la última pregunta puesta por el profesor. Este indicará al alumno el momento en que debería contestar dicha pregunta de cara a garantizar el perfecto desarrollo y coordinación de la clase.

2) Obtener realimentación sobre la respuesta correcta una vez contestada una pregunta bien del profesor bien del resto de alumnos (dependiendo del caso).

3) Indicar (votar) la opinión sobre el ritmo de impartición del profesor.

La figura 1 muestra, a modo de ejemplo, la pantalla que el

alumno usa para responder a la última pregunta puesta por el profesor:

Fig. 1. Interfaz del alumno: responder a una pregunta

La figura 2 muestra por su parte la pantalla asociada al

punto 3 anterior.

Fig. 2. Interfaz del alumno: opinar sobre la velocidad de impartición

El perfil del profesor presenta un menú con mayor

funcionalidad. En concreto permite 1) Ver las estadísticas de lo que los alumnos opinan sobre el

ritmo de impartición de la clase. Estas estadísticas

ISSN 1932-8540 © IEEE

14 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

muestran los resultados tanto en números absolutos como en porcentajes y se van refrescando periódicamente. De esta manera el profesor puede obtener una idea de su ritmo de impartición y a la vez saber cuán fidedigna es la medida en función del número de respuestas obtenidas.

2) Obtener estadísticas globales y por alumno de la respuesta a las preguntas. Las estadísticas globales permiten obtener al profesor una información rápida y en tiempo de impartición del grado de asimilación de los conceptos que se están presentando. Las estadísticas por alumno permiten realizar un seguimiento personalizado en diferido de los mismos, tanto en su seguimiento de la clase en tiempo de impartición como en diferido. Estos datos pueden usarse para alimentar sistemas de motivación del alumno como por ejemplo el dar puntos extra a los alumnos que mejor responden entre los asistentes a las sesiones presenciales.

3) Componer preguntas mediante interfaz Web. Dado que durante la impartición de la clase el profesor no tiene tiempo normalmente de componer las preguntas, esta herramienta permite al profesor pre-cargar preguntas en el sistema de forma que puedan ser enviadas a los alumnos a la hora de impartir la clase. La interfaz se ha diseñado de forma suficientemente sencilla como para que profesores no tecnólogos puedan hacer uso de la misma.

4) Cargar preguntas de fichero y exportar preguntas a fichero. Esta herramienta permite la reutilización de material entre ediciones de un curso o entre cursos. Además permite crear herramientas de autor de preguntas más complejas que la introducida en el sistema y comentada en el punto anterior. Mediante la exportación-importación permite la inserción de dichas preguntas en el sistema.

A modo de ejemplo, la figura 3 muestra la interfaz que el

profesor utiliza para cargar preguntas según lo presentado en el punto 4 anterior.

Fig. 3. Interfaz del profesor: cargar a una pregunta

Finalmente el perfil administrador tiene asignadas las tareas

de gestión de usuarios bien encapsulando el acceso a base de datos bien usando el protocolo LDAP.

Por lo que se refiere a las tecnologías utilizadas, la parte

cliente de la aplicación corre sobre un cliente Web bien en plataforma de sobremesa bien en plataforma móvil como PDA.

A su vez, para la implementación de la parte servidora se han utilizado principalmente las siguientes tecnologías: 1) Tomcat [10] como contenedor de Servlets y JSPs 2) OpenLDAP [11] como servidor LDAP 3) DOM [12] como API para el tratamiento de ficheros

XML.

V. FORMATO DE INTERCAMBIO DE DATOS Es importante que la información introducida al sistema

pueda reutilizarse en múltiples ediciones de un curso. Para ello se ha definido un formato de exportación en importación de preguntas siguiendo XML Schema que permita la validación del proceso. En la versión actual del desarrollo solo se permite el uso del tipo de pregunta de respuesta simple y de respuesta múltiple aunque se prevé insertar nuevos tipos en el futuro. No es el objetivo llegar a soportar al completo el estándar QTI [6] dado que el entorno de aplicación es distinto. Los sistemas ARS requieren una agilidad de respuesta que evita tipos de preguntas complejas. Por otra parte, el procesamiento en tiempo real de las opciones dadas lleva al despliegue de tipos de preguntas como los capturados en la aplicación aquí comentada.

El XML Schema utilizado por el sistema WSTIS es el mostrado gráficamente en la figura 4.

Fig. 4. XML Schema usado para el intecambio de datos.

Según puede observarse en el schema diseñado, la

estructura a seguir por el fichero XML que contiene la pregunta es la siguiente:

• El fichero debe estar compuesto por un enunciado y

unas opciones. • El enunciado debe contener una cadena de caracteres

y representa el texto de la pregunta. • A su vez, la parte de opciones debe contener un

conjunto de dos elementos opcion como mínimo. • Los elementos opcion deben contener un atributo

obligatorio correcta, que puede adoptar el valor ‘true’ o ‘false’. Para preguntas de respuesta simple solo se debe introducir una opción como correcta y para el caso de respuesta múltiple se permitirán varias opciones correctas

Un fichero XML de ejemplo con la estructura adecuada

es el que se muestra en la figura 5.

ISSN 1932-8540 © IEEE

MUÑOZ ORGANERO Y DELGADO KLOOS: DESARROLLO DE UN SISTEMA ARS 15

<?xml version="1.0" encoding="ISO-8859-15"?> <pregunta xmlns:xsi=…"> <enunciado> ¿Cuántos bytes debe tener como mínimo la cabecera IP? </enunciado> <opciones> <opcion correcta="true"> 20 bytes </opcion> <opcion correcta="false"> 30 bytes </opcion> <opcion correcta="false"> 40 bytes </opcion> </opciones> </pregunta> Fig. 5. Ejemplo de fichero de exportación de datos

El ejemplo muestra una pregunta con tres respuestas de

las cuales solo la primera es correcta. Los espacios de nombres han sido omitidos para mayor claridad del ejemplo.

VI. CASO DE USO El sistema WSTIS ha sido diseñado para satisfacer un

entorno de enseñanza que combina las clases presenciales con la enseñanza a distancia como es el caso de la Universidad Carlos III de Madrid. En la presente sección, describimos primeramente el marco impuesto por dicha universidad para pasar posteriormente a comentar un caso de uso concreto del sistema WSTIS dentro de una asignatura concreta que se imparte en dicha universidad combinando clases por videoconferencia y educación a distancia.

La universidad Carlos III de Madrid, por el tipo de enseñanza que realiza así como por su carácter innovador y tecnológico, constituye un escenario interesante de pruebas para el sistema ARS presentado (WSTIS). De hecho, el sistema WSTIS está siendo utilizado en experiencias piloto en el marco de dicha Universidad.

Desde el punto de vista de apoyo a la impartición de clases presenciales la Universidad Carlos III consta de unas aulas de teoría dotadas todas ellas con un PC de sobremesa para el profesor conectado a la red IP de la Universidad y con acceso a Internet. La imagen de la pantalla del PC puede proyectarse a los alumnos mediante un sistema de proyección instalado en la clase que a su vez permite la proyección de la imagen de un ordenador externo como puede ser un portátil o un tablet PC. Además, todas las aulas tienen cobertura WiFi abierta para todo el mundo para el uso de HTTP y restringida a profesores y alumnos mediante acceso con contraseña para el resto de protocolos (incluido HTTPS). La figura 6 muestra el aula de grados del Campus de Leganés de la Universidad Carlos III de Madrid. Su dotación en cuanto a los medios informáticos, de proyección y cobertura de red son los mismos que el resto de aulas docentes de la universidad.

Fig. 6. Aula de grados del Campus de Leganés de la Universidad Carlos III de Madrid

Desde el punto de vista de la enseñanza on-line, la Universidad Carlos III tiene abiertos varios frentes. El más importante es la herramienta de Aula Global que pone en red a disposición de alumnos y profesores capacidades básicas de interacción on-line como soporte a la docencia presencial. Esta herramienta está siendo re-evaluada en la actualidad y su futuro vendrá de la mano de plataformas como Moodle [13] o .LRN [14]. Por otra parte la Universidad Carlos III está participando en proyectos de tele-educación como el proyecto ADA-Madrid, financiado en sus orígenes por la Comunidad de Madrid, que imparte a distancia algunas de las asignaturas para alumnos de las 6 universidades públicas de la Comunidad de Madrid. Estas asignaturas, que son impartidas a distancia como se comentaba, constan por una parte de sesiones de videoconferencia en las que el profesor tiene conectadas 5 sedes remotas y una presencial y que son grabadas en la plataforma on-line para que los alumnos puedan verlas en diferido y por otra parte de una serie de herramientas para facilitar el seguimiento a distancia como documentación on-line, foros, comunicadores y tests de autoevaluación entre otros. El sistema WSTIS está pensado para su adaptación a este entorno permitiendo resolver problemas como el que surge en las sesiones de videoconferencia a la hora de que el profesor tenga conocimiento sobre el seguimiento de sus alumnos remotos a la vez que facilitando la participación de los mismos. También permite aprovechar y obtener información de los alumnos que realizan el seguimiento de la clase on-line en diferido a la vez que es un elemento motivacional para no ir dejando para el futuro el seguimiento de las mismas.

Precisamente, como caso de uso, se está utilizando el sistema WSTIS dentro de la asignatura de Sociedad Internet del programa ADA-Madrid. Esta asignatura utiliza Moodle [13] como sistema de gestión de contenidos para el aprendizaje a distancia en combinación, como se ha comentado en el punto anterior con sesiones por videoconferencia. Estas pueden ser seguidas en tiempo de impartición desde las 6 universidades que participan en ADA-Madrid o bien en diferido a través de la plataforma on-line una vez que la videoconferencia ha finalizado y se ha maquetado. La figura 7 muestra el despliegue de la asignatura

ISSN 1932-8540 © IEEE

16 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

en el sistema de gestión de contenidos on-line. La asignatura de Sociedad Internet consta de 60 alumnos

(10 de cada universidad participante). Estos alumnos provienen de titulaciones diversas, combinando titulaciones técnicas como informática, ciencias exactas como matemáticas o incluso de humanidades o ciencias sociales.

Fig. 7. Sistema de gestión de contenidos on-line

Las sesiones de videoconferencia permiten la interacción de

alumnos de 5 sedes remotas más los que asisten presencialmente al aula desde donde se imparte la misma con el profesor. La figura 8 muestra una captura de la señal emitida en la videoconferencia inaugural de la asignatura. Como puede apreciarse en la figura, la visión que el profesor tiene de lo que está ocurriendo en las sedes remotas es muy limitada, no permitiendo obtener una realimentación del grado de asimilación de los contenidos por parte de los alumnos remotos. El sistema WSTIS permite mejorar la interacción alumno-profesor. Usando este sistema el profesor obtiene en menos de 30 segundos respuestas de los alumnos, que le permiten conocer el grado de asimilación de estos. En ediciones anteriores de la asignatura la forma de obtener realimentación por parte de los alumnos era la realización de preguntas de viva voz que debían ser contestadas por turno por representantes en cada sede lo cual por una parte dificultaba el ritmo de impartición de la clase y por otra no ofrecía datos fiables pues las respuestas de alumnos que contestaban después se veían influidas por los que habían contestado antes. Por otra parte, un resultado interesante es el elemento motivacional que supone para el alumno que las respuestas de cada uno queden grabadas en la plataforma. Esto motiva al alumno a seguir la clase para acertar las preguntas. Finalmente, el hecho de que las sesiones queden grabadas permite que los alumnos que cursan en diferido la sesión de videoconferencia también puedan recibir en el momento apropiado las mismas preguntas y contestar a ellas de cara a que el profesor pueda evaluar su rendimiento en diferido. Esta funcionalidad no ha sido usada aún en esta experiencia pero se espera que su introducción motive también el seguimiento de las sesiones de videoconferencia en diferido.

Fig. 8. Utilización de WSTIS en sesiones de videoconferencia

VII. CONCLUSIONES En el presente artículo se ha presentado un sistema de

respuesta de audiencia adaptado tanto al apoyo a la docencia presencial como a la tele-enseñanza y que hemos denominado WSTIS. Se han capturado primeramente los requisitos que un sistema de enseñanza on-line introduce en un sistema de respuesta de audiencia. Estos requisitos tienen en cuenta tanto el soporte a la impartición de sesiones por videoconferencia como el acceso Web a la información en diferido. Se ha presentado posteriormente la funcionalidad del sistema WSTIS y las herramientas software utilizadas para su implementación. Se ha presentado el formato utilizado para la exportación e importación de información del sistema de cara a facilitar su reutilización entre varias ediciones de un curso o entre varios cursos. Se ha mostrado finalmente el escenario de pruebas y validación de la herramienta dentro de la Universidad Carlos III de Madrid.

El sistema WSTIS se ha optimizado para que la interfaz del alumno pueda visualizarse en PDA de cara a su utilización como soporte a la clase en tiempo de impartición. Presenta una interfaz Web que se puede fácilmente insertar en una herramienta de tele-educación.

El formato de preguntas soportado se ha centrado en preguntas tipo test que permiten su rápida respuesta y procesamiento, permitiendo al profesor recibir realimentación de las estadísticas globales de la clase casi instantáneamente.

La herramienta guarda estadísticas por alumno de cara a permitir al profesor contabilizar la participación de cada uno de ellos y a la vez fomentar la participación de los mismos.

AGRADECIMIENTOS Este trabajo ha estado parcialmente financiado por el

Programa Nacional de Tecnologías de la Sociedad de la Información mediante los proyectos TSI2005-08225-C07-01 y -02. El segundo autor agradece la ayuda recibida de la Secretaría de Estado de Universidades e Investigación del Ministerio de Educación y Ciencia durante su año sabático en el MIT, así como a Steve Lerman, Daniel Weitzner y Tim Berners-Lee, que le han acogido.

ISSN 1932-8540 © IEEE

MUÑOZ ORGANERO Y DELGADO KLOOS: DESARROLLO DE UN SISTEMA ARS 17

REFERENCIAS [1] Lowry, P.B.; Romano Jr., N.C.; Guthrie, R.; “Explaining and Predicting

Outcomes of Large Classrooms Using Audience Response Systems”. En Proceedings of the 39th Annual Conference on System Sciences, HICSS '06. Hawaii. Enero. 2006

[2] Petr, D.W.; “Experience with a Multiple-Choice Audience Response System in an Engineering Classroom”. En Proceedings de la 35th Annual Conference Frontiers in Education, 2005. FIE '05. Indianapolis, EE.UU. Octubre. 2005

[3] Casanova J. “An instructional experiment in organic chemistry, the use of a student response system”. Journal of Chemical Education, volumen 48 (7), pp. 453-455. Julio, 1971

[4] Brown J. D. “An Evaluation of the Spitz Student Response Systems in Teaching a Course in Logical and Mathematical Concepts”. Journal of Experimental Education, volumen 40 (3), pp.12-20. Junio 1972

[5] Grag D. P. “Experiments with a computerized Response System: A Favorable Experience”. Proceedings of the Conference on Computers in the Undergraduate Curricula, Fort Worth, Texas, EE.UU, 1975

[6] Baer, H., Muehlhaeuser, M., Tews, E. & Roessling, G. “Interaction During Lectures Using Mobile Phones”. En Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2005. Montreal, Canadá. Junio, 2005.

[7] Miguel Riesco Albizu, María de los Ángeles Díaz Fondón, “Sistema docente de realimentación inmedata en clases practices”. En actas de congreso Jornadas de Enseñanza Universitaria de la Informática. Madrid, España. Julio, 2005

[8] Koile, K. y Singer, D. "Development of a Tablet-PC-based System to Increase Instructor-Student Classroom Interactions and Student Learning." En Proceedings of WIPTE 2006, First Workshop on the Impact of Pen-based Technology on Education, Purdue University. EEUU. Abril, 2006.

[9] Liu, T., Kiang, J. K., Wang, H. Y., Chan, T. W., y Wei, L. H., “Embedding EduClick in Classroom to Enhace Interaction“. En Proceedings of the International Conference on Computers in Education, 2003. Hong Kong. China. Junio, 2003

[10] Proyecto de desarrollo software Apache Tomcat. Disponible en Internet en la dirección: http://tomcat.apache.org/. Última consulta el 12 octubre 2006

[11] Proyecto de desarrollo software OpenLDAP. Disponible en Internet en la dirección: http://www.openldap.org/software/download/. Última consulta el 12 octubre 2006

[12] El paquete de procesado XML DOM para Java. Disponible en Internet en la dirección: http://java.sun.com/j2se/1.4.2/docs/api/org/w3c/dom/package-summary.html. Última consulta el 12 octubre 2006

[13] Moodle, Sistema de gestión de cursos on-line. Disponible en Internet en la dirección: http://moodle.org/. Última consulta el 12 octubre 2006

[14] .LRN, Sistema de gestión de cursos on-line. Disponible en Internet en la dirección: http://www.dotlrn.org/. Última consulta el 12 octubre 2006

[15] Proyecto ADA-Madrid. Disponible en Internet en la dirección: http://adamadrid.uc3m.es/. Última consulta el 12 octubre 2006

[16] Boyle, J.; Nicol, D.; Hamilton, B.; Dempster, B.; “Experience with classroom feedback systems to enable socratic dialogue in large engineering classes” En Proceedings del IEEE Engineering Education 2002: Professional Engineering Scenarios Londres. Reino Unido. Enero 2002.

[17] Keng Siau; Hong Sheng; Nah, F.F.-H.; “Use of a classroom response system to enhance classroom interactivity”. En IEEE Transactions on Education. volumen 49 (3), pp. 398- 403. Agosto 2006.

Mario Muñoz Organero, obtuvo el título de Ingeniero de Telecomunicación en la Universidad Politécnica de Cataluña (UPC) en 1996, el título de Master en Administración de empresas (MBA) en la UNED en 2002 y el de Doctor Ingeniero de Telecomunicación en la Universidad Carlos III de Madrid en 2004. Actualmente es Profesor Titular de Ingeniería Telemática en la Universidad Carlos III de Madrid, y secretario académico del Master NEBCC, en esta misma universidad. Sus intereses incluyen las

tecnologías middleware para el m-learning, las arquitecturas ubicuas para el e-learning y las arquitecturas abiertas orientadas a servicios. Ha participado en numerosos proyectos de investigación entre los que destacan el proyecto E-LANE de eLearning, financiado por la Unión Europea, en el que participan 5 instituciones europeas y otras tantas latinoamericanas y el proyecto MOSAIC Learning de m-learning en el que participan 6 universidades españolas. Ha participado como miembro del comité de programa de varios congresos internacionales como el 2nd IEEE International Conference on Mobile Ad-hoc and Sensor Systems, el IEEE GLOBECOM 2005, el IEEE International Conference on Communications (ICC 2006) y el First International Symposium on Pervasive Computing and Applications (SPCA06). Entre sus responsabilidades anteriores destacan las tareas de consultoría y asesoramiento técnico al Ministerio de Ciencia y Tecnología, a Telefónica y a Lucent Technologies, la representación de Telefónica en el proyecto ETSI TIPHON, así como la secretaría académica del Master en Comercio Electrónico de la Universidad Carlos III de Madrid.

Carlos Delgado Kloos obtuvo el título de Ingeniero de Telecomunicación en la Universidad Politécnica de Madrid (UPM) en 1978 y el de Doctor en Informática de la Universidad Técnica de Múnich (Alemania) en 1986. Actualmente es Catedrático de Ingeniería Telemática en la Universidad Carlos III de Madrid, Director del Máster en Comercio Electrónico y del Master NEBCC en esta misma universidad. Sus intereses incluyen aplicaciones basadas en Tecnología Internet, tales como la publicación electrónica, la tele-

educación o el comercio electrónico. Ha liderado un buen número de proyectos de investigación tanto a nivel europeo, como nacional y bilateral (España-Alemania y España-Francia). Entre ellos cabe destacar que actua como coordinador del proyecto E-LANE de eLearning, financiado por la Unión Europea, en el que participan 5 instituciones europeas y otras tantas latinoamericanas. Ha publicado más de 120 artículos científicos en congresos y revistas nacionales e internacionales. Además ha escrito un libro y co-editado otros cuatro. Entre los cargos que ha ocupado u ocupa se encuentran los siguientes: Vice-presidente de la Junta Directiva Estatal de la Asociación de Técnicos de Informática, representante español comité técnico nº 10 y nº 3 de IFIP, secretario del grupo de trabajo nº 10.5 de IFIP, miembro del Consejo editorial de la revista ‘Formal Aspects of Computing’ publicada por Springer-Verlag, subdirector de Ingeniería de Telecomunicación en la Universidad Carlos III de Madrid, director del Departamento de Ingeniería Telemática en esta universidad, gestor del Programa Nacional de Tecnologías de la Información y las Comunicaciones en el Ministerio de Ciencia y Tecnología español y miembro de comités de programa de más de 70 congresos, entre los que cabe destacar la vicepresidencia del Comité de Programa del Congreso Mundial de Informática de IFIP en el año 1992 y la presidencia de los Comités de Programa de DATE 2002, Telecom I+D 2003, EduTech2004 y EUNICE2005. Pertenece a diversas asociaciones extranjeras y españolas, entre ellas IEEE en donde es miembro senior.

ISSN 1932-8540 © IEEE

18 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

ISSN 1932-8540 © IEEE

IEEE-RITA Vol.1, Núm.1, Nov. 2006 19

ISSN 1932-8540 © IEEE

Abstract— Engineering is defined as “the application of

scientific principles and knowledge to the systematic design and construction of devices, machines or systems of a certain economic value”. Often, the engineers instruct themselves on scientific knowledge applied to the design, but the phase of the construction is omitted. It is proposed in this article to use like developmental pattern a project on mobile robotics with the strategy of portfolio during a degree course or like final work. The students motivate themselves through the challenge to solve complex problems of the real world in a controlled framework.

Index Terms— Engineering education, Mecatronics, Mobile robotics.

I. INTRODUCCIÓN n proyecto de robótica móvil puede diseñarse como un

modelo que focaliza sobre los conceptos y los principios centrales de muchas disciplinas de la ingeniería, implicando a los estudiantes en tareas de solución de problemas, y culminando en productos realistas generados por el estudiante. Básicamente, para construir un robot [1] es necesario: un cuerpo físico (ingeniería mecánica), un microprocesador que controle el robot (ingeniería de control e informática), varios sensores que detecten el entorno (ingeniería electrónica), motores para actuar (ingeniería de control y eléctrica) y un programa que defina el comportamiento del robot (ingeniería informática). En suma, puede considerarse como un trabajo en mecatrónica.

Si existe una infraestructura mínima, el coste total de construir un robot móvil educativo es reducido, por debajo de los €80, ya que los componentes informáticos y electrónicos son baratos, la parte mecánica no tiene por qué ser extremadamente robusta, el software es libre de licencias en la mayoría de los casos, y son accesibles en línea numerosos tutoriales e información técnica.

Un proyecto de estas características, gestionado a través de un portafolio, favorece un aprendizaje multidisciplinario y modular, propone nuevas perspectivas de conocimiento respecto a la educación tradicional de una cierta disciplina y

Los autores forman parte del Departamento de Automática (ESAII) de la

Universidad Politécnica de Catalunya (e-mail: cecilio.angulo@ upc.edu). DOI (Digital Object Identifier) Pendiente

supone un método estructurado para que los estudiantes aprendan conceptos en una cierta profundidad. Además, estas estrategias realzan capacidades como el auto-aprendizaje (aprendiendo a aprender), la auto-gestión, la capacidad de innovación y otras habilidades de la vida real [2,3].

La estrategia del portafolio proviene del mundo empresarial y su uso en docencia se fecha en los años 90 del pasado siglo, con el objetivo de medir algunos aspectos y habilidades del aprendizaje que no son medibles a través de pruebas [4]. Además, ayuda al estudiante a un mejor uso y reflejo de los conocimientos, habilidades adquiridas, destrezas, etc. [5]. Experiencias similares a la aquí presentada están siendo también analizadas y desarrolladas con cierto éxito como instrumento docente habitual en diferentes áreas de conocimiento (Diseño Gráfico, Historia, Derecho) y universidades (Univ. Autònoma de Barcelona, Univ. Politècnica de Catalunya, Univ. de Barcelona) de nuestro contexto cercano [6,7].

En la Sección II se comentará en detalle el desarrollo del proyecto propuesto y su aplicación en el ámbito de la robótica móvil. En la Sección III se mostrará la metodología del uso del portafolio sobre el caso de estos proyectos de robótica móvil, mientras en la Sección IV se sintetizarán los resultados de las diversas experiencias llevadas a cabo. Finalmente, se presentarán conclusiones sobre el trabajo presentado.

II. PROYECTOS EN ROBÓTICA MÓVIL

A. Definición del proyecto La definición del proyecto es esencial para el éxito del

aprendizaje. Los proyectos que se proponen en este trabajo se adaptan a las características de cada estudiante mediante una complejidad y una profundidad del aprendizaje ajustable a la habilidad particular del alumnado. Además, se combina la teoría clásica con la tecnología más reciente como ejercicio para aprender sobre la evolución de técnicas en un área.

Para desarrollar la capacidad de diseño en modularidad de los estudiantes es necesario definir el proyecto no solamente como meta por sí mismo, sino como un complemento y punto de partida para otros. La cooperación es posible con un planeamiento inicial apropiado.

La figura del profesor varía a lo largo del proyecto. De inicio, su papel es el de un profesor estándar que establece

Construcción modular de robots móviles. Proyecto basado en portafolio para estudiantes

de grado Cecilio Angulo, Pere Ponsa y Cristóbal Raya

U

20 IEEE-RITA Vol.1, Núm.1, Nov. 2006

ISSN 1932-8540 © IEEE

claramente los objetivos del proyecto (con diversos grados de dificultad) y las especificaciones para permitir modularidad entre diversos proyectos al mismo tiempo o en diversas etapas. Los estudiantes, por su parte, expresan al profesor sus preferencias y se alcanza un acuerdo, de forma que ahora el profesor es su ingeniero-jefe y trabajan bajo su supervisión. Para evitar que el proyecto se aparte de las metas principales, se fijan ciertos hitos o plazos de tiempo. Los estudiantes mantienen entrevistas de forma regular con el profesor, quizá junto con otros estudiantes implicados en proyectos relacionados, y utilizan las herramientas y los recursos de forma autónoma. Finalmente, los estudiantes comienzan la construcción o la modificación del ingenio asociado al proyecto y a partir de este momento el profesor es considerado como un cliente o usuario que espera que el producto final cumpla con todas las especificaciones y objetivos marcados inicialmente. Así, las tareas asignadas al profesor son:

1. Como diseñador de objetivos: definir la meta, las condiciones de contorno y su división en un conjunto de hitos.

2. Como supervisor: seguir la evolución de cada hito y de la tarea global, así como la detección de comportamientos anómalos y sus correcciones.

3. Como cliente: comprobar la calidad del producto final, el ajuste del coste y del tiempo utilizado para construir el robot.

4. Como tutor: ayuda en línea, desarrollo de materiales didácticos, selección de bibliografía.

En cualquier caso, si el proyecto está bien definido desde el

principio con objetivos e hitos acordados muy claros, la figura del profesor no es crítica en este tipo de aprendizaje. El profesor puede proponer una metodología específica, pero es el estudiante quien debe contribuir con su conocimiento y autonomía personal. Es deseable alcanzar un equilibrio entre la rigurosa metodología, la imaginación y la artesanía. Es necesario, entonces, que el profesor anime las capacidades personales a lo largo de la tarea de elaboración del proyecto.

Para completar el proyecto de una manera profesional, se debe crear documentación que satisfaga el doble propósito de: demostrar avances y resultados del actual trabajo y facilite el desarrollo de módulos futuros basados en la estructura o componentes desarrollados.

B. Proyecto en robótica móvil Un proyecto integrado sobre robótica móvil es de interés en

la educación de la ingeniería por: 1) Contenido Competencial: Este método de trabajo permite

evaluar de una manera muy objetiva la capacidad de una futura ingeniera en la formulación de problemas, su desarrollo y la búsqueda de soluciones. Es necesario un esfuerzo de análisis para justificar sus elecciones y sintetizar conclusiones sobre los resultados obtenidos.

2) Condiciones Globales: Los estudiantes desarrollan un proyecto de principio a fin, ocupándose de todos los problemas desafiantes asociados. Esta forma de aprendizaje es didáctica porque existe una componente importante de motivación. Los estudiantes se ocupan de los contenidos de

una manera que les interesa y les es relevante. Por otra parte, para desarrollar un proyecto es necesario un período de búsqueda de información sobre los componentes a utilizar tanto en Internet o la biblioteca, como visitando minoristas y distribuidores, para obtener información directa y reciente, lo que favorece el desarrollo de “comportamientos sociales de ingeniería” fuera de la Universidad.

3) Resultados Positivos: Los estudiantes obtienen un resultado productivo al final del proyecto. Se crea, partiendo de un papel blanco, un dispositivo capaz de realizar tareas específicas.

Se alega en ocasiones que la construcción de un robot es una tarea muy dura, que requiere un buen equipo de investigadores en diversas disciplinas y una inyección importante de dinero. Esto no es así cuando la robustez no es un aspecto crítico en el desarrollo del robot. El objetivo final en esta clase de proyectos no es el robot móvil en sí mismo, sino el diseño, la fabricación y el proceso de evaluación del dispositivo, es decir, un objetivo educativo, lejos de desarrollos avanzados, pero quizás un estímulo para futuros investigadores.

Además es importante la diferenciación entre la robótica en la automatización industrial y la robótica móvil. La robótica industrial presenta una clasificación de estructuras mecánicas y un conjunto de aplicaciones industriales que son el resultado de más de 40 años de experiencia en esta área. La robótica móvil es un campo multidisciplinario que emerge con problemas sin resolver en el ámbito de la robótica autónoma [8]. Los expertos comparten diferentes visiones: desde un robot simple a un robot inteligente en el sentido de una criatura mecánica que puede trabajar de forma autónoma [9].

La Figura 1 muestra diferentes acercamientos al trabajo en robótica móvil: el Tipo I define la construcción de un robot, con la mecánica básica, una combinación interesante de sensores y comportamiento y sin el uso de la programación; el Tipo II también construye un robot con disposiciones mecánicas flexibles pero sólo un subsistema motorizado y no muchos sensores, mientras se mantiene una programación interesante de alto nivel; el Tipo III persigue trabajar sobre un robot base con los dispositivos mecánicos y electrónicos convenientes, y centrarse en el diseño de algoritmos sofisticados de control. Ninguna de las tipologías definidas se ajusta muy bien a un curso de grado, y por lo tanto se propone una alternativa en este artículo.

Los sensores con los que se dota al robot son elementos claves para integrar diversas disciplinas y definir un proyecto emocionante con objetivos claros según las preferencias y el background de los estudiantes. Por otra parte, el estudio de sensores permite a los estudiantes aprender y practicar muchos de los fundamentos prácticos de una manera motivadora, demostrándoles que las teorías clásicas son interesantes y útiles.

Se puede afirmar que en algunos casos es posible seguir una receta totalmente determinista para construir un robot móvil completo: diseño, integración de los sensores y actuadores, control electrónico, comportamiento y ambiente.

ANGULO, PONSA Y RAYA: CONSTRUCCIÓN MODULAR DE ROBOTS MÓVILES

ISSN 1932-8540 © IEEE

21

Este punto de vista presenta dos problemas específicos. El primero es el particular de cada diseñador, que supondrá un obstáculo para la integración del robot en un campo de trabajo genérico. El segundo es el comportamiento pasivo del estudiante, que actúa en modo de lazo abierto, en el sentido que él/ella sigue simplemente una lista de instrucciones.

Una forma de solucionar el primer problema es mirar más allá de la tarea de construcción de un robot. Otros trabajos son también necesarios, por ejemplo: un gráfico que muestre la evolución del robot móvil; una tabla comparativa entre diversos microcontroladores, motores, sensores; una discusión sobre el tipo de rueda a ser utilizada.

Para atacar el segundo problema, se debe de cambiar el comportamiento pasivo del alumnado en uno activo, en un proceso dinámico que permita trabajar en modo de lazo cerrado y facilite el mecanismo de aprendizaje. El papel del profesor en este punto es importante, pues su interacción con el estudiante condiciona el desarrollo de las actividades.

El estudiante debe definir un conjunto de opciones dentro de cada actividad y tomar una decisión razonada por sí mismo. Entonces, el profesor actúa como un subsistema de ayuda humano con respuestas cualitativas. El estudiante actúa como en una secuencia de decisiones ligadas (una decisión para cada uno de los hitos). Ésta podría no ser la manera óptima pero será en cualquier caso una manera razonada personal.

Esta compleja relación entre el profesor y el estudiante requiere realizarse dentro de un entorno físico de trabajo apropiado con las herramientas adecuadas [10]. El laboratorio en robótica móvil es una sala con espacio flexible dividido en dos zonas. La primera está dedicada al planeamiento de la tarea, la discusión de ideas, la formación inicial de estudiantes, los entornos multimedia, etc. La segunda área es el lugar de trabajo experimental típico con posibilidad para construir un robot móvil.

Finalmente, una lección aprendida es que son necesarios mecanismos docentes que reduzcan la distancia entre la manera académica de enseñar y el realismo industrial. Así, existen tres conceptos importantes a tratar durante el proyecto: el coste del robot, su robustez, y su mantenimiento. Existe una relación compleja entre estos conceptos. En la visión

académica tradicional, se asume que el robot móvil debe ser de bajo coste, robustez reducida, y alto mantenimiento, mientras que en la industria el coste y la robustez son más elevados y el mantenimiento se reduce casi a cero. Esta carencia de realismo es un problema sin resolver en la Universidad.

III. METODOLOGÍA Y GUÍA DEL PORTAFOLIO La construcción de un robot móvil desde un punto de vista

académico debe ser una mezcla inteligente de imaginación, de artesanía, y de método. La mayoría de tareas a realizarse se pueden manejar como metas independientes en un plan a largo plazo, el portafolio, y realizadas como un ejercicio de artesanía, donde el estudiante aplica el conocimiento aprendido y su autonomía. Por supuesto, el método debe ser lo bastante flexible como para adecuarse mejor a la enseñanza que a puros propósitos productivos, y debe ser entendido como una serie de etapas en una trayectoria difuminada hacia el objetivo final de conseguir un robot móvil funcional.

Acorde al propósito motivacional de la robótica móvil, se propone utilizar la metodología [11] mostrada en la Figura 2, donde cada etapa es modelada por un bloque cuadrado de tamaño proporcional al coste de tiempo de la tarea definida. Después de terminar ciertas tareas, se obtiene un conjunto de documentos o guías de puesta en marcha, para ser utilizados como entradas por las etapas subsecuentes del método.

A. Especificación Especificar un proyecto es la técnica de describir sin

ambigüedades todos los objetivos que se desean alcanzar, y las restricciones que se asumen. Una buena especificación aumenta de forma significativa la probabilidad de éxito de un proyecto, pero es una de las tareas más difíciles a realizar.

En el caso de robots móviles, los ítems que cualquier especificación al menos debería describir son: Comportamiento básico; Dimensiones globales; Peso máximo incluyendo carga; Nivel de autonomía: a corriente, baterías, tiempo de autonomía; Tipo de locomoción: ruedas, oruga; Tipo y forma del terreno de trabajo; Velocidad y aceleración máximas requeridas; Nivel de interacción con el entorno; Escalabilidad: diseño cerrado o posibilidad de módulos adicionales; Reusabilidad: un diseño ad-hoc difícil de reproducir, o un robot basado en componentes fácilmente replicables; Coste económico máximo.

La primera premisa para realizar una especificación es disponer de un mercado, es decir, un grupo objetivo que nos emplee para construir un robot móvil. Primero se debe escribir una especificación informal de lo que se supone el robot podrá hacer, y de lo que no. Este documento refleja en su escrito las prospecciones completas del estudiante para su robot futuro. Inicialmente, sobre un redactado no demasiado específico, el profesor discute con el estudiante unos requisitos mínimos de especificación. El resultado final es una especificación formal:

“Se desea construir un robot móvil con ruedas que reconozca sonidos ruidosos repentinos y capaz de moverse

Fig. 1. Diversos acercamientos a la Robótica Móvil.

BACKGROUND

MECÁNICA ELECTRÓNICA SOFTWARE

I BÁSICO MEDIO NINGUNO

II MEDIO BÁSICO MEDIO – BÁSICO

III NO DEFINIDO NO DEFINIDO ALTO

22 IEEE-RITA Vol.1, Núm.1, Nov. 2006

ISSN 1932-8540 © IEEE

hacia la fuente de sonido. Además, el robot debe ser capaz de reproducir algunas frases grabadas de antemano como ‘No oigo nada’ o ‘¿Quién está ahí?’ La estructura del robot tiene que estar contenida en unas dimensiones máximas de 15x15x15 centímetros, y debe poder llevar una carga máxima de 1 kilogramo. Se desea que el robot trabaje con baterías recargables permitiendo una autonomía mínima de 1 hora antes de recargar. El robot debe funcionar solamente sobre superficies duras y relativamente limpias como las de un edificio público típico, con pendientes máximas de 10º. El robot debe poder evitar colisiones peligrosas con el entorno en la dirección de su avance. Tiene que estar construid con módulos estandarizados, siempre que sea posible, y debe costar entorno a €100...”

B. Revisión del estado del arte De la primera versión de la especificación formal se extrae

un conjunto de palabras claves que ayudarán a realizar una revisión exhaustiva del estado del arte. La meta principal en esta fase es encontrar y analizar diseños de robots reales cercanos a la especificación acordada. La búsqueda tiene que ser restringida a centros de investigación y empresas comerciales de prestigio, y las fuentes de información son principalmente Internet, catálogos de vendedores, actas de conferencias y revistas especializadas.

En el estadio final, se realiza un análisis del estado del arte centrándose en los robots más cercanos a la especificación. Se resumirán las desventajas principales encontradas, las debilidades estructurales, limitaciones de la autonomía, precios elevados. Estas desventajas conformarán la discusión principal de la argumentación del proyecto, que de hecho es un proyecto de ingeniería y por lo tanto, teóricamente, una mejora sobre la competencia. Por otra parte, también se debe de adjuntar información técnica que se considere relevante para ayudar en el diseño final.

Tras la revisión del estado del arte, se modifica la especificación formal añadiendo aquellos nuevos objetivos o restricciones que se han encontrado interesantes.

C. Elección de una arquitectura La arquitectura base del robot móvil es el marco de trabajo

sobre el que se encajan todos sus componentes para alcanzar el comportamiento previsto. En un sentido más técnico, es un arreglo específico entre los componentes de software y de hardware que controlan el robot.

Desafortunadamente, los sistemas robóticos son complejos y difíciles de controlar pues integran muchos sensores y actuadores de una manera no muy clara, y por lo tanto el diseño de arquitecturas robóticas convenientes es más bien un campo importante de investigación que un tema propio de un grado. A pesar de esto, existen tres arquitecturas muy populares entre constructores de robots y por lo tanto muy documentadas y convenientes para propósitos académicos [12]: la arquitectura Sensar-Planificar-Actuar (con una unidad central de proceso que recibe todas las entradas sensorias y genera todas las salidas de los actuadores), la arquitectura de

Especificación Informal

Discusión

Especificación Formal

Especificación

Estado del Arte

Estudio Locomoción

Diseño de Alto Nivel

Estudio Arquitectura

Diseño de Alto Nivel

Elección Locomoción

Elección Alimentación

Elección Sensores

Requerimiento Energía

Elección Computación

CAD del Robot Global

Elección Chasis

CAD de Componentes

Diseños Mecánicos

Diseño Eléctrico Global y Prototipo

Construcción y Mecanizado de la

Plataforma

Circuitos Impresos

Ensamblado

Diseño Eléctrico y Prototipo de Módulos

Programación del Control a Bajo Nivel

Programación del Control a Alto Nivel &

Comunicaciones

Pruebas de Campo

Programación de la Aplicación Final

Análisis Económico

Escritura de la Documentación

Diseños

Eléctricos

Biblioteca

Documentación

Revisión

Fig. 2. Metodología de trabajo: la estructura modular del portafolio.

ANGULO, PONSA Y RAYA: CONSTRUCCIÓN MODULAR DE ROBOTS MÓVILES

ISSN 1932-8540 © IEEE

23

Subsumption [13] (una opción muy altamente reactiva sin procesador central alguno, y con un acople muy cercano entre los sensores y los actuadores), y la arquitectura de Tres-Capas (una mezcla entre las aproximaciones reactiva y deliberativa).

D. Elección de una configuración para locomoción La configuración de la locomoción describe el tipo y la

forma de los elementos de tracción, de la geometría del chasis, de los esquemas de actuación para conducir y dirigir, de la articulación y de la suspensión para los movimientos tridimensionales sobre el terreno [14]. Además, la configuración de la locomoción será determinante para la estabilidad (estática y dinámica) y la cinemática del robot. En esta fase los estudiantes aplican los conocimientos de mecánica para la ingeniería obtenidos en asignaturas de cuatrimestres precedentes, como por ejemplo ‘Sistemas mecánicos’ dentro del plan de estudios de la titulación de Ingeniería Técnica Industrial, especialidad en Electrónica Industrial.

Varios esquemas son posibles para la locomoción, pero la mayoría de ellos pertenecen al dominio de la investigación. Específicamente, dependiendo de la configuración elegida, algunas características de la cinemática serían muy difíciles o aún imposibles de calcular [15]. La configuración más conveniente en el caso general es la de dos ruedas motoras directrices fijas situadas diametralmente opuestas en paralelo, con hasta dos ruedas locas para propósitos de estabilidad. La conducción diferencial es el método más común para conseguir el cambio de dirección de estos robots.

E. Diseño de alto nivel para el robot completo Este paso consiste en la identificación de todos los módulos

que constituirán el robot completo, y de sus relaciones. Cada módulo tiene que ser una abstracción de una tarea específica a ser hecha, y las relaciones entre ellos son la abstracción del flujo de la información. El diseño de alto nivel es muy dependiente de la arquitectura elegida, y es así recomendable realizar un primer diseño aproximado justo después de seleccionar una arquitectura. Más adelante sobre la metodología, se terminará y refinará el diseño.

F. Selección de componentes Ahora que se ha dividido el robot en módulos se puede

iniciar una búsqueda exhaustiva de los componentes. Lejos de ofrecer un conjunto de componentes previamente seleccionado, el profesor debe inducir al estudiante a que visite a minoristas, telefonee distribuidores, etc. El estudiante aprende a leer e interpretar las hojas de datos técnicas, y a obrar en un aspecto importante del mundo de la ingeniería.

El primer elemento que se seleccionará y comprará son los motores porque son generalmente los elementos que consumen más energía en el robot y, por lo tanto, una vez elegidos determinan la energía máxima disponible para el resto de los componentes.

Se seleccionan después los sensores, incluyendo: sensores para alcanzar el comportamiento especificado (según la

aplicación en uso); sensores para alcanzar una navegación estándar (codificadores) y de seguridad (detectores de proximidad); y sensores proprioceptivos (detección del nivel batería, y quizás un sensor de corte de corriente).

Comenzando por el diseño de alto nivel, se pueden identificar todos los elementos de programación necesarios. Una buena práctica es no sobredimensionar las unidades de procesado para reducir al mínimo el consumo, y simplificar la programación. Una arquitectura más reactiva tiende a requerir varios microprocesadores de baja potencia, mientras que una más deliberativa necesita a menudo un microprocesador de consumo medio. En ambos casos, una cuestión crítica es la comunicación entre las unidades de procesado.

G. Cálculo de los requerimientos de energía El consumo de energía total es la suma de todos los

consumos de los componentes principales elegidos. Una práctica útil es proporcionar dos fuentes de energía separadas, una para alimentar los motores y otra para accionar la lógica de programa. Esta opción es fundamental si se sospecha que los motores añadirán mucho ruido electromagnético a su fuente de alimentación. Otra alternativa es utilizar una sola fuente de energía y generar diversos voltajes por medio de un convertidor DC-DC y filtrado.

El consumo real de energía más la especificación del nivel de autonomía guiará la búsqueda de una fuente de energía conveniente. A menudo, las características de la fuente seleccionada implicarán una revisión del diseño de alto nivel.

H. Dibujo asistido por ordenador, CAD Una vez que se han elegido todos los componentes

principales, deben ser medidos y dibujados mediante un software de CAD (mejor en formato 3D). En nuestros cursos se utiliza el clásico Autocad y se diseñan prototipos mediante Unigraphics. Cada elemento (baterías, motores, sensores, etc.) debe ser tratado en este paso como un componente aislado.

Los requerimientos mínimos que se deben lograr son: Acomodo robusto de todos los elementos principales; Acceso fácil a las zonas de mantenimiento, como el espacio de las baterías, los conectores de expansión, etc; Situación apropiada de los sensores de acuerdo a sus características funcionales; Garantizar la estabilidad del robot situando su centro de gravedad en un lugar adecuado.

Un esquema de la forma del robot puede ayudar en la determinación de las características de su centro de gravedad y de estabilidad. Tras ello, se debe dibujar el CAD del ensamblado de todos los componentes diseñados previamente en su forma definitiva. Así se llega a la forma provisional del robot (muy explícita si utilizamos un modelado 3D con capacidad de renderizado).

I. Diseño eléctrico y prototipaje En esta etapa será beneficiosa la técnica divide-y-vencerás

ya que se tienen que diseñar e implementar por separado los módulos de hardware identificados durante el diseño de alto nivel. El prototipo de cada módulo debe ser probado de forma exhaustiva, y sus entradas emuladas por medio de

24 IEEE-RITA Vol.1, Núm.1, Nov. 2006

ISSN 1932-8540 © IEEE

instrumentación electrónica. Al menos, es de esperar el diseño de: Alimentación a los motores de dirección; Interfase de los sensores; Gestión de la alimentación; Rutinas de control de bajo nivel sobre el microprocesador para dirigir los motores; Rutinas de servicio de interrupciones para el micro; Rutinas de comunicación en el micro.

Una vez que cada módulo es operativo, es hora de conectarlos todos juntos. Esto significa que se implementarán y probarán todas las comunicaciones entre los módulos. Debe realizarse un diseño eléctrico del robot entero, incluyendo ranuras de extensión y puertos de comunicación, y es posible que se necesite una revisión del CAD del robot completo.

J. Construcción de la plataforma completa Asumiendo que el CAD del robot completo es correcto, el

estudiante puede pasar a esta etapa con una pequeña ayuda del profesor. Se debe construir una plataforma física totalmente mecanizada a partir del CAD (la conclusión de un trabajo mecánico bien hecho), todos los módulos electrónicos tienen que ser implementados como circuitos impresos, y las conexiones entre ellos también. Una vez que se termine de montar y todos los componentes estén fijados y conectados correctamente, se dispondrá del robot completo en su forma definitiva.

K. Programación del control de bajo nivel Sea cual fuere la arquitectura elegida, existirá por lo menos

un actuador y un sensor, y cualquiera de ellos necesitará ser gestionado por elementos de cómputo. Se necesitará programación de bajo nivel para poder trabajar muy cerca del hardware. Típicamente, por lo menos el estudiante ha de programar un PWM para los motores (practicando así un campo muy orientado al mundo industrial), y la gestión de datos del sensor. Este paso es un ejercicio interesante de la programación de bajo nivel, donde se forzará al estudiante a trabajar probablemente con lenguajes tipo ensamblador, y deberá construir una biblioteca de control de bajo nivel.

L. Control de alto nivel y comunicaciones Para completar la gestión de todos los dispositivos de la

plataforma, y para asegurar características básicas de navegación, debe ser programado y agregado a la biblioteca del software un conjunto de rutinas de medio-a-alto nivel. Típicamente, habrá rutinas de control de velocidad y posición, y algún tipo de gestión del sensor más complejo que los de bajo nivel (como por ejemplo el uso de cámaras fotográficas para la visión por ordenador). Además, debe ser ejecutada y testada la comunicación entre los módulos hardware y también deben ser seleccionados los protocolos de transmisión de datos adecuados para el buen funcionamiento del robot.

M. Prueba Deben programarse varias aplicaciones de prueba

exhaustivas, incluyendo el uso de la biblioteca de software construida en etapas anteriores, y el acople y la comunicación de los módulos deben ser comprobados. Como resultado, se deberán obtener las características técnicas finales del robot.

N. Programación de la aplicación final Ahora que han sido probados todos los componentes de

hardware y de software, y se conocen las características del robot, es hora de lograr satisfacer todas las especificaciones definidas. El estudiante tiene que ocuparse de las aplicaciones en la programación de alto nivel, realizando un diseño y una puesta en marcha del software final que dé al robot su comportamiento previsto.

O. Análisis económico Debido al acercamiento ingenieril realista de este trabajo, se

hace esencial un estudio de mercado. Esto implica calcular el coste del desarrollo del primer prototipo del robot, y estimar el precio que una implementación comercial tendría. Además, es muy interesante realizar una prospección de clientes potenciales, y desarrollar una estrategia de venta basada en el estudio de la competencia, en una etapa avanzada.

P. Redactado de la Documentación Éste será el último esfuerzo para concluir la construcción de

un robot móvil. A pesar de la gran cantidad de trabajo requerida, la mayoría de la información ya se ha recogido: se ha escrito una especificación formal, se ha elaborado un estado del arte, y también los dibujos y los cálculos. Todo lo que resta es combinarlo en una manera clara, recopilando todo el trabajo anterior en un texto conciso y significativo. Por lo menos deben ser escritos tres documentos: la memoria del proyecto, un manual de usuario y un manual técnico.

IV. EXPERIENCIAS El primer banco de pruebas de la experiencia propuesta de

usar un portafolio en educación basada en proyectos fue sobre proyectos final de carrera en Ingeniería Técnica Industrial, especialidad en Electrónica Industrial, porque los estudiantes ya tienen un bagaje amplio de ingeniería y se espera que estén motivados para obtener su titulación. Por lo tanto, cuatro educadores en tres Escuelas diferentes, con sedes en Manresa (asignatura ‘Mecatrónica’), Vilanova i la Geltrú (asignatura ‘Robótica móvil’) y Terrassa (‘Tecnología de sistemas de control’), de la Universidad Politécnica de Catalunya han iniciado un conjunto de proyectos modulares sobre la construcción de robots móviles para evaluar la motivación generada en los estudiantes con esta herramienta didáctica. La meta es crear una línea conductora de trabajo que pueda satisfacer la curiosidad de los alumnos y que los integre en un grupo dinámico: su esfuerzo se basa en los trabajos de ex-estudiantes y el éxito de los proyectos futuros depende de su grado de precisión en realizar la documentación sobre objetivos alcanzados.

El comportamiento motivacional de la línea educacional propuesta fue comprobado durante cuatro semestres académicos, desde 2000/2001 a 2002/2003. Una vez verificada esta hipótesis motivacional, se iniciaron varias experiencias por separado, comenzando en el período académico 2002/2003 hasta la fecha, que han servido como ejercicio para probar la validez de los proyectos de robótica

ANGULO, PONSA Y RAYA: CONSTRUCCIÓN MODULAR DE ROBOTS MÓVILES

ISSN 1932-8540 © IEEE

25

móvil basados en portafolio como una herramienta vehicular en el proceso de aprendizaje de un espectro de estudiantes más amplio. Estas experiencias incluyen, (i) mini-proyectos breves; (ii) mini-proyectos durante un curso; (iii) proyectos finales de carrera; (iv) actividades del profesorado.

A. Mini-proyectos breves Consisten en trabajos específicos de tiempo limitado dentro

de la asignatura de ‘Robótica Móvil’ con un peso en la evaluación final cercano al 40%. Esta asignatura de 3 créditos LRU (2 h/semana, 15 semanas lectivas) se imparte de forma cuatrimestral. La meta perseguida es acentuar qué conocimiento adquirido permite a un estudiante de electrónica acercarse al campo de la robótica móvil y cuáles son las limitaciones. Estos trabajos han confirmado el alto grado de interés de los estudiantes, su poca preparación para el diseño mecánico y la necesidad de aumentar sus habilidades de trabajo en equipo. Se realizaron trabajos con robots basados en microprocesadores PIC16F84 y con robots educaciones LEGO Mindstorms.

B. Mini-proyectos durante un curso Una vez obtenidos resultados positivos con los primeros

mini-proyectos breves, se consideró formalizar de forma definitiva esta dinámica y desarrollar un curso entero que siguiera la herramienta didáctica del portafolio. Como experiencia concreta, el procedimiento educativo ha sido aplicado en la asignatura opcional de ‘Laboratorio de Sistemas de Control’ para los estudiantes de ingeniería técnica industrial, especialización en electrónica industrial, de la Universidad Politécnica de Catalunya en la sede de Vilanova i la Geltrú (EPSEVG). Esta asignatura de 3 créditos LRU se imparte de forma cuatrimestral. Los estudiantes disponen ya de un bagaje técnico importante en esta etapa que les posibilita para la realización de proyectos a escala pequeña. Inicialmente, el profesor expone los objetivos y pautas a seguir durante el curso, los estudiantes, en grupos de 3 personas, analizan los portafolios de módulos disponibles, eligen el contenido principal de sus proyectos y firman un acuerdo. Los proyectos se exponen al acabar el curso en una sesión oral pública con herramientas multimedia, y los estudiantes entregan el portafolio original, mencionando el material agregado y los informes técnicos anteriores actualizados. Sobre el formato del portafolio, se prefirió la realización de CDs o webs con informes en formato electrónico. A destacar en este sentido que los estudiantes valoran positivamente la evaluación de sus trabajos en el marco de la exposición oral y debate, ya que observan el trabajo efectuado por el resto de grupos y reciben críticas constructivas por parte de compañeros y profesores docentes de otras materias.

A continuación se expone una lista a modo de ejemplos ilustrativos de algunos de los trabajos diversos elaborados hasta el momento: Diseño de la mecánica de un robot móvil cumpliendo con ciertas especificaciones; Ensamblado de robots comerciales y su mejora para tareas específicas;

Desarrollo de un entrenador para microcontroladores; Contenidos multimedia de Robótica Móvil e Industrial [16].

La lista de experiencias se ha ido ampliando a lo largo de los años. En el marco del “buzón del profesor” de la asignatura ‘Automatización Industrial’ de ingeniería técnica industrial, especialidad electrónica industrial, se ha llevado a cabo la valoración de un total de 64 mini proyectos de diversos ámbitos de aplicación. La valoración pública actualizada en un enlace URL de la Universidad, no se analiza en profundidad por motivos de limitación de espacio [17].

Se ha comprobado que la dedicación a los proyectos excede en muchas ocasiones el tiempo inicial del acuerdo debido a que la acertada motivación del curso favorece que los estudiantes adquieran capacidades que de ser introducidas de otro modo podrían resultar no tan interesantes o hubieran podido ser consideradas distantes a su objeto de estudio, la electrónica industrial. En este sentido se ha optado por reducir el número de horas de impartición de conocimientos por parte del profesor, e incrementar las tareas de aprendizaje cooperativo por parte de los grupos de estudiantes en sesiones prácticas. Se pretende también ajustar el número de horas que el estudiante debe invertir fuera de las horas de clase y prácticas en el centro. Sin duda sería beneficioso aplicar el aprendizaje basado en proyectos sobre portafolios en asignaturas de 6 créditos LRU ya que sería una propuesta mucho más realista de la dedicación de tiempo que el estudiante debe aportar.

La evaluación se realiza en dos sentidos, una evaluación de equipo y una del esfuerzo individual, por medio de criterios cualitativos. Los estudiantes observan que la evaluación es continuada, la pueden comparar durante el curso con aquella que ellos considerarían adecuada y con la del trabajo del resto de grupos. El trabajo colectivo refuerza así los resultados de forma positiva y no se ha producido ningún tipo de crítica al sistema acordado de evaluación individual. En este sentido se ofrece realimentación de forma que el grupo o el estudiante en concreto puedan analizar qué pasos deben realizar para mejorar el rendimiento propio y el del grupo. A nivel de evaluación se considera la forma de presentar el trabajo, la originalidad del proyecto, la dificultad técnica, la capacidad de síntesis de los objetivos y propuestas, y la capacidad de resolver los problemas que pudieran bloquear la buena ejecución y finalización con éxito del proyecto. Un ejemplo numérico de la evaluación sería:

- forma (objetivos, planificación, calidad memoria): 10% - contenido (dificultad técnica, solución problemas): 30% - opinión (debate con profesor, mejora borradores): 10% - producto (calidad producto final tras proceso): 25% - defensa pública oral del proyecto: 25% Las sesiones orales públicas se han demostrado también

como un hecho positivo, pues se muestra la necesidad al futuro ingeniero de argumentar y defender de forma pública el proyecto realizado. Al tribunal se ha invitado a exalumnos del centro, a la responsable de biblioteca, al Director del centro.

26 IEEE-RITA Vol.1, Núm.1, Nov. 2006

ISSN 1932-8540 © IEEE

C. Proyectos Finales de Carrera Usados como experimentación inicial de la herramienta

motivadora, un proyecto muy ilustrativo desarrollado sobre tres proyectos finales de carrera es el del ‘Control del estado de carga de la batería de un microbot’, que enfatizó sobre la mejora del diseño de un robot móvil creado por un diseñador previo (concepto de modularidad), realizó un estudio en profundidad del uso de baterías en robótica móvil (estado del arte) y diseñó un paquete para usuarios de estudio de la vida útil de las baterías (mejora del portafolio). Desde el período 1998 hasta la actualidad, el número de proyectos del centro EPSEVG en el área de la robótica y la automatización se ha incrementado notablemente hasta el punto de ser merecedores de premios en la convocatoria de mejor proyecto final de carrera del centro EPSEVG en las ediciones de 2004 y 2005.

D. Actividades del Profesorado Los profesores implicados en el proyecto llevaron a cabo

actividades en paralelo con objeto de seguir y mejorar el desarrollo educacional del proyecto. En particular, el éxito de la experiencia motivó encuentros entre diferentes departamentos de ingeniería (Mecánica, Automática, Electricidad y Electrónica) en las Escuelas para extender la metodología a otros cursos (‘Mecatrónica’) y crear un curso interdisciplinario específico sobre ‘Robótica Móvil’. En la actualidad se trabaja en un proyecto de Mejora de la Calidad Docente en el área de introducción de metodologías activas en la ingeniería que ha culminado recientemente con la creación de las primeras jornadas de docencia del centro EPSEVG [18].

V. CONCLUSIONES La construcción de un robot móvil de complejidad baja-

media gestionado por medio de un portafolio es una forma excelente de integrar el conocimiento adquirido por los estudiantes de grado en diversas asignaturas no conectadas entre ellas de un currículum de ingeniería estándar. Además, es un trabajo muy adecuado para completar los conocimientos académicos más teóricos con un conjunto de apuntes industriales.

Se ha presentado una metodología basada en el sistema del portafolio que constituye una combinación equilibrada de imaginación, artesanía y metodología, persiguiendo conseguir unos resultados óptimos en la consecución de objetivos teniendo en consideración los recursos y tiempo limitados propios de la Universidad

AGRADECIMIENTOS Los autores quisieran dedicar este trabajo a la memoria del

profesor Carles Torrens, por su dedicación a este proyecto educacional y su conocimiento experto.

Este trabajo ha sido parcialmente realizado con el apoyo del proyecto ADA (DPI2006-15630-C02-01) del Ministerio de Educación y Ciencia de España.

REFERENCIAS [1] A. Ollero, Robótica. Manipuladores y robots móviles, Editorial

Marcombo, 2001. [2] D. F. Kjersdam, S. Enemark, The Aalborg Experiment, Project

Innovation in University Education. Aalborg University Press, 1994. [3] Student Portfolios: Classroom Uses. Office of Education Research

Consumer Guide, Nº 9, 1993. [4] V. Klenowski, Desarrollo de portafolios para el aprendizaje y la

evaluación, Nancea, S.A. de Ediciones, 2005. [5] C. Poyatos, “La evaluación alternativa de los aprendizajes”, Primeras

Jornadas de Docencia EPSEVG, Vilanova i la Geltrú, España, 2006. [6] Jornada d'Innovació Docent a la UAB. Bellaterra, España, 2005 [7] A. Font et al., “L'ús del portafoli electrònic en entorns semipresencials i

d'aprenentatge per problemes (Projecte CarpeTiki)”, 4t Congrés Int. de Docència Universitària i Innovació, Barcelona, España, 2006.

[8] J. Santos, R.J. Duro, “Evolución artificial y robótica autónoma”. Editorial Ra-Ma, 2005.

[9] R. R. Murphy, Introduction to AI Robotics. The MIT Press, 2000. [10] P. Ponsa, A. Català. “Actividades docentes en mecatrónica”, en XXII

Jornadas de Automática, Bellaterra, España, 2001. [11] C. Torrens, “Building a Mobile Robot as an Excellent Graduating

Exercise”, Workshop on Robotics Education and Training, Weingarten, Alemania, 2001.

[12] D. Kortenkamp et al. (ed), Artificial Intelligence and Mobile Robots, AAAI Press/The MIT Press, 1998.

[13] R. A. Brooks, “A Robust Layered Control System For A Mobile Robot”, IEEE Journal of Robotics and Automation, vol. 2(1), 1986.

[14] D. Apostopoulos, “Systematic Configuration of Robotic Locomotion”. Carnegie Mellon Univ. Tech. Rep. CMU-RI-TR-96-30, 1996.

[15] P. F. Muir, C. P. Neuman, “Kinematic Modeling of Wheeled Mobile Robots”, Carnegie Mellon Univ. Tech. Rep. CMU-RI-TR-86-12, 1986.

[16] P. Ponsa, J. Aranda, “Creación de un aplicativo multimedia en robótica” XXIII Jornadas de Automática, Univ. La Laguna, España, 2002.

[17] P. Ponsa, “Aplicación de la metodología PBL a materias de la titulación de Ingeniería Técnica Industrial, especialidad Electrónica Industrial, en “El buzón del profesor” de la Biblioteca de la UPC, 2005.

[18] J.A. Roman, P. Ponsa, “Primeras Jornadas de Docencia de EPSEVG”, Vilanova i la Geltrú, España, 2006.

Cecilio Angulo. Barcelona, España, 1969. Recibió la

Licenciatura en Matemáticas en 1993 por la Universidad de Barcelona y el título de Doctor en Ciencias por la Universidad Politécnica de Catalunya (UPC) en 2001. El objeto de su investigación es el aprendizaje estadístico con aplicaciones en sistemas de control. Es profesor lector en el Depto. de Ingeniería de Sistemas, Automática e Informática Industrial de la UPC.

Pere Ponsa. Barcelona, España, 1966. Recibió la Licenciatura en Ciencias Físicas en 1994 por la Universidad Autónoma de Barcelona y el título de Doctor por la Universidad Politécnica de Catalunya en 2003. Es profesor colaborador en el Depto. de Ingeniería de Sistemas, Automática e Informática Industrial de la UPC. Su investigación está dirigida al razonamiento cualitativo con aplicaciones en control de sistemas.

Cristóbal Raya. Vilanona i la Geltrú, España, 1972. Recibió el título de Ingeniería en Electrónica en 1999 por la Universidad Politécnica de Catalunya. En la actualidad es doctorando de la UPC. Es profesor colaborador en el Depto. de Ingeniería de Sistemas, Automática e Informática Industrial de la UPC. El objeto de su investigación son los elementos electrónicos con aplicación en computación ubicua y ambientes inteligentes.

IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006 27

Especificación Metodológica de la Implementación y Desarrollo de Entornos de

Experimentación Rafael Pastor, Member, IEEE, Roberto Hernández, Member, IEEE, Salvador Ros, Member, IEEE,

y Manuel Castro, Senior Member, IEEE.

Abstract—In engineering grades, the accomplishment of

experimental practices is limited to a real presence in the laboratory installations. Nevertheless, the development of remote environments has facilitated the use of experimental equipment outside the laboratory, avoiding the spatial and temporary barriers. There are so many initiatives that provides real interaction with the laboratory equipment, but no methodology exits that allows getting a unified vision of the development and access to these laboratories, that is to say, an specification of the experimental environment. This paper describes a specification proposal that relies about the definition of the laboratory components and the functionality of the experimentation environment in terms of these components. Using this approach, it will be possible to focus on the accomplishment of experiments and define them as reusable units of learning in an independent way. The component descriptions are defined in terms of XML tags and also a development framework is modelled in order to add tools for experiment designers and to provide a visual interaction with the laboratory.

Index terms—Remote experimentation, virtual and remote labs, XML, Engineering education, Interactivity, Web based education.

I. INTRODUCCIÓN RADICIONALMENTE la enseñanza de las asignaturas

de Ingeniería se ha caracterizado por un fuerte componente práctico en forma de laboratorios, que permite desarrollar y aplicar los conceptos teóricos que se asimilan en las clases presenciales. Es un hecho constatado que la evolución del concepto de enseñanza y la aplicación de dicho modelo a la educación a distancia demanda una metodología

educativa diferente a la empleada en la enseñanza presencial, una metodología específica concreta que establece la separación física real existente entre profesor y alumno. Esto es particularmente importante en carreras eminentemente prácticas, donde la ausencia del aula presencial provoca la búsqueda de nuevas soluciones que permitan la realización de actividades desde la distancia.

Rafael Pastor pertenece al Departamento de Informática y Automática de la

UNED, C/Juan del Rosal nº 16, 28040, Madrid, España (autor de contacto, Tel.: 34-91 398 83 83; e-mail: rpastor@dia.uned.es).

Roberto Hernández pertenece al Departamento de Informática y Automática de la UNED, C/Juan del Rosal nº 16, 28040, Madrid, España (e-mail: roberto@dia.uned.es).

Salvador Ros pertenece al Departamento de Informática y Automática de la UNED, C/Juan del Rosal nº 16, 28040, Madrid, España (e-mail: sros@dia.uned.es).

Manuel Castro pertenece al Departamento de Ingeniería Eléctrica, Electrónica y de Control de la UNED, C/Juan del Rosal nº 12, 28040, Madrid, España (e-mail: mcastro@ieec.uned.es).

DOI (Digital Object Identifier) Pendiente

Una de las principales herramientas de la enseñanza a distancia es la generación y uso de un entorno de aprendizaje que emule el funcionamiento real de un aula convencional: un conjunto de alumnos que puedan conversar entre ellos, asimilar los contenidos distribuidos oralmente por el profesor y discutir dichos contenidos entre ellos y/o el profesor. Para conseguir este objetivo se utiliza un tipo específico de elemento tecnológico denominado plataforma de e-learning, que agrupa al conjunto de estudiantes en torno al concepto de curso virtual. La interacción entre los estudiantes se realiza a través de foros de discusión y la asimilación de contenidos mediante la lectura del material que, habitualmente, se encuentra en un formato electrónico que el alumno puede descargar e imprimir. Así mismo, estas plataformas de e-learning disponen de un conjunto de herramientas que permiten la autoevaluación, o incluso la evaluación final, de los estudiantes y la creación de grupos de trabajo en torno a un objetivo docente específico.

Uno de esos objetivos docentes dentro de una disciplina eminentemente experimental lo constituye la realización de prácticas de laboratorio [1]-[2]. Sin embargo, en el modelo tecnológico de estas plataformas educativas se carece de los elementos y herramientas necesarias para dar soporte de forma directa a este objetivo. Una vez más, la solución que se propone es la emulación de dicho laboratorio, generando un entorno virtual de experimentación dotado de las características propias de un laboratorio real: 1) El alumno recibe el guión de las prácticas, indicándole las tareas a realizar y las actividades a seguir para finalizar la sesión experimental con éxito. 2) El estudiante dispone de un software específico en el laboratorio para la realización de la práctica, ejecutándose dicho software en un computador y visualizando algún tipo de interfaz gráfico que le permite interaccionar con el laboratorio.

T

ISSN 1932-8540 ©IEEE

28 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

3) Las prácticas se realizan en grupo. De esta manera los estudiantes pueden discutir, generar informes y preguntar dudas al instructor del laboratorio. 4) Al finalizar la práctica en el laboratorio, el grupo de trabajo debe entregar un informe conforme a un formato específico, que el instructor debe verificar para validar que la práctica se ha realizado de forma correcta.

Los puntos 1, 3 y 4 pueden resolverse mediante el empleo

de la misma plataforma educativa utilizada para la distribución de los contenidos teóricos y la realización de actividades de aprendizaje. Sin embargo, el punto 2 requiere un esfuerzo adicional por parte de los responsables de la materia a impartir ya que deben proporcionar al estudiante el mismo entorno visual de experimentación que se encontraría en caso de realizar la práctica de forma presencial. Dada la naturaleza del acceso a las diferentes plataformas de aprendizaje, la utilización de Internet como medio de distribución y acceso a la información del laboratorio se convierte en un factor clave en el desarrollo del entorno de experimentación a distancia.

A continuación se muestra una propuesta metodológica que aborda el desarrollo estructurado de software para la implementación de laboratorios en línea. En la sección II se definen las especificaciones deseables del entorno de experimentación y las posibles tipologías de los laboratorios experimentales en el ámbito de la experimentación a distancia (junto a los criterios de calidad medibles sobre los que se debe fundamentar el factor de éxito de la implementación del laboratorio). Una vez analizadas las características a desarrollar, en la sección III se describe el protocolo que define la metodología propuesta y que pretende implementar el conjunto de especificaciones anteriores. Para ello se define un esquema secuencial de desarrollo modular que emplea un lenguaje de definición para la estructuración en componentes de un laboratorio experimental. Dicho esquema está soportado por un marco de desarrollo que contiene las herramientas necesarias para interpretar la definición en componentes del laboratorio, además de dotarle de herramientas visuales para comprobar el correcto funcionamiento de la implementación software del laboratorio. Finalmente en la sección IV se presentan las conclusiones más importantes que se pueden extraer de los conceptos generales mostrados en las secciones II y III.

II. ESPECIFICACIÓN DEL ENTORNO DE EXPERIMENTACIÓN

A. Características del entorno Existen desarrollos de diferentes entornos experimentales

basados en Internet como los propuestos en [3]-[13] que, aunque ofrecen soluciones particulares, no engloban un conjunto de características básicas en el entorno de experimentación que deben usarse como opciones de diseño: 1. Facilidad de uso y comprensión. La interfaz gráfica del

entorno de experimentación debe ser amigable y haber sido probada con éxito en otros entornos de simulación disponibles como, por ejemplo, el presentado en [14].

2. El software empleado por el cliente debe ser multiplataforma. Puesto que el acceso al entorno de experimentación se hace a través de un navegador web, la interfaz de dicho entorno necesariamente debe estar compuesta por un applet 100% compatible Java. Los estudiantes sólo necesitan un navegador web con soporte Java para poder realizar el conjunto de experimentos disponibles desde el entorno de experimentación. No debe ser necesario otro software añadido a un navegador en particular, denominado plug-in, o software desarrollado a medida para el entorno de experimentación, tal y como ocurre en los trabajos de [3], [5], [6], [11], [15]-[19] entre otros.

3. Acceso universal al laboratorio mediante una aproximación orientada a la compartición de datos. El intercambio de información entre el servidor y el cliente se debería realiza mediante un protocolo ligero, en término de envío de datos, facilitándose así: a. Conocer el tipo de usuario que está empleando el

entorno de experimentación: alumno o profesor tutor. b. Enviar desde la interfaz gráfica del cliente parámetros

y datos que permitan modificar el comportamiento interno del laboratorio. Por ejemplo, en el caso de representar un laboratorio real con el entorno de experimentación, poder ubicar la ejecución del controlador asociado al experimento en el software del cliente y cerrar en lazo de control a través de Internet, de forma que se consiga una interacción real entre ambos entornos.

c. Gestionar el ciclo de control del entorno de experimentación. Por ejemplo, en el caso de representar una simulación con el entorno de experimentación, poder detener, comenzar, asignar un nuevo tiempo de muestreo a la simulación, etc.

Esta aproximación no es nueva, tal y como se propone en [20]-[21], pero en este caso el protocolo debe ser muy simple y ligero, reduciéndose a un conjunto de órdenes. Estos deben ser independientes del tipo de representación con la que se corresponda el entorno de experimentación, ya sea una simulación o un equipo didáctico real, lo que permite independizar el desarrollo de la interfaz gráfica del cliente del modelo de acceso al sistema representado.

4. Acceso en tiempo real al recurso representado por el entorno de experimentación. La interacción con el entorno de experimentación debe ser dinámica y tener realimentación en tiempo real de los eventos producidos en dicho entorno. Los usuarios no esperan sólo mover barras de desplazamiento, ejecutar el experimento y examinar los datos representados en gráficas y tener que repetir los pasos anteriores si se modifica algún dato. Durante la realización del experimento, cada cambio en las variables de entrada debe ser mostrada en la interfaz del entorno. Los usuarios podrán entonces supervisar en tiempo real cómo evoluciona el comportamiento del

ISSN 1932-8540 ©IEEE

PASTOR et al.: ESPECIFICACIÓN METODOLÓGICA

29

sistema de acuerdo a los valores de las variables interactivas que puedan modificarse.

5. Definición explícita de experimentos. Habitualmente, el entorno de experimentación se define en términos de qué variables pueden modificarse y cómo se presenta la interfaz gráfica del usuario en el cliente sin definir de una forma precisa cómo se deben realizar dichos cambios con el objetivo de conseguir algún fin, es decir, especificar lo que se pretende hacer en un experimento. El profesor debe ser capaz de añadir nuevos experimentos al entorno de experimentación con algún mecanismo simple como, por ejemplo, la utilización de ficheros de definición. De esta forma es posible crear diferentes experimentos: limitar las posibilidades de control presentes en la interfaz gráfica, adecuar el tiempo de experimentación a la ejecución real del experimento, cambiar el tiempo de muestreo, cambiar la estrategia de control, etc. Esta característica no está presente en los trabajos previos revisados, y proporciona una forma muy flexible de ajustar el entorno de experimentación a un curso de control en particular.

6. Generación de eventos de fallos en el entorno de experimentación. La mayor parte de los entornos de experimentación basados en Web sólo permiten introducir situaciones anómalas si existe una figura de supervisor que puede realizar un conjunto de acciones cuando un estudiante está llevando a cabo un experimento. Sin embargo, es deseable que dicho conjunto de acciones se pudieran programar para producir de manera automática los eventos adecuados que llevaran a situaciones anómalas y que fuera el entorno de experimentación el que supervisara la resolución de dichas situaciones anómalas. Un ejemplo de situación anómala es la presencia de perturbaciones en la planta o ruidos en las señales, por lo que se podría usar esta característica para validar en un experimento que el controlador diseñado por el estudiante sea capaz de responder de manera adecuada a dichas alteraciones.

B. Clasificación de los tipos de experimentos Todos estos factores de diseño deben ser comunes a los

diferentes tipos de sistemas de prácticas de laboratorio que se representan mediante el entorno de experimentación. Siguiendo las argumentaciones presentadas en [22], se pueden agrupar diferentes modalidades de laboratorios bajo dos criterios muy claros: la forma de acceso a los recursos sobre los que experimentar y la naturaleza del sistema sobre el que se opera. Atendiendo al primer criterio, se puede distinguir entre acceso remoto a través de una red y acceso local, es decir, que no es necesaria la presencia de una red de comunicación que permita interactuar entre sí a los diferentes componentes del laboratorio. Desde el punto de vista de la naturaleza del recurso se pueden distinguir entre modelos simulados y sistemas reales, es decir, plantas didácticas tradicionales ubicadas en el laboratorio. Al primer tipo de laboratorios se le denomina laboratorio virtual debido a que

no existe físicamente como tal y para el segundo tipo se emplea la denominación de laboratorio real. Existen otras clasificaciones que podrían usarse [23] donde se distingue el tipo de recurso en base a herramientas hardware o software.

Si se parte inicialmente del criterio por tipo de acceso, se pueden agrupar los diferentes entornos de experimentación en: 1. Laboratorio remoto. Se accede a través de Internet a un

sistema físico real para su manipulación directa. El software utilizado para el control remoto puede ser un navegador web o una aplicación que necesita ser descargada del servidor del laboratorio. En algunas ocasiones puede que sea posible su visualización e incluso audición en tiempo real.

2. Laboratorio virtual descargable. Utilizando un navegador se descarga un applet, un ActiveX o una aplicación que opera localmente con un recurso simulado. Es decir, la interfaz y el núcleo de simulación constituyen un único objeto. No se necesita la instalación de ningún entorno de simulación, salvo los correspondientes plug-in o run-time (por ejemplo, los componentes necesarios para ejecutar applets Java [24], interfaces remotas de Labview [25] o simulaciones SysQuake [26]). También se incluyen las aplicaciones ejecutables independientes.

3. Laboratorio virtual distribuido. El cliente utiliza una página HTML, un applet, un ActiveX o una aplicación para conectarse con un servidor en el que se encuentra todo el software de simulación. El cliente ejecuta exclusivamente la interfaz en su ordenador, estableciéndose un diálogo a través de la red entre la interfaz y el servidor de simulaciones.

4. Laboratorio virtual mixto. Es análogo al descargable pero necesita obligatoriamente que el cliente tenga instalado en su ordenador el entorno de ejecución de los componentes que se ejecutarán en la parte cliente y se conectan a través de un canal de comunicación propio con el entorno de ejecución de la parte servidora (por ejemplo, el caso de la herramienta Matlab/Simulink [27]).

Existe un último tipo que no se ha descrito en los cuatro

grupos anteriores y que se corresponde con el acceso local a un recurso local, que es lo que tradicionalmente se conoce como un laboratorio de prácticas en la educación presencial.

C. Criterios de calidad El interés fundamental de la realización de experimentos a

través de la red se centra en aquellos entornos de experimentación que se puedan aplicar de manera efectiva a la educación a distancia o a otras modalidades no ligadas al entorno educativo presencial, como servicios de formación a empresas comerciales. Un ejemplo claro de esto último se puede aplicar a la industria o a centros de investigación donde la teleoperación remota de dispositivos constituye una característica deseable en los entornos de trabajo de dichas instituciones. Este tipo de operación remota permite eliminar un conjunto de inconvenientes derivados del carácter distribuido de las empresas como es la adquisición de equipos

ISSN 1932-8540 ©IEEE

30 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

específicos en una localización, inaccesibles para el resto de centros de la compañía, y que se pueden compartir de manera remota con el conjunto global de ubicaciones de la empresa. Además, de esta manera se reducen costes asociados a los desplazamientos de técnicos y científicos al centro, además de aliviar los presupuestos de adquisición de dispositivos que se duplican con el objetivo de proporcionar la misma funcionalidad en diferentes centros. Este tipo de operación remota abre un mercado de servicios en el cual es posible alquilar el uso remoto de sistemas o dispositivos para obtener un rendimiento puntual, que de otra forma obligaría a adquirir el equipamiento necesario.

En cualquier caso, para facilitar el empleo de este tipo de entornos se deben satisfacer los siguientes criterios de calidad: 1. Facilidad de instalación y uso. Los entornos de

experimentación implementados deben poseer de manera inherente una manera sencilla e intuitiva de instalarse y de usarse, sin que esto obligue a perder calidad en el trabajo desarrollado por el alumno. Las herramientas del entorno deben paliar la ausencia del tutor presencial mediante el empleo de sistemas de comunicación bi-direccional entre el alumno, el tutor virtual y el resto de compañeros del aula.

2. Acceso a través de Internet. El empleo de Internet como medio de transmisión exclusivo para el acceso al entorno de experimentación implica que la única herramienta necesaria para un usuario, durante la realización de las prácticas, debe ser un navegador web.

3. Coste cero. Es muy importante que el uso del entorno de experimentación no obligue al usuario la compra o adquisición de ningún tipo de licencia software. El único gasto asociado al acceso y empleo del entorno debe ser debido a la forma de acceso a Internet, gasto que puede asumir el usuario desde su domicilio particular (soluciones ADSL o RDSI) o bien, en el caso de instituciones como la UNED, las aulas informáticas del centro asociado o los centros de cálculo equivalentes ubicados en el resto de universidades presenciales.

4. Interactividad y realismo. La sensación de realidad en la manipulación remota de un sistema, ya sea virtual o real, proporciona respuestas positivas por parte de los alumnos, lo que motiva el uso del entorno de experimentación como sustituto adecuado del sistema real. En el caso de un laboratorio remoto es muy relevante mostrar de manera audiovisual la evolución del sistema real y que cualquier acción realizada en el entorno de experimentación tenga una realimentación de información y un efecto visual en el entorno. Esta interactividad directa entre el entorno, el usuario y el sistema debe proporcionar una sensación de proximidad al sistema remoto.

5. Disponibilidad total. Los entornos de experimentación y el acceso a través de Internet permiten ofrecer al usuario una disponibilidad completa (las 24 horas del día, los siete días a la semana, etc.). Las únicas limitaciones que se deben imponer son las restricciones de acceso

simultáneo, únicamente en el caso de laboratorios remotos, al sistema físico real bien por realización de las prácticas bien por tareas de mantenimiento.

6. Robustez y fiabilidad. La disponibilidad del entorno de experimentación obliga a diseñar soluciones fiables que no fallen y que se puedan utilizar durante el tiempo de uso del experimento. Consecuentemente, la selección del laboratorio es muy importante ya que se debe buscar un sistema experimental autónomo que no necesite mantenimiento, o al menos, el mínimo posible.

III. METODOLOGÍA DE IMPLEMENTACIÓN Y DESARROLLO DE UN MARCO DE TRABAJO PARA EL ENTORNO EXPERIMENTAL A partir de las especificaciones descritas en el apartado

anterior surge de manera natural la idea de proponer e implementar una metodología de desarrollo unificada para entornos de experimentación, a partir de la utilización de recursos ya existentes o generados para tal fin. Para ello es necesario emplear una misma notación que permita describir los diferentes laboratorios o sistemas desde los que se tendrá acceso al entono de experimentación. Una vez que se dispone de una forma común de especificar el laboratorio es necesario proporcionar el conjunto de herramientas, denominado marco de desarrollo, que facilite la puesta en producción de dicho entorno en Internet. Dicho conjunto de herramientas debe poder integrar desarrollos de entornos de experimentación previos y facilitar el desarrollo de nuevos entornos, por lo que es necesario representar de manera precisa la correlación entre los recursos asociados al entorno de experimentación con sus respectivas entidades software: módulos software e interfaces gráficas de usuario. Además, es necesario incorporar de forma explícita el concepto de experimento, tanto a nivel de definición como de manipulación del entorno, de forma que sea posible definir el conjunto de actividades que se pueden realizar de forma secuencial dentro del experimento. Esto último es muy importante porque permite definir tareas de aprendizaje [28] y actividades de aprendizaje colaborativo [29] que se pueden integrar en diferentes plataformas de aprendizaje que soporten lenguajes de etiquetado educativo como IMS Learning Design [30]. Finalmente, el marco de desarrollo debe ser capaz de añadir enlaces de información contextual asociados a los experimentos que permitan explicar los principios básicos del entorno de experimentación o cualquier material de apoyo necesario.

Sin embargo, dotar al conjunto de desarrolladores del entorno de desarrollo, del lenguaje de especificación y de las herramientas adecuadas no garantiza el correcto uso de las mismas. Por lo tanto, es imprescindible especificar un procedimiento secuencial de uso de las herramientas, que es lo que realmente se puede considerar como metodología de implementación de entornos de experimentación.

En la Figura 1 se muestra el diagrama correspondiente al protocolo de trabajo presentado. A partir de un lenguaje de especificación del entorno se genera el entorno experimental mediante el uso de un marco de desarrollo que proporciona un conjunto de herramientas, etiquetadas como 1), 2), 3), 4) y 5)

ISSN 1932-8540 ©IEEE

PASTOR et al.: ESPECIFICACIÓN METODOLÓGICA

31

que se deben usar mediante un protocolo secuencial de trabajo.

De lo descrito anteriormente se deduce que se deben alcanzar los siguientes objetivos específicos para la propuesta de desarrollo metodológico: a) Definir un lenguaje de especificación que permita

describir de manera completa cualquier entono de experimentación, y que tenga en cuenta los factores de diseño comentados en el apartado anterior.

b) Proporcionar un marco de desarrollo de entornos experimentales formado por las herramientas necesarias que permitan interpretar una especificación del laboratorio, realizada con el lenguaje generado en el primer sub-objetivo, y permitir la ejecución de diferentes experimentos en el entorno.

c) Especificar un procedimiento de trabajo que defina cómo utilizar las diferentes herramientas para estandarizar el desarrollo de los entornos de experimentación.

Fig. 1. Diagrama de especificación de la metodología de desarrollo.

A. Especificación del laboratorio Para la especificación del laboratorio es necesario emplear

algún tipo de lenguaje neutro, en el sentido de independiente de la implementación, que permita describir de manera autónoma las diferentes estructuras que aparecen en un entorno experimental o laboratorio. En este caso se emplea un metalenguaje denominado LEDML (Laboratory Experimentation Description Language) basado en XML para la definición de cada laboratorio [31].

La parte conceptual más importante de LEDML consiste en identificar la división del laboratorio en sus diferentes partes constituyentes y definir las propiedades concretas de las etiquetas del metalenguaje de especificación. Por este motivo conviene analizar cuáles son los elementos más comunes en la definición de todo laboratorio. Se pueden dividir los componentes básicos de un laboratorio en:

I. Módulos. II. Vistas. III. Experimentos. IV. Referencias. Para clarificar la clasificación propuesta, a continuación se

describen los principios y conceptos que conllevan la definición de los componentes.

En primer lugar, en la implementación de cualquier laboratorio de ingeniería, ya sea virtual o real, se debe desarrollar un software específico que permita la comunicación entre el computador y el sistema, que, dependiendo del tipo de laboratorio, podrá ser un equipo didáctico o un modelo simulado. En cualquiera de los dos casos es necesario desarrollar el código que permita tanto obtener los valores de las magnitudes significativas del laboratorio como cambiar el conjunto de variables que puedan ser alterables como, por ejemplo en un laboratorio real, el porcentaje de apertura de la válvula que controla el caudal de líquido de entrada a un depósito. En todo caso, se puede ver a este software como una caja negra con distintos puertos de entrada y de salida que representa al sistema. Los puertos de entrada se usan para enviar los cambios en las magnitudes manipulables, mientras que los puertos de salida se emplean para observar el estado de las magnitudes de interés, mostrándose en algún tipo de interfaz gráfica creada para tal finalidad.

Una vez desarrollada la implementación, que se denominará interfaz software-sistema, normalmente, se pretende que sobre el laboratorio se ensayen una serie de estrategias de control. A tal efecto es necesario generar un nuevo componente, o reutilizar uno ya existente, para implementar la estrategia de control deseada. Las estrategias más usadas en los laboratorios, dada su sencillez, son el control manual y el control PID (Proporcional-Integral-Derivativo).

En el primer caso, el control manual, hay que facilitar mecanismos al usuario final, normalmente un estudiante, para que pueda cambiar alguna magnitud relacionada con el modelo físico y visualizar los resultados del cambio presentando algún gráfico. De esta manera sólo es necesario recurrir a la interfaz software-sistema. Si se considera el control PID, lo más habitual es implementar la estrategia PID, permitiendo al usuario definir qué magnitudes se pretenden controlar y sobre qué magnitudes se desea realizar la manipulación automática. Por supuesto, y si se considera necesario para el experimento, se deben poder cambiar los parámetros del controlador.

Desde un punto de vista práctico todo lo anterior se puede resumir diciendo que el trabajo esencial para desarrollar un laboratorio, ya sea virtual o real, consiste en escribir un conjunto de programas que de aquí en adelante se denominarán módulos, que encapsulen el software necesario para realizar una tarea específica dentro de la estructura del laboratorio. Por lo tanto, como mínimo será necesario escribir un módulo que implemente la interfaz software-sistema y tantos módulos como estrategias de control se ofrezcan en el laboratorio. Otra alternativa es la escritura de un único módulo monolítico que implemente la interfaz software-sistema junto con las estrategias de control que se ofrezcan. Las posibilidades a este respecto son ilimitadas.

Continuando con el ciclo de desarrollo de un laboratorio, el siguiente paso consiste en elaborar las interfaces gráficas que

ISSN 1932-8540 ©IEEE

32 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

se presentarán al usuario durante la interacción con el laboratorio. En este caso, se definirán las diferentes vistas, y se implementarán teniendo en cuenta que deben permitir el envío de cambios en las magnitudes manipulables asociadas a uno o varios módulos y la obtención de información sobre las magnitudes observables de esos mismos módulos.

Una vez que se ha desarrollado todo el software necesario para el acceso y manipulación del laboratorio, el paso final consiste en definir los experimentos. Estos experimentos necesitarán de la ejecución remota del software encapsulado en módulos y la presentación al estudiante de las interfaces gráficas que necesite para ensayar una estrategia de control determinada. Por tanto, los experimentos representarán los diferentes ensayos que se hayan definido para las estrategias de control con que se pueda trabajar en el laboratorio.

Finalmente, es necesario proporcionar las guías y ayudas que el estudiante necesita, recurriendo para ello a hipervínculos de información que se denominan referencias. De esta manera, se permitirá el acceso de los estudiantes a la documentación necesaria que les enseñe a usar de forma correcta el laboratorio.

<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE system SYSTEM "http://lab-virtual.dia.uned.es/related/dtd/ledml.dtd"> <system name="RANDOM_GENERATOR" type="0"> Produces random data for test <module name="GENERATOR_MODULE"> <var name="max_value" type="double" initial="10" max="10000" min="0" units="N/A">max random value</var> <var name="min_value" type="double" initial="0" max="-10000" min="0" units="N/A">min random value</var> <var name="value1" type="double" initial="0" max="10000" min="-10000" units="N/A">random value 1</var> <var name="value2" type="double" initial="0" max="10000" min="-10000" units="N/A">random value 2</var> <var name="value3" type="double" initial="0" max="10000" min="-10000" units="N/A">random value 3</var> <var name="value4" type="double" initial="0" max="10000" min="-10000" units="N/A">random value 4</var> <implementation type="JAVA" jarfile="file:///D:\users\rafa\RLAB_Xml\RLAB\modules\Ejemplo\ModuloGenerador.jar" classname="es.uned.dia.related.modules.ejemplo.Generador"> Run the module for random data</implementation> </module> <experiment name="Test" sampleTime="1000"> Test <duration type="User"/> <run name="GENERATOR_MODULE"> <interactives names="max_value,min_value" show="true,true"/> <paint names="value1,value2,value3,value4" colors=" blue,red,yellow,pink"/> </run> </experiment> </system> Fig. 2. Ejemplo de definición de componentes de un laboratorio.

En la figura 2 se muestra un ejemplo de definición de un

laboratorio mediante etiquetas del metalenguaje LEDML. El laboratorio representa un generador de números aleatorios que expone cuatro variables (value1, value2, value3, value4) cuyo valor se genera de manera aleatoria entre los palores

max_value y min_value. La generación de los valores se realiza cada segundo dentro del módulo GENERATOR_MODULE. En este fichero de especificación se define un experimento llamado Test que permite verificar el funcionamiento del módulo GENERATOR_MODULE y muestra gráficamente (etiqueta <paint>) la evolución temporal de las cuatro variables. Es el ejemplo que se distribuye con el marco de desarrollo y que permite verificar que el funcionamiento correcto del marco.

B. Marco de desarrollo El marco de desarrollo proporciona un conjunto de

funcionalidades a través de unas herramientas software que permiten el acceso al laboratorio y cuyos objetivos son las siguientes: 1) Validar y leer la especificación LEDLM del laboratorio. 2) Proporcionar métodos de acceso remoto al laboratorio. 3) Posibilitar la utilización de diferentes interfaces gráficas

que permitan un uso sencillo del acceso remoto. 4) Proporcionar mecanismos de monitorización. 5) Facilitar un servicio de búsqueda de laboratorios y

experimentos integrados en la red de entornos de experimentación.

Las herramientas que se facilitan con el marco de desarrollo

realizan las siguientes funciones: 1. Visualizar la estructura del laboratorio y realizar

acciones sobre el mismo. El applet de experimentación permite visualizar los componentes definidos mediante la especificación. En la figura 3 se muestra el applet de experimentación y, tal y cómo se puede apreciar en dicha figura, contiene una vista jerárquica de los componentes definidos en el fichero de especificación LEDML. Además permite realizar una sesión experimental seleccionando el experimento, presentándose al inicio del mismo aquellas vistas que sean necesarias para realizar la manipulación del laboratorio virtual o remoto. El applet se presenta cuando se accede al entorno de experimentación y permite ejecutar los diferentes experimentos definidos en el fichero de especificación y adicionalmente permite comprobar la estructura modular del laboratorio especificado. Cuando se comienza la ejecución de un experimento se presentan las vistas indicadas en la especificación del experimento, lo que permite la interacción entre el usuario y el laboratorio en el escenario experimental definido. En el caso de la figura 3 se muestra la estructura de un laboratorio correspondiente a un motor de corriente continua donde existen varios escenarios de control: manual, control de velocidad en lazo abierto y en lazo cerrado y control de posición en lazo abierto y lazo cerrado.

2. Visualizar la información del experimento. Esto se realiza mediante las propias vistas definidas como componentes propios, mediante el componente de variables interactivas (que permite modificar las variables del experimento en curso, véase la figura 4) y

ISSN 1932-8540 ©IEEE

PASTOR et al.: ESPECIFICACIÓN METODOLÓGICA

33

mediante el componente de gráfico de tendencias, que representa la evolución temporal del experimento, tal y como se muestra en la figura 5. El componente de variables interactivas permite una manipulación simple de las variables definidas en los módulos de laboratorio. Se puede apreciar en la figura 4 que se indica el tipo y nombre de variable a la izquierda y se proporciona un editor del valor a la derecha (en este caso al ser un número de tipo double, una caja de texto). La evolución temporal de las variables de los módulos involucrados en un escenario experimental se muestran en el gráfico de tendencias. En la figura 5 se presenta la evolución de los valores de las variables definidas en el fichero de especificación de la figura 2 durante la ejecución del experimento Test. Para usar esta herramienta basta con declarar que variables se desean representar en el experimento mediante la etiqueta <paint>.

Fig. 3. Applet de experimentación.

Fig.4. Componente de variables interactivas.

Fig.5. Componente de gráfico de tendencias.

C. Protocolo de desarrollo de un entorno de experimentación Los pasos del procedimiento son los siguientes: 1. Definición de la conducta estática del laboratorio en

términos de variables y parámetros. Se debe realizar un trabajo de clasificación de estas variables para agruparlas en conjuntos con una funcionalidad o método de acceso similar. Por ejemplo, las variables de estado de un motor de corriente continua se leen mediante la correspondiente tarjeta de adquisición de datos, mientras que las variables del controlador serán accesibles desde el código software que lo implementa.

2. Programación de módulos. Para cada de grupo de variables y parámetros definidos en el paso anterior se desarrolla el módulo adecuado. El administrador del sistema puede optar para cada módulo por una implementación nativa o Java para su posterior programación, posiblemente reutilizando código ya desarrollado. Por lo tanto, por cada grupo de variables se debe implementar un módulo.

3. Desarrollo de las vistas. Las distintas ventanas gráficas ayudan a describir y entender de forma visual la conducta dinámica del sistema, por lo que constituyen una pieza fundamental en la construcción del laboratorio.

4. Tarea de documentación. Los resultados de la misma son documentos HTML (o cualquier URL válida) que se incluyen en el sistema como referencias.

5. Definición de la conducta dinámica del sistema. En primer lugar el administrador decide qué propiedades del sistema pueden ser manipuladas por los usuarios. A continuación se deben definir los experimentos empleando los módulos disponibles en el entorno y todos aquellos accesibles en otros laboratorios. Finalmente, se define la duración del experimento y las distintas conexiones de puertos de entrada y salida entre los módulos que se ejecutarán en el experimento.

ISSN 1932-8540 ©IEEE

34 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

IV. CONCLUSIONES El uso de la metodología estructurada de desarrollo

propuesta permite definir y clasificar el conjunto de experimentos que se pueden ofrecer en línea a través de diferentes entornos de experimentación. Esta clasificación proporciona un método para globalizar la totalidad de los experimentos ofertados dentro de una red de laboratorios, a la vez que permite agruparlos por funcionalidades.

Además, de la propia separación de tareas del protocolo de trabajo se deduce que la realización independiente de las vistas y módulos produce modelos de reutilización de software que presentan beneficios inmediatos de disponibilidad de los componentes a otros desarrolladores de laboratorios en línea. Se pueden reutilizar tanto el software de los módulos como las interfaces gráficas o vistas, por ejemplo las mostradas en las figuras 6 y 7, que fueron desarrolladas para un entorno de experimentación con actividades de manipulación sobre un motor de corriente continua [32]. Para dicho laboratorio se empleó como herramienta de desarrollo el software Easy Java Simulations [33] que permite reutilizar los modelos de simulación que se preparan en la propia herramienta y las interfaces gráficas, como la mostrada en la figura 6, dentro de un entorno Java. La vista representa la posición del motor (en rojo) y la evolución de dicha posición, y se puede reusar para cualquier tipo de motor de características parecidas. Por otra parte se pueden emplear técnicas de programación de interfaces para desarrollar componentes de presentación de video en tiempo real, como la mostrada en la Figura 7, que permiten dar una sensación de realidad y usabilidad a la teleoperación de un laboratorio real.

De esta manera si se genera un repositorio central con control de versiones que permita agrupar y catalogar los componentes reutilizables de vistas y módulos se pueden acelerar los tiempos de desarrollo de los proyectos que tengan como objetivo final la elaboración de un laboratorio en línea empleando el protocolo propuesto, sin más que añadir las líneas de descripción LEDML correspondientes.

. Fig.6. Vista virtual del entorno de experimentación desarrollado para el caso del motor de corriente continua.

Fig. 7. Vista virtual del entorno de experimentación desarrollado para el caso del motor de corriente continua.

AGRADECIMIENTOS Este trabajo ha sido subvencionado por la CICYT

(Comisión Interministerial de Ciencia y Tecnología) bajo el proyecto DPI2004-05903.

REFERENCIAS [1] R. Pastor; Especificación Formal de Laboratorios Virtuales y Remotos:

Aplicación a la Ingeniería de Control. Tesis doctoral, UNED, 2006. [2] S. Dormido; F. Torres, Algunas consideraciones sobre las TIC’s y la

educación en Automática. Revista Iberoamericana de Automática e Informática Industrial, vol. 2, nº 2, pp. 3-7, 2005.

[3] A. Leva, A simple and flexible experimental laboratory for automatic control courses. Control Engineering Practice, vol. 14, nº 2, Feb. 2006, pp. 167-176.

[4] K. Arzen, A. Blomdell and B. Wittenmark, Laboratories and Real Time Computing. Control Systems Magazine, Vol. 25, nº 1, Feb. 2005, pp. 30-34.

[5] J.A. Asumadu, R. Tanner, J. Fitzmaurice, M. Kelly, H. Ogunleye, J. Belter, S.C. Koh, A Web-based electrical and electronics remote wiring and measurement laboratory (RwmLAB) instrument. IEEE Transactions on Instrumentation and Measurement, Vol. 54, nº 1, Feb. 2005 , pp. 38–44.

[6] L. Gomes, A. Costa, Remote laboratory support for an introductory microprocessor course. Proceedings of the IEEE International Conference on Microelectronic Systems Education, 12-14 Junio 2005 pp. 21–22.

[7] S.C. Sivakumar, W. Robertson, M. Artimy, N. Aslam, A web-based remote interactive laboratory for Internetworking education. IEEE Transactions on Education, Vol. 48, nº 4, Nov. 2005, pp. 586–598.

[8] A. Valera, J.L. Diez, M. Valles, P. Albertos, Virtual and remote control laboratory development. IEEE Control Systems Magazine, Vol. 25, nº 1, Feb. 2005, pp: 35–39.

[9] G. Viedma, I.J. Dancy, K.H. Lundberg, A Web-based linear-systems iLab. American Control Conference 2005. Proceedings of the 2005. 8-10 Junio 2005 pp. 5139-5144.

[10] M. Basso, G. Bagni, ARTIST: a real-time interactive Simulink-based telelab. IEEE International Symposium on Computer Aided Control Systems Design, 2004. pp. 196–201.

[11] M. Casini, D. Prattichizzo, A. Vicino, The automatic control telelab. IEEE Control Systems Magazine. Vol. 24, nº 3, Jun. 2004 pp. 36–44.

[12] F. Cennamo, F. Fusco, M. Inverno, A. Masi, A. Ruggiero, A remotely controlled measurement system for education and training of experiments in wind tunnel. Instrumentation and Measurement Technology Conference, 2004. IMTC 04. Proceedings of the 21st IEEE. Vol. 2, 18-20 May 2004 pp. 991-995.

[13] M. Casini, D. Prattichizzo, and A. Vicino; The automatic control telelab: A user-friendly interface for distance learning. IEEE Trans. Educ., vol. 46, nº 2, pp. 252–57.

ISSN 1932-8540 ©IEEE

PASTOR et al.: ESPECIFICACIÓN METODOLÓGICA

35

[14] J. Sánchez, F. Morilla, S. Dormido, J. Aranda, P. Ruipérez, Virtual control lab using Java and Matlab: A qualitative approach. IEEE Control Systems Magazine, vol. 22, nº 2, 2002, pp. 8-20.

[15] A. Ferrero, S. Salicone, C. Bonora, and M. Parmigiani; ReMLab: A Java-based remote, didactic measurement laboratory. IEEE Trans. Instrum. Meas., vol. 52, no. 3, pp. 710–715, Jun. 2003.

[16] J.W. Overstreet and A. Tzes; An Internet based real-time control engineering laboratory; IEEE Control Systems Magazine, vol. 19, no 5, pp. 19-34, Oct. 1999.

[17] C. Schmid; A Remote Laboratory Using Virtual Reality on the Web. Simulation, Vol. 73, nº 1, pp. 13-21, Jul. 1999.

[18] W. Sheng, L. Choo-Min, and L. Khiang-Wee. An integrated Internet based control laboratory. IFAC/IEEE Symposium on Advances in Control Education, Gold Coast (Australia), Diciembre 2000.

[19] K. Ling, Y. Lai, and K. Chew,; An online Internet laboratory for control experiments. IFAC/IEEE Symposium on Advances in Control Education, Gold Coast (Australia), Diciembre 2000.

[20] D. Gillet, H. A. Latchman, Ch. Salzmann, and O. D. Crisalle; Hands-On Laboratory Experiments in Flexible and Distance Learning. Journal of Engineering Education, pp.187-191, Abril 2001.

[21] D. Gillet, C. Salzmann, and P. Huguenin; A Distributed Architecture for Teleoperation over the Internet with Application to the Remote Control of an Inverted Pendulum. Libro “Lecture Notes in Control and Information Sciences 258: Nonlinear Control in the year 2000”, vol. 1, pp. 399-407, Springer-Verlag, London, 2001.

[22] J. Sánchez. Un nuevo enfoque metodológico para la enseñanza a distancia de asignaturas experimentales: Análisis, Diseño y Desarrollo de un laboratorio virtual y remoto para el estudio de la automática a través de Internet. Tesis doctoral, UNED, 2002.

[23] Luís Anido, Martín Llamas, Manuel J. Fernández. “Internet-based Learning by Doing”. IEEE Transactions on Education. ISSN 0018-9359. Vol. 44, No. 2. CD-ROM Folder 17. May, 2001.

[24] http://java.sun.com/ última consulta noviembre de 2006. [25] http://www.ni.com/labview/ última consulta noviembre de 2006. [26] http://www.calerga.com/products/Sysquake/index.html última consulta

noviembre de 2006. [27] http://www.mathworks.com/ última consulta noviembre de 2006. [28] D. Edelson, R. Pea and L. Gomez; Constructivism in the Collaboratory.

In B. G. Wilson (Ed.), Constructivist learning environments: Case studies in instructional design, (pp. 151-164). Englewood Cliffs, NJ: Educational Technology Publications.

[29] E. Gaudioso, J.G. Boticario; Towards web-based adaptive learning communities. Proceedings of the 11th International Conference on Artificial Intelligence in Education. Sidney, Australia, Julio 20-24, 2003 (http://www.ia.uned.es/~elena/publi.htm#internacionales).

[30] http://www.imsglobal.org/learningdesign/index.html última consulta noviembre de 2006.

[31] R. Pastor, J. Sánchez, S. Dormido; Related: a framework to publish web-based laboratory control systems. First IFAC Workshop on Internet Based Control Education (IBCE’01). Diciembre de 2001, Madrid, España.

[32] R. Pastor, C. Martín, J. Sánchez and S. Dormido; A XML framework customization for a servo motor web-based laboratory. Conferencia Anual del Instituto Americano de Ingenieros Químicos (AIChE). San Francisco, CA, Nov. 16-21, 2003.

[33] http://www.um.es/fem/Ejs/ última consulta noviembre de 2006

Rafael Pastor es Doctor en Ingeniería Informática y Titular de Escuela Universitaria. Es Director de Innovación del Centro de Innovación y Desarrollo Tecnológico (CInDeTec) de la UNED, dónde desarrolla labores de transferencia de conocimiento sobre plataformas educativas. Ha participado en varios proyectos de investigación como investigador asociado así como ha dirigido proyectos PROFIT del Ministerio de Industria, Comercio y Turismo. Además ha

publicado en revistas y congresos, tanto nacionales e internacionales. Es miembro de la Sociedad de Educación de IEEE y Member del IEEE.

Roberto Hernández Berlinches es Doctor en Ciencias y Titular de la Escuela Técnica Superior de Ingeniería Informática de la UNED. Ha participado en numerosos proyectos de investigación como investigador y ha publicado en revistas y congresos, tanto nacionales e internacionales. Además, ha publicado diversos libros y material multimedia dentro de sus líneas de investigación y docencia. Es miembro de la Sociedad de Educación de

IEEE y Member del IEEE.

Salvador Ros es Licenciado en Ciencias Físicas y Titular de Escuela Universitaria de la ETSII de la UNED. Actualmente es Director de Tecnologías Educativas del Centro de Innovación y Desarrollo Tecnológico (CInDeTec) de la UNED. Ha participado en numerosos proyectos de investigación como investigador y ha publicado en revistas y congresos, tanto nacionales e internacionales. Ha publicado igualmente diversos libros y

material multimedia dentro de sus líneas de investigación y docencia. Es miembro de la Sociedad de Educación de IEEE y Member del IEEE.

Manuel Castro es Doctor Ingeniero Industrial y Catedrático de Universidad. Ha sido Vicerrector de Nuevas Tecnologías de la UNED, así como Subdirector de Ordenación Académica y de Investigación en la Escuela de Ingenieros Industriales de la UNED, y Director del Centro de Servicios Informáticos de la UNED, siendo actualmente Director de Departamento. Ha participado en numerosos proyectos de investigación como investigador,

coordinador y director y ha publicado en revistas y congresos, tanto nacionales e internacionales. Ha publicado igualmente diversos libros y material multimedia dentro de sus líneas de investigación y docencia. Es Senior Member del IEEE así como miembro del Comité de Administración de la Sociedad de Educación del IEEE.

ISSN 1932-8540 ©IEEE

36 IEEE-RITA, Vol. 1, Núm. 1, Nov. 2006

ISSN 1932-8540 ©IEEE

IEEE-RITA (http://webs.uvigo.es/cesei/RITA)

DOI (Digital Object Identifier) Pendiente

Volumen 1: Lista de Revisores

Addison Salazar Afanador, Universidad Politécnica de Valencia, España Alfredo Fernández Valmayor, Universidad Complutense de Madrid, España

André Luís Alice Raabe, Universidade do Vale do Itajaí, Brasil Antonio J. Méndez, Universidad de Coimbra, Portugal

Baltasar Fernández, Universidad Complutense de Madrid, España Basil M. Al-Hadithi, Universidad Alfonso X El Sabio, España

Carlos Vaz do Carvalho, INESP, Portugal Cecilio Angulo Bahón, Universidad Politécnica de Catalunya , España

César Alberto Collazos Ordóñez, Universidad del Cauca, Colombia Daniel Burgos, Universidad Abierta de Holanda, Holanda

Edmundo Tovar, UPM, España Faraón Llorens Largo, Universidad de Alicante, España

Fernando Pescador, UPM, España Francisco Arcega, Universidad de Zaragoza, España

Francisco Azcondo, Universidad de Cantabria, España Francisco Jurado, Universidad de Jaen, España

Gloria Zaballa Pérez, Universidad de Deusto, España Gracia Ester Martín Garzón, Universidad de Almeria, España

Inmaculada Plaza, Universidad de Zaragoza, España Ismar Frango Silveira, Universidad de Cruzeiro do Sul, Brasil

Jaime Sánchez, Universidad de Chile, Chile Javier Areitio Bertolin, Universidad de Deusto, España

Joaquín Roca Dorda, Universidad Politécnica de Cartagena, España Jorge Alberto Fonseca e Trindade, Escola Superior de Tecnología y Gestión, Portugal

José Bravo, Universidad de Castilla La Mancha, España José Carpio, UNED, España

José Javier López Monfort, Universidad Politécnica de Valencia, España José Luis Guzmán Sánchez, Universidad de Almeria, España

Juan Suardíaz Muro, Universidad Politécnica de Cartagena, España Juan Vicente Capella Hernández, Universidad Politécnica de Valencia, España

Luis de la Fuente Valentín, Universidad Carlos III, España Luis Fernando Mantilla Peñalba, Universidad de Cantabria, España

Luis Gómez Déniz, Universidad de Las Palmas de Gran Canaria, España Luis Zorzano Martínez, Universidad de La Rioja, España Manuel Caeiro Rodríguez, Universidad de Vigo, España

Manuel Castro Gil, UNED, España Manuel Fernández Iglesias, Universidad de Vigo, España

Manuel Ortega, Universidad de Castilla La Mancha, España Manuel Pérez Cota, Universidad de Vigo, España

Martín Llamas Nistal, Universidad de Vigo, España Mateo Aboy, Instituto de Tecnología de Oregón, USA

Miguel Ángel Redondo Duque, Universidad de Castilla-La Mancha, España Miguel Rodríguez Artacho, UNED, España

Paloma Díaz, Universidad Carlos III de Madrid, España Rosa M. Vicari, UFGRS, Brasil

Víctor H. Casanova, Universidad de Brasilia, Brasil Xabiel García Pañeda, Universidad de Oviedo, España Yannis Dimitriadis, Universidad de Valladolid, España

IEE

E-R

ITA

Vol. 1, N

um. 1, 11/2006

IEEE-RITA es una publicación lanzada por el Capítulo Español del IEEE (CESEI) a través de su Comité Técnico, de Acreditación y Evaluación (CTAE), y apoyada por el Ministerio Español de Educación y Ciencia a través de la acción complementaria TSI2005-24068-E, Red Temática del CESEI IEEE-RITA é uma publicação lançada pelo Capítulo Espanhol da Sociedade da Educação de IEEE (CESEI), através de seu Comitê Técnico, do Acreditação e da Avaliação (CTAE), e suportada pelo Ministério Espanhol da Educação e da Ciência com a ação complementaria TSI2005-24068-E, Rede Temática do CESEI. IEEE-RITA is a publication launched by the Spanish Chapter of the Education Society of IEEE (CESEI), through its Technical Committee, of Accreditation and Evaluation (CTAE), and supported by the Spanish Ministry of Education and Science through complementary action TSI2005-24068-E, Thematic Network of CESEI.