Alles, was Sie über VDA 5050 wissen müssen, gebündelt auf einer Seite
VDA 5050 in der Praxis
Der Fachverband Fördertechnik und Intralogistik (VDMA) hat gemeinsam mit dem Verband der Automobilindustrie (VDA) eine Schnittstelle definiert, welche die Kommunikation zwischen fahrerlosen Transportsystemen und einer Leitsteuerung beschreibt. Die aktuelle Version (1.1) kann hier kostenfrei herunterladen werden.
Das Ziel durch die vereinheitlichte Kommunikation ist die Interoperabilität zwischen verschiedenen fahrerlosen Transportsystemen sowie eine vereinfachte Integration in Leitsysteme. Damit werden nicht nur „Lock-In“ Effekte, sowohl gegenüber den Herstellern von FTSen als auch gegenüber den Entwicklern der Leitsysteme, vermieden, sondern auch Komplexität, spezielle Eigenentwicklungen und Integrationsaufwand auf ein Minimum reduziert.
Auch wenn die VDA 5050 sich speziell an den Anforderungen der Automobilindustrie orientiert, sind diese immer noch so divers, dass die definierte Schnittstelle Freiraum für viele verschiedene Szenarien und Sonderfälle lassen muss. Aus diesem Grund reicht es bei neuen Projekten auch leider nicht aus, davon auszugehen, dass ein FTS problemlos mit dem Leitstand kommunizieren kann, falls beide die VDA 5050 unterstützen. Der Standard bietet ein breites Spektrum an Möglichkeiten wo in der Praxis individuell überprüft werden muss welche Aspekte in der Kommunikation tatsächlich genutzt werden sollten.
Hinzu kommt in der Praxis noch die Komplexität verschiedener Systeme. Der Datenaustausch zwischen dem Leitsystem und einem ERP/Lagerverwaltungssystem ist natürlich selbstverständlich, jedoch bieten mittlerweile viele Hersteller von fahrerlosen Transportsystemen auch Flottenmanager an. Diese Flottenmanager haben unterschiedliche Funktionalitäten, angefangen vom Batteriemanagement bis hin zu einfachen Leitsystemen. Hier muss zuerst geklärt werden, ob und welche Flottenmanager eingesetzt werden und anschließend welche Aspekte der VDA 5050 bei der Kommunikation jeweils Anwendung finden. Ein Beispiel hierzu wäre das Batteriemanagement: Der Standard definiert die Möglichkeit den aktuellen Ladezustand an das Leitsystem mitzuteilen und auch die Anweisung zurück ans FTS an eine Ladestation zu fahren. In der Praxis wird dies bereits von allen Flottenmanagern unterstützt. Hier muss geklärt werden, ob die Verantwortlichkeit so bleibt oder nach oben in das Leitsystem wandern soll.
Im Folgenden werden die wichtigsten Aspekte der VDA 5050 beschrieben und direkt mit Erfahrungen aus der Praxis kommentiert, wie man diese einzelnen umsetzen kann. Der Fokus liegt darauf, wie ein schneller Proof-of-Concept erstellt werden kann, der zwar der definierten Schnittstelle entspricht aber noch nicht alle Features unterstützen muss.
Welche Akteure gibt es und wer kommuniziert mit wem?
Neben dem ERP oder Lagerverwaltungssystem ist eine sogenannte Leitsteuerung vorgesehen. Diese kennt die Topologie und mögliche Routen sowie die einzelnen Fahraufträge. In der folgenden Grafik wurden alle fahrerlosen Transportsysteme und Flottenmanager als ein Akteur gezeichnet. Die Realität sieht hier komplizierter aus. Mehrere FTSen hängen (meistens) an einem Flottenmanager, der wiederum in manchen Fällen optional ist.
Der Fokus liegt jedoch darauf zu zeigen, dass noch ein zusätzliches, neues System notwendig ist, der sogenannte Message-Broker (MQTT-Broker). Dies kann man sich als ein System mit mehreren Warteschlangen (diese werden „topics“ genannt) vorstellen.
Akteure können Nachrichten an ein topic schicken oder Nachrichten aus einem topic auslesen. Hierdurch wird das Leitsystem von den verschiedenen FTSen oder Flottenmanagern entkoppelt und es ist jederzeit möglich ein anderes Leitsystem oder zusätzliche Hardware anzubinden.
Herausforderungen in der Praxis
Eine Herausforderung, welche wir in der Praxis festgestellt haben, ist die Umstellung zB. vom Push zum Pull Prinzip. Manche Systeme „warten“ auf eine Aktion, die sie verarbeiten, ausführen oder weiterleiten sollen. Dies ändert sich bei der Umstellung auf ein VDA 5050 kompatibles System: Jeder Akteur muss selbst eine Verbindung zum Message-Broker aufbauen und dort, auf ein für ihn relevantes topic, auf neue Nachrichten warten.
Abgesehen von der Entkopplung zwischen FTS und Leitsystem ist der große Vorteil, dass jedes System selbst entscheiden kann welche Art von Nachrichten es empfangen will. Beispielsweise ist in der VDA 5050 das topic „visualization“ definiert. Hier können Ressourcen mit einer hohen Frequenz ihre aktuelle Position melden. Für das Leitsystem sind diese Updates irrelevant, es muss diese also nicht empfangen. Ein Dashboard oder eine 2D-Karte des Lagers wiederum interessiert sich ausschließlich für diese Informationen und empfängt dementsprechend auch nur diese.
Klärungsbedarf zu Projektbeginn
Zu Beginn eines Projektes ist es also wichtig zu klären welche Systeme im Einsatz sind, wer den zentralen Message-Broker stellt und ob alle Systeme mit diesem kommunizieren können. Anschließend muss erarbeitet werden welche Verantwortlichkeiten, Funktionen und Rollen die unterschiedlichen Systeme wahrnehmen. Darauf aufbauend können die topics definiert werden und die Akteure, welche in diese Nachrichten schicken beziehungsweise von dort empfangen.
Kommunikation des aktuellen Status eines FTS zum Leitstand
Eine der wichtigsten Nachrichten ist der aktuelle Status eines FTS, welcher zum Leitstand gelangen muss. Ohne diesen ist weder bekannt, welche Ressourcen verfügbar sind, noch können Fahraufträge vernünftig zugeteilt werden. In der VDA 5050 wurde hierfür das topic „state“ definiert. Nachrichten von diesem Typ sollten in regelmäßigen Abständen (es werden 30 Sekunden erwähnt) oder bei besonderen Vorkommnissen verschickt werden. Beispiele dafür sind Fehler, das Ankommen an einem Knoten oder auch das Bestätigen des Empfangs eines Auftrags. Der Leitstand wiederum kann diese auslesen und weiß jederzeit über die aktuelle Situation der fahrerlosen Transportsysteme Bescheid.
Daten im „state“
Für den Status wurde ein komplexes Datenobjekt mit vielen verpflichtenden, aber auch optionalen Elementen definiert. Aus diesem Grund werden im Folgenden nur die wichtigen Datentypen erläutert, welche man kennen sollte, um das Potential und die Möglichkeiten einschätzen zu können.
- orderId: ID des aktuellen oder vorherigen Auftrages
- lastNodeId: ID des aktuellen oder zuletzt überfahrenen Knotens
- safetyState: Sicherheitsrelevante Informationen, beispielsweiße ob der „E-Stop“ aktiviert ist
- informations: Beliebige Informationen, die vom FTS versendet werden können. Der Inhalt ist nicht definiert und sollte keine Logik im Leitsystem auslösen
- errors: Eine Liste von aktuellen Fehlermeldungen
- batteryState: Der aktuelle Ladezustand des FTS
- actionStates: Liste der Aktionen, welche das FTS in Zukunft abarbeiten wird
- edgeStates: Liste aller Wege, die das FTS noch bis zur Erledigung des aktuellen Auftrages befahren wird
- nodeStates: Liste aller Knoten, die das FTS noch bis zur Erledigung des aktuellen Auftrages befahren wird
Genauer werden wir in diesem Beitrag nicht auf die einzelnen Daten eingehen. Für mehr Informationen sollte direkt in der VDA 5050 nachgeschlagen werden.
Klärungsbedarf in der Praxis
Worauf man hier zu Beginn eines Projektes achten muss, ist, wie bereits erwähnt, welche Daten davon tatsächlich verschickt werden und welche Systeme wie darauf reagieren. Eingangs wurde das Beispiel mit dem Batteriemanagement erwähnt. Der Standard bietet die Möglichkeit den Ladezustand zu übertragen. Jetzt muss geprüft werden, ob jedes FTS oder jeder Flottenmanager tatsächlich diese Information versenden kann und ob das Leitsystem darauf reagieren kann/soll.
Ein weiteres Beispiel ist die Position des Fahrzeugs: Es gibt mehrere Möglichkeiten mitzuteilen, bzw. zu berechnen, wo sich das FTS aktuell aufhält. Über die lastNodeId, edgeStates und nodeStates kann innerhalb der Topologie (zumindest grob) erkannt werden wo das Fahrzeug aktuell unterwegs ist. Es gibt jedoch noch ein (optionales) Feld im state, die agvPosition. Hier können exakte X und Y Koordinaten übergeben werden. Gemeinsam muss direkt zu Beginn geklärt werden welche dieser Informationen vorhanden sind, welche das Leitsystem für die Zuweisung von Fahraufträgen nutzen soll und wie bei widersprüchlichen Daten vorgegangen werden soll.
Kommunikation von Fahraufträgen / Routen an ein FTS
Der Kern und Sinn des gesamten Systems ist die Zuweisung von Fahraufträgen an verschiedene Ressourcen. Hierfür definiert die VDA 5050 das topic „order“. Das Prinzip einer order ist schnell erklärt: Sie beinhaltet einen Weg von Knoten X zu Knoten Y und Aktionen, die ausgeführt werden sollen. Die Aktionen werden im darauffolgenden Kapitel genauer betrachtet, hier werden wir zuerst auf die Route eingehen, also von wo nach wo und auf welchem Weg ein FTS fahren soll.
Topologie im Leitstand
Der Ausgangspunkt ist eine vollständige Topologie des Lagers oder Produktion im Leitstand. Diese besteht aus Knoten und Kanten. Folgendes Beispiel ist sehr vereinfacht dargestellt. In der Realität gibt es noch Einbahnstraßen, Beschränkungen welcher Typ Fahrzeug auf welcher Kante fahren kann, Aufzüge, Tore und sonstige Hindernisse.
Übertragene Route an das FTS
Sobald das Leitsystem einen Fahrauftrag erhält oder erstellt, muss eine Route an das FTS übertragen werden. Im Idealfall gibt es keinerlei Einschränkungen und auch keinen anderen Fahrzeugen, in die Quere kommen können. In diesem Fall kann die komplette Route übertragen werden.
Das FTS, welches aktuell an Knoten 3 steht, weiß nun, dass es über Knoten 6 und 7 zu Knoten 8 fahren soll. Der Standard sieht jedoch vor, dass bei dieser übertragenen Route alle Knoten und Kanten für dieses Fahrzeug reserviert sind, es also ungestört die komplette Route abfahren kann.
Da es in der Praxis sehr ineffizient wäre direkt alle zu befahrenen Kanten für andere Fahrzeuge zu sperren sieht die VDA 5050 ein Konzept mit „base“ und „horizon“ vor.
Übertragene Route an das FTS mit „BASE“ und „HORIZON“
Die Idee dahinter ist, dass zu Beginn nicht die komplette Route gesperrt werden muss. Sie wird also in einen „base“ Abschnitt, der schon reserviert ist, und einem „horizon“ Abschnitt aufgeteilt
Das FTS kann nun also schon von Knoten 3 bis Knoten 6 losfahren, obwohl ein Teil der Route (von Knoten 7 bis 8) noch nicht freigegeben wurde. Bei Knoten 6 angelangt bleibt es stehen und wartet auf eine Freigabe des weiteren Streckenabschnittes. Im folgenden Beispiel kommt das Update, dass die Strecke zu Knoten 7 und der Knoten selbst nun für dieses Fahrzeug freigegeben und reserviert sind. Es kann also weiterfahren.
Vereinfachtes Konzept für ersten Proof-of-Concept
Wie oben gesehen bietet der Standard viele Möglichkeiten zu optimieren und detaillierte Informationen zum richtigen Zeitpunkt zu übertragen. Auch hier muss zu Beginn wieder die Frage gestellt werden, welche Informationen tatsächlich genutzt und übertragen werden müssen. Viele Flottenmanager unterstützen schon heute die Funktion von Punkt X zu Punkt Y auf der anderen Seite des Lagers zu fahren. Sie orientieren sich dabei an Magnetstreifen, RFID-Tags oder an visuellen Merkmalen. Falls ein Flottenmanager, der diese Funktionalität bereits unterstützt, per VDA 5050 Schnittstelle an ein Leitsystem angebunden werden soll, ist es eventuell nicht notwendig die exakte Route zu übertragen.
Das Positive und gleichzeitig Herausfordernde an dem Standard ist, dass viel möglich aber in der Praxis meistens nicht notwendig ist. Alle Seiten sollten die Möglichkeiten der VDA 5050 kennen und zu Projektbeginn gemeinsam entscheiden welche Aspekte notwendig sind. Nur auf einen Standard zu setzen heißt nicht, dass keine Kommunikation und Abstimmung mehr notwendig ist.
Kommunikation von Aktionen an ein FTS
Im vorherigen Abschnitt wurde erläutert, wie die Information übertragen wird, dass ein FTS von Knoten 3 zu Knoten 8 fahren soll. Der VDA 5050 Standard bietet jedoch noch zusätzlich die Möglichkeit konkrete Aktionen zu übermitteln, die vom Fahrzeug durchgeführt werden sollen.
Vordefinierte und eigene Aktionen
Da einige Aktionen universal gültig sind wurden diese in den Standard mit aufgenommen. Dazu zählen unter anderem folgende:
- startPause/stopPause: Aktiviert/Deaktiviert den Pausenmodus
- startCharging/stopCharging: Aktiviert/Deaktiviert den Ladevorgang
- pick/drop: Fordert das FTS auf etwas aufzunehmen/abzusetzen
- cancelOrder: Bricht den aktuellen Auftrag ab
Zusätzlich sind Felder vorgesehen, wo jeder FTS-Hersteller eigene Aktionen implementieren kann. Hier muss auch eine Unterstützung im Leitstand entwickelt werden. Wie bereits mehrfach erwähnt muss auch bei den Aktionen geprüft werden, welche relevant für das aktuelle Projekt sind und welche von welchem System getriggert und empfangen werden müssen.
Zeitpunkte der Aktionen
Es gibt zwei Möglichkeiten dem FTS Aktionen mitzuteilen:
Zum einen gibt es das topic „instantAction“. Hier können direkt und jederzeit Aktionen versendet werden. Dies kann notwendig sein um Kollisionen oder „dead-locks“ an Kreuzungen zu vermeiden, Aufträge spontan abzuändern oder auf Fehler anderer Fahrzeuge zu reagieren.
Zum anderen können bei einem Auftrag direkt Aktionen mitgesendet werden, die an bestimmten Kanten oder Knoten ausgeführt werden sollen.
Im folgenden Beispiel soll das FTS von Knoten 3 zu Knoten 8 fahren. Unterwegs soll es bei Knoten 6 das Warnsignal anschalten und auf dem Weg zwischen 7 und 8 sowohl das Warnsignal als auch die Signalleuchte aktivieren. Angekommen bei Knoten 8 soll die Aktion „pick“ ausgeführt werden.
Fragestellungen aus der Praxis
Beim Umstieg auf eine per VDA 5050 standardisierte Kommunikation oder eines neuen Projektes reicht es nicht aus den Herstellern des FTS und des Leitstandes zu sagen, dass dieser Standard unterstützt werden muss. Dafür gibt es zu viele Möglichkeiten den Standard auszulegen oder zu interpretieren. Folgende Fragestellungen bieten einen ersten Anhaltspunkt auf welche Punkte direkt zu Beginn eingegangen werden sollte.
- Technische Klärung: Wer stellt den Message-Broker?
- Welche topics sind für dieses Projekt relevant?
- Wird visualization benötigt?
- Wird connection benötigt?
- Werden zusätzliche, selbstdefinierte topics notwendig sein?
- Welche Informationen können vom FTS bzw. Flottenmanager versendet werden?
- Ist die aktuelle Position vorhanden?
- Kann der Batteriezustand versendet werden?
- Gibt es spezifische Informationen, die übertragen werden müssen? (Beispielsweiße das Ladungsgewicht, Position eines Greifarms oder Förderband)
- Können alle Fahrzeuge und Flottenmanager die gleichen Informationen verschicken?
- Welches System reagiert auf welche Informationen?
- Welche Information wird als tatsächliche aktuelle Position verwendet?
- Welche Fehlercodes sind für den Leitstand relevant? Wann muss umgeplant werden?
- Welches System ist für was verantwortlich?
- Kümmert sich das FTS/Flottenmanager selbstständig um die Routenfindung?
- Kümmert sich das FTS/Flottenmanager selbstständig um das Batteriemanagement? Fahren Fahrzeuge selbstständig zur Ladestation und melden sich beim Leitstand ab?
Fazit
Wir konnten Ihnen in diesem Beitrag hoffentlich aufzeigen, was die VDA 5050 eigentlich beinhaltet und was es bedeutet auf diesen Standard umzustellen. Er überzeugt zum einen dadurch, dass entscheidende Punkte der Kommunikation standardisiert sind, welche ansonsten zu viel Kommunikations- und Integrationsaufwand führen. Zum anderen bietet er den Vorteil „klein“ anfangen zu können. Wie am Beispiel der Route zu sehen war muss nicht vom ersten Tag an das gesamte Konzept mit „base“ und „horizon“ implementiert werden, es reicht auch erstmal aus einen Start- und Zielknoten zu versenden.
Diese Flexibilität ist der entscheidende Vorteil. Sobald die Infrastruktur, also der Message-Broker und die einzelnen topics, definiert sind, ist es sehr leicht zusätzliche Akteure anzubinden. Ein zusätzlicher FTS Hersteller kann problemlos integriert werden, ein neues Tool zur Visualisierung der Fahrzeuge in Echtzeit kann angebunden werden und selbst das Leitsystem kann mit deutlich geringerem Aufwand ersetzt werden.
Falls Sie also lediglich ein Leitsystem und einen Flottenmanager oder FTS-System einsetzen und nicht planen dies zu erweitern werden Sie keine Vorteile aus diesem Standard ziehen können (die den Implementierungsaufwand übersteigen). Bei einer komplexeren Systemlandschaft, einem neuen Projekt, was auf der grünen Wiese startet, oder falls diese Flexibilität notwendig ist da zukünftige Pläne noch nicht feststehen, können wir Ihnen nur empfehlen diesen Standard zumindest in Betracht zu ziehen.
Weitere Informationen
Sie haben Fragen bezüglich der neuen VDA 5050 Richtlinie. Gerne beantworten unsere Mitarbeiter Ihre Fragen und helfen Ihnen weiter. Füllen Sie dazu ganz einfach unser Kontaktformular aus. Informieren Sie sich in der Zwischenzeit zudem, wie das Flexus Leitsystem Fahrerlose Transportsysteme integriert.
