EUMABOIS Version 1.0 rückt in greifbare Nähe

Wie schon in unserem Blog zum Kick-Off der EUMABOIS angekündigt wurde, hat sich die Joint Working Group Woodworking Machines (JWG WWM) nun am 07.02.2020 in Frankfurt bei der VDMA ein weiteres Mal getroffen um die OPC UA Companion Specification für die Holzindustrie voranzubringen. Dabei wurden die Ergebnisse der ersten Arbeitsphase mit dem Schwerpunkt “Kommunikation zwischen Maschine und MES, ERP oder Cloud Systemen” präsentiert und die noch zu lösenden Punkte besprochen.

Warum eine Companion Specification?

Zur Erinnerung: weshalb gibt es die JWG WWM und warum beschäftigt sich diese sich mit dem Thema einer gemeinsamen Sprache für die Holzindustrie?

Die Motivation der JWG WWM für eine Companion Specification besteht darin, dass es ein Standard für Holzverarbeitungsmaschinen geben muss, um die Digitalisierung in der Branche weiterzubringen und dem Endkunden das Betreiben eines heterogenen Maschinenparks zu erleichtern. Es sollen also Anforderungen erfasst werden, um einen gemeinsamen Standard zu definieren und diesen durch ein Plug-and-Play-Framework zu realisieren. Dabei wird insbesondere darauf geachtet das Rad nicht neu zu erfinden, sondern auf den Ergebnissen bestehender Companion Specifications anderer Branchen aufzubauen.

Abbildung 1: Gruppenfoto der JWG © VDMA/Bette 2020

Welche Qualitätsziele soll erreicht werden?

Bei dem Erstellen einer Companion Specification gilt es sich die Frage zustellen, welche Ziele qualitativ erreicht werden sollen. Hierzu wurde die ISO 25010 als internationale Norm für Qualitätskriterien von Software herangezogen, welche folgende 8 Kriterien definiert: Funktionale Eignung, Zuverlässigkeit, Effizienz der Leistung, Bedienbarkeit, Sicherheit, Kompatibilität, Wartbarkeit und Übertragbarkeit.

Aus diesen Kriterien wurden 2 für die EUMABOIS ausgewählt, auf welchen der Schwerpunkt bei der Entwicklung gelegt werden soll: Zum einen liegt der Fokus auf maximaler Kompatibilität  als Grundlage dafür, dass die Companion Specification auch wirklich bei den Herstellern verwendet wird. Muss der Hersteller oder Verwender der Schnittelle immer wieder größere Anpassungen aufgrund mangelnder Kompatibilität vornehmen, wird dies die  Akzeptanz negativ beeinflussen. Der zweite Schwerpunkt ist die Bedienbarkeit, was in diesem Fall bedeutet möglichst ein Plug-and-Play-Framework bereitzustellen, um auch damit die Nutzerakzeptanz zu erhöhen. Natürlich werden auch die anderen Punkte der ISO bei der Entwicklung mit berücksichtigt, jedoch mit nachgestellter Priorität.

Aktueller Stand des Drafts 0.1

Der aktuelle Stand für einen ersten Spezifikationsentwurf wurde durch die Core Working Group (CWG), welche aus den Unternehmen ALTENDORF, BIESSE, BRÜKLE, HOMAG, IMA SCHELLING GROUP, SCM GROUP, WEBER und WEINIG HOLZHER besteht,  erarbeitet und vorgestellt. Die beim letzten Termin vorgestellten Anwendungsfälle, welche durch die Spezifikation abgedeckt sein sollen, wurden in den letzten Monaten um zwei weitere erweitert (WW10, WW11). Damit sind nun die folgenden Anwendungsfälle definiert:

• WW1: Identification of Machines from different Manufacturers
• WW2: Overview of machine states
• WW3: Overview of Errors and warnings
• WW4: Provide information from Key Performance Indicator (KPI) calculations
• WW5: Overview of upcoming manual activities
• WW6: Providing data from media and energy usage statistics
• WW7: Overview of runtime for a job
• WW8: Overview of the parts in a job
• WW9: Job handling
• WW10: Requesting comprehensive tool information
• WW11: Report tool usage

Abbildung 2 zeigt unter Verwendung der OPC UA Notation, wie die Struktur der Companion Specification nach aktuellem Stand aussieht. Maschinen werden mittels MachinesType repräsentiert. Unterhalb dieses Knoten kann ein und dieselbe Maschine mehrmals aufgeführt sein: hat eine CNC-Maschine beispielsweise zusätzlich ein Transportsystem für die Zu- und Abführung von Produktionsmaterialien, so könnte sie beispielsweise einmal als CNC-Maschinentyp und einmal als Transportsystem aufgeführt sein. Jedes Machine-Objekt repräsentiert wiederum eine einzelne Maschine wie z.B. eine CNC Fräse oder eine Plattensäge. Ein MachineType beinhaltet dann Identification, State und Alarm, welche verpflichtend sind, und Manufacturer Specific was optional verwendet werden kann.

Abbildung 2: Struktur des OPC UA Baum

Identification beinhaltet fixe Informationen zu den Maschinen wie z.B. Hersteller, Baujahr und Seriennummer, welche nur gelesen nicht aber geschrieben werden können. Weiterhin befinden sich hier Informationen, die sich während der Verwendung einer Maschine ändern können wie z.B. Standort, Kundennamen etc.

State definiert ein State Model, welches die Zustände einer Maschine definiert und wie sie in einen bestimmten Zustand gelang:

• Standby: Maschine ist an aber noch nicht bereit zu produzieren
• Read: Maschine ist an und bereit zu produzieren
• Working: Maschine führt einen Auftrag aus
• Error: Maschine hat Fehler und benötigt menschlichen Eingriff

Alarm stellt Fehler und Störungen dar, welche mittels Events und Conditions übertragen werden. Hierbei werden die OPC UA Typen verwendet, welche auch Severitys bereitstellen, wie auch die Funktion wann eine Bestätigung erforderlich ist.

Manufacturer Specific bietet Herstellern die Möglichkeit Daten unterschiedlichster Art bereitzustellen. Somit besteht die notwendige Flexibilität Daten über die Schnittstelle bereitzustellen, die nicht in die vorherigen vier Bereiche passen.

Wie kann die JWG nun Anmerkungen einbringen

Abbildung 3 stellt den Ablauf des Entwicklungsprozess dar. Gestartet wird bei den Anwendungsfällen, welche im Fokus stehen sollen. Diese Anforderungen fordern Parameter/ Informationen der Maschinen, die definiert werden, um die Anforderungen erfüllen zu können. Um diese Informationen dann bereitstellen zu können, werden diese mittels OPC UA Modellierungsprinzipien und Regeln in  ein “Information Model” überführt, welches verschiedene Informationen darstellt, z.B. welche Daten über OPC UA Typen, Objekte oder Methoden verfügbar sind. Die Total Working Group (TWG) kann sich nun den entstandenen Entwurf anschauen und Verbesserungen vorschlagen. Diese werden dann wiederum von dem Core Team geprüft und eingearbeitet.

Abbildung 3: Ablauf des Entwicklungsprozess der JWG

Wie geht es nun weiter

Im nächsten Schritt wird das Feedback der JWG zum Draft 0.1 eingearbeitet. Parallel dazu wird an den weiteren Anwendungsfällen gearbeitet. Aktuell geplant ist darüber hinaus in Q3 2020 das Thema Harmonisierung zu adressieren, welches vermutlich nicht oder nur teilweise in der Version 1.0 der Spezifikation vorhanden sein wird. Noch nicht klar zu dem heutigen Zeitpunkt ist, ob die neu hinzugefügten Anwendungsfälle “WW10: Requesting comprehensive tool information” und “WW11: Report tool usage” in der ersten Version mit abgedeckt sein werden, da hier viel Abstimmung mit Dritten notwendig ist. Geplant ist eine Version 1.0 der EUMABOIS am Ende des Jahres 2020 zu veröffentlichen.

Weitere Informationen zu OPC UA finden Sie auch in unserer Blogserie „IoT zum Anfassen“:

• IoT zum Anfassen – OPC UA
• IoT zum Anfassen – OPC UA Companion Specification

Wenn Sie weitere Fragen zu OPC UA haben oder Unterstützung bei der Umsetzung Ihrer OPC UA Lösungen suchen, dann können Sie uns gerne kontaktieren: [email protected]