DE102019120519A1

DE102019120519A1 - Computer-implementiertes Verfahren und Computerprogrammprodukt zum Test von realen oder virtuellen Steuergeräten

Info

Publication number: DE102019120519A1
Application number: DE102019120519.0A
Authority: DE
Inventors: Nicolas Amringer; Matthias Gehrke; Tobias Schumacher; Gregor Sievers; Daniel Tigges
Original assignee: Dspace GmbH; Dspace Digital Signal Processing and Control Engineering GmbH
Current assignee: Dspace GmbH
Priority date: 2019-07-30
Filing date: 2019-07-30
Publication date: 2021-02-04

Abstract

Computerimplementiertes Verfahren zum Test von virtuellen oder realen Steuergeräten, wobei durch ein Umgebungsmodell einer virtuellen Umgebungsszene fortlaufend mit einer Simulationsfrequenz Umgebungsdatensätze berechnet werden. Dabei ist jedem Umgebungsdatensatz ein Zeitpunkt t in der Gesamtsimulationszeit zugeordnet wird. Es werden zwei Sensorsimulationsmodelle ausgeführt, welche mit verschiedenen Abtastfrequenzen fortlaufend, basierend auf den Umgebungsdatensätzen, Sensordaten zur Weiterverarbeitung durch ein Steuergerät generieren. Dabei startet ein erster Berechnungsschritt am Zeitpunkt t1, in welchem das erste Sensorsimulationsmodell basierend auf den Umgebungsdaten Sensordaten berechnet, und ein zweiter Berechnungsschritt am Zeitpunkt t2, in welchem das zweite Sensorsimulationsmodell basierend auf den Umgebungsdatensätzen Sensordaten berechnet. Erfindungsgemäß ist eine Koordinatorkomponente vorgesehen, an welche wenigstens ein Teil der Umgebungsdatensätze übermittelt werden, und welche in einem ersten Weiterleitungsschritt zum Zeitpunkt t1 den Umgebungsdatensatz an das erste Sensorsimulationsmodell weiterleitet, der dem Zeitpunkt in der Gesamtsimulationszeit t1 zugeordnet ist, und in einem zweiten Weiterleitungsschritt zum Zeitpunkt t2 den Umgebungsdatensatz an das zweite Sensorsimulationsmodell weiterleitet, der dem Zeitpunkt t2 in der Gesamtsimulationszeit zugeordnet ist.

Description

Die Erfindung betrifft ein computer-implementiertes Verfahren zum Test von virtuellen oder realen Steuergeräten oder Steuergeräteverbünden für Sensorsysteme, wie sie im automotiven Bereich oder in Luft- und Raumfahrtanwendungen verwendet werden. Solche Steuergeräte und Steuergeräteverbünde werden für Radar-, Lidar-, Kamera- oder Ultraschallbasierte Sensoren verwendet und mittels Hardware-in-the-Loop- oder Software-in-the-Loop-Test (HIL- oder SIL-Test) getestet. Darüber hinaus betrifft die Erfindung ein Computerprogrammprodukt mit einem Computerprogramm, das Softwaremittel zur Durchführung des Verfahrens umfasst.
Verfahren dieser Art sind bekannt im Bereich der Entwicklung und Absicherung sicherheitskritischer Steuergeräte, wie sie beispielsweise von Automobilzulieferern durchgeführt werden. Dies betrifft auch die Untergruppe der Steuergeräte, die für Fahrerassistenzsysteme eingesetzt werden. Solche Geräte finden Anwendung in Einparkhilfen, Spurhalte- und Notbremsassistenten, Abstandstempomaten u.v.m.
Gerade im Bereich der automobilen Umfelderfassung mittels Sensortechnik sind die Anforderungen an die Steuergeräte heutzutage hoch. Die Anzahl der in den Fahrzeugen verbauten Sensoren steigt mit dem Streben nach autonomen Fahrfunktionen und damit auch die Anzahl der in einem Fahrzeug verbauten Steuergeräte. In diesem Zusammenhang ist die Vernetzung der Steuergeräte ein wichtiger Aspekt, da diese untereinander in einem Wirkzusammenhang stehen. Verfahren zur Absicherung werden daher nicht nur auf einzelne Steuergeräte angewendet, sondern auch auf Steuergeräteverbünde.
Gemeinsam ist diesen Systemen, dass sie auf die präzise Erfassung des Fahrzeugumfelds durch Sensoren angewiesen sind. Die Klasse von Steuergeräten, um die es hier geht, verarbeiten Sensordaten von umfelderfassenden Sensoren. Diese erfassen ihr Umfeld in der Regel mittels elektromagnetischer Wellen, oder im Fall von Ultraschallbasierten Systemen, mittels Schallwellen. Beispiele für umfelderfassende Sensoren sind Kameras. Andere Beispiele sind Radar- und Lidar-Sensoren, die ihr Umfeld mittels aktiver Abtastung und Auswertung der Reflexionssignale erfassen. Für die vorliegende Erfindung ist unerheblich, ob die getesteten Sensoren auf aktiven oder passiven Prinzipien beruhen, oder welcher Natur die dafür verwendeten Umweltsignale sind.
Die Evaluierung dieser Steuergeräte findet häufig mittels HIL- oder SIL-Test in einem offenen (Open-Loop) oder geschlossenen (Closed-Loop) System statt. In beiden Fällen wird die Umgebung des oder der zu testenden Steuergeräte durch eine Simulation abgebildet, eventuell vorhandene Sensoren werden bis zu einem gewissen Punkt der Wirkkette ebenfalls simuliert. Die Simulation findet auf einem Rechnersystem statt, dass je nach Anwendungsfall mit Recheneinheiten und echtzeitfähigen Betriebssystemen ausgestattet ist, oder auch über leistungsfähige GPUs und FPGAs verfügen kann. Bei diesem Rechnersystem spricht man in der Regel und im Folgenden von einem Simulator.
In der offenen Variante wird entweder ein Prototyp des Steuergeräts - also ein real vorhandenes Steuergerät - oder ein simuliertes Steuergerät über eine geeignete Schnittstelle mit den durch die Simulation künstlich erzeugten Sensordaten stimuliert und überprüft, ob die Ausgabe des Steuergeräts bzw. des zu testenden Algorithmus auf dem simulierten Steuergerät den Erwartungen entspricht. In der geschlossenen Variante wird der Wirkungskreis über das Steuergerät geschlossen, d.h. die Ausgabe des zu testenden Steuergeräts wird wieder an den Simulator zurückgespielt und kann dort den Zustand der Simulation beeinflussen. Eventuell verlangt das zu testende Steuergerät Ausgabedaten weiterer, zum Testzeitpunkt nicht verfügbarer Steuergeräte zurück. Diese können dann durch eine Restbussimulation eingebunden werden. Ziel eines solchen Closed-Loop-Systems ist, dem zu testenden Steuergerät den Eindruck zu verschaffen, es wäre in einem echten Fahrzeug verbaut und in der realen Umgebung unterwegs um das Zusammenspiel der verschiedenen Komponenten zu evaluieren.
Zu einem frühen Zeitpunkt im Entwicklungsprozess liegt der Fokus auf der virtuellen Absicherung und damit auf frühzeitigen Tests der Steuergerätesoftware. Diese finden statt, bevor das elektronische Steuergerät an seinem Bestimmungsort getestet wird und bevor überhaupt ein Prototyp der zukünftigen Steuergeräte-Hardware vorliegt. Zum Test zu diesem frühen Zeitpunkt werden Software-in-the-Loop-Simulationen (kurz: SIL-Simulation) durchgeführt, mittels welcher der fertige Produktivcode in einer virtuellen Umgebung getestet werden kann, ohne über Steuergeräte-Hardware zu verfügen. Geht es wie im vorliegenden Fall um Sensorsteuergeräte, ist eine präzise Simulation der Sensordaten erforderlich. Diese umfasst beispielsweise die Berechnung der virtuellen Umgebungsszene in einer Form, die das Sensorsteuergerät erwartet. Bei Kamerasteuergeräten sind das beispielsweise Kamerabilder, bei Lidar-Steuergeräten eine an die jeweils vorliegende Messtechnik angepasste Reflexionspunktewolke. Die Sensordaten werden dabei durch Sensorsimulationsmodelle aus der virtuellen Umgebungsszene berechnet. Dafür wird eine SIL-Simulationsumgebung benötigt, in der die Fahrzeugumgebung (Umgebungsmodell) sowie die Sensordaten simuliert werden und die die generierten Sensordaten dem Steuergerätecode zur Verarbeitung zuführt.
Zu einem weiter fortgeschrittenem Zeitpunkt im Entwicklungsprozess liegt bereits ein Steuergeräteprototyp vor, so dass dieser zusammen mit der Steuergerätesoftware getestet werden soll. Hier werden vorzugsweise Hardware-in-the-Loop-Simulationen (kurz: HIL-Simulation) durchgeführt. Dabei ist es wieder erforderlich, ein Umgebungsmodell der Fahrzeugumgebung einschließlich Sensordatensimulation auf einem Simulator auszuführen, und das Verhalten der Steuergerätesoftware in dieser Fahrzeugumgebung zu prüfen. Im Fall der HIL-Simulation ist vorgesehen, dass die Simulation gewisse Echtzeitbedingungen erfüllt. Dies ist erforderlich, weil das Steuergerät an seinem Bestimmungsort - im Fahrzeug - in Interaktion mit der Umwelt steht und auf diese zeitnah reagieren muss. Der Simulator muss daher die durch die Simulation errechneten Ausgabedaten in Reaktion auf die Eingabedaten des Steuergeräts innerhalb eines festgelegten Zeitintervalls - häufig im einstelligen Millisekunden Bereich - liefern.
Die deutsche Offenlegungsschrift DE102016119538A1 beschreibt einen HIL-Simulator zum Test eines Sensorsteuergeräts - dort eine Kamera - mit dem Ziel, Latenzen in der Verarbeitungskette mittels eines Extrapolationsalgorithmus zu reduzieren. Bekannt ist auch, solche Sensordatensimulationen für SIL-Tests eines Sensorsteuergeräts durchzuführen.
Die EP2402827B1 offenbart ein Verfahren und eine Vorrichtung für eine Funktionsprüfung einer Objekt-Erkennungsvorrichtung eines Kraftwagens. Die Offenlegungsschrift schlägt einen Sensorsimulator vor, durch welchen eine Kamera simuliert wird. Ein Umgebungssimulator übermittelt Umgebungsdaten, aus welchen Sensorsignale berechnet werden, wobei hier auch mit der Kamera in Zusammenhang stehende Effekte wie optische Verzerrung der abbildenden Optik berücksichtigt werden können.
In diesen bekannten Verfahren geht es immer darum, ein einzelnes Sensorsteuergerät zu testen. Jedoch steigt die Nachfrage nach Integrationstest von ganzen Steuergeräteverbünden oder von Steuergeräten, die im Kraftfahrzeug miteinander in einem Wirkzusammenhang stehend. Bei diesen Steuergeräten kann es sich um genau die verschiedenen Sensortypen handeln, die in einem modernen Fahrzeug verbaut sind, bspw. Front- und Heckkamera, Radar und Lidar-Sensoren. Um diesen Verbund zu testen, ist es notwendig, die vom Umgebungsmodell berechneten Umgebungsdaten parallel von einer Vielzahl von Sensorsimulationsmodellen verarbeiten zu lassen. Da jedoch je nach Steuergerät und Komplexität der zugrundeliegenden Sensorsimulationsmodelle unterschiedliche Berechnungszeiten vorliegen und auch unterschiedliche Taktraten bedient werden müssen, treten in der Praxis Schwierigkeiten mit der Konsistenz der ausgegebenen und ins jeweilige Steuergerät eingespeisten Sensordaten auf. Diese begründen sich darin, dass die einzelnen Sensorsimulationsmodelle durch die unterschiedlichen Voraussetzungen hinsichtlich Berechnungstaktung und - komplexität Sensordaten liefern, die nicht zueinander passen, weil sie auf Umgebungsdaten beruhen, die das Umgebungsmodell zu unterschiedlichen Zeitpunkten berechnet hat. Die Konsistenz der gelieferten Sensordaten ist aber von großer Wichtigkeit für ein akzeptables Testergebnis, da es bei den getesteten Funktionen um sicherheitskritische Aspekte geht.
Vor diesem Hintergrund ist es die Aufgabe der Erfindung, den Stand der Technik weiterzubilden.
Die Aufgabe wird durch ein Verfahren zum Test von virtuellen oder realen Steuergeräten oder Steuergeräteverbünden mit den Merkmalen des Patentanspruchs 1 gelöst. Die Aufgabe wird ebenfalls durch ein Computerprogrammprodukt und ein computerlesbares Speichermedium gelöst, das Befehle umfasst, die bei Ausführung durch einen Computer diesen veranlassen, das erfindungsgemäße Verfahren auszuführen.
Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand von abhängigen Unteransprüchen.
Gemäß der Erfindung wird ein Verfahren vorgeschlagen, das vorsieht ein Umgebungsmodell einer virtuellen Umgebungsszene fortlaufend mit einer Simulationsfrequenz auf einer Simulatorrecheneinheit auszuführen und als Ausgabe des Umgebungsmodells Umgebungsdatensätze zu erhalten.
Die Simulatorrecheneinheit kann dabei ein spezialisiertes HIL-Simulatorsystem mit echtzeitfähigem Betriebssystem sein, aber auch ein handelsüblicher Computer.
Das Umgebungsmodell einer virtuellen Umgebungsszene enthält dabei alle geometrischen Informationen der in der Umgebung vorkommenden Umgebungsobjekte in Bezug auf die Position des oder der zu testenden Steuergeräte, wie zum Beispiel Informationen über die Fahrbahn mit Leitplanken und Straßenbäume, Hindernissen und eine Verkehrssituation bildende Fahrzeuge. Das Umgebungsmodell wird periodisch fortlaufend mit einer Simulationsfrequenz ausgeführt und bildet damit eine Sequenz von wechselnden Einzelzuständen des Umgebungsmodells, die sich in den Umgebungsdatensätzen niederschlagen. Dabei reiht sich die Sequenz von Umgebungsdatensätzen entlang der Gesamtsimulationszeit, welche die allen Berechnungen zugrunde liegende Zeit ist, auf. Jedem einzelnen Umgebungsdatensatz ist dementsprechend ein Zeitpunkt in der Gesamtsimulationszeit zugeordnet.
Die durch das Umgebungsmodell erzeugten Umgebungsdatensätze werden in der Folge durch wenigstens ein erstes und ein zweites Sensorsimulationsmodell verarbeitet. Die Sensorsimulationsmodelle können dabei jeweils unterschiedliche Abtastfrequenzen aufweisen. Die Abtastfrequenz ergibt sich durch die Anforderungen des jeweils zu testenden Sensorsteuergeräts. Die Abtastfrequenzen unterscheiden sich in der Regel von der Simulationsfrequenz, mit der das Umgebungsmodell arbeitet. Wichtig ist jedoch, dass die Simulationsfrequenz größer oder gleich der größten Abtastfrequenz der Sensorsimulationsmodelle ist. Die Sensorsimulationsmodelle geben Sensordaten aus, welche für den jeweils zu bedienenden Sensor eine erwartbare Beschaffenheit haben und bilden die der Umgebungsdaten so ab, wie der jeweilige Sensor die virtuelle Umgebungsszene wahrnehmen würde.
Das erste, das zweite und jedes weitere Sensorsimulationsmodell erhält für jeden anstehenden Berechnungsschritt einen Umgebungsdatensatz, aus dem jeweils Sensordaten generiert werden. Das erste Sensorsimulationsmodell startet dabei seinen - den ersten - Berechnungsschritt zu einem ersten Zeitpunkt, das zweite Sensorsimulationsmodell startet seinen - den zweiten - Berechnungsschritt zu einem zweiten Zeitpunkt in der Gesamtsimulationszeit. Diese Sensordaten können dann direkt durch das zu testende Steuergerät verarbeitet werden. Ob vor der Verarbeitung durch das Steuergerät noch eine Zwischenverarbeitung der Daten stattfindet, ist für die Erfindung nicht von Belang.
Das erfindungsgemäße Verfahren sieht weiterhin vor, dass eine Koordinatorkomponente vorliegt, welche alle oder einen Teil der Umgebungsdatensätze, die vom Umgebungsmodell berechnet werden, übermittelt erhält. Die Koordinatorkomponente leitet die Umgebungsdatensätze an die Sensorsimulationsmodelle weiter. Dabei ist unerheblich, ob das Umgebungsmodell, die Koordinatorkomponente und die Sensorsimulationsmodelle auf derselben Recheneinheit oder auf verschiedenen Recheneinheiten ausgeführt werden. Die Übertragung der Umgebungsdatensätze vom Umgebungsmodell zur Koordinatorkomponente und von dort zu den Sensorsimulationsmodellen auf unterschiedlichen Recheneinheiten findet dabei vorzugsweise mittels Netzwerkverbindung und entsprechenden Netzwerkprotokollen statt.
Das erste Sensorsimulationsmodell teilt dabei der Koordinatorkomponente seine Abtastfrequenz, und das zweite Sensorsimulationsmodell teilt ebenso seine Abtastfrequenz mit. Damit ist der Koordinatorkomponente bekannt, zu welchen Zeitpunkten in der Gesamtsimulationszeit die Sensorsimulationsmodelle Umgebungsdatensätze erhalten müssen. Gemäß dem Verfahren leitet die Koordinatorkomponente dem ersten Sensorsimulationsmodell den Umgebungsdatensatz weiter, der dem ersten Zeitpunkt in der Gesamtsimulationszeit zugeordnet ist - also dem Zeitpunkt, an dem das erste Sensorsimulationsmodell seinen Berechnungsschritt startet. Ebenso leitet die Koordinatorkomponente dem zweiten Sensorsimulationsmodell den Umgebungsdatensatz weiter, der dem zweiten Zeitpunkt in der Gesamtsimulationszeit zugeordnet ist - also dem Zeitpunkt, an dem das zweite Sensorsimulationsmodelle den zweiten Berechnungsschritt startet. Auf diese Weise erhalten alle Sensorsimulationsmodelle genau den Umgebungsdatensatz, der für den Berechnungsschritt benötigt wird, auch wenn die Berechnungsschritte nicht zur selben Zeit gestartet werden. Das Ergebnis - die Ausgabe der Sensordaten - ist damit über alle Sensorsimulationsmodelle hinweg konsistent, bezogen auf die Umgebungsdatensätze aus der Umgebungssimulation.
Gemäß einer besonders bevorzugten Ausführungsform der Erfindung ist vorgesehen, dass die Sensorsimulationsmodelle nach Beendigung eines Berechnungsschritts einen empfangsbereiten Zustand einnehmen und der Koordinatorkomponente mitteilen, dass sie diesen Zustand erreicht haben. Dabei ist vorgesehen, dass die Koordinatorkomponente einem der Sensorsimulationsmodelle dann - und nur dann - einen neuen Umgebungsdatensatz weiterleitet, der dem Zeitpunkt in der Gesamtsimulationszeit zugeordnet ist, zu dem der nächste Berechnungsschritt starten soll, wenn das jeweilige Sensorsimulationsmodell den letzten Berechnungsschritt beendet hat. Diese Vorgehensweise ermöglicht, dass die durch die Sensorsimulationsmodelle erzeugten Sensordaten konsistent gehalten werden. Ist der Koordinatorkomponente nicht bekannt, dass ein Sensorsimulationsmodell nicht empfangsbereit ist, würden der Koordinatorkomponente Umgebungsdatensätze des falschen Zeitpunkts übermittelt. Denn wenn das Sensorsimulationsmodell wieder empfangsbereit ist, erhält es einen veralteten bzw. zeitlich unpassenden Umgebungsdatensatz und berechnet daher Sensordaten, die nicht konsistent mit denen der anderen Sensorsimulationsmodelle sind.
Zudem hat diese Vorgehensweise den Vorteil, dass nicht unnötig Umgebungsdatensätze weitergeleitet werden, obwohl diese gar nicht verarbeitet werden können.
Eine Übertragung von Umgebungsdatensätzen kann eine hohe Datenverarbeitungslast mit sich bringen, insbesondere wenn die Koordinatorkomponente auf einem anderen Rechnersystem ausgeführt wird, als die Sensorsimulationsmodelle. Weiterhin ist der Koordinatorkomponente durch den Empfang der Mitteilung über die Empfangsbereitschaft dann bekannt, wie lange ein Sensorsimulationsmodell für einen Berechnungsschritt braucht, oder dass es mit dem der Abtastfrequenz entsprechenden Abtastschritt nicht auskommt. Allen Ausführungsformen gemeinsam ist, dass ein Abtastschritt sich aus der Abtastfrequenz ergibt und die Zeitspanne - der Kehrwert der Abtastfrequenz - ist, in der ein Berechnungsschritt eines Sensorsimulationsmodells in der Regel beendet sein sollte. Ist die Berechnung in dieser Zeitspanne nicht abgeschlossen, kann das mehrere Gründe haben. Wie oben angedeutet, ist ein möglicher Grund, dass das entsprechende Sensorsimulationsmodell zu langsam ist. Ein weiterer Grund kann sein, dass das Sensorsimulationsmodell zwar schnell genug gerechnet hat, aber die Übertragung der Nachricht über die Empfangsbereitschaft zu lange dauert. Dies kann beispielsweise auftreten, wenn die Koordinatorkomponente und das Sensorsimulationsmodell jeweils auf separaten Rechnersystemen laufen. Ein weiterer Grund kann auch sein, dass die Berechnung des Sensorsimulationsmodells zwar schnell genug ist, aber die Lastanforderungen an die Übertragung der Umgebungsdatensätze zu hoch sind. Dann erhält das Sensorsimulationsmodell den benötigen Umgebungsdatensatz sehr spät und kann den Berechnungsschritt nicht innerhalb des Abtastschritts bewältigen.
In einer vorteilhaften Ausgestaltung der Erfindung kann die oben erläuterte Weiterleitung durch eine Weiterleitungseinheit erfolgen. Diese Weiterleitungseinheit umfasst dabei Kommunikationskanäle, also Nachrichtenverbindungen, über die die Koordinatorkomponente Umgebungsdatensätze an die Sensorsimulationsmodelle senden kann und auch Nachrichten von den Sensorsimulationsmodellen empfangen kann. So können die Sensorsimulationsmodelle über einen Kommunikationskanal mit ihrer Abtastfrequenz in ihrem Namen an die Koordinatorkomponente anmelden, und außerdem mitteilen, dass sie nach Abschluss eines Berechnungsschritts wieder empfangsbereit sind. Pro beteiligter Abtastfrequenz - es können ja mehrere Sensorsimulationsmodelle die gleiche Abtastfrequenz aufweisen - kann ein eigener Kommunikationskanal für die Übertragung von Umgebungsdatensätzen erzeugt werden. Die Sensorsimulationsmodelle können sich beim Koordinator über den Kommunikationskanal wieder abmelden. Das An- und Abmelden kann während der Laufzeit der Koordinatorkomponente erfolgen. Sofern mehrere Abtastfrequenzen ein ganzzahliges Vielfaches von einander bilden, kann der Koordinator diese Kommunikationskanäle zu einem bündeln, um Datentransferlast zu sparen.
In einer vorteilhaften Ausgestaltung der Erfindung sieht das Verfahren vor, dass der Zeitpunkt in der Gesamtsimulationszeit, der den Umgebungsdatensätzen zugeordnet ist, durch die Koordinatorkomponente bestimmt wird, indem die Koordinatorkomponente die zwischen zwei an die Koordinatorkomponente übermittelten aufeinander folgenden Umgebungsdatensätzen verstrichene Zeit misst. Obwohl jeder Umgebungsdatensatz auch einen Zeitstempel trägt, der den Zeitpunkt in der Gesamtsimulationszeit angibt, kann durch diese Vorgehensweise darauf verzichtet werden, die Zeitinformation aus den Umgebungsdatensätzen auszulesen. Das bringt den Vorteil mit sich, dass eventuell vorhandene Übertragungslatenzen zwischen Umgebungsmodell und Koordinatorkomponente keine Auswirkung mehr auf die Sensorsimulation mehr haben können. Außerdem kann das Dekodieren der Zeitstempel entfallen und bringt damit eine Zeitersparnis.
Wie oben erläutert, weisen die Umgebungsdatensätze Zeitstempel auf, welche die den Umgebungsdatensätzen zugeordneten Zeitpunkte in der Gesamtsimulationszeit identifizieren. Gemäß einer weiteren, alternativen Ausführungsform der Erfindung ist vorgesehen, dass die Koordinatorkomponente eine Dekodierungskomponente umfasst, wobei diese Dekodierungskomponente den Zeitstempel aus den Umgebungsdatensätzen ausliest und damit der Koordinatorkomponente die Information über den Zeitpunkt in der Gesamtsimulationszeit der einzelnen Umgebungsdatensätze zur Verfügung stellt. Weiterhin ist in einer bevorzugten Ausführung vorgesehen, dass die Koordinatorkomponente oder die Dekodierungseinheit aus dem zeitlichen Abstand zweier ausgelesener Zeitstempel die Zeitpunkte in der Gesamtsimulationszeit zukünftig eintreffender Umgebungsdaten voraussagen.
In einer weiteren bevorzugten Ausführungsform kann vorgesehen sein, dass die Koordinatorkomponente sowohl den zeitlichen Abstand zweier ausgelesener Zeitstempel bestimmt, als auch den zeitlichen Abstand der an die Koordinatorkomponente übermittelten Umgebungsdatensätze bestimmt, und daraus der Abweichung der beiden Abstände ermittelt. Hierdurch kann die Latenz für die Übermittlung der Umgebungsdatensätze durch das Umgebungsmodell an die Koordinatorkomponente bestimmt werden. Unter der Annahme, dass diese Latenz jitter-frei ist, hat diese Vorgehensweise den Vorteil, dass die Latenz lediglich einmalig berechnet werden muss und auf eine fortlaufende Zeitmessung durch die Koordinatorkomponente verzichtet werden kann.
In einer weiteren bevorzugten Ausführungsform der Erfindung sieht das Verfahren vor, dass die Koordinatorkomponente als Softwareeinheit ausgeführt ist, die auf der ersten oder zweiten Recheneinheit, oder auf einer weiteren Recheneinheit ausgeführt wird, oder wobei die Koordinatorkomponente als Hardwareeinheit auf einem programmierbaren Logikbaustein ausgeführt wird.
In einer vorteilhaften Ausgestaltung der Erfindung sieht das Verfahren vor, dass auf einer der Recheneinheiten ein drittes Sensorsimulationsmodell ausgeführt wird, wobei das dritte Sensorsimulationsmodell eine dritte Abtastfrequenz aufweist. Dabei ist die dritte Abtastfrequenz ein ganzzahliges Vielfaches der zweiten Abtastfrequenz. In diesem Fall ist vorgesehen, dass die Koordinatorkomponente den Umgebungsdatensatz an das zweite und dritte Sensorsimulationsmodell gleichzeitig versendet. Dabei kann die Koordinatorkomponente gegebenenfalls einen einzigen Kommunikationskanal, der durch Bündelung entstanden ist, nutzen. Dieses Vorgehen hat den Vorteil, dass derselbe Umgebungsdatensatz nur einmal versendet werden muss, und damit Datentransferlast eingespart wird.
Für den Fall, dass ein Sensorsimulationsmodell nach Ende eines Abtastschritts keine Empfangsbereitschaft an die Koordinatorkomponente mitteilt, ist in einer weiteren, vorteilhaften Ausführung der Erfindung vorgesehen, dass die Koordinatorkomponente keinen neuen Umgebungsdatensatz an das Sensorsimulationsmodell übermittelt. Stattdessen ist vorgesehen, dass die Ausführung des Umgebungsmodells angehalten wird, bis das entsprechende Sensorsimulationsmodell wieder Empfangsbereitschaft signalisiert. Für den Fall, dass eine SIL-Test durchgeführt wird, kann diese Vorgehensweise vorteilhaft sein, da dort keine Echtzeitbedingungen eingehalten werden müssen. Wenn der Auslöser für das Ausbleiben der Mitteilung der Empfangsbereitschaft ein erhöhter Bedarf an Berechnungszeit eines Sensorsimulationsmodells ist, kann in diesem Fall die Ausführung des Umgebungsmodells gestoppt werden, womit implizit auch die Ausführung der anderen Sensorsimulationsmodelle und das Verstreichen der Gesamtsimulationszeit gestoppt wird. Sobald das verzögernde Sensorsimulationsmodell wieder Empfangsbereitschaft mitgeteilt hat, kann die Ausführung des Umgebungsmodells wieder aufgenommen werden.
In einer weiteren, vorteilhaften Ausgestaltung sieht das Verfahren vor, dass Koordinatorkomponente in einem Überprüfungsschritt vor dem Weiterleitungsschritt überprüft, ob ein Umgebungsdatensatz aus einem vorhergehendem Abtastschritt zurückgeblieben ist. Falls das nicht der Fall ist, wird der ältere Umgebungsdatensatz verworfen und stattdessen der neuere Umgebungsdatensatz übermittelt.
In einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die Koordinatorkomponente eine Fehlereinheit aufweist, welche einen Fehlerspeicher aufweist. Dabei ist vorgesehen, dass die Fehlereinheit einen Eintrag in dem Fehlerspeicher protokolliert, wenn ein Sensorsimulationsmodell zu Beginn des nächsten Berechnungsschritts keine Empfangsbereitschaft mitgeteilt hat. Dabei umfasst der Eintrag in den Fehlerspeicher wenigstens den Namen des Sensorsimulationsmodells und den Zeitpunkt des Beginns des Berechnungsschritts, zu welchem keine Empfangsbereitschaft mitgeteilt wurde. Tritt die Empfangsbereitschaft dann doch ein, wird ebenfalls der Zeitpunkt protokolliert, zu dem die Empfangsbereitschaft mitgeteilt wurde. Weiter oben wurden bereits mögliche Gründe für ausbleibende oder verspätete Empfangsbereitschaft beschrieben. Der Vorteil des Protokollierens vom Zeitpunkt der Weiterleitung eines Umgebungsdatensatzes und des Zeitpunkts der darauffolgenden Mitteilung über die Empfangsbereitschaft ist, dass unterschieden werden kann, ob die verspätete Empfangsbereitschaft durch ein langsames Sensorsimulationsmodell ausgelöst wird oder durch die erhöhte Übertragungslast der Weiterleitung der Umgebungsdatensätze.
In einer alternativen Ausführungsform ist vorgesehen, dass die oben erläuterte Fehlereinheit einen Eintrag in den Fehlerspeicher protokolliert, wenn wie weiter oben erläutert festgestellt wird, dass ein älterer Umgebungsdatensatz noch nicht an das Sensorsimulationsmodell übermittelt wurde. In einer alternativen Ausgestaltung kann vorgesehen sein, dass die Koordinatorkomponente einen Pufferspeicher aufweist, welcher Teil eines gemeinsamen Speichers ist, auf den das Umgebungsmodell und die Koordinatorkomponente Zugriff haben. In diesem Fall speichert das Umgebungsmodell die erzeugten Umgebungsdatensätze in den Pufferspeicher, und die Koordinatorkomponente leitet die Umgebungsdatensätze daraus an die Sensorsimulationsmodelle weiter. Nach der Weiterleitung kann der Umgebungsdatensatz aus dem Pufferspeicher entfernt werden. Der Vorteil dieses Vorgehens ist, dass die Koordinatorkomponente daran erkennen kann, ob ein Umgebungsdatensatz erfolgreich übermittelt wurde.
In diesen beiden Fällen kann in einer alternativen Ausgestaltung vorgesehen sein, dass eine vorher festgelegte Anzahl gestatteter Fehler im Fehlerspeicher zugelassen ist. Bei Überschreiten dieser Anzahl kann beispielsweise mit dem Anhalten der Koordinatorkomponente reagiert werden. Diese Vorgehensweise ist vorteilhaft im Fall einer HIL-Simulation oder einer Simulation in der Echtzeitbedingungen erfüllt werden müssen. Nach dem Stopp der Koordinatorkomponente kann anhand des Fehlerspeichers ermittelt werden, worin der Fehler besteht. Die Ausführung der Koordinatorkomponente kann dann nach Abhilfe des Fehlers weitergeführt werden. In einer alternativen Ausführung kann nach Überschreiten der vorbestimmten Anzahl von Fehlern im Fehlerspeicher festgelegt werden, dass das Umgebungsmodell gestoppt wird - solange bis die Empfangsbereitschaft wiederhergestellt ist. Um das Umgebungsmodell zu stoppen, nutzt die Koordinatorkomponente in diesem Fall einen Rückkanal zum Umgebungsmodell, welche sich von dem Kommunikationskanal zum Übermitteln der Umgebungsdatensätze unterscheidet. Diese Vorgehensweise ist vorteilhaft im Fall einer SIL-Simulation oder falls keine Echtzeitbedingung erfüllt werden muss. Das Anhalten der Umgebungsmodells entspricht dann dem Anhalten der Gesamtsimulationszeit solange, bis die Berechnungsschritte der Sensorsimulationsmodelle abgeschlossen ist.
In einer weiteren vorteilhaften Ausführungsform sieht das Verfahren vor, dass das erste Sensorsimulationsmodell eine Verzögerungszeitspanne an die Koordinatorkomponente übermittelt. Der Berechnungsschritt des ersten Sensorsimulationsmodells startet in diesem Fall zu einem um die Verzögerungszeitspanne verschobenen Zeitpunkt, während die Koordinatorkomponente den Umgebungsdatensatz an das Sensorsimulationsmodell übermittelt, welcher nicht um die Verzögerungszeitspanne verschoben ist. Daher rechnet in diesem Fall das erste Sensorsimulationsmodell mit verzögerten - veralteten - Umgebungsdatensätzen. Diese Vorgehensweise ist vorteilhaft, wenn bekannt ist, dass das erste Sensorsimulationsmodell wenig Zeit für seinen Berechnungsschritt benötigt, und gewünscht ist, dass der Berechnungsschritt zeitgleich mit einem zweitem, parallel ausgeführten Sensorsimulationsmodell beendet wird.
In einer weiteren, vorteilhaften Ausführungsform sieht das Verfahren vor, dass das erste Sensorsimulationsmodell eine Versatzzeitspanne an die Koordinatorkomponente übermittelt. Der Berechnungsschritt des ersten Sensorsimulationsmodells startet in diesem alternativen Fall zu einem um die Versatzzeitspanne verschobenen Zeitpunkt, während die Koordinatorkomponente den Umgebungsdatensatz an das Sensorsimulationsmodell übermittelt, welcher ebenfalls um die Versatzzeitspanne verschoben ist. Wird die Versatzzeitspanne vom Sensorsimulationsmodell mitgeteilt, startet der Berechnungsschritt um die Spanne verzögert, während im Unterschied zum oben beschrieben Fall mit zu diesem verzögerten Zeitpunkt aktuellen Umgebungsdatensätzen gerechnet wird. Diese Ausführungsform ist dann vorteilhaft, wenn die zu testenden Sensorsteuergeräte nicht untereinander synchronisiert sind. So können mehrere Steuergeräte durchaus die gleiche Abtastfrequenz aufweisen, aber die Abtastschritte nicht zeitlich takten. Um eine solches unsynchronisiertes System mit Sensordaten bedaten zu können, ist es erforderlich den individuellen Versatz in der Taktung bereits bei der Generierung der Sensordaten zu berücksichtigen.
In einer alternativen, bevorzugten Ausgestaltung sieht das Verfahren vor, dass die Umgebungsdatensätze von einem Speichermedium an die Koordinatorkomponente übermittelt werden. Der Vorteil dieser Vorgehensweise ist, dass dann auf die Ausführung des Umgebungsmodells verzichtet werden kann, wenn bereits Umgebungsdatensätze auf dem Speichermedium vorhanden sind. Diese Vorgehensweise ist dann vorteilhaft, wenn das Umgebungsmodell gar nicht vorliegt, da der Besitzer des Umgebungsmodells bspw. sein geistiges Eigentum nicht herausgeben möchte.
In einer weiteren, vorteilhaften Ausführungsform sieht das Verfahren vor, dass die Koordinatorkomponente eine Aufzeichnungseinheit umfasst, und die Aufzeichnungseinheit (12) die Umgebungsdatensätze (x,t), die der Koordinatorkomponente (7) durch das Umgebungsmodell (3) übermittelt werden, aufzeichnet und auf einem Speichermedium (13) speichert. Die Aufzeichnungseinheit zeichnet die Umgebungsdatensätze auf, die das Umgebungsmodell an die Koordinatorkomponente übermittelt und speichert sie auf einem Speichermedium. Der Vorteil dieser Vorgehensweise ist, dass die gespeicherten Umgebungsdatensätze dann, wie weiter oben erläutert, für eine weitere Ausführung der Sensorsimulationsmodelle verwendet werden können, ohne dass es der Ausführung des Umgebungsmodells bedarf.
Es gibt nun eine Vielzahl Möglichkeiten, das beschriebene computerimplementierte Verfahren weiterzubilden. Dazu wird sowohl auf die abhängigen Patentansprüche verwiesen, als auch auf die nachfolgende Beschreibung von bevorzugten Ausführungsbeispielen in Verbindung mit den Figuren. Hierbei werden gleichartige Teile mit identischen Bezeichnungen beschriftet. Die dargestellten Ausführungsformen sind stark schematisiert.
Figurenliste

1 schematisch ein computerimplementiertes Verfahren zum Test von virtuellen oder realen Steuergeräten, bei dem Sensordaten als Eingangsdaten zur Weiterverarbeitung durch wenigstens ein Sensorsteuergerät ausgegeben werden
2 schematisch eine weitere Ausführungsform des computerimplementiertes Verfahrens zum Test von virtuellen oder realen Steuergeräten
3 schematisch eine weitere Ausführungsform des computerimplementiertes Verfahrens zum Test von virtuellen oder realen Steuergeräten
4 schematisch ein Zeitverlaufsdiagramm der Berechnungsschritte von drei Sensorsimulationsmodellen als mögliches Ergebnis des computerimplementierten Verfahrens
5 schematisch ein Zeitverlaufsdiagramm der Berechnungsschritte von drei Sensorsimulationsmodellen in einer detaillierteren Darstellung als mögliches Ergebnis des computerimplementierten Verfahrens
6 schematisch ein Zeitverlaufsdiagramm zur Verdeutlichung des Konzepts der Verzögerungszeitspanne
7 schematisch ein Zeitverlaufsdiagramm zur Verdeutlichung des Konzepts der Versatzzeitspanne

1 zeigt schematisch ein computerimplementiertes Verfahren 1 zum Test von virtuellen oder realen Steuergeräten 2. Dabei wird auf einer Simulatorrecheneinheit 4 ein Umgebungsmodell einer virtuellen Umgebungsszene 3 berechnet und fortlaufend mit der Simulationsfrequenz (nicht dargestellt) Umgebungsdatensätze x,t an eine Koordinatorkomponente 7 übermittelt. Die Koordinatorkomponente 7 leitet die Umgebungsdatensätze an die Sensorsimulationsmodelle 5a, 5b, 5c weiter. In diesem Beispiel werden die Sensorsimulationsmodelle 5a und 5b auf einer Recheneinheit 6a ausgeführt, und das Sensorsimulationsmodell 5c auf einer weiteren Recheneinheit 6b. Auf Basis der Umgebungsdatensätze x,t berechnen die Sensorsimulationsmodelle die Sensordaten w,t, welche direkt in ein oder mehrere Steuergeräte 2 eingespeist werden. Denkbar ist auch, dass nach Ausgabe der Sensordaten w,t und vor Einspeisung in ein Steuergerät noch eine Zwischenverarbeitung stattfindet (nicht dargestellt).
2 zeigt eine weitere Ausführungsform eines computerimplementierten Verfahrens 1 zum Test von virtuellen oder realen Steuergeräten 2. Zusätzlich zu den zu 1 erläuterten Zusammenhängen weist die Koordinatorkomponente in 2 noch eine Dekodierungskomponente 8 auf. Die Dekodierungskomponente 8 liest die Zeitstempel (nicht dargestellt) aus, die den Umgebungsdatensätzen x,t zugehören. Jedem Umgebungsdatensatz x,t ist ein Zeitpunkt in der Gesamtsimulationszeit zugeordnet, welche in Form eines Zeitstempels dem jeweiligen Umgebungsdatensatz x,t anhängen. Darüber hinaus zeigt 2 als Teil der Koordinatorkomponente 7 noch eine Fehlereinheit 9, die einen Fehlerspeicher 10 aufweist. Die Fehlereinheit 9 kann immer dann einen Fehler registrieren, wenn die Koordinatorkomponente 7 einen Umgebungsdatensatz x,t nicht weiterleiten konnte oder wenn ein Berechnungsschritt am Ende eines Abtastschritts nicht abgeschlossen wurde.
Die Dekodierungskomponente 8 und die Fehlereinheit 9 sind optionale Komponenten.
In 3 ist eine weitere Ausführungsform eines computerimplementierten Verfahrens 1 zum Test von virtuellen oder realen Steuergeräten 2 dargestellt. Zusätzlich zu den zu 1 und 2 beschriebenen Komponenten weist die Koordinatorkomponente 7 noch eine Weiterleitungseinheit 14 mit Kommunikationskanälen 15a, 15b, 15c sowie eine Aufzeichnungseinheit 12 mit Speichermedium 13 auf. Die Weiterleitungseinheit 14 leitet die Umgebungsdatensätze unter Verwendung der Kommunikationskanälen 15a, 15b, 15c an die Sensorsimulationsmodelle weiter. Ebenfalls über Kommunikationskanäle melden sich die Sensorsimulationsmodelle 5a, 5b, 5c bei der Koordinatorkomponente mit ihrer Abtastfrequenz an. Die Weiterleitungseinheit leitet Umgebungsdatensätze x,t an die Sensorsimulationsmodelle 5a und 5c über denselben Kommunikationskanal 15a weiter, da die Sensorsimulationsmodelle 5a und 5c in diesem Beispiel die gleiche Abtastfrequenz aufweisen. Das Sensorsimulationsmodell 5b erhält Umgebungsdatensätze x,t über einen separaten Kommunikationskanal 15b. Die Sensorsimulationsmodelle 15a, 15b, 15c melden der Koordinatorkomponente 7 ihre Empfangsbereitschaft über einen weiteren Kommunikationskanal 15c. Aus Gründen der Übersichtlichkeit ist keine Verbindung zwischen den Sensorsimulationsmodellen 5a, 5b, 5c und dem Ansatz des Kommunikationskanals 15c der Koordinatorkomponente 7 eingezeichnet, obwohl sie existiert. Weiterhin weist die Koordinatorkomponente 7 in diesem Beispiel eine Aufzeichnungseinheit 12 mit einem Speichermedium 13 auf. Die Aufzeichnungseinheit 12 speichert die an die Koordinatorkomponente 7 übermittelten Umgebungsdatensätze x,t auf dem Speichermedium 13. In einem späteren Simulationsdurchlauf können die gespeicherten Daten dann verwendet werden, ohne dass das Umgebungsmodell 3 ausgeführt werden muss.
Zusätzlich ist hier noch ein Analysewerkzeug 16 eingezeichnet. Die Weiterleitungseinheit 14 kann die eingehenden Umgebungsdatensätze x,t dann an das Analysewerkzeug 16 weiterleiten, wodurch Analysen der Umgebungsdatensätze x,t ermöglicht werden.
4 zeigt schematisch ein Zeitverlaufsdiagramm der Berechnungsschritte von drei Sensorsimulationsmodellen 5a, 5b, 5c als mögliches Ergebnis des computerimplementierten Verfahrens 1. In diesem Diagramm sind die Berechnungsschritte jeweils als schraffierte Flächen eingezeichnet. In diesem Beispiel werden zum Zeitpunkt 0 ms Umgebungsdatensätze x,t an alle Sensorsimulationsmodelle 5a, 5b, 5c übermittelt, und zwar die Umgebungsdatensätze, die dem Zeitpunkt 0 ms zugeordnet sind. Alle Sensorsimulationsmodelle starten daraufhin ihre Berechnungsschritte, wobei zunächst Sensorsimulationsmodell 5a fertig wird, und dann Sensorsimulationsmodell 5b. Das dritte Sensorsimulationsmodell 5c benötigt längere Zeit, hat aber die halbe Abtastfrequenz im Vergleich zu den Sensorsimulationsmodellen 5a und 5b. Daher erhalten Sensorsimulationsmodelle 5a und 5b bereits zum Zeitpunkt 33 ms weitere Umgebungsdatensätze, während Sensorsimulationsmodell 5c noch rechnet. Zum Zeitpunkt 66 ms werden wieder Umgebungsdatensätze an alle drei Sensorsimulationsmodell 5a, 5b und 5c übermittelt, nachdem die Koordinatorkomponente 7 von diesen Sensorsimulationsmodellen die Empfangsbereitschaft mitgeteilt bekommen hat.
In 5 ist ein ähnlicher Sachverhalt dargestellt. Dabei zeigen schraffierte Fläche wieder Berechnungsschritte der Sensorsimulationsmodelle 5a (obere Reihe), 5b (mittlere Reihe) und 5c (untere Reihe), während die unschraffierten Blöcke die Einsätze der Koordinatorkomponente 7 darstellen. Es beginnt kurz vor dem Zeitpunkt 66 ms, zu welchem die Koordinatorkomponente 7 den Sensorsimulationsmodellen 5a un=d 5 b - mit Abtastfrequenz 30 Hz - und dem Sensorsimulationsmodell 5c - mit Abtastfrequenz 15 Hz - Umgebungsdatensätze weiterleitet. Nach Beendigung der Berechnungsschritte teilen die Sensorsimulationsmodelle 5a und 5b ihre Empfangsbereitschaft mit, bevor der Zeitpunkt 99 ms erreicht ist. Zu diesem Zeitpunkt leitet die Koordinatorkomponente 7 bereits die neuen Umgebungsdatensätze weiter, die dem Zeitpunkt 99 ms in der Gesamtsimulationszeit zugeordnet sind. Währenddessen rechnet das halb so schnell getaktete Sensorsimulationsmodell 5c noch weiter und meldet erst später Empfangsbereitschaft an die Koordinatorkomponente 7.
In 6 und 7 sind Zeitverlaufsdiagramme dargestellt, die das Konzept der Verzögerungszeitspanne j und der Versatzzeitspanne k verdeutlichen sollen. So zeigt 6 ein Beispiel mit zwei Sensorsimulationsmodellen 5a und 5b mit einem gemeinsamen Abtastschritt 11a-11b. Auch hier bedeuten schraffierte Flächen wieder Berechnungsschritte b1, b2. Sensorsimulationsmodell 5b erhält zum Zeitpunkt t1 zu Beginn des Abtastschritts 11a Umgebungsdaten, die dem Zeitpunkt t1 zugeordnet sind. Sensorsimulationsmodell 5a erhält jedoch die Umgebungsdaten, die dem Zeitpunkt t1 zugeordnet sind, erst zum Zeitpunkt t1+j, der um die Verzögerungszeitspanne j verschoben ist. Die Umgebungsdaten sind zu diesem Zeitpunkt zwar schon veraltet, aber das Ziel der Verzögerung ist in diesem Beispiel, dass bei Sensorsimulationsmodelle 5a und 5b ihre Berechnungsschritte b1 und b2 zum gleichen Zeitpunkt beenden.
In 7 sind hingegen wieder zwei Sensorsimulationsmodelle 5a und 5b beteiligt, die aber jeweils versetzte Abtastschritte 11a-11b bzw.11a'-11b' aufweisen. Daher erhält das Sensorsimulationsmodell 5a zum Beginn des Abtastschritts 11a den Umgebungsdatensatz, der dem Zeitpunkt t1 zugeordnet ist, während Sensorsimulationsmodell 5b den Umgebungsdatensatz erhält, der dem um die Versatzzeitspanne k versetzten Zeitpunkt t1+k zugeordnet sind.
Bezugszeichenliste

1: Computer-implementiertes Verfahren
2: Steuergerät/Steuergeräteverbund
x,t: Umgebungsdatensätze
3: Umgebungsmodell einer virtuellen Umgebungsszene
4: Simulatorrecheneinheit
5a, 5b, 5c: Sensorsimulationsmodell
6a, 6b, 6c: Recheneinheit
w,t: Sensordaten
b, b1, b2: Berechnungsschritt
7: Koordinatorkomponente
8: Dekodierungskomponente
9: Fehlereinheit
10: Fehlerspeicher
j: Verzögerungszeitspanne
k: Versatzzeitspanne
11a, 11a': Beginn Abtastschritt
11b, 11b': Ende Abtastschritt
12: Aufzeichnungseinheit
13: Speichermedium
14: Weiterleitungseinheit
15a, 15b, 15c: Kommunikationsschnittstelle
16: Analysewerkzeug

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 102016119538 A1 [0009]
EP 2402827 B1 [0010]

Claims

Computerimplementiertes Verfahren (1) zum Test von virtuellen oder realen Steuergeräten oder Steuergeräteverbünden (2), wobei durch ein Umgebungsmodell einer virtuellen Umgebungsszene (3) mittels einer Simulatorrecheneinheit (4) fortlaufend mit einer Simulationsfrequenz Umgebungsdatensätze (x,t) berechnet werden, und wobei jedem Umgebungsdatensatz (x,t) ein Zeitpunkt (t) in einer Gesamtsimulationszeit zugeordnet wird, wobei wenigstens ein erstes und ein zweites Sensorsimulationsmodell (5a, 5b) auf wenigstens einer Recheneinheit (6) ausgeführt werden und das erste Sensorsimulationsmodell (5a) mit einer ersten Abtastfrequenz und das zweite Sensorsimulationsmodell (5b) mit einer zweiten Abtastfrequenz fortlaufend, basierend auf den Umgebungsdatensätzen (x,t), Sensordaten (w) zur Weiterverarbeitung durch ein Steuergerät (2) generieren, wobei ein erster Berechnungsschritt (b1) am Zeitpunkt t1 der Gesamtsimulationszeit startet und dabei durch das erste Sensorsimulationsmodell (5a) basierend auf den Umgebungsdaten (x,t) Sensordaten (w,t) berechnet werden und ein zweiter Berechnungsschritt (b2) am Zeitpunkt t2 der Gesamtsimulationszeit startet und dabei durch das zweite Sensorsimulationsmodell (5b) basierend auf den Umgebungsdatensätzen (x,t) Sensordaten (w,t) berechnet werden, wobei das erste und das zweite Sensorsimulationsmodell (5a, 5b) die Sensordaten (w,t) zur Verarbeitung durch ein oder mehrere Steuergeräte oder einen Steuergeräteverbund (2) generieren, dadurch gekennzeichnet, dass das Verfahren eine Koordinatorkomponente (7) vorsieht, wobei wenigstens ein Teil der Umgebungsdatensätze (x,t) in einem Übermittlungsschritt an die Koordinatorkomponente (7) übermittelt werden, und wobei die Koordinatorkomponente (7) in einem ersten Weiterleitungsschritt zum Zeitpunkt t1 den Umgebungsdatensatz (x,t) an das erste Sensorsimulationsmodell (5a) weiterleitet, der dem Zeitpunkt t1 in der Gesamtsimulationszeit zugeordnet ist, und in einem zweiten Weiterleitungsschritt zum Zeitpunkt t2 den Umgebungsdatensatz (x,t) an das zweite Sensorsimulationsmodell (5a) weiterleitet, der dem Zeitpunkt t2 in der Gesamtsimulationszeit zugeordnet ist.
Verfahren nach Anspruch 1, wobei die Sensorsimulationsmodelle (5a, 5b, 5c) nach Beendigung eines Berechnungsschritts (b) einen empfangsbereiten Zustand einnehmen und der Koordinatorkomponente (7) die Empfangsbereitschaft mitteilen, und wobei die Koordinatorkomponente (7), falls das erste oder das zweite Sensorsimulationsmodell (5a, 5b) Empfangsbereitschaft mitgeteilt haben, die Umgebungsdatensätze (x,t) an das erste oder zweite Sensorsimulationsmodell (5a, 5b) übermittelt.
Verfahren nach Anspruch 1 oder 2, wobei der Zeitpunkt in der Gesamtsimulationszeit, der den Umgebungsdatensätzen (x,t) zugeordnet ist, durch die Koordinatorkomponente (7) bestimmt wird, indem die die Koordinatorkomponente (7) die zwischen zwei an die Koordinatorkomponente (7) übermittelten aufeinander folgenden Umgebungsdatensätzen (x,t) verstrichene Zeit misst.
Verfahren nach einem der Ansprüche 1 bis 3, wobei die Umgebungsdatensätze (x,t) weiterhin Zeitstempel aufweisen, welche die den Umgebungsdatensätzen (x,t) zugeordneten Zeitpunkte in der Gesamtsimulationszeit identifizieren, und wobei die Koordinatorkomponente (7) eine Dekodierungskomponente (8) umfasst, und wobei der Zeitpunkt in der in der Gesamtsimulationszeit, der den Umgebungsdatensätzen (x,t) zugeordnet ist, durch die Dekodierungskomponente (8) durch Auslesen des Zeitstempels festgestellt wird.
Verfahren nach Anspruch 4, wobei die Dekodierungseinheit (8) die Zeitstempel eines ersten und eines zweiten Umgebungsdatensatzes (x,t) ausliest und aus dem Abstand der ermittelten Zeitpunkte in der Gesamtsimulationszeit die Zeitpunkte der zukünftige eintreffenden Umgebungsdatensätze (x,t) voraussagt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Koordinatorkomponente (7) als Softwareeinheit ausgebildet ist, die auf der ersten oder zweiten Recheneinheit (6a, 6b), oder auf einer weiteren Recheneinheit (6c) ausgeführt wird, oder wobei die Koordinatorkomponente (7) als Hardwareeinheit auf einem programmierbaren Logikbaustein ausgeführt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei auf der wenigstens einen Recheneinheit (6a, 6b) ein drittes Sensorsimulationsmodell (5c) ausgeführt wird, und das dritte Sensorsimulationsmodell (5c) mit einer dritten Abtastfrequenz fortlaufend, basierend auf den Umgebungsdaten (x,t), Sensordaten (w,t) zur Weiterverarbeitung durch ein Steuergerät (2) generiert, und wobei die dritte Abtastfrequenz ein ganzzahliges Vielfaches der zweiten Abtastfrequenz des zweiten Sensorsimulationsmodells (5b) ist, und wobei durch die Koordinatorkomponente (7) in dem zweiten Weiterleitungsschritt zum Zeitpunkt t2 den Umgebungsdatensatz (x,t) an das zweite und das dritte Sensorsimulationsmodell (5b, 5c) gleichzeitig weiterleitet, der dem Zeitpunkt t2 in der der Gesamtsimulationszeit zugeordnet ist.
Verfahren nach Anspruch 2, wobei die Koordinatorkomponente (7), falls das erste oder das zweite Sensorsimulationsmodell (5a, 5b) nach Beendigung eines Berechnungsschritts (b) keine Empfangsbereitschaft mitgeteilt hat, keinen Umgebungsdatensatz (x,t) an das erste oder zweite Sensorsimulationsmodell (5a, 5b) übermittelt, und die Ausführung des Umgebungsmodells (3) durch die Koordinatorkomponente (7) mittels eines Rückkanals von der Koordinatorkomponente (7) zum Umgebungsmodell (3) angehalten wird, solange durch das Sensorsimulationsmodell (5a, 5b) keine Empfangsbereitschaft mitteilt wird.
Verfahren nach Anspruch 8, wobei die Koordinatorkomponente (7) eine Fehlereinheit (9) aufweist, und wobei die Fehlereinheit (9) einen Fehler registriert und einen Eintrag in einem Fehlerspeicher (10) protokolliert, wenn ein Sensorsimulationsmodell (5a, 5b, 5c) zu Beginn des nächsten Berechnungsschritts (b) keine Empfangsbereitschaft mitgeteilt hat, wobei der Eintrag in den Fehlerspeicher (10) wenigstens den Namen des Sensorsimulationsmodells (5a, 5b, 5c) und den Zeitpunkt des Berechnungsschritts (b) aufweist, zu welchem keine Empfangsbereitschaft mitgeteilt wurde.
Verfahren nach Anspruch 9, wobei die Koordinatorkomponente (7) eine Fehlereinheit (9) aufweist, und wobei die Fehlereinheit (9) einen Fehler registriert und einen Eintrag in einem Fehlerspeicher (10) protokolliert, wenn die Koordinatorkomponente (7) in dem Überprüfungsschritt feststellt, dass ein Umgebungsdatensatz (x,t) aus einem vorhergehendem Berechnungsschritt (b) zurückgeblieben ist.
Verfahren nach Anspruch 9 oder 10, wobei das Verfahren (1) eine vorbestimmte Anzahl von durch die Fehlereinheit (9) protokollierten Fehlern vorsieht, wobei bei Überschreiten der vorbestimmten Anzahl die Ausführung der Koordinatorkomponente (7) gestoppt wird, und/oder die Koordinatorkomponente (7) die Ausführung des Umgebungsmodells (3) stoppt, wobei die Ausführung der Koordinatorkomponente (7) und/oder des Umgebungsmodells (3) wieder aufgenommen wird, wenn alle Sensorsimulationsmodelle (5a, 5b, 5c) Empfangsbereitschaft mitteilen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das erste Sensorsimulationsmodell (5a) eine Verzögerungszeitspanne (j) an die Koordinatorkomponente (7) übermittelt, und wobei der Berechnungsschritt (b1) des ersten Sensorsimulationsmodells (5a) am Zeitpunkt t1+j gestartet wird, und die Koordinatorkomponente (7) an das erste Sensorsimulationsmodell (5a) den Umgebungsdatensatz (x,t) übermittelt, der dem Zeitpunkt t1 zugeordnet ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das erste Sensorsimulationsmodell (5a) eine Versatzzeitspanne (k) an die Koordinatorkomponente (7) übermittelt, und wobei der Berechnungsschritt des ersten Sensorsimulationsmodells (5a) am Zeitpunkt t1+k gestartet wird, und die Koordinatorkomponente (7) an das erste Sensorsimulationsmodell den Umgebungsdatensatz übermittelt, der dem Zeitpunkt t1+k zugeordnet ist
Computerprogrammprodukt mit einem Computerprogramm, das Softwaremittel zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 13 umfasst, wobei das Computerprogramm auf einem Computer ausgeführt wird.
Computerlesbares Speichermedium mit einem Computerprogramm, das Befehle umfasst, die bei Ausführung durch einen Computer diesen veranlassen, das Verfahren nach einem der Ansprüche 1 bis 13 auszuführen.