← Zurück zu den Fallstudien Fallstudie für wissenschaftliche Software

Steuerungs- und Datenerfassungssoftware für Halbleiter-Forschungsanlagen: Zuverlässigkeitsüberarbeitung eines Windows-Leitrechners

Anonymisierte Sinovanta-Fallstudie zu einer Qt/C++-Windows-Anwendung, Modbus-Temperaturregelung, Industriekamera, SQLite-Daten, verifizierten Schreibvorgängen und reproduzierbarer Installation.

Auftrag
Prüfung eines Bestandssystems und gezielte Softwareüberarbeitung
Umfang
Windows-Software, Gerätekommunikation, Industriekamera, Datenspeicherung und Paketierung
Plattform
Windows 10/11 x64, Qt 5.12, C++/MSVC, Modbus RTU und SQLite
Nachweisversion
Kundentest-Installer 1.0.3.20260728
01

Projektkontext

Die vorhandene Leitrechner-Anwendung koordinierte zehn Temperaturregler, Verschlüsse, eine Industriekamera, Prozessskripte und Versuchsprotokolle. Die Felddiagnose zeigte unterbrochene Temperaturdaten, nicht gemeldete Speicherlücken und verzögerte Kameravorschau, scheinbar erfolgreiche Schreibvorgänge ohne Geräteänderung, einen Ramp-Rate-Wert vor der Hardware-Rücklesung und uneinheitliche Temperaturskalierung.

02

Technisches Ziel

Bewährte Geräteintegrationen sollten erhalten bleiben, während die risikoreichen Pfade gezielt abgesichert wurden: nachvollziehbare Schreibvorgänge, bidirektionaler Parameterabgleich, Wiederanlauf von Aufnahme und Speicherung, konsistente Einheiten, ein reproduzierbarer Release-Installer und klar definierte Restprüfungen an der Kundenhardware.

Zuverlässigkeit über den gesamten Steuerungs- und Datenpfad

Serielle Kommunikation, Kameraaufnahme, Speicherung, UI-Zustand und Paketierung wurden als zusammenhängende, beobachtbare Kette behandelt. Jede Änderung ist einem Fehlerbild und einem prüfbaren Ergebnis zugeordnet.

  1. 01

    Baseline und Beweissicherung

    Quell- und Installerstand fixieren, Protokolle und SQLite-Daten prüfen, Gerätegrenzen erfassen und beobachtete Fehler von Annahmen trennen.

  2. 02

    Serielle Erfassung und Rücklesen

    Die schnelle PV/SP-Abfrage stabil halten und Ramp Rate aus Register 0x0023 mit niedriger Frequenz lesen: alle drei Sekunden ein Regler.

  3. 03

    Verifizierte Gerätesteuerung

    Ein Schreiben erst akzeptieren, wenn die Modbus-0x06-Antwort Slave, Register und Wert exakt bestätigt und der Ziel-SP zurückgelesen wurde; andernfalls wiederholen oder Fehler melden.

  4. 04

    Wiederanlauf der Kamerakette

    Rohbildeingang und Speicherung getrennt überwachen, die Aufnahme nach drei Sekunden Stillstand neu öffnen und die Speicherung erneut anstoßen, wenn Bilder eintreffen, aber keine Datei entsteht.

  5. 05

    Daten- und Einheitkonsistenz

    Einen gemeinsamen Temperaturpfad verwenden, den alten Faktor-10-Fehler entfernen, reale Aufnahmezeitstempel erhalten und Diagnosedaten für spätere Prüfungen vorhalten.

  6. 06

    Release- und Abnahmekontrolle

    x64-Release bauen, Laufzeitabhängigkeiten prüfen, Versionen und SHA-256 dokumentieren, Rollback-Material sichern und eine Hardware-Abnahmeliste ausgeben.

03

Kontrollierte Liefergegenstände

Gezielter Quellcode-Patch
Patch aus 12 Dateien für Ramp-Rate-Rücklesen, verifizierte Schreibvorgänge, Kamerawiederanlauf, Speicherplanung und Temperatureinheiten.
Kundentest-Installer
Version 1.0.3.20260728 für Windows x64 mit Qt-Laufzeit, SQLite-Treiber, Kamera-SDK, Gerätekonfiguration und VC Runtime.
Architektur- und Codeprüfung
Prüfung der Anwendungsstruktur, Kommunikationspfade, Datenverarbeitung und priorisierten P0/P1-Risiken.
Build- und Paketnachweis
Release-Ausgabe, Abhängigkeitsliste, Versionsmetadaten, Dateizahlen und SHA-256-Prüfsummen.
Feldabnahme-Checkliste
Geräterücklesen, wiederholte Schreibprüfung, Kamera-Dauertest, Wiederverbindung, Speicherkontinuität und Einheitenkontrolle.
04

Technische Nachweise

Jeder Nachweis nennt Artefakt, Prüfumfang und Grenze. Er ersetzt keine Abnahme an der Kundenhardware.

Architekturprüfung

83 C++-Quell- und Headerdateien; rund 36.200 physische Zeilen geprüft.

Die Prüfung identifizierte konkrete P0/P1-Risiken und Verantwortungsgrenzen. Sie ist keine Softwarezertifizierung.

Felddiagnose der Vorversion

Medianer Bildabstand etwa 125 ms; 99 % höchstens 130 ms; eine Lücke von 562,921 s und eine von 17,306 s; 1.486 gespeicherte Bilder ohne direkt aufeinanderfolgende Duplikate.

Die Werte bilden die frühere Fehlerbasis ab und belegen keinen Dauertest von Version 1.0.3.

Release-Build

Build bestanden; EXE 1.727.488 Byte; SHA-256 CB4A11624F97BABC892399DF0975059408AA62CA4502622BBEE84D058D2FD5FD.

Belegt werden nur das reproduzierbare Artefakt und die geprüften statischen Zusicherungen.

Installer-Prüfung

78 Dateien mit insgesamt 66.292.772 Byte; keine Qt-Debug-DLL; erforderliche Qt-, SQLite-, Kamera-SDK-, VC-Runtime- und Gerätedateien vorhanden.

Installer-SHA-256: 6908988BF48670AC25A9F004BC77070960AE55D19D35AB51212EBDD64B4321A9. Das Paket ist nicht signiert.

05

Validierungsstatus

  • Statische Prüfungen bestanden für Ramp-Rate-Lesepfad, Schreib-/Rücklesefluss, Aufnahme-Watchdog, Speicher-Watchdog und Entfernung der alten Temperaturskalierung.
  • CTest endete erfolgreich, meldete jedoch keine gefundenen Tests; dies ist kein funktionaler Testnachweis.
  • ProductVersion, FileVersion, Paketinhalt, Laufzeitabhängigkeiten und SHA-256-Werte wurden geprüft.
  • Version 1.0.3 war zum Nachweisdatum nicht auf dem Kundeninstrument installiert oder ausgeführt; Geräte- und Dauertestabnahme steht aus.
06

Umfang und Grenzen

Veröffentlicht werden ein Windows-Kundentest-Installer sowie Quell-, Build-, Paket- und statische Prüfnachweise. Nicht belegt sind eine abgeschlossene Standortabnahme, Produktionssignierung, zertifizierte Messgenauigkeit, unterbrechungsfreie Langzeitspeicherung oder der Betrieb mit jeder Regler- und Kamerakombination. Die Endabnahme erfordert echtes Ramp-Rate-Rücklesen, Übereinstimmung mit der Geräteanzeige bei wiederholten Schreibvorgängen, mindestens zwei Stunden Kamerabetrieb ohne ungeklärte Lücken, Trenn- und Wiederverbindungstests sowie Einheitenprüfungen am Zielinstrument.

Software für wissenschaftliche Geräte besprechen

Teilen Sie Anlagentopologie, Protokolle, Kameramodell, Aufbewahrungsregeln, Ablauf, vorhandenen Quellcode oder Executable, Zielumgebung und Abnahmekriterien mit.

Anforderungen senden →