AT528437A1 - Verfahren zum Erstellen eines Fahrzeugmodells - Google Patents

Abstract

Die gegenständliche Erfindung betrifft ein computerimplementiertes Verfahren zum Erstellen und Validieren eines Fahrzeugmodells (1) zur Verwendung als digitalen Zwilling eines Fahrzeugs (2), wobei das erstellte und validierte Fahrzeugmodell (1) zum Steuern und/oder Betreiben des Fahrzeugs (2) angepasst ist und auf einer Rechnereinheit (5) ausgeführt wird. Im Verfahren ist vorgesehen, dass die folgenden Schritte durchlaufen werden: - Erstellen eines physikalischen Modells für zumindest eine Fahrzeugkomponente (4) des Fahrzeugs (2) und Erstellen zumindest einer virtuellen Steuereinheit (9) für die zumindest eine Fahrzeugkomponente (4) (S101); - Erstellen des Fahrzeugmodells (1), wobei das physikalische Modell der zumindest einen Fahrzeugkomponente (4) und die zumindest eine virtuelle Steuereinheit (9) kombiniert werden (S102); und - Validieren des erstellten Fahrzeugmodells (1), wobei mit dem Fahrzeugmodell (1) Simulationsdaten generiert werden, wobei aus den mit dem Fahrzeugmodell (1) generierten Simulationsdaten jene Simulationsdaten ausgewählt werden, deren Eingabedaten mit Messbedingungen von gemessenen Testdaten übereinstimmen, und wobei die ausgewählten Simulationsdaten mit den gemessenen Testdaten verglichen und auf eine Abweichung geprüft werden (S103, S1031).

Description

x bes AT 528 437 A1 2026-01-15

Ss N

Beschreibung

VERFAHREN ZUM ERSTELLEN EINES FAHRZEUGMODELLS

[0001] Die gegenständliche Erfindung betrifft ein computerimplementiertes Verfahren zum Erstellen eines Fahrzeugmodells zur Verwendung als digitalen Zwilling eines Fahrzeugs, wobei das erstellte und validierte Fahrzeugmodell zum Steuern und/oder Betreiben des Fahrzeugs angepasst ist und auf einer Rechnereinheit ausführbar ist. Weiterhin betrifft die gegenständliche Erfindung ein Computerprogrammprodukt.

STAND DER TECHNIK

[0002] Auf Grund der zunehmenden Komplexität von modernen Fahrzeugen und der Vielzahl an Sensoren und Aktoren werden in den Fahrzeugen Steuereinheiten mit hoher Rechenleistung verbaut, um die dementsprechende Datenmenge zu verarbeiten. Diese Steuereinheiten tragen nicht nur zu höheren Herstellungskosten der Fahrzeuge bei, sondern erhöhen auf Grund der hohen Rechenleistung folglich auch den Energieverbrauch des Fahrzeuges. Insbesondere bei rein batteriebetriebenen Fahrzeugen verringert sich dadurch die Reichweite. Bei konventionell angetriebenen Fahrzeugen mit Verbrennungsmotor erhöht sich der Energieverbrauch (z.B. Verbrauch von Benzin oder Diesel) und folglich auch der Schadstoffausstoß.

[0003] Grundsätzlich dient eine Steuereinheit (auch als Steuergerät bezeichnet) dazu, Steuerparameter auf Basis von Fahrzeugparametern (z.B. der Batterieladung, der Motorbetriebstemperatur, des Restsauerstoffgehalts im Abgas, usw.), welche durch die Sensoren des Fahrzeugs ermittelt werden, zu bestimmen. Mit diesen Steuerparametern werden dann Funktionen des Fahrzeugs während des Betriebs des Fahrzeugs gesteuert, wie z.B. eine Anpassung des Drehmoments des Antriebs, eine Einspritzmenge an Kraftstoff, eine Anpassung der Einstellung des Kühlsystems oder der Abgasnachbehandlung, usw. Im Fahrzeug ist eine entsprechende Sensorik vorhanden, um Fahrzeugparameter am Fahrzeug zu messen. Weiterhin können Fahrzeugparameter z.B. von der Steuereinheit aus anderen (gemessenen) Fahrzeugparametern ermittelt werden — d.h. z.B. berechnet oder aus vorhandenen Kennfeldern oder -linien entnommen werden.

[0004] Üblicherweise ist dazu in der Steuereinheit ein digitales Modell des realen (physischen) Fahrzeugs oder bestimmter Fahrzeugkomponenten hinterlegt. Dieses digitale Modell bildet das Verhalten des realen Fahrzeugs oder zumindest einer Fahrzeugkomponente ab und kann dadurch zumindest einen Steuerparameter für die Steuerung des realen Fahrzeugs oder der zumindest einen Fahrzeugkomponente auf Basis zumindest eines Fahrzeugparameters ermitteln. Dieses Modell weist zumindest Inputdaten oder Eingabedaten und Outputdaten oder Ausgabedaten auf. Die Inputdaten oder Eingabedaten bezeichnen dabei die Daten, welche dem Modell übergeben werden, wie z.B. Sensorwerte. Die Eingabedaten werden vom Modell verarbeitet und daraus die Outputdaten oder Ausgabedaten erzeugt, welche z.B. den zumindest einen Steuerparameter und/oder Aktuatordaten für eine Steuerung und/oder Betrieb des Fahrzeugs und/oder Betriebsdaten (z.B. Energieverbrauch, Abgaswerte, Kraftstoffverbrauch, etc.) umfassen.

[0005] Weiterhin weist das Modell Modellparameter auf. Dabei beschreiben die Modellparameter die physikalischen Eigenschaften (z.B. geometrische, kinematische, etc.) des realen Fahrzeugs, wobei den Modellparametern Modellparameterwerte zugewiesen werden, um das Modell zu parametrieren und dadurch das Verhalten des Fahrzeugs möglichst realitätsnah abzubilden. Die Modellparameter, konkret die Modellparameterwerte definieren, wie das Modell auf bestimmte Inputdaten oder Eingabedaten reagiert und damit welche Werte von den Outputdaten oder Ausgabedaten angenommen werden. Üblicherweise basieren die Modellparameter auf Daten, welche mittels realer Fahrzeuge oder Fahrzeugkomponenten beispielsweise in Versuchen (z.B. auf Prüfständen oder Teststrecken) und/oder mittels empirischer Modelle des Fahrzeugs (z.B. numerischer Simulation) ermittelt werden.

[0006] Ein in einer Steuereinheit eingesetztes Fahrzeugmodell oder Modell zumindest einer Fahrzeugkomponente wird dabei üblicherweise auf die notwendigsten Modellparameter des realen Fahrzeugs oder der realen Fahrzeugkomponente reduziert, um so die erforderliche Rechen-

x bes AT 528 437 A1 2026-01-15

Ss N

leistung der Steuereinheit des Fahrzeugs möglichst gering zu halten. Ein derartiges Modell ist oftmals als mathematisches Modell hinterlegt und kann als Softwarecode implementiert sein, welcher auf der Steuereinheit des Fahrzeugs ausgeführt wird.

[0007] Um Fahrzeuge oder deren Komponenten mit einem Fahrzeugmodell jedoch realitätsnäher simulieren zu können, kann beispielsweise, wie in der WO 2021/016250 A1 oder in der US 2022/0176938 A1 beschrieben, das Fahrzeugmodell von der Steuereinheit eines Fahrzeugs in eine externe und gegebenenfalls leistungsstärkere Recheneinheit (z.B. in einen Cloud-Server) ausgelagert werden. Im Fahrzeug können dadurch die Anforderungen an die Steuereinheit, insbesondere die Rechenleistung, reduziert werden und damit ein Energieverbrauch gesenkt werden. Weiterhin kann aufgrund der vielfach höheren Rechenleistung der externen Recheneinheit, wie z.B. eines Cloud-Servers, ein komplexeres und realitätsnäheres Modell eines realen Fahrzeugs verwendet werden, um z.B. ein Fahrzeugverhalten zu simulieren und/oder zumindest einen Steuerparameter für das Fahrzeug zu ermitteln.

[0008] Häufig wird bei einem in externe Recheneinheiten, wie z.B. Cloud-Server, ausgelagerten Fahrzeugmodell ein so genannter digitaler Zwilling (engl. Digital Twin) verwendet. Ein digitaler Zwilling stellt eine digitale Repräsentanz eines materiellen oder immateriellen Objekts aus der realen Welt, wie z.B. eines Fahrzeugs und/oder gleichartiger Fahrzeuge vom selbem Fahrzeugmodell oder aus der gleichen Produktionsserie und/oder von Fahrzeugen mit zumindest einer gleichen Fahrzeugkomponente (z.B., Batterie, Kühlerbaugruppe, etc.), in der digitalen Welt dar, wobei das Objekt in der realen Welt bereits existieren kann oder erst zukünftig existieren wird. Ein digitaler Zwilling umfasst zumeist Modelle des repräsentierten Objekts, wie z.B. eines Fahrzeugs oder zumindest einer Fahrzeugkomponente des Fahrzeugs, und kann auch Eigenschaften oder Verhalten des repräsentierten Objekts beschreiben, beeinflussen oder Dienste anbieten und z.B. eine übergreifenden Datenaustausch ermöglichen. Ein in eine externe Recheneinheit, wie z.B. einem Cloud-Server, ausgelagertes Fahrzeugmodell, für welches ein digitaler Zwilling verwendet wird, kann beispielsweise Eingabedaten (z.B. Sensordaten des Fahrzeugs, Routendaten, Verkehrssituation, Wetterdaten, etc.) von realen Fahrzeugen oder über andere Schnittstellen zur externen Recheneinheit und/oder über die Cloud erhalten, diese verarbeiten und dann entsprechende Ausgabedaten (z.B. Steuerparameter, Aktuatordaten, etc.) ermitteln und z.B. an reale Fahrzeuge zurücksenden, sofern eine Verbindung zwischen der externen Recheneinheit und den Fahrzeugen besteht. Die Steuereinheit im Fahrzeug kann dann beispielsweise relativ einfach ausgestaltet sein und im einfachsten Fall nur mehr dazu eingerichtet sein, ein Notprogramm ausführen, für den Fall, dass keine Verbindung zur externen Recheneinheit, wie dem Cloud-Server, besteht oder die Verbindung oder die Recheneinheit nicht verfügbar ist.

[0009] Üblicherweise werden heutzutage derartige Fahrzeugmodelle von Fahrzeugen, welche z.B. zur Steuerung von Fahrzeugen einsetzbar sind, erstellt, indem große Datenpools von gemessenen Fahrzeugdaten — das heißt, von realen Fahrzeugen im laufenden Betrieb und/oder Testbetrieb ermittelte Daten, wie z.B. Steuerparameter, Aktuatordaten und/oder Betriebsdaten, sowie nur ein empirischer Ansatz für die Modellierung des Fahrzeugmodells (z.B. Regression, Fourier-Reihen, künstliche neuronale Netzwerke, etc.) verwendet wird. Daten und/oder Modelle aus der Entwicklung fließen dabei in der Regel nicht in die Modellierung des Fahrzeugmodells ein. Das bedeutet, das Fahrzeugmodell wird rein auf Basis von Daten, welche während des Fahrbetriebs von Fahrzeugen als Mess-, Fahrzeug- und/oder Betriebsdaten gesammelt wurden, und von Beobachtungen erstellt. Dies weist allerdings den Nachteil auf, dass sich die gesammelten Mess-, Fahrzeug- und/oder Betriebsdaten der Fahrzeuge, wie z.B. Sensordaten und Werte von Aktuator- und/oder Steuerparametern, meist auf im Betrieb übliche Wertebereiche von Fahrzeugparametern beschränken sind. Mess-, Fahrzeug- und/oder Betriebsdaten für einen Betrieb des Fahrzeugs in Randbereichen beispielsweise für einen Betrieb des Fahrzeugs bei extremen Temperaturen (z.B. unter -20°C oder z.B. über 45°C) oder in größer Höhe (z.B. über 2000 m über dem Nullniveau) fehlen regelmäßig in diesen gesammelten Messdaten. Damit ist ein Gültigkeitsbereich des Fahrzeugmodells, welcher auch als Design Space bezeichnet wird, und auch des Fahrzeugs auf die üblichen Wertbereiche von Fahrzeugparametern beschränkt, welche durch den verwendeten Datenpool der im laufenden Betrieb ermittelten Fahrzeugdaten abgedeckt wer-

x bes AT 528 437 A1 2026-01-15

Ss N

den. Ein derartiges Fahrzeugmodell ist damit nicht geeignet, um einen Betrieb des Fahrzeugs in Randbereichen (z.B. bei tiefen und/oder hohen Umgebungstemperaturen, in großer Höhe, etc.) abzuschätzen oder zu simulieren, da es insbesondere für die Randbereich und/oder Extremwerte der Fahrzeugparameter keine validen Aussagen liefert.

DARSTELLUNG DER ERFINDUNG

[0010] Es ist daher eine Aufgabe der gegenständlichen Erfindung ein Fahrzeugmodell zur Verwendung als digitaler Zwilling eines Fahrzeugs zu erstellen, welches über breite Parameterwertbereiche valide Aussagen über ein Verhalten des Fahrzeugs ermöglicht und eine Basis für einen Betrieb des Fahrzeugs mit hoher Genauigkeit bietet.

[0011] Diese Aufgabe wird durch ein computerimplementiertes Verfahren sowie ein Computerprogrammprodukt gemäß den unabhängigen Ansprüchen gelöst. Vorteilhafte Ausführungsformen der vorliegenden Erfindung sind in den abhängigen Ansprüchen beschrieben.

[0012] Erfindungsgemäß erfolgt die Lösung der Aufgabe durch computerimplementiertes Verfahren zum Erstellen eines Fahrzeugmodells zur Verwendung als digitaler Zwilling eines Fahrzeugs, wobei für zumindest eine Fahrzeugkomponente des Fahrzeugs ein physikalisches Modell und zumindest eine virtuelle Steuereinheit erstellt wird, wobei das Fahrzeugmodell erstellt wird, indem das physikalische Modell der zumindest einen Fahrzeugkomponente und die zumindest eine virtuelle Steuereinheit kombiniert oder verknüpft werden, und wobei das erstellte Fahrzeugmodell validiert wird. Dazu werden mit dem erstellten Fahrzeugmodell Simulationsdaten generiert, wobei dem Fahrzeugmodell als Eingabedaten zumindest ein Fahrzeugparameter vorgegeben wird und der zumindest eine Fahrzeugparameter über einen vor- gebbaren Eingabewertebereich variiert wird. Dann werden aus den mit dem Fahrzeugmodell generierten Simulationsdaten jene Simulationsdaten ausgewählt, deren Eingabedaten mit Messbedingungen gemessener Testdaten übereinstimmen Dann werden die ausgewählten Simulationsdaten mit den gemessenen Testdaten verglichen und auf eine Abweichung geprüft.

[0013] Der Hauptaspekt der vorgeschlagenen Lösung besteht darin, dass für die Validierung des Fahrzeugmodells sowohl Simulationsdaten, die Eingabedaten, wie z.B. einem Fahrzeugparameter, zumeist mehreren Fahrzeugparametern, basieren, welche über eine vorgebbaren Eingabewertebereich variiert werden, als auch gemessene Testdaten verwendet werden, die die bei realen Messbedingungen ermittelt wurden. Derartige gemessene Testdaten umfassen beispielsweise Messwerte, welche auf einem Prüfstand, insbesondere einem Höhenprüfstand, generiert wurden, und/oder Messdaten, die von echten Testfahrten, gegebenenfalls unter speziellen Bedingungen (z.B. bei niedrigen und/oder hohen Umgebungstemperaturen, Bergfahrten, etc.) stammen. Beim Generieren der Simulationsdaten können durch entsprechende Vorgabe und Variieren der Eingabedaten beispielsweise Extremwerte von Fahrzeugparametern und/oder Randbereiche des Eingabewertebereichs des jeweiligen Fahrzeugparameters, beispielsweise besonders niedrige und/oder hohe Umgebungstemperaturen, große Höhe, etc., berücksichtigt werden, welche bei laufendem oder im üblichen Betrieb des Fahrzeugs nicht oder nur äußerst selten gemessen werden. Durch den Vergleich der mit dem Fahrzeugmodell generierten und ausgewählten Simulationsdaten mit den entsprechenden real gemessenen Testdaten und durch die Prüfung auf eine Abweichung der ausgewählten Simulationsdaten von diesen Testdaten wird sichergestellt, dass das Fahrzeugmodell eine hohe Genauigkeit aufweist und auch für Fahrzeugparameterwerte (z.B. Extremwerten, Randbereiche), zu denen keine Testdaten ermittelt wurden oder ermittelbar sind, valide Aussagen über das Verhalten des mit dem Fahrzeugmodell abgebildeten Fahrzeugs liefern kann.

[0014] Weiterhin wird dadurch der Gültigkeitsbereich, der sogenannte Design Space, für das Fahrzeugmodell idealerweise erweitert, wodurch auch zukünftige, mögliche Betriebsbedingungen des Fahrzeugs vom Fahrzeugmodell abgedeckt werden können. Durch die Validierung wird außerdem sichergestellt, dass das Fahrzeugmodell eine möglichst hohe Genauigkeit aufweist. Das bedeutet, das reale Verhalten des Fahrzeugs wird möglichst exakt abgebildet. Damit kann das Fahrzeugmodell idealerweise als Basis z.B. zum Steuern und Regeln des Fahrzeugs auf

x bes AT 528 437 A1 2026-01-15

Ss N

bestimmten Fahrtstrecken, zur Vorhersage von Wartungsbedarf (Predictive Maintainance) und/oder zum energieeffizienten und verschleißarmen Betreiben des Fahrzeugs verwendet werden.

[0015] Idealerweise wird vom validierten Fahrzeugmodell zumindest eine fahrzeugspezifische Modellvariante abgeleitet, welche ebenfalls wie das Fahrzeugmodell zum Steuern und/Betreiben des Fahrzeugs angepasst ist. Diese fahrzeugspezifische Modellvariante wird durch spezifische Parameter des abgebildeten realen, individuellen Fahrzeugs, wie z.B. Gewicht, Aerodynamik, Reifendruck, Alterung der Batterie, Verschmutzung des Kühlers, Druck- und Temperaturverluste, etc., definiert. Diese fahrzeugspezifische Modellvariante wird idealerweise auf einer Recheneinheit, wie z.B. einem Cloud-Server, bereitgestellt, wobei die zumindest eine fahrzeugspezifische Modellvariante einem realen Fahrzeug zugeordnet wird. Das bedeutet, dass die fahrzeugspezifische Modellvariante das zugeordnete reale Fahrzeug abbildet und damit zum Betreiben und/oder Steuern des zugeordneten realen Fahrzeugs verwendet werden kann. Typischerweise sind die vom validierten Fahrzeugmodell abgeleiteten Modellvarianten als so genannte Fast Models oder Fast Digital Twins ausgestaltet, damit von der Modellvariante Ausgabewerte (z.B. Steuerparameter für das individuelle Fahrzeug) rasch ermittelt und zur Verfügung gestellt werden können. Da die jeweilige fahrzeugspezifische Modellvariante vom validierten Fahrzeugmodell abgeleitet wurde, kann auch sie mit hoher Genauigkeit eine optimale Vorhersage des Verhaltens für das jeweils zugeordnete Fahrzeug liefern und z.B. zum Betreiben und/oder Steuern dieses Fahrzeugs z.B. auf einer vorgegebenen Fahrtstrecke verwendet werden.

[0016] Weiterhin ist es günstig, wenn auch das validierte Fahrzeugmodell und zumindest die Simulationsdaten als Datenpool auf der Recheneinheit (z.B. einem Cloud-Server) bereitgestellt werden. Damit stehen das validierte Fahrzeugmodell und die bei der Entwicklung sowie die bei der Validierung entstandenen Simulationsdaten auf der Recheneinheit zur Verfügung. Zusätzlich können auch die Testdaten aus der Fahrzeugentwicklung auf der Recheneinheit bereitgestellt werden. Damit stehen als Datenpool ein gesamter Bestand an Entwicklungstestdaten — d.h. Simulationsdaten des Fahrzeugmodells und während der Entwicklung gesammelte und genutzte Testdaten (z.B. aus einem Testbetrieb, von Prüfstanden, etc.) — auf der Recheneinheit zur Verfügung.

[0017] In einer bevorzugten Ausführungsform des Verfahrens zum Erstellen eines Fahrzeugmodells wird für die mit dem Fahrzeugmodell generierten und ausgewählten Simulationsdaten die Abweichung von den entsprechenden, real gemessenen Testdaten ermittelt. Dann wird geprüft, ob bei zumindest einer vorgegebenen Anzahl oder einem vorgegebenen Prozentsatz (z.B. 90% oder sogar 95%) der ausgewählten Simulationsdaten die ermittelte Abweichung von den entsprechenden real gemessenen Testdaten unterhalb einer vorgegebenen Abweichung liegt. Vorzugsweise wird für die vorgegebene Abweichung ein Prozentsatz von 5%, insbesondere 1%, vorgegeben. Durch die Vorgabe einer (möglichst geringen) Abweichung wird eine hohe Genauigkeit des Fahrzeugmodells erreicht.

[0018] In einer zweckmäßigen Weiterbildung des erfindungsgemäßen Verfahrens ist vorgesehen, das Fahrzeugmodell anzupassen, wenn für weniger als die vorgegebene Anzahl oder der vorgegebene Prozentsatz der ausgewählten Simulationsdaten eine Abweichung von den Testdaten unterhalb der vorgegebenen Abweichung ermittelt wird. Das angepasste Fahrzeugmodell wird dann erneut validiert, bis zumindest die vorgegebene Anzahl oder der vorgegebene Prozentsatz der ausgewählten Simulationsdaten eine Abweichung von den entsprechenden real gemessenen Testdaten unterhalb der vorgegebenen Abweichung aufweisen. Durch eine gegebenenfalls iterative Anpassung des Fahrzeugmodells wird sichergestellt, dass nur ein Fahrzeugmodell zum Einsatz kommt, dessen Simulationsdaten maximal die vorgegebene Abweichung von den real gemessenen Testdaten aufweist.

[0019] Es ist auch günstig, wenn während eines Betriebs des zumindest einen realen Fahrzeugs Fahrzeugparameter und Fahrzeugdaten auf der Recheneinheit, z.B. dem Cloud-Server, für eine Aktualisierung und Erweiterung des Datenpools gesammelt und gespeichert werden.

[0020] Damit wird der Datenpool auf einfache Weise um real gemessene Daten (z.B. Fahrzeug-

x bes AT 528 437 A1 2026-01-15

Ss N

parameter, Sensormesswerte, Fahrzeugdaten, Betriebsdaten, etc.) aus dem laufenden Betrieb des zumindest einen Fahrzeugs, üblicherweise mehrerer Fahrzeuge oder einer Fahrzeugflotte erweitert, welche durch das Fahrzeugmodell abgebildet werden.

[0021] Es ist weiterhin vorteilhaft, wenn das Fahrzeugmodell mit dem aktualisierten und erweiterten Datenpool neu parametriert und aktualisiert wird, wobei vom neu parametrierten und aktualisierten Fahrzeugmodell zumindest eine aktualisierte fahrzeugspezifische Modellvariante abgeleitet wird. Das Fahrzeugmodelle und in der Folge die vom Fahrzeugmodell abgeleiteten fahrzeugspezifischen Modellvarianten werden dadurch noch besser und genauer an die abgebildeten Fahrzeuge und deren Verhalten angepasst.

[0022] Idealerweise wird das neu parametrierte und aktualisierte Fahrzeugmodell — und auch die davon abgeleitete fahrzeugspezifische Modellvariante —- in vorgegebenen zeitlichen Intervallen erstellt wird. Diese regelmäßige Anpassung kann in vorteilhafter Weise bis zum Lebensende des jeweiligen Fahrzeugs durchgeführt werden. Damit könnten z.B. Fahrzeugalterung, Verschleißerscheinungen, etc. der Fahrzeuge im Fahrzeugmodell und vor allem in den fahrzeugspezifischen Modellvarianten berücksichtigt werden, welche damit bestmöglich an die jeweiligen Fahrzeuge angepasst werden können und das Verhalten der jeweiligen Fahrzeuge mit hoher Genauigkeit repräsentieren können.

[0023] Eine bevorzugte Ausgestaltung der Erfindung sieht vor, dass die zumindest eine fahrzeugspezifische Modellvariante zum Betreiben des zugeordneten Fahrzeugs verwendet wird, wobei der fahrzeugspezifischen Modellvariante als zumindest ein Fahrzeugparameter eine Fahrtstrecke für das zugeordnete Fahrzeug vorgegeben wird, wobei von der fahrzeugspezifischen Modellvariante anhand der vorgegebenen Fahrtstrecke ein Zusammenhang zwischen einem Energiebedarf und/oder einem Fahrzeugverschleiß des Fahrzeugs und einer Fahrtzeit des Fahrzeugs für die vorgegebene Fahrtstrecke ermittelt wird, wobei der Zusammenhang zwischen dem Energiebedarf und/oder dem Fahrzeugverschleiß des Fahrzeugs und der Fahrtzeit des Fahrzeugs für eine Auswahl einer Fahrtzeit ausgegeben wird, und wobei nach Auswahl einer akzeptablen Fahrtzeit von der fahrzeugspezifischen Modellvariante Steuerparameter zum Betreiben des Fahrzeugs ermittelt und dem Fahrzeug vorgegeben werden. Mit dieser Verwendung der fahrzeugspezifischen Modellvariante wird auf einfache Weise ermöglicht, ein Fahrzeug entweder mit minimaler Fahrzeit, minimalen Energiebedarf und/oder minimalen Fahrzeugverschleiß zu betreiben. Von der fahrzeugspezifischen Modellvariante werden anhand der Vorgabe der Fahrtstrecke (z.B. anhand eines Fahrziels bei bekanntem aktuellem Standort des Fahrzeugs) mögliche Szenarien bzw. Einstellungen der Steuerparameter für das Fahrzeug in Abhängigkeit von einer möglichen Fahrtzeit (z.B. in Form einer Zeitverzögerung gegenüber einer prognostizierten Mindestfahrtzeit) für die zu fahrende Fahrtstrecke ermittelt und ausgegeben. Durch die Auswahl einer gewünschten oder akzeptablen Fahrtzeit und/oder Zeitverzögerung gegenüber einer prognostizierten Mindestfahrzeit können dann ein optimales Szenario und damit optimale Einstellungen für die Steuerparameter während der tatsächlichen Fahrt zum Fahrziel gewählt werden. Es kann idealerweise in einem Entscheidungsraum zwischen minimaler Zeit (z.B. prognostizierte Mindestfahrzeit), minimalen Energiebedarf und/oder minimalen Fahrzeugverschleiß gewählt werden.

[0024] Idealerweise wird ein Ermitteln des Zusammenhangs zwischen dem Energiebedarf und/oder dem Fahrzeugverschleiß des Fahrzeugs und der Fahrtzeit des Fahrzeugs durch die fahrzeugspezifische Modellvariante unter Berücksichtigung einer aktuellen Verkehrssituation auf der vorgegebenen Fahrtstrecke, aktueller Wetterbedingungen und weitere externer Einflüsse in der Recheneinheit durchgeführt. Dadurch fließen die aktuellen Bedingungen für die Fahrt zum vorgegebenen Fahrtziel idealerweise in die Ermittlung des Zusammenhangs zwischen dem Energiebedarf und/oder dem Fahrzeugverschleiß des Fahrzeugs und der Fahrtzeit des Fahrzeugs ein.

[0025] Es ist günstig, wenn eine Eingabe der Fahrtstrecke und eine Auswahl der Fahrtzeit im Fahrzeug beispielsweise durch den Fahrer erfolgen kann. Der Fahrer kann z.B. die Fahrtstrecke durch eine Eingabe des Fahrziels in ein Navigationssystem eingeben. Der Zusammenhang zwischen dem Energiebedarf und/oder dem Fahrzeugverschleiß des Fahrzeugs und der Fahrtzeit des Fahrzeugs kann dann dem Fahrer zur Auswahl einer akzeptablen Fahrtzeit z.B. auf einer

x bes AT 528 437 A1 2026-01-15

Ss N

Ausgabeeinheit im Fahrzeug (z.B. Navigationssystem, Informationssystem, etc.) ausgegeben werden. Die Auswahl der gewünschten Fahrtzeit (z.B. akzeptable Zeitverzögerung) erfolgt dann beispielsweise durch den Fahrer ebenfalls auf der Ausgabeeinheit. Es ist aber auch möglich, dass eine eigene Eingabeeinheit für die Auswahl der gewünschten Fahrtzeit (z.B. akzeptable Zeitverzögerung) vorgesehen ist.

[0026] Alternativ oder zusätzlich kann vorgesehen sein, dass die Eingabe der Fahrtstrecke und die Auswahl der Fahrtzeit auch an einer zentralen Stelle, wie z.B. einer Spedition, Fahrzeugdisposition, etc. erfolgen, welche einen Betrieb des Fahrzeugs plant und überwacht. Die Fahrtstrecke des Fahrzeugs kann dann von der zentralen Stelle z.B. in Form des Fahrziels des Fahrzeugs eingegeben werden. Die Ausgabe des Zusammenhangs zwischen dem Energiebedarf und/oder dem Fahrzeugverschleiß des Fahrzeugs und der Fahrtzeit des Fahrzeugs erfolgt dann z.B. auf einer Ausgabeeinheit in der zentralen Stelle, wobei eine Auswahl einer gewünschten oder akzeptablen Fahrtzeit für das Fahrzeug (z.B. in Form einer zulässigen Zeitverzögerung gegenüber der prognostizierten Mindestfahrzeit) idealerweise ebenfalls für diese Ausgabeeinheit erfolgen kann.

[0027] Zur Lösung der Aufgabe ist auch ein Computerprogrammprodukt vorgesehen, welches auf eine Recheneinheit (z.B. einen Cloud-Server) ladbar ist und/oder auf der Recheneinheit ausführbar ist. Das Computerprogrammprodukt umfasst zumindest einen Softwarecode eines Fahrzeugmodells zur Verwendung als digitaler Zwilling eines Fahrzeugs, wobei dieses Fahrzeugmodell nach dem erfindungsgemäßen Verfahren erstellt wurde. Weiterhin kann das Computerprogrammprodukt auch einen Softwarecode der zumindest einen Modellvariante umfassen, welche vom Fahrzeugmodell abgeleitet wurde.

KURZBESCHREIBUNG DER FIGUREN

[0028] Die gegenständliche Erfindung wird nachfolgend unter Bezugnahme auf die Figuren 1 bis 4 näher erläutert, die beispielhaft, schematisch und nicht einschränkend vorteilhafte Ausgestaltungen der Erfindung zeigen. Dabei zeigt

[0029] Fig. 1 schematisch einen Einsatz eines Fahrzeugmodells zur Verwendung als digitaler Zwilling zur Steuerung eines oder mehrerer Fahrzeuge,

[0030] Fig. 2a einen beispielhaften Ablauf eines Verfahrens zum Erstellen eines Fahrzeugmodells zur Verwendung als digitaler Zwilling;

[0031] Fig. 20 eine vorteilhafte Variante des beispielhaften Ablaufs des Verfahrens zum Erstellen eines Fahrzeugmodells zur Verwendung als digitaler Zwilling;

[0032] Fig. 3 einen Ablauf einer beispielhaften Verwendung einer vom Fahrzeugmodell abgeleiteten, fahrzeugspezifischen Modellvariante zum Betreiben eines Fahrzeugs; und

[0033] Fig. 4 einen von der fahrzeugspezifischen Modellvariante eines Fahrzeugs beispielhaft ermittelten Zusammenhang zwischen einer Fahrzeit des Fahrzeugs auf einer vorgegebenen Fahrtstrecke und einem Energiebedarf und/oder Fahrzeugverschleiß.

AUSFÜHRUNG DER ERFINDUNG

[0034] Figur 1 zeigt beispielhaft und schematisch einen Einsatz eines Fahrzeugmodells 1 zur Verwendung als digitaler Zwilling 1, mit welchem ein physikalisches Verhalten eines Fahrzeugs 2 abgebildet werden kann. Das Fahrzeugmodell 1 kann beispielsweise für eine Steuerung eines Fahrzeugs 2 oder mehreren gleichartigen Fahrzeugen 2 eingesetzt werden, welche z.B. dasselbe Modell oder Type (z.B. Fahrzeuge 2 aus der gleichen Produktionsserie) und dasselbe Antriebssystem aufweisen oder zumindest eine gleiche Fahrzeugkomponente 4 (z.B. Batterie, Kühlerbaugruppe, etc.) gemeinsam haben. Die Fahrzeuge 2 können z.B. Personenkraftwagen, Lastkraftwagen, Busse, etc. sein und können z.B. zu einer Fahrzeugflotte gehören, welche aus einer bekannten oder festgelegten Anzahl an Fahrzeugen 2 besteht. Als Antriebssystem können die Fahrzeuge 2 beispielsweise ein konventionelles oder ein rein elektrisches oder ein kombiniertes (hyb-

x bes AT 528 437 A1 2026-01-15

Ss N

rides) Antriebssystem aufweisen. Unter einem konventionellen Antriebssystem ist ein Antriebssystem mit Verbrennungsmotor, der mit Benzin oder einem anderen Brennstoff betrieben wird, Zu verstehen. Der Begriff „gleiches Antriebssystem“ umfasst neben der gleichen Art des Antriebssystems vorzugsweise auch eine gleiche Leistung des Antriebssystems, wobei aber auch unterschiedliche Leistungen des Antriebssystems möglich sind.

[0035] Jedes der Fahrzeuge 2 weist mehrere Fahrzeugkomponenten 4 auf, wie z.B. einen Antriebsstrang, eine Bremsanlage, ein Kühlsystem, eine Pumpe (Aktuator) des Kühlsystems, eine Batterie, ein Abgasnachbehandlungssystem, etc. Idealerweise umfasst die zumindest eine Fahrzeugkomponente 4 jene Komponenten des Fahrzeuges 2, welche beispielsweise durch eine optimierte Steuerung Einfluss auf einen Energieverbrauch, einen Verschleiß, eine Emission, usw., des Fahrzeuges 2 haben, also generell die Effizienz des Fahrzeuges 2 verbessern können.

[0036] Weiterhin wird in jedem Fahrzeug 2 mit zumindest einer Sensoreinheit 3 des Fahrzeugs 2 zumindest ein Fahrzeugparameter FP von zumindest einer Fahrzeugkomponente 4 erfasst, welche beispielsweise bei allen Fahrzeugen 2 vorhanden ist. Im Prinzip erfasst die Sensoreinheit 3 jeweils einen aktuellen Wert des Fahrzeugparameters FP. Als zumindest eine Sensoreinheit 3 wird ein geeigneter Sensor verwendet, um den gewünschten Fahrzeugparameter FP erfassen zu können. In einem Fahrzeug 2 sind üblicherweise eine Fülle von Sensoren verbaut, die verschiedene Fahrzeugparameter FP erfassen. Als Sensoreinheit 3 kann beispielsweise ein Temperatursensor, ein Drehzahlsensor, ein Beschleunigungssensor, etc., im Fahrzeug 2 vorgesehen sein.

[0037] Der erfasste zumindest eine Fahrzeugparameter FP beschreibt einen Zustand der zumindest einen Fahrzeugkomponente 4. Der Zustand der zumindest einen Fahrzeugkomponente 4 kann beispielsweise eine Batterieladung, eine Motorbetriebstemperatur, ein Restsauerstoffgehalt im Abgas, eine Kühlwassertemperatur, etc., sein. Dieser Zustand kann aber auch Umgebungsbedingungen der Fahrzeugkomponente 4, wie z.B. eine Umgebungstemperatur beschreiben. Als Fahrzeugparameter FP kann auch eine Bedienung des Fahrzeugs 2 (durch einen Fahrer oder autonom), wie etwa ein Getriebegang, eine Stellung des Beschleunigungspedals, etc., erfasst werden. Weiterhin können Eingaben oder Einstellungen von Fahrzeugkomponenten 4 als Fahrzeugparameter FP erfasst werden, welche durch Interaktionen des Fahrers oder anderer Insassen während des Betriebs mit der jeweiligen Fahrzeugkomponente (z.B. ein Informationssystem, ein Navigationssystem, eine Klimaanlage, etc.) entstehen.

[0038] Das Fahrzeugmodell 1 zur Verwendung als digitaler Zwilling wird in einer externen Recheneinheit 5, wie z.B. einem Cloud-Server, betrieben, welcher eine notwendige Rechenleistung zur Verfügung stellt. Dieses Fahrzeugmodell 1, mit welchem ein Fahrzeugverhalten inklusive der Interaktion der Fahrzeugkomponenten 4 oder das Verhalten einer Fahrzeugkomponente 4 inklusive zugehöriger Interaktionen abgebildet und simuliert werden kann, stellt einen sehr genauen digitalen Zwilling 1 der Fahrzeuge 2 dar, und kann ein Simulationsergebnis in Echtzeit erstellen. Das bedeutet, die Simulationszeit entspricht 1:1 der realen Ablaufzeit des simulierten Verhaltens oder eine Sekunde in der Simulation entspricht einer Sekunde in der Realität. Das Fahrzeugmodell 1 wird mittels des erfindungsgemäßen Verfahrens erstellt, welches noch anhand der Figur 2 im Detail beschrieben wird.

[0039] Weiterhin sind auf der Recheneinheit 5 für jedes Fahrzeug 2 fahrzeugspezifische individuelle Modellvarianten 6 vorgesehen. Die fahrzeugspezifischen Modellvarianten 6 werden vom Fahrzeugmodell 1, das bedeutet, vom digitalen Zwilling 1 des Fahrzeugs 2, abgeleitet. Dazu kann beispielsweise für jedes individuelle Fahrzeug 2 mittels künstlicher Intelligenz, insbesondere mittels so genannter Reinforcement Learning-Methoden und/oder mittels anderer Methoden des maschinellen Lernens, auf Basis eines Datenpools 7 eine fahrzeugspezifische Modellvariante 6 ermittelt werden. Im Datenpool 7, welcher z.B. ebenfalls auf der externen Recheneinheit 5, insbesondere auf dem Cloud-Server 5, sein kann, sind beispielsweise zumindest Simulationsdaten, welche während der Entwicklung des Fahrzeugs 2sowie des Fahrzeugmodells 1 (z.B. für eine Validierung) vom Fahrzeugmodell 1 generiert wurden, im laufenden Betrieb und/oder im Feldbetrieb der Fahrzeuge 2 gesammelte Fahrzeugparameter FP (z.B. Sensorwerte) und weitere gesammelte Fahrzeugdaten (z.B. Aktuatorparameter, Betriebsverhalten, Serviceintervalle, Alte-

x bes AT 528 437 A1 2026-01-15

Ss N

rung, etc.) sowie gegebenenfalls auch Mess- und Testdaten aus der Fahrzeugentwicklung enthalten.

[0040] Das bedeutet, auf der Recheneinheit 5, insbesondere dem Cloud-Server 5, ist für jedes Fahrzeug 2 eine fahrzeugspezifische und individualisierte Modellvariante 6 vorgesehen, welche dem jeweiligen Fahrzeug 2 zugeordnet ist. Diese fahrzeugspezifische Modellvariante 6 wird vor der Verwendung parametriert bzw. individualisiert, sodass die jeweilige Modellvariante 6 zumindest eine physikalische Eigenschaft und/oder ein physikalisches Verhalten des jeweiligen individuellen Fahrzeug 2 beschreibt. Dazu werden Eingaben, wie beispielsweise Gewicht, Aerodynamik, Reifendruck, Alterung der Batterie, Verschmutzung des Kühlers, Druck- und Temperaturverluste, etc., herangezogen werden, welche das jeweilige Fahrzeug 2 charakterisieren. Damit wird im Wesentlichen festgelegt, mit welchem zumindest einen Ausgabewert die jeweilige Modellvariante 6 auf zumindest einen Eingabewert reagiert.

[0041] Die fahrzeugspezifischen Modellvarianten 6 können beispielsweise als mathematisches Modell, insbesondere als sogenanntes Fast Model, ausgestaltet sein. Dabei können die fahrzeugspezifischen Modellvarianten 6 einen Echtzeitfaktor aufweisen, der typischerweise 1000 beträgt. Das bedeutet, dass eine Sekunde in der Simulation mit der Modelvariante 6 1000 Sekunden in der Realität entspricht, wodurch die jeweilige Modelvariante 6 sehr rasch das individuelle physikalische Verhalten des jeweiligen Fahrzeug 2 und damit Ausgabewerte, wie beispielsweise Steuerparameter SP für das Fahrzeug 2, ermitteln kann. Das Fahrzeugmodell 1 sowie die fahrzeugspezifischen Modellvarianten 6 können als Softwarecode implementiert sein, welche von der Recheneinheit 5 oder dem Cloud-Server 5 ausgeführt wird.

[0042] Die externe Recheneinheit 5 ist mit dem jeweiligen Fahrzeug 2 über eine geeignete drahtlose Kommunikationsverbindung 8 (z.B. über das Mobilfunknetz, vorzugsweise 5G) verbunden. Diese Kommunikationsverbindung 8 ist dazu ausgebildet, den zumindest eine Fahrzeugparameter FP, vorzugsweise in Echtzeit, vom Fahrzeug 2 zu empfangen und der dem Fahrzeug 2 zugeordneten Modelvariante 6 als Eingabewerte bereitzustellen. Zusätzlich zu dem zumindest einen Fahrzeugparameter FP kann der Modellvariante 6 auch eine Information über einen Standort des Fahrzeugs 2 (z.B. ein GNSS-Signal), über Wetterbedingungen (Regen, Schnee, usw.), über eine geplante Route des Fahrzeugs 2 oder über Verkehrsbedingungen (z.B. Stau auf der geplanten Route) zur Verfügung gestellt werden.

[0043] Im Betrieb der Fahrzeuge 2 werden die Fahrzeugparameter FP laufend, vorzugsweise in vorgegebenen zeitlichen Abständen, die auch von den jeweiligen Fahrzeugparametern FP abhängen, erfasst und über die Kommunikationsverbindung 8 an die externe Recheneinheit 5 übermittelt. Die Fahrzeugparameter FP können dort — gemeinsam mit weiteren Fahrzeugdaten (z.B. Aktuatorparameter, Betriebsverhalten, Serviceintervalle, Alterung, etc.) gesammelt und im Datenpool 7 gespeichert werden.

[0044] Mit der Modellvariante 6 des Fahrzeugs 2 wird dann aus dem zumindest einen erhaltenen Fahrzeugparameter FP (z.B. Motorbetriebstemperatur, Fahrtziel, Ladestatus der Batterie, etc.) zumindest ein Steuerparameter SP als Ausgabewert für das zugeordnete Fahrzeug 2 ermittelt. Der zumindest eine ermittelte Steuerparameter SP wird dann über die Kommunikationsverbindung 8, vorzugsweise in Echtzeit, an das zugeordnete Fahrzeug 2 übermittelt und von einer Steuereinheit 9 des zugeordneten Fahrzeugs 2 verwendet, um zum Betrieb des Fahrzeugs 2 eine Funktion des Fahrzeugs 2 zu steuern (z.B. Anpassen einer Durchflussgeschwindigkeit einer Kühlflüssigkeit, Regelung der Geschwindigkeit, Drehmoment des Antriebs, Abgasnachbehandlung, etc.). Neben dem zumindest einen Steuerparameter SP kann das Modell noch weitere Ausgabewerte bereitstellen. Wie die Fahrzeugparameter FP können auch die daraus von der Modellvariante 6 ermittelten Steuerparameter SP gesammelt und im Datenpool 7 gespeichert werden.

[0045] Die Funktionen des Fahrzeugs 2 hängen grundsätzlich von der Art des Fahrzeugs 2 und dessen Antriebssystem ab. Dabei sind die Funktionen des Fahrzeugs 2 jedoch nicht auf das Antriebssystem beschränkt. Es können auch Funktionen von anderen Fahrzeugkomponenten 4 gesteuert werden, z.B. mit welchen der Fahrer oder andere Insassen des Fahrzeugs 2 während des Betriebs interagieren, wie etwa ein Informationssystem, ein Navigationssystem, eine Klimaan-

x bes AT 528 437 A1 2026-01-15

Ss N

lage, etc. Beispielsweise könnte auch eine Eingabe in ein Navigationssystem (z.B. Fahrtziel) übermittelt werden, um z.B. ein Fahrzeug 2 oder bestimmte Fahrzeugkomponenten 4 des Fahrzeugs 2 auf einer bestimmten Fahrtstrecke zu steuern und zu regeln oder um z.B. einen Energiebedarf und/oder einen Fahrzeugverschleiß in Abhängigkeit von der Fahrzeit mit Hilfe der fahrzeugspezifischen Modellvariante 6 zu ermitteln — wie noch anhand der Figuren 3 und 4 im Detail erläutert wird.

[0046] Figur 2a zeigt beispielhaft und schematisch einen Ablauf eines Verfahrens zum Erstellen eines Fahrzeugmodells 1 zur Verwendung als digitaler Zwilling, welches ein physikalisches Verhalten eines Fahrzeugs 2 abbildet. Das Fahrzeugmodell 1 kann auf einer externen Recheneinheit 5 betrieben werden und ist zum Steuern und/oder Betreiben von Fahrzeugen 2 angepasst.

[0047] Dazu werden während der Entwicklung eines Fahrzeugs 2 (z.B. Design- und Entwicklungsphase für ein neues Fahrzeug 2) in einem ersten Modellierungsschritt S101 ein physikalisches Modell für zumindest eine Fahrzeugkomponente 4, wie z.B. einen Antriebsstrang, eine Bremsanlage, ein Kühlsystem, eine Pumpe (Aktuator) des Kühlsystems, eine Batterie, ein Abgasnachbehandlungssystem, etc., idealerweise für eine Anzahl verschiedener Fahrzeugkomponenten 4 des (geplanten und zu produzierenden) Fahrzeugs 2 erstellt. Der Begriff des physikalischen Modells kommt aus der Systemtechnik. Beim Erstellen eines physikalischen Modells werden üblicherweise physikalische Grundfunktionen und Module des zu modellierenden Systems benutzt, um das Verhalten des zumeist komplexen zu modellierenden Systems in mathematische Funktionen zu formulieren und um sie berechenbar zu machen. Bei physikalischen Modellen besteht daher zumeist ein naher Zusammenhang zwischen dem Modell und der Realität, wodurch z.B. physikalische Einflüsse von außen (z.B. Temperatur, Höhe, Wettereinflüsse, etc.) einfach und direkt als Variation in die Simulation mit dem Modell einfließen können.

[0048] Für die Erstellung des physikalischen Modells für die zumindest eine Fahrzeugkomponente 4 können beispielsweise Lieferanten- oder Herstellerdaten der jeweiligen Fahrzeugkomponenten 4 herangezogen und spezielle Modellierungswerkzeuge, wie z.B. Matlab, GT-Power, Flowermaster, etc., verwendet. Das erstellte, physikalische Modell der zumindest einen Fahrzeugkomponente wird dann z.B. mittels Messungen auf einem Prüfstand validiert. Parallel dazu wird im ersten Modellierungsschritt S101 für die zumindest eine Fahrzeugkomponente 4 zumindest eine entsprechende virtuelle Steuereinheit 9 erstellt, welche mittels zumindest eines Steuerparameters SP die zumindest eine Fahrzeugkomponente 4 und/oder das entsprechende physikalische Modell der Fahrzeugkomponente 4 ansteuert. Die virtuelle Steuereinheit 9 wird beispielsweise als Software-Komponente erstellt und entspricht weitgehend der in einem realen Fahrzeug 2 eingesetzten Steuereinheit 9, um die jeweilige Fahrzeugkomponente 4 anzusteuern. Üblicherweise wird für jede der modellierten Fahrzeugkomponenten 4 des Fahrzeugs 2 zumindest eine entsprechende virtuelle Steuereinheit 9 erstellt, durch welche die modellierten Fahrzeugkomponenten 4 ansteuerbar sind. Zum Erstellen der zumindest einen virtuellen Steuereinheit 9 werden z.B. ebenfalls Lieferanten- oder Herstellerdaten herangezogen. Eine Validierung der zumindest einen Steuereinheit 9 kann ebenfalls mittels Messungen auf einem Prüfstand erfolgen. Für die zumindest eine erstellte, virtuelle Steuereinheit 9 kann z.B. der reale Steuerungssoftwarecode verwendet, welcher auch für einen Einsatz im Fahrzeug 2 vorgesehen ist.

[0049] In einem zweiten Modellierungsschritt S102 werden dann das physikalische Modell der zumindest einen Fahrzeugkomponente 4 beispielsweise mit einem Verknüpfungstool mit der entsprechenden zumindest einen virtuellen Steuereinheit 9 kombiniert. Durch die Verknüpfung des physikalischen Modells der zumindest einen Fahrzeugkomponente 4 und der zumindest einen virtuellen Steuereinheit 9 wird das Fahrzeugmodell 1 erstellt, welches das physikalische Verhalten des (geplanten und zu produzierenden) Fahrzeugs 2 und/oder der zumindest einen Fahrzeugkomponente 4, für welche das physikalische Modell im ersten Modellierungsschritt S101 erstellt wurde, abbilden soll. Üblicherweise werden im ersten Modellierungsschritt S101 für eine Anzahl von Fahrzeugkomponenten 4 physikalische Modelle sowie entsprechende virtuelle Steuereinheiten 9 erstellt., Die physikalischen Modelle dieser Anzahl von Fahrzeugkomponenten werden dann im zweiten Modellierungsschritt S102 mit den entsprechenden virtuellen Sensoreinheiten 9 kombiniert, um das Fahrzeugmodell 1 zu erhalten. Von diesem Fahrzeugmodell 1 wird dann

x bes AT 528 437 A1 2026-01-15

Ss N

das Verhalten des Fahrzeugs 2, insbesondere das Zusammenwirken der modellierten Fahrzeugkomponenten 4 und der virtuellen Sensoreinheiten 9, beschrieben. Dieses Fahrzeugmodell 1 kann in der Folge als digitaler Zwilling des Fahrzeugs 2 verwendet werden, um ein physikalisches Verhalten des Fahrzeugs 2 bei Eingabe zumindest eines Fahrzeugparameters FP — idealerweise bei Eingabe mehrerer Fahrzeugparameter FP (z.B. Umgebungstemperatur, Höhenlage während des Fahrzeugbetrieb, Sensorwerte, etc.) — zu simulieren.

[0050] In einem Validierungsschritt S103, z.B. am Ende der Design- und Entwicklungsphase, wird dann das im zweiten Modellierungsschritt S102 erstellte Fahrzeugmodell 1 für einen möglichst großen Gültigkeitsbereich validiert. Das bedeutet, das Fahrzeugmodell 1 kann für einen großen Eingabewertebereich des zumindest einen Fahrzeugparameter FP valides Ausgabedaten liefern und deckt damit Randwerte des Eingabewertebereichs und/oder Extremwerte des zumindest einen Fahrzeugparameters FP ab. Dazu werden mit dem Fahrzeugmodell 1 Simulationsdaten generiert und als Eingabedaten für das Fahrzeugmodell 1 der zumindest eine Fahrzeugparameter FP verwendet. Dabei wird der zumindest eine als Eingabedaten verwendeten Fahrzeugparameter FP über einen vorgebbaren — zumeist sehr großen — Eingabewertebereich variiert. Üblicherweise sind die Eingabedaten des Fahrzeugmodells 1 multidimensional und umfassen mehrerer variierbare Fahrzeugparameter FP (z.B. Temperatur, Höhe, Reifendruck, etc.). Das bedeutet, es werden als Eingabedaten Kombinationen unterschiedlicher Fahrzeugparameter FP verwendet und dabei von den einzelnen Fahrzeugparameter FP vorgebbare — zumeist große — Eingabewertebereiche durchlaufen, sodass die Simulationsdaten als Ausgabedaten des Fahrzeugmodells 1 auch ein Fahrzeugverhalten in Randbereichen und/oder bei Extremwerten der Fahrzeugparameter FP (z.B. einen Betrieb bei tiefen und/oder hohen Umgebungstemperaturen, auf großer Höhe, etc.) abdecken. Das Generieren der Simulationsdaten kann z.B. mittels Cloud Computing, d.h. mittels geteilter Computerressourcen, etwa in Form von mehreren Recheneinheiten, erfolgen, um eine entsprechenden Rechenleistung zur Verfügung zu haben.

[0051] Andererseits werden für den Validierungsschritt S103 real gemessene Testdaten herangezogen, welche unter vorgegebenen und/oder einstellbaren Messbedingungen (z.B. Umgebungstemperatur, Höhe, Reifendruck, etc.) ermittelt werden. Diese Testdaten umfassen beispielsweise Messwerte, welche auf einem Prüfstand, insbesondere einem Höhenprüfstand, unter beispielsweise vorgebbaren Messbedingungen ermittelt wurden, und/oder Messwerte, die von echten Testfahrten, gegebenenfalls unter speziellen Messbedingungen (z.B. bei niedrigen und/oder hohen Umgebungstemperaturen, Bergfahrten, etc.) ermittelt wurden.

[0052] Dann werden die mit dem Fahrzeugmodell 1 generierten Simulationsdaten mit den real gemessenen Testdaten verglichen. Dazu werden jene Simulationsdaten aus den mit den Fahrzeugmodell 1 generierten Simulationsdaten als Validierungspunkte ausgewählt, deren zumindest einer als Eingabedaten verwendeter Fahrzeugparameter FP (z.B., Temperatur, Höhe, etc.) mit Messbedingungen der gemessenen Testdaten übereinstimmt. Das bedeutet, wurde beispielsweise für einen aus den Simulationsdaten ausgewählten Validierungspunkt eine bestimmte Temperatur als Fahrzeugparameter FP und damit als Eingabewert für das Fahrzeugmodell 1 vorgegeben, so muss dieser Validierungspunkt mit gemessenen Testdaten verglichen werden, welche bei derselben Temperatur ermittelt wurden. Dann werden die als Validierungspunkte ausgewählten Simulationsdaten mit den jeweils passenden Testdaten verglichen und auf eine Abweichung von den Testdaten sowie eine Genauigkeit des Fahrzeugmodells 1 geprüft.

[0053] Für diese Prüfung im Validierungsschritt S$S103 kann beispielsweise ein Bewertungskriterium in Form einer maximal zulässigen Abweichung zwischen den mit dem Fahrzeugmodell 1 generierten und als Validierungspunkte ausgewählten Simulationsdaten und den real gemessenen Testdaten vorgegebenen werden. Die Abweichung kann beispielsweise ein vorgegebener Prozentsatz, z.B. 5%, vorzugsweise 1%, sein. Zusätzlich kann das Bewertungskriterium auch vorgeben, wie viele der als Validierungspunkte ausgewählten Simulationsdaten die maximal zulässige Abweichung nicht überschreiten dürfen. Dazu kann z.B. ein Prozentsatz, idealerweise 90% oder sogar 95%, vorgegeben werden. Das bedeutet, dass beispielsweise der vorgegebene Prozentsatz (z.B. 90% oder sogar 95%) der als Validierungspunkte ausgewählten Simulationsdaten die maximal zulässige Abweichung nicht überschreiten dürfen.

x bes AT 528 437 A1 2026-01-15

Ss N

[0054] Nach dem Validierungsschritt S103 liegt ein Fahrzeugmodell 1 zur Verwendung als digitaler Zwilling für ein Fahrzeug 2 vor, das eine sehr hohe Genauigkeit (z.B. Genauigkeitsstufe 3) aufweist und das physikalische Verhalten des Fahrzeugs 2 möglichst exakt — auch in Randbereichen und/oder bei Extremwerten von Fahrzeugparametern FP — als digitaler Zwilling des Fahrzeugs 2 simulieren kann. Das validierte Fahrzeugmodell 1 weist typischerweise einen Echtzeitfaktor von 1 (d.h., eine Sekunde der Simulation entsprecht einer Sekunde in der Realität) auf. Weiterhin umfasst das validierte Fahrzeugmodell 1 ein validiertes physikalisches Modell für die zumindest eine Fahrzeugkomponente 4 und die zumindest eine virtuelle Steuereinheit 9, von welcher ein realer (d.h. im Fahrzeug 2 eingesetzte) Steuerungssoftwarecode verwendet wird. Üblicherweise weist das validierte Fahrzeugmodell 1 eine Anzahl an validierten physikalischen Modellen von Fahrzeugkomponenten 4 sowie entsprechende virtuelle Steuereinheiten 9 auf, um das Verhalten des Fahrzeugs 2 und/oder zumindest das Verhalten einzelner Fahrzeugkomponenten 4 des Fahrzeugs 2 möglichst genau zu simulieren.

[0055] Idealerweise werden im Validierungsschritt S103 für die Validierung des Fahrzeugmodells 1 beispielsweise bei Fahrzeugen 2 mit einem konventionellen Antriebssystem oder mit einem Antriebssystem mit Verbrennungsmotor Simulationsdaten und real gemessene Testdaten wie z.B. Kraftstoffverbrauch, Luftstrom durch den Motor, Temperatur und Drücke im Ein- und Auslass, NOx-Emissionen, etc. verwendet. Bei Fahrzeugen 2 mit elektrischem Antriebssystem und/oder mit einem kombinierten Antriebssystem können z.B. Energieverbrauch zum Betrieb bei einer vorgegebenen Geschwindigkeit des Fahrzeugs 2, Energie zur Kühlung, Massenstrom von Kühlflüssigkeit, etc. betrachtet werden. Weiterhin können auch Verschleißdaten der Fahrzeuge 2, wie z.B. ein Alterungszustand einer Batterie eines Fahrzeugs 2 mit elektrischem und/oder kombiniertem Antriebssystem oder ein Alterungszustand eines Luft-Flüssigkeitskühlers oder ein Alterungszustand anderer Fahrzeugkomponenten 4, betrachtet werden.

[0056] Nach dem Validierungsschritt S103 wird dann in einem Implementierungsschritt S104, welcher beispielsweise kurz vor einem Produktionsstart des Fahrzeugs 2 durchgeführt wird, vom Fahrzeugmodell 1 zumindest eine fahrzeugspezifische Modellvariante 6 abgeleitet. Die fahrzeugspezifische Modellvariante 6 wird durch Modellparameter, das bedeutet, durch Eingaben, die das individuelle Fahrzeug 2 charakterisieren, wie z.B. Gewicht, Aerodynamik, Reifendruck, Alterung der Batterie, Verschmutzung der Kühlerflüssigkeit, Druck- und Temperaturverluste, etc., definiert. Die fahrzeugspezifische Modellvariante 6, die im Implementierungsschritt S104 mittels künstlicher Intelligenz und/oder mittels so genannter Reinforcement Learning-Methoden und/oder andere Methoden des maschinellen Lernens erstellt wird, basiert nur auf der Grundlage der Simulationsdaten des validierten Fahrzeugmodell 1, welche z.B. im Validierungsschritt S103 generiert wurden. Die fahrzeugspezifische Modellvariante 6 kann z.B. als mathematisches Modell, insbesondere als sogenanntes Fast Model oder Fast Digital Twin, ausgestaltet sein und beispielsweise einen Echtzeitfaktor von typischerweise 1000 aufweisen — d.h., eine Sekunde in der Simulation mit der Modellvariante 6 entspricht 1000 Sekunden in der Realität. Die zumindest eine fahrzeugspezifische Modellvariante 6 kann dann noch mit dem Fahrzeugmodell 1 verglichen werden, um sicherzustellen das beide Modelle 1, 6 ähnliche Ergebnisse — d.h. Simulationsdaten — mit einer gewissen Genauigkeit liefern.

[0057] Nach dem Produktionsstart des Fahrzeugs 2 werden dann im Implementierungsschritt S104 das Fahrzeugmodell 1, die zumindest eine fahrzeugspezifische Modellvariante 6 und zumindest die Simulationsdaten des Fahrzeugmodells 1 aus dem Validierungsschritt S103 auf der externen Recheneinheit 5 bereitgestellt, wobei die Recheneinheit 5 eine Kommunikationsverbindung 8 zu jedem der Fahrzeuge 2 z.B. einer Fahrzeugflotte aufweist. Weiterhin wird die zumindest eine fahrzeugspezifische Modellvariante 6 einem jeweiligen realen Fahrzeug 2 zugeordnet. Im Prinzip wird jedem Fahrzeug 2 der Fahrzeugflotte eine fahrzeugspezifische individuelle Modellvariante 6 zugeordnet, welche dann — wie anhand von Figur 1 bereits beschrieben — zum Betreiben und/oder Steuern des jeweiligen Fahrzeugs 2 angepasst ist und eingesetzt werden kann.

[0058] Die Simulationsdaten des Fahrzeugmodells 1 bilden eine Startversion des Datenpools 7. In diesem Datenpool 7 können im Implementierungsschritt S104 beispielsweise auch die Messdaten aus der Fahrzeugentwicklung, welche z.B. zur Validierung des Fahrzeugmodells 1 im Va-

x bes AT 528 437 A1 2026-01-15

Ss N

lidierungsschritt S103 verwendet wurden, abgelegt werden, sodass ein gesamter Bestand an Entwicklungsmessdaten — d.h. Simulationsdaten und real gemessene Testdaten — als Startversion des Datenpools 7 auf der externen Recheneinheit 5 bereitgestellt wird.

[0059] Während des laufenden Betriebs der Fahrzeuge 2 oder der Fahrzeugflotte werden die von den Fahrzeugen 2 gelieferten Fahrzeugparameter FP (z.B. Sensorwerte, etc.), die aus den Fahrzeugparametern FP abgeleiteten Steuerparameter (z.B. Aktuatorparameter, Betriebsverhalten, etc.) und weiteren Fahrzeugdaten (z.B. Serviceintervalle, Alterung, etc.) gesammelt und im Datenpool 7 gespeichert. Der Datenpool 7 enthält nun neben den Simulationsdaten und gegebenenfalls den Testdaten aus der Entwicklung, welche im Implementierungsschritt S104 auf der Recheneinheit 5 bereitgestellt wurden, auch die während des Betriebs nach dem Produktionsstart des Fahrzeugs 2 gesammelten Fahrzeugparameter, Steuerparameter und Fahrzeugdaten.

[0060] In einem Aktualisierungsschritt S105 kann dann das Fahrzeugmodell 1 mit dem aktuellen Datenpool 7, welcher auch die während des Betriebs des Fahrzeugs 2 gesammelten Fahrzeugparameter FP, aus den Fahrzeugparametern FP abgeleiteten Steuerparameter SP und weitere Fahrzeugdaten enthält, neu parametriert und aktualisiert werden, um die Genauigkeit gegenüber den Fahrzeugen 2 zu erhöhen. Das bedeutet, dass in Abhängigkeit von festgestellten Änderungen z.B. der gesammelten Fahrzeug- und/oder Steuerparameter FP, SP die Modellparameter des Fahrzeugmodells 1 angepasst werden. Vom aktualisierten Fahrzeugmodell 1 können dann unter Verwendung des Datenpools 7 neue aktualisierte fahrzeugspezifische Modellvarianten 6 für die Fahrzeuge 2 erstellt werden, um hier die Genauigkeit gegenüber dem jeweils zugeordneten Fahrzeug 2 zu erhöhen. Idealerweise wird der Aktualisierungsschritt S106 in vorgegebenen zeitlichen Intervallen (z.B. alle 3 bis 12 Monate) z.B. bis zu einem „Ende der Lebensdauer“ des jeweiligen Fahrzeugs 2 durchgeführt werden, um sicherzustellen, dass die jeweilige fahrzeugspezifische Modellvariante 6 das jeweilige individuelle Fahrzeug 2 repräsentiert und um z.B. unterschiedliche Alterung und/oder Verschließ von Fahrzeugkomponenten 4, etc. der jeweiligen Fahrzeuge bestmöglich in der jeweils zugeordneten fahrzeugspezifischen Modellvariante 6 zu berücksichtigen.

[0061] Figur 2b zeigt beispielhaft und schematisch eine vorteilhafte Variante des Verfahrens zum Erstellen eines Fahrzeugmodells zur Verwendung als digitaler Zwilling. Diese Variante weist ebenfalls den ersten und den zweiten Modellierungsschritt S101, S102 auf, in welchen zuerst ein physikalisches Modell zumindest einer Fahrzeugkomponente 4 und zumindest eine zugehörigen virtuellen Steuereinheit 9 erstellt und validiert werden und dann durch Kombinieren und/oder Verknüpfen der zumindest einen virtuellen Steuereinheit 9 mit dem validierten physikalischen Modell der zumindest einen Fahrzeugkomponente 4 das Fahrzeugmodell 1 erstellt wird.

[0062] Dieses Fahrzeugmodell 1 wird wieder in einem Validierungsschritt S1031 validiert. D.h., es werden mit dem Fahrzeugmodell 1 einerseits Simulationsdaten für Eingabedaten (z.B. Fahrzeugparameter, etc.) generiert, welche über einen vorgebbaren — zumeist sehr großen — Eingabewertebereich variiert werden, und andererseits real gemessene Testdaten herangezogen. Dann wird wieder die Abweichung zwischen von ausgewählten Simulationsdaten und den entsprechenden real gemessenen Testdaten ermittelt.

[0063] Dazu werden beispielsweise im Validierungsschritt S1031 Simulationsdaten als Validierungspunkte ausgewählt, deren Eingabedaten mit den Messbedingungen der real gemessenen Testdaten übereinstimmen, und mit diesen Testdaten werden. Für die ausgewählten Simulationsdaten wird dann die Abweichung von den real gemessenen Testdaten ermittelt. Die ermittelte Abweichung wird anschließend mit dem vorgegebenen Prozentsatz für die Abweichung verglichen. Der vorgegebene Prozentsatz kann beispielsweise 5%, vorzugsweise nur 1% betragen. Dabei wird zusätzlich überprüft, ob eine vorgegebene Anzahl oder ein vorgegebener Prozentsatz (z.B. 90% oder sogar 95%) der als Validierungspunkte ausgewählten Simulationsdaten, die vorgegebene Abweichung nicht überschreitet.

[0064] Wird dann im Validierungsschritt S1031 festgestellt, dass beispielsweise weniger als die vorgegeben Anzahl oder der vorgegebene Prozentsatz der als Validierungspunkte ausgewählten Simulationsdaten eine Abweichung aufweisen, die kleiner als die vorgegebene Abweichung ist,

x bes AT 528 437 A1 2026-01-15

Ss N

so kann das Fahrzeugmodell 1 beispielsweise in einem Anpassungsschritt S1032 angepasst werden. Das bedeutet, das Fahrzeugmodell 1 wird z.B. angepasst, wenn beispielsweise weniger als 90% (oder sogar weniger als 95%) der ausgewählten Simulationsdaten eine Abweichung von nicht mehr als 5%, idealerweise 1%, von den entsprechenden real gemessenen Testdaten aufweisen.

[0065] Nach dem Anpassen kann der Validierungsschritt S1031 mit dem angepassten Fahrzeugmodell 1 nochmals durchlaufen werden, um die Abweichung zwischen den ausgewählten Simulationsdaten und den entsprechenden real gemessenen Testdaten nochmals zu überprüfen, wobei Simulationsdaten in diesem Durchlauf vom angepassten Fahrzeugmodell generiert werden. Im Prinzip könnte der Anpassungsschritt S1032 solange wiederholt werden, bis im Validierungsschritt S1031 festgestellt wird, dass zumindest von der vorgegebenen Anzahl oder vom vorgegebenen Prozentsatz der ausgewählten Simulationsdaten die vorgegebene Abweichung nicht mehr überstiegen wird. Hierdurch wird sichergestellt, dass die Simulationsdaten weitgehend mit den real gemessenen Testdaten übereinstimmen, vorzugsweise ein vorgegebener Prozentsatz der Simulationsdaten (z.B. 90% oder mehr) innerhalb einer Toleranz liegen.

[0066] Wird im Validierungsschritt S1031 festgestellt, dass zumindest von der vorgegebenen Anzahl oder vom vorgegebenen Prozentsatz der als Validierungspunkte ausgewählten Simulationsdaten die vorgegebene Abweichung von den entsprechenden real gemessene Testdaten nicht überschritten wird, so wird — wie in dem in Figur 2a dargestellten Ablauf des Verfahrens — mit dem Implementierungsschritt S104 fortgesetzt. Hierbei wird vom validierten Fahrzeugmodell 1 die zumindest eine fahrzeugspezifische Modellvariante 6 abgeleitet und es werden das Fahrzeugmodell 1, die zumindest eine fahrzeugspezifische Modellvariante sowie zumindest die Simulationsdaten als Datenpool 7 auf der externen Recheneinheit 5 bereitgestellt werden. Dort kann dann die zumindest eine fahrzeugspezifische Modellvariante wieder mit zumindest einem realen Fahrzeug verknüpft werden und es können laufend Fahrzeugdaten aus dem laufenden Betrieb des zumindest einen realen Fahrzeugs, wie z.B. Fahrzeugparameter FP, aus den Fahrzeugparametern FP ermittelte Steuerparameter und weitere Fahrzeugdaten, auf der externen Recheneinheit 5 gesammelt und gespeichert werden, um den Datenpool 7 zu erweitern und zu aktualisieren. Ebenso können das Fahrzeugmodell 1 sowie die zumindest eine fahrzeugspezifische Modellvariante 6 im Aktualisierungsschritt 105, welcher in zeitlich vorgegebenen Intervallen (z.B. alle 3 bis 12 Monate) durchlaufen wird, auf Basis des erweiterten und aktualisierten Datenpools 7 aktualisiert werden.

[0067] Figur 3 zeigt beispielhaft und schematisch einen Ablauf einer Verwendung einer vom Fahrzeugmodell 1 abgeleiteten, fahrzeugspezifischen Modellvariante 6 zum Betreiben des Fahrzeugs 2, welches der fahrzeugspezifischen Modellvariante 6 zugeordnet ist. Insbesondere zeigt die Figur 3 einen Ablauf, um mit der fahrzeugspezifischen Modellvariante 6 einen optimalen — d.h. energieeffizienten und verschleißarmen — Fahrzeugbetrieb des jeweils zugeordneten Fahrzeug 2 in Abhängigkeit von einer Fahrzeit (z.B. in Form einer Zeitverzögerung D gegenüber einer prognostizierten Mindestfahrzeit) für eine vorgegebene Fahrtstrecke zu ermitteln. Das Fahrzeug 2 kann beispielsweise ein Lastkraftwagen, kurz LKW, oder ein Kleinlastkraftwagen einer Fahrzeugflotte sein, welcher z.B. ein rein elektrisches Antriebssystem aufweist. Es ist aber auch denkbar, dass das Fahrzeug 2 ein anderes Antriebssystem (z.B. Verbrennungsmotor, Hybrid-Antriebssystem) aufweist. Diesem Fahrzeug 2, insbesondere dem LKW2 ist die fahrzeugspezifische Modellvariante 6 zugeordnet. D.h., die fahrzeugspezifische Modellvariante 6 beschreibt das physikalische Verhalten des zugeordneten Fahrzeugs 2 und wurde dazu mit Modellparametern, wie z.B. Gewicht, Aerodynamik, Reifendruck, Alterung der Batterie, Verschmutzung des Kühlers, Druck- und Temperaturverluste, etc., parametriert, um das individuelle, zugeordnete Fahrzeug 2 zu beschreiben.

[0068] Zum Ermitteln des optimalen Fahrzeugbetrieb des Fahrzeugs 2 auf der vorgegebenen Fahrtstrecke wird in einem Eingabeschritt S201 der fahrzeugspezifischen Modellvariante 6 die geplante Fahrtstrecke des Fahrzeug 2 als Eingabewert oder als Fahrzeugparameter FP vorgegeben. Dazu kann z.B. vom Fahrer über eine Fahrzeugkomponente 4, wie z.B. ein Navigationssystem, die geplante Fahrtstrecke des Fahrzeugs 2 in Form eines Fahrziels eingegeben werden.

x bes AT 528 437 A1 2026-01-15

Ss N

Das eingegebene Fahrziel des Fahrzeugs 2 wird an die fahrzeugspezifische Modellvariante 6 z.B. als Fahrzeugparameter FP über die Kommunikationsverbindung 8 — beispielsweise gemeinsam mit einer aktuellen Standortinformation des Fahrzeugs 2 (z.B. GPS-Signal, etc.) — übermittelt. Alternativ kann die Eingabe der geplanten Fahrtstrecke des Fahrzeugs 2 beispielsweise auch von einer zentralen Stelle vorgenommen werden, welche die Touren der Fahrzeuge 2 plant und deren Erledigung überwacht (z.B. Spedition, Disposition einer Spedition, etc.). Diese zentrale Stelle muss dazu eine Kommunikationsverbindung 8 (z.B. Internetverbindung) zur externen Recheneinheit 5 aufweisen, auf welcher die fahrzeugspezifische Modellvariante 6 bereitgestellt wird.

[0069] In einem Simulationsschritt S202 wird dann von der fahrzeugspezifischen Modellvariante 6 anhand des eingegebenen Fahrtstrecke fahrzeugindividuell ein Zusammenhang zwischen einem Energiebedarf E und/oder einem Fahrzeugverschleiß DI (z.B. einer Batterie bei einem rein elektrischen Antriebssystem, etc.) und einer Fahrtzeit des Fahrzeugs 2 auf der geplanten Fahrtstrecke ermittelt werden. Die Fahrtzeit des Fahrzeugs 2 kann z.B. in Form einer Zeitverzögerung D gegenüber einer prognostizierten Mindestfahrzeit für die vorgegebenen Fahrtstrecke ausgestaltet sein. Dabei können von der fahrzeugspezifischen Modellvariante 6 aktuelle Verkehrsverhältnisse auf der vorgegebenen Fahrtstrecke, aktuelle Wetterbedingungen und/oder andere externe Einflüsse auf die Fahrtzeit, den Energiebedarf E und/oder den Fahrzeugverschleiß DI berücksichtigt werden. Diese Informationen können der fahrzeugspezifischen Modellvariante 6 beispielsweise vom zugeordneten Fahrzeug 2 und/oder dessen Fahrzeugkomponenten 4 als weitere Fahrzeugparameter FP (z.B. Sensorwerte, etc.) und/oder von externen Informationssystemen (z.B. Verkehrsdienst, Wetterdienst, etc.) z.B. über Schnittstellen zu entsprechenden Cloud-Servern zur Verfügung gestellt werden. Die Ermittlung des fahrzeugindividuellen Energiebedarfs E und/oder des Fahrzeugverschleißes DI in Abhängigkeit von der Fahrzeit, insbesondere der Zeitverzögerung D gegenüber der prognostizierten Mindestfahrzeit für die vorgegebenen Fahrtstrecke wird von der fahrzeugspezifischen Modellvariante 6 idealerweise auf der externen Recheneinheit 5, insbesondere einem Cloud-Server, durchgeführt, welche die entsprechende Rechenleistung für eine rasche Ermittlung bietet.

[0070] Der als Ergebnis des Simulationsschritts S202 ermittelte Zusammenhang zwischen Energiebedarf E und/oder Fahrzeugverschleiß DI und der Fahrzeit, beispielsweise in Form der Zeitverzögerung D gegenüber der Mindestfahrzeit für die vorgegebenen Fahrtstrecke, wird dann in einem Ausgabeschritt S203 von der fahrzeugspezifischen Modellvariante 6 zur Verfügung gestellt werden. Dazu kann beispielsweise das Ergebnis des Simulationsschritts S202 im Ausgabeschritt S203 an das Fahrzeug 2 und/oder an eine Fahrzeugkomponente 4 (z.B. Navigationssystem, Informationssystem, etc.) des Fahrzeugs 2, welchem der fahrzeugspezifischen Modellvariante 6 zugeordnet ist, über die Kommunikationsverbindung 8 übermittelt werden. Im Fahrzeug 2 kann dann das Ergebnis des Simulationsschritts S202 dem Fahrer z.B. über eine Ausgabeeinheit einer Fahrzeugkomponente 4 (z.B. Navigationssystem, Informationssystem, etc.) angezeigt werden. Alternativ kann der im Simulationsschritt S202 ermittelte Zusammenhang zwischen Energiebedarf E und/oder Fahrzeugverschleiß DI und der Fahrzeit und/oder der Zeitverzögerung D gegenüber der prognostizierten Mindestfahrzeit für die vorgegebenen Fahrtstrecke im Ausgabeschritt S203 auch an eine Ausgabeeinheit in der zentralen Stelle (z.B. Spedition, Disposition einer Spedition, etc.) übertragen werden, wenn das Fahrziel für das Fahrzeug 2 von dieser vorgegeben wurde.

[0071] Figur 4 zeigt beispielhaft einen Zusammenhang zwischen Energiebedarf E und/oder Fahrzeugverschleiß DI eines Fahrzeugs 2 und einer Fahrzeit und/oder einer Zeitverzögerung D gegenüber einer prognostizierten Mindestfahrzeit für die vorgegebene Fahrtstrecke. Ein derartiger Zusammenhang wurde beispielsweise von der fahrzeugspezifischen Modellvariante 6 im Simulationsschritt S202 ermittelt und kann im Ausgabeschritt S203 z.B. auf einer Ausgabeeinheit (z.B. Display eines Navigations- oder Informationssystems, Bildschirm in einer zentralen Stelle, wie z.B. einer Disposition einer Spedition) ausgegeben werden. Auf der x- Achse des in Figur 4 beispielhaft gezeigten Zusammenhangs ist beispielsweise die Zeitverzögerung D gegenüber der prognostizierten Mindestfahrzeit für die vorgegebene Fahrtstrecke in Minuten aufgetragen, wobei ein beispielhafter Bereich von 0 bis 20 Minuten für die Zeitverzögerung dargestellt ist. Alternativ

x bes AT 528 437 A1 2026-01-15

Ss N

könnte auf der x-Achse auch die Fahrtzeit selbst dargestellt sein. Die y-Achse zeigt den jeweiligen Energiebedarf E und den jeweiligen Fahrzeugverschleiß DI bei der jeweiligen Zeitverzögerung, wobei der Fahrzeugverschleiß DI in Figur 4 beispielsweise in Form eines Verschleißindex für eine Batterie eines rein elektrisch betriebenen Fahrzeugs 2 dargestellt. Dieser Verschleißindex kann von der fahrzeugspezifischen Modellvariante 6 im Simulationsschritt S202 beispielsweise auf Basis eines Energiedurchsatzes, eines Temperaturniveaus während der geplanten Fahrt auf der vorgegebenen Fahrtstrecke und einer Dauer und/oder Intensität von Vibrationen berechnet werden.

[0072] Aus dem in Figur 4 beispielhaft dargestellten Zusammenhang, welcher z.B. dem Fahrer des Fahrzeugs 2 und/oder in der zentralen Stelle (z.B. Spedition, Fahrzeugdisposition, etc.) im Ausgabeschritt S203 angezeigt wird, ist ersichtlich, dass sowohl der Energiebedarf E als auch der Fahrzeugverschleiß DI, insbesondere der Verschleißindex der Batterie, bei einer Zeitverzögerung D von ca. 10 min ein relatives Minimum aufweisen. Das bedeutet, wird vom Fahrer oder Spediteur z.B. eine um 10 Minuten längere Fahrtzeit als die prognostizierte Mindestfahrtzeit (d.h. eine Fahrtzeit mit einer Zeitverzögerung D von 0 min) in Kauf genommen, so kann das Fahrzeug 2 auf der vorgegebenen Fahrtstrecke wesentlich energieeffizienter und verschleißärmer betrieben werden.

[0073] In einem Auswahlschritt S204 kann dann beispielsweise der Fahrer oder der Spediteur in der zentralen Stelle eine akzeptable Fahrtzeit und/oder akzeptable Zeitverzögerung D für die vorgegebenen Fahrstrecke auswählen. Hierdurch erreicht das Fahrzeug 2 das vorgegebene Fahrziel um die gewählte Zeitverzögerung D später, als wenn keine Zeitverzögerung D gewählt würde und die vorgegebene Fahrtstrecke in der prognostizierten Mindestfahrzeit (z.B. einer von einem Navigationsgerät ermittelten Fahrtzeit) zurückgelegt werden würde. Die aktuelle Verkehrssituation, aktuelle Wetterbedingungen und/oder andere externe Einflüsse auf die (Mindest-)Fahrtzeit können bei der prognostizierten Mindestfahrtzeit berücksichtigt sein.

[0074] Die Auswahl der akzeptablen Fahrtzeit und/oder Zeitverzögerung D kann z.B. über die Ausgabeeinheit erfolgen, von welcher der Zusammenhang zwischen Energiebedarf E und/oder Fahrzeugverschleiß DI des Fahrzeugs 2 und Fahrzeit und/oder der Zeitverzögerung D für die vorgegebenen Fahrtstrecke angezeigt wird. Es ist aber auch möglich, dass Voreinstellungen für akzeptable Zeitverzögerungen D z.B. in Form einer Eingabeeinheit oder Eingabefunktion im Fahrzeug oder auf einer Fahrzeugkomponente 4 (z.B., Drehknopf, Auswahlliste auf einem Display oder Bildschirm, etc.) vorgesehen sind.

[0075] Die gewählte akzeptable Fahrtzeit und/oder Zeitverzögerung D kann dann als Eingabewert oder Fahrzeugparameter FP über die Kommunikationsverbindung 8 an die fahrzeugspezifische Modellvariante 6 übermittelt werden. Die fahrzeugspezifische Modellvariante 6 ermittelt dann die zur gewählten Fahrtzeit und/oder Zeitverzögerung D passenden Steuerparameter SP, über welche beispielsweise eine Geschwindigkeit des Fahrzeugs 2 und entsprechende Einstellungen der Aktuatoren im Fahrzeug 2 gesteuert werden können. In einem Umsetzungsschritt S205 werden dann die für die gewählte Fahrtzeit und/oder Zeitverzögerung D ermittelten Steuerparameter SP über die Kommunikationsverbindung 8 an das Fahrzeug 2 und damit folglich an die entsprechenden Steuereinheiten 9 im Fahrzeug 2 übermittelt, um das Fahrzeug 2 mit der fahrzeugspezifischen Modellvariante 6 energieeffizient und verschleißarm in Abhängigkeit von der gewählten Fahrtzeit und/oder Zeitverzögerung D auf der vorgegebenen Fahrtstrecke zu betreiben. Durch die Verwendung der fahrzeugspezifischen Modellvariante 6 kann idealerweise gewählt werden, ob das zugeordnete Fahrzeug 2 auf einer vorgegebenen Fahrtstrecke mit der Mindestfahrtzeit, mit minimalem Energiebedarf E und/oder minimalen Fahrzeugverschleiß DI betrieben wird.

[0076] Werden z.B. während der Fahrt auf der vorgegebenen Fahrtstrecke Veränderungen z.B. der Verkehrssituation festgestellt, so kann z.B. der Fahrer oder auch die zentrale Stelle (z.B. Spediteur) z.B. über die fahrzeugspezifische Modellvariante 6 informiert werden. Es besteht dann die Möglichkeit die gewählte Fahrtzeit und/oder die gewählte Zeitverzögerung D zu ändern und damit auch den Betrieb des Fahrzeugs 2 an die geänderte Situation anzupassen.

16 / 25

x bes AT 528 437 A1 2026-01-15

Ss N

Patentansprüche

1. Computerimplementiertes Verfahren zum Erstellen eines Fahrzeugmodells (1) zur Verwendung als digitaler Zwilling eines Fahrzeugs (2), wobei das erstellte und validierte Fahrzeugmodell zum Steuern und/oder Betreiben des Fahrzeugs angepasst ist und auf einer Rechnereinheit ausführbar ist, dadurch gekennzeichnet, dass zumindest folgende Schritte ausgeführt werden:

- Erstellen eines physikalischen Modells für zumindest eine Fahrzeugkomponente (4) des Fahrzeugs (2) und Erstellen zumindest einer virtuellen Steuereinheit (9) für die zumindest eine Fahrzeugkomponente (4) (S101);

- Erstellen des Fahrzeugmodells (1), wobei das physikalische Modell der zumindest einen Fahrzeugkomponente (4) und die zumindest eine virtuelle Steuereinheit (9) kombiniert werden (S102); und

- Validieren des erstellten Fahrzeugmodells (1), wobei mit dem Fahrzeugmodell (1) Simulationsdaten generiert werden, bei welchen als Eingabedaten zumindest ein Fahrzeugparameter (FP) verwendet wird und der zumindest eine Fahrzeugparameter (FP) über einen vorgebbaren Eingabewertebereich variiert wird, wobei aus den mit dem Fahrzeugmodell (1) generierten Simulationsdaten jene Simulationsdaten ausgewählt werden, deren Eingabedaten mit Messbedingungen von gemessenen Testdaten übereinstimmen, und wobei die ausgewählten Simulationsdaten mit den gemessenen Testdaten verglichen und auf eine Abweichung geprüft werden (S103, S1031).

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass vom validierten Fahrzeugmodell (1) zumindest eine fahrzeugspezifische Modellvariante (6) abgeleitet wird (S104), welche zum Steuern und/oder Betreiben eines realen Fahrzeugs angepasst ist.

3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, dass das validierte Fahrzeugmodell (1) und zumindest die Simulationsdaten als Datenpool (7) auf einer Recheneinheit (5), insbesondere einem Cloud-Server (5), bereitgestellt werden (S105), und dass weiterhin die zumindest eine fahrzeugspezifische Modellvariante (6) auf der Recheneinheit bereitgestellt und ausgeführt wird (S104), wobei die zumindest eine fahrzeugspezifische Modellvariante (6) einem realen Fahrzeug (2) zugeordnet wird, welches von der zumindest einen fahrzeugspezifischen Modellvariante (6) gesteuert und/oder betrieben wird.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass für die mit dem Fahrzeugmodell (1) generierten und ausgewählten Simulationsdaten die Abweichung von den entsprechenden, real gemessenen Testdaten ermittelt wird (S1031), und dass geprüft wird, ob für zumindest eine vorgegebene Anzahl oder einen vorgegebenen Prozentsatz der ausgewählten Simulationsdaten die ermittelte Abweichung unterhalb einer vorgegebenen Abweichung liegt (S1031).

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Fahrzeugmodell (1) angepasst wird (S1032), wenn für weniger als die vorgegebene Anzahl oder der vorgegebene Prozentsatz der ausgewählten Simulationsdaten eine Abweichung von den entsprechenden real gemessenen Testdaten kleiner als die vorgegebene Abweichung ermittelt wird, und dass das angepasste Fahrzeugmodell (1) erneut validiert wird (S1031), bis zumindest die vorgegebene Anzahl oder der vorgegebene Prozentsatz der ausgewählten Simulationsdaten eine Abweichung von den entsprechenden real gemessenen Testdaten unterhalb der vorgegebenen Abweichung aufweist.

6. Verfahren nach einem der Ansprüche 4 oder 5, dadurch gekennzeichnet, dass für die vorgegebene Abweichung vorzugsweise ein Prozentsatz von 5%, vorzugsweise von 1% vorgegeben wird.

7. Verfahren nach einem der Ansprüche 3 bis 6, dadurch gekennzeichnet, dass während eines Betriebs des zumindest einen realen Fahrzeugs (2) Fahrzeugparameter (FP) und Fahrzeugdaten auf der Recheneinheit (5) für eine Aktualisierung und Erweiterung des Datenpools (7) gesammelt und gespeichert werden (S104).

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das Fahrzeugmodell (1) mit dem aktualisierten und erweiterten Datenpool (7) neu parametriert und aktualisiert wird, wobei vom neu parametrierten und aktualisierten Fahrzeugmodell (1) zumindest eine aktualisierte fahrzeugspezifische Modellvariante (6) abgeleitet wird (S105).

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass das neu parametrierte und aktualisierte Fahrzeugmodell (1) in vorgegebenen zeitlichen Intervallen erstellt wird (S105).

10. Verfahren nach einem der Ansprüche 3 bis 9, dadurch gekennzeichnet, dass die zumindest eine fahrzeugspezifische Modellvariante (6) zum Betreiben des zugeordneten Fahrzeugs (2) verwendet wird, wobei der fahrzeugspezifischen Modellvariante (6) als zumindest ein Fahrzeugparameter (FP) eine Fahrtstrecke für das zugeordnete Fahrzeug (2) vorgegeben wird (S201), wobei von der fahrzeugspezifischen Modellvariante (6) anhand der vorgegebenen Fahrtstrecke ein Zusammenhang zwischen einem Energiebedarf (E) und/oder einem Fahrzeugverschleiß (DI) des Fahrzeugs (2) und einer Fahrtzeit des Fahrzeugs (2) für die vorgegebene Fahrtstrecke ermittelt wird (S202), wobei der Zusammenhang zwischen dem Energiebedarf (E) und/oder dem Fahrzeugverschleiß (DI) des Fahrzeugs (2) und der Fahrtzeit des Fahrzeugs (2) für eine Auswahl einer Fahrtzeit ausgegeben wird (S203), und wobei nach Auswahl einer akzeptablen Fahrtzeit (S204) von der fahrzeugspezifischen Modellvariante (6) Steuerparameter (SP) zum Betreiben des Fahrzeugs (2) ermittelt und dem Fahrzeug (2) vorgegeben werden (S205).

11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass ein Ermitteln des Zusammenhangs zwischen dem Energiebedarf (E) und/oder dem Fahrzeugverschleiß (DI) des Fahrzeugs (2) und der Fahrtzeit des Fahrzeugs (2) durch die fahrzeugspezifische Modellvariante (6) unter Berücksichtigung einer aktuellen Verkehrssituation auf der vorgegebenen Fahrtstrecke, aktueller Wetterbedingungen und weiterer externer Einflüsse in der Recheneinheit (5) durchgeführt wird (S202).

12. Verfahren nach einem der Ansprüche 10 bis 11, dadurch gekennzeichnet, dass eine Eingabe der Fahrtstrecke und eine Auswahl der Fahrtzeit im Fahrzeug (2) oder in einer zentralen Stelle erfolgt, welche einen Betrieb des Fahrzeugs (2) plant und überwacht.

13. Computerprogrammprodukt, wobei das Computerprogrammprodukt in eine Recheneinheit (5), insbesondere einen Cloud-Server (5) ladbar ist und/oder auf der Recheneinheit (5), insbesondere einem Cloud-Server, ausführbar ist, und wobei das Computerprogrammprodukt zumindest einen Softwarecode eines Fahrzeugmodells (1) zur Verwendung als digitaler Zwilling eines Fahrzeugs (2) umfasst, wobei das Fahrzeugmodell (1) nach einem der Ansprüche 1 bis 12 erstellt wurde.

Hierzu 5 Blatt Zeichnungen

18 / 25

Claims (1)

1. x bes AT 528 437 A1 2026-01-15

   Ss N

   Neue Patentansprüche

   1. Computerimplementiertes Verfahren zum Erstellen eines Fahrzeugmodells (1) zur Verwendung als digitaler Zwilling eines Fahrzeugs (2), wobei das erstellte und validierte Fahrzeugmodell zum Steuern und/oder Betreiben des Fahrzeugs angepasst ist und auf einer Rechnereinheit ausführbar ist, dadurch gekennzeichnet, dass zumindest folgende Schritte ausgeführt werden:

   - Erstellen eines physikalischen Modells für zumindest eine Fahrzeugkomponente (4) des Fahrzeugs (2) und Erstellen zumindest einer virtuellen Steuereinheit (9) für die zumindest eine Fahrzeugkomponente (4) (S101);

   - Erstellen des Fahrzeugmodells (1), wobei das physikalische Modell der zumindest einen Fahrzeugkomponente (4) und die zumindest eine virtuelle Steuereinheit (9) kombiniert werden (S 102);

   - Validieren des erstellten Fahrzeugmodells (1), wobei mit dem Fahrzeugmodell (1) Simulationsdaten generiert werden, bei welchen als Eingabedaten zumindest ein Fahrzeugparameter (FP) verwendet wird und der zumindest eine Fahrzeugparameter (FP) über einen vorgebbaren Eingabewertebereich variiert wird, wobei aus den mit dem Fahrzeugmodell (1) generierten Simulationsdaten jene Simulationsdaten ausgewählt werden, deren Eingabedaten mit Messbedingungen von gemessenen Testdaten übereinstimmen, und wobei die ausgewählten Simulationsdaten mit den gemessenen Testdaten verglichen und auf eine Abweichung geprüft werden (S103, S1031); und

   - Ableiten zumindest einer fahrzeugspezifischen Modellvariante (6) vom validierten Fahrzeugmodell), wobei die fahrzeugspezifische Modellvariante (6) zum Steuern und/oder Betreiben eines realen Fahrzeugs angepasst ist.

   2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das validierte Fahrzeugmodell (1) und zumindest die Simulationsdaten als Datenpool (7) auf einer Recheneinheit (5), insbesondere einem Cloud-Server (5), bereitgestellt werden (S105), und dass weiterhin die zumindest eine fahrzeugspezifische Modellvariante (6) auf der Recheneinheit bereitgestellt und ausgeführt wird (S104), wobei die zumindest eine fahrzeugspezifische Modellvariante (6) einem realen Fahrzeug (2) zugeordnet wird, welches von der zumindest einen fahrzeugspezifischen Modellvariante (6) gesteuert und/oder betrieben wird.

   3. Verfahren nach Anspruch 1 bis 2, dadurch gekennzeichnet, dass für die mit dem Fahrzeugmodell (1) generierten und ausgewählten Simulationsdaten die Abweichung von den entsprechenden, real gemessenen Testdaten ermittelt wird (S1031), und dass geprüft wird, ob für zumindest eine vorgegebene Anzahl oder einen vorgegebenen Prozentsatz der ausgewählten Simulationsdaten die ermittelte Abweichung unterhalb einer vorgegebenen Abweichung liegt (S1031).

   4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass das Fahrzeugmodell (1) angepasst wird (S1032), wenn für weniger als die vorgegebene Anzahl oder der vorgegebene Prozentsatz der ausgewählten Simulationsdaten eine Abweichung von den entsprechenden real gemessenen Testdaten kleiner als die vorgegebene Abweichung ermittelt wird, und dass das angepasste Fahrzeugmodell (1) erneut validiert wird (S1031), bis zumindest die vorgegebene Anzahl oder der vorgegebene Prozentsatz der ausgewählten Simulationsdaten eine Abweichung von den entsprechenden real gemessenen Testdaten unterhalb der vorgegebenen Abweichung aufweist.

   5. Verfahren nach einem der Ansprüche 3 oder 4, dadurch gekennzeichnet, dass für die vorgegebene Abweichung ein Prozentsatz von 5%, vorzugsweise von 1%, vorgegeben wird.

   6. Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass während eines Betriebs des zumindest einen realen Fahrzeugs (2) Fahrzeugparameter (FP) und Fahrzeugdaten auf der Recheneinheit (5) für eine Aktualisierung und Erweiterung des Datenpools (7) gesammelt und gespeichert werden (S104).

   24125

   ZULETZT VORGELEGTE ANSPRÜCHE

   10.

   11.

   12.

   AT 528 437 A1 2026-01-15

   Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das Fahrzeugmodell (1) mit dem aktualisierten und erweiterten Datenpool (7) neu parametriert und aktualisiert wird, wobei vom neu parametrierten und aktualisierten Fahrzeugmodell (1) zumindest eine aktualisierte fahrzeugspezifische Modellvariante (6) abgeleitet wird (S105).

   Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das neu parametrierte und aktualisierte Fahrzeugmodell (1) in vorgegebenen zeitlichen Intervallen erstellt wird (S105).

   Verfahren nach einem der Ansprüche 2 bis 8, dadurch gekennzeichnet, dass die zumindest eine fahrzeugspezifische Modellvariante (6) zum Betreiben des zugeordneten Fahrzeugs (2) verwendet wird, wobei der fahrzeugspezifischen Modellvariante (6) als zumindest ein Fahrzeugparameter (FP) eine Fahrtstrecke für das zugeordnete Fahrzeug (2) vorgegeben wird (S201), wobei von der fahrzeugspezifischen Modellvariante (6) anhand der vorgegebenen Fahrtstrecke ein Zusammenhang zwischen einem Energiebedarf (E) und/oder einem Fahrzeugverschleiß (DI) des Fahrzeugs (2) und einer Fahrtzeit des Fahrzeugs (2) für die vorgegebene Fahrtstrecke ermittelt wird (S202), wobei der Zusammenhang zwischen dem Energiebedarf (E) und/oder dem Fahrzeugverschleiß (DI) des Fahrzeugs (2) und der Fahrtzeit des Fahrzeugs (2) für eine Auswahl einer Fahrtzeit ausgegeben wird (S203), und wobei nach Auswahl einer akzeptablen Fahrtzeit (S204) von der fahrzeugspezifischen Modellvariante (6) Steuerparameter (SP) zum Betreiben des Fahrzeugs (2) ermittelt und dem Fahrzeug (2) vorgegeben werden (S205).

   Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass ein Ermitteln des Zusammenhangs zwischen dem Energiebedarf (E) und/oder dem Fahrzeugverschleiß (DI) des Fahrzeugs (2) und der Fahrtzeit des Fahrzeugs (2) durch die fahrzeugspezifische Modellvariante (6) unter Berücksichtigung einer aktuellen Verkehrssituation auf der vorgegebenen Fahrtstrecke, aktueller Wetterbedingungen und weiterer externer Einflüsse in der Recheneinheit (5) durchgeführt wird (S202).

   Verfahren nach einem der Ansprüche 9 bis 10, dadurch gekennzeichnet, dass eine Eingabe der Fahrtstrecke und eine Auswahl der Fahrtzeit im Fahrzeug (2) oder in einer zentralen Stelle erfolgt, welche einen Betrieb des Fahrzeugs (2) plant und überwacht.

   Computerprogrammprodukt, wobei das Computerprogrammprodukt in eine Recheneinheit (5), insbesondere einen Cloud-Server (5) ladbar ist und/oder auf der Recheneinheit (5), insbesondere einem Cloud-Server, ausführbar ist, und wobei das Computerprogrammprodukt zumindest einen Softwarecode eines Fahrzeugmodells (1) zur Verwendung als digitaler Zwilling eines Fahrzeugs (2) umfasst, wobei das Fahrzeugmodell (1) nach einem der Ansprüche 1 bis 11 erstellt wurde.

   ZULETZT VORGELEGTE ANSPRÜCHE