Advanced Seminar
Responsible | Sandy Seifarth-Haupold |
Module | DSE-14-E13, DSE-E13, INF-04-HS, INF-AQUA, INF-D-940, INF-DSE-20-E-BDSE, MINF-04-HS |
Scope and Type |
2 SWS exercise |
Cycle | Year round |
This is where suggestions for topics for student lectures at the EZAG are collected.
The EZAG also serves as a platform for the advanced seminar, so there are no special dates for advanced seminar presentations. In order to give a lecture as a student in the advanced seminar, you should either choose a topic from the list on this page or suggest a topic yourself. Afterwards you should contact the supervisor of the chosen topic or me (if you have your own topic) to determine the further course of events and a date for the lecture.
In addition to the advanced seminar presentation, an elaboration is necessary. The exact content should be discussed with the supervisor after the presentation. The elaboration should not exceed 10 pages and should be handed in to the supervisor at most 4 weeks after the advanced seminar presentation. Presentaion and elaboration are necessary to get a certificate. General information on the structure of scientific papers can be found in the section "Thesis/Diploma Structure". The basic structure should be adapted as follows: Introduction, Problem, Related Work (1 page), Core Idea, Details of an aspect, Assessment, Summary. Note: The paper should be written as continuous text (no collection of headwords !), the Duden or spell checker is strongly recommended, page numbering is also desired.
The audience of advanced seminar presentations consists of advanced students and staff. It may be useful to make some references to the OS lecture in the presentation, furthermore basic concepts should be treated as known and the introduction to the lecture can usually be compact. The focus should be on an interesting scientific topic, so that everyone can learn something.
The presentation itself should be designed for a duration of about 30 minutes, unless otherwise agreed upon. Afterwards there are usually 15 minutes for questions. It is advisable to practice the presentation before, so that you can better estimate your own speed.
Suggestions For Topic
Profiling on Linux
Task: Profiling is the process of analyzing the behavior of a single program or whole system to understand the usage of resources, such as CPU time, memory usage, and I/O.
It helps to identify points of bottlenecks (e.g. frequently-invoked and long-running functions) and to optimize program inefficiencies.
Typically, profiling tools sample execution traces of threads to determine frequently-executed code paths.
Visualization tools like Flame Graphs can use this information to approximately depict the distribution of execution time among the various functions.
The goal of this seminar topic is to compare profiling tools for Linux applications/systems and show how they work internally.
Resources:
Supervisor: Viktor Reusch
Aliasing Models for Rust
Task: Safe Rust code ensures memory safety guarantees through compile-time checks and strict ownership rules.
Unsafe Rust allows developers to selectively bypass these guarantees for specific tasks; but it introduces risks of memory corruption, data races, and other safety violations if not used correctly.
In particular, the interplay of references and pointers must follow specific aliasing rules, which are still evolving.
The task for this seminar topic is to review the officially documented rules of unsafe code and compare them with proposed aliasing models like Stacked Borrows.
Additionally, the work should contrast the rules for unsafe Rust with restrictions in other languages (e.g., C++) and hardware capabilities (e.g., CHERI).
Resources:
- Unsafe Rust
- Aliasing – The Rustonomicon
- std::ptr
- Behavior Considered Undefined
- Stacked Borrows
- From Stacks to Trees
- Tree Borrows
- Miri
- Strict Aliasing
- CHERI
Supervisor: Viktor Reusch
ROS 2 and microROS
The Robot Operating System (ROS) is a framework for programming robots. Programs consist of a large number of interacting components, for which an extensive kit of ready-made components is provided. The current version ROS 2 is advertised as real-time capable and thus it is possible to use ROS 2 in safety-critical environments.
The aim of the presentation is on the one hand to present the architecture of ROS 2 and to address the interaction of the components and the real-time properties. On the other hand, alternative implementations such as micro-ROS can also be discussed comparatively, especially their use in embedded environments such as microcontrollers or minimal operating systems.
Resources:
Supervisor: Michael Roitzsch