• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    DieErfindung betrifft eine Schnittstelle zur Kommunikation zwischenFahrzeug-Applikationen (FA1-FAn) und Fahrzeug-Bussystemen (FB1-FBn), umfassendeinen Fahrzeugrechner mit einem Betriebssystem, wobei das Betriebssystemeinen Socket-Layer und einen Network-Layer aufweist, wobei mindestensein hardware-abhängigerNetzwerkgerätetreiberunterhalb des Network-Layers angeordnet und mindestens ein Fahrzeug-Bus-Protokollinnerhalb einer Protokoll-Familie zwischen dem Socket-Layer unddem Network-Layer implementiert ist.
    公开号:DE102004020880A1
    申请号:DE200410020880
    申请日:2004-04-26
    公开日:2005-11-17
    发明作者:Oliver Hartkopp；Urs Dr. Thürmann
    申请人:Volkswagen AG；
    IPC主号:H04L12-413
    专利说明:
    [0001] DieErfindung betrifft eine Schnittstelle zur Kommunikation zwischenFahrzeug-Applikationen und Fahrzeug-Bussystemen.
    [0002] DerEinsatz von Fahzeug-Bussystemen in modernen Kraftfahrzeugen nimmtstetig zu. Das bekannteste Fahrzeug-Bussystem ist der CAN-Bus. Danebenexistieren weitere Fahrzeug-Bussystemewie beispielsweise der LIN-Bus oder FlexRay, die ergänzend und/oderersetzend zum CAN-Bus zur Anwendung kommen. Die auf einem Fahrzeugrechnerin dem Kraftfahrzeug implementierten Applikationen wie beispielsweisedie Klimaregelung müssen über dasBussystem mit anderen Steuergerätenkommunizieren. Hierzu muss das Betriebssystem des Fahrzeugrechnerseine Schnittstelle zum Fahrzeug-Bussystem bereitstellen.
    [0003] Hierzuist es bekannt, dass die Applikation ähnlich dem Öffnen einer herkömmlichenDatei mittels eines 'CharacterDevices' und demdamit verbundenen Gerätetreiberauf das Bussystem zugreift. Dabei wird der Fahrzeug-Bus ähnlich einemGerät wiebeispielsweise einer seriellen Schnittstelle angesprochen. Die Implementierungder zugehörigenTransportprotokolle muss dabei jedoch jeweils in den Applikationenerfolgen. Dies erfordert wiederum, dass der Programmierer der ApplikationenKenntnisse überden Aufbau und die Wirkungsweise der Transportprotokolle haben muss.
    [0004] Eineneuere Entwicklung der Firma Micro Control geht dahin, die CAN-Anbindung über Socketszu realisieren, wobei hierzu bei Verwendung von Linux der ohnehinvorhandene Socket Layer verwendet wird. Dabei werden dann die Gerätetreiberunterhalb des Network Layers implementiert und stellen die Funktionalität des jeweiligenBus-Controllers als 'NetworkDevice' zur Verfügung. Dieshat den Vorteil, dass der Netzwerkcharakter vom CAN-Bus für die Anwendungerhalten bleibt. Nachteilig an dem bekannten Lösungsansatz ist, dass weiterhindie anwenderspezifischen CAN-Protokolle wie beispielsweise das Transportprotokollin den Applikationen implementiert werden müssen. Die in der Applikationerzeugten protokollgerechten Nachrichten „durchtunneln" dann im Wesentlichenunbearbeitet („RAW"-Modus) nur den Socket und Network Layer,um unterhalb des Network Layers einem geeigneten 'Network Device' zugeführt zu werden.
    [0005] DerErfindung liegt daher das technische Problem zugrunde, eine Schnittstellezur Kommunikation zwischen Fahrzeug-Applikationen und Fahrzeug-Bussystemenzu schaffen, die eine vereinfachte Anbindung von Applikationen anFahrzeug-Bussysteme ermöglich.
    [0006] DieLösungdes technischen Problems ergibt sich durch den Gegenstand mit denMerkmalen des Patentanspruchs 1. Weitere vorteilhafte Ausgestaltungender Erfindung ergeben sich aus den Unteransprüchen.
    [0007] Hierzuwird mindestens ein Fahrzeug-Bus-Protokoll innerhalb einer neu zuschaffenden Protokoll-Familie zwischen dem Socket Layer und demNetwork Layer implementiert. Dadurch kann bei der Erstellung der Fahrzeug-Applikationenauf vertiefte Kenntnisse der einzelnen Fahrzeug-Bus-Protokolle verzichtetwerden, da die protokollgerechte Übertragung der Daten durchdas erweiterte Betriebssystem des Fahrzeugrechners erfolgt. Diesgewährleistet,dass keine fehlerhafte Anwendung der Fahrzeug-Bus-Protokolle inden Fahrzeug-Applikationen zu Fehlern führt. Neben der einfachen Programmierungder Fahrzeug-Applikationen erlaubt dies ein einfaches zentralesUpdaten der Protokolle. Des Weiteren erlaubt die verwendete Schnittstelledie netzwerkmäßige Ansteuerungdes Fahrzeug-Bussystems, so dass einfache parallele Verbindungsaufbauteneiner oder mehrerer Fahrzeug-Applikationen zum Fahrzug-Bussystem möglich sind.
    [0008] Wiebereits ausgeführt,stellt CAN derzeit das am weitesten verbreitete Fahrzeug-Bussystemdar. In einer bevorzugten Ausführungsformsind die Treiber fürdie CAN-Controller als Netzwerkgerätetreiber ('Network Device Driver') ausgebildet, wobeifür unterschiedlicheCAN-Controller jeweilsein eigener Netzwerkgerätetreibervorhanden ist. Durch das Bereitstellen verschiedener Netzwerkgerätetreiberdie zum Network Layer dieselbe Schnittstelle implementieren, können diedarüberliegendenSchichten (Protokolle und Applikationen) unabhängig von der tatsächlichenHardware realisiert werden. Es versteht sich, dass die für CAN erläuterten Ausführungenzu den Gerätetreibernsich beliebig auf andere Fahrzeug-Bussysteme wie beispielsweise LIN oderFlexRay übertragenlassen.
    [0009] Ineiner weiteren bevorzugten Ausführungsformist mindestens ein Netzwerkgerätetreiber('Network DeviceDriver') implementiert,mittels dessen eine virtuelle Verbindung zwischen zwei Applikationen über den NetworkLayer realisierbar ist. Dies ermöglichtinsbesondere in der Erstellungsphase der Fahrzeug-Applikationenbereits ein sehr realistisches Testen ohne Hardware, da die protokollgerechtenNachrichten rückgekoppeltwerden, was den Empfang realer Fahrzeug-Bus-Nachrichten simuliert.
    [0010] Vorzugsweisesind mindestens ein Transportprotokoll und/oder ein Netzwerkmanagement-Protokoll in derProtokoll-Familie des Fahrzeug-Bussystems implementiert.
    [0011] Ineiner weiteren bevorzugten Ausführungsformist zwischen dem Network Layer und den Protokoll-Modulen ein Dispatcherangeordnet. Ebenso ist vorzugsweise zwischen dem Socket Layer undden Protokoll-Modulen ein Dispatcher angeordnet.
    [0012] DieErfindung wird nachfolgend anhand eines bevorzugten Ausführungsbeispielsnäher erläutert. Die einzigeFigur zeigt ein schematisches Schichtenmodell der Schnittstelle.
    [0013] Inder 1 ist ein Schichtenmodell der Schnittstelle zurKommunikation zwischen Fahrzeug-ApplikationenFA1 – FAnund Fahrzeug-Bussystemen FB1 – FBndargestellt. Die Fahrzeug-ApplikationenFA1 – FAn können dabeidie verschiedensten Anwenderprogramme wie beispielsweise Klimaregelungoder Diagnosetools sein. Gemeinsam ist den Fahrzeug-Applikationen FA1 – FAn, dassdiese Daten von Steuergerätenin den Fahrzeug-Bussystemen empfangen müssen bzw. Nachrichten an diesesenden müssen.Die Fahrzeug-Applikationen FA1 – FAnsind dabei auf mindestens einem nicht dargestellten Fahrzeugrechnerimplementiert, der mit einem Betriebssystem ausgebildet ist. Dabeisei nachfolgend angenommen, dass es sich bei dem Betriebssystemum Linux handelt. Andere Betriebssysteme sind möglich, soweit diese über einestandardisierte Socket-Schnittstelle verfügen (Berkley-Socket API). Nachfolgendsei weiter angenommen, dass es sich bei den Fahrzeug-BussystemenFB1 – FBnum unterschiedliche CAN-Bussysteme in Kraftfahrzeugen handelt. Allerdingskönnenergänzendoder alternativ weitere Fahrzeug-Bussysteme wie beispielsweise FlexRay oder LIN-Bussysteme zur Anwendung kommen, was in der Figur durchdie Netzwerkgerätelin0, lin1 angedeutet ist.
    [0014] DerLinux-Kernel umfasst standardmäßig einenLinux Socket Layer und einen Linux Network Layer. Dabei sind zwischendem Linux Socket Layer und dem Linux Network Layer standardmäßig verschiedeneProtokoll-Familien angeordnet. Beispiele hierfür sind die Internet-Protokoll-Familieoder die Packet-Protokoll-Familie. Bevor die erfindungsgemäße Einbettungder verschiedenen CAN-Protokolle erläutert wird, wird zunächst diebekannte Einbettung der Internet-Protokoll-Familie erläutert. DieInternet-Protokoll-Familie PF_INET enthält beispielsweise die Protokoll-ModuleICMP, TCP und UDP.
    [0015] ICMP(Internet Control Message Protocol) ist ein Protokoll der Internetschicht.ICMP nutzt die Dienste des auf der gleichen Schicht arbeitendenInternet Protocol, um Fehlermeldungen und andere Netzinformationen(zum Beispiel Router-Informationen) der Protokolle IP, TCP oderUDP zu übermitteln.
    [0016] UDP(User Datagram Protocol) ist in der TCP/IP-Protokollarchitekturein einfaches, verbindungslos übertragendesTransportprotokoll.
    [0017] TCPist das am häufigstenverwendete Transportprotokoll in Internet-/Intranet-Umgebungen.Es ist ein verbindungsorientiertes Ende-zu-Ende- Protokoll mit gerichteterDatenübertragung,Verbindungssteuerung, Flusskontrolle, Zeitüberwachung und Multiplex inder Transportschicht der Protokollarchitektur TCP/IP. Eine Anwendung,beispielsweise ein Browser, nutzt eine virtuelle Steckdose (Socket),um eine gesicherte Verbindung überTCP zu einer anderen Anwendung wie beispielsweise einen Webserveraufzubauen. Hierzu wird überden Linux Socket Layer ein Socket aufgebaut, über einen Dispatcher DIS-TXdas richtige Protokoll-Modul (hierTCP) ausgewähltund anschließendprotokollgerecht die Nachricht überIP und den Linux Network Layer übergeben.Der Linux Network Layer gibt die Daten an das betreffende Netzwerkgerät ('Network Device'), und die Nachrichtwird beispielsweise überein Modem übertragen.Der Empfang läuftentsprechend umgekehrt, wobei übereinen Dispatcher DIS-RX die empfangenen Nachrichten dem richtigenProtokoll-Modul zugeordnet werden. Diese aus der Internet-Kommunikationbekannte Art zum Aufbau einer Schnittstelle wird nun auf die Kommunikationeiner Fahrzeug-Applikation mit einem Fahrzeug-Bussystem übertragen.
    [0018] Hierzuwird eine CAN- Protokoll-Familie PF_CAN erstellt und im Linux SocketLayer registriert. Die CAN-Protokoll-Familie umfasst die verschiedenenCAN-Protokolle wie beispielsweise CAN_BCM (CAN-Broadcast Manager)für dasSenden und Empfangen von (zyklischen) CAN-Nachrichten, das Netzwerkmanagement,CAN_TP20 als ein möglichesTransportprotokoll und CAN_RAW fürdes Senden und Empfangen von einzelnen CAN-Nachrichten. Dabei können verschiedene Ausprägungen vonCAN_TP-Modulen realisiert sein (z.B. VAG TP2.0, VAG TP1.6, MCNet,OSEK COM, etc.). Des Weiteren kann eine oder mehrere Fahrzeug-ApplikationenFA1 – FAngleichzeitig das selbe CAN_TP-Modul nutzen. Ausserdem kann eineFahrzeug-Applikation gleichzeitig auch mehrere unterschiedlicheCAN_TP-Module nutzen. Gleiches gilt für die anderen Module. Analogder Verteilung bei der Internet-Protokoll-Familie PF_INET teiltder Dispatcher-TX einer Nachrichten-Sendung von einer Fahrzeug-ApplikationFA1 – FAndas richtige CAN-Protokoll-Modul zu. Die protokollgerechte Nachrichtwird dann an den Linux Network Layer übermittelt, der das zuständige Netzwerkgerät ('Network Device') can0 – can3,lin0-lin1, vcan0 zur Übertragungauswählt.Durch das Vorhandensein der verschiedenen NetzwerkgerätetreiberTypA – TypC können dieverschiedensten CAN-Controller TypA – TypC von verschiedenen Herstellernim Fahrzeug-Bussystem verbaut werden, ohne dass sich etwas an derSchnittstelle zum Network Layer ändert.Sind dabei physikalisch die gleichen CAN-Controller verbaut (wiebeispielsweise bei FB0 und FB1), so kann unter dem Netzwerkgerät can0 bzw.can1 jeweils der gleiche Netzwerkgerätetreiber TypA implementiertwerden. Die Übertragungvon Daten von den Fahrzeug-Bussystemen FB1 – FBn zu den Fahrzeug-ApplikationenFA1 – FAnerfolgt entsprechend umgekehrt. Der durch die Erfindung erreichte Vorteilbesteht insbesondere darin, dass nunmehr der Entwickler bzw. Programmierereiner Fahrzeug-Applikation FA1 – FAnkeinerlei Detail-Kenntnisse mehr über die einzelnen CAN-Protokolleverfügenmuss. Dies wiederum führtdazu, dass die Programme an Komplexität abnehmen, was Fehlersucheund damit einhergehend die Zuverlässigkeit erhöht.
    [0019] Diessoll an einem Beispiel zum Öffneneines Transportkanals erläutertwerden.
    [0020] Wieleicht erkennbar, benötigtder Programmierer keinerlei interne Kenntnisse über das Transportprotokoll.Dieser muss nur wissen, welche Fahrzeug-Bussysteme vorhanden sindund wie diese bezeichnet werden (hier can1).
    [0021] Nebenden NetzwerkgerätetreibernTypA – TypCist ein virtueller Netzwerkgerätetreiberfür dasNetwork Device 'vcan' zu erkennen. Dieserdient dazu, dass eine Applikation eine Nachricht generiert und diese nichtphysikalisch auf das Fahrzeug-Bussystem gesendet wird bzw. einenentsprechenden Bus-Controller zur Übertragung übergeben, sondern unterhalbdes Linux Network Layer wieder analog einer empfangenen Nachricht über denNetwork Layer zu einer auf dem lokalen System vorhandenen Fahrzeug-Applikation übertragen wird.Dies ermöglichtfrühzeitigin der Entwicklung, wo häufignoch die Hardware nicht zur Verfügungsteht, einzelne Fahrzeug-Applikationen zu testen und auch das Zusammenspielvon Fahrzeug-Applikationen zu überprüfen. Dadie generierten und empfangenen Nachrichten jeweils die Protokoll-Schichtdurchlaufen, kann somit softwaretechnisch die Fahrzeug-Applikation unterrealen Bedingungen getestet werden.
    [0022] Wiebereits erläutert,dient der Dispatcher DIS-RX zum Verteilen empfangener Nachrichtenauf die richtigen CAN-Protokolle. Dabei übernimmt der Dispatcher DIS-RXgleichzeitig eine Filterfunktion, indem dieser nur CAN-Botschaftenmit einem Identifier weiterleitet, die eine der Fahrzeug-Applikationenbenötigt.Prinzipiell ist es jedoch auch möglich,die Filterfunktion eines CAN-Controllers zu nutzen, soweit der verwendete Contollerdie entsprechende Funktionalitätanbietet. In diesem Fall würdeder Dispatcher DIS-RX weniger unbenötigte CAN-Nachrichten empfangen,wodurch sich der Verarbeitungsaufwand reduziert.
    [0023] Nebender CAN-Protokoll-Familie PF_CAN ist die Packet-Protokoll-FamiliePF_PACKET dargestellt. Mittels dieser Protokoll-Familie können einfachePakete durch den Linux Socket Layer und den Linux Network Layergeschleust werden. Ein Socket der PF_PACKET-Familie besitzt ähnlicheFunktionalitätwie der CAN_RAW-Socket der PF_CAN-Familie, bietet jedoch nicht dieCAN-spezifische beschriebene Filterung von CAN-Nachrichten. AnalogeRAW-Protokolle lassensich auch fürandere Fahrzeugbusse in der jeweiligen Protokollfamilie (z.B. PF_LIN,PF_FLEXRAY, etc) realisieren.
    [0024] Weitersei angemerkt, dass die Internet-Protokoll-Familie, weil ohnehinbereits vorhanden, auch fürdie Fahrzeug-Applikationen genutzt werden kann, beispielsweise umbestimmte Informationen aus dem Internet abzurufen.
    权利要求:
    Claims (6)
    [1] Schnittstelle zur Kommunikation zwischen Fahrzeug-Applikationenund Fahrzeug-Bussystemen,umfassend einen Fahrzeugrechner mit einem Betriebsystem, wobei dasBetriebssystem einen Socket Layer und einen Network Layer aufweist,wobei mindestens ein hardware-abhängiger Netzwerkgerätetreiberunterhalb des Network Layers angeordnet ist, dadurch gekennzeichnet,dass mindestens ein Fahrzeug-Bus-Protokoll innerhalb einer Protokoll-Familiezwischen dem Socket Layer und dem Network Layer implementiert ist.
    [2] Schnittstelle nach Anspruch 1, dadurch gekennzeichnet, dassdie Netzwerkgerätetreibermindestens teilweise als CAN-Treiber ausgebildet sind, wobei für unterschiedlicheCAN-Controller jeweils ein eigener Netzwerkgerätetreiber vorhanden ist.
    [3] Schnittstelle nach Anspruch 1 oder 2, dadurch gekennzeichnet,dass mindestens ein Netzwerkgerätetreiberimplementiert ist, mittels dessen eine virtuelle Verbindung zwischenzwei Fahrzeug-Applikationen (FA1 – FAn) über den Network Layer realisierbarist.
    [4] Schnittstelle nach einem der vorangegangenen Ansprüche, dadurchgekennzeichnet, dass mindestens ein Transportprotokoll (CAN_TP)des Fahrzeug-Bussystems und/oder ein weiteres Netzwerkmanagement-, oderBroadcast-Protokoll (CAN_BCM) zwischen dem Socket-Layer und demNetwork Layer angeordnet ist.
    [5] Schnittstelle nach Anspruch 4, dadurch gekennzeichnet, dasszwischen dem Network Layer und den Protokoll-Modulen ein Dispatcher(DIS-RX) zugeordnet ist.
    [6] Schnittstelle nach Anspruch 4 oder 5, dadurch gekennzeichnet,dass zwischen dem Socket Layer und den Protokoll-Modulen ein Dispatcher(DIS-TX) angeordnet ist.
    类似技术:
    公开号 | 公开日 | 专利标题
    US20200310782A1|2020-10-01|Gateway device, in-vehicle network system, and firmware update method
    US10735260B2|2020-08-04|Gateway device, firmware update method, and recording medium
    US9762429B2|2017-09-12|Control protocol encapsulation
    US5432907A|1995-07-11|Network hub with integrated bridge
    US7983250B2|2011-07-19|Method and communications system for transmitting information in a motor vehicle
    US7447728B1|2008-11-04|Method and apparatus supporting network communications
    KR100699701B1|2007-03-27|Home-Network Automatic Configuration
    US9912531B2|2018-03-06|Data logging or stimulation in automotive Ethernet networks using the vehicle infrastructure
    US7603266B2|2009-10-13|Generic emulator of devices in a device communications protocol
    DE10026918B4|2004-09-30|Virtueller Netzwerkadapter
    US5710908A|1998-01-20|Adaptive network protocol independent interface
    US7835295B2|2010-11-16|Interface module with power over Ethernet function
    CN101216800B|2010-12-29|一种linux日志的管理装置及方法
    US9542302B2|2017-01-10|System and method for remote debugging of an application in an image forming apparatus over a network
    US8032660B2|2011-10-04|Apparatus and method for managing subscription requests for a network interface component
    CN100581207C|2010-01-13|通过usb连接的软件更新
    US7523237B2|2009-04-21|Method and protocol for diagnostics or arbitrarily complex networks of devices
    US20070058670A1|2007-03-15|UDP to TCP bridge
    JP2005006303A|2005-01-06|仮想ネットワーク・アドレス
    EP0330834A2|1989-09-06|Verfahren und Vorrichtung zur Verbindung eines SNA-Hostrechners mit einem entfernten SNA-Hostrechner über ein paketvermitteltes Nachrichtennetz
    EP0330835A2|1989-09-06|Verfahren und Vorrichtung zur Verbindung von SNA-Endgeräten mit einem SNA-Hostrechner über ein paketvermitteltes Nachrichtennetz
    US20040236991A1|2004-11-25|System and method for on-line diagnosing of network interface cards
    US20060268861A1|2006-11-30|Network system and communication method
    JP4038221B2|2008-01-23|Relay device and connection method between client device and server
    EP2351315B1|2018-05-02|Virtualisierungsplattform
    同族专利:
    公开号 | 公开日
    DE102004020880B4|2014-10-09|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    法律状态:
    2005-11-17| OR8| Request for search as to paragraph 43 lit. 1 sentence 1 patent law|
    2007-01-11| 8105| Search report available|
    2011-06-16| R012| Request for examination validly filed|Effective date: 20110329 |
    2011-06-16| 8110| Request for examination paragraph 44|
    2014-05-08| R016| Response to examination communication|
    2014-06-23| R018| Grant decision by examination section/examining division|
    2014-07-10| R082| Change of representative|
    2015-07-10| R020| Patent grant now final|
    2015-11-03| R119| Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee|
    优先权:
    申请号 | 申请日 | 专利标题
    DE200410020880|DE102004020880B4|2004-04-26|2004-04-26|Interface for communication between vehicle applications and vehicle bus systems|DE200410020880| DE102004020880B4|2004-04-26|2004-04-26|Interface for communication between vehicle applications and vehicle bus systems|
    [返回顶部]