=Paper=
{{Paper
|id=Vol-2066/seerts2018paper04
|storemode=property
|title=Entwurfsabsicherung für eingebettete Mehrkernsysteme im Kontext der ISO 26262 (Design Validation for Embedded Multi-core Systems in the Context of ISO 26262)
|pdfUrl=https://ceur-ws.org/Vol-2066/seerts2018paper04.pdf
|volume=Vol-2066
|authors=Benedikt Bauer,Jan Steffen Becker,Thomas Peikenkamp,Christof Schlaak,Ingo Stierand
|dblpUrl=https://dblp.org/rec/conf/se/BauerBPSS18
}}
==Entwurfsabsicherung für eingebettete Mehrkernsysteme im Kontext der ISO 26262 (Design Validation for Embedded Multi-core Systems in the Context of ISO 26262)==
https://ceur-ws.org/Vol-2066/seerts2018paper04.pdf
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