DE102021202334A1

DE102021202334A1 - Filterung von betriebsszenarien im betrieb eines fahrzeugs

Info

Publication number: DE102021202334A1
Application number: DE102021202334.7A
Authority: DE
Inventors: Antonia Reiter; Indrasen Raghupatruni; Maria Belen Bescos Del Castillo; Christian Bartelt; Guido Drechsel; Lars Hoffmann; Noah Metzger
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-03-10
Filing date: 2021-03-10
Publication date: 2022-09-15
Also published as: CN115131750A; US12165442B2; US20220292888A1

Abstract

Ein Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur Filterung von Betriebsszenarien während des Betriebs eines Fahrzeugs, umfassend Empfangen mindestens einer Zeitreihe von Daten, Speichern von zeitgeordneten Datenpunkten der mindestens einen Zeitreihe von Daten in einem ersten Speicher, Erzeugen eines Spurgraphen für die im ersten Speicher gespeicherten zeitgeordneten Datenpunkte, Prüfen, ob der erzeugte Spurgraph im Vergleich zu einem oder mehreren vorhandenen Spurgraphen neu ist und Speichern der im ersten Speicher gespeicherten zeitgeordneten Datenpunkte in einem zweiten Speicher, wenn der erzeugte Spurgraph neu ist.

Description

Stand der Technik
Autonomes Fahren kann als Problem des offenen Kontexts gesehen werden, da nie alle späteren Betriebs-/Fahrszenarien eines zumindest teilautonom operierenden Fahrzeugs in all ihren möglichen Details und Ausführungen bereits zum Entwicklungszeitpunkt (d.h. z.B. vor Verkauf und Übergabe des Fahrzeugs an einen Verbraucher) bekannt sein können. Zur Lösung dieses Problems können Maschinenlernalgorithmen (z.B. für Computer Vision) trainiert und eingesetzt werden, die dafür ausgelegt sind, Erkenntnisse (z.B. Objekterkennung) und/oder Bewertungen auch auf unbekannten Input (z.B. Kamera-, RADAR-, LIDAR-Daten,...) zu verallgemeinern. Der verlässliche und/oder sichere Betrieb des zumindest teilautonom operierenden Fahrzeugs hängt allerdings weiterhin maßgeblich davon ab, ob die Systeme des zumindest teilautonom operierenden Fahrzeugs auf möglichst viele und insbesondere relevante Betriebs-/Fahrszenarien vorbreitet sind (und insbesondere auf die Behandlung aller relevanten Betriebs-/Fahrszenarien trainiert worden sind). Dafür ist die Bereitstellung von Felddaten (also Daten, die von den zumindest teilautonom operierenden Fahrzeugen im Betrieb gesammelt werden) von Bedeutung. Wenn ein existierender Felddatensatz Lücken aufweist, kann ein auf Basis dessen ausgelegtes (z.B. trainiertes) zumindest teilautonom operierendes Fahrzeug unter Umständen Betriebs-/Fahrszenarien nicht befriedigend meistern. Zum Beispiel kann zu einem bestimmten Zeitpunkt ein neues Fahrzeug oder ein neues Verkehrsschild in dem Betriebsbereich des zumindest teilautonom operierenden Fahrzeugs auftauchen, das dementsprechend in einem existierenden Felddatensatz nicht repräsentiert ist. In dieser Situation kann es zu Fehlern des auf Basis dieses Felddatensatzes ausgelegten (z.B. trainierten) zumindest teilautonom operierenden Fahrzeugs kommen. Es ist daher wichtig, möglichst viele Lücken in dem Trainingsdatensatz (fortlaufend) zu erkennen und zu schließen. Felddaten wie z.B. Fahrzeuggeschwindigkeit und Umgebungsdaten können von der Fahrzeugtechnologie unabhängig sein und dann ganz oder teilweise (z.B. mit entsprechenden Skalierungen) auf neue Entwicklungsprojekte zumindest teilautonom operierender Fahrzeuge übertragen werden. Das eine oder die mehreren Fahrzeuge, die Felddaten ansammeln, können aber müssen nicht zumindest teilautonom operierende Fahrzeuge sein, sofern sie (z.B. aus anderen Gründen) mit einem entsprechenden Sensorsystem zur Erfassung der Sensordaten ausgestattet sind.
Bei der kontinuierlichen Erfassung von Sensordaten können große Datenmenge akkumuliert werden. Solche Datenmengen können beispielsweise während des Betriebs/während der Fahrt und/oder beim Service auf einen Cloud Server transferiert werden.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur Filterung von Betriebsszenarien während des Betriebs eines Fahrzeugs, umfassend Empfangen mindestens einer Zeitreihe von Daten, Speichern von zeitgeordneten Datenpunkten der mindestens einen Zeitreihe von Daten in einem ersten Speicher, Erzeugen eines Spurgraphen für die im ersten Speicher gespeicherten zeitgeordneten Datenpunkte, Prüfen, ob der erzeugte Spurgraph im Vergleich zu einem oder mehreren vorhandenen Spurgraphen neu ist, Speichern der im ersten Speicher gespeicherten zeitgeordneten Datenpunkte in einem zweiten Speicher, wenn der erzeugte Spurgraph neu ist.
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-Programm, welches dafür ausgelegt ist, das computer-implementierte Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-lesbares Medium oder Signal, das das Computer-Programm nach dem zweiten allgemeinen Aspekt speichert und/oder enthält.
Ein vierter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computersystem, insbesondere eine Steuereinheit eines Fahrzeugs, welches dafür ausgelegt ist, das Computer-Programm nach dem zweiten allgemeinen Aspekt auszuführen.
Die Daten (insbesondere die Betriebs-/Fahrszenarien) können beispielsweise für die Erkennung von Corner Cases (deutsch: Eckfälle) genutzt werden, anhand derer dann Lücken in der Auslegung der Systeme des zumindest teilautonom operierenden Fahrzeugs geschlossen werden können. Corner Cases, die im Betrieb und insbesondere während der Fahrt eines Fahrzeugs, insbesondere eines Fahrzeugs zum (teil)autonomen Fahren, auftreten können, sind wichtige (Grenz-)Fälle, die in der entwicklungs- und/oder serienbegleitenden Auslegung und Erprobung des Fahrzeugs berücksichtigt werden können, um einen verlässlichen und sicheren Betrieb des Fahrzeugs zu gewährleisten. Corner Cases können über einen, mehrere, oder viele Zeitschriebe (z.B. Fahrzeuggeschwindigkeit, Lenkungswinkel, Sensordaten eines bildgebenden Systems, Positionsdaten,...) beschrieben werden, wobei sich der Zeitraum von wenigen Interrupts eines Steuergeräts (z.B. mit 100 Hz Taktung) über eine oder mehrere Sekunden, bis hin zu einer oder mehreren Minuten und/oder einer oder mehreren Stunden erstrecken kann.
Die eine oder die mehreren (z.B. mehr als 2, mehr als 3, mehr als 4, mehr als 5, mehr als 10, mehr als 20, mehr als 50, mehr als 100, mehr als 500, oder mehr als 1000) Zeitreihen (oder auch Zeitschriebe) können während des Betriebs/während der Fahrt eines oder mehrerer Fahrzeuge erfasst werden. Allerdings können die bei der kontinuierlichen Erfassung von Daten der mindestens einen Zeitreihe, insbesondere von Sensordaten, anfallenden Datenmengen groß sein. In der Tat entstehen dabei üblicherweise, z.B. in Abhängigkeit der Datendichte in den Zeitschrieben und je nach Flottenstärke, große Datenmengen, die viel Speicherplatz (z.B. auf einem Cloud Server) beanspruchen. Alternativ oder zusätzlich kann die Auswertung solcher Datenmenge eine große Rechenzeit erfordern. Insbesondere in Fällen, in denen die Zeitschriebe nicht nur in Testphasen während der Entwicklung, sondern auch nach Verkauf und Übergabe der Fahrzeuge an Verbraucher gesammelt werden, um die Funktionalität (z.B. Computer Vision) fortlaufend über Updates verbessern zu können, kann die Flotte z.B. mehr als 1e2, mehr als 1e3, mehr als 1e4, mehr als 1e5, mehr als 1e6, oder mehr als le7 Fahrzeuge umfassen.
Solche Datenmengen weisen zudem üblicherweise eine hohe Redundanz auf. Zum einen beschreiben diese Datenmenge überwiegend normale Betriebs-/Fahrszenarien, die häufig bereits bekannt sind (z.B. eine Geradeausfahrt auf der Autobahn mit gelegentlichen Spurwechseln für das Überholen). In der Tat können z.B. gerade Corner Cases unwahrscheinlich sein, insbesondere bei höherdimensionalen Parameterräumen. Zum anderen kann jeder Zeitschrieb für sich oder im Zusammenspiel mit anderen Zeitschrieben redundante Informationen enthalten (z.B. Datenpunkte in konstanten Phasen oder Proportionalitäten zwischen Signalen wie z.B. Fahrzeuggeschwindigkeit und Drehfrequenz einer Antriebsmaschine in bestimmten Fahrzuständen).
Ein Vorteil der Spurgraphen kann darin gesehen werden, dass durch Spurgraphen das eine oder die mehreren Betriebs-/Fahrszenarien in einer aggregierten und dadurch (weitestgehend) redundanzfreien Weise gespeichert werden. Durch Rekonstruktion z.B. durch eine Simulation können dann (z.B. später) aus diesen Spurgraphen wieder Betriebs-/Fahrszenarien erzeugt werden, die im Wesentlichen mit den ursprünglichen Betriebs-/Fahrszenarien übereinstimmen. In diesem Sinne können die Spurgraphen als eine reversible Komprimierung betrachtet werden. Dadurch kann der Speicherbedarf und insbesondere der im Fahrzeug gesenkt werden.
Eine solche Reduzierung der Datengröße ist vorteilhaft, da selbst bei einer Anbindung des Fahrzeugs an einen Cloud Server (alternativ können Daten z.B. auch erst beim nächsten Service abgegriffen und auf einen Cloud Server geladen werden), die Daten zumindest vorübergehend im Fahrzeug (z.B. hier im zweiten Speicher) gespeichert werden müssen.
Spurgraphen können zudem z.B. (in einer zwei-dimensionalen Ebene) durch Knoten und Kanten visualisiert werden und ermöglichen dadurch Entwicklungs- und Testingenieuren eine zusätzliche Perspektive auf Betriebs-/Fahrszenarien jenseits von Zeitschrieben. Die Knoten können z.B. in unterschiedlicher Größe und/oder unterschiedlicher Farbe (z.B. gemäß einer heatmap) dargestellt werden. Dadurch können beispielsweise Häufigkeit und/oder Verweildauer graphisch und somit anschaulich dargestellt werden.
Die effiziente Speicherung von Betriebs-/Fahrszenarien in Spurgraphen kann zum Beispiel genutzt werden um neue und/oder unbekannte Corner Cases (zu deutsch: Eckfälle) zu ermitteln. Hierzu kann z.B. ein Betriebs-/Fahrszenario in einen Spurgraphen transformiert werden und mit bereits bekannten und als Spurgraphen gespeicherten Betriebs-/Fahrszenarien verglichen werden. Im Gegensatz zum direkten Vergleich von Betriebs-/Fahrszenarien kann dadurch die Effizienz gesteigert werden.
Der Begriff „Fahrzeug“ umfasst jegliche Vorrichtungen, die Passagiere und/oder Fracht transportieren. Ein Fahrzeug kann ein Kraftfahrzeug (zum Beispiel ein PKW oder ein LKW) sein, aber auch ein Schienenfahrzeug. Allerdings können auch schwimmende und fliegende Vorrichtungen Fahrzeuge sein.
Dementsprechend umfasst der Begriff „zumindest teilautonom operierendes Fahrzeug“ jegliche Vorrichtungen, die in zumindest teilautonomer Weise Passagiere und/oder Fracht transportieren. Ein zumindest teilautonom operierendes Fahrzeug kann ein Kraftfahrzeug (zum Beispiel ein PKW oder ein LKW) sein, aber auch ein Schienenfahrzeug. Allerdings können auch schwimmende und fliegende Vorrichtungen zumindest teilautonom operierende Fahrzeuge sein. Das Attribut „zumindest teilautonom“ drückt aus, dass das Fahrzeug zumindest in manchen Situationen und/oder zumindest zu manchen Zeiten autonom (d.h. ohne Mitwirkung eines Nutzers) gesteuert wird und/oder dass gewisse Systeme des Fahrzeugs (z.B. Assistenzsysteme) einen Fahrer zumindest zeitweise autonom unterstützen (z.B. ein Notbremssystem oder ein Spurhalteassistent). Insbesondere betrifft die vorliegende Offenbarung assistierte und/oder zumindest teilautonome Kraftfahrzeuge, daher werden in der Folge Aspekte der Offenbarung mithin an Beispielen von zumindest teilautonom operierenden Kraftfahrzeugen (einschließlich der assistierten Kraftfahrzeuge) erläutert (z.B. autonome Fahrzeuge der SAE J3016 Autonomiestufen 1 bis 5). Die entsprechenden Aspekte sind aber auch auf andere Typen von zumindest teilautonom operierenden Fahrzeugen übertragbar (insofern sie nicht spezifische Gegebenheiten zumindest teilautonom operierenden Kraftfahrzeugen betreffen). Der Begriff „Nutzer“ umfasst jegliche Person, die mit dem Fahrzeug fährt, von diesem transportiert wird oder seinen Betrieb überwacht. Ein Nutzer kann ein Passagier eines Fahrzeugs (insbesondere ein Fahrer). Ein Nutzer kann sich aber auch außerhalb des Fahrzeugs befinden und dieses beispielsweise steuern und/oder überwachen (z.B. während eines Einparkvorgangs oder von einer entfernten Zentrale).
Ein „Betriebsszenario“ kann jegliches Szenario sein, dass während des Betriebs des Fahrzeugs auftritt. Zum Beispiel kann ein Betriebsszenario eine bestimmte Fahrsituation sein. Ein Betriebsszenario kann sich auf einen zeitlich begrenzten Abschnitt während des Betriebs des Fahrzeugs beziehen (z.B. kürzer als 10 Minuten oder kürzer als 1 Minute). Dabei ist ein Betriebsszenario nicht auf Szenarien beschränkt, in denen das Fahrzeug sich bewegt (also fährt).
Unter dem Begriff „Fahrszenario“ wird ein Betriebsszenario verstanden, das während der Fahrt des Fahrzeugs auftritt.
Der Begriff „Sensordaten“ umfasst alle Daten, die für das Fahrzeug oder von dem Fahrzeug im Betrieb des Fahrzeugs erfasst werden. Dabei können die Sensordaten von Sensoren des Fahrzeugs erfasst werden. Sensordaten können auch außerhalb des Fahrzeugs erfasst werden (und an dieses übermittelt werden). Zum Beispiel sind GPS-Daten (oder andere Positionsdaten) Sensordaten. Der Begriff „Sensordaten“ umfasst auch Verarbeitungsstufen der Daten, die von den jeweiligen Sensoren aufgenommen werden, sowie entsprechende Metadaten. Weitere Beispiele sind weiter unten zu finden.
„Felddaten“ umfassen alle Daten, die im Zusammenhang mit dem Betrieb eines (oder einer Vielzahl) von Fahrzeugen anfallen und die beispielsweise zum Auslegen (z.B. Training) von zumindest teilautonomen Fahrzeugen verwendet werden. Beispielsweise können Felddaten dazu verwendet werden, entsprechende Betriebsszenarien in einer Simulationsumgebung zum Trainieren von zumindest teilautonomen Fahrzeugen (bzw. der darin enthaltenen Systeme) zu erzeugen. Ein „Felddatensatz“ ist einen Korpus von Felddaten. In manchen Fällen kann der Felddatensatz die Felddaten in einer gemäß einem einzigen vorgegebenen Schema strukturierten Form enthalten. Der Felddatensatz kann jedoch aus verschiedenen Teildatensätzen bestehen, die jeweils unterschiedlich strukturiert sind.
Figurenliste

1 ist ein Flussdiagramm, das die Verfahren der vorliegenden Offenbarung schematisch illustriert.
2 zeigt in schematischer Weise ein Computer-Programm, ein computer-lesbares Medium oder Signal und ein Computersystem.
3 zeigt ein Beispiel eines Spurgraphen.
4 zeigt eine Ausführungsform für ein Flussdiagramm, das die Verfahren der vorliegenden Offenbarung schematisch illustriert.
5 zeigt ein Fahrzeug mit mindestens einem Sensor zur Erfassung von Sensordaten.

Beschreibung
Zumindest teilautonom operierende Fahrzeuge 10 weisen mindestens einen Sensor 11, in der Regel mehrere/viele Sensoren 11 bzw. Sensorsysteme (z.B. Kameras für verschiedene Raumwinkel, RADAR, LIDAR, GPS,...) auf, über welche eine oder mehrere Zeitreihen 20 von Daten, insbesondere von Sensordaten, erfasst werden können. Alternativ oder zusätzlich können Daten auch Nichtsensordaten umfassen. Nichtsensordaten können beispielsweise Triggerdaten und/oder Eingaben (z.B. eine Tonspur) eines Nutzers, insbesondere eines Insassen, der das Fahrgeschehen aktiv verfolgt und/oder sich daran beteiligt, sein. Solche Daten können z.B. mittels Maschinenlernalgorithmen, die auf einem entsprechenden Trainingsdatensatz trainiert worden sind, dahingehend analysiert werden, ein Verständnis der Verkehrssituation und der Umgebung des Fahrzeugs 10 zu erlangen. Auf Basis solcher Informationen kann sodann ein Fahrmanöver gewählt und/oder angepasst werden. Ein Fahrzeug 10, z.B. ein zumindest teilautonom operierendes Fahrzeug, ist schematisch und beispielhaft in 5 dargestellt.
Das eine oder die mehreren Fahrzeuge, die Felddaten ansammeln, können aber müssen nicht zumindest teilautonom operierende Fahrzeuge sein, sofern sie (z.B. aus anderen Gründen) mit einem entsprechenden Sensorsystem (z.B. Kameras für verschiedene Raumwinkel, RADAR, LIDAR, GPS,...) zur Erfassung der Sensordaten ausgestattet sind. Zum Beispiel können auch Fahrer nicht zumindest teilautonom operierender Fahrzeuge sich bereit erklären (z.B. gegen Entgelt), ein Kamerasystem zur Erfassung der Fahrsituation zu installieren, das in ein Computersystem nach dem vierten allgemeinen Aspekt der vorliegenden Offenbarung integriert ist. So erfasste Daten können ebenfalls dazu beitragen die Funktionalität und/oder Sicherheit anderer zumindest teilautonom operierender Fahrzeuge zu verbessern.
Offenbart wird ein computer-implementiertes Verfahren 100 zur Filterung von Betriebs-/Fahrszenarien während des Fahrbetriebs eines Fahrzeugs 10, welches schematisch in 1 dargestellt ist. Das Verfahren 100 umfasst Empfangen 110 mindestens einer Zeitreihe 20 von Daten. Die Daten können sowohl Sensordaten als auch Nichtsensordaten sein. Sensordaten können beispielsweise bildgebende Daten von mindestens einer Kamera, RADAR-, und/oder LIDAR-System umfassen oder sein. Nichtsensordaten können beispielsweise Triggerdaten und/oder Eingaben des Nutzers sein. Solche Triggerdaten und/oder Eingaben des Nutzers können Bewertungen vermöge einer natürlichen Intelligenz des Nutzers umfassen, die zur weiteren Verbesserung der Maschinenlernalgorithmen und insbesondere beim überwachten Lernen als Labels (groundtruth) der Daten im Trainingsdatensatz dienen können. Weitere Nutzerdaten können auch von einer Fernsteuerung des Fahrzeugs und insbesondere von außerhalb des Fahrzeugs (z.B. beim automatisierten Einparken) empfangen werden.
Das Verfahren 100 umfasst weiterhin Speichern 120 von zeitgeordneten Datenpunkten 21 der mindestens einen Zeitreihe 20 von Daten in einem ersten Speicher. Das Verfahren 100 umfasst weiterhin Erzeugen 130 eines Spurgraphen 30 für die im ersten Speicher gespeicherten zeitgeordneten Datenpunkte 21.
Das Verfahren umfasst weiterhin Prüfen 140, ob der erzeugte Spurgraph 30 im Vergleich zu einem oder mehreren vorhandenen Spurgraphen 40 neu ist (oder als neu bewertet wird, siehe unten). Das Verfahren 100 umfasst weiterhin Speichern 150 der im ersten Speicher gespeicherten zeitgeordneten Datenpunkte 21 in einem zweiten Speicher, wenn der erzeugte Spurgraph 30 neu ist (oder als neu bewertet wird). Anderenfalls, d.h. wenn der erzeugte Spurgraph 30 als nicht neu bewertet worden ist, kann auf das Speichern der im ersten Speicher gespeicherten zeitgeordneten Datenpunkte 21 im zweiten Speicher verzichtet werden. Das Prüfen 140 kann somit als eine Filterung von Betriebs-/Fahrszenarien betrachtet werden.
Der eine oder die mehreren vorhandenen Spurgraphen 40 können eine (weitestgehend) redundanzfreie und komprimierte Version von bekannten Betriebs-/Fahrszenarien darstellen und somit in kleiner oder großer Zahl (z.B. mehr als 2, mehr als 3, mehr als 4, mehr als 5, mehr als 10, mehr als 20, mehr als 50, mehr als 100, mehr als 200, mehr als 500, mehr als 1e3, mehr als 1e4, oder mehr als le5) in einem weiteren Speicher, insbesondere in einer Datenbank, innerhalb des Fahrzeugs gespeichert werden. Zum Beispiel können der eine oder die mehreren vorhandenen Spurgraphen 40 in dem weiteren Speicher hardcodiert sein. Im Vergleich zum Abspeichern von zeitgeordneten Datenpunkten kann der ohnehin begrenzte Speicherplatz innerhalb des Fahrzeugs 10 durch Spurgraphen effizienter genutzt werden und/oder Kosten reduziert werden. Alternativ können der eine oder die mehreren vorhandenen Spurgraphen 40 auch über eine Kommunikationsschnittstelle von einem weiteren (oder demselben) Cloud Server on-demand abgerufen werden. Die Kommunikationsschnittstelle (auch: backend-Schnittstelle) kann zum Beispiel auch genutzt werden, um zu bestimmten Zeitpunkten (z.B. jeweils beim Start des Fahrzeugs, in regelmäßigen Abständen nach dem Kalender, auf Wunsch des Nutzers,...) den einen oder die mehreren Spurgraphen 40 von dem Cloud Server herunterzuladen und in dem weiteren Speicher zu speichern. Der eine oder die mehreren in dem weiteren Speicher gespeicherten Spurgraphen können somit aktualisiert werden.
Das Verfahren kann weiterhin das Speichern des erzeugten Spurgraphen 30 in dem weiteren Speicher, insbesondere in der Datenbank, innerhalb des Fahrzeugs umfassen, wenn der erzeugte Spurgraph 30 neu ist (oder als neu bewertet wird). In der Tat können der eine oder die mehreren vorhandenen Spurgraphen 40 durch Wiederholung des Verfahrens 100 und jeweiliger Speicherung des erzeugten Spurgraphen 30 über eine gewisse (Betriebs-)zeit angehäuft werden und beispielsweise in einer Datenbank gespeichert werden. Alternativ oder zusätzlich können der eine oder die mehreren vorhandenen Spurgraphen 40 (oder ein Teil davon) in in-vehicle Lernverfahren erzeugt werden. Beispielsweise können vorhandene Spurgraphen 40 über die Laufzeit des Fahrzeugs verändert und/oder angepasst werden.
Die eine oder die mehreren Zeitreihen 20 von Daten (d.h. die Sensordaten) können über mindestens einen Sensor 11 eines Fahrzeugs 10 während des Betriebs und/oder während des Fahrbetriebs (der Fahrt) erfasst werden, optional in Zeitschritten mit konstanter Abtastrate. Alternativ oder zusätzlich können Daten durch Triggern oder Eingabe seitens des Nutzers erfasst werden.
Die eine oder die mehreren Zeitreihen 20 von Daten können einen Videodatenstrom, RADAR-Daten, LIDAR-Daten, Positionsdaten (z.B. GPS, Galileo etc.), Umgebungsdaten Fahrzeugdaten und/oder Benutzerdaten umfassen.
Die zeitgeordneten Datenpunkte 21 der einen oder der mehreren Zeitreihen 20 von Daten können einem unmittelbar zurückliegenden Zeitraum (in Abgrenzung zu einem beliebig in der Vergangenheit zurückliegenden Zeitraum) und/oder einer Anzahl von unmittelbar zurückliegenden Datenpunkten der mindestens einen Zeitreihe von Daten entsprechen (moving window). Der unmittelbar zurückliegende Zeitraum kann z.B. weniger als 0.5 Sekunden, weniger als 1 Sekunde, weniger als 2 Sekunden, weniger als 5 Sekunden, weniger als 30 Sekunden, weniger als 1 Minute, weniger als 2 Minuten, oder weniger als 5 Minuten betragen. Dieser Zeitraum und/oder diese Anzahl können ein mögliches Maß an Überlappung zwischen zeitgeordneten Datenpunkten 21 unterschiedlicher aber zeitlich benachbarter Ausführungen des Verfahrens 100 definieren. Bei konstanter Abtastung kann der Zeitraum zu einer Anzahl äquivalent sein.
Die zeitgeordneten Datenpunkte 21 der einen oder der mehreren Zeitreihen 20 von Daten können ein Betriebs-/Fahrszenario beschreiben und/oder charakterisieren. In der Praxis kann es auch vorkommen, dass die zeitgeordneten Datenpunkte 21 der einen oder der mehreren Zeitreihen 20 von Daten nur Teile eines Betriebs-/Fahrszenarios beschreiben und/oder charakterisieren.
Der Spurgraph 30, dargestellt z.B. in 3, kann ein Graph sein. Der Graph kann einen oder mehrere Knoten umfassen, wobei jeder Knoten einem Wertebereich von Daten in einem durch die Wertebereiche der zeitgeordneten Datenpunkte 21 aufgespannten (Vektor-)Raum entspricht. Z.B. können die y-Werte je Zeitreihe/Sensorsignal in diskrete Klassen (eindimensionale Wertebereiche) eingeordnet werden. Aus den eindimensionalen Wertebereichen können durch ein direktes Produkt höher-dimensionale Wertebereiche gebildet werden. Die (höherdimensionalen) Wertebereiche von je zwei Knoten des Spurgraphen 30 können unterschiedlich sein. Überlappungen zwischen Wertebereiche von je zwei Knoten des Spurgraphen 30 können vermieden werden. Jeder Wertebereich kann eine höherdimensionale Untermenge des durch ein oder mehrere Merkmale aufgespannten (Vektor-)Raum sein. Ein Knoten kann einem Wertebereich in dem (Vektor-)Raum entsprechen, indem dem Knoten ein Vektor zugeordnet ist, dessen Einträge Koordinaten bezüglich einer Basis im (Vektor-)Raum und/oder Abzählungen von Untermengen des (Vektor-)Raums sind. Zum Beispiel können (höher-dimensionale) Intervalle im (Vektor)-Raum durchnummeriert werden.
In bestimmten Fällen kann es vorteilhaft sein, wenn der Spurgraph mindestens einen Knoten mehrfach umfasst. Ein solcher Knoten könnte z.B. einen Zwischenzustand darstellen, der in je zwei Betriebs-/Fahrszenarien auftritt, die allerdings auseinandergehalten werden sollen.
Ein (z.B. beliebiges) Merkmal zur Charakterisierung eines Betriebs-/Fahrzustands kann einen Zeitschrieb und/oder einen Wertebereich (oder einen Teil des Wertebereichs, insbesondere einen Wert) des Zeitschriebs umfassen (oder sein).
Alternativ oder zusätzlich kann ein (z.B. beliebiges) Merkmal einen Parameter des einen oder der mehreren Zeitschriebe oder einen aus diesen abgeleiteten Parameter (z.B. Stärke des Gegenlichts aus Kameradaten) umfassen (oder sein). In dem beispielhaften Fall mit vier Merkmalen, wobei z.B. einem Knoten der vierdimensionale Vektor [1, 2, 1, 1] zugeordnet ist, kann z.B. der erste Eintrag (hier: eine 1) des Vektors einem Wertebereich der Fahrzeuggeschwindigkeit von 20km/h bis 50km/h zugeordnet sein. Weiterhin kann der zweite Eintrag (hier: eine 2) des Vektors z.B. einem Wertebereich des Lenkwinkels von 0° bis +5° zugeordnet sein. Weiterhin kann z.B. der dritte Eintrag (hier: eine 1) des Vektors einer aus Kameradaten abgeleiteten Stärke des Gegenlichts von 3 (oder einem Wertebereich, z.B. auf einer einheitlosen Skala von 1 bis 5) sein. Weiterhin kann z.B. der vierte Eintrag (hier: eine 1) des Vektors einem (diskreten) Klassifikationsergebnis zur Erkennung eines Hindernisses auf der Fahrbahn sein. Jeder mögliche andere Knoten des Spurgraphen 30 kann ebenfalls einen vierdimensionalen Vektor (z.B. [2, 0, 1, 1]) mit jeweils anderen Einträgen aufweisen. Hierbei können die Einträge zweier Vektoren als anders betrachtet werden, wenn sie sich mindestens in einem Eintrag unterscheiden. Die Vektoren der Knoten eines Spurgraphens können sich allerdings auf dieselben Merkmale beziehen. Z.B. kann sich der erste Eintrag (hier: eine 2) des Vektors des anderen Knoten ebenfalls auf den Zeitschrieb Fahrzeuggeschwindigkeit beziehen und insbesondere auf einen Wertebereich der Fahrzeuggeschwindigkeit z.B. von 50km/h bis 70km/h, etc.
Der Graph kann weiterhin keine oder eine Kante zwischen je zwei Knoten umfassen, wobei jede Kante mindestens eine Pfeilrichtung aufweist, optional auch entgegengesetzte Pfeilrichtungen aufweisen kann, wobei die Pfeilrichtung jeweils die Richtung eines Übergangs zwischen den Knoten zugehörigen Wertebereichen anzeigt.
Jedem Knoten kann eine Häufigkeit zugeordnet werden, die optional durch die Größe des Knoten dargestellt wird. Alternativ oder zusätzlich kann jedem Knoten eine Verweildauer zugeordnet werden, die optional durch eine Farbkodierung dargestellt wird. Alternativ oder zusätzlich kann jeder Kante (oder jeder Kante und deren Richtung) eine Übergangshäufigkeit zugeordnet werden, die optional durch eine weitere Farbkodierung dargestellt werden kann (z.B. können jeweils die Pfeilspitzen von Kanten entsprechend eingefärbt werden). Die Darstellbarkeit von Spurgraphen kann für Entwicklungs- und/oder Testingenieure nützlich sein.
Der mindestens eine Spurgraph 30 kann eine Datenstruktur sein, die die zeitgeordneten Datenpunkte 21 aggregiert und komprimiert (d.h. weitestgehend redundanzfrei) repräsentiert. Die zeitgeordneteten Datenpunkte 21 können insbesondere Sensorsignale des Fahrzeugs oder der Fahrzeuge der Fahrzeugflotte sein. Die Datenstruktur kann z.B. in einem xml oder json Format gespeichert werden. Dabei können auch Metadaten (z.B. zur eindeutigen Kennzeichnung von Fahrzeugen in der Fahrzeugflotte) gespeichert werden.
Der Spurgraph 30 beinhaltet implizit eine Wahl von einem oder mehrerer Merkmale, da jeder Knoten im Spurgraphen 30 einem jeweiligen Wertebereich in ein und demselben durch das oder die Merkmale aufgespannten (Vektor-)Raum entspricht. In anderen Worten, jeder Spurgraph 30 kann einem oder mehreren Merkmalen zugeordnet werden. 3 zeigt zum Beispiel einen Spurgraphen 30 mit vier Merkmalen, wobei jedem Knoten ein vierdimensionaler Vektor (z.B. [1, 2, 1, 1]]) zugeordnet ist, dessen Einträge sich auf die durch das oder die Merkmale definierte Basis in einem Vektorraum beziehen.
Das Erzeugen 130 des Spurgraphen 30 für die im ersten Speicher gespeicherten zeitgeordneten Datenpunkte 21 kann zunächst Clustern von y-Werten der zeitgeordneten Datenpunkte 21 der mindestens einen Zeitreihe 20 von Daten oder der mehreren Zeitreihen 20 von Daten in mindestens zwei Clusters in einem (Vektor-)Raum, dessen Dimensionalität der Anzahl der mindestens einen Zeitreihe 20 von Daten oder der mehreren Zeitreihen 20 von Daten entspricht, optional mittels unüberwachtem Lernen, umfassen. Dabei kann optional unüberwachtes Maschinenlernen zum Einsatz kommen (z.B. k-means clustering oder andere Cluster-Verfahren). Zum Beispiel können die y-Werte der zeitgeordneten Datenpunkte 21 zweier Zeitreihen 20 (z.B. Fahrzeuggeschwindigkeit und Lenkwinkel) (als Punktewolke) in einen zweidimensionalen (Vektor-)Raum abgebildet und zweidimensionale Clusters, d.h. zweidimensionale Untermengen, im zweidimensionalen (Vektor-) Raum definiert werden.
Alternativ kann das Erzeugen 130 des Spurgraphen 30 für die im ersten Speicher gespeicherten zeitgeordneten Datenpunkte 21 (oder zusätzlich kann das Clustern von y-Werten der zeitgeordneten Datenpunkte 21 der mindestens einen Zeitreihe 20 von Daten oder der mehreren Zeitreihen 20 von Daten in mindestens zwei Clusters in dem (Vektor-) Raum) zunächst Clustern von y-Werten der zeitgeordneten Datenpunkte jeder der mindestens einen Zeitreihe 20 von Daten oder der mehreren Zeitreihen 20 von Daten separat in jeweils eindimensionale Clusters umfassen, wobei mindestens für eine Zeitreihe 20 von Daten mindestens zwei eindimensionale Clusters definiert werden können. Im Falle von mehreren Zeitreihen 20 kann das Erzeugen 130 des Spurgraphen (oder das Clustern von y-Werten der zeitgeordneten Datenpunkte 21 der mindestens einen Zeitreihe 20 von Daten oder der mehreren Zeitreihen 20 von Daten in mindestens zwei Clusters in einem (Vektor-)Raum) sodann Erstellen von höherdimensionalen Clusters in einem (Vektor-)Raum, dessen Dimensionalität der Anzahl der mehreren Zeitreihen 20 von Daten entspricht, durch Kombinieren eindimensionaler Clusters je Zeitreihe 20 von Daten umfassen. Werden zum Beispiel die y-Werte der zeitgeordneten Datenpunkte 21 einer Zeitreihe (z.B. der Fahrzeuggeschwindigkeit) in zwei Clusters geclustert und die y-Werte der zeitgeordneten Datenpunkte 21 einer zweiten Zeitreihe (z.B. der Lenkgeschwindigkeit) in drei Clusters geclustert, können sechs höherdimensionale (hier: zweidimensionale) Clusters in dem (Vektor-)Raum definiert werden.
Weiterhin kann das Erzeugen 130 des Spurgraphen Identifizieren von mindestens einem Cluster (z.B. einem höher-dimensionalen Wertebereich) als Knoten im Spurgraphen 30 umfassen. In der Regel werden mindestens zwei Clusters als Knoten identifiziert, da anderenfalls der Spurgraph keine Kante und somit keinen Übergang zwischen Zuständen enthalten kann. Das Erstellen von Knoten im Spurgraphen kann eine Zustand-zu-Vektor Transformation bezüglich des einen oder der mehreren Merkmale umfassen. Weiterhin kann das Erzeugen 130 des Spurgraphen Analysieren der Übergänge zwischen Clusters anhand der zeitgeordneten Datenpunkte 21 und Identifizieren von mindestens einem Übergang als Kante zwischen zwei Knoten im Spurgraphen 30 umfassen. Das Erzeugen 130 des Spurgraphen kann optional Auswerten der Häufigkeit eines Clusters und/oder der Verweildauer eines Clusters anhand der zeitgeordneten Datenpunkte 21 umfassen. Das Erzeugen 130 des Spurgraphen kann optional Hinzufügen der Häufigkeit eines Clusters und/oder der Verweildauer eines Clusters an den mit dem Cluster identifizierten Knoten im Spurgraphen 30 umfassen. Die Clusterbildung kann derart ausgelegt sein, dass im Zuge der Clusterbildung irrelevante und/oder redundante Information in dem einen oder den mehreren Zeitschrieben eliminiert wird.
Das Prüfen 140, ob der erzeugte Spurgraph 30 im Vergleich zu dem einem oder den mehreren vorhandenen Spurgraphen 40 neu ist (oder als neu bewertet wird), kann Anwenden eines Maschinenlernalgorithmus umfassen, der dafür ausgelegt ist und anhand von Trainingsdaten trainiert worden ist, ein kategorisches (z.B. durch eine Klassifikation) und/oder quantifizierbares Maß (z.B. durch eine Regression) für Neuheit des Spurgraphen 30 auszugeben.
Das Prüfen 140, ob der erzeugte Spurgraph 30 im Vergleich zu dem einem oder den mehreren vorhandenen Spurgraphen 40 neu ist (oder als neu bewertet wird), kann (somit) ein vorbestimmtes (Ähnlichkeits-) Kriterium umfassen, das dafür ausgelegt ist, mindestens zwei Spurgraphen vergleichen zu können. Dazu kann beispielsweise zunächst die Anzahl der Knoten in den zwei Spurgraphen verglichen werden. Alternativ oder zusätzlich kann die Anzahl der Kanten in den zwei Spurgraphen verglichen werden. Weiterhin kann z.B. die Anzahl der übereinstimmenden Knoten in den zwei Spurgraphen ermittelt werden. Alternativ oder zusätzlich kann auch die Anzahl der übereinstimmenden Kanten zwischen übereinstimmenden Knoten in den zwei Spurgraphen ermittelt werden. Alternativ oder zusätzlich können die den Knoten und/oder Kanten zugeordneten Parameter miteinander verglichen werden. Dabei kann es vorteilhaft sein, die Knoten beispielsweise nach ihrem Vektor geordnet anzuordnen. Dadurch können z.B. auch je zwei nicht übereinstimmende aber sich nahestehende Knoten aus beiden Spurgraphen identifiziert werden. Alternativ oder zusätzlich können die Spurgraphen in einen (metrischen) Raum eingebettet werden. Dadurch kann dann über eine Metrik ein Abstand zwischen den Spurgraphen ermittelt werden. Dabei können bekannte Abstandsmaße wie der Levenshtein-Abstand (z.B. nach Transformation der Spurgraphen in je eine Zeichenkette), der Hamming-Abstand, kürzeste Durchschnittspfade und/oder Euklidische Oberflächen angewandt werden. Weiterhin kann ein vorbestimmter Schwellwert für den Abstand zwischen Spurgraphen definiert werden, oberhalb dessen die Unterschiedlichkeit als neu und/oder unbekannt bewertet wird.
Der erste Speicher kann ein Ringspeicher sein. Ein Ringspeicher kann für die temporäre Speicherung praktisch sein. Der erste und der zweite Speicher können auch logische Einheiten ein und desselben Speichers sein.
Ein Fahrer oder ein Insasse (allgemein: Nutzer) des Fahrzeugs 10 kann veranlassen 160 (z.B. über eine Nutzerschnittstelle des Fahrzeugs), dass die zeitgeordneten Datenpunkte 21 (d.h. die zuletzt im ersten Speicher gespeicherten zeitgeordneten Datenpunkte), in dem zweiten Speicher gespeichert werden. Dadurch können solche Betriebs-/Fahrszenarien, die der Nutzer als interessant, problematisch und/oder unsicher wahrgenommen hat, weiter analysiert und in der Zukunft mitunter verhindert oder verbessert werden.
Weiterhin können in dem zweiten Speicher gespeicherte zeitgeordnete Datenpunkte 21 manuell (z.B. über die Nutzerschnittstelle des Fahrzeugs und/oder ein im Fahrzeug befindliches Mobilgerät) oder automatisch (z.B. in einer gewissen Periodizität: jeden Tag, jede Woche, jeden Monat, jedes Jahr,...) über mindestens ein Kommunikationsmodul des Fahrzeugs 10 auf einen (Cloud) Server außerhalb des Fahrzeugs 10 hochgeladen werden 170. Somit können Daten in den zweiten Speicher gespeichert werden, die für den Upload auf den (Cloud) Server vorgesehen sind. Alternativ oder zusätzlich können auch der jeweils (bei Wiederholung des Verfahrens 100) erzeugte Spurgraph 30, so er z.B. nach erfolgreicher Prüfung 140 im zweiten Speicher gespeichert worden ist, auf den (Cloud) Server außerhalb des Fahrzeugs 10 hochgeladen werden 170. Durch das Hochladen 170 können die zeitgeordneten Datenpunkte 21 und/oder erzeugten Spurgraphen 30 und somit die als neu erkannten Betriebs-/Fahrszenarien z.B. von Entwicklungs- und/oder Testingenieuren analysiert und bewertet werden. Alternativ oder zusätzlich können die hochgeladenen Daten zur Verbesserung des Fahrzeugs 10 (z.B. über over-the-air Update), insbesondere des zumindest teilautonom operierenden Fahrzeugs, oder weiterer Fahrzeuge (z.B. in neuen Entwicklungsprojekten) eingesetzt werden. Zum Beispiel können die Betriebs-/Fahrszenarien in den hochgeladenen Daten gegebenenfalls gelabelt werden und/oder den Trainingsdatensatz für das überwachte Lernen ergänzen und idealerweise komplettieren.
Das Verfahren kann in einem nächsten Zeitschritt wiederholt werden 180 mit der Maßgabe, dass das Empfangen 110 der einen oder der mehreren Zeitreihen 20 von Daten ein Fortschreiben der einen oder der mehreren Zeitreihen 20 von Daten ist. Im Falle eines Ringspeichers als ersten Speicher kann der Index im Ringspeicher inkrementiert werden, modulo der Größe des Ringspeichers.
Eine Ausführungsform des Verfahrens 100 zur Filterung von Betriebs-/Fahrszenarien während des Fahrbetriebs eines Fahrzeugs 10 ist in 4 dargestellt.
Offenbart wird weiterhin ein Computer-Programm 200, welches dafür ausgelegt ist, das computer-implementierte Verfahren 100 zur Filterung von Betriebs-/Fahrszenarien während des Betriebs eines Fahrzeugs (z.B. während der Fahrt des Fahrzeugs) auszuführen. Das Computer-Programm 200 kann z.B. in interpretierbarer oder in kompilierter Form vorliegen. Es kann zur Ausführung (z.B. als Byte-Folge) in den RAM eines Steuergeräts oder Computer geladen werden. Offenbart wird weiterhin ein computer-lesbares Medium oder Signal 300, das das Computer-Programm 200 speichert und/oder enthält. Das Medium kann z.B. eines von RAM, ROM, EPROM,... umfassen, in dem das Signal gespeichert wird.
Offenbart wird weiterhin ein Computersystem 400, schematisch dargestellt in 2, insbesondere eine Steuereinheit eines Fahrzeugs 10, welches dafür ausgelegt ist, das Computer-Programm 200 auszuführen. Das Computersystem 400 kann insbesondere mindestens einen Prozessor und mindestens einen Arbeitsspeicher umfassen. Das Computersystem 400 kann insbesondere den ersten Speicher (z.B. als Ringspeicher) und/oder den zweiten Speicher umfassen. Weiterhin kann das Computersystem 400 den weiteren Speicher z.B. mit der Datenbank umfassen. Alternativ oder zusätzlich kann das Computersystem 400 die Kommunikationsschnittstelle umfassen, über welche eine Verbindung zu dem (Cloud) Server hergestellt werden kann.

Claims

Computer-implementiertes Verfahren (100) zur Filterung von Betriebsszenarien während des Betriebs eines Fahrzeugs (10), umfassend: Empfangen (110) mindestens einer Zeitreihe (20) von Daten; Speichern (120) von zeitgeordneten Datenpunkten (21) der mindestens einen Zeitreihe (20) von Daten in einem ersten Speicher; Erzeugen (130) eines Spurgraphen (30) für die im ersten Speicher gespeicherten zeitgeordneten Datenpunkte (21); Prüfen (140), ob der erzeugte Spurgraph (30) im Vergleich zu einem oder mehreren vorhandenen Spurgraphen (40) neu ist; Speichern (150) der im ersten Speicher gespeicherten zeitgeordneten Datenpunkte (21) in einem zweiten Speicher, wenn der erzeugte Spurgraph (30) neu ist.
Verfahren (100) nach Anspruch 1, wobei die eine oder die mehreren Zeitreihen (20) von Daten über mindestens einen Sensor (11) eines Fahrzeugs (10) während des Fahrbetriebs erfasst werden, optional wobei die eine oder die mehreren Zeitreihen (20) von Daten einen Videodatenstrom, RADAR-Daten, LIDAR-Daten, Positionsdaten, Umgebungsdaten, Fahrzeugdaten und/oder Benutzerdaten umfassen.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die zeitgeordneten Datenpunkte (21) der einen oder der mehreren Zeitreihen (20) von Daten einem unmittelbar zurückliegenden Zeitraum und/oder einer Anzahl von unmittelbar zurückliegenden Datenpunkten der mindestens einen Zeitreihe von Daten entsprechen.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die zeitgeordneten Datenpunkte (21) der einen oder der mehreren Zeitreihen (20) von Daten ein Betriebsszenario beschreiben und/oder charakterisieren.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei der Spurgraph (30) ein Graph ist, umfassend: einen oder mehrere Knoten, wobei jeder Knoten einem Wertebereich von Daten in einem durch die Wertebereiche der zeitgeordneten Datenpunkte (21) aufgespannten Raum entspricht; keine oder eine Kante zwischen je zwei Knoten, wobei jede Kante mindestens eine Pfeilrichtung aufweist, optional auch entgegengesetzte Pfeilrichtungen aufweisen kann, wobei die Pfeilrichtung jeweils die Richtung eines Übergangs zwischen den Knoten zugehörigen Wertebereichen anzeigt.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wenn abhängig von Anspruch 5, wobei das Erzeugen (130) des Spurgraphen (30) für die im ersten Speicher gespeicherten zeitgeordneten Datenpunkte (21) umfasst: Clustern von y-Werten der zeitgeordneten Datenpunkte (21) der mindestens einen Zeitreihe (20) von Daten oder der mehreren Zeitreihen (20) von Daten in mindestens zwei Clusters in einem Raum, dessen Dimensionalität der Anzahl der mindestens einen Zeitreihe (20) von Daten oder der mehreren Zeitreihen (20) von Daten entspricht, optional mittels unüberwachtem Lernen; Identifizieren von mindestens einem Cluster als Knoten im Spurgraphen (30); Analysieren der Übergänge zwischen Clusters anhand der zeitgeordneten Datenpunkte (21); Identifizieren von mindestens einem Übergang als Kante zwischen zwei Knoten im Spurgraphen (30); optional Auswerten der Häufigkeit eines Clusters und/oder der Verweildauer eines Clusters anhand der zeitgeordneten Datenpunkte (21); optional Hinzufügen der Häufigkeit eines Clusters und/oder der Verweildauer eines Clusters an den mit dem Cluster identifizierten Knoten im Spurgraphen (30).
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei der erste Speicher ein Ringspeicher ist.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei in dem zweiten Speicher gespeicherte zeitgeordnete Datenpunkte (21) manuell oder automatisch über mindestens ein Kommunikationsmodul des Fahrzeugs (10) auf einen Server außerhalb des Fahrzeugs (10) hochgeladen werden (170).
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Verfahren in einem nächsten Zeitschritt wiederholt wird (180) mit der Maßgabe, dass das Empfangen (110) der einen oder der mehreren Zeitreihen (20) von Daten ein Fortschreiben der einen oder der mehreren Zeitreihen (20) von Daten ist.
Ein Computer-Programm (200), welches dafür ausgelegt ist, das computer-implementierte Verfahren (100) nach einem der vorhergehenden Ansprüche auszuführen.
Computer-lesbares Medium oder Signal (300), das das Computer-Programm (200) nach Anspruch 10 speichert und/oder enthält.
Ein Computersystem (400), insbesondere eine Steuereinheit eines Fahrzeugs (10), welches dafür ausgelegt ist, das Computer-Programm (200) nach Anspruch 10 auszuführen.