Elektroniknet Logo

Der Weg zum autonomen Fahren

Durch unbekanntes Terrain


Fortsetzung des Artikels von Teil 1

Neue Konzepte

Sollte nun zukünftig die kostenintensive Rechenkapazität einmal nicht ausgelastet sein, wird das Fahrzeug vielleicht selbst in der Cloud seine (bezahlten) Dienste anbieten (Bild 3). So wird das Fahrzeug der Zukunft selbst zu einem Knoten im globalen Netzwerk und über weit mehr Rechenleistung verfügen, als vor einigen Jahren vorstellbar war. Hier müssen OEMs, Lieferanten und neue Marktteilnehmer ihre Strategien überdenken und entsprechend neu ausrichten.

Die erforderlichen Strategien müssen zu Produktstrategien für einen spezifischen Markt verfeinert werden, der sich jedoch sehr schnell entwickelt und auch wieder verändert. Um Schritt zu halten, muss der Entwicklungsvorlauf reduziert werden.

Das bedeutet, dass die Arbeit nicht auf die OEM-Vorgaben warten kann (die oftmals für einen langen Zeitraum einer Geheimhaltung unterliegen). Eigene Strategien sind erforderlich, um darauf basierend Wahrscheinlichkeitsaussagen zu treffen und den zukünftigen Markt vorherzusehen.

Anbieter zum Thema

zu Matchmaker+
Das Auto der Zukunft wird als „Smart Car“ in die Cloud integriert und neue Anwendungen und Dienste ermöglichen
Bild 3. Das Auto der Zukunft wird als »Smart Car« in die Cloud integriert und neue Anwendungen und Dienste ermöglichen.
© shutterstock – Andrey Suslov

Um das zu erreichen, sind neue Entwicklungswerkzeuge und -methoden notwendig. Eine reine »Evolution« ist nicht ausreichend, um in einem radikal neuen Umfeld zu bestehen – Kreativität, Einblick in branchenfremde Ansätze, rasche Vorentwicklungszyklen und auch Willen sind gefragt. Aus derartigen Ansätzen entstehen neue Entwicklungslinien, die sich idealerweise mit den Tendenzen im eher klassischen Umfeld überschneiden – ein wichtiges Indiz für eine hohe Eintrittswahrscheinlichkeit.

Zudem sind auch neue Fragestellungen ausschlaggebend. Wie viel Kapital wird beispielsweise ein Endkunde dem OEM für das autonome Fahrzeug zur Verfügung stellen?

Laut Schätzungen von Uber wird ein autonom fahrendes Taxi pro Jahr, je nach Schichtmodell, ein bis drei Jahresgehälter für den Fahrer einsparen. Auf den Return on Investment von einem Jahr umgerechnet entspricht das pro Fahrzeug einem Kostenrahmen von einigen Tausend Euro. Wird es daher zwei oder mehr große Entwicklungslinien geben? Eine für Taxis, LKW und möglicherweise die Stadtreinigung und eine zweite für Privatkunden? Wie teilt sich dann der Markt auf, und welche Komponenten werden jeweils spezifisch benötigt?

Grundsätzlich handelt es sich hierbei um eine komplexe Skalierungsaufgabe, denn die Herausforderungen sind für die hypothetischen Märkte identisch.

Risiken und Chancen

Die größte Aufgabe liegt im Bereich des Rechtssystems. Denn aus Sicht eines OEMs wächst das Risikoportfolio mit dem autonomen Fahren dramatisch an. »Menschliche Fehler« im herkömmlichen Sinn gibt es dann nicht mehr. Stattdessen drohen Fehlinterpretationen, zu lange Verarbeitungs- und Reaktionszeiten oder schlicht mangelnde Komponentenverfügbarkeiten (Sensoren, Verarbeitung, Aktuatoren, Kommunikation) – all das fällt nun auf das Kraftfahrzeug zurück und gilt es entsprechend zu vermeiden.

Bei der Formulierung der Lösungsstrategien kann nicht einfach auf die Erfahrungen anderer Industrien, wie beispielsweise der Luft- oder Raumfahrt, zurückgegriffen werden. Begriffe wie Robustheit, Redundanz, Rückwirkungsfreiheit und Verfügbarkeit sind dort zwar ebenfalls formuliert, allerdings unterscheiden sie sich stark von allem, was im Kraftfahrzeug realisierbar ist.

Die vernetzten Fahrzeuge müssen umgehend auf Situationen reagieren und entsprechende Fahrmanöver ausführen
Bild 4. Die vernetzten Fahrzeuge müssen umgehend auf Situationen reagieren und entsprechende Fahrmanöver ausführen.
© shutterstock – Zapp2Photo

So ist es unwahrscheinlich, dass ein OEM jeweils zwei oder mehr Firmen mit der Entwicklung eigenständiger Hard- und Software beauftragt, wie in der Raumfahrt üblich. Ebenso unwahrscheinlich ist, dass sechs bis sieben unabhängige Rechnersysteme parallel arbeiten, wie bei SpaceX in seiner Dragon-Kapsel. Bei der Entwicklung wurde der Re-Boot eines Rechners als normaler Betriebszustand interpretiert. Auch muss ein Fahrzeug nicht einen Funktionsausfall über Tage oder Stunden hinweg kompensieren – folgerichtig können die Systeme einfacher gestaltet werden. Auf der anderen Seite stehen dem PKW auch nicht Tage oder Stunden zur Erarbeitung einer Lösung zur Verfügung, sondern, je nach Szenario, nur wenige Sekunden (Bild 4).

Wie werden die OEMs nun den Herausforderungen gerecht? Mehrere Hochleistungs-Chipsätze integrieren und die Kosten übernehmen oder weiterreichen? Eine weitere entscheidende Frage in der Elektronik-Entwicklung: Was wird der Kunde in (spätestens) drei Jahren anfragen? Welche Integrationen werden kommen? Multi-GPUs? Mehrere hochkomplexe »Fahrzeuggehirne«?

Bewältigung der Herausforderung

Mit der Frage nach den »kleinsten gemeinsamen Nenner« wurden Mitglieder der Vorentwicklung bei Yazaki beauftragt, Ideen und Konzepte zu sammeln und zu verknüpfen. Unabhängig der Informationen seitens der OEMs sollten so Erkenntnisse aus den Bereichen der Architektur, der Elektronik, als auch zum Kabelbaum und dessen Produktion zusammengetragen werden. Die Ideen und Konzepte wurden zunächst in kurzen Studien näher beschrieben und dienten als Ausgangspunkt für das Skizzieren von potenziellen Lösungsstrategien. Das übergeordnete Ziel bestand darin, die Vorlaufzeit zu verkürzen und gleichzeitig in der Konzeption selbstständig zu bleiben.
Dabei kamen interessante Ideen auf. Zum Beispiel wurde »Redundanz durch Diversität« vorgeschlagen – durch Fusion der Sensordaten aus unterschiedlichen Messverfahren überprüft ein eigenständiger »Kontra-Computer«, als quasi furchtsamer Beifahrer, die Ergebnisse des Fahrzeugführungssystems kontinuierlich auf Fehler. Im Normalbetrieb bietet das dem Endkunden einen zusätzlichen Sicherheitsfaktor, während das unabhängige System im Notfall die Funktionen des ausgefallenen Hauptsystems übernehmen kann – Redundanz mit zusätzlichem Kundennutzen, um auch die Kosten kurzfristig zu amortisieren. Bei einem Ausfall des Hauptsystems könnte so mit reduzierter Systemleistung fortgefahren werden (alles andere würde Erstfehlersicherheit bedeuten).

Können daher die Anforderungen an den Kontra-Computer reduziert werden? Möglicherweise wäre es ausreichend, stets einen »Plan B« vorzuhalten. Das Hauptsystem würde immer und fortlaufend einen kurzen Plan erzeugen, was bei einem Systemausfall zu tun wäre. Das Notsystem bildet in dem Szenario lediglich für einige Sekunden bis Minuten die Umsetzungsebene, das aber keine hoch entwickelte Situationsanalyse und Entscheidungsfindung betreiben muss – das entspricht der Vorgehensweise eines Piloten, der auch stets die nächste Notlandemöglichkeit im Auge behält. Das Konzept wurde
als »komplementäre Redundanz« bezeichnet.

Doch selbst dann besteht noch Optimierungspotenzial. Wie oben erwähnt, ist die Cloud eine Entität, die sich aus vielen Knoten in einem Netzwerk zusammensetzt. Die Knoten bieten zusätzlichen Speicherplatz, aber auch Verarbeitungskapazitäten (wie beispielsweise bei Amazon Lumberyard). Analog können bei Einsatz schneller Datenübertragungssysteme auch die Prozessoren im Fahrzeug als »lokale Cloud« betrachtet werden. Werden nun Sensorik (Eingänge) und Aktuatorik (Ausgänge) von der eigentlichen Datenverarbeitung getrennt, wird eine funktionsunabhängige Hardware-Nutzung erreicht. Der »Taktik-Manager« würde somit für einige Sekunden ein beliebiges anderes Steuergerät mitverwenden und könnte damit noch kompakter gestaltet werden.

Vielleicht ist das eine Option für die OEMs? Es ist jedenfalls ein Beispiel für Hardware-Skalierung, wobei das oben genannte Taxi eventuell noch eine zusätzliche, reale Redundanzebene besitzt.

Entwicklungsgrundlagen

Auch im Bereich der Entwicklungsmethodik ist es erforderlich, bisherige Ansätze neu zu überdenken. Insbesondere im Bereich des Kabelbaums, der sich plötzlich im Anforderungsspektrum von ASIL (Automotive Safety Integrity Level) wiederfindet, für die noch keine eigenen juristischen oder auch nur technischen Interpretationen vorliegen. Die reine Übernahme von Erfahrungen aus anderen Branchen gestaltet sich in dem Zusammenhang schwierig, da die Vergleichbarkeit beispielsweise eines Kondensators mit einer Kupferleitung nicht gegeben ist. Zwar kennt man die FIT-Raten (Failure In Time) von Halbleiter-Bauelementen, aber wie sieht das Ausfallverhalten des Fügeschritts »Crimpen« über den Zeitraum aus? Ist eine erhöhte Ausfallrate am Anfang der Lebensdauer gegeben, gefolgt von einem niedrigen Plateau bis zu einem erneuten Anstieg gemäß der aus der Halbleiterbranche bekannten »Badewannenkurve« (Bild 5)?

Die typische Failure-In-Time-Rate eines beispielhaften Halbleiter-Elements
Bild 5. Die typische Failure-In-Time-Rate eines beispielhaften Halbleiter-Elements.
© Yazaki

Wie können, ohne enormen Aufwand, verlässliche und aussagekräftige Daten generiert werden, um die FIT-Rate im Lebenszyklus zu ermitteln? Schnell wird dann unerforschtes Territorium betreten, das beispielsweise auch vor einigen Jahren die Vorentwicklung von CCA-Leitungen (Copper Clad Aluminum, kupferumhüllte Aluminiumleitungen) betraf. Um Referenzzahlen im Vergleich zu Kupfer zu erhalten, wurden damals zahlreiche Crimps/Leitungen über mehrere Wochen korrosiven und thermischen Bedingungen ausgesetzt.

Die damalige Analyse zeigte, dass CCA nach einiger Zeit Ermüdungserscheinungen aufweist – die konventionelle Kupferleitung mit Standard-Crimp hingegen nicht – obwohl der Test schätzungsweise mehrere PKW-Lebenszyklen umfasste. Wie lässt sich jedoch das Verhalten beschreiben und quantifizieren? Aussagen wie »Unsere Lösung hält ewig« stellen keine akzeptablen Ergebnisse dar.

Ähnlich verhält es sich bei der Güte des Crimp-Prozesses. In jedem Fahrzeug sind etwa 1.000 Crimpungen enthalten. Wie können die Felderfahrungen von Milliarden Vercrimpungen über Jahrzehnte hinweg in eine FIT-Rate (typischerweise angegeben in pro Milliarden Stunden) umgerechnet werden? Und ist das statthaft? Wie kann und muss demzufolge die Verkabelung als Systembestandteil in die Fehlerbaumanalyse des funktionalen Systems eingebunden werden? Welche neuen Anforderungen entstehen daraus hinsichtlich der Prozessdefinition und -überwachung? Welche Anforderungen ergeben sich für die Rückverfolgbarkeit bis hin zum Reparaturfall? Und welche für die Automatisierung? Oder kann bei der Kombination von Kupferleitungen und Standardvercrimpungen das Erfahrungswissen genutzt werden?

Die Systeme eines autonomen Fahrzeugs müssen redundant sein, was die Single Point of Failures ausschließt – auch in Bezug auf den Kabelbaum. Können also weiterhin die bewährten Strategien zum Einsatz kommen, während Systemauslegung, Architektur und Kommunikation sich immer weiterentwickeln?

Die Frage kann sicherlich noch nicht abschließend beantwortet werden. Eines ist allerdings sicher: Das autonom fahrende Auto wird nicht einfach eine Fortentwicklung heutiger Konzepte sein, sondern wird zum integralen Bestandteil einer neuen Mobilitätsumwelt werden und ganz neue Lösungs- und Produktstrategien erfordern – womöglich sogar bis in den Kabelbaum.

 

Der Autor

 

 

Prof. Dr. Götz-Roderer von der Firma Yazaki
Prof. Dr. Götz-Roderer von der Firma Yazaki.
© Yazaki

Prof. Dr. Götz Roderer

arbeitete nach seinem Studium der Physik an der Universität Würzburg seit 1996 im Bereich der Software- und Systementwicklung, zunächst bei Mecalc Pty. und anschließend bei Siemens. Von 2003 bis 2014 arbeitete er bei S-Y Systems Technologies in unterschiedlichen Positionen. Seit 2014 ist Götz Roderer als Director Advanced Engineering bei Yazaki Systems Technologies tätig und hält zusätzlich seit 2015 eine Professur an der Hochschule Landshut.

 


  1. Durch unbekanntes Terrain
  2. Neue Konzepte

Das könnte Sie auch interessieren