Adapterplatine zur Videovorverarbeitung von unverarbeiteten Videodaten auf einem Fahrzeugprozessor und Validierungssystem zum Validieren einer Softwarekomponente für hochautomatisiertes Fahren

Gebiet der Erfindung

Die Erfindung betrifft eine Adapterplatine zur Videovorverarbeitung von unverarbeiteten Videodaten auf einem Fahrzeugprozessor und ein Validierungssystem zum Validieren einer Softwarekomponente für hochautomatisiertes Fahren.

Stand der Technik

Zum hochautomatisierten Fahren eines Fahrzeugs sind Softwarekomponenten erforderlich, die situationsabhängig Steuersignale für das Fahrzeug generieren. Bevor das Fahrzeug mit diesen Softwarekomponenten am Straßenverkehr teilnehmen kann, ist eine Validierung der Softwarekomponenten erforderlich. Dabei werden einer zu validierenden Softwarekomponente aufgezeichnete Fahrsituationen vorgespielt und Reaktionen der Softwarekomponente mit erwarteten Reaktionen verglichen, um eventuelle falsche Reaktionen zu erkennen.

Damit die Softwarekomponente die Fahrsituationen interpretieren kann, ist insbesondere bei Videodaten eine rechenintensive Vorverarbeitung erforderlich. Diese Vorverarbeitung kann in angemessener Zeit nur durch spezialisierte Hardware des Fahrzeugs durchgeführt werden. Die Vorverarbeitung kann daher bereits beim Aufzeichnen der Fahrsituationen im Fahrzeug erfolgen. Die Aufzeichnung der vorverarbeiteten Fahrsituation erfordert eine große Speicherkapazität. Alternativ kann das Fahrzeug im Labor angeschlossen werden, aufgezeichnete Sensordaten in das Fahrzeug eingegeben werden und die Steuersignale aus dem Fahrzeug ausgelesen werden. Dieser Ansatz ist materialintensiv.

Offenbarung der Erfindung

Vor diesem Hintergrund werden mit dem hier vorgestellten Ansatz eine Adapterplatine zur Videovorverarbeitung von unverarbeiteten Videodaten auf einem Fahrzeugprozessor und ein Validierungssystem zum Validieren einer Softwarekomponente für hochautomatisiertes Fahren gemäß den unabhängigen Ansprüchen vorgestellt. Vorteilhafte Weiterbildungen und Verbesserungen des hier vorgestellten Ansatzes ergeben sich aus der Beschreibung und sind in den abhängigen Ansprüchen beschrieben.

Vorteile der Erfindung

Wenn vorverarbeitete Sensordaten von Fahrsituationen aufgezeichnet werden, ist ein erneutes Erfassen der Fahrsituationen, Vorverarbeiten der Sensordaten und Aufzeichnen der vorverarbeiteten Sensordaten erforderlich, wenn eine verwendete Hardware verändert wird. Wenn die Vorverarbeitung während des Abspielens von unverarbeiteten Sensordaten erfolgt, ist das komplette Fahrzeug erforderlich, obwohl die Vorverarbeitung nur durch die spezialisierte Hardware im Fahrzeug erfolgt und wesentliche Teile des Fahrzeugs während der Validierung nicht benutzt werden.

Bei dem hier vorgestellten Ansatz wird die spezialisierte Hardware, insbesondere ein Fahrzeugprozessor aus dem Fahrzeug in ein Computersystem im Labor transplantiert. Der Rest des Fahrzeugs wird dann nicht benötigt. Zum Integrieren in das Computersystem wird die Hardware auf einer speziell dafür konfigurierten Adapterplatine angeordnet und über Standardschnittstellen durch das Computersystem angesprochen. Die Hardware führt die Vorverarbeitung von unvorverarbeiteten Sensordaten durch und gibt vorverarbeitete Sensordaten an das Computersystem zurück. Die zu validierende Softwarekomponente wird auf dem Computersystem ausgeführt und ihre Reaktionen ausgewertet.

Durch den hier vorgestellten Ansatz kann die Vorverarbeitung jeweils mit der aktuellen Hardware durchgeführt werden. Da nur die spezialisierte Hardware verwendet wird, kann der Materialeinsatz geringgehalten werden. Durch die Hardwarebeschleunigung der spezialisierten Hardware kann die Validierung in geringer Zeit erfolgen.

Es wird eine Adapterplatine zur Videovorverarbeitung von unverarbeiteten Videodaten auf einem Fahrzeugprozessor vorgestellt, wobei die unverarbeiteten Videodaten zumindest eine aus einer Fahrzeugperspektive eines Aufnahmefahrzeugs aufgezeichnete Fahrsituation abbilden, wobei die Adapterplatine zumindest den einen Fahrzeugprozessor zur Vorverarbeitung von unverarbeiteten Videodaten zu vorverarbeiteten Videodaten und zumindest eine Standardschnittstelle für die Videodaten aufweist.

Weiterhin wird ein Verfahren zum Validieren einer Softwarekomponente für hochautomatisiertes Fahren vorgeschlagen, wobei unverarbeitete Videodaten, die zumindest eine aus einer Fahrzeugperspektive eines Aufnahmefahrzeugs aufgezeichnete Fahrsituation abbilden, durch ein Datenverarbeitungssystem eingelesen werden und unter Verwendung eines mit dem Datenverarbeitungssystem verbundenen Fahrzeugprozessors zur Videovorverarbeitung (PiL) zu vorverarbeiteten Videodaten verarbeitet werden, wobei der Fahrzeugprozessor auf einer Adapterplatine angeordnet ist und über Standardschnittstellen mit dem Datenverarbeitungssystem verbunden ist, wobei die vorverarbeiteten Videodaten von dem Datenverarbeitungssystem als Eingangsgrößen für die zu validierende Softwarekomponente verwendet werden und eine in Ausgangsgrößen der Softwarekomponente abgebildete Reaktion der Softwarekomponente auf die in den vorverarbeiteten Videodaten abgebildete Fahrsituation von dem Datenverarbeitungssystem mit einer erwarteten Reaktion verglichen wird, um die Softwarekomponente zu validieren.

Weiterhin wird ein Betriebssystem zum Betreiben eines Fahrzeugprozessors zur Videovorverarbeitung von unverarbeiteten Videodaten auf einer Adapterplatine vorgestellt, wobei die unverarbeiteten Videodaten zumindest eine aus einer Fahrzeugperspektive eines Aufnahmefahrzeugs aufgezeichnete Fahrsituation abbilden, wobei das Betriebssystem eine Einleseroutine zum Einlesen der unverarbeiteten Videodaten von einem Datenverarbeitungssystem über eine Standardschnittstelle der Adapterplatine, eine Weitergaberoutine zum bitgenauen und deterministischen Weitergeben der unverarbeiteten Videodaten an den Fahrzeugprozessor, eine Entgegennahmeroutine zum bitgenauen und deterministischen Entgegennehmen von vorverarbeiteten Videodaten von dem Fahrzeugprozessor und eine Bereitstellungsroutine zum Bereitstellen der vorverarbeiteten Videodaten für das Datenverarbeitungssystem über die Standardschnittstelle aufweist.

Ferner wird ein Betriebssystem zum Betreiben einer Adapterplatine zur Videovorverarbeitung von unverarbeiteten Videodaten auf einem Fahrzeugprozessor vorgestellt, wobei die unverarbeiteten Videodaten zumindest eine aus einer Fahrzeugperspektive eines Aufnahmefahrzeugs aufgezeichnete Fahrsituation abbilden, wobei das Betriebssystem eine Bereitstellungsroutine zum Bereitstellen der unverarbeiteten Videodaten für die Adapterplatine über eine Standardschnittstelle eines Datenverarbeitungssystems und eine Einleseroutine zum Einlesen von vorverarbeiteten Videodaten von der Adapterplatine über die Standardschnittstelle aufweist.

Ideen zu Ausführungsformen der vorliegenden Erfindung können unter anderem als auf den nachfolgend beschriebenen Gedanken und Erkenntnissen beruhend angesehen werden.

Eine Softwarekomponente kann ein Computerprogrammprodukt sein. Die Softwarekomponente kann dazu ausgebildet sein, zumindest eine Funktion eines Fahrzeugs hochautomatisiert anzusteuern. Beispielsweise kann die Softwarekomponente eine Trajektorie des Fahrzeugs in Abhängigkeit von einer aktuellen Fahrsituation planen und das Fahrzeug dazu ansteuern, auf dieser Trajektorie zu fahren.

Die Softwarekomponente kann durch eine Überprüfung ihrer Funktion beziehungsweise ihrer Reaktionen auf verschiedene Fahrsituationen validiert werden. Dabei dürfen die Reaktionen maximal um eine Fehlertoleranz von vordefinierten erwarteten Reaktionen abweichen. Die Reaktionen können beispielsweise in ausgegebenen Steuersignalen abgebildet sein.

Eine Fahrsituation kann eine Situation während einer Fahrt eines Fahrzeugs sein. Die Fahrsituation kann feste sowie bewegliche Objekte in einem Umfeld des Fahrzeugs betreffen. Die Fahrsituation kann also Infrastruktur, Hindernisse und andere Verkehrsteilnehmer betreffen. Die Fahrsituation kann Relativbewegungen der enthaltenen Objekte zum Fahrzeug beinhalten. Die Fahrsituation kann auch eine Bewegung des eigenen Fahrzeugs enthalten. Eine momentane Kinematik des Fahrzeugs kann durch die Relativbewegung der festen Objekte zum Fahrzeug in der Fahrsituation enthalten sein. Die Kinematik des Fahrzeugs kann auch durch anderweitig erfasste Kinematikdaten in der Fahrsituation enthalten sein.

Videodaten können Bewegtbildinformationen sein. Die Videodaten können von zumindest einer Videokamera erfasst worden sein. Die Videokamera kann die Fahrsituation erfasst haben. Die erfassten Videodaten können ohne Vorverarbeitung auf einem Speichermedium gespeichert worden sein. Die Videodaten können in der Vergangenheit aufgezeichnet worden sein. Die Videodaten können unter Verwendung eines speziellen Aufnahmefahrzeugs aufgezeichnet worden sein. Die Videodaten können aber auch Aufzeichnungen von einer Flotte von Fahrzeugen sein. Eine Fahrzeugperspektive kann die Fahrsituation aus einer Perspektive des Fahrzeugs mit der Softwarekomponente abbilden.

Ein Datenverarbeitungssystem kann ein Computersystem sein. Das Datenverarbeitungssystem kann insbesondere in einem Labor angeordnet sein. Das Datenverarbeitungssystem kann als Serversystem bezeichnet werden.

Ein Fahrzeugprozessor zur Videovorverarbeitung kann ein spezialisierter Prozessor sein, der für den Anwendungsfall der Vorverarbeitung von Videodaten entwickelt worden ist. Der Fahrzeugprozessor kann Videodaten um ein Vielfaches schneller vorverarbeiten als ein Prozessor des Datenverarbeitungssystems. Der Fahrzeugprozessor kann im Normalfall in einem Fahrzeug verbaut sein. Der Fahrzeugprozessor kann in einem Fahrzeug direkt mit zumindest einer Videokamera des Fahrzeugs verbunden sein. Der Fahrzeugprozessor kann die Videodaten in Echtzeit vorverarbeiten.

Eine Adapterplatine ermöglicht ein Ansteuern des Fahrzeugprozessors durch das Datenverarbeitungssystem. Die Adapterplatine ermöglicht einen Datenaustausch zwischen dem Datenverarbeitungssystem und dem Fahrzeugprozessor über Standardschnittstellen. Die Adapterplatine weist auch eine Fahrzeugschnittstelle zu dem Fahrzeugprozessor auf. Die Adapterplatine weist keine überflüssigen Komponenten auf. Auf der Adapterplatine beziehungsweise auf dem Fahrzeugprozessor wird ein Betriebssystem ausgeführt, das den Datenaustausch mit dem Datenverarbeitungssystem orchestriert. Eine Standardschnittstelle kann eine üblicherweise in einem Computersystem verwendete Schnittstelle sein. Die Standardschnittstelle kann genormt sein, zumindest eine Standardschnittstelle kann beispielsweise an einem Steckplatz des Datenverarbeitungssystems angeordnet sein. Die Adapterplatine kann in den Steckplatz eingesteckt sein und so über die Standardschnittstelle kontaktiert sein.

Ein Betriebssystem zum Betreiben des Fahrzeugprozessors kann auf der Adapterplatine ausgeführt werden. Das Betriebssystem kann auf die Adapterplatine aufgespielt sein. Alternativ kann das Betriebssystem zum Betreiben des Fahrzeugprozessors auch auf dem Fahrzeugprozessor ausgeführt werden. Ein Betriebssystem zum Betreiben der Adapterplatine kann auf dem Datenverarbeitungssystem ausgeführt werden.

Die Betriebssysteme können in Programmcode abgebildete Routinen aufweisen. Die Routinen können eine Handhabung von Daten beschreiben. Die Routinen können beispielsweise Datenregister des Datenverarbeitungssystems, der Adapterplatine und/oder des Fahrzeugprozessors ansprechen. Die Routinen können auch eine Datenübertragung über die Standardschnittstellen beschreiben.

Eine Bereitstellungsroutine kann eine Bereitstellung der unverarbeiteten Videodaten beziehungsweise vorverarbeiteten Videodaten in einer über die Standardschnittstelle übertragbaren Form und Geschwindigkeit kontrollieren. Eine Einleseroutine kann ein Gegenpart zur Bereitstellungsroutine sein. Die Einleseroutine kann ein Einlesen der unverarbeiteten Videodaten beziehungsweise vorverarbeiteten Videodaten in der über die Standardschnittstelle übertragbaren Form und Geschwindigkeit kontrollieren.

Eine Weitergaberoutine kann eine Weitergabe der unverarbeiteten Videodaten in einer für den Fahrzeugprozessor vorgesehenen Form und Geschwindigkeit kontrollieren. Eine Entgegennahmeroutine kann eine Entgegennahme der Vorverarbeiteten Videodaten in der für den Fahrzeugprozessor vorgesehenen Form und Geschwindigkeit kontrollieren.

Die Betriebssysteme können als ein zusammenhängendes

Computerprogrammprodukt programmiert sein. Beim Aufspielen auf das

Datenverarbeitungssystem, die Adapterplatine und/oder den Fahrzeugprozessor können anwendbare Routinen aktiviert werden, während nicht anwendbare Routinen nicht aktiviert werden. Das Betriebssystem kann ein Linux- Betriebssystem sein.

Unter Verwendung des Fahrzeugprozessors kann ein optischer Fluss der Videodaten berechnet werden. Der optische Fluss kann in die vorverarbeiteten Videodaten eingebettet werden. Eine Berechnung des optischen Flusses von Videodaten kann sehr rechenintensiv sein. Der Fahrzeugprozessor kann den optischen Fluss in kurzer Zeit berechnen. Durch die Berechnung des optischen Flusses im Fahrzeugprozessor kann die Validierung der Softwarekomponente mit einer hohen Geschwindigkeit durchgeführt werden.

Unter Verwendung des Fahrzeugprozessors können Tiefeninformationen aus den Videodaten berechnet werden. Die Tiefeninformationen können in die vorverarbeiteten Videodaten eingebettet werden. Eine Berechnung der Tiefeninformationen in Videodaten kann sehr rechenintensiv sein. Der Fahrzeugprozessor kann Tiefeninformationen in kurzer Zeit berechnen.

Unter Verwendung des Fahrzeugprozessors können die unverarbeiteten Videodaten rektifiziert werden. Eine Rektifizierung von Videodaten kann sehr rechenintensiv sein. Der Fahrzeugprozessor kann die Videodaten in kurzer Zeit rektifizieren.

Eine Fortschrittsinformation kann von der Softwarekomponente eingelesen werden. Unter Verwendung der Fortschrittsinformation können Steuersignale erzeugt werden. Die unverarbeiteten Videodaten können ansprechend auf die Steuersignale Schritt für Schritt an den Fahrzeugprozessor übergeben werden. Alternativ oder ergänzend können die vorverarbeiteten Videodaten ansprechend auf die Steuersignale Schritt für Schritt für die Softwarekomponente bereitgestellt werden. Eine Bearbeitungsgeschwindigkeit des Fahrzeugprozessors kann durch die Softwarekomponente vorgegeben werden. Die Fortschrittsinformation kann einen Takt der Vorverarbeitung vorgeben, Durch die Schritt-für-Schritt- Vorverarbeitung kann auf Zwischenspeicherung der vorverarbeiteten Videodaten verzichtet werden. Die Fortschrittsinformation kann von zumindest einem der Betriebssysteme eingelesen und verarbeitet werden. Die Routinen der Betriebssysteme können durch die Steuersignale synchronisiert werden. Das Betriebssystem zum Betreiben der Adapterplatine kann eine Steuerroutine zum Bereitstellen von Steuersignalen für die Adapterplatine über eine weitere Standardschnittstelle des Datenverarbeitungssystems aufweisen. Die Steuerroutine kann dazu ausgebildet sein, eine Fortschrittsinformation von der Softwarekomponente einzulesen und unter Verwendung der Fortschrittsinformation die Steuersignale zu erzeugen. Die auf der Adapterplatine ausgeführte Weitergaberoutine kann dazu ausgebildet sein, ansprechend auf die über die weitere Standardschnittstelle der Adapterplatine von dem Datenverarbeitungssystem eingelesene Steuersignale die unverarbeiteten Videodaten Schritt für Schritt an den Fahrzeugprozessor weiterzugeben. Die Entgegennahmeroutine kann dazu ausgebildet sein, die vorverarbeiteten Videodaten ansprechend auf die Steuersignale Schritt für Schritt von dem Fahrzeugprozessor entgegenzunehmen.

Die unverarbeiteten Videodaten können in Bulks an die Adapterplatine übergeben werden. Ein Bulk kann ein Datenpaket sein. Beispielsweise kann ein Bulk eine vorbestimmte Anzahl Einzelbilder oder eine vordefinierte Zeitdauer aufweisen. Durch eine bulkweise Verarbeitung der Videodaten kann der Fahrzeugprozessor mit voller Kapazität betrieben werden. Die Bereitstellungsroutinen und Einleseroutinen können die bulkweise Übergabe kontrollieren.

Zumindest eine der Standardschnittstellen kann als Datenschnittstelle ausgebildet sein. Insbesondere kann die Datenschnittstelle als PCIe-Schnittstelle ausgeführt sein. Eine Datenschnittstelle kann für hohe Datendurchsätze konfiguriert sein. Die unverarbeiteten Videodaten sind bereits sehr groß. Durch die Vorverarbeitung kann eine Datenmenge der vorverarbeiteten Videodaten noch anwachsen. Über die Datenschnittstelle können die Videodaten in Echtzeit übertragen werden. Die Bereitstellungsroutinen und Einleseroutinen können für die Datenschnittstelle konfiguriert sein. Zum Übertragen der unverarbeiteten Videodaten und zum Übertragen der vorverarbeiteten Videodaten kann die PCIe- Schnittstelle angesprochen werden.

Zumindest eine der Standardschnittstellen kann als Steuerungsschnittstelle ausgebildet sein. Insbesondere kann die Steuerungsschnittstelle als Ethernetschnittstelle ausgeführt sein. Zum Übertragen der Steuersignale kann die Ethernet-Schnittstelle angesprochen werden. Eine Steuerungsschnittstelle kann ein robustes Kommunikationsprotokoll aufweisen. Über die

Steuerungsschnittstelle können die Steuersignale verlustlos übertragen werden.

Der Fahrzeugprozessor kann austauschbar sein. Beispielsweise wenn ein verbesserter Fahrzeugprozessor verfügbar ist, kann die Adapterplatine aktualisiert werden. Ebenso kann der Fahrzeugprozessor bei einem Defekt getauscht werden.

Die Betriebssysteme können aktualisiert werden. Neue Betriebssysteme können auf das Datenverarbeitungssystem, die Adapterplatine und/oder den Fahrzeugprozessor aufgespielt werden.

Die Adapterplatine kann Betriebseinrichtungen zum Betreiben des Fahrzeugprozessors aufweisen. Die Betriebseinrichtungen können auf minimale Anforderungen des Fahrzeugprozessors abgestimmt sein. Das Betriebssystem zum Betreiben des Fahrzeugprozessors kann auf den Betriebseinrichtungen ausgeführt werden. Die Betriebseinrichtungen können beispielsweise Datenregister umfassen.

Die Adapterplatine kann kühlerlos sein. Im Datenverarbeitungssystem herrschen wesentlich niedrigere Temperaturen als im Fahrzeug möglich sind. Die Adapterplatine kann einfach aufgebaut sein. Es ist nicht erforderlich die Adapterplatine auf die Extrembedingungen im Fahrzeug auszulegen. Der Fahrzeugprozessor kann durch einen Lüfter des Datenverarbeitungssystems gekühlt werden.

Das Verfahren ist vorzugsweise computerimplementiert und kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät implementiert sein.

Der hier vorgestellte Ansatz schafft ferner ein Validierungssystem zum Validieren einer Softwarekomponente für hochautomatisiertes Fahren, das dazu ausgebildet ist, um die Schritte einer Variante des hier vorgestellten Verfahrens in entsprechenden Einrichtungen durchzuführen, anzusteuern bzw. umzusetzen. Das Validierungssystem weist ein Datenverarbeitungssystem und zumindest eine Adapterplatine gemäß dem hier vorgestellten Ansatz auf. Von Vorteil ist auch ein Computerprogrammprodukt oder Computerprogramm mit Programmcode, der auf einem maschinenlesbaren Träger oder Speichermedium wie einem Halbleiterspeicher, einem Festplattenspeicher oder einem optischen Speicher gespeichert sein kann und zur Durchführung, Umsetzung und/oder Ansteuerung der Schritte des Verfahrens nach einer der vorstehend beschriebenen Ausführungsformen verwendet wird, insbesondere wenn das Programmprodukt oder Programm auf einem Computer oder einer Vorrichtung ausgeführt wird.

Es wird darauf hingewiesen, dass einige der möglichen Merkmale und Vorteile der Erfindung hierin mit Bezug auf unterschiedliche Ausführungsformen beschrieben sind. Ein Fachmann erkennt, dass die Merkmale des Steuergeräts und des Verfahrens in geeigneter Weise kombiniert, angepasst oder ausgetauscht werden können, um zu weiteren Ausführungsformen der Erfindung zu gelangen.

Kurze Beschreibung der Zeichnung

Nachfolgend werden Ausführungsformen der Erfindung unter Bezugnahme auf die beigefügte Zeichnung beschrieben, wobei weder die Zeichnung noch die Beschreibung als die Erfindung einschränkend auszulegen sind.

Fig. 1 zeigt eine Darstellung eines Validierungssystems gemäß einem Ausführungsbeispiel;

Die Figur ist lediglich schematisch und nicht maßstabsgetreu. Gleiche Bezugszeichen bezeichnen gleiche oder gleichwirkende Merkmale.

Ausführungsformen der Erfindung

Fig. 1 zeigt eine Darstellung eines Validierungssystems 100 gemäß einem Ausführungsbeispiel. Das Validierungssystem 100 besteht aus einem Datenverarbeitungssystem 102 und zumindest einem mit dem Datenverarbeitungssystem 102 über eine Adapterplatine 104 verbundenen Fahrzeugprozessor 106 zur Vorverarbeitung von unverarbeiteten Videodaten 108 zu vorverarbeiteten Videodaten 110. Gleichartige Fahrzeugprozessoren können in hochautomatisierten Fahrzeugen verbaut sein, um unverarbeitete Videodaten von Videosensoren der Fahrzeuge für nachfolgende Verwendungen vorzuverarbeiten. Auf der Adapterplatine 104 beziehungsweise dem Fahrzeugprozessor ist ein Betriebssystem 112 zum Betreiben des Fahrzeugprozessors 106 installiert. Auf dem Datenverarbeitungssystem 102 ist ein entsprechendes Betriebssystem 114 zum Betreiben der Adapterplatine 104 installiert. Die Betriebssysteme 112, 114 können auch als Treiber für die Adapterplatine 104 beziehungsweise den Fahrzeugprozessor 106 bezeichnet werden. In einem Ausführungsbeispiel basieren die Betriebssysteme 112, 114 auf dem Linux-Betriebssystem.

Das Validierungssystem 100 ist dazu konfiguriert, eine Softwarekomponente 116 für hochautomatisierte Fahrzeuge zu validieren. Das Validieren kann als Recomputing bezeichnet werden. Das Validieren kann im Labor erfolgen. Die Softwarekomponente 116 wird dazu auf dem Datenverarbeitungssystem 102 ausgeführt und die vorverarbeiteten Videodaten 110 von unterschiedlichen abgespeicherten Fahrsituationen 118 werden von dem Datenverarbeitungssystem 102 für die Softwarekomponente 116 als Eingangsgrößen bereitgestellt. Die in Ausgangsgrößen der Softwarekomponente 116 abgebildeten Reaktionen 120 der Softwarekomponente 116 auf die Fahrsituationen 118 werden von dem Datenverarbeitungssystem 102 ausgewertet, um die Softwarekomponente 116 zu validieren. Dabei werden die Reaktionen 120 mit erwarteten Reaktionen 122 verglichen und eine bestimmungsgemäße Funktion der Softwarekomponente 116 erkannt, wenn die Reaktionen 120 im Wesentlichen den erwarteten Reaktionen 122 entsprechen.

Das Datenverarbeitungssystem 102 ist bei dem hier vorgestellten Ansatz ein aus Standardprozessoren und Standardkomponenten aufgebautes Serversystem und ist in einer Laborumgebung angeordnet. Die Videodaten werden von dem Datenverarbeitungssystem 102 unverarbeitet beziehungsweise als Rohdaten von einem Speichermedium 124, wie beispielsweise zumindest einer Festplatte eingelesen und an den Fahrzeugprozessor 106 übergeben. Die Übergabe wird durch die entsprechenden Betriebssysteme 112, 114 gesteuert. Der Fahrzeugprozessor 106 verarbeitet die unverarbeiteten Videodaten 108 zu den vorverarbeiteten Videodaten 110 und übergibt die vorverarbeiteten Videodaten 110 wieder an das Datenverarbeitungssystem 102. Die vorverarbeiteten Videodaten 110 werden dann der Softwarekomponente 110 als die Eingangsgrößen übergeben. Die Übergabe wird wieder durch die entsprechenden Betriebssysteme 112, 114 gesteuert.

Die unverarbeiteten Videodaten 108 sind von zumindest einem Aufnahmefahrzeug während realen Fahrsituationen aus einer Fahrzeugperspektive aufgezeichnet worden und auf dem Speichermedium 124 abgespeichert worden, um für das Validieren mehrfach die gleichen Fahrsituationen verwenden zu können, wenn sich beispielsweise ein Entwicklungsstand der Softwarekomponente 116 ändert.

Die Adapterplatine 104 ist über Standardschnittstellen 126 mit dem Datenverarbeitungssystem 102 verbunden. Dabei werden die unverarbeiteten Videodaten 108 und die vorverarbeiteten Videodaten 110 über eine schnelle Datenschnittstelle 128, wie beispielsweise eine PCIe-Schnittstelle ausgetauscht. Über eine Steuerungsschnittstelle 130, wie beispielsweise eine Ethernet- Schnittstelle, werden Steuersignale 132 zum Ansteuern des Fahrzeugprozessors 106 übertragen.

In einem Ausführungsbeispiel wird unter Verwendung des Fahrzeugprozessors 106 ein optischer Fluss 134 der unverarbeiteten Videodaten 108 berechnet. Die Videodaten werden mit dem optischen Fluss 134 angereichert und so zu den vorverarbeiteten Videodaten 110. Durch das Anreichern der Videodaten wird eine Datenmenge der Videodaten vergrößert.

In einem Ausführungsbeispiel werden unter Verwendung des Fahrzeugprozessors 106 aus den unverarbeiteten Videodaten 108 Tiefeninformationen 136 berechnet. Die Tiefeninformationen 136 werden in die Videodaten eingebettet.

In einem Ausführungsbeispiel wird ein Fortschritt der Softwarekomponente 116 überwacht und die Vorverarbeitung auf dem Fahrzeugprozessor 106 mit dem Fortschritt synchronisiert. Dazu wird eine den Fortschritt repräsentierende Fortschrittsinformation 138 von der Softwarekomponente 116 eingelesen und unter Verwendung der Fortschrittsinformation 138 Steuersignale 132 für den Fahrzeugprozessor 106 erzeugt. Dadurch kann der Fahrzeugprozessor 106 Schritt für Schritt angesteuert werden. In einem Ausführungsbeispiel ist der Fahrzeugprozessor 106 gesockelt und somit austauschbar.

In einem Ausführungsbeispiel sind auf der Adapterplatine 104 Betriebseinrichtungen 140 zum Betreiben des Fahrzeugprozessors 106 angeordnet. Die Betriebseinrichtungen 140 sind beispielsweise Datenregister, die von dem Betriebssystem 112 angesprochen werden, um die Übergabe der unverarbeiteten Videodaten 108 und vorverarbeiteten Videodaten 110 bitgenau und deterministisch zu steuern.

In einem Ausführungsbeispiel weist die Adapterplatine 104 keinen Kühler für den Fahrzeugprozessor 106 auf. Durch den Verzicht auf den Kühler kann die Adapterplatine in einem Standard-Steckplatz des Datenverarbeitungssystems 102 eingesteckt sein.

Nachfolgend werden mögliche Ausgestaltungen der Erfindung nochmals zusammengefasst bzw. mit einer geringfügig anderen Wortwahl dargestellt.

Es wird Processor in the Loop (PiL)-Hardware zur Videodatenvorverarbeitung beim Recomputing vorgestellt.

Der hier vorgestellte Ansatz bezieht sich auf die Videodatenvorverarbeitung im Kontext einer Software open Loop (SoL) Testplattform für das hochautomatisierte Fahren. Beim Testen und der Freigabe der Komponenten für das hochautomatisierte Fahren werden große reale (im Fahrzeug aufgezeichnete) Datenmengen der Sensoren, die verschiedene Fahrsituationen und Umgebungen umfassen, softwareseitig nachträglich abgespielt, um die Funktion der Softwarekomponenten während der Entwicklung sicherstellen zu können. Dies soll in einer angemessenen Testzeit erfolgen. Dabei sind gerade bei den Videosensoren wie der SVC die aufgezeichneten Datenmengen sehr groß. Hinzu kommt, dass diese Sensoren zur Datenvorverarbeitung, wie der Berechnung des optischen Flusses und von Tiefeninformationen spezielle Hardware im Fahrzeug benötigen, um die Zeitvorgaben zu erreichen. Diese Vorverarbeitungen reichern die Daten zusätzlich an und vergrößern sie. Dieser Ablauf im Fahrzeug kann zu Problemen im Recomputing führen.

Einerseits gibt es die Möglichkeit, die vorverarbeiteten Daten im Fahrzeug aufzuzeichnen und dann im Recomputing abzuspielen. So kann die eigentliche Hardware des Fahrzeugs genutzt werden und es muss kein weiterer Aufwand getrieben werden. Allerdings sind die abzuspeichernden Datenmengen groß, das heißt, entsprechend teurer Speicher ist erforderlich. Entwickeln sich die Hardware und die Embedded Software evolutionär weiter oder werden Bugs gefixt, können zuvor aufgezeichnete Daten nicht mehr verwendet werden und es wird erforderlich, neue Fahrsituationen aufzuzeichnen, was zu einem erhöhten Aufwand und zum Verlust wichtiger Tests zu sehr seltenen Situationen führen kann.

Andererseits gibt es die Möglichkeit, in einem HoL (Hardware open Loop) Ansatz in Rechenzentren die Hardware aus dem Fahrzeug zu verbauen. Im Auto selbst werden dann die Rohdaten der Sensoren aufgezeichnet, welche im Rechenzentrum unabhängig weiterverarbeitet werden können. Dies hat den Vorteil, dass Änderungen an Hard- und Software abbildbar sind und Daten nicht verloren gehen. Allerdings bleiben der Speicheraufwand und es sind größere Mengen an Hardware erforderlich, die in entsprechend designten Rechenzentren verbaut und angesprochen werden. Dies kann gerade bei Freigabeszenarien, bei denen mehrere tausend Stunden Videomaterial möglichst schnell verarbeitet werden müssen, sehr teuer werden.

Eine weitere Möglichkeit ist, die Vorverarbeitung in Software auf Standard-CPUs umzusetzen. Dadurch fällt der Speicheraufwand weg, da die Orchestrierung im SoL- Kontext softwareseitig möglich ist. Zudem können aktualisierte Softwarestände immer wieder neu verwendet werden. Allerdings ist die Bildverarbeitung auf nicht speziell dafür ausgelegter Hardware extrem (ca. 1000- mal) langsamer, was die Lösung für große Datenmengen zur Softwarefreigabe unpraktikabel macht.

Hier wird ein die Hardware eines Systems vorgestellt, welches die Vorteile aus den oben genannten Möglichkeiten vereint und zudem direkt in einem SoL- Recomputing Prozess verwendet und orchestriert werden kann. Es wird der PiL (Processor in the Loop) eingeführt. Der PiL ist eine eigens für das Recomputing entwickelte, leichtgewichtige Hardware mit entsprechender Simulationssoftware, die den zentralen Chip der Fahrzeughardware verbaut, aber im Simulationskontext von Software angesprochen und in Standard-Servern mittels PCIe-Schnittstelle zur Datenübertragung und Ethernet-Schnittstelle zur Steuerung verbaut werden kann. Dadurch ist es nicht erforderlich vorverarbeitete Daten abzuspeichern, da der zentrale Chip wie im Fahrzeug verwendet wird. Softwareänderungen können in der Simulation nachvollzogen werden und wichtige Rohdaten können zur Freigabe von Fahrzeugfunktionen dauerhaft verwendet werden.

Bisher werden SoL/SiL-Systeme, die eine softwareseitige(s) Recomputing bzw. Simulation ermöglichen oder HoL/HiL-Systeme, die mit der konkret entwickelten und im Fahrzeug verbauten Hardware als Grundlage die zu testende Software abspielen, verwendet. Beide Ansätze haben gewisse Vor- und Nachteile bezüglich Realitätsnähe, Schnelligkeit, Kosten, Aufwand. Diese Vor- und Nachteile können und werden durch optimierte Methoden und Optimierungen mitigiert, allerdings bleiben sie bestehen. Der hier vorgestellte Ansatz ist eine Optimierung, die das Beste aus beiden Welten vereint und die Vorteile in den Vordergrund stellt. Einen ähnlichen leichtgewichtigen Ansatz gibt es bisher noch nicht.

Durch den hier vorgestellten Ansatz ergibt sich die Möglichkeit, spezialisierte Hardware für besondere Einsatzzwecke, wie der Bildvorverarbeitung einer SVC im hochautomatisierten Fahrzeug, leichtgewichtig in einer softwaregestützten Resimulation/Recomputing verfügbar zu machen und diese dadurch zu beschleunigen. Mit Standard- Hardware (CPU, GPU) sind diese speziellen Aufgaben nicht in einem vertretbaren Zeitrahmen zu erledigen. Nur die spezialisierte und teilweise auch eigenentwickelte Hardware vermag dies. Allerdings ist der Einsatz der Hardware, die auch im Fahrzeug verbaut wird, sehr teuer, da ganze Platinen, die noch einige weitere Komponenten um den spezialisierten Chip herum verbauen, die aber nicht unbedingt im Recomputing benötigt werden, verwendet werden. Zudem sind dann spezielle HoL-Systeme nötig, die diese Hardware wie im Fahrzeug ansprechen und orchestrieren können.

Der Ansatz des PiL ist hingegen, den spezialisierten Chip auf eine einfache Platine zu bringen, die mittels einer PCIe- und Ethernetschnittstelle in einem Server verbaut werden kann. So wird es möglich, mittels Software, die Recompute-Tests durchführt auch die spezialisierte Hardware zu nutzen, zu orchestrieren und zu skalieren. Die Platine selbst ist dabei so designed, dass es möglichst einfach ist, den spezialisierten Chip auszutauschen, wenn neuere Modelle auf den Markt kommen (siehe V3H vs. V3U beispielsweise). Dazu ist es nur erforderlich, gewisse Leiterbahnen umzurouten. Es wird eine leichtgewichtige Platine mit spezialisiertem Chip vorgestellt, die eine Serverschnittstelle bietet, um sie in SiL/SoL-Systemen zu verwenden. Dabei werden Standardschnittstellen wie PCIe und Ethernet verwendet, um keine spezielle Serverhardware zu benötigen. Auch ist das Design der Platine so ausgelegt, dass der spezialisierte Chip in weiteren Versionen austauschbar bleibt. Das heißt auch, dass möglichst wenige weiter Komponenten verbaut werden. So sind zum Beispiel keine Kühler oder ähnliches verbaut.

Dadurch können die Vorteile des spezialisierten Chips (Hardwarebeschleunigung, Nähe zum realen Einsatz) mit den Vorteilen des softwareseitigen Recomputing (Flexibilität, große Datenmengen, günstig) vereinigt werden. Zusätzlich bleibt der Vorteil, dass Änderungen der Hardware und Simulationssoftware abbildbar bleiben und alte im Fahrzeug aufgezeichnete Daten im Recomputing Bestand haben. Insbesondere seltene Fahrsituationen sind dabei wertvoll. Dadurch das die Platine im Vergleich zum Steuergerät auch sehr günstig ist, lässt sich der hier vorgestellte Ansatz auch im Sinne einer Softwaresimulation sehr gut skalieren.

Die hier vorgestellte Hardware des PiL dient dazu, spezialisierte Hardware-Chips für Datenvorverarbeitungen in einem softwareseitigen Recomputing im Serververbund zur Verfügung zu stellen. Dazu ist die Platine als leichtgewichtige Adapterplatine designed, die sehr einfach gehalten ist. Sie beinhaltet eine PCIe- Schnittstelle zur Datenübertragung und eine Ethernet-Schnittstelle für Steuersignale. Der spezialisierte IP-Chip ist dann das einzig weitere große Bauteil. Die restliche Hardware besteht nur aus kleinen Komponenten, die der IP- Chip benötigt. Der IP-Chip selbst enthält ein leichtgewichtiges Linux-System, in dem eine Simulationssoftware laufen kann, die die Hardwarekomponenten abhängig von den Steuersignalen anspricht und die Ergebnisse bereitstellt. Die Daten kommen über den Host-Server, der als Bare- Metal-Server oder VM ausgeführt sein kann. Dieser Server verbaut die Adapterplatine über die Schnittstellen und beinhaltet selbst ein Software-Gateway, welches die Steuersignale und Daten über entsprechende Treiber and die Platine weitergeben und diese überwachen kann. Zusätzlich sind sowohl die Adapterplatine als auch der Service im Netzwerk verfügbar, um das Setup und Updates zu ermöglichen.

Es wird eine PCIe-Platine mit Vorverarbeitungshardware (IP-Chip) zur Vorverarbeitung großer Videosequenzen und Simulationssoftware in einem Server-Cluster mittels Ethernet und PCIe eingebunden und zum Recomputing von Komponenten des Hochautomatisierten Fahrens verwendet, kann die Verwendung nachgewiesen werden.

Abschließend ist darauf hinzuweisen, dass Begriffe wie „aufweisend“, „umfassend“, etc. keine anderen Elemente oder Schritte ausschließen und Begriffe wie „eine“ oder „ein“ keine Vielzahl ausschließen. Bezugszeichen in den Ansprüchen sind nicht als Einschränkung anzusehen.