DE102021000243A1 - Ganzheitliches Fahrzeugsystem - Google Patents

Abstract

Die Erfindung betrifft ein ganzheitliches Fahrzeugsystem (1) für mindestens ein Fahrzeug (2, 20) zur Konfiguration, Testung und/oder Steuerung mindestens eines Merkmals (M) und/oder mindestens einer Funktion (F) des Fahrzeugs (2, 20). Das ganzheitliche Fahrzeugsystem (1) umfasst mindestens eine Eingabeeinheit (3) zur Vorgabe von Interaktionsdaten (ID) durch einen Benutzer (C1 bis C3) und/oder ein externes Gerät, und/oder mindestens einen Sensor (4) zur Erfassung von Sensordaten (SD), wobei mittels der Interaktionsdaten (ID) und/oder der Sensordaten (SD) das Merkmal (M), insbesondere software-basierte und/oder hardware-basierte Merkmale, und/oder die Funktion (F), insbesondere software-basierte Funktionen, dynamisch individuell bzw. situationsbasiert generierbar, konfigurierbar und/oder anpassbar sind bzw. ist.

Description

• Die Erfindung betrifft ein ganzheitliches Fahrzeugsystem für mindestens ein Fahrzeug zur Konfiguration und/oder Steuerung von zumindest einem Parameter und/oder Merkmal eines Fahrzeugs und/oder einer Fahrt des Fahrzeugs, wobei das ganzheitliche Fahrzeugsystem mindestens eine Eingabeeinheit zur Eingabe von Interaktionsdaten durch einen Benutzer und/oder ein externes Gerät, und/oder mindestens einen Sensor zur Erfassung von Sensordaten umfasst.
• Für die Herstellung von Fahrzeugen sind Kundenindividualisierungen bekannt. Beispielsweise können Benutzer in einem sogenannten Online-Konfigurator das Fahrzeug konfigurieren, bevor eine Bestellung für das zu produzierende Fahrzeug aufgegeben wird. Dabei sind mittels des Online-Konfigurators strukturelle oder Hardware-Merkmale des Fahrzeugs konfigurierbar.
• Der Erfindung liegt die Aufgabe zu Grunde, ein Fahrzeugsystem für ein Fahrzeug anzugeben, welches eine verbesserte Kundenindividualisierung des Fahrzeugs ermöglicht.
• Die Aufgabe wird erfindungsgemäß durch die Merkmale des Patentanspruchs 1 gelöst.
• Weiterbildungen der Erfindung sind Gegenstand der abhängigen Patentansprüche.
• Erfindungsgemäß ist ein ganzheitliches Fahrzeugsystem für mindestens ein Fahrzeug zur Konfiguration, Testung und/oder Steuerung mindestens eines Merkmals und/oder einer Funktion des Fahrzeugs vorgesehen, wobei das ganzheitliche Fahrzeugsystem mindestens eine Eingabeeinheit zur Vorgabe von Interaktionsdaten durch einen Benutzer und/oder ein externes Gerät und/oder mindestens einen Sensor zur Erfassung von Sensordaten umfasst, und wobei mittels der Interaktionsdaten und/oder der Sensordaten das Merkmal und/oder die Funktion, insbesondere ein softwarebasiertes und/oder hardware-basierte Merkmal bzw. eine softwarebasierte Funktion, dynamisch individuell bzw. situationsbasiert generierbar, konfigurierbar und/oder anpassbar sind bzw. ist. Mit dem Aufkommen von immer mehr softwarebasierten Fahrzeugfunktionen und/oder Fahrzeugmerkmalen (auch softwarezentrierten Funktionen bzw. Merkmale genannt) besteht der Wunsch eines Benutzers oder eines Kunden, diese softwarebasierten Funktionen und/oder Merkmale zusätzlich zu hardwarebasierten Merkmalen vorab zu konfigurieren, einzustellen oder vorzugeben. Das ganzheitliche Fahrzeugsystem, insbesondere ausgebildet als ein ganzheitliches Fahrzeugkonfigurationssystem, ermöglicht neben der herkömmlichen hardwarebasierten Individualisierung eines Fahrzeugs auch eine softwarebasierte Individualisierung des Fahrzeugs.
• Eine Weiterbildung sieht vor, dass anhand des dynamisch individuell und/oder situationsbasiert anpassbaren Merkmals und/oder der Funktion mindestens ein Szenario, wie ein Nutzungsszenario, des Fahrzeugs und/oder mindestens einer Fahrzeugkomponente, wie zum Beispiel eines Assistenzsystems, eines Multimediasystems, und/oder einer Fahrzeugfunktion, wie zum Beispiel einer Automatisierungsfunktion, einer Kommunikationsfunktion, konfigurierbar und/oder steuerbar ist.
• Darüber hinaus kann eine Kommunikationsschnittstelle vorgesehen sein, mittels der das mindestens eine Szenario des einen Fahrzeugs und/oder der mindestens einen Fahrzeugkomponente und/oder der mindestens einen Fahrzeugfunktion des einen Fahrzeugs zumindest indirekt, zum Beispiel über ein Backend-System eines Fahrzeugherstellers oder Fahrzeuganbieters, wie zum Beispiel einer Mietwagenfirma, auf ein anderes Fahrzeug übertragbar ist.
• Ausführungsbeispiele der Erfindung werden im Folgenden anhand einer Zeichnung näher erläutert.
• Dabei zeigen:
• 1 in schematischer Blockdarstellung eine Ausführungsform eines ganzheitlichen Fahrzeugsystems für ein Fahrzeug zur Konfiguration, Testung und/oder Steuerung eines Merkmals und/oder einer Funktion des Fahrzeugs, und
• 2 bis 20 jeweils in schematischer Blockdarstellung bzw. als ein Funktionsablaufplan ein Ausführungsbeispiel für eine Konfiguration eines Fahrzeugs mittels des ganzheitlichen Fahrzeugsystems
• Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen.
• 1 zeigt in schematischer Blockdarstellung eine Ausführungsform eines ganzheitlichen Fahrzeugsystems 1 für ein Fahrzeug 2 zur Konfiguration, Testung und/oder Steuerung mindestens eines Merkmals M und/oder mindestens einer Funktion F des Fahrzeugs 2.
• Das ganzheitliche Fahrzeugsystem 1 umfasst mindestens eine Eingabeeinheit 3 zur Vorgabe von Interaktionsdaten ID, insbesondere zum Vorgeben von Triggerpunkten und/oder Triggerbereichen, durch einen Benutzer und/oder ein externes Gerät 8, und/oder mindestens einen Sensor 4 zur Erfassung von Sensordaten SD.
• Das ganzheitliche Fahrzeugsystem 1 ist eingerichtet, dass mittels der vorgegebenen Interaktionsdaten ID und/oder der erfassten Sensordaten SD das mindestens eine Merkmal M, insbesondere ein software-basiertes und/oder hardware-basierte Merkmal, und/oder die mindestens eine Funktion F, insbesondere eine software-basierte Funktion, dynamisch individuell bzw. situationsbasiert generierbar, konfigurierbar und/oder anpassbar sind bzw. ist.
• Das ganzheitliche Fahrzeugsystem 1 ist insbesondere als ein ganzheitliches Fahrzeugkonfigurationssystem ausgebildet und ermöglicht in einfacher Art und Weise zusätzlich zu der herkömmlichen hardwarebasierten Individualisierung oder Konfiguration des Fahrzeugs 2 eine softwarebasierte Individualisierung oder Konfiguration des Fahrzeugs 2 und/oder von Fahrzeugkomponenten des Fahrzeugs 2.
• Das ganzheitliche Fahrzeugsystem 1 ermöglicht eine ganzheitliche Konfiguration von mehreren Fahrzeugen 2, 20 eines Benutzers oder die Konfiguration des einen Fahrzeugs 2 oder 20 durch einen fremden Benutzer derart beispielsweise, dass:
• - investierte oder konfigurierte Funktionen F des einen Fahrzeugs 2 nahtlos in ein anderes angeschlossenes Fahrzeug 20, das der Kunde vorübergehend nutzt, übertragen, eingefügt und/oder implementiert werden können.
• - ein fremder Benutzer, der kein Fahrzeug besitzt, aber ein Fahrzeug 2 oder 20 vorübergehend nutzt, die eingestellte Fahrzeugkonfiguration an seine Benutzererfahrung, seinen Benutzerwunsch oder seine gewünschte Konfiguration während der vorübergehenden Nutzung des Fahrzeugs 2 oder 20 anpassen kann. Ein solcher fremder Benutzer ist beispielsweise ein Carsharing-Kunde, ein Auto-Leasing-Kunde oder ein Fahrgast in einem Taxi oder Bus.
• - ein Benutzer neue softwarezentrierte oder software-basierte Funktionen F ausprobieren oder testen kann oder auch alternative Nutzungsmuster definieren oder vorgeben kann, anstatt eine Funktion F oder Merkmal M, wie ein Muster, auszuwählen, wie zum Beispiel „einmal kaufen und für immer besitzen“ zu wählen.
• Das ganzheitliche Fahrzeugsystem 1 ist eingerichtet, anhand des dynamisch individuell und/oder situationsbasiert anpassbaren Merkmals M und/oder der Funktion F mindestens ein Benutzererfahrungsszenario N des Fahrzeugs 2, 20, mindestens einer Fahrzeugkomponente 5, wie eines Assistenzsystems, eines Multimediasystems, und/oder mindestens einer Fahrzeugfunktion FF, wie einer Automatisierungsfunktion, einer Kommunikationsfunktion, zu konfigurieren, zu testen und/oder zu steuern.
• Hierzu ist eine Kommunikationsschnittstelle 6 vorgesehen, mittels der das mindestens eine Benutzererfahrungsszenario N des einen Fahrzeugs 2, der mindestens einen Fahrzeugkomponente 5 und/oder der mindestens einen Fahrzeugfunktion FF des einen Fahrzeugs 2 auf das andere Fahrzeug 20 über eine Kommunikationsschnittstelle 6, insbesondere drahtlos, zum Beispiel per Mobilfunk, Bluetooth oder WLAN, übertragbar ist.
• Dazu kommuniziert das ganzheitliche Fahrzeugsystem 1 über die Kommunikationsschnittstelle 6 mit einem Backend-System 7 zum Beispiel eines Fahrzeugherstellers (auch OEM genannt) zum Aktivieren und/oder zur Übertragung zumindest eines Benutzererfahrungsszenarios N im betreffenden Fahrzeug 2 oder 20 und/oder weiterer Daten, wie einzustellende Funktionen F, Fahrzeugfunktionen FF, Merkmale M. Beispielsweise wird oder ist für einen Kunden, Eigentümer und/oder Benutzer des Fahrzeugs 2 und/oder für das Fahrzeug 2 ein Benutzererfahrungsszenario N in der Kundendatenbank CD des Backend-Systems 7, zum Beispiel bei einem Hersteller oder einem Fahrzeugvermieter, hinterlegt. Dabei kann über entsprechende Verknüpfungen dieses Benutzererfahrungsszenario N mit einem anderen Fahrzeug 20 in der Kundendatenbank CD für denselben Kunden, Eigentümer und/oder Benutzer hinterlegt sein und beispielsweise über die Kommunikationsschnittstelle 6 an das andere Fahrzeug 20 übertragen oder im anderen Fahrzeug 20 aktiviert werden. Alternativ oder zusätzlich kann ein Benutzererfahrungsszenario N mit einem Kunden, Eigentümer und/oder Benutzer verknüpft in der Kundendatenbank CD hinterlegt sein, so dass wenn dieser Kunde, Eigentümer bzw. Benutzer ein weiteres, nicht näher dargestelltes Fahrzeug benutzt, das Benutzererfahrungsszenario N des Kunden, Eigentümers bzw. Benutzers an dieses weitere Fahrzeug übertragen oder in diesem weiteren Fahrzeug aktiviert wird.
• Dabei kann das Backend-System 7 mit einer weiteren Eingabeeinheit 3 über eine zugehörige Kommunikationsschnittstelle 6 interagieren. Die Eingabeeinheit 3 ist eingerichtet zur Vorgabe von Interaktionsdaten ID, insbesondere zum Vorgeben von Triggerpunkten und/oder Triggerbereichen, durch einen Benutzer. Die zugehörige Kommunikationsschnittstelle 6 ist eingerichtet beispielsweise zur Ankopplung eines externen Geräts 8, wie zum Beispiel eines Tablets, einer Diagnoseeinheit, etc. zur Erfassung von Sensordaten SD und/oder Interaktionsdaten ID.
• Darüber hinaus kann das Backend-System 7 zusätzlich zur Kundendatenbank CD weitere Speichereinheiten, wie Datenbanken, zum Beispiel eine Produktflotten-Bestandsdatenbank PFID, umfassen.
• Das ganzheitliche Fahrzeugsystem 1 ist somit insbesondere als ein ganzheitliches Konfigurations-, Test- und/oder Steuersystem ausgebildet.
• Die Erfindung ist auch anwendbar für andere Technikbereiche, wie zum Beispiel für mobile Geräte, wie Smartphones. Das ganzheitliche Fahrzeugsystem 1 ist dann als ein ganzheitliches Konfigurations-, Test- und/oder Steuersystem für mobile Geräte ausgebildet.
• Darüber hinaus kann mittels eines solchen mobilen Gerätes, das als eine Eingabeeinheit 3 verwendet wird, eine sogenannte „Ganzkörper“-Nutzererfahrung von dem Benutzer im zu nutzenden Fahrzeug 2 oder 20 mittels des ganzheitlichen Fahrzeugsystems 1 konfiguriert oder gesteuert werden. Ein solches mobiles Gerät kann dabei als Eingabeeinheit 3 oder als externes Gerät 8 mit dem ganzheitlichen Fahrzeugsystem 1 gekoppelt sein.
• Beispielsweise kann der Benutzer, zum Beispiel ein Fahrer, Beifahrer und/oder ein Insasse des Fahrzeugs 2 oder 20, mittels des ganzheitlichen Fahrzeugsystem 1 in einem modernen Luxus-Fahrzeug hardware- und/oder softwarebasierte Merkmale M und/oder Funktionen F, insbesondere Fahrzeugfunktionen FF, eines Sitzkomforts, audiovisueller Infotainmentsysteme, einer Klimaanlage und/oder eines Luftqualitätsmanagements oder bei gleichzeitiger Mobilität, sich von einem Ort zum anderen zu bewegen, auch einer Fahrfunktion dynamisch individuell und/oder situationsbasiert konfigurieren, testen bzw. anpassen, um so ein individuelles Benutzererfahrungsszenario N zu konfigurieren, zu testen und/oder zu steuern.
• Dabei ist das ganzheitliche Fahrzeugsystem 1 derart eingerichtet, dass das betreffende Merkmal M oder die Funktion F, wie zum Beispiel ein Sitz in dem Fahrzeug 2 oder 20, als ein so genannter Benutzererfahrungsraum UES (User Experience Space) betrachtet wird, der mit konfigurierbaren Hardware-Komponenten ausgestattet ist, um softwarezentrierte oder basierte Merkmale M und/oder Funktionen F als ganzheitliche User Experience-Funktionen zu ermöglichen, welche insbesondere konfigurierbar, steuerbar und/oder anpassbar sind.
• Hierzu umfasst das ganzheitliche Fahrzeugsystem 1 zumindest eine Speichereinheit, zum Beispiel eine Kundendatenbank CD (auch Customer Database genannt) und/oder eine Produktflotten-Bestandsdatenbank PFID (auch Product Fleet Inventory Database genannt) und eine Analyseeinheit sowie eine Steuer- und/oder Regeleinheit, wie zum Beispiel eine zentrale Komponenten- und Merkmalsverwaltungseinheit CCFMS (auch Central Components & Feature Management System genannt). Diese Kundendatenbank CD und/oder die Produktflotten-Bestandsdatenbank PFID sind externe Datenbanken beim Backend-System 7. Das Backend-System 7 umfasst mindestens eine Verarbeitungseinheit 11, insbesondere einen Mikroprozessor, zur Verarbeitung der Daten und/oder Informationen.
• Das jeweilige Fahrzeug 2, 20 kann dabei zum Beispiel eine zugehörige Speichereinheit 9 zur Hinterlegung von Merkmalen M, Funktionen F, Fahrzeugfunktionen FF, Szenarien N und/oder ein Fahrzeugassistenzsystem 10 zur Einstellung, Anpassung und/oder Aktivierung eines vorgegebenen Szenarios N umfassen. Das Fahrzeugassistenzsystem 10 kann beispielsweise ein Steuergerät oder ein Mikroprozessor oder eine andere geeignete Software sein.
• Das ganzheitliche Fahrzeugsystem 1 ist beispielsweise als Software, integrierte Schaltung oder als ein Mikroprozessor ausgebildet. Dabei findet beispielsweise die sogenannte Flux-Anwendungsarchitektur Anwendung in der Software. Es handelt sich um ein architektonisches Software-Muster. Dieses Software-Muster wird in mobilen Anwendungen wie Android- oder iOS-Anwendungen und auch in der Cloud-Computing-Domäne als ein Mechanismus zur Verwaltung der Interoperabilität von sogenannten Micro Services, zum Beispiel um Micro Services miteinander zu verknüpfen, eingesetzt. Die Erfindung ermöglicht damit einen ganzheitlichen automatischen Mechanismus in mobilen Ganzkörper-Benutzererfahrungssystemen.
• Das ganzheitliche Fahrzeugsystem 1 ermöglicht eine Unterstützung sowohl des Benutzers des Fahrzeugs 2 oder 20 und/oder eines mobilen Gerätes, wie zum Beispiel eines Mobiltelefons oder Tablets, als auch eines Softwareentwicklers des ganzheitlichen Fahrzeugsystems 1, um diesen generisch in die Lage zu versetzen, ganzheitliche Benutzererfahrungen in solchen Produkten, wie dem Fahrzeug 2 oder 20 oder dem mobilen Gerät, zu schaffen, die skalierbar sind.
• Im nachfolgenden wird ein ganzheitliches Fahrzeugsystem 1 beschrieben, welches einen ganzheitlichen Ansatz für die Art und Weise, wie die Benutzererfahrung des Kunden eines Fahrzeugs 2 oder 20 als Produkt P verwaltet wird, während er das oder weitere Produkte P desselben Herstellers einsetzt. Dieses ganzheitliche Fahrzeugsystem 1 kann sowohl auf Fahrzeugen 2 oder 20, wie Personenkraftwagen, Bussen, Schiffen, als auch auf allen Mobilitäts- und Gastlichkeitsprodukten, wie mobilen Endgeräten, wie Tablets, Smartphones, angewendet werden, die individuelle Benutzererfahrungen während der Nutzung der Produkte bieten, wie z.B. Passagiersitze in Taxis, Car-Sharing-Autos, Fahrräder, Schiffe, Busse, Boote, Sitze in Passagierflugzeugen, Hotelzimmer, Sitze in Kinos, Restaurants, Konzert- und Opernhäusern, um nur einige zu nennen.
• Die Zielproduktkategorie, die in den folgenden Beispielen beschrieben wird, sind autonome und vielseitig nutzbare Fahrzeuge 2 oder 20, wie Autos oder Schiffe, die in der Lage sind, sich irgendwie von einer Inneneinrichtung in eine andere zu verwandeln, um mehrere Szenarien N einer Benutzererfahrung eines Benutzer zu verwirklichen.
• In einigen Basisimplementierungen unterscheiden sich die Szenarien N nur unter dem Aspekt der Abhängigkeiten und Beziehungen der Softwarefunktionen zwischen den verschiedenen Benutzererfahrungsräumen UES#1 bis UES#4, welche auch als Szenarien A bis E bezeichnet werden und Raum, Komponenten- und/oder Teil-Szenarien darstellen.
• In einigen Implementierungen könnte der Wechsel von einem Benutzererfahrungsszenario N, insbesondere Szenarium A bis E zum anderen durch den Austausch einiger Teile des Innenraums gelöst werden. Eine weitere Variante dieses Konzepts könnte darin bestehen, dass der Austausch der Innenmodule, wie Hardware- und/oder Softwaremodule, nicht automatisiert erfolgt. Letztendlich ergibt sich der größte Nutzen, wenn der Wechsel von einem Benutzererfahrungsszenario N zum anderen vollautomatisch und ohne Beeinträchtigung der Benutzererfahrungen der Kunden erfolgt.
• In einigen Implementierungen kann dieser Wechsel vom ganzheitlichen Fahrzeugsystem 1 elektronisch durchgeführt werden, während die Kunden während dieser Zeit den Innenraum und damit das Fahrzeug 2 oder 20 verlassen müssen.
• 2 bis 18 zeigen jeweils in schematischer Blockdarstellung bzw. als ein Funktionsablaufplan ein Ausführungsbeispiel für eine Konfiguration des Fahrzeugs 2 oder 20 mittels des ganzheitlichen Fahrzeugsystems 1.
• 2 stellt eine Situation dar, in der ein erster Benutzer C1 einen ersten Benutzererfahrungsraum UES#1 (UES#1) einer ersten Produktinstanz P1 betreten hat, dies könnte z.B. der Fahrersitz eines Personenkraftwagens, zum Beispiel von Fahrzeug 2, sein. Dieser erste Benutzererfahrungsraum UES#1 ist im ganzheitlichen Fahrzeugsystem 1 mit den Merkmalen M, wie zum Beispiel Sitz mit integrierter Kopfstütze, Sitz mit verstellbarer Kopfstütze, und/oder Funktionen F, wie zum Beispiel Sitzheizung, elektrische Längsverstellung, nachgebildet.
• Der Kunde ist in einem Backend-System 7 des Fahrzeugherstellers (auch OEM genannt) bekannt und zum Beispiel in Form von Kundendaten in der Kundendatenbank CD hinterlegt. Beispielsweise kann jeder Benutzer, wie ein Kunde oder Neukunde oder Fahrzeugbesitzer, ein OEM-spezifisches Benutzerkonto in der Kundendatenbank CD haben, die die Identität des Kunden oder Benutzers repräsentieren.
• In einigen Implementierungen könnte dies auch durch die Anwendung selbst-souveräner Identitätskonzepte realisiert werden, bei denen der Benutzer die Verwaltung seiner eigenen Identität selbst bestimmt und im Vorfeld einen Onboarding-Prozess durchgeführt hat, um Dienstleistungen des Herstellers des Produkts P nutzen zu können.
• Die Mittel der Autorisierung und des Zugangsmanagements fallen nicht in den Anwendungsbereich dieses Konzepts. Es wird davon ausgegangen, dass die Identität des ersten Benutzers C1 erfolgreich validiert wurde und dass er einen gültigen Zugang zu der ersten Produktinstanz P1, zum Beispiel des Fahrzeugs 2, hat und erfolgreich in den ersten Benutzererfahrungsraum UES#1 eingetreten ist - mit anderen Worten: er hat auf dem Fahrersitz des Fahrzeugs 2 Platz genommen.
  Nun initiiert eine lokale Benutzerverwaltungseinheit LUMU als Teil des ganzheitlichen Fahrzeugsystems 1 die Anfrage an das zentrale Komponenten- und Merkmalsverwaltungssystem CCFMS des Backend-Systems 7. Dort wird der Merkmals- und/oder Funktionensatz (zum Beispiel ein Satz von Merkmalen M und/oder Funktionen F) des ersten Benutzers C1 für das betreffende Fahrzeug 2 aus der Kundendatenbank CD abgerufen und mit dem P1-Bestand des Produkts P der ersten Produktinstanz P1 abgeglichen, der in der Produktflotten-Bestandsdatenbank PFID gespeichert ist.
• Sobald dieser Abgleich erfolgreich abgeschlossen ist, informiert das zentrale Komponenten- und Merkmalsverwaltungssystem CCFMS eine lokale Komponenten- und Merkmalsverwaltungseinheit LCFMS (auch Local Components & Feature Management Unit bezeichnet) in der ersten Produktinstanz P1 über den neuen Status von verfügbaren Merkmalen AF, insbesondere verfügbaren Merkmalen AF(Cx) aller Benutzer Cx oder verfügbaren Merkmalen AF(Px) aller Produkte Px, wie dies in 3 dargestellt ist.
• Nun kommuniziert die lokale Komponenten- und Merkmalsverwaltungseinheit LCFMS des ganzheitlichen Fahrzeugsystems 1 mit den entsprechenden Komponenten, insbesondere Fahrzeugkomponenten 5, im Produkt P der ersten Produktinstanz P1, um die verfügbaren Merkmale AF für den ersten Benutzererfahrungsraum UES#1 im Produkt P der ersten Produktinstanz P1, zum Beispiel dem Fahrzeug 2, zu aktivieren.
• Dieselben Mechanismen werden verwendet, wenn dem ersten Benutzer C1 neue softwarebasierte Funktionen F angeboten werden. Sie werden in seiner Aufzeichnung der Kundendatenbank CD und auch in der Aufzeichnung des Produkts P in der ersten Produktinstanz P1 in der Produktflotten-Bestandsdatenbank PFID aktiviert.
• Mögliche Implementierungen dieses Konzepts könnten viele Arten von Geschäftsmodellen ermöglichen, z.B. Freemium, Bundles, Pay-per-Use, Leasing, einmalige Nutzung usw. Die Einzelheiten dazu stehen nicht im Mittelpunkt dieses Konzepts, können aber mit dieser technologischen Grundlage leicht unterstützt werden.
• 3 zeigt, wie der Match-Making-Prozess von produkt- und kundenbezogenen Merkmalen M für Hardware-Komponenten HCP (auch Hardware Components Perspective genannt) und Software-Merkmalen SFP (auch Software Feature Perspective genannt) im Backend-System 7 mittels des zentralen Komponenten- und Merkmalsverwaltungssystem CCFMS umgesetzt werden kann. Eine Menge Set A repräsentiert alle Software-Features (= softwarebasierte Merkmale M), die für alle Produktinstanzen P1 bis P3, zum Beipiel Fahrzeuge 2 und 20, von einem Hersteller (= OEM), für alle Produktlinien oder Produkte Px und eventuell auch für alle Geschäftsbereiche in einer Software-Feature-Perspektive SFP verfügbar sind.
• Darüber hinaus kann eine alternative Menge Set A' genau die gleiche Menge von Merkmalen M, wie zum Beispiel die Menge Set A, wenn ein Hersteller OEM alle seine softwarebasierten Merkmale M (Software-Features) zumindest an einige Benutzer Cx oder Kundensegmente verkauft.
• Im Folgenden wird diese Menge Set A als Satz von Software-Features für eine konkrete Fahrzeuglinie CL eines Fahrzeugherstellers definiert. Betrachtet man nun ein Produkt P, also eine Instanz der Fahrzeuglinie CL, so hat dieses Produkt P eine definierte Menge Set B von Hardware-Komponenten, mit denen er derzeit tatsächlich ausgestattet ist.
• Im nächsten Schritt ist eine Menge Set C eine Untermenge der Menge Set A, da sie von der Menge Set A abgeleitet ist und alle Merkmale M aus der Menge Set A filtert, die von den Hardwarekomponenten der Menge Set B des Produkts P abhängig sind.
• Diese Menge Set C definiert also alle möglichen Softwaremerkmale M aus der Menge Set A, die in dem Produkt P installiert werden können.
• Der nächste Schritt besteht darin, einen Blick auf den Satz von softwarebasierten Merkmalen M (Software-Features) zu werfen, die derzeit im Produkt P installiert sind - dies ist zum Beispiel eine Menge Set D.
• Dabei werden nicht die Features oder Merkmale M installiert, sondern Software-Komponenten, von denen die Merkmale M abhängen. Da die Aktivierung und Deaktivierung wesentlich schneller und flexibler ist als ein Software-Update (Download und Installation können einige Zeit in Anspruch nehmen und hängen von externen Faktoren wie Verfügbarkeit und Qualität der Verbindung usw. ab), könnten einige Implementierungen dieses Konzepts die Software-Installation von der Software-Aktivierung entkoppeln, um die Benutzerfreundlichkeit zu verbessern oder die Ressourcen zu optimieren.
• Die Menge Set F enthält zum Beispiel alle Softwarefunktionen, die zum aktuellen Zeitpunkt für den Kunden, zum Beispiel den ersten Benutzer C1, aktiviert sind, unabhängig davon, für welche Produktinstanz Px. Die Menge Set E enthält zum Beispiel alle Softwarefunktionen oder -merkmale, die aktuell für eine der Produktinstanzen Px für irgendeinen Nutzer Cx aktiviert sind.
• Schließlich muss es eine logische Verknüpfungsfunktion geben, um eine Verknüpfungsoperation zwischen der Menge Set E und der Menge Set F durchzuführen. Einige Implementierungen könnten eine UND-Verknüpfung realisieren: nur wenn der erste Benutzer C1 und das Produkt P ein Merkmal M aktiviert haben, dann wird es auch für den ersten Benutzer C1 im Produkt P aktiviert.
• Einige andere Implementierungen könnten eine ODER-Verknüpfung realisieren: wenn der erste Benutzer C1 oder das Produkt P ein Merkmal M aktiviert haben (nur eines von beiden oder beide), dann wird das Merkmal M auch für den ersten Benutzer C1 im Produkt P aktiviert.
• Welche Strategie oder Logik verwendet wird, hängt vom Anwendungsfall und dem Geschäftsmodell in der konkreten Implementierung ab.
• 4 zeigt eine Situation, wenn der erste Benutzer C1 den Personenkraftwagen von der Produktinstanz P1 auf die Produktinstanz P2 gewechselt hat. Der ganzheitliche Ansatz mit dem ganzheitlichen Fahrzeugsystem 1 erlaubt eine Lösung, die unabhängig von der konkreten Fahrzeuglinie desselben Herstellers ist. In einigen Implementierungen kann dies funktionieren, wenn die erste Produktinstanz P1 ein PKW war und die zweite Produktinstanz P2 ein LKW, ein Bus, ein Lieferwagen, ein Flugzeug usw. ist.
• Nach dem in 3 dargestellten Matching-Prozess erfährt der erste Benutzer C1 nun die Kombination seines Merkmalssatzes im Kontext der neuen Produktinstanz P2.
• In einigen Implementierungen könnte der Reservierungs- und Eincheck-Prozess vom ersten Benutzer C1 bis zur zweiten Produktinstanz P2 einige Zeit im Voraus benötigen - z.B. bei der Buchung eines Mietwagens ist der Wagen frühestens am nächsten Morgen verfügbar. Die Zeit über Nacht kann dazu genutzt werden, die Software herunterzuladen, um die Funktionen F für den ersten Benutzer C1 am nächsten Tag zu aktivieren.
• In weiteren Implementierungen ermöglicht dieser Mechanismus erweiterte Funktionen F und Benutzererfahrung auch für Kunden oder Benutzer Cx, die kein Auto dieses Herstellers besitzen, dieses aber von Zeit zu Zeit nutzen möchten. 5 zeigt die beispielhafte Situation, wenn der erste Benutzer C1 in den vierten Benutzererfahrungsraum UES#4 der dritten Produktinstanz P3 eingetreten ist, z.B. auf dem hinteren rechten Sitz in der zweiten Sitzreihe eines PKW, während der zweite Benutzer C2 auf dem Fahrersitz Platz genommen hat (= erster Benutzererfahrungsraum UES#1). Der erste Benutzererfahrungsraum UES#1 passt sich der Kombination aus den Merkmalen M des zweiten Benutzers C2 und dem Kontext der dritten Produktinstanz P3 an, während der vierte Benutzererfahrungsraum UES#4 sich der Kombination aus den Merkmalen M des ersten Benutzers C1 und dem Kontext der dritten Produktinstanz P3 anpasst.
• Dies könnte z.B. auch auf den Anwendungsfall eines Taxis angewendet werden, bei dem der zweite Benutzer C2 der Taxifahrer und der erste Benutzer C1 sein eigener Kunde, der Fahrgast, ist.
• 6 stellt eine Situation dar, in der eine erste Produktinstanz P1 mit vier individuellen Benutzererfahrungsräumen UES#1 bis UES#4 ausgestattet ist. Dies könnte sein: als erster Benutzererfahrungsraum UES#1 ein Fahrersitz, als zweiter Benutzererfahrungsraum UES#2 ein Beifahrersitz vordere Reihe, als dritter Benutzererfahrungsraum UES#3 ein Passagiersitz links in der zweiten Sitzreihe und als vierter Benutzererfahrungsraum UES#4 ein Passagiersitz rechts in der zweiten Sitzreihe. Alle diese vier Instanzen von Benutzererfahrungsräumen UES#1 bis UES#4 geben ihre Fähigkeiten in einer Spezifikation der UES-Fähigkeiten an.
• Die lokale Komponenten- und Feature-Management-Einheit LCFMU in einem Steuergerät im Fahrzeug 2 einer ersten Produktinstanz P1 oder im Fahrzeug 20 in einer zweiten Produktinstanz P2 sammelt alle diese Daten als Sammeldaten, wie Sensordaten SD und/oder Interaktivitätsdaten ID, Merkmale M, Funktionen F, in Schritt S1) und meldet sie als vollständige Benutzererfahrungsraum-Fähigkeitsspezifikation UESCS(P1) an das zentrale Komponenten- und Feature-Managementsystem CCFMS im Backend-System 7 in Schritt S2).
• Dort werden die Daten in der Produktflotten-Bestandsdatenbank PFID gespeichert.
• In einigen alternativen Implementierungen könnten die Einzelheiten der Fähigkeiten der Komponente in dem Backend-System 7 in einer Hardware-Fähigkeitsdatenbank HCDB gespeichert werden.
• Die Benutzererfahrungsräume UES#1 bis UES#x melden nur ihre Hardware-Identifikationsnummern (bzw. die der Komponenten, die sich innerhalb der Benutzererfahrungsräume UES#1 bis UES#x) befinden. Diese Identifikationsnummern werden an die Hardware-Fähigkeitsdatenbank HCDB gesendet, um von dort die Details abzurufen und diese Details in der Benutzererfahrungsraum-Fähigkeitsspezifikation UESCS (P1) zusammenzuführen.
• Sobald ein neues Software-Feature freigegeben wird, wird eine UES-Anforderungsspezifikation UESRS (F) für den betreffenden Benutzererfahrungsraum UES anhand dieses Features oder Merkmals M oder der Funktion F, wie zum Beispiel einer neuen Funktion nF, durch das Feature-to-Capabilities Match-Maker-System FCMM in Schritt S4) zusammen mit der Benutzererfahrungsraum-Fähigkeitsspezifikation UESCS (P1) der ersten Produktinstanz P1 aus der Produktflotten-Bestandsdatenbank PFID in Schritt S3) aus der Software-Features-Inventory-Datenbank SFID abgerufen.
• Ein Modul Features-to-Capabilities-Match-Maker FCMM analysiert nun die UES-Anforderungsspezifikation UESRS(nF) der neuen Funktion nF mit Hilfe des oder der betreffenden Benutzererfahrungsräumen UES und führt einen intelligenten Abgleich mit der Benutzererfahrungsraum-Fähigkeitsspezifikation UESCS(P1) der ersten Produktinstanz P1 durch. Das Ergebnis dieses Matching-Prozesses ist ein Abdeckungsgrad (auch kurz CR genannt) zwischen „0“ und „1“, wobei „1“ eine 100-prozentige Übereinstimmung der Anforderungen des Software-Merkmals an die Fähigkeiten der Hardware des Produkts ist und „0“ keine Übereinstimmung darstellt.
• Ein vordefinierter Schwellenwert für das Abdeckungsverhältnis (auch kurz CRTL genannt) für jedes Software-Feature/-Merkmal muss berücksichtigt werden: Wenn der tatsächliche Wert des Abdeckungsgrades CR unter diesem Schwellenwert liegt, wird eine Feature-to-Product Match Result Spezifikation FPMRS von nF-P1 nicht generiert und somit nicht an das Produkt P der ersten Produktinstanz P1 gesendet. Das Ergebnis dieser Analyse wird zur späteren Bezugnahme innerhalb der Produktflotten-Bestandsdatenbank PFID des Backend-Systems 7 gespeichert.
• Wenn der tatsächliche Abdeckungsgrad CR gleich oder höher als der Schwellwert CRTL ist, wird die Feature-to-Product Match Result Spezifikation FPMRS von nF-P1 generiert und in Schritt S5) an die lokale Komponenten- und Feature-Management-Einheit LCFMU der ersten Produktinstanz P1, dem Fahrzeug 2 und/oder 20, gesendet.
• Diese Feature-to-Product Match Result Spezifikation FPMRS enthält alle Einzelheiten über Diskrepanzen zwischen den optimalen Anforderungen aus der Sicht der Software und den tatsächlichen Möglichkeiten des Produkts der ersten Produktinstanz P1.
• Im Schritt S6) generiert die lokale Komponenten- und Feature-Management-Einheit LCFMU das „Angebot des neuen Software-Features“, zum Beispiel neue Funktion nF, an den Benutzer über eine Benutzerschnittstelle UI mit adäquater Kommunikation der Abhängigkeiten, wenn der Benutzer diese neue Funktion nF innerhalb der ersten Produktinstanz P1 akzeptieren würde.
• Diese Abhängigkeiten können sich sowohl aus dem Geschäftsmodell und damit den vorgesehenen Nutzungsmodellen und -schemata als auch aus den im Feature-to-Product Match Result Spezifikation FPMRS von NF-P1 beschriebenen Diskrepanzen ergeben.
• Wenn der Benutzer die neue Funktion nF akzeptiert, die in der ersten Produktinstanz P1 installiert werden soll, dann ist die neue Funktion nF entweder bereits installiert und muss nur noch aktiviert werden, oder die neue Funktion nF wird jetzt an die erste Produktinstanz P1 übertragen und anschließend aktiviert.
• Struktur und Komponenten der Spezifikationen des jeweiligen Benutzererfahrungsraumes UES
• Das Ziel einer Spezifikation eines Benutzererfahrungsraumes UES ist es, Parameter in semantisch logischer Weise zu definieren, um die verschiedenen Aspekte der digitalen Benutzererfahrung zu beschreiben. Sie leitet sich einerseits aus der Fähigkeit des Menschen ab, seine Umwelt wahrzunehmen und mit ihr zu interagieren, und andererseits aus der Fähigkeit des Systems, menschliche Aspekte jeglicher Art wahrzunehmen.
• Die folgenden Aspekte können in einigen Implementierungen als Merkmale M und/oder Funktionen F für den gewünschten Benutzererfahrungsraum UES berücksichtigt werden:
• - die physischen Dimensionen des jeweiligen Benutzererfahrungsraumes UES, UES#1 bis UES#4 und menschliche Sinne:
• - Extern: Vision, Hören, Berühren, Ausgewogenheit, Geschmack, Geruch,
• - Intern: Propriozeption (Bewegung), Anthropometrische Parameter oder Wertebereiche, Höhe, Gewicht, Messung von biologischen Signalen oder anderen Aspekten, wie Puls, Blutdruck, Bewegungsverfolgung (Beschleunigungen), Qualität der Atemluft, z.B. zum Nachweis der Verbreitung von Viren etc.
• - Andere: Sitzpositionen (aufrecht, flach usw.), Restriktionsgurte (empfohlen, eingelegt usw.), Zugang zu Fahrzeugdaten (schreibgeschützt oder lese/schreibbar), wie z. B: Navigation, Richtung, Beschleunigung, Lenkradstellung usw., Innenraumklima, Lüftungsstufen, Temperaturen, Luftfeuchtigkeit, Heizung, Belüftung oder Vibrationen von Lenkrad, Sitzen, anderen Oberflächen, Berührungsereignisse auf jeder Art von Oberflächen, Haptische Interaktionen auf jeder Art von Oberflächen, Außen-Bedingungen (nur lesend): wie Luftqualität, Temperatur, Lichtexposition, Wetterbedingungen,
• - Außengeräuschquellen (vorne, links, rechts, hinten),
• - Außenkamerasignale (vorne, links, rechts, hinten, Rückansicht links/rechts): Außen-Aktivatoren (nur schreibend): Lichtquellen, Horn, Tongenerator, Ergebnisse von Objekterkennungsalgorithmen für die Fahrzeugumgebung mit relativer Position zum Benutzererfahrungsraum UES,
• - Klassifikation von Objekten mit Unsicherheitsfaktoren,
• - Erkannte Bewegungsbahnen von Objekten mit Unsicherheitsfaktoren,
• - Vorhergesagte nächste Bewegungen aus historischen Bewegungsbahnen von Objekten mit Unsicherheitsfaktoren,
• - Kollisionswahrscheinlichkeitsverhältnisse mit eigenem Fahrzeug für klassifizierte Objekte mit Unsicherheitsfaktoren,
• Beispiel für einen Matchmaking-Prozess:
• Anhand dieser beiden einfachen Beispieldateien einer UES-Anforderungsspezifikation UESRS(nF) und einer Benutzererfahrungsraum-Fähigkeitsspezifikation UESCS(P1) für den zweiten Benutzererfahrungsraum UES#2 (= Beifahrersitz) lässt sich der allgemeine Matchmaking-Prozess wie folgt erklären:
  • In diesem Fall könnte ein „einfaches Video-Streaming-Feature“ für Video-Streaming in Full-HD-Qualität die Benutzererfahrungsraum-Anforderungsspezifikation UESRS#2 verursachen. Auf der anderen Seite haben wir eine Benutzererfahrungsraum-Fähigkeitsspezifikation UESCS(P1) für einen Beifahrersitz in der ersten Reihe eines modernen Luxus-Personenwagens. Der Prozess würde iterativ die Anforderungsspezifikation von oben nach unten analysieren und versucht, auf der gleichen Aggregationsebene in den Fähigkeiten die dort spezifizierten Aspekte abzugleichen.
• In diesem Fall ist das Display in der Lage, Full-HD-Video in Bezug auf die Auflösung zu bedienen, und das Soundsystem ist in der Lage, Stereoton zu unterstützen. Da es keine Möglichkeit gibt, die Lautstärke für diesen zweiten Benutzererfahrungsraum UES#2 individuell einzustellen, da es sich um den Beifahrersitz handelt, führt dies zu einer leichten Diskrepanz zwischen den Anforderungen und Fähigkeiten. Daher würde der Abdeckungsgrad CR in diesem Beispiel 0,95 betragen. Da das Merkmal mit einem Schwellenwert für den Deckungsgrad CRTL von 0,9 ausgestattet ist, wäre das Ergebnis des Matchmaking-Prozesses mit einer Diskrepanz von 5% positiv.
• Nach dem in 6 dargestellten Prozess würde dieses Ergebnis in die Spezifikation des Matchmaking-Ergebnisses für das Feature eingefügt und dieses „einfache Video-Streaming-Feature“ würde dem Kunden über die Benutzeroberfläche angeboten.
• 7 stellt eine Situation dar, in der ein Kunde, ein erster Benutzer C1, den ersten Benutzererfahrungsraum UES#1 der ersten Produktinstanz P1 betreten hat, dies könnte z.B. der Fahrersitz eines Personenkraftwagens sein.
• Der Kunde ist in dem Backend-System 7 des Herstellers bekannt. Dies könnte mit OEMspezifischen Benutzerkonten, die in der Kundendatenbank CD hinterlegt und eingerichtet sind, realisiert werden, die die Identität des Kunden repräsentieren. In einigen Implementierungen könnte dies auch durch die Anwendung selbst-souveräner Identitätskonzepte realisiert werden, bei denen der Kunde die Verwaltung seiner digitalen Identität selbst bestimmt und im Vorfeld einen Onboarding-Prozess durchgeführt hat, um Dienstleistungen des Herstellers des Produkts P nutzen zu können.
• Auch die Mittel der Autorisierung und des Zugangsmanagements fallen nicht in den Anwendungsbereich dieses Konzepts. Vorerst gehen wir davon aus, dass die Identität des ersten Benutzers C1 erfolgreich validiert wurde und dass er einen gültigen Zugang zur ersten Produktinstanz P1 hat und erfolgreich in den ersten Benutzererfahrungsraum UES#1 eingetreten ist - mit anderen Worten: er hat auf dem Fahrersitz Platz genommen.
• Dasselbe gilt für die drei anderen Fahrgäste: die zweiten bis vierten Benutzer C2, C3 und C4, die auf den anderen Benutzererfahrungsräumen UES#2 bis UES#4 Platz genommen haben.
• Nun initiiert die lokale Benutzerverwaltungseinheit LUMU die Anfrage an das zentrale Komponenten- und Merkmalverwaltungssystem CCFMS.
• Dort wird der Merkmalssatz des Kunden für das Szenario A aus der Kundendatenbank (CD) abgerufen und mit dem P1-Bestand des Produkts für Szenario A abgeglichen, der in der Datenbank für den Produktflottenbestand PFID gespeichert ist. Sobald dieser Abgleich erfolgreich abgeschlossen ist, informiert das zentrale Komponenten- und Merkmalverwaltungssystem CCFMS die lokale Komponenten- und Merkmalsverwaltungseinheit LCFMS in der ersten Produktinstanz P1 über den neuen Status der verfügbaren Merkmale AF. Nun kommuniziert das lokale Komponenten- und Merkmalverwaltungssystem LCFMS mit den entsprechenden Komponenten im Produkt der ersten Produktinstanz P1, um die verfügbaren Merkmale AFs für die Benutzererfahrungsräume UES#1 bis UES#4 im Produkt der ersten Produktinstanz P1 zu aktivieren.
• Während dieses Prozesses wird der Innenraum, zum Beispiel der Fahrzeuginnenraum, als ein ganzes System von Benutzererfahrungsräumen UES verwaltet, die voneinander abhängig sind. In diesem Standardszenario hat der erste Benutzererfahrungsraum UES#1 die Rechte, die Funktionen „Tür verriegeln“, „Fenster öffnen/schließen“ und „Fenster verriegeln“ der anderen Benutzererfahrungsräume UES#2, UES#3 und UES#4 auszuführen. Dies ist nur beispielhaft und könnte bei einigen Implementierungen anders sein.
• Dieselben Mechanismen werden verwendet, wenn den Kunden neue softwarezentrierte Funktionen F angeboten werden. Sie werden in ihren Aufzeichnungen der Kundendatenbank CD und auch in der Aufzeichnung des Produkts der ersten Produktinstanz P1 in der Produktflotten-Bestandsdatenbank PFID aktiviert.
• 8 zeigt nun dieselbe erste Produktinstanz P1 mit dem Fahrzeuginnenraum im Szenario B. Der Innenraum des Fahrzeugs der ersten Produktinstanz P1 hat sich von Szenario A („Standard vier Sitze“) zu Szenario B („Vier-Sitz-Chauffeur-Modus“) verändert. In diesem Szenario B hat der vierte Benutzererfahrungsraum UES#4 die Rechte, die „move seat“- Funktion des zweiten Benutzererfahrungsraumes UES#2 auszuführen. Dies ist nur beispielhaft und könnte bei einigen Implementierungen anders sein. Alle anderen Folgeprozesse sind die gleichen wie zuvor für Szenario A beschrieben.
• 9 zeigt nun die gleiche erste Produktinstanz P1 mit dem Fahrzeuginnenraum im Szenario C. Der Innenraum des Fahrzeugs der ersten Produktinstanz P1 hat sich zu Szenario C („eine Liegefläche, zwei Sitze“) gewandelt. In diesem Szenario C haben die Benutzererfahrungsräume UES#1, UES#2 und UES#4 unterschiedliche Parameter und Fähigkeiten, die der Produktflotten-Bestandsdatenbank PFID gemeldet werden. Der dritte Benutzererfahrungsraum UES#3 ist in diesem Szenario C nicht vorhanden. Alle anderen Folgeprozesse sind die gleichen wie zuvor für Szenario A beschrieben.
• 10 zeigt nun dieselbe erste Produktinstanz P1 mit dem Fahrzeuginnenraum im Szenario D. Der Innenraum des Fahrzeugs der ersten Produktinstanz P1 hat sich nun zum Szenario D („zwei gegenüberliegende Sitze, ein Tisch T“) geändert. Diese Einstellung könnte für Essensgebrauchsfälle anwendbar sein, bei denen das Fahrzeug z.B. in einem Restaurantbereich parkt, wo das Essen direkt an den Tisch T im Inneren des Fahrzeugs der ersten Produktinstanz P1 serviert wird.
• In diesem Szenario D werden die Benutzererfahrungsräume UES#1 und UES#2 kombiniert und haben andere Parameter und Fähigkeiten als in den vorherigen Szenarien A bis C, die der Produktflotten-Bestandsdatenbank PFID übermittelt und dort gespeichert werden. Die Benutzererfahrungsräume UES#3 und UES#4 sind in diesem Szenario D nicht vorhanden. Alle anderen nachfolgenden Prozesse sind die gleichen wie zuvor für Szenario A beschrieben.
• 11 zeigt nun dieselbe erste Produktinstanz P1 mit dem Fahrzeuginnenraum im Szenario E. Der Innenraum des Fahrzeugs der ersten Produktinstanz P1 hat sich nun zum Szenario E („Liegefläche / Bett für zwei Personen“) geändert. Diese Einstellung könnte als Liegefläche für Entspannungs- oder Schlafnutzungsfälle anwendbar sein, wenn das Fahrzeug z.B. in einem Hotelbereich parkt, wo andere Hospitality-Dienstleistungen in Gehdistanz erreichbar sind, z.B. für Sanitär- oder Waschanlagen.
• Dieses Szenario E könnte auch eine solche Inneneinrichtung unterstützen, während die Reise in einem völlig autonomen Fahrzeug fortgesetzt wird, z.B. mit einem „Nachtzug auf der Straße“.
• In diesem Szenario E werden die Benutzererfahrungsräume UES#1 und UES#2 kombiniert und haben andere Parameter und Fähigkeiten als in den vorherigen Szenarien A bis D, die der Produktflotten-Bestandsdatenbank PFID übermittelt und dort gespeichert werden. Die Benutzererfahrungsräume UES#3 und UES#4 sind in diesem Szenario E nicht vorhanden. Alle anderen nachfolgenden Prozesse sind die gleichen wie zuvor für Szenario A beschrieben.
• Die Szenarien A, B, C, D und E sind beispielhaft und veranschaulichen die Idee des Konzepts. Jedes andere Benutzererfahrungs-Szenario N, auch mit anderen, komplexeren Funktionen, wird von diesem Konzept abgedeckt. Denkbar wären Benutzererfahrungsräume, die Wasserbassins, Duschen, Solarien, Sportgeräte usw. umfassen.
• Auch Konstellationen, in denen mehrere Benutzererfahrungsräume UES kombiniert werden, sind denkbar. Solche Produkte P wie Busse, Lieferwagen oder Schiffe könnten so ausgestattet werden, dass sie mehrere Szenarien A bis E für mehrere Benutzererfahrungsräume UES unterstützen, um die optimale Umgebung für Gruppenerfahrungen zu schaffen, z.B. bei gemeinsamen Reisen oder der Teilnahme an spiel- oder kommunikationsbasierten Anwendungsfällen.
• Erweiterung des Benutzererfahrungsraum-(UES)-Konzepts zur Integration eines bordeigenen Kontextmanagementsystems
• Die Lösung besteht darin, die sogenannte Flux-Idee anzuwenden, um Borddaten eines angeschlossenen externen (internetfähigen) Gerätes, wie zum eines sogenannten loT-Gerätes (internet-of-things-Gerät), das drahtgebunden oder drahtlos an das Internet angeschlossen ist, zu verwalten, das zum Transport oder zur Aufnahme von Passagieren verwendet wird. Dabei kann es sich um ein Fahrzeug am Straßenrand, ein Flugzeug, eine Drohne, ein Boot oder ein anderes System handeln, das Sensordaten SD verarbeitet und als loT-Gerät mit seiner Umgebung interagiert und Platz für mindestens einen Passagier bietet. Im weiteren konzentriert sich dieses Konzept auf Passagierfahrzeuge.
• Die Idee besteht darin, das Muster der Flux-Architektur auf die Datenverarbeitungsfunktionen im Inneren des Fahrzeugs zu übertragen, um die Datenverarbeitungsdienste zu entkoppeln und die Entwicklung neuer Anwendungen auf der Grundlage der von den bestehenden Diensten erzeugten Daten zu ermöglichen. Dies ermöglicht ein echtes Cloud-Natives Computing mit einer entkoppelten Micro-Service-Architektur innerhalb des Edge-Gerätes, das mindestens einen Passagier beherbergt.
• 12 zeigt den detaillierten Überblick über ein Onboard-Kontextmanagementsystem OCMS des ganzheitlichen Fahrzeugsystems 1, wie es aus dem Konzept „Ein Onboard-Kontextmanagementsystem zur Ermöglichung von Edge-Computing“ bekannt ist. In Spalte 1 ist beispielhaft eine erste Domänenperspektive D1 dargestellt, die beispielsweise Sensordaten SD anderer Objekte, Personen und deren Verhalten (=„otherobjects, individuals and their behavious“) als Rohdaten RAW berücksichtigen. In Spalte 2 ist eine zweite Domänenperspektive D2 dargestellt, die beispielsweise Sensordaten SD des Wetters, Wetterbedingungen und/oder Trends (= „Weather conditions and trends“) als Rohdaten RAW berücksichtigen. In Spalte 3 ist eine dritte Domänenperspektive D3 dargestellt, die beispielsweise Sensordaten SD von Verkehrsbedingungen und Trends (= „Traffic conditions and trends“) als Rohdaten RAW berücksichtigen. In Spalte 4 ist eine vierte Domänenperspektive D4 dargestellt, die beispielsweise Daten und/oder Informationen betreffend das „eigene Verhalten“ (= „Own behaviour“) als Rohdaten RAW berücksichtigen. Diese erfassten Rohdaten RAW werden bei der Generierung eines neuen oder bei der Anpassung eines vorhandenen Szenarios N berücksichtigt und schrittweise und/oder in Hierarchien L1 bis L4 hinsichtlich ihrer Bedeutung BED, im Context CON und/oder ihrer Anwendung APP weiterverarbeitet.
• Im weiteren Verlauf wird beispielhaft näher betrachtet, was unter der vierten Domänenperspektive D4 dem „eigenen Verhalten“ zu verstehen ist und wie es Passagierinteraktionen, insbesondere Interaktionsdaten ID, integrieren kann.
• 13 zeigt die schematische Übersicht eines Onboard-Kontextmanagementsystems OCMS, das auf einen einzelnen Benutzererfahrungsraum UES angewendet wird. Das Konzept eines Benutzererfahrungsraumes UES wird auf das Kontextmanagement-Konzept angewandt. Jede der vierten Domänenperspektive D4 zugehörige Unterdomänenperspektive UD1 bis UD4 konzentriert sich auf verschiedene Sensordatenquellen, die durch die Interaktionen des Passagiers, der sich innerhalb dieses spezifischen Benutzererfahrungsraumes UES befindet, gespeist werden.
• In Spalte 1 (= erste Unterdomänenperspektive UD1) werden die Daten von Innenraumkameras, insbesondere Videosignale, als eingehende Sensordaten SD verarbeitet, um z.B. Grimassen, Körperbewegungen, Emotionen usw. zu erkennen. Auch andere Datenquellen, wie z.B. Vitalparameter des Fahrgastes oder Luftqualitätsmessungen oder Audiosignale für die Spracherkennung können als Sensordaten SD und/oder Interaktivitätsdaten ID berücksichtigt werden. Diese Bereiche sind exemplarisch und können in einigen Anwendungen dieses Konzepts je nach den jeweiligen Anwendungsfällen völlig unterschiedlich sein.
• In Spalte 2 (= zweite Unterdomänenperspektive UD2) werden die Daten von Mikrofonen, insbesondere Audiosignale, als eingehende Sensordaten SD verarbeitet, um beispielsweise Sprachnachrichten, Befehle, Audiosignale der Spracherkennung, zu berücksichtigen.
• In Spalte 3 (= dritte Unterdomänenperspektive UD3) werden die Daten von biometrischen Sensoren, insbesondere Vitalparameter, als eingehende Sensordaten SD verarbeitet, um beispielsweise Herzschlag, Puls, Augenzucken, etc. der betreffenden Person zu überwachen und zu berücksichtigen bei der Einstellung, Anpassung oder Generierung des Szenarios N
• In Spalte 4 (= vierte Unterdomänenperspektive UD4) werden die Daten von Umweltsensoren, insbesondere Luftqualitätsdaten, Feuchtigkeitsdaten, als eingehende Sensordaten SD verarbeitet.
• Dabei werden die erfassten Daten der Domänenperspektiven D1 bis D4 als auch der Unterdomänenperspektiven UD1 bis UD4 sowohl hinsichtlich deren Anwendung APP als auch im Context CON, deren Bedeutung BED und als Rohdaten RAW schrittweise in Verarbeitungsschritten F1 bis F4 und/oder in Hierarchien L1 bis L4 je Domänenperspektive D1 bis D4 und/oder je Unterdomänenperspektive UD1 bis UD4 zu Informationen, Wissen und Weisheitswissen verarbeitet. Insbesondere werden dabei in einer ersten Hierarchie L1 die Daten aller Domänenperspektiven D1 bis D4 und/oder aller Unterdomänenperspektiven UD1 bis UD4 zu Informationen, die Informationen der ersten Hierarchie L1 zu Wissen einer zweiten Hierarchie L2 und das Wissen der zweiten Hierarchie L2 zu Weisheitswissen einer dritten Hierarchie L3 und von dieser zur Anwendung APP in einer vierten Hierarchie L4 verarbeitet.
• 14 zeigt die Anwendung des Onboard-Kontextmanagementsystems OCMS in einem Personenkraftwagen bzw. innerhalb eines Hochleistungsrechnersystems in diesem Fahrzeug V1 bis V3. Die Idee ist nun, dass jeder Benutzererfahrungsraum UES im Fahrzeug V1 bis V3 mit einem eigenen Onboard-Kontextmanagementsystem OCMS verbunden ist, das die Entwicklung von Anwendungen APP#1, APP#N ermöglicht, die auf den aggregierten „Weisheitsdaten“ oder dem Weisheitswissen aus verschiedenen Domänenperspektiven D1 bis D4 und/oder Unterdomänenperspektiven UD1 bis UD4 aufbauen und so integrierte Funktionen F, wie zum Beispiel User-Experience-Funktionen, realisieren. Auf der nächsthöheren Integrationsebene werden alle verschiedenen Kontexte CON mittels eines zugehörigen logischen Kontextmanagementsystem CMS(UES#1) bis CMS(UES#4) (in diesem Fall vier) integriert und in der eigenen Verhaltensperspektive des gesamten Onboard-Kontextmanagementsystems OCMS des Fahrzeugs V1 aggregiert. Dabei kann das Onboard-Kontextmanagementsystem OCMS einen Kontextdatenspeicher CON-DS zur Speicherung der relevanten Daten und Informationen umfassen.
• Möglicher Anwendungsbereich dieses Konzepts ist beispielsweise:
• - ein mehrkanaliges Benutzererlebnis in einem Autokino 12, wie dies in 15 gezeigt ist.
• Ein Autokino 12 bietet eine Show mit Spezialeffekten, die über Video- und Audioeffekte hinausgehen, um ein immersives multisensuales Erlebnis in Personenfahrzeugen zu schaffen, indem die verfügbaren Möglichkeiten der Benutzererfahrungsräume UES innerhalb des Fahrzeugs genutzt werden.
• Es gibt feste Installationen spezieller Kinos (z.B. das 6D-Kino im Disneyland Paris), in denen ein Kunde einen Film mit 3D-Bildern, bewegten Sitzen, speziellen Wind- und Lichteffekten und Toneffekten im Rhythmus des Films erleben kann.
• Dieses Konzept ist nicht skalierbar, da der Service nur an sehr wenigen Orten auf der Welt verfügbar ist.
• Die Lösung besteht darin, das maximale Potenzial der vorhandenen Komponenten in modernen Luxus-Personenwagen zu nutzen und sie mit den Möglichkeiten moderner digitaler Unterhaltungsmöglichkeiten zu kombinieren. Um einen solchen Ansatz zu ermöglichen, erfolgt eine standardisierte Integration zwischen den Möglichkeiten des oder der Benutzererfahrungsräume UES#1 bis UES#4 aus den Fahrzeugen V1 bis V3 und den Anforderungen an den Benutzererfahrungsraum UES# aus der Kinosoftware und damit aus den Videoinhalten. Zusätzlich zu den Audio- und Videokanälen eines solchen „Unterhaltungsdatenstroms“ muss es zusätzliche Kanäle zur Übertragung von Signalen geben, um die Aktuatoren in dem Benutzererfahrungsraum UES synchron zur erzählten Geschichte zu stimulieren.
• 15 zeigt die Grundelemente eines mehrkanaligen Benutzererfahrungs-Drive-in-Kinos MUEDC mit exemplarischer Präsenz von drei Fahrzeugen: V1, V2 und V3 und einem Kinosteuerungssystem CSCS und einem Kinobildschirm CinSc. Das Kinosteuerungssystem CSCS ist mit allen Fahrzeugen V1 bis V3 über das Internetprotokoll verbunden. In einigen Implementierungen wird dies über Wifi-Konnektivität zwischen dem Kinosteuerungssystem CSCS und den Fahrzeugen realisiert. In einigen Implementierungen sind die Fahrzeuge über Mobilfunk-Netzwerke basierend auf Cloud-Technologie mit dem Internet verbunden.
• 16 stellt die Details dieses Konzepts im Fahrzeug V1 dar: Bevor die Kino-Client-App CCA auf dem Fahrzeug V1 installiert wurde, fand ein Matchmaking-Prozess statt, wie zuvor beschrieben. Das Ergebnis dieses Prozesses ist eine positive Übereinstimmung zwischen den Anforderungen des Kinos bzw. des Films an die mehreren Benutzererfahrungsräume UES#1 bis UES#4 und den tatsächlichen Fähigkeiten der jeweiligen Benutzererfahrungsraumes UES des Fahrzeugs V1. Darüber hinaus ist die entsprechende Feature-to-product Match Result Spezifikation FPMRS für das Fahrzeug V1 für die Kino-Client-App CCA verfügbar.
• Diese Spezifikation definiert die Verarbeitung der Anforderungen des Films an die zusätzlichen Komponenten im Fahrzeug V1 synchron mit der Geschichte und die reale Ausführung in den real existierenden Benutzererfahrungsräumen UES des Fahrzeugs V1. Während der Filminhalt auf die Kinoleinwand oder dem Kinobildschirm CinSc gestreamt wird, müssen die Audiosignale und alle anderen „Special Effects“-Signale aus einem Show-Content-Datenspeicher SCDS eines Cinema Show Content Server CSCServ synchron zu den angeschlossenen Fahrzeugen V1, V2 und V3 gestreamt werden.
• Weitere Anwendung: Ein dynamisches mehrstufiges Transportintegrationssystem 13, wie dies in 17 gezeigt ist:
• Dieser Anwendungsfall eines modularen Transportsystems bietet die Integration und den Austausch von Passagier- und Frachtmodulen in Transportmodule, der automatisch durchgeführt wird, während die Benutzererfahrung des Kunden und die Einstellungen der Frachtmodule automatisch an die sich ändernden Umgebungen angepasst werden.
• Für die Integration von Traktoren und Maschinen in den land- und forstwirtschaftlichen Kontext gibt es eine Norm mit der Bezeichnung „ISOBUS“ - ISO 11783 - und diese ermöglicht die automatische Übernahme und Integration von Maschinenfunktionen in die Benutzeroberfläche der Benutzersystem mit Benutzerschnittstelle UI (Ul-Systeme) des Traktors unter Verwendung eines „Plug & Play“-Paradigmas (siehe https://en.wikipedia.org/wiki/ISO_11783).
• Dies ermöglicht die Integration von externen Maschinenfunktionen in das Benutzererfahrungssystem des Traktorfahrers.
• In der Computerwelt hat sich das „Plug & Play“-Paradigma für viele Kommunikationsschnittstellenstandards wie USB, PCI oder PCMCIA durchgesetzt. Diese Implementierungen bieten dem Benutzer Cx für jede Art von Gerät, das zunächst an ein Computersystem angeschlossen wird, eine automatische Erkennung und automatische Installation. Ähnlich wie bei der ISOBUS-Lösung konzentrieren sich diese Lösungen auf die funktionelle Integration externer Geräte in das Hauptsystem.
• Die Lösung ist ein ganzheitlicher Ansatz für die Art und Weise, wie die Benutzererfahrung des Kunden gehandhabt wird, während die Dienste eines Transportsystems genutzt werden, das aus mehrstufigen integrierten Modulen besteht, die automatisch kombiniert und neu kombiniert werden können, um die Reiseerfahrung der Fahrgäste zu optimieren. Sie erweitert das Konzept eines dynamischen Customer Experience Management Systems für softwarebasierte Funktionen F in verbundenen Geräten, um eine mögliche vollautomatische mehrstufige Integration autonomer Module in einem zukünftigen Transportsystem zu realisieren. Es kann auch auf Frachtmodule angewendet werden, die keine Passagiere befördern, aber ebenfalls besondere Anforderungen an die Bedingungen der Fracht während der Reise darstellen. Dies können z.B. Anforderungen an Belüftung, Kühlung, Vibrationen oder Beschleunigungen sein.
• 17 zeigt eine Kombination aus einem Kabinenmodul CM1 in einer Kabinenmodulinstanz CMI, das Platz für vier Passagiere bietet, während der Benutzererfahrungsraum UES#1 von einem ersten Benutzer C1 (Passagier) belegt wird, und einem Transportmodul TM1 in einer Transportmodulinstanz TMI. Das Transportmodul TM1 umfasst eine lokale Komponenten- und Feature-Management-Integrationseinheit LCFMIU. Das Kabinenmodul CM1 umfasst eine lokale Komponenten- und Feature-Management-Einheit LCFMU.
• Im Vorfeld gab es einen Modulintegrationsprozess der folgenden Module:
1. 1. Transportmodul TM1, das die gesamte Ausrüstung für den Transport enthält, wie z.B. Energiespeicher, Antriebsstrang, Fahrgestell, Lenksysteme, externe Sensoren und Akteure zur Interaktion mit dem Außenbereich und anderen Verkehrsteilnehmern,
2. 2. Kabinenmodul CM1, das die gesamte Passagierausrüstung für einen komfortablen Aufenthalt an Bord enthält. Dies könnten sein: Klimaanlagen, externe Licht- und Wärmemanagement-Systeme (wie z.B. intelligentes Glas, Fenster usw.), Türen und ein oder mehrere fest installierte Benutzererfahrungsräume UES.
• Diese Benutzererfahrungsräume UES fassen alle Ausrüstungen zusammen, um den Passagieren die beabsichtigte Benutzererfahrung zu bieten, wie z.B. Sitze, Armlehnen, Betten, Tische, Bänke, Abteile für Gepäck und andere Ablagefächer, Kühlboxen usw. sowie alle Arten von Sensoren und Aktoren zur Interaktion mit den Passagieren, wie z.B. Anzeigen, Kameras, Mikrofone, Lichtquellen, Lautsprecher, empfindliche Oberflächen usw.
• Dieser Integrationsprozess könnte in einigen Implementierungen dieses Konzepts vollautomatisch durchgeführt werden, wenn z.B. ein Transportmodul TM mit einer speziellen Form eines Kabinenmoduls CM1 kombiniert und an den gewünschten Ort eines Kunden geschickt wird, um ihn abzuholen und die gewünschte Dienstleistung in dieser Kombination zu erbringen. Oder bei der Realisierung einer Fernreise, bei der der Kunde keine Zeit verlieren möchte, wird das Transportmodul TM1 unterwegs an definierten Tauschstationen gegen ein neues Transportmodul TM2 ausgetauscht, das über eine voll aufgeladene Batterie einer oder einer beliebigen anderen Energiespeichertechnologie verfügt. Dies macht nur dann Sinn, wenn die Zeit für diesen Tausch kürzer ist als das Warten auf das Aufladen oder Auftanken des Energiesystems des Transportmoduls TM1. Oder in einem dritten Fall hat das Transportmoduls TM1 ein technisches Problem und muss an einer Servicestelle ausgetauscht werden, um mit der Fahrt für das Kabinenmodul CM1 fortzufahren.
• Der Integrationsprozess im Einzelnen:
• Die 18 zeigt das Transportmodul TM1, das eine lokale Komponenten- und Feature-Management-Integrationseinheit LCFMIU - im folgenden Kapitel als Einheit 1 bezeichnet - enthält, während das Kabinenmodul CM1 eine lokale Komponenten- und Feature-Management-Einheit LCFMU - im folgenden Kapitel als Einheit 2 bezeichnet - aufweist.
• In der gleichen dynamischen, semantisch korrekten und daher immer noch sehr flexiblen Art und Weise, wie sie zuvor in diesem Dokument beschrieben wurde, muss der Matchmaking-Prozess zwischen den Anforderungen der Software-Features an die Hardware und den Hardware-Fähigkeiten stattfinden. Nur die Software-Features, die eine positive Übereinstimmung aufweisen, werden aktiviert. Dieses Konzept muss in der ersten Phase auf den Integrationsprozess von verschachtelten Hardwaremodulen ausgeweitet werden. In der zweiten Phase muss die Integration mit dem eigentlichen Kunden, die später auch onboard erfolgt, berücksichtigt werden.
• Phase 1: Modulintegrationsprozess
• In Schritt S1) stellt die Einheit 1 eine allgemeine, kundenunabhängige Fähigkeitsspezifikation TMCS bereit und sendet diese als Teil des Backend-Systems 7 des Herstellers an die zentrale Komponenten- und Merkmalsverwaltungseinheit CCFMS. Sie enthält die vollständigen Fähigkeiten des Transportmoduls TM1, die das Transportmodul TM1 allen möglichen Modulen auf der nächstniedrigeren Integrationsstufe bietet, um einen ordnungsgemäßen Betrieb zu gewährleisten. Dies könnten z.B. Fähigkeiten für die Energiebereitstellung, manövrierbare Aspekte wie Beschleunigungsfähigkeit oder Wendekreise usw. und natürlich Fähigkeiten für den Grad der Autonomie sein.
• In Schritt S2) erstellt die Einheit 2 eine allgemeine, kundenunabhängige Spezifikation der Merkmalsanforderungen TMRS und sendet diese an das zentrale Komponenten- und Merkmalsmanagementsystem CCFMS. In dieser Spezifikation werden die vollständigen Fähigkeiten des Kabinenmoduls CM1 mit allen darin enthaltenen Benutzererfahrungsräumen UES#1 bis UES#4 angesprochen und alle Anforderungen aufgelistet, die das Kabinenmodul CM1 vom Modul auf der nächsten Integrationsstufe aufwärts, in diesem Fall dem Transportmodul TM1, benötigt, um einen ordnungsgemäßen Betrieb zu ermöglichen.
• Dies könnten z.B. Anforderungen an die Energieversorgung, Fahrfunktionen FF, wie Beschleunigungsbegrenzungen oder Wendekreise usw. und natürlich Anforderungen an den Grad der Autonomie sein, um das Maß an Privatsphäre, Gastfreundschaft und Entspannung abzuleiten, das den Passagieren während ihres Aufenthalts an Bord geboten werden kann.
• Bei einigen Implementierungen werden die Einzelheiten der hardwarebasierten Anforderungen und Fähigkeiten in Bestandsdatenbanken, wie der Produktflotten-Bestandsdatenbank PFID und der Kundendatenbank CD, gespeichert, und die physischen Instanzen melden nur ihre Identifikationsdaten ID (Hardware-Partnernummern usw.), und die zentrale Komponenten- und Merkmalsverwaltungseinheit CCFMS kann die Daten entsprechend abrufen.
• Das Backend-System 7 umfasst darüber hinaus ein RCMM-System RCMM (=Requirements-to-Capabilities Match-Maker).
• 19: Als nächstes verarbeitet das RCMM-System RCMM (=Requirements-to-Capabilities Match-Maker) die Analyse dieser beiden Spezifikationen TMCS, TMRS und generiert die Requirements-to-Capabilities Match-Ergebnisspezifikationen RCMRS von Kabinenmodul CM1 und TM1 und sendet sie in Schritt S3) an die Integrationseinheit 1) zurück. Abgeleitet von dieser Ergebnisspezifikation RCMRS entscheidet die Einheit 1, welche Merkmale M zwischen dem Transportmodul TM1 und dem Kabinenmodul CM1 aktiviert und „bereitstellbar“ sind und welche Merkmale M oder Anforderungen von dem Kabinenmodul CM1 nicht erfüllt werden können, und setzt sie daher auf „inaktiv“. Diese Informationen werden in Schritt S4) mit der Einheit 2 geteilt, und diese Einheit 2 entscheidet selbst, wie sie auf diese Informationen reagiert. Wenn sie den Dienstzustand ihrer eigenen Merkmale M beeinflusst, dann muss dies entsprechend eingestellt werden, und einige Merkmale M müssen möglicherweise auf „inaktiv“ gesetzt werden.
• Das Ergebnis dieses Prozesses könnte auch sein, dass entweder eines oder beide Module TM1, CM1 den Betrieb in dieser Kombination ablehnen, da sie ihren Service unter diesen Umständen nicht erfüllen kann bzw. können. Wenn dies der Fall ist, dann muss das zentrale Managementsystem der Transportmodule TM1 und aller anderen Untermodule in diesem Fall entsprechende Maßnahmen ergreifen. Die Einzelheiten hierzu sind nicht Gegenstand dieses Konzepts.
• Im Folgenden gehen wir davon aus, dass dieser Matchmaking-Prozess positiv verlaufen ist und die Kombination von dem Transportmodul TM1 und dem Kabinenmodul CM1 gültig und funktionsfähig ist.
• Phase 2: Verfahren zum Einsteigen der Passagiere
• In der zweiten Phase des Integrationsprozesses zur Vorbereitung des kundenzentrierten Verkehrsdienstes wird die Perspektive des Fahrgastes berücksichtigt. Da die Einheit 2 oder die lokale Komponenten- und Feature-Management-Einheit LCFMU jetzt mit den Möglichkeiten für das Kabinenmodul CM1 innerhalb des Transportmoduls TM1 „kalibriert“ ist, ist der restliche Einstiegsprozess derselbe wie im Konzept „ein dynamisches Kundenerfahrungsmanagementsystem für softwarebasierte Funktionen F in angeschlossenen Geräten“, während die erste Produktinstanz P1 in diesem Konzept das Kabinenmodul CM1 ist.
• Mehrfache Integration von Modulen:
• 20 zeigt ein weiteres Transportmodul TM2, das in der Lage ist, ein weiteres Kabinenmodul CABM1 und ein zusätzliches Frachtmodul CARM1 zu integrieren. Die Integration eines Frachtmoduls CARM1 ist konzeptionell genau die gleiche wie bei einem Kabinenmodul CM1. Das Frachtmodul CARM1 hat möglicherweise andere Attribute und Werte, die es für seinen Betrieb benötigt (z.B. in Bezug auf Beschleunigungs- und Schwingungsanforderungen oder Belüftungs- oder Klimabedingungen wie Temperatur, Feuchtigkeit usw.). In Analogie dazu gibt es in modernen Flugzeugen verschiedene Arten von Frachträumen, die z.B. in der Lage sind, lebende Tiere zu befördern, andere hingegen nicht. Ähnlich wie bei Passagierflugzeugen erlaubt dieses Konzept die Implementierung jedes Transportmoduls TM, das sich durch den Raum bewegt, entweder auf dem Land (Straßen oder Schienen), auf dem Wasser (Boote oder U-Boot-Schiffe) oder in der Luft (Drohnen, Hubschrauber, Flugzeuge usw.).
• Bei einigen Implementierungen können einige der vorgelagerten Prozessschritte während der Reservierungs- und Dispositionsphasen notwendig sein und vorgeladen und auf der Backend-Seite des Backend-Systems 7 durchgeführt werden, um einen planbaren Zustand zu erhalten, sobald die physischen Module in der realen Welt zusammenkommen. Dies ist wichtig für die Anwendung dieses Konzepts in logistischen und geschäftlichen Zusammenhängen. Andererseits ermöglicht es eine vollständige Flexibilität bei der Neuanordnung und Reorganisation von Reisen, da all diese Schritte automatisch von Computersystemen durchgeführt werden.
• In einigen anderen Implementierungen ist das Konzept in der Lage, verschachtelte Modularchitekturen zu unterstützen. Das bedeutet, dass ein Transportmodul TM selbst Teil eines größeren Integrationssystems sein kann, wie z.B. eine Fähre, ein Frachtflugzeug, ein Sattelschlepper, ein Zug, ein Untergrund- oder Unterwasser-Transportsystem oder sogar Raumtransportsysteme.
• Die mit der Erfindung verbundenen Vorteile bestehen insbesondere darin, dass Kundenmerkmale und damit alle möglichen Präferenzen für diese Merkmale M beim Wechsel der Produktinstanz P1 übergangsweise vorhanden sein können, was eine nahtlose Kundenerfahrung z.B. bei einer längeren Reise mit unterschiedlichen Mobilitätssystemen ermöglicht.
• Darüber hinaus können neue Möglichkeiten, neue oder verbesserte Dienstleistungen angeboten werden, die innerhalb der Benutzererfahrungsräume UES der Produkte P erlebbar sind. Ferner sind individuelle Benutzererfahrungen möglich für mehrsitzige Produkte P wie Busse, Taxis oder VAN-Shuttles, möglich. Ebenso können flexiblere Flottennutzungsmuster erreicht werden, z.B. wird eine Flotte von Liefer-VANs werktags von Auslieferungsmitarbeitern genutzt, und dieselben Fahrzeuge können für kundenspezifische Nutzungen von Dritten über das Wochenende gemietet werden.
• Auch sind fortschrittlichere Softwarefunktionen für bestimmte Kundengruppen, z.B. spezialisierte Logistikanwendungen für die Flotte eines Logistikanbieters oder spezielle Anwendungen für Taxiflotten usw. ermöglicht, die sowohl Front-End-Komponenten im Fahrzeug als auch Cloud-basierte Komponenten enthalten können, die sich nahtlos in das Front-End und damit in die Benutzererfahrung an Bord integrieren lassen. Auch beliebige Kombinationen mit anderen mobilen Geräten sind möglich.
• Ferner ist ein generischer Ansatz für die Entwicklung von Software-Features ermöglicht, die die Möglichkeiten des Benutzererfahrungsraumes UES moderner Luxus-Personenwagen oder anderer Transportsysteme wie Eisenbahnen, Flugzeuge, Busse, Lastwagen, VANs, Schiffe und Boote usw. voll ausschöpfen. Je nach dem Kontext und den Fähigkeiten des Benutzererfahrungsraumes UES, in dem die Benutzererfahrung des Software-Features stattfindet, kann das Software-Feature entsprechend konfiguriert und angepasst werden. Dies ist dasselbe Konzept, das auch beim sogenannten „Responsive Webdesign“ von Benutzeroberflächen auf zweidimensionalen Displays verwendet wird.
• Darüber hinaus wird ein Höchstmaß an Entkopplung von Hardware und Software ermöglicht, wenn es um die Benutzererfahrung geht. Kundenmerkmale und damit alle möglichen Präferenzen für diese Merkmale M können bei der Änderung von Produktinnenraumeinstellungen oder Szenarien A bis E, die das Verhalten des Fahrzeugs V1 bis V3 entsprechend ändern, vorübergehend sein.
• Auch können neue Möglichkeiten, wie neue oder verbesserte Dienstleistungen, angeboten werden, die innerhalb der Benutzererfahrungsräume UES der Produkte P in mehreren Hardware-aktivierten Szenarien A bis E erlebt werden können.
• Neue Geschäftsmodelle für z.B. Catering, Bewirtung etc. sind möglich, die sowohl an festen Standorten als auch auf Reisen erbracht werden können. Die Funktionen, die mit Sensordaten SD arbeiten, die aus Fahrgastinteraktionen generiert werden, können lose gekoppelt werden und ermöglichen so eine interdisziplinäre Onboard-Micro Service-Architektur für Benutzererfahrungsräume UES.
• Es können domänenübergreifende Funktionen und Anwendungen entwickelt werden, die den größtmöglichen Nutzen aus den verschiedenen Datenbereichen ziehen, einschließlich der KI-Technologie zur Unterstützung der Ziele der Anwendungen. Auf einer höheren Integrationsebene können alle verschiedenen passagierbezogenen Daten und Dienste zu einer kombinierten „Eigenverhalten“-Perspektive aggregiert und in das übergreifende Onboard-Kontextmanagementsystem integriert werden.
• Neue Möglichkeiten, neue oder verbesserte Dienste werden angeboten, die innerhalb der Benutzererfahrungsräume UES von Personenkraftwagen erlebbar sind, z.B. während sie innerhalb eines Drive-in-Kinos geparkt sind, und die in das externe Kinosystem integriert werden können. Darüber hinaus können diese Vorteile der Software-Flexibilität mit den Vorteilen der Hardware-Flexibilität kombiniert werden, wenn sie auf verschachtelte Hardware-Modul-Architekturen angewendet werden.
• Bezugszeichenliste

1

ganzheitliches Fahrzeugsystem

2,20

Fahrzeug

3

Eingabeeinheit

4

Sensor

5

Fahrzeugkomponente

6

Kommunikationsschnittstelle

7

Backend-System

8

externes Gerät

9

Speichereinheit

10

Fahrzeugassistenzsystem

11

Verarbeitungseinheit

12

Autokino

13

Transportintegrationssystem

A bis E

Szenario

AF, AF(Px), AF(Cx)

verfügbares Merkmal

APP

Anwendung

BED

Bedeutung

CABM1

weiteres Kabinenmodul

CARM1

zusätzliches Frachtmodul

C1

erster Benutzer

C2

zweiter Benutzer

C3

dritter Nutzer

C4

vierter Nutzer

Cx

alle Benutzer

CCA

Kino-Client-App

CCFMS

zentrale Komponenten- und Merkmalsverwaltungseinheit

CD

Kundendatenbank

CinSc

Kinobildschirm

CIM

Kabinenmodulinstanz

CL

Fahrzeuglinie

CM1

Kabinenmodul

CMS(UES#1) bis CMS(UES#4)

Kontextmanagementsystem

CON

Kontext

CON-DS

Kontextdatenspeicher

CSCS

Kinosteuerungssystem

CSCServ

Cinema Show Content Server

D1 bis D4

Domänenperspektive

F

Funktion

nF

neue Funktion

FF

Fahrzeugfunktion

F1 bis F4

Verarbeitungsschritt

FCMM

Feature-to-Capabilities Match-Maker-System

FPMRS

Feature-to-Product Match Result Spezifikation

HCDB

Hardware-Fähigkeitsdatenbank

ID

Interaktionsdaten

L1 bis L4

Hierarchie

LCFMIU

lokale Komponenten- und Feature-Management-Integrationseinheit

LCFMS

lokale Komponenten- und Merkmalsverwaltungseinheit

LCFMU

lokale Komponenten- und Feature-Management-Einheit

LUMU

lokale Benutzerverwaltungseinheit

M

Merkmal

MUEDC

Benutzererfahrungs-Drive-in-Kino

N

Szenario

OCMS

Onboard-KontextmanagementsystemP Produkt

P1

erste Produktinstanz

P2

zweite Produktinstanz

P3

dritte Produktinstanz

PFID

Produktflotten-Bestandsdatenbank

Px

Produktinstanz

RCMM

RCMM-System

RCMRS

Requirements-to-Capabilities Match-Ergebnisspezifikation

Set A bis Set F

Satz von Merkmalen und/oder Funktionen

SCDS

Show-Content-Datenspeicher

SD

Sensordaten

SFID

Software-Features-Inventory-Datenbank

S1) bis S6)

Schritt

T

TischTM, TM1, TM2 Transportmodul

TMI

Transportmodulinstanz

TMCS

allgemeine, kundenunabhängige Fähigkeitsspezifikation

TMRS

allgemeine, kundenunabhängige Spezifikation der Merkmalsanforderungen

UD1 bis UD4

Unterdomänenperspektive

UES

Benutzererfahrungsraum

UES#1 bis UES#4

Benutzererfahrungsraum

UESCS(P1)

Benutzererfahrungsraum-Fähigkeitsspezifikation

UESRS(F1)

UES-Anforderungsspezifikation

Ul

Benutzerschnittstelle

V1 bis V3

Fahrzeug mit eigenem Onboard-Kontextmanagementsystem

• 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 Nicht-Patentliteratur
• ISO 11783 [0116]

Claims (3)

1. Ganzheitliches Fahrzeugsystem (1) für mindestens ein Fahrzeug (2, 20) zur Konfiguration , Testung und/oder Steuerung mindestens eines Merkmals (M) und/oder mindestens einer Funktion (F) des Fahrzeugs (2, 20), umfassend mindestens eine Eingabeeinheit (3) zur Vorgabe von Interaktionsdaten (ID) durch einen Benutzer (C1 bis C3) und/oder ein externes Gerät, und/oder mindestens einen Sensor (4) zur Erfassung von Sensordaten (SD), dadurch gekennzeichnet, dass mittels der Interaktionsdaten (ID) und/oder der Sensordaten (SD) das Merkmal (M), insbesondere software-basierte und/oder hardware-basierte Merkmale, und/oder die Funktion (F), insbesondere software-basierte Funktionen, dynamisch individuell bzw. situationsbasiert generierbar, konfigurierbar und/oder anpassbar sind bzw. ist.
2. Ganzheitliches Fahrzeugsystem (1) nach Anspruch 1, dadurch gekennzeichnet, dass anhand des dynamisch individuell und/oder situationsbasiert anpassbaren Merkmals (M) und/oder der Funktion (F) mindestens ein Szenario (N) des Fahrzeugs (2, 20) und/oder mindestens einer Fahrzeugkomponente (5) und/oder mindestens einer Fahrzeugfunktion (FF) konfigurierbar und/oder steuerbar ist.
3. Ganzheitliches Fahrzeugsystem (1) nach Anspruch 2, dadurch gekennzeichnet, dass eine Kommunikationsschnittstelle (6) vorgesehen ist, mittels der das mindestens eine Szenario (N) des einen Fahrzeugs (2, 20) und/oder der mindestens einen Fahrzeugkomponente (5) und/oder der mindestens einen Fahrzeugfunktion (FF) des einen Fahrzeugs (2 oder 20) zumindest indirekt auf ein anderes Fahrzeug (20 oder 2) übertragbar ist.

Images