SECS/GEM in Maschinen integrieren und Mehrwert für Ihre Kunden steigern

Sie überlegen eine Ihrer Anlagen für den Einsatz mit SECS/GEM fit zu machen?

Oder einer Ihrer Kunden fordert für den nächsten Auftrag, dass Sie auch SECS/GEM als Möglichkeit anbieten?

Auch wenn SECS/GEM vielfach schon als überholt gilt, so gibt es genug Projekte, wo Sie um diese Schnittstelle nicht herumkommen. Mit der Integration eines solchen Standards erhält Ihre Maschine eine Aufwertung und es ergeben sich neue Auftragsmöglichkeiten. Je nach Branche sind bestimmte Industrieprotokolle mehr oder weniger verbreitet. Speziell in der Herstellung von Halbleitern geht es ohne SECS/GEM (fast) nicht. Aber auch in verwandten Branchen, wie z.B. bei der Herstellung von Leiterplatten, ist der SECS/GEM Standard verbreitet.

Was ist SECS/GEM eigentlich?

Wagen wir einen kurzen Blick in die Technik von SECS/GEM. Auch schon bevor es die aktuelleren Technologien wie etwa Web Services oder OPC UA gegeben hat, war der Bedarf der Integration und Anbindung von Maschinen an IT-Systeme gegeben. Sicher nicht so zentral und wichtig wie im Moment, aber doch war es notwendig Kommunikationsprotokolle für M2M zu entwickeln. Wie es zu frühen Zeiten der IT üblich war, sind die ersten dieser Protokolle auf einer seriellen Datenübertragung als Basis entstanden.

Ursprünglich basierte SECS/GEM auf serieller Übertragung

Technologien wie RS232 oder RS485 waren und sind in vielen Bereichen nach wie vor Standards. Auch SES/GEM wurde vor den Zeiten von TCP/IP als serielle Übertragung spezifiziert. Der sogenannte SEMI E04 SECS I Standard legt diese Art der Datenübertragung fest.

Dass damit in einer aktuellen Systemumgebung nicht mehr gearbeitet werden sollte, liegt auf der Hand. Bei einer modernen Maschinenanbindung, sind je nach Umfang und Art (Einzelmaschine oder ganze Maschinenlinie) und je nach Aufbau, vielleicht sogar ein eigenes Maschinennetzwerk vorhanden. Damit die GEM Messages über TCP/IP übertragen werden können, gibt es den SEMI E37 HSMS Standard. Dieser legt den Kommunikationsfluss der GEM Nachrichten über ein Netzwerk basierend auf TCP/IP fest.

SECS/GEM Kommunikation und Protokollstack

Im SECS/GEM Standard sind die beiden Kommunikationspartner als Host (z.B. ein MES) und Equipment (die Maschine) beschrieben. Dabei steuert der Host den Ablauf der Maschine. Die Maschine liefert an den Host die Daten in Form von Variablen und Events.

SECS/GEM umfasst bei jeder Implementierung mehrere SEMI Standards

Wie der Name SECS/GEM schon vermuten lässt, handelt es sich dabei eigentlich um eine Kombination von mehreren Standards. Die Ebenen bauen aufeinander auf und stellen dabei Funktionen für die nächsthöhere Ebene bereit. So wie es auch aus dem OSI 7-Schichten Modell bekannt ist. Bei SECS/GEM sind in der Regel 3 Ebenen in Verwendung. Jede Ebene wird in einem eigenen SEMI Standard definiert.

Auf Ebene der Datenübertragung muss aus einem der möglichen Standards gewählt werden, je nachdem welche Übertragungstechnologie eingesetzt wird:

  • SEMI E4 für RS232 / RS485 basierte Übertragung
  • SEMI E37 für TCP/IP basierte Übertragung

Nachrichten, Streams und Funktionen

Die mittlere Ebene wird abgebildet im SEMI E5 SECS II Standard und beschreibt die vorhandenen Nachrichten und deren Inhalt. Diese Ebene stellt die Basis aller übermittelbaren Inhalte dar. Dabei sind die einzelnen Nachrichten in sogenannte Streams gruppiert. Ein Stream fasst alle Nachrichten einer Kategorie zusammen.

Jeder Stream besteht wiederrum aus einer Reihe von Funktionen. Eine Funktion ist eine spezielle Message für eine bestimmte Aktivität. Dabei wird nochmals zwischen Primary und Secondary Messages unterschieden. Eine Primary Message ist eine Anfrage von Equipment an den Host oder umgekehrt. Eine Secondary Message ist der Response auf eine Primary Message.

SECS II definiert in 21 verschiedenen Streams alle möglichen Messages und deren Abfolge sowie deren Bedeutung und deren möglichen Inhalt.

Z.B. werden im Stream S10 Terminal Services definiert. Bei Terminal Services handelt es sich um Textnachrichten zwischen dem Bediener an der Maschine und dem Host. Damit können Infos vom Host an den Operator oder umgekehrt geschickt werden. Die empfangenen Nachrichten müssen vom Bediener bestätigt werden.

Eine der Funktionen aus dem Stream S10 ist z.B. S10,F1 Terminal Request (TRN). Die Message wird von der Maschine an den Host gesendet und enthält einen Text mit dem Inhalt der Nachricht.

State Models und Equipment Capabilities

Die oberste Ebene wird im SEMI E30 GEM Standard abgebildet und setzt die Streams und Funktionen ein, um Prozesse und Verhalten der Maschine zu definieren. Der E30 Standard definiert dazu auch exakt, welche State Models implementiert sein müssen und wie der genaue Ablauf sein muss. So gibt es z.B. ein State Model für den Communication State, wo der Vorgang zum Aufbau einer Verbindung des Host oder von der Maschine beschrieben ist. Darin ist genau geregelt, welcher Teilnehmer zu welchem Zeitpunkt eine Verbindung aufbauen darf, welche Timeouts eingehalten werden müssen und was nach einem erfolgreichen Verbindungsaufbau geschehen soll.

Neben den Zustandsmodellen sind in dieser Ebene beschrieben, wie die Capabilities (Funktionen) der Maschine vom Host aus aufgerufen werden können. Darunter fallen z.B. wie Dynamic Event Reports definiert werden oder wie Data Collections bearbeitet werden können.

In welche Standards soll ich mich einarbeiten?

Zur Einarbeitung in ein neues Projekt sollten in der Regel der E30 und der E5 Standard ausreichend sein. Wenn eine SECS/GEM Library eingesetzt wird, sollte in vielen Fällen auch nur der E30 Standard ausreichend sein. Da eine Library den kompletten E5 und E30 Standard bereits umgesetzt hat und für die Umsetzung API Calls oder Callbacks bereitstellt. Für das allgemeine Verständnis und eine kompetente Kommunikation mit dem Kunden zur Klärung von Fragen, hat sich der E5 und E30 Standard als nützlich erwiesen.

Aber mit OPC UA kann das viel einfacher gemacht werden

Statt SECS/GEM könnte auch OPC UA eingesetzt werden, das mag auf den ersten Blick einfacher und vielleicht auch kostengünstiger erscheinen. Bei OPC UA müssen keine Standards gekauft werden und es gibt genügend Bibliotheken für die Kommunikation per OPC UA (auch in einer freien Lizenz). Das ist alles richtig.

Allerdings sind bei SECS/GEM im Vergleich zu OPC UA mehr Definitionen rund um den Prozess- und Kommunikationsablauf vorhanden. Bei OPC UA gibt es üblicherweise eine Reihe an Variablen und Funktionen. Die Funktionen können aufgerufen werden und somit auf der Maschine Vorgänge ausgelöst werden. Wann genau eine Funktion ausgelöst werden darf oder in welcher Reihenfolge ist nicht definiert.

Hingegen bei SECS/GEM sind mit den State Models die Vorgänge weitgehend festgelegt. Die Zustände in den State Models können nur anhand festgelegter Transitions gewechselt werden. Die Steuerung der Maschine ergibt sich damit aus den SEMI Standards und dem SECS/GEM Manual (muss vom Equipmenthersteller, also vom Maschinenbauer, definiert und mitgeliefert werden). Eine Abweichung von den State Models ist nicht zulässig und wird vom Equipment schlichtweg abgelehnt.

Soll ich eine SECS/GEM Library einsetzen?

Das kommt darauf an. Wenn Sie bei einem Projekt SECS/GEM zügig implementieren wollen und die Stückzahlen der ausgelieferten Installationen eine überschaubare Anzahl sein werden, dann auf alle Fälle ja. Üblicherweise werden die Libraries mit einer einmaligen SDK Lizenz und einer Runtime Lizenz pro Maschine bzw. Installation angeboten. Wenn die Stückzahlen der Installationen entsprechend groß werden, kann es sich aber auch lohnen z.B. die E30 Ebene selbst zu implementieren.

In der Regel gilt aber die Empfehlung auf eine ausgereifte SECS/GEM Library zurückzugreifen. Wichtig bei der Entscheidung ist auch die Qualität und die Schnelligkeit des Supports. Beim ersten Rollout sind mit großer Wahrscheinlichkeit noch technische Klärungen notwendig. Häufig ist gibt es auch Anlaufschwierigkeiten beim Verbindungsaufbau mit der Gegenseite. Und obwohl bei SECS/GEM jedes Detail beschrieben ist, halten sich nicht alle Implementierungen an den Standard (besonders wenn die Gegenseite keine Library einsetzt).

Fazit

SECS/GEM ist noch lange nicht outdated. Bei vielen Projekten oder Maschinen wird es vom Kunden erwartet diese Schnittstelle anzubieten. Wenn Sie bis dato noch keine Implementierung umgesetzt haben, ist der Einsatz einer Bibliothek der einfachere Weg.