Herr Zeltwanger, was war der Auslöser für die Gründung der Vereinigung „CAN in Automation“ vor exakt zwei Jahrzehnten?

■ Damals war ich Fachredakteur und schrieb Artikel über CAN. Die Technik hat mich auf Anhieb begeistert – insbesondere die Zuverlässigkeit der Übertragung. Kein anderes se-rielles Bussystem konnte damals fünf beliebig eingestreute Bitfehler in einer einzelnen Nachricht erkennen, was einer Hamming-Distanz von 6 entspricht. Außerdem werden Burst-Fehler bis zu einer Länge von 15 Bit entdeckt. Allerdings gab es damals keine standardisierte Anwendungsschicht. Das war, als hätte man die lateinischen Buchstaben definiert, aber keine definierte Sprache würde sie nutzen beziehungsweise jeder Anwender müsste seine eigene Sprache erfinden. Folglich wurde im CiA zuerst der „CAN Application Layer“, kurz CAL, entwickelt, den wir noch im Gründungsjahr vorstellten. Da dieser CAL jedoch sehr akademisch war – so ähnlich wie Esperanto – definierten einige Firmen im Rahmen eines europäischen Forschungsprojektes ab 1993 ein auf CAL basierendes Kommunikationsprofil, welches später den Namen „CANopen“ erhielt.

CANopen wurde schließlich 1995 in den Markt eingeführt – in welchen Bereichen war das Profil zuerst erfolgreich?

■ Die erste CANopen-Anwendung, die mehrere Mitglieder auf dem HMI-Messestand demonstrierten, war eine generische Fertigungszelle. Ganz allgemein lässt sich sagen, dass einge-bettete Steuerungen für Textil-, Druck-, Verpackungs- und Kunststoffspritzguss-Maschinen als erste das ursprünglich für die Automobilindustrie entwickelte Bussystem nutzten. Es folgten die Medizintechnik und viele andere Industrien, bei denen eine robuste und zuverlässige Kommunikation gefordert ist. Dazu gehören unter anderem die Aufzugstechnik, die Schiffselektronik, die Labor-Automation und die Tür- sowie Torsteuerungen. Inte-ressanterweise setzte sich CAN in der Automobilindustrie langsamer durch, da aus Kostengründen anfänglich nur die Oberklasse mit CAN-Netzwerken ausgerüstet wurde. Die Industrie-Automation ist nicht so preissensitiv und konnte von daher CAN-Netzwerke früher einführen.

Die 90er waren auch die Zeit des so genannten „Feldbus-Krieges“, an dem sich CAN nicht beteiligt hat. Warum?

■ Ja, wir waren aus dem Fokus der in den Fachzeitschriften geführten Auseinandersetzungen, da wir uns damals nicht an der internationalen Normung beteiligten. Stattdessen haben wir ohne große Marketing-Aktivitäten CANopen weiterentwickelt, insbesondere die vielfältigen Geräte-, Anwendungs- und Schnittstellenprofile. Inzwischen sind die CANopen-Anwendungsschicht und das CANopen-Safety-Protokoll jedoch zumindest in Europa genormt. Einige Profile sind auch international genormt, beispielsweise das Antriebsprofil CiA 402 in der Normenreihe IEC 61800-7.

Stichwort Safety – von CANopen liest man diesbezüglich wenig. Spielt das Thema Funktionale Sicherheit für CAN-open keine Rolle?

■ Zumindest in der Fabrikautomation spielt CANopen-Safety bisher keine große Rolle. Die Sicherheitsfunktionen werden in CANopen-gesteuerten Maschinen und Anlagen überwiegend diskret – also festverdrahtet – gelöst. Anders sieht es bei Baumaschinen und anderen mobilen Arbeitsmaschinen aus, hier sollen zukünftig über das CANopen-Netzwerk auch sichere Daten übertragen werden. Und auch in der Eisenbahntechnik wird CANopen-Safety Einzug halten, nachdem CANopen im Rahmen der Eisenbahnnetzwerke*) international genormt wird.
Das CANopen-Safety-Protokoll ist in EN 50235-5 europaweit genormt. Es basiert auf der Idee, eine Nachricht noch einmal mit bitweise invertiertem Inhalt zu übertragen und durch Kreuzvergleich beim Empfänger jeden Einfachfehler zu erkennen. So erreicht man auch mit einem Buskabel einen Sicherheitslevel von 3 nach IEC 61508.

CAN ist hinsichtlich des Datendurchsatzes bei gegebener Netzwerk-Länge begrenzt – sind da Ethernet-basierende Lösungen nicht per se überlegen?

■ Mag sein – dafür sind Ethernet-basierende Netzwerke nicht so robust und zuverlässig. Außerdem erfordern nicht alle Anwendungen einen hohen Datendurchsatz. CAN-Anwender übertragen oft die Daten nicht periodisch, sondern nur wenn sie sich ändern. Dies reduziert den Datendurchsatz meist signifikant. Und wenn die angeschlossenen Teilnehmer sehr „autark“ arbeiten, müssen sie nur selten ein oder wenige Bit kommunizieren. In solchen Fällen sind CAN-Netzwerke manchmal sogar deutlich schneller als Ethernet-Lösungen, da der Protokoll-Overhead bei CANopen deutlich geringer ist.

Ungeachtet des Erfolges von CAN in industriellen Anwendungen, hat die Automobilindustrie mit ihren hohen Stückzahlen wesentlich zur Verbreitung dieser seriellen Kommunikationslösung beigetragen. Wird die Automobilindustrie auch in den nächsten Jahren CAN noch verwenden?

■ Never changing a winning team! Zudem sind die Fahrzeughersteller sehr konservativ. Sie ergänzen CAN nach unten – Stichwort LIN – und oben – Stichwort FlexRay. Die Hauptlast der Kommunikation wird aber meiner Überzeugung nach auch in Zukunft von mehreren CAN-Netzwerken getragen werden. Trotzdem denkt man in CAN-Netzwerken auch in Richtung mehr Datendurchsatz.

Hier spricht aber die Physik dagegen – bei CAN müssen alle Teilnehmer dasselbe Bit in einer Bitzeit abtasten.

■ Das stimmt für die Phase der Bus-Arbitrierung und die Acknowledge-Phase. Dazwischen – vom Datenlängen-Code bis zur Ende-Erkennung des CRC-Polynoms – kann man die Geschwindigkeit theoretisch beliebig erhöhen. Bei Verwendung der handelsüblichen und bewährten Transceiver ist man allerdings auf einige Mbit/s eingeschränkt. Bosch und die Industrie arbeiten derzeit an dem CAN-FD-Protokoll genannten Nachfolger. Dabei ist auch geplant, die andere Begrenzung, das 8-Byte-Datenfeld, auf 64 Byte auszudehnen. Letzteres ist vor allem für die Antriebstechnik und andere industrielle Geräte von großer Bedeutung. Bis dato muss man die Begrenzung auf 8 Byte noch mit Work-arounds in der Software umgehen.

Warum dann nicht gleich Ethernet?

■ Wegen der Robustheit und Zuverlässigkeit der CAN-Kommunikation.

„Vor allem in der elektrischen Antriebstechnik hat sich CAN einen großen Marktanteil erobert, speziell bei den kleinen und kleinsten Servomotoren. Ausschlaggebend dafür sind die Kompaktheit der Hardware und die geringen Kosten.“

© CAN in Automation

Trotzdem haben Sie einigen Ethernet-Technologien erlaubt, CANopen-Profile zu verwenden.

■ Wir haben allen Konsortien unsere Profile angeboten. Deren Nutzung erleichtert den Anwendern die Migration zu Ethernet-basierenden Lösungen, wenn die Busbandbreite von CAN nicht ausreicht und die Anforderungen an die Robustheit und Zuverlässigkeit nicht sehr hoch sind. Es gibt
aber auch gemeinsame Profil-Entwicklungen: Mit der PNO haben wir beispielsweise gemeinsam das Profil für Gateways zwischen ProfinetIO und CANopen festgelegt, welches Ende letzten Jahres von der PNO veröffentlicht wurde.

Selbstverständlich gibt es einige Regeln zur Nutzung der CANopen-Profile – insbesondere bezüglich des Objekt-Verzeichnisses. Die Parameter für Gerätetyp, Fehlerregister und die Geräte-Identifizierung – einschließlich der vom CiA zugeteilten Hersteller-Erkennung – sowie die Profil-Parameter werden exklusiv von CiA spezifiziert. Auch die Struktur des Objektverzeichnisses ist ausschließlich unsere Sache. Aber die anderen Organisationen können selbstverständlich Wünsche an die entsprechenden CiA-Gremien stellen.

Das Thema Energie-Effizienz ist in der Industrie in aller Munde. Wie trägt CAN in Automation dem Rechnung?

■ Die Arbeiten an einem Energie-Effizienz-Profil sind weitgehend abgeschlossen. Außerdem haben wir ein CANopen-Profil für die Messung des Energieverbrauchs entwickelt. Mit ihm kann man einen altersbedingten Mehrverbrauch entdecken, damit solche Ge-räte rechtzeitig ausgetauscht werden können. Auch auf der CAN-Transceiver-Ebene normen wir derzeit das so genannte „Partial Networking“. Dabei handelt es sich um einzeln aufweckbare CAN-Teilnehmer, die vorher „schlafen“ gelegt wurden. So lässt sich der Energieverbrauch im Auto erheblich reduzieren. Das gleiche gilt selbstverständlich für industrielle Anwendungen.

Es scheint, als gäbe es noch genug Entwicklungspotenzial für CAN auch in den nächsten Jahren?

■ Auf jeden Fall. Es erstaunt mich selbst, mit welcher Dynamik CAN noch weiter entwickelt wird. So arbeiten wir beispielsweise mit den Halbleiterherstellern aktuell an Treiberbausteinen mit integrierter galvanischer Trennung. Die ersten Produkte sind bereits am Markt. Weniger Bauteile sind nicht nur preisgünstiger, sondern reduzieren auch die Fehlermöglichkeiten, erhöhen demnach die Zuverlässigkeit und Verfügbarkeit.

*) TCN, train communication system