DE102023107070A1

DE102023107070A1 - Kompatibilität von fahrzeugsoftware

Info

Publication number: DE102023107070A1
Application number: DE102023107070.3A
Authority: DE
Inventors: Karl Nathan Clark; Jason Michael Miller; John Cardillo; Vijayababu Jayaraman
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2022-04-05
Filing date: 2023-03-21
Publication date: 2023-10-05
Also published as: CN116935448A; US20230315440A1

Abstract

Es ist ein Verfolgen einer Steuerungskonfiguration bereitgestellt. Es wird eine Abfrage von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die jeweilige ECU umgesetzt werden, von jeder ECU einer Vielzahl von ECUs vorgenommen. Jeder der Merkmalscodes entspricht einer Sollmenge an ECUs, die an der Umsetzung der Funktionalität beteiligt sind. Eine Warnung wird als Reaktion darauf angegeben, dass das Abfragen eine andere Menge an ECUs, welche die Funktionalität umsetzen, als die Sollmenge zurückgibt.

Description

GEBIET DER TECHNIK
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Einrichtungen zum Verfolgen von Fahrzeugkonfigurationen über den Fahrzeuglebenszyklus.
ALLGEMEINER STAND DER TECHNIK
Um eine Software-Version einer Komponente eines Fahrzeugs zu aktualisieren, kann das Fahrzeug zu einem Händler gefahren und durch einen Techniker gewartet werden. Der Techniker kann ein System nutzen, welches die einzelnen Software-Ebenen von jeder Komponente in dem Fahrzeug sowie verfügbare Software-Aktualisierungen verfolgt. Der Techniker kann die durch das System angegebenen Software-Aktualisierungen manuell anwenden und alle Änderungen in dem System aufzeichnen.
Kabellose (over-the-air - OTA) Software-Aktualisierungen sind eine Technik, durch welche die Software eines Fahrzeugs über eine drahtlose Verbindung aktualisiert werden kann. Unter Verwendung eines eingebetteten Modems oder einer anderen drahtlosen Datenverbindung zu dem Fahrzeug ermöglichen OTA-Aktualisierungen Änderungen an der Software von elektronischen Steuereinheiten (electronic control units - ECUs) des Fahrzeugs ohne einen Wartungsbesuch.
KURZDARSTELLUNG
In einer ersten veranschaulichenden Ausführungsform ist ein System zum Verfolgen einer Steuerungskonfiguration bereitgestellt. Das System beinhaltet ECUs und ein zentrales Gateway. Das zentrale Gateway ist dazu programmiert, Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die jeweilige ECU umgesetzt werden, von jeder ECU der ECUs abzufragen, wobei jeder Merkmalscode einer Sollmenge an ECUs entspricht, die an der Umsetzung der Funktionalität beteiligt sind, und als Reaktion darauf, dass die Abfrage eine andere Menge an ECUs, welche die Funktionalität umsetzen, zurückgibt als die Sollmenge, eine Warnung anzugeben.
In einer zweiten veranschaulichenden Ausführungsform ist ein Verfahren zum Verfolgen einer Steuerungskonfiguration bereitgestellt. Es wird eine Abfrage von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die jeweilige ECU umgesetzt werden, von jeder ECU einer Vielzahl von ECUs vorgenommen. Jeder der Merkmalscodes entspricht einer Sollmenge an ECUs, die an der Umsetzung der Funktionalität beteiligt sind. Eine Warnung wird als Reaktion darauf angegeben, dass das Abfragen eine andere Menge an ECUs, welche die Funktionalität umsetzen, als die Sollmenge zurückgibt.
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein nicht transitorisches computerlesbares Medium Anweisungen zum Verfolgen einer Steuerungskonfiguration, die bei Ausführung durch ein zentrales Gateway in Kommunikation über einen oder mehrere Busse mit einer Vielzahl von ECUs das zentrale Gateway dazu veranlassen, Vorgänge durchzuführen, einschließlich zum Abfragen von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die jeweilige ECU umgesetzt werden, von jeder ECU der ECUs, wobei jeder Merkmalscode einer Sollmenge an ECUs entspricht, die an der Umsetzung der Funktionalität beteiligt sind; und Angeben einer Warnung als Reaktion darauf, dass die Abfrage eine andere Menge an ECUs, welche die Funktionalität umsetzen, zurückgibt als die Sollmenge.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 veranschaulicht ein beispielhaftes System, das ein zentrales Gateway beinhaltet, das zur Verwendung beim Verfolgen von Fahrzeugkonfigurationen über den Fahrzeuglebenszyklus konfiguriert ist;
2 veranschaulicht ein Beispiel für ein Merkmalswörterbuch des Fahrzeugs, das weitere Aspekte der Merkmalscodes veranschaulicht; und
3A veranschaulicht ein Beispiel für Merkmalscodes für eine erste Version eines Merkmals über die ECUs des Fahrzeugs;
3B veranschaulicht ein Beispiel für Merkmalscodes für eine zweite Version des Merkmals über die ECUs des Fahrzeugs;
4 veranschaulicht einen beispielhaften Prozess zum Verfolgen von Fahrzeugkonfigurationen über den Fahrzeuglebenszyklus; und
5 veranschaulicht eine beispielhafte Rechenvorrichtung zum Verfolgen von Fahrzeugkonfigurationen über den Fahrzeuglebenszyklus.

DETAILLIERTE BESCHREIBUNG
Den Anforderungen entsprechend sind in dieser Schrift detaillierte Ausführungsformen der vorliegenden Offenbarung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Offenbarung sind, die in verschiedenen und alternativen Formen umgesetzt werden kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können stark vergrößert oder verkleinert sein, um Details konkreter Komponenten zu zeigen. Daher sind in dieser Schrift offenbarte spezifische strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann den vielfältigen Einsatz des vorliegenden Ansatzes zu lehren.
Das Ausgestalten von durch Software aktualisierten Merkmalen ist in der Fahrzeugumgebung komplex, da die Funktionalität über viele Fahrzeug-ECUs verteilt sein kann. Da ECU-Software unabhängig OTA oder in einer Wartungsumgebung aktualisiert werden kann, ist es wichtig, die Kompatibilität von Fahrzeug-Software während des gesamten Lebenszyklus des Produkts sicherzustellen. Zusätzlich zu OTA-Software-Verteilungen kann es bei Fahrzeugen von Zeit zu Zeit zum Austauschen von ECUs aufgrund von Reparaturen, Aufrüstungen, Arbeiten von Heimwerkern oder anderen Situationen kommen. Wenn Händler oder Werkstätten ECUs austauschen, können sie die geeignete Software und Konfigurationsparameter installieren, um die Kompatibilität mit anderen ECUs in dem Fahrzeug sicherzustellen. Einige Reparaturen können jedoch unter Verwendung einer Hardware-kompatiblen ECU von einem Donor-Fahrzeug durchgeführt werden, ohne dass verstanden wird, dass eine Software-Inkompatibilität vorliegen könnte. Aspekte der Offenbarung betreffen einen Ansatz zur Validierung kompatibler Fahrzeugsoftware. Diese Validierung kann in einem Beispiel als Reaktion auf das Auftreten des Zündzyklus durchgeführt werden.
1 veranschaulicht ein beispielhaftes System 100, das ein zentrales Gateway 110 beinhaltet, das zur Verwendung beim Verfolgen von Fahrzeugkonfigurationen über den Fahrzeuglebenszyklus konfiguriert ist. Das zentrale Gateway 110 kann über einen oder mehrere Fahrzeugbusse 106 mit einer Vielzahl von ECUs 104 verbunden sein. Das zentrale Gateway 110 kann außerdem einen oder mehrere Diagnoseanschlüsse 108 beinhalten. Das zentrale Gateway 110 kann außerdem einen Prozessor 112, einen Arbeitsspeicher 114 und einen Datenspeicher 116 für Anwendungen und/oder Daten beinhalten. Wenngleich in 1 ein beispielhaftes System 100 gezeigt ist, sollen die beispielhaften Komponenten, wie veranschaulicht, nicht einschränkend sein. Tatsächliche kann das System 100 mehr oder weniger Komponenten aufweisen und können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden.
Das Fahrzeug 102 kann verschiedene Arten von Kraftfahrzeugen, Softroadern (crossover utility vehicle - CUV), Geländewagen (sport utility vehicle - SUV), Trucks, Wohnmobilen (recreational vehicle - RV), Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern beinhalten. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine mit Leistung versorgt werden. Als eine andere Möglichkeit kann das Fahrzeug 102 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch eine Brennkraftmaschine als auch einen oder mehrere Elektromotoren mit Leistung versorgt wird. In einem anderen Beispiel kann das Fahrzeug 102 ein reines Elektrofahrzeug sein, das ausschließlich durch Elektromotoren angetrieben wird.
Das Fahrzeug 102 kann eine Vielzahl von ECUs 104 beinhalten, die dazu konfiguriert ist, mithilfe der Fahrzeugbatterie und/oder des Fahrzeugantriebsstrangs unterschiedliche Funktionen des Fahrzeugs 102 durchzuführen und zu managen. Wie dargestellt, werden die beispielhaften Fahrzeug-ECUs 104 als diskrete ECUs 104-A bis 104-H dargestellt. Die Fahrzeug-ECUs 104 können jedoch physische Hardware, Firmware und/oder Software gemein haben, sodass die Funktionalität von mehreren ECUs 104 in eine einzige ECU 104 integriert oder über eine Vielzahl von ECUs 104 verteilt sein kann. Die Fahrzeug-ECUs 104 können verschiedene Komponenten des Fahrzeugs 102 beinhalten, die dazu konfiguriert sind, Aktualisierungen assoziierter Software, Firmware oder Konfigurationseinstellungen zu empfangen.
Nicht einschränkende Bespiele für Fahrzeug-ECUs 104 sind folgende: ein Leistungsstrangsteuermodul (powertrain control module - PCM) 104-A kann dazu konfiguriert sein, Motor- und Getriebekomponenten zu steuern; eine Steuerung eines Antiblockierbremssystems (ABS-Steuerung) 104-B, die dazu konfiguriert ist, Brems- und Traktionssteuerkomponenten zu steuern; eine Steuerung einer elektrisch unterstützten Lenkung (electronic power-assisted steering - EPAS) 104-C, die dazu konfiguriert ist, Lenkunterstützung und Zug- oder Driftkompensationsfunktionen einzustellen; fortschrittliche Fahrerassistenzsysteme (driver assistance systems - ADAS) 104-D, wie etwa adaptive Geschwindigkeitsregelung oder automatisches Bremsen; und ein Scheinwerfersteuermodul (headlamp control module - HCM) 104-E, das dazu konfiguriert ist, Einstellungen zum Einschalten/Ausschalten von Leuchten zu steuern. Die ECUs 104 können außerdem Folgendes beinhaltet: andere Komponenten des Leistungsstrangs 104-F oder des Fahrgestells 104-D, ein Infotainment-System 104-H, das dazu konfiguriert ist, Sprachbefehle und BLUETOOTH-Schnittstellen mit dem Fahrer und Fahrermobilvorrichtungen zu unterstützen (z. B. das SYNC-System, das durch die Ford Motor Company in Dearborn, MI, bereitgestellt wird), eine Konnektivitätssteuerung 104-I, wie etwa eine Telematiksteuereinheit (telematics control unit - TCU), die dazu konfiguriert ist, ein eingebettetes Modem zu nutzen, um auf vernetzte Vorrichtungen zuzugreifen, die extern zu dem Fahrzeug 102 sind, elektromechanische Karosseriesteuerungen 104-J, wie etwa Fenster- oder Verriegelungsaktoren, und Komponenten einer Anhängersteuerung 104-K, wie etwa Leuchtensteuerung und Sensordaten, um verbundene Anhänger zu unterstützen.
Der Fahrzeugbus 106 kann verschiedene Kommunikationsverfahren beinhalten, die zwischen den Fahrzeug-ECUs 104 verfügbar sind. Der Fahrzeugbus 106 kann außerdem Kommunikation zwischen dem zentralen Gateway 110 und den Fahrzeug-ECUs 104 unterstützen. Als einige nicht einschränkende Beispiele kann der Fahrzeugbus 106 ein Controller Area Network (CAN) des Fahrzeugs, ein Ethernet-Netzwerk oder ein Media-Oriented-System-Transfer-Netzwerk (MOST-Netzwerk) sein. Das CAN-Netzwerk oder die CAN-Netzwerke können von verschiedener Art sein, darunter unter anderem Highspeed-CAN (HS-CAN), das eine Datenkapazität von bis zu 500 Kbit/s aufweist, Midspeed-CAN (MS-CAN), das eine Datenkapazität von bis zu 125 Kbit/s aufweist, und/oder CAN mit flexibler Datenrate (FD-CAN), das eine Datenkapazität von bis zu 2.000 Kbit/s oder mehr aufweist. Es ist anzumerken, dass die veranschaulichte Bustopologie lediglich ein Beispiel ist und eine andere Anzahl an und andere Anordnungen von Fahrzeugbussen 106 verwendet werden können. Diese Fahrzeugbusse 106 können als eine Reihe von Verdrahtungssegmenten umgesetzt sein. Zum Beispiel kann ein Fahrzeugbus 106 eine Vielzahl von Verdrahtungssegmenten von dem zentralen Gateway 110 zu einer Endstelle beinhalten.
Das Fahrzeug 102 kann ferner Diagnoseanschlüsse 108 beinhalten, die durch externe Vorrichtungen verwendet werden können, um den Status des Fahrzeugs 102 zu überwachen. In einem Beispiel kann der Diagnoseanschluss 108 ein bordeigener Diagnoseanschluss (onboard diagnostics port - OBD-Anschluss) sein, der mit dem Fahrzeugbus 106 verbunden ist. Ein Benutzer kann einen Dongle, eine Codelesevorrichtung oder andere Scanvorrichtung mit dem Diagnoseanschluss 108 verbinden und kann die durch den Diagnoseanschluss 108 bereitgestellte Verbindung verwenden, um sich Zugriff auf Nachrichten zu verschaffen, die den Fahrzeugbus 106 durchqueren. Sobald sie verbunden ist, kann ein Benutzer diese verbundene Scanvorrichtung nutzen, um Diagnosecodes zu erfassen, den Fahrzeugzustand zu überwachen oder in einigen Fällen Fahrzeugeinstellungen einzustellen. Ähnlich der Geschwindigkeit des HS-CAN können die CAN-Diagnoseanschlüsse 108 eine Datenkapazität von bis zu 500 Kbit/s unterstützen. In einem anderen Beispiel kann der Diagnoseanschluss 108 ein Diagnostic-over-Internet-Protocol-Anschluss (DoIP-Anschluss) 124 sein und kann Zugriff auf Nachrichten bereitstellen, die den Fahrzeugbus 106 über Ethernet anstatt über den OBD-Standard durchqueren. Ein DoIP-Anschluss 124 kann eine höhere Datenrate unterstützen als das CAN, da Ethernet unter Verwendung einer TCP/IP-Nutzlast von 64 Byte Datenraten von etwa ungefähr 45 Mbit/s unterstützen kann und bei Nutzlasten von 1460 Byte Datenraten von etwa 95 Mbit/s unterstützen kann.
Das zentrale Gateway 110 kann dazu konfiguriert sein, eine elektrische Schnittstelle zwischen den Fahrzeugbussen 106 bereitzustellen, die verwendet wird, um innerhalb des Fahrzeugs 102 zu kommunizieren. In einem Beispiel kann das zentrale Gateway 110 dazu konfiguriert sein, Signale und Befehle zwischen dem CAN und/oder den fahrzeuginternen Ethernet-Fahrzeugbussen 106, die mit dem zentrale Gateway 110 verbunden sind, zu übersetzen. Beispielsweise kann das zentrale Gateway 110 eine Verbindung von bis zu zehn CAN-Fahrzeugbussen 106 und bis zu sieben Ethernet-Fahrzeugbussen 106 unterstützen. Durch Unterstützten von Ethernet zusätzlich zu dem CAN kann das zentrale Gateway 110 dazu in der Lage sein, Unterstützung von fahrzeuginterner Netzwerkkommunikation mit höherer Geschwindigkeit bereitzustellen, während weiterhin bestehende Gateway-Funktionen oder Vorgänger-Gateway-Funktionen innerhalb des Fahrzeugs 102 durchgeführt werden.
Als ein spezifisches nicht einschränkendes Beispiel kann das zentrale Gateway 110 wie folgt verbunden sein: über einen HS-CAN-Fahrzeugbus 106 mit den Komponenten des Leistungsstrangs 104-F; über einen zweiten HS-CAN-Fahrzeugbus 106 mit den Komponenten des Fahrgestells 104-G, Sicherheitssystemen und einem Cluster; über einen dritten HS-CAN Fahrzeugbus 106 mit dem Infotainment-System 104-G; über einen vierten HS-CAN-Fahrzeugbus 106 mit der Konnektivität 104-1 und dem Ethernet-Sicherheitsbackupsystem; über einen ersten MS-CAN-Bus mit den elektromechanischen Karosseriesteuerungen 104-J; über einen zweiten MS-CAN-Fahrzeugbus 106 mit der Anhängersteuerung 104-K und/oder Knoten, auf die leicht von außerhalb des Fahrzeugs 102 zugegriffen werden kann; über eine erste und zweite Verbindung eines Diagnosedaten-Fahrzeugbusses 106 mit einem Diagnoseanschluss 108; über einen ersten FD-CAN-Fahrzeugbus 106 mit dem PCM 104-A, ABS 104-B, EPAS 104-C und anderen Steuerungen; und über einen zweiten FD-CAN-Fahrzeugbus 106 mit dem ADAS 104-D, HCM 104-E und anderen Steuerungen. Zum Beispiel sind das Infotainment-System 104-H, die Konnektivität 104-I, das Cluster 104-L, die Frontanzeige 104-M und das ADAS 104-D jeweils über getrennte 2-Draht-Ethernet-Busse 106 mit 100 Mbit/s mit dem zentralen Gateway 110 verbunden. In einem noch anderen Beispiel kann die Frontanzeige 104-M in das Cluster 104-L integriert sein.
Das zentrale Gateway 110 kann ferner dazu konfiguriert sein, eine Rechenfunktionalität zur Unterstützung des Nachrichtenverkehrs im CAN-Bereich des Fahrzeugs 102 zu unterstützen. Zum Beispiel kann das zentrale Gateway 110 einen oder mehrere Prozessoren 112 beinhalten, die dazu konfiguriert sind, Anweisungen, Befehle und andere Routinen durchzuführen, um die in dieser Schrift beschriebenen Prozesse zu unterstützen. In einem Beispiel kann das zentrale Gateway 110 dazu konfiguriert sein, Anweisungen von Anwendungen 118 auszuführen, die von einem Datenspeichermedium 116 des zentralen Gateways 110 in einen Arbeitsspeicher 114 des zentralen Gateways 110 geladen wurden. Die Anwendungen 118 können Software-Code beinhalten, der dazu programmiert ist, den Betrieb des in dieser Schrift ausführlich erörterten zentralen Gateways 110 zu unterstützen.
Zum Beispiel können die Anwendungen 118 Software-Code beinhalten, um das Verfolgen von Fahrzeugkonfigurationen über den Fahrzeuglebenszyklus zu erleichtern, wie in dieser Schrift ausführlich erörtert. Das computerlesbare Datenspeichermedium 116 (auch als prozessorlesbares Medium oder prozessorlesbarer Datenspeicher bezeichnet) beinhaltet ein nicht transitorisches (z. B. materielles) Medium, das an der Bereitstellung von Anweisungen oder anderen Daten beteiligt ist, die durch den Prozessor 112 des zentralen Gateways 110 ausgelesen werden können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielfalt von Programmiersprachen und/oder -technologien hergestellt werden, einschließlich unter anderem und entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und strukturierte Abfragesprache (structured query language - SQL). Als ein spezifisches Beispiel kann das zentrale Gateway 110 mit mindestens 128 Megabyte Direktzugriffsspeicher (random-access memory - RAM) sowie einem 2-4-Core-Prozessor 112 für Verarbeitungsleistung ausgestattet sein, um verschiedene Rechenaufgaben zu ermöglichen.
Ein Merkmal eines Fahrzeugs 102 kann sich auf ein diskretes Element der Hardware- und/oder Software-Funktionalität beziehen. Beispielhafte Merkmale können ein Glasschiebedach, beheizte Sitze, eine Rückfahrkamera, ein Navigationssystem, eine BLUETOOTH-Konnektivität, einen Fernstart, eine Überwachung des toten Winkels usw. beinhalten. Jedes Merkmal des Fahrzeugs 102 kann einem eindeutigen technischen Merkmalscode 120 zugewiesen sein. Diese Merkmalscodes 120 können je nach Version und Variante des Merkmals variieren. Jeder der Merkmalscodes 120, die durch eine ECU 104 umgesetzt werden, kann in einem nicht flüchtigen Arbeitsspeicher der jeweiligen ECU 104 vorgegeben sein.
Das zentrale Gateway 110 kann dazu konfiguriert sein, eine Anwendung 118 zu nutzen, um die vollständige Liste der in dem Fahrzeug 102 installierten Merkmale zu verfolgen. Um dies zu tun, kann das zentrale Gateway 110 ein Merkmalswörterbuch 122 verwalten, das eine Zusammenstellung von zulässigen Kombinationen von Merkmalscodes 120 über die ECUs 104 beinhaltet. In einigen Beispielen kann das Merkmalswörterbuch 122 durch Durchführen einer Abfrage der ECUs 104 nach ihren Versionsinformationen konstruiert werden. In einem anderen Beispiel kann das Merkmalswörterbuch 122 gemäß einem Aufbaublatt des Fahrzeugs 102, das die richtige Ausrüstung für das Fahrzeug 102 vorgibt (z. B. gemäß der Ausgestaltungsabsicht), an das zentrale Gateway 110 übertragen werden. In noch einem weiteren Beispiel kann das Merkmalswörterbuch 122 auf das zentrale Gateway 110 heruntergeladen werden (z. B. als ursprüngliche Software, als Software-Aktualisierung usw.) und kann dieses eine Liste von mehreren zulässigen Kombinationen von Merkmalscodes 120 beinhalten, die in das Fahrzeug 102 installiert werden können.
Die Software-Kompatibilität des Fahrzeugs kann durch die Anwendung 118 des zentralen Gateways 110 durchgeführt werden. In einem Beispiel kann die Anwendung 118 über den einen oder die mehreren Fahrzeugbusse 106 Merkmalscodes 120, die in den Konfigurationsteilen der ECUs 104 eingebettet sind, von den ECUs 104 abfragen und diese abgefragten Informationen mit der zulässigen Kombination oder Kombinationen vergleichen, die durch das Merkmalswörterbuch 122 des zentralen Gateways 110 vorgegeben sind.
Die Anwendung 118 kann dazu programmiert sein, sicherzustellen, dass der gleiche Satz von Merkmalscodes 120 von den ECUs 104 in dem Merkmalswörterbuch 122 des zentralen Gateways 110 enthalten ist. Wenn eine nicht autorisierte ECU 104 mit inkompatibler Software installiert ist, ist diese ECU 104 unter Umständen nicht mit dem Rest des Fahrzeugs 102 abgestimmt. Dies kann dadurch ersichtlich werden, dass die Merkmalscodes 120 für diese ECU 104 nicht mit den Merkmalscodes 120 des Merkmalswörterbuchs 122 übereinstimmen.
2 veranschaulicht ein Beispiel für ein Merkmalswörterbuch 122 des Fahrzeugs 102, das weitere Aspekte der Merkmalscodes 120 veranschaulicht. Jeder Merkmalscode 120 kann einem Fahrzeugprogramm 202 zugeordnet sein. Ein Fahrzeugprogramm 202 kann sich auf eine erstellbare Kombination eines Satzes von Merkmalen beziehen, auf die durch die Merkmalscodes 120 Bezug genommen wird. Die Fahrzeugprogramme 202 können auch durch Kennungen identifiziert werden, die für die konkreten Fahrzeugprogramme 202 spezifisch sind. Die Programminformationen können außerdem ein Modelljahr 204 oder eine andere zeitliche Angabe der Erstellung beinhalten, da Programme je nach Modelljahr 204, Auftrag usw. variieren können.
Einige Merkmale können vorgeschrieben oder standardmäßig sein, was bedeutet, dass sie im Allgemeinen an dem Fahrzeug 102 installiert sind. Diese Merkmale können als eine Merkmalszuordnung zwischen dem Merkmalscode 120 für dieses Merkmal und einem generischen Fahrzeugprogrammcode 202 definiert sein. Andere Merkmale können optionale, aber bestellbare Merkmale sein. Diese optionalen Merkmale können eine Zuordnung des optionalen Merkmalscodes 120 zu einem erstellbaren Code 206 beinhalten. Die Merkmalszuordnung kann außerdem eine durch Menschen lesbare Merkmalsbezeichnung 210 beinhalten, um das Verständnis der Informationen in dem Merkmalswörterbuch 122 zu unterstützen. Jeder der Merkmalscodes 120 kann betroffenen Steuerungen 212 zugeordnet werden, die zur Umsetzung des Merkmals erforderlich sind. Das Merkmalswörterbuch 122 kann außerdem eine ECU-Zuordnung 214 der erforderlichen Hardware- und Software-Teilenummern sowie der erforderlichen Konfigurationsparameter beinhalten. Zum Beispiel können, wie gezeigt, unterschiedliche Versionen des Leistungsausgangsmerkmals unterschiedliche Software-Konfigurationen der Fahrzeug-ECUs 104 erforderlich machen (z. B. Power!, Power2, Power3, Power4, wie veranschaulicht).
3A veranschaulicht ein Beispiel für Merkmalscodes 120 für eine erste Version eines Merkmals über die ECUs 104 des Fahrzeugs 102. In einem Beispiel kann das Merkmal ein Fernstartmerkmal RS-1A für das Fahrzeug 102 sein. Wie gezeigt, kann das beispielhafte Fernstartmerkmal Konnektivitäts-, Karosserie-, Antriebsstrang- und Funk-ECUs 104 des Fahrzeugs 102 einschließen. Da das Merkmal vier der ECUs 104 einschließt, kann der Merkmalscode 120 diese Informationen ebenfalls codieren (z. B. als RS-1A4, wie gezeigt).
Es ist anzumerken, dass in anderen Beispielen die Menge an ECUs 104, die den Merkmalscode 120 aufweisen soll, in einem anderen Abschnitt des Merkmalswörterbuchs 122 oder in einer anderen Datenstruktur gespeichert sein kann, anstatt dass es sich hierbei um eingebettete Informationen innerhalb des Merkmalscodes 120 selbst handelt. Zum Beispiel kann das zentrale Gateway 110 das Merkmalswörterbuch 122 nutzen, um die Zahl an ECUs 104 unter Verwendung der Informationen der betroffenen Steuerungen 212 oder der ECU-Zuordnung 214 zu bestimmen. Es ist jedoch auch anzumerken, dass, wenn die Menge in den Merkmalscodes 120 beinhaltet ist, die Informationen der betroffenen Steuerungen 212 und ECU-Zuordnungen 214 möglicherweise nicht in dem zentralen Gateway 110 gespeichert werden müssen, wodurch weniger Datenspeicher 116 genutzt wird.
3B veranschaulicht ein Beispiel für Merkmalscodes 120 für eine zweite Version des Merkmals über die ECUs 104 des Fahrzeugs 102. Diese zweite Version des Fernstartmerkmals (RS-2A) kann eine Kabinenvorklimatisierung beinhalten. Um diese zusätzliche Funktionalität zu ermöglichen, kann die zweite Version des Fernstartmerkmals zusätzlich Software der ECU 104 zur Heizung, Lüftung und Klimatisierung (HLK) einschließen. Wie gezeigt, schließt die revidierte Version nun Konnektivitäts-, Karosserie-, HLK-, Antriebsstrang- und Funk-ECUs 104 des Fahrzeugs 102 ein. Da das aktualisierte Merkmal vier der ECUs 104 einschließt, kann der Merkmalscode 120 diese ebenfalls codieren (z. B. als RS-2A5, wie gezeigt).
Wie vorstehend angemerkt, kann das zentrale Gateway 110 die Merkmalscodes 120 der ECUs 104 von diesen abfragen. Diese Informationen können analysiert werden, um Probleme zu identifizieren. Um das Beispiel aus 3A zu verwenden, kann das zentrale Gateway 110 bestätigen, dass der RS-lA-Code zu sehen ist und dass keine andere(n) Version(en) desselben Codes ebenfalls zu sehen ist (z. B. keine Instanzen von RS-2A, RS-3A usw.). Als eine weitere Bestätigung kann das zentrale Gateway 110 auch bestätigen, dass die Menge an ECUs 104, die den Merkmalscode 120 zurückgeben, richtig ist. Weiter mit dem Beispiel aus 3A kann das zentrale Gateway 110 bestätigen, dass vier ECUs 104 vorhanden sind, die den Code RS-1A zurückgeben.
Wenn die Konfiguration falsch ist, kann das zentrale Gateway 110 dazu konfiguriert sein, eine Warnung bereitzustellen, die das Problem angibt. Darüber hinaus kann das zentrale Gateway 110, da das Problem mit der Verifizierung eines Merkmalscodes 120 verbunden ist, zusätzlich in der Warnung angeben, welche Merkmale von dem Problem betroffen sind. Die Warnung kann zum Beispiel nicht übereinstimmende Software-Versionen für ein Merkmal und/oder eine falsche Menge an ECUs 104 für ein Merkmal angeben. Das zentrale Gateway 110 kann ECUs 104 des Fahrzeugs 102 nutzen, um die Warnung in der Mensch-Maschine-Schnittstelle (human machine interface - HMI) des Fahrzeugs 102, an eine mobile Vorrichtung in Kommunikation mit dem Fahrzeug 102, an einen entfernten Server über ein Netzwerk, an einen Server einer Wartungseinrichtung, an eine Diagnosevorrichtung, die über den Diagnoseanschluss 108 mit dem Fahrzeug 102 verbunden ist, usw. bereitzustellen. In einem anderen Beispiel kann, wenn kompatible Software verfügbar ist, um die Warnung zu beheben, diese Software automatisch installiert werden (um z. B. eine gültige Satz von Merkmalen gemäß dem Merkmalswörterbuch 122 zu installieren). Wenn zum Beispiel eine der ECUs 104 eine falsche oder fehlende Software-Version aufweist, kann die richtige Version auf dieser ECU 104 installiert werden.
4 veranschaulicht einen beispielhaften Prozess 400 zum Verfolgen von Konfigurationen des Fahrzeugs 102 über den Lebenszyklus des Fahrzeugs 102. In einem Beispiel kann der Prozess 400 im Rahmen des Systems 100 durch das zentrale Gateway 110 des Fahrzeugs 102 durchgeführt werden.
Bei Vorgang 402 bestimmt das zentrale Gateway 110, ob die Verifizierung der ECU 104 ausgelöst wird. In einem Beispiel kann die Verifizierung als Reaktion darauf ausgelöst werden, dass ein Benutzer die Fahrzeuge 102 einschaltet (z. B. als Reaktion auf einen Zyklus des Einschaltens mit dem Zündschlüssel). In einem anderen Beispiel kann die Verifizierung durch Auswahl einer Verifizierungsfunktion von der HMI des Fahrzeugs 102 ausgelöst werden, wobei die Funktion die Anwendung 118 des zentralen Gateways 110 informiert, um die Verifizierung durchzuführen. In noch einem anderen Beispiel kann die Verifizierung durch ein mit dem Diagnoseanschluss 108 verbundenes Werkzeug ausgelöst werden, das eine Verifizierungsnachricht zur Verarbeitung durch die Anwendung 118 an das zentrale Gateway 110 sendet, um die Verifizierung durchzuführen.
Bei Vorgang 404 fragt das zentrale Gateway 110 Merkmalscodes 120 von den ECUs 104 ab. In einem Beispiel kann die Anwendung 118 über den einen oder die mehreren Fahrzeugbusse 106 Merkmalscodes 120, die in den Konfigurationsteilen der ECUs 104 eingebettet sind, von den ECUs 104 abfragen.
Bei Vorgang 406 vergleicht das zentrale Gateway 110 die Merkmalscodes 120 mit den Informationen in dem Merkmalswörterbuch 122. In einem Beispiel kann das zentrale Gateway 110 den empfangenen Satz von Informationen von den ECUs 104 vergleichen, um sicherzustellen, dass die Merkmalscodes 120 von den ECUs 104 mit den akzeptablen Kombinationen von Merkmalscodes 120 übereinstimmen, die in dem Merkmalswörterbuch 122 vorgegeben sind.
Bei Vorgang 408 bestimmt das zentrale Gateway 110, ob ein Problem identifiziert wurde. In einem Beispiel kann das zentrale Gateway 110 bestätigen, dass eine einzelne Version eines Merkmalscodes 120 in den abgefragten Merkmalscodes 120 zu sehen ist. In einem anderen Beispiel kann das zentrale Gateway 110 zusätzlich oder alternativ bestätigen, dass die Menge an ECUs 104, die den Merkmalscode 120 zurückgeben, richtig ist.
Bei Vorgang 410 gibt das zentrale Gateway 110 das Problem an. Zum Beispiel kann das zentrale Gateway 110 angeben, welche Merkmale gemäß den Merkmalscodes 120 von dem Problem betroffen sind. Die Warnung kann zum Beispiel nicht übereinstimmende Software-Versionen für ein Merkmal und/oder eine falsche Menge an ECUs 104 für ein Merkmal angeben. In einigen Beispielen kann das Merkmalswörterbuch 122 verwendet werden, um zusätzliche Informationen (falls verfügbar) bereitzustellen, wie etwa durch Menschen lesbare Merkmalsbezeichnungen 210 der Merkmale, die Probleme aufweisen können, und/oder welche der ECUs 104 die falsche, fehlende oder unnötige Software aufweisen. Das Problem kann als eine Warnung an eines oder mehrere von der HMI des Fahrzeugs 102, an eine mobile Vorrichtung in Kommunikation mit dem Fahrzeug 102, über ein Netzwerk an einen entfernten Server, an einen Server einer Serviceeinrichtung, an ein Diagnosevorrichtung, die über den Diagnoseanschluss 108 mit dem Fahrzeug 102 verbunden ist, um die Software-Konfiguration automatisch zu korrigieren, usw. bereitgestellt werden. Nach Vorgang 410 endet der Prozess 400.
5 veranschaulicht eine beispielhafte Rechenvorrichtung 502 zum Verfolgen von Konfigurationen des Fahrzeugs 102 über den Lebenszyklus des Fahrzeugs 102. In Bezug auf 5 und unter Bezugnahme auf 1-4 können das Fahrzeug 102, die ECUs 104 und das zentrale Gateway 110 Beispiele für derartige Rechenvorrichtungen 502 sein. Rechenvorrichtungen 502 beinhalten im Allgemeinen computerausführbare Anweisungen, wie etwa die der Anwendungen 118, wobei die Anweisungen durch eine oder mehrere der Rechenvorrichtungen 502 ausführbar sein können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielfalt von Programmiersprachen und/oder -techniken hergestellt werden, einschließlich unter anderem und entweder allein oder in Kombination Java™, C, C++, C#, Visual Basic, JavaScript, Python, Perl usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen z. B. von einem Arbeitsspeicher, einem computerlesbaren Medium usw. und führt diese Anweisungen aus, wodurch ein oder mehrere Prozesse, einschließlich eines oder mehrerer der in dieser Schrift beschriebenen Prozesse, durchgeführt werden. Derartige Anweisungen und andere Daten, wie etwa die Merkmalscodes 120 und das Merkmalswörterbuch 122, können unter Verwendung einer Vielzahl von computerlesbaren Medien gespeichert und übertragen werden.
Wie gezeigt, kann die Rechenvorrichtung 502 einen Prozessor 504 beinhalten, der mit einem Datenspeicher 506, einer Netzwerkvorrichtung 508, einer Ausgabevorrichtung 510 und einer Eingabevorrichtung 512 wirkverbunden ist. Es ist anzumerken, dass dies lediglich ein Beispiel ist und Rechenvorrichtungen 502 mit mehr, weniger oder anderen Komponenten verwendet werden können.
Der Prozessor 504 kann eine oder mehrere integrierte Schaltungen beinhalten, welche die Funktionalität einer zentralen Verarbeitungseinheit (central processing unit - CPU) und/oder Grafikverarbeitungseinheit (graphics processing unit - GPU) umsetzen. In einigen Beispielen handelt es sich bei den Prozessoren 504 um ein System auf einem Chip (system on a chip - SoC), in dem die Funktionalität der CPU und der GPU integriert ist. Das SoC kann gegebenenfalls andere Komponenten, wie zum Beispiel den Datenspeicher 506 und die Netzwerkvorrichtung 508, in einer einzigen integrierten Vorrichtung beinhalten. In anderen Beispielen sind die CPU und die GPU über eine Peripherie-Verbindungsvorrichtung, wie etwa Peripheral-Component-Interconnect-Express (PCI-Express) oder eine andere geeignete Peripherie-Datenverbindung, miteinander verbunden. In einem Beispiel handelt es sich bei der CPU um eine handelsübliche zentrale Verarbeitungsvorrichtung, die einen Anweisungssatz umsetzt, wie etwa eine von der x86-, ARM- oder Power-Anweisungssatzfamilie oder eine Anweisungssatzfamilie für Mikroprozessoren ohne verschränkte Pipeline-Stufen (microprocessor without interlocked pipeline stages - MIPS).
Unabhängig von den Einzelheiten führt der Prozessor 504 während des Betriebs gespeicherte Programmanweisungen aus, die aus dem Datenspeicher 506 abgerufen werden. Die gespeicherten Programmanweisungen beinhalten dementsprechend Software, die den Betrieb der Prozessoren 504 steuert, um die in dieser Schrift beschriebenen Vorgänge durchzuführen. Der Datenspeicher 506 kann sowohl nicht flüchtige als auch flüchtige Arbeitsspeichervorrichtungen beinhalten. Der nicht flüchtige Arbeitsspeicher beinhaltet Festkörperspeicher, wie etwa Nicht-UND-(Not AND -NAND-)Flash-Arbeitsspeicher, magnetische und optische Datenspeichermedien oder eine beliebige andere geeignete Datenspeichervorrichtung, die Daten speichert, wenn das System deaktiviert oder dessen Stromversorgung unterbrochen ist. Der flüchtige Arbeitsspeicher beinhaltet einen statischen und dynamischen RAM, auf dem während des Betriebs des Systems 100 Programmanweisungen und Daten gespeichert werden.
Die GPU kann Hardware und Software zur Anzeige von mindestens zweidimensionalen (2D-) und gegebenenfalls dreidimensionalen (3D-)Grafiken auf der Ausgabevorrichtung 510 beinhalten. Die Ausgabevorrichtung 510 kann eine grafische oder visuelle Anzeigevorrichtung, wie etwa einen elektronischen Anzeigebildschirm, einen Projektor, einen Drucker oder eine beliebige andere geeignete Vorrichtung, die eine grafische Anzeige wiedergibt, beinhalten. Als ein anderes Beispiel kann die Ausgabevorrichtung 510 eine Audiovorrichtung, wie etwa einen Lautsprecher oder einen Kopfhörer, beinhalten. Als ein noch weiteres Beispiel kann die Ausgabevorrichtung 510 eine taktile Vorrichtung, wie etwa eine mechanisch erhöhbare Vorrichtung, beinhalten, die in einem Beispiel dazu konfiguriert sein kann, Blindenschrift oder eine andere physische Ausgabe anzuzeigen, die berührt werden kann, um einem Benutzer Informationen bereitzustellen.
Die Eingabevorrichtung 512 kann eine beliebige von verschiedenen Vorrichtungen beinhalten, die es der Rechenvorrichtung 502 ermöglichen, Steuereingaben von Benutzern zu empfangen. Beispiele für geeignete Eingabevorrichtungen 512, die Eingaben über eine menschliche Schnittstelle empfangen, können Tastaturen, Mäuse, Trackballs, Touchscreens, Mikrofone, Grafiktablets und dergleichen beinhalten.
Die Netzwerkvorrichtungen 508 können jeweils eine beliebige von verschiedenen Vorrichtungen beinhalten, die es den beschriebenen Komponenten ermöglichen, Daten von externen Vorrichtungen über Netzwerke zu senden und/oder zu empfangen. Beispiele für geeignete Netzwerkvorrichtungen 508 beinhalten eine Ethernet-Schnittstelle, einen Wi-Fi-Sendeempfänger, einen Mobilfunk-Sendeempfänger, einen BLUETOOTH- oder BLUETOOTH-Low-Energy-Sendeempfänger (BLE-Sendeempfänger) oder einen anderen Netzwerkadapter oder eine andere Peripherie-Verbindungsvorrichtung, der/die Daten von einem anderen Computer oder einer externen Datenspeichervorrichtung empfängt, was zum Empfangen großer Datensätze auf effiziente Weise nützlich sein kann.
Hinsichtlich der in dieser Schrift beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass obwohl die Schritte derartiger Prozesse usw. als gemäß einer gewissen geordneten Abfolge erfolgend beschrieben worden sind, derartige Prozesse praktisch umgesetzt werden könnten, wobei die beschriebenen Schritte in einer Reihenfolge durchgeführt werden, die von der in dieser Schrift beschriebenen Reihenfolge abweicht. Ferner versteht es sich, dass gewisse Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder gewisse in dieser Schrift beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt, dienen die Beschreibungen von Prozessen in dieser Schrift dem Zweck der Veranschaulichung gewisser Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Patentansprüche einschränken.
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Aus der Lektüre der vorangehenden Beschreibung ergeben sich viele andere Ausführungsformen und Anwendungen als die aufgeführten Beispiele. Der Umfang sollte nicht unter Bezugnahme auf die vorstehende Beschreibung, sondern stattdessen unter Bezugnahme auf die beigefügten Patentansprüche bestimmt werden, zusammen mit dem gesamten Umfang an Äquivalenten, zu denen diese Patentansprüche berechtigen. Es ist davon auszugehen und beabsichtigt, dass es zukünftige Entwicklungen in den Techniken, die in dieser Schrift erörtert sind, geben wird und dass die offenbarten Systeme und Verfahren in derartige zukünftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und variiert werden kann.
Allen in den Patentansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutungen zugeordnet sein, wie sie den mit den in dieser Schrift beschriebenen Techniken vertrauten Fachleuten bekannt sind, sofern in dieser Schrift kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „eine“, „der“, „die“, „das“ usw., dahingehend zu verstehen, dass eines oder mehrere der angegebenen Elemente genannt werden, es sei denn, ein Patentanspruch nennt eine ausdrückliche gegenteilige Einschränkung.
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird in der Auffassung eingereicht, dass sie nicht dazu verwendet wird, den Umfang oder die Bedeutung der Patentansprüche auszulegen oder einzuschränken. Außerdem geht aus der vorstehenden detaillierten Beschreibung hervor, dass zum Zweck der vereinfachten Darstellung der Offenbarung verschiedene Merkmale in verschiedenen Ausführungsformen zusammengefasst wurden. Dieses Verfahren der Offenbarung ist nicht dahingehend zu interpretieren, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als in jedem Patentanspruch ausdrücklich genannt sind. Wie die folgenden Patentansprüche widerspiegeln, liegt der Gegenstand der Erfindung vielmehr in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform. Somit werden die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch für sich als getrennt beanspruchter Gegenstand steht.
Während vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Offenbarung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende als einschränkende Ausdrücke, und es versteht sich, dass diverse Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Offenbarung zu bilden.
Gemäß der vorliegenden Erfindung ist ein System zum Verfolgen einer Steuerungskonfiguration bereitgestellt, das Folgendes aufweist: elektronische Steuereinheiten (ECUs); und ein zentrales Gateway, das zu Folgendem programmiert ist: Abfragen von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die jeweilige ECU umgesetzt werden, von jeder ECU der ECUs, wobei jeder Merkmalscode einer Sollmenge an ECUs entspricht, die an der Umsetzung der Funktionalität beteiligt sind, und Angeben einer Warnung als Reaktion darauf, dass die Abfrage eine andere Menge an ECUs, welche die Funktionalität umsetzen, zurückgibt als die Sollmenge.
Gemäß einer Ausführungsform hat jeder der Merkmalscodes die Sollmenge als einen Abschnitt des jeweiligen Merkmalscodes eingebettet.
Gemäß einer Ausführungsform ist die Sollmenge ein Suffix des jeweiligen Merkmalscodes.
Gemäß einer Ausführungsform steht das zentrale Gateway über einen oder mehrere Busse in Kommunikation mit den ECUs, wobei das zentrale Gateway ferner dazu programmiert ist, die Merkmalscodes über den einen oder die mehreren Busse von den ECUs abzufragen.
Gemäß einer Ausführungsform ist das System ein Fahrzeug und ist das zentrale Gateway ferner dazu programmiert, die Merkmalscodes als Reaktion auf ein Einschalten des Fahrzeugs mit dem Zündschlüssel von den ECUs abzufragen.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner zu Folgendem programmiert: Abfragen der Merkmalscodes von den ECUs als Reaktion auf eine Anforderung von einer Diagnosevorrichtung, die über einen Diagnoseanschluss mit dem zentralen Gateway verbunden ist; und Angeben der Warnung als eine Nachricht, die von dem zentralen Gateway an die Diagnosevorrichtung gesendet wird.
Gemäß einer Ausführungsform gibt die Warnung die Merkmalscodes an, für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.
Gemäß einer Ausführungsform beinhaltet das zentrale Gateway einen Datenspeicher, der dazu konfiguriert ist, ein Merkmalswörterbuch zu verwalten, das zulässige Merkmalscodekombinationen über die ECUs vorgibt, und ist das zentrale Gateway ferner dazu programmiert, das Merkmalswörterbuch zu nutzen, um Angaben davon, welchen der ECUs Merkmalscodes für ein Merkmal fehlen, oder Angaben, die Merkmalscodes melden, die für das Merkmal nicht vorgegeben sind, in die Warnung einzuschließen.
Gemäß einer Ausführungsform beinhaltet das Merkmalswörterbuch durch Menschen lesbare Bezeichnungen für das Merkmal und beinhaltet die Warnung die durch Menschen lesbaren Bezeichnungen, für welche die Merkmalscodes für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren zum Verfolgen einer Steuerungskonfiguration Folgendes: Abfragen von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die j eweilige ECU umgesetzt werden, von jeder ECU einer Vielzahl von ECUs, wobei jeder Merkmalscode einer Sollmenge an ECUs entspricht, die an der Umsetzung der Funktionalität beteiligt sind; und Angeben einer Warnung als Reaktion darauf, dass das Abfragen eine andere Menge an ECUs, welche die Funktionalität umsetzen, zurückgibt als die Sollmenge.
In einem Aspekt der Erfindung hat jeder der Merkmalscodes die Sollmenge als einen Abschnitt des jeweiligen Merkmalscodes eingebettet.
In einem Aspekt der Erfindung ist die Sollmenge ein Suffix des jeweiligen Merkmalscodes.
In einem Aspekt der Erfindung steht ein zentrales Gateway über einen oder mehrere Busse in Kommunikation mit den ECUs, und ferner umfassend Abfragen der Merkmalscodes von den ECUs durch das zentrale Gateway über den einen oder die mehreren Busse.
In einem Aspekt der Erfindung sind die ECUs Komponenten eines Fahrzeugs, und ferner umfassend Abfragen der Merkmalscodes von den ECUs als Reaktion auf ein Einschalten des Fahrzeugs mit dem Zündschlüssel.
In einem Aspekt der Erfindung beinhaltet das Verfahren Folgendes: Abfragen der Merkmalscodes von den ECUs als Reaktion auf eine Anforderung von einer Diagnosevorrichtung; und Angeben der Warnung als eine Nachricht an die Diagnosevorrichtung als Reaktion auf die Anforderung.
In einem Aspekt der Erfindung gibt die Warnung die Merkmalscodes an, für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.
In einem Aspekt der Erfindung beinhaltet das Verfahren Folgendes: Verwalten eines Merkmalswörterbuchs, das zulässige Merkmalscodekombinationen über die ECUs vorgibt; und Nutzen des Merkmalswörterbuchs, um Angaben davon, welchen der ECUs Merkmalscodes für ein Merkmal fehlen, oder Angaben, die Merkmalscodes melden, die nicht für das Merkmal vorgegeben sind, in die Warnung einzuschließen.
In einem Aspekt der Erfindung beinhaltet das Merkmalswörterbuch durch Menschen lesbare Bezeichnungen für das Merkmal und beinhaltet die Warnung die durch Menschen lesbaren Bezeichnungen, für welche die Merkmalscodes für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.
Gemäß der vorliegenden Erfindung ist ein nicht transitorisches computerlesbares Medium bereitgestellt, das Anweisungen zum Verfolgen einer Steuerungskonfiguration aufweist, die bei Ausführung durch ein zentrales Gateway in Kommunikation über einen oder mehrere Busse mit einer Vielzahl von ECUs das zentrale Gateway dazu veranlassen, Vorgänge durchzuführen, einschließlich zu Folgendem: Abfragen von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die jeweilige ECU umgesetzt werden, von jeder ECU der ECUs, wobei jeder Merkmalscode einer Sollmenge an ECUs entspricht, die an der Umsetzung der Funktionalität beteiligt sind; und Angeben einer Warnung als Reaktion darauf, dass die Abfrage eine andere Menge an ECUs, welche die Funktionalität umsetzen, zurückgibt als die Sollmenge.
Gemäß einer Ausführungsform hat jeder der Merkmalscodes die Sollmenge als einen Abschnitt des jeweiligen Merkmalscodes eingebettet.

Claims

System zum Verfolgen einer Steuerungskonfiguration, umfassend: elektronische Steuereinheiten (ECUs); und ein zentrales Gateway, das zu Folgendem programmiert ist: Abfragen von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die j eweilige ECU umgesetzt werden, von j eder ECU der ECUs, wobei jeder Merkmalscode einer Sollmenge an ECUs entspricht, die an der Umsetzung der Funktionalität beteiligt sind, und Angeben einer Warnung als Reaktion darauf, dass die Abfrage eine andere Menge an ECUs, welche die Funktionalität umsetzen, zurückgibt als die Sollmenge.
System nach Anspruch 1, wobei jeder der Merkmalscodes die Sollmenge als einen Abschnitt des jeweiligen Merkmalscodes eingebettet hat.
System nach Anspruch 2, wobei die Sollmenge ein Suffix des j eweiligen Merkmalscodes ist.
System nach Anspruch 1, wobei das zentrale Gateway über einen oder mehrere Busse in Kommunikation mit den ECUs steht, wobei das zentrale Gateway ferner dazu programmiert ist, die Merkmalscodes über den einen oder die mehreren Busse von den ECUs abzufragen.
System nach Anspruch 1, wobei das System ein Fahrzeug ist und das zentrale Gateway ferner dazu programmiert ist, die Merkmalscodes als Reaktion auf ein Einschalten des Fahrzeugs mit dem Zündschlüssel von den ECUs abzufragen.
System nach Anspruch 1, wobei das zentrale Gateway ferner zu Folgendem programmiert ist: Abfragen der Merkmalscodes von den ECUs als Reaktion auf eine Anforderung von einer Diagnosevorrichtung, die über einen Diagnoseanschluss mit dem zentralen Gateway verbunden ist; und Angeben der Warnung als eine Nachricht, die von dem zentralen Gateway an die Diagnosevorrichtung gesendet wird.
System nach Anspruch 1, wobei die Warnung die Merkmalscodes angibt, für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.
System nach Anspruch 1, wobei das zentrale Gateway einen Datenspeicher beinhaltet, der dazu konfiguriert ist, ein Merkmalswörterbuch zu verwalten, das zulässige Merkmalscodekombinationen über die ECUs vorgibt, und das zentrale Gateway ferner dazu programmiert ist, das Merkmalswörterbuch zu nutzen, um Angaben darüber, welchen der ECUs Merkmalscodes für ein Merkmal fehlen, oder Angaben, die Merkmalscodes melden, die für das Merkmal nicht vorgegeben sind, in die Warnung einzuschließen.
System nach Anspruch 8, wobei das Merkmalswörterbuch durch Menschen lesbare Bezeichnungen für das Merkmal beinhaltet und die Warnung die durch Menschen lesbaren Bezeichnungen beinhaltet, für die Merkmalscodes, für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.
Verfahren zum Verfolgen einer Steuerungskonfiguration, umfassend: Abfragen von Merkmalscodes, die auf Elemente der Funktionalität hinweisen, die durch die jeweilige ECU umgesetzt werden, von jeder ECU einer Vielzahl von ECUs, wobei jeder Merkmalscode einer Sollmenge an ECUs entspricht, die an der Umsetzung der Funktionalität beteiligt sind; und Angeben einer Warnung als Reaktion darauf, dass das Abfragen eine andere Menge an ECUs, welche die Funktionalität umsetzen, zurückgibt als die Sollmenge.
Verfahren nach Anspruch 10, wobei jeder der Merkmalscodes die Sollmenge als einen Abschnitt des jeweiligen Merkmalscodes eingebettet hat.
Verfahren nach Anspruch 10, wobei ein zentrales Gateway über einen oder mehrere Busse in Kommunikation mit den ECUs steht, und ferner umfassend Abfragen der Merkmalscodes von den ECUs durch das zentrale Gateway über den einen oder die mehreren Busse.
Verfahren nach Anspruch 10, wobei die ECUs Komponenten eines Fahrzeugs sind, und ferner umfassend Abfragen der Merkmalscodes von den ECUs als Reaktion auf ein Einschalten des Fahrzeugs mit dem Zündschlüssel.
Verfahren nach Anspruch 10, ferner umfassend: Abfragen der Merkmalscodes von den ECUs als Reaktion auf eine Anforderung von einer Diagnosevorrichtung; und Angeben der Warnung als eine Nachricht an die Diagnosevorrichtung als Reaktion auf die Anforderung, wobei die Warnung die Merkmalscodes angibt, für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.
Verfahren nach Anspruch 10, ferner umfassend: Verwalten eines Merkmalswörterbuchs, das zulässige Merkmalscodekombinationen über die ECUs vorgibt; und Nutzen des Merkmalswörterbuchs, um Angaben davon, welchen der ECUs Merkmalscodes für ein Merkmal fehlen, oder Angaben, die Merkmalscodes melden, die nicht für das Merkmal vorgegeben sind, in die Warnung einzuschließen, wobei das Merkmalswörterbuch durch Menschen lesbare Bezeichnungen für das Merkmal beinhaltet und die Warnung die durch Menschen lesbaren Bezeichnungen beinhaltet, für die Merkmalscodes, für welche die Sollmenge nicht mit der Menge an ECUs übereinstimmt, welche die Funktionalität umsetzen.