Wer Software zur Anlagensteuerung für eine Fabrik oder ein OSAT-System entwickelt, stößt früher oder später auf dasselbe Problem: Die Maschine muss mit dem Host kommunizieren, und zwar über SECS/GEM. Für Teams, die standardmäßig mit C#/.NET arbeiten, stellt sich daher schnell weniger die Frage „Sollen wir das entwickeln?“, sondern vielmehr „Welches SDK verwenden wir?“.

Dieser Leitfaden erläutert, worauf es bei der Bewertung eines C#/.NET SECS/GEM SDKs wirklich ankommt , welche Abwägungen zwischen Eigenentwicklung und Kauf für OEMs relevant sind und wie man einen Anbieter in die engere Auswahl nimmt, ohne Monate mit einem Machbarkeitsnachweis zu verschwenden, der zu nichts führt.

Warum SECS/GEM immer noch Probleme für Gerätehersteller verursacht

SECS/GEM (SEMI E30, basierend auf SECS-II/E5 und HSMS/E37) ist kein schwer zu beschreibendes Protokoll. Schwieriger ist es jedoch, es korrekt zu implementieren, da es bei der Konformität nicht primär um das Parsen von Nachrichten geht, sondern vielmehr um das Verhalten der Zustandsmaschine. Die korrekte Implementierung des GEM-Zustandsmodells (Gerätezustände, Steuerungszustände, Kommunikationszustände, Ereignis-/Alarm-/Berichtsverarbeitung, Fernbefehle) ist der Knackpunkt, an dem die meisten Eigenentwicklungen scheitern.

Für einen OEM äußert sich dies in einigen wiederkehrenden Problemen:

  • Compliance-Risiko. Halbleiterhersteller fordern zunehmend die Einhaltung der SEMI-Normen E30/E37/E4/E5, bevor die Anlagen überhaupt in Betrieb genommen werden. Eine intern entwickelte Lösung, die „größtenteils funktioniert“, kann bei der Abnahmeprüfung vor Ort beim Kunden durchfallen.
  • Opportunitätskosten im Engineering. Jeder Monat, der für SECS/GEM-Verrohrung aufgewendet wird, ist ein Monat, der nicht für die eigentliche, differenzierende Logik der Anlagen – Prozesssteuerung, Bewegungsabläufe, Rezeptausführung – zur Verfügung steht.
  • Wartungsaufwand. SECS/GEM ist nicht statisch. GEM300 (E40, E87, E90, E94, E116) erhöht die Komplexität der 300-mm-Fabrikintegration erheblich, und die Anforderungen auf der Hostseite entwickeln sich je nach Kunde weiter.
  • Fragmentiertes Fachwissen. SECS/GEM-Kenntnisse sind ein enges Spezialgebiet. Verlässt der einzige Entwickler, der die Zustandsmaschine versteht, das Unternehmen, wird die Codebasis zu einer Belastung.

Aus diesem Grund evaluieren die meisten Gerätehersteller – selbst solche mit starken internen Softwareteams – letztendlich eine kommerzielle SECS/GEM-API oder ein SDK, anstatt einen maßgeschneiderten Stack auf unbestimmte Zeit zu pflegen.

Wem diese Entscheidung üblicherweise zufällt

Die Entscheidung für das SECS/GEM SDK obliegt selten einer einzelnen Rolle. In den meisten OEM-Organisationen betrifft sie:

  • Automatisierungsingenieure und Embedded-Software-Ingenieure, die Eigentümer des Gerätesteuerungscodes sind und tagtäglich mit der API arbeiten müssen.
  • Architekten für Fabrikautomatisierung die die Integrationsarchitektur benötigen, um den gesamten Software-Stack der Ausrüstung abzudecken, nicht nur ein einzelnes Werkzeug.
  • MES-Integrationsingenieure, Für diejenigen, denen es besonders wichtig ist, wie reibungslos die Implementierung auf der Geräteseite mit dem Fabrik-Host kommuniziert – denn eine schlecht funktionierende GEM-Zustandsmaschine auf der Geräteseite wird später zu einem Supportfall.
  • Engineering-Manager und CTOs, die letztendlich die Vor- und Nachteile von Eigenbau und Fremdbezug unter Berücksichtigung von Zeitplan, Budget und langfristiger Instandhaltung abwägen.

Wenn Sie dies in einer dieser Rollen lesen, sind die folgenden Abschnitte so aufgebaut, dass jeder Beteiligte das findet, was er braucht: technische Bewertungskriterien für die Ingenieure, die die Implementierung durchführen, und ein Build-vs.-Buy-Framework sowie eine Anbieterübersicht für die Personen, die die Entscheidung genehmigen.

Worauf Sie bei einem C#/.NET SECS/GEM SDK achten sollten

Nicht alle SECS/GEM C#-Bibliotheken sind gleich aufgebaut, und die Unterschiede werden besonders relevant, sobald man die Demophase hinter sich gelassen hat. Hier sind die Kriterien, die ein nutzbares SDK von einem unterscheiden, das sich stillschweigend zu einem eigenen Wartungsprojekt entwickelt.

1. Echte Einhaltung der SEMI-Standards

Achten Sie auf die explizite Konformität mit SEMI E30 (GEM) , E5 (SECS-II) , E4 (SECS-I) und E37 (HSMS) – nicht nur auf die Angabe „SECS/GEM-Unterstützung“ in Marketingtexten. Wenn Sie 300-mm-Fertigungsanlagen anvisieren, muss die GEM300-SDK-Funktionalität (E40, E87, E90, E94, E116) Teil der Roadmap sein oder bereits verfügbar sein.

2. Native C#/.NET-Implementierung (Kein Wrapper)

Eine echte .NET-native SECS/GEM-Bibliothek bietet Ihnen verwaltete Speicherverwaltung, Unterstützung für async/await-Nachrichtenflüsse und eine Integration, die sich wie normales C# anfühlt, anstatt mit einer C++-Interop-Schicht oder COM+-Marshalling zu kämpfen. Eingebundene oder überbrückte Bibliotheken neigen dazu, Komplexität genau dort in Ihren Code zurückfließen zu lassen, wo Sie sie eigentlich vermeiden wollten.

3. API-Ergonomie

Die besten SECS/GEM-APIs stellen Konzepte – Ereignisse, Alarme, Fernbefehle, Datenerfassungspläne – über klare und verständliche Methoden bereit, anstatt dass Ihr Team Stream-Function-Nachrichtenstrukturen (SF) manuell erstellen muss. Dies ist besonders wichtig für Teams ohne dedizierten SECS/GEM-Spezialisten, da es die Anforderungen an das Fachwissen für die tägliche Entwicklung deutlich senkt. Einige Anbieter gehen noch einen Schritt weiter und bieten visuelle Konfigurationstools zur Definition von GEM-Diensten und Datenelementen an, wodurch die Einarbeitung neuer Entwickler in das Protokoll erheblich beschleunigt wird.

4. Flexibilität der Integrationsarchitektur

Die Softwarearchitekturen von Geräten variieren stark. Ein gutes SDK sollte mehrere Integrationsmuster unterstützen:

  • Eingebettet in denselben Prozess wie Ihre Gerätesteuerung (engste Integration, voller Quellzugriff)
  • Ausführung als separater Prozess auf demselben PC (bessere Isolation, minimale Änderungen am bestehenden Controller-Code)
  • Läuft auf einem dedizierten PC innerhalb der Anlage (für ressourcenbeschränkte Controller)
  • Eine REST-API- oder gRPC-Schicht für Teams, die SECS/GEM-Funktionalität benötigen, ohne ein natives SDK einzubetten.

Wenn ein SDK nur eine Architektur unterstützt, ist es möglicherweise nicht mit Geräten kompatibel, die Sie noch nicht entworfen haben.

5. Plattform- und sprachübergreifende Reichweite

Windows dominiert zwar weiterhin die Anlagen in der Fertigungshalle, doch Linux und sogar Controller der Raspberry-Pi-Klasse werden auf neueren Plattformen immer häufiger eingesetzt. Wenn in Ihrem Unternehmen gemischte Teams arbeiten oder älterer Code in anderen Sprachen vorliegt, prüfen Sie, ob derselbe Anbieter neben der .NET-Bibliothek auch Bindungen für C++, Java, Python oder Delphi anbietet. Dies verringert das Risiko, zwei unabhängige Toolchains für dasselbe Protokoll pflegen zu müssen.

6. GEM300 und Wachstumspfad

Selbst wenn Ihre aktuellen Werkzeuge der 200-mm-Klasse angehören, fragen Sie nach, ob der Anbieter einen klaren Upgrade-Pfad zur GEM300-Unterstützung bietet. Die nachträgliche Integration von GEM300 in ein SDK, das nicht dafür ausgelegt ist, ist deutlich aufwendiger als die Verwendung eines SDKs, das bereits das erweiterte Objektmodell enthält.

7. Test- und Simulationswerkzeuge

Ein integrierter SECS/GEM-Simulator – mit dem man Ereignisberichte, Alarme und Fernbefehle ohne Live-Host-Verbindung testen kann – verkürzt die Entwicklungs- und Debugging-Zyklen erheblich, insbesondere für Teams, die keinen einfachen Zugang zu einem Fab-Host für Tests haben.

8. Echter Support, nicht nur Dokumentation

SECS/GEM-Probleme treten häufig während der Kundenabnahmetests auf – also genau dann, wenn am wenigsten Zeit für die Fehlersuche in einem Protokoll-Sonderfall bleibt. Die Reaktionsfähigkeit des Herstellersupports (und ob dieser das Problem bereits für OEMs gelöst hat) ist genauso wichtig wie der Funktionsumfang des SDKs.

9. Erfolgsbilanz bei OEMs, nicht nur bei Fabriken

Es besteht ein wesentlicher Unterschied zwischen einem SDK für die Host-Seite (Fabrik/MES) und einem für die Geräte-Seite (OEM). Stellen Sie sicher, dass der Anbieter Implementierungen speziell für OEMs bereitgestellt hat – die Aufgaben der Zustandsmaschine unterscheiden sich deutlich zwischen Host- und Geräterollen.

Selbst bauen oder kaufen: Der wahre Kompromiss

Eigenschaften Eigenbau Kommerzielles SECS/GEM SDK
Zeit bis zur ersten funktionierenden Integration Monatelange Entwicklung und Tests Wochen mit vorgefertigten Komponenten
SEMI-Standards-Konformität Hängt vollständig von der Expertise Ihres Teams ab. Integrierte Konformität mit den SEMI-Standards
Entwicklungskosten Hohe Vorabinvestitionen im Engineering-Bereich Geringere Implementierungskosten und schnellerer ROI
Laufende Wartung Wird auf unbestimmte Zeit von Ihrem Ingenieurteam verwaltet. Vom Anbieter gewartet und regelmäßig aktualisiert
GEM300 & zukünftige Standards Erfordert kontinuierliche Reinvestitionen In den SDK-Erweiterungen und -Releases enthalten
Kundenabnahmetest (FAT/SAT) Nur interne Unterstützung Technischer Support des Herstellers verfügbar
Implementierungsrisiko Höher aufgrund kundenspezifischer Entwicklung Senken Sie die Kosten mit einem bewährten, produktionsreifen SDK.
Time-to-Market Längere Produkteinführungszyklen Schnellere Bereitstellung und Produktveröffentlichung
Technischer Support Beschränkt auf interne Ressourcen Dedizierter Anbietersupport und Fehlerbehebung
Skalierbarkeit Erfordert zusätzlichen Entwicklungsaufwand Konzipiert für die Skalierung auf verschiedene Gerätemodelle.
Dokumentation & Beispiele Muss intern erstellt werden. Umfassende Dokumentation, APIs und Beispielprojekte
Langfristige Gesamtbetriebskosten (TCO) Höher aufgrund laufender Wartungs- und Modernisierungsarbeiten. Niedrigere Kosten durch kontinuierliche Unterstützung und Updates des Anbieters

Der Entwicklungspfad kann sinnvoll sein, wenn SECS/GEM-Konnektivität ein zentrales Alleinstellungsmerkmal Ihres Unternehmens darstellt oder Sie bereits über umfassende interne Protokollexpertise verfügen. Für die meisten OEMs von Halbleiteranlagen ist SECS/GEM-Konformität jedoch eine Voraussetzung für die Auslieferung und kein Wettbewerbsvorteil – was die Entscheidung für ein bewährtes SDK deutlich beeinflusst.

Die C#/.NET SECS/GEM SDK-Landschaft

Bei genauerer Betrachtung finden Sie einige etablierte Optionen für die .NET-basierte SECS/GEM-Entwicklung, jede mit einer anderen Ausrichtung. Hier ein allgemeiner Überblick über die wichtigsten Kategorien, denen Sie bei der Evaluierung begegnen werden (prüfen Sie die aktuellen Spezifikationen immer direkt beim jeweiligen Anbieter, da sich SDKs weiterentwickeln):

Etablierte native .NET-Bibliotheken (z. B. SECSGEM.NET/GEM300) sind in der Regel seit Jahren auf dem Markt und zeichnen sich dadurch aus, dass sie echte .NET-Bibliotheken und keine Wrapper sind. Sie bieten Lizenzierung pro Verbindung und unterstützen sowohl Host- als auch Gerätefunktionen. Diese Bibliotheken sind besonders für Teams attraktiv, die eine ausgereifte, codebasierte Bibliothek bevorzugen und gerne direkt auf der Protokollschicht arbeiten.

SDKs mit Fokus auf Modellentwicklung (z. B. NxSphere GEM, ehemals unter einem anderen Produktnamen bekannt) setzen auf visuelle Konfigurationswerkzeuge – eine grafische Benutzeroberfläche zur Definition von GEM-Diensten, Datenelementen und Ereignissen – sowie auf die zugrundeliegende .NET-Bibliothek und einen integrierten Simulator für Offline-Tests. Dadurch kann die Einarbeitungszeit für Teams ohne eigene SECS/GEM-Spezialisten deutlich verkürzt werden.

Komplettanbieter von SDKs und Implementierungen (z. B. EIGEMEquipment von eInnoSys) kombinieren das SDK mit Integrationsdiensten, Schnittstellen zu verschiedenen Programmiersprachen (C#/.NET, C++, Java, REST-API), verschiedenen Integrationsarchitekturen (eingebettet, separate Prozesse, dedizierte PCs, SPS/HMI-Brücke) und direkter technischer Unterstützung bei der Konformitätsprüfung und Implementierung. Dieses Modell eignet sich besonders für OEMs, die neben einer Bibliothek zum Aufbau von Systemen auch die Einhaltung von Vorschriften und eine termingerechte, funktionierende Integration benötigen.

Keine dieser Kategorien ist objektiv „die beste“, unabhängig von Ihrer Situation. Ein kleines Team mit fundierter Protokollexpertise bevorzugt möglicherweise eine schlanke, codebasierte Bibliothek; ein Team unter Zeitdruck mit begrenzten SECS/GEM-Kenntnissen profitiert oft mehr von einem Anbieter, der auch Integrationsdienste und Support bietet. Die untenstehende Bewertungscheckliste soll Ihnen helfen, die passende Kategorie zu finden.

Wo EIGEMEquipment passt

Das EIGEMEquipment SECS/GEM SDK von eInnoSys wurde speziell für die OEM-Seite dieses Problems entwickelt. Einige Details sollten anhand der oben genannten Kriterien überprüft werden:

  • Normenabdeckung: Vollständige Konformität mit SEMI E30 (GEM), E4 (SECS-I), E5 (SECS-II) und E37 (HSMS), einschließlich GEM300-Funktionalität.
  • Sprach- und Betriebssystemunterstützung: Verfügbar in C#/.NET, C++, Java und als REST-API, lauffähig unter Windows, Linux und Raspberry Pi – nützlich, wenn Ihre Gerätepalette mehr als eine Plattform umfasst oder Ihr Entwicklerteam nicht vollständig auf eine einzige Sprache standardisiert ist.
  • Unkomplizierte Abdeckung: eInnoSys gibt an, dass etwa 80 % der typischen SECS/GEM-Funktionalität ohne kundenspezifische Integrationsarbeiten verfügbar sind, was den größten Teil der Zeitersparnis ausmacht.
  • Architekturflexibilität: Unterstützt die direkte Einbettung des SDK in Ihren Controller-Prozess, die Ausführung als separaten Prozess auf demselben PC, die Ausführung auf einem dedizierten PC oder die Anbindung über SPS/HMI-basierte Optionen (EIGEMHMI, EIGEMLink) für Geräte, bei denen Sie keinen vollständigen Zugriff auf den Controller-Quellcode haben.
  • API-Design: Ausgerichtet auf einfache, lesbare APIs, damit auch Teams ohne dedizierten SECS/GEM-Spezialisten die Integration implementieren und warten können.
  • Pfad für ältere Geräte: Für ältere 150-mm-/200-mm-Werkzeuge, die nie für SECS/GEM konzipiert wurden, bietet eInnoSys ebenfalls Lösungen an. EIGEMBox, eine Plug-and-Play-Schnittstelle, die SECS/GEM-Konnektivität hinzufügt, ohne die bestehende Controller-Software zu verändern – relevant, wenn Ihr OEM-Portfolio sowohl neue als auch ältere Werkzeuggenerationen umfasst.

Ob EIGEMEquipment oder ein anderes SDK die richtige Wahl ist, hängt von Ihrer Gerätearchitektur, den Zielplattformen, Ihrem internen SECS/GEM-Know-how und davon ab, wie viel von Ihrem Controller-Quellcode Sie bereit sind, einer Drittanbieterabhängigkeit preiszugeben – aber es ist ein vernünftiger Ausgangspunkt für eine Vorauswahl, wenn Sie C#/.NET-Optionen mit zugehöriger technischer Unterstützung evaluieren.

MES-Integration: Was passiert nach der Installation des SDK?

Die Auswahl eines SECS/GEM SDKs beschränkt sich nicht nur darauf, die Geräte mit dem Protokoll kompatibel zu machen – es geht darum, was passiert, sobald die Geräte in der Fertigungshalle mit einem realen MES kommunizieren. Einige Punkte sollten Sie vor der SDK-Auswahl und nicht erst danach berücksichtigen:

Datenerfassungspläne (DCP) und Trace-Anforderungen: Fabs definieren ihre eigenen Anforderungen an die Stream 2/6-Datenerfassung pro Tool. Die API Ihres SDKs zur Verarbeitung dynamischer Ereignisberichte und Trace-Daten ist im Produktivbetrieb wichtiger als in einer Demo.

Rezeptverwaltung: Wenn Ihre Geräte herunterladbare Rezepte unterstützen, prüfen Sie, wie das SDK Stream 7 (Prozessprogrammverwaltung) handhabt und ob es die Übertragung großer Rezepte unterstützt (relevant, wenn Ihre Rezepte die praktische Größe einer einzelnen Nachricht überschreiten).

Alarm- und Ereignisanpassung pro Kunde: Verschiedene Fabriken konfigurieren unterschiedliche Alarmsätze und aktivieren/deaktivieren verschiedene Erfassungsereignisse. Ein SDK, das dies konfigurationsgesteuert statt codegesteuert ermöglicht, erspart Ihnen Nacharbeiten bei Kundeneinführungen.

Skalierung mehrerer Tools und Verbindungen: Wenn Ihr OEM Geräte mit mehreren Submodulen ausliefert oder Cluster von Tools verwaltet, vergewissern Sie sich, dass die Lizenzierung und Architektur des SDKs gleichzeitige Verbindungen problemlos und ohne Instabilität pro Verbindung unterstützen.

Nichts davon taucht in einer Funktionsvergleichstabelle auf, aber genau dort wird die SDK-Wahl tatsächlich auf die Probe gestellt – bei der Kundenqualifizierung, nicht bei Ihrem internen Machbarkeitsnachweis.

Eine praktische Bewertungscheckliste

Bevor man sich für ein SDK entscheidet, empfiehlt es sich, eine kurze technische Evaluierung durchzuführen, anstatt sich auf ein Datenblatt zu verlassen:

  1. Die Einhaltung der SEMI-Normen E30/E5/E37/E4 kann durch einen realen Konformitätstest bestätigt werden, nicht nur durch eine Behauptung.
  2. Erkundigen Sie sich, ob die Unterstützung für GEM300 bereits existiert oder geplant ist – und wann.
  3. Erstellen Sie einen kleinen Prototyp mit den Ereignis-/Alarmfunktionen Ihrer tatsächlichen Geräte, keine generische Demo.
  4. Prüfen Sie, welche Integrationsarchitekturoptionen existieren und ob diese mit dem aktuellen Design Ihres Controllers übereinstimmen.
  5. Prüfen Sie, ob die Betriebssystem- und Sprachunterstützung mit Ihrer tatsächlichen Geräteausstattung und den Fähigkeiten Ihres Teams übereinstimmt, einschließlich aller Pläne für die nächsten 1–2 Jahre.
  6. Erkundigen Sie sich insbesondere nach den Reaktionszeiten des Supports während der Kundenabnahmetests – in dieser Zeit treten die Probleme auf.
  7. Testen Sie alle mitgelieferten Simulator- oder Modellierungswerkzeuge anhand eines realistischen Ereignis-/Alarm-/Rezept-Szenarios, nicht nur anhand der Beispiel-App.
  8. Sprechen Sie mit Referenzen, die das SDK in OEM-Einsätzen (nicht nur in der Fabrik) verwendet haben, idealerweise auf Geräten, die Ihren ähnlich sind.

Letzter Gedanke

Das „beste“ C#/.NET SECS/GEM SDK ist keine Universallösung – es ist dasjenige, das zu Ihrer Gerätearchitektur, Ihrem Compliance-Zeitplan, dem SECS/GEM-Know-how Ihres Teams und Ihrer Bereitschaft zur langfristigen Protokollwartung passt. Für die meisten OEMs von Halbleiteranlagen ermöglicht ein ausgereiftes, standardkonformes SDK jedoch eine schnellere, konforme und supportfähige Integration als eine Eigenentwicklung – und spart Entwicklungskapazität für die Komponenten Ihrer Geräte, die diese tatsächlich von anderen abheben.

Wenn Sie verschiedene Optionen abwägen, ist eine technische Beratung zur SECS/GEM SDK-Integration eine kostengünstige Möglichkeit, Ihre Architektur anhand realer Implementierungserfahrungen auf Herz und Nieren zu prüfen, bevor Sie Monate an Entwicklungsarbeit in einen der beiden Wege investieren.