Aufwand für das Einarbeiten ist nicht zu unterschätzen

Von unserem Redaktionsmitglied Dr. Birgit Oppermann

Bisher sind wir mit unserer Entscheidung für den Can-Bus gut gefahren“, lobt Johannes Tenfelde, verantwortlich für die Hardware-Entwicklung bei der Offenbacher MAN Roland Druckmaschinen AG, „aber etwas einfacher hatten wir uns die Einführung schon vorgestellt“.

Inwieweit die Erwartungen eines Maschinenbauers an ein Feldbus-System mit der Wirklichkeit übereinstimmen, haben die Offenbacher am Beispiel ihrer neuen Bogendruckmaschine erlebt, die sie heute in Serie bauen. Maschinenelemente wie Antriebe und Hilfsgeräte sollten via Bus sicher kommunizieren. Auf Grund verschiedener Kriterien fiel die Wahl schon früh auf das Can-System: Da es ursprünglich für die Automobilindustrie entwickelt wurde und auch heute in hohen Stückzahlen hergestellt wird, sind beispielsweise die Kosten pro Busknoten relativ niedrig.

An erster Stelle hat aber die Verfügbarkeit der Maschine jeden Schritt des Herstellers bestimmt: Eine Bogendruckmaschine bestehe durchschnittlich aus acht bis zehn Modulen, jedes mit bis zu 250 digitalen Ein- und Ausgängen. Diese müssten schnell und zuverlässig kommuniziert werden. „Dabei kann der Ausfall eines einzigen I/O zum Maschinenstillstand führen“, fasst Tenfelde zusammen. Für den Betreiber einer Druckmaschine sei das der Alptraum. Daher stand die störsichere Datenübertragung ganz oben auf der Checkliste der Maschinenbauer. Während Tenfelde darüber berichtet, breitet sich ein Lächeln auf seinem Gesicht aus. Die Forderung aufzustellen, war eine Sache, aber „erst heute, nachdem wir einiges Lehrgeld bezahlt haben, kann ich sagen, dass der Can-Bus sogar sehr störsicher ist, wenn man ihn richtig anwendet.“

Mit der Entscheidung für das System war erst der erste Schritt getan, denn für die Kommunikation auf dem Can-Bus stellen verschiedene Protokolle den Entwickler vor die Qual der Wahl. Sie unterscheiden sich in ihren Möglichkeiten, benötigen dafür unterschiedliche Rechenkapazitäten und sind unter Umständen eine Herausforderung für Anwender, die mit Bus-Systemen unerfahren sind.

Nach einigen Anläufen sind die Offenbacher inzwischen auf Can-Open eingeschwenkt. Dieses verbesserte Protokoll gab es zum Zeitpunkt des Steuerungsentwurfs 1996 noch gar nicht, weshalb sie ihre ersten Versuche mit einem selbst entwickelten Protokoll unternahmen. „Wir hatten uns vorgenommen, ein einfaches, leicht adaptierbares Protokoll zu erstellen, das sich auch nachträglich zum Beispiel in einen Antrieb integrieren lassen sollte“, berichtet Tenfelde. Er musste jedoch feststellen, dass der Aufwand für Spezifikation und Implementierung immens und die ersten Testläufe entmutigend waren – „es hat zunächst einmal nichts funktioniert“. Besonders schwierig war es, die Abläufe und das Zeitverhalten der Kommunikation eindeutig festzulegen. Obwohl die Offenbacher laut Tenfelde davon ausgingen, dass ihre Spezifikationen völlig klar seien, erwiesen sich diese im Detail als interpretierbar und verursachten einen zum Teil erheblichen Nachbesserungsaufwand. „Für eine kleine Aufgabe ist es durchaus akzeptabel, auf ein proprietäres Protokoll zurückzugreifen“, urteilt daher der Hardware-Entwickler. „Sobald der Kommunikationsaufwand steigt, machen die erforderlichen Tests aber so viel Arbeit, dass ein eigenes Protokoll nicht mehr sinnvoll ist.“

Als nächstes untersuchten die Offenbacher in einer Studie, ob sich das Can-Protokoll CAL (s. Kasten) besser für ihre Zwecke eignen würde. Aus heutiger Sicht war dieses Vorgehen für Tenfelde „nur ein akademischer Zwischenschritt“, an dem sich erläutern lässt, warum schließlich CanOpen der Favorit war.

Positiv sei, dass für CAL die Treiberbibliotheken für verschiedene Geräte zur Verfügung stehen. Es zeigte sich jedoch, dass die Fähigkeiten des CAL-Protokolls viel weiter reichten als erforderlich, die beteiligten Rechner aber sehr leistungsfähig sein mussten. Die Spezifikation für CAL nennt Tenfelde „sehr umfangreich“ und fährt fort: „Wer sie mal in der Hand gehabt und allein daraus versucht hat, die Zusammenhänge zu verstehen, weiß, was ich meine.“

Wesentlich besser kommt in seinen Augen die Beschreibung zu Can-Open weg, die er als „gelungen“ bezeichnet. Doch auch hier war der Weg zum Feldbuseinsatz kein Spaziergang. Obwohl das Protokoll mehr oder weniger standardisiert sei, bringe es großen Einarbeitungsaufwand mit sich. „Beim ersten Versuch mit unserem proprietären Protokoll hatten wir zwar noch mehr Schwierigkeiten. Aber selbst mit Can-Open sind wir in manchen Fällen an Informationen gescheitert, die interpretiert werden konnten.“ Die Offenbacher sind daher dazu übergangen, ihr Vorgehen zusätzlich „in Prosa“ zu erläutern. Diese Dokumente dienen den Entwicklern als Implementierungsgrundlage.

Für Can-Open haben sich neben MAN Roland auch die Heidelberger Druckmaschinen AG und die Koenig & Bauer AG Planeta-Bogenoffest, Radebeul, entschieden und einen Arbeitskreis gegründet. Sie wollen die Schnittstelle vereinheitlichen, mit der sich Trockner oder Pudergeräte an Druckmaschinen anbinden lassen. So sollen Hilfsgeräte eines Zulieferers zu Maschinen aller drei Anbieter passen.

Derart komplexe Schnittstellen konnten ohne Unterstützung von Software-Tools nicht ausreichend getestet werden. So gab der Arbeitskreis die Entwicklung einer unabhängigen Testplattform in Auftrag, die als Referenzmaster bezeichnet wird. Sie soll die ersten Schritte mit Can-Open erleichtern und beim Zertifizieren der Druckmaschinen und der Hilfsgeräte eingesetzt werden.

Diese Test-Software überprüft die Protokolle, simuliert dynamische Abläufe, fasst Testergebnisse in Dateien zusammen und dokumentiert die Objektverzeichnisse. Um das Tool erweitern zu können, wurde eine Programmierumgebung nach IEC 1131-3 integriert.

„Zur Zeit steht noch nicht fest, ob und wie wir den Referenzmaster weiterentwickeln“, berichtet Tenfelde. „Es ist uns bisher nicht gelungen, die Druckmaschinen-Branche damit vollständig zu erreichen.“ Eindeutiger fällt seine Auskunft zum Bus aus: „Insgesamt hat sich der Einsatz des Can-Bus als richtiger Schritt bestätigt, um heutigen und zukünftigen Anforderungen des Serienmaschinenbaus zu genügen.“

Herkunft:

CAN (Controller Area Network) wurde 1981 von Bosch und Intel für den Einsatz in Kraftfahrzeugen entwickelt, wegen der hohen Stückzahlen sollen die Anschaltkomponenten relativ preiswert sein

Datenübertragung:

– unempfindlich gegen Störeinflüsse, da der Bus für den Einsatz in Fahrzeugen entwickelt wurde

– schnell, Nachrichtenlänge ist jedoch begrenzt

– Multi-Master-System: Zugriff der Teilnehmer nicht von vornherein koordiniert, bei mehreren Teilnehmern wird die Priorität einer Nachricht codiert

– mögliches Problem: Teilnehmer mit niedriger Priorität könnten vom Bus-System ausgeschlossen werden

Verfügbare Protokolle:

Can Application Layer (CAL): wurde für die ersten industriellen Anwendungen entwickelt, enthält vielfältige Funktionen, benötigt aber große Rechnerkapazitäten

Device Net: offenes Protokoll für den Anlagenbau, Austausch der Komponenten während des Betriebs möglich

Can-Open: offenes Protokoll für den Maschinenbau, ermöglicht beispielsweise den direkten Kontakt der Busteilnehmer untereinander

Can Kingdom: CAN-Bus für Fortgeschrittene, erlaubt die Entwicklung eines Netzwerkes, das die Basis-Funktionen von Can in sehr freier Form kombiniert

Industrielle Anwendung:

Die ersten Anwender in der Industrie kamen laut Nutzerorganisation CiA e.V. (Can in Automation) aus der Textilbranche. Ähnliche Anforderungen und Einsatzbeispiele seien in der Verpackungs- und Papierindustrie zu finden. Weiterführende Informationen: www.can-cia.de

Im VDMA entstand im Jahr 2000 der neue Fachverband Industrial Communication, der Informationstage zu verschiedenen Bus-Systemen für Anwender anbietet: www.vdma.org

Die folgenden Eigenschaften des Can-Bus und des Protokolls CanOpen bewerten die Entwickler des Druckmaschinenherstellers MAN Roland als positiv:

– niedrige Herstellkosten

– niedrige Anschaltkosten pro Knoten

– hohe Verfügbarkeit

– Zahl verfügbarer Treiber

– störsichere Übertragung

– Multi-Master-System

– Kommunikationssystem flexibel einsetzbar

Bei der Auswahl des geeigneten Protokolls sollten nach Ansicht der Entwickler weitere Punkte berücksichtigt werden:

– Eine Beschreibungsvorschrift für die zu übertragenden Daten erleichtert die Spezifikation, ist aber allein nicht immer ausreichend.

– Komplexe Protokolle wie CAL stellen sehr hohe Anforderungen an die Anwender.