Friday 20 May 2011

Wireless Sensor Networks

The academic year 2010-2011 saw major improvements to the Embedded Systems module (see previous post). One of such improvements was aimed to reflect the increasing importance and widespread use of wireless sensor networks (WSNs). Such networks are a specific type of distributed embedded system, and have been applied to application domains such as habitat monitoring, earthquake prediction and smart homes. WSN nodes (also known as motes) are thumb-sized computers that operate on batteries and sense the environment around them. Motes can cost between £50-£250 each (depending on their wireless radio standard, processing/storage capabilities and packaging), plus additional costs for specific sensors (temperature, light, sound, etc.)

To provide students with practical experience on the development of such systems, I submitted a request to the university's Rapid Response Fund to finance the purchase of a set of wireless sensor nodes (with matching funds from the CS department). I was really happy to see that both the university and the department have such mechanisms to enable small but high-impact initiatives that can improve student experience. It was very lightweight, no bureaucracy, and in a few weeks I've got the notification that the request was granted.

I had decided to purchase a IRIS Classroom Kit, which includes 30 motes, 20 light/temperature sensors and 10 USB data acquisition boards (for programming and debugging on lab PCs), respective software and documentation. After the delivery of the kit, I tested the motes and started to prepare my laboratory activities and experiments. To simplify the programming of the motes by the students, I chose Mote Runner, a new software package that had been recently released by IBM within their alphaworks. In an agreement with IBM's research center in Zurich, York became one of the first universities worldwide that could use that software package for teaching and research purposes (alongside ETH Zurich). I will probably write more about Mote Runner in another post, but here's some information coming directly from the source:



I've prepared six 2-hour lab sessions covering different aspects of WSN design, including system specification, embedded software programming, networking protocols, energy efficiency, system simulation and deployment. Some of the lab sessions included simple exercises to familiarise students with the hardware and software infrastructure, while others followed a problem-based learning approach.

In one of the problem-based sessions, students were divided in two groups that were given 10 motes each, and were asked to create a simple packet forwarding protocol to transmit a message over the Computer Science building, from the Crossrail Lab (where the lab sessions took place) to my office. Once both groups had the protocol implemented and the motes deployed, they should call my office from the CrossRail lab and ask for the message to be transmitted (actually a sequence of colors that should be displayed by blinking LEDs on a mote). The message would then be loaded to a base station mote, which in turn should forward it to other nodes, successively towards the destination. The first group to complete the mission was awarded a box of chocolates.


Part of the assessment of the students (their exam!) was also based on Mote Runner and the IRIS motes. This time, the problem involved indoor localisation of a mobile mote using radio signal strenght obtained from six stationary motes. Students were evaluated on the accuracy of the localisation algorithms they implemented, as well as the memory footprint and energy efficiency of their solutions. They actually did well!


At the moment I am thinking about some new problems that I can use to assess the students taking the Embedded Systems module in the next academic year. But I can't give you any details now... my students would be really sad if I ruin the surprise :-)

Monday 9 May 2011

Embedded Systems Design and Implementation

In line with the profile of the department (as discussed in my previous post), we are often improving the curriculum so that we can graduate professionals that are proficient in both software and hardware parts of a computing system. A specific type of computers are the so called embedded systems: computers that have a specific functionality and must perform them very efficiently, often as part of a larger system or network. Examples of embedded systems include a mobile phone, the motor controller of an industrial robot, a car's anti-lock braking system or the digital audio effect rack used by recording studios. It is estimated that 98% of all computers are actually embedded systems (yes, that's right, all PCs, laptops and servers account for only 2% of all computers!)

For many years already, our Computer Science degree programme has included a module called Embedded Systems which covers basic and advanced topics in that area. It makes sure that our graduates learn to fine-tune a computer system so that it can fulfil the requirements of specific applications and functionality. Recognising the importance of that area and its wide range of applications, we expanded that module, which is now called Embedded Systems Design and Implementation. It focuses on the complete engineering flow: specification, design, implementation and validation. Additional content and new lab sessions were added, so that students have a chance to learn and practice the following skills:


  • specification of functionality at system level (unified hardware/software view)
  • different approaches to implement functionality in hardware or in software 
  • embedded software implementation 
  • wireless communication design
  • on-chip communication design
  • custom hardware design using FPGAs

I'll post more details about some of those topics soon.

Friday 6 May 2011

Hardware vs. Software

Computer Science students here at York know that they must be proficient in both hardware and software. From the moment they arrive to the time they hand in their graduation projects, they are exposed to a healthy mix of lectures and labs that cover both domains as well as their mutual dependencies. This is a consequence of the department's commitment to research in embedded, real-time and safety critical computer systems, which require careful co-design of the hardware and software subsystems. 


I was pleased to find out that prospective students are also aware of that. A few weeks back, I was interviewing a candidate for one of our undergraduate degrees, and when I asked why did he apply to study at York he answered "because York Computer Science students do a lot of hardware stuff". I was curious about that answer, so he told me that very few Computer Science departments have so many hardware labs and advertisement flyers with photos of students playing with robots, circuit boards and osciloscopes.


That got me thinking how the perception of a software vs. hardware dichotomy could influence someone's choice of a higher education institution or degree programme. But considering that usability, performance and energy consumption are the key issues in computing these days, I wonder who would benefit from concentrating only in hardware or software when it is their interplay that will determine the success and wide adoption of a computing system. Will someone use an Ipad if it is slow, runs out of battery in 20 minutes and has a poor user interface? Will they use it if only two out of the three issues are solved? No, you need a design that solve all three problems, and you cannot do that with software or hardware alone. And therefore I think we should be happy to be known as the Computer Science department where students also learn a lot of "hardware stuff".