Neben einigen FPGA-Implementierung von Bosch waren auf der Embedded World auch Mikrocontroller von Freescale und ST-Microelectronics im 70 m langen CAN-FD-Netzwerk verbaut.

Neben einigen FPGA-Implementierung von Bosch waren auf der Embedded World auch Mikrocontroller von Freescale und ST-Microelectronics im 70 m langen CAN-FD-Netzwerk verbaut. CiA

Da CANopen auf CAN basiert, ist die Performance begrenzt. Die maximale Geschwindigkeit beträgt 1 Mbit/s und die maximalen Nutzdaten pro Nachricht sind auf 8 Byte limitiert. Da das CAN-Protokoll auf einem zerstörungsfreien Buszuteilungsmechanismus basiert, bei der alle Teilnehmer das gleiche Bit abtasten müssen, gibt es eine Abhängigkeit von Netzwerklänge und Übertragungsgeschwindigkeit. Bei 1 Mbit/s liegen die Buslängen in der Praxis bei 25 m. Bei reduzierter Geschwindigkeit sind auch größere Distanzen möglich – zum Beispiel 500 m bei 125 kbit/s. Da bei CAN FD nach der Phase der Buszuteilung, nur noch ein Sender vorhanden ist, müssen die anderen Teilnehmer nicht zeitgleich das Bit abtasten. Das heißt, man kann die Bits schneller übertragen. Theoretisch setzen dem nur die Transceiver-Bausteine Grenzen. Im Labor erreicht man heute bis zu 15 Mbit/s – bei Verwendung von handelsüblichen Transceivern und CAN-Kabeln.

In der Praxis sind diese Werte aber nicht zu erreichen. Die Asymmetrie der am Markt erhältlichen Transceiver bezüglich der steigenden und fallenden Flanken bei niedrigen (-40 °C) und hohen (150 °C) Temperaturen erlauben derzeit eine maximale Geschwindigkeit von 2 Mbit/s. Transceiver, die über den gesamten Temperaturbereich höhere Datenraten ermöglichen, sind derzeit in Entwicklung. Denn die Automobilindustrie wünscht sich 5 Mbit/s. Es ist zu erwarten, dass solche Transceiver-Bausteine demnächst erhältlich sein werden. Eventuell werden sie auch für Datenraten bis 8 Mbit/s qualifiziert.

Da während der CAN-FD-Datenphase, in der nur ein Teilnehmer sendet, die Bits nicht innerhalb einer Bitzeit erneut gelesen werden können, muss der Sender diese Verzögerungen kompensieren. Er vergleicht das gesendete Bit also erst später mit dem zugehörigen Empfangenen. Dies kann bis zwei Bit-Zeiten später sein. Diese Transmitter-Delay-Kompensation erfolgt automatisch im CAN-Controller. Der Anwender muss sich darum nicht kümmern. Nach dem Acknowledge-Feld, in dem bereits wieder mit der langsamen Arbitrierungsgeschwindigkeit übertragen wird, sind die Teilnehmer wieder synchronisiert. Für typische Maschinensteuerungen bei den beispielsweise bisher mit 500 kbit/s übertragen wurde,  lässt sich nun ohne Probleme mit 2 Mbit/s in der Datenphase arbeiten. Sobald die Transceiver für höhere Geschwindigkeiten qualifiziert sind, sind auch 4 oder 8 Mbit/s möglich. Der Systementwickler muss das Netzwerk jedoch präziser auslegen. Lange Stichleitungen, langsame Transceiver, Kabel und Stecker mit niedrigen oder hohen Impedanzen (nominal 120 Ohm) können die Zuverlässigkeit der Übertragung beeinträchtigen.

Mehr Daten in eine Nachricht packen

Um die Übertragungseffizienz zu erhöhen, wurde für CAN FD das Datenfeld verlängert. Die Dateneffizienz berechnet sich aus dem Verhältnis der Nutzdaten zu den Protokolldaten. Beim klassischen CAN-Protokoll lag dies bei rund 50 % – je nach Länge des jeweiligen Datenfelds. Bei dem CAN-FD-Protokoll mit maximal 64 Byte ist dieses Verhältnis besser.

Die längeren Nutzdaten werden auch anders behandelt: Die Datenkonsistenz wird bereits beim Sender geprüft. Bisher konnte man zwar die Daten auf mehrere Nachrichten verteilen, aber die Zusammengehörigkeit musste bei jedem Empfänger in Software verifiziert werden. Die direkte Prüfung hat vor allem in der Antriebstechnik Vorteile. Denn dort muss der Anwender nur das PDO-Mapping für CiA 402 anpassen. Aber auch bei der Übertragung von digitalen und analogen Ein-/Ausgabedaten (CiA 401) können nun größere Datenmengen mit einem Schuss übertragen werden.

Von der Theorie zur Praxis

Noch ist CAN FD mehr oder weniger Theorie. Zwar gibt es erste FPGA-Implementierungen von Bosch, Kvaser, Peak und Vector sowie erste IP-Cores (Bosch, Cast und Inicore), aber die Anbieter von Mikrocontrollern haben noch keine Produkte mit CAN FD auf den Markt gebracht. Allerdings haben viele Hersteller bereits die Unterstützung von CAN FD angekündigt: Atmel, Freescale, Infineon, Microchip, Renesas, Spansion und ST-Microelectronics. Freescale und ST-Microelectronics zeigten auf der Embedded World im Februar erste Mikrocontroller mit CAN-FD-Modulen auf dem Chip. Sie waren in einen von Bosch gebauten CAN-FD-Demonstrator integriert. Das CAN-FD-Netz war rund 70 m lang und bestand aus einer Bus-Topologie mit angeschlossenem passiven Stern, der an den am weitesten auseinander liegenden Teilnehmern mit Widerständen terminiert war. Die Arbitrations-Bitrate betrug 500 kbit/s und die Daten-Bitrate war auf 4 Mbit/s eingestellt.

Link zu allen Infos und Trends rund um die Hannover Messe 2014

Link zu allen Infos und Trends rund um die Hannover Messe 2014Peak

Die von Freescale und STMicroelectronics erstmals vorgestellten Mikrocontroller mit vier und zwei CAN-FD-Schnittstellen sind für Motorsteuergeräte gedacht. Zusätzlich ist jeweils eine TTCAN-FD-Schnittstelle vorhanden, die für zeitgesteuerte Kommunikation genutzt werden kann. Die Mikrocontroller verfügen nicht nur über die erforderliche Rechenleistung, sondern implementieren auch ein dediziertes Zeitgebermodul. Beide Produkte basieren auf dem IP-Core M-CAN von Bosch. Renesas wird demnächst einen Mikrocontroller mit CAN FD ankündigen, der für Body-Steuergeräte entwickelt wurde. Die erste Version wird ebenfalls auf dem M-CAN basieren, doch schon zum Jahresende soll eine Eigenimplementierung von CAN FD zur Verfügung stehen. Freescale und NXP haben Transceiver im Portfolio, die für Datenraten bis 2 Mbit/s über den gesamten Temperaturbereich qualifiziert sind. Auch die Hersteller von Analysewerkzeugen und Interface-Boards haben bereits ihre Produkte CAN-FD-ertüchtigt. Intreprid, Ixxat, Peak und Vector stellten auf der Embedded World Prototypen vor. Wobei Peak ein selbstentwickeltes CAN-FD-FPGA nutzt. Weitere IP-Cores sind bereits in Entwicklung.

Bereits auf dem Weg zur Norm

Das CAN-FD-Protokoll wurde bereits bei der ISO zur internationalen Normung eingereicht. Es ist derzeit als Committee-Draft in der internationalen Abstimmung. Ein entsprechender Konformitätstestplan ist ebenfalls in der internationalen Normung. CAN in Automation (CiA) erweitert derzeit die CANopen-Spezifikation, um die Vorteile des CAN-FD-Protokolls nutzen zu können. Dazu muss vor allem das SDO-Protokoll (Servicedatenobjekt) erweitert werden, sodass sich die Daten auch in 64-Byte-Segmenten transferieren lassen. Diese würde vor allem die Konfiguration und das Herunterladen von Programmen beschleunigen.

Bezüglich der PDO-Kommunikation (Prozessdatenobjekte) ist weniger zu tun. Das PDO-Mapping erlaubt bereits das Zusammenstellen von bis zu 64 Prozessdaten. War bisher auch ein bitweises Mapping erlaubt, so wird bei CAN FD nur ein byteweises Mapping erlaubt sein, damit die Mapping-Tabelle nicht verändert werden muss. Die anderen CANopen-Dienste (zum Beispiel EMCY, Heartbeat, NMT und Sync) werden unverändert genutzt. Sie werden nur schneller übertragen.

Wenig Aufwand für höheren Datendurchsatz

Der Hauptvorteil für Automatisierer: Er kann ohne nennenswerten Aufwand den Datendurchsatz erhöhen. Er muss lediglich eine zweite Bit-Rate konfigurieren. Zwar muss er die Vorschriften und Empfehlungen bezüglich der Verkabelung und der anderen Element der physikalischen Übertragung genauer beachten, aber er muss sich nicht in eine neue Kommunikationstechnik einarbeiten. Er kann Bewährtes weiter nutzen. Dies trifft insbesondere auf die höheren Schichten zu, das CANopen-Protokoll sowie die zugehörigen Profile. Der Verein CiA geht davon aus, dass sich ein bis zu achtmal so hoher Datendurchsatz erreichen lässt. Und das bei gleicher Robustheit und Zuverlässigkeit der Datenübertragung, da das CAN-FD-Protokoll ebenfalls eine Hamming-Distanz von sechs aufweist. Das heißt, es werden bis zu fünf beliebig verteilte Bit-Fehler in einer Nachricht erkannt. Bei Fehlererkennung wird die Nachricht automatisch abgebrochen und wiederholt. Dies sorgt für eine netzwerkweite Datenkonsistenz, was bei vielen anderen Busprotokollen nicht möglich ist.