Project

Overview

The goal of the term project is to give you the opportunity to get your hands dirty on a concrete problem related to real-time systems, fault-tolerant systems, and related domains such as sensor networks, robotics, multimedia, etc. The project will be performed in teams of 1-3 students and each team will prepare a project proposal in consultation with the lecturer. Further, the teams will be responsible for frequent progress reports, demos, a term paper, and final presentation.

First Milestone: Forming of Teams and Project Proposal

The first milestone is to form teams (unless you insist on working alone) and to find and describe a project you and your team mates want to work on. The outcome of this first step will be a project proposal. Please follow these steps:

Form a team of 1-3 members. If you need help in finding team mates with similar interests, contact the instructor. Teams of size 2 are preferred, but teams of size 3 and individuals working alone are fine too, the expectations will be adjusted depending on the team size.
By September 9 the team must submit a first draft of a project proposal and a paper study (see details below). The goal is to give you an opportunity to identify a research area of interest and to learn more about the field before you define a concrete problem. Also, the instructor's feedback will allow you to define a more specific topic.
By September 16 a full project proposal has to be submitted. The instructor will provide feedback (approval, desired modifications and adjustments, etc.) by September 20.
While these are absolute deadlines, feel free to become active in team building and topic search immediately and begin on your project right away, especially if you know already what you want to work on. Also feel free to consult with the instructor as often as needed (from now on until the submission deadline for the project proposal) to discuss ideas, topics, reading suggestions, etc. The instructor will also provide a list of suggestions (see below) which can be used to identify topics of interest.

Second Milestone: Progress Reports

On October 12 and 14, the teams will provide short (at most 10 minutes) presentations on their progress in the projects. This will happen in class and students should prepare up to 5 slides that outline the problem they are working on, the approach they are taking, the goals achieved, the outstanding goals, and any preliminary results that may be available. This is accompanied by a written report of up to 5 pages (see report requirements below).

Third Milestone: Draft of Term Paper

On November 18 a draft of the term paper is due. The form, content, and quality should be of workshop-quality (see below). The papers will be exchanged among class mates and with students from the Operating Systems course, and a peer review process will begin (with reviews due on November 22). The feedback from the review process is very valuable feedback and should be considered for the final paper version. Details about the peer review process will be provided in due time.

Fourth Milestone: Final Paper

The final paper is due on December 12 and has to be complete with all results (paper requirements described below).

Fifth and Final Milestone: Project Workshop

The teams will present their results in a workshop to be held at the Department (time and location TBD). Each team will have about 20 minutes for presentation and 5-10 minutes for Q&A from the audience. Depending on time constraints, the workshop may be held in conjunction with paper presentations of the Operating System course.

Project Proposal

The project proposal consists of two parts: the actual work you propose and an annotated bibliography of research papers in the field of the proposed work. While there are no page restrictions for the bibliography, the actual proposal has to be at most 3 pages for the draft and 4 pages for the final version. Your proposal should have the following sections:

Introduction: Outline the problem you are addressing. The introduction should be sufficient for a reader to understand the problem domain, why previous solutions are missing or insufficient, why the problem is relevant, and how your work will fill the gap.
Related Work: Based on the annotated bibliography (see below), refer to the most relevant prior work and describe how your approach will differ from or build on previous solutions.
Proposed Work: This is the main section, here you desribe in detail what you are trying to accomplish. Outline your approach (high-level architecture, interfaces, etc.), the hardware/software tools needed or the modifications you expect to do to existing software (e.g., extensions to operating systems), etc. A reader of the section should have a clear idea what you will be working on for the next few months.
Assessment and Evaluation: A key issue is how to evaluate your work, i.e., quantitative results should compare your work with some sort of baseline (e.g., previous work) and underline how/why your solutions works or is better (in terms of real-time characteristics, fault tolerance, performance, Quality-of-Service, ...) than other solutions. Desribe how you will evaluate your work and the expected results (what kind of graphs do you expect to have in your final paper). Also, don't forget microbenchmarks, i.e., evaluations where you study the performance or overheads of individual components of your work.
Work Plan and Schedule: In the work plan you have the opportunity to discuss which team member will be responsible for which component of the proposed work, how you will integrate different components, and when you will submit which milestones (progress reports, etc.). It may be wise to be overly optimistic (setting milestones early), such that you have sufficient time to catch up in case you fall behind (unexptected problems in the implementation, hardware problems, sickness, etc). If you feel that you deviated from the schedule too much to be able to catch up, immediately contact the instructor to discuss adjustements to both schedule and proposal.
Summary of Contributions: This section should summarize the expected key contributions of your work and the expected results of your evaluations.

Annotated Bibliography and Paper Study

This part of the proposal will help you identify a topic of interest to you and your team members. There is no golden rule how to quickly find an interesting and relevant topic, but consider the following suggestions:

Look at the list of project suggestions below and identify one that seems most attractive to you. Each suggestion contains a number of key words, use these to find revelant papers in the problem field (find a list of relevant conferences below).
Start with a very broad topic, say 'real-time scheduling' and read some papers in that field. Then refine the field, e.g., to 'real-time scheduling for multimedia streams' and read some more papers, etc., until you arrive a sufficiently detailed problem.
Talk to the instructor. Be somewhat prepard when you meet, e.g., look at the list of suggestions or the technical programs of previous real-time systems conferences, to be able to quickly agree on a specific problem.
If you are a graduate student and already have an advisor, think about real-time issues in your ongoing work or discuss with your advisor potential projects or problem domains.

The majority of the papers discussed in the annotated bibliography should be very specific to the problem field you will address in your proposal. The bibliography should have at least 10 papers articles PER TEAM MEMBER (if you work alone, at least 10 papers, if you work in a team of 2, at least 20 papers, etc) and complete references have to be provided (name of authors, title, journal/conference/book paper appeared in, month and year, and location if conference paper). It may be wise to split the task of reading and writing among all team members, where team members explain to each other the key concepts of each paper. Each paper should be described (key contributions, approaches, outcome, shortcomings, future work and open problems) in a very brief and concise manner (a short paragraph of 5-10 sentences). Keep in mind that these are recent research papers, there is no need to read a paper thoroughly. The goal is to understand the problem addressed in a paper, the approach chosen to solve the problem and the outcome. Look closely to the results and the future work sections of a paper, these may help you identify open issues.

List of Relevant Conferences/Journals

This is a list of conferences and journals that address problems related to the topics discussed in class. The conference links point to the most recent conferences in the series, for previous years you can use a search engine (type in the name of the conference and the year). If a conference/journal is not exclusively a real-time systems event (i.e., not the name 'real-time' in the title), the look for appropriate sessions in the program (e.g., "Real-Time Computing", "Fault-Tolerant Computing", "Embedded Systems", "Resource Management", "Low-Power Computing", etc).

Real-Time Systems Symposium
Real-Time and Embedded Technology and Applications Symposium
Euromicro Conference on Real-Time Systems

International Conference on Dependable Systems and Networks
Symposium on Operating Systems Principles
Symposium on Operating Systems Design and Implementation
USENIX Annual Technical Conference
International Conference on Mobile Computing and Networking
Search for papers in the "Journal of Real-Time Systems", "Transactions on Embedded Computing", "Transactions on Mobile Computing", or "Transactions on Computers".
Use tools such as www.citeseer.com. They also allow you to see who referenced a paper you were looking for, e.g, to find the most recent papers.

Project Suggestions

Look at this link to find project ideas and keywords, these are meant to help you in identifying a project for your team.

Project Suggestions

Paper Requirements

It is wise to start writing toward your final document very early (e.g., write the proposal and progress reports so that they can be reused in the final document). Graduate students have to use TeX/LaTeX to submit their reports (see tutorial and template below), undergraduate students are free to use other tools (Microsoft Word, Adobe Acrobat, etc), however, PDF or postscript files are desired for their submissions. While reading papers for the paper study, have a close look at the outline and style. You will see that the structure of these papers are very similar (abstract, introduction, approach, implementation, evaluation, related work, summary, future work), try to structure your reports/paper accordingly.