RoastedKit

Fraunhofer-Institut für Materialfluss und Logistik

Kurzbeschreibung

In der Projektgruppe wird ein Framework für eine auf Web Services basierenden Steuerung für Förderanlagen entwickelt. Dabei werden einzelne Komponenten (bspw. Förderer) des Systems zu Akteuren mit Regelungskompetenz, wodurch die klassische Steuerungshierachie stark abgeflacht wird. Dadurch wird eine bessere Adaptivität der Steuerungslogik an sich verändernde Randbedingungen, wie Änderung der Systemtopologie, erreicht.

Motivation und Hintergrund

Komplexe Materialflusssysteme werden trotz der Fortschritte in der Automatisierungs- und Steuerungstechnik derzeit hauptsächlich mit zentralen SPS2-Steuerungen bedient und bleiben nahezu unverändert über einen längeren Zeitraum in Betrieb. Dadurch sind die meisten klassischen Steuerungen starre Systeme mit einem begrenzten Maß an Flexibilität. Änderungen erfordern dabei primär die Überarbeitung und Neuinstallation des oft komplexen Steuerungsprogramms, verbunden mit dem vorübergehenden Stopp des Systems. Diese Problemstellung wird durch die folgenden Faktoren erschwert:

  • Keine Anlage gleicht der anderen
  • Großer Entwicklungsaufwand
  • Hohe Inbetriebnahmekosten
  • Kleine Änderungen haben große Auswirkungen auf das Gesamtsystem
  • Die Steuerungslogik bleibt unverändert über den ganzen Lebenszyklus (engl.: lifecycle) der Anlage.

Eine Notwendigkeit zur Anpassung kann gegeben sein durch variierende Systemanforderungen, wie z. B.

  • Schwankungen in der Auftragslage
  • Schwankungen in den Tagesspektren
  • Notwendigkeit von austauschbaren Materialflussstrategien

Schafft man es diesen Anforderungen gerecht zu werden, ergeben sich daraus zahlreiche vor allem wirtschaftliche Vorteile gegenüber den klassischen Lösungen, wie beispielsweise

  • Erhöhung der Verfügbarkeit des Systems
  • Erhöhung der Skalierbarkeit und Gesamtleistung des Systems
  • Erhöhung der Flexibilität des Systems
  • Senkung von Entwicklungs- und Wartungskosten
  • Geringerer Verkabelungsaufwand (als bei bisherigen Lösungen)
  • Konfigurationsanpassungen zur Laufzeit möglich

Die stetig zunehmende Rechenleistung auch im Bereich eingebetteter Systeme sowie die Entwicklung/Evaluierung der RFID-Technologie erleichtern die Aufteilung von Steuerungsaufgaben in einem dezentral organisierten System.

Zielsetzung

Darstellung der klassischen Steuerungspyramide 
Darstellung der klassischen Steuerungspyramide

Die Zielsetzung dieses Projekts kann man sich am besten an der klassischen Steuerungspyramide vergegenwärtigen (siehe Abb. 5.2.5). Wie dargestellt, werden auf den jeweiligen Steuerungsebenen verschiedenartige Kommunikationsverfahren verwendet, wobei die Regelungskompentenz von der Leitebene bis zur Feldebene stark abnimmt. So steckt in den einzelnen SPS-Steuerungen für die Sensoren und Aktoren der Feldebene nur recht wenig Logik, wohingegen die Leitebene über eine globale Sicht verfügt. Von diesem Standpunkt aus kann sie alle nötigen Steuerungsentscheidungen ohne Weiteres treffen - allerdings mit der Konsequenz, dass ein Ausfall oder Umbau in der Leitebene fatale Folgen für das gesamte System hat.

Es besteht bereits in der klassischen Steuerungspyramide und damit auch in klassischen Materialflusssystemen ein gewisses Maß an Verteilung, was man vor allem an der Ethernet-basierenden Kommunikation in Leit- und Zellebenen ablesen kann. Allerdings ist diese Verteilung noch nicht ausgeschöpft und hat besonders in die prozessnahen Bereichen noch keinen Einzug gehalten. Aus diesem Grund beschäftigt sich der Lehrstuhl für Förder- und Lagerwesen bereits seit längerem mit dieser Problemstellung und hat in der Vergangenheit einen ersten Prototyp einer prozessnahen dezentralen Steuerung für eine eigens dafür umgebaute Testanlage entwickelt. Ausgehend von dieser Arbeit wollte die Projektgruppe 475 ein Framework erstellen, dass die Entwicklung dezentraler Steuerungen erleichtern bzw. unterstützen soll. Besonderes Augenmerk wurde im Zuge dessen auf Komponenten gelegt, die häufig auftretende Verwaltungsprobleme (wie z.B. Topologie- und Routenerkundung) lösen. Außerdem wurde darauf geachtet, die Steuerungspyramide abzuflachen und die Leitebene nur noch für die Zustandsvisualisierung und Statuswechsel von Komponenten zu nutzen.

Ergebnisse I

Das Minimalziel der PG 475 war die Entwicklung einer prototypischen, dezentralen, auf Web Services basierenden Steuerung für Förderanlagen. Da mit der hier vorgestellten Förderanlagensteuerung Roasted Kit ein solches System geschaffen wurde, ist das Minimalziel erreicht worden. Das erweiterte Ziel: die Identifizierung von Problemfeldern und Überführung in ein Framework – konnte allerdings nicht vollständig erreicht werden.

Anforderungen an die Steuerung: Dezentralität

Aufgrund der flexiblen Architektur ist die Anforderung eines dezentralen Systems mehr als erfüllt. Das System kann sowohl serverorientiert als auch als komplett verteiltes System agieren. Desweiteren kommunizieren die einzelnen Subkomponenten per Web Service untereinander (auch lokal); dies bedeutet, dass über einen komplett verteilten Ansatz hinaus auch die Subkomponenten eines Steuerrechners rechnerunabhängig aktiv sind und theoretisch auf andere Rechner übertragen werden könnten. Der Grad der Dezentralisierung wird dadurch enorm gesteigert.

Modularität

Die hier vorgestellte Steuerung ist äußerst modular aufgebaut. Durch die Unterteilung in wichtige Systemkomponenten und Definition von Schnittstellen, sowie einheitlicher Inter-Komponenten-Kommunikation, basierend auf Web Services, konnte auch diese Anforderung erfolgreich erfüllt werden.

Autonomität

Die Anforderung der Autonomität wurde erfüllt, indem die Initialisierungsphase komplett automatisiert wurde. Dies geschah durch generische Systemkomponenten; ausschließlich CEModule (Java-Modul) sowie CEDescriptoren (XML-Datei) sind förderanlagenspezifisch und müssen generiert sowie an die einzelnen DeviceManagements bzw. SystemManagements verteilt werden. Mit Hilfe dieser zwei Dateien wandelt sich die vorher generische Steuerung in eine, die speziell für die entsprechende Anlage angepasst wurde. Dadurch werden alle Daten zur Verfügung gestellt, die eine automatische Systeminitialisierung ermöglichen.

Adaptivität

Die Anpassung an sich ändernde Topologie war von Anfang an einer der wichtigsten Punkte, auf die während der Entwicklung geachtet wurde. Bereits die Initialisierungsphase basiert auf dem sequentiellen Hinzufügen von DeviceManagements zu der Steuerung. Ein Abschluss dieser Phase wird gewissermaßen nie erreicht, da jederzeit Komponenten hinzugefügt oder entfernt werden dürfen. Die Technologie Universal Plug and Play (UPnP) macht der Steuerung dazu Änderungen bei Kommunikationsteilnehmern bekannt. Dadurch wurde also auch dieser Punkt vom System voll erfüllt.

Fehlertoleranz

Da jederzeit Komponenten (unabhängig ob Software- oder Hardwarekomponenten) ausfallen dürfen (siehe Adaptivität), ist die Anforderung der Fehlertoleranz implizit erfüllt. Der Ausfall von Komponenten wird per Eventsystem allen Teilnehmern mitgeteilt, so dass auf Fehlersituationen reagiert werden kann. Die Supervisor erstellen ausgefallene Komponenten bei Bedarf neu.

Proaktivität

Da viele Informationen, insbesondere zeitkritische Steuerungsinformationen wie z.B. die Wahl des vorhandenen Weges (durch Routing-Subkomponenten), vorab berechnet werden,ist ein proaktives System gegeben.

Weitere Erkenntnisse

Neben der oben genannten Erfüllung des Minimalziels sowie der Anforderungen wurden weitere technologische Erkenntnisse gewonnen.

UPnP

Die Technologie Universal Plug and Play (UPnP) wirkt anfangs überaus vielversprechend. Automatisches Auffinden von Netzwerkteilnehmern, und von evtl. angebotenen Diensten, die softwaretechnisch genutzt werden können soll somit möglich sein. Während der Arbeit der PG475 mit UPnP stellte sich heraus, dass derzeit keine stabil arbeitende UPnP-Bibliothek für Java vorhanden ist.

Ergebnisse II

Java

Die Entwicklung zeitkritischer Anwendungen mit Java ist möglich, jedoch benötigt der Faktor Performance besondere Aufmerksamkeit. Dies gilt nicht nur für die Architektur der entsprechenden Software, sondern auch für den Programmierstil und eingesetzte Technologien. Möglicherweise bietet die Echt-Zeit-Erweiterung von Java weitere Möglichkeiten, die der PG während der Arbeit noch nicht zur Verfügung standen.

Web Services

Ähnlich wie bei UPnP oder Java, sind auch für Web Services vorab Recherchen zu empfehlen, da sich die Implementierungen stark unterscheiden können. Insbesondere die Geschwindigkeit des Parsings der per HTTP versendeten XML-Nachrichten, kann sehr variieren. So ist zum Beispiel das Problem entstanden, dass Web Service Aufrufe extrem verlangsamt wurden (bis zu 5 Sekunden pro Aufruf), sobald sich ein Rechner mit dem Microsoft Windows Betriebssystem als Kommunikationsteilnehmer im Steuerungverbund befand. Nur wenn auschließlich Linux benutzt wurde, wurden Web Service Aufrufe effizient abgearbeitet (ca.8 Millisekunden, also ca. um den Faktor 625 schneller). Effizient arbeitende Web Service Bibliotheken sind zwar vorhanden, sowohl für Java als auch für C++, diese unterscheiden sich aber zum Teil stark in der Benutzbarkeit, Stabilität sowie dem Funktionsumfang.

Supervisor

Der Supervisor dient dazu, die für die Steuerung benötigten Komponenten zu erzeugen. Da mehrere Supervisor und somit mehrere Steuerrechner vorhanden sein können bzw. sollen, ist eine Absprache unter diesen notwendig, um Dateninkonsistenz zu vermeiden. In der vorhandenen Steuerung wird ein temporärer Server - der Primärsupervisor - gewählt, der als eine Art Server agiert. Entscheidungen werden nur vom Primärsupervisor durchgeführt bzw. bestätigt und danach jedem Supervisor bekannt gemacht. Während der Testphase hat sich jedoch herausgestellt, dass dieser Ansatz diverse Nachteile hat. So wird bei der Initialisierungsphase der erste Supervisor sich selbst als Primärsupervisor wählen, da er zu dem Zeitpunkt noch der einzige Supervisor ist. Kommen weitere Supervisoren hinzu, was normalerweise der Fall ist, stellt sich zum Beispiel die Frage, ob jemals ein neuer Primärsupervisor gewählt werden soll, sofern der Steuerrechner des Primärsupervisors nicht ausfällt. Eine andere Realisierungsmöglichkeit ist ein komplett verteilter Ansatz, bei dem es keinen (temporären) Server gibt. Für die Entscheidungsfindung fragt jeder Supervisor bei jedem anderen an und erbittet eine Bestätigung. Stimmen alle zu, so ist die Entscheidung bestätigt. Der Vorteil ist hier zwar die Flexibilität, der Nachteil jedoch die Anzahl der Web Service Aufrufe, die dann für n Supervisor bei n2 − n pro Entscheidung liegt.

Man hat weiterhin die Möglichkeit, die DSL-Ebene in die Hardware-Steuerungs-Ebene zu verschieben also die Supervisor und die entsprechenden Systemkomponenten auf den IndustriePCs (IPCs) starten. Dadurch würden viele Web Service Aufrufe lokal ablaufen, was schließlich die Performance erhöht. Ob die Steuerung überhaupt auf den IPCs lauffähig ist, müsste jedoch getestet werden.

Man sieht also, das hier vorgestellte Architekturkonzept bietet viel Flexibilität, jedoch auch viele Optimierungsmöglichkeiten. Hier ist also ein Trade-Off zwischen Flexibilität und Performance zu erkennen. Somit sind noch weitere Untersuchungen nötig, um das beste Flexibilität-Performance-Verhältnis herauszufinden.

Simulation

Die Simulation ermöglicht guten Einblick in die Systemstati und lässt sich gut zur Überprüfung von Konzepten einsetzen.

Durch eine Simulation hat man natürlich auch erst die Möglichkeit, nicht vorhandene, also virtuelle, Systeme zu testen. Hier müsste man lediglich passende XML-Dateien erstellen und die Steuerungsmodule hierfür schreiben. Erst dadurch werden umfangreiche System- und Ausführungstests möglich, da man beliebige Systeme mit nur sehr geringem Kosten-/Zeitaufwand testen kann. Leistungsgrenzen, Skalierbarkeit und Anpassungsfähigkeit lassen sich so problemlos für beliebige Systemtopologien empirisch verifizieren.