Industrie 4.0: Integration und Vernetzung existierender ... · Erklärung gem. ABPO, Ziff. 6.4.3...

160
Hochschule RheinMain Fachbereich Design Informatik Medien Studiengang Informatik Master-Thesis zur Erlangung des akademischen Grades Master of Science - M.Sc. Industrie 4.0: Integration und Vernetzung existierender Werkzeugmaschinen vorgelegt von Daniel Mierswa am 5. Oktober 2016 Referent: Prof. Dr. Reinhold Kröger Koreferent: Prof. Dr. Martin Gergeleit

Transcript of Industrie 4.0: Integration und Vernetzung existierender ... · Erklärung gem. ABPO, Ziff. 6.4.3...

Hochschule RheinMainFachbereich Design Informatik Medien

Studiengang Informatik

Master-Thesiszur Erlangung des akademischen Grades

Master of Science - M.Sc.

Industrie 4.0: Integration und Vernetzungexistierender Werkzeugmaschinen

vorgelegt von Daniel Mierswa

am 5. Oktober 2016

Referent: Prof. Dr. Reinhold KrögerKoreferent: Prof. Dr. Martin Gergeleit

II

Erklärung gem. ABPO, Ziff. 6.4.3

Ich versichere, dass ich die Master-Thesis selbstständig verfasst und keine anderen alsdie angegebenen Hilfsmittel benutzt habe.

Wiesbaden, 5. Oktober 2016 Daniel Mierswa

Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungs-formen dieser Master-Thesis:

Verbreitungsform ja neinEinstellung der Arbeit in dieBibliothek der HochschuleRheinMain

Veröffentlichung des Titels derArbeit im Internet

Veröffentlichung der Arbeit imInternet

Wiesbaden, 5. Oktober 2016 Daniel Mierswa

III

IV

Inhaltsverzeichnis

1 Einführung 1

2 Grundlagen 5

2.1 Industrie 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 OPC Unified Architecture (OPC UA) . . . . . . . . . . . . . . . . . . . 7

2.2.1 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2.1 Architektur-Muster . . . . . . . . . . . . . . . . . . . 10

2.2.2.2 Redundanz . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2.3 Lesen und Speichern von Daten . . . . . . . . . . . . . 13

2.2.3 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 CNC-Werkzeugmaschinen . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Einführung in die CNC-Technik . . . . . . . . . . . . . . . . . . 23

2.3.2 Aufbau von CNC-Werkzeugmaschinen . . . . . . . . . . . . . . 24

2.3.3 CNC-Steuerungen . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Analyse 31

3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Vorhandene Werkzeuge für das Arbeiten mit OPC UA . . . . . . . . . . . 34

3.2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.2 Unified Automation SDK . . . . . . . . . . . . . . . . . . . . . 35

3.2.3 UaModeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.4 Designentscheidungen . . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Modellierung von CNC-Werkzeugmaschinen . . . . . . . . . . . . . . . 38

3.3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

V

3.3.2 Klassische Gerätebeschreibungssprachen . . . . . . . . . . . . . 39

3.3.3 MTConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.4 OPC Unified Architecture for Devices (DI) . . . . . . . . . . . . 43

3.3.4.1 TopologyElementType . . . . . . . . . . . . . . . . . . 45

3.3.4.2 DeviceType . . . . . . . . . . . . . . . . . . . . . . . 47

3.3.4.3 ConfigurableObjectType . . . . . . . . . . . . . . . . . 50

3.3.4.4 Modulare Geräte im Adressraum . . . . . . . . . . . . 50

3.3.5 OPC Unified Architecture Information Model for CNC Systems . 52

3.3.5.1 CncAlarmType . . . . . . . . . . . . . . . . . . . . . . 54

3.3.5.2 CncMessageType . . . . . . . . . . . . . . . . . . . . 57

3.3.5.3 CncInterfaceType . . . . . . . . . . . . . . . . . . . . 57

3.3.5.4 Listen-Typen . . . . . . . . . . . . . . . . . . . . . . . 58

3.3.5.5 CncComponentType . . . . . . . . . . . . . . . . . . . 59

3.3.5.6 CncChannelType . . . . . . . . . . . . . . . . . . . . 59

3.3.5.7 CncDriveType . . . . . . . . . . . . . . . . . . . . . . 66

3.3.5.8 CncAxisType . . . . . . . . . . . . . . . . . . . . . . 67

3.3.5.9 CncSpindleType . . . . . . . . . . . . . . . . . . . . . 68

3.3.5.10 Informationsmodell im Adressraum . . . . . . . . . . . 70

3.3.6 Designentscheidungen . . . . . . . . . . . . . . . . . . . . . . . 71

3.4 Zugriff auf CNC-Steuerungen . . . . . . . . . . . . . . . . . . . . . . . 73

3.4.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.4.2 PLCopen OPC-UA-Funktionsblöcke . . . . . . . . . . . . . . . . 73

3.4.3 CODESYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.4.4 Treiber für CNC-Steuerungen der Eckelmann AG . . . . . . . . . 76

3.4.5 Designentscheidungen . . . . . . . . . . . . . . . . . . . . . . . 79

4 Design 81

4.1 Gesamtarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2 Informationsmodell für CNC-Werkzeugmaschinen . . . . . . . . . . . . 82

4.2.1 Überblick und Notation . . . . . . . . . . . . . . . . . . . . . . . 82

4.2.2 Resultierendes Informationsmodell . . . . . . . . . . . . . . . . 84

4.2.3 Herstellerspezifische Erweiterungen . . . . . . . . . . . . . . . . 88

VI

4.2.4 Beispiel-Instanz des Informationsmodells für eine 3-Achsen-Plasma-Schneidmaschine . . . . . . . . . . . . . . . . . . . . . . 91

4.3 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.3.2 Generische Adapterkomponenten . . . . . . . . . . . . . . . . . 96

4.3.3 Herstellerspezifische Erweiterungen des Adapters . . . . . . . . . 101

5 Implementierung 105

5.1 Informationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.2 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.2.2 Objektorientierte Schnittstelle des Eckelmann-Treibers . . . . . . 108

5.2.3 Remote Anbindung der Steuerung . . . . . . . . . . . . . . . . . 112

5.3 NodeManager für Instanzen des Prototyps . . . . . . . . . . . . . . . . . 115

5.4 Anbindung des OPC UA Servers . . . . . . . . . . . . . . . . . . . . . . 117

5.5 Umfang und Aufwand . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6 Evaluierung 121

6.1 Überprüfen des Konzepts auf Erfüllung der Anforderungen . . . . . . . . 121

6.2 Testen der Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . 123

6.3 Performance-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

7 Zusammenfassung & Ausblick 133

8 Literaturverzeichnis 137

VII

VIII

Abbildungsverzeichnis

2.1 Veröffentlichte Teile der OPC Unified Architecture. Entnommen aus[Gmb16e]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Beispiel einer Abbildung einer Methode mit Pseudocode in OPC UA.Entnommen aus [MLD09]. . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Beispiel eines OPC UA Adressraumes mit Variablen, Objekten und Me-thoden. Entnommen aus [MLD09]. . . . . . . . . . . . . . . . . . . . . . 19

2.4 In OPC UA bereits vorhandene einfache Datentypen. Entnommen aus[MLD09]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 In OPC UA vorhandene Referenztypen. Entnommen aus [Urb13] . . . . . 22

2.6 Beispiel eines Views im OPC UA Adressraum. Entnommen aus [MLD09]. 22

2.7 Exemplarischer Aufbau einer Drehmaschine. Entnommen aus [Rö12]. . . 24

2.8 Exemplarischer Aufbau einer Fräsmaschine. Entnommen aus [Rö12]. . . 24

2.9 Hexapod als gängiges Bauteil in der parallelen Kinematik. Entnommenaus [Utz05]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 Anwendungsfälle des zu entwickelnden Prototyps . . . . . . . . . . . . . 31

3.2 UaModeler GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Überblick über gängige Komponenten eines MTConnect Geräts. Entnom-men aus [Con16]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4 Überblick des Gerätemodells. Entnommen aus [Fou13]. . . . . . . . . . . 45

3.5 Komponenten des TopologyElementType. Entnommen aus [Fou13]. . . . 46

3.6 Definition des TopologyElementType. Entnommen aus [Fou13]. . . . . . 46

3.7 Definition des DeviceType. Entnommen aus [Fou13]. . . . . . . . . . . . 47

3.8 Definition von DeviceTypeImage. Entnommen aus [Fou13]. . . . . . . . 49

3.9 Definition von Documentation. Entnommen aus [Fou13]. . . . . . . . . . 49

3.10 Definition von ConfigurableObjectType. Entnommen aus [Fou13]. . . . . 50

3.11 Beispielstruktur eines modularen Geräts nach OPC UA DI. Entnommenaus [Fou13]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

IX

3.12 Objekttypen in OPC UA CNC. Entnommen aus OPC UA CNC 0.9. . . . 54

3.13 Struktur des CncInterfaceType in OPC UA CNC. Entnommen aus OPCUA CNC 0.9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.14 Beispiel eines Informationsmodells einer 3-Achsen-CNC-Werkzeugmaschinenach OPC UA CNC. Entnommen aus OPC UA CNC 0.9. . . . . . . . . . 56

3.15 Definition des CncAlarmType. Entnommen aus OPC UA CNC 0.9. . . . . 56

3.16 Definition des CncInterfaceType. Entnommen aus OPC UA CNC 0.9. . . 57

3.17 Definition des CncAxisListType. Entnommen aus OPC UA CNC 0.9. . . 58

3.18 Definition des CncSpindleListType. Entnommen aus OPC UA CNC 0.9. . 58

3.19 Definition des CncChannelListType. Entnommen aus OPC UA CNC 0.9. 59

3.20 Definition des CncComponentType. Entnommen aus OPC UA CNC 0.9. . 59

3.21 Beispiele für Tool Carrier Zero Points. Entnommen aus OPC UA CNC 0.9. 60

3.22 Beispiel für einen TCP in einem Bohrwerkzeug. Entnommen aus OPCUA CNC 0.9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.23 Beispiel für einen TCP in einem Fräswerkzeug. Entnommen aus OPC UACNC 0.9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.24 Beispiel für Koordinatensysteme. Entnommen aus OPC UA CNC 0.9. . . 61

3.25 Definition des CncChannelType. Entnommen aus OPC UA CNC 0.9. . . . 62

3.26 Definition des CncPositionVariableType. Entnommen aus OPC UA CNC0.9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.27 Definition des CncDriveType. Entnommen aus OPC UA CNC 0.9. . . . . 66

3.28 Definition des CncAxisType. Entnommen aus OPC UA CNC 0.9. . . . . 67

3.29 Definition des CncSpindleType. Entnommen aus OPC UA CNC 0.9. . . . 68

3.30 Überblick der Komponenten der CODESYS Software-Plattform. Entnom-men von http://de.codesys.com. . . . . . . . . . . . . . . . . . . . . . . . 75

4.1 Gesamtarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2 Überblick der verwendeten Komponenten im Informationsmodell . . . . 83

4.3 CNCMachineDeviceType-Klasse für CNC-Werkzeugmaschinen . . . . . 84

4.4 CNCDriveComponentDeviceType-Klasse für physikalische Komponen-ten von CNC-Werkzeugmaschinen . . . . . . . . . . . . . . . . . . . . . 85

4.5 Klassen für CNC-Kanäle und Werkzeugträger . . . . . . . . . . . . . . . 87

4.6 Eckelmann-spezifische CNC-Komponenten . . . . . . . . . . . . . . . . 88

4.7 Eckelmann-spezische physikalische Geräte . . . . . . . . . . . . . . . . 89

4.8 Objektdiagramm für die CNC-Schnittstelle am Beispiel Eckelmann . . . 92

X

4.9 Objektdiagramm für Geräte am Beispiel Eckelmann . . . . . . . . . . . . 93

4.10 Komponenten des Adapters . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.11 Klassenübersicht der Adapterkonfiguration . . . . . . . . . . . . . . . . 96

4.12 Klassenübersicht in generischer Komponente des Adapters . . . . . . . . 100

4.13 Klassenübersicht bei herstellerspezifischen Erweiterungen des Adapters . 102

5.1 Komponenten des Wrappers für Eckelmann CNC-Steuerungen . . . . . . 107

5.2 Klassenübersicht des Wrappers für Eckelmann CNC-Steuerungen . . . . 109

5.3 Exception-Klassen für die objektorienterte Schnittstelle für EckelmannCNC-Steuerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.4 Klassen und Datentypen für das Nachrichten-Protokoll . . . . . . . . . . 113

5.5 Überblick der Klassen in der Client-Server-Architektur von MMICTRLRemote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.1 UaExpert Oberfläche nach Verbindungsaufbau zum OPC UA Server . . . 125

6.2 UaExpert Oberfläche nach Browsen eines statischen Werts im Informai-tonsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.3 Teil der UaExpert Oberfläche nach Browsen eines dynamischen Werts imInformaitonsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.4 Teil der UaExpert Oberfläche nach Browsen eines dynamischen Werts imInformaitonsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.5 DataAccessView im UaExpert zur Beobachtung von Subscriptions . . . . 128

6.6 DataAccessView im UaExpert nach Veränderung einer Subscription . . . 129

6.7 EventView im UaExpert nach Auslösung eines asynchronen Fehler-Ereignisses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

XI

XII

Tabellenverzeichnis

2.1 Gemeinsame Attribute aller NodeClasses . . . . . . . . . . . . . . . . . 15

2.2 Attribute der Variable NodeClass . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Möglichkeiten von Datenwerten im Zusammenhang mit ihrem Datentyp . 17

2.4 Attribute und Eigenschaften der NodeClass Method . . . . . . . . . . . . 18

2.5 Attribute und Eigenschaften der View NodeClass . . . . . . . . . . . . . 23

5.1 Anzahl der Codezeilen der Implementierung . . . . . . . . . . . . . . . . 119

6.1 Messergebnisse der Performance-Tests . . . . . . . . . . . . . . . . . . . 131

XIII

XIV

Verzeichnis der Quellcodes undDatei-Ausschnitte

4.1 XML-Konfigurationsdatei für den Beispiel-Adapter . . . . . . . . . . . . 974.2 XML-Konfigurationsdatei für den Eckelmann-Adapter . . . . . . . . . . 1015.1 Hinzufügen von GeneralModelChangeEvent-Referenzen . . . . . . . . . 1065.2 Erstellung des Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185.3 Hinzufügen eines NodeManager . . . . . . . . . . . . . . . . . . . . . . 1186.1 Ausgaben bezüglich Verbindungsaufbau zu CNC-Steuerung . . . . . . . 123

XV

XVI

Kapitel 1

Einführung

Die Einführung von Maschinen in Landwirtschaft und Produktion leitete Mitte des 18.Jahrhunderts die erste industrielle Revolution ein. Gegen Ende des 18. Jahrhunderts be-gann die zweite industrielle Revolution, die in Deutschland auch Hochindustrialisierunggenannt wird [SK16]. In diesen Zeitraum waren vor allem Erfindungen im Bereich derElektrotechnik und der chemischen Industrie Motoren für die Modernisierung der Pro-duktion und auch der Durchdringung der Gesellschaft [Fuc16]. Zu Beginn des 20. Jahr-hunderts drang die Nutzung des Computers in die Industrie vor und startete die dritte in-dustrielle Revolution. Dabei wurde der Grad der Automatisierung gegenüber der Hochin-dustrialisierung deutlich erhöht. In der Automobil-Industrie lag der Branchendurchschnittbei ca. 5%, während bei Volkswagen, durch die Nutzung von Robotern in der Fertigungein Automatisierungsgrad von 25% angestrebt wurde [Lic16]. Durch die Verwendung vonComputer-gesteuerten Maschinen war es möglich, Produkte in Massen, preiswert und mithöherem Grad der Individualisierung zu fertigen. Die aktuell eingeleitete vierte Revoluti-on der Industrie verstärkt die Bedeutung der Computer in der Industrie.

Während der Kern der dritten Revolution im wesentlichen darin bestand, die Steue-rung der Produktion von einem Computer durchführen zu lassen, zielt die derzeitproklamierte vierte Revolution darauf ab, Menschen, Maschinen und die Objekte inFertigungsprozessen miteinander zu vernetzen [Brü14]. Für diese Vernetzung werdenCyber Physical Systems (CPS) entwickelt, die eingebettete Systeme sind, welche ihreAnwendungs- und Umgebungssituation erfassen und diese mit deren Nutzern beeinflus-sen können. CPS benutzen dabei je nach Einsatzumgebung drahtgebundene und drahtloseKommunikationsmechanismen. Typische Einsatzgebiete von CPS mit drahtloser Kom-munikation (z.B. WLAN, Bluetooth oder auch UMTS) sind z.B. Sensor-Netzwerke. Diephysikalischen Aspekte der Umgebung bieten Modelle, Analyse-Methoden und Konzep-

1

Kapitel 1. Einführung

te für ein integrierendes System an. Die vierte Revolution wird unter dem Begriff Indus-trie 4.0 vorangetrieben. Der Begriff Industrie 4.0 wurde auf der Hannovermesse in 2011das erste mal öffentlich genutzt. Im April 2013 entstand aus einer Kooperationsverein-barung verschiedener Verbände die Plattform Industrie 4.0. Diese soll die Themen rundum Industrie 4.0 durch Handlungsempfehlungen für Akteure und Initiierung von Stan-dards vorantreiben. Mittlerweile steht die Plattform Industrie 4.0 unter der Leitung desBundesministerium für Wirtschaft und Energie (BMWi), sowie des Bundesministeriumfür Bildung und Forschung (BMBF) [BMB15].

Während Computer Einzug in die Industrie erhielten, haben sich auch die Maschinen inder Produktion dieser Situation angepasst. In der industriellen Revolution waren Werk-zeugmaschinen Voraussetzung für die Herstellung von Dampfmaschinen, die in Fabrikenfür viele Arbeiten eingesetzt wurden. 1775 wurde die erste bekanntere Werkzeugmaschi-ne (Horizontal-Bohrmaschine) von John Wilkinson erschaffen, um Bohrungen von Zylin-dern zu ermöglichen, die nur wenige Millimeter Abweichung einhalten konnte [Sch56].Eine Werkzeugmaschine ist nach DIN 69 651 eine mechanisierte und mehr oder wenigerautomatisierte Fertigungseinrichtung, die durch relative Bewegung zwischen Werkstückund Werkzeug eine vorgegebene Form am Werkstück oder eine Veränderung einer vor-gegebenen Form an einem Werkstück erzeugt. Durch die Mordernisierung verändertensich auch die Werkzeugmaschinen. Während der zweiten industriellen Revolution wur-den Elektromotoren eingesetzt, die Riemengetriebe antrieben, die wiederum für die Be-wegung von Achsen in einer Werkzeugmaschine genutzt wurden. Erst relativ spät wurdenseparate Elektromotoren für jede Achse genutzt. CNC-Werkzeugmaschinen (Computeri-zed Numerical Control) sind Werkzeugmaschinen, die sehr präzise komplexe Werkstückeautomatisiert herstellen können. Sie benutzen dazu moderne Steuerungstechnik (CNC-Steuerung), die von einer Computer-Software realisiert wird. Der Anwender schreibt dazuein Programm, welches manuell oder mit graphischen Zeichenprogrammen (CAD) einerSteuerung übergeben und von dieser ausgeführt wird.

In dieser Arbeit werden CNC-Werkzeugmaschinen in den Kontext Industrie 4.0 einge-bettet. CNC-Werkzeugmaschinen werden derzeit lokal am Einsatzort überwacht und be-treut. Die modernen Technologien von Industrie 4.0 sollen Anwendung finden, um CNC-Werkzeugmaschinen im Netzwerk sichtbar zu machen.

Für den Austausch von Informationen in diesem Kontext stehen verschiedene Kommuni-kationsmodelle zur Verfügung, die unter dem Begriff M2M-Protokolle (Machine to Ma-

chine) gesammelt werden. Darunter fallen z.B. MQTT, OPC UA und OMG DDS. DasEinbinden von CNC-Werkzeugmaschinen in Industrie 4.0 erlaubt es, die Vorteile einesNetzwerks in Fertigungsprozessen zu nutzen. Dadurch ist es z.B. möglich, Veränderun-

2

Kapitel 1. Einführung

gen der Genauigkeit oder des Energieverbrauchs von einzelnen Komponenten zentral zuüberwachen.

Neben den Protokollen für die Kommunikation von Maschineninformationen im Netz-werk existieren Beschreibungssprachen für Geräte. Diese Beschreibungen sind zum TeilBestandteil von Protokollen oder eigenständig. Durch die Verbreitung und stark zu-nehmende Verwendung von Automatisierungsgeräten in der Fertigung ändern sich die-se Sprachen stetig oder erlauben es für spezifische Anwendungsfälle, eigene Erweite-rungen einzubringen. Diese Beschreibungssprachen besitzen Komponenten zur Model-lierung von spezifischen Geräten. Gängige Beschreibungssprachen sind zum BeispielGSDML (Generic Station Description Markup Language), AutomationML und MT-Connect. Der Standard MTConnect bietet eine große Anzahl von Modellierungsmög-lichkeiten für Werkzeugmaschinen. AutomationML dient hauptsächlich der Beschreibungvon Objekten mit dem Fokus auf vertikale Integration und GSDML dient der Beschrei-bung von Feldbus-Geräten. Um ein Informationsmodell für die Maschinen-Komponentenvon CNC-Werkzeugmaschinen zu erstellen, existieren also verschiedene Basismodelle,die sich aber konzeptionell voneinander unterscheiden. Daher gilt zu prüfen, ob sich dieseBasismodelle für die Modellierung eignen, ob Gemeinsamkeiten bestehen oder Teile vonanderen Modellen in existierenden Modellen übertragen werden können. Neben der Mo-dellierung von Geräten und maschinellen Komponenten von CNC-Werkzeugmaschinenist der Aspekt der Modellierung für die CNC-Schnittstelle zu betrachten. Derzeit gibt esnur einen geplanten Standard für das Modellieren von CNC-Schnittstellen. Hersteller vonCNC-Steuerungen bieten zwar teilweise OPC UA Server oder andere Dienste in ihrenSteuerungen an, die ein Informationsmodell der CNC-Steuerungen bereitstellen, jedochsind diese proprietär.

Die Master-Thesis wird in Kooperation mit der Eckelmann AG in Wiesbaden durchge-führt. Die Eckelmann AG ist ein internationaler Automatisierungspartner für Maschinen-und Anlagenbau. Sie stellt für die Entwicklung des Prototyp für diese Arbeit, eine CNC-Steuerung bereit. Es ist vorgesehen, sich zu Beginn des Bearbeitungszeitraums zu treffen,so dass generelle Anforderungen eines Herstellers von CNC-Steuerungen in die Bear-beitung einfließen kann. Für die Arbeit wird exemplarisch eine CNC-Werkzeugmaschinemodelliert, die mit einer CNC-Steuerung der Eckelmann AG arbeitet und diese im Kon-text Industrie 4.0 angeboten. Dadurch, dass Industrie 4.0 insbesondere zukunftsorienterteThemen behandelt, wollen Unternehmen für die Nachfrage gerüstet sein und mit gutemBeispiel voran gehen. Insbesondere Energie-Monitoring wird durch die Energiewende inDeutschland ein nicht zu vernachlässigendes Thema in Unternehmen sein. Deshalb giltes zu analysieren, wie dieses Thema in der Modellierung von CNC-Werkzeugmaschinen

3

Kapitel 1. Einführung

berücksichtigt werden kann.

Diese Arbeit ist wie folgt gegliedert: Kapitel 2 beschreibt die Grundlagen, die für dasweitere Verständnis der Arbeit notwendig sind. Im Grundlagen-Kapitel wird in Ab-schnitt 2.1 der Begriff Industrie 4.0 genauer beschrieben. In Abschnitt 2.2 wird dasOPC Unified Architecture Framework beschrieben, welches für Industrie 4.0 ein be-deutendes M2M-Protokoll anbietet. Abschnitt 2.3 beschreibt die Grundlagen für CNC-Werkzeugmaschinen. Kapitel 3 umfasst die Analyse der Arbeit. Die Anforderungen, diein dieser Arbeit analysiert und schließlich abgedeckt werden sollen, werden in Abschnitt3.1 herausgearbeitet. In Abschnitt 3.2 werden Werkzeuge vorgestellt, die das Arbeitenmit dem OPC Unified Architecture Framework für Entwickler vereinfachen. Die Model-lierung von CNC-Werkzeugmaschinen wird in Abschnitt 3.3 und der Zugriff auf CNC-Steuerungen in Abschnitt 3.4 untersucht. Jeder Abschnitt im Analyse-Kapitel endet mitEntscheidungen bezüglich eines Konzepts, dass die Aufgabenstellung erfüllen soll. Die-ses Konzept wird in Kapitel 4 vorgestellt und die Implementierung des Konzepts wirdin Kapitel 5 beschrieben. Die Evaluierung in Kapitel 6 bewertet das Konzept bezüglichder Anforderungen und beschreibt Tests der Implementierung auf ihre Funktionalität. Ab-schließend werden im Kapitel 7 die Ergebnisse dieser Arbeit zusammengefasst und einAusblick gegeben.

4

Kapitel 2

Grundlagen

2.1 Industrie 4.0

Unter dem Begriff Industrie 4.0 versteht man umgangssprachlich die 4. industrielle Revo-lution. Genauer soll die deutsche Industrie für die Zukunftstechnologien in der Produktiongerüstet werden. Dabei müssen diverse Anforderungen berücksichtigt werden [Bun16]:

• Starke Individualisierung der Produkte

• Hohe Flexibilität der (Großserien-) Produktion (bedarfsgerechte Produktion bzw.Losgröße 1)

• Integration von Kunden und Geschäftspartnern in Geschäfts- und Wertschöpfungs-prozesse

• Hochwertige Verbindung der Produktion mit Dienstleistungen

Ein Anwendungsszenario in Industrie 4.0 ist die nahezu Echtzeit-Steuerung und Opti-mierung von Unternehmen und Wertschöpfungsnetzwerken mittels intelligenter Entschei-dungs- und Überwachungsprozesse. Durch das Vorantreiben von Industrie 4.0 möchteman neue Geschäftsmodelle gestalten und Optimierungspotenziale ausnutzen. Die Bun-desregierung setzt seit 2011 die Forschungsagenda Industrie 4.0 um. Das Bundesminis-terium für Bildung und Forschung (BMBF) stellte bisher 120 Millionen Euro [Bun16]für Forschung und Entwicklung bereit. Das Bundeswirtschaftsministerium (BMWi) trägtebenfalls 80 Millionen Euro als Förderungsmittel bei. Das BMWi konzentriert sich aufdie Schwerpunkte der Regulierung und Standardisierung.

5

2.1. Industrie 4.0 Kapitel 2. Grundlagen

Es werden konzeptionell vier Schwerpunkte unterschieden: Mittelstand, Standards undIT-Architekturen, IT-Sicherheit und Qualifikation. Insbesondere im Bereich der IT-Architekturen ist die Arbeit an einer IT-Referenzarchitektur der Verbändeplattform In-dustrie 4.0 hervorzuheben. Sie wird vom Zentralverband für Elektrotechnik- und Elek-tronikindustrie e.V. (ZVEI), Verband Deutscher Maschinen- und Anlagenbau e.V. (VD-MA) und dem Bundesverband Informationswirtschaft, Telekommunikation und neue Me-dien (BITKOM) vorangetrieben und hat den Namen Referenzarchitektur für Industrie 4.0

(kurz: RAMI). Sie soll als Basis für zukünftige Standardisierungsbemühungen genutztund in Kürze (Stand: Mai 2016, [Bun16]) als detailliert ausgearbeitete Referenz vorgelegtwerden. In der Wertschöpfung und der Automatisierung werden häufig komplexe Softwa-resysteme verwendet. Damit diese für Industrie 4.0 genutzt werden können, müssen siezuverlässig und leistungsfähig sein, aber auch ökonomisch entwickelt werden. In [VDI15]werden vier derzeitig existierende Ansätze analysiert und auf die Wiederverwendbarkeithin untersucht:

Ansatz für die Realisierung eines Communication Layers

• OPC Unified Automation

Ansatz für die Realisierung des Information Layers

• IEC Common Data Dictionary (IEC 61360 [IEC09a]) als Standard für Daten-typen für Elektronikteile.

• Merkmale, Klassifikation und Werkzeuge nach eCl@ss [e.V16g] für Stan-dards zur Klassifizierung und Beschreibung von Produkten und Diensten

• Electronic Device Description Language (EDDL) für die Informationsbe-schreibung in Geräten

• Field Device Tool (FDT) als Standard für Kommunikation und Konfigurationvon Feldgeräten

Ansatz für die Realisierung von Functional und Information Layer

• Field Device Integration (FDI) als Integrationstechnologie, welches Möglich-keiten aus FDT und EDDL miteinander verbindet

Ansatz für die durchgängige Nutzung vorhandener Technologien

• Automation Markup Language (AutomationML) [IAF16] für den Datenaus-tausch im kompletten Fertigungsprozess

6

Kapitel 2. Grundlagen 2.2. OPC Unified Architecture (OPC UA)

• eCl@ss

Eine technologische Grundlage für Industrie 4.0 sind Cyber Physical Systems (CPS). CPSsind gekennzeichnet durch eine Verknüpfung von realen (physischen) Objekten und Pro-zessen mit informationsverarbeitenden (virtuellen) Objekten und Prozessen über offene,teilweise globale und jederzeit miteinander verbundene Informationsnetze. [GB12] CPSin unmittelbarer Umgebung der Fertigungsanlagen kommunizieren mit anderen CPS, diein der Regel ebenfalls als Endgeräte auftreten (z.B. Leitsysteme oder andere Maschi-nen). Diese Art der Kommunikation besitzt ein anderes Anforderungsprofil als üblicheRechensystem-Kommunikation und wird unter dem Begriff Machine to Machine (M2M)-Kommunikation zusammengefasst.

Für M2M-Kommunikation gibt es eine Reihe verschiedener Standardlösungen, wie z.B.Message Queue Telemetry Transport (MQTT) [OAS16], Data Distribution Service (DDS)[Gro16d] und OPC UA, welches im Kapitel 2.2 vorgestellt wurde. Insbesondere DDSund MQTT sind für die Verarbeitung von Echtzeitdaten konzipiert und werden z.B. inAutomationssystemen von Fahrzeugen eingesetzt (siehe IBM Connected Car [IBM16]).Real-Time Innovations (RTI), Hersteller einer Implementierung von DDS, ist Mitgliedim Industrial Internet Consortium (IIC), welches das amerkanische Pendant zum ProjektIndustrie 4.0 ist. Somit ist die Protokollverwendung im Kontext von Industrie 4.0 sehrheterogen.

Im Rahmen der Thesis liegt der Fokus auf OPC UA als Standardlösung. Während bisherdie Annahme galt, dass beide Standards konkurrieren, wurde im März 2016 beschlossen,dass sowohl die deutsche als auch die amerikanische Industrie gemeinsame Ziele verfol-gen und kooperieren [Wal16]. Daraus folgend wird auch eine Brücke zwischen DDS undOPC UA [Sch16] (Stand: April 2016) vorangetrieben.

2.2 OPC Unified Architecture (OPC UA)

OPC UA ist ein Framework im Bereich der M2M-Kommunikation. UA (Universal Ar-

chitecture) steht dabei für die letzte Generation von Spezifikationen der OPC (Open Plat-

form Communications) Foundation. Die folgenden Grundlagen stammen zum Großteilaus OPC Unified Architecture [MLD09] und OPC: Von Data Access bis Unified Archi-

tecture [LIB10].

7

2.2. OPC Unified Architecture (OPC UA) Kapitel 2. Grundlagen

2.2.1 Historie

Mit DDE (Dynamic Data Exchange) wurde ein erster Versuch unternommen, MicrosoftWindows® Software über eine standardisierte Schnittstelle kommunizieren zu lassen.Später wurde DDE durch das leistungsfähigere OLE (Object Linking and Embedding)ersetzt. Zur Verbesserung der Performance haben Hersteller Erweiterungen für DDE an-gefertigt, wodurch weitere proprietäre herstellerspezifische DDE-Dialekte entstanden undInteroperabilität auf Ebene der Software nicht gewährleistet werden konnte. Durch diegroße Menge an neuen Systemen und Kommunikationsprotokollen mussten Herstellerweitere Treiber schreiben und warten. Dies hatte zur Folge, dass Hersteller sich einenStandard wünschten, um auf Echtzeitdaten von Systemen mit Microsoft Windows® zu-zugreifen. Es bildete sich die OPC (damals noch: OLE for Process Control) Task Force,welche 1996 die erste OPC Specification veröffentlichte, um genau dies zu ermöglichen.Später wurde aus dieser Task Force die OPC Foundation gegründet, die seitdem versucht,den Bedürfnissen der Industrie nachzukommen und standardisierte Lösungen zu ent- oderweiterentwickeln.

Aus der OPC Specification entstand die Data Access Specification (DA), die dazu dient,Mechanismen zu definieren, um Prozessdaten zu lesen und schreiben. In einer OPC Ar-beitsgruppe wurde die Alarms and Events Specification (AE) erarbeitet, um Ereignissezu überwachen und alarmiert zu werden. Im Jahr 2000 wurde die Historical Data Access

Specification (HDA) fertiggestellt, welche es erlaubt, historische Daten zu verwenden.Durch die Einführung von XML und der Verbreitung der Verwendung von Web Ser-vices hat die OPC Foundation Ende 2003 die Arbeitsgruppe OPC UA gegründet mit demZiel, diese drei Kernbereiche auf Web Services umzusetzen. Dieses Ziel hat zur Folge,dass man die Plattformabhängigkeit (DCOM Distributed Component Object Model) ausden bisherigen Spezifikationen entfernte und die Daten in einem gemeinsamen (unified)Adressraum verarbeiten kann. Weitere Spezifikationen der OPC Foundation mit ihrenKernbereichen, die in OPC UA verwendet werden:

Data eXchange (DX) Kommunikation zwischen OPC Servern

Batch Stapelverarbeitung

Security Sicherheitsregeln beim Verwenden von OPC-Komponenten

Die Arbeitsgruppe verabschiedete 2006 erste Teile der Spezifikation. Zum jetzigen Zeit-punkt werden weitere Teile veröffentlicht. Abbildung 2.1 zeigt die bisherigen 13 Teile derOPC UA Spezifikation.

8

Kapitel 2. Grundlagen 2.2. OPC Unified Architecture (OPC UA)

Abbildung 2.1: Veröffentlichte Teile der OPC Unified Architecture. Entnommen aus[Gmb16e].

Durch das Lösen der Plattformabhängigkeit dringt OPC in Bereiche des Embedded Com-puting vor und findet Verwendung in allen informationstechnischen Systemen (z.B. ERP(Enterprise Resource Planning)), so dass vertikale Integration komplett mit OPC realisiertwerden kann. Die plattformabhängigen OPC Spezifikationen werden seit Einführung vonOPC UA unter Classic OPC verwaltet. Seit 2007 sind alle Teile der OPC UA Spezifika-tion Teil des IEC- (International Electrotechnical Comission) Normungsprozesses. OPCUA löst jedoch Classic OPC nicht ab. Es wird seitens OPC Foundation sichergestellt,dass OPC Classic Geräte in OPC UA integriert werden können. Während Classic OPCals Treiber-Schnittstelle genutzt wurde, wird OPC heutzutage als System-Schnittstelleverwendet [MLD09, p. 8]. Dadurch gibt es für OPC UA neue Anforderungen an Kommu-nikation:

• Robustheit und Fehlertoleranz, Redundanz

• Plattform-Unabhängigkeit

• Skalierbarkeit

9

2.2. OPC Unified Architecture (OPC UA) Kapitel 2. Grundlagen

• Hohe Performance

• Berücksichtigung von Internet und Firewalls

• Sicherheit und Zugriffskontrolle

• Interoperabilität

Desweiteren ergeben sich neue Anforderungen an Daten-Modellierung:

• Gemeinsames Modell für OPC-Daten

• Objektorientierung

• Erweiterbares Typensystem

• Meta-Informationen

• Komplexe Daten und Methoden, die mit diesen Daten arbeiten

• Skalierbare Modelle (einfach bis komplex)

• Abstrakte Modelle

2.2.2 Kommunikation

In Classic OPC ist eine feste Art der Kommunikation vorgesehen. Dank der generi-schen Architektur von OPC UA und der Anforderung an Interoperabilität gibt es meh-rere Architektur-Muster und Eigenschaften von Server und Clients. Im folgenden werdenKommunikationseigenschaften von OPC UA-Komponenten näher betrachtet.

2.2.2.1 Architektur-Muster

OPC UA übernimmt als Basis für Kommunikationseigenschaften die Client/Server-Architektur aus Classic OPC. Da OPC UA generisch spezifiziert wurde, gibt es mehrereArchitekturmuster für OPC UA-Systeme.

Client-ServerDieses Muster ist das Basismuster für alle OPC-UA-Systeme. Der Server bieteteinen Service an, den Clients konsumieren können. Ein Client sendet eine An-frage an den Server, die dieser beantwortet. Die Kommunikation zwischen Server

10

Kapitel 2. Grundlagen 2.2. OPC Unified Architecture (OPC UA)

und Client geschieht mittels wohldefinierten Nachrichten, die in anderen OPC UA-Spezifikationen definiert sind.

Chained-ServerIn diesem Muster befinden sich 4 Rollen auf 3 Entitäten. In der ersten Entität (OPCUA-Client 1) wird die Rolle Client angenommen. Die zweite Entität (OPC UA-Server 1 und OPC UA-Client 2) nimmt sowohl Client- als auch Server-Rolle an.Die dritte Entität (OPC UA-Server 2) nimmt nur die Server-Rolle an. Somit ist esz.B. möglich, dass man mehrere OPC UA-Systeme passieren muss, um an Daten zugelangen. Ein typisches Einsatzszenario für dieses Muster ist ein Gateway. Damitman von außerhalb nicht direkt auf Geräte zugreifen kann, werden im Firmennetz-werk verschiedene Sicherheitsvorkehrungen getroffen. Eine davon könnte z.B. dasEinsetzen von Firewalls sein. Mit der Chained-Server-Architektur ist es möglich,von außen über beispielsweise HTTPS mit einem ersten OPC UA-Server zu kom-munizieren. Dieser leitet dann über HTTP oder HTTPS die Anfrage intern weiterzu einem Server, der sich in der Nähe des Geräts befindet. Als Ziel-Server wirddann die Anfrage an das Gerät über Binärprotokolle übermittelt. Somit ist es mög-lich, mit Chained-Server-Architekturen verschiedene Protokolle an verschiedenenStellen umzusetzen.

Server-to-ServerÄhnlich wie bei Chained-Servers wird hier in einer Entität Client- und Serverrolleangenommen. Clients können auf diese Entitäten von außen wie gewohnt zugrei-fen, werden aber in diesem Architekturmuster nicht berücksichtigt. Server könnenuntereinander Anfragen stellen und sind somit in der Lage, Redundanz zu erzeugen.

Aggregating ServerDas Aggregating Server-Muster lehnt ebenfalls an das Chained-Servers-Muster an.Ein Client kommuniziert mit einem Server, wie im Client-Server-Muster. Die Da-ten, die vom Server zurückgeliefert werden, sind vorverarbeitet bzw. aufbereitet.Während das Chained-Server-Muster eine Art Gateway bereitstellt, so kann diesesMuster als Proxy angesehen werden. Ein Anwendungsfall für dieses Muster ist dasÜberwachen und Ausführen von Produktionsaufträgen. Der erste Server empfängtdie Aufträge und leitet sie an andere OPC UA-Server weiter. Dabei kann der ServerStatistiken für diese Aufträge und den Status der Aufträge zwischenspeichern. So-bald die Ziel-Server ihre Teilaufträge abgearbeitet haben, kann der erste Server dieAntwort an den Client zurückschicken.

11

2.2. OPC Unified Architecture (OPC UA) Kapitel 2. Grundlagen

2.2.2.2 Redundanz

Redundanz bedeutet, dass mehrere Instanzen einer systemkritischen Komponente verfüg-bar sind, um so die Verlässlichkeit eines Systems zu erhöhen. Somit kann bei Eintritteines Fehlers auf hoher Komponentenebene eine andere genutzt werden, solange die an-dere Komponente gewartet wird. OPC UA bietet Redundanz durch Vervielfältigung vonClient/Server-Applikationen an. Es werden spezielle OPC UA Datenstrukturen und Ser-vices genutzt. Man unterscheidet zwischen Client- und Server-Redundanz.

Client-RedundanzClient-Redundanz wird z.B. verwendet, wenn kontinuierliche Überwachung vonProduktionsprozessen benötigt wird. OPC UA bietet diesen Typ Redundanz mittelsdes TransferSubscription-Services und des Monitorings von Client-Informationenim Server-Adressraum an. Der TransferSubscription-Service dient dazu, Subscrip-tions von einer Session in eine andere zu übertragen. Das folgende Szenario aus[MLD09, p. 269] zeigt, wie Client-Redundanz funktionieren kann. Es gibt einenaktiven Client mit Subscriptions auf bestimmte Daten im Server und einen Backup-Client. Der Backup-Client überwacht die Session-Informationen des aktiven Cli-ents auf dem Server, genau wie ein Client andere Daten überwachen würde. Fälltder aktive Client aus, ändert sich der Status dieser Informationen und der Backup-Client nutzt den TransferSubscription-Service, um alle aktiven Subscriptions aufdiese Session zu übertragen. Das ist möglich, da die Subscriptions auch nach Ab-lauf einer Session im Server erhalten bleiben. Der Server muss somit die Daten, diean einen Client gesendet werden, puffern, damit diese im Fehlerfall neu gesendetwerden können. Der Backup-Client benötigt die Session-Identität des aktiven Cli-ents. Wie diese Information an den Backup-Client gelangt, ist Aufgabe der Clients.

Server-RedundanzDie Server-Redundanz wird noch einmal in Transparente Server-Redundanz undNichttransparente Server-Redundanz unterteilt. Diese Kategorisierung geschiehtaus Sicht des Clients.

Transparente Server-RedundanzBei dieser Art Redundanz erfährt der Client nicht, dass ein Fehler aufdem Server eingetreten ist. Dadurch muss der Client nichts unternehmen,um seine Aufgaben fortzuführen. Der Server jedoch muss sowohl Session-Informationen als auch Daten komplett redundant anbieten. Tritt ein Fehlerauf, so wird der Request an einen zweiten identischen Server übermittelt. Die

12

Kapitel 2. Grundlagen 2.2. OPC Unified Architecture (OPC UA)

Tatsache, dass der Client mit einem anderen Server kommuniziert, wird imServer Adressraum festgehalten und weiterhin muss der Server eine ID spei-chern, um sich selbst zu identifizieren.

Nichttransparente Server-RedundanzBei nichttransparenter Server-Redundanz muss der Client bestimmte Aktio-nen durchführen, sobald ein Fehler auf dem Server eintritt. Der Client muss imFehlerfall eine neue Session zum Backup-Server erstellen und seine Subscrip-tions manuell duplizieren oder mit dem TransferSubscription-Service transfe-rieren. Da dieser Mechanismus von allen Clients genutzt werden kann (sieheClient-Redundanz) wird diese Funktionalität in einer separaten Komponen-te Failover Proxy gesammelt. Dupliziert der Client seine Subscriptions, somuss am Server nichts unternommen werden. Der Client hält seine Subscrip-tions auf beiden Servern parallel aufrecht. Im Fehlerfall werden die Anfragenauf den funktionierenden Server umgeleitet. Wird der TransferSubscription-Service genutzt, so muss der Server die Subscriptions parallel aufrechterhal-ten. Der Client hat in diesem Fall nur eine Server-Session und muss im Feh-lerfall eine andere Session zum funktionierenden Server aufbauen.

2.2.2.3 Lesen und Speichern von Daten

Die OPC DA-Spezifikation definiert Konzepte für einen Data Access Server, Data Access

Client, einen Namensraum und die OPC-Objekthierarchie, welche als Baumstruktur vonObjekten realisiert ist. Ein DA-Client kann im DA-Server verschiedene OPC-Objekte an-legen. Das Wurzelobjekt (Top-Level-Objekt) ist das OPCServer-Objekt. Während der Na-mensraum für alle DA-Clients gleich ist, kann es mehrere Objekthierarchien für verschie-dene Clients, je nach Anforderungsprofil, geben. Unter dem Top-Level-Objekt befindensich dann OPCGroup- und OPCItem-Objekte, wobei als Blätter nur OPCItem-Objekte inFrage kommen.

Es gibt drei verschiedene Möglichkeiten, wie ein Data Access Server Daten erfassen kann.

• Die Werte liegen in der gleichen Ausführungsumgebung vor (findet man z.B. inChained-Server-Architekturen)

• Die Werte müssen angefordert werden (z.B. von Feldgeräten)

• Die Werte werden dem Server unaufgefordert von Quellen gesendet

13

2.2. OPC Unified Architecture (OPC UA) Kapitel 2. Grundlagen

Um sich an diese Gegebenheiten anzupassen, können DA-Clients Daten synchron undasynchron aufrufen, um so einen Performancegewinn zu erzielen. Eine weitere Art desDatenaustausches zwischen Clients und Server ist der Refresh. Dabei werden alle akti-ven OPCItem-Objekte eines aktiven OPCGroup-Objekts gelesen. Die Initiative, Datenzu lesen, geht bei diesen Arten vom Client aus. Möchte man bzgl. Werteänderung vomServer informiert werden, so müssen im Server Änderungskriterium und ein Zyklusin-tervall festgelegt werden. Schreibt ein DA-Client einen Wert in den DA-Server, so wirdder Schreibvorgang sofort an das Gerät übermittelt. Ein Caching und verzögertes Sendenvom Server an Gerät ist nicht vorgesehen.

2.2.3 Modellierung

Die Basis OPC UA-Spezifikationen bieten nur die Infrastruktur an, um Informationenzu modellieren. Das führt dazu, dass verschiedene Hersteller ähnliche Informationen inverschiedener Weise modellieren können. Es wird deshalb angestrebt, dass Informations-modelle verwendet werden, die auf OPC UA basieren [MLD09, p. 19]. Als Beispiel wer-den Gerätespezfikationen als Basis-Modelle genutzt, die dann von Herstellern erweitertwerden können. Modellierung in OPC UA geschieht nach den folgenden Prinzipien:

Objektorientierte Techniken Mittels Objektorientierung, Typ-Hierarchien und Verer-bung können alle Instanzen eines Typs im Client auf gleiche Weise behandelt wer-den. Durch die Hierarchie können Clients mit dem Basistyp arbeiten und die spe-zialisierten Eigenschaften ignorieren.

Typinformationen Typinformationen werden veröffentlicht. Auf sie kann genau so wieauf Instanzen zugegriffen werden. Dieses Prinzip findet man ebenfalls in Relatio-nalen Datenbanken, wo man auf die Schemata der Datenbank mittels normaler Ab-fragen zugreifen kann.

Netzwerk von Knoten Information kann auf verschiedene Weise miteinander verbundenwerden, so dass je nach Anwendungsfall Informationen auf verschiedene Weiseveröffentlicht und organisiert werden können.

Erweiterbarkeit Es können nicht nur eigene Typen erstellt werden, die Basistypen kap-seln, sondern auch Relationen zwischen verschiedenen Methoden und Knoten.

Anpassungsfähigkeit OPC UA Informationsmodelle können vorhandene Datenmodellenativ unterstützen und müssen keine Abbildung definieren.

14

Kapitel 2. Grundlagen 2.2. OPC Unified Architecture (OPC UA)

Attribut BeschreibungNodeId Eindeutige Identifizierung eines Knotens im OPC UA Server, wel-

che zur Adressierung in Services genutzt wird.NodeClass Der Typ des Knotens (z.B. Objekt oder Methode).BrowseName Ein nicht lokalisierter Name des Knotens, der beim Browsen des

Servers angezeigt wird.DisplayName Ein lokalisierte Name, der bei Client-Ausgaben verwendet werden

soll.Description Ein lokalisierter Text, der den Knoten beschreibt.WriteMask Optionales Attribut, welches von Clients genutzt werden kann, um

zu erfahren, welche Attribute verändert werden können.UserWriteMask Optionales Attribut mit den Eigenschaften des WriteMask-Attributs

mit Beschränkung auf den aktuell zugreifenden Benutzer.

Tabelle 2.1: Gemeinsame Attribute aller NodeClasses

Nur serverseitige Modelle OPC UA Informationsmodelle existieren nur auf dem Server.Clients können zwar die Informationsmodelle im Server ändern, allerdings ist esnicht nötig, dass Clients das Informationsmodell integrieren müssen.

Anhand eines Beispiels aus [MLD09, p. 20] wird verdeutlicht, wie man modellieren kann.Ein Hersteller stellt einen Temperatursensor in einem OPC UA Server zur Verfügung. Da-zu muss er die Informationen bereitstellen, die von Clients abgerufen werden können (z.B.Messwert, Toleranz, Konfigurationen, usw.). Es spielt dabei keine Rolle, wo der Servergenau betrieben wird. In diesem Fall wäre es wohl so, dass der Server in einer Umgebungin der Nähe des Sensors auf einem PC oder Controller ausgeführt wird. Clients könnendann Schnittstellen für Gerätetypen schreiben., um die Informationen für den Anwen-dungsfall spezifisch weiterverarbeiten zu können. Diese Schnittstellen können dann fürjede Instanz des Sensors genutzt werden.

Die Basiskonzepte des OPC UA Modelings sind Knoten und Referenzen. Knoten könnenverschiedene NodeClasses sein, je nach Verwendung der Knoten. Knoten werden durchAttribute beschrieben. Gewisse Attribute (Tabelle 2.1) sind in jedem Knotentyp vorhan-den.Referenzen dienen zur Beschreibung einer Relation zwischen genau zwei Knoten. Siesind eindeutig identifiziert durch den Quellknoten, den Zielknoten, den Referenztyp unddie Richtung der Referenz. Da Knoten von anderen OPC UA Servern referenziert wer-den können, muss der Server in der Angabe des Zielknotens hinterlegt werden. Wennein Server nur eine Richtung der Referenz veröffentlicht, so sind die Referenzen unidi-

rektional, andernfalls bidirektional. Man unterscheidet symmetrische und nichtsymmetri-

sche Referenzen. Symmetrische Referenzen haben die gleiche Semantik in beide Richtun-

15

2.2. OPC Unified Architecture (OPC UA) Kapitel 2. Grundlagen

Attribut BeschreibungValue Der tatsächliche Wert der Variable. Der Datentyp wird

durch die folgenden drei Attribute definiert.DataType Eine NodeID eines Knotens vom Typ DataType.ValueRank Wenn der Wert ein Array ist, wird hier die Dimension

festgelegt.ArrayDimensions Wenn der Wert ein Array ist, wird hier für jede Dimensi-

on die Länge des Arrays festgelegt.AccessLevel Eine Bitmaske, welche Eigenschaften das Value-Attribut

aufweist (Lesen, Schreiben).UserAccessLevel Gleiche Eigenschaften wie das AccessLevel-Attribut be-

schränkt auf den derzeitig zugreifenden Benutzer.MinimumSamplingInterval Optionales Attribut welches benutzt werden kann um

mitzuteilen, dass der Server die Werte nur in einem be-stimmten Intervall ändern wird.

Historizing Ein Flag welches mitteilt, ob der Server eine Historie fürdie Werte anlegt.

Tabelle 2.2: Attribute der Variable NodeClass

gen (Bsp.: is-sibling-of, Geschwisterbeziehung) während nichtsymmetrische Referenzenfür jede Richtung eine eigene Semantik haben (Bsp.: has-parent/is-child-of, Eltern/Kind-Beziehung). Betrachtet man die Referenzen wie Referenzen (oder Pointer) in Program-miersprachen (Bsp.: Java, C, C++, usw.), so wird klar, dass Referenzen nicht immer gültigsein müssen. In OPC UA ist dies ebenfalls so, was bedeutet, dass Clients evtl. Referenzenauf nicht vorhandene Knoten vorfinden können. Clients müssen ebenfalls berücksichti-gen, dass Referenzen zu Schleifen führen können. Referenzen eines Knotens sind ohnedie Verwendung des Referenztyps HasOrderedComponent nicht geordnet. Möchte manRelationseigenschaften in Referenzen hinterlegen, so muss ein sogenannter Proxy Knoten

genutzt werden. Dieser steht mit beiden Referenzknoten in Verbindung.

Im folgenden werden die verschiedenen OPC UA NodeClasses betrachtet.

VariableDiese NodeClass wird verwendet, um Werte zu repräsentieren. Dabei wird zwi-schen der Repräsentierung des Wertes und weiterer Eigenschaften der Knoten vomTyp Object und Variable unterschieden. Die Variable NodeClass besitzt die At-tribute in Tabelle 2.2. Der Datentyp einer Variable wird durch die drei AttributeDataType, ValueRank und ArrayDimensions spezifiziert. Ein Grund für diese Artder Spezifizierung ist, dass Variablen-Werte Arrays oder Matrizen sein können undClients Informationen über den Aufbau benötigen. Eine Alternative wäre, die Da-

16

Kapitel 2. Grundlagen 2.2. OPC Unified Architecture (OPC UA)

Value DataType ValueRank ArrayDimensions“A String” String −1 (Scalar) -{1, 2, 3} Int16 1 -{4, 9, 10, 17}{1, 2, 3} UInt16 1 {3}{4, 9, 10}1 Uint32 −2 (Beliebig) -{1, 4, 9}{1, 2}{1, 5}{4, 5}{1, 9}{3, 4} Int32 2 {2, 3}{123, 456} Uint64 0 (1 oder mehr){1, 4}{9, 11}{5, 8}

Tabelle 2.3: Möglichkeiten von Datenwerten im Zusammenhang mit ihrem Datentyp

tentypen mittels Referenzen zu beschreiben, dies ist jedoch in OPC UA deutlichineffizienter, wenn Änderungen überwacht werden müssen ([MLD09, p. 33]). Va-riablen müssen stets zu anderen Knoten in Relation stehen, was bedeutet, dass siein mindestens einer HasComponent oder HasProperty-Referenz referenziert wer-den müssen.

Tabelle 2.3 zeigt Beispielwerte für Variablen bei entsprechender Belegung derdrei Attribute, die den Datentyp beschreiben. Das AccessLevel-Attribut (bzw.UserAccessLevel-Attribut) erweitert das WriteMask-Attribut für diese NodeClass,indem es zusätzlich festlegt, ob das Datum gelesen werden darf bzw. ob historischeDaten gelesen/geschrieben werden können.

MethodDiese NodeClass wird benutzt, um ausführbare Methoden am Server zu spezifi-zieren. Die Attribute und Eigenschaften Method NodeClasses sind in Tabelle 2.4festgelegt. Ein- und Ausgabe werden in speziellen Variable NodeClasses definiert,so dass die Attributliste der NodeClass Method einfach gehalten werden kann. DieEin- und Ausgabevariablen werden genau so wie die NodeClass Variable mit dendrei Attributen DataType, ValueRank und ArrayDimensions spezifiziert. Weiterhinbesitzen sie ein Name- und Description-Attribut. Abbildung 2.2 zeigt, wie eine Me-thode aus einer Programmiersprache in OPC UA überführt werden kann. Die da-zugehörige Signatur der Methode in Pseudocode wäre Byte[] Encrypt(Byte[] Key,

Byte[] Data, out Int32 length) Dabei haben die Variablen-Knoten InputArguments

und OutputArguments jeweils als Value-Attribut ein Array von Argument Daten-typen. Methoden sollten in der Regel schnell ausgeführt werden [MLD09, p. 36].

17

2.2. OPC Unified Architecture (OPC UA) Kapitel 2. Grundlagen

Attribut BeschreibungExecutable Ein Flag welches anzeigt, ob die Methode ausführbar ist. In der

Regel ist dies nur dann nicht möglich, wenn die Hardware desGeräts dieses nicht zulässt.

UserExecutable Gleiche Eigenschaften wie das Executable-Attribut beschränkt aufden derzeitig zugreifenden Benutzer.

Eigenschaft BeschreibungInputArguments Optionale Eigenschaft, welches eine geordnete Liste von Argu-

ment bereitstellt, die für den Funktionsaufruf benötigt werden.OutputArguments Gleiche Eigenschaften wie die InputArguments-Eigenschaft für

die Ausgabe.

Tabelle 2.4: Attribute und Eigenschaften der NodeClass Method

Abbildung 2.2: Beispiel einer Abbildung einer Methode mit Pseudocode in OPC UA.Entnommen aus [MLD09].

Falls längere Ausführungen zu erwarten sind, sollten Programme benutzt werdenund z.B. über StartProgram-, EndProgram-Methoden und beliebig vielen Zustän-den realisiert werden.

18

Kapitel 2. Grundlagen 2.2. OPC Unified Architecture (OPC UA)

ObjectObject NodeClasses dienen zum Aufbau des Server-Adressraums. Sie besitzen ne-ben den gemeinsamen Attributen keine weiteren Attribute. Werte von Objektenwerden mittels Variable NodeClasses definiert. Obwohl OPC UA nicht konkret denBesitz spezifiziert, so werden Variable und Method NodeClasses immer mit Object

NodeClasses verbunden, welche dann diese NodeClass besitzen. Ein Object kannweiterhin ein EventNotifier sein. Clients können dieses Objekt dann abonnieren,um Ereignisse zu empfangen. Abbildung 2.3 zeigt exemplarisch den Aufbau eines

Abbildung 2.3: Beispiel eines OPC UA Adressraumes mit Variablen, Objekten und Me-thoden. Entnommen aus [MLD09].

Adressraums mit Knoten vom Typ Object, Variable, Method und Referenzen.

19

2.2. OPC Unified Architecture (OPC UA) Kapitel 2. Grundlagen

ObjectType, VariableType, DataType und ReferenceTypeDiese NodeClasses stehen zur Verfügung, um die Knoten vom Typ Object, Varia-

ble, sowie dessen Value-Attribut und Referenzen zu typisieren. Knoten vom TypObject und Variable sind mit einer HasTypeDefinition-Referenz zu einem Object-

Type bzw. VariableType-Knoten verbunden. DataType-Knoten werden nicht übereine Referenz an Knoten vom Typ Variable gebunden, sondern in dessen DataType-Attribut festgelegt. Der Unterschied zwischen DataType und VariableType bestehtdarin, dass DataType den Typen des Variablenwertes repräsentiert (z.B. String) undVariableType die “Bedeutung” einer Variable typisiert (Bsp.: AnalogItemType mitder Eigenschaft Range [LIB10, p. 121]).

Alle diese NodeClasses sind in einer Baumstruktur organisiert, die eine Typhier-archie darstellt. Jede RootNode dieser vier Baumstrukturen ist der Base Type. Alleanderen Typen können mittels einer HasSubtype Referenz abgeleitet werden. Somitkann eine einfache Vererbung von Typen realisiert werden. Typen können abstrakt

sein, wie man es aus objektorientierten Sprachen gewohnt ist. Dabei gilt genausozu beachten, dass abstrakte Typen nicht instanziert werden dürfen, sondern nur vonihnen abgeleitet werden darf.

Abbildung 2.4 zeigt die Typ-Hierarchie für in OPC UA bereits vorhandene einfacheDatentypen.

Der ReferenceType repräsentiert die Semantik einer Referenz. Abbildung 2.5 zeigteinen Ausschnitt der wichtigsten OPC UA ReferenceTypes ([LIB10, p. 122]).

ViewDiese NodeClass kann dafür genutzt werden, die Sichtbarkeit auf die Knoten undReferenzen im Adressraum zu filtern. Dies kann für bestimmte Anwendungsfäl-le oder Aufgaben verwendet werden. Views können aus zwei Sichten betrachtetwerden. Zum Einen gibt es Views als View-Knoten im Adressraum, welcher alsEinsprungspunkt für den View genutzt wird. Alle Knoten, die Teil des Views sind,müssen vom View-Knoten erreichbar sein (d.h. direkt oder indirekt referenziert wer-den). Die NodeID des View-Knotens kann als Filter-Parameter verwendet werden,wenn der Adressraum durchsucht wird.

Abbildung 2.6 zeigt beispielhaft, wie ein View im Adressraum realisiert wird. Eswird ein View mit dem Namen Maintenance erstellt, welcher Referenzen auf alleMaintenance-Attribute von Geräten enthält. Der Client kann auch von Objects ausin den Adressraum einspringen und die NodeID des View-Knotens verwenden, umdie Referenzen zu filtern.

20

Kapitel 2. Grundlagen 2.3. CNC-Werkzeugmaschinen

Abbildung 2.4: In OPC UA bereits vorhandene einfache Datentypen. Entnommen aus[MLD09].

Tabelle 2.5 zeigt die Attribute der View NodeClass. Ist der View-Knoten ein Event-

Notifier, so werden alle Ereignisse aus den EventNotifier-Knoten auch über diesenView-Knoten übertragen.

2.3 CNC-Werkzeugmaschinen

In diesem Abschnitt werden Begriffe im Umfeld einer CNC-Werkzeugmaschine einge-führt und die Funktionsweise und Komponenten in einzelnen Teilsystemen benannt. DieInformationen stammen zum Großteil aus dem Skript zur Vorlesung von Prof. Dr. WilliRößner an der FH Augsburg [Rö12].

21

2.3. CNC-Werkzeugmaschinen Kapitel 2. Grundlagen

Abbildung 2.5: In OPC UA vorhandene Referenztypen. Entnommen aus [Urb13]

Abbildung 2.6: Beispiel eines Views im OPC UA Adressraum. Entnommen aus [MLD09].

22

Kapitel 2. Grundlagen 2.3. CNC-Werkzeugmaschinen

Attribut BeschreibungContainsNoLoops Ein Flag welches mitteilt, dass das hierarchische Folgen der Re-

ferenzen der enthaltenen Knoten keine Schleifen enthält.EventNotifier Eine Bitmaske die mitteilt, ob dieser View genutzt werden kann,

um Ereignisse zu abonnieren und ob auf die Historie von Ereig-nissen zugegriffen werden oder diese geändert werden kann.

Tabelle 2.5: Attribute und Eigenschaften der View NodeClass

2.3.1 Einführung in die CNC-Technik

Werkzeugmaschinen sind Maschinen, die mit Werkzeugen Werkstücke anfertigen. In ver-schiedenen Teilkomponenten der Werkzeugmaschinen befinden sich kleinere Geräte (z.B.Antriebe, Getriebe, usw.), die Werkstücke oder Werkzeuge bewegen. Die Konstruktionder Maschine gibt vor, wie und wann sich die Werkzeuge bewegen bzw. wann verschie-dene Komponenten ihre Teilaufgabe erfüllen können, um das Werkstück zu fertigen. Siewerden in den DIN 8580 und DIN 69651 Normen in verschiedenen Kategorien eingeteilt.Ein Großteil der Werkzeugmaschinen sind:

• Umformungsmaschinen

• Klassische Trennungsmaschinen (Zerteilen, Spanen, Abtragen)

• Thermische Trennungsmaschinen (Laser- und Plasmaschneider)

• Fügungsmaschinen

• Kombinationen dieser Formen

Zudem kann man Werkzeugmsachinen nach dem Automatisierungsgrad einteilen. Diesereicht von konventionellen Maschinen, die manuell bedient werden müssen, über Au-tomaten und CNC-Werkzeugmaschinen, bis hin zu großen Transferstraßen für die Seri-enproduktion. CNC-Werkzeugmaschinen (Computer Numerical Control) werden in derSteuerungstechnik eingesetzt. Werden Werkstücke von einer CNC-Werkzeugmaschineverarbeitet, so wird in der Regel nur das Einspannen bzw. Bereitstellen des Werkstücksmanuell durchgeführt. Die komplette Bearbeitung findet automatisiert statt und wird unterUmständen mit einem Soll-/Ist-Vergleich solange nachbearbeitet, bis es den gewünschtenZustand erreicht hat. Ab diesem Automatisierungsgrad der Werkzeugmaschine werden siefür die Informatik interessant. Das betreuende Personal muss die Bearbeitungsvorschrif-ten programmieren und diese dann auf die Maschinen übertragen. Je nach Hersteller der

23

2.3. CNC-Werkzeugmaschinen Kapitel 2. Grundlagen

Maschinen gibt es verschiedene Programmiersprachen und Möglichkeiten, wie die Ma-schine das Programm einlesen kann. Das Anforderungsprofil von CNC-Steuerungen mussbereits im Bau der Werkzeugmaschine berücksichtigt werden, so dass sich im Laufe derZeit mit mehr Anteil von CNC-Steuerungen neuere Technologien im Werkzeugmaschi-nenbau eingesetzt werden, wie z.B. Kugelgewindebetrieb, translatorische Messsysteme,digitale Messwerterfassung, absolute Wegmessung, usw.

2.3.2 Aufbau von CNC-Werkzeugmaschinen

CNC-Werkzeugmaschinen können aus verschiedenen Sichtweisen betrachtet werden. In

Abbildung 2.7: Exemplarischer Aufbaueiner Drehmaschine. Entnommen aus[Rö12].

Abbildung 2.8: Exemplarischer Aufbaueiner Fräsmaschine. Entnommen aus[Rö12].

Abbildung 2.7 und Abbildung 2.8 werden exemplarisch zwei CNC-Werkzeugmaschinengezeigt. Sie besitzen jeweils ein Bedienpult, sowie eine Kombination von verschiedenenmechanischen Komponenten. Im folgenden wird aufgeführt, welche Größen, Komponen-ten und Funktionen CNC-Werkzeugmaschinen aus systematischer und konstruktiver Sichtvorweisen [Rö12, p. 11].

24

Kapitel 2. Grundlagen 2.3. CNC-Werkzeugmaschinen

Das Arbeitssystem bildet den Kern der CNC-Werkzeugmaschine und umfasst das Fer-tigungsverfahren. Es umfasst die Gesamtheit aller relevanten Teilkomponenten zur Be-arbeitung (z.B. Antriebe und Steuerungen) und manueller Tätigkeiten (z.B. Einstellen,Bedien, Überwachen und Prüfen). Die in Arbeitssystemen relevanten Größen können ka-tegorisiert werden:

Geometrie Abmessungen, Form

Kinematik Wege, Geschwindigkeit

Dynamik Kräfte, Beschleunigung

Verfahrenstechnik Drehen, Lasern, Fräsen, usw.

Das Arbeitssystem besteht im wesentlichen aus Systemen für Werkzeug, Werkstück undKinematik und hat übergeordnet weitere Teilsysteme für z.B. Entsorgung und Überwa-chung.

Das Kinematiksystem unterteilt sich in zwei Funktionsgruppen:

• Relativbewegungen zwischen Werkzeug und Werkstück in der Bearbeitungsphase(Hauptachsen)

• Hilfsbewegungen, um z.B. Werkzeug und Werkstück zu wechseln (Hilfsachsen)

Man unterscheidet die Achsen zusätzlich zwischen Linear- und Drehachsen. Je nach Artdes Werkzeugs (Punkt-Werkzeug oder Form-Werkzeug) kann die Komplexität der Kine-matik variieren. Bei einem Punkt-Werkzeug (z.B. Schneidwerkzeug) ist die Kinematikbeliebig komplex, so dass die Maschine das Werkzeug im 3D-Raum frei positionierenmuss. Wenn die resultierende Form des Werkstücks bereits an den Werkzeugen vorgege-ben ist (Formwerkzeuge) muss die Maschine das Werkzeug nur linear in eine Richtungbewegen. Weiterhin kann die Kinematik zwischen serieller und paralleler Kinematik un-terschieden werden. Die serielle Kinematik bezeichnet die klassische kinematische Kette,wie sie z.B. bei Industrierobotern vorzufinden ist. In einer kinematischen Kette sorgt eineBaugruppe dafür, dass der Antrieb in einer Achse eine andere Baugruppe auf einer an-deren Achse bewegt, bis schließlich der Gesamtbewegungsablauf realisiert ist. ParalleleKinematiken besitzen mehrere Bewegungsachsen, die gleichzeitig Bewegungen durch-führen können. Ein gängiges Bauteil in der parallelen (Stab-)Kinematik ist das Hexapod,welches in Abbildung Abbildung 2.9 gezeigt ist.

25

2.3. CNC-Werkzeugmaschinen Kapitel 2. Grundlagen

Abbildung 2.9: Hexapod als gängiges Bauteil in der parallelen Kinematik. Entnommenaus [Utz05].

Das Werkzeugsystem umfasst die Schnittstelle zwischen Werkzeug und Maschine. In die-sem System werden alle Komponenten betrachtet, die sich in unmittelbarer Nähe desWerkzeugs befinden. Darunter befinden sich in der Regel folgende Baugruppen

• Werkzeugträger (Aufnahmeelemente, Träger)

• Sensorik (Schnittkrafterfassung, Temperatur, Verschleiß, Überlastung, usw.)

• Aktorik (Maßkorrektur, Bewegung von z.B. Schneidelementen, Dämpfung)

• Werkzeugwechsler (entweder mit eigener Kinematik oder mit der Kinematik derMaschine)

Zu den Aufgaben, die im Werkstücksystem durchgeführt werden, gehören die Bestimmungund das Spannen des Werkstückes. Im Werkstücksystem können folgende Kategorien eineRolle spielen:

• Werkstückform

• Spannvorrichtung (Anzahl, Beweglichkeit)

• Automatisierung des Spannvorrichtung

• Schnittstellen zur Maschine und zum Informationsfluss

Gängige Schnittstellen im Werkstücksystem sind z.B. Spindelköpfe und Nuten (An-bindung an die Maschine), Spannbacken (Anbindung an das Werkstück) und Strich-code/RFID-Technik (Anbindung an Informationsfluss, z.B. für Lagerhaltungssysteme).

Sowohl das Werkzeug- als auch dem Werkstücksystem kann mit einem Handhabungssys-tem interagieren. Dies ist notwendig, sobald ein Werkstück oder Werkzeug ausgetauscht

26

Kapitel 2. Grundlagen 2.3. CNC-Werkzeugmaschinen

werden muss. Unabhängig von Werkstück oder Werkzeug befinden werden in diesem Sys-tem Größen verwendet, um die Funktionen Transport, Vor- und Aufbereitung, Wechseln,Speichern und Einstellen der Komponenten zu beschreiben. Der Wechsel eines Werk-zeugs wird in der Regel durch Folgearbeitsgänge, Umrüstung und Nachrüstung notwen-dig. Da es bei großen Volumen der Vorgänge (z.B. das Spanen von Integralteilen im Flug-zeugbau) häufig vorkommt, dass ein Werkzeug gewechselt werden muss, wirkt sich diesesZeitfenster auf die Stückzahl pro Zeit aus. Dieses Zeitfenster ist somit eine relevante Grö-ße und wird als Werkzeugwechselzeit erfasst. Genauer ist nach VDI 2852 [VDI84] dieSpan-zu-Spanzeit definiert, die die Zeit zwischen dem Wegführen eines Werkzeugs auseiner Bearbeitungsposition und dem Ende des Heranführens eines gleichartigen Werk-zeugs in die gleiche Position angibt.

Mess- und Überwachungssysteme dienen der Vermeidung von Ausschuss und dem Schutzder Maschine. In der Regel wird signalisiert, dass ein Eingriff erfolgen muss, um dasWerkstück oder Werkzeug auszutauschen. Typischerweise werden Standzeit, Verschleißund Brüchigkeit überwacht. Werden bei der Verschleißüberwachung Grenzwerte über-schritten, so wird die Maschine in der Regel erst nach dem Bearbeitungsvorgang zumStillstand gebracht. Bei einem Bruch oder Fehlen von Werkzeugen/Werkstücken sollte dieSteuerung die Maschine sofort anhalten. Das Werkstück kann entweder in-process oderpost-process gemessen werden. Wird das Werkstück während der Bearbeitung gemessen,so spielt es eine Rolle, ob dies in Abhängigkeit vom maschineneigenen Wegmeßsystemgeschieht, da Fehler des Wegmeßsystems evtl. unentdeckt bleiben.

Damit der Gesamtzustand der Maschine erfasst wird, existiert ein Diagnose- und Prozess-

überwachungssystem. In diesem System werden Wechselwirkungen zwischen Werkstück-und Werkzeugsystem überwacht und für die Fehlerfrühdiagnose analysiert (z.B. Driftver-halten, Spitzenwerte, usw.). Für Industrie 4.0 gibt es in diesem System den Begriff desCondition Monitoring. Dieses unterteilt sich in vier Überwachungskomponenten

• Schädigungen an relativ zueinander bewegten Maschinenteilen

• Veränderungen in der Funktionsfähigkeit

• Veränderungen am Verfahrensablauf

• Veränderungen am Verfahrensergebnis

27

2.3. CNC-Werkzeugmaschinen Kapitel 2. Grundlagen

2.3.3 CNC-Steuerungen

Steuerungen in unmittelbarer Nähe der Maschine bieten Bedienern die Möglichkeit, diebeschriebenen Systeme einer Maschine zentral zu überwachen, zu steuern und zu re-geln. Um dies zu ermöglichen, muss die Steuerung einen großen Anteil des Datenvo-lumens zeitnah verarbeiten. Durch die Anbindung der Steuerungen an ein Netzwerk kön-nen Maschinen auch ferndiagnostiziert werden. Dem Bediener wird von der Steuerungein Human-Machine-Interface (HMI) präsentiert, welches zwischen Bildschirm/Tastatur-kombinationen bis zum Touchscreen variiert. Da eine Maschine nicht direkt eine Maschi-nenfunktion auslösen kann, befinden sich an der Steuerung Ein- und Ausgangskanäle, dieDaten von Sensoren und zu Aktoren übertragen müssen. Dabei unterscheidet man die Artder Datenübertragung

• Point-to-Point-Übertragung (Einzelverdrahtung und Verkabelungssysteme)

• Bus (Datenbus, z.B. INTERBUS und PROFIBUS und Energiebus, z.B. SiemensEcofast und Lenze L-Force)

Auch berührungslose Technologien wie RFID, Lichtwellen und WLAN werden für dieDatenübertragung genutzt. Durch die Verwendung von CNC-Steuerungen hat sich lauteinem Privatblog für CNC-Fachkraft-Kurse des Bildungszentrums München [BM16] dieSpan-zu-Spanzeit um mehr als 20% verringert. Um Maschinenfunktionen auszulösen,werden Komponenten zwischen CNC-Steuerung und Maschine benötigt. Diese teilen sichin folgende Bereiche auf:

• Anpaßsteuerung

• Achsensteuerung

• Leistungsteil

Die Anpaßsteuerung wird in der Regel von einer Speicherprogrammierbaren Steuerung

(SPS) übernommen und wird im Englischen mit Programmable Logic Controller (PLC)bezeichnet. Sie formt Schaltbefehle unter der Voraussetzung erfüllter Vorbedingungen umund gibt diese von an die Maschine weiter oder umgekehrt. Eine Achsensteuerung (oderLage-Regelkreis) sorgt dafür, dass zwischen dem Wegmeßsystems der Maschine und denAntrieben ein Regelkreis entsteht, der von der CNC-Steuerung parametrisiert wird. DerLeistungsteil schaltet Motoren, Ventile und andere Komponenten, da die geringe Leistungder Steuerungsimpulse nicht ausreichen.

CNC-Steuerungen werden kategorisiert in:

28

Kapitel 2. Grundlagen 2.3. CNC-Werkzeugmaschinen

• Punktsteuerung

• Streckensteuerung

• Bahnsteuerung

Bediener haben bei den meisten Steuerungs-Anwendungen die Möglichkeit, das fertigeWerkstück selbst zu modellieren und dies von der Maschine herstellen zu lassen (Compu-

ter Aided Manufacturing oder CAM-Software) oder ein Programm manuell zu erstellenund dies abarbeiten zu lassen. Um Programme in CNC-Steuerungen zu schreiben, un-terscheidet man zwischen Programmen für komplexere Bewegungsabläufe (MotionCon-

trol) und rudimentären technologiespezifischen Programmen (Punkt anfahren, Vorwärts,Hoch, usw.). Für PLC-Programme wird häufig der Standard IEC 61131-3 verwendet, wel-cher als einziger globaler Standard für PLC-Programmiersprachen gilt. Er spezifiziert fünfProgrammiersprachen, um PLCs zu programmieren:

• Anwendungsliste/AWL (engl.: Instruction List/IL) (Assembler als passendes Ge-genstück in der Informatik)

• Kontaktplan/KOP (engl.: Ladder Diagram/LD) (grafisch)

• Funktionsbausteinsprache/FBS (engl.: Function Block Diagram/FBD) (grafisch)

• Ablaufsprache/AS (engl.: Sequential Function Chart/SFC) (grafisch)

• Strukturierter Text/ST (engl.: Structured Text/ST) (Pascal als passendes Gegenstückin der Informatik)

Obwohl IEC 61131-3 fast 25 Jahre zur Verfügung steht, ist die Verwendung von diesenSprachen in den Vereinigten Staaten nicht sehr verbreitet [Pay16]. Durch Bereitstellungder verschiedenen Programmiersprachen steht es dem Programmierer frei, verschiede-ne Teilprogramme jeweils in einer Programmiersprache zu schreiben. Die resultierendenTeilprogramme können dann unabhängig von der Programmiersprache zu einem ganzenProgramm zusammengefügt werden. Alternativ werden Programme mit herstellerspezifi-scher Software erstellt oder Variationen der Relay-Ladder-Logic (RLL)-Programmierungbenutzt. CNC-Programme hingegen werden nach der Norm ISO 6983 (DIN 66025) ge-schrieben.

29

2.3. CNC-Werkzeugmaschinen Kapitel 2. Grundlagen

30

Kapitel 3

Analyse

3.1 Anforderungen

Firmen, die in der Fertigung CNC-Werkzeugmaschinen verwenden, werden diese für In-dustrie 4.0 aufrüsten wollen. Die Anwendungsfälle in Abbildung 3.1 müssen betrachtet

Abbildung 3.1: Anwendungsfälle des zu entwickelnden Prototyps

werden. Im Rahmen der Master-Thesis wird ein Szenario betrachtet, welches in Zusam-menarbeit mit der Eckelmann AG erstellt wird, wodurch ein Teil der Anforderungen ge-nerisch und ein anderer Teil Szenario-spezifisch ist. Die verschiedenen Anforderungen,werden in dieser Arbeit analysiert und die Analyseergebnisse münden in Designentschei-

31

3.1. Anforderungen Kapitel 3. Analyse

dungen.

Die folgenden Anwendungsfälle werden betrachtet:

U1 Ein Hersteller von CNC-Komponenten muss in der Lage sein, die CNC-Komponen-ten in ein Informationsmodell zu überführen. Dieses Informationsmodell dient demÜberblick über die Daten- und Funktionssicht der verschiedenen Komponenten. Esgilt zu prüfen, welche Daten von CNC-Werkzeugmaschinen und CNC-Steuerungenfür das Modell relevant sind und welche Modellierungsmöglichkeiten existieren.

U2 Das Informationsmodell muss für Technologien im Kontext Industrie 4.0 verwendbarsein. Dies bedeutet, dass Daten der CNC-Werkzeugmaschine und CNC-Steuerungvon Teilnehmern im Netzwerk abgerufen werden können. Es gilt zu prüfen, welcheKommunikationstechnologien genutzt werden können, um das entworfene Infor-mationsmodell zu nutzen.

U3 Die Eckelmann AG möchte in der Lage sein, über das entworfene InformationsmodellDaten für die Überwachung des Energieverbrauchs und des Verschleiß verschiede-ner Maschinenkomponenten bereitzustellen.

Aus den Anwendungsfällen können folgende Anforderungen entnommen werden:

A1 Ein Informationsmodell für CNC-Steuerungen erstellen. Die im Grundlagenkapitel2.3.3 beschriebenen CNC-Steuerungen führen CNC-Programme aus. Es gilt zu prü-fen, welche Informationen aus CNC-Steuerungen und Programmen für ein Infor-mationsmodell relevant sind und ob bereits vorhandene Informationsmodelle exis-tieren.

A2 Ein Informationsmodell für eine CNC-Werkzeugmaschine erstellen.CNC-Werkzeugmaschinen sind für den Fertigungsprozess angefertigte Werkzeug-maschinen mit einer CNC-Steuerungskomponente. Da die mechanischen Eigen-schaften einer Werkzeugmaschine separat von der CNC-Steuerung betrachtet wer-den (vgl. Kapitel 2.3) muss ein Informationsmodell für CNC-Werkzeugmaschinenerstellt werden. Es gilt zu analysieren, ob und wie das Informationsmodell für CNC-Steuerungen mit dem Informationsmodell für Werkzeugmaschinen verknüpft wer-den kann und ob bereits vorhandene Ansätze dafür existieren.

A3 Das Informationsmodell muss im Kontext Industrie 4.0 genutzt werden können undsomit mit den dort vorhandenen Technologien kompatibel sein. In Kapitel 2.1 wer-den verschiedene M2M-Protokolle genannt. Als Standardlösung soll OPC UA für

32

Kapitel 3. Analyse 3.1. Anforderungen

den Kontext Industrie 4.0 genutzt werden. Es muss analysiert werden, wie ein Infor-mationsmodell in OPC UA genutzt werden kann. Weiterhin können Lösungsansätzefür das Überführen von vorhandenen Informationsmodellen in OPC UA existieren.

A4 In Kapitel 2.2 werden verschiedene Architekturmuster für OPC UA vorgestellt. Diesemüssen auf ihre Vor- und Nachteile untersucht und bezüglich ihrer Verwendbarkeitfür den Anwendungsfall evaluiert werden.

A5 OPC UA bietet im Standard keine Referenz-Implementierung. Deshalb wird nachvorhandenen OPC-UA-Implementierungen recherchiert und diese analysiert.

A6 Das Informationsmodell muss mit Daten befüllt werden. Im Informationsmodell wer-den statische und dynamische Informationen hinterlegt. Es muss untersucht werden,welche Informationen im Betrieb der CNC-Werkzeugmaschine in das Informati-onsmodell übertragen werden müssen und welche Möglichkeiten es gibt, dies zutun.

Die genannten Anforderungen können in folgende Problemfelder zusammengefasst wer-den:

Vorhandene Werkzeuge für das Arbeiten mit OPC UA Wie in der Beschreibung vonAnforderung A5 beschrieben, existiert keine Standard-Implementierung von OPCUA. Für OPC UA Server existieren verschiedene Referenz-Implementierungen.In diesem Problemfeld werden diese Standard-Implementierungen bezüglich ihrerVerwendbarkeit untersucht. Dabei gilt zu prüfen, welche Architekturmuster (sie-he A4) unterstützt werden und ob diese für den Anwendungsfall U2 geeignet sind.Desweiteren wird in diesem Problemfeld analysiert, ob Modellierungswerkzeugebereitstehen, um die Informationsmodelle in den Anforderungen A1 und A2 zu er-stellen, wie auch die Anbindung an OPC UA Server (Anforderung A3) zu unterstüt-zen.

Modellierung von CNC-Werkzeugmaschinen Für die Anforderungen A1, A2, und A3

und dem Anwendungsfall U3 müssen Modellierungsaspekte betrachtet werden.Da CNC-Steuerungen Bestandteil von CNC-Werkzeugmaschinen und im Wesent-lichen Werkzeugmaschinen von CNC-Werkzeugmaschinen unterscheiden, werdendiese Aspekte im Problemfeld Modellierung von CNC-Werkzeugmaschinen zusam-mengefasst. Für dieses Problemfeld muss untersucht werden, welche Modellie-rungsmöglichkeiten für Geräte und Komponenten von Werkzeugmaschinen exis-tieren und wie Daten von einer CNC-Steuerung modelliert werden können. Dasresultierende Informationsmodell muss in OPC UA repräsentiert werden können.

33

3.2. Vorhandene Werkzeuge für das Arbeiten mit OPC UA Kapitel 3. Analyse

Zugriff auf CNC-Steuerungen Für die Anforderung A5 muss ein Zugriff auf vorhan-dene CNC-Steuerungen erfolgen. Da CNC-Steuerungen keine einheitliche Schnitt-stelle haben, müssen die verschiedenen Schnittstellen analysiert werden. Insbeson-dere muss die Anbindung von CNC-Steuerungen der Eckelmann AG unterstütztwerden, um den Prototyp zu evaluieren.

Im folgenden werden die Problemfelder in dieser Reihenfolge analysiert.

3.2 Vorhandene Werkzeuge für das Arbeiten mit OPCUA

3.2.1 Überblick

OPC UA ist ein Framework für M2M-Kommunikation, welches im Abschnitt 2.2 einge-führt wurde. Ein Server stellt für Clients einen navigierbaren Baum (Adressraum) be-reit. Entwickler, die einen OPC UA Server bereitstellen wollen, müssen den Adress-raum modellieren und den Server implementieren. Verschiedene Werkzeuge stehen zurVerfügung, um Entwickler bei diesen Aufgaben zu unterstützen. Die OPC Foundationstellt auf ihrer Webseite Referenzen auf verschiedene Produkte von Mitgliedern der OPCFoundation bereit [Fou16b] (z.B. Development Kits und verschiedene Client-/Server-Implementierungen). Die API aus dem Teil 4 der OPC UA Specifications wird in einerReferenz-Implementierung angeboten [Fou16a]. Beispiel-Code steht für Mitglieder derOPC Foundation zur Verfügung.

Im Verlauf der Literatur-Recherche wurde Stefan Hoppe [Fou16c] (mittlerweile Vizeprä-sident der OPC Foundation, Stand: September 2016) bezüglich Style Guides und Tippsfür das Modellieren in OPC UA kontaktiert. In diesem Schriftverkehr wurden das Toolkitund die Anwendungsprogramme von Unified Automation empfohlen. Die Unified Auto-mation GmbH bietet sowohl Software Development Kits für OPC UA für die Betriebssys-teme Microsoft Windows ® und Linux als auch einige Anwendungsprogramme für dasArbeiten mit OPC UA Servern. Darunter fallen:

UaModeler Modellierung des OPC UA Adressraums und Generierung von Code für denOPC UA Server von Unified Automation

UaExpert OPC UA Client mit Unterstützung für Monitoring

34

Kapitel 3. Analyse 3.2. Vorhandene Werkzeuge für das Arbeiten mit OPC UA

UaGateway Gateway für basierende OPC Classic Applikationen, um sie für OPC UAServer kompatibel zu machen

Das Toolkit mit einem Beispiel-OPC-UA-Server und der UaModeler für das Modellierendes Adressraums werden im folgenden beschrieben.

3.2.2 Unified Automation SDK

Das SDK enthält neben Bibliotheken und API-Dokumentation jeweils Einführungsbei-spiele, um eigene OPC-UA-Lösungen zu entwickeln. Die verschiedenen Produkte stehenfür Evaluationszwecke frei zur Verfügung und können mit einer Lizenzgebühr zu Voll-versionen umgestuft werden. Evaluierungsversionen haben unterschiedliche Effekte aufdie einzelnen Produkte. Der OPC UA Server beendet sich eine Stunde nach Start, wenndieser sich im Evaluationsmodus befindet.

Der OPC UA Server von Unified Automation wird mit dem SDK zum Download ange-boten. Er unterstützt OPC UA Datenzugriff, Methoden, Ereignisse, Alarmierungen, Zu-stände und Historien. Um den Adressraum aufzubauen, bietet das SDK eine API. DerUaModeler erleichtert es den Anwendern, den Adressraum aufzubauen, indem dieserCode generiert, der diese API benutzt. Im SDK befindet sich ein voll funktionsfähigerBeispiel-OPC UA Server, dessen Adressraum für eine Sensor-Applikation modelliert undvon einem emulierten Sensor-Controller befüllt wird. Die API-Referenzdokumentationenthält eine Einführung, die in sieben Sektionen unterteilt ist:

• Grundlegende OPC UA Server Konsolenapplikation

• Adressraum mit Daten aus der realen Welt erweitern

• Knoten mit Echtzeitdaten verbinden

• Unterstützung für Methoden

• Unterstützung für Ereignisse

• Unterstützung für Alarme und Zustände

• Unterstützung für Historie

Das SDK stellt Klassen bereit, die Knoten im Adressraum repräsentieren (z.B. UaNode,UaVariable, UaDataType, usw.). Für das Verwalten aller Knoten in einem Namens-raum wird ein NodeManager erzeugt. Dieser verwaltet den Lese- und Schreibzugriff

35

3.2. Vorhandene Werkzeuge für das Arbeiten mit OPC UA Kapitel 3. Analyse

auf die Knoten, das Generieren von Ereignissen und das Verknüpfen von Knoten. DieNodeManager müssen dann zur Laufzeit des Servers eingebunden werden. Es existiertein RootNodeManager, der allen anderen übergeordnet ist. Dieser kann z.B. verwendetwerden, um den kompletten Adressraum zu durchsuchen (browse) oder Referenzen zuKnoten in andere NodeManager hinzuzufügen.

Allen Variablen im Adressraum können bezüglich ihres Verhaltens konfiguriert werden,wenn ein Datum von ihnen angefordert wird (Lesezugriff im Client auf eine Variable imAdressraum). Zwei relevante Konfigurationsmöglichkeiten für Variablen sind:

• Variablenwert liegt im Cache: Der NodeManager wird über das CallbackreadValues und variableCacheMonitoringChanged über einzelne Lesezugriffe undMonitoring-Aktivität informiert.

• Variablenwert wird im Variablen-Objekt gespeichert: Der Programmierer setzt denWert der Variable manuell mit setValue. Lesezugriffe von Clients werden nicht anden NodeManager weitergeleitet.

3.2.3 UaModeler

Der UaModeler ist eine graphische Anwendung, die es ermöglicht, ein Informationsmo-dell für OPC UA Server von Unified Automation zu erstellen. Es kann ein Projekt erstelltwerden, um Informationsmodelle zu erstellen oder um Code für Informationsmodelle zugenerieren. Informationsmodelle können entweder über mehrere Projekte verteilt sein (fürjeden Namensraum ein Adressraum) oder in einem einzigen Projekt verwaltet werden. ImUaModeler können XML-NodeSets, die von der OPC Foundation spezifiziert sind, umden Adressraum in XML abzubilden, generiert werden. In der Evaluierungsversion kannder UaModeler nur zehn Knoten in ein XML-NodeSet exportieren.

Abbildung 3.2 zeigt die graphische Benutzeroberfläche des UaModeler. Im linken obe-ren Bereich wird in Project angezeigt, welche Projekte (Informationsmodelle) eingebet-tet sind. Diese können individuell für die Code-Generierung an- und abgewählt werdenund vor Veränderungen geschützt werden (locking). Der untere linke Abschnitt kannentweder Ausgaben des UaModeler (Output) oder eine Baum-Abbildung des Informa-tionsmodells (Information Model) anzeigen. Dort können dann Sub-Typen, Instanzenoder Datentypen hinzugefügt werden. Das mittlere Fenster kann für das Editieren derKnoten-Eigenschaften genutzt werden. Darin können z.B. die Werte für BrowseName,DisplayName, NodeClass, TypeDefinition, usw. verändert werden. Das rechte Fenster

36

Kapitel 3. Analyse 3.2. Vorhandene Werkzeuge für das Arbeiten mit OPC UA

Abbildung 3.2: UaModeler GUI

zeigt die Eigenschaften des Knotens in einer Tabelle an. Durch Klicken auf das blaueZahnrad kann Code in einem ausgewählten Verzeichnis für das Informationsmodell ge-neriert werden.

3.2.4 Designentscheidungen

Aufgrund der Empfehlung von Herrn Hoppe wird das SDK von Unified Automation ver-wendet. Die Produkte von Unified Automation werden von Firmen genutzt, die internatio-nal in ihrem Segment eine große Rolle einnehmen, z.B. Siemens AG (Speicherprogram-mierbare Steuerungen), TRUMPF (Hersteller von Werkzeugmaschinen), Bosch Rexroth,3S-Smart Software Solutions (CODESYS) und Mitsubishi [Gmb16f]. Die Vorteile bei derVerwendung der Produkte sind:

Ausgereifte API Aufgrund des hohen Marktanteils der Produkte ist die API des SDKweit entwickelt und getestet. Das SDK bietet jeweils ältere Versionen für den LongTime Support und neuere Versionen, in denen neue Features hinzugefügt werden,die dann von den Entwicklern getestet werden können.

Graphische Modellierung des Adressraums Der UaModeler bietet die Möglichkeit,den Adressraum graphisch zu modellieren und den benötigten Code für den Ser-ver zu generieren. Dadurch ist es einfacher, eigene Informationsmodelle in kurzerZeit vollständig zu entwickeln oder bei Bedarf zu ändern.

37

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Auswahl der Programmiersprache Während einige OPC UA Stacks vorwiegend für ei-ne Programmiersprache bereitgestellt werden, stellt Unified Automation das SDKfür Java, C++, .NET und ANSI C zur Verfügung. Somit können sowohl leistungs-stärkere Plattformen unterstützt werden (z.B. Desktops) und Plattformen, die weni-ger Resourcen benutzen (z.B. Embedded Systems).

Unterstützung gängiger Betriebssysteme Die Bibliotheken im SDK stehen für Linuxund Microsoft Windows ® bereit. Damit werden die Betriebssysteme unterstützt,die am häufigsten verwendet werden.

Durch das Lizenzmodell und Closed Source entstehen einige Nachteile:

Beschränkte Laufzeit der Server Der OPC UA Server von Unified Automation beendetsich nach einer Stunde Laufzeit. Für die Evaluierung des Prototyps ist dies jedochausreichend.

Beschränkung des UaModelers Der UaModeler ist in der Lage, XML NodeSets zu ex-portieren. Damit können Adressräume im XML-Format mit anderen Entwicklernausgetauscht werden. Die Evaluierungsversion des UaModelers erlaubt es, maxi-mal zehn Knoten zu exportieren, wodurch der Austausch vollständiger Informati-onsmodelle in der Regel nicht möglich ist.

Bindung an Entwicklungsumgebung Während bei der Verwendung der Linux-Biblio-theken die Entwicklungsumgebung frei gewählt werden kann, so ist die Entwick-lung unter Microsoft Windows ® mit der Microsoft Visual Runtime Component anbestimmte Versionen gebunden. Unified Automation stellt sowohl Bibliotheken fürMicrosoft Visual Studio 10 und 12 bereit.

Als Programmiersprache für den Prototyp wird C++ gewählt. Dem Autor der Thesis istdie Programmiersprache geläufig, und es gibt keine Einschränkungen der Programmier-sprachen bezüglich der Zielplattform.

3.3 Modellierung von CNC-Werkzeugmaschinen

3.3.1 Überblick

Es existieren in der Automatisierungstechnik viele Gerätebeschreibungssprachen, die inunterschiedlichen Aufgabenbereichen eingesetzt werden. Der Anreicherungsgrad der Da-

38

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

ten in diesen Modellen ist je nach Verwendung im Lebenszyklus des Geräts unterschied-lich, da diese Sprachen oft über den gesamten Verlauf der vertikalen und horizontalenIntegration benutzt werden. Unabhängig von Sprachen, die Geräte beschreiben, existie-ren Mechanismen, die dazu dienen, die verschiedenen Geräte zu integrieren. Auch wenndiese Mechanismen oft Gerätebeschreibungssprachen genannt werden, so handelt es sichdabei in der Regel eher um Frameworks, die den Zugriff beschreiben und nicht das Ver-halten im Betrieb [Sel11]. Im folgenden werden klassische Beschreibungssprachen undIntegrationsmechanismen betrachtet (Abschnitt 3.3.2). Danach wird das Protokoll MT-Connect analysiert (Abschnitt 3.3.3), welches für die Beschreibung und Integration vonWerkzeugmaschinen entwickelt wurde.

Das Objektmodell von OPC UA ist generisch und bietet verschiedene Elemente, um In-formationsmodelle für Geräte zu erstellen. Für OPC UA gibt es bereits Companion Spe-cifications, die spezifizieren, wie man bestimmte Gerätebeschreibungen, die in diesemAbschnitt analysiert werden, in OPC UA umsetzen kann (siehe MTConnect, FDI und Au-tomationML). Die OPC Foundation bietet mit der Companion Specification (OPC Uni-

fied Architecture for Devices (DI)) ein Informationsmodell für Geräte, welches das Basis-Informationsmodell mit gerätespezifischen Elementen erweitert. Eine weitere CompanionSpecification, das OPC UA Information Model for CNC Systems, spezifiziert ein Modellfür den Austausch von Daten zwischen CNC-Systemen. Diese beiden Companion Speci-fications werden in den Abschnitten 3.3.4 und 3.3.5 analysiert.

3.3.2 Klassische Gerätebeschreibungssprachen

Eine Anforderung des Gateways ist es, CNC-Maschinen in OPC UA zu modellieren undin diesem Datenmodell Meta- und Ablauf-Informationen bereitzustellen. Da OPC UAim Basis-Informationsmodell nur generische Bausteine besitzt und es somit keine Mo-dellierungslemente gibt, die speziell dazu dienen, CNC-Maschinen zu modellieren, wirdzunächst untersucht, welche Beschreibungsmöglichkeiten existieren und wie diese dannbei der Modellierung in OPC UA berücksichtigt werden können.

Generic Station Description (GSD),Generic Station Description Markup Language (GSDML)

GSD-Dateien sind ASCII-Dateien im INI-Format, die Geräte in einem PROFIBUS-Kommunikationsnetzwerk [e.V16d] beschreiben. Sie werden von den Geräteherstellern

39

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

geschrieben und können von Anwendungen bzw. Anwendern genutzt werden, um Gerä-te zu konfigurieren. Für jedes Gerät mit einer PROFIBUS-Geräteschnittstelle muss einesolche Datei erstellt werden. Das Format unterliegt einer Spezifikation [e.V16e], die vonder PROFIBUS Nutzerorganisation bereitgestellt wird. PROFIBUS-Geräte bestehen auseinem Grundgerät (Buskoppler) und Modulen, die in Slots verbaut werden können. Die-se Slots bieten sowohl zyklische als auch azyklische Daten und Dienste an. Die Dateienunterteilen sich in einen Metadaten-Abschnitt, worin Informationen über den Hersteller,Seriennummer, usw. hinterlegt sind, und in einen Abschnitt für Parameter, in dem sämtli-che Ein-/Ausgabekanäle mit ihren Bedeutungen aufgelistet werden.

GSDML-Dateien verfolgen das Ziel der GSD-Dateien unter der Berücksichtigung desXML-Formats. Das Format dieser Dateien wird ebenfalls in einer Spezifikation beschrie-ben, die für Mitglieder zum Download bereitgestellt wird [e.V16c]. Durch die Verwen-dung von XML können diese Dateien mit Schemata (XML Stylesheet Definitions, XSD)validiert werden. Diese Schemata werden von der PROFIBUS Nutzerorganisation für ver-schiedene Gerätetypen auf ihrem Webserver bereitgestellt. Neben den syntaktischen Än-derungen aufgrund des XML-Formats ergeben sich zu GSD folgende Neuerungen:

• Unterstützung des Datenmodells von PROFINET IO-Geräten (im GrundePROFIBUS-Geräte mit Subslots) und generell Geräte, die der Norm IEC 61158(Digitale Datenkommunikation für Messungen und Steuerung) [IEC14] entspre-chen

• Möglichkeit zur Modellierung ganzer Gerätefamilien im Gegensatz zu einzelnenGeräten

• Verwendung mehrerer Fremdsprachen für textuelle Beschreibungen in einer einzel-nen Datei

• Struktur basiert auf ISO 15745-1 Standard [ISO03a], welcher Kommunikationspro-file und Kommunikationsaspekte von Geräteprofilen von Feldbusgeräten beschreibt

Field Device Configuration Markup Language (FDCML)

Die FDCML dient als XML-Metasprache zur Beschreibung von Automatisierungskom-ponenten. FDCML wird von den Nutzergruppen DRIVECOM [e.V16a] und INTERBUSClub [e.V16b] entwickelt. Im Gegensatz zu Gerätebeschreibungssprachen gibt es inFDCML keine ausmodellierten Geräte, sondern generische Strukturen zu deren Beschrei-bung. Das Informationsmodell nutzt auf hoher Abstraktionsebene Media Access Units

40

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

(MAUs) als Modellierungselement für Geräte. MAUs werden über Eigenschaften mitGeräteparametern und E/A-Daten verbunden. Die FDCML berücksichtigt bei der Model-lierung verschiedene Standards, z.B. IEC 61499 (Funktionsblöcke für industrielle Mess-und Steuerungssysteme) [IEC16a], IEC 61158 und ISO 15745-1. FDCML ist zur Stan-dardisierung in ISO 15745-3 [ISO03b] eingereicht worden.

Automation Markup Language (AutomationML)

Der AutomationML e.V. hat sich zum Ziel gesetzt, die Integration von Automatisie-rungskomponenten entlang der Prozesskette mit einem entsprechenden Format für Da-tenaustausch zu erleichtern. Mit AutomationML [IAF16] besitzt man die Möglichkeit,Topologien, Attribute, Schnittstellen und Relationen von Maschinen abzubilden. Für dasObjektmodell wird CAEX benutzt (Computer Aided Engineering Exchange), welchesim IEC 62424 Standard [IEC16b] beschrieben wird. Für die Beschreibung von Kine-matik und Geometrie wird COLLADA (Collaborative Design Activity) benutzt, welchesim ISO/PAS 17506 Standard [ISO12] spezifiziert ist. Das COLLADA-Dateiformat wirdvon der Khronos Group verwaltet und von vielen 3D-Applikationen genutzt [Gro16c].Um Verhalten der Maschinen in AutomationML zu repräsentieren, wird PLCopen XML[PLC16] verwendet, welches dafür entwickelt worden ist, Programme, die der IEC 61131-3 Norm (Programmiersprachen für programmierbare Steuerungen) [IEC13] entsprechen,in XML-Dokumenten zu übertragen. OPC UA unterstützt die Umsetzung von Informa-tionsmodellen aus AutomationML durch die Spezifikation OPC UA Information Model

for AutomationML [Fou16d]. AutomationML kann die Objektstruktur bis maximal zurDetailstufe des Fabrikobjekts selbst modellieren (z.B. Roboter, Greifer, usw.), aber nichtdie Komponenten der Objekte (z.B. Achsen, Verbindungen, usw.).

Field Device Tool (FDT) und Device Type Manager (DTM)

Ein von der Field Device Group entwickeltes Konzept, das aus dem FDT und DTM be-steht, soll insbesondere bei der Inbetriebnahme von Geräten unterstützen. Das Konzeptist in IEC 62453 standardisiert [IEC09b]. Der DTM stellt in diesem Konzept die low level

Geräteanbindung (Konfiguration, Diagnose, Betrieb) zur Verfügung. Diese DTM könnendann in Frame-Applikationen (Inbetriebsnahme-Software) genutzt werden, indem dieseDTM eine FDT-Schnittstelle anbieten. Die FDT-Schnittstelle wird von der FDT-Joint In-terest Group spezifiziert [Gro16b]. Es gibt heute eine Reihe von Erweiterungen für dieFDT-Schnittstelle, um verschiedene Feldbusse wie z.B. EtherCAT [Gro16a], PROFIBUSund Sercos [e.V16f] zu nutzen.

41

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Electronic Device Description Language (EDDL)

Die EDDL dient zur Beschreibung der statischen Gerätedaten als auch des dynamischenVerhaltens aus Sicht des Bedieners. Die Sprache wird dazu genutzt, EDD-Dateien zuerstellen, die dann wiederum von verschiedenen Anwendungen genutzt werden können,um verschiedene Komponenten zu bedienen.

Field Device Integration (FDI)

Während man mit EDDL darauf abzielt, Konfigurationsparameter von Geräten mit ei-ner Datei zu beschreiben, zielt FDT darauf ab, dass Hersteller bestimmte Software-Komponenten (DTM) mit ihren Geräten ausliefern, die dann in Anwendungen genutztwerden. Mit FDI nach der Norm IEC 62769 [IEC15a] wird angestrebt, die beiden Stan-dards EDDL und FDT zu verbinden. Der Aufgabenbereich für FDI umfasst Konfigura-tion, Kalibrierung, Diagnose und Kommission von Geräten. In einem Paket (FDI device

package) werden dann Gerätebeschreibungen, Geschäftslogik als auch Benutzerschnitt-stellenbeschreibungen und optional Anhänge, wie z.B. Handbücher, zusammengefasst.Das Informationsmodell von FDI ist mit OPC UA gekoppelt. Mithilfe des Standards IEC62769-5 (Field Device Integration (FDI) - Part 5: FDI Information Model) [IEC15b] istes möglich, Feldbusgeräte direkt in OPC UA zu modellieren.

3.3.3 MTConnect

MTConnect [Ins16] ist ein Protokoll, welches dafür entwickelt wurde, Daten zwischenFertigungsanlagen und Überwachungs- und Analysesoftware zu übertragen. Das Proto-koll entstand aus der Zusammenarbeit zwischen der Berkeley Universität, dem GeorgiaInstitute of Technology und verschiedenen Industrieteilnehmern. Es existiert ein Draft,der das Protokoll spezifiziert [Ins14]. Der Draft unterteilt sich in drei Teile:

1. Protokollinformation und Aufbau der XML-Dokumente

2. Komponenten von Werkzeugmaschinen und Beschreibung der Daten

3. Datenströme von Geräten

Die derzeitige Version des Drafts (Stand: Juni 2016), erlaubt nur Lesezugriff auf dieMaschinen. Agenten können die Daten von Maschinen, die im XML-Format hinterlegt

42

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

sind, über eine HTTP RESTful-Schnittstelle anfordern. Geräte, die eine MTConnect-Schnittstelle besitzen, können in OPC UA auf Basis der MTConnect OPC UA CompanionSpecification modelliert werden.

MTConnect-Modelle setzen sich aus mehreren Teilkonzepten zusammen:

Header Protokollinformationen (z.B. die Version)

Components Elemente um Geräte zu modellieren

DataItems Daten, die gemessene Werte definieren, die von diesem Gerät publiziert wer-den.

MTConnect besitzt auf der obersten Ebene des Modells einen Einstiegspunkt zurMaschinen-Topologie, das MTDevices-Element. Dieses Element dient nur dem Aufbauder Struktur und hat sonst keinerlei semantische Bedeutung für Werkzeugmaschinen. Aufder nächsten Ebene befinden sich eine beliebige Anzahl von MTDevice-Elementen. Siesind Container für alle Geräteteile. Ein MTDevice-Element besitzt Attribute (Hersteller,Seriennummer, Konfiguration und Sampling-Intervall), sowie Referenzen auf DataItems,Components und Conditions.

Abbildung 3.3 zeigt einen Ausschnitt von gängigen Komponenten für Geräte, die in MT-Connect modelliert werden. Das Modell von MTConnect unterscheidet dabei die vierHauptkomponenten: Controller (Steuerungen, NC/CNC), Systems (Teilsysteme), Doors

(Türen, um Menschen vor Eingreiffen in die Mechanik zu schützen) und Axes (Lineareund rotatorische Achsen einer Werkzeugmaschine).

3.3.4 OPC Unified Architecture for Devices (DI)

OPC Unified Architecture for Devices (DI), im weiteren OPC UA DI bezeichnet, be-schreibt in einer Companion Specification ein offenes und standardisiertes Gerätemodell.Die Companion Specification liegt derzeit in Version 1.01 vor, die im Juli 2013 veröf-fentlicht wurde [Fou13]. Es werden in der Spezifikation die drei aufeinander aufbauendeModelle beschrieben:

• Ein Basis-Datenmodell, welches eine von Protokollen unabhängige, generischeSicht auf Geräte ermöglicht

• Ein Kommunikationsmodell, welches Elemente für Netzwerk- und Verbindungsin-formationen anbietet und somit das Modellieren von Topologien ermöglicht

43

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Abbildung 3.3: Überblick über gängige Komponenten eines MTConnect Geräts. Entnom-men aus [Con16].

• Ein Integrationsmodell, welches zusätzlich Elemente und Regeln definiert, um dieIntegration eines kompletten Systems (inkl. Kommunikation und Gerätebeschrei-bungen) zu verwalten.

Abbildung 3.4 zeigt einen Ausschnitt aus dem Gerätemodell von OPC UA DI. Es solleinen Gesamtüberblick über die Komponenten verschaffen und enthält dadurch nicht alledefinierten Komponenten und Relationen. Im oberen Teil der Abbildung werden Objekt-Typen von OPC UA gezeigt, von denen TopologyElementType und ProtocolType ableiten.Diese befinden sich im mittleren Kasten, wo sich die Objekt-Typen befinden, die in derSpezifizierung eingeführt werden. Der untere Kasten zeigt dann exemplarisch, wie dieseObjekt-Typen in Spezifikationen, die von anderen Organisationen definiert werden (z.B.PROFIBUS), benutzt werden.

TopologyElementType ist der Basisobjekt-Typ für Elemente in einer Geräte-Hierarchieund führt Parameter und Methods ein, wie auch Functional Groups, um verschiedenePerspektiven auf Geräte zu bekommen. In DeviceType werden generische Bestandteilefür beliebige Geräte gesammelt. Der BlockType-Typ dient zur Modellierung von Feldbus-geräten, die aneinander gereiht sind. Sie können zusätzlich Untergeräte und Blockgeräte

44

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

Abbildung 3.4: Überblick des Gerätemodells. Entnommen aus [Fou13].

unterstützen. Der Typ ProtocolType dient zur Repräsentierung der Kommunikation vonGeräten, z.B. bei Feldbus-Geräten. Diese Typ wird im weiteren nicht analysiert, da erfür die Modellierung von CNC-Werkzeugmaschinen nicht benötigt wird. Um eine Struk-tur für modulare Hierarchien aufzubauen, wird ConfigurableObjectType verwendet. Fallses benötigt wird, erscheint eine Instanz dieses Typs als Einstiegselement für die darauffolgende Hierarchie.

3.3.4.1 TopologyElementType

Abbildung 3.5 zeigt Komponenten des TopologyElementType und ihre Relationen zu-einander. Im oberen Abschnitt der Abbildung befinden sich die Vererbungsrelationenzwischen den Komponent-Typen, während der untere Abschnitt eine Beispiel-Instanzzeigt. Die Typen FunctionalGroupType und UIElementType leiten von FolderType bzw.BaseVariableType aus dem OPC UA Basis-Datenmodell ab. Der UIElementType wirdzur Repräsentierung von GUI-Komponenten genutzt und wird hier nicht weiter betrach-tet. Falls ein Element in der Hierarchie Parameter oder Methoden anbietet, so werdendiese in den Objekten ParameterSet bzw. MethodSet aufgelistet. Die Gruppen vom TypFunctionalGroupType können dazu verwendet werden, um die Methoden und Parameterzu ordnen und optional eine GUI-Komponente zu referenzieren, die diese Funktionalitätveranschaulicht. Methoden und Parameter können von verschiedenen solcher Gruppenreferenziert werden.

In Tabelle 3.6 ist die Definition des Typs TopologyElementType aufgezeigt. Der Typ ist

45

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Abbildung 3.5: Komponenten des TopologyElementType. Entnommen aus [Fou13].

Tabelle 3.6: Definition des TopologyElementType. Entnommen aus [Fou13].

abstrakt und leitet von BaseObjectType aus der OPC UA Spezifikation Teil 5 (Part 5)ab. Die Typen DeviceType und BlockType, welche noch analysiert werden, leiten vondiesem Typ ab und werden in der Companion Specification in Abschnitt 5.3 und 5.10definiert. Die Referenzen zu ParameterSet, MethodSet und Lock, welcher dazu genutztwird, um insbesondere in Feldbusanlagen Geräte für einen bestimmten Zeitraum exklu-siv zu beanspruchen, werden nicht weiter betrachtet, da sie für die Modellierung derCNC-Werkzeugmsachine zunächst nicht benötigt werden. Ein TopologyElementType re-

46

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

ferenziert verschiedene Instanzen des Typs FunctionalGroupType über den BrowseNameIdentification und <GroupName>. Standardisierungskomitees sollen Identification so be-füllen, dass das entsprechende Bus-Protokoll in der Lage ist, ein Gerät zu identifizie-ren. <GroupName> mit der ModellingRule OptionalPlaceholder wird durch den Namender Funktionsgruppe ersetzt. Da bei der Modellierung von CNC-Werkzeugmaschinen zu-nächst keine Bus-Protokolle betrachtet und auch keine Methoden verwendet werden, wer-den die optionalen Referenzen in der Definition nicht betrachtet.

3.3.4.2 DeviceType

Tabelle 3.7: Definition des DeviceType. Entnommen aus [Fou13].

In Tabelle 3.7 wird die Definition des Typs DeviceType veranschaulicht. DeviceType istabstrakt und leitet von TopologyElementType ab und enthält somit alle Attribute ausTopologyElementType. Im folgenden wird beschrieben, für welche Zwecke die Attribu-te genutzt werden.

SerialNumber Die Seriennummer ist eine eindeutige Nummer des Geräteherstellers, dieinsbesondere zur Verfolgung des Geräts und für Gewährleistungsansprüche genutztwerden kann. Sie befindet sich häufig leicht erkennbar an der Außenseite des Ge-räts.

47

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

RevisionCounter Diese Zahl gibt an, wie oft sich die statischen Daten eines Geräts imLaufe der Zeit verändert haben.

Manufacturer Eine Zeichenkette, die den Namen des Geräteherstellers angibt.

Model Eine Zeichenkette für das Modell des Geräts.

DeviceManual In dieser Zeichenkette kann sowohl ein Pfad im Dateisystem als aucheine URL auftauchen, die zum Handbuch des Geräts führt.

DeviceRevision, SoftwareRevision, HardwareRevision Diese Nummern geben dieRevision des Geräts, der Software (oder Firmware) und der Hardware wieder.

DeviceClass Diese Zeichenkette wird für die Geräteklasse bzw. Domain des Geräts ge-nutzt. In der Companion Specification werden keine Namen vordefiniert. Sie sindTeil der Spezifikationen, die auf OPC UA DI aufbauen.

DeviceHealth Der Status des Geräts nach NAMUR Recommendation NE107 [PI06]. DerDatentyp wird unter der Auflistung beschrieben.

Der Aufzählungstyp DeviceHealth kann folgende Werte annehmen:

NORMAL_0 Das Geräte funktioniert ungehindert.

FAILURE_1 Fehlfunktion im Gerät oder der Peripherie.

CHECK_FUNCTION_2 Es wird derzeitig eine Funktionsprüfung durchgeführt (z.B.Konfigurationsänderungen, lokale Änderungen, usw.)

OFF_SPEC_3 Das Gerät arbeitet außerhalb der Spezifikation (z.B. bei Sensoren) odereine Diagnose hat ergeben, dass eine zu starke Abweichung zwischen den Wertenvorhanden ist.

MAINTENANCE_REQUIRED_4 Das Ausgabesignal ist zwar korrekt, jedoch wirddas Gerät durch eine hohe Abnutzung bald falsche Werte liefern.

Falls ein Gerät keine Information über den RevisionCounter preisgibt, muss dieserWert auf −1 gesetzt werden. Obwohl ein Attribut vorhanden sein muss (ModellingRuleMandatory), so können leere Strings benutzt werden, falls ein Gerät diese Attribute nichtexportiert.

Desweiteren kann ein Gerät vom Typ DeviceType optionale Support-Informationen anbie-ten. Die angebotene Information wird in verschiedenen Verzeichnissen strukturiert. Jede

48

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

Information wird als read-only Variable in den Verzeichnissen untergebracht und wirddem Typen (nicht der Instanz) zugeordnet. Verschiedene Instanzen vom Typ DeviceType

besitzen somit alle die gleichen Support-Informationen, die hier bereitgestellt werdenkönnen. Der BrowseName ImageSet enthält Bilddateien, die die GUI-Komponenten,die vom Gerät referenziert werden, aufzeigt. Da bereits vorher schon festgelegt wur-de, dass es keine FunctionalGroupType-Instanzen gibt und somit auch keine Referen-zen zu GUI-Komponenten, entfällt dieses Attribut. ProtocolSupport kann für Feldbus-geräte verwendet werden, um Gerätebeschreibungsdateien anzubieten (z.B. GSD). DieBrowseNames DeviceTypeImage und Documentation können auch für die Modellierungvon Werkzeugmaschinen genutzt werden. DeviceTypeImage kann mehrere Bilddateiendes Geräts enthalten, und Documentation kann mehrere Dokumente enthalten, die dasProdukt beschreiben. Während im DeviceManual-Attribut nur ein Pfad als Zeichenketteerlaubt ist, so können hier Dokumente vollständig eingebettet werden. In Tabelle 3.8 wird

Tabelle 3.8: Definition von DeviceTypeImage. Entnommen aus [Fou13].

Tabelle 3.9: Definition von Documentation. Entnommen aus [Fou13].

DeviceTypeImage und in Tabelle 3.9 wird Documentation definiert. Die Typ-Definitionder Verzeichnisse ist der OPC UA Basis-Objekttyp FolderType. <DocumentIdentifier>

und <ImageIdentifier> werden durch die entsprechenden Namen des Bilds oder Doku-ments ersetzt. OPC UA definiert die Bildtypen BMP, GIF, JPEG und PNG in Teil 3 derSpezifikationen. Der Typ des Dokuments, welcher für die Verarbeitung notwendig ist,muss dem Namen entnommen werden.

49

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

3.3.4.3 ConfigurableObjectType

Der ConfigurableObjectType-Typ dient zur Hierarchie-Bildung von modularen Geräten.Tabelle 3.10 zeigt die Definition von ConfigurableObjectType. Es enthält ein Verzeich-

Tabelle 3.10: Definition von ConfigurableObjectType. Entnommen aus [Fou13].

nis mit dem BrowseName SupportedTypes, worin alle erlaubten Untergeräte, welcheselbst wieder modulare Geräte sein können, auflistet. Das <ObjectIdentifier>-Attributwird nicht näher spezifiziert.

3.3.4.4 Modulare Geräte im Adressraum

Die aus der Spezifikation vorgestellten Typen, reichen aus, um modulare CNC-Werkzeug-maschinen zu modellieren. Dabei liegt der Fokus auf physikalischen Geräten, wie z.B.Motoren und Antrieben.

Abbildung 3.11 zeigt exemplarisch ein modulares Gerät. Ein modulares Gerät wird auseinem Top Device (in der Abbildung Some Modular Device Type) und Untergeräten (Mo-dulen) zusammengesetzt. Die Module eines Geräts werden im Objekt SubDevices aufge-listet, welches vom Typ ConfigurableObjectType ist. Dieses Objekt enthält ein Verzeich-nis SupportedTypes, welches die Namen der unterstützen Typen auflistet. Die Spezifi-kation sieht vor, dass man Geräte zur Laufzeit des OPC UA Servers hinzufügen kann,spezifiziert jedoch nicht genauer wie und überlässt dies dem Benutzer. Wenn ein Typ nureinmal in einem modularen Gerät instanziert werden darf, so muss das SupportedTypes

den Namen dieses Typs in der Auflistung streichen. Für die Modellierung von CNC-Werkzeugmaschinen genügt also eine Auflistung aller vorhandenen Module, da das In-formationsmodell selbst zur Laufzeit nicht verändert werden soll. Module können selbstwieder modulare Geräte (Top Device) sein.

Im Adressraum müssen alle BrowseNames und NodeIds, die in dieser Companion Spe-cification definiert wurden, den Namensraum http://opcfoundation.org/UA/DI/ benutzen.

50

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

Abbildung 3.11: Beispielstruktur eines modularen Geräts nach OPC UA DI. Entnommenaus [Fou13].

Alle modellierten Geräte müssen in einem DeviceSet-Objekt aufgelistet werden. Für mo-dulare Geräte gilt, dass nur das Top Device aufgelistet wird. Das DeviceSet-Objekt istein Kind-Element vom Objects-Objekt aus dem OPC UA Basis-Datenmodell und hat alsTypeDefinition den Typ BaseObjectType.

Die folgenden Server Facets mit ihren Conformance Units für diese Companion Specifi-cation sind wie folgt:

• Base Device Server Facet

DI Information Model Unterstützung von Objekten, die mit den Typen aus die-ser Companion Specification konform sind. Insbesondere Objekte vom TypDeviceType und FunctionalGroupType.

DI DeviceSet Unterstützung des DeviceSet-Objekts.

DI DeviceHealth Optionale Unterstützung der Eigenschaft DeviceHealth.

DI DeviceSupportInfo Optionale Unterstützung von zusätzlichen Daten für Ge-räte. Die hier genannten Verzeichnisse DeviceTypeImage und Documentation

sind relevant in dieser Kategorie.

51

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Weitere Server Facets, die in dieser Companion Specification angeboten werden, werdenfür die Modellierung von CNC-Werkzeugmaschinen nicht benötigt und somit nicht weiterbetrachtet.

3.3.5 OPC Unified Architecture Information Model for CNC Sys-tems

Das OPC Unified Architecture Information Model for CNC Systems, im folgenden OPCUA CNC genannt, ist eine geplante Companion Specification für OPC UA, welche voneiner Working Group mit der OPC Foundation und dem VDW (Verein Deutscher Werk-zeugmaschinenfabriken e.V.) veröffentlicht wird. Für die Thesis stellte die Uni Stuttgart(Herr Keinert [Stu16]) ein Release Candidate der Specification in der Version 0.9 bereit.Die Spezifikation dient zur Modellierung von CNC-Datenschnittstellen und beschreibtden Zugriff auf bereitgestellte Daten von CNC-Systemen. Im folgenden werden dieseDaten beschrieben.

Parameter Konfigurationsdaten des CNC-Systems, der Hardware und der Kommunika-tionsmechanismen.

Zustandsdaten Zustandsdaten der Hardware, des CNC-Kernels und des PLC (Abschnitt2.3).

Prozessdaten Ist-Werte, die von verschiedenen Geräten zyklisch zum CNC-Systemkommuniziert werden.

Befehlsdaten Sollwerte, die von der Maschinen-Schnittstelle zum CNC-System und vondort zyklisch zu den Geräten kommuniziert werden.

Alarmierungen & Benachrichtungen Ereignisse, die von verschiedenen Stellen (z.B.CNC-Kernel, PLC, UI) ausgelöst werden.

Dateien Dateien, die von der Maschinen-Schnittstelle zum CNC-Kernel, PLC oder zuGeräten transferriert werden, um z.B. Konfiguration oder Kalibrierung vorzuneh-men.

Da ein Teil dieser Daten sowohl geschrieben als auch gelesen werden darf, werden vonder Spezifikation die folgenden Anwendungsfälle abgedeckt:

52

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

Setup Daten, die zur Konfiguration von Produktionssystemen genutzt werden, wel-che von CNC-Systemen gesteuert werden. Darunter fallen Produktdaten (z.B.Aufgabenbeschreibung, Werkzeugbeschreibung), aber auch CNC-Konfigurations-parameter (z.B. Achsenparameter, Zykluszeit).

Operation Bereitstellen von UI-Einstiegspunkten für die Ablaufsteuerung.

Observation Bereitstellen von Einstiegspunkten für eine UI, sowie Überwachungs- undDiagnoseapplikationen.

In der Spezifikation von OPC UA CNC wird ein Modellierungskonzept beschrieben.Dies besagt, dass herstellerspezifische und anwendungsspezifische Erweiterungen mög-lich sein sollen, jedoch nicht genau, wie diese zu integrieren sind. Elemente zur Beschrei-bung von Daten sollen, soweit möglich, OPC UA VariableType verwenden. Zur Beschrei-bung von einheitsbasierenden Daten (z.B. Positionsdaten) wird AnalogItemType und fürdie Beschreibung von einheitslosen Daten (z.B. Zustände) wird DataItemType verwendet.Die Specification gibt in diesem Release Candidate keine Einheiten für die Daten, die mitAnalogItemType modelliert werden. Für alle fehlenden Einheiten werden SI-Einheitenverwendet, die dem repräsentierten Wert des Attributs entspricht. Weiterhin werden indieser Version nicht alle Attribute vollständig beschrieben, so dass Annahmen darübergemacht wurden, was sie in Bezug auf CNC-Werkzeugmaschinen bedeuten könnten.

Abbildung 3.12 zeigt alle Objekt-Typen, die in der Spezifikation definiert werden.Darin enthalten sind strukturierende Typen (CncListType), ein Typ für CNC-Kanäle(CncChannelType), gruppierende Typen (z.B. CncAxisType) und Typen für Ereignisse undBenachrichtigungen (CncAlarmType und CncMessageType). Neben den Typen in dieserAbbildung gibt es den Typ CncInterfaceType, der die komplette CNC-Datenschnittstellerepräsentiert.

Der CncInterfaceType-Typ repräsentiert den Einstiegspunkt in eine CNC-Datenschnitt-stelle. Dieser wird in Abbildung 3.13 dargestellt. Der CncInterfaceType-Typ enthält Re-ferenzen zu den Objekt-Typen in Abbildung 3.12 und weitere Eigenschaften der Daten-schnittstelle (z.B. Version, Revision, usw.). Auf alle Komponenten soll schnellstmöglichzugegriffen werden, wodurch der CncInterfaceType-Typ flache Listen zu den Komponen-ten enthält, ohne auf ihre logische Hierarchie im CNC-System Rücksicht zu nehmen. DieHierarchie in einem CNC-System wird durch die einzelnen Komponenten selbst herge-stellt (siehe Abbildung 3.12).

Abbildung 3.14 zeigt beispielhaft den Adressraum für ein Informationsmodell einer 3-Achsen-CNC-Werkzeugmaschine. Im folgenden werden alle Objekt-Typen definiert und

53

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Abbildung 3.12: Objekttypen in OPC UA CNC. Entnommen aus OPC UA CNC 0.9.

beschrieben.

3.3.5.1 CncAlarmType

CncAlarmType repräsentiert ein Fehler-Ereignis und leitet von DiscreteAlarmType ausdem OPC UA Basis-Datenmodell ab. Tabelle 3.15 zeigt die Definition des CncAlarmType.

HelpSource Zusätzliche Informationen, die nicht von der Nachricht (Message-Attributvon DiscreteAlarmType) abgedeckt wird. Wenn HelpSource einen Hilfstext reprä-sentiert, muss der Datentyp LocalizedText gewählt werden. Wird HelpSource ge-nutzt, um einen URI anzugeben, der auf eine externe Information zeigt, so mussder Datentyp String gewählt werden.

AlarmIdentifier Dieses Attribut entspricht einer eindeutigen Fehlernummer, die in derRegel von CNC-Systemen angeboten wird.

AuxParameters Fragmentierte Informationen, die z.B. von UI genutzt werden kann, umeigene Fehlernachrichten zu erstellen.

Die Spezifikation gibt an, wie ein Teil der vererbten Attribute zu nutzen ist.

54

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

Abbildung 3.13: Struktur des CncInterfaceType in OPC UA CNC. Entnommen aus OPCUA CNC 0.9]

Severity Dieses vererbte Attribut (BaseEventType) repräsentiert den Schweregrad desEreignisses und wird in Teil 5 der OPC UA Spezifikationen definiert. Die OPCUA Spezifikation definiert nur den höchsten Schweregrad (1000) und den niedrigs-ten (1). OPC UA CNC gibt exemplarisch 2 Beispiele, wie Severity gesetzt werdenmuss bei drei oder mehr Schweregraden.Beispiel 1: Werden die Schweregrade Information, Error und Warning repräsen-tiert, so entspricht Information dem Wert 1, Warning einem Wert zwischen 2 und999 und Error dem Wert 1000.Beispiel 2: Werden die Schweregrade Information, Error, Warning, Critical und Fa-tal repräsentiert, so entspricht Information dem Wert 0, Warning einem Wert zwi-schen 2 und 333, Error einem Wert zwischen 334 und 666, Critical einem Wertzwischen 667 und 999 und Fatal dem Wert 1000.

ConditionName Die textuelle Repräsentierung von Severity (z.B. Warning, Error, Fatal,usw.)

SourceName, SourceNode Die SourceNode (Node ID der Fehlerquelle) soll so genau

55

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Abbildung 3.14: Beispiel eines Informationsmodells einer 3-Achsen-CNC-Werkzeug-maschine nach OPC UA CNC. Entnommen aus OPC UA CNC 0.9.

Tabelle 3.15: Definition des CncAlarmType. Entnommen aus OPC UA CNC 0.9.

56

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

wie möglich angegeben werden. Kann die Quelle nicht eindeutig identifiziert wer-den, muss die Node ID der Instanz des CncInterfaceType genutzt werden. FürSourceName muss der Name der Komponente genutzt werden, die den Fehler ge-neriert hat (z.B. CNC, PLC, Channel, usw.).

AckedState Wenn keine Bestätigung gefordert wird, ist dieser Wert true. Ist dieser Wertfalse, ändert sich dieser Wert in true, sobald dieses Ereignis bestätigt wurde.

Retain, ActiveState Diese beiden Attribute sollen synchronisiert sein und zeigen an, obein Ereignis abgearbeitet wurde.

3.3.5.2 CncMessageType

CncMessageType ist ein Typ, der von ConditionType aus dem OPC UA Basis-Daten-modell ableitet und keine weiteren Referenzen einführt. Nachrichten dieses Typs wer-den nicht für Alarm-Ereignisse genutzt. Typischerweise werden CNC-Informationen inProgrammen generiert, um Tracing oder andere Informationen an einen Client zu veröf-fentlichen. Instanzen von CncMessageType werden von CncChannelType undCncInterfaceType generiert.

3.3.5.3 CncInterfaceType

Tabelle 3.16: Definition des CncInterfaceType. Entnommen aus OPC UA CNC 0.9.

Tabelle 3.16 zeigt die Definition des CncInterfaceType.

<CncAlarm>, <CncMessage> Der Typ kann Ereignisse und Benachrichtigungen gene-rieren, welche dazu verwendet werden, Fehler oder Informationen anzubieten.

57

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

CncAxisList, CncChannelList, CncSpindleList Diese Listen werden dafür verwendet,um alle Komponenten des CNC-Systems in den entsprechenden Verzeichnissenaufzulisten.

0:FileSystem Ein optionaler Einstiegspunkt in das Dateisystems des CNC-Systems.

Fix Eine Zeichenkette zur Versionierung für Änderungen in der Implementierung (vonBug Fix).

Revision Die Revisionsnummer der Companion Specification.

VendorName, VendorRevision Zeichenketten für die Bereitstellung von Herstellerna-men und der Revision des CNC-Systems. Das Format ist dabei dem Hersteller über-lassen.

Version Die Versionsnummer der Companion Specification.

3.3.5.4 Listen-Typen

Die Listen-Typen CncAxisListType, CncSpindleListType und CncChannelListType wer-den als strukturierendes Element im Adressraum benutzt. Sie werden in Tabelle 3.17,

Tabelle 3.17: Definition des CncAxisListType. Entnommen aus OPC UA CNC 0.9.

Tabelle 3.18: Definition des CncSpindleListType. Entnommen aus OPC UA CNC 0.9.

58

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

Tabelle 3.19: Definition des CncChannelListType. Entnommen aus OPC UA CNC 0.9.

Tabelle 3.18 und Tabelle 3.19 definiert. Sie lösen ein GeneralModelChangeEvent Ereig-nis aus, welches mitteilt, dass neue Elemente in der Liste hinzugefügt oder Elemente ausder Liste entfernt wurden. Die Attribute <CncAxis>, <CncSpindle> und <CncChannel>

sind Platzhalter (ModellingRule MandatoryPlaceholder), welche mit Namen der Achse,Spindel oder dem Kanal bei der Instanzierung ersetzt wird.

3.3.5.5 CncComponentType

CncComponentType ist ein abstrakter Typ, welcher von konkreten Typen, die Hardwareoder Software eines CNC-Systems repräsentieren, abgeleitet wird. In diesem Typ werdenalle Elemente gebündelt, die die ableitenden konkreten Typen gemeinsam haben. In Ta-

Tabelle 3.20: Definition des CncComponentType. Entnommen aus OPC UA CNC 0.9.

belle 3.20 ist CncComponentType definiert. Der Typ hat in der Spezifikation zu diesemZeitpunkt keine Referenzen.

3.3.5.6 CncChannelType

Der CncChannelType-Typ repräsentiert einen CNC-Kanal (Abschnitt 2.3). Neben denElementen für die Beschreibung eines CNC-Kanals werden weiterhin die Komponentenreferenziert, die der Kanal zu einem Zeitpunkt administriert (Achsen, Spindeln, usw.).

Für die Positionierung eines Werkzeugs, welches diesem Kanal zugeordnet ist, benutztdas Informationsmodell den Tool Center Point oder kurz TCP. Ist diesem Kanal kein

59

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Werkzeug zugeordnet, so wird stattdessen der Tool Carrier Zero Point oder kurz TCZP

genutzt.

Der Tool Carrier Zero Point ist ein Referenzpunkt der Haltevorrichtung des Werkzeugs.Abbildung 3.21 zeigt am Beispiel eines Fräswerkzeugs (links) und eines Bohrwerkzeugs

Abbildung 3.21: Beispiele für Tool Carrier Zero Points. Entnommen aus OPC UA CNC0.9.

(rechts) zwei solche Punkte.

Der Tool Center Point ist in der Regel der Schnittpunkt von der zentralen Linie und dertiefsten Spitze des Werkzeugs. Er wird im Detail von Peter Smid [Smi05] beschriebenund gibt anschauliche Beispiele. Bei Fräswerkzeugen ist der TCP in der Regel ein imagi-närer Punkt in der Schnittplatte, da diese meist Schneidkanten mit einem Radius besitzen.Für Punkt-zu-Punkt-Werkzeuge, wie z.B. Bohrwerkzeugen, ist der TCP an der Spitze desBohrers.

CncChannelType referenziert den TCP in zwei Koordinatensystemen:

60

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

Abbildung 3.22: Beispiel für einen TCP in einem Bohrwerkzeug. Entnommen aus OPCUA CNC 0.9.

Abbildung 3.23: Beispiel für einen TCP in einem Fräswerkzeug. Entnommen aus OPCUA CNC 0.9.

Base coordinate system Das Basis-Koordinatensystem (BCS) wird vom Hersteller spe-zifiziert. Der Ursprung ist im Nullpunkt der CNC-Werkzeugmaschine.

Workpiece coordinate system Das Werkstück-Koordinatensystem (WCS) wird vomBenutzer spezifiziert und erlaubt es, den Einspannungspunkt und die Ausrichtungdes Werkstücks zu berücksichtigen. Der Ursprung ist im Nullpunkt des Werkstücks.

Abbildung 3.24: Beispiel für Koordinatensysteme. Entnommen aus OPC UA CNC 0.9.

Abbildung 3.24 zeigt exemplarisch zwei Koordinatensysteme. Der Bezugspunkt M ist der

61

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Nullpunkt der CNC-Werkzeugmaschine und W der Nullpunkt des Werkstücks.

Tabelle 3.25: Definition des CncChannelType. Entnommen aus OPC UA CNC 0.9.

In Tabelle 3.25 ist CncChannelType definiert. Der Basistyp für CncChannelType ist

62

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

CncComponentType.

<CncMessage> Ein Kanal kann eine spezifische Informationsnachricht senden. Diesekommen typischerweise aus CNC-Programmen.

<GeneralModelChangeEvent> Ein GeneralModelChangeEvent wird generiert, wennsich eine Instanz eines Kanals bezüglich der Struktur verändert hat. Dies kommtunter anderem dann vor, wenn sich die Administration der Achsen bzw. Spindelneines Kanals ändert.

<CncAxis>, <CncSpindle> Diese Platzhalter werden bei der Instanzierung durch denNamen der administrierten Komponenten ersetzt.

ActFeedrate Die aktive Feed-Rate der Komponenten in Millimeter pro Minute.

ActJogIncrement Der aktive Inkrementierungs-Wert für das Vorrücken.

ActGFunctions Ein Array, welches die aktiven G-Funktionen (siehe 2.3) enthält.

Die folgenden vier Attribute beziehen sich auf das aktiven CNC-Hauptprogramm:

ActMainProgramFile Dateipfad zum aktiven CNC-Hauptprogramm

ActMainProgramFileOffset Datei-Offset im aktiven CNC-Hauptprogramm.

ActMainProgramLine Zeilennummer des aktiven CNC-Hauptprogramms.

ActMainProgramName Name des aktiven CNC-Hauptprogramms.

ActMFunctions Ein Array, welches die aktiven M-Funktionen (siehe 2.3) enthält.

ActOperationMode Der aktive Operationsmodus des CNC-Systems. Der DatentypCncOperationMode wird unter der Auflistung beschrieben.

ActOverride Der aktive Wert des Feed-Rate Override Switches. Dieser Wert ist in derRegel in 10%-Inkrementierungen segmentiert und beschreibt die Abweichung vomprogrammierten Feed-Rate-Wert.

Die folgenden sechs Attribute beziehen sich auf das aktuelle CNC-Programm:

ActProgramBlock Ein Block von vorherigen, aktuellen und folgenden Zeilen des akti-vien CNC-Teilprogramms.

63

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

ActProgramFile Dateipfad zum aktiven CNC-Programm.

ActProgramFileOffset Datei-Offset im aktiven CNC-Programm.

ActProgramLine Zeilennummer des aktiven CNC-Programms.

ActProgramName Name des aktiven CNC-Programms.

ActProgramStatus Der Status des aktiven CNC-Programms. Der DatentypCncChannelProgramStatus wird unter der Auflistung beschrieben.

ActStatus Der aktive Status des Kanals. Der Datentyp CncChannelStatus wird unter derAuflistung beschrieben.

BlockMode Zeigt an, ob der Blockmodus (Ausführung eines einzelnen Programm-blocks) aktiv ist.

CmdFeedrate Soll-Wert für die Feed-Rate in Millimeter pro Minute.

CmdOverride Soll-Wert für den Override-Switch.

DryRunFeed Die Feed-Rate für einen Testlauf (Dry Run) in Millimeter pro Minute.

FeedHold Wahr wenn der Feed Hold eingeschaltet ist. Das bedeutet, dass sich keineAchsen (Spindeln schon) mehr bewegen.

Id Eindeutiger Bezeichner des Kanals.

PosTcpBcsA, PosTcpBcsB, PosTcpBcsC,PosTcpBcsX, PosTcpBcsY, PosTcpBcsZ

Die aktuelle A/B/C/X/Y/Z-Position des Tool Center Points im Base coordinate sys-

tem. Falls kein Werkzeug vorhanden ist, wird der Tool Carrier Zero Point angege-ben. Der Datentyp CncPositionType wird unter der Auflistung beschrieben.

PosTcpWcsA, PosTcpWcsB, PosTcpWcsC,PosTcpWcsX, PosTcpWcsY, PosTcpWcsZ

Die aktuelle A/B/C/X/Y/Z-Position des Tool Center Points im Workpiece coordi-

nate system. Falls kein Werkzeug vorhanden ist, wird der Tool Carrier Zero Point

angegeben. Diese Elemente spiegeln die Position, wie sie im CNC-Programm vor-kommen, wieder. Der Datentyp CncPositionType wird unter der Auflistung be-schrieben.

64

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

ToolId Eindeutiger Bezeichner für das aktuelle Werkzeug. Dies kann z.B. ein Eintrag ineine Tabelle sein. Der Wert 0 bedeutet, dass kein Werkzeug vorhanden ist.

Der Aufzählungstyp CncOperationMode kann folgende Werte annehmen:

Manual Manueller Operationsmodus: Inkrementelle Bewegung der Achsen wird vomBenutzer gesteuert.

MDA MDA Operationsmodus: Manuelle Dateneingabe und Ausführung.

Automatic Automatischer Operationsmodus: Ausführen von CNC-Teilprogrammen.

Der Aufzählungstyp CncChannelProgramStatus kann folgende Werte annehmen:

Stopped Programm ist gestoppt.

Running Programm wird ausgeführt.

Waiting Programm ist im Wartezustand.

Interrupted Programm ist unterbrochen.

Canceled Programm ist abgebrochen.

Der Aufzählungstyp CncChannelStatus kann folgende Werte annehmen:

Active Der Kanal ist aktiv.

Interrupted Der Kanal ist unterbrochen.

Reset Der Kanal wird zurückgesetzt.

Der Strukturtyp CncPositionType enthält drei Elemente:

ActPos Ein Double-Datum, welches die aktuelle Position kennzeichnet.

CmdPos Ein Double-Datum, welches die gewünschte Position kennzeichnet.

RemDist Ein Double-Datum, welches die restliche Distanz zur gewünschten Zielpositionkennzeichnet.

65

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Tabelle 3.26: Definition des CncPositionVariableType. Entnommen aus OPC UA CNC0.9.

Für den Strukturtyp gibt es einen zugehörigen Variablen-Typ, der Auskunft über dieStruktur-Elemente gibt. Der zugehörige Variablen-Typ ist CncPositionVariableType undwird in Tabelle 3.26 aufgezeigt. Die Elemente mit dem BrowseName 0:EngineeringUnits

und 0:EURange sind äquivalent zu interpretieren wie bei AnalogItemType und geben In-formationen über die Einheiten und den Wertebereich für die Positionsangaben. Da dieBrowseNames bereits im OPC UA Basis-Datenmodell definiert wurden, wird der Präfix0: gewählt.

3.3.5.7 CncDriveType

Der CncDriveType enthält alle gemeinsamen Elemente aller Betriebselemente von CNC-Systemen, wird von konkreten Komponenten (z.B. Achsen und Spindeln) abgeleitet undist somit abstrakt. Die Definition von CncDriveType wird in Tabelle 3.27 gezeigt. Der

Tabelle 3.27: Definition des CncDriveType. Entnommen aus OPC UA CNC 0.9.

Basistyp für CncDriveType ist CncComponentType

ActChannel Gibt die Node ID des administrierenden Kanals an. Ist dieses Attribut leer,

66

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

dann wird es von keinem Kanal administriert.

ActLoad Aktiver Kraftwert in Newton.

ActPower Aktive Leistung in Watt.

ActTorque Aktives Drehmoment in Newtonmeter.

CmdTorque Soll-Wert des Drehmoments in Newtonmeter.

IsInactive Wahr, wenn diese Komponente inaktiv ist.

IsVirtual Wahr, wenn keine Hardware für diese Komponente vorhanden (und somit vir-tuell) ist.

3.3.5.8 CncAxisType

CncAxisType repräsentiert CNC-Achsen. Sie werden von Kanälen administriert und tau-chen in CncAxisList der Instanz des CncInterfaceType unabhängig davon, ob und vonwelchem Kanal sie gerade administriert werden. Die Definition von CncAxisType wird in

Tabelle 3.28: Definition des CncAxisType. Entnommen aus OPC UA CNC 0.9.

Tabelle 3.28 gezeigt. Der Basistyp für CncAxisType ist CncDriveType

ActStatus Der aktive Status der Achse. Der Datentyp CncAxisStatus wird nach der Auf-listung beschrieben.

IsReferenced Wahr, wenn die Achse derzeit referenziert wird. Die Companion Specifi-cation definiert nicht weiter, was dies genau bedeutet.

IsRotational Wahr, wenn diese Achse eine Rotationsachse ist, sonst linear.

67

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

PosDirect, PosIndirect Position der Achse mit Bezug zum direkten bzw. indirektenMesssystem. Der Datentyp CncPositionType ist in 3.3.5.6 beschrieben.

ZeroOffset Aktive Nullpunktkorrektur der Achse in Millimeter.

Der Aufzählungstyp CncAxisStatus kann folgende Werte annehmen:

InPosition CNC-Achse hat Zielposition erreicht.

Moving CNC-Achse bewegt sich zur Zielposition.

Parked CNC-Achse ist konfiguriert, aber nicht aktiv.

3.3.5.9 CncSpindleType

CncSpindleType repräsentiert CNC-Spindeln. Sie werden von Kanälen administriert undtauchen in der Instanz CncSpindleList des CncInterfaceType auf. Sie werden dort auchaufgelistet, wenn sie nicht von einem Kanal administriert werden. Die Definition von

Tabelle 3.29: Definition des CncSpindleType. Entnommen aus OPC UA CNC 0.9.

CncSpindleType wird in Tabelle 3.29 gezeigt. Der Basistyp für CncSpindleType istCncDriveType

ActChuckPowerStatus Aktive Leistung der Halterung.

ActGear Aktive Getriebestufe.

ActOverride Aktiver Override Status für die Drehzahl. Dieser Wert ist in der Regelin 10%-Inkrementierungen segmentiert und beschreibt die Abweichung vom pro-grammierten Drehzahl-Wert.

68

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

ActSpeed Die aktive Drehzahl bzw. Geschwindigkeit der Spindel in Meter pro Sekunde.

ActStatus Der aktive Zustand der Spindel. Der Datentyp CncSpindleStatusType wirdnach der Auflistung beschrieben.

ActTurnDirection Die aktive Drehrichtung der Spindel. Der DatentypCncSpindleTurnDirection wird nach der Auflistung beschrieben.

ActAnglePos Der aktive Wert des Drehwinkels bei interpolierender (positionsgesteuerte)Spindelbewegung. Dieser Wert ist 0, wenn die Bewegung geschwindigkeitsgesteu-ert ist. Der Datentyp CncPositionType ist in Abschnitt 3.3.5.6 beschrieben.

CmdGear Soll-Wert der Getriebestufe.

CmdOverride Soll-Wert des Override Status für die Drehzahl.

CmdSpeed Soll-Wert für die Drehzahl bzw. Geschwindigkeit.

Der Aufzählungstyp CncSpindleTurnDirection kann folgende Werte annehmen:

None Keine Rotation

CW Rotation im Uhrzeigersinn.

CCW Rotation gegen den Uhrzeigersinn.

Der Aufzählungstyp CncSpindleStatus kann folgende Werte annehmen:

Stopped CNC-Spindel gestoppt.

InTargetArea CNC-Spindel hat die gewünschte Ziel-Drehzahl erreicht.

Accelerating CNC-Spindel erhöht die Drehzahl.

Decelerating CNC-Spindel verringert die Drehzahl.

Parked CNC-Spindel konfiguriert, aber nicht aktiv.

69

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

3.3.5.10 Informationsmodell im Adressraum

Das Informationsmodell muss für alle BrowseNames und NodeIds im Adressraum denNamensraum http://opcfoundation.org/UA/CNC/ benutzen. BrowseNames aus dem OPCUA Basis-Datenmodell (z.B. EURange, EngineeringUnits und FileSystem) müssen denNamensraum http://opcfoundation.org/UA/ mit dem NamespaceIndex 0 benutzen. Lokaleingeführte Namen und Ids benutzen den Namensraum mit dem NamespaceIndex 1.

Ein OPC UA Server, welcher OPC UA Information Model for CNC Systems nutzt,muss ein CncInterface-Objekt vom Typ CncInterfaceType an einer beliebigen Stelle imAdressraum anlegen. Die darauffolgenden Nodes müssen der Struktur entsprechen, diehier beschrieben wurde. Dabei gilt darauf zu achten, dass das CncInterface-Objekt al-le CNC-Achsen und CNC-Spindeln vom Typ CncAxisType und CncSpindleType in denListen-Objekten CncAxisList (vom Typ CncAxisListType) und CncSpindleList (vom TypCncSpindleListType) enthalten sind. Desweiteren müssen alle Kanal-Objekte vom TypCncChannelType im Listen-Objekt CncChannelList (vom Typ CncChannelListType) ent-halten sein. Wenn der Dateizugriff realisiert wird, muss das CncInterface-Objekt einFileSystem-Objekt im Standard Namensraum als Kind-Element haben.

Die folgenden Server Facets mit ihren Conformance Units für diese Companion Specifi-cation sind wie folgt:

• Base CNC Data Interface Server Facet

Base Data Access Unterstützung der Strukturen und Zugriff auf alle Daten,die von der CNC-Datenschnittstelle bereitgestellt werden.

Alarming Unterstützung Alarmierungen und Nachrichten aus dieser Com-panion Specification.

• Model Change Server Facet

Model Change Unterstützung der GeneralModelChangeEvent-Ereignisseaus dieser Companion Specification.

• File Access Server Facet

File Access Unterstützung der Dateizugriff-Mechanismen aus dieser Com-panion Specification

70

Kapitel 3. Analyse 3.3. Modellierung von CNC-Werkzeugmaschinen

3.3.6 Designentscheidungen

Die Gerätebeschreibungen GSD, GSDML, EDDL (daraus folgend auch FDI) undFDCML dienen ausschließlich der Beschreibung von Feldbusgeräten. AutomationMLwird auf einer höheren Ebene der vertikalen Integration angewendet. MTConnect bie-tet als Teil des Protokolls eine XML-basierende Beschreibungsdatei für Werkzeugma-schinen. Laut einer Konferenz im November 2015 [Cor15] gilt MTConnect als de-factoStandard für Werkzeugmaschinen in den Vereinigten Staaten. Da MTConnect selbst einProtokoll ist, steht es als Alternative zu OPC UA zur Verfügung. Vor- und Nachteile vonMTConnect sind:

HTTP REST HTTP-fähige Server und Clients erfüllen REST automatisch und das Pro-tokoll ist zustandslos.

XML Die Anwendungsdaten von MTConnect sind XML-Dateien. XML ist ein weit ver-breitetes Austauschformat in der Informatik und wird von den meisten Anwendernleicht verstanden.

Zustandslos Das REST-Protokoll ist zustandslos. Dies vereinfacht die Entwicklung vonServer-Komponenten, da keine Informationen über Clients gespeichert werdenmüssen. Jedoch wird dadurch die Unterstützung von Autorisierung und Authentifi-zierung problematisch und fällt auf das unterlagerte Transport-Protokoll HTTP(S)und TCP/IP zurück.

Modellierungsmöglichkeiten Die Modellierungsmöglichkeiten sind per XML-Schemavordefiniert und basieren zum Großteil auf ISO 13399 [ISO06] (Werkzeugdatendar-stellung und -austausch). Somit stehen viele Komponenten und ein Begriffskatalogbereits zur Verfügung, um Werkzeugmaschinen zu modellieren. Der Nachteil liegtdarin, dass die Modellierung starr ist. Eine Erweiterung kann nur durch Änderungoder Erweiterung des Standards erfolgen.

Vorteile bei der Modellierung von OPC UA sind:

Freiheiten Die Modellierung des Datenmodells in OPC UA basiert auf dem Basis-Informationsmodell in OPC UA (siehe Abschnitt 2.2.3). Eigene Knotentypen, dievon den Basis-Knoten ableiten, und Referenzen werden genutzt, um das anwen-dungsspezifische Informationsmodell zu erstellen. Somit kann jedes Informations-modell in OPC UA abgebildet werden. Auch eine Änderung des Informationsmo-dells zur Laufzeit des Servers ist möglich.

71

3.3. Modellierung von CNC-Werkzeugmaschinen Kapitel 3. Analyse

Sicherheitsaspekte Die Sicherheitsaspekte sind fester Bestandteil von OPC UA (Au-thentifizierung als auch Zugriff auf Variablen und Objekte). Companion Specifica-tions können diese bei Bedarf erweitern.

Nachteile bei der Modellierung mit OPC UA sind:

Fehlende Informationsmodelle Für die Modellierung von CNC-Werkzeugmaschinenexistiert derzeit nur ein Release Candidate einer Companion Specification, mit demeine CNC-Datenschnittstelle modelliert werden kann (Abschnitt 3.3.5). Die Erstel-lung bzw. Änderung an einem Informationsmodell ist in der Regel aufwändig. Ver-schiedene Anwendungen, z.B. der UaModeler (Abschnitt 3.2.3), helfen jedoch da-bei, dies zu beschleunigen.

Diese Arbeit fokussiert sich auf die Verwendung von OPC UA. Für MTConnect gibt es ei-ne Companion Specification, die es erlaubt, MTConnect-Modelle in OPC UA abzubilden[FI13]. Somit kann das resultierende Informationsmodell für CNC-WerkzeugmaschinenKonzepte von MTConnect wiederverwenden. Aufgrund von Schriftverkehr mit der UniStuttgart, welche das in Abschnitt 3.3.5 beschriebe Informationsmodell bereitgestellt ha-ben, ging hervor, dass dieses Informationsmodell vollständig im OPC UA Server ange-boten werden sollte. Das bedeutet, dass das Modell nicht mit MTConnect-spezifischenKomponenten erweitert wird, sondern ein überlagertes Informationsmodell erstellt wer-den sollte, welches Referenzen in einen Teil für MTConnect-Komponenten als auch in dasInformationsmodell der VDW erstellt. Durch die zeitliche Begrenzung der Master-Thesiswurde von der Verwendung von MTConnect im Informationsmodell abgesehen.

Für die Eckelmann AG werden Variablen in das Informationsmodell eingeführt, die rudi-mentäre Energie-Überwachung erlauben (siehe Anwendungsfall U3). Geräte, für die ei-ne Energie-Überwachung vorgesehen ist (z.B. Motoren) müssen modelliert werden. DerSchriftverkehr mit der OPC Foundation (Herr Hoppe, siehe Abschnitt 3.2.4) ergab, dassfür die Gerätemodellierung generell OPC UA DI (Abschnitt 3.3.4) verwendet werdensollte. Da man bereits durch den abstrakten Typ DeviceType von OPC UA DI zur Verer-bung gezwungen ist und OPC UA nur einfache Vererbung erlaubt, ist es nicht möglich,von Typen aus dem Informationsmodell der VDW zu vererben.

Das in dieser Arbeit zu entwickelnde Informationsmodell für CNC-Werkzeugmaschinenwird aus diesen Empfehlungen heraus entworfen. Zum Einen leiteten Typen in diesem In-formationsmodell von Typen aus OPC UA DI ab (Gerätemodellierung) und zum anderenwerden Referenzen in das Informationsmodell der VDW hinzugefügt (Abschnitt 3.3.5)(Modellierung der CNC-Datenschnittstelle).

72

Kapitel 3. Analyse 3.4. Zugriff auf CNC-Steuerungen

Die Modellierung des Adressraums soll und kann im UaModeler vorgenommen (Ab-schnitt 3.2.3).

3.4 Zugriff auf CNC-Steuerungen

3.4.1 Überblick

Steuerungen von CNC-Werkzeugmaschinen werden in zwei Kategorien (Abschnitt 2.3)unterteilt:

• Anpasssteuerung (Speicherprogrammierbare Steuerung bzw. SPS), welche Unter-stützungsfunktionen in einer Werkzeugmaschine realisieren. Darunter fällt z.B. dasFreigeben der Motoren nur bei geschlossenen Schutztüren, Auswechseln von Werk-zeugen, Anschalten der Kühlung, usw.

• CNC-Steuerung (Umwandeln der programmierten Bewegungsabläufe in Steue-rungsbefehle)

Die Software für SPS und CNC-Steuerung können sowohl auf dem gleichen Gerät vor-handen sein (z.B. Eckelmann AG) oder auf getrennten Geräten realisiert sein. EinzelneSPS findet man auf Geräten der Siemens AG, die in diesem Segment Marktführer ist. Fürden Programmierer von CNC-Steuerungen ist es in der Regel nicht ersichtlich, ob undwie eine SPS der CNC-Steuerung unterlagert ist.

In diesem Abschnitt werden exemplarisch zwei Arten von CNC-Steuerungszugriffen be-schrieben, die in der Praxis häufiger auftreten. In Abschnitt 3.4.2 werden PLC OPC-UA-Funktionsblöcke vorgestellt und in Abschnitt 3.4.3 Komponenten der Software-PlattformCODESYS vorgestellt. Da der zu entwickelnde Prototyp CNC-Steuerungen der Eckel-mann AG unterstützen muss, wird die Anbindung an diese Steuerungen in Abschnitt 3.4.4analysiert.

3.4.2 PLCopen OPC-UA-Funktionsblöcke

PLCopen ist ein Produkt- und Hersteller-unabhängiger weltweiter Zusammenschlussim Bereich industrieller Steuerungstechnik, der sich für offene Standards einsetzt. DiePLCopen hat ihren Sitz in den Niederlanden und wurde 1992 gegründet. Sie wird durchMitgliedschaften finanziert. Ein Großteil der Aktivitäten von PLCopen fokussiert sich auf

73

3.4. Zugriff auf CNC-Steuerungen Kapitel 3. Analyse

den SPS-Programmierstandard IEC 61131-3. Die folgenden Ergebnisse wurden bisher er-reicht:

• Bibliothek zur Unterstützung von Bewegungsabläufen

• Sicherheitseigenschaften von Steuerungen

• Realisierung von Projektdaten-Austausch über PLCopen XML

• Regeln zur Bestimmung von Kompatibilität zwischen Programmierwerkzeugen

In der Bibliothek für Bewegungsabläufe werden Funktionsblöcke bereitgestellt. DieseBlöcke können in IEC 61131-3 Programmen mit PLCopen-Unterstützung verwendet wer-den. Die Spezifikation der Blöcke wurde im November 2001 veröffentlicht. Das Ziel die-ser Spezifikation ist es, dem Programmierer die Möglichkeit zu geben, Bewegungsabläu-fe zu programmieren, ohne die genaue Architektur und Hardware des Geräts zu kennen,welche diese vollzieht. Dadurch kann das Programm auf verschiedenen Geräten wieder-verwendet werden. Aufgrund von Inkonsistenzen, die bei den ersten Implementierungenauftraten, wurde im April 2005 eine neue Version veröffentlicht, die in 30 verschiede-nen Produkten implementiert wurde. 2007 wurden Korrekturen und Anhänge für dieseVersion für Mitglieder veröffentlicht. Aus diesen Korrekturen und Anhängen entstand dieaktuelle Version 2.0 der Spezifikation.

Die OPC Foundation hat zusammen mit PLCopen Funktionsblöcke veröffentlicht, diees erlauben, OPC-UA-Client-Funktionalität in IEC 61131-3 Programmen zu nutzen, diePLCopen unterstützen. Damit ist man in der Lage, ein Informationsmodell im OPC UAServer direkt aus dem Programm der Steuerung zu befüllen. Das verwendete Informati-onsmodell im OPC UA Server bildet eine einheitliche Sicht auf IEC 61131-3 Programmeund darin verwendete Metadaten (Zyklenzeiten, Ein-/Ausgabeparameter, usw.).

3.4.3 CODESYS

CODESYS [Gmb16b] ist eine Software-Plattform der 3S-Smart Software SolutionsGmbH. Die Plattform stellt Software auf verschiedenen Ebenen bereit. Diese ermöglichtes Anwendern, CNC-Steuerungen auf eine große Anzahl von Geräten zu realisieren. Ab-bildung 3.30 zeigt die verschiedenen Komponenten der Software-Plattform.

Die zwei Hauptkomponenten sind die CODESYS Professional Developer Edition und dieLaufzeit-Komponente CODESYS Control. Die Laufzeit-Komponenten sind käuflich zu

74

Kapitel 3. Analyse 3.4. Zugriff auf CNC-Steuerungen

Abbildung 3.30: Überblick der Komponenten der CODESYS Software-Plattform. Ent-nommen von http://de.codesys.com.

erwerben und stehen unter Lizenzgebühren. CODESYS Control realisiert auf einer Reihevon Geräten ein IEC 61131-3 programmierbaren Controller. Eine Liste der unterstützenGeräte kann auf [Gmb16a] abgerufen werden. Unterstützt werden z.B. auch Desktop-

PCS und Raspberry-PI [Fou16e]. Im Rahmen der Analyse wurde CODESYS auf demRaspberry-PI installiert und eine Beispiel-Anwendung ausgeführt.

In der CODESYS Professional Developer Edition können alle Komponenten verwaltetoder bei Bedarf zusätzliche Komponenten (Plug-Ins) nachinstalliert werden. Mit Hilfeder Developer Edition ist es möglich, IEC 61131-3 Programme zu schreiben und diese aufGeräte zu übertragen und dort auszuführen. Die Programme können mit typischen IDE-Applikationen (Integrated Development Environment), wie z.B. Debugger zur Laufzeitanalysiert werden. SPS-Eigenschaften können konfiguriert werden, dabei ist es ebenfallsmöglich, dass die SPS auf dem Gerät nur emuliert wird und keine Ein- und Ausgängebesitzt.

Eine Plug-In stellt die Komponente SoftMotion da. SoftMotion bietet Programmierbau-steine für IEC 61131, die für komplexe Bewegungsabläufe (CNC) optimiert sind. Der

75

3.4. Zugriff auf CNC-Steuerungen Kapitel 3. Analyse

kompilierte Code wird über die CODESYS Automation Platform-Schnittstelle an das Ge-rät übertragen, welches die Runtime ausführt. Die Oberfläche ist lizenzfrei zum Downloaderhältlich. CODESYS CNC 3D Editor kann genutzt werden, um graphisch Bewegungsab-läufe zu zeichnen und den generierten Code manuell einzusehen und zu verändern.

Zwischen Geräten und Oberfläche existiert ein Gateway, welches verschiedene Geräteverwalten kann. Diese Komponente stellt ebenfalls einen OPC UA Server bereit, der inder Lage ist, verschiedene Daten verschiedener Steuerungen, die in der Developer Edition

freigegeben werden, über den OPC UA Server anzubieten. In einer Standard-Installationist das Gateway auf dem gleichen System installiert wie die Oberfläche. Das Gatewaykommuniziert dann über TCP/IP oder serieller Schnittstelle mit verschiedenen Endgerä-ten.

3.4.4 Treiber für CNC-Steuerungen der Eckelmann AG

Die Eckelmann AG stellt für den Zugriff auf ihre CNC-Steuerungen einen Treiber bereit.Dieser wird in einer Shared Library (DLL) in einer Microsoft Windows ® Umgebungangeboten. Ein PDF-Dokument dokumentiert Parameter und Verhalten der angebotenenTreiber-Funktionen. Dabei werden zwei verschiedene Schnittstellen angeboten:

• Zugriff auf das Gateway

• Zugriff auf die CNC-Steuerung selbst

Das Gateway bietet die Möglichkeit, verschiedene CNC-Steuerungen zu verwalten. MitHilfe des Treibers können im Gateway verschiedene Trace-Elemente ausgewählt werden,die die Zugriffe auf eine CNC-Steuerung aufzeichnen. Weiterhin können auf dem Gate-way sämtliche CNC-Verbindungen mit einem Aufruf geschlossen werden. Die Verwen-dung des Gateways ist optional. Die Treiber-Funktionen für den Zugriff auf eine CNC-Steuerung können wie folgt gruppiert werden:

(De-)Initialisierung Verbindungsaufbau und Abbau zu der CNC-Steuerung, sowie La-den der Firmware.

Transfers Synchrone- und asynchrone Aufrufe zum Starten eines Transfers zu oder voneiner CNC-Steuerung.

Parameter Einlesen und Schreiben von Parametern der CNC-Steuerung (im weiterenVerlauf genauer beschrieben).

76

Kapitel 3. Analyse 3.4. Zugriff auf CNC-Steuerungen

Nachrichten Synchrones und asynchrones Senden von Nachrichten zur CNC-Steuerung.

Ausdrücke Auswerten von Echtzeit-Ausdrücken auf der Steuerung (z.B. Funktionen, dieG-Code benutzen).

CAN-Transfers Funktionen für das Starten von Transfers mit CAN-Objekten.

Für den weiteren Verlauf der Analyse werden Funktionen für CAN-Transfers und Aus-drücke nicht betrachtet, da sie für das Auslesen von Eigenschaften der CNC-Steuerungund den laufenden Programmen nicht von Bedeutung sind.

CNC-Steuerungen der Eckelmann AG besitzen Parameter-Felder. Diese Felder sind Spei-cherplätze, die sowohl in CNC-Programmen beschrieben als auch vom Treiber eingelesenund verändert werden können. Sie sind Grundlage für das Beschaffen von Informationenzur Laufzeit der Steuerung. Die Art der Informationen ist in drei Kategorien unterteilt:

Interne Daten des NC-Rechners Daten, die durch Programme erzeugt werden oder Zu-stände des NC-Rechners wiedergeben. Diese Daten stehen nur für Lesezugriffe zurVerfügung.

Daten für Zyklen und Makros Daten, die vom NC-Rechner an Zyklen übergeben wer-den. Zyklen und Makros haben sowohl Lese- als auch Schreibzugriff auf die Daten.Anwenderprogramme sollen nur lesend auf diese Daten zugreifen.

Daten für Anwenderprogramme Frei verwendbare Daten für Anwenderprogramme,die sowohl gelesen als auch geschrieben werden können.

Parameter-Felder sind indiziert und werden je nach Index-Bereich in verschiedene Berei-che gruppiert.

0-1023 Interne Daten des NC-Rechners

1024-1499 Daten für Zyklen

1500-47952 Anwenderdaten

50000-65535 Erweitertes P-Feld (ebenfalls im internen Speicher des NC-Rechners hin-terlegt)

Im internen Speicher des NC-Rechners (Felder 0 - 1023 und 50000 - 65535) befinden sichfolgende Parameter:

77

3.4. Zugriff auf CNC-Steuerungen Kapitel 3. Analyse

Achsspezifische Parameter Positionen, Offsets, Geschwindigkeitsvorgaben, Spindel-drehzahlen

Parameter zur Programmverwaltung Programm- und Satznummern, Informationenzum Satzvorlauf, Kanal-spezifische Override-Werte, Schrittweitvorgabe

Technologiespezifische Parameter Winkel-Einstellungen, Informationen zu Gewinden,Werkzeug- und Technologiedaten

Parameter zur Zeiterfassung Fahr-, Verweil- und Laufzeiten

Kanalanzeige Aktuelle Satz- und Programmnummer, Werkzeug- und Werkstückkoordi-natensysteme, Bahngeschwindigkeit, Bearbeitungszustand des Kanlals, Schrittwei-te, Interpreterzustand, Aktive modale

Im Zykelnspeicher (Felder 1024 - 1499) stehen folgende Parameter zur Verfügung:

Technologiespezifische Anwenderparameter Informationen bezüglich Anwender-daten, z.B. beim Nähen, Schneiden von Stoffen oder Styropor

Die Initialisierungsfunktion liefert ein Handle zurück, welches für alle weiteren Funk-tionsaufrufe als erster Parameter benötigt wird. Im Gateway kann ein Name für eineCNC-Steuerung vergeben werden. Dieser Name ist dann an die IP-Adresse der Steuerunggebunden. Weiterhin kann im Gateway eine Steuerung als Standard-Steuerung definiertwerden. Eine Verbindung kann entweder zu der Standard-Steuerung oder zu einer CNC-Steuerung mit Hilfe des Namens aufgebaut werden. Ist die Firmware der Steuerung nochnicht geladen, so muss dies als erstes geschehen. Danach können verschiedene Dateienan die Steuerung übertragen werden, die für das Abarbeiten eines Programms notwendigsind. Darunter fallen z.B. Dateien, die Maschinenkonstanten und Achsenkonfigurationdefinieren.

Die Eckelmann AG stellt weiterhin ein Standard HMI (Human Machine Interface) bereit,um graphisch die Steuerung zu administrieren. Beim Starten des HMI wird die Firmwa-re auf das Gerät geladen und das Gerät initialisiert. Deshalb ist es nicht notwendig, dieSteuerung zu initialisieren, wenn die CNC-Steuerung bereits mit dem HMI administriertwird.

Nach erfolgreichem Verbindungsaufbau wird ein registriertes Callback aufgerufen. Die-ses Callback signalisiert Fortschritte bei synchronen Transfers oder asynchrone Fehler-Nachrichten von der CNC-Steuerung. Für die Übermittlung von Nachrichten wird im

78

Kapitel 3. Analyse 3.4. Zugriff auf CNC-Steuerungen

Treiber die Struktur MSG_TR genutzt. Darin werden drei Steuerblöcke hinterlegt (sb0_uc,sb1_uc und sb2_uc). Je nach Steuerblock 0 können verschiedene Steuerblöcke 1 und2 genutzt werden. Die Steuerblöcke werden in der Header-Datei com_sbx.h des Trei-bers definiert. Bei Fehler-Nachrichten ist der Steuerblock 0 SB0_EXCEPTION_KUC

und der Steuerblock 1 kann die Werte SB1_FEHLERNUMMER_KUC (Fehlermeldungan den Treiber), SB1_FEHLERQUITTUNG_KUC (Fehlerquittierung vom Treiber) oderSB1_FEHLERQUITTUNG_ALLE_KUC (Fehlerquittierung aller Fehler vom Treiber) an-nehmen.

3.4.5 Designentscheidungen

Die CODESYS Software Platform hat eine hohe Verbreitung am Markt. Laut Webseitedes Herstellers wird die Runtime-Komponente auf über 1000 unterschiedlichen Gerätenweltweit genutzt. Da die CNC-Steuerung vollständig in der Komponente SoftMotion reali-siert wird und als IEC 61131-3 Programm auf der Runtime-Komponente ausgeführt wird,hätte analysiert werden müssen, welche CNC-Steuerungsdaten auf die Runtime übertra-gen werden und wie diese dort abgerufen werden können. Da der Prototyp auf CNC-Steuerung der Eckelmann AG zugreift wird sich auf die Treiberanbindung der EckelmannAG fokussiert.

Folgende Vorteile würde die Verwendung von CODESYS bieten:

• Verwendbarkeit des hier entwickelnden Prototyps für viele Hersteller von CNC-Steuerungen.

• Evaluierung des Prototyps auf verschiedenen Plattformen, für die CODESYS Run-time Components existieren.

• API für den Zugriff auf Runtime-Komponenten [Gmb16d]. Diese API ist jedochnicht frei verfügbar und muss für eine Lizenzgebühr erkauft werden.

Durch das Abrufen der Daten in den P-Feldern von CNC-Steuerungen der Eckelmann AGist es möglich einen Teil der Informationen zu erhalten, die in OPC UA CNC (Abschnitt3.3.5) modelliert werden können. Fehlende Informationen werden nicht beachtet und ha-ben im Informationsmodell Standard-Werte, die sich im Betrieb der CNC-Steuerung nichtverändern. Da sich die Informationsart der P-Felder-Indizes mit der Zeit ändern (Versio-nierung des Eckelmann-Treibers), wird eine Konfigurationsdatei bereitgestellt, in der dieP-Feld-Indizes hinterlegt werden können. Dadurch kann die Eckelmann AG die Indizesändern ohne den Zugriffscode für die CNC-Steuerung neu zu kompilieren.

79

3.4. Zugriff auf CNC-Steuerungen Kapitel 3. Analyse

80

Kapitel 4

Design

In diesem Kapitel wird ein Konzept entwickelt, um existierende Werkzeugmaschinenzu vernetzen und in einen Industrie-4.0-Kontext zu integrieren. Anhand von UML-Diagrammen werden die Grob- und die Feinarchitektur modelliert. Ausschlaggebend fürdas Konzept sind die Designentscheidungen aus den Analyseabschnitten 3.2.4, 3.3.6 und3.4.5.

4.1 Gesamtarchitektur

Abbildung 4.1: Gesamtarchitektur

81

4.2. Informationsmodell für CNC-Werkzeugmaschinen Kapitel 4. Design

In Abbildung 4.1 wird das Komponentendiagramm für die Gesamtarchitektur aufgezeigt.Gelb gefüllte Kästchen sind bereits vorhandene Komponenten, während blau gefüllteKästchen in dieser Arbeit entwickelt werden müssen.

Der OPC UA Server basiert auf dem Unified Automation C++ Server (siehe 3.2.2). Diesgeht aus den Designentscheidungen in 3.2.4 hervor. Damit der OPC UA Server das In-formationsmodell unterstützt, muss dieses eingebettet und evtl. angepasst werden. DerUaModeler (siehe 3.2.3) kann mit Hilfe eines GUI C++-Code generieren. Dieser Codewird verwendet, um das Informationsmodell in den OPC UA Server einzubinden.

Es wird ein Informationsmodell für CNC-Werkzeugmaschinen entwickelt (siehe 3.3.6),welches mit Unified Automation Modeler erstellt und vom Unified Automation C++ Ser-ver eingelesen wird.

Um zur Laufzeit Daten von der CNC-Steuerung einer CNC-Werkzeugmaschine zu er-fassen und diese dann in das Informationsmodell zu exportieren (siehe 3.4.5), wird eineAdapterkomponente entworfen. Für den Adapter wird eine Konfiguration bereitgestellt,so dass der Adapter in der Lage ist zu erkennen, welche spezifischen CNC-Daten derCNC-Steuerung an welche Position im Informationsmodell zu exportieren sind.

4.2 Informationsmodell für CNC-Werkzeugmaschinen

4.2.1 Überblick und Notation

Die Anforderungen A1 und A2 (siehe 3.1) aus dem Anwendungsfall U1 zeigen, dass einInformationsmodell für CNC-Werkzeugmaschinen und Daten einer CNC-Steuerung be-nötigt werden. Das Informationsmodell wird in Komponenten aufgeteilt, die in diesemAbschnitt beschrieben werden. Abbildung 4.2 zeigt die verwendeten Komponenten imInformationsmodell. Die Bausteine für das Informationsmodell stammen aus dem OPCUA Basis-Datenmodell (2.2.3), OPC UA DI (3.3.4) und OPC UA CNC (3.3.5). Für dieVerfeinerung des Modells dienen die Grundlagen von CNC-Werkzeugmaschinen (2.3),und eine exemplarische CNC-Werkzeugmaschine der Eckelmann AG. Bei der Entwick-lung dieses Informationsmodells muss berücksichtigt werden, dass OPC UA DI und OPCUA CNC vollständig im OPC UA Server genutzt werden können. Dies hat zur Folge, dassbeide Informationsmodelle miteinander verbunden werden müssen.

Damit es keine Namenskonflikte im OPC UA Adressraum gibt, müssen Namensräumevergeben werden. Vorhandene Companion Specifications legen Namensräume für Na-men fest, die in den Spezifikationen eingeführt werden. Für Namen, die in dieser Arbeit

82

Kapitel 4. Design 4.2. Informationsmodell für CNC-Werkzeugmaschinen

Abbildung 4.2: Überblick der verwendeten Komponenten im Informationsmodell

Namensraum Beschreibunghttp://opcfoundation.org/UA/ OPC UA Basis-Datenmodellhttp://opcfoundation.org/UA/CNC/ OPC UA Information Model for CNC

Systems (OPC UA CNC)http://opcfoundation.org/UA/DI/ OPC Unified Architecture for Devices

(OPC UA DI)http://cs.hs-rm.de/mierswa_thesis/CNC Namensraum für hier eingeführte Ty-

pen, die nicht herstellerspezifisch sindhttp://cs.hs-rm.de/mierswa_thesis/eckelmann Namensraum für spezifische Typen,

die für CNC-Systeme der EckelmannAG eingeführt werden

definiert werden, muss ebenfalls ein Namensraum gewählt werden. Tabelle 4.2.1 zeigt dieverwendeten Namensräume, für Basis-Komponenten wie auch hier eingeführte Kompo-nenten, an. Die Namensräume für das Basis-Datenmodel (siehe 2.2.3), OPC UA DI undOPC UA CNC sind im Standard bzw. in den Companion Specifications vorgegeben. Dielokalen Namensräume (Typen, die im Rahmen der Thesis eingeführt werden) verwendenfür den URI den Präfix http://cs.hs-rm.de/mierswa_thesis.

Während in den Kapiteln Grundlagen und Analyse die grafische Notation der OPC-UA-Spezifikation und der Companion Specifications genutzt wird, werden die nun folgendenTypen in UML-Klassendiagrammen modelliert. Dabei gilt zu beachten, dass Attributenicht in allen Fällen eine Eltern-Kind-Beziehung mit der Klasse haben (HasChild Re-ferenz). Attribute können ebenfalls als OPC-UA-Referenz auf andere Objekte realisiert

83

4.2. Informationsmodell für CNC-Werkzeugmaschinen Kapitel 4. Design

werden. Die Beschreibung der Attribute befindet sich im Text. Ist im UML-Diagrammkeine Assoziation zu anderen Klassen sichtbar, so hat das Attribut einen primitiven Da-tentypen im OPC-UA-Basis-Datenmodell (z.B. Double oder String). Diese Datentypensind in Abbildung 2.4 dargestellt. Attribute mit nicht-primitiven Datentypen werden stetsüber eine HasComponent OPC-UA-Referenz realisiert und stehen somit immer in einerEltern-Kind-Beziehung mit der Elternklasse, da HasComponent von HasChild ableitet(siehe Abbildung 2.5).

Das UML-Klassendiagramm beschreibt keine TypeDefinition und NodeClass der Knoten.Diese Information muss dem Text entnommen werden. Der Name eines Attributs ent-spricht dem BrowseName im OPC-UA-Adressraum. Ist der Name in <...> eingeschlos-sen, so bedeutet dies, dass eine Referenz auf ein Objekt eingefügt wird, dessen Namebei der Instanzierung beliebig gewählt werden kann. Wird im Text keine Auskunft überdie ModellingRule gegeben, so ist dies standardmäßig ModellingRule Mandatory. Dieverschiedenen Typen der Knoten (NodeClass) werden im Abschnitt 2.2.3 des KapitelGrundlagen aufgezeigt. In diesem Informationsmodell werden ausschließlich die Kno-tentypen Object und Variable genutzt. Methodenaufrufe im Informationsmodell werdennicht benötigt.

4.2.2 Resultierendes Informationsmodell

Alle eingeführten Typen, die von DeviceType aus OPC UA DI ableiten, besitzen imNamen den Suffix DeviceType. Die übergeordnete Modellierungskomponente für CNC-Werkzeugmaschinen wird mit dem Typ CNCMachineDeviceType bereitgestellt. Abbil-

Abbildung 4.3: CNCMachineDeviceType-Klasse für CNC-Werkzeugmaschinen

dung 4.3 zeigt das Klassendiagramm für CNCMachineDeviceType. Der Typ leitet vom

84

Kapitel 4. Design 4.2. Informationsmodell für CNC-Werkzeugmaschinen

abstrakten Typ DeviceType aus OPC UA DI ab, womit die Verbindung zu OPC UA DIhergestellt wird. Folgende Attribute und Referenzen werden hinzugefügt:

<CncInterface> Für das Informationsmodell aus OPC UA CNC muss ein ObjektCncInterface vom entsprechenden Typ CncInterfaceType instanziiert werden. DerOrt, an dem das Objekt instanziiert wird, ist von der Companion Specification nichtvorgeschrieben. Damit es möglich ist, zu diesem Objekt aus dieser Klasse zu navi-gieren, wird eine OPC-UA-Referenz (Organizes) hinzugefügt. Die TypeDefinitiondes Knotens ist CncInterfaceType und die NodeClass Object.

Channels Ein Verzeichnis, welches alle Instanzen der Klasse CNCChannelType (nichtCncChannelType von OPC UA CNC) sammelt. Obwohl in OPC UA CNC be-reits eine Modellierung für CNC-Kanäle vorgesehen ist, müssen eigene Klassenfür CNC-Kanäle eingeführt werden, da diese zusätzliche Attribute enthalten (z.B.Referenzen zu Werkzeugträgern), die in OPC UA CNC nicht vorhanden sind. DieKlasse CNCChannelType wird in diesem Abschnitt beschrieben. Die TypeDefiniti-on des Knotens ist FolderType und die NodeClass Object.

Durch OPC UA DI wird in Objekten dieser Klasse ein Verzeichnis SubDevices hinzuge-fügt. In diesem Verzeichnis befinden sich alle Untergeräte, die vom TypCNCDriveComponentDeviceType abgeleitet wurden. Damit herstellerspezifische Infor-mationen hinzugefügt werden können, kann von CNCMachineDeviceType abgeleitet wer-den.

Abbildung 4.4: CNCDriveComponentDeviceType-Klasse für physikalische Komponen-ten von CNC-Werkzeugmaschinen

Abbildung 4.4 zeigt das Klassendiagramm für CNCDriveComponentDeviceType. Der Typleitet vom abstrakten Typ DeviceType aus OPC UA DI ab, womit die Verbindung zu OPC

85

4.2. Informationsmodell für CNC-Werkzeugmaschinen Kapitel 4. Design

UA DI hergestellt wird. Diese Komponenten können nun als Module in SupportedTypes

(dynamische Instanzierung) und SubDevices (statische Instanzierung) für das Top DeviceCNCMachineDeviceType (siehe Abschnitt 3.3.4) verwendet werden. Es besitzt folgendeAttribute:

BelongingDrives Ein Verzeichnis, welches alle Instanzen sammelt, deren Klasse vonCncDriveType (z.B. Achsen und Spindeln) aus OPC UA CNC ableitet. Damit wirdeine Verbindung von physikalischen Geräten, z.B. Motoren und Getrieben, zu denCNC-Komponenten, wie z.B. Achsen und Spindeln, hergestellt. Die TypeDefinitiondes Knotens ist FolderType und die NodeClass Object.

BelongingChannels Ein Verzeichnis, welches alle Instanzen sammelt, deren Klasse vonCNCChannelType (nicht CncChannelType aus OPC UA CNC) ableitet. Damit wirdeine Verbindung von physikalischen Geräten zu den dazugehörigen CNC-Kanälenhergestellt. Der Typ CNCChannelType wird im Verlauf dieses Abschnitts beschrie-ben. Die TypeDefinition des Knotens ist FolderType und die NodeClass Object.

Für herstellerspezifische Informationen muss von CNCDriveComponentDeviceType ab-geleitet werden.

Um Werkzeugvorrichtungen (z.B. Bohrköpfe, Schneidköpfe, usw.) zu modellieren, wirdein neuer Typ CNCToolCarrierType eingeführt. Da es sich dabei nicht um ein physika-lisches Gerät handelt, leitet es nicht von DeviceType aus OPC UA DI ab, sondern vonBaseObjectType aus dem OPC UA Basis-Datenmodell. Exemplarisch wird in Abbildung4.5 der Typ CNCPlasmaCutType modelliert, welcher Träger für Plasma-Schneidköpfe re-präsentiert. Darin werden folgende Attribute hinzugefügt:

LoadPercentage Ein Double-Datum (Festkommazahl), das den Lastanteil in Bezug aufdie Maximalleistung repräsentiert. Die TypeDefinition des Knotens istAnalogItemType und die NodeClass Variable. Die entsprechende Einheit ist % (Pro-zent) und der Wertebereich wird auf 0 - 100 festgelegt.

Power Ein Double-Datum, das die momentane Leistung angibt. Die TypeDefinition desKnotens ist AnalogItemType und die NodeClass Variable. Die entsprechende Ein-heit ist W (Watt) und der Wertebereich wird auf 0 - 100000 festgelegt.

CoolingActive Ein Boolean-Datum, welches angibt, ob die Kühlung gerade aktiv ist. DieTypeDefinition ist DataItemType und die NodeClass Variable.

86

Kapitel 4. Design 4.2. Informationsmodell für CNC-Werkzeugmaschinen

Abbildung 4.5: Klassen für CNC-Kanäle und Werkzeugträger

Temperature Ein Double-Datum, in dem die Temperatur am Kopf des Werkzeugs fest-gehalten wird. Die TypeDefinition ist AnalogItemType und die NodeClass Variable.Ddie entsprechende Einheit ist °C (Grad Celsius) und der Wertebereich wird auf 0- 6000 festgelegt.

Desweiteren zeigt Abbildung 4.5 den Typ CNCChannelType, welcher CncChannelType

aus OPC UA CNC und CNCToolCarrierType referenziert. Damit wird zum einen eineVerbindung zu OPC UA CNC hergestellt und zu dem Werkzeugträger, der nicht in OPCUA CNC oder OPC UA DI direkt modelliert wird. Darin werden folgende Attribute hin-zugefügt:

<CncChannel> Eine Organizes OPC UA Referenz zum CNC-Kanal, welcher mit OPCUA CNC modelliert wird.

<ToolCarrier> Eine HasComponent OPC UA Referenz zu einem Werkzeugträger. DasObjekt wird von einem Typ instanziiert, der von CNCToolCarrierType ableitet.Der Name des Attributs wird durch den Namen des CNCToolCarrier-Objekts er-setzt. Die TypeDefinition des Knotens ist CNCToolCarrierType und die NodeClassObject. Das Modellierung des Werkzeugträgers in diesem Kanal ist notwendig, so-mit ist die ModellingRule des Knotens MandatoryPlaceholder.

87

4.2. Informationsmodell für CNC-Werkzeugmaschinen Kapitel 4. Design

4.2.3 Herstellerspezifische Erweiterungen

Der Anwendungsfall U3 (siehe 3.1) zeigt, dass herstellerspezifische Erweiterungen amInformationsmodell hinzugefügt werden müssen. Das entwickelte Informationsmodellbietet durch das objektorientierte OPC UA verschiedene Erweiterungsmöglichkeiten Indiesem Informationsmodell werden herstellerspezifische Informationen für Geräte durchAbleitungen und CNC-Komponenten durch Referenzen eingeführt (siehe 3.3.6). Exem-plarisch werden für die Eckelmann AG zusätzliche Modellierungskomponenten hinzu-gefügt. Im folgenden wird gezeigt, wie herstellerspezifische Informationen zu physika-lischen Geräten hinzugefügt werden können. Für hier eingeführte Typen wird der PräfixEckelmann benutzt.

Abbildung 4.6: Eckelmann-spezifische CNC-Komponenten

Abbildung 4.6 zeigt das Klassendiagramm für Eckelmann-spezifische CNC-Komponen-ten. Darin wird die Klasse EckelmannCNCInterfaceType eingeführt, die vonBaseObjectType ableitet. Im resultierenden Informationsmodell werden keine Zusatz-informationen für die CNC-Schnittstelle benötigt. Aus diesem Grund wird kein ei-gener Typ für eine CNC-Schnittstelle eingeführt. Dem Typen muss eine Referenzzum OPC UA CNC Informationsmodell hinzugefügt werden. Die Basisklasse vonEckelmannCNCChannelType ist CNCChannelType, da im resultierenden Informations-modell ein Typ eingeführt wurde, der Referenzen zu CNC-Kanälen im OPC UA CNCInformationsmodell enthält.

Der Klasse EckelmannCNCChannelType wird folgendes Attribut hinzugefügt:

ToolDescription Ein String-Datum, welches das Werkzeug am Kanal näher beschreibt.Die TypeDefinition des Knotens ist DataItemType und die NodeClass Variable.

Der Klasse EckelmannCNCInterfaceType wird folgendes Attribut hinzugefügt:

88

Kapitel 4. Design 4.2. Informationsmodell für CNC-Werkzeugmaschinen

Channels Dieses Attribut ist ein Verzeichnis, welches alle Objekte enthält, die vonEckelmannCNCChannelType instanziiert wurden. Dies folgt aus dem Modellie-rungskonzept von OPC UA CNC, welches alle Kanäle in der CNC-Schnittstelleauflistet. Die TypeDefinition des Knotens ist FolderType und die NodeClass Object.

<CncInterface> Organizes OPC UA Referenz zu dem CncInterface-Objekt, welches dasOPC UA CNC Informationsmodell anbietet. Die TypeDefinition des Knotens istCncInterfaceType und die NodeClass Object.

Abbildung 4.7: Eckelmann-spezische physikalische Geräte

Abbildung 4.7 zeigt das Klassendiagramm für Eckelmann-spezifische physikalische Ge-räte. Die folgenden Attribute werden EckelmannCNCDriveComponentDeviceType hinzu-gefügt:

Lifetime Ein vorzeichenloses 32-Bit-Integer-Datum, welches die Zeit in Sekunden an-gibt, die seit dem Einbau des Geräts vergangen ist. Die TypeDefinition des Knotensist AnalogItemType und die NodeClass Variable. Die entsprechende Einheit ist s

(Sekunde) und der Wertebereich wird auf 0 - 3154000000 (100 Jahre) festgelegt.

Wearing Eine Enumeration, die den Abnutzungsgrad des Geräts angibt. Da die Klassevon CNCDriveComponentDeviceType und somit von DeviceType ableitet, ist eineähnliche Information bereits im DeviceHealth-Attribut vorhanden. Hier wird zu-sätzlich eine fein-granulare Abstufung der Abnutzung angegeben.Der Aufzählungstyp EckelmannWearingStatus kann folgende Werte annehmen:

89

4.2. Informationsmodell für CNC-Werkzeugmaschinen Kapitel 4. Design

New Keine Abnutzung (kaum genutzt bzw. neues Gerät).

MildlyUsed Leichte Abnutzung.

Used Mittelmäßige Abnutzung.

HeavilyUsed Starke Abnutzung.

NeedsReplacement Die Abnutzung ist so weit fortgeschritten, dass das Ge-rät demnächst ausgewechselt werden muss.

Die TypeDefinition des Knotens ist DataItemType und die NodeClass Variable.

EnergyConsumed Ein Double-Datum, welches die verwendete Energie seit Start desOPC UA Servers angibt. Die TypeDefinition des Knotens ist AnalogItemType unddie NodeClass Variable. Die entsprechende Einheit ist Wh (Wattstunde) und derWertebereich wird auf 0 - 100000000000 (100 GWh) festgelegt. Dabei gilt zu be-achten, dass OPC UA das Format IEEE-754-1985 [IEE85] für den Datentyp Double

benutzt. Ab einem Wert von 8388608 ist die nächste Zahl nur noch in einem Ab-stand von 1 darstellbar. Daher muss ab diesem Wert eine andere Einheit verwendetwerden (z.B. Kilowattstunde, kWh), um die Nachkommastellen nutzen zu können.

Power Ein Double-Datum, welches die momentate Leistung angibt. Die TypeDefinitiondes Knotens ist AnalogItemType und die NodeClass Variable. Die entsprechendeEinheit ist W (Watt) und der Wertebereich wird auf 0 - 100000 festgelegt.

EMBelongingChannels Ein Verzeichnis, welches Objekte sammelt, deren KlassenEckelmannCNCChannelType sind. Während im BelongingChannels-Attribut derCNCDriveComponentDeviceType-Klasse nur Kanäle vom TypCNCChannelType gesammelt werden, können hier abgeleitete Kanaltypen mit her-stellerspezifischen Informationen gesammelt werden. Die TypeDefinition des Kno-tens ist FolderType und die NodeClass Object.

Die folgenden Attribute werden EckelmannCNCMachineDeviceType hinzugefügt:

<EMCncInterface> Referenziert ein Objekt (HasComponent), welches vom TypenEckelmannCNCInterfaceType instanziiert wird. Während im <CncInterface>-Attribut der CNCMachineDeviceType-Klasse nur ein Objekt von CncInterfaceType

erlaubt ist, kann hier ein herstellerspezifisches CNC-Interface referenziert werden.Die TypeDefinition des Knotens ist EckelmannCNCInterfaceType und die Node-Class Object. Da die CNC-Schnittstelle des Herstellers als Kind-Element in Objek-ten dieser Klasse instanziiert wird, ist die ModellingRule MandatoryPlaceholder.

90

Kapitel 4. Design 4.2. Informationsmodell für CNC-Werkzeugmaschinen

Der Name des Attributs wird durch den Namen des EckelmannCNCInterfaceType-Objekts ersetzt.

4.2.4 Beispiel-Instanz des Informationsmodells für eine 3-Achsen-Plasma-Schneidmaschine

Anhand der Klassendiagramme wird nun exemplarisch für eine 3-Achsen-Plasma-Schneidmaschine ein Objektdiagramm aufgeführt. Durch die Instanzierung der Klassenverändern sich die Namen (BrowseNames) der <...>-Attribute. Im folgenden wird ausPlatzgründen für die Struktur ab den Einstiegspunkten CncInterface (OPC UA CNC) undDeviceSet (OPC UA DI) zwei verschiedene Abbildungen gezeigt. Das Objektdiagrammin Abbildung 4.8 zeigt die Eintrittspunkte Server, DeviceSet und CncInterface unter demSammel-Verzeichnis Objects im OPC UA Server. Das Verzeichnis Objects und der Ein-stiegspunkt Server werden vom OPC UA Standard vorgeschrieben. Der EinstiegspunktServer enthält vom Server generierte Informationen, z.B. Namensräume, Versionen, usw.DeviceSet ist der Einstiegspunkt für Geräte, die mit OPC UA DI modelliert werden. DieObjektstruktur unter DeviceSet wird in der nächsten Abbildung dargestellt. Das ObjektCncInterface vom Typen CncInterfaceType ist der Einstiegspunkt in das Informations-modell OPC UA CNC. Die Objektstruktur wird durch die Companion Specification inAbschnitt 3.3.5 vorgeschrieben.

Im Objektdiagramm werden die Attribute der Objekte dargestellt. Leere Attribute (z.B.ActChannel) sind komplexe Attribute, die im folgenden Text beschrieben werden. Da-tentypen, die als TypeDefinition AnalogItemType referenzieren, besitzen einen Wertebe-reich und eine Einheit. Diese können aus den Analyseabschnitten 3.3.5, 3.3.4 und denDesignabschnitten 4.2.2 und 4.2.3 entnommen werden. Ist die TypeDefinition eines Da-tums DataItemType, so ist dies ein primitiver Datentyp ohne Einheit.

Die Attribute CmdFeedrate und CmdOverride besitzen keinen Wert, da diese Variablen imOPC UA Server für Schreibbefehle genutzt werden (Command). Das Attribut ActChannel

der Objekte X, Y und Z besitzt als Wert die NodeId des Kanalobjekts Channel1. Diese Idwird zum Zeitpunkt der Modellierung festgelegt.

Die Referenzen im OPC UA Server werden als Pfeile im Objektdiagramm dargestellt.Diese Art der Darstellung weicht vom UML-Standard ab, wird aber benötigt, um dieRichtung der Referenz darzustellen. Vom Verzeichnis Objects existieren drei Organizes

Referenzen zu den Einstiegspunkten Server, DeviceSet und CncInterface. Das Ob-jekt CncAxisList besitzt drei HasComponent Referenzen zu den Achsen-Objekten X, Y

91

4.2. Informationsmodell für CNC-Werkzeugmaschinen Kapitel 4. Design

Abbildung 4.8: Objektdiagramm für die CNC-Schnittstelle am Beispiel Eckelmann

und Z. Das verwaltende CncAxisList steht also mit den drei Achsen-Objekten in einerEltern-Kind-Beziehung. Kanäle (Channel1) werden ebenfalls mit dem verwaltenden Ob-jekt CncChannelList in eine Eltern-Kind-Beziehung verwaltet. Zusätzlich existieren dreiOrganizes Referenzen von dem verwaltenden Kanal (Channel1) zu den zugehörigen Ach-sen (X, Y und Z).

Das Objektdiagramm in Abbildung 4.9 zeigt die Eintrittspunkte Server, DeviceSet undCncInterface unter dem Sammel-Verzeichnis Objects im OPC UA Server. Dies ist iden-tisch mit den Einstiegspunkten Abbildung 4.9, allerdings wird hier nur der Knoten

92

Kapitel 4. Design 4.2. Informationsmodell für CNC-Werkzeugmaschinen

Abbildung 4.9: Objektdiagramm für Geräte am Beispiel Eckelmann

DeviceSet beschrieben.

Wie in diesem Diagramm ersichtlich, überwiegt die Anzahl der Referenzen die Anzahlder eigentlichen Objekte. Der Grund für die Vielzahl von Referenzen ist die Naviga-tionsmöglichkeit zu den einzelnen Informationsmodellen aus OPC UA CNC und OPCUA DI. Unter dem Objekt DeviceSet befinden sich alle Geräte, die mit OPC UA DImodelliert wurden. Das Top Device ist das Objekt EckelmannPlasmaSchneidmaschine

vom Typ EckelmannCNCMachineDeviceType. Der Suffix DeviceType zeigt, dass dieKlasse des Objekts von DeviceType aus OPC UA DI ableitet. Es besitzt die Attri-bute eines Objekts der Klasse DeviceType, wie sie in Abschnitt 3.3.4 beschriebensind. Die aus dem Objekt ausgehenden Pfeile (untere Kante) sind Referenzen auf an-dere Objekte. Das Top Device besitzt zwei HasComponent Referenzen auf die Ob-jekte Channels und EMCncInterface und eine Organizes Referenz auf das Verzeich-

93

4.2. Informationsmodell für CNC-Werkzeugmaschinen Kapitel 4. Design

nis SubDevices aus OPC UA DI, wie es in OPC UA DI vorgeschrieben ist. DasObjekt EMCncInterface vom Typ EckelmannCNCInterfaceType und das VerzeichnisChannels in EckelmannPlasmaSchneidmaschine besitzen eine HasComponent Referenzauf den CNC-Kanal EMChannel1 vom Typ EckelmannCNCChannelType. Dieser Ka-nal hat nur ein Attribut, der das Werkzeug beschreibt, welches diesem Kanal zuge-wiesen ist. Es referenziert das Objekt PlasmaCutter der Klasse CNCPlasmaCutType,um spezifische Eigenschaften der Anwendung des Kanals zu beschreiben. Damit ei-ne Navigation zum Informationsmodell aus OPC UA CNC möglich ist, wird demObjekt EMCncInterface eine Referenz zum Objekt CncInterface (Abbildung 4.8) undChannel1 (Abbildung 4.8) hinzugefügt. Beide Referenzen sind vom Typ Organizes. FürUntergeräte des Top Devices wird das Verzeichnis SubDevices von OPC UA DI be-reitgestellt. Darin werden nun alle Geräte modelliert, die für das Energie-Monitoringfür die Eckelmann AG notwendig sind. In diesem Prototyp wird ein Motor model-liert, der zu einer Achse gehört. Dieser Motor ist im Informationsmodell unter demNamen EckelmannMotor1 modelliert. Das Objekt besitzt die grundlegenden Attributefür ein DeviceType aus OPC UA DI und zusätzlich die Energie-Monitoring-AttributeEnergyConsumed, Lifetime, Power und Wearing. Diese Attribute sind in Abschnitt4.2.3 beschrieben. Ausgehend von diesem Objekt (untere Kante) gibt es drei Refe-renzen (HasComponent) zu Verzeichnissen. Das Verzeichnis BelongingChannels wirdvon dem abgeleiteten Typ CNCDriveComponentDeviceType eingeführt. Das VerzeichnisEMBelongingChannels wird vom Typ EckelmannCNCDriveComponentDeviceType ein-geführt. Beide Verzeichnisse referenzieren (Organizes) das Kanal-Objekt EMChannel1.Der Grund für die doppelte Referenzierung ist, dass der abgeleitete Typ nur Objekte vomTyp CNCChannelType referenzieren darf und der TypEckelmannCNCDriveComponentDeviceType nur Objekte vom TypEckelmannCNCChannelType referenzieren darf. Da aber EckelmannCNCChannelType

von CNCChannelType ableiten darf, entsteht eine doppelte Referenzierung. Das Verzeich-nis BelongingDrives wird vom abgeleiteten Typ CNCDriveComponentDeviceType einge-führt und referenziert die eigentliche Achse oder Spindel im Informationsmodell OPCUA CNC.

94

Kapitel 4. Design 4.3. Adapter

4.3 Adapter

4.3.1 Überblick

Der Adapter muss in der Lage sein auf CNC-Steuerungen zuzugreifen (siehe 3.4) underfüllt zwei Funktionen (siehe Abbildung 4.1):

• Datenerhebung

• Generische Schnittstelle für OPC UA Server zum Befüllen des Adressraums

Die Datenerhebung findet an der CNC-Steuerung statt. Deshalb muss der Adapter fürdie Entwicklung des Prototyps in der Lage sein, das Protokoll für CNC-Steuerungen derEckelmann AG umzusetzen. Das Protokoll für die Interaktion mit CNC-Steuerungen derEckelmann AG wird in 3.4.4 beschrieben. Ein OPC UA Server muss den Adapter zurLaufzeit einbinden, um an Informationen aus der CNC-Steuerung zu gelangen. Eine Kon-figuration für den Adapter wird vorgesehen (siehe Abbildung 4.1). In der Konfigurationwird festgelegt, was der Adapter für die Erhebung eines Datums tun muss, damit ein OPCUA Knoten mit den Daten befüllt werden kann.

Abbildung 4.10: Komponenten des Adapters

In Abbildung 4.10 befindet sich ein Überblick über die Komponenten des Adapters. DieAdapterkomponente in Abbildung 4.1 wird in einen generischen Teil und einen herstel-lerspezifischen Teil aufgeteilt. Die generischen Komponenten erlauben es, den Adapterrudimentär zu benutzen. Er stellt die Schnittstelle bereit, die dann von einem OPC UAServer genutzt werden kann. Weiterhin wird in diesem Teil Funktionalität gesammelt, die

95

4.3. Adapter Kapitel 4. Design

vom herstellerspezifischen Adapter wiederverwendet werden kann. Für die Konfigurati-on wird eine XML-Datei benutzt, in der man für den generischen Adapter nur statischeWerte für einen Knoten im Informationsmodell angeben kann. Das Einlesen und Parsender XML-Datei wird nicht durch den Adapter durchgeführt, da sich das Design dann ab-hängig von bestimmten XML-Bibliotheken machen würde. Der OPC UA Server muss zurLaufzeit die XML-Datei einlesen und den resultierenden Baum in ein Format umwandeln,welches vom Adapter verarbeitet werden kann. Nach dem Konstruieren des Adapters istdie XML-Datei für den OPC UA Server nicht mehr relevant, da der Server ab dann aus-schließlich die Schnittstellen des Adapters benutzt.

Hersteller müssen den generischen Teil des Adapters erweitern. Aufgrund der Erweiter-barkeit von XML-Dokumenten ist das Erweitern der Konfiguration bereits implizit vor-handen.

4.3.2 Generische Adapterkomponenten

Die generischen Adapterkomponenten verwenden nur Konstrukte aus der Standardbiblio-thek der Programmiersprache. Somit ist keine Abhängigkeit von externen Bibliothekennotwendig. Folglich kann der Adapter von Compilern gut optimiert werden. In Abbil-

Abbildung 4.11: Klassenübersicht der Adapterkonfiguration

dung 4.11 werden die Klassen gezeigt, die die XML-Konfigurationsdatei repräsentierenund somit für die Konfiguration des Adapters verwendet werden. Der OPC UA Servermuss diese Klassen benutzen, um den Adapter anhand einer Konfigurationsdatei zu kon-struieren. Die Klassen realisieren die für ein XML-Dokument typische Abbildung in ei-ne Baum-Struktur. Ein XML-Knoten (XML Node) besitzt Kind-Knoten (children), einen

96

Kapitel 4. Design 4.3. Adapter

Wert (value), den Namen des Tags (name) im entsprechenden Namensraum (namespace)und Attribute (attributes). Attribute (XML Attribute Map) werden als Wertepaar vom At-tributnamen (attribute) und dessen Wert (value) realisiert. Um das Auffinden eines Kno-tens mit Namen des Tags einfacher zu machen, wird die Klasse XML Node Map einge-führt. Diese realisiert eine Abbildung von einem Tagnamen (tagname) zu einer Liste vonKnoten (nodes). Zusätzlich wird in XML-Knoten der BrowsePath des OPC UA Knotensgespeichert. In OPC UA dient die NodeID als eindeutige Identifikation eines OPC UAKnotens im Adressraum. Dieses Design benutzt jedoch den BrowsePath als Identifikati-on des Knotens, da beim Lesen der Konfigurationsdatei unmittelbar hervorgeht, welcherKnoten konfiguriert wird und im Informationsmodell keine Knoten benachbart sind, dieden gleichen BrowseName besitzen. Die Abbildung des BrowsePath wird in der Klas-se XML Node BrowsePath bereitgestellt. Eine Instanz der Klasse besitzt mindestens einObjekt der Klasse XML Node BrowseName in elements. Der BrowsePath kann, z.B. fürDebugging, in eine Zeichenkette umgewandelt werden (to_string). Das Format der Zei-chenkette ist nicht definiert und Teil der Implementierung. Mit dem Aufruf von last kannder letzte BrowseName des Pfades erreicht werden. Ein XML BrowseName enthält denNamen des OPC UA Knotens (name) und den entsprechenden Namensraum (namespace).Das Format für die Zeichenkette, die mit to_string angefordert werden kann, ist ebenfallsTeil der Implementierung.

1 <?xml version="1.0" encoding="UTF-8"?>

<configuration xmlns:ua="http://opcfoundation.org/UA/"

3 xmlns:di="http://opcfoundation.org/UA/DI/"

xmlns:vdw="http://opcfoundation.org/UA/CNC/"

5 xmlns:thesis_cnc="http://cs.hs-rm.de/mierswa_thesis/CNC/"

xmlns:eckelmann_cnc="http://cs.hs-rm.de/mierswa_thesis/eckelmann"

7 xmlns:demo="http://cs.hs-rm.de/mierswa_thesis/3AchsenEMCNCPlasmaSchneid/">

9 <position>remote</position>

<remote_info>10.0.0.29:44455</remote_info>

11 <name>CNC1</name>

<minimum_communication_interval>1000</minimum_communication_interval>

13<!-- server entry -->

15 <ua:object browse_name="Objects">

17 <!-- DeviceSet OpcUaDi entry point -->

<di:object browse_name="DeviceSet">

19<!-- prototype machine as example -->

21 <demo:object browse_name="EckelmannPlasmaSchneidmaschine">

23 <!-- Eckelmann specific cnc interface -->

<eckelmann_cnc:object browse_name="EMCncInterface">

97

4.3. Adapter Kapitel 4. Design

25<!-- the data interface of a CNC machine -->

27 <vdw:object browse_name="CncInterface">

29 <!-- revision of VDW CNC companion specification [string] -->

<vdw:variable browse_name="Revision">

31 <value kind="fix">0</value>

</vdw:variable>

33<vdw:object browse_name="CncChannelList">

35<demo:object browse_name="Channel1">

37<!-- actual feedrate value [double] -->

39 <vdw:variable browse_name="ActFeedrate">

<!-- range: 0-100 m/min -->

41 <value kind="fix" range_start="0" range_end="100000" unit="mm/min">0</value>

</vdw:variable>

43</demo:object> <!-- end of channel -->

45</vdw:object> <!-- end of channel list -->

47</vdw:object> <!-- end of interface -->

49</eckelmann_cnc:object> <!-- end of Eckelmann specific interface -->

51</demo:object> <!-- end of example machine -->

53</di:object> <!-- end of DeviceSet entry -->

55</ua:object> <!-- end of server entry -->

57</configuration>

Datei-Ausschnitt 4.1: XML-Konfigurationsdatei für den Beispiel-Adapter

Datei-Ausschnitt 4.1 zeigt einen Auszug aus der XML-Konfigurationsdatei für einen Ad-apter. Diese Datei konfiguriert beispielhaft die CNC-Werkzeugmaschine, die in 4.2.4 mo-delliert wurde. Das Wurzel-Element wird mit dem Tag configuration eingeleitet. Darinwerden Namensraum-Präfixe vergeben, damit die Datei lesbarer wird. Sie werden benö-tigt, um einen OPC UA BrowseName zu erstellen. Ein OPC UA Knoten wird mit dem Tagobject für OPC UA Objekt-Knoten oder variable für OPC UA Variablen-Knoten konfigu-riert. Der Namensraum des Tags und die Zeichenkette im Attribut browse_name ergebendann den OPC UA BrowseName.

Ein Beispiel: Das OPC UA Objekt Objects, welches als Einstiegspunkt im OPC UAServer alle Objekte sammelt, wird in Zeile 15 konfiguriert. Da das Objekt im OPCUA Standard-Namensraum vorhanden ist, wird der Präfix ua gewählt, welches auf den

98

Kapitel 4. Design 4.3. Adapter

Namensraum http://opcfoundation.org/UA/ abgebildet ist. Die Zeichenkette für den Na-mensraum muss identisch mit der gewählten Zeichenkette bei der Erstellung des Informa-tionsmodells sein. Dabei gilt zu beachten, dass auf Groß- und Kleinschreibung geachtetwird und auf die korrekte Benutzung von / am Ende des URI.

In configuration müssen neben object und variable folgende Tags erscheinen.

position Gibt an, ob die lokale Anbindung benutzt wird oder die Anbindung der CNC-Steuerung in einer anderen Umgebung stattfindet (gültige Werte: remote oderlocal).

remote_info Notwendig, falls position den Wert remote hat. Es dient als Informations-angabe, die der Adapter braucht, um die CNC-Steuerung zu erreichen.

name Der Name der verwendeten CNC-Steuerung. Diese Konfigurationsmöglichkeit er-laubt es, die korrekte CNC-Steuerung auszuwählen, falls eine Umgebung mit meh-reren CNC-Steuerungen kommuniziert.

minimum_communication_interval Das kürzeste Intervall in Millisekunden zwischenzwei aufeinander folgenden Übertragungen an die CNC-Steuerung. Damit wird si-chergestellt, dass CNC-Steuerungen vom OPC UA Server nicht überlastet werden.

Diese Tags werden nicht von der generischen Adapterkomponente verarbeitet. Sie dienenaber als gemeinsame Tags für alle ableitenden Adapterkomponenten.

In den Tags object und variable ist nur das Attribut browse_name relevant. In einemTag object dürfen beliebig viele andere object und variable Tags vorkommen. Der Tagvariable benötigt ein Kind-Element mit dem Tag value. Dieser Tag wird benutzt, umWerte für einen Knoten zu konfigurieren. Besitzt das Attribut kind den Wert fix wird beimInitialisieren des OPC UA Servers der Wert fest in das Informationsmodell übertragen, oh-ne sich jemals zu ändern. Ohne herstellerspezifische Erweiterung des Adapters ist dies dieeinzige Möglichkeit, Werte im Adressraum des OPC UA Servers einzubinden. Beispielefür statische Werte befinden sich in Zeile 31 und 41. Der XML-Tag value benötigt, wenndas Attribut kind den Wert fix besitzt, immer einen Wert (hier: 0). Beschreibt das Tag value

einen OPC UA Knoten mit dem Datentyp AnalogItemType, so muss ebenfalls angegebenwerden, in welchem Bereich die Werte liegen (Attribute range_start und range_end). DieEinheit für den AnalogItemType wird im Attribut unit spezifiziert. Diese drei Attributemüssen auch bei der Konfiguration der Variable vom Typ CncPositionVariableType an-gegeben werden. Sie spezifizieren den Wertebereich und die Einheit der Position in derCNC-Schnittstelle. Wird das Attribut kind für den Tag value auf fetcher gesetzt, so muss

99

4.3. Adapter Kapitel 4. Design

weiterhin das Attribut cache gesetzt sein. Dieses Attribut gibt an, wie lange dieses Datumim Cache (in Millisekunden) gespeichert wird.

Abbildung 4.12: Klassenübersicht in generischer Komponente des Adapters

In Abbildung 4.12 befindet sich eine Übersicht über die verwendeten Klassen in der ge-nerischen Komponente des Adapters. Die Schnittstelle des Adapters sieht vor, dass einOPC UA Server zu einem beliebigen Zeitpunkt Knoten im OPC UA Adressraum beob-achten (watch_node) und ignorieren (unwatch_node) kann. Für die Methode watch_node

muss zusätzlich zum Knoten ein Callback registriert werden, welches dann aufgerufenwird, wenn Daten für diesen Knoten von der CNC-Steuerung empfangen worden sind.In diesem Callback (XML Node Fetch Callback wird zum Einen der Knoten als Parame-ter übergeben, für den Daten empfangen wurden sind (node) und zusätzlich die StrukturXML Node Fetch Info. In dieser Struktur werden die Daten, die von der CNC-Steuerungempfangen worden sind, im Attribut bytes gespeichert.

Folgende Datentypen aus dem Informationsmodell werden unterstützt:

• Double (siehe 2.2.3)

• UInt32 (siehe 2.2.3)

• String (siehe 2.2.3)

• CncOperationMode (siehe 3.3.5)

• CncChannelProgramStatus (siehe 3.3.5)

• CncChannelStatus (siehe 3.3.5)

100

Kapitel 4. Design 4.3. Adapter

• CncPositionType (siehe 3.3.5)

Es werden weiterhin eindimensionale Array-Datentypen unterstützt, deren Elemente fol-genden Datentyp besitzen:

• String

• UInt32

• Double

Die Repräsentierung dieser Datentypen im Byte-Array ist Teil der Implementierung.

Der Aufruf clear bewirkt den Aufruf unwatch_node für alle derzeitig beobachteten Kno-ten. Mit Hilfe der Methoden set_info_callback und set_error_callback kann zu Beginneine Callback-Funktion registriert werden, die dann aufgerufen wird, wenn Status- oderFehlernachrichten von der CNC-Steuerung übermittelt werden. Die Methode run dientzum Starten des Adapters. Ab diesem Zeitpunkt können die Callbacks nicht mehr regis-triert werden. Diese können dann z.B. auf die Ereignisse des Typs CncMessageType undCncAlarmType aus OPC UA VDW abgebildet werden. Die Daten auf dem die Parameter-Zeiger zeigen, sind Teil der Implementierung. Die Methode iterate_nodes navigiert durchden Baum der XML-Knoten und ruft für jeden Knoten das übergebene Callback Iteration

Callback auf. Bei der Initialisierung des OPC UA Servers können mithilfe dieses Aufrufsalle Knoten konfiguriert werden.

Alle Methoden ausschließlich iterate_nodes sind abstrakt und müssen erweitert werden,damit der Adapter instanziiert werden kann.

4.3.3 Herstellerspezifische Erweiterungen des Adapters

Für die Eckelmann AG wird die Konfiguration erweitert, in dem für Knoten mit dem Tagvalue mehrere Kind-Elemente erlaubt sind. Derzeit wird nur das Tag pfield eingeführt,welches keine Attribute besitzt und als Wert einen P-Feld-Index repräsentiert.

[...]

2 <!-- the data interface of a CNC machine -->

<vdw:object browse_name="CncInterface">

4 <vdw:object browse_name="CncChannelList">

6 <demo:object browse_name="Channel1">

101

4.3. Adapter Kapitel 4. Design

8 <!-- active G functions [uint32 array] -->

<vdw:variable browse_name="ActGFunctions">

10 <value kind="fetcher" cache="1000">

<pfield>51015</pfield>

12 </value>

</vdw:variable>

14</demo:object> <!-- end of channel -->

16</vdw:object> <!-- end of channel list -->

18 </vdw:object> <!-- end of interface -->

[...]

Datei-Ausschnitt 4.2: XML-Konfigurationsdatei für den Eckelmann-Adapter

Datei-Ausschnitt 4.2 erweitert die Konfigurationsdatei in Datei-Ausschnitt 4.1 ab Zeile34 mit dem Tag pfield (Zeile 11). Dieses Tag gibt an, dass die Beschaffung des Datumsvon einem P-Feld abhängig ist (siehe 3.4.4). Es ist möglich, mehrere P-Felder anzuge-ben, falls Daten aus verschiedenen P-Feldern zusammen erst ein Datum für den OPC UAAdressraum ergeben.

Hersteller von CNC-Steuerungen müssen den Adapter so erweitern, dass Daten zur Lauf-zeit des OPC UA Servers von der CNC-Steuerung in den Adressraum übermittelt werdenkönnen. Sie müssen die abstrakten Methoden in Abbildung 4.12 implementieren und dieSteuerung anbinden.

Abbildung 4.13: Klassenübersicht bei herstellerspezifischen Erweiterungen des Adapters

Abbildung 4.13 zeigt, welche Methoden der abstrakten Basisklasse Adapter Herstellerimplementieren müssen.

Die Beschreibung der Methoden kann aus dem vorherigen Abschnitt 4.3.2 entnommen

102

Kapitel 4. Design 4.3. Adapter

werden. Ein P-Feld wird beim Abruf von Daten für verschiedene Variablentypen imAdressraum benötigt. Wird für die Beschaffung von Daten eines Knotens keine Um-wandlung benötigt, so wird der Wert aus dem P-Feld direkt als Datum für den Adress-raum benutzt. Dies ist z.B. der Fall für den Knoten ActJogIncrement (P-Feld 51013) undActOverride (P-Feld 51016). Andere Knoten müssen die Werte aus einem oder mehrerenP-Feldern umwandeln. Dazu muss der Programmcode in watch_node entsprechend desbeobachteten Knotens eine Umwandlungsfunktion benutzen.

103

4.3. Adapter Kapitel 4. Design

104

Kapitel 5

Implementierung

In diesem Kapitel wird das Konzept aus Kapitel 4 umgesetzt. Die Programmiersprache derImplementierung ist C++ (siehe 3.2.4). Der Programmcode wird auf dem Linux-SystemUbuntu 16.04.1 LTS [Ltd16] kompiliert. Für die Entwicklungsumgebung werden folgen-de Werkzeuge benutzt:

• Vim [Moo16]

• CMake [CHK+16]

• GNU Compiler Collection [Inc16]

• MinGW [Tie16]

5.1 Informationsmodell

Das Informationsmodell wird vom UaModeler (Abschnitt 3.2.3) erstellt und der entspre-chende Code generiert. Die erstellten Dateinamen haben einen Präfix, um Namenskon-flikte zu vermeiden. Symbole, darunter auch Funktionen und Klassen, werden in dengenerierten Dateien in C++-Namensräumen gesammelt, die ebenfalls im UaModeler an-gegeben werden können. Der UaModeler generiert für jeden modellierten Typen zweiDateien:

• Basis-Implementierung (z.B. thesiscnc_cnctoolcarriertypebase.cpp/h)

• Abgeleitete Implementierung (z.B. thesiscnc_cnctoolcarriertype.cpp/h)

105

5.1. Informationsmodell Kapitel 5. Implementierung

In der abgeleiteten Implementierung können Entwickler eigenen Code hinzufügen. Dieabgeleiteten Implementierungsklassen werden vom UaModeler nur dann überschrieben,wenn dies vom Benutzer gewünscht ist. Damit ist es möglich, das Informationsomdell beiBedarf zu verändern, ohne den hinzugefügten Programmcode neu zu schreiben.

Um Änderungen im Informationsmodell zur Laufzeit zu signalisieren (siehe Abschnitte3.3.5.4 und 3.3.5.6), werden GeneralModelChangeEvent-Ereignisse genutzt. Der UaMo-deler erzeugt derzeit fehlerhaften Code, wenn ein GeneralModelChangeEvent-Ereignisfür Listen-Typen (CncAxisListType, CncSpindleListType und CncChannelListType) mo-delliert wird. Deshalb müssen diese Ereignisse in den abgeleiteten Implementierungs-klassen manuell modelliert werden. Dazu wird der Adressraum durchsucht und versucht,einen Knoten mit der TypeDefinition eines der drei Typen zu finden. Bei Erfolg wird dieMethode addUaReference des RootNodeManager mit entsprechenden Parametern aufge-rufen. Quellcode 5.1 zeigt, wie der RootNodeManager genutzt werden kann, um Referen-zen im Informationsmodell manuell hinzuzufügen.

1 root_nm_ = NodeManagerRoot::CreateRootNodeManager();

root_nm_->addUaReference(node->nodeId(), OpcUaId_GeneralModelChangeEventType,

OpcUaId_GeneratesEvent);

Quellcode 5.1: Hinzufügen von GeneralModelChangeEvent-Referenzen

Die Kernkomponenten des generierten Codes für das Informationsmodell sindNodeManager (Abschnitt 3.2.2). Sie werden in den Dateien generiert, die mitnodemanager.cpp/h enden. Diese werden im Binding-Code des Unified AutomationC++ Server vor dem Start hinzugefügt und verwalten alle Knoten in einem OPC-UA-Namensraum. Das Informationsmodell für die 3-Achsen-Plasma-Schneidmaschine ausAbschnitt 4.2.4 wird im Namensraum Demo modelliert. Der generierte NodeManagerwird in der Datei demo_nodemanagerdemo.cpp/h erzeugt. Um das Verzeichnis des ge-nerierten Codes vom UaModeler unberührt zu lassen, wird stattdessen im Quellcode-Verzeichnis des Binding-Codes, eine Datei mit einer Klasse erzeugt, die von diesemNodeManager ableitet (siehe Abschnitt 5.3).

106

Kapitel 5. Implementierung 5.2. Adapter

5.2 Adapter

5.2.1 Überblick

In diesem Abschnitt wird die Implementierung der Anbindung an die CNC-Steuerung derEckelmann AG (Abschnitt 4.3) beschrieben. Die generische Adapterkomponente (Ab-schnitt 4.3.2) muss mit der Kommunikation zur CNC-Steuerung erweitert werden. Diesergibt sich durch die Implementierung der abstrakten Methoden (Abschnitt 4.3.3).

Abbildung 5.1: Komponenten des Wrappers für Eckelmann CNC-Steuerungen

Da die Benutzung der CNC-Steuerung der Eckelmann AG (Abschnitt 3.4.4) derzeitnur in einer Microsoft Windows ® Umgebung stattfindet, wird als Teil der Implemen-tierung eine Wrapper-Komponente entwickelt. Abbildung 5.1 zeigt die Komponentendes Wrappers. Damit dieser Treiber in Linux und Windows benutzt werden kann, wer-

107

5.2. Adapter Kapitel 5. Implementierung

den die Funktionen und Datentypen in objektorientierte Datenstrukturen verpackt, dieausschließlich Standard-C++-Komponenten nutzen. In der Abbildung werden diese alsInterface-Komponente Anbindung aufgezeigt. Im weiteren Verlauf werden die Anbin-dungen MMICTRL genannt, da die Eckelmann AG so ihren Treiber nennt. Lokale Anbin-

dung und Remote Anbindung stellen zwei Implementierungen der abstrakten Schnittstellebereit. Der Name Remote bedeutet hier, dass sich die Steuerung nicht in der aktuellenUmgebung befindet. Diese kann aber auch in einer virtuellen Maschine auf dem glei-chen Host laufen. Auf Microsoft Windows ® kann dann sowohl die lokale als auch dieRemote Anbindung genutzt werden, während Linux-basierende Laufzeitumgebung aus-schließlich die Remote Anbindung benutzen können. Diese Implementierungen ermög-lichen es, über die Verwendung des TCP/IP-Protokolls mit einer CNC-Steuerung in ei-nem Netzwerk zu kommunizieren. Die Remote Anbindung ist über eine Client-Server-Architektur (Wrapper Client und Wrapper Server) realisiert. Der Wrapper Server musswiederum auf Microsoft Windows ® ausgeführt werden und dort eine lokale Anbindungan die CNC-Steuerung besitzen.

5.2.2 Objektorientierte Schnittstelle des Eckelmann-Treibers

Abbildung 5.2 zeigt einen Überblick über die objektorientierte Schnittstelle für CNC-Steuerungen der Eckelmann AG. Für die Schnittstelle werden alle relevanten Komponen-ten des Treibers betrachtet. Die Klasse MMICTRL realisiert den Zugriff auf eine CNC-Steuerung. Die Bedeutung der abgebildeten Funktionen und Typen kann aus dem Analy-seteil 3.4.4 entnommen werden. Folgende Methoden werden auf DLL-Funktionen abge-bildet:

close ncrClose

get_init_state ncrGetInitState

load_firmware_blocked ncrLoadFirmwareBlocked

send_file_blocked ncrSendFileBlocked

receive_file_blocked ncrReceiveFileBlocked

send_message ncrSendMesage

read_param_array ncrReadParamArray

108

Kapitel 5. Implementierung 5.2. Adapter

Abbildung 5.2: Klassenübersicht des Wrappers für Eckelmann CNC-Steuerungen

Diese Methoden sind abstrakt deklariert, da sie spezifisch für die jeweilige Anbindung(Remote oder Lokal) implementiert werden müssen.

Die Klasse Transfer Message bildet den Typen MSG_TR der DLL ab. Der Typ MSG_TR

wird in der Regel durch Zugriffe auf die enthaltene union, je nach Wert in sb0_uc undsb1_uc (bzw. controlblock0 und controlblock1). Die objektorientierte Schnittstelle siehtein data-Attribut in Transfer Message vor, in dem die union hinterlegt wird. Dabei gilt zubeachten, dass die Daten des union ohne Padding bzw. Alignment Bytes im data-Attributehinterlegt werden. Für die Verarbeitung des Attributs data in der Klasse Transfer Message

benötigt man die Informationen, wie die union des Typs MSG_TR aufgebaut ist. DieseInformationen befinden sich im Header com_def.h. Transfer Message wird als Parameterder Methode send_message verwendet und kann als Teil des Byte-Arrays im CallbackParameter data des Callbacks Message Callback auftreten (Erklärung im weiteren Verlauf

109

5.2. Adapter Kapitel 5. Implementierung

dieses Abschnitts).

Die Klasse PField Map ist eine Abbildung von P-Feld-Indizes auf ihre Werte. Sie wird alsEin- und Ausgabeparameter für die Methode send_param_array benutzt. Als Eingabepa-rameter müssen die Indizes gesetzt sein, die aus der Steuerung gelesen werden sollen.Nach Aufruf der Methode sind an entsprechenden Stellen die Werte gesetzt.

Für die Methoden receive_file_blocked und send_file_blocked wird neben dem Namen derzu übertragenden Datei (Parameter name) ein Transferblock (Parameter block) vom Enu-merationstypen Transfer Block benötigt. Dieser Block gibt an, um welchen Dateitypenes sich handelt. Die Enumerations-Werte ntsprichen der bereitgestellten Transferblöckein der DLL. Beispielsweise bildet der Enumerations-Wert NC_PROGRAMM den DLL-Wert SB1_NC_PROG_KUC ab, usw. Weiterhin benötigt die Methode send_file_blocked

bei bestimmter Parameterwahl eine Header-Zeichenkette (siehe Dokumentation vonncrSendFileBlocked).

Der Enumerationstyp Init Status wird als Rückgabewert für die Methodeload_firmware_blocked benötigt. Der Enumerations-WertFIRMWARE_ALREADY_LOADED entspricht dem Rückgabewert -1 vonncrLoadFirmwareBlocked und FIRMWARE_LOADED entspricht dem Rückgabewert 0.

Die Methoden set_message_callback und get_message_callback setzen das Callback fürden Empfang von CNC-Steuerungsnachrichten bzw. fordern es an. Das Callback ist vomTypen Message Callback und wird mit den Parametern type und data aufgerufen. Der Pa-rameter type vom Enumerations-Typen Callback Type entspricht dem ulType Parameterder DLL-Callback-Funktion MsgCallback. Bestimmte Typen von Nachrichten-Callbacks,z.B. VK_MMI_CAN_TRANSFER_STATE, welcher den aktuellen Status der laufendenCAN-Übertragung mitteilt, nicht verarbeitet, da sie nicht benötigt werden. In solch einemFall wird der Typ auf MMI_UNIMPLEMENTED gesetzt und data ist ein NULL-Pointer.Folgende Callback-Typen werden unterstützt:

MMI_DOWNLOAD_... Entspricht den DLL-Werten VK_MMI_DOWNLOAD_....Das Byte-Array in data ist wie folgt aufgebaut: An erster Stelle befindet sich derEnumerations-Wert vom Enumerations-Typ Transfer Block. An zweiter und dritterstelle befinden sich vorzeichenlose 64-Bit Integer (Byte-Reihenfolge Little Endian),die die derzeitige Transfer-Position und Dateigröße repräsentieren. Darauf folgt ei-ne maximal 260 Zeichen lange Zeichenkette für den Dateinamen und eine maximal256 Zeichen lange Zeichenkette, die den Status bei Firmware-Transfers repräsen-tiert.

110

Kapitel 5. Implementierung 5.2. Adapter

MMI_TRANSFER_... Entspricht den DLL-Werten VK_MMI_TRANSFER_....Das Byte-Array ist identisch mit dem Byte-Array in MMI_DOWNLOAD_.... Jedochbesitzt es keine Status-Repräsentierung, da diese exklusiv für Firmware-Transfersvorgesehen ist.

MMI_NCMSG_RECEIVED Entspricht dem DLL-WertVK_MMI_NCMSG_RECEIVED. Das Byte-Array in data enthält eine Instanz desTyps Transfer Message. Die ersten vier Bytes entsprechen einem vorzeichenlosen32-Bit Integer, der die Anzahl an Bytes im Attribut data der folgenden Transfer

Message angibt.

MMI_ERROR Entspricht dem DLL-Wert VK_MMI_ERROR_MSG. Aufbau des Byte-Arrays wie in MMI_NCMSG_RECEIVED.

MMI_CYCLIC_CALL Entspricht dem DLL-Wert VK_MMI_CYCLIC_CALL.Das Byte-Array ist ein NULL-Pointer.

MMI_DEFAPP_STATE Entspricht dem DLL-Wert VK_MMI_DEFAPP_STATE. DasByte-Array enthält 1 Byte mit dem Wert 0 oder 1 (siehe ncrSetDefaultApp).

MMI_UNIMPLEMENTED Wird dann als Typ gesetzt, wenn die Verarbeitung internnicht implementiert ist oder fehlschlägt. Das Byte-Array enthält einen vorzeichen-losen 32-Bit Integer, der die Länge der folgenden Zeichenkette angibt. Darauf fol-gen die Zeichen der Fehlermeldung.

Im Falle eines Fehlers beim Aufrufen der Methoden wird eine Exception geworfen. Diezugehörigen Klassen sind in Abbildung 5.3 dargestellt.

Alle Methoden ausser open können einen std::runtime_error erzeugen, falls die Verbin-dung noch nicht geöffnet wurde. Diese Klasse wird vom C++-Standard bereitgestellt undkann mit der Operation what den Fehlertext zurückgeben. Die Methode close kann einenstd::runtime_error erzeugen, falls die Verbindung schon geschlossen wurde. Falls dieFunktion ncrGetInitState in der DLL fehlschlägt, kann die Methode get_init_state einenstd::runtime_error erzeugen. Das Treiber-Dokument der Eckelmann AG gibt in diesemFall keine weitere Auskunft über die Fehlerart.

Die Methoden open, load_firmware_blocked und read_param_array können Error erzeu-gen. Diese Klasse leitet von std::runtime_error ab. Das Attribut win32_error repräsentierteine Fehlernummer, dessen Aufbau im Treiberdokument der Eckelmann AG definiert ist.

111

5.2. Adapter Kapitel 5. Implementierung

Abbildung 5.3: Exception-Klassen für die objektorienterte Schnittstelle für EckelmannCNC-Steuerungen

Die Methoden send_file_blocked und receive_file_blocked können Transfer Excepti-

on und Transfer Exception Error erzeugen. Transfer Exception wird von den Me-thoden send_file_blocked und receive_file_blocked geworfen. Das Attribut type vomEnumerations-Typen Transfer Error Type gibt Auskunft, warum der Transfer fehlgeschla-gen ist. Es bildet die entsprechenden Fehlerarten in der DLL ab (TRANSFER_BREAK, ...).Der Enumerations-Wert FAIL bildet den DLL-Wert TRANSFER_ERROR ab. Die Ausnah-me Transfer Exception Error wird dann generiert, wenn bei einem Transfer ein Zugriffs-fehler auftritt, also die DLL-Funktionen TRANSFER_ERROR zurückliefern. Dieser Typleitet sowohl von Transfer Exception als auch von Error ab. Das Attribut type besitzt indiesem Fall den Wert FAIL gesetzt und win32_error enthält einen Fehlercode.

Die Schnittstelle wird von einer Klasse MMICTRL Local (Lokale Anbindung in 5.2.1) undeiner Klasse MMICTRL Remote (Remote Anbindung in 5.2.1) implementiert. MMICTRL

Local bindet die Treiber der Eckelmann AG an und konvertiert die internen Typen aufTypen aus der objektorientierten Schnittstelle. MMICTRL Remote benutzt ein Client, dermit einem Server kommuniziert, welcher selbst Instanzen von MMICTRL Local verwaltet.

5.2.3 Remote Anbindung der Steuerung

Für CNC-Steuerungen der Eckelmann AG, die in anderen Umgebungen laufen, wird ei-ne Client-Server-Architektur entworfen (siehe 5.2.1). Abbildung 5.4 zeigt die Klassenund Datentypen, die das Nachrichten-Protokoll zwischen Client und Server realisieren.Nachrichten werden mit der Klasse Message repräsentiert. Das Attribut version gibt dieVersion des Nachrichtenprotokolls an. Für jede Methode der objektorientierten Schnitt-

112

Kapitel 5. Implementierung 5.2. Adapter

Abbildung 5.4: Klassen und Datentypen für das Nachrichten-Protokoll

stelle MMICTRL wird ein entsprechender Nachrichten-Typ eingeführt. Clients setzen denNachrichten-Typ für das Versenden (z.B. CTRL_OPEN), wohingegen Server die Nach-richt mit CTRL_OPEN_RESPONSE quittieren. Zusätzlich werden die Typen OK (fürPing-Nachrichten), SERVER_ERROR (für Fehler im Server) und CTRL_MESSAGE (fürNachrichten von CNC-Steuerungen) eingeführt. Nachrichten können maximal 65535 By-tes umfassen (16-Bit Attribut size) und haben einen Payload (data), in welchem dieNachrichten-Parameter gespeichert werden. Client und Server können mit den Methodenappend_... und extract_... bestimmte Daten an die Nachricht anhängen und extrahieren.Dabei müssen die Methoden prüfen, dass die Nachricht genügend Informationen in data

bereitstellt bzw. die Größe der Nachricht nicht überschritten wird. Nachrichten könnenmit dem Aufruf von to_bytes in Byte-Arrays konvertiert werden und mit from_bytes ausByte-Arrays erstellt werden. Eine leere Nachricht kann mit der Methode from_type erstelltwerden.

Abbildung 5.5 zeigt die Klassen, die für das Bereitstellen der CNC-Steuerung in einer an-deren Umgebung benötigt werden. Der Server (Wrapper Server) verwaltet lokale Anbin-dungen an CNC-Steuerungen (MMICTRL Local). Die Klasse MMICTRL Remote benutzteinen Client (Wrapper Client) und kommuniziert über Nachrichten mit dem Server. Fürdie Übermittlung von Informationen zwischen Client und Server wird ein Nachrichten-Protokoll basierend auf TCP/IP implementiert.

Ein Client kann sich mit dem Aufruf von connect zu einer bestimmten IP Adresseverbinden und baut intern eine TCP/IP-Verbindung auf. Danach können Nachrichten

113

5.2. Adapter Kapitel 5. Implementierung

Abbildung 5.5: Überblick der Klassen in der Client-Server-Architektur von MMICTRLRemote

vom Typ Message versendet (send_message) und Nachrichten vom Server empfangen(recv_message) werden. Die Methode recv_message wird als blockierende Methode ent-worfen. Es muss also möglich sein, mittels send_message das Warten auf Nachrichten zuunterbrechen und den parallelen Zugriff auf Attribute zu verhindern.

Der Server ist abstrakt und kann beim Konstruieren in einen Modus versetzt werden,der auf eingehende Verbindungen wartet. Mit dem Aufruf der Methode run_one wirdfür ein Zeitintervall von timeout_ms Millisekunden auf eingehende Verbindungen oderNachrichten gewartet. Wird eine Verbindung entgegengenommen, so wird die Metho-de on_client_new mit einem Handle (client) aufgerufen. Die Methode on_client_remove

wird dann aufgerufen, wenn ein Client in run_one nicht länger beobachtet wird. Dies kannzum Beispiel auftreten, wenn Fehler bei der Kommunikation entstehen. Trifft eine Nach-richt für einen Client ein, so wird on_client_message mit dem Client-Handle (client) undder Nachricht (message) aufgerufen. Eine ableitende Klasse kann jederzeit einen Cliententfernen (remove_client) und Nachrichten zu Clients senden (send_message_to_client).

Die Klasse MMICTRL Server leitet von Wrapper Server ab und muss die abstrakten Me-

114

Kapitel 5. Implementierung 5.3. NodeManager für Instanzen des Prototyps

thoden implementieren. Das Client-Handle kann für eine interne Abbildung von Clientsund Instanzen von MMICTRL Local benutzt werden. So ist es möglich, dass ein Servermehrere Anbindungen gleichzeitig verwalten kann. Das Server-Programm muss auf dergleichen Umgebung gestartet werden, in der auf CNC-Steuerungen zugegriffen werdenkann.

Der Client von MMICTRL Remote muss die Parameter der Methoden in eine Nachrichteinbetten und auf eine Antwort vom Server warten. Dabei wird ein Timeout gesetzt, sodass davon ausgegangen wird, dass die Kommunikation mit dem Server störungsfrei ver-läuft. Nach Erhalt der Antwort vom Server extrahiert der Client die relevanten Daten ausder Nachricht. Tritt ein Fehler im Server auf, so kann jederzeit eine Ausnahme vom Typstd::runtime_error generiert werden. Abgesehen davon müssen die Methoden sich so ver-halten, wie es bei der Beschreibung der Schnittstelle festgelegt wurde.

5.3 NodeManager für Instanzen des Prototyps

Der NodeManager für die Instanzen des Prototyps muss darüber informiert werden,wann Variablen gelesen werden, da die Lesezugriffe an den Adapter weitergeleitetwerden müssen. Aus diesem Grund müssen die Callback-Methoden readValues undvariableCacheMonitoringChanged implementiert werden. Dafür wird eine KlasseMyNodeManager erstellt, die vom NodeManager für die Instanzen ableitet. Im Initialisie-rungs-Callback afterStartup wird über alle Knoten iteriert, die in der XML-Konfigurationangegeben sind und für jeden dieser Knoten wird eine Initialisierung durchgeführt. Zu-nächst wird geprüft, dass jeder konfigurierte Knoten im Adressraum des OPC UA Serversauftaucht. Schlägt eine Prüfung fehl, so wird ein Fehler erzeugt und der OPC UA Servernicht gestartet. Ist die XML-Konfigurationsdatei fehlerhaft (fehlt z.B. ein value-Tag ineinem variable-Tag), so wird der Server ebenfalls nicht gestartet. Für Variablen vom TypAnalogItemType werden Einheiten und zulässige Minimal- und Maximalwerte gesetzt.Als letzter Schritt wird das Caching-Verhalten für die Variablen im Adressraum kon-figuriert. Variablen, die in der XML-Konfiguration mit kind="fix" konfiguriert wurden,werden mit dem Wert aus der Konfiguration initialisiert und im Callback für Lesezugrif-fe nicht beachtet. Alle anderen Variablen müssen im Callback auf Gültigkeit des Cachesgeprüft werden. Ist das Cache-Datum gültig, so wird bei einem Lesezugriff das Cache-Datum zurückgeliefert, sonst muss der Adapter dazu veranlasst werden, beim nächstenZugriff auf die CNC-Steuerung das Datum anzufordern, und der OPC UA Server mussdas Cache-Datum aktualisieren.

115

5.3. NodeManager für Instanzen des Prototyps Kapitel 5. Implementierung

In MyNodeManager wird ein Thread gestartet, der die Methode run des Adapters aus-führt. Die Callbacks für Lesezugriffe und Monitoring müssen dann je nach Bedarfwatch_node und unwatch_node des Adapters aufrufen. Damit dynamisch Ereignisse er-zeugt werden können, müssen vor Starten der Methode run entsprechend die Callbacksfür Nachrichten der CNC-Steuerung im Adapter registriert werden. Bei Aufruf wer-den im Adressraum des Servers dynamisch Ereignis-Knoten erstellt (CncAlarmType undCncMessageType) und mit dem CncInterface-Objekt aus dem Instanz-Namensraum ver-bunden.

Da der Adapter keine Informationen über den OPC UA Server besitzt, müssen die Da-ten aus dem Adapter zur Laufzeit des UA Servers konvertiert werden. Die Methodewatch_node des Adapters erlaubt es, ein Callback zu registrieren, welches mit dem Da-tum aus der CNC-Steuerung aufgerufen wird, sobald ein Datum erfolgreich aus der CNC-Steuerung beschafft wurde. Für Konvertierungen von primitiven Integer-Datentypen wirddie Byte-Reihenfolge Little Endian gewählt. Ein Double-Zahlenwert aus dem Adapterwird in eine Zeichenkette umgewandelt. Wird vom Adapter zum OPC UA Server eine Zei-chenkette übertragen, so befindet sich in den ersten vier Bytes die Länge der Zeichenkettein der Byte-Reihenfolge Little Endian. Zusammengesetzte Typen (Structures) werden imAdapter als Abfolge von primitiven (oder zusammengesetzten Attributen) übertragen. Ar-rays werden im Adapter ebenfalls als Abfolge von Elementen konvertiert. Die Länge desArrays wird als 32-Bit Zahl repräsentiert und als erstes gespeichert. Bisher werden nureindimensionale Arrays unterstützt, deshalb wird keine Information über die Dimensio-nierung des Arrays gespeichert.

Der NodeManager für die Instanzen des Prototyps ist verantwortlich für das Caching derWerte im Informationsmodell. Durch Implementierung der Methode readValues könnenLesezugriffe auf Werte verarbeitet werden. In dieser Methode wird der Quell-Zeitstempeldes Wertes (SourceTimestamp) mit dem Zeitstempel des Zeitpunktes vom Lesezugriff ver-glichen. Bei einer Differenz, die höher als das Cache-Intervall ist, wird der Wert invalidiertund ein Client erfährt mit dem BadWaitingForInitialData Status der Variable, dass die-ses Datum derzeit nicht vorliegt. Der Adapter wird zu diesem Zeitpunkt mit dem Aufrufvon watch_node dazu veranlasst, beim nächsten Kommunikationsintervall dieses Datumvon der CNC-Steuerung abzurufen. Wird im Server eine Subscription aktiviert, so kanndurch Implementierung der Methode variableCacheMonitoringChanged herausgefundenwerden, welche Daten in der Subscription aktiv sind. Bei einem normalen Lesenzugriff(einzeln) des Clients, wird nach Aufrufen des Callbacks für das Eintragen des Datums imInformationsmodell, das Datum nicht weiter von der CNC-Steuerung abgefragt (Metho-denaufruf unwatch_node im Adapter). Ist dieses Datum in einer Subscription aktiviert,

116

Kapitel 5. Implementierung 5.4. Anbindung des OPC UA Servers

so wird die Methode unwatch_node nicht aufgerufen. Stattdessen werden die Daten so-lange im Informationsmodell aktualisiert, bis die Subscription dieses Datum nicht längerbenötigt.

5.4 Anbindung des OPC UA Servers

Der OPC UA Server basiert auf Beispielen aus dem Unified Automation C++ Server Fra-mework, welches in 3.2.2 analysiert wurde. Zunächst wird die Konfiguration des Adapterseingelesen und in Objekten der XML-Klassen gespeichert, die in Abbildung 4.11 abge-bildet sind. Da der Unified Automation C++ Server bereits XML-Funktionalität anbietet,sind keine weiteren Abhängigkeiten zu XML-Bibliotheken notwendig.

117

5.4. Anbindung des OPC UA Servers Kapitel 5. Implementierung

UaXmlDocument adapterConfigDocument(sAdapterConfigFileName.toUtf8());

2 std::shared_ptr<adapter::adapter> adapter;

adapter::xml_node_map_type adapterConfigNodes;

4// Benutzung der Unified Automation XML-Funktionalitaet, zum Befuellen von

6 // adapterConfigNodes

[...]

8// Erstellen des Adapters

10 adapter.reset(new adapter_eckelmann(adapterConfigNodes));

Quellcode 5.2: Erstellung des Adapters

Quellcode 5.2 zeigt einen Ausschnitt des Programmcodes zur Erstellung des Adap-ters. Zunächst wird ein XML-Dokument erzeugt (UaXmlDocument) und ein leeresXML Node Map (adapterConfigNodes). Dann wird das Mapping durch Parsen der XML-Datei befüllt und schließlich die Eckelmann-Implementierung des Adapters erstellt (Zeile10).

Daraufhin können die NodeManager einzeln dem Server hinzugefügt werden.

manager = new OpcUaCnc::NodeManagerCNC(OpcUa_True);

2 pServer->addNodeManager(manager);

Quellcode 5.3: Hinzufügen eines NodeManager

Quellcode 5.3 zeigt, wie der NodeManager für das Informationsmodell OPC UA CNChinzugefügt wird. Das gleiche Prinzip wird für alle NodeManager angewendet:

• OpcUaDi::NodeManagerDevices (OPC UA DI, bereitgestellt von Unified Automa-tion)

• OpcUaCnc::NodeManagerCNC (OPC UA CNC)

• ThesisCNC::NodeManagerTCNC (Resultierendes Informationsmodell ausAbschnitt 4.2.2)

• EckelmannCNC::NodeManagerECNC (Herstellerspezifische Erweiterungen ausAbschnitt 4.2.3)

• MyNodeManager (Informationsmodell für Instanzen des Prototyps mit Code-Erweiterungen (siehe 5.1) aus Abschnitt 4.2.4)

118

Kapitel 5. Implementierung 5.5. Umfang und Aufwand

Teil der Implementierung CodezeilenInformationsmodelle

OPC UA CNC 15881Resultierendes Informationsmodell 1744Eckelmann Informationsmodell 1774Demo-Instanzen 4909Gesamt 24308

AdapterGenerische Komponenten 188Eckelmann-spezifische Komponenten 546Objektorientierte Schnittstelle des Treibers 141Remote- und Lokal-Anbindung des Treibers 3126Gesamt 4001

Anbindung des Adapters an den OPC UA ServerGesamt 1076

Gesamt 29308

Tabelle 5.1: Anzahl der Codezeilen der Implementierung

Zuletzt wird der Server gestartet (Methode start von UaServerApplication) und auf dasBeenden des Servers gewartet (Shutdown-Flag). Nach dem Start des Servers werden Call-backs der NodeManager (afterStartUp) aufgerufen, die dann eigenen Initialisierungscodeausführen können.

5.5 Umfang und Aufwand

Der Implementierungsaufwand der Informationsmodelle ist gering, da ein Großteil desProgrammcodes vom UaModeler generiert wird. Das Hinzufügen vonGeneralModelChangeEvent-Referenzen im Informationsmodell für OPC UA CNC um-fasst im Wesentlichen nur wenige Zeilen Programmcode. Die Anbindung des Adap-ters am Unified Automation C++ Server und die objektorientierte Schnittstelle desEckelmann-Treibers machen den größten Teil der Implementierung aus. Mit dem Pro-gramm cloc [Dan16] wurden die Programmcode-Zeilen für verschiedene Anteile der Im-plementierung ermittelt. Tabelle 5.1 zeigt die Anzahl der Codezeilen für die jeweiligenTeile der Implementierung.

Die generischen Adapterkomponenten stellen nur wiederverwendbare Basis-Funktiona-litäten für alle Implementierungen des Adapters bereit (z.B. Iterieren der Knoten inder XML-Konfigurationsdatei). Abstrakte Methoden der Schnittstelle müssen implemen-tiert werden. Der Aufwand der Implementierung ist aufgrund wenig wiederverwendbarer

119

5.5. Umfang und Aufwand Kapitel 5. Implementierung

Funktionalität sehr gering. Die Eckelmann-spezifischen Adapterkomponenten implemen-tieren die abstrakten Methoden des generischen Adapters und verwenden darin die ob-jektorientierte Schnittstelle des Eckelmann-Treibers und die zwei Anbindungen an denEckelmann-Treiber. In dieser Komponenten werden ebenfalls Daten, die von der CNC-Steuerung empfangen werden für das Informationsmodell umgewandelt bzw. konvertiert,falls dies notwendig ist.

Die Betrachtung der Größen des kompilierten Codes wird in drei Kategorien unterteilt.

• Eckelmann-Adapter auf einem Linux-System

• Unified Automation Server auf einem Linux-System

• MMICTRL Server auf einem Windows-System

Die Größe der shared library des Eckelmann-Adapters beträgt 284kb. In dieser Bibliothekwerden die Anbindungen an den Treiber (static library, 309kb), die generischen Kom-ponenten (static library, 40kb) und die Eckelmann-spezifischen Adapter-Komponentenverknüpft. Der OPC UA Server von Unified Automation hat auf einem Linux-Systemeine Größe von 9376kb. Zur Laufzeit benötigt der Server die Bibliothek libuastack.so,die vorkompiliert von Unified Automation im SDK enthalten ist. Der Speicherverbrauchnach 10 Minuten Laufzeit beträgt auf einem Linux-System ca. 15MB (Virtual Set Size).Auf dem Windows-Rechner wurde die Komponente MMICTRL Server genauer betrach-tet. Die ausführbare Datei hat eine Größe von 416kb. Da die Datei mit MinGW übersetztworden ist, werden die MinGW-C++-Bibliotheken benötigt, die ca. 12MB groß sind.

120

Kapitel 6

Evaluierung

In diesem Kapitel wird der entwickelte Prototyp evaluiert. Für die Evaluierung werdendie Anwendungsfälle aus Abschnitt 3.1 betrachtet. In den Anwendungsfällen und dendaraus abgeleiteten Anforderungen müssen mehrere Funktionen erfüllt werden, die indiesem Kapitel mit Testfällen überprüft werden. Abschließend wird in diesem Kapitel dieImplementierung zur Erbringung der Anwendungsfälle bewertet und über gesammelteErfahrungen berichtet.

6.1 Überprüfen des Konzepts auf Erfüllung der Anfor-derungen

Die Anforderungen A1 (Erstellen eines Informationsmodells für CNC-Steuerungen) undA2 (Erstellen eines Informationsmodells für CNC-Werkzeugmaschinen) werden beidedurch die Anwendung UaModeler (Abschnitt 3.2.3) bereitgestellt. Damit Anwender einInformationsmodell spezifisch für CNC-Steuerungen bzw. CNC-Werkzeugmaschinen er-stellen können, wurden Typen im Design-Kapitel im Abschnitt 4.2 eingeführt. Das In-formationsmodell in Abschnitt 4.2.2 verbindet zum einen den für die Zukunft geplantenStandard für CNC-Datenschnittstellen OPC UA CNC (Abschnitt 3.3.5) und den Standardfür modulare Geräte OPC UA DI (Abschnitt 3.3.4). Exemplarisch wird diesem Infor-mationsmodell die Komponente der Typ CNCPlasmaCutType hinzugefügt. Dies zeigt,dass das Informationsmodell für weitere Modellierungsmöglichkeiten erweiterbar ist. Füreine CNC-Werkzeugmaschine mit einer CNC-Steuerung der Eckelmann AG wurde dar-auf aufbauend ein Informationsmodell entwickelt (Abschnitt 4.2.3), das die Modellierungvon Komponenten ermöglicht, die Energie-Monitoring unterstützen. Für eine 3-Achsen-

121

6.1. Überprüfen des Konzepts auf Erfüllung der Anforderungen Kapitel 6. Evaluierung

Plasma-Schneidmaschine mit einer CNC-Steuerung der Eckelmann AG ist ein vollstän-diges Objektdiagramm in Abschnitt 4.2.4 aufgezeigt. Die Anforderungen A1 und A2 imAnwendungsfall U1 werden zum einen durch den Entwurf eines Informationsmodellsin dieser Arbeit und der Anwendung UaModeler von Unified Automation abgedeckt. Ineinem Review-Meeting mit der Eckelmann AG wurde das hier entworfene Informations-modell vorgestellt und es wurden keine gravierenden Unstimmigkeiten entdeckt. WeitereErweiterungen im Informationsmodell sind durch die geerbte Modularität von OPC UAgegeben. Durch die Objekt-basierende Struktur von OPC UA ist es möglich, an verschie-denen Stellen das Informationsmodell für eigene CNC-Werkzeugmaschinen zu erweitern.Dies beinhaltet die Vererbung von existierenden Typen und das Hinzufügen von Referen-zen und Attributen in existierenden Typen.

Nachdem ein Informationsmodell erstellt wurde, kann dies mit der Anwendung UaMode-ler in ein Adressraum für den OPC UA Server von Unified Automation überführt werden.Die Anforderung A3 (Informationsmodell im Kontext Industrie 4.0) wird durch die Code-Generierung von UaModeler und das Einbinden des Informationsmodells im OPC UAServer (Abschnitt 5.4) realisiert. Der Programmieraufwand für die Einbindung des In-formationsmodells im OPC UA Server ist gering. Durch das Benutzen der AnwendungUaModeler ist das Erstellen des Informationsmodells mit zeitlichem Aufwand bei derEinarbeitung in UaModeler und das Bedienen der graphischen Oberfläche verbunden.Die Einbindung des NodeManagers für ein Informationsmodell ist nur einmalig durchzu-führen. Eine Änderung im Informationsmodell bedarf keiner Änderung in der Anbindungdes Informationsmodells im OPC UA Server. Das Anbieten des OPC-UA-Adressraums,welcher mit UaModeler erstellt wird, reicht aus, um Anforderung A3, jedoch nicht denAnwendungsfall U2 (Abrufen von Daten im Netzwerk) zu realisieren. Die Funktionalitätzur Erbringung der Anforderung A6 (Befüllen des Informationsmodells mit Daten) unddas Abrufen von Daten wird mit detaillierten Testfällen im nächsten Abschnitt evaluiert.

In Abschnitt 2.2.2.1 werden verschiedene Architektur-Muster für das OPC UA Frame-work beschrieben. Für die Implementierung des Prototyps wird angenommen, dass sichein lokaler OPC UA Server in unmittelbarer Umgebung der CNC-Werkzeugmaschinebefindet. Deshalb nutzt die Implementierung die Client-Server-Architektur, die als Basis-Architektur ausreichend ist. Die Daten und Ereignisse im Informationsmodell werden inder Regel lokal beobachtet und bei entsprechenden Fehlern werden Eingriffe vom Bedie-ner der CNC-Werkzeugmaschine nötig sein. An einer zentralen Verarbeitungsstelle ist essinnvoll Aggregating Server einzusetzen, um z.B. Durchschnittswerte oder den zeitlichenVerlauf von Daten zu überwachen. Auch eine Server-Server-Architektur kann auf dieserEbene benutzt werden, um Datenredundanz zu ermöglichen.

122

Kapitel 6. Evaluierung 6.2. Testen der Datenverarbeitung

6.2 Testen der Datenverarbeitung

In diesem Abschnitt wird die Datenverarbeitung (Bereitstellung und Anforderung) desOPC UA Servers mit dem Informationsmodell aus Abschnitt 4.2.4 getestet. Dazu werdenfolgende Testfälle erstellt:

T1 Verbindungsaufbau zur CNC-Steuerung

T2 Verbindungsaufbau zum OPC UA Server

T3 Bereitstellen eines statischen/fixen Datums im Informationsmodell

T4 Bereitstellen eines dynamischen Datums im Informationsmodell

T5 Monitoring von Daten im Informationsmodell

T6 Monitoring von Ereignissen im Informationsmodell

Testfall T1 soll prüfen, ob die Verbindung zu einer CNC-Steuerung erfolgreich durchge-führt werden kann. Die Implementierung sieht vor, dass anhand der Konfigurationsdateiangegeben werden kann, wie eine Verbindung zur CNC-Steuerung aufgebaut wird. Fürdiesen Testfall wird zunächst die Standard HMI Software der Eckelmann AG gestartet,die dazu benutzt wird, die Firmware auf die CNC-Steuerung zu laden und diese zu in-itialisieren (Abschnitt 3.4.4). Die Implementierung ist derzeit lediglich in der Lage, eineVerbindung zur CNC-Steuerung aufzubauen, ohne eine Initialisierung oder einen Uploadder Firmware durchzuführen. Die Verbindung zur CNC-Steuerung wird automatisch beimStarten des OPC UA Servers aufgebaut. Kann keine Verbindung aufgebaut werden, brichtder Start des Servers ab. Für zukünftige Erweiterungen der Implementierung kann vorge-sehen werden, den Pfad zur Firmware und anderen Initialisierungsdateien in der Adapter-Konfiguration anzugeben und die Initialisierung ebenfalls nach Start des OPC UA Serversdurchzuführen. Wird der OPC UA Server über die kompilierte Konsolenanwendung ge-startet, so erscheint im Ausgabefenster eine oder mehrere Meldungen:

Looked up address for ’IPv4’: 10.18.48.144

2 Initiate connection to <10.18.48.144>:<22233>

[MMICTRL] Opened CNC connection [CNC1] successfuly.

Quellcode 6.1: Ausgaben bezüglich Verbindungsaufbau zu CNC-Steuerung

123

6.2. Testen der Datenverarbeitung Kapitel 6. Evaluierung

Ausschnitt 6.1 zeigt die Ausgaben beim Starten des OPC UA Servers bezüglich des Ver-bindungsaufbau zu CNC-Steuerungen. Die Zeilen 1 und 2 signalisieren das eine CNC-Steuerung auf einem Remote Host kontaktiert wird. Darin wird sowohl die IP-Version alsauch die Adresse und der Port des MMICTRL Servers ausgegeben. Zeile 3 wird sowohlbei Verbindungsaufbau für lokale als auch entfernte Verbindungen angezeigt. Darin wirdder Name (CNC1) der CNC-Steuerung ausgegeben.

Testfall T2 kann z.B. mit einem OPC UA Client getestet werden. Für die Evaluierungwird der OPC UA Client von Unified Automation UaExpert genutzt. Durch den Menü-punkt Add Server, kann im Eingabefeld die Adresse des Servers eingegeben werden. DerOPC UA Server wird auf dem gleichen System gestartet, wie der OPC UA Client. Fürden Verbindungsaufbau sind die Informationen aus der Datei ServerConfig.xml auf Seitedes Servers relevant, die vom Unified Automation C++ Server bereitgestellt werden, umEndpunkte zu konfigurieren. Mit der Standard-Konfiguration wird ein Endpunkt erstellt,der auf einer Adresse auf eingehende Verbindungen wartet. Für den Verbindungsaufbaumuss im UaExpert der Endpunkt der aktuelle Hostname des Systems ermittelt werden (aufLinux-Systemen durch den Befehl hostname). Damit eine IPv4-Verbindung zum OPCUA Server aufgebaut werden kann, wird der Endpunkt opc.tcp://<hostname>:48010 ver-wendet. Im Log-Fenster meldet UaExpert, nach erfolgreichem Verbindungsaufbau, mitBrowseSucceeded einen erfolgreichen initialen Browse des Adressraums. Abbildung 6.1zeigt im unteren Fenster Ausgaben nach Verbindungsaufbau zum lokalen OPC UA Ser-ver. Die Meldung BrowseSucceeded steht für das erfolgreiche Durchsuchen der Standard-Knoten des OPC UA Servers.

Testfall T3 und T4 wurden erstellt, um das Auslesen der Daten im Informations-modell zu testen. Statische Daten im Informationsmodell werden in der Adapter-Konfigurationsdatei mit dem Attribut-/Wertepaar kind="fix" für ein value XML-Tag defi-niert. Datei-Ausschnitt 4.1 zeigt, dass die Variable VendorName für ein statisches Datumkonfiguriert ist. Durch Ausklappen (Browsen) des BrowsePaths der Knoten gelangt manzum Knoten CncInterface. Dort wird die Variable VendorName angeklickt. Das untereFenster zeigt dann den Variablen-Wert mit Attributen an. Abbildung 6.2 zeigt im unterenFenster zunächst welcher Knoten erfolgreich ausgelesen wurde (NS6|Numeric|6010 ent-spricht der Node ID der Variable VendorName). Im unteren Teil der Abbildung (FensterAttributes) steht sowohl der Wert Eckelmann AG und der Datentyp String. Diese Test-Vorgehensweise wurde für alle statischen Informationen im Informationsmodell durchge-führt und somit Testfall T3 erfolgreich getestet.

Der Testfall T4 wird für Variablen durchgeführt, die von der CNC-Steuerung Wer-te zugewiesen bekommen. Diese Daten werden in der Adapter-Konfiguration mit dem

124

Kapitel 6. Evaluierung 6.2. Testen der Datenverarbeitung

Abbildung 6.1: UaExpert Oberfläche nach Verbindungsaufbau zum OPC UA Server

Attribut-/Wertepaar kind="fetcher" definiert. Datei-Ausschnitt 4.2 zeigt so eine definier-te Variable. Durch gleiche Vorgehensweise, die beim Testen von T3 angewandt wurde,ist man in der Lage, diese Variable im Informationsmodell zu finden. Durch Anklickender Variable ActGFunctions wird der untere Bereich aktualisiert und der Wert und dieAttribute der Variable wurde aufgelistet. Abbildung 6.3 zeigt im oberen Abschnitt mitblauer Hervorherbung die für das Browsen ausgewählte Variable. Im unteren Abschnittsteht zunächst der StatusCode BadWaitingForInitialData. Dies liegt an der Caching-Implementierung. Wird ein Wert nicht beobachtet oder das erste mal aufgerufen wirdder Adapter nach Ablauf des Kommunikations-Intervall dieses Datum von der CNC-Steuerung anfordern und für die konfigurierte Zeit im Cache behalten. Ein weiterer Brow-se in diesem Zeitraum zeigt, dass die Daten erfolgreich von der CNC-Steuerung über-

125

6.2. Testen der Datenverarbeitung Kapitel 6. Evaluierung

Abbildung 6.2: UaExpert Oberfläche nach Browsen eines statischen Werts im Informai-tonsmodell

tragen wurden (Abbildung 6.4). Ohne das Starten eines Programms in der EckelmannStandard HMI ist der Wert initial UInt32 Array[2] mit den Elementen 31 und 132. Diessind die aktiven G-Codes, die von einer CNC-Steuerung der Eckelmann AG ausgelesenwerden können, ohne dass ein Programm auf der CNC-Steuerung ausgeführt wird. Die-se Vorgehensweise wurde für alle konfigurierten dynamischen Variablen angewendet underfolgreich getestet.

Der Testfall T5 soll dazu genutzt werden, um zu überprüfen, ob sich Werte im Laufe derZeit im Informationsmodell verändern. In der Regel werden die Informationen, die auseiner CNC-Steuerung ausgelesen werden, nicht nur einmalig, sondern über einen gewis-sen Zeitraum benötigt. Dies gilt z.B. für das Überwachen der Veränderung der Achsen-Position oder der aktuell ausgeführten Steuerungsbefehle der Programme. Für die Ver-anschaulichung des Testfalls wird die Variable ActProgramStatus des Kanals Channel1

im Informationsmodell ausgewählt. Durch das Ziehen (per Drag & Drop) der Variable indas Fenster Data Access View im UaExpert wird eine Subscription am OPC UA Serverkonfiguriert. Durch Rechtsklick auf diese Variable können die Einstellungen der Subscrip-

126

Kapitel 6. Evaluierung 6.2. Testen der Datenverarbeitung

Abbildung 6.3: Teil der UaExpert Oberfläche nach Browsen eines dynamischen Werts imInformaitonsmodell

tion verändert werden. Der Standardfall (Update alle 500ms) reicht für den Testfall aus.Nach Initialisierung der Steuerung besitzt diese Variable den Wert 0 (Stopped). In Abbil-dung 6.5 zeigt das DataAccessView-Fenster die Variable ActProgramStatus im Initialzu-stand. Im Standard HMI der Eckelmann AG kann ein Programm geladen (z.B. BIKE.DIN)und ausgeführt werden. Wechselt man in den UaExpert, so erkennt man, dass sich derVariablen-Wert auf 1 (Running) (Abbildung 6.6) geändert hat. Die Implementierung istalso in der Lage, die Daten zur Laufzeit der CNC-Steuerung im OPC-UA-Adressraum zuändern und der Testfall somit erfolgreich.

Der Testfall T6 prüft, ob Ereignisse der CNC-Steuerung im OPC UA Server sichtbar

127

6.2. Testen der Datenverarbeitung Kapitel 6. Evaluierung

Abbildung 6.4: Teil der UaExpert Oberfläche nach Browsen eines dynamischen Werts imInformaitonsmodell

Abbildung 6.5: DataAccessView im UaExpert zur Beobachtung von Subscriptions

werden. Dazu wird zunächst eine Verbindung zum OPC UA Server ohne aktive Subscrip-tions aufgebaut. Im UaExpert kann unter dem Menüpunkt Document->Add das Fenster

128

Kapitel 6. Evaluierung 6.2. Testen der Datenverarbeitung

Abbildung 6.6: DataAccessView im UaExpert nach Veränderung einer Subscription

Event View hinzugefügt werden. Nun kann das zu beobachtende Objekt (hier das Server-Objekt Server) mittels Drag & Drop in das Fenster gezogen werden. Nun wird im Adress-raum die Variable ActGFunctions in das DataAccessView-Fenster gezogen. Dadurch wirdder Adapter beauftragt das entsprechende P-Feld der CNC-Steuerung auszulesen. Diesschlägt in diesem Fall jedoch fehl, da das Standard HMI der Eckelmann AG noch nichtgestartet wurde und somit keine Initialisierung der CNC-Steuerung durchgeführt wurde.Abbildung 6.7 zeigt, dass im EventView-Abschnitt von UaExpert ein Ereignis ausgelöst

Abbildung 6.7: EventView im UaExpert nach Auslösung eines asynchronen Fehler-Ereignisses

wurde (Tab Event). Die erste Zeile der Nachricht wird von der Adapter-Implementierunggeneriert. Sie beinhaltet den Task, die Fehlerklasse und die Fehlernummer des Fehlers.Die zweite Zeile wird von der CNC-Steuerung generiert und der Alarm-Meldung ange-hängt. Das Dokument HMI_Error_DE.db, in dem deutsche Fehlermeldungen für CNC-Steuerungen der Eckelmann AG hinterlegt sind, beschreibt die Fehlernummer 101 mit:

129

6.3. Performance-Tests Kapitel 6. Evaluierung

Steuerung nicht initialisiert, Nachricht konnte nicht gesendet werden. Die zu erwartendeFehlermeldung wurde also korrekt von der CNC-Steuerung übertragen und im OPC UAServer sichtbar gemacht. Die Ereignis-Typen unterscheiden sich zwischen Fehlern undNachrichten. In diesem Testfall wurden ausschließlich Fehler-Ereignisse betrachtet, dadie Implementierung der Behandlung für Nachrichten-Ereignissen identisch ist und keineNachrichten von der CNC-Steuerungen generiert wurden.

6.3 Performance-Tests

In diesem Abschnitt wird ein Teil der Implementierung auf Performance untersucht. Fürdie Tests wird die folgende Umgebung verwendet:

• Die CNC-Steuerung der Eckelmann AG ist einsatzbereit und das Standard HMIwurde gestartet

• An einem entfernten Windows-Arbeitsplatzrechner im LAN wird die CNC-Steue-rung angeschlossen und dort ein MMICTRL Server gestartet

• An einem Linux-Arbeitsplatzrechner im LAN wird der OPC UA Server gestartet,welcher über MMICTRL Remote mit dem MMICTRL Server kommuniziert

• Ein Test-Programm wurde geschrieben, welches das Unified Automation ClientSDK verwendet

Das Test-Programm misst die benötigte Zeit für den Abruf eines Cache-Wertes im In-formationsmodell und die benötigte Zeit für den Abruf eines Wertes, welcher vor demAbruf nicht im Cache stand. Für die Ermittlung des Durchschnittwerts werden 500 Wer-te abgerufen. Zusätzlich zählt das Programm wie oft ein Wert im Cache lag und wieoft das Datum von der CNC-Steuerung abgerufen werden musste. Die Testfälle werdennach dem Kommunikationsintervall (minimum_communication_interval in der Adapter-Konfiguration) und dem Zeitraum im Cache (cache-Attribute des value-Tags in derAdapter-Konfiguration) kategorisiert. Die folgenden Performance-Tests wurden durch-geführt:

TP1 Abrufen eines Datums, welches 10ms im Cache gespeichert wird bei einem Kom-munikationsintervall von 1ms.

TP2 Abrufen eines Datums, welches 10ms im Cache gespeichert wird bei einem Kom-munikationsintervall von 50ms.

130

Kapitel 6. Evaluierung 6.3. Performance-Tests

Testfall Abrufdauer (cached) Abrufdauer (non-cached) Hits MissesTP1 197,16µs 5170,39µs 17799 7789TP2 254,43µs 39421,44µs 20377 73374TP3 277,92µs 238948,89µs 18346 405876TP4 232,92µs 4798,51µs 423304 7214

Tabelle 6.1: Messergebnisse der Performance-Tests

TP3 Abrufen eines Datums, welches 10ms im Cache gespeichert wird bei einem Kom-munikationsintervall von 250ms.

TP4 Abrufen eines Datums, welches 250ms im Cache gespeichert wird bei einem Kom-munikationsintervall von 50ms.

Tabelle 6.1 zeigt die Messungen des Test-Programms für die Performance-Tests. DerTestfall TP1 zeigt, dass die geringste durchschnittliche Zeit für das Abrufen eines Da-tum im Caches bei etwa 197,16µs liegt und der höchste Durchnittswert im Testfall TP3bei 277,92µs liegt. Diese Durchschnittswerte sollten nahe beieinander liegen. Die Abwei-chung können durch das Locking in der Implementierung der Funktion oder durch denOverhead der Netzwerk-Implementierung der verwendeten Virtual Machine (an die dieCNC-Steuerung angeschlossen ist) zustande kommen. Testfälle TP2 und TP3 zeigen beider Abrufdauer eines nicht im Cache bereitstehenden Datum eine Abrufdauer, die in etwagleich dem Kommunikationsintervall sind. Die Abrufdauer eines Datums, welches nichtim Cache bereitsteht, ist maximal die Länge des Kommunikationsintervall. Abweichun-gen können dadurch entstehen, dass sowohl der Thread für die Bearbeitung im OPC UAServer und der Thread für das Kommunizieren mit der CNC-Steuerung unabhängig von-einander ausgeführt werden. Dadurch kann die Abfrage eines Datums zu Beginn bis zumEnde des Kommunikationsintervall am OPC UA Server eintreffen. Die Zeit die benötigtwird bis das Datum aus der CNC-Steuerung verfügbar ist, hängt dann von der Restdauerdes abgelaufenen Kommunikationsintervalls ab. Als weitere Beobachtung kann festgehal-ten werden, dass die Cache-Hits durch das Verlängern des Cache-Zeitraums steigen unddie Cache-Misses mit Verlängern des Kommunikationsintervalls steigen.

131

6.3. Performance-Tests Kapitel 6. Evaluierung

132

Kapitel 7

Zusammenfassung & Ausblick

Ein wichtiger Aspekt der Integration und Vernetzung existierender Werkzeugmaschinenin Industrie 4.0 ist die Modellierung der relevanten Maschinendaten, so dass sie von Tech-nologien unterstützt werden, die in Industrie 4.0 eingesetzt werden. Die Modellierungs-möglichkeiten, die in dieser Arbeit vorgestellt wurden, sollen Hersteller dabei helfen. Da-zu wurden in Abschnitt 3.3 vorhandene Gerätebeschreibungssprachen auf ihre Verwend-barkeit für die Modellierung von CNC-Werkzeugmaschinen untersucht und vorhandeneInformationsmodelle analysiert. OPC Unified Architecture gilt in Deutschland im Kon-text Industrie 4.0 als de-facto Standard für die Modellierung und die Kommunikation vonInformationen. In den Vereinigten Staaten ist das Industrial Internet Consortium (IIC) einPendant zu Industrie 4.0 in Deutschland, welches als Standard OMG DDS favorisiert. ImMai 2016 trafen sich Vertreter des IIC und der Plattform Industrie 4.0 und beschlossengemeinsame Ziele [Wal16]. Dies hat zur Folge, dass OPC UA und DDS, die auf jeweilsanderen Technologien basieren, aufeinander abgebildet werden sollen [McD16]. Das indieser Arbeit entwickelte Informationsmodell basiert auf dem Basis-Informationsmodellvon OPC UA. Das Informationsmodell OPC UA Information Model for CNC Systems

wird als Basis für die Modellierung von CNC-Schnittstellen herangezogen, welches alsCompanion Specification bei der OPC Foundation eingereicht wird. Das OPC UA Infor-

mation Model for CNC Systems wurde an der Uni Stuttgart in Kooperation mit verschiede-nen CNC-Steuerungen evaluiert. Es sollte daher als ausreichende Basis für die Modellie-rung von CNC-Schnittstellen dienen. Um Informationen von CNC-Werkzeugmaschinenzu modellieren, wird die Companion Specification OPC UA for Devices (DI) herange-zogen, da diese von der OPC Foundation empfohlen wird, um Geräte zu modellieren.In Abschnitt 4.2 wurde ein Informationsmodell entworfen, welches diese beiden Spezifi-kationen miteinander verbindet und Herstellern die Möglichkeit anbietet, das Modell zu

133

Kapitel 7. Zusammenfassung & Ausblick

erweitern.

Ein weiteres Ziel dieser Arbeit war es, einen Prototyp zu entwickeln, der Informatio-nen von ausgewählten CNC-Steuerungen für den ausgewählten Kommunikationsstandardbereitstellt. Damit Daten einer CNC-Steuerung im Informationsmodell sichtbar werden,werden Daten von einer CNC-Steuerung abgerufen und gegebenenfalls angepasst oderumgewandelt. Verschiedene Zugriffsmöglichkeiten auf CNC-Steuerungen wurden in Ab-schnitt 3.4 analysiert. Die Eckelmann AG stellte für den Prototyp eine CNC-Steuerungbereit. Aus diesem Grund wurde für den Entwurf zwar angenommen, dass verschiede-ne Arten existieren, um auf CNC-Steuerungen zuzugreifen, jedoch berücksichtigt dieImplementierung des Prototyps nur CNC-Steuerungen der Eckelmann AG. Um dieserPrototypen für andere CNC-Steuerungen zu verwenden, müssen eigene Implementierun-gen geschrieben werden, um Informationen im OPC-UA-Adressraum bereitzustellen. DasKonzept für den Prototyp, welches in Kapitel 4 beschrieben wurde, enthält eine Adapter-Komponente, die implementiert werden muss. Der Prototyp nutzt für die Implementie-rung den OPC UA C++ Server von Unified Automation. Dieser Server wird laut der OPCFoundation am häufigsten genutzt. Das Informationsmodell konnte mit einer Anwendung,die von Unified Automation bereitgestellt wird, über eine graphische Benutzeroberflächeerstellt werden.

Die Bedeutung von Energiemanagement ist für Unternehmen, aufgrund von stetig stei-genden Energiekosten und der Sorge um das zukünftige Klima, enorm hoch. Das Energie-Monitoring dient oft als erste Hilfestellung, um intern ein intelligentes Energiemanage-ment zu betreiben. Aufgrund dieser Erkenntnis wurde in Absprache mit der EckelmannAG beispielhaft eine Erweiterung vereinbart, welche das Informationsmodell in dieser Ar-beit mit Informationen erweitern soll, die Energie-Monitoring unterstützen. Derzeit gibtes keine formalen Standards für Energie-Monitoring, so dass nur rudimentäre und fürsinnvoll befundene Informationen im Informationsmodell hinzugefügt wurden.

Während der Recherche über vorhandene Informationsmodelle für CNC-Werkzeug-maschinen wurde zunächst festgestellt, dass der Standard MTConnect, der in den Ver-einigten Staaten weit verbreitet ist, eine große Anzahl von Möglichkeiten bereitstellt,um Komponenten von CNC-Werkzeugmaschinen zu modellieren. Allerdings beschrän-ken sich die Modellierungsmöglichkeiten auf Komponenten der Werkzeugmaschinen undnicht auf Eigenschaften der CNC-Steuerung oder deren ausführbaren Programmen. Her-steller von CNC-Steuerungen bieten zum Teil integrierte OPC UA Server mit eigenenInformationsmodellen für den Zugriff auf Variablen an (z.B. CODESYS OPC UA Ser-ver [Gmb16c]). Durch die Verwendung von speziell entwickelten Informationsmodellen,stellte sich die Modellierung der CNC-Schnittstelle im Allgemeinen als Herausforderung

134

Kapitel 7. Zusammenfassung & Ausblick

da. Das von der VDW entwickelte Informationsmodell, wurde nach dem Erhalt des Re-lease Candidates im Juni 2016 als Basis für das hier entwickelte Informationsmodell her-angezogen. Allerdings wird es eine Zeit dauern, bis Hersteller dieses Informationsmodellintegrieren, da es zum jetzigen Zeitpunkt noch nicht von der OPC Foundation angenom-men wurde.

Das MTConnect-Informationsmodell, welches in den Vereinigten Staaten eine weite Ver-breitung hat, kann ebenfalls in OPC UA abgebildet werden. In einem nächsten Schrittkann dies mit dem Informationsmodell der CNC-Schnittstelle verbunden werden. Da-mit wären sowohl für die Modellierung von Werkzeugmaschinen-Komponenten und derCNC-Schnittstelle standardisierte Informationsmodelle vorhanden.

Sobald ein Standard-Informationsmodell für Energie-Monitoring bereitstellt, sollte diesebenfalls im Informationsmodell berücksichtigt und mit eingebunden werden. Das Infor-mationsmodell für die CNC-Schnittstelle sieht zwar vor, dass Daten geschrieben werdenkönnen, jedoch wird dies in der Implementierung nicht genutzt, da CNC-Steuerungen derEckelmann AG keine Schreibrechte für diese Daten anbietet.

Die Eckelmann AG ist sich bewusst, dass sie derzeit nicht in der Lage sind alle Daten imInformationsmodell mit den Daten der CNC-Steuerungen zu befüllen. Insbesondere Da-ten für das Energie-Monitoring sind derzeit nicht von CNC-Steuerungen der EckelmannAG abrufbar. Dies galt auch in der Implementierung zu berücksichtigen, so dass für be-stimmte Informationen nur Platzhalter-Werte oder sich über den Zeitverlauf veränderndeWerte eingetragen werden konnten.

Die Implementierung des Prototyps bestand im wesentlichen aus der Anbindung des ge-nerierten Codes für das Informationsmodell an den OPC UA Server von Unified Automa-tion und der Anbindung des OPC UA Servers an die CNC-Steuerung. Dabei stellte sichheraus, dass der UaModeler, der den Code für das Informationsmodell generiert, zumTeil fehlerhaft ist und man manuell einige Änderungen im Code vornehmen muss. Da dasInformationsmodell ausschließlich die API des Unified Automation C++ SDK benutzt,musste ein Großteil der API-Dokumentation betrachtet werden. Unified Automation siehtvor, dass man anhand von kleinen Beispielen ein eigenes Informationsmodell mit derAPI erstellt, weshalb die Recherche der API anhand des generierten Codes (was tut eineFunktion <x> an dieser Stelle) entgegen der Intuition von Unified Automation schwierigwar.

Der entwickelte Prototyp kann für die Eckelmann AG als Initiator dabei helfen, vorhan-dene Werkzeugmaschinen in Industrie 4.0 zu integrieren. Die Informationen, die durchdas hier entworfene Informationsmodell bereitgestellt werden, können dann an verschie-

135

Kapitel 7. Zusammenfassung & Ausblick

denen Positionen im Unternehmen genutzt werden. Durch die Verwendung von OPCUA als Framework wird eine CNC-Werkzeugmaschine im Netzwerk sichtbar, so dassdie Maschinendaten in Unternehmen auf Betriebsebene (MES) oder Unternehmensebe-ne (SAP) bei der vertikalen Integration durchgängig verwendet werden können. Da dasInformationsmodell auch vorsieht, gewisse Daten zu schreiben, könnte dies in Zukunftdafür genutzt werden, ganze Steuerungsvorgänge für CNC-Werkzeugmaschinen überOPC UA einzuleiten. Die Basis des Informationsmodells sind Companion Specificationsder OPC Foundation, so dass das Informationsmodell auch unternehmensübergreifendwiederverwendbar und wiedererkennbar ist. Das Energie-Monitoring im Informations-modell stellt zusätzlich eine Komponente bereit, um den Energieverbrauch von CNC-Werkzeugmaschinen zu beobachten. Dies kann von Unternehmen genutzt werden, diebereits jetzt Energiemanagement betreiben oder dies in Zukunft müssen. Dadurch kön-nen nicht nur Werte des Energieverbrauchs für die Bilanz herangezogen werden, son-dern auch den Energieverbrauch zweier identischer CNC-Werkzeugmaschinen einfachverglichen werden. Seit April 2012 können sich Unternehmen das Energiemanagement-system (EnMS) nach DIN EN ISO 50001 [ISO11] zertifizieren lassen [EA16b]. Die Zer-tifizierung ist für alle Größen eines Unternehmens durchführbar und birgt Vorteile durchAusgleichsregelungen [GRU16b]. Große und verbundene Unternehmen müssen seit 2015[EA16a] gesetzlich nach DIN EN 16247-1 [GRU16a] Anforderungen erfüllen. Die hiereingeführten rudimentären Energie-Monitoring-Komponenten sollen ein Anstoß sein dieAnalyse bezüglich des Energiemanagements im Unternehmen zu unterstützen.

136

Kapitel 8

Literaturverzeichnis

[BM16] BILDUNGSZENTRUM MÜNCHEN, Privatblog für CNC-Fachkraft-Kurse d.: Einführung in die CNC-Technik. https://cnctraining.

wordpress.com/theorie/, 2016. – Zugriff: 12.09.2016

[BMB15] BMBF: Gemeinsame Plattform Industrie 4.0 startet. https:

//www.bmbf.de/de/gemeinsame-plattform-industrie-

4-0-startet-1017.html, 2015. – Zugriff: 03.10.2016

[Brü14] BRÜCKER, Frank: Industrie 4.0 - Die vierte industrielle Revolution. http://euro.vdma.org/documents/106103/4318562/Industrie%

204.0.pdf/f887fce0-cc90-455a-966a-a780e71baf06, 2014

[Bun16] Zukunftsprojekt Industrie 4.0 (BMBF). https://www.bmbf.de/de/

zukunftsprojekt-industrie-4-0-848.html, 2016. – Zugriff:06.05.2016

[CHK+16] CEDILNIK, Andy ; HOFFMAN, Bill ; KING, Brad ; MARTIN, Ken ; NEUN-DORF, Alexander: CMake. https://cmake.org/, 2016. – Zugriff:12.09.2016

[Con16] CONTRIBUTORS, MTConnect ® User’s P.: MTConnect ® User’s Portal - De-

vices and Components. http://mtcup.org/wiki/Devices_and_

Components, 2016. – Zugriff: 12.09.2016

[Cor15] CORPORATION, Brian Sides Okuma A.: MTConnect for IoT - ARC Con-

ference. http://www.arcweb.com/events/arc-industry-

forum-orlando/arcindustryforum2015presentations/

BSides-Okuma.pdf, 2015. – Zugriff: 12.09.2016

137

Kapitel 8. Literaturverzeichnis

[Dan16] DANIAL, Al: cloc - Count Lines of Code. https://github.com/

AlDanial/cloc, 2016. – Zugriff: 12.09.2016

[EA16a] ENERGIE-AGENTUR, Deutsche: Deutsche Energie-Agentur (dena) -

Energieaudit. http://industrie-energieeffizienz.de/

energiekosten-senken/energieeffizienz-prozesse/

energieaudit/ablauf/, 2016

[EA16b] ENERGIE-AGENTUR, Deutsche: Deutsche Energie-Agentur (dena) -

Energiemanagement. http://industrie-energieeffizienz.

de/energiekosten-senken/energieeffizienz-prozesse/

energiemanagement/energiemanagemensysteme/, 2016

[e.V16a] E.V., DRIVECOM N.: DRIVECOM USER GROUP e.V. http://www.

drivecom.org/, 2016. – Zugriff: 12.09.2016

[e.V16b] E.V., INTERBUS C.: INTERBUS Club. http://www.interbusclub.com/, 2016. – Zugriff: 12.09.2016

[e.V16c] E.V., PROFIBUS N.: PROFIBUS Downloads for Devie Integrati-

on. http://www.profibus.com/nc/download/device-

integration/downloads/vol-1-gsd-specification-

specification-for-profibus-device-description-and-

device-integration/display/, 2016. – Zugriff: 12.09.2016

[e.V16d] E.V., PROFIBUS N.: PROFIBUS Home. http://www.profibus.

com/technology/profibus/, 2016. – Zugriff: 12.09.2016

[e.V16e] E.V., PROFIBUS N.: PROFIBUS Specifications & Standards.http://www.profibus.com/nc/download/specifications-

standards/downloads/profibus-standard-dp-

specification/display/, 2016. – Zugriff: 12.09.2016

[e.V16f] E.V., Sercos I.: Sercos - The Automation Bus. http://www.sercos.

org/, 2016. – Zugriff: 12.09.2016

[e.V16g] E.V. eCl@ss: eCl@ss - Classification and Product Description. http:

//www.eclass.eu/, 2016. – Zugriff: 12.09.2016

[FI13] FOUNDATION, OPC ; INSTITUTE, MTConnect: MTConnect OPC UA

Companion Specification. http://www.mtconnect.org/opc-ua-

companion-specification/, 2013. – Zugriff: 12.09.2016

138

Kapitel 8. Literaturverzeichnis

[Fou13] FOUNDATION, OPC: OPC Unified Architecture for Devices (DI). https://opcfoundation.org/developer-tools/specifications-

unified-architecture/opc-unified-architecture-for-

devices-di/, 2013. – Zugriff: 12.09.2016

[Fou16a] FOUNDATION, OPC: OPC Foundation - ANSI C Stack Sour-

ce Code. https://opcfoundation.org/developer-

tools/developer-kits-unified-architecture/ansi-

c-stack-source-code/, 2016. – Zugriff: 12.09.2016

[Fou16b] FOUNDATION, OPC: OPC Foundation - Find Products. https://

opcfoundation.org/products, 2016. – Zugriff: 12.09.2016

[Fou16c] FOUNDATION, OPC: OPC Foundation - Stefan Hoppe - Lead Product Mana-

ger. https://opcfoundation.org/about/opc-foundation/

organization/stefan-hoppe-lead-product-manager/,2016. – Zugriff: 12.09.2016

[Fou16d] FOUNDATION, OPC: OPC Unified Architecture for AutomationML. https://opcfoundation.org/developer-tools/specifications-

unified-architecture/opc-unified-architecture-for-

automationml/, 2016. – Zugriff: 12.09.2016

[Fou16e] FOUNDATION, Raspberry P.: Raspberry Pi - Teach, Learn and Make with

Raspberry Pi. https://www.raspberrypi.org/, 2016. – Zugriff:12.09.2016

[Fuc16] FUCHS, Manuel: Zweite Industrielle Revolution. http://www.

globalisierung-fakten.de/industrialisierung/zweite-

industrielle-revolution/, 2016

[GB12] GEISBERGER, Eva ; BOY, Manfred: agendaCPS - Integrierte Forschungs-

agenda Cyber-Physical-Systems. https://www.bmbf.de/files/

acatech_STUDIE_agendaCPS_Web_20120312_superfinal.

pdf, 2012. – Zugriff: 12.09.2016

[Gmb16a] GMBH, 3S-Smart Software S.: CODESYS - Device Directory. http://

devices.codesys.com/device-directory.html, 2016. – Zu-griff: 12.09.2016

139

Kapitel 8. Literaturverzeichnis

[Gmb16b] GMBH, 3S-Smart Software S.: CODESYS - Industrial IEC 61131-3 PLC Pro-

gramming. https://www.codesys.com/, 2016. – Zugriff: 12.09.2016

[Gmb16c] GMBH, 3S-Smart Software S.: CODESYS - OPC UA. https:

//www.codesys.com/products/codesys-runtime/opc-

ua-server.html, 2016. – Zugriff: 12.09.2016

[Gmb16d] GMBH, 3S-Smart Software S.: CODESYS PLCHandler. https:

//www.codesys.com/products/codesys-runtime/

plchandler.html, 2016. – Zugriff: 12.09.2016

[Gmb16e] GMBH, Buxbaum A.: OPC UA Spezifikationen. http://www.

myautomation.at/OPC-u-IT-Integration/OPC-UA/Teil-

4-OPC-UA-Spezifikationen, 2016

[Gmb16f] GMBH, Unified A.: Unified Automation Refernces. https://www.

unified-automation.com/references.html, 2016

[Gro16a] GROUP, EtherCAT T.: EtherCAT Technology Group. https://www.

ethercat.org/default.htm, 2016. – Zugriff: 12.09.2016

[Gro16b] GROUP, FDT: Die FDT Group. http://www.fdtgroup.org/de/

die-fdt-group-wir-ueber-uns, 2016. – Zugriff: 12.09.2016

[Gro16c] GROUP, Khronos: COLLADA - 3D Asset Exchange Schema. https://

www.khronos.org/collada/, 2016. – Zugriff: 12.09.2016

[Gro16d] GROUP, OMG Object M.: DDS Portal - Data Distribution Service. http://portals.omg.org/dds/, 2016. – Zugriff: 12.09.2016

[GRU16a] GRUPPE, TÜV S.: TÜV SÜD GRUPPE - DIN EN 16247 -

Energieaudits. http://www.tuev-sued.de/management-

systeme/energiemanagementsysteme/din-en-16247-

energieaudits, 2016. – Zugriff: 04.10.2016

[GRU16b] GRUPPE, TÜV S.: TÜV SÜD GRUPPE - ISO 50001 Zertifi-

zierung. http://www.tuev-sued.de/management-systeme/

energiemanagementsysteme/iso-50001, 2016. – Zugriff:04.10.2016

140

Kapitel 8. Literaturverzeichnis

[IAF16] IAF, AutomationML e.V. c.: AutomationML. https://www.

automationml.org/o.red.c/home.html, 2016. – Zugriff:12.09.2016

[IBM16] IBM: IBM Connected Car. http://m2m.demos.ibm.com/

connectedCar.html, 2016. – Zugriff: 13.05.2016

[IEC09a] IEC: IEC Webstore - IEC 61360-1:2009. https://webstore.iec.

ch/publication/5380, 2009. – Zugriff: 12.09.2016

[IEC09b] IEC: IEC Webstore - IEC 62453-1:2009. https://webstore.iec.

ch/publication/7040, 2009. – Zugriff: 12.09.2016

[IEC13] IEC: IEC Webstore - IEC 61131-3:2013. https://webstore.iec.

ch/publication/4552, 2013. – Zugriff: 12.09.2016

[IEC14] IEC: IEC Webstore - IEC 61158-1:2014. https://webstore.iec.

ch/publication/4624, 2014. – Zugriff: 12.09.2016

[IEC15a] IEC: IEC Webstore - IEC 62769-1:2015. https://webstore.iec.

ch/publication/22453, 2015. – Zugriff: 12.09.2016

[IEC15b] IEC: IEC Webstore - IEC 62769-5:2015. https://webstore.iec.

ch/publication/22482, 2015. – Zugriff: 12.09.2016

[IEC16a] IEC: IEC 61149 - International Standard for Distributed Systems. http://www.iec61499.de/, 2016. – Zugriff: 12.09.2016

[IEC16b] IEC: IEC Webstore - IEC 62424:2016. https://webstore.iec.ch/publication/25442, 2016. – Zugriff: 12.09.2016

[IEE85] IEEE: 754-1985 - IEEE Standard for Binary Floating-Point Arith-

metic. https://standards.ieee.org/findstds/standard/

754-1985.html, 1985

[Inc16] INC., Free Software F.: GCC, the GNU Compiler Collection. https://

gcc.gnu.org/, 2016. – Zugriff: 12.09.2016

[Ins14] INSTITUTE, MTConnect: MTConnect - DRAFTOverview. http://www.mtconnect.org/docs/overview/, 2014. – Zugriff: 12.09.2016

[Ins16] INSTITUTE, MTConnect: MTConnect. http://www.mtconnect.

org/, 2016. – Zugriff: 12.09.2016

141

Kapitel 8. Literaturverzeichnis

[ISO03a] ISO: ISO 15745-1:2003. http://www.iso.org/iso/catalogue_detail.htm?csnumber=30418, 2003. – Zugriff: 12.09.2016

[ISO03b] ISO: ISO 15745-3:2003. http://www.iso.org/iso/iso_

catalogue/catalogue_tc/catalogue_detail.htm?

csnumber=33820, 2003. – Zugriff: 12.09.2016

[ISO06] ISO: ISO 13399-1:2006. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=36757,2006. – Zugriff: 12.09.2016

[ISO11] ISO: ISO 50001:2011. http://www.iso.org/iso/catalogue_

detail?csnumber=51297, 2011. – Zugriff: 12.09.2016

[ISO12] ISO: ISO/PAS 17506:2012. http://www.iso.org/iso/

catalogue_detail.htm?csnumber=59902, 2012. – Zugriff:12.09.2016

[LIB10] LANGE, Jürgen ; IWANITZ, Frank ; BURKE, Thomas J.: OPC: Von Da-

ta Access bis Unified Architecture. VDE-Verl http://isbnplus.org/9783800732173. – ISBN 9783800732173

[Lic16] LICHTER, Jörg: Digitale Revolution oder Digitale Evoluti-

on? https://www.wko.at/Content.Node/kampagnen/

WirtschaftspolitischeBlaetter/003_Lichter.pdf, 2016

[Ltd16] LTD., Canonical: Ubuntu 16.04.1 LTS Release Notes. https://

wiki.ubuntu.com/XenialXerus/ReleaseNotes, 2016. – Zu-griff: 12.09.2016

[McD16] MCDONOUGH, Ann: OPC Foundation and Object Management Group

(OMG) Announce Cooperative Strategy. http://www.omg.org/news/releases/pr2016/04-13a-16.htm, 2016

[MLD09] MAHNKE, Wolfgang ; LEITNER, Stefan-Helmut ; DAMM, Matthias: OPC

Unified Architecture. 1st. Springer Publishing Company, Incorporated, 2009.– ISBN 3540688986, 9783540688983

[Moo16] MOOLENAAR, Bram: Vim - the ubiquitous text editor. http://www.vim.org/, 2016. – Zugriff: 12.09.2016

[OAS16] OASIS: MQTT. http://mqtt.org, 2016. – Zugriff: 12.09.2016

142

Kapitel 8. Literaturverzeichnis

[Pay16] PAYNE, Jeff: IEC 61131-3: What’s the acceptance rate of this con-

trol programming standard? http://www.controleng.com/

single-article/iec-61131-3-whats-the-acceptance-

rate-of-this-control-programming-standard/

235bfa337c311b8e0dc0386ca3b5590a.html, 2016. – Zugriff:13.06.2016

[PI06] PROCESS INDUSTRIES, NAMUR User A. i.: Current NAMUR Recommen-

dations (NE) and Worksheets (NA). http://www.namur.net/en/

recommendations-and-worksheets/current-nena.html,2006. – Zugriff: 12.09.2016

[PLC16] PLCOPEN: PLCopen XML. http://www.plcopen.org/pages/

tc6_xml/, 2016. – Zugriff: 12.09.2016

[Rö12] RÖSSNER, Willi: Vorlesung: Werkzeugmaschine/NC. http://www.hs-

augsburg.de/~roessner/downloads/vwm06.pdf, 2012. – Zu-griff: 12.09.2016

[Sch56] SCHWERD, F.: Spanende Werkzeugmaschinen: Grundlagen und Konstruk-

tionen. Ein Lehrbuch für Hochschulen, Ingenieurschulen und für die Praxis.Springer https://books.google.ca/books?id=ynTVAAAAMAAJ

[Sch16] SCHNEIDER, Stan: How OPC UA and DDS joined forces.https://blogs.rti.com/2016/04/11/how-opc-ua-and-

dds-joined-forces/, 2016. – Zugriff: 13.05.2016

[Sel11] SELIG, Andreas: Informationsmodell zur funktionalen Typisierung von

Automatisierungsgeräten. http://elib.uni-stuttgart.de/

bitstream/11682/4450/1/Diss_Selig_hs_Verlag.pdf,2011. – Zugriff: 12.09.2016

[SK16] SCHUBERT, K. ; KLEIN, M.: Das Politiklexikon. Dietz, 2016

[Smi05] SMID, Peter: CNC Programming Handbook - 3rd Edition.http://new.industrialpress.com/cnc-programming-

handbook-3rd-edition-ebook-on-cd.html, 2005. – Zugriff:12.09.2016

[Stu16] STUTTGART, Universität: Universität Stuttgart - Institut für Steue-

rungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen -

143

Kapitel 8. Literaturverzeichnis

Mitarbeiter. http://www.isw.uni-stuttgart.de/institut/

mitarbeiter/Keinert/, 2016. – Zugriff: 12.09.2016

[Tie16] TIETZ, Kai: MinGW - Minimalist GNU for Windows. http://www.

mingw.org/, 2016. – Zugriff: 12.09.2016

[Urb13] URBAN, S.: Vorlesung Prozessleittechnik I: Middleware in Automatisie-

rungssystemen. http://docplayer.org/4883751-Fakultaet-

fuer-elektrotechnik-und-informationstechnik-

professur-fuer-prozessleittechnik-middleware-in-

automatisierungssystemen.html, 2013

[Utz05] UTZONBIKE: File:Hexapod general Anim.gif - Wikipedia Com-

mons. https://commons.wikimedia.org/wiki/File:

Hexapod_general_Anim.gif, 2005

[VDI84] VDI: VDI 2852 Blatt 1:1984-10. http://www.beuth.de/de/

technische-regel/vdi-2852-blatt-1/609217, 1984. – Zu-griff: 12.09.2016

[VDI15] VDI: VDI Statusreport - Referenzarchitekturmodell Industrie 4.0 (RA-

MI4.0). https://www.vdi.de/fileadmin/user_upload/VDI-

GMA_Statusreport_Referenzarchitekturmodell-

Industrie40.pdf, 2015. – Zugriff: 12.09.2016

[Wal16] WALSH, Kathy: Plattform Industrie 4.0 and Industrial Internet Consortium

agree on cooperation. http://www.iiconsortium.org/press-

room/03-02-16.htm, 2016. – Zugriff: 13.05.2016

144