Abstract:

In computer terminology, “real-time” is reserved for systems that have to interact with their environment without having the capacity of controlling its timing. This lack of control implies that real-time systems are subject to severe timing constraints: they should only interact at moments acceptable for the external system. An air bag controller is an intuitively clear example: when the readings of accelerometers cross a threshold, airbags should inflate within milliseconds, any excessive delay making them ineffective and even dangerous. Interactive systems like ATM machines are not real-time as the users wait till they are prompted by the computer to interact. Even most computer games are not real-time, as it is the game that imposes its rhythm to the players. As for most people computers are interactive devices, awareness of real-time issues is very low, even among computer freaks. Unfortunately, in modern , networked systems involving multiple processors, many subsystems can have real-time constraints, even if the global system doesn’t. For instance, wireless sensors collecting environmental data transmit these data from sensor to sensor via an unreliable radio channel. Messages are repeated until they are acknowledged, via the same radio channel. If, due to some timing error, retransmission takes place before the acknowledgement can reach the sender, both messages will be lost and the sender will continue retransmitting, despite the fact that the receiver already got once the message. This might result in buffer overflows and, at last, total mixing up of the application.

In order to make students aware of such issues some straightforward lab exercises were designed.

The first was inspired by the example given in the previous paragraph: simple, numbered messages had to be transmitted between two wireless nodes and the loss of messages investigated. The normal timing of the radio subsystem had been altered as described previously. Some messages got lost and even sometimes the radio link got entirely blocked. Students started investigating the problems by adding write statements at critical points in the communications software. This allowed them to identify and correct the problem but the corrected system still malfunctioned, although in a completely different way. Adding still more write statements made things worse. This led them to suspect, rightly, that now real-time requirements were no longer satisfied due to the delays introduced by the write statements. Finally, students were provided with a “sniffer” test system that allowed to observe the radio traffic, without disturbing it. They unanimously concluded that they had learned what real-time was and how difficult to debug it was.

A second, more straightforward laboratory experiment was also developed: it consisted in a miniature water tower, equipped with computer controlled pump, valves and sensors. In a first assignment students had to display and manually adjust the level of the water through a graphical user-interface. Thereafter they had to program a control loop, maintaining the water level at a preset value, regardless of the water used outside the control system. Most students discovered that, despite it worked perfectly for slow manual commands, their software became unreliable once external conditions imposed fast reactions.

We believe such didactic experiments, which will be described in detail, are a must for making students aware of real-time issues.