Sicherheit und Leistung durch ASIL-D

© Vector Informatik GmbH
SAFETY & SECURITY
Sicherheit und Leistung
durch ASIL-D-AUTOSARBasissoftware
In Steuergeräten, die nach ISO 26262 entwickelt werden, kommt häufig sicherheitsrelevante und nicht-sicherheitsrelevante Software parallel zum Einsatz. Damit diese
sich gegenseitig nicht stören, wird bisher mit Partitionierungsmaßnahmen für einen
rückwirkungsfreien Ablauf der Software gesorgt. Diese Partitionierung führt allerdings oftmals zu Laufzeit-Einbußen und erhöhter Komplexität. Mit einer komplett
nach ISO 26262 entwickelten AUTOSAR-Basissoftware lässt sich die Anzahl der
Partitionen minimieren. Ein Erfahrungsbericht von Vector Informatik.
D
er Anteil von in Software umgesetzten sicherheitsrelevanten Funktionen wächst stetig. Dadurch ergibt sich
auch eine häufigere Interaktion zwischen sicherheits
relevanter Applikationssoftware und AUTOSAR-Basissoftware. Wenn beide in unterschiedlichen Partitionen liegen,
kostet diese Interaktion Rechenzeit, da mindestens die aktive
Task gewechselt und je nach Hardware-Plattform aufwendig
16
HANSER automotive 7-8 / 2016
die Memory Protection Unit (MPU) umprogrammiert werden
muss. Mit einer nach den Anforderungen für ASIL D entwickelten Basissoftware ist dessen Koexistenz mit sicherheitsrelevanter Applikationssoftware in einer Partition möglich.
Dadurch lässt sich ein enormer Leistungsgewinn erzielen, da
auf Task-Umschaltung, Umprogrammierung der MPU und zusätzliches Kopieren von Daten verzichtet werden kann. Darü© Carl Hanser Verlag, München
SAFETY & SECURITY
ber hinaus können weitere Sicherheitsanforderungen in der
Basissoftware implementiert werden, ohne dass diese individuell für jedes Steuergerät entwickelt werden müssen. Bild 1
stellt die beiden Ansätze grafisch gegenüber.
Hintergrund
Die ISO 26262 definiert das Automotive Safety Integrity
Level (ASIL) immer als Attribut einer in Software implementierten Funktion. Es gibt die Güte an, mit der die Funktion umgesetzt werden soll. Das ASIL wird über den Weg von der
Gefahren- und Risikoanalyse über Sicherheitsziele und das
funktionale und technische Sicherheitskonzept bis zu den sicherheitsrelevanten Softwareanforderungen abgeleitet. Sobald eine Softwarekomponente eine sicherheitsrelevante Anforderung umsetzt, sind für deren Entwicklung die Methoden
aus Band 6 der ISO 26262 mit dem entsprechenden ASIL anzuwenden (Bild 2). Bekannte Beispiele von Funktionen in der
Basissoftware, die sich so aus dem Sicherheitskonzept ableiten, sind der Speicherschutz durch das Betriebssystem, die
zeitliche Überwachung durch den Watchdog-Stack und die
Absicherung der Kommunikation mithilfe der End-to-End
(E2E)-Protection, wie in der AUTOSAR-Spezifikation [1] beschrieben.
rung verletzen. Insbesondere Rückwirkungen auf sicherheitsrelevante Daten und auf die sicherheitsrelevante zeitliche Ausführung der Software sind möglich. Diese potenziellen Gefährdungen durch Rückwirkungen gilt es zu vermeiden. Als eine Lösung bietet die ISO 26262 [2] die Möglichkeit,
auch für Software-Teile ohne sicherheitsrelevante Funktion
dieselben Methoden wie für eine sicherheitsrelevante Funktion anzuwenden. Diese Software-Teile gelten dann als hinreichend rückwirkungsfrei.
Konsequenzen für die Entwicklung
Als Folge dieser Argumentation muss für die betroffene Software unter anderem ein ausführliches semi-formales Design
erstellt werden. Hierzu ist im Allgemeinen ein großer Hub in
der Entwicklung notwendig, um den Ansprüchen für ASIL D
gerecht zu werden. Dieser Aufwand verblasst jedoch vor den
Aufwänden für den Test der Software.
Aus ISO 26262 Band 6 Tabelle 4 lässt sich die Forderung
nach einer diversitären Implementierung von Algorithmen als
Ergebnis der Software-Sicherheitsanalyse ableiten. Dabei
wird ein Algorithmus mit zwei unterschiedlichen Implementierungen umgesetzt, um bestimmte systematische Fehler
zu verhindern. Um auf eine diversitäre Implementierung verzichten zu können, baut
Vector auf eine sehr gute
Testbarkeit seiner Komponenten. Diese lässt sich
durch eine geringe zyklomatische Komplexität der
getesteten Software-Teile
belegen. Die zyklomatische Komplexität ist ein
Maß für die Pfade im Kontrollflussgraphen
einer
Funktion. Um die hohen
Anforderungen an die
Testbarkeit der Komponenten zu erreichen, war
bei vielen Komponenten
eine Refaktorierung, also
Bild 1: Unterschiedliche Partitionierungskonzepte mit QM- und ASIL-Basissoftware.
eine Strukturverbesserung
(© Vector Informatik GmbH)
des Quellcodes, notwendig. Diese wurde gleichzeiDie Nutzung der AUTOSAR-E2E-Protection ist Stand der tig genutzt, um auch die defensive Programmierung, also die
Technik zur Absicherung von sicherheitsrelevanten Signalen. Erhöhung der Robustheit durch zusätzliche Überprüfungen,
Da sich mit ihrer Hilfe alle relevanten Fehlerfälle entdecken und die Modularisierung innerhalb der Komponenten zu verlassen, werden keine Sicherheitsanforderungen an die Kom- bessern.
munikationskomponenten der Basissoftware gestellt. Um
AUTOSAR-Basissoftware ist extrem konfigurierbar. Dieauf eine Partitionierung zwischen E2E-Protection und Kom- se Konfigurierbarkeit behandelt die ISO 26262 nur teilweise.
munikationskomponenten verzichten zu können, müssen für Insbesondere im Bereich des Unit-Tests geht die ISO 26262
deren Entwicklung auch die Methoden aus Band 6 der implizit nur von einer möglichen Code-Variante aus. Um BaISO 26262 angewendet werden. Denn es wird angenom- sissoftware als Safety Element out of Context (SEooC) [3] in
men, dass Software mit niedrigerem ASIL einen höheren An- verschiedensten Konfigurationen einsetzbar zu machen,
teil an systematischen Fehlern beinhaltet als nach einem hö- muss ein Ansatz gefunden werden, der diese Konfigurierbarheren ASIL entwickelte Software. Diese Fehler können als keit abdeckt. Die Konfigurierbarkeit bildet sich zum Teil in Präkaskadierende Fehler die sicherheitsrelevante Software be- prozessor-Bedingungen ab. Mögliche Konfigurationen wereinflussen und damit die zugeordnete Sicherheitsanforde- den daher von Vector auf Basis von Anwendungsfällen und
www.hanser-automotive.de
HANSER automotive 7-8 / 2016
17
»
SAFETY & SECURITY
heitsrelevanten Teilen der Basissoftware auf sicherheitsrelevante Teile sichergestellt.
Sicherheitskonzept
Bild 2: Entwicklung von Softwarekomponenten nach ASIL
aufgrund von Sicherheitsanforderungen oder wegen der
gewünschten Koexistenz.
(© Vector Informatik GmbH)
Abhängigkeiten zwischen Konfigurationsparametern hergeleitet. Analog zum Testende-Kriterium für Laufzeittests [4]
hat Vector für Präprozessor-Bedingungen denselben Maßstab in seinem Entwicklungsprozess angelegt. Darüber hinaus ist bei Vector in der Komponentenentwicklung ein weiteres Testende-Kriterium definiert: Es muss eine vollständige
Code-Coverage zur Laufzeit in allen Konfigurationsvarianten,
die zur Erfüllung der Präprozessor-Coverage notwendig sind,
erreicht werden.
Die statische Code-Analyse ist ein wichtiger Bestandteil
des Prozesses, da sich hierdurch bestimmte Fehlerarten, wie
Speicherüberschreiber, wesentlich besser finden lassen als
im funktionalen Test. Dafür entwickelte Vector speziell für
den Kontext konfigurierbarer Software eine statische CodeAnalyse zur Erkennung von out-of-bounds-Zugriffen und ungültigen Zeigern. Aufgrund der Variantenvielfalt der Basissoftware gehört dazu auch eine automatisierte Prüfung der generierten Konfigurationen, die der Anwender selbst durchführt.
Dadurch ist auch die Rückwirkungsfreiheit von nicht sicher-
18
HANSER automotive 7-8 / 2016
Dieser sicherheitsgerichtete Entwicklungsprozess erlaubt
nun einfacher, neue Sicherheitsanforderungen für die SEooCBasissoftware anzunehmen, da bereits fast alle Vorgaben
hierfür aus der ISO 26262 erfüllt werden. Als zusätzliche Sicherheitsanforderungen an die Basissoftware hat Vector die
Erkennung von Verlust, Korruption und Maskierung von Daten im nicht flüchtigen Speicher (non-volatile memory) formuliert – ausgelöst durch die unteren Schichten der Basissoftware oder die Hardware. Auch den Neustart einer SoftwareApplikation und die AUTOSAR Timing Protection kann zukünftig als Sicherheitsmechanismus genutzt werden. Um ein
Steuergerät bei der Initialisierung in einen definierten Zustand zu bringen, hat Vector hierfür Sicherheitsanforderungen angenommen. Die Sicherheitsanforderungen, die für die
Partitionierung benötigt werden, sind oft weiterhin notwendig. So muss zum Beispiel häufig bestehende QM-Software
integriert werden, für die eine Kosten-Nutzen-Abschätzung
ergeben hat, dass eine Neuentwicklung oder Nachqualifizierung nicht sinnvoll ist.
Angenommene Sicherheitsanforderungen müssen genau
analysiert und die zugrunde liegenden Annahmen kommuniziert werden, bevor diese Anforderungen in einem Sicherheitskonzept eines Steuergeräteprojekts genutzt werden
können. Dies bedeutet, dass ausschließlich Funktionen, die
Teil der angenommenen Sicherheitsanforderungen sind, im
projekt-spezifischen Sicherheitskonzept genutzt werden dürfen. Beispielsweise ist deshalb die E2E Protection notwendig
um sicherheitsrelevante Daten zu übertragen, da die Kommunikationskomponenten zwar nach den Methoden der
ISO 26262 entwickelt, aber keine Sicherheitsanforderungen
dafür durch Vector angenommen sind. Eine Liste der angenommenen Sicherheitsanforderungen sollte daher bereits in
einer sehr frühen Phase eines Projektes verfügbar sein.
Nutzung
Nachdem der Anwender der Basissoftware die angenommenen Sicherheitsanforderungen mit dem Projektkontext abgeglichen hat, führt er mithilfe des mitgelieferten Safety Manual
eine Konfiguration und Integration der Basissoftware durch.
Ein Unit-Test für die Basissoftware erfolgt normalerweise bereits durch den Lieferanten. Der Integrations- und Verifikationsschritt, wie in der ISO 26262 beschrieben [5], muss jedoch durch den Nutzer erfolgen. Der Basissoftware-Lieferant
kann auf diesen Ebenen keinen Beitrag zum Sicherheitsnachweis leisten, da ihm während der Entwicklung der Basissoftware Informationen zur Konfiguration, Applikation und der exakte Zielumgebung fehlen.
Eine Bestätigung über die Einhaltung des ISO-26262-konformen Entwicklungsprozesses erhält der Nutzer durch den
Safety Case für die Basissoftware. Der Nutzer referenziert
diesen Safety Case in seinem Sicherheitsnachweis. Der Safety Case wird unter anderem auf Basis der vom Nutzer ein© Carl Hanser Verlag, München
SAFETY & SECURITY
Bild 3: Aktuelle Übersicht der nach ASIL D entwickelten Komponenten der AUTOSAR 4 Basissoftware.
gereichten Konfiguration ausgestellt. Die Konfiguration bei
Vector zu prüfen ist notwendig, um den Komponententest zu
validieren. Es werden nicht alle möglichen Kombinationen
von Konfigurationsparametern während der Entwicklung getestet. Um trotzdem sicher zu sein, dass auch exotische Konfigurationen getestet wurden, bleibt nur eine projektspezifische Prüfung.
Die Wirksamkeit dieses Ansatzes ist exemplarisch durch
ein Zertifizierungs-Unternehmen (exida) in einem unabhängigen Assessment bestätigt. Dabei wurden das Betriebssystem und die Komponenten für CAN-, LIN- und FlexRay-Kommunikation als auch die Komponenten im System- und Memory-Cluster evaluiert. Bild 3 zeigt eine aktuelle Übersicht
der nach ASIL D entwickelten Komponenten.
Ausblick
Der vorgestellte Ansatz zeigt, wie mit einer ASIL D Basissoftware die Anzahl der Partitionen verringert sowie Laufzeiten
reduziert werden können. Die Komplexität in einem Steuergeräteprojekt sinkt, weil Sicherheitsmechanismen nicht extra
implementiert werden müssen, sondern in der Basissoftware bereits enthalten sind.
Ziel von Vector ist es weitere AUTOSAR-4-Basissoftware-Komponenten nach dem neuen sicherheitsgerichteten
Prozess zu entwickeln und damit für möglichst viele Anwendungsfälle eine optimale Lösung anzubieten. Besondere Herausforderungen in der nächsten Zeit sind die AUTOSARKomponenten, die aktuell noch viele Änderungen erfahren.
www.hanser-automotive.de
(© Vector Informatik GmbH)
Ebenso stellen durch OEMs beigestellte Erweiterungen und
Hardware-Treiber der verschiedenen Halbleiterhersteller eine
Herausforderung dar. Sie stehen standardmäßig noch nicht
mit der notwendigen Qualität zur Verfügung und sind daher
nur mit erhöhtem Aufwand und Leistungseinbußen zusammen mit einer sicheren Basissoftware einsetzbar. In einem
weiteren Schritt arbeiten Vector und exida an der Umsetzung
einer RTE, die sich ohne aufwendige Qualifizierungsmaßnahmen im Kontext von sicherheitsrelevanter Software einsetzen lässt. W (oe)
»» www.vector.com
Literaturhinweise:
[1] AUTOS AR Specification of SW-C End-to-End
Communication Protection Library.
[2] ISO 26262, Band 9, Abschnitt 6.
[3] ISO 26262, Band 10, Abschnitt 9.
[4] ISO 26262, Band 6, Tabelle 12.
[5] ISO 26262, Band 6, Abschnitte 10 und 11.
Dipl.-Ing. Jonas Wolf ist seit 2012 bei Vector und jetzt
als Senior Product Management Engineer für Funktionale
Sicherheit tätig.
Peter Müller arbeitete 10 Jahre beim TÜV Süd im Bereich
der Funktionalen Sicherheit. Im Jahr 2002 wechselte er zu
exida. Seit 2007 ist er bei exida Lead Assessor für Zertifizierungen im Automations- und Automobil-Bereich.
HANSER automotive 7-8 / 2016
19

Download Report