-
Die Erfindung betrifft ein Verfahren zur Bereitstellung, Aktivierung und/oder Verwendung mindestens einer Software-Anwendung in einem Fahrzeug.
-
Bei der Verwendung von Software-Anwendungen (auch Softwarekonfigurationen genannt) in einem Fahrzeug, beispielsweise in einem oder in mehreren Steuergeräten eines Fahrzeugs, sind auch technische Eigenschaften von Hardware-Komponenten des Fahrzeugs, insbesondere Art und Aufbau der Hardwarekomponenten, wie zum Beispiel Art einer Lichtanlage, Motortyp, Getriebeart, Batterietyp, etc. von Bedeutung. Die Dokumentation der technischen Eigenschaften der Hardware-Komponenten des Fahrzeugs entsteht in einem von der Entwicklung der Software-Anwendung mindestens teilweise abgetrennten Hardwareentwicklungsprozess und ist somit nicht direkt vom Softwareentwicklungsprozess nutzbar.
-
Der Erfindung liegt die Aufgabe zu Grunde, ein verbessertes Verfahren zur Bereitstellung, Aktivierung und/oder Verwendung mindestens einer Software-Anwendung in einem Fahrzeug anzugeben.
-
Die Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zur Bereitstellung, Aktivierung und/oder Verwendung mindestens einer Software-Anwendung in einem Fahrzeug mit den Merkmalen des Patentanspruchs 1.
-
Weiterbildungen der Erfindung sind Gegenstand der abhängigen Patentansprüche.
-
Das erfindungsgemäße Verfahren zur Bereitstellung, Aktivierung und/oder Verwendung mindestens einer Software-Anwendung in einem Fahrzeug, umfasst zumindest folgende Schritte:
- - Bereitstellung mindestens eines Fahrzeugdatensatzes und
- - Bereitstellung mindestens eines Kundendatensatzes,
wobei der Fahrzeugdatensatz und der Kundendatensatz derart miteinander verknüpft werden, dass eine aktuelle, neue und/oder zukünftige Software-Anwendung in Relation zu einer aktuellen, neuen und/oder zukünftigen Hardware-Komponente des Fahrzeugs generisch und vollautomatisch für einen Nutzer oder Kunden bereitgestellt, installiert und/oder aktiviert wird.
-
Die mit der Erfindung erzielten Vorteile bestehen insbesondere darin, dass die aktuelle, neue oder zukünftige Software-Anwendung, insbesondere ein Software-Merkmal und/oder eine Software-Funktion, auf Anfrage oder Abruf (features on demand) aufgrund der Verknüpfung des Fahrzeugdatensatzes und des Kundendatensatzes fahrzeugindividuell und kundenindividuell verarbeitet, bereitgestellt und angewendet werden können. Auch ermöglicht das Verfahren, dass eine aktuelle Software-Anwendung um mindestens ein Merkmal, eine Funktion und/oder eine Konfiguration aktualisiert und/oder erweitert fahrzeugbezogen oder kundenbezogen oder beides werden kann.
-
Dabei werden die Fähigkeiten und Möglichkeiten des jeweiligen Fahrzeugs berücksichtigt. Dies wird beispielsweise mit Hilfe eines sogenannten, zweischichtigen Digital-Twin-Konzeptes realisiert. Da sich die Konfiguration des Fahrzeugs, insbesondere die installierten Software-Anwendungen, zum Beispiel aufgrund einer Aktualisierung oder neuen Version einer installierten Software-Anwendung, und/oder die vorhandenen Hardware-Komponenten, beispielsweise aufgrund einer Reparatur, ändern kann, muss der Aspekt der zertifizierungsrelevanten Dokumentation der Änderungen ebenso berücksichtigt werden.
-
Wesentliche Merkmale dieser Erfindung sind:
- - Der Fahrzeugdatensatz, auch digitaler Twin des Fahrzeugs genannt, ist der „single point of truth“ für jegliche Fragestellungen zur aktuellen Systemkonfiguration des Fahrzeugs (auch physical Twin genannt) über den gesamten Lebenszyklus des Fahrzeugs hinweg.
- - Der Kundendatensatz, auch digitaler Twin des Kunden genannt, ist der „single point of truth“ für jegliche Fragestellungen zur aktuellen Einstellung der personalisierbaren Kundenparameter, wie Software-Anwendungen, durch den Kunden über den gesamten Lebenszyklus des Kundendatensatzes hinweg. Die Kundenparameter können beispielsweise von dem Kunden vorgegeben werden und sind im Kundendatensatz über den gesamten Lebenszyklus des Kundendatensatzes gespeichert.
- - Beide Datensätze oder digitale Twins - der Fahrzeugdatensatz und der Kundendatensatz - werden miteinander verknüpft, so dass kundenspezifisch gekaufte Software-Anwendungen, insbesondere digitale Merkmale und Funktionen, für ein konkretes Fahrzeug generisch und vollautomatisch verwaltet, installiert, dokumentiert und angewendet werden.
-
Ausführungsbeispiele der Erfindung werden im Folgenden anhand von Zeichnungen näher erläutert.
-
Dabei zeigen:
- 1 eine schematische Darstellung einer Verknüpfung eines Kundendatensatzes und eines Fahrzeugdatensatzes mit Mengen an Merkmalen („Sets“) und ihren jeweiligen Abbildungen und Verknüpfungen auf einer Hardware-Software-Relation und einer Kunden-Produkt-Relation,
- 2 einen schematischen und exemplarischen Ablauf, wie ein neues Software-Merkmal X einem Kunden angeboten wird,
- 3 einen schematischen und exemplarischen Ablauf, nachdem der Kunde das Software-Merkmal X gekauft hat,
- 4 einen schematischen und exemplarischen Ablauf des Software-Merkmals X im Kontext von einem Fahrzeug als Produkt aus dem vorherigen Beispiel,
- 5 einen schematischen und exemplarischen Ablauf, nachdem der Kunde ein Software-Merkmal Y gekauft hat, und
- 6 und 7 einen schematischen und exemplarischen Ablauf, nachdem der Kunde ein Software-Merkmal Z gekauft hat.
-
Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen.
-
1 zeigt eine schematische Darstellung einer Verknüpfung eines Kundendatensatzes 1 und eines Fahrzeugdatensatzes 2 in einem Datenkommunikationssystem 3 (dargestellt in 2).
-
Im gezeigten Ausführungsbeispiel wird als ein Produkt Pn ein vorgegebenes Fahrzeug beschrieben. Die Erfindung kann auch für andere Produkte, wie zum Beispiel ein Miettelefon, ein Mietcomputer, verwendet werden. Das Verfahren kann auch bei jeglichen variantenreichen und komplexen Massenprodukten eingesetzt werden, die kundenindividuelle Merkmale auf Anfrage oder Abruf (Features on Demand) unterstützen, wie beispielhaft bei Flugzeugen, Lastkraftwagen, Bussen, Landmaschinen, Schiffen, Zügen, Drohnen, Robotern, Zweirädern, autonomen Fahrzeugen, Maschinen und Anlagen sowohl in der Konsumgüterindustrie als auch in der Informations- und Kommunikationstechnologie (ITK-Industrie genannt).
-
Die Verknüpfung des Kundendatensatzes 1 und des Fahrzeugdatensatzes 2 erfolgt zum Beispiel mittels einer Verknüpfung von hinterlegten Unterdatensätzen kundenbezogen und/oder fahrzeugbezogen. Die Unterdatensätze werden nachfolgend als Mengen oder Teilmengen bezeichnet, welche verfügbare, installierte und/oder aktivierte Software-Anwendung 4 und/oder Hardware-Komponente 5, insbesondere Hardware-Komponenten, mit welchen das Produkt P ausgestattet ist, umfassen.
-
Der Kundensatz 1 umfasst beispielsweise zumindest:
- - eine erste Menge Set_A' von verfügbaren Software-Anwendungen 4, insbesondere Software-Merkmalen und/oder Software-Funktionen, für alle Kunden CC und
- - eine zweite Menge Set_F von für einen Kunden Cn aktivierte Software-Anwendungen 4, insbesondere Software-Merkmalen und/oder Software-Funktionen, für alle Produkte PP, insbesondere für jegliche Produktreihe oder jegliche Produktinstanz.
-
Der Fahrzeugdatensatz 2 umfasst zumindest:
- - eine dritte Menge Set_A von verfügbaren Software-Anwendungen 4, insbesondere Softwaremerkmalen und/oder Software-Funktionen, für alle Produkte PP,
- - eine vierte Menge Set_B von vorhandenen Hardware-Komponenten 5, insbesondere Ausstattungsmerkmale, für ein vorgegebenes, insbesondere ein konkretes, Produkt, insbesondere eine aktuelle Produktinstanz Pn, welche mit diesen Hardware-Komponenten 5 aktuell ausgestattet ist,
- - eine fünfte Menge Set_C von verfügbaren Software-Anwendungen 4, insbesondere Softwaremerkmalen und/oder Software-Funktionen, welche abhängig von der vierten Menge Set_B von vorhandenen Hardware-Komponenten 5 gemäß eines ersten Pfeils P1 für die aktuelle Produktinstanz Pn verfügbar ist,
- - eine sechste Menge Set_D von installierten Software-Anwendungen 4, insbesondere Softwaremerkmalen und/oder Software-Funktionen, welche für die aktuelle Produktinstanz Pn installiert, zum Beispiel vorinstalliert sind oder als Standartausstattung für jedes Produkt Pn dieser Produktinstanz Pn vorgesehen ist, und
- - eine siebte Menge Set_E von aktivierten Software-Anwendungen 4, welche für die aktuelle Produktinstanz Pn unabhängig vom konkreten Kunden Cn aktiviert ist.
-
Die Verknüpfung kann als eine Hardware-Software-Relation 6 beispielsweise gemäß des ersten Pfeils P1 und einer Kunden-Produkt-Relation 7 gemäß eines zweiten Pfeils P2 ausgeführt werden. Die Hardware-Software-Relation 6 umfasst dabei zum einen die Hardware-Komponenten 5 und die Software-Anwendungen 4. Die Kunden-Produkt-Relation 7 umfasst zum Beispiel den Kundendatensatz 1 mit personalisierten Kundenparametern, insbesondere personalisierte, insbesondere auf einen Kunden Cn abgestimmte oder diesem Kunden Cn zugeordnete Software-Anwendungen 4, insbesondere Software-Merkmalen und/oder Software-Funktionen, in Form der zuvor beschriebenen Mengen Set_A' und Set_F, und den Fahrzeugdatensatz 2 für ein konkretes Produkt, zum Beispiel ein Fahrzeug, unabhängig von der Produktinstanz Pn in Form der zuvor beschriebenen Mengen Set_A bis Set_E.
-
Die 1 zeigt, dass ausgehend von der Summe aller Software-Anwendungen 4 für alle Kunden CC, die für alle Produkte PP verfügbar sind, welche durch die Verknüpfung der ersten Menge Set_A' und der dritten Menge Set_A gebildet wird, es eine Teilmenge, insbesondere die fünfte Menge Set_C bezogen auf eine konkrete Produktinstanz Pn gibt, welche die Software-Anwendungen 4, insbesondere Softwaremerkmale und/oder - funktionen, beinhaltet, die mit den Hardware-Komponenten 5 des vorgegebenen Produkts, definiert als vierte Menge Set_B überhaupt möglich sind, wie anhand des ersten Pfeils P1 gezeigt.
-
Die sechste Menge Set_D ist von der fünften Menge Set_C wiederum eine Teilmenge, welche alle bereits installierten Software-Anwendungen 4 für die konkrete Produktinstanz Pn beinhaltet. Die siebte Menge Set_E ist schließlich die Menge an Software-Anwendungen 4, die tatsächlich für das betreffende Produkt der konkreten Produktinstanz Pn aktiviert sind.
-
Der obere Abschnitt beschreibt den Kundendatensatz 1 und damit die erste Menge Set_A' von Software-Anwendungen 4, die aus Kundensicht alle verfügbar sind. Eine Teilmenge davon ist die zweite Menge Set_F, welche die Menge aller Softwarefunktionen beinhaltet, die für einen konkreten Kunden Cn für jegliche Produktreihe oder jegliche oder eine konkrete Produktinstanz Pn aktiviert sind. Die zweite Menge Set_F kann beispielsweise eine Anwendungssoftware (app) eines Dienstleisters, wie zum Beispiel die Spotify-App, sein, die der Kunde unabhängig vom Produkt, dem Fahrzeug F1, gekauft hat. Wenn der Kunde das Fahrzeug F1 wechselt, dann wird oder ist diese Anwendungssoftware automatisch auch in dem „neuen“ Fahrzeug, zum Beispiel einem Mietwagen, freigeschaltet.
-
2 zeigt das Datenkommunikationssystem 3 mit einem Backend-System 8, einem vorgegebenen Fahrzeug F1 und einem Kunden-Frontend 9.
-
Das Backend-System 8 umfasst zumindest einen Typenkonfigurationsdienst 10, einen Produktübersichtsinformationsdienst 11, einen Fahrzeugdatensatzverwaltungsdienst 12 (auch Digital Twin Management Service genannt) für den Fahrzeugdatensatz 2 des vorgegebenen Fahrzeuges F1, einen Kundendatensatzverwaltungsdienst 13 für den Kundendatensatz 1 des Kunden Cn, eine Software-Anwendungsverwaltung 14 (auch Feature Management genannt), einen allgemeinen Konfigurationsdienst 15, einen Aktualisierungsdienst 16 und einen Software-Anwendungs-Anbietungsdienst 17 (auch Feature Store Backend genannt) zum Beispiel zum Anbieten einer neuen Software-Anwendung 4 oder eines Updates für eine im Fahrzeug F1 bereits installierte Software-Anwendung 4 an den Kunden Cn sowie ein Fahrzeugdokumentationsdienst 18 und einen Software-Anwendungs-Einlagerungsdienst 24 (auch Software Features Repository Service genannt) zur Bereitstellung, Speicherung, Verwaltung und Aktivierung der Software-Anwendungen 4, insbesondere zur Bereitstellung und/oder Aktivierung und/oder Verwendung von neuen und/oder zu aktualisierenden Software-Merkmalen X.
-
Das Fahrzeug F1 kann darüber hinaus als ein Assistenzsystem oder Steuergerät zum Beispiel einen lokalen allgemeinen Konfigurationsdienst 19 (auch local generic configuration management unit genannt) und einen lokalen Aktualisierungsdienst 20 (auch local update management unit genannt) sowie einen Digitalen Identifizierungsdienst 21 (auch digital identity genannt) mit einem Speicher 22 (auch kurz electronic wallet oder EW genannt) und einer Fahrzeugidentität 23 (auch Vehicle-DID (VDID) genannt) umfassen.
-
Des Weiteren zeigt die 2 einen exemplarischen Ablauf, wie als neue Software-Anwendung 4 ein neues Software-Merkmal X einem Kunden Cn angeboten wird.
-
Das neue Software-Merkmal X wird im Schritt S1 freigegeben und dem Kunden Cn angeboten. Dabei wird im Schritt S2 das Software-Merkmal X hinsichtlich seiner zertifizierungsrelevanten Dokumentationsvorgaben geprüft und über den gesamten Lebenszyklus des Fahrzeugs F1 gepflegt und verwaltet. Beispielsweise ist hierzu ein Typenkonfigurationsservice 10 vorgesehen, der beispielsweise die in der parallelen Patentanmeldung „Verfahren zur Verwaltung von Konfigurationen und Einhaltung zertifizierungsrelevanter Dokumentationsvorgaben über den gesamten Lebenszyklus von Fahrzeugen mit Hilfe eines digital Twins“ (ID: 2021ID02294, unveröffentlicht, auf die hier in vollem Umfang Bezug genommen wird) beschriebenen Mechanismen zur Verwaltung von kompletten Typkonfigurationen, angewendet.
-
Sollten sich aufgrund des neuen Software-Merkmals X neue, zertifizierungsrelevante vollständige Typkonfigurationen ergeben, so werden sie in diesem Schritt S2 angelegt und entsprechend wird die Dokumentationsgrundlage geschaffen, dass dieses neue Software-Merkmal X dann später auch tatsächlich in dem realen Fahrzeug F1 des Kunden Cn installiert werden darf.
-
Im nächsten Schritt S3 wird die Software-Anwendungsverwaltung 14 („Feature Management“) über das neue Software-Merkmal X informiert.
-
Daraufhin werden im Schritt S4 der konkrete Fahrzeugdatensatz 2, auch digital Twins genannt, des Fahrzeugs F1 und somit für das aktuelle Produkt der konkreten Produktinstanz Pn die fünfte Menge Set_C von verfügbaren Software-Anwendungen 4 aktualisiert. Sind die jeweiligen Voraussetzungen in dem jeweiligen Fahrzeug F1 (= Kundenfahrzeugen) erfüllt, so kann das neue Software-Merkmal X in die jeweilige Menge Set_C bis Set_F der möglichen Software-Anwendungen 4 aufgenommen werden.
-
Ist dies für das im Beispiel beschriebene Fahrzeug F1 ausgeführt worden, so kann der Kunde Cn im Schritt S5 bis S10 schließlich das Software-Merkmal X im Software-Anwendungs-Anbietungsdienst 17, zum Beispiel einem Online-Store oder Feature-Store, sehen.
-
3 zeigt einen exemplarischen Ablauf, nachdem der Kunde das Software-Merkmal X im Schritt S11 gekauft hat.
-
Die 3 zeigt, wie nach dem Kaufvorgang im Schritt S11 das Software-Merkmal X im Fahrzeug F1 aktiviert wird.
-
Im Schritt S12 wird der Kaufvorgang über den Software-Anwendungs-Anbietungsdienst 17 vollzogen.
-
Anschließend informiert der Software-Anwendungs-Anbietungsdienst 17 verschiedene Dienste des Backend-Systems 8 über den Kauf des Software-Merkmals X. Beispielsweise sendet der Software-Anwendungs-Anbietungsdienst 17 eine Information über den Kauf des Software-Merkmals X an den Kundendatensatzverwaltungsdienst 13 und den Fahrzeugdatensatzverwaltungsdienst 12 sowie über diesen an die Software-Anwendungsverwaltung 14. Mittels der Information über den Kauf des Software-Merkmals X werden dann die betreffenden Mengen Set_C bis Set_F aktualisiert. Alternativ können nur die Mengen Set D, E und F aktualisiert werden, wobei die anderen Mengen Set C und Set A, A' durch den Kauf unverändert bleiben.
-
Im Schritt S14 werden aus dem Software-Anwendungs-Einlagerungsdienst 24 die spezifischen Details des gekauften Software-Merkmals X abgefragt, um das Software-Merkmal X orchestrieren zu können. In diesem Beispiel muss für das Software-Merkmal X lediglich ein Software-Update durchgeführt werden.
-
Im Schritt S15 werden die Vorgaben mittels des Produktübersichtsinformationsdienstes 11, insbesondere eine Baubarkeitsdokumentation (Produktübersicht) des Software-Merkmals X abgefragt und der Software-Anwendungsverwaltung 14 zur Verfügung gestellt.
-
Im Schritt S16 wird die komplette Typkonfiguration für die Zielkonfiguration des Software-Merkmals X, zum Beispiel Software-Merkmal X im Fahrzeug F1 aktiviert, abgefragt.
-
Wenn diese Schritte erfolgreich abgeschlossen sind, so kann der Aktualisierungsdienst 16 mit der Ausgabe (auch rollout) der Software-Anwendung 4 (auch Paket genannt) für das Software-Merkmal X auf das Fahrzeug F1 im Schritt S17 beginnen. Insbesondere wird das zu aktualisierende Software-Merkmal X an den lokalen Aktualisierungsdienst 20 des Fahrzeugs F1 übertragen.
-
In manchen Realisierungen dieses Konzeptes kann es sich als vorteilhaft erweisen, wenn zur Absicherung der tatsächlichen Durchführung dieser Konfigurationsänderung das Fahrzeug F1 über eine digitale Identität (kurz VDID genannt) verfügt, welches optimalerweise eine hardwarebasierte Cryptofunktion nutzen kann (electronic wallet), womit der neue Zustand mit nach der W3C Recommendation Verifiable Credentials Data Model 1.0 erstellten Credentials „confirmedConfiguration“ dokumentiert und im Schritt S18 mittels des Identifizierungsdienstes 21 signiert wird.
-
Nach Rückmeldung über eine erfolgreiche Aktualisierung des Software-Merkmals X im Fahrzeug F1 im Schritt S19 vom Fahrzeug F1 an den Aktualisierungsdienst 16 wird der Fahrzeugdatensatz 2 (digital Twin von Fahrzeug F1) im Schritt S20 mit dem neuen Zustand der Konfiguration aktualisiert, indem dieser neue Zustand und damit die erfolgreiche lokale allgemeine Konfiguration des Software-Merkmals Y im Fahrzeug F1 im Fahrzeugdatensatz 2 des Fahrzeugdatensatzverwaltungsdienstes hinterlegt wird.
-
In manchen Umsetzungen dieses Konzeptes kann es sich als vorteilhaft erweisen, wenn dieser Zustand durch die digitale Identität 26 (gespeichert zum Beispiel in einer electronic wallet) des Backend-Systems 8 (auch OEM-Backend genannt), die im Fahrzeugdatensatzverwaltungsdienst 12 hinterlegt ist, mittels eines Signierdienstes 25 im Schritt S21 signiert und im Schritt S22 einem Verteiler 27, insbesondere einem übergeordneten, verteilten Datennetz, z.B. durch den Einsatz von Distributed Ledger Technologie, zugeführt und dort gegebenenfalls gespeichert oder weiterverarbeitet wird.
-
4 zeigt einen Weg vom Software-Merkmal X im Kontext von Fahrzeug F1 aus dem vorherigen Beispiel.
-
Die 4 zeigt, mit welchen Schritten S23 bis S24 das zu aktualisierende Software-Merkmal X in Bezug auf das Fahrzeug F1 sich durch die jeweiligen Mengen Set_A, Set_C hin zur siebten Menge Set_E bewegt, bis es schließlich nach Installation und Aktivierung in der siebten Menge Set_E der aktivierten Software-Anwendung 4 für die Produktinstanz Pn - das Fahrzeug F1 - gespeichert ist.
-
5 zeigt einen exemplarischen Ablauf, nachdem der Kunde Cn ein anderes Software-Merkmal Y einer Software-Anwendung 4 gekauft hat.
-
Die 5 zeigt, wie der Prozess für das andere Software-Merkmal Y abläuft, wenn nach dem Kaufvorgang im Schritt S11 dieses Software-Merkmal Y im Fahrzeug F1 aktiviert wird. Die Software-Anwendungsverwaltung 14 wird im Schritt S13 in analoger Weise, wie in 3 beschrieben, über den Kaufvorgang informiert.
-
Im Schritt S14 werden analog aus dem Software-Anwendungs-Einlagerungsdienst 24 die featurespezifischen Details des Software-Merkmals Y abgefragt, um das Software-Merkmal Y orchestrieren zu können. In diesem Beispiel muss für das Software-Merkmal Y lediglich eine allgemeine Konfiguration („generic configuration“) durchgeführt werden.
-
Im Schritt S15 werden die Vorgaben seitens der Baubarkeitsdokumentation (Produktübersicht) und im Schritt S16 die komplette Typkonfiguration für die Zielkonfiguration (Software-Merkmal Y im Fahrzeug F1 aktiviert) abgefragt, analog wie zu 3 beschrieben. Wenn diese Schritte S15 und S16 erfolgreich abgeschlossen sind, so kann der allgemeine Konfigurationsdienst 15 (Generic Configuration Service) mit der Konfiguration für das Software-Merkmal Y auf das Fahrzeug F1 in einem abgeänderten Schritt S17 beginnen, indem das Software-Merkmal Y dem lokalen allgemeinen Konfigurationsdienst 19 des Fahrzeugs F1 zugeführt wird. Dieser lokale allgemeine Konfigurationsdienst 19 meldet dann die erfolgreiche Konfiguration des Software-Merkmals Y im Fahrzeug F1 an die Software-Anwendungsverwaltung 14 im Schritt S19 zurück.
-
In manchen Realisierungen dieses Konzeptes kann es sich als vorteilhaft erweisen, wenn zur Absicherung der tatsächlichen Durchführung dieser Konfigurationsänderung das Fahrzeug F1 über eine digitale Identität (VDID) verfügt, welches optimalerweise eine hardwarebasierte Cryptofunktion nutzen kann (electronic wallet), womit der neue Zustand mit nach der W3C Recommendation Verifiable Credentials Data Model 1.0 erstellten Credentials „confirmedGenericConfiguration“ dokumentiert und im Schritt S18 mittels des Fahrzeugsignierdienstes 21 signiert wird. Nach Rückmeldung im Schritt S19 wird der digital Twin von Fahrzeug F1 im Schritt S20 mit dem neuen Zustand der Konfiguration aktualisiert, indem dieser neue Zustand und damit die erfolgreiche lokale allgemeine Konfiguration des Software-Merkmals Y im Fahrzeug F1 im Fahrzeugdatensatz 2 des Fahrzeugdatensatzverwaltungsdienstes hinterlegt wird.
-
In manchen Umsetzungen dieses Konzeptes kann es sich als vorteilhaft erweisen, wenn dieser Zustand durch die digitale Identität 26 (electronic wallet) des OEM-Backendservices mittels des Signierdienstes 25 des Backend-Systems 8 signiert wird, wie anhand des Schritts S21 gezeigt. Im Schritt S22 kann dann dem Verteiler 27, insbesondere einem übergeordneten, verteilten Datennetz, z. B. durch den Einsatz von Distributed Ledger Technologie, der aktuelle Zustand der Konfiguration des Software-Merkmals Y zugeführt, insbesondere gesendet oder in diese geschrieben, werden.
-
6 und 7 zeigen einen exemplarischen Ablauf, nachdem der Kunde ein Software-Merkmal Z gekauft hat.
-
Die 6 zeigt, wie der Prozess für das andere Software-Merkmal Z abläuft, wenn nach dem Kaufvorgang im Schritt S11 dieses Software-Merkmal Z im Fahrzeug F1 aktiviert wird.
-
Die Software-Anwendungsverwaltung 14 wird im Schritt S13 über den Kaufvorgang informiert. Im Schritt S14 werden aus dem Software-Anwendungs-Einlagerungsdienst 24 die featurespezifischen Details des Software-Merkmals Z abgefragt, um das Software-Merkmal Z orchestrieren zu können.
-
In diesem Beispiel muss für das Software-Merkmal Z zuerst eine Aktualisierung, insbesondere ein sogenanntes Software Update, durchgeführt werden und anschließend eine allgemeine Konfiguration („generic configuration“) durchgeführt werden, um es schließlich zu aktivieren.
-
Im Schritt S15 werden die Vorgaben seitens der Baubarkeitsdokumentation (Produktübersicht) und im Schritt S16 die komplette Typkonfiguration für die Zielkonfiguration (Software-Merkmal Z im Fahrzeug F1 aktiviert) abgefragt, analog wie zu 3 oder 5 beschrieben. Wenn diese Schritte S15 und S16 erfolgreich abgeschlossen sind, so kann der Aktualisierungsdienst 16 mit dem Bereitstellen (Rollout) der Software-Anwendung 4 für das Software-Merkmal Z auf das Fahrzeug F1 im Schritt S17 beginnen.
-
In manchen Realisierungen dieses Konzeptes kann es sich als vorteilhaft erweisen, wenn zur Absicherung der tatsächlichen Durchführung dieser Konfigurationsänderung das Fahrzeug F1 über eine digitale Identität 26 (VDID) verfügt, welches optimalerweise eine hardwarebasierte Cryptofunktion nutzen kann (electronic wallet), womit der neue Zustand mit nach der W3C Recommendation Verifiable Credentials Data Model 1.0 erstellten Credentials „confirmedConfiguration“ dokumentiert und im Schritt S18 mittels des Fahrzeugsignierdienstes 21 signiert wird. Die Rückmeldung über die erfolgreiche lokale Installation erfolgt im Schritt S19.
-
7 zeigt den exemplarischen Ablauf, nachdem der Kunde Cn das Software-Merkmal Z gekauft hat.
-
Die 7 zeigt den zweiten Teil (die Aktivierung) des Ablaufs für die Aktualisierung des Software-Merkmals Z. Nachdem die Aktualisierung oder das Update durchgeführt wurde, wird im Schritt S21 und S22 das Software-Merkmal Z durch den allgemeinen Konfigurationsdienst 15 an den lokalen allgemeinen Konfigurationsdienst 19 übertragen und dort aktiviert.
-
In manchen Realisierungen dieses Konzeptes kann es sich als vorteilhaft erweisen, wenn zur Absicherung der tatsächlichen Durchführung dieser Konfigurationsänderung das Fahrzeug F1 über eine digitale Identität (VDID) verfügt, welches optimalerweise eine hardwarebasierte Cryptofunktion nutzen kann (electronic wallet), womit der neue Zustand mit nach der W3C Recommendation Verifiable Credentials Data Model 1.0 erstellten Credentials „confirmedGenericConfiguration“ dokumentiert und im Schritt S23 mittels des Fahrzeugsignierdienstes 21 signiert wird.
-
Nach Rückmeldung über eine erfolgreiche Aktualisierung des Software-Merkmals Z im Fahrzeug F1 im Schritt S24 vom Fahrzeug F1 an den lokalen allgemeinen Konfigurationsdienst 19 wird der Fahrzeugdatensatz 2 (digital Twin von Fahrzeug F1) im Schritt S25 mit dem neuen Zustand der Konfiguration des Software-Merkmals Z aktualisiert.
-
In manchen Umsetzungen dieses Konzeptes kann es sich als vorteilhaft erweisen, wenn dieser Zustand durch eine digitale Identität 26 des Backend-Systems 8 (auch OEM-Backend genannt), die im Fahrzeugdatensatzverwaltungsdienst 12 hinterlegt ist, mittels des Signierdienstes 25 im Schritt S26 signiert und im Schritt S27 einem Verteiler 27, insbesondere einem übergeordneten, verteilten Datennetz, z.B. durch den Einsatz von Distributed Ledger Technologie, zugeführt und dort gegebenenfalls gespeichert oder weiterverarbeitet wird.
-
In einer weiteren Ausbaustufe des Konzeptes könnte diese Erfindung die Interpretation des „Kunden“ differenzierter betrachten, wie zum Beispiel nach den Rollen:
- • Besitzer
- • Leasingnehmer
- • Fahrer
- • Passagier
-
Rollenspezifische Kundenmerkmale, insbesondere die zuvor beschriebenen Software-Merkmale X, Y und/oder Z, können zum Beispiel unterschiedliche Software-Anwendungen 4 sein, wenn der Besitzer oder Kunde Cn des Fahrzeugs F1 eine Mietwagenfirma ist und diese bestimme Serviceanwendungen direkt in ihren Fahrzeugen F1 anbieten wollen. Ein Stammkunde dieser Mietwagenfirma könnte gegebenenfalls seine Standardmerkmale „mitbringen“, die er bei der Mietwagenfirma abonniert hat und die automatisch in das neue Fahrzeug F1, das er für die aktuelle Miete übernimmt, installiert und aktiviert werden.
-
In einer weiteren Ausbaustufe des Konzeptes könnte die zuvor beschriebene Erfindung mit dem Konzept: „A holistic system for an immersive user experience in a vehicle based on individual and situation based user experience features“ (offenbart in der
DE 10 2021 000 243 A1 , auf die hier in vollem Umfang Bezug genommen wird) kombiniert werden. In diesem Konzept werden dynamische „User Experience Spaces“ beschrieben, die sich hardwareseitig und softwareseitig situativ umkonfigurieren lassen. Gemeinsam mit dem in diesem Dokument beschriebenen Featuremanagement-Konzeptes können sowohl kundenindividuelle, als auch fahrzeugspezifische und situativ-dynamische Kundenerlebnisszenarien vollautomatisch realisiert, verwaltet und orchestriert werden.
-
Diese Erfindungsmeldung ist beispielhaft auf den Anwendungsfall von Kraftfahrzeugen für die Automobilindustrie ausgelegt. Das Verfahren kann jedoch bei jeglichen variantenreichen und komplexen Produkten Pn, insbesondere Massenprodukten, eingesetzt werden, die kundenindividuelle Features on Demand unterstützen, wie beispielhaft bei Flugzeugen, Lastkraftwagen, Bussen, Landmaschinen, Schiffen, Zügen, Drohnen, Robotern, Zweirädern, autonomen Fahrzeugen, Maschinen und Anlagen sowohl in der Konsumgüter- und in der ITK-Industrie.
-
Diese Erfindung ermöglicht es, dass sich Kunden Cn digitale Features oder Software-Anwendungen 4 kaufen und sich diese nahtlos über ein doppeltes digital-Twin-Konzept in die Verwaltung von Fahrzeugkonfigurationen, den Hardware-Komponenten 5, einbinden lassen, wobei die Vorgaben bezüglich zertifizierungsrelevanter Dokumentationsvorgaben durchgehend eingehalten werden. Ebenso können sowohl mehrere Kundendatensätze 1 als auch mehrere Fahrzeuge F über deren jeweiligen Fahrzeugdatensätze 2, den digitalen Twins, verknüpft und die jeweiligen Software-Merkmale X, Y und/oder Z, installiert und aktiviert werden.
-
Bezugszeichenliste
-
- 1
- Kundendatensatz
- 2
- Fahrzeugdatensatz
- 3
- Datenkommunikationssystem
- 4
- Software-Anwendung
- 5
- Hardware-Komponente
- 6
- Hardware-Software-Relation
- 7
- Kunden-Produkt-Relation
- 8
- Backend-System
- 9
- Kunden-Frontend-System
- 10
- Typenkonfigurationsdienst
- 11
- Produktübersichtsinformationsdienst
- 12
- Fahrzeugdatensatzverwaltungsdienst
- 13
- Kundendatensatzverwaltungsdienst
- 14
- Software-Anwendungsverwaltung
- 15
- allgemeiner Konfigurationsdienst
- 16
- Aktualisierungsdienst
- 17
- Software-Anwendungs-Anbietungsdienst
- 18
- Fahrzeugdokumentationsdienst
- 19
- lokaler allgemeiner Konfigurationsdienst
- 20
- lokaler Aktualisierungsdienst
- 21
- Fahrzeugsignierdienst
- 22
- Speicher
- 23
- Fahrzeugidentität
- 24
- Software-Anwendungs-Einlagerungsdienst
- 25
- Signierdienst
- 26
- digitale Identität
- 27
- Verteiler
- Cn
- Kunde
- CC
- alle Kunden
- F1
- Fahrzeug
- Pn
- Produktinstanz, aktuelle Produktinstanz
- PP
- alle ProdukteP1 erster Pfeil
- P2
- zweiter Pfeil
- Set_A'
- erste Menge von verfügbaren Software-Anwendungen
- Set_A
- dritte Menge von verfügbaren Software-Anwendungen
- Set_B
- vierte Menge von vorhandenen Hardware-Komponenten
- Set_C
- fünfte Menge von verfügbaren Software-Anwendungen
- Set_D
- sechste Menge von installierten Software-Anwendungen
- Set_E
- siebte Menge von aktivierten Software-Anwendungen
- Set_F
- zweite Menge von aktivierten Software-Anwendungen
- S1 bis S27
- Schritte (Verfahrensschritte)
- X, Y, Z
- Software-Merkmal
-
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 102021000243 A1 [0063]
