DE102018003281A1

DE102018003281A1 - Fahrzeugbetriebssystem

Info

Publication number: DE102018003281A1
Application number: DE102018003281.8A
Authority: DE
Inventors: Carsten Gut
Original assignee: Daimler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2018-04-23
Filing date: 2018-04-23
Publication date: 2019-10-24
Anticipated expiration: 2038-04-24
Also published as: DE102018003281B4; US20210237664A1; US11926269B2; CN112004722A; WO2019206502A1; CN112004722B

Abstract

Die Erfindung betrifft ein Fahrzeugbetriebssystem (2) mit einem Funktionsspeicher (3) zum Speichern von Funktionen oder Anwendungen (A, B, ..., F) mit einer Schnittstelle (4) zur Ausgabe von festgelegten Sensordaten an die Funktionen oder Anwendungen (A, B, ..., F) und mit einer Schnittstelle (6) zur Weitergabe von durch die Funktionen oder Anwendungen (A, B, ..., F) generierten Steuerbefehlen an Aktuatoren des Fahrzeugs (1). Erfindungsgemäß ist es vorgesehen, dass ein Speicher (8) vorgesehen ist, in welchem fahrzeugseitig festgelegte zulässige Wertebereiche für die Steuerbefehle hinterlegt sind, wobei die Schnittstelle (6) zur Weitergabe der Steuerbefehle die Steuerbefehle nur im Rahmen der in dem Speicher (8) hinterlegten Wertebereiche weitergibt.

Description

Die Erfindung betrifft ein Fahrzeugbetriebssystem nach der im Oberbegriff von Anspruch 1 näher definierten Art. Außerdem betrifft die Erfindung ein Verfahren zum Betreiben eines Fahrzeugbetriebssystems nach der im Oberbegriff von Anspruch 5 näher definierten Art.
Fahrzeugbetriebssysteme und Verfahren zum Betreiben derartiger Fahrzeugbetriebssysteme sind grundlegend aus dem Stand der Technik bekannt. Diese Fahrzeugbetriebssysteme weisen im Allgemeinen einen Funktionsspeicher zum Speichern von Funktionen oder Anwendungen auf, welche ihrerseits entsprechende Funktionalitäten in dem Fahrzeug steuern. Dabei ist es so, dass diese Funktionen, welche häufig komfort- und/oder sicherheitsrelevante Aspekte des Fahrzeugs betreffen, alleine vom Fahrzeughersteller programmiert werden, um die geforderten Sicherheitsaspekte zuverlässig unter der Maßgabe des Fahrzeugherstellers einzuhalten. In der Praxis führt dies zu relativ starren Fahrzeugbetriebssystemen, deren Funktionen sich häufig nur sehr langsam verändern, beispielsweise mit der Markteinführung eines neuen Fahrzeugmodells, sodass Kundenwünsche häufig erst spät oder durch ein anderes Fahrzeugmodell erfüllt werden. Insbesondere Komfortfunktionen, Funktionen zur Beeinflussung einer Multimediaanlage und dgl. sind so jeweils nur für die Käufer der neuesten Fahrzeuggeneration in ihrer neuesten Version zugänglich.
Die DE 10 2011 109 720 A1 beschreibt ein Verfahren und ein System, welches die benutzerabhängige Nutzung eines Fahrzeugs über ein Kommunikationsgerät umfasst. Dabei ist es so, dass über ein Kommunikationsgerät wie beispielsweise ein Smartphone Steuerungsdaten und Steuerungsbefehle an das Fahrzeug übermittelt werden, um Fahrzeugfunktionen den Wünschen und den Bedürfnissen des Benutzers anzupassen. Dieser kann somit das Fahrzeug individualisieren, indem er es über das Kommunikationsgerät steuert. Führt der Nutzer dieses Kommunikationsgerät mit, wird sich jedes von ihm genutzte Fahrzeug, beispielsweise im Rahmen eines Car-Sharings, entsprechend seiner vorprogrammierten Wünsche anpassen. Das Problem kann hier darin liegen, dass nur bestimmte Funktionalitäten, wie beispielsweise Komforteinstellungen in dem Fahrzeug bezüglich einer Multimediaanlage, eines Navigationsgeräts, Position von Sitzen und Spiegeln etc. über die Steuerung erfasst werden können. Für den eigentlichen Fahrbetrieb und die Fahrsicherheit relevante Funktionalitäten können hier nicht freigegeben werden, da prinzipiell die Gefahr besteht, dass die Steuerungsbefehle missbräuchlich genutzt werden, was ein erhebliches Sicherheitsrisiko darstellt.
Aus der DE 10 2016 008 981 A1 ist es ferner bekannt, dass die Einstellung der Lichtverteilung eines Scheinwerfers mit einer Vielzahl von Lichtquellen, beispielsweise eines Pixelscheinwerfers, anhand von Nutzervorgaben erfolgt, wofür eine vergleichsweise aufwändige Sicherheitsabfrage mit einer Nutzerauthentifizierung realisiert wird, um der Gefahr eines Missbrauchs vorzugreifen.
Die Aufgabe der vorliegenden Erfindung besteht nun darin, ein Fahrzeugbetriebssystem sowie ein Verfahren zum Betreiben eines derartigen Fahrzeugbetriebssystems anzugeben, welches einfach und effizient die schnelle Weiterentwicklung von Funktionen unterstützt und dabei eine sichere und zuverlässige Fahrzeugfunktionalität gewährleistet.
Erfindungsgemäß wird diese Aufgabe durch ein Fahrzeugbetriebssystem mit den Merkmalen im Anspruch 1, und hier insbesondere im kennzeichnenden Teil des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Unteransprüchen. Außerdem löst ein Verfahren mit den Merkmalen im Anspruch 5, und auch hier insbesondere wieder im kennzeichnenden Teil des Anspruchs 5, die Aufgabe. Auch bezüglich des Verfahrens ergeben sich vorteilhafte Ausgestaltungen und Weiterbildungen aus den abhängigen Verfahrensansprüchen.
Über das Fahrzeugbetriebssystem werden mit einer Schnittstelle festgelegte und vorzugsweise fusionierte Sensordaten an eine Funktion oder Anwendung in dem Funktionsspeicher ausgegeben. Diese Schnittstelle kann dabei als definierte offene Schnittstelle realisiert werden, um neben dem Fahrzeughersteller auch Drittanbietern die Entwicklung und Programmierung von Funktionen und Anwendungen für das Fahrzeug zu ermöglichen. Hierdurch ist eine sehr viel schnellere Entwicklung von neuen Funktionen und Anwendungen zu erwarten, welche sich dann sehr viel schneller als bisher an verschiedene Fahrzeuge und deren Nutzer verteilen lassen, sodass die Möglichkeiten der Nutzung erhöht und eine kundenspezifische Anpassung jedes Fahrzeugs möglich wird. Dies verbessert letztlich die Zufriedenheit des Kunden und den erlebbaren Kundennutzen.
Über eine weitere -vorzugsweise offene- Schnittstelle werden von der Funktion oder Anwendung generierte Steuerbefehle in dem Fahrzeugbetriebssystem an Aktuatoren des Fahrzeugs weitergegeben, welche so die entsprechenden Funktionen steuern. Dabei ist es so, dass ein Speicher vorgesehen ist, in welchem fahrzeugseitig, durch den Fahrzeughersteller, festgelegte zulässige Wertebereiche für die Steuerbefehle hinterlegt sind, und dass die Schnittstelle zur Weitergabe der Steuerbefehle diese nur im Rahmen der festgelegten und gespeicherten Wertebereiche weitergibt. Ergänzend zur definierten offenen Schnittstelle können auch die zulässigen Wertebereiche jeder definiert werden. Um dennoch durch den Fahrzeughersteller die erforderliche Sicherheit zu gewährleisten, welche in seinem Verantwortungsbereich für das Produkt liegt, wird über den Speicher für jeden denkbaren Steuerbefehl, welcher beispielsweise in einer Dokumentation der offenen Schnittstelle beschrieben und mit einem zulässigen Wertebereich angegeben sein kann, sichergestellt, dass dieser zulässige Wertebereich, welcher gegebenenfalls auch durch Parameter bezüglich des aktuellen Zustands des Fahrzeugs beeinflusst werden kann, nicht überschritten wird. Sollte also die Anwendung oder Funktion einen unzulässigen Wertebereich für die Steuerbefehle nutzen wollen, sei es durch einen Programmierfehler oder um dem Fahrzeughersteller bzw. seinem Endkunden mutwillig zu schaden, dann wird dies durch das erfindungsgemäße Betriebssystem verhindert, indem die Wertebereiche für jeden der Steuerbefehle bei Bedarf auf den zulässigen Wertebereich beschnitten werden. Damit können durch die Funktionen weder versehentlich noch mutwillig sicherheitskritische Situationen durch fehlerhafte oder manipulierte Steuerbefehle ausgelöst werden.
Eine sehr vorteilhafte Weiterbildung des erfindungsgemäßen Fahrzeugbetriebssystems sieht es dabei vor, dass ein Kommunikationsmodul zur Verbindung des Funktionsspeichers mit einem Backend-Server vorgesehen ist. Über ein solches Kommunikationsmodul, beispielsweise ein GSM- Modul lässt sich eine zumindest zeitweise Anbindung des Fahrzeugs bzw. seines Betriebssystems an einen Backend-Server, insbesondere einen Backend-Server des Fahrzeugherstellers erreichen. Über diesen Weg können beispielsweise von dem Fahrzeughersteller entsprechend freigegebene Funktionen oder Anwendungen in den Funktionsspeicher des Betriebssystems heruntergeladen und durch den Nutzer des Fahrzeugs entsprechend genutzt werden.
Dabei kann gemäß einer vorteilhaften Weiterbildung der Idee ein Personalisierungsspeicher vorgesehen sein, welcher mit dem Funktionsspeicher und dem Kommunikationsmodul verbunden ist, und in welchem gespeichert ist, welche Funktionen oder Anwendungen in dem Funktionsspeicher einer in dem Personalisierungsspeicher hinterlegten Person zur Verfügung stehen. Hierdurch ist eine Personalisierung möglich. Die Person gibt sich dem Fahrzeugbetriebssystem zu erkennen, sei es durch spezifische über einen Sensor erfassbare Werte, wie beispielsweise Gewicht, Größe, Aussehen, welches entsprechend optisch erfasst werden kann oder dgl. Ebenso ist es denkbar, zur Identifizierung einen entsprechenden Fahrzeugschlüssel mit personalisierten Merkmalen einzusetzen oder ein mobiles Gerät, wie beispielsweise ein Smartphone oder ein Wearable derjenigen Person zu erkennen, welches zuvor in dem Fahrzeug bzw. dem Backend-Server registriert worden ist. Das Fahrzeugbetriebssystem ist dann in der Lage, im Personalisierungsspeicher die entsprechenden Daten abzurufen, welche Funktionen und gegebenenfalls welche Parametrisierung der Funktionen von der jeweiligen Person genutzt werden dürfen und ob entsprechende personalisierte Einstellungen von Parametern der Funktionen vorliegen. Das Fahrzeugbetriebssystem kann dann den entsprechenden der jeweiligen Person zugeordneten individuellen Funktionsumfang freischalten und so ein individuell angepasstes Fahrzeug zu ermöglichen. Dies ist insbesondere dann von Vorteil, wenn verschiedene Personen ein und dasselbe Fahrzeug nutzen oder insbesondere auch, wenn verschiedene Personen verschiedene Fahrzeuge nutzen, beispielsweise im Rahmen eines Car-Sharings, sodass beispielsweise beim öffnen des Fahrzeugs über einen personalisierten Schlüssel, welcher insbesondere in ein Smartphone oder ein Wearable integriert sein kann, sofort die entsprechenden dieser Person zugeordneten Funktionen zur Verfügung stehen. So kann eine einzelne Person beispielsweise verschiedene Funktionen lizenzieren, welche sie im Fahrzeug zur Verfügung haben möchte. Dasselbe Fahrzeug kann dann einen gänzlich anderen Funktions- und Komfortumfang für die eine Person zur Verfügung stellen, wie für die andere Person, welche lieber sparsam ist und auf die Lizenzierung von zusätzlichen Komfortfunktionen lieber verzichten möchte.
Die Funktionen oder Anwendungen in dem Funktionsspeicher des Fahrzeugbetriebssystems können dabei verschiedenartige Funktionen umfassen, beispielsweise Navigationsfunktionen, autonome Fahrzeugfunktionen, Komfortfunktionen wie beispielsweise das Einstellen von Sitz, Spiegel, Heizung oder dgl. sowie Multimediafunktionen, über welche beispielsweise Lautstärke, bevorzugte Radiosender etc. vorgewählt werden können. Daneben sind weitere Funktionen für den Fahrzeugbetrieb denkbar, beispielsweise nutzeradaptierte Schaltprogramme, um mit dem Fahrzeug je nach Nutzervorgaben und Wünschen zu fahren.
Gemäß einer besonders günstigen Ausgestaltung des erfindungsgemäßen Fahrzeugbetriebssystems können die Funktionen nun insbesondere Lichtfunktionen umfassen. Dazu ist es entsprechend vorgesehen, dass die Funktionen zur Ausgabe von Steuerbefehlen an eine Scheinwerfersteuerung ausgebildet sind. Bei derartigen Lichtfunktionen, wie sie beispielsweise in der eingangs genannten DE 10 2016 008 981 A1 erwähnt sind, kann es sich insbesondere um Funktionen wie ein Teilfernlicht oder dgl. handeln, welches mit hochauflösenden Pixelscheinwerfern entsprechend realisiert werden kann. Vor allem eine derartige Funktionalität, welche einen großen Vorteil für den Kunden ermöglicht, kann ein Hauptanwendungsaspekt für eine derartige offene Schnittstelle sein. Verschiedene Anbieter können hier konkurrierend Beleuchtungskonzepte entwickeln und anbieten. Eine schnelle Entwicklung in diesem Gebiet garantiert eine sehr schnelle Umsetzung von neuen Funktionen in Fahrzeugen mit derartigen offenen Schnittstellen. Hierdurch ist, bezogen auf den Gesamtverkehr, eine höhere Sicherheit möglich, da innovative Beleuchtungskonzepte sehr schnell sehr vielen Personen zur Verfügung stehen und beispielsweise ausgefeilte Funktionalitäten hinsichtlich eines Teilfernlichts, eines Kurvenlichts und dgl. nachweislich zu einer Erhöhung der Fahrsicherheit im Verkehr führen. Einerseits weiter gesehen und andererseits wird dennoch die Gefahr einer Blendung des Gegenverkehrs entsprechend reduziert. Diese Art der Funktionen bietet sich deshalb als bevorzugte Anwendung an. Sie bietet darüber hinaus ein Anwendungsfeld, in welchem die Gefahr eines Missbrauchs relativ klein ist, da von einem potenziellen Missbrauch keine unmittelbare Gefahr für den Nutzer des Fahrzeugs ausgeht und da ein solcher für den Nutzer des Fahrzeugs eher leicht zu erkennen ist.
Neben einer Individualisierung von Komforteinstellungen und dgl. stellt diese Anwendung also eine besonders günstige und effiziente Nutzung für das erfindungsgemäße Betriebssystem dar.
Das erfindungsgemäße Verfahren zum Betreiben eines Fahrzeugbetriebssystems kann nun insbesondere mit einem Betriebssystem im oben beschriebenen Sinne zusammenwirken, ist jedoch nicht zwingend auf ein solches angewiesen. Bei dem erfindungsgemäßen Verfahren ist es vorgesehen, dass Funktionen oder Anwendungen in das Fahrzeugbetriebssystem geladen werden, welche auf Basis von Daten einer Datenschnittstelle Steuerungsfunktionen in dem Fahrzeug ausführen, indem sie Steuerbefehle an eine Fahrzeugschnittstelle senden. Auch hier können die Schnittstellen wieder, wie oben bereits erwähnt, als offene entsprechend dokumentierte Schnittstellen verfügbar sein, um so eine Entwicklung von Funktionen und Anwendungen nicht nur durch den Fahrzeughersteller, sondern in dem oben beschriebenen positiven Sinn auch durch Dritte zu ermöglichen. Das erfindungsgemäße Verfahren begrenzt, vergleichbar wie das Fahrzeugbetriebssystem gemäß der Erfindung, fahrzeugseitig den Wertebereich der Steuerbefehle auf einen jeweils zulässigen Wertebereich, um so einem Missbrauch oder einer Fehlfunktion vorzubeugen und die Sicherheit des Fahrzeugs gewährleisten zu können.
Das Verfahren sieht es dabei gemäß einer vorteilhaften Weiterbildung vor, dass die Datenschnittstelle Daten gemäß vorgegebener Modelle von Sensorfusionen bereitstellt, welche der Kontrolle des Fahrzeugherstellers unterliegen. Die Sensordaten werden also insbesondere nach vorgegebenen Modellen, welche sich entsprechend anpassen und bei Bedarf verändern lassen, fusioniert und in dieser Art zur Verfügung gestellt. Bei einer offenen Schnittstelle ist dies entsprechend dokumentiert. Dabei kann es beispielsweise Fusionsmodelle für die Fusion der Sensordaten geben, welche insbesondere auf Beleuchtungsfunktionen zugeschnitten sind, also von den Umfeldsensoren des Fahrzeugs erfasste Daten beispielsweise über vorausfahrende, nachfolgende und entgegenkommende weitere Verkehrsteilnehmer benötigen. Andere Funktionen und Anwendungen, welche diese komplexen Daten nicht benötigen, können Daten alternativer Modelle der Sensorfusion entsprechend abfragen, um so beispielsweise Einstellungen hinsichtlich der gewünschten Temperatur einer Heiz- oder Klimaanlage, der aktuell eingestellten Lautstärke eines Multimediageräts oder dgl. zur Verfügung zu stellen.
Eine sehr vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens sieht es dabei vor, dass die Funktionen und Anwendungen vom Fahrzeughersteller und/oder von Drittanbietern erstellt werden. Sie können dann über einen Backend-Server und ein Kommunikationsmodul in das Fahrzeugbetriebssystem bzw. seinen Funktionsspeicher geladen und entsprechend genutzt werden. Dadurch können Drittanbieter über die offenen Schnittstellen in Form der Datenschnittstelle einerseits und der Steuerschnittstelle andererseits geeignete Funktionen entwickeln und zur Verfügung stellen. Der Nutzer kann diese dann über einen Backend-Server des Fahrzeugherstellers in sein Betriebssystem laden oder der Fahrzeughersteller kann beispielsweise Updates zu bestehenden Funktionen automatisiert in das Betriebssystem laden, wenn über das Kommunikationsmodul eine Verbindung zum Backend-Server besteht.
Eine sehr vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens sieht es ferner vor, dass die Freigabe von geladenen Funktionen oder Anwendungen anhand von Nutzerdaten und/oder in Abhängigkeit von fahrzeugspezifischen Daten erfolgt. Die in dem Funktionsspeicher des Fahrzeugbetriebssystems vorhandenen Funktionen und Anwendungen werden also entsprechend von Benutzerdaten, beispielsweise aus dem oben bereits genannten Personalisierungsspeicher angepasst und freigegeben. So kann beispielsweise ein Nutzer in ein und demselben Fahrzeug mehr Funktionen zur Verfügung haben, da er mehr Funktionen lizenziert hat, als beispielsweise ein anderer Nutzer, welcher in demselben Fahrzeug weniger Funktionsumfang nutzen kann. Darüber hinaus können bestimmte Funktionen nur in eingeschränktem Rahmen oder gegebenenfalls gar nicht von bestimmten Fahrzeugen ausgeführt werden. Nutzt ein Nutzer beispielsweise verschiedene Fahrzeuge und hat sich verschiedene Funktionen lizenziert, so kann es nun sein, dass nicht alle Funktionen in allen Fahrzeugen funktionieren. Fahrzeugspezifische Daten werden deshalb bei der Freigabe ebenfalls berücksichtigt. Hat der Nutzer beispielsweise autonome Fahrfunktionen geladen und nutzt diese in seinem ersten Fahrzeug regelmäßig, dann kann es sein, dass sein zweites Fahrzeug beispielsweise nicht alle notwendigen Sensoren der Umfelderfassung, wie beispielsweise Stereokameras, Lidar oder dgl. zur Verfügung hat, da das Fahrzeug beispielsweise das Fahrzeug einer kleineren Fahrzeugklasse ist oder da dieses Fahrzeug schon älter ist. Die entsprechenden Funktionen werden dann als technisch nicht ausführbar blockiert, auch wenn der Nutzer diese prinzipiell aufgrund einer gültigen Lizenz nutzen könnte.
Eine vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens sieht es vor, dass in die Schnittstelle zwischen dem Kommunikationsmodul und dem Backend-Server eine Bezahlfunktion integriert ist. Eine solche Bezahlfunktion macht es außerordentlich einfach möglich, ein Update zu beziehen oder lizenzpflichtige zusätzliche Funktionen oder Anwendungen zu lizenzieren oder zu kaufen. Durch die integrierte Bezahlfunktion lässt sich die Bezahlung beim Herunterladen der entsprechenden Funktionen oder Anwendungen in das Fahrzeug mit abwickeln, sodass ein außerordentlich einfaches und effizient zu nutzendes System entsteht.
Dabei können die Funktionen fahrzeugspezifische Basisfunktionen umfassen und insbesondere einem Nutzer zugeordnete, erweiterte Funktionen oder Anwendungen. Die Basisfunktionen für das Fahrzeug werden typischerweise vom Fahrzeughersteller entsprechend programmiert und mit dem Fahrzeug bereitgestellt, beispielsweise bei dessen Auslieferung. Hier können weitere Updates auch während der Betriebsdauer des Fahrzeugs erfolgen. Die erweiterten Funktionen, welche bevorzugt eben nicht mehr dem Fahrzeug, sondern nun einem Nutzer zugeordnet werden, sind praktisch Funktionen einer „Sonderausstattung“. Diese Funktionen können von dem Nutzer entsprechend erworben werden, beispielsweise beim Fahrzeughersteller oder auch von beliebigen Drittanbietern. Über diese kann der Nutzer das Fahrzeug seinen individuellen Bedürfnissen anpassen und kann beispielsweise von schnelleren Entwicklungszyklen durch das Einbinden von Drittanbietern profitieren. Er kann so beispielsweise auch ein älteres Fahrzeug, sofern dieses es technisch und bezüglich seiner Sensordaten zulässt, mit neueren Funktionen aufwerten oder Ähnliches.
Diese erweiterten Funktionen oder Anwendungen können nun in Abhängigkeit des jeweiligen Nutzers des Fahrzeugs über das Kommunikationsmodul in das Fahrzeug geladen werden. Eine solche dem Nutzer erfolgte Zuordnung der Funktionen ermöglicht, wie es oben bereits erwähnt worden ist, dass der Nutzer mit den von ihm genutzten und insbesondere gekauften oder lizenzierten Funktionen verschiedene Fahrzeuge nutzen kann und das Funktions- und Anwendungsumfeld immer in der gleichen Art und Weise vorfindet. Insbesondere bei der Nutzung von Fahrzeugen durch verschiedene Personen, beispielsweise im Rahmen eines Car-Sharings oder auch bei der Nutzung einer Flotte von Firmenfahrzeugen kann dies ein ganz entscheidender Vorteil sein, da jeder Nutzer sein ihm bekanntes Umfeld in jedem Fahrzeug vorfindet, egal, wer das Fahrzeug zuvor gefahren hat, und, sofern sich hier keine Beschränkungen durch die verfügbaren Sensoren in dem Fahrzeug ergeben, auch unabhängig vom Typ des Fahrzeugs selbst.
Eine weitere sehr vorteilhafte Ausgestaltung der Idee sieht es dabei ferner vor, dass Fahrzeugdaten in Abhängigkeit einer Nutzerzustimmung anonymisiert über das Kommunikationsmodul an den Backend-Server übertragen und in dem Backend-Server verarbeitet werden. Hierdurch lassen sich Fahrzeugdaten in dem Backend-Server sammeln und beispielsweise für die Weiterentwicklung von Funktionalitäten nutzen. Diese Daten können dann über den Backend-Server und eine geeignete Schnittstelle auch Drittanbietern beispielsweise von Funktionen zur Verfügung gestellt werden. Auch das Zur-Verfügung-Stellen derartiger Daten beispielsweise an Behörden, welche diese zu statistischen Zwecken und zur Planung von Verkehrsprojekten nutzen können, ist denkbar. Ein weiterer Anwendungsfall wäre beispielsweise die Bereitstellung derartiger Daten, vorzugsweise gegen Entgelt, an kommerzielle Unternehmen, wie beispielsweise Versicherungen oder dgl., welche auf dieser Basis mit hoher statistischer Zuverlässigkeit Typklassen, Regionalklassen oder dgl. berechnen und die damit möglichen angepassten Versicherungstarife ihren Kunden zur Verfügung stellen können.
Weitere vorteilhafte Ausgestaltungen des Fahrzeugbetriebssystems sowie des Verfahrens ergeben sich ferner aus dem Ausführungsbeispiel, welches nachfolgend unter Bezugnahme auf die Figur näher beschrieben ist.
Dabei zeigen:

1 schematische Darstellung eines Fahrzeugs, eines Fahrzeugbetriebssystems und der für das erfindungsgemäße Verfahren notwendigen und sinnvollen Schnittstellen;
2 schematische Darstellung der Situation, wenn ein Nutzer von einem Fahrzeug der Fahrzeugklasse I zu einem Fahrzeug der Fahrzeugklasse II wechselt;
3 das umgekehrte Szenario zur Darstellung in 2; und
4 schematische Darstellung zur Prüfung des Funktionsumfangs in Abhängigkeit von fahrzeugspezifischen Daten.

In der Darstellung der 1 ist ein schematisch angedeutetes Fahrzeug 1 dargestellt, mit einem Fahrzeugbetriebssystem 2. Teil dieses Fahrzeugbetriebssystems 2 ist ein Funktionsspeicher 3 zum Speichern von Funktionen oder Anwendungen, welche hier beispielhaft mit A bis F gekennzeichnet sind. Der Funktionsspeicher 3 steht mit einer Schnittstelle 4 als Datenschnittstelle für die Ausgabe von Sensordaten, welche aus einer Sensorfunktion 5 stammen, in Verbindung. Eine weitere Schnittstelle 6 dient der Ausgabe von Steuerbefehlen an ein Fahrzeug-Gateway 7, sodass entsprechende Aktuatoren des Fahrzeugs die Steuerbefehle der Funktionen oder Anwendungen A bis F entsprechend umsetzen. Entscheidend ist dabei ein mit 8 bezeichneter Speicher für den zulässigen Wertebereich der über die Schnittstelle 6 ausgegebenen Steuerbefehle. Das Fahrzeugbetriebssystem 2 erhält aus diesem Speicher 8 die entsprechenden zulässigen Wertebereiche. Sollten diese von der Funktion A bis F nicht eingehalten werden, so werden sie über das Fahrzeugbetriebssystem 2 auf den zulässigen Wertebereich begrenzt, sodass weder aufgrund eines Programmierungsfehlers noch missbräuchlich der zulässige Wertebereich überschritten werden kann.
Ein Kommunikationsmodul 9 steht in dem Fahrzeug 1 zur Verfügung. Es kann insbesondere über den mit 10 bezeichneten Weg zum Download neuer Funktionen eingesetzt werden, indem es bidirektional mit einem Backend-Server 11, vorzugsweise einem Backend-Server des Fahrzeugherstellers kommuniziert. Das Betriebssystem 2 kann außerdem über einen mit 12 bezeichneten Upload über das Kommunikationsmodul 9 Fahrzeugdaten für den Backend-Server zur Verfügung stellen, welche dort beispielsweise zur Weiterentwicklung von Funktionen oder Anwendungen A bis F, für Zwecke der Statistik oder dgl. Anwendung finden können. Der Backend-Server 11 hat dazu eine mit 13 bezeichnete Schnittstelle, über welche derartige anonymisierte Fahrzeugdaten beispielsweise an kommerzielle Anwender verkauft oder Behörden zur Verfügung gestellt werden können. Über eine weitere mit 14 bezeichnete Schnittstelle erhält der Backend-Server 11 neue Funktionen, Funktionsmodule, Updates oder Anwendungen A bis F, welche über den Backend-Server und das Kommunikationsmodul 9 als Download 10 in den Funktionsspeicher 3 des Betriebssystems 2 geladen werden können. Bei Bedarf können über den Backend-Server 11 auch neue Fusionsmodelle initiiert werden. Über das Kommunikationsmodul 9 können diese zu dem Fahrzeug heruntergeladen werden und werden über den mit 15 bezeichneten Weg der Sensorfunktion 5 zur Verfügung gestellt, welche über die Schnittstelle 4 dann die Daten auch gemäß dieser neuen Fusionsmodelle alternativ oder ergänzend zu den bisherigen Fusionsmodellen zur Verfügung stellt. In die Datenschnittstelle zwischen dem Kommunikationsmodul 9 und dem Backend-Server 11 lässt sich dabei außerdem eine schematisch angedeutete Bezahlfunktion 27 integrieren, um so beispielsweise kostenpflichtige Funktionen oder Anwendungen A bis F unmittelbar herunterladen und dabei bezahlen zu können.
Ergänzend steht ein Personalisierungsspeicher 16 zur Verfügung, welcher einerseits mit dem Funktionsspeicher 3 und andererseits zumindest mittelbar, beispielsweise über ein User-Interface 17 mit dem Fahrzeugbetriebssystem 2 verbunden ist. Über diesen Personalisierungsspeicher 16 können verschiedene Funktionalitäten durch das Fahrzeugbetriebssystem 2 abgefragt werden, beispielsweise welche Funktionen oder Anwendungen A bis F einer bestimmten Person zugeordnet sind und deshalb, wenn diese Person das Fahrzeug 1 nutzt, freigeschaltet werden sollen. Auch Informationen über die Lizenzierung einzelner Funktionen A bis F, um diese nicht versehentlich Personen bereitzustellen, welche diese nicht lizenziert oder gekauft haben, können in dem Personalisierungsspeicher 16 entsprechend hinterlegt sein.
Ein wesentlicher Bestandteil ist es nun, dass die Schnittstelle 4 als definierte offene Schnittstelle konzipiert ist, wodurch die Möglichkeit besteht, die Funktionen und Anwendungen A bis F zu partitionieren. Die offene Schnittstelle stellt als Datenschnittstelle 4 im Wesentlichen die fusionierten Sensordaten aus der Sensorfunktion 5 bereit. Über die Schnittstelle 6 erfolgt dann die Ausgabe der Steuerbefehle an das Fahrzeug-Gateway 7 und damit an die Aktuatoren des Fahrzeugs, wobei dies in einem vom Fahrzeughersteller definierten und durch das Fahrzeugbetriebssystem 2 und die in dem Speicher 8 hinterlegten Wertebereiche überwacht wird, um die Gefahr eines Missbrauchs oder einer versehentlichen Fehlprogrammierung auszuschließen. Die eingangs bereits genannte bevorzugte Anwendung von zumindest einer der Funktionen A bis F zur Steuerung eines Scheinwerfers 30, insbesondere eines hochauflösenden Pixelscheinwerfers zum Erzeugen einer individuell angepassten Lichtverteilung ist dabei in der Darstellung der 1 ebenso angedeutet. Das Fahrzeug-Gateway 7 steht dazu mit einem Scheinwerfersteuergerät 28 in Verbindung, welches den angedeuteten Scheinwerfer 30 des Fahrzeugs 1 entsprechend ansteuert.
Über das Kommunikationsmodul 9, beispielsweise ein GSM-Modul wird das Fahrzeug 1 außerdem an den Backend-Server 11 entsprechend angebunden, sodass schnell neu entwickelte Funktionen A bis F, beispielsweise Lichtfunktionen zur Steuerung des Scheinwerfersteuergeräts 28, auf das Fahrzeug 1 bzw. in dessen Funktionsspeicher 3 geladen werden können. Zusätzlich können personalisierte Einstellungen über den Backend-Server 11 entsprechend transferiert werden, um so verschiedene Fahrzeuge an denselben Nutzer oder ein Fahrzeug an verschiedene Nutzer jeweils individuell anpassen zu können.
Die schraffierten Blöcke in der Darstellung der 1 unterliegen dabei dem Verantwortungsbereich des Fahrzeugherstellers. Dieser hat also die Verantwortung über beispielsweise das Kommunikationsmodul 9, die Sensorfusion 5, den Backend-Server 11 und insbesondere über den Speicher 8 und das Fahrzeug-Gateway 7, den Personalisierungsspeicher 16 das Userinterface 17 sowie ferner, auch wenn dieses nicht schraffiert markiert ist, das Betriebssystem 2 des Fahrzeugs 1.
Die Qualität der angebotenen Funktionen und Anwendungen A bis F hängt dabei maßgeblich von der Qualität der Sensorfusion 5 ab. Dieser Block wird deshalb auch weiterhin vom Fahrzeughersteller erarbeitet und im Rahmen einer Dokumentation der offenen Schnittstellen 4, 6 zur Verfügung gestellt. Wie bereits erwähnt, wird in dem Speicher 8 dabei ein fest definierter Wertebereich für jeden denkbaren Steuerbefehl, welcher auch Teil der Dokumentation der offenen Schnittstellen 4 und 6 ist, hinterlegt. Das Einhalten desselben wird über das Fahrzeugbetriebssystem 2 überwacht, um Fehlfunktionen sicher ausschließen zu können. Ansonsten erlaubt die Verwendung der offenen Schnittstellen 4, 6, dass die einzelnen Funktionen und Anwendungen A bis F nicht zwingend ausschließlich vom Fahrzeughersteller entwickelt werden müssen, sondern dass auch Drittanbieter derartige Funktionen A bis F zur Verfügung stellen können. Dies hat den Vorteil, dass neue Funktionen und Anwendungen A bis F beispielsweise durch Zulieferfirmen, durch Tochterunternehmen oder spezialisierte Softwareunternehmen bereitgestellt werden können. Diese müssen dabei nicht zwingend aus dem Automotive-Bereich kommen, da die Sensordaten ja bereits fusioniert aus der Sensorfusion 5 in vordefinierter Art an der Schnittstelle 4 vorliegen. Somit wird ein sehr hohes Maß an Flexibilität geschaffen. Neue auch sehr komplexe Funktionen und Anwendungen A bis F lassen sich dabei durch die jeweiligen Softwarespezialisten, beispielsweise für verschiedene Fahrzeuganwender, nicht als vertraglich verpflichtete Dienstleister, sondern als eigenständige Serviceunternehmen, anbieten. Hierdurch ist ein sehr schneller Entwicklungszyklus möglich und neue Funktionen und Anwendungen A bis F lassen sich dem Nutzer des Fahrzeugs 1 als Endkunden sehr schnell zur Verfügung stellen.
Durch die offenen Schnittstellen 4,6 lassen sich dabei durch die Funktionen oder Anwendungen A bis F auch Informationen über den Upload 12 zu dem Backend-Server 11 hochladen. Der Backend-Server 11 kann dann über die bereits angesprochene definierte Schnittstelle 13 diese Daten entsprechend zur Verfügung stellen. Dies ermöglicht beispielsweise, dass anonymisierte Daten für Statistikzwecke an Behörden oder Verkehrsinstitute herausgegeben werden können, welche dann beispielsweise bei der bevorzugten Anwendung von Lichtfunktionalitäten in der Lage sind auszuwerten, wie oft und wie lange ein blendfreies Fernlicht aktiviert wurde. Dies kann auch als Basis genutzt werden, um zukünftige Verbesserungen der Funktionen und Anwendungen A bis F vorzunehmen. Der Zugang zu der Schnittstelle 13 kann dabei durch den Fahrzeughersteller kontrolliert werden, sodass die Daten beispielsweise gegen entsprechendes Entgelt in verschiedenem Umfang verschiedenen Nutzergruppen verfügbar gemacht werden.
Ferner ist es auch möglich, dass neue Funktionen oder Anwendungen A bis F und gegebenenfalls eine Anfrage hinsichtlich neuer Sensorfusionsmodelle erstellt und an den Fahrzeughersteller übermittelt werden. Verschiedene Drittunternehmen haben dabei sicherlich unterschiedliches Interesse. Einige Unternehmen sind daran interessiert, dem Nutzer des Fahrzeugs Funktionen oder Anwendungen A bis F zur Verfügung zu stellen, beispielsweise zu verkaufen oder zu lizenzieren, welche die Funktionen in dem Fahrzeug steuern. Beispielsweise können Anbieter von Multimedia-Equipment, welches in dem Fahrzeug installiert ist, auch entsprechende Anwendungen oder Funktionen A bis F zur Verfügung stellen, welche unmittelbar mit dem von ihnen gelieferten System des Fahrzeugs interagieren. Andere Unternehmen sind daran interessiert, Verbesserungen zur Verfügung zu stellen, beispielsweise verbesserte Fernlichtfunktionen, um dem Fahrer gegen Entgelt diese zur Verfügung zu stellen und ihm ein komfortableres und sichereres Fahren bei Nacht zu ermöglichen. Wieder andere Unternehmen können beispielsweise auch primär an den Daten des Fahrzeugs 1 interessiert sein. Eine Versicherung möchte beispielsweise Zugang zu den Geschwindigkeitsdaten haben. Der Nutzer des Fahrzeugs kann hierzu eine Funktion bzw. Anwendung A bis F der Versicherung über den Backend-Server 11 und das Kommunikationsmodul 9 entsprechend installieren. Die Versicherung kann dann über die Schnittstelle 13 zwischen der Funktion oder Anwendung A bis F und dem Backend 11 ausgetauschte Daten wiederum abfragen und kann auf dieser Basis Typklassen, Regionalklassen oder dgl. statistisch bewerten. Mit entsprechender Zustimmung des Fahrzeuginhabers können beispielsweise auch personenbezogene oder fahrzeugbezogene Daten, wie beispielsweise Geschwindigkeitsprofile und dgl. erfasst werden, um hiermit Einfluss auf die Versicherungsprämien, welche durch den Fahrzeugnutzer zu zahlen sind, zu nehmen. Dies kann insbesondere bei einem Fahrer mit primär defensiver Fahrweise von Vorteil sein, sodass dieser von einem günstigeren Versicherungstarif profitieren kann.
Ein weiterer Aspekt sieht es dabei vor, dass insbesondere die Funktionen A bis F in Basisfunktionen, beispielsweise A, B, C und erweiterte Funktionen oder Anwendungen, beispielsweise D, E, F unterteilt sind. Die Basisfunktionen sind dabei bei der Auslieferung des Fahrzeugs 1 bereits inkludiert. Die erweiterten Funktionen können heruntergeladen und beispielsweise durch eine entsprechende Lizenz freigeschaltet oder käuflich erworben werden.
Über die Anbindung des Fahrzeugs 1 über das Kommunikationsmodul 9 an dem Backend-Server 11 und insbesondere über die Möglichkeit der Personalisierung, wozu letztlich der Personalisierungsspeicher 16 Verwendung finden kann, ist es dabei möglich, dass die Funktionen und Anwendungen A bis F einem Nutzer zugeordnet werden. Dies bedeutet, dass er diese Funktionen und Anwendungen A bis F nicht nur in einem, sondern in verschiedenen Fahrzeugen nutzen kann, sodass er faktisch in jedem Fahrzeug seine persönliche Fahrzeugumgebung und immer dieselben Funktionen und Anwendungen A bis F vorfindet, solange das Fahrzeug in der Lage ist, diese umzusetzen. Eine bevorzugte Anwendung können hier Flottenfahrzeuge von Firmen oder Fahrzeuge im Car-Sharing-Betrieb sein.
In der Darstellung der 2 sind zwei Fahrzeuge 1 und 1' angedeutet. Das Fahrzeug 1 gehört einer ersten Fahrzeugklasse I und das zweite Fahrzeug 1' einer zweiten Fahrzeugklasse II an. In dem mit 18 bezeichneten Feld findet sich jeweils die Grundausstattung an Basisfunktionen A, B, C, welche in den Funktionsspeicher 3 geladen sind, wenn das Fahrzeug ausgeliefert wird. Das Fahrzeug 1 in der Fahrzeugklasse I hat dabei entsprechend der mit 19 bezeichneten Box alle drei Funktionen A, B, C freigeschaltet. Die Freischaltung 19 beim Fahrzeug 1' der Fahrzeugklasse II beinhaltet nur die Funktionen A und B, sodass nur diese Funktionen entsprechend genutzt werden können. In beiden Fällen ist es so, dass über einen nachträglichen Download 20 in beiden Fahrzeugen 1, 1' die erweiterten Funktionen und Anwendungen D, E, F heruntergeladen worden sind. Der Nutzer des Fahrzeugs 1 der Fahrzeugklasse I hat sich nun die Funktion E zusätzlich lizenziert, wie es in der mit 21 bezeichneten Box angedeutet ist. Nutzt er das Fahrzeug 1, stehen ihm nun die Funktionen A, B, C und E zur Verfügung. Dies ist in der mit 22 bezeichneten Box entsprechend angedeutet. Wechselt ein Nutzer des Fahrzeugs 1 der Fahrzeugklasse I nun, wie es durch den Pfeil 23 symbolisiert ist, das Fahrzeug und nutzt nun das Fahrzeug 1' der Fahrzeugklasse II, dann liegen in diesem Fahrzeug dieselben Funktionen in der Grundausstattung 18 und im Download 20 zur Verfügung. Er kann also in der Box 22 über dieselben Funktionen A, B zusätzlich dazu die Basisfunktion C, welche in dem Fahrzeug der Typklasse II typischerweise nicht zur Verfügung steht, sowie über die von ihm lizenzierte Funktion E verfügen. Der Nutzer hat damit unabhängig vom Fahrzeug, sofern das Fahrzeug technisch in der Lage ist, die jeweiligen Funktionen umzusetzen, „seine“ Funktionen A, B, C und E zur Verfügung.
In der Darstellung der 3 ist das umgekehrte Szenario dargestellt. Diesmal betrachten wir den Fahrer oder Nutzer des Fahrzeugs 1' der Fahrzeugtypklasse II. Dieser hat ebenfalls die Funktion E zusätzlich lizenziert, ansonsten ist das Szenario dasselbe wie in der Darstellung der 3. Bei dem Fahrzeug 1' der Typklasse II stehen dabei nur die Basisfunktionen A und B zur Verfügung. Außerdem hat der Nutzer die von ihm lizenzierte Funktion E zur Verfügung. Wechselt er nun in ein Fahrzeug der Fahrzeugklasse I, würden prinzipiell mehr Basisfunktionen zur Verfügung stehen, wie es in der Box 19 entsprechend angedeutet ist. Da er aber als registrierter Nutzer der Fahrzeugklasse II das Fahrzeug 1 der Fahrzeugklasse I nutzt, stehen für ihn nur die Funktionen A, B und E zur Verfügung, wie er dies von seinem Fahrzeug entsprechend gewohnt ist.
Ob eine Funktion oder Anwendung A bis F für den Nutzer eines Fahrzeugs 1, 1' also tatsächlich verfügbar und freigegeben ist, hängt nicht, wie bisher, von dem Fahrzeug 1, 1' ab, sondern von dem Nutzer selbst. Ob nun alle von dem Nutzer gewünschten und ihm zustehenden Funktionalitäten tatsächlich auch genutzt werden können, hängt jedoch auch von weiteren Parametern ab, welche im Sinne der hier vorliegenden Anmeldung unter dem Begriff fahrzeugspezifische Parameter zusammengefasst sind.
In 4 zeigt die obere mit 19, 20 bezeichnete Box alle prinzipiell verfügbaren Funktionen und Anwendungen A bis F, welche entsprechend in dem Fahrzeug vorhanden sind oder heruntergeladen worden sind, analog zu den Szenarien in den 2 und 3.
.Ein Nutzer könnte also über alle Funktionen A bis F verfügen. Ob er dies nun tatsächlich kann oder nicht, hängt neben seinen Lizenzen auch von den fahrzeugspezifischen Bedingungen ab. In einem ersten mit 29 bezeichneten Pfeil wird überprüft, ob die Hardware des Fahrzeugs 1, 1' in der Lage ist, die Funktionen alle darzustellen. Der mit 24 bezeichnete Pfeil prüft eine entsprechende lokale Funktionalität, ob beispielsweise die entsprechende Funktion A bis F in dem jeweiligen Land, in welchem sich das Fahrzeug befindet, zulässig ist. Ein weiterer Aspekt hat mit der Lizenzierung zu tun. Hat der Nutzer nicht alle verfügbaren Funktionen lizenziert, wie es über den mit 21 analog zur Lizenzierung in den 2 und 3 bezeichneten Pfeil angedeutet ist, stehen ihm bestimmte Funktionen, im Beispiel der 2 und 3 beispielsweise die Funktionen D und F, aus diesem Grund nicht zur Verfügung. Über den Pfeil 25 wird abgefragt, ob die entsprechende Funktionalität in dem User-Interface 17 bzw. dem Personalisierungsspeicher 16 für den entsprechenden Nutzer hinterlegt ist. Im letzten mit 26 bezeichneten Pfeil wird dann überprüft, ob die verfügbaren Sensordaten und damit faktisch die Qualität der verfügbaren Sensordaten eine Nutzung der entsprechenden Funktion A bis F zulassen. So können beispielsweise bei entsprechend schlechten Witterungsbedingungen bestimmte Funktionalitäten nicht oder nicht in vollem Umfang genutzt werden, beispielsweise Funktionalitäten des autonomen Fahrens oder andere Funktionalitäten, welche hinsichtlich der Qualität der erfassten Sensordaten auch von den Umgebungsbedingungen, wie beispielsweise der Witterung oder Ähnlichem, abhängen.
Sind all diese Punkte überprüft, werden dem Nutzer analog zur Darstellung in den 2 und 3 verschiedene Funktionen und Anwendungen A bis F zur Verfügung gestellt. Dies ist auch hier wieder in der mit 22 bezeichneten Box entsprechend angedeutet. Im hier dargestellten Ausführungsbeispiel sind dabei lediglich die Funktionen B und E verfügbar, weil beispielsweise die Funktion C analog zu dem Szenario in 3 für den jeweiligen Nutzer nicht zur Verfügung steht, weil die Funktionen D und F nicht lizenziert wurden und weil die Funktion A beispielsweise aufgrund lokaler Vorschriften oder der nicht ausreichenden Qualität von Sensordaten nicht verfügbar gemacht werden darf bzw. kann.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102011109720 A1 [0003]
DE 102016008981 A1 [0004, 0012]

Claims

Fahrzeugbetriebssystem (2) mit einem Funktionsspeicher (3) zum Speichern von Funktionen oder Anwendungen (A, B, ..., F) mit einer Schnittstelle (4) zur Ausgabe von festgelegten Sensordaten an die Funktionen oder Anwendungen (A, B, ..., F) und mit einer Schnittstelle (6) zur Weitergabe von durch die Funktionen oder Anwendungen (A, B, ..., F) generierten Steuerbefehlen an Aktuatoren des Fahrzeugs (1), dadurch gekennzeichnet, dass ein Speicher (8) vorgesehen ist, in welchem fahrzeugseitig festgelegte zulässige Wertebereiche für die Steuerbefehle hinterlegt sind, wobei die Schnittstelle (6) zur Weitergabe der Steuerbefehle die Steuerbefehle nur im Rahmen der in dem Speicher (8) hinterlegten Wertebereiche weitergibt.
Fahrzeugbetriebssystem (2) nach Anspruch 1, dadurch gekennzeichnet, dass ein Kommunikationsmodul (9) zur Verbindung zumindest des Funktionsspeichers (3) mit einem Backend-Server (11) vorgesehen ist.
Fahrzeugbetriebssystem (2) nach Anspruch 2, dadurch gekennzeichnet, dass ein Personalisierungsspeicher (16) vorgesehen ist, welcher mit dem Funktionsspeicher (3) und dem Kommunikationsmodul (9) verbunden ist, und in welchem gespeichert ist, welche der Funktionen oder Anwendungen (A, B, ..., F) einem Nutzer zur Verfügung stehen.
Fahrzeugbetriebssystem (2) nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenigstens eine der Funktionen (A, B, ..., F) zur Ausgabe von Steuerbefehlen an eine Scheinwerfersteuerung ausgebildet ist.
Verfahren zum Betreiben eines Fahrzeugbetriebssystems (2), bei welchem Funktionen oder Anwendungen (A, B, ..., F) in einen Funktionsspeicher (3) geladen werden, welche auf Basis von Daten einer Datenschnittstelle (4) Steuerungsfunktionen in dem Fahrzeug (1) ausführen, indem sie Steuerbefehle über eine Schnittstelle (6) an das Fahrzeug (1) senden, dadurch gekennzeichnet, dass fahrzeugseitig ein Wertebereich der Steuerbefehle auf einen jeweils zulässigen Wertebereich begrenzt wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass über die Datenschnittstelle (4) Daten gemäß vorgegebener Modelle von einer Sensorfunktion (5) bereitgestellt werden, welche der Kontrolle des Fahrzeugherstellers unterliegen.
Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass die Funktionen und Anwendungen (A, B, ..., F) vom Fahrzeughersteller und/oder von Drittanbietern erstellt und über einen Backend-Server (11) und ein Kommunikationsmodul (9) in den Funktionsspeicher (3) des Fahrzeugbetriebssystems (2) geladen werden.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass die Freigabe der geladenen Funktionen oder Anwendungen (A, B, ..., F) anhand von Nutzerdaten und/oder in Abhängigkeit von fahrzeugspezifischen Daten erfolgt.
Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass in eine Schnittstelle zwischen dem Kommunikationsmodul (9) und dem Backend-Server (11) eine Bezahlfunktion integriert ist.
Verfahren nach einem der Ansprüche 5 bis 9, dadurch gekennzeichnet, dass die Funktionen oder Anwendungen (A, B, ..., F) fahrzeugspezifische Basisfunktionen (A, B, C) und, insbesondere einem Nutzer zugeordnete, erweiterte Funktionen oder Anwendungen (D, E, F) umfassen.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die erweiterten Funktionen oder Anwendungen (D, E, F) in Abhängigkeit des Nutzers des Fahrzeugs (1, 1') über das Kommunikationsmodul (9) in das Fahrzeug (1, 1') geladen werden.
Verfahren nach einem der Ansprüche 7 bis 11, dadurch gekennzeichnet, dass Fahrzeugdaten in Abhängigkeit einer Nutzerzustimmung anonymisiert über das Kommunikationsmodul (9) an den Backend-Server (11) übertragen und in dem Backend-Server verarbeitet und gegebenenfalls weiterverteilt werden.