Stabilisierung einer MBE-Steuersoftware für Halbleiteranlagen und Windows-Auslieferung

Projektüberblick

Das Projekt betraf eine Windows-Leitsoftware für Halbleiterprozessanlagen. Die Qt/C++-Anwendung kommuniziert mit Temperaturreglern, einem Nadelventil, Vakuummessgeräten, Blendensteuerungen und einer Industriekamera. SQLite speichert Gerätemesswerte, Befehlsereignisse und Metadaten der Kamerabilder. Untersucht wurden unterbrochene Temperaturdaten, unvollständige Befehlsbestätigung, ein Rückgang der Kamerabildrate und unbemerkte Aufzeichnungsstopps, ohne die laufende Anwendung am Standort zu unterbrechen.

Die Auslieferung wurde in zwei getrennte Linien aufgeteilt. Die Wartungslinie änderte die vorhandene Anwendung in begrenztem, rückrollbarem Umfang und erzeugte einen Windows-x64-Installer. Eine separate v2-Linie verwendete ein eigenes Verzeichnis und eine eigene AppId, um die Zuständigkeit für serielle Ports, Datenbankverbindungen, Kamera-Worker und Skriptausführung zu prüfen. Vorhandene Konfigurationen und Verlaufsdaten blieben erhalten. Software mit möglichem Gerätezugriff wurde ohne bestätigtes Sicherheitsfenster nicht gestartet.

Systemumfang und Technik

Diagnose anhand vorhandener Nachweise

Eine schreibgeschützte Auswertung umfasste rund 8,89 Stunden historischer Protokolle und Datenbanken. COM5 verzeichnete 5.168 Pufferlöschungen, nachdem der Empfangspuffer 128 Byte überschritten hatte. Die wirksamen Aktualisierungen der zehn Temperaturregler lagen deutlich über dem konfigurierten Zwei-Sekunden-Zyklus. Der Quellcode las bei jeder hochfrequenten Abfrage etwa 35 Register mit einer typischen Antwort von ungefähr 75 Byte. GUI-Planung, langsame Datenbank-Batches und ein Wartefenster von 150 ms erhöhten die Wahrscheinlichkeit einer Vermischung verspäteter Antworten mit neuen Anforderungen.

Zwei historische Kameraaufzeichnungen vom selben Rechner ermöglichten einen weiteren Vergleich. Die frühere Basis schrieb JPEG-Dateien mit 8,006 FPS, die rückläufige Version mit 3,919 FPS. In beiden Stichproben gab es keine unmittelbar aufeinanderfolgenden identischen JPEG-Dateien. Der Rohbild-ACK wurde in die Warteschlange des Kamera-Workers gestellt. Eine blockierende Aufnahme konnte vor diesem ACK laufen, sodass ein neues Bild regelmäßig übersprungen wurde. Die Werte dokumentieren die Regression und ihre Diagnose; sie sind kein Feldabnahmeergebnis der korrigierten Version.

Begrenzte Wartung der bestehenden Anwendung

Die Wartungslinie behielt Benutzeroberfläche, Gerätekonfiguration, Datenordner und Zugänge zu Prozessskripten bei. Geänderte Dateien wurden vor dem Austausch gesichert. Für Patch-Archiv und Installer wurden SHA-256-Werte protokolliert. Der Installer bewahrt vorhandene Verzeichnisse MBE_Data, Scriptfile und die Gerätekonfiguration und startet die Leitsoftware nach der Installation nicht automatisch.

• Hochfrequente Temperaturabfragen wurden auf die für PV, SP und Working SP benötigten Register begrenzt; eine typische Antwort sank von etwa 75 auf etwa 15 Byte.
• Ein Sub-Temperaturschreibvorgang gleicht die Modbus-Antwort 0x06 ab und liest anschließend SP. Fehlende oder abweichende Antworten gelten als Fehler.
• Die Kamera arbeitet Worker-gesteuert; Vorschau und Rohaufzeichnung erlauben jeweils nur ein laufendes Bild und bevorzugen das aktuelle Bild.
• Temperaturwerte in Grad Celsius werden in Statusanzeige und altem Steuerpfad nicht erneut durch zehn geteilt.

Geräte-Rücklesen der Ramp Rate

Das Ramp-Rate-Feld beginnt mit -- anstelle eines von der Software erzeugten Festwerts. Danach liest die Anwendung das Geräteregister 0x0023. Im stabilen Betrieb wird alle drei Sekunden ein Regler gelesen; ein Umlauf über zehn Regler dauert etwa 30 Sekunden. Die Ramp Rate bleibt außerhalb der häufigen PV/SP-Anforderung, sodass nicht jede Antwort auf dem 9600-baud-Bus verlängert wird.

Diese Änderung korrigiert die Herkunft des angezeigten Werts: Eine Zahl erscheint erst nach Eingang der Gerätedaten. Die Synchronisierung nach einer Änderung am Gerätepanel muss noch mit Version 1.0.3 am realen System geprüft werden und wird deshalb nicht als abgeschlossene Hardwareabnahme dargestellt.

Kameraerfassung und Speicherpfad

Vorschau und Aufzeichnung verwenden das jeweils aktuellste Bild. Wenn GUI oder JPEG-Encoder vorübergehend langsamer sind, werden Zwischenbilder ersetzt, anstatt eine unbegrenzte Ereigniswarteschlange aufzubauen. Der Rohbild-ACK löst sein atomares Flag direkt und wartet nicht hinter einem weiteren blockierenden Kameraaufruf. Dateinamen und Datenbankfelder verwenden den tatsächlichen Aufnahmezeitpunkt; Start und Ende des Speicherns werden getrennt erfasst.

Version 1.0.3 ergänzt zwei Watchdog-Pfade. Ist die Kamera geöffnet, liefert aber drei Sekunden lang kein Rohbild, wird die Erfassung geschlossen und erneut geöffnet; für Neustartanforderungen gilt eine Abkühlzeit von zehn Sekunden. Überschreitet ein Speicherauftrag oder die Zeit seit der letzten Persistierung drei Sekunden, wird der blockierte Zustand gelöst und mit dem aktuellen Bild erneut versucht. Treiber, USB-Verbindung, Datenträgerleistung und Datenbankfehler müssen weiterhin vor Ort untersucht werden.

Getrennte v2-Architektur-Testlinie

v2 verwendet einen eigenen Quellbaum, eine eigene AppId und ein eigenes Installationsverzeichnis. Die laufende Altanwendung wird nicht ersetzt. Standardmäßig verbindet v2 keine seriellen Ports, startet keine Überwachung, öffnet keine Kamera und sendet beim Start keine Blendenbefehle. Ein physischer Port gehört genau einem PortWorker; Polling, Bedienbefehle und Skriptbefehle gelangen in eine gemeinsame priorisierte Transaktionswarteschlange.

SQLite besitzt nur eine Schreibverbindung. Gerätemesswerte und Kamerametadaten werden nach Zeit- oder Mengenschwelle gemeinsam bestätigt, während Verlaufssuchen eine getrennte schreibgeschützte Verbindung nutzen. Kameraerfassung, Vorschau und JPEG-Aufzeichnung sind getrennt. Das Prozessskript läuft in kurzen Zustandsmaschinenschritten und stoppt, wenn eine Antwort oder der Rücklesewert des Ziels fehlschlägt.

Build, Paketierung und Datenerhalt

Die Wartungsversion 1.0.3 wurde mit CMake und MSVC als Release x64 erstellt und mit Inno Setup 6.7.3 paketiert. Die Release-Datei hat 1.727.488 Byte. Die Installationsstufe enthält 78 Dateien mit insgesamt 66.292.772 Byte. Galaxy SDK, Qt-Bibliotheken, SQLite-Treiber, VC Runtime und Gerätekonfiguration waren vorhanden; Qt-Debug-DLLs waren nicht enthalten.

Die Installerversion lautet 1.0.3.20260728 und ist 19.884.961 Byte groß. Vollständige SHA-256-Werte für Programm, Patch-Archiv und Installer liegen im Auslieferungsprotokoll. Der Installer ist nicht mit Authenticode signiert; Windows kann deshalb einen Hinweis auf einen unbekannten Herausgeber anzeigen.

Prüfnachweise und Grenzen

Sicherheit am Standort und Abnahmeplan

Nach dem Start kann die Anwendung serielle Geräte und die Kamera verbinden und Steuerbefehle senden. Deshalb wurde der neue Build in der Fernsitzung nicht auf einem unbeaufsichtigten Desktop gestartet und der vorhandene Prozess nicht beendet. Nach Bestätigung eines sicheren Anlagenzustands sollte die Prüfung von reiner Überwachung über Einzelbefehle, Kamera, Ventil und Blenden sowie Skripte bis zum gemeinsamen Betrieb fortschreiten.

• 30 Minuten überwachen und Messintervall, Timeout-Rate sowie größte Lücke jedes Reglers berechnen.
• Mehrere sichere Sub-Ziele schreiben und 0x06-Antwort, SP-Rücklesen, Gerätepanel und PV vergleichen.
• Belichtung, Auflösung und Speicherort festlegen und Erfassungs-FPS, Speicher-FPS, ausgelassene Bilder und Ende-zu-Ende-Latenz messen.
• Kameraverbindung unterbrechen und wiederherstellen; Watchdog-Protokoll, Vorschau und Aufzeichnung prüfen.
• Vor einer Ablösung der Altanwendung acht Stunden kombinierten Betrieb aufzeichnen.

Wiederverwendbare Vorgehensweise

Die Vorgehensweise eignet sich für vorhandene industrielle Windows-Anwendungen, bei denen Betrieb und Rückrollbarkeit erhalten bleiben müssen: Halbleiteranlagen, Vakuumsysteme, Temperaturregelung, Industriekameras, Mehrport-Erfassung, Laborgeräte und Prozessskripte. Zuerst werden reproduzierbare Belege aus Protokollen, Datenbanken und Protokollpfaden erstellt. Danach werden begrenzte Korrekturen und eine getrennte Architekturprüfung nach ihrem Risiko ausgewählt.

Eingaben für ein ähnliches Projekt

Für eine erste Prüfung werden Geräteprotokolle, serielle Topologie, Registerlisten, Kamera-SDK und Beispiele, Quellcode und Build-Umgebung, historische Protokolle und Datenbanken, Sicherheitsgrenzen, Rückrollweg sowie messbare Vorgaben für Abtastzeit, Befehlserfolg, Bildrate, Latenz und Dauerbetrieb benötigt. Statische Diagnose, Tests ohne Hardware, Installerprüfung und Abnahmeplan können vor einem Gerätefenster erfolgen, ersetzen aber keine Feldabnahme.

Häufige Fragen

War dies eine Neuentwicklung oder die Wartung eines bestehenden Systems?

Beides. Die Wartungslinie lieferte begrenzte Änderungen und den Installer 1.0.3. v2 ist eine getrennte Testlinie für klarere Thread-, Transaktions- und Datenzuständigkeiten und ersetzt die laufende Altanwendung nicht.

Warum wurde der neue Build nicht über die SSH-Sitzung gestartet?

Der Start kann Kamera und serielle Ports belegen und Gerätebefehle auslösen. Ohne bestätigten sicheren Anlagenzustand wurden nur Quellcode, Build, Paketierung und statische Prüfungen durchgeführt.

Sind 8,006 FPS ein Messwert nach der Korrektur?

Nein. Der Wert stammt aus einer historischen Basis auf demselben Rechner; 3,919 FPS stammen aus der rückläufigen Version. Der Vergleich diente der Diagnose. Die korrigierte Version muss unter festgelegten Bedingungen neu gemessen werden.

Wurden alle Gerätefunktionen getestet?

Nein. Im Wartungsprojekt waren keine automatischen Tests registriert. Ein v2-Testprogramm deckte 11 Gruppen von Protokoll-, Zustands-, Skript- und Speicherprüfungen ohne Hardware ab. Reale Geräte und Dauerbetrieb bleiben Abnahmepunkte.

Wie wurden Standortdaten und Konfiguration geschützt?

Vor Änderungen wurden Sicherungen erstellt und Hashwerte protokolliert. Der Installer erhält Daten, Skripte und vorhandene Konfiguration. v2 nutzt eine getrennte AppId und ein anderes Verzeichnis. Der Versionswechsel folgt erst der Feldabnahme.