-
Die
Erfindung betrifft eine Schnittstelle zur Kommunikation zwischen
Fahrzeug-Applikationen und Fahrzeug-Bussystemen.
-
Der
Einsatz von Fahzeug-Bussystemen in modernen Kraftfahrzeugen nimmt
stetig zu. Das bekannteste Fahrzeug-Bussystem ist der CAN-Bus. Daneben
existieren weitere Fahrzeug-Bussysteme
wie beispielsweise der LIN-Bus oder FlexRay, die ergänzend und/oder
ersetzend zum CAN-Bus zur Anwendung kommen. Die auf einem Fahrzeugrechner
in dem Kraftfahrzeug implementierten Applikationen wie beispielsweise
die Klimaregelung müssen über das
Bussystem mit anderen Steuergeräten
kommunizieren. Hierzu muss das Betriebssystem des Fahrzeugrechners
eine Schnittstelle zum Fahrzeug-Bussystem bereitstellen.
-
Hierzu
ist es bekannt, dass die Applikation ähnlich dem Öffnen einer herkömmlichen
Datei mittels eines 'Character
Devices' und dem
damit verbundenen Gerätetreiber
auf das Bussystem zugreift. Dabei wird der Fahrzeug-Bus ähnlich einem
Gerät wie
beispielsweise einer seriellen Schnittstelle angesprochen. Die Implementierung
der zugehörigen
Transportprotokolle muss dabei jedoch jeweils in den Applikationen
erfolgen. Dies erfordert wiederum, dass der Programmierer der Applikationen
Kenntnisse über
den Aufbau und die Wirkungsweise der Transportprotokolle haben muss.
-
Eine
neuere Entwicklung der Firma Micro Control geht dahin, die CAN-Anbindung über Sockets
zu realisieren, wobei hierzu bei Verwendung von Linux der ohnehin
vorhandene Socket Layer verwendet wird. Dabei werden dann die Gerätetreiber
unterhalb des Network Layers implementiert und stellen die Funktionalität des jeweiligen
Bus-Controllers als 'Network
Device' zur Verfügung. Dies
hat den Vorteil, dass der Netzwerkcharakter vom CAN-Bus für die Anwendung
erhalten bleibt. Nachteilig an dem bekannten Lösungsansatz ist, dass weiterhin
die anwenderspezifischen CAN-Protokolle wie beispielsweise das Transportprotokoll
in den Applikationen implementiert werden müssen. Die in der Applikation
erzeugten protokollgerechten Nachrichten „durchtunneln" dann im Wesentlichen
unbearbeitet („RAW"-Modus) nur den Socket und Network Layer,
um unterhalb des Network Layers einem geeigneten 'Network Device' zugeführt zu werden.
-
Der
Erfindung liegt daher das technische Problem zugrunde, eine Schnittstelle
zur Kommunikation zwischen Fahrzeug-Applikationen und Fahrzeug-Bussystemen
zu schaffen, die eine vereinfachte Anbindung von Applikationen an
Fahrzeug-Bussysteme ermöglich.
-
Die
Lösung
des technischen Problems ergibt sich durch den Gegenstand mit den
Merkmalen des Patentanspruchs 1. Weitere vorteilhafte Ausgestaltungen
der Erfindung ergeben sich aus den Unteransprüchen.
-
Hierzu
wird mindestens ein Fahrzeug-Bus-Protokoll innerhalb einer neu zu
schaffenden Protokoll-Familie zwischen dem Socket Layer und dem
Network Layer implementiert. Dadurch kann bei der Erstellung der Fahrzeug-Applikationen
auf vertiefte Kenntnisse der einzelnen Fahrzeug-Bus-Protokolle verzichtet
werden, da die protokollgerechte Übertragung der Daten durch
das erweiterte Betriebssystem des Fahrzeugrechners erfolgt. Dies
gewährleistet,
dass keine fehlerhafte Anwendung der Fahrzeug-Bus-Protokolle in
den Fahrzeug-Applikationen zu Fehlern führt. Neben der einfachen Programmierung
der Fahrzeug-Applikationen erlaubt dies ein einfaches zentrales
Updaten der Protokolle. Des Weiteren erlaubt die verwendete Schnittstelle
die netzwerkmäßige Ansteuerung
des Fahrzeug-Bussystems, so dass einfache parallele Verbindungsaufbauten
einer oder mehrerer Fahrzeug-Applikationen zum Fahrzug-Bussystem möglich sind.
-
Wie
bereits ausgeführt,
stellt CAN derzeit das am weitesten verbreitete Fahrzeug-Bussystem
dar. In einer bevorzugten Ausführungsform
sind die Treiber für
die CAN-Controller als Netzwerkgerätetreiber ('Network Device Driver') ausgebildet, wobei
für unterschiedliche
CAN-Controller jeweils
ein eigener Netzwerkgerätetreiber
vorhanden ist. Durch das Bereitstellen verschiedener Netzwerkgerätetreiber
die zum Network Layer dieselbe Schnittstelle implementieren, können die
darüberliegenden
Schichten (Protokolle und Applikationen) unabhängig von der tatsächlichen
Hardware realisiert werden. Es versteht sich, dass die für CAN erläuterten Ausführungen
zu den Gerätetreibern
sich beliebig auf andere Fahrzeug-Bussysteme wie beispielsweise LIN oder
FlexRay übertragen
lassen.
-
In
einer weiteren bevorzugten Ausführungsform
ist mindestens ein Netzwerkgerätetreiber
('Network Device
Driver') implementiert,
mittels dessen eine virtuelle Verbindung zwischen zwei Applikationen über den Network
Layer realisierbar ist. Dies ermöglicht
insbesondere in der Erstellungsphase der Fahrzeug-Applikationen
bereits ein sehr realistisches Testen ohne Hardware, da die protokollgerechten
Nachrichten rückgekoppelt
werden, was den Empfang realer Fahrzeug-Bus-Nachrichten simuliert.
-
Vorzugsweise
sind mindestens ein Transportprotokoll und/oder ein Netzwerkmanagement-Protokoll in der
Protokoll-Familie des Fahrzeug-Bussystems implementiert.
-
In
einer weiteren bevorzugten Ausführungsform
ist zwischen dem Network Layer und den Protokoll-Modulen ein Dispatcher
angeordnet. Ebenso ist vorzugsweise zwischen dem Socket Layer und
den Protokoll-Modulen ein Dispatcher angeordnet.
-
Die
Erfindung wird nachfolgend anhand eines bevorzugten Ausführungsbeispiels
näher erläutert. Die einzige
Figur zeigt ein schematisches Schichtenmodell der Schnittstelle.
-
In
der 1 ist ein Schichtenmodell der Schnittstelle zur
Kommunikation zwischen Fahrzeug-Applikationen
FA1 – FAn
und Fahrzeug-Bussystemen FB1 – FBn
dargestellt. Die Fahrzeug-Applikationen
FA1 – FAn können dabei
die verschiedensten Anwenderprogramme wie beispielsweise Klimaregelung
oder Diagnosetools sein. Gemeinsam ist den Fahrzeug-Applikationen FA1 – FAn, dass
diese Daten von Steuergeräten
in den Fahrzeug-Bussystemen empfangen müssen bzw. Nachrichten an diese
senden müssen.
Die Fahrzeug-Applikationen FA1 – FAn
sind dabei auf mindestens einem nicht dargestellten Fahrzeugrechner
implementiert, der mit einem Betriebssystem ausgebildet ist. Dabei
sei nachfolgend angenommen, dass es sich bei dem Betriebssystem
um Linux handelt. Andere Betriebssysteme sind möglich, soweit diese über eine
standardisierte Socket-Schnittstelle verfügen (Berkley-Socket API). Nachfolgend
sei weiter angenommen, dass es sich bei den Fahrzeug-Bussystemen
FB1 – FBn
um unterschiedliche CAN-Bussysteme in Kraftfahrzeugen handelt. Allerdings
können
ergänzend
oder alternativ weitere Fahrzeug-Bussysteme wie beispielsweise Flex
Ray oder LIN-Bussysteme zur Anwendung kommen, was in der Figur durch
die Netzwerkgeräte
lin0, lin1 angedeutet ist.
-
Der
Linux-Kernel umfasst standardmäßig einen
Linux Socket Layer und einen Linux Network Layer. Dabei sind zwischen
dem Linux Socket Layer und dem Linux Network Layer standardmäßig verschiedene
Protokoll-Familien angeordnet. Beispiele hierfür sind die Internet-Protokoll-Familie
oder die Packet-Protokoll-Familie. Bevor die erfindungsgemäße Einbettung
der verschiedenen CAN-Protokolle erläutert wird, wird zunächst die
bekannte Einbettung der Internet-Protokoll-Familie erläutert. Die
Internet-Protokoll-Familie PF_INET enthält beispielsweise die Protokoll-Module
ICMP, TCP und UDP.
-
ICMP
(Internet Control Message Protocol) ist ein Protokoll der Internetschicht.
ICMP nutzt die Dienste des auf der gleichen Schicht arbeitenden
Internet Protocol, um Fehlermeldungen und andere Netzinformationen
(zum Beispiel Router-Informationen) der Protokolle IP, TCP oder
UDP zu übermitteln.
-
UDP
(User Datagram Protocol) ist in der TCP/IP-Protokollarchitektur
ein einfaches, verbindungslos übertragendes
Transportprotokoll.
-
TCP
ist das am häufigsten
verwendete Transportprotokoll in Internet-/Intranet-Umgebungen.
Es ist ein verbindungsorientiertes Ende-zu-Ende- Protokoll mit gerichteter
Datenübertragung,
Verbindungssteuerung, Flusskontrolle, Zeitüberwachung und Multiplex in
der Transportschicht der Protokollarchitektur TCP/IP. Eine Anwendung,
beispielsweise ein Browser, nutzt eine virtuelle Steckdose (Socket),
um eine gesicherte Verbindung über
TCP zu einer anderen Anwendung wie beispielsweise einen Webserver
aufzubauen. Hierzu wird über
den Linux Socket Layer ein Socket aufgebaut, über einen Dispatcher DIS-TX
das richtige Protokoll-Modul (hier
TCP) ausgewählt
und anschließend
protokollgerecht die Nachricht über
IP und den Linux Network Layer übergeben.
Der Linux Network Layer gibt die Daten an das betreffende Netzwerkgerät ('Network Device'), und die Nachricht
wird beispielsweise über
ein Modem übertragen.
Der Empfang läuft
entsprechend umgekehrt, wobei über
einen Dispatcher DIS-RX die empfangenen Nachrichten dem richtigen
Protokoll-Modul zugeordnet werden. Diese aus der Internet-Kommunikation
bekannte Art zum Aufbau einer Schnittstelle wird nun auf die Kommunikation
einer Fahrzeug-Applikation mit einem Fahrzeug-Bussystem übertragen.
-
Hierzu
wird eine CAN- Protokoll-Familie PF_CAN erstellt und im Linux Socket
Layer registriert. Die CAN-Protokoll-Familie umfasst die verschiedenen
CAN-Protokolle wie beispielsweise CAN_BCM (CAN-Broadcast Manager)
für das
Senden und Empfangen von (zyklischen) CAN-Nachrichten, das Netzwerkmanagement,
CAN_TP20 als ein mögliches
Transportprotokoll und CAN_RAW für
des Senden und Empfangen von einzelnen CAN-Nachrichten. Dabei können verschiedene Ausprägungen von
CAN_TP-Modulen realisiert sein (z.B. VAG TP2.0, VAG TP1.6, MCNet,
OSEK COM, etc.). Des Weiteren kann eine oder mehrere Fahrzeug-Applikationen
FA1 – FAn
gleichzeitig das selbe CAN_TP-Modul nutzen. Ausserdem kann eine
Fahrzeug-Applikation gleichzeitig auch mehrere unterschiedliche
CAN_TP-Module nutzen. Gleiches gilt für die anderen Module. Analog
der Verteilung bei der Internet-Protokoll-Familie PF_INET teilt
der Dispatcher-TX einer Nachrichten-Sendung von einer Fahrzeug-Applikation
FA1 – FAn
das richtige CAN-Protokoll-Modul zu. Die protokollgerechte Nachricht
wird dann an den Linux Network Layer übermittelt, der das zuständige Netzwerkgerät ('Network Device') can0 – can3,
lin0-lin1, vcan0 zur Übertragung
auswählt.
Durch das Vorhandensein der verschiedenen Netzwerkgerätetreiber
TypA – TypC können die
verschiedensten CAN-Controller TypA – TypC von verschiedenen Herstellern
im Fahrzeug-Bussystem verbaut werden, ohne dass sich etwas an der
Schnittstelle zum Network Layer ändert.
Sind dabei physikalisch die gleichen CAN-Controller verbaut (wie
beispielsweise bei FB0 und FB1), so kann unter dem Netzwerkgerät can0 bzw.
can1 jeweils der gleiche Netzwerkgerätetreiber TypA implementiert
werden. Die Übertragung
von Daten von den Fahrzeug-Bussystemen FB1 – FBn zu den Fahrzeug-Applikationen
FA1 – FAn
erfolgt entsprechend umgekehrt. Der durch die Erfindung erreichte Vorteil
besteht insbesondere darin, dass nunmehr der Entwickler bzw. Programmierer
einer Fahrzeug-Applikation FA1 – FAn
keinerlei Detail-Kenntnisse mehr über die einzelnen CAN-Protokolle
verfügen
muss. Dies wiederum führt
dazu, dass die Programme an Komplexität abnehmen, was Fehlersuche
und damit einhergehend die Zuverlässigkeit erhöht.
-
Dies
soll an einem Beispiel zum Öffnen
eines Transportkanals erläutert
werden.
-
-
Wie
leicht erkennbar, benötigt
der Programmierer keinerlei interne Kenntnisse über das Transportprotokoll.
Dieser muss nur wissen, welche Fahrzeug-Bussysteme vorhanden sind
und wie diese bezeichnet werden (hier can1).
-
Neben
den Netzwerkgerätetreibern
TypA – TypC
ist ein virtueller Netzwerkgerätetreiber
für das
Network Device 'vcan' zu erkennen. Dieser
dient dazu, dass eine Applikation eine Nachricht generiert und diese nicht
physikalisch auf das Fahrzeug-Bussystem gesendet wird bzw. einen
entsprechenden Bus-Controller zur Übertragung übergeben, sondern unterhalb
des Linux Network Layer wieder analog einer empfangenen Nachricht über den
Network Layer zu einer auf dem lokalen System vorhandenen Fahrzeug-Applikation übertragen wird.
Dies ermöglicht
frühzeitig
in der Entwicklung, wo häufig
noch die Hardware nicht zur Verfügung
steht, einzelne Fahrzeug-Applikationen zu testen und auch das Zusammenspiel
von Fahrzeug-Applikationen zu überprüfen. Da
die generierten und empfangenen Nachrichten jeweils die Protokoll-Schicht
durchlaufen, kann somit softwaretechnisch die Fahrzeug-Applikation unter
realen Bedingungen getestet werden.
-
Wie
bereits erläutert,
dient der Dispatcher DIS-RX zum Verteilen empfangener Nachrichten
auf die richtigen CAN-Protokolle. Dabei übernimmt der Dispatcher DIS-RX
gleichzeitig eine Filterfunktion, indem dieser nur CAN-Botschaften
mit einem Identifier weiterleitet, die eine der Fahrzeug-Applikationen
benötigt.
Prinzipiell ist es jedoch auch möglich,
die Filterfunktion eines CAN-Controllers zu nutzen, soweit der verwendete Contoller
die entsprechende Funktionalität
anbietet. In diesem Fall würde
der Dispatcher DIS-RX weniger unbenötigte CAN-Nachrichten empfangen,
wodurch sich der Verarbeitungsaufwand reduziert.
-
Neben
der CAN-Protokoll-Familie PF_CAN ist die Packet-Protokoll-Familie
PF_PACKET dargestellt. Mittels dieser Protokoll-Familie können einfache
Pakete durch den Linux Socket Layer und den Linux Network Layer
geschleust werden. Ein Socket der PF_PACKET-Familie besitzt ähnliche
Funktionalität
wie der CAN_RAW-Socket der PF_CAN-Familie, bietet jedoch nicht die
CAN-spezifische beschriebene Filterung von CAN-Nachrichten. Analoge
RAW-Protokolle lassen
sich auch für
andere Fahrzeugbusse in der jeweiligen Protokollfamilie (z.B. PF_LIN,
PF_FLEXRAY, etc) realisieren.
-
Weiter
sei angemerkt, dass die Internet-Protokoll-Familie, weil ohnehin
bereits vorhanden, auch für
die Fahrzeug-Applikationen genutzt werden kann, beispielsweise um
bestimmte Informationen aus dem Internet abzurufen.
