Heutzutage sind Fertigungsanlagen auf die Massenproduktion identischer Waren ausgelegt. Obwohl Fertigungssysteme oft eine gewisse Flexibilität besitzen, sind sie nicht vollständig wandelbar. Stattdessen sind Änderungen mit hohen Kosten verbunden. Wandelbare Produktion hingegen erlaubt es Herstellern, schneller auf eine veränderte Nachfrage zu reagieren und kleine Losgrößen effizient zu produzieren. Der Digitale Zwilling ist ein Schlüsselkonzept für die Umsetzung der erforderlichen Wandelbarkeit. Doch diese Wandelbarkeit kann nicht durch die Integration einzelner »Industrie-4.0-Geräte« in das Produktionssystem erzielt werden. Vielmehr werden neue Architekturkonzepte benötigt. BaSys 4.0 definiert eine Referenzarchitektur für Produktionssysteme, die den Wandel zur Industrie 4.0 ermöglicht. Unsere Open-Source Middleware Eclipse BaSyx ist eine Referenzimplementierung der Konzepte von BaSys 4.0.
Sich wandelnde Märkte erfordern eine wandelbare Produktion
Die zunehmende Nachfrage nach individualisierten Produkten und die immer kürzeren Produktlebenszyklen eröffnen Fertigungsanlagen neue Möglichkeiten, sich von der Konkurrenz abzuheben [1]. Traditionell waren die Verkaufsargumente in der Fertigung Stückkosten und Qualität; heute gewinnt die Fähigkeit, individualisierte Produkte herzustellen, zunehmend an Bedeutung. Hersteller, die in der Lage sind, Produkte zu individualisieren, können schon heute wesentlich höhere Umsätze pro Produkt erzielen; ein Hersteller, der zum Beispiel in der Lage ist, ganz bestimmte Bohrungen für Sicherheitsgurte in speziellen Fahrzeugvarianten hinzuzufügen, kann für seine individualisierten Produkte deutlich höhere Stückpreise verlangen als für seine regulären Produkte. Bei individualisierten Produkten besteht jedoch die Herausforderung darin, dass solche Produkte nur in kleinen Losgrößen nachgefragt werden. Die Änderungskosten sind bei traditionellen Fertigungslinien zu hoch, um kleine Losgrößen wirtschaftlich zu realisieren. Andererseits könnte ein wandelbares Fertigungssystem höhere Stückkosten für individualisierte Produkte zu geringen Mehrkosten oder gar ohne Mehrkosten für die Änderung der Fertigungslinien realisieren. Dies bringt Wettbewerbsvorteile [2], erfordert aber eine neue Fertigungsarchitektur für Produktionsanlagen.
Wandelbare Produktion erfordert Wandelbarkeit sowohl bezüglich der Produktionsressourcen einer Fertigungslinie als auch bezüglich der Produktionsprozesse. Zur physikalischen Wandelbarkeit gehört die Fähigkeit, beispielsweise die von einem Roboter benutzten Werkzeuge zu ändern, eventuell Produktionsgeräte hinzuzufügen oder zu entfernen und Mitarbeiter auszubilden. Veränderungen der Produktionsprozesse erfordern Änderungen im Bereich Prozessautomation, Anpassung der Prozess- und Qualitätsdokumentation und möglicherweise die Einrichtung von Lieferketten und die erneute Zertifizierung von Fertigungslinien, um sicherzustellen, dass sie die Kundenanforderungen erfüllen.
Physikalische Wandelbarkeit ist normalerweise in bestehenden Fertigungslinien gegeben. Änderungen im Bereich Prozessautomation und Re-Zertifizierung sind dagegen die Haupthindernisse, die einer wandelbaren Produktion im Wege stehen. Diese lassen sich nicht einfach durch den Austausch eines einzelnen Geräts erzielen, sondern die Fertigungsprozesse müssen an Industrie 4.0 angepasst werden. Heutzutage wird Prozessautomation mithilfe speicherprogrammierbarer Steuerungen (SPS) realisiert. Diese führen zyklische Programme aus, die in einer Standardsprache programmiert sind; in den meisten Fällen handelt es sich hierbei um Sprachen, die den Anforderungen von IEC 61131 entsprechen. Eine einzelne SPS automatisiert eine Produktionszelle oder einen Schritt eines automatisierten Fertigungsprozesses. SPS steuern Arbeitsplätze und Roboter und führen für jedes Werkstück die notwendigen Prozessschritte aus. Programmparameter ermöglichen eine vordefinierte Flexibilität in der Herstellung, die es möglich macht, Produktvarianten herzustellen, z.B. Fahrzeuge mit und ohne adaptive Tempomatsysteme. Der komplette Fertigungsprozess wird auf alle SPS der Fertigungslinie verteilt. Änderungen in der Prozessautomation erfordern daher die Umprogrammierung der SPS, was heute oftmals unerwünschte Seiteneffekte in dem Prozess verursacht. Diese Seiteneffekte führen zu deutlich längeren Stillstand- und Änderungszeiten sowie höheren Kosten.
Wandelbarkeit möglich machen mit BaSys-4.0-Architekturkonzepten
Wandelbare Prozesse verkürzen die Stillstandzeiten von Fertigungslinien bei Prozessänderungen. Idealerweise kann die Programmierung ohne Seiteneffekte und ohne jegliche Stillstandzeiten geändert werden. BaSys 4.0 definiert eine dienstbasierte Fertigungsarchitektur, die diese Wandelbarkeit ermöglicht. Es sind nicht mehr SPS, die Prozessschritte umsetzen, sondern aufrufbare Dienste, die das tun [3], wie in Abbildung 1 illustriert. SPS-Basisdienste implementieren Echtzeitverhalten, das Fertigungsschritte steuert, z.B. für das Bohren von Löchern, oder automatisierte Qualitätsbewertung. Die Anpassung der Dienste ist mithilfe von Parametern möglich, die zum Beispiel die Position und Größe von Bohrlöchern bestimmen. Für alle Basisdienste ist es unabdingbar, dass sie atomar und zustandslos sind; d.h. es muss möglich sein, sie kontextunabhängig aufzurufen und sie dürfen keinen internen Zustand haben. Alle relevanten Parameter und Produktzustände müssen beim Aufruf eines Dienstes angegeben werden. Die SPS weiß daher, wie ein Dienst zu implementieren ist, hat aber keine Kenntnis darüber, wann ein Dienst aufgerufen wird. Stattdessen steuern Orchestratoren den Aufruf von Diensten und verbinden so Basisdienste mit Fertigungsprozessen. Dies ähnelt somit dem Ansatz der serviceorientierten Architektur, der in vielen großen Softwareprojekten erfolgreich eingesetzt wird [4]. Der Orchestrator verwendet eine Rezeptur, bei der es sich um ein digitales Prozessmodell handelt, das für jedes Produkt die notwendigen Fertigungsschritte definiert.
Dank der serviceorientierten Architektur ist die Anpassung von SPS-Programmen lediglich bei der Entwicklung neuer Basisdienste erforderlich; die Anpassung von Produkten erfordert nur Änderungen an übergeordneten Rezepturen. Orchestratoren können beispielsweise BPMN-Modelle (BPMN = Business Process Model and Notation) verwenden, um Rezepturen zu beschreiben, und BPMN-Engines, um den Orchestrierungsprozess zu implementieren. Um ein Produkt zu ändern, muss dann nur das BPMN-Modell für dieses Produkt geändert werden, was viel einfacher und weniger zeitaufwändig ist als das SPS-Programm zu ändern.
Gerätesteuerungskomponenten auf SPS implementieren Dienstanbieter für grundlegende SPS-Dienste. Diese dürfen keine Abhängigkeiten zwischen Diensten definieren, z.B. von anderen Diensten, die auf dem gleichen Gerät laufen, oder von Diensten auf anderen Geräten. Es darf während der Ausführung eines Dienstes keine Kommunikation zwischen SPS stattfinden. Wenn ein Basisdienst ausgeführt wird, machen wir zur Bedingung, dass die SPS nur mit denjenigen Sensoren und Aktuatoren kommuniziert, die für die Umsetzung des Fertigungsschritts und für zusätzliche Sicherheitsfunktionen notwendig sind. Gruppensteuerungskomponenten implementieren Orchestratoren, d.h. Nutzer eines Dienstes. Wenn sie einen Dienst aufrufen, müssen sie den Dienstanbietern alle Parameter zur Verfügung stellen. Die Ergebnisse, wie z.B. gesampelte Qualitätsdaten und die Dokumentation von Prozessschritten, werden dem Orchestrator nach Abschluss des Dienstes zur Verfügung gestellt. Dies verhindert Seiteneffekte bei der Änderung von Produktrezepturen und der Reihenfolge des Aufrufs von Diensten.
Die Trennung von Steuerungskomponenten in Gerätesteuerungskomponenten und Gruppensteuerungskomponenten ähnelt dem Clean-Code-Prinzip bei der Softwareentwicklung (s. https://clean-code-developer.com/). Clean Code befürwortet die Trennung von Softwarefunktionen in solche, die das Verhalten von Algorithmen implementieren, und solche, die Funktionen in übergeordnete Funktionen integrieren. Dieses Prinzip hat zu leicht wartbaren großen Softwaresystemen geführt. BaSys passt dieses Prinzip an, indem es das Verhalten von Algorithmen durch den Zugriff auf native Geräte ersetzt. Sowohl Gerätesteuerungskomponenten als auch Gruppensteuerungskomponenten implementieren Dienste, unterscheiden sich aber in Bezug auf die Art der implementierten Dienste. Gerätesteuerungskomponenten bieten Dienste, die direkt auf Prozessgeräte zugreifen, z.B. Lichtschranken und Roboter, doch sie orchestrieren niemals andere Dienste. Gruppensteuerungskomponenten orchestrieren Dienste, greifen aber niemals auf native Geräte zu.
Ähnlich wie BaSys erfordert auch Clean Code, dass der Aufrufer eines Dienstes alle Informationen für den Aufruf mittels Parametern bereitstellt, verlangt, dass die Funktion dem Caller nach Beendigung alle Resultate liefert, und verbietet, dass eine Funktion nach der Beendigung eines Aufrufs einen Zustand behält.
Industrie-4.0-Szenarien und -Architekturkonzept
Die BaSyx-Steuerungskomponenten definieren vereinheitlichte Schnittstellen für die Geräte- und Gruppensteuerungskomponenten. Gruppensteuerungskomponenten können daher selbst Dienstanbieter sein, was eine hierarchische Abstraktion von Produktionsdiensten ermöglicht. Während Gerätesteuerungskomponenten beispielsweise Basisdienste implementieren, die die Bewegung auf einem Fließbandabschnitt implementieren, können Gruppensteuerungskomponenten komplexere Dienste implementieren, die selbstständig den Transport von Werkstücken durch den Fertigungsprozess hindurch steuern.
Die Definition gemeinsamer Basisdienste für Gerätetypen macht es auch einfacher, Geräte bei der Wartung auszutauschen. Wenn ein Gerät ersetzt werden muss, z.B. aufgrund der Verfügbarkeit von Geräten durch ein anderes Gerät, werden Stillstandzeiten deutlich verkürzt, wenn das neue Gerät das gleiche Set an Diensten implementiert und sich daher nahtlos in die Gruppensteuerungskomponenten integriert, die die Prozessautomation steuern.
Gerätekomponenten werden entweder als explizite Hardwarekomponenten realisiert, die mit Geräten verbunden werden, oder in intelligenteren Geräten als Softwarekomponenten. Der Einsatz zusätzlicher Hardwaregeräte ermöglicht bereits bestehenden Fertigungsanlagen den Übergang zu Industrie 4.0.
Abbildung 2 zeigt, dass Gruppensteuerungskomponenten Daten über das gefertigte Produkt an die Gerätesteuerungskomponenten liefern müssen und die zurückgesendeten Werte speichern müssen. Herstellergerätespezifische Daten, wie etwa die Zahl der Prozessaufrufe, müssen eventuell ebenfalls für die spätere Verwendung gespeichert werden. Da Dienste Daten, die über Dienstaufrufe hinweg persistent sind, nicht intern speichern dürfen, müssen solche Daten an anderer Stelle gespeichert werden. BaSyx verwendet Verwaltungsschalen (VS) für den Zugang zu Untermodellen, die Asset-Daten strukturieren. Ein Untermodell fokussiert daher auf eine bestimmte Art von Daten und definiert ein Metamodell, das diese Daten strukturiert. Wenn Verwaltungsschalen Untermodelle definieren, die eine Prognose für ein Asset ermöglichen, dann wird aus der VS ein Digitaler Zwilling des Assets.
Verfügbarkeit
Eclipse Basyx wird im Kontext der Projekte BaSys 4.0 und BaSys 4.2 entwickelt, die vom Bundesministerium für Bildung und Forschung (BMBF) gefördert werden. Es integriert relevante Konzepte aus Forschungs- und Normungsgremien, z.B. von der Plattform Industrie 4.0. Unsere Open-Source-Middleware Eclipse BaSyx (https://projects.eclipse.org/projects/technology.basyx) implementiert wichtige Industrie-4.0-Konzepte und bietet Referenzimplementierungen für gängige Industrie-4.0-Komponenten. Außerdem bietet sie ein Software Development Kit für die Implementierung neuer Industrie-4.0-Komponenten und für die Integration von Geräten und SPS-Controllern. Weiterführende Informationen zu Eclipse BaSyx sind unter https://www.eclipse.org/basyx/ zu finden.
Literatur
- Wang, Y.; Ma, H. S.; Yang, J. H.; Wang, K. S.: Industry 4.0: a way from mass customization to mass personalization production. Advances in Manufacturing, 5 (2017) 4, S. 311-320.
- Lasi, H.; Fettke, P.; Kemper, H.-G.; Feld, T.; Hoffmann, M.: Industry 4.0 Business & information systems engineering 6 (2014), S. 239-242.
- Colombo, A. W.; Karnouskos, S.; Mendes, J. M.: Factory of the future: A service-oriented system of modular, dynamic reconfigurable and collaborative systems. In Artificial intelligence techniques for networked manufacturing enterprises management. London 2010.
- Perrey, R.; Lycett, M.: Service-oriented architecture. In: Applications and the Internet Workshops, 2003. IEEE. 2003 Symposium on (2003), S. 116-119.