DE102022125552A1

DE102022125552A1 - Dynamischer mitteilungsversand eines controller area network

Info

Publication number: DE102022125552A1
Application number: DE102022125552.2A
Authority: DE
Inventors: Amrit Gopal; James Martin Lawlis
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2021-10-07
Filing date: 2022-10-04
Publication date: 2023-04-13
Also published as: CN115955369A; US20230116328A1

Abstract

Es ist ein dynamischer Mitteilungsversand eines Controller Area Network (CAN) bereitgestellt. Ein zentrales Gateway eines Fahrzeugs beinhaltet einen Prozessor und einen Speicher, der mit einer Vielzahl von Fahrzeugbussen verbunden ist, wobei jeder der Fahrzeugbusse mit einer oder mehreren elektronischen Steuerungseinheiten (ECUs) verbunden ist. Der zentrale Gateway empfängt eine Mitteilung von einem Client der ECUs, wobei die Mitteilung ein dynamisches CAN-Signal anfordert. Die Mitteilung wird über die Vielzahl von Fahrzeugbussen an einen Server der ECUs weitergeleitet. Eine Antwort von dem Server wird an dem zentralen Gateway empfangen, wobei die Antwort die Verfügbarkeit des dynamischen CAN-Signals festlegt. Die Antwort wird an den Client weitergeleitet.

Description

GEBIET DER TECHNIK
Aspekte der Offenbarung betreffen im Allgemeinen dynamischen Mitteilungsversand eines Controller Area Network (CAN).
ALLGEMEINER STAND DER TECHNIK
Fahrzeugkomponenten senden und empfangen Daten über Fahrzeugbusprotokolle, wie etwa ein Controller Area Network (CAN). Um zu kommunizieren, sind die Fahrzeugkomponenten ausgebildet, um handgefertigten Datenaustausch über den CAN-Bus zu senden. CAN-Mitteilungslisten sind quasi statisch; daher ist ein Systembetreiber oder -implementierer nicht in der Lage, Eingaben oder Ausgaben zu ändern, ohne Softwarekomponenten in mehreren Steuerungen zu ändern. Beschränkungen der Netzwerkbandbreite über den CAN-Bus hindern Module daran, überschüssige Daten zu veröffentlichen, was somit das Absichern von Designs für die Zukunft beschränkt. Komponenten, die eine Echtzeitsteuerung durchführen, sind üblicherweise mit einem beschränkten Spielraum für neue Merkmale oder Funktionen ausgebildet. Derartige Systeme sind oftmals um einen einfachen Aufgabenplaner konzipiert.
KURZDARSTELLUNG
In einer oder mehreren veranschaulichenden Ausführungsformen wird ein System zum dynamischen Mitteilungsversand eines Controller Area Network (CAN) bereitgestellt. Das System beinhaltet ein zentrales Gateway eines Fahrzeugs, das einen Prozessor und einen Speicher beinhaltet, der mit einer Vielzahl von Fahrzeugbussen verbunden ist, wobei jeder der Fahrzeugbusse mit einer oder mehreren elektronischen Steuerungseinheiten (electronic control units - ECUs) verbunden ist. Das zentrale Gateway ist dazu programmiert, eine Mitteilung von einem Client der ECUs zu empfangen, wobei die Mitteilung ein dynamisches CAN-Signal anfordert, die Mitteilung über die Vielzahl von Fahrzeugbussen an einen Server der ECUs weiterzuleiten, eine Antwort von dem Server zu empfangen, wobei die Antwort eine Verfügbarkeit des dynamischen CAN-Signals festlegt, und die Antwort an den Client weiterzuleiten.
In einer oder mehreren veranschaulichenden Ausführungsformen wird ein Verfahren zum dynamischen Mitteilungsversand eines Controller Area Network (CAN) bereitgestellt. Ein zentrales Gateway eines Fahrzeugs beinhaltet einen Prozessor und einen Speicher, der mit einer Vielzahl von Fahrzeugbussen verbunden ist, wobei jeder der Fahrzeugbusse mit einer oder mehreren elektronischen Steuerungseinheiten (ECUs) verbunden ist. Der zentrale Gateway empfängt eine Mitteilung von einem Client der ECUs, wobei die Mitteilung ein dynamisches CAN-Signal anfordert. Die Mitteilung wird über die Vielzahl von Fahrzeugbussen an einen Server der ECUs weitergeleitet. Eine Antwort von dem Server wird an dem zentralen Gateway empfangen, wobei die Antwort die Verfügbarkeit des dynamischen CAN-Signals festlegt. Die Antwort wird an den Client weitergeleitet.
Figurenliste

1 veranschaulicht ein beispielhaftes System, das ein erweitertes zentrales Gateway (enhanced central gateway - ECG) beinhaltet, das für dynamischen CAN-Mitteilungsversand konfiguriert ist;
2 veranschaulicht einen beispielhaften CAN-Datenrahmen, der dynamischen CAN-Mitteilungsversand unterstützt;
3 veranschaulicht eine beispielhafte Darstellung des Datenfelds des CAN-Datenrahmens, der in einzelne Bits unterteilt ist;
4 veranschaulicht eine beispielhafte Darstellung möglicher Datenstruktur-IDs, die in den ersten drei Bits des Datenabschnitts des CAN-Rahmens zu nutzen sind;
5 veranschaulicht einen beispielhaften Abschnitt des Signalverfügbarkeitsdatenflusses der Entdeckungsphase;
6 veranschaulicht ein Beispiel für Details der Struktur der Signalverfügbarkeitsanforderungsmitteilung;
7 veranschaulicht einen beispielhaften Abschnitt des Signalverfügbarkeitsantwortdatenflusses der Entdeckungsphase;
8 veranschaulicht ein Beispiel für Details der Struktur der Signalverfügbarkeitsantwortmitteilung für ein Signal, das bereits über den CAN-Bus verfügbar ist;
9 veranschaulicht ein Beispiel für Details der Signalverfügbarkeitsantwortmitteilung für ein Signal, das neu über den CAN-Bus verfügbar ist;
10 veranschaulicht einen beispielhaften Abschnitt des Signalbandbreitenanalysedatenflusses der Entdeckungsphase;
11 veranschaulicht einen beispielhaften Prozess zum Antworten auf die Signalverfügbarkeitsanforderungsmitteilung mit der Signalverfügbarkeitsantwortmitteilung;
12 veranschaulicht ein Beispiel für Details der Mitteilungskennungszuweisungsmitteilung für ein Signal, das über den CAN-Bus verfügbar gemacht wurde;
13 veranschaulicht einen beispielhaften Abschnitt des Vertragsanbahnungsdatenflusses der Vertragseinrichtungsphase;
14 veranschaulicht ein Beispiel für Details der Vertragsmitteilung für ein Signal, das über den CAN-Bus verfügbar gemacht wurde;
15 veranschaulicht einen beispielhaften Abschnitt des Vertragsannahme-/- ablehnungsdatenflusses der Vertragseinrichtungsphase;
16 veranschaulicht ein Beispiel einer Antwortvertragsmitteilung;
17 veranschaulicht einen beispielhaften vollständigen Datenfluss für das Signalabonnementmodell;
18 veranschaulicht einen beispielhaften Abschnitt des Vertragsdetailsabfragedatenflusses des Vertragsabfragemodells;
19 veranschaulicht ein Beispiel einer Vertragsabfragemitteilung;
20 veranschaulicht einen beispielhaften Abschnitt des Vertragsdetailsabfrageantwortdatenflusses des Vertragsabfragemodells;
21 veranschaulicht ein Beispiel einer Vertragsabfrageantwortmitteilung;
22 veranschaulicht einen beispielhaften E/A-Steuerungsmodelldatenfluss;
23 veranschaulicht ein Beispiel einer E/A-Steuerungsanforderungsmitteilung;
24 veranschaulicht ein Beispiel einer negativen E/A-Steuerungsantwortmitteilung; und
25 veranschaulicht ein Beispiel einer positiven E/A-Steuerungsantwortmitteilung.

DETAILLIERTE BESCHREIBUNG
Nach Bedarf werden in dieser Schrift detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen umgesetzt werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details spezieller Komponenten zu zeigen. Daher sind in dieser Schrift offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um einen Fachmann den vielfältigen Einsatz der vorliegenden Erfindung zu lehren.
Dynamischer CAN-Mitteilungsversand bezieht sich auf eine Strategie, um CAN-Datenrahmen dynamisch zu erzeugen, zu senden und/oder deren Senden abzubrechen. In vielen Fällen kann ein CAN-Netzwerk auf eine streng konstruierte Weise eingerichtet sein, wobei das Netzwerk nicht dazu ausgelegt ist, dynamische Änderungen zu berücksichtigen. Ein Ergebnis eines derartigen Ansatzes ist, dass eine Änderung des Mitteilungsversands (z. B., um ein Signal hinzuzufügen, ein Signal zu entfernen, ein Signal zu ändern usw.) eine vollständige Softwareaktualisierung in Fahrzeugsteuerungen erfordern kann. Da drahtlose Aktualisierungen und aktualisierbare Fahrzeugkonfigurationen immer häufiger werden, kann es wünschenswert sein, dass der Mitteilungsversandinhalt entlang des CAN-Busses während einer Fahrzeuglebensdauer nicht mehr statisch bleibt. Um das CAN flexibler zu machen und derartige Aktualisierungen zu berücksichtigen, kann ein dienstorientiertes Architektur-(service-oriented architecture - SOA-) Modell der Datenübertragung über das CAN umgesetzt werden. Wie in dieser Schrift ausführlich erörtert, kann eine derartige Strategie dazu verwendet werden, dabei zu helfen, ein CAN von einem streng konstruierten Netzwerk zu einem adaptiven Echtzeitnetzwerk zu entwickeln.
Unter Verwendung von dynamischem CAN können Steuerungen neue CAN-Signale abonnieren, wenn dies gewünscht ist, und sich abmelden, wenn die Signale länger erforderlich sind. Unter Verwendung dieses Ansatzes kann das Senden neuer Signale dynamisch ausgehandelt werden. Jedem Signal in einer globalen Signaldatenbank aller Fahrzeug-CAN-Mitteilungen kann eine eindeutige Signalnummer zugewiesen werden. Ein Signalvermittler kann die Datenbank von Signalen pflegen und sicherstellen, dass die verfügbaren Datenelemente, für die jeder Sender verantwortlich ist, selektiv verfügbar gemacht werden können. Neue Signale können unter Verwendung dieser Signalnummern abonniert werden. Unter Verwendung des Abonnementansatzes können Vorlaufzeit und Kosten für das Aktualisieren der Sendersoftware verringert werden, wenn neue Merkmale entwickelt werden, die neue Signale erfordern. Weitere Aspekte der SOA für dynamische CAN sind in dieser Schrift ausführlich erörtert.
1 veranschaulicht ein beispielhaftes System 100, das ein erweitertes zentrales Gateway (ECG) 110 beinhaltet, das für dynamischen CAN-Mitteilungsversand konfiguriert ist. Das erweiterte zentrale Gateway 110 kann über einen oder mehrere Fahrzeugbusse 106 mit einer Vielzahl von elektronischen Steuerungseinheiten (ECUs) 104 verbunden sein. Das erweiterte zentrale Gateway 110 kann außerdem einen oder mehrere Diagnoseanschlüsse 108 beinhalten. Das erweiterte zentrale Gateway 110 kann einen Prozessor 112, einen Arbeitsspeicher 114 und einen Speicher 116 für einen Signalvermittler 118 und/oder Daten 120 beinhalten. Obwohl in 1 ein beispielhaftes System 100 gezeigt ist, sollen die beispielhaften Komponenten, wie sie veranschaulicht sind, nicht einschränkend sein. Tatsächlich kann das System 100 mehr oder weniger Komponenten aufweisen und es können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden.
Das Fahrzeug 102 kann verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländelimousinen (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 nur durch Elektromotoren angetrieben wird.
Das Fahrzeug 102 kann eine Vielzahl von elektronische Steuerungseinheiten (ECUs) 104 beinhalten, die dazu konfiguriert sind, verschiedene Funktionen des Fahrzeugs 102, die dem Einfluss der Batterie und/oder des Antriebsstrangs des Fahrzeugs unterliegen, durchzuführen und zu verwalten. Wie dargestellt, werden die beispielhaften Fahrzeug-ECUs 104 als einzelne ECUs 104-A bis 104-H dargestellt. Die Fahrzeug-ECUs 104 können jedoch derartig eine physische Hardware, Firmware und/oder Software gemeinsam haben, dass die Funktion mehrerer ECUs 104 in eine einzige ECU 104 integriert sein kann 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 zugeordneter Software, Firmware oder Konfigurationseinstellungen zu empfangen.
Einige nichteinschränkende Bespiele für Fahrzeug-ECUs 104: ein Antriebsstrangsteuermodul (powertrain control module - PCM) 104-A, das dazu konfiguriert sein kann, Motor- und Getriebekomponenten zu steuern; eine Steuerung eines Antiblockierbremssystems (antilock brake system - ABS) 104-B, die dazu konfiguriert ist, Brems- und Antriebsschlupfregelungskomponenten zu steuern; eine Steuerung einer elektrisch unterstützten Lenkung (electric power-assisted steering - EPAS) 104-C, die dazu konfiguriert ist, Steuerunterstützung und Zuganpassungs- oder Driftkompensationsfunktionen zu steuern; fortschrittliche Fahrerunterstützungssysteme (advanced driver assistance systems - ADAS) 104-D, wie etwa adaptive Abstands- und Geschwindigkeitsregelung oder automatisches Bremsen; und ein Scheinwerfersteuermodul (headlamp control module - HCM) 104-E, das dazu konfiguriert ist, Licht-Ein-/Aus-Einstellungen zu steuern. Die ECUs 104 können außerdem Folgendes beinhalten: andere Komponenten des Antriebsstrangs 104-F oder des Fahrgestells 104-G, ein Infotainment-System 104-H, das dazu konfiguriert ist, Sprachbefehle und BLUETOOTH-Schnittstellen mit dem Fahrer und Fahrerhandvorrichtungen zu unterstützen (z. B. das SYNC-System, das durch die Ford Motor Company in Dearborn, Michigan, USA, bereitgestellt wird), eine Konnektivitätssteuerung 104-I, wie etwa eine Telematiksteuerungseinheit (telematics control unit - TCU), die dazu konfiguriert ist, ein eingebettetes Modem zu nutzen, um auf vernetzte Vorrichtungen zuzugreifen, die sich außerhalb des Fahrzeugs 102 befinden, Steuerungen einer elektromechanischen Karosserie 104-J, wie etwa Fenster- oder Verriegelungsaktoren, und Komponenten einer Anhängersteuerung 104-K, wie etwa Lichtsteuerung und Sensordaten, um die verbundenen Anhänger zu unterstützen.
Der Fahrzeugbus 106 kann verschiedene Verfahren zur Kommunikation beinhalten, die zwischen den Fahrzeug-ECUs 104 verfügbar sind. Der Fahrzeugbus 106 kann außerdem die Kommunikation zwischen dem ECG 110 und den Fahrzeug-ECUs 104 unterstützen. Der Fahrzeugbus 106 kann ein Controller Area Network (CAN) des Fahrzeugs sein. Das CAN-Netzwerk kann aus verschiedenen Arten bestehen, die CAN mit hoher Geschwindigkeit (high speed CAN - HS-CAN), das eine Datenkapazität von bis zu 500 kbit/s aufweist, CAN mit mittlerer Geschwindigkeit (mid-speed 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, beinhalten, ohne darauf beschränkt zu sein. Es ist anzumerken, dass die veranschaulichte Bustopologie lediglich ein Beispiel ist und eine andere Anzahl und/oder andere Anordnungen von Fahrzeugbussen 106 verwendet werden können.
Das Fahrzeug 102 kann ferner Diagnoseanschlüsse 108 beinhalten, die durch externe Vorrichtungen verwendet werden können, um den Zustand des Fahrzeugs 102 zu überwachen.
In einem Beispiel kann der Diagnoseanschluss 108 ein fahrzeuginterner Diagnoseanschluss (on-board diagnostics port - OBD-Anschluss) sein, der mit dem Fahrzeugbus 106 verbunden ist. Ein Benutzer kann ein Dongle, eine Codelesevorrichtung oder andere Abtastvorrichtung mit dem Diagnoseanschluss 108 verbinden und kann die durch den Diagnoseanschluss 108 bereitgestellte Verbindung verwenden, um Zugriff auf Mitteilungen zu erhalten, die den Fahrzeugbus 106 durchqueren. Sobald sie verbunden ist, kann ein Benutzer die verbundene Abtastvorrichtung nutzen, um Diagnosecodes zu erfassen, den Fahrzeugzustand zu überwachen oder in einigen Fällen Fahrzeugeinstellungen anzupassen. In einem nichteinschränkenden Beispiel können die CAN-Diagnoseanschlüsse 108, ähnlich wie die Geschwindigkeit des HS-CAN, eine Datenkapazität von bis zu 500 kbit/s unterstützen. Andere beispielhafte Arten von Bussen des Diagnoseanschlusses 108 sind ebenfalls möglich.
Das ECG 110 kann dazu konfiguriert sein, eine elektrische Schnittstelle zwischen den Fahrzeugbussen 106 bereitzustellen, die dazu verwendet werden, innerhalb des Fahrzeugs 102 zu kommunizieren. In einem Beispiel kann das ECG 110 dazu konfiguriert sein, Signale und Befehle zwischen den CAN-Bussen 106, die mit dem ECG 110 verbunden sind, zu übersetzen. In einer nichteinschränkenden Möglichkeit kann das ECG 110 eine Verbindung mit bis zu zehn CAN-Fahrzeugbussen 206 unterstützen.
Als ein konkretes nichteinschränkendes Beispiel kann das ECG 110 mit Folgendem verbunden sein: über einen HS-CAN-Fahrzeugbus 106 mit den Komponenten des Antriebsstrangs 104-F; über einen zweiten HS-CAN-Fahrzeugbus 106 mit den Fahrgestellkomponenten 104-G, Sicherheitssystemen und einem Cluster; über einen dritten HS-CAN Fahrzeugbus 106 mit dem Infotainment-System 104-H; über einen vierten HS-CAN-Fahrzeugbus 106 mit dem Konnektivitätssystem 104-I und Ethernet-Sicherheitssicherungssystem; über einen ersten MS-CAN-Bus mit den Steuerungen der elektromechanischen Karosserie 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 eine zweite Verbindung eines Diagnosedaten-Fahrzeugdatenbusses 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. In einem anderen Beispiel sind Infotainment 104-H, Konnektivität 104-I, das Cluster 104-L, die Blickfeldanzeige 104-M und das ADAS 104-D jeweils über getrennte Fahrzeugbusse 106 mit dem ECG 110 verbunden. In noch einem anderen Beispiel kann die Blickfeldanzeige 104-M in das Cluster 104-L integriert sein.
Das ECG 110 kann ferner dazu konfiguriert sein, eine Rechenfunktion zur Unterstützung des Domänen-CAN-Mitteilungsversands des Fahrzeugs 102 bereitzustellen. Zum Beispiel kann das ECG 110 einen oder mehrere Prozessoren 112 beinhalten, die dazu konfiguriert sind, Anweisungen, Befehle und andere Abläufe zur Unterstützung der in dieser Schrift beschriebenen Prozesse durchzuführen. In einem Beispiel kann das ECG 110 dazu konfiguriert sein, Anweisungen des Signalvermittlers 118 auszuführen, die von einem Speichermedium 116 des ECG 110 auf einen Arbeitsspeicher 114 des ECG 110 geladen sind. Der Signalvermittler 118 kann Softwarecode beinhalten, der dazu programmiert ist, den dynamischen CAN-Mitteilungsversand zu unterstützen, die in dieser Schrift ausführlich erörtert ist. Die Daten 120 können Signal- und Vertragszuweisungsinformationen sowie andere Informationen zur Unterstützung des dynamischen CAN-Mitteilungsversands beinhalten.
Der Signalvermittler 118 und die Daten 120 können auf nichtflüchtige Weise unter Verwendung einer Reihe von Arten von computerlesbaren Speichermedien 116 gepflegt werden. Das computerlesbare Medium 116 (auch als ein durch den Prozessor lesbares Medium oder Speicher bezeichnet) beinhaltet ein nichttransitorisches (z. B. materielles) Medium, das beim Bereitstellen von Anweisungen oder anderen Daten beteiligt ist, die durch den Prozessor 112 des ECG 110 gelesen werden können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Reihe von Programmiersprachen und/oder -technologien hergestellt werden, die ohne Beschränkung und entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, JavaScript, Python, Perl und PL/SQL beinhalten. Als ein konkretes Beispiel kann das ECG 110 zum Verarbeiten von Leistung, um verschiedene Rechenaufgaben zu ermöglichen, mit mindestens 128 Megabyte RAM sowie 2-4 Kernen des Prozessors 112 vorgesehen sein.
2 veranschaulicht einen beispielhaften CAN-Datenrahmen 200, der dynamischen CAN-Mitteilungsversand unterstützt. Wie gezeigt, beinhaltet der CAN-Rahmen ein Start-of-Frame-Bit (SOF-Bit) 202, eine 11-Bit-CAN-ID 204, ein Remote-Übermittlungsanforderungs-(remote transmission request - RTR-)Bit 206, einen vorgehaltenen 2-Bit-Bereich und einen 4-Bit-Datenlängencode 208, ein Datenfeld 210 von bis zu 64 Bit, eine zyklische 16-Bit-Redundanzprüfung (cyclic redundancy check - CRC) 212, die einen 15-Bit-Code und ein 1-Bit-CRC-Trennzeichen beinhaltet, eine Bestätigung 214, die ein Bestätigungsbit und ein Bestätigungstrennzeichenbit beinhaltet, und eine 6-Bit-End-of-Frame-(EOF-)Markierung 216. Wie ferner in der Veranschaulichung gezeigt, ist der beispielhafte Abschnitt des Datenfelds 210 als Hexadezimalwerte dargestellt. Es ist anzumerken, dass die Werte des veranschaulichten Abschnitts des Datenfelds 210 rein beispielhaft sind und beliebige Daten verwendet werden können.
3 veranschaulicht eine beispielhafte Darstellung 300 des Datenfelds 210 des CAN-Datenrahmens 200, der in einzelne Bits unterteilt ist. Jede Spalte stellt ein Bit dar und jede Zeile ist ein Byte (Bit 0 bis Bit 7). Bytenr. 0 ist das erste Byte der Mitteilung, wobei Bit 0 das LSB ist und Bit 7 das MSB ist. In Übereinstimmung mit dem CAN folgt die Reihenfolge der Übermittlungsbits in dem Beispiel der Big-Endian-Konvention, d. h. das höchstwertige Bit in der Sequenz wird zuerst gespeichert und/oder gesendet. Im Allgemeinen können die ersten zwei Bytes des Datenfelds 210 als ein Header für den dynamischen CAN-Mitteilungsversand dienen, während der Rest der Bytes des Datenfelds 210 als die Mitteilungsnutzdaten dienen kann. Wie gezeigt, bilden die ersten drei Bits eine Datenstruktur-ID 302, die definiert, wofür die Mitteilung verwendet wird und was an den anderen Bitstellen zu erwarten ist.
Es ist anzumerken, dass in dieser beispielhaften Mitteilungsdarstellung 300 sowie für alle anderen Mitteilungsbeispiele in dieser Schrift zwar konkrete Werte und Reihenfolgen von Werten in den Datenstrukturen gezeigt sind, dies jedoch nur Beispiele sind und unterschiedliche Zuordnungen von Werten zu Funktionen und unterschiedliche Reihenfolgen von Feldern in Betracht gezogen werden und verwendet werden können. Als einige andere Möglichkeiten können mehrere der veranschaulichten Felder zu einem einzelnen Feld kombiniert werden, ein oder mehrere Felder können in andere Felder getrennt werden usw.
4 veranschaulicht eine beispielhafte Darstellung möglicher Datenstruktur-IDs 302, die in den ersten drei Bits des Datenabschnitts des CAN-Rahmens zu nutzen sind. Da in dem Beispiel für die Datenstruktur-IDs 302 drei Bits zugewiesen sind, können acht mögliche Werte durch die Datenstruktur-IDs 302 dargestellt werden. In dem veranschaulichten Beispiel bedeutet ein Wert von null eine Signalverfügbarkeitsmitteilung, bedeutet ein Wert von eins eine Mitteilungs-ID-Zuweisungsmitteilung, bedeutet ein Wert von zwei eine Vertragsmitteilung, bedeutet ein Wert von drei eine E/A-Steuerungsmitteilung, bedeutet ein Wert von vier bedeutet eine Konfigurationsmitteilung und bedeutet ein Wert von fünf eine Diagnosemitteilung. In dem veranschaulichten Beispiel werden die Werte von sechs und sieben nicht verwendet, können jedoch für eine zukünftige Verwendung verfügbar gemacht werden. Erneut können diese Auswahlen von Werten und die Menge von Bits in unterschiedlichen Umsetzungen variieren.
Ein Signalabonnementmodell kann dazu verwendet werden, Clients (manchmal in dieser Schrift als Anforderer bezeichnet) zu ermöglichen, Server (manchmal in dieser Schrift als Ressourcenbereitsteller bezeichnet) zu abonnieren. Der Signalabonnementansatz kann vier Phasen beinhalten: Entdeckung, Vertragseinrichtung, reguläre Mitteilungsübermittlung und Vertragsbeendigung. Die Entdeckungsphase kann einen Signalverfügbarkeitsanforderungsdatenfluss, einen Signalverfügbarkeitsantwortdatenfluss und einen Signal-zu-Mitteilungs-ID-Zuweisungsdatenfluss beinhalten. Die Vertragseinrichtungsphase kann einen Vertragseinrichtungsdatenfluss und einen Vertragsannahme-/-ablehnungsdatenfluss beinhalten. Die Phase der regulären Mitteilungsübermittlung kann dann durchgeführt werden, sobald der Vertrag eingerichtet ist. Die Vertragsbeendigungsphase kann einen Vertragsabschlussanforderungsdatenfluss beinhalten. Jede dieser Phasen wird der Reihe nach in den 5-17 erörtert.
5 veranschaulicht einen beispielhaften Abschnitt des Signalverfügbarkeitsdatenflusses 500 der Entdeckungsphase. Der Signalverfügbarkeitsdatenfluss 500 kann dazu verwendet werden, einem Client 502 zu ermöglichen, zu bestimmen, ob ein angefordertes Signal von einem Server 504 verfügbar ist. In einem Beispiel kann der Client eine der ECUs 104 sein und der Server 504 kann eine andere der ECUs 104 sein. Der Client 502 kann eine Signalverfügbarkeitsanforderungsmitteilung 506, die nach Signalverfügbarkeit fragt, an das ECG 110 senden. Als Reaktion auf den Empfang der Mitteilung 506 kann das ECG 110 die Signalverfügbarkeitsmitteilung 506 an alle CAN-Busse 106 weiterleiten, die mit dem ECG 110 verbunden sind.
6 veranschaulicht ein Beispiel für Details der Struktur 600 der Signalverfügbarkeitsanforderungsmitteilung 506. Das Format der beispielhaften Struktur 600 ist einheitlich mit der Veranschaulichung der Darstellung 300 des Datenfelds 210 des CAN-Datenrahmens 200 gezeigt, der in einzelne Bits unterteilt ist. Es ist erneut anzumerken, dass zwar konkrete Werte und Reihenfolgen von Werten in der Struktur 600 gezeigt sind, dies jedoch nur ein Beispiel ist und unterschiedliche Zuordnungen von Werten zu Funktionen und unterschiedliche Reihenfolgen von Feldern verwendet werden können.
Wie zuvor erörtert, kann die Datenstruktur-ID 302 durch die ersten drei Bits des Datenfelds 210 angegeben sein. Zusätzlich können die nächsten fünf Bits des Datenfelds 210 eine eindeutige Anforderungsnummer 602 beinhalten. Die eindeutige Anforderungsnummer 602 kann ein eindeutiger Wert sein, wie etwa ein zunehmender Wert oder ein Zufallswert, der für die Signalverfügbarkeitsanforderungsmitteilung 506 konkret ist. Diese Anforderungsnummer 602 kann dazu verwendet werden, konkreten Anforderungen zu ermöglichen, ohne Weiteres verfolgt zu werden und/oder dass durch die Parteien entlang der Busse 106 darauf zugegriffen werden kann.
Die nächsten zwei Bits des Datenfelds 210 können eine Sendeart 604 beinhalten. Die Sendeart 604 kann eine Art der Übermittlung angeben. In dem veranschaulichten Beispiel kann ein Wert von null eine Mitteilung angeben, die einmal gesendet wird, ein Wert von eins kann eine Mitteilung angeben, die auf eine Änderung reagiert, ein Wert von zwei kann eine feststehende Periodenzeit zum Senden der Mitteilung angeben und ein Wert von drei kann eine Mitteilung angeben, die periodisch als Reaktion auf ein Ereignis gesendet wird.
Die nächsten zwei Bits des Datenfelds 210 können einen Spezifizierer einer Flusssteuerung 606 beinhalten. Zum Beispiel kann ein Wert von 0 angeben, dass eine schnellste Dienstqualität angefordert wird, kann ein Wert von 1 eine Dienstqualität von 100 Millisekunden (ms) angeben, kann ein Wert von 3 angeben, dass eine Dienstqualität von 500 ms angefordert wird, und kann ein Wert von 4 angeben, dass eine Dienstqualität von 1.000 ms angefordert wird.
Die nächsten zwei Bits des Datenfelds 210 können vorgehalten sein. Das nächste Bit des Datenfelds 210 kann eine Abfrageart 608 der Mitteilung angeben. Zum Beispiel kann ein Wert von null eine Anforderungsmitteilung angeben und ein Wert von eins kann eine Antwortmitteilung angeben. Das nächste Bit des Datenfelds 210 kann vorgehalten sein.
Die folgenden Bits des Datenfelds 210 können Details des Signals 610 der Signalverfügbarkeitsanforderungsmitteilung 506 beinhalten. Zum Beispiel können die nächsten 16 Bits eine Kennung eines Signals 610 angeben. Das Signal 610 kann als eine 15-Bit-Kennung plus ein vorgehaltenes Bit festlegt werden (das später verwendet werden kann, wie in 9 gezeigt). In einigen Beispielen können mehrere Signale 610 durch die Signalverfügbarkeitsanforderungsmitteilung 506 festgelegt sein. Zum Beispiel können weitere 16 Bits des Datenfelds 210 eine zweite Kennung eines zweiten Signals 610 angeben, dessen Verfügbarkeit angefordert wird.
7 veranschaulicht einen beispielhaften Abschnitt des Signalverfügbarkeitsantwortdatenflusses 700 der Entdeckungsphase. Der Signalverfügbarkeitsantwortdatenfluss 700 kann dazu verwendet werden, einem Client 502 zu ermöglichen, eine Signalverfügbarkeitsantwort 702 zu empfangen, ob ein angefordertes Signal aktuell von dem Server 504 verfügbar ist oder von dem Server 504 verfügbar gemacht werden könnte. Als Reaktion auf den Empfang der Signalverfügbarkeitsanforderungsmitteilung 506 kann der Server 504 einen Prozess 1100, wie in 11 gezeigt, zum Bestimmen durchführen, ob auf die Signalverfügbarkeitsanforderungsmitteilung 506 geantwortet werden soll. Wenn das Signal (oder die Signale), das oder die in der Signalverfügbarkeitsanforderungsmitteilung 506 festlegt ist/sind, über den Server 504 verfügbar ist/sind, kann die Signalverfügbarkeitsantwortmitteilung 702 von dem Server 504 zurück an den Client 502 gesendet werden.
8 veranschaulicht ein Beispiel für Details der Struktur der Signalverfügbarkeitsantwortmitteilung 702 für ein Signal 610, das bereits über den CAN-Bus 106 verfügbar ist. Das Format der beispielhaften Struktur 800 ist einheitlich mit der Veranschaulichung der Darstellungen 300 und 600 des Datenfelds 210 des CAN-Datenrahmens 200 gezeigt.
Ähnlich wie die Signalverfügbarkeitsanforderungsmitteilung 506 beinhaltet der Header der Signalverfügbarkeitsantwortmitteilung 702 die Datenstruktur-ID 302. Der Header der Signalverfügbarkeitsantwortmitteilung 702 kann auch die eindeutige Anforderungs-ID 602 und die Abfrageart 608 der Signalverfügbarkeitsanforderungsmitteilung 506 beinhalten, auf welche die Signalverfügbarkeitsantwortmitteilung 702 eine Antwort ist. Dies kann es dem Client 502 ermöglichen, Antworten 702 ohne Weiteres mit Anforderungen 506 abzugleichen.
Wie ferner gezeigt, beinhaltet der Header der Signalverfügbarkeitsantwortmitteilung 702 ein Bit der Verfügbarkeitsart 801, das im Allgemeinen festlegt, ob das Signal 610 neu verfügbar ist oder alternativ bereits über das CAN verfügbar war. Für die veranschaulichte Mitteilung würde die Verfügbarkeitsart 801 angeben, dass dies ein vorhandenes verfügbares Signal 610 ist.
Die folgenden Bits des Datenfelds 210 können Details des Signals 610 der Signalverfügbarkeitsantwortmitteilung 702 beinhalten. Zum Beispiel können die nächsten 16 Bits die Kennung des Signals 610 angeben, auf das geantwortet wird. Zusätzlich können die Nutzdaten des Datenfelds 210 ferner eine Bitposition 802 innerhalb einer CAN-Mitteilung und eine Mitteilungs-ID 804 einer derartigen CAN-Mitteilung beinhalten, die zusammen einen aktuellen Standort des angeforderten Signals 610 über den CAN-Bus 106 festlegen. Ein Empfänger der Signalverfügbarkeitsantwortmitteilung 702 kann daher den angeforderten Wert durch Überwachen des CAN-Busses auf die festlegte Mitteilungs-ID 804 und dann Überprüfen der Bitposition 802 dieser CAN-Mitteilung abrufen.
9 veranschaulicht ein Beispiel für Details der Signalverfügbarkeitsantwortmitteilung 702 für ein Signal 610, das neu über den CAN-Bus 106 verfügbar ist. Im Vergleich zu der Signalverfügbarkeitsantwortmitteilung 702, die in 8 gezeigt ist, würde die Verfügbarkeitsart 801 in 9 angeben, dass dies ein neu verfügbares Signal 610 ist. Zusätzlich können die Mitteilungsnutzdaten die 15-Bit-Kennungen des Signals 610 (oder der Signale 610) beinhalten, von denen angefordert wird, dass sie verfügbar gemacht werden, wobei das vorgehaltene 16. Bit festlegt, ob dieses konkrete Signal 610 verfügbar gemacht werden kann oder nicht (z. B. 1 für ja, 0 für nein).
10 veranschaulicht einen beispielhaften Abschnitt des Signalbandbreitenanalysedatenflusses 1000 der Entdeckungsphase. Der Signalbandbreitenanalysedatenfluss 1000 kann dazu verwendet werden, dem ECG 110 zu ermöglichen, dem Client 502 zu bestätigen, dass das angeforderte Signal 610 innerhalb der Fähigkeiten des Systems liegt, die durch den Server 504 bereitzustellen sind. Wie gezeigt, kann das ECG 110 die Bandbreite auf dem CAN-Bus 106 zwischen dem Server 504 und dem Client 502 analysieren. Wenn die Bandbreitennutzung des Busses 106 geringer als ein vordefinierter Betrag ist (zusätzliche Bandbreite ist für das Signal 610 verfügbar), dann kann das ECG 110 eine neue CAN-Mitteilungs-ID, eine zulässige Rate und eine Vertragsnummer (nachstehend ausführlicher erörtert) für das Signal 610 zuweisen. Diese Informationen können in einer Mitteilungskennungszuweisungsmitteilung 1202 an den Client 502 und den Server 504 kommuniziert werden, wie in 12 gezeigt.
11 veranschaulicht einen beispielhaften Prozess 1100 zum Antworten auf die Signalverfügbarkeitsanforderungsmitteilung 506 mit der Signalverfügbarkeitsantwortmitteilung 702. In einem Beispiel kann der Prozess 1100 durch einen Server 504 im Rahmen des offenbarten Systems 100 durchgeführt werden, welches das ECG 110 und den Client 502 beinhaltet.
Wie in Vorgang 1102 gezeigt, kann der Client 502 eine Signalverfügbarkeitsanforderungsmitteilung 506, die nach Signalverfügbarkeit fragt, an das ECG 110 senden. Als Reaktion auf den Empfang der Mitteilung 506 kann das ECG 110 die Signalverfügbarkeitsmitteilung 506 an alle CAN-Busse 106 weiterleiten, die mit dem ECG 110 verbunden sind. Diese Mitteilung kann durch den Server 504 empfangen werden, der mit einem der CAN-Busse 106 verbunden ist.
Bei Vorgang 1104 bestimmt der Server 504, ob die Nummer des Signals 610 aus der Signalverfügbarkeitsanforderungsmitteilung 506 übermittelt wird. Wenn das Signal 610 keines ist, das verfügbar ist oder durch den Server 504 gesendet wird, ergreift der Server 504 keine Maßnahme, wie bei Vorgang 1106 gezeigt. Wenn das Signal 610 j edoch eines ist, das verfügbar ist oder durch den Server 504 gesendet wird, geht die Steuerung zu Vorgang 1108 über.
Bei Vorgang 1108 bestimmt der Server 504, ob das Signal 610 aktuell durch den Server 504 gesendet wird. Zum Beispiel kann das Signal 610 bereits durch einen anderen Client 502 zur Übermittlung über den CAN-Bus 106 angefordert worden sein. Wenn dies der Fall ist, geht die Steuerung zu Vorgang 1110 über, um eine Signalverfügbarkeitsantwortmitteilung 702 zu senden, die angibt, dass das Signal 610 bereits verfügbar ist. Ein Beispiel für eine derartige Mitteilung 702 ist vorstehend unter Bezugnahme auf 8 erörtert. Nach Vorgang 1110 endet der Prozess 1100. Wenn das Signal 610 jedoch aktuell nicht durch den Server 504 gesendet wird, geht die Steuerung zu Vorgang 1112 über.
Bei Vorgang 1112 bestimmt der Server 504, ob Ressourcen auf dem Server 504 verfügbar sind, um das angeforderte Signal 610 zu senden. In einem Beispiel kann das ECG 110 sicherstellen, dass Bandbreite zum Senden des Signals 610 zwischen dem Client 502 und dem ECG 110 sowie zwischen dem Server 504 und dem ECG 110 verfügbar ist. Wenn dies der Fall ist, werden eine neue CAN-Mitteilungs-ID, eine zulässige Rate und eine Vertragsnummer für das Signal 610 durch den Server 504 empfangen, wie sie von dem ECG 110 gesendet wurden, wie unter Bezugnahme auf 10 angemerkt.
Somit geht die Steuerung, wenn Netzwerkressourcen verfügbar sind, zu Vorgang 1114 über, um eine Signalverfügbarkeitsantwortmitteilung 702 zu senden, die angibt, dass das Signal 610 jetzt verfügbar ist. Ein Beispiel für eine derartige Mitteilung 702 ist vorstehend unter Bezugnahme auf 9 erörtert. Wenn keine Netzwerkressourcen verfügbar sind, geht die Steuerung zu Vorgang 1116 über, bei dem der Server 504 (oder das ECG 110) eine Signalverfügbarkeitsantwortmitteilung 702 sendet, die angibt, dass der Server 504 zum aktuellen Zeitpunkt oder für aktuelle Bedingungen des Busses 106 nicht in der Lage ist, das Signal 610 bereitzustellen.
12 veranschaulicht ein Beispiel für Details der Mitteilungskennungszuweisungsmitteilung 1202 für ein Signal 610, das über den CAN-Bus 106 verfügbar gemacht wurde. Als Reaktion darauf, dass das ECG 110 die Mitteilungs-ID zuweist, um das Signal 610 zu packen, das in der Entdeckungsphase angefordert wurde, kann das ECG 110 den ECUs 104 die Mitteilungskennungszuweisungsmitteilung 1202 bereitstellen.
Wie gezeigt, beinhaltet die Mitteilungskennungszuweisungsmitteilung 1202 die Datenstruktur-ID 302, die eindeutige Anforderungsnummer 602, die Sendeart 604, die Flusssteuerung 606 und die Mitteilungs-ID 804, wie vorstehend erörtert. Die Mitteilungskennungszuweisungsmitteilung 1202 kann ferner eine Vertragsnummer 1204 in dem Headerabschnitt des Datenfelds 210 beinhalten, die eine eindeutige Kennung des auszuhandelnden Vertrags festlegt, wie durch das ECG 110 bereitgestellt. Die Mitteilungskennungszuweisungsmitteilung 1202 kann auch eine Anfordererknotenkennung 1206 angeben, die eine Kennung des Clients 502 ist, sowie eine Ressourcenbereitstellerknotenkennung 1208, die eine Kennung des Servers 504 ist.
13 veranschaulicht einen beispielhaften Abschnitt des Vertragsanbahnungsdatenflusses 1300 der Vertragseinrichtungsphase. Als Reaktion auf das Empfangen der Mitteilungskennungszuweisungsmitteilung 1202 handelt der Server 504 den Vertrag mit dem Anforderer-Client 502 aus, um Mitteilungsdetails, wie etwa Geschwindigkeit, Periodizität und die Bitposition des Signals 610 innerhalb des CAN-Mitteilungsdatenfelds 210, zu bestätigen. Diese Informationen können von dem Server 504 in einer Vertragsmitteilung 1302 an den Client 502 kommuniziert werden.
14 veranschaulicht ein Beispiel für Details der Vertragsmitteilung 1302 für ein Signal 610, das über den CAN-Bus 106 verfügbar gemacht wurde. Verschiedene Details der Vertragseinrichtungsmitteilung 1302, wie etwa die Datenstruktur-ID 302, die Sendeart 604, die Flusssteuerung 606, die Signalnummer 610 und die Bitposition 802, wurden erörtert. Besonders hervorzuheben ist jedoch die Vertragsnummer 1204 im Header, die eine eindeutige Kennung des Vertrags, wie sie durch das ECG 110 bereitgestellt wird, sowie die Vertragsart 1404 festlegt. Die Vertragsart 1404 kann einen Aspekt der Art der bereitgestellten Vertragseinrichtungsmitteilung 1302 festlegen. Zum Beispiel kann ein Wert von null eine Einrichtungsmitteilung angeben, kann ein Wert von eins eine Annahmemitteilung angeben, kann ein Wert von zwei eine Abschlussmitteilung angeben und kann ein Wert von drei eine Abfragemitteilung angeben.
15 veranschaulicht einen beispielhaften Abschnitt des Vertragsannahme-/- ablehnungsdatenflusses 1500 der Vertragseinrichtungsphase. Als Reaktion auf den Empfang der Vertragsmitteilung 1302 durch den Client 502, wie sie in dem Vertragsanbahnungsdatenfluss 1300, wie in 13 gezeigt, gesendet ist, sendet der Client 502 eine Vertragsmitteilung 1302 als Reaktion auf Annehmen oder Ablehnen der vorgeschlagenen Bedingungen in der Vertragsanforderungsmitteilung 1302.
16 veranschaulicht ein Beispiel einer Antwortvertragsmitteilung 1302. Ähnlich wie unter Bezugnahme auf 14 erörtert, werden die Details der Vertragsmitteilung 1302 bereitgestellt. In dem Beispiel hier kann die Vertragsart 1404 für eine Annahme der Anforderung der Art Einrichtung der Vertragsmitteilung 1302 auf Annehmen eingestellt sein und kann auf Abschließen eingestellt sein, wenn die Anforderung der Vertragsmitteilung 1302 für den Client 502 nicht akzeptabel ist.
17 veranschaulicht einen beispielhaften vollständigen Datenfluss 1700 für das Signalabonnementmodell. Wie gezeigt, beinhaltet der Datenfluss 1700 die vorstehend erörterten Phasen des Entdeckens 1301 und der Vertragseinrichtung 1302 sowie die reguläre Mitteilungsübermittlung und die Vertragsbeendigung. Um das Signalabonnement anzubahnen, kann der Client 502 eine Signalverfügbarkeitsanforderungsmitteilung 506, die nach Verfügbarkeit eines oder mehrerer Signale 610 fragt, an das ECG 110 senden. Als Reaktion auf den Empfang der Signalverfügbarkeitsanforderungsmitteilung 506 kann das ECG 110 die Signalverfügbarkeitsanforderungsmitteilung 506 an alle CAN-Busse 106 weiterleiten, die mit dem ECG 110 verbunden sind. Der Server 504, der das eine oder die mehreren Signale 610 bereitstellt, kann mit einer Signalverfügbarkeitsantwortmitteilung 702 antworten, welche die Verfügbarkeit angibt. Das ECG 110 kann die Signalverfügbarkeitsantwortmitteilung 702 empfangen und kann die CAN-Mitteilungs-ID, die zulässige Rate und die Vertragsnummer für das Signal 610 zwischen dem Client 502 und dem Server 504 aushandeln. Als Reaktion auf die Aushandlung kann der Server 504 eine Vertragsmitteilung 1302 senden, um den Vertrag mit dem Client 502 einzurichten. Als Reaktion auf den Empfang der Vertragsmitteilung 1302 von dem Server 504 kann der Client 502 als Reaktion auf Annehmen oder Ablehnen des Vertrags eine Vertragsmitteilung 1302 senden. Bei Annahme kann der Server 504 damit beginnen, das Signal 610 über den CAN-Bus 106 unter Verwendung der zugewiesenen Mitteilungs-ID zu übermitteln. Dies ist als regulärer Mitteilungsversand 1702 gezeigt. Als Reaktion darauf, dass der Client 502 das Signal 610 nicht mehr erfordert, kann der Client 502 eine Vertragsmitteilung 1302 an das ECG 110 senden, die anfordert, die Übermittlung des Signals 610 abzuschließen, wie bei 1704 gezeigt. Als Reaktion auf den Empfang der Vertragsabschlussmitteilung 1302 kann das ECG 110 eine Vertragsabschlussmitteilung 1302 an den Server 504 senden, welche die Vertrags-ID beinhaltet und anfordert, dass der Server 504 das Senden des Signals 610 abbricht. Dies kann dementsprechend den Server 504 veranlassen, die Übermittlung des Signals 610 abzubrechen.
Zusätzlich zu dem Signalabonnementmodell kann das System 100 auch ein Vertragsabfragemodell unterstützen. Das Vertragsabfragemodell kann dazu verwendet werden, die dynamischen CAN-Mitteilungen zu decodieren, die von einem Server 504 zu Fehlerbehebungs- oder Datenprotokollierungszwecken gesendet wurden. Dieses Vertragsabfragemodell ist unter Bezugnahme auf die 18-21 erörtert.
18 veranschaulicht einen beispielhaften Abschnitt des Vertragsdetailsabfragedatenflusses 1800 des Vertragsabfragemodells. Wie gezeigt, kann die Kommunikation zwischen einer Prüf- oder Datenprotokollierungsvorrichtung 1802 und dem ECG 110 erfolgen. In einem Beispiel kann die Prüf- oder Datenprotokollierungsvorrichtung 1802 eine OBD-II-Prüfvorrichtung sein, die mit dem Diagnoseanschluss 108 des Netzwerks verbunden ist. In einem anderen Beispiel kann die Prüf- oder Datenprotokollierungsvorrichtung 1802 eine der ECUs 104 des Fahrzeugs 102 sein. Die Prüf- oder Datenprotokollierungsvorrichtung 1802 kann eine Vertragsmitteilung 1302 mit einer Vertragsart 1404 der Abfrage an das ECG 110 senden.
19 veranschaulicht ein Beispiel einer Vertragsabfragemitteilung 1302. Ähnlich wie unter Bezugnahme auf 14 erörtert, ist eine Vertragsmitteilung 1302 gezeigt. In dem Beispiel hier kann die Vertragsart 1404 auf Abfrage eingestellt sein, kann die Abfrageart 608 auf Anforderung eingestellt sein, kann die eindeutige Anforderungsnummer 602 auf einen eindeutigen Wert eingestellt sein und kann die Datenstruktur-ID 302 auf Vertrag eingestellt sein.
20 veranschaulicht einen beispielhaften Abschnitt des Vertragsdetailsabfrageantwortdatenflusses 2000 des Vertragsabfragemodells. Wie gezeigt, kann das ECG 110 als Reaktion auf die Vertragsabfragemitteilung 1302, die in 18 gesendet wurde, mit einer Vertragsabfrageantwortmitteilung 1302 antworten, welche die Vertragsdetails beinhaltet.
21 veranschaulicht ein Beispiel einer Vertragsabfrageantwortmitteilung 1302. Wenn die Vertragsabfrageantwortmitteilung 1302 eine gültige Antwort angibt, kann das Bit der DNE 2102 auf falsch eingestellt sein. Wenn die Vertragsabfrageantwortmitteilung 1302 jedoch angibt, dass der angeforderte Vertrag nicht vorhanden ist, dann kann das Bit der DNE 2102 auf wahr eingestellt sein. Wenn es wahr ist, können die Vertragsart und andere Informationen in der Vertragsabfrageantwortmitteilung 1302 ignoriert werden.
Ähnlich wie unter Bezugnahme auf 16 erörtert, kann für eine gültige Antwort in dem Headerabschnitt des dynamischen CANs der Datenfelder 210 die Mitteilung die Datenstruktur-ID 302 auf Vertrag eingestellt sein, kann die Vertragsnummer 1204 auf die Nummer eingestellt sein, die der angeforderten Mitteilungs-ID 804 entspricht, kann die Sendeart 604 auf die für den Vertrag festlegten Sendeinformationen eingestellt sein, kann die Flusssteuerung 606 auf den für den Vertrag eingestellten Flussparameter eingestellt sein, kann die Vertragsart 1404 auf Abfrage eingestellt sein und kann die Abfrageart 608 auf Antwort eingestellt sein. In dem Bodyabschnitt der Datenfelder 210 kann die Vertragsabfrageantwortmitteilung 1302 die Signalnummer 610 des Signals sowie die Bitposition 802 innerhalb des Signals des Werts beinhalten, wobei diese Werte wie vorstehend erörtert sind.
Zusätzlich zu dem Signalabonnementmodell und dem Vertragsabfragemodell kann das System 100 auch ein E/A-Steuerungsmodell unterstützen. Das E/A-Steuerungsmodell kann für ereignisbasierte Aufgaben verwendet werden (z. B., um Scheinwerfer aus der Ferne einzuschalten). Dieses E/A-Steuerungsmodell ist unter Bezugnahme auf die 22-25 erörtert.
22 veranschaulicht einen beispielhaften E/A-Steuerungsmodelldatenfluss 2200. Dieses Modell beinhaltet drei Phasen, Entdeckung, Steuerungsanforderung und Antwort auf die Anforderung. Die Entdeckungsphase kann durch das ECG 110 angebahnt werden. Zum Beispiel kann die Entdeckungsphase als Reaktion auf den Abschluss des Baus des Fahrzeugs 102 am Ende der Strecke in einer Fabrik angebahnt werden. In einem anderen Beispiel kann die Entdeckungsphase zu einem oder mehreren vorläufigen Zeitpunkten während des Baus des Fahrzeugs 102 angebahnt werden. In noch einem anderen Beispiel kann die Entdeckungsphase als Reaktion auf eine Softwareaktualisierung angebahnt werden, die in dem Fahrzeug installiert wird (z. B. unter der Leitung des ECG 110 in einer ECU 104 installiert wird).
In der Entdeckungsphrase kann das ECG 110 eine E/A-Entdeckungsmitteilung an jede der ECUs 104 senden. Die ECUs 104 können dem ECG 110 antworten, das eine Liste aller verfügbaren E/A an dem Fahrzeug 102 pflegen kann.
23 veranschaulicht ein Beispiel einer E/A-Steuerungsanforderungsmitteilung 2302. Unter fortgeführter Bezugnahme auf 22 kann der Client 502 in der Steuerungsanforderungsphase eine E/A-Steuerungsanforderungsmitteilung 2302 an das ECG 110 senden. Als Reaktion auf den Empfang der E/A-Steuerungsanforderungsmitteilung 2302 kann das ECG 110 des Fahrzeugs die E/A-Steuerungsanforderungsmitteilung 2302 an den CAN-Bus 106 weiterleiten, mit dem der richtige Server 504 verbunden ist.
24 veranschaulicht ein Beispiel einer negativen E/A-Steuerungsantwortmitteilung 2402. 25 veranschaulicht ein Beispiel einer positiven E/A-Steuerungsantwortmitteilung 2502. Unter fortgeführter Bezugnahme auf 22 kann der Server 504 in der Antwort auf die Anforderungsphase eine negative E/A-Steuerungsantwortmitteilung 2402 oder eine positive E/A-Steuerungsantwortmitteilung 2502 an das ECG 110 zurücksenden, die wiederum zurück an den Client 502 weitergeleitet werden können.
Im Einzelnen Bezug nehmend auf 23 ist eine beispielhafte E/A-Steuerungsanforderungsmitteilung 2302 gezeigt. Der Client 502 kann die E/A-Steuerungsanforderungsmitteilung 2302 senden, um eine E/A-Anforderung anzubahnen. Wie gezeigt, sind die Datenstruktur-ID 302 und die eindeutige Anforderungsnummer 602 wie zuvor erörtert.
Zusätzlich kann ein Feld für die Steuerungsart 2304, das in dem Headerabschnitt des Datenfelds 210 beinhaltet ist, dazu verwendet werden, eine Art der E/A-Steuerungsanforderungsmitteilung 2302 festzulegen. Diese Steuerungsarten können zum Beispiel eine E/A-Anforderungsart, eine Art zum Anfordern eines Werts, eine Art zum Angeben in einer Antwort, dass die Anforderung positiv abgeschlossen wurde, und eine Art zum Angeben eines negativen Ergebnisses beinhalten.
Der Headerabschnitt des Datenfelds 210 kann außerdem eine Anforderungsart 2306 beinhalten. Die Anforderungsart kann ein Bit sein, das verwendet wird, um zwischen zwei Werten anzugeben, wie etwa, ob das angeforderte E/A-Merkmal anzuschalten oder abzuschalten ist. Wenn eine größere Menge an Werten für das E/A-Merkmal erforderlich ist, dann kann ferner eine erweiterte Anforderungsart 2308 in dem Header beinhaltet sein. Zum Beispiel kann die erweiterte Anforderungsart 2308 5 Bits beinhalten, um 32 eindeutige Kombinationen für individuelle Anforderungen zu ermöglichen. In einem derartigen Fall kann eine Anforderungslänge 2310 in dem Nutzdatenabschnitt des Datenfelds 210 festgelegt werden, die festlegt, wie lang die erweiterte Anforderungsart 2308 in Bits ist. In einigen Beispielen kann, wenn die erweiterte Anforderungsart 2308 ungleich null ist, die Anforderungsart 2306 ignoriert werden und die erweiterte Anforderungsart 2308 kann stattdessen verwendet werden. In einem konkreten Beispiel können das vierte und fünfte Byte des Datenfelds 210 Daten, wie etwa Positions-/Winkelwerte, für eine konkrete erweiterte Anforderungsart 2308 festlegen.
Das Parameternummernfeld 2311 kann ein Feld in den Nutzdaten des Datenfelds 210 sein und kann sich auf eine eindeutige Nummer beziehen, die der angeforderten steuerbaren E/A zugewiesen ist. In einem Beispiel können die Parameternummern von vorhandenen Signalen, Datenkennungen (data identifiers - DIDs) oder Parameterkennungen (parameter identifiers - PIDs) der ECUs 104 abgeleitet sein. In einem anderen Beispiel können die Parameternummern pro Modul individuell zugewiesen sein. Ein beispielhafter DID/PID-Diagnosemechanismus ist in SAE J1979 definiert und ermöglicht es einer ECU 104, einen vordefinierten Satz von Informationen an einer Adresse bereitzustellen, die über ein Diagnoseverfahren aufgerufen werden kann. DIDs können Informationen enthalten, die einen Einblick in Systemstatus und - leistung bereitstellen. Das Parameternummernfeld 2311 kann dementsprechend in einigen Umsetzungen bestehende DID- und/oder PID-Spezifizierer beinhalten.
Eine Anforderungsquelle 2312 kann ebenfalls als ein Feld in den Nutzdaten des Datenfelds 210 beinhaltet sein. Die Anforderungsquelle 2312 kann festlegen, ob die E/A-Steuerungsanforderungsmitteilung 2302 von dem Fahrzeug 102 stammt oder von außerhalb des Fahrzeugs 102 empfangen wurde, wie etwa von einem Cloud-Server.
Ein Feld einer zyklischen Redundanzprüfung (CRC) 2314 und ein Feld eines Zählers 2316 können optional ebenfalls in den Nutzdaten des Datenfelds 210 beinhaltet sein. Das CRC- und das Zählerfeld können dazu verwendet werden, dem Empfänger der E/A-Steuerungsanforderungsmitteilung 2302 zu ermöglichen sicherzustellen, dass die Felder ohne Netzwerkfehler korrekt empfangen werden, und um einen Ende-zu-Ende-(E2E-)Schutz für die Übermittlung der E/A-Steuerungsanforderungsmitteilung 2302 bereitzustellen.
Wie vorstehend angemerkt, kann die E/A-Steuerungsanforderungsmitteilung 2302 eine negative Antwortart, was bedeutet, dass die Anforderung der E/A-Steuerungsanforderungsmitteilung 2302 nicht in der Lage war, abgeschlossen zu werden, oder eine positive Antwortart aufweisen, was bedeutet, dass die Bearbeitung der E/A-Steuerungsanforderungsmitteilung 2302 erfolgreich abgeschlossen wurde.
Unter besonderer Bezugnahme auf 24 ist, wie vorstehend angemerkt, eine beispielhafte negative E/A-Steuerungsantwortmitteilung 2402 veranschaulicht. Wie gezeigt, sind die Datenstruktur-ID 302 und die eindeutige Anforderungsnummer 602 wie zuvor erörtert. Die Steuerungsart 2304, die vorstehend in der Erörterung der E/A-Steuerungsanforderungsmitteilung 2302 erwähnt wurde, kann festlegen, dass dies eine negative Antwort ist.
Zusätzlich kann ein Feld der Antwortart 2404 einen Code oder Grund angeben, warum die Antwort negativ war. Zum Beispiel kann die Antwortart 2404 angeben, dass die Anforderung ungültig war, dass das E/A-Merkmal deaktiviert ist oder nicht unterstützt wird, dass die E/A-Funktion fehlgeschlagen ist, dass die E/A-Funktion ausgelastet ist oder verwendet wird, dass ein Fehler aufgetreten ist, als versucht wurde, die E/A-Funktion durchzuführen, dass die Anforderung, die E/A-Funktion zu verwenden, abgelehnt wurde, dass die E/A-Funktion aussteht usw.
Unter besonderer Bezugnahme auf 25 ist eine beispielhafte positive E/A-Steuerungsantwortmitteilung 2502 veranschaulicht. Wie gezeigt, sind die Datenstruktur-ID 302 und die eindeutige Anforderungsnummer 602 wie zuvor erörtert. Die Steuerungsart 2304, die vorstehend in der Erörterung der E/A-Steuerungsanforderungsmitteilung 2302 erwähnt wurde, kann festlegen, dass dies eine positive Antwort ist. Die Nutzdaten des Datenfelds 210 können auch den Parameter 2310 festlegen, wie für die E/A-Steuerungsanforderungsmitteilung 2302 angemerkt, sowie optional eine CRC 2314 und/oder einen Zähler 2316 festlegen, wie für die E/A-Steuerungsanforderungsmitteilung 2302 angemerkt.
Zusätzlich kann die positive E/A-Steuerungsantwortmitteilung 2502 einen endgültigen Wert oder Zustand 2504 als Reaktion auf den Abschluss des Verarbeitens der E/A-Steuerungsanforderungsmitteilung 2302 festlegen. Wenn zum Beispiel die E/A-Steuerungsanforderungsmitteilung 2302 von der Wertanforderungssteuerungsart 2304 war, kann der angeforderte Wert in dem endgültigen Wert oder Zustand 2504 beinhaltet sein. Oder wenn die E/A-Steuerungsanforderungsmitteilung 2302 eine Anforderung war, E/A durchzuführen, kann der endgültige Wert oder Zustand 2504 einen neuen Zustand oder zurückgegebenen Wert für die Durchführung der angeforderten E/A angeben.
Somit ist ein System 100 zum dynamischen CAN-Mitteilungsversand offenbart. Unter Verwendung des Systems kann ein Signalabonnementmodell dazu verwendet werden, Anforderern des Clients 502 zu ermöglichen, Ressourcenanbieterserver 504 zu abonnieren. Zusätzlich kann das Vertragsabfragemodell dazu verwendet werden, die dynamischen CAN-Mitteilungen zu decodieren, die von einem Server 504 zu Fehlerbehebungs- oder Datenprotokollierungszwecken gesendet wurden. Ferner kann das E/A-Steuerungsmodell für ereignisbasierte Aufgaben verwendet werden (z. B., um Scheinwerfer aus der Ferne einzuschalten).
Es ist anzumerken, dass bestimmte Infrastrukturanforderungen an das Fahrzeug 102 gestellt werden können, um das beschriebene System 100 umzusetzen. Zum Beispiel kann es nützlich sein, Bandbreite auf den Fahrzeugbussen 106 vorzuhalten, und diese Vorhaltung kann in Berechnungen einbezogen werden, wenn die Architektur des Fahrzeugs 102 erzeugt wird. Es kann auch nützlich sein, die Kennung des Signals 610 als ein CAN-Attribut zur Verwendung in Mitteilungsdatenbanken zu beinhalten. Unter Bezugnahme auf die CAN-Mitteilungs-ID 804 kann ein Bereich von 29-Bit-Mitteilungs-IDs (z. B. 18CA0000 - 18CA0FFF h (4096)) für diesen Zweck vorgehalten werden.
Unter Bezugnahme auf die Fähigkeiten der ECUs 104, die am dynamischen Mitteilungsversand teilnehmen würden, kann es für diese ECUs 104 erforderlich sein, CAN-Slots (Puffer), nichtflüchtigen Speicher und zusätzliche Verarbeitungsleistung für die Übermittlung neuer Mitteilungen und die Verarbeitung von Anforderungen vorzuhalten. Unter Bezugnahme auf die Funktion des ECG 110 kann das ECG 110, wie in dieser Schrift erörtert, die offenbarten Prozesse vermitteln, indem es der Signalvermittler 118 ist. Somit kann das ECG 110 dazu konfiguriert sein, die aktuelle Buslast zu messen, den Überblick über alle Verträge zu behalten (z. B. als Daten 120 in dem Speicher 116 gespeichert), sowie dazu konfiguriert sein, Mitteilungsversand zu senden, um alle teilnehmenden ECUs 104 über eine Diagnoseanforderung im Falle eines Problems zurückzusetzen.
In dieser Schrift beschriebene Rechenvorrichtungen, wie etwa die ECUs 104 und das ECG 110, beinhalten im Allgemeinen computerausführbare Anweisungen, bei denen die Anweisungen durch eine oder mehrere Rechenvorrichtungen, wie etwa die vorstehend aufgelisteten, ausgeführt werden können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Reihe von Programmiersprachen und/oder -techniken erstellt wurden, die ohne Einschränkung und entweder für sich oder in Kombination Java™, C, C++, C#, Visual Basic, JavaScript, Python, Perl, PL/SQL usw. beinhalten. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch ein oder mehrere Prozesse durchgeführt werden, die einen oder mehrere der in dieser Schrift beschriebenen Prozesse beinhalten. Derartige Anweisungen und andere Daten können unter Verwendung einer Reihe von computerlesbaren Medien gespeichert und übermittelt werden.
Hinsichtlich der in dieser Schrift beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass obwohl die Schritte derartiger Prozesse usw. als gemäß einer bestimmten geordneten Abfolge erfolgend beschrieben worden sind, derartige Prozesse praktisch umgesetzt werden könnten, indem die beschriebenen Schritte in einer Reihenfolge durchgeführt werden, die von der in dieser Schrift beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt, dass andere Schritte hinzugefügt oder dass bestimmte in dieser Schrift beschriebene Schritte weggelassen werden könnten. Mit anderen Worten sind die Beschreibungen von Prozessen in dieser Schrift zum Zweck des Veranschaulichens bestimmter Ausführungsformen bereitgestellt 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 vorstehenden Beschreibung ergeben sich viele Ausführungsformen und Anwendungen, die nicht die bereitgestellten Beispiele sind. Der Schutzumfang sollte nicht unter Bezugnahme auf die vorstehende Beschreibung, sondern stattdessen unter Bezugnahme auf die beigefügten Patentansprüche bestimmt werden, zusammen mit der gesamten Bandbreite an Äquivalenten, zu denen diese Patentansprüche berechtigen. Es wird vorweggenommen und ist beabsichtigt, dass es zukünftige Entwicklungen bei den in dieser Schrift erörterten Technologien geben wird und dass die offenbarten Systeme und Verfahren in derartige zukünftigen Ausführungsformen einbezogen werden. Insgesamt versteht es sich, dass die Anmeldung zur Modifikation und Variation in der Lage ist.
Allen in den Patentansprüchen verwendeten Ausdrücken sollen ihre breitesten nachvollziehbaren Auslegungen und ihre allgemeinen Bedeutungen zukommen, wie sie dem mit den in dieser Schrift beschriebenen Technologien vertrauten Fachmann bekannt sind, es sei denn, in dieser Schrift erfolgt eine ausdrückliche gegenteilige Angabe. 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 zu ermöglichen, die Natur der technischen Offenbarung schnell herauszufinden. Sie wird unter der Maßgabe eingereicht, dass sie nicht zum Auslegen oder Einschränken des Schutzumfangs oder der Bedeutung der Patentansprüche verwendet werden wird. Außerdem geht aus der vorstehenden detaillierten Beschreibung hervor, dass zum Zweck der vereinfachten Darstellung der Offenbarung verschiedene Merkmale in verschiedenen Ausführungsformen zusammengefasst sind. 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 separat beanspruchter Gegenstand steht.
Obwohl vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Wörter beschreibende und keine einschränkenden Wörter und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Schutzumfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
Gemäß der vorliegenden Erfindung wird ein System zum dynamischen Mitteilungsversand eines Controller Area Network (CAN) bereitgestellt, das Folgendes aufweist: ein zentrales Gateway eines Fahrzeugs, das einen Prozessor und einen Speicher beinhaltet, der mit einer Vielzahl von Fahrzeugbussen verbunden ist, wobei jeder der Fahrzeugbusse mit einer oder mehreren elektronischen Steuerungseinheiten (ECUs) verbunden ist, die zu Folgendem programmiert sind: Empfangen einer Mitteilung von einem Client der ECUs, wobei die Mitteilung ein dynamisches CAN-Signal anfordert, Weiterleiten der Mitteilung über die Vielzahl von Fahrzeugbussen an einen Server der ECUs, Empfangen einer Antwort von dem Server, wobei die Antwort eine Verfügbarkeit des dynamischen CAN-Signals festlegt, und Weiterleiten der Antwort an den Client.
Gemäß einer Ausführungsform gibt die Antwort eine CAN-Mitteilungskennung und eine Bitposition innerhalb einer CAN-Mitteilung an, welche die CAN-Mitteilungskennung aufweist, an der das dynamische CAN-Signal bereits verfügbar ist.
Gemäß einer Ausführungsform gibt die Antwort dem Client eine mögliche Verfügbarkeit des dynamischen CAN-Signals an, aber dass das dynamische CAN-Signal nicht bereits verfügbar ist, und das zentrale Gateway ist ferner dazu programmiert, eine Vertragsaushandlung zwischen dem Client und dem Server durchzuführen, um ein dynamisches CAN-Signal als eine neue CAN-Mitteilung über die Fahrzeugbusse hinzuzufügen.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner zu Folgendem programmiert: Analysieren einer Client-Busbandbreite zwischen dem Client und dem zentralen Gateway, Analysieren einer Server-Busbandbreite zwischen dem Server und dem zentralen Gateway und Überprüfen, dass die Client-Busbandbreite und die Server-Busbandbreite eine Hinzufügung einer Abgabe des dynamischen CAN-Signals in einer neuen CAN-Mitteilung unterstützen.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner dazu programmiert, eine Mitteilungskennungszuweisungsmitteilung an den Client und an den Server zu senden, wobei die Mitteilungskennungszuweisungsmitteilung eine Bandbreitenanforderung für die neue CAN-Mitteilung, eine Mitteilungskennung für die neue CAN-Mitteilung, eine Rate zum Senden der neuen CAN-Mitteilung und eine Vertragsnummer beinhaltet, die der neuen CAN-Mitteilung entspricht.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner zu Folgendem programmiert: Empfangen einer Vertragseinrichtungsmitteilung von dem Server als Reaktion auf den Empfang der Mitteilungskennungszuweisungsmitteilung von dem Server; Weitergeben der Vertragseinrichtungsmitteilung an den Client; Empfangen einer Vertragsannahmemitteilung von dem Client als Reaktion auf den Empfang der Vertragseinrichtungsmitteilung beim Client; und Weitergeben der Vertragsannahmemitteilung an den Server, um den Server dazu zu veranlassen, mit dem Senden der neuen CAN-Mitteilung zu beginnen.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner zu Folgendem programmiert: Empfangen einer Vertragsablehnungsmitteilung von dem Client als Reaktion auf den Empfang der Vertragseinrichtungsmitteilung beim Client; und Weitergeben der Vertragsablehnungsmitteilung an den Server, um den Server dazu zu veranlassen, das Senden der neuen CAN-Mitteilung zu unterlassen.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner zu Folgendem programmiert: Empfangen einer Vertragsdetailabfragemitteilung von einer Prüf- oder Protokollierungsvorrichtung; und als Reaktion auf den Empfang der Vertragsdetailabfragemitteilung Senden einer oder mehrerer von der Bandbreitenanforderung für die neue CAN-Mitteilung, der Mitteilungskennung für die neue CAN-Mitteilung, der Rate zum Senden der neuen CAN-Mitteilung und der Vertragsnummer, die der neuen CAN-Mitteilung entspricht, an die Prüf- oder Protokollierungsvorrichtung.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner zu Folgendem programmiert: Senden einer E/A-Entdeckungsmitteilung an jede der ECUs; Empfangen von E/A-Entdeckungsantworten von den ECUs; und Pflegen eines Speichers verfügbarer E/A-Funktionen der ECUs auf Grundlage der E/A-Entdeckungsantworten.
Gemäß einer Ausführungsform ist das zentrale Gateway ferner zu Folgendem programmiert: Empfangen einer Steuerungsanforderung von einer der ECUs, die eine Durchführung einer der verfügbaren E/A-Funktionen anfordert; Weiterleiten der Steuerungsanforderung an die eine der ECUs, die in dem Speicher als die angeforderte E/A-Funktion durchführend angegeben ist; Empfangen einer Steuerungsantwort von der einen der ECUs, die in dem Speicher als die angeforderte E/A-Funktion durchführend angegeben ist; und Weiterleiten der Steuerungsantwort an die anfordernde der ECUs, wobei die Steuerungsantwort ein Ergebnis oder einen Wert als Reaktion auf die E/A-Funktion angibt.
Gemäß der vorliegenden Erfindung wird ein Verfahren zum dynamischen Mitteilungsversand eines Controller Area Network (CAN) bereitgestellt, das Folgendes aufweist: Empfangen, an einem zentralen Gateway eines Fahrzeugs, wobei das zentrale Gateway einen Prozessor und einen Speicher beinhaltet, der mit einer Vielzahl von Fahrzeugbussen verbunden ist, wobei jeder der Fahrzeugbusse mit einer oder mehreren elektronischen Steuerungseinheiten (ECUs) verbunden ist, einer Mitteilung von einem Client der ECUs, wobei die Mitteilung ein dynamisches CAN-Signal anfordert, Weiterleiten der Mitteilung über die Vielzahl von Fahrzeugbussen an einen Server der ECUs, Empfangen einer Antwort von dem Server, wobei die Antwort eine Verfügbarkeit des dynamischen CAN-Signals festlegt, und Weiterleiten der Antwort an den Client.
Gemäß einer Ausführungsform gibt die Antwort eine CAN-Mitteilungskennung und eine Bitposition innerhalb einer CAN-Mitteilung an, welche die CAN-Mitteilungskennung aufweist, an der das dynamische CAN-Signal bereits verfügbar ist.
Gemäß einer Ausführungsform gibt die Antwort dem Client eine mögliche Verfügbarkeit des dynamischen CAN-Signals an, aber dass das dynamische CAN-Signal nicht bereits verfügbar ist, und umfasst ferner Durchführen einer Vertragsaushandlung zwischen dem Client und dem Server, um ein dynamisches CAN-Signal als eine neue CAN-Mitteilung über die Fahrzeugbusse hinzuzufügen.
Gemäß einer Ausführungsform ist die Erfindung ferner durch Folgendes gekennzeichnet: Analysieren einer Client-Busbandbreite zwischen dem Client und dem zentralen Gateway, Analysieren einer Server-Busbandbreite zwischen dem Server und dem zentralen Gateway und Überprüfen, dass die Client-Busbandbreite und die Server-Busbandbreite eine Hinzufügung einer Abgabe des dynamischen CAN-Signals in einer neuen CAN-Mitteilung unterstützen.
Gemäß einer Ausführungsform ist die Erfindung ferner durch Folgendes gekennzeichnet: Senden einer Mitteilungskennungszuweisungsmitteilung an den Client und an den Server, wobei die Mitteilungskennungszuweisungsmitteilung eine Bandbreitenanforderung für die neue CAN-Mitteilung, eine Mitteilungskennung für die neue CAN-Mitteilung, eine Rate zum Senden der neuen CAN-Mitteilung und eine Vertragsnummer beinhaltet, die der neuen CAN-Mitteilung entspricht.
Gemäß einer Ausführungsform ist die Erfindung ferner durch Folgendes gekennzeichnet: Empfangen einer Vertragseinrichtungsmitteilung von dem Server als Reaktion auf den Empfang der Mitteilungskennungszuweisungsmitteilung von dem Server; Weitergeben der Vertragseinrichtungsmitteilung an den Client; Empfangen einer Vertragsannahmemitteilung von dem Client als Reaktion auf den Empfang der Vertragseinrichtungsmitteilung beim Client; und Weitergeben der Vertragsannahmemitteilung an den Server, um den Server dazu zu veranlassen, mit dem Senden der neuen CAN-Mitteilung zu beginnen.
Gemäß einer Ausführungsform ist die Erfindung ferner durch Folgendes gekennzeichnet: Empfangen einer Vertragsablehnungsmitteilung von dem Client als Reaktion auf den Empfang der Vertragseinrichtungsmitteilung beim Client; und Weitergeben der Vertragsablehnungsmitteilung an den Server, um den Server dazu zu veranlassen, das Senden der neuen CAN-Mitteilung zu unterlassen.
Gemäß einer Ausführungsform ist die Erfindung ferner durch Folgendes gekennzeichnet: Empfangen einer Vertragsdetailabfragemitteilung von einer Prüf- oder Protokollierungsvorrichtung; und als Reaktion auf den Empfang der Vertragsdetailabfragemitteilung Senden einer oder mehrerer von der Bandbreitenanforderung für die neue CAN-Mitteilung, der Mitteilungskennung für die neue CAN-Mitteilung, der Rate zum Senden der neuen CAN-Mitteilung und der Vertragsnummer, die der neuen CAN-Mitteilung entspricht, an die Prüf- oder Protokollierungsvorrichtung.
Gemäß einer Ausführungsform ist die Erfindung ferner durch Folgendes gekennzeichnet: Senden einer E/A-Entdeckungsmitteilung an jede der ECUs; Empfangen von E/A-Entdeckungsantworten von den ECUs; und Pflegen eines Speichers verfügbarer E/A-Funktionen der ECUs auf Grundlage der E/A-Entdeckungsantworten.
Gemäß einer Ausführungsform ist die Erfindung ferner durch Folgendes gekennzeichnet: Empfangen einer Steuerungsanforderung von einer der ECUs, die eine Durchführung einer der verfügbaren E/A-Funktionen anfordert; Weiterleiten der Steuerungsanforderung an die eine der ECUs, die in dem Speicher als die angeforderte E/A-Funktion durchführend angegeben ist; Empfangen einer Steuerungsantwort von der einen der ECUs, die in dem Speicher als die angeforderte E/A-Funktion durchführend angegeben ist; und Weiterleiten der Steuerungsantwort an die anfordernde der ECUs, wobei die Steuerungsantwort ein Ergebnis oder einen Wert als Reaktion auf die E/A-Funktion angibt.

Claims

Verfahren zum dynamischen Mitteilungsversand eines Controller Area Network (CAN), umfassend: Empfangen, an einem zentralen Gateway eines Fahrzeugs, wobei das zentrale Gateway einen Prozessor und einen Speicher beinhaltet, der mit einer Vielzahl von Fahrzeugbussen verbunden ist, wobei jeder der Fahrzeugbusse mit einer oder mehreren elektronischen Steuerungseinheiten (ECUs) verbunden ist, einer Mitteilung von einem Client der ECUs, wobei die Mitteilung ein dynamisches CAN-Signal anfordert, Weiterleiten der Mitteilung über die Vielzahl von Fahrzeugbussen an einen Server der ECUs, Empfangen einer Antwort von dem Server, wobei die Antwort eine Verfügbarkeit des dynamischen CAN-Signals festlegt, und Weiterleiten der Antwort an den Client.
Verfahren nach Anspruch 1, wobei die Antwort angibt, dass das dynamische CAN-Signal bereits über eine CAN-Mitteilungskennung und eine Bitposition innerhalb der CAN-Mitteilung verfügbar ist.
Verfahren nach Anspruch 1, wobei die Antwort dem Client eine mögliche Verfügbarkeit des dynamischen CAN-Signals angibt, aber dass das dynamische CAN-Signal nicht bereits verfügbar ist, und ferner umfassend Durchführen einer Vertragsaushandlung zwischen dem Client und dem Server, um ein dynamisches CAN-Signal als eine neue CAN-Mitteilung über die Fahrzeugbusse hinzuzufügen.
Verfahren nach Anspruch 3, ferner umfassend: Analysieren einer Client-Busbandbreite zwischen dem Client und dem zentralen Gateway, Analysieren einer Server-Busbandbreite zwischen dem Server und dem zentralen Gateway und Überprüfen, dass die Client-Busbandbreite und die Server-Busbandbreite eine Hinzufügung einer Abgabe des dynamischen CAN-Signals in einer neuen CAN-Mitteilung unterstützen.
Verfahren nach Anspruch 3, ferner umfassend Senden einer Mitteilungskennungszuweisungsmitteilung an den Client und an den Server, wobei die Mitteilungskennungszuweisungsmitteilung eine Bandbreitenanforderung für die neue CAN-Mitteilung, eine Mitteilungskennung für die neue CAN-Mitteilung, eine Rate zum Senden der neuen CAN-Mitteilung und eine Vertragsnummer beinhaltet, die der neuen CAN-Mitteilung entspricht.
Verfahren nach Anspruch 5, ferner umfassend: Empfangen einer Vertragseinrichtungsmitteilung von dem Server als Reaktion auf den Empfang der Mitteilungskennungszuweisungsmitteilung von dem Server; Weitergeben der Vertragseinrichtungsmitteilung an den Client; Empfangen einer Vertragsannahmemitteilung von dem Client als Reaktion auf den Empfang der Vertragseinrichtungsmitteilung beim Client; und Weitergeben der Vertragsannahmemitteilung an den Server, um den Server dazu zu veranlassen, mit dem Senden der neuen CAN-Mitteilung zu beginnen.
Verfahren nach Anspruch 6, ferner umfassend: Empfangen einer Vertragsablehnungsmitteilung von dem Client als Reaktion auf den Empfang der Vertragseinrichtungsmitteilung beim Client; und Weitergeben der Vertragsablehnungsmitteilung an den Server, um den Server dazu zu veranlassen, das Senden der neuen CAN-Mitteilung zu unterlassen.
Verfahren nach Anspruch 5, ferner umfassend: Empfangen einer Vertragsdetailabfragemitteilung von einer Prüf- oder Protokollierungsvorrichtung; und als Reaktion auf den Empfang der Vertragsdetailabfragemitteilung Senden einer oder mehrerer von der Bandbreitenanforderung für die neue CAN-Mitteilung, der Mitteilungskennung für die neue CAN-Mitteilung, der Rate zum Senden der neuen CAN-Mitteilung und der Vertragsnummer, die der neuen CAN-Mitteilung entspricht, an die Prüf- oder Protokollierungsvorrichtung.
Verfahren nach Anspruch 1, ferner umfassend: Senden einer E/A-Entdeckungsmitteilung an jede der ECUs; Empfangen von E/A-Entdeckungsantworten von den ECUs; und Pflegen eines Speichers verfügbarer E/A-Funktionen der ECUs auf Grundlage der E/A-Entdeckungsantworten.
Verfahren nach Anspruch 9, ferner umfassend: Empfangen einer Steuerungsanforderung von einer der ECUs, die eine Durchführung einer der verfügbaren E/A-Funktionen anfordert; Weiterleiten der Steuerungsanforderung an die eine der ECUs, die in dem Speicher als die angeforderte E/A-Funktion durchführend angegeben ist; Empfangen einer Steuerungsantwort von der einen der ECUs, die in dem Speicher als die angeforderte E/A-Funktion durchführend angegeben ist; und Weiterleiten der Steuerungsantwort an die anfordernde der ECUs, wobei die Steuerungsantwort ein Ergebnis oder einen Wert als Reaktion auf die E/A-Funktion angibt.
System zum dynamischen Mitteilungsversand eines Controller Area Network (CAN), umfassend: ein zentrales Gateway eines Fahrzeugs, das einen Prozessor und einen Speicher beinhaltet, der mit einer Vielzahl von Fahrzeugbussen verbunden ist, wobei jeder der Fahrzeugbusse mit einer oder mehreren elektronischen Steuerungseinheiten (ECUs) verbunden ist, die dazu programmiert sind, das Verfahren nach einem der Ansprüche 1-10 durchzuführen.