In modernen Autos erhöhen Fahrerassistenzsysteme mehr und mehr sowohl den Komfort als auch die Sicherheit. Viele dieser Systeme verringern die Wahrscheinlichkeit menschlicher Fehler, die immer noch die Hauptursache für Unfälle sind1. Mittlerweile können selbstfahrende Autos in den meisten Situationen sogar völlig ohne direktes menschliches Eingreifen funktionieren. Auf diese Weise verlagert sich ein Großteil der Verantwortung für die Vermeidung von Unfällen vom Fahrer auf das Auto – und damit auf die Hersteller und ihre Zulieferer. Die funktionale Sicherheit von Autos wird damit wichtiger denn je. Um diese sicherzustellen, definiert die Norm ISO 26262 verbindliche Anforderungen an den Entwicklungsprozess. Dieser Artikel erläutert, wie Requirements-Traceability dazu beitragen kann, die Anforderungen dieser Norm zu erfüllen.
Autounfälle, die durch einen technischen Defekt verursacht werden, können nicht nur für die Insassen sehr schwere Folgen haben, sondern auch für den Hersteller des Fahrzeugs. Das Image der Marke und sogar des gesamten Unternehmens kann beschädigt werden und den zukünftigen Absatz negativ beeinflussen.
Darüber hinaus kann ein Hersteller nach einem Unfall rechtlich zur Verantwortung gezogen werden, wenn er diesen durch die Anwendung der „üblichen“2 Techniken, die von seinen Wettbewerbern eingesetzt werden, hätte verhindern können. Dazu gehören auch diejenigen Systeme, die nicht von den Herstellern selbst, sondern von ihren Zulieferern produziert wurden.
Daher müssen Automobilhersteller von ihren Zulieferern die Anwendung aktueller Methoden nach dem „Stand der Wissenschaft und Technik“3 verlangen, um die Sicherheit der von ihnen gekauften Systeme zu gewährleisten. Sie überprüfen den korrekten Einsatz dieser Methoden durch Audits, d. h. durch Untersuchungen, bei denen der Zulieferer den Automobilhersteller davon überzeugen muss, dass er die notwendigen Schritte zur Gewährleistung der Sicherheit seiner Produkte durchführt.
Um definieren zu können, was rechtlich von den Automobilherstellern verlangt wird, und was diese wiederum von ihren Zulieferern verlangen müssen, ist ein gemeinsames Verständnis davon erforderlich, was der aktuelle Stand der Technik bei der Entwicklung sicherheitskritischer Systeme ist. Solch ein gemeinsames Verständnis wird durch Standards geschaffen. ISO 26262 ist der wichtigste Standard für die funktionale Sicherheit im Automobilbereich.
Die Norm ISO 26262 empfiehlt spezifische Maßnahmen, die bei der Entwicklung von Fahrzeugsystemen auf den drei Ebenen Hardware, Software und Gesamtsystem umzusetzen sind. Über die Anwendung der Norm hinaus können natürlich neue Technologien verfügbar werden, deren Einsatz nach einiger Zeit obligatorisch werden kann. ISO 26262 wurde 2011 veröffentlicht, wurde aber im Dezember 2018 aktualisiert, um die Norm an den neuen Stand der Technik anzupassen.
ISO 26262 verlangt ein allgemeines Konzept für die funktionale Sicherheit des gesamten Fahrzeugs, das durch eine auf Komponenten basierende Systemarchitektur umgesetzt werden muss. Welche Sicherheitsmaßnahmen bei der Entwicklung einer konkreten Komponente angewendet werden müssen, hängt davon ab, wie wichtig das korrekte Verhalten dieser Komponente für die Sicherheit des Fahrzeugs ist.
eder Komponente wird, abhängig von ihrem Beitrag zum Risiko für schwere Unfälle, ein ASIL (Automotive Safety Integrity Level) zugewiesen. Fehlerhaftes Verhalten einer Komponente mit der höchsten ASIL-Einstufung D führt mit hoher Wahrscheinlichkeit zu Situationen, in denen der Fahrer einen Unfall mit lebensbedrohlichen oder sogar tödlichen Verletzungen nicht mehr verhindern kann.
Komponenten erhalten niedrigere ASILs, wenn ihr Versagen mit geringerer Wahrscheinlichkeit zu Unfällen führt, diese Unfälle weniger gravierende Auswirkungen haben oder sie durch den Fahrer trotz des Systemfehlers vermeidbar sind. Die niedrigste ASIL-Einstufung ist A. Komponenten, die mit noch niedrigerem Risiko behaftet sind, werden als nicht sicherheitskritisch betrachtet. Für sie sind daher nur die üblichen Qualitätssicherungsmaßnahmen ohne besonderen Fokus auf die Sicherheit erforderlich.
Um die Norm ISO 26262 zu erfüllen, muss jeder Komponente das korrekte ASIL zugeordnet werden, und es müssen in der Regel zumindest diejenigen Maßnahmen umgesetzt werden, die in der Norm für das jeweilige ASIL als “highly recommended” definiert sind, also dringend empfohlen werden.
Davon kann allerdings im Einzelfall abgewichen werden, wenn überzeugend dargelegt werden kann, dass dies für die betreffende Komponente nicht erforderlich ist. Das kann beispielsweise dann vorkommen, wenn stattdessen geeignetere Alternativen implementiert wurden oder die jeweilige Empfehlung auf den konkreten Fall nicht anwendbar ist.
Beispielsweise ist für Systeme, die sich lange Zeit im realen Einsatz bewährt haben („proven in use“), eine Ausnahme im Standard vorgesehen4, die eine Einhaltung anderer Vorgaben des Standards ersetzen kann. Letztendlich wird ISO 26262 dann „erfüllt“, wenn die Auditoren davon überzeugt sind, dass sie erfüllt wird.
Am Ende eines erfolgreichen Audits müssen die Auditoren die Überzeugung gewonnen haben, dass der Entwicklungsprozess insgesamt sicherstellt, dass alle Sicherheitsziele (Safety Goals) erfüllt werden. Zulieferer müssen also genau dafür Belege liefern. Allerdings kann das eine ziemlich anspruchsvolle Aufgabe sein, wenn die betreffenden Komponenten sehr komplex sind – was immer häufiger der Fall ist.
Ein Unternehmen, das Komponenten entwickelt, produziert Artefakte (in der Norm als “work products” bezeichnet), wie beispielsweise Anforderungs- oder Testdokumente oder Quellcode. Die in ISO 26262 enthaltenen Empfehlungen definieren die zu erzeugenden Artefakte, die für diese durchzuführenden Arbeitsschritte sowie die Eigenschaften, die sie am Ende des Entwicklungsprozesses haben müssen. Oft betreffen diese Empfehlungen mehrere Artefakte gleichzeitig und auch ihre Beziehungen zueinander.
Die folgende Abbildung zeigt ein kleines Beispiel für mögliche Beziehungen zwischen den bei der Entwicklung relevanten Artefakten. In der Mitte ist ein mit Enterprise Architect entwickeltes Komponentenmodell (RainSensing) für die Implementierung eines Regensensors dargestellt. Dieses steht in direkter Beziehung einerseits zur Softwareanforderung, die es umsetzt (SW-R 4.2.1.1), und andererseits zu einem Test der modellierten Funktionalität sowie einem Simulink-Modell (RainSensor), welches RainSensing auf einer niedrigeren Ebene konkretisiert.
Das Beispiel zeigt nur Beziehungen zu denjenigen Artefakten, die direkt für RainSensing relevant sind. Natürlich stehen diese Artefakte wiederum in Beziehung zu weiteren Artefakten, die indirekt ebenfalls für RainSensing relevant sind.
Ein großer Teil der Funktionalität vieler moderner Fahrzeugsysteme wird mittlerweile durch Software definiert. Mittels Software kann sehr komplexes Systemverhalten auf vergleichsweise einfache Weise definiert werden. Weniger einfach ist es jedoch, die Korrektheit dieses Verhaltens sicherzustellen. Das hängt damit zusammen, dass bei der Entwicklung komplexer Software extrem viele Artefakte im Softwareentwicklungsprozess relevant sind bzw. durch diesen erzeugt werden. Bei Projekten zur Entwicklung von Steuergeräten etwa liegt diese Zahl nach unserer Erfahrung ca. im Bereich von 20.000–200.000 Artefakten.
Eine höhere Komplexität eines Systems bedeutet, dass es sich in einer größeren Anzahl von Situationen unterschiedlich verhält. In jeder Situation muss das Systemverhalten korrekt sein. Um zu definieren, was in jeder Situation „korrekt“ ist, müssen bei höherer Komplexität also mehr Anforderungen definiert werden. Diese Anforderungen wiederum müssen implementiert und getestet werden, was die Anzahl von Artefakten weiter erhöht.
Um diese Komplexität beherrschbar zu machen, werden Systemkomponenten oft hierarchisch in kleinere Komponenten auf einer niedrigeren Abstraktionsstufe aufgeteilt, die jeweils nur einen Teil der Funktionalität realisieren. Auf diese Weise können sich Entwickler auf die Lösung kleinerer, lokaler Probleme konzentrieren, die einfacher zu verstehen sind. Dies ist erforderlich, weil die Menge von Informationen, die ein Entwickler gleichzeitig erfassen kann, begrenzt ist. Muss er mehr Informationen berücksichtigen, steigt seine Fehlerquote.
Aus diesem Grund wird eine hierarchische Strukturierung der Software sogar für ASIL A dringend empfohlen („strongly recommended“). Leider erhöht jede hierarchische Unterteilung von Komponenten die Gesamtzahl an Artefakten, die berücksichtigt werden müssen, wenn die Einhaltung von ISO 26262 überprüft werden soll.
Üblicherweise ist eine hohe Anzahl von Artefakten nicht einmal die größte Herausforderung. Die Anzahl von Beziehungen zwischen den Artefakten ist meist noch wesentlich größer. Entwickler von Komponenten müssen nachvollziehen können, welche Teile ihrer Implementierung welche sicherheitskritische Anforderung umsetzen, und welche Testfälle (oder anderen Maßnahmen) überprüfen, ob die Implementierung tatsächlich funktioniert.
Um Anforderungen höherer Abstraktionsstufen zu implementieren, müssen diese Anforderungen oft zu untergeordneten Anforderungen mit mehr technischen Details verfeinert werden. Die Beziehungen zwischen Anforderungen auf derselben und auf anderen Ebenen der resultierenden Hierarchie sind für das Verständnis des Systems essenziell. Sie sind insbesondere auch wichtig, wenn nachvollzogen werden soll, wie die Sicherheit des Systems durch seinen Entwicklungsprozess garantiert wird. Daher verlangt ISO 26262 explizit, dass Requirements-Traceability (die Nachverfolgbarkeit von Anforderungen) zwischen diesen Artefakten sichergestellt werden muss.
Requirements-Traceability bedeutet, dass Entwickler Anforderungen zu denjenigen Artefakten zurückverfolgen können, die sicherstellen, dass die Anforderungen tatsächlich erfüllt werden. Wie bereits in den vorherigen Abschnitten erläutert, gehören zu diesen Artefakten typischerweise weitere Anforderungen, für die Implementierung relevante Dokumente (z. B. Modelle und Quellcode) sowie Artefakte, die Maßnahmen zur Verifikation und deren Ergebnisse dokumentieren.
Um Requirements-Traceability zu garantieren, müssen die Beziehungen zwischen Artefakten auf irgendeine Art dokumentiert werden. Diese dokumentierten Beziehungen werden als „Tracelinks“ bezeichnet.
Die folgende Abbildung zeigt einige Tracelinks aus einem Beispielprojekt. Die Knoten des Graphen repräsentieren Artefakte mit Bezug zu einer bestimmten Anforderung auf höchster Abstraktionsebene (SH-R 2.1.1, SH-R steht dabei für „Stakeholder Requirement“). Die Kanten zwischen diesen Knoten entsprechen den Tracelinks. Die Abbildung zeigt nur einen Ausschnitt aus dem Graphen des Beispielprojekts. Die manuelle Analyse der Tracelinks ist selbst dann eine Herausforderung, wenn es nur wenige ähnlich komplexe Anforderungen auf höchster Abstraktionsebene gibt. In echten Projekten sind diese weitaus zahlreicher, und es sind mehr Artefakte für deren Umsetzung erforderlich.
Natürlich sollte Requirements-Traceability auch dann sichergestellt werden, wenn diese in einem konkreten Fall nicht explizit von der ISO 26262 verlangt wird, da sie zum Nachweis mancher Empfehlungen der Norm implizit benötigt wird. Beispielsweise ist es nicht besonders hilfreich, wenn im Audit für einen bestimmten Teil der Implementierung eine formale Spezifikation nachgewiesen werden soll, diese auch existiert, aber nicht (schnell genug) auffindbar ist. Es reicht nicht aus, dass die verlangten Artefakte existieren, man muss sie auch finden können. Requirements-Traceability kann das sicherstellen.
Darüber hinaus können Tracelinks auch für verschiedene Analysen des Systems verwendet werden:
Tracelinks ermöglichen außerdem eine „Coverage Analysis“. Dies ist eine Analyse, die sichtbar macht, welche Artefakte eines gegebenen Typs mit Artefakten eines anderen Typs in Beziehung stehen sind. Die dadurch ermittelten Informationen können dabei helfen, verschiedene Arten von Problemen in der Software zu finden bzw. deren Abwesenheit nachzuweisen:
Weiterhin kann man die durch Requirements-Traceability verfügbaren Informationen in Verbindung mit anderen Techniken nutzen, um ihre Effektivität zu steigern. Wird beispielsweise auf Grundlage von Anforderungen getestet („Requirements-based Testing“), dann muss sichergestellt sein, dass alle Anforderungen direkt oder indirekt durch Tests abgedeckt werden. Eine hohe Überdeckung von Anforderungen durch Tests kann ein überzeugendes Argument für die Qualität einer Software bzw. eines Systems sein.
Um die Überdeckung von Anforderungen zu berechnen, müssen zwei Arten von Tracelinks verwendet werden. Dies sind einerseits die Tracelinks, welche die Hierarchie von Anforderungen repräsentieren, und andererseits die Tracelinks, die Anforderungen mit den spezifisch für sie durchgeführten Tests verknüpfen. Auf dieser Grundlage kann man ermitteln, welche Anforderungen indirekt durch Tests abgedeckt sind. Da dieser Schritt sehr aufwendig sein kann, sollte er automatisiert werden.
Der Nutzen von Requirements-Traceability beschränkt sich nicht auf Audits. Tracelinks sind im Prinzip eine Form der Dokumentation, die implizite Informationen über Beziehungen zwischen Artefakten explizit macht. Wenn Entwickler sich impliziter Abhängigkeiten zwischen Artefakten nicht bewusst sind, kann dies sehr leicht zu Fehlern führen.
Abhängigkeiten zwischen Komponenten („Interference“) führen nach ISO 26262 außerdem dazu, dass alle betreffenden Komponenten nach dem höchsten ASIL der Einzelkomponenten entwickelt werden müssen. Werden solche Abhängigkeiten ignoriert, dann ist die Wirksamkeit jeglicher Bemühungen, die Sicherheit des Systems zu garantieren, zweifelhaft. Das Übersehen von Abhängigkeiten ist besonders dann wahrscheinlich, wenn Komponenten nach ihrer ursprünglichen Entwicklung zu einem späteren Zeitpunkt geändert werden, besonders wenn dies durch andere Entwickler geschieht und diese nicht auf eine Dokumentation dieser Abhängigkeiten zurückgreifen können.
Wenn eine Beziehung zwischen zwei Artefakten besteht, dann kann diese auf einfache Weise als Tracelink dokumentiert werden, indem man einen Globally Unique Identifier (also einen global eindeutigen Bezeichner, GUID) des ersten Artefakts zusammen mit dem zweiten Artefakt (oder als dessen Teil) speichert. Beispielsweise könnte ein Kommentar im Quellcode einer Funktion in der Programmiersprache C Referenzen auf bestimmte Abschnitte von Testdokumenten enthalten, welche die bei der Implementierung dieser Funktion zu berücksichtigenden Anforderungen beschreiben.
Die Beziehungen können in diesem Fall allerdings nur in eine Richtung nachvollzogen werden. Man könnte also von der C-Funktion aus zwar sehr einfach den Text der verknüpften Anforderungen finden, aber nicht umgekehrt. Um Nachverfolgbarkeit in beide Richtungen, also Bidirectional Traceability, zu ermöglichen, muss die C-Funktion auch vom Text der Anforderungen aus eindeutig referenziert werden. Man könnte jeden bidirektionalen Tracelink als zwei unidirektionale Tracelinks umsetzen, allerdings unter der Gefahr, dass sich durch spätere Änderungen Inkonsistenzen einschleichen.
Wenn man Tracelinks auf die oben beschriebene Weise speichert, dann kann es sehr schwer werden, einen umfassenden Überblick darüber zu bekommen, welche Links zwischen welchen Arten von Artefakten existieren. Dies kann aber erforderlich sein, beispielsweise um die Überdeckung von Anforderungen oder Quelltext durch Tests zu ermitteln, die (wie bereits erwähnt) als Qualitätsmaßstab wichtig sein kann.
Alternativ lassen sich Tracelinks auch unabhängig von den Artefakten in speziellen Dateien oder als Datenbankeinträge speichern. Dies ermöglicht einen einfacheren Überblick und garantiert Konsistenz. Andererseits kann man dann nicht mehr an den Artefakten selbst erkennen, an welchen Tracelinks sie beteiligt sind. Beim Bearbeiten der Artefakte können Entwickler dadurch die durch diese Tracelinks repräsentierten Beziehungen übersehen. Umgekehrt können sie auch die Beziehungen kennen, aber übersehen, dass diese nicht durch Tracelinks dokumentiert sind. Beides kann zu falschen Entscheidungen aufgrund unvollständiger Informationen führen.
Ein beliebter Ansatz zum zentralen Erfassen von Tracelinks ist die Requirements-Traceability-Matrix. Der Blogbeitrag „5 reasons why a requirements traceability matrix is not enough“ befasst sich mit den spezifischen Problemen dieser Technik und behandelt außerdem einige allgemeine Probleme, die für alle manuellen Ansätze gelten.
In einem typischen Projekt macht es die enorme Anzahl von Tracelinks praktisch unmöglich, Requirements-Traceability ohne jede Automatisierung zu erreichen. Das ist schon dann ein Problem, wenn es nur um das Verstehen der verfügbaren Informationen geht. Es ist aber noch viel schwieriger, diese Informationen aktuell und konsistent zu halten.
Im Idealfall sollten Tracelinks automatisch erzeugt und aktualisiert werden oder zumindest mit minimalem menschlichem Eingreifen. Um wirklich Nutzen aus Traceability ziehen zu können, muss es möglich sein, verschiedene Analysen auf diesen Daten durchzuführen (wie im vorherigen Abschnitt erläutert wurde), was selten manuell möglich ist. Es gibt mittlerweile einige Werkzeuge, die solche Analysen unterstützen. Viele Projekte erfordern jedoch speziell angepasste oder neu erstellte Lösungen.
Eine zusätzliche Herausforderung ist, dass Tracelinks oft in vielen Dateien mit unterschiedlichen Formaten gespeichert werden. Der Grund dafür ist normalerweise, dass mehrere unterschiedliche Werkzeuge im Projekt verwendet werden müssen, weil jedes von ihnen nur ein bestimmtes Problem löst.
Die folgende Abbildung zeigt ein Beispiel einer möglichen Menge von Artefakttypen, die in der Entwicklung eines Projekts benötigt werden, und deren mögliche Beziehungen. Diese Artefakttypen sind hier grob entsprechend des V-Modells angeordnet, also mit den Artefakten der Systementwicklung auf der linken Seite und den entsprechenden Tests auf der rechten.
Die Abbildung zeigt den Project Overview aus dem Tool YAKINDU Traceability (Information: YAKINDU Traceability Is Now itemis ANALYZE).
Die Icons in den Kästchen zeigen an, in welchen Werkzeugen oder Dokumentenformaten die Artefakte des jeweiligen Typs gespeichert sind. In diesem Beispiel sind Testspezifikationen und -ergebnisse in XML sowie in Excel- und Word-Dateien abgelegt. Auf der linken Seite des V werden Excel, Simulink, Enterprise Architect und YAKINDU Statechart Tools (Information: YAKINDU Statechart Tools Is Now itemis CREATE) für Spezifikation und Entwurf verwendet, während die Software selbst in C geschrieben wird. Anforderungen sind in IBM DOORS gespeichert.
Um die Verwendung derart vieler Formate zu vermeiden, kann man versuchen, die Anzahl von Werkzeugen zu reduzieren, indem man eine integrierte Lösung in Form eines einzelnen Werkzeugs verwendet, das so viele Schritte des Entwicklungsprozesses wie möglich abdeckt. Dies kann aber bedeuten, dass man gezwungen ist, seinen Entwicklungsprozess an diesem einen Werkzeug auszurichten, statt diejenigen Werkzeuge zu finden, die den eigenen Prozess am besten unterstützen.
Weiterhin birgt dieser Ansatz die Gefahr eines „Vendor Lock-in“, d. h. man kann in eine Situation geraten, in der alle wichtigen Informationen im Format eines bestimmten Werkzeugs abgelegt sind, das nun aber nicht mehr gepflegt wird oder für das der Hersteller extrem hohe Lizenzgebühren verlangt. Ein weiteres Problem in solchen Fällen ist, dass sich viele Beschäftigte zu einem gewissen Grad in der Anwendung des nun obsoleten Werkzeugs spezialisiert haben. Zeit und Aufwand werden nötig, um sie in anderen Werkzeugen zu schulen.
Einzelne Werkzeuge sind normalerweise einfacher zu ersetzen. Das Risiko kann weiter durch den Einsatz standardisierter Dokumentenformate reduziert werden, die Werkzeuge verschiedener Hersteller unterstützen. Außerdem kann ein Werkzeug, das sehr viele unterschiedliche Aufgaben abdeckt, im Allgemeinen nicht jede einzelne Aufgabe so gut lösen wie ein auf die jeweilige Aufgabe spezialisiertes.
Es gibt spezielle Lösungen, mit denen Requirements-Traceability erreicht oder unterstützt werden kann und die auf die im jeweiligen Projekt verwendeten Werkzeuge angepasst werden können. Sie ermöglichen die Visualisierung und Analyse von Tracelinks unabhängig davon, wie diese abgelegt sind. Dadurch bleiben die Vorteile aufgabenspezifischer Werkzeuge erhalten, während gleichzeitig das Problem gelöst wird, viele verschiedene Dokumentenformate unterstützen zu müssen.
Bei der Entwicklung sicherheitskritischer Systeme, die von ISO 26262 nicht abgedeckt werden, können andere Normen oder rechtliche Vorgaben direkt oder indirekt Requirements-Traceability verlangen. Doch selbst wenn das nicht der Fall ist, kann Traceability sinnvoll oder erforderlich sein, um nach einem Unfall schnell alle relevanten Informationen ermitteln zu können. Damit kann man im Idealfall nachweisen, dass inkorrektes Systemverhalten nicht die Ursache gewesen sein kann oder dass man bei der Entwicklung des problematischen Systems zumindest alle üblichen Vorkehrungen zur Vermeidung derartiger Fehler getroffen hat.
Auch bei der Entwicklung nicht sicherheitskritischer Systeme kann Traceability helfen. Requirements-Traceability besteht letztendlich in der Dokumentation der Beziehungen zwischen den bei der Entwicklung relevanten Artefakten. Diese Beziehungen zu ignorieren, kann bei der Entwicklung jedes Systems schnell zu Fehlern führen.
Wie jede Art von Dokumentation bedeutet auch die Dokumentation von Tracelinks Aufwand. Dieser Aufwand beschränkt sich nicht auf die initiale Erzeugung der Tracelinks, sondern ergibt sich zu einem großen Teil aus dem Erfordernis, die Links aktuell zu halten. Wenn für Requirements-Traceability kein zwingender Grund besteht, muss man entscheiden, ob die Vorteile die Kosten rechtfertigen. Das hängt in erster Linie davon ab, wie gravierend die Auswirkungen von Fehlern im Produkt sind.
Eine große Anzahl von Blogbeiträgen über verschiedene Themen mit Bezug zu Traceability gibt es in unserem Blog, sowohl auf Deutsch als auch auf Englisch. Wir entdecken oft neue und interessante Aspekte von Requirements-Traceability, wenn wir zusammen mit unseren Kunden daran arbeiten, die richtige Lösung für ihre jeweiligen Projekte zu finden und zu implementieren. Wir werden daher weiterhin Artikel in diesem Bereich veröffentlichen.
Wenn du willst, dass wir in einem zukünftigen Blogbeitrag ein spezielles Thema mit Bezug zu Requirements-Traceability behandeln, dann schreibe uns deinen Vorschlag einfach als Kommentar zu diesem Artikel!
1 In 2021, according to the Federal Statistical Office of Germany (Statistisches Bundesamt), 306,292 traffic accidents with personal injuries in Germany had driver-related causes (Link to www.destatis.de/EN). In the same year, only 3,333 traffic accidents with personal injuries were caused by technical faults (Link to www.destatis.de/EN).