Lehrstuhl für 22. August 2000 Hochspannungstechnik und elektrische Anlagen

Entwicklung und Aufbau eines CAN-Feldbussystems für die Steuerungstechnik

Zur dezentralen Steuerung von Aktoren und zur Erfassung von analogen und digitalen Sen-sorsignalen werden Feldbussysteme eingesetzt. Diese Systeme sind äußerst komplex und damit kostenintensiv. Bedingt durch die Verfügbarkeit applikationsspezifischer integrierter Schaltkreise ist eine wesentliche Vereinfachung des Aufbaus möglich. Die hohe Funktionsdichte dieser Bausteine erlaubt, Geräte mit vielschichtigen Eigenschaften robust und auch kostengünstig aufzubauen.

Herr Nause erhält die Aufgabe, ein modulares, kostengünstiges und störunempfindliches Feldbussystem für die Steuerungstechnik mit einer Schnittstelle zum Internet zu entwickeln und aufzubauen. Das Feldbussystem soll dabei aus einem Busmaster und mehreren Knotenpunkten bestehen. Um eine komfortable Fernwartung zu ermöglichen, soll die Schnittstelle vom Busmaster zu einem übergeordneten Steuerrechner mit dem TCP/IP-Standard realisiert werden. Der Steuerrechner soll auf alle dezentralen I/O-Module Zugriff haben und den kompletten Prozeß abbilden. Dabei sollen weder spezielle Funktionskarten noch spezifische Gerätetreiber eingesetzt werden. Die Übertragung der Feldbusdaten soll gegebenenfalls auch über Schleifleitungen erfolgen. Dabei ist mit erheblichen EMV-Problemen insbesondere im Bereich der inneren EMV zu rechnen. Zur Sicherstellung der ordnungsgemäßen Funktion ist auf die korrekte Führung von Signal- und Energieleitungen zu achten. Aufgrund der zu erwartenden Störgrößen soll die Störfestigkeit untersucht werden.

Im einzelnen wird für die Bearbeitung folgendes Vorgehen empfohlen:

1. Literaturrecherche

2. Auswahl geeigneter Hardwarekomponenten

3. Entwurf und Realisierung der Schaltungen

4. Funktionsnachweis

5. Untersuchung der Störfestigkeit

6. Ausarbeitung

Die Ausarbeitung hat nach den Richtlinien des Lehrstuhles zu erfolgen; das einzureichende Exemplar bleibt Eigentum des Lehrstuhles.

Bei Arbeiten mit Hochspannung sind die Sicherheitsrichtlinien des Lehrstuhles zu beachten.

Ausgabe: 01.05.2000 Abgabe: 01.11.2000

Betreuer: Dipl.-Ing. Tycho Weißgerber

Dipl.-Ing. Uwe Sondhof (Lehrstuhl für Förder-und Lagerwesen, Maschinenbau)

Übersicht

In der vorliegenden Arbeit wird der Aufbau und die Programmierung eines Feldbussystems für die Steuerungstechnik beschrieben. Die entwickelten Feldbus-Knoten zeichnen sich durch eine modulare und kompakte Bauweise aus. Als Feldbus wird das Controller Area Network (CAN) eingesetzt, das sich durch eine weite Verbreitung in der Automatisierungstechnik und eine Vielzahl preiswerter Controller auszeichnet.

Es sind zwei Modulvarianten entwickelt worden: SLIO-Knoten (Serial Linked I/O) und Master-Knoten. Beide Varianten verfügen über sieben digitale und drei analoge Ein- und Ausgänge. Die SLIO-Knoten basieren auf einem Philips-CAN-Baustein mit wenig Eigenintelligenz, während die Master-Knoten einen DOS-kompatiblen Einchip-PC und einen hochintegrierten CAN-Protokoll-Controller beinhalten und damit genügend Rechenkapazität für anspruchsvolle Automatisierungsaufgaben besitzen. Die Master-Module sind über eine Ethernet-Schnittstelle mit anderen Automatisierungs-Rechnern vernetzbar. Insbesondere ist über einen eingebauten Webserver eine Visualisierung, Bedienung und Fernwartung des gesamten Feldbussystems über herkömmliche Internetbrowser möglich.

Die Arbeit umfaßt zusätzlich eine Marktübersicht über CAN-Controller, Mikrocontroller mit CAN-Schnittstellen und CAN-Transceiver. Es werden Maßnahmen zur Sicherstellung der elektromagnetischen Verträglichkeit geschildert, die zu einer unerläßlichen Aufgabe bei der Planung und beim Aufbau von elektronischen Systemen geworden sind. Eigene Störfestigkeits-Prüfungen und Störemissions-Messungen belegen die Wirksamkeit der vorgenommenen Maßnahmen.

Inhalt 4

Inhalt   

  Übersicht  3

Inhalt   4

Einleitung   6

1.  Feldbusse in der Automatisierungstechnik.  7

1.1.  Einsatzgebiete, Merkmale  7

1.1.1  Profibus  8

1.1.2  InterBus-S.  9

1.1.3  Controller Area Network.  10

1.2.  Internettechnologien in der Automatisierungstechnik  10

2.  CAN - Controller Area Network  12

2.1.  Protokoll.  12

2.1.1  Busstruktur.  12

2.1.2  Busarbitrierung, Identifier  12

2.1.3  Nachrichtentelegramm-Formate  14

2.1.4  Fehlermanagement  15

2.1.5  Überlast-Telegramme.  17

2.1.6  Bittiming und Bitsynchronisation.  17

2.1.7  Physikalische Ankopplung  18

2.2.  Marktübersicht Protokollcontroller und Transceiver.  19

3.  Aufbau CAN-Feldbus-Knoten  22

3.1.  Übersicht  22

3.2.  Basisplatine  24

3.3.  Masterplatine  26

3.4.  SLIO-Platine.  32

3.5.  Schnittstellenadapter.  33

3.6.  Tischgehäuse  34

3.7.  Netzteil  34

4.  Programmierung  36

4.1.  Übersicht  36

4.2.  Eigene Typ-Deklarationen  38

4.3.  Kommunikation SC12-SJA1000  39

4.4.  Kommunikation SC12-I 2 C-Peripherie  41

4.4.1  Initialisierung  41

4.4.2  I/O-Baustein PCF8574A  42

4.4.3  D/A-Wandler AD5311  43

4.4.4  A/D-Wandler AD7417  43

4.4.5  EEPROM M24C16  45

4.5.  Interruptverarbeitung  45

4.5.1  Übersicht.  45

4.5.2  SJA1000-Interrupt.  46

4.5.3  Timer-Interrupt  47

4.6.  Timer, Ablaufsteuerung  47

Inhalt 5

4.7.  CAN-Kommunikation.  49

4.8.  SLIO-Knoten.  50

4.8.1  Identifier, Telegrammformate, I/O-Register  50

4.8.2  Digitale I/O-Verarbeitung  53

4.8.3  Analoge I/O-Verarbeitung  53

4.8.4  Synchronisierung  53

4.8.5  Softwareroutinen.  54

4.9.  Web-Interface  55

5.  Elektromagnetische Verträglichkeit  58

5.1.  Übersicht  58

5.2.  Maßnahmen zur EMV.  58

5.2.1  Schaltungstechnik  58

5.2.2  Überspannungsschutz.  60

5.2.3  Leiterplattenlayout  60

5.3.  Störfestigkeitsprüfung.  61

5.4.  Störemissionsmessungen  64

5.5.  Zusammenfassung  66

6.  Zusammenfassung und Ausblick  67

7.  Literatur- und Quellenverzeichnis.  68

Anhang 71   

A1  Stromlaufpläne  71

A2  Platinendokumentation.  78

A3  Stücklisten  90

A4  Jumper  101

A5  Register SJA1000  102

A6  Quelltexte (in diesem Dokument nicht enthalten)  

Einleitung

Die moderne Automatisierungstechnik ist gekennzeichnet durch eine zunehmende Dezentralisierung von Verarbeitungs- sowie Ein- und Ausgabefunktionen über Datenkommunikationssysteme [Etsch, S. 1]. Zum Einsatz kommen immer häufiger Feldbusse, die die herkömmliche parallele Verdrahtung von Sensoren und Aktoren durch serielle digitale Bussysteme ersetzen. Das Einsparpotential wird auf ca. 40 % geschätzt [Rath]. Eine dominierende Rolle hat dabei das von Bosch spezifizierte Controller Area Network (CAN) [Bosch1]. Ursprünglich für die Vernetzung von Kraftfahrzeugelektronik-Komponenten entwickelt, hat sich gezeigt, daß CAN ebenso gut für den schnellen Transfer kleiner Datenmengen in der Automatisierungstechnik geeignet ist [Pfei], wie sie beispielsweise bei der Ankopplung einfacher E/A-Module oder kleiner dezentraler Steuerungen entstehen.

Der massenhafte Einsatz von intelligenten CAN-Controllern in Kraftfahrzeugen ermöglicht die Entwicklung von preiswerten und hochintegrierten CAN-Modulen. Die in dieser Arbeit vorgestellten CAN-Feldbusknoten tragen dabei dem Bedarf nach kompakten Automatisierungsmodulen mit einer geringen Anzahl von I/O-Klemmen Rechnung. Die hohe Granularität der Feldbusmodule gestattet eine effiziente Konfigurierbarkeit und Erweiterbarkeit des Automatisierungssystems.

Das Bedürfnis, Informationen in Automatisierungsumgebungen vom Feldbereich bis zur Betriebsleitung verfügbar zu machen, führte zur Einführung von Ethernet TCP/IP in der Automatisierungstechnik. Die hier beschriebenen Module ermöglichen über ihre Ethernet-Schnittstelle die problemlose Kopplung des Feldbusses mit der Steuer- und Leitebene einer Industrieanlage. Damit ist die Integration des Automatisierungssystems in den gesamten Informationsfluß eines Unternehmens möglich [Mül, S. 74].

1. Feldbusse in der Automatisierungstechnik

1.1. Einsatzgebiete, Merkmale

Die Dezentralisierung in der Automatisierungstechnik erfolgte in zwei Phasen. Als erstes wurde die konventionelle Parallelverkabelung von Sensoren und Aktoren ersetzt durch eine Busverkabelung. Durch diese Vorgehensweise wurde eine erhebliche Kostenersparnis erzielt. In einem zweiten Schritt entfiel auch die Parallelverkabelung der Leistungsversorgung von Schaltgeräten und Pneumatik-Aktoren, die mittlerweile durch Energiebusse ver-sorgt werden [Foe]. Große Teile zentraler Steuerungen werden zunehmend durch dezentrale Verarbeitungssysteme ersetzt, die mit seriellen Bussystemen vernetzt werden. Die verbleibenden Teile der zentralen Steuerungsprogramme werden dadurch kürzer und reaktionsschneller.

Verschiedene Hersteller haben unabhängig voneinander eigene Bussysteme für die Automatisierungstechnik entwickelt. Diese Systeme werden als Feldbusse bezeichnet.

Betrachtet man die in einem typischen Produktionsbetrieb eingesetzte kommunikationstechnische Infrastruktur, erkennt man die hierarchische Unterteilung in verschiedene Netzwerkebenen, die die Automatisierungsebenen des Betriebes widerspiegeln (Abbildung 1). Jede Ebene bildet dabei ein eigenständiges Kommunikationssystem mit Schnittstellen zu über- und untergelagerten Systemen. Feldbusse werden typischerweise in der Feld- und Prozeßebene eingesetzt. In dieser Ebene sind die für die Erfassung, Steuerung und direkte Beeinflussung von Prozeßgrößen erforderlichen Geräte angesiedelt.

Abbildung 1: Automatisierungspyramide [Eil]

Prinzipielle Unterscheidungsmerkmale der verschiedenen Feldbussysteme sind die Art des Buszugriffs (stochastisch oder deterministisch per Master/Slave oder Token), die Netzaus- dehnung, die Teilnehmerzahl, die Bustopologie (Linie, Ring, Baum etc.) und die Datenra-

ten. Diese Merkmale werden anhand der folgenden Betrachtung einiger Feldbussysteme näher erläutert.

Die Vielzahl der auf dem Markt erhältlichen Systeme darf nicht darüber hinwegtäuschen, daß nur wenige Systeme Marktrelevanz besitzen. Daher werden in dieser Arbeit die im deutschsprachigen Raum am häufigsten eingesetzten Feldbussysteme Profibus, InterBus-S und Controller Area Network genauer betrachtet [Boe].

1.1.1 Profibus

Profibus (Process Field Bus) wurde 1987 bis 1991 von verschiedenen Firmen und Forschungseinrichtungen entwickelt. Das System wird in verschiedenen Ausprägungen (Profibus-FMS, -DP und -PA) von der Feldebene bis zur Leitebene eingesetzt. Als Bustopologie wird eine geschirmte, verdrillte Zweidrahtleitung (Linienstruktur) nach RS485 mit Datenraten von 9,6 kBit/s bei 1200 m maximaler Leitungslänge und bis zu 12 MBit/s bei max. 100 m verwandt. Das System wird in Segmente mit max. 32 Teilnehmern eingeteilt. Die Segmente werden durch Repeater miteinander verbunden. Zwischen zwei Teilnehmern sind maximal drei Repeater zulässig. Insgesamt können damit 124 Teilnehmer in einem Profibus-Netzwerk betrieben werden.

Der Buszugriff erfolgt nach dem Token-passing-Verfahren. Die Zugriffsberechtigung wird mittels eines speziellen Datentelegramms (Token) reihum von einem Teilnehmer zum nächsten weitergereicht (Abbildung 2). Im Gegensatz zum Master-Slave-Verfahren gibt es bei Token-passing keinen dezidierten Master, der über den Buszugriff entscheidet. Beim Profibus wird eine Kombination aus Token-passing und Master-Slave realisiert. Dazu werden im System mehrere Master und Slaves definiert. Das Token wird nur zwischen den Mastern weitergereicht. Somit sind sowohl Master-Master- als auch M aster-Slave-Kommunikationen möglich.

Master-Master-Kommunikation

Profibus

Abbildung 2: Linienstruktur Profibus [Reiss, S. 68]

Für die Eigenentwicklung von Feldbusmodulen scheint sich Profibus nicht gut zu eignen, da nur komplexe und teure Profibus-Controller in Form von ASICs verfügbar sind:

• AG⋅E GmbH: Rekonfigurierbarer Profibus Master Chip [Age]

• sci-worx GmbH: Profibus Controller PBM [Sci]

• Siemens: Profibus Communication Controller ASPC2 [Sie]

• Uni Hamburg: Multiprotokoll Feldbusprozessor IX0 [UnH]

1.1.2 InterBus-S

InterBus-S wurde 1987 von der Firma Phoenix Contact vorgestellt [Phoe1]. Phoenix Contact ist der alleinige Hersteller und Lieferant dieses Feldbus-Systems. Ursprünglich war der Bus als Achtdraht-Leitung ausgeführt. Mittlerweile wird eine RS485-Anschaltung mit fünf Leitern verwandt. InterBus-S ist eine Kombination aus Ring- und Baumstruktur (Abbildung 3). Das Buskabel wird wie bei einer Baumstruktur verlegt. Es enthält neben einem Bezugsleiter zwei Zweidrahtleitungen als Hin- und Rückleiter, die an den Busenden verbunden werden. So entsteht eine Ringtopologie, in der Datenübertragungsraten von 500 kBit/s erreicht werden. Die maximale Entfernung zwischen zwei Teilnehmern beträgt 400 m, die Gesamtlänge des Bussystems darf eine Strecke von 13 km nicht überschreiten.

Abbildung 3: Kombinierte Ring-/Baumstruktur bei InterBus-S [Etsch, S. 48]

Das bei InterBus-S implementierte Buszugriffsverfahren ist ein spezielles Master-Slave-Verfahren. Es basiert auf einem Ringschieberegister. Ein zentraler Busmaster initiiert in einem Schiebezyklus den Datenaustausch mit sämtlichen Busteilnehmern über ein entsprechend langes Datentelegramm (Summenrahmen). Aufgrund der aus diesem Verfahren resultierenden hohen Protokolleffizienz ist InterBus-S gut geeignet für zeitkritische Anwen- dungen.

InterBus-S-Controller sind ausschließlich von Phoenix Contact [Phoe2] erhältlich:

• InterBusS-Master-Chips IPMS3, UART

• InterBusS-Slave-Chips SUPI1, SUPI2, SUPI3, LPC1, LPC2, IB8052

1.1.3 Controller Area Network

Das Controller Area Network (CAN) wurde 1987 von Bosch als serielles Bussystem für Personen- und Nutzfahrzeuge entwickelt [Bosch1]. Aufgrund seiner Eignung für den Feldbusbereich wird es immer häufiger in der Automatisierungstechnik eingesetzt.

Im folgenden seien die Eigenschaften des Bussystems nur stichpunktartig genannt. Einer genauen Beschreibung des CAN-Protokolls ist Kapitel 2, S. 12 gewidmet.

• Datenrate, Leitungslänge: 50 kBit/s bei 1000 m bis 1 MBit/s bei 40 m

• Bustopologie: Linie, verdrillte Zweidrahtleitung, RS485

• Buszugriffsverfahren: Multi-Master mit verlustloser Busarbitrierung 1

• Priorisierung von Nachrichten

• Sehr geringe Latenzzeit für hochpriore Nachrichten

• Erkennung und Abschaltung defekter Teilnehmer

• Mehrere Fehlererkennungsmechanismen

CAN ist das Feldbussystem mit den meisten Protokoll-Controllern und Mikrocontrollern mit entsprechender Schnittstelle. Die Marktübersicht in Kapitel 2.2, S. 19 verdeutlicht dies. Die durch den Einsatz in der Kraftfahrzeugtechnik bedingten hohen Stückzahlen führen zu niedrigen Chip-Preisen. Aus diesem Grund und der weiten Verbreitung in der Automatisierungstechnik, basieren die in dieser Arbeit erstellten Feldbusmodule auf dem CAN-Protokoll.

1.2. Internettechnologien in der Automatisierungstechnik

So wie in der Feld- und Prozeßebene Feldbusse als Kommunikationsstandard gelten, haben sich in der Leit- und Betriebsebene die aus der Bürokommunikation stammenden Netzwerke auf Ethernet-TCP/IP-Basis etabliert. Die Kopplung dieser Bussysteme ist unabdingbar, um dem Bedürfnis nach transparenter Kommunikation Rechnung zu tragen. Im Rahmen der heutigen Qualitätssicherungs-Bestrebungen und Just-In-Time-Lieferketten, ist die

¹ CSMA/CA-Verfahren: Carrier Sense Multiple Access/Collision Avoidance

genaue Kenntnis und Beeinflussung aller Prozeßgrößen zu jeder Zeit erforderlich. Die zunehmende Dezentralisierung der Automatisierungsaufgaben erschwert aber gerade die Kommunikation zwischen den Automatisierungsebenen. Aus diesem Grund zeichnet sich ein Trend zur Vereinheitlichung der Kommunikationstechnologien ab.

Mit der Verfügbarkeit echtzeitfähiger Industrial Ethernet Systeme steht nun eine Technologie bereit, die es ermöglichen soll, alle Automatisierungsebenen bis in den Feldbereich hinein zu vernetzen. Ob Industrial Ethernet die bestehenden Feldbussysteme tatsächlich ersetzen wird, ist umstritten [Mark]. Es werden allerdings zunehmend Gateways implementiert, die eine Kopplung von Feldbussystemen mit dem Ethernet ermöglichen.

Durch die Vernetzung der Automatisierungssysteme mit Ethernet-TCP/IP ist die Kopplung von Internettechnologien mit der Automatisierungstechnik möglich geworden. So sind Anwendungen erstellt worden, die die Visualisierung von Prozeßgrößen über Standard-Webbrowser gestatten. Auch der umgekehrte Weg, die Fernsteuerung und Fernwartung des Prozesses vom Webbrowser aus, ist möglich. Der entscheidende Vorteil ist, daß auf der Client-Seite keine Spezialsoftware notwendig ist. TCP/IP ist der Standard in der Intranet-und Internetkommunikation, so daß hier lediglich Implementierungen auf der Automatisie- rungsseite notwendig sind.

2. CAN - Controller Area Network

2.1. Protokoll

Das Controller Area Network ist ein hochleistungsfähiges, robustes und preisgünstiges Feldbussystem. Es ermöglicht sowohl zeitkritische Verbindungen mit hohen Datenraten als auch Vernetzungen mit kleinen Bitraten (Tabelle 1).

Tabelle 1: CAN-Bus-Applikationsbereiche im Kraftfahrzeug [Law, S. 15]

Der CAN-Bus hat in der Zwischenzeit über den Einsatz in der Fahrzeugtechnik hinaus eine große Bedeutung in der Vernetzung dezentraler intelligenter Systeme, Sensoren und Aktoren in der Automatisierungstechnik gefunden. Mit über 20 Millionen installierten Knoten ist CAN das führende Feldbussystem geworden [Reiss, S. 189] ¹ .

2.1.1 Busstruktur

Hauptmerkmal von CAN ist die Multi-Master-Struktur. Jeder Busteilnehmer (Knoten) darf mit der Nachrichtenübertragung beginnen, sobald der Bus frei ist. Im Gegensatz zu anderen Bussystemen braucht der Teilnehmer nicht warten, bis er eine Sendeberechtigung erhält. Somit ist kein Teilnehmer bevorrechtigt, es gibt keine Bus-Master. Wenn in dieser Arbeit trotzdem der Begriff Master verwandt wird, soll damit seine Rolle als Busknoten mit höherer Rechenkapazität und als Kalibrierungs-Host (siehe Kapitel 4.8.4, S. 53) unterstrichen werden.

2.1.2 Busarbitrierung, Identifier

Die Nachrichtenübertragung auf dem CAN-Bus ist objektorientiert. Anstatt alle Teilnehmer mit einer Adresse zu versehen, werden die Nachrichten mit einer Kennung (Identifier) markiert. Alle Bus-Teilnehmer empfangen die Nachrichten und werten sie aus, sofern sie für sie von Bedeutung sind. Der Identifier ist gemäß der CAN Spezifikation 2.0A [Bosch2]

¹ 1998 wurden rund 100 Millionen CAN-Chips verkauft [Markt, S. 26].

11 bit lang. Es sind damit 2048 unterschiedliche Nachrichtenobjekte möglich ¹ . Dieses Standard-Frame-Format wurde 1991 in der CAN 2.0B-Spezifikation auf 29 bit-Identifier erweitert. Mit dem Extended-Frame-Format können 2 ²⁹ ≈ 537 Mio. Nachrichten unterschieden werden. Beide Frame-Formate sind kompatibel zueinander. Es können in einem Netzwerk Nachrichten beider Formate existieren, sofern die eingesetzten CAN-Bausteine die Spezifikation 2.0B zumindest passiv unterstützen (Kapitel 2.2, S. 19).

Falls zwei Busteilnehmer den Bus frei vorfinden und gleichzeitig mit der Nachrichtenübertragung beginnen, findet eine Buskollision statt. Das CAN-Protokoll sieht für diesen Fall eine prioritätsorientierte Busarbitration ² vor. Die zwei möglichen Bitzustände auf dem Bus werden als dominanter und rezessiver Bitpegel definiert. Ein dominantes Bit überschreibt ein rezessives. Physikalisch wird diese Vorgabe durch eine Wired-AND-Verschaltung von Open-Collector-Bustreibern erreicht (Abbildung 4).

Definiert man ein rezessives Bit mit 1 und ein dominantes Bit mit 0, wird anhand der Logiktabelle (Tabelle 2) deutlich, daß der Bus nur rezessiven Pegel annimmt, wenn alle Eingänge rezessiv sind. Sobald ein Eingang einen dominanten Pegel liest, liegt auch der Bus auf dominantem Pegel.

+5V

Busleitung

Tabelle 2: Wired-AND-Logiktabelle

Abbildung 4: Wired-AND-Schaltung

Da jeder Teilnehmer in der Arbitrierungsphase den Buszustand mitliest, kann er sofort an-hand des Vergleichs von gesendetem und gelesenem Bit prüfen, ob eine Buskollision vorliegt. Falls er eine Kollision bemerkt, stellt er seinen Sendeversuch sofort ein. Dieses Verfahren hat den Vorteil, daß Buskollisionen nicht zu Sendeabbrüchen beider Teilnehmer führen. Da während der Busarbitrierung der Nachrichtenidentifier gesendet wird, stellt nur der Teilnehmer seine Nachrichtensendung ein, dessen Nachricht die geringere Priorität hat.

¹ Zugelassen sind nur die Identifier 0...2031, der Rest ist reserviert.

² Arbitrium (lat.): Schiedsspruch.

Da der Bitzustand 0 dominant ist, ist die Priorität der Nachrichten mit dem kleinsten Identifier am größten.

2.1.3 Nachrichtentelegramm-Formate

Es gibt vier verschiedene CAN-Telegramm-Formate:

• Datentelegramm (Data Frame): Die Datenübertragung erfolgt von einem Sender zu einem oder mehreren Empfängern auf Initiative des Senders.

• Datenanforderungstelegramm (Remote Frame): Ein Busteilnehmer fordert das Senden einer bestimmten Nachricht an.

• Fehlertelegramm (Error Frame): Ein Busteilnehmer signalisiert einen Busfehler.

• Überlasttelegramm (Overload Frame): Ein Busteilnehmer fügt zwischen zwei Nachrichten ein Telegramm ein, um die Datenübertragung zu verzögern.

CAN-Telegramme bestehen aus mehreren Feldern, die aus einem oder mehreren Bits bestehen. Abbildung 5 zeigt exemplarisch den Aufbau von Datentelegrammen.

CAN 2.0A (11 bit-Identifier)

rezessiv

dominant

CAN 2.0B (29 bit-Identifier)

rezessiv

dominant

Abbildung 5: Aufbau CAN-Datentelegramm

Im folgenden werden einige wichtige Einzelheiten von Data Frames und Remote Frames aufgezeigt. Die genauen Telegramm-Definitionen sind den Spezifikationen zu entnehmen [Bosch2].

Jedes Telegramm beginnt mit einem Startbit, auf dessen fallende Flanke sich alle Busteilnehmer synchronisieren und endet mit einem End Of Frame-Feld, das aus zehn rezessiven Bits besteht. Im Arbitrierungsfeld befindet sich der Identifier und das RTR-Bit, das einen Data Frame (RTR=0) von einem Remote Frame (RTR=1) unterscheidet. Das IDE-Bit un- terscheidet ein Standard- (IDE=0) und ein Extended Frame (IDE=1). Beim Extended Fra-

me ist der Identifier in einen Basis-Identifier (11 bit) und einen Extended-Identifier (18 bit) aufgespalten. Das Steuerfeld enthält binär codiert die Anzahl der Datenbytes im Datenfeld. Es sind 0...8 Datenbytes möglich. Remote Frames enthalten keine Datenbytes, da sie lediglich eine Sendeaufforderung signalisieren. Selbst Data Frames ohne Datenbytes sind sinnvoll, da auch der Empfang einer Nachricht mit einem bestimmten Identifier schon Informationsgehalt besitzt. Die Bits r0 und r1 des Steuerfeldes sind reserviert. Das CRC-Feld besteht aus einer 15 bit Prüfsumme zur Fehlererkennung und einem Begrenzungsbit. Das Acknowledge-Feld (ACK-Slot) enthält ein Acknowledge-Slot-Bit und ein Begrenzungsbit. Der ACK-Slot wird vom Sender mit einem rezessiven Pegel belegt. Hat ein Empfänger eine Nachricht korrekt empfangen, setzt er den ACK-Slot noch während der laufenden Nachrichtenübertragung auf dominanten Pegel. Weitere Einzelheiten zur Fehlerbehandlung werden im nächsten Kapitel 2.1.4 angeführt. Nach dem Acknowledge-Feld folgt das schon genannte End Of Frame-Feld.

2.1.4 Fehlermanagement

Im CAN-Protokoll werden im Gegensatz zu anderen Bussystemen keine Quittungen ver-sandt, sondern eventuell aufgetretene Fehler per Fehlertelegramm signalisiert. Da bereits ein Teilnehmer ausreicht, um das ACK-Bit auf dominanten Pegel zu setzen, ist mit dieser Verfahrensweise nicht sichergestellt, daß alle Teilnehmer eine Nachricht korrekt empfangen haben. Aus diesem Grunde ist im CAN-Protokoll ein sehr effektives Fehlermanagement implementiert. Es ist in der Lage, fünf verschiedene Fehler zu erkennen:

1. Mit Hilfe des CRC-Verfahrens (Cyclic Redundancy Check) wird auf der Sende- und Empfangsseite jeweils eine Prüfsumme gebildet [Reiss, S. 93]. Bei Nichtübereinstimmung liegt ein CRC-Fehler vor.

2. Der Message Frame Check überprüft die Struktur eines empfangenen Daten-Telegramms, indem die Bitfelder mit dem definierten Format verglichen werden. Außerdem wird die Telegrammlänge überprüft.

3. Wenn der Sender einer Nachricht im ACK-Slot keinen dominanten Pegel liest, wurde das Telegramm von keinem anderen Teilnehmer auf dem Bus korrekt empfangen.

4. Jeder Teilnehmer der sendet, überwacht gleichzeitig den Buspegel und kann somit jederzeit Differenzen zwischen dem gesendeten und empfangenen Bit feststellen. Diese Verfahrensweise wird als Bit-Monitoring bezeichnet.

5. Beim CAN-Protokoll wird zur Bitcodierung das NRZ-Verfahren eingesetzt (Non Return to Zero). Dabei bleibt der Signalpegel über die gesamte Bitzeit konstant. Da die CAN-Teilnehmer aber auf häufige Signalwechsel angewiesen sind um sich auf den Bittakt synchronisieren zu können, wird nach fünf aufeinanderfolgenden gleichwertigen Bits ein so- genanntes Stuffbit mit komplementärem Wert in den Bitstrom eingefügt. Das Stuffbit wird

vom Empfänger automatisch entfernt. Die Einhaltung der Bit-Stuffing-Regel wird vom Empfänger überwacht.

Jeder Teilnehmer, der einen der vorgenannten Fehler erkannt hat, setzt sofort ein Fehlertelegramm ab. Dieses Fehlertelegramm besteht aus einer Folge von sechs dominanten Bits. Da diese sechs Bits eine Verletzung der Bit-Stuffing-Regel darstellen, wird die Nachricht von jedem anderen Busteilnehmer sicher erkannt [Law, S. 54ff.]. Diese Teilnehmer werden durch das Fehlertelegramm veranlaßt, ihrerseits Fehlertelegramme abzusetzen (sekundäre Fehlersignalisierung). Je nach dem Zeitpunkt, zu dem die anderen Teilnehmer die Fehlerbedingung erkennen, entsteht somit eine Folge dominanter Pegel mit einer Länge von 6 bis 12 bits [Etsch, S. 64].

Damit dauerhafte lokale Störungen nicht dazu führen, daß der Bus durch Fehlertelegramme blockiert wird, wechseln CAN-Teilnehmer nach einer bestimmten Anzahl von erkannten Fehlern vom Error-Active-Zustand (Normalzustand) in den Error-Passive-Zustand. Befindet sich ein Knoten in diesem Zustand, kann er nur noch Fehlertelegramme mit einer Folge von sechs rezessiven Bits versenden. Auf diese Weise markiert er lediglich seine eigenen Telegramme als ungültig, kann aber den Bus nicht mehr blockieren. Detektiert er weiterhin Busfehler, wechselt er nach einer gewissen Zeit in den Bus-Off-Zustand. In diesem Zu-stand hat er sich komplett vom Bus abgekoppelt und kann nur durch einen Soft- oder Hardware-Reset wieder in den Error-Active-Zustand wechseln.

Die einzelnen CAN-Fehlerzustände und Übergangsbedingungen zeigt das Zustandsdiagramm Abbildung 6.

REC: Empfangsfehler-Zähler, TEC: Sendefehler-Zähler

Abbildung 6: CAN-Fehlerzustandsdiagramm

Die im Zustandsdiagramm aufgeführten Empfangs- und Sendefehler-Zähler sind Bestandteil jedes CAN-Controllers. Das Inkrementieren und Dekrementieren der Zählerstände ist abhängig von den erkannten Fehlern und ausführlich in [Law, S. 57ff.] erklärt.

2.1.5 Überlast-Telegramme

Mit Überlasttelegrammen signalisieren CAN-Teilnehmer, daß sie kurzfristig nicht in der Lage sind, neue Nachrichten zu empfangen. Die Telegramme bestehen aus einer Folge von sechs dominanten Bits und werden, im Gegensatz zu Fehlertelegrammen, nicht sofort, sondern im Telegrammzwischenraum (Interframe Space) zwischen Daten- und Datenanforderungstelegrammen versandt. Die Versendung neuer Nachrichten verzögert sich dadurch um die Länge des Überlasttelegramms.

2.1.6 Bittiming und Bitsynchronisation

Der Bitstrom der CAN-Telegramme wird synchron übertragen. Das heißt, das eine Erkennung des Zeittaktes nur möglich ist, wenn sich der Signalpegel zwischen zwei Bits ändert. Es reicht nicht aus, sich auf die Einhaltung der Bit-Stuffing-Regel zu beschränken, die dafür sorgt, daß spätestens nach fünf Bitzeiten ein Signalwechsel erfolgt. Um sicherzustellen, daß der empfangene Bitstrom auch in Worst-Case-Fällen richtig synchronisiert wird, ist der Synchronisations- und Abtastzeitpunkt bei allen CAN-Controllern programmierbar. In [Etsch, S. 87ff.] wird gezeigt, wie eine Bitzeit in verschiedene Zeitsegmente aufgeteilt werden muß, um alle Forderungen zu erfüllen (Abbildung 7). Während des Synchronisationssegmentes sollte eine S ynchronisation erfolgen. Das Signalausbreitungssegment b erücksichtigt die Signalausbreitung über die Busleitung sowie die Signalverzögerungen in den Sende- und Empfangsschaltungen. Die Phasensegmente stellen Zeitpuffer für die zeitlich vorgezogene bzw. verspätete Abtastung durch Phasenabweichungen der Sende- und Empfangs-Oszillatoren dar.

Abbildung 7: Aufteilung des Bitzeitintervalls in Segmente gemäß ISO99-1 [Etsch, S. 88]

In Tabelle 3, S. 18 ist der Zusammenhang zwischen der gewünschter Baudrate, der maximalen Leitungslänge und dem optimalen Abtastzeitpunkt dokumentiert. Zugrundegelegt wird eine Protokollcontroller-Oszillatorfrequenz von 16 MHz, ein Synchronisationssegment von einem Zeitquantum (1 tq) und ein Phasen-Puffer-Segment der Länge 2 tq. Die nominelle Bitzeit bt ist der Kehrwert der Baudrate. Teilt man die Bitzeit bt in a konstante Zeitquanten ein, gilt , wobei tl der Länge eines Zeitquantums tq entspricht. tl a bt ⋅ =

Tabelle 3: Baudrate, maximale Netzausdehnung und optimaler Abtastzeitpunkt [CiA2, S. 4]

Konkrete Berechnungsbeispiele zur Ermittlung der Bittiming-Parameter sind in [Etsch, S. 419ff.] und [Bosch3] wiedergegeben.

2.1.7 Physikalische Ankopplung

Die physikalische Ankopplung ist bei CAN nicht durch das Protokoll definiert. So sind verschiedene elektrische und optische Busmedien im Einsatz. Elektrische Busmedien können aus Eindraht- oder Zweidrahtleitungen oder aus Bussen mit Übertragung von Hilfsenergie bestehen. In der Automatisierungstechnik hat sich die Verwendung von Zweidrahtleitungen durchgesetzt (Abbildung 8). Sie ermöglichen eine symmetrische Übertragung und sind dadurch unempfindlich gegen Gleichtaktstörungen.

^R T

Abbildung 8: CAN-Zweidrahtleitung mit n CAN-Knoten und Terminierungswiderständen R T

Zur Anschaltung der CAN-Knoten an das Busmedium dienen Transceiver-Bausteine (Kapitel 2.2, S. 19). Sie wandeln die TTL-Pegel des CAN-Controllers in ein symmetrisches Differenzsignal um (Abbildung 9). Bei einem rezessiven Signal ist CAN_H = CAN_L = 2,5 V und bei einem dominanten Signal gilt CAN_H = 3,5 V und CAN_L = 2,5 V.

Buspegel/V

5 4 3 2 1

Abbildung 9: Nominelle Buspegel gemäß ISO 11898 bei 0 V Gleichtaktspannung [Etsch, S. 113]

Da bei den hohen CAN-Datenraten Wellenausbreitungsphänome auf der Busleitung be- rücksichtigt werden müssen, sind einige Anschlußregeln zu beachten [Law, S. 117]. So

sind Leitungsenden mit Terminierungswiderständen von ca. 120 Ω abzuschließen. Stichleitungen sind so kurz wie möglich zu halten.

In der CAN in Automation (CiA) Draft Recommendation DR-303-1 [CiA3] werden detaillierte Empfehlungen für Buskabel-Typen, Leiterquerschnitte, Terminierungswiderstände und Steckverbinder gegeben. Die Empfehlungen basieren auf der Norm ISO 11898 „Road vehicles - Interchange of digital information - Controller area network (CAN) for highspeed communication“ ¹ .

2.2. Marktübersicht Protokollcontroller und Transceiver

Auf dem Markt sind eine Vielzahl von CAN-Protokollcontrollern und -Transceivern verfügbar. Protokollcontroller sind entweder eigenständige Bausteine oder in Mikrocontrollern oder I/O-Bausteinen integrierte Module. In den Controllern sind sämtliche für die Abwicklung des CAN-Protokolls notwendigen Funktionen implementiert. Ein übergeordneter Rechner (Host-Controller) ist lediglich für die Übergabe von zu sendenden Nachrichten oder die Übernahme von empfangenen Nachrichten erforderlich. I/O-Bausteine mit integriertem CAN-Protokollcontroller werden als SLIO bezeichnet (Serial Linked I/O device). SLIO-Chips werden über den CAN-Bus konfiguriert und gesteuert und verfügen über keine Eigenintelligenz in Form eines Mikrocontrollers oder Prozessors (Kapitel 3.4, S. 32).

Protokollcontroller unterscheiden sich in erster Linie in der Art der Nachrichtenverwaltung und in der Unterstützung des Nachrichtenanforderungsbetriebes [Etsch, S. 129]. So haben sogenannte BasicCAN-Bausteine lediglich je einen Empfangspuffer und Sendepuffer, während FullCAN-Bausteine über mehrere Empfangs- und Sendepuffer verfügen (Abbildung 10, S. 20). BasicCAN-Bausteine haben auf der Empfangsseite eine grobe Vorfilterung. Nur Nachrichten, deren Identifier ein Akzeptanzfilter passiert haben, werden verarbeitet. Auf diese Weise kann eine begrenzte Anzahl verschiedener Nachrichten gefiltert werden. FullCAN-Bausteine haben meist eine exakte Identifier-Vorfilterung, so daß entsprechend viele verschiedene Telegramme abgelehnt werden können. Der übergeordnete Hostrechner wird dadurch weniger belastet [Law, S. 34ff.].

¹ In der Norm ISO 11519-2 wird die low-speed CAN-Variante (5...125 kBit/s) spezifiziert.

Abbildung 10: Übersicht Protokoll-Controller [Har, S. 2]

Die Wahl eines geeigneten Protokoll-Controllers hängt unter anderem vom eingesetzten CAN-Protokoll ab. Controller, die ausschließlich nach der CAN-Spezifikation 2.0A (11 bit-Identifier) arbeiten, können Telegramme mit 29 bit-Identifier nach CAN 2.0B nicht verarbeiten und dürfen nur in 2.0A-Umgebungen eingesetzt werden. Controller mit der sogenannten 2.0B-passiv-Eigenschaft tolerieren 2.0B-Nachrichten, können aber nur 2.0A-Nachrichten verarbeiten. Controller mit 2.0B-aktiv-Eigenschaft können beide Telegramm-Typen verarbeiten.

Die folgende Tabelle 4 enthält eine Marktübersicht über zur Zeit verfügbare CAN-Protokollcontroller, Mikrocontroller mit CAN-Schnittstelle und CAN-Transceiver.

Tabelle 4: Marktübersicht CAN-Controller, Mikrocontroller mit CAN-Schnittstelle, CAN-Transceiver