Ein offenes Testsystem mit OPC-UA

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

ISH Ingenieursozietät GmbH

NetModule AG

LXinstruments GmbH

Vernetzte Prüf- und Testsysteme müssen miteinander kommunizieren. Doch proprietäre Systeme sind mit Kosten verbunden. Abhilfe verspricht ein standardisiertes Kommunikationsverfahren wie OPC-UA.

Wer in der Messtechnik über Industrie 4.0 redet, meint vor allem vernetzte Anlagen und Maschinen. Entstanden ist der Begriff Industrie 4.0 als ein Marketingbegriff der Forschungsunion der Bundesregierung für eine Forschungsplattform und ein gleichnamiges Projekt in der Hightech-Strategie der Bundesregierung. Mit dem Begriff beschreiben die Projektbeteiligten die Digitalisierung der industriellen Produktion in der gesamten Wertschöpfungskette. Zur Selbstorganisation sollen sogenannte intelligente und vernetzte Kommunikationssysteme eingesetzt werden. Man unterscheidet vier grundlegende Prinzipien, um die Organisation zu gestalten:

• Vernetzung: Maschinen, Geräte, Sensoren und Menschen vernetzen sich und kommunizieren miteinander (Internet der Dinge, Internet der Menschen).

• Informative Transparenz: Zusätzliche Sensordaten erweitern aktuelle Informationssysteme um ein virtuelles Abbild der realen Produktion und Umwelt.

• Technische Assistenz: Assistenzsysteme liefern bedarfsgerechte, verständliche Informationen, um Probleme schneller zu erkennen und richtige Schlüsse zu ziehen. Anstrengende, eintönige oder gefährliche Arbeit wird von Ihnen unterstützt und übernommen.

• Dezentrale Entscheidung: Intelligente (Teil-)Systeme treffen eigenständige Entscheidungen und lösen Aufgaben autonom. Für Zielkonflikte oder übergeordnete Störungen wird ein Eingriff benötigt. Im Ergebnis sollen Selbstkonfiguration, -diagnose und -optimierung für optimierte Fertigungsfähigkeit und Flexibilisierung bis Losgröße eins mit den Vorteilen einer Großserienproduktion kombiniert werden.

Bildergalerie

Um für die wachsende Kommunikation mit oft proprietären Protokollen nicht mit steigenden Entwicklungskosten zu bezahlen, werden standardisierte Verfahren benötigt. Diese müssen auf verschiedenen Ebenen der Automatisierungspyramide (Bild 1) unter Berücksichtigung von Sicherheitsinteressen der Teilnehmer kommunizieren können. Bei der Entwicklung von automatisierten Testabläufen muss außerdem auf Planungssicherheit und Wiederverwendbarkeit geachtet werden. Es stellt sich die Frage: Wie weit hat der Ansatz das tägliche Geschehen bereits durchdrungen und was kann ein Testsystemintegrator zur Zielerreichung beitragen?

Die Automatisierungs-Partner von LXinstruments entwickeln und bauen komplette Produktionslinien oder Handlingsysteme für die Teststationen einer Produktionslinie. Im Unternehmen arbeiten ausnahmslos hierarchisch organisierte SPS- und Linienleitsystem-Kommunikationssysteme. Gespräche mit Firmen der Automatisierungsbranche ergaben, dass sie bei Industrie 4.0 nur über geringe Erfahrungen verfügen. Projekte werden nach Aussagen der Kunden „nur mit zusätzlichem Aufwand und Spezialisten realisiert.“ Auch künftig wurde bis auf weiteres mit einem hohen Anteil zeichenkettenbasierter Kommunikation gerechnet. Um die Testsysteme für Industrie 4.0 weiterzuentwickeln und die vorhergesagten Änderungen vorzubereiten, konnte nicht auf dem noch geringen Erfahrungsschatz unserer Projektpartner aufgebaut werden. Wir suchten nach einem Spezialisten, der näher an der Thematik ist. Hier half das Kompetenzzentrum Mittelstand 4.0 des Fraunhofer IPA in Stuttgart.

Zusammen mit den Spezialisten wurden verfügbare und denkbare Kommunikationstechnologien und Standards verglichen – Herzstück im Umfeld von Industrie 4.0. Es wurden unter anderem Hermes, MTConnect, DDS und OPC-UA in den Vergleich einbezogen. Auf Grundlage des Vergleichs entschieden sich die Verantwortlichen für OPC-UA. Kurz zum Hintergrund OPC UA: OPC-Unified Architecture (OPC UA) ist ein Datenaustauschstandard, der in Zusammenarbeit von Herstellern, Anwendern, Forschungsinstituten und Konsortien spezifiziert wurde, um eine sichere, zuverlässige, hersteller- und plattformunabhängige Kommunikation und betriebssystemübergreifenden Datenaustausch zwischen Produkten unterschiedlicher Hersteller zu ermöglichen.

Monitoring und die Remote-Kommunikation integrieren

Für die weitere Zusammenarbeit mit dem Fraunhofer Institut wurde die Begleitung des Projekts im Rahmen von Workshops vereinbart. Weiter stellte sich die Frage: Wie kann OPC-UA sinnvoll mit dem Operator Interface TSCOE4 von LXinstruments verwendet werden? TSCOE4 bietet für OPC-UA zwei sinnvolle Einsatzmöglichkeiten: Das Monitoring und die Remote-Kommunikation von Zyklusfunktionen für SPS oder Linienleitsysteme. Der System-Monitor von TSCOE4 ist die zentrale Instanz, an der sich ereignis-interessierte Kunden-Plugins anmelden können. Das Monitoring liefert wichtige Informationen über den Zustand des Testsystems und kann von TSCOE4 angezeigt oder aufgezeichnet werden. Mit der Aufzeichnung wird der Anwender beispielsweise beim Suchen und Beheben von Fehlern unterstützt.

Unterliegt das Testsystem beispielsweise einer Temperaturüberwachung, die während einer Geisterschicht den vordefinierten Toleranzbereich verlässt, so liefern MonitorEventSource.Temperature und MonitorEventType.Critical die Ursache für einen drohenden Systemausfall. Mit MonitorData.Text können Informationen über Anfragen und Antworten von SPS-Telegrammen bearbeitet werden. Das Informationsmodell des OPC-UA bietet die Möglichkeit, sich auf grundsätzlich beliebige Daten anzumelden, um sich über Statusänderungen zu informieren. Somit sollte der TSCOE4-Monitor in das OPC-UA-Datenmodell integriert werden.

Das Testsystem über OPC-UA fernsteuern

Neben den Systembefindlichkeiten muss das Testsystem seine Fernsteuerbarkeit über den OPC-UA-Standard offenlegen. Der Leitlinienrechner liefert Informationen über die Produktauswahl und veranlasst direkt oder über die SPS den Teststart. Die SPS benötigt das Testergebnis, um das Produkt im Fehlerfall zu kennzeichnen und aus der Produktlinie auszuleiten. Die Abläufe sind recht unterschiedlich. Im Kern aber wird das DUT ausgewählt, die Seriennummer ermittelt und vorzeitig der Testvorgang gestartet oder beendet. Über das OPC-UA-Informationsmodell lässt sich die Server-Funktionalität offenlegen. Damit war neben dem Monitoring das zweite Arbeitspaket für die Anbindung an OPC-UA definiert. Im nächsten Schritt wurden die Rahmenbedingungen der Realisierung definiert. Dazu musste ermittelt werden, welche Standardbibliotheken in unserer Entwicklungsumgebung verwendet werden können.

Es gibt bereits kommerzielle Produkte, allerdings hängt die gesamte Testsystemsoftware vom Lizenzierungsmodell und der Updatestrategie des Anbieters ab. Um Kosten- und Risikofaktoren zu umgehen, entschieden wir uns für die Bibliothek open62541. Neben open62541 gibt es weitere Open-Source-Bibliotheken, die allerdings aufgrund der .NET Entwicklungsumgebung nicht infrage kamen. Die Bibliothek open62541 basiert auf C, allerdings ist die Anwendung mit C# geschrieben. Ein Wrapper vereint beide Programmiersprachen. Die Bibliothek verarbeitet komplexe Strukturen mit ressourcenschonenden Unions und bietet einen großen Funktionsumfang. Deshalb implementiert der open62541-Wrapper einen für die Realisierung der Anforderungen notwendigen eingeschränkten Funktionssatz. In der Entwicklungsphase wurde der Quellcode für die Anbindung verkürzt, die Speicherverwaltung gekapselt und der objektorientierte Ansatz von C# unterstützt. Entstanden ist das open62541Wrapper.UaModel. Aufrufmethoden, Knoten und Knotentypen ließen sich einfach erstellen, wie das Code-Fragment zeigt:

var methodStatusType = new OpcVariableTypeNode
{
BrowseName = "AsyncMethodStatusType",
Description = "Type of callback function.",
DisplayName = "AsyncMethodStatusType"
};
Server.AddNode(methodStatusType);

Hier entsteht der Variablentyp methodStatusType, der über das Attribut BrowseName identifiziert werden kann und innerhalb des Knotenbaumes mit DisplayName und Description visualisiert wird. Das so erzeugte Objekt wird der Server-Methode Server.AddNode übergeben und kann somit für eine Ableitung eines Variablen-Knotens genutzt werden. Die Entstehung dieser Baumstruktur basiert auf einem Informationsmodell, das im nachfolgenden Abschnitt für unsere Anwendung erläutert wird.

Vor dem eigenen Informationsmodell prüften wir, ob bereits definierte OPC-UA Informationsmodelle (Companion Specifications) nutzbar waren. Das hätte eine deutlich höhere Akzeptanz bei den Schnittstellenpartnern. Es zeigte sich, dass die verfügbaren Spezifikationen Ableitungen aus bereits bestehenden Standards waren und unsere Anforderungen nicht abbildeten.

Entstanden ist ein eigenes Informationsmodell, das sowohl Monitoring als auch Fernsteuerbarkeit eines LXinstruments-Testsystems enthält. Das entwickelte Modell kann als XML-Datei zur Verfügung gestellt werden, um eine Anbindung an unser System zu erleichtern. Im letzten Schritt wurde das Informationsmodell in einem Server-Plugin für OPC-UA implementiert und die Integration in die bestehende TSCOE4-Softwarearchitektur realisiert.

Externer Link: TSCOE4 Operator Interface

* Gunther Marschner ist Leiter der Softwareabteilung der LXinstruments und Roland Blaschke Geschäftsführung LXinstruments in Sindelfingen.

(ID:45555881)