Subsections

• CAL
• CANopen

CAN Protokolle

An dieser Stelle wird die Bezeichung ,,CAN Protokolle`` ausschließlich für Protokolle des OSI Layer 7 (Application Layer, s. Kap. A4) verwendet. Das Protokoll des CAN Data-Link Layer der ISO 11898 unterstützt nur die Übertragung und Anfrage von bis zu 8 Datenbytes. Praktische Anwendungen benötigen aber meist mehr als 8 Datenbytes. Auch ist häufig eine Initialisierung und Verwaltung der CAN-Knoten notwendig. Ein Application Layer Protokoll sollte also die folgenden Aufgaben erfüllen:

• Transparente Übertragung von Daten
• Vergabe der Identifier (ID's)
• Network Management (z.B. Hochfahren des Netzwerks)
• Synchronisation
• Übermitteln einer Zeitbasis

Im Automobilbereich wird von jedem Hersteller ein eigener Application Layer verwaltet, der i.d.R. nicht an dritte freigegeben wird. Beispiele hierfür sind:

• der Komfort-Bus bei Audi
• der I-, K-, M-Bus bei BMW
• der Comfort-Bus bei Mercedes

In der industriellen Automatisierungtechnik ist ein anderer Weg gegangen worden. Hier bemüht sich eine eigene Nutzerorganisation ,,CAN in Automation e.V.`` (CiA e.V.) um die Standardisierung einiger weniger Protokolle. So wurde 1992 von der CiA Benutzergruppe die Spezifikation eines allgemein akzeptierten Application-Layer-Protokolls besonders für industrielle Systeme initiiert. Dazu wurde ein bereits existierendes und getestetes Protokoll von Philips Medical Systems übernommen und erweitert. 1993 wurde dies von der CiA als ,,CAN Application Layer (CAL)`` [2, DS 201 ... 207] herausgegeben.

Neben CAL unterstützt CiA die folgenden Protokolle, die in verschiedenen Ländern ihren Ursprung und Einsatz haben:

• CANopen (Europa)
• CAN Kingdom (Skandinavien)
• DeviceNet (USA von Rockwell/Allen Bradley)
• Smart Distributed System (SDS) (von Honeywell)

CANopen ist aus CAL heraus entwickelt worden und stellt eine Vereinfachung dar. Diese beiden Protokolle sollen im folgenden kurz betrachtet werden.

CAL

  Neben den beiden Basisdiensten des CAN Data-Link Layer bietet CAL eine offene Umgebung für offene Standard Netzwerk Lösungen. CAL bietet vier Application Layer Service Elemente:

• CAN based Message Specification (CMS)
• Network Management (NMT)
• Identifier Distributor (DBT)
• Layer Management (LMT)

Der in jedem Netzwerk vorhandene CAN-Master stellt diese Dienste zur Verfügung und verwaltet damit alle im Netzwerk vorhandenen Clients. Weitere Informationen können der CiA Dokumentation [2, DS 201 ... 207] entnommen werden. CAL ist ein älteres Protokoll, aus dem CANopen entstanden ist. Es gibt viel Parallelen, so daß hier nicht näher auf CAL eingegangen werden soll.

CANopen

  Die Spezifikationen von CANopen in [3, DS 301] beschreiben einen minimalen Funktionsumfang, den jeder Knoten erfüllen muß. So muß z.B. jeder Knoten ein Objektverzeichnis kennen, in dem alle für diesen Knoten relevanten CANopen-Objekte eingetragen sind. Lesende und schreibende Zugriffe erfolgen mit einem Service Data Object (SDO). Sie werden für Änderungen im Objektverzeichnis und für Statusabfragen verwendet. Jeder CANopen Knoten hat mindestens ein SDO, dem zwei CAN-Identifier zugeordnet sind. Mit dem ,,Multiplexed Domain Transfer Protocol`` der CAL Definition lassen sich Daten beliebiger Länge übertragen. Die Daten werden ggf. auf mehrere CAN-Nachrichten aufgeteilt (segmentiert). In der ersten CAN-Nachricht des SDO sind vier Byte mit Protokollinformationen belegt. Bei Nachrichten bis 4 Byte Länge genügt folglich eine einzige CAN-Nachricht. Für Daten mit mehr als 4 Byte erfolgt eine Aufteilung auf mehrere Nachrichten, bei der ab der 2. CAN-Nachricht jeweils 7 Byte für Nutzdaten zur Verfügung stehen. Jedes SDO wird vom Empfänger durch eine entsprechende CAN-Nachricht bestätigt. Insgesamt entsteht ein nicht unerheblicher Overhead durch das Protokoll.

Für die Übertragung von Prozeßdaten kommen die Process Data Objects (PDO) zur Anwendung. Es wird das ,,Stored Event Protocol`` von CAL verwendet. Dem Knoten stehen dabei alle 8 Datenbytes der CAN-Nachricht zur Verfügung. PDO's werden im Gegensatz zu den SDO's unbestätigt übertragen, da der CAN Data-Link Layer (OSI Layer 2) eine fehlerfreie Übertragung sicherstellt. Dadurch steht den PDO's die maximale Busbandbreite ohne den Protokolloverhead der SDO's zur Verfügung. Dies ist besonders bei zeitkritischen Anwendungen wichtig.

Die Zuordnung der CAN-Identifier erfolgt automatisch mit Hilfe der eingestellten Knotennummer und der definierten Objekte (COB's, s. Tabelle 4.1). PDO's haben demnach eine höhere Priorität als die SDO's. Die höchste Priorität ist für das Netzwerk-Management (NMT) vorgesehen, mit dem das Netzwerk gestartet und gestoppt wird. Die COB-ID's werden in Klassen (Priority Level) aufgeteilt (s. Tabelle A5.1). Die anderen definierbaren Objekte, wie EMERGENCY, SYNC usw., sind optional. Ein ,,Minimum Capability Device``, also ein Knoten mit minimalem Funktionsumfang, muß zumindest die Dienste bzw. COB's NMT, SDO und PDO unterstützen.

 

 

Objekt function code COB-IDs Priority Level (binär)

NMT 0000  0   0 

SYNC 0001 128  0 

TIME STAMP 0010 256 1

EMERGENCY 0001 129 .. 255 0, 1

PDO1 (tx) 0011 385 .. 511 1, 2

PDO1 (rx) 0100 513 .. 639 2

PDO2 (tx) 0101 641 .. 767 2, 3

PDO2 (rx) 0110 769 .. 895 3, 4

SDO (tx) 1011 1409 .. 1535 6

SDO (rx) 1100 1537 .. 1663 6, 7

Nodeguard 1110 1793 .. 1919 -

Neben dem Protokoll sind in CANopen auch die empfohlenen Datenraten und die daraus folgenden maximalen Buslängen und Bitzeiten definiert (s. Tabelle A5.2). Jeder CANopen Knoten muß 20 KBit/s unterstützen, da mit dieser Datenrate das Netzwerk initialisiert wird.