-
Die vorliegende Erfindung betrifft ein System für eine Datenverwaltung und Funktionsauslösung sowie ein Verfahren zum Betreiben eines solchen Systems.
-
Heutzutage sind in vielen Bereichen und Anwendungsgebieten verteilte softwaregesteuerte Systeme und Einrichtungen zu finden. Beispielsweise können Daten und Funktionen einzelner Kraftfahrzeuge durch ein Backend, also eine stationäre Servereinrichtung, verwaltet werden. Es findet aber üblicherweise auch eine lokale Daten- und Funktionsverwaltung auf Seiten des jeweiligen Kraftfahrzeugs statt. Dabei können sich eine ganze Reihe von Herausforderungen ergeben, beispielsweise eine begrenzte Rechenkapazität auf Seiten des Kraftfahrzeugs, eine enorme Vielfalt und Komplexität von Funktionsimplementierungen, Schnittstellen, Protokollen, Datenformatanforderungen, Software- und Hardwareversionen, Fahrzeugmodellen und/oder dergleichen mehr. Dadurch kann eine Nutzung, Pflege und Weiterentwicklung des Systems im Laufe der Zeit immer mehr erschwert werden. Dies kann insbesondere im Zusammenhang mit der derzeitigen Entwicklung zunehmend vernetzter und automatisierter Fahrzeuge von besonderer Bedeutung sein und werden, da derartige Fahrzeuge auf zunehmend mehr und komplexere Softwarelösungen angewiesen sind.
-
Eine Softwareapplikationen und Logik zum Modifizieren einer Konfiguration eines autonomen Fahrzeugs ist beispielsweise in der
US 10,334,050 B2 beschrieben. Darin werden basierend auf einer empfangenen Position eines Nutzergerätes Instruktionen generiert, die ein autonomes Fahrzeugsystem zu dieser Position senden, um das autonome Fahrzeugsystem dem Nutzer verfügbar zu machen, um diesen zu einem Ziel zu transportieren. Diese Instruktionen sowie mit dem Nutzer assoziierte Informationen werden an das autonome Fahrzeugsystem übermittelt. Diese Informationen umfassen Einstellungsinformationen zur Straßennutzung einschließlich mit dem Nutzer assoziierter Konfigurationsdaten. Letztere umfassen Einstellungen für ein aktives Dämpfungssystem des autonomen Fahrzeugsystems. Diese Konfigurationsdaten werden dann durch das autonome Fahrzeug verwendet, um einen Dämpfungsparameter des aktiven Dämpfungssystems zu modifizieren, bevor der Nutzer an der empfangenen Position in das autonome Fahrzeug einsteigt. Auf diese Weise soll eine Lösung bereitgestellt werden, die eine Implementierung autonomer Fahrzeuge ohne die Limitierung konventioneller Techniken ermöglichen soll.
-
Aufgabe der Erfindung ist es, einen besonders effizienten Betrieb eines softwaregesteuerten Systems zu ermöglichen.
-
Diese Aufgabe wird erfindungsgemäß durch die Gegenstände der unabhängigen Patentansprüche gelöst. Mögliche Ausgestaltungen und Weiterbildungen der vorliegenden Erfindung sind in den abhängigen Patentansprüchen, in der Beschreibung und in den Figuren offenbart.
-
Das erfindungsgemäße System umfasst einen stationären Teil und einen mobilen Teil, wobei letzterer insbesondere zur Verwendung in einem Kraftfahrzeug vorgesehen oder eingerichtet sein kann. Ebenso können aber andere Anwendungen oder Einsatzbereiche möglich sein. Die beiden Teile des Systems können hier jeweils Hardware- und Softwarekomponenten umfassen. Beide Teile des Systems umfassen jeweils eine kabellose Kommunikationseinrichtung für eine kabellose Kommunikation, beispielsweise via Mobilfunk oder dergleichen, und eine jeweilige Datenverarbeitungseinrichtung. Diese Datenverarbeitungseinrichtungen können beispielsweise einen computerlesbaren Datenspeicher, eine damit verbundene Prozessoreinrichtung, also etwa einen Mikrochip, Mikroprozessor oder Mikrocontroller, entsprechende Schnittstellen oder Verbindungen sowie eine Softwarekomponente, die beispielsweise auf dem Datenspeicher hinterlegt, also gespeichert und durch die Prozessoreinrichtung ausführbar sein kann, umfassen.
-
In der Datenverarbeitungseinrichtung jeden Teils des Systems ist ein vorgegebenes Datenmodell hinterlegt. Mit anderen Worten kann also ein gemeinsames Datenmodell vorgegeben sein, von dem individuelle Instanzen oder Kopien in jedem der Teile des Systems hinterlegt sind. Diese jeweiligen Instanzen oder Kopien des Datenmodells werden nachfolgend auch als lokale Datenmodelle bezeichnet. Ein Datenmodell kann im vorliegenden Sinne eine organisierte oder strukturierte Menge von Datenfeldern mit jeweils wenigstens einem Dateneintrag sein oder enthalten. Das Datenmodell kann dabei für eine bestimmte vorgegebene Domäne, also einen bestimmten Anwendungsbereich oder eine bestimmte Perspektive darauf, vorgegeben oder definiert sein. Eine solche Domäne kann beispielsweise Kraftfahrzeuge im Allgemeinen, die Kraftfahrzeugtechnik, ein Flottenmanagement und/oder dergleichen mehr umfassen oder beschreiben.
-
In wenigstens einer der Datenverarbeitungseinrichtungen ist eine Modifizierungsfunktion zum Verändern des jeweiligen lokalen, also in dieser Datenverarbeitungseinrichtung hinterlegten, Datenmodells implementiert. Durch diese Modifizierungsfunktion können beispielsweise einzelne Dateneinträge, also in den Datenfeldern des Datenmodells gespeicherte Werte, modifiziert werden. Dazu kann diese Modifizierungsfunktion beispielsweise durch eine andere Einrichtung, durch ein anderes System oder durch eine Bedienperson aufgerufen oder aktiviert werden. Diese Datenverarbeitungseinrichtung ist dabei dazu eingerichtet, durch die Modifizierungsfunktion bewirkte Veränderungen automatisch an die jeweils andere der Datenverarbeitungseinrichtungen, also an den jeweils anderen Teil des Systems zu senden. Mit anderen Worten können also die durch die Modifizierungsfunktion veränderten Dateneinträgen oder Werte sowie gegebenenfalls deren jeweilige Adresse, also eine jeweilige Angabe der zugehörigen Datenfelder des Datenmodells an die andere Datenverarbeitungseinrichtung bzw. den anderen Teil des Systems gesendet werden, insbesondere via der jeweiligen Kommunikationseinrichtung.
-
Wenigstens die jeweils andere der Datenverarbeitungseinrichtungen ist dazu eingerichtet, diese gesendeten Veränderungen, beispielsweise via ihrer Kommunikationseinrichtung, zu empfangen und automatisch in das lokale Datenmodell zu übernehmen. Mit anderen Worten ist diese andere Datenverarbeitungseinrichtungen bzw. dieser andere Teil des Systems also dazu eingerichtet, automatisch ein entsprechendes Update, das heißt eine Aktualisierung des lokalen Datenmodells durchzuführen. Wenigstens auf diesem lokalen Datenmodell ist wenigstens eine vorgegebene Anwendungsfunktion zum Bewirken oder Ausführen wenigstens einer vorgegebenen Steuermaßnahme für eine dem jeweiligen Teil des Systems zugeordnete technische Einrichtung implementiert. Diese Anwendungsfunktion ist dabei mit dem jeweiligen lokalen Datenmodell bzw. wenigstens einem Datenfeld oder Dateneintrag dieses lokalen Datenmodells verknüpft, sodass dessen Veränderung automatisch eine Ausführung oder Aktivierung der Anwendungsfunktion auslöst.
-
Grundsätzlich kann die vorliegende Erfindung in vielerlei unterschiedlichen technischen Anwendungen zum Einsatz kommen. Nachfolgend wird zur Erläuterung ohne Einschränkung von dem Beispiel oder Anwendungsfall ausgegangen, dass es sich bei dem stationären Teil des Systems um zumindest einen Teil eines Backends, also einer stationären Servereinrichtung, eines Rechenzentrums oder dergleichen und bei dem mobilen Teil um ein Kraftfahrzeug oder eine Einrichtung eines Kraftfahrzeugs handelt. In dem Datenmodell können dann beispielsweise ein Eigenschaften des Kraftfahrzeugs oder Daten für dessen Betrieb hinterlegt sein. Beispielsweise kann dann auf Seiten des Backends für eine Navigation des Kraftfahrzeugs eine Koordinatenangabe eines Navigationsziels oder eine Angabe bezüglich einer Verfügbarkeit oder eines Preises einer Tankstelle oder Ladestation verändert werden. Durch die Übernahme dieser Veränderungen in das fahrzeugseitige lokale Datenmodell kann die dortige, mit entsprechenden Teilen oder Datenfeldern des Datenmodells verknüpfte Anwendungsfunktion automatisch ausgeführt werden. Dadurch kann als Steuermaßnahme beispielsweise die Navigation oder Routenführung des Kraftfahrzeugs aktiviert oder modifiziert werden, eine Anzeige eines entsprechenden Hinweises durch eine Anzeigeeinrichtung des Kraftfahrzeugs ausgelöst oder durchgeführt werden, eine Temperierung oder Konditionierung einer Traktionsbatterie durchgeführt oder angepasst werden und/oder dergleichen mehr. Ebenso können entsprechende Datenfelder und Anwendungsfunktionen bzw. Steuermaßnahmen für prinzipiell beliebige Eigenschaften, Daten oder Funktionen des Kraftfahrzeugs implementiert sein oder werden.
-
Wie an anderer Stelle näher erläutert wird, ist ebenso ein Datenfluss in umgekehrter Richtung möglich, sodass beispielsweise auf Seiten des Kraftfahrzeugs durch eine dort implementierte Modifizierungsfunktion das lokale Datenmodell verändert werden kann. Beispielsweise kann eine aktuelle Position oder ein aktueller Zustand, beispielsweise bezüglich einer Fahrbereitschaft oder einer Verriegelung des Kraftfahrzeugs, hinsichtlich eines detektierten Fehlers und/oder dergleichen mehr, in das fahrzeugseitiges lokale Datenmodell eingetragen werden. Entsprechende Daten bzw. Veränderungen können dann in dem Backend in das dortige lokale Datenmodell übernommen werden und eine dort implementierte, damit verknüpfte Anwendungsfunktion auslösen. Als resultierende Steuermaßnahme kann dann beispielsweise eine vorgegebene Auswertungsroutine aktiviert werden, eine Benachrichtigung an ein mobiles Endgerät, beispielsweise eine Smartphone eines Besitzers des Kraftfahrzeugs oder dergleichen, gesendet werden und/oder dergleichen mehr.
-
Die genannten technischen Einrichtungen können also in dem hier betrachteten Beispiel nahezu beliebige technische Einrichtungen des Kraftfahrzeugs bzw. des Backends oder eines dieses umfassenden Systems sein.
-
Durch die vorliegende Erfindung wird ein datenzentrischer Ansatz für ein Design bzw. eine Implementierung eines softwaregesteuerten Systems vorgeschlagen, bei dem eine Funktionsmodellierung auf Basis eines einheitlichen Datenmodells vorgesehen ist. Hier wird also ein einheitliches Datenmodell und dessen Nutzung, beispielsweise zumindest innerhalb einer jeweiligen vorgegebenen Domäne, in den Mittelpunkt gestellt, beispielsweise im Gegensatz zu einer Sammlung von Funktionsschnittstellen. Dies ermöglicht es, über einzelne Systemteile zumindest der jeweiligen Domäne hinweg mit einem einheitlichen Verständnis der genutzten Daten zu arbeiten, insbesondere ohne dass dafür in sämtlichen Teilen des Systems sämtliche auch in den anderen Teilen des Systems implementierten Funktionen sowie entsprechende Schnittstellen bekannt, also ebenfalls implementiert oder dupliziert sein müssten.
-
Bei bisher üblichen und verbreiteten Implementierungen oder Herangehensweisen verteilter, softwaregesteuerte Systeme findet unter Systemteilen bzw. einzelnen Applikationen oder Nutzern des Systems ein Datenaustausch sowie ein Anstoß bzw. eine Ausführung von Funktionen oftmals durch jeweils für den individuellen Zweck implementierte Schnittstellen und Funktionen statt und wird nicht über eine zentrale gemeinsame Stelle - wie sie in der vorliegenden Erfindung durch das vorgegebene Datenmodell gegeben ist - abgebildet oder angestoßen. Durch diese bisher übliche Art der Implementierung wird, sofern überhaupt ein gemeinsames Datenmodell vorhanden ist, dessen Hoheit durch die zusätzliche Bereitstellung von speziellen eigenständigen Funktionen untergraben, sodass die Nutzung und Pflege des gesamten Systems erschwert und dessen Komplexität im Vergleich zur vorliegenden Erfindung in letztlich unnötiger Weise erhöht wird. Bei bisherigen Ansätzen können zudem für individuelle Funktionen oder Schnittstellen individuelle spezifische Datenmodelle verwendet werden bzw. vorgegeben sein. Dadurch muss beispielsweise ein Nutzer, der eine Funktion aus einem Backend heraus in einem Fahrzeug triggern, also auslösen will, sowohl das spezifische Datenmodell als auch die eigentliche vom Fahrzeug bereitgestellte bzw. im Fahrzeug implementierte Funktion und/oder eine entsprechende Schnittstelle zum Ansprechen der individuellen Funktion und/oder zum Übermitteln von Daten oder Datenveränderungen für das spezifische Datenmodell kennen. Es müssen also im Backend beispielsweise Informationen hinsichtlich jeweiliger Anforderungen an ein Daten- oder Befehlsformat hinterlegt sein und gepflegt werden sowie gegebenenfalls entsprechende Funktionen oder Schnittstellen implementiert sein. Dabei kann erschwerend hinzukommen, dass über unterschiedliche Versionen der spezifischen Datenmodelle und/oder der bereitgestellten Funktionen zusätzliche neue oder abgewandelte Schnittstellen entstehen oder beispielsweise über verschiedene Fahrzeuge hinweg gegeben sein können. Dadurch kann ein Umfang und Aufwand zu wartender und zu implementierender Funktionen und Schnittstellen in komplexen Systemen rasant ansteigen.
-
Selbst bisherige Herangehensweisen oder Implementierungen, die ein einheitliches Datenmodell als Grundlage für mehrere Funktionen nutzen, realisieren den datenzentrischen Ansatz nur hinsichtlich des Datenmodells, nicht aber hinsichtlich der Funktionen. Mit anderen Worten wird zwar gegebenenfalls ein einheitliches Datenmodell genutzt, die Funktionen werden jedoch nicht damit verknüpft bzw. direkt auf diesem Datenmodell implementiert oder modelliert. Vielmehr werden die einzelnen Funktionen weiterhin separat oder individuell implementiert und durch jeweilige Schnittstellen angesprochen oder aufgerufen. Damit werden also unterschiedliche Funktionen gegebenenfalls über unterschiedliche Schnittstellentechnologien separat bzw. unabhängig voneinander entwickelt, implementiert und versioniert, was wie beschrieben zu einer im Laufe der Zeit ansteigenden Vielfalt von Schnittstellen, Standards, Formatanforderungen und/oder dergleichen mehr führen kann und zudem Kompatibilitätsprobleme mit sich bringen kann - sowohl fahrzeugseitig als auch auf Seiten des Backends.
-
Bei bisherigen Ansätzen bestehen also die Probleme, dass Funktionen und Datenmodell getrennt sind, wodurch eine höhere Komplexität und ein erhöhter Entwicklungsaufwand entsteht, eine zusätzliche Versionierung und ein zusätzlicher Abgleich zwischen genutztem Datenmodell und Funktionen notwendig ist und Funktionen oder entsprechende Schnittstellen in allen Teilen des Systems entsprechend einer jeweils verwendeten Ausführungslogik, gegebenenfalls auch über mehrere Versionen und Datenmodelle hinweg, implementiert werden müssen.
-
All diesen beschriebenen Herausforderungen, Schwierigkeiten und Problemen bisheriger Ansätze oder Implementierungen kann durch die vorliegende Erfindung begegnet werden. Dazu wird hier vorgeschlagen, dass alle Teile des Systems, also etwa das Backends und das Kraftfahrzeug bzw. mehrere durch das Backend verwaltete Kraftfahrzeuge, sich ein gemeinsames, also einheitliches Datenmodell teilen. Dabei sind innerhalb dieses Systems auszuführende Anwendungsfunktionen auf diesem Datenmodell modelliert, sodass bei der Kommunikation zwischen den Teilen des Systems, also etwa zwischen dem Backend und einem Kraftfahrzeug oder umgekehrt, keine zusätzliche Implementierung von Funktionsschnittstellen zum direkten Ansprechen individueller Funktionen oder Datenmodelle notwendig ist. Auf dem Datenmodell modellierte, also darauf implementierte bzw. mit diesem oder einzelnen Datenfeldern oder Dateneinträgen von diesem verknüpfte Funktionen können allein durch das Ändern des Datenmodells, also der einzelnen Datenfelder oder Dateneinträge bzw. von Zuständen von für die jeweilige Funktion verantwortlichen oder modellierten, also mit der jeweiligen Funktion verknüpften Datenpunkten in dem jeweiligen Systemteil ausgelöst oder bedient werden. Die vorliegende Erfindung beruht also auf einem Konzept, in welchem Anwendungsfunktionen auf Basis des einheitlichen Datenmodells modelliert bzw. auf dieses gemapped, also durch eine vorgegebene Abbildung oder Verknüpfung verbunden sind. Dadurch ist es nicht mehr notwendig, zusätzliche Funktionen oder Funktionsschnittstellen in dem sendenden Teil des Systems, durch den die Veränderungen des Datenmodells gesendet werden, für die Nutzung oder Ausführung entsprechender Anwendungsfunktionen zu implementieren oder in dem empfangenden Teil des Systems bereitzustellen.
-
Gemäß der vorliegenden Erfindung müssen dann für eine Aktivierung oder Auslösung einer Anwendungsfunktion in einem anderen Teil des Systems lediglich die Veränderungen des Datenmodells an diesen Teil gesendet werden, nicht aber spezifische Aktivierungen oder Parameter für individuelle Anwendungsfunktion. Dadurch kann gegebenenfalls ein zu übertragendes Datenvolumen sowie eine Fehleranfälligkeit reduziert werden.
-
Ebenso kann eine Anwendungsfunktion bzw. deren Ausführung gegebenenfalls ausgelöst werden, ohne dass das Datenmodell verändert wird, indem beispielsweise Angaben oder Adressen entsprechender Teile, also Datenfelder oder Dateneinträge des Datenmodells gesendet werden. Mit anderen Worten kann dann wenigstens ein Teil des Systems bzw. dessen Datenverarbeitungseinrichtung dazu eingerichtet sein, bei einem Empfang von Angaben oder Adressen einzelner Datenfelder oder Dateneinträge des Datenmodells die wenigstens eine damit verknüpfte Anwendungsfunktion auszulösen, auch wenn keine Veränderungen entsprechender Dateneinträge oder Werte empfangen werden bzw. empfangene Daten, also Dateneinträge oder Werte, den bereits in dem auf empfängerseitigen lokalen Datenmodell vorhandenen Daten entsprechend. Dies ermöglicht es beispielsweise zu einem bestimmten Zeitpunkt gezielt einen bestimmten Zustand herzustellen bzw. eine Ausführung einer bestimmten Anwendungsfunktion sicherzustellen oder zu garantieren.
-
Die vorliegende Erfindung ermöglicht im Vergleich zu bisherigen Ansätzen oder Implementierungen eine reduzierte Anzahl und Komplexität von Schnittstellen, insbesondere eine Einsparung individueller, also funktionsspezifischer Funktionsschnittstellen, da Anwendungsfunktionen bzw. durch das Datenmodell gesteuerte Applikationen lediglich auf Basis des Datenmodells arbeiten können, also beispielsweise keine separaten Aufrufe benötigen. Durch die vorliegende Erfindung kann auch einer Inkompatibilität von Schnittstellen, Versionen, Teilen des Systems und externer Einrichtungen oder Nutzer vorgebeugt werden, da das genutzte Datenmodell in der genutzten Version und dem angebotenen Umfang stets konsistent ist bzw. mit im Vergleich zu bisherigen Ansätzen signifikant reduziertem Aufwand konsistent gehalten werden kann. Zudem ermöglicht die vorliegende Erfindung durch die Reduzierung auf die Nutzung des Datenmodells zur Steuerung oder zum Ansprechen der Anwendungsfunktion eine Entkopplung einer Anwendungsfunktion bzw. deren Nutzung oder Implementierung oder technischer Umsetzung in den verschiedenen Teilen des Systems, also auf Aufrufer- oder Senderseite einerseits und Empfängerseite andererseits.
-
In einer möglichen Ausgestaltung der vorliegenden Erfindung umfasst das Datenmodell eine Vielzahl von taxonomisch oder ontologisch organisierten Datenfelder oder Dateneinträgen, die Eigenschaften und/oder Zustände des Kraftfahrzeugs angeben. Mit anderen Worten kann in dem Datenmodell also ein hierarchisches Klassifikationsschema implementiert sein, in oder gemäß dem die Dateneinträge nach vorgegebenen Kriterien klassifiziert oder kategorisiert sind. Zusätzlich oder alternativ kann das Datenmodell Inferenz- oder Integritätsregeln umfassen, die verschiedene Dateneinträge miteinander verknüpfen. Dadurch können Schlussfolgerungen, Gültigkeits- oder Plausibilitätsprüfungen oder komplexes Wissen in dem Datenmodell repräsentiert oder implementiert werden. Dies ermöglicht die Implementierung komplexer Systeme und Anwendungsfunktionen trotz des Verzichts auf funktionsspezifische Schnittstellen und individuell angepasste Datenmodelle. Beispielsweise kann das Kraftfahrzeug bzw. dessen Eigenschaften und/oder Zustände in dem Datenmodell hierarchisch repräsentiert werden, wobei eine oberste Schicht das gesamte Fahrzeug, eine darunterliegende Schicht Fahrzeugeigenschaften, gegliedert in Komponenten, wie beispielsweise eine Karosserie, ein Fahrwerk, eine Sensorik, und dergleichen repräsentieren kann. Die Eigenschaften bzw. Komponenten können dabei ihrerseits weiter hierarchisch untergliedert sein. So können beispielsweise der Komponente Fahrzeuginnenraum als Subkomponenten mehrere Sitzreihen, jeder Sitzreihe als Subkomponenten ein oder mehrere Einzelsitze und einem Einzelsitz beispielsweise ein oder mehrere Schalt- oder Sensorzustände zugeordnet oder untergeordnet sein. Ein individueller Schalt- oder Sensorzustand kann beispielsweise durch einen individuellen Dateneintrag, beispielsweise einen bestimmten numerischen oder booleschen Wert, beispielsweise „An/Aus“ oder beispielsweise „Schaltposition 3 von 10“ oder dergleichen, repräsentiert sein. Als Veränderung des Datenmodells kann dann beispielsweise ein solcher individueller Dateneintrag geändert werden, beispielsweise von „Aus“ nach „An“ oder von „3“ nach „5“ oder dergleichen.
-
In einer weiteren möglichen Ausgestaltung der vorliegenden Erfindung weist wenigstens der zum Empfangen der Veränderungen eingerichtete Teil des Systems spezifisch dafür eine Datenübertragungsschnittstelle auf, die unabhängig von der wenigstens einen Anwendungsfunktion ist. Mit anderen Worten kann also eine generische Datenübertragungsschnittstelle für das Datenmodell vorgegebenen bzw. implementiert sein, über die veränderte Daten übermittelt bzw. empfangen und in das jeweilige lokale Datenmodell übernommen werden können. Diese Datenübertragungsschnittstelle kann dabei nur für eine solche Datenübertragung bzw. Übernahme von Daten oder Veränderungen eingerichtet sein und dementsprechend nur einen Zugriff auf das Datenmodell selbst ermöglichen oder implementieren. Insbesondere kann die Datenübertragungsschnittstelle also keinen direkten Aufruf der wenigstens einen auf dem Datenmodell implementierten Anwendungsfunktion ermöglichen oder bereitstellen. Dadurch kann die Datenübertragungsschnittstelle besonders einfach sein und auch bei Veränderung bestehender Anwendungsfunktion oder Implementierung neuer Anwendungsfunktionen unverändert bleiben. Insbesondere kann die Datenübertragungsschnittstelle für sämtliche Teile des Systems identisch sein bzw. in allen Teilen des Systems verwendet oder implementiert werden. Auf diese Weise kann ein Implementierungs- und Wartungsaufwand für das erfindungsgemäße System besonders gering gehalten werden.
-
In einer weiteren möglichen Ausgestaltung der vorliegenden Erfindung ist die wenigstens eine Anwendungsfunktion für einen direkten Aufruf über die Kommunikationseinrichtung unzugänglich. Mit anderen Worten ist die Anwendungsfunktion also von außerhalb des jeweiligen Teils des Systems betrachtet versteckt oder unsichtbar, also nicht nach außen hin, etwa über eine entsprechende Funktionsschnittstelle, exponiert. Die wenigstens eine Anwendungsfunktion ist also nicht über eine entsprechende jeweilige Schnittstelle direkt ansprechbar oder ausführbar, sondern wird nur aufgrund einer Veränderung des Datenmodells oder zumindest einer Übermittlung einer Angabe oder Referenz zu einem bestimmten Datenfeld oder Eintrag ausgeführt. Dadurch kann die wenigstens eine Anwendungsfunktion bzw. deren Implementierung von anderen Teilen des Systems entkoppelt werden, ein Implementierungs-, Wartungs- und Versionierungsaufwand für eine entsprechende Funktionsschnittstellen eingespart und gegebenenfalls eine exponierte Angriffsfläche des Systems reduziert, also dessen Sicherheit verbessert werden.
-
In einer weiteren möglichen Ausgestaltung der vorliegenden Erfindung sind beide bzw. alle Teile des Systems für eine bidirektionale Kommunikation eingerichtet. Mit anderen Worten können die einzelnen Teile des Systems also über ihre jeweilige Kommunikationseinrichtung sowohl Daten senden als auch Daten empfangen. Wenigstens ein empfangender Teil des Systems ist dann dazu eingerichtet, auf den Empfang und die Übernahme der Veränderungen des Datenmodells hin automatisch eine dazu korrespondierende Antwort zu erzeugen und an den jeweiligen sendenden Teil des Systems, der die jeweiligen Veränderungen des Datenmodells gesendet hat, zurückzusenden. Dieser sendende Teil des Systems ist dann dazu eingerichtet, diese Antwort zu empfangen und anhand daran die durch den anderen, empfangenden Teil des Systems durchgeführten Veränderungen des Datenmodells zu validieren. Der sendende Teil ist weiter dazu eingerichtet, erst bei erfolgreicher Validierung die ursprünglichen, gemäß den ursprünglich gesendeten Veränderungen zu verändernden ursprünglichen, also vor der Veränderung gegebenen Daten zu verwerfen. Die Validierung kann beispielsweise unter Berücksichtigung der bzw. durch Abgleich mit den auf Seiten des sendenden Teils vorgenommenen Veränderungen des lokalen Datenmodells bzw. der dortigen lokalen aktualisierten und/oder ursprünglichen Version des lokalen Datenmodells durchgeführt werden. Dazu kann die Antwort beispielsweise einen aus den Veränderungen, gegebenenfalls in Abhängigkeit von den ursprünglichen Daten bzw. dem ursprünglichen Zustand des Datenmodells, berechneten Hashwert oder dergleichen umfassen. Dies ermöglicht die Validierung mit einem besonders geringem Datenübertragungsaufwand. Durch die hier vorgeschlagene automatische Validierung und das bis zu deren erfolgreicher Durchführung vorgesehene Beibehalten der ursprünglichen Daten, also der ursprünglichen, vor der Veränderung gegebenen Version oder des ursprünglichen Zustands des Datenmodells, kann automatisch sichergestellt werden, dass die lokalen Datenmodelle der einzelnen Teile des Systems konsistent zueinander bleiben und zudem eine Absicherung gegen Datenübertragungsfehler realisiert werden.
-
In einer weiteren möglichen Ausgestaltung der vorliegenden Erfindung sind beide bzw. mehrere oder alle Teile des Systems für eine bidirektionale Kommunikation eingerichtet. In den Datenverarbeitungseinrichtungen dieser Teile des Systems ist dann wenigstens eine Modifizierungsfunktion zum Verändern des jeweiligen lokalen Datenmodells implementiert. Zudem ist dann auf den lokalen Datenmodellen dieser Teile des Systems jeweils wenigstens eine vorgegebene Anwendungsfunktion zum Bewirken oder Ausführen einer vorgegebenen Steuermaßnahme für eine dem jeweiligen Teil des Systems zugeordnete technische Einrichtung implementiert. Mit anderen Worten ist das System bzw. sind die Teile des Systems für eine Durchführung der an anderer Stelle nur für eine Richtung beschriebenen Abläufe in beiden, mehreren oder allen Richtungen eingerichtet. In diesem Sinne können die Teile des Systems also symmetrisch sein. Dabei können die in unterschiedlichen Teilen des Systems implementierten Anwendungsfunktionen ganz oder teilweise gleich oder unterschiedlich sein. Durch die hier vorgeschlagene Möglichkeit, bidirektionale Veränderungen des Datenmodells zu übertragen und dadurch auf beiden, mehreren oder allen Seiten bzw. Teilen des Systems eine Ausführung einer dort implementierten Anwendungsfunktion auszulösen, können komplexe Abläufe oder Funktionsketten sowie Sicherheitsfunktionen besonders einfach und robust realisiert werden.
-
In einer weiteren möglichen Ausgestaltung der vorliegenden Erfindung sind beide bzw. mehrere oder Teile des Systems für eine bidirektionale Kommunikation eingerichtet. Wenigstens ein empfangender Teil des Systems ist dann dazu eingerichtet, aus der dortigen Ausführung der Anwendungsfunktion resultierende Veränderungen des lokalen Datenmodells automatisch zumindest an den jeweils sendenden Teil des Systems zu übermitteln. Dieser sendende Teil des Systems ist dann dazu eingerichtet, diese resultierenden Veränderungen zu empfangen und automatisch in das lokale Datenmodell zu übernehmen. Mit anderen Worten können also auch komplexe oder auf das Datenmodell zurückverweisende oder rückgekoppelte Anwendungsfunktionen implementiert und ausgeführt werden und dennoch die Konsistenz der Datenmodelle in beiden, mehreren oder allen Teilen des Systems gewahrt werden. Am Beispiel der Navigation kann beispielsweise durch den sendenden Teil eine Veränderung einer Zielposition, also eines Navigationsziel für das Kraftfahrzeug übermittelt werden. Dadurch kann in dem empfangenden Teil eine damit verknüpfte Anwendungsfunktion, die einen Navigationsprozess betrifft oder auslöst, automatisch ausgeführt werden. Daraus kann eine veränderte Position des Kraftfahrzeugs resultieren, beispielsweise während auf der Fahrt zu dem Navigationsziel oder bei Erreichen des Navigationsziels. Diese veränderte Position kann dann automatisch in das lokale Datenmodell geschrieben werden - sei es durch die jeweilige Anwendungsfunktion selbst oder über einen automatischen Aufruf einer entsprechenden Modifizierungsfunktion. Gemäß der hier vorgeschlagenen Ausgestaltung der Erfindung ist das System dann dazu eingerichtet, die derart aktualisierte Position des Kraftfahrzeugs automatisch auch an den ursprünglichen sendenden Teil des Systems zu übermitteln, sodass dort dann also ebenfalls die jeweils aktuelle Position des Kraftfahrzeugs hinterlegt sein oder werden kann.
-
In einer weiteren möglichen Ausgestaltung der vorliegenden Erfindung umfasst der stationäre Teil des Systems mehrere Datenmodelle für unterschiedliche Kraftfahrzeuge. Diese mehreren Datenmodelle können separat vorliegen bzw. hinterlegt sein oder beispielsweise unterschiedliche Abschnitte oder Bereiche oder Zweige eines entsprechend umfassenderen Gesamtdatenmodells sein oder bilden. Der stationäre Teil des Systems ist dann dazu eingerichtet, bei einer Kommunikation mit einem bestimmten mobilen Teil des Systems nur dasjenige Datenmodell zu verwenden, dass auch in der Datenverarbeitungseinrichtungen dieses mobilen Teils des Systems hinterlegt ist. Ein Verwenden dieses Datenmodells kann dabei bedeuten, dass nur dieses Datenmodell aus einem Langzeitspeicher geladen wird, dass durch den stationären Teil nur Veränderungen dieses Datenmodells an den jeweiligen mobilen Teil des Systems gesendet werden, auch wenn es weitere Veränderungen in anderen Datenmodellen ergibt, dass nur dieses Datenmodell für die an anderer Stelle genannte Validierung berücksichtigt wird und/oder dass auf von dem jeweiligen mobilen Teil des Systems gesendeten Veränderungen hin auf Seiten des stationären Teils eine Übernahme solcher Veränderungen nur in dieses Datenmodell zugelassen wird und/oder dergleichen mehr. Auf diese Weise können komplexe Systeme mit mehr als zwei mobilen Teilen und/oder mehreren unterschiedlichen Datenmodellen oder Datenmodellversionen konsistent, zuverlässig und robust betrieben oder verwaltet werden. Zudem können Kompromittierungen des Datenmodells bzw. der Datenmodelle vermieden und gegebenenfalls eine größere Performanz bzw. ein reduzierter Ressourcenbedarf des Systems erreicht werden.
-
In einer weiteren möglichen Ausgestaltung der vorliegenden Erfindung ist das System dazu eingerichtet, bei einer Kommunikation zwischen den Teilen des Systems zunächst das jeweils verwendete Datenmodell zu identifizieren, bevor Veränderungen gesendet oder übernommen werden. Dazu kann eine Identifikation, also beispielsweise eine Versionsnummer oder Identifikationsnummer, des Datenmodells, auf dem die zu sendenden Veränderungen basieren und/oder in das gesendete bzw. zu sendende Veränderungen zu übernehmen sind bzw. übernommen werden dürfen, übermittelt oder zwischen den Teilen des Systems ausgetauscht werden. Auf diese Weise kann besonders zuverlässig sichergestellt werden, dass die Datenmodelle auch dann konsistent gehalten werden, wenn es in dem System mehrere unterschiedliche Datenmodelle oder Datenmodellversionen gibt. Zudem können auf diese Weise zuverlässig unbeabsichtigte Auslösungen von Anwendungsfunktionen vermieden werden, wodurch eine Sicherheit im Betrieb des Systems verbessert werden kann. Die Identifikation des Datenmodells kann beispielsweise aus dessen Struktur ermittelt werden, beispielsweise als Hashwert oder dergleichen, sodass eine veränderte Struktur, beispielsweise ein zusätzliches Datenfeld oder dergleichen, zu einer veränderten Identifikation führt. Dadurch, dass Veränderungen nur bei übereinstimmender Identifikation der lokalen Datenmodelle beider kommunizierender Teile des Systems übernommen werden, kann sichergestellt werden, dass diese Veränderungen zu einer bestimmungsgemäßen Aktualisierung des jeweiligen lokalen Datenmodells auf des jeweiligen empfangenden Teils des Systems führen. Wird hingegen festgestellt, dass die lokalen Datenmodelle der kommunizierenden Teile des Systems unterschiedliche Identifikationen aufweisen, kann beispielsweise der Prozess der Übermittlung von Veränderungen abgebrochen werden. Ebenso kann dann beispielsweise eine Versionsaktualisierung des Datenmodells angestoßen oder einem jeweiligen Nutzer vorgeschlagen werden.
-
Ein weiterer Aspekt der vorliegenden Erfindung ist ein Verfahren zum Betreiben eines erfindungsgemäßen Systems. In dem Verfahren wird durch Ausführen einer vorgegebenen Modifizierungsfunktion das lokale Datenmodell eines sendenden Teils des Systems verändert. Daraufhin werden entsprechende Veränderungen automatisch über eine kabellose Kommunikationsverbindung an den oder einen anderen, empfangenden Teil des Systems gesendet. Die Veränderungen werden diesem wenigstens einen empfangenden Teil des Systems automatisch in das dortige lokale Datenmodell übernommen. Dadurch wird dort, also in dem wenigstens einen empfangenden Teil des Systems eine automatische Ausführung wenigstens einer vorgegebenen mit dem dortigen lokalen Datenmodell verknüpften Anwendungsfunktion zum Bewirken einer vorgegebenen Steuermaßnahme für eine dem empfangenden Teil des Systems zugeordnete technische Einrichtung ausgelöst. Das erfindungsgemäße Verfahren kann als weitere, gegebenenfalls optionale Verfahrensschritte einige oder alle der im Zusammenhang mit dem erfindungsgemäßen System beschriebenen Schritte, Maßnahmen oder Abläufe umfassen. Das erfindungsgemäße Verfahren kann beispielsweise als Betriebs- oder Computerprogramm implementiert sein, das in einem computerlesbaren Datenspeicher des Systems gespeichert sein und zur Anwendung oder Ausführung des Verfahrens durch eine oder mehrere Datenverarbeitungseinrichtungen, insbesondere Prozessoreinrichtungen, des Systems ausgeführt werden kann. Ein solches Computerprogramm sowie ein computerlesbarer Datenspeicher, in oder auf dem ein solches Computerprogramm gespeichert ist, können ihrerseits eigene Aspekte der vorliegenden Erfindung bilden.
-
Weitere Merkmale der Erfindung können sich aus den Ansprüchen, den Figuren und der Figurenbeschreibung ergeben. Die vorstehend in der Beschreibung genannten Merkmale und Merkmalskombinationen sowie die nachfolgend in der Figurenbeschreibung und/oder in den Figuren allein gezeigten Merkmale und Merkmalskombinationen sind nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar, ohne den Rahmen der Erfindung zu verlassen.
-
Die Zeichnung zeigt in:
- 1 eine schematische Darstellung zur Veranschaulichung eines Datenmodells;
- 2 eine schematische Darstellung zur Veranschaulichung eines datenmodellbasierten Systems; und
- 3 eine schematische Darstellung zur Veranschaulichung einer datenmodellbasierten Funktionsauslösung.
-
In den Figuren sind gleiche und funktionsgleiche Elemente mit den gleichen Bezugszeichen versehen.
-
1 zeigt eine schematische Darstellung zur Veranschaulichung eines Datenmodells 10. Dieses Datenmodell 10 umfasst mehrere Datenfelder 12, von denen der Übersichtlichkeit halber hier nur einige explizit gekennzeichnet sind. Die Datenfelder 12 sind in einer vorgegebenen Struktur, hier rein beispielhaft in einer hierarchischen Baumstruktur, angeordnet, also organisiert. Die einzelnen Datenfelder 12 können beispielsweise jeweils wenigstens einen Aspekt, eine Eigenschaft, einen Zustand oder einen Wert betreffen, beschreiben oder beinhalten. Auf diesem Datenmodell 10 können eine oder mehrere Funktionen modelliert oder implementiert sein. Eine solche Funktion kann mit einem oder mehreren der Datenfelder 12 verknüpft sein, sodass sie durch eine Veränderung des jeweiligen Datenfeldes 12 bzw. von dessen Inhalt oder Wert getriggert, also ausgelöst wird.
-
Beispielhaft sind hier zwei erste Datenfelder 14 gekennzeichnet, die zur Ausführung einer ersten Funktion benötigte Datenfelder 12 oder Datenpunkte, also Dateneinträge des Datenmodells 10 darstellen. Diese erste Funktion wird hier also über diese zwei ersten Datenfelder 14 modelliert, ist also mit diesen beiden ersten Datenfeldern 14 verknüpft.
-
Als weiteres Beispiel sind drei zweite Datenfelder 16 gekennzeichnet, die mit einer zweiten Funktion verknüpft sind.
-
Ebenso sind andere Strukturen oder Repräsentation des Datenmodells 10 möglich. Beispielsweise können mit einem der Datenfelder 12 mehrere Funktionen verknüpft sein.
-
Das Datenmodell 10 kann über eine Datenverarbeitungsschnittstelle angesprochen werden, um beispielsweise Datenveränderungen, insbesondere also Veränderungen der in einem oder mehreren der Datenfelder 12 gespeicherten Daten oder Werte, in das Datenmodell 10 einzubringen. Ebenso können Veränderungen des Datenmodells 10 über diese oder eine entsprechende Schnittstelle gesendet oder kommuniziert werden, beispielsweise, zumindest indirekt, an einen anderes Datenmodell.
-
2 zeigt eine schematische Darstellung zur Veranschaulichung eines datenmodellbasierten Systems 18. Dieses System 18 umfasst hier einen stationären Teil 20 und einen davon separaten Teil mobilen Teil 22. Der stationäre Teil 20 kann beispielsweise zumindest Teil einer Servereinrichtung, also eines Backends sein, während der mobile Teil beispielsweise zumindest Teil eines Kraftfahrzeugs sein kann. Zwischen dem stationären Teil 20 und dem mobilen Teil 22 können über eine kabellose Datenverbindung, beispielsweise eine Mobilfunkverbindung 24, Daten ausgetauscht werden.
-
In dem stationären Teil 20 ist vorliegend ein Backenddatenmodell 26 hinterlegt, während in dem mobilen Teil 22 ein fahrzeugseitiges Datenmodell 28 hinterlegt ist. Das Backenddatenmodell 26 und das fahrzeugseitiges Datenmodell 28 können gleich sein, also lokale Instanzen oder Kopien eines einzigen, gemeinsamen oder einheitlichen Datenmodells, beispielsweise des Datenmodells 10, darstellen. Ebenso können das Backenddatenmodell 26 und/oder das fahrzeugseitiges Datenmodell 28 aber Teile umfassen, die nicht in dem jeweils anderen Datenmodell 28, 26 repräsentiert sind.
-
In dem stationären Teil 20 ist ein Modifizierungsmechanismus, hier repräsentiert als Modifizierungsfunktion 30, implementiert, wodurch Veränderungen 32 des Backenddatenmodells 26 vorgenommen oder ausgeführt werden können. Der stationäre Teil 20 ist dazu eingerichtet, auf solche Veränderungen 32 des Backenddatenmodells 26 hin diese Veränderungen 32 über die Mobilfunkverbindung 24 an den mobilen Teil 22 zu senden.
-
Der mobile Teil 22 ist dazu eingerichtet, diese Veränderungen 32 zu empfangen und in das dortige lokale fahrzeugseitiges Datenmodell 28 zu übernehmen. In dem mobilen Teil 22 ist auf dem dortigen fahrzeugseitigen Datenmodell 28 vorliegend wenigstens eine Anwendungsfunktion 34 modelliert. Diese Anwendungsfunktion 34 bzw. deren Ausführung wird durch Übernahme der Veränderungen 32 in das fahrzeugseitige Datenmodell 28 ausgelöst. Dies kann unmittelbar bei oder nach Empfang dieser Veränderungen 32 geschehen oder beispielsweise erst nach einer Analyse, Konsistenzprüfung, Validierung und/oder dergleichen der empfangenden Veränderungen 32. Durch die Anwendungsfunktion 34 können in dem mobilen Teil 22 bzw. dem damit ausgestatteten Kraftfahrzeug je nach Implementierung der Anwendungsfunktion 34 eine oder mehrere Maßnahmen oder Prozesse durchführen oder auslösen. Beispielsweise kann die Anwendungsfunktion 34 ihrerseits eine vorgegebene Steuermaßnahme 36 triggern.
-
Dabei kann es wiederum fahrzeugseitig zu weiteren, resultierenden Veränderungen des fahrzeugseitigen Datenmodells 28 kommen, die dann in umgekehrter Richtung über die Mobilfunkverbindung 24 an den stationären Teil 20 gesendet werden können, wo sie dann in das dortige Backenddatenmodell 26 eingepflegt werden können.
-
Auf die hier schematisch veranschaulichte Weise kann durch eine Modifizierung oder Aktualisierung des Backenddatenmodells 26 eine Ausführung der Anwendungsfunktion 34 in dem stationären Teil 20 ausgelöst werden, ohne dass dafür die Anwendungsfunktion 34 oder eine entsprechende Funktionsschnittstelle für die Anwendungsfunktion 34 auf Seiten des stationären Teils 20 bekannt oder implementiert sein müsste.
-
3 zeigt eine weitere schematische Darstellung zur Veranschaulichung einer solchen datenmodellbasierten Funktionsauslösung. Beispielhaft sind hier Eigenschaften und/oder Zustände, die das Kraftfahrzeug, das den mobilen Teil 22 umfasst, betreffen, in einer Datenstruktur 38 repräsentiert. Die Datenstruktur 38 kann mehrere Datenfelder 12 umfassen. Beispielsweise ist hier ein Zieldatenfeld 40 vorgesehen, dem ein erstes Koordinatenfeld 42 und ein zweites Koordinatenfeld 44 zugeordnet oder untergeordnet sind. Beispielweise kann in dem ersten Koordinatenfeld 42 eine geographische Länge und in dem zweiten Koordinatenfeld 44 eine geographische Breite eines Navigationsziels gespeichert sein. Weiter kann ein Zeitdatenfeld 46 vorgesehen sein, dem beispielsweise ein Jetztzeitdatenfeld 48 und ein Zukunftszeitdatenfeld 50 zugeordnet oder untergeordnet sein können. Weiter kann ein Temperaturdatenfeld 52 vorgesehen sein, dem beispielsweise ein Schätztemperaturdatenfeld 54 zugeordnet oder untergeordnet sein kann. Weiter kann ein Personendatenfeld 56 vorgesehen sein, dem beispielsweise ein Fahrerdatenfeld 58 zugeordnet oder untergeordnet sein kann.
-
Auf diesem fahrzeugseitigen Datenmodell 28 bzw. dieser Datenstruktur 38 können mehrere Anwendungsfunktionen 34 modelliert sein. Beispielsweise kann mit dem ersten Koordinatenfeld 42 und dem zweiten Koordinatenfeld 44 eine erste Anwendungsfunktion 60 verknüpft sein. Die erste Anwendungsfunktion 60 kann beispielsweise ein Senden eines Interessenpunktes (englisch: Point of Interest, Pol) an einen Fahrer, ein Navigationsgerät oder ein Anzeigegerät des Kraftfahrzeugs gesendet werden, wenn sich das erste Koordinatenfeld 42 und/oder das zweite Koordinatenfeld 44 verändern.
-
Mit dem ersten Koordinatenfeld 42 und dem zweiten Koordinatenfeld 44 kann ebenso ein eine zweite Anwendungsfunktion 62 verknüpft sein, durch die beispielsweise eine Berechnung oder eine Planung einer Route zu einem durch diese Koordinatenfelder 42, 44 angegebenen Position durchgeführt oder ausgelöst werden kann.
-
Mit den Zeitdatenfeldern 48, 50 kann eine dritte Anwendungsfunktion 64 verknüpft sein. Da in der Datenstruktur 38 das Zieldatenfeld 40 und das Zeitdatenfeld 46 miteinander verknüpft sind, können auch die Anwendungsfunktion 60, 62, 64 miteinander verknüpft sein. So kann beispielsweise die dritte Anwendungsfunktion 64 bei einer Veränderung der Zeitdatenfelder 48, 50 und/oder durch eine Ausführung beispielsweise der zweiten Anwendungsfunktion 62 ausgelöst werden. Durch die dritte Anwendungsfunktion 64 kann beispielsweise eine Startzeit und/oder eine voraussichtliche Ankunftszeit für die Navigation bzw. Fahrt zu der durch die Koordinatenfelder 42, 44 angegebenen Position berechnet werden. Dies kann gegebenenfalls in Abhängigkeit davon erfolgen, ob das Jetztzeitdatenfeld 48 oder das Zukunftszeitdatenfeld 50 geändert wurde. Wird beispielsweise das Zukunftszeitdatenfeld 50 verändert, so kann dies als gewünschte Ankunftszeit in die dritte Anwendungsfunktion 64 übernommen werden, die dann darauf basierend die zum Einhalten dieser Ankunftszeit notwendige Abfahrtszeit berechnen und in das Jetztzeitdatenfeld 48 eintragen kann.
-
Weiter kann eine vierte Anwendungsfunktion 66 implementiert sein, die mit dem Temperaturdatenfeld 52 und/oder dem Schätztemperaturdatenfeld 54 verknüpft sein kann. Ebenso kann die vierte Anwendungsfunktion 66 mit den übrigen Datenfeldern und/oder Anwendungsfunktion oder eine Auswahl davon verknüpft sein, um die Ausführung der vierten Anwendungsfunktion 66 auszulösen. Durch die vierte Anwendungsfunktion 66 kann beispielsweise in Abhängigkeit von der berechneten Abfahrtszeit eine Klimatisierung eines Fahrzeuginnenraums und/oder einer Betriebseinrichtung, wie etwa einer Traktionsbatterie des Kraftfahrzeugs, zeitgemäß für die berechnete Abfahrtszeit ausgelöst oder durchgeführt werden. Beispielsweise kann durch die vierte Anwendungsfunktion 66 dann eine erwartete oder geschätzte Temperatur, die beispielsweise voraussichtlich zu der berechneten Abfahrtszeit erreicht wird, in das Schätztemperaturdatenfeld 54 eingetragen werden.
-
Weiter kann eine fünfte Anwendungsfunktion 68 implementiert sein, die zumindest mit dem Fahrerdatenfeld 58 und/oder dem Personendatenfeld 56 verknüpft sein kann. Auch die fünfte Anwendungsfunktion 68 kann mit den übrigen Datenfeldern und/oder Anwendungsfunktion oder einer Auswahl davon verknüpft sein, um die Ausführung der fünften Anwendungsfunktion 68 zu triggern. Durch die fünfte Anwendungsfunktion 68 kann beispielsweise eine Konditionierung oder Konfiguration des Kraftfahrzeugs für an der geplanten Fahrt teilnehmende Personen eingestellt werden, beispielsweise ein jeweils bevorzugter Radiosender, eine Playlist, eine Ambientebeleuchtung, eine Sitzposition, eine Lenkradposition, eine Spiegelposition, eine Fahrwerksabstimmung und/oder dergleichen mehr. Dies kann beispielsweise für eine oder mehrere in dem Personendatenfeld 56 angegebenen Personen durchgeführt werden. Ebenso kann, beispielsweise durch die fünfte Anwendungsfunktion 68 oder eine weitere Anwendungsfunktion eine Fahrerschätzung durchgeführt werden, um einen Fahrer zu bestimmen, der während der geplanten Fahrt das Kraftfahrzeug voraussichtlich führen wird. Ein entsprechender Wert oder eine entsprechende Angabe kann in dem Fahrerdatenfeld 58 hinterlegt sein oder werden.
-
Die hier beschriebenen Beispiele dienen nur der Veranschaulichung. Ebenso können viele andere oder weitere Datenfelder, Anwendungsfunktion und/oder Kombinationen oder Verknüpfungen implementiert sein.
-
Insgesamt zeigen die beschriebenen Beispiele wie eine Funktionsmodellierung auf Basis eines einheitlichen Datenmodells 10 realisiert werden kann, um einen besonders effizienten Betrieb softwaregesteuerter Einrichtungen oder Systeme zu ermöglichen.
-
Bezugszeichenliste
-
- 10
- Datenmodell
- 12
- Datenfelder
- 14
- erste Datenfelder
- 16
- zweite Datenfelder
- 18
- System
- 20
- stationärer Teil
- 22
- mobiler Teil
- 24
- Mobilfunkverbindung
- 26
- Backenddatenmodell
- 28
- fahrzeugseitiges Datenmodell
- 30
- Modifizierungsfunktion
- 32
- Veränderung
- 34
- Anwendungsfunktion
- 36
- Steuermaßnahme
- 38
- Datenstruktur
- 40
- Zieldatenfeld
- 42
- erstes Koordinatenfeld
- 44
- zweites Koordinatenfeld
- 46
- Zeitdatenfeld
- 48
- Jetztzeitdatenfeld
- 50
- Zukunftszeitdatenfeld
- 52
- Temperaturdatenfeld
- 54
- Schätztemperaturdatenfeld
- 56
- Personendatenfeld
- 58
- Fahrerdatenfeld
- 60
- erste Anwendungsfunktion
- 62
- zweite Anwendungsfunktion
- 64
- dritte Anwendungsfunktion
- 66
- vierte Anwendungsfunktion
- 68
- fünfte Anwendungsfunktion
-
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
-
