Projekte

Das Konzept von Distributed Ledger Systemen (Blockchain) ist eine grundlegend neue Basistechnologie, welche in der öffentlichen Wahrnehmung derzeit verstärkt im Fokus steht und welche erhöhtes Potential zur Lösung von Problemstellungen in einer Vielzahl von Anwendungsbereichen verspricht.

Daneben wandelt sich die Luftverkehrslandschaft absehbar mit einer massiven Zunahme an Luftverkehrsteilnehmern und weiteren Luftverkehrsarten wie autonomen Kleinstsystemen. Des Weiteren besteht ein Bedarf bei der Digitalisierung in administrativen und operativen Bereichen des Luftverkehrs, welcher sich dabei in eine globale Digitalisierungsstrategie einordnet. Im Luftverkehr sollte dabei der Erhalt des hohen Sicherheitsstandards bzw. sogar eine Erhöhung dessen ein übergeordnetes Ziel bleiben.

Im Rahmen des vorliegenden Projektes soll die Anwendbarkeit der Basistechnologie der Distributed Ledger Technologie für die Luftfahrt untersucht werden, die nutzbaren Potentiale für die Luftfahrt identifiziert werden und zur Anwendung gebracht werden.

Zur Maximierung des Vorhabenerfolges in dem Projekt wird folgendes Vorgehen angestrebt: Zunächst werden in einer divergenten Explorationsphase parallel Anforderungen und Potentiale in der Luftfahrt erarbeitet und zugleich die Basistechnologie Blockchain technisch analysiert und in den luftfahrtbezogenen Kontext gebracht. Anschließend werden Konzepte zur Anwendung der Blockchaintechnologie in zwei Anwendungsbereichen entwickelt. Diese decken eine repräsentative Bandbreite an Einsatzbereichen in der Luftfahrt ab und bieten zugleich ein hervorgehobenes Nutzungspotential. Zum einen wird ein Konzept entwickelt, welches eine lückenlose, revisionssichere und vertrauenswürdige digitale Dokumentation aller Bauteile eines Flugzeuges über den gesamten Lebenszyklus eines Luftfahrzeuges zwischen allen Beteiligten auf Basis der Distributed Ledger Technologie ermöglicht. Dies verspricht Vorteile in Bezug auf Reduzierung des Verwaltungsaufwandes, Nachhaltigkeit und Vertrauenssteigerung und repräsentiert einen administrativen Anwendungsfall. Zum anderen wird ein Konzept eines dezentralen Flugdatenschreibers entwickelt, um im Hinblick auf neue Luftraumstrukturen und -Teilnehmer Freigaben und Zustandsdaten von Fluggeräten für die Analyse von potenziellen Fehlerfällen sicher zu dokumentieren. Die Blockchaintechnologie erlaubt es dabei, die Aufzeichnung von Flugzustandsdaten dezentral verteilt durch mehrere Luftverkehrsteilnehmer und Bodenstationen vorzunehmen, wodurch eine hohe Verfügbarkeit der Aufzeichnung erreicht wird. Gleichzeitig werden Manipulationen der Daten durch einzelne Teilnehmer ausgeschlossen und der Zugang zu den Aufzeichnungen ist auch nach einer möglichen Zerstörung des UAVs gegeben. Dieses Konzept wird anschließend prototypisch implementiert und dient so dem Nachweis der praktischen Applikabilität der Blockchaintechnologie in dem vorgesehenen Anwendungskontext. Ergebnisse werden der Fachöffentlichkeit und der europäischen Industrie zugänglich gemacht, so dass dieses Projekt direkt den Technologievorsprung des Luftfahrtstandorts sichert und eine Anschlussverwendung in Folgeprojekten mit Industriepartnern ermöglicht.

Das Vorhaben wird in Kooperation der Technischen Universität Braunschweig und der Friedrich-Alexander-Universität Erlangen-Nürnberg durchgeführt. Durch die Beteiligung des Instituts für Flugführung (IFF, TUBS) sowie des Lehrstuhl Informatik 16 für Systemsoftware (I16, FAU) können interdisziplinär die benötigten Kompetenzen im Bereich der Informationstechnologie und Luftfahrt eingebracht werden und der Verbund bildet damit ein Alleinstellungsmerkmal und vorteilhafte Voraussetzungen zur Erreichung der Projektziele.

Distributed Ledger Technologies (DLTs), oft auch als Blockchains bezeichnet, ermöglichen die Realisierung zuverlässiger und angriffsresilienter Dienste ohne zentrale Infrastruktur. Die verbreiteten "Proof-of-Work"-Mechanismen für DLTs leiden jedoch unter hohen Latenzen von Operationen und enormen Energiekosten. Byzantinisch fehlertolerante (BFT) Einigungsalgorithmen stellen eine potentiell bessere Alternative zu Proof-of-Work dar. Jedoch bringen aktuelle BFT-Protokolle auch Herausforderungen mit sich, die ihre praktische Verwendung in Produktivsystemen noch einschränken. Dieses Forschungsvorhaben adressiert diese Herausforderungen, indem es (1) die Skalierbarkeit von BFT-Protokollen verbessert, ohne ihre Resilienz einzuschränken, (2) durch Modellierung die zu erwartende Performanz und das zeitliche Verhalten der Protokolle auch unter Angriffen und in Abhängigkeit der Rahmenparameter des Protokolls vorhersehbarer macht, sowie (3) den Entwurfsprozesses von validen, automatisiert prüfbaren BFT-Systemen von Spezifikation bis hin zum Einsatz in einer Blockchain-Infrastruktur unterstützt. Beim Thema Skalierbarkeit geht es darum, praxistaugliche Lösungen zu finden, die auch Herausforderungen wie Wiederanlauf nach größeren Ausfällen oder Upgrades sowie Rekonfigurationen zur Laufzeit berücksichtigen. Auch möchten wir eine resiliente Kommunikationsschicht konzipieren, die die Wahl einer geeigneten Kommunikationstopologie vom eigentlichen BFT-Einigungsalgorithmus entkoppelt und somit dessen Komplexität reduziert. Dies soll durch die Verwendung von vertrauenswürdigen Hardwarekomponenten unterstützt werden. Anknüpfend wollen wir an der Kombination dieser Konzepte mit kryptographischen Primitiven forschen, um die Skalierbarkeit weiter zu verbessern. Mit Hilfe von systematischen Modellierungstechniken möchten wir die Effizienz von skalierbaren, komplexen BFT-Protokollen (beispielsweise hinsichtlich Durchsatz und Latenz von Operationen) schon vor einem Deployment analysieren können, wenn man die Systemgröße, Rechenleistung von Knoten und grundlegende Eigenschaften der Kommunikationsverbindungen kennt. Auch möchten wir an robusten Gegenmaßnahmen forschen, die in groß-skalierbaren Blockchain-Systemen helfen, gezielte Angriffe abzuwehren. Das dritte Ziel ist es, die systematische und valide Umsetzung in ein praktisches System zu unterstützen, gegliedert in einem konstruktiven, modularen Ansatz, bei dem ein validierbares BFT-Protokoll aus kleineren, validierbaren Bausteinen komponiert wird, die Inkorporation automatisierter Testverfahren auf Grundlage eines heuristischen Algorithmus, der den komplexen Suchraum von Fehlverhalten in BFT-Systemen beherrschbarer macht und ein Werkzeug für automatisiertes Deployment mit einhergehendem Benchmarking und Stress-Testing in einem groß-skalierten DLT-System.

Ein Betriebssystem befindet sich zwischen zwei Fronten: Einerseits ("oben") die Maschinenprogramme der Anwendungen mit ihren teils sehr unterschiedlichen funktionalen und nichtfunktionalen Anforderungen und andererseits ("unten") die Rechnerhardware, deren Merkmale und Gerätschaften den Anwendungen idealerweise "ungefiltert" und "geräuschfrei" zur Verfügung gestellt werden sollen. Allerdings kann ein Allzwecksystem in keiner seiner Funktionen so effizient sein wie ein System, das speziell für einen bestimmten Zweck entwickelt wurde und weniger anspruchsvolle Anwendungen dürfen verlangen, dass sie nicht gezwungen werden, für die verbrauchten Ressourcen durch die nicht benötigten Funktionen zu zahlen. So ist es nicht ungewöhnlich, dass große Systeme, einmal in Betrieb genommen, in der Regel häufigen Änderungen unterliegen --- eben gerade auch deshalb, um eine höhere Passgenauigkeit an sich ändernde Anwendungsanforderungen zu erreichen.

Das ideale Betriebssystem bietet genau das, was für die jeweilige Anwendung benötigt wird --- nicht mehr und nicht weniger, aber eben auch in Abhängigkeit von den Merkmalen der Hardwareplattform. Ein solches Ideal ist jedoch, wenn überhaupt, nur für den Einprogrammbetrieb realistisch. Bei Mehrprogrammbetrieb müssten die verschiedenen Anwendungen schon "hinreichend gleiche" funktionale und nichtfunktionale Anforderungsmerkmale aufweisen, um keine der Anwendungen mit den Gemeinkosten (overhead) zu belasten, die die nicht benötigten Funktionen mit sich bringen. Ein Betriebssystem mit diesen Eigenschaften fällt in die Kategorie Spezialsystem (special purpose operating system), es ist zugeschnitten auf die Bedürfnisse von Anwendungen eines bestimmten Typs.

Im Gegensatz dazu steht das Allzwecksystem (general purpose operating system), wo letztlich nur zu hoffen ist, dass eine Anwendung nicht mit zu hohen Gemeinkosten durch die nicht benötigten Funktionen belastet wird. Hier kann immerhin versucht werden, das "Hintergrundrauschen" (background noise) im Betriebssystem bei Bedarf zu minimieren --- idealerweise in diesem Fall mit unterschiedlichem "Rabatt" je nach Programmtyp. Das Betriebssystem müsste dann mit weniger anspruchsvollen Anwendungen nicht nur dynamisch von unnötigem Ballast befreit werden und schrumpfen können, sondern auch in die Lage versetzt werden, bei anspruchsvolleren Anwendungen mit dafür nötigen und zusätzlichen Funktionen wieder anzuwachsen. Spezialisierung eines Betriebssystems in Abhängigkeit vom jeweiligen Anwendungsfall bedeutet letztlich funktionelle Abmagerung und Anreicherung, wozu ein geeigneter Systemsoftwareentwurf zwar wünschenswert ist, sich aber gerade bei Altsoftware (legacy system) oft nicht mehr umsetzen lässt.

Ein Umstand für die Spezialisierung eines Betriebssystems bezieht sich auf explizit "von außen her" initiierte Maßnahmen. Dies betrifft einerseits ausgewählte Systemaufrufe und andererseits Vorgänge wie das Urladen (bootstrap) sowie das Laden von Maschinenprogrammen, Betriebssystemkernmoduln oder von Programmen, die in sandkastenartigen virtuellen Maschinen innerhalb des Betriebssystemkerns zur Ausführung kommen sollen. Diese Form der Spezialisierung ermöglicht ebenfalls die dynamische Generierung von gezielten Schutzmaßnahmen in Folge von besonders vulnerablen Betriebssystemoperationen, wie dem Laden von externen Modulen des Betriebssystemkerns. Der andere ausschlaggebende Umstand für die Spezialisierung eines Betriebssystems bezieht sich auf implizit "von innen heraus" initiierte Maßnahmen. Dies betrifft mögliche Reaktionen eines Betriebssystems auf erst zur Laufzeit wahrnehmbare Änderungen im eigenen Laufzeitverhalten, um daraufhin etwa die Strategien einer Ressourcenverwaltung der jeweiligen Arbeitslast anzupassen und entsprechende Systemsoftware in das bestehende System nahtlos einzupassen.

Projektfokus ist die dynamische Betriebssystemspezialisierung, ausgelöst durch extrinsische und intrinsische Ereignisse. Im Vordergrund stehen Verfahren und Techniken, die (a) unabhängig von einem bestimmten Programmierparadigma oder Hardwareansatz sind und (b) auf bedarfssynchrone (just in time, JIT) Übersetzung von Teilen des Betriebssystem(kern)s basieren, um im bereits laufenden Betrieb bedarfsweise (on demand) zu ladende oder vorausschauend (anticipatory) zu ersetzende Betriebssystemprogramme den jeweiligen Gegebenheiten an den "Betriebssystemfronten" anzupassen. Untersuchungsgegenstand sind bestehende Allzwecksysteme wie etwa Linux.

Der gegenwärtige Trend hin zu schnellem, byteadressierbarem nichtflüchtigem Hauptspeicher (non-volatile memory, NVM) mit Latenzen und einer Schreibfestigkeit näher an SRAM und DRAM als an Flash positioniert NVM als möglichen Ersatz für die etablierten flüchtigen Technologien. Während einerseits die Nichtflüchtigkeit und geringe Leckleistung NVM, neben weiteren vorteilhaften Merkmalen, zum attraktiven Kandidaten für neue Systementwürfe macht, ergeben sich andererseits auch große Herausforderungen insbesondere für die Programmierung solcher Systeme. So bewirken etwa Stromausfälle in Kombination mit NVM zum Schutz des Rechenzustands Kontrollflüsse, die einen sequentiellen Prozess unerwartet in einen nichtsequentiellen Prozess verwandeln können: Ein Programm muss sich mit seinem eigenen Zustand aus früheren unterbrochenen Läufen auseinandersetzen.

Wenn Programme direkt im NVM zur Ausführung kommen können, wird normaler flüchtiger Hauptspeicher (funktional) überflüssig. Flüchtiger Speicher findet sich dann ausschließlich im Cache und in Geräte-/Prozessoregistern ("NVM-pure"). Ein darauf ausgelegtes Betriebssystem kann auf viele, wenn nicht sämtliche, für gewöhnlich sonst zu realisierende Persistenzmaßnahmen verzichten und dadurch sein Maß an Hintergrundrauschen (background noise) verringern. Im Einzelnen betrachtet lassen sich so der Energiebedarf senken, die Rechenleistung erhöhen und Latenzen verringern. Des Weiteren ist durch den Wegfall oder Vereinfachung dieser Persistenzmaßnahmen ein "NVM-pure" Betriebssystem schlanker als sein funktional identischer Zwilling herkömmlicher Bauart. Dies trägt einerseits zur besseren Analysierbarkeit nichtfunktionaler Eigenschaften des Betriebssystems bei und ergibt andererseits eine kleinere Angriffsoberfläche beziehungsweise vertrauenswürdige Rechenbasis.

Das Projekt verfolgt einen "NVM-pure" Ansatz. Dabei resultiert ein drohender Stromausfall in einer Unterbrechungsanforderung (power- failure interrupt, PFI), mit der Folge, einen Fixpunkt (checkpoint) des unvermeidbaren volatilen Systemzustands zu erstellen. Zusätzlich werden, um mögliche PFI-Verluste zu tolerieren, sensitive Betriebssystemdatenstrukturen in transaktionaler Weise analog zu Methoden der nichtblockierenden Synchronisation abgesichert. Des Weiteren werden Methoden der statischen Programmanalyse genutzt, um (1) das Betriebssystem von überflüssigen Persistenzmaßnahmen, die sonst nur noch Hintergrundrauschen erzeugen, zu entschlacken, (2) ununterbrechbare Anweisungsfolgen mit zu hohen Unterbrechungslatenzen, die die PFI-basierte Fixpunktsicherung scheitern lassen können, aufzubrechen und (3) die Arbeitsbereiche der dynamischen Analyse des Energiebedarfs zu definieren. Zur Demonstration, dass ein "NVM-pure" Betriebssystem gegenüber seinem funktional gleichen herkömmlichen Zwilling sowohl in zeitlichen als auch energetischen Belangen effizienter operieren kann, laufen die Arbeiten beispielhaft mit Linux.

Subsysteme für virtuellen Speicher (VM) lassen die Unterschiede zwischen Sekundär- und Hauptspeicher verschwimmen, so dass auf flüchtige und nicht-flüchtige Daten gleichermaßen mit denselben CPU-Instruktionen zugegriffen werden kann. Jedes VM-Subsystem versucht, häufig benötigte Daten in schnellem, flüchtigen Hauptspeicher zu halten, um die hohe Zugriffslatenz des Sekundärspeichers zu vermeiden, unabhängig davon, ob die Daten selbst flüchtig sind oder nicht. Das Aufkommen von byte- adressierbarem NVRAM ändert dieses Muster nicht grundlegend, da diese Technologie aufgrund der höheren Zugriffslatenz derzeit weder DRAM als schnellen Hauptspeicher, noch herkömmlichen Sekundärspeicher aufgrund der höheren Kosten und geringeren Kapazität, ersetzen kann. Daher sollten VM-Subsysteme NVRAM- gewahr gemacht und so erweitert werden, dass alle verfügbaren byte- adressierbaren Speichertechnologien gemäß ihrer jeweiligen Stärken eingesetzt werden können. Mit Hilfe einer in der virtuellen Speicherverwaltung des Betriebssystems verankerten Abstraktion lässt sich erreichen, dass bestehende Software ohne weitere Änderung von NVRAM profitieren kann. Dadurch, dass VM- Subsysteme hochkomplexe und fein abgestimmte Softwaresysteme sind, die teils seit Jahrzehnten immer weiter entwickelt werden, folgen wir einem minimal-invasivem Ansatz, um NVRAM-Unterstützung in ein bereits existierendes VM-Subsystem zu integrieren, anstatt eines von Grund auf neu zu entwickeln. NVRAM soll als unmittelbarer DRAM-Ersatz bei Speicherknappheit dienen, um Prozesse mit großem Speicherbedarf auch bei Ressourcenknappheit lauffähig zu halten. Jedoch müssen aufgrund der höheren NVRAM-Zugriffslatenz auch nicht-flüchtige Daten zeitweise im schnellen, aber flüchtigen DRAM oder in Prozessorcaches bewahrt werden. Unser neues VM- Subsystem - wir passen FreeBSD entsprechend an - ermöglicht deshalb die Wanderung von Seiten zwischen DRAM und NVRAM, sofern es die verfügbaren Ressourcen erlauben. Somit wird DRAM gewissermaßen als ein großer, durch Software verwalteter, flüchtiger Cache für NVRAM genutzt. Daraus ergibt sich in der Folge das Problem von möglichem Datenverlust im Falle eines Stromausfalls. Das VM-Subsystem muss daher seine eigenen Metadaten in einem konsistenten und wiederherstellbaren Zustand halten und in einem solchen Fall modifizierte Seiten aus dem DRAM im NVRAM persistieren, um Datenverluste zu vermeiden. Ersteres erfordert einen hochgradig effizienten transaktionalen Mechanismus zur Veränderungen von komplexen und parallel genutzen Datenstrukturen, die für die VM-Metadaten zum Einsatz kommen. Letzteres hingegen bedeutet, dass unter Umständen große Mengen an modifizierten Seiten mit einem eng begrenzten Restenergie- und Zeitfenster gesichert werden müssen.

Netzwerkbasierte Dienste wie replizierte Datenbanken, verteilte Dateisysteme oder Blockchains sind grundlegende Bausteine heutiger IT-Infrastrukturen und müssen daher in der Lage sein, ein breites Spektrum an Problemszenarien zu bewältigen, das von Hardware-Ausfällen über Software-Fehlverhalten bis hin zu Angriffen reicht. Zwar existieren bereits diverse fehler- und einbruchstolerante Protokolle zur Replikation von Zustandsmaschinen, allerdings ist es alles andere als trivial diese auf Basis ihrer komplexen und oftmals unvollständigen Spezifikationen zu implementieren. Dies führt zumeist zu einer Anfälligkeit von Systemen gegenüber korrelierten Fehlern oder Angriffen, beispielsweise immer dann, wenn zur Reduzierung von Entwicklungs- und Wartungskosten bei allen Replikaten eines Systems dieselbe Implementierung zum Einsatz kommt.

Ziel des Mirador-Projekts ist es, diese Lücke zwischen Theorie und Praxis verschwinden zu lassen, und zwar mit Hilfe einer neuen Herangehensweise zur Spezifizierung und Implementierung zuverlässiger Systeme: Mikroreplikation. Anders als traditionelle Systeme umfassen mikroreplizierte Architekturen keine komplexen Replikate, sondern bestehen stattdessen aus lose gekoppelten Mikroreplikatgruppen, die jeweils ausschließlich für einen bestimmten Protokollschritt verantwortlich sind. Der daraus folgende geringe Funktionsumfang jedes einzelnen Mikroreplikats macht es dabei deutlich einfacher, die Vollständigkeit und Korrektheit von sowohl Spezifikationen als auch Implementierungen zu beurteilen. Da Mikroreplikate darüber hinaus über einen einheitlichen inneren Aufbau verfügen, erleichtern sie zudem eine Diversifizierung auf Replikats-, Kommunikations- sowie Authentifizierungsebene.

Ausgehend von diesem grundlegenden Konzept erforscht das Mirador-Projekt die Verwendung von Mikroreplikation als zentrales Instrument für den Bau zuverlässiger Systeme und untersucht ihre Flexibilität durch Entwicklung mikroreplizierter Architekturen für unterschiedliche Fehlermodelle (Ausfälle und byzantinische Fehler). Hierbei liegt der Fokus vor allem auf zwei Problemfeldern: Zum einen soll die Widerstandsfähigkeit mikroreplizierter Systeme gestärkt werden, indem man sie in die Lage versetzt, sich zur Laufzeit selbst zu heilen. Dies erfordert unter anderem Mechanismen zur Wiederherstellung bzw. nachträglichen Integration von Mikroreplikaten. Zum anderen soll eine hohe Performanz und Effizienz mikroreplizierter Systeme sowie den auf ihnen laufenden Anwendungen erreicht werden. Neben neuen Techniken zur Aufwandsreduzierung unter Zuhilfenahme optimistischer Ansätze umfasst dies auch die Auslagerung von Vorverarbeitungsschritten auf vorgeschaltete Mikroreplikatgruppen. Für die Evaluierung der entwickelten Konzepte, Protokolle und Mechanismen wird im Rahmen des Projekts eine mikroreplizierte Plattform aufgebaut, welche die Durchführung von Experimenten in diversen Konfigurationen und mit einer Vielfalt von Anwendungen ermöglicht.

Innerhalb des sehr weiten Feldes der Resilienz vernetzter Welten konzentriert sich ResPECT auf einen Kernbaustein aller vernetzten Systeme: Sensor- oder Aktor-Knoten in cyber-physischen Systemen. Bis heute wird die Kommunikation als Zusatzfunktionalität eingebetteter Systeme verstanden. Das System an sich wird Störungs-tolerant ausgelegt und kann mit Stromausfällen umgehen oder sogar Hardwareprobleme in gewissem Maße kompensieren. Die Kommunikation jedoch wird in die Konzeption nicht einbezogen, sondern kann die Verlässlichkeit allenfalls nutzen. ResPECT entwickelt daher ein holistisches Betriebssystem- und Kommunikations-Protokoll-Konzept, welches davon ausgeht, dass die Vermittlung von Information (der Erhalt von Steuerdaten für Aktoren oder das Versenden von Sensordaten) die Kernaufgabe fast aller vernetzten Knoten ist. Damit muss diese Aufgabe Teil des Managements des Betriebssystems werden. Grundlage von ResPECT sind zwei Pfeiler: Nicht-flüchtiger Speicher und transaktionaler Betrieb. Nicht-flüchtiger Speicher hat sich in den letzten Jahren zu einem sehr ernst zu nehmenden Element der Speicherhierarchie entwickelt. Selbst eingebettete Plattformen mit ausschließlich nicht-flüchtigem Speicher werden vorstellbar. Netzwerkkommunikation ist, anders als soziale Kommunikation, im Kern transaktional: Daten werden gesammelt und unter Rahmenbedingungen wie Latenz, Fehlertoleranz und Energieverbrauch der Übertragung sowie Alter und damit Wert der zu übertragenden Information vermittelt. Anders als das Betriebssystem unterliegt die Kommunikation jedoch einer Vielzahl äußerer Einflüsse und Störungen. Auch die Dauer einer Störung hat unmittelbaren Einfluss auf z. B. den Erhalt der physischen Verbindung und muss bei Wiederaufnahme berücksichtigt werden. ResPECT wird daher - durch die Zusammenarbeit von Betriebssystem- und Kommunikationsexperten - ein auf Transaktionen basierendes Modell für das Betriebssystem sowie die Kommunikation entwickeln und durch den Einsatz nicht-flüchtiger Speicher dafür Sorge tragen, dass Zustände im Ablauf der Transaktionen zu jedem Zeitpunkt bekannt sind und persistent gespeichert werden. Dieses Beobachten und Speichern muss sehr effizient (sowohl in Bezug auf den Energieverbrauch als auch in Bezug auf die im nicht-flüchtigen Speicher zu speichernden Datenmengen) geschehen und daher als Kernaufgabe des Betriebssystems implementiert werden. Um die Verallgemeinerbarkeit sicher zu stellen und das Modell für viele zukünftige Plattformen nutzbar zu machen, wird sich ResPECT auf IP-Netze fokussieren und Kommunikationsnetze verwenden, welche üblicherweise als WAN, LAN oder PAN (Wide, Local oder Personal Area Network) betrieben werden.

Energiebeschränkte Echtzeitsysteme, wie beispielsweise implantierbare Medizingeräte, sind heutzutage allgegenwärtig. Diese Systeme erfordern von ihrer Software die Erfüllung der beiden Eigenschaften von sicherer und zugleich energieeffizienter Ausführung von Aufgaben der Software. In Hinblick auf funktionale Sicherheit müssen diese Systeme ihre Aufgaben innerhalb von Laufzeit- und Energieschranken ausführen, da das Überschreiten von Terminen und Energiebudgets zu lebensgefährlichen Konsequenzen führen kann. Statische Programmanalysewerkzeuge ermöglichen hierfür automatisiert das Worst-Case-Verhalten des Systems zu bestimmen, um letztendlich den sicheren Betrieb mit gegebenen Zeit- und Energieressourcen zu garantieren. Jedoch sind existierende statische Analysen nicht in der Lage, das Problem zu adressieren eines ressourceneffizienten Betriebs unter Beibehaltung der Eigenschaft von sicherer Ausführung. Weiterhin ist eine manuelle Maßschneiderung für das Effizienzproblem unpraktikabel durch die große Anzahl an Energiesparmechanismen in modernen Hardwareplattformen. Um dem Betriebssystem zur Laufzeit eine optimale Nutzung der Ressourcen zu ermöglichen bei sicherem Ablauf der Aufgaben, wäre eine ganzheitliche Sicht auf Aufgaben, ihre Ressourcenbeschränkungen und Energiesparmechanismen erforderlich, was vom aktuellen Stand der Forschung nicht erreicht wird.

Das Forschungsprojekt Watwa bietet einen Ansatz für ganzheitliche Optimalitätsanalysen und Maßschneiderung von Systemen mit Worst-Case-Beschränkungen. Das Grundkonzept umfasst die automatisierte Generierung von funktional gleichwertigen Varianten der Aufgaben unter Ausnutzung vorhandener Energiesparmechanismen der Hardwareplattform. Die dadurch erreichte anwendungsgewahre Maßschneiderung erlaubt das gezielte Ein-/Ausschalten unbenutzter Leistungsverbraucher. Eine anschließende Worst-Case-Analyse bewertet das unterschiedliche zeitliche und energetische Verhalten der Varianten hinsichtlich des Ressourcenbedarfs. Schlussendlich ermöglicht es Watwa durch die Kombination aus Variantengenerierung und Analyse erstmals Hinweise auf optimale Systemabläufe vollständig automatisch zu finden. Optimalität meint hier die möglichst effiziente Ressourcennutzung bei garantierter Einhaltung aller Termine und Energiebudgets. Um analytisch bestimmte Hinweise zur Laufzeit auszunutzen, beinhaltet Watwa die Entwicklung eines Betriebssystems und einer Ablaufplanung, die auf veränderte Umweltbedingungen reagieren und einen effizienten, aber gleichzeitig sicheren Betrieb ermöglichen. Zusammengefasst zielt das Forschungsprojekt auf die Beantwortung folgender zwei Fragen ab: (1) Wie können statische Analysen unter Ausnutzung moderner Energiesparmechanismen Varianten mit optimalem Ressourcenbedarf und sicheren Schranken des Bedarfs erzeugen? (2) Wie können Betriebssysteme statisch bestimmte Hinweise auf mögliche Abläufe und Gerätenutzungen verwenden, um einen effizienten Betrieb unter Sicherheitsgarantien zu ermöglichen?