Startseite > Automation > Industrie 4.0 & IoT > IoT-System aus Standardkomponenten selbst bauen

Arduino, Raspberry Pi und Node-RED

IoT-System aus Standardkomponenten selbst bauen

30. Juli 2018, 12:00 Uhr | Klaus Dembowski

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Wer kann, der CAN

Die Entwicklung des CAN-Busses (Controller Area Network) wurde in den achtziger Jahren von der Firma Bosch als Bussystem für die Verkabelung von Sensoren und Aktoren in Kraftfahrzeugen initiiert, um die immer größer werdenden Kabelstränge einer herkömmlichen Verkabelung durch »intelligente« Knoten reduzieren zu können. Die CAN-Bus-Spezifikationen sind durch ISO 11898 festgelegt. Im ISO/OSI-Referenzmodell sind die Ebene 1 als Physical-Layer und die Ebene 2 als Data-Link-Layer definiert, auf der das CAN-Bus-Protokoll absolviert wird. Mittlerweile ist der CAN-Bus in verschiedenen Ausprägungen anzutreffen und als Feldbus etabliert, wofür auf der Schicht 7 verschiedene Kommunikationsprotokolle (CANopen, DeviceNet) existieren.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Jeder CAN-Bus-Teilnehmer ist gleichberechtigt und wird mithilfe von zwei differentiellen Leitungen (CAN High, CAN Low), die meist als verdrilltes TP-Kabel ausgeführt sind, an den Bus angeschlossen (Bild 3). Dieser ist an den beiden Enden typischerweise mit jeweils 120 O zu terminieren, d. h. das jeweils letzte Gerät am Bus muss diese Terminierung sicherstellen.

Auf dem CAN-Bus werden verschiedene Datenrahmen übertragen, die stets mit einem SOF-Bit (Start Of Frame) beginnen. Befindet sich das CAN-Bussystem im Ruhemodus (Idle), kann prinzipiell jeder Knoten eine Nachricht aussenden. Aufgrund der gleichberechtigten Teilnehmer gibt es keine Master-Slave-Struktur, sodass ein Zugriffsverfahren (Arbitrierung) regeln muss, welcher Teilnehmer gerade auf den CAN-Bus zugreifen darf. Hierfür ist das Arbitration-Field zuständig, das sich im Standard-Datenrahmen (Bild 4) aus elf Identifier-Bits und einem RTR-Bit (Remote Transmission Request) zusammensetzt.

Setzen mehrere Knoten Bits im Arbitration-Field, werden die einzelnen Identifier-Bits an der jeweils gleichen Stelle miteinander verglichen. Der dominante Zustand überschreibt den rezessiven Zustand. Sobald ein Knoten einen dominanten Zustand registriert, obwohl er selbst einen rezessiven Zustand erzeugt hat, wird der Sendeversuch abgebrochen und der Knoten wartet (Listen only, Bild 5), bis die Übertragung abgeschlossen und der Bus wieder im Idle-Modus ist. Danach kann ein erneuter Zugriffsversuch initiiert werden. Dabei sind nicht die einzelnen Knoten mit einer ihr eigenen ID versehen, sondern jeweils die gesendeten Nachrichten. Über dieses Zugriffsverfahren lassen sich die Nachrichten anhand der Werte in den Identifier-Bits außerdem priorisieren.

Im folgenden Control-Field wird das IDE-Bit (IDentifier Extension) transportiert, das kennzeichnet, ob es sich um einen Standard-Datenrahmen oder um einen erweiterten Rahmen handelt. Ein Standardrahmen erlaubt bis zu acht Datenbytes im Data-Field und elf Identifier-Bits, womit sich bis zu 2048 einzelnen CAN-Busknoten selektieren lassen. Es folgt das reservierte Bit RB0, das rezessiv ist. Die nächsten vier Bits beinhalten den Data-Length-Code (DLC3 bis DLC0), der spezifiziert, wie viele Datenbytes sich im folgenden Data-Field befinden.

Den Daten folgt die Datensicherung (CRC Field), bestehend aus einer 15-Bit-Prüfsequenz und einem rezessiven Begrenzungsbit. Diese zyklische Blockprüfung ist ein allgemein verwendetes Verfahren zur Erkennung von Bitfehlern. Das anschließende Acknowledge-Field setzt sich aus dem ACK-Slot-Bit und dem Begrenzungsbit ACK Del zusammen. Sendet ein Knoten eine Nachricht, ist der Pegel des ACK-Bit rezessiv. Hat eine Station die Nachricht empfangen und sie durch den CRC-Check als gültig anerkannt, sendet ein Empfängerknoten an dieser Stelle einen dominanten Pegel auf den Bus, um zu kennzeichnen, dass die Nachricht fehlerfrei übermittelt wurde. Das Begrenzungsbit sorgt dafür, dass das ACK-Bit von zwei rezessiven Pegeln umgeben ist, um somit die Zuverlässigkeit einer dominanten Bestätigung zu gewährleisten.

Neben dem Standard-Datenrahmen ist der Error-Frame, der für die Fehlererkennung zuständig ist, essenziell. Prinzipiell gibt es zwei Arten von Fehlersignalen, die über den CAN-Bus gesendet werden können: Aktiv und Passiv. Ein CAN-Busknoten sendet ein Aktiv-Fehlersignal aus, sobald er einen Fehler erkennt. Der Error-Frame besteht aus sechs dominanten, aufeinander folgenden Bits. Registriert ein Knoten mehr als fünf aufeinander folgende Bits gleichen Wertes, so ist die Bit-Stuffing-Regel (nach fünf gleichen Bits wird für die Synchronisation ein invertiertes Bit eingefügt) verletzt und der Knoten sendet seine Nachricht erneut.

Es besteht jedoch ebenfalls die Möglichkeit, dass ein defekter Netzknoten fälschlicherweise Fehlersignale sendet und somit den Bus blockiert. Um dies zu verhindern, werden die Knoten in die Zustände Error-Active und Error-Passive unterteilt. Jeder CAN-Controller führt hierfür zwei interne Zähler, den Sendefehlerzähler TEC und den Empfangsfehlerzähler REC. Befinden sich die Werte der Zähler unter einem festgelegten Grenzwert, ist der Knoten im Zustand Error-Active und darf dominante Error-Flags senden.

Übersteigen die Zähler diesen Grenzwert, ist davon auszugehen, dass der Knoten fehlerhafte Error-Frames sendet und so den Datenverkehr behindert. Er wechselt eigenständig in den Zustand Error-Passive und signalisiert einen Fehler dann durch sechs aufeinander folgende rezessive Bits, wodurch ein Abbruch der Übertragung mitgeteilt wird. Andere Nachrichten können jedoch nicht überschrieben werden, sodass der weitere Datenverkehr nicht beeinträchtigt wird.