Fu¨ r rechenleistungsintensive Anwendungen wie Fahrerassistenzsysteme werden auch in eingebetteten Systemen zunehmend Mehrprozessor- und Mehrkernprozessorsysteme eingesetzt. Bei der Entwicklung eingebetteter Softwaresysteme muss im Automobilbereich insbesondere die Norm ISO 26262
Die Arbeiten wurden teilweise vom Bundesministerium fu¨r
Bildung und Forschung (BMBF) unter den Fo¨rderkennzeichen 01IS14029A
(Amalthea4Public), 01IS16025A (Aramis II) und 01IS15031H (ASSUME)
gefo¨rdert.
[
Die Anforderungen, die bei der Implementierung einer sicherheitskritischen Systemfunktion (sog. Item) zu erfu¨ llen sind, leiten sich nach ISO 26262 aus der Gefahren- und Risikoanalyse (engl.: Hazards analysis and risk assessment, kurz: HARA) und den daraus bestimmten Sicherheitszielen ab. Im Rahmen der Gefahren- und Risikoanalyse wird untersucht, welche Fehlfunktionen des Items in welchen Nutzungssituationen zu einer Gefa¨hrdung von Menschen fu¨ hren ko¨ nnen. Die Gefa¨hrdung wird in den Kategorien Schwere der zu erwartenden Verletzungen (S0–S3), Kontrollierbarkeit (C0–C3) und Exposition (E0–E4) bewertet und daraus eine grity Level (ASIL) gebildet. Auf den Gefa¨hrdungsereignissen basierend werden Sicherheitsziele als ho¨ chstrangige Sicherheitsanforderungen definiert und den Gefa¨hrdungsereignissen
Abbildung 1. Ausschnitt aus der HW-Architektur des Quadcopters zugeordnet, deren Eintritt sie verhindern sollen. Die Sicherheitsziele erhalten nach ISO 26262 neben anderen Informationen einen ASIL und eine Fehlertoleranzzeit, sofern anwendbar, die sich aus den Bewertungen der jeweils zugeordneten Gefa¨hrdungsereignisse ergeben. Wenn sichere Zusta¨nde bekannt sind, sollen auch diese angegeben werden. Ein Beispiel anhand des Quadcopters ist in Tabelle I dargestellt.
Wird die Systemfunktion in Teilfunktionalita¨ten zerlegt, so ist fu¨ r jede daraus resultierende Anforderung zu pru¨ fen, welche Sicherheitsziele durch Fehler der Teilfunktionalita¨ten verletzt werden ko¨ nnen. Entsprechend erben abgeleitete Anforderungen nach gewissen Regeln ASIL und Fehlertoleranzzeit von den u¨ bergeordneten Anforderungen. Hierbei gilt, dass eine Anforderung mit einem bestimmten ASIL durch zwei parallel durchgef u¨hrte Funktionalita¨ten mit dann niedrigerem ASIL erfu¨ llt werden. In letzterem Fall ist sicherzustellen, dass die Sta¨rke der Segregation zwischen den beiden parallelen Funktionalita¨ten dem ASIL der urspr u¨nglichen, nicht dekomponierten Anforderung entspricht.
Beim Quadrocopter wird das Sicherheitsziel SZ2 ”Die Motorsteuerung muss ausfallsicher sein“ beispielsweise dadurch erfu¨ llt werden, dass die Steuerungskomponenten redundant ausgelegt werden. Die relevante HW-Architektur ist in Abb. 1 dargestellt. Die Software fu¨ r die Motorsteuerung wird standardma¨ßig sowohl auf den MicroBlaze- und LEONSoftcores als auch dem ARM-Hardware-Kern ausgefu¨ hrt. Die Sensorwerte werden u¨ber die I2C-Schnittstelle gelesen und die resultierenden Motorstellwerte in den BRAM geschrieben. Die Voter-Komponente vergleicht die berechneten Motorsignale, und leitet bei U¨ bereinstimmung zweier Signale dieses an das Motorboard weiter. Gema¨ß der ASIL-Dekomposition kann das ASIL fu¨ r die Stellwertberechnung nun herabgesetzt werden. Fu¨ r die ECUs MicroBlaze, LEON ASIL und die Mission Control Unit ergibt sich ASIL A(C)1 und fu¨ r den Voter ASIL B(C). Die maximale Signallaufzeit Sensoren ! Rechenkerne ! Rotoren kann experimentell ermittelt werden, wie in Abschnitt III dargestellt.
MEHRKERNARCHITEKTUREN BEI DER FUNKTIONALEN
DEKOMPOSITION
Die Tiefe der funktionalen Dekomposition sollte zu einer Verfeinerung fu¨ hren, die es gestattet, Teilfunktionen eindeutig 1Das C in Klammern ist eine Referenz auf den ASIL des Sicherheitsziels. ]56 -n [m4 e g öh un3 .xaH iceh2
1 m bAw0 0
200 300 400 500 600 Regler Aktivierungsrate (Periode) [ms] Abbildung 2. Abha¨ngigkeit der durch einen Windstoß verursachten Flugho¨henabweichung von der Aktivierungsrate des Ho¨henreglers, ermittelt in 7 Simulationsla¨ufen (gru¨n = innerhalb, rot = außerhalb des erlaubten Bereiches).
Elementen der Zielplattform zuordnen zu ko¨ nnen. Mehrkernsysteme bieten kosteng u¨nstige Hardware mit viel Rechenleistung und spielen dadurch bei komplexen Eingebetteten Systemen eine zunehmend wichtigere Rolle. Bei der Realisierung einer Systemfunktion mit mehreren parallel arbeitenden Berechnungselementen entstehen allerdings neue Herausforderungen. Bei zeitkritischen Funktionen werden Garantien ben o¨tigt, die die Verfu¨ gbarkeit von Ergebnissen zu einem gewissen Zeitpunkt zusichern. Scheduling- und MappingEntscheidungen sollen vom Entwickler so gewa¨hlt werden, dass die beno¨ tigten Berechnungsergebnisse auch rechtzeitig bereit stehen. Damit diese Entscheidungen richtig getroffen werden ko¨ nnen, werden konkrete technische Anforderungen (z.B. an die Aktivierungsperiode von periodisch durchgef u¨hrten Berechnungen) beno¨ tigt, welche zwar implizit in den Anforderungen auf Systemebene enthalten sind, aber daraus zuna¨chst noch abgeleitet werden mu¨ ssen. Fu¨ r diese Dekomposition der System-Anforderungen werden zusa¨tzliche Informationen beispielsweise u¨ ber die eingesetzte Hardware beno¨ tigt. Diese fließen dann in die abgeleiteten Anforderungen der Teilfunktionen mit ein.
In Sicherheitsziel SZ1 (siehe I) wurde identifiziert, dass der Quadcopter gegen Windsto¨ ße robust sein muss. In Abb. 2 wurden die Auswirkungen verschiedener Berechnungszeiten simuliert. So ko¨ nnen konkrete technische Anforderung an die untergeordneten Systemkomponenten (Scheduling der Regler) abgeleitet werden.
IV. ABLEITUNG VON SOFTWAREANFORDERUNGEN
Parallel zur funktionalen Dekomposition werden neben
Hardwareanforderungen auch feingranulare
Softwareanforderungen aus den Systemanforderungen und den
Sicherheitszielen abgeleitet. F u¨r einen ISO 26262-konformen und
effizienten Entwicklungsprozess ist es wichtig, dass Anforderungen
u¨ ber die verschiedenen Entwurfsebenen und -sichten hinweg
nachverfolgt werden ko¨ nnen. Um hohe Qualita¨tsstandards
sicherzustellen und unno¨ tige Kosten durch Fehler in spa¨teren
Entwicklungsschritten zu vermeiden, sollten Anforderungen
m o¨glichst fru¨ h wa¨hrend der funktionalen Dekomposition auf
Konsistenz u¨ berpru¨ ft werden. Dabei helfen formale
Spezifikationssprachen wie das Simplified Universal Pattern [
Fehlerfall Abweichung > Y der Flugsteuerung
Situation Windsta¨rke X, im Flug
Die technische Realisierung des Systems besteht einerseits aus der Entwicklung einer Software- aus der Systemarchitektur, und andererseits aus der Auswahl einer geeigneten Hardwarearchitektur, auf der die Software schließlich ausgerollt wird. Die ISO 26262 fordert, dass in diesem Prozess die Sicherheitsanforderungen der Systemarchitektur und daraus abgeleitete Fehlermodelle in der technischen Realisierung nachverfolgt werden. Eine dienst-basierte Modellierung soll diese Nachverfolgbarkeit stark vereinfachen. Hierbei werden die Funktionen mit Diensten (im Sinne von Fa¨higkeiten) assoziiert, die sie fu¨ r die Umsetzung ihrer Aufgabe beno¨ tigen. Zum Beispiel muss fu¨ r eine Funktion, die fu¨ r ihre Operation Eingabedaten beno¨ tigt, ein entsprechender Dienst zum Erhalt dieser Daten zur Verfu¨ gung stehen. A¨hnlich werden Funktionen, die als Softwarekomponenten realisiert werden, entsprechend die Fa¨higkeit zur Ausfu¨ hrung durch die Hardware beno¨ tigen. Ein konzeptuelles Metamodell zur Modellierung von Diensten ist in Abb. 3 dargestellt, welches als Erweiterung des AMALTHEA Metamodells angelegt ist.
Vermo¨ ge dieses Dienstkonzeptes kann nunmehr auch die
Fehlermodellierung erfolgen, indem Fehler nicht mehr direkt
mit den Funktionen sondern mit Diensten assoziiert werden.
Fehler von Diensten, die fu¨ r die Realisierung der
Schnittstellen beno¨ tigt werden, werden ebenfalls an diesen
Schnittstellen sichtbar. Fehler von Ausfu¨ hrungsdiensten werden als
interne Systemfehler der Funktion sichtbar. Die
Identifikation von Fehlerpropagationen erfolgt mit etablierten
Methoden, beispielsweise durch entsprechende Fehlermodellierung
(z.B. HIP-HOPS [
Daru¨ ber hinaus bietet dieser Ansatz die Mo¨ glichkeit, bereits wa¨hrend der Entwicklung der Funktionsarchitektur (abstrakte) Hardware-Ressourcen mit den Diensten zu assoziieren (vgl. uses Beziehung zwischen ServiceCapability und Resource). Hierdurch ko¨ nnen unter anderem ra¨umliche Segregationanforderungen ausgedru¨ ckt werden, indem Funktionen Dienste mit unterschiedlichen assoziierten Resourcen benutzen. Schließlich zeigt Abb. 3 eine Mo¨ glichkeit, Spezifikationen zu erstellen, die die Benutzung der Dienste genauer formulieren. Hiermit ko¨ nnen dann zeitliche Segregationeigenschaften ausgedru¨ ckt werden, indem die maximalen Interferenzen durch gemeinsame Benutzung der assoziierten Ressourcen festgelegt werden.
Der dargestellte Ansatz wird f u¨r die Softwarearchitektur ebenfalls angewendet. Dabei werden bei dem Softwareentwurf die verwendeten Schnittstellen definiert und ebenso wie fu¨ r die Ausfu¨ hrung der Funktionen mit den dafu¨ r notwendigen Dienste assoziiert. Im Zuge dieses Entwurfsschrittes wird die Nachverfolgbarkeit der in der Funktionsarchitektur vorgenommenen Fehlermodellierung durch eine Allokation der entsprechenden Dienste sichergestellt. In Abb. 4 ist dies im unteren Bereich durch gestrichelte Linien angedeutet. Diese Beziehung erm o¨glicht es dem Entwickler unter anderem nachzuvollziehen, ob die Kombination aus HW/SW Fehlern durch die identifizierten Systemfehler abgedeckt sind. Ebenso kann auf diese Weise die Konsistenz der Fehlermodellierung im Hinblick auf Fehlerpropagationen u¨ berpru¨ ft werden. Insbesondere ko¨ nnen bereits Verletzungen von bestimmten Unabha¨ngigkeitseigenschaften u¨ berpru¨ ft werden, die durch die Allokation von mehreren Diensten der Funktionsarchitektur auf Dienste der Softwarearchitektur entstehen ko¨ nnen (in Abb. 4 z.B. durch die Allokation der Dienste ServiceA der Funktionen auf ServiceA’).
Die HW/SW-Schnittstelle stellt fu¨ r die Umsetzung der ISO 26262 ein Schlu¨ ssselement in dem Sicherheitsprozess der technischen Realisierung dar, da durch sie die Beziehungen zwischen auftretenden HW Fehlern und ihrer Wirkung auf die SW sichtbar wird. In MC Systemen wird diese Aufgabe dadurch erschwert, dass aufgrund der gemeinsamen Ressourcennutzung komplexe Wechselbeziehungen entstehen ko¨ nnen.
Um Anforderungen der ISO in einem modellbasierten Ansatz zu adressieren, wird die Hardware mit ihren bereitgestellten Schnittstellen und den mo¨ glichen Fehlertypen modelliert. Auch hier kann das oben beschriebene dienstbasierte Vorgehen genutzt werden. Auf Basis dieser Modelle ist es dann mo¨ glich, bei der Allokation der Softwarekomponenten auf die vorhandene Hardware auch die Zwangsbedingungen zu beru¨ cksichtigen, die sich aus den Anforderungen der Funktionalen Sicherheit ergeben. Die oben eingefu¨ hrten Konzepte werden mit in dem Projekt AMALTHEA4public entwickelten Modellierungskonzepten kombiniert. Die Modellierungssprache erlaubt die Definition von sogenannten Zugriffspfaden, mit deren Hilfe Abla¨ufe innerhalb der Hardware dargestellt werden ko¨ nnen. Ein Beispiel aus der Flugsteuerung des Quadcopters zeigt Abb. 5, in dem der Zugriffspfad vom LEON-Softcore u¨ ber den Systembus (AXI) zum Datenspeicher (BRAM) definiert ist. Abbildung 3. Konzeptuelles Metamodell fu¨r Dienste und Ressourcen Abbildung 4. Allokation von Diensten zwischen Funktionen und Software Failure: invalid output
Fault: wrong value realises Fault Fault
Die HW/SW-Schnittstelle wird hierbei mit Hilfe der Dienste realisiert. In dem Beispiel wird angenommen, dass Ausgaben der Softwarekomponente u¨ ber einen Dienst realisiert werden, bei dem die Daten in den lokalen Datenspeicher geschrieben werden. Umgesetzt werden diese Dienste durch die ”Benutzung“ dieser Zugriffspfade, was durch eine entsprechende Realisierungsbeziehung in Abb. 5 angedeutet ist.
Der Modellierungsansatz adressiert mehrere Anforderungen eines ISO 26262 konformen Entwicklungsprozesses. Erstens erlaubt dies die Analyse von Segregationseigenschaften, indem untersucht werden kann, welche Elemente auf die verschiedenen Hardwarewaressourcen zugreifen. Durch eine verfeinerte Spezifikation des zeitlichen Aspekts, d.h., wann und wie ha¨ufig Dienste von Softwarekomponenten genutzt werden, kann die zeitliche Segregation durch eine entsprechend durchgefu¨ hrte Schedulinganalyse u¨ berpru¨ ft werden.
Zweitens erlaubt der Modellierungsansatz die detaillierte Analyse von Fehlereffekten der Hardware auf die Softwarekomponenten. Entsprechende Fehlermodelle fu¨ r die einzelnen Hardwarekomponenten vorausgesetzt, erlaubt die Modellierung von Zugriffspfaden die Ableitung von entsprechenden Fehlermodellen f u¨r die Zugriffspfade selbst und damit indirekt fu¨ r die damit assoziierten Dienste.
Das Papier zeigt wesentliche Anforderungen an ISO26262 konforme Entwicklungsprozesse auf, wobei insbesondere die durchga¨ngige und nachverfolgbare Absicherung von Sicherheitszielen bei dem Entwurf der verschiedenen Architekturebenen (System, Hardware, Software) fu¨ r Mehrkernsysteme Ber u¨cksichtigung findet.
Neben der notwendigen Integration der beschriebenen Konzepte in das AMALTHEA Metmodell ist zu bemerken, dass mit Zugriffspfaden und entsprechenden Fehlermodellen angereicherte Hardwaremodelle anwendungsunabha¨ngig und damit wiederverwendbar sind. Es wa¨re daher wu¨ nschenswert, wenn solche Modelle von den Hardwareherstellern bereitgestellt wu¨ rden.