Im Wareneingang von Continental kommen täglich tausende von Paketen von Zulieferern für die Herstellung von elektronischen Bauteilen, wie Platinen für Fahrzeuge, an. Diese werden bis zu ihrer Verwendung an einer Arbeitsstation des Werks vor Ort eingelagert. Die dafür notwendigen Schritte, wie das Auspacken, die Kontrolle und Sortierung der Teile, aber auch die Erfassung und Verbuchung über SAP im Wareneingangssystem, erfolgte in der Vergangenheit manuell. Eine automatische Sortieranlage soll diesen Bereich durch Automation zukünftig effizienter gestalten. Die händisch ausgepackten Bauteile werden dabei auf einem Förderband durch verschiedene Kamerasysteme über den Barcode erkannt, erfasst und validiert. Anschließend greift ein Roboter diese Bauteile vom Band ab und sortiert sie automatisch auf Basis bestimmter Sortier-Algorhythmen in verschiedene bereitgestellte Kisten. Gleichzeitig erfolgt dabei eine Verbuchung nach SAP. Bis dato gab es noch keine Software, die quasi als Mittler zwischen der Anlage – dem Roboter – und dem internen ERP System fungierte.
Die Entwicklung der Software für die Wareneingangsbuchung erfolgte über eine Schnittstelle von Conti in Richtung SAP. Dabei war es auch Ziel des Projekts, dessen Laufzeit nur knapp drei Monate betrug, einen einheitlichen Conti-Standard zu entwickeln, das heißt die serienreife Anlage soll später nicht nur im Werk Regensburg zum Einsatz kommen, sondern nach Möglichkeit weltweit. Durch den Einsatz von OPC UA, einer neuen Technologie für Kommunikationsschnittstellen und den Datenaustausch von Maschinen ließ sich eine standardisierte Schnittstelle in Richtung SPS schaffen. Für die Schnittstelle zwischen ERP-Sstem und Software kam REST zum Einsatz.
Erst der Prozess und dann die Software
Als EDAG Production Solutions vor einigen Monaten die Anfrage für die Entwicklung einer Software für die automatische Sortierstation im Wareneingang von Continental auf den Tisch bekam, waren sich die Verantwortlichen schnell sicher, dass dieses Projekt anders angegangen werden muss. Überzeugen konnte das Unternehmen schließlich durch den agilen Ansatz: Es sollten nicht irgendwelche Annahmen oder Anforderungen an die Software definiert werden, die am Ende überhaupt nicht dem entsprechen, was sich der Kunde vorstellt oder was er braucht. Deswegen wurde von Anfang an der Prozess in den Mittelpunkt gestellt und nicht die Software selbst.
„Den Ausschlag, EDAG mit der Entwicklung der Software zu beauftragen, war auch die Tatsache, dass sie nicht stur von der Software Seite kommen, sondern von der Prozessseite. Uns gefiel die Vorgehensweise, eine Software in Sprints zu entwickeln und zu programmieren und dabei den Scrum-Prozess abzuarbeiten. In der Vergangenheit kannte ich es nur so, dass man schaute, was die Software kann und der Prozess musste sich anpassen, musste der Software folgen. Der Ansatz von EDAG war komplett anders: Erst wurden die Prozesse definiert und dann überlegt, wie die Software den Prozess unterstützen kann. “, so Tamara Fischer, Head of Factory Flow & Simulation bei Continental Regensburg.
Die Umsetzung des Projekts in Scrum, einem flexiblen Vorgehensmodel für Projekt- und Produktmanagement für die Softwareentwicklung, spiegelte sich bereits in der Angebotsphase wider. Auf Basis eines agilen Festpreises wurde ein Abrechnungsmodell mit sogenannten Story Points verkauft. Es gab ein festgelegtes Kontingent von Story Points, die wiederum je nach Komplexität der einzelnen Schritte bzw. Funktionen entsprechend viele Story Points gekostet haben. In sogenannten Sprints – einem Zeitraum von vier Wochen – wurde rückwirkend immer wieder kontrolliert, was die nächsten Schritte sein müssen, damit die Software funktioniert. Dabei wurden zuerst die Funktion und nicht die Serienreife in den Fokus gesetzt.
Story-Points dienen bei Scrum dazu, den Gesamtaufwand der User-Story einzuschätzen. Die User-Storys wiederum ist die Brücke zwischen dem Softwareentwicklungsteam und dem Kunden und erfasst die Anforderungen an die Software in einer für jeden verständliche Sprache. Mehrere User-Storys bilden dann am Ende den Use-Case. Eine wichtige Voraussetzung für die erfolgreiche Entwicklung der Software war neben Scrum auch die Nutzung der Microservices-Architektur, die cloudbasiert gehostet wird. Durch die Verwendung des Kubernetes-Clusters, einem Verbund aus Rechnern für containerisierten Anwendungen, wurde das Konzept abgerundet. Bereits nach 14 Wochen konnte so der Geschäftsleitung von Continental der Proof of Concept vorgelegt, also ein Prototypen präsentiert werden.
Bild: EDAG Production Solutions GmbH & Co. KG 
Bild: EDAG Production Solutions GmbH & Co. KG
Aus einem Proof of Concept wird ein internationaler Standard
Ziel der Software war es, einen serienreifen Standard für alle Automotive-Werke von Continental zu entwickeln. Auf Basis bestimmter vordefinierter Rahmenbedingungen wie Hardware, Platzbedarf oder Peripherie funktioniert die Software werksübergreifend. Continental hat bereits eine Warteliste mit anderen Werken, die nach erfolgtem Test innerhalb der Pilotphase und dem Nachweis der Effizienz ebenfalls den Einsatz der Software planen. Auch eine Weiterentwicklung für neue Anwendungsfälle, wie z.B. der Kommissionierung inklusive eines kompletten fahrerlosen Transportsystems ist bereits im Gespräch. Basis für alle weiteren Verwendungen wird der EDAG-Prototyp für die intelligente, flexible und vollautomatisierte Sortierung von Bauteilen mit Hilfe von Industrierobotern, auf Basis von IIoT-Architekturen sein. Wichtig für die erfolgreiche Umsetzung der Software war auch die vertrauensvolle und partnerschaftliche Zusammenarbeit mit Continental: „Die Zusammenarbeit mit EDAG hat sehr viel Spaß gemacht. Durch den Scrum-Prozess haben wir schon nach zwei Wochen die ersten Screenshots der Software gesehen und konnten sogar schon Labels einscannen. Es war für mich sehr aufregend zu sehen, wie Woche für Woche dieses Stück Software und dieser Prozess von der Vision in die Realität wächst. Es war für mich wirklich sehr spannend, dieses Projekt zu begleiten.“ so Fischer.