Entwicklung eines Produktionscockpits für ein energieorientiertes Manufacturing Execution System

Fakultät für

Informatik

Verfasser der Diplomarbeit:

Kai Alexander Eckardt

Neidhartstraße 23 1/2

86159 Augsburg

Telefon:+0821 511419

[email protected]

Fakultät für Informatik

Telefon: +49 821 5586-3450

Fax: +49 821 5586-3499

Bachelorarbeit

Studienrichtung

Informatik

Kai Alexander Eckardt Entwicklung eines Produktionscockpits für ein energieorientiertes Manufacturing Execution System

Prüfer: Prof. Dr. Thomas Rist

Abgabe der Arbeit am: 23.03.2015

Inhaltsverzeichnis

II

Inhaltsverzeichnis Inhaltsverzeichnis ................................................................................................................ II

Abkürzungsverzeichnis ....................................................................................................... 1

1 Motivation ....................................................................................................................... 2

2 Grundlagen, Stand der Technik .................................................................................... 3

2.1 Produktionsplanung und –steuerung ...................................................................... 3

2.2 IT-Systeme in der Produktion ................................................................................. 3

Automatisierungspyramide ........................................................................ 4 2.2.1

Wozu dient Enterprise Resource Planning? .............................................. 4 2.2.2

Manufacturing Execution System .............................................................. 5 2.2.3

Betriebs- und Maschinendatenerfassung .................................................. 6 2.2.4

3 Anforderungserhebung ................................................................................................. 8

3.1 Das Forschungsprojekt FOREnergy ....................................................................... 8

Zielstellung ............................................................................................... 8 3.1.1

Übersicht der Teilprojekte ......................................................................... 9 3.1.2

3.2 Anforderungen an das Cockpit ............................................................................. 10

Maschinenbelegung ändern .................................................................... 11 3.2.1

Maschineninfos anzeigen ....................................................................... 12 3.2.2

Simulation starten und stoppen ............................................................... 12 3.2.3

Simulation wechseln ............................................................................... 12 3.2.4

Einstellungen ändern .............................................................................. 13 3.2.5

3.3 Der FOREnergy Prototyp...................................................................................... 13

Zielsetzung ............................................................................................. 13 3.3.1

Architektur Vorgaben des Prototypen ..................................................... 14 3.3.2

3.3.2.1 Hardware ................................................................................ 14

3.3.2.2 Software ................................................................................. 15

4 Konzeption der grafischen Bedienoberfläche ........................................................... 16

4.1 Auswahl von Bedienkonzepten in der Produktionsplanung ................................... 16

Andon Board/System .............................................................................. 16 4.1.1

Produktionscockpit .................................................................................. 17 4.1.2

Leitstand ................................................................................................. 18 4.1.3

4.2 Elemente einer Grafischen Oberfläche ................................................................. 19

Kreisdiagramm ........................................................................................ 19 4.2.1

Liniendiagramm ...................................................................................... 21 4.2.2

Säulen/Balkendiagramm ......................................................................... 22 4.2.3

Zeigerinstrument ..................................................................................... 23 4.2.4

Gantt-Diagramm ..................................................................................... 24 4.2.5

Inhaltsverzeichnis

III

4.3 Konzeptentwicklung der Ansichten ....................................................................... 24

Ansicht der Fabrik ................................................................................... 25 4.3.1

Ansicht des Verlaufs ............................................................................... 26 4.3.2

Ansicht der Aufträge ............................................................................... 27 4.3.3

5 Implementierung des Cockpits ................................................................................... 29

5.1 Techniken zur Umsetzung .................................................................................... 29

HTML ...................................................................................................... 29 5.1.1

CSS ........................................................................................................ 30 5.1.2

JavaScript ............................................................................................... 32 5.1.3

Responsive Webdesign .......................................................................... 33 5.1.4

5.2 Teilaufgaben der Implementierung ....................................................................... 34

Erstellen der Fabrikansicht mit Blender ................................................... 34 5.2.1

Erstellen eines eigenen Zeigerdiagrammes ............................................ 35 5.2.2

Auswahl der Diagrammbibliothek ............................................................ 37 5.2.3

Grundlegender Aufbau mit Bootstrap ...................................................... 40 5.2.4

Zustandsdiagramm ................................................................................. 41 5.2.5

Realisierung der Auftrags-Verschiebung ................................................. 42 5.2.6

5.3 Umfang des implementierten Cockpits ................................................................. 45

6 Evaluation ..................................................................................................................... 47

6.1 Ablauf der Evaluation ........................................................................................... 47

6.2 Befunde ................................................................................................................ 48

6.3 Befragung zur subjektiven Bewertung .................................................................. 49

6.4 Diskussion der Ergebnisse ................................................................................... 51

7 Zusammenfassung und Ausblick ............................................................................... 52

8 Abbildungsbezeichnungen ......................................................................................... 55

9 Literaturverzeichnis ..................................................................................................... 57

10 Anhänge ....................................................................................................................... 59

11 Verzeichnis verwendeter Software ............................. Fehler! Textmarke nicht definiert.

12 Inhalt der Daten-DVD ................................................................................................... 65

Eidesstattliche Erklärung................................................................................................... 66

Abkürzungsverzeichnis

1

Abkürzungsverzeichnis BDE Betriebsdatenerfassung

CSS Cascading Style Sheets

ERP Enterprise Resource Planning

GPL General Public License

JS JavaScript

MDE Maschinendatenerfassung

MES Manufacturing Execution System

MRP II Manufacturing Resource Planning

MRP Material Requirements Planning

MVC Model View Controller

PPS Produktionsplanungs- und Steuerungssystem

SAP MII SAP Manufacturing Integration and Intelligence

SPS Speicherprogrammierbare Steuerung

SVG Scalable Vector Graphics

TGA Technische Gebäudeausrüstung

W3C World Wide Web Consortium

Motivation

2

1 Motivation Elektrische Energie wird gegenwärtig nicht sehr nachhaltig erzeugt. Im Jahre 2014 wur-

den nur 27% des Stroms aus erneuerbaren Energien gewonnen (Burger, 2015). Die

dadurch entstehenden Probleme sind: ein enormer Ressourcenverbrauch und eine hohe

Emission von Treibhausgasen. Dies wiederum führt zu einer Gefährdung unserer natürli-

chen Lebensgrundlagen. Katastrophen wie zuletzt in Fukushima haben gezeigt, dass

auch die Atomkraft nicht so sicher ist, wie immer angenommen wurde. Die Lösung dieser

Problematik ist der Umbau der Energieversorgungssysteme, hin zu einer effizienteren und

nachhaltigeren Energieerzeugung (Umweltbundesamt, 2012).

Um eine solche Energiewende zu erreichen, müssen volatile Energien wie Wind, Solar,

Wasser und Biomasse ausgebaut werden und die bisherigen Energiequellen ersetzen.

Kernkraftwerke erfüllen aber durch ihre Auslastung von 97,6% die Rolle von Grundlast-

kraftwerken (Burger, 2015).

Die dadurch entstehenden Kosten und das Wegfallen der Grundlast, führt zu einer sin-

kenden Versorgungssicherheit, schwankenden und allgemein höheren Preisen von elekt-

rischem Strom. Aus diesem Grund sind Unternehmen gefordert, ihre Fabriken und Pro-

duktionssysteme so zu planen und zu gestalten, dass diese flexibel auf das Stromangebot

reagieren können. Ziel ist es, den Verbrauch und damit die Auslastung möglichst vieler

Maschinen eines produzierenden Unternehmens an das aktuelle Stromangebot anzupas-

sen. Dadurch ist es möglich, den Anstieg der Stromkosten gering zu halten und somit die

Wettbewerbsfähigkeit mit ausländischen Firmen zu wahren (Fraunhofer, 2012).

Die Produktionsplanung ist durch den Einsatz von Techniken wie ERP (Enterprise Res-

source Planning) und MES (Manufacturing Exekution System) bereits abgedeckt. Der

Faktor Energieeffizienz und die Darstellung des Stromverbrauchs ist jedoch noch eine

recht neue Entwicklung. Auf diesem Gebiet besteht daher noch Forschungsbedarf,

wodurch die Entwicklung eines Produktionscockpits, das diese Anforderungen berück-

sichtigt, notwendig ist.

Grundlagen, Stand der Technik

3

2 Grundlagen, Stand der Technik Das Produktionscockpit stellt ein Frontend für die Überwachung des Energieverbrauchs

einer Fabrik dar und bildet einen kleinen Teil eines größeren Forschungsprojektes. Die

Projektgruppe Ressourceneffiziente Mechatronische Verarbeitungsmaschinen (RMV) des

Fraunhofer Instituts für Werkzeugmaschinen und Umformtechnik (IWU) ist für die For-

schungen verantwortlich und wird dabei von 33 Industriepartnern unterstützt (Fraunhofer

IWU RMV, 2015).

2.1 Produktionsplanung und –steuerung

Die Produktionsplanung und –steuerung (PPS) umfasst die Betriebswirtschaftslehre, Ma-

schinenbau, Wirtschaftsingenieurwesen und insbesondere die Wirtschaftsinformatik. Be-

rücksichtigt werden dabei operative, zeitliche, mengenmäßige und räumliche Planung,

Steuerung und Kontrolle und die Überwachung aller Vorgänge, die für die Produktion von

Gütern und Waren notwendig sind.

Die PPS dient somit zur Planung aller die Produktion betreffender Prozesse. Dazu sind in

einem PPS-System alle Daten der Fabrik, der Aufträge und der Produkte hinterlegt. Die

Aufgaben eines PPS sind sehr vielseitig und reichen von Planungen über den Standort

und die Maschinenbelegung der Fabrik bis hin zur Freigabe einzelner Aufträge. Am wich-

tigsten ist jedoch die Planung der Fertigung in einem mittelfristigen Zeitraum. Dazu gehö-

ren Aussagen darüber, was produziert werden soll, welches Personal, Material und Werk-

zeug dafür benötigt wird, und ob es für den geplanten Zeitraum verfügbar ist. Bei der kon-

kreten Planung ist es die Aufgabe, eine Reihenfolge in der Fertigung festzulegen, um Fris-

ten und Termine einzuhalten. Im Falle von ausfallenden Produktionsanlagen oder kurzfris-

tig eintreffenden Kundenaufträgen muss die PPS ebenfalls regieren können.

2.2 IT-Systeme in der Produktion

In Fabriken fallen viele Daten über Maschinen, Aufträge, Personal, Material und weitere

für die Produktion erforderliche Güter an. Die Erfassung dieser Informationen erfolgt heute

automatisch mit Hilfe von Computersystemen. Dabei kommen verschiedene Arten von

Software zum Einsatz, die sich in Umfang und Anwendungsbereich unterscheiden. Viele

dieser Techniken sind bereits vor dem Einsatz von IT-Systemen eingeführt worden und

wurden erst im Laufe der Zeit in Form von Software abgelöst.


4

Automatisierungspyramide 2.2.1

In der industriellen Fertigung kommt Leit- und Steuerungstechnik auf verschiedenen Ebe-

nen zum Einsatz. Die Automatisierungspyramide dient der Einordnung dieser Techniken

und Systeme. Jede Ebene hat in der Produktion eine eigene Aufgabe, bei der spezifische

Techniken der analogen wie auch der digitalen Datenübertragung und –verarbeitung zum

Einsatz kommen. Je nach betrieblicher Situation können die Grenzen der Ebenen mehr

oder weniger fließend ausfallen.

Abbildung 1 Darstellung der Automatisierungspyramide (KSB AG, Frankenthal Germany, 2015)

Die in Abbildung 1 gezeigte Pyramide repräsentiert eine allgemeine Darstellung. Je nach

Unternehmen können Ebenen wegfallen, zusammenfallen oder hinzugefügt werden. So

können Unternehmensebene und Betriebsleitebene als Managementebene zusammenge-

fasst werden oder die Leitebene je nach Branche als Prozess-, Verkehrs- oder Gebäude-

leitebene bezeichnet werden.

Wozu dient Enterprise Resource Planning? 2.2.2

Als Enterprise-Resource-Planning-System oder kurz ERP-System bezeichnet man ein

System, dass sämtliche Geschäftsprozesse und Funktionen eines Unternehmens unter-

stützt. Die Bereiche, in denen ERP eingesetzt wird, sind Beschaffung und Materialwirt-

schaft, Produktion, Vertrieb, Forschung und Entwicklung, Anlagenwirtschaft, Personalwe-

sen, Finanz- und Rechnungswesen, Controlling und weitere. Alle diese Bereiche sind

über eine gemeinsame Datenbank verbunden. Durch diese Struktur ist es möglich, in je-

der Phase der Planung und auf jeder Unternehmensebene Unterstützung zu ermöglichen

(Siepermann, 2013).

Feldebene

Steuerungsebene

(Prozess - )Leitebene

Betriebsleitebene

Unternehmensebene ERP

MES

SCADA

SPS

Ein - /Ausgangssignale

Fertigung/Produktionsprozess

P

lan

un

g

Date

n e

rfassen


5

Abbildung 2 Struktur und Verbindung von MRP bis APS über mehrere Unternehmen

ERP kann als eine Fortführung von MRP (Material Requirements Planning) und

MRP II (Manufacturing Requirements Planning) angesehen werden.

MRP wurde in den 1960er-Jahren entwickelt und war nur zur Unterstützung in der Pla-

nung des Materialbedarfs eines fertigenden Unternehmens vorgesehen (Siepermann,

2013). Die Weiterentwicklung MRP II erfasste dann auch andere für die Produktionspla-

nung und -steuerung erforderliche Ressourcen. Erst mit Einführung von ERP-Systemen

wurden alle für die Geschäftstätigkeit eines Unternehmens erforderlichen Ressourcen

erfasst (Kurbel, 2005).

In Kombination mit APS (Advanced Planning and Scheduling) wird der Vorteil von ERP,

alle Prozesse eines Unternehmens zu erfassen, um die Verbindung mehrerer Unterneh-

men erweitert (Abbildung 2). Die Produktionsplanung in einer solchen Lieferkette berück-

sichtigt die Beschaffung der Vorlieferanten und den Absatz an die nachfolgenden Glieder

der Kette.

Manufacturing Execution System 2.2.3

Während die Automation in der Fertigung im Sekundenbereich abläuft, geht es im Bereich

von ERP und APS um mittel- und langfristige Prozesse. Um diese beiden Extreme zu

verbinden, kommt MES (Manufacturing Execution System) zum Einsatz. Dieses versorgt

einerseits das ERP mit allen notwendigen Daten und ermöglicht es andererseits, den Mit-

arbeitern in der Fertigung, die richtigen Entscheidungen zu treffen (Kletti, 2007).

Der Informationsaustausch zwischen Produktion und MES kann in Echtzeit stattfinden

und orientiert sich an den auf den Maschinen und Anlagen verfügbaren Techniken. Ein

MES bildet daher zu jedem Zeitpunkt alle verwendeten Materialen, Maschinen und Hilfs-

APS

Unternehmen 1

ERP

MRP II

MRP

Unternehmen 3

ERP

MRP II

MRP

Unternehmen 2

ERP

MRP II

MRP


6

mittel in der Produktion ab. Den Verantwortlichen wie Planern, Meistern oder Werksleitern

bietet es daher im Fall von Problemen sofort alternative Entscheidungen an. Die Kommu-

nikation zwischen ERP und MES findet dabei deutlich seltener und vor allem mit weniger

Details statt. Die Detaillierung der Informationen nimmt in dem beschriebenen Modell von

unten nach oben ab (Kletti, 2007).

Die gerade beschriebenen Diskrepanzen bei Zeit und Technik zwischen ERP und Produk-

tionsebene haben bereits Anfang der 1990er Jahre zur Entwicklung erster ME-Systeme

geführt. Dazu zählen die Betriebs- und Maschinendatenerfassung (BDE), Personalzeiter-

fassung (PZE) und Zeitwirtschaft und Qualitätsdatenerfassung (CAQ). Diese Systeme

hatten oft keine Verbindung untereinander und waren meist nur als Insellösung anzuse-

hen. Der Begriff MES entstand erst Mitte der 1990er Jahre, als die Einzelsysteme immer

mehr zusammengefasst wurden. Seitdem wurde die Definition vom MES immer mehr

erweitert, weiterentwickelt und mit Datenmodellen angereichert.

Betriebs- und Maschinendatenerfassung 2.2.4

Aktuelle Daten über das Betriebsgeschehen sind sowohl für die Erstellung von Plänen, als

auch für die Aktualisierung bestehender Pläne erforderlich. Sollten bei der Durchführung

eines Planes Ergebnisse eintreten, die von der Planung abweichen, müsste der Plan ver-

worfen und ein neuer erstellt werden. Geschieht dies nicht, besteht eine große Wahr-

scheinlichkeit, dass sich auch die nachfolgenden Abläufe vom geplanten Produktionsge-

schehen entfernen.

Die Betriebsdatenerfassung (BDE) umfasst alle Maßnahmen, die erforderlich sind, um

Betriebsdaten in maschinell verarbeitbarer Form am Ort ihrer Verwendung bereitzustellen

(Kurbel, 2005). Je nach Leistungsspektrum der Betriebsdatenerfassungssysteme rechnet

man auch Vorverarbeitungs- und Aufbereitungsfunktionen zur BDE. Maschinendatener-

fassung (MDE) beschreibt die automatische Erfassung der Daten an den Produktionsan-

lagen. Die Daten werden dabei entweder über die Anlagensteuerung der Maschine oder

spezieller Sensoren ermittelt. Die dadurch erfassten Werte können Informationen über

Umdrehungs- oder Hubzahlen, Takte, Zeitdauern, Temperaturen u. v. m darstellen. Heute

werden zunehmend automatische Technologien zur Erfassung der Daten eingesetzt,

wodurch die Begriffe BDE und MDE oft als Kombination verwendet werden (BDE/MDE).

Diese automatische Erfassung bezeichnet man als Online-Erfassung. Hierbei sind der

MES-Server oder ein spezieller BDE-Rechner direkt mit dem Erfassungsterminal verbun-

den. Dadurch werden die Daten sofort übermittelt, auf Plausibilität geprüft, verarbeitet und

gegebenenfalls an weitere Systeme weitergeleitet. Bei der Offline-Erfassung hingegen

werden die Daten aus einem BDE-Terminal auf analoge Datenträger geschrieben, zwi-


7

schengespeichert und erst später in das MES oder den BDE-Rechner eingegeben

(Kurbel, 2005).

Betriebsdaten sind die im Laufe der Produktionsprozesse anfallenden Daten, wie die

Menge der produzierten Produkte, die dazu benötigte Zeit, die Zustände von Fertigungs-

anlagen, Bewegungen der Güter im Lager, Qualitätsmerkmale und anderes. Als weitere

Angaben sind Ident-Nummern vorhanden, die die zur Identifikation der Daten erforderli-

chen Zahlen erhalten. Weitere Daten, die nicht unmittelbar in das Produktionsgeschehen

eingreifen oder Anwesenheitszeiten des Personals fallen auch in den Bereich Betriebsda-

ten.

Anforderungserhebung

8

3 Anforderungserhebung Das Produktionscockpit dient zur Darstellung von Forschungsergebnissen eines For-

schungsprojektes des Fraunhofer IWU. Als Teilprojekt muss es unterschiedliche Anforde-

rungen, die teilweise von anderen Teilen stammen, berücksichtigen.

3.1 Das Forschungsprojekt FOREnergy

FOREnergy ist ein Projektverbund mit Partnern aus Wissenschaft und Wirtschaft zur Ent-

wicklung und Erforschung der energieflexiblen Fabrik. Der Forschungsverbund besteht

aus insgesamt acht Teilprojekten (Abbildung 3), die innerhalb von drei Jahren Möglichkei-

ten zur effektiven Energienutzung in fertigenden Unternehmen finden sollen.

TP 8: Demonstrator

TP 1:

Transparenz

TP 5:

Produktions-

planung und

-steuerung

TP 6:

Energie-

versorgung

TP 3:

Energiespeicherung

und dez. ErzeugungTechnik

Planung

TP 2:

Anlagenbau

TP 4:

Leitsystem

TP

7: B

ew

ert

un

gwww.FOREnergy.de

Abbildung 3 Verbindung der Teilprojekte im Projektverbund FOREnergy

(Fraunhofer, 2012)

Zielstellung 3.1.1

Effiziente Nutzung von Energie stellt eine Möglichkeit dar, den Stromverbrauch eines pro-

duzierenden Unternehmens zu senken und dadurch die Kosten für die Elektrizität zu ver-

ringern. Eine Möglichkeit, dies zu erreichen, ist das Anpassen der Fertigung einer Fabrik

an den aktuellen Strommarktpreis. Zusätzlich können noch Speicher für Energie, wie Bat-

terien oder Druckluft, verwendet werden, um günstigen Strom zu einem späteren Zeit-

punkt, wenn der mit Strompreis hoch ist, zu verwenden.


9

Übersicht der Teilprojekte 3.1.2

Teilprojekt 1 kümmert sich um ein grundlegendes Verständnis der Energieverbräuche in

der Produktion bzw. der gesamten Fabrik. Die dabei gewonnenen Daten werden in einem

Energiemodell verknüpft.

Um die grundsätzlich mögliche Energieflexibilität, die eine intelligente Steuerung des

Energiebedarfs zulässt, zu erhöhen, gilt es in Teilprojekt 2, vorhandene Technologien im

Bereich der Produktionsanlagen und der technischen Gebäudeausrüstung (TGA) sowie

der Energiespeicherung aus Teilprojekt 3 weiter voran zu treiben.

In Teilprojekt 5 werden innovative Planungs- und Steuerungsansätze entwickelt, mit de-

nen der Energiebedarf eines produzierenden Unternehmens an das Energieangebot an-

gepasst werden kann. Eine weitere wesentliche Grundlage zur Steuerung und Überwa-

chung des Stromverbrauchs ist das Zusammenspielen von konventioneller Fertigungsleit-

technik mit der Netz- und Gebäudeleittechnik. Diese Verknüpfung wird mit Teilprojekt 4

vollzogen, indem Methoden und Strategien zur Steuerung von ME-Systemen entwickelt

werden. Das ME-System soll dadurch in der Lage sein, die von der PPS verfügbaren

lang- bis mittelfristigen Planungen kurzfristig umzusetzen. Hierfür müssen Informationen

über den aktuellen Energieverbrauch der Verbraucher in der Fabrik und über das Ener-

gieangebot, das externen aus dem Energieversorger und intern aus Energiespeichern

besteht, in Echtzeit erfasst werden. Der Zusammenhang dieser Komponenten wird im

Abbildung 4 veranschaulicht.

Energie-DB

Energieangebot

Bestellung (langfristig)

Verbrauch

Bestellung (kurzfristig)

PPS

Produktionsplan

Energieplan

Produktionsergebnis

Steuerbefehle

Energiedaten

Prozessdaten

Verbrauch

Produktionsdaten

Energiedaten

Energieversorger

Automationsebene

Eingriff

Produktionsstatus

Lüftung/Klima Maschinen Energiespeicher

Disponent

Energiemessung

eERP

eMES

Abbildung 4 Zusammenhang aller für das Teilprojekt 4 notwendiger Systeme

(Schultz, Keller, & Reinhart, 2014)


10

Das Produktionscockpit ist dabei eine Schnittstelle zwischen eMES und Disponent. Die

Energiedaten der Fabrik werden auf der Automationsebene gesammelt und dem MES zu

Verfügung gestellt. Das Cockpit nutzt die Daten des MES und stellt sie in einer grafisch

aufbereiteten Form dar. Anhand dieser Daten können dann vom Disponenten Entschei-

dungen bezüglich der Produktionsplanung getroffen werden.

Um die Wirtschaftlichkeit dieser Steuerung zu gewährleisten, bedarf es einer Bewer-

tungsmethode. Diese muss die Konsequenzen der Anpassung abschätzen und mit den

monetären Vorteilen abgleichen. Diese Methode wird in Teilprojekt 7 erforscht.

Die Eingangsdaten für die Bewertung soll die energieflexible Fabrik des Energieversor-

gers erhalten. Damit ist eine übergreifende Optimierung der Energieversorgung möglich.

Die Bereitstellung von Preisfunktionen sowie die technische Ausgestaltung der Anbindung

an das Stromnetz, etwa über sogenannte „Smart Grids“, ist Aufgabe von Teilprojekt 6.

Eine Umsetzung der Forschungsergebnisse erfolgt anhand eines aus simulierten und

realen Elementen bestehenden Demonstrators im Rahmen von Teilprojekt 8.

3.2 Anforderungen an das Cockpit

Die vorliegende Bachelorarbeit konzentriert sich auf die Entwicklung einer grafisch-

interaktiven Bedienoberfläche für den FOREnergy Prototypen. Anforderungen an das

Produktionscockpit (nachfolgend auch nur als „Cockpit“ bezeichnet), werden durch sog.

Use-Cases dokumentiert. Da das Cockpit eine reine grafische Oberfläche ist, gibt es nur

einen Benutzer, welcher Eingaben tätigen kann. Dazu zählen einfache Operationen, wie

das Wechseln oder komplexere Aufgaben, die nachfolgend erläutert werden.

Benutzer

Ansicht ändern

Produktionscockpit

Maschinenbeleg

ung ändern

Maschineninfos

anzeigen

Simulation

stoppen

Simulantion

starten

Simulation

wechseln

Einstellungen

ändern

Abbildung 5 Use-Case Diagramm des Produktionscockpits


11

Die in Abbildung 5 dargestellten Use-Cases werden zur Vereinfachung, folgendermaßen

nummeriert:

U1. Ansicht ändern

U2. Maschinenbelegung ändern

U3. Maschineninfos anzeigen

U4. Simulation starten

U5. Simulation wechseln

U6. Einstellungen ändern

U7. Simulation starten

Maschinenbelegung ändern 3.2.1

In der Fabrik gibt es zwei Arten von Maschinen. Die einen dienen der Abarbeitung von

Fertigungsaufträgen, die anderen der Steuerung von Funktionen der Fabrik. Zudem wird

noch zwischen Aufträgen, wie der Fertigung eines Teils und simplen Zuständen, die kei-

nem Produkt zugeordnet sind, unterschieden.

Die Aufträge der Maschinen sind dabei in ihrer Anzahl unveränderbar und können nur auf

einer speziellen Maschine gefertigt werden. Jedoch soll es dem Nutzer ermöglicht wer-

den, diese in ihrer Reihenfolge, Dauer und ihrem Startzeitpunkt zu verändern. Dies soll

über eine klassische Drag-and-Drop-Funktionalität realisiert werden. Der Benutzer wählt

hierzu einen Auftrag aus, verschiebt ihn entlang der Horizontalen und lässt ihn am ge-

wünschten Punkt los. Zur Veränderung der Dauer eines Auftrages gibt es zwei Möglich-

keiten. Entweder wird der Auftrag mit hohem Energieeinsatz in kurzer Zeit oder energie-

sparend in längerer Zeit erledigt. Dieser Wechsel entspricht daher der Funktionalität eines

einfachen Schalters.

Zustände hingegen können hinzugefügt und entfernt werden. Auf fertigenden Maschinen

kann als einziger Zustand eine Pause zugewiesen werden, während es auf den anderen

Stromverbrauchern mehr als nur eine mögliche Auswahl gibt. Ein Umordnen und Ver-

schieben ist ebenfalls möglich und entspricht der Funktionalität der eines „normalen“ Auf-

trages. Die Dauer kann jedoch in einem begrenzten Bereich, der abhängig von der ver-

bleibenden freien Zeit des simulierten Produktionstages ist, frei gewählt werden. Ein Zu-

stand darf daher nur dann hinzugefügt werden, wenn noch genug freie Zeit vorhanden ist.


12

Die Zustände der Anfangsbelegung sind von Seiten des Programms definiert. Diese Be-

legung soll der Benutzer jederzeit wieder herstellen können. Alle bisher erfolgten Ände-

rungen werden dabei verloren gehen.

Maschineninfos anzeigen 3.2.2

Zu den einzelnen Maschinen in der Fabrik sollen detailliertere Informationen angezeigt

werden können. Dazu gehört ein Text mit Informationen und Beschreibungen der gewähl-

ten Maschine, der die Funktionen der Maschine und deren Möglichkeiten zur Energieeffi-

zienz aufzeigt. Ein Bild einer echten Maschine dient zum besseren Verständnis der Funk-

tion der simulierten Version davon. Außerdem werden der aktuelle Zustand und die aktu-

elle Auslastung des Energieverbrauches sowie die Daten des bisherigen Verbrauchs vi-

sualisiert.

Diese Informationen sollen nicht immer angezeigt werden, sondern nur, wenn es der Nut-

zer wünscht. Zum besseren Verständnis sollen diese Aktionen und Anzeigen an ein Lay-

out der Fabrik gekoppelt sein, sodass die Maschinen auch eine realistische Position und

Verwendung in der simulierten Fabrik haben.

Simulation starten und stoppen 3.2.3

Die Simulation des Produktionscockpits soll steuerbar sein. Hierzu wird vor dem Ablauf

selbiger die Belegung der Maschinen verändert. Entspricht die Verteilung der Aufträge,

Pausen und Zuständen den Wünschen des Benutzers, wird die Simulation gestartet.

Einmal bestätigt, kann die Maschinenbelegung nicht weiter bearbeitet werden. Nach dem

Starten läuft die Simulation bis sie vom Nutzer gestoppt oder die maximale Ablaufzeit er-

reicht wird. Während des Ablaufens werden ununterbrochen die aktuellen Werte ange-

zeigt bzw. der Verlauf der Daten erweitert. Ist eine Simulation beendet, wird sie in die His-

torie der vergangenen Simulationen eingereiht und steht somit zur späteren Verfügung.

Simulation wechseln 3.2.4

Um die Auswirkungen der verschiedenen Belegungen der in der Fabrik befindlichen Ma-

schinen zu veranschaulichen, sollen die vergangenen Simulationen nochmals angezeigt

werden können. Zum einen soll die Auswahl ähnlich der Funktionalität eines Musikplayers

erfolgen, indem man zum vorherigen oder nächsten Ablauf wechseln kann. Zum anderen

soll die Auswahl eines bestimmten Verlaufs möglich sein. Dazu könnte aus einer Liste mit

alle vergangen Simulationen eine bestimmte ausgewählt werden.


13

Beim Darstellen vergangener Simulationen fällt die Anzeige des aktuellen Verbrauchs

weg. Stattdessen werden nur die Werte des Verlaufs aktualisiert.

Einstellungen ändern 3.2.5

Das Produktionscockpit soll später von unterschiedlichen Personen als Demonstrator

verwendet werden. Da nicht alle Elemente der Oberfläche für jeden Demonstrationszweck

erforderlich sind, sollen diese ausgeblendet werden können. Dazu sollen die verschiede-

nen Ansichten über eine einfache An/Aus-Regelung bedient werden können, mit der die

Funktionen geschaltet werden. Damit der Nutzer die Änderungen nicht bei jedem Pro-

grammstart vornehmen muss, sollten die gewählten Einstellungen gespeichert werden

und bei jedem Start automatisch angewandt werden.

3.3 Der FOREnergy Prototyp

Zielsetzung 3.3.1

Zur Kontrolle der Maschinen werden in produzierenden Unternehmen sogenannte Leit-

stände verwendet. Im Rahmen dieser Arbeit sollen ein Konzept und ein Produkt entwickelt

werden, das den neuen Aspekt der flexiblen Energienutzung darstellt und eine Überwa-

chung bzw. Steuerung der Maschinen und Aufträge in Zusammenhang mit dem Stroman-

gebot ermöglicht.

Der Prototyp soll dazu dienen, die Möglichkeiten des Einsatzes energieorientierter Leit-

stände in Fabriken zu testen und Aufschluss darüber geben, wie flexibel der Energiever-

brauch in eine Fabrik überwacht und gesteuert werden kann. Wichtig ist dabei die mögli-

che Einbindung in bestehende Software- und Hardwaresysteme, um den Aufwand bei der

Einbindung in eine reale Fabriksteuerung möglichst gering zu halten. Der Benutzer soll

auf der grafischen Oberfläche des Produktionscockpits verschiedene Eingaben tätigen

und unterschiedliche Werte auslesen können. Dazu gehört das Ändern der Aufträge auf

den Maschinen, wodurch unterschiedliche Maschinenbelegungen und damit verschiedene

Stromverläufe simuliert werden können. Zum Vergleichen unterschiedlicher Belegungen

kann zwischen den Simulationen gewechselt werden. Angezeigt werden der aktuelle Ver-

brauch und die Historie der Maschinen in der Fabrik im Rahmen der gewählten Simulati-

on.

Der Prototyp wird noch nicht in einer echten Fabrik eingesetzt. Stattdessen wird die Fabrik

simuliert. Normalerweise würde eine Maschine Daten generieren und mit einem Server


14

austauschen. Diese Erfassung von Maschinendaten erfolgt auf Speicherprogrammierba-

ren Steuerungen (SPS). Im Rahmen der Simulation werden alle Maschinen von einer ein-

zigen SPS repräsentiert, die Algorithmen nutzt, um eine Fertigung zu simulieren.

Architekturvorgaben des Prototypen 3.3.2

Das Produktionscockpit stellt eine grafische Oberfläche dar, die Daten einer Fabrik an-

zeigt und eine Produktionsplanung ermöglicht. Um die Daten bereit zu stellen und das

Cockpit anzuzeigen, kommt verschiedene Hard- und Software zum Einsatz.

3.3.2.1 Hardware

Durch die Verwendung bestehender Strukturen ist der grobe Aufbau des gesamten Sys-

tems, wie in Abbildung 6 zu sehen, festgelegt. Eine Speicherprogrammierbare Steue-

rung (SPS) steht stellvertretend für alle Maschinen und Anlagen in der Fabrik. Auf ihr

werden das Verhalten der Maschinen simuliert und die Daten generiert, die später als

Verbrauch angezeigt werden. Die Daten werden dann über einen SAP PCo-Clienti an

einen Laptop weitergeleitet, auf dem alle Informationen gesammelt werden und zur Abfra-

ge auf einem Server bereitstehen. Dieser Server setzt zur Verwaltung der Daten das Ma-

nufacturing Integration and Intelligence System (SAP MII) von SAP ein. Das Produktions-

cockpit läuft ebenfalls auf dem Laptop, kann aber auch auf anderen Geräten, die eine

direkte Verbindung zu dem Server aufweisen, angezeigt werden.

Laptop Tablet

LAN WLAN/(Bluetooth)

SPS

Abbildung 6 Aufbau der Hardware des gesamten Systems

Das Produktionscockpit ist somit ein Frontend oder Thin-Client, das der Anzeige und

Steuerung der Simulation dient und keinen direkten Kontakt zu der SPS hat.

i SAP PCo ist eine Softwarekomponente, die den Datenaustausch zwischen einem SAP-System

und branchenspezifischen Standarddatenquellen ermöglicht.


15

3.3.2.2 Software

Die Software teilt sich in drei Bereiche. In das Produktionscockpit als Frontend, das MII

als Server und eine Simulation, die auf der SPS läuft. Innerhalb des MII werden soge-

nannte Transaktionen erstellt, die Daten aus einer Datenbank oder dem PCo einlesen und

weiterverarbeiten. Diese Transaktionen können vom Cockpit in Form von Web-Services

aufgerufen werden, um entweder den Wert der Simulation abzufragen oder die Simulation

zu steuern. Die Simulation wird durch ein eigenständiges Programm auf der SPS reali-

siert. Hierzu wurde mit Matlab ein Ablauf erstellt, der anhand der Maschinenbelegung und

eines fixen Verlaufs der Strompreise die Werte der Maschinen erzeugt.

In nachfolgender Abbildung 7 sieht man die Verbindung aller verwendeten Softwarekom-

ponenten. Für das Cockpit selber ist nur der Kommunikationsweg bis zum MII erforderlich.

SPS

SAP PCo

SAP MII

OPC M1 OPC M2OPC

TGA

OPC

Speicher

Simulation

Parameter

GUI

Dialog Fabrik Dialog VerlaufDialog Aufträge

Trennung zwischen Front- und Backend

Abbildung 7 Die Softwarearchitektur des gesamten Systems

Konzeption der grafischen Bedienoberfläche

16

4 Konzeption der grafischen Bedienoberfläche Zur Verwirklichung der Anforderungen sind verschiedene Visualisierungen erforderlich.

Wie bereits festgestellt, eignet sich dafür eine Kombination aus Dashboard und Leitstand

am besten. Die Grafik soll so einheitlich und übersichtlich sein wie ein Dashboard und

zugleich Steuerungsmöglichkeiten wie ein Leitstand aufweisen.

4.1 Auswahl von Bedienkonzepten in der Produktions-

planung

Zur Kontrolle und Steuerung von einzelnen Maschinen oder ganzen Fabriken kommen

verschiedene Arten von grafischen und meist digitalen Anzeigen zum Einsatz. Dabei gibt

es verschiedene Einsatzgebiete, für die jeweils andere Typen sinnvoll sind. Einige aus-

gewählte Konzepte, die sich im Anwendungsbereich stark unterscheiden, werden im Fol-

genden erläutert.

Andon Board/System 4.1.1

Andon (jap. アンドン) ist eine Methode des Visual Managements, um eine selbsterklä-

rende Symbolik zu erstellen. Vermittelt werden sollen Funktionen und Abläufe einer Ma-

schine oder eines Prozesses. Bei der Darstellung eines Andons handelt es sich um ein

visuelles Signal, wie eine kleine Lampe, die den Zustand einer Maschine wie Produktion,

Leerstand oder Fehler durch eine Signalfarbe anzeigt, siehe Abbildung 8.

Bei einem Andon-Board handelt es sich meist um ein beleuchtetes Display im Produkti-

onsbereich, das den Status eines Produktionssystems ausgibt. Durch Automatisierung

kann im Fehlerfall ein visuelles Signal gegeben werden, das es den Mitarbeitern ermög-

licht, schnell zu reagieren und den Fehler zu beheben oder einen Verantwortlichen zu

holen. Durch den Einsatz von Displays, die unterschiedliche Darstellungen ermöglichen,

kann in definierten Situationen ein Problem „hervorgehoben“ werden, siehe Abbildung 9.


17

Abbildung 8 Einfaches Andon-System mit 3 Zuständen (Welotec Solutions, 2014)

Abbildung 9 Andon-Board für Stillstandzeiten und Fehlerursache (Welotec Solutions, 2014)

Ein Andon-Board sollte daher klar strukturiert und übersichtlich gehalten sein und, wie in

Abbildung 9 zu sehen, nur wenige und dafür wichtige Information anzeigen. Die Darstel-

lung von detaillierten Informationen oder Grafiken ist nicht empfehlenswert und Benutzer-

eingaben sind überhaupt nicht möglich, weil ein Andon-Board oft ein an der Decke befes-

tigtes für alle Mitarbeiter sichtbares Display ist, wie die Ampelleuchte in Abbildung 8. Für

das zu entwickelnde Produktionscockpit ist dieser Typ der grafischen Anzeige daher un-

geeignet, da er nicht alle gewünschten Funktion verwirklichen kann.

Produktionscockpit 4.1.2

Ein Produktionscockpit (engl. Dashboard) ist eine Anzeige- oder Instrumententafel mit

Messanzeigern und Bedienelementen. Während ein Leitstand oft aus mehreren Monitoren

besteht und von mehr als einer Person gleichzeitig bedient werden kann, ist das Produkti-

onscockpit meist nur ein einzelner Bildschirm für einen Arbeitsplatz ohne Funktionen zur

direkten Steuerung der dargestellten Prozesse oder Maschinen. Als reines Instrument zur

Überwachung wird ein Dashboard meist im Browser angezeigt. Dadurch ist es möglich,

die Daten unabhängig vom Anzeigegerät auszulesen. Dadurch wird der Einsatz auf mobi-

len Geräten wie Smartphones und Tablets ermöglicht. Dies wiederum erlaubt eine Kon-

trolle des Unternehmens aus der Ferne.


18

Abbildung 10 Ansicht eines einfachen klar strukturierten Produktionscockpits für einen Bildschirm (Büro Büning, 2014)

Die Darstellung ist deutlich umfangreicher als die eines Andon-Boards und ermöglicht das

Anzeigen von mehr Werten als nur den reinen Zuständen von Maschinen oder der Pro-

duktion. Stattdessen werden, wenn möglich, alle Managementprozesse dargestellt. Im

Vordergrund steht dabei die grafische Visualisierung, die deutlich aufwändiger ausfällt als

bei einem Andon-Board und mehr grafische Anzeigen, wie in Abbildung 10 zu sehen, ent-

halten kann.

Daher wird solch ein Anzeigeinstrument meist im Bereich der Führungskräfte als Informa-

tionszentrum eingesetzt, da hierbei eine direkte Steuerung über das Cockpit nicht erfor-

derlich ist, sondern es eine einheitliche und schnell zu verstehende Oberfläche ist.

Leitstand 4.1.3

Ein Leitstand ist eine technische Einrichtung, die den Menschen bei der Planung und

Steuerung eines Prozesses unterstützt. Wichtig sind dabei meist die Fertigungssteuerung

und die Fortschrittskontrolle eines produzierenden Unternehmens unter terminlichen Ge-

sichtspunkten.

Abbildung 11 Leitstand zur Steuerung und Kontrolle von Überwachungskameras (Peras GmbH, 2014)


19

Aufgabe eines Leitstandes ist die Verteilung der Fertigungsarbeitsgänge auf Betriebsmit-

tel und Arbeitsplätze und die Entgegennahme und Behandlung von Rückmeldungen aus

der Produktion. Hierzu zählen Ereignisse wie der Beginn, das Ende oder auch Störungen

von Arbeitsabläufen. Des Weiteren kann ein Leitstand die Aufträge verfolgen, um den

Fortschritt oder den Zustand der Aufträge zu kontrollieren. Abbildung 11 zeigt einen Leit-

stand, der mehreren Personen zur Kontrolle und Steuerung von Überwachungskameras

dient. Je zuverlässiger die verfügbaren Informationen am Leitstand sind, desto besser

werden die Aufgaben bewältigt (Kurbel, 2005).

Ein Leitstand erfüllt daher alle für das Cockpit benötigten Funktionen, ist aber gleichzeitig

zu umfangreich für das Projekt, das hauptsächlich der Kontrolle und nicht der Steuerung

dient. Eine Mischung aus Leitstand und Dashboard erfüllt alle Anforderungen und bildet

die Grundlage für die Entwicklung des Produktionscockpits.

4.2 Elemente einer grafischen Oberfläche

Eine grafische Oberfläche besteht aus vielen verschiedenen Elementen. Einige davon,

wie Knöpfe, Schieberegler, Textfelder u. a., besitzen nur rudimentäre Funktionen und sind

daher in ihrer Erscheinung und Nutzung nur geringfügig flexibel. Andere Elemente, die

grafisch über mehr Darstellungsmöglichkeiten verfügen, bieten Raum für eigene Gestal-

tung und können zu unterschiedlichen Zwecken und zur Interkation mit teilweise mehrdi-

mensionalen Daten verwendet werden.

Kreisdiagramm 4.2.1

Kreisdiagramme werden auch als Kuchen- oder Tortendiagramm bezeichnet (engl. Pie

Chart). Sie sind eine Darstellungsform für Teilwerte eines Ganzen in Form von Kreissek-

toren eines Kreises. Jeder Sektor stellt einen Teilwert da, wodurch der Kreis die Summe

aller Sektoren ist.


20

Abbildung 12 Kreisdiagramm Abbildung 13 Ringdiagramm

Kreisdiagramme werden häufig für die Darstellung von Verteilungen und Anteilen genutzt.

Dabei sollte die Anzahl der Teilwerte nicht zu groß werden, sonst wird das Diagramm un-

übersichtlich. Sind die Teilwerte zu klein, werden diese ebenfalls schwer erkennbar. Es

empfiehlt sich, die Teilwerte im Uhrzeigersinn geordnet nach ihrer Größe, beginnend beim

größten, anzuzeigen. Zur besseren Unterscheidung der jeweiligen Sektoren sollten ver-

schiedene Farben, Muster und/oder Schattierungen verwendet werden.

Die Sektoren werden durch Linien vom Rand zum Kreismittelpunkt definiert. Die jeweilige

Sektorengröße (als Winkel) wird folgendermaßen errechnet:

𝑊𝑖𝑛𝑘𝑒𝑙 = 360° ∙ 𝑇𝑒𝑖𝑙𝑤𝑒𝑟𝑡

𝐺𝑒𝑠𝑎𝑚𝑡𝑤𝑒𝑟𝑡

Neben dem einfachen Kreisdiagramm aus Abbildung 12 gibt es noch abgewandelte Dar-

stellungen wie das Ringdiagramm in Abbildung 13, das Daten auf mehreren Eben bereit-

stellt. Dadurch können z. B. Stromverbrauch und Ertrag gegenübergestellt bzw. über die

gesamte Produktion einer Fabrik verglichen werden. Wie in Abbildung 14 zu sehen, sind

aber noch weitere Abwandlungen möglich. Die explodierte Darstellung bricht bestimmte

Stücke aus dem Kreis heraus, um diese hervorzuheben oder feiner zu unterteilen. Das

Halbkreisdiagramm dient zur kompakteren Darstellung des Ringdiagramms und kann in

der Mitte mit dem Gesamtwert aller Teilwert versehen werden. Das Polar-Area Diagramm

ist eine Mischung aus Balken und Kreisdiagramm, wobei pro Teilstück zwei Werte darge-

stellt werden und der zweite Wert den Radius des Sektors beeinflusst.

33%

29%

18%

20% 1. Quartal

2. Quartal

3. Quartal

4. Quartal

33%

29%

18%

20% 40%

7% 4%

49%

1. Quartal

2. Quartal

3. Quartal

4. Quartal


21

Abbildung 14 Explodiertes Kreisdiagramm, Halbkreisdiagramm und Polar-Area Diagramm.

Liniendiagramm 4.2.2

Ein Liniendiagramm (auch Kurvendiagramm genannt) dient der grafischen Darstellung

von 2D- oder 3D-Daten in Linienform. Dabei werden zwei oder mehr Punkte durch Linien

verbunden. Das Diagramm wird dazu meist in einem kartesischen Koordinatensystem

gezeichnet.

Die Grenzwerte der Y-Achse müssen nicht bekannt sein, sondern können bei jedem Zei-

chenvorgang neu aus den Daten ermittelt werden. Die Grenzwerte der X-Achse sind

ebenfalls nicht zwingend anzugeben und entsprechen nur einem Bereich, in dem die Da-

ten visualisiert werden.

Das Liniendiagramm eignet sich daher sehr gut, um sich zeitlich ändernde Werte, wie in

Abbildung 15, darzustellen. Dabei wird auf der X-Achse immer ein Bereich fester Größe,

aber von unterschiedlichem Startpunkt, gewählt und die Diagrammdaten regelmäßig ak-

tualisiert und neu angezeigt. Die Y-Achse reicht dann vom minimalen bis zum maximalen

Wert aller bisherigen Daten.

Abbildung 15 Liniendiagramm mit mehreren Achsen.

Auf einer Ache kann auch mehr als eine Kurve bzw. Punktemenge angezeigt werden. Es

ist zudem möglich, mehr als eine X- bzw. Y-Achse zu verwenden. Vielmehr können Werte

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014

-10

-5

0

5

0

2

4

6

8

Data 1

Data 2

Data 3


22

mit unterschiedlichsten Einheiten und Wertebereichen in einem Liniendiagramm darge-

stellt werden. Hierbei ist nur zu beachten, dass die Darstellung übersichtlich bleibt.

Eine Sonderform des Liniendiagrammes ist die gestapelte Form. Hierbei werden die Wer-

te mehrerer Linien aufeinander addiert. Bei einer weiteren Variante gibt es einen Maxi-

malwert, der auf die verschiedenen Kurven verteilt wird, sodass die Summe der Anteile

jedes Punkwertes 100% ergibt.

Säulen/Balkendiagramm 4.2.3

Ein Säulendiagramm, bei sehr schmalen Säulen auch Stabdiagramm genannt, ist ein Di-

agrammtyp, der durch Rechtecke Werte darstellt. Die Breite der Rechtecke ist dabei un-

wichtig, der Wert wird nur über die Höhe abgebildet. Wie im Liniendiagramm wird auch

hier ein Verlauf dargestellt, mit dem Unterschied, dass eine Einteilung in Kategorien ge-

schieht. Die Anzahl der Rechteecke sollte daher nicht zu hoch sein, um die Übersichtlich-

keit zu wahren. Abbildung 16 stellt dieselben Werte wie in Abbildung 15 dar. Die Anzahl

der Werte reduziert sich durch die Säulen, dafür wird das Vergleichen der Werte verein-

facht, weil sich die Daten nicht, wie im Liniendiagramm, überlagern.

Abbildung 16 Säulendiagramm der Werte aus Abbildung 15

Eine Variante davon ist das gestapelte Säulendiagramm, bei dem mehrere Werte durch

übereinander gestapelte Rechtecke angezeigt werden. Eine Gruppierung von mehreren

Rechtecken ist ebenfalls möglich. Hierzu wird der Abstand aller Säulen einer Gruppe ge-

genüber dem Verlauf verringert. Dabei können sich die Pfeiler auch überlappen, um wei-

teren Platz zu sparen. Des Weiteren können auch negative Werte realisiert werden, in-

dem die Säulen Richtung Boden zeigen.

Das Balkendiagramm ist eine gedrehte Form des Säulendiagramms. Die Werte werden

hierbei in der Horizontalen angegeben, während die Verteilung über die Vertikale erfolgt.

Ansonsten sind alle Varianten möglich, die auch mit Säulen realisiert werden können.

-7

-3,5

0

3,5

7

2002 2006 2010 2014

Data 1

Data 2

Data 3


23

Zeigerinstrument 4.2.4

Ein Zeigerinstrument besitzt einen oder mehrere Zeiger zur Darstellung von Messwerten

auf einer Skala. Die Werte können dabei negativ oder positiv sein, der Bereich in dem die

Werte liegen muss aber bekannt sein und ist wären der Nutzung unveränderbar. Der Ein-

satzbereich solcher Anzeigeinstrumente ist begrenzt, wenn es keinen festen Werteberei-

che gibt.

Abbildung 17 Modernes Zeigerinstrument

Abbildung 18 Klassisches Zeigerinstrument

Die Darstellung ist sehr übersichtlich und erlaubt das schnelle Erkennen der Auslastung je

nach Entfernung des Zeigers zum Endausschlag. Anstelle des Zeigers kann auch ein

Ringsegment verwendet werden, das den Bereich vom Nullpunkt bis zum aktuellen Wert

farbig darstellt. Durch Einsatz von Computergrafiken kann diese Farbe in Abhängigkeit

vom Wert geändert werden. Meist wird Grün für den Ursprung und Rot für den Maximal-

wert verwendet. Abbildung 18 zeigt ein Zeigerinstrument, in dem nur der kritische Bereich

farbig markiert wurde. Die vom Wert abhängige Einfärbung wird dann zwischen minimaler

und maximaler Farbe interpoliert. Dadurch wird das Zeigerinstrument zu einem nützlichen

Werkzeug, um die Auslastung einer Maschine oder eines anderen Verbrauchers zu kon-

trollieren. Das Zeigerinstrument kann auch als eine Sonderform des Ringdiagramms an-

gesehen werden. Hierzu gibt es verschiedene Bereiche, auf oder in die die Anzeigenadel

zeigen kann. Diese Bereiche müssen fest definiert sein und können genau wie der ge-

samte Wertebereich nicht verändert werden.

Der Zeiger alleine biete meist keine optimale Möglichkeit, um den Wert exakt abzulesen.

Durch Einblendung des aktuellen Wertes in die Mitte, wie in Abbildung 17 zu sehen, oder

neben die Skala wird dies möglich.

Eine Sonderform des Zeigerdiagrammes ist die lineare Darstellung. Hierbei wird die Skala

auf eine horizontale oder vertikale Ebene abgebogen. Der Zeiger rotiert dadurch nicht

mehr um einen Punkt, sondern bewegt sich linear auf einer Achse.


24

Gantt-Diagramm 4.2.5

Das Gantt-Diagramm ist eine Form des Balkendiagrammes und wird daher auch Balken-

plan genannt. Veranschaulicht wird immer ein zeitlicher Verlauf, aufgeteilt in detaillierte

Schritte. Das Zeitintervall kann dabei von einigen Stunden bis hin zu mehreren Monaten

reichen. Die Aufteilung geschieht entlang der Vertikalen, wodurch das Gantt-Diagramm

Strukturen einer Treppe aufweist, wie sie in Abbildung 19 zu erkennen sind. Die dabei

entstehenden Teilbalken verfügen alle über einen Start- und einen Endzeitpunkt, die Ver-

bindungen zu anderen Balken aufweisen können. Dadurch wird ersichtlich, welche Abläu-

fe einen Vorgänger benötigen oder welche gleichzeitig ausgeführt werden.

Abbildung 19 Beispiel für ein Gantt-Diagramm (Keynotevorlagen.de, 2014)

Zur besseren Übersichtlichkeit kann die vertikale Achse in einer Art Baumstruktur darge-

stellt werden und bei Bedarf können einzelne Äste oder vorher definierte Gruppen „einge-

klappt“ werden.

Im Bereich der Fertigung werden mit diesem Diagramm Maschinenbelegungen geplant

und überwacht. Im Rahmen des Projektes soll eine solche Belegung ebenfalls bearbeitet

werden können.

4.3 Konzeptentwicklung der Ansichten

Die im Rahmen dieser Arbeit zu entwickelnde Benutzeroberfläche soll sich in bestehende

Systeme eingliedern lassen. Die Verwendung von bestehender Software und bekannten

Elementen zu Darstellung von Daten und Werten ist daher erforderlich. Im Folgenden


25

werden die heute am meisten verbreiteten Systeme in Unternehmen und gängige Ober-

flächen skizziert.

Ansicht der Fabrik 4.3.1

Diese Ansicht (Abbildung 20) soll die Aufgabe eines Startbildschirms erfüllen. Daher wer-

den hier nur wenige Werte angezeigt. Stattdessen erhält man einen gröberen Überblick

über die Fabrik. Dies geschieht einerseits durch die Darstellung des Inneren der Fabrik,

andererseits durch einige allgemeine Werte. Hierzu gehört die Temperatur in der Fabrik,

von der die Steuerung und damit der Stromverbrauch der Techni-

schen Gebäudeausstattung (TGA) abhängt, der aktuelle Energieverbrauch der gesamten

Fabrik und der im Stromspeicher vorhandenen Energie. Diese Werte werden in Form von

Zeigerdiagrammen dargestellt. Durch unterschiedliche, vom Wert abhängige Einfärbung

der Bogenfläche, wird hier schnell der Zustand der Fabrik ersichtlich.

20 C°

Temperatur

78kW

Speicher

23kW

Energieverbrauch

Fabrik Verlauf Aufträge Simulation Einstellungen

Abbildung 20 Entwurf der Fabrik-Ansicht

Über die Miniaturansicht der Fabrikausstattung wird der Standort der Maschinen ersicht-

lich und der Bezug zu einer echten Fabrik durch die realistische Gestaltung der Ansicht

gesteigert. Die Maschinen, die im Rahmen der Simulation verwendet werden, können

ausgewählt werden, eine Detailansicht, wie in Abbildung 21, kann angezeigt werden. Die-

se Ansicht besteht aus einem Foto der echten Maschine, mit der wiederum der Bezug zur

Realität hergestellt wird, und einem beschreibenden Text über die Maschine, der Informa-

tionen zu Stromverbrauch, Verwendung und Einsatzgebiet enthält. Die Anzeige des aktu-


26

ellen Verbrauchs erfolgt wieder durch ein Zeigerdiagramm. Zusätzlich gibt es noch ein

Liniendiagramm für den Verlauf. Durch dieses Diagramm wird der Verbrauch der Maschi-

ne bis zum aktuellen Zeitpunkt bzw. während eines Tages ersichtlich. Durch Interaktion

mit dem Diagramm kann der Wert jeder erfolgten Messung zu einem späteren Zeitpunkt

erneut ausgelesen werden.

Maschine1

12kW

0kW

1kW

2kW

3kW

4kW

5kW

6kW

08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00

Lastgang

Zustand: Produzieren

Lorem ipsum dolor sit amet, consetetursadipscing elitr, sed diam nonumyeirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diamvoluptua. At vero eos et accusam et justoduo dolores et ea rebum. Stet clita kasdgubergren.

Abbildung 21 Entwurf des Maschineninfo-Dialogs

Da die Fabrikansicht als Startpunkt des Programmes fungiert, sind hier auch die Logos

der Industriepartner und der Forschungseinrichtungen untergebracht. Um das Layout an

verschiedene Bildschirmgrößen anzupassen, werden die Firmenzeichen je nach Bild-

schirmbreite in eine, zwei oder drei Zeilen umgebrochen. Die Zeigerdiagramme werden

auf kleinen Displays als Steifen über der Fabrikansicht dargestellt. Die Elemente ordnen

sich daher bei kleiner werdender Anzeige immer weiter vertikal an.

Ansicht des Verlaufs 4.3.2

Die zweite Ansicht (Abbildung 22) stellt den Verlauf aller Werte in der Fabrik dar. Dazu

gibt es zwei Haupt-Diagramme, eines für den Verlauf, das andere für die Zustände. Der

Stromverlauf wird wieder als Liniendiagramm dargestellt, wobei auf der X-Achse die Zeit

von 8:00 Uhr bis 20:00 Uhr eingetragen ist und die Y-Achse den jeweiligen Stromver-

brauch in kW angibt. Eine Linie stellt den geplanten Verbrauch dar, der die optimale Aus-

lastung repräsentiert, die andere die Daten des gesamten Verbrauchs der gesamten Fab-

rik.


27

0,00kW

2,00kW

4,00kW

6,00kW

8,00kW

10,00kW

12,00kW

14,00kW

16,00kW

18,00kW

8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00

Plan-Verbrauch

Energieverbrauch

167kW

Heizung

2kW

Kühlung

24kW

Lüftung

Fabrik Verlauf Aufträge Simulation Einstellungen

200kW

Auslastung

45kW

Auslastung

100kW

Auslastung

Maschine 1

Maschine 2

Speicher

TGA

Kolbenspeicher

Aus Betriebsbereit Teillast Volllast Pause

Abbildung 22 Entwurf des Verlauf-Dialogs

Das zweite Diagramm zeigt die zum Verbrauch führenden Zustände jeder Maschine an.

Der Aufbau der Darstellung ähnelt dabei der eines Balkendiagrammes. Die Zustände

werden hierzu in Kategorien zusammengefasst. Das heißt, dass gleichfarbige Balken

nicht denselben Verbauch haben, sondern dass das Verbrauchsverhalten gleich ist.

Neben dem aktuellen Zustand kann auch der aktuelle Verbrauch ausgelesen werden.

Dies erfolgt wieder mit Zeigerdiagrammen, die in dieser Anicht jedoch kleiner ausfallen als

in der Fabrik-Ansicht und nur einen groben Überblick gewähren sollen. Setzt sich eine

Maschine aus weiteren, kleineren, Verbrauchern zusammen, so wird nicht der

Gesamtverbauch, sondern der eines jeden Stromverbrauchers visualisert.

Ansicht der Aufträge 4.3.3

In der Fabrik gibt es verschiedene Stromverbraucher. Deren Verbrauch ist abhängig vom

jeweiligen Zustand der Maschine. Um eine Simulation zu starten, muss eine Belegung für

den simulierten Tag vorhanden sein. Das Programm verfügt über eine standardmäßige

Belegung. Diese soll jedoch geändert werden können.

In der Ansicht der Aufträge (Abbildung 23) sind dazu zwei Diagramme vorhanden. Das

obere zeigt die aktuelle Verteilung der Aufträge an. Jeder Auftrag kann auf die ihm zuge-

ordnete Maschine verschoben werden. Nach dem Verschieben dürfen sich die Aufträge

nicht überlappen. Je nach Art des Zustandes sind verschiedene Aktionen möglich. Aufträ-


28

ge können nur in ihrer Ablaufzeit verändert werden. Zustände hingegen können hinzuge-

fügt, entfernt und in ihrer Dauer frei gewählt werden.

Das Hinzufügen funktioniert dabei über ein Kontextmenü, das über die Freiräume der Ma-

schine aufgerufen werden kann. Nach dem Öffnen dieses Dialogs, gibt es je nach Ma-

schine verschiedene mögliche Zustände, die hinzugefügt werden können. Sollte es keine

freien Zeiten mehr geben, so wird die Hinzufüge-Option ausgegraut und steht nicht zur

Verfügung.

Fabrik Verlauf Aufträge Simulation

Bestätigen

Aufträge auf Maschinen

Produkt F10min

Produkt B16min

Produkt E45min

Maschine 1

Maschine 2

Einstellungen

Zurücksetzen

Produkt C14min

Produkt F35min

0,00kW

5,00kW

10,00kW

15,00kW

20,00kW

25,00kW

30,00kW

Lastgang

Pause7min

Pause1:25min

TGA

SpeicherFüllen23min

Leeren23min

Mittel23min

Schwach23min

Stark2:12min

Abbildung 23 Entwurf des Auftrags-Dialogs

Für das Ändern der Dauer gibt es zwei Möglichkeiten. Zum einen kann das Zahnradsym-

bol benutzt werden, um einen neuen Dialog anzuzeigen. In diesem kann der Wert der Zeit

numerische eingegeben werden, er wird durch einen oberen und eine unteren Schwell-

wert begrenzt. Zum anderen kann das Rechteck, das den Zustand repräsentiert, an den

vertikalen Rändern in die Breite gezogen oder gestaucht werden. Die maximale Streckung

ergibt sich dabei aus der verbleibenden Restzeit des Tages. Über die Schaltflächen am

unteren Rand des ersten Diagramms kann die Simulation entweder mit der aktuellen Ma-

schinenbelegung gestartet oder auf die Standard-Belegung zurückgesetzt werden.

Das untere Diagramm gibt einen groben Überblick über den geschätzten Energiebedarf

eines Tages. Dieser Verbrauch setzt sich aus dem durchschnittlichen Stromverbrauch der

Zustände aller Maschinen zusammen. Ändert sich die Belegung, so muss auch das Lini-

endiagramm aktualisiert werden. Diese Kurve ist jedoch nur ein Anhaltspunkt und reprä-

sentiert nicht den reellen Ablauf, der im simulierten Betrieb der ganzen Fabrik erfolgt.

Implementierung des Cockpits

29

5 Implementierung des Cockpits

5.1 Techniken zur Umsetzung

SAP MII ermöglicht zwei Arten von grafischen Oberflächen. Zum einen Java-Applets, die

aus heutiger Sicht als veraltet betrachtet werden müssen, zum anderen HTML5, das den

Nachfolger von Techniken wie Java-Applets und Flash darstellt (RJ Owen, 2013). Es ist

also ratsam, der Entwicklung im Bereich plattformunabhängiger Benutzeroberflächen zu

folgen und die Oberfläche komplett als Webseite umzusetzen. Als Folge kommen mehre-

re Programmiersprachen, Techniken und Programme zum Einsatz. Im anschließenden

Text werden die wichtigsten davon erläutert.

HTML 5.1.1

Die Hypertext Markup Language (HTML) ist eine Auszeichnungssprache zur Strukturie-

rung digitaler Dokumente mit Texten, Bildern, Hyperlinks und anderen Inhalten. HTML-

Dokumente bilden die Grundlage des World Wide Web (WWW) und werden von

Webbrowsern dargestellt. Dabei müssen nicht alle Elemente einer HTML-Datei angezeigt

werden, sondern es können auch Metainformationen wie Sprache oder Autor des Textes

beinhalten. Entwickelt wird und wurde HTML vom World Wide Web Consortium (W3C)

und der Web Hypertext Application Technology Working Group (WHATWG). HTML ist

eine reine Auszeichnungssprache (Markup Language) und wird als solche auch nicht pro-

grammiert, sondern schlicht geschrieben.

Dem Text einer HTML-Datei wird durch Auszeichnungen (engl. mark-up) von Textstellen

eine Struktur verliehen. Die meisten der HTML-Elemente werden durch einen Starttag und

einen Endtag markiert. Ein Starttag besteht dabei nur aus dem Zeichen < gefolgt vom

Namen des Elements. Geschlossen wird der Starttag mit einem > bzw. mit einem /> im

Falle eines fehlenden Endtags. Besitzt das Element einen Endtag, so beginnt dieser mit

einem </ gefolgt vom Elementnamen und er endet mit >. Zwischen Starttag und Endtag,

falls vorhanden, können weitere Elemente geschachtelt werden. Die Klein- bzw. Groß-

schreibung ist dabei nicht ausschlaggebend. Je nach HTML-Version können diese Regeln

jedoch stärker oder schwächer ausfallen.

Beim Darstellen wird eine HTML-Datei geparsed. Das heißt, dass der Browser die Datei

einliest und anhand der Tags das Dokument rendert. Dabei enthält ein Tag keine Informa-

tionen. Der Browser weiß zwar, dass nach <h1> eine Überschrift kommt, nicht aber, in

30

welcher Schriftgröße oder Schriftart diese darzustellen ist. Die Standardeinstellungen der

Browser zum Formatieren solcher Elemente sind nicht Teil der HTML-Spezifikation.

Eine HTML-Webseite ist immer nach folgendem Grundmuster aufgebaut.

<!DOCTYPE html>

<html>

<head>

<title>Titel der Website</title>

</head>

<body>

Inhalt der Website

</body>

</html>

Im Kopf (head) stehen Informationen zum Titel des Dokuments, Metadaten wie Autor und

Erstelldatum und Links zu weiteren Dokumenten, die der Gestaltung und Funktionalität

dienen. Alle diese Daten fließen jedoch nicht direkt in das angezeigte Dokument ein, son-

dern werden separat verarbeitet. So ist der Titel nur dann sichtbar, wenn der Browser

einen Bereich hat, in dem dieser angezeigt werden kann.

Im Körper (body) stehen die Elemente, die den Inhalt des Dokuments definieren. Dabei

wird zwischen Block- und Inline-Elementen unterschieden. Erstere erzeugen eine Ausga-

be in einem Block, in dem der Inhalt untergebracht wird. Inline-Elemente hingegen verän-

dern den Textfluss nicht. Block-Elemente werden somit in unterschiedlichen Zeilen darge-

stellt, während Inline-Elemente in der Zeile des Eltern-Elements stehen. Mit der Einfüh-

rung von CSS war es jedoch möglich, dieses Erscheinen zu ändern und Elemente freier

zu positionieren.

HTML-Seiten können mittlerweile dynamisch geändert werden. Zur Laufzeit können Ele-

mente hinzugefügt, verschoben und gelöscht werden. Grundlage bildet dabei das

Document Object Model (DOM), das eine Schnittstelle für den Zugriff auf HTML- oder

XML-Dokumente spezifiziert. Diese Operationen erfordern jedoch die Verwendung von

Zusatztechniken. Die am verbreitetsten ist heute JavaScript.

CSS 5.1.2

Cascading Style Sheets, kurz CSS, dienen der vollständigen Kontrolle über das Layout

und die Gestaltung von Webseiten und anderen elektronische Dokumenten. Texte können

so in Form, Farbe, Größe und vielen weiteren Faktoren verändert werden. Bilder können

positioniert und mit Rahmen versehen werden. Elemente können in flexiblen Listen oder

31

Tabellen dargestellt und Übergänge wie bei Dropdown-Menüs animiert werden. CSS wur-

de entwickelt, um die Gestaltung von Webseiten zu vereinfachen. Dabei werden aber nur

bestehende Elemente grafisch und stilistisch verändert. Zusammen mit HTML und DOM

bildet CSS eine der Kernsprachen des World Wide Web.

HTML alleine bietet nur wenige Möglichkeiten zum Design. Bevor es CSS gab, konnten

nur HTML-Elements wie , oder verwendet werden, um Text zu ge-

stalten. Aufwändige Seiten oder gar Effekte waren damit nicht möglich. Mit CSS wurde

daher eine Sprache eingeführt, die solche Effekte ermöglicht und inhaltlich vom HTML-

Dokument getrennt ist. Diese HTML-Stilmittel gelten heute als veraltet und zählen nicht

mehr zum HTML-Standard (Redaktion SELFHTML, 2014). Dadurch kann ein in CSS defi-

nierter Style gegen einen anderen ausgetauscht oder auf eine andere Webseite übertra-

gen werden. Soll ein Dokument gedruckt werden, kann man so für diese Ausgabe eine

andere Darstellung vorgeben. Wird das Dokument auf einem PDA oder Mobiletelefon

dargestellt, kann der Stil so gewählt werden, dass der Text auch auf kleinen Bildschirmen

noch lesbar ist.

Die Zuordnung bestimmter Stile erfolgt über HTML-Tags und Attribute wie Klassen oder

IDs. Diese können wiederum kombiniert werden, sodass man z. B. alle Überschriften in-

nerhalb eines Elements mit einer bestimmten ID anderes formatiert. CSS kann auch auf

bestimmte Ereignisse, wie das Bewegen oder Klicken der Maus auf ein Element, reagie-

ren und so den Stil beim Interagieren mit Elementen unterschiedlich visualisieren.

Erste Vorschläge für Web-Stylesheets gab es von 1993 bis 1995. Ende 1994 veröffent-

lichte Håkon Wium Lie den ersten Vorschlag für Cascading HTML Style Sheets, kurz

CHSS (Lie, 1994). Zusammen mit Bert Bos, der einen Browser namens Argo implemen-

tierte, entwickelte er dann CSS. Das World Wide Web Consortium (W3C) wurde 1994 in

Chicago auf CSS aufmerksam. Nachdem Lie und Bos mit W3C zusammenarbeiteten,

wurde im Dezember 1996 CSS Level 1 Recommendation (CSS1) veröffentlicht (W3C,

2008).

CSS Level 2 wurde im Mai 1998 veröffentlicht, aber erst mit CSS 2.1 als fertiger Empfeh-

lung (Recommendation) am 7. Juni 2011 veröffentlicht (W3C, 2011).

CSS Level 3 wird seit 2000 entwickelt (W3C, 2000). Die mit CSS2 begonnenen Entwick-

lungen werden hier weiter vorangetrieben. CSS3 wird jedoch die letzte Version von CSS

bleiben, wie Vertreter von W3C klarstellten (Atkins, 2012). Stattdessen wird CSS3 in un-

terschiedliche Module unterteilt, die jeweils getrennt weiter entwickelt werden können.

Das Hinzufügen von neuen Elementen, wie verschiedene Grafikfilter, ist ebenfalls möglich


32

(W3C, 2014). Die Versionsnummern werden nur noch in den Modulen vorangetrieben.

CSS3 wird somit in Zukunft einfach nur noch den Namen CSS tragen (Atkins, 2012).

Momentan werden die CSS1-Spezifikationen von allen aktuellen Browsern uneinge-

schränkt unterstützt. CSS2 verarbeiten die meisten Webbrowser weitgehend korrekt.

Auch CSS3 wird von modernen Browsern weitestgehend unterstützt, obwohl das W3C

noch nicht für alle Module eine Empfehlung (Recommendation) herausgegeben hat

(W3C, 2014) Eine Übersicht über alle unterstützen CSS-Eigenschaften erhält man auf

den Seiten von „Can I use“ unter folgender URL: http://caniuse.com/.

JavaScript 5.1.3

JavaScript (JS) ist eine Skriptsprache, die hauptsächlich im Bereich HTML zum Einsatz

kommt, um Benutzerinteraktionen auszuwerten und nachträglich Inhalte zu ändern oder

hinzuzufügen. Heutzutage kommt JavaScript auch auf Microcontrollern und Servern zum

Einsatz (Heise Zeitschriften Verlag, 2013).

JavaScript wird vom Browser in einer sogenannten Sandbox ausgeführt. Dadurch erhält

man im Allgemeinen keinen Zugriff auf das Dateisystem, sondern nur auf Elemente des

Browsers. Zusätzlich läuft jede Webanwendung innerhalb eines isolierten Bereichs,

wodurch eine Webseite nicht auf Informationen einer anderen geöffneten Seite zugreifen

kann. Dies dient zum Schutz des Benutzers vor Cross-Site-Scripting-(XSS)-Angriffen, bei

denen versucht wird, einen Schadcode einzuschleusen, der Daten wie Kontonummern

oder Passwörter bei der Eingabe mitliest.

JavaScript besitzt keine Typsicherheit. Als elementare Datentypen werden Zahlen, Strings

und Boolesche Werte unterstützt. Andere Daten wie Arrays, Datumsangaben oder JSON

werden durch vordefinierte Objekte repräsentiert. JavaScript ist außerdem in der Lage

Datentypen automatisch in Objekte der entsprechenden Konstruktorfunktion umzuwan-

deln oder den Typ zu ändern.

var string1 = new String("Beispieltext");

console.log(typeof string1); // "object"

var string2 = "Beispieltext";

console.log(typeof string2); // "string"

console.log(string1.length); // 12

console.log(string2.length); // 12


33

Die beiden Variablen string1 und string2 sind nicht vom selben Datentyp. Beim Auf-

ruf des Wertes length wird aber automatisch der Wert des String-Objekts zurückgegeben,

ohne das der Nutzer eine Umwandlung vornehmen muss.

string1 = "2";

string2 = "3"

console.log(string1 * 4 * string2); // 24

Bei Rechenoperationen versucht JavaScript automatisch, den Inhalt eines Strings in eine

Zahl umzuwandeln. Sollte der Versuch fehlschlagen, wird mit dem Wert NaN (Nor a Num-

ber) gerechnet und das Ergebnis ist undefiniert.

Responsive Webdesign 5.1.4

Durch Smartphones, Tablets, Notebooks, Desktop-Computer und Fernseher gibt es eine

Vielzahl unterschiedlicher Bildschirmgrößen und Ausrichtungen der Displays. Eine Web-

seite, deren grafischer Aufbau ein responsiv-Design verfolgt, passt ihre Ansicht den un-

terschiedlichen Bildschirmauflösungen, der Größe des Gerätes selbst, der Orientierung

und den Eingabemöglichkeiten an. Die Anpassung kann in zwei Bereichen erfolgen. Zum

einen werden die Elemente der Oberfläche anders angeordnet, zum anderen können Ein-

gaben über verschiedene Methoden wie Knöpfe oder Gesten erfolgen.

Abbildung 24 Unterschiedliche Verteilung der Elemente bei Responsive Design

Während auf einem Desktop-Computer die Elemente horizontal angeordnet werden kön-

nen, werden sie auf einem Smartphone umgebrochen und vertikal angeordnet, wie es in

Abbildung 24 zu sehen ist. Je nach Breite des Bildschirms können mehr oder weniger

Elemente umgeordnet werden, um so auch Displays mit Größen zwischen dem eines

Smartphones und dem eines Desktops bestmöglich auszufüllen. Neben der reinen Um-

ordnung können bestimmte Elemente auch verborgen werden, wenn sie nicht permanent

sichtbar sein müssen oder komplett wegfallen, wenn sie für die Bandbreite der Internet-

verbindung zu komplex sind.

Mit Hilfe dieser Techniken ist es möglich, eine einzige Webseite für alle Geräte zu erstel-

len, indem sich die Darstellung stufenlos dem aktuellen Seitenverhältnis anpasst. Ein re-

Tablet Smartphone Desktop


34

aktionsfähiges Design hat aber nur auf Desktop-Geräten einen Vorteil gegenüber einem

starren. Wird ein Fenster, das eine Webseite anzeigt, verkleinert, wie es die Technik

SNAP von Microsoft erlaubt, passt sich die Darstellung ebenfalls an (Joos, 2010).

5.2 Teilaufgaben der Implementierung

Bei der Umsetzung der Anforderungen und Ansichten mittels HTML5 kommen die Ent-

wicklungsumgebung Eclipse und verschiedene Grafikprogramme zum Einsatz. In HTML-

Code wird zuerst das Grundgerüst der Ansichten erstellt. Diese werden mit Daten befüllt,

die entweder vorhanden sind oder erst noch mit den Grafikprogrammen erstellt werden

müssen. Mit Hilfe von CSS erfolgt dann die Positionierung und Gestaltung der einzelnen

Elemente des Cockpits. Zuletzt wird die Oberfläche um eine Logik erweitert, die für alle

Benutzereingaben und das Ansteuern der verschiedenen Diagramme verantwortlich ist.

Erstellen der Fabrikansicht mit Blender 5.2.1

Blenderii ist eine freie (GPLiii lizenzierte) 3D-Grafiksoftware. Sie ermöglicht das Modellie-

ren, Texturieren, Animieren und Renderniv dreidimensionaler Körper. Blender besitzt zu-

dem einen eingebauten Videoschnitt-Editor und eine Spiele-Engine. Die sehr aktive Ent-

wicklung hat zu einem großen, sich ständig erweiternden Funktionsumfang geführt, der z.

B. die Simulation von Flüssigkeiten oder die Optimierung und Analyse von Objekten für

den 3D-Druck einschließt. Als Skriptsprache wird Python benutzt, wobei es möglich ist,

eigene Skripte nachträglich einzubinden. Dadurch wird Blender zu einem sehr umfangrei-

chen und vielseitigen Werkzeug im Bereich der 3D-Visualisierung.

Der Aufbau der simulierten Fabrik wurde von einem Praktikant erstellt. Dieser hatte hierzu

die Aufgabe, ein beispielhaftes Produkt und die dazu nötigen Produktionsabläufe zu ge-

stalten und die dafür nötigen Produktionsmaschinen auszuwählen. Der von ihm erstellte

Grundriss mit der Maschinenverteilung wurde als Bild in Blender geladen. Anhand der

Grafik konnten alle 3D-Objekte erzeugt oder importiert und anschließend positioniert wer-

den. Zum Gestalten der Maschinen stand eine Bibliothek zu Verfügung, die ein umfang-

reiches Angebot an vorgefertigten Fabrikutensilien enthielt. Im Laufe der Arbeit zeigte sich

jedoch, dass immer mehr Maschinen selbst modelliert werden mussten, um den Ansprü-

ii http://www.blender.org/

iii GPL: General Public License

iv Rendern beschreibt das Umrechnen von 3D-Daten in digitale Bilder


35

chen an eine realistische Darstellung Genüge zu leisten. Produktzeichnungen und Sei-

tenansichten der entsprechenden Maschinen waren dabei sehr hilfreich und erhöhen den

Wiedererkennungswert der 3D-Modelle, die teilweise echten Produkten der Industriepart-

ner nachempfunden sind.

Der meiste Aufwand war für das Bakenv der „Ambient-Occlusion-Maps“ nötig, die zur Ver-

besserung der Qualität der Lichteffekte beitragen, indem sie Objekten eine Umgebungs-

verdeckung hinzufügen. Dadurch erhalten kleine Ritzen und Vorsprünge realistische

Schatten, die unabhängig von einer Lichtquelle sind. Zu Erstellung dieses Effekts werden

die Lichtverhältnisse des Umgebungslichts, die auf ein 3D-Objekt wirken, auf eine Textur

abgebildet. Dieser Vorgang dauert je nach Qualität und Auflösung des Bildes unterschied-

lich lange.

Erstellen eines eigenen Zeigerdiagrammes 5.2.2

In der Fabrik- und der Verlaufsansicht sollen Zeigerdiaramme zum Einsatz kommen. Die

Anforderungen an ein Zeigerdiagramm sind:

Ändern der Grenzwerte zur Laufzeit

Farben in Abhängigkeit vom aktuellen Wert

Schrift- und Zeigergröße abhängig vom Diagrammbereich

Dynamische und automatische Skalierung des Diagrammbereichs

Animation sollte ohne zu Ruckeln ablaufen

Möglichst wenige übersichtige Elemente

Für HTML gibt es bereits Bibliotheken, die diese Anforderungen erfüllen. Die professio-

nellste Darstellung und die meisten Funktionen bietet JustGagevi. Zum Einsatz kommt

hierbei raphael.js, eine weitere Bibliothek, die das Erstellen und Bearbeiten von Vektor-

grafiken vom Typ (Scalable Vector Graphics) SVG erleichtert.

JustGage hat jedoch einige Nachteile. SVG-Grafiken sind auf mobilen Endgeräten nicht

besonders performant. Auf einem Smartphone mit Android 5 liegt die Bildrate bei drei an-

zuzeigenden Diagrammen bei ca. 2 Frames per Second (FPS). Außerdem liegt in der

Bibliothek ein Fehler vor. So funktioniert die automatische Skalierung nicht richtig.

v Baken: Abbilden von bestimmten Modell-Daten z.B. Licht oder Rauheit auf eine Textur

vi http://justgage.com/


36

Fläche mit 400px Breite und 320px Höhe Fläche mit 400px Breite und 400px Höhe

Abbildung 25 Vergleich von JustGage bei unterschiedlicher Diagrammfläche

Der Inhalt des Diagrammes wird nur dann richtig dargestellt, wenn das Verhältnis von

Breite zu Höhe 5 : 4 beträgt. Ansonsten wird der Hintergrund der Zeigerfläche zu weit

gezeichnet und die Zeigerfläche wie in Abbildung 25 zu stark gebogen.

Als Alternative wurde auf eine Eigenentwicklung zurückgegriffen. Grafisch orientiert sich

diese am Stil von JustGage. Die Darstellung erfolgt jedoch nicht in Form einer Vektorgra-

fik, sondern in einem Canvas Element von HTML5. Dazu wird als erstes der Bogen, der

den Hintergrund des Zeigers bildet, gezeichnet. Darauf wird der eigentliche Zeiger gemalt.

Als letztes werden noch der aktuelle Wert, die Grenzwerte und der Diagrammtitel als Text

gezeichnet.

Das Zeichnen der Bögen erfolgt durch Kreissegmente. Der Winkel des ersten Segments

ist fest, während sich der des zweiten aus folgenden Formeln ergibt:

𝑓 =𝑣𝑐𝑢𝑟𝑟𝑒𝑛𝑡

𝑣𝑚𝑎𝑥 − 𝑣𝑚𝑖𝑛

Der aktuelle Faktor des Wertes reicht von 0 bis 1 und wird als Anteil vom gesamten Wer-

tebereich berechnet.

𝑤𝑖𝑛𝑘𝑒𝑙 = 𝑓 ∙ 𝜋

Die Angabe der Winkel erfolgt in Radianten, weshalb der Faktor nur noch mit 𝜋 multipli-

ziert werden muss.

Die Farbe des Segments soll zudem vom Wert abhängig sein. Dazu gibt es die drei Far-

ben Grün(𝑐1), Gelb(𝑐2) und Rot(𝑐3) die je nach Wert interpoliert werden. Eine Farbe be-

steht dabei aus den drei Teilfarben Rot, Grün und Blau. Je nach Faktor wird die Farbe

anders berechnet. Ist der Wert kleiner als 0,5 gilt:

𝑐𝑣 =𝑐1 ∙ (0,5 − 𝑓)

0,5+ 𝑐2 ∗

𝑓

0,5


37

Diese Formel muss für jeden Farbanteil einmal angewandt werden. Ist der Wert größer

als 0,5 gilt:

𝑐𝑣 =𝑐2 ∙ (−𝑓)

0,5+ 𝑐3 ∗

𝑓 − 0,5

0,5

Durch die Nutzung des HTML5-Canvas-Elements ergibt sich bei gleicher Anzahl, Größe

und Optik der Zeigerdiagramme eine Framerate von ca. 12 FPS, was einer Verbesserung

der Performance gegenüber den Diagrammen aus der JustGauge Bibliothek um 500%

entspricht.

Auswahl der Diagrammbibliothek 5.2.3

Zur Darstellung der Historienwerte, wie dem Verlauf des Energieverbrauchs, sollen Lini-

endiagramme verwendet werden. Diese ermöglichen die beste Übersichtlichkeit für fort-

laufende Werte in einem bestimmten Zeitverbrauch. Die Anforderungen an ein Liniendia-

gramm sind:

Mehrere Linien gleichzeitig

Ändern der Werte zur Laufzeit

Berücksichtigung der Zeitkomponente jedes Wertes

Dynamische und möglichst automatische Skalierung des Diagrammbereichs

Anzeigen von Informationen über die Teilwerte

Angabe der Breite des reinen Diagrammbereichs

Die wichtigsten Anforderungen sind dabei die Zeitkomponente und die Breite des Be-

reichs, in dem die Linien gezeichnet werden. Die Werte, die von der SPS ermittelt werden

und vom MII in das Cockpit gelangen, besitzen jeweils einen Zeitstempel. Dieser gibt an,

zu welchem Zeitpunkt der Wert erfasst wurde. Grundsätzlich gibt es zwei Arten, wie An-

gaben für die Linienwerte gemacht werden können. Die erste Möglichkeit besteht darin,

nur die Y-Werte in einem Array anzugeben. Die zweite Darstellung erfolgt wieder in Form

eines Arrays, nur werden hier innerhalb des Arrays Objekte angegeben, die eine Kompo-

nente für den X- und den Y-Wert enthalten.


38

Abbildung 26 Vergleich der X-Komponente eines Linendiagrammes

Berücksichtigt man diesen Zeitwert nicht, so wird der Graph, wie in Abbildung 26 zu se-

hen, fehlerhaft dargestellt. In Abbildung 26 wird ersichtlich, wie sich dies auswirkt. Im lin-

ken Diagramm werden die Werte des Verbrauches im festen Abstand von einer Minute

angetragen. Es ist jedoch nicht für jede Minute ein Wert vorhanden. Der Fehler in der

Darstellung wird dann sichtbar, wenn man den rechten Graphen betrachtet. Hier werden

die Daten anhand ihres X-Wertes angetragen. Die dadurch entstehenden Lücken zeigen,

in welchen Minuten keine Messungen erfolgt sind, und stellen damit den echten Verlauf

der Messungen da.

Neben dieser Art der Datenverarbeitung gibt es noch ein weiteres Problem. In der Ver-

laufs- und der Auftragsansicht befinden sich die Diagramme unterhalb anderer Historien-

werte. Beide haben dabei denselben Wertebereich, der von 8:00 bis 20:00 Uhr reicht. Die

Anzeigen müssen daher denselben horizontalen Bereich der Oberfläche abdecken, um

einen Vergleich der Daten zu ermöglichen.

0

1

2

3

4

5

6

08

:00

08

:02

08

:03

08

:04

08

:06

08

:10

08

:11

08

:12

08

:13

08

:16

08

:17

08

:18

08

:19

0

1

2

3

4

5

6

08

:00

08

:02

08

:03

08

:04

08

:06

08

:10

08

:11

08

:12

08

:13

08

:16

08

:17

08

:18

08

:19


39

0

1

2

3

4

5

6

0

1

2

3

4

5

6

08:00 08:02 08:03 08:04 08:06 08:10 08:11 08:12 08:13 08:16 08:17 08:18 08:19

167kW

Heizung

2kW

Kühlung

200kW

Auslastung

45kW

Auslastung

100kW

Auslastung

Maschine 1

Maschine 2

Speicher

TGA

Kolbenspeicher


167kW

Heizung

2kW

Kühlung

200kW

Auslastung

45kW

Auslastung

100kW

Auslastung

Maschine 1

Maschine 2

Speicher

TGA

Kolbenspeicher


Abbildung 27 Vegleich: Falsche und richte Anpassung der Breite

Beim Zeichnen eines Diagramms definiert man einen Bereich in HTML, in dem das Dia-

gramm angezeigt werden soll. Dieser Bereich dient der Bibliothek als Zeichenfläche.

Problematisch dabei ist, dass alle Komponenten wie X- und Y-Achsen, Linien, Legenden

und Ränder innerhalb des Bereichs angeordnet werden. Zudem erfolgt meist eine Opti-

mierung des Platzverbrauches, wodurch die Breite einer Achse von der Größe der Zahlen

abhängt, die angetragen werden. Für das Produktionscockpit ist es jedoch erforderlich,

die Breite aller Elemente einzeln zu definieren oder die Achsen und Legenden in eigene

HTML-Elemente zu verteilen. Abbildung 27 zeigt die Problematik dieser fehlerhaften Ska-

lierung.

Eine Diagramm-Bibliothek, die im Cockpit eingesetzt werden kann, muss daher diese bei-

den Anforderungen erfüllen. Die einzige kostenlose Softwaresammlung, die dies erfüllte,

war rickshaw.js. Genau wie JustGage greift auch Rickshawvii auf eine Bibliothek für Vek-

torgrafiken zurück, verwendet aber statt raphael.js d3.js. Der Vorteil von Rickshaw besteht

in der Trennung der Diagramm-Elemente. Die Legende, die Diagrammachsen und der

Linienbereich können in verschiedene HTML-Container verteilt werden. Dadurch gelingt

die perfekt Ausrichtung zu den darüber liegenden Diagrammen, weil die Zeichenfläche

der Graphen exakt skaliert werden kann und nicht von Achsenbeschriftungen abhängig

ist. Die Anforderung der Zeitabhängigkeit der Werte erfüllt Rickshaw ebenfalls, da die Da-

ten nach folgender Struktur angegeben werden:

vii http://code.shutterstock.com/rickshaw/


40

[{𝑥: 𝑥1, 𝑦: 𝑦1}, {𝑥: 𝑥2, 𝑦: 𝑦2}, {𝑥: 𝑥3, 𝑦: 𝑦3}, … ]

Der X-Wert steht dabei für die Zeit, der Y-Wert für den Wert zum Zeitpunkt X. Rickshaw

sortiert die Daten jedoch nicht nach ihrem X-Wert, weshalb die Werte bereits in der richti-

gen Reihenfolge übergeben werden müssen.

Grundlegender Aufbau mit Bootstrap 5.2.4

HTML bietet standardmäßig kaum aufwändigere GUI-Elemente wie Nachrichtendialoge

oder Menüleisten. Stattdessen stehen nur einfache Bausteine zur Verfügung, mit denen

Texte und Grafiken positioniert werden können. Um die Entwicklung zu vereinfachen wur-

de das CSS- Framework Bootstrapviii verwendet. Bootstrap bietet eine einheitliche Ober-

fläche mit Dialogfenstern, Menüleisten und weiteren Elementen. Außerdem bietet es die

Möglichkeit, Responsive-Design zu verwenden.

Das Produktionscockpit wurde als eine Webseite realisiert. Diese Seite besteht aus einer

Menüleiste am oberen Rand, einem Container für die Inhalte der verschieden Anzeigen

und Dialogen, die über der gesamten Seite angezeigt werden können.

Über die Menüleiste kann der Benutzer zwischen den verschiedenen Ansichten wechseln.

Auf kleinen Displays, wie sie Smartphones besitzen, wird das Menü versteckt und klappt

erst beim Drücken eines Knopfes nach unten auf. Damit ist gewährleistet, dass der Nutzer

auch auf einem mobilen Endgerät die Ansichten wechseln kann ohne, dass die Navigati-

onsleiste zu viel Platz beansprucht.

Der Inhalt besteht aus einem Container, in dem alle Ansichten als Tabs enthalten sind.

Möchte der Nutzer eine Darstellung wechseln, wird der aktuelle Tab versteckt und der

neue gewünschte angezeigt. Bootstrap bietet für diese Art des Inhaltswechsels die Mög-

lichkeit, dem jeweiligen Menübutton ein Zielattribut zu geben, das auf den Tab verweist,

der gezeigt werden soll. Der Ablauf des Tabwechsels wird dadurch komplett von

Bootstrap übernommen und erfordert keine weiteren Angaben, als die HTML-Attribute.

Innerhalb der Tabs wird der Inhalt horizontal und falls möglich auch vertikal zentriert dar-

gestellt. Ist der Inhalt höher als der Bereich, in dem er angezeigt werden soll, werden die

Elemente nicht mehr zentriert, sondern können über eine Scroll-Funktionalität verschoben

werden.

Die Dialoge sind Elemente, die außerhalb des Menüs oder des Inhaltes in die HTML-Datei

geschrieben werden. Wird ein Dialog angezeigt, überlagert er einen Teil der Seite und

blendet den Rest dunkel aus. Klickt der Nutzer auf diesen dunklen Bereich, wird das Dia-

viii http://getbootstrap.com/


41

logfenster geschlossen. Ein geöffneter Dialog verhindert somit weitere Eingaben auf der

Seite.

Zustandsdiagramm 5.2.5

Jede Maschine verfügt über zwei verschiedene Daten über ihren Verlauf, die während der

Simulation erzeugt und erweitert werden. Der erste Datensatz umfasst den Energiever-

brauch und wird in Form eines Liniendiagramms dargestellt. Zu diesem Zweck kommt die

Bibliothek rickshaw.js zum Einsatz, die alle Anforderungen an die gewünschte Darstellung

erfüllt. Der zweite Datensatz umfasst die Zustände, die die Maschine in der Vergangen-

heit eingenommen hat. Die Darstellung soll in Form eines Balkendiagrammes erfolgen.

Ein herkömmliches Balkendiagramm erfüllt die Anforderungen jedoch nicht. Balken- und

Säulendiagramme nutzen verschiedene Elemente, um einen zeitlichen Zusammenhang

zwischen Werten darzustellen, wie das Beispiel in Abbildung 28 zeigt.

Abbildung 28 Zeitliche Ordnung innerhalb eines Balkendiagramms

Die Balken sollen aber für die unterschiedlichen Maschinen stehen, deren Daten anzeigen

und die Daten, in Abhängigkeit von der Zeit, auf der Horizontalen antragen.

Abbildung 29 Zweckentfremdung eines Balkendiagramms

Eine Möglichkeit, dies zu erreichen, ist die Zweckentfremdung des Diagrammtyps wie in

Abbildung 29. Anstatt die Werte auf der X-Achse anzutragen, werden die Daten über die

Dauer der Zustände dargestellt. Dies führt zu zwei Problemen. Zum einen wird jedem

neuen Bereich eines Balkens eine neue Farbe zugwiesen, wodurch dieselben Zustände

0 1 2 3 4 5

08:00

09:00

10:00

11:00

Zustand

0:00 0:28 0:57 1:26 1:55 2:24 2:52 3:21 3:50 4:19

Kategorie 1

Kategorie 2

Datenreihe 1

Datenreihe 2

Datenreihe 3


42

nicht erkannt werden können. Zum anderen startet ein Balken immer bei Null, wodurch es

nicht möglich ist, nur den Bereich von acht bis 20 Uhr darzustellen.

Die gewünschte Funktionalität kann daher nur durch eine Eigenentwicklung realisiert wer-

den. Zum Einsatz kommt, wie bei den Zeigerdiagrammen, das HTML5-Canvas-Element.

Bei jedem Zeichenvorgang wird eine Liste mit den bisherigen Zuständen durchlaufen und

ein Rechteck vom letzten Zeitpunkt bis zum Endzeitpunkt des Zustandes gezeichnet. Da-

nach wird der letzte Zeitpunkt um die Dauer des Zustandes erweitert. Dadurch wird si-

chergestellt, dass zwischen den zu zeichnenden Rechtecken keine Lücken entstehen, die

durch Rundungsfehler verursacht werden könnten, wenn jeder Zustand ohne Bezug auf

seinen Vorgänger betrachtet wird.

Realisierung der Auftrags-Verschiebung 5.2.6

Jeder Maschine sind Aufträge zugeordnet, bzw. können Aufträge zugeordnet werden. Die

Verteilung erfolgt dabei entlang der Zeitachse und erlaubt keine Überlappung der Anwei-

sungen. Die Verteilung soll mittels Drag-and-Drop entlang der Horizontalen verändert

werden können. Die Anforderungen an die Verschiebung sind:

Nicht über die Zeitgrenzen schieben

Aufträge bei Überlappung neu ordnen

Verschiebung nur auf der X-Achse

Freie Positionierung ohne Raster

Bei der Drag-and-Drop-Funktionalität in HTML müssen zwei Varianten unterschieden

werden. Die eine bezeichnet das Verschieben oder Kopieren eines Objekts zwischen dem

Browser und dem umliegende System. Dadurch können Bilder auf einer Webseite schnell

in einem Ordner auf dem Rechner gespeichert werden oder alle auf eine Webseite hoch-

zuladende Bilder auf diese verschoben werden. Die andere Möglichkeit umfasst nur das

Bewegen von HTML-Elementen innerhalb der Seite.

Für die Maschinenbelegung ist eine Funktionalität nach der zweiten Möglichkeit erforder-

lich. Für diesen Zweck gibt es bereits Bibliotheken, die das Anordnen von HTML-

Containern ermöglichen. Die Library Docking boxes (dbx) bietet diese Funktionalität. Die

Anordnung erfolgt hierbei nach einem festen Raster und kann in der horizontalen oder

vertikalen Richtung gesperrt werden. Eine Verschiebung der Aufträge auf der X-Achse

wäre dadurch möglich. Da eine Anforderung an die Verschiebung aber eine freie Positio-

nierung ohne Raster ist, ist diese Bibliothek für den Einsatz im Produktionscockpit unge-

eignet. Vergleichbare Libraries weisen alle dasselbe Problem auf. Die Funktionalität wur-

de daher selber verwirklicht.


43

Die Grundidee besteht dabei aus dem Verschieben innerhalb der Layout-Grenzen und

dem anschließenden Ordnen aller Blöcke. Die folgende Grafik veranschaulicht die Funkti-

onsweise anhand der Verschiebung eines Blocks.

1 2 3 4

Die Ausgangssituation umfasst die vier Blöcke (1), (2), (3) und (4). Der Block (4) soll in

diesem Beispiel verschoben werden.

1 2 34

Nach erfolgter Verschiebung befindet sich (4) zwischen (2) und (3) und überlappt (2) die-

se. Da dies nicht erlaubt ist, müssen die benachbarten Blöcke verschoben werden.

1 2 34

Dazu werden die jeweils nächsten Elemente in jeder Richtung so weit verschoben, dass

sie den vorhergehen Block nicht mehr überlagern. Ausgangsblock ist (4). Wurde ein Block

verschoben, wird dieselbe Operation auf den nächsten Block ausgeführt, wobei sich der

Ausgangsblock nach jeder Verschiebung ändert. Nach dem (2) in Bezug auf (4) geordnet

wurden, wird (1) in Bezug auf (2) verschoben.

1 2 34

Nach den bisher erfolgten Schritten wurde der Block (4) erfolgreich verschoben und alle

Überlappungen mit anderen Blöcken behoben. Durch diese Ordnung wurde Block (1)

aber über die Grenzen des zur Verschiebung verfügbaren Bereichs geschoben. Er hat

somit einen negativen Startpunkt.

2 341

Um diesen Fehler zu beheben wird (1) auf den kleinsten möglichen Startpunkt gesetzt.

Dies führt wiederum zu einer Überlagerung von (1) und (2). Um dies zu beheben, werden


44

alle nachfolgenden Blöcke wieder soweit verschoben, dass sie ihren Vorgänger nicht

überlappen.

2 341

Die Position von Block (3) wurde bisher nicht geändert, da er in keinem Konflikt mit den

anderen Blöcken stand. Nach den letzten Verschiebungen liegt (4) aber auf (3). Element

(3) muss nun auch verschoben werden.

2 341

Als Ergebnis der Neuordnung wurde die Reihenfolge der letzten beiden und die Position

aller Blöcke geändert. Die Position des zu verschiebenden Elements entspricht daher

nicht mehr der durch die Verschiebung zugewiesen Funktion, stattdessen wurde er, um

die Reihenfolge zu erhalten, fortbewegt.

Diese Technik, setzt voraus, dass die Abschnitte maximal die gesamte verfügbare Fläche

einnehmen. Sollten die Blöcke diesen Maximalwert überschreiten, so würden sie am Ende

der Neuordnung über das gegebene Layout herausragen. Alle Verschiebungen finden

rein mathematisch statt und werden erst am Ende gezeichnet. Dadurch werden unnötige

Zeichenaufrufe und Bildfehler vermieden.


45

5.3 Umfang des implementierten Cockpits

Zum Anzeigen wird das Cockpit als Webseite im Browser geöffnet. Die Dateien werden

dabei vom Server oder der Festplatte geladen. Das fertige Cockpit umfasst dabei

72 Dateien in 13 Ordnern und kommt auf eine Größe von etwas mehr als 2 MB, wodurch

die Seite auch bei einer schlechteren Netzwerkverbindung zügig geladen werden kann.

Eine Übersicht über die Dateien gibt nachfolgend Abbildung 30.

Abbildung 30 Ansicht aller zum Cockpit gehörenden Dateien

Ziel der Implementierung ist es, alle Use-Cases des Cockpits abzudecken. Die Funktiona-

litäten für U3, U4 und U7 sind, wie in Abbildung 31 zu erkennen, unter dem Menüpunkt

Simulation in der Menüleiste zu erreichen. Über diese Leiste ist auch das Wechseln der

Ansichten nach U1 möglich.


46

Abbildung 31 Die Menüleiste mit den Optionen und dem Untermenü zur Steuerung der Simulation

Zusätzlich kann U7 noch über die Schaltfläche „Simulation Starten“ (Abbildung 31) aus

der Ansicht der Maschinenbelegung angesteuert werden. In dieser Ansicht wurde auch

Use-Case U2 umgesetzt. Über die Menüleiste kann auch ein Dialog (Abbildung 32) geöff-

net werden, der die Änderungen an Einstellungen wie in U6 beschreiben ermöglicht.

Abbildung 32 Dialog zum Ändern der Einstellungen

Evaluation

47

6 Evaluation Eine Evaluation dient der Bewertung von Projekten, Prozessen oder Organisationseinhei-

ten. Im Bereich der grafischen Oberflächen wird dabei ermittelt, wie gut ein Benutzer mit

deren Bedienung zurechtkommt. Dadurch wird sichergestellt, dass die Oberfläche den

Anforderungen gerecht wird und der Benutzer möglichst produktiv arbeiten kann. Dies

wird über verschiedene Methoden ermittelt. Der Tester der Oberfläche wird bei der Benut-

zung beobachtet und alle Interaktionen wie Mausklicks oder Tastatureingaben aufge-

zeichnet. Die erstellte Oberfläche kann bereits vorher mit bestehenden GUIs oder Richtli-

nien, sogenannten Design Guidelines, verglichen werden. Nachdem der Nutzer die An-

wendung testen durfte, wird er zu seiner Meinung befragt, um zu erfahren, was gut oder

schlecht war und was man verbessern könnte. Die letzte Möglichkeit ist das Erfassen von

Werten, die Aufschluss darüber geben, wie schnell und mit wie vielen Fehlern der Nutzer

eine Aufgabe erledigt hat (Debbie Stone, 2005).

6.1 Ablauf der Evaluation

Bei der Evaluation des Produktionscockpits bekam jeder Nutzer ein Blatt mit zwölf Aufga-

ben, die in gegebener Reichenfolge abgearbeitet werden mussten. Die Nutzer wurden in

zwei Gruppen mit jeweils drei Personen aufgeteilt, von denen eine in den Grundlagen des

Programmes unterwiesen wurde, währende die andere das Programm zum ersten Mal

nutzte, aber bereits Erfahrungen mit ähnlichen Oberflächen hatte. Eine dritte Gruppe mit

Testern, die weder eingewiesen wurde noch erfahren im Umgang mit ähnlichen Oberflä-

chen ist, wurde weggelassen, da dies keiner für die Anwendung vorgesehenen Zielgruppe

entsprach. Die zu lösenden Aufgaben waren:

A1. Ändere die Reihenfolge der Aufträge auf der Maschine Grob G300 zu: Pasiert,

Teillast, Stand By.

A2. Starte die Simulation.

A3. Verstecke das Diagramm zum Lastgang der Aufträge.

A4. Betrachte den Verlauf der Zustände.

A5. Welchen Wert hat der Planverbrauch um 18:00 Uhr?

A6. Rufe Informationen zu der Maschine Trumpf TruLaser ab.

A7. Um welche Art von Maschine handelt es sich?

A8. Wie hoch ist der maximal mögliche Stromverbrauch in der Fabrik?

Evaluation

48

A9. Stoppe die aktuelle Simulation, falls Sie noch läuft.

A10. Starte eine neue Simulation und beende sie sofort wieder.

A11. Wechsle zu vorherigen Simulation

A12. Betrachte die Liste der vergangenen Simulationen und lösche anschließend al-

le.

Die Aufgaben entsprechen einem Ablauf, der bei der Nutzung des Cockpits realistisch ist.

Die Abfolge richtet sich nach der Nummerierung der Aufgaben und wird durch das Weg-

lassen einer Aufgabe nicht abgebrochen. Jede Aufgabe hat dabei den Zweck einen Use-

Case zu testen. Die Zusammenhänge zwischen Aufgaben und Use-Cases werden in Ab-

bildung 33 beschrieben.

Use-Case Aufgabe

U1 A4, A5, A8

U2 A1

U3 A6, A7

U4 A9, A10

U5 A11, A12

U6 A3

U7 A2, A10

Abbildung 33 Zusammenhänge zwischen Aufgaben und Use-Cases

Die Aufgaben erfordern, dass der Nutzer die Ansichten wechselt, die Elemente der Ober-

fläche versteht und die Simulation steuert. Während der Abarbeitung wurde kontrolliert, ob

die Aufgaben erfolgreich bewältigt wurden und die zu findenden Daten korrekt waren. Die

Zeit wurde vom Anfang der Abarbeitung bis zum Fertigstellen aller Aufgaben gemessen.

6.2 Befunde

Während der Ausführung wurde der Tester beobachtet und protokolliert, welche Aufgaben

er erfolgreich gelöst hat. Der Anteil der gelösten Aufgaben wird in Abbildung 34 darge-

stellt, wobei zwischen eingewiesenen und nicht eingewiesenen Testern unterschieden

wird, um die Auswirkung der Einweisung auf die Ausführung zu ermitteln.

Evaluation

49

Abbildung 34 Anteil gelöster Aufgaben

Ein Vorteil der Einweisung wird besonders deutlich, wenn man die Ausführzeiten betrach-

tet. In der Ausführungszeit sind alle Zeiten enthalten, unabhängig davon, ob eine Aufgabe

gelöst wurde oder nicht. Eine falsche Lösung bedeutet dabei nicht, dass der Nutzer einen

Zeitgewinn hat. Nur das komplette Weglassen einer Aufgabenstellung würde einen Zeit-

gewinn mit sich ziehen, der das Ergebnis verfälschen würde. Solche Abbrüche kamen

aber nicht vor. Der Vergleich der Zeiten in Abbildung 35 zeigt, dass die Unterweisung ei-

nen durchschnittlichen Zeitgewinn von 18% brachte.

Abbildung 35 Durchschnittliche Ausführungszeit

6.3 Befragung zur subjektiven Bewertung

Jedem Tester wurde nach Beendigung des Tests ein Fragebogen ausgehändigt. Dieser

enthielt die folgenden vier allgemeinen Fragen:

1. Wie gut haben Sie die jeweiligen Ansichten/Menüs gefunden?

2. Wie gut haben Sie die jeweiligen Werte/Angaben gefunden?

3. Wie einfach fanden Sie die Bedienung?

4. Wie übersichtlich fanden Sie die Diagramme?

Ziel dieser Fragen war, herauszufinden, wie gut der Nutzer mit dem gesamten Programm

zurechtkam und, ob die Einweisung auch eine suggestive Verbesserung nach sich zieht.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 2 3 4 5 6 7 8 9 10 11 12Aufgaben

Eingewiesen

Nicht Eingewiesen

03:27 03:36 03:45 03:53 04:02 04:11 04:19 04:28 04:36

Nicht eingewiesen

Eingewiesen

Evaluation

50

Die Fragen konnten in fünf Stufen von sehr schlecht über neutral bis zu sehr gut beant-

wortet werden. Sehr gut entspricht dabei voller Zufriedenheit (100%) bei der Ausführung

der Aktionen, auf die die Fragen Bezug nahmen.

Abbildung 36 Verglich der Nutzerbewertungen des Cockpits

Während der Unterschied in der Bewertung bei den Werten, Angaben und der Bedienung

gering ist, ist er bei der Übersichtlichkeit der gesamten Oberfläche und der Diagramme,

wie man es der Abbildung 36 entnehmen kann, deutlich höher. Der durch die Unterwei-

sung erzielte Vorteil wird damit auch beim Nutzer spürbar. Die Oberfläche ist somit nicht

für Personen geeignet, denen die Funktionsweise noch nicht erläutert wurde.

Die weiteren Fragen konnten vom Nutzer frei beantwortet werden. Dabei ging es darum,

wo welche Probleme bei der Bedienung aufgetaucht sind und was man verbessern könn-

te.

Abbildung 37 Probleme und Verbesserungsvorschläge der Tester

Obwohl jeder Nutzer in Anzahl und Art unterschiedlich antworten konnte, sind einige

Probleme mehrfach genannt worden, wie es das Diagramm in Abbildung 37 zeigt. Dazu

zählen die fehlenden Einheiten bei der Beschriftung der Diagramme, das noch nicht opti-

male Verschieben der Aufträge und eine Möglichkeit, um an helfende Informationen zu

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 2 3 4Fragen

Eingewiesen

Nicht eingewiesen

Löschen der Simulationen

Neue Simulation starten

Zustandsverlauf übersichtlicher

Maschinen in der Fabrik besser finden

Mehr Beschriftungen

Besseres verschieben

Fehlende Einheiten

Hilfe Option hinzufügen

Evaluation

51

kommen. Die Ergebnisse der Evaluation sind sehr eindeutig. Die Oberfläche ist beim ers-

ten Benutzen sehr unübersichtlich. Einige Funktionen, wie die Einstellungen der Ansicht,

sind nicht sofort zu finden und das Ablesen der korrekten Werte ist durch fehlende Anga-

ben der Einheiten ebenfalls nicht möglich.

6.4 Diskussion der Ergebnisse

Betrachtet man die Ergebnisse, fällt auf, dass die nicht eingewiesenen Tester bei einigen

Aufgaben besser abgeschnitten haben, als die Eingewiesenen. Dies ist eine Folge der

Einteilung der Testgruppen. Die Aufgaben A5, A8 und A11 wurden intuitiv richtig gemacht,

da die erfahrenen Tester nach bekannten Mustern in der Oberfläche gesucht haben. Bei

speziellen Funktionen, wie sie in Aufgabe A5 erforderlich sind, hatten die Unterwiesenen

durch ihre Einführung einen klaren Vorteil.

Der Zeitgewinn bedeutet für die Ausführung, dass der Anwender die Ansichten und Gra-

phen schneller oder im besten Fall auf Anhieb gefunden hat, während der nicht Unterwie-

sene teilweise danach suchen musste. Dies wurde auch bei Schritt A2 auffällig. Während

die nicht Unterwiesenen eine Schaltfläche suchten und diese in der Auftragsansicht fan-

den, haben die unterwiesen Tester sofort das Untermenü „Simulation“ in der Menüleiste

geöffnet, das ihnen zuvor gezeigt wurde.

Zusammenfassung und Ausblick

52

7 Zusammenfassung und Ausblick Das fertige Produktionscockpit verfügt über alle Funktionen, die in den Anforderungen

genannt wurden. Die grafische Umsetzung orientiert sich stark an den erstellten Entwür-

fen. Durch die Evaluation war es möglich, einige Verbesserungen, wie die fehlenden Ein-

heiten bei manchen Anzeigen, einzubringen. Weitere Optimierungen wären bei längerer

Projektdauer noch möglich. Die Benutzung der Oberfläche wird durch die fehlenden Kor-

rekturen aber nicht beeinträchtigt.

Abbildung 38 Die fertig implementierte Fabrikansicht

Die Ansicht der Fabrik hat am wenigsten Bezug zu einem Leitstand einer echten Fabrik.

Da der Prototyp zu Test-, Demonstrations- und Werbezwecken eingesetzt wird, sind hier

Logos eingebunden, bzw. wurde die Fabrik dreidimensional dargestellt. Für den produkti-

ven Einsatz würde die Fabrikansicht aus Abbildung 38 durch eine schematische Darstel-

lung ersetzt und die Logos würden entfernt werden. Die Verbesserungsvorschläge der

Evaluation wurden in dieser Ansicht bereits umgesetzt, indem die Zeigerdiagramme um

Einheiten erweitert wurden.


53

Abbildung 39 Fertige Ansicht des Verlaufs

Die Darstellung des Verlaufs aus Abbildung 39 zeigt alle Maschinen der Fabrik und den

Gesamtverlauf. Für den Einsatz in Unternhmen müsste die Funktionalität für

Untermaschinen überarbeitet werden. Momentan werden nur maximal drei solcher

Maschinen unterstützt. Bei einer größeren Anzahl würde der verbleibende

Diagrammbereich zu klein werden.

Abbildung 40 Umsetzung der Auftragsansicht


54

Die letzte Ansicht (Abbildung 40) zeigt die Aufträge, die von den Maschinen abgearbeitet

werden sollen. Diese Funktionalität dient nur zu Demonstrationszwecken und würde in

echten Fabriken durch Daten ersetzt, die das PPS liefert.

Mit Hilfe des Produktionscockpits kann ein Nutzer jetzt die Aufträge auf den Maschinen

verändern und seinen Vorstellungen anpassen. Nachdem die Simulation gestartet wurde,

können der Verlauf der Zustände und des Verbrauchs beobachtet bzw. die aktuellen Wer-

te ausgelesen werden. Über die Ansicht der Fabrik können zudem weitere Informationen

zu den simulierten Maschinen abgerufen werden. Die Simulation bzw. das Testen von

verschiedenen Szenarien ist somit möglich.

Durch die Nutzung bestehender Software und Technik wie dem MII oder der SPS ist es

möglich, die erstellte Benutzeroberfläche jederzeit in einem anderen Umfeld einzusetzen,

solange dieses die Komponenten unterstützt. Die Oberfläche ist jedoch nur ein Prototyp,

weshalb der Einsatz in einer echten Fabrik nicht möglich ist. Die durch den Prototyp ge-

wonnenen Erkenntnisse sind jedoch für die Entwicklung echter Leitstände, die zur Über-

wachung und Steuerung des Energieverbrauchs dienen, hilfreich. Dazu zählt vor allem die

Möglichkeit, einen Leitstand in Form einer Website zu erstellen. Die Vorteile einer Web-

seite sind die teilweise Unabhängigkeit des Zielgeräts und die dadurch entstehende Mög-

lichkeit, einen Leitstand auch auf mobilen Geräten wie Tablets zu betreiben.

Abbildungsbezeichnungen

55

8 Abbildungsbezeichnungen Abbildung 1 Darstellung der Automatisierungspyramide (KSB AG, Frankenthal Germany, 2015) .............. 4

Abbildung 2 Struktur und Verbindung von MRP bis APS über mehrere Unternehmen ................................ 5

Abbildung 3 Verbindung der Teilprojekte im Projektverbund FOREnergy ................................................... 8

Abbildung 4 Zusammenhang aller für das Teilprojekt 4 notwendiger Systeme ........................................... 9

Abbildung 5 Use-Case Diagramm des Produktionscockpits ....................................................................... 10

Abbildung 6 Aufbau der Hardware des gesamten Systems ....................................................................... 14

Abbildung 7 Die Softwarearchitektur des gesamten Systems ................................................................... 15

Abbildung 8 Einfaches Andon-System mit 3 Zuständen (Welotec Solutions) ............................................. 17

Abbildung 9 Andon-Board für Stillstandzeiten und Fehlerursache (Welotec Solutions) ............................ 17

Abbildung 10 Ansicht eines einfachen klar strukturierten Produktionscockpits für einen Bildschirm (Büro

Büning) ............................................................................................................................................. 18

Abbildung 11 Leitstand zur Steuerung und Kontrolle von Überwachungskameras (Peras GmbH) ............. 18

Abbildung 12 Kreisdiagramm .................................................................................................................... 20

Abbildung 13 Ringdiagramm ..................................................................................................................... 20

Abbildung 14 Explodiertes Kreisdiagramm, Halbkreisdiagramm und Polar-Area Diagramm. .................... 21

Abbildung 15 Liniendiagramm mit mehreren Achsen. .............................................................................. 21

Abbildung 16 Säulendiagramm der Werte aus Abbildung 15 .................................................................... 22

Abbildung 17 Modernes Zeigerinstrument ............................................................................................... 23

Abbildung 18 Klassisches Zeigerinstrument .............................................................................................. 23

Abbildung 19 Beispiel für ein Gantt-Diagramm (Keynotevorlagen.de) ...................................................... 24

Abbildung 20 Entwurf der Fabrik-Ansicht ................................................................................................. 25

Abbildung 21 Entwurf des Maschineninfo-Dialogs .................................................................................... 26

Abbildung 22 Entwurf des Verlauf-Dialogs ................................................................................................ 27

Abbildung 23 Entwurf des Auftrags-Dialogs .............................................................................................. 28

Abbildung 24 Unterschiedliche Verteilung der Elemente bei Responsive Design ...................................... 33

Abbildung 25 Vergleich von JustGage bei unterschiedlicher Diagrammfläche ........................................... 36

Abbildung 26 Vergleich der X-Komponente eines Linendiagrammes ........................................................ 38

Abbildung 27 Vegleich: Falsche und richte Anpassung der Breite ............................................................. 39

Abbildung 28 Zeitliche Ordnung innerhalb eines Balkendiagramms ......................................................... 41

Abbildung 29 Zweckentfremdung eines Balkendiagramms ....................................................................... 41

Abbildung 30 Ansicht aller zum Cockpit gehörenden Dateien ................................................................... 45

Abbildung 31 Die Menüleiste mit den Optionen und dem Untermenü zur Steuerung der Simulation....... 46

Abbildung 32 Dialog zum Ändern der Einstellungen ................................................................................. 46

Abbildung 33 Zusammenhänge zwischen Aufgaben und Use-Cases .......................................................... 48

Abbildung 34 Anteil gelöster Aufgaben ..................................................................................................... 49

Abbildung 35 Durchschnittliche Ausführungszeit ...................................................................................... 49

Abbildung 36 Verglich der Nutzerbewertungen des Cockpits .................................................................... 50

Abbildungsbezeichnungen

56

Abbildung 37 Probleme und Verbesserungsvorschläge der Tester ............................................................ 50

Abbildung 38 Die fertig implementierte Fabrikansicht .............................................................................. 52

Abbildung 39 Fertige Ansicht des Verlaufs ................................................................................................ 53

Abbildung 40 Umsetzung der Auftragsansicht .......................................................................................... 53

Literaturverzeichnis

57

9 Literaturverzeichnis Atkins, T. (5. 9 2012). A Word About CSS4 - Tab Completion. Abgerufen am 13. 11 2014

von http://www.xanthir.com/b4Ko0

Burger, P. D. (7. 1 2015). Stromerzeugung aus Solar. Freiburg.

Büro Büning. (06. 08 2014). WILO | Büro Büning Informationsgestalter. (Büro Büning)

Abgerufen am 06. 08 2014 von http://www.buero-buening.de/portfolio-item/wilo-

cockpit-optimierung/

Debbie Stone, C. J. (2005). User Interface Design and Evaluation. San Francisco:

Elsevier.

Fraunhofer. (2012). FOREnergy. (Fraunhofer) Abgerufen am 19. 02 2014 von

http://www.forenergy.de/de

Fraunhofer IWU RMV. (07. 01 2015). FOREnergy. Abgerufen am 03. 02 2015 von

http://forenergy.de/de/projektverbund/partner.html

Heise Zeitschriften Verlag. (15. 08 2013). Abgerufen am 25. 02 2015 von Tessel:

JavaScript-Entwicklerboard fürs "Internet der Dinge":

http://www.heise.de/newsticker/meldung/Tessel-JavaScript-Entwicklerboard-fuers-

Internet-der-Dinge-1936379.html

Joos, T. (2010). Windows 7: das Praxisbuch für Home, Professional und Ultimate Edition.

München: Markt+Technick Verlag.

Keynotevorlagen.de. (04. 11 2014). Vorlage Gantt-Diagramm | Keynotevorlagen.de.

Abgerufen am 04. 11 2014 von http://www.keynotevorlagen.de/keynote-

vorlagen/vorlage-gantt-diagramm

Kletti, J. (2007). Konzeption und Einführung von MES-Systemen. Berlin Heidelberg:

Springer.

KSB AG, Frankenthal Germany. (09. 03 2015). Kreiselpumpenlexikon - Pumpenlexikon -

Feldebene. Abgerufen am 09. 03 2015 von

http://www.ksb.com/Kreiselpumpenlexikon_de/Pumpenlexikon/1562924/feldebene.

html

Kurbel, P. D. (2005). Produktionsplanung und -steuerung im Enterprise Resource

Planning und Supply Chain Managment. München: Oldenbourg

Wissenschaftsverlag GmbH.

Lie, H. W. (11. 10 1994). Cascading HTML style sheets -- a proposal. Abgerufen am 13.

11 2014 von http://www.w3.org/People/howcome/p/cascade.html

Literaturverzeichnis

58

Peras GmbH. (01. 09 2014). Leitstand - Peras GmbH. Abgerufen am 01. 09 2014 von

http://www.peras.de/schluesselthema-sicherheit/datensicherheit/leitstand.html

Redaktion SELFHTML. (22. 10 2014). SELFHTML: HTML/XHTML / Elemente zur

Textstrukturierung / Ältere Elemente zur Schriftformatierung. Abgerufen am 13. 11

2014 von http://de.selfhtml.org/html/text/schrift.htm#art_groesse_farbe

RJ Owen, L. S. (2013). The Truth About HTML5. Apress.

Schultz, C., Keller, F., & Reinhart, G. (11/12 2014). Modellierung einer energieorientierten

PPS. wt-online, S. 771-775.

Siepermann, D. C. (25. 03 2013). Definition » Enterprise-Resource-Planning-System /

ERP-System « | Gabler Wirtschaftslexikon. Abgerufen am 30. 10 2014 von

http://wirtschaftslexikon.gabler.de/Archiv/17984/enterprise-resource-planning-

system-v12.html

Umweltbundesamt. (30. 05 2012). Häufige Fragen zur Energiewende. Abgerufen am 03.

02 2015 von http://www.umweltbundesamt.de/themen/klima-energie/klimaschutz-

energiepolitik-in-deutschland/haeufige-fragen-zur-energiewende

W3C. (22. 6 2000). CSS3 introduction. Abgerufen am 13. 11 2014 von

http://www.w3.org/TR/2000/WD-css3-roadmap-20000414

W3C. (11. 04 2008). Cascading Style Sheets, level 1. Abgerufen am 24. 02 2015 von

http://www.w3.org/TR/REC-CSS1/

W3C. (7. 6 2011). Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification.

Abgerufen am 13. 11 2014 von http://www.w3.org/TR/CSS2/

W3C. (6. 10 2014). CSS current work & how to participate. Abgerufen am 13. 11 2014 von

http://www.w3.org/Style/CSS/current-work

Welotec Solutions. (04. 11 2014). Andon-Board — Welotec Solutions. Abgerufen am 04.

11 2014 von http://www.welotec-solutions.com/andon-board/

Anhänge

59

10 Anhänge Bildschirmfotos der fertigen Anwendung

Anhänge

60

Anhänge

61

Anhänge

62

Anhänge

63

Anhänge

64

Inhalt der Daten-DVD

65

11 Inhalt der Daten-DVD Eine digitale Version dieser Arbeit

Das Produktionscockpit als Webseite

Bildschirmfotos

Eidesstattliche Erklärung

66



Ich, Kai Eckardt, erkläre hiermit eidesstattlich, dass ich die vorliegende Arbeit selbständig

angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken

sind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt.

Augsburg, den 18.03.2015

(Kai Alexander Eckardt)

Entwicklung eines Produktionscockpits für ein energieorientiertes Manufacturing Execution System

Documents

Transcript of Entwicklung eines Produktionscockpits für ein energieorientiertes Manufacturing Execution System