DE102011075064A1

DE102011075064A1 - Verfahren und System zum Implementieren und Durchsetzen von Sicherheits- und Betriebsmittelrichtlinien für ein Fahrzeug

Info

Publication number: DE102011075064A1
Application number: DE102011075064A
Authority: DE
Inventors: Michael Raymond Westra; Sandeep Waraich; Sukhwinder Wadhwa; Michael J. Schanerberger; Jason Bernard Johnson; Julius Marchwicki
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2010-05-27
Filing date: 2011-05-02
Publication date: 2011-12-01
Also published as: US20110295444A1; US9639688B2; CN102332067A

Abstract

Bei einer oder mehreren Ausführungsformen umfasst ein Fahrzeugbetriebsmittel-Benutzungskontrollsystem einen Fahrzeugcomputer, der Sicherheitsrichtlinien aufweist, die Benutzungsregeln für ein oder mehrere Fahrzeugbetriebsmittel definieren. Eine oder mehrere mit dem Fahrzeugcomputer kommunizierende Einrichtungen können im Speicher installiert Softwareanwendungen aufweisen, die zum Betrieb ein oder mehrere Fahrzeugbetriebsmittel verwenden. Es können programmierte Anweisungen empfangen werden, die definieren, welches des einen oder der mehreren Fahrzeugbetriebsmittel die Softwareanwendungen zum Betrieb verwenden. Diese programmierten Anweisungen können mit der einen oder den mehreren Sicherheitsrichtlinien assoziiert sein. Die mit den Softwareanwendungen assoziierte Sicherheitsrichtlinie kann auf der Basis der programmierten Anweisungen bestimmt werden. Der Betrieb der Softwareanwendungen kann gemäß der Sicherheitsrichtlinie gestattet werden.

Description

Verschiedene Ausführungsformen betreffen mit der Verwendung eines Fahrzeugdatenverarbeitungssystems assoziierte Sicherheitskontrollelemente. Bei bestimmten Ausführungsformen betreffen die Sicherheitskontrollelemente die Regelung der Verwendung von Fahrzeugbetriebsmitteln bei Verwendung von Anwendungen, die auf einer oder mehreren Einrichtungen installiert sind, über das Fahrzeugdatenverarbeitungssystem. Die eine oder mehreren Einrichtungen können von dem Fahrzeugdatenverarbeitungssystem entfernt sein.
Es gibt verschiedene Beispiele auf dem Gebiet des Regelns der Verwendung von Computerbetriebsmitteln und des Implementierens von Computersicherheitsrichtlinien. Zum Beispiel offenbart das US-Patent Nr. 7,207,041 für Elsen et al. ('041-Patent) eine offene Plattform-Architektur zur Zugangsverwaltung gemeinsam benutzter Betriebsmittel. Das '041-Patent offenbart ein Umlenkungsmodul im Kernel-Raum, das Anforderungen des Zugangs zu Betriebsmitteln von Anwendungen im Benutzerraum empfängt. Das Umlekungsmodul routet die empfangene Anforderungen repräsentierenden Signale zu einer Einrichtungstreiberschnittstelle im Benutzerraum. Komponenten der Einrichtungstreiberschnittstelle umfassen Betriebsmittelverwaltungsmodule und Einrichtungstreiber, die verfügbaren Betriebsmitteln entsprechen. Die Betriebsmittelverwaltungsmodule erzeugen Abfragen an die Einrichtungstreiber bezüglich Verfügbarkeit der angeforderten Betriebsmittel. Beim Empfang von Betriebsmittelstatusinformationen von den Einrichtungstreibern erzeugen Komponenten der Einrichtungstreiberschnittstelle Ablaufpläne zum Gewähren des Zugangs zu den angeforderten Betriebsmitteln. Ferner steuern die Einrichtungstreiberschnittstellenkomponenten den Zugang zu den Betriebsmitteln gemäß den erzeugten Ablaufplänen, einschließlich des Ausgebens von Antworten an die anfordernden Anwendungen und die Einrichtungstreiber der angeforderten Betriebsmittel.
Die US-Patentpublikation Nr. 2007/0050854 für Cooperstein et al. ('854 Publikation) offenbart auf Betriebsmitteln basierende dynamische Sicherheitsautorisierung. Der Zugang zu einem Betriebsmittel durch Sandboxed-Code wird auf der Basis einer auf Betriebsmitteln basierenden Richtlinie durch ein Client-Sicherheitssystem dynamisch autorisiert. Einer auf einem Client ablaufenden Sandboxed-Anwendung wird auf der Basis einer auf Betriebsmitteln basierenden Richtlinie trotz Verweigerung des Zugangs auf der Basis einer mit dem Client-Sicherheitssystem assoziierten statischen Richtlinie Zugang zu einem Betriebsmittel gewährt. Das Gewähren des Zugangs fällt mit der Bestimmung zusammen, dass die Gefahr für einen Benutzer oder die Informationen des Benutzers nicht vergrößert wird, falls der Zugang gewährt wird.
Die US Patentpublikation Nr. 2008/0148374 für Spaur et al. offenbart ein Telematiksystem, das eine Sicherheitssteuerung umfasst. Die Sicherheitssteuerung ist dafür verantwortlich, sicheren Zugang zu Betriebsmitteln in dem Fahrzeug und kontrollierte Verwendung dieser sicherzustellen. Die von der Sicherheitssteuerung verwendeten Sicherheitsmaßnahmen können auf digitalen Zertifikaten basieren, die Zertifikathaltern, z. B. Anwendungsentwicklern, Rechte gewähren. Falls Anwendungen mit Fahrzeugbetriebsmitteln zu verwenden sind, werden Prozeduren implementiert, um sicherzustellen, dass zertifizierte Anwendungen die Sicherheit von Fahrzeugbetriebsmitteln und die Sicherheit von Fahrzeugbenutzern nicht gefährden. Es werden Beziehungen zwischen interessierten Entitäten hergestellt, um sicheren Zugang zu Fahrzeugbetriebsmitteln und sichere Verwendung dieser zu fördern und zu unterstützen. Die Entitäten können Fahrzeughersteller, Kommunikationsdienstanbieter, Kommunikationsvorrichtungshändler, Fahrzeugsubsystem-lieferanten, Anwendungsentwickler sowie Fahrzeugeigentümer/-benutzer umfassen. Mindestens bestimmte der Entitäten können Mitglieder einer Föderation sein, die hergestellt wird, um sicheren Zugang zu Fahrzeugbetriebsmitteln und sichere Verwendung dieser zu fördern und zu ermöglichen.
Ein Aspekt umfasst ein Fahrzeugbetriebsmittel-Benutzungskontrollsystem. Das System kann einen Fahrzeugcomputer umfassen, der eine oder mehrere Sicherheitsrichtlinien aufweist, die Benutzungsregeln für ein oder mehrere Fahrzeugbetriebsmittel definieren. Die eine oder die mehreren Sicherheitsrichtlinien können Vorgabe- oder spezifische Richtlinien sein. Bei bestimmten Ausführungsformen kann der Fahrzeugcomputer ein Virtuelle-Maschine-Computer sein, der in einem computerlesbaren Medium verkörpert wird.
Der Fahrzeugcomputer kann dafür ausgelegt sein, mit einer oder mehreren Einrichtungen zu kommunizieren, die im Speicher installiert eine oder mehrere Softwareanwendungen aufweisen, die zum Betrieb ein oder mehrere Fahrzeugbetriebsmittel verwenden. Der Computer kann ferner dafür ausgelegt sein, programmierte Anweisungen zu empfangen, die definieren, welches des einen oder der mehreren Fahrzeugbetriebsmittel die Softwareanwendung zum Betrieb verwendet. Die programmierten Anweisungen können mit der einen oder den mehreren Sicherheitsrichtlinien assoziiert sein. Der Fahrzeugcomputer kann ferner dafür ausgelegt sein, die mit der einen oder den mehreren Softwareanwendungen assoziierte Sicherheitsrichtlinie auf der Basis der programmierten Anweisungen zu bestimmen. Betrieb der einen oder der mehreren Softwareanwendungen gemäß der Sicherheitsrichtlinie kann gestattet werden.
Bei einer Ausführungsform kann der Fahrzeugcomputer einen Betriebsmittelbenutzungstimer umfassen. Dementsprechend kann die Sicherheitsrichtlinie eine Zeitgrenze für das Ausführen der programmierten Anweisungen definieren. Zusätzlich kann der Fahrzeugcomputer ferner dafür ausgelegt sein, eine Fehlernachricht zu senden, wenn die Ausführung der programmierten Anweisungen die Zeitgrenze überschreitet. Zusätzlich kann der Fahrzeugcomputer ferner dafür ausgelegt sein, die Ausführung der programmierten Anweisungen zu beenden.
Ein anderer Aspekt kann ein Verfahren zum Kontrollieren der Benutzung von Fahrzeugbetriebsmitteln durch eine oder mehrere auf einer oder mehreren mit einem Fahrzeugcomputer kommunizierenden Einrichtungen installierte Softwareanwendungen umfassen. Das Verfahren kann das Vergeben einer Fahrzeugbetriebsmittel-Zugangsebene für ein oder mehrere Fahrzeugbetriebsmittel umfassen. Es können eine oder mehrere Sicherheitsrichtlinien hergestellt werden, die die Benutzungsregeln für ein oder mehrere Fahrzeugbetriebsmittel auf der Basis der Fahrzeugbetriebsmittel-Zugangsebene definieren. Die Fahrzeugbetriebsmittel-Zugangsebene kann allgemeinen Zugang zu Fahrzeugbetriebsmitteln oder spezifischen Zugang zu Fahrzeugbetriebsmitteln definieren und kann auf einer Empfindlichkeit der Funktionalität der Fahrzeugbetriebsmittel basieren. Eine spezifische Zugangsebene kann im Vergleich zu der allgemeinen Zugangsebene Zugang zu zusätzlichen Fahrzeugbetriebsmitteln umfassen.
Das Verfahren kann ferner das Empfangen von programmierten Anweisungen umfassen, die definieren, welches des einen oder der mehreren Fahrzeugbetriebsmittel die eine oder mehreren Softwareanwendungen zum Betrieb verwenden. Auf der Basis der programmierten Anweisungen kann eine Sicherheitsrichtlinie mit der einen oder den mehreren Softwareanwendungen assoziiert werden. Der Betrieb der einen oder der mehreren Softwareanwendungen kann gemäß der Sicherheitsrichtlinien gestattet werden.
Bei einer Ausführungsform kann das Verfahren ferner das Empfangen einer Anwendungsprogrammierschnittstelle zum Kommunizieren mit dem einen oder den mehreren Fahrzeugmodulen umfassen. Die eine oder mehreren Sicherheitsrichtlinien können dynamisch sein, so dass die eine oder mehreren Sicherheitsrichtlinien auf der Basis des Empfangens der Anwendungsprogrammierschnittstelle hergestellt werden.
Ein anderer Aspekt kann ein Verfahren umfassen, das das Empfangen von Anweisungen über ein allgemeines Protokoll zur Verwendung von Fahrzeugbetriebsmitteln zum Betrieb einer auf zwei oder mehr Einrichtungen, die verschiedene Kommunikationsprotokolle aufweisen, installierten Anwendung auf einem Fahrzeugcomputer umfasst. Die Anweisungen können eine Dienst- oder Betriebsanforderung für eine Anwendung von den zwei oder mehr Einrichtungen umfassen. Bei einer Ausführungsform können die Anweisungen auf dem Fahrzeugcomputer gespeichert werden, und nachdem die Anweisungen validiert wurden, können die Anweisungen entfernt werden.
Auf der Basis einer Assoziation zwischen der Anwendung und der Sicherheitsrichtlinie kann eine Benutzungssicherheitsrichtlinie, die mit der Anwendung assoziiert wird, bestimmt werden. Daten können über das allgemeine Transportprotokoll zum Betrieb der Anwendung auf dem Fahrzeugcomputer auf der Basis der Sicherheitsrichtlinie ausgetauschte Daten sein.
Diese und andere Aspekte werden hinsichtlich der beigefügten Zeichnungen und der folgenden ausführlichen Beschreibung der Erfindung besser verständlich.
Die nachfolgend identifizierten Figuren veranschaulichen bestimmte Ausführungsformen der Erfindung. Die Figuren sollen die in den angefügten Ansprüchen aufgeführte Erfindung nicht beschränken. Die Ausführungsformen werden sowohl in Bezug auf ihre Organisation als auch auf ihre Betriebsweise zusammen mit weiteren Aufgaben und Vorteilen dieser am besten mit Bezug auf die folgende Beschreibung in Verbindung mit den beigefügten Zeichnungen verständlich. Es zeigen:
1 eine Blocktopologie eines Fahrzeugdatenverarbeitungssystems;
2 eine Systemarchitektur zum Durchsetzen von Betriebsmittel- und Sicherheitsrichtlinien des Fahrzeugdaten-verarbeitungssystems von 1 gegenüber einer oder mehreren von einem Fahrzeug aus betriebenen Softwareanwendungen;
3 einen Prozess zum Implementieren von Betriebsmittelrichtlinien des Fahrzeugdatenverarbeitungssystems gegenüber einer oder mehreren von einem Fahrzeug aus betriebenen Softwareanwendungen;
4 einen Prozess zum Bestimmen einer auf die eine oder mehreren von einem Fahrzeug aus betriebenen Softwareanwendungen anzuwendenden Betriebsmittelrichtlinie;
5 einen Prozess zum Durchsetzen einer oder mehrerer Betriebsmittel- und Sicherheitsrichtlinien gegenüber einer oder mehreren von einem Fahrzeug aus betriebenen Softwareanwendungen.
Es gibt naturgemäße Risiken bei der Verwendung von nicht vertrauenswürdigen Anwendungen auf einer Datenverarbeitungseinrichtung. Zum Beispiel können nicht vertrauenswürdige Anwendungen Schadcode enthalten, Datenverarbeitungsbetriebsmittel wie Computerspeicher erschöpfen oder den ordnungsgemäßen Betrieb der Datenverarbeitungseinrichtung anderweitig stören. In diesem Kontext ist eine nicht vertrauenswürdige Anwendung eine Anwendung, die entfernt von der Datenverarbeitungseinrichtung gespeichert ist und in die Datenverarbeitungseinrichtung, wie etwa einen Personal Computer, einen Fahrzeugcomputer, ein Mobilgerät (wie etwa ein Mobiltelefon, PDS, Smartphone usw.), einen persönlichen Medienplayer und dergleichen heruntergeladen und/oder davon betrieben wird. Beispielsweise kann Software, die über das Internet auf einen Personal Computer heruntergeladen wird, eine nicht vertrauenswürdige Anwendung sein.
Nicht vertrauenswürdige Anwendungen können in vielfältigen Umgebungen verwendet werden. Ein Beispiel ist in und/oder mit einem Fahrzeugcomputer, wie etwa dem SYNC-System von THE FORD MOTOR COMPANY. In dieser Umgebung können auf einem Mobilgerät (das auch als ”mobile Anwendungen” bezeichnet wird) installierte Anwendungen von dem Fahrzeugcomputer (z. B. SYNC) aus über Sprachbefehle und/oder Tastenbetätigungen von einem Benutzer betrieben werden. Der Fahrzeugcomputer kommuniziert mit einer Anzahl von Fahrzeugmodulen, wie etwa dem Kraftübertragungssteuermodul (PCM), dem Airbag-Steuermodul (ACM), der Motorsteuereinheit (ECU) und anderen ähnlichen Modulen. Dementsprechend dürfen nicht vertrauenswürdige Anwendungen, die in einer Fahrzeugumgebung verwendet werden können, keinen uneingeschränkten Zugang zu Fahrzeugbetriebsmitteln besitzen. Deshalb sollten nicht vertrauenswürdige Anwendungen identifiziert und die Verwendung von Fahrzeugbetriebsmitteln durch die nicht vertrauenswürdigen Anwendungen geregelt werden.
Es werden hier ausführliche Ausführungsformen der Erfindung offenbart. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für eine Verbindung sind, die in verschiedenen und alternativen Formen realisiert werden kann. Hier offenbarte spezifische Funktionsdetails sind deshalb nicht als die Ansprüche beschränkend zu interpretieren, sondern lediglich als repräsentative Grundlage dieser, und/oder als repräsentative Grundlage, um Fachleuten zu lehren, die vorliegende Erfindung verschiedenartig zu verwenden.
Es versteht sich, dass, obwohl die verschiedenen Ausführungsformen mit Bezug auf die Verwendung eines Datenverarbeitungssystems in einem Automobil beschrieben werden, es andere Umgebungen geben kann, in denen nicht vertrauenswürdige Anwendungen benutzt werden können. Nicht-einschränkende Beispiele für solche Umgebungen wären eine Wohnung, ein Büro, eine Schule, ein Flugzeug, ein Zug, ein Bus, eine Bibliothek und andere ähnliche Umgebungen.
1 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem 1 für ein Fahrzeug 31. Ein mit einem fahrzeuggestützten Datenverarbeitungssystem befähigtes Fahrzeug kann eine visuelle Frontend-Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann auch in der Lage sein, mit der Schnittstelle in Dialog zu treten, wenn sie zum Beispiel mit einem berührungsempfindlichen Schirm ausgestattet ist. Bei einer anderen beispielhaften Ausführungsform erfolgt der Dialog durch Tastenbetätigungen, hörbare Sprache und Sprachsynthese.
Bei der in 1 gezeigten beispielhaften Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems. Der Prozessor ist in dem Fahrzeug vorgesehen und erlaubt Onboard-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nicht persistentem 5 als auch persistentem Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nicht persistente Speicher Direktzugriffsspeicher (RAM) und der persistente Speicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher.
Der Prozessor ist außerdem mit einer Anzahl verschiedener Eingänge ausgestattet, die es dem Benutzer erlauben, eine Schnittstelle mit dem Prozessor herzustellen. Bei dieser beispielhaften Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 vorgesehen. Außerdem ist eine Eingangsselektor 51 vorgesehen, um es einem Benutzer zu erlauben, zwischen verschiedenen Eingängen zu wechseln. Die Eingabe sowohl in den Mikrofon- als auch in den Hilfsverbinder wird durch einen Umsetzer 27 von analog in digital umgesetzt, bevor sie zu dem Prozessor geleitet wird.
Ausgänge des Systems können, aber ohne Beschränkung darauf, eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereoanlagenausgang umfassen. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Umsetzer 9 von dem Prozessor 3. Es können auch Ausgaben an eine entfernte BLUETOOTH-Einrichtung, wie etwa eine PND 54 oder eine USB-Einrichtung wie ein Fahrzeugnavigationsgerät 60 entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, erfolgen.
Bei einer beispielhaften Ausführungsform verwendet das System 1 den BLUETOOTH-Sender/Empfänger 15 zur Kommunikation 17 mit der ortsungebundenen Einrichtung 53 (z. B. Mobiltelefon, Smartphone, PDA usw.) eines Benutzers. Die ortsungebundene Einrichtung kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Die beispielhafte Kommunikation zwischen der ortsungebundenen Einrichtung und dem BLUETOOTH-Sender/Empfänger wird durch das Signal 14 repräsentiert.
Das Paaren einer ortsungebundenen Einrichtung 53 und des BLUETOOTH-Senders/-Empfängers 15 kann durch eine Taste 52 oder ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der Onboard-BLUETOOTH-Sender/-Empfänger mit einem BLUETOOTH-Sender/-Empfänger in einer ortsungebundenen Einrichtung gepaart werden wird.
Zwischen der CPU 3 und dem Netzwerk 61 können zum Beispiel mit einem Datenplan, Data Over Voice oder DTMF-Tönen, die mit der ortsungebundenen Einrichtung 53 assoziiert sind, Daten übermittelt werden. Als Alternative kann es wünschenswert sein, ein Onboard-Modem 63 vorzusehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übermitteln 16. Die ortsungebundene Einrichtung 53 kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann das Moden 63 zur Kommunikation mit dem Netzwerk 61 Kommunikation 20 mit dem Mast 57 herstellen. Als nicht einschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein, und die Kommunikation 20 kann Mobilfunk-Kommunikation sein.
Bei einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API zur Kommunikation mit Modem-Anwendungssoftware umfasst. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder Firmware in dem BLUETOOTH-Sender/-Empfänger zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sender/-Empfänger (wie etwa dem in einer ortsungebundenen Einrichtung angetroffenen) abzuschließen.
Bei einer anderen Ausführungsform umfasst die ortsungebundene Einrichtung 53 ein Modem zur Sprachband- oder Breitband-Datenkommunikation. Bei der Data-Over-Voice-Ausführungsform kann eine als Frequenzmultiplexen bekannte Technik implementiert werden, wenn der Eigentümer der ortsungebundenen Einrichtung über die Einrichtung sprechen kann, während Daten transferiert werden. Zu anderen Zeiten kann der Datentransfer, wenn der Eigentümer die Einrichtung nicht verwendet, die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) verwenden.
Wenn der Benutzer einen mit der ortsungebundenen Einrichtung assoziierten Datenplan besitzt, ist es möglich, dass der Datenplan Breitbandübertragung erlaubt und das System eine wesentlich größere Bandbreite verwenden könnte (wodurch der Datentransfer beschleunigt wird). Bei noch einer weiteren Ausführungsform wird die ortsungebundene Einrichtung 53 mit einem (nicht gezeigten) Mobilfunk-Kommunikationsgerät ersetzt, das in dem Fahrzeug 31 installiert wird. Bei noch einer weiteren Ausführungsform kann die ND 53 eine drahtlose LAN-Einrichtung (LAN = lokales Netzwerk) sein, die zum Beispiel (und ohne Beschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMAX-Netzwerk kommunizieren kann.
Bei einer Ausführungsform können ankommende Daten durch die ortsungebundene Einrichtung über einen Data-Over-Voice- oder Datenplan durch den Onboard-BLUETOOTH-Sender/-Empfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf der HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die an das Fahrzeug angeschaltet werden können, wären ein persönliches Navigationsgerät 54, das zum Beispiel eine USB-Verbindung 56 oder eine Antenne 58 aufweist; oder ein Fahrzeugnavigationsgerät 60 mit einem USB 62 oder einer anderen Verbindung, ein Onboard-GPS-Gerät 24 oder Fernnavigationssystem (nicht gezeigt) mit Konnektivität zu dem Netzwerk 61.
Ferner könnte sich die CPU in Kommunikation mit vielfältigen anderen Hilfseinrichtungen 65 befinden. Diese Einrichtungen können durch eine drahtlose 67 oder verdrahtete 69 Verbindung verbunden werden. Außerdem oder als Alternative könnte die CPU zum Beispiel unter Verwendung eines WiFi-Senders/-Empfängers 71 mit einem fahrzeuggestützten drahtlosen Router 73 verbunden werden. Dadurch könnte sich die CPU mit entfernten Netzwerken in der Reichweite des lokalen Routers 73 verbinden.
2 zeigt einen nicht einschränkenden Rahmen, in dem ein Benutzer eine Schnittstelle mehrerer Einrichtungen mit einem Fahrzeugdatenverarbeitungssystem (VCS) 1 herstellen kann. Genauer gesagt kann das System 100 einem Benutzer gestatten, eine Schnittstelle der Anwendungen 103a–f, die auf den Einrichtungen 102a–f installiert sind, mit dem VCS 1 zum Betrieb der Anwendungen 103a–f durch das VCS 1 herzustellen. Das Betreiben der Anwendungen 103a–f kann, aber ohne Beschränkung darauf, Folgendes umfassen: Aktivieren der Anwendungen, Eingeben von Befehlen und Anweisungen (über Sprache, Tastenbetätigungen usw.) und Empfangen von Ausgaben (z. B. visuelle, grafische, textliche, hörbare und andere ähnliche Ausgaben).
Es versteht sich jedoch, dass die Architektur von 2 und die assoziierte Beschreibung nicht einschränkend ist. Zum Beispiel und ohne Beschränkung kann der Betrieb der Anwendungen 103a–f zusätzlich oder als Alternative durch die Einrichtungen 102a–f erfolgen. Zum Beispiel und ohne Beschränkung können die Eingaben, Ausgaben und Befehle an der Einrichtung 102a–f erfolgen.
Ferner versteht sich, dass die verschiedenen in Bezug auf 2 beschriebenen Ausführungsformen zusätzlich oder als Alternative für Telematikunterstützung verwendet werden können. Als nicht einschränkendes Beispiel können die verschiedenen Ausführungsformen beim Austauschen von Fahrzeugintegritätsberichtsdaten verwendet werden. Als weiteres nicht einschränkendes Beispiel können die verschiedenen Ausführungsformen beim Austauschen von Lizensierungsdaten für eine Anwendung 103a–f verwendet werden. Als weiteres nicht einschränkendes Beispiel können die verschiedenen Ausführungsformen zur Ferntürentriegelung verwendet werden.
Nunmehr mit Bezug auf 2 können eine oder mehrere Einrichtungen 102a–f vorliegen, die eine Schnittstelle mit dem VCS 1 aufweisen können. Der Veranschaulichung und Klarheit halber ist 2 jedoch mit mehreren Einrichtungen 102a–f gezeigt. Nicht einschränkende Beispiele für solche Einrichtungen wären Mobiltelefone, in der Hand gehaltene Diagnostikwerkzeuge, Personal Computers, Smartphones, PDAs (Personal Digital Assistants), Mediengeräte (z. B. und ohne Beschränkung MP3-Player), tragbare Speichereinrichtungen (z. B. und ohne Beschränkung USB-Thumbdrives, Speicherkarten/-Sticks, SLOTMUSIC-Karten und andere geeignete Speichereinrichtungen) und/oder Adapter zur Aufnahme dieser Speichereinrichtungen und andere Einrichtungen, die jetzt oder später bekannt sein können.
Die auf den Einrichtungen 102a–f installierten Anwendungen 103a–f können auf der Einrichtung 102a–f fabrikinstalliert oder durch einen Benutzer nach dem Kauf der Einrichtung 102a–f installiert werden. Zum Beispiel und ohne Beschränkung kann der Benutzer die Anwendung von einem computerlesbaren Medium (z. B. einer CD oder einem Thumbdrive) aus installieren oder die Anwendung über das Internet herunterladen. Bei bestimmten Ausführungsformen kann der Benutzer die Anwendung 103a–f entwickeln.
Ein Benutzer kann, aber ohne Beschränkung darauf, Folgendes umfassen, einen Verbraucher, einen Fahrzeughändler (und von dem Händler angestellte Personen), oder eine Servicewerkstatt (und von der Werkstatt angestellte Personen). Nicht einschränkende Beispiele für Anwendungen 103a–f, die auf den Einrichtungen 102a–f installiert sein können, wären Fahrzeugdiagnostikanwendungen, Kommunikationsanwendungen (z. B. und ohne Beschränkung E-Mail, VOIP und Textnachrichten), Unterhaltungsanwendungen (z. B. und ohne Beschränkung Multimedia-Streaming, Videos, Musik, Spiele usw.), Sozialnetzwerk-Anwendungen, auf dem Ort basierende Anwendungen, Internetanwendungen, auf persönlicher Werbung basierende Anwendungen und anderes.
Jede Einrichtung 102a–f kann durch einen oder mehrere Kommunikationskanäle unter Verwendung eines oder mehrerer Kommunikationsprotokolle 104a–f Daten übermitteln. Nicht einschränkende Beispiele für solche Kommunikationsprotokolle 104a–f wären die BLUETOOTH-Protokolle, 802.11-Protokolle, TCP/IP, proprietäre Protokolle (wie zum Beispiel, ohne Beschränkung, das iAP-Protokoll von APPLE CORPORATION), Massenspeicherprotokolle (z. B. USB-Protokolle), auf USB basierende Vernetzungsprotokolle (z. B. und ohne Beschränkung USB-seriell oder USB-RNDIS) und andere Protokolle, die jetzt oder später bekannt sind. Es versteht sich, dass die Einrichtungen 102a–f Daten unter Verwendung mehrerer Kommunikationsprotokolle (z. B. und ohne Beschränkung BLUETOOTH und 802.11) übermitteln können.
Diese Beziehung zwischen dem VCS 1 und den Einrichtungen 102a–f kann als ein Netzwerk bezeichnet werden. Bei bestimmten Ausführungsformen kann die Beziehung zwischen den Einrichtungen 102a–f und dem VCS 1 ein ”Ad-hoc”-Netzwerk erzeugen.
Wieder mit Bezug auf 2 kann mit Bezug auf BLUETOOTH-fähige Einrichtungen jede Einrichtung außerdem ein oder mehrere BLUETOOTH-Profile umfassen, die definieren, mit welchen Einrichtungen die BLUETOOTH-fähige Einrichtung kommunizieren kann. Profile können Standardprofile sein (wie etwa A2DP, HFP, SDAP und HSP) oder angepasste Profile.
Die Einrichtungen 102a–f können unter Verwendung eines oben beschriebenen Kommunikationskanals eine Verbindung mit dem VCS 1 herstellen. Bei einer Ausführungsform können die Einrichtungen 102a–f nach einer Verbindungsanforderung von dem VCS 1 horchen. Bei anderen Ausführungsformen kann das VCS 1 nach Verbindungsanforderungen von den Einrichtungen 102a–f horchen. Wenn eine Verbindung hergestellt wird, kann ein Datentransportmanager 106 (der auf die CPU 3 des VCS 1 als Software implementiert werden kann oder auch nicht) die von der einen oder den mehreren Anwendungen 103a–f (über die Einrichtung 102a–f) übermittelten Nachrichten/Daten empfangen und die Nachrichten/Daten zur weiteren Übertragung verarbeiten.
Bei bestimmten Ausführungsformen können die Einrichtungen 102a–f gleichzeitig mit dem VCS 1 verbunden werden. Bei anderen Ausführungsformen kann die Einrichtung 102a–f individuelle und separate (d. h. nicht gleichzeitige) Verbindungen herstellen.
Der Transportmanager 106 kann diese Daten zu dem Sicherheitsmanager 108 senden. Dementsprechend kann der Transportmanager 106 die Kommunikation zwischen der Einrichtung 102a–f und dem Sicherheitsmanager 108 ermöglichen. Weitere Einzelheiten des Sicherheitsmanagers werden später beschrieben. Bei bestimmen Ausführungsformen kann der Transportmanager auch mit einem (nicht gezeigten) Datenmanager kommunizieren, der die Daten zu dem Sicherheitsmanager übermitteln kann. Der Datenmanager kann zwischen Anwendungen verfügbare Systemdaten in einer Datenbankstruktur speichern.
Nicht einschränkende Beispiele für die Aufgaben des Transportmanagers 106 wären Abstrahieren (d. h. Standardisieren) der Kommunikationsprotokolle 104a–f und Weiterleiten der folgenden nicht einschränkenden Informationen: Daten, Transportzustandsänderungen, entdeckte Anwendungen und Startanforderungen. Der Transportmanager 106 kann diesen Aufgaben als die Schnittstelle zum Verbinden mit einer Einrichtung 102a–f mit einem gegebenen Namen über einen gegebenen Kommunikationskanal 104a–f erfüllen. Insbesondere kann der Transportmanager 106 Daten über eine existierende Sitzung senden und/oder empfangen. Eine Sitzung kann eine logische Verbindung zwischen einer Anwendung 103a–f auf der Einrichtung 102a–f und dem VCS 1 sein. Ferner kann der Transportmanager 106 verschiedene Verbindungsabbildungen unterhalten, einschließlich einer Abbildung zwischen Verbindungen und allen aktiven Sitzungen über eine gegebene Verbindung und einer Abbildung zwischen Verbindungen und entsprechenden Kommunikationskanälen 104a–f. Eine 'Verbindung” kann eine Verbindung zwischen den Transportschichten der Einrichtungen 102a–f und dem VCS 1 sein. Dementsprechend kann der Transportmanager den Austausch von Daten zwischen den Anwendungen 103a–f und dem VCS 1 über ein beliebiges der Kommunikationsprotokolle 104a–f, die zum Übermitteln von Daten zu/von der Einrichtung 102a–f verwendet werden, ermöglichen.
Der Transportmanager 106 kann ferner ankommende Verbindungen von der Einrichtung 102a–f empfangen. Der Transportmanager 106 kann die Verbindung für jedes Kommunikationsprotokoll 104a–f bestimmen und verwalten. Bei bestimmten Ausführungsformen kann dies durch ein Datentransport-Plugin durchgeführt werden. Ein Plugin kann für proprietäre Protokolle, BLUETOOTH-Protokolle, 802.11-Protokolle und dergleichen existieren. Bei bestimmten Ausführungsformen kann das Plugin 107 als eine Dynamic Link Library (DLL) implementiert werden.
Die durch den Transportmanager 106 hergestellte Verbindung kann das Senden und/oder Empfangen von Daten über eine existierende Verbindung (wie oben definiert) gestatten. Diese Schnittstelle kann von dem zugrundeliegenden Kommunikationstransportprotokoll 104a–f unabhängig sein. Dementsprechend können Fähigkeiten für aktuelle und neue Kommunikationskanäle 104a–f bereitgestellt werden.
Der Transportmanager 106 kann ferner die Art des Dienstes bestimmen, der von den Anwendungen 103a–f angefordert wird. Ein Dienst kann ein Heartbeat (HB), ein Remote Procedure Call (RPC) oder ein Bulk-Dienst sein. Andere nicht einschränkende Dienste wären Medien-Streaming, Verwendung von anwendungsspezifischen Transportprotokollen (z. B. Anwendungen können spezifische Domänenprotokolle aufweisen), Verwendung anderer Protokolle (wie etwa HTTP, FTP, IRC, SOAP und IMAP) und andere geeignete Dienstarten. Allgemeiner kann ein Dienst die Art einer Aktion angeben, die eine Anwendung 103a–f anfordern kann. Bei bestimmten Ausführungsformen kann diese Dienstartbestimmung durch ein separates Protokollmodul durchgeführt werden, das Teil des Transportmanagers 106 sein kann. Bei anderen Ausführungsformen ist das Protokollmodul möglicherweise nicht Teil des Transportmanagers 106, sondern kann mit ihm kommunizieren.
Der Transportmanager 106 ermöglicht Datenaustausch zwischen der Anwendung 103a–f und dem VCS 1 durch ein allgemeines Transportprotokoll, das in dem Transportmanager 106 gespeichert ist. Das Protokoll kann in zwei Schichten (z. B. eine höhere Schicht und eine niedrigere Schicht) aufgeteilt werden. Eine höhere Schicht kann die Funktionsaufrufe enthalten, die zum Erzielen von Einrichtungskommunikation und Systemsteuerfluss erforderlich sind. Eine niedrigere Schicht kann die Grundkommunikationsfunktionen bereitstellen. Diese niedrigere Schicht kann bezüglich der Hardware- und Systemdetails agnostisch sein. Dementsprechend kann dieses Datentransportprotokoll ”transportagnostisch” sein. Auf diese Weise kann das Datentransportprotokoll ein dynamisches Protokoll sein, dergestalt, dass es Erweiterbarkeit ohne signifikante (oder beliebige) Änderungen seiner Architektur unterstützen kann. Anweisungen (d. h. Daten, von den Anwendungen 103a–f können somit über das Datentransportprotokoll transportiert werden, gleichgültig, welches der Kommunikationsprotokolle 104a–f (d. h. sowohl derzeitige als auch zukünftige Kommunikationsprotokolle) die Einrichtung 102a–f zum Transportieren von Daten verwendet.
Zum Beispiel und ohne Beschränkung kann eine Einrichtung die Anwendung 103a–f unter Verwendung von BLUETOOTH betreiben (z. B. unter Verwendung der Protokolle der Hochfrequenzkommunikation (RFComm) und der Logical Link Control and Adaptation (L2CAP)), während eine andere Einrichtung die Anwendungen 103a–f unter Verwendung eines proprietären Protokolls (wie etwa iAP von APPLE) betreiben kann. Das Datentransportprotokoll ermöglicht den Betrieb der Anwendungen auf den jeweiligen Einrichtungen 102a–f von dem VCS 1 aus ohne Rücksicht auf den von jeder Einrichtung verwendeten Datenkommunikationskanal 103a–f. Von der Perspektive eines Benutzers aus gesehen kann die Anwendung auf einer Einrichtung 102a–f nahtlos verwendet werden. Von der Perspektive eines Entwicklers der Anwendung 103a–f aus gesehen, muss die Anwendung nicht individuell auf der Basis der unterschiedlichen Kommunikationsprotokolle 104a–f entwickelt werden.
Der Sicherheitsmanager 108 kann Daten von dem Transportmanager 106 empfangen, um sicherzustellen, dass anwendungsspezifische Richtlinien und/oder Vorgabe-Sicherheitsrichtlinien durchgesetzt werden. Auf diese Weise können die Anwendungen 103a–f nicht größeren Zugang zu den Betriebsmitteln des VCS 1 erhalten, als von den Anwendungen 103a–f benötigt wird. Auf der Basis der Sicherheitsrichtlinien des Sicherheitsmanagers 108 kann ferner jede Anwendung darauf eingegrenzt werden, innerhalb ihrer ”Zuteilungs”-Parameter zu arbeiten. Bei einer Ausführungsform kann die Sicherheitsrichtliniendurchsetzung als eine ”Sandbox”-Umgebung angesehen werden.
Wenn beispielsweise ein Benutzer von einer Einrichtung 102a–f aus anfordert, ein Musikprogramm (z. B. PANDORA) zu betreiben, kann der Sicherheitsmanager 108 die Benutzungsbeschränkungen (d. h. Grenzen) mit Bezug auf VCS-Betriebsmittel des Musikprogramms auf der Basis der computerlesbaren Anweisungen (z. B. Anwendungsscripts) aus der Anwendung 103a–f bestimmen. Genauer gesagt können die Beschränkungen aussagen, dass das Musikprogramm Zugang zu Grafik und Audio erwünscht. Dementsprechend kann der Sicherheitsmanager 108 Zugang zu diesen Betriebsmitteln, aber nicht zu anderen (z. B. Fahrzeugdiagnostikbetriebsmitteln) gestatten. Dementsprechend können die Beschränkungen auf der bestimmten Funktion der Anwendung basieren.
Dementsprechend kann der Sicherheitsmanager 108 bestimmen, welche Betriebsmittel von einer Anwendung 103a–f angefordert werden, und andere Betriebsmittel ausblockieren. Ferner kann er die für jede ankommende Anforderung von einer Anwendung 103a–f definierten Richtlinien bewerten, um ihren Zugang für das Betriebsmittel, zu dem sie Zugang hat, weiter zu beschränken.
Bei einer Ausführungsform kann der Zugang zu den Betriebsmitteln des VCS 1 (z. B. Fahrzeugkontrollelementen 112 und Fahrzeugmodulen 114) durch Anwendungsprogrammierschnittstellen (APIs) 110, die auf dem VCS 1 installiert sind, erreicht werden. Dementsprechend kann der Sicherheitsmanager 108 zusätzlich definieren, welche APIs zugänglich sein können, und Zugangskontrolllisten zum Beschränken des Zugangs zu den APIs bereitstellen.
Diese APIs können durch den Fahrzeug-OEM entwickelt werden. Bei einer Ausführungsform können die APIs als DLLs programmiert und in der Programmiersprache C oder C++ programmiert werden. Die APIs können zusätzlich oder als Alternative in einer Scripting-Sprache geschrieben werden. Bei bestimmten Ausführungsformen können die APIs in derselben Sprache wie der Sicherheitsmanager 108 geschrieben werden. Ferner kann jede API ihre eigene Menge von Sicherheitsparametern umfassen, so dass sie jeweils einzigartige Richtlinienbeschränkungen durchsetzen können.

Nichteinschränkende Beispiele für Fahrzeugkontrollelemente 112 wären Text-zu-Sprache-(TTS-)Funktionalität, Sprache-zu-Text-(STT-)Funktionalität, Sprachkontrollelemente, Tastenkontrollelemente (z. B. Lenkrad-Tastenkontrollelemente und/oder Mittelkonsolen-Tastenkontrollelemente) und Berührungsschirm-Tastenkontrollelemente. Der Betrieb auf einem oder mehreren Fahrzeugmodulen 114 kann als Reaktion auf die Verwendung eines oder mehrerer Fahrzeugkontrollelemente 112 erzielt werden. Daten können über die Kommunikationsverbindung 115 zwischen den Fahrzeugkontrollelementen 112 und den Fahrzeugmodulen 114 gesendet werden. Bei einer Ausführungsform kann die Kommunikationsverbindung ein Fahrzeugnetzwerk 115 sein. Nicht einschränkende Beispiele für Fahrzeugmodule 114 wären Kraftübertragungs-Steuermodule (PCM), Body-Steuermodule (BCM), ABS-Steuermodule, Infotainment-Module und dergleichen. Bei zusätzlichen oder alternativen Ausführungsformen können Daten zur hörbaren, textlichen und/oder grafischen Ausgabe zu anderen Fahrzeugmodulen 114 gesendet werden. Diese können, aber ohne Beschränkung darauf, eine oder mehrere Anzeigen (einschließlich, aber ohne Beschränkung darauf, eine Anzeige 4, Cluster-Schirmanzeigen (nicht gezeigt) oder hintere Unterhaltungsanzeigen (nicht gezeigt)), Lautsprecher 13 oder andere ähnliche Ausgabemodule in dem Fahrzeug 31 umfassen Die APIs können OEM-entwickelte APIs, von Dritten entwickelte APIs und/oder offene APIs sein. Nicht einschränkende Beispiele für APIs und ihre nicht einschränkenden Funktionen, die auf dem VCS 1 installiert sein können, sind in der nachfolgenden Tabelle 1 aufgeführt. Tabelle 1

API	Beschreibung/Funktion
Fahrzeugdialog	Dialog durch Fahrzeugnetzwerkschnittstellenschicht; Dialog mit dem Fahrzeugnetzwerk (z. B. CAN); Diagnostiksystemen, GPS; Zeitgeber; Personalisierung; Clusteranzeige; Tastenereignisse; Türverriegelung; Kraftstoff-/Elektrofahrzeug-Ladestatus.
Anzeige	Menüdialog; grafischer Widget-Dialog; Dialog mit Tasten; Zugang zu Anzeigeeigenschaften; hintere Kamera; Kommunikation mit hinterer Unterhaltung; Hardwarezugang zu 3 D GPU; Zugang zu einer Web-HTML-Wiedergabeengine.
Audio	Dialog mit einer Text-zu-Sprache-(TTS-)Engine; Dialog mit einem Spracherkennungs-modul; Zugang zu Mikrofon-Audiostrom; Digitalaudiowiedergabe; Audiodatei-Push für Wiedergabe.
VCS-Systemverwaltung	Ereignisregistration und Benachrichtigungseinrichtungen; interner Datenbankzugang zu transienten und persistenten Daten (z. B. Medien- und Telefondatenbanken); Zugang zu Systemzustands- und Anwendungszustandsinformationen; Telematik-Warteschlange.
Systemadministration	Erweiterungen zur Bereitstellung von Funktionalität für verschiedene Merkmale des VCS; Sprachenauswahl und Internationalisierung; System konfigurationsparameter; Zugang zu Flash- und externen Dateisystemen; verbundene Einrichtung und indirekter Zugang.
Vernetzung	Vorgabe-Socket-Zugang, Vernetzungszugang; Ereignisse in Bezug auf Netzwerkverfügbarkeit

Es werden nun weitere Einzelheiten des Sicherheitsmanagers 108 beschrieben. Der Sicherheitsmanager 108 kann in dem VCS 1 als Software implementiert sein. Bei einer Ausführungsform kann der Sicherheitsmanager 108 die native Umgebung des VCS 1 imitieren und dementsprechend als virtuelle Maschine dienen. Bei bestimmten Ausführungsformen kann der Zugang des Sicherheitsmanagers 108 jedoch auf bestimmte native Funktionalitäten begrenzt werden. Diese bestimmten nativen Funktionalitäten können die eine oder mehreren APIs in Tabelle 1 betreffen. Nicht einschränkende Beispiele sind wie folgt: Push-to-Talk, Text-zu-Sprache, Benutzeroberfläche, Sprachenauswahl, die VCS-Anzeige (einschließlich Präsentation von Informationen auf der Anzeige, Schreiben auf die Anzeige und Lesen von Informationen aus der Anzeige), Sprachgrammatikmodule, Spracherkennungsmodule, das Mikrofon (über eine Tonerfassungs-API), Audiofunktion (einschließlich Aufzeichnung von Audio und Transfer von Audio zu einer externen Einrichtung), Bildhochlademodule und GPS.
Der Sicherheitsmanager 108 kann ein Ereignismodell unterstützen. In diesem Kontext kann der Sicherheitsmanager 108 ein Subscriber/Publisher-Muster der Nachrichtenübertragung unterstützen, um größere Skalierbarkeit zu gewährleisten. Bei bestimmten Ausführungsformen kann ein (nicht gezeigter) Ereignismanager, der den Teilnehmer über das Ereignis benachrichtigen kann, Ereignisse subskribieren. Der Ereignismanager kann in den Sicherheitsmanager 108 eingebaut sein. Der Sicherheitsmanager 108 kann zusätzlich Ereignisse filtern oder bereits vorliegende Systemereignisse umdefinieren. Der Sicherheitsmanager 108 kann auch Zugang zu vorbestimmten Ereignissen des VCS 1 erhalten. Nicht einschränkende Beispiele für vorbestimmte Ereignisse wären unter anderem Power-Modus, Spracherkennung/Text-zu-Sprache, Medien-Telefonsteuerung, USB-Einfügung/-Entfernung, Tastatur, Telematik, WiFi-Netzwerk-Roaming, Audiozustand/-Anforderung, Taste, Klima, Radio, Cluster, GPS, Datum/Uhrzeit, Kraftstoffstand, Batterieladepegel eines Elektrofahrzeugs, Temperatur, Türstatus, Notfallinformationen, Unfallstatus, Parkhilfe, Sitze, Personalisierung und Datenmanager.
Der Sicherheitsmanager 108 kann zusätzlich Betriebsmittelverbrauch von Fahrzeugbetriebsmitteln regulieren. Wie später ausführlicher beschrieben werden wird, kann diese Regulierung so durchgesetzt werden, dass ein Anwendungsscript (das das Fahrzeugbetriebsmittel definieren kann, zu dem eine Anwendung 103a–f Zugang haben kann) beendet werden kann, wenn es gegen durch den Sicherheitsmanager 108 durchgesetzte Betriebsmittelverbrauchsregulierungen verstößt. Es versteht sich, dass der Sicherheitsmanager 108 gemäß einer beliebigen anderen Beschränkung regulieren kann, die der Sicherheitsmanager 108 eingerichtet hat.
Der Sicherheitsmanager 108 kann dafür programmiert werden, den Zugang zu Fahrzeugbetriebsmitteln durch nicht vertrauenswürdige Anwendungen (d. h. die Anwendungen 103a–f) zu begrenzen. Somit kann der Sicherheitsmanager 108 ein Schirm vor diesen nicht vertrauenswürdigen Anwendungen sein, die sich anderweitig auf die Leistungsfähigkeit des Fahrzeugs auswirken können. Bei einer Ausführungsform kann der Sicherheitsmanager 108 in einer Scripting-Sprache programmiert werden, darunter, aber ohne Beschränkung darauf, Java,. NET (Visual Basic, C#), ActionScript, JavaScript, LUA, Perl oder Python. Bei bestimmten Ausführungsformen kann ein Script auf die nicht vertrauenswürdigen Anwendungen programmiert werden (das auf der Scripting-Sprache des Sicherheitsmanagers 108 basieren kann oder auch nicht). Dieses Script (oder allgemeiner dieser Code) kann die Betriebsmittelbeschränkungen und andere Sicherheitsparameter der nicht vertrauenswürdigen Anwendungen definieren. Bei weiteren Ausführungsformen kann die nicht vertrauenswürdige Anwendung voll in der Scripting-Sprache programmiert werden, und das Sicherheits-Script kann ein Teil des Anwendungscodes sein.
Wie später ausführlicher beschrieben wird, kann der Sicherheitsmanager 108 mit dem Script assoziierte Sicherheitsrichtliniendateien umfassen. Diese Richtliniendateien können den Umfang des Zugangs der Anwendung zu den Fahrzeugbetriebsmitteln definieren. Diese Richtliniendateien können auch mit digitalen Zertifikaten assoziiert sein. Die digitalen Zertifikate können zusätzliche Richtliniendateigrenzen individuell definieren.
Bei zusätzlichen oder alternativen Ausführungsformen können sich Sicherheitsrichtlinien in der Anwendung 103a–f befinden. Zum Beispiel kann eine Anwendung 103a–f in separate Bibliotheken (oder Komponenten) aufgeteilt werden, und jede Bibliothek (oder Komponente) kann mit einer Richtlinie assoziiert werden. Es versteht sich, dass gleichzeitig verschiedene Richtlinien durchgesetzt werden können. Als ein nicht einschränkendes Beispiel können eine Vorgaberichtlinie, eine anwendungsspezifische Richtlinie und eine bibliotheksspezifische Richtlinie durch den Sicherheitsmanager 108 durchgesetzt werden.
Bei einer Ausführungsform kann der Sicherheitsmanager 108 flexibel und dynamisch sein, so dass der (in 2 dargestellte) Systemrahmen erweitert und aufgerüstet werden kann, um neue Basisfunktionalität hinzuzufügen. Durch dieses Merkmal können neue Bibliotheken geladen und dynamisch auf dem VCS 1 zur Laufzeit, statt Compilezeit, verfügbar gemacht werden. Bei einer Ausführungsform können diese Bibliotheken Dynamic Link Libraries (DLL) sein. Auf diese Weise können Aufrüstungen durchführbar sein, ohne sich nachteilig auf Einrichtungen mit existierender Unterstützung auszuwirken. Durch Installation oder Herunterladen der neuen Bibliotheken können deshalb neue Remote Procedure Calls registriert oder neue APIs dem Sicherheitsmanager 108 zur Verfügung gestellt werden. Das allgemeine Transportprotokoll kann bei dieser Erweiterbarkeit durch Transportieren von Inhalt und Befehlskontrollelementen von dem Transportmanager 106, statt den spezifischen APIs, helfen.
Der Sicherheitsmanager 108 kann zusätzliche nicht einschränkende Funktionen ausführen. Als ein Beispiel kann der Sicherheitsmanager 108 Daten (d. h. Ereignisse) von einem beliebigen oder mehreren der verschiedenen Kommunikationsprotokolle 104a–f empfangen und senden. Wie oben beschrieben, kann der Datenaustausch über das allgemeine Transportprotokoll erzielt werden. Dementsprechend kann der Sicherheitsmanager 108 auch ”transportagnostisch” sein.
Der Sicherheitsmanager 108 kann auch in der Lage sein, elegant auszufallen, wenn Fehler in dem Script auftreten. Falls zum Beispiel das VCS 1 verschiedene Generationen oder Versionen umfasst, sind möglicherweise bestimmte APIs (oder Fahrzeugkontrollelemente) in früheren Generationen oder Versionen nicht verfügbar. In einem solchen Szenario können die Anwendungen 103a–f den Sicherheitsmanager 108 nach der Existenz bestimmter APIs abfragen. Eine Fehlernachricht kann zu den Anwendungen 103a–f gesendet werden, wenn die API nicht existiert. Als Alternative oder zusätzlich kann ein Programmfehler durch den Sicherheitsmanager 108 getriggert werden. Dieser Programmfehler kann gefangen werden und die Anwendung 103a–f kann sich von dem Fehler erholen. Als Alternative kann das Script beendet werden, wenn der Programmfehler nicht gefangen wird.
Bei bestimmten Ausführungsformen kann die zu der Anwendung 103a–f gesendete Fehlernachricht Informationen zum Durchführen eines Anwendungs-Debugging umfassen. Als ein nicht einschränkendes Beispiel kann ein Call Stack Trace in der Fehlernachricht zum Identifizieren des Orts des Fehlers bereitgestellt werden. Bei bestimmen Ausführungsformen kann der Call Stack Trace ein teilweiser Call Stack Trace sein. Andere Beispiele für den Umgang mit Fehlern werden nachfolgend mit Bezug auf 5 beschrieben.
Nunmehr mit Bezug auf 3 wird ein Prozess zum Implementieren einer Sicherheitsrichtlinie gegenüber einem Script dargestellt und beschrieben. Es versteht sich, dass die Offenbarung und Anordnung von 3 modifiziert oder umgeordnet werden kann, um am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung zu passen.
Wie im Block 200 dargestellt, können ein Befehl oder Anweisungen zum Ausführen einer Anwendung 103a–f von der Einrichtung 102a–fgesendet werden. Der Befehl oder die Anweisungen können durch den Benutzer (über eine GUI und/oder Sprachbenutzeroberfläche oder ”SUI” des VCS 1) gesendet werden und umfassen, aber ohne Beschränkung darauf, Aktivierung von Anwendungen 103a–f, Eingeben von Eingaben, Empfangen von Ausgaben und Beenden der Anwendung 103a–f. Die Anwendungen 103a–f können die Benutzeranweisungen empfangen und den Befehl oder die Anweisungen als einen Dienst oder eine Operations-anweisung senden (Block 202). Der Dienst oder die Operations-anweisungen können über eine oder mehrere oben beschriebene Dienstarten gesendet werden. Zur Veranschaulichung und Beschreibung wird 3 in dem Kontext beschrieben, dass der Dienst oder die Operationsanweisung über einen Remote Procedure Call (RPC) gesendet wird.
Der RPC kann auf in dem Sicherheitsmanager 108 registrierte Callbacks abgebildet werden. Diese Callbacks können in einer Tabelle in dem Sicherheitsmanager 108 registriert und gemäß der RPC-Anweisung (oder -Funktion) von der Anwendung 103a–f abgebildet werden. Auf der Basis eines Nachschlagens der Callback-Tabelle kann das Callback die Funktionalität auf Script-Basis zum Durchführen der Anweisung im Namen der Anwendung 103a–f bereitstellen. Dementsprechend kann das Script Ereignisse senden und empfangen. Wenn die Anweisung nicht existiert hat, kann ein Fehler zu der Anwendung 103a–f gesendet werden.
Callbacks können auf der Art der mit einem von den Anwendungen 103a–f durch den Sicherheitsmanager 108 empfangenen Script assoziierten Richtlinie basieren. Die Sicherheitsrichtlinien können eine Vorgabe-Sicherheitsrichtlinie (d. h. eine allgemeine Richtlinie) oder eine anwendungsspezifische Richtlinie sein. Die Sicherheitsrichtlinien können auch ”signierte” Sicherheitsrichtlinien sein. Weitere Einzelheiten dieser Richtlinien werden später beschrieben. Es versteht sich, dass sich ”Sicherheitsrichtlinie” auf Fahrzeugbetriebsmittel-Benutzungsrichtlinien bezieht und, aber ohne Beschränkung darauf, Folgendes umfasst: Richtlinien in Bezug auf Schadcode, Denial-off-Service-Attacken, Speicherverbrauch, Pufferüberlauf, Flash-Benutzung, API-Beschränkung, Prozessorbenutzung, Verwendung von Watchdog-Timern und andere ähnliche Sicherheitsverstöße.
Wie im Block 204 dargestellt, kann das Script von der Anwendung 103a–f durch den Sicherheitsmanager 108 empfangen werden. Wie im Block 206 dargestellt, können diese Scripts validiert werden, indem bestimmt wird, ob eine Sicherheitsrichtlinie 105a–f mit dem Script assoziiert ist. Diese Richtlinien sind in 2 als Sicherheitsrichtlinien (”SP”) 105a–f dargestellt.
Bei bestimmten Ausführungsformen kann, wenn das Script durch den Sicherheitsmanager 108 empfangen wird, das Script vorübergehend zum Zwecke des Validierens des Scripts in den VCS-Speicher kopiert werden. Wenn das Script ausgeführt wird (Block 218), kann das Script aus dem VCS 1 gelöscht werden. Scripts können also ohne Installation in das VCS 1 ausgeführt werden.
Der Sicherheitsmanager 108 kann das Script validieren, indem bestimmt wird, ob eine Richtliniendatei mit dem Script assoziiert ist (Block 206). Wenn es keine Richtliniendatei gibt, kann eine Vorgabe-Sicherheitsrichtlinie benutzt werden (Block 208). Andernfalls kann eine anwendungsspezifische Richtlinie benutzt werden. Bei bestimmten Ausführungsformen kann diese Bestimmung (Block 206) damit zusammenhängen, welche Richtliniendatei zu verwenden ist. Das heißt, es kann für alle durch den Sicherheitsmanager 108 empfangenen Scripts eine Richtliniendatei existieren, aber es kann eine Bestimmung durchgeführt werden, welche Richtliniendatei zuzuweisen ist. Dies kann auf der Empfindlichkeit der VCS-Funktionalität, die die Anwendung anfordert, basieren. Zum Beispiel und ohne Beschränkung, kann, wenn die Anwendung die Verwendung von Fahrzeugbetriebsmitteln anfordert, die hohe Empfindlichkeit aufweisen, wie etwa diagnostische Betriebsmittel, erfordert werden, dass eine anwendungsspezifische Richtlinie mit der Anwendung assoziiert ist. Es versteht sich, dass diese Bestimmung (d. h. die Empfindlichkeit eines Fahrzeugbetriebsmittels) in den oben beschriebenen Ausführungsformen und allen anderen Ausführungsformen, in denen eine Richtliniendatei mit einem Script assoziiert ist, erfolgen kann.
Die Sicherheitsrichtliniendatei kann definieren, welche(s) Fahrzeugbetriebsmittel das Script verwenden kann. Das Script kann mit einer Zugangsebene assoziiert werden. Zum Beispiel kann eine allgemeine (oder Vorgabe-)Sicherheitsrichtlinie die Betriebsmittel definieren, die alle Anwendungen 103a–f verwenden dürfen. Eine anwendungsspezifische Sicherheitsrichtlinie kann die spezifischen Betriebsmittel definieren, die eine spezifische Anwendung verwenden darf. Bei bestimmten Ausführungsformen kann die Zugangsebene auf einem Spezifizitätswert basieren. Bei weiteren Ausführungsformen kann der Spezifizitätswert auf einer Hierarchie basieren. Diese Werte können numerisch, alphabetisch, alphanumerisch und dergleichen sein. Mit zunehmendem Spezifizitätswert kann zum Beispiel der Zugang zu einem Fahrzeugbetriebsmittel strikter sein. Es versteht sich, dass dieses Beispiel lediglich zur Veranschaulichung dient und andere Systeme implementiert werden können, ohne von dem Umfang und Gedanken der verschiedenen Ausführungsformen abzuweichen.
Die spezifischen Betriebsmittel können zusätzlich zu den Betriebsmitteln sein, zu denen unter der Vorgaberichtlinie alle Anwendungen 103a–f Zugang haben. Die anwendungsspezifische Richtliniendatei kann auch eine Anzahl von Attributen umfassen, die Übersteuerung von Vorgabeverhalten gestatten. Nicht erschöpfende und nicht einschränkende Beispiele für diese Attribute wären die Möglichkeit, im Hintergrund zu laufen, wenn andere Scripts den Fokus besitzen können, die Möglichkeit, normale Betriebsmittelbeschränkungen zu übersteuern, die Möglichkeit, Fahrerablenkbeschränkungen zu übersteuern und die Möglichkeit, Verbrauchervalidierung des Zugangs zu Betriebsmitteln wie GPS und Fahrzeugdaten zu übersteuern.
4 zeigt den Prozess zum Bestimmen der Art von mit einem Script assoziierten Richtliniendatei. Es versteht sich, dass die Offenbarung und Anordnung von 4 modifiziert oder umgeordnet werden kann, um am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung zu passen.
Das Script kann beim Empfang durch den Sicherheitsmanager 108 (Block 300) untersucht werden und es kann bestimmt werden, ob ein signiertes digitales Zertifikat mit dem Script assoziiert ist (Block 302). Wenn dem so ist, kann der Sicherheitsmanager 108 das in einem Zertifikatspeicher gespeicherte digitale Sicherheitszertifikat nachschlagen (Block 304). Andernfalls kann eine weitere Bestimmung erfolgen, ob das Script die Verwendung eines spezifischen Betriebsmittels erfordert, das nicht allgemein allen Anwendungen verfügbar ist (Block 306). Bei bestimmten Ausführungsformen kann die Bestimmung im Block 302 erfolgen, um zu bestimmen, ob das Zertifikat unmodifiziert ist. Wenn das Zertifikat modifiziert wurde, kann es dementsprechend notwendig sein, ein neues digitales Zertifikat zu empfangen. Bei weiteren Ausführungsformen kann die Bestimmung im Block 302 auf der Validität des digitalen Zertifikats basieren. Somit kann ein ungültiges digitales Zertifikat erfordern, dass ein neues digitales Zertifikat empfangen wird.
Wenn keine spezifischen Betriebsmittel erforderlich sind, kann das Script mit einer Vorgaberichtlinie assoziiert werden (Block 310). Dementsprechend können die allen Anwendungen verfügbaren Fahrzeugbetriebsmittel dieser Anwendung zur Verfügung gestellt werden (Block 308). Bei bestimmten Ausführungsformen benötigen Anwendungen möglicherweise kein signiertes digitales Zertifikat, um diese Betriebsmittel zu verwenden. Bei anderen Ausführungsformen umfassen alle Richtlinien ein digitales Zertifikat.
Wenn kein Zertifikat existiert, kann ein digitales Zertifikat gemäß in der Technik bekannten Verfahren empfangen (Block 312) werden, das für die Anwendung 103a–f signiert ist. Das signierte digitale Zertifikat kann auf ein durch einen OEM (d. h. den Fahrzeughersteller) ausgegebenes Gegenstück-Zertifikat abgebildet (Block 314) und in dem VCS 1 gespeichert (Block 316) werden.
Wieder mit Bezug auf 3 kann, wenn eine anwendungsspezifische Richtlinie verwendet wird, das signierte digitale Zertifikat durch den Sicherheitsmanager erhalten werden (Block 210). Es kann bestimmt werden, ob das digitale Zertifikat gültig ist (Block 212). Wenn nicht, kann das Script abbrechen und eine Fehlernachricht zu der Anwendung 103a–f gesendet werden (Block 214). Weitere Einzelheiten des Fehlerdetektionsprozesses und der Nachrichtenübertragung werden nachfolgend mit Bezug auf 5 beschrieben. Bei bestimmten Ausführungsformen kann ein ungültiges digitales Zertifikat die in 4 dargestellte und oben beschriebene Operation triggern.
Wenn das digitale Zertifikat gültig ist, kann weiter bestimmt werden, ob es modifiziert wurde (Block 216). Wenn das Zertifikat modifiziert wurde, kann das Script beendet und eine Fehlernachricht zu der Anwendung 103a–f gesendet werden (Block 214). Bei bestimmten Ausführungsformen kann ein modifiziertes digitales Zertifikat die in 4 dargestellte und oben beschriebene Operation triggern. Wenn das Zertifikat nicht modifiziert ist, kann dem Script erlaubt werden, zu laufen, wie im Block 218 dargestellt.
Bei bestimmten Ausführungsformen kann der Sicherheitsmanager 108 außerdem das Script authentifizieren und sicherstellen, dass es nicht modifiziert wurde. Zu diesem Zweck kann ein sicheres Hash mit jedem Script assoziiert werden. Das sichere Hash kann in der Richtliniendatei enthalten sein.
5 zeigt einen Prozess zum Verwalten einer Sicherheitsrichtlinie, wenn ein Script ausgeführt wird. Die Verwaltung kann, aber ohne Beschränkung darauf, das Durchsetzen von Betriebsmittelbeschränkungen/Begrenzungen und das Verwalten von Script-Fehlern umfassen. Es versteht sich, dass die Offenbarung und Anordnung von 5 modifiziert oder umgeordnet werden kann, um am besten auf eine bestimmte Implementierung der verschiedenen Ausführungsformen der Erfindung zu passen.
Information hinsichtlich der Richtlinienart (d. h. Vorgabe oder anwendungsspezifisch) können (wie in 3 und 4 beschrieben) durch den Sicherheitsmanager 108 erhalten werden (Block 406). Auf der Basis der in der Richtlinienart definierten Betriebsmittel werden die Fahrzeugbetriebsmittel überwacht, zu denen die Anwendung 103a–f Zugang haben kann (Block 408).
Bei einer Ausführungsform kann, wie in den Blöcken 400–404 dargestellt, das VCS 1 bestimmen, welche Prozesse auf dem VCS 1 ablaufen (Block 400). Diese Bestimmung kann für das Bestimmen, welche Prozesse Fokus-Priorität besitzen (d. h. dem Benutzer angezeigt werden), das Bestimmen von Betriebsmittelvergabestrategie, Fehlerdetektion und andere ähnliche Bestimmungen erfolgen. Zur Veranschaulichung zeigt 5 eine Prioritätsbestimmung.
Zum Beispiel können native Prozesse Priorität gegenüber Prozessen des Sicherheitsmanagers 108 mit Bezug auf Fokus und Betriebsmittelvergabe besitzen. Dementsprechend kann der Sicherheitsmanager 108 möglicherweise trotz der Tatsache, dass ein Script läuft, den Schirmfokus nicht von einem nativen Prozess wegnehmen. Als weiteres nicht einschränkendes Beispiel kann der Sicherheitsmanager 108 möglicherweise eine Anzeige (oder HMI) nicht monopolisieren, wenn ein nativer Prozess die Verwendung der Anzeige erfordert. Wie hier beschrieben, beziehen sich native Prozesse auf für das VCS 1 native Prozesse (d. h. Prozesse, die sich nicht aus dem Ausführen eines oder mehrerer Scripts ergeben).
Dementsprechend kann bestimmt werden, ob ein nativer Prozess läuft oder die Verwendung eines Fahrzeugbetriebsmittels anfordert (Block 402). Wenn dem so ist, kann der native Prozess ausgeführt werden (Block 404).
Bei einer Ausführungsform kann es Scripts gestattet werden, im Hintergrund zu laufen, wenn ein nativer Prozess läuft und/oder wenn ein anderes Script läuft. Zusätzlich oder als Alternative können mehrere Scripts gleichzeitig ausgeführt werden. Jedes Script kann unterschiedlichen Zugang zu den Fahrzeugbetriebsmitteln besitzen oder auch nicht. Ferner kann jedem Script der Fokus gegeben werden und es kann in der Lage sein, zu bestimmen, wann es im Fokus ist. Dies kann bestimmt werden, wenn eine Anwendung auf der Anzeige 4 gezeigt wird.
Nunmehr mit Bezug auf Block 410 kann der Status der Benutzung eines Fahrzeugbetriebsmittels durch das Script bestimmt werden. Als nicht einschränkendes Beispiel kann die Verwendung des VCS-Speichers bestimmt werden. Wie oben beschrieben, kann der Sicherheitsmanager 108 sicherstellen, dass das Script nicht durch exzessiven Speicherverbrauch den VCS-Speicher erschöpft. Die Richtlinie für ein Script kann eine Grenze oder ein Quotum des Speicherverbrauchs für das Script definieren. Wenn das Script dieses Quotum überschreitet, kann das Script beendet werden. Bei einer Ausführungsform kann eine Warnbenachrichtigung bei einer vorbestimmten Schwelle zu der Anwendung 103a–f gesendet werden, dass ein Überschreiten des Speicherquotums bevorsteht.
Bei bestimmen Ausführungsformen können, obwohl ein Script möglicherweise seine vergebene Grenze eines Betriebsmittels nicht voll benutzt, andere Faktoren solche Betriebsmittel erschöpfen. Die Betriebsmittelbenutzung kann somit auf der Basis von Timern, Thread-Priorität und dergleichen begrenzt werden. Obwohl 5 die Bestimmung im Kontext von Timern darstellt, versteht sich, dass dieses Beispiel nicht einschränkend ist und zur Veranschaulichung angegeben wird.
Wenn die Betriebsmittelbenutzung eine bestimmte definierte Grenze nicht überschreitet, kann ferner bestimmt werden, ob der Timer abgelaufen ist (Block 426). Diese Bestimmung kann sicherstellen, dass das Script nicht in eine unendliche Schleife eintritt und dadurch VCS-Betriebsmittel (wie etwa Speicher oder CPU) erschöpft. Es versteht sich, dass dieses Merkmal des Sicherheitsmanagers 108 in bestimmten Fällen (z. B. während eines Text-zu-Sprache-Ereignisses) suspendiert werden kann.
Bei bestimmten Ausführungsformen kann der Sicherheitsmanager 108 ferner bestimmen, ob das Script einen Syntax- oder Programmierfehler aufweist (Block 428). Solche Fehler können Programmfehler und/oder Fehler erzeugen, die eine Beendigung des Scripts verursachen können oder auch nicht.
Es versteht sich, dass der Dienst oder Betrieb der Anwendung 103a–f durchgeführt werden kann (Block 424), nachdem beliebige, alle oder bestimmte der oben beschriebenen Bestimmungen erfolgt sind.
Der Fehlerdetektions- und Übertragungsprozess wird nun ausführlicher beschrieben. Wie oben beschrieben, kann, wenn ein Ausfall aufgetreten ist, durch den Sicherheitsmanager 108 ein Programmfehler erzeugt werden (Block 412) und zu der Anwendung 103a–f gesendet werden (Block 414). Wenn der Programmfehler fatal ist (z. B. wenn die Speicherbenutzung die vorbestimmte Grenze überstiegen hat) (Block 416), kann das Script beendet (Block 418) und die Anwendung 103a–f über die Beendigung benachrichtigt werden (Block 420). Die Benachrichtigung kann über das allgemeine Transportprotokoll gesendet werden.
Wenn der Programmfehler nicht fatal ist (Block 416) (z. B. ein Programmier- oder Syntaxfehler in dem Script vorliegt), kann bestimmt werden, ob der Programmfehler gefangen wird (Block 422). Wenn der Programmfehler nicht gefangen wird, kann das Script beendet (Block 418) und die Anwendung 103a–f benachrichtigt werden (Block 420).
Wenn der Programmfehler gefangen wird, kann der Dienst oder die Operation von der Anwendung 103a–f durchgeführt werden (Block 424), wenn nicht ein anderer Programmfehler entsteht. In diesem Fall kann derselbe Prozess wie in den Blöcken 412–422 dargestellt befolgt werden.
Obwohl oben beispielhafte Ausführungsformen dargestellt und beschrieben wurden, ist nicht beabsichtigt, dass diese Ausführungsformen alle Möglichkeiten darstellen und beschreiben. Stattdessen sind die in der Beschreibung verwendeten Wörter nicht Wörter der Beschränkung, sondern der Beschreibung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen.
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

US 7207041 [0002]
US 2007/0050854 [0003]
US 2008/0148374 [0004]

Zitierte Nicht-Patentliteratur

802.11g-Netzwerk [0034]
802.11-Protokolle [0044]
802.11-Protokolle [0051]

Claims

Fahrzeugbetriebsmittel-Benutzungskontrollsystem, umfassend: einen Fahrzeugcomputer, der eine oder mehrere Sicherheitsrichtlinien umfasst, die Benutzungsregeln für ein oder mehrere Fahrzeugbetriebsmittel definieren, wobei der Fahrzeugcomputer für Folgendes ausgelegt ist: Kommunizieren mit einer oder mehreren Einrichtungen, die im Speicher eine oder mehrere installierte Softwareanwendungen aufweisen, die zum Betrieb ein oder mehrere Fahrzeugbetriebsmittel verwenden; Empfangen von programmierten Anweisungen, die definieren, welches der einen oder der mehreren Fahrzeugbetriebsmittel die Softwareanwendung zum Betrieb verwendet, wobei die programmierten Anweisungen mit einen oder den mehreren Sicherheitsrichtlinien assoziiert sind; Bestimmen der mit der einen oder den mehreren Softwareanwendungen assoziierten Sicherheitsrichtlinie auf Basis der programmierten Anweisungen; und Gestatten des Betriebs der einen oder mehreren Softwareanwendungen gemäß der Sicherheitsrichtlinie.
System nach Anspruch 1, wobei die eine oder mehreren Sicherheitsrichtlinien für die Softwareanwendung spezifisch sind.
System nach Anspruch 1, wobei die eine oder mehreren Sicherheitsrichtlinien voreingestellte Sicherheitsrichtlinien oder für die Softwareanwendung spezifische Sicherheitsrichtlinien sind.
System nach Anspruch 1, wobei der Fahrzeugcomputer einen Betriebsmittelbenutzungstimer umfasst und die Sicherheitsrichtlinie eine Zeitgrenze für das Ausführen der programmierten Anweisungen definiert.
System nach Anspruch 4, wobei der Fahrzeugcomputer ferner dafür ausgelegt ist, eine Fehlernachricht zu senden, wenn die Ausführung der programmierten Anweisungen die Zeitgrenze überschreitet.
System nach Anspruch 5, wobei der Fahrzeugcomputer ferner dafür ausgelegt ist, die Ausführung der programmierten Anweisungen zu beenden.
System nach Anspruch 1, wobei das Fahrzeugbetriebsmittel eine zum Kommunizieren mit einem oder mehreren Fahrzeugmodulen implementierte Anwendungsprogrammierschnittstelle ist.
System nach Anspruch 1, wobei der Fahrzeugcomputer ein virtueller Computer ist, der in einem computerlesbaren Medium verkörpert wird.
System nach Anspruch 8, wobei der virtuelle Computer transportunabhängig ist.
System nach Anspruch 1, wobei die programmierten Anweisungen aus der einen oder den mehreren Einrichtungen empfangen werden.