-
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Kraftfahrzeuges in einem automatisierten Fahrmodus mittels einer Assistenzfunktion für automatisiertes Fahren unter Berücksichtigung einer Leistungsfähigkeit der Assistenzfunktion, wobei zur Ausführung der Assistenzfunktion ein Abgleich der Leistungsfähigkeit mit einem Leistungsbedarf erfolgt. Das Verfahren ist dadurch gekennzeichnet, dass als Leistungsbedarf ein Leistungsbedarf für eine bevorstehende Fahrsituation ermittelt wird. Weiterhin ist erfindungsgemäß eine Vorrichtung vorgesehen, welche eingerichtet ist zur Ausführung des Verfahrens.
-
Stand der Technik
-
Ein Treiber derzeitiger Entwicklung bei Kraftfahrzeugen ist im Bereich der automatisierten Fahrfunktionen zu sehen. Ein sogenanntes Feature übernimmt dabei die Fahraufgabe eines Kraftfahrzeugs. Bei geringem Automatisierungslevel (bspw. SAE ≦ L2) besitzt der Fahrer die komplette Verantwortung für die Fahrzeugführungsaufgabe (Minds-On und Hands-On). Es wird dabei auch von sog. Advanced Driver Assistance System (ADAS) gesprochen. Bei höherem Automatisierungslevel (bspw. SAE > L2, d.h. L2+...L4/5) übernimmt das System stückweise immer mehr Verantwortung und der menschliche Fahrer kann über die Schritte Hands-Off; Minds-Off, Driverless aus der Führungsaufgabe genommen werden. Es kann auch vom sog. Automated Driving (AD) gesprochen werden. Der Begriff Operational Design Domain (ODD) beschreibt nach SAE J3016 die Betriebsbedingungen für die ein Assistenzsystem für automatisiertes Fahren entwickelt wurde und daher betriebssicher betrieben werden kann. Folglich ist die ODD die Design Domain eines ADAS / AD Features bezüglich der Betriebsbedingungen und der Umgebung, die vorliegen muss, damit das Feature aktiv Fahraufgaben übernehmen kann und darf. Ein Verlassen der ODD von einem ADAS / AD Feature führt somit zu nicht vertretbaren Risiken für die Insassen und Verkehrsteilnehmer.
-
Offenbarung der Erfindung
-
Vorteilhaft ermöglicht hingegen das erfindungsgemäße Verfahren ein rechtzeitiges Erkennen eines Verlassens der Operational Design Domain einer automatisierten Fahrfunktion. Durch das rechtzeitige Erkennen können bspw. Maßnahmen eingeleitet werden, um ein tatsächliches Verlassen zu verhindern. Es wird daher nicht nur die Sicherheit erhöht, sondern auch die Einsatzfähigkeit und Verfügbarkeit einer automatisierten Fahrfunktion vergrößert.
-
Ermöglicht wird dies gemäß der Erfindung durch die in den unabhängigen Patentansprüchen angegebenen Merkmale. Weitere Ausgestaltungen der Erfindung sind Gegenstand von Unteransprüchen.
-
Das erfindungsgemäße Verfahren zum Betreiben eines Kraftfahrzeuges in einem automatisierten Fahrmodus mittels einer Assistenzfunktion für automatisiertes Fahren unter Berücksichtigung einer Leistungsfähigkeit der Assistenzfunktion, wobei zur Ausführung der Assistenzfunktion ein Abgleich der Leistungsfähigkeit mit einem Leistungsbedarf erfolgt, ist dadurch gekennzeichnet, dass als Leistungsbedarf ein Leistungsbedarf für eine bevorstehende Fahrsituation ermittelt wird.
-
Hierunter kann verstanden werden, dass ein für die bevorstehende Fahrsituation geeignetes automatisiertes Fahrmanöver geplant wird. Im Anschluss wird ermittelt, welcher Leistungsbedarf zur Ausführung dieses Fahrmanövers notwendig wäre. Dieser Leistungsbedarf wird mit der im System zur Verfügung stehenden Leistungsfähigkeit der automatisierten Fahrfunktion abgeglichen. Hierdurch kann vorteilhaft bereits vor Einleitung des Fahrmanövers eruiert werden, ob das Fahrmanöver auch (komplett) ausgeführt werden kann. Ist dies nicht der Fall, übersteigt bspw. der Leistungsbedarf für die Fahrsituation die Leistungsfähigkeit des Systems, können entsprechende (auch präventive) Maßnahmen eingeleitet werden. Hierdurch wird eine Erhöhung der Sicherheit ermöglicht. Weiterhin ermöglicht die Einleitung präventiver Maßnahmen vorteilhaft eine Vermeidung eines tatsächlichen Verlassens der Leistungsfähigkeit. Dadurch erfolgt vorteilhaft eine Erhöhung der Einsatzfähigkeit, durch Aufrechterhalten der automatisierten Fahrfunktion.
-
Der Begriff „bevorstehende Fahrsituation“ kann als ein sog. „Fahrszenario“ verstanden werden. Der Begriff „Leistungsbedarf für eine bevorstehende Fahrsituation“ kann entsprechend als „Leistungsbedarf für ein Fahrszenario“ verstanden werden. Als Fahrszenario ist die mögliche Ausführung eines definierten Fahrmanövers in einer beschriebenen Fahrumgebung zu verstehen. Insbesondere sei hiervon umfasst: die Ausführung eines geplanten automatisierten Fahrmanövers in der aktuell bestehenden Fahrumgebung des Kraftfahrzeugs.
-
Unter dem Begriff „Leistungsbedarf für eine bevorstehenden Fahrsituation“ soll im Detail verstanden werden, dass sich das Fahrzeug aktuell in einer definierten und/oder ermittelbaren Fahrumgebung befindet und ein als nächstes anstehendes Fahrmanöver bewertet wird. Insbesondere ist also das jeweilige als nächstes geplante Fahrmanöver zu verstehen. Jedoch kann sich bei oder durch die Ausführung des Fahrmanövers eine Änderung der Fahrumgebung ergeben, welche selbstverständlich in vorteilhafter Weise hierbei berücksichtigt wird. Als Leistungsbedarf für die bevorstehende Fahrsituation wird in diesem Sinne also der Leistungsbedarf verstanden, welcher für das Fahrmanöver notwendig ist zur (weiteren) Ausführung des automatisierten Fahrfunktion unter Berücksichtigung der vorliegenden Umgebung des Kraftfahrzeugs. Unter dem Begriff „bevorstehende Fahrsituation“ wird also das geplante Fahrmanöver des Fahrzeugs in der bestehenden Umgebung des Fahrzeugs verstanden.
-
Der Leistungsbedarf (sog. Demand) kann im Kraftfahrzeug selbst ermittelt werden. Bspw. kann die Ermittlung des Leistungsbedarfs auf Basis von Daten der Umgebungssensorik (bspw. Videosensorik) erfolgen. Diese Daten können hierfür in graphenbasierte Datenformate umgewandelt werden, bspw. in Labeled Property Graph Daten (LPG). Aus den (umgewandelten) Daten können zur Beschreibung des Leistungsbedarfs auch graphenbasierte Datenstrukturen erstellt werden, bspw. Ontologien.
-
Die Leistungsfähigkeit (sog. Capability) kann im Fahrzeug selbst hinterlegt sein. Bspw. kann die Leistungsfähigkeit in Form sogenannter Feature-ODDs beschrieben sein. Zur Beschreibung der Leistungsfähigkeit kann ebenfalls das Datenformat LPG Verwendung finden.
-
In einer vorteilhaften Ausführungsform ist das Verfahren dadurch gekennzeichnet, dass eine Einleitung einer Reaktionsmaßnahme erfolgt, wenn ermittelt wird, dass der Leistungsbedarf für die bevorstehende Fahrsituation außerhalb der Leistungsfähigkeit der Assistenzfunktion liegt.
-
Hierunter wird verstanden, dass definierte Maßnahmen ausgeführt werden, wenn der für die Ausführung eines Fahrmanövers ermittelte Leistungsbedarf die zur Verfügung stehende Leistungsfähigkeit des Systems übersteigt. Diese Maßnahmen könnten präventiv sein oder reaktiv sein. Eine präventive Maßnahme könnte vorteilhafterweise das Ziel besitzen ein tatsächliches Verlassen der Leistungsfähigkeit zu vermeiden, bspw. durch Änderung des Fahrmanövers. Eine reaktive Maßnahme könnte das Ziel besitzen bei einem tatsächlichen Verlassen der Leistungsfähigkeit weiterhin eine ausreichend hohe Verkehrssicherheit sowie Systemsicherheit zu gewährleisten oder wiederherzustellen.
-
In einer möglichen Ausgestaltung ist das Verfahren dadurch gekennzeichnet, dass als Reaktionsmaßnahme ausgeführt wird:
- - eine Abwendungsmaßnahme, um ein Verlassen der Leistungsfähigkeit zu vermeiden; insbesondere eine Änderung des automatisierten Fahrmanövers, und/oder
- - eine Sicherheitsmaßnahme, um bei einem Verlassen der Leistungsfähigkeit eine ausreichende Verkehrssicherheit zu ermöglichen; insbesondere eine Degradierung der Assistenzfunktion für automatisiertes Fahren und/oder eine Einleitung eines Safe-Stop-Fahrmanövers und/oder eine Ausgabe einer Warnung.
-
Hierunter ist zu verstehen, dass als Maßnahme bspw. eine Änderung des Fahrmanövers hin zu einem geringeren Leistungsbedarf durchgeführt werden kann. Selbstverständlich ist auch denkbar, dass entsprechend eine Warnung an den Fahrer oder ein Abbruch der automatisierten Fahrfunktion erfolgt. Somit wird eine Erhöhung der Sicherheit ermöglicht. Weiterhin ermöglicht die Einleitung präventiver Maßnahmen vorteilhaft eine Vermeidung eines tatsächlichen Verlassens der Leistungsfähigkeit. Dadurch erfolgt vorteilhaft eine Erhöhung der Einsatzfähigkeit, durch Aufrechterhalten der automatisierten Fahrfunktion. Alternativ oder zusätzlich könnte auch als Maßnahme eine Hinzunahme externer Ressourcen durchgeführt werden, um die Leistungsfähigkeit des Systems zu erhöhen.
-
In einer bevorzugten Ausführung ist das Verfahren dadurch gekennzeichnet, dass eine Wahrscheinlichkeit dafür ermittelt wird, ob der Leistungsbedarf bei Ausführung der Assistenzfunktion in der bevorstehenden Fahrsituation die Leistungsfähigkeit übersteigen wird, wobei insbesondere bei einem Überschreiten eines Grenzwertes für diese Wahrscheinlichkeit angenommen wird, dass der Leistungsbedarf außerhalb der Leistungsfähigkeit der Assistenzfunktion liegt
-
Hierunter wird verstanden, dass eine Wahrscheinlichkeit für ein mögliches Verlassen der Leistungsfähigkeit bei weiterer Ausführung der Assistenzfunktion in der bevorstehenden Fahrsituation ermittelt wird - insbesondere bei Durchführung des geplanten Fahrmanövers. Bei einem Überschreiten eines definierten Grenzwertes für ein wahrscheinliches Verlassen der Leistungsfähigkeit wird angenommen, dass der Leistungsbedarf für die bevorstehende Fahrsituation außerhalb der Leistungsfähigkeit liegt. Entsprechend wird angenommen, dass keine abgesicherte Ausführung des geplanten Fahrmanövers erfolgen kann.
-
In einer alternativen Weiterbildung ist das Verfahren dadurch gekennzeichnet, dass zur Beschreibung des Leistungsbedarfs für die bevorstehende Fahrsituation eine graphenbasierte Datenstruktur eingesetzt werden und/oder zur Beschreibung der Leistungsfähigkeit der Assistenzfunktion eine graphenbasierte Datenstruktur eingesetzt werden.
-
Hierunter wird verstanden, dass die Leistungsfähigkeit mittels graphenbasierten Datenstrukturen beschrieben wird. Weiterhin wird hierunter verstanden, dass der Leistungsbedarf mittels graphenbasierten Datenstrukturen beschrieben wird. Entsprechend können auch sowohl ODD als auch Fahrzeugdaten im graphenbasierte Datenstrukturen und/oder Datenbanken vorliegen, bzw. verwendet werden. Als Datenformat können bspw. Labeled Property Graph (LPG) Daten Einsatz finden. Alternativ ist natürlich auch jedes andere technisch geeignete Beschreibungsformat denkbar, insbesondere Ressource Description Framework (RDF).
-
In einer vorteilhaften Ausgestaltung ist das Verfahren dadurch gekennzeichnet, dass zur Ermittlung des Leistungsbedarfs für die bevorstehende Fahrsituation eine Ontologie hinsichtlich der bevorstehenden Fahrsituation erstellt wird.
-
Hierunter wird verstanden, dass bspw. ontologische Datenbankstruktur erstellt und eingesetzt werden. Die Ontologien bzgl. dem Leistungsbedarf werden in vorteilhafter Weise basierend auf ermittelten Daten bzgl. der vorliegenden Fahrsituation erstellt.
-
In einer möglichen Ausführung ist das Verfahren dadurch gekennzeichnet, dass zur Ermittlung des Leistungsbedarfs für die bevorstehende Fahrsituation eine Beschreibung der bevorstehende Fahrsituation erfolgt, basierend auf:
- - mittels eigener Fahrzeugsensorik ermittelten Daten und/oder
- - mittels an das Fahrzeug übermittelten externen Daten.
-
Hierunter wird verstanden, dass die Ermittlung relevanter Eingangsgrößen und Daten bzgl. der aktuellen Fahrumgebung mittels Fahrzeugsensorik, bspw. Radar, Video, GPS, Sensoren, ECU, Aktuatoren erfolgt. Vorteilhafterweise werden dafür - soweit vorhanden - bereits im Kraftfahrzeug vorhandene Strukturen (d.h. Vorrichtungen) verwendet.
-
In einer bevorzugten Weiterbildung ist das Verfahren dadurch gekennzeichnet, dass zur Ermittlung des Leistungsbedarfs für die bevorstehende Fahrsituation zumindest einer der folgenden Schritte ausgeführt wird:
- - Ermittlung Rohdaten;
- - Vorverarbeitung Rohdaten;
- - Objekt-Klassifizierung;
- - Transformation vorliegender Daten in ein graphenbasiertes Datenformat, insbesondere Transformation in Labeled Property Graph (LPG);
- - Erstellung Verbindungen, insbesondere Erstellung Einzel-Ontologien und/oder Gesamt-Ontologie;
- - Speicherung Datenstruktur, insbesondere Speicherung Gesamt-Ontologie.
-
Hierunter wird insbesondere verstanden, dass eine Transformation von vorliegenden oder ermittelten Eingangsdaten, bzw. Rohdaten, bzw. klassifizierter Objekte in ein graphenbasiertes Datenformat erfolgt. Als graphenbasiertes Datenformat wird bspw. LPG verstanden. In einer alternativen Ausführungsform ist das Verfahren dadurch gekennzeichnet, dass zur Beschreibung der bevorstehenden Fahrsituation eine Umwandlung definierter Eingangsdaten in graphenbasierten Datenstrukturen erfolgt. Als graphenbasierte Datenstrukturen werden bspw. Ontologien verstanden.
-
In einer vorteilhaften Weiterbildung ist das Verfahren dadurch gekennzeichnet, dass zur Beschreibung der Leistungsfähigkeit der Assistenzfunktion eine Ontologie hinsichtlich möglicher Einsatzbedingungen der Assistenzfunktion berücksichtigt wird.
-
Hierunter wird verstanden, dass nicht nur hinsichtlich des Leistungsbedarfs, sondern auch hinsichtlich der Leistungsfähigkeit graphenbasierte Datenstrukturen eingesetzt werden. Ebenso finden auch bei der Beschreibung der Leistungsfähigkeit Ontologien Berücksichtigung. In vorteilhafter Weise können Ontologien bzgl. der Leistungsfähigkeit bereits im System hinterlegt sein. Das System kann also selbst eine graphenbasierte Beschreibung der Betriebsbedingungen und Betriebsmöglichkeiten vorhalten, so dass diese im Einzelfall nicht erzeugt werden muss, sondern aus einer Datenbank abgerufen werden kann. Eine solche Datenbank kann sich auch außerhalb des Kraftfahrzeugs befinden.
-
In einer möglichen Ausführungsform ist das Verfahren dadurch gekennzeichnet, dass zur Beschreibung der Leistungsfähigkeit der Assistenzfunktion eine Pegasus-Ontologie berücksichtigt wird, insbesondere eine Pegasus-Ontologie erweitert um einen menschlichen Faktor berücksichtigt wird.
-
Hierunter wird verstanden, dass zur Ermittlung des Leistungsbedarfs und oder der Leistungsfähigkeit eine Pegasus-Ontologie Verwendung findet. Insbesondere wird hierfür eine Pegasus-Ontologie eingesetzt, welche um einen menschlichen Faktor erweitert ist. Eine derart erweiterte Pegasus Ontologie zur Beschreibung bspw. der ODD, kann vorteilhafterweise die nachfolgenden Aspekte berücksichtigen.
- - L1: Straßen Level
- - L2: Leitinfrastruktur
- - L3: Temporäre Beeinflussung L1 & L2
- - L4: Bewegliche Objekte inkl. mögliches Verhalten derer
- - L5: Umweltbedingungen
- - L6: Digitale Informationen
- - L7: Menschlicher Fahrer des Ego-Fahrzeugs
- - Relative & absolute Position gegenüber anderen Objekten
- - Fahrmanöver
-
In einer bevorzugten Ausgestaltung ist das Verfahren dadurch gekennzeichnet, dass das Verfahren einen bidirektionalen Austausch von Daten mit einer externen Ressource, insbesondere mit einem Edge-Server und/oder Cloud-Server, umfasst, wobei insbesondere, Daten zur Ermittlung des Leistungsbedarfs und/oder Daten zur Beschreibung der Leistungsfähigkeit der Assistenzfunktion mit externen Ressourcen ausgetauscht werden und/oder wobei insbesondere der Abgleich des Leistungsbedarfs für die bevorstehende Fahrsituation mit der Leistungsfähigkeit der Assistenzfunktion mittels der externen Ressource erfolgt.
-
Hierunter wird verstanden, dass nicht nur Ressourcen berücksichtigt und eingesetzt werden können, welche fahrzeugintern sind, bspw. ein im Kraftfahrzeug verbautes Steuergerät. Vielmehr können auch (bedarfsweise) Ressourcen eingesetzt werden, welche fahrzeugextern sind. Vorteilhaft kommen hierfür Cloud Services und Cloud Technologien zum Einsatz. Bspw. können hierbei sog. performante Data Analytic Algorithmen und/oder Big Data Graph Analytics eingesetzt werden, bspw. um den Leistungsbedarf zu ermitteln oder einen Abgleich des Leistungsbedarfs mit der Leistungsfähigkeit durchzuführen.
-
Dieses Verfahren kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät implementiert sein.
-
Der hier vorgestellte Ansatz schafft ferner eine Vorrichtung, die ausgebildet ist, um die Schritte einer Variante eines hier vorgestellten Verfahrens in entsprechenden Einrichtungen durchzuführen, anzusteuern bzw. umzusetzen. Auch durch diese Ausführungsvariante der Erfindung in Form einer Vorrichtung kann die der Erfindung zugrundeliegende Aufgabe schnell und effizient gelöst werden.
-
Unter einer Vorrichtung kann vorliegend ein elektrisches Gerät verstanden werden, das Sensorsignale verarbeitet und in Abhängigkeit davon Steuer- und/oder Datensignale ausgibt. Die Vorrichtung kann eine Schnittstelle aufweisen, die hard- und/oder softwaremäßig ausgebildet sein kann. Bei einer hardwaremäßigen Ausbildung können die Schnittstellen beispielsweise Teil eines sogenannten System-ASICs sein, der verschiedenste Funktionen der Vorrichtung beinhaltet. Es ist jedoch auch möglich, dass die Schnittstellen eigene, integrierte Schaltkreise sind oder zumindest teilweise aus diskreten Bauelementen bestehen. Bei einer softwaremäßigen Ausbildung können die Schnittstellen Softwaremodule sein, die beispielsweise auf einem Mikrocontroller neben anderen Softwaremodulen vorhanden sind. Als Vorrichtung kann daher bspw. zählen: ein zentrales Steuergerät, insbesondere eine Central Operational Design Domain Computing Unit, ein Steuergerät für eine Kamera, ein Kamerasystem, sonstige Sensoren zur Erfassung der Fahrumgebung, eine Vorrichtung zum Austausch von Daten mit einer fahrzeugexternen Ressource, etc.
-
Von Vorteil ist auch ein Computerprogrammprodukt oder Computerprogramm mit Programmcode, der auf einem maschinenlesbaren Träger oder Speichermedium wie einem Halbleiterspeicher, einem Festplattenspeicher oder einem optischen Speicher gespeichert sein kann und zur Durchführung, Umsetzung und/oder Ansteuerung der Schritte des Verfahrens nach einer der vorstehend beschriebenen Ausführungsformen verwendet wird, insbesondere wenn das Programmprodukt oder Programm auf einem Computer oder einer Vorrichtung ausgeführt wird.
-
Ausfü hru ngsformen
-
Es ist darauf hinzuweisen, dass die in der Beschreibung einzeln aufgeführten Merkmale in beliebiger, technisch sinnvoller Weise miteinander kombiniert werden können und weitere Ausgestaltungen der Erfindung aufzeigen. Weitere Merkmale und Zweckmäßigkeit der Erfindung ergeben sich aus der Beschreibung von Ausführungsbeispielen anhand der beigefügten Figuren.
-
Von den Figuren zeigt:
- 1 eine schematische Einbettung der zentralen Steuerungsvorrichtung (Central Operation Design Domain Computing Unit); und
- 2 die Verfahrensschritte einer beispielhaften Ausführungsform; und
- 3 die Verfahrensschritte zur Generierung der ODD-Daten; und
- 4 eine schematische Darstellung des Ontologie-basierten Vergleichs zwischen Leistungsfähigkeit und Leistungsbedarf.
-
1 zeigt eine schematische Einbettung einer zentralen Steuerungsvorrichtung (cODDU Central Operation Design Domain Computing Unit). Hierbei ist die zentrale Steuerungsvorrichtung 2 in einem Kraftfahrzeug 1 integriert. Selbstverständlich kann die zentrale Steuerungsvorrichtung 2 auch Teil eines anderen Steuergeräts sein. Das Kraftfahrzeug 1 kann in einer automatisierten Fahrfunktion (sog. Feature) betrieben werden. Die automatisierte Fahrfunktion kann nur innerhalb definierter Grenzen betrieben werden, d.h. innerhalb der Leistungsfähigkeit 3 der Fahrfunktion (innerhalb der sog. Feature Capabilities). Die sog. Operational Design Domains (ODD) beschreiben dabei die Situationen und Bedingungen innerhalb derer die Fahrfunktion betrieben werden kann. 1 zeigt eine schematische Darstellung der Leistungsfähigkeit 3 der Fahrfunktion. Weiterhin schematisch ist in 1 eine Beschreibung 4 der Leistungsfähigkeit der Fahrfunktion dargestellt. Diese Beschreibung 4 erfolgt bspw. in Graphenstruktur. Beispielhaft hierfür sind mehrere Knotenpunkte 5 eines Labeled Property Graphs (LPG) dargestellt, inkl. deren Verbindungen. Es werden also die ODDs der Automatisierungsfeatures des Fahrzeugs als Ontologie in einem Labeled Property Graph gespeichert. Folglich wird die ODD des Features im Sinne der Feature Capabilities definiert und auf der cODDU als Ontologie abgelegt. Damit wird festgelegt in welcher ODD das Fahrzeug mit aktivem AD / ADAS Feature operieren kann bzw. darf, was wiederum als Input dient ob das Feature unter gegebenem Kontext das Manöver sicher ausführen kann.
-
Weiterhin zeigt 1 schematisch den Leistungsbedarf 13 für die bevorstehende Fahrsituation des Kraftfahrzeugs. Die aktuelle Fahrumgebung wird durch das Fahrzeug mittels unterschiedlichen Vorrichtungen erfasst. Hierzu können zählen: Sensoren 6, Aktoren 7, Steuergerät 8, sowie weitere Vorrichtungen 9 zur Erfassung relevanter Daten. Diese Daten werden an die zentrale Steuerungsvorrichtung 2 mittels unidirektionalen Informationsfluss 10 weitergeleitet. Die relevanten Roh- bzw. aufbereiteten Daten der Datenquellen (Sensoren, ECUs, Aktuatoren, Cloud) werden entweder Quellennah in LPG Daten transformiert oder beim Eintritt in die cODDU wo sie bspw. als Live LPG Ontologie gespeichert werden.
-
Zur Unterstützung der Auswertung kann sich die zentrale Steuerungsvorrichtung 2 einer externen Ressource 12 bedienen. Als externe Ressource 12 kann bspw. eine externe Datenbank oder eine externe Berechnungsvorrichtung dienen. Der Austausch der Daten zwischen zentraler Steuerungsvorrichtung 2 und externer Ressource erfolgt bspw. mittels bidirektionalem Informationsfluss 11. D.h. es gibt eine bidirektionale Verbindung zu externen Ressource, wie z.B. einem Edge oder Cloud Server, womit weitere zur ODD Departure Detection Funktion zuträglichen Daten ausgetauscht werden. Die cODDU errechnet somit für jeden Zeitpunkt eine gültige Live LPG Ontologie, die mit der hinterlegten Feature ODD abgeglichen wird. Ferner gibt es für jedes ADAS / AD Feature eine in der cODDU gespeicherte Feature Capability Liste, womit je nach notwendigem Manöver und relativer, bzw. absoluter Position zu anderen Objekten die aktuellen Feature Capabilities errechnet werden. Ferner können prädiktiv vor einem Verlassen der ODD gewarnt und Präventivmaßnahmen eingeleitet werden.
-
In 2 ist eine Darstellung der Verfahrensschritte einer Ausführungsform der Erfindung gezeigt. Hierbei erfolgt in einem ersten Schritt S1 der Start des Verfahrens, bspw. durch Aktivierung der automatisierten Fahrfunktion. In einem Schritt S2 wird das bevorstehende Fahrmanöver ermittelt, also das Fahrmanöver, welches unter Berücksichtigung der bevorstehenden Fahrsituation zur Ausführung, bzw. Weiterführung der automatisierten Fahrfunktion zu erfolgen hat. In einem Schritt S3 werden weiterhin ODD-relevante Daten ermittelt, also Daten die zur Ermittlung der Fahrsituation, bzw. des geeigneten Fahrszenarios und/oder zur Ermittlung des Leistungsbedarfs hierfür benötigt werden. In dem Schritt S4 erfolgt die Ermittlung der Fahrsituation, bzw. des Fahrszenario. Weiterhin erfolgt in diesem Schritt die Ermittlung des Leistungsbedarfs hierfür. Hierbei können selbstverständlich auch entsprechende Unsicherheiten berücksichtigt werden. In einem Schritt S5 erfolgt die Ermittlung der Leistungsfähigkeit der Assistenzfunktion. Hierbei kann bspw. auf im Fahrzeug hinterlegte Daten zurückgegriffen werden. In einem Schritt S6 erfolgt ein Datenaustausch mit einer externen Ressource. Als externe Ressource kann bspw. eine fahrzeugexterne Datenbank oder Rechenkapazität, bspw. ein Edge- oder Cloud-Rechner dienen.
-
In einem Schritt B1 wird überprüft, ob der ermittelte Leistungsbedarf für eine bevorstehende Fahrsituation, bzw. ein bestimmtes Fahrmanöver die Leistungsfähigkeit der Assistenzfunktion des ADAS / AD Features übersteigt. Selbstverständlich kann hierbei auch Wahrscheinlichkeiten zugrunde gelegt werden. Insbesondere wird überprüft, ob eine definierte Potentialschwelle überschritten wird. Ist dies nicht der Fall (N-Abzweig), wird in einem Schritt S10 das reguläre Fahrmanöver ausgeführt, d.h. das als geeignet für die bevorstehende Fahrsituation ermittelte automatisierte Fahrmanöver durchgeführt.
-
Wird die Potentialschwelle jedoch überschritten (Y-Abzweig), kann bspw. in einem weiteren Schritt B2 überprüft werden, ob auch eine Risikoschwelle überschritten ist. Ist bspw. die Risikoschwelle noch nicht überschritten (N-Abzweig), kann bspw. in einem Schritt S9 eine Änderung des geplanten Fahrmanövers vorgenommen oder zumindest analysiert werden. Ist jedoch auch die Risikoschwelle überschritten (Y-Abzweig), kann bspw. in einem nächsten Schritt B3 eine Entscheidung über eine Reaktionsmaßnahme getroffen werden. So ist bspw. in einem nachfolgenden Schritt S7 eine Feature Degradation möglich, bei welchem bestimmte automatisierte Fahrfunktionen eingestellt werden. Alternativ oder additional kann in einem Schritt S8 ein Safe-Stop-Fahrmanöver ausgeführt werden, mittels welchem das Fahrzeug automatisiert in einen sicheren Zustand gebracht wird. Ein Safe-Stop-Fahrmanöver kann bis zu mehreren Kilometern umfassen. In einem anschließenden Schritt B4 wird überprüft ob eine Weiterführung der automatischen Fahrfunktion möglich ist. Ist dies nicht der Fall (N-Abzweig) wird das Verfahren mit Schritt S11 beendet. Ist dies jedoch der Fall (Y-Abzweig) kann bspw. mit Schritt S4 der Leistungsbedarf für die nächste Fahrsituation ermittelt und analysiert werden.
-
In 3 ist eine Darstellung der Verfahrensschritte zur Generierung der ODD-Daten gezeigt. Es handelt sich also um eine mögliche technische Ausgestaltung des zuvor beschriebenen Verfahrensschritts S3 hinsichtlich Ermittlung des Leistungsbedarfs für eine bevorstehende Fahrsituation. Hierzu werden in einem ersten Teilschritt S3a Rohdaten ermittelt. Dies kann bspw. mittels einer Videokamera erfolgen. In einem weiteren Teilschritt S3b erfolgt eine Vorverarbeitung der Rohdaten. In einem nächsten Schritt BS3c wird überprüft ob klassifizierbare Objekte in den Daten ermittelbar sind. Ist dies der Fall (Y-Abzweig), folgt in einem Teilschritt S3c die Objektklassifizierung. Ist dies jedoch nicht der Fall (N-Abzweig), wird keine Klassifizierung vorgenommen. In einem nachfolgenden Schritt S3d erfolgt eine Transformation der Daten in ein graphenbasiertes Datenformat, bspw. in Labeled Property Graph Daten. In einem weiteren Teilschritt S3e erfolgt eine Erstellung einer Ontologie. Hierbei können Einzel-Ontologien sowie unter Berücksichtigung von Verknüpfungen auch Gesamt-Ontologien erstellt werden. In einem abschließenden Teilschritt S3f erfolgt die Speicherung der Ontologien.
-
In anderen Worten: Die relevanten Input ODD Daten können bspw. aus allen möglichen datengenerierenden Elementen abgeleitet werden, bspw. Kamera, Radar, Raddrehzahlsensor, Zahnstangenposition der Lenkung, GNSS, Beschleunigungssensor, Inverter, Batterie Management System, Gurtverschluss, etc. Unabhängig von der Art der Rohdatenaufbereitung (bspw. quellennah mittels ASIC versus Zonen- oder zentralem Steuergerät) werden die Rohdaten zunächst aufbereitet und je nachdem ob diese klassifiziert werden oder nicht in LPG Daten transformiert. Bspw. wird bei einem Kamerasystem was ein Objekt mit 75% Wahrscheinlichkeit als Fahrrad klassifiziert ein LPG Knoten gebildet mit dem Typ und Label Fahrrad, Wahrscheinlichkeit=75%, Zeitstempel sowie weiteren Attributen (bspw. x-y-z Position im Verlauf, ID, Höhe, Breite, ...). Aus all diesen Input ODD Daten werden die entsprechenden Knoten gebildet und für jeden Zeitstempel eine Ontologie kreiert und abgelegt. Folglich wird eine Live ODD Ontology generiert und gespeichert, womit sich auch der Verlauf des Fahrzeugs sowie des Kontexts nachvollziehen lässt.
-
4 zeigt eine schematische Darstellung des Ontologie-basierten Vergleichs zwischen Leistungsfähigkeit und Leistungsbedarf. 4 verdeutlicht dabei insbesondere das Zusammenwirken der Leistungsfähigkeit 3 der Fahrfunktion sowie des Leistungsbedarfs 13 für die bevorstehende Fahrsituation. Ergänzend zu 1 zeigt 4 wird hierbei auch eine Beschreibung 14 des Leistungsbedarfs für die Fahrsituation in Graphenstruktur gezeigt. Wie bereits zu 3 beschrieben werden die zum zentralen Steuergerät übermittelten Daten bspw. in LPG-Daten transformiert und entsprechende Ontologien für den Leistungsbedarf erstellt. Ontologie-basiert kann ein Abgleich der Leistungsfähigkeit mit dem Leistungsbedarf erfolgen.
-
In anderen Worten: Zunächst werden die relevanten ODD Daten in der cODDU verarbeitet und eine sogenannte Situation-/ Scenario Demand & Complexity errechnet. Der Demand ist eine Funktion der eingehenden relevanten Input ODD Daten. Dies kann auch als Komplexitätsgrad der Situation und des Szenarios verstanden werden in dem sich das Fahrzeug bewegt. Es wird abgeleitet welche Anforderung und Bedarf an das Feature (automatisierte Fahrfunktion) vorliegt. Parallel dazu werden unter den kurzfristig ausführbaren Manövern sowie künftig zu erwartende Manövern inkl. der Positionsdaten Feature Capabilities unter Berücksichtigung der hinterlegten Feature ODD berechnet. Letztlich folgt ein Abgleich Demand vs. Capabilities, womit in der Situation geprüft wird ob das Feature unter den Randbedingungen die gewünschten und zu erwartenden Manöver sicher umsetzen kann bzw. sich in der spezifizierten ODD, d.h. sich innerhalb der Leistungsfähigkeit befindet.
-
Ein weiteres wichtiges Element stellt die externe Kommunikation der cODDU dar, womit live für die aktuelle Position zu erwartenden Manöver bereitgestellt werden und weitere aufbereitete Live Daten ausgetauscht werden. Zudem können die Live LPG Ontologien des Fahrzeugs an den Server zur Validierung, Plausibilisierung und für Big Data Analytics geschickt werden, womit immer bessere prädiktive ODD Departure Modelle generiert werden können.
-
In 4 ist weiterhin ein Ontology Check zwischen Live LPG Ontology und der Feature ODD gezeigt. Diese Live LPG Ontology Checks können somit auch mit der Cloud ausgetauscht werden. Im Falle dass der Demand die Feature Capabilities überschreitet, kann - wie zu 2 beschrieben - entweder ein degradierter Feature Zustand eingeleitet oder ein Safe-Stop Fahrmanöver durchgeführt werden.
