Fachthemen

42 ProduktDatenJournal 2019-1

Jens Krüger, NTT DATA

Entwicklungsmethoden für autonomes Fahren

Das Rennen zum autonomen Fahren ist in vollem Gange und beschäftigt die Entwicklungsabteilungen

der Automobil- und IT-Industrie. In diesem Beitrag werden eine Reihe von Innovationen zur Entwick-

lung und Absicherung automatisierter Fahrfunktionen vorgestellt: Erweiterungen des sogenannten

V-Modells, skalierte agile Methoden, Model-Based Systems Engineering und der datengetriebene

Entwicklungsprozess.

Neue Fahrzeugkomponenten Fahrerassistenzsysteme (Advanced Driver Assistance Systems, kurz ADAS) für das autonome Fahren erfordern die Integra-tion mehrerer neuer Komponenten in das Fahrzeug – allen voran Sensoren: Die Augen und Ohren eines mensch -lichen Fahrers werden im autonomen Fahrzeug durch Sensorik ersetzt. Senso-ren ermöglichen dem Fahrzeug, ein Bild der Umgebung zu generieren. Um auch bei Defekten und ungünstigen Umwelt-bedingungen wie Regen und Schnee eine Abbildung des Fahrzeugumfelds zu

Wann wird autonomes Fahren Wirklichkeit? Elon Musk sagte 2014, dass die Technologie für voll-ständig selbstfahrende Fahrzeuge in fünf bis sechs Jahren vorhanden sein wird, was eine Serienreife ab 2020 impliziert. Stand heute ist: Mit Adaptive Cruise Con-trol, Parkassis tenten oder Staupiloten sind mittlerweile erste Fahrzeuge verfügbar, die automatisiertes Fahren auf Level 3 bieten. Level 3 bedeutet: Das Auto übernimmt für bestimmte Situationen die Kontrolle, der Fahrer muss aber jederzeit eingreifen können. Die Automobil OEMs arbeiten mit Hoch-druck an der Entwicklung weiterer Funktionen zum auto -nomen Fahren.

erhalten, ist eine redundante Auslegung der Sensoren erforderlich. Mit der Kom-bination mehrerer Sensortypen (Lidar, Radar, Kameras, Ultraschall) und der Fusion der erzeugten Sensordaten wird es möglich, das Umfeld sehr zuverlässig zu erfassen und entsprechend das Fahr-verhalten des autonomen Fahrzeugs abzuleiten. Die Verarbeitung der Sensordaten umfasst neben der Datenfusion insbe-sondere das Erkennen der Umwelt und die Ableitung entsprechender Fahrent-scheidungen. Dazu werden leistungs -

fähige Rechner mit Artificial Intelligence (AI) genutzt, d.h. vorab trainierte neuro-nale Netze (Machine Learning). Die Sensordaten können an ein IT-Back–end-System übertragen, dort ver-arbeitet und dann wieder an das Fahr-zeug zurückgesendet werden. Dies eröffnet neue Möglichkeiten, zum Bei-spiel die Zusammenführung der gene-rierten Daten mit zusätzlichen, zeitgleich gesammelten Daten durch weitere Fahrzeuge in der Umgebung. Eine weitere Komponente sind hoch -präzise, dynamische Echtzeit-Karten. Sie steuern das Fahrzeug mit einer Genauig-keit im Dezimeter-Bereich und sind unverzichtbar für das autonome Fahren, da sie eine Vorhersage der Steuerung über die Reichweite der Sensoren hin-aus erlauben. Echtzeit-Karten finden die bestmögliche Route und enthalten aktu-elle Daten über Verkehrsregeln, Stra-ßenschilder, mögliche Hindernisse oder Straßenverhältnisse.

Fachthemen

2019-1 ProduktDatenJournal 43

Wanted: Ein neuer Entwicklungs-prozess für ADAS Die Entwicklung von komplexen mecha-tronischen Systemen in der Automobil-industrie basiert normalerweise auf Methoden aus dem Systems Enginee-ring und wird als V-Modell dargestellt. Die Entwicklung vernetzter, AI-basieren-der Systeme erfordert allerdings einige Änderungen und Erweiterungen im Entwicklungsprozess: Ein neues V-Modell Das klassische V-Modell gemäß VDI-Richtlinie 2206 beschreibt im linken Ast die Entwicklungstätigkeiten von der Produkt-Ebene über die System-Ebene bis hin zur Komponenten-Ebene. Für die Komponenten-Entwicklung gibt es die Disziplinen Mechanik, Elektrik/Elektronik und Software. Im rechten Ast finden sich die entsprechenden Integrations- und Verifikations-/Validierungstätigkeiten auf diesen drei Ebenen. Schon das Festlegen der Produkt-Ebene ist für die ADAS-Entwicklung nicht ein-fach: Hier geht es nicht nur um das einzelne Fahrzeug, sondern um ganze Fahrzeugflotten sowie die Vernetzung zwischen Fahrzeugen und mit dem Con-nected Services Backend. Entsprechend

muss die Entwicklung der digitalen Ser-vices in den Entwicklungsprozess inte-griert werden, um deren Verfügbarkeit und Funktionalität bei der Markteinfüh-rung sicherzustellen. Das heißt konkret: Die Entwicklung von Services ist eine neue Disziplin im V-Modell. Agile Produktentwicklung In der Software-Entwicklung für Busi-ness-Applikationen werden mittlerweile überwiegend agile Methoden wie SCRUM eingesetzt. Die Vorteile im Hinblick auf Flexibilität, Geschwindigkeit und auch Mitarbeitermotivation über-wiegen mögliche Nachteile wie Kommu-nikationsaufwand und fehlende Projekt-planung. Insbesondere die schnellen Zyklen von Spezifikation, Entwicklung und Test in den Sprints führen zu einem sichtbaren Projektfortschritt und bieten Gelegenheit, die Planung flexibel anzu-passen. Entsprechende Überlegungen fließen auch in Verbesserungen des V-Modells ein. So gibt es zum Beispiel das W-Modell, in dem die Integration der digitalen Modelle aus den einzelnen Teildisziplinen schon während der Ent-wicklung erfolgt. Dadurch werden späte, teure Änderungen vermieden, die sonst in der Integrationsphase des klassischen V-Modells zu erwarten sind.

In der Software-Entwicklung für sicher-heitskritische Fahrfunktionen gibt es allerdings weitere Herausforderungen im Hinblick auf den Einsatz agiler Metho-den, nämlich die Sicherheitsnorm ISO 26262 und die Skalierung der agilen Methoden auf Programmebene. Die ISO 26262 „Functional Safety“ ist eine Norm für sicherheitskritische E/E-Systeme und Software-Komponenten in der Fahrzeugentwicklung. Sie nutzt ein Prozessmodell mit Phasen auf Basis des V-Modells, das zunächst im Widerspruch zu agilem Vorgehen steht. Mit einem Fokus auf die Arbeitsergebnisse wie Operational Situations, Hazards, Safety Goals und Safety Requirements sowie der Priorisierung dieser Themen im Backlog lassen sich auch agile Metho-den für sicherheitskritische Themen nut-zen. Die optimale Größe von Arbeitsteams wird oft mit „7 +/- 2 Personen“ angege-ben. Jedoch werden für das autonome Fahren mit Level 3 bereits mehrere hun-dert Millionen Zeilen Software-Code benötigt, für Level 5 über eine Milliarde Zeilen Code. Es werden also Wege zur Skalierung agiler Methoden benötigt, mit denen Teams von mehreren hundert Personen in einem Programm agil

Bild 1: V-Modell [Quelle: prostep ivip – Smart Systems Engineering]

Fachthemen

44 ProduktDatenJournal 2019-1

zusammenarbeiten können. Zwei gängi-ge Frameworks sind das Scaled Agile Framework (SAFe) und Large-Scale Scrum (LeSS). Damit können mehrere agile Teams auf Team-Ebene effizient arbeiten und auf Programm-Ebene effektiv synchronisiert werden. Model-Based Systems Engineering (MBSE) Methoden wie Anforderungs- und Konfi-gurationsmanagement können zu umfangreichen Dokumenten führen: Hunderte von Komponenten-Lastenhef-ten, die in System-Lastenheften referen-ziert werden. Auch mit Best Practices aus dem Requirements Engineering wird eine Komplexität erreicht, die von Menschen nicht mehr beherrschbar ist. Daher geht man zur Nutzung formaler Modelle anstelle von Fließtext-Spezifika-tionen über. Solche Modelle lassen sich zum Beispiel mit der Modellierungsspra-che SysML beschreiben. Die Vorteile lie-gen in der möglichen Automatisierung, zum Beispiel der Validierung von Model-len gegen vorgegebene Regeln, der automatischen Optimierung von Model-len sowie der Generierung von ausführ-barem Code für Steuergeräte.

Datengetriebener Entwicklungsprozess Für die Fusion der Sensordaten, das Erkennen der Umwelt und anderer Ver-kehrsteilnehmer und für die Steuerung des autonomen Fahrzeugs wird AI ein-gesetzt, insbesondere Deep-Learning-Verfahren. Dabei bestimmen die Menge und Qualität der Trainingsdaten die Qualität der resultierenden neuronalen Netze. Daten sind in diesem Kontext

ähnlich wie Anforderungen zu sehen. Zur Absicherung und Zulassung der ADAS müssen Millionen von Testszena-rien und virtuellen Testkilometern simu-liert werden. Autonome Fahrzeuge generieren circa 5 Terabyte pro Tag. Diese Datenmengen sind effizient von Testfahrzeugen herun-terzuladen und mit einer Speicher-Archi-tektur zu verwalten, die für dreistellige

Bild 2: Scaled Agile Framework (SAFe)

Bild 3: IT-Plattform zur Entwicklung und Absicherung automatisierter Fahrfunktionen

Fachthemen

2019-1 ProduktDatenJournal 45

Petabyte-Volumina ausgelegt ist. Die Kosten solcher IT-Plattformen lassen sich durch gemeinsame Nutzung einer Hybrid-Cloud-Architektur optimieren. Neben teuren Messdaten aus Realfahr-ten kommen auch synthetisch generierte Trainingsdaten zum Einsatz. Umfangrei-che Simulationsumgebungen können Straßen, Umgebung, Wetter, andere Verkehrsteilnehmer und die eigene Fahrzeugphysik simulieren. Durch Varia-tion dieser Teilmodelle lassen sich nicht nur umfangreiche Trainingsdaten gene-rieren. Es können auch die besonders interessanten Grenzfälle untersucht werden, die im realen Verkehr nur selten vorkommen. Ein weiterer Vorteil synthe-tischer Trainingsdaten ist: Es entfällt der aufwendige Labeling-Prozess, das heißt die Klassifizierung von Objekten in rea-len Sensordaten als Referenz für das Machine Learning. Überblick ADAS Entwicklung Eine Herausforderung in diesem Umfeld ist nicht nur die IT-Infrastruktur, sondern sind auch konzeptionelle Probleme im Debugging von neuronalen Netzen. Nachdem die Ergebnisse nicht mehr hauptsächlich auf beweisbaren Algorith-men, sondern auf umfangreichen, hete-

rogenen Daten basieren, müssen neue Wege zur Absicherung gefunden wer-den. Gemäß ISO 26262 werden derzeit Sicherheitskonzepte für Technik, Hard-ware und Software erstellt. Nach der aktuellen Diskussion ist die Entwicklung eines zusätzlichen Sicherheitskonzeptes für Machine Learning erforderlich. Dieses kann nicht mehr auf einfachen Fehler-Ursache-Wirkungsketten beru-hen, sondern muss mit Hypothesen und Wahrscheinlichkeiten in neuronalen Netzen arbeiten. Ausblick Neben den technischen Hürden müssen vor einer breiten Markteinführung weite-re Fragen zum Beispiel von Gesetzge-bern, Zulassungsbehörden und Versi-cherungsgesellschaften beantwortet werden. Zentrale Voraussetzung für die gesellschaftliche Akzeptanz des autono-men Fahrens sind sicherere Systeme. Das bedeutet neben funktionaler Sicher-heit der Fahrerassistenzsysteme auch Datensicherheit, sichere Software-Updates und Cybersecurity zum Schutz des Fahrzeugs gegen Angriffe von außen. Daher muss im Sinne von „Security by Design“ dieses Thema durchgängig bei allen Verbesserungen

des Produktentwicklungsprozesses im Vordergrund stehen. Ob das bis 2020 zu schaffen ist?

Bild 4: Überblick ADAS Entwicklung

Jens Krüger NTT DATA Tel. +49 89 9936-1133 E-Mail: jens.krueger@nttdata.com

Kontakt