Die Arbeit im Logistikzentrum kann eintönig sein. Eine Order nach der anderen muss abgearbeitet und dafür schnell und fehlerfrei kommissioniert werden. Für die Mitarbeiter*innen bedeutet das: Hin zur ersten Lagerposition, Ware aus dem Regal nehmen und auf den Sammelwagen stellen, weiter zur nächsten Lagerposition und zur einer weiteren und schließlich mit den gesammelten Kartons zur Packstation und mit dem Folgeauftrag wieder zurück zu den Regalreihen. Doch so abwechslungslos die Aufgabe ist, sie ist trotzdem körperlich anstrengend. Und sie erfordert eine hohe Konzentration. 

Vielleicht sind auch das gewichtige Gründe, warum immer mehr Logistikzentren autonomen, mobilen Robotern, kurz AMRs den stupiden Teil der Verrichtung überlassen: Autonomous Mobile Robots arbeiten selbstständig. Sie kennen keine Langeweile. Und sie bleiben konzentriert – zumindest solange der Akku hält. Längst sind sie in der Lage, Hindernisse zu erkennen, ihnen auszuweichen oder gar andere AMRs und auch die Menschen vorzuwarnen. Kurz: In »ihrer« Halle arbeiten die AMR-Systeme zuverlässig und schnell. Aber eben nur hier und unter der Voraussetzung, dass sich in ihrer Umgebung und an ihren Aufgaben nichts so gravierend ändert, dass sie es mit dem Mindset ihres Steuerungssystems nicht mehr bewältigen können. 

Das allerdings beschränkt aktuell arbeitende AMRs deutlich. Wie flexibel sie eigentlich auf Änderungen reagieren müssten, verdeutlicht Andreas Kreutz vom Fraunhofer-Institut für Kognitive Systeme IKS an Beispielen aus der Praxis: Die Übergabe von Kartons für darauffolgende Prozessschritte erfolgt bisher über Sammelwägen. Nach einer Umgestaltung des Lagers geschieht dies teilweise aber auch über Förderbänder. Oder an der Hallenausstattung selbst ändert sich zwar nichts, aber ein Teil der Waren erhält eine neue Verpackung: Zum Beispiel Kartons mit spiegelnder Oberfläche und abgerundeten Ecken. Im ersteren Fall werden die Roboter die Übergabeplätze nur dann sicher anfahren und bedienen können, wenn ihre Navigationsalgorithmen entsprechende Freiheitsgrade bei der Positionierung berechnen und auch die Greifalgorithmen mit den veränderten Bedingungen zurechtkommen können. Und im zweiten Beispiel muss der Roboter auch die neue Form der Behältnisse zuverlässig erkennen können, um sie sicher aufzunehmen. »Um die Robotersysteme auch für diese neuen Aufgabenstellungen befähigen zu können, benötigen sie eine Weiterbildung – sprich ein Software-Update«, sagt Kreutz. Das aber ist einfacher gefordert als tatsächlich umgesetzt. 

Software-Updates bei Robotersystemen

Andererseits: Eine neue Softwareversion oder zusätzliche Programmkomponenten in die Systeme einzuspielen, sollte doch kein Problem sein, oder? IT-Nutzer*innen erleben das Prozedere schließlich an PCs und Smartphones nahezu täglich – wenn auch meist nur als Vollzugsmeldung eines Updates. Solch ein eher lautloses Updaten oder Upgraden wäre natürlich auch bei Robotersystemen möglich und sinnvoll, sagt Kreutz. Allerdings sei in diesen Fällen eine Menge spezifischer Vorarbeit zu leisten. Erst dann könne ein Software-Update in das laufende System so eingespielt werden, dass der Übergang reibungslos verläuft. Denn im Unterschied etwa zu einem Online-Marktplatz unterscheiden sich die Anforderungen und Möglichkeiten zur Sicherung der Softwarequalität beträchtlich: Bei einem Roboter wirkt sich ein neues Programm nicht nur innerhalb der Sphäre des Informatiksystems aus, sondern auch auf das Agieren seiner mechanischen Komponenten – vom Fahrwerk bis zu den Greifern. Jede Nachrüstung, ob »nur« eine Codekorrektur oder sogar ein neues Hardware-Software-Feature muss deshalb aufwendige Testzyklen durchlaufen. Das kostet vor allem drei Dinge: Zeit, Zeit und nochmals Zeit. 

Doch dank des vom Bayerischen Staatsministerium für Wirtschaft, Landesentwicklung und Energie geförderten Projekts »RoboDevOps« könnte sich das ändern. Hier entwickeln und testen Forscher*innen des Fraunhofer IKS gemeinsam mit den Spezialist*innen des Roboter-Unternehmens Magazino GmbH neuartige Methoden und Tools. Das Ziel: Selbst bereits laufende AMR-Flotten sollen erheblich schneller auf den neuesten Stand gebracht oder in ihrem Funktionsumfang weiterentwickelt werden können, als das bislang möglich war. 

Erfolgsmethoden der IT-Welt übertragen

Die Forscher*innen arbeiten dafür mit bei IT-Unternehmen inzwischen überaus erfolgreich eingesetzten DevOps-Methoden. Sie verzahnen die Zusammenarbeit zwischen Development und Operations so geschickt, dass eine automatisierte Weiterentwicklung beispielsweise von Softwareplattformen und deren Betriebs- und Supportabteilungen möglich wird. So kann für jede geplante Programmänderung die Softwarequalität und Funktionsfähigkeit bereits in frühen Stadien Schritt für Schritt abgesichert werden. Unverzichtbar dafür ist allerdings ein Klon des Gesamtsystems. Denn über ihn können die Verantwortlichen Testläufe durchführen ohne das Original zu beinträchtigen. 

Eine Adaption dieser Vorgehensweise zum Einsatz bei Robotersystemen ist nicht einfach. Denn im Gegensatz zu einem Internetmarktplatz lässt sich das Logistikzentrum als Arbeitsumgebung der Roboter nicht klonen. »Die Entwicklungsteams der AMR-Systeme haben sich bislang damit beholfen, dass sie eine Testhalle entsprechend ausstatten und ihr geplantes Software-Update anhand von Probeszenarien testen«, erklärt Kreutz. Dieses Prozedere lasse sich zwar auch künftig wohl nicht umgehen, aber den Aufwand dafür können die Forscher*innen deutlich reduzieren. Möglich, so Kreutz, werde das durch im Projekt entwickelte Verfahren und Tools, mit denen sich Testläufe zusätzlich auch in einer virtuellen Simulationsumgebung durchführen lassen. Diese können zwar die reale Erprobung in der Testhalle nicht vollständig ersetzen, diese aber auf wenige, kritische Szenarien reduzieren.

Interdisziplinäre Coproduktion

Die virtuellen Probeeinsätze der Roboter-Systeme sind ein wichtiger, aber nicht der einzige »Booster«, den die Projektpartner identifiziert und umgesetzt haben: Ein zweites Kernelement des »RoboDevOps«-Ansatzes ist die zeit- und qualitätsoptimierte Zusammenarbeit der Teams von den Softwareentwickler*innen bis zu den Betreuer*innen der Systeme im laufenden Betrieb. »Sowohl die Organisation der Teamarbeit wie auch die Entwicklungs-, Dokumentations-, und Kooperationswerkzeuge müssen so gestaltet sein, dass sie die bestmöglichen Schnittstellen für zielführende Entwicklungsprozesse bieten«, sagt Kreutz. Als erstes mussten die Forscher*innen dafür gemeinsam mit den Akteuren der unterschiedlichen Fachdomänen eine gemeinsame »Sprache« und ein gegenseitiges Verständnis der jeweils aufgabenspezifischen Prozesse schaffen. Und zweitens entwickelten und erprobten sie strukturierte, weitgehend automatisierte Abläufe, die eine schnelle, effiziente Zusammenarbeit über alle beteiligten Abteilungen hinweg garantieren.

»Das läuft dann zum Beispiel über ‚Quality-Gates‘, die wir ebenfalls eingeführt haben«, erklärt Kreutz. An jedem der Gates muss ein Entwicklungsprojekt definierte Qualitätsziele nachweislich erreicht haben. Sowohl innerhalb der Fachdomänen, als auch im Zusammenspiel mit dem Gesamtsystem. Fehler lassen sich so schneller und vor allem auch zuverlässig finden, die Korrektur- und Anpassungsschleifen werden verkürzt. 

»Speziell für die Entwicklungsprozesse bei den AMR-Systemen unseres Projektpartners hat die Methode bereits zu deutlichen Verbesserungen geführt«, resümiert Kreutz. Die Prinzipien und Lösungen des Projekts seien aber auch als Blaupause für Qualitätsabsicherungen bei anderen Robotersystemen oder Maschinen geeignet. Allerdings sei immer auch eine unternehmensspezifische Anpassung der Werkzeuge und Vorgehensweisen notwendig. Orientierung dabei gibt das aktuelle Whitepaper »DevOps for Developing Cyber-Physical Systems«, in dem die Projektpartner einen Überblick geben, wie sich das »DevOps«-Erfolgsmodell über den Tellerrand der Informatik hinaus gewinnbringend einsetzen lässt.

(stw)