Entwicklung und Aufbau eines CAN-Feldbussystems für die Steuerungstechnik mit Schnittstelle zum Internet

Inhalt

Übersicht

Einleitung

1. Feldbusse in der Automatisierungstechnik
1.1. Einsatzgebiete, Merkmale
1.1.1 Profibus
1.1.2 InterBus-S
1.1.3 Controller Area Network
1.2. Internettechnologien in der Automatisierungstechnik

2. CAN – Controller Area Network
2.1. Protokoll
2.1.1 Busstruktur
2.1.2 Busarbitrierung, Identifier
2.1.3 Nachrichtentelegramm-Formate
2.1.4 Fehlermanagement
2.1.5 Überlast-Telegramme
2.1.6 Bittiming und Bitsynchronisation
2.1.7 Physikalische Ankopplung
2.2. Marktübersicht Protokollcontroller und Transceiver

3. Aufbau CAN-Feldbus-Knoten
3.1. Übersicht
3.2. Basisplatine
3.3. Masterplatine
3.4. SLIO-Platine
3.5. Schnittstellenadapter
3.6. Tischgehäuse
3.7. Netzteil

4. Programmierung
4.1. Übersicht
4.2. Eigene Typ-Deklarationen
4.3. Kommunikation SC12-SJA1000
4.4. Kommunikation SC12-I2C-Peripherie
4.4.1 Initialisierung
4.4.2 I/O-Baustein PCF8574A
4.4.3 D/A-Wandler AD5311
4.4.4 A/D-Wandler AD7417
4.4.5 EEPROM M24C16
4.5. Interruptverarbeitung
4.5.1 Übersicht
4.5.2 SJA1000-Interrupt
4.5.3 Timer-Interrupt
4.6. Timer, Ablaufsteuerung
4.7. CAN-Kommunikation
4.8. SLIO-Knoten
4.8.1 Identifier, Telegrammformate, I/O-Register
4.8.2 Digitale I/O-Verarbeitung
4.8.3 Analoge I/O-Verarbeitung
4.8.4 Synchronisierung
4.8.5 Softwareroutinen
4.9. Web-Interface

5. Elektromagnetische Verträglichkeit
5.1. Übersicht
5.2. Maßnahmen zur EMV
5.2.1 Schaltungstechnik
5.2.2 Überspannungsschutz
5.2.3 Leiterplattenlayout
5.3. Störfestigkeitsprüfung
5.4. Störemissionsmessungen
5.5. Zusammenfassung

6. Zusammenfassung und Ausblick

7. Literatur- und Quellenverzeichnis

Anhang
A1 Stromlaufpläne
A2 Platinendokumentation
A3 Stücklisten
A4 Jumper
A5 Register SJA1000
A6 Quelltexte (nicht enthalten)

Übersicht

In der vorliegenden Arbeit wird der Aufbau und die Programmierung eines Feldbussys­tems 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, Mikrocon­troller mit CAN-Schnittstellen und CAN-Transceiver. Es werden Maßnahmen zur Sicherstellung der elek­tromag­neti­schen 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.

Für die hervorragende Betreuung dieser Diplomarbeit durch die Herren Dipl.-Ing. Uwe Sondhof vom Lehrstuhl für Förder- und Lagerwesen und Dipl.-Ing. Tycho Weißgerber vom Lehrstuhl für Hochspannungstechnik und elektrische Anlagen möchte ich mich an dieser Stelle herzlich bedanken.

Ein besonderer Dank gilt auch meinen Eltern, die mir während meines Studiums immer zur Seite standen.

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-Kom­po­nen­ten 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 Parallel­verkabelung der Leistungsversorgung von Schaltgeräten und Pneumatik-Aktoren, die mittlerweile durch Energiebusse versorgt werden [Foe]. Große Teile zentraler Steuerungen werden zunehmend durch dezentrale Verarbeitungssysteme ersetzt, die mit seriellen Bus­systemen vernetzt werden. Die verbleibenden Teile der zentralen Steue­rungspro­gramme 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 kommunikations­technische 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 in dieser Leseprobe nicht enthalten

Abbildung 1: Automatisierungspyramide [Eil]

Prinzipielle Unterscheidungsmerkmale der verschiedenen Feldbussysteme sind die Art des Buszugriffs (stochastisch oder deterministisch per Master/Slave oder Token), die Netzausdehnung, die Teilnehmerzahl, die Bustopologie (Linie, Ring, Baum etc.) und die Datenraten. Diese Merkmale werden anhand der folgenden Betrachtung einiger Feldbus­systeme 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 Bus­topo­lo­gie 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 Master-Slave-Kommu­nikatio­nen möglich.

Abbildung in dieser Leseprobe nicht enthalten

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 in dieser Leseprobe nicht enthalten

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 Anwendungen.

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 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 Automatisierungsseite 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).

Abbildung in dieser Leseprobe nicht enthalten

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 Automatisie­rungs­tech­nik gefunden. Mit über 20 Millionen installierten Knoten ist CAN das führende Feldbussystem geworden [Reiss, S. 189]^[2].

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) unter­strichen 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] 11 bit lang. Es sind damit 2048 unterschiedliche Nachrichtenobjekte möglich^[3]. Dieses Standard-Frame-Format wurde 1991 in der CAN 2.0B-Spezifikation auf 29 bit-Identifier erweitert. Mit dem Extended-Frame-Format können 229 » 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^[4] 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Wired-AND-Schaltung

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Wired-AND-Logiktabelle

Da jeder Teilnehmer in der Arbitrierungsphase den Buszustand mitliest, kann er sofort anhand 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. 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.

Abbildung in dieser Leseprobe nicht enthalten

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 unterscheidet ein Standard- (IDE=0) und ein Extended Frame (IDE=1). Beim Extended Frame 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 versandt, 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 sogenanntes 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 Zustand 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.

Abbildung in dieser Leseprobe nicht enthalten

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 Synchronisation erfolgen. Das Signalausbreitungssegment berü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 in dieser Leseprobe nicht enthalten

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 Abbildung in dieser Leseprobe nicht enthalten, wobei tl der Länge eines Zeitquantums tq entspricht.

Abbildung in dieser Leseprobe nicht enthalten

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 Zwei­drahtleitungen durchgesetzt (Abbildung 8). Sie ermöglichen eine symmetrische Übertragung und sind dadurch unempfindlich gegen Gleichtaktstörungen.

Abbildung in dieser Leseprobe nicht enthalten

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

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.

Abbildung in dieser Leseprobe nicht enthalten

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 berücksichtigt werden müssen, sind einige Anschlußregeln zu beachten [Law, S. 117]. So sind Leitungsenden mit Terminierungswiderständen von ca. 120 W 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, Ter­mi­nierungswider­stände und Steckverbinder gegeben. Die Empfehlungen basieren auf der Norm ISO 11898 „Road vehicles – Interchange of digital information – Controller area network (CAN) for high-speed communication“^[5].

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.].

Abbildung in dieser Leseprobe nicht enthalten

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-Proto­kollcontroller, Mikrocontroller mit CAN-Schnittstelle und CAN-Transceiver.

Abbildung in dieser Leseprobe nicht enthalten

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

3. Aufbau CAN-Feldbus-Knoten

3.1. Übersicht

Die Feldbus-Knoten bestehen aus mehreren Komponenten. Eine universelle Basisplatine enthält Ein- und Ausgangsklemmen, Spannungsregler, einen CAN-Transceiver und eine 230 V-Ein- und Ausgangsbeschaltung mit Optokopplern und Relais. Auf die Basisplatine wird, je nach Verwendungszweck, eine Master- oder SLIO-Platine gesteckt (Abbildung 11). Dazu dienen zwei einreihige 18polige Pfostensteckverbinder X20 und X21.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Modularer Aufbau mit Master-, SLIO- und Basisplatine

Die Master- und SLIO-Module haben identische Ein- und Ausgabeports (Tabelle 5).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Ein- und Ausgabeports Master- und SLIO-Knoten

Die Basisplatine ist zusammen mit der aufgesteckten Knotenplatine in einem 110 × 110 × 65 mm3 großen Industrieklemmenkasten nach Schutzart IP66 (Feldgehäuse) montiert (Abbildung 12). Die Spannungsversorgung erfolgt aus einem Netzteil, das in einem eigenen gleichartigen Gehäuse untergebracht ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Seitenansicht Master- und Basisplatine

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: SLIO-Platine im Feldgehäuse

Ein 230 × 80 × 215 mm3 großes Tischgehäuse in Pultform dient zur Aufnahme einer Basis­platine incl. Masterplatine. Darüber hinaus beinhaltet es ein eigenes Netzteil und Schnitt­stellen für eine Zehner-Tastatur, ein LCD-Display, zwei RS232-Schnittstellen, eine Ether­net-Schnittstelle und zwei CAN-Bus-Steckverbinder (Abbildung 14).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Seitenansicht Masterplatine im Tischgehäuse

Um unabhängig von der Tischgehäuse-Elektronik die Anschaltung der Masterplatine an das Ethernet oder über RS232 an einen anderen Rechner zu ermöglichen, ist ein entsprechender Schnittstellenadapter entwickelt worden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Tischgehäuse mit installierter Masterplatine

Vorgabe für die Erstellung der Module ist eine möglichst kompakte Bauweise. Daher werden in großem Maße SMD-Bauteile verwandt.

In den folgenden Unterkapiteln wird der Aufbau und die Funktion der einzelnen Platinen detailliert beschrieben. Die Stromlaufpläne, Bestückungspläne, Layouts und Stücklisten befinden sich im Anhang A1, S. 71; A2, S. 78 und A3, S. 90.

3.2. Basisplatine

Die Basisplatine dient der Aufnahme der Master- bzw. Knotenplatine und hat 19 Printklemmen zur Anschaltung der Ein- und Ausgabeports, der Stromversorgung und des CAN-Busses (Abbildung 16, S. 25). Leuchtdioden zeigen den Zustand der Ver­sor­gungs­spannun­gen und I/O-Ports an.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Anschlußbelegung Printklemmen Basisplatine

Die vom Netzteil (Kapitel 3.7, S. 34) zugeführten Gleichspannungen U1P und U2P (ca. 11,5 V) werden zur Versorgung der Knoten- und CAN-Elektronik benötigt. In Kapitel 5.2.1, S. 58 wird näher auf die Notwendigkeit von zwei getrennten Stromversorgungen eingegangen. Die Spannungen VCC und VCCCAN (je +5 V) werden mit Standardreglern der Baureihe 78xx stabilisiert. VCCCAN versorgt die CAN-Elektronik und kommt mit einem SMD-100 mA-Regler TA78L05 aus. VCC versorgt die restliche Elektronik und wird mit einem 1 A-Typ 7805 geregelt. Es hat sich gezeigt, daß die Stromaufnahme des Masters mit ca. 550 mA so hoch ist, daß über dem Spannungsregler IC 1 eine Verlustleistung von Abbildung in dieser Leseprobe nicht enthaltenentsteht. Der Kühlkörper vom Typ SK13/35 ist dafür bei hohen Umgebungstemperaturen vermutlich zu klein, so daß die Montage des Spannungs­reg­lers auf einem Aluminiumblech unter der Basisplatine zu empfehlen ist^[6], was aus Zeit­gründen aber nicht erfolgt ist. Die Spannung U1P wird außerdem für die Versorgung der Analogelektronik auf der Master- bzw. SLIO-Platine und für die Ausgangsrelais benutzt.

Die Ausgangsrelais werden über Darlingtontreiber ULN2003 angesteuert. Ein High-Pegel des vom Master- bzw. SLIO-Knoten kommenden Signals (OUT1L...OUT3L) aktiviert den entsprechenden Treiber, der nach Masse schaltet. Die Relaisspulen sind fest über eine gemeinsame Leitung an VCCREL angeschlossen, die über einen Optokoppler IC4-1 freigegeschaltet wird. Diese Freigabeelektronik ist nachträglich eingebaut worden, da die Ansteuerungselektronik der Masterplatine (I2C-Chip IC14) die Treiber im nichtinitialisierten Zustand durchsteuert, so daß die Ausgangsrelais mit dem Einschalten der Versorgungsspannung anziehen. Dieses Verhalten kann bei einem Redesign durch das Einfügen von Invertern vor den Darlingtontreibern und entsprechenden Softwaremodifikationen vermieden werden.

Die Relais haben eine maximale Kontaktbelastung von 750 VA bei Netzspannung (230 V AC). Bei induktiven oder kapazitiven Lasten ist der Leistungsfaktor Abbildung in dieser Leseprobe nicht enthalten der Last entsprechend zu berücksichtigen: Abbildung in dieser Leseprobe nicht enthalten mit P als Wirkleistung der Last.

Die 230 V-Eingangsports sind über Optokoppler PC824 galvanisch von der restlichen Elektronik getrennt. Eine Eingangsschaltung mit ausreichend spannungsfesten Widerständen und einem 100 nF-Kondensator (230 V AC) begrenzt den Eingangsstrom betragsmäßig auf etwa 7 mA. Die Optokoppler sind durch antiparallele Schutzdioden für den Wechselspannungs­be­trieb ausgelegt. Die am Ausgang des Optokopplers anliegende pulsierende Gleichspannung wird durch ein RC-Netzwerk geglättet und der Master- bzw. Knoten-Platine zugeführt (IN1L...IN4L).

Die Anpassung der CAN-Bussignale erfolgt durch eine Standard-Applikation des Philips-CAN-Transceivers PCA82C250 [Phil1, S.12]. Die getrennten CAN-Sende- und Empfangs-Signale (CANT und CANR) werden über Optokoppler 6N137 auf den Transceiver geschaltet. Umfangreiche Schutzbeschaltungen sorgen für eine Erhöhung der Störfestigkeit (Kapitel 5.2.1, S. 58f.).

3.3. Masterplatine

Die Hauptkomponente des Masters ist ein 16 bit-Singlechip-PC (IPC@CHIP SC12). Der von der Fa. Beck IPC GmbH [Beck1] erstellte Controller ist in einem 32poligen DIL-Gehäuse untergebracht. Der Chip hat ein echtzeitfähiges DOS-kompatibles Betriebssystem und ist kompatibel zu 80C186- und 80C188-Mikrocontrollern. Dadurch ist es möglich, Programme mit Standard-PC-Compilern wie Borland C/C++ 5.0, Microsoft C 6.0, Borland Turbo Pascal 7.0 etc. zu erstellen. Die Compiler müssen lediglich in der Lage sein, 16 bit-DOS-Code zu erzeugen. Die Hardware des mit 20 MHz getakteten SC12 umfaßt einen AMD186-Mikroprozes­sor, 512 kB RAM, 256 kB Flash-ROM, 256 kB Firmware-ROM, eine Ethernet-Schnittstelle, zwei serielle Schnittstellen RS232, eine I2C-Schnittstelle und einen gemultiplexten Adreß-/Datenbus (Abbildung 17, S. 27).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: SC12-Blockdiagramm [Beck2, S. 4]

[...]

---

^[1] CSMA/CA-Verfahren: Carrier Sense Multiple Access/Collision Avoidance

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

^[3] Zugelassen sind nur die Identifier 0...2031, der Rest ist reserviert.

^[4] Arbitrium (lat.): Schiedsspruch.

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

^[6] Ein größerer Kühlkörper ist aufgrund des begrenzten Platzes nicht montierbar.