CS4220/6235 - Embedded Systems and Real-Time Systems
Fall 2005
Location: College of Computing Building (CCB) 102 Time: MW 4:35-5:55
Instructor: Calton Pu (calton@cc.gatech.edu)
Office: 269 CCB Bldg.
Office hours: by appointment.
TA: Bugra Gedik (bgedik@cc.gatech.edu)
Office: CCB 226B
Office hours: MW 3:30-4:30 CCB 226B or by appointment
Email: please include [CS4220/6235] in the title of your email to get immediate attention
The official due date for the project reports is December 9! See end of the page for details.
The official due date for the project proposal revisions is (was) October 12!
The official due date for the project proposals is (was) September 28!
Course Description
CS4220 (Embedded Systems) and CS6235 (Real-Time Systems) are co-listed this term. This course covers the principles of real-time and embedded systems inherent in many hardware platforms and applications being developed for engineering and science as well as for ubiquitous systems, including robotics and manufacturing, interactive and multimedia, immersive and omnipresent applications. As part of this course, students will learn about real-time and quality of service system principles, understand real-time operating systems and the resource management and quality of service issues that arise, and construct sample applications on representative platforms. Platforms range from handheld and mobile computers to media and real-time server systems. Platforms may also include specialized systems used in application-specific contexts, such as autonomous robotics, smart sensors, and others.
Homework
All students must submit written commentaries for at least 75% of the classes that involve paper study. The final commentary grade will be based on the average of all commentarries, including the ones not submitted (counted as 0). Each commentary should consist of three paragraphs (not too long, since quality is more important than quantity). The first paragraph should summarize the main ideas and the strong points of the paper. The second paragraph should outline the limitations or weaknesses of the paper. The third paragraph contains your own comments. Commentaries should not be simple cut and paste from the papers -- they should display some understanding of the material and criticism of the work (both pros and cons). Only one commentary is due for each class, and unless indicated otherwise, students may choose which paper to summarize.
Commentaries will be graded by 0 (not submitted), 1 (average), and 2 (good). 0.5 and 1.5 are also possible for commentaries that are slightly below or over the average. Commentaries must be emailed to the TA by class time. The title of the email should be in the form [CS4220/6235] (your last name) (the last name of the first author of the paper you have chosen). Please send your commentaries in plain TXT format placing them in your email. Do NOT attach your commentaries especially in .doc or .pdf format. I appreciate your help.
GTID: For some stats, click here.
If you have any problems accessing your grades, please contact the TA.
Projects
Class projects will use the Unix Solaris and Linux operating systems, both of which offer some facilities for construction and control of real-time systems. Class members have access to selected real-time devices and ubiquitous systems, including smart sensors (skiff boards running Linux), possibly including Lego robots (if there is class interest), including handheld devices and portable PCs (Linux-based PCs and PalmOS/Linux-based handhelds and/or wearables), including camera and other video-based sensors on PCs running Windows or Linux, and they can have access to the commercially most prevalent real-time operating system kernel, called Vxworks, running on Pentium and Sparc machines.
Sample applications available to students include multimedia codes (video and audio), distributed games, sensor processing codes, image processing codes, location identification (if there is class interest) and possibly, distributed virtual environments (again, given class interest).
NOTE: The paper links are hosted on an internal web server, so you may download them ONLY FROM ON-CAMPUS HOSTS with Georgia Techdomain (gatech.edu), excluding resnet and eastnet. To download files from remote sites, you can ssh any of the CoC or Gatech Linux/Solaris machines and use wget.
Weeks 1 - 2: Basic Concepts and Research Techniques
Wednesday, Oct 19 TinyOS and Sensor Networks (Bugra)
"System architecture directions for network sensors." Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister. In Architectural Support for Programming Languages and Operating Systems (ASPLOS'00), 2000.
"Specialization Tools and Techniques for Systematic Optimization of System Software", by Dylan McNamee, Jonathan Walpole, Calton Pu, Crispin Cowan, Charles Krasic, Ashvin Goel, and Perry Wagle of OGI, and Charles Consel, Gilles Muller, and Renaud Marlet of IRISA, ACM Transactions on Computer Systems, Vol. 19, No. 2, May 2001, pp 217-251.
"Clearwater - Extensible, Flexible, Modular Code Generation." Galen Swint, Calton Pu, Charles Consel, Gueyoung Jung, Akhil Sahai, Wenchang Yan, Younggyun Koh, and Qinyi Wu. IEEE/ACM International Conference on Automated Software Engineering (ASE 2005). November 7-11, 2005. Long Beach, California.
Weeks 14B-Week 16: Project Presentations
Wednesday, November 23 (5 per class)
Group 3: Evaluation of a Multiplayer Game: Effects of Loss and Latency. [Sudhindra Kota, Mahesh Palekar, Saurabh Shah]
Group 10: Research and development of an intelligent traffic control system. [Stefan Tzanev]
Group 17: A Performance Study of Real-Time Operation System using RTLinux. [Jianli Shen, Zongyu Zhang]
Group 18: Queens and Knights: An Exploration of Hard Real-time Constraints and AI. [Derrick Brown]
Group 8: Distributed Real-Time Collaborative Filtering RSS Feeds. [Edward Newett]
Monday, November 28 (5 per class)
Group 1: Implementation and Analysis of a Cyber Foraging System. [Robert Thomas]
Group 0: A Real-Time Music Genre-Detecting System. [Kunle Oguntebi]
Group 16: Trip Planning. [Daniel Mentz, Roland Aydin, Chung-Yen Huang]
Group 19: An empirical study of Ad Hoc and Infrastructure based peer-2-peer networks for Emergency-Rescue Services. [Farhan Khan, Gabriel Heim]
Group 20: Streaming Media under QoS Constraints. [Sarang Karandikar, Alkesh Shah]
Wednesday, November 30 (5 per class)
Group 11: Benchmarking Several Operating Systems to Determine Real-time Performance. [Charles Frey, Erich Stuntebeck, Brian Faust]
Group 4: PIC-Home. [Quocthanh Thuy]
Group 2: Energy Management of Peripherals in a Real-Time Operating System. [Balasubramanian Seshasayee]
Group 13: Embedded Application Voice Controller. [Han Lu, Pritesh Patel]
Group 15: ATP Board. [Richard Wunderlich, Brian Degnan, Jordan Gray]
Monday, December 5 (4 per class)
Group 7: Locus: A Location-based Enhancement for Instant Messengers [Dylan Dsilva, Raphael Kobi, Dolapo Kuyoki]
Group 6: RTLinux-Powered Sensor Node for Distributed Antenna Array [Christopher Durkin]
Group 12: Real Time Traffic Re-routing. [Anurag Laddha, Chintan Thakkar]
Group 21: Mobile CRM Application. [Sean Thompson]
Wednesday, December 7 (3 per class)
Group 9: A Real-time Note-Taking System. [Echezona Ukah, Kamaram Munira, Alexander Powell]
Group 14: TANAT: The ABIO as a Navigation Assistance Tool [Volkan Oktem, Brent Potter]
Group 5: Real-time imitation and personalized recovery using a Sony AIBO [Aniket Naik, Fayez Mohamood]
Additional, Possible Class Topics:
Structuring and describing real-time software
Real-time languages,vincluding:
Specification and statement of timing constraints.
Verification of timing correctness.
Compiler techniques, including compiling for embedded systems.
Imprecise computation
Object-oriented real-time applications and design tools
Performance Evaluation
Modeling
Measurement and Monitoring
Optimization
Further issues in Real-Time Systems
Real-time database
Reliability
High availability
Multi-version
Replication
Fault tolerance
Graceful degradation
Note
This class is taught every year, by combining the 4220 and 6235 course numbers. It is suitable for both CoC and non- CoC majors, in part because grades are based on project work, which is defined jointly by the instructor and students. The intent is to ensure some basic skills on the part of each student and also to match both student interests/background and course objectives.
Grading
Each student (or team) will present one course topic in class and also complete a class project. Maximum team size for the project is 3 students. In addition, as part of class homework, all students must submit written commentaries for at least 75% of the papers studied in class, before each paper's presentation.
60% Project
20% Commentaries/Class Participation
20% Student Presentations
Project Presentations and Reports
Presentation Instructions:
Length: limited to 18 minutes total when five presentations are scheduled for that class and 30 minutes when three presentations are scheduled.
Mandatory content in four parts
Quick summary of the project proposal (what was promised)
Quick summary of the current results (what was accomplished)
How the project was done (mapping between items 1 and 2)
An evaluation of the achievements
Optional content in remaining time: demos, etc
Report Instructions:
Reports due on December 9th
Project report to be handed (emailed to the TA) in machine-readable form (paper optional)
Reports should include
Source code, documentation, help pages, test and demo code, scripts to build the system, run tests, and demos, links to appropriate documentation for the underlying platforms.
Other documentation that complements the project description. For example, if you built a hardware gadget and you are not handing in the gadget, then you should have enough description of the gadget (photos, pictures, schematics, and documentation) so we can appreciate your work.
A copy of the project proposal, history of changes if appropriate, and the presentation slides.
Project documentation: a few pages of "evaluator guide" to navigate the above listed. Typically, the project documentation should follow the outline of the presentation. However, it should be a more verbose, report-type document that describes how you solved the proposed problem, what were your design choices, what were the problems you encountered, how you evaluated your solution, and the results you got.