During the first week of the course, the students are to form groups (3 persons each). Each group selects a project, which is handed in at the end of the course. (In addition, the project groups will be used for other purposes). The projects can be one of the topics below, but you are free to come up with projects of your own. The topics below are of interest to some local researcher, who will devote some time to helping you with the project, and is interested in the results of your project. The same may not be true of projects that you come up with yourselves (although Jakob and Ulrik will of course do what they can to help you). This is not to say that new ideas for projects are not welcome - on the contrary - but just that there are fewer guarantees about them. If in doubt, come see Jakob or Ulrik.

Please note that there are a few restrictions on the choice of project:

• Certain hardware needed for projects can only be used by a limited number of people.
• To avoid severely burdening the people who are responsible for different projects, we may have to limit the number of groups that do projects in a certain topic.

To decide who gets what hardware and who gets to do which project, we have decided on the following simple algorithm: the order in which the groups perform postings on daimi.pvc with a description of what project they want to do and what hardware is needed decided who gets priority.

Regardless of which topic is chosen, a detailed project description (see below) must be handed in before the project starts (for dates, see course schedule).

Overview of project ideas (in alphabetical order):

• Bang&Olufsen Lab
• Context awareness
• Embedded systems
• Mobile agents
• Requirements engineering

To pass the course, you are required to (0) hand in a project description, (1) implement a proof-of-concept prototype, (2) present it during class, (3) document both the design and implementation of the prototype as well as your experiences in a project report, which also should contain background information on the subject that you are working with, and (4) hand in everything (report, presentation, source code) - see below.

If your proof-of-concept prototype does not work (e.g., you cannot demonstrate its functionality), you must demonstrate to Jakob and Ulrik that you have actually done a fair amount of work in trying to get to work.

The project report is due the 15th of January (unless your final exams are in January, in which case we need to have your report at the beginning of January). The source code is handed in at the same time (again, see below).

The report should be between 10 and 20 pages, depending on the size of your group and the amount of material that you have (but no more than 20 pages!). The report should consist of the following parts:

• Introduction, motivation, problem statement
• A survery of related work
• A description of the analysis and design of your solution
• A description of you technical implementation
• A short conclusion and/or perspectives

The report will be evaluated with a 1/3 score on related work, design, and implementation, respectively. We encourage you strongly to do a proper search for related work.

• A paper (e.g., printed) version of your report
• An email sent to both Ulrik and Jakob either containing or giving the name of a tar/zip archive named after your group number (e.g., 0.tgz for group 0):
  • It should contain a single directory named as your group number (e.g., 0)
  • It should have a subdirectory 0/report which contains your report in electronic form
  • It should have a subdirectory 0/presentation which contains the slides of your presentation in electronic form
  • It should have a subdirectory 0/implementation which contains the implementation of your project, preferably structured in a nice manner with further subdirectories, as appropriate
  • It should contain a file 0/implementation/README which describes what is stored where in the implementation directory, how to build/compile your project, and how to run it
  You should only send us the archive directly by email if it's not "too large", where "too large" is around 1MB.

The project description should include an initial survey of the work that is relevant to your project, and should define at least two milestones for your project: "minimal prototype" and "complete version" (more milestones in between are encouraged).

Project descriptions are expected to be "a couple of pages and then one more": a couple of pages for surveying relevant work, one page for describing what you want to do in your project and defining your milestones.

Project descriptions should be handed in electronically (ASCII, HTML, or PDF) by email to Jakob or Ulrik. The email should be entitled "PvC project description".

• Bluetooth-based remote control: Our current remote control uses wireless networking (standard IEEE812b equipment). However, bluetooth has a number of advantages in terms of cost and power consumption, and could potentially provide additional information about the location of the client (distance). We can equip a portable PC or our tablet PC with a bluetooth thingie, to enable it to connect with the Linux-based stationary devices. Alternatively, some smaller bluetooth-enabled device could perhaps be used (a mobile phone?). Warning: with the current state of software, working with bluetooth means quite a bit of low-level hacking!
• Context-awareness based on bluetooth: In the context of a remote control based on bluetooth (see previous project idea), we are interested in obtaining context information regarding the location of the remote control. This context information should be integrated with current remote control prototype (written in Java).
• Biometrics for personalized remote control: We are currently developing an "interactive remote control" based on a tablet PC with wireless networking. This remote control reacts to its surroundings based on IR-signals from the environment (still preliminary). We have a fingerprint reader for the tablet PC, which could be used to provide personal preferences for whomever is holding the remote control at the moment. What is needed to do is to hook up the C-based API biometrics API with the Java-based remote control application, and then extend the Java-based remote control application appropriately.
• Remote GUI display on AV devices: It is useful for interconnected AV-devices to be able to display their control panel on e.g. a television. Mobile code a la Java would be an option, but puts high requirements on the interface. Alternatively, a simple language describing the interface appeareance and the interaction possibilities can be used. DDI is such a language (search for "DDI data driven interaction" on google), but it does not offer very good support for customizing the GUI to the device it is displayed on (for example, the graphical appearance should match the appearance of the television, no matter what device is displaying the GUI). The task here is to develop a DDI-like language which adapts the appearance of the GUI to the device that it is displayed on.
• Remote GUI display using applets: Like the previous assignment, except that our device really is large enough to support Java applets (or some other remote code technology). However, the interface still needs to be customized to the device that it is displayed on (which could range from an LCD display to a wall-sized screen, and each of these devices may have different ways of presenting their interfaces).
• Automatic download of television programming: Television programs are currently available on the net (e.g., tv.tv2.dk). Develop software to automatically download such television programs and store the information in the AV content directory currently being developed at B&O in conjunction with the B&O-Lab.
• MPEG-2 streaming over firewire: We know how to stream arbitrary data over the firewire network, but we're not currently using the correct stream format (which includes time stamps and must be correctly synchronized etc.) The task is to do it right. Warning:: lots of low-level C hacking!

[Contact: Ulrik Pagh Schultz]

The following is a list of application of context-aware computing. In such projects you can use the Java Context-Awareness Framework (JCAF) developed here at AU, or other context-awareness toolkits, e.g. the Context Toolkit from Georgia Tech.

• The Context-aware office. More to come ...
• The Context-aware Home. Building the context-aware home of the future. More to come ...
• Context-awareness in a operating room. In the hospitals of the future we are designing interactive operating rooms. These rooms needs to be sensitive to what is going on in there. For example, they should know who the patient is, the type of operation, etc. Furthermore, there is a need to help manage the instruments. We have the following suggestion for a project from an Industrial Designer (In Danish).

  I sidste uge var jeg inde og se en operation på afd. T.Op for at se hvordan en operationsstue ser ud og undersøge hvad man egentlig kunne gøre lettere for sygeplejerskene og lægerne. Under dette besøg lagde jeg bl.a. mærke til en speciel procedure sygeplejerskene gentog flere gange under operationen for at undgå at der blev gemt genstande inde i patienten: De talte alle genstande tre gange og sammenlignede med lister og små mærker. Derudover blev alle brugte servietter stoppet i en lille klar pose og hængt op på et stativ. Derved var de lettere at tælle og anæstesilægen kunne holde øje med hvormeget blod der var på dem. På den måde kunne han give et skøn om patienten skulle have tilført blod.

  Det projekt jeg har valgt at lave er et produkt der kan tælle alle genstande (servietter, tænger, m.m.) og samtidig måle hvormeget blod servietterne indeholder. Disse data kan fx blive sendt direkte op til anæstesilægens computer og blive lagret der. Jeg forestiller mig at der kunne være en chip i alle genstande, som indeholder data om hvad det er for en genstand, og at det på den måde kan lade sig gøre at tælle og holde styr på det hele. Chippen kan evt. også holde styr på hvor mange gange fx en tang eller saks har været brugt, så man kan få en idé om hvornår de skal udskiftes.

• The Context-aware meeting room. When you enter a meeting room you should be able to see on you personal device (PDA or laptop) what resources are available here. And you should be able to interact with the available resources. For example, you should be able to transfer and show your slide at a wall-projector, and transfer notes to the screen in the table. Also you should be able to se a list of people in the room. And so on ...
• The Interactive 'Falck box'. Together with Falck and the course on Designing Interactive Systems (DIS), we are designing what Falck's box with first-aid stuff should look like in the future. Together with students at the DIS course you should implement the hardware and software systems for this box, using whatever technology available.

Technologi and Framework

We are currently designing and implementing the Java Context-Awareness Framework (JCAF). There is a number of exciting and challeging project connected to the further developmed of this framework.

• Location Acqusition and Modelling. Location is one of the most important context information for a context-aware system. You should build one or more location monitors based on e.g. (i) WLAN, (ii) the WorkSPACE IrDA beacons, (iii) recording and identifying a speaker, or others you decide upon. You should then model 'location' as a piece of context information in the framework. There are a number of challenges associated with building the monitors, as well with modelling location and merging different location data. Inspiration from the GA Tech is available here Location Service
• RFID Location Antenna. This project is for hardware engineers. You should build a RFID antenna as a mat on the floor. The idea is to equip people with personal RFID tags in their shoes, and then determine where they are based on them walking over RFID mats in a building. Inspiration from the GA Tech is available here RFID in the Aware Home. We are however using the Philips I-Code technology.
• Peer-to-Peer Location Services. The JCAF framework currently runs as one Context Service. It would be feasible to divide this into a range of cooperating Context Services, collaborating in a Peer-to-Peer network about delivering context-aware functionality to the clients. We could hence have dedicated services for different tasks and/or locations. E.g. a context service for each room in a building.
• Jini and the JCAF framwork. You should build a Context Service, which runs as a Jini service in a Jini network. Clients should be able to lookup and discover this context-awareness service when e.g. entering a room. Could be made in cooperation with a project group doing the project above.
• Security in Context-awareness. There is currently no security in the JCAF framework. Important questions like "Can we trust the context information from the context service?" is unanswered. You should extend the JCAF framework with basic security mechanism that can (i) provide an access control list, which controls who can access what in the context service, and (ii) a mechanism for authenticating requesting clients (including monitors). To do this assignment you should be familiar with basic security mechanisms in distributed systems.

[Contact: Jakob Bardram]

Projects in embedded systems can be done using Atmel-based boards (low-end, have serial and CAN-bus connections), using Lego RCX bricks (Hitach CPU), using Ajile Real-Time Java (RTJ) boards (serial connection plus many low-level I/O options), or using standard workstations with appropriate restrictions imposed.

Projects with Atmel-based boards, the Lego RCX brick, and standard workstations can be done using the JEPES compiler for Java on low-end embedded systems. (Or whatever compilation system/virtual machine you're interested in using.)

Ideas for projects:

• Mobile code on RTJ embedded systems: The Ajile RTJ boards support a restricted version of dynamic loading of code, which can be used to implement a form of mobile agents. The goal is to implement a (simulation) control system with real-time requirements which mobile agents can dynamically move through the systems to compute statistics. [Contact: Ulrik Pagh Schultz]
• Application framework for RTJ embedded systems: The Ajile RTJ boards contain a number of features (most significantly multiple JVMs) that are difficult to employ in a high-level fashion. The goal is to create an application framwork that simplifies the task of writing program with real-time requirements for this platform. Having taken a course such as PASA is a definite advantage here. [Contact: Ulrik Pagh Schultz]
• Sensor networks using Smart-Its: The SmartIs project has designed and build a set of small computers usefull as basic building blocks in ubicomp research. It consists of a pair of boards, a communication board and a sensor board. The sensor board has sensors for acceleration, sound, light, temperature, and other things can be added. The communication board can communicate through RF or RS232. These are very generic boards and can be used in a range of applications. See for example the projects home page for the SmartIts project. You might think of you own application where you want to sense something and communicate it with surround SmartIts. Or you may want to add a sensor to the board. [SmartIts homepage] [Contact: Jakob Bardram / Simon B. Larsen]
• Object-oriented modelling of the RCX: Based on the past couple of years of experience in the Lego Lab, there is an interest in developing a library/framework for developing object-oriented applications on the RCX platform. Development can be done either in C++ or in Java using JEPES. [Contact: Ole Caprani]
• Large, interesting application in 4K of ROM and 0.5K of RAM: The JEPES Java compiler supports running applications on Atmel boards with only 4K of RAM and 0.5K of RAM (or more). However, we have very little experience developing interesting applications (e.g., controllers, sensors, etc.) in Java using these boards. The goal of this project is to get a non-trivial program, preferably based on nice, object-oriented programming techniques, running on an Atmel board using JEPES. [Contact: Ulrik Pagh Schultz]

Recommended agent software:

1. POM platform. POM is a virtual machine implemented in Java that executes programs written in Smalltalk, and that supports strong mobility of multi-threaded agent-like entities referred to as systems. Still very preliminary, but good for "adding things" if you're interested in implementing parts of an agent platform. (No documentation, but full support from Ulrik.)
2. JADE and LEAP. JADE is a Java-based, full-fledged agent platform with weak mobility. Fairly complete and under active development. LEAP is a light-weight version of JADE. (Documentation, but very limited support from Ulrik.)

Project ideas:

• Publish/subscribe for agents: Develop support for publish/subscribe for a distributed agent platform, but without relying on a central server, and taking the mobility of agents into account. Develop proof-of-concept applications.
• Develop a graphical application as a mobile agent. Application mobility is interesting in the context of pervasive computing, and mobile agents may be useful for implemeting such applications. Develop a (simple) mobile graphical application for an agent platform, preferably with a "scalable" GUI.
• Develop a FIPA communication model for POM (note: requires CORBA IIOP). FIPA-compliant agents communicate in FIPA ACL over CORBA IIOP. Develop a FIPA ACL interface for POM, so that it is at least capable of performing simple interactions with agents from other platforms.
• Develop a composite device framework using agents. Composite devices are formed by splitting the GUI of a single program across multiple physical devices, e.g. a hand-held and a PC. Implement a program that uses a composite device, such as a drawing program where the tools are on a hand held device, and which (by using mobile agents) initially is located on just the one device.

[Contact: Ulrik Pagh Schultz]

Executable Use Cases (EUCs) are an approach to requirements engineering for pervasive systems. EUCs combine prose, formal models, and animation to represent new work processes and their proposed computer support. The representation enables stakeholders to make interactive investigations of the requirements for the system in the context of the envisioned work processes.

The goals of EUCs are firstly to narrow the gap between informal ideas about requirements and the formalisation that eventually and inevitably emerges when the system is implemented, and secondly to spur communication between users and system developers. Iterative prototyping using prototypes in the form of running programs on a computer as a basis to get feedback from users to system developers would be a feasible starting point to pursue these goals. However, it has been argued for a long time that making an explicit description of the environment in which the system is to be used is important, and usually a prototype only provides an explicit representation of the system itself. We believe that for pervasive computing, whose main aim is to tightly integrate the system into the environment in terms of the work processes to be supported, the argument becomes even more important. Therefore, EUCs compose iterative prototyping and explicit environment description in terms of workflow modelling.

We (Claus Bossen and Jens Bak Jorgensen) have applied the EUC approach to the pervasive health care system envisioned in cooperation between Aarhus Amt, Systematic, and Centre for Pervasive Computing. We are very interested in further developing, maturing, and testing EUCs and see a number of ways to do so. Examples of specific project ideas in relation to EUCs are:

1. Outline EUCs for new application areas.
2. Further develop the existing EUC for the pervasive health care system.
3. Propose and perhaps implement ways to formalise, execute, and animate requirements in your favorite programming or modelling language.

[Contact: Jens Bæk Jørgensen]