1. Geschichte
Der Varan-Bus wurde von der Salzburger Firma Sigmatek entwickelt. Ziel der Entwicklung war die Vereinigung der Vorteile verschiedener, bereits am Markt verfügbarer Systeme. Dabei wurde größter Wert auf hohe Performance, einfache Implementierung, niedrige Anschlusskosten und vor allem hohe Auswahlsicherheit gelegt. Der Varan-Bus wurde im Rahmen einer Veranstaltung der VDMA in Frankfurt im Januar 2006 erstmals der Öffentlichkeit präsentiert. Die äußerst positive Resonanz der Maschinenhersteller hat die Firma Sigmatek dazu bewogen, die Bustechnologie offen zu legen und damit der Allgemeinheit zugänglich zu machen. Zu diesem Zweck wurde im Juni 2006 die Varan-Bus-Nutzerorganisation, kurz VNO, ins Leben gerufen. Dieser Verein hält die Rechte am Varan-Bus und ist für die Betreuung und Weiterentwicklung des Standards zuständig. An einem Tisch finden sich hier Maschinen- und Anlagenbauer sowie Komponentenlieferanten, die gemeinsam Ihre Ideen und Konzepte in neue Produkte umsetzen.
2. Protokolle und Funktionsprinzip
Der Varan-Bus basiert auf dem Manager-Client-Prinzip. Das heißt, dass der Manager jede Kommunikation initiiert und der angesprochene Client sofort darauf antwortet. Somit können Kollisionen am Bus komplett vermieden werden. Weiters wurde das Protokoll zur Gänze in Hardware gelöst. Dies hat den großen Vorteil, dass sich die CPU oder SPS ausschließlich den Steuer- und Regelungsaufgaben widmen kann und sie nicht zusätzlich durch Kommunikations- und Management-Aufgaben für den Echtzeit-Ethernet-Bus belastet wird. Für Manager- und Client-Anschaltungen können preisgünstige FPGA\’s verwendet werden, die zahlreiche Hersteller anbieten. Varan-Bus-Anschaltungen lassen sich somit auf einem Preisniveau von Feldbusanschlüssen realisieren. Die Synchronisation der einzelnen Teilnehmer erfolgt mit einem Jitter von <100ns. Der Einsatz von verteilten Uhren nach IEEE 1588 ist dafür nicht notwendig. Die Entscheidung, wie das Varan-Bus-Protokoll auszusehen hat, war relativ einfach. Da als Übertragungsmedium die Ethernet-Physik verwendet wird, wurde im ersten Ansatz auch der Einsatz des Standard Ethernet-Protokolls in Erwägung gezogen. Es stellte sich jedoch sehr rasch heraus, dass der Overhead, den dieses Protokoll vorschreibt, für ein hart echtzeitfähiges Bussystem, das Zykluszeiten im Sub-Millisekunden Bereich bieten muss, nicht zielführend war. Das Protokoll musste verkürzt und der Overhead verringert werden, um einen höheren Nutzungsgrad der verfügbaren Bandbreite zu erreichen. Die Varan-Bus-Datenframes wurden so weit optimiert, dass sie nur einen Overhead von 6 bis maximal 15Byte benötigen – im Gegensatz zu Standard Ethernet-Frames, die einen Overhead von minimal 26Byte vorschreiben. Die Nutzdatenlänge im Varan-Frame wurde auf maximal 128Byte limitiert. Dies ist für alle I/O-, Regelungs- und Steuerdaten vollkommen ausreichend und ermöglicht außerdem, dass im Fehlerfall die Anfrage noch im gleichen Zyklus wiederholt werden kann. Das bedeutet, dass am Ende eines Bus-Zyklus alle Daten gültig sind. Eine Datensicherheit in dieser Form wäre mit den langen Standard Ethernet-Frames nicht zu erfüllen gewesen. Gleichzeitig ist es weiterhin möglich, Standard Ethernet-Frames im System zu übertragen, ohne die Echtzeit-Varan-Frames zu beeinflussen. Dies wird durch die Festlegung unterschiedlicher Task-Prioritäten ermöglicht. Im Task mit der höchsten Priorität, dem isochronen Task, werden die Echtzeit-Varan-Datenobjekte übertragen. Wenn alle Echtzeit-Datenobjekte verarbeitet wurden, startet der asynchrone Task, in welchem Varan-Datenobjekte mit geringerer Priorität übertragen werden. Den beiden untergeordnet ist der Administration Task, welcher für den Transfer der Standard Ethernet-Frames zuständig ist. Weiters wird in diesem Task zyklisch auf neue Teilnehmer im Varan-Bus-Netzwerk gescannt. Der Nutzer kann so während des Betriebs Teilnehmer ab-/anschließen und neue Teilnehmer hinzufügen. Zusätzlich ermöglicht der Varan-Bus jederzeit einen asynchronen Direktzugriff auf Busteilnehmer. Eine Herausforderung, die es zu meistern galt, war die Tatsache, dass bei niedrigsten Zykluszeiten oder einer großen Anzahl isochroner Daten für den Administration Task nicht mehr genügend Zeit zur Verfügung steht, um einen Standard Ethernet-Frame komplett zu übertragen. Dieser benötigt im maximalen Ausbau 122µs (1.550Byte).Gelöst wurde dies bei Varan-Bus, indem große Frames in kleine Pakete mit maximal 128Byte zerlegt und nur in Teilpaketen übertragen werden. Somit wird die Zeit, die für den Administration Task zur Verfügung steht, optimal genutzt und es sind mehr Teilnehmer bei niedrigeren Zykluszeiten möglich. Daneben ist es auch möglich, die Kommunikation zu den Varan-Teilnehmern mit Standard Ethernet-Frames anstelle von Varan-Frames zu realisieren. Für diesen Zweck ist für den Varan-Bus der Standard Ethertype #88fa eingetragen. Es steht somit ein optimales System für die Kommunikation mit niedrigsten Zykluszeiten zur Verfügung.
Wie funktioniert nun die Programmierung und der Zugriff auf die Clients?
Das komplette Varan-Bus-Netzwerk stellt für den Varan-Bus-Manager einen einzigen, großen Speicher dar. Der Varan-Manager verwaltet den gesamten Bus-Speicherbereich, der bis zu 65.536 Teilnehmer aufnehmen kann. Beim Start des Systems wird das Varan-Bus-Netzwerk auf Teilnehmer gescannt. Diese melden sich beim Manager an und bekommen dann einen eigenen, linearen Adressraum von 65.536Byte zugewiesen. Der Speicher befindet sich physikalisch immer auf Client-Seite. Der Manager weiß immer ab welchem Adress-Offset er welchen Client findet. Somit kann für die Programmierung auf einfache Schreib-/Lesebefehle zurückgegriffen werden. Nehmen wir beispielsweise einen Client, der Messwerte zur Verfügung stellt: Um die Messwerte in der Applikation verarbeiten zu können, muss nur ein einziger Befehl: \“Lese von Adresse X im Varan-Bus-Speicher ein Anzahl von n Byte\“ aufgerufen werden. Spätestens am Ende des Varan-Bus-Zyklus sind die Messwerte dann konsistent in der Applikation zur weiteren Verarbeitung vorhanden. Da der Varan-Bus-Manager im Fehlerfall das Kommando selbstständig wiederholt sind die Daten, auch wenn ein Paket zerstört wurde, in jedem Fall gültig und aktuell. Die Anzahl der Retries kann konfiguriert werden. Der Befehlssatz umfasst zusätzlich noch kombinierte Schreib-/Lesekommandos und Broadcast-Befehle. Auf höherer Protokollebene wurde in Zusammenarbeit mit CiA (CAN in Automation) eine komplette Abbildung des CANopen-Profils DS301/302 auf Varan-Bus realisiert. SDO\’s und PDO\’s werden dabei einfach im Speicherbereich der Client- und Manager-Baugruppen abgebildet. Dadurch kann bereits geleistete Entwicklungsarbeit größtenteils wiederverwendet werden und eine Portierung von Feldbus auf Echtzeit-Ethernet ist mit minimalem Aufwand in kürzester Zeit möglich. Ein Alleinstellungsmerkmal ist das zweifellos das elektronischeTypenschild, das in jedem Varan-Bus-Teilnehmer (Client) abgelegt ist. Dieses elektronische Typenschild beinhaltet unter anderem Daten wie Hersteller, Gerätekennung, Seriennummer, Versionsnummer und Lizenznummer, die jeden Varan-Bus-Teilnehmer eindeutig identifizierbar machen. Zusätzlich können im Typenschild kundenspezifische Dateien wie eine Produktdokumentation als PDF, Anschlusspläne usw. abgelegt werden. Die Vergabe der Gerätekennung erfolgt durch die VNO. Somit ist gewährleistet, dass Komponenten mit identischer Gerätekennung funktionskompatibel sind und beliebig ausgetauscht werden können.
