-
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 Lagers einem geeigneten ,Network Device’ zugeführt zu werden.
-
Aus der
DE 100 19 151 A1 ist eine Schnittstelle zur Kommunikation zwischen Fahrzeug-Applikationen und Fahrzeugbussystemen bekannt, umfassend einen Fahrzeugrechner mit mindestens einem Betriebssystem. Bevorzugt werden zwei Betriebssysteme verwendet, zum einen das Betriebssystem Linux, das den Mehrnutzerzugang ermöglicht, zum anderen das Betriebssystem OSEK. OSEK ist ein Betriebssystem, das für Fahrzeugfunktionen wie Motorsteuerung verwendet wird, während das Infotainmentsystem durch Linux gesteuert wird.
-
Aus MERIGEAULT, S.; LAMY, C.: Concepts for Exchanging Extra Information Between Protocol Layers Transparently for the Standard Protocol Stack. In: 10th International Conference an Telecommunications, Vol. 2, 2003, S. 981–985 – ISBN: 0-7803-7661-7 ist ein Linux-Betriebssystem mit einem Socket-Layer und einem Network Layer bekannt.
-
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, TOP oder UDP zu übermitteln.
-
UDP (User Datagram Protocol) ist in der TCP/IP-Protokollarchitektur ein einfaches, verbindungslos übertragendes Transportprotokoll.
-
TOP 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 TOP 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 TOP) 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.
