1 Einleitung

Seit der Mitte des 18. Jahrhunderts ist die industrielle Fertigung in stetigem Wandel. Mit der Entwicklung dampfbetriebener Arbeits- und Kraftmaschinen um 1750 wurde die erste industrielle Revolution eingeleitet. Zum Ende des 19. Jahrhunderts ermöglichte die Einführung arbeitsteiliger Massenproduktion und wissenschaftlicher Betriebsführung das erste Transportband in der Fleisch verarbeitenden Industrie. Knapp einhundert Jahre nach dieser zweiten Revolution wurden 1969 erste speicherprogrammierbare Steuerungen (SPS) zur variantenreichen Serienproduktion eingesetzt. Informations- und Kommunikationstechnologie sind seither der Grundstein automatisierungsgetriebener Rationalisierungen. Im Jahr 2011 wurde ausgehend von Lean Production der Begriff Industrie 4.0 geprägt, der die vierte industrielle Revolution beschreibt (vgl. zu diesem Abschnitt [1]). Sie zeichnet sich durch neue Ansätze wie das Internet of Things (IoT) und cyber-physische Systeme (CPS) im Kontext industrieller Produktion aus [2].

1.1 Motivation

Vor der vierten Revolution war klassische Produktionssteuerung zentralisiert und Steuerungstechnik monolithisch strukturiert. Zukünftig wird die Fertigung in cyber-physische Systeme von Systemen zerlegt und mit offenen Standards dezentral betrieben (vgl. zu diesem Absatz [3]).
Moderne Produktionseinrichtungen beherbergen Maschinen jeden Alters, die zu einem gemeinsamen System verwachsen müssen. Die Technologie zur numerischen Kontrolle von Werkzeugmaschinen existiert seit den frühen 1950er Jahren [4]. Gerade diese älteren Anlagen besitzen keine Möglichkeit der Integration in die IT-Systeme einer künftigen Fertigungsstrecke [5]. Das schlichte Ersetzen dieser Altmaschinen ist aufgrund hoher Kosten keine Lösung [6].
Dennoch behindern sie vorrangig die nahtlose Machine-to-Machine (M2M) Kommunikation durch fehlende Infrastrukturanbindung, womit die Kette von Bearbeitungsschritten für ein Produkt zahlreiche manuelle Eingriffe erfordert.
Vor einigen Jahren wurden bis zu 60 % der Arbeitszeit eines Werkers auf die Übertragung des Entwurfs eines Fertigungsschrittes in die Umsetzung an der Maschine verwendet [7]. So besitzt eine Altmaschine als Teil des Fertigungsprozesses keine Möglichkeit externer Kommunikation und kein Application Programming Interface (API) [8]. Bei jüngeren Konstruktionen treten Integrationsschwierigkeiten an anderer Stelle auf. So sind auch bei bestehender Netzwerkfähigkeit geschlossene Soft- und Hardwarearchitekturen und fehlende Schnittstellen verantwortlich für eingeschränkte Überwachung und Steuerung, respektive für die Verhinderung von ökonomisch sinnvoller Automatisierung (vgl. zu diesem Absatz [8, 9]). Weiterhin erschweren die unzureichende Umsetzung von Industriestandards und  die Integration der Maschinen [5, 10].

Technische Komponenten, wie eine Netzwerkanbindung, sind nicht die einzigen Barrieren moderner Produktionsautomatisierung. Fehlerbehaftete Kommunikationsmechanismen, sowie die Gefahr der Veräußerung betriebsinterner Daten, sind Probleme, die heute gelöst werden können. Auch erfordern sinkende Losgrößen und steigende Produktvariabilität eine flexible Automatisierung von Echtzeitüberwachung und  verteilter, rekonfigurierbarer Fertigungssysteme (vgl. zu diesem Absatz [5, 11]).
Produktionseinrichtungen basierten bisher auf dem manuellen Sammeln und Verteilen von Daten für Überwachung, Steuerung und Wartung der Maschinen. Doch gegenüber hohen Kosten, menschlichen Fehlern, dem teilweise schlechten Zugang zur Anlage und Aspekten der Datensicherheit, sind Automatisierungslösungen heute günstig, sicher und attraktiv für die Fertigungsindustrie (vgl. zu diesem Absatz [8]).

1.2 Zielsetzung

Nach der Motivation und der damit einhergehenden Identifikation des Kernproblems werden nun die Ziele dieser Arbeit beschrieben. Den Schwierigkeiten in der industriellen Praxis wird wie folgt begegnet:

• Durch die entfernte Kontrolle einer Altmaschine werden manuelle Tätigkeiten wie das Übertragen eines Maschinenprogramms gemindert. Der operative Einsatz einer vormals nicht integrierten Anlage kann damit stärker automatisiert werden und beschleunigt den übergeordneten Produktionsablauf.
• Die zentrale Auswertung von Prozessdaten ermöglicht einen gesamtheitlichen Einblick in die Produktion, wobei jene Daten nicht notwendigerweise zentral zu persistieren sind. Diagnosen geschehen damit nicht mehr vor Ort, wodurch Wartungszyklen besser überprüft und eingehalten werden können. In der Konsequenz wird außerdem die Planung der Fertigung vereinfacht und die Zeit bis zur Produktion gesenkt. Weiterhin sollen Störfälle wie Werkzeugbruch und  ad hoc an Verantwortliche kommuniziert werden.

Im Kontext dieser Arbeit gilt eine Anlage als integriert, wenn die infrastrukturelle Einbettung in ein cyber-physisches Gesamtsystem den Anforderungen (vgl. Abschnitt 3) genügt. Neben den praktisch orientierten Vorgaben wird die Forschung zur Anlagenmodernisierung für die Industrie 4.0 durch weitere Ziele unterstützt:

• Eine dezentrale Informations- und Kommunikationsarchitektur verbessert die Produktionsstabilität und Skalierbarkeit von verteilten Fertigungssystemen.
• Kommunikationskanäle zwischen einzelnen Maschinen werden aufgrund durchgängig offener Schnittstellen nicht mehr unterbrochen. Durch damit einheitlich mögliche Machine-to-Machine (M2M) Kommunikation wird die Kontrolle und Überwachung hierarchisiert und dezentralisiert.
• Die Modellierung von Komponenten und Funktionalität einer Maschine wird durch Standardentwicklungswerkzeuge und -austauschformate vereinfacht.
• Das Optimierungspotential der Gesamtanlage kann durch statistische Auswertung der anfallenden Daten zu Maschinenoperation und -auslastung ausgeschöpft werden.

Die Hierarchisierung von Kontrolle und Überwachung bezieht sich auf das Beispiel der flexiblen Fertigungszelle in denen ein Verbund von Maschinen eine gemeinsame Aufgabe bearbeitet (vgl. [12]). Innerhalb eines solchen Verbunds wird zunehmend über Ethernet kommuniziert, wodurch eine Basis für die TCP/IP-Protokollfamilie zur Verfügung steht.

Aktuell sind nach einer Studie der Fachhochschule Südwestfalen 86 % der SPS-Systeme über Ethernet angebunden, wobei von den verbleibenden 14 % der Befragten 6 % angaben, Ethernet wahrscheinlich in Zukunft einzusetzen. [13]¹

Um nun die Ziele im Rahmen dieser Arbeit effektiv erreichen zu können, unterliegen Konzept und Implementierung verschiedenen Einschränkungen und Voraussetzungen.

Eine ethernetbasierte Netzwerkinfrastruktur erlaubt das Einbinden eines virtuellen Maschinenabbilds in die Fertigungsstrecke. Zugang zur Anlage, regelungstechnische Modifikationen und das Anbringen von Sensorik und Aktuatoren sind gegeben. Die zu modernisierende Werkzeugmaschine wird durch rechnergestützte numerische Steuerung (CNC) kontrolliert. Automatisierte Werkzeugkomponenten, wie Einspannvorrichtungen oder Schutztüren, sind an eine Speicherprogrammierbare Steuerung (SPS) gekoppelt. Einplatinencomputer sind ausreichend leistungsfähig für die Steuerung und Überwachung von CNC-Maschinen [14].

Auch ist das vorgestellte Konzept der Anlagenmodernisierung auf diskrete Fertigung mit bestehender Netzwerkinfrastruktur beschränkt. Unter Berücksichtigung der besprochenen Ziele und Einschränkungen wird eine konzeptuelle und prototypische Lösung durch die folgenden Schritte erreicht.

1. Ermitteln der Anforderungen für eine Integration von Altmaschinen in moderne, verteilte Produktionsumgebungen – im Folgenden als Retrofitting bezeichnet.
2. Recherchen zum heutigen Stand der Technik und die Einbeziehung vorhandener Systeme.
3. Konzeption einer virtuellen Repräsentation als Schnittstelle der zu integrierenden Anlage.
   • Einsatz von Einplatinencomputern als Integrationshardware
4. Ermöglichen von dezentraler Kontrolle und Überwachung im Hinblick auf cyber-physische Produktionssysteme.
   • Transfer und Ausführung von Maschinenprogrammen.
   • Erfassen von Produktionsdaten durch angeschlossene Sensoren.
   • adaptive Reaktion auf Zustandsänderung durch Rückkopplung.
5. Vorstellung eines skalierenden, erweiterbaren Frameworks für die softwaretechnologische Seite der virtuellen Repräsentation.
6. Eine prototypische Implementierung belegt die prinzipielle Durchführbarkeit.

Retrofitting ist nicht nur die Integration von Altmaschinen. Im Rahmen dieser Arbeit gilt die Definition von Bergweiler, nach der Retrofitting die Erweiterung des Equipments einer Anlage durch zusätzliche Hardware meint. Der funktionale Umfang einer Maschine wird durch neue Module für die Übertragung und verteilte Verarbeitung der Daten ausgebaut. Dadurch wird die Kommunikation zwischen individuellen Geräten und Produkten der Fertigung ermöglicht, bis die Fabrik den künftigen Standards, Direktiven und Prinzipien der Industrie 4.0 genügt [15]. In Verbindung mit den Zielen muss die zusätzliche Hardware, für die Erweiterung des Equipments, in Einplatinencomputern bestehen.

Nach Klärung der Ziele, Beschränkung des Konzepts und dem Aufzeigen eines groben Lösungswegs werden in dieser Arbeit folgende Fragen zu beantworten sein.

Welchen softwaretechnologischen Konzepten müssen die Modernisierung und der infrastrukturelle Kontext einer Altmaschine unterliegen, um eine ganzheitliche Integration in cyber-physische Produktionssysteme (CPPS) gewährleisten zu können?

1. Welche System- und Softwarearchitektur ist für ein flexibles Retrofitting zur Steuerung und Überwachung veralteter Fertigungsanlagen im Kontext von CPPS geeignet?
2. Wie und wo werden Informationen zu Maschinenzustand
   und -operation erfasst, verarbeitet, persistiert und Fremdsystemen zur Verfügung gestellt?
3. Welche standardisierten Protokolle und Datenstrukturen eignen sich für M2M-Kommunikation in einem CPPS?

1.3 Methode und Aufbau

Angelehnt an die Design Science Research Methodology wurden bisher grundlegende Probleme identifiziert und die Arbeit motiviert [16]. Durch die folgenden Grundlagen (Abschnitt 2) werden essentielle Technologien und Konzepte beschrieben. Die sich anschließenden Anforderungen (Abschnitt 3) spezifizieren Zielvorgaben für die Anlagenmodernisierung und -abstraktion in cyber-physischen Produktionssystemen. Ein Einblick in den aktuellen Stand der Forschung gibt Abschnitt 4. Das darauf aufbauende Lösungskonzept und Design des Frameworks sind in Abschnitt 5 erläutert. Eine prototypische Implementation des virtuellen Maschinenabbilds belegt die prinzipielle Durchführbarkeit des Vorhabens in Abschnitt 6. Die Evaluation in Abschnitt 7 hat die Bewertung von Konzept und Implementation zum Ziel. Weiterhin gibt sie einen Ausblick auf sich anschließende Forschungsfragen.

2 Grundlagen

Für diese Arbeit relevante Technologien und Konzepte werden in folgendem Kapitel erläutert. Grundlegende Eigenschaften von Fertigung und Automatisierung sind die Basis für das Verständnis von semantischen Informationsmodellen, respektive dem virtuellen Abbild der Realität. Durch dieses Modell ist ein System in der Lage die Produktion und deren Schritte zu überwachen, Differenzen zu erwartetem Verhalten festzustellen und autonom darauf zu reagieren.

2.1 Fertigung und Automatisierung

Fertigung, als Unterbegriff der Produktion, beschreibt Verfahren zur Umwandlung oder Erzeugung von Stoffen mit Hilfe von Energie und Informationen innerhalb eines Prozesses [17]. Automatisierung, nach der DIN 19233, ist das Ausrüsten einer Einrichtung, so dass sie ganz oder teilweise ohne Mitwirkung des Menschen bestimmungsgemäß arbeitet [18]. Eine Verknüpfung dieser beiden Konzepte ist in Abbildung 1 dargestellt. Die Rückkopplung von Prozessdaten in eine Automatisierungseinrichtung befähigt das System, unter Berücksichtigung von Zielen, steuernd auf die Fertigung zu wirken. Direkte Eingriffe in den Prozess, sowie dessen Beobachtung durch den Menschen, werden verringert – im ökonomischen Zusammenhang rationalisiert (vgl. zu diesem Absatz [17]).

Figure 1: Automatisierte Fertigung aus [17]

Um die verschiedenen Bereiche der klassischen² Automatisierung darzustellen, wird eine Schichtenorganisation herangezogen. Die Struktur eines Unternehmens entspricht damit einer Automatisierungspyramide. Unterschieden werden diese Ebenen aufgrund der unterschiedlichen Anforderungen an Datendurchsatz und Übertragungsgeschwindigkeit (vgl. zu diesem Absatz [17]). Wird eine neue Komponente in diese Pyramide integriert, geschieht dies entweder horizontal oder vertikal. Ersteres bedeutet die Verbindung der Komponente mit Geräten gleicher Ebene. Ist sie vertikal integriert, verbindet sie Komponenten unterschiedlicher Ebenen. Die Ebenen des Beispiels der Abbildung 2 erläuterte Linke wie folgt:

• Unternehmensleitebene
  Unter Zuhilfenahme eines Systems für Enterprise Resource Planning (ERP) befinden sich marktrelevante Unternehmensprozesse, wie Unternehmensführung, Personal-, Investitions- und Produktionsplanung auf dieser Ebene.
• Betriebsleitebene
  Prozesse wie Auftragsbearbeitung und Produktionsplanung, Terminüberwachung und Kostenanalyse sichern auf dieser Ebene den täglichen Fertigungsbetrieb eines Unternehmens. Die softwareseitige Unterstützung übernimmt beispielsweise ein Manufacturing Execution System (MES).
• Prozessleitebene
  Je nach Größe der Anlage wird in detaillierteren Ebenen die Steuerung und Regelung von Produktionsprozessen und deren Überwachung vollzogen. Verbindungen, wie die zwischen einzelnen Fertigungszellen, werden auf dieser Ebene abgebildet.
• Steuerungs- & Feldebene
  Aktuatoren und Sensoren und deren Schnittstelle zu Ein- und Ausgangssignalen befinden sich auf der Feldebene. Die von diesen Komponenten konsumierten, beziehungsweise erfassten Daten, werden auf der Steuerungsebene mit dem Prozess verbunden. Daraus entstehende Information werden in die Reaktion des Systems einbezogen, weshalb minimale Latenzen in der Übertragung notwendig sind.

Figure 2: Beispiel einer klassischen Automatisierungspyramide³

Auf der Prozessebene (Level 0) des Beispiels geschieht die physikalische Fertigung des Produkts. Dabei fallen große Mengen von Rohdaten an, die in jeder folgenden, höheren Schicht zu abstrakteren Informationen verarbeitet werden. Die Toleranz bezüglich der Übertragungsgeschwindigkeit ist auf diesen unteren Ebenen am geringsten. Speicherprogrammierbare Steuerungen (SPS, vgl. Abschnitt 2.1.3) und numerische Kontrolle (NC, vgl. Abschnitt 2.1.2) erhalten Befehle in Echtzeit und automatisieren den Produktionsablauf. Über einen Feldbus (vgl. Abschnitt 2.1.1) werden diese Instruktionen und Messdaten an ein Supervisory Control and Data Acquisition (SCADA) System gekoppelt. Derlei Systeme sind verantwortlich für die Überwachung und Steuerung technischer Prozesse und kontrollieren die übergeordnete Fertigungszelle, beziehungsweise Verbünde von Werkzeugmaschinen, Robotern und automatisierten Komponenten [17]. Ein MES, beziehungsweise Fertigungsmanagementsystem bildet dann die Schnittstelle zum Ressourcenmanagementsystem (ERP) der Unternehmensleitebene.

2.1.1 Kommunikationssysteme

In der industriellen Fertigung werden Feldbusse als Kommunikationskanal in Feld- und Steuerungsebene genutzt. Neben dem Feldbus existieren weitere, teils veraltete Kommunikationskanäle, die zu der in Abbildung 3 dargestellten, heterogenen Automationsstruktur führen.

Figure 3: Repräsentative Automationsstruktur nach [19]

Hammertringl und Reinhart fanden vier Klassen von Kommunikationssystemen in dieser durch eine Befragung ermittelten Struktur. Sensoren und Aktuatoren der ersten Klasse sind direkt verbunden und übermitteln binäre oder analoge Informationen rein physikalischer Natur, wie Strom mit 24V oder Druckluft. Sie stellen keine standardisierte, digitale Beschreibung ihrer Funktion bereit, wodurch dem angeschlossenen Gerät diese händisch mitgeteilt werden muss.
Feldgeräte mit IO-Link⁴-Fähigkeit können durch die IO Device Description beschrieben werden und sind Teil einer zweiten Klasse mit Direktverbindung. Innerhalb dieser können minimale Protokolle beschrieben und die Identifikation der Komponenten durchgeführt werden. Dadurch kann innerhalb dieser Klasse extern parametriert und eine maschinenlesbare Beschreibung übertragen werden. Letzteres wird in der Praxis jedoch kaum genutzt. Ein weiterer, stark verbreiteter Repräsentant ist die serielle Schnittstelle RS-232.
Die dritte Klasse von Kommunikationssystemen verbindet Bus-basierte Geräte. Traditionelle Bussysteme und Real-Time Ethernet (RTE) sind Stand der Technik und erlauben die Definition der Strukturen durch einen Bus-Master. RTE ist hierbei ein Überbegriff verschiedener Netzwerkstandards wie Profinet IO, EtherNet/IP und EtherCAT [20]. Bildverarbeitungssysteme, ihre Protokolle (z.B. GigE Vision⁵) und Beschreibungssprachen (z.B. GenICam⁶) sind hier verbreitet. Für Konfiguration und Überwachung der Systeme wird eine Mensch-Maschine-Schnittstelle (MMS) eingesetzt (vgl. zu diesem Absatz [19]).
Feldbusse sind digitale bidirektionale, serielle Kommunikationsnetzwerke für echtzeitfähige, verteilte Kontrolle von Instrumenten, Steuerungseinheiten und Aktuatoren [21]. Trotz der Standardisierungsbemühungen durch IEC 61158, existieren unterschiedliche Feldbusse wie CAN, ProfiBUS oder EtherCAT. Jeder Hersteller von Maschinen, Robotern und automatisierten Komponenten stellt einen anderen Busstandard, weshalb die Kommunikation der Geräte nicht garantiert werden kann. Für deren Verbindung mit unterschiedlichen Systemen wird ein Adapter benötigt, wodurch der Aufwand bezüglich Bereitstellung und Konfiguration steigt (vgl. zu diesem Absatz [22]).

Auf den höheren Ebenen der Automatisierungspyramide (vgl. Abbildung 2) etablierte sich das nicht echtzeitfähige Ethernet. Die Variante des RTE verbreitet sich jedoch zunehmend auch auf den unteren Ebenen (vgl. Abschnitt 1.2) und erlaubt Kommunikation mit Remote Procedure Calls (RPC), TCP/IP-Sockets und OPC (ursprünglich OLE⁷ for Process Control, vgl. Abschnitt 2.2) [22]. Die Homogenisierung der Infrastruktur, vom Ressourcenmanagement im ERP über die Speicherprogrammierbare Steuerung bis zum einzelnen Sensor auf der Feldebene, vereinfacht den Informationsaustausch und trägt zur Flexibilisierung des Gesamtsystems bei. Weiterhin stehen damit die Daten aller Schichten für jeden anderen Netzwerkteilnehmer zur Verfügung.
Diese Form der Kommunikations- und Informationsstruktur ist nach Hammerstingl und Reinhart in einer vierten Klasse zu finden. Abbildung 3 zeigt OPC und OPC UA (vgl. Abschnitt 2.2) als Standard für den Datenaustauch zwischen dem Produktionsplanungssystem (PPS) und den speicherprogrammierbaren Steuerungen (SPS, vgl. Abschnitt 2.1.3). Mit dieser Technologie stellen Geräte aktiv ihre virtuelle Beschreibung bereit, was durch die Hersteller unterstützt und vorangetrieben wird (vgl. zu diesem Absatz [19]). Auch mit numerischer Steuerung (CNC, vgl. Abschnitt 2.1.2) kontrollierte Werkzeugmaschinen können so Informationen zu Zustand und Produktionsfortschritt bereitstellen.

2.1.2 Numerische Kontrolle

Für die Fertigung eines Produkts werden Bauteile benötigt, die durch Werkzeugmaschinen entstehen. In der DIN 69651 ist eine Werkzeugmaschine definiert als eine mechanisierte und mehr oder weniger automatisierte Fertigungseinrichtung, die durch relative Bewegung zwischen Werkstück und Werkzeug eine vorgegebene Form am Werkstück oder eine Veränderung einer vorgegebenen Form an einem Werkstück erzeugt (Zitat aus [23]). Ein Werkstück ist dabei ein Rohling eines bestimmten Materials, welcher auf eine bestimmte Art durch Bearbeitung verändert wird. Die aus diesem entstehende Form wird mit Software für Computer-Aided Design (CAD) entworfen, wobei eine zwei- oder dreidimensionale Visualisierung des Modells den Konstrukteur unterstützt. In einem zweiten Schritt werden die so entstandenen Konstruktionspläne in Bewegungsmuster umgewandelt. Der etablierte Kodierungsstandard für die Steuerungsinformationen zu diesen Mustern ist durch die DIN 66025, beziehungsweise ISO 6983 normiert und als G-Code bekannt. Eine vollständige Kompatibilität der Befehle zwischen den Anlagen wird aufgrund spezifischer Werkzeug- und Maschinenparameter, wie Drehzahlen oder Begrenzungskoordinaten der Arbeitsfläche, verhindert. Durch Präprozessoren und manuelle Anpassungen werden Steuerungsinformationen des zweiten Schritts auf die Maschine angepasst.
Wurde der vorverarbeitete G-Code auf eine Werkzeugmaschine mit Computer Numerical Control (CNC) übertragen, kann diese mit dem eigentlichen Fertigungsschritt beginnen. Derlei Maschinen besitzen mehrere durch Schrittmotoren und Servos angetriebene Bearbeitungsachsen, welche die Position des Werkzeugs relativ zum Werkstück durch Translation und Rotation (Hilfsachsen) verändern. Mit dieser relativen Bewegung wird sukzessiv Material entfernt, wodurch die im CAD entworfenen Bauteile physisch entstehen. Für das Entfernen von Material werden verschiedene Typen von Werkzeugmaschinen eingesetzt. Drehmaschinen und Fräsen sind hier die prominentesten Repräsentanten, wobei zum Beispiel auch spezielle Roboter mit Befehlen der CNC gesteuert werden können (vgl. zu diesem Absatz [23]).

Figure 4: Beispielkonstruktion und G-Code für eine Drehbank

G-Code teilt sich in zwei Gruppen von Instruktionen, die wiederum herstellerspezifisch beziehungsweise generisch sind. Abbildung 4 zeigt das Beispiel einer Konstruktion und dessen Programm mit Bewegungsinstruktionen (G-Befehle) und sonstige Anweisungen (M-Befehle) für die Herstellung auf einer Drehbank⁸. Das Einspannen des Rohlings durch M12 schließt die Klammern - in der Konstruktion als schraffierte Blöcke dargestellt. Ein Eilgang, wie durch G0 X100 Z50, richtet das Werkzeug ohne das Entfernen von Material an einem bestimmten Punkt aus, wobei sich A im Beipiel an Position (X = 100, Z = 50) befindet. Der Befehl G1 wird für den eigentlichen Fräsvorgang verwendet und lässt das Werkzeug mit einer Geschwindigkeit (Vorschub) von 600 mm/min durch das Material laufen.

Vielen CNC-Anlagen fehlt der Speicher für Programme mit mehreren tausend Bewegungsinstruktionen. Derlei Befehlslisten müssen während der Bearbeitung durch ein Fremdsystem an die Maschine sukzessiv übertragen werden. Das Konzept der Direct Numerical Control (DNC) steht für diese Verbindung via RS-232 oder Parallel Port. Fremdsysteme sind PCs oder dedizierte DNC-Transfergeräte, die den Code von Speichermedien wie USB-Sticks und SD-Karten beziehen. DNC, verstanden als Distributed Numerical Control, ermöglicht weiterhin die Verteilung von Programmen auf einen Maschinenverbund [23].

Die Vorteile der Fertigung mit CNC liegen in der Wiederholbarkeit und Genauigkeit der Operation. Weiterhin wird die Rüstzeit, jene zum Einstellen der Maschine, verringert und damit die Produktivität erhöht (vgl. zu diesem Absatz [24]).
Dennoch sind auch moderne CNC-Anlagen in ihrer Funktion limitiert, da der verwendete G-Code lediglich Instruktionen und prozedurale Daten abbilden kann, wodurch ein Großteil der Konstruktionsinformationen verloren geht. Zwei neue Standards, namentlich STEP-NC (ISO 10303-238) und Function Blocks etablieren sich aus diesem Grund. Durch diese sollen CNC-Maschinen mit mehr Informationen, für intelligentere Fertigung und bessere Interoperabilität, ausgestattet werden. Beispielsweise wird durch STEP-NC die Abhängigkeit von Parametern reduziert. Neuberechnungen zur Laufzeit beziehen unter anderem Verformungen durch Erhitzen des Werkstücks in die Fahrtenplanung ein. Function Blocks dagegen, sind Teil eines Standards für verteilte industrielle Prozesse und Kontrollsysteme. Sie kapseln Maschinendaten, wie Werkzeugeigenschaften oder Algorithmen, für CNC (vgl. zu diesem Absatz [25]).
Darüber hinaus besitzen Anlagen spezifische, automatisierte Maschinen- und Werkzeugkomponenten, die nur indirekt durch CNC steuerbar sind. Schließmechanismen, Abluftsysteme oder Materialzufuhr werden von maschinenspezifischen, internen speicherprogrammierbaren Steuerungen in die Fertigung integriert [23].

2.1.3 Speicherprogrammierbare Steuerung

Daten und Zustände automatisierter Maschinen- Werkzeug- und Fertigungsprozesskomponenten werden durch speicherprogrammierbare Steuerungen (SPS) aufgenommen, verarbeitet und verändert. Durch die sind sie definiert als eine rechnergestützte programmierte Steuerung, deren logischer Ablauf über eine Programmiereinrichtung, zum Beispiel ein Bedienfeld, einen Hilfsrechner oder ein tragbares Terminal, veränderbar ist (Zitat aus [26]). Nach Heinrich et al. sind folgende Komponenten dafür notwendig. Ein Hardwaresystem stellte die Verbindung zum Fertigungsprozess und weiteren automatisierten Anlagen her. Programm- und Datenspeicher sind für die Persistenz des Anwenderprogramms, beziehungsweise der Prozessdaten verantwortlich und werden durch die Verarbeitung verändert. Dafür sind ein Betriebssystem sowie ein Anwenderprogramm zuständig.

Der prinzipielle Aufbau einer SPS umfasst Stromversorgungs-, Signalverarbeitungs- und vier Schnittstellenfunktionen für den Datenaustausch. Eine Mensch-Maschine-Schnittstelle ermöglicht dem Bediener den operativen Betrieb, z.B. durch Statusanzeigen, zu überwachen. Die Programmier- und Test-Schnittstelle wird durch einen Programmierer, neben der Implementierung von Instruktionen, auch zur Fehleranalyse genutzt. Kommunikationsfunktionen erlauben die Anbindung an externe Systeme, automatisierte Komponenten und Datenquellen. Aktuatoren und Sensoren werden über die Prozessschnittstelle an eine SPS gekoppelt. Der konzeptuelle Aufbau wird durch ein, in Abbildung 5 dargestelltes, Hardwaresystem implementiert. Die Stromversorgungseinheit liefert die für den Betrieb notwendige Energie und kann an die jeweilige Quelle angepasst werden. Eine Zentraleinheit mit CPU, Speicher, Verarbeitungseinheit und Anschlüssen für Programmiergeräte und Netzwerk bildet die Steuerungslogik ab. Die Kopplung an digitale und analoge Datenquellen und -empfänger erfolgt über Ein-/Ausgabe-, beziehungsweise Signaleinheiten.

Figure 5: Grundlegender Hardwareaufbau einer SPS nach [26]

Signalverarbeitungsfunktionen im Anwenderprogramm werden innerhalb der Verarbeitungseinheit zyklisch ausgeführt. In einem ersten Schritt werden dafür die aktuellen Zustände der Eingänge erfasst, z.B. Sensordaten, und der Datenspeicher gelesen. Das Anwenderprogramm wird nach dem EVA-Prinzip (Eingabe, Verarbeitung, Ausgabe) abgearbeitet, woraufhin Ausgangssignale, z.B. Befehle für Aktuatoren, erzeugt werden. Diese Zyklen verbrauchen Zeit, die kritische Aktionen verhindern können.
So existieren neben den zyklusorientierten auch unterbrechungsfähige SPS. Das aktuell laufende Programm kann dabei durch Interrupts pausiert und später wieder aufgenommen werden. Programmiert werden Anwenderprogramme mit normierten Methoden der EN 61131-3. In textueller Form existieren Standards für Anweisungslisten und strukturierten Text. Grafisch wird die Logik einer SPS durch Kontaktpläne, eine Funktionsbaustein- oder Ablaufsprache implementiert.
Eine weitere Kategorie bilden ereignisorientierte Steuerungen, bei denen das Anwenderprogramm erst bei Statusveränderungen der Eingangssignale abgearbeitet wird. Weiterhin unterschieden werden modulare SPS, wie die Simatic S7-Serie von Siemens, und kompakt-SPS, wie zum Beispiel LOGO!. Letztere zeichnen sich durch fehlende Erweiterbarkeit aus. Neben hardwarebasierten SPS ermöglichen Software-Steuerungen (Soft-SPS) eine weitere Stufe der Flexibilisierung. Steuerungen mit Echtzeit-Betriebssystemen, auch in eingebetteten Recheneinheiten, übernehmen hier die Überwachung und Kontrolle des Prozesses, sind jedoch weniger verbreitet.
Eine Alternative zu SPS bietet die verbindungsprogrammierte Steuerung (VPS), bei der die Komponenten der Ein- und Ausgabe festverdrahtet und die Logik vordefiniert ist. Die speicherprogrammierbare Variante hat nicht nur den Vorteil der Flexibilität. Der Funktionsumfang, die Verarbeitung analoger und digitaler Daten sowie die geringen Betriebskosten etablierten die SPS als Standard in der industriellen Fertigungsautomatisierung (vgl. zu diesem Absatz [26]).

Die EN 61131-3 ist nicht die einzige Möglichkeit der Programmierung einer SPS. Zugunsten vertikaler und horizontaler Integration hat die PLCopen⁹, eine Vereinigung von Steuerungsherstellern, und die OPC-Foundation Funktionsbausteine in einer Spezifikation für OPC UA abgebildet. Damit kann die SPS eine aktive Rolle innerhalb der Automatisierungspyramide einnehmen und sich beispielsweise Produktionsaufträge eigenständig abholen (vgl. zu diesem Absatz [27, 28]).

2.2 OPC Unified Architecture

Der Austausch und die Modellierung von Daten kann in einem heterogenen Technologieraum nur durch standardisierte Beschreibungssprachen, Kommunikationsprotokolle und Modelle erreicht werden. Diese Aussage wird im Zusammenhang mit Industrie 4.0 durch eine Tendenzbefragung von BITKOM, VDMA und ZVEI aus dem Jahr 2013 gestützt. So sehen Mitarbeiter aus 278 Unternehmen des Maschinen- und Anlagenbaus Standardisierung als größte Herausforderung für die Umsetzung von Industrie 4.0 [29].
Die OPC¹⁰ Foundation ist ein Industriekonsortium, das für Entwicklung und Wartung solcher Standards verantwortlich ist. Sie schuf Interoperabilitätsstandards für den sicheren und zuverlässigen Austausch von Daten im Automatisierungsraum industriell produzierender Unternehmen auf Basis des Distributed Component Object Model (DCOM). Dieses ist ein von Microsoft definiertes System für entfernte Methodenaufrufe (Remote Procedure Calls, RPC) innerhalb eines Windows-Ökosystems, das für die heutigen heterogenen Informationssysteme ungeeignet ist. Neben der Plattformunabhängigkeit ist die Zusicherung des nahtlosen Übergangs von Informationen, zwischen Geräten unterschiedlicher Hersteller, die Hauptaufgabe querschnittlicher Spezifikationen im Kontext der OPC Unified Architecture (OPC UA)¹¹. Das Konsortium berücksichtigte bei der Spezifikation folgende  [27]:

• sicherer, zuverlässiger Informationsaustausch
• Plattform- und Herstellerunabhängigkeit
• standardisierte Kommunikation über Internet und Firewalls
• serviceorientierte Architektur (SOA)
• Schutz vor unerlaubtem Zugriff
• Erreichbarkeit und Zuverlässigkeit
• Vereinfachung durch Vereinheitlichung

Konkret bietet die OPC UA (auch IEC 62541) einen semantischen Kommunikations- und Datenmodellierungsstandard für den Informationsaustausch [30]. Ein erweiterbares Meta-Modell definiert die Grundbausteine und Regeln für ein Informationsmodell und beinhaltet verschiedene Einstiegsknoten und Basis-Typen [27]. Informationsmodelle sind Repräsentationen von Konzepten, Relationen, Beschränkungen, Regeln und Operationen zur Spezifikation der Bedeutung (Semantik) von Daten innerhalb einer bestimmten Domäne [31]. Diese werden von Maschinen, Baugruppen und anderen Ressourcen im Adressraum angeboten, wodurch jede Entität innerhalb eines IT-Ökosystems mit der jeweilig anderen kommunizieren kann und deren strukturelle Eigenschaften kennt.

2.2.1 Informationsarchitektur

Figure 6: Spezifikationen von OPC UA

In Abbildung 6 ist die dafür notwendige Informationsstruktur dargestellt [27]. Auf der untersten Ebene werden Transportprotokolle, das Meta-Modell und grundlegende Services beschrieben. Das bevorzugte Protokoll setzt auf TCP/IP auf und erlaubt einen performanten Austausch von beispielsweise Geräte-, Sensor-, Maschinen- und Prozessdaten innerhalb einer Client-/Server-Architektur. Eine für die Kommunikation über Firewalls taugliche Methode bietet die im Standard verankerte HTTP/XML-Schnittstelle. Durch einen Discovery-Mechanismus können Funktionen und Eigenschaften von OPC-UA-fähigen Teilnehmern in einem Subnetz bekannt gegeben werden. Doch auch Dienste für Ereignisregistrierung oder Sitzungsmanagement sind Teil der elementaren Definitionen. Eckpfeiler dieser Basis von OPC UA sind Fehlertoleranz und Sicherheit als zentrale Aspekte der Spezifikation. Darauf aufbauend werden generische Informationsmodelle definiert, die unter anderem den Adressraum eines Servers repräsentieren und durch die OPC Foundation wie folgt beschrieben sind [27]:

• Data Access (DA)
  Daten zur Automatisierung werden durch das Data Access Modell strukturiert. Sowohl analoge und diskrete Variablen, als auch Einheiten und Qualitätsattribute werden hier beschrieben. Sensoren, Steuerungen und Regler sind beispielsweise Quellen jener Variablen.
• Alarms and Conditions (AC)
  Die Behandlung von Dialogen und Alarmen wird mit diesem Modell definiert. Events, beziehungsweise Ereignisse auf die sich Clients registrieren, werden durch Veränderungen im Zustand eines Geräts ausgelöst.
• Historical Access (HA)
  Historische Variablenwerte und Events werden mit diesem Modell dargestellt. Die Persistenz dieser Daten ist konfigurierbar.
• Programs
  Komplexe Aufgaben werden durch Programme repräsentiert und mit Zustandsautomaten beschrieben.

2.2.2 Transportprotokolle

Protokoll-Bindings erlauben den Transport der Daten zwischen einem OPC UA Client und Server durch unterschiedliche Mechanismen. Diese können parallel verwendet werden und arbeiten transparent, auch ohne Zutun des Entwicklers. Die Bereitstellung der drei Varianten kann ohne Anpassungen der Software verändert werden. Abbildung 7 stellt die Kommunikationsvarianten gegenüber und zeigt deren orthogonale Eingliederung.

Figure 7: OPC UA Transportvarianten

2.2.2.0.1 Binärprotokoll (UA-Binary).

Dieses vorgeschriebene Protokoll bietet die beste Performance und den geringsten Overhead. Da weder XML-Inhalte umgewandelt, noch SOAP¹² oder HTTP verwendet werden, ist es aufgrund des geringen Ressourcenverbrauchs für eingebettete Geräte geeignet. Außerdem bietet es die beste Interoperabilität, weil Binärdaten im Gegensatz zu XML-Dokumenten weniger Freiheitsgrade besitzen.

2.2.2.0.2 Webservice (XML-SOAP).

Eine optionale Web-Service-Schnittstelle kann durch den OPC UA Server bereitgestellt werden. Der Overhead ist größer, da der Nachrichtenaustausch mit XML das Protokoll verlangsamt. Somit herrscht wenig bis keine Akzeptanz beim Einsatz mit kleinen und Kleinstgeräten. Dem gegenüber erfährt SOAP umfassende Werkzeugunterstützung und kann leicht durch .NET oder Java-Anwendungen verwendet werden. Weiterhin ist es durch die Verwendung von HTTP/HTTPS Firewall-freundlich.

2.2.2.0.3 Hybrid (UA-Binary über HTTPS).

Das Hybridprotokoll verbindet binären und SOAP-basierten Nachrichtenaustausch. Der Overhead ordnet sich zwischen den Verwendeten Kommunikationsmechanismen ein, wobei die die Vorteile beider vereinigt werden. Die binär kodierte Nachricht wird hierbei in den HTTPS-Frames versendet und ermöglicht eine Firewall-freundliche Kommunikation.

Dieser Abschnitt wurde der Website von ascolab¹³ entnommen.

2.2.3 Modularität und Erweiterbarkeit

Viele bereits existierende Standards, wie MTConnect, PLCopen, FDI und ISA95, unterscheiden sich von OPC UA durch fehlende Erweiterbarkeit. Semantische Zusammenhänge lassen sich oft nicht ohne weiteres darstellen. So beschrieb Hoppe folgende Fragen [10]:

• Wie geben sich z. B. ein Temperatursensor oder eine Ventilsteuerung zu erkennen?
• Welche Objekte, Methoden, Variablen und Ereignisse definieren die Schnittstelle für Konfiguration, Initialisierung, Diagnose und Laufzeit?

Die Erweiterbarkeit des Informationsmodells von OPC UA (vgl. Abbildung 6) ermöglicht Companion Specifications, die diesen Mangel ausgleichen und zusätzlich domänenspezifische Definitionen erlauben. Plattformunabhängigkeit wird durch frei verfügbare, aber auch proprietäre Implementierungen des Softwareinfrastruktur-Stacks ermöglicht. Ein API, Codegeneratoren für den Adressraum und Entwicklungswerkzeuge werden für die Programmiersprachen Ansi C/C++, .NET, Java und weitere durch die OPC Foundation bereitgestellt.

2.3 Cyber-physische Produktionssysteme

Die Verbindung von Überwachung und Kontrolle technischer Systeme mündet in Paradigmen, die Realität und virtuelle Umgebungen miteinander verschmelzen lassen. So wurde das Konzept cyber-physischer Systeme (CPS) 2006 durch Edward A. Lee erstmalig erläutert. Er versteht diese als Integration von Informationsverarbeitung und physischen Prozessen. Virtuelle und physische Abläufe werden durch Sensoren und Aktuatoren überwacht, beziehungsweise beeinflusst, stehen in unmittelbarer Wechselwirkung und sind durch Kontrollschleifen rückgekoppelt [32]. Der historische Weg, hin zu darauf aufsetzenden Systemen, ist in Abbildung 8 dargestellt¹⁴.

Figure 8: Der historische Weg zu CPSoS

Im konventionellen Computing (Abbildung 8a) sind Systeme der physischen Welt durch abstrakte Modelle repräsentiert. Berechnungen bezüglich der Realität werden in Simulationen auf diesen Modellen durchgeführt. Durch eingebettete Systeme (ES, Abbildung 8b) wird der Computer in das Realweltobjekt integriert, wodurch Berechnungen in die physikalischen Systeme getragen werden. Mit CPS (Abbildung 8c) existiert nicht nur ein passives Modell des Realweltsystems. Das Wissen um den Zustand des Realitätsausschnitts verhilft zur Steuerung der ES, wodurch neben dem realen Objekt ein synchrones, virtuelles Modellobjekt entsteht. Diese Konzept dualer Realität von Objekten steht für die Kontrolle von Elementen der physischen Welt. Um die Synchronität des Modells gewährleisten zu können, müssen Rückkopplungsschleifen die Effekte physischer Prozesse auf Berechnungen und Simulationen beziehungsweise vice versa verifizieren [32]. Weiterhin sollen derlei Systeme autonom auf Diskrepanzen reagieren und korrigierende Maßnahmen einleiten.
MAPE-K ist ein geeignetes Konzept cyber-physischer Rückkopplung und besteht aus den Phasen Monitor, Analyze, Plan und Execute. Eine übergeordnete Wissensbasis (Knowledge-Base) beinhaltet das physische Modell sowie Regeln und Ziele des verwalteten Elements, respektive der Fertigungsanlage. In Abbildung 9 sind die Phasen und ihre Beziehungen zueinander dargestellt.

Figure 9: MAPE-K Kontrollschleife nach [33]

Die Sensordaten werden vom Monitoring erfasst und im Kontextmodell der Wissensbasis abgelegt. Symptome, beziehungsweise Ereignisse die eine Analyse des Modells anstoßen, werden ermittelt. In der folgenden Analyse werden die Ziele der Rückkopplung im physischen Kontext überprüft. Ist ein Eingreifen in die Realität erforderlich um die Ziele zu erfüllen, wird ein Veränderungsanfrage (Change-Request) an die Planungskomponente von MAPE-K übergeben. Diese Phase mündet in einem Veränderungsplan (Change-Plan) der sich an Regeln und Zielen orientiert und mittels Execute über Aktuatoren ausgeführt wird (vgl. zu diesem Absatz [33]).
In CPS werden außerdem semantische Kontrollregeln benötigt um die Rückkopplung mit MAPE-K zu ermöglichen. Die Regeln werden in der Kombination von Ereignis, Bedingung und Aktion festgehalten, besser bekannt als Event-Condition-Action (ECA, vgl. zu diesem Absatz [34]). In der Monitor-Phase von MAPE-K werden die Ereignisse gesammelt. Die Analyse wertet die Bedingungen aus, woraufhin die Planung eine Aktion ermittelt, die von der Execute-Phase durchgeführt wird. So kann ein Ereignis beispielsweise die Veränderung eines Sensorwertes sein. In der Analyse ergibt sich das Überschreiten eines Schwellwertes. Die Planung sucht eine Aktion den Wert zu senken und überlässt die Ausführung der Execute-Phase. Das Konzept ist etabliert und bewerkstelligt die Rückkopplung in adaptiven, cyber-physischen Systemen [35–37].
In Systemen von CPS (CPSoS, Abbildung 8d) wird die physische Welt in Realweltsysteme gegliedert, die über ihre Modelle interagieren. CPSoS bieten Potential für die vierte industrielle Revolution und sind Grundlage cyber-physischer Produktionssysteme (CPPS). Produkte, Maschinen und andere Ressourcen werden in diesen durch CPS repräsentiert, welche Informationen und Dienste über das Netzwerk der gesamten Produktionsstrecke teilen. CPS sind fundamentale Elemente eines CPPS, die unmittelbaren Zugriff auf relevante Informationen, Maschinenparameter, Produktionsprozesse und deren Produkte besitzen. Durch die Dezentralisierung der Produktionslogik haben CPPS, im Gegensatz zu traditionellen Produktionssystemen, wesentliche Vorteile bezüglich Transparenz, Adaptivität, Ressourceneffizienz und Flexibilität. Auf Ebene der Automatisierung werden Informationen eines CPS-Netzwerk benötigt, um den Fertigungsprozess auf Basis von strategischen Entscheidungen erfolgreich durchzuführen. Für Entscheidungsfindung und Kontrolle der Fertigung werden konsistente, kohärente Informationen über die reale Welt  [15].

Figure 10: Auflösung der Automatisierungspyramide aus [38]

Diese Informationen, Dienste und Funktionen werden an jener Stelle lokalisiert, die im Sinne einer flexiblen Entwicklung und Produktion den größten Vorteil  [38]. Starre Strukturen, wie die der klassischen Automatisierungspyramide, sind ungeeignet für die dezentrale Verortung der genannten Ressourcen. Die demnach notwendige Auflösung dieser Architektur zu einem vernetzten System von Systemen, beziehungsweise CPSoS, wie in Abbildung 10 verdeutlicht. Sowohl Hard- und Software als auch die Verarbeitung der anfallenden Daten wird nicht länger in Schichten organisiert werden [39]. Damit sollen die Produktionsressourcen auf Knoten eines Netzwerks aufgeteilt und schrittweise auf ihre funktionale Struktur abstrahiert werden [38]. Bis eine geeignete Architektur für CPPS andere Möglichkeiten bietet (vgl. [40, 41]), werden Echtzeit-Steuerungen in der Feldebene verbleiben [38].

3 Anforderungen

Für die in Abschnitt 1.2 aufgestellten Ziele werden in diesem Kapitel die spezifischen Kriterien zu deren Erfüllung erläutert.

Informationssysteme in der Produktion dienen der Verbesserung der Wettbewerbsfähigkeit und müssen Innovations- und Zeitdruck standhalten. Moderne Produktionsumgebungen helfen Arbeitsabläufe zu optimieren und vereinfachen Beteiligten die Ausführung ihrer Arbeit. Jedoch verhindern Altmaschinen aufgrund fehlender Infrastrukturanbindung und geschlossener Architekturen (vgl. [8]) die Vollautomatisierung dieser Arbeitsabläufe und erfordern die physische Anwesenheit einer Fachkraft [5].

3.1 Überwachung

Im Wartungs- und Störfall muss der Zustand der Anlage bekannt sein. Dieser kann bei nicht integrierten Altmaschinen nur an deren Terminal eingesehen werden. Ein Techniker muss die Betriebs- und Prozessdaten vor Ort erfassen um eine Diagnose stellen zu können und unter anderem das ERP-System darüber zu informieren. Im Sinne der Industrie 4.0 wird diese Form ortsgebundener Arbeitsplätze an Bedeutung verlieren und einer dezentralen Nutzungsschnittstelle weichen [42]. Damit müssen die Daten über geeignete Schnittstellen zur Verfügung stehen. Subsysteme können dann auch automatisiert über Zustandsänderungen der Maschine in Kenntnis gesetzt werden. Weiterhin braucht ein CPPS diese Informationen um adäquat reagieren zu können (vgl. Abschnitt 2.3, [32]). Abgesehen von der notwendigen Dezentralisierung und dem Informationsgewinn für Rückkopplungsschleifen gilt es einen Werkzeugbruch zugunsten von Maschinenverfügbarkeit und Produktqualität, respektive der Ökonomie des gesamten Produktionssystems, zu  [43].

R1

Die Überwachung von Betriebs- und Prozessdaten der Altmaschine und ihrer automatisierten Maschinen- und Werkzeugkomponenten ist ortsunabhängig, so dass Zustandserfassung und Störfalldiagnose durch Subsysteme des CPPS erfolgen kann.

3.2 Steuerung

Um einen bestimmten Fertigungsschritt an einer numerisch kontrollierten (NC) Anlage durchzuführen, muss das auszuführende Programm nach DIN 66025 übertragen werden [23]. Auch Speicherprogrammierbare Steuerungen (SPS) benötigen ein Anwenderprogramm nach EN 61131-3 oder der PLCopen-Spezifikation [26, 27]. Diese Befehlsketten werden entweder mit einem Speichermedium auf den Steuerungs-PC kopiert oder direkt an dessen Terminal kodiert. Der zeitliche Aufwand und das notwendige Personal verlangsamen die Fertigung des Endprodukts und führen zu einer suboptimalen Fertigungsstrecke [30]. Für das Retrofitting der Anlage muss die entfernte numerische Kontrolle ermöglicht werden. Weiterhin sind Produktionsmaschinen mit zusätzlichen automatisierten Komponenten wie Schließmechanismen für Schutztüren, Kühl-, Entlüftungs- oder Einspannsystemen ausgestattet. Auch die Steuerung dieser muss ortsunabhängig sein, damit ein CPPS ganzheitlich in den Produktionsprozess eingreifen  [42].

R2

Die Steuerung der Altmaschine und ihrer automatisierten Maschinen- und Werkzeugkomponenten ist ortsunabhängig, so dass Übertragung, Ausführung und Abbruch von NC-Programmen, beziehungsweise produktionsbedingter Steuerbefehle, durch Subsysteme des CPPS erfolgen kann.

Die steigende Automatisierung zur Optimierung der Produktionsabläufe wird in einem CPPS durch Rückkopplung erreicht. Mit den Einhalten der Anforderungen zu Überwachung und Steuerung hat das System die Möglichkeit automatisch auf veränderte Bedingungen zu reagieren.

3.3 Standardisierung

Nach Ferrolho et al. entstehen auch mit Netzwerkanbindung und Programmierschnittstellen noch zu überwindende Probleme [9]. CNC-Maschinen basieren auf einer geschlossenen Architektur numerischer Kontrolle und sind nicht für die Integration mit anderen ausgelegt. Die Kontrolleinheit der Anlage lässt die Steuerung von einem entfernten PC nicht zu. Programmierumgebungen sind nicht ausreichend leistungsfähig um komplexe Aufgaben, wie die kollaborative Operation innerhalb einer flexiblen Fertigungszelle, zu entwickeln. Unterschiedliche Hersteller verwenden eigene Programmiersprachen und Entwicklungstools, wodurch Integration und gemeinschaftliche Produktion erschwert werden. Die sich damit ergebende Heterogenität der Anlagen einer Produktionsstrecke ist ein bereits betrachtetes Problem cyber-physikalischer Systeme (vgl. [2]). Im Falle proprietärer Schnittstellen und geschlossener Architekturen muss ein Adapter die Standardisierung von Protokollen und Informationen durchsetzen [30, 42]. Für SPS gelten in diesem Zusammenhang die gleichen Anforderungen.

R3

Standardisierte Informationsprotokolle und -modelle werden für die Integration heterogener Altmaschinen eingesetzt, so dass Datenaggregation und M2M-Kommunikation gesamtheitlich gewährleistet werden kann.

3.4 Lokalität

CPPS müssen in geringstmöglicher Zeit Betriebs- und Prozessdaten der Maschine analysieren, bewerten und in den Produktionsprozess eingreifen können. Die Synchronisation des virtuellen Modells der Realität wird jedoch durch stetig wachsende Datenvolumina aufgrund steigender Geräteanzahl erschwert. Damit verlangsamt sich die Verarbeitung der Daten mit der geografischen Entfernung zwischen Gerät und System. Bei der Integration von Altmaschinen muss demnach die Datenanalyse,  und Historie sowie die Reaktion auf dadurch erkannte Veränderungen möglichst nahe an der Anlage geschehen. Läuft eine Rückkopplungsschleife direkt an der Maschine, muss außerdem nur ein Teil der anfallenden Daten veräußert und die Kontrolle nur teilweise an hierarchisch übergeordnete Systeme abgegeben werden (vgl. zu diesem Absatz [44]). Durch den verminderten Austausch zwischen den Systemen werden die Sicherheit der Daten verbessert und Kommunikationsfehler minimiert (vgl. [5]).

R4

Die Erfassung und Persistierung anfallender Betriebs- und Prozessdaten sowie die Interpretation von Maschinenbefehlen geschieht geografisch nahe der Anlage, wodurch zeitliche Latenzen, Kommunikationsaufwände und -fehler minimiert werden.

Auch wenn die Zeit für die Kommunikation von Steuerbefehlen und Sensordaten durch die Nähe zur Maschine minimiert wird, ist weder harte noch weiche Echtzeit ein Kriterium. Es wird davon ausgegangen, dass die Interpretation und Ausführung der Maschinenbefehle sowie die Aggregation der Daten direkt an der Maschine geschieht. Um in adäquater Zeit reagieren zu können, unterliegen die für CPPS erforderlichen Kontrollschleifen damit ebenfalls dem  [44].

3.5 Integrationshardware

Die Leistungsfähigkeit von Einplatinencomputern, wie dem Raspberry Pi¹⁵ oder Arduino¹⁶, sowie deren Tauglichkeit im Bereich der Maschinensteuerung (vgl. [14]), ist in der industriellen Fertigung nicht zu ignorieren. Die Ökonomie eines Fertigungssystems hängt unmittelbar an den Kosten für zusätzliche Hardware, wodurch preisgünstige, eingebettete Systeme, nicht nur durch cyber-physische Produktion, an Attraktivität gewinnen [29, 32]. Weiterhin können Einplatinencomputer durch Echtzeitbetriebssystemen auch zeitkritische Steuerungsaufgaben (vgl. Abschnitt 2.1.3) übernehmen. Demnach müssen Einplatinencomputer für das hardwareseitige Retrofitting eingesetzt werden.

R5

Einplatinencomputer werden als zusätzliche Hardware zum Retrofitting eingesetzt, wodurch die Kosten der Modernisierungsmaßnahmen gering ausfallen.

4 Forschungsstand

Nach der Spezifikation der Zielvorgaben werden in diesem Kapitel der aktuelle Stand der Technik sowie bereits bestehende Forschungsarbeiten zum Thema erläutert und mit den aufgestellten Kriterien für eine Lösung abgeglichen.

4.1 Überwachung des Maschinenbetriebs

In cyber-physischen Produktionssystemen ist Adaptivität durch Rückkopplung zentrales Element. Doch um korrigierend auf einen Produktionsprozess wirken zu können, muss der Zustand des physischen Systems bekannt sein. Dieser wird durch Sensorik an der Maschine erfasst und in einem Modell persistiert (vgl. zu diesem Absatz Abschnitt 2.3).

Figure 11: Messgrößen bei der Maschinenüberwachung aus [45]

Vielschichtige Möglichkeiten dieser Art der Erfassung von Betriebs- und Prozessdaten wurden über die Jahre untersucht. Einen aktuellen Überblick hierzu veröffentlichten Teti et al. [45]. Für die Datenaggregation werden im Kontext dieser Arbeit direkte und indirekte Messmethoden mittels Sensorik betrachtet. Bei einer direkten Messung werden Parameter wie Leistungsaufnahme, Drehzahl eines Motors oder die Position erfasst. Indirekte Messungen hingegen sind dem Prozess näher und erfassen Daten wie die auf ein Werkzeug wirkende Kraft, Temperaturen am Werkstück oder Vibrationen. Abbildung 11 stellt diese beiden Kategorien am Beispiel einer Werkzeugmaschine dar. Weitere von Teti et al. untersuchte Forschungsgebiete befassten sich mit Signalverarbeitung und Sensordatenfusion, der Kategorisierung von Messpunkten (Monitoring Scopes) und der Entscheidungsfindung bezüglich konkreter Reaktionen auf sich ändernde Zustände (vgl. zu diesem Absatz [45]).
Eine andere ausführliche Studie zu Arbeiten der Fertigungsprozessüberwachung wurde von Liang et al. veröffentlicht. Sie kategorisierten Forschungsarbeiten nach der Anwendung auf konkrete Anwendungsfälle (vgl. zu diesem Absatz [4]).
Einen konkreten Anwendungsfall zur Signalverarbeitung untersuchten Deshpande und Pieper bei Altmaschinen. Ihr Ziel war eine nicht-invasive Methode der Echtzeitüberwachung über die Stromaufnahme. Die in Kilowatt eingehenden Verbrauchsdaten wurden durch an Bedingungen gekoppelte Schwellwerte in Status (an, aus, Leerlauf), Energieverbrauch, Werkzeugwechsel und Werkstückdurchsatz unterschieden. Via TCP und UDP konnten diese Informationen zur Weiterverarbeitung an Fremdsysteme übergeben werden. Für die Fallstudie und einen anschließenden Vergleich hatten Deshpande und Pieper auch moderne Maschinen mit der UPC ausgestattet (vgl. zu diesem Absatz [8]).
Der abstrakte Weg vom Produktionsprozess bis zur Quantifizierung des Werkzeugzustands wurde durch Ambhore et al. beschrieben. Vom physischen Prozess ausgehend erfassen Sensoren unterschiedliche Werte, die durch Signalanalysen und Klassifikation zur Beschaffenheit des Werkzeugs führen (vgl. Abbildung 12). Zu jedem dieser Schritte des Tool Condition Monitoring (TCM) erläutern die Autoren aktuelle Forschungsarbeiten und belegen die ökonomische Relevanz (vgl. zu diesem Absatz [43]).

Figure 12: Tool Condition Monitoring-System nach [43]

Durch einer Instanz dieses Prozesses wurden indirekte Datenaggregation, Signalverarbeitung und TCM insgesamt am Beispiel von CNC-Maschinen in der Dissertation von Lee erforscht. In seiner Arbeit untersucht und verglich er zahlreiche Sensorsysteme und analysierte durch neuronale Netzwerke und statistische Regression den Zustand des Werkzeugs (vgl. zu diesem Absatz [46]).
Fusion von Sensordaten in einer Fallstudie war Schwerpunkt der Arbeit zu TCM von Downey et al. Die Verortung und Signalkorrelation von Akustikemissions-, Vibrations- und Kraftsensorik ermöglicht das Erkennen von schlechten und guten Fräsverhältnissen. Sie berücksichtigten dabei auch den aktuell ausgeführten CNC-Befehl (vgl. zu diesem Absatz [47]).

Die Konzepte und Zusammenfassungen von Teti et al. [45], Deshpande und Pieper [8], Ambhore et al. [43], Lee [46], Liang et al. [4] und Downey et al. [47] dienen der Kategorisierung von Überwachungsmöglichkeiten. Der Rahmen dieser Arbeit endet mit dem Erfassen des Sensor-Signals im Modell von Ambhore et al. (vgl. Abbildung 12).

4.2 Steuerung von Fertigungssystemen

Die Kontrolle von Werkzeugmaschinen geht von einem Computer aus, der CNC und interne speicherprogrammierbare Steuerungen (SPS) über eine proprietäre Schnittstelle oder Direct Numerical Control (DNC) mit Befehlen versorgt [23]. Während der erste Fall kaum Schwerpunkt aktueller Forschung ist, wurden DNC-Protokolle für die Fertigungsintegration detailliert beleuchtet.
Ferrolho et al. legten den Fokus auf die Integration von Maschinen in flexible Fertigungssysteme (FFS) [48]. Dazu untersuchten sie proprietäre DNC-Protokolle zweier CNC-Anlagen und konzeptionierten ein abstrahierendes Framework. Sowohl die Steuerung der CNC, als auch der über DNC verfügbare Überwachungsmechanismus, kann über ein Netzwerk und somit aus der Ferne bedient werden. Die anfallenden Daten werden auch für die Rückkopplung der Steuerung verwendet (vgl. zu diesem Absatz [48]). Durch die ethernetbasierte Kommunikation über DNC sind die Anforderungen R1 und R2 erfüllt (vgl. Abschnitt 3). Da bei der Abstraktion des DNC-Protokolls keine standardisierten Informationsmodelle und Kommunikationsmechanismen verwendet wurden, gilt R3 für dieses Konzept nicht. Die Verortung und Art der Persistenz eingehender Daten ist in der Arbeit von Ferrolho et al. nicht beschrieben, womit R4 ebenfalls nicht erfüllt ist. R5 ist nicht erfüllt, da als Integrationshardware, beziehungsweise Steuerungssysteme PCs verwendet werden. Eine Sammlung von Softwarewerkzeugen für die Steuerung von Robotern, Fräs- und Drehmaschinen entwickelten Ferrolho et al. zwei Jahre später [9]. Sie erkannten die Notwendigkeit von DNC-Adaptern und schufen ein erweitertes Framework für die verteilte Kontrolle dieser Produktionsmaschinen. Die Generizität der dabei entstandenen Softwarearchitektur wurde in einem Fallstudie mit fünf Anlagen verifiziert und erlaubt die Integration, unabhängig von Hersteller und verwendetem Protokoll (vgl. zu diesem Absatz [9]). Dennoch wurde auch in dieser Arbeit kein Standard verwendet (R3), Lokalität (R4) nicht diskutiert und kein Einplatinencomputer zur Kontrolle eingesetzt (R5), weswegen sie hier lediglich als Erweiterung des vorangegangenen Konzepts verstanden wird.
Die Standardisierung von Kommunikationsprotokollen und Informationsmodellen ist eine Forderung der Industrie 4.0 [49]. Somit müssen auch bei der Aufbereitung der Steuerung einer Altmaschine etablierte Standards beachtet werden.

Figure 13: Flexible Fertigungszelle des IFT Wien [30]

Ayatollahi et al. entwickelten eine CNC-Steuerungsvariante auf Basis eines DNC-Protokolls mit OPC UA (vgl. Abschnitt 2.2) [30]. Für die Integration einer Drehmaschine in ein FFS, wurde ein Informationsmodell entworfen. Ein Server, verantwortlich für die Aktualisierung des Laufzeitmodells des Maschinenkontexts, hält die Verbindung zur Maschine und stellt die physikalischen Informationen und Methoden zur Kontrolle der CNC bereit. Abbildung 13 zeigt den konzeptuellen Aufbau des Systems am Institut für Fertigungstechnik der TU Wien. Weiterhin wurde ein OPC UA Frontend für den speziellen Fall der Maschinensteuerung entwickelt (vgl. zu diesem Absatz [30]). Die Autoren verifizierten den Anwendungsfall der Steuerung von CNC-Maschinen mit einem in der Industrie etablierten Standard [10, 27]. Durch die Verwendung von OPC UA sind die Anforderungen R1-3 vollständig erfüllt. Das Lokalitätskriterium ist bezüglich der Erfassung von Maschinendaten erfüllt. Lediglich der Anforderung R5 wird das Konzept aufgrund der Verwendung eines PCs nicht gerecht. OPC UA beinhaltet auch die Spezifikation von Historie und beantwortet damit auch die Persistenzfrage. Analyse und Rückkopplung sind nicht Teil des Konzepts von Ayatollahi et al. und müssen durch Subsysteme implementiert werden.
Zum Einsatz von Robotern innerhalb FFS forschten Pauker et al. Sie entwarfen ein Konzept, ähnlich dem von Ayatollahi et al., für die Steuerung und Überwachung von Robotern [50]. Die proprietäre Software des Roboters wird durch einen OPC UA Server gekapselt. Ein Informationsmodell bildet den Roboter mit Funktionalität und Zuständen in Form von Variablen ab. Ändert sich zur Laufzeit das vom Roboter eingesetzte Werkzeug, wird dies auch im Informationsmodell widergespiegelt. Das Fehlen standardisierter Steuerungsschnittstellen wird den Autoren nach durch OPC UA ausgeglichen. Außerdem existierte damit eine semantische Beschreibung der Komponenten eines Roboters (vgl. zu diesem Abschnitt [50]). Aufgrund des Fokus auf Produktionsmaschinen wird die Steuerung von Robotern in dieser Arbeit nicht weiter betrachtet. Die Weiterentwicklung des Konzepts der Steuerung beliebiger Maschinen über OPC UA bestärkt jedoch dessen Eignung für die Integration von Altmaschinen.
Auch ältere SPS profitierten von der Beschreibung von Struktur und Funktionalität durch OPC UA. Durch die Zusammenarbeit des PLCopen Konsortiums und der OPC Foundation (vgl. Abschnitt 2.1.3) wird außerdem die Programmierung von SPS mit OPC UA möglich.

Figure 14: Service-orientierte Steuerungslogik nach [13]

Auf Basis von OPC UA stellte Windmann et al. das in Abbildung 14 abgebildete, Service-orientierte Steuerungskonzept für die Automatisierung von Feldgeräten mit SPS vor [13]. Der Fokus lag dabei auf Plug & Produce, wodurch sich das Gerät eigenständig in die Infrastruktur integriert, konfiguriert und arbeitet. Aufgaben, die für eine Programmierung mit IEC 61131-3 (vgl. Abschnitt 2.1.3) zu komplex sind, werden mit einem Softwareagenten plattformunabhängig abgebildet. Die Ein- und Ausgabe sowie die Kommunikation über einen Feldbus übernimmt die Maschinensteuerung. Mit einer Fallstudie zur Bewegungssteuerung mit SPS verifizierten die Autoren das Konzept (vgl. zu diesem Absatz [13]). Die vorgestellte Schichtenarchitektur (vgl. Abbildung 14) kann nach entsprechenden Anpassungen für das Retrofitting eines Feldgerätes im Kontext cyber-physischer Produktionssysteme (CPPS) genutzt werden. Durch die Verwendung von OPC UA sind die Anforderungen R1-3 erfüllt. Der Software-Agent als Teil der Geräteabstraktion lässt neben der lokalen Datenhaltung auch komplexere Logik für Rückkopplungsschleifen zu, wodurch R4 erfüllt ist. Durch die Verwendung eines Industrie-PCs zur Steuerung wird das Konzept der Anforderung R5 nicht gerecht.

4.3 Architektur flexibler Produktion

Überwachung und Steuerung einzelner Maschinen muss im Kontext einer Produktionsumgebung mit vielen heterogenen Feldgeräten betrachtet werden. Die Software- und Systemarchitektur des Gesamtsystems nimmt damit eine zentrale Rolle bei der Integration von Altmaschinen ein.
Wang et al. entwickelten eine offenen Architektur für die Echtzeitüberwachung und -kontrolle von im Netzwerk befindlichen CNC-Maschinen über eine grafische Schnittstelle mit 3D Repräsentation [5].
Ein Web-basierter Thin-Client des Wise-ShopFloor ermöglicht die Kontrolle und Überwachung der Maschinen über ein dreidimensionales Modell der Fertigungsstrecke. Das darunterliegende Framework basiert auf dem^Client/Server-Architekturstil und verwendet seitens des Servers das MVC-Entwurfsmuster. Maschinen werden über das Fabriknetzwerk mit dem Server verbunden und sind somit vom Internet getrennt. Bei der Verwendung mehrerer Clients wird für das Routing ein Publish/Subscribe Mechanismus über HTTP-Streaming eingesetzt. Mit Hilfe dessen wird das Verhalten des auf Java 3D basierenden Visualisierungsmodells durch Sensorik an den Maschinen beeinflusst. In der von Wang et al. durchgeführten Fallstudie wurde, unter Verwendung einer CNC-Fräsmaschine, die Tauglichkeit des Konzepts verifiziert. Die Schnittstelle zwischen Server und Maschine wurde durch einen Open Architecture Controller¹⁷ bereitgestellt (vgl. zu diesem Absatz [5]).
Durch Verteilung von Steuerung und Überwachung der Maschine auf im Netzwerk befindliche Clients, sowie die browserbasierte Nutzungsschnittstelle, werden die Anforderungen R1 und R2 (vgl. Abschnitte 3.1, 3.2) vollständig erfüllt. Ein Standard wird mit der Kommunikation via HTTP verwendet, während Informationsprotokoll und -modell nicht näher erläutert wird. Damit ist R3 nur ansatzweise erfüllt. Da aber Persistenz von Prozess- und Betriebsdaten von einem dedizierten Datenserver übernommen wird, ist das Lokalitätskriterium (R4) nur teilweise erfüllt. Anforderung R5 ist nicht erfüllt, da ein PC Steuerung die Steuerung übernimmt.
Handelt es sich, wie in einem flexiblen Fertigungssystem (FFS), um einen Verbund von Maschinen, werden Rekonfigurierbarkeit und flexible Datenhaltung architektonisch relevant. Die Heterogenität und Austauschbarkeit der Feldgeräte (vgl. Abschnitt 2.1) muss zur Laufzeit berücksichtigt werden. Unter dieser Maßgabe entwarfen Pauker et al. eine Kommunikations- und Integrationsarchitektur für die Montage und Konfiguration einer Fertigungszelle auf Informationsebene [22]. Das Design beinhaltet ein Informationsmodell sowie zentrale Datenhaltung für die Komponenten einer Zelle. Abbildung 15 stellt den Unterschied zwischen einem herkömmlichen und dem Fertigungssystem von Pauker et al. dar.

Figure 15: Vergleich der Architekturen von Fertigungszellen aus [22]

In ihrem Konzept werden die unterschiedlichen Kommunikationskanäle, wie Feldbusse, serielle und digitale Ein-/Ausgabe-Schnittstellen, durch ein TCP/IP Protokoll auf Ethernet-Basis vereinheitlicht. Aus dem Bereich der intelligenten Systeme übernahmen die Autoren das Blackboard-Konzept (vgl. [52]) für den Informationscache, respektive die zentrale Datenhaltung. Parameter für die Kommunikation, der Maschinenstatus, das aktuelle Programm sowie Informationen zu angeschlossenen Geräten werden hierfür in einer XML-Datei abgelegt. Eine Sequenzkontrollkomponente legt seine Forderungen (z.B. starte CNC-Programm) in dieser Datei ab, wodurch andere ihre Aufgaben eigenständig abholen und wahrnehmen können. Komponenten des FFS werden durch ein adaptierendes, nicht standardisiertes Protokoll angebunden. Dieser Ansatz reduziert die Komplexität der Gerätetopologie und führt zu einem geringen Konfigurationsaufwand (vgl. zu diesem Absatz [22]).
Steuerung und Überwachung können mit dem Blackboard auch aus der Ferne geschehen, womit R1 und R2 erfüllt sind. Standardisierung ist nicht Teil des Konzepts, soll aber mit einer OPC UA-Anbindung durchgesetzt werden. Gleiches gilt für die Lokalität von Daten und Logik, wodurch die Anforderungen R2 und R3 nicht erfüllt sind. Auch R5 ist durch das Konzept nicht abgedeckt. Für Retrofitting relevant ist die Arbeit im Bezug auf die zur Laufzeit mögliche Rekonfiguration der Komponenten.
Während Pauker et al. die horizontale Vereinheitlichung der Kommunikation anstreben, forschten Moctezuma et al. an vertikalem und horizontalem Informationsaustausch [53]. Dafür modernisierten die Autoren die Fastory Forschungsfertigungsstrecke. Wenn die zur Steuerung notwendige Echtzeit nahe der Maschine bereitgestellt wird, können Web-Services die Anlagen für den abstrakteren Informationsaustausch kapseln. Die ursprünglich heterogene Feldgerätelandschaft wurde durch eine Service-orientierte Architektur (SOA) ersetzt. Ziel des Konzept ist unter anderem die Einsparung von Energie, Flexibilisierung und Rekonfigurierbarkeit, die Fähigkeit der eigenständigen Wiederherstellung nach Ausfall und Fehler (self-recovery) sowie prädiktive Wartung (predictive Maintenance). Eine zentrale Anforderung an die Schnittstellen der Geräterepräsentation ist, neben Skalierbarkeit und Homogenität, die lokale Verarbeitung von Daten. Intelligente Remote Terminal Units, wie auf der rechten Seite der Abbildung 16, kapseln dazu das industrielle Equipment.

Figure 16: Equipment ohne und mit Retrofitting aus [53]

Das original-Equipment besteht aus der physischen Schicht (Physical) für Aktuatoren und Sensoren. Darüber (Processing) werden die Daten umgewandelt – bei einfachen Sensoren auch ohne Verarbeitung durchgereicht. Die Schnittstellenschicht (Interface) bindet das Gerät an ein Bussystem, digitale Ein-/Ausgabesysteme oder andere, teils proprietäre Kommunikationsmedien (vgl. Abschnitt 2.1). Mit der aufsetzenden Remote Terminal Unit wird zuerst eine zum jeweiligen Medium kompatible Schnittstelle eingesetzt. Eine flexibel anpassbare Schicht für die lokale Datenverarbeitung und Logik stellt die Intelligenz der Remote Terminal Unit. Durch die Kommunikationsschicht werden dann Informationen anstelle der Daten des original-Equipments weitergereicht und konsumiert. Eine Remote Terminal Unit kann außerdem mehrere funktional zusammengehörige Geräte zu einer logischen Einheit verbinden (vgl. zu diesem Absatz [53]).
Das Konzept von Moctezuma et al. erfüllt die Anforderungen R1-R4, basiert aber im Gegensatz zu Windmann et al. auf Web-Services. Lediglich R5 ist kein Teil des Konzepts.
Die Kombination aus Rekonfigurierbarkeit ([22]), Web-Service-basierter Kapselung von Feldgeräten ([53]) und der lokalen Informationsgewinnung aus Anlagen-Rohdaten untersuchten Dürkop et al. im Kontext von SOA [20]. Die vorgeschlagene Architektur ermöglicht Plug-and-Produce, respektive die automatische Rekonfiguration nach physischen Veränderungen auf Basis abstrakter Prozessdefinitionen. Da industrielle Automation beispielsweise Echtzeitkommunikation erfordert, ist eine reine SOA-Lösung unzureichend. Ein Vorteil von Web-Services besteht in der Möglichkeit der Kombination zu abstrakten Diensten. Der Produktionsprozess bestünde aus der Komposition mehrerer Fertigungszellen und Transportsysteme. In vorgestellten Konzept wird daher die strikte Trennung von Web-Service Modul und Echtzeit-Gerätekontrolle postuliert, dargestellt in Abbildung 17.

Figure 17: Aufteilung von Geräten in Automatisierungsmodule [20]

Ein Modul ist eine mechatronische Einheit, die abstrakte Funktionalität, beziehungsweise Dienste, externalisiert. Die Implementierung der Funktionen ist gekapselt und besteht aus Sensoren, Aktuatoren und einer Kontrollkomponente. Echtzeitkommunikation wird zwischen den Geräten, nicht aber zwischen den Modulen gewährleistet. Die Schnittstelle der beiden Schichten wird durch OPC UA bereitgestellt. Dürkop et al. erläutern einen möglichen Arbeitsablauf in dem eine Prozessdefinitionssprache, wie die Business Process Execution Language (BPEL), den übergeordneten Produktionsablauf beschreibt. Anhand derer ermittelt eine Orchestrierungskomponente die für den Prozess benötigten Dienste auf Modulebene. Identifizierte Dienste werden mithilfe eines Diensteverzeichnis (Service Directory) ausgewählt (vgl. zu diesem Absatz [20]).
Überwachung und Steuerung werden von entfernten Subsystemen teilweise übernommen. Feingranulare Logik zur Kontrolle des einzelnen Geräts wird lokal verortet und übermittelt Informationen durch standardisierte Protokolle. Damit sind die Anforderungen R1-4 erfüllt, wodurch die beschriebene Architektur zum Großteil für die Modernisierung von Altanlagen tauglich ist. Anforderung R5 ist kein Teil des Konzepts von Dürkop et al.
In der vorangegangenen Arbeit schlagen die Autoren den Einsatz von Device Profiles for Web Services¹⁸ (DPWS) als Modulimplementierung vor. DPWS ist die Standardisierung einer generischen Web-Service-Middleware für Geräteprofile, welche Struktur und angebotene Dienste des Equipments definieren. Aufbauend auf dem SOAP-Standard kombiniert DPWS eine Auswahl von Web Service Spezifikationen, wie WS-Addressing¹⁹ und WS-Policy²⁰, um das Nachrichtenmodell zu beschränken (vgl. zu diesem Absatz [54]). Aber auch im Zusammenhang mit Erweiterungen können dann eingebettete Systeme andere DPWS-fähige Geräte auffinden und unter anderem mit Ereignissen kommunizieren. Unterschiede, Gemeinsamkeiten und Interoperabilität von OPC UA und DPWS wurden durch Cândido et al. untersucht [54]. Eine teilweise Kopplung beider Standards über Complex Event Processing (CEP) erreichten Izaguirre et al. [55]. Ein übergreifendes Informationsmodell und eine Middleware für die Verbindung von OPC UA und DPWS stellten Bony et al. vor [56]. Sie postulieren, dass weder OPC UA noch DPWS die Anforderungen einer SOA auf Feldebene erfüllen können und die Kombination beider vorteilhaft wäre.

Die bisher vorgestellten Arbeiten bereiten industrielles Equipment auf den Einsatz in CPPS vor, thematisieren ihn aber nicht. Für die Integration von Altmaschinen in ein CPPS wird eine dedizierte Architektur benötigt. Die fünf-Schichten CPS-Struktur (5C-Architektur) von Lee et al. liefert eine Leitfaden zu Entwicklung und Deployment von cyber-physischen Systemen (CPS) für die Produktionsdomäne [40]. Die unterste Ebene (Smart Connection) dient der zuverlässigen und akkuraten Erfassung von Daten der Maschinen und Komponenten, sowie deren ethernetbasierte Kommunikation. Darauf aufbauend (Data-to-Information Conversion) werden die Daten in Informationen gewandelt. Inferenzsysteme und intelligente Analysen dienen hier der Ausfall- und Leistungsvorhersage und führen zur Selbstwahrnehmung (self-awareness) des Equipments. Die folgende Cyber-Schicht bietet digitale Zwillinge der Maschinen und ihrer Komponenten. Sie vergleichen die Leistungsmerkmale ihres physischen Äquivalents mit denen anderer Maschinen (self-compare), führen eine Historie (Time-Machine) und stellen eine cyber-physische Schnittstelle (Cyber-Physical Interface, CPI) für die Machine-to-Machine, beziehungsweise M2M-Kommunikation. Auf einer darüber liegenden Schicht der Kognition, werten Systeme zur Entscheidungsfindung (Decision Support Systems, DSS) zur Unterstützung des Nutzers die Informationen der Cyber-Schicht aus. Auch die Simulation und Synthese weiterer Schritte zählt zu den Aufgaben der Cognition-Ebene. Die oberste Schicht (Configuration) ist als Kontrollinstanz verantwortlich für die Rückkopplung des physischen Raums in das virtuelle Modell. Das Konzept der Time-Machine der Cyber-Ebene verwaltet Momentaufnahmen des erfassten Kontexts (Snapshot Collection) und verhilft dem System zu einer kumulierten Maschinenhistorie. Dadurch kann das aktuelle Verhalten mit bereits bekanntem verglichen werden (Similarity Identification) und ermöglicht Vorhersagen. Durch Simulation können Verhaltensmuster für Szenarien extrapoliert und optimierte Schritte synthetisiert werden (vgl. zu diesem Absatz [40]).
Aufgrund der abstrakten Beschreibung einer Schichtenarchitektur werden die Anforderungen nur teilweise erfüllt. Die Time-Machine läuft nicht zwangsläufig nahe der Maschine. Dennoch erfolgen Zustandserfassung und Störfalldiagnose durch Subsysteme des CPPS, womit R1 erfüllt ist. Die Steuerung von industriellem Equipment ist kein Teil des Konzepts und erfüllt demnach R2 nicht. R3 ist nicht erfüllt, da standardisierte Informationsprotokolle und Modelle nicht integriert wurden. Die Verortung von Daten und Logik ist zweigeteilt. Anforderung R4 ist teilweise erfüllt, da Zustandsüberwachung sowie Ausfall- und Leistungsvorhersage an der Maschine geschehen, jedoch die Cyber-Ebene den zentralen Knotenpunkt für die Historie aller Geräte bildet. Die technologische Sicht wird bei dieser Architektur nicht thematisiert, wodurch Anforderung R5 nicht erfüllt wird. Insgesamt bietet der Ansatz von Lee et al. eine architektonische Basis für CPS in der .

4.4 Fazit zum derzeitigen Forschungsstand

Die Überwachung und Steuerung von Produktionsmaschinen für Anwendungen in der Industrie 4.0 ist Teil unterschiedlicher Forschungsprojekte. Im Projekt OPC4Factory der TU Wien wurden generische OPC UA Informationsmodelle entwickelt. Diese verbessern die Konnektivität von NC-Maschinen, Industrierobotern und anderen Komponenten innerhalb einer flexibel automatisierten Fertigungszelle. Die Orchestrierung der Fertigungsoperationen sowie die Konfiguration der Komponenten soll durch die Lösung der Schnittstellenproblematik vereinfacht werden (vgl. zu diesem Absatz [57]).
Die Integration bestehender Hardware in die intelligente Steuerung einer Fabrik ist Thema des RetroNet-Projekts. Das Fraunhofer IPK entwickelt mit Industriepartnern physische und logische Adapter für die Anbindung von bestehenden Anlagen an eine Steuerungsplattform. Maschinen-, Anlagen und Produktionsdaten werden zu diesem Zweck zentral erfasst und gespeichert. Weiterhin soll eine Middleware im Client-Server-Architekturstil Dienste und zugrunde liegende Teilsysteme miteinander verbinden und eine vermittelnde Rolle im Gesamtsystem einnehmen (vgl. zu diesem Absatz [6]).
Forschung im Bereich Cloud-basierter Industriesteuerung wird in Zusammenarbeit von Fraunhofer, der TU Berlin und Industriepartnern betrieben. Im Projekt pICASSO werden die Auslagerung von Steuerungsdiensten in die Cloud und Möglichkeiten einer Verteilung und Modularisierung herkömmlicher Kontrollsysteme auf CPS-Komponenten untersucht (vgl. zu diesem Absatz [58]).
Der Schwerpunkt eines Großteils aktueller Forschung liegt auf der Vereinheitlichung der Schnittstellen und deren Durchsetzung – meist mittels Software-Adaptern. Die Gemeinsamkeit aller vorgestellten Architekturkonzepte liegt in der Verwendung von Maschinenrepräsentanten. Auch die Aufteilung einer solchen Repräsentation in zwei Schichten ist etabliert. Der Echtzeit-Kontakt zur physischen Welt wird durch eine bereitgestellt. Intelligentes Informationsmanagement, Analyse- und Rechenfähigkeit durch die andere [59]. Das Referenzarchitekturmodell RAMI4.0 der VDI/VDE-Gesellschaft beschreibt diese Komponente als I4.0-Komponente mit virtueller Verwaltungsschale [49].
Nahezu alle betrachteten Forschungsarbeiten erlauben die Steuerung und Überwachung durch Nutzungsschnittstellen oder Subsysteme eines Produktionssystems. Standards werden oft gefordert, stehen jedoch meist nicht im Zentrum der wissenschaftlichen Betrachtungen. Hervorzuheben ist hierbei die Verwendung der etablierten OPC Unified Architecture (vgl. Abschnitt 2.2). Aktuelle Feldgeräte besitzen entweder einen eingebetteten OPC UA Server, sind darauf vorbereitet oder können mit zusätzlicher Peripherie²¹ und Software²² ausgestattet werden. Somit liegt die Verwendung dieser Spezifikationen für die Steuerung von Produktionskomponenten nahe und muss in ein Konzept für die Integration von Altmaschinen einfließen.

Die Gegenüberstellung von Anforderungen und bestehenden, für das folgende Konzept relevanten, Forschungsarbeiten ist in Tabelle 1 zusammengefasst, wobei ● die Erfüllung, ◐ die eingeschränkte oder teilweise Erfüllung und ○ die Nichterfüllung symbolisiert.

5 Konzeption

Nach der Analyse bestehender Forschungsarbeiten folgt in diesem Kapitel die Konzeption einer Lösung zu den in Abschnitt 1 beschriebenen Problemen unter Berücksichtigung der Anforderungen aus Abschnitt 3 und Konzepten aus Abschnitt 4. Ein Softwareartefakt und seine Einbettung in eine System- und Softwarearchitektur werden vorgestellt. Die verschiedenen Perspektiven auf den Entwurf sind an das 4+1 Software-Architekturmodell nach Kruchten angelehnt [60]. Eine virtuelle Maschinenrepräsentation (VMR) bildet die Schnittstelle zur Altanlage, beziehungsweise zu ihren automatisierten Werkzeugkomponenten und damit den Schwerpunkt des hier vorgestellten Designs. Das Informations- und Kommunikationsmodell der VMR mit OPC UA ergänzt die Anlage um eine in der Industrie etablierte, semantische Schnittstelle. Repräsentanten der berücksichtigten Maschinen sind in Szenarien beschrieben. Die Arbeit im Kontext dieser Szenarien und die Aufteilung der Aufgaben unter den Produktionsbeteiligten wird durch Anwendungsfälle .

5.1 Kontext

5.1.1 Szenarien

5.1.1.0.1 S1 – Werkzeugmaschine ohne Schnittstellen.

Besitzt die Altanlage keinerlei Schnittstellen, können weder CNC noch automatisierte Werkzeugkomponenten von außen beeinflusst werden. Die CNC ist fest mit der Antriebssteuerung verdrahtet und die maschineneigene SPS für automatisierte Werkzeugkomponenten ist dem Entwickler verborgen. Auch die notwendigen Daten zur Überwachung des Fertigungsprozesses können nicht durch externe Systeme bezogen werden. Ein serieller RS-232 oder Parallelport verbindet lediglich die Steuerungseinheit mit der SPS. Somit ist außer dem Lokalitätskriterium (vgl. Abschnitt 3.4) keine der Anforderung erfüllt. Für solche Anlagen muss eine standardkonforme Schnittstelle und deren Anbindung an CNC und automatisierte Werkzeugkomponenten vollständig durch die virtuelle Maschinenrepräsentation (VMR) bereitgestellt .

5.1.1.0.2 S2 – Werkzeugmaschine mit Direct Numerical Control.

Direct Numerical Control (DNC) erlaubt das sukzessive Übertragen der CNC-Befehle an die Maschine (vgl. Abschnitt 2.1.2). Trotz der damit physisch kompatiblen Datenverbindung zur Anlage sind unterschiedliche, meist proprietäre, Kommunikationsprotokolle für DNC üblich [61]. Die maschineneigene SPS ist verantwortlich für automatisierte Werkzeugkomponenten wie Türautomatik oder Kühlsystem. Dem Entwickler steht keine Schnittstelle für diese zur Verfügung. Somit muss neben Adaptern für die DNC-Protokolle eine SPS-Anbindung durch die VMR umgesetzt werden, sofern die DNC jene nicht bereits kapselt.

5.1.1.0.3 S3 – Speicherprogrammierbare Steuerungen.

Beim Retrofitting von SPS werden in dieser Arbeit drei Fälle unterschieden. Im aufwändigsten Fall besitzt die SPS keine Ethernetanbindung für Kommunikation via TCP/IP und arbeitet über einen Feldbus (S3.1). Der zweite Fall von zu modernisierenden SPS setzt eine Netzwerkanbindung voraus, veräußert jedoch weder ein Informationsmodell noch standardisierte Kommunikationsprotokolle (S3.2). Im letzten Fall verfügt die SPS bereits über ein integriertes Informationsmodell und kommuniziert durch standardisierte Protokolle. Gegebenenfalls müssen Adapter die Protokolle und Modelle zu einem im Netzwerk einheitlichen überführen (S3.3).

Sowohl Ayatollahi et al., als auch Ferrolho et al. nutzten für die Umsetzung ihres Konzepts die Drehmaschine EMCO Concept Turn 55, an der auch die Anwendungsfälle S1 und S2 orientiert sind (vgl. [30, 48], Abschnitt 4.2). Die in dieser Anlage verbauten automatisierten Werkzeugkomponenten sind und Kühlsystem sowie eine Türautomatik. Ein proprietäres, serielles DNC-Protokoll ermöglicht die Anbindung externer Systeme in Szenario S2.

5.1.2 Anwendungsfälle

Die unterschiedlichen Anforderungen der mit dem System interagierenden Menschen werden in Anwendungsfällen deutlich, die auszugsweise aus den Personas von Denner et al. hervorgegangen sind [62].

5.1.2.0.1 A1 – Montagearbeiter.

Ein Montagearbeiter ist neben dem Zusammensetzen einer Maschine verantwortlich für die Verwaltung und Reparatur der einzelnen Komponenten (vgl. Abbildung 18). Dafür muss er wissen, welche Teile verbaut werden sollen und wie diese zusammenhängen. Eine einfache Stückliste leistet das nicht und muss bei der Anlagenmodernisierung durch ein digitales Modell der Zusammensetzung – zugänglich auch für andere Teammitglieder – abgebildet werden. Bei modernen Anlagen ist der Maschinenhersteller ist für die Modellierung des Informationsmodells zur Maschinenstruktur und für die initiale Einrichtung verantwortlich.

Figure 18: Anwendungsfälle eines Montagearbeiters

5.1.2.0.2 A2 – Produktionsleiter.

Wie in Abbildung 19 dargestellt, ist ein Produktionsleiter hauptsächlich für die Erstellung, Überwachung und Dokumentation von Produktionsplänen zuständig. Er ist für eine reibungslos funktionierende Fertigungsstrecke verantwortlich und benötigt eine zusammenfassende Darstellung der Betriebs- und Prozessdaten um auch Wartungsaufträge delegieren zu können. Altmaschinen können diese Daten auch erfassen. Jedoch lassen sie die Einsicht aus der Ferne aufgrund fehlender Infrastrukturanbindung nicht zu.

Figure 19: Anwendungsfälle eines Produktionsleiters

5.1.2.0.3 A3 – Maschinenbediener.

Der Maschinenbediener richtet die Anlage ein (vgl. Abbildung 20). Er integriert sie in den Kontext der Produktionsstrecke und bindet sie an das bestehende Automatisierungssystem. Kenntnis der technischen Schnittstellen für diese Integration entnimmt er dem digitalen Modell der Maschine. Die detaillierte Darstellung des Systemzustands hilft einem Maschinenbediener bei der Überwachung des Fertigungsschritts und der Reaktion bei Störfällen. Auch maschinenspezifische Anpassungen von CNC-Programmen werden von ihm .

Figure 20: Anwendungsfälle eines Maschinenbedieners

5.1.3 Systemumgebung

Durch die Anwendungsfälle und Szenarien ergibt sich ein Systemkontext, dargestellt in Abbildung 21. In diesem interagiert der Produktionsleiter mit dem Enterprise Resource Management (ERP) und einem Produktionsplanungssystem (PPS). Aufträge und benötigte Ressourcen werden hier in die Planung der Fertigung überführt. Die Bedienung der konkreten Maschinen geschieht über die virtuelle Maschinenrepräsentation (VMR). Diese kapselt die in den Szenarien vorgestellten Altanlagen und ist weiterhin mit den Feldgeräten und der Produktionsplanung verbunden. Ein Maschinenbediener muss nicht direkt an der Anlage arbeiten, sondern kann die Steuerung und Überwachung von einer entfernten Nutzungsschnittstelle übernehmen. Der Montagearbeiter agiert auf Feldebene, kennt die Systemstrukturen und verwaltet und wartet das Produktionsequipment. Die Verbindung der VMR zu anderen Feldgeräten, ihre Kapselung der Altanlage und die Integration mit externen Systemen, wie einem ERP-System, wird in diesem Konzept vorgestellt.

Figure 21: Kontext der zu integrierenden Altanlage

5.2 Informationsmodell

Die Forderung standardisierter Informationsmodelle und Machine-to-Machine Kommunikation wird durch aktuelle Forschung im industriellen Umfeld gestützt [19]. OPC UA, im weiteren Verlauf als Unified Architecture (UA) abgekürzt, bietet die dafür geeigneten Werkzeuge [19, 55]. Echtzeit und direkte Bewegungskontrolle sind nicht möglich, weshalb eine eigenständiger Schicht in Abschnitt 5.3.1 besprochen wird [19]. Bei der Modernisierung von Altanlagen wird deren strukturelle Komponentenbeschreibung in einem UA-Adressraummodell hinterlegt.

5.2.1 Modellierung der Anlagenstruktur

Das Metamodell der UA bietet unter anderem typisierte Objekte, Variablen und Methoden. Mit dessen Instanzen werden die automatisierten Werkzeugkomponenten einer Maschine baumartig organisiert. Das grundständige Modell eines UA-Adressraums wurde bereits für die Integration einer Werkzeugmaschine erweitert und Modellelemente für deren automatisierte Werkzeugkomponenten und numerische Kontrolle definiert [30]. Diese Erweiterung der Data-Access Spezifikation (vgl. Abschnitt 2.2.1) von Ayatollahi et al. wird in dem vorliegenden Konzept verwendet und ist in Abbildung 22 dargestellt. In diesem Teilmodell sind, bis auf den BaseObjectType der grundlegenden UA-Spezifikation, alle Elemente aus dem Namensraum OPC4Factory. Variablen und Methoden sind Elemente, welche durch die hasComponent-Relation mit einer Maschinenkomponente verknüpft werden. Beispielsweise komponiert ein Objekte vom Typ LoadingDoorType sowohl die Variable Door_Status, als auch Methoden zum Öffnen (Open_Door) und Schließen (Close_Door) einer Ladetür.

Figure 22: OPC UA Modellerweiterung nach [30]

Bei der Modellierung einer SPS wie in Szenario S3 bietet sich die Companion Specification der PLCopen an (vgl. Abschnitt 2.1.3). Durch Abbildung von Funktionsbausteinen und Ein-/Ausgabeparametern auf den UA-Adressraum können Anwendungen die Anlagenstrukturen auf gleiche Weise erfragen und manipulieren [63]. Bei der Verwendung der IBH Link UA, ist die Informationsmodellierung implizit in der Variablendefinition enthalten und wird via Ethernet auf das Gerät übertragen²³. Wird das Ignition OPC UA Softwaremodul verwendet, kann das Modell frei und damit nach der Erweiterung von Ayatollahi et al. gestaltet werden. Eine Alternative zu dem vorgestellten Informationsmodell für SPS ist das von Windmann (vgl. Bild 4 in [13]). Innerhalb dieses Konzepts hängt der Verwendete Ansatz vom jeweiligen Nutzungskontext ab. Da Standardisierung jedoch eine zentrale Anforderung der Anlagenmodernisierung ist, wird die Variante mit PLCopen bevorzugt.

Figure 23: CPPS Erweiterung des Informationsmodells

Cyber-physische Produktionssysteme (CPPS) stehen über Aktuatoren und Sensoren mit der realen Welt in Verbindung (vgl. Abschnitt 2.3). Um sie mit der virtuellen Maschinenrepräsentation (VMR) verknüpfen zu können, sind Konfigurationsparameter, wie physische Adresse, ein Netzwerk oder Hardwareport und andere Initialisierungswerte notwendig. Diese sollen im Informationsmodell festgelegt werden können. Dafür wird die Spezifikation von Ayatollahi et al. um physische Objekte für jede automatisierte Werkzeugkomponente ergänzt, dargestellt in Abbildung 23. Beispielsweise besitzt der LoadingDoorType aus dem OPC4Factory-Namensraum eine Unterklasse PhysicalLoadingDoorType. Eine Anlagendefinition vom Type MachineType kann dann das optionale Objekt Loading_Door beinhalten. Die Objekte Opening_Gear und Door_Lock sind vom Typ PhysicalConnectionType aus dem Namensraum CPPS. Sie sind aktive, virtuelle Teilkomponenten der Maschine und in diesem Beispiel verantwortlich für die Bewegung und einen Schließmechanismus der Anlagentür der Szenarien S1/2. Die Bewegung kann durch einen Servomotor-Aktuator und das Verschließen durch ein Relais ausgeführt werden. Eine physische Verbindung beinhaltet ein Property ConnectionIdentifier, welches die Konfigurationsparameter repräsentiert.
Im Anwendungsfall A1 wird bei der Montage der Maschine das Modell um die Beschreibung der physischen Verbindungen ergänzt. Auch bei der Verwaltung der Maschinenkomponenten unterstützt das Modell den Monteur. Ein Wartungsauftrag des Produktionsleiters (A2) kann im Modell mit einer solchen Verbindung verknüpft werden. Der Maschinenbediener (A3) bekommt im Fehlerfall ein UA-Ereignis mit der detaillierten Beschreibung des Ausfallgrunds an die jeweilige Nutzungsschnittstelle.

Figure 24: ECA Erweiterung des Informationsmodells

Die Regeln einer cyber-physischen Rückkopplung werden mit der Anlagenstruktur der VMR modelliert, dargestellt in Abbildung 24. Dafür wurde das Informationsmodell um den Variablentyp PhysicalConditionType und den Referenztyp HasPhysicalActionType erweitert (vgl. Abbildung 24a). Instanzen (im Beispiel StopCondition) des ersten sind als Teil der Variablen (NC_Program_Status) einer automatisierten Werkzeugkomponente (NC) der Maschine (EMCO CONCEPT TURN 55) beschrieben. Diese beinhalten den Wert einer Bedingung (Stop) und können beliebigen Typs sein. Mit dem zweiten Typ wird die jeweilige Aktion, respektive UA-Methode (Open_Door) referenziert. Eine Modellierung der Ereignisse von Event-Condition-Action ist nicht notwendig (vgl. Abschnitt 5.3.4). Wird nun der Wert einer Variablen verändert und der neue entspricht der verknüpften Bedingung, folgt die physische Aktion. Im Beispiel der Abbildung 24b soll demnach die Ladetür der Anlage geöffnet werden, wenn die numerische Kontrolle stoppt.

Das Informationsmodell besteht demnach aus drei Schichten der Spezifikation. Allem zugrunde liegt die UA-Definition (OPC UA Part 5²⁴). Darauf aufbauend wurden die Modellelemente von Ayatollahi et al. zur Steuerung und Überwachung der Altanlage übernommen (OPC4Factory, [30]). Die Verbindung mit dem physikalischen Kontext und die Modellierung der Regeln für cyber-physische Rückkopplung gehen von der in diesem Konzept entworfenen UA-Erweiterung aus (CPPS).

5.2.2 Laufzeitmodell

Beim Start der virtuelle Maschinenrepräsentation (VMR) wird das Informationsmodell geladen und steht für andere Maschinen und Nutzungsschnittstellen zur Verfügung. Die angeschlossenen Sensoren erfassen permanent den physischen Kontext und aktualisieren das Informationsmodell zur Laufzeit. Außerdem werden die Regeln für Rückkopplung innerhalb der VMR auch aus diesem Modell gewonnen. Damit besitzt die VMR eine Wissenbasis mit Local Context und Runtime Adaptation Model nach Wätzoldt und Giese [35]. Fragt eine andere Maschine oder Nutzungsschnittstelle die Struktur der Anlage hinter der VMR an, wird auch der aktuelle Kontext präsentiert.

Figure 25: Laufzeitmodell der Maschine der Szenarien S1/2

In Abbildung 25 ist das Laufzeitmodell der Anlage aus Sicht eines Anwendungsprogramms²⁵ zu sehen. Durch die beispielhaften Methoden Close_Door und Open_Door sowie die Variable Door_Status der Ladetür, kann der physische Kontext nicht nur eingesehen, sondern auch manipuliert werden. Rückkopplungsmechanismen (vgl. Abschnitt 5.3.4) sorgen für die Konsistenz von Realität virtuellem Modell. Änderungen an der Struktur der automatisierte Werkzeugkomponenten werden im Modell reflektiert und dessen Struktur neu organisiert. In Szenario S1/2 betrifft das den Austausch des Werkzeugs der Maschine.

5.3 Virtuelle Maschinenrepräsentation

Die virtuelle Maschinenrepräsentation (VMR) ist in der Verwaltungsschale einer I4.0-Komponente des RAMI4.0 Referenzmodells eingebettet und bietet fachliche Funktionalität (vgl. Bild 9 aus [49]). Durch sie können einzelne Baugruppen, Sensoren/Aktuatoren oder ganze Maschinen im Kontext eines Produktionssystems abgebildet werden. Bei der Modernisierung von Altanlagen mittels dieses Konzepts müssen allem voran die Schnittstellen durch eine VMR gekapselt werden, was in den folgenden Abschnitten detailliert beschrieben wird.
Die Architektur des Industrie 4.0 konformen Retrofittings besteht aus den Schichten und Komponenten der Arbeiten von Lee et al., Moctezuma et al. und Dürkop et al. [20, 40, 53], dargestellt in Abbildung 26.

Figure 26: Konzept der virtuellen Maschinenrepräsentation

Die VMR entspricht der intelligenten Remote Terminal Unit von Moctezuma, kapselt die Altanlage und bietet durch die Comm-Schicht nahtlose Kommunikation auf Feldebene [53]. Sie wandelt mittels der Processing-Ebene die gesammelten Daten der Maschine, abgebildet durch UA-Variablen, in Informationen in Form von Fusionsvariablen und UA-Ereignissen. Fusionsvariablen entstehen durch den Schritt der Signalverarbeitung im Monitoring-Prozess nach Ambhore et al. und setzen sich aus vorverarbeiteten Sensorwerten zusammen (vgl. Abbildung 12 in Abschnitt 4.1) So werden die Daten der Altanlage zentral erfasst und vorverarbeitet, nicht aber persistiert, wie im Blackboard-Konzept von Pauker et al. [22]. Dennoch ist die Rekonfigurierbarkeit nach deren Konzept durch die lose gekoppelten Module gegeben. Außerdem werden historische Maschinendaten durch die Historical Access Spezifikation (OPC UA Part 11²⁶) in der VMR persistiert. Die zentrale Auswertung der Informationen wird von den Mechanismen der Time-Machine (TM) auf Cyber-Ebene übernommen (vgl. [40]). Diese steht in Verbindung mit der VMR, ist aber nicht direkt an der Anlage verortet, wodurch intelligente Analysealgorithmen (vgl. Time-Machine Mechanismen in Abschnitt 4.3) auf leistungsfähiger Hardware implementiert werden können. Die Verbindung zwischen Time-Machine, anderen Diensten und VMR, symbolisiert durch die gestrichelte Grenze in Abbildung 26, wird mit dem Web-Service-Modul nach Dürkop et al. an die Cyber- und Conversion-Schicht der 5C-Architektur gebunden [20, 40]. Die darüberliegenden Ebenen der Cognition und Configuration sind kein Teil dieses Konzepts.

5.3.1 Anlagenanbindung

Die Remote Terminal Unit besitzt eine Schnittstelle zur Altanlage, die das physische Gerät von der VMR separiert und auf der Smart Connection Ebene implementiert ist [40, 53]. In den Szenario S1/2 wird diese Anbindung durch einen Einplatinencomputer auf Feldebene (Device-Level, vgl. Abbildung 26) realisiert. Der Einplatinencomputer fungiert als Integrationshardware zwischen den digitalen und analogen Signale von Sensoren und Aktuatoren und einem abstrakten Kommunikationsprotokoll wie zum Beispiel dem Representational State Transfer (REST) mit HTTP oder WebSockets. In Szenario S1 kapselt er die Antriebssteuerung der CNC und dessen interne SPS. Eine Software-Middleware (vgl. Abschnitt 5.4) auf dem Einplatinencomputer ist für diese Datenvermittlung verantwortlich und implementiert die Comm-, Processing und Interface-Schicht der Remote Terminal Unit (vgl. Abbildung 26). Eine andere Möglichkeit der physikalischen Anbindung sind Einplatinencomputer mit vorbereiteter Middleware, wie das Grove-²⁷ oder Wio-Link-System²⁸.
Die Möglichkeiten der Verortung von Sensorik und die der Signalverarbeitung zur Überwachung des Anlagenzustands werden in den Arbeiten von Teti et al., Liang et al. und Downey et al. ausführlich diskutiert und sind auf das Retrofitting mit der VMR anwendbar [4, 45, 47]. Szenario S2 reduziert den Einsatz des Einplatinencomputers auf einen Software-Adapter für das Direct Numerical Control (DNC) Protokoll, wie bei Ferrolho et al., wobei die Echtzeitkontrolle der Anlagensteuerung selbst obliegt [48]. Falls die zu modernisierenden Anlagen über COM/DCOM (vgl. Abschnitt 2.2) verfügen, können Gateways, wie das Unified Automation UaGateway²⁹ oder der MatrikonOPC UA Proxy³⁰, im Retrofitting eingesetzt werden. Im Szenario S1 kann Echtzeitfähigkeit nur über zusätzliche Steuerungshardware gewährleistet werden. So können bei der Verbindung der VMR mit der Antriebssteuerung einer CNC, ebenfalls Einplatinencomputer verwendet werden, die wiederum eine Middleware mit Schnittstelle bereitstellen [14].
Für die Anlagenanbindung in Szenario S3 werden drei Fälle unterschieden. Sollte keine Ethernetanbindung mit TCP/IP existieren (S3.1) muss die SPS durch Hardware entsprechen ausgestattet werden. Die SPS ist lediglich an ein Bussystem gekoppelt und wird mit einer Ethernet-Karte erweitert. Bei existierendem TCP/IP Kommunikationskanal (Szenario S3.2) repräsentiert externe Soft- und Hardware die VMR und stellt die UA-Verbindung bereit. Eine Komponente mit integriertem UA-Server ist die IBH Link UA³¹ für die Steuerungen S5 und S7 von Siemens. Weiterhin existieren Softwarelösungen für SPS von Allen-Bradley oder Siemens, sowie für verschiedene proprietäre Protokollen, wie das Ignition OPC UA Module³². Dieses Softwaremodul ist ein UA-Server der mittels Treibern SPS, andere Geräte und Netzwerkprotokolle kapselt. Bei bestehenden Informationsmodellen (S3.3) kann die Middleware als Adapter für das Informationsmodell der SPS fungieren und eines nach Abschnitt 5.2 kommunizieren (vgl. Abschnitt 5.2.1).
Windmann et al. beschrieben einen generischen Ansatz für die Anbindung von Steuerungen, abseits industrieller Hersteller [13]. Die darin vorgeschlagenen Softwareagenten implementieren das Konzept der hier vorgestellten VMR.
Alle beschriebenen Varianten der technischen Anbindung einer Altanlage dienen der Kommunikation zwischen den Feldgeräten.

5.3.2 Horizontale Integration

Nahtlose Kommunikation zwischen den Maschinen wird durch eine horizontale Integration der Altanlage erreicht. Durch die Verbreitung der OPC Unified Architecture (UA) sind neben deren Informationsmodell (vgl. Abschnitt 5.2) die Kommunikationskonzepte geeignet für diese Arbeit. Beim Starten der Middleware auf dem Einplatinencomputer wird zuerst das Informationsmodell der virtuellen Maschinenrepräsentation (VMR) geladen und initialisiert. Danach integriert sie sich selbstständig in das Fertigungssystem, um mit anderem Equipment interagieren zu können. Die Dienste der UA zum Auffinden von Geräten (OPC UA Discovery) werden für die automatische Eingliederung der VMR genutzt, dargestellt durch Abbildung 27.

Figure 27: Horizontale VMR-Integration

Dafür wird ein Eintrag im Diensteverzeichnis der UA (Local Discovery Server, LDS) angelegt (Variante a der Abbildung 27). Der UA-Server der VMR sendet eine Nachricht an den LDS, dessen Adresse bekannt sein muss und informiert ihn damit über seine Verfügbarkeit (Abbildung 27, a.1). UA-Clients können diesen Knotenpunkt nach Diensten fragen (a.2) und erhalten die jeweilige Beschreibung (a.3). Danach kann dieser Client die Dienste der VMR in Anspruch nehmen (a.4). Soll kein zentralisiertes Diensteverzeichnis verwendet werden, bietet das Multicast Domain Name System (mDNS) eine Alternative (Variante b der Abbildung 27). Durch Multicasts im lokalen Netzwerk der VMR können Feldgeräte ad hoc die verfügbaren Dienste erfragen (b.1). Wird eine solche Anfrage durch ein Feldgerät abgesendet, schicken ihr die umliegenden Geräte eine Beschreibung ihrer Funktionalität (b.2). Der Client entscheidet sich für die VMR und nutzt dessen Dienste (b.3). Nachteilig ist hierbei die Beschränkung auf das lokale Subnetz. Besteht das Produktionssystem aus mehreren Netzwerken, kann die Multicast-Anfrage die Grenzen nicht überwinden, wodurch Geräte nicht gefunden werden.
Für die eigentliche Verbindung zu den Diensten bestehender Feldgeräte mit der VMR, respektive die horizontale Integration, wird das binäre UA-Transportprotokoll verwendet (vgl. Abschnitt 2.2.2), da die Integrationshardware mit ressourcenschonender Software betrieben werden muss.

Die Anwendungsfälle eines Monteurs (A1) werden zwischen dem Module- und dem Cyber-Level des VMR-Konzepts unterstützt (vgl. Abbildung 26). Mit einem UA-Client hat er die Möglichkeit die Maschinenkomponenten zu verwalten und die abgeschlossene Wartung derer zu bestätigen. Über diesen Client kann auch der Maschinenbediener (A3) die Altanlage auf den Betrieb vorbereiten, indem er die physikalischen Verbindungen, also Instanzen des PhysicalConnectionType, konfiguriert (vgl. Abschnitt 5.2.1). Bei der Überwachung des Fertigungsschritts kann er die Sensorwerte und Aktuatorenzustände sowie die Situation einsehen und Ausnahmefälle antizipieren. Bevor CNC-Programme ausgeführt werden, hat er die Möglichkeit sie anhand der aktuellen Situation anzupassen. Ein Beispiel wäre das Fehlen eines vom Programm geforderten Werkzeugs und dessen programmatischer Austausch im Laufzeitmodell.

5.3.3 Vertikale Integration

Durch die Anlagenanbindung (vgl. Abschnitt 5.3.1) und horizontale Integration (vgl. Abschnitt 5.3.2) kapselt die virtuelle Maschinenrepräsentation (VMR) die Funktionalität sowie den Zustand der Altanlage und ermöglicht die nahtlose Kommunikation mit anderen Feldgeräten und Nutzungsschnittstellen. Mit dem Modulkonzept von Dürkop et al. kommen Rekonfigurierbarkeit (vgl. [22]) und die Schnittstelle zu einer SOA hinzu [20]. Die UA ermöglicht zwar dem MES oder SCADA-System das Vordringen bis auf Feldebene (vgl. Abschnitt 2.1, [27, 56]), jedoch fehlen ihr die Konzepte für eine übergeordnete Produktionsplanung und -steuerung, die in Prozessen formalisiert beschrieben (z.B. mit BPEL) und innerhalb einer SOA ausgeführt werden kann (vgl. [20]). Mit der Spezifikation der Device Profiles for Web Services (DPWS) wird in diesem Konzept eine Modulimplementierung verwendet, die eine industrienahe, rekonfigurierbare, vertikale Integration und Prozessebene ermöglicht. Das Modul nach Dürkop et al. koppelt die VMR mit den übergeordneten Ebenen der 5C-Architektur via DPWS und ist in Abbildung 28 dargestellt [20, 40]. Nach ihrer Initialisierung verbindet sich die VMR mit dem UA-Client ihres Modul-Pendants (Abbildung 28, 1) auf der Cyber-Ebene, welches Anfragen und Ereignisse zwischen den beiden Schnittstellen vermittelt. Eine Konkretisierung der Vermittlung durch das Modul geht über den Rahmen dieser Arbeit hinaus.

Figure 28: Vertikale Integration der VMR

Im Anwendungsfall A2 kann der Produktionsleiter einen übergeordneten Produktionsprozess inklusive der Altanlage definieren, Überwachen und anstoßen (Abbildung 28, 2/3). Eine Prozess-Engine ist verantwortlich für die Delegation der Fertigungsschritte und führt die in BPEL definierten Service-Aufrufe an die SOA-Module aus (vgl. Beispielarbeitsablauf in [20], Abbildung 28.4/5/6). Diese schicken dann die Methodenaufrufe an den UA-Server der VMR und steuern damit die Maschine (Abbildung 28, 7). Durch die Verwendung einer formalisierten Prozesssprache, wie der BPEL, ist die Dokumentation in Anwendungsfall A2 abgedeckt. Die gesammelten Daten der Altanlage werden permanent im Informationsmodell der VMR aktualisiert (vgl. Abschnitt 5.2.2). Das Modul reagiert durch UA-Ereignisse auf Veränderungen des Modells und gibt diese durch DPWS-Ereignisse an übergeordnete Dienste, wie ein ERP, Mobilgerät oder Time-Machine, weiter. Eine geeignete Nutzungsschnittstelle (User-Interface, UI) aggregiert diese Ereignisse und bereitet sie für den Produktionsleiter zentral auf. Fällt eine Anlage aus, wird dies mittels Ereignis durchgereicht und visualisiert, so dass die Vergabe von Wartungsaufträgen (A2) erfolgen kann. Der Monteur aus Anwendungsfall A1 kann diese Aufträge einsehen und entsprechend reagieren.

5.3.4 Cyber-physische Rückkopplung

In cyber-physischen Produktionssystemen (CPPS) wird der reale Zustand eines verwalteten Elements über Rückkopplungsschleifen (Feedback Control Loop, FLC) mit Zielen und erwartetem Verhalten verglichen und auf ihn eingewirkt (vgl. Abschnitt 2.3). Bei der Modernisierung von Fertigungsanlagen kann der Automatisierungsgrad erhöht werden, wenn die Maschine selbst als verwaltetes Element ihren Zustand teilweise kontrolliert. Eine interne FCL als Teil der virtuellen Maschinenrepräsentation (VMR) ist für diese Selbstwahrnehmung (self-aware) der Anlage zuständig. Zur eigenständigen Konfiguration (self-configure), Selbstadaptivität (self-adaptive) und Fähigkeit zum Vergleich (self-compare) im Kontext der Produktionsstrecke wird eine externe FCL genutzt, die auf dem Configure-Level der Architektur nach Lee et al. arbeitet [40]. Letztere liegt außerhalb des Rahmens dieser Arbeit. Im Gegensatz zur externen FCL, ist die interne Teil des verwalteten Elements und damit Teil der VMR [64]. MAPE-K bildet hier das Konzept des Adaptivitätsmechanismus und nutzt dafür Event-Condition-Action (ECA, vgl. auch [65] und Abschnitt 2.3).

Eine gesonderte Verarbeitung von Ereignissen ist während des Monitorings nicht notwendig. Die VMR benötigt keinen internen Ereignismechanismus und kann in dieser Phase direkt auf die Veränderung der Variablen des Informationsmodells reagieren. Wurde beispielsweise die Variable NC_Program_Status aktualisiert, werden alle darunter organisierten Variablen vom Typ PhysicalConditionType im Modell lokalisiert. In Abbildung 24 aus Abschnitt 5.2.1 ist StopCondition die Instanz eines PhysicalConditionType der Variable NC_Program_Status. Stimmt der Wert der Bedingung (im Beispiel Stop) mit dem neuen Wert überein wird eine Veränderungsanfrage (Change Request) bezüglich der Bedingung an die Planungsphase übergeben. Die Übereinstimmung, festgestellt in der Analyse, ist nicht auf die Gleichheit der Werte beschränkt. Mit Verwendung beliebiger Variablentypen der UA-Spezifikation können numerische Werte, Zeichenketten und strukturelle Attribute wie Wertebereiche oder Zeitstempel verglichen werden.
So kann MAPE-K beispielsweise die Temperatur eines Werkzeugs für normalen Betrieb und Störfall unterscheiden, indem die Wertebereiche (UA-Datentyp Range) in entsprechenden PhysicalConditionType-Variablen festgehalten werden. Eine Veränderungsanfrage beinhaltet die geltende Bedingung, durch die wiederum HasPhysicalAction-Referenzen auf UA-Methoden verweisen (vgl. Abschnitt 5.2.1). In der Planung werden diese Referenzen aufgelöst und sich dahinter verbergenden UA-Methoden an die Ausführungsphase übergeben. Als Wissensbasis für die einzelnen Schritte der Schleife wird das Informationsmodell mit dem Zustand der Anlage und den ECA-Regeln genutzt (vgl. Abschnitt 5.2.1).

5.4 Softwareframework

In diesem Kapitel wird das besprochene Konzept der virtuellen Maschinenrepräsentation in einem Softwareframework umgesetzt, welches die Remote Terminal Unit von Moctezuma et al. implementiert [53]. Ein Framework ist ein komplexes Software-System, welches sich Konzepten der Vererbung objektorientierter Programmierung und dynamischen Bindens von Bausteinen bedient. Es zeichnet sich durch externe Schnittstellen, Variabilität und -erweiterbarkeit aus und besteht aus abgeschlossenen und halbfertigen Elementen. Die übergeordnete Architektur, respektive die Komposition und Interaktion der Bausteine, ist vordefiniert und wird nicht verändert. Auf der anderen Seite stehen Aspekte der spezifischen Anwendungsdomäne die bei dem Entwurf einer Software nicht antizipiert werden können und an das Framework in Form von Zusatzmodulen anzubinden sind (vgl. zu diesem Absatz [66]).

Zur besseren Unterscheidbarkeit werden in diesem Abschnitt Instanzen kursiv und Informationsmodellelemente nichtproportional formatiert. In den Sequenzdiagrammen sind die Instanzen von Komponenten rechteckig und Erweiterungspunkte, beziehungsweise Entitäten als Kreis dargestellt.

5.4.1 Logische Architektur

Die abgeschlossene drei-Schicht-Architektur des Frameworks der virtuellen Maschinenrepräsentation (VMR) ist in Abbildung 29 dargestellt. Auf der Smart Connection, beziehungsweise Interface Ebene, wird der Signalaustausch mit der Altanlage vermittelt und eine einheitliche Schnittstelle bereitgestellt (vgl. Abschnitt 5.3.1). Dies wird durch mehrere cyber-physische Adapter (CPA) bewerkstelligt. Die physischen Kontextdaten und -manipulationsbefehle werden durch die Modellkontrollkomponente konsumiert, prozessiert und produziert (vgl. Abschnitte 5.3.2, 5.3.3). Eine MAPE-K-Rückkopplungsschleife (vgl: Abschnitt 5.3.4) interagiert mit dieser. Für die Kommunikation der Informationen des Adapters bietet der Adressraum des Laufzeitmodells der VMR eine strukturelle Beschreibung der Anlage (vgl. Abschnitt 5.2). Ein UA-Server stellt dieses Modell durch das binäre Transportprotokoll bereit und vermittelt Information und Interaktion mit der .

Figure 29: Framework-Schichten und -Komponenten

5.4.1.0.1 Interface.

Auf dieser Schicht implementieren cyber-physische Adapter (CPA) die Anbindung an digitale/analoge Ein-/Ausgangssignale und serielle Schnittstellen (vgl. Abschnitt 5.3.1). Sie erfassen den physischen Kontext, vermitteln Manipulation und stellen die Daten der Maschine für die Modellkontrolle bereit. Durch die Heterogenität der Schnittstellen von Steuerungs- und Datenerfassungshardware müssen Adapter an das Framework gebunden werden können. Ob Direct Numerical Control (DNC), IO-Link oder einfach Sensorik (vgl. Abschnitt 2.1.1), wie schon bei Ferrolho et al. muss das jeweilige System gekapselt werden. [9, 48]. Diese Protokollkapselung, in Abbildung 29 ein Relay Actuator, implementieren den Erweiterungspunkt des jeweiligen Signaltyps des CPA. Neben der Software benötigt ein CPA zusätzliche Hardware und die entsprechende Anbindung durch Softwarebibliotheken der Ausführungsplattform.

5.4.1.0.2 Processing.

Die Model Control ist zentrale Komponente dieser Schicht und verantwortet die Verwaltung des Laufzeitmodells (vgl. Abschnitt 5.2.2). Jede von den CPA kommunizierte Veränderung wird hier in das UA-Informationsmodell geschrieben. Wird eine UA-Methode aufgerufen, delegiert Model Control dies an die jeweilige Implementierung. Die Implementierung des Erweiterungspunkts Equipment erlaubt die Abbildung der Logik einer automatisierten Maschinenkomponente. Sie beschreibt deren Methoden und Variablen und besteht aus einer oder mehreren Protokollkapselungen der Interface-Ebene. Im Beispiel der Abbildung 29 ist Physical Loading Door die Instanz des Abbilds der Ladetür einer Maschine und besteht aus einem digital angebundenen Relais (Relay Actuator) für den Schließmechanismus Door_Lock (vgl. Abbildungen 22, 23 in Abschnitt 5.2.1). Die Model Control ist außerdem verantwortlich für die Initialisierung der VMR. Sie verbindet beim Start die in der Implementierung des Abbilds gekennzeichneten Variablen und Methoden mit dem Laufzeitmodell. Welche Implementierung für das Abbild geladen wird, beschreiben die Erweiterungen OPC4Factory und CPPS (vgl. Abbildung 22 in Abschnitt 5.2.1) im Informationsmodell. Wird im Modell der Maschine beispielsweise eine Instanz eines PhysicalLoadingDoorType gefunden, lädt Model Control die Implementierung dieses Typs und initialisiert sie mit den Informationen des ConnectionIdentifier von PhysicalConnectionType (vgl. Abbildung 23 in Abschnitt 5.2.1). Die Verknüpfung zwischen Implementierung und Modelldefinition kann durch Namenskonvention oder Annotationen in der jeweiligen Programmiersprache erfolgen.
Für die Rückkopplung ist Feedback Control verantwortlich. Beim Initialisieren des Modells werden die Variablen der Abbilder von Maschinenkomponenten an die Implementierungen von Equipment gebunden. Für jede Variable überprüft Feedback Control die Existenz von Instanzen des PhysicalConditionType und evaluiert die Bedingung (vgl. Abbildung 24 in Abschnitt 5.2.1). Jede Wertänderung löst eine Iteration der MAPE-K Kontrollschleife aus und führt schlussendlich zur Ausführung einer oder mehrerer UA-Methoden.

5.4.1.0.3 Communication.

Beim Start der VMR wird der UA-Server mit den internen Modellen (VMR Models) aus Abschnitt 5.2.1 und den Instanzen einer externen Strukturbeschreibung der Anlage (Machine Definition) initialisiert (vgl. Abbildung 30). Konfigurationsparameter zur Initialisierung des Servers sind statisch und müssen nach der Auslieferung der Software festgelegt werden. Neben denen der vorausgesetzten Netzwerkanbindung wird der Middleware die Referenz auf eine Datei mit der Machine Definition übergeben (vgl. Abbildung 25 in Abschnitt 5.2.2). Diese, wie auch alle Modellerweiterungen, liegt im XML-Format vor und enthält die Knoten des Informationsmodells und ihre Verbindungen (UANodeSet). Für die Modellierung der Machine Definition kann die Software UaModeler³³ eingesetzt werden. Mit dem binären Transportprotokoll der UA kommuniziert der Server die von Model Control gepflegten Informationen im Laufzeitmodell an andere Maschinen und Nutzungsschnittstellen.

Figure 30: Zusammensetzung des Adressraums der VMR

5.4.2 Verhalten zur Laufzeit

Die logische Architektur vorausgesetzt, beschreibt dieser Abschnitt das Verhalten der virtuellen Maschinenrepräsentation (VMR) zur Laufzeit. Interaktion und Kommunikation in den auftretenden Situationen werden durch Sequenzdiagramme veranschaulicht. Es wird angenommen, dass die VMR in ein Netzwerk integriert ist und uneingeschränkt mit UA-Clients kommunizieren kann.

5.4.2.0.1 Initialisierung

Figure 31: Initialisierung des Frameworks

Voraussetzung für die Initialisierung der VMR ist eine mit der Middleware ausgelieferte Machine Definition. Die Model Control startet den UA-Server mit dieser als Parameter, dargestellt in Abbildung 31 (1). Danach werden die cyber-physischen Adapter (CPA) instantiiert und etwaige Hardwarekomponenten für die Anbindung der Signale initialisiert (2). Der UA-Server kreiert den Adressraum (3), beziehungsweise das Laufzeitmodell der VMR, und lädt die Modelle (4). Ist das Informationsmodell vollständig geladen, sendet der Server das entsprechende Signal (5) und die Model Control sucht nach dem für die Anlage definierten Equipment (5.1). Für jede im Informationsmodell gefundene, automatisierte Werkzeugkomponente wird nun die Implementierung gesucht (5.3). Dem bereits angesprochenen Beispiel einer Ladetür (Physical Loading Door, vgl. Abbildung 29 in Abschnitt 5.4.1) ist wenigstens ein Relais (Relay Actuator) für den Schließmechanismus Door_Lock untergeordnet. Diese Ausprägungen des PhysicalConnectionType halten die Informationen zur Instanziierung der Implementierung in einem ConnectionIdentifier-Attribut und werden aus dem Modell geladen (5.4, vgl. Abschnitt 5.2.1). Nun kann Physical Loading Door instanziiert und dessen Logik, respektive Variablen und Methoden, an den UA-Server gebunden werden (5.6). Für die horizontale Integration der VMR muss sich der Server mit einem der in Abschnitt 5.3.2 vorgestellen Discovery-Mechanismen in das Produktionssystem eingliedern.

5.4.2.0.2 Methodendelegation.

Durch die horizontale Integration, beschrieben in
Abschnitt 5.3.2, kann eine Anlage oder Nutzungsschnittstelle die Methoden der VMR aufrufen. Dafür nimmt der UA-Server die Anfrage des jeweiligen Clients entgegen und leitet sie an die Model Control weiter. Das Beispiel der Ladetür mit einem Relais für den Schließmechanismus ist in Abbildung 32 (1) dargestellt. Daraufhin wird die mit der Methode gebundene Implementation der automatisierten Werkzeugkomponente identifiziert (1.1). Ein Zuordnung dieser Art kann durch Maps, also Listen von Schlüssel-Wert-Paaren oder das Beobachter-Muster (Observer) umgesetzt werden. Im Beispiel delegiert Model Control den Aufruf an Physical Loading Door – Instanz des PhysicalLoadingDoorType (1.2). Diese führt die Logik zum Schließen des Relais aus (1.2.1), wobei die physische Adresse des Aktuators aus dem ConnectionIdentifier des Informationsmodells stammt (vgl. Abschnitt 5.2.1). Ein cyber-physischer Adapter (CPA) übermittel ein digitales Signal (1.2.1.1) an die Instanz der Relay Actuator-Erweiterung des digital I/O, der Teil des Equipments ist (vgl. Abbildung 29). Mit dem Methodenaufruf der Physical Loading Door an die CPA lässt sich die physische Umsetzung nicht verifizieren, da der Relay Actuator keine Bestätigung der Aktion zurückgibt. Das Prüfen der Wirkung dieser asynchronen Methoden muss durch cyber-physische Rückkopplung geschehen (vgl. Abschnitt 5.3.4).

Figure 32: Methodendelegation im Framework

5.4.2.0.3 Kontextveränderung.

Mit der VMR verbundene UA-Clients können den physischen Zustand der VMR einsehen. Dieser wird durch Variablen repräsentiert, die stetig im Laufzeitmodell aktualisiert werden (vgl. Abschnitt 5.2.2). In Abbildung 33 ist die Aktualisierung eines Kontaktsensors als Teil der Ladetür einer Anlage beschrieben. Der Contact Sensor sendet die Veränderung seines Zustands digital an die CPA (1). Sie fragt bei der Model Control nach der für die Adresse des Sensors zuständigen Implementierung (1.1) und vermittelt den neuen Status an die Instanz des Equipments (1.3). Die Physical Loading Door gibt die Veränderung der Variable an Model Control zurück (1.3.1), die das Model schlussendlich aktualisiert (1.3.1.1). Eine optionale Verarbeitungslogik innerhalb der Physical Loading Door nach 1.3 ist in diesem Diagramm nicht dargestellt.

Figure 33: Kontextveränderungen im Framework

5.4.2.0.4 Rückkopplung.

Nicht zuletzt wegen der asynchronen Befehle an Aktuatoren hinter der CPA, muss Rückkopplung gewährleistet werden (vgl. Abschnitt 5.3.4). Beispielsweise kann die Interaktion zwischen einer Ladetür und der numerischen Steuerung abgebildet werden. Dafür notwendige Regeln werden in imperativer Form im Informationsmodell hinterlegt (vgl. Abschnitt 5.2.1) und zur Laufzeit von der Feedback Control evaluiert. Wird eine Variable wie NC_Program_Status geändert, zum Beispiel weil die CNC-Werkzeugmaschine den Fertigungsschritt abgeschlossen hat, beginnt die Feedback Control die Analyse der MAPE-K-Schleife (vgl. Abbildung 34, 1). Nach dem Einholen der Instanzen des PhysicalConditionType im Laufzeitmodell (1.1), wird der Wert dieser gelesen und mit dem der Variable verglichen (1.3). So würde das Ende der CNC-Operation durch den Wert Stop in NC_Program_Status angezeigt. Dieser Wert entspricht nun dem der StopCondition, wodurch die Bedingung erfüllt ist (vgl. Abbildung 24 in Abschnitt 5.2.1). Die Feedback Control aggregiert dann die Methoden hinter der HasPhysicalAction-Referenz im Laufzeitmodell (1.4) und überlässt der Model Control die Ausführung (1.6). Im Beispiel würde die Open_Door-Methode aufgerufen, womit die Ladetür nach abgeschlossener Fertigung geöffnet wird.

Figure 34: Cyber-physische Rückkopplung im Framework

5.4.3 Organisation

Die interne Organisation der Komponenten des Frameworks wurde in Abschnitt 5.4.1 besprochen. In diesem Abschnitt wird beschrieben, wie die Komponenten seitens der Softwarestruktur organisiert sind.

Figure 35: Organisation des Frameworks

Grundsätzlich bestehen die Komponenten aus Klassen einer objektorientierten Programmiersprache, die auf mehrere Pakete aufgeteilt sind, dargestellt in Abbildung 35. Das Framework der virtuellen Maschinenrepräsentation (VMR), als oberstes Hierarchieelement, beinhaltet die Schichten Communication, Processing und Interface. Erstere, zuständig für die Kommunikation mit anderen Anlagen und Nutzungsschnittstellen auf Feldebene, benötigt eine Implementierung der UA-Spezifikation Data Access (OPC UA Part 8³⁴) und des binären Transportprotokolls. Zur Anbindung von Variablen und Methoden ist sie abhängig von der Processing-Schicht, die deren strukturelle und logische Beschreibung, beziehungsweise Implementierung, kapselt. Für diesen Equipment-Erweiterungspunkt existiert eine dedizierte Softwarebibliothek, in Abbildung 35 Equipment Extensions genannt, die die Implementierungen (Physical Loading Door) der UA-Objecttypen (PhysicalLoadingDoorType) beinhaltet. Das Equipment (Physical Loading Door) besteht aus Sensoren (Contact Sensor) und Aktuatoren (Relay Actuator), die als Interface-Erweiterungspunkte in der Bibliothek Interface Extensions abgelegt werden. Da cyber-physische Adapter (CPA) zusätzliche Hardware benötigen, existiert eine Abhängigkeit zu den jeweiligen Bibliotheken im Paket Hardware Bindings. Die Klassen des Equipments bezeichnen Methoden und Variablen durch Konvention analog zu denen des Informationsmodells. Gleiches gilt für die Namen der Klassen selbst. Beinhaltet beispielsweise die Instanz (Loading_Door) einer Ladetür (PhysicalLoadingDoorType) laut Modell die Methode Open_Door, besitzt die Klasse PhysicalLoadingDoorType deren gleichnamige Implementierung.
Eine gesonderte Rolle spielen die Pakete des Stereotyps testSuite. Sie beinhalten Unit-Testfälle für die Equipment- und Interface-Implementierungen und verifizieren deren Funktionalität. Während diese nur bestimmte Teile des Frameworks überprüfen, bieten Integrationstests einen vertikalen Durchstich. Mit der Implementierung eines UA-Clients können sie zur VMR verbinden und das korrekte Zusammenspiel von Methodenaufrufen, Kontextveränderungen und Rückkopplung im Bezug auf ein ganzheitliches Anlagenmodell testen.

5.4.4 Verteilung

Wird nun eine konkrete Anlage modernisiert, muss die physische Verteilung der Bausteine des Frameworks festgelegt werden. Es existiert ein Anlagenmodell, die entsprechenden Erweiterungen wurden implementiert und Unit- und Integrationstests verifizieren die virtuelle Maschinenrepräsentation (VMR) als als Anwendungssoftware.

Figure 36: Verteilung des Frameworks

Abbildung 36 zeigt die Verteilung der Soft- und Hardwareartefakte an der Altanlage. Zentrales Element ist ein Einplatinencomputer (Single Board Computer, SBC), der eine serielle Schnittstelle bietet und einen Netzwerkanschluss benötigt. Er ist starr, z.B. via USB oder serieller Schnittstelle, mit einem oder mehreren Hardwarekomponenten für die cyber-physischen Adapter (CPA) verbunden. Diese bieten die Schnittstellen für Sensoren, Aktuatoren oder andere Geräte mit digitaler und analoger Ein- und Ausgabe. Die VMR wird auf dem Einplatinencomputer gespeichert und ist auf eine Anlagendefinition angewiesen. Für die Ausführung wird eine, der Implementierung entsprechende Laufzeitumgebung, vorausgesetzt. Das Anlagenmodell ist, je nach verwendeten Typen automatisierter Werkzeugkomponenten (PhysicalLoadingDoorType), abhängig von den Implementierungen des Equipments. Letzteres ist wiederum auf die jeweiligen Interface-Erweiterungen angewiesen.

6 Implementation

Der Entwurf der virtuellen Maschinenrepräsentation (VMR) wurde im vorangegangenen Kapitel vorgestellt. Nach der Design Science Research Methodology (vgl. Abschnitt 1.3) wird nun die Eignung des Konzepts anhand einer prototypischen Implementierung des Frameworks beschrieben. Neben verwendeten Technologien sind die technischen Details folgenden Beispiels im Fokus dieses Kapitels.

Die CNC-Drehmaschine aus dem Szenario S2 in Abschnitt 5.1.1 bietet eine anschauliche Grundlage für die exemplarische Anwendung der prototypischen Entwicklung. Sie besitzt eine serielle Schnittstelle für die Direct Numeric Control (DNC) der Antriebssteuerung, soll durch die VMR gekapselt und durch cyber-physische Rückkopplung zusätzlich automatisiert werden. In Abschnitt 4.1 wurden indirekte Überwachungsmethoden, auch mit Temperatursensorik, diskutiert. Im hier beschriebenen Beispiel soll die CNC angehalten und die Ladetür geöffnet werden, wenn die Temperatur des Werkzeugs der Drehmaschine einen kritischen Wert überschreitet.

6.1 Verwendete Hard- und Software

Benötigt wird ein Einplatinencomputer als Server für die VMR, eine Antriebssteuerung mit DNC sowie die Hardware für einen cyber-physischen Adapter (CPA). Temperatursensor und Relais, für den Verriegelungsmechanismus der Ladetür, müssen analoge und digitale Signale mit der CPA-Hardware austauschen können. Alle Hardwarekomponenten zur Umsetzung sind in Tabelle 2 zusammengestellt.

Der Raspberry Pi ist ein Einplatinencomputer der Ethernetanschluss, Wireless LAN Modul und USB Steckplätze, auch geeignet für serielle Kommunikation, besitzt. Er ist via USB direkt mit dem Smoothieboard verbunden. Das Smoothieboard 4XC ist ein Open Source Hardware CNC-Controller, der seriell CNC-Befehle aber auch ganze Programme entgegennimmt und für vier Schrittmotortreiber und Spindelkontrolle interpretiert (vgl. Abschnitt 2.1.2). Für die CPA-Hardware ist das GrovePi Erweiterungsboard für den Raspberry Pi geeignet. Es vereinheitlicht die Schnittstelle zu digitalen und analogen Sensoren und Aktuatoren des Grove-Systems für modulares, standardisiertes Prototyping⁴⁰. Die Messung der Temperatur am Werkzeug der Drehmaschine wird mit einem kombinierten Temperatur- und Luftfeuchtigkeitssensor des Grove-Systems vorgenommen. Der Verriegelungsmechanismus der Ladetür wird mit einem entsprechenden Relais realisiert.

Das VMR-Framework wurde mit serverseitigem JavaScript auf Basis von Node.js⁴¹ entwickelt. JavaScript ist, im Gegensatz zu C++ und Java, eine dynamisch typisierte Programmiersprache und wird primär für die Entwicklung von Nutzungsschnittstellen verwendet. Durch die serverseitige Plattform Node.js etablierte sie sich auch im Backendbereich. Mit der ursprünglich von Google entwickelten Laufzeitumgebung V8⁴² ist sie auf einem Einplatinencomputer ausreichend leistungsfähig (vgl. [67]). Da JavaScript kein objektorientiertes Konzept verfolgt, wurde mit CoffeeScript⁴³ eine ergänzende Skriptsprache gewählt, die in JavaScript übersetzt und damit nicht zur Laufzeit interpretiert werden muss. Werkzeuge zur Modellierung des OPC UA Adressraums verwenden Codegenerierung für eine schablonenartige Struktur der Implementierung von Laufzeitlogik (z.B. der UaModeler⁴⁴ von Unified Automation). Dieser Schritt ist durch die Verwendung einer dynamisch typisierten Programmiersprache nicht notwendig und komprimiert das endgültige Softwareprodukt. Die aus dem Modellierungswerkzeug exportierte XML wird von der VMR gelesen und dynamisch mit den Implementierungen verbunden (vgl. Abschnitt 6.3). Durch das Ökosystem von Node.js steht der Node Package Manager⁴⁵ mit quelloffenen Softwarebibliotheken zur Verfügung. Eine Auflistung der wichtigsten verwendeten ist in Tabelle 3 beschrieben⁴⁶.

Das Projekt node-opcua implementiert den Großteil des OPC UA Stacks in JavaScript. Auf dessen GitHub-Seite⁴⁷ ist eine Tabelle mit dem Grad der Umsetzung der Spezifikationen dargestellt. Im Zuge dieser Arbeit wurde zu dem Projekt beigetragen. Zu dem GrovePi-Erweiterungsboard existiert eine Entwicklungsbibliothek für mehrere Programmiersprachen. JavaScript mit Node.js wird vollständig durch das Paket node-grovepi unterstützt. Mitgeliefert werden grundsätzliche Implementierungen für analoge und digitale Sensoren und Aktuatoren, sowie das I2C-Bussystem⁴⁸ für die Kommunikation zwischen integrierten Schaltungen. Die Umsetzung des Prototypen der VMR wird weiterhin durch eine Bibliothek für die serielle Kommunikation (serialport), das Überwachen von Variablen und Objekten in JavaScript (watchjs) und Test-Bibliotheken (mocha, chai) ergänzt.

6.2 Laufzeitmodell und Erweiterungspunkte

Für die Umsetzung des Beispiels vom Anfang dieses Kapitels wurde ein OPC UA Modell der CNC-Werkzeugmaschine erstellt. Die für den Anwendungsfall relevanten Komponenten, Variablen und Methoden sind in Abbildung 37 dargestellt.

Figure 37: Laufzeitmodell des Prototypen

Im Modell besitzt die Drehmaschine eine Ladetür, eine NC-Steuerung und einen Sensor für die Temperatur des Werkzeugs. Letztere ist mit der Implementierung des Equipment-Erweiterungspunkts PhysicalToolTemperatureType verknüpft, die eine OPC UA Variable für die tatsächliche Temperatur am Werkzeug beschreibt. Unter dieser Variable organisiert ist mit OverheatCondition ein Bereich für diesen Wert definiert, der Überhitzung symbolisiert. Da node-opcua noch keine Unterstützung für spezialisierte Referenzen bietet, wird HasEffect, aus der Spezifikation von OPC UA, als Synonym zu HasPhysicalAction verwendet (vgl. Abschnitt 5.2.1). Feedback Control reagiert auf die Veränderung der Temperatur und löst Stop_NC aus, sobald die Bedingung zutrifft (vgl. Abschnitt 6.3). Nach der Methodenausführung ändert sich die Variable NC_Program_Status durch die Implementierung des PhysicalNCType. Mit der daraufhin zutreffenden StoppedCondition wird aufgrund der HasEffect-Referenz Open_Door ausgeführt. Die Instanz der PhysicalLoadingDoor schließt dann das Relais über den RelayActuator – eine abgeleitete Klasse des DigitalSensor der GrovePi-Bibliothek.

Um einen Equipment-Erweiterungspunkt zu laden, liest die Model Control alle Objekte des Pakets Processing Extensions (vgl. Abschnitt 5.4.3) und hält sie für die Bindung zu Modellelementen bereit. Exemplarisch ist der PhysicalLoadingDoorType in Listing ?? beschrieben. Damit die Model Control OPC UA Variablen und Methoden binden kann, werden diese mit einem Dollar-Zeichen am Anfang des Bezeichners markiert. Die Ladetür besitzt im Informationsmodell nach Ayatollahi et al. (vgl. Abschnitt 5.2.1) eine Variable Door_Status sowie die Methoden Close_Door und Open_Door, die auch die Implementierung aus Listing ?? deklariert (Zeilen 3, 12 und 16). Sie beinhaltet den RelayActuator aus dem Paket Interface Extensions (vgl. Abschnitt 5.4.3), der mit den Parametern des ConnectionIdentifier (vgl. Abbildung 23 in Abschnitt 5.2.1) initialisiert wird (Zeile 6⁴⁹). In Zeile 8 wird die Ladetür mit dem Öffnen des Relais initialisiert. Die Methode $Close_Door – von der Model Control aufgerufen – delegiert die Anweisung an den RelayActuator und aktualisiert den Wert der Variablen $Door_Status.

class PhysicalLoadingDoorType

  $Door_Status: null

  constructor: (connectionIdentifier) ->
    @DoorLock = new RelayActuator connectionIdentifier.DoorLock.pin

    @onState  = 'closed'
    @offState = 'open'

    @$Open_Door()

  $Close_Door: =>
    @DoorLock.on()
    @$Door_Status = @onState

  $Open_Door: =>
    @DoorLock.off()
    @$Door_Status = @offState

Der Equipment-Erweiterungspunkt wird durch Definition im Modell und Namenskonvention im Paket Equipment Extensions an das Framework gebunden. Die Interface Extension hingegen durch Aggregation im jeweiligen Equipment und das Erben von Klassen der GrovePi-Bibliothek. In Listing ?? ist eine solche Spezialisierung von DigitalSensor dargestellt. Der RelayActuator ist eine Komponente der PhysicalLoadingDoor aus Listing ??. Zeile 4 deklariert den physischen Kommunikationskanal als ausgehend mit der Pin-Identifikation aus dem ConnectionIdentifier-Wert (vgl. Listing ?? Zeile 6). In den Zeilen 6 und 7 sind die Möglichkeiten des Aktuators beschrieben. Für das Öffnen und Schließen übergeben sie ein digitales Signal an die GrovePi-Implementierung.

class RelayActuator extends DigitalSensor

  constructor: (@pin) ->
    @board.pinMode @pin, @board.OUTPUT

  on:  => @write 1
  off: => @write 0

6.3 Umsetzung der Komponenten

Die Implementierungen der Erweiterungspunkte müssen nun an das Modell der Maschine gebunden werden. Model Control initialisiert, ähnlich wie in Abbildung 31 aus Abschnitt 5.4.2, das Modell. Das Binden einer automatisierten Werkzeugkomponente, zum Beispiel der Ladetür (LoadingDoor), mit seiner Equipment-Implementierung ist, bis auf Ausnahme- und Fehlerbehandlung, in Listing ?? dargestellt. Die bereits bekannten PhysicalConnections werden mit denen des Objekts abgeglichen (Zeilen 4 ff.) und der in JSON definierte ConnectionIdentifier-Wert geladen (Zeile 8). Im Beispiel ist {"pin":7} der Wert für die Deklaration der Nummer der Steckverbindung des GrovePi-Erweiterungsboards für das Relais. Der typeNode aus Zeile 10 beschreibt den Equipmenttyp des Laufzeitmodells, dessen Name die Implementierung (PhysicalLoadingDoorType) identifiziert. Diese wird in Zeile 13 instanziiert und durch das Objekt referenziert. In den Zeilen 15-19 werden nun die OPC UA Methoden und Variablen mit deren Implementierung verknüpft (vgl. Abschnitt 6.2). Für die Rückkopplung wird beim Binden der Variablen, zum Beispiel NC_Program_Status as Abbildung 37, listenTo der Feedback Control mit einer Referenz auf die Variable aufgerufen.

bind: (object) =>
  conns = {}

  for conn in @physicalConnections
    if object.nodeId == conn.parent.nodeId
      connName = conn.browseName.name
      connIdentifier = @valueOf conn.connectionIdentifier
      conns[connName] = JSON.parse connIdentifier

  typeNode = @addressSpace.findNode object.typeDefinition
  typeName = typeNode.browseName.name

  object.instance = new equipment[typeName](conns)

  if not @methodsOf(object.instance).isEmpty()
    @bindMethodsTo object

  if not @variablesOf(object.instance).isEmpty() 
    @bindVariablesTo object

Ein Auszug der Feedback Control in Listing ?? beschreibt die Implementierung der Phasen von MAPE-K (vgl. Abschnitt 5.3.4). Für das Monitoring werden zuerst alle Variablenzustände (PhysicalCondition) identifiziert. Besitzt die Variable mindestens einen zu verarbeitenden Zustand, wird sie mittels watchjs überwacht (Zeile 5). Der letzte Parameter der Methode watch ist ein Callback für den Fall der Veränderung. Innerhalb dessen iteriert Feedback Control über die möglichen Variablenzustände und überprüft (Analyze-Phase) ihre Qualifikation für den nächsten Schritt (Zeilen 6-7). In der Plan-Phase werden über die HasEffect-Referenz verbundene OPC UA Methoden gesucht und schlussendlich ausgeführt (Execute, Zeile 8). hasBeenMet führt eine Fallunterscheidung nach dem Typ der PhysicalCondition durch. Bei booleschem Typ, Zeichenketten und anderen atomaren Werten wird ein einfacher Abgleich mit dem tatsächlichen Zustand durchgeführt – Wert der Bedingung entspricht dem Wert der Variablen. Im eingangs beschriebenen Beispiel wird der Wert Stop der Variable NC_Program_Status mit dem Wert der StoppedCondition verglichen und gegebenenfalls die Methode Open_Door der LoadingDoor aufgerufen (vgl. Abbildung 37). Der andere Ausgang der Fallunterscheidung von hasBeenMet ist durch den kritischen Temperaturbereich des OPC UA Typs Range abgedeckt. In diesem Fall wird überprüft, ob der tatsächliche Zustand (Temperature) innerhalb dieses Bereichs (OverheatCondition) liegt.

listenTo: (addressSpaceVariable, variable, equipment) =>
  # [...] find physical conditions

  if not physicalConditions.isEmpty()
    watch equipment, variable, () => 
      for condition in physicalConditions
        if @hasBeenMet(condition, addressSpaceVariable)
          @findAndExecuteActionFor condition

Die Implementierung der cyber-physischen Adapter und des OPC UA Servers sind delegierende Fassaden (Wrapper) um die Bibliotheken node-grovepi und node-opcua und können im Quellcode des Prototypen⁵⁰ nachgeschlagen werden.

6.4 Softwaretests für Erweiterungspunkte

Die Implementierung des Frameworks kann durch Unit- und Integrationstests überprüft werden. Da sie sich als Kern der virtuellen Maschinenrepräsentation (VMR) kaum verändert, werden diese Tests einmalig definiert. Interessanter sind die Erweiterungspunkte, die stetig wachsend, einem kontinuierlichen Testzyklus unterliegen müssen. Um das logische Verhalten der Implementierung von Equipment vor dem operativen Einsatz zu verifizieren, werden Unit-Tests wie in Listing ?? eingesetzt. Mit mocha als JavaScript Test-Framework und chai für die Assertions (Annahmen) kann das Verhalten des Equipments beschrieben werden. Die describe-Funktionen der Zeilen 1-2 definieren einen Kontext für die eigentlichen Tests, welche mit it (Zeilen 4, 7 und 11) und einem passenden Bezeichner definiert werden.
Im ersten Testfall (Zeilen 4-5) des PhysicalNCType soll der Start der numerischen Kontrolle in einem OPC UA Status-Code für ungültige Zustände münden, falls kein Programm für die Werkzeugmaschine festgelegt wurde. Die Variable its hält dabei eine Instanz der zu testenden Implementierung. Im zweiten Fall (Zeilen 7-9) schlägt der Start aufgrund einer bereits laufenden Programmausführung fehl. Dafür wird die Variable $NC_Program_Status auf Active gesetzt, $Start_NC aufgerufen und der ungültige Zustand festgestellt. Da PhysicalNCType vom SmoothieboardActuator der Interface Extensions abhängt, müssen Hilfskonstruktionen zur Überwachung der internen Methodenaufrufe an andere Objekte verwendet werden. In Zeile 12 wird dafür ein Spion auf die Methode start des SmoothieboardActuator angesetzt und der aktuelle Zustand festgelegt (Zeile 13). Die Ausführung von $Start_NC (Zeile 14) muss dann in einem Aufruf der Startfunktion des Aktuators münden.

describe 'PhysicalNCType', ->
  describe 'operation start', -> 

    it 'should fail without a program assigned', ->
      its.$Start_NC().statusCode.should.equal status.BadInvalidState

    it 'should fail when already active', ->
      its.$NC_Program_Status = 'Active'
      its.$Start_NC().statusCode.should.equal status.BadInvalidState

    it 'should succeed if inactive and assigned program', ->
      start = chai.spy.on its.SmoothieboardActuator, 'start'
      its.$NC_Program = 'test'
      its.$Start_NC()
      start.should.have.been.called.with 'test'

Das oben beschriebene Prinzip kann auf die Implementierungen des Interface Extension Pakets angewendet werden. Da die GrovePi-Bibliothek getestete Implementierungen für die meisten Sensoren und Aktuatoren bereitstellt, reduziert sich der Aufwand und wird hier nicht näher beschrieben. Spezielle Erweiterungen wie der SmoothieboardActuator oder dessen Abhängigkeit vom SerialPort müssen ebenfalls validiert werden, was kein Teil der prototypischen Umsetzung ist.
Integrations- sind den Unit-Tests ähnlich, greifen aber nicht auf die konkrete Implementierung zurück, sondern validieren das Verhalten der VMR mit der Perspektive eines OPC UA Clients.

7 Evaluation

Mit der Umsetzung des Konzepts in einem Framework mit prototypischer Entwicklung wird eine Möglichkeit zur Integration von Altanlagen in ein cyber-physisches Produktionssystem (CPPS) aufgezeigt. Die Demonstration des Entwurfs nach der Design Science Research Methodology (vgl. [16]) wurde im vorangegangenen Kapitel geschildert und benötigt eine evaluative Analyse. Dafür werden nun die Anforderungen und Ziele mit dem Konzept der virtuellen Maschinenrepräsentation verglichen. Da bestehende Forschung Teilprobleme der in Abschnitt 1 vorgestellten bereits gelöst hat, wird ein Vergleich gezogen um den Mehrwert dieser Arbeit herauszustellen. Abschließend werden die Ergebnisse und Limitationen vor einem Ausblick auf mögliche Folgeuntersuchungen erläutert.

7.1 Anforderungen und Ziele

Für die Modernisierung von Altanlagen sind in Abschnitt 3 Anforderungen aufgestellt, die mit dem vorgestellten Konzept abgeglichen werden.

Für die Überwachung von Betriebs- und Prozessdaten der Maschine wird Ortsunabhängigkeit gefordert (vgl. Abschnitt 3.1). Durch die Verwendung von OPC UA auf Feldebene und Web-Services für übergeordnete Dienste kann die Anlage mittels entsprechender Clients nahtlos überwacht werden (vgl. Abschnitt 5.3.2). Eine vollständige Abbildung der Anlagenstruktur im Informationsmodell erlaubt die Hierarchisierung der automatisierten Werkzeugkomponenten und liefert ein ganzheitliches Bild für Maschinenbediener und Subsysteme der cyber-physischen Produktionsumgebung, beschrieben in Abschnitt 5.2.1.
Auch die Steuerung von Altanlagen soll ortsunabhängig möglich sein (vgl. Abschnitt 3.2). Wie bei der Überwachung ist OPC UA das Bindeglied zwischen der VMR, Nutzungsschnittstelle und Subsystemen des CPPS. Mit der Erweiterung des Konzepts von Ayatollahi et al. ist die entfernte Steuerung der Maschine möglich und erlaubt beispielsweise das Eingreifen in den operativen Betrieb einer CNC-Werkzeugmaschine.
Die Modernisierung der Anlage wird auf Basis etablierter Standards ermöglicht (vgl. Abschnitt 3.3). Horizontal wie vertikal wird die Integration durch OPC UA beziehungsweise Web-Services bewerkstelligt. Damit ist die Datenaggregation und Kommunikation der Maschinen untereinander gesamtheitlich möglich.
Ein Großteil der Datenverarbeitung und -analyse soll den Anforderungen nach geographisch nahe der Maschine geschehen (vgl. Abschnitt 3.4). Die VMR kann Signale der angeschlossenen Peripherie in Informationen umwandeln, um sie anderen Feldgeräten sowie Nutzungsschnittstellen und übergeordneten Diensten zur Verfügung zu stellen (vgl. Abschnitt 5.3). OPC UA ermöglicht außerdem eine lokale Historie. Darüber hinaus ist eine interne Rückkopplungsschleife verantwortlich für die Kapselung bestimmter Automatisierungslogik und reagiert autonom auf veränderte Bedingungen (vgl. Abschnitt 5.3.4).
Ökonomische Aspekte sind relevant für Retrofitting, weswegen die Forderung nach kostengünstiger Integrationshardware besteht (vgl. Abschnitt 3.5). In der Umsetzung der VMR wird der Einplatinencomputer Raspberry Pi verwendet, womit auch die letzte Anforderung dieser Arbeit vollständig erfüllt ist (vgl. Abschnitt 6).

Im Bezug auf die in Abschnitt 1.2 beschriebenen Ziele verhält sich das vorgestellte Konzept wie folgt. Die entfernte Kontrolle der Altmaschine wird durch die Kapselung mit einer VMR bewerkstelligt. Somit werden manuelle Tätigkeiten gemindert, die Automatisierung erweitert und schlussendlich der übergeordnete Produktionsablauf beschleunigt. Prozess- und Produktionsdaten können durch eine Nutzungsschnittstelle zentral ausgewertet werden. Die in der prototypischen Umsetzung verwendete Nutzungsschnittstelle ist der OPC UA Client UaExpert⁵¹ von Unified Automation. Diagnosen in Ausnahmesituationen und bei Störfällen können mit diesem Client ortsunabhängig und zentral gestellt werden. Mit OPC UA verwendet die VMR eine dezentrale Kommunikations- und Informationsarchitektur, einhergehend mit der Verbesserung von Produktionsstabilität, Skalierbarkeit und Rekonfiguration (vgl. Abschnitte 5.3.2, 5.3.3). Durch die starke Verbreitung von OPC UA (vgl. [27]) wird die M2M-Kommunikation, beziehungsweise der Informationsaustausch der Anlagen untereinander, nahtlos gewährleistet. Für die Modellierung der Anlagenstruktur und Regeln für die Rückkopplung kann durchgängig ein einziges Werkzeug, wie der UaModeler⁵², verwendet werden (vgl. Abschnitt 5.2.1). Auch das Austauschformat der Modelle unterliegt, mit XML und Schemadefinition⁵³ der OPC Foundation, einer Spezifikation der Unified .

7.2 Vergleich zum Forschungsstand

Für die Steuerung der Altanlage mit Direct Numerical Control (DNC) wird das Konzept von Ferrolho et al. vorgestellt (vgl. Abschnitt 4.2, [48]). Sie entwarfen ein Adapter-Framework für DNC im Kontext flexibler Fertigungszellen das ethernetbasierte Steuerung und Überwachung sowie Rückkopplung ermöglicht. Das in dieser Arbeit vorgestellte Konzept geht über die numerische Kontrolle innerhalb von Fertigungszellen hinaus und nutzt Kommunikationsstandards für eine durchgängige Integration (vgl. Abschnitt 5.3). Vorteilhaft hierbei ist die Allgemeingültigkeit und nahtlose Informationsübertragung durch einen etablierten Standard. Ayatollahi et al. nutzen ebenfalls DNC für die Kontrolle der Maschine, abstrahieren aber die Steuerungskommunikation durch ein standardisiertes Protokoll mit der Möglichkeit zur Modellierung der Anlagenstruktur [30]. Das Modell der VMR erweitert die Definitionen von Ayatollahi et al. für CPPS (vgl. Abschnitt 5.2.1). Neben der Maschine selbst können somit Regeln für die Rückkopplung und Teilautonomie direkt im Informationsmodell beschrieben werden. Ein Service-orientiertes Konzept für die abstrakte Kontrolle speicherprogrammierbarer Steuerungen (SPS) von Windmann et al. nutzt OPC UA und implementiert komplexe Logik durch einen Agenten direkt am Feldgerät [13]. Der von ihm vorgestellte Software-Agent ist wie die VMR für komplexe Prozesse und lokale Datenhaltung verantwortlich, beschränkt sich aber auf die Abstraktion von SPS.
Entfernte Kontrolle von CNC-Maschinen realisieren Wang et al. mit dem Wise-ShopFloor (vgl. Abschnitt 4.3, [5]). Mit einem Publish/Subscribe Mechanismus auf einer Client/Server Architektur ermöglichen sie auch komplexe Kommunikation innerhalb einer cyber-physischen Produktionsumgebung. Im Gegensatz zu dieser Arbeit liegt ihr Fokus auf der Nutzungsschnittstelle und Visualisierung operativer Produktion und nicht auf der Integration der Feldgeräte. Für gerade diese entwarfen Pauker et al. eine Architektur unter Berücksichtigung von Rekonfigurierbarkeit in flexiblen Fertigungszellen [22]. Die Vereinheitlichung von Schnittstellen sowie Rekonfigurierbarkeit auf Feldebene wird auch im horizontalen Integrationskonzept der VMR beachtet (vgl. Abschnitt 5.3.2). Im Unterschied zu dem Blackboard-Ansatz von Pauker et al. werden die Daten am Gerät persistiert und Instruktionen dezentral auf Basis eines Standards kommuniziert. Durch die dezentrale Persistenz wird die Ausfallsicherheit der Fertigungsstrecke erhöht.
Ein in die VMR einfließendes Konzept mit Schwerpunkt auf Anlagenmodernisierung entwickelten Moctezuma et al. [53]. Ihre dreischichtige Lösung mit Communication-, Processing- und Interface-Ebene ist ein Kernaspekt des in dieser Arbeit vorgestellten Frameworks (vgl. Abschnitt 5.3). Der Unterschied zur VMR liegt in der Verwendung von OPC UA für die horizontale Integration (vgl. Abschnitt 5.3.2). Eine Service-orientierte Architektur durch Web-Service Module ist hier Teil des Konzepts zur vertikalen Integration, wird im Entwurf des Frameworks jedoch nicht betrachtet. Diese Module werden von Dürkop et al. übernommen und setzen mit einer neuen Schicht auf der Feldebene auf [20]. Zwar verbindet OPC UA die beiden Ebenen, jedoch wird im Gegensatz zur VMR keine explizite Kommunikation zwischen den Modulen erlaubt. So wird mit der VMR der Informationsaustausch zwischen den Maschinen hierarchisiert und entlastet den Kommunikationskanal der Web-Services. Die abstrakte Perspektive auf CPPS wurde von Lee et al. entworfen [40]. An die mehrschichtige Struktur und Richtlinien für Architekturen von CPPS ist das VMR-Konzept angelehnt (vgl. Abschnitt 5.3.3). Dadurch ist die VMR für den produktiven Einsatz in Kontext der Industrie 4.0 geeignet.
Ein Unterschied zu allen betrachteten Forschungsarbeiten besteht in der Verwendung von Einplatinencomputern für die VMR und das Retrofitting von Altanlagen. Die Kosten dieser Geräte sind gering und verbessern dadurch die Wirtschaftlichkeit der Modernisierungsmaßnahmen. Grigoriev et al. untersuchten deren Tauglichkeit für die Steuerung von CNC-Maschinen, betrachten den Aspekt der Anlagenmodernisierung in CPPS jedoch nicht [14].

7.3 Ergebnisse

Neben den Anforderungen und Zielen wurden in der Einleitung Fragen formuliert, die durch den aktuellen Forschungsstand nicht ganzheitlich beantwortet werden. Im Ergebnis führen die Recherchen und der darauf aufbauende Entwurf der VMR zu folgendem Schluss.

7.3.0.0.1 System- und Softwarearchitektur.

Flexibles Retrofitting für die Steuerung und Überwachung von Fertigungsanlagen benötigt eine geschichtete System- und Softwarestruktur. Eingebettet in die 5C-Architektur von Lee et al. (vgl. Abschnitt 4.3) ist eine virtuelle Maschinenrepräsentation (VMR) verantwortlich für die Kapselung der Altanlage innerhalb eines ganzheitlichen cyber-physischen Produktionssystems (CPPS, vgl. Abschnitt 5.3). Sie konvertiert die feingranularen, technischen Signale der Maschine in semantische Informationen und abstrahiert die Steuerung automatisierter Werkzeugkomponenten mittels eines dedizierten Softwareframeworks (vgl. Abschnitt 5.4). Teilautonome Handlungsfähigkeit wird durch Rückkopplung der Signale in den operativen Betrieb innerhalb der VMR erreicht (vgl. Abschnitt 5.3.4).

7.3.0.0.2 Protokolle und Datenstrukturen.

Mit der Standardisierung horizontaler Kommunikation durch die etablierte OPC Unified Architecture, wird eine nahtlose Informationsübertragung zwischen modernen und modernisierten Werkzeugmaschinen und Steuerungen möglich (vgl. Abschnitt 5.3.2). Das Laufzeitmodell der Anlage ist durch das Informationsmodell der OPC UA beschrieben und mit dem Web-Service Modul nach Dürkop et al. an eine Service-orientierte Architektur mit dem DPWS-Standard gekoppelt (vgl. Abschnitte 5.2.2, 5.3.3). Durch diese Form der vertikalen Integration kann eine übergeordnete Produktionssteuerung den Fertigungsprozess abbilden (vgl. Abschnitt 5.3.3). Auf Feld- und Prozessebene ermöglicht die Anbindung entsprechender Nutzungsschnittstellen die zentrale Überwachung und .

7.3.0.0.3 Datenverarbeitung und -persistenz.

Neben Betriebsdaten und physischem Kontext der Altanlage werden Sensordaten direkt an der Maschine verarbeitet und durch das Konzept der Historie von OPC UA lokal persistiert (vgl. Abschnitt 5.3). Die Verarbeitung von Steuerungsinstruktionen in Form von OPC UA Methoden geschieht lokal und wird an cyber-physische Hardwareadapter delegiert (vgl. Abschnitte 5.2.1, 5.4).

7.4 Limitationen

Da die Komplexität der Integration von Altmaschinen in cyber-physische Produktionssysteme nicht durch eine wissenschaftliche Arbeit gelöst werden kann, bestehen Einschränkungen für Konzept und Umsetzung. Im direkt folgenden Ausblick des Abschnitt 7.5 werden Möglichkeiten des Aufhebens der Limitationen vorgestellt.
Durch die cyber-physische Rückkopplung in der VMR wird der Automatisierungsgrad erhöht (vgl. Abschnitt 5.3.4). Ein Laufzeitmodell enthält neben der Anlagenbeschreibung Regeln für die interne Rückkopplung, womit die VMR teilautonom agiert und online-Monitoring für Altmaschinen ermöglicht (vgl. Abschnitt 5.2.2). Diese Regeln, im Stil von Ereignis-Bedingung-Aktion (Event-Condition-Action, ECA), sind durch die Verwendung beliebiger OPC UA Datentypen sehr ausdrucksstark. Wie in der prototypischen Umsetzung gezeigt, können in der Bedingung (PhysicalCondition, vgl. Abschnitt 5.2.1) nicht nur skalare Werte, sondern auch Wertebereiche für einen Variablenzustand beschrieben werden. Durch die Softwarebibliothek node-opcua (vgl. Abschnitt 6) ist das Laden konstanter Werte aus dem Anlagenmodell bisher auf diese zwei Möglichkeiten beschränkt. Da OPC UA noch keine Echtzeitunterstützung bietet, wird die Formulierung zeitlicher Aspekte (z.B. numerische Kontrolle muss innerhalb einer Sekunde stoppen) nicht betrachtet. Bei Aufruf der Methoden hinter den HasPhysicalAction-Referenzen einer Bedingung, können mit der bisherigen Modellierung keine Parameter übergeben werden.
Logischen Verknüpfungen zwischen den Zuständen von automatisierten Werkzeugkomponenten (Equipment) können mit der vorgestellten Modellierungsmethode nicht hergestellt werden (vgl. Abschnitt 5.2.1). Die Verbindung von Regeln über ein logisches und beziehungsweise oder wird nicht unterstützt. Außerdem ist die ECA-Beschreibung imperativ. Wenn beispielsweise die numerische Kontrolle gestoppt wird, soll die Ladetür geöffnet werden. Die Rückkopplung könnte dann den Wert eines Kontaktsensors auswerten, um das erfolgreiche Öffnen der Tür zu prüfen. Eine deklarative Beschreibung dieses Problems mit einem Formalismus für Implikationen ist notwendig. Auch eine Kompensationsstrategie für den Fall der Inkonsistenz von Realität und virtuellem Modell, also die Verletzung einer Annahme über den Systemzustand, muss umgesetzt werden. Die imperativen Regeln der wenn-dann-Form im Informationsmodell der VMR leisten diese Art der Rückkopplung nicht. Außerdem existiert kein Konzept zur Lösung von Konflikten zwischen den ECA-Regeln, wodurch unter anderem ungewollte Schleifen auftreten können (vlg. [68]).

Bei der prototypischen Umsetzung werden Testfälle (vgl. Abschnitt 6.4) für Erweiterungen aus den Paketen Equipment Extension und Interface Extension (vgl. Abschnitt 5.4.3) exemplarisch erläutert. Für die Vollständigkeit der Softwaretests müssen Integrationstests ebenfalls detailliert beschrieben werden.
Der Abschnitt 5.3.1 geht auf die Technologien zur Kommunikation, nicht aber auf die genaue Erfassung der Daten und hardwareseitige Verknüpfung, zum Beispiel einer bestehenden Antriebssteuerung, ein. So wird die Verortung und konkrete Verdrahtung von Sensoren und Aktuatoren in diesem Konzept nicht besprochen. Dieses vielfältige Forschungsfeld geht über den Rahmen dieser Arbeit hinaus, wird aber in Abschnitt 4.1 referenziert. Ebenfalls außerhalb dieses Rahmens liegt eine Betrachtung der übergeordneten Produktionssteuerung als Teil der vertikalen Integration.
Neben den vorgestellten konzeptuellen Szenarien und Anwendungsfällen wurde ein Laborexperiment, aber keine Fallstudie oder quantitative Evaluation durchgeführt. Dennoch ermöglicht die vorliegende Arbeit eine realitätsnahe Konzeption unter Einbeziehung bestehender Integrationsumstände und betroffener .

7.5 Ausblick

Aufgrund des begrenzten inhaltlichen Rahmens, der Einschränkungen des Konzepts und der Komplexität des Problemraums Retrofitting, sind die Möglichkeiten anschließender Forschung vielfältig.

7.5.0.0.1 Selbstadaptive Prozesse.

Produktionssysteme durch cyber-physische Rückkopplung an der Maschine stärker zu automatisieren bedarf intelligenter Lösungen und sollte über eine imperative Regelbeschreibung und Ausführung hinausgehen. Cyber-physische Workflows besitzen das Potenzial die Komplexität der Rückkopplung in Prozessen innerhalb einer Altmaschine abzubilden. Seiger et al. untersuchten Selbstadaptivität in Prozessen unter Verwendung von MAPE-K Rückkopplungsschleifen, die eine Erweiterung für automatisierte Werkzeugkomponenten darstellen kann [36]. Die in diesem Zusammenhang beschriebene Process-Engine kann außerdem in das Konzept der vertikalen Integration eingebunden werden [37]. Auch externe Rückkopplungsschleifen auf der Cyber- und Configuration-Ebene der 5C-Architektur von Lee et al. können bezüglich übergeordneter Produktionssteuerung von selbstadaptiven Prozessen profitieren (vgl. [40]).

7.5.0.0.2 Vertikale Integration.

Die dafür notwendige Konkretisierung des Web-Service-Moduls der virtuellen Maschinenrepräsentation (VMR) hängt von der Interoperabilität von OPC UA und dem DPWS-Standard ab (vgl. Abschnitt 5.3.3). Bony et al. postulierten einen Ansatz für die Konvergenz der unterschiedlichen Modelle, welcher dafür detailliert beleuchtet werden kann [56]. Eine Variante für die Interoperabilität der beiden Standards, unter Verwendung von Complex Event Processing (CEP), beschrieben Izaguirre et al. [55]. Pauker et al. verwenden modellgetriebene Softwareentwicklung und beschreiben ein UML-Metamodell als Brücke zwischen heterogenen Gerätebeschreibungsstandards, die hier eine generische Alternative bietet [69]. Ebenfalls die Interoperabilität betreffend sollte AutomationML⁵⁴, ein standardisiertes XML-Format für den Austausch produktionstechnischer Daten und Anlagenbeschreibungen, bezüglich etwaiger Integration untersucht werden (vgl. [27]).

7.5.0.0.3 Anlagensteuerung.

OPC UA Methoden zur Steuerung von Altanlagen sind ein elementarer, imperativer Ansatz. Zustandsautomaten und Programs der Spezifikation können den Implementierungsaufwand einer automatisierten Werkzeugkomponente gegebenenfalls verringern und den Rückkopplungsmechanismus entlasten. Auch für CNC-Programme existiert mit STEP-NC eine zu evaluierende Alternative (vgl. [25, 70–72]). Leistungsfähigkeit und Optimierungspotential der Altanlage korrelieren mit der Programmierung, beziehungsweise mit dem einzelnen Befehl. Downey et al. verknüpfen die Befehle mit der Überwachung und ermöglichen damit die Rückkopplung parallel zum Fertigungsschritt [47]. Zu untersuchen wäre, inwiefern die VMR diese Informationen zur Verbesserung der Selbstadaptivität nutzen kann.

7.5.0.0.4 Echtzeitfähigkeit.

Die Echtzeitfähigkeit der Steuerung wird Antriebssystemen und spezialisierter Hardware überlassen. Seitens der OPC UA wird sie aktuell nicht unterstützt. Mit dem Aufkommen von Time Sensitive Networking⁵⁵ (TSN) sind Standardisierungsbemühungen im Gange, die Ethernet-Echtzeitsteuerung im Bezug auf die Automatisierungspyramide nach oben bewegen könnte und einer Untersuchung der Eignung für Retrofitting bedürfen.

7.5.0.0.5 Nutzungsschnittstellen.

Im Laborexperiment wurde ein grafischer OPC UA Client verwendet (vgl. Abschnitt 6). Mit diesem werden die Daten der Altanlage zentral visualisiert und der Aufruf von Methoden realisiert. Doch gerade für die Analyse von Fertigungsinformationen und -überwachung müssen Nutzungsschnittstellen abhängig vom Anwendungsfall implementiert werden. Der Wise-ShopFloor von Wang et al. fokussiert genau diese [5]. Mit einer OPC UA Schnittstelle könnte dieses Konzept mit der VMR als Informationsquelle und Steuerungsziel integriert werden. Aber auch andere Werkzeuge wie Kibana⁵⁶ unterstützen bei der zentralisierten Visualisierung großer Informationsmengen und wären ein Zugewinn bei der Analyse von Betriebs- und Prozessdaten der Altanlage, die dafür mit Elasticsearch⁵⁷ indexiert werden müssten.

7.5.0.0.6 Prototypische Evaluation.

Bezüglich einer quantitativ vergleichenden Evaluation wäre die VMR auf andere Einplatinencomputer zu übertragen. Auch Laborexperimente mit speicherprogrammierbaren Steuerungen könnten die Eignung des hier vorgestellten Konzepts weiter untermauern. Einen größeren Einblick in die Tauglichkeit des Retrofittings mit der VMR wäre mit einer Fallstudie an realen Produktionsanlagen gegeben.

8 Zusammenfassung

In Anlehnung an die Design Science Research Methodology (vgl. [16]) ist in dieser Arbeit ein Konzept für die Modernisierung von Altanlagen im Kontext cyber-physischer Produktionssysteme entstanden. Viele Fertigungsanlagen, wie Werkzeugmaschinen und speicherprogrammierbare Steuerung besitzen keine Netzwerkanbindung oder standardisierte Kommunikationsmechanismen. Im Zuge der vierten industriellen Revolution müssen diese Anlagen in eine bestehende Informations- und Kommunikationsinfrastruktur eingebettet werden, um eine ganzheitlich ökonomische Produktion zu garantieren. Durch Komplexität und geringe Losgrößen heutiger Produktion muss ein Großteil der Überwachung und Steuerung direkt an den Maschinen gewährleistet werden. So müssen auch Altanlagen intelligent auf veränderte Situationen reagieren können, um die Automatisierung des Fertigungsprozesses zu unterstützen. Die Untersuchung aktueller Forschung ergab keine ganzheitliche Lösung zur Modernisierung im Kontext cyber-physischer Produktionssysteme. Jedoch wurden unter der Maßgabe definierter Anforderungen die bestehenden Konzepte evaluiert und in das Design einer System- und Softwarearchitektur eingebunden. Mithilfe eines Einplatinencomputers als Stellvertreter wurde eine horizontale und vertikale Integration der Maschine realisiert. Die Kapselung von Funktionalität und Zustand einer Altanlage durch eine virtuellen Maschinenrepräsentation verhilft intelligenten Analyseverfahren die Daten in Informationen zu überführen und anderen Systemen zur Verfügung zu stellen. Entsprechende Nutzungsschnittstellen zentralisieren die Informationen, geben an der Produktion beteiligten Personen einen Überblick in den laufenden Prozess und ermöglichen den Eingriff. Neben der Architektur und Funktionsweise der Maschinenrepräsentation wird ein Softwareframework zur Umsetzung der Modernisierungsmaßnahme beschrieben und die Implementation eines Laborexperiments erläutert. Eine Evaluation setzt sich kritisch mit dem Konzept auseinander und verifiziert die Lösung bezüglich der Anforderungen und eingangs formulierter Ziele. Der Ausblick vermittelt offene Fragen und Wege weiterführender Forschung. Das letztendliche Ergebnis in Form einer virtuellen Maschinenrepräsentation bildet die Basis zur kostengünstigen Eingliederung des Altanlagenbestands in die moderne IT-Infrastruktur eines cyber-physischen Produktionssystems.

9 Prototypische Umsetzung

Der Quellcode des Frameworks befindet sich auf der beiliegenden CD und ist außerdem im Internet unter github.com/phdd/diplom/tree/surrogate erreichbar. In den folgenden Abschnitten wird neben der Installation auf einem Raspberry Pi die Aufnahme des operativen Betriebs und die Methode der Weiterentwicklung erläutert.

9.1 Installation

Um das Framework der virtuellen Maschinenrepräsentation (VMR) starten zu können wird das Einrichten einiger Softwarepakete vorausgesetzt. Die Elementare Installation eines Debian-basierten Betriebssystems und die der Node.js Laufzeitumgebung wird unter thisdavej.com/beginners-guide-to-installing-node-js-on-a-raspberry-pi detailliert beschrieben. Ist ein Betriebssystem bereits vorhanden findet sich unter joshondesign.com/2013/10/23/noderpi eine kürzere Erläuterung.
Neben der Laufzeitumgebung wird das Softwarepaket für das GrovePi Erweiterungsboard benötigt. Dafür wird das Git-Repository (github.com/DexterInd/GrovePi) auf dem Raspberry geklont und die Software als Superuser installiert.

• git clone https://github.com/DexterInd/GrovePi.git
• sudo bash GrovePi/Script/install.sh

Die Übersetzung des Frameworks wird durch Grunt, ein JavaScript basiertes Build-System bewerkstelligt. Für den folgenden Schritt werden mit Superuser-Rechten einige lokale Pakete mit dem Node Package Manager (NPM) installiert.

• sudo npm install -g grunt grunt-cli
• sudo npm install -g coffee-script

Danach muss das Repository geklont und auf dessen VMR-Branch gewechselt werden.

• git clone https://github.com/phdd/diplom.git vmr
• cd vmr
• git checkout vmr

Schlussendlich werden die JavaScript-Abhängigkeiten installiert, die CoffeeScript-Quellen übersetzt und ein Ordner mit den für das Framework notwendigen Dateien erstellt.

• npm install

9.2 Operativer Betrieb

Um die VMR zu starten wird der Installationsschritt vorausgesetzt. Das beispielhafte Maschinenmodell aus dem Implementationskapitel ist in der XML-Datei objects.xml definiert. Zum Start muss folgender Befehl ausgeführt werden:

• node dist/vmr.js --machineDefinition=objects.xml

Danach ist ein OPC UA Server unter der Raspberry-IP mit dem Port 26543 erreichbar. Welche Sensoren und Aktuatoren an welchem Anschluss des GrovePi-Erweiterungsboards anzuschließen sind, ist in im Maschinenmodell nachzulesen (ConnectionIdentifier) und gegebenenfalls zu korrigieren. Für Details zu Fehlern oder dem Binden von Equipment-Implementationen muss dem Befehl zum Starten der VMR eine Umgebungsvariable vorangestellt werden:

• DEBUG=vmr* node dist/vmr.js --machineDefinition=objects.xml

9.3 Weiterentwicklung

9.3.0.0.1 Maschinendefinition.

Soll das Maschinenmodell angepasst werden, wird eine OPC UA Modellierungssoftware wie der kostenfreie UaModeler von Unified Automation verwendet. Bezogen werden kann die Software unter folgender Adresse:

unified-automation.com/de/downloads/opc-ua-development.html

In diesem wird nun ein neues Projekt angelegt. Im Dialog Generate Code wird der modelling-Ordner ausgewählt, wodurch kein Quellcode generiert, die relevanten XML-Dateien aber erstellt werden. Bei Choose Base Models wird find another model ausgewählt um die Erweiterungen des Informationsmodells zu integrieren. Der heruntergeladene Quellcode der VMR vorausgesetzt, müssen nun die XML-Dateien für die Namespaces OPC4Fatory und CPPS in res/nodesets und objects.xml im Wurzelverzeichnis der VMR ausgewählt werden. Sind diese Dateien nicht sichtbar, sollte der Eintrag Information Model (im Dateiwahl-Dialog unten rechts) durch den zweiten ausgetauscht werden. Für die konkrete Bearbeitung des Informationsmodells bitte ich den Leser die Anleitung zu konsultieren:

documentation.unified-automation.com/uamodeler/1.5.0/html/modeling.html

Nach der Bearbeitung der Objekte kann über das Kontextmenü des Modelleintrags objects.ua die XML-Datei exportiert werden. Im unteren Teil des Programms befindet sich ein Fenster Output, dass den Pfad zur Datei ausgibt. Diese muss schlussendlich in das Wurzelverzeichnis der VMR auf dem Raspberry kopiert werden. Das Framework kann dann durch den Befehl aus dem vorangegangenen Abschnitt mit der aktualisierten Maschinendefinition geladen werden.

9.3.0.0.2 Erweiterungspunkte.

Für die Entwicklung eines Equipment-Erweiterungspunkts wird eine neue Klasse in src/equipment angelegt. Soll beispielsweise ein Förderband mit dem PhysicalConveyorType beschrieben werden, muss eine Datei namens PhysicalConveyorType.coffee wie folgt strukturiert werden.

class PhysicalConveyorType

  $Running: null

  constructor: (connectionIdentifier) ->
    @Conveyor = new ConveyorActuator connectionIdentifier.Conveyor.pin
    @$Stop()

  $Start: =>
    @Conveyor.start()
    @$Running = true

  $Stop: =>
    @Conveyor.stop()
    @$Running = false

Um die Implementation im Framework zu registrieren, wird die Daten src/equipment/index.coffee um eine weitere Zeile ergänzt.

PhysicalConveyorType: require './PhysicalConveyorType'

Nun kann der PhysicalConveyorType im Informationsmodell definiert und dessen Objektinstanz als automatisierte Werkzeugkomponente verwendet werden. Der ConveyorActuator ist eine Umsetzung des Interface-Erweiterungspunkts und muss in src/interface/ConveyorActuator.coffee beschrieben werden. Die Tests werden in test/ und dem entsprechenden Unterordner abgelegt und mit dem folgenden Befehl ausgeführt.

• npm test

Bei Fragen zur Installation und Weiterentwicklung des Prototyps kann der Leser den Autor unter erreichen. Beteiligung an einer Weiterentwicklung wird über das oben genannte GitHub-Repository organisiert.

Literatur