DE112022002947T5

DE112022002947T5 - Fahrzeugsteuerungsvorrichtung, fahrzeugsteuerungsprogramm und fahrzeugsteuerungssystem

Info

Publication number: DE112022002947T5
Application number: DE112022002947.1T
Authority: DE
Inventors: Hideyuki Yamaguchi; Satoshi Niwa
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2021-06-07
Filing date: 2022-06-06
Publication date: 2024-04-25
Also published as: JPWO2022260010A1; CN117425587A; US20240101049A1; WO2022260010A1; GB2621753A

Abstract

Eine Fahrzeugsteuerungsvorrichtung (10, 20, 30, 40) weist auf: mindestens eine erste Befehlseinheit (15A, 15B, 25A, 25B), die konfiguriert ist, um einen ersten Befehl auszugeben, bei dem es sich um einen Befehl handelt, der mehrere Schnittstellen (19A, 19B, 19C, 29A, 29B) des Steuerungsprogramms nicht spezifiziert; mehrere Ausgabeeinheiten (18A, 18B, 18C, 28A, 28B); und mindestens eine zweite Befehlseinheit, die konfiguriert ist, um eine Ausgabeeinheit zum Übermitteln eines Befehls aus den mehreren Ausgabeeinheiten auf der Grundlage des ersten Befehls auszuwählen und einen zweiten Befehl an die Schnittstelle zu übermitteln (17, 27). Jede der mehreren Ausgabeeinheiten ist eine Ausgabeeinheit, die konfiguriert ist, um den zweiten Befehl an eine entsprechende Schnittstelle unter den mehreren Schnittstellen zu übermitteln.

Description

QUERVERWEIS AUF IN BEZIEHUNG STEHENDE ANMELDUNG
Diese internationale Anmeldung beansprucht die Priorität der am 7. Juni 2021 beim japanischen Patentamt eingereichten japanischen Patentanmeldung Nr. 2021-095279 , auf deren Offenbarung hiermit vollinhaltlich Bezug genommen ist.
TECHNISCHES GEBIET
Die vorliegende Offenbarung bezieht sich auf eine Fahrzeugsteuerungsvorrichtung, ein Fahrzeugsteuerungsprogramm und ein Fahrzeugsteuerungssystem zur Steuerung eines gesteuerten Ziels.
STAND DER TECHNIK
Patentdokument 1, das nachfolgend beschrieben ist, offenbart eine Konfiguration, in der ein Fahrzeug mit einem als Adapter bzw. Anpasser bezeichneten Programm zur Anpassung von Befehlen aus einer Anwendung an ein Steuerungsprogramm ausgerüstet ist. Der Adapter hat eine Funktion zum Hinzufügen oder Ändern einer Anwendung, die einen Dienst bereitstellt, und das Steuerungsprogramm hat eine Funktion zur Steuerung eines gesteuerten Ziels, wie z. B. einer Sprachsteuerungsvorrichtung.
STAND-DER-TECHNIK-LITERATUR
PATENTLITERATUR
Patentdokument 1: JP 2017 - 220 220 A
KURZDARSTELLUNG DER ERFINDUNG
Als Ergebnis einer detaillierten Untersuchung durch den Erfinder wurde festgestellt, dass die Technologie von Patentdokument 1 eine Schwierigkeit dahingehend aufweist, dass eine breite Palette von Programmen geändert werden muss, da nicht nur der Adapter, sondern auch das Steuerungsprogramm geändert werden muss, wenn Änderungen wie Hinzufügen oder Aktualisieren einer Anwendung vorgenommen werden. Dies liegt daran, dass zur Zeit einer Änderung einer Anwendung, wenn mehrere widersprüchliche Befehle in das Steuerungsprogramm eingegeben werden, eine Störung bzw. Fehlfunktion in Operationen des Steuerungsprogramms auftreten kann.
Es ist Aufgabe der vorliegenden Offenbarung, eine Technologie bereitzustellen, die in der Lage ist, einen Bereich von Programmen einzugrenzen, deren Modifikation erforderlich ist, wenn eine Anwendung in einer Fahrzeugsteuerungsvorrichtung, einem Fahrzeugsteuerungsprogramm und einem Fahrzeugsteuerungssystem, die konfiguriert sind, um ein gesteuertes Ziel zu steuern, geändert wird.
Ein Aspekt der vorliegenden Offenbarung ist eine Fahrzeugsteuerungsvorrichtung, die sich in einem Fahrzeug befindet und konfiguriert ist, um die gesteuerten Ziele zu steuern, indem sie einen Befehl an das Steuerungsprogramm zur Steuerung der gesteuerten Ziele übermittelt. Das Steuerungsprogramm enthält mehrere Schnittstellen zum Austauschen eines Parameters. Die Fahrzeugsteuerungsvorrichtung enthält mindestens eine erste Befehlseinheit, mehrere Ausgabeeinheiten und mindestens eine zweite Befehlseinheit.
Die erste Befehlseinheit ist konfiguriert, um einen ersten Befehl auszugeben, der eine Schnittstelle des Steuerungsprogramms nicht spezifiziert. Die Ausgabeeinheit ist konfiguriert, um den eingegebenen Befehl an eine entsprechende Schnittstelle auszugeben.
Die zweite Befehlseinheit ist ferner konfiguriert, um auf der Grundlage des ersten Befehls eine Ausgabe, die einen Befehl übermittelt, unter den mehreren Ausgabeeinheiten zu wählen, und jede gewählte Ausgabeeinheit zu veranlassen, einen zweiten Befehl an die entsprechende Schnittstelle zu übermitteln, wobei der zweite Befehl ein Befehl ist, der dem ersten Befehl entspricht und einen Befehl darstellt, der die ausgewählte Ausgabeeinheit veranlasst, eine Übermittlung durchzuführen. Jede der mehreren Ausgabeeinheiten ist eine Ausgabeeinheit, die konfiguriert ist, um den zweiten Befehl an eine entsprechende Schnittstelle unter den mehreren Schnittstellen zu übermitteln.
Gemäß einer solchen Konfiguration ist jede der mehreren Ausgabeeinheiten so konfiguriert, dass für jede der mehreren Schnittstellen nur eine Ausgabeeinheit den zweiten Befehl an die Schnittstelle übermittelt. Dementsprechend ist es möglich, wenn die erste Befehlseinheit, z. B. eine Anwendung, geändert wird, die Notwendigkeit zum Ändern des Steuerungsprogramms durch einfache Änderung der Konfiguration der zweiten Befehlseinheit zu eliminieren. Daher ist es möglich, die Palette von zu modifizierenden Programmen weiter einzugrenzen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 zeigt ein Blockdiagramm zur Veranschaulichung einer Hardware-Konfiguration eines Fahrzeugsteuerungssystems.
2 zeigt ein Blockdiagramm zur Veranschaulichung einer Software-Konfiguration einer ECU.
3 zeigt eine erläuternde Abbildung zur Veranschaulichung einer Verarbeitungsprozedur in einem ersten Betriebsbeispiel.
4 zeigt eine erläuternde Abbildung zur Veranschaulichung einer Verarbeitungsprozedur in einem zweiten Betriebsbeispiel.
5 zeigt eine erläuternde Abbildung zur Veranschaulichung einer Verarbeitungsprozedur in einem dritten Betriebsbeispiel.
6 zeigt eine erläuternde Abbildung zur Veranschaulichung einer Verarbeitungsprozedur in einem vierten Betriebsbeispiel.
7 zeigt eine erläuternde Abbildung zur Veranschaulichung einer Verarbeitungsprozedur in einem Referenzbeispiel.
8 zeigt eine erläuternde Abbildung zur Veranschaulichung einer Verarbeitungsprozedur in einem fünften Betriebsbeispiel.
9 zeigt eine erläuternde Abbildung zur Veranschaulichung von Zielen, an die Befehle von der Ausgabeeinheit übermittelt werden, in einer weiteren Ausführungsform.
10 zeigt ein Blockdiagramm zur Veranschaulichung eines Beispiels für die Hardware-Konfiguration eines Fahrzeugsteuerungssystems in einer weiteren Ausführungsform.
11 zeigt ein Ablaufdiagramm zur Veranschaulichung eines von einem Fahrzeugsteuerungssystem ausgeführten Basisprozesses.
12 zeigt ein Blockdiagramm zur Veranschaulichung eines Beispiels für die Hardware-Konfiguration eines Fahrzeugsteuerungssystems in noch einer weiteren Ausführungsform.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Nachstehend sind Ausführungsformen der vorliegenden Offenbarung unter Bezugnahme auf die Zeichnungen beschrieben. Es ist zu beachten, dass ECUs 10, 20, 30 und 40 in den Ausführungsformen einer Fahrzeugsteuerungsvorrichtung in der vorliegenden Offenbarung entsprechen, und Anwendungen 15A, 15B, 25A und 25B in den Ausführungsformen entsprechen einer ersten Befehlseinheit in der vorliegenden Offenbarung. Ferner entsprechen Berechnungseinheiten 17 und 27 in der Ausführungsform einer zweiten Befehlseinheit, und Ausgabeeinheiten 18 und 28 in der Ausführungsform entsprechen einer Arbitrierungseinheit in der vorliegenden Offenbarung. Darüber hinaus entsprechen Steuer-IFs 19 und 29 in der Ausführungsform einer Schnittstelle in der vorliegenden Offenbarung, und eine API-Einheit 6 in der Ausführungsform entspricht einem Fahrzeugsteuerungsprogramm in der vorliegenden Offenbarung.
(1. Erste Ausführungsform)
(1-1. Konfiguration)
Ein in 1 gezeigtes Fahrzeugsteuerungssystem 1 ist an einem Fahrzeug, z. B. einem Pkw, angebracht und enthält mehrere ECUs 10, 20, 30 und 40 (im Folgenden als 10 bis 40 bezeichnet) sowie verschiedene Controller 50, 55, 60 und 65 (im Folgenden als 50 bis 65 bezeichnet) und gesteuerte Ziele 51, 56, 61, 66 (im Folgenden als 51 bis 66 bezeichnet). Die mehreren ECUs 10 bis 40 sind konfiguriert, um die gesteuerten Ziele 51 bis 66 zu steuern. Es ist zu beachten, dass die ECU eine elektronische Steuereinheit repräsentiert.
Die verschiedenen Controller 50 bis 65 umfassen z. B. einen Verbrennungsmotor-Controller 50, einen Licht-Controller 55, einen Hupen-Controller 60 und einen Energiequellen-Controller 65. Die gesteuerten Ziele 51 bis 66 umfassen beispielsweise einen Verbrennungsmotor 51, verschiedene Lichter 56, eine Hupe 61 und einen Generator 66.
Der Verbrennungsmotor-Controller 50 hat eine Funktion zum Steuern des Verbrennungsmotors 51 durch Ansteuern von Aktuatoren wie Ventilen und Motoren im Verbrennungsmotor 51 in Übereinstimmung mit Befehlen, die von den Berechnungseinheiten 17 und 27 empfangen werden, die nachstehend noch beschrieben sind. Der Licht-Controller 55 hat eine Funktion zum Steuern der verschiedenen Lichter 56 durch Ansteuern von Aktuatoren wie Schaltern zum Ein- und Ausschalten der verschiedenen Lichter 56 in Übereinstimmung mit Befehlen von den Berechnungseinheiten 17 und 27.
Der Hupen-Controller 60 hat eine Funktion zum Steuern der Hupe 61 durch Ansteuern eines Aktuators wie eines Schalters zum Betreiben der Hupe 61 in Übereinstimmung mit Befehlen von den Berechnungseinheiten 17 und 27. Der Energiequellen-Controller 65 hat eine Funktion zum Steuern der vom Generator 66 erzeugten Energiemenge (wie beispielsweise des Erregerstroms usw.) in Übereinstimmung mit Befehlen von den Berechnungseinheiten 17 und 27.
Die mehreren ECUs 10 bis 40 enthalten einen bekannten Mikrocomputer mit CPUs 11, 21, 31 und 41 (im Folgenden als 11 bis 41 bezeichnet) und Halbleiterspeichern 12, 22, 32 und 42 (im Folgenden als Speicher 12 bis 42 bezeichnet) wie RAM, ROM und Flash-Speicher. Die mehreren ECUs 10 bis 40 enthalten Kommunikationseinheiten 13, 23, 33 und 43 (im Folgenden als 13 bis 43 bezeichnet) zur Kommunikation mit anderen ECUs 10 bis 40 und verschiedenen Controllern 50 bis 65 über die Kommunikationsleitung 5.
Verschiedene Funktionen der mehreren ECUs 10 bis 40 werden durch die CPUs 11 bis 41 realisiert, die Programme ausführen, die in einem nichtflüchtigen, materiellen Speichermedium gespeichert sind. In diesem Beispiel entsprechen die Speicher 12 bis 42 einem nichtflüchtigen, materiellen Speichermedium, in dem das Programm gespeichert ist. Ferner wird, durch Ausführen dieses Programms, ein dem Programm entsprechendes Verfahren ausgeführt. Es ist zu beachten, dass unter dem nichtflüchtigen, materiellen Speichermedium ein Speichermedium zu verstehen ist, das keine elektromagnetischen Wellen verwendet. Darüber hinaus kann die Anzahl von Mikrocomputern, die mehrere der ECUs 10 bis 40 bilden, ein oder mehrere sein.
Hier zeigt, gemäß einem Beispiel, 2 Funktionskonfigurationen der ECU 10 und der ECU 20, die durch die Programme ausführenden CPUs 11 und 21 realisiert werden. Es ist zu beachten, dass die ECUs 30 und 40 zwar nicht beschrieben sind, aber die gleichen Funktionen wie die ECU 10 und die ECU 20 aufweisen können.
Wie in 2 gezeigt, enthalten die Funktionskonfigurationen der ECU 10 und der ECU 20 mehrere Anwendungen (Applications) 15A, 15B, 25A und 25B (im Folgenden als 15 und 25 bezeichnet), die API-Einheit 6 und mehrere Steuerungsprogramme 190 und 290.
Bei den mehreren Anwendungen 15 und 25 handelt es sich um Programme zur Bereitstellung von Diensten für Fahrzeugnutzer. Die mehreren Anwendungen 15 und 25 übermitteln indirekt Befehle an die gesteuerten Ziele 51 bis 66 und betreiben die gesteuerten Ziele 51 bis 66, um dem Benutzer nützliche Funktionen bereitzustellen.
Genauer gesagt, die mehreren Anwendungen 15 und 25 sind konfiguriert, um einen ersten Befehl zu erzeugen, der die Steuer-IFs 19 und 29 für die Steuerungsprogramme 190 und 290 nicht spezifiziert. Es ist zu beachten, dass sich „Befehle“ auf Anweisungen, Befehle wie Argumente, Funktionsaufrufe usw. unter den von den Steuerungsprogrammen 190 und 290 verwendeten Daten beziehen.
Es ist zu beachten, dass die mehreren Anwendungen 15 und 25 keine Programme sind, die speziell für Fahrzeugtypen, -klassen und dergleichen entwickelt wurden, sondern Allzweckprogramme, die viele Fahrzeugtypen, -klassen und dergleichen unterstützen können. Dementsprechend können die mehreren Anwendungen 15 und 25 nicht spezifizieren, wie das Fahrzeug, in dem sie installiert sind, die gesteuerten Ziele 51 bis 66 steuert. Somit geben die Anwendungen 15 und 25 Befehle aus, die nicht die Steuerbeträge der gesteuerten Ziele 51 bis 66 spezifizieren, d. h. die von den Steuerungsprogrammen 190 und 290 verwendeten Steuer-IFs 19 und 29. Andererseits erzeugen die mehreren Anwendungen 15 und 25 gewünschte abstrakte Operations- bzw. Betriebsinhalte. Zum Beispiel umfassen die Betriebsinhalte der mehreren Anwendungen 15 und 25 nur eine Beleuchtung, nicht aber eine spezifische Bestimmung des Beleuchtungsziels.
Die mehreren Steuerungsprogramme 190 und 290 unterscheiden sich von den mehreren Anwendungen 15 und 25 und sind Programme, die speziell für Fahrzeugtypen, -klassen und dergleichen erstellt wurden. Die mehreren Steuerungsprogramme 190, 290 sind mit mehreren Steuer-IFs 19A, 19B, 29A, 29B (im Folgenden als 19, 29 bezeichnet) zum Austauschen mehrerer Befehle versehen. Die mehreren Steuer-IFs 19 und 29 dieser Ausführungsform handhaben jeweils nur einen Befehl.
Die Steuerungsprogrammen 190 und 290 sind Programme zur Steuerung der gesteuerten Ziele 51 bis 66 und berechnen z. B. Betriebsbeträge von Aktuatoren, die in den gesteuerten Zielen 51 bis 66 enthalten sind, und übermitteln Befehle einschließlich der Betriebsbeträge an die verschiedenen Controller 50 bis 65. Es ist zu beachten, dass die Steuerungsprogramme 190 und 290 in verschiedenen Controllern 50 bis 65 platziert sein können, an die Befehle ausgegeben werden.
Die API-Einheit 6 ist ein Programm, das als eine API (Application Programming Interface / Anwendungsprogrammierschnittstelle) zum Abgleichen von Befehlen, die von den mehreren Anwendungen 15 und 25 gehandhabt werden, und Befehlen, die von den mehreren Steuerungsprogrammen 190 und 290 gehandhabt werden, fungiert. Die API-Einheit 6 enthält mehrere Eingabeeinheiten 16A, 16B, 26A, 26B (im Folgenden als 16, 26 bezeichnet), mehrere Berechnungseinheiten 17, 27 und mehrere Ausgabeeinheiten 18A, 18B, 28A, 28B (im Folgenden als 18, 28 bezeichnet).
In dem Beispiel, das in dieser Ausführungsform gezeigt ist, ist die API-Einheit 6 über die mehreren ECUs 10 und 20 hinweg angeordnet. Es ist zu beachten, dass die API-Einheit 6 in einer einzelnen ECU 10 bis 40 angeordnet sein kann. Bei den mehreren Eingabeeinheiten 16 und 26 handelt es sich um Programme, die eine Funktion zum Annehmen von Befehlen von den Anwendungen 15 und 25 aufweisen.
Die mehreren Berechnungseinheiten 17 und 27 haben eine Funktion zum Wählen einer der mehreren Ausgabeeinheiten 18 und 28, um einen Befehl zu übermitteln bzw. zu senden. Mit anderen Worten, die mehreren Berechnungseinheiten 17, 27 wählen die für die Realisierung des ersten Befehls erforderlichen Ausgabeeinheiten 18, 28 aus. Ferner haben die mehreren Berechnungseinheiten 17 und 27 eine Funktion zum Kommunizieren mit den anderen ECUs 10 bis 40 und zum Erzeugen eines zweiten Befehls (oder eines Zwischenbefehls in der vorliegenden Offenbarung) in Kooperation mit den anderen ECUs 10 bis 40. Die mehreren Berechnungseinheiten 17 und 27 müssen jedoch nicht unbedingt konfiguriert sein, um den zweiten Befehl zu erzeugen, sondern können auch konfiguriert sein, um einen zweiten Befehl, der im Voraus festgelegt wurde, in Übereinstimmung mit dem ersten Befehl zu extrahieren. Außerdem haben die mehreren Berechnungseinheiten 17 und 27 eine Funktion, die ausgewählten Ausgabeeinheiten 18 und 28 zu veranlassen, den erzeugten zweiten Befehl oder den gelesenen zweiten Befehl zu übermitteln.
Die ersten Befehle, die von den Anwendungen 15 und 25 ausgegeben werden, sind Befehle, die, wie oben beschrieben, die Steuer-IFs 19 und 29 nicht spezifizieren. Demgegenüber ist der zweite Befehl ein Befehl, der dem ersten Befehl entspricht, und ein Befehl, der die Steuer-IFs 19 und 29 spezifiziert. Der zweite Befehl ist ein Befehl zum Identifizieren des gesteuerten Ziels und zur Übermittlung von Steuerinhalten an das gesteuerte Ziel.
Die mehreren Ausgabeeinheiten 18 und 28 sind für die mehreren Steuer-IFs 19 bzw. 29 vorgesehen und konfiguriert, um Eingabebefehle an die entsprechenden Steuer-IFs 19 und 29 auszugeben. D. h., die mehreren Ausgabeeinheiten 18 und 28 sind in einer Eins-zu-Eins-Beziehung zu den mehreren Steuer-IFs 19 und 29 angeordnet.
Es ist zu beachten, dass jede der mehreren Steuer-IFs 19 und 29 mehrere Befehle handhaben kann. Im nachstehenden Beispiel empfangen die Steuer-IFs 19 und 29 Befehle zur individuellen Steuerung mehrerer Arten von Lichtern jede Art von Licht. Die Ausgabeeinheiten 18 und 28 können jedoch für jeden Befehl, der von den Steuer-IFs 19 und 29 gehandhabt wird, angeordnet sein.
(1-2. Erstes Betriebsbeispiel)
Als ein erstes Betriebsbeispiel, das die obige Konfiguration verwendet, ist nachfolgend ein Prozess zum Aktivieren verschiedener Lichter 56 aufgrund des Betriebs der Anwendung 15 unter Bezugnahme auf 3 beschrieben. Die Anwendung 15A erzeugt Befehle für die verschiedenen Lichter 56 beispielsweise in Übereinstimmung mit einem Beleuchtungsstärkewert, der von einem Beleuchtungsstärkesensor (nicht dargestellt) erhalten wird.
Insbesondere erzeugt die Anwendung 15A, wie in 3 gezeigt, zunächst einen Befehl zum Einschalten des Lichts durch Ausführen eines Prozesses entsprechend der Anwendung 15A. Dieser Befehl entspricht dem ersten Befehl in der vorliegenden Offenbarung und ist ein Befehl, der die Steuer-IFs 19 und 29 nicht spezifiziert. Der erste Befehl muss beispielsweise nur einen abstrakten Befehl enthalten, z. B. „Das Licht einschalten“. Der erste Befehl muss keinen Befehl enthalten, der ein spezifisches Objekt, das zu steuern ist, spezifiziert, wie z. B. eine Spezifizierung, welches Licht einzuschalten ist, oder eine Vorrichtung, deren Betrieb zu stoppen ist, wenn ein Licht eingeschaltet wird.
Ein Befehl zum Einschalten des Lichts von der Anwendung 15A wird in die Eingabeeinheit 16A eingegeben, und die Berechnungseinheit 17 führt Berechnungen durch, die zur Realisierung des Befehls zum Einschalten des Lichts erforderlich sind. Es ist zu beachten, dass die Eingabeeinheit 16A und die Berechnungseinheit 17 in 3 als ein Element dargestellt sind.
Die Berechnungseinheit 17 führt erforderliche Berechnungen durch, wie z. B. die Auswahl der Ausgabeeinheiten 18 und 28 zur Ausgabe des Befehls, die Erzeugung des zweiten Befehls und die Veranlassung jeder ausgewählten Ausgabeeinheit 18 und 28 zur Übermittlung des zweiten Befehls an die Steuer-IF 19 und 29. Der zweite Befehl ist ein Befehl, der dem ersten Befehl entspricht, und enthält Steuerungsdetails für die gesteuerten Ziele 51 bis 66, die auf dem ersten Befehl basieren. Der Steuerungsinhalt kann hier abstrakt sein, wie z. B. die Spezifizierung eines Steuerziels, das Ein- oder Ausschalten eines spezifischen Lichts oder das Einschalten eines spezifischen Lichts mit einer vorbestimmten Helligkeit. Dies liegt daran, dass die Steuerungsprogramme 190 und 290 den spezifischen Steuerinhalt, wie z. B. die Auswahl des betriebenen Aktuators und die Bestimmung des Steuerbetrags für den Betrieb, berechnen.
Im Beispiel von 3 wählt die Berechnungseinheit 17 z. B. die Ausgabeeinheit 18A als die Ausgabeeinheit 18, 28, die den Befehl ausgibt. Anschließend werden, als ein zweiter Befehl, ein Befehl zum Ausschalten des Fernlichts, der Rückleuchte, der Umrissleuchte, der Paneel-Leuchte, des Tagfahrlichts und der Nebelschlussleuchte unter den verschiedenen Lichtern 56 und ein Befehl zum Einschalten des Abblendlichts und des Nebelscheinwerfers erzeugt. D. h., die Berechnungseinheit 17 erzeugt auf der Grundlage eines ersten Befehls mehrere zweite Befehle für die ausgewählten Ausgabeeinheiten 18 und 28.
Es ist zu beachten, dass die Berechnungseinheit 17 auch die Priorität des zweiten Befehls in den Befehl aufnehmen kann. Die Priorität wird im Voraus in Abhängigkeit von der Art des zweiten Befehls zugeordnet. So wird beispielsweise einem Befehl zum Einschalten eines Lichts im Voraus „niedrig“ zugeordnet, was einer relativ niedrigen Priorität entspricht. Es ist zu beachten, dass die Priorität z. B. „hoch“, was einer relativ hohen Priorität entspricht, „niedrig“, was einer relativ niedrigen Priorität entspricht, und „mittel“, was einer Zwischenpriorität zwischen „hoch“ und „niedrig“ entspricht, umfasst, und dass der zweite Befehl mit einer dieser Prioritäten verknüpft übermittelt wird.
Anschließend weist die Berechnungseinheit 17 die ausgewählte Ausgabeeinheit 18A an, den zweiten Befehl an die Steuer-IF 19A zu übermitteln, indem sie den zweiten Befehl an die ausgewählte Ausgabeeinheit 18A übermittelt. Die Ausgabeeinheit 18A empfängt den zweiten Befehl und übermittelt den zweiten Befehl an die Steuer-IF 19A. In diesem Fall übermittelt die Ausgabeeinheit 18A mehrere zweite Befehle zur Steuerung einer großen Anzahl von Lichter an die Steuer-IF 19A.
Es ist zu beachten, dass das Steuerungsprogramm 190 auf der Grundlage des zweiten Befehls einen spezifischen Betrag für den Aktuatorbetrieb usw. berechnet und das Berechnungsergebnis an den Licht-Controller 55 übermittelt. Ferner kann der Licht-Controller 55 die Berechnung des Betriebsbetrags und dergleichen durchführen. Der Licht-Controller 55 betreibt bzw. steuert verschiedene Lichter 56 im Ansprechen auf den Betriebsbetrag und dergleichen.
(1-3. Zweites Betriebsbeispiel)
Nachstehend ist als ein zweites Betriebsbeispiel, das die obige Konfiguration verwendet, ein Prozess zum Betreiben der verschiedenen Lichter 56 und der Hupe 61 aufgrund des Betriebs der Anwendung 15 unter Bezugnahme auf 4 beschrieben. Die Anwendung 15A in diesem Betriebsbeispiel führt den Prozess aus, wenn sie beispielsweise ein Befehl empfängt, einen Autofinder auszuführen, d. h. eine Funktion, die dem Benutzer hilft, sein eigenes Fahrzeug zu finden, während das Fahrzeug geparkt ist.
Wenn die Anwendung 15A bestimmt, dass die Funktion des Autofinders auf dem Programm ausgeführt werden soll, wie in 4 dargestellt, übermittelt die Anwendung 15A einen Befehl zur Ausführung des Autofinders an die Eingabeeinheit 16A. Der Befehl zur Ausführung des Fahrzeug- bzw. Autofinders entspricht dem ersten Befehl der vorliegenden Offenbarung.
Ein Befehl zur Ausführung des Autofinders wird in die Eingabeeinheit 16A eingegeben, und die Berechnungseinheit 17 führt Berechnungen durch, die zur Realisierung des Befehls zur Ausführung des Fahrzeugfinders erforderlich sind. Die Berechnungseinheit 17 wählt beispielsweise mehrere Ausgabeeinheiten 18A und 18B aus, wie in 4 gezeigt. Das liegt daran, dass es zwei Arten von Befehlen gibt, die den Steuer-IFs 19 und 29 entsprechen, an die die Befehle übermittelt werden sollen. Die Ausgabeeinheit 18A entspricht beispielsweise der Steuer-IF 19A für die verschiedenen Lichter 56, und die Ausgabeeinheit 18B entspricht beispielsweise der Steuer-IF 19B für die Hupe 61.
Die Berechnungseinheit 17 erzeugt als einen zweiten Befehl, der an die Ausgabeeinheit 18A zu übermitteln ist, einen Befehl zum Einschalten der Warnblinkleuchte und zum Ausschalten derselben nach einer Minute. Ferner erzeugt die Berechnungseinheit 17 eine Hupaktivierungsanfrage als einen zweiten Befehl, der an die Ausgabeeinheit 18B zu übermitteln ist. D. h., die Berechnungseinheit 17 ist konfiguriert, um mehrere Ausgabeeinheiten 18, 28 auf der Grundlage eines ersten Befehls auszuwählen und den zweiten Befehl für jede der ausgewählten Ausgabeeinheiten 18, 28 zu erzeugen.
Anschließend veranlasst die Berechnungseinheit 17 die ausgewählten Ausgabeeinheiten 18A und 18B, den zweiten Befehl zu übermitteln. Die Ausgabeeinheiten 18A und 18B empfangen den zweiten Befehl und übermitteln den zweiten Befehl an die Steuer-IF 19A. In diesem Fall übermittelt die Ausgabeeinheit 18A einen zweiten Befehl zur Steuerung der Warnblinkleuchte an die Steuer-IF 19A, und die Ausgabeeinheit 18B übermittelt den zweiten Befehl zur Steuerung der Hupe 61 an die Steuer-IF 19B.
(1-4. Drittes Betriebsbeispiel)
Nachstehend ist ein drittes Betriebsbeispiel, das die obige Konfiguration verwendet, unter Bezugnahme auf 5 beschrieben. Das dritte Betriebsbeispiel ähnelt weitgehend dem ersten Betriebsbeispiel. Der Unterschied besteht jedoch darin, dass die Berechnungseinheit 17 die Ausgabeeinheit 18B zusätzlich zur Ausgabeeinheit 18A auswählt und dass die Berechnungseinheit 17 eine Energiereservierungsanfrage als den zweiten Befehl erzeugt und an die Ausgabeeinheit 18B übermittelt.
D. h., die Berechnungseinheit 17 erzeugt einen Befehl zur Erhöhung der vom Energieerzeuger 66 erzeugten Energiemenge als einen zweiten Befehl an die Ausgabeeinheit 18B und übermittelt diesen zweiten Befehl an die Ausgabeeinheit 18B. Das Steuerungsprogramm 190 empfängt den zweiten Befehl, erzeugt einen Steuerbetrag für den Generator 66 und übermittelt einen Befehl auf der Grundlage des Steuerbetrags an den Energiequellen-Controller 65. Anschließend wird die vom Generator 66 erzeugte Energiemenge entsprechend dem Befehl sichergestellt.
(1-5. Viertes Betriebsbeispiel)
Die Berechnungseinheit 17 enthält mehrere Funktionen zur Erzeugung des zweiten Befehls. In 6 sind die mehreren Funktionen zur Erzeugung des zweiten Befehls als eine erste Berechnungseinheit 17A und zweite Berechnungseinheit 17B bezeichnet.
Die erste Berechnungseinheit 17A erzeugt als den zweiten Befehl einen Befehl zum Einschalten der Warnblinkleuchte und zum Ausschalten nach einer Minute. Ferner erzeugt die zweite Berechnungseinheit 17B als den zweiten Befehl einen Befehl zum Einschalten des Abblendlichts und zum Einschalten der Warnblinkleuchte. Diese zweiten Befehle werden an die gleiche Ausgabeeinheit 18A übermittelt, die als das Ausgabeziel ausgewählt wurde.
Hier kann die Ausgabeeinheit 18A konkurrierende Befehle, die sich überschneidende Befehle sind, oder widersprüchliche Befehle empfangen. Daher ist die Ausgabeeinheit 18A konfiguriert, um eine Arbitrierung der mehreren zweiten Befehle vorzunehmen, wenn sie die mehreren zweiten Befehle empfängt, die von den mehreren Berechnungseinheiten 17 und 27 erzeugt wurden. Die Arbitrierung bezieht sich auf einen Prozess zum Bestimmen, ob individuelle zweite Befehle angenommen werden sollen, zum Festlegen der Priorität der Verarbeitungsreihenfolge, zum Verarbeiten der Wartezeit usw., wenn die mehreren zweiten Befehle angenommen und die Verarbeitung ausgeführt wird. Die Arbitrierung kann auch ein Ignorieren der Überschneidungsverarbeitung umfassen. Es ist zu beachten, dass die Ausgabeeinheiten 18 und 28 die Arbitrierung nach Regeln durchführen, die im Voraus für jeden der mehreren zweiten Befehle, die eingegeben werden können, festgelegt wurden. Zu dieser Zeit kann die im zweiten Befehl enthaltene Prioritätsreihenfolge verwendet werden.
Die Ausgabeeinheiten 18 und 28 sind konfiguriert, um auf der Grundlage des Ergebnisses der Arbitrierung selektiv die mehreren zweiten Befehle an die Steuer-IFs 19 und 29 auszugeben. D. h., die Ausgabeeinheiten 18 und 28 können mehrere zweite Befehle auswählen und nur den ausgewählten zweiten Befehl an die Steuer-IFs 19 und 29 ausgeben.
In der Konfiguration des vierten Betriebsbeispiels ignoriert die Ausgabeeinheit 18A, als Arbitrierung, einen der Befehle zum Einschalten der Warnblinkleuchte, die von der ersten Berechnungseinheit 17A und von der zweiten Berechnungseinheit 17B empfangen wurden, und führt einen Prozess zur Annahme aller nicht-überschneidenden Befehle aus. Anschließend übermittelt die Ausgabeeinheit 18A den zweiten Befehl nach Arbitrierung an die Steuer-IF 19A.
(1-6. Sechstes Betriebsbeispiel)
In einer Konfiguration eines in 7 gezeigten Referenzbeispiels wird ein Befehl von einer Upper-Layer-Berechnungseinheit 17Z an eine Lower-Layer-Ausgabeeinheit 18Z übermittelt und wird ferner ein Befehl an eine andere Ausgabeeinheit 18Y in demselben Layer bzw. derselben Schicht übermittelt. Außerdem wird der Befehl von dieser Ausgabeeinheit 18Y an die Berechnungseinheit 17Z im Upper Layer übermittelt.
Mit anderen Worten, es besteht eine Möglichkeit, dass die Befehle zwischen der Berechnungseinheit 17Z und den Ausgabeeinheiten 18Y und 18Z in einer Schleife laufen, was zu einer Endlosschleife führt. Demgegenüber ist, in der Konfiguration des fünften Betriebsbeispiels, wie in 8 dargestellt, die Konfiguration der API-Einheit 6 hierarchisch, und Befehle werden nacheinander in einer Richtung vom Upper Layer zum Lower Layer übermittelt. Es ist zu beachten, dass nicht nur das fünfte Betriebsbeispiel, sondern auch die API-Einheit 6 des ersten bis vierten Betriebsbeispiels ähnlich hierarchisch aufgebaut ist.
Wie in 8 dargestellt, ist ein Layer nahe der Anwendung 15 der Upper Layer und ein Layer nahe dem Steuerungsprogramm 190, 290 der Lower Layer. Die API-Einheit 6 weist in der Reihenfolge vom obersten Layer aus einen Interfahrzeugsteuerungsverbundlayer (inter vehicle control composite layer) 17E, einen Fahrzeugsteuerungsinterieurverbundlayer (vehicle control interior composite layer) 17F, einen Vereinfachungslayer (simplification layer) 17G und Ausgabeeinheiten 18 und 28 auf. Darüber hinaus sind in 8 die Funktionen der Berechnungseinheit 17 weiter unterteilt, und dadurch sind der Interfahrzeugsteuerungsverbundlayer 17E, der Fahrzeugsteuerungsinterieurverbundlayer 17F und der Vereinfachungslayer 17G dargestellt. Ferner sind die Ausgabeeinheiten 18 und 28 mit einer Ausgabeeinheit 18C versehen, und die Steuer-IFs 19 und 29 sind mit einer Steuer-IF 19C versehen, die der Ausgabeeinheit 18C entspricht.
Jeder der Layer 17E, 17F und 17G enthält eine oder mehrere der in der Berechnungseinheit 17 enthaltenen Funktionen. Obwohl die Eingabeeinheiten 16 und 26 nicht abgebildet sind, befinden sie sich in einem höheren Layer als der Interfahrzeugsteuerungsverbundlayer 17E.
Der Interfahrzeugsteuerungsverbundlayer 17E ist der erste Layer, d. h. der oberste Layer in 8, und stellt eine abstrahierte API bereit, die mehrere Domänen in Bezug auf die Fahrzeugsteuerung überspannt. Wenn der Interfahrzeugsteuerungsverbundlayer 17E beispielsweise eine Anfrage von einer Anwendung unter Verwendung der abstrakten API namens „Fahrerweckung“ empfängt, um einen schläfrigen Fahrer zu wecken, hat sie eine Funktion zum Ausführen der folgenden Steuerung. Der Interfahrzeugsteuerungsverbundlayer 17E führt beispielsweise eine Steuerung der Lenkungsvibration und der Lautstärke auf „höher bzw. größer (d. h. lauter)“ und der Kaltluft der Klimaanlage auf „stärker“ (d. h. auf ein höheres Luftvolumen) aus. Mit anderen Worten, es handelt sich um eine Steuerung, die die HMI-Domäne (HMI: Human Machine Interface / Mensch-Maschine-Schnittstelle) und die Körper- bzw. Karosserie-Domäne überspannt. Darüber hinaus hat der Interfahrzeugsteuerungsverbundlayer 17E eine Funktion zum Vornehmen einer Arbitrierung, die Domänen überspannt und mit der Fahrzeugsteuerung zusammenhängt. Wenn beispielsweise eine Steuerungsanfrage zum Einschalten der Lichter oder zum Einschalten der Klimaanlage empfangen wird, wird der verbleibende Batteriestand herangezogen und darauf basierend, ob der verbleibende Batteriestand ausreichend ist, bestimmt, ob die Steuerungsanfrage ausgeführt werden kann. Mit anderen Worten, es handelt sich um eine Arbitrierung, die die Körper-Domäne und die Energiequellen-Domäne überspannt.
Der Fahrzeugsteuerungsinterieurverbundlayer 17F ist der zweite Layer in 8, d. h. der zweite Layer von dem obersten Layer, und stellt eine abstrakte API innerhalb einer Domäne der Fahrzeugsteuerung bereit. Zum Beispiel stellt er eine abstrakte API mit der Bezeichnung „Licht an im Automatikmodus“. Darüber hinaus nimmt der Fahrzeugsteuerungsinterieurverbundlayer 17F eine Arbitrierung innerhalb der Fahrzeugsteuerungsdomäne vor. Wenn zum Beispiel Anfragen nach „Licht an im Automatikmodus“ und „Überholen“ gleichzeitig auftreten, wird der Steuerungsinhalt bestimmt. Beide sind abstrakte APIs innerhalb der Körpersystemdomäne und sind eine Arbitrierung innerhalb der Körpersystemdomäne.
Der Vereinfachungslayer 17G ist der dritte Layer in 8, d. h. der dritte Layer vom obersten Layer aus, und hat eine Funktion zum Verbergen detaillierter Parameter der Fahrzeugsteuerung. Mit anderen Worten, der Vereinfachungslayer 17G ist konfiguriert, um den Steuerbetrag der Fahrzeugsteuerung oder die Reihenfolge der Fahrzeugsteuerung zu bestimmen. Beispielsweise wird ein von der abstrakten API als „Hoch/Mittel/Niedrig“ spezifizierter Parameter in einen spezifischen Steuerbetrag (z. B. einen Drehmomentwert) umgewandelt. Ferner erfolgt, wenn z. B. „Blinken für 10 Sekunden“ spezifiziert ist, eine Verarbeitung wie „EIN, AUS, Standby für 1 Sekunde“ wiederholen.
Die Ausgabeeinheiten 18 und 28 sind Layer, die auch als Basislayer bezeichnet werden und in 8 den vierten Layer darstellen, d. h. den vierten Layer vom obersten Layer. Die Ausgabeeinheiten 18 und 28 sind in Eins-zu-eins-Entsprechung mit den Steuer-IFs 19A bis 19C und 29A bis 29C zur Steuerung der Sensoren und Aktuatoren und mit den von den ECUs 141 bis 148 bereitgestellten APIs konfiguriert.
Wie in 8 dargestellt, sind die in den einzelnen Layern 17E, 17F, 17G und 18 gehandhabten Daten so bestimmt, dass sie nur in einer Richtung an den unteren Layer weitergeleitet werden und nicht an den gleichen oder höheren Layer.
In dieser Konfiguration kann, wenn beispielsweise eine neue Anwendung 15 zum Fahrzeugsteuerungssystem 1 hinzugefügt wird, der Interfahrzeugsteuerungsverbundlayer 17E (zusätzlich die Eingabeeinheit 16) hinzugefügt oder geändert werden, um mit den Layern unterhalb des Fahrzeugsteuerungsinterieurverbundlayers 17F der API-Einheit 6 kompatibel zu sein.
Mit anderen Worten, es ist möglich, die Anwendung 15 hinzuzufügen, ohne die Steuerungsprogramme 190 und 290 zu ändern, indem der von der Hinzufügung der Anwendung 15 betroffene Teil nur auf einen Teil der API-Einheit 6 beschränkt bleibt.
(1-7. Effekt)
Die oben beschriebene Ausführungsform erzielt die folgenden Effekte.
(1a) Ein Aspekt der vorliegenden Offenbarung sind die ECUs 10 bis 40, die sich im Fahrzeug befinden und konfiguriert sind, um die gesteuerten Ziele 51 bis 66 zu steuern, indem sie einen Befehl an das Steuerungsprogramm 190, 290 zur Steuerung der gesteuerten Ziele 51 bis 66 übermitteln. Die Steuerungsprogramme 190, 290 enthalten mehrere Steuer-IFs 19, 29 zum Austauschen von Befehlen. Die ECUs 10 bis 40 enthalten mindestens eine Anwendung 15, 25, mehrere Ausgabeeinheiten 18, 28 und mindestens eine Berechnungseinheit 17, 27.
Genauer gesagt, die mehreren Anwendungen 15 und 25 sind konfiguriert, um einen ersten Befehl zu erzeugen, der die Steuer-IFs 19 und 29 für die Steuerungsprogramme 190 und 290 nicht spezifiziert. Die Ausgabeeinheiten 18 und 28 sind zumindest für jeden der mehreren Steuer-IFs 19 und 29 vorgesehen und konfiguriert, um Eingangsbefehle an die entsprechenden Steuer-IFs 19 und 29 auszugeben.
Die Berechnungseinheiten 17 und 27 sind konfiguriert, um auf der Grundlage des ersten Befehls die Ausgabeeinheit 18 und 28 zur Übermittlung des Befehls unter den mehreren Ausgabeeinheiten 18 und 28 auszuwählen. Ferner erzeugen oder extrahieren die Berechnungseinheiten 17 und 27 für jede ausgewählte Ausgabeeinheit 18 und 28 den zweiten Befehl, der dem ersten Befehl entspricht und einen von der ausgewählten Ausgabeeinheit 18 und 28 zu übermittelnden Befehl darstellt. Die Berechnungseinheiten 17, 27 sind konfiguriert, um jede der ausgewählten Ausgabeeinheiten 18 und 28 zu veranlassen, den zweiten Befehl an die Steuer-IFs 19 und 29 zu übermitteln. Jede der mehreren Ausgabeeinheiten 18, 28 ist so konfiguriert, dass nur eine Ausgabeeinheit 18, 28 den zweiten Befehl an die Steuer-IF 19, 29 für jede der mehreren Steuer-IFs 19, 29 übermittelt.
Gemäß einer solchen Konfiguration sind die mehreren Ausgabeeinheiten 18, 28 für jede der mehreren Steuer-IFs 19, 29 vorgesehen. Folglich ist es, wenn die Anwendungen 15, 25 geändert werden, lediglich erforderlich, die Konfiguration der Berechnungseinheiten 17, 27 zu ändern, und nicht erforderlich, die Steuerungsprogramme 190, 290 zu ändern. Daher ist es möglich, die Palette von zu modifizierenden Programmen weiter einzugrenzen.
(1b) Gemäß einem Aspekt der vorliegenden Offenbarung ist die Hierarchiereihenfolge der Anwendungen 15, 25, der Berechnungseinheiten 17, 27 (zweite Befehlseinheit), der Ausgabeeinheiten 18, 28 die der Anwendungen 15, 25, der Berechnungseinheiten 17, 27, der Ausgabeeinheiten 18, 28. Gemäß einem Aspekt der vorliegenden Offenbarung sind Befehle konfiguriert, um in einer Richtung gemäß der Reihenfolge dieser Hierarchie übermittelt zu werden.
Gemäß einer solchen Konfiguration kann der Befehlsfluss von den Anwendungen 15, 25 zu den Steuerungsprogrammen 190, 290 unidirektional gestaltet werden. So kann verhindert werden, dass der Prozess in den Anwendungen 15, 25, den Berechnungseinheiten 17, 27 und den Ausgabeeinheiten 18, 28 zu einer Endlosschleife wird.
(1c) Gemäß einem Aspekt der vorliegenden Offenbarung sind zumindest die Berechnungseinheiten 17 und 27 konfiguriert, um den zweiten Befehl in Zusammenarbeit mit den anderen ECUs 10 bis 40 zu erzeugen, während sie mit den anderen ECUs 10 bis 40 kommunizieren. Gemäß einer solchen Konfiguration ist es, da die ECU 10 mit anderen ECUs 10 bis 40 zusammenarbeitet und Prozesse verteilt werden, möglich, die Verarbeitungslast für jede ECU 10 bis 40 zu reduzieren.
(1d) Gemäß einem Aspekt der vorliegenden Offenbarung sind die mehreren Berechnungseinheiten 17 und 27 vorgesehen. Die Ausgabeeinheiten 18, 28 (Arbitrierungseinheit) sind konfiguriert, um eine Arbitrierung zwischen den mehreren zweiten Befehlen vorzunehmen, wenn irgendeine der mehreren Ausgabeeinheiten 18, 28 die mehreren zweiten Befehle empfängt, die von den mehreren Berechnungseinheiten 17, 27 erzeugt wurden. Die Ausgabeeinheiten 18 und 28 sind konfiguriert, um auf der Grundlage des Ergebnisses der Arbitrierung selektiv die mehreren zweiten Befehle an die Steuer-IFs 19 und 29 auszugeben.
Gemäß einer solchen Konfiguration werden, wenn die mehreren zweiten Befehle in die Ausgabeeinheiten 18 und 28 eingegeben werden, die mehreren zweiten Befehle arbitriert und dann selektiv an die Steuer-IFs 19 und 29 ausgegeben. Dementsprechend ist es möglich, den zweiten Befehl zufriedenstellend auszugeben, selbst wenn die konkurrierenden zweiten Befehle in die Ausgabeeinheiten 18 und 28 eingegeben werden.
(1e) Gemäß einem Aspekt der vorliegenden Offenbarung sind die Berechnungseinheiten 17, 27 konfiguriert, um mehrere Ausgabeeinheiten 18, 28 auf der Grundlage eines ersten Befehls auszuwählen und den zweiten Befehl für jede der ausgewählten Ausgabeeinheiten 18, 28 zu erzeugen.
Gemäß einer solchen Konfiguration werden die zweiten Befehle für die mehreren Ausgabeeinheiten 18 und 28 auf der Grundlage eines ersten Befehls erzeugt, so dass es nicht notwendig ist, die mehreren ersten Befehle vorzubereiten, und es möglich ist, den ersten Befehl weiter zu abstrahieren.
(1f) Gemäß einem Aspekt der vorliegenden Offenbarung sind die Berechnungseinheiten 17 und 27 konfiguriert, um auf der Grundlage eines ersten Befehls die mehreren zweiten Befehle an die ausgewählten Ausgabeeinheiten 18 und 28 zu erzeugen. Gemäß einer solchen Konfiguration werden die mehreren zweiten Befehle für die ausgewählten Ausgabeeinheiten 18, 28 auf der Grundlage eines ersten Befehls erzeugt, so dass es nicht notwendig ist, die mehreren ersten Befehle vorzubereiten. Es ist möglich, den ersten Befehl weiter zu abstrahieren.
(2. Weitere Ausführungsformen)
Obgleich vorstehend die Ausführungsform der vorliegenden Offenbarung beschrieben ist, ist die vorliegende Offenbarung nicht auf die vorstehend beschriebene Ausführungsform beschränkt, sondern auf verschiedene Weise modifizierbar.

(2a) In der obigen Ausführungsform ist die Konfiguration beschrieben, in der die gesteuerten Ziele 51 bis 66 den Verbrennungsmotor 51, verschiedene Lichter 56, die Hupe 61 und den Generator 66 umfassen, aber die vorliegende Offenbarung ist nicht hierauf beschränkt. In einer Konfiguration mit Bremsen, Messgeräten, Audiogeräten usw. können die ECUs 10 bis 40 beispielsweise konfiguriert sein, um diese zu steuern.
(2b) In 3 usw. erzeugt und übermittelt die Berechnungseinheit 17 die mehreren zweiten Befehle an die ausgewählten Ausgabeeinheiten 18 und 28 auf der Grundlage eines ersten Befehls, wobei die Berechnungseinheit 17 die mehreren zweiten Befehle nacheinander senden bzw. übermitteln kann. Die Reihenfolge und das Timing der Übermittlung der mehreren zweiten Befehle können im Voraus festgelegt werden. Außerdem kann die Berechnungseinheit 17 mehrere zweite Befehle in einer Reihenfolge entsprechend einer voreingestellten Prioritätsreihenfolge übermitteln.
(2c) Wie in 4 gezeigt, kann die Berechnungseinheit 17, wenn sie die mehreren Ausgabeeinheiten 18A, 18B auf der Grundlage eines ersten Befehls auswählt und den zweiten Befehl an diese Ausgabeeinheiten 18A, 18B übermittelt, die mehreren zweiten Befehle in einer Reihenfolge gemäß einer voreingestellten Prioritätsreihenfolge übermitteln.
(2d) In der obigen Ausführungsform ist eine Ausgabeeinheit 18, 28 konfiguriert, um einen Befehl an eine Steuer-IF 19, 29 zu übermitteln. Die Konfiguration ist jedoch nicht hierauf beschränkt. Beispielsweise kann, wie in 8 dargestellt, eine Ausgabeeinheit 28B konfiguriert sein, um Befehle an die mehreren Steuer-IFs 29B und 29C zu übermitteln.
(2e) Insbesondere enthält die Schnittstelle in der vorliegenden Offenbarung die gesamte Konfiguration (z. B. mehrere Steuer-IFs 19 und 29), die mehrere Befehle handhaben kann, und eine Konfiguration (z. B. einen Teil der mehreren Steuer-IFs 19 und 29), die nur eine Art von Befehl handhabt.

Gemäß diesen Konfigurationen kann jede der mehreren Ausgabeeinheiten 18, 28 so konfiguriert sein, dass nur eine Ausgabeeinheit 18, 28 den zweiten Befehl an die Steuer-IF 19, 29 für jede der mehreren Steuer-IFs 19, 29 übermittelt. Die Steuer-IFs 19A bis 19C und 29A bis 29C entsprechen einer ersten Eingabeeinheit in der vorliegenden Offenbarung.
Ferner kann, bezüglich jeder der mehreren Ausgabeeinheiten 18 und 28, nur eine Ausgabeeinheit 18, 28, die den zweiten Befehl an eine Empfangseinheit übermittelt, für jede Empfangseinheit vorgesehen sein, die den von den mehreren Steuer-IFs 19 und 29 gehandhabten Befehl empfängt. Insbesondere ist nachstehend, wie in 9 gezeigt, ein Fall beschrieben, in dem die Steuer-IF 19A, die Befehle A und B handhabt, eine Empfangseinheit 19E, die den Befehl A empfängt, und eine Empfangseinheit 19F, die den Befehl B empfängt, aufweist. Die Empfangseinheiten 19E und 19F entsprechen der ersten Eingabeeinheit in der vorliegenden Offenbarung.
Wie in 9 dargestellt, ist die Empfangseinheit 19E konfiguriert, um Befehle nur von der Ausgabeeinheit 18A zu empfangen, und die Empfangseinheit 19F ist konfiguriert, um Befehle nur von der Ausgabeeinheit 18B zu empfangen. Mit anderen Worten, die Beziehung zwischen der Anzahl von Steuer-IFs 19 und 29 und der Anzahl von Ausgabeeinheiten 18 und 28 ist eins-zu-viele, aber eine Beziehung zwischen der Anzahl von Befehlen, die von den Steuer-IFs 19 und 29 gehandhabt werden (z. B. die Anzahl von Empfangseinheiten) und der Anzahl von Ausgabeeinheiten 18 und 29 ist auf einer Eins-zu-eins-Basis festgelegt.
(2-1. Erste Modifikation)
Die oben beschriebene Konfiguration ist z. B. in Form einer spezifischen Konfiguration gemäß 10 realisierbar. Eine in 10 gezeigte Fahrzeugdienst-Einheit 107 hat eine Funktion, die dem oben beschriebenen Interfahrzeugsteuerungsverbundlayer 17E entspricht, und eine Zustandsverwaltungseinheit 108 hat Funktionen, die dem oben beschriebenen Fahrzeugsteuerungsinterieurverbundlayer 17F, dem Vereinfachungslayer 17G und den Ausgabeeinheiten 18 und 28 entsprechen.
Das in 10 gezeigte Fahrzeugsteuerungssystem 100 ist meist an einem Fahrzeug montiert und enthält mehrere ECUs 110, 115, 120, 125, 130, 141 bis 148 (im Folgenden als eine große Anzahl von ECUs 110 usw. bezeichnet). Das Fahrzeugsteuerungssystem 100 kann eine Zentrale 135 außerhalb des Fahrzeugs umfassen.
Die Zentrale 135 ist als Server konfiguriert, der eine Funktion für das Fahrzeug bereitstellen kann. Beispielsweise kann die Zentrale 135 dem Fahrzeug eine Funktion in Bezug auf automatisiertes Fahren zur Verfügung stellen. Die große Anzahl von ECUs 110 und dergleichen sowie die Zentrale 135 enthalten jeweils hauptsächlich einen bekannten Mikrocomputer mit CPUs 111, 116, 121, 126, 131, 136 (im Folgenden als CPUs 111 bis 136 bezeichnet) und Halbleiterspeichern 112, 117, 122, 127, 132 und 137 (im Folgenden als Speicher 112 bis 137 bezeichnet) wie RAM, ROM und Flash-Speicher. Darüber hinaus enthalten die ECUs 141 bis 148 CPUs 141A, 142A, 143A, 144A, 145A, 146A, 147A, 148A und Speicher 141B, 142B, 143B, 144B, 145B, 146B, 147B, 148B.
Eine große Anzahl der ECUs 110 und dergleichen sowie die Zentrale 135 sind konfiguriert, um ein am Fahrzeug montiertes Steuerziel zu steuern. Das Steuerziel entspricht z. B. einem Aktuator wie einem Verbrennungsmotor, einer Bremse, einem Motor, verschiedenen Lichtern, einer Anzeigevorrichtung, einer Klimaanlage, einem Sitz, einer Hupe oder einem Energieerzeuger bzw. Generator oder einem Sensor wie einer Kamera oder einem Millimeterwellen-Radar. Es ist zu beachten, dass das Steuerziel nicht abgebildet ist.
Die gesteuerten Ziele werden individuell von den ECUs 141 bis 148 gesteuert, bei denen es sich um Betriebssteuervorrichtungen handelt. Die ECUs 141 bis 148 umfassen eine ECUF 141 mit einem Kamera-Controller 191, eine ECUG 142 mit einem Millimeterwellen-Radar-Controller 192, eine ECUH 143 mit einem Brems-Controller 193 und eine ECUI 144 mit einem Lenkungs-Controller 194. Darüber hinaus umfassen die ECUs 141 bis 148 auch eine ECUJ 145 mit einem Display-Controller 195, eine ECUK 146 mit einem Sound-Controller 196, eine ECUL 147 mit einem HVAC-Controller 198 und eine ECUM 148 mit einem Sitz-Controller 199.
Jeder der Controller 191 bis 199 enthält ein Betriebssteuerungsprogramm zum Betreiben eines Steuerziels. Der Kamera-Controller 191 erfasst ein aufgenommenes Bild einer In-Vehicle-Kamera und steuert Belichtung und dergleichen der In-Vehicle-Kamera. Der Millimeterwellen-Radar-Controller 192 steuert ein im Fahrzeug vorhandenes Millimeterwellen-Radar und erfasst ein vom Millimeterwellen-Radar erhaltenes Erfassungsergebnis.
Der Brems-Controller 193 steuert eine Bremse. Der Lenkungs-Controller 194 steuert die Lenkung. Der Display-Controller 195 steuert eine Anzeige, wie beispielsweise einen Zähler oder eine Warnleuchte. Der Sound-Controller 196 steuert einen Ton, wie beispielsweise einen Warnton und eine Stimme, die von einem Lautsprecher erzeugt werden. Ein Licht-Controller 197 steuert verschiedene am Fahrzeug montierte Lichter. Es ist zu beachten, dass der Licht-Controller 197 in der ECUE 130 enthalten ist.
Der HVAC-Controller 198 steuert eine In-Vehicle-Klimaanlage. Es ist zu beachten, dass HVAC für Heating Ventilation and Air-Conditioning (Heizung, Lüftung und Klimatisierung) steht. Der Sitz-Controller 199 steuert einen elektrisch betriebenen bzw. verstellbaren Sitz des Fahrzeugs.
Verschiedene Funktionen einer großen Anzahl von ECUs 110 und der Zentrale 135 werden von den CPUs 111 bis 131 realisiert, die ein auf einem nichtflüchtigen, materiellen Speichermedium gespeichertes Programm ausführen. In diesem Beispiel entsprechen die Speicher 112 bis 132 dem nichtflüchtigen, materiellen Speichermedium, auf dem das Programm gespeichert ist. Ferner wird, durch Ausführen dieses Programms, ein dem Programm entsprechendes Verfahren ausgeführt. Es ist zu beachten, dass unter dem nichtflüchtigen, materiellen Speichermedium ein Speichermedium zu verstehen ist, das keine elektromagnetischen Wellen verwendet. Darüber hinaus kann die Anzahl von Mikrocomputern, die eine große Anzahl der ECUs 110 und dergleichen bilden, und die Zentrale 135 ein oder mehrere sein.
Unter einer großen Anzahl von ECUs 110 und dergleichen führt eine ECUA 110 ein Programm aus, um Funktionen wie Anwendungen 161 und 162 (im Folgenden Apps 161, 162), eine Fahrzeug-API 171 und einen Bewegungssystemausrüstungs-Controller 182 zu realisieren. Eine ECUB 115 realisiert bzw. implementiert eine Funktion als eine Anwendung 163. Die Zentrale 135 realisiert eine Funktion als eine Anwendung 164.
Bei den Anwendungen 161 bis 164 handelt es sich um Programme zur Bereitstellung eines Dienstes für einen Benutzer des Fahrzeugs. Die Anwendungen 161 bis 164 übermitteln indirekt einen Befehl an das Steuerziel und bieten dem Benutzer eine nützliche Funktion, indem sie das Steuerziel betreiben. Diese Anwendungen 161 bis 164 können in der ECUA 110, der ECUB 115 oder in der Zentrale 135 installiert sein.
Genauer gesagt, die Anwendungen 161 bis 164 sind konfiguriert, um einen ersten Befehl, der ein Befehl ist, der die nachstehend noch beschriebenen Controller 191 bis 199 nicht direkt bezeichnet, für die Fahrzeug-API 171 zu erzeugen. Es ist zu beachten, dass der „Befehl“ einen Befehl wie eine Betriebsanfrage, einen Befehl wie ein Argument und einen Funktionsaufruf unter von der Fahrzeug-API 171 verwendeten Daten umfasst. Der „Befehl“ kann Prioritätsinformation enthalten, die angibt, welcher Befehl bevorzugt verarbeitet werden soll.
Die Anwendungen 161 bis 164 sind keine Programme, die speziell für Fahrzeugtypen, -klassen und dergleichen entwickelt wurden, sondern Allzweckprogramme, die viele Fahrzeugtypen, -klassen und dergleichen unterstützen können. Daher können die Anwendungen 161 bis 164 nicht spezifizieren, wie das Fahrzeug, in dem die Anwendungen installiert sind, das Steuerziel steuert. Daher geben die Anwendungen 161 bis 164 einen spezifischen Steuerbetrag des Steuerziels aus, d. h. einen Befehl, der die von der Fahrzeug-API 171 verwendeten Controller 191 bis 199 nicht bezeichnet bzw. benennt. Andererseits erzeugen die Anwendungen 161 bis 164 einen gewünschten abstrakten Betriebsinhalt. Zum Beispiel beinhaltet der von den Anwendungen 161 bis 164 angewiesene Betriebsinhalt nur das Einschalten des Lichts in einem Automatikmodus, insbesondere ohne das einzuschaltende Licht zu bestimmen.
Nachfolgend ist mindestens eine der Anwendungen 161 bis 164 auch als eine Dienstanwendung 106 bezeichnet. Ungleich den Anwendungen 161 bis 164 handelt es sich bei der Fahrzeug-API 171 um ein Programm, das speziell für einen Fahrzeugtyp, eine Fahrzeugklasse und dergleichen erstellt wurde. D. h., die Fahrzeug-API 171 ist ein Programm, das Unterschiede in Fahrzeugtyp, -klasse und dergleichen absorbiert, so dass die Anwendungen 161 bis 164 die Unterschiede in Fahrzeugtyp, -klasse und dergleichen nicht erkennen müssen. Die Fahrzeug-API 171 ist ein Programm, das als eine API fungiert, die dazu ausgelegt ist, einen Befehl anzupassen, der von den Anwendungen 161 bis 164 verwendet wird, und einen Befehl, der von der Zustandsverwaltungseinheit 108 und einer Ausrüstungsverwaltungseinheit 109 verwendet wird, die nachstehend noch beschrieben sind. Es ist zu beachten, dass API für Application Programming Interface (Anwendungsprogrammierschnittstelle) steht.
Die Fahrzeug-API 171 ist in der ECUA 110 installiert. Die Fahrzeug-API 171 empfängt Befehle von mehreren der Anwendungen 161 bis 164, die in der ECUA 110, die die Fahrzeug-API 171 ist, der ECUB 115, die eine andere ECU ist, und der Zentrale 135 installiert sind.
Nachfolgend ist mindestens eine der Fahrzeug-APIs 171 auch als Fahrzeugdiensteinheit 107 bezeichnet. Es ist zu beachten, dass die Fahrzeugdienst-Einheit 107 mehrere Fahrzeug-APIs enthalten kann. Hier realisiert die ECUC 20 eine Funktion als eine Zustandserkennungseinheit 181. Die ECUD 25 realisiert die Funktion der HMI-System-Zustandserkennungseinheit 183. Die ECUE 130 realisiert eine Funktion als ein Körpersystem-Controller 184. Im Folgenden ist mindestens eine der Einheiten Zustandserkennungseinheit 181, Bewegungssystemausrüstungs-Controller 182, HMI-System-Zustandserkennungseinheit 183 und Karosserie- bzw. Körpersystem-Controller 184 auch als die Zustandsverwaltungseinheit 108 bezeichnet. Die Zustandserkennungseinheit 181, der Bewegungssystemausrüstungs-Controller 182, die HMI-System-Zustandserkennungseinheit 183 und der Körpersystem-Controller 184 entsprechen den Domänen (Domains) der Zustandserkennung, des Bewegungssystems, des HMI-Systems bzw. des Körpersystems und sind funktionale Einheiten, die die zu den Domänen gehörenden ECUs integrieren.
Die Zustandsverwaltungseinheit 108 ist eines von Programmen zur Steuerung eines Steuerziels. Die Zustandsverwaltungseinheit 108 berechnet z. B. einen Betriebsbetrag eines Aktuators oder eines Sensors, der ein Steuerziel ist, und übermittelt einen Befehl einschließlich des Betriebsbetrags an die verschiedenen Controller 191 bis 199. D. h., die Zustandsverwaltungseinheit 108 hat eine Funktion zum Erzeugen eines zweiten Befehls, der den ersten Befehl verkörpert, wenn der abstrahierte erste Befehl eingegeben wird. Es ist zu beachten, dass die Fahrzeugdienst-Einheit 107 eine Funktion zum Erzeugen des zweiten Befehls, der den ersten Befehl verkörpert, haben kann.
Die Zustandsverwaltungseinheit 108 ist ebenso ein Programm zum Übermitteln von Daten, die von einem Sensor oder einem Aktuator erhalten werden, an die Dienstanwendung 106. Mit anderen Worten, die Zustandsverwaltungseinheit 108 führt eine Funktion der „Zustandserkennung“ und eine Funktion der „Ausrüstungssteuerung“ aus. Die Funktion der Zustandserkennung wandelt Sensordaten, die von der Ausrüstungsverwaltungseinheit 109 (jedes der nachstehend noch beschriebenen Controller 191 bis 199) erhalten werden, oder Daten, die von einem Aktuator erhalten werden, in ein für die Fahrzeugdienst-Einheit 107 geeignetes Format um und übermittelt sie an die Fahrzeugdienst-Einheit 107. Bei der Funktion der Ausrüstungssteuerung wird ein Ansteuerungsbefehl von der Fahrzeugdienst-Einheit 107 an die Ausrüstungsverwaltungseinheit 109 verteilt.
Die Zustandsverwaltungseinheit 108 kann in der gleichen ECUA 110 wie die Fahrzeug-API 171 oder in der ECUC 120, ECUD 125 oder ECUE 130, die eine andere ECU ist, installiert sein. Die Zustandserkennungseinheit 181, der Bewegungssystemausrüstungs-Controller 182, die HMI-System-Zustandserkennungseinheit 183 und der Körpersystem-Controller 184, die die Zustandsverwaltungseinheit 108 bilden, können alle in derselben ECUA 110 wie die Fahrzeug-API 171 installiert sein. Alternativ kann sie auch verteilt und in jeder ECU installiert sein, die jede Domäne steuert.
Bei der Funktion der Zustandserkennung wird eine Funktion zur Klassifizierung einzelner Sensor-Rohdaten, die durch die Ausrüstungsverwaltungseinheit 109 von dem Fahrzeugsensor erfasst werden, in Daten für jedes Erfassungsziel so realisiert, dass die Dienstanwendung 106 die Daten leicht verwenden kann. Ferner gibt es eine Funktion zum Integrieren von Daten, zum Wandeln von Daten in Information mit einem höheren Abstraktionsniveau und zum Übermitteln der Information an die Fahrzeugdienst-Einheit 107.
Beispielsweise erfasst, bei der Funktion der Zustandserkennung, jeder der Controller 191 bis 199, die die Ausrüstungsverwaltungseinheit 109 bilden, Teile von Information wie eine Fahrzeuggeschwindigkeit von 0 km/h, eine Schaltposition P und eine Abwesenheit eines Fahrers im Fahrzeug und konzentriert sich hauptsächlich darauf, dass sich das Fahrzeug in einem geparkten Zustand befindet, und zwar auf der Grundlage dieser Teile von Information. Diese Information wird über die Fahrzeugdienst-Einheit 107 an die Dienstanwendung 106 übermittelt.
So kann beispielsweise in einem Fall, in dem die Dienstanwendung 106 eine Anfrage nach einem Autofinder stellt, die Fahrzeugdienst-Einheit 107 eine Ack von einem Licht und eine Ack von einer Hupe zu einem Betriebsergebnis kombinieren und der Dienstanwendung 106 antworten. Hier ist Ack (Acknowledgement) eine Antwort auf die Steuerungsanfrage des Lichts und der Hupe. Darüber hinaus ist der Autofinder eine Funktion einer Anwendung, die dem Nutzer auf leicht verständliche Weise die Position des Fahrzeugs auf einem Parkplatz oder dergleichen mitteilt.
Bei der Funktion der Ausrüstungssteuerung wird jeder der Controller 191 bis 199 (wie beispielsweise ein Verbrennungsmotor, eine Lenkung, eine Schaltung, eine Tür, ein Fenster, eine Klimaanlage oder dergleichen) in der optimalen Ausrüstungsverwaltungseinheit 109 ausgewählt, um die Fahrzeugbetriebsanfrage von der Dienstanwendung 106 zu realisieren. Anschließend wird das Format in ein Datenformat umgewandelt, das von jedem der Controller 191 bis 199 empfangen werden kann, und die Daten werden unter Berücksichtigung der Reihenfolge der Übermittlung der Daten verteilt.
So wird beispielsweise, wenn die Fahrzeugbetriebsanfrage „Beschleunigen des Fahrzeugs mit 0,3 G bei Kurvenfahrt des Fahrzeugs nach links mit einem Radius von 200 m“ lautet, bei der Funktion der Ausrüstungssteuerung „Anfrage an den Verbrennungsmotor, 1000 Nm zu leisten, und Anfrage an die Lenkung, -0,1 rad zu leisten“ ausgegeben.
Ferner wird beispielsweise angenommen, dass die Fahrzeugbetriebsanfrage „in einen Parkzustand wechseln“ lautet. In diesem Fall werden bei der Funktion der Ausrüstungssteuerung eine „Anfrage zum Einstellen einer Schaltung auf p, eine Anfrage zum Ausschalten einer Klimaanlage, eine Anfrage zum vollständigen Schließen eines Fensters, eine Anfrage zum Verriegeln einer Tür, wenn die oben beschriebene Anfrage abgeschlossen ist und kein Insasse anwesend ist, und eine Anfrage zum Übergang in einen Parkzustand“ ausgegeben.
Die Zustandsverwaltungseinheit 108 ist in mehrere Programme für jede Art von Fahrzeugbetrieb entsprechend der Art des ersten Befehls unterteilt. Die Art des Fahrzeugbetriebs umfasst beispielsweise ein Fahrsystem in Bezug auf Wenden bzw. Kurvenfahrt, Fahren und Anhalten des Fahrzeugs, ein HMI-System in Bezug auf eine Darstellung von Information für den Benutzer, ein Karosserie- bzw. Körpersystem in Bezug auf eine Zustandsänderung des Fahrzeugkörpers und dergleichen. Wie oben beschrieben, werden in der Zustandsverwaltungseinheit 108 die Verwaltungsfunktionen 81 bis 84 je nach Art der Domäne bereitgestellt, und die Programme der Verwaltungsfunktionen werden im Speicher 122 der ECUC 120, im Speicher 127 der ECUD 125, im Speicher 132 der ECUE 130, die Domänensteuereinheiten sind, oder im Speicher 112 der ECUA 110, die eine integrierte ECU ist, gespeichert.
Mit anderen Worten, die Zustandsverwaltungseinheit 108 wird nicht für jedes Implementierungsmittel (z. B. jeden der Controller 191 bis 199 oder dergleichen) klassifiziert, das wahrscheinlich von einer Fahrzeugvariation abhängt, sondern für jeden Fahrzeugbetrieb, der wahrscheinlich von der Dienstanwendung 106 angefragt wird.
Die Zustandserkennungseinheit 181 erfasst Information vom Kamera-Controller 191 und vom Millimeterwellen-Radar-Controller 192, wandelt die Information in Information über die Positionen des Fahrzeugs und des Fußgängers um und gibt die Information an die Fahrzeugdienst-Einheit 107 aus. Der Bewegungssystemausrüstungs-Controller 182 wandelt die Betriebsanfrage des Fahrzeugs in Steuerbeträge des Brems-Controllers 193 und des Lenkungs-Controllers 194 um und gibt die Steuerbeträge aus.
Die HMI-System-Zustandserkennungseinheit 183 empfängt einen Befehl für eine Warnung, bestimmt, ob eine Benachrichtigung mit Hilfe des Display-Controllers 195 und des Sound-Controllers 196 durchgeführt werden soll, und gibt den Steuerbetrag aus. Zum Beispiel empfängt der Körpersystem-Controller 184 einen Befehl in Bezug auf die Fahrzeugumgebung, bestimmt, welcher Controller des Licht-Controllers 197, des HVAC-Controllers 198, des Sitz-Controllers 199 und dergleichen zu betreiben ist, wandelt den Befehl in einen geeigneten Befehl um und gibt den Befehl aus.
Wie oben beschrieben, ist die Architektur innerhalb des Fahrzeugnetzwerks so konfiguriert, dass der erste Layer die Ausrüstungsverwaltungseinheit 109, der zweite Layer die Zustandsverwaltungseinheit 108, der dritte Layer die Fahrzeugdiensteinheit 107 und der vierte Layer die Dienstanwendung 106 ist.
Nachstehend ist ein vom Fahrzeugsteuerungssystem 100 ausgeführter Basisprozess unter Bezugnahme auf das in 11 gezeigte Ablaufdiagramm beschrieben. Es ist zu beachten, dass die Prozessreihenfolge von Schritt S10 und Schritt S20 beliebig änderbar ist.
Die Dienstanwendung 106 übermittelt eine Betriebsanfrage (d. h. den ersten Befehl in der vorliegenden Offenbarung) an die Fahrzeugdienst-Einheit 107. Demgegenüber bestimmt die Fahrzeugdienst-Einheit 107, wie in 11 dargestellt, in Schritt S110, ob eine Betriebsanfrage von der Dienstanwendung 106 vorliegt, und wiederholt Schritt S110, bis die Betriebsanfrage erfolgt. Wenn die Betriebsanfrage erfolgt, schreitet der Prozess zu Schritt S10 voran.
Die Fahrzeugdienst-Einheit 107 führt in Schritt S10 eine Betriebsanfrageannahmebestimmung durch. Die Betriebsanfrageannahmebestimmung ist ein Prozess zum Bestimmen, ob jeder der Controller 191 bis 199 den ersten Befehl annehmen kann.
Beispielsweise interpretiert die Fahrzeugdiensteinheit 107 in Schritt S12 die abstrahierte API, führt in Schritt S14 eine Arbitrierung innerhalb der Fahrzeugsteuerung durch und bestimmt in Schritt S16, ob die Arbitrierung erfolgreich war. Wenn die Arbitrierung erfolgreich war, schreitet der Prozess zu Schritt S20 voran. Wenn die Arbitrierung nicht erfolgreich war, schreitet der Prozess zu Schritt S150 (oder Schritt S120) voran.
In Schritt S10 ist die Fahrzeugdienst-Einheit 107 konfiguriert, um zu bestimmen, ob der erste Befehl angenommen werden kann, und zwar auf der Grundlage wenigstens entweder der Fahrzeugausrüstung, des Fahrzeugzustands oder der Syntax des Befehls in dem ersten Befehl. Es ist zu beachten, dass die Fahrzeugausrüstung und der Fahrzeugzustand die Ausrüstung und den Zustand des Fahrzeugs angeben, in das das Fahrzeugsteuerungssystem 100 eingebaut ist.
In Schritt S10 bestimmt die Fahrzeugdienst-Einheit 107, ob sie eine Betriebsanfrage von der Dienstanwendung 106 annehmen kann, zum Beispiel auf der Grundlage der folgenden sechs Punkte.

<<1>> Syntax: Ob ein Fehler in der API-Syntax zu dem Programm vorliegt.
<<2>> Ausrüstungsinformation: Ob das Fahrzeug mit dem für den Betrieb erforderlichen gesteuerten Ziel ausgerüstet ist.
<<3>> Betriebsmögliches Niveau: Ob die für den Betrieb erforderliche Ausrüstung derzeit Betriebsanfragen annehmen kann.
<<4>> Authentifizierung/Autorisierung: Ob die anfragende Dienstanwendung 106 authentifiziert ist und ob sie das Recht hat, auf die Fahrzeugdiensteinheit 107 zuzugreifen.
<<5>> Abnormität in Fahrzeugdienst-Einheit 107: Ob eine Abnormität (z. B. eine Daten- oder Kommunikationsabnormität, ein Betrieb außerhalb der normalen Spezifikationen und dergleichen) in der Fahrzeugdienst-Einheit 107 aufgetreten ist.
<<6>> Cache-Status: Ob seit der Bestimmung der Zustandsverwaltungseinheit 108, dass der Befehl nicht angenommen werden konnte, eine Zeitspanne zur Ermöglichung einer Annahme des Befehls verstrichen ist.

Es ist zu beachten, dass in «3» der Status „Ausrüstung kann annehmen“ anzeigt, dass der Betriebsanfragebereich oder die Anzahl von möglichen Anfragen innerhalb einer bestimmten Periode innerhalb des Bereichs liegt. Die Anzahl von möglichen Anfragen innerhalb des Bereichs gibt jedoch die Anzahl von empfangenen Anfragen innerhalb einer vorbestimmten Zeitspanne an. Ferner wird in «3» eine Betriebsanfrage, die nicht mit dem Fahrzeugzustand übereinstimmt, abgelehnt. So wird zum Beispiel bei einer Geschwindigkeit von 100 km/h eine Anfrage zum Öffnen der Tür abgelehnt.
In «5» wird in Abhängigkeit von der Kombination der Fahrzeug-API 171 und der nicht annehmbaren Inhalte geändert, ob die nicht annehmbare Information für jede Anfragequelle zwischengespeichert wird oder ob sie unabhängig von der Anfragequelle zwischengespeichert wird. Es ist zu beachten, dass für jede Fahrzeug-API 171 in der Fahrzeugdienst-Einheit 107 Bestimmungspunkte festgelegt werden können. D. h., es kann Punkte geben, für die keine Bestimmung vorgenommen wird. Hier werden Ausrüstungsinformation des Fahrzeugs, der Authentifizierungsstatus der Dienstanwendung 106 und das Vorhandensein oder Nichtvorhandensein von Zugriffsrechten, der aktuelle Fahrzeugstatus in Bezug auf die Ausrüstung sowie Abnormitätsinformation des Fahrzeugs und beider Dienstabteilungen im Speicher 112 gespeichert. Darüber hinaus wird im Speicher 112 auch Information wie Cache-Statusinformation gespeichert, auf die sich die Fahrzeugdienst-Einheit 107 bezieht, wenn sie bestimmt, ob die Anfrage anzunehmen ist.
Wenn die Fahrzeugdienst-Einheit 107 die Arbitrierung nicht durchführen kann, übermittelt sie in Schritt S120 an die Dienstanwendung 106 den Fehler, der anzeigt, dass der erste Befehl nicht angenommen werden kann.
Wenn die Arbitrierung erfolgreich war, empfängt die Zustandsverwaltungseinheit 108 die Betriebsanfrage von der Fahrzeugdienst-Einheit 107 und führt eine Betriebsanfrage-Arbitrierung in Schritt S20 durch. Bei der Betriebsanfrage-Arbitrierung bestimmt die Zustandsverwaltungseinheit 108, ob der erste Befehl angenommen werden kann, wobei der Konflikt zwischen dem ersten Befehl und einem anderen Befehl, der sich von dem ersten Befehl und dem zweiten Befehl unterscheidet, berücksichtigt wird. Die Zustandsverwaltungseinheit 108 kann bestimmen, ob die Anfrage angenommen werden kann, wobei Konflikte mit Anfragen berücksichtigt werden, die von anderen APIs (z. B. anderen Fahrzeug-APIs) empfangen wurden, die sich von der API (z. B. der Fahrzeug-API 171) unterscheiden, die die Anfrage empfangen hat.
Beispielsweise führt die Zustandsverwaltungseinheit 108 in Schritt S22 eine Arbitrierung zwischen Fahrzeugsteuerungen durch und bestimmt in Schritt S24, ob die Arbitrierung erfolgreich war. Wenn die Arbitrierung nicht möglich ist, wird in Schritt S150 ein Fehler an die Dienstanwendung 106 übermittelt. Wenn die Arbitrierung erfolgreich war, wird in Schritt S26 die Prozessreihenfolge gesteuert und in Schritt S28 die Parameterumwandlung durchgeführt, woraufhin der Prozess zu Schritt S160 voranschreitet.
Darüber hinaus wird in Schritt S26, wenn das Licht blinken gelassen wird, ein Prozess der Wiederholung der Prozedur des Einschaltens, des Ausschaltens, des Wartens für eine Sekunde und des Einschaltens ausgeführt. Ferner wird in Schritt S28 beispielsweise, wenn die Ausgabe gesteuert wird, ein Prozess ausgeführt, um den Inhalt des Befehls nach Arbitrierung in einen Steuerbetrag wie Hoch, Mittel oder Niedrig umzuwandeln.
Auf diese Weise bezieht sich die oben beschriebene Betriebsanfrageannahmebestimmung (einschließlich der „Arbitrierung zwischen Fahrzeugsteuerungen“ in Schritt S14) auf einen Fahrzeugstatus usw. und bestimmt, ob die Betriebsanfrage angenommen werden kann, und zwar unabhängig von anderen Befehlen. Andererseits wird bei der Betriebsanfrage-Arbitrierung dieses Prozesses (einschließlich der „Arbitrierung zwischen Fahrzeugsteuerungen“ in Schritt S22) bestimmt, ob die Betriebsanfrage angenommen werden kann, wobei Konflikte mit anderen Befehlen berücksichtigt werden. Es ist zu beachten, dass dann, wenn die Zustandsverwaltungseinheit 108 die Betriebsanfrage annehmen kann, sie einen zweiten Befehl erzeugt, der den abstrahierten ersten Befehl als den Betriebsbefehl verkörpert.
In Schritt S20 bestimmt die Zustandsverwaltungseinheit 108, ob die Betriebsanfrage angenommen werden kann, zum Beispiel auf der Grundlage der folgenden fünf Punkte.

<<1>> Anfrageprioritätsarbitrierung: Ob der erste Befehl eine höhere Priorität hat als Anfragen, die auf anderen Anwendungen oder Benutzeroperationen basieren.
<<2>> Anfrageraufhebungsanfrage: Ob der Anfrager eine Aufhebung der Anfrage angefragt hat und die Anfrage bearbeitet wird.
«3» Benutzeraufhebungsanfrage: Ob eine Benutzeranfrage zur Unterbrechung des Betriebs aufgetreten ist.
<<4>> Anfrageverarbeitungslast-Überlastung: Ob das gesteuerte Ziel mehr Anfragen empfangen hat, als es verarbeiten kann.
«5» Abnormität in Zustandsverwaltungseinheit 108 / Ausrüstungsverwaltungseinheit 109: Ob eine Abnormität (z. B. Daten- oder Kommunikationsabnormität, anomaler Betrieb) in der Zustandsverwaltungseinheit 108 oder der Ausrüstungsverwaltungseinheit 109 aufgetreten ist. Es ist zu beachten, dass bei «1» die Priorität durch die Anwendung spezifiziert wird und der Betrieb auf der Grundlage der Priorität durch die Empfängerseite bestimmt wird. Die durch die Anwendung auf der Empfängerseite spezifizierte Priorität kann jedoch ignoriert werden, und der Prozess kann ausgeführt werden.

Beispielsweise bestimmt die Zustandsverwaltungseinheit 108 in einem Fall, in dem eine Anfrage zum Einschalten einer Klimaanlage und eine Anfrage zum Einschalten eines Lichts empfangen werden, dann, wenn die Spannung aufgrund des Empfangs beider Anfragen unter einen elektrisch zulässigen Schwellenwert fällt, dass der Empfang nicht durchgeführt werden kann. Darüber hinaus bestimmt die Zustandsverwaltungseinheit 108 in einem Fall, in dem eine Anfrage bezüglich der Beschleunigung und eine Anfrage bezüglich der Lenkung empfangen werden, dass die Anfrage nicht angenommen werden kann, wenn der Fahrzeugantriebssteuerungsbetrag, der beide Anfragen erfüllt, dazu führen könnte, dass das Fahrzeug von der Straße abweicht. Hier werden Prioritätsinformation für Anfragen, Information über Anfrageraufhebungen, Information über Benutzeraufhebungen und Schwellenwerte, die vom gesteuerten Ziel verarbeitet werden können (z. B. Anzahl von Anfragen, Steuerbetrag, Verarbeitungslast usw.), in dem Speicher 112 oder in den Speichern 22, 27 und 32 gespeichert. Darüber hinaus wird Information, auf die sich die Zustandsverwaltungseinheit 108 bei der Bestimmung von Annahme oder Ablehnung bezieht, wie z. B. Abnormitätsinformation von der Zustandsverwaltungseinheit 108 und der Ausrüstungsverwaltungseinheit 109, ebenfalls in dem Speicher 112 oder in den Speichern 22, 27 und 32 gespeichert.
Als nächstes gibt die Zustandsverwaltungseinheit 108 in Schritt S160 den zweiten Befehl (d. h. einen Betriebsbefehl) auf der Grundlage des ersten Befehls an jeden der Controller 191 bis 199 der Ausrüstungsverwaltungseinheit 109 aus. Nach Schritt S160 endet der in 11 dargestellte Prozess.
Jede der Steuereinheiten 191 bis 199 ist mit einem Betriebssteuerungsprogramm zum Betreiben des gesteuerten Ziels ausgerüstet, und jeder Controller 191 bis 199 der Ausrüstungsverwaltungseinheit 109, die den Betriebsbefehl empfängt, führt das Betriebssteuerungsprogramm aus. D. h., der Speicher jeder der ECUs 141 bis 148, die jeweils eine Betriebssteuerungsvorrichtung sind, speichert das Betriebssteuerungsprogramm, das jeden der Controller 191 bis 199 bildet, und das Programm wird von der CPU ausgeführt.
(2-2. Zweite Modifikation)
Die oben beschriebene Konfiguration ist beispielsweise ebenso in Form einer spezifischen Konfiguration gemäß 12 realisierbar. In diesem Beispiel wird das Fahrzeugsteuerungssystem 201 dieser Ausführungsform in ein Fahrzeug eingebaut. Das Fahrzeug kann neben einer manuellen Fahrfunktion über eine automatisierte Fahrfunktion verfügen. Bei dem Fahrzeug kann es sich um ein Hybridfahrzeug mit einem Verbrennungsmotor und einem Elektromotor als Antriebsquelle handeln. Das Fahrzeug ist nicht auf das Fahrzeug mit der automatisierten Fahrfunktion oder das Hybridfahrzeug beschränkt, sondern kann auch ein Fahrzeug sein, das nur eine manuelle Fahrfunktion hat, oder ein Fahrzeug, das nur einen Verbrennungsmotor oder nur einen Elektromotor als Antriebsquelle hat. Im Folgenden ist das Fahrzeug, das mit dem Fahrzeugsteuerungssystem 201 ausgerüstet ist, einfach als Fahrzeug bezeichnet.
Wie in 12 dargestellt, enthält das Fahrzeugsteuerungssystem 201 eine ECU 202 und mehrere ECUs 203. Die ECU 202 steuert die mehreren ECUs 203, um eine koordinierte Steuerung des gesamten Fahrzeugs zu erzielen. D. h., die ECU 202 fungiert als eine integrierte ECU.
Die ECU 203 ist für jede Domäne vorgesehen, nach Funktion im Fahrzeug unterteilt, und steuert hauptsächlich mehrere ECUs 4, die innerhalb der Domäne vorhanden sind. Beispiele für Domänen umfassen einen Antriebsstrang (Bewegungssystem), eine Karosserie bzw. einen Fahrzeugkörper und ein Chassis bzw. Fahrgestell.
Die ECU 203, die zur Antriebsstrang-Domäne gehört, ist beispielsweise mit einer ECU 204, die den Verbrennungsmotor steuert, einer ECU 204, die den Motor steuert, einer ECU 204, die die Batterie steuert, und dergleichen verbunden.
Zum Beispiel sind eine ECU 204, die eine Klimaanlage steuert, eine ECU 204, die eine Tür steuert, und dergleichen mit der ECU 203 verbunden, die zur Körper-Domäne gehört.
So sind beispielsweise eine ECU 204, die die Bremsen steuert, eine ECU 204, die die Lenkung steuert, und dergleichen mit der ECU 203 verbunden, die zur Fahrgestell-Domäne gehört.
Die ECU 203 und die ECU 204 sind elektronische Steuereinheiten, die hauptsächlich einen Mikrocomputer mit CPU, ROM, RAM und dergleichen enthalten. Die ECU 202 enthält einen Controller 211 und eine Fahrzeuginnenkommunikationseinheit 212.
Der Controller 211 ist eine elektronische Steuereinheit, die hauptsächlich einen Mikrocomputer mit einer CPU 221, einem ROM 222, einem RAM 223 und dergleichen enthält. Verschiedene Funktionen des Mikrocomputers werden durch die CPU 221 realisiert, die Programme ausführt, die auf einem nichtflüchtigen, materiellen Speichermedium gespeichert sind. In diesem Beispiel entspricht das ROM 222 einem nichtflüchtigen, materiellen Speichermedium, das Programme speichert. Ein dem Programm entsprechendes Verfahren wird durch Ausführen des Programms durchgeführt. Es ist zu beachten, dass ein Teil oder alle von der CPU 221 ausgeführten Funktionen in Hardware unter Verwendung eines oder mehrerer ICs konfiguriert sein können. Die Anzahl von Mikrocomputern, die den Controller 211 bilden, kann einer oder mehrere sein.
Die Fahrzeuginnenkommunikationseinheit 212 ist über CAN oder Ethernet^® mit den mehreren ECUs 203 verbunden und führt eine Datenkommunikation mit den mehreren ECUs 203 durch. Das Fahrzeugsteuerungssystem 201 enthält ferner eine Fahrzeugaußenkommunikationsvorrichtung 205. Die Fahrzeugaußenkommunikationsvorrichtung 205 führt eine Datenkommunikation mit einer Kommunikationsvorrichtung außerhalb des Fahrzeugs über ein Weitbereichs-Drahtloskommunikationsnetz durch. Die Fahrzeugaußenkommunikationsvorrichtung 205 ist eine elektronische Steuereinheit, die hauptsächlich einen Mikrocomputer mit CPU, ROM, RAM und dergleichen enthält. Die ECU 202 führt eine Datenkommunikation mit der Fahrzeugaußenkommunikationsvorrichtung 205 über die Fahrzeuginnenkommunikationseinheit 212 durch.
(2h) Die ECUs 10 bis 40 und die Verfahren, die in der vorliegenden Offenbarung beschrieben sind, sind durch einen dedizierten Computer realisierbar, der durch Konfigurieren eines Prozessors und eines Speichers bereitgestellt wird, programmiert, um eine oder mehrere Funktionen auszuführen, die durch ein Computerprogramm verkörpert werden. Alternativ sind die ECUs 10 bis 40 und die Verfahren, die in der vorliegenden Offenbarung beschrieben sind, durch einen dedizierten Computer realisierbar, der durch Konfigurieren eines Prozessors mit einer oder mehreren dedizierten Hardware-Logikschaltungen bereitgestellt wird. Alternativ können die ECUs 10 bis 40 und das zugehörige Verfahren, die in der vorliegenden Offenbarung beschrieben sind, durch einen oder mehrere Spezialcomputer realisiert werden, die konfiguriert sind durch eine Kombination aus einem Prozessor und einem Speicher, programmiert, um eine oder mehrere Funktionen auszuführen, und einem Prozessor, der durch eine oder mehrere Hardware-Logikschaltungen konfiguriert ist. Darüber hinaus kann das Computerprogramm auf einem computerlesbaren, nichtflüchtigen, materiellen Speichermedium als ein vom Computer auszuführender Befehl gespeichert sein. Das Verfahren zum Realisieren der Funktionen der jeweiligen Einheiten in den ECUs 10 bis 40 muss nicht notwendigerweise Software umfassen, und alle der Funktionen sind unter Verwendung einer oder mehrerer Hardware realisierbar.
(2i) Mehrere Funktionen einer Komponente in der vorstehend beschriebenen Ausführungsform sind durch mehrere Komponenten realisierbar, oder eine Funktion einer Komponente ist durch mehrere Komponenten realisierbar. Die mehreren Funktionen der mehreren Elemente sind durch ein Element realisierbar, oder eine durch mehrere Elemente realisierte Funktion ist durch ein Element realisierbar. Ein Teil der Konfiguration der obigen Ausführungsform kann wie jeweils anwendbar weggelassen werden. Darüber hinaus kann zumindest ein Teil der Konfiguration der vorstehend beschriebenen Ausführungsform zu der Konfiguration einer weiteren Ausführungsform, die vorstehend beschrieben ist, hinzugefügt oder durch diese ersetzt werden.
(2j) Zusätzlich zu den oben beschriebenen Fahrzeugsteuerungssystemen 1, 100 und 201 können eine Komponente der Fahrzeugsteuerungssysteme 1, 101, 201, wie z. B. die Fahrzeugsteuerungsvorrichtung, wie z. B. die ECUs 10 bis 40, ein Programm zum Realisieren bzw. Implementieren der Computerfunktion als die Fahrzeugsteuerungsvorrichtung, ein nichtflüchtiges, materielles Speichermedium, wie z. B. ein Halbleiterspeicher, in dem das Programm gespeichert ist, und ein Fahrzeugsteuerungsverfahren bereitgestellt werden, um die vorliegende Offenbarung zu realisieren.
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

JP 2021095279 [0001]
JP 2017 [0004]
JP 220220 A [0004]

Claims

Fahrzeugsteuerungsvorrichtung (10, 20, 30, 40), die sich in einem Fahrzeug befindet und konfiguriert ist, um ein gesteuertes Ziel (51, 56, 61, 66) zu steuern, indem sie einen Befehl an ein Steuerungsprogramm (190, 290) zur Steuerung des gesteuerten Ziels übermittelt, wobei das Steuerungsprogramm mehrere Schnittstellen (19A, 19B, 19C, 29A, 29B) zum Austauschen des Befehls enthält, wobei die Fahrzeugsteuerungsvorrichtung aufweist: - mindestens eine erste Befehlseinheit (15A, 15B, 25A, 25B), die konfiguriert ist, um einen ersten Befehl auszugeben, bei dem es sich um einen Befehl handelt, der die mehreren Schnittstellen des Steuerungsprogramms nicht spezifiziert; - mehrere Ausgabeeinheiten (18A, 18B, 18C, 28A, 28B), die konfiguriert sind, um einen empfangenen Befehl an eine entsprechende Schnittstelle auszugeben; und - mindestens eine zweite Befehlseinheit (17, 27), die konfiguriert ist, um - auf der Grundlage des ersten Befehls eine Ausgabeeinheit zum Übermitteln des Befehls unter den mehreren Ausgabeeinheiten auszuwählen, und - einen zweiten Befehl an die mehreren Schnittstellen zu übermitteln, indem sie den zweiten Befehl ausgibt, der einen Befehl darstellt, der die ausgewählte Ausgabeeinheit veranlasst, den zweiten Befehl entsprechend dem ersten Befehl zu übermitteln, wobei - jede der mehreren Ausgabeeinheiten eine Ausgabeeinheit ist, die konfiguriert ist, um den zweiten Befehl an die entsprechende Schnittstelle unter den mehreren Schnittstellen zu übermitteln.
Fahrzeugsteuerungsvorrichtung nach Anspruch 1, wobei - die erste Befehlseinheit, die zweite Befehlseinheit und die Ausgabeeinheit hierarchisch in einer Reihenfolge der ersten Befehlseinheit, der zweiten Befehlseinheit und der Ausgabeeinheit angeordnet sind, und - ein Befehl gemäß der Reihenfolge in einer Richtung übermittelt wird.
Fahrzeugsteuerungsvorrichtung nach Anspruch 1 oder 2, wobei zumindest die zweite Befehlseinheit konfiguriert ist, um den zweiten Befehl während einer Kommunikation mit einer anderen Fahrzeugsteuerungsvorrichtung in Kooperation mit der anderen Fahrzeugsteuerungsvorrichtung zu erzeugen.
Fahrzeugsteuerungsvorrichtung nach einem der Ansprüche 1 bis 3, wobei - die zweite Befehlseinheit mehrere zweite Befehlseinheiten umfasst; - die Fahrzeugsteuerungsvorrichtung ferner eine Arbitrierungseinheit (18, 28) aufweist, die konfiguriert ist, um eine Arbitrierung der mehreren zweiten Befehle vorzunehmen, wenn irgendeine der mehreren Ausgabeeinheiten die mehreren zweiten Befehlen empfängt, die von den mehreren zweiten Befehlseinheiten erzeugt wurden, und - die empfangende Ausgabeeinheit konfiguriert ist, um auf der Grundlage eines Arbitrierungsergebnisses selektiv die mehreren zweiten Befehle an die mehreren Schnittstellen auszugeben.
Fahrzeugsteuerungsvorrichtung nach einem der Ansprüche 1 bis 4, wobei die zweite Befehlseinheit konfiguriert ist, um die mehreren Ausgabeeinheiten auf der Grundlage eines ersten Befehls auszuwählen und den zweiten Befehl für jede der mehreren ausgewählten Ausgabeeinheiten zu erzeugen.
Fahrzeugsteuerungsvorrichtung nach einem der Ansprüche 1 bis 5, wobei die zweite Befehlseinheit konfiguriert ist, um die mehreren zweiten Befehle für die ausgewählte Ausgabeeinheit auf der Grundlage eines ersten Befehls zu erzeugen.
Fahrzeugsteuerungsprogramm, das von einer Fahrzeugsteuerungsvorrichtung (10, 20, 30, 40) ausgeführt wird, die sich in einem Fahrzeug befindet und konfiguriert ist, um ein gesteuertes Ziel zu steuern, indem sie einen Befehl an ein Steuerungsprogramm zur Steuerung des gesteuerten Ziels übermittelt, wobei das Fahrzeugsteuerungsprogramm konfiguriert ist, um folgende Funktionen zu realisieren: - Eingeben eines ersten Befehls, der: ein Befehl für das Steuerungsprogramm ist, das mehrere Schnittstellen (19A, 19B, 19C, 29A, 29B) zum Austauschen des Befehls aufweist; und ein Befehl ist, der die mehreren Schnittstellen nicht spezifiziert; - Veranlassen von mehreren Programmen, als mehrere Ausgabeeinheiten (18A, 18B, 18C, 28A, 28B) zu dienen, die konfiguriert sind, um einen empfangenen Befehl an eine entsprechende Schnittstelle auszugeben; - Auswählen einer Ausgabeeinheit, die einen Befehl sendet, aus den mehreren Ausgabeeinheiten auf der Grundlage des ersten Befehls; und - Veranlassen jeder ausgewählten Ausgabeeinheit, einen zweiten Befehl an die entsprechende Schnittstelle zu übermitteln, wobei der zweite Befehl ein Befehl ist, der dem ersten Befehl entspricht und einen Befehl darstellt, der die ausgewählte Ausgabeeinheit veranlasst, die Übermittlung durchzuführen.
Fahrzeugsteuerungsprogramm, das konfiguriert ist, um von einer Fahrzeugsteuerungsvorrichtung (10, 20, 30, 40) ausgeführt zu werden, wobei das Fahrzeugsteuerungsprogramm konfiguriert ist, um Funktionen auszuführen als: - eine Eingabeeinheit (16, 26), die konfiguriert ist, um einen abstrakten ersten Befehl von einer Anwendung zu empfangen; - mehrere Ausgabeeinheiten (18, 28), die konfiguriert sind, um eine Ausgabe an eine Schnittstelle eines Steuerungsprogramms zur Steuerung eines gesteuerten Ziels durchzuführen; und - eine Berechnungseinheit (17, 27), die konfiguriert ist, um die mehreren Ausgabeeinheiten auszuwählen, die zur Umsetzung des ersten Befehls erforderlich sind, und einen Zwischenbefehl an die mehreren ausgewählten Ausgabeeinheiten zu übermitteln, wobei - die mehreren Ausgabeeinheiten konfiguriert sind, um einen zweiten Befehl gemäß dem Zwischenbefehl über eine entsprechende Schnittstelle zu übermitteln, und - jede der mehreren Ausgabeeinheiten eine Ausgabeeinheit ist, die konfiguriert ist, um den zweiten Befehl an die entsprechende Schnittstelle unter den mehreren Schnittstellen zu übermitteln.
Fahrzeugsteuerungssystem (1), aufweisend: - mehrere erste Fahrzeugsteuerungsvorrichtungen (50, 55, 60, 65, 141 bis 148), die konfiguriert sind, um ein gesteuertes Ziel (51, 56, 61, 66) zu steuern, das an einem Fahrzeug angebracht ist; und - eine zweite Fahrzeugsteuerungsvorrichtung (10, 20, 30, 40, 110), die mit den mehreren ersten Fahrzeugsteuerungsvorrichtungen kommunikativ verbunden ist, wobei - die mehreren ersten Fahrzeugsteuerungsvorrichtungen aufweisen: - mehrere erste Eingabeeinheiten (19A, 19B, 19C, 29A, 29B, 19E, 19F), die konfiguriert sind, um einen von der zweiten Fahrzeugsteuerungsvorrichtung übermittelten Befehl zu empfangen; und - mehrere Controller (190, 290), die konfiguriert sind, um das gesteuerte Ziel auf der Grundlage des von der ersten Eingabeeinheit empfangenen Befehls zu steuern, und - die zweite Fahrzeugsteuerungsvorrichtung aufweist: - eine zweite Eingabeeinheit (16A, 16B, 26A, 26B), die konfiguriert ist, um einen Befehl von einer Anwendung (15A, 15B, 25A, 25B) zu empfangen; - eine Berechnungseinheit (17, 27), die konfiguriert ist, um den Befehl von der Anwendung, der von der zweiten Eingabeeinheit empfangen wird, zu verarbeiten; und - mehrere Ausgabeeinheiten (18A, 18B, 28A, 28B), die konfiguriert sind, um auf der Grundlage eines Verarbeitungsergebnisses der Berechnungseinheit einen Befehl an die mehreren ersten Fahrzeugsteuerungsvorrichtungen auszugeben, und - jede der mehreren Ausgabeeinheiten entsprechend für jede der mehreren ersten Eingabeeinheiten vorgesehen und konfiguriert ist, um einen Befehl an eine entsprechende erste Eingabeeinheit auszugeben.
Fahrzeugsteuerungssystem nach Anspruch 9, wobei die zweite Fahrzeugsteuerungsvorrichtung, als mehrere Funktionen, die von der zweiten Fahrzeugsteuerungsvorrichtung ausführbar sind, mindestens zwei der folgenden Layer aufweist: - einen ersten Layer (17E), der konfiguriert ist, um einen Befehl zu verarbeiten, der mehrere Fahrzeugsteuerungs-Domänen überspannt; - einen zweiten Layer (17F), der konfiguriert ist, um einen Befehl innerhalb einer Domäne der Fahrzeugsteuerung zu verarbeiten; - einen dritten Layer (17G), der konfiguriert ist, um einen Steuerbetrag der Fahrzeugsteuerung oder eine Reihenfolge der Fahrzeugsteuerung zu bestimmen; oder - einen vierten Layer (18A), der mehrere Ausgabeeinheiten aufweist.
Fahrzeugsteuerungssystem nach Anspruch 10, wobei der erste Layer, der zweite Layer, der dritte Layer und der vierte Layer in einer Reihenfolge des ersten Layers, des zweiten Layers, des dritten Layers und des vierten Layers hierarchisiert sind, und ein Befehl in nur einer Richtung gemäß der Reihenfolge übermittelt wird.
Fahrzeugsteuerungssystem nach einem der Ansprüche 9 bis 11, wobei die Berechnungseinheit aufweist: - eine erste Berechnungseinheit (17E, 108), die konfiguriert ist, um einen Befehl zwischen mehreren Fahrzeugsteuerungs-Domänen zu arbitrieren; - eine zweite Berechnungseinheit (17F, 107), die konfiguriert ist, um einen Befehl innerhalb einer Domäne der Fahrzeugsteuerung zu arbitrieren; und - eine dritte Berechnungseinheit (17G, 108), die konfiguriert ist, um einen Steuerbetrag oder eine Reihenfolge der Fahrzeugsteuerung zu bestimmen.
Fahrzeugsteuerungssystem nach Anspruch 12, abhängig von Anspruch 10, wobei - die zweite Berechnungseinheit in dem zweiten Layer enthalten ist, und - die zweite Berechnungseinheit mehrere zweite Berechnungseinheiten umfasst, die entsprechend für jede Domäne der Fahrzeugsteuerung vorgesehen sind.
Fahrzeugsteuerungsvorrichtung (10, 20, 30, 40, 110), die kommunikativ mit mehreren elektronischen Steuereinheiten (50, 55, 60, 65, 141 bis 148) verbunden ist, die mehrere erste Eingabeeinheiten (19A, 19B, 19C, 29A, 29B, 19E, 19F) enthalten, die konfiguriert sind, um einen Befehl zur Steuerung eines an einem Fahrzeug angebrachten gesteuerten Ziels (51, 56, 61, 66) zu empfangen, wobei die Fahrzeugsteuerungsvorrichtung aufweist: - eine zweite Eingabeeinheit (16A, 16B, 26A, 26B), die konfiguriert ist, um einen Befehl von einer Anwendung (15A, 15B, 25A, 25B) zu empfangen; - eine Berechnungseinheit (17, 27), die konfiguriert ist, um den Befehl von der Anwendung, der von der zweiten Eingabeeinheit empfangen wird, zu verarbeiten; und - mehrere Ausgabeeinheiten (18A, 18B, 28A, 28B), die konfiguriert sind, um auf der Grundlage eines Verarbeitungsergebnisses der Berechnungseinheit einen Befehl an die mehreren elektronischen Steuereinheiten auszugeben, wobei - jede der mehreren Ausgabeeinheiten entsprechend für jede der mehreren ersten Eingabeeinheiten vorgesehen und konfiguriert ist, um den Befehl an eine entsprechende erste Eingabeeinheit auszugeben.