CAN in Automation 30 Jahre im Dienste der CAN-Gemeinschaft

Von Holger Zeltwanger*

Am 5. März 1992 wurde CAN in Automation CiA gegründet. Kürzlich übergab die internationale Anwender- und Herstellervereinigung die Spezifikation der dritten CAN-Protokoll-Generation CAN XL an die ISO zur Normung.

Anbieter zum Thema

Industrielle Vernetzung: Wenige Jahre nach der Vorstellung des Controller Area Network durch Bosch im Jahr 1986 startete der CAN-Bus seine Industriekarriere.
Industrielle Vernetzung: Wenige Jahre nach der Vorstellung des Controller Area Network durch Bosch im Jahr 1986 startete der CAN-Bus seine Industriekarriere.
(Bild: gemeinfrei / Pixabay )

Sechs Firmen und zwei natürliche Personen gründeten vor 30 Jahren den in Nürnberg beim Amtsgericht eingetragenen Verein CAN in Automation (CiA). Das Ziel war und ist, Anwendern und Herstellern des 1986 von Bosch vorgestellten Controller Area Network (CAN) eine neutrale Plattform zur Verfügung zu stellen. Einerseits sollten zusätzliche Spezifikationen erarbeitet werden, damit eine Interoperabilität von CAN-Produkten erreicht werden kann. Anderseits sollte der Verein technische Hilfestellung für Anwender in Form von Seminaren und Publikationen bieten.

Schon im ersten Jahr gab der Verein eine Empfehlung für die physikalische CAN-Schnittstelle heraus. In ihr wurden Bitraten und Abtastzeitpunkte sowie eine Steckerbelegung festgelegt. Eine erste praktische Prüfung fand auf dem ersten CiA-Gemeinschaftsstand statt, auf dem 15 Mitglieder ihre CAN-Produkte an ein CAN-Netzwerk anschlossen. Das war sozusagen das erste Plugfest – aber dieser Begriff war damals noch nicht erfunden.

CiA und höhere Protokolle und Geräteprofile

Schon im ersten Jahr entwickelten CiA-Mitglieder eine generische Anwendungsschicht, CAN Application Layer (CAL) genannt. Maßgeblich war daran Philips Medizintechnik beteiligt. Der kommerzielle Erfolg blieb allerdings aus, weil den meisten industriellen Anwendern, die der CiA anfänglich hauptsächlich unterstützte, CAL-Implementierungen zu viel Rechenleistung und Speicher benötigen.

Deshalb entwickelte ein europäisches Forschungsprojekt unter Leitung von Bosch ein CAL-basierendes Profile, das unter dem Namen CANopen von CiA vermarktet wurde. Ende 1994 erschien die erste CANopen-Spezifikation. Parallel unterstützte der Verein auch andere höhere CAN-Protokolle (z. B. DeviceNet). Aber die Spezifikationsarbeit konzentrierte sich ausschließlich auf CANopen.

Im Laufe der Zeit entwickelten CiA-Mitglieder für viele Gerätetypen sogenannte CANopen-Profile. Insgesamt wurden mehr als 20 000 Seiten verfasst, in denen die zu übertragenen Prozessdaten sowie entsprechende Konfigurationsparameter spezifiziert wurden. Eine der am weitesten verbreiteten Profil-Spezifikationen ist CiA 402. Sie spezifiziert das Kommunikationsverhalten von elektrischen Antriebssteuerungen (Frequenzumrichter, Servoregler und Schrittmotoren). Das Profil ist inzwischen international genormt (IEC 61800-7-201/301) und wurde auch von anderen Kommunikationstechnologien adaptiert.

Mitglieder entwickelten im Laufe des 30-jährigen Bestehens des CiA für verschiedene Branchen CANopen-Profile. Dazu gehört beispielsweise das Anwendungsprofil für Aufzugssteuerungen (CiA 417), welches unter dem Namen CANopen-Lift seit fast 20 Jahren im Einsatz ist. Manche Profile sind sehr anwendungsspezifisch, zum Beispiel das Profil für Kontrastmittelinjektoren (CiA 425), das Profil für Container-Spreader und Straddle-Carrier (CiA 444), das Profil für Abfallsammelfahrzeuge (CiA 422) und das Profil für sogenannte Subsea-Trees (CiA 443). Subsea-Trees sind komplexe Messsysteme für Bohrinseln. Sie liegen auf dem Meeresgrund.

Aber es gibt auch generische Geräteprofile beispielsweise für Ein-/Ausgabe-Module (CiA 401) sowie Drehgeber (CiA 406) und Neigungssensoren (CiA 410), die in unterschiedlichen Branchen eingesetzt werden. CANopen-Drehgeber sind in Baumaschinen, in Windkraftanlagen, in nachführbaren Solarpanelen, im Aufzug, in automatischen Türen, in Computertomographen sowie im klassischen Maschinenbau im Einsatz. Diese Aufzählung erhebt keinen Anspruch auf Vollständigkeit.

Die am meisten genannten Gründe für den Einsatz von CAN sind seine Robustheit gegen elektromagnetische Störungen, die Zuverlässigkeit der Übertragung (geringe Restfehlerwahrscheinlichkeit) sowie die Verfügbarkeit von preisgünstigen Protokoll-Controller und Transceivern – nicht zu vergessen die einfache Anwendbarkeit von CAN.

Die Überwindung der Grenzen

Die drei CAN-Generationen spezifizieren fünf Datenframe-Formate: CBFF/CEFF gehören zur 1. Generation (klassisches CAN), FBFF/FEFF repräsentieren die 2. Generation (CAN FD) und XLFF ist das Protokoll der 3. Generation (CAN XL).
Die drei CAN-Generationen spezifizieren fünf Datenframe-Formate: CBFF/CEFF gehören zur 1. Generation (klassisches CAN), FBFF/FEFF repräsentieren die 2. Generation (CAN FD) und XLFF ist das Protokoll der 3. Generation (CAN XL).
(Bild: CAN in Automation)

Es gibt selbstverständlich auch Grenzen: Das klassische CAN-Protokoll der 1. Generation kann pro Datenframe nur 8 Byte übertragen und die Datenrate ist maximal 1 MBit/s. Selbstverständlich kann man auch längere Nachrichten übertragen, aber dann muss man sie auf der Senderseite stückeln und auf der Empfängerseite wieder zusammenfügen. Dazu gibt es mehrere sogenannte Transport-Protokolle (Schicht 4 im siebenschichtigen OSI-Referenzmodell).

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Die höheren Protokolle CANopen, J1939 und DeviceNet unterstützen ebenfalls eine Segmentierung von Nachrichten. In der Automobilindustrie wird oft das in ISO 15765-2 standardisierte Transport-Protokoll (ISO-TP) verwendet, zum Beispiel für Diagnosezwecke.

Mit einem Transport-Protokoll kann man sogar Software-Downloads bewerkstelligen. Allerdings ist der Protokoll-Overhead erheblich und führt am Ende des Bandes in den Fabriken der Fahrzeughersteller zu langen Wartezeiten, wenn in die elektronischen Steuergeräte die Software heruntergeladen wird. Der Wunsch diese Zeit zu verkürzen, führte dazu, dass das CAN-FD-Protokoll entwickelt wurde.

Der CiA begleitete die von Bosch betriebene Entwicklung von CAN FD (2. Generation) und veröffentlichte mehrere Design-Empfehlungen bezüglich des Einstellens der beiden Bitraten. CAN FD unterliegt in der Arbitrierungsphase der gleichen Bitraten-Begrenzung wie klassisch CAN. In der Datenphase, wenn nur ein Teilnehmer senden darf, kann man je nach verwendetem Transceiver, der Netzwerk-Topologie und dem gewünschten Temperaturbereich die Bitrate auf 2 MBit/s und mehr erhöhen.

In Norm ISO 11898-2:2016 sind zwar Transceiver-Parameter für Bitraten bis 5 MBit/s standardisiert, die aber nur bei optimaler Auslegung der elektromechanischen Komponenten (Kabel und Steckverbinder) oder einer Begrenzung der Teilnehmer erreichbar sind. Die längeren Datenfelder (bis zu 64 Byte) im CAN-FD-Datenframe gestatten eine effizientere Segmentierung, da der Protokoll-Overhead niedriger ist als bei Frames mit nur acht Datenbytes.

Im CiA wurden sogenannte SIC-Transceiver (Signal Improvement Capability) spezifiziert (CiA 601-4), die das Klingeln auf den CAN-Leitungen unterdrücken können. So können die oben erwähnten Begrenzungen bezüglich der Topologie und der Anzahl der Teilnehmer überwunden werden. In der Automobilindustrie hat der Migrationsprozess zu CAN FD mit SIC-Transceivern bereits begonnen. Diesmal hat ein chinesischer Fahrzeughersteller die Nase vorn: Changan wird in seiner nächsten Plattform SIC-Transceiver verwenden. Deutsche Marken werden ebenfalls SIC-Transceiver einsetzen.

Kaum war die 2. CAN-Generation entwickelt, da initiierte Volkswagen den nächsten Schritt. Unter dem Schirm des CiA entwickelten Fahrzeughersteller, Zulieferer und Halbleiterfirmen die 3. CAN-Generation unter dem Namen CAN XL mit einer Datenfeldlänge von bis zu 2048 Byte (CiA 610-1). Mit diesem Protokoll kann man auch Ethernet-Frames tunneln. In CAN-XL-Netzwerken kann man auch CAN-FD-Frames übertragen und hat so einen einfachen Migrationspfad.

CAN XL stellt auch einige Features zur Verfügung, die in den beiden ersten CAN-Generationen nicht vorhanden sind. In einem 8-Bit-Feld (Service Data Unit Type) kann die übergeordnete Schicht dem Empfänger mitteilen, welches höhere Protokoll verwendet wurde. Da auch die Doppelfunktion des CAN-Identifiers (Priorität beim Netzwerkzugriff und Adress- oder Inhaltsinformation) aufgeteilt wurde in einen 11-Bit-Prioritätsfeld und ein 32-Bit-Akzeptanzfeld, kann man nun mehrere höhere Protokolle simultan auf dem CAN-XL-Netzwerk betreiben. Mit der 8-bit-CAN-Netzwerk-ID sind sogar bis 256 Instanzen eines höheren Protokolltyps unterscheidbar.

CAN-XL-Protokoll bietet Hamming-Distanz 6

Um die Zuverlässigkeit der Übertragung von Datenframes in CAN-XL-Netzwerken gegenüber den beiden ersten CAN-Generationen trotz längerer Datenframes noch zu verbessern, wurden zwei CRC-Sequenzen in das CAN-XL-Datenframe eingebettet. Die Universitäten von Kassel und Stuttgart haben unabhängig voneinander die Performance der Datensicherung untersucht. Danach bietet das CAN-XL-Protokoll eine Hamming-Distanz von 6, das heißt, fünf beliebig verteilte Bitfehler werden erkannt und mit einem Fehler-Frame dem Anwender signalisiert. Eine Besonderheit von CAN XL ist die Abschaltbarkeit der Fehlersignalisierung, um die Fehlerbehandlung in den höheren Protokollschichten (z. B. in der Transportschicht) in Software zu realisieren.

Holger Zeltwanger: Der CiA-Gründer derzeit auch als Obmann des ISO-Arbeitskreises für In-Vehicle-Netzwerke tätig.
Holger Zeltwanger: Der CiA-Gründer derzeit auch als Obmann des ISO-Arbeitskreises für In-Vehicle-Netzwerke tätig.
(Bild: CAN in Automation)

CAN XL nutzt ähnlich wie CAN FD zwei Bitraten: Die Arbitrierungs-Bitrate ist auf 1 MBit/s limitiert und wird nur in der Phase, bis die Sendeerlaubnis erteilt ist, verwendet. Danach wird je nach Konfiguration weiterhin mit NRZ-Kodierung (non-return-to-zero) oder einer PWM-Kodierung (pulse-width modulation), aber mit einer höheren Bitrate gesendet. Mit der PWM-Kodierung sind Geschwindigkeiten von über 10 MBit/s erreichbar. Am Ende des CAN-XL-Datenframes wird wieder auf die Arbitrierungs-Bitrate zurückgeschaltet, damit alle Teilnehmer gleichzeitig den korrekten Empfang (ACK-Slot-Bit) bestätigen können.

Erste CAN-XL-Implementierungen wurden im Rahmen eines CiA-Plugfests auf Interoperabilität erfolgreich getestet. Dies betraf CAN-XL-FPGA-Implementierungen sowie Prototypen von CAN-SIC-XL-Transceivern (CiA 610-3). Ein zweites CAN-XL-Plugfest, bei dem das korrekte Verhalten bei Fehlern getestet werden soll, ist wegen der Covid-19-Pandemie für das späte Frühjahr geplant.

Die CiA-Spezifikationen für SIC-Transceiver (CiA 601-4 und CiA 610-3) wurden bereits zur internationalen Standardisierung bei ISO eingereicht und sollen in die nächste Edition von ISO 11898-2 eingefügt werden. Das CAN-XL-Protokoll (CiA 610-1) soll in die nächste Ausgabe der Norm ISO 11898-1 integriert werden. Im Anhang soll auch die CAN-FD-Light-Spezifikation (CiA 604-1) beigefügt werden. CAN-FD-Light spezifiziert einen Responder-Knoten, der von einem CAN-FD-Commander gesteuert wird. Die Kommunikationsinitiative geht dabei immer vom Commander aus und der angesprochene Responder antwortet dann.

Der Vorteil gegenüber anderen Commander/Responder-Netzwerken ist das 64-Byte-Datenfeld sowie die mit herkömmlichen CAN-Transceivern erreichbare Bitrate von 1 MBit/s. Typische Anwendungen sind Fahrzeuglampen mit sehr vielen LEDs und Batterien mit einer hohen Anzahl von Zellen. Der Vorteil: Da keine Busarbitrierung stattfindet, braucht man in den Respondern keine CAN-Oszillatoren. Auch die in CAN FD übliche Fehlersignalisierung gibt es nicht, so dass eine Implementierung von CAN-FD-Light deutlich preisgünstiger ist als dies eines normalen CAN-FD-Controllers.

Von Industrieautomatisierung zum globalen CAN-Verein

Der CiA war anfänglich auf die Unterstützung von CAN-Anwender in der Industrieautomation fokussiert. Sehr schnell kam schon die Medizintechnik hinzu. Gefolgt von Baumaschinen, Aufzugsteuerungen, Eisenbahntechnik und Schifffahrt ist der eingetragene Verein mit seinen über 700 Mitgliedern heutzutage an alle CAN-Entwicklungen beteiligt. Das schließt gerade auch die Automobilindustrie ein. Es gibt auch exotische Anwendungen: CANopen fliegt beispielsweise in Satelliten mit. Es wurde sogar eine entsprechende strahlungsgehärtete Hardware-Implementierung realisiert, die unter anderem in der ESA-Mars-Mission genutzt wird.

CiA-Mitarbeiter vertreten die Interessen der Mitglieder in der Normung. Deshalb beteiligen sie sich in den Normungsgremien von DIN, IEC, ISO, SAE usw. bei der Erstellung von Dokumenten. Im Prinzip stellt der Verein auf Wunsch seine Spezifikationen den Normungsgremien zur Verfügung. Der CiA ist eine Plattform zur Vorentwicklung von Normen. Die Publikationen und Trainingsdienstleistungen bieten den CAN-Anwendern herstellerunabhängige Informationsmöglichkeit.

* Holger Zeltwanger ist der Initiator der CiA-Gründung und seit dem Bestehen im Vorstand des eingetragenen Vereins. Er ist derzeit auch Obmann des ISO-Arbeitskreises für In-Vehicle-Netzwerke. Außerdem ist er in mehreren DIN-, ISO- und SAE-Arbeitskreisen tätig. Er ist auch der Editor von DIN 4630, DIN 14700, DIN 14704 sowie von ISO 11898-2.

Artikelfiles und Artikellinks

(ID:48097445)