ERTOS Honours Thesis Projects

Introduction

The thesis topics listed here are available to strong undergraduate students. They are mostly associated with research projects and generally quite challenging; many topics have the potential to lead to a publication, and in average we get about one paper a year from the work of one (or more) undergraduate thesis students.

Students who are not aiming for excellence are in the wrong place here. We are generally looking for honours candidates, or students with outstanding performance in operating systems. Specifically we guarantee a thesis topic to any student who has obtained a HD grade in UNSW's Operating Systems or Advanced Operating Systems course, no matter what their other grades are!

Note that the below list is constantly updated, new topics are added as we identify them as work on various research projects proceeds. Topics marked NEW are recent additions.

UNSW students can access all of our recent student theses.

Present topics supervised by Gernot Heiser (official list)

2980: Native OKL4 Android Stack
Google's Android is an operating system for mobile phones based on a Linux kernel. Actual Android apps are written in Java and run on the Dalvik JVM. Obviously, OK Linux runs on OKL4 and thus Android could be easily made to run on OKL4 as well. But that's no fun.
This thesis is to cut out the middle man and allow Android software to run natively on OKL4. Essentially this requires porting Dalvik to run natively, without a Linux kernel. This is enabled by OKL4's Posix support. Nevertheless, this project is not for the faint-hearted!
2979: Hardware-supported virtualization on OKL4 for ARM
ARM is presently adding virtualization hardware support to their processors (as Intel, AMD etc have done for theirs). This thesis is to design and implement support for this feature for OKL4 and evaluate the performance trade-offs (on a simulator).
2978: VT-x support for OKL4
OKL4 uses para-virtualization to run Linux, even on x86, where pure virtualization is enabled by the VT-x extensions. This makes sense on performance-sensitive mobile devices, as para-virtualization has performance advantages over pure virtualization (see Adams and Agesen, ASPLOS'06). However, there are uses where the convenience of running an unmodified OS binary outweighs the performance penalty.
This project is to evaluate this tradeoff for the OKL4 platform. It will enable the execution of an unmodified Linux binary on the OKL4 hypervisor, and compare the performance with OK Linux (using lmbench and other benchmarks as appropriate).
This topic i quite open-ended, with in-depth performance analysis and performance tuning, particularly when making use of more recent VT-x features, such as two-level virtual-address translation.
2977: SMT kernel locking trade-offs
Multi-threaded (SMT) processors are characterised by shared caches and very low (single-cycle) communication latencies between execution contexts. Consequently, treads on such a system are scheduled from a single scheduling queue, and other kernel data structures are also shared. This makes fine-grained locking hard and potentially expensive. For a kernel where average latencies of kernel operations are very short, a global kernel lock (i.e., single-threaded kernel) could be an appropriate approach.
This project is to investigate global vs fine-grained kernel locking on the OKL4 microkernel running on a highly (>4) multi-threaded processor core. This is likely to lead to publishable results.
2976: NoTA prototype on OKL4
The Network on Terminal Architecture (NoTA) is an emerging approach for structuring software on a mobile phone handset, turning it logically into a distributed system. OKL4 should be the ideal platform for supporting NoTA with low overhead. This project is to demonstrate this by building a prototype NoTA-based system, and evaluate its performance.
2975: OKL4 on OLPC XO-1
Port OKL4 and OK Linux to the one-laptop-per-child laptop.
2867: L4 vs Singularity
The open-sourcing of the Singularity opeating system makes it possible to perform an in-depth comparison with L4. Such a comparison is of significant interest (and publishable) as Singularity and L4 are the leading examples of the two alternative approaches to protection: using language (Singularity) or hardware (L4) mechanisms. The thesis is to perform such a quantitative comparison. This includes comparing performance (IPC, thread- and process creation/deletion, lmbench, macrobenchmarks) as well as security-related measures (eg size and nature of the trusted computing base).
1444 (GH145): Linux multiprocessor scalability
Linux is claimed to be scalable to 1000s of CPU. However, experience shows that this is only really true for HPC workloads that do essentially no system calls.
This thesis is to analyse Linux scalability, identify bottlenecks and suggest approaches to resolve them. Specifically develop and run benchmarks that perform concurrent system calls on multiple processors, and measure they overhead as a function of the number of processors. Use profiling to determine the bottlenecks.
This work is in collaboration with HP and is expected to lead to publishable results.
Day-to-day supervision by Peter Chubb.
1436 (GH142): Analysing the L4 IPC fast path
The high-performance OKL4 microkernel uses an assembler “fastpath” to overcome the performance problems resulting from C code in the critical IPC system call path. Relying on assembler code has a high engineering and maintenance cost, and makes formal verification harder. Eliminating the need for assembler code, or, at least, reducing the amount needed, would have significant practical benefits.
This thesis is to analyse the IPC path in order to understand why C compilers do not do a better job on it. It will analyse possible (semantically-invariant) modifications of the C code, in order to investigate how far C performance can be pushed, and whether it can be made competitive with the assembler implementation. This study is to be done on at least two architectures (x86 and ARM) and using several compilers (gcc, Intel compiler, RVCT, maybe Green Hills).
A thorough and insightful evaluation should be publishable in an OS workshop.
1266 (GH140): Steering-wheel integrated driver controls and display for the Sunswift 4 solar race car
Recent changes to the international technical regulations for solar racing were required to slow the cars below the road speed limit. One new regulation requires a steering wheel. By integrating the driver controls and display into a steering wheel, all driver interfaces with the car can be consolidated in a similar way to Formula 1 racing cars. In addition, the greater visibility and area for controls allows for more functionality to be built into the steering wheel, including all driver controls, data logging, speed control, and a graphical display.
This project will involve the specification, design, manufacture, integration and testing of steering-wheel based computer for a next-generation solar racing car. This will require close collaboration with the UNSW solar racing team. An ideal student would have, or have the ability to very quickly learn, PCB design and low-level software skills.
Day-to-day supervision by David Snowdon
1265 (GH139): Accurate data acquisition for the Sunswift 4 solar race car
The Sunswift solar car has the most advanced electrical system of any solar racing car in the world, with fully-custom electronics feeding real-time telemetry information to the support crew during the race. The car has a 30kg Lithium Polymer battery pack running at up to 164V. Estimating the charge left in the batteries is crucial to implementing good strategy during the race (i.e. never over-filling, or running the batteries flat except at the start and end of the race respectively).
This project would focus on implementing a battery-state-of-charge estimation system for Sunswift electrical systehttp://www.sunswift.com/m. The system would connect to the car's control area network (CAN), allowing these measurements to be read by the driver and wirelessly by the support crew. While the exact approach would be dependent on the student, one method requires an integration of the current into and out of the battery, along with some linear modelling. Ideally, other factors, such as the voltage, would be determined to provide multiple methods of characterisation. Depending on the aptitude of the student, a large number of other useful sensors could and should be developed, including tyre pressure, temperatures, tilt, acceleration, etc. all connected to the car's telemetry network, feeding information to the driver and support crew.
This project would require close collaboration with the UNSW solar racing team. Day-to-day supervision by David Snowdon
1264 (GH138): On-race strategy and data analysis software for the Sunswift 4 solar race car
Modern solar racing cars have a limited battery storage (equivalent to about a third of a day's energy needs, running at 100km/h). This charge must be managed over the course of a race in order to complete the race most efficiently (similarly to the way a a Formula 1 team must manage the car's fuel through the duration of a race). Additionally, real-time telemetry data from the car must be analysed to determine the car's correct operation, and the severity of any faults. Data about the course, data being transmitted from the car itself, data from sensors around the support fleet (wind speed/ direction, solar radiation, road conditions, etc), and anecdotal data from the support crew can all be taken into account.
This project would first of all develop models for the behaviour of a solar car. A testing scheme would be developed and data gathered (via on-road testing) to characterise the models. A software system would be developed to analyse data coming from the car with respect to these models. Finally, methods for choosing the speed at each point along a pre-surveyed course would be implemented. The entire package should be tested on-road with Sunswift 3 in preparation for future solar car races. Depending on the success of the strategy decisions, the optimal speed could be fed back to the car's cruise control system in real-time, allowing for intelligent, efficient, autonomous cruise control.
This project would require close collaboration with the UNSW solar racing team. Day-to-day supervision by David Snowdon
1263 (GH137): Maximum power point tracking for the Sunswift 4 solar race car
Maximum power point trackers allow a solar panel to operate under its optimal operating conditions. They are a power electronics device which converts between the panel's optimal operating voltage and the output voltage which is determined by the battery state of charge. MPPTs have generally been a weak point of the Sunswift race cars. The team have designed a highly efficient (>98%) MPPT, with reliable hardware, but the control software has a number of issues which causes the devices to behave sub-optimally.
This project would, depending on the student's aptitude, first of all perfect the control software for the MPPTs in Sunswift 3. Secondly, implement new features such as diagnostics (IV curve sweeps) and improved tracking algorithms (aiming to improve the solar array power output), and explore efficiency-increasing behaviours (e.g. synchronous rectification). Lastly, depending on the available time, the student would look at implementing improved MPPT hardware based on a novel power-electronics architecture.
This project would require close collaboration with the UNSW solar racing team. Day-to-day supervision by David Snowdon
605 (GH110): Multi-kernel fault tolerance
Fault tolerance of computer systems is important in mission-critical applications. A number of standard approaches to fault tolerance exist, including hardware- and software redundancy. However, protection from redundancy-based approaches is limited, as long as the redundant components are identical, and thus likely to fail in exactly the same way at the same time. A more reliable approach to redundancy-based fault tolerance would employ components that are independently engineered to the same (or compatible) specification.
While this is a reasonable approach at the application software level, the cost of independently manufactured operating systems is normally prohibitive. Given that failure of the operating system is generally fatal for the system, this implies serious limitations for practical fault tolerance.
However, the small size and simplicity of a microkernel could make kernel-level redundancy feasible. Furthermore, on some architectures there already exist independently engineered implementations of the L4 microkernel, namely L4Ka::Pistachio and Fiasco. This thesis is to investigate the use of these independent kernels as a redundant fault-tolerant operating systems platform on a suitable SMP or SMT system, and design and implement a prototype.
If successful, this work can lead to a landmark publication.
594 (GH109): BLUEsat OS
Design and implement an operating system for the BLUEsat student satellite project. The operating system will require a high degree of fault tolerance, including resilience against memory errors, and a very high degree of robustness.
498 (GH99): Multics on modern hardware
Forward-port Multics to Itanium or 64-bit PowerPC.
While this topic had originally been posed as a joke (which not everybody got), the recent release of Multics sources means that this could be looked at seriously. Nevertheless, it isn't for the faint-hearted!
488 (GH96): Sunswift OS
Design and implement an L4-based operating system for Sunswift, the UNSW solar racing car. Sunswift features a CAN-based control system with a PLEB for central coordination and external communication. The PLEB presently runs Linux and L4.
This project will build a new, lightweight OS for Sunswift, specially designed to meet the car's requirements for real-time control, communication and reliability. It will be based on Iguana and serve as a demonstrator for the groups embedded-systems framework. Suitable for a student with a good OS background, L4 experience and an interest in embedded systems and interfacing to hardware.
57 (GH46): Port OKL4 to SuperHitachi
Port OKL4 to the SuperHitachi architecture. This will cover the last outstanding mainstream general-purpose architectures for L4.
Serious operating system kernel hacking.... Only suitable for students with very strong OS background and a good understanding of architectural issues.

I will not take on students who have not shown a convincing performance in COMP3231 ``Operating Systems''. I normally expect students to have done COMP9242 ``Advanced Operating Systems'', although I make exceptions in special cases.

Most topics can lead to publications.

Present topics supervised by Ihor Kuz (official list)

Background

The following projects are related to embedded systems applications and componentised embedded operating systems. We are looking at a wide range of embedded applications in order to get a feel for the complexity and issues involved in designing and building such systems. We will use this experience to aid in the further design and development of an embedded systems framework (a software framework for building and deploying embedded applications) and embedded component architecture (a component-based programming architecture especially targeted at embedded systems).

Topics

IK24: Non-C languages on L4
Currently almost all software for L4-based systems is written in C. There are however many languages whose runtimes or interpreters could be ported to run on L4 as well. For example, Python was ported to Mungi, an early version of Io was made to run on L4, as was a very simple version of the Squeak Smalltalk system, and Lua was also ported to L4/Iguana. However, none of these run on current versions and, as such, we are still limited to using C for programming all L4-based applications. In this project you will choose a favourite language and port its runtime or interpreter and critical libraries to run on L4. Furthermore you should integrate the language into the L4 environment such that code written in that language can invoke L4 system calls, perform IPC and transfer data to processes implemented in other languages. (see also 2980: Native OKL4 Android Stack)
IK23: Shared resources in an microkernel-based OS
One of the key services that an OS provides is a managing access to shared resources. For example, a file system manages access to shared disk space, a network stack manages access to a network device, a window system manages access to the display, etc. In a modular, microkernel-based OS, these shared resources are managed by user-level services. In this project you will investigate ways of modelling such shared resource managers within the CAmkES component framework on L4 and develop a suitable model for building such services in a componentised environment. You will assess the suitability of this model by designing, implementing, and evaluating one or more such services (e.g., a file system, a network stack, etc.).
IK22: Component Architecture on Secure Microkernel
The seL4 kernel is a new secure version of the L4 microkernel. CAmkES is a component architecture designed for building microkernel-based operating systems. Currently CAmkES is based on L4 and does not address security issues. The aim of this project would be to get CAmkES working with seL4 and then explore the ways that seL4 security features can be leveraged by CAmkES to build secure embedded systems.
IK15: Video game console
Design a video game console system (based on CAmkES and L4) that is programmable but cannot be 'hacked' i.e., games cannot be used to override the default OS or other security software.
IK14: Programmable security camera
Design and build a networked and programmable security camera based on L4/Iguana. It is basically a regular security camera that can be programmed to do image manipulation, analysis, etc. directly in the camera. There are numerous security issues involved, e.g., there must be a tamper proof way of marking images as originals. There are also real-time issues to deal with.
IK11: Display architecture for L4
Explore the possibilities for a display (GUI) architecture for L4/Iguana. It should be flexible so that it can be used on many different kinds of (embedded) displays (PDAs, phones, watches, media players, etc.). The project will include exploring existing embedded graphics display architectures (e.g., QT/embedded) and evaluating whether basing such an architecture on L4/Iguana would provide benefits or drawbacks.
IK10: Click Modular Router on L4
Investigate, design and implement a Click compatible modular network router architecture on L4 making use of the CAmkES component framework. Click is a software architecture for building network router software from small, reusable, software components, while CAmkES is a component-based framework for developing L4-based systems. Given the componentised nature of both Click and CAmkES, it should be possible to define a Click router in terms of CAmkES components. The project will require you to design a framework on L4 that will allow Click components to be reused to build network routers. Besides designing and implementing this framework, you will also reuse existing Click components to build several variations of network routers and compare the performance of your implementation to existing Click implementations.

How to apply:

Contact the relevant supervisor.

Note: We promise a thesis topic to every interested student who has obtained a HD grade in COMP3231/COMP9201 Operating Systems or COMP9242 Advanced Operating Systems. If necessary we will define additional topics to match demand.

We will not turn down any students doing exceptionally well in OS courses. However, this does not mean that an HD in OS or Advanced OS is a prerequisite for doing a thesis with me. Interested students with lower OS marks are welcome to talk to me if they feel they can convince me that they will be able to perform well in an OS thesis.

Keep in mind that these topics are all research issues and generally at the level of Honours Theses. They are not suitable for marginal students or students with a weak understanding of operating systems. We expect you to know your OS before you start.

Past thesis reports and DiSy thesis rules (internal access only)

Postgraduate thesis topics:

Undergraduate thesis topics are also suitable for coursework Master's projects. Same conditions apply: You must have a pretty good track record in OS courses.

Information about research theses

Return Home