Autoren: Ulrich Kloidt, Altium Europe GmbH, Rudolf Grave, Elektrobit (EB)<\/p>\n
Die Integration sicherheitsrelevanter Anwendungen im AUTOSAR-Umfeld stellt eine Herausforderung dar, da nahezu immer Software mit unterschiedlichen Sicherheitszielen integriert werden muss, kombiniert mit einem R\u00fcckwirkungsfreiheitsargument. Zur Unterst\u00fctzung des Integrators soll hier eine automatisierte \u00dcberpr\u00fcfung vorgestellt werden, die die Entwicklung von Software im Safety-Umfeld wesentlich erleichtert. Diese Vorgehensweise f\u00fchrt zu einer besseren Ausnutzung der Hardware-Ressourcen und reduzierten Entwicklungszeit und damit zu geringeren Kosten.<\/strong><\/p>\n Um die Sicherheit elektronischer Systeme durch Standardisierung zu erh\u00f6hen, wurden verschiedene Normen entwickelt. Im Kraftfahrzeugbereich findet beispielsweise die ISO 26262 Anwendung. Diese dient der Gew\u00e4hrleisung der funktionalen Sicherheit eines Systems mit elektrischen\/elektronischen Komponenten. Sicherheitsstandards f\u00fcr andere Bereiche werden in Normen wie IEC 61508, ISO 25119 oder EN 50128 definiert.<\/em><\/p>\n Traditionell werden sicherheitskritische Softwarefunktionen von einer separaten Einzelprozessor-Steuereinheit (ECU) verarbeitet. Diese Praxis gew\u00e4hrleistet eine Trennung von Funktionen mit unterschiedlichen Sicherheitsintegrit\u00e4tsebenen (SIL), da eine physikalische Trennung besteht und damit eine gegenseitige Beeinflussung ausgeschlossen wird.<\/p>\n Gegenw\u00e4rtig werden mehrere dieser Einzelprozessor-Steuerger\u00e4te durch wenige Mehrkern-Steuerger\u00e4te ersetzt. Vorteile dieser L\u00f6sung sind eine Reduzierung des Verkabelungsaufwands und auch des Stromverbrauchs. Diese Ma\u00dfnahme bedeutet aber die parallele Existenz von Funktionen mit unterschiedlichen Sicherheitsanforderungen in einer ECU.<\/p>\n Das ist nach ISO 26262 nur dann zul\u00e4ssig, wenn eine R\u00fcckwirkungsfreiheit (Freedom from Interference) zwischen den Softwarekomponenten, die eine unterschiedliche Sicherheitsintegrit\u00e4tsebene bzw. unterschiedliche Sicherheitsanforderungen haben, garantiert ist. Als Beispiel w\u00fcrde sowohl eine Funktion mit ASIL A Anforderungen von einer ASIL C Funktion getrennt \u00a0als auch zwei ASIL D Funktionen mit inhaltlich unterschiedlichen Sicherheitsanforderungen.<\/p>\n Des Weiteren darf eine sicherheitsrelevante Funktion z.B. nicht durch die Basis-Software beeinflusst werden. Eine M\u00f6glichkeit, dieses zu erreichen, ist die Speicherpartitionierung (Software Partitioning), die durch den Einsatz einer Memory Protection Unit (MPU) realisiert wird. Dieser Ansatz ist aufw\u00e4ndig und bedingt eine vorhandene Hardware, auf der die Anwendung getestet werden kann. Effizienter ist es, schon fr\u00fcher in den Entwicklungsprozess einzugreifen und die Einhaltung der Speicherpartitionierung mittels einer Software zu \u00fcberpr\u00fcfen.<\/p>\n In der ISO 26262, Teil 1, Definition 1.49 wird die R\u00fcckwirkungsfreiheit beschrieben als „Nichtvorhandensein von Kaskadierungsfehlern zwischen zwei oder mehr Elementen, die zur Verletzung einer Sicherheitsanforderung f\u00fchren k\u00f6nnen.“ Zum Beispiel sind Element 1 und Element 2 r\u00fcckwirkungsfrei, wenn kein Fehler von Element 2 einen Fehler in Element 1 ausl\u00f6sen kann.<\/p>\n Es gibt drei Arten von Interferenzen:<\/p>\n Ausf\u00fchrungszeit<\/strong> Speicher Informationsaustausch<\/strong> Die hier vorgestellte Safety Checker Software hilft, Speicherinterferenzen zu erkennen. Das reduziert sowohl den Entwicklungsaufwand als auch den Bedarf einer Speicherschutzeinheit bei niedrigen Sicherheitsstufen:<\/p>\n Um Speicherinterferenzen zu erkennen, kann eine statische Analyse des Quellcodes mittels einer Software durchgef\u00fchrt werden. Der Code wird dabei nicht auf einer Zielhardware ausgef\u00fchrt. Das erlaubt eine schnelle Interferenzpr\u00fcfung nach Quellcode-\u00c4nderungen. Die Analyse beinhaltet eine Kontrolle aller m\u00f6glichen Programmabl\u00e4ufe, wodurch eine hohe Codeabdeckung gew\u00e4hrt wird. Dedizierte Testf\u00e4lle werden daher nicht ben\u00f6tigt. C++ Code sowie (Inline-) Assembler Code werden nicht \u00fcberpr\u00fcft.<\/p>\n Nachteil dieses Ansatzes ist, dass der Quellcode aller Dateien vorliegen muss, um die Analyse durchzuf\u00fchren. Das ist zum Schutze des geistigen Eigentums kein gangbarer Weg. Eine L\u00f6sung dieses Problems ist, die Analysedaten der einzelnen Dateien in einem verschl\u00fcsselten Format abzulegen. Diese Daten werden dann bei der Integration der Software benutzt.<\/p>\n Der Hardwareansatz \u00fcber die MPU erlaubt keine Differenzierung innerhalb einer SIL-Stufe. Der Softwareansatz bietet diese M\u00f6glichkeit. Es k\u00f6nnen beliebig viele Stufen definiert werden, also auch mehrere f\u00fcr eine SIL-Stufe:<\/p>\n <\/p>\n __SAFETY_CLASS_ATTRIBUTES__<\/p>\n {<\/p>\n \u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\/* Klassenname *\/<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { 0, „QM“ },<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { 1, „ASIL A“ },<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { 2, „ASIL B_1“ },<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { 3, „ASIL B_2“ },<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { 4, „ASIL C“ }<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { 5, „ASIL D“ }<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0 { 6, \u201eCOM_Buf_B1toA\u201c}<\/p>\n };<\/p>\n Anwendungsbeispiel: MCAL-Treiber. Diese d\u00fcrfen auf Konfigurationsdaten sowohl lesend als auch schreibend zugreifen. Andere ASIL B Funktionen d\u00fcrfen diese Konfigurationsdaten jedoch nur lesen.<\/p>\n __SAFETY_CLASS_ACCESS_RIGHTS__ MCAL-Funktionen und Konfigurationsdaten werden der Klasse ASIL_B_2 zugewiesen, die restlichen ASIL_B Funktionen und Daten der Klasse ASIL_B_1.<\/p>\n Die Zuweisung der Funktionen und Variablen zu den zuvor definierten Sicherheitsintegrit\u00e4tsstufen geschieht mittels einer Tabelle:<\/p>\n __SAFETY_CLASS_SELECTIONS__ Soll ein Adressbereich statt einer Variablen oder Funktion einer SIL-Stufe zugewiesen werden, so wird eine Startadresse, Gr\u00f6\u00dfe und die gew\u00fcnschte Sicherheitsstufe des Bereichs angegeben.<\/p>\n Nachdem die statische Analyse beendet wurde, werden Verletzungen der vorgegebenen Zugriffsregeln in einer Diagnosedatei angezeigt:<\/p>\n csaf E497: [„file_1.c“ 12] safety violation writing „x“ (ASIL B_2) from „f2“ (ASIL B_1)<\/span> Zur Dokumentation liegt ein Bericht vor, dessen inhaltlicher Detailgrad skalierbar ist. Dieser Bericht besteht aus<\/p>\n Zwei Anwendungsszenarien sollen im folgenden Abschnitt dargestellt werden:<\/p>\n Ein typisches Szenario ist, Softwareelemente mit niedrigen Sicherheitsanforderungen zusammen mit QM-Software zu integrieren, z.B. um Performance-Einbu\u00dfen bei einem Partitionswechsel, z.B. durch das Umschalten oder Reprogrammieren der MPU, zu sparen, Legacy Code wiederzuverwenden oder sich eine Speicherschutzeinheit auf dem Prozessor zu ersparen. Wie einleitend angef\u00fchrt muss nun eine Argumentation f\u00fcr die R\u00fcckwirkungsfreiheit geliefert werden. Dies kann durch eine „virtuelle“ Partitionierung im Safety Checker geschehen, indem in der Konfiguration unterschiedliche Partitionen f\u00fcr die zu integrierenden Software Elemente angelegt werden. Dabei bekommt der Safety Checker einen hohen Tool Confidence Level (TCL), da er direkt f\u00fcr die Sicherheitsargumentation benutzt wird.<\/p>\n Ein weiterer Anwendungsfall findet sich bei Systemen mit Speicherschutz. In den fr\u00fchen Projektphasen ist h\u00e4ufig der Speicherschutz deaktiviert, da zeitnah lauff\u00e4hige Funktionen gezeigt werden m\u00fcssen und am Brettaufbau keine Gefahr f\u00fcr Leib und Leben besteht. In dieser Phase achtet der Entwickler meist nicht auf eine saubere Partitionierung, da diese ja nicht kontrolliert wird. Soll in einer sp\u00e4teren Projektphase der Speicherschutz aktiviert werden, kann dies bis zur vier Wochen Entwicklungszeit kosten, da jeder falsche Speicherschutzzugriff zu einer Exception f\u00fchrt, die dann einzeln analysiert und korrigiert werden muss. Der Einsatz des Safety Checkers insbesondere in fr\u00fchen Projektphasen kann hier die Entwicklungszeit drastisch reduzieren und die Anwendung auf den Einsatz des Speicherschutzes vorbereiten. Da die Safety-Argumentation in diesem Szenario auf dem verf\u00fcgbaren Speicherschutz beruht, wird der TCL meist auf den Level 1 gesetzt und erfordert somit keine weiteren Aktivit\u00e4ten.<\/p>\n Die Integration des Safety Checkers in einer Make-Umgebung ist relativ einfach und kann vom AUTOSAR-Zulieferer vorbereitet werden. Der Aufruf des Safety Checkers erfolgt analog zu dem eines Compilers.<\/p>\n Die Erstellung des Konfigurationsfiles besitzt eine \u00e4hnliche Komplexit\u00e4t wie die eines Linkerscripts, allerdings lassen sich bei der Verwendung einer Systembeschreibung, wie sie z.B. bei AUTOSAR vorhanden ist, gro\u00dfe Teile generieren. So k\u00f6nnen z.B. die im Systemmodel hinterlegten Partitionen (OS Application) und das SW-C\/ Basic Software Mapping in der AUTOSAR RTE verwendet werden um die SAFETY_CLASS_ATTRIBUTES und die SAFETY_CLASS_SELECTIONS zu generieren.<\/p>\n Der Einsatz einer statischen Analysesoftware, um Speicherinterferenzen zu lokalisieren, reduziert den Entwicklungs- und Hardware-Testaufwand mittels einer MPU, da viele Zugriffsverletzungen bereits fr\u00fchzeitig in der Entwicklungsphase erkannt und behoben werden k\u00f6nnen. Durch einen hohen Integrationsgrad mit Betriebssystemen wie AUTOSAR und dem dazugeh\u00f6rigen Tooling l\u00e4sst sich der zus\u00e4tzliche Aufwand bedingt durch den Einsatz des Safety Checkers sehr stark reduzieren, da ben\u00f6tigte Informationen bereits hinterlegt sind. Die Wunschvorstellung eines Integrators ist der Knopf oder das make-target \u201emake safetycheck\u201c.<\/p>\n [1] Boehm, B. W. Understanding and controlling software costs. Journal of Parametrics 8, 32\u201368 (1988). Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Automotive\/ Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Automotive \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinf\u00fchrung<\/h2>\n
R\u00fcckwirkungsfreiheit (Freedom from Interference)<\/h2>\n
\nHierbei muss sichergestellt sein, dass eine sicherheitsrelevante Funktion nicht durch eine andere Funktion unterbrochen wird, wobei diese Unterbrechung dann dazu f\u00fchren kann, dass die sicherheitsrelevante Funktion nicht innerhalb des vorgegebenen Zeitrahmens bzw. Zeitintervalls ausgef\u00fchrt werden kann. Dieses wird \u00fcblicherweise mittels Hardware- und Software-Watchdogs, die Kontrollfluss-\u00dcberwachung und Deadline-\u00dcberwachung unterst\u00fctzen, gew\u00e4hrleistet. Das sind meist Bestandteile eines Echtzeitbetriebssystems.<\/p>\n
\n<\/strong>Eine Speicherinterferenz tritt auf, wenn Programmcode oder Programmdaten einer sicherheitsrelevanten Funktion durch andere Funktionen oder externe Fehler modifiziert werden. Speicherzugriffsverletzungen k\u00f6nnen durch eine Speicherschutzeinheit (MPU) erkannt werden.<\/p>\n
\nSt\u00f6rungen beim Informationsaustausch treten auf, wenn Nachrichten wiederholt werden oder verlorengehen bzw. deren Inhalt verf\u00e4lscht wird.<\/p>\n\n
Statische Analyse des Quellcodes als Alternative zur MPU<\/h2>\n
Differenzierung innerhalb einer Sicherheitsintegrit\u00e4tsstufe<\/h2>\n
\n{
\n\/* Quelle Ziel Zugriffsrechte *\/
\n{ ASIL_B_1, COM_Buf_B1toA, W },\/* ASIL B_1 Funktion darf in den Kommunikationspuffer zur ASIL A Partition schreiben *\/
\n{ ASIL_B_1, ASIL_A, R },\u00a0\u00a0\u00a0\u00a0 \/* ASIL B_1 Funktion darf ASIL A Daten
\nlesen *\/
\n{ ASIL_A, ASIL_B_2, X }, \u00a0\u00a0\u00a0\u00a0\/* ASIL A Funktion darf ASIL B_2
\nFunktion aufrufen *\/
\n{ ASIL_B_1, ASIL_B_2, R }, \u00a0\u00a0\/* ASIL B_1 Funktion darf ASIL B_2
\nDaten lesen *\/
\n{ ASIL_B_2, ASIL_B_1, R|W|X }\/* ASIL B_2 Funktion darf ASIL B_1 Funktionen aufrufen und hat Vollzugriff auf\u00a0 ASIL B_1 Daten *\/
\n};<\/p>\n
\n{
\n\/* Dateiname Name SIL *\/
\n\/* Alle Funktionen und Variablen aus Datei ‚file_1.c‘ beginnend mit ‚f‘ werden ASIL_B_1 zugewiesen *\/
\n{ „file_1.c“, „f*“, ASIL_B_1 },
\n\/* Die Variable mit dem Namen ‚x‘ wird ASIL_B_2 zugewiesen *\/
\n{ „file_1.c“, „x“, ASIL_B_2 },
\n\/* Alle Funktionen und Variablen aus Datei ‚file_2.c‘ werden ASIL_A zugewiesen, ‚file_2.c‘ beinhaltet Funktion ‚test‘ *\/
\n{ „file_2.c“, „*“, ASIL_A }
\n};<\/p>\n
\ncsaf E499: [„file_2.c“ 13] safety violation calling „f1“ (ASIL B_1) from „test“ (ASIL A)<\/span><\/p>\n\n
Praxisanwendung<\/h2>\n
\n
Integration des Safety Checkers<\/h2>\n
Schlussfolgerung<\/h2>\n
Literaturverzeichnis<\/h2>\n
\n[2] https:\/\/www.popsci.com\/software-rising-cause-car-recalls
\n[3] Software debugging, testing and verifcation by Hailpern and Santhanam, 2002 (https:\/\/www.cs.uleth.ca\/~benkoczi\/3720\/pres\/debug-test-verify_hailpern02.pdf)
\n[4] Tassey, G. The economic impacts of inadequate infrastructure for software testing. National Institute of Standards and Technology, RTI Project 7007, (2002).<\/p>\n
\nAutomotive – unsere Trainings & Coachings<\/h2>\n
\nAutomotive – Fachwissen<\/h2>\n