Eine Vielzahl unterschiedlicher Kommunikationsprotokolle hat sich bis heute in Automatisierungssystemen etabliert. Wurden in den vergangenen zwei Jahrzehnten die klassischen Feldbusse eingesetzt, sind es nun verstärkt diverse Ethernet-basierte Systeme. Diese Vielfalt führt dazu, dass bereits beim Beginn einer Neuentwicklung zu überlegen ist, welche Sprache das Gerät beziehungsweise System sprechen soll. Hierbei ist es zunächst wichtig, die Zielmärkte zu kennen – etwa die unterschiedlichen Länder, die Endanwendung aber auch den im Netz eingesetzten Steuerungshersteller.

In den USA etwa kommt man an Devicenet und Ethernet/IP kaum vorbei. Im asiatischen Raum sind es CC-Link und Powerlink und in Europa geben Profibus/Profinet, Ethercat, Sercos III und CANopen den Ton an. Dabei sind die Grenzen fließend. Liefert man beispielsweise in die Antriebstechnik mit hohen Realtime-Anforderungen, stehen Ethercat und Sercos III ganz oben auf der Liste. Oftmals ist es zudem wichtig, welcher Master das Gesamtsystem steuert, da die verschiedenen Hersteller von Steuerungen ihre eigenen Bussysteme präferieren. Kurzum: Sich auf ein Netzwerk-Protokoll zu begrenzen, ist in vielen Fällen schlicht nicht möglich. Das führt zur nächsten Frage, die sich ein Hersteller stellen muss: Habe ich das erforderliche Know-how, um ein multiprotokollfähiges System zu realisieren und zu pflegen? Die Antwort hierauf wird oft ‚nein‘ lauten, da dies  nicht die Kernkompetenz des Unternehmens ausmacht. In diesem Falle führt demnach kein Weg an einem Zukauf vorbei, wahlweise in Form einer

■ Chiplösung,
■ Softwarelösung (Zukauf eines Protokollstacks),
■ fertigen Optionsplatine oder
■ Auftragsentwicklung eines eigenen Protokollmoduls.

Bei kleinen und mittleren Stückzahlen – sprich zwischen 1 und etwa 5000 pro Jahr – spricht vieles für den Einsatz einer fertigen Optionsplatine. Die Vorteile einer solchen Lösung: Die Anbindung eines Produktes an eine fertige Optionsplatine ist technisch recht einfach. Meistens wird diese über leicht zu beherrschende Schnittstellen wie RS 232, RS 485, UART, SPI (Schieberegister) oder Dual Port RAM realisiert. Die Realisierung kann innerhalb weniger Wochen geschehen wohingegen die eigene Entwicklung beziehungsweise Implementierung eines Protokolls etliche Monate dauern kann – Stichwort ‚Time to market‘.

Da diese Optionsplatinen für viele Protokolle zur Verfügung stehen und PIN-kompatibel sind, hat man sofort nach der Integration ein breites Protokollspektrum zur Verfügung. Je nach Stückzahl und ­gewünschtem Protokoll bewegen sich die Preise zwischen 60 und 170 Euro. Im Vergleich dazu sind Software-Stacks oder Chiplösungen nochmals deutlich preiswerter; allerdings muss dann die Peripherie sowie die Ansteuerung selbst entwickelt werden, was nur bei größeren Stückzahlen (>5000/Jahr) wirtschaftlich Sinn macht. Hier kommt man auch nicht mehr ohne eigenes Know-how bei der Implementierung aus.

Protokoll-Integration – ein Praxisbeispiel

Wie eine solche Integration ablaufen kann, wird nachfolgend am Beispiel des Servolasers Xpert der Firma LAP gezeigt. LAP entwickelt und produziert seit 30 Jahren laserbasierte Systeme für die hochpräzise Projektion von Linien und Umrissen in Industrie und Medizin sowie zur berührungsfreien Messung geometrischer Größen wie Position, Breite, Dicke, Länge und Durchmesser von Produkten in der industriellen Produktion. Der Servolaser Xpert findet hauptsächlich bei der Fertigung von Automobil- und LKW-Reifen Verwendung.

Die Endkunden der Firma LAP benötigen unterschiedliche Protokolle mit einem Schwerpunkt auf Ethernet/IP. Da man sich aber keinem Markt verschließen wollte und der Aufwand für eine eigene Entwicklung dieser vielen Protokolle zu groß war, entschied LAP sich für den Einsatz der so genannten Kunbus-IC-Optionsplatinen im DIL32-Format. Die kleine Bauweise ermöglichte eine Unterbringung des Moduls samt Trägerplatine direkt am Laser. Dabei wird die Spannungsversorgung über die bereits vorhandenen 5 V realisiert wobei auch 3,3 V möglich sind.

Die Verbindung der Optionsplatine mit der Trägerplatine erfolgt über einen Standard-DIL32-Steckverbinder. Dabei sind die einzelnen PINs zur Applikation immer gleich, so dass durch den Austausch der Module auf andere Protokolle gewechselt werden kann. Die Trägerplatine beinhaltet die Steuerungslogik für den Laser, die Spannungsversorgung und den Steckverbinder zum Netzwerk, der die Schnittstelle nach außen bildet.

Zunächst stellte sich LAP allerdings die Frage, wie die Anbindung des Lasers an ein Netzwerk konkret realisiert werden sollte. Denn jede Applikationsschnittstelle hat ihre Vorteile:

Serielle Schnittstellen

Serielle Schnittstellen können mit unterschiedlichen Protokollen laufen. Das am weitesten verbreitete ist dabei sicherlich Modbus RTU. Allerdings können ebenfalls individuelle Protokolle mit so genannten Protokoll-Skriptern erstellt werden.

Das Modbus-Protokoll ist ein Kommunikationsprotokoll, das auf einer Master/Slave-Architektur basiert. Es wurde 1979 von Gould-Modicon für den Datenaustausch mit  speicherprogrammierbaren Steuerungen entwickelt. Mittlerweile hat sich Modbus RTU zu einem De-facto-Standard in der Industrie entwickelt, da es sich um ein offenes Protokoll handelt. Der RTU-Modbus – RTU steht für Remote Terminal Unit Modus – überträgt seine Daten über eine serielle Schnittstelle in binärer Form. Die Struktur dieser Sprache ist sehr einfach, was ebenfalls zu seiner großen Verbreitung  beigetragen hat.

Der RTU-Modus fängt mit einer mindestens 3,5 Zeichen langen Pause an, variiert jedoch mit der Übertragungsgeschwindigkeit. Danach folgen die Adresse des Empfängers, welche in 8 bit dargestellt wird, sowie der Funktionscode, welcher ebenfalls aus 8 bit besteht. Bei einer korrekten Übertragung werden die Felder vom Master an den Slave und dann unverändert wieder zurück gesendet. Bei Fehlern kommt es zu Code-Änderungen. Das darauf folgende Datenfeld dient zur Übertragung der gemessenen Daten an den Master. Überprüft wird die ganze Nachricht via CRC. Das Ende einer jeden RTU-Nachricht wird durch eine weitere Wartezeit von mindestens 3,5 Zeichen gekennzeichnet. Generell gilt, dass es zu keinen Unterbrechungen im Informationslauf kommen sollte, um die angeforderten Informationen vollständig zu erhalten. Kommt es zwischendurch trotzdem zu einer Unterbrechung des Datenstroms, wird meist dazu geraten, sich nicht auf die Nachricht zu verlassen, da sie unvollständig sein könnte.

SPI und SSR

Der offene SPI-Standard (Serial Peripheral Interface) arbeitet ebenfalls nach dem Prinzip des Master-Slave-Mechanismus. Neben der Vollduplex-Fähigkeit bietet eine SPI-Schnittstelle eine hohe Flexibilität hinsichtlich der Einstell- und Modifizierungsmöglichkeiten. Bei SPI handelt es sich um einen synchronen seriellen Bus. Für die Anschaltung von Applikationen werden häufig der SPI-Slavemode oder SSR (Serial Shift Register) verwendet.

Mit Abmessungen von lediglich 25 mm × 45 mm lässt sich das kompakte Embedded-Modul auch in Geräten mit begrenztem Platzangebot unterbringen.

© Kunbus

Beim SPI-Slavemode kann durch ein einfaches Protokoll ein SPI-Master Daten in Speicherregister schreiben oder Daten aus Speicherregistern lesen. Durch Setzen des Chip-Select-Signals teilt der Master dem Slave mit, dass er Daten übertragen möchte. Der Slave informiert den Master sodann durch Setzen des Ready-Signals, dass er zur Datenübertragung bereit ist. Der Master beginnt mit der Datenübertragung, sobald das Ready-Signal gesetzt ist, und setzt das Chip-Select-Signal zurück, wenn er die Datenübertragung beendet hat. Der Slave wiederum setzt das Ready-Signal zurück, sobald das Chip-Select-Signal zurückgesetzt ist.

Beim Schreiben von Daten durch den Master besteht die Datenübertragung aus einem Header und dem Datenanhang. Der Header enthält den Befehlscode und die Zieladresse. Der Datenanhang beinhaltet schließlich die Nutzdaten. Die Länge des Datenanhangs entspricht den Angaben im Header. Beim Senden des Headers einer Schreibanforderung sendet der Master einen weiteren Header mit Lese-, Schreib- oder NoOperation-Befehl an den Slave. Dieser Header wird vom Slave zurückgesandt und meldet dem Master den Status der vorangegangenen Schreibanforderung.

Die Statusangabe bestätigt, dass die übertragenen Daten geschrieben wurden oder gibt in einem Fehlercode den Grund für das fehlgeschlagene Schreiben an. Die Daten lassen sich dabei byte- und wortweise, blockweise und simultan blockweise übertragen. Ein NoOperation-Befehl ermöglicht dem Master die Statusabfrage der Schreibanforderung, ohne dass eine weitere Lese- oder Schreibanforderung durchgeführt werden muss. Ein Speicherregister kann entsprechend seiner Registerdefinition beschrieben werden.

Alternativ zum SPI-Modus lässt sich der SSR-Modus verwenden. Im Serial-Shift-Register-Modus wird eine Kette von bis zu 32 I/O-Bausteinen direkt an das Modul angeschlossen. Ohne einen zusätzlichen Prozessor ist es damit möglich, Signale auszugeben und einzulesen. Welche Daten ausgegeben werden und in welcher Reihenfolge, ist mit dem Data Broker im Modul frei konfigurierbar. Dieser verfügt über folgende Funktionen:

■ Erkennung der Schieberegisteranzahl,
■ Erkennung der Eingabe-/Ausgabe­register durch Einsatz eines Mittel­abgriffs
■ sowie Prüfung der aktuellen Geschwindigkeit auf Bitfehler.

Dual Port RAM

Das Basisboard für die Ansteuerung des Servolasers mit aufgestecktem Kommunikations-Modul ist im Seitenteil des Lasers eingebaut.

© Kunbus

Unter einem Dual Port RAM versteht man einen RAM-basierenden Speicher, bei dem von zwei Seiten (Ports) gleichzeitige Lese- und/oder Schreibzugriffe möglich sind. Dual-Port-RAM-Speicher (DPR oder auch DPRAM) besitzen getrennte Adress- und Daten-Bussysteme sowie eine Arbitrationslogik.

Durch den gleichzeitigen Zugriff können zwei ansonsten getrennte Systeme mit gemeinsamen Daten arbeiten, ohne sich gegenseitig in der Zugriffsgeschwindigkeit einzuschränken oder zu behindern. Bei herkömmlichen Speichern kann System B nur dann auf den Speicher zugreifen, wenn System A seinen Zugriff abgeschlossen hat. Beide Systeme können entsprechend lediglich mit eingeschränkter Geschwindigkeit arbeiten. Probleme können auftreten, wenn beide Ports gleichzeitig schreiben wollen, oder einer liest gerade dann aus, wenn der andere beschreibt. Durch ein spezielles Handshake lässt sich dies bei den Kunbus-Modulen vermeiden werden. Das DPR ist dabei platzsparend im CLPD beziehungsweise im FPGA integriert.

Umsetzung in wenigen ­Wochen

Ergo hat jedes der drei Systeme seine Vorteile. Eine Gemeinsamkeit ist, dass sie alle technisch gut beherrschbar sowie ausgereift sind und somit ohne großen Aufwand einsetzbar sind, um Systeme, Aktoren und Sensoren an ein Netzwerk anzubinden. Letztendlich entschied LAP sich für die Anbindung via SPI. Das SPI wurde nie mit störenden Patenten belegt. Diese Lizenzfreiheit hat dem Bussystem neben der einfachen Implementierung eine weite Verbreitung gesichert. SPI erreicht sehr hohe Datenübertragungsraten von 20 Mbit/s, da das Taktsignal bis in den 20-MHz-Bereich arbeiten kann – und das auch noch im Fullduplex-Betrieb. Darüber hinaus hält sich der Hardware-Aufwand in Grenzen, da nur drei Pins für den Slave-Select, Chip-Select, MISO (Master In Slave Out, Dateneingang Master) und MOSI (Master Out Slave In, Datenausgang Master) sowie für den vom Master gesteuerten Takt benötigt werden.
Synchron zum Taktsignal des Masters werden die Daten über die Datenleitungen – in diesem Falle die PINs des Kunbus-IC-Moduls – ausgegeben. Die Integration des Moduls beinhaltet:

■ Ersten Funktionstest mit einem Evaluation-Kit
■ Abstimmung der Software-Anpassungen
■ Anpassung des Mapping
■ Entwicklung der Trägerplatine
■ Test in der Entwicklungsumgebung
■ Test in einem vorhandenen Laser mit Masteranschaltung
■ Regressionstests
■ CE und Zertifizierung
■ Dokumentation

Alles in allem dauerte die Integration nur wenige Wochen.
Generell lässt sich festhalten: Die Integration von Systemen, Sensoren, Aktoren und HMIs in Netzwerken wird einen immer größeren Raum einnehmen. Gerade mit den Herausforderungen der Industrie 4.0 ist die industrielle Kommunikation das Rückgrat aller Anwendungen. Es wird dadurch sicherlich Veränderungen in diesem Markt geben, wie zum Beispiel neue beziehungsweise weiterentwickelte Kommunikationsprotokolle. Die Lösung mittels Einbauplatinen ermöglicht es aber, auf einfache Art und Weise mit den neuen Herausforderungen mitzuwachsen.

Autor: Andreas Müller ist Leiter Vertrieb und Marketing bei Kunbus.