Entwicklung einer Spezifikationssprache zur modellbasierten Generierung von Security-/Safety-Monitoren zur Absicherung von (Eingebetteten) Systemen

Getrieben durch technische Innovationen gewinnt die Kommunikation zwischen eingebetteten Systemen immer mehr an Bedeutung. So kommunizieren heutzutage nicht nur PCs über lokale Netzwerke oder das Internet, sondern auch mobile Geräte wie Smartphones und Tablets erobern den Markt. Diese bieten aufgrund ihrer geringeren Rechenleistung neue Angriffsflächen, da Sicherungsmaßnahmen der PC-Domäne nicht ohne Anpassung anwendbar sind. Durch die Vernetzung dieser mobilen Geräte mit Fahrzeugen und die Anbindung der Fahrzeuge an externe Dienstleistungen sind selbst eingebettete Systeme im Fahrzeug, die sicherheitskritische Aufgaben erfüllen, nicht mehr vollständig von der Außenwelt abgeschirmt. Bei ihrer Entwicklung wurde jedoch wenig Aufmerksamkeit auf Sicherheitsmechanismen, wie Verschlüsselung und sicheres Komponentendesign, zur Abwehr von Angriffen aus der Außenwelt gelegt. Solche Fahrzeuge sind hierdurch von außen für aktive und passive Angriffe anfällig. Selbst wenn bei einer Neuentwicklung eines eingebetteten Systems großer Wert auf die Absicherung gelegt wird, ist es meist nicht möglich, alle Sicherheitslücken zu eliminieren und jeden möglichen Angriff vorherzusehen. Betrachtet man komplexe heterogene Systeme oder Komponenten und will diese nachträglich absichern, ist dies meistens ökonomisch oder technisch nicht zu realisieren. Resultierend daraus kann bei keinem System davon ausgegangen werden, dass es sicher ist -- sei es durch unbekannte Schwachstellen oder der Verwendung von Legacy-Komponenten. Um Systeme dennoch gegen Angriffe, die vorher unbekannte Fehler und Sicherheitslücken ausnutzen, absichern zu können, hat sich die Überwachung eines Systems während der Laufzeit als geeignet herausgestellt. Eine solche Absicherung wird durch den in dieser Dissertationsschrift und in [Pat14] vorgestellten verständlichen Model Based Security/Safety Monitor-Entwicklungsprozess (MBSecMon-Entwicklungsprozess) erreicht, der sich in bestehende modellbasierte Systementwicklungsprozesse nahtlos eingliedert. Dieser MBSecMon-Entwicklungsprozess generiert aus einer in der Anforderungsphase entstandenen Spezifikation automatisch effiziente Sicherheitsmonitore für hoch nebenläufige Kommunikationen. Diese Arbeit betrachtet zwei Schritte dieses Entwicklungsprozesses. Der erste Teil der Arbeit stellt eine neue auf dem szenariobasierten Design aufbauende graphische, modellbasierte Signaturbeschreibungssprache vor - die MBSecMon-Spezifikationssprache. Diese Sprache vereinigt die Vorteile bestehender Formalismen, indem sie (1) alle wichtigen Konzepte zur Modellierung von verhaltensbeschreibenden Signaturen für hoch nebenläufige Kommunikationsabläufe unterstützt und diese kompakt repräsentieren kann. Sie bezieht (2) bestehende Entwicklungsartefakte des Systementwicklungsprozesses in die Modellierung ein, (3) befindet sich auf einer höheren Abstraktionsebene als üblicherweise zur Spezifikation eingesetzte Sprachen und unterscheidet explizit zwischen Normalverhalten und bekannten Angriffsmustern und -klassen. Durch diese Unterscheidung und durch Nähe der Sprache zur UML wird (4) eine hohe Verständlichkeit der Spezifikation sowohl für den Softwaretechniker als auch für Nicht-Experten erreicht. Den zweiten Teil dieser Arbeit bildet die Abbildung der sehr kompakten in der MBSecMon-Spezifikationssprache verfassten Spezifikationen in die formale Zwischensprache Monitor-Petrinetze [Pat14]. Hierdurch wird zum einen die Semantik der MBSecMon-Spezifikationssprache formalisiert und zum anderen der im MBSecMon-Entwicklungsprozess eingesetzte automatische Übergang in eine für die Generierung effizienter Monitore besser geeignete Repräsentation realisiert

Automation and transition in motor vehicles - User-centered design of take-over situations within a multilevel automation approach

Die Arbeit beschäftigt sich mit der nutzerzentrierten Gestaltung von Übergabe- und Übernahmesituationen im Fahrkontext. Diese beziehen sich auf einen vierstufigen Automationsansatz, der sich vom manuellen über das assistierte, teilautomatisierte bis hin zum hochautomatisierten Fahren erstreckt. Im Kern der betrachteten Transitionen zwischen Fahrer und Automation stand die Frage, ob dem Fahrer zu jeder Zeit transparent ist, welcher Systemmodus gerade aktiv ist und wie dessen Abhängigkeiten zu den anderen Fahrfunktionen definiert sind. Das Augenmerk lag auf Übergangsszenarien die mit hoher Wahrscheinlichkeit zu einem geminderten Systemmodusbewusstsein führen und Effekte wie Modusverwechslungen oder Handlungsfehler forcieren können. In dieser Arbeit waren sie durch unterschiedliche Grade der Kontrollverschiebung charakterisiert, gingen mit indirekten Transitionen auf Zwischenstufen der Automation einher, berücksichtigten einander funktional ähnliche Systemmodi und schlossen Aktivierungs- als auch Deaktivierungssituationen ein. Die Untersuchung jener Übergänge erfolgte in zwei Studien. Während einer realen sowie simulierten Autobahnfahrt konnte der Fahrer hier neben manuellen Anteilen ein Adaptive Cruise Control und integrierte Systemauslegungen mit zusätzlich assistierter oder automatisierter Querführung nutzen. Die Ergebnisse zeigen, dass weniger das Ausmaß an Automatisierung Einfluss auf die Güte des Modusbewusstseins des Fahrers hat, sondern eher der kognitive Aufwand bei der Differenzierung noch zu übernehmender Anteile der Fahraufgabe. Ist der Fahrer noch in den Regelkreis Fahrer-Fahrzeug-Straße eingekoppelt, wird eine hierarchische (De-)Aktivierung von Systemen empfohlen. Ist dies nicht mehr der Fall, passt hingegen eine Entweder-oder-Logik besser zur mentalen Fahrerrepräsentation. Weicht das tatsächliche Systemverhalten von dem Erwarteten ab, lassen sich diese Inkonsistenzen im mentalen Nutzermodell anhand verzögerter Fahrerreaktionen, höherer Fahrerbeanspruchungen und nutzerseitigen Angaben zur Intransparenz der Transition nachweisen. Handlungsfehler treten ausschließlich nur dann auf, wenn sich einander funktional ähnliche Systeme in der verfügbaren Automationsbandbreite befinden. So bewirkt die Verwechslung der Systemmodi in diesem Fall falsche Annahmen über den Systemstatus und bedingt eine inadäquate Informationsaufnahme sowie Reaktion der Fahrer. Die Arbeit zeigt, dass vor allem Aktivierungsszenarien für diese Automation Surprises sensitiv sind.The present thesis deals with the user-centered design of handover and takeover situations in the context of driving. These relate to four stages of an automation concept, which ranges from manual and assisted driving to partly autonomous and highly autonomous driving. The central question regarding the considered transitions between driver and automation is whether it is transparent to the driver which system mode is active at the moment, what the active system does and how it depends on other driving functionalities. Particular attention was paid to transition scenarios, which, referring to aviation research, are most likely to cause reduced system mode awareness and unintended effects like mode confusion and mode errors. Those transitions were characterized by different levels of control allocation and included indirect transitions to intermediate levels of automation. They also included functionally similar system modes, and both activation and deactivation situations. The evaluation of these transitions happened in two empirical studies. During a real and a simulated highway drive, the driver could use an Adaptive Cruise Control and integrated system conceptions including assisted or automated lateral control next to manual portions of the drive. The results of this thesis demonstrate that it is not the level of automation that affects the driver’s awareness about the system mode. His awareness level is rather affected by the cognitive effort to differentiate parts of the driving tasks that still need to be controlled manually. Is the driver still a part of the control loop between “driver-vehicle-road”, a hierarchical (de-)activation of systems is recommended. If this is not the case anymore, an “either-or” logic fits better to the mental representation of the driver. If there is a difference between the expected and the actual behavior of the system, delayed driver reactions, higher driver workload and statements about lack of system transparency during transitions are the consequence. However, mistakes in action execution solely occur when functionally similar systems are located in the available automation range. In that case, mode confusion results in false assumptions about the current system status, inadequate assimilation of information as well as false driver reaction. The present thesis shows that these automation surprises primarily arise during activation scenarios