DE102021204143A1 - Gewinnung eines Sensor-Datensatzes eines Fahrzeugs einer Fahrzeugflotte - Google Patents

Abstract

Die Rechenkapazität von mehreren Fahrzeugen (30) einer Fahrzeugflotte (9) zur Gewinnung von Sensordaten (50) soll systematisch besser genutzt werden. Dazu wird ein Verfahren zur Gewinnung eines Sensordatensatzes (70) eines Fahrzeugs (30) einer Fahrzeugflotte (9) bereitgestellt, wobei in dem Fahrzeug Sensordaten (50) mindestens eines Sensors des Fahrzeugs (30) empfangen werden. Auf einem Server (3) außerhalb des Fahrzeugs werden mehrere Trigger (10A, 10B) zum Erfassen jeweils eines Objekts oder einer Situation, von denen jeder einen Trigger-Rechenleistungswert (12), einen Trigger-Klassifizierer (13) und eine Trigger-Anforderung (14) aufweist, definiert oder bereitgestellt. Die mehreren Trigger (10A, 10B) werden an das Fahrzeug gesendet. In dem Fahrzeug erfolgt ein Zuordnen einer jeweiligen Priorität zu den mehreren Triggern (10A, 10B) anhand ihrer jeweiligen Trigger-Rechenleistungswerte (12) sowie ein Anwenden des jeweiligen Trigger-Klassifizierers (13) eines oder mehrerer der Trigger entsprechend ihrer Priorität, soweit es eine Rechenkapazität des Servers des Fahrzeugs erlaubt, auf die Sensordaten direkt oder indirekt, woraus sich ein jeweiliger Klassifizier-Qualitätswert (85) ergibt. Schließlich wird der Sensordatensatz (70) basierend auf den Sensordaten (50) von dem Fahrzeug (30) an den Server (3) außerhalb des Fahrzeugs gesendet, nur wenn der jeweilige Klassifizier-Qualitätswert (85) die Trigger-Anforderung (14) des jeweiligen Triggers erfüllt.

Description

• Die vorliegende Erfindung betrifft ein Verfahren zur Gewinnung eines Sensor-Datensatzes eines Fahrzeugs einer Fahrzeugflotte, wobei Sensor-Daten mindestens eines Sensors des Fahrzeugs in dem Fahrzeug empfangen werden. Darüber hinaus betrifft die vorliegende Erfindung ein entsprechendes System mit einer Fahrzeugflotte und einem fahrzeugexternen Server.
• Die Leistungsfähigkeit eines lernenden Algorithmus steigt, wenn die Trainingsdaten, mit denen er trainiert wird, die folgenden drei Eigenschaften besitzt: Umfangreich, abwechslungsreich und real. So bedarf es z.B. zur korrekten Identifikation und Interpretation von Stoppschildern eines großen Trainingsdatensatzes (z.B. 100.000 bis Millionen Stoppschildern), abwechslungsreichen Trainingsdaten (z.B. Bilder von Stoppschildern unter Bäumen, teils zu sehen hinter einem Fahrzeug und auch gehalten durch einen Bauarbeiter in einem aktiven oder inaktiven Status) und sie müssen aus der realen Welt stammen, um durch seltene Varianten nicht überrascht zu werden. Eine aktive Suche nach passenden Sensor-Daten mithilfe der gesamten Fahrzeugflotte, die diese Situationen in der Realität darstellen, wird „Active-Learning“ genannt.
• Dieses Beispiel zeigt, dass je größer und globaler verteilt eine eigene Daten sammelnde Flotte ist, desto besser und schneller können Daten gesammelt werden, um lernende Algorithmen zu trainieren. Insofern kann eine große Flotte die Entwicklungszeit pro Funktion im Vergleich zu einer kleinen Flotte signifikant verkürzen.
• Das Erfassen und Verarbeiten von Sensor-Daten erfordert jedoch entsprechend hohe Rechenkapazitäten. In heutigen Fahrzeugen sind Hochleistungsrechner mit entsprechenden Rechenkapazitäten - sogenannte InCar-Application-Server - zur Realisierung von modernen Assistenz bzw. autonomen Fahrfunktionen verbaut. Da die Fahrfunktionen die Hochleistungsrechner nicht durchgängig auslasten, können nicht benötigte Rechenkapazitäten bereitgestellt werden an Dritte, die Software auf den InCar-Application-Servern betreiben wollen. Hierzu zählt insbesondere der Zugriff auf die Sensor-Daten durch Active-Learning, um so neue Trainingsdaten erzeugen zu können.
• Aus der Druckschrift DE 10 2018 200 134 B3 ist ein Verfahren zum Erfassen von Trainingsdaten für ein Fahrer-Assistenzsystem bekannt. Dabei wird von einer Servereinrichtung ein Kriterium vorgegeben und an die Kraftfahrzeuge übermittelt. Diese übermitteln darauf hin bei Erfülltsein des Kriteriums mit einer jeweiligen Kamera erfasste Einzelbilder einer Umgebung des jeweiligen Kraftfahrzeugs an die Servereinrichtung. Von der Servereinrichtung wird dann aus von verschiedenen der Kraftfahrzeuge übermittelten Einzelbildern eine gemeinsame Bilderreihe zum Training des Fahrer-Assistenzsystems erzeugt.
• Darüber hinaus offenbart die Druckschrift DE 10 2017 201 226 A1 ein Verfahren zum Betrieb eines Datenauswertungssystems für Kraftfahrzeugfunktionen. Dabei werden innerhalb des Kraftfahrzeugs im Auswertevorgang Auswertungsalgorithmen des maschinellen Lernens eingesetzt.
• Zudem offenbart die Druckschrift DE 10 2013 021 867 A1 ein Verfahren zum Bereitstellen einer Funktion für ein Kraftfahrzeug, bei dem die Funktion für das Kraftfahrzeug auf einem Kontrollmodul des Kraftfahrzeugs installiert und einem örtlich begrenzten Gebiet freigeschaltet wird. Für den Fall, dass die Funktion in einem Betrieb des Kraftfahrzeugs situationsbedingt eingreift, wird einem Nutzer des Kraftfahrzeugs der Eingriff der Funktion automatisch berechnet.
• Außerdem offenbart die Druckschrift EP 3 363 706 A1 ein Verfahren zur Aktivierung einer Funktion eines Fahrzeugs. Durch eine Autorisierung mittels eines externen Servers kann eine Funktion des Fahrzeugs aktiviert werden.
• Die Aufgabe der vorliegenden Erfindung besteht darin, möglichst effizient von einer Fahrzeugflotte Daten sammeln zu können.
• Erfindungsgemäß wird diese Aufgabe gelöst durch ein Verfahren und ein System gemäß den unabhängigen Ansprüchen. Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen.
• Entsprechend der vorliegenden Erfindung wird demnach ein Verfahren zur Gewinnung eines Sensor-Datensatzes eines Fahrzeugs einer Fahrzeugflotte bereitgestellt. Ein Sensor-Datensatz ist ein abgeschlossenes Paket von Daten, die mithilfe eines Sensors des Fahrzeugs gewonnen wurden. Ein Beispiel eines solchen Sensor-Datensatzes wäre eine Video-Sequenz, die von einer Fahrzeugkamera aufgenommen wurde. Das Fahrzeug gehört zu einer Fahrzeugflotte, zu der eine Vielzahl von Fahrzeugen zusammengeschlossen sind. Beispielsweise handelt es sich dabei um alle Fahrzeuge eines Herstellers oder zumindest einen oder mehreren Typen von Fahrzeugen eines Herstellers.
• Bei dem Verfahren werden in dem Fahrzeug Sensor-Daten mindestens eines Sensors des Fahrzeugs empfangen. Beispielsweise erfolgt dieses Empfangen der Sensor-Daten durch eine entsprechende Datenverarbeitungseinrichtung des Fahrzeugs. Es können Daten von mehreren Sensoren wie Kameras, Radareinrichtungen, Ultraschallsensoren und dergleichen von der Datenverarbeitungseinrichtung empfangen werden.
• Auf einem Server außerhalb des Fahrzeugs werden mehrere Trigger zum Erfassen jeweils eines Objekts oder einer Situation definiert beziehungsweise bereitgestellt. Unter dem Trigger kann hier eine Auslösefunktion für die Erfassung beziehungsweise eine bedingte Erfassungsfunktion verstanden werden. Mit einer solchen Erfassungsfunktion soll ein Objekt wie etwa ein Stoppschild oder eine Situation, wie etwa das Erkennen von Rechts vor Links, erfasst werden. Ein solcher Trigger zeichnet sich durch einen Rechenleistungswert, einen Trigger-Klassifizierer und eine Trigger-Anforderung aus. Der Trigger-Rechenleistungswert ist eine Wertangabe für eine Rechenleistung (z.B. Wert für eine Rechenoperation). Dabei kann es sich beispielsweise um einen Prioritätswert handeln oder beispielsweise auch um einen Geldwert, mit dem die jeweilige Rechenleistung bewertet wird. So kann beispielsweise für eine gewünschte Rechenleistung eine hohe Priorität oder ein hoher Geldwert festgelegt werden. Bei dem Trigger-Klassifizierer handelt es sich um einen Klassifikationsalgorithmus, mit dem die Sensordaten klassifiziert werden. Vorzugsweise wird ein solcher Trigger-Klassifizierer durch einen lernenden Algorithmus realisiert. Bei der Trigger-Anforderung handelt es sich um eine Bedingung, mit der das Klassifizierergebnis bewertet wird, um die Sensor-Daten an den Server außerhalb des Fahrzeugs zu übertragen.
• Mehrere solcher Trigger werden an das Fahrzeug gesendet. Von welchen Einheiten die Trigger an das Fahrzeug gesendet werden, ist zweitrangig. Es können die Trigger von den Server auf das Fahrzeug übertragen werden. Generell können die Trigger aber auch von anderen Einheiten (z. B. auch anderen Fahrzeugen) auf das Fahrzeug übertragen werden.
• In dem Fahrzeug erfolgt nun eine Zuordnen einer jeweiligen Priorität zu den mehreren Triggern anhand ihrer jeweiligen Trigger-Rechenleistungswerte. Beispielsweise ist die Priorität eines Triggers höher als die eines anderen Triggers, wenn sein Trigger-Rechenleistungswert höher ist. Wenn es sich bei dem Trigger-Rechenleistungswert bereits um einen Prioritätswert handelt, erübrigt sich dieser Zuordnungsschritt beziehungsweise erfolgt dieser Zuordnungsschritt beispielsweise durch das Auslesen dieses Triggers. Ist der Trigger-Rechenleistungswert hingegen beispielsweise ein Geldwert, (z.B. 1,1 € pro Einheit Rechenoperationen (ERO) so wird demjenigen Trigger eine höhere Priorität zugeordnet, der z.B. einen höheren Geldwert pro Rechenoperation darstellt.
• Nun erfolgt ein Anwenden des jeweiligen Trigger-Klassifizierers eines oder mehrerer der Trigger entsprechend ihrer Priorität, soweit es eine Rechenkapazität des Servers des Fahrzeugs erlaubt, auf die Sensor-Daten direkt oder indirekt. Dies bedeutet, dass der Trigger-Klassifizierers mit der höchsten Priorität zuerst angewandt wird und der Trigger-Klassifizierer eines Triggers mit der zweithöchsten Priorität erst danach, wenn die Rechenkapazität des Servers nicht das Anwenden beider Trigger-Klassifizierer gleichzeitig erlaubt. Gegebenenfalls kann jedoch ein Trigger-Klassifizierer eines dritten Triggers gegenüber dem zweiten Trigger vorgezogen werden, wenn es beispielsweise im Rahmen der Rechenkapazität möglich ist, dass der erste Trigger und der dritte Trigger gemeinsam abgearbeitet werden. Auf jeden Fall erfolgt im Rahmen der Rechenkapazität des Servers das Abarbeiten der Trigger entsprechend ihrer Priorität. Dabei kann der jeweilige Trigger-Klassifizierer direkt oder indirekt auf die Sensor-Daten angewandt werden. Bei indirekter Anwendung kann vorher eine entsprechende Vorverarbeitung erfolgen. Als Resultat bei der Anwendung eines jeweiligen Trigger-Klassifizierers ergibt sich ein jeweiliger Klassifizier-Qualitätswert. Dieser Klassifizier-Qualitätswert gibt Aussage über die Qualität der Klassifizierung. Je höher beispielsweise dieser Klassifizier-Qualitätswert ist, desto höher ist die Wahrscheinlichkeit, dass die Sensor-Daten tatsächlich in eine bestimmte Klasse fallen.
• Schließlich erfolgt ein Senden des Sensor-Datensatzes basierend auf den Sensor-Daten von dem Fahrzeug an den Server außerhalb des Fahrzeugs, aber nur wenn der jeweilige Klassifizier-Qualitätswert die Trigger-Anforderung des jeweiligen Triggers erfüllt. Der Sensor-Datensatz wird also beispielsweise nur dann an den fahrzeugexternen Server übertragen, wenn das Klassifikationsergebnis einen hohen Wert, d. h. eine hohe Qualität besitzt. So kann beispielsweise die Trigger-Anforderung bei 100 liegen und nur wenn das Klassifikationsergebnis, d. h. der Klassifizier-Qualitätswert über 100 liegt, wird der Sensor-Datensatz an den fahrzeugexternen Server übertragen. Auf diese Weise kann sichergestellt werden, dass hochqualitative Sensor-Daten, beispielsweise für die Allgemeinheit beziehungsweise für die Fahrzeugflotte bereitgestellt werden.
• Bei einer vorteilhaften Ausführungsform ist vorgesehen, dass jeder Trigger jeweils eine Trigger-Bedingung aufweist und das Anwenden des jeweiligen Trigger-Klassifizierers nur unter der Bedingung erfolgt, dass die Sensordaten direkt oder indirekt die jeweilige Trigger-Bedingung erfüllen. Die Trigger-Bedingung definiert also, unter welcher Bedingung der Trigger überhaupt angewendet werden soll. Beispielsweise lautet die Trigger-Bedingung, dass der Trigger nur bei deutschen Fahrzeugen angewandt werden soll. Eine andere Trigger-Bedingung kann lauten, dass der Trigger nur bei einem vorbestimmten Fahrzeugtyp Anwendung finden soll. Die Sensordaten können die Trigger-Bedingung direkt, d.h. unverarbeitet erfüllen. Alternativ können die Sensordaten auch vorverarbeitet werden und erst nach der Vorverarbeitung wird geprüft, ob die Trigger-Bedingung erfüllt ist. In diesem Fall erfüllen die Sensor-Daten die Trigger-Bedingungen indirekt.
• Bei einer weiteren Ausführungsform kann vorgesehen sein, dass die Objekte, deren Erfassung mit den mehreren Triggern erfolgen soll, vorgegebene Ereignisse oder Gegenstände auf oder an einer Fahrbahn sind. Bei den Objekten kann es sich beispielsweise um Verkehrsschilder, Ampeln oder dergleichen handeln. Diese befinden sich an oder auf der Fahrbahn und sind somit durch die Sensoren des Fahrzeugs erfassbar. Bei den Ereignissen kann es sich um Situationen und Events bzw. Gegenständen in Zuständen handeln (z.B. Hund läuft Richtung Straße, Fahrzeugtür wird geöffnet).
• Vorzugsweise werden die mehreren Trigger vom Server an mindestens ein weiteres Fahrzeug geschickt, wo sie wie in dem ersten Fahrzeug eingesetzt werden. Dies bedeutet, dass die mehreren Trigger nicht nur an ein einziges Fahrzeug, sondern an mehrere Fahrzeuge beziehungsweise alle Fahrzeuge einer Fahrzeugflotte geschickt werden. Auf diese Weise ist es möglich, dass die gesamte Rechenkapazität aller Fahrzeuge der Fahrzeugflotte oder zumindest einiger der Fahrzeuge der Fahrzeugflotte ausgenutzt wird, um die Daten zu erfassen. In jedem Fahrzeug werden dann die erhaltenden Trigger entsprechend ihrer Trigger-Bedingungen eingesetzt.
• Bei einem weiteren Ausführungsbeispiel beinhaltet einer der mehreren Trigger eine Wertgrenze und das Anwenden des jeweiligen Trigger-Klassifizierers wird nur solange durchgeführt, bis eine in dem Fahrzeug in Bezug auf den jeweiligen Trigger erbrachte Rechenleistung multipliziert mit dem Rechenleistungswert noch unterhalb der Wertgrenze liegt. Natürlich kann vorgesehen sein, dass nicht nur einer, sondern mehrere oder alle Trigger eine entsprechende, gegebenenfalls individuelle Wertgrenze beinhalten. Die Rechenleistung kann beispielsweise in Rechenoperationen gemessen werden. Der Rechenleistungswert entspricht beispielsweise der Relation, welche Priorität beziehungsweise welcher Geldwert einer oder einer Vielzahl an Rechenoperationen zugeordnet werden kann. Damit ergibt das Produkt von Rechenleistung und Rechenleistungswert einen Wert (z. B. Prioritätswert, Kostenfaktor oder Geldwert) für die erbrachte Rechenleistung. Falls dieser Wert für die erbrachte Rechenleistung die genannte Wertgrenze des Triggers übersteigt, wird der Trigger beziehungsweise der Trigger-Klassifizierer nicht mehr ausgeführt. Dies bedeutet, dass der Trigger nur solange arbeitet, bis z.B. die Kosten unterhalb einer bestimmten Vorgabe bleiben.
• In einem weiteren Ausführungsbeispiel kann vorgesehen sein, dass einer der mehreren Trigger einen Trigger-Zeitraum beinhaltet und der Trigger-Klassifizierer nur in dem Trigger-Zeitraum angewendet wird. Der Trigger-Zeitraum ist üblicherweise durch einen Beginn und ein Ende gekennzeichnet. Gegebenenfalls kann der Zeitraum aber auch sofort beginnen, so dass der Trigger-Zeitraum durch einen Ende-Zeitpunkt ausreichend gekennzeichnet ist. Außerhalb des Trigger-Zeitraums wird der Trigger-Klassifizierer beziehungsweise der Trigger nicht mehr angewendet. So kann beispielsweise vorgesehen sein, dass der Trigger nur ein halbes Jahr in den Monaten von Januar bis Juni angewendet wird. In einem alternativen Beispiel kann vorgesehen sein, dass der Trigger-Zeitraum beispielsweise drei Monate läuft. Bei einer weiteren Alternative kann ein fester Endzeitpunkt, wie z. B. 31. Dezember, in dem Trigger enthalten sein, um den Zeitraum zu definieren. Auf diese Weise lässt sich das Ende der Datenerfassung in der Fahrzeugflotte steuern.
• Des Weiteren kann mindestens einer der mehreren Trigger ein Trigger-Zieldatenformat beinhalten, das einen Typ, einen Verarbeitungsgrad und/oder ein Format des von dem Fahrzeug an den Server übermittelten Sensor-Datensatzes angibt, wobei der Sensor-Datensatz in dem Trigger-Zieldatenformat gesendet wird. Durch das Zieldatenformat kann angegeben werden, welches Format die an den Server zu übertragenden Daten haben sollen. So kann beispielsweise mit einer Typangabe geregelt werden, dass nur Video-Daten durch den Trigger erfasst werden. Gegebenenfalls kann mit dem Zieldatenformat aber auch der Verarbeitungsgrad der Sensordaten festgelegt werden. Beispielsweise sollen die Sensordaten nur nach einer Fourier-Transformation im Spektralbereich übertragen werden. Mit dem Verarbeitungsgrad kann aber auch bestimmt werden, dass beispielsweise eine gewünschte Filterung durchgeführt wird. Des Weiteren kann das Zieldatenformat dazu genutzt werden, um das tatsächliche Format der zu übertragenen Daten festzulegen. Auf diese Weise kann beispielsweise der Header eines Datensatzes oder die Anzahl an Datenblöcken in einem Datensatz vorgegeben werden.
• Entsprechend einem weiteren Ausführungsbeispiel kann vorgesehen sein, dass mindestens einer der mehreren Trigger einen Trigger-Bearbeitungszeitpunkt beinhaltet, der einen Zeitpunkt definiert, zu dem der Trigger-Klassifizierer anzuwenden ist, und das Verfahren mit dem Trigger-Bearbeitungszeitpunkt gesteuert wird. Dies bedeutet, dass von vornherein festgelegt werden kann, dass der Klassifizierer beispielsweise eine halbe Stunde vor dem Sonnenuntergang anzuwenden. So sucht ein Trigger z.B. nach Videosequenzen von Tunnelausfahrten bei niedrig stehender, blendender Sonne. Da diese Situation häufig zu Fehler bei der Klassifikation von Straßenmarkierungen führt. Ein anderes Beispiel wären Schulkilder mit großen Tornistern, die aufgrund der veränderten Silhouette, insbesondere bei Bildern von hinten, mit einem erhöhten Risiko nicht als Menschen klassifiziert werden könnten, wenn der Algorithmus nicht genau mit diesen Bildern vorab trainiert wurde. Die Trigger für die Schulkinder mit Tornistern könnte auf den Zeitraum 7:00 - 8:00 begrenzt bzw. bevorzugt angewendet werden. Gegebenenfalls kann dann zusätzlich mit dem Trigger-Zeitraum festgelegt werden, wie lange nach dem Trigger-Bearbeitungszeitpunkt der Trigger-Klassifizierer angewendet werden soll. Gegebenenfalls werden die Sensordaten entsprechend lange in dem Fahrzeug zwischengespeichert. Der Trigger-Zeitpunkt kann eine relative Angabe (z. B. „in einem Tag“) oder eine absolute Zeitangabe (z. B. „um 12:00 Uhr“) beinhalten. In jedem Fall wird dadurch der Start-Zeitpunkt oder der Endzeitpunkt der Trigger-Bearbeitung festgelegt. Auf diese Weise können Rechenkapazitäten der Fahrzeuge gegebenenfalls besser ausgenutzt werden. So ist es eventuell günstig, wenn die Bearbeitungszeitpunkte in der Nacht gewählt werden, wenn die meisten Fahrzeuge nicht in Betrieb sind.
• In einem weiteren Ausführungsbeispiel ist vorgesehen, dass mindestens einer der mehreren Trigger eine Zieldatenmenge beinhaltet, mit der eine Menge von den Sensordatensätze definiert ist, die von der Fahrzeugflotte zu gewinnen ist, und das Verfahren beendet wird, wenn die Zieldatenmenge erreicht ist. In der Regel kann eine Menge von Sensor-Daten vorgegeben werden, mit der eine ausreichende Qualität z. B. beim Anlernen eines Algorithmus erreicht werden kann. Beispielsweise reicht es für einen Algorithmus, der ein Stoppschild erkennen soll, dass 100.000 Bilder beziehungsweise Video-Sequenzen als Sensordaten zur Verfügung gestellt werden. Falls diese Vieldatenmenge erreicht ist, wird der Trigger bzw. Trigger-Klassifizierer nicht mehr angewendet.
• Bei einer besonders bevorzugten Ausführungsform wird in dem Fahrzeug ein lernender Algorithmus auf die Sensordaten angewendet, woraus sich dann der jeweilige Klassifizier-Qualitätswert ergibt, wobei der jeweilige Trigger-Klassifizierer z.B. auf ein Zwischenergebnis des lernenden Algorithmus angewendet wird. Ein derartiger lernender Algorithmus kann auf einem neuronalen Netzwerk basieren. Alternativ kann er aber auch auf Vektormaschinen oder dergleichen basieren. Durch einen derartigen selbstlernenden Algorithmus kann eine hohe Klassifizierungsgüte erreicht werden.
• Die oben genannte Aufgabe wird erfindungsgemäß auch gelöst durch ein System mit einer Fahrzeugflotte aus mehreren Fahrzeugen und einem fahrzeugexternen Server zur Durchführung eines oben beschriebenen Verfahrens. Die im Zusammenhang mit dem erfindungsgemäßen Verfahren beschriebenen Ausführungsvarianten und Vorteile gelten sinngemäß auch für das erfindungsgemäße System. Dieses System enthält entsprechende Mittel, um die jeweiligen Verfahrensschritte ausführen zu können.
• Zu der Erfindung gehören auch Weiterbildungen des erfindungsgemäßen Verfahrens, die Merkmale aufweisen, wie sie bereits im Zusammenhang mit den Weiterbildungen des erfindungsgemäßen Kraftfahrzeugs beschrieben worden sind. Aus diesem Grund sind die entsprechenden Weiterbildungen des erfindungsgemäßen Verfahrens hier nicht noch einmal beschrieben.
• Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen.
• Die vorliegende Erfindung wird nun anhand der beigefügten Zeichnungen näher erläutert, in denen zeigen:
• 1 Ein Flussdiagramm für eine OTA-Aktualisierung (Over The Air) einer Fahrzeugflotte und
• 2 Ein Datenflussdiagramm zur Gewinnung von Sensordaten für die Erzeugung von Trainingsdaten für ein autonomes Fahrsystem durch aktives Lernen.
• Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsbeispiele der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden und damit auch einzeln oder in einer anderen als der gezeigten Kombination als Bestandteil der Erfindung anzusehen sind. Des Weiteren sind die beschriebenen Ausführungsbeispiele auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
• In den Figuren sind funktionsgleiche Elemente jeweils mit denselben Bezugszeichen versehen.
• Die nachfolgend geschilderten Ausführungsbeispiele stellen bevorzugte Ausführungsform der vorliegenden Erfindung dar. Die vorliegende Erfindung ist auf die Verteilung von Rechenkapazitäten unter den einzelnen Akteuren fokussiert, die mithilfe von aktiven Lernen Sensordaten durch die Fahrzeuge sammeln wollen. Im Detail werden für das aktive Lernen die Systeme des Fahrerassistenzsystems verwendet. Dabei erheben die Fahrzeug-Sensoren (Kamera, Radar und so weiter) für das Fahrer-Assistenzsystem Sensor-Daten. Diese werden nach einer Vorverarbeitung in einen lernenden Algorithmus, beispielsweise ein „deep learning neuronal system“, gespeist. Auf Basis von dessen Output steuert das sogenannte vehicle control-module (Fahrzeug-Steuermodul) das Fahrzeug (u.a. Beschleunigung, Lenkwinkel).
• Zum „Auffinden von Sensor-Daten” (z. B. Bilder von Stoppschildern) im Rahmen des active-learning (aktives Lernen) werden sogenannte Trigger-Klassifizierer auf Zwischenergebnisse des Lernenden Algorithmus angewendet und dabei ein sogenannter Klassifizier-Qualitätswert (classifier-Score) berechnet. Diese bestimmten die Wahrscheinlichkeit, ob die Sensordaten z.B. ein Stoppschild repräsentieren. Falls der Klassifizier-Qualitätswert über einem Schwellwert liegt, werden die Sensordaten nach einer Verarbeitung in einem Post-Processing-Modul über eine Netzwerkschnittstelle des Fahrzeugs an einen Server außerhalb des Fahrzeugs zur weiteren Verarbeitung übermittelt. Bei der weiteren Verarbeitung werden Sensor-Daten gelabelt beziehungsweise gekennzeichnet, um sie so später als Trainingsdaten für lernende Algorithmen (z. B. zur Erkennung von Stoppschildern) zu verwenden.
• Das technische Problem kann insbesondere darin liegen, dass die verfügbaren Rechenkapazitäten nicht genügen, um alle von unterschiedlichen Akteuren (Personen beziehungsweise Unternehmen, die Daten erfassen wollen) stammenden Trigger-Klassifizierer durchzuführen. Daher bedarf es gegebenenfalls einer effizienten und effektiven Zuordnung, Preisfindung und späteren Preisbildung von Rechenkapazitäten für die in Konkurrenz um Rechenleistung stehenden Trigger-Klassifizierer der einzelnen Akteure. Dies führt dazu, dass Trigger-Klassifizierer nur dann angewendet werden, wenn die Wahrscheinlichkeit, einen relevanten Sensordatensatz zu erzeugen, am höchsten ist.
• Bekannte Systeme zur Gewinnung von Trainingsdaten (z. B. WO 2020/056331 A1 ) betrachten nicht die Verteilung der Rechenkapazitäten in den Fahrzeugen unter konkurrierenden Akteuren, die Sensor-Daten für die Erzeugung von Trainingsdaten sammeln wollen. Außerdem bieten sie nicht die Möglichkeiten, eine Trigger-Klassifizierer bei ihrer Anwendung zu priorisieren beziehungsweise sie in den Wettbewerb zu einander zu stellen. Daraus ergibt sich, dass die Entwickler die Anzahl an gleichzeitig auf dem Fahrzeug laufenden Trigger-Klassifizierer eigenständig begrenzen müssen.
• Zudem besitzen diese bekannten Systeme keinen Mechanismus, Trigger-Klassifizierer, deren Trigger-Bedingung gehäuft der aktuellen Situation entsprechen und damit durchgeführt werden, aber dann keine relevanten Sensor-Daten identifizieren, zu sanktionieren beziehungsweise Trigger-Klassifizierer mit guter Trigger-Bedingung zu fördern. Die Folge ist, dass Rechenkapazität von „schlecht“ definierten Trigger-Klassisfizierern in Anspruch genommen wird, die von „besser“ definierten Trigger-Klassifizierern effizienter hätten genutzt werden können.
• Entsprechend der Fahrsituation schwankt die Wahrscheinlichkeit, relevante Sensor-Daten für die Erzeugung von Trainingsdaten identifizieren zu können, signifikant. Gerade in Situationen, in denen relevante Trainingsdaten identifiziert werden können, bedarf es einer Priorisierung einzelner Klassifizierer, um das System nicht zu überlasten. Ein entsprechender Mechanismus wäre, den Preis für die Rechenoperationen entsprechend der Wahrscheinlichkeit, einen Trainingsdatensatz zu gewinnen, dynamisch zu bestimmen.
• In einem konkreten Beispiel soll nun ein Verfahren und ein Computersystem zur Gewinnung und gegebenenfalls auch zur Abrechnung von Sensor-Daten zur Erzeugung von Trainingsdaten für Assistenzsysteme beziehungsweise autonome Fahrsysteme per active-Learning bereitgestellt werden.
• Hierzu ist in 1 ein Flussdiagramm zur Versorgung einer Fahrzeugflotte 9 mit aktuellen Trigger-Daten dargestellt. Über eine Applikation 1 verwaltet ein Akteur 2A beziehungsweise 2B seine Gewinnung von Trainingsdaten für ein Fahrer-Assistenzsystem (FAS) oder ein hochautomatisiertes Fahrsystem (HAF) beispielsweise mithilfe von active-Learning. Die Applikation 1 läuft auf einem Server 3 außerhalb des Fahrzeugs und ermöglicht durch API-Schnittstellen 4 (Application Programing Interface) und Datenbanken 5 deren Einbindung in weitere Systeme 6. Die weiteren Systeme 6 können zur Automatisierung weiterer Prozessschritte dienen. Ein Beispiel wäre ein System eines Labeling-Dienstleisters über welches die gewonnenen Sensor-Daten 50 (vergl. 2) und danach als Trainingsdaten verwendet werden können.
• Die Applikation 1 gibt dem Akteur 2A beziehungsweise 2B die Möglichkeit, seine Trigger 10 10A beziehungsweise 10B zur Gewinnung von Sensor-Daten 50 zur Erzeugung von Trainingsdaten (z. B. für die Stoppschilderkennung) bestehend aus Trigger-Bedingung 11, Trigger-Rechenleistungswert 12 (gegebenenfalls Auktionsgebot), Trigger-Klassifizierer 13, Trigger-Anforderung 14, Trigger-Wertgrenze 15 (z. B. Budget), Trigger-Zeitraum 16, Trigger-Zieldatenformat 17, Trigger-Bearbeitungszeitpunkt 18 und Trigger-Zieldatenmenge 19 für die Fahrzeugflotte 9 zu definieren. Die Applikation 1 verteilt die Trigger 10A beziehungsweise 10B der einzelnen Akteure 2A beziehungsweise 2B auf die Fahrzeugflotte 9, um diese effizient und effektiv auszulasten.
• Hierbei definiert die Trigger-Bedingung 11 eine jeweilige Bedingung, unter der der Trigger-Klassifizierer 13 angewendet wird beziehungsweise unter der der Trigger 10A beziehungsweise 10B an einer Auktion zur Anwendung des Trigger-Klassifizierers 13 im Auktions-Modul 56 teilnehmen soll. Der Trigger-Rechenleistungswert 12 (z. B. Auktionsgebot) definiert das Maximal-Gebot (z. B. Prioritätswert oder Geldwert) pro Rechenoperation bei der Gewinnung von Sensor-Daten 50 zur späteren Erzeugung von Trainingsdaten durch die Anwendung des Trigger-Klassifizierers 13. Der Trigger-Klassifizierer 13 ist beispielsweise ein lernender Algorithmus 53 wie etwa eine Support Vector Maschine oder ein neuronales Netz, welcher mit einem initialen Trainingsdatensatz für den jeweiligen Einsatzzweck (z. B. StoppschildErkennung) trainiert wurde. Er wird durch das Trigger-Klassifizierer-Modul 57 auf Sensor-Daten 50 beziehungsweise auf die Zwischenergebnisse eines lernenden Algorithmus 54 angewendet, um so Sensor-Datensätze 50 für potenzielle Trainingsdatensätze zu identifizieren. Die Trigger-Anforderung definiert beispielsweise den minimalen Wert eines normierten Klassifizier-Qualitätswert 85 bei dem ein Sensor-Datensatz zu speichern und zu übertragen ist. Das Trigger-Budget 15 definiert das durch den Akteur 2A beziehungsweise 2B festgelegte Budget, welches der Akteur 2B maximal bereit ist, für die Gewinnung von Sensor-Daten zur späteren Erzeugung von Trainingsdaten mit einem Trigger 10A, 10 B in einem definierten Zeitraum auszugeben. Der Trigger-Zeitraum 16 definiert den Zeitraum, in dem der Trigger 10A, 10 B aktiv sein soll.
• Das Trigger-Zieldatenformat 17 definiert beispielsweise den Datenstandard, den Verarbeitungsgrad, den Typ der Sensor-Daten (z.B. Video-Sequenz, Radar, Ultraschall, Bildausschnitte) 50, die durch den Trigger 10A, 10B über die Fahrzeugflotte 9 gewonnen werden und dem Akteur 2A, 2B bereitgestellt werden sollen. Der Trigger-Bearbeitungszeitpunkt 18 definiert, wann der Trigger-Klassifizierer 13 anzuwenden ist. Dies variiert beispielsweise zwischen „Sofort“ und „Innerhalb von mehreren Tagen“, wobei die entsprechenden Zwischenergebnisse des lernenden Algorithmus 54 und die Sensor-Daten 50 auf einem Speichermedium 60 auf dem In-Car-Application Server (fahrzeuginterner Server) 34 für die Anwendung des Trigger-Klassifizierers gespeichert werden. Hierdurch kann die Verarbeitung des Trigger-Klassifizierers 13 auf einen Zeitraum verschoben werden, in dem andere Systeme weniger Rechenkapazität benötigen (z. B. Fahrzeugstillstand, Parken, leere Autobahn, etc.).
• Die Trigger-Zieldatenmenge 19 definiert die Menge an Sensor-Datensätzen 70, die maximal durch den Trigger 10 über die Fahrzeugflotte 9 gewonnen werden sollen.
• Die Applikation 1 stellt dem Akteur 2A, 2B die entsprechend den definierten Trigger 10 durch die Fahrzeuge gewonnenen Sensor-Daten 50 in einem Sensor-Datensatz 70 gegebenenfalls inklusive weiterer Metadaten 80 bereit.
• Die Fahrzeuge 30 der Fahrzeugflotte 9 sind vorzugsweise mit Fahrzeugsensoren für das Fahrer-Assistenzsystem 32 (Kamera, Lidar, Radar, Ultraschallsensoren) ausgestattet, die in unterschiedliche Richtungen gerichtet sein können. Die Fahrzeuge können außerdem weitere Systeme zur Erfassung und Bereitstellung von Daten zum Fahrzeug-Betrieb und/oder zur Kontrolle und/oder zur Umwelt, Topografien und/oder GPS 33 aufweisen. Außerdem kann in einem Fahrzeug ein Vorverarbeitungsmodul 51, welches mit Sensor-Daten 50 aus den Fahrzeug-Sensoren 32 für das Fahrer-Assistenzsystem gespeist wird, beispielsweise ein Bildverarbeitungsprozessor aufweisen, um vorverarbeitete Sensor-Daten 52 zu erzeugen. Außerdem kann das Fahrzeug einen lernenden Algorithmus aufweisen, welcher mit den vorverarbeiteten Sensor-Daten 52 aus dem Vorverarbeitungsmodul 51 gespeist wird. Der lernende Algorithmus 53 umfasst beispielsweise mehrere Schichten, bestehend aus einer Eingabeschicht, Zwischenschichten und einer Ausgabeschicht. Der lernenden Algorithmus 53 kann auch konvolutionäre und Pooling-Schichten umfassen. Hierbei kann das Fahrzeug mit dem bereits erwähnten fahrzeuginternen Server 34 ausgestattet sein, auf welchem u.a. der lernende Algorithmus 53 läuft.
• Teil des Fahrzeugs kann außerdem ein Fahrzeugsteuermodul 40 sein, welches durch den Ausgang des lernenden Algorithmus 53 gespeist wird und das Fahrzeug 30 steuert.
• Weitere Module 55 bis 59 verarbeiten beispielsweise die Zwischenergebnisse 54 des lernenden Algorithmus 53 weiter. So wird beispielsweise ein Trigger-Filter-Modul 55 mit Zwischenergebnissen des lernenden Algorithmus gespeist und es wählt die Trigger 10A, 10B aus, die an der Auktion zur Durchführung ihres Trigger-Klassifizierers 13 im Auktionsmodul teilnehmen dürfen. Damit begrenzt das Trigger-Filter-Modul 55 Bedingungen, unter welchen der Trigger 10A, 10B an einer Auktion zur Durchführung des Trigger-Klassifizierers teilnimmt. Diese Zwischenergebnisse 54 des lernenden Algorithmus 53 können z.B. auf der Straße, Kreuzungen oder Straßenschilder repräsentieren. Das Trigger-Filter-Modul 55 berücksichtigt gegebenenfalls auch Daten aus weiteren Fahrzeugsystemen wie GPS 33. Das Trigger-Filter-Modul 55 läuft auf dem fahrzeuginternen Server 34.
• Das Auktions-Modul 56 wird mit Triggern 10A, 10B gespeist, die durch das Trigger-Filter-Modul 55 ausgewählt wurden. Das Auktionsmodul 56 wählt dabei auf Basis der einzelnen Trigger-Rechenleistungswerte 12 (z.B. Trigger-Aktionsgebote) und Daten aus der jeweiligen Trigger-Statistik 100 die Trigger 10A, 10B aus, deren Trigger-Klassifizierer 13 im Klassifizier-Trigger-Modul 57 anzuwenden sind. Bei der Auswahl berücksichtigt das Auktions-Modul 56 darüber hinaus die auf dem fahrzeuginternen Server 34 zur Verfügung stehende Rechenkapazität 65.
• In der Trigger-Statistik 100 werden z.B. folgende Daten zu den Triggern 10A, 10B beziehungsweise deren Trigger-Klassifizierer 13 gespeichert:
• - Historischer Erfolgsanteil des einzelnen Trigger-Klassifizierers 101
• - Voraussichtlich benötigte Rechenkapazität des Trigger-Klassifizierers 102
• - Trigger verbrauchtes Budget 103
• - Trigger-Anzahl gesammelter Sensor-Daten 104
• - Durchschnittlicher Rechenaufwand zum Auffinden eines relevanten Sensordatensatzes 105
• - Trigger-Qualitätswert 106
• - Durchschnittlicher Klassifizierer-Qualitätswert bei vorherigen Anwendungen des Trigger-Klassifizierers 107
• - Durchführungsrang aus Trigger-Qualitätswert x Rechenleistungswert beziehungsweise Gebot 108
• Das Auktions-Modul 56, mit dem auf jedem der Fahrzeuge eine Reihenfolge der Abarbeitung der Trigger im Rahmen der jeweiligen Rechenkapazität festgelegt wird, sortiert die durchzuführenden Trigger-Klassifizierer 13 in einer Variante nach dem Produkt aus Trigger-Auktionsgebot beziehungsweise Trigger-Rechenleistungswert 12 multipliziert mit dem Trigger-Qualitätswert 106. Der Trigger-Qualitätswert 106 kann dabei eine Vielzahl von Einflussfaktoren berücksichtigen. Sobald das verbrauchte beziehungsweise aufsummierte Trigger-Budget 103 (d.h. die Bewertung aller im jeweiligen Fahrzeug bereits durchgeführten Rechenoperationen) das Trigger-Budget 15 oder die Trigger-Anzahl 104 der gesammelten Sensordaten die Trigger-Zieldatenmenge 19 erreicht, wird die Teilnahme des Triggers 10 an der Auktion beziehungsweise der Ausführung des Triggers in einem Fahrzeug gestoppt. Hierzu wird beispielsweise eine Trigger-Statistik 100 über die Fahrzeugflotte 9 hinweg synchronisiert. Dies geschieht gegebenenfalls, indem die Fahrzeuge über eine Netzwerkschnittstelle 31 mit einem System außerhalb des Fahrzeugs wie z.B. der oben genannten Applikation 1 kommunizieren.
• Wenn ein Trigger 10 aus der Auktion ausscheidet (d.h. entsprechend der Einsatzstrategie nicht mehr durchgeführt wird), wird die Leerstelle mit dem nächsten passenden Trigger 10 gefüllt. Eine hohe Auslastung des fahrzeuginternen Servers 34 wird, soweit wie möglich, immer angestrebt, da die Anzahl der anwendbaren Trigger-Klassifizierer letztlich von der auf dem fahrzeuginternen Server 34 zur Verfügung stehenden Rechenkapazität 65 abhängt.
• Das Trigger-Klassifizier-Modul 57 wendet den Trigger-Klassifizierer 13 vorzugsweise auf die Zwischenergebnisse des lernenden Algorithmus 53 an und berechnet einen entsprechenden Klassifizier-Qualitätswert 85. Falls dieser die Trigger-Anforderung 14 erfüllt, werden die zugehörigen Sensordaten 50 vorzugsweise ergänzt um Metadaten 80, als Sensordaten 70 über die Netzwerkschnittstelle 31 an ein System außerhalb des Fahrzeugs, wie z.B. der oben genannten Applikation 1, gesendet. Das Trigger-Klassifizier-Modul 57 arbeitet die Trigger-Klassifizierer 13 entsprechend der im Auktions-Modul 56 definierten Reihenfolge ab.
• Der Klassifizier-Qualitätswert 85 kann beispielsweise eine normierte Gleitkommazahl zwischen - 1 und 1 sein, die die Wahrscheinlichkeit repräsentiert, dass die Sensordaten 50 ein positives (beziehungsweise bei -1 negatives) Beispiel für den jeweiligen Einsatzfall (z.B. StoppschildErkennung) darstellen. Der Schwellwert zur Übermittlung kann hierbei zum Beispiel bei >0,5 für Positivbeispiele beziehungsweise <-0,5 für gesuchte Negativbeispiele liegen.
• Ein Wertfeststellungsmodul 58 berechnet gegebenenfalls den Wert (z.B. Summe von Bewertungspunkten beziehungsweise Preis) für den einzelnen Akteur 2 für die Gewinnung von Sensordaten 50 entsprechend dem Trigger-Klassifizierer 10 zur Erzeugung von Trainingsdaten. Das Trigger-Klassifizier-Modul 57 speist dafür das Wertfeststellungsmodul 58 mit Daten zu den entsprechenden Sensordaten 50. Diese Daten umfassen beispielsweise die Summe an durchgeführten Rechenoperationen 89 und die durch die Netzwerkschnittstelle 31 zu übertragende Datenmenge 87.
• Der Gesamtwert für die Sensordaten 50 ergibt sich aus einem aus einer Auktion entstanden Wert (z.B. Preis) pro Rechenoperation 88 und der Anzahl an durchgeführten Rechenoperationen 89. Hinzu werden noch die Kosten beziehungsweise Wertanteile für die Datenübertragung addiert. Sie ergeben sich aus der zu übertragenden Datenmenge 87 und dem Wert 63 für die Datenübertragung (z.B. pro Megabyte). Als weitere Rahmenbedingung neben dem Wert 63 für die Datenübertragung kann von dem Systembetreiber ein Mindestwert 64 pro Rechenoperation definiert werden.
• In einem Nachverarbeitungsmodul 59 werden die durch die Trigger-Klassifizierer 13 ermittelten Sensordaten 50 verarbeitet, um die Qualität zu verbessern und/oder die Menge der über das Netzwerk zu übermittelnden Daten zu reduzieren. Diese werden dann vorzugsweise um Metadaten 80 aus anderen Fahrzeugsystemen und Sensoren 33 zu einem Sensordatensatz 70 zusammengefügt. Dazu zählen z.B. Zeitstempel 81, Trigger-ID 82, eine lernende Algorithmus-ID 83, ein Ort 84, ein Klassifizier-Qualitätswert 85, ein Fahrzeugkontrollparameter 86 (z.B. eine Betriebsbedingung wie Geschwindigkeit, Beschleunigung, Lenkwinkel und Bremskraft). Darüber hinaus sind die durch das Bewertungsmodul 56 und das Wertfeststellungsmodul 58 ermittelten Werte für den Sensordatensatz 90 für den Akteur 2 zu nennen.
• Eine Netzwerkschnittstelle 31 sendet gegebenenfalls den durch das Nachverarbeitungsmodul 59 erstellten Sensordatensatz 70 an ein System außerhalb des Fahrzeugs, wie z.B. der genannten Applikation 1. Über das außerhalb des Fahrzeugs betriebene System, wie z.B. die genannte Applikation 1, kann der Akteur 2, welcher den entsprechenden Trigger 10 definiert hat, Zugang zu dem Sensordatensatz 70 haben. Der Sensordatensatz 70 ist optional ebenfalls per API-Schnittstelle 4 für weitere Systeme zugänglich. Das Fahrzeug kann des Weiteren ein Speichermedium 60 aufweisen, auf dem die verarbeiteten Sensordaten, wie Metadaten und rohen Sensordaten, entweder bei geringer verfügbarer Rechenkapazität 65 oder auch bei schlechter oder keiner Konnektivität zwischengespeichert werden können.
• Entsprechend einem Ausführungsbeispiel kann somit ein Auktionsmechanismus für Rechenkapazitäten im Fahrzeug einer Fahrzeugflotte zur Gewinnung von Sensordaten für die spätere Erzeugung von Trainingsdaten für Assistenzsysteme beziehungsweise autonome Fahrsysteme durch aktives Lernen mit den folgenden zehn Schritten bereitgestellt werden, wobei die Teilnahme an der Auktion von den erfassten Sensordaten abhängt.
1. 1. Empfang von Sensordaten 50 von Fahrzeugsensoren für das FAS 32 entsprechend ihrer Sensorreichweite 35 und Daten aus weiteren Fahrzeugsystemen wie einem GPS-Modul 33.
2. 2. Anwendung eines lernenden Algorithmus 53 auf die Sensordaten 50.
3. 3. Definition eines Triggers 10 über ein System außerhalb des Fahrzeugs durch einen Akteur 2 und Übermittlung des Triggers 10 an ausgewählte Fahrzeuge 30 einer Fahrzeugflotte 9 z.B. per OTA-Update 8 über ein Netzwerk 7.
4. 4. Anwendung des Trigger-Filter-Moduls 55 zur Limitierung von Bedingungen, unter welchen ein Trigger 10 an einer Auktion zur Durchführung des eigenen Trigger-Klassifizierers teilnimmt.
5. 5. Anwendung einer Auktion unter zuvor durch Filter ausgewählten Trigger-Klassifizierern 13, wobei die Rechenleistungswerte 12 der Trigger 10 in Wertpunkten pro Rechenoperation und weitere Trigger-Statistiken 100 berücksichtigt werden. Hierzu zählen unter anderem zur Verfügung stehende Rechenkapazitäten 65, ein historischer Erfolgsanteil 101 des einzelnen Trigger-Klassifizierers bei seiner Anwendung, die voraussichtlich benötigte Rechenkapazität 102 des Trigger-Klassifizierers und ein Trigger-Qualitätswert 106.
6. 6. Anwendung der durch die Auktion ausgewählten Trigger-Klassifizierer 13 auf Zwischenergebnisse des lernenden Algorithmus 53 zur Berechnung eines Klassifizier-Qualitätswerts 85 für die Sensordaten 50.
7. 7. Wertbildung (z.B. Preisbildung) für die Durchführung des Trigger-Klassifizierers entsprechend dem aus der Auktion entstandenen Wert (z.B. Preis) pro Rechenoperation 88, der Anzahl an durchgeführten Rechenoperationen 89 und der Datenmenge 87. Dabei entspricht der Wert pro Rechenoperation 88 mindestens einem im System hinterlegten Mindestwert 64 pro Rechenoperation. Dies gilt auch, wenn nur ein Trigger 10 an einer Auktion teilnimmt.
8. 8. Entscheidung, ob die Daten als Sensordatensatz 70 über ein Netzwerk 7 mit mindestens einem Teil der Sensordaten und weiterer Metadaten 80 (mindestens einem Klassifizier-Qualitätswert) an ein System 3 außerhalb des Fahrzeugs über ein Netzwerk 7 gesendet werden soll.
9. 9. Übertragung des Sensordatensatzes 70 an ein System außerhalb des Fahrzeugs zur Bereitstellung der Daten gegenüber dem Akteur 2, wobei das System durch API-Schnittstellen 4 die Einbindung weiterer Systeme 6 ermöglicht.
10. 10. Synchronisation der Trigger-Statistik 100 zwischen den Fahrzeugen 30 der Flotte 9 über ein System außerhalb des Fahrzeugs, wie z.B. einer Applikation 1.
• In einem konkreten Ausführungsbeispiel könnte ein Ingenieur die Aufgabe erhalten, die Erkennung eines Stoppschilds 37 als zusätzliches Feature für ein Fahrerassistenzsystem oder ein hochautomatisiertes Fahrsystem zu entwickeln. Hierfür legt dieser einen neuen Trigger 10 in der Applikation 1 an. Der Trigger 10 ist beispielsweise wie folgt beschrieben:
• - Trigger-Bedingung 11: Der Trigger-Klassifizierer 13 ist nur an Kreuzungen anzuwenden; anzuwenden auf gesamte Fahrzeugflotte 9 in Deutschland
• - Trigger-Auktionsgebot 12: 1,1 € für Einheit Rechenoperationen (ERO) Rechenoperationen
• - Trigger-Klassifizierer 13: ein mit 1000 Stoppschildern trainierter, lernender Algorithmus
• - Trigger-Anforderung 14: Klassifizier-Qualitätswert 85 >0,7
• - Trigger-Budget 15: 100.000 Euro
• - Trigger-Zeitraum 16: bis zum 2024-01-20
• - Trigger-Zieldatenformat 17: Stoppschild (Bildausschnitt, .JPG) + Radar (Gesamtsatz, Punktewolke)
• - Trigger-Bearbeitungszeitpunkt 18: Sofort
• - Trigger-Zieldatenmenge 19: 1 Mio. Sensordatensätze 70.
• Damit das Trigger-Filter-Modul 55 später die Trigger-Bedingungen 10 auf die richtigen Zwischenergebnisse des lernenden Algorithmus 53 anwendet, sind beispielsweise in einer Datenbank 5 die Zwischenschichten des lernenden Algorithmus 53, die z.B. eine Kreuzung anzeigen, hinterlegt. Hinzu kommen ausschließende Bedingungen: Beispielsweise eine Anwendung des Trigger-Klassifizierers 13 an Orten 84, an denen bereits die Trigger-Klassifizierer 13 von einem Fahrzeug 30 aus der Flotte 9 in einem definierten Zeitraum angewendet wurde und gegebenenfalls einen Sensordatensatz 70 erzeugt hat. Auf der Basis der Eingaben berechnet die Applikation entsprechend ähnlicher Trigger 10 den voraussichtlichen Preis pro Sensordatensatz und zeigt diesen dem Akteur 2 an.
• Der Ingenieur bestätigt daraufhin den Auftrag. Nach einer eingehenden Sicherheits- und Systemkompatibilitätsprüfung sendet die Applikation 1 den Trigger 10 (stellvertretend für 10A und 10B) an die entsprechenden Fahrzeuge 30 in der Fahrzeugflotte 9. In diesem Fall sind dies alle Fahrzeuge 30 in Deutschland. Als Netzwerk 7 zur Übertragung der Daten wird z.B. ein LTE-Netz verwendet.
• Das Fahrzeug empfängt den Trigger 10 über die Netzwerkschnittstelle 31 und installiert den Trigger 10 per OTA-Update 8 auf einem seiner fahrzeuginternen Server 34.
• Die Fahrzeugsensoren für das FAS 32 (unter anderem Kamera, Radar, Ultraschallsensoren) speisen Sensordaten 50 in ein Vorverarbeitungsmodul 51, welches die Daten normalisiert und Filter anwendet.
• Die verarbeiteten Sensordaten 52 aus dem Vorverarbeitungsmodul 51 werden in einem lernenden Algorithmus 53 gespeist.
• Das Trigger-Filtermodul 55 wird mit Zwischenergebnissen des lernenden Algorithmus 53 gespeist und vergleicht diese mit den Trigger-Bedingungen 11. Zusätzlich vergleicht das Trigger-Filter-Modul 55 das GPS-Signal des Fahrzeugs 33 mit den auf einer Karte hinterlegten Koordinaten. In diesem Fall sind es entsprechend der Trigger-Bedingungen 11 die Koordinaten von Kreuzungen. Falls sich das Fahrzeug einer Kreuzung nähert, prüft das Trigger-Filter-Modul 55 auf Basis des Triggers „Stoppschild“ 10A, ob der Output einer definierten Zwischenschicht des lernenden Algorithmus 53 die in der Trigger-Bedingung 11 definierten Eigenschaften besitzt. Falls dies der Fall ist, sendet das Trigger-Filter-Modul 55 ein Signal an das Bewertungsmodul 56.
• Das Bewertungsmodul 56 beziehungsweise das Auktions-Modul greift auf die einzelnen Trigger-Rechenleistungswerte (hier Trigger-Auktionsgebote) 12 zu und sortiert diese entsprechend ihres Gebots in € je Einheit Rechenoperationen (ERO). Das Auktionsmodul 56 kann Tausende von Trigger-Auktionsgeboten 12 gleichzeitig verarbeiten. Um das Beispiel zu vereinfachten, sind hier vier genannt:

  Trigger 10	Erfolgsanteil 101	Rechenbedarf 102	Auktionsgebot 12
  (1.) Stoppschilder 37	30%	5 ERO	1,1 €/ERO
  (2.) Mülltonnen auf der Straße 39	10%	3 ERO	1,0 €/ERO
  (3.) Ampeln (blaues Licht) 36	5%	2 ERO	0,8 €/ERO
  (4.) Ampeln (rechtsabbiegen frei) 38	15%	4 ERO	0,7 €/ERO

• Über die durch den Akteur 2 definierten Informationen hinaus berücksichtigt das Auktionsmodul 56 gegebenenfalls weitere Trigger-Statistiken 100. Dazu zählt der Trigger-Qualitätswert 106. Er beeinflusst in Kombination mit dem Trigger-Auktionsgebot 12 die Reihenfolge, in welcher die Trigger-Klassifizierer bearbeitet werden. Er kann eine Vielzahl von Einflussfaktoren berücksichtigen.
• In vereinfachter Form setzt sich der Trigger-Qualitätswert 106 in diesem Beispiel aus folgenden drei Faktoren zusammen:
• - Historischer Erfolgsanteil 101 des einzelnen Trigger-Klassifizierers in Prozent [Trigger-Qualitätswert 106 > Schwellenwert aus den Trigger-Anforderungen 14]
• - durchschnittlicher Rechenaufwand 105 (über das gesamte System inklusive Misserfolge) zum Auffinden eines relevanten Sensordatensatzes 90
• - durchschnittlicher Klassifizier-Qualitätswert 107 bei vorherigen Anwendungen des Trigger-Klassifizierers 10
• Es gilt die Formel: $$\begin{array}{l}\text{Trigger}-\text{Qualit}\ddot{\text{a}}\text{tswert 106}=\text{Erfolgsanteil 101/Durch}\text{. Rechenaufwand 105* Durch}\text{. Klassifizier}-\\ \text{Qualit}\ddot{\text{a}}\text{tswert 107}\end{array}$$

  

  Trigger 10	Erfolgsanteil 101	Durch. Rechenaufwand 105	Durch. Klassifizier-Qualitätswert 107	Trigger-Qualitätswert 106
  (1.) 37	30%	30 ERO	0,4	0,00400
  (2.) 39	10%	20 ERO	0,2	0,00100
  (3.) 36	5%	30 ERO	0,1	0,00017
  (4.) 38	15%	10 ERO	0,25	0,00375

• Durch Multiplikation des Trigger-Qualitätswertes 106 mit dem Auktionsgebot 12 berechnet das Auktionsmodul 56 den Durchführungsrang 108 des Triggers.

  Trigger 10	Trigger-Qualitätswert 106	Gebot 12	Durchführungsrang 108
  (1.) Stoppschilder 37	0,00400	1,1 €/ERO	0,00440
  (2.) Mülltonnen auf der Straße 39	0,00100	1,0 Cent/ERO O	0,00100
  (3.) Ampeln (blaues statt grünes Licht) 36	0,00017	0,8 E/ERO	0,00013
  (4.) Ampeln (rechtsabbiegen frei) 38	0,00375	0,7 E/ERO	0,00263

• Die einzelnen Trigger 10 werden im Folgenden nach diesem Durchführungsrang 108 sortiert.

  Trigger 10	Trigger-Qualitätswert 106	Gebot 12	Durchführungsrang 108
  (1.) Stoppschilder 37	0,00400	1,1 €/ERO	0,00440
  (4.) Ampeln (rechtsabbiegen frei) 38	0,00375	0,7 E/ERO	0,00263
  (2.) Mülltonnen auf der Straße 39	0,00100	1,0 €/ERO	0,00100
  (3.) Ampeln (blaues statt grünes Licht) 36	0,00017	0,8 €/ERO	0,00013

• Entsprechend wird immer der Trigger-Klassifizierer 13 eines Triggers 10 mit dem höchsten Durchführungsrang 108bevorzugt bearbeitet. In einer Variante können stochastische Methoden wie zum Beispiel eine Verteilungsfunktion mit einer Zufallsvariablen die Reihenfolge beeinflussen.
• Erreicht der fahrzeuginterne Server 34 seine Kapazitätsgrenzen, werden die Trigger-Klassifizierer 13 aufsteigend mit dem niedrigsten Durchführungsrang 108 beginnend nicht mehr sofort bearbeitet. Falls der Anwender bei der Definition des Triggers 10 auch eine zeitversetzte Verarbeitung entsprechend dem Trigger-Bearbeitungszeitpunkt 18 akzeptiert, z.B. bis zu vier Stunden, werden die notwendigen Daten (unter anderem Sensordaten, Zwischenergebnis des lernenden Algorithmus 53) zwischengespeichert. Gelangt das Speichermedium 60 an seine Grenzen, werden die Daten für die einzelnen Trigger-Klassifizierer 13 wiederum entsprechend ihrem Produkt aufsteigend gelöscht.
• Sobald das Bewertungs- beziehungsweise Auktions-Modul 56 ein Signal aus dem Trigger-Filtermodul 55 erhält, welches besagt, dass der Output einer definierten Zwischenschicht des lernenden Algorithmus 53 die Trigger-Bedingungen erfüllt, legt das Auktions-Modul 56 den zu zahlenden Preis/Rechenoperation 88 fest. Dieser ergibt sich aus dem Quotienten aus dem nächst niedrigeren Durchführungsrang eines Triggers 10, welcher in einem definierten Zeitraum (z.B. in den letzten fünf Minuten) zuvor durchgeführt wurde, und dem eigenen Trigger-Qualitätswert 106 plus einem Mindestwert 64. In einer weiteren Variante werden alle Trigger 10 in der Preisfindung berücksichtigt, deren zu erkennende Objekte sich in Sensorreichweite 35 befinden.

  Trigger 10	Trigger-Klassifizier-Qualitätswert 106	Gebot 12	Durchführungsrang 108	Im definierten Zeitraum durchgeführt?
  (1.) Stoppschilder 37	0,00400	1,1 E/ERO	0,00440	Ja
  (4.) Ampeln (rechtsabbiegen frei) 38	0,00375	0,7 €/ERO	0,00263	Nein
  (2.) Mülltonnen auf der Straße 39	0,00100	1,0 €/ERO	0,00100	Ja
  (3.) Ampeln (blaues statt grünes Licht) 36	0,00017	0,8 €/ERO	0,00013	Nein

• Daraus ergibt sich für den Stoppschild-Trigger 37 ein Preis von $$\mathrm{0,001}/\mathrm{0,004}*\mathrm{1,1}+\mathrm{0,01}=\mathrm{0,285}€\text{/ERO 88}\text{.}$$

  
• Das Trigger-Klassifizier-Modul 57, welches mit den Daten aus dem Auktionsmodul 56 und den Zwischenergebnissen des lernenden Algorithmus 53 gespeist wird, führt nun die ausgewählten Trigger-Klassifizierer 13 durch und berechnet einen entsprechenden Klassifizier-Qualitätswert 85 (Die Reihenfolge der Trigger sollte nicht vor jeder Anwendung eines Trigger-Klassifizierer neu berechnet werden, sondern, dass vielmehr z.B. jede Minute einmal aktualisiert werden. Die ständige Neuberechnung würde sonst zu viel Rechenleistung kosten). In unserem Fall wendet der Trigger-Klassifizierer 13 seinen kleinen, lernenden Algorithmus (trainiert mit zirka 1000 Stoppschild-Bildern) auf die im Rahmen einer Kreuzung-Überquerung erhobenen Sensordaten 50 an und berechnet einen Klassifizier-Qualitätswert 85. Der Klassifizier-Qualitätswert 85 übersteigt in dem beschriebenen Fall mit einem Wert von 0,9 den in den Trigger-Anforderungen 14 definierten Schwellenwert von 0,7. Entsprechend werden die Sensordaten 50 zur Übermittlung ausgewählt.
• Vor der Übermittlung der Daten werden die Sensordaten 50 nun im Nachverarbeitungsmodul 59 verarbeitet, um die Qualität zu verbessern und/oder die Menge der über das Netzwerk zu übermittelnden Daten zu reduzieren, falls dies vom Akteur im Zieldatenformat 17 so definiert worden ist. Weiter ergänzt das Nachverarbeitungsmodul 59 den Sensordatensatz 70 unter anderem mit weiteren Metadaten 80 (z.B. Zeitstempel 81, Trigger-ID 82, Lernender-Algorithmus-ID 83, Ort 84, Klassifizier-Qualitätswert 85, Fahrzeugkontrollparameter /Betriebsbedingungen 86 wie Geschwindigkeit, Beschleunigung, Lenkwinkel, Bremskraft). Darüber hinaus ist der durch das Auktions-Modul 56 und dem Preisbildungs-Modul 58 ermittelte Preis für den Sensordatensatz 90 zu nennen.
• Der Preis für den Sensordatensatz 90 ergibt sich aus dem in der Auktion bestimmten Preis pro Rechenoperation 88, der Anzahl an durchgeführten Rechenoperationen 89, der zu übertragenden Datenmenge 87 und dem Preis pro übermitteltem Megabyte 59.
• In diesem Fall des Stoppschild-Triggers 37 bedeutet dies: $$\begin{array}{l}\mathrm{0,285}€/\text{ERO 88*5 ERO 89}\\ \text{+0}\text{,8 MB 87*0}\text{,1 }€/\text{MB}\\ \text{=1}\text{,505 }€/\text{Sensordatensatz 90}\end{array}$$

  
• Die Netzwerkschnittstelle 31 sendet den durch das Nachverarbeitungsmodul 59 erstellten Sensordatensatz 70 an eine Datenbank 5, welche auf einem Server außerhalb des Fahrzeugs betrieben wird. Über die genannte Applikation 1 hat der Akteur 2, welcher den entsprechenden Trigger 10 definiert hat, Zugang zu dem in einer Datenbank 5 gespeicherten Sensordatensatz 70. Wenn die Sensordaten 70 die Zieldatenmenge 19 erreicht haben, wird die Teilnahme des Triggers 10 an der Auktion gestoppt und entsprechende Updates des Triggers 10 über ein Netzwerk 7, z.B. über das LTE-Netz (oder andere Netzwerke wie zum Beispiel WLAN), an die Fahrzeugflotte 9 gesendet. Das einzelne Fahrzeug 30 empfängt die Updates wiederum über die Netzwerkschnittstelle 31 und installiert die geänderten Trigger-Einstellungen beziehungsweise löscht diese per OTA-Update auf dem fahrzeuginternen Server 34.
• In einem alternativen Ausführungsbeispiel könnte eine direkte Abrechnung von Rechenoperationen im jeweiligen Fahrzeug bei der Gewinnung von Sensordaten zur Erzeugung von Trainingsdaten für das Fahrerassistenzsystem beziehungsweise autonome Fahrsystem per aktivem Lernen ohne Auktionsmechanismus zu einem festen, aber gegebenenfalls ortsabhängigen Preis erfolgen. Ein solcher Verzicht auf den Auktionsmechanismus ist sinnvoll, wenn beispielsweise ausschließlich Teams/Abteilungen eines Unternehmens auf die Daten zugreifen und diese nicht im Wettbewerb um die Rechenkapazitäten im Fahrzeug stehen. Sobald mehrere Teams im Wettbewerb um den Zugang zu den Fahrzeugen, ihren Sensordaten und ihrer Verarbeitung stehen, benötigt es einen Versteigerungsmechanismus, um die Rechenkapazitäten in den Fahrzeugen optimal auszunutzen.
• Der Trigger 10 wird in einem weiteren Ausführungsbeispiel zur Preisberechnung an eine global verteilte Test-Fahrzeugflotte 9 versendet und dann auf die Sensordaten 50 angewendet, um z.B. 100 Sensordatensätze 70 zu erzeugen. Diese Sensordatensätze 70 werden dem Akteur 2 über die Applikation 1 bereitgestellt und auf Basis des Rechenaufwands zur Erhebung der 100 Sensordatensätze 70 ein Preis/Sensordatensatz 90 berechnet. Der Akteur 2 kann durch Bestätigung des Betrags dann z.B. die Erhebung von 100.000 entsprechenden Sensordatensätzen 70 beauftragen. Dieser Ansatz vereinfacht die Nutzung für den Akteur 2 deutlich. Im Hintergrund müsste in jedem Fahrzeug jedoch ebenfalls ein Mechanismus angewendet werden, der auswählt, welche Trigger-Klassifizierer anzuwenden sind.
• Gemäß einer weiteren alternativen Ausführungsform könnte man auf den Auktionsmechanismus verzichten und eine Abteilung beziehungsweise ein Dritter könnte sich das Recht seiner Trigger-Klassifizierer 13 auf einer Fahrzeugflotte 9 anzuwenden, kaufen. Dabei zahlt dieser z.B. pro Fahrzeugjahr oder Fahrzeugkilometer, auf denen seine Trigger-Klassifizierer angewendet werden. Dieses vereinfacht den Prozess deutlich. Es bedarf bei der Trigger-Klassifizierer-Bereitstellung einer Prüfung der notwendigen Rechenkapazität, um keine Überlastung des Systems zu riskieren. Sobald jedoch wiederum mehrere Akteure 2 um die Rechenkapazität konkurrieren, ist dieses System nicht möglich. Eine Möglichkeit wäre, dass ein Akteur 2 sich in eine definierte Fahrzeugflotte 9 (z.B. 100.000 Fahrzeuge) einkaufen kann. Der nächste kauft sich in die nächste Fahrzeugkohorte ein und so weiter.
• In einem weiteren Ausführungsbeispiel können Trigger 10 neben der manuellen Erzeugung über eine Applikation auch durch einen automatisch erkannten Verbesserungsbedarf erzeugt werden.
• Bei den erfindungsgemäßen Ausführungsformen ergeben sich folgende Vorteile:
• - Die Verteilung der Rechenkapazitäten in den Fahrzeugen unter konkurrierenden Akteuren 2 wird ermöglicht.
• - Es wird die Möglichkeit geboten, einzelne Trigger-Klassifizierer bei ihrer Anwendung zu priorisieren beziehungsweise sie in den Wettbewerb zueinander zu stellen. Daraus ergibt sich, dass die Entwickler die Anzahl an gleichzeitig auf dem Fahrzeug laufenden Trigger-Klassifizierern nicht mehr begrenzen müssen.
• - Die Zuordnung von Kosten zu einzelnen Trigger-Klassifizieren und damit zu dem jeweiligen Verursacher wird ermöglicht.
• - Man erhält einen Mechanismus, Trigger-Klassifizierer, deren Trigger-Bedingung gehäuft der aktuellen Situation entsprechen und damit durchgeführt werden, aber dann keine relevanten Sensordaten identifizieren, zu sanktionieren beziehungsweise Trigger-Klassifizierer mit guter Trigger-Bedingung zu fördern. Die Folge ist, dass Rechenkapazität von „schlecht“ definierten Trigger-Klassifizierern seltener in Anspruch genommen wird und die „besser“ definierten Trigger-Klassifizierer mehr Rechenkapazität erhalten.
• - Es wird eine Abrechnung der Erhebung von Sensordaten zur Erzeugung von Trainingsdaten durch Dritte ermöglicht.
• - Entsprechend der Fahrsituation schwankt die Wahrscheinlichkeit, relevante Trainingsdaten identifizieren zu können, signifikant. Gerade in Situationen, in denen potentiell relevante Trainingsdaten identifiziert werden könnten, bietet das System eine Möglichkeit der Priorisierung einzelner Klassifizierer, um das System nicht zu überlasten. Der entsprechende Mechanismus liegt darin, den Preis für die Rechenoperationen entsprechend der Wahrscheinlichkeit, einen Trainingsdatensatz zu gewinnen, dynamisch zu bestimmen (Auktionsmodell). Dies ermöglicht auch anderen und in Konkurrenz stehenden Akteuren 2, auf die Sensordaten zuzugreifen.
• Bezugszeichenliste

1

Applikation

2, 2A, 2B

Akteur

3

Server außerhalb des Fahrzeugs

4

API-Schnittstelle

5

Datenbank

6

weitere Systeme

7

Netzwerk

8

OTA-Update

9

Fahrzeugflotte

10, 10A, 10B

Trigger

11

Bedingung

12

Rechenleistungswert/Auktionsgebot

13

Trigger-Klassifizierer

14

Anforderung

15

Budget

16

Zeitraum

17

Zieldatenformat

18

Bearbeitungszeitpunkt

19

Zieldatenmenge

30

Fahrzeug

31

Netzwerkschnittstelle

32

Fahrzeugsensoren

33

weitere Fahrzeugsysteme

34

fahrzeuginterner Server

35

Sensorreichweite

36

Ampel (blaues statt grünes Licht)

37

Stoppschild

38

Ampel (Rechtsabbiegen frei)

39

Mülltonne

40

Fahrzeugsteuermodul

50

Sensordaten

51

Vorverarbeitungsmodul

52

vorverarbeitete Daten

53

lernender Algorithmus

54

Zwischenergebnisse

55

Trigger-Filter-Modul

56

Bewertungsmodul/Auktions-Modul

57

Trigger-Klassifizier-Modul

58

Wertfeststellungsmodul/Preisbildungsmodul

59

Nachverarbeitungsmodul

60

Speichermedium

63

Preis für Datenübertragung

64

Mindestpreis pro Rechenoperation

65

verfügbare Rechenkapazität

70

Sensordatensatz

80

Metadaten

81

Zeitstempel

82

Trigger-ID

83

Lernender-Algorithmus-ID

84

Ort

85

Klassifizier-Qualitätswert

86

Fahrzeugkontrollparameter

87

zu übertragende Datenmenge

88

Preis pro Rechenoperation

89

Anzahl durchgeführter Rechenoperationen

90

Preis für den Sensordatensatz

100

Trigger-Statistik

101

historischer Erfolgsanteil

102

voraussichtlich benötigte Rechenkapazität

103

verbrauchtes Budget

104

Anzahl gesammelter Sensordaten

105

durchschnittlicher Rechenaufwand

106

Trigger-Qualitätswert

107

Durchschnittlicher Klassifizier-Qualitätswert

108

Durchführungsrang

• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• DE 102018200134 B3 [0005]
• DE 102017201226 A1 [0006]
• DE 102013021867 A1 [0007]
• EP 3363706 A1 [0008]
• WO 2020/056331 A1 [0036]

Claims (11)

1. Verfahren zur Gewinnung eines Sensordatensatzes (70) eines Fahrzeugs (30) einer Fahrzeugflotte (9) durch in dem Fahrzeug (30): - Empfangen von Sensordaten (50) mindestens eines Sensors des Fahrzeugs (30), gekennzeichnet durch auf einem Server (3) außerhalb des Fahrzeugs (30): - Definieren oder Bereitstellen mehrerer Trigger (10, 10A, 10B) zum Erfassen jeweils eines Objekts oder einer Situation, von denen jeder einen Trigger-Rechenleistungswert (12), einen Trigger-Klassifizierer (13) und eine Trigger-Anforderung (14) aufweist, und - Senden der mehreren Trigger (10, 10A, 10B) an das Fahrzeug, in dem Fahrzeug (30): - Zuordnen einer jeweiligen Priorität zu den mehreren Triggern (10, 10A, 10B) anhand ihrer jeweiligen Trigger-Rechenleistungswerte (12), - Anwenden des jeweiligen Trigger-Klassifizierers (13) eines oder mehrerer der Trigger (10, 10A, 10B) entsprechend ihrer Priorität, soweit es eine Rechenkapazität eines fahrzeuginternen Servers (34) des Fahrzeugs erlaubt, auf die Sensordaten direkt oder indirekt, woraus sich ein jeweiliger Klassifizier-Qualitätswert (85) ergibt, - Senden des Sensordatensatzes (70) basierend auf den Sensordaten (50) von dem Fahrzeug (30) an den Server (3) außerhalb des Fahrzeugs, nur wenn der jeweilige Klassifizier-Qualitätswert (85) die Trigger-Anforderung (14) des jeweiligen Triggers (10, 10A, 10B) erfüllt.
2. Verfahren nach Anspruch 1, wobei jeder Trigger (10, 10A, 10B) jeweils eine Trigger-Bedingung (11) aufweist, und das Anwenden des jeweiligen Trigger-Klassifizierers (13) nur unter der Bedingung erfolgt, dass die Sensordaten (50) direkt oder indirekt die jeweilige Trigger-Bedingung (11) erfüllen.
3. Verfahren nach Anspruch 1 oder 2, wobei die Objekte, deren Erfassung mit den mehreren Triggern (10, 10A, 10B) erfolgen soll, vorgegebene Gegenstände oder Ereignisse auf oder an einer Fahrbahn sind.
4. Verfahren nach einem der vorhergehenden Ansprüche, wobei die mehreren Trigger (10, 10A, 10B) vom Server (3) an mindestens ein weiteres Fahrzeug geschickt werden, wo sie wie in dem Fahrzeug eingesetzt werden.
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei einer der mehreren Trigger (10, 10A, 10B) eine Wertgrenze (15) beinhaltet, und das Anwenden des jeweiligen Trigger-Klassifizierers (13) nur solange durchgeführt wird, bis eine in dem Fahrzeug in Bezug auf den jeweiligen Trigger (10, 10A, 10B) erbrachte Rechenleistung multipliziert mit dem Rechenleistungswert noch unterhalb der Wertgrenze (15) ist.
6. Verfahren nach einem der vorhergehenden Ansprüche, wobei einer der mehreren Trigger (10, 10A, 10B) einen Trigger-Zeitraum (16) beinhaltet, und der Trigger-Klassifizierer (13) nur in dem Trigger-Zeitraum (16) angewendet wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei einer der mehreren Trigger (10, 10A, 10B) ein Trigger-Zieldatenformat (17) beinhaltet, das einen Typ, einen Verarbeitungsgrad und/oder ein Format des von dem Fahrzeug (30) an den Server (3) übermittelten Sensordatensatzes (70) angibt, und der Sensordatensatz (70) in dem Trigger-Zieldatenformat (17) gesendet wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei einer der mehreren Trigger (10, 10A, 10B) einen Trigger-Bearbeitungszeitpunkt (18) beinhaltet, der einen Zeitpunkt definiert, zu dem der Trigger-Klassifizierer (13) anzuwenden ist, und das Verfahren mit dem Trigger-Bearbeitungszeitpunkt (18) gesteuert wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei einer der mehreren Trigger (10, 10A, 10B) eine Zieldatenmenge (19) beinhaltet, mit der eine Menge von den Sensordatensätzen (70) definiert ist, die von der Fahrzeugflotte (9) zu gewinnen ist, und das Verfahren beendet wird, wenn die Zieldatenmenge (19) erreicht ist.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei in dem Fahrzeug (30) ein lernender Algorithmus (53) auf die Sensordaten (50) angewendet wird, woraus sich dann der jeweilige Klassifizier-Qualitätswert (85) ergibt, und wobei der jeweilige Trigger-Klassifizierer (13) auf ein Zwischenergebnis des lernenden Algorithmus (53) angewendet wird.
11. System mit einer Fahrzeugflotte (9) aus mehreren Fahrzeugen (30) und einem fahrzeugexternen Server (3) zur Durchführung eines Verfahrens gemäß einem der vorhergehenden Ansprüche.

Images