Home

News

Schnelleinstieg

Hintergrund

Doku

Bilder

Download

Forum

Kontakt

1 Einführung

1.1 Beschreibung der Ziele

Es soll ein Aktor/Sensor-Bussystem auf der Basis der CAN-Protokoll-Spezifikation 2.0A (Basis-Norm: ISO 11898) erstellt werden, das zum Beispiel im privaten Bereich (Grundstück, Haus, Wohnung) Automationsaufgaben übernehmen kann. Zu diesen zählen unter anderem zum Beispiel Beleuchtungssteuerungen, Jalousiesteuerungen, Temperaturmessstellen usw.. Die gesetzen Entwicklungsziele, die den Umfang der Studienarbeit bestimmen, werden im folgenden genauer definiert. Doch zunächst ein paar Worte zur Wahl des CAN-Bussystems.

Aufgrund des angestrebten Einsatzgebietes des Aktor/Sensor-Bussystems musste die Busspezifikation, auf dem das System basieren sollte, folgende Anforderungen erfüllen:

·         Überwindung mittlerer Entfernungen von ca. 100 bis 300 Metern zwischen den einzelnen Busteilnehmern

·         Multimasterfähigkeit

·         hohe Übertragungssicherheit

·         einfaches Übertragungsprotokoll

·         leichte Realisierbarkeit der Hard- und Software durch allgemein verfügbare Standardkomponenten und Programmierumgebungen

·         hohe Verfügbarkeit des Busses selbst bei Ausfällen einzelner Knoten

·         mittlere bis geringe Bauteilkosten

·         gute Beschaffbarkeit der benötigten Komponenten

·         gute und kostenlose Zugänglichkeit zu Informations- und Dokumentationsmaterialien

·         Anzahl der Busknoten möglichst groß (ca.100)

Mit den verfügbaren Komponenten (CAN-Controller, Leitungstreiber) für das CAN-Bus-System können die obigen Anforderungen erfüllt werden.

CAN ist ein serielles Bussystem mit Multi-Master-Fähigkeit. Das bedeutet, alle Busteilnehmer sind beim Buszugriff gleichberechtigt und können Daten nach Bedarf senden und empfangen. In CAN-Netzwerken werden keine Adressen für die Busteilnehmer verwendet, sondern prioritätsbehaftete Nachrichtenobjekte. Dies bedeutet, dass ein sendender Teilnehmer eine Nachricht über den Bus an alle anderen angeschlossenen Busteilnehmer sendet (Broadcasting). Jeder empfangende Busteilnehmer entscheidet auf der Basis eines Akzeptanzfilters, der Identifikationsnummern beinhaltet, ob das empfangene Nachrichtobjekt relevant für ihn ist. Trifft dies zu, so wird das Nachrichtenobjekt in dem Busteilnehmer weiter verarbeitet. Ist dies nicht der Fall, so wird das Nachrichtenobjekt verworfen. Die Identifikationsnummern im Akzeptanzfilter (auch Identifier genannt) entscheiden auch über die Prioritäten der Nachrichten, welche essenziell für die Busarbitration sind (CAN benutzt das Buszugriffsverfahren Carrier Sense Multiple Access / Collision Avoidance , kurz CSMA/CA). Gegenstand der ISO-Norm 11898, sowie darauf aufbauender Erweiterungsstandards, ist ein serielles Bussystem mit Echtzeitfähigkeiten und sie spezifiziert die untersten beiden Schichten des ISO/OSI Referenzmodells. Wir nutzen für unsere Zwecke aus dieser Spezifikation die Physikalische Schicht (Physical Layer, Schicht 1), sowie die Datensicherungsschicht (Data Link Layer, Schicht 2). Die Komponenten dieser beiden Schichten sind auf dem Markt leicht erhältlich. [1]

1.1.1 Entwicklungsziele

1.1.1.1 Definition der Entwicklungsziele

Es wurden folgende Ziele definiert:

a)       Es soll eine Hardware entwickelt werden (nachfolgend nur noch als "Buskoppler" bezeichnet), die folgende Anforderungen bzw. Aufgaben erfüllt:

·           Auf diesen Buskoppler soll modular eine beliebige Applikationshardware aufgesetzt werden können.

·           Ein Busteilnehmer / Knoten bestehend aus Buskoppler in Kombination mit der jeweiligen Applikationshardware soll verschiedene Steuer-, Mess- und/oder Visualisierungsaufgaben übernehmen können.

·           Der Buskoppler soll den Informationsaustausch der Busteilnehmer / Knoten untereinander über die Busleitung ermöglichen.

b)       Es soll eine Applikationshardware entwickelt werden (nachfolgend nur noch als "I/O-Applikation" bezeichnet), die folgende Anforderungen bzw. Aufgaben erfüllt:

·           Durch die I/O-Applikation sollen vier binäre Eingänge und vier binäre Ausgänge realisiert werden.

c)       Es soll eine Applikationshardware entwickelt werden (nachfolgend nur noch als "RS232-Applikation" bezeichnet), die folgende Anforderungen bzw. Aufgaben erfüllt:

·           Die RS232-Applikation soll die Bus-Ankopplung eines Rechners ermöglichen, welcher mit geeigneter Software als aktiver Busteilnehmer agieren kann.

Abbildung 1.1: Blockschema des Bus-Systems

Um die einzelnen Punkte zu verdeutlichen, werden diese nun etwas genauer ausgeführt.

1.1.2 Detaillierte Beschreibung der Entwicklungsziele

1.1.2.1 Der Buskoppler

Der Buskoppler stellt die Kernhardware des Bus-Systems dar. Er soll die Kommunikation über die Busleitung ermöglichen und in Kombination mit der Applikationshardware die speziellen für den jeweiligen Busteilnehmer / Knoten vorgesehenen Funktionen erfüllen (z.B. Steuer-, Mess- und/oder Visualisierungsaufgaben). Er besteht prinzipiell aus drei Funktionsblöcken, die in Abbildung 1.2 dargestellt sind.

Abbildung 1.2: Blockschema des Buskopplers

Block 1 bildet die Busschnittstelle. Sie besteht aus der Datensicherungsschicht und der physikalischen Schicht. Sie wird von dem ihr übergeordneten Block 2, dem Bus- und Applikationsmanagement, verwaltet und sendet die von Block 2 erhaltenen Daten auf den Bus, bzw. empfängt die über den Bus für Block 2 eintreffenden Daten und stellt diese zur weiteren Verarbeitung bereit. Die Busschnittstelle ist vollkommen vom Bus- und Applikationsmanagement abhängig und würde ohne Block 2 nicht sinnvoll funktionieren.

Block 3 bildet die Applikationsschnittstelle. Auf diese Schnittstelle wird die Applikationshardware aufgesetzt, die auch von dem ihr übergeordneten Block 2 verwaltet wird. Die Applikationshardware bestimmt die eigentliche Funktion des jeweiligen Busteilnehmers wie zum Beispiel die schon vorher aufgeführten Steuer-, Mess- und/oder Visualisierungsaufgaben. Auch die Applikationsschnittstelle ist vollkommen vom Bus- und Applikationsmanagement abhängig und würde ohne Block 2 nicht sinnvoll funktionieren. Die im Rahmen dieser Arbeit  vorgesehenen Applikationen, die auf diese Schnittstelle aufgesetzt werden können, sind die I/O-Applikation und die RS232-Applikation.

Block 2 ist der eigentliche Kern des Buskopplers. Er initialisiert, verwaltet und verwendet die ihm in den Blöcken 1 und 3 zu Verfügung stehende Hardware um die vorgesehene Funktion des von ihm dargestellten Busteilnehmers zu realisieren. Er verarbeitet die Daten bzw. die Informationen, die er von der Applikation bzw. über die Busleitung erhält und leitet sie entsprechend weiter.

1.1.2.2 Die Applikationshardware

Die Applikationshardware bestimmt durch ihre Eigenschaften die Funktion des Busteilnehmers. Die jeweiligen Applikationsschaltungen werden einfach mit einer Steckverbindung auf den Buskoppler aufgesetzt und erfüllen sodann, in Verbindung mit dem Buskoppler, die für den Busteilnehmer vorgesehenen Aufgaben (siehe Abbildung 1.3).

Abbildung 1.3: Schema eines Busteilnehmers

Die I/O-Applikation

Mit Hilfe der I/O-Applikation soll ein Busteilnehmer realisiert werden, der vier binäre Eingänge und vier binäre Ausgänge zur Verfügung stellt. Die binären Eingänge werden durch den Buskoppler zyklisch abgefragt und ausgewertet. Nach der Auswertung werden entsprechende Nachrichtentelegramme über den Bus gesendet. Treffen beim Buskoppler Nachrichtentelegramme zur Zustandsänderung eines binären Ausgangs ein, so gibt dieser den geforderten Ausgangszustand am betreffenden Ausgang aus. Abbildung 1.4 zeigt das Blockschema der I/O-Applikation.

Abbildung 1.4: Blockschema der I/O-Applikation

Die RS232-Applikation

Mit Hilfe der RS232-Applikation soll ein Busteilnehmer realisiert werden, der die Anbindung eines Rechners an das Bussystems ermöglicht. Die Verbindung zwischen RS232-Applikation und Rechner wird mittels einer RS232-Schnittstelle realisiert. Mit geeigneter Software kann der so angebundene Rechner dann als aktiver Busteilnehmer agieren (siehe Abbildung 1.5).

Abbildung 1.5: Blockschema der RS232-Applikation

Eine ausführliche Dokumentation der einzelnen Hardwarekomponenten, sowie all ihrer Bestandteile ist in den Kapiteln Hardware, Software und Datenblattsammlung zu finden.

1.2 Einführung in das CAN Übertragungsprotokoll und die physikalische Schicht

1.2.1 Allgemeine Beschreibung des Controller-Area-Networks (CAN)

1.2.1.1 Bustopologie, Datenrate, Anzahl der Teilnehmer

CAN basiert auf einer linienförmigen Topologie. Über Repeater oder Router sind baumartige Topologien und hierarchische Netzstrukturen möglich. Die Anzahl der Teilnehmer pro Netz ist nicht durch das Protokoll begrenzt, sondern abhängig von der Leistungsfähigkeit der eingesetzten Leitungstreiber. Repeater ermöglichen darüber hinaus eine Erweiterung der Anzahl der Netzknoten. Die bei einer bestimmten Datenrate maximale Netzausdehnung ist im wesentlichen durch die auf dem Busmedium erforderliche Signallaufzeit begrenzt. Bei 1MBit/s ist z.B. eine Netzausdehnung von 40m, bei 80kBit/s eine Netzausdehnung von 1000m möglich. Neben dem Einsatz von Zweidrahtleitungen sind auch Lösungen auf Basis von Lichtwellenleitern möglich.

1.2.1.2 Nachrichtenorientiertes Protokoll

Das CAN-Protokoll basiert nicht auf einem Datenaustausch durch Adressierung des Nachrichtenempfängers, sondern erfolgt durch Kennzeichnung einer übertragenen Nachricht über eine Nachrichtenkennung (Nachrichten-Identifier, Identifier). Alle Netzknoten prüfen anhand der Kennung einer empfangenen Nachricht, ob diese für sie relevant ist. Nachrichten können daher von keinem, einem, vielen oder allen Teilnehmern übernommen werden (Multicasting, Broadcasting). Über die in einigen Protokoll-Controllern integrierten Möglichkeiten der Nachrichtenfilterung können Teilnehmer von der Übernahme nicht interessierender Nachrichten entlastet werden (FullCAN-Funktionalität). Enthalten die Protokoll-Controller diese Möglichkeit nicht, so unterstützen sie nur BasicCAN-Funktionalität.

1.2.1.3 Priorisierung von Nachrichten

Da der Identifier einer Nachricht gleichzeitig dessen Priorität in bezug auf den Buszugriff bestimmt, ist es möglich, Nachrichten entsprechend ihrer Wichtigkeit einen entsprechend schnellen Buszugriff zu ermöglichen. Besonders wichtige Nachrichten können damit unabhängig von der augenblicklichen Busbelastung den Zugang zum Bus mit kurzer Latenzzeit erlangen. Diese Eigenschaft stellt auch in Ausnahmesituationen (z.B. bei länger andauernden Störeinwirkungen) sicher, dass besonders wichtige Nachrichten bevorzugt übertragen werden, um auch in Phasen eingeschränkter Transportkapazität die Funktion eines Systems sicherzustellen. Eine derartige Behandlung von Überlastsituationen ist in anderen Buskonzepten kaum möglich.

1.2.1.4 Multi-Master-Fähigkeit

Die Vergabe des Buszugriffsrechts erfolgt nicht durch eine übergeordnete Steuereinheit (Busmaster) pro Netzwerk. Vielmehr kann jeder Teilnehmer gleichberechtigt mit dem Senden einer Nachricht beginnen, sobald der Bus frei geworden ist. Im Rahmen eines Arbitrierungsprozesses erhält bei gleichzeitigem Zugriff mehrerer Teilnehmer jener Teilnehmer das Buszugriffsrecht, welcher die augenblicklich höchstpriore Nachricht senden will. Jeder Teilnehmer kann damit direkt mit jedem anderen Teilnehmer kommunizieren. Da das Senden einer Nachricht von der Nachrichtenquelle selbst veranlasst werden kann, erfolgt bei ereignisgesteuerter Nachrichtenübertragung eine Busbelegung nur dann, wenn eine neue Nachricht vorliegt. Hieraus resultiert gegenüber einem Bussystem mit deterministischem Buszugriff (z.B. Master-Slave-Prinzip) eine wesentlich niedrigere mittlere Busbelastung.

1.2.1.5 Verlustlose Busarbitrierung

Da der Buszugriff im CAN-Protokoll zufällig erfolgt, ist es möglich, dass gleichzeitig mehrere Teilnehmer den Bus belegen möchten. Bei anderen zufälligen Buszugriffsverfahren (z.B. Carrier Sense Multiple Access / Collision Detection, kurz CSMA/CD bei Ethernet-Netzen) kommt es hierbei zu einer Zerstörung der aufgeschalteten Nachrichten. Die Auflösung des Buszugriffkonflikts erfordert eine wiederholte Belegung des  Busses im Rahmen einer Auflösungsstrategie. Im CAN-Protokoll kommt deshalb ein Verfahren zum Einsatz, das garantiert, dass die zum jeweiligen Zeitpunkt höchstpriore Nachricht ohne Zerstörung von Nachrichteninhalten gesendet wird (CSMA/CA).

1.2.1.6 Nachrichten-Telegrammlänge

Die maximale Datenlänge einer CAN-Nachricht ist auf 8 Byte begrenzt. Die Begrenzung der Nachrichtenlänge auf wenige Bytes ist erforderlich, um einerseits eine (bei gegebener Baudrate) möglichst hohe Nachrichtenrate zu erhalten und andererseits eine möglichst kurze Latenzzeit für den Buszugang anderer Nachrichtenobjekte zu gewährleisten. Für ein CAN-Netzwerk mit 8 Byte langen Nachrichteninhalten beträgt die maximal mögliche Latenzzeit für die höherpriore Nachricht 130 Bitzeiten. Besondere Bedeutung kommt einer möglichst kurzen Nachrichtenlänge jedoch vor allem dann zu, wenn die Übertragung in stark gestörter Umgebung stattfindet, da die Wahrscheinlichkeit für das Einfangen einer Störung proportional mit der Telegrammlänge zunimmt.

1.2.1.7 Erkennung und Abschaltung defekter Teilnehmer

Das CAN-Protokoll beinhaltet die Überwachung der kommunikationsspezifischen Funktion von Netzknoten insoweit, dass ein defekter Teilnehmer den Datenverkehr auf dem Bus nicht dauernd stören kann. Bei Überschreiten festgelegter mittlerer Fehlerraten werden Maßnahmen ergriffen, die das Einwirken eines betroffenen CAN-Knotens auf den Bus einschränken bzw. den Knoten vom Bus abkoppeln.

1.2.2 Das CAN-Übertragungsprotokoll

1.2.2.1 Prinzip der Busarbitrierung

Bei CAN erfolgt der Buszugriff durch die Busteilnehmer völlig unkoordiniert nach dem Prinzip des dezentralen Buszugriffs. Da die Anforderungen zum Senden einer Nachricht bei den über das Netzwerk verteilten Busteilnehmern im allgemeinen asynchron erfolgt, ist es grundsätzlich möglich, dass mehrere Teilnehmer gleichzeitig mit dem Senden einer Nachricht beginnen. Generell gilt allerdings, dass ein Teilnehmer nur dann den Bus belegen darf, wenn dieser vorher frei war. Die Busteilnehmer erkennen den Belegungszustand des Busses über eine festgelegte Zeitspanne (11 Bitzeiten), innerhalb welcher der Bus auf Ruhepotential sein muss. Immer dann, wenn mehrere Teilnehmer gleichzeitig mit dem Senden einer Nachricht beginnen, wird im Rahmen einer Auswahlphase (Arbitrierungsphase) entschieden, welcher Teilnehmer am Ende der Auswahlphase am Bus verbleiben darf. Ein solcher Buszugriffskonflikt wird durch bitweises Aufschalten des Nachrichtenarbitrierungsfeldes aufgelöst. Das Arbitrierungsfeld einer CAN-Nachricht besteht aus dem Nachrichten-Identifier sowie dem RTR-Bit (Remote Transmission Request Bit), über welches zwischen einem Daten- und einem Datenanforderungstelegramm unterschieden wird. Im CAN-Standardformat hat der Nachrichten-Identifier eine Länge von 11 Bit. Das höchstwertige Bit des Identifiers wird zuerst übertragen.

Grundlage der bitweisen Arbitrierung ist die Unterscheidung von zwei physikalischen Buspegeln, nämlich einem dominanten (überstimmenden) und einem rezessiven (nachgebenden) Pegel. Solange der Bus frei ist, befindet er sich auf rezessivem Pegel. Ein Teilnehmer, der den Bus belegt, signalisiert dies durch Aufschalten eines dominanten Bits (Start-of-Frame, SOF). Während der Arbitrierungsphase vergleicht jeder sendende Teilnehmer den von ihm aufgeschalteten Buspegel mit dem tatsächlichen auf dem Bus vorhandenen Pegel. Jeder Teilnehmer, der ein rezessives Bit gesendet hat und ein dominantes beobachtet, stellt seinen Arbitrierungsversuch sofort ein und wird zum Empfänger der gerade von einem anderen Teilnehmer gesendeten Nachricht. Unter der Vorraussetzung, dass ein Identifierwert nur jeweils einer Nachricht zugeordnet wird, und dass eine logische Null durch einen dominanten Buspegel abgebildet wird, verbleibt am Ende eines Arbitrierungsprozesses daher nur derjenige Teilnehmer am Bus, dessen Nachricht den niedrigsten Identifierwert besitzt. Die Priorität einer Nachricht ist also umso höher, je niedriger der Wert des dieser Nachricht zugeordneten Identifiers ist. Abbildung 1.6 stellt einen solchen Arbitrierungsprozess dar.

Abbildung 1.6: Arbitrierungsvorgang zwischen Teilnehmer 1,2 und 3.

In dem oben gezeigten Diagramm erhält der Busteilnehmer 3 das Buszugriffsrecht. Die im CAN-Protokoll zugrundegelegte bitweise Arbitrierung über den Identifier einer Nachricht stellt also sicher, dass bei gleichzeitiger Belegung des Busses durch mehrere Teilnehmer immer nur ein Teilnehmer am Bus verbleibt. Die von diesem Teilnehmer gesendete Nachricht wird hierbei nicht zerstört. Das Prinzip der bitweisen Arbitrierung basiert drauf, dass ein arbitrierender Teilnehmer den Wert des von ihm aufgeschalteten Bits mit dem tatsächlich auf dem Bus vorhandenen Wert vergleicht. Bei der Festlegung des frühestmöglichen Abtastzeitpunktes nach dem Aufschalten eines Bits auf den Bus müssen daher die maximal möglichen Signallaufzeiten zwischen den Teilnehmern sowie deren interne Signalverzögerungen berücksichtigt werden. Das Verfahren der bitweisen Arbitrierung begrenzt somit bei gegebener Datenrate (d.h. Bitdauer), die maximal mögliche Busausdehnung.

1.2.2.2 Nachrichtenformat

Der Nachrichtentransfer basiert auf vier verschiedenen Telegrammformaten. Dem Datentelegramm (Data Frame), dem Datenanforderungstelegramm (Remote Frame), dem Fehlertelegramm (Error Frame) und dem Überlasttelegramm (Overload Frame). Im folgenden soll nur auf das Datentelegramm weiter eingegangen werden.

Ein Datentelegramm (siehe Abbildung 1.7) besteht aus den Bitfeldern Telegrammanfangskennung (Start-of-Frame, SOF), Arbitrierungsfeld, Steuerfeld, Datenfeld, Datensicherungsfeld (CRC Field), Bestätigungsfeld (Acknowledge Field) sowie Telegrammendekennung (End-of-Frame, EOF). Das Datenfeld kann auch entfallen.

Abbildung 1.7: Standard Daten- und Datenanforderungstelegramm

1.2.2.3 Telegrammanfangskennung (Start-of-Frame, SOF)

Diese kennzeichnet den Beginn eines Datentelegramms (oder Datenanforderungstelegramms) und besteht aus einem dominanten Bit. Ein Busteilnehmer darf mit einer Arbitrierung nur dann beginnen, wenn der Bus im Ruhezustand ist (mindestens 11 Bit rezessiver Buspegel). Über die erste Flanke des Start-Bits werden alle anderen Busteilnehmer auf den Teilnehmer synchronisiert, der als erster mit der Busarbitrierung begonnen hat.

1.2.2.4 Arbitrierungsfeld

Das Arbitrierungsfeld (Abbildung 1.8) besteht aus dem Identifier-Feld (Standard: 11 Bit) und dem RTR-Bit. Über den Identifier wird eine Nachricht gekennzeichnet und deren Priorität bestimmt. Bei einer Standardlänge von 11 Bit ermöglicht das Identifier-Feld eine Unterscheidung von 2¹¹ (2048) Nachrichten. Das MSB-Identifier-Bit (ID-10) wird zuerst übertragen. Über das Anforderungsbit (RTR-Bit) wird zwischen Daten- und Datenanforderungstelegramm unterschieden. Für unsere Anwendung verwenden wir aber vorerst nur das Datentelegramm.

Abbildung 1.8: Arbitrierungsfeld

1.2.2.5 Steuerfeld (Control Field)

Mit den vier niederwertigen Bits des 6-Bit-Steuerfeldes wird die Datenlänge (Data Length Code, DLC) des nachfolgenden Datenfeldes in Bytes angegeben. Ein Wert von 0 entspricht 0 Datenbytes, ein Wert von 8 entspricht 8 Datenbytes (siehe Abbildung 1.9).

Abbildung 1.9: Standard Steuerfeld

1.2.2.6 Datenfeld (Data Field)

Dieses Feld enthält die eigentliche Nutzinformation einer CAN-Nachricht und kann 0 bis 8 Byte umfassen.

1.2.2.7 Datensicherungsfeld (CRC Field)

Das Datensicherungsfeld (Abbildung 1.10) besteht aus einer 15-Bit-Prüfsequenz sowie einem rezessiv übertragenen Begrenzungsbit. Ein Empfänger kann damit nachprüfen, ob eine empfangene Nachricht verfälscht wurde.

Abbildung 1.10: Datensicherungsfeld

1.2.2.8 Bestätigungsfeld (Acknowledge Field)

Das zwei Bit lange Bestätigungsfeld besteht aus dem sogenannten Acknowledge-Slot (ACK-Slot) und einem Begrenzungsbit (Acknowledge-Delimiter). Der Sender einer Nachricht erwartet die Bestätigung des fehlerfreien Empfangs der gesendeten Nachricht während des Acknowledge-Slots. Alle Empfänger, welche die gesendete Nachricht nach Abschluss der CRC-Prüfung als fehlerfrei erkannt haben, legen hierzu im ACK-Slot einen dominanten Pegel auf den Bus, der Sender selbst schaltet während des ACK-Slots einen rezessiven Pegel auf. Ein empfangender Busteilnehmer, welcher anhand der CRC-Prüfung einen Übertragungsfehler erkannt hat, signalisiert dies im Anschluss an das ACK-Feld. Damit ist es möglich, dass ein Sender im ACK-Slot zwar die fehlerfreie Übertragung der Nachricht durch mindestens einen Busteilnehmer bestätigt bekommt, anschließend aber über das von einem lokal gestörten Teilnehmer ausgelöste Fehlertelegramm zur Wiederholung der Nachricht aufgefordert wird. Ein lokales Empfangsproblem kann somit durch im CAN-Protokoll realisierte Fehlerlokalisierungsverfahren erkannt werden. Auf den ACK-Slot folgt immer ein rezessives Begrenzungsbit.

Abbildung 1.11: Bestätigungsfeld

1.2.2.9 Telegrammendekennung (End-of-Frame, EOF)

Jedes Datentelegramm (und Datenanforderungstelegramm) wird durch eine Bitsequenz von 7 rezessiven Bits abgeschlossen. Zusammen mit dem ebenfalls rezessiven ACK-Begrenzungsbit ergibt sich somit insgesamt eine Folge von 8 rezessiven Bits am Ende eines Daten- oder Anforderungstelegramms.

1.2.3 Die physikalische Schicht

1.2.3.1 Signalcodierung

Der Signalcodierung auf der CAN-Busleitung liegt die NRZ-Codierung mit Bitstuffing (Stuffweite 5) zugrunde. Diese Signalcodierung erstreckt sich über die Telgrammelemente SOF, Arbitrierungs-, Steuer- und Datenfeld, sowie der CRC-Sequenz eines CAN-Daten- bzw. Datenanforderungsrahmens. Die verbleibenden Telegrammsegmente eines Daten- oder Datenanforderungstelegramms haben eine festgelegte Form und werden ohne Bitstuffing übertragen, ebenso wie Fehler- und Overloadtelegramme.

1.2.3.2 Zusammenhang zwischen Baudrate und Buslänge

Aufgrund der beim CAN-Protokoll angewendeten Busarbitrierungs- und Fehlererkennungsmechanismen ist die in einem Netzwerk maximal mögliche Baudrate abhängig von der räumlichen Ausdehnung des Netzwerks. Die folgende Grafik verdeutlicht diesen Zusammenhang. Abbildung 1.12 zeigt schematisch (nicht maßstäblich) den Zusammenhang.

Abbildung 1.12: Abhängigkeit: Baudrate(Leitungslänge)

1.2.3.3 Busmedien

Grundvoraussetzung für das Busmedium ist die zu realisierende Darstellbarkeit von rezessivem und dominantem Signalpegel. Dies bedeutet, dass Busmedium und Busanschaltung das Prinzip des "wired-and" ermöglichen müssen. Eine einfache Realisierbarkeit dieses Prinzips ist bei elektrischen und optischen Busmedien gegeben.