Industrie 4.0 trotz Altsystemen - Integration bestehender Anlagen in Cyber-Physische Produktionssysteme

Sander Lass

Cyber-Physische Systeme (CPS) prägen im Rahmen von Industrie 4.0 seit geraumer Zeit die Diskussionen. Die Vision sieht Cyber-Physische Produktionssysteme (CPPS) als wesentlichen Bestandteil der modernen Fabrik zur Sicherstellung der Wettbewerbsfähigkeit produzierender Unternehmen. Wandlungsfähigkeit und Komplexitätsbeherrschung sind u. a. Potenziale dieser neuen Generation des Produktionsmanagements. Die Transformation des theoretischen Konstrukts in die praktische Realisierung kann allerdings nur unter Einbezug der den Anwendungskontext Fabrik prägenden Rahmenbedingungen erfolgen. Gegenstand des Beitrags ist ein Konzept, welches den Brown-Field-Charakter aufgreift und die CPS-Erweiterung bestehender Systeme gestattet.

Bedingt durch die Trends in der Wirtschaft und der voranschreitenden technologischen Entwicklung sind produzierende Unternehmen künftig immer mehr mit wachsender Komplexität in der Fabrik konfrontiert. Schnelle Veränderungen des Markts erfordern eine hohe Agilität des Produktionsmanagements und der Fabrikgestaltung, welche nur durch die Realisierung von Wandlungsfähigkeit effizient und zuverlässig möglich ist.
Als möglicher Lösungsansatz gelten CPS, die durch lokale Informationsbearbeitung und Autonomie sowie weitreichende Vernetzung gekennzeichnet sind. Die durch den CPS-Einsatz mögliche Dezentralisierung erlaubt, der zunehmenden, multidimensionalen Komplexität adäquat begegnen zu können. Der Terminus CPS – im deutschsprachigen Raum geprägt durch die Forschungsagenda CPS [1] – ist integraler Bestandteil der Diskussion zukünftiger industrieller Trends. Im Rahmen der Hightech-Strategie Zukunftsprojekt „Industrie 4.0“ proklamiert die Bundesregierung CPS als Teil der Lösung zur erfolgreichen Bewältigung der wachsenden Herausforderungen durch das produzierende Gewerbe in Deutschland [2]. Als einer der wesentlichen Bausteine schaffen CPS die technische Grundlage für Selbststeuerungsmethoden in der Produktion [3, 4]. Als Potenzial der entstehenden Cyber- Physischen Produktionssysteme wird vor allem die hohe Anpassungsfähigkeit an sich ändernde Betriebsumgebungen durch die systemimmanente Adaptivität und Autonomie herausgestellt [1].
 


Bild 1: Prinzip der I4.0-Box.

Rahmenbedingungen

Eine erfolgreiche Transformation in CPPS bedarf der Berücksichtigung der den Anwendungskontext Fabrik prägenden Rahmenbedingungen. Die Fabrik-IT konstituiert sich größtenteils aus der Automatisierungstechnik. Im Vergleich zur Office-IT mit den Informationssystemen der höheren Ebenen der Automatisierungspyramide (vgl. u. a. [5]) ergeben sich zusätzliche Rahmenbedingungen [6, 7]. Dies sind u. a. die Echtzeitfähigkeit der Steuer- und Regelkreise bzgl. Informationsverarbeitung und -übertragung sowie die durch lange Betriebs- und Innovationszyklen (> 7 Jahre) implizierte Realisierung im Brown-Field.
Aus der Aufgabe, Steuer- oder Regelkreise für physisch agierende Komponenten zu implementieren, resultiert das Erfordernis der Echtzeitfähigkeit. Echtzeitfähigkeit bedeutet, dass ein System garantiert innerhalb einer Zeitschranke reagiert (Rechtzeitigkeit), nebenläufig mehrere Vorgänge bearbeitet (Gleichzeitigkeit), planbar und deterministisch ist (Vorhersehbarkeit) und unter definierten Umgebungsbedingungen ordnungsgemäß arbeitet (Verlässlichkeit) [6]. Aufgrund der Assoziation mit externen technischen Prozessen muss die Datenverarbeitung bzw. Kommunikation zwingend synchron und schritthaltend erfolgen, d. h., die Dimension Zeit besitzt explizite Relevanz im Vergleich zur allgemeinen Datenverarbeitung [7].
Die praxistypische Implementierung von CPS ist als Brown-Field-Szenario zu betrachten. Die Errichtung von Grund auf neuer Produktionsstätten ist eher der Ausnahmefall. Typische Situation ist die Reorganisation bestehender Anlagen und Prozesse, die möglicherweise aufgrund langfristig gewachsener Strukturen mit erheblichem Aufwand verbunden sein kann [8]. Gegebenenfalls müssen aus Gründen des Investitionsschutzes oder fehlender Investitionsbereitschaft bereits bestehende Systeme zweckmäßig eingebunden werden. Die CPS-Einführung mit gleichzeitiger Neuentwicklung bildet keine realistische Option, eher ist die bestmögliche Integration von CPS in vorhandene Informationssysteme eine wesentliche Forschungsfrage [3].
Als potenzielle Elemente eines CPPS bedürfen Produktionsobjekte der grundlegenden CPS-Fähigkeiten, um im Verbund ausreichend Kommunikationsfähigkeiten anzubieten, komplexitätsreduzierende Autonomie zu realisieren und in kooperativer Interaktion die Vorteile der Dezentralität umsetzen zu können.
Der Begriff Produktionsobjekte subsumiert die möglichen Entitäten der Fertigung und Produktionsplanung. Diese sind Elemente des Produktionssystems und in diesem Kontext vorrangig Maschinen und Werkzeuge, Werkstücke und Werkstückträger sowie Logistikausrüstung, wie Transportsysteme mit Fahrzeugen, Förderstrecken und Puff erelementen. Autonomie und Dezentralität bedeuten insbesondere die Informationsaufnahme und -verarbeitung sowie Entscheidungsfi ndung und -ausführung direkt vor Ort durch die Produktionsobjekte selbst [9]. Dahingehend bedarf es Subsystemen mit erweiterten Speicher- und Kommunikationsfähigkeiten, die die Umsetzung eines umfassenden Informationsaustauschs und der Umgebungswahrnehmung sowie der selbstständigen Aufgabendurchführung erlauben [10].
Die vor allem durch die Autonomie implizierte lokale Informationsverarbeitung und Entscheidungsausführung erfordert entsprechende Algorithmen. Die Umsetzung der angestrebten schnellen und ggf. automatischen Rekonfi guration von Anlagen (Wandlungsfähigkeit) sowie die lokale Bereitstellung aggregierter Funktionen und Systemzustände (Komplexitätsbeherrschung) durch klassische SPS-Automatisierungslösungen zeigten, dass die schrittkettenbasierte Programmierweise die Realisierung der notwendigen Algorithmen erschwert und zum Teil das Echtzeitverhalten (Zykluszeit) ungünstig beeinfl usst. Damit ergänzt die Notwendigkeit der lokalen Implementierung komplexer Algorithmen die Echtzeitfähigkeit und den Brown-Field-Charakter als weitere Rahmenbedingung.
Die Kombination dieser drei Prämissen führt zu Lösungsansätzen, die die CPS-Befähigung vorhandener Produktionsobjekte durch geeignete Erweiterung vorsehen, die sowohl Echtzeitfähigkeit sicherstellt als auch die adäquate Implementierung komplexer Algorithmen unter Vermeidung der Restriktionen der klassischen Programmierweisen der Automatisierungstechnik erlaubt. Mit Blick auf die einzubeziehenden Altanlagen beinhaltet dies sowohl Hardware- als auch Softwareaspekte.


Bild 2: Architektur und Komponenten des FaBS.

CPS-Befähigung vorhandener Produktionsobjekte

Da nicht davon auszugehen ist, dass vorhandene Maschinen und Anlagen ohne Weiteres durch neue Exemplare ersetzt werden, ergibt sich die Implikation, Vorhandenes in geeigneter Form zu befähigen, als Teil eines CPPS zu agieren. Insbesondere die Integration von geschlossenen Legacy-Systemen bildet einen typischen Anwendungsfall. Um dieser Problemstellung adäquat zu begegnen, sieht das Konzept einen Baustein vor, welcher die Nachrüstung der geforderten Eigenschaften ermöglicht und ein Produktionsobjekt mit CPS-Fähigkeiten ausstattet. In Anlehnung an den Industrie 4.0 Begriff fi ndet die Bezeichnung I4.0-Box Verwendung. Ebenfalls diesen Aspekt aufgreifend, beschreibt auch das Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0) unter dem konzeptionellen Begriff Verwaltungsschale einen derartigen Ansatz [11].
Bild 1 skizziert das Wirkprinzip der Industrie 4.0-Box. Der Baustein erhält Zugriff auf die verbauten Sensoren des Produktionsobjekts durch deren Konnektierung per diskreter Verkabelung, mittels vorhandenem Feldbus über die Steuerung/SPS oder alternativ über zusätzliche Sensoren, die an geeigneter Stelle installiert werden. Aktoren werden über Feldbus oder über direkte Verkabelung zur Steuerung angebunden.

Fabrikbetriebssystem

In Analogie zu Betriebssystemen und deren Aufgaben – der Abstraktion der Betriebsmittel von der zugrundeliegenden Hardware und der Verwaltung der Hardwareressourcen – werden die Softwarekomponenten der Boxen unter dem Terminus Fabrikbetriebssystem (FaBS) zusammengefasst.
Das FaBS basiert auf der in Bild 2 dargestellten Architektur. Wesentliche Elemente sind Laufzeitumgebung, ConnectionService und MonitoringService sowie KPI-Service und Control-Center.
Die Laufzeitumgebung teilt sich in zwei Funktionsbereiche. Die Low-Level-Runtime (LLR) ermöglicht die Umsetzung echtzeitkritischer Funktionen. Die Realisierung geschieht per SPS oder echtzeitfähigen Mikrocontrollern, deren Programmierung mittels automatisierungstypischer Entwicklungsumgebung (beispielsweise CODESYS) erfolgt. In der praktischen Umsetzung zeigte sich, dass eine dieser Art folgende Implementierung bei komplexen Algorithmen an ihre Grenzen stößt. Die Gestaltung eines frei konfi - gurierbaren Transportsystems mittels zentraler SPS als steuernde Instanz erwies sich mit der klassischen Schrittketten-Programmierweise als schwer handhabbar. Deshalb sieht das Konzept eine weitere Möglichkeit der Implementierung vor. Die High-Level-Runtime (HLR) gestattet die Nutzung höherer Programmiersprachen und -paradigmen und begünstigt die schnelle Erweiterung. Je nach Produktionsobjekt und Bedarf resultiert das Verhalten aus der LLR- oder der HLR-Umsetzung oder deren Kombination.
Der ConnectionService realisiert die Kommunikation der Komponenten. Ähnlich einem Treiber nimmt er eine Abstraktion von technischen Details vor und bietet Zugriff auf Funktionen des FaBS. Er erlaubt die Implementierung einer Gateway- Funktion zwischen der internen Kommunikation der Systemkomponenten und dem jeweiligen Protokoll der externen Komponente. Dies kann unter Nutzung von Standards (wie OPC-UA im Falle der Verknüpfung von LLR und HLR) oder mittels durch den Anbieter spezifisch definierter Art und Weise geschehen. Instanzen des ConnectionServices können als zentraler Serverdienst angelegt oder dezentral, innerhalb der relevanten Komponenten implementiert werden.
Wesentliche Eigenschaft eines CPS ist die Umgebungswahrnehmung. Zuständiges lokales Modul ist der MonitoringService. Die Laufzeitumgebung jedes Produktionsobjekts nimmt das Loggen und Abspeichern von Ereignissen (Events) vor. Dies umfasst u. a. Kommunikationsvorgänge und Veränderungen von Umgebungsdaten, Mengen und Eigenschaften, die das interne Modell abbildet, sowie Benutzerinteraktionen. Ebenfalls ist die Protokollierung von Wertverläufen in bestimmten Zeitintervallen vorgesehen, die sich über zeitbasierte Events in die ereignisorientierte Verfahrensweise einreiht.
Ergänzend zu der lokalen Persistierung von Ereignissen ist dem allgemeinen Paradigma Inversion of Control (IoC) folgend mit der Verwendung von Listenern eine weitere Möglichkeit gegeben, Informationen zielgerichtet zu kommunizieren bzw. abzurufen. Adressierter Anwendungsfall ist vorrangig die Bereitstellung von Echtzeitdaten und die Vermeidung von ineffizientem Polling. In diesem Zusammenhang bezieht sich der Begriff Echtzeit auf die Aktualität, d. h., die Werte spiegeln den zum Betrachtungszeitpunkt tatsächlich vorliegenden Wert wider.
Der ProcessService koordiniert zeitliche Abläufe und ist für Zeitsynchronisation der Produktionsobjekte zuständig. Mit dem RessourceService werden Abhängigkeiten bezüglich notwendiger Betriebsmittel bei der Ausführung abgebildet. Dies sind insbesondere benötigtes Material und Werkzeuge, Personal, Baugruppen oder Halbzeuge.
Ein VirtualDevice bildet ggf. ein Modell eines bestimmten Elements oder Subsystems ab (Digitaler Zwilling).
 


Bild 3: Verwendete Module und relevante Größen.

Proof of Concept

Teil der Validierung ist die prototypische Umsetzung im Anwendungszentrum Industrie 4.0 Potsdam [12], welche ein konventionelles Rollenbahnsystem als Vertreter eines Altsystems – bestehend aus unterschiedlichen Modulen – gemäß dem CPS-Konzept ausstattet und eine dezentrale Anlagenkoordination mit intelligenten Elementen erlaubt. Dieser Anwendungsfall adressiert ebenfalls die Komplexitätsreduzierung durch dezentrale Steuerung und die Möglichkeit der schnellen Rekonfiguration des Transportsystems. Dahingehend teilt sich das Gesamtsystem in Segmente auf, die jeweils eine geringe Anzahl von Modulen mithilfe der I4.0-Box anbinden. Alle Signale sind direkt mit dem Interface-Baustein der Box konnektiert. Auf der LLR werden deren Basisfunktionen abgewickelt (z. B. Motor an, bis Lichtschranke auslöst). Die HLR sorgt für die Abstraktion dieser Elementarabläufe zu Funktionsaufrufen (wie Durchfahrt) und stellt sie dem externen Zugriff zur Verfügung. Weiterhin löst die HLR – gegebenenfalls im Zusammenspiel mit anderen CPS – komplexe Aufgaben (wie Routenwahl oder Konfliktbewältigung). Deren Lösungsalgorithmen sind mittels höherer Programmiersprache (hier Python) implementiert. Dieses Setup bildet die Steuerungsvariante (A).
Diesem wird die Variante (B) mit zentraler SPS mit diskreter Verkabelung aller Komponenten gegenübergestellt. Der Vergleich erfolgt mithilfe dreier Szenarien: partielle Layoutänderungen (Ausfall eines Moduls, Hinzufügen eines Elements) und starke Veränderung des Layouts (Rekonfi guration von mehr als der Hälfte der Module). Die verwendeten Module zeigt Bild 3a. Sie sind jeweils durch vorhandene Sensor- und Aktorsignale, Anzahl der Ports und die internen Positionen charakterisiert. Folgende Basismodule stehen zur Verfügung: Transfere (3 Ports und 1 Position), gerade Abschnitte (2 Ports und 2 Positionen sowie 2 Ports und 4 Positionen) und gekrümmte Abschnitte (2 Ports mit 2 Positionen) sowie einen Dispatcher (6 Ports und 1 Position). Erkennbar ist, dass insgesamt 110 Ein-/Ausgangssignale und 65 die Konfi guration bzw. den momentanen Zustand beschreibende Variablen berücksichtigt werden müssen. Hinzu treten die hinterlegten Routen von den relevanten Start- bzw. Zielpunkten.


Bild 4: Benötigte Aufwände.

Bild 4 zeigt die benötigten Aufwände beider Varianten. Diese strukturieren sich jeweils in Hardwaresetup (vor allem Verkabelung), Programmerstellung und Inbetriebnahme mit abschließendem Gesamttest der Anlage. Der selbsttätigen Anpassung im Fehlerfall mit kurzem Anlagentest von (A) steht ein wesentlich höherer Aufwand für die Programmanpassung von (B) gegenüber. Besonders stark ausgeprägt ist die Aufwandsreduzierung durch CPS bei der Programmerstellung. Im Gegensatz dazu ist bezüglich Hardwaresetup nur geringfügig höherer Aufwand bei (B) festzustellen. Dem Anwender erlaubt die resultierende Aufwandsminderung den Verzicht (Szenario 1 und 2) oder die Reduktion (Szenario 3) der Inanspruchnahme interner oder externer Dienstleister bei Wartung bzw. Rekonfi guration. Ebenfalls ist die Skalierung des Systems durch Ergänzung um weitere Segmente ohne tiefgreifende Anpassungen (Szenario 2) möglich.
Insgesamt zeigt diese erste Validierung, dass durch den Einsatz der I4.0-Box mit FaBS die Vorteile der dezentral organisierten CPS-Variante in bestehenden Systemen umgesetzt werden können. Insbesondere zeigt sich dies bei der Programmerstellung. Die Ergebnisse deuten auf einen progressiven Anstieg der Komplexität der Informationsverarbeitung respektive Rekonfi gurationsaufwand in Abhängigkeit von der Anzahl der zu verarbeitenden Datenmenge hin. Eine geeignete Segmentierung der Steuerungsaufgabe mit dezentraler Ausführung wirkt dem entgegen, sofern sich die notwendigen Fähigkeiten aufwandsarm – hier durch die Erweiterung vorhandener Systeme – realisieren lassen. Im Rahmen des Anwendungszentrums Industrie 4.0 Potsdam finden dahingehend weitere Forschungsarbeiten statt.

 

Das Anwendungszentrum Industrie 4.0 stellt eine hybride Simulationsplattform aus cyber-physischen Systemen (CPS) und realer Automatisierungstechnik bereit. Durch die Kombination von Softwaresimulation und physischer Modellfabrik können alle Produktionselemente der Simulationsumgebung für unterschiedliche Grade an dezentraler Steuerung konfi guriert und reale Industriekomponenten problemlos eingebunden werden. Als cyber-physische Forschungsplattform bietet Simulationsumgebung ein Werkzeug für Forschungsthemen im Rahmen des Produktionsmanagements als auch der Automatisierung.

Schlüsselwörter:

Fabrikbetriebsystem, CPPS, CPS, dezentrale Produktionssteuerung, Industrie 4.0 Retrofit

Literatur:

[1] acatech: acatech Studie: Integrierte Forschungsagenda Cyber-Physical Systems. Deutsche Akademie der Technikwissenschaften Berlin 2012.
[2] BMBF: Zukunftsbild Industrie 4.0. Bundesministerium für Bildung und Forschung – Referat IT-Systeme. 2014.
[3] Gronau, N.: Der Einfl uss von Cyber-Physical Systems auf die Gestaltung von Produktionssystemen. In: Kersten, W.; Koller, H.; Lödding, H. (Hrsg): Industrie 4.0 – Wie intelligente Vernetzung und kognitive Systeme unsere Arbeit verändern. In: Schriftenreihe der Hochschulgruppe für Arbeitsund Betriebsorganisation e.V. (HAB). Berlin 2014, S. 279-295.
[4] acatech: acatech POSITION: Cyber-Physical Systems: Innovationsmotor für Mobilität, Gesundheit, Energie und Produktion. Deutsche Akademie der Technikwissenschaften. Heidelberg 2011.
[5] Langmann, R.: Taschenbuch der Automatisierung. München 2004.
[6] Lauber, R.; Göhner, P.: Prozessautomatisierung 2. Berlin Heidelberg 2013.
[7] Halang, W. A.: Schwerpunkte der internationalen Forschung im Bereich Echtzeitsysteme. In: Henn, R.; Stieger, K. (Hrsg.): PEARL 89 – Workshop über Realzeitsysteme Bd. 231. Berlin Heidelberg 1989, S. 1-12.
[8] Kühn, W.: Digitale Fabrik. München 2006.
[9] Theuer, H.: Extension of Value Stream Design for the Simulation of Autonomous Production Systems. In: Enabling Manufacturing Competitiveness and Economic Sustainability. Berlin Heidelberg 2012, S. 586-591.
[10] Freitag, M.; Herzog, O.; Scholz- Reiter, B.: Selbststeuerung logistischer Prozesse – ein Paradigmenwechsel und seine Grenzen. In: Industrie Management 20 (2004) 1, S. 23-27.
[11] Adolphs, P.; Epple, U.; u. a.: Statusreport Referenzarchitektur Industrie 4.0 (RAMI4.0). 2015.
[12] Lass, S.: Simulationskonzept zur Nutzenvalidierung Cyberphysischer Systeme in komplexen Fabrikumgebungen. Dissertation, Universität Potsdam 2017.