Günlükler, Tanılama, Telemetri ve Güvenlik

Bu bölüm, Mikrofab yarıiletken/TFT/PV ölçüm ve analiz yazılımının operasyonel omurgasını oluşturan dört birbiriyle ilişkili sistemi kapsar: günlük (log) altyapısı, tanılama (diagnostics) araçları, kullanım raporu (telemetri) ve donanım güvenliği. Bu sistemlerin tamamı, "bir sorun olduğunda ne oldu?" sorusuna güvenilir biçimde yanıt vermek, gizliliği korumak ve her durumda cihazı güvenli bir duruma getirmek üzere tasarlanmıştır.

Tasarımın ortak ilkesi şudur: sırlar asla diske yazılmaz veya ağ üzerinden gönderilmez; kişisel veri (PII) maskelenir; donanım her hata, iptal ve kapanışta güvenli duruma alınır. Aşağıdaki alt bölümler her sistemi ayrı ayrı, koddaki gerçek davranışa sadık kalarak açıklar.

1. Günlük (Log) Sistemi

Yazılım iki tamamen ayrı günlük akışına sahiptir ve bunların karıştırılmaması kritik öneme sahiptir:

1. Yerel tanılama günlüğü — diske yazılır, makinede kalır, ağ üzerinden hiçbir yere gönderilmez. Sorun giderme ve destek için kullanılır.
2. Çıktı günlüğü konsolu (Output Log) — arayüzdeki, operatöre dönük, renk kodlu canlı akış. Ölçüm sırasında ne olduğunu insan-okunur biçimde gösterir.

Bu ikisi farklı amaçlara hizmet eder; her ikisi de telemetri/kullanım raporundan (Bölüm 3) tamamen bağımsızdır.

1.1. Yerel günlük dosyası ve dönüşümlü saklama (rotation)

Yerel günlük, adı tft_measurement_app olan tek bir logger tarafından üretilir ve hem bir dosyaya hem de standart konsola (stderr) yazılır. Dosya, sınırsız büyümeyi önlemek için dönüşümlü (rotating) olarak tutulur.

Dönüşüm mantığı: etkin dosya 2 MB'ye ulaştığında ...log → ...log.1 olarak yeniden adlandırılır, en eski yedek (...log.5) silinir. Böylece toplam disk kullanımı her zaman üst sınırda kalır.

Günlük satırı biçimi sabittir ve makinece ayrıştırılabilir:

2026-06-29T14:32:07 | INFO | tft_measurement_app | Keithley 2612A baglandi
<zaman damgası (UTC)> | <SEVİYE> | <logger adı> | <mesaj>

1.2. Günlük dosyasının konumu

Günlük dosyası, kullanıcıya özgü veri kökü altındaki logs klasöründe tutulur. Veri kökü, ilk yazılabilir olanı seçilerek aşağıdaki sırayla belirlenir:

1. MIKROFAB_APPDATA ortam değişkeni (ayarlıysa) — taşınabilir/özel kurulumlar için.
2. %APPDATA%\<Üretici>\<Uygulama>\ (Windows'ta tipik yol).
3. %LOCALAPPDATA%\<Üretici>\<Uygulama>\ (yedek).
4. ~/.mikrofab/tft_measurement_app/ (ev dizini yedeği).
5. <çalışma dizini>/user_data/ (son çare).

Yani Windows'ta tipik tam yol:

%APPDATA%\Mikrofab\TFT Measurement App\logs\tft_measurement_app.log

1.3. PII maskeleme ve sır koruması (yerel günlükte)

Yerel günlüğe yazılan her satır, dosyaya/konsola düşmeden önce bir PII filtresi (PiiFilter) üzerinden geçer. Bu filtre iki kuralı uygular:

Kural A — Olası sır içeren satır tamamen redakte edilir

Mesaj metni küçük harfe çevrilip aşağıdaki anahtarlardan herhangi biri aranır; biri bulunursa satırın tamamı <redacted: possible secret> ile değiştirilir (içerik asla yazılmaz):

Kural B — Dosya yolundaki kullanıcı adı maskelenir

Satır sır içermiyorsa, yol içindeki kullanıcı-adı bileşeni <user> ile değiştirilir:

Ayrıca yakalanmamış istisnalar (uncaught exception), tam traceback ile birlikte CRITICAL seviyesinde günlüğe düşürülür. Bu mekanizma, hem GUI çalışırken hem de başsız (headless) çalıştırmada devrede olduğu için, çökme nedeni her zaman dosyaya kaydedilir.

1.4. Çıktı Günlüğü konsol paneli (Output Log)

Arayüzün alt kısmında yer alan Çıktı Günlüğü (başlık: "ÇIKTI GÜNLÜĞÜ"), operatöre dönük, salt-okunur, renk kodlu canlı bir akıştır. Bir yan/alt panel (dock) içinde "Çıktı Günlüğü" başlığıyla yerleştirilir ve Reading Values (okuma değerleri) paneliyle aynı alanda sekmelenir.

Panel özellikleri:

• Konum: Pencerenin alt kenarına yerleşik, ayrılabilir/yüzdürülebilir dock.
• Görünürlük: Görünüm > Günlük / Konsol menüsü ile açılıp kapatılabilir.
• İçerik: Her satır [SS:DD:ss] biçiminde yerel saat damgası + mesaj.
• Eş zamanlı yerel günlük: Konsola yazılan her mesaj, aynı anda logger.info(...) ile yerel günlük dosyasına da düşer (tek çağrı, çift hedef).

Renk kodlaması. Konsol, mesaj içeriğine göre satırı otomatik dört renge ayırır (içerikteki anahtar sözcüklere bakılır):

2. Tanılama (Diagnostics)

Tanılama araçları, bir sorunu uzaktan destek almadan ya da geliştiriciye gönderilebilecek temiz bir paket hazırlayarak teşhis etmenizi sağlar. Üç katman vardır: tanılama paketi dışa aktarımı, donanım öz-testi (self-test) ve adım-adım sorun giderme (troubleshoot) ile tek-tık düzeltmeler.

2.1. Tanılama paketi dışa aktarma

Tanılama paketi, destek/hata-ayıklama için gereken her şeyi tek bir zip dosyasında toplar. İşlem GUI'den bağımsız (saf), best-effort (en iyi çaba) ve asla uygulamayı çökertmeyecek biçimde tasarlanmıştır.

Pakete dahil edilenler:

system_info.json içeriği:

Sır redaksiyonu (ayarlarda). settings.json yazılmadan önce, adı aşağıdaki ipuçlarından birini içeren her ayar alanı <redacted> ile değiştirilir (iç içe sözlükler özyinelemeli taranır):

api_key · api-key · apikey · token · secret · password · passwd
license_key · license-key · private · signing · authorization · bearer

Bu sınır aşılırsa en büyük günlük dosyaları atlanır (paket yine üretilir); böylece zip dosyası makul boyutta kalır.

2.2. Donanım öz-testi (Self-test)

Öz-test, bir cihazın "yaşıyor ve iletişim kurulabilir" olduğunu salt-okunur denetimlerle doğrular. Hiçbir çıkış (output) veya akım uygulanmaz — bu nedenle bağlı bir DUT (test edilen cihaz) varken bile güvenle çalıştırılabilir.

Öz-test, Donanım sayfasındaki cihaz kartının eylem menüsünden tetiklenir. Test arka planda (engellemeyen bir iş parçacığında) koşar; panel modeless'tir (başka işlerinizi engellemez) ve test bitince sinyalle güncellenir.

Çalıştırılan denetimler (sırayla):

Genel sonuç (roll-up) hesabı en kötü tekil denetime göre belirlenir:

girdi  : her denetimin durumu {OK, WARN, FAIL, SKIP}
formül : herhangi FAIL  -> genel = FAIL
         (FAIL yok) herhangi WARN -> genel = WARN
         (yalnız OK)            -> genel = PASS
çıktı  : PASS / WARN / FAIL  (SKIP roll-up'ta yok sayılır)
dayanak: IEEE-488.2 öz-test (*TST?) + cihaz hata kuyruğu (SYST:ERR?) sözleşmesi

Panel görünümü ve durum bandı:

Panel öğeleri:

• Durum bandı: Büyük, renk kodlu PASS/WARN/FAIL etiketi.
• Meşgul çubuğu (busy bar): Test sürerken belirsiz (marquee) animasyon; yavaş bir gerçek denetim (*TST?, SYST:ERR? döngüsü) sırasında panelin donmuş görünmesini engeller. Sonuç gelince gizlenir.
• Tanıtım satırı: "Bu öz-test cihaz üzerinde aşağıdaki salt-okunur denetimleri çalıştırır:" — testten önce ne yapılacağını açıklar.
• Denetim satırları: Her denetim için simge + ad + mesaj. Simgeler: ✓ (OK), ⚠ (WARN), ✗ (FAIL), – (SKIP / yapılmadı).
• Ham hata bölümü: Cihaz hata kuyruğundan dönen ham metin (tek-aralıklı/monospace); kuyruk boşsa gizlenir.

2.3. Tanılama bandı, sorun giderme ve tek-tık düzeltmeler

Bir cihaz bağlanamadığında ya da yanıt vermediğinde, Donanım sayfası bir tanılama bandı gösterir. Bant, soruna olası nedeni insan-okunur biçimde açıklar ve tek-tık düzeltme eylemleri sunar. Örnek neden ve eylemler:

Adım-adım Sorun Giderme penceresi (Troubleshoot). "Sorun gider" eylemi, cihaza özel modeless bir kontrol listesi açar. Pencerede beş adım, her birinin yanında bir Yeniden dene düğmesiyle listelenir; "Yeniden dene", ilgili *IDN? yoklamasını GUI iş parçacığı dışında yeniden çalıştırır:

Pencerenin altında, son hatanın ham hata metni (tek-aralıklı) gösterilir ve çevrimiçi sorun giderme kılavuzuna giden bir Yardım bağlantısı (https://mikrofab.com/docs/troubleshoot) bulunur.

3. Telemetri / Kullanım Raporu

Kullanım raporu (telemetri), yazılımın hangi koşullarda nasıl davrandığını anlamak ve hataları proaktif gidermek için anonim, PII'siz olay sinyalleri toplar. Sistem çevrimdışı-öncelikli (offline-first) çalışır ve rıza modeli ile sıkıca sınırlandırılmıştır.

3.1. Çevrimdışı-öncelikli kuyruk

Telemetri çağrıları asla uygulamayı bekletmez veya çökertmez. Gönderilemeyen (internet/uç nokta yoksa) olaylar bir kuyruk dosyasına yazılır ve sonraki denemede toplu (batch) gönderilir.

Çalışma akışı:

1. Bir olay üretilince telemetry_queue.jsonl dosyasına eklenir (append).
2. Arka plandaki bir işçi (daemon thread) periyodik olarak kuyruğu anlık görüntü (.sending dosyası) alarak gönderir; bu sırada yeni olaylar engellenmez.
3. Gönderim başarılıysa olaylar kuyruktan düşer; başarısızsa kuyrukta kalır (veri kaybı yok).
4. Önceki çalışmadan kalan bir .sending dosyası açılışta kuyruğa geri kazanılır (çökme dayanıklılığı).
5. Çıkışta (shutdown) kuyruk son bir kez boşaltılmaya çalışılır.

3.2. Ne gönderilir, ne gönderilmez

Telemetrinin temel ilkesi: ham bilimsel veri, kişisel veri ve sırlar asla gönderilmez. Gönderilen her şey ya bir bayrak, ya bir sayı, ya bir düşük-kardinaliteli sınıf/kovadır. Adres/IP gibi alanlar yalnızca bus tipine indirgenir.

Maskeleme yardımcıları. Gönderim öncesi iki katman uygulanır:

• mask_pii: Metindeki yol-içi kullanıcı adlarını (C:\Users\X, /home/X → <user>) ve çıplak geçen oturum-kullanıcı adını maskeler.
• sanitize_params: Parametre sözlüğünden PII anahtarlarını (ad, operatör, e-posta, not, başlık vb.) sözcük-parçası eşleşmesiyle ayıklar. Önemli incelik: eşleşme tam sözcük parçası üzerindendir; bu yüzden sample_rate veya address gibi PII olmayan ayarlar yanlışlıkla atılmaz, ama sample_name / operator_name / numune_adi atılır.

Parmak-izi (fingerprint) azaltma — kovalama. Ham donanım/ekran değerleri, makineyi benzersizleştirmemek için kovalara indirgenir:

3.3. Rıza (consent) modeli ve coğrafi-kapı

Hangi telemetri kategorilerinin etkin olduğu, kullanıcının bölgesine göre verilen bir coğrafi-kapı ile başlar; nihai söz her zaman kullanıcınındır.

Kategoriler ve hukuki sınıfları:

• notice (P): Bildirimle paketlenebilir; AB-dışı bölgelerde bildirimli varsayılan-açık önerilir.
• consent (R): Her yerde açık irade (opt-in) gerektirir; varsayılan kapalı.

Coğrafi-kapı (ilk varsayılanı belirler):

Olay → kategori eşlemesi (gate). Her olay, gönderilmeden önce eşlendiği kategorinin etkin olup olmadığı kontrol edilerek kapıdan geçirilir. Kategori kapalıysa olay hiç üretilmez. Listede olmayan bir olay, en kısıtlayıcı usage kategorisine düşer (sessiz sızıntı yerine güvenli varsayılan). Kullanıcının bilerek gönderdiği geri bildirim (feedback) bu kapıdan muaftır.

3.4. Geri bildirim (feedback)

Geri bildirim, kullanıcının kasıtlı olarak gönderdiği bir mesajdır ve telemetri rıza kapılarından bağımsız değerlendirilir.

4. Güvenlik (Donanım Güvenli-Durumu)

Bu sistem, cihazla konuşan her yolda en yüksek önceliğin donanımı güvenli duruma getirmek olduğunu garanti eder. Üç sütun vardır: ölçüm-öncesi doğrulama + akım compliance, güvenli-durum sırası ve E-STOP (acil durdurma).

4.1. Ölçüm-öncesi doğrulama ve akım compliance

Hiçbir sweep, parametreleri doğrulanmadan başlamaz. Doğrulama (validate_common_limits) şu kuralları uygular:

Ayrıca uygulanacak her gerilim değeri tek tek max_abs_voltage'a karşı denetlenir (ensure_voltage_values_safe): herhangi bir değer aşarsa ölçüm başlamadan reddedilir.

Güvenlik limitleri config/default_config.json içindeki safety_limits bloğundan gelir:

Compliance vuruşu (compliance hit). Bir ölçüm noktasında cihaz ayarlı akım compliance'ına dayanırsa, bu bir compliance_hit olarak işaretlenir, veriye yazılır ve ölçüm güvenli biçimde sonlandırılır. Telemetri tarafında bu vuruşlar sweep sonunda agrega olarak (toplam vuruş sayısı + ilk vuruş adımı) raporlanır — sıcak döngüye (hot-loop) dokunulmaz.

4.2. Güvenli-durum sırası

Hata, iptal (abort) veya uygulama kapanışında donanım kesin bir sırayla güvenli duruma alınır. Bu sıra, kaynağın önce kesilip ardından anahtarlamanın yapılması ilkesine dayanır (önce de-enerjize et, sonra rölesini aç).

1. SMU çıkışı KAPALI            (Keithley/Keysight/R&S SMU output OFF)
2. Switch Matrix rölesi KAPALI  (relay OFF — örn. switch matrix komutu `a`)
3. Bağlantıların güvenli kapatılması

Kod düzeyinde bu, safe_shutdown ile sağlanır:

• Önce smu.output_all_off() çağrılır (try bloğunda).
• Ardından (finally), bağlam (context) None ise ya da relay_enabled doğruysa relay.all_off() çağrılır. Yani çıkış her durumda kapatılır; röle ise yalnızca ilgili olduğunda açılır.

Çökme/çıkış kapsaması. Yorumlayıcı çıkışında (atexit) ve yakalanmamış istisnada da aynı güvenli-durum geri çağrımı çalışır (device_safety). Sıra: önce donanım güvenli, sonra mevcut hook zinciri (telemetri/log). Bu, Qt closeEvent yolunu tamamlar: Qt-dışı, başsız (headless) veya anormal sonlanmalar da kapsanır. Güvenli-durum kancası kendi hatasını yutar ve asla çıkış/raporlama zincirini çökertmez.

4.3. E-STOP (Acil Durdurma)

E-STOP düğmesi ("ACİL DURDUR" / EMERGENCY STOP), tüm donanımı anında güvenli duruma alan öne çıkan bir kontroldür. Diğer donanım widget'larının aksine, E-STOP niyet yayıp sahibinin işlem yapmasını beklemez; tıklandığı an doğrudan güvenli-all işlemini çalıştırır, ancak ondan sonra sonucu (hedef başına çıktı) yayar.

Tetiklenme sırası (H3 garantisi): trigger() iki fazda çalışır ve hiçbir fazda kısa devre yapmaz (bir hedefin hatası diğerlerini durdurmaz):

Faz 1: Tüm worker-stopper'lar  (QThread işçileri önce durdurulup join edilir)
Faz 2: Tüm cihaz güvenli-fonksiyonları (donanım çıkış-kapatma ikinci sırada)

Bu sıra, GUI iş parçacığı ile geride kalmış bir işçinin aynı SMU'ya eşzamanlı erişmesini önler (önce işçiyi durdur, sonra donanımda output-off uygula).

Güvenli-durum metodu seçimi. Denetleyici, her cihazın ilk bulunan güvenli-durum metodunu öncelik sırasıyla çağırır:

Bir RoleBinding (rol bağlaması) kaydedilirken sıra önemlidir: smu → relay → thermometer. Yani kaynak (SMU) röleden önce güvenceye alınır. Bilinen güvenli metotlardan hiçbirini sunmayan bir cihaz (örneğin henüz safe_off kazanmamış bir sıcaklık denetleyicisi) atlanır ve adı çağırana döndürülür; böylece eksiklik tezgâhta sürpriz olmak yerine önceden yüzeye çıkar.

Sonuç (EStopResult):

Arayüz, sonuca göre mesaj gösterir: tümü güvenliyse "Acil durdurma: tüm cihazlar güvenli."; bir kısmı alınamadıysa "Acil durdurma: bazı cihazlar güvenceye alınamadı."

Diğer önemli davranışlar:

• Idempotent: E-STOP bir kez ateşlendikten sonra tekrarlanan tetiklemeler (örn. üst-çubuk tıklaması ardından closeEvent'in acil-durdurma çağrısı) işlemsizdir; worker-stopper'lar/güvenli-fonksiyonlar iki kez koşmaz. Yeni bir ölçüm için reset() ile yeniden kurulur.
• Erişilebilirlik (a11y): Düğmenin erişilebilir adı, durumuna göre güncellenir: "ACİL DURDUR — hazır (çıkışlar durdurmaya hazır)" (armed) veya "ACİL DURDUR — aktif (durdurma işlemi sürüyor)" (live). Ekran okuyucular bu durumu seslendirir.
• Görsel nabız (pulse): Düğme, dikkat çekmek için opaklık nabzıyla yanıp söner — hazır durumda yavaş (1800 ms, 1.0→0.70), aktif/ölçüm sürerken hızlı (600 ms, 1.0→0.45). Kullanıcı azaltılmış hareket (reduced motion) tercih ediyorsa (Windows erişilebilirlik ayarı / Qt) animasyon hiç oluşturulmaz.
• Çökme kapsaması: Aynı güvenli-all, başlangıçta device_safety'ye bağlanır; böylece bir çökme / yakalanmamış istisna / çıkışta da çalışır.

4.4. Kalibrasyon hatırlatıcısı

Yazılım, tezgâh araçlarındaki (ör. BenchVue) hatırlatma özelliğini örnek alarak, yeniden kalibrasyonun zamanı geçtiğinde açılışta bir uyarı kaydeder. Hesap, saf tarih aritmetiğidir (G/Ç yok, açılışı bloklamaz).

Kalan gün hesabı (days_until_calibration_due):

girdi  : last_date (ISO), interval_days, today (bugün)
formül : kalan = (last_date.gün_sırası + interval_days) - today.gün_sırası
çıktı  : kalan (gün)   — negatif değer = süresi geçmiş (overdue)
özel   : last_date boş/geçersiz VEYA interval_days <= 0  ->  None (hatırlatma yok)

Açılışta, hatırlatıcı etkinse ve kalan < 0 ise yerel günlüğe şu uyarı düşer:

WARNING | Calibration overdue by <N> day(s)

Ayar konumu: Ayarlar > Donanım > Kalibrasyon.

Özet: Hızlı Başvuru