+43 2757 24131
info@x-works.atDu überlegst eine Deiner Anlagen für den Einsatz mit SECS/GEM fit zu machen?
Oder einer Deiner Kunden fordert für den nächsten Auftrag, dass Du auch SECS/GEM als Möglichkeit anbietest?
Auch wenn SECS/GEM vielfach schon als überholt gilt, so gibt es genug Projekte, wo Du um diese Schnittstelle nicht herumkommst. Mit der Integration eines solchen Standards erhält Deine 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.
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.
State Models und Equipment Capabilities
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 es in vielen Fällen genügen, sich nur den E30 Standard im Detail anzusehehen. 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.
Soll ich eine SECS/GEM Library einsetzen?
Das kommt darauf an. Wenn Du bei einem Projekt SECS/GEM zügig implementieren willst 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).
Weitere SEMI Standards
Die beiden angesprochenen SEMI Standards E5 und E30 sind nur ein kleiner Teil der Möglichkeiten. E5 und E30 decken sozusagen den Einstieg in SECS/GEM ab. Damit kann die Kommunikation zwischen Host und Equipment hergestellt werden und Daten sowie Remote Commands ausgetauscht werden. Wenn darüber hinaus weitere Features integriert werden sollen, adressiert SECS/GEM dies mit einer Reihe darauf aufbauender Standards, wie unter anderem:
- E87 Spezifikation für Carrier Management
- E90 Spezifikation für Substrate Tracking
- E94 Spezifikation für Control Job Management
- E116 Spezifikation für Equipment Performance Tracking
- E148 Spezifikation für Time Synchronization
- E157 Spezifikation für Module Process Tracking
Fazit
SECS/GEM ist noch lange nicht outdated, ganz im Gegenteil. Aus den aktuellen Trends bei unseren Projekten sehen wir, dass immer mehr Unternehmen auf SECS/GEM setzen und die Vorteile einer klar strukturierten Kommunikation erkennen. Bei vielen Projekten oder Maschinen wird es vom Kunden sogar erwartet diese Schnittstelle anzubieten. Wenn Du bis dato noch keine Implementierung umgesetzt hast, ist der Einsatz einer Bibliothek der einfachere Weg.
