DE102019106795A1

DE102019106795A1 - Konfliktbestimmung und -eindämmung für Fahrzeuganwendungen

Info

Publication number: DE102019106795A1
Application number: DE102019106795.2A
Authority: DE
Inventors: Nobuyuki Tomatsu
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2018-03-19
Filing date: 2019-03-18
Publication date: 2019-09-19
Also published as: JP2019164791A; US10705817B2; JP6809551B2; US20190286457A1

Abstract

Die Offenbarung umfasst Ausführungsbeispiele zum Bereitstellen einer Konfliktbestimmung und Konflikteindämmung bezüglich Fahrzeuganwendungen. Ein Verfahren gemäß einigen Ausführungsbeispielen umfasst ein Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs. Das Verfahren umfasst Abrufen einer ersten Konflikttabelle von der Fahrzeuganwendung. Das Verfahren umfasst ein Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere in dem fahrzeuginternen Fahrzeugcomputer installierte Fahrzeuganwendungen umfasst. Das Verfahren umfasst ein Analysieren des Tabellensatzes, um zu identifizieren, ob ein Aktivieren der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen erzeugen wird. Das Verfahren umfasst ein Bestimmen bezüglich des Aktivierens der Fahrzeuganwendung basierend darauf, dass der Konflikt nicht identifiziert wird.

Description

Hintergrund
Die Spezifikation bezieht sich auf ein Bereitstellen einer Konfliktbestimmung und Konflikteindämmung für Fahrzeuganwendungen.
Fahrzeugsteuerungssysteme werden zunehmend populär. Ein Beispiel eines Fahrzeugsteuerungssystems ist ein fortschrittliches bzw. erweitertes Fahrerassistenzsystem (engl. „advanced driver assistance system“) („ADAS-System“ im Singular, „ADAS-Systeme“ im Plural).
ADAS-Systeme stellen Fahrzeugen ein oder mehrere autonome Merkmale bereit, die diese ADAS-Systeme umfassen. Zum Beispiel kann ein ADAS-System die Position eines Fahrzeugs bezüglich der Fahrspur, in der das Fahrzeug fährt, überwachen, und wenn das Fahrzeug beginnt, nach außerhalb dieser Spur abzuweichen, kann das ADAS-System eine abhelfende Aktion durch Neupositionieren des Fahrzeugs, sodass das Fahrzeug in der Spur verbleibt, oder Bereitstellen einer Benachrichtigung an einen Fahrer des Fahrzeugs, sodass der Fahrer darüber Kenntnis erlangt, dass eine Aktion zum Beheben der Situation erforderlich ist, durchführen.
Einige Fahrzeuge umfassen eine ausreichende Anzahl und Qualität von autonomen Merkmalen, dass diese als autonome Fahrzeuge betrachtet werden.
Zusammenfassung
Automobilhersteller bevorzugen eine „Plug-and-Play“ bzw. sofort betriebsbereite Systemlandschaft am Fahrzeug. Zum Beispiel möchte ein Fahrzeughersteller, dass dessen Fahrzeuge eine Infrastruktur aufweisen, die Softwareentwicklern ermöglicht, Softwareanwendungen für deren Fahrzeuge zu schreiben (d.h. „Fahrzeuganwendungen“), und dass diese Fahrzeuganwendungen bei unterschiedlichen Marken und Modellen deren Fahrzeuge gleich oder im Wesentlichen gleich arbeiten. Dies ist unter Verwendung von vorhandenen Lösungen gegenwärtig nicht möglich. Zum Beispiel wird eine Software für ein ADAS-System (nachstehend „ADAS-Software“, die ein Beispiel einer Fahrzeuganwendung ist) für „Fahrzeug X“ relativ zu „Fahrzeug Y“ unterschiedlich arbeiten, wenn Fahrzeug X und Fahrzeug Y eine unterschiedliche Marke und Modell aufweisen, auch wenn Fahrzeug X und Fahrzeug Y vom gleichen Hersteller sind. Eine „Plug-and-Play“-Systemlandschaft am Fahrzeug löst dieses Problem beispielsweise durch Ermöglichen der ADAS-Software, auf ähnliche Weise zu arbeiten, ungeachtet der Marke und des Modells des Fahrzeugs, in dem die ADAS-Software installiert ist.
Ein Hindernis bei einer Bereitstellung einer Plug-and-Play-Systemlandschaft am Fahrzeug ist, dass Fahrzeuge viele unterschiedliche Typen von Fahrzeuganwendungen umfassen. Zum Beispiel kann ein einzelnes Fahrzeug zahlreiche ADAS-Systeme umfassen. Es entstehen Konflikte, wenn mehrere Fahrzeuganwendungen versuchen, gleichzeitig das gleiche Fahrzeugstellglied oder dieselben Fahrzeugressourcen zu verwenden. Solche Konflikte können ein Auftreten von fatalen Unfällen verursachen. Gegenwärtig werden solche Konflikte vermieden, weil die Fahrzeuganwendungen, die in Fahrzeugen installiert sind, straff durch den Fahrzeughersteller verwaltet werden, und die Fahrzeuganwendungsentwickler müssen selbst miteinander bezüglich den Fahrzeuganwendungen kommunizieren, die diese jeweils entwickeln, und diese Kommunikationen erzeugen eine Situation, in der die in den Fahrzeugen der Fahrzeughersteller installierten Fahrzeuganwendungen derart geschrieben werden, dass Konflikte vermieden werden. Jedoch ist es in der Zukunft gewünscht, sich zu einer Plug-and-Play-Systemlandschaft zu entwickeln, in der diese Art von Entwickler-zu-Entwickler-Kommunikation nicht auftreten muss.
In einer Plug-and-Play-Softwaresystemlandschaft muss eine Fahrzeuganwendungsentwicklung nicht straff durch den Fahrzeughersteller verwaltet werden, und die Fahrzeuganwendungsentwickler müssen nicht miteinander kommunizieren. Dies erzeugt ein Problem, weil basierend auf gegenwärtig verfügbaren Lösungen keine Weise eines Steuerns von Konflikten unter Fahrzeuganwendungen verfügbar ist, die in den Fahrzeugen installiert sind. Das hier beschriebene Konfliktsystem löst dieses Problem als ein Bestandteil einer Plug-and-Play-Systemlandschaft eines Fahrzeugs, in dem Fahrzeuganwendungen ohne Vorbereitung und ohne direkten Überblick durch Fahrzeuganwendungsentwickler oder den Fahrzeughersteller installiert werden können.
Der Konflikt ist ein Element eines fahrzeuginternen Fahrzeugcomputersystems eines Fahrzeugs. In einigen Ausführungsbeispielen ist das Fahrzeug ein autonomes Fahrzeug. Die „National Highway Traffic Safety Administration („NHTSA“)“ hat unterschiedliche Niveaus bzw. „Level“ von autonomen Fahrzeugen definiert, z. B. Level 0, Level 1, Level 2, Level 3, Level 4 und Level 5. Wenn ein Fahrzeug eine höhere Level-Nummer aufweist als ein anderes Fahrzeug (z. B. Level 3 ist eine höhere Level-Nummer als Level 2 oder 1), dann bietet das Fahrzeug mit einer höheren Level-Nummer eine größere Kombination und Menge von autonomen Merkmalen bezüglich des Fahrzeugs mit der niedrigeren Level-Nummer. Diese unterschiedlichen Level von autonomen Fahrzeugen werden nachstehend kurz beschrieben.
Level 0: Der Satz von ADAS-Systemen, der in dem Fahrzeug installiert ist, weist keine Fahrzeugsteuerung auf, kann jedoch Warnungen an den Fahrer des Fahrzeugs ausgeben.
Level 1: Der Fahrer muss bereit sein, jederzeit die Steuerung des Fahrzeugs zu übernehmen. Der Satz von ADAS-Systemen, der in dem Fahrzeug installiert ist, kann autonome Merkmale aufweisen, wie etwa eines oder mehrere der Folgenden: Abstandsregeltempomat („ACC“); und Parkassistenz mit automatisiertem Lenken und Spurhalteassistenz („LKA“) Typ II, in beliebiger Kombination.
Level 2: Der Fahrer ist gezwungen, Objekte und Ereignisse in der Straßenumgebung zu erfassen, und darauf zu reagieren, wenn der Satz von ADAS-Systemen, der in dem Fahrzeug installiert ist, damit fehlschlägt, angemessen zu reagieren (basierend auf der subjektiven Beurteilung des Fahrers). Der in dem Fahrzeug installierte Satz von ADAS-Systemen führt ein Beschleunigen, Bremsen und Lenken aus. Der in dem Fahrzeug installierte Satz von ADAS-Systemen kann unmittelbar nach Übernahme durch den Fahrer deaktiviert werden.
Level 3: Innerhalb bekannten, begrenzten Umgebungen (wie etwa Autobahnen) kann der Fahrer sicher seine Aufmerksamkeit von Fahraufgaben weglenken, muss jedoch nach wie vor bereit sein, die Steuerung des Fahrzeugs zu übernehmen, wenn dies erforderlich ist.
Level 4: Der in dem Fahrzeug installierte Satz von ADAS-Systemen kann das Fahrzeug in allen außer einigen Umgebungen, wie etwa bei extremem Wetter, steuern. Der Fahrer darf das automatisierte System (das aus dem in dem Fahrzeug installierten Satz von ADAS-Systemen besteht) nur aktivieren, wenn es sicher ist, dies zu tun. Wenn das automatisierte System aktiviert ist, ist die Aufmerksamkeit des Fahrers nicht erforderlich, um das Fahrzeug sicher und im Einklang mit akzeptierten Normen zu betreiben.
Level 5: Außer ein Einstellen des Ziels und Starten des Systems ist keine menschliche Intervention erforderlich. Das automatisierte System kann zu jedem Ort fahren, wohin es legal ist, zu fahren, und trifft seine eigenen Entscheidungen (was basierend auf der Rechtsprechung, wo sich das Fahrzeug befindet, variieren kann).
in einigen Ausführungsbeispielen ist das Fahrzeug ein hochgradig autonomes Fahrzeug („HAV“ im Singular, oder „HAVs“ im Plural). Ein HAV ist ein Fahrzeug (z. B. das Eigenfahrzeug mit aktiviertem DSRC), das einen Satz von ADAS-Systemen umfasst, die bei Level 3 oder höher, wie vorstehend beschrieben, arbeiten, oder durch die NHTSA auf Seite 9 deren Strategiepapier mit dem Titel „Federal Automated Vehicles Policy: Accelerating the Next Revolution in Roadway Safety“ definiert ist, das im September 2016 veröffentlicht wurde.
Ein System von einem oder mehreren Computern kann konfiguriert sein, um bestimmte Operationen oder Aktionen mittels Software, Firmware, Hardware, oder einer Kombination von diesen durchzuführen, die in dem System installiert sind, die im Betrieb das System bewirken, die Aktionen durchzuführen. Ein oder mehrere Computerprogramme können konfiguriert sein, um bestimmte Operationen oder Aktionen mittels Umfassen von Anweisungen durchzuführen, die, wenn diese durch eine Datenverarbeitungsvorrichtung ausgeführt werden, die Vorrichtung bewirken, die Aktionen durchzuführen.
Ein allgemeiner Aspekt umfasst ein System umfassend einen nicht-transitorischen Speicher, der eine Fahrzeuganwendung speichert, die digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch einen fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten bzw. einer ersten Auswahl an Zeitpunkten, wenn der das Fahrzeug betreffende Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten bzw. einer zweiten Auswahl an Zeitpunkten, wenn der das Fahrzeug betreffende Kontext nicht zutrifft. Andere Ausführungsbeispiele dieses Aspekts umfassen entsprechende Computersysteme, Vorrichtungen und Computerprogramme, die auf einer oder mehreren Computerspeichereinrichtungen aufgezeichnet sind, die jeweils konfiguriert sind, die Aktionen der Verfahren durchzuführen.
Ein allgemeiner Aspekt umfasst ein Verfahren, mit: Empfangen einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs, und Verweigern der Anforderung als Antwort auf eine Bestimmung, dass die Fahrzeuganwendung nichtdigitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer des Fahrzeugs verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft. Andere Ausführungsbeispiele dieses Aspekts umfassen entsprechende Computersysteme, Vorrichtungen und Computerprogramme, die auf einer oder mehreren Computerspeichereinrichtungen aufgezeichnet sind, die jeweils konfiguriert sind, um die Aktionen der Verfahren durchzuführen.
Ein allgemeiner Aspekt umfasst ein Verfahren, mit: Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs, Abrufen einer ersten Konflikttabelle von der Fahrzeuganwendung, Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere Fahrzeuganwendungen umfasst, die in dem fahrzeuginternen Fahrzeugcomputer installiert sind, Analysieren des Tabellensatzes, um zu identifizieren, ob ein Aktivieren der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen erzeugen wird, und Bestimmen, die Fahrzeuganwendung zu aktivieren, basierend darauf, dass der Konflikt nicht identifiziert wird. Andere Ausführungsbeispiele dieses Aspekts umfassen entsprechende Computersysteme, Vorrichtungen und Computerprogramme, die auf einer oder mehreren Computerspeichereinrichtung aufgezeichnet sind, die jeweils konfiguriert sind, um die Aktionen der Verfahren durchzuführen.
Implementierungen können eines oder mehrere der folgenden Merkmale umfassen. Das Verfahren, in dem die erste Konflikttabelle digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft. Das Verfahren, in dem das Fahrzeug ein autonomes Fahrzeug ist. Das Verfahren, in dem das Fahrzeug ein hochautonomes Fahrzeug ist. Das Verfahren, in dem die Fahrzeuganwendung ein erweitertes Fahrerassistenzsystem ist. Das Verfahren, in dem der fahrzeuginterne Fahrzeugcomputer eine elektronische Steuerungseinheit ist. Implementierungen der gewünschten Technologien können Hardware, ein Verfahren oder einen Prozess, oder Computersoftware auf einem computerzugreifbaren Medium umfassen.
Ein allgemeiner Aspekt umfasst ein Computerprogrammprodukt mit einem nicht-transitorischen Speicher eines Fahrzeugs, der einen Computercode speichert, der betreibbar ist, wenn dieser durch einen fahrzeuginternen Fahrzeugcomputer des Fahrzeugs ausgeführt wird, um den fahrzeuginternen Fahrzeugcomputer zu bewirken, Schritte auszuführen, die umfassen: Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einen fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs; Abrufen einer ersten Konflikttabelle von der Fahrzeuganwendung; Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere Fahrzeuganwendungen umfasst, die in dem fahrzeuginternen Fahrzeugcomputer installiert sind; Analysieren des Tabellensatzes, um zu identifizieren, ob eine Aktivierung der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen erzeugen wird; und Bestimmen, die Fahrzeuganwendung zu aktivieren, basierend darauf, dass der Konflikt nicht identifiziert wird. Andere Ausführungsbeispiele dieses Aspekts umfassen entsprechende Computersysteme, Vorrichtungen und Computerprogramme, die auf einer oder mehreren Computerspeichereinrichtungen aufgezeichnet sind, die jeweils konfiguriert sind, um die Aktionen der Verfahren durchzuführen.
Implementierungen können eines oder mehrere der folgenden Merkmale umfassen. Das Computerprogrammprodukt, in dem die erste Konflikttabelle digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wo der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Seiten, wenn der fahrzeugbezogene Kontext nicht zutrifft. Das Computerprogrammprodukt, wobei das Fahrzeug ein autonomes Fahrzeug ist. Das Computerprogrammprodukt, wobei das Fahrzeug ein hochautonomes Fahrzeug ist. Das Computerprogrammprodukt, wobei die Fahrzeuganwendung ein fortgeschrittenes Fahrerassistenzsystem ist. Das Computerprogrammprodukt, wobei der fahrzeuginterne Fahrzeugcomputer eine elektronische Steuerungseinheit ist. Implementierungen der beschriebenen Technologien können Hardware, ein Verfahren oder einen Prozess, oder Computersoftware auf einem computerzugreifbaren Medium umfassen.
Ein allgemeiner Aspekt umfasst ein System eines Fahrzeugs mit einem Prozessor, der kommunikationsfähig mit einem nicht-transitorischen Speicher gekoppelt ist, der einen computerausführbaren Code speichert, der, wenn dieser durch den Prozessor ausgeführt wird, betreibbar ist, um den Prozessor zu bewirken, Schritte auszuführen, die umfassen: Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs; Abrufen einer ersten Konflikttabelle von der Fahrzeuganwendung; Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere Fahrzeuganwendungen, die in dem fahrzeuginternen Fahrzeugcomputer installiert sind, umfasst; Analysieren des Tabellensatzes, um zu identifizieren, ob eine Aktivierung der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen verursachen wird; und Bestimmen, die Fahrzeuganwendung zu aktivieren, basierend darauf, dass der Konflikt nicht identifiziert wird. Andere Ausführungsbeispiele dieses Aspekts umfassen entsprechende Computersysteme, Vorrichtungen und Computerprogramme, die auf einer oder mehreren Computerspeichereinrichtungen aufgezeichnet sind, die jeweils konfiguriert sind, um die Aktionen der Verfahren durchzuführen.
Implementierungen können eines oder mehrere der folgenden Merkmale umfassen. Das System, wobei die erste Konflikttabelle digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft. Das System, wobei das Fahrzeug ein autonomes Fahrzeug ist. Das System, wobei das Fahrzeug ein hochautonomes Fahrzeug ist. Das System, wobei die Fahrzeuganwendung ein fortgeschrittenes Fahrerassistenzsystem ist. Das System, wobei der fahrzeuginterne Fahrzeugcomputer eine elektronische Steuerungseinheit ist. Implementierungen der beschriebenen Technologien können Hardware, ein Verfahren oder einen Prozess, oder Computersoftware auf einem computerzugreifbaren Medium umfassen.
Figurenliste
Die Offenbarung wird beispielhaft veranschaulicht und ist in keiner Weise auf die Figuren und anhängenden Zeichnungen beschränkt, in denen gleiche Bezugszeichen verwendet werden, um gleiche Elemente zu bezeichnen.

1 ist eine Blockdarstellung, die ein Betriebsumfeld für ein Konfliktsystem und eine erste Fahrzeuganwendung mit einer Konflikttabelle gemäß einigen Ausführungsbeispielen veranschaulicht.
2 ist eine Blockdarstellung, die ein beispielhaftes Computersystem mit dem Konfliktsystem gemäß einigen Ausführungsbeispielen veranschaulicht.
Die 3-6 sind Blockdarstellungen, die beispielhafte Konflikttabellen gemäß einigen Ausführungsbeispielen veranschaulichen.
7 ist eine Blockdarstellung, die einen beispielhaften Satz von Ressourcen gemäß einigen Ausführungsbeispielen veranschaulicht.
8 ist eine Blockdarstellung, die einen beispielhaften Satz von Kontexten gemäß einigen Ausführungsbeispielen veranschaulicht.
Die 9-11 sind Blockdarstellungen, die beispielhafte Tabellensätze gemäß einigen Ausführungsbeispielen veranschaulichen.
12 ist eine Blockdarstellung, die ein Beispiel eines Verfahrens zum Bestimmen eines Konflikts zwischen zwei oder mehreren Fahrzeuganwendungen basierend auf einem Tabellensatz gemäß einigen Ausführungsbeispielen veranschaulicht.
13 ist eine Blockdarstellung, die ein Beispiel eines Prozessablaufs zum Bestimmen, ob eine Fahrzeuganwendung zu aktivieren ist, gemäß einigen Ausführungsbeispielen veranschaulicht.

Detaillierte Beschreibung
Hier werden Ausführungsbeispiele eines Konfliktsystems und eines Konfliktprotokolls beschrieben, die vorzugsweise Konflikte zwischen Fahrzeuganwendungen eines Fahrzeugs mit einer Plug-and-Play-Systemlandschaft eliminieren.
In einigen Ausführungsbeispielen ist das Konfliktprotokoll ein Satz von Regeln, der beschreibt, welche Fahrzeuganwendungen (z. B. ADAS-Systeme) zulässig sind, in dem Fahrzeug installiert zu werden, oder anderweitig in der Plug-and-Play-Systemlandschaft verfügbar zu machen. Zum Beispiel erfordert das Konfliktprotokoll, dass alle Fahrzeuganwendungen eine Konflikttabelle innerhalb ihres zugrundeliegenden Computercodes umfassen. Das Konfliktprotokoll kann spezifizieren, dass jede Fahrzeuganwendung die Konflikttabelle an einem oder mehreren Orten innerhalb ihres zugrundeliegenden Computercodes umfasst, sodass das Konfliktsystem prüfen kann, ob diese eine Konflikttabelle umfassen.
In einigen Ausführungsbeispielen spezifiziert das Konfliktprotokoll einen Satz von Erfordernissen bezüglich der Konflikttabelle. Zum Beispiel erfordert die Konflikttabelle für jede Fahrzeuganwendung, zu beschreiben: die Ressourcenverwendung der spezifischen Fahrzeuganwendung, die die Konflikttabelle umfasst, während unterschiedlichen Kontexten (z. B. einer oder mehreren Fahrzeuggeschwindigkeiten), sowie die Ressourcenverwendung der Fahrzeuganwendung in allen Kontexten (z. B. zu jeder Zeit, wenn die Software aktiv ist). Beispiele von Ressourcen sind gemäß einigen Ausführungsbeispielen in 7 veranschaulicht. Beispiele von Konflikttabellen sind gemäß einigen Ausführungsbeispielen in den 3-6 veranschaulicht.
Das Konfliktsystem umfasst einen Code und Routinen, die in einem fahrzeuginternen Fahrzeugcomputer des Fahrzeugs installiert sind. In einigen Ausführungsbeispielen sind der Code und die Routinen des Konfliktsystems betreibbar, wenn diese durch den fahrzeuginternen Fahrzeugcomputer ausgeführt werden, um den fahrzeuginternen Fahrzeugcomputer zu bewirken, einen oder mehrere der folgenden Schritte auszuführen: (1) Analysieren von Fahrzeuganwendungen, bevor diese installiert werden, um zu bestimmen, ob diese eine Konflikttabelle umfassen [d.h. Bestimmen, ob die Fahrzeuganwendungen mit dem Konfliktprotokoll konform sind]; (2) Verhindern der Installation einer beliebigen Fahrzeuganwendung, die keine Konflikttabelle umfasst; (3) Zusammenfassen der Konflikttabellen für jede Fahrzeuganwendung, wenn die Fahrzeuganwendung in dem Fahrzeug installiert wird; und (4) während des Betriebs, Analysieren der Konflikttabellen für eine oder mehrere aktive Fahrzeuganwendungen und eine Fahrzeuganwendung, deren Operation ansteht, aktiv zu werden [z. B. weil ein fahrzeuginterner Fahrzeugcomputer des Fahrzeugs versucht, die Fahrzeuganwendung auszuführen], um zu bestimmen, ob beliebige Konflikte zwischen der anstehenden Fahrzeuganwendung und einer oder mehreren aktiven Fahrzeuganwendungen vorliegen. Wenn in Schritt 4 kein Konflikt vorliegt, führt das Konfliktsystem Schritt 5 aus. Wenn in Schritt 4 ein Konflikt vorliegt, führt das Konfliktsystem anschließend Schritt 6 aus. In Schritt 5 lässt das Konfliktsystem zu, dass die anstehende Fahrzeuganwendung aktiviert oder gestartet wird. In Schritt 6 mildert das Konfliktsystem den Konflikt durch Steuern einer Operation einer Hardwaresteuerung der Softwareplattform des Fahrzeugs, um zu verhindern, dass die anstehende Fahrzeuganwendung aktiviert wird, sodass die Konflikte, die durch Aktivieren der anstehenden Fahrzeuganwendung verursacht werden würden, vermieden werden. Durch Ausführen dieser Schritte verbessert das Konfliktsystem positiv die Leistungsfähigkeit des Fahrzeugs durch Ermöglichen einer Plug-and-Play-Systemlandschaft, um Ressourcenkonflikte zwischen Fahrzeuganwendungen zu identifizieren, bevor diese auftreten, und unternimmt Schritte, um diese Konflikte abzuschwächen, sodass diese nicht auftreten. Das Konfliktsystem garantiert ebenso vorzugsweise, dass solche Konflikte kein fatales Problem bezüglich des Fahrzeugs oder seiner menschlichen Passagiere verursacht.
Bezugnehmend auf 1 ist eine Blockdarstellung gezeigt, die eine Betriebsumgebung 100 für ein Konfliktsystem 199 und eine erste Fahrzeuganwendung 181 mit einer Konflikttabelle 198 gemäß einigen Ausführungsbeispielen veranschaulicht. Wie dargelegt umfasst die Betriebsumgebung 100 die folgenden Elemente: die erste Fahrzeuganwendung 181; und ein Fahrzeug 123.
In einigen Ausführungsbeispielen umfasst die Betriebsumgebung 100 eine zweite Fahrzeuganwendung 182. Das Konfliktsystem 199 umfasst einen Code und Routinen, die betreibbar sind, wenn diese durch den Prozessor 125 ausgeführt werden, um ein Konfliktprotokoll zu erzwingen. Das Konfliktprotokoll ist ein Satz von Regeln, der in dem Konfliktsystem 199 gespeichert ist, und reguliert, welche Fahrzeuganwendungen in dem Fahrzeug 123 installiert sind (z. B. in der elektronischen Steuerungseinheit 122 des Fahrzeugs 123 installiert sind). Das Konfliktprotokoll erfordert, dass jede beliebige Fahrzeuganwendung, die in dem Fahrzeug 123 installiert ist, als einen Teil ihres Computercodes, eine Konflikttabelle (wie etwa die Konflikttabelle 198) umfassen muss, die spezifisch für die bestimmte Fahrzeuganwendung ist, deren Computercode die Konflikttabelle umfasst.
Wie in 1 dargestellt ist, ist die erste Fahrzeuganwendung 181 konform mit dem Konfliktprotokoll, weil ihr Computercode die Konflikttabelle 198 umfasst. Demzufolge ist die erste Fahrzeuganwendung 181 in 1 so dargestellt, dass diese in dem Speicher 127 des Fahrzeugs 123 gespeichert ist. Die zweite Fahrzeuganwendung 182 ist nicht konform mit dem Konfliktprotokoll, weil die zweite Fahrzeuganwendung 182 keine Konflikttabelle speichert. Demzufolge ist die zweite Fahrzeuganwendung 182 nicht in dem Speicher 127 installiert, weil das Konfliktsystem 199 nicht zulassen wird, dass die zweite Fahrzeuganwendung 182 in dem Fahrzeug 123 zu installieren ist. Auf die Weise dieses Beispiels verbessert das Konfliktsystem 199 die Leistungsfähigkeit des Fahrzeugs 123 durch Ermöglichen einer Plug-and-Play-Systemlandschaft, in dem Fahrzeuganwendungen, die nicht mit dem Konfliktprotokoll konform sind, nicht in dem Fahrzeug 123 zu installieren sind, weil es beispielsweise ohne die Konflikttabelle nicht möglich ist, zu wissen, ob ein Ausführen der Fahrzeuganwendung Konflikte mit anderen in dem Fahrzeug installierten Fahrzeuganwendungen verursachen würde, wenn diese Fahrzeuganwendungen gleichzeitig ausgeführt werden. Im Rest dieser Beschreibung wird die erste Fahrzeuganwendung 181 als die „Fahrzeuganwendung 181“ bezeichnet.
Das Fahrzeug 123 ist ein straßenbasiertes Beförderungsmittel. Zum Beispiel ist das Fahrzeug 123 eines der folgenden Typen von Beförderungsmitteln: ein Automobil; ein Lastwagen; ein Sports Utility Vehicle; ein Bus; ein Sattelzug; eine Drohne, oder ein beliebiges anderes straßenbasiertes Beförderungsmittel.
In einigen Ausführungsbeispielen ist das Fahrzeug 123 ein autonomes Fahrzeug. Zum Beispiel ist das Fahrzeug 123 eines der Folgenden: ein autonomes Fahrzeug von Level 1, ein autonomes Fahrzeug von Level 2; ein autonomes Fahrzeug von Level 3, ein autonomes Fahrzeug von Level 4; und ein autonomes Fahrzeug von Level 5. In einigen Ausführungsbeispielen ist das Fahrzeug 123 ein HAV. Ein HAV ist ein autonomes Fahrzeug, dessen Satz von ADAS-Betriebssystemen eine autonome Funktionalität bereitstellt, die ausreichend ist, um bei Level 3 oder darüber zu arbeiten. Ein Beispiel eines fahrzeuginternen Fahrzeugcomputers für das Fahrzeug 123 ist gemäß einigen Ausführungsbeispielen in 2 dargestellt.
Wie in 1 dargestellt ist, umfasst das Fahrzeug 123 eine elektronische Steuerungseinheit („ECU 122“). Die ECU 122 ist ein fahrzeuginternes Fahrzeugcomputersystem. In einigen Ausführungsbeispielen ist das in 2 dargestellte Computersystem 201 ein Beispiel einer ECU 122.
Wie in 1 dargestellt ist, umfasst das Fahrzeug 123 die folgenden Elemente: den Prozessor 125; eine Kommunikationseinheit 145; einen Ressourcensatz 170; eine Hardwaresteuerung 189; und den Speicher 127.
Der Prozessor 125 umfasst eine arithmetische Logikeinheit, einen Mikroprozessor, eine Allgemeinzwecksteuerung, oder einige andere Prozessoranordnungen, um Berechnungen durchzuführen und elektronische Signale bereitzustellen, die erforderlich sind, um die Funktionalität der ECU 122 (oder dem in 2 dargestellten Computersystem 200) bereitzustellen. Der Prozessor 125 verarbeitet Datensignale und kann verschiedene Berechnungsarchitekturen umfassend eine komplexe Anweisungssatzcomputer-(CISC-)Architektur, eine reduzierte Anweisungssatzcomputer-(RISC-)Architektur, oder eine Architektur, die eine Kombination von Anweisungssätzen implementiert, umfassen. Die ECU 122 (oder das Computersystem 200) kann einen oder mehrere Prozessoren 125 umfassen. Weitere Prozessoren, Betriebssysteme, Sensoren, Anzeigen und physikalische Konfigurationen sind möglich. In einigen Ausführungsbeispielen sind der eine oder die mehreren Prozessoren 125 ein Element eines fahrzeuginternen Fahrzeugcomputers oder der elektronischen Steuerungseinheit der ECU 122 (oder des Computersystems 200).
Die Kommunikationseinheit 145 ist eine elektronische Kommunikationsschnittstelle, die betreibbar ist, um elektronische Nachrichten zu senden und zu empfangen. In einigen Ausführungsbeispielen umfasst die Kommunikationseinheit 145 einen Anschluss für eine direkte physikalische Verbindung mit der ECU 122. Zum Beispiel umfasst die Kommunikationseinheit 145 einen universellen seriellen Bus (USB), Secure Digital (SD), CAT-5, oder einen ähnlichen Anschluss für eine verdrahtete Kommunikation mit der ECU 122.
In einigen Ausführungsbeispielen umfasst die Kommunikationseinheit 145 einen drahtlosen Sendeempfänger zum Datenaustausch mit der ECU 122 und andere kommunikationsermöglichende Einrichtungen, die ein oder mehrere drahtlose Kommunikationsverfahren verwenden, umfassend eines oder mehrere der Folgenden: IEEE 802.11; IEEE 802.16, BLUETOOTH®; EN ISO 14906:2004 Electronic Fee Collection - Application interface EN 11253:2004 Dedicated Short-Range Communication - Physical layer using microwave at 5.8 GHz (review); EN 12795:2002 Dedicated Short-Range Communication (DSRC) - DSRC Data link layer: Medium Access and Logical Link Control (review); EN 12834:2002 Dedicated Short-Range Communication - Application layer (review); EN 13372:2004 Dedicated Short-Range Communication (DSRC) - DSRC profiles for RTTT applications (review); das in der US-Patentanmeldung 14/471,387 , eingereicht am 28.8.2014 mit dem Titel „Full-Duplex Coordination System“ beschriebene Kommunikationsverfahren; und ein anderes geeignetes drahtloses Kommunikationsverfahren.
In einigen Ausführungsbeispielen umfasst die Kommunikationseinheit 145 ein Full-Duplex-Koordinationssystem, wie in der US-Patentanmeldung 14/471,387 , eingereicht am 28.8.2014 mit dem Titel „Full-Duplex Coordination System“ beschrieben ist.
In einigen Ausführungsbeispielen umfasst die Kommunikationseinheit 145 einen zellulären Kommunikationssendeempfänger zum Senden und Empfangen von Daten über ein zelluläres Kommunikationsnetzwerk umfassend über Kurzmitteilungsdienst (SMS), Multimedianachrichtendienst (MMS), Hypertext Transfer Protokoll (HTTP), direkte Datenverbindung, WAP, E-Mail, oder einen anderen geeigneten Typ von elektronischer Kommunikation. In einigen Ausführungsbeispielen umfasst die Kommunikationseinheit 145 einen verdrahteten Anschluss und einen drahtlosen Sendeempfänger. Die Kommunikationseinheit 145 stellt ebenso andere herkömmliche Verbindungen zu einem oder mehreren drahtlosen Netzwerken (z. B. ein fahrzeuginternes drahtloses Netzwerk) zum Verteilen von Dateien oder Medienobjekten unter Verwendung von Standardnetzwerkprotokollen umfassend TCP/IP, HTTP, HTTPS und SMTP, Millimeterwelle, DSRC, etc. bereit.
In einigen Ausführungsbeispielen empfängt die Kommunikationseinheit 145 eine oder mehrere der nachstehend mit Bezugnahme auf 12 beschriebenen Anforderungen. In einigen Ausführungsbeispielen werden eine oder mehrere Fahrzeuganwendungen in dem Fahrzeug 123 über die Kommunikationseinheit 145 installiert. Zum Beispiel werden digitale Daten, die die Fahrzeuganwendung 181 beschreiben, über die Kommunikationseinheit 145 empfangen und durch das Konfliktsystem 199 in dem Speicher 127 installiert, wenn die Fahrzeuganwendung 181 konform mit dem Konfliktprotokoll ist.
Eine Signalleitung 140 wird durch die Kommunikationseinheit 145 verwendet, um die Fahrzeuganwendung 181 als Antwort darauf, dass das Konfliktsystem 199 bestimmt, dass die Fahrzeuganwendung 181 eine Konflikttabelle 198 umfasst und daher mit dem Konfliktprotokoll konform ist, zu installieren.
Eine Signalleitung 141 wird durch die Kommunikationseinheit 145 verwendet, um ausreichende digitale Daten dem Konfliktsystem 199 bereitzustellen, um zu bestimmen, dass die zweite Fahrzeuganwendung 182 nicht konform mit dem Konfliktprotokoll ist und daher nicht in dem Fahrzeug 123 installiert werden kann.
Der Ressourcensatz 170 ist ein Satz von einer oder mehreren Ressourcen, die eine Fahrzeugfunktionalität bereitstellen. Eine Ressource ist eine fahrzeugbezogene Einrichtung, die einer Komponente des Fahrzeugs 123 einen Nutzen bereitstellt. Zum Beispiel ist eine Ressource eine Fahrzeugeinrichtung, die der Fahrzeuganwendung 181 einen Nutzen bereitstellt. Beispiele von in dem Ressourcensatz 170 enthaltenen einer oder mehreren Ressourcen sind in 7 dargestellt. Die eine oder mehreren Ressourcen, die in den Ressourcensatz 170 enthalten sind, sind kommunikationsfähig mit der Hardwaresteuerung 189 über eine Signalleitung 143 gekoppelt.
Die Hardwaresteuerung 189 ist eine Steuerung, die betreibbar ist, um zu steuern, welche Fahrzeuganwendungen (z. B. die Fahrzeuganwendung 181 und/oder andere in dem Speicher 127 gespeicherte Fahrzeuganwendungen) dazu fähig sind, auf eine in dem Ressourcensatz 170 enthaltene Ressource zuzugreifen.
In einigen Ausführungsbeispielen befindet sich die Hardwaresteuerung 189 gemäß der Architektur zwischen den Fahrzeuganwendungen und der einen oder den mehreren Ressourcen, die in dem Ressourcensatz 170 enthalten sind, sodass auf keine Ressource des Ressourcensatzes 170 durch eine beliebige Fahrzeuganwendung des Fahrzeugs 123 zugegriffen werden kann, wenn keine Zulassung der Hardwaresteuerung 189 vorliegt. Zum Beispiel wird angenommen, dass die Fahrzeuganwendung 181 ein ADAS-System ist, das Sensordaten von einem Sensor benötigt, der in dem Ressourcensatz 170 enthalten ist. In diesem Beispiel kann das ADAS-System den Sensor nicht aktivieren oder die Sensordaten empfangen, ohne Empfangen einer Zulassung von der Hardwaresteuerung 189, um auf diesen bestimmten Sensor des Ressourcensatzes 170 zuzugreifen.
In einigen Ausführungsbeispielen steuert das Konfliktsystem 199 die Operation der Hardwaresteuerung 189 basierend auf dem Tabellensatz 197, sodass Konflikte weder durch gleichzeitige Verwendung einer Ressource oder Verwendung einer bestimmten Ressource, die bezüglich der Spezifikation des Fahrzeugs 123 überschüssig ist, noch die bestimmte Ressource erzeugt werden.
Der Speicher 127 ist ein nicht-transitorisches Speichermedium, das Anweisungen oder Daten speichert, auf die durch einen fahrzeuginternen Fahrzeugcomputer des Fahrzeugs 123 wie etwa die ECU 122 (oder das Computersystem 200) zugegriffen und ausgeführt werden kann. Die Anweisungen oder Daten können einen Code zum Durchführen der hier beschriebenen Technologien umfassen. Der Speicher 127 kann eine dynamische Schreib-Lese-Speicher-(DRAM-)Einrichtung, eine statische Schreib-Lese-Speicher-(SRAM-)Einrichtung, ein Flashspeicher, oder eine andere Speichereinrichtung sein. In einigen Ausführungsbeispielen umfasst der Speicher 127 ebenso einen nicht-volatilen Speicher oder eine ähnliche permanente Speichereinrichtung, sowie Medien umfassend ein Festplattenlaufwerk, ein Diskettenlaufwerk, eine CD-ROM-Einrichtung, eine DVD-ROM-Einrichtung, eine DVD-RAM-Einrichtung, eine DVD-RW-Einrichtung, eine Flashspeichereinrichtung, oder eine andere Massenspeichereinrichtung zum Speichern von Informationen auf einer permanenteren Basis. Ein Abschnitt des Speichers 127 kann zur Verwendung als ein Puffer oder virtueller Schreib-Lese-Speicher (virtueller RAM) reserviert werden.
Wie dargestellt speichert der Speicher 127 die folgenden Elemente: das Konfliktsystem 199; den Tabellensatz 197; eine Warteschlange 188; und eine oder mehrere Fahrzeuganwendungen 181, die mit dem Konfliktprotokoll konform sind, weil diese jeweils eine für sie spezifische Konflikttabelle 198 umfassen.
Obwohl in 1 nur eine Fahrzeuganwendung 181 dargestellt ist, in dem Speicher 127 gespeichert zu sein, kann in der Praxis der Speicher 127 eine Vielzahl von Fahrzeuganwendungen 181 speichern, die jeweils unterschiedliche Funktionalitäten bezüglich einander bereitstellen. Zum Beispiel kann der Speicher 127 eine Vielzahl von unterschiedlichen ADAS-Systemen speichern, die jeweils unterschiedliche Funktionalitäten bezüglich einander bereitstellen.
Eine Konflikttabelle 198 ist eine Datenstruktur, die beschreibt: die Ressourcenverwendung der spezifischen Fahrzeuganwendung 181, die die Konflikttabelle 198 umfasst, während unterschiedlichen Kontexten (z. B. einer oder mehreren Fahrzeuggeschwindigkeiten), sowie die Ressourcenverwendung der Fahrzeuganwendung 181 in allen Kontexten (z. B. immer, wenn die Software aktiv ist). Beispiele der Konflikttabellen sind gemäß einigen Ausführungsbeispielen in den 3-6 dargestellt.
In einigen Ausführungsbeispielen ist die Konflikttabelle 198 eine Datenstruktur, die beschreibt: einen fahrzeugbezogenen Kontext (z. B. Geschwindigkeit des Fahrzeugs 123), wenn die Fahrzeuganwendung 181 durch einen fahrzeuginternen Fahrzeugcomputer (z. B. die ECU 122) des Fahrzeugs 123 verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung 181 während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft (z. B. wenn das Fahrzeug 123 bei einer Geschwindigkeit fährt, die größer ist als 20 Meilen pro Stunde); und eine zweite Ressourcenverwendung der Fahrzeuganwendung 181 während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft (z. B. zu allen Zeiten, wenn die Geschwindigkeit des Fahrzeugs nicht größer als 20 Meilen pro Stunde ist).
Die Fahrzeuganwendung 181 umfasst einen Code und Routinen, die betreibbar sind, wenn diese durch den Prozessor 125 ausgeführt werden, um den Prozessor 125 zu bewirken, eine Fahrzeugfunktionalität bezüglich des Fahrzeugs 123 bereitzustellen. Zum Beispiel ist die Fahrzeuganwendung 181 ein ADAS-System, das eine bestimmte ADAS-Funktionalität bezüglich des Fahrzeugs 123 bereitstellt.
Beispiele einer Fahrzeuganwendung 181 sind eines oder mehrere der folgenden ADAS-Systeme: ein Abstandstempomat-(„ACC“-)System, ein adaptives Fernlichtsystem; ein adaptives Lichtsteuerungssystem; ein automatisches Parksystem; ein Automobilnachtsichtsystem; eine Totwinkelüberwachung; ein Kollisionsvermeidungssystem; ein Seitenwindstabilisierungssystem; ein Fahrerschläfrigkeitserfassungssystem; ein Fahrerüberwachungssystem; ein Notfallfahrerassistenzsystem; ein Vorwärtskollisionswarnsystem; ein Kreuzungsassistenzsystem; ein intelligentes Geschwindigkeitsadaptionssystem; ein Spurabweichungswarnsystem; ein Fußgängerschutzsystem; ein Verkehrszeichenerkennungssystem; ein Kurvenfahrtassistent; und ein Geisterfahrerwarnsystem. Jedes dieser beispielhaften ADAS-Systeme stellt seine eigenen Merkmale und Funktionalitäten bereit, die hier als „ADAS-Merkmal“ bzw. „ADAS-Qualität“ bezeichnet werden können. Die Merkmale und Funktionalitäten, die durch diese beispielhaften ADAS-Systeme 180 bereitgestellt werden, werden hier ebenso als „autonomes Merkmal“ bzw. „autonome Funktionalitäten“ bezeichnet.
In einigen Ausführungsbeispielen sind die autonomen Merkmale und autonomen Funktionalitäten, die durch die Fahrzeuganwendung bereitgestellt werden, ausreichend, um das Fahrzeug 123 als eines oder mehrere der Folgenden zu klassifizieren: ein autonomes Fahrzeug von Level 1; ein autonomes Fahrzeug von Level 2; ein autonomes Fahrzeug von Level 3; ein autonomes Fahrzeug von Level 4; und ein autonomes Fahrzeug von Level 5. In einigen Ausführungsbeispielen ist das Fahrzeug 123 ein HAV. Ein HAV ist in autonomes Fahrzeug, dessen Fahrzeuganwendungen, wenn diese in der Gesamtheit betrachtet werden, eine autonome Funktionalität bereitstellen, die ausreichend ist, um bei Level 3 oder darüber zu arbeiten. Ein Beispiel eines fahrzeuginternen Fahrzeugcomputers für das Fahrzeug 123 ist gemäß einigen Ausführungsbeispielen in 2 dargestellt. In einigen Ausführungsbeispielen stellt 2 eine ECU 122 des Fahrzeugs 123 dar.
Das ADAS-System kann ebenso beliebige in dem Fahrzeug enthaltene Software oder Hardware umfassen, die das Fahrzeug 123 bewirken, ein autonomes Fahrzeug oder ein halbautonomes Fahrzeug zu sein.
In einigen Ausführungsbeispielen verwendet die Fahrzeuganwendung 181 eine oder mehrere der in dem Ressourcensatz enthaltenen Ressourcen, um deren Funktionalität bereitzustellen.
Der Tabellensatz 197 sind digitale Daten, die eine Kombination von zwei oder mehreren Konflikttabellen 198 für zwei oder mehrere Fahrzeuganwendungen 181 beschreiben. Beispiele eines Tabellensatzes 197 sind gemäß einigen Ausführungsbeispielen in den 9-11 dargestellt.
Die Warteschlange 188 ist ein Abschnitt eines nicht-transitorischen Speichers, der speichert: (1) eine Liste von Fahrzeuganwendungen 181, die darauf warten, aktiviert (z. B. ausgeführt) zu werden; und (2) eine Liste von Fahrzeuganwendungen 181, die gegenwärtig aktiv sind (z. B. gegenwärtig ausgeführt werden).
Das Konfliktsystem 199 umfasst einen Code und Routinen, die in der ECU 122 installiert sind. In einigen Ausführungsbeispielen sind der Code und die Routinen des Konfliktsystems 199 ausführbar, wenn diese durch den Prozessor 125 ausgeführt werden, um den Prozessor 125 zu bewirken, einen oder mehrere der folgenden Schritte auszuführen: (1) Analysieren von Fahrzeuganwendungen 181, 182, bevor diese in dem Fahrzeug 123 installiert werden, um zu bestimmen, ob diese eine Konflikttabelle 198 umfassen [d.h. Bestimmen, ob die Fahrzeuganwendungen 181, 182 mit dem Konfliktprotokoll konform sind]; (2) Verhindern der Installation einer beliebigen Fahrzeuganwendung, die keine Konflikttabelle 198 umfasst [z. B. die zweite Fahrzeuganwendung 182 umfasst keine Konflikttabelle 198]; (3) Zusammenführen der Konflikttabellen 198 für jede Fahrzeuganwendung 181, wenn die Fahrzeuganwendung 181 im Fahrzeug 123 installiert wird; und (4) bei Ausführung, Analysieren der Konflikttabellen 198 für eine oder mehrere aktive Fahrzeuganwendungen und einer Fahrzeuganwendung, deren Betrieb aussteht, aktiv zu werden [z. B. weil der Prozessor 125 versucht, die Fahrzeuganwendung auszuführen], um zu bestimmen, ob beliebige Konflikte zwischen der ausstehenden Fahrzeuganwendung und der einen oder den mehreren aktiven Fahrzeuganwendungen vorliegen. Wenn in Schritt 4 kein Konflikt vorliegt, führt anschließend das Konfliktsystem 199 Schritt 5 aus. Wenn in Schritt 4 ein Konflikt vorliegt, führt anschließend das Konfliktsystem 199 Schritt 6 aus. In Schritt 5 lässt das Konfliktsystem 199 zu, dass die ausstehende Fahrzeuganwendung aktiviert oder gestartet wird. In Schritt 6 schwächt das Konfliktsystem 199 den Konflikt durch Steuern einer Operation einer Hardwaresteuerung 189 des Fahrzeugs 123 ab, um zu verhindern, dass die anstehende Fahrzeuganwendung aktiviert wird, sodass die Konflikte, die durch Aktivieren der ausstehenden Fahrzeuganwendung verursacht werden würden, vermieden werden. Durch Ausführen dieser Schritte verbessert das Konfliktsystem 199 positiv die Leistungsfähigkeit des Fahrzeugs 123 durch Ermöglichen einer Plug-and-Play-Systemlandschaft, um Ressourcenkonflikte zwischen Fahrzeuganwendungen 181 zu identifizieren, bevor diese auftreten, und um Schritte zu unternehmen, diese Konflikte abzuschwächen, dass diese nicht auftreten. Das Konfliktsystem 199 garantiert ebenso vorzugsweise, dass solche Konflikte kein fatales Problem bezüglich des Fahrzeugs 123 verursachen.
In einigen Ausführungsbeispielen führt das Konfliktsystem 199 einen oder mehrere Schritte des in 12 dargestellten Verfahrens 1200 aus.
In einigen Ausführungsbeispielen ist das Konfliktsystem 199 unter Verwendung von Hardware umfassend ein feldprogrammierbares Gate-Array („FPGA“) oder eine anwendungsspezifische integrierte Schaltung („ASIC“) implementiert. In einigen anderen Ausführungsbeispielen ist das Konfliktsystem 199 unter Verwendung einer Kombination von Hardware und Software implementiert. Das Konfliktsystem 199 kann in einer Kombination der Einrichtungen (z. B. einer oder mehrere ECUs 122), oder in einer der Einrichtungen gespeichert sein. Zusätzliche Elemente des Konfliktsystems 199 sind gemäß einigen Ausführungsbeispielen in 2 dargestellt.
Nun ist Bezug nehmend auf 2 eine Blockdarstellung gezeigt, die ein beispielhaftes Computersystem 200 umfassend das Konfliktsystem gemäß einigen Ausführungsbeispielen veranschaulicht.
In einigen Ausführungsbeispielen ist das Computersystem 200 ein Spezialzweckcomputersystem, das programmiert ist, um einen oder mehrere Schritte eines nachstehend mit Bezugnahme auf 12 beschriebenen Verfahrens 1200 durchzuführen.
In einigen Ausführungsbeispielen ist das Computersystem 200 ein fahrzeuginterner Fahrzeugcomputer des Fahrzeugs 123. Zum Beispiel ist das Computersystem 200 die ECU 122.
In einigen Ausführungsbeispielen ist das Computersystem 200 eine fahrzeugeigene Einheit, ECU, Haupteinheit, oder eine andere prozessorbasierte Computereinrichtung des Fahrzeugs 123.
Das Computersystem 200 kann eines oder mehrere der folgenden Elemente gemäß einigen Beispielen umfassen: das Konfliktsystem 199; den Prozessor 125; den Speicher 127; die Kommunikationseinheit 145; und die Hardwaresteuerung 189. Diese Komponenten des Computersystems 200 sind über den Bus 220 kommunikationsfähig gekoppelt.
In dem veranschaulichten Ausführungsbeispiel ist der Prozessor 125 kommunikationsfähig mit dem Bus 220 über eine Signalleitung 238 gekoppelt. Der Speicher 127 ist kommunikationsfähig mit dem Bus 220 über eine Signalleitung 244 gekoppelt. Die Kommunikationseinheit 145 ist kommunikationsfähig mit dem Bus 220 über eine Signalleitung 246 gekoppelt. Die Hardwaresteuerung 189 ist kommunikationsfähig mit dem Bus 220 über eine Signalleitung 239 gekoppelt.
Diese Elemente des Computersystems 200, die vorstehend mit Bezugnahme auf 1 beschrieben wurden, sowie deren Beschreibungen werden hier nicht wiederholt: das Konfliktsystem 199; der Prozessor 125; der Speicher 127; die Kommunikationseinheit 145; und die Hardwaresteuerung 189.
In einigen Ausführungsbeispielen speichert der Speicher 127 beliebige der hier beschriebenen Daten, Informationen oder Nachrichten. Der Speicher 127 kann beliebige Daten speichern, die das Computersystem 200 benötigt, um dessen Funktionalität bereitzustellen.
In dem in 2 gezeigten veranschaulichten Ausführungsbeispiel umfasst das Konfliktsystem 199 ein Kommunikationsmodul 202 und ein Bestimmungsmodul 204.
Das Kommunikationsmodul 202 kann eine Software umfassend Routinen zum Handhaben von Kommunikationen zwischen dem Konfliktsystem 199 und anderen Komponenten des Computersystems 200 sein. In einigen Ausführungsbeispielen kann das Kommunikationsmodul 202 ein Satz von Instruktionen sein, die durch den Prozessor 125 ausführbar sind, um die nachstehend beschriebene Funktionalität zum Handhaben von Kommunikationen zwischen dem Konfliktsystem 199 und anderen Komponenten des Computersystems 200 bereitzustellen.
Das Kommunikationsmodul 202 sendet und empfängt Daten über die Kommunikationseinheit 145 zu und von einem oder mehreren Elementen der Betriebsumgebung 100 (siehe z. B. 1). Zum Beispiel empfängt oder überträgt das Kommunikationsmodul 202, über die Kommunikationseinheit 145, beliebige von hier beschriebenen in dem Speicher 127 gespeicherten Daten oder Nachrichten (z. B. Anforderungen). Das Kommunikationsmodul 202 kann beliebige der hier beschriebenen Daten oder Nachrichten über die Kommunikationseinheit 145 senden oder empfangen.
In einigen Ausführungsbeispielen empfängt das Kommunikationsmodul 202 eine oder mehrere Nachrichten von der Kommunikationseinheit 145, die digitale Daten umfassen, die beschreiben, ob eine Fahrzeuganwendung 181, 182 eine Konflikttabelle umfasst.
In einigen Ausführungsbeispielen kann das Kommunikationsmodul 202 Kommunikationen zwischen Komponenten des Konfliktsystems 199 handhaben.
In einigen Ausführungsbeispielen kann das Kommunikationsmodul 202 in dem Speicher 127 des Computersystems 200 gespeichert sein und kann durch den Prozessor 125 zugreifbar und ausführbar sein. Das Kommunikationsmodul 202 kann für eine Kooperation und Kommunikation mit dem Prozessor 125 und anderen Komponenten des Computersystems 200 über eine Signalleitung 222 eingerichtet sein.
Das Bestimmungsmodul 204 kann eine Software umfassend Routinen zum Ausführen von einem oder mehreren Schritten des in 12 dargestellten Verfahrens 1200 sein. In einigen Ausführungsbeispielen kann die Bestimmung eine Software umfassend Routinen zum Ausführen von einem oder mehreren der folgenden Schritte sein: (1) Analysieren von Fahrzeuganwendungen 181, 182, bevor diese in dem Fahrzeug 123 installiert werden, um zu bestimmen, ob diese eine Konflikttabelle 198 umfassen [d.h. Bestimmen, ob die Fahrzeuganwendungen 181, 182 mit dem Konfliktprotokoll konform sind]; (2) Verhindern der Installation einer beliebigen Fahrzeuganwendung, die keine Konflikttabelle 198 umfasst [z. B. die zweite Fahrzeuganwendung 182 umfasst keine Konflikttabelle 198]; (3) Zusammenführen der Konflikttabellen 198 für jede Fahrzeuganwendung 181, wenn die Fahrzeuganwendung 181 in dem Fahrzeug 123 installiert wird; und (4) während der Ausführung, Analysieren der Konflikttabellen 198 für eine oder mehrere aktive Fahrzeuganwendungen und eine Fahrzeuganwendung, deren Betrieb ansteht, aktiviert zu werden [z. B. weil der Prozessor 125 versucht, die Fahrzeuganwendung auszuführen], und Bestimmen, ob beliebige Konflikte zwischen der anstehenden Fahrzeuganwendung und der einen oder mehreren aktiven Fahrzeuganwendungen vorliegen. Wenn in Schritt 4 kein Konflikt vorliegt, führt das Konfliktsystem 199 anschließend Schritt 5 aus. Wenn in Schritt 4 ein Konflikt vorliegt, führt das Konfliktsystem 199 anschließend Schritt 6 aus. In Schritt 5 lässt das Konfliktsystem 199 zu, dass die anstehende Fahrzeuganwendung aktiviert oder gestartet wird. In Schritt 6 mildert das Konfliktsystem 199 den Konflikt durch Steuern einer Operation einer Hardwaresteuerung 189 des Fahrzeugs 123 zum Verhindern, dass die anstehende Fahrzeuganwendung aktiviert wird, ab, sodass die Konflikte, die durch Aktivieren der anstehenden Fahrzeuganwendung verursacht werden würden, vermieden werden.
In einigen Ausführungsbeispielen kann das Bestimmungsmodul 204 in dem Speicher 127 des Computersystems 200 gespeichert sein und kann durch den Prozessor 125 zugreifbar und ausführbar sein. Das Bestimmungsmodul 204 kann für eine Kooperation und Kommunikation mit dem Prozessor 125 und anderen Komponenten des Computersystems 200 über eine Signalleitung 224 eingerichtet sein.
Die 3-6 sind Blockdarstellungen, die beispielhafte Konflikttabellen 399, 499, 599, 699 gemäß einigen Ausführungsbeispielen veranschaulichen. Diese Konflikttabellen 399, 499, 599, 699 sind beispielhaft bereitgestellt und sind nicht gedacht, einschränkend zu sein. Die in den 3-6 dargestellten Konzepte bauen aufeinander auf und auf sie wird wiederum in den 9-11 Bezug genommen, um Beispiele von Tabellensätzen gemäß einigen Ausführungsbeispielen zu demonstrieren, die aus Kombinationen dieser Konflikttabellen 399, 499, 599, 699 der 3-6 gebildet werden.
Nun ist Bezug nehmend auf 3 eine Blockdarstellung dargestellt, die eine beispielhafte Konflikttabelle 399 für eine erste beispielhafte Fahrzeuganwendung 300 gemäß einigen Ausführungsbeispielen veranschaulicht. In einigen Ausführungsbeispielen ist die erste beispielhafte Fahrzeuganwendung 300 ein erstes Beispiel eines LKA-Systems.
Die rechte Spalte der in 3 dargestellten Konflikttabelle 399 wird als „Kontextspalte“ bezeichnet. Die 4-6 stellen unterschiedliche Konflikttabellen 499, 599, 699 für unterschiedliche beispielhafte Fahrzeuganwendungen 400, 500, 600 dar, wobei jede davon eine leicht unterschiedliche Kontextspalte als jene für die erste beispielhafte Fahrzeuganwendung 300, die in 3 dargestellt ist, aufweist. Dies liegt daran, dass die Ressourcenverwendung der unterschiedlichen beispielhaften Fahrzeuganwendungen 300, 400, 500, 600 unterschiedlich für unterschiedliche Fahrzeugkontexte eingebunden sind. Zum Beispiel kann die Ressourcenverwendung für eine Fahrzeuganwendung nur basierend auf einer Geschwindigkeit des Fahrzeugs eingebunden werden, wohingegen die Ressourcenverwendung für eine unterschiedliche Fahrzeuganwendung basierend auf der Geschwindigkeit des Fahrzeugs und darauf, ob die Fahrtrichtungsanzeiger für das Fahrzeug in Betrieb sind, eingebunden sein kann. Ebenso kann unter Fahrzeuganwendungen, deren Ressourcenverwendung durch die Geschwindigkeit des Fahrzeugs beeinträchtigt wird, eine erste Fahrzeuganwendung deren Ressourcenverwendung aufweisen, die durch einen ersten Geschwindigkeitsschwellenwert (z. B. Geschwindigkeiten höher als 20 Meilen pro Stunde) eingebunden sind, wohingegen eine unterschiedliche Fahrzeuganwendung deren Ressourcenverwendung aufweisen kann, die durch einen zweiten Geschwindigkeitsschwellenwert (z. B. Geschwindigkeiten niedriger als 15 Meilen pro Stunde) eingebunden sind.
In 3 ist nur ein Fahrzeugkontext bezüglich des Betriebs der ersten beispielhaften Fahrzeuganwendung relevant, d.h. die Geschwindigkeit des Fahrzeugs, und ob die Geschwindigkeit größer ist als 20 Meilen pro Stunde.
In dem dargestellten Ausführungsbeispiel umfasst die Konflikttabelle 399 eine Zelle, die den fahrzeugbezogenen Kontext 301 für die Konflikttabelle 399 beschreibt. Hierbei ist der fahrzeugbezogene Kontext 301, ob die Geschwindigkeit des Fahrzeugs höher ist als 20 Meilen pro Stunde.
In dem dargestellten Ausführungsbeispiel umfasst die Konflikttabelle 399 eine Spalte, die einen Satz von ersten Ressourcenverwendungen 302 beschreibt, die eingebunden sind, wenn das Fahrzeug bei einer Geschwindigkeit größer als 20 Meilen pro Stunde fährt. Wenn insbesondere das Fahrzeug bei einer Geschwindigkeit größer als 20 Meilen pro Stunde fährt, weist die erste beispielhafte Fahrzeuganwendung 300 die folgenden Ressourcenerfordernisse auf: eine Verwendung der Maschine (z. B. Steuerung der Maschine) wird nicht durch die erste beispielhafte Fahrzeuganwendung 300 erfordert; eine Verwendung der Lenkhardware ist erforderlich; ein exklusiver Zugriff auf eine elektronische Anzeige des Fahrzeugs ist nicht erforderlich (z. B. der Zugriff ist „umschaltbar“, weil es für andere Fahrzeuganwendungen wie etwa einem Infotainment-System zulässig ist, auf die Anzeige zuzugreifen); ein Zugriff auf einen Sendeempfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf den Empfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf einen Prozessor des Fahrzeugs ist mit einer Frequenz von 10 Millisekunden pro Zyklus von 30 Millisekunden erforderlich; und ein Zugriff auf 1 Megabyte des RAM ist erforderlich.
Die Konflikttabelle 399 umfasst eine Spalte, die einen Satz von zweiten Ressourcenverwendungen 303 auflistet, die jederzeit zutreffen, wenn das Fahrzeug bei einer Geschwindigkeit von 20 Meilen pro Stunde oder darunter fährt. Wenn insbesondere das Fahrzeug bei einer Geschwindigkeit von 20 Meilen pro Stunde oder darunter fährt, weist die erste beispielhafte Fahrzeuganwendung 300 die folgenden Ressourcenerfordernisse auf: eine Verwendung der Maschine (z. B. Steuerung der Maschine) ist nicht durch die erste beispielhafte Fahrzeuganwendung 300 erforderlich; eine Verwendung der Lenkhardware ist nicht erforderlich; eine Verwendung der elektronischen Anzeige des Fahrzeugs ist nicht erforderlich; ein Zugriff auf einen Sendeempfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf den Empfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf einen Prozessor des Fahrzeugs ist bei einer Frequenz von 0,1 Millisekunden pro Zyklus von 30 Millisekunden erforderlich; und ein Zugriff auf 10 Kilobyte des RAM ist erforderlich.
Die 3-6 und 9-11 zeigen Kontexttabellen für unterschiedliche Fahrzeuganwendungen. Jede dieser Kontexttabellen umfasst eine Spalte an der linken Seite, die verschiedene Ressourcen auflistet. Enthalten in der Liste von Ressourcen von jeder dieser Kontexttabellen ist eine Anzeige. Die Anzeige ist in jeder der in den 3-6 und 9-11 dargestellten Kontexttabelle in deren Reihe enthalten. Die Terminologie und Symbole für diese „Anzeige“-Reihe werden nun beschrieben. „0“ bedeutet, dass die Fahrzeuganwendung eine Verwendung der Anzeige erfordert, um deren Funktionalität bereitzustellen. „X“ bedeutet, dass die Fahrzeuganwendung die Verwendung der Anzeige zum Bereitstellen deren Funktionalität nicht erfordert. „Umschaltbar“ bedeutet, dass die Fahrzeuganwendungen die Anzeige verwenden, um deren Funktionalität bereitzustellen, jedoch können andere Fahrzeuganwendungen (z. B. ein Infotainment-System) ebenso die Anzeige verwenden. „Exklusiv“ bedeutet, dass die Fahrzeuganwendung eine exklusive Verwendung der Anzeige erfordert, um deren Funktionalität bereitzustellen.
Die Symbole „O“ und „X“ haben ebenso eine Bedeutung für andere Ressourcen (die hier manchmal als „Hardware“ bezeichnet werden), und nicht nur die Anzeige. Zum Beispiel bedeutet „O“, dass die Fahrzeuganwendung die Ressource/Hardware erfordert, um deren Funktionalität bereitzustellen, und „X“ bedeutet, dass die Fahrzeuganwendung die Ressource/Hardware nicht erfordert, um deren Funktionalität bereitzustellen.
Nun ist Bezug nehmend auf 4 eine Blockdarstellung dargestellt, die eine beispielhafte Konflikttabelle 499 für eine zweite beispielhafte Fahrzeuganwendung 400 gemäß einigen Ausführungsbeispielen veranschaulicht. In einigen Ausführungsbeispielen ist die zweite beispielhafte Fahrzeuganwendung 400 ein zweites Beispiel eines LKA-Systems, wohingegen die erste beispielhafte Fahrzeuganwendung 300 von 3 ein erstes Beispiel eines LKA-Systems ist.
4 baut auf der Idee von 3 durch Veranschaulichen mehrerer fahrzeugbezogener Kontexte, die bezüglich der Operation bzw. des Betriebs der zweiten beispielhaften Fahrzeuganwendung 400 relevant sind, auf: (1) ob die Geschwindigkeit des Fahrzeugs größer ist als 15 Meilen pro Stunde; und (2) ob der Fahrtrichtungsanzeiger des Fahrzeugs eingeschaltet oder ausgeschaltet ist. Zum Beispiel ist die zweite beispielhafte Fahrzeuganwendung 400 ein zweites Beispiel eines LKA-Systems, und wenn das Fahrtrichtungsanzeigesignal eingeschaltet ist, beabsichtigt der Fahrer des Fahrzeugs, die gestrichelte Linie, die zwei Spuren aufteilt, zu überqueren, was bezüglich des Betriebs bzw. der Operation des LKA-Systems relevant ist.
In dem dargestellten Ausführungsbeispiel umfasst die Konflikttabelle 499 eine Zelle, die den fahrzeugbezogenen Kontext 401 für die Konflikttabelle 499 beschreibt, d.h., ob die Geschwindigkeit des Fahrzeugs größer ist als 15 Meilen pro Stunde und ob der Fahrtrichtungsanzeiger des Fahrzeugs ein- oder ausgeschaltet ist.
In dem dargestellten Ausführungsbeispiel umfasst die Konflikttabelle 499 eine Spalte, die einen Satz von ersten Ressourcenverwendungen 402 beschreibt, die eingebunden werden, wenn das Fahrzeug bei einer Geschwindigkeit höher als 20 Meilen pro Stunde fährt und das Fahrtrichtungsanzeigesignal ausgeschaltet ist. Wenn insbesondere das Fahrzeug bei einer Geschwindigkeit höher als 20 Meilen pro Stunde fährt und das Fahrtrichtungsanzeigesignal ausgeschaltet ist, weist die zweite beispielhafte Fahrzeuganwendung 400 die folgenden Ressourcenerfordernisse auf: eine Verwendung der Maschine (z. B. Steuerung der Maschine) wird durch die zweite beispielhafte Fahrzeuganwendung 400 nicht erfordert; eine Verwendung der Lenkhardware ist erforderlich; ein exklusiver Zugriff auf eine elektronische Anzeige des Fahrzeugs ist nicht erforderlich (z. B. der Zugriff ist „umschaltbar“, weil es für die anderen Fahrzeuganwendungen zulässig ist, auf die Anzeige zuzugreifen); ein Zugriff auf einen Sendeempfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf den Empfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf einen Prozessor des Fahrzeugs ist bei einer Frequenz von 10 Millisekunden pro Zyklus von 30 Millisekunden erforderlich; und ein Zugriff auf 1 Megabyte des RAM ist erforderlich.
Die Konflikttabelle 499 umfasst eine Spalte, die einen Satz von zweiten Ressourcenverwendungen 403 auflistet, die jederzeit zutreffen, wenn eines der Folgenden zutrifft: das Fahrzeug fährt bei einer Geschwindigkeit von 15 Meilen pro Stunde oder darunter; oder ein Fahrtrichtungsanzeigesignal des Fahrzeugs ist eingeschaltet. Wenn insbesondere eines von diesen zutrifft, weist die zweite beispielhafte Fahrzeuganwendung 400 die folgenden Ressourcenerfordernisse auf: eine Verwendung der Maschine (z. B. Steuerung der Maschine) durch die zweite beispielhafte Fahrzeuganwendung 400 ist nicht erforderlich; eine Verwendung der Lenkhardware ist nicht erforderlich; eine Verwendung der elektronischen Anzeige des Fahrzeugs ist nicht erforderlich; ein Zugriff auf einen Sendeempfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf den Empfänger der Kommunikationseinheit 145 ist nicht erforderlich; ein Zugriff auf einen Prozessor des Fahrzeugs ist bei einer Frequenz von 0,1 Millisekunden pro Zyklus von 30 Millisekunden erforderlich; und ein Zugriff auf 10 Kilobyte des RAM ist erforderlich.
Nun ist Bezug nehmend auf 5 ist eine Blockdarstellung dargestellt, die eine beispielhafte Konflikttabelle 599 für eine dritte beispielhafte Fahrzeuganwendung 500 gemäß einigen Ausführungsbeispielen veranschaulicht. In einigen Ausführungsbeispielen ist die dritte beispielhafte Fahrzeuganwendung 500 ein Parkassistenzsystem.
In dem dargestellten Ausführungsbeispiel umfasst die Konflikttabelle 599 eine Zelle, die den fahrzeugbezogenen Kontext 501 für die Konflikttabelle 599 beschreibt, d.h., ob die Geschwindigkeit des Fahrzeugs niedriger ist als 15 Meilen pro Stunde. Die Konflikttabelle 599 umfasst eine Spalte, die einen Satz von ersten Ressourcenverwendungen 502 beschreibt, die eingebunden werden, wenn das Fahrzeug bei einer Geschwindigkeit von weniger als 15 Meilen pro Stunde fährt. Die Konflikttabelle 599 umfasst ebenso eine Spalte, die einen Satz von zweiten Ressourcenverwendungen 503 auflistet, die jederzeit zutreffen, wenn das Fahrzeug mit einer Geschwindigkeit von 15 Meilen pro Stunde oder darüber fährt. Wenn das Fahrzeug mit einer Geschwindigkeit von 15 Meilen pro Stunde oder darüber fährt, erfordert die dritte beispielhafte Fahrzeuganwendung 500, unter anderen in 5 dargestellten Dingen, einen exklusiven Zugriff auf eine elektronische Anzeige des Fahrzeugs (z. B. zur Sicherheit, weil der Fahrer des Fahrzeugs Objekte in dem Pfad des Fahrzeugs sehen muss, sowie durch die dritte beispielhafte Fahrzeuganwendung 500 bereitgestellte visuelle Benachrichtigungen, wenn das Fahrzeug geparkt wird).
Nun ist Bezug nehmend auf 6 eine Blockdarstellung dargestellt, die eine beispielhafte Konflikttabelle 699 für eine vierte beispielhafte Fahrzeuganwendung 600 gemäß einigen Ausführungsbeispielen veranschaulicht. In einigen Ausführungsbeispielen ist die vierte beispielhafte Fahrzeuganwendung 601 ein Spurwechselsystem.
In dem dargestellten Ausführungsbeispiel umfasst die Konflikttabelle 699 eine Zelle, die den fahrzeugbezogenen Kontext 601 für die Konflikttabelle 699 beschreibt, d.h., ob die Geschwindigkeit des Fahrzeugs höher ist als 20 Meilen pro Stunde und ob das Fahrtrichtungsanzeigesignal des Fahrzeugs ein- oder ausgeschaltet ist.
In dem dargestellten Ausführungsbeispiel umfasst die Konflikttabelle 699 eine Spalte, die einen Satz von ersten Ressourcenverwendungen 602 beschreibt, die eingebunden werden, wenn das Fahrzeug mit einer Geschwindigkeit von höher als 20 Meilen pro Stunde fährt und das Fahrtrichtungsanzeigesignal eingeschaltet ist. Die Konflikttabelle 699 umfasst ebenso eine Spalte, die einen Satz von zweiten Ressourcenverwendungen 603 auflistet, die jederzeit zutreffen, wenn eines der Folgenden zutrifft: das Fahrzeug fährt mit einer Geschwindigkeit von 20 Meilen pro Stunde oder darunter; oder ein Fahrtrichtungsanzeigesignal des Fahrzeugs ist ausgeschaltet.
Nun ist Bezug nehmend auf 7 eine Blockdarstellung dargestellt, die einen beispielhaften Satz von Ressourcen 700 gemäß einigen Ausführungsbeispielen veranschaulicht. In einigen Ausführungsbeispielen ist eine oder mehrere der Ressourcen 700 in dem Ressourcensatz 170 enthalten.
Nun ist Bezug nehmend auf 8 eine Blockdarstellung dargestellt, die einen beispielhaften Satz von Kontexten 800 gemäß einigen Ausführungsbeispielen veranschaulicht. In einigen Ausführungsbeispielen kann einer oder mehrere der Kontexte 800 ein Kontext sein, der durch eine Kontextspalte einer Konflikttabelle 198 berücksichtigt wird.
Bezugnehmend auf 9 ist eine Blockdarstellung dargestellt, die einen beispielhaften Tabellensatz 900 veranschaulicht, der die Konflikttabelle 399 für die erste beispielhafte Fahrzeuganwendung 300 und die Konflikttabelle 599 für die dritte beispielhafte Fahrzeuganwendung 500 umfasst. Der Tabellensatz 900 gibt an, dass die erste beispielhafte Fahrzeuganwendung 300 und die dritte beispielhafte Fahrzeuganwendung 500 gleichzeitig aktiviert werden können, weil kein Konflikt auftreten wird.
Bezugnehmend auf 10 ist eine Blockdarstellung dargestellt, die einen beispielhaften Tabellensatz 1000 veranschaulicht, der die Konflikttabelle 399 für die erste beispielhafte Fahrzeuganwendung 300 und die Konflikttabelle 699 für die vierte beispielhafte Fahrzeuganwendung 600 umfasst. Der Tabellensatz 1000 gibt an, dass die erste beispielhafte Fahrzeuganwendung 300 und die vierte beispielhafte Fahrzeuganwendung 600 nicht gleichzeitig aktiviert werden sollten, weil ein Konflikt auftreten wird. Insbesondere ist es bei sowohl der ersten beispielhaften Fahrzeuganwendung 300 als auch der vierten beispielhaften Fahrzeuganwendung 600 erforderlich, auf die Lenkhardware zuzugreifen oder diese zu steuern, wenn: (1) das Fahrzeug mit Geschwindigkeiten höher als 20 Meilen pro Stunde fährt; und (2) das Fahrtrichtungsanzeigesignal eingeschaltet ist. Dies ist ein Beispiel eines Konflikts zwischen der ersten beispielhaften Fahrzeuganwendung 300 und der vierten beispielhaften Fahrzeuganwendung 600.
Bezugnehmend auf 11 ist eine Blockdarstellung dargestellt, die einen beispielhaften Tabellensatz 1100 veranschaulicht, der die Konflikttabelle 499 für die zweite beispielhafte Fahrzeuganwendung 400 und die Konflikttabelle 699 für die vierte beispielhafte Fahrzeuganwendung 600 umfasst. Der Tabellensatz 1100 gibt an, dass die zweite beispielhafte Fahrzeuganwendung 400 und die vierte beispielhafte Fahrzeuganwendung 600 gleichzeitig aktiviert werden können, weil kein Konflikt auftreten wird.
Nun ist Bezug nehmend auf 12 eine beispielhafte Ablaufdarstellung eines Verfahrens 1200 zum Bestimmen eines Konflikts zwischen zwei oder mehr Fahrzeuganwendungen basierend auf einem Tabellensatz gemäß einigen Ausführungsbeispielen dargestellt.
In Schritt 1201 wird eine Anforderung zum Installieren einer Fahrzeuganwendung empfangen.
In Schritt 1202 wird eine Bestimmung darüber getroffen, ob eine Konflikttabelle in der Fahrzeuganwendung auf eine Weise vorhanden ist, die mit dem Konfliktprotokoll konform ist. Wenn keine Konflikttabelle vorhanden ist, wird die Anforderung in Schritt 1204 zurückgewiesen. Wenn eine Konflikttabelle vorhanden ist, fährt das Verfahren 1200 zu Schritt 1203 fort.
In Schritt 1203 wird die Anforderung zum Installieren der Fahrzeuganwendung akzeptiert.
In Schritt 1205 wird die Konflikttabelle für die Fahrzeuganwendung abgerufen und in einem nicht-transitorischen Speicher gespeichert.
In Schritt 1207 wird die Konflikttabelle mit einer oder mehreren anderen Konflikttabellen zusammengeführt, um zumindest einen Tabellensatz zu bilden.
In Schritt 1209 wird eine Anforderung zum Aktivieren der Fahrzeuganwendung empfangen. Nun ist die Fahrzeuganwendung eine ausstehende Anwendung.
In Schritt 1211 wird eine Bestimmung darüber getroffen, ob ein Konflikt zwischen der Fahrzeuganwendung und einer oder mehreren anderen Fahrzeuganwendungen, die bereits aktiv sind, vorliegt. Wenn kein Konflikt vorliegt, wird anschließend die Fahrzeuganwendung in Schritt 1213 aktiviert, und ein Zugriff auf die Ressourcen, die erforderlich sind, um deren Funktionalität bereitzustellen, wird zugelassen. Wenn ein Konflikt vorhanden ist, wird anschließend der Konflikt durch das Verfahren 1200 durch Fortfahren zu Schritt 1212 abgemildert.
In Schritt 1212 wird die Fahrzeuganwendung entweder nicht aktiviert, oder die Fahrzeuganwendung wird aktiviert, jedoch wird ein Zugriff auf die Ressourcen, die erforderlich sind, um deren Funktionalität bereitzustellen, nicht zugelassen.
Nun ist Bezug nehmend auf 13 eine Blockdarstellung dargestellt, die ein Beispiel eines Prozessablaufs 1300 zum Bestimmen, ob eine erste beispielhafte Fahrzeuganwendung 300 zu aktivieren ist, gemäß einigen Ausführungsbeispielen veranschaulicht. Die erste beispielhafte Fahrzeuganwendung wird zu einem sich in einer Warteschlange befindlichen Anwendungssatz 1301 hinzugefügt, der Fahrzeuganwendungen umfasst, die noch nicht aktiviert sind, deren Aktivierung jedoch angefordert wurde. Das Konfliktsystem 199 erzeugt einen Tabellensatz, der die Konflikttabellen 399, 499, 599, 699 umfasst, und bestimmt basierend auf diesem Tabellensatz, ob die erste beispielhafte Fahrzeuganwendung 300 zu aktivieren ist, was dazu führen würde, dass die erste beispielhafte Fahrzeuganwendung zu dem aktivierten Anwendungssatz 1302 hinzugefügt wird.
In der vorstehenden Beschreibung wurden zum Zweck der Erklärung zahlreiche spezifische Details dargelegt, um ein volles Verständnis der Spezifikation bereitzustellen. Es wird jedoch durch den Fachmann anerkannt, dass die Offenbarung ohne diese spezifischen Details praktiziert werden kann. In manchen Fällen sind Strukturen und Einrichtungen in Blockdiagrammform gezeigt, um eine Unklarheit der Beschreibung zu vermeiden. Zum Beispiel können die vorliegenden Ausführungsbeispiele, die vorstehend beschrieben sind, hauptsächlich mit Bezug auf Benutzerschnittstellen und bestimmte Hardware beschrieben werden. Jedoch können die vorliegenden Ausführungsbeispiele auf irgendeine Art eines Computersystems, das Daten und Anweisungen empfangen kann, und irgendeine periphere Einrichtung, die Dienste bereitstellt, angewendet werden.
Eine Bezugnahme in der Spezifikation auf „manche Ausführungsbeispiele“ oder „manche Fälle“ bedeutet, dass ein bestimmtes Merkmal, Struktur oder Charakteristik, die in Verbindung mit Ausführungsbeispielen oder Fällen beschrieben ist, in zumindest einem Ausführungsbeispiel der Erfindung enthalten sein kann. Das Erscheinen des Ausdrucks „in manchen Ausführungsbeispielen“ an verschiedenen Stellen in der Spezifikation betrifft nicht notweniger Weise die gleichen Ausführungsbeispiele.
Manche Abschnitte der detaillierten Beschreibungen, die folgen, sind hinsichtlich des Algorithmus und symbolischen Darstellungen von Operationen bezüglich Datenbits innerhalb eines Computerspeichers präsentiert. Diese algorithmischen Beschreibungen und Darstellungen sind die Mittel, die durch den Fachmann in dem Bereich der Datenverarbeitung verwendet werden, um die Substanz ihrer Arbeit den anderen Fachmännern darzulegen. Ein Algorithmus wird hier und im Allgemeinen als eine in sich stimmige Abfolge von Schritten betrachtet, die zu einem gewünschten Ergebnis führt. Die Schritte sind die, die eine physikalische Manipulation von physikalischen Größen erfordert. Üblicherweise, obwohl es nicht notwendig ist, nehmen diese Größen die Form von elektrischen oder magnetischen Signalen an, die dazu in der Lage sind, gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert zu werden. Es hat sich zeitweise als komfortabel erwiesen, prinzipiell aus Gründen der üblichen Verwendung, auf diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Zahlen oder Ähnliches zu verweisen.
Es sollte jedoch berücksichtigt werden, dass all diese und ähnliche Ausdrücke mit geeigneten physikalischen Größen zu verknüpfen sind und lediglich angenehme Bezeichnungen sind, die auf diese Größen angewendet werden. Solange es nicht anderweitig dargelegt ist, wie von der folgenden Diskussion offensichtlich ist, wird anerkannt, dass in der gesamten Beschreibung Diskussionen unter Verwendung der Ausdrücke, die „Verarbeiten“ oder „Rechnen“ oder „Berechnen“ oder „Bestimmen“ oder „Anzeigen“ oder Ähnliches umfassen, auf die Aktion und Prozesse eines Computersystems oder einer ähnlichen elektronischen Rechnereinrichtung Bezug nehmen, die Daten manipuliert und transformiert, die als physikalische (elektronische) Größen innerhalb des Computersystemregisters und -speichers dargestellt sind, in andere Daten, die auf ähnliche Weise als physikalische Größen innerhalb des Computersystemspeichers oder -registers dargestellt sind, oder andere solche Informationsspeicher, Übertragung oder Anzeigeeinrichtungen.
Die vorliegenden Ausführungsbeispiele der Spezifikation können sich ebenso auf eine Vorrichtung zum Durchführen der Operationen hierin beziehen. Diese Vorrichtung kann für den erforderlichen Zweck speziell konstruiert sein oder kann ein Allzweckcomputer sein, der selektiv aktiviert und durch ein Computerprogramm, das in dem Computer gespeichert ist, rekonfiguriert wird. Solch ein Computerprogramm kann in einem computerlesbaren Speichermedium aufgezeichnet werden, das umfasst, aber nicht beschränkt ist auf, irgendeine Art einer Platte, inklusive Disketten, optischen Disketten, CD-ROMs und magnetischen Platten, Festwertspeichern (ROMs), Direktzugriffspeichern (RAMs), EPROMs, EEPROMs, magnetische oder optische Karten, Flashspeicher inklusive USB-Sticks mit einem nichtflüchtigen Speicher, oder irgendeine andere Art von Medien, die zum Speichern von elektronischen Anweisungen geeignet sind, die jeweils mit einem Computersystembus gekoppelt sind.
Die Spezifikation kann die Form von manchen ganzheitlichen Hardwareausführungsbeispielen, manchen ganzheitlichen Softwareausführungsbeispielen oder manchen Ausführungsbeispielen, die sowohl Hardware als auch Softwareelemente umfassen, annehmen. In solchen bevorzugten Ausführungsbeispielen wird die Spezifikation in Software implementiert, die zum Beispiel umfasst aber nicht beschränkt ist auf, Firmware, Betriebssoftware (resident software), Microcode usw.
Des Weiteren kann die Beschreibung die Form eines Computerprogrammprodukts annehmen, das von einem computerverwendbaren oder computerlesbaren Medium zugreifbar ist, das einen Programmcode bereitstellt zur Verwendung durch oder in Verbindung mit einem Computer oder irgendeinem Anweisungsausführungssystem. Zum Zweck dieser Beschreibung kann ein computerverwendbares oder computerlesbares Medium irgendeine Vorrichtung sein, die das Programm speichern, kommunizieren, propagieren oder transportieren kann, zur Verwendung durch oder in Verbindung mit dem Anweisungsausführungssystem, der Vorrichtung oder Einrichtung.
Ein Datenverarbeitungssystem, das zum Speichern oder Ausführen von Programmcode geeignet ist, wird zumindest einem Prozessor, der direkt oder indirekt mit Speicherelementen durch einen Systembus verbunden ist, umfassen. Die Speicherelemente können einen lokalen Speicher umfassen, der während einer tatsächlichen Ausführung des Programmcodes eingesetzt wird, einen Massenspeicher und Cache-Speicher, die eine vorübergehende Speicherung von zumindest gewissen Programmcodes bereitstellen, um die Anzahl zu reduzieren, wie oft der Code von dem Massenspeicher während der Ausführung abgerufen werden muss.
Eingabe-/Ausgabeeinrichtungen oder I/O-Einrichtungen (inklusive aber nicht beschränkend auf Tastaturen, Anzeigen, Zeigereinrichtungen usw.) können mit dem System entweder direkt oder unter Verwendung von I/O-Steuerungen gekoppelt sein.
Netzwerkadapter können ebenso mit dem System gekoppelt sein, um dem Datenverarbeitungssystem zu ermöglichen, mit anderen Datenverarbeitungssystemen oder entfernten Druckern oder Speichereinrichtungen durch dazwischenliegende private oder öffentliche Netzwerke gekoppelt zu werden. Modems, ein Kabelmodem und Ethernetkarten sind nur ein paar der momentan verfügbaren Arten von Netzwerkadaptern.
Schließlich sind die hierin präsentierten Algorithmen und Anzeigen nicht inhärent auf irgendeinen bestimmten Computer oder irgendeine Vorrichtung bezogen. Verschiedene Mehrzwecksysteme können mit Programmen gemäß den hierin beschriebenen Lehren verwendet werden, oder es kann sich als vorteilhaft erweisen, spezialisierte Vorrichtungen zum Durchführen der erforderlichen Verfahrensschritte zu konstruieren. Die erforderliche Struktur für eine Vielzahl dieser Systeme wird von der nachstehenden bzw. vorstehenden Beschreibung in Erscheinung treten. Zusätzlich ist die Spezifikation nicht mit Bezug auf irgendeine bestimmte Programmiersprache beschrieben. Es ist anzuerkennen, dass eine Vielzahl von Programmiersprachen verwendet werden kann, um die Lehren der hierin beschriebenen Spezifikation zu implementieren.
Die vorgehende Beschreibung von Ausführungsbeispielen der Spezifikation wurde zum Zweck der Darstellung und Beschreibung präsentiert. Diese ist nicht dazu gedacht, erschöpfend zu sein oder die Spezifikation auf die präzise offenbarte Form zu beschränken. Viele Modifikationen und Variationen sind im Lichte der vorstehenden Lehre möglich. Es ist gedacht, dass der Umfang der Offenbarung nicht durch die detaillierte Beschreibung beschränkt ist, sondern durch die Ansprüche dieser Anmeldung. Wie durch den Fachmann verstanden wird, kann die Spezifikation auf andere spezifische Formen verkörpert werden, ohne sich vom Geist oder essentiellen Charakteristika von dieser zu entfernen. Auf ähnliche Weise sind die bestimmte Namensgebung und Aufteilung der Module, Routinen, Merkmale, Attribute, Methoden und andere Aspekte nicht zwingend oder signifikant, und die Mechanismen, die die Spezifikation oder deren Merkmale implementieren, können unterschiedliche Namen, Aufteilungen oder Formate aufweisen. Des Weiteren, wie für den Fachmann offensichtlich ist, können die Module, Routinen, Merkmale, Attribute, Methoden und andere Aspekte der Offenbarung als Software, Hardware, Firmware oder irgendeine Kombination von diesen dreien implementiert werden. Ebenso, wo auch immer eine Komponente, wie zum Beispiel ein Modul der Spezifikation als Software implementiert ist, kann die Komponente als ein eigenständiges Programm, als ein Teil eines größeren Programms, als eine Vielzahl von separaten Programmen, als eine statische oder dynamisch verlinkte Bibliothek, als ein Kernel-ladbares Modul, als ein Einrichtungstreiber, oder auf irgendeine andere bekannte Weise, die dem Fachmann für Computerprogrammierung jetzt oder in der Zukunft bekannt ist, verkörpert werden. Zusätzlich ist die Offenbarung in keiner Weise auf ein Ausführungsbeispiel in irgendeiner spezifischen Programmiersprache beschränkt, oder auf irgendein spezifisches Betriebssystem oder eine spezifische Umgebung. Dementsprechend ist die Offenbarung dazu gedacht, den Umfang der Spezifikation darzustellen und nicht zu beschränken, welcher in den folgenden Ansprüchen dargelegt ist.
Die Offenbarung umfasst Ausführungsbeispiele zum Bereitstellen einer Konfliktbestimmung und Abschwächung bezüglich Fahrzeuganwendungen. Ein Verfahren gemäß einigen Ausführungsbeispielen umfasst ein Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs. Das Verfahren umfasst Abrufen einer ersten Konflikttabelle von der Fahrzeuganwendung. Das Verfahren umfasst ein Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere in dem fahrzeuginternen Fahrzeugcomputer installierte Fahrzeuganwendungen umfasst. Das Verfahren umfasst ein Analysieren des Tabellensatzes, um zu identifizieren, ob ein Aktivieren der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen erzeugen wird. Das Verfahren umfasst ein Bestimmen zum Aktivieren der Fahrzeuganwendung basierend darauf, dass der Konflikt nicht identifiziert wird.
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 14/471387 [0039]
US 14471387 [0040]

Claims

System, mit: einem nicht-transitorischen Speicher, der eine Fahrzeuganwendung speichert, die digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch einen fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft.
Verfahren, mit: Empfangen einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs; und Ablehnen der Anforderung als Antwort auf eine Bestimmung, dass die Fahrzeuganwendung keine digitalen Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft.
Verfahren, mit: Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs; Empfangen einer ersten Konflikttabelle von der Fahrzeuganwendung; Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere in dem fahrzeuginternen Fahrzeugcomputer installierte Fahrzeuganwendungen umfasst; Analysieren des Tabellensatzes, um zu identifizieren, ob ein Aktivieren der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen erzeugen wird; und Bestimmen, die Fahrzeuganwendung zu aktivieren, basierend darauf, dass der Konflikt nicht identifiziert wird.
Verfahren gemäß Anspruch 3, wobei die erste Konflikttabelle digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft.
Verfahren gemäß einem der Ansprüche 1 bis 4, wobei das Fahrzeug ein autonomes Fahrzeug ist.
Verfahren gemäß einem der Ansprüche 1 bis 4, wobei das Fahrzeug ein hochgradig autonomes Fahrzeug ist.
Verfahren gemäß einem der Ansprüche 1 bis 6, wobei die Fahrzeuganwendung ein fortgeschrittenes Fahrerassistenzsystem ist.
Verfahren gemäß einem der Ansprüche 1 bis 7, wobei der fahrzeuginterne Fahrzeugcomputer eine elektronische Steuerungseinheit ist.
Computerprogrammprodukt, mit einem nicht-transitorischen Speicher eines Fahrzeugs, der einen Computercode speichert, der funktionsfähig ist, wenn dieser durch einen fahrzeuginternen Fahrzeugcomputer des Fahrzeugs ausgeführt wird, um den fahrzeuginternen Fahrzeugcomputer zu bewirken, Schritte auszuführen, die aufweisen: Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs; Abrufen einer ersten Konflikttabelle von der Fahrzeuganwendung; Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere in dem fahrzeuginternen Fahrzeugcomputer installierte Fahrzeuganwendungen umfasst; Analysieren des Tabellensatzes, um zu identifizieren, ob ein Aktivieren der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen erzeugen wird; und Bestimmen, die Fahrzeuganwendung zu aktivieren, basierend darauf, dass der Konflikt nicht identifiziert wird.
Computerprogrammprodukt gemäß Anspruch 9, wobei die erste Konflikttabelle digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft.
Computerprogrammprodukt gemäß Anspruch 9 oder 10, wobei das Fahrzeug ein autonomes Fahrzeug ist.
Computerprogrammprodukt gemäß Anspruch 9 oder 10, wobei das Fahrzeug ein hochgradig autonomes Fahrzeug ist.
Computerprogrammprodukt gemäß einem der Ansprüche 9 bis 12, wobei die Fahrzeuganwendung ein fortschrittliches Fahrerassistenzsystem ist.
Computerprogrammprodukt gemäß einem der Ansprüche 9 bis 13, wobei der fahrzeuginterne Fahrzeugcomputer eine elektronische Steuerungseinheit ist.
System eines Fahrzeugs mit einem Prozessor, der kommunikationsfähig mit einem nicht-transitorischen Speicher gekoppelt ist, der einen computerausführbaren Code speichert, der, wenn dieser durch den Prozessor ausgeführt wird, betriebsbereit ist, um den Prozessor zu bewirken, Schritte auszuführen, die aufweisen: Akzeptieren einer Anforderung zum Installieren einer Fahrzeuganwendung in einem fahrzeuginternen Fahrzeugcomputer eines Fahrzeugs; Abrufen einer ersten Konflikttabelle von der Fahrzeuganwendung; Zusammenführen der ersten Konflikttabelle mit einem Tabellensatz, der eine oder mehrere zweite Konflikttabellen für andere in dem fahrzeuginternen Fahrzeugcomputer installierte Fahrzeuganwendungen umfasst; Analysieren des Tabellensatzes, um zu identifizieren, ob ein Aktivieren der Fahrzeuganwendung einen Konflikt zwischen der Fahrzeuganwendung und mindestens einer der anderen Fahrzeuganwendungen erzeugen wird; und Bestimmen, die Fahrzeuganwendung zu aktivieren, basierend darauf, dass der Konflikt nicht identifiziert wird.
System gemäß Anspruch 15, wobei die erste Konflikttabelle digitale Daten umfasst, die beschreiben: einen fahrzeugbezogenen Kontext, wenn die Fahrzeuganwendung durch den fahrzeuginternen Fahrzeugcomputer verwendbar ist; eine erste Ressourcenverwendung der Fahrzeuganwendung während eines ersten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext zutrifft; und eine zweite Ressourcenverwendung der Fahrzeuganwendung während eines zweiten Satzes von Zeiten, wenn der fahrzeugbezogene Kontext nicht zutrifft.
System gemäß Anspruch 15 oder 16, wobei das Fahrzeug ein autonomes Fahrzeug ist.
System gemäß Anspruch 15 oder 16, wobei das Fahrzeug ein hochautonomes Fahrzeug ist.
System gemäß einem der Ansprüche 15 bis 18, wobei die Fahrzeuganwendung ein fortschrittliches Fahrerassistenzsystem ist.
System gemäß einem der Ansprüche 15 bis 19, wobei der fahrzeuginterne Fahrzeugcomputer eine elektronische Steuerungseinheit ist.