Alles unter Kontrolle

Viele Fahrzeuge verfügen bereits über automatische Beleuchtung, intelligente Parkhilfen, Näherungssensoren mit Alarmfunktion und andere automatische Systeme. Für den vollständig autonomen Betrieb von Fahrzeugen oder für selbstfahrende Fahrzeuge bestehen jedoch zahlreiche technische, regulative und rechtliche Hürden. Nur wenige US-Bundesstaaten erlauben derzeit einen halbautonomen Fahrzeugbetrieb, beispielsweise mit Systemen, die die Kontrolle übernehmen, wenn der Fahrer einen Fehler macht. Hingegen sind vollautonome, fahrerlose Fahrzeuge nirgendwo zugelassen. Für die vorhersehbare Zukunft werden Fahrzeugautomatisierung und hochentwickelte Fahrerassistenzsysteme, bekannt als Advanced Driving-Assistance Systems (ADAS), die Assistenz- und Automatisierungsfunktionen bereitstellen, deren Spektrum von der vollständigen Kontrolle durch den Fahrer bis hin zur 100-prozentigen Kontrolle durch die Automatisierungstechnik reicht. Bei der Entwicklung dieser Systeme besteht eine große Herausforderung darin, die vom Fahrer oder von der Automatisierungstechnik ausgelösten Übergänge zwischen diesen verschiedenen Automatisierungsebenen zu realisieren.

Der dynamische Fahrsimulator des DLR verfügt über eine hochgradig realitätsgetreue Darstellung mit integriertem Cockpit und einem hydraulischen Bewegungssystem. Ansys

Weniger Verkehrstote durch Fahrzeugautomatisierung

Das Institut für Verkehrssystemtechnik am Deutschen Zentrum für Luft- und Raumfahrt (DLR) entwickelt in Zusammenarbeit mit führenden Fahrzeugtechnik-Anbietern (OEMs) Fahrzeugautomatisierungssysteme und ADAS zur Lösung diverser Problemstellungen. Das DLR kombiniert sein technologisches Know-how mit psychologischer und ergonomischer Forschung, um Fahrzeugautomatisierungstechnik zu entwickeln, die sich an die Fähigkeiten und Erwartungen jedes Fahrers anpassen lässt. Derzeit in der Entwicklung befindliche Systeme sehen eine Integration von Fahrer und Automatisierungstechnik zum Beispiel in der Form vor, dass die Kontrolle an den Fahrer zurückgeht, wenn die Automatisierung an ihre Grenzen gelangt. In diesem Fall muss die Mensch-Maschine-Schnittstelle (HMI – Human-Machine Interface) dem Fahrer die richtigen Informationen zur richtigen Zeit liefern, sodass er auf sichere Weise wieder die Kontrolle über das Fahrzeug übernehmen kann. Das DLR nutzt die Scade Suite und Scade Display von Ansys zur Entwicklung von HMIs in der Modellumgebung bei Nutzung vordefinierter und spezifischer Komponenten. Durch die Simulation des Verhaltens unter Verwendung des Modells lassen sich in einem frühen Stadium des Entwicklungsprozesses Fehler erkennen und beheben sowie wichtige Erkenntnisse gewinnen, um die Systemleistung schnell verbessern zu können.

Für stark automatisiertes Fahren erscheint die HMI auf dem Head-up-Display. Ansys

Die Rolle der Mensch-Maschine-Schnittstelle

Ein Beispiel für die Funktionsweise der HMI liegt vor, wenn die Automatisierungstechnik die Fahrbahnmarkierung infolge von Verschmutzungen nicht erkennen kann und die Kontrolle daher an den Fahrer zurückgeben muss. Die HMI erzeugt die akustischen, taktilen und optischen Hinweise, um den Fahrer zu veranlassen, wieder die Kontrolle zu übernehmen; die HMI überprüft auch auf verschiedene Weise, dass der Fahrer wie geplant übernommen hat, beispielsweise durch Erkennen, ob der Fahrer das Lenkrad ergriffen hat. Reagiert der Fahrer nicht, bringt die Automatisierungstechnik das Fahrzeug zu einem sicheren Halt. Im umgekehrten Fall, wenn der Fahrer das Fahrzeug steuert und die Automatisierungstechnik eine plötzliche Gefahr erkennt, kann das System eine Warnung an den Fahrer ausgeben und die Kontrolle übernehmen, um einen Umfall zu verhindern.

Die Abwicklung dieses Übergabeprozesses ist nur eine der vielen Funktionen der Mensch-Maschine-Schnittstellen, die im Zuge der Weiterentwicklung der Automatisierungstechnik ständig an Funktionalität gewinnen. Dies hat zur Folge, dass der HMI-Entwicklungsprozess immer schwieriger wird. Bei der Entwicklung von HMIs mit manuellen Codierverfahren erhielten die Entwickler bisher erst dann eine Rückmeldung, wenn der Code kompiliert war und in der teuren und komplizierten Zielhardware-Umgebung ausgeführt wurde. Änderungen an der HMI waren schwierig, denn der zuständige Entwickler konnte diese erst nach Ausführung des Codes auf dem Zielsystem überprüfen. Für jeden HMI-Entwicklungsschritt musste man in der Zielumgebung viele verschiedene Szenarien überprüfen, was den Prozess extrem langwierig machte. Änderungen an der HMI, zum Beispiel die Verschiebung eines Elements aus einer Darstellung in eine andere, erforderten einen beträchtlichen manuellen Codier- und Testaufwand.

Im Fahrsimulator lassen sich Situationen wie der automatische Wechsel der Fahrspur realitätsnah simulieren. Ansys

Übergang zur modellbasierten Entwicklung

Den Zeitaufwand für die Entwicklung und Validierung der HMI konnte man erheblich verringern, indem man den Entwicklungsprozess in Scade Suite und Scade Display verlagerte. Funktionale Anforderungen und Testfälle verknüpfte man mithilfe des Scade-Requirements-Management-Gateways mit dem Scade-Modell. Die Entwickler beim DLR verwenden heute einen modellbasierten Entwicklungsansatz, der auf der Erzeugung eines ausführbaren Modells in einer Blockschaltbild-Entwicklungsumgebung basiert und definieren die Funktionalität der HMI mithilfe von Bausteinen, die Algorithmen oder Subsysteme darstellen. Sie haben in der Scade-Umgebung eine Bibliothek mit Bausteinen für die Durchführung und Anzeige gebräuchlicher HMI-Funktionen zur Fahrzeugautomatisierung erstellt, sodass der Entwicklungsprozess weitgehend darin besteht, vorhandene Bausteine auszuwählen, anzupassen und ihre Ausgänge und Eingänge miteinander zu verschalten.

Die Entwickler simulieren das Verhalten des Modells und erhalten eine sofortige Rückmeldung über seine Leistung. Testfälle führt man in der virtuellen PC-Umgebung aus, statt in der komplizierteren und kostspieligeren Zielumgebung. So müssen die Entwickler beispielsweise für jeden neuen Code-Lauf viele hundert verschiedene Szenarien prüfen, um sicherzustellen, dass bestimmte Informationen an kritischen Stellen des Bildschirms erscheinen, zum Beispiel bei der Übergabe von der Automatisierungstechnik an den Fahrer. Wo dies früher einen langwierigen manuellen Prozess erforderlich machte, können die Entwickler des Modells heute eine automatische Routine ausführen, die jedes Szenario rasch auswertet.

Automatische Codegenerierung

Nach erfolgter Validierung des Modells erzeugt der Scade-KCG-Codegenerator den Code für die Zielumgebung und ermöglicht eine vollständige Rückverfolgung vom Modell zum generierten Code, indem er eine eindeutige 1:1-Beziehung zwischen Modell und Code herstellt. Der Code wird zunächst in verschiedenen DLR-Fahrsimulatoren ausgeführt, zuletzt im dynamischen Fahrsimulator des DLR, der über eine hochgradig realitätsgetreue Darstellung mit integriertem Cockpit und einem hydraulischen Bewegungssystem verfügt, um eine realistische Fahrumgebung zum Testen von automatisierungstechnischen Prototypen zu erzeugen. Hier können die Entwickler die Leistung der Mensch-Maschine-Schnittstelle in Fahrszenarien beurteilen, die der Realität sehr nahe kommen, beispielsweise für den Fall, dass die Kontrolle wieder an den Fahrer übergehen soll, wenn das System wegen einer Baustelle mit Umleitung an seine Grenzen gelangt. Nachdem der HMI-Betrieb im Fahrsimulator überprüft ist, generiert man den Code für das Testfahrzeug, das sich für die Systembeurteilung durch einen virtuellen Copiloten steuern lässt.

Scade Suite und Scade Display erleichtern Änderungen an der HMI zur Überprüfung verschiedener alternativer Designs und zur Erzeugung unterschiedlicher Varianten der HMI für verschiedene Fahrzeuge. Die Entwickler des DLR können die Anordnung der Elemente in den einzelnen Ansichten einfach dadurch ändern, dass sie Bausteine im Modell anders anordnen. Bisher wären dafür umfangreiche manuelle Codierungsarbeiten erforderlich gewesen. Die Scade Suite und Scade Display haben des Verfahren der HMI-Entwicklung erheblich verbessert, indem die HMI kontinuierlich getestet und validiert wird: Zuerst in der Modellphase, dann im Fahrzeugsimulator und schließlich in der Zielumgebung im Testfahrzeug, sodass sich Probleme zum frühestmöglichen Zeitpunkt erkennen und beheben lassen.

(pet)