Herr Keinert, was genau gab den Ausschlag, das Projekt 'HMI OPC-UA Schnittstelle' zu starten?

Die meisten Werkzeug­maschinenbauer bieten ihre Maschinen aufgrund von Kundenanforderungen mit Steuerungen unterschiedlicher Hersteller an. Da im Bereich der CNC-Steuerungen jedoch herstellerspezifische Schnittstellen dominieren, müssen die Werkzeugmaschinenbauer eigene Bedienoberflächen, OEM-Anwendungen und Erweiterungen der zur Steuerung gehörigen Standardbedienoberfläche jeweils an die herstellerspezifischen Protokolle anpassen. Dies ist mit hohem Zusatzaufwand verbunden.

Eine Standardisierung der Kommunikation zwischen CNC-Steuerung und den genannten Anwendungen würde zu erhöhter Flexibilität, zur Verschlankung der Entwicklung und zur Reduktion der Softwarekomplexität führen. Und mit OPC UA sind hierfür die besten Voraussetzungen gegeben, da OPC UA die Möglichkeit bietet, anwendungsfallspezifische Informationsmodelle zu spezifizieren. Zudem ist hier die unterlagerte Kommunikation unter anderem hinsichtlich Performanz, Sicherheit und Plattformunabhängigkeit sehr gut durchdacht. Mit dem VDW haben wir schließlich die ideale Plattform, um ein solches Projekt durchzuführen, da hier Werkzeugmaschinenhersteller und auch Steuerungsanbieter an einem Tisch sitzen.

Sind Sie mittlerweile zu einer Lösung gekommen?

Lassen Sie mich zunächst einen kurzen Blick zurückwerfen. Ursprünglich sind wir ja mit der Intention gestartet, eine HMI-Schnittstelle zu ­entwerfen. Es hat sich dann aber schnell gezeigt, dass wir uns nicht auf HMI-Anwendungen beschränken dürfen, sondern vielmehr eine allgemeingültige CNC-Schnittstelle sinnvoll ist, auf die alle der Steuerung überlagerten Anwendungen zugreifen können.

Im Rahmen des Projekts haben wir dementsprechend ein OPC-UA-Informationsmodell erarbeitet, welches in der jetzt vorliegenden ersten Version grundlegende Daten und Mechanismen einer CNC-Schnittstelle bereitstellt. Hierfür wurden Objekte definiert – zum Beispiel Achs-, Spindel- und Kanal­objekte –, die spezifische Daten bereitstellen. Darüber hinaus stellt das Informationsmodell Alarm-Mechanismen zur Verfügung sowie Events, um einer Applikation beispielsweise mitzuteilen, wenn eine Achse ihre Kanalzugehörigkeit geändert hat.

Was genau geschieht nun mit Ihren Arbeitsergebnissen?

Oberstes Ziel des Forschungsprojektes war es, zu einer Lösung zu kommen, die breite Anwendung finden kann. Aus diesem Grund war es uns ein Anliegen, nicht nur für die Mitglieder des Projektes eine Lösung zu erarbeiten, sondern diese allen interessierten Anwendern zur Verfügung zu stellen. Die beste Möglichkeit, um dies zu erreichen, ist die direkte Verankerung dieser Schnittstellen-Spezifikation im OPC-UA-Standard. Dies kann über sogenannte ‚Companion Specifications‘ erfolgen.

Die Arbeiten an der in Kooperation mit der OPC Foundation erstellten Spezifikation sind größtenteils abgeschlossen. Derzeit sind wir noch mit dem Feinschliff beschäftigt sowie mit der abschließenden Validierung der Lösung. Ende März wird es einen 'Release Candidate' der Companion Specification geben, welcher der OPC Founda­tion zur Kommentierung vorgelegt wird. Parallel dazu erfolgt das Proto­typing bei den am Forschungsprojekt beteiligten Firmen.

Im Herbst – so hoffen wir – kann die Companion Specification dann offiziell herausgeben werden. Da im Rahmen des Projekts konkrete Anwendungsfälle Berücksichtigung finden und das Prototyping miteinbezogen wird, hoffen wir auch, dass die Schnittstelle zeitnah in CNC-Steuerungen Einzug hält. Sicherlich ist die Integration in die Steuerung mit Aufwand verbunden: Im einfachsten Fall gilt es nur ein Datenmapping zu realisieren. Zur Umsetzung der Alarm- und Event-Mechanismen ist aber mehr notwendig. Dennoch ist der Zeitpunkt gut, da OPC UA im Automatisierungsbereich und auch bei den CNC-Steuerungsherstellern aktuell eine starke Verbreitung findet und eine Umsetzung des Informationsmodells dann direkt erfolgen kann.

Inwiefern unterstützen die Steuerungshersteller das Konzept bereits?

Wie bereits erwähnt, haben wir die Schnittstelle ja in Zusammenarbeit mit Werkzeugmaschinen- und Steuerungsherstellern erarbeitet. Aktiv beteiligt sind beispielsweise Bosch Rexroth und Siemens. Es haben jedoch auch andere Firmen, die nicht VDW-Mitglied sind, Interesse gezeigt. Nicht zuletzt haben wir unter anderem auf dem OPC Day Europe im ver­gangenen Jahr Zuspruch erhalten, als wir dort unser Projektvorhaben vor­gestellt hatten.­

Wäre es nicht denkbar und sinnvoll, das Konzept generell auf die hersteller­unabhängige Kommunikation mit Steuerungen – also zum Beispiel auch von SPSen – auszudehnen?

Im Projekt haben wir uns Rohdaten fokussiert, die ihren Ursprung in der CNC-Steuerung haben. Demnach werden aktuell keine SPS-Daten oder verdichtete Daten bereitgestellt.

Eine Ausweitung dieses Ansatzes auf Anlagensteuerungen ist sicherlich schwierig, da hier sehr unterschiedliche, von Anlage zu Anlage wechselnde Daten bereitzustellen sind. Diesbezüglich kann man sich eher auf die PLCopen Companion Specification stützen.

Nichtsdestotrotz wird man sich in den weiteren Versionen unserer Companion-Spezifikationen für die CNC-Datenschnittstelle auch SPS-Daten ansehen müssen, da eine CNC-Steuerung in der Regel nun einmal zusammen mit einer SPS betrieben wird.

Im Zusammenhang mit der Interoperabilität von Werkzeugmaschinen und Fertigungssoftware fällt in jüngster Zeit immer öfter das Stichwort MTConnect – ein offener Kommunikationsstandard, der in den USA seinen Ursprung hat. Wie beurteilen Sie diesen beziehungsweise sehen Sie darin eine ernsthafte Konkurrenz zu der von Ihnen entwickelten Lösung?

Wir haben uns MTConnect im Rahmen der Arbeiten an der Companion Specification angesehen. Mit MTConnect besteht analog zu unserem ­Ansatz die Möglichkeit, hersteller­übergreifend auf Werkzeugmaschinen zuzugreifen. Auch liefert MTConnect teils umfangreiche Datenmodelle. Ich sehe jedoch auch einige große Nach­teile in dem Konzept. So sind beispielsweise die Datenmodelle gerade für CNC-Steuerungen nicht detailliert genug. Die Abwicklung der Kommunikation über http im Vergleich zur ­binären Datenübertragung mittels OPC UA sehe ich ebenfalls kritisch. Eine große Stärke von OPC UA ist die ­getrennte Behandlung der Kommunikationsschicht und der anwendungsfallspezifischen Informationsmodelle, weshalb wir uns auch für diesen Ansatz entschieden haben.

Fakt ist jedoch, dass namhafte Steuerungshersteller wie etwa Siemens und Rexroth oder auch NUM die Schnittstelle MTConnect unterstützen beziehungsweise die entsprechende Schnittstelle integriert haben!

Wenn die entsprechenden Kundenanfragen vor allem aus dem US-amerikanischen Markt kommen, können die Hersteller diese natürlich nicht ignorieren. Mein Eindruck ist jedoch, dass MTConnect bei den CNC-Her­stellern nicht als das Nonplusultra gilt. Vielmehr ist OPC UA aktuell in ­aller Munde und auch die Hersteller von CNC-Steuerungen setzen diese Schnittstelle um – teilweise als die ­native Steuerungsschnittstelle, wie ­beispielsweise Bosch Rexroth, teil­weise als Add-on, wie etwa bei Siemens oder Beckhoff.

Als ein Manko von MTConnect wird immer wieder angeführt, dass es sich dabei lediglich um eine unidirektionale Schnittstelle handelt und somit kein schreibender Zugriff auf die Steuerung möglich ist. Halten Sie es für denkbar – beziehungsweise auch technisch machbar – MTConntect zu einer bidirektionalen Schnittstelle weiterzuentwickeln?

Technisch machbar ist das sicherlich. MTConnect hat ja das Konzept der Adapter, welche auf  entsprechende Daten der ­Steuerung zugreifen. Diesen Adapter auch für Schreibzugriffe zu nutzen, ist bestimmt möglich. Allerdings ­werden wir aufgrund der bereits ­genannten Mecha­nismen und Eigenschaften – Kommunikationssicherheit, Performanz, Informationsmo­dellierung – weiterhin auf OPC UA setzen.

NUM setzt auf MTConnect

NUMConnect ist vollständig mit der neuesten Version 1.3.0 des Standards MTConnect kompatibel und steht für neue Systeme oder als Nachrüstoption für die CNC-Systeme Axium, Flexium und Flexium+ sowie für die frühere Serie Power 1000 zur Verfügung.

© NUM

Einer der CNC-Anbieter, die MTConnect als Schnittstelle zwischen Werkzeugmaschine und Fertigungssoftware proklamieren, ist die im schweizerischen Teufen ansässige Firma NUM. Sie wird künftig von allen Steuerungen des Herstellers unterstützt.

MTConnect ist ein offener und lizenzfreier Kommunikationsstandard, der vom MTConnect Institute verwaltet wird. Die dem Standard zugrundeliegende Technologie basiert auf XML (Extensible Markup Language), wobei das Format sämtlicher Datenübertragungen durch HTTP (Hypertext Transfer Protocol) definiert wird. Die CNC-Systeme mit offener Architektur von NUM verwenden bereits eine ähnliche Softwaretechnologie für ihre Bedienoberfläche, die auf HTML und JavaScript beruht und Standard-Serverfunktionen zur Unterstützung des Datenaustauschs zwischen dem CNC-Kern, PLC, Antrieben und Motoren verwendet. Folglich kann NUMConnect alles lesen, was auf der Bedienoberfläche des CNC-Systems angezeigt werden kann, unabhängig davon, ob es im analogen oder digitalen Format vorliegt. Selbst detaillierte Maschinendaten, wie Fehlermeldungen des Motors, des Antriebs oder des Gebers, sind  abrufbar und lassen sich zur Überwachung der Maschinenleistung, für vorbeugende Wartung und zu Diagnosezwecken verwenden.

Erstmals hat die Firma NUM die Schnittstelle im Jahr 2008 bei ihrer Axium-Produktlinie eingeführt. Nun macht das Unternehmen MTConnect als Option für seine gesamten CNC-Systeme verfügbar. Das von der NUM Corporation in den USA entwickelte NUM­Connect ist vollständig mit der neuesten Version 1.3.0 des Standards MTConnect kompatibel und steht für neue Systeme oder als Nachrüst-Option für die CNC-Systeme Axium, Flexium und Flexium+ sowie für die frühere Serie Power 1000 zur Verfügung. Die Software ist auf jedem Standard-PC unter Windows XP oder aktueller installierbar und wird im Hintergrund aller Industrie-PC-Konsolen von NUM ausgeführt.

Die Softwareschnittstelle besteht im Wesentlichen aus zwei Hauptkomponenten: einem MTConnect-Adapter und einem MTConnect-kompatiblen Informationslieferanten beziehungsweise einem als 'Agent' bezeichneten schlanken Webserver. Der Adapter sammelt Daten aus dem CNC-System, verknüpft sie mit den definierten MTConnect-Daten-Elementen, filtert Datenduplikate aus und sendet die Daten dann an den Agenten, wo sie in einem Pufferspeicher verbleiben, bis sie mit neuen Informationen überschrieben werden. Um die Reaktionszeiten zu minimieren, erfordert MTConnect nicht die Herstellung einer formellen Datenübertragungssitzung und im normalen Betrieb gibt es keine Anmelde- oder Abmeldesequenzen. Wenn der Agent eine Informationsanforderung von einer Client-Software-Anwendung erhält, überträgt er die entsprechenden Daten mithilfe von HTTP über das Netzwerk.