Studi stabilisasi perangkat lunak kontrol peralatan semikonduktor MBE dan pengiriman Windows

Ikhtisar proyek

Proyek ini menangani aplikasi kontrol tingkat atas berbasis Windows untuk peralatan proses semikonduktor. Sistem Qt/C++ berkomunikasi dengan pengontrol suhu, katup jarum, pengukur vakum, pengontrol shutter, dan kamera industri. SQLite menyimpan sampel perangkat, peristiwa perintah, serta metadata frame kamera. Pekerjaan berfokus pada diagnosis data suhu yang terputus, konfirmasi perintah yang belum lengkap, penurunan frame rate kamera, dan perekaman yang berhenti tanpa pesan, tanpa mengganggu aplikasi lokasi yang sedang berjalan.

Pengiriman dibagi menjadi dua jalur terisolasi. Jalur pemeliharaan menerapkan perubahan terbatas yang dapat dipulihkan pada aplikasi lama dan menghasilkan installer Windows x64. Jalur v2 memakai direktori dan AppId terpisah untuk menguji kepemilikan port serial, koneksi basis data, worker kamera, dan eksekusi skrip. Konfigurasi serta data historis dipertahankan. Perangkat lunak yang dapat terhubung ke peralatan tidak dijalankan sebelum operator menyetujui jendela keselamatan.

Ruang lingkup sistem dan teknologi

Diagnosis berbasis bukti

Peninjauan baca-saja mencakup sekitar 8,89 jam log dan basis data historis. COM5 mencatat 5.168 pengosongan buffer setelah penerimaan melebihi 128 byte, sedangkan pembaruan efektif dari sepuluh pengontrol suhu jauh lebih lambat daripada periode dua detik yang dikonfigurasi. Pemeriksaan kode menunjukkan bahwa setiap polling frekuensi tinggi membaca sekitar 35 register dengan respons tipikal sekitar 75 byte. Penjadwalan GUI, batch basis data yang lambat, dan jendela tunggu 150 ms meningkatkan kemungkinan respons terlambat bercampur dengan permintaan berikutnya.

Dua catatan kamera historis dari komputer yang sama memberi perbandingan lain. Basis lama menulis JPEG pada 8,006 FPS, sedangkan build yang mengalami regresi menulis 3,919 FPS. Kedua sampel tidak memiliki JPEG berurutan yang isinya sama. ACK frame mentah dimasukkan kembali ke antrean worker kamera; akuisisi yang memblokir dapat berjalan sebelum ACK sehingga frame baru dilewati saat frame sebelumnya masih dianggap tertunda. Angka ini dipakai untuk menetapkan regresi, bukan sebagai hasil penerimaan setelah perbaikan.

Pemeliharaan terbatas pada aplikasi lama

Jalur pemeliharaan mempertahankan antarmuka, konfigurasi perangkat, folder data, dan titik masuk skrip proses. File diarsipkan sebelum penggantian, sedangkan arsip patch dan installer menerima catatan SHA-256. Installer mempertahankan MBE_Data, Scriptfile, dan konfigurasi perangkat yang sudah ada serta tidak menjalankan aplikasi kontrol secara otomatis setelah instalasi.

• Pembacaan suhu frekuensi tinggi dibatasi pada register untuk PV, SP, dan Working SP, sehingga respons tipikal turun dari sekitar 75 menjadi sekitar 15 byte.
• Penulisan suhu Sub mencocokkan respons Modbus 0x06 lalu membaca SP. Respons yang hilang atau nilai yang berbeda dilaporkan gagal.
• Akuisisi kamera digerakkan worker; pratinjau dan rekaman mentah masing-masing hanya mengizinkan satu frame dalam proses dan memilih frame terbaru.
• Nilai teknik dalam Celsius tidak lagi dibagi sepuluh untuk kedua kalinya pada status dan jalur kontrol lama.

Pembacaan perangkat untuk Ramp Rate

Sel Ramp Rate dimulai dengan --, bukan nilai tetap buatan perangkat lunak. Aplikasi kemudian membaca register perangkat 0x0023. Dalam keadaan stabil, satu pengontrol dibaca setiap tiga detik dan satu putaran sepuluh perangkat selesai sekitar 30 detik. Ramp Rate tidak disertakan dalam permintaan PV/SP frekuensi tinggi, sehingga tidak memperpanjang semua respons pada bus 9600 baud.

Perubahan ini memperbaiki sumber nilai yang ditampilkan: angka hanya muncul setelah data perangkat diterima. Sinkronisasi setelah operator mengubah nilai pada panel perangkat masih perlu diperiksa melalui pengujian lapangan versi 1.0.3 dan tidak dinyatakan sebagai penerimaan perangkat keras yang selesai.

Jalur akuisisi dan penyimpanan kamera

Pratinjau dan rekaman menggunakan makna frame terbaru. Jika GUI atau encoder JPEG lebih lambat untuk sementara, frame perantara dapat diganti agar antrean peristiwa tidak terus bertambah. ACK frame mentah melepaskan flag atomik secara langsung dan tidak menunggu di belakang panggilan kamera yang memblokir. Nama file dan kolom basis data menggunakan waktu akuisisi sebenarnya; waktu mulai serta selesai penyimpanan dicatat terpisah.

Versi 1.0.3 menambahkan dua jalur watchdog. Jika kamera terbuka tetapi tidak ada frame mentah selama tiga detik, aplikasi menutup dan membuka ulang akuisisi dengan jeda restart sepuluh detik. Jika tugas penyimpanan atau waktu sejak persistensi terakhir melebihi tiga detik, status macet dilepas dan proses mencoba lagi dengan frame saat ini. Mekanisme ini menangani penghentian diam, tetapi tidak menggantikan diagnosis driver, USB, throughput disk, atau kesalahan basis data di lapangan.

Jalur uji arsitektur v2 yang terisolasi

v2 menggunakan pohon sumber, AppId, dan direktori instalasi sendiri, sehingga tidak mengganti aplikasi lama yang berjalan. Secara bawaan v2 tidak menghubungkan port serial, memulai pemantauan, membuka kamera, atau mengirim perintah shutter saat startup. Satu port fisik dimiliki oleh satu PortWorker; polling, perintah operator, dan perintah skrip masuk ke satu antrean transaksi berprioritas.

SQLite memiliki satu koneksi penulis. Sampel perangkat dan metadata kamera dikomit berdasarkan waktu atau ambang batch, sementara kueri historis memakai koneksi baca-saja terpisah. Akuisisi, pratinjau, dan perekaman JPEG menjadi tanggung jawab terpisah. Skrip proses maju melalui langkah mesin status yang singkat dan berhenti bila respons atau pembacaan target gagal.

Build, pengemasan, dan retensi data

Versi pemeliharaan 1.0.3 dibangun memakai CMake dan MSVC Release x64 lalu dikemas dengan Inno Setup 6.7.3. Executable Release berukuran 1.727.488 byte. Tahap installer berisi 78 file dengan total 66.292.772 byte. Pemeriksaan menemukan Galaxy SDK, pustaka Qt, driver SQLite, VC Runtime, dan konfigurasi perangkat, tanpa Qt Debug DLL.

Versi installer adalah 1.0.3.20260728 dan ukurannya 19.884.961 byte. Nilai SHA-256 lengkap untuk program, arsip patch, dan installer disimpan dalam catatan pengiriman. Installer belum ditandatangani Authenticode sehingga Windows dapat menampilkan pemberitahuan penerbit tidak dikenal.

Bukti verifikasi dan batasnya

Keselamatan lokasi dan rencana penerimaan

Setelah dijalankan, aplikasi dapat menghubungkan perangkat serial dan kamera serta mengirim perintah kontrol. Karena itu sesi jarak jauh tidak menjalankan build baru pada desktop tanpa pengawasan dan tidak menghentikan proses lama. Setelah operator memastikan peralatan aman, penerimaan sebaiknya bergerak dari pemantauan saja ke perintah tunggal, kamera, katup dan shutter, skrip, lalu operasi gabungan.

• Pantau 30 menit dan hitung interval sampel, rasio timeout, serta jeda terbesar untuk setiap pengontrol suhu.
• Tulis beberapa target Sub yang aman dan bandingkan respons 0x06, pembacaan SP, panel perangkat, dan PV.
• Tetapkan exposure, resolusi, dan lokasi penyimpanan lalu ukur FPS akuisisi, FPS simpan, frame terlewat, dan latensi ujung-ke-ujung.
• Putus dan pulihkan koneksi kamera, lalu periksa log watchdog serta pemulihan pratinjau dan rekaman.
• Catat delapan jam operasi gabungan sebelum memutuskan penggantian aplikasi lama.

Metode rekayasa yang dapat digunakan kembali

Metode ini sesuai untuk aplikasi Windows industri yang harus tetap tersedia dan dapat dipulihkan selama perbaikan, termasuk peralatan semikonduktor, sistem vakum, kontrol suhu, kamera industri, akuisisi multiport, peralatan laboratorium, dan kontrol skrip proses. Langkah pertama adalah membangun bukti yang dapat diulang dari log, basis data, dan jalur protokol, kemudian memilih perubahan terbatas atau uji arsitektur terpisah sesuai risiko.

Masukan untuk proyek serupa

Peninjauan awal biasanya memerlukan protokol perangkat, topologi serial, peta register, SDK kamera dan sampel, sumber serta lingkungan build, log dan basis data historis, batas keselamatan, cara rollback, dan target terukur untuk periode sampel, keberhasilan perintah, frame rate, latensi, serta operasi terus-menerus. Diagnosis statis, uji tanpa perangkat, pemeriksaan installer, dan rencana penerimaan dapat dilakukan sebelum tersedia waktu perangkat, tetapi tidak menggantikan penerimaan lapangan.

Pertanyaan umum

Apakah ini pengembangan baru atau pemeliharaan sistem lama?

Keduanya. Jalur pemeliharaan menghasilkan perubahan terbatas dan installer 1.0.3. v2 adalah jalur uji terpisah untuk kepemilikan thread, transaksi, dan data yang lebih jelas dan tidak mengganti aplikasi lama.

Mengapa build baru tidak dijalankan melalui SSH?

Startup dapat mengambil kamera dan port serial serta mengirim perintah perangkat. Tanpa konfirmasi keadaan aman, pekerjaan dibatasi pada sumber, build, pengemasan, dan pemeriksaan statis.

Apakah 8,006 FPS adalah hasil setelah perbaikan?

Tidak. Itu adalah basis historis pada komputer yang sama; 3,919 FPS adalah build regresi. Perbandingan dipakai untuk menemukan masalah penjadwalan ACK. Build perbaikan masih harus diukur ulang dengan kondisi tetap.

Apakah semua fungsi perangkat telah diuji?

Belum. Proyek pemeliharaan tidak mendaftarkan uji otomatis. Satu program uji v2 mencakup 11 grup protokol, status, skrip, dan penyimpanan tanpa perangkat. Perangkat nyata dan operasi jangka panjang tetap menjadi item penerimaan.

Bagaimana data dan konfigurasi lokasi dilindungi?

File dicadangkan sebelum perubahan, hash dicatat, installer mempertahankan data, skrip, dan konfigurasi lama, sedangkan v2 memakai AppId dan direktori terpisah. Peralihan versi ditentukan setelah penerimaan lapangan.