Arp@: Remote Experiences with Real Embedded Systems XAVIER VILAJOSANA,1 JORDI LLOSA,2,3 IGNASI VILAJOSANA,3 JOSEP PRIETO-BLA`ZQUEZ1 1
Computer Science, Universitat Oberta de Catalunya, Barcelona, Spain
2
IN3, Universitat Oberta de Catalunya, Barcelona, Spain
3
Worldsensing S.L., Barcelona, Spain
Received 15 November 2011; accepted 30 December 2011 ABSTRACT: The emergence of the Internet of Things increases the demand on embedded computer systems, which in turn requires the availability of specialized engineers in the near future. Several universities commenced embedded-systems programming courses to complement students’ skills by introducing specific firmware development techniques. Hands-on labs with real hardware interaction is restricted to the time students are in the laboratory whilst virtual-laboratories provide more flexibility at the caveat that students do not improve hardware manipulation skills as they cannot physically inter-actuate with real devices. We argue that students’ abilities can be increased by providing them with a sensor board with reduced computation and communication capabilities to work with at home. Students increase the time spent manipulating the device; moreover, their motivation is also increased as they can put their effort on developments of their interest. The article presents the experience carried out at the virtual-course of Embedded-Systems at the UOC. The developed technology, the methodology, and the feedback from students are presented here, and corroborate the benefits of the chosen methodology. ß 2012 Wiley Periodicals, Inc. Comput Appl Eng Educ; View this article online at wileyonlinelibrary.com/journal/cae; DOI 10.1002/cae.21555 Keywords: embedded system; wireless sensor network; virtual laboratory; virtual learning environment; embedded system laboratory activities; TinyOS
INTRODUCTION The importance of embedded system programming has been increasing over past years. This is due to the fact that a large part of protocol and algorithm development for communications systems is in reality working with the embedded systems. The actual development work, particularly software development, for embedded systems requires practical skills and is highly different when compared to ordinary workstation programming or working with simulators. This article evaluates an initiative carried out at a virtual course of embedded systems programming at the Univesitat Oberta de Catalunya, Barcelona, Spain, which aimed to improve the skills of computer science engineering students through the use of real hardware while they work at their homes. The innovative approach differs from current trends on remote laboratories [1–3] as students physically interactuate with real hardware while they are at home. Teaching embedded system’s programming is not an easy task in any computer science and telecommunication university Correspondence to X. Vilajosana (
[email protected]). ß 2012 Wiley Periodicals, Inc.
due to the need of appropriate and sufficient hardware devices. In most of the cases, the universities’ budget is reduced and does not allow having one device per student but they share a pool of devices in a physical laboratory and organize practical sessions in groups. Therefore, the teaching of hardware programming courses is constrained to the time that students are in the laboratory. The use of simulators [4–7] is a widely used alternative that fulfills the teaching purposes but neglects other transversal knowledge (e.g., soldering, solving USB to Serial problems, configuring the hardware to work with a specific O.S., setting the tool chain, installing cross-compilers, facing hardware failures, plugging a debugger, etc.), related to working with real devices. In virtual universities the difficulty of teaching hardware programming increases as students are not able to use a real laboratory but their activities are carried out in a virtual lab [8,9]. While the use of virtual laboratories has emerged as a very interesting and complementary alternative, there is some transversal knowledge related to hardware manipulation that cannot be attained due to the distance factor. Our work here thus aims to address the fairly negative experience obtained from several IT companies that received new graduate students, most of them with inferior or absent
1
2
VILAJOSANA ET AL.
embedded programming skills. It is becoming an increasingly hard issue for most embedded system programming companies to hire new engineers as they need good programming skills combined with hardware abilities which are difficult to find in recent graduates. With that in mind, in the Embedded System’s course of both Computer Science and Telecommunication degrees, we have introduced a new approach on teaching embedded system’s programming and low power communication protocols. We combine the use of virtual laboratories [10] and simulators [5] with the use of real own made hardware devices that are sent to the student’s home. The article motivates our choice to develop our hardware related to already existing embedded nodes for learning and research purposes. Besides, it presents the initiative and the course structure showing its evaluation from the student’s point of view.
GENERAL STRUCTURE FOR AN EMBEDDED SYSTEMS LABORATORY Laboratory tests and experimentation are essential components for education and research in all fields of engineering. Handson labs are the most common forms of such laboratory environments, offering students opportunities of experimentation with physical, or real, systems related to the research or education material in consideration. Remote Laboratories are key tools to complement students skills and perfect substitutes for real laboratories in certain knowledge areas [1]. However, in virtual learning environment (VLE) students suffer from the lack of real hardware interaction which reduces their abilities as engineers. Through the characterization of Embedded Systems’ Laboratories (ESL) it is possible to construct learning experiences according to the learning environment, without interfering with the learning purposes. Thus, the general structure of an Embedded System’s Laboratory (ESL) defines the elements and the methodology for students complete training process. Next subsections will describe all the elements that integrate an ESL. They can be seen in Figure 1.
Elements of the ESL All hardware and software elements that will be used by ESL students. The most basic technological elements are: 1. Technological resources - Hardware. - Simulators. - Networking tools or network labs. - Compilers, debuggers, and tracers. - Support and tool chain tools. ESL usually require a device per student or per-group of students. Those devices should integrate a microcontroller, some kind of peripherals to inter-actuate with, I/O interfaces and the possibility to be reprogrammed. Other interesting features include the possibility to expand hardware functionalities and the possibility to introduce networking concepts. Software development for embedded systems is usually bound to a specific tool chain that require platform-specific compilers and debuggers. Therefore, a very important dimension for an ESL
Figure 1 Main elements that configure an embedded system’s laboratory. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]
is the chosen technology which has to be realistic and fit to Industrial reality.
Methodology of the ESL There are several proposals of learning methodology from a teacher/lecture-centered to student-centered [11] environment. Practical activities require a specific learning methodology where the student is the central element of this educational model. Student-centered models must give students enough freedom to take advantage of the support offered, to plan their learning process, and to regulate their own working rate, guaranteeing a dynamic learning experience for each student. An ESL combines the following pedagogic resources: 1. Pedagogic and strategic resources - Learning methodology. - Support documentation. - Evaluation. 2. Academic staff resources - Teacher (TCH). The learning methodology is activity driven which requires a specific scheduling and timing of activities as normally students are constrained to the time that they are in the laboratory. The support documentation includes all information that will help students to achieve the objectives of the practical activities. Usually the documentation is structured in:
Hardware data-sheet: a comprehensible description of the hardware and its main features. Practical assignments: different practice activities that must be completed in order for the student to be evaluated. Basic reference documentation: the programming language basic documentation. Virtual library: links to different electronic media or resources that are deemed interesting in order to get some
ARP@: REMOTE EXPERIENCES
3
extra information about the different topics discussed in the curricula. A defined evaluation criteria is also needed. The evaluation criteria has to be activity oriented, publicly known by students, and should guide them to accomplish their goal (learning and not only passing the subject). Finally the academic staff has to advise students during their work at the laboratory. Teachers have to combine technical support with more theoretical aspects.
EVALUATION OF THE Arp@ LAB: THE CASE OF AN EMBEDDED SYSTEMS HOME LABORATORY The following sections describe the Arp@ lab experience carried out at the Universitat Oberta de Catalunya, Barcelona, Spain since early 2010. Arp@ lab applied the general structure of an Embedded System’s Laboratory to the Virtual Laboratory Environment (VLE) of our engineering careers. The Arp@ course was designed by defining the main ESL elements to fit in the structure of a virtual course where laboratories are remote and students work at their home. During the 2010–2011 academic year, 90 students attended the Embedded Systems graduate course on the Computer Science and Telecommunication Engineering degrees. The following sections describe the pedagogic resources and the technological resources used to model the Arp@ experience.
Learning Methodology The learning methodology applied in our Arp@ lab is the general UOC methodology [12] adapted to carry out practical activities. It is based on constructivist learning theory adapted to VLE where asynchronous communication is allowed in space and in time between the students and the academic staff [13]. Such methodology allows students to have maximum flexibility, adapting their studies to their own rhythm and circumstances at any particular time [14]. The main features are: the teacher facilitates and monitors the learning process of the students, students are encouraged to be responsible and autonomous, the practical activities are divided into different parts to permit continuous evaluation and communication between students themselves and between students and teachers. In short, the Arp@ lab is student-centered. As far as we know, Arp@ is the first attempt to develop an embedded systems’ home laboratory based on student-centered methodologies. Other student-centered approaches to teach embedded-systems in an on-site university have proven excellent success rates [15].
Figure 2 COU24 mote depicting the elements described in this article. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]
structured in four continuous assessment activities. Table 1 summarizes the course curriculum including the planning week by week of the activities.
The first activity is accomplished by carrying out the training process that consists of an initial reading stage, and a subsequent training process based on different tutorials. It is very important that students read the minimum documentation at the beginning as the most basic concepts need to be acquired, the first continuous assessment activity will certify that students have acquired the basic theoretical knowledge by means of a conceptual test. In addition, during the first stage, students are guided through five incremental tutorials that provide them with the skills to program the motes. In parallel the professors propose a set of different applications that can be done with COU24 motes (e.g., alarm systems using the sensors
Course Structure At the beginning of the course, the student receives to his/her home a pair of COU24 motes (described in ‘‘COU Mote’’ Section see Figure 2) and gets access to the wiki of the embedded systems lab course [16]. The wiki has the necessary information (including data-sheets of the COU24 platform) for a student to start learning the way COU24 motes are programmed and used. The objective of the subject is that students develop an application using the COU24 motes. Figure 3 presents the course structure from the students’ point of view. The course is
Figure 3 Course lifecycle from student’s point of view. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary. com.]
4
VILAJOSANA ET AL.
Table 1 Weeks Week 1 Week 2 Week 3 Week 4 Week 5 Week 5 Week 7 Week 8 Week 9 Week 10 Week 11 Week 12 Week 13 Week 14 Week 15 Week 16
Curriculum of Embedded Systems Block
Contents
Cont. assessment
Intro Intro Hardware Hardware Hardware Software Software Software O.S. O.S. O.S. O.S Debug Summary Practical Exam
Introduction, what is an embedded-system? Form factors and families Applications, design principles, and the development process System Architecture, internal components: core, buses, addressing Instructions, memory, registers, multiplexers, counters, divisors, clocks External communication: Ports, wireless interfaces. Power supply Programming Languages and tools. Functions, pointers Embedded systems programming tricks. Programming models State machines. Multitasking systems Introduction to embedded O.S. A basic example Task scheduler (RR, Event based, multi-task). Real time O.S. Drivers, data-sheets and controller programming Embedded systems O.S. (Contiki, TinyOS, FreeRTOS, QNX, uOSIII, etc.) Tool chain and laboratory tools. Testing strategies (white, gray, black box) Summary and project meetings Project meetings and presentations Final Exam
TinyOS tutorial 1, 2 TinyOS tutorial 3, 4, 5 CA 1
on board: presence, fire, light; communication protocols using the radio, or time of flight measurements, remote control applications, etc.) and also allow students to propose other applications. By the first continuous assessment, students have to propose individually an application to develop and the planning for that development. The second continuous assessment concludes with a first prototype of the application running. During this phase students are developing (programming) the application and modifying the hardware if needed with the support of their teachers. The third assessment is optional and consists of deploying their application into the MoteLab [10], a remote wireless sensor network testbed at Harvard University that offers the possibility to deploy an application using up to 190 motes. This activity is optional as not all students develop a networking application and it requires to adapt COU24 code to the TMote Sky platform [17]. The activity aims to provide the means to evaluate an application for those students that developed networking protocols. Finally, in the last continuous assessment activity, students deliver the developed application. This activity aims to strengthen several transversal skills such as formal documentation and presentation of results. Students are required to present their work in a smart way; simple slides or text are not allowed. This encourages students to figure out a way to present their work. One well-accepted medium is through the use of videos where students guide us through a demo of their application. Other smart ideas are posters and collages presenting their development. Documentation is also evaluated, with a maximum of 60 pages, where students have to document their application following structured software engineering specification concepts as they have already learnt during the degree.
The development work is accompanied by week-by-week lectures and activities (continuous assessment—CA) of the main theoretical concepts related to embedded-systems (see Table 1). The contents include the main hardware parts that integrate an embedded system, software programming techniques focusing on the main features and tricks to program
Practical assessment
D1-basic program from tutorials
State machine 1 State machine 2 CA 2 Contiki paper CA 3
D2-application D3-MoteLab D4-project presentation D4-project presentation
embedded systems (e.g., in-lining, volatile variables, debug pins, etc.), O.S. for embedded-systems and finally a brief overview of the tool chain and debugging techniques for embedded systems.
Evaluation The evaluation is a pedagogical resource that allows the students to gauge and achieve their learning objectives. In a Virtual Course Environment, it is very important to offer students a flexible model of continuous evaluation, providing activities to be completed throughout the semester [18]. The system evaluation used in our Arp@ course follows a continuous evaluation model [12]. Students have to perform four activities along the course. Three of them are mandatory and one activity is optional. Activities require students to demonstrate their progress. Each activity is evaluated based on three aspects, methodology, content, and form. Methodology evaluates the formalism and techniques used by the student to fulfill the activity, for example, the planning of their work have to follow software development life cycle. Content relates to the correctness of their answers or quality of their code and Form refers to how the content is structured and how it fits to the Methodology.
Teacher ‘‘Virtual teachers’’ of our Virtual Arp@ Lab are members of the academic staff who help students to reach their individual objectives, offering each student personalized attention. The teachers of Arp@ ought to have specific skills. Among the most important ones are those related to the technological skills regarding the tools that are used along the course [10,19–22]. Another aspect that impacts on the role of the teacher is the fact that the students are usually isolated in a VLE. They are at home alone. This isolation means that mentorship and guidance must be reinforced to guide, motivate, plan, and be more proactive. On the other hand, Virtual Environment Labs such as Arp@ need a team of teachers composed of at least two members of staff, each with different skill-sets: one of them will need in-depth knowledge of the
ARP@: REMOTE EXPERIENCES
content related to the subject, ‘‘Theory Teacher,’’ and other will need more technical skills, ‘‘Teacher Lab.’’ In the specific case of our Arp@, The Teacher Lab is in charge of the resolution of technical problems (e.g., solving cross-compiling issues, supporting the installation of TinyOS, helping on the design of some state machines that control a specific embedded system, supporting the driver programming, etc.). The Theory Teacher follows students progression during the course and guides them to achieve the necessary knowledge to acquire the competences of the course. This teacher is in charge of developing the online material used by students along the course, including, theoretical fundamentals, exercises, tutorials, exams, and continuous assessment tests amongst others. Students are guided by Theory Teachers week-byweek indicating the activities, and lectures that they have to do during the week. Another very important aspect is personalized feedback to each student in order to improve their weaknesses.
Technological Resources Prior to the development of the COU node, a survey of commercial low cost devices was carried out. We aimed to determine whether existing devices could be used for the purpose of the course and if any of them fit to our hardware requirements:
Reduced cost in order to be able to send a free pair of nodes to each student, essentially limiting the budget (in our case, as of Q2 2011) to 60 s per student. IEEE 802.15.4 compliant radio in order to train students with standardized communication interfaces with low power radio for industrial applications. Multi-channel 2.4 GHz radios in order to explore the multi-channel availability in this ISM band. Multiple sensors on board in order to support at least three different sensors on board, combining analog and digital outputs. Supported by different O.S. (e.g., TinyOS, Contiki, FreeRTOS, uOS-II) in order to provide component abstraction which is most adequate for Computer Science students, which is why TinyOS had been preferred.
Table 2
5
Programmable through USB port in order to avoid the use of a JTAG or any other hardware programmer. Medium range of communication (>50 m) in order to be able to study range effects. Open Source Debugging tools and complete tool chain in order not to pay licenses as neither students nor the university can afford a license for each student; the tool chain is considered to be very important as we want students to use standardized open source tools.
Tables 2–4 summarize the candidate hardware platform studied before developing COU node. Most of them are integrated by similar components and there are few variations in price except for the EZ430-RF2500 [23] which is sold under their production cost due to a commercial strategy of Texas Instruments. We also compared our market survey with other commercial hardware surveys, such as [24], finding a good agreement. Therefore, the best-suited candidate is eZ430-RF2500 by Texas Instruments with a cost of 37 s for a pair of boards. The eZ430-RF2500 is a complete wireless development tool for the MSP430 microcontroller and CC2500 radio that includes all the hardware and software required to develop an entire wireless project with the MSP430 in a convenient USB stick. Some of its drawbacks include low range communication (
