Entwurfsabsicherung für eingebettete Mehrkernsysteme im Kontext der ISO 26262 Benedikt Bauer⇤ , Jan Steffen Becker† , Thomas Peikenkamp† , Christof Schlaak† , Ingo Stierand† ⇤ TWT GmbH Science & Innovation benedikt.bauer@twt-gmbh.de † OFFIS becker,peikenkamp,schlaak,stierand@offis.de Zusammenfassung—Für rechenleistungsintensive Anwendun- [1] beachtet werden. Diese Arbeit beinhaltet eine Zusam- gen wie Fahrerassistenzsysteme werden auch in eingebetteten menstellung von Ergebnissen nationaler und internationaler Systemen zunehmend Mehrprozessor- und Mehrkernprozessor- Forschungsprojekte (insbesondere Amalthea4public, Aramis II systeme eingesetzt. In diesem Papier wird dargestellt, wie sich Anforderungen im Rahmen eines Mehrkernsystementwurfs unter und ASSUME), die Fragen des sicherheitsgerichteten Ent- Verwendung geeigneter, standardisierter Modellierungskonzepte wurfs von Applikationen für Mehrkernsysteme untersuchen. ISO 26262 konform umgesetzt werden können. Dementsprechend Die Ergebnisse werden exemplarisch in einen ISO 26262- wird aufgezeigt, wie sich sicherheitsrelevante Anforderungen der konformen Entwicklungsprozess eingeordnet. Systemebene auf die untergeordneten System-Komponenten (z.B. Als laufendes Beispiel dient in dieser Arbeit ein fern- Regler) und letztendlich die HW/SW-Architektur heruntergebro- chen werden. In sicherheitskritischen Anwendungsbereichen gibt gesteuerter, unbemannter Helikopter mit vier Rotoren, im es dort insbesondere auch Anforderungen und Einschränkungen, folgenden Quadcopter genannt. Der Quadcopter dient zur die bei der Partitionierung und Verteilung zu beachten sind. Videoübertragung bei Ballspielen und ist daher mit einer Für die Verteilung von Softwarekomponenten auf die einzelnen schwenkbaren Kamera und Objekt-Tracking-Software ausge- Prozessorkerne kommen hierbei meist Algorithmen zum Einsatz, stattet. Die Flugsteuerung, insbesondere die Steuerung der da eine Verteilung unter Beachtung aller Zwangsbedigungen von ” Rotoren, wird als sicherheitskritisch betrachtet. Es wurde hier Hand“ nicht mehr zu leisten ist. Am Beispiel von Methoden und Werkzeugen, welche im AMALTHEA Projekt entwickelt wurden, bewusst kein Beispiel aus dem Automobilbereich gewählt, wird gezeigt, welche Arten von Anforderungen dies sind und wie um zu verdeutlichen, dass die vorgestellten Methoden auch sie ermittelt werden können. in anderen Domänen als der ISO 26262 eingesetzt werden Abstract—For computing-intensive applications such as driver können. Der Aufbau dieses Artikels orientiert sich grob an der assistance systems, multiprocessor and multi-core processor systems are increasingly being used in embedded systems. This paper shows Struktur der ISO 26262. Abschnitt II stellt die Gefahren- und how requirements for a multi-core system design can be imple- Risikoanalyse vor. Darauf aufbauend werden in Abschnitt III mented in compliance to ISO 26262 modeling concepts, i.e. safety Anforderungen auf Systemebene und in Abschnitt IV. In standards. Accordingly, safety-relevant system-level requirements Abschnitt V wird als Kernthema dieser Arbeit der Dienst- have to be broken down to the subordinate system components basierte Entwurf der technischen Architektur vorgestellt und (e.g., controllers) as well as the hardware and software architecture. In safety-critical application domains, there are also requirements dies in Abschnitt VI für die Hardware/Software-Schnittstelle and limitations that must be taken into account during partition- eingesetzt. Die Arbeit schließt mit einem Ausblick in Ab- ing, mapping, and distribution processes. For the distribution of schnitt VII. software components to the individual processing cores, various algorithms are mostly used, since a manual distribution under II. HARA & A BLEITUNG S ICHERHEITSZIELE consideration of all constraints is error prone, time consuming, and ineffective. This paper finally presents a way to determine and Die Anforderungen, die bei der Implementierung einer identify requirement types along with methods and tools that are sicherheitskritischen Systemfunktion (sog. Item) zu erfüllen supported by the APP4MC platform. sind, leiten sich nach ISO 26262 aus der Gefahren- und Risikoanalyse (engl.: Hazards analysis and risk assessment, I. E INLEITUNG kurz: HARA) und den daraus bestimmten Sicherheitszielen ab. Im Rahmen der Gefahren- und Risikoanalyse wird un- Für rechenleistungsintensive Anwendungen wie Fahreras- tersucht, welche Fehlfunktionen des Items in welchen Nut- sistenzsysteme werden auch in eingebetteten Systemen zu- zungssituationen zu einer Gefährdung von Menschen führen nehmend Mehrprozessor- und Mehrkernprozessorsysteme ein- können. Die Gefährdung wird in den Kategorien Schwere gesetzt. Bei der Entwicklung eingebetteter Softwaresysteme der zu erwartenden Verletzungen (S0–S3), Kontrollierbarkeit muss im Automobilbereich insbesondere die Norm ISO 26262 (C0–C3) und Exposition (E0–E4) bewertet und daraus eine Kritikalitätsbewertung in Form eines Automotive Safety Inte- Die Arbeiten wurden teilweise vom Bundesministerium für Bil- grity Level (ASIL) gebildet. Auf den Gefährdungsereignissen dung und Forschung (BMBF) unter den Förderkennzeichen 01IS14029A (Amalthea4Public), 01IS16025A (Aramis II) und 01IS15031H (ASSUME) basierend werden Sicherheitsziele als höchstrangige Sicher- gefördert. heitsanforderungen definiert und den Gefährdungsereignissen SEERTS 2018: Workshop on Software Engineering for Applied Embedded RealTime Systems @ SE18, Ulm, Germany 107 6 Abweichung [m] 5 max. Höhen- 4 3 2 1 0 0 100 200 300 400 500 600 700 Regler Aktivierungsrate (Periode) [ms] Abbildung 2. Abhängigkeit der durch einen Windstoß verursachten Flughöhenabweichung von der Aktivierungsrate des Höhenreglers, ermittelt in 7 Simulationsläufen (grün = innerhalb, rot = außerhalb des erlaubten Bereiches). Abbildung 1. Ausschnitt aus der HW-Architektur des Quadcopters Elementen der Zielplattform zuordnen zu können. Mehrkern- zugeordnet, deren Eintritt sie verhindern sollen. Die Sicher- systeme bieten kostengünstige Hardware mit viel Rechen- heitsziele erhalten nach ISO 26262 neben anderen Informatio- leistung und spielen dadurch bei komplexen Eingebetteten nen einen ASIL und eine Fehlertoleranzzeit, sofern anwend- Systemen eine zunehmend wichtigere Rolle. Bei der Realisie- bar, die sich aus den Bewertungen der jeweils zugeordneten rung einer Systemfunktion mit mehreren parallel arbeitenden Gefährdungsereignisse ergeben. Wenn sichere Zustände be- Berechnungselementen entstehen allerdings neue Herausfor- kannt sind, sollen auch diese angegeben werden. Ein Beispiel derungen. Bei zeitkritischen Funktionen werden Garantien anhand des Quadcopters ist in Tabelle I dargestellt. benötigt, die die Verfügbarkeit von Ergebnissen zu einem Wird die Systemfunktion in Teilfunktionalitäten zerlegt, gewissen Zeitpunkt zusichern. Scheduling- und Mapping- so ist für jede daraus resultierende Anforderung zu prüfen, Entscheidungen sollen vom Entwickler so gewählt werden, welche Sicherheitsziele durch Fehler der Teilfunktionalitäten dass die benötigten Berechnungsergebnisse auch rechtzei- verletzt werden können. Entsprechend erben abgeleitete Anfor- tig bereit stehen. Damit diese Entscheidungen richtig ge- derungen nach gewissen Regeln ASIL und Fehlertoleranzzeit troffen werden können, werden konkrete technische Anfor- von den übergeordneten Anforderungen. Hierbei gilt, dass derungen (z.B. an die Aktivierungsperiode von periodisch eine Anforderung mit einem bestimmten ASIL durch zwei durchgeführten Berechnungen) benötigt, welche zwar implizit parallel durchgeführte Funktionalitäten mit dann niedrigerem in den Anforderungen auf Systemebene enthalten sind, aber ASIL erfüllt werden. In letzterem Fall ist sicherzustellen, dass daraus zunächst noch abgeleitet werden müssen. Für diese die Stärke der Segregation zwischen den beiden parallelen Dekomposition der System-Anforderungen werden zusätzliche Funktionalitäten dem ASIL der ursprünglichen, nicht dekom- Informationen beispielsweise über die eingesetzte Hardware ponierten Anforderung entspricht. benötigt. Diese fließen dann in die abgeleiteten Anforderungen Beim Quadrocopter wird das Sicherheitsziel SZ2 Die der Teilfunktionen mit ein. ” In Sicherheitsziel SZ1 (siehe I) wurde identifiziert, dass der Motorsteuerung muss ausfallsicher sein“ beispielsweise da- durch erfüllt werden, dass die Steuerungskomponenten red- Quadcopter gegen Windstöße robust sein muss. In Abb. 2 undant ausgelegt werden. Die relevante HW-Architektur ist wurden die Auswirkungen verschiedener Berechnungszeiten in Abb. 1 dargestellt. Die Software für die Motorsteuerung simuliert. So können konkrete technische Anforderung an die wird standardmäßig sowohl auf den MicroBlaze- und LEON- untergeordneten Systemkomponenten (Scheduling der Regler) Softcores als auch dem ARM-Hardware-Kern ausgeführt. Die abgeleitet werden. Sensorwerte werden über die I2C-Schnittstelle gelesen und die resultierenden Motorstellwerte in den BRAM geschrieben. Die IV. A BLEITUNG VON S OFTWAREANFORDERUNGEN Voter-Komponente vergleicht die berechneten Motorsignale, Parallel zur funktionalen Dekomposition werden neben und leitet bei Übereinstimmung zweier Signale dieses an das Hardwareanforderungen auch feingranulare Softwareanforde- Motorboard weiter. Gemäß der ASIL-Dekomposition kann das rungen aus den Systemanforderungen und den Sicherheitszie- ASIL für die Stellwertberechnung nun herabgesetzt werden. len abgeleitet. Für einen ISO 26262-konformen und effizien- Für die ECUs MicroBlaze, LEON ASIL und die Mission ten Entwicklungsprozess ist es wichtig, dass Anforderungen Control Unit ergibt sich ASIL A(C)1 und für den Voter ASIL über die verschiedenen Entwurfsebenen und -sichten hinweg B(C). Die maximale Signallaufzeit Sensoren ! Rechenkerne nachverfolgt werden können. Um hohe Qualitätsstandards ! Rotoren kann experimentell ermittelt werden, wie in Ab- sicherzustellen und unnötige Kosten durch Fehler in späteren schnitt III dargestellt. Entwicklungsschritten zu vermeiden, sollten Anforderungen möglichst früh während der funktionalen Dekomposition auf III. B ER ÜCKSICHTIGUNG VON Konsistenz überprüft werden. Dabei helfen formale Spezifi- M EHRKERNARCHITEKTUREN BEI DER FUNKTIONALEN kationssprachen wie das Simplified Universal Pattern [2], [3]. D EKOMPOSITION Diese erlauben durch ihre eindeutige Semantik automatisierte Die Tiefe der funktionalen Dekomposition sollte zu einer (Konsistenz-)Analysen und Testfallgenerierung. In [4] wird Verfeinerung führen, die es gestattet, Teilfunktionen eindeutig eine integrierte Toolchain vorgestellt, die Formalisierung, Kon- sistenzanalyse, Testfallgenerierung und Qualitätsmanagement 1 Das C in Klammern ist eine Referenz auf den ASIL des Sicherheitsziels. abdeckt. SEERTS 2018: Workshop on Software Engineering for Applied Embedded RealTime Systems @ SE18, Ulm, Germany 108 Hazard Fehlerfall Situation Sicherheitsziel ASIL Unkontrolliertes Flugverhalten Abweichung > Y der Flug- Windstärke  X, im Flug SZ1: Die Positionsabweichung E4,C3,S2 steuerung durch Seitenwinde  X darf )C maximal Y betragen. Absturz Ausfall der Motorsteuerung Im Flug SZ2: Die Motorsteuerung muss E4,C3,S2 ausfallsicher sein. )C Tabelle I T EIL DER HARA F ÜR DEN Q UADCOPTER V. NACHVERFOLGUNG VON A NFORDERUNGEN ENTLANG werden. DES H ARDWARE / S OFTWARE E NTWURFS Der dargestellte Ansatz wird für die Softwarearchitektur ebenfalls angewendet. Dabei werden bei dem Softwareentwurf Die technische Realisierung des Systems besteht einerseits die verwendeten Schnittstellen definiert und ebenso wie für aus der Entwicklung einer Software- aus der Systemarchi- die Ausführung der Funktionen mit den dafür notwendigen tektur, und andererseits aus der Auswahl einer geeigneten Dienste assoziiert. Im Zuge dieses Entwurfsschrittes wird Hardwarearchitektur, auf der die Software schließlich ausge- die Nachverfolgbarkeit der in der Funktionsarchitektur vor- rollt wird. Die ISO 26262 fordert, dass in diesem Prozess genommenen Fehlermodellierung durch eine Allokation der die Sicherheitsanforderungen der Systemarchitektur und dar- entsprechenden Dienste sichergestellt. In Abb. 4 ist dies im aus abgeleitete Fehlermodelle in der technischen Realisierung unteren Bereich durch gestrichelte Linien angedeutet. Die- nachverfolgt werden. Eine dienst-basierte Modellierung soll se Beziehung ermöglicht es dem Entwickler unter anderem diese Nachverfolgbarkeit stark vereinfachen. Hierbei werden nachzuvollziehen, ob die Kombination aus HW/SW Fehlern die Funktionen mit Diensten (im Sinne von Fähigkeiten) durch die identifizierten Systemfehler abgedeckt sind. Ebenso assoziiert, die sie für die Umsetzung ihrer Aufgabe benötigen. kann auf diese Weise die Konsistenz der Fehlermodellie- Zum Beispiel muss für eine Funktion, die für ihre Opera- rung im Hinblick auf Fehlerpropagationen überprüft werden. tion Eingabedaten benötigt, ein entsprechender Dienst zum Insbesondere können bereits Verletzungen von bestimmten Erhalt dieser Daten zur Verfügung stehen. Ähnlich werden Unabhängigkeitseigenschaften überprüft werden, die durch die Funktionen, die als Softwarekomponenten realisiert werden, Allokation von mehreren Diensten der Funktionsarchitektur entsprechend die Fähigkeit zur Ausführung durch die Hardwa- auf Dienste der Softwarearchitektur entstehen können (in re benötigen. Ein konzeptuelles Metamodell zur Modellierung Abb. 4 z.B. durch die Allokation der Dienste ServiceA der von Diensten ist in Abb. 3 dargestellt, welches als Erweiterung Funktionen auf ServiceA’). des AMALTHEA Metamodells angelegt ist. Vermöge dieses Dienstkonzeptes kann nunmehr auch die VI. HW/SW S CHNITTSTELLE Fehlermodellierung erfolgen, indem Fehler nicht mehr direkt mit den Funktionen sondern mit Diensten assoziiert werden. Die HW/SW-Schnittstelle stellt für die Umsetzung der ISO Fehler von Diensten, die für die Realisierung der Schnitt- 26262 ein Schlüssselement in dem Sicherheitsprozess der stellen benötigt werden, werden ebenfalls an diesen Schnitt- technischen Realisierung dar, da durch sie die Beziehungen stellen sichtbar. Fehler von Ausführungsdiensten werden als zwischen auftretenden HW Fehlern und ihrer Wirkung auf interne Systemfehler der Funktion sichtbar. Die Identifikati- die SW sichtbar wird. In MC Systemen wird diese Aufgabe on von Fehlerpropagationen erfolgt mit etablierten Metho- dadurch erschwert, dass aufgrund der gemeinsamen Ressour- den, beispielsweise durch entsprechende Fehlermodellierung cennutzung komplexe Wechselbeziehungen entstehen können. (z.B. HIP-HOPS [5], AltaRica [6]). Sobald entsprechende Um Anforderungen der ISO in einem modellbasierten An- Ausführungsmodelle der Funktionen existieren, sollte dies satz zu adressieren, wird die Hardware mit ihren bereitgestell- durch direkte Fehlerinjektion erfolgen (z.B. [7]). Hierdurch ten Schnittstellen und den möglichen Fehlertypen modelliert. kann sichergestellt werden, dass die Fehlermodellierung die Auch hier kann das oben beschriebene dienstbasierte Vorge- relevanten Fehlerphänomene tatsächlich abdeckt. hen genutzt werden. Auf Basis dieser Modelle ist es dann Darüber hinaus bietet dieser Ansatz die Möglichkeit, bereits möglich, bei der Allokation der Softwarekomponenten auf während der Entwicklung der Funktionsarchitektur (abstrakte) die vorhandene Hardware auch die Zwangsbedingungen zu Hardware-Ressourcen mit den Diensten zu assoziieren (vgl. berücksichtigen, die sich aus den Anforderungen der Funk- uses Beziehung zwischen ServiceCapability und Resource). tionalen Sicherheit ergeben. Die oben eingeführten Konzepte Hierdurch können unter anderem räumliche Segregationanfor- werden mit in dem Projekt AMALTHEA4public entwickelten derungen ausgedrückt werden, indem Funktionen Dienste mit Modellierungskonzepten kombiniert. Die Modellierungsspra- unterschiedlichen assoziierten Resourcen benutzen. Schließ- che erlaubt die Definition von sogenannten Zugriffspfaden, mit lich zeigt Abb. 3 eine Möglichkeit, Spezifikationen zu er- deren Hilfe Abläufe innerhalb der Hardware dargestellt werden stellen, die die Benutzung der Dienste genauer formulieren. können. Ein Beispiel aus der Flugsteuerung des Quadcopters Hiermit können dann zeitliche Segregationeigenschaften aus- zeigt Abb. 5, in dem der Zugriffspfad vom LEON-Softcore gedrückt werden, indem die maximalen Interferenzen durch über den Systembus (AXI) zum Datenspeicher (BRAM) defi- gemeinsame Benutzung der assoziierten Ressourcen festgelegt niert ist. SEERTS 2018: Workshop on Software Engineering for Applied Embedded RealTime Systems @ SE18, Ulm, Germany 109 Abbildung 3. Konzeptuelles Metamodell für Dienste und Ressourcen zeitliche Segregation durch eine entsprechend durchgeführte Schedulinganalyse überprüft werden. Zweitens erlaubt der Modellierungsansatz die detaillierte Analyse von Fehlereffekten der Hardware auf die Software- komponenten. Entsprechende Fehlermodelle für die einzelnen Hardwarekomponenten vorausgesetzt, erlaubt die Modellie- rung von Zugriffspfaden die Ableitung von entsprechenden Fehlermodellen für die Zugriffspfade selbst und damit indirekt für die damit assoziierten Dienste. VII. Z USAMMENFASSUNG UND AUSBLICK Das Papier zeigt wesentliche Anforderungen an ISO26262 Abbildung 4. Allokation von Diensten zwischen Funktionen und Software konforme Entwicklungsprozesse auf, wobei insbesondere die durchgängige und nachverfolgbare Absicherung von Sicher- Failure: invalid output heitszielen bei dem Entwurf der verschiedenen Architekture- benen (System, Hardware, Software) für Mehrkernsysteme Fault: wrong value Berücksichtigung findet. Neben der notwendigen Integration der beschriebenen Kon- zepte in das AMALTHEA Metmodell ist zu bemerken, dass mit Zugriffspfaden und entsprechenden Fehlermodellen ange- realises Fault reicherte Hardwaremodelle anwendungsunabhängig und damit wiederverwendbar sind. Es wäre daher wünschenswert, wenn solche Modelle von den Hardwareherstellern bereitgestellt würden. L ITERATUR Fault Fault Fault [1] ISO 26262:Road vehicles—Functional safety, 1st ed., International Orga- nization for Standardization, 11 2011. Abbildung 5. Modellierung der HW/SW Architektur [2] T. Bienmüller, T. Teige, A. Eggers, and M. Stasch, “Modeling requi- rements for quantitative consistency analysis and automatic test case Die HW/SW-Schnittstelle wird hierbei mit Hilfe der Dienste generation,” in Workshop on Formal and Model-Driven Techniques for Developing Trustworthy Systems, 2016. realisiert. In dem Beispiel wird angenommen, dass Ausgaben [3] T. Teige, T. Bienmüller, and H. J. Holberg, “Universal pattern: Formali- der Softwarekomponente über einen Dienst realisiert werden, zation, testing, coverage, verification, and test case generation for safety- bei dem die Daten in den lokalen Datenspeicher geschrieben critical requirements,” in MBMV, 2016. [4] J. S. Becker, V. Bertram, T. Bienmüller, U. Brockmeyer, H. Dörr, werden. Umgesetzt werden diese Dienste durch die Benut- ” T. Peikenkamp, and T. Teige, “Interoperable toolchain for requirements- zung“ dieser Zugriffspfade, was durch eine entsprechende driven model-based development,” in ERTS, 2018. Realisierungsbeziehung in Abb. 5 angedeutet ist. [5] Y. Papadopoulos and J. A. McDermid, Hierarchically Performed Hazard Origin and Propagation Studies, 1999. Der Modellierungsansatz adressiert mehrere Anforderungen [6] F. Kuntz, S. Gaudan, C. Sannino, É. Laurent, A. Griffault, and G. Point, eines ISO 26262 konformen Entwicklungsprozesses. Erstens “Model-based diagnosis for avionics systems using minimal cuts,” in DX, erlaubt dies die Analyse von Segregationseigenschaften, indem M. Sachenbacher, O. Dressler, and M. Hofbaur, Eds., Germany, 2011, pp. 138–145. untersucht werden kann, welche Elemente auf die verschiede- [7] T. Peikenkamp, A. Cavallo, L. Valacca, E. Böde, M. Pretzer, and E. M. nen Hardwarewaressourcen zugreifen. Durch eine verfeinerte Hahn, Towards a Unified Model-Based Safety Assessment, 2006. Spezifikation des zeitlichen Aspekts, d.h., wann und wie häufig Dienste von Softwarekomponenten genutzt werden, kann die SEERTS 2018: Workshop on Software Engineering for Applied Embedded RealTime Systems @ SE18, Ulm, Germany 110