Automotive
Embedded
Software

Beratung
Entwicklung
Functional Safety
Cybersecurity

Autonome Systeme - aber sicher

Autonome Systeme sind eine große Herausforderung für die Automobilindustrie. Neben den benötigten Funktionen (die großenteils bereits implementiert sind), gilt es, die Sicherheit der Systeme unter allen (un-)denkbaren Umständen zu gewährleisten, damit durch verringerte Unfallzahlen die Systeme breite gesellschaftliche Akzeptanz bekommen.

In der recht neuen Norm SOTIF wurden für Level 1 und 2 der 6 Automatisierungsstufen bereits weitreichende Regeln definiert. Aber für Level 3 und 4 werden weitere benötigt. Unter Federführung von Daimler haben Fahrzeughersteller und Zulieferer eine Studie durchgeführt und deren Ergebnisse in dem Whitepaper Safety First for Automated Driving (SaFAD) veröffentlicht.

Welche zusätzlichen Anforderungen für die Systementwicklung definiert wurden, weiß Dipl.-Inform. Marc Ruppert. Er arbeitet als Berater bei der F+S Fleckner und Simon Informationstechnik GmbH.

Herr Ruppert, wenn die funktionalen Probleme gelöst sind, wieso sind dann die Systeme nicht sicher?

Dipl.-Inform. Marc Ruppert: Funktional heißt, dass das System einen Algorithmus hat, der funktioniert. Nehmen Sie die Schildererkennung: Wir haben Algorithmen, die ein Schild erkennen und seine Bedeutung verstehen. Funktionale Herausforderungen sind nun, alle Schilder auf der Welt zu kennen, auch alte, ehemals gültige, auch die Warnung vor Kängurus in Australien oder vor Elchen in Schweden. Inklusive der Bedeutung, also welche Gefahr droht und wie man (bzw. das Fahrzeug) sich verhalten soll.

Sicher heißt aber, dass jedes Schild jederzeit erkannt wird, zumindest mit der Qualität eines menschlichen Fahrers. Auch wenn es teilweise von Sträuchern verdeckt wird, ausgebleicht oder verwittert ist, selbst ein von Schnee bedecktes Stoppschild.

Aber ist die Erkennung eines verwitterten Schildes nicht auch eine funktionale Herausforderung?

Ruppert: Teilweise schon. Wenn ich die Anforderungen kenne, kann ich den Algorithmus darauf erweitern. Aber abhängig vom Wetter, den Sicht- und Straßenverhältnissen, von anderen Verkehrsteilnehmern und aufgrund von Streuungen im Fertigungsprozess kommt das System irgendwann an seine Grenzen und erkennt ein Schild gar nicht mehr als solches oder interpretiert es falsch. Und das kann dann zu gefährlichen Situationen führen. Die Optimierung der Funktionalität ist nur eine Möglichkeit für fehlerfreies Verhalten. Sie wird immer an ihre Grenzen kommen, und dann müssen andere Lösungen sicherstellen, dass es zu keinem Unfall kommt.

Und welche Lösungen hat die Studie entwickelt?

Ruppert: Zuerst hat man definiert, was überhaupt abzusichern ist. Hierfür hat man "Twelve Principles" (12 allgemeine Prinzipien) definiert, die ein autonomes System erfüllen muss. Man kann diese 12 Prinzipien quasi als 12 „Safety Goals“ ansehen, die jedes autonome System gewährleisten muss.

Aus diesen Prinzipien leitet SaFAD ab, welche zusätzlichen Entwicklungsschritte wie durchzuführen sind, Stichwort „Safety by Design“.

Ein dritter Schwerpunkt ist die ausführliche Verifikation und Validierung der Systeme zum Nachweis der Sicherheit und, insbesondere in der Anfangszeit der Entwicklung, zur Ermittlung weiterer konkreter Anforderungen. Eine Kombination aus Simulation, Testfahrten auf dem Prüfgelände und in der realen Welt wird gefordert. Die Verifikation weist nach, dass alle 12 Prinzipien erfüllt sind.

Herr Ruppert, können Sie die 12 Prinzipien näher erläutern?

Ruppert: Ja, gerne. Zur besseren Übersicht ordne ich die Prinzipien in drei Bereiche:

Der erste Bereich ist verantwortlich dafür, dass das System seine Aufgabe immer sicher ausführt. Hierzu gehört die klare Definition des Einsatzbereiches (fahrerische Aufgabe, Strecke, Wetter, ...), das immer für andere Verkehrsteilnehmer nachvollziehbare Verhalten und Rückfallebenen für problematische Situationen und Fehlerfälle. Das ist in den folgenden vier Prinzipien beschrieben:

  • Operational Design Domain (ODD)
  • Behaviour in Traffic
  • Safe Operation
  • Safe Layer

Der zweite Bereich sichert die Verantwortung zwischen Fahrer und Fahrzeug, also die Übergabe der Verantwortung vom Fahrer an das autonome System oder umgekehrt, aber auch die Überwachung der Fahrtüchtigkeit des Fahrers und seiner möglichen Fehlreaktionen nach Übernahme der Verantwortung. Das erfordert die Einhaltung folgender vier Prinzipien:

  • Vehicle Operator-initiated Handover
  • User Responsibility
  • Vehicle initiated Handover
  • Interdependency

Den dritten Bereich bilden einzelne Prinzipien, die als Unterstützung notwendig sind. Diese sind:

  • Security
  • Passive Safety
  • Data Recording
  • Safety Assessment

Klingt sehr sinnvoll. Aber, was kann ich mir unter „Safety by Design“ vorstellen?

Ruppert: So wie man Qualität nicht durch Testen in ein System hinein bekommt, so ist es auch notwendig, die Sicherheit von Anfang an zu betrachten und in die Architektur einzuarbeiten. Wie dieses geschehen kann, wird in der Studie erarbeitet.

Dafür leitet SaFAD aus den 12 Prinzipien 13 "Capabilities" (Fähigkeiten) ab, die ein autonomes System beherrschen muss, um die Prinzipien zu erfüllen. 7 Fähigkeiten bilden die eigentliche Regelung für das autonome Fahren und eine erste Überwachungsebene. Sie sind "fail-safe“, also ausfallsicher. Die anderen 6 Fähigkeiten erkennen Probleme wie kritische Wetterbedingungen oder Systemfehler. Sie bilden eine Rückfallebene, sie sind „fail-degraded“, eine Fehler vermindernde Fähigkeit. D.h. im Problemfall verhindern sie ein Versagen des Systems und damit einen drohenden Unfall. Sie bringen das Fahrzeug immer in den Zustand des kleinsten Risikos (Minimal Risk Condition (MRC).

Und was hat das mit Design zu tun?

Ruppert: Die fail-safe Fähigkeiten werden nach dem "Sense – Plan – Act („wahrnehmen – planen – agieren) Design Paradigma“, bekannt aus der Robotik und Automatisierungsliteratur, angeordnet. Das heißt, die ersten drei Fähigkeiten nehmen die notwendigen Informationen einer Situation wahr, z. B. Objekte und ihre Bewegung. Die nächste Fähigkeit erstellt einen Plan über das eigene dynamische Verhalten, wie und wo soll sich das Fahrzeug hinbewegen. Zwei weitere agieren, setzen also den Plan um und informieren andere Teilnehmer über den Plan. Die letzte, die überwachende fail-safe und die 6 fail-degraded Fähigkeiten sind parallel immer aktiv, um Probleme zu erkennen und als Rückfallebene zu agieren.

Und das ergibt dann das Design?

Ruppert: Das ist der erste Schritt. Den 12 Fähigkeiten werden in einem zweiten Schritt auf einer funktionalen Ebene “elements“ (Elemente) wie Sensoren, Algorithmen und Aktuatoren zugeordnet, die diese implementieren. Diese Elemente werden dann in einer generischen Architektur angeordnet und Schnittstellen zwischen ihnen definiert. Diese Architektur folgt auch dem Sense – Plan – Act Design Paradigma“.

Das Ergebnis ist also eine funktionale generische Architektur, die ich für alle autonomen Systeme implementieren kann. Mit Hilfe der beschriebenen einzelnen Schritte kann ich meine konkreten Anforderungen auf die Architektur übertragen und erhalte, wenn ich sie richtig implementiere, ein sicheres System.

„Wenn ich es richtig implementiere“ klingt aber nicht sehr vertrauenerweckend!

Ruppert: Natürlich können immer und überall Fehler passieren. Um diese zu erkennen und zu beheben gibt es den dritten Teil: Verifikation und Validierung.

Ähnlich wie beim Design werden hier zuerst einmal fünf Testherausforderungen der autonomen Systeme identifiziert, die es bisher nicht oder nur eingeschränkt gab.

Zur Herleitung einer Teststrategie orientierte sich das Team dann an den 5W2H Fragen (who, what, where, when, why, how, how well). Diese Fragen werden für jede Herausforderung beantwortet, so dass eine Teststrategie entsteht, die man „nur noch“ umsetzen muss.

Wohlgemerkt, die etablierten Testmethoden gelten auch weiterhin, bisherige Tests auf allen Ebenen müssen zusätzlich durchgeführt werden.

Herr Ruppert, das klingt alles sehr theoretisch.

Ruppert: Ja und nein. Im SaFAD Whitepaper wird es natürlich deutlich ausführlicher erläutert, als ich es hier machen kann. Zudem sind zur besseren Veranschaulichung vier Entwicklungsbeispiele enthalten, an denen man sich orientieren kann (Staupilot und Autobahnpilot als Level 3, Stadtpilot und Parkpilot als Level 4 Beispiele).

Ähnlich wie das vom VDA entwickelte E-Gas Überwachungskonzept, das sich zum Quasi-Standard für die Entwicklung sicherheitsrelevanter E/E-Systeme im Fahrzeug entwickelte, bis es von der ISO 26262 abgelöst wurde, hat man hier eine Vorlage, an der man sich orientieren kann. Viele Details, die man übersehen oder Fallen, in die man stolpern könnte, sind benannt und Lösungsvorschläge erstellt. Mit diesem Whitepaper als Grundlage kann man die Entwicklung und Absicherung autonomer Systeme viel genauer abschätzen und planen.

Herr Ruppert, könnten Sie das mal anhand des Beispiels Verkehrsschild ausführen?

Ruppert: Gerne. Wie gesagt, können die Schilder z.B. abhängig vom Wetter nicht erkannt werden. Indem man die Funktionalität erweitert, kann man z.B. ein Stoppschild auch unter Schnee erkennen. Aber bei schwierigen Sichtverhältnissen wie Nebel oder Schneetreiben ist man außerhalb der Operational Design Domain (ODD), sprich ab einer definierten Einschränkung der Sensoren muss das System den Fahrer zur Übernahme des Fahrzeugs auffordern, bevor Schilder übersehen oder falsch interpretiert werden.

Die Grenzen hierzu kann man zuerst mit Simulationen am Rechner, dann z.B. in Klimakammern ausloten. Auf dem Testgelände kann man entsprechende (schlechte) Schilder aufstellen und die Wetterbedingungen simulieren, wenn möglich die Testfahrten auch nach Wetter planen. Fahrten in der realen Umgebung, insbesondere bei den kritischen Wetterbedingungen dort, wo Schilder schon mal falsch erkannt wurden, runden die Erfahrungen ab.

Man braucht also das Whitepaper nur wie ein Kochbuch Schritt für Schritt umzusetzen?

Ruppert: Ganz so einfach ist es auch nicht. Die Vorgaben sind schon noch recht abstrakt. Ähnlich wie bei der Anwendung einer Norm wie Automotive SPICE oder der ISO 26262 muss man aus dem Whitepaper konkrete Arbeitsschritte für das eigene System und Umfeld ableiten, ggf. die eigenen Prozesse anpassen und ergänzen. Auch hier lauern wieder Fallen, die viel Lehrgeld kosten können. Von unserer Erfahrung im Umgang mit solchen Anforderungen und deren Transfer in pragmatische, konkrete Prozessschritte in einem echten technischen Umfeld, profitieren unsere Kunden.

Dann hoffe ich, dass viele Kunden Ihre Dienste nutzen und mit Ihrer Hilfe wirklich sichere autonome Systeme entwickeln, vor denen niemand Angst zu haben braucht.

Besser als Testfahrten

Google & Co. fahren Millionen von Kilometern, um die Funktionalität ihrer autonomen Systeme zu testen. Um die Funktionalität wirklich abzusichern, reicht dieses nach Expertenmeinung bei weitem nicht aus.

Das Bundesministerium für Wirtschaft und Energie hat zusammen mit der Autoindustrie, Zulieferern und anderen Experten das Pegasus Projekt durchgeführt, um eine machbare, bezahlbare, aber trotzdem sichere Alternative zur Verifikation und Validierung der Systeme zu entwickeln. Welche Prozesse benötigt werden und welche Prozessänderungen sie erfordert, weiß Dipl.-Ing. Josef Horstkötter, Senior Consultant und Gesellschafter der F+S Fleckner und Simon Informationstechnik GmbH.

Interview Josef HorstkoetterHerr Horstkötter, wo liegt das Problem, Systeme für das autonome Fahren zu verifizieren?

Dipl.-Ing. Josef Horstkötter: Nach den Vorschlägen der Ethik Kommission sind autonome Fahrzeuge bzw. Fahrzeugfunktionen auch dann vertretbar, wenn sie nicht absolut sicher sind. Sie müssen aber deutlich sicherer sein als ein menschlicher Fahrer. Der Mensch ist ein sehr guter Autofahrer. Auf der Autobahn gibt es nur alle gut 600 Millionen Personen-km einen Unfall mit Schwerverletzten oder Toten. Um nach heutigem Stand der Technik nachzuweisen, dass ein System doppelt so gut wie der durchschnittliche Fahrer ist, wären dann über 6 Milliarden Testkilometer notwendig. Dieses ist natürlich weit jenseits jeder Realisierbarkeit.

Daher werden andere Verifikations- und Validierungsmethoden benötigt, die bezahlbar sind, aber die auch die Sicherheit des Systems konkret nachweisen. Andernfalls erreicht man keine gesellschaftliche Akzeptanz der autonomen Fahrzeuge.

Und diese Methoden wurden von dem Pegasus Projekt entwickelt?

Horstkötter: Teilweise. Das Pegasus Projekt verstand sich als ein zentraler Teil, die Sicherheit eines Systems auf Level 3 zu begründen. Insbesondere will es Nachweise für die Sicherheit des Systems schaffen. Hierbei hat es sich auf die Verifikation und Validierung (V&V) konzentriert. Neben der von Pegasus entwickelten Methode sind aber weitere Aufgaben abzuarbeiten, um das System als sicher zu qualifizieren, z.B. „Safety by Design“ oder eine Feldüberwachung.

Konkret erarbeitete Pegasus eine Methode, um belastbare Nachweise für die Sicherheit autonomer Systeme zu erhalten und außerdem eine exemplarische Werkzeugsammlung, die für die Nachweise der Beispiele entwickelt wurden und weiter ausgebaut werden sollen.

Wie ist das Pegasus Projekt zu diesen Ergebnissen gekommen?

Horstkötter: Das Projekt hat sich in 4 Subprojekte aufgeteilt mit dem Ziel, die beiden zentralen Fragen „Wie sicher ist sicher genug“ und „Wie können wir das überprüfen“ zu beantworten.

Hierzu hat eine Gruppe das fahrerische Können des Menschen untersucht. Eine andere hat die etablierten Entwicklungsprozesse erweitert, um z.B. die Abhängigkeit vom beabsichtigten Einsatzbereich (Operational Design Domain, ODD) zu berücksichtigen. Eine dritte Gruppe prüfte, wie man die Systeme testen kann und eine weitere Gruppe achtete darauf, dass die Ergebnisse in zukünftigen Projekten weiterverwendet und weiterentwickelt werden können, also wirklich die Basis für einen neuen Stand der Technik liefern.

Was haben die menschlichen Fahrkünste mit autonomen Systemen zu tun?

Horstkötter: Um nachzuweisen, dass ein System besser ist als der Mensch, muss man zuerst wissen, wie gut der Mensch die gleiche Aufgabe meistern würde. Ein Durchschnittswert für eine Autobahnfahrt wie in der Einleitung reicht dafür nicht. Man muss neben dem Durchschnitt auch die speziellen Szenarien, also z.B. Fahrten bei Nacht, bei Regen, bei Nebel, in Baustellen etc. bewerten. In keinem Szenario darf der Automat schlechter sein als der Mensch. Ansonsten muss er die Kontrolle an den Menschen abgeben.

Man muss auch beachten, wie gut ein Mensch in der Lage ist, die Fahrzeugkontrolle zu übernehmen, wenn der Automat an seine Grenzen kommt. Er darf nicht zu sehr abgelenkt sein und muss genug Zeit haben, die Situation zu überblicken. Hierbei resultierende Unfälle sind ggf. dem Automaten anzurechnen, nicht dem Menschen.

Zu der dritten Gruppe: sowohl Software- als auch Systemtests sind doch seit langem etabliert. Was muss hier noch erarbeitet werden?

Horstkötter: Die klassischen Tests der Implementierung (Modultest, Software-Integrationstest, Hardwaretests, Systemintegrationstests und Systemtests) müssen natürlich auch weiterhin durchgeführt werden. Diese sind hauptsächlich anforderungsbasiert, man kann für klare Anforderungen hat auch gute Testfälle erstellen.

Bei den komplexen autonomen Systemen, von denen wir hier sprechen, fehlen jedoch oft solche klaren Anforderungen. Wir wissen zwar, dass sie unter bestimmten Umständen an ihre Grenze kommen. Aber wir haben weder eine Vollständigkeit noch die notwendige Detaillierung der Umstände. Diese fehlenden Anforderungen müssen durch Simulationen und Versuche mit dem echten System (Sensoren, Aktuatoren, Algorithmen) ermittelt werden. Das ist ein zyklischer Prozess von Testen, Verbessern und erneut Testen, bis man den Nachweis hat, dass das System sicher genug ist.

Wie muss man sich das konkret vorstellen?

Horstkötter: Zur Verifikation des Automaten versucht man, möglichst alle Situationen und Szenarien zu identifizieren und zu überprüfen. Dies kann anhand von Simulation, Testfahrten auf dem Testgelände oder Feldtests geschehen.

Simulation ist der preiswerteste und reproduzierbarste Ansatz. Daher liegt hier zuerst der Schwerpunkt auf der Identifikation der Systemgrenzen und seiner Optimierung. Eine Datenbank unterstützt durch die Beschreibung von Szenarien auf 6 unabhängigen Ebenen, die notwendige Vollständigkeit zu erreichen.

Bei den Feldtests versucht man, in der Simulation erkannte Grenzen nachzustellen, um zu überprüfen, dass das reale System sich nicht kritischer verhält als das simulierte. Auch bei extremer Fahrdynamik oder Sensor-Phänomenen ist die Simulation in ihrer Genauigkeit begrenzt, hier sind reale Tests aussagekräftiger.

Im Feldtest kann man kritische Fälle nur eingeschränkt prüfen, aber „Überraschungen“ erleben und neue Szenarien oder Parameter erkennen, an die man vorher nicht gedacht hat.

Und das ist dann die neu entwickelte Methode?

Horstkötter lacht: Ein ganz grober Überblick. Allein schon eine grobe Beschreibung der Methode würde hier den Rahmen sprengen. Wenn man die fertige Idee sieht, ist es oft einfach und logisch, sie aus dem „Nichts“ heraus zu erarbeiten ist aber schwierig. Und natürlich habe ich hier nur die Idee wiedergegeben, der Teufel steckt im Detail, und es wurden viele Details erarbeitet, die es umzusetzen gilt.

Wie bei vielen öffentlich geförderten Projekten sind die Ergebnisse öffentlich, jeder kann sie gerne unter www.PegasusProjekt.de nachlesen. Wir haben uns mit den Ergebnissen intensiv auseinandergesetzt, um unseren Kunden auf ihre Bedürfnisse zugeschnittene Lösungen geben zu können. Das ist der Mehrwert, den wir liefern.

Dann wünsche ich Ihnen viel Erfolg bei der Anwendung der Projektergebnisse in ihren Kundenprojekten!

Neue Sicherheitsnorm für Assistenzsysteme

Seit knapp 10 Jahren gibt es die ISO 26262, die vorgibt, wie man die funktionale Sicherheit von Steuergeräten im Automobil sicherstellt. Aber für viele neue Systeme, z.B. Assistenzsysteme, reicht dieses nicht aus. Daher wurde 2019 die ISO 21448 „Road Vehicles — Safety of the Intended Functionality“ (SOTIF) veröffentlicht. Wofür sie benötigt wird und welche Prozessänderungen bei der Entwicklung von Level 1 und Level 2 Systemen sie erfordert, weiß Dipl.-Ing. Josef Horstkötter, Senior Consultant und Gesellschafter der F+S Fleckner und Simon Informationstechnik GmbH.

Josef HorstkötterHerr Horstkötter, wieso reicht die ISO 26262 für Assistenzsysteme nicht aus?

Dipl.-Ing. Josef Horstkötter: Die ISO 26262 geht davon aus, dass ein System sicher funktioniert, wenn es nicht defekt ist. Viele neue Systeme hingegen müssen eine Fahrsituation richtig bewerten, andernfalls sind sie potentiell unsicher. Hierzu benötigen sie komplexe Sensoren, z.B. Kameras oder Radarsensoren, und ggf. künstliche Intelligenz (KI). Alle Komponenten sind in ihrer Leistungsfähigkeit begrenzt, so dass nicht alle Fahrsituationen richtig bewertet werden können.

Man kann sich ja leicht vorstellen, dass eine Kamera im Nebel genauso wenig sieht wie der Mensch, oder dass ein mit Schneematsch bedeckter Radarsensor auch keine Auswertung mehr hinbekommt. Selbst mit korrekt arbeitenden Sensoren können KI Systeme nur die gelernten Fahrsituationen richtig interpretieren. D.h. auch Systeme ohne Defekt sind nicht zwangsweise sicher.

Und was kann man dann tun?

Horstkötter: Die Entwickler müssen die Szenarien und Situationen identifizieren, in denen das System die Fahrsituation nicht mehr korrekt erkennt und Maßnahmen ergreifen, um Unfälle zu verhindern. Z.B. muss ggf. vor Eintritt einer solchen Situation das System abgeschaltet und der Fahrer informiert werden.

Was ist denn daran so schwierig?

Horstkötter: Ein Auto zu bauen ist auch nicht sehr schwierig, das konnten eine Handvoll Mechaniker schon vor 100 Jahren. Ein modernes Auto fordert aber Tausende von Ingenieuren, denn der Teufel steckt im Detail.

Die Umwelt und Technik sind sehr komplex, da ist es nicht einfach, sich jede mögliche Fahrsituation und jeden möglichen Umwelteinfluss vorzustellen. Das ist aber nur die erste Voraussetzung. Danach muss man prüfen, bei welcher Kombination aller Parameter, bspw. unter Berücksichtigung der Streuung der Sensoren oder anderer am Straßenverkehr beteiligter Personen, die Grenzen des Systems liegen und ab welchem Grenzwert daher das System abschalten muss.

Ist es dann denn überhaupt möglich, so ein System wirklich sicher zu entwickeln?

Horstkötter: Ja und nein, das hängt davon ab, was Sie als sicher ansehen. So wie die ISO 26262 die Abwesenheit unangemessener Risiken fordert, tut dieses auch die ISO 21448, ein kleines Restrisiko wird akzeptiert.

Was müssen denn die Entwickler konkret zusätzlich tun?

Horstkötter: Sie müssen alle Situationen genau spezifizieren, daraus Szenarien ableiten und durch Verifikation und Validierung prüfen, bis zu welcher Parameterkombination das System die Fahrsituation richtig erkennt. Die Ergebnisse können zur Verbesserung der Sensoren und Algorithmen verwendet werden oder zur Identifikation der Systemgrenzen und Einnahme eines sicheren Zustandes, wenn sie überschritten werden. Das Ganze natürlich zyklisch, immer wieder, bis das Restrisiko vertretbar klein ist.

Denken Sie an die Mengenlehre in der Schule und stellen Sie sich zwei sich schneidende Mengen vor. Die erste beschreibt die Menge der Fahrsituationen, die bekannt sind (1), der Rest der Welt ist unbekannt. Die Zweite beschreibt die Situationen, in denen das System unsicher ist (2). Schnittmenge sind die Situationen, die den Entwicklern bekannt sind, und in denen das System unsicher ist (3). Der zweite Bereich und die Schnittmenge sollten möglichst klein sein. Der Vollständigkeit halber will ich noch den vierten Bereich, alles, was nicht zu diesen drei Mengen gehört, erwähnen (4). Alles hierin ist unbekannt, aber sicher, daher brauchen wir uns nicht darum zu kümmern.

SOTIF

Sie können sich bestimmt vorstellen, dass man durch entsprechende Tests den unbekannten Bereich verkleinern kann. Und für den bekannten, unsicheren Bereich kann man durch Designmaßnahmen sicherstellen, dass das System diesen nicht betritt (z.B. Abschalten und Fahrer informieren).

Benötigt man dann überhaupt noch die ISO 26262?

Horstkötter: Natürlich, die ISO 21448 setzt ja lediglich dort an, wo die ISO 26262 aufhört. „Klassische Safety“, also die Einhaltung der ISO 26262 ist genauso eine Voraussetzung wie die Einhaltung der in Entwicklung befindlichen ISO 21434 „Road Vehicles - Cybersecurity Engineering“.

Die Norm kann ja jeder kaufen, aber welchen Mehrwert bieten Sie denn ihren Kunden?

Horstkötter: Auch die ISO 26262 kann jeder kaufen. Automotive SPICE ist sogar frei verfügbar. Trotzdem bitten uns unsere Kunden um Hilfe. Die Normen richtig zu verstehen und in pragmatische, den Notwendigkeiten der jeweiligen Unternehmen entsprechende Prozesse umzusetzen, das ist die wahre Schwierigkeit, die ein sehr gutes Verständnis aller Prozesse und Normen erfordert. Mit unserer über 20 Jahre langen Expertise als Prozessberater im Automobilbereich unterstützen wir unsere Kunden auch bei der konkreten Umsetzung der ISO 21448.

Kann man dann mit ihren Prozessen sicher Systeme für autonomes Fahren entwickeln?

Horstkötter: Nein, die Norm gilt nur für die Assistenzsysteme auf Level 1 und Level 2, der Fahrer ist immer noch in der Verantwortung. Für höhere Level des autonomen Fahrens sind noch weitere Sicherheitsmaßnahmen notwendig. Auch hiermit beschäftigen wir uns, aber es gibt noch keine „state of the art“ Lösung. Hier wird noch geforscht, s. das Whitepaper SaFAD oder das Pegasus Projekt der Bundesregierung.

Funktional ist autonomes Fahren schon weit fortgeschritten (s. Presseberichte), aber in der Absicherung dieser Funktionen gibt es noch viele Lücken. Erst wenn auch diese abgestellt sind, sprich das Restrisiko auf ein gesellschaftlich akzeptiertes Niveau gesunken ist, kann man die Systeme einführen und den Menschen zumuten.

Dann wünsche ich Ihnen viel Erfolg, damit die Angst vieler Autofahrer vor den autonomen Systemen unbegründet bleiben möge!

Qualität, Zeit und Kosten im Griff behalten

Automotive-Unternehmen können bei der Softwareentwicklung von den Kompetenzen externer Partner profitieren. Worauf es ankommt, weiß Dr. Joachim Fleckner, Gesellschafter, ehemaliger Geschäftsführer und früherer Mitarbeiter der F+S Fleckner und Simon Informationstechnik GmbH.

Herr Dr. Fleckner, Sie sind viel mit Ihrem Wagen unterwegs – mit „F+S inside“?

Dr. Joachim Fleckner: Klar, denn auch in meinem Wagen „arbeiten“ zahlreiche elektronische Systeme wie Bremsassistenten oder Abstandswarner. Und wir stehen Automotive-Unternehmen eben dabei zur Seite, entsprechende Software-Lösungen zu entwickeln.

Sie engagieren sich auch für Weltmarktführer. Müssten die nicht in der Lage sein, das meiste intern umzusetzen?

Fleckner: Große Zulieferer machen durchaus eine Menge in eigener Regie. Doch auch sie können und wollen nicht alles selbst auf die Beine stellen.

Woran liegt’s?

Fleckner: Automotive-Unternehmen müssen immer komplexere elektronische Systeme bei zunehmenden Qualitätsanforderungen wirtschaftlich zur Marktreife führen. Die Softwareentwicklung erfordert deshalb spezifisches Wissen – und sie braucht eine effiziente Organisation. Als Experten für Automotive Embedded Software stehen wir für beides. Unsere Kunden können also ihre Teams und die technische Infrastruktur schlank halten und unsere Leistungen flexibel nutzen.

Wie meistern Sie Ihre Herausforderungen?

Fleckner: Indem wir unseren Kunden mit einer weiten Perspektive zur Seite stehen: Wir entwickeln und optimieren Software-Lösungen und wir testen sie frühzeitig, um mit wenigen Restfehlern in die aufwändigen nachgelagerten Systemtests zu gehen. Wir helfen unseren Kunden, ihre Entwicklungsprozesse noch besser zu gestalten. Und wir bieten Tools für eine reibungslose Entwicklungsarbeit. Wir können unseren Kunden also versprechen, ihre Projekte mit Blick auf Qualität, Zeit und Kosten optimal umzusetzen.

Wie halten Sie dieses Versprechen?

Fleckner: Wir haben unser Unternehmen so ausgerichtet, dass wir alle Marktanforderungen erfüllen – für unser Qualitätsmanagement wurden wir deshalb nach der ISO-Norm 9001 zertifiziert. Wir folgen den maßgeblichen technischen Normen wie dem State of the Art für eine optimale funktionale Sicherheit, der ISO-Norm 26262. Zudem bewerten wir Software-Prozesse im Rahmen des Branchenstandards „Automotive SPICE“.

Wie sichern Sie das erforderliche Wissen?

Fleckner: Wir stellen nur hervorragende Mitarbeiter ein und qualifizieren sie beständig weiter. Viele unsere Entwickler sind zum Beispiel Certified Requirement Engineers, Architects, Testers. Wir haben zertifizierte „Automotive Functional Safety Professionals“ und „Experts“ in unseren Reihen. Und unsere Berater sind zertifizierte SPICE Assessoren, darunter auch zwei Principal Assessoren. Deshalb dürfen wir auch Assessments durchführen, die von der Hersteller-Initiative HIS und der Interessenvertretung der Assessoren intacs™ anerkannt werden, für die wir übrigens auch die Assessoren-Treffen organisieren.

Und woran arbeiten Sie aktuell?

Fleckner: Konkretes darf ich leider nicht sagen, es geht um Software-Module für technische Systeme, die auch die nächste Fahrzeuggeneration sicherer, effizienter und komfortabler machen.

Dann weiterhin „gute Fahrt“!

Vom Konzept bis zum Produktionsstart

Die Automobilwirtschaft lebt von Ideen. Elektronische Systeme spielen dabei eine wichtige Rolle. Doch damit aus innovativen Ideen auch Erfolge werden, müssen sie effektiv und effizient zur Marktreife geführt werden. Dazu tragen wir als Technologiepartner renommierter Automotive-Unternehmen bei.

Dabei konzentrieren wir uns mit ineinandergreifenden Leistungen auf komplexe Software-Lösungen: Wir entwickeln und testen für unsere Kunden Software-Module für den Einsatz in Fahrzeugen sowie unterstützende Tools. Wir beraten sie, wie sie ihre Entwicklungsprozesse besser und schneller machen können. All unser Wissen wird auch für die Entwicklung sicherer Systeme benötigt, sowohl für funktionale Sicherheit (Safety) als auch für Informationssicherheit (Security).

Unsere Kunden vertrauen uns seit vielen Jahren, auch weil wir uns immer weiterentwickeln. Aktuelle Themen sind die im Automobilbereich die neue Safety Norm ISO 21448 "Road Vehicles — Safety of the Intended Functionality" (SOTIF) und allgemein die Sicherheitsanforderungen für Level 3 und Level 4 Systeme. Wir sind als zertifiziertes „Qualitätsunternehmen“ stets mit allen relevanten Normen und den besten Vorgehensweisen vertraut. Insgesamt verfügen wir über das Expertenwissen, um Entwicklungsprojekte vom Konzept bis zum Produktionsstart zu begleiten. Dieses Wissen machen wir für unsere Kunden produktiv!

Berichte unserer Experten

Interview mit Dipl.-Ing. Josef Horstkötter "Neue Sicherheitsnorm für Assistenzsysteme"

Interview mit Dipl.-Ing. Josef Horstkötter "Besser als Testfahrten"

Interview mit Dipl.-Inform. Marc Ruppert "Autonome Systeme - aber sicher"

Interview mit Dr. Joachim Fleckner "Qualität, Zeit und Kosten im Griff behalten"