REFLEX Ein Echtzeitbetriebssystem für tief eingebettete Systeme

Transkript

1 Forum der Forschung 21/2008: BTU Cottbus, Eigenverlag, ISSN-Nr.: REFLEX Ein Echtzeitbetriebssystem für tief eingebettete Systeme Kurzfassung Jedes komplexere technische Produkt enthält heute Kleinstrechner, die in Echtzeit vielfältige Steuer- und Regelvorgänge vornehmen. Diese sogenannten eingebetteten Systeme verwenden aus Kostengründen ressourcenarme Microcontroller, die aufgrund ihrer Betriebsmittelknappheit die Softwareentwicklung zu einer besonderen Herausforderung machen. REFLEX (Real-Time Event FLow EXecutive) ist ein ereignisgetriebenes Echtzeitbetriebssystem für solche tief eingebetteten Systeme, das selber nur einen extrem geringen Speicherbedarf hat und dennoch eine objektorientierte Softwareentwicklung dem Stand der Kunst entsprechend ermöglicht. Beispielhaft wird dies in diesem Beitrag anhand eines komplexen Hauskontrollsystems gezeigt, das von der Heizungssteuerung mit zwei Brennern, über ein bewegliches Solarpanel bis hin zur Licht- und Alarmanlage alles zuverlässig mit nur einem einzigen kleinen Mikrocontroller steuert. Abstract Nowadays every sophisticated technical product is based on computer electronics, often used to realize a sort of real-time control. These so called embedded systems engage low-end microcontrollers for economical reasons, which makes it challenging to implement high quality software for those systems. REFLEX (Real-Time Event FLow EXecutive) is an event based real-time operating system for such an environment. It has low memory requirements, even though it allows state of the art object oriented software development. This paper shows exemplarily, how a complex house control application can be implemented at a high abstraction level, using only one microcontroller. Hauptspeicher. Aufgrund dieser Einschränkungen ist es bis heute üblich, selbst komplexe, nebenläufige Steuersysteme unter Verzicht auf jegliche Betriebssystemplattform direkt in Maschinensprache zu entwickeln, eine fehleranfällige und kostenträchtige Vorgehensweise, die nur bei hohen Produktstückzahlen rentabel ist. REFLEX (Real-Time Event FLow EXecutive) ist ein leichtgewichtiges Echtzeitbetriebssystem für solche tief eingebetteten Systeme. Das System beruht durchgängig auf einem Ereignisflussmodell, das problemadäquate Abstraktionen für die Programmierung von nebenläufigen Steuerungssystemen bietet, die auf vielfältige externe Ereignisse (ausglöst durch Sensorik bzw. Aktuatorik) reagieren müssen. Bereits auf der Modellebene können wesentliche Eigenschaften einer Anwendung etwa die Echtzeitfähigkeit oder Synchronisation überprüft bzw. sichergestellt werden, während die eigentliche Implementierung dem Stand der Technik entsprechend mit Hilfe einer objektorientierten Hochsprache (C++) erfolgt. Dadurch wird nicht nur die Softwareentwicklung deutlich vereinfacht, sondern es ist möglich, selbst komplexe, nebenläufige Steuerprogramme auf einfachen und kostengünstigen Mikrocontrollerplattformen ablaufen zu lassen. In diesem Beitrag zeigen wir dies beispielhaft anhand eines auf REFLEX basierenden Hauskontrollsystems, das kostengünstig ausschließlich mit Standard-Hardware realisiert wurde und inzwischen seit vier Jahren zuverlässig seinen Dienst versieht. In Abschnitt 2 geben wir zunächst einen kurzen Überblick über das RE- FLEX-System. Danach stellen wir in Abschnitt 3 das Hauskontrollsystem mit seiner Sensorik und Aktuatorik vor. Abschließend fassen wir unsere Erkenntnisse noch einmal kurz zusammen und geben einen Ausblick auf weiterführende Arbeiten. 1 Einleitung Im täglichen Leben sind wir von Millionen von Mikrocontroller-basierten Systemen umgeben, die als Bestandteile technischer Systeme aller Art von der Waschmaschine bis zum Flugzeug zuverlässig im Verborgenen wirken. Ohne diese eingebetteten Informatiksysteme ist heutzutage kaum ein komplexes Produkt mehr vorstellbar. Aus Kostengründen kommen in diesem Bereich fast ausschliesslich betriebsmittelarme Mikrocontroller zum Einsatz. Diese Ein-Chip-Rechnersysteme haben nur eine geringe Rechenleistung und bestenfalls wenige KB 2 Das REFLEX-System REFLEX ist ein ereignisgetriebenes Betriebssystem, in dem jegliche Steuer- und Regelvorgänge von externen Ereignissen (Interrupts) initiiert werden. Letztere werden von Geräten (Timer, Sensorik, Aktuatorik) ausgelöst, wenn z. B. Uhren abgelaufen sind, Schwellwerte erreicht oder überschritten werden oder eine angeschlossene Aktuatorik eine definierte Postion erreicht hat. Diese Ereignisse lösen eine direkte Vorbehandlung durch Unterbrechungsbehandlungsroutinen aus, die ihrerseits bei Bedarf sogenannte Aktivitäten anstoßen können. Aktivitäten implementieren die eigentlichen Steuer- und Regelfunktionen 59

2 und sind passive Objekte, die Zustandsinformationen über mehrfache Aktivierungen hinweg speichern können. Dadurch wird auch nur ein einziger Stapel (Stack) benötigt, was im Gegensatz zu Systemen mit mehreren Kontrollflüssen signifikant Speicher einspart. Aktivitäten können über Ereigniskanäle miteinander verknüpft werden, sodass eine komplette Anwendung sich als gerichteter Graph darstellt, entlang dessen Kanten zur Laufzeit Ereignisse propagiert werden. Das Schreiben eines Wertes in einen Ereigniskanal führt dazu, dass dieser Wert nach einer wählbaren Strategie gespeichert und die mit diesem Kanal assozierte Aktiviät vom Scheduler für den späteren Ablauf eingeplant wird. Hat eine Aktivität mehrere Eingänge, wird sie nur dann eingeplant, wenn an allen Eingängen Daten anliegen. In Abb. 1 ist ein typischer Ereignisflussgraph dargestellt. Abbildung 1: Ereignisflussgraph für PWM Temperaturmessung In dem Beispiel signalisiert eine trigger-aktivität einem Temperaturfühler mit PWM-Controller (Pulse Width Modulation), dass ein Rohwert aufgenommen werden soll. Die capture-aktivität started daraufhin den Messvorgang. Die PWM-Hardware initiiert nun bei der nächsten Signalflanke eine Unterbrechung und misst die Pulsweite. Dieser Rohwert muss zur Weiterverarbeitung seinerseits in einen Temperaturwert konvertiert werden und wird dazu einfach auf den Eingangskanal einer Konversionsaktivität convert geschrieben. Letztere wird dadurch angestoßen, konvertiert den empfangenen Rohwert und schreibt ihrerseits den Wert auf den Ereigniskanal einer evaluate-aktivität, die den Wert daraufhin auswertet. An dem Beispiel ist gut zu sehen, dass funktionale Komponenten sowohl Aktivitäten als auch Unterbrechungsbehandlungsroutinen kapseln können. Die Kommunikation zwischen Komponenten erfolgt immer asynchron über Ereigniskanäle, während alle Aktivitäten innerhalb einer Komponente auch auf gemeinsame Zustandsvariablen zugreifen können, ohne sich explizit zu synchronisieren. Dies setzt jedoch voraus, dass alle beteiligten Aktivitäten die gleiche Priorität besitzen. Dieses Konzept ist ähnlich zu TinyGALS (Globally Asynchronous Locally Synchronous) (CHEONG, LIEBMAN, LIU & ZHAO, 2003). Die asynchrone Form der Kommunikation über Ereigniskanäle erfordert Puffer am Ende der Ereigniskanäle, deren Typ frei konfiguriert werden kann. REFLEX stellt zu diesem Zweck Standardpuffer wie Warteschlangen, Fifos mit definierbarer Tiefe oder verschiedene Einzelwertpuffer zur Verfügung. Der Zugriff auf diese Puffer erfolgt implizit und atomar bei dem Beschreiben bzw. Lesen des zugehörigen Ereigniskanals. Aufgrund dieser Eigenschaften sind die meisten Applikationen bereits implizit synchronisiert (WALTHER & NOLTE, 2006), was die Gefahr nichtdeterministischer Synchronisationsfehler deutlich herabsetzt. Weiterhin wird für jedes Datum im Puffer ein Planungsvorgang angestossen und die Aktivitäten können sich immer darauf verlassen, dass mit jeder Aktivierung auch gültige Daten vorliegen. Alle Aktivitäten haben grundsätzlich eine sogen. run-to-completion-semantik wie es in ereignisgetriebenen Systemen allgemein üblich ist. Diese Semantik verbietet es, dass Aktivitäten in Endlosschleifen gehen oder blockierend warten. REFLEX ist jedoch ein objektorientiertes System und die Aktivitäten sind nicht nur durch einfach Funktionen repräsententiert, sondern durch Objekte (Instanzen von C++-Klassen), die mit einer virtuellen run()-methode assoziiert sind. Daher können Aktivitäten auf einfacheweise Zustandsinformationen über mehrfache Aktivierungen hinweg bewahren. Ferner ist das Ereignisflussmodell orthogonal zur verwendeten Planungsstrategie. Das Scheduling-Rahmenwerk (WALTHER & NOLTE, 2007) von REFLEX umfasst die Strategien FCFS (First Come First Served), FP (Fixed Priority), EDF (Earliest Deadline First) und TT (Time Triggered). Die FP- und EDF-Scheduler umfassen außerdem präemptive wie nichtpräemptive Versionen. Alle Varianten nutzen lediglich einen einzigen systemweiten Stapel, wodurch der Speicheraufwand gegenüber Thread-basierten Systemen drastisch sinkt. Ermöglicht wird das durch die run-to-completion- Semantik der Aktivitäten. Die Planungstrategie kann zudem einfach ersetzt werden, ohne den eigentlichen Anwendungskode zu verändern. Dadurch wird die Wiederverwendbarkeit von existierendem Code in neuen Anwendungskontexten deutlich vereinfacht und neue Applikationen können aus vorhandenen Komponenten zusammengestellt werden. Zudem kann eine Aktivität unabhängig von deren Implementierung parametriesiert werden, um deren Ausführung in fest vorgegebenen Zeitschranken (Deadlines) sicherzustellen. 3 Fallstudie: Das Hauskontrollsystem Das betrachtete Hauskontrollsystem steuert zum einem das Heizungssystem und zum anderen die Alarm- und Lichtanlage (Hoflicht). Das Heizungssystem allein ist bereits komplex und besteht aus einem Ölbrenner, einem Holz-Kohlenofen, einem beweglichen Solarpanel, diversen Raumheizungen, zwei Warmwasserspeichern, mehreren Pumpen und Temperatursensoren. Das Hoflicht- und Alarmsystem umfasst diverse Reed-Relais an Toren und Türen, sowie Lampen, Lichtsensoren und eine Alarmsirene. Beide Subsysteme beziehen von einer batteriegepufferten DCF77-Funkuhr die lokale Uhrzeit. Alles in allem umfasst die Steuersoftware neun verschiedene Gerätetreiber, von denen fünf unterbrechungsgetrieben und vier zeitgesteuert arbeiten. Ferner ist neben einem obligatorischen Watchdog-Treiber zur Selbstüberwachung auch ein Subsystem für die Ein-/Ausgabe vorhanden. Insgesamt überwacht das System 24 Sensoren, steuert 16 Aktuatoren und kommuniziert außerdem mit 6 externen Geräten. 60

3 3.1 Die Heizungs- und Warmwassersteuerung Die Warmwasserversorgung des Hauses wird über 2 Speicher mit einem Gesamtinhalt von 860 Litern sichergestellt. Die Wasserspeicher werden durch das Solarpanel, den Holz-/Kohlebrennofen und den Ölbrenner beheizt. können. Deshalb sind die beiden Öfen in Reihe geschaltet, zuerst wird das Wasser durch den Holzofen erhitzt und durch den automatisch kontrollierten Ölofen nur bei Bedarf zugeheizt. Das Solarpanel ist das primäre Heizsystem und hat eine Fläche von 3m 2 (Abb. 2). Das Panel wird mit dem Lauf der Sonne mitbewegt, um einen hohen Wirkungsgrad zu erzielen. Die Position des Panels wird deshalb stündlich korrigiert. Die beste Position für jede Stunde wurde für jede Jahreszeit a priori ermittelt. Der Motor des Panels besitzt eine eigene Stromversorgung. Endschalter zu Beginn und am Ende des Weges sorgen dafür, dass das Panel sich nicht um sich selbst dreht und die eigenen Kabel und Schläuche abdreht. Diese Schalter sind aufgrund der Ungenauigkeit des Positioniermotors notwendig. Mit einem präziseren Motor könnte man auch darauf verzichten, dies würde jedoch den Preis der Anlage unnötig in die Höhe treiben und würde die Steuerung auch nicht vereinfachen. Abbildung 3: Die beiden Öfen, Holz (links) und Öl (rechts) Abbildung 2: Das bewegliche Solarpanel Abb. 4 zeigt den Heizverlauf für einen Novembertag. Im oberen Teil ist zu sehen wann die Heizkreispumpe (Heating Circuit Pump) und der Ölbrenner (Oil Burner) aktiv waren. Im unteren Teil sind verschiedene Temperaturen für ein Zimmer, den Rücklauf, den Holzofen und den Ölbrenner aufgetragen. Bis 6.00 Uhr morgens wurde keine Heizung benötigt, da in der Nacht die Restwärme des Systems zum beheizen ausreichte. Um 6.00 Uhr morgens wurde der Ölbrenner gestartet, woraufhin sich auch die Rücklauftemperatur erhöht. Durch die Geschwindigkeit, in der die Rücklauftemperatur sich erhöht oder abfällt kann der Heizbedarf ermittelt werden. Gut zu sehen ist dies beim ersten Anstieg, der flacher ist als die Folgenden, da beim ersten Start das Rohrleitungssystem mit erwärmt werden muss. Danach weist die Regelung ungefähr einen 40-minütigen Zyklus auf. Das warme Wasser für das Heizsystem wird in den beiden Öfen (Holzofen VEB Niederkirchner Berlin und Hansa Ölofen, Abb. 3 links und rechts) aufgeheizt. Im Gegensatz zu den meisten Systemen, die Heizwasser unabhängig vom Verbrauch produzieren, wurde hier ein verbrauchsorientiertes System ähnlich dem Bajorath-Verfahren (BAJO- RATH, 2005) implementiert. Dazu wird mit Hilfe eines Temperatursensors die Temperatur des rückfliessenden Heizungswassers bestimmt und daraus auf die im Haus absorbierte Energie geschlossen. Dieses Kontrollsystem verringert effektiv die Anzahl der Startvorgänge im Ölbrenner, da dieser gerade nach dem Start sehr ineffizient arbeitet und eine längere Aufwärmphase benötigt. Beide Heizöfen haben höchst unterschiedliche Eigenschaften. Der Ölofen ist vollständig durch das Kontrollsytem steuerbar, der Holzofen jedoch kann nur überwacht werden und muss manuell befeuert werden. Dieses lohnt sich aufgrund des hohen Ölpreises und aufgrund der Tatsache, dass die Bewohner sich selbst mit Feuerholz versorgen Abbildung 4: Heizverlauf an einem Novembertag 61

4 Um Uhr hat jemand versucht, den Holzofen zu starten. Der Kurve ist zu entnehmen, dass dies fehlschlug, weil die Temperatur nur von 10 auf 20 Grad Celsius gestiegen ist. Der Ofen brennt normalerweise ca. 2-3 Stunden, weshalb gegen Uhr wieder jemand zum nachfüllen kam und das Problem festgestellt hat. Diesmal war das Anfeuern erfolgreich, wie man an der Temperatur von ca. 65 Grad sehen kann. Da der Ölbrenner ebenfalls noch brannte, erreicht die Wassertemperatur beinahe 80 Grad. Wenn der Holzofen das Wasser auf über 40 Grad erhitzt hat, wird der Ölbrenner automatisch abgestellt. Da er sich jedoch in heißem Zustand befand, dauerte das Abkühlen noch eine Weile. Alle Türen werden außerdem durch das Alarmsystem überwacht. Normalerweise werden die Türen nur zwischen 6.00 und Uhr geöffnet. Außerhalb dieser Zeit werden alle Türöffnungen gemeldet. So werden potentielle Eindringlinge erfasst und die Bewohner daran erinnert, alle Türen nach Uhr geschlossen zu halten. Das gesamte Alarmsystem ist vollständig ereignisgetrieben, d. h., alles wird durch einen Zustandsautomaten gesteuert, der nur auf Ereignisse der Sensorik reagiert. Ein zeitgesteuertes oder zyklisches Abfragen der beteiligten Sensorik ist daher nicht notwendig. Ein eher ungewöhnlicher Aspekt des Heizungssystems ist die beheizte Hundehütte (Abb. 5). Da die Temperaturen im Winter beträchtlich niedrig sein können, wurde hier eine rein elektrisch betriebene Heizung für die Hundehütte vorgesehen, die ebenfalls mit Hilfe eines Sensors automatisch frostfrei gehalten wird. Abbildung 6: Skizze des Anwesens 3.3 Die Hauptkontrolleinheit und periphere Hardware Abbildung 5: Die beheizte Hundehütte 3.2 Das Hoflicht- und Alarmsystem Abb. 6 skizziert das Anwesen. Die bereits beschriebenen Öfen sind im oberen Mittelteil dargestellt. Das obere Gebäude war ehemals ein Stall, der jetzt als Garage und Waschküche dient und außer den Öfen auch die Holz- und Ölvorräte beherbergt. Das Wohnhaus ist auf der linken Seite zu finden. Die Gebäude rechts und unten sind Wirtschaftgebäude. In der Mitte des Bildes sind die Positionen der Lampen (n-p) und der Lichtsensoren dargestellt. Wenn es draußen dunkel ist und eine der Türen geöffnet wird, wird automatisch das Hoflicht eingeschaltet. Zwei der Lampen bleiben auch nach dem Schliessen aller Türen für weitere 20 Sekunden eingeschaltet, damit man den Hof problemlos überqueren kann. Die dritte Lampe (p) wird hingegen als Rückmeldung sofort abgeschaltet. Die Hauptkontrolleinheit besteht aus 6 Elementen. Zwei Netzteile (12 Watt bei 5 V bzw. 12 V) sind für die Stromversorgung der Sensoren und der Kontrollrelais verantwortlich. Die digitalen Ein- und Ausgänge der Sensorik/Aktuatorik werden über 4 I2C-Schnittstellenbausteine mit 8 Bit Breite angeschlossen, wobei 2 für die Eingänge und 2 für die Ausgänge verwendet werden. Die Eingänge bekommen Daten von den Türkontakten, dem Lichtsensor und den Endschaltern des Solarpanels. Die Platine mit dem steuernden Mikrocontroller ist eine CardD64 der Fa. Elektronikladen, die mit einem 8 MHz Freescale HC(S)12 mit 4 KB Hauptspeicher und 64 KB ROM bestückt ist. Die kleine Platine ist in Abb. 7 im oberen Mittelteil zu finden. Auf diesem Microcontroller läuft das gesamte Hauskontrollsystem. Neben der Hauptkontrolleinheit wird eine Reihe peripherer Hardware benötigt, um den Ölbrenner und die Pumpen zu steuern. Hier kommen insgesamt 16 Triac 220V/4A Lastschalter zum Einsatz. Letztere haben zusätzlich den Vorteil, dass sie auch manuell geschaltet werden können, was in Problemfällen z. B. eine schnelle Abschaltung defekter Geräte ermöglicht. 62

5 softwaregesteuerte Emulation einer parallelen Schnittstelle notwendig ist, die Signalantwortzeiten von 0.5 Millisekunden garantieren muss. Deshalb war es notwendig, ein präemptives, prioritätenbasiertes Planungsschema für die Steueraktivitäten zu verwenden. Andernfalls wäre es nicht möglich gewesen, die vorgegebenen Zeitschranken einzuhalten. Das kombinierte Licht-/Alarmsystem verwendet eine Sirene und einen Lichtsensor. Ferner kommen im Heizungssystem eine Reihe von Pumpen zum Einsatz. Die Kontrolleinheit ist über eine RS 232 Schnittstelle mit einem PC verbindbar, um das System bei Bedarf zu reprogrammieren oder den Zustand der Haussteuerung abzufragen. 3.4 Das Steuersystem Abbildung 7 Die Hauptkontrolleinheit Die Temperatursensoren vom Typ SMT160 arbeiten mit Pulsweitenmodulation (vergl. Abschnitt 2) und generieren eine Frequenz zwischen 1 und 8 Khz. Diese Sensoren sind über einen Maxim 16x1 Multiplexer an das System angeschlossen. Die Alarmanlage wie auch das Heizungssystem benötigen eine hinreichend genaue Uhrzeit, die von einer Conrad DCF77 Funkuhr geliefert wird. Mit Hilfe des Funksignals werden stündlich oder nach einem Reset die internen Uhren des Mikrocontrollers abgeglichen. Die Funkuhr ist batteriebetrieben und wird direkt an den Mikrocontroller angeschlossen. Letzteres ist nicht ganz trivial, da für den Anschluss eine In Abb. 8 sind die gesamten Komponenten des Steuersystems dargestellt. Alle dunkelgrauen Komponenten sind hardware-abhängige Gerätetreiber, während die hellgrauen Komponenten hardware-unabhängig sind. Mit ca. 800 Zeilen C++-Quellcode und einem Speicherverbaruch von 23 KB Code und 2 KB Daten, von denen ca. 1.7 KB allein auf die komplexe Funkuhrenbehandlung zurückzuführen sind, ist das Gesamtsystem trotz der relativ hohen Komplexität erstaunlich klein und wartbar. Dies ist in erster Linie auf das eingängige und problemadäquate Ereignisflusskonzept von REFLEX mit seinen impliziten Synchronisationsmechanismen und der objektorientierten Implementierung zurückzuführen. Der Programmierer kann so seine Probleme auf einem hohen Abstraktionsniveau formulieren und wird von der typischen, extrem fehleranfälligen Synchronisationsproblematik in nebenläufigen Systemen weitgehend befreit. Abbildung 8: Die Software-Komponenten des Hauskontrollsystems 63

6 Zu Beginn des Projektes musste die Software etwa wöchentlich aktualisiert werden, um all die diversen Parameter korrekt einzustellen. Dies war jedoch weniger ein Software als ein allgemeines Mess- und Regelproblem. Danach wurden Software-Änderungen in erster Linie zur funktionalen Erweiterung und zur Aktualisierung der REFLEX-Basiplattform durchgeführt, wobei die diversen graphischen Möglichkeiten zur Systemüberwachung die wichtigsten waren. Abgesehen davon lief das System über längere Perioden (bis zu 7 Monaten) fehlerfrei. Die längste Periode wurde jäh durch einen Blitzschlag im Sommer 2007, der alle elektrischen Einrichtungen des Hauses zerstörte, beendet. 5 Zusammenfassung In diesem Artikel haben wir REFLEX, ein ereignisgetriebenes Betriebssystem für tief eingebettete Systeme vorgestellt und die wesentlichen Eigenschaften des Systems anhand eines komplexen Hauskontrollsystems, das 24 Sensoren, 16 Aktuatoren und 6 externe Geräte mit nur einem einfachen Mikrocontroller steuert, demonstriert. Sowohl das REFLEX zugrunde liegende Ereignisflussmodell als auch die objektorientierte Implementierung haben eine hohe Effektivität in der Softwareentwicklung ermöglicht. Die Ereigniskanäle und die impliziten Synchronisationsmechanismen erlauben es in Verbindung mit dem Scheduling-Rahmenwerk, neue Steuer- und Regelsoftware weitgehend frei aus vorhandenen Komponenten zusammenzustellen. Der nächste logische Schritt wird eine weitere Erhöhung des Abstraktionsniveaus durch modellgetriebenen Entwurf sein. Ein erster Schritt in diese Richtung wurde bereits unternommen, indem eine REFLEX-Laufzeitumgebung für ein kommerzielles SDL-Werkzeug realisiert wurde (WAGENKNECHT, DIETTERLE, EBERT & KRAE- MER; 2006). Literatur BAJORATH, R.; (2005): Hintergrundinformationen zur verfahrenstechnik (Tech. Rep.). Bajorath Systemhaus für Regelungstechnik und Hydraulik GmbH. CHEONG, E.; LIEBMAN, J.; LIU, J. & ZHAO, F.; (2003): Tinygals: A programming model for event-driven embedded systems. In Sac (p ). WAGENKNECHT, G.; DIETTERLE, D.; EBERT J.-P. & KRAEMER R., (2006): Transforming protocol specifications for wireless sensor networks into efficient embedded system implementations. In Proc. of european workshop on wireless sensor networks. WALTHER K. & NOLTE J., (2006): Event-flow and synchronization in single threaded systems. In First gi/itg workshop on non-functional properties of embedded systems (nfpes). WALTHER K. & NOLTE J., (2007): A flexible scheduling framework for deeply embedded systems. In In proc. of 4th ieee international symposium on embedded computing. M.Sc. Karsten Walther, geboren 1978, Studium der Informations und Medientechnik an der BTU Cottbus , seit Oktober 2003 wissenschaftlicher Mitarbeiter am Lehrstuhl Verteilte Systeme Betriebssysteme. Beschäftigt sich mit der Hochsprachen-basierten Programmierung tief eingebetteter Systeme. Dipl.-Inf. Reinhardt Karnapke, geboren 1978, Studium der Informatik an der FU Berlin , seit April 2005 wissenschaftlicher Mitarbeiter am Lehrstuhl Verteilte Systeme Betriebssysteme. Beschäftigt sich mit Kommunikationsprotokollen für Sensornetze und tief eingebettete Systeme. Prof. Dr.-Ing. Jörg Nolte wurde 1962 geboren und ist seit 2003 Professor für Verteilte Systeme und Betriebssysteme an der Brandenburgischen Technischen Universität Cottbus. Er erhielt 1988 sein Diplom in Informatik von der TU Berlin und promovierte 1994 an der TU Berlin zum Dr.-Ing. Von war er am Forschungsinstitut für Rechnerund Softwaretechnik (FIRST) der GMD (seit 2001 FhG) tätig und war dort u. a. maßgeblich an dem Entwurf und der Entwicklung der PEACE Betriebssystemfamilie für Deutschlands ersten massiv parallelen Rechner beteiligt. In den Jahren und ging er als Postdoc Fellow und Senior Researcher im Rahmen des Real World Computing Programmes des MITI an das Tsukuba Research Center der RWCP in Japan. Die aktuellen Forschungsaktivitäten seines Lehrstuhls konzentrieren sich auf schlanke Middleware-, Laufzeit- und Betriebssysteme für verteilte, parallele und eingebettete Systeme. Jörg Nolte ist seit 2004 Mitglied des Leitungsgremiums der FG Betriebssysteme der Gesellschaft für Informatik und seit 2008 deren stellvertretender Sprecher. Ferner ist er Subject Area Editor for Parallel and Distributed Systems für Elsevier s Journal of Systems Architecture und seit Ende 2005 Vorsitzender des Fakultätsrates der Fakultät 1 Mathematik, Naturwissenschaften und Informatik an der BTU Cottbus. 64