conplement AG Ihr Partner für
Embedded Software-Entwicklung
HMI, AUTOSAR, Bussysteme, Tools & alles andere – der Aufbau und die Weitergabe von Know how – das können wir!

Automotive-Embedded-Systeme für ISO 26262 fit machen

Facelift oder neues Modell?

Funktionale Sicherheit hat das Ziel, konzeptionelle Fehler zu vermeiden und beim Auftreten anderer Fehler das Erreichen eines sicheren Zustands zu garantieren. Seit 2011 ist sie in der ISO?26262 standardisiert. Doch was ist mit Systemen, bei denen Software aus Alt projekten übernommen werden muss?

Airbag-Steuerungen, ESP, aktive Hinterachslenkung, LEDScheinwerfer und Batteriemanagement bei Hybrid- und vollelektrischen Autos – all das sind Schlagwörter, die heute im Zusammenhang mit modernen Fahrzeugen fallen. Hinter diesen Begriffen verbirgt sich eine stetig steigende Anzahl an Funktionen von Fahrzeugsystemen, die in ECUs (Electronic Control Units; Steuergeräte) implementiert werden. Unter ihnen sind nicht nur "alte" Funktionen, bei denen die mechanische Regelung ersetzt wird, sondern auch neue, oft höchst innovative. Der adaptive Abstandstempomat ist so ein Beispiel, das erst durch den Einsatz von Mikroelektronik der ECUs möglich wurde. Die Abbildung 1 veranschaulicht, getrennt nach Hardware- und Softwareanteilen, die wachsenden Aufwendungen für ECUs.


Auto voller Software: Historie der wachsenden Aufwendungen für ECUs (Abb. 1)

Allein von 2000 bis 2010 haben sich die Entwicklungskosten für ECUs von 125 auf 270?Milliarden mehr als verdoppelt. Da ein Großteil der von unterschiedlichen Tier-1s stammenden Steuergeräte miteinander kommunizieren muss, ist, zusätzlich zu den Kosten, vor allem die zu beherrschende Komplexität bei der Entwicklung zuverlässiger und sicherer Fahrzeuge gestiegen. Um die Komplexität beherrschbar zu machen, arbeitet die Automobilbranche unter anderem an der Definition und dem Einsatz von AUTOSAR. Ob man mit dem Standard und funktionaler Sicherheit die Kernfragen zur Beherrschung der Kombination aus steigender Komplexität und Sicherheitsansprüchen beantworten kann, ist die eine Frage, weitere sind:

  • Sind damit alle Werkzeuge vorhanden, um die aktuellen Herausforderungen bei der Entwicklung von Steuergeräten zu lösen?
  • Wie sieht es mit Projekten aus, die vor dem Inkrafttreten der ISO?26262 im Jahr 2011 begonnen wurden, und was ist bei solchen Projekten zu beachten?
  • Welchen Einfluss hat AUTOSAR (Automotive Open System Architecture)? Ist es die "Silver Bullet" für diese Probleme?
  • Wie groß ist der Aufwand, diese Themen unter einen Hut zu bekommen? Um in der Begriffswelt der Automobilbranche zu bleiben: Reicht ein "Facelift", oder benötigt man gleich ein neues Modell?

Was ist funktionale Sicherheit?

"Funktionale Sicherheit ist derjenige Teil der Gesamtsicherheit, der von der korrekten Funktion des sicherheitsbezogenen Systems abhängt", heißt es in einem maßgeblichen Buch zur funktionalen Sicherheit?[1]. Die Sicherheit wird im Gefahrenfall durch das Erreichen eines sicheren Zustandes gewährleistet. Die Maßnahmen reichen vom Weiterbetrieb des betroffenen sicherheitsbezogenen Systems mit geringerer Funktionalität bis zur vollständigen Abschaltung des Systems.

Ein Beispiel: Moderne Automobile ohne Lenkkraftverstärkung sind kaum noch vorstellbar. Die Unterstützung des Fahrers erfolgt elektrisch oder hydraulisch. Der elektrische Motor einer Lenkkraftverstärkung steuert beispielsweise das Lenkgestänge fehlerhaft an. Es kommt also zu einer nicht korrekten Funktion eines sicherheitsbezogenen Systems, das zu einer Gefährdung führt. Der sichere Zustand ist, dass das Fahrzeug weiterhin lenkbar bleibt. Um das zu erreichen, wird die elektrische Unterstützung ausgeschaltet. Der mechanische Durchgriff über die Lenksäule gewährleistet die Lenkbarkeit des Fahrzeugs und damit den sicheren Zustand.

Doch durch welche Fehler wird eine nicht korrekte Funktion eines Systems ausgelöst? Auf der einen Seite ist es die Hardware, die aus vielen Elementen besteht (CPU, ADC, Flash usw.). Jedes einzelne Element kann unter bestimmten Umständen ausfallen. Auf der anderen Seite gibt es die Software beziehungsweise mehrere Softwarekomponenten, die viele Funktionen im Fahrzeug steuern. Der "Blue Screen" ist hier ein Synonym für fehlerhafte Software. In einem Fahrzeug kann die Auswirkung von Fehlern in der Software deutlich gravierender sein. Zu den Fehlern zählen nicht nur Software-Bugs, sondern auch konzeptionelle Fehler aus der Designphase. Unter diesem Gesichtspunkt kann man den Begriff funktionale Sicherheit allgemeiner fassen: Sie hat das Ziel, konzeptionelle Fehler zu vermeiden und beim Auftreten anderer Fehler das Erreichen eines sicheren Zustand zu garantieren. Wichtig ist es, Hardware und Software immer in Kombination zu betrachten.


Was zeichnet sichere Systeme aus?

Ein sicheres System ermöglicht das Erreichen eines sicheren Zustandes in allen erdenklichen Betriebszuständen – auch oder besonders, wenn ein Hardwaredefekt auftritt. Beispielsweise lässt sich die korrekte Funktion einer MCU (Microcontroller Unit) durch einen Sicherheitsrechner überwachen, und ein Ausfall des Microcontrollers bliebe nicht unbemerkt.

Ein weiterer Ansatzpunkt ist, mit zwei unterschiedlichen Methoden Messwerte eines Sensors zu erfassen und auszuwerten. Durch Vergleich der Ergebnisse der Messwertermittlung lässt sich überprüfen, ob die Berechnungen konzeptuell richtig waren. Beim Weiterverfolgen dieses Gedankens kommt man vermutlich auf die Idee, zwei unabhängige Sensoren zu verwenden und diese auch unabhängig voneinander auszuwerten. Diese Redundanz führt zu einer Sicherheit, die höher ist als die durch jeden einzelnen Sensor des Gesamtsystems erreichte Sicherheit für sich allein genommen. Diesen Umstand bezeichnet die 2011 eingeführte ISO 26262 auch als Dekomposition.

Sicherlich konnte etwas so Essenzielles, das die Gesundheit und sogar das (Über)Leben von Menschen gewährleistet, nicht schon vor der Einführung der ISO 26262 dem Zufall überlassen werden. Deshalb wurde bereits Anfang der 90er-Jahre die Norm DIN EN 61508 entwickelt, die sich mit dem Thema funktionale Sicherheit beschäftigt.

Diese DIN stellt die Grundnorm für alle Normen dar, die sich mit dem Thema funktionale Sicherheit beschäftigen. Die Abbildung 2 veranschaulicht die DIN EN 61508 und die aus ihr abgeleiteten Normen. Die abgeleitete ISO 26262 ersetzt die DIN 61508 im Automobilbau für Personenkraftwagen bis 3,5 Tonnen. Diese Erweiterung im Sinne einer Spezialisierung durch einen Wechsel der gültigen Normen hat für laufende Projekte, die vor Inkrafttreten der ISO 26262 begonnen wurden und erst danach abgeschlossen werden, einen großen Einfluss.


Sich von der DIN EN 61508 ableitende Normen (Abb. 2)

Zur Einleitung geeigneter Maßnahmen sind unterschiedliche Gefährdungspotenziale sicherheitsrelevanter Funktionen der Fahrzeugsysteme eindeutig zu klassifizieren. Hierfür wurden in der ISO 26262 der ASIL (Automotive Safety Integrity Level) eingeführt. Er reicht vom reinen Qualitätsmanagement (QM), über ASIL A bis ASIL D, wobei Letzteres den höchsten Sicherheitslevel darstellt.

Bei der ASIL-Festlegung wird neben der Häufigkeit des Auftretens des gefährlichen Zustandes (Exposure) und eines möglicherweise daraus resultierenden Schadens (Severity) die Kontrollierbarkeit (Controllability) durch den Fahrer betrachtet. Aus ihnen leitet man dann den ASIL ab (siehe Tabelle). Für die Lenkung kann eine Einstufung von ASIL B bis ASIL D erfolgen, was auf den ersten Blick verwirrend wirken mag. Eine Lenkung mit elektrischer Lenkkraftunterstützung wird als ASIL B eingestuft, wohingegen Drive-by-Wire dem höchsten Sicherheitslevel ASIL D genügen muss. Der geringere ASIL der Lenkung mit elektrischer oder hydraulischer Unterstützung ist begründet durch das Vorhandensein eines mechanischen Durchgriffs. Dieser existiert für Drive-by-Wire nicht mehr.

Neben der ISO?26262 wird die Entwicklung von ECUs durch andere Standards entscheidend beeinflusst. Wenn man über Software im Automobilbereich redet, kommt man um den Begriff AUTOSAR nicht herum. Vorhandene Steuergeräteplattformen basieren seit Längerem auf diesem Standard, und für neue Plattformen ist AUTOSAR meistens zwingend vorgegeben.


Wer oder was ist AUTOSAR?

Unter dem Kürzel arbeitet ein Konsortium weltweit führender Automobilhersteller, Tier-1s und Tool-Hersteller seit 2003 an der Standardisierung von Software für Steuergeräte im Automobil. Dabei definiert das Konsortium eine speziell an die Bedürfnisse der Automobilbranche angepasste Softwarearchitektur sowie ein breites Spektrum an Softwaremodulen hinsichtlich deren Funktionalität und Interfaces. Noch nicht vom Standard abgedeckte Funktionen in der Basissoftware lassen sich vom Steuergeräteentwickler über sogenannte Complex Device Driver als Basissoftwarekomponente (BSW) implementieren und einbinden. Die Applikation, die aus funktional zusammengefassten Softwarekomponenten (SWCs) besteht, ist über die Runtime Environment (RTE) an die BSWs angebunden.

Mit der Standardisierung liefert das Konsortium eine Antwort auf die stetig steigende Komplexität der Software im Auto. Dadurch dass sämtliche Schnittstellen spezifiziert sind, bietet AUTOSAR zudem die Möglichkeit, BSWs sowie SWCs beliebiger Zulieferer auf einem Steuergerät einzusetzen. Schließlich soll durch den Einsatz von AUTOSAR-Komponenten die Entwicklungszeit für Steuergeräte verkürzt werden, während gleichzeitig die Zuverlässigkeit des Codes steigt. Zunehmend mehr OEMs erkennen mittlerweile die Vorteile von AUTOSAR, sodass mehr und mehr Steuergeräte nach diesem Standard entwickelt werden.

Seit dem Release 4.0 (2009) spezifiziert AUTOSAR Lösungsansätze für ein Konzept, das für die funktionale Sicherheit einige Mechanismen zur Absicherung sicherheitskritischer Software bietet. Die Mechanismen unterstützen den Steuergeräteentwickler beim Erreichen der für das Steuergerät geltenden Sicherheitsanforderungen. Einige der interessantesten sind:

  1. Program Flow Control (PFC) – jeder kommt dran: Darunter versteht man die Überwachung der korrekten Ausführung speziell abzusichernder Softwareanteile im Steuergerät. Der Mechanismus überprüft, ob sicherheitskritische Softwareanteile vollständig und in korrekter Reihenfolge ausgeführt werden. Ohne diese Überwachung ist die Konsistenz der Daten, aufgrund derer sicherheitsrelevanter Code Entscheidungen trifft, nicht gewährleistet, oder aber – noch schlimmer – es würde nicht erkannt werden, wenn wichtige Entscheidungen nicht getroffen würden. Entscheidungen werden stets aufgrund bestimmter Eingangswerte getroffen. Zur Verdeutlichung sei angenommen, dass die Eingangswerte aus einem Sensor ausgelesen und anschließend im sicherheitskritischen Code als Basis wichtiger Entscheidungen verwendet werden. Der PFC-Mechanismus überwacht hierbei, dass alle nötigen Eingangswerte eingelesen wurden, bevor eine Entscheidung im Code getroffen wird. Zudem wird überwacht, dass anschließend eine Entscheidung getroffen wurde.
  2. Laufzeitüberwachung – alles zu seiner Zeit: Systeme, die im sicherheitskritischen Bereich arbeiten, haben höchste Anforderungen an ihre Echtzeitfähigkeit. Das bedeutet, vom System ist sicherzustellen, dass auf ein Ereignis innerhalb einer garantierten Laufzeit eine erwartete Reaktion erfolgt sein muss. Ohne eine garantierte Reaktionszeit kann ein System nie dem Anspruch funktionaler Sicherheit genügen. Selbst wenn sämtliche Sicherheitsmechanismen implementiert wären, könnte ein System ohne Laufzeitüberwachung keine zuverlässigen Schutzmechanismen bieten. Daher definiert man für eine sicherheitskritische Funktion deren maximale Laufzeit und überwacht diese über einen Hardware-Timer. Stellt man eine Verletzung der maximal zulässigen Laufzeit fest, ist das System in einen sicheren Zustand zu überführen. Das lässt sich über verschiedene Mechanismen wie der Beendigung der aktuell laufenden Task bis zum Reset durch einen hardware - basierten Watchdog umsetzen.
  3. Kommunikationsabsicherung und End-to-End Protection – Sicherheit garantiert: Aufgabe jedes Steuergeräts ist es, Daten zu sammeln, zu verarbeiten, weiterzuleiten oder aber aus den gesammelten Daten Aktionen abzuleiten. Wer schon einmal stille Post gespielt hat, wird am eigenen Leib erfahren haben, was bei einer "Datenübertragung" alles passieren kann. Um aber im datenverarbeitenden Softwaremodul sicher zu sein, dass man gültige Daten empfangen hat, werden diese mit Absicherungsmechanismen wie CRC16-Checksumme oder einem PDU Counter, der bei jeder neuen Botschaft inkrementiert wird, abgesichert. Über diese Mechanismen erhält das Modul Informationen über Gültigkeit, Datenverlust oder Mehrfachempfang von Nachrichten und kann entsprechend reagieren.
  4. Memory Management – wer darf was? Der Abschnitt zur funktionalen Sicherheit erwähnte, dass man Funktionen auf einem Steuergerät abhängig von den Parametern (E)xposure, (C)ontrollability und (S)everity bestimmten ASILs zuweist. Das bedeutet, dass Funktionen unterschiedlich strenge Anforderungen bezüglich ihrer Absicherung haben können. Diese greifen jedoch im Falle eines Single-Core-Microcontrollers im Normalfall auf gemeinsam genutzte Ressourcen wie RAM- oder ROM-Zellen zu. ASIL- und QM-Code wird somit auf gemeinsamen Speichermedien des Systems ausgeführt. Hier sei angenommen, dass QM-Code beliebig Daten im gemeinsam genutzten RAM manipulieren kann. Eine ASILFunktion kann auf die vom QM-Code beschriebene RAMZelle zugreifen und arbeitet damit auf Daten, die nur mit QM abgesichert sind. Die Funktion wäre damit nicht länger nach dem geforderten ASIL abgesichert. Ein anderes Problem kann dadurch entstehen, dass ASIL-Code Funktionen im QM-Code ausführt, um etwa Berechnungen durchzuführen. Auch dann wäre die Funktion nicht mehr mit dem geforderten ASIL konform. Deswegen bedient man sich mit der MPU oder MMU (Memory Protection Unit/Memory Management Unit) eines hardwarebasierten Speicherzugriffsschutzmechanismus. Mit ihnen lassen sich während der Laufzeit rwx-Rechte (read/write/ execute) für RAM- und ROM-Bereiche setzen. Um diesen Mechanismus nutzen zu können, werden zunächst ROM- und RAM-Speicher partitioniert. Die Anzahl der Partitionen entspricht mindestens der Anzahl der umzusetzenden Sicherheitslevel. Anschließend werden die Funktionen entsprechend ihres ASILs auf die Partitionen verteilt. AUTOSAR-Module ermöglichen, die Zugriffsberechtigungen auf die Partitionen in der MPU/MMU entsprechend dem Sicherheitslevel der derzeit laufenden Funktionen zu setzen und damit einen der oben genannten unerlaubten Zugriffe zu verhindern. Das Prinzip der Speicherzugriffsüberwachung bezeichnet der AUTOSAR- Standard als "freedom from interference".

Die hier genannten Mechanismen unterstützen den Softwareentwickler bei der Umsetzung der für das Steuergerät geltenden Sicherheitsanforderungen. Es ist jedoch ein Trugschluss davon auszugehen, man hätte allein durch die Verwendung von AUTOSAR bereits ein sicheres System. Es bedarf einer genauen Gefahrenanalyse und einer exakten Definition aller Maßnahmen, um Funktionen tatsächlich sicher zu machen. Nur sinnvoll und an den richtigen Stellen eingesetzt, können die oben beschriebenen Mechanismen greifen und für Sicherheit sorgen.


Die Realität: Probleme bei Altprojekten

Die Nutzung der beschriebenen AUTOSAR-Prinzipien zur Absicherung sicherheitskritischer Software ist nicht immer möglich. Das kann bei Projekten der Fall sein, die noch nach einem alten AUTOSAR-Standard (z.?B. Version?3.1) begonnen wurden und nach dem alten Standard weiterzuführen sind oder bei denen bewährte Softwarekomponenten wiederverwendet werden sollen. Die ISO 26262 sieht zwar über das "proven in use"- Argument (in Teil 8, Klausel 14) vor, diese Softwarekomponenten zu nutzen, aber dazu sind Felderfahrung und Änderungen hinsichtlich der vorgesehenen Nutzung zu betrachten.

Im Folgenden sei ein theoretisches Beispiel für eine Softwarekomponente entwickelt, bei der im laufenden Projekt umfangreiche Änderungen (Nutzungsänderung) durchgeführt wurden, sodass sich das "proven in use"-Argument nicht mehr anwenden lässt: ein Steuergerät für den Frontscheinwerfer, bestehend aus LED-Tagfahrlicht und Halogen-Abblendlicht. In diesem Steuergerät soll nun das konventionelle Abblendlicht durch LEDs ersetzt werden. Hierfür sollen die Softwaremodule des LED-Tagfahrlichts teilweise für das neue LED-Abblendlicht übernommen werden.

Das LED-Abblendlicht ist im Gegensatz zum LED-Tagfahrlicht nun nach ASIL C zu überwachen. Also ist eine Softwarekomponente, die ASIL C erfordert, in eine Codebasis einzufügen, die ASIL C nicht genügt. Hierfür wird die Dekomposition nach ISO 26262 verwendet. Die vorhandene Codebasis lässt sich als QM weiternutzen. Es ist zusätzlich eine Funktion zur Überwachung der LEDs für das Abblendlicht notwendig, die prüft, ob die LEDs auch leuchten. Für die LEDs des Tagfahrlichts war das nicht notwendig. Diese Leuchtdiodenüberwachung bestehend aus Photodiode und den bereits vorhandenen Shunts zur Stromüberwachung als Eingangssensoren ist – auf ASIL C implementiert – zu integrieren und zu validieren.

Folgende Punkte sind bei der bevorstehenden Integration von ASIL C zu beachten: Die Gültigkeit der zur Leuchtdiodenüberwachung benötigten Sensordaten sind über einen E2E-Mechanismus (End-to-End Protection) sicherzustellen. Um die Sicherheit der Funktion zu garantieren, ist die erwähnte "freedom from interference" zu gewährleisten. Über MPU und eventuell MMU sind die nach ASIL C funktionsrelevanten Daten vor unbefugten QM-Zugriffen zu schützen. Ebenso ist eine Laufzeitüberwachung zur Kontrolle der korrekten Kadenz der Aufrufe und der Einhaltung der maximalen Laufzeit zu realisieren. Für die Konfiguration der MPU, die regelmäßigen Aufrufe und die Einhaltung der maximalen Laufzeit zeichnet das Betriebssystem verantwortlich. Es gehört allerdings beim Beispiel zum vorhandenen Code, der nicht nach ASIL C oder ASIL D zertifiziert ist, und gehört somit zum QM-Anteil. Die Herausforderung liegt nun darin, in die Software, die ein Betriebssystem auf QM-Niveau besitzt, die ASIL-C-Funktion "Leuchtdiodenüberwachung" zu integrieren. Zur Umsetzung sind sowohl Softwareanpassungen als auch Änderungen an der Konfiguration der MCU notwendig.

Die Umsetzung der Anforderungen für die im Beispiel notwendigen Sensoren (Photodiode und Shunt) werden wie folgt umgesetzt: Das Einlesen und die Verarbeitung der Sensorsignale muss nach ASIL C erfolgen. Zunächst ist sicherzustellen, dass die von den Sensoren gelieferten Rohwerte unverändert verarbeitenden Softwarekomponente gelangen. Der Signalweg muss durchgängig ASIL C genügen, sodass hier nicht der Standardweg über die lediglich mit QM abgesicherten Layer wie der RTE als Schnittstelle gewählt werden darf. Zusätzlich werden die Rohwerte im MCAL (Microcontroller Abstraction Layer) über eine E2E-Bibliothek mit einer Checksumme und einem PDU Counter versehen. Die E2E-Library überprüft in der verarbeitenden Softwarekomponente das Datenpaket und gewährleistet damit die Datenkonsistenz.


Softwarearchitektur à la AUTOSAR (Abb. 3)


Exemplarischer Lösungsansatz OS/Memory Management

Nach Gewährleistung der Konsistenz der Sensordaten ist zu überprüfen, ob auch die übrigen Aktionen, die als Vorbedingungen zur Entscheidungsfindung nötig sind, bereits durchgeführt wurden. Dazu wird ein PFC-Mechanismus implementiert, der sicherstellt, dass die übrigen an der Entscheidung beteiligten Eingangswerte (z. B. Board-Spannung und Systemzustand) eingelesen und aktuell sind, bevor die Verarbeitung der Daten startet. Eine Umsetzung des PFC-Mechanismus wäre etwa die Befüllung eines Bitfeldes, dessen Bits jeweils für einen Eingangswert oder eine im Vorfeld auszuführende Aktion gesetzt werden. Nur wenn alle geforderten Bits auf "1" stehen, kann die Softwarekomponente mit der Verarbeitung der Signale beginnen und anschließend das Bitfeld für den nächsten Durchlauf neu initialisieren (Nullen).

Des Weiteren sind die Laufzeit und die Zykluszeit zu messen, mit der die Softwarekomponente die sicherheitskritischen Entscheidungen trifft. Im Systemdesign wurden die maximale Laufzeit und die maximale Zykluszeit festgelegt. Wird eine der beiden Grenzen verletzt, führt das unverzüglich zum Neustart des Systems. Das wird im Beispiel mit zwei Timer Overflow Interrupts implementiert.

Entsprechend der Vorgehensweise aus "Memory Management – wer darf was" wird für die ASIL-C-Softwarekomponente eine eigene RAM- und ROM-Speicherpartition definiert. Durch die Konfiguration der rwx-Rechte über die MPU/MMU vor und nach Ausführung der ASIL-C-Funktion wird verhindert, dass QM-Code die mit ASIL C abzusichernde Funktion beeinflusst. Es wird zudem eine eigene Task erstellt, in der einzig die neue Funktion komplett abgearbeitet wird. Bei der Partitionskonfiguration des RAM ist insbesondere darauf zu achten, dass sowohl der RAM-Bereich mit ASIL-C-relevanten globalen Variablen als auch der Task-Stack des Betriebssystems, auf dem etwaige Rücksprungadressen oder lokale Variablen abgelegt werden, in die Partition mit aufzunehmen sind. Alle Interrupts, die auf QM-Ebene laufen, darunter auch die Timer Interrupts für den Scheduler des Betriebssystems, sind während der Ausführung des ASIL-C-Codes abzuschalten. Das blockiert die Ausführung aller Interrupts, die lediglich mit QM abgesichert sind.

Um die Sicherheit des Systems nachzuweisen, müssen Tests im laufenden System sicherstellen, dass die implementierten Sicherheitsmechanismen im Fehlerfall wirksam werden. Die Voraussetzungen für die Tests sind zum Teil bereits bei der Implementierung einzurichten. Will man beispielsweise eine Speicherzugriffsverletzung testen, muss man diese von "außen" provozieren können. Wer den Test als Blackbox-Test ausführen will, muss sich eine Möglichkeit schaffen, den Fehlerfall beispielsweise über einen Diagnoseservice oder aber über XCP (eXtended Calibration Protocol) anzustoßen.


Fazit

Zusammenfassend lässt sich sagen, dass trotz oder gerade wegen der Tools, die zum Beispiel durch Softwaregenerierung die Umsetzung von AUTOSAR erleichtern oder erst ermöglichen, das Zusammenspiel alter Softwarekomponenten mit AUTOSAR und ISO 26262 eine ingenieurwissenschaftliche Leistung für sich darstellt und damit der jeweilige Einzelfall zu betrachten ist. Das wird dadurch verstärkt, dass die ISO 26262 erst seit 2011 verfügbar ist und sich deshalb Schwierigkeiten bei der Übernahme von Software aus Altprojekten ergeben. Der exemplarische Lösungsansatz in diesem Artikel hat aufgezeigt, dass es speziell für diese Herausforderung wenige oder keine Lösungen von der Stange gibt.

Für den oben beschriebenen Fall, in dem ein komplett neues Modell basierend auf einem mit ASIL C zertifizierten Grundsystem wegen zu hoher Kosten oder zu hohem Aufwand nicht einsetzbar ist, ist "nur" ein einfaches Facelift mit dem Ziel, die Sicherheitsanforderungen abzudecken, nicht möglich. Es ist eine konzeptuell sorgfältig ausgedachte Lösung notwendig, die vom Entwicklungsaufwand und von den Kosten her zwischen Facelift und neuem Modell liegen wird.


Literatur
[1] Peter Löw, Roland Pabst, Erwin Petry; Funktionale Sicherheit in der Praxis; Anwendung von DIN EN 61508 und ISO/DIS 26262 bei der Entwicklung von Serienprodukten; dpunkt.verlag 2010, S. 6

english
Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Datenschutzerklärung
OK