Autoren: Lukas Osinski, J\u00fcrgen Mottok,\u00a0 Laboratory for Safe and Secure Systems (LaS\u00b3), Zentrum Digitalisierung.Bayern (ZD.B)<\/p>\n
Im Forschungsvorhaben Multi-Core Safe and Software-intensive Systems Improvement Community wurden durch einen ganzheitlichen Ansatz die durch heterogene Multi-\/Many-Core Architekturen entstehenden Herausforderungen f\u00fcr Automotive und Avionics gel\u00f6st. Das zu entwickelnde ganzheitliche L\u00f6sungskonzept spiegelt sich in der Ber\u00fccksichtigung der verschiedenen Ebenen des Hardware-Software Co-Designs wider. Damit wurden neben L\u00f6sungen f\u00fcr aktuelle Probleme in erster Linie Beitr\u00e4ge f\u00fcr die effiziente Nutzung heterogener Multi- und Many-Core-Systeme geleistet.<\/strong><\/p>\n Der Forschungsverbund Multi-Core Safe and Software-intensive Systems Improvement Community (FORMUS3<\/sup>IC) aus dem Bereich der Informationstechnologie leistete in den Jahren 2015-2018 einen wichtigen Beitrag, um sichere heterogene parallele Hardwareplattformen zu nutzen.<\/p>\n Am Forschungsverbund FORMUS\u00b3IC sind sechs Hochschulen beteiligt (Ostbayerische Technische Hochschule Regensburg, Friedrich-Alexander-Universit\u00e4t Erlangen-N\u00fcrnberg, Hochschule f\u00fcr Angewandte Wissenschaften M\u00fcnchen, Ostbayerische Technische Hochschule Amberg-Weiden, Technische Hochschule Ingolstadt, Technische Hochschule N\u00fcrnberg Georg Simon Ohm), und acht Unternehmen (Airbus Defence & Space GmbH, AUDI AG, Continental Automotive GmbH, Elektrobit Automotive GmbH, Infineon Technologies AG, iNTENCE automotive electronics GmbH, \u00a0Timing-Architects Embedded Systems GmbH, XKrug GmbH) belegen die Relevanz entlang der Wertsch\u00f6pfungskette. Das Vorhaben wird von der Bayerischen Forschungsstiftung gef\u00f6rdert und hat ein Gesamtvolumen von ca. 4 Mio.\u20ac.<\/p>\n Mit sechs technischen Arbeitspaketen (TP2, \u2026, TP6) werden unterschiedliche Fragestellungen aufgegriffen, L\u00f6sungen entwickelt und in einem Demonstrator die Machbarkeit (TP7) nachgewiesen. Die im ersten Projektjahr identifizierten und verfolgten Forschungsfragen wurden im zweiten Projektjahr vertieft, und die Entwicklung von L\u00f6sungen wurde im dritten Projektjahr verfolgt. Folgende Leistungen der einzelnen Teilprojekte von FORMUS\u00b3IC sind kurz aufgez\u00e4hlt:<\/p>\n Abbildung 1 (s.\u00a0PDF<\/a>): Technische Arbeitspakete des FORMUS\u00b3IC-Forschungsverbundes<\/p>\n Nach einem Diskurs der Ausganglage im Jahr 2015 bei Projektstart in Kapitel 2 folgt in Kapitel 3 die exemplarische Diskussion des Projektergebnisses der Funktionalen Sicherheit aus Teilprojekt 3 (TP3). Kapitel 4 wird im Anschluss eine Zusammenfassung und einen Ausblick geben.<\/p>\n Die Diskussion des Stands der Technik erfolgt einzeln f\u00fcr die Themenfelder.<\/p>\n Die EAST-ADL, kurz f\u00fcr Electronics Architecture and Software Technology \u2013 Architecture Description Language [1], ist eine dom\u00e4nenspezifische Architekturbeschreibungssprache f\u00fcr die modellbasierte Entwicklung und Beschreibung eingebetteter E\/E-System- und Softwarearchitekturen in einem standardisierten Format mit besonderem Fokus auf dem Bedarfsfeld der Dom\u00e4ne Automotive [2]. Die Sprache wurde in enger Anlehnung an den etablierten Automotive Standard entworfen und nutzt dessen sprachliche Mittel zur Umsetzung einer der vier EAST-ADL Abstraktionsebenen. In diesem Sinne kann die EAST-ADL auch als Erweiterung der implementierungsnahen AUTOSAR-Sicht angesehen werden, welche diese um zus\u00e4tzliche, h\u00f6here Abstraktionsebenen erg\u00e4nzt. Die EAST-ADL wurde urspr\u00fcnglich im Rahmen des europ\u00e4ischer Forschungsprojektes ITEA EAST-EEA [3] entwickelt und anschlie\u00dfend in verschiedenen europ\u00e4ischen Forschungsprojekten weiterentwickelt, zuletzt insbesondere im Kontext der FP7 Projekte ATESST und ATESST2 [4] sowie MAENAD [5], welches insbesondere auf die Anforderungen moderner Elektrofahrzeuge abzielte.<\/p>\n Im Zentrum eines jeden Betriebssystems mit Multitasking-Unterst\u00fctzung steht das implementierte Schedulingverfahren. Dieses legt fest, welcher Programmteil zu welchem Zeitpunkt welche Priorit\u00e4t hat. Anhand der Priorisierung werden die Programmteile dann im Systemverlauf ausgef\u00fchrt. Abh\u00e4ngig von der Zielsetzung des implementierten Schedulingverfahrens haben sich hier verschiedene Strategien etabliert. Das erste Priorit\u00e4tsprotokoll f\u00fcr Multi-Prozessor-Umgebungen wurde von Rajkumar et al. in [6] pr\u00e4sentiert. Moderne Synchronisationsprotokolle erlauben geschachtelte Resourcenan-fragen. Dies wurde erstmals im „Flexible Multiprocessor Locking Protocol“ (FMLP) von Block et al. implementiert [7]. Dieses ist sowohl f\u00fcr statisches, als auch f\u00fcr dynamisches Scheduling geeignet, erzeugt allerdings immer noch viele Priorit\u00e4tsinversionen. Sowohl die Synchronisationsprotokolle von Brandenburg und Anderson [8], als auch das von Ward und Anderson [9] erlauben die geschachtelte Verwendung von Semaphoren, dies allerdings nur f\u00fcr statische, bzw. w\u00e4hrend der Abarbeitung einer Taskinstanz fester Priorit\u00e4tsvergabe. Beide Protokolle basieren auf passivem Warten. Das von Brandenburg et al. vorgeschlagene FMLP wurde durch Alfranseder et al. In [10] erweitert. Dabei werden die kritischen Abschnitte des Synchronisationsprotokolls in einen ununterbrechbaren und in einen unterbrechbaren Teil unterteilt. Dadurch verringert sich die Zahl der Priorit\u00e4tsinversionen f\u00fcr bestimmte Tasksets. Basierend auf den Short-Resource-Requests des FMLP Protokolls erweitern Alfranseder et al. in [11] das Priorit\u00e4tsprotokoll des OSEK-Betriebssystems und erm\u00f6glichen damit den Einsatz von OSEK auf Mehrkernplattformen. In [12] pr\u00e4sentieren Wieder und Brandenburg eine umfassende \u00dcbersicht und Analyse verschiedener Arten von, auf aktivem Warten basierenden, Synchronisationsprotokollen. Der in [13] vorgestellte Ansatz baut auf dem Stack Resource Protocol auf und verwendet Software Transactional Memory-Mechanismen um Deadlocks und Priorit\u00e4tsinversionen zu vermeiden.<\/p>\n Im Kalenderjahr 2015 zeigte sich jedoch deutlich, dass das Internet der Dinge, welches die Hersteller f\u00fcr sich erschlie\u00dfen m\u00f6chten, vielf\u00e4ltige Herausforderungen mit sich bringt. Die gr\u00f6\u00dfte Aufmerksamkeit erzielten Charlie Miller und Chris Valasek mit ihrem Hack des Jeep Cherokee. Sie demonstrierten, wie sie \u00fcber das Internet die Kontrolle \u00fcber ein Fahrzeug dieses Typs erlangen konnten und anschlie\u00dfend praktisch s\u00e4mtliche Funktionen, die der Fahrer im Auto selbst ausl\u00f6sen kann, beispielsweise die Scheibenwaschanlage, die L\u00fcftung oder die Stereoanlage, \u00fcber das Internet fernsteuerten. Es war ihnen sogar m\u00f6glich, das Fahrzeug anzuhalten (vgl. [14]). Aber auch andere Hersteller, beispielsweise Nissan oder BMW, offenbarten und offenbaren, dass ihre Fahrzeuge aktuell nicht ausreichend gegen Hackerangriffe gesch\u00fctzt sind.<\/p>\n Die Angriffe reichten vom unautorisierten Zugriff auf vertrauliche Fahrzeugdaten (bei Nissan, vgl. [15]) bis zum unautorisierten \u00d6ffnen des Fahrzeugs \u00fcber das Internet (bei BMW, vgl. [16]). Die Folge derartiger, insbesondere medienwirksam inszenierter Hacks sind in der Regel teure R\u00fcckrufaktionen oder die Au\u00dferbetriebnahme von Konnektivit\u00e4tsdiensten – ein Nebeneffekt ist au\u00dferdem ein Imageverlust f\u00fcr den jeweiligen Hersteller. Dass weder die genannten Angriffe noch die zuvor genannten Automobilhersteller Einzelf\u00e4lle sind, zeigt ein Bericht von US-Senator Edward J. Markey (Massachusetts) vom Februar 2015: Die „Connected Cars“ betreffend fehlen offensichtlich geeignete Sicherheitsfunktionen, um den Fahrer gegen Hackerangriffe zu sch\u00fctzen, die entweder die Kontrolle \u00fcber das Fahrzeug \u00fcbernehmen oder fahrerspezifische und damit personenbezogenen Daten sammeln, um aus diesen Kapital zu schlagen (vgl. [17]).<\/p>\n Sicherheitsnormen (z.B. Automotive: ISO 26262, Avionik: DO-178B) schlagen bereits verschiedene Diagnosetechniken und \u00dcberwachungstechniken zur funktionalen Absicherung von eingebetteten Systemen vor. Die Herausforderung hierbei ist, f\u00fcr die unterschiedlichen Anwendungsf\u00e4lle bzw. Fehlerbilder eines Automotive-Systems geeignete Verfahren und Methoden der Fehlererkennung sowie Fehlerbehandlung zu identifizieren, bei Bedarf neu zu entwickeln und anzuwenden. Die Einf\u00fchrung von Redundanz durch unterschiedliche Software-Kan\u00e4le oder eines Kanals von speziell kodierter Software (spezifische Kodierung von Daten und Anweisungen) wird als Safely-Embedded-Software (SES) [18] bezeichnet und ist inspiriert von dem Vital Coded Processor Ansatz [19]. Der einfachste Ansatz einen redundanten Kanal zu erhalten ist die Verdoppelung der urspr\u00fcnglichen Befehle und Daten.<\/p>\n Durch die entstehende einfache Redundanz k\u00f6nnen jedoch Common Cause Failures nicht erkannt werden, da sie in beiden Kan\u00e4len auftreten. Raab et al. [18] haben gezeigt, dass die Verwendung von SES zu einer Erh\u00f6hung der Laufzeit um das 44-fache \u2013 im Gegensatz zur originalen Version mit Standartmethoden \u2013 f\u00fchrt. Die Autoren merken an, dass ihre Methode ein Proof-of-Concept ist und noch Potentiale zur Verbesserung der Laufzeit bestehen. In der Arbeit von Braun [20] wurde die kodierte Verarbeitung einem parallel ausgelegten System gegen\u00fcbergestellt. Hierbei konnte ein besseres Langzeitverhalten des Coded Processing Ansatzes aufgezeigt werden. Durch die reduzierte Fehlerwahrscheinlichkeit mit geeignet gew\u00e4hltem Coded Processing kann es erm\u00f6glicht werden COTS (components-off-the-shelf) zu verwenden, um Kosten zu sparen, wobei die Zuverl\u00e4ssigkeit des Systems unver\u00e4ndert bleibt.<\/p>\n Braun schl\u00e4gt zudem ein Software Rejuvenation Model vor, in welchem SES durch das Partial Rejuvenation erg\u00e4nzt wird [21]. Durch die Anwendung von Markov Modellen k\u00f6nnte eine Verbesserung der Mean-Time-To-Failure (MTTF) um mehr als den Faktor 1000 gezeigt werden. Ein wichtiger Vorteil von SES ist, dass es in der problemorientierten Programmiersprache C realisiert werden kann und dass au\u00dferdem bestimmte Fehler erkannt werden, die durch den Compiler entstehen k\u00f6nnen [22]. Mit dem Thema der kodierten Verarbeitung besch\u00e4ftigt sich neben Braun et al. auch eine Forschergruppe um die TU Dresden Ausgr\u00fcndung SIListra. Die Forschergruppe entwickelt einen Compiler, der automatisiert C basierte Anwendungen nach den Prinzipien des Coded Processing transformiert und Hardware Fehler aufdecken kann [23]. Zu Verifikation von z.B. Sicherheitsma\u00dfnamen schl\u00e4gt die automobile Sicherheitsnorm ISO 26262 die Methode der Fault-Injection vor [19]. Dies kann auch auf Diagnose und \u00dcberwachungstechniken wie dem SES-Ansatz angewendet werden, bspw. durch eine auf dem Monte-Carlo-Prinzip beruhende modellbasierte Simulationsumgebung.<\/p>\n In diesem Themenfeld liegt der Fokus in der Auffindung von Entwurfswerkzeugen und geeigneten eigebetteten Architekturen, welche ein hohes Ma\u00df an Heterogenit\u00e4t aufweisen und speziell an die Bed\u00fcrfnisse der Automobil-Industrie angepasst sind. Die Simulation solcher heterogenen Architekturen ist hierf\u00fcr ein wichtiges Instrument, da oft noch kein synthetisiertes Hardware-Design existiert. Dieses Kapitel gibt einen \u00dcberblick \u00fcber vorhandene Multi- und Many-Core Simulatoren und bewertet deren Eignung f\u00fcr das Vorhaben. Drei Kriterien sind f\u00fcr die Bewertung von Bedeutung. Diese Kriterien sind (i) die\u00a0Simulationsperformanz<\/em>, (ii) die\u00a0Verf\u00fcgbarkeit von Prozessor-Modellen<\/em>\u00a0f\u00fcr eingebettete und Low-Power-Prozessoren sowie (iii) die M\u00f6glichkeit,\u00a0Energiebedarf und Rechenleistung<\/em>\u00a0zu\u00a0evaluieren<\/em>. Tabelle 1 zeigt einen zusammen\u00adfassenden Vergleich der im Folgenden bewerteten Simulationsum\u00adgebungen.<\/p>\n1 Einf\u00fchrung<\/h2>\n
\n
2 Stand der Technik<\/h2>\n
2-1 Architekturbeschreibungssprache EAST-ADL<\/h3>\n
2-2 Scheduling<\/h3>\n
2-3 Informationssicherheit<\/h3>\n
2-4 Funktionale Sicherheit<\/h3>\n
2-5 Multi- und Many-Core Simulationsumgebungen f\u00fcr Universalprozessoren<\/h3>\n