Bachelorarbeit Sebastian Schmitt
Bachelorarbeit Sebastian Schmitt
Wirtschaftsingenieurwesen
Maschinenbau
Sebastian Schmitt
Matrikelnummer: 353208
Das Ziel dieser Bachelorarbeit ist es, ein Konzept für eine effiziente Datenanbindung einer
industriellen Werkzeugmaschine der Forschungseinrichtung des Digital Labs an eine Fabriksi-
mulation zu entwickeln und aufzubauen. Für die Datenanbindung werden zwei Methoden mit
unterschiedlichen Vorgehensweisen vorgestellt und umgesetzt. Im Anschluss an die Daten-
anknüpfung, findet eine Integration der Daten in ein geeignetes Simulationsmodell in Plant
Simulation statt.
In der ersten Methode werden, da die Werkzeugmaschine kontinuierlich Daten mittels OBDC-
Schnittstelle an die Datenbank (MongoDB) überträgt, diese in das Simulationsmodell inte-
griert, um Simulationen anhand der Vergangenheitswerte durchzuführen. Mit einer OPC UA-
Schnittstelle wird in der zweiten Methode eine Echtzeitdatenanbindung über einen program-
mierten OPC UA-Server ermöglicht und schließlich die Daten ebenfalls in ein Simulationsmo-
dell implementiert.
III
Inhaltsverzeichnis
Abkürzungsverzeichnis ............................................................................................................. V
Abbildungsverzeichnis ............................................................................................................. VI
2.5 Der Begriff „digitaler Zwilling“ im Zusammenhang mit der diskreten Simulation ..12
3.2 NoSQL-Datenbanken................................................................................................18
5.1.4 Bewertung des Simulationsmodells und der Datenanbindung mittels einer ODBC-
Schnittstelle .....................................................................................................................40
5.2.3 Bewertung des Simulationsmodells und der Datenanbindung mittels einer OPC
UA-Schnittstelle ...............................................................................................................47
Abkürzungsverzeichnis
BI Business Intelligence
DBS Datenbanksystem
IP Internet Protokoll
PLM Product-Lifecycle-Managment
Abbildungsverzeichnis
Abbildung 1: grundlegender Aufbau der Bachelorarbeit ..........................................................2
Abbildung 2: Beziehung von Zustands- und Zeitmenge entnommen aus Gutenschwager et al.
2017, S. 16 (in Anlehnung an Ören 1979, S.36) .........................................................................5
Abbildung 3: Typen von Systemen (in Anlehnung an Hedtstück 2013, S. 11)...........................6
Abbildung 4 Die Arbeitsoberfläche von Tecnomatix Plant Simulation......................................9
Abbildung 5: Aufbau eines Digitalen Zwillings entnommen aus Schüller et al. 2019, S. 74....13
Abbildung 6: Funktion eines DBMS zwischen Anwender und Datenbank (entnommen aus
Geisler 2014, S. 4) ....................................................................................................................15
Abbildung 7: Beispielszenario und grundlegendes Konzept eines relationalen Datenmodells
..................................................................................................................................................17
Abbildung 8: Grafische Darstellung der Skalierungsprinzipien ...............................................19
Abbildung 9: Grafische Darstellung des MongoDB Compass Tools mit einer Datenbank für eine
Werkzeugmaschine ..................................................................................................................21
Abbildung 10: Abbildung eines kompletten BI-Systems mit den dazugehörigen Komponenten
(entnommen aus MongoDB 2020, S. 1) ...................................................................................22
Abbildung 11: Architektur einer ODBC-Schnittstelle ...............................................................24
Abbildung 12: AddressSpace eines simulierten OPC UA-Servers ............................................26
Abbildung 13: Grafische Darstellung der Attribute einer Node ..............................................26
Abbildung 14: Grafische Darstellung eines Verbindungsaufbaus zu einer MongoDB ............29
Abbildung 15: ODBC-Datenquellen-Administrator..................................................................30
Abbildung 16: MongoDB ODBC Data Source Configuration ....................................................31
Abbildung 17: Das ODBC-Simulationsmodell ..........................................................................33
Abbildung 18: Das Eingabefenster der Init-Methode ..............................................................34
Abbildung 19: Auszug aus der Tabelle variableBearbeitung ...................................................35
Abbildung 20: Auszug aus der Tabelle RohBearbeitungszeiten ..............................................35
Abbildung 21: Auszug aus der Methode variableBearbeitungszeit ........................................36
Abbildung 22: Auszug aus der Tabelle Rohrüstdaten ..............................................................37
Abbildung 23: Auszug aus der Methode Rüstwerte ................................................................37
Abbildung 24: Die Tabelle Rüstdaten ......................................................................................38
Abbildung 25: Die Methode Rüsten.........................................................................................38
Abbildung 26: XY-Diagramm der Bearbeitungszeiten pro Werkstück.....................................39
Abbildung 27: Die Methode Mittelwertberechnung ...............................................................40
Abbildung 28: Die Tabelle Normalverteilung...........................................................................40
VII
Abbildung 29: Die Eclipse IDE Benutzeroberfläche mit einem Auszug aus dem
Programmiercode des OPC UA-Servers ...................................................................................42
Abbildung 30: Auszug aus dem Programmiercode des OPC UA-Servers ................................43
Abbildung 31: Die Benutzeroberfläche von UA-Expert ...........................................................44
Abbildung 32: Das OPC UA-Simulationsmodell .......................................................................44
Abbildung 33: Tabelle der Elemente........................................................................................45
Abbildung 34: Tabelle der einzelnen Variablen .......................................................................45
Abbildung 35: Tabelle für den Status aller Variablen des OPC UA-Servers .............................46
Abbildung 36: Auszug aus der Methode Bearbeitung .............................................................46
Abbildung 37: Ressourcenstatistik der Werkzeugmaschine....................................................47
1
Im Rahmen dieser Bachelorarbeit soll untersucht werden, inwiefern eine real operierende
Werkzeugmaschine der Forschungseinrichtung des Digital Labs digital abgebildet und an eine
diskrete Simulation angebunden werden kann. Ziel der Arbeit ist es, die Datenspeicherung
der Werkzeugmaschine zu untersuchen und anschließend die Daten mithilfe geeigneter Da-
tenschnittstellen in ein erzeugtes Simulationsmodell zu integrieren. Anhand einer OPC UA-
Schnittstelle und einer ODBC-Schnittstelle werden zwei Methoden vorgestellt, die auf unter-
schiedliche Art die Daten der Werkzeugmaschine anbinden und in eine Simulation implemen-
tieren. Dabei liegt der Fokus beider Methoden darauf, durch einen simplen Simulationsauf-
bau eine grundsätzliche Datenanbindung zu ermöglichen.
Der grundlegende Aufbau der Arbeit wird in Abbildung 1 grafisch dargestellt. Beginnend mit
dem Einstieg und einer Einführung in die diskrete Simulation werden im Anschluss die Grund-
lagen von Datenbanken behandelt. Danach findet eine detaillierte Beschreibung der einge-
setzten Datenschnittstellen statt. Mithilfe der Informationen werden anschließend zwei Da-
tenanbindungsmethoden vorgestellt, umgesetzt und anschließend in ein Simulationsmodell
integriert. Das Fazit beinhaltet eine Zusammenfassung der Ergebnisse beider Schnittstellen
und einen Ausblick über zukünftige Entwicklungen im Bereich der Datenanbindung.
2
Vor allem im Bereich der Produktionsplanung und -optimierung ist es aufgrund der stetig
wachsenden Komplexität der zu untersuchenden Prozesse sinnvoll, auf die Anwendung von
Simulationen zurückzugreifen. Diese ermöglichen es, Produktionsanlagen, Prozesse oder ein-
zelne Maschinen zu analysieren und zu verbessern. Dabei wird mithilfe einer Abstraktion des
realen oder imaginären Systems versucht, ein Verständnis für die Problemstellung und deren
Zusammenhänge herzustellen. Anschließend können durch eine gezielte Veränderung von
Stellgrößen die Auswirkungen auf das System untersucht werden.
In den folgenden Abschnitten werden zunächst wichtige Definitionen erklärt, die häufig im
Zusammenhang mit der ereignisdiskreten Simulationen aufkommen. Ziel ist es, ein funda-
mentales Verständnis für die Bedeutung der Simulation herzustellen. Dabei orientieren sich
die Definitionen stets an der VDI-Richtlinie 3633. Die Richtlinie dient als Basis und Orientie-
rung für Anwender, Simulationsstudien effizienter durchzuführen, indem Begriffe eindeutig
definiert und Leitsätze zur Verfügung gestellt werden. Die Vorgaben sollen gezielt Missver-
ständnisse zwischen den beteiligten Parteien während der Durchführung einer Simulations-
studie vermeiden (vgl. VDI 2014, S. 2).
Im Anschluss daran, wird der Ablauf einer Simulationsstudie erklärt und das eingesetzte Si-
mulationswerkzeug vorgestellt. Abschließend findet eine Betrachtung des digitalen Zwillings
im Zusammenhang mit der ereignisdiskreten Simulation statt.
Wird bei der Durchführung einer Simulation auf den Einsatz von Computern zurückgegriffen,
spricht man hierbei von einer digitalen- oder einer Computersimulation. Digitale Simulatio-
nen zeichnen sich dadurch aus, dass das zu integrierende Modell in einer systematischen
Struktur vorliegen und in eine geeignete Software implementiert werden muss (vgl. Eley
2012, S. 4). Die genutzte Software ist dabei das Simulationswerkzeug.
Der Begriff Simulation wird laut VDI wie folgt konkretisiert: Die Simulation ist das
Die Berücksichtigung des Zeitverlaufes einer Simulation, ist entscheidend für die Ergebnisse
und die Auswirkungen auf ein System und ferner der ausschlaggebende Grund für die Ab-
grenzung von rein statistischen Analysen, wie beispielsweise Tabellenkalkulationsanwendun-
gen. Je nach Betrachtung des Zeitverhaltens in einem Simulationsmodell wird zwischen der
kontinuierlichen und der diskreten Simulation unterschieden. In Abbildung 2 ist das Verhalten
unterschiedlicher Zustandsmengen grafisch dargestellt, wobei die kontinuierliche Simulation
kontinuierliche Zeitmengen, sowie kontinuierliche Zustandsmengen beinhaltet. Daraus resul-
tierend, entsteht eine Abbildung mit Systemzuständen, die sich in einem stetigen Verlauf in
Abhängigkeit von der Zeit verändern (vgl. Gutenschwager et al. 2017, S. 24 f.).
Bei der ereignisdiskreten Simulation (auch Ablaufsimulation genannt) verändert sich die Zeit
in Abhängigkeit eines eintretenden Ereignisses. Das heißt, die Zeit setzt sich in einem sprung-
haften Intervall auf den Zeitpunkt des nächsten Ereignisses. Die dadurch hervorgerufenen
Zustandsänderungen sind somit ebenfalls diskret. (vgl. Gutenschwager et al. 2017, S. 53 f.).
Daraus resultiert ein wesentlicher Vorteil der ereignisdiskreten Simulation, denn somit ist die
Rechenzeit im Vergleich zu einer kontinuierlichen Simulation deutlich geringer, da die Re-
chenzeit nur von der Anzahl der eintretenden Ereignisse abhängt und nicht von der Länge der
Zeitintervalle (vgl. Gutenschwager et al. 2017, S. 55).
Ein weiterer Vorteil der ereignisdiskreten Simulation ist es, mit hoher Genauigkeit das dyna-
mische Verhalten eines Systems nachspielen zu können. Ein typisches Beispiel für eine ereig-
nisdiskrete Simulation ist die Betrachtung von Bearbeitungsvorgänge in einer Produktion (vgl.
Hedtstück 2013, S. 22).
Im Verlauf dieser Bachelorarbeit wird sich ausschließlich auf die ereignisdiskrete Simulation
konzentriert.
5
Abbildung 2: Beziehung von Zustands- und Zeitmenge entnommen aus Gutenschwager et al. 2017, S. 16 (in Anlehnung an
Ören 1979, S.36)
Dabei können Objekte einerseits zeitweise in einem System vorhanden sein, sogenannte tem-
poräre Objekte wie beispielsweise Aufträge, Werkstücke oder Fahrzeuge. Andererseits kön-
nen auch dauerhafte Objekte, sogenannte permanente Objekte wie Maschinen, Läger oder
Abteilungen in einem System vorkommen (vgl. Hedtstück 2013, S. 11).
Sobald das reale oder geplante System abgebildet wird, spricht man hierbei von einem Modell
(vgl. Bangsow 2016, S. 2).
„Vereinfachte Nachbildung eines geplanten oder existierenden Systems mit seinen Prozessen
in einem anderen begrifflichen oder gegenständlichen System“ (vgl. VDI 2014, S. 3).
Expliziter formuliert, bildet ein Modell die Struktur oder das Verhalten eines zu untersuchen-
den Systems mit einem geringeren Detaillierungsgrad als beim ursprünglichen System ab. Da-
bei liegt der Fokus der Abstraktion auf den wesentlichen Komponenten und notwendigen
Prozessen, die ausschlaggebend sind, um eine Leistungsbewertung am System durchführen
zu können. Details, die für die Untersuchung des Systems nicht relevant sind, werden bei der
Bildung des Modells weggelassen (vgl. März et al. 2011, S. 13).
Innerhalb eines Modells laufen unterschiedliche Systeme ab und somit auch eine Vielzahl an
Prozessen mit verschiedenen Attributen und Abhängigkeiten. Dabei wird ein Prozess allge-
mein definiert, als eine
„Gesamtheit von aufeinander einwirkenden Vorgängen in einem System, durch die Materie,
Energie oder Information umgeformt, transportiert oder gespeichert wird" (DIN IEC 60050-
351:2013, S. 32).
Bezogen auf ein dynamisches System, ist ein Prozess die Zusammenfassung aller Objekte ei-
nes Systems mit dessen Eigenschaften und Beziehungen. Dabei können Prozesse in einem
dynamischen System sequentiell, parallel, nebenläufig und synchronisiert kohärieren. Be-
trachtet man nur ein einzelnes Objekt, so wird dieses als Teilprozess innerhalb des Gesamt-
systems angesehen. Ein diskreter Prozess zeichnet sich dadurch aus, dass die Ereignisse meist
den Abschluss einer Aktivität, sowie den Beginn einer neuen Aktivität kennzeichnen. Ausge-
nommen ist das erste und letzte Ereignis (vgl. Hedtstück 2013, S. 16).
In den meisten Fällen ist in einer Simulation eine umfassende Simulationsstudie impliziert.
Das Ziel einer Simulationsstudie ist eine Prozessverbesserung anhand zuvor festgelegter Key
Performance Indicators (KPI) durchzuführen, welche die Leistungsfähigkeit eines Systems
messen und anschließend optimieren. In diesem Zusammenhang stellt die Optimierung die
Verbesserung eines Prozesses dar und nicht die Suche nach einem Optimum. Die Kunst bei
der Zielerreichung liegt darin, eine Annäherung der Ziele nur soweit vorzunehmen, bis sich
insgesamt eine maximale Zunahme der gewünschten Wertschöpfung ergibt. Eine typische
Zielsetzung ist beispielsweise die Reduktion der Produktionszeit. Dabei spielen Kennzahlen
wie Durchlaufzeiten, Liegezeiten oder Rüstzeiten eine wichtige Rolle, die in der durchzufüh-
renden Simulationsstudie betrachtet und analysiert werden müssen (vgl. Hedtstück 2013, S.
7).
Im Zeitalter der Digitalisierung stehen Simulationen verstärkt bei der Umsetzung der Digitalen
Fabrik als wichtige Methode im Fokus. Vor allem Schnittstellenentwicklungen für den Daten-
austausch werden somit immer bedeutender (vgl. Bracht et al. 2018, S. 83).
8
Dadurch entstehen neue individuelle Anforderungen an die Simulationshersteller, die die un-
terschiedlichen Schnittstellen zur Verfügung stellen müssen, um weiterhin wettbewerbsfähig
agieren zu können. Tecnomatix Plant Simulation bietet eine Vielzahl von Schnittstellen an,
mit denen Datenbanken, Grafiken oder Daten als Textdateien ausgelesen werden können.
Dabei zeichnet sich das Simulationssystem laut Siemens PLM Software (vgl. Siemens Product
Lifecycle Management Software Inc. 2008) unter anderem durch folgende Leistungsmerk-
male aus:
Vor allem die offene Systemarchitektur, mit den unterschiedlichen Schnittstellen sorgt dafür,
dass Plant Simulation ein wichtiges Einstiegswerkzeug in das Thema der Digitalen Fabrik dar-
stellt. Um die im späteren Verlauf durchgeführten Testmodelle besser nachvollziehen zu kön-
nen, wird im folgenden Abschnitt auf die Grundlagen von Plant Simulation eingegangen.
Am linken Rand des TUNE-Fensters befindet sich die Klassenbibliothek, die alle benötigten
Bausteine für eine Erstellung eines Simulationsmodells umfasst. Die Bausteine sind in die
Gruppen Materialfluss, Ressourcen, Informationsfluss, Oberfläche, BEs (Bewegliche Einhei-
ten), Tools und Modelle eingeteilt. Je nach Anwendungszweck können die Objekte aus ihren
Gruppen ausgewählt und falls nötig individuell angepasst werden. Sollten benötigte Objekte
wie beispielsweise Datenbankschnittstellen fehlen, die regulär nicht in der Klassenbibliothek
angezeigt werden, können diese nachträglich über das Icon "Klassenbibliothek verwalten"
beschafft werden (vgl. Eley 2012, S. 33).
Die Toolbox im oberen Drittel des Programms listet alle verfügbaren Elemente auf und er-
möglicht eine schnelle Übertragung der Bausteine in das Modell. Die Toolbox kann auf eigene
Bedürfnisse entsprechend umgestaltet werden. Die Konsole im unteren Bereich der Bedien-
oberfläche liefert nützliche Informationen während eines Simulationsprozesses. So werden
z.B. Fehlermeldungen angezeigt, die während eines Simulationslaufes entstanden sind (vgl.
Bangsow 2016, S. 9).
Das Netzwerk befindet sich in der Mitte der Arbeitsoberfläche. In das Fenster können je nach
Anwendung verschiedene Objekte aus der Klassenbibliothek oder der Toolbox gezogen und
miteinander in Verbindung gebracht werden. Während eines Simulationslaufes sind Bewe-
gungen unterschiedlichster Art im Netzwerkfenster sichtbar. Über den Ereignisverwalter, der
sich im Netzwerk befindet oder über die Toolbox eingefügt werden kann, wird die Simulation
10
zeitlich gesteuert. Optional kann der Ereignisverwalter, sobald er im Netzwerk sichtbar ist,
unter der Registerkarte „Start“ bedient werden. Der Ereignisverwalter kann die Geschwindig-
keit der Simulation sowie der Start- und Endzeitpunkt einstellen (vgl. Eley 2012, S. 34).
Da sich die Bachelorarbeit intensiv mit Datenanbindungen auseinandersetzt, werden die ein-
zelnen Schnittstellen separat in Kapitel 4 erläutert.
Eine Methode erstellt Steuerungen, mit denen sie andere Elemente beeinflussen kann. Steu-
erungen beinhalten wiederum Variablen, die in einer Methode deklariert werden müssen.
Eine Variable ist ein definierter Ort im Speicher; das heißt, ein Bereich im Programm indem
Informationen gespeichert werden. Deshalb ist es sinnvoll aussagekräftige Namen für eine
Variable zu verwenden, um den Überblick in einer Methode zu bewahren. Dabei unterschei-
det Plant Simulation zwischen lokalen und globalen Variablen. Eine lokale Variable ist aus-
schließlich innerhalb einer Methode verfügbar. Im Umkehrschluss sind globale Variablen me-
thodenübergreifend ansprechbar. Jede Variable braucht einen eindeutigen Datentyp, um die
Informationen als Zahlen, Zeichen oder Zeichenketten speichern zu können. Dafür stehen in
SimTalk elementare Datentypen zur Verfügung, die in Tabelle 2 aufgelistet sind. Die verwen-
deten Datentypen von SimTalk gleichen den Datentypen der gängigsten Programmierspra-
chen (vgl. Bangsow 2016, S. 17).
12
2.5 Der Begriff „digitaler Zwilling“ im Zusammenhang mit der diskreten Simulation
Durch die Fortschreitung der Digitalisierung, gewinnt der Begriff des digitalen Zwillings ver-
mehrt an Bedeutung. Dabei wird der Digitale Zwilling im Informatiklexikon der Gesellschaft
für Informatik als „digitale Repräsentanzen von Dingen aus der realen Welt“ (Kuhn Thomas
2017) definiert.
Diese Dinge können sowohl physische Objekte als auch nicht-physische Dinge sein. Bezogen
auf die Produktion und Logistik ist ein digitaler Zwilling die Abbildung einer geplanten bezie-
hungsweise realen Produktionsanlage und kann als ein Gesamtsystem mit unterschiedlichen
Teilsystemen angesehen werden. Er erzeugt auf digitaler Ebene eine vollständige Nachbil-
dung der Produktionsprozesse und gibt die dynamischen Abläufe während der Fertigung in
Echtzeit wieder. Mit Hilfe von Simulationsmodellen können sowohl die Merkmale der Sys-
teme als auch deren Verhalten beschrieben werden. In Abbildung 5 ist der Digitale Zwilling
mit seinen Bestandteilen grafisch dargestellt. So besteht eine kontinuierliche Interaktion zwi-
schen den einzelnen Modellen und der Datenbank. Die Simulationsmodelle greifen auf die
Datenbank zu. Die Informationsmodelle sorgen dafür, dass die Daten eine Semantik erhalten
und unterstützen das Simulationsmodell, indem sie die benötigten Informationen auffinden
und interpretieren. Des Weiteren sind für den durchgehenden Import und Export der Daten
aus den Werkzeugen Schnittstellen notwendig, die eine Übertragung dieser an die Datenbank
13
ermöglichen. Die Visualisierung ist ein wichtiger Faktor des Digitalen Zwillings, welche die
hinterlegten Daten anschaulich darstellt und als Grundlage für eine Analyse dient (vgl.
Schüller et al. 2019, 71 ff.).
Die Ablaufsimulation ist ein Teilsystem des Digitalen Zwillings, mit der es durch eine regelmä-
ßige Durchführung möglich ist, gezielt auf Veränderungen oder Störungen in der Produktion
eingehen zu können. Produktionssituationen können somit kontinuierlich vorausschauend
betrachtet werden.
Abbildung 5: Aufbau eines Digitalen Zwillings entnommen aus Schüller et al. 2019, S. 74
Damit das Konzept des Frauenhofer-Instituts in der industriellen Praxis umsetzbar ist, sind
Datenbanken notwendig, die die enormen Mengen an Informationen verarbeiten. Die Daten-
bank ist ein essenzieller Bestandteil, um eine Vielzahl von Daten zu sammeln und zu spei-
chern. Auch in Bezug auf die in dieser Bachelorarbeit erzeugten Simulationsmodelle, spielen
Datenbanken eine wesentliche Rolle und werden somit im folgenden Kapitel spezifischer er-
läutert.
14
Eine Datenbank ermöglicht es, eine Vielzahl an Daten abzuspeichern und verschiedene kom-
plexe Beziehungen zwischen den Daten zu definieren. Nach Geisler ist eine Datenbank ein
verteiltes, integriertes Computersystem, das im Wesentlichen aus Nutzdaten, welche die Be-
nutzer anlegen, löschen oder verschieben können, und aus Metadaten, welche dafür zustän-
dig sind, die Nutzdaten zu strukturieren, besteht. In einer Tabelle wären z.B. die Metadaten
die Überschriften, die die Inhalte der Tabelle, also die Daten in geordneter Form, darstellen
(vgl. Geisler 2014, S. 1).
Damit aus einer Datenbank Informationen gewonnen werden können, müssen die Daten in
Zusammenhang gebracht werden. Ein einfaches Szenario aus der Produktion soll den Zusam-
menhang zwischen Daten und Informationen verdeutlichen. Ein Industrieunternehmen muss
für einen Auftrag das Produkt ND1 herstellen. Dabei ist die Produktnummer allein nur ein
Datensatz. Sobald die Nummer in ein Computersystem eingegeben wird, erhält man weitere
Daten, die im direkten Zusammenhang mit der Produktnummer stehen. Durch die Verknüp-
fung dieser Daten entstehen Informationen, die Entscheidungen oder Handlungen auslösen
können. Da der Computer alle getätigten Aufträge mit der Produktnummer ND1 kennt, kann
er weitere Daten über den Verlauf der Produktion beschaffen. Die daraus resultierenden In-
formationen können genutzt werden, um den Produktionsprozess individuell anzupassen.
Das heißt, erst die gewonnen Informationen aus den unterschiedlichen Daten sind das Wich-
tige und Wertvolle. Setzt man die Daten in einen anderen Zusammenhang, entstehen
dadurch auch andere Informationen (vgl. Geisler 2014, S. 1 f.).
Für die Verwaltung einer Datenbank wird ein Datenbankmanagementsystem (DBMS) benö-
tigt. Ein DBMS ist dafür zuständig, eine Datenbank zu erstellen, zu organisieren und zu pfle-
gen. Dabei fungiert das DBMS als eine Schnittstelle zwischen dem Anwender und der Daten-
bank. Formuliert der Anwender eine Abfrage an die Datenbank, wird diese zum DBMS wei-
tergeleitet. Das DBMS wertet die Abfrage aus, sucht die benötigten Daten aus der Datenbank
heraus und leitet sie zurück an den Anwender (siehe Abb. 6). So können Daten leicht zur Da-
tenbank hinzugefügt, gelöscht oder geändert werden. Die leistungsstarke Suchfunktion eines
15
DBMS ermöglicht es, Daten schnell in einer Datenbank zu finden. Datenbanken arbeiten so-
mit hauptsächlich im Hintergrund. Häufig wird in der Praxis der Begriff Datenbank anstatt
DBMS verwendet, obwohl es sich in den meisten Fällen um ein DBMS handelt (z.B. Oracle und
Access). Datenbankmanagementsysteme sind heutzutage ein wesentlicher Bestandteil der
Informationsgesellschaft und zwingend erforderlich, um aus Daten Informationen zu formen.
(vgl. Geisler 2014, S. 4 f.).
Abbildung 6: Funktion eines DBMS zwischen Anwender und Datenbank (entnommen aus Geisler 2014, S. 4)
Damit ein DBMS optimal eingesetzt werden kann, ist es wichtig bei der Entwicklung einer
Datenbank die verwendeten Datenstrukturen an das DBMS anzupassen. Das Design, welches
auch als Datenbankmodell bezeichnet wird, muss logisch und stimmig sein, um eine Daten-
bank effektiv nutzen zu können. Dabei gibt ein Datenbankmodell vor, auf welche Art und
Weise die Daten zu speichern sind. Datenbankmodelle können anhand deren grundlegenden
Struktur in folgende unterschiedliche Kategorien eingeteilt werden (vgl. Geisler 2014, S. 32
ff.):
• Hierarchische Datenbanken
• Netzwerk-Datenbanken
• Relationale Datenbanken
• NoSQL Datenbanken
Ein übersichtliche Darstellung einiger heute verfügbarer DBMS verschiedener Hersteller und
die grundlegenden Datenbankmodelle sind in Tabelle 3 abgebildet.
Anhand Tabelle 3 ist zu sehen, dass die in der industriellen Praxis am meisten eingesetzten
Datenbanken auf einem relationalen DBMS (RDBMS) beruhen. Somit werden diese im folgen-
den Abschnitt spezifischer betrachtet.
In Abbildung 7 ist ein vereinfachtes Szenario dargestellt, welches den Umgang mit eintreffen-
den Materialen und deren Weiterverarbeitung in einem Unternehmen beschreibt. Ziel ist es
den Zusammenhang zwischen Primär- und Fremdschlüssel zu verdeutlichen.
Beim Eintreffen einer Lieferung werden die Materialien in einer Datenbank mit den dazuge-
hörigen Informationen gespeichert. Für die Weiterverarbeitung des Materials soll klar defi-
niert werden, welche Presse die geeigneten Eigenschaften aufweist, um eine optimale Bear-
beitung zu erzielen. Die einzelnen Pressen sind in einer weiteren Tabelle genau gekennzeich-
net und mit zusätzlichen Attributen beschrieben. Um genau festzulegen, welche Maschine
das Material weiterverarbeiten soll, muss eine Beziehung zwischen der Tabelle des Materials
und der Tabelle der Maschinen/Pressen hergestellt werden. Dabei wird der Primärschlüssel
aus der Tabelle der Maschinen, in die Tabelle des Materials überführt (siehe grünen Pfeil).
Der überführte Primärschlüssel ist in der Tabelle des Materials nun ein Fremdschlüssel (siehe
grünmarkierte Umrandung). Bei Eintritt einer Lieferung im Unternehmen, muss nun die für
die Weiterverarbeitung zuständige Presse angegeben werden. Bei der fehlenden Auswahl der
Pressen, erzeugt die Software eine Hinweismeldung, die dem Benutzer signalisiert, dass noch
keine Presse ausgewählt wurde.
17
Die im zuvor beschriebenen Szenario eingesetzte Beziehung nennt man 1:N-Beziehung. Ein
Datensatz aus der Tabelle Material steht mit mehreren Datensätzen der Tabelle Maschine in
Beziehung. Des Weiteren gibt es noch M:N und 1:1 Beziehungen.
Der wesentliche Vorteil einer relationalen Datenbank ist die strukturelle Unabhängigkeit. Das
heißt, es ist ein direkter Datenzugriff möglich, ohne davor durch verzweigte Strukturen navi-
gieren zu müssen. Dadurch können relationale Datenbanken einfach entworfen und verwal-
tet werden. Durch die Unterstützung von Ad-hoc-Abfragen, die bestimmte Abfragen direkt
an das Datenbanksystem weitergeben können, ohne dass der Anwender umfassende Struk-
turkenntnisse der Datenbank benötigt, wird die Flexibilität einer relationalen Datenbank ver-
deutlicht. Mit der Abfragesprache Structured Query Language (SQL) ist es unter anderem
möglich, die in der Datenbank gespeicherten Daten zu verändern oder umfassende Informa-
tionsabfragen durchzuführen. Da das Konzept der relationalen Datenbank gegenüber anderer
Datenbanken viel einfacher und übersichtlicher gestaltet ist, hat es im Laufe der Zeit eine
dominierende Stellung im Datenbanksektor eingenommen (vgl. Geisler 2014, S. 41 ff.).
Besonders hervorzuheben ist die relationale Datenbank SQLite, welches das verbreitetste
und meistverwendete Datenbanksystem der Welt ist. Vor allem in Mobiltelefonbetriebssys-
temen und in Computern findet SQLite Anwendung. Der wesentliche Unterschied zu her-
kömmlichen relationalen Datenbanken ist, dass das Datenbanksystem vollständig in eine An-
18
wendung integrierbar ist und somit auf keine laufenden Datenbankserveranwendungen an-
gewiesen ist. Dabei besteht eine SQLite-Datenbank nur aus einer einzelnen Datei, die alle Ta-
bellen beinhaltet. Das hat zur Folge, dass ein vereinfachter Datenaustausch zwischen unter-
schiedlichen Systemen möglich ist. Ist man jedoch auf die volle Funktionalität der SQL-Befehle
angewiesen, ist von einer SQLite-Datenbank abzuraten, da es sich hier um eine „Lite“-Version
für SQL handelt (vgl. sqlite 2020).
Allgemein weisen RDBMS in Bezug auf die stetig wachsenden Datenmengen, die heutzutage
von einem Datenbanksystem bewältigt werden müssen, einen großen Nachteil auf. Denn ein
RDBMS benötigt bei großen Datenmengen eine wesentlich höhere Prozessleistung als andere
DBMS. Somit können mit zunehmenden Datenvolumen die Hardwarekosten rasant steigen
(vgl. Kudraß und Brinkhoff 2015, S. 368).
Für die erfolgreiche Bewältigung von großen Datenmengen, die sich teilweise im Bereich von
mehreren hundert Petabyte bewegen, eignen sich beispielsweise NoSQL-Datenbanken.
3.2 NoSQL-Datenbanken
Die NoSQL-Datenbank (Not only SQL) ist ein Datenbanksystem der neuen Generation, mit
dem Ziel, sehr große Datenmengen beherrschen zu können. Dabei ist die wesentliche Eigen-
schaft einer NoSQL-Datenbank, dass das zugrundeliegende Datenmodell nicht relational ist,
sondern die Systeme auf eine verteilte und horizontale Skalierbarkeit (Scale-out) ausgerichtet
sind (siehe Abb. 8). Eine horizontale Skalierbarkeit ermöglicht das Einfügen von zusätzlichen
dynamischen Rechenknoten, die einen Teil der Datenlast tragen können und somit zu einer
Leistungserhöhung des Systems beitragen. Dagegen wird bei einer klassischen vertikalen Ska-
lierung (Scale-up), die vor allem bei relationalen Datenbanken Anwendung findet, eine Leis-
tungssteigerung durch das Hinzufügen von mehr Ressourcen zu einem System ermöglicht.
Das heißt, mit immer größer werdenden Datenmengen nehmen die dadurch entstehenden
Hardwarekosten exponentiell zu. Zudem ist das Maß der Skalierbarkeit begrenzt, sodass re-
lationale Datenbanken enorme Probleme haben, mit „BigData“-Anwendungen erfolgreich
umgehen zu können (vgl. Kudraß und Brinkhoff 2015, S. 369 f.) (vgl. Edlich 2011, S. 3).
19
Nicht nur große Firmen wie Yahoo, Amazon oder Facebook verwenden unterschiedliche Ar-
ten von NoSQL-Datenbanken, sondern auch vermehrt Industrieunternehmen, die für eine er-
folgreiche Gestaltung ihrer Produktionsprozesse Unmengen an Daten analysieren und aus-
werten müssen. Die heutzutage klassischen NoSQL-Systeme sind vor allem CouchDB,
Cassandra, MongoDB, Redis und HBase/Hypertable. Diese können in unterschiedliche Sys-
temkategorien eingeteilt werden (vgl. Edlich 2011, S. 1 ff.).
• Key/Value-Systeme (Redis)
• Column-Family-Systeme (HBase, Hypertable und Cassandra)
• Document Stores (MongoDB, CouchDB)
• Graphdatenbanken (SonseDB)
Bezogen auf die in dieser Bachelorarbeit betrachteten Datenübertragungen, sind die Daten-
banksysteme der Document Stores von besonderer Relevanz, da die Werkzeugmaschine kon-
tinuierlich Daten an eine speziell eingerichtete MongoDB übermittelt. Deshalb wird im fol-
genden Abschnitt der Aufbau und das Verhalten von dokumentorientierten Datenbanken nä-
her erläutert.
3.2.2 MongoDB
Die MongoDB ist eine dokumentorientierte Datenbank, die in der Programmiersprache C++
geschrieben ist und als Open Source zur Verfügung steht. Der Name setzt sich aus dem engli-
schen Wort humongous zusammen und bedeutet übersetzt gigantisch.
Ziel dieser Datenbank ist es, möglichst kurze Reaktionszeiten auch bei großen Datenmengen
zu generieren. Neben den allgemeinen Features einer dokumentorientierten Datenbank, bie-
tet MongoDB weitere nützliche Funktionen an, wie beispielsweise die automatische Repro-
duktion aller unbeendeten Transaktionen nach einem Crash des Systems. Der Einsatzbereich
von MongoDB erstreckt sich über eine Vielzahl von Plattformen. Je nach Betriebssystem ste-
hen für die Plattformen Linux, Windows, MacOS X sowie Solaris spezielle Versionen für die
Anwendung zur Verfügung. Nach Edlich liegen die wesentlichen Vorteile einer MongoDB vor
allem in folgenden Punkten (vgl. Edlich 2011, S. 132 ff.):
Für die Verwaltung eines laufenden MongoDB-Servers bietet MongoDB verschiedene Wege
an. Zum einen können Benutzer mittels Mongo Shell Lese- sowie Schreiboperationen durch-
führen. Dabei ist Mongo Shell ein Kommandozeilen-Client, mit dem man in der Eingabeauf-
forderung Befehle in der Sprache JavaScript ausführen kann. Zum anderen ist MongoDB mit
21
unterschiedlichen Treibern ausgestattet, sodass eine Verwaltung auch mit den offiziellen Pro-
grammiersprachen möglich ist. Möchte man die Daten in einer grafischen Oberfläche bear-
beiten, stehen hier ebenfalls einige Programme, wie z.B. MongoDB Compass zur Verfügung.
In Abbildung 9 sind die Datenbanken für die Werkzeugmaschine des Digital Labs grafisch in
MongoDB Compass dargestellt. Am linken Rand des Fensters, befinden sich allgemeine Infor-
mationen zur Datenbankverbindung und eine Auflistung der vorhandenen Datenbanken.
Nachdem eine Datenbank ausgewählt wurde, erscheint im mittleren Bereich des Fensters
eine Übersicht aller verfügbaren collections mit den dazugehörigen spezifischen Angaben. In
diesem Teil des Fensters ist eine Bearbeitung der Datenbank möglich. Wird eine collection
geöffnet, erzeugt MongoDB Compass alle in dieser collection befindlichen Dokumente mit
den einzelnen Attributen, die anschließend individuell verändert werden können.
Das Tool bietet die Möglichkeit, Anpassungen einer Datenbank auch von Benutzern ohne spe-
zifisches Fachwissen einer Programmiersprache vornehmen zu können. Es ist zu beachten,
dass bei Fehlhandlungen wichtige Daten der Datenbank auf Dauer gelöscht werden können,
sodass nur Personen mit der Datenbank arbeiten sollten, die ein gewisses Fachwissen vor-
weisen können.
Abbildung 9: Grafische Darstellung des MongoDB Compass Tools mit einer Datenbank für eine Werkzeugmaschine
22
Damit Business Intelligence-Anwendungen wie beispielsweise Excel, Tableau oder Qlik, die
SQL als Abfragesprache benutzen, auch auf Daten einer MongoDB zugreifen können, wurde
der MongoDB Connector for BI (Business Intelligence) entwickelt. Dieser ermöglicht es, ein
relationales Schema darzustellen und SQL-Abfragen in die speziell von MongoDB genutzte
Abfragesprache MongoDB Query Language (MQL) umzuwandeln. Anschließend wird die um-
gewandelte Abfrage an die Datenbank weitergeleitet und die benötigten Daten an das An-
wendungsprogramm zurückgesendet. Ein vollständiger Verbindungsprozess von einem An-
wendungsprogramm zu einer Datenbank, ist in Abbildung 10 dargestellt. Dabei beinhaltet ein
sogenanntes BI-System folgende Komponenten (vgl. MongoDB 2020, S. 1):
Je nachdem ob sich eine Datenbank lokal oder auf einem Netzwerk befindet, sind unter-
schiedliche Vorgehensweisen nötig, um eine Verbindung zwischen Datenbank und Anwen-
dungsprogramm herzustellen. In Kapitel 5 wird eine spezielle Methode beschrieben, die eine
auf einem Netzwerk befindliche MongoDB mit einer Simulationssoftware über einen BI-
Connector verbindet und die Daten für eine Simulation verwendet.
Abbildung 10: Abbildung eines kompletten BI-Systems mit den dazugehörigen Komponenten (entnommen aus MongoDB
2020, S. 1)
23
Aufbau und Funktionsweise einer ODBC-Schnittstelle werden anhand einer vereinfachten Ar-
chitektur aus Abbildung 11 im Folgenden kurz erläutert:
24
ODBC-Anwendung
Die ODBC-Anwendung ist das Programm (z.B. Plant Simulation), das der Benutzer bedient und
ODBC-Befehle aufruft, um SQL-Befehle an die Datenbank zu senden und Ergebnisse zurück-
zubekommen (vgl. Geisler 2014, S. 55).
ODBC-Treiber-Manager
Der Treiber-Manager lokalisiert anhand des zuvor festgelegten Data Source Name (DSN) den
zuständigen Treiber und lädt die ODBC-Treiber. Im Anschluss daran, leitet er die Daten an den
richtigen ODBC-Treiber weiter (vgl. Luber 2017, S. 1).
ODBC-Treiber
Der ODBC-Treiber selbst führt ODBC-Funktionen aus, übermittelt SQL-Anfragen an die spezi-
fische Datenbank und liefert das Ergebnis an die ODBC-Anwendung zurück (vgl. Geisler 2014,
S. 55).
Bezogen auf eine MongoDB übermittelt der ODBC-Treiber die SQL-Anfragen an den MongoDB
Connector for BI. Anschließend verarbeitet dieser die SQL-Anfrage weiter (siehe Abschnitt
3.2.2) und sendet die erforderlichen Daten an den ODBC-Treiber zurück.
DBMS
Das DBMS beinhaltet die Daten, auf die der Benutzer der ODBC-Anwendung zugreifen möchte
(vgl. Geisler 2014, S. 55).
Die OPC UA Infrastruktur basiert auf dem Konzept des Client-Server-Modells. Das Client-Ser-
ver-Modell beschreibt eine Möglichkeit zur Verteilung von Aufgaben innerhalb eines Netz-
werks. Die Aufgaben werden mithilfe von Clients und Servern erledigt. Der Client kann auf
Wunsch einen Dienst vom Server anfordern. Der Server beantwortet die Anforderung und
stellt dem Client einen Zugang zum angeforderten Dienst zur Verfügung. Dabei ist jeder Ser-
ver in der Lage gleichzeitig mit mehreren Clients zu interagieren. Jeder Client kann mit meh-
reren Servern verbunden sein. Sobald der Client eine Verbindung über die spezifische IP-Ad-
resse des OPC UA-Servers hergestellt hat, können gezielt Informationen der Maschine oder
Anlage abgefragt werden. Die Hauptkomponente eines OPC UA-Servers ist der AddressSpace.
Innerhalb des AddressSpace werden in einer objektorientierten Struktur verschiedene Nodes
(Knoten) vom Server bereitgestellt. Nodes repräsentieren unter anderem reale Objekte einer
Fertigungsumgebung und können beispielsweise verwendet werden, um Sensordaten, Mess-
werte oder spezifische Informationen einer Anlage abzubilden (vgl. Hoffmann 2019, S. 92 ff.).
In Abbildung 12 ist die Grundstruktur eines OPC UA AddressSpace abgebildet. Der Root Ord-
ner bildet den Einstiegspunkt in den AddressSpace. Der Ordner Types beinhaltet alle Definiti-
onen zu bestehenden oder benutzerdefinierten Nodes. Innerhalb des Ordners Objects sind
zuvor definierte Nodes abgebildet.
26
Um Nodes eindeutig zu identifizieren, besitzt jede Node eine NodeID. Eine NodeID setzt sich
aus dem jeweiligen NamespaceIndex und einer zusätzlichen Identifikation in Form eines
Strings oder eines Integers zusammen. Der Namespace dient dazu, Nodes anhand spezifischer
Merkmale zu gruppieren. In Abbildung 13 sind die Attribute einer Node grafisch dargestellt.
Die Node besitzt folgende NodeID: ns=2;i=4. Dabei steht ns für den Namespace und i für den
zusätzlichen Identifikator, der in diesem Fall aus einem Integer besteht.
Eine OPC UA-Schnittstelle bietet nicht nur die Möglichkeit Daten in Echtzeit abzurufen, son-
dern diese auch gezielt zu verändern. Somit können Anwendungen wie beispielsweise Simu-
lationssoftwareprogramme einerseits reale Prozesse digital abbilden und laufend analysie-
ren, andererseits kann bewusst Einfluss auf den echten Prozess genommen werden. Inwie-
fern sich eine OPC UA-Schnittstelle in Plant Simulation eignet, wird in Abschnitt 5.3 unter-
sucht.
27
• MongoDB
• MongoDB Connector for BI
• ODBC Data Source Name (DSN)
Die eigentliche MongoDB läuft auf einem Computer, der mit der Maschine verbunden ist.
Darauf läuft ein Programm, das die Daten per MQTT von der Maschine erhält, verarbeitet und
in die Datenbank einfügt. MQTT ist ein offenes Netzwerkprotokoll für die Kommunikation
zwischen Maschinen und ermöglicht den Transport von Daten. Zusätzlich läuft eine Kopie der
MongoDB auf einem Hochschulserver, die täglich die Daten der originalen Datenbank erhält.
Bei der Erzeugung der Datenbankverbindung wird nicht auf die originale Datenbank, sondern
auf die Kopie der MongoDB zugegriffen.
Der MongoDB Connector for BI kann direkt von der MongoDB-Internetseite heruntergeladen
werden. Nach Abschluss der Installation befindet sich der MongoDB Connector in einem be-
stimmten Verzeichnis auf dem Computer. Der Zugriff auf die Datenbank erfolgt ausschließlich
aus den in diesem Verzeichnis befindlichen Dateien, die per Windows-Eingabeaufforderung
angesteuert werden. Falls kein bestimmtes Verzeichnis während der Installationsanleitung
ausgewählt wurde, befindet sich der MongoDB Connector for BI in folgendem Verzeichnis:
Mit Hilfe der Windows-Eingabeaufforderung auch cmd.exe genannt, ist es möglich Komman-
dozeilenbefehle zu verarbeiten. Die cmd.exe wird in dieser Arbeit hauptsächlich verwendet,
um mit der MongoDB zu interagieren (vgl. Abbildung 14). Mit dem Befehl
findet eine Navigation in den Ordner des MongoDB Connectors for BI statt. Um eine Verbin-
dung zur Datenbank herzustellen, ist die folgende Kommandozeile notwendig:
Die Funktionsweise der Kommandozeile setzt sich aus folgenden Befehlen zusammen:
mongosqld
Die mongosqld akzeptiert eintreffende SQL-Anfragen und sendet diese weiter an die Mon-
goDB. Anschließend erzeugt sie abfragemögliche Schemata für die ausgewählte Datenbank.
mongo-uri
Der Befehl mongo-uri gibt eine Adresse an, zu der eine Verbindung hergestellt werden soll.
sampleNamespaces
Dieser Befehl wählt bestimmte Collections aus und wandelt sie anschließend in ein Schema
um, damit SQL-Abfragen möglich sind. Wird dieser Befehl nicht angewendet, wandelt der
MongoDB Connector alle vorhandenen Collection in ein Schema um.
auth
Der Befehl auth authentifiziert eingehende Clientanforderungen und benötigt zusätzlich die
Befehle mongo-username und mongo-password
mongo-authenticationSource
Der Befehl gibt die Datenbank an, die die Anmeldeinformationen für den Benutzer enthält.
Nach erfolgreicher Bearbeitung der Befehle durch die Eingabeaufforderung ist eine aktive
Verbindung zur MongoDB hergestellt. Bevor Plant Simulation eine SQL-Abfrage an die Daten-
bank senden kann, ist es notwendig eine ODBC-Datenquelle zu konfigurieren. Unter Windows
gibt es jeweils abhängig des Systemtyps eine ODBC-Datenquellen-Administration. Innerhalb
dieses Systemtools können ODBC Konfigurationen durchgeführt werden. Im Reiter System-
DSN ist es möglich, neue Systemdatenquellen hinzuzufügen (siehe Abbildung 15).
Innerhalb des Fensters der spezifischen Konfiguration (siehe Abbildung 16), ist die Eingabe
unterschiedlicher Informationen erforderlich. Dabei ist auf folgende Punkte zu achten:
1. Die TCP/IP Server-Adresse ist nicht die der MongoDB, sondern die des MongoDB
Connectors, da über den MongoDB Connector eine Verbindung zur Datenbank herge-
stellt wird
2. Der User ist mit der Authentifizierungsdatenbank in einem speziellen Format anzuge-
ben, ansonsten wird die Verbindung blockiert. In diesem Fall besteht der User aus fol-
gender Zusammensetzung: benutzername?source=Authentifizierungsdatenbank
3. Mithilfe der Test-Schaltfläche findet eine Überprüfung der Verbindung statt. Sobald
die Meldung „Connection Successful“ erscheint, ist die Verbindung ordnungsgemäß
eingerichtet
31
Bevor die konfigurierte ODBC-Datenquelle mit Plant Simulation angesteuert und auf die Mon-
goDB zugegriffen werden kann, müssen die Daten in der Datenbank auf Eignung und Kompa-
tibilität untersucht werden. Anschließend findet die Modellierung des Simulationsmodells
statt.
• program_history
• values
• values_actual
• values_alarms
• values_ncprogram
Innerhalb der collection program_history befinden sich alle Programme mit einer Startzeit
und einer Endzeit, die in der Werkzeugmaschine abgespielt wurden. Unter anderem sind dort
unterschiedliche Bearbeitungs-, Einstellungs- und Aufwärmprogramme aufgezeichnet. Alle
anderen collections zeichnen hauptsächlich Werte auf, welche Kräfte, Positionen und Status-
meldungen der Werkzeugmaschine wiedergeben. Da die Werte der anderen collections nur
den aktuellen Zeitpunkt aufzeichnen, zu der je ein Ereignis aufgetreten ist, ist es nicht möglich
die exakte Dauer der Ereignisse zu bestimmen. Zudem sendet die Werkzeugmaschine keine
32
Statusmeldungen an die Datenbank, die die Beendigung von Ereignissen beschreiben. Somit
können unter anderem Alarmmeldungen nicht genau einem Vorgang zugeordnet werden.
Zwar verfügt die Werkzeugmaschine über ein Andonsystem, welches den aktuellen Betriebs-
zustand an die Datenbank sendet, dieses findet aber nach Auswertung aufgrund der erhebli-
chen Inkonsistenz keine Verwendung. Folglich sind nicht alle Daten für die Integration der
Werkzeugmaschine in die Simulation verwendbar und geeignet.
Das Simulationsmodell aus Abbildung 17 setzt sich aus folgenden Bausteinen zusammen:
• Quelle
• Einzelstation (Werkzeugmaschine)
• Einzelstation (Arbeitsstation)
• Senke
Die Quelle ist für die Produktion der fünfzig Werkstücke verantwortlich und sendet diese nach
einander an die Werkzeugmaschine. Auf der Werkzeugmaschine finden mithilfe der Daten
aus der Datenbank zum einen unterschiedliche Rüstvorgänge statt und zum anderen indivi-
duelle Bearbeitungen der Werkstücke. Nachdem die Bearbeitung der Werkstücke abgeschlos-
sen ist, werden die Werkstücke an die Arbeitsstation übergeben. Die Arbeitsstation ist für die
Fertigstellung der Werkstücke verantwortlich und übermittelt die Werkstücke abschließend
an die Senke. Die Senke bildet die Endkomponente der Simulation und vernichtet die fertig-
gestellten Werkstücke wieder.
33
Um die Funktionsweise der Rüst- und Bearbeitungsvorgänge auf der Werkzeugmaschine de-
tailliert beschreiben zu können, wird sie in die folgenden Teilbereiche untergliedert:
• Datenimport
• Erzeugung der spezifischen Bearbeitungszeiten
• Simulation von individuellen Rüstvorgänge
Datenimport
zu vermeiden, dass der Simulationslauf mit unvollständigen oder fehlerhaften Daten ausge-
führt wird, wird die Methode zu einer Init-Methode umgewandelt, die vor jedem Simulati-
onslauf automatisch startet und eine Datenabfrage durchführt.
Für die Erzeugung der individuellen Bearbeitungszeiten, müssen die Daten der Tabelle Roh-
Bearbeitungszeiten (vgl. Abbildung 20) ausgewertet und zusammengefasst werden. Dies er-
folgt mithilfe der Methode variableBearbeitungszeit (vgl. Abbildung 21). Innerhalb der Me-
thode laufen unterschiedliche Schleifen ab, die anhand der Tabellenspalten: name, start und
end nach jeweils acht Bearbeitungsschritten die Bearbeitungszeit für ein Werkstück berech-
nen und in einer neuen Tabelle namens variableBearbeitung (vgl. Abbildung 19) speichern.
Zusätzlich zu den acht Bearbeitungsschritten an einem Werkstück kann es vorkommen, dass
einzelne Bearbeitungsvorgänge desselben Typs, aufgrund einer nicht vollständigen oder einer
fehlerhaften Bearbeitung in der Werkzeugmaschine, wiederholt wurden. Dies führt zu einem
individuellen Anstieg der Bearbeitungszeit und muss ebenfalls in der Methode berücksichtigt
werden. Nachdem die Methode vollständig durchlaufen ist, sind fünfzig Werkstücke mit spe-
zifischen Bearbeitungszeiten in der Tabelle variableBearbeitung gespeichert. Sobald ein
Werkstück auf der Einzelstation eintrifft, wird die benötigte Bearbeitungszeit aus der Tabelle
variableBearbeitung ausgelesen und an die Einzelstation übergeben.
35
Die Simulation der Rüstvorgänge wird mithilfe der Aufwärmprogramme realisiert, die zu Be-
ginn eines jeden Produktionstages, vor der Bearbeitung der Werkstücke, an der Werkzeug-
maschine durchgeführt wurden. Die Aufwärmprogramme dienen dazu, die Bestandteile der
Werkzeugmaschine - wie beispielsweise Sensoriken - hinsichtlich Funktionalität zu überprü-
fen. Um die Rüstzeiten aus den Aufwärmprogrammen zu generieren, wird die Methode Rüst-
werte (vgl. Abbildung 23) erstellt, die zunächst die Gesamtaufwärmzeit, sowie die dazugehö-
rigen bearbeiteten Werkstücke pro Tag aus den Tabellen Rohrüstdaten und RohBearbeitungs-
zeiten berechnet und in die Tabelle Rüstdaten speichert. Eine zusätzliche Methode namens
Rüsten liest die einzelnen Werte in der Tabelle Rüstdaten (vgl. Abbildung 22) aus und erzeugt
immer dann einen Rüstvorgang an der Einzelstation, wenn das erste zu bearbeitende Werk-
stück auf der Einzelstation eintrifft. Ein weiterer Rüstvorgang wird ausgelöst, sobald die An-
zahl der behandelten Werkstücke mit der Anzahl der Werkstücke aus der Tabelle Rüstdaten
übereinstimmt. Durch diese Technik finden eine Reihe von Rüstvorgängen während der Si-
mulation statt und die Daten der Aufwärmprogramme werden sinnvoll in das Simulationsmo-
dell integriert.
37
Abschließend erfolgt die Fertigstellung der Werkstücke auf einer Arbeitsstation. Dabei basie-
ren die Bearbeitungszeiten der Arbeitsstation auf rein hypothetischen Werten, um das Zu-
sammenspiel zwischen realen und fiktiven Daten innerhalb der Simulation darstellen zu kön-
nen.
Bearbeitungszeit in Minuten
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Werkstücknummer
Abbildung 26: XY-Diagramm der Bearbeitungszeiten pro Werkstück
Alternativ zur klassischen Anbindung aller Daten, kann über den Mittelwert und einer an-
schließenden Normalverteilung ebenfalls eine Simulation durchgeführt werden. Dies ist vor
allem dann empfehlenswert, wenn nicht alle Daten zur Verfügung stehen oder eine Simula-
tion auch nach Verwendung aller Daten weiterlaufen soll. Für die Umsetzung in Plant Simula-
tion wird zunächst die Methode Mittelwertberechnung erstellt (vgl. Abbildung 27). Innerhalb
dieser Methode wird aus allen Daten der Mittelwert berechnet und anschließend in die Ta-
belle Normalverteilung übertragen. In der Tabelle Normalverteilung befinden sich der Mittel-
wert, die Oberschranke, die Unterschranke, sowie das festgelegte Sigma. Die Oberschranke
definiert sich aus der Addition des Mittelwerts und des Sigmas, die Unterschranke aus der
Division des Mittelwerts und des Sigmas. Das Sigma legt die Standardabweichung der Vertei-
lung fest. Bei Betrachtung der vorhandenen Daten wird ein Sigma von drei Minuten ange-
nommen. Die Methode Mittelwertberechnung erzeugt vor der Bearbeitung eines Werkstücks
mithilfe der Formel für die Normalverteilung eine Bearbeitungszeit und übergibt sie an die
Werkzeugmaschine. Daraufhin bearbeitet die Werkzeugmaschine die Werkstücke mit den
vorgegebenen Bearbeitungszeiten und übergibt sie anschließend an die Arbeitsstation. Somit
kann das Verhalten der Werkzeugmaschine auf unterschiedliche Art in einer Simulation un-
tersucht werden.
40
Die Verwendung einer ODBC-Schnittstelle in Plant Simulationen bietet sich an, um das Ver-
halten eines realen Prozesses, mithilfe aufgezeichneter Daten, in einer Simulation zu unter-
suchen. Des Weiteren können reale Prozesse in verschiedene Simulationsszenarien digital ab-
gebildet und analysiert werden. Dazu ist eine konsistente Aufzeichnung der Daten in einer
41
Datenbank erforderlich. Ansonsten können Fehler und somit falsche Aussagen aus dem be-
trachteten System resultieren. Eine Echtzeitdatenanbindung ist mit einer ODBC-Schnittstelle
nicht möglich, da das Ereignis in Form eines Datensatzes erst an die Datenbank übermittelt
wird, sobald es abgeschlossen ist.
Im folgenden Abschnitt wird zunächst die Erstellung des OPC UA-Servers detailliert beschrie-
ben. Anschließend erfolgt die Anbindung des erzeugten OPC UA-Servers an ein Simulations-
modell. Zum Schluss findet eine Beurteilung und Auswertung der Methode statt.
5.2.1 Programmierung eines OPC UA-Servers für die Herstellung einer Datenanbin-
dung
Dieser Abschnitt behandelt die Programmierung eines OPC UA-Servers, der Bearbeitungs- so-
wie Störprogramme simuliert. Für die Realisierung des Servers sind folgende Komponenten
notwendig:
• Python 3.8.5
• Eclipse IDE
• UA-Expert
Mit Python, einer universell anwendbaren Programmiersprache, wird der OPC UA-Server er-
stellt. Dabei findet die eigentliche Programmierung mithilfe des Entwicklerwerkzeuges Eclipse
42
IDE statt. Eclipse IDE ist ein weitverbreitetes Tool für die Entwicklung von Softwareanwen-
dungen. Die Clientanwendung UA-Expert dient dazu, anschließend die Funktionalität des OPC
UA-Servers zu überprüfen.
Sobald Python installiert ist, muss zunächst ein Basispaket für einen OPC UA-Server in Python
heruntergeladen werden. Dieses Basispaket ermöglicht es, einen vorprogrammierten Grund-
aufbau eines OPC UA-Servers zu verwenden und vereinfacht die Programmierung eines OPC
UA-Servers. Über die Windows Eingabeaufforderung ist in das Verzeichnis, in dem sich Python
befindet, zu navigieren. Anschließend findet durch die Eingabe des Befehls
der Import des Basispakets statt. Danach kann die Programmierung des Servers in Eclipse IDE
beginnen.
In der Benutzeroberfläche des Entwicklerwerkzeuges wird über die Registerkarte File ein
neues Python-Projekt und eine dazugehörige Datei namens server.py erstellt (vgl. Abbildung
29). Innerhalb der server.py ist der Programmcode für den OPC UA-Server zu definieren. In
den ersten Kommandozeilen lädt das Modul alle benötigten Pakete herunter, die im Laufe
des Programms Anwendung finden. Um den OPC UA-Server mithilfe eine Clientanwendung
ansteuern zu können, wird eine URL festgelegt, über die der Server erreichbar ist. Im An-
schluss daran, wird eine objektorientierte Node erzeugt, die die Werkzeugmaschine darstellt.
Für die Simulation von verschiedenen Daten, sind zusätzlich variable Nodes notwendig. Diese
sind in Zeile 19-22 programmiert.
Abbildung 29: Die Eclipse IDE Benutzeroberfläche mit einem Auszug aus dem Programmiercode des OPC UA-Servers
43
Die Hauptaufgabe des Servers ist es, Bearbeitungen und zufällig eintretende Störungen zu
simulieren. Dabei sind die Bearbeitungs- sowie Störzeiten variabel definiert. Die Verfügbar-
keit der Werkzeugmaschine ist mit einer geeigneten Verteilungsmethode auf 80% gesetzt. In
zufälligen Zeitabständen generiert der Server Störungen, die unterschiedlich lang andauern.
Sobald der Fehler behoben ist, startet die Bearbeitung der Werkstücke erneut (vgl. Abbildung
30). Die beschriebene Programmierung ist bei der Verwendung eines realen OPC UA-Servers
nicht notwendig, da die Werkzeugmaschine automatisch die Daten an den OPC UA-Server
senden würde.
Der Server startet durch das Öffnen der server.py-Datei, die sich im Eclipse-Verzeichnis befin-
det. Um die Funktionalität des Servers und der einzelnen Variablen überprüfen zu können, ist
die Clientanwendung UA Expert notwendig. Innerhalb der Benutzeroberfläche ist über die
Toolbox ein neuer Server hinzuzufügen. Nachdem eine Verbindung zum Server hergestellt ist,
zeigt das mittlere Fenster den Status aller Variablen an (vgl. Abbildung 31). Sobald der Sta-
tuscode aller Variablen: Good ist, kann die Anbindung des Servers an Plant Simulation begin-
nen.
44
• Quelle
• Werkzeugmaschine (Einzelstation)
• Arbeitsstation (Einzelstation)
• Senke
Für die Anbindung des OPC UA-Servers an Plant Simulation, ist der Schnittstellenbaustein OP-
CUA notwendig. Innerhalb des Eingabefensters ist zunächst die IP-Adresse des OPC UA-Ser-
vers anzugeben. Anschließend sind über die Schaltfläche Elemente der Gruppenname, der
45
Namensraum sowie die Lese- und Schreibintervalle einzutragen (vgl. Abbildung 31). Der Grup-
penname ist frei definierbar. Der Namensraum ist fest durch den Server festgelegt. Die Lese-
und Schreibintervalle sind frei wählbar und in Millisekunden anzugeben. Ein Standardwert
hierfür ist 50.
Die zu einem Namensraum zugehörigen Variablen sind nach Fertigstellung des Elements in
einer weiteren Tabelle einzutragen (vgl. Abbildung 32). Der Bezeichner beschreibt die eindeu-
tige Identifikation einer Variable und ist somit fest durch den Server vorgegeben. Plant Simu-
lation füllt automatisch den Datentyp der Variablen aus. Der Alias ist für die Beschreibung der
Variablen zuständig. Sind alle Werte ordnungsgemäß eingetragen und die Kontrollleuchte des
Bausteins auf grün, ist eine Verbindung zwischen Plant Simulation und dem OPC UA-Server
hergestellt. Die aktuellen Werte der Variablen sind in einer zusätzlichen Tabelle einsehbar
(vgl. Abbildung 33).
Abbildung 35: Tabelle für den Status aller Variablen des OPC UA-Servers
Der OPC UA-Server ist in Echtzeit mit Plant Simulation verbunden und sendet den Status aller
Variablen im Millisekunden-Bereich an die Simulationssoftware. Die Methode Bearbeitung
greift auf alle Werte zu und übergibt sie an die Einzelstation (Werkzeugmaschine) in Plant
Simulation (vgl. Abbildung 34).
Sobald der OPC UA-Server startet, muss die Simulation ebenfalls innerhalb von 10 Sekunden
beginnen, um einen synchronen Verlauf der Bearbeitung zu gewährleisten. Mit einem OPC
UA-Server, der mit einer realen Maschine verbunden ist, ist dieser Schritt nicht notwendig,
da der OPC UA-Server in diesem Fall keine Bearbeitungszeiten simulieren muss. Während ei-
nes Simulationslaufes bearbeitet das Simulationsmodell Werkstücke in Abhängigkeit der
Werte des OPC UA-Servers. Wechselt die Werkzeugmaschine in den Störungsbetrieb, ist die
Einzelstation der Simulation ebenfalls gestört. Nachdem die Bearbeitung der Werkstücke auf
der Werkzeugmaschine fertiggestellt ist, findet eine abschließende Behandlung der Werkstü-
47
cke auf einer Arbeitsstation statt. Die Produktivität der Werkzeugmaschine kann laufend mit-
hilfe eines geeigneten Diagramms untersucht werden (siehe Abbildung 35). Somit ist eine di-
gitale Abbildung der Werkzeugmaschine in Plant Simulation über einen OPC UA-Server und
einer OPC UA-Schnittstelle erzeugt und in ein Simulationsmodell integriert.
5.2.3 Bewertung des Simulationsmodells und der Datenanbindung mittels einer OPC
UA-Schnittstelle
Das Simulationsmodell aus Abschnitt 5.2.2 bearbeitet Werkstücke in Abhängigkeit von Daten
eines programmierten OPC UA-Servers und zeigt das Plant Simulation grundsätzlich die Daten
eines OPC UA-Servers verwenden und in eine Simulation integrieren kann. Obwohl die Werk-
zeugmaschine des Digital Labs über einen OPC UA-Server verfügt, kann dieser Server auf-
grund der eingestellten Sicherheitskonfiguration nicht verwendet werden. In den aktuellen
Versionen von Plant Simulation ist nur ein anonymer Zugriff auf einen OPC UA-Server möglich.
Der programmierte OPC UA-Server und die generierten Bearbeitungs- und Störvorgänge die-
nen dazu, generell eine OPC UA-Schnittstelle in Plant Simulation zu untersuchen.
Eine OPC UA-Schnittstelle bietet die Möglichkeit, reale Prozesse eines Unternehmens in Echt-
zeit in einer Simulation zu untersuchen. Dazu sind keine komplexen Abfragen und Methoden
nötig. Der OPC UA-Server listet die Daten des zu untersuchenden Prozesses automatisch nach
einer bestimmten Struktur auf. Plant Simulation importiert die Daten und übergibt sie mit
einer geeigneten Methode an die gewünschten Bausteine. Je nachdem wie viele Prozesse mit
einem OPC UA-Server verbunden sind, können komplette Produktionslinien digital in einer
48
Simulation abgebildet und untersucht werden. Die OPC UA-Schnittstelle kann, wie auch die
ODBC-Schnittstelle, reale Prozesse in verschiedenen Simulationsszenarien analysieren. Des
Weiteren kann eine OPC UA-Schnittstelle unmittelbaren Einfluss auf den verbundenen OPC
UA-Server nehmen und somit Parameter des Servers verändern. Dadurch ist nicht nur eine
Datenabfrage möglich, sondern auch eine Steuerung des Prozesses aus der Simulationssoft-
ware heraus durchführbar.
49
Im Gegensatz zu einer ODBC-Schnittstelle greift eine OPC UA-Schnittstelle auf die Echtzeitda-
ten eines OPC UA-Servers zu. Die Werkzeugmaschine des Digital Labs verfügt über einen kon-
figurierten OPC UA-Server, welcher sämtliche Maschinendaten empfängt. Dieser OPC UA-Ser-
ver ist durch eine Sicherheitskonfiguration geschützt, um einen unbefugten Zugriff auf die
Werkzeugmaschine zu vermeiden. Die aktuellen Versionen von Plant Simulation bieten aus-
schließlich einen anonymen Zugriff auf einen OPC UA-Server an, sodass jeder Zugriffsversuch
der Werkzeugmaschine abgeblockt wird. Um trotzdem eine OPC UA-Schnittstelle in Plant Si-
mulation untersuchen zu können, wird ein OPC UA-Server programmiert, der Bearbeitungs-
sowie Störvorgänge simuliert. Mit dem Simulationsmodell aus Abschnitt 5.2.2 findet eine
Echtzeitanbindung der simulierten Daten des programmierten OPC UA-Servers an Plant Si-
mulation statt. Dabei ist der Grundaufbau der Simulation identisch zu dem Aufbau des ODBC-
50
Modells. Die Werkstücke werden anhand der genierten Bearbeitungszeiten des OPC UA-Ser-
vers bearbeitet und anschließend auf einer Arbeitsstation fertiggestellt. Die Simulation rea-
giert in Millisekunden auf Wertveränderungen des Servers. Mit einem realen OPC UA-Server,
der mit einer operierenden Maschine verbunden ist, kann eine digitale Abbildung erzeugt
werden, die parallel zur Maschine zeitgleich die Werkstücke bearbeitet. Zusätzlich ist eine
OPC UA-Schnittstelle in der Lage, gezielt Parameter des OPC UA-Servers zu verändern. Somit
können neben Datenabfragen auch Prozesse aus der Simulationssoftware heraus gesteuert
werden. Besonders wegen der Integrierbarkeit von Systemen unterschiedlicher Hersteller in
einen OPC UA-Server, eignet sich eine OPC UA-Schnittstelle für die Anbindung von Prozessen
an Plant Simulation.
Literaturverzeichnis
Bracht, U.; Geckler, D.; Wenzel, S. (2018): Digitale Fabrik. Springer Verlag, Berlin.
Edlich, S. (2011): NoSQL. Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken. Hanser
Verlag, München.
Geisler, F. (2014): Datenbanken. Grundlagen und Design. Verlagsgruppe Hüthig Jehle Rehm,
Heidelberg.
Hoffmann, M. (2019): Smart Agents for the Industry 4.0. Springer Verlag, Wiesbaden.
Kuhn T. (2017): Digitaler Zwilling [online]. Was ist ein digitaler Zwilling? Berlin. [Zugriff am:
25.05.2020]. Verfügbar unter: gi.de/informatiklexikon/digitaler-zwilling/.
Luber, S. (2017): Was ist ODBC? [online]. Augsburg. [Zugriff am: 05.06.2020]. Verfügbar unter:
www.bigdata-insider.de/was-ist-odbc-a-626950/.
März, L. et al (2011): Simulation und Optimierung in Produktion und Logistik. Springer Verlag,
Berlin.
MongoDB (2020): MongoDB Connector for BI 2.13 [online]. New York City. [Zugriff am:
07.06.2020]. Verfügbar unter: docs.mongodb.com/bi-connector/master/.
Schüller, A. et al (2019): "Der Digitale Zwilling in der Prozessindustrie". In: atp magazin 1-2, S.
70–74.
Siemens Product Lifecycle Management Software Inc. (2008): Plant Simulation Produktüber-
sicht [online]. Köln. [Zugriff am 20.05.2020]. Verfügbar unter: www.plm.automation.sie-
mens.com/global/de/products/tecnomatix/
sqlite Homepage (2020): About SQLite [online]. [Zugriff am: 12.06.2020]. Verfügbar unter:
www.sqlite.org/index.html.
VDI (2014): VDI-Richtlinie 3633. Simulation von Logistik-, Materialfluss- und Produktionssys-
temen - Grundlagen. Beuth Verlag, Berlin.
Vogel-Heuser, B.; Bauernhansl, T.; Ten Hompel, M. (2017): Handbuch Industrie 4.0. Springer
Verlag, Berlin.
Eigenständigkeitserklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt, nicht ander-
weitig zu Prüfungszwecken vorgelegt, keine anderen als die angegebenen Hilfsmittel be-
nutzt und wörtliche sowie sinngemäße Zitate als solche gekennzeichnet habe.