doc/intro.tex

   1 % $Id$
   2
   3 \newpage
   4 \section{Einleitung}
   5 \label{intro}
   6
   7 Im Rahmen verschiedener Projekte wurde in der Konzernforschung der
   8 Volkswagen AG
   9 ein so genanntes \LLCF\ (\LL) entwickelt, das den einfachen Zugriff
  10 auf die Kommunikationsschichten des {\it Controller Area Network}
  11 (CAN) für Anwendungen erlaubt.  Das \LLCF\ sollte dabei möglichst
  12 modular konzipiert werden, um eine möglichst große
  13 Wiederverwendbarkeit in weiteren Projekten zu erreichen.\\
  14
  15 Wesentliche Komponenten des \LL\ sind die Netzwerk(!)-Treiber für die
  16 verschiedenen CAN-Controller und die darüberliegenden Protokolle wie
  17 TP1.6,
  18 TP2.0, MCNet, ISO-TP, etc.  Diese Komponenten sind im Linux-Kernel
  19 implementiert und  werden über die standardisierte
  20 Socket-Schnittstelle angesprochen. Das Ziel dieses Konzeptes liegt
  21 darin, die Kommunikation über
  22 den CAN-Bus soweit wie möglich an die Benutzung gewöhnlicher
  23 TCP/IP-Sockets anzupassen.  Dies gelingt jedoch nur zum Teil, da der
  24 CAN-Bus eine Reihe von Unterschieden zur Kommunikation mit TCP/IP und
  25 Ethernet aufweist:
  26
  27 \begin{itemize}
  28 \item CAN kennt keine Geräte-Adressen wie die MAC-Adressen beim Ethernet.
  29   Das CAN-Frame enthält eine CAN-ID, die durch die übliche
  30   Zuordnung von zu sendenen CAN-IDs zu realen Endgeräten am ehesten einer
  31   Absender-Adresse entspricht.  Weil alle Nachrichten
  32   Broadcast-Nachrichten sind, ist es auch nicht möglich, eine
  33   CAN-Nachricht nur an ein Gerät zu senden. Geräte am CAN-Bus können
  34   empfangene Nachrichten also nicht nach Zieladressen, sondern nur
  35   nach der CAN-ID 'Absenderadresse' filtern. CAN-Frames können daher
  36   nicht - wie beim Ethernet - explizit an ein bestimmtes Zielgerät
  37   gerichtet werden.
  38
  39 \item Es gibt keinen Network Layer und damit auch keine
  40   Network-Layer-Adressen wie IP-Adressen. Folglich gibt es auch kein
  41   Routing (z.B. über verschiedene Netzwerk-Interfaces), wie es mit
  42   IP-Adressen möglich ist.
  43 \end{itemize}
  44
  45 \begin{figure}[htbp]
  46 \begin{center}
  47
  48 \psfig{file=frame_types.eps}
  49
  50 \caption{Unterschiedliche Adressierungen bei Ethernet /  CAN}
  51 \label{figure:frame_types}
  52 \end{center}
  53 \end{figure}
  54
  55 Diese Unterschiede führen dazu, dass die Struktur
  56 \verb|struct sockaddr_can| sich nicht ganz analog zu der bekannten
  57 \verb|struct sockaddr_in| für die TCP/IP-Protokollfamilie verhält.
  58 Der Ablauf eines Verbindungsaufbaus und die Benutzung geöffneter
  59 Sockets zum Datenaustausch sind jedoch stark an TCP/IP angelehnt.
  60
  61 Neben diesem Dokument sind daher auch die Manual Pages
  62 \man{socket}{2}, \man{bind}{2}, \man{listen}{2},
  63 \man{accept}{2}, \man{connect}{2}, \man{read}{2},
  64 \man{write}{2}, \man{recv}{2}, \man{recvfrom}{2},
  65 \man{recvmsg}{2}, \man{send}{2}, \man{sendto}{2},
  66 \man{sendmsg}{2}, \man{socket}{7}, \man{packet}{7} eines
  67 aktuellen Linux-Systems für das \LL\ relevant.  Außerdem bieten die
  68 Manual Pages \man{ip}{7}, \man{udp}{7} und \man{tcp}{7} einen
  69 Einblick in Grundlagen, auf denen auch das \LL\ basiert.
  70
  71 \newpage
  72 Das \LLCF\ ist neben den bekannten Protokollen, wie z.B. den
  73 Protokollen der Internetprotokollfamilie PF\_INET im Linux-Kernel
  74 integriert. Dazu wurde eine neue Protokollfamilie PF\_CAN
  75 eingeführt. Durch die Realisierung der verschiedenen CAN-Protokolle
  76 als Kernelmodule, können zeitliche Randbedingungen im Kernel-Kontext
  77 eingehalten werden, die auf der Anwenderschicht in dieser Form nicht
  78 realisierbar wären. Für verschiedene Anwendungen (was zu mehreren
  79 Socket-Instanzen führt) kommt immer derselbe Code zur Ausführung.\\
  80
  81 \begin{figure}[htbp]
  82 \begin{center}
  83
  84 \psfig{file=llcf_overview.eps}
  85
  86 \caption{Das \LL\ im Linux-Kernel}
  87 \label{figure:llcf_overview}
  88 \end{center}
  89 \end{figure}
  90
  91 Das \LL\ stellt für die verschiedenen Transportprotokolle und einen
  92 so genannten \BCM\ (\BC) eine Reihe verschiedener Socket-Typen
  93 zur Verfügung.  Außerdem ist ein RAW-Socket vorgesehen, der den
  94 direkten Zugriff auf den CAN-Bus ohne dazwischenliegende
  95 Protokollschichten erlaubt.
  96
  97 \newpage
  98 Eine Besonderheit stellt der so genannte RX-Dispatcher des \LL\
  99 dar. Durch die Art der Adressierung der CAN-Frames kann es
 100 mehrere 'Interessenten' an einer empfangenen CAN-ID geben. Durch die
 101 \LL-Funktionen rx\_register() und rx\_unregister() können sich die
 102 Protokollmodule beim \LL-Kernmodul für ein oder mehrere CAN-IDs von
 103 definierten CAN-Netzwerkgeräten registrieren, die ihnen beim Empfang
 104 automatisch zugestellt werden. Das \LL-Kernmodul sorgt beim Senden auf
 105 den CAN-Bus auch für ein lokales Echo ('local loopback') der zu
 106 versendenden CAN-Frames, damit für alle Applikationen auf einem System
 107 die gleichen Informationen verfügbar sind.
 108
 109
 110 \begin{figure}[htbp]
 111 \begin{center}
 112
 113 \psfig{file=llcf_module.eps}
 114
 115 \caption{Das \LL-Kernmodul im Linux-Kernel}
 116 \label{figure:llcf_module}
 117 \end{center}
 118 \end{figure}
 119
 120 Für die Anbindung der CAN-Netzwerktreiber wurde ein neuer
 121 'Ethernet-Protokoll-Typ' ETH\_P\_CAN eingeführt, der die Durchleitung
 122 der empfangenen CAN-Frames durch die Linux-Netzwerkschicht
 123 sicherstellt. Das \LL-Kernmodul meldet sich dazu als Empfänger von
 124 ETH\_P\_CAN-'Ethernetframes' beim Kernel an.\\
 125
 126 Durch die konsequente Realisierung der Anbindung des CAN-Busses mit
 127 Schnittstellen aus der etablierten Standard-Informationstechnologie
 128 eröffnen sich für den Anwender (Programmierer) alle Möglichkeiten, die
 129 sich auch sonst bei der Verwendung von Sockets zur Kommunikation
 130 ergeben. D.h. es können beliebig viele Sockets (auch verschiedener
 131 Socket-Typen auf verschiedenen CAN-Bussen) von einer oder mehreren
 132 Applikationen gleichzeitig geöffnet werden. Bei der Kommunikation auf
 133 verschiedenen Sockets kann beispielsweise mit \man{select}{2} auf
 134 Daten aus den einzelnen asynchronen Kommunikationskanälen
 135 ressourcenschonend gewartet werden.
 136