Gömülü Sistemlerde WATCHDOG Kurgusu: Stratejik Rehber

[slimandheavy]

Gömülü Sistemlerde WATCHDOG Kurgusu: Stratejik Rehber

1. Mimari Felsefe
Watchdog'un (WD) gerçek amacı sistemin donmasını engellemek değil, donan sistemin en kısa sürede kurtulmasını (recovery) sağlamaktır. WD sadece bir zamanlayıcı değil, sistemin doğru çalıştığını onaylayan bir sağlık denetçisidir.

Yanlış kurulmuş bir WD, hiç olmamasından daha tehlikelidir
size güvenlik yanılsaması verir. Bu yüzden WD, yazılımın bir parçası gibi değil, yazılımı dışarıdan denetleyen bir mühendislik disiplini gibi kurgulanmalıdır.

2. Donanım Katmanları (Defense in Depth)
Güvenli bir sistemde tek bir denetleyici yetmez; katmanlı savunma şarttır:

• Bağımsız WD: Ana saatten bağımsız kendi osilatörüyle çalışır. CPU kilitlense bile sistemi resetler. Birincil savunmadır. (STM32: IWDG, NXP Kinetis: COP, TI Hercules: RTI-WDT, Microchip: WDT)
• Pencere WD: Sadece zaman aşımını değil, erken beslemeyi de denetler. Akış disiplini sağlar. (STM32: WWDG, TI: DWT, NXP: EWM)
• Harici WD: MCU tamamen fiziksel olarak çöktüğünde (EMI, voltaj hatası vb.) dışarıdan reset atan bağımsız çiptir. (TPS3823, MAX706 sınıfı)

3. Pencere (Window) Modu: Akış Kontrolü
Standart WD, süresi dolmadan herhangi bir zamanda beslenebilir. Bu durum, sonsuz bir döngüde (runaway loop) takılan kodun WD'yi beslemeye devam etmesine yol açabilir.

Kritik Kural: Window modu, besleme için bir alt sınır belirler. Çok erken besleme yapıldığında (mantık hatası varsayılarak) sistem anında resetlenir.

4. İdeal Besleme Stratejisi: Supervised Watchdog
WD beslemesi asla rastgele veya kesme (ISR) içinden yapılmamalıdır. En profesyonel yaklaşım Checkpoint mekanizmasıdır:

Mekanizma:

• Heartbeat: Her kritik görev (Haberleşme, Kontrol vb.) döngüsünü bitirdiğinde bir bayrak set eder.
• Supervisor Task: En yüksek öncelikli bu görev, tüm bayrakları denetler.
• Karar: Ancak tüm görevler "sağlıklı" raporu verirse WD beslenir. Bir görev bile takılırsa sistem kilitlenmiş sayılır ve reset beklenir.

Temel kod iskeleti:

// Her kritik task kendi içinde:
void critical_task(void) {
    do_work();
    hb[TASK_ID].alive_counter++;   // "ben yaşıyorum"
}

// Supervisor — en yüksek öncelikli, sadece bu iş için:
void supervisor_task(void) {
    if (tüm_taskların_counter'ı_arttı()) {
        wdt_feed();
    }
    // Aksi halde → timeout → reset
}

Bare-metal senaryosu:
RTOS kullanmıyorsan mantık aynı, sadece "task" yerine "state" geçer. Ana state machine'de her state geçişinde bit set edilir; WD ancak tüm state'lerden beklenen sırayla geçildiğinde beslenir.

5. Timeout Süresinin Belirlenmesi
Çok kısa timeout → jitter'da bile false reset. Çok uzun → sistem donduğunda kimse farkına varmaz.

Pratik kural: Worst-case task süresinin 2–3 katı. Örnek: 20 ms'de dönmesi gereken task için 50–200 ms tipik WD timeout'udur.

• Uygulama alanına göre tipik aralıklar:
• Otomotiv ECU (safety-critical): 10–100 ms
• Endüstriyel ölçüm/kontrol: 100 ms – 2 s
• IoT / telemetri: 1–10 s
• Tüketici elektroniği: 500 ms – 5 s

Bunlar başlangıç referansı; gerçek değer WCET analiziyle belirlenir.

6. İki Seviyeli Denetim (Soft + Hard)

• Donanım erken uyarı kesmesi (Early Warning Interrupt): WWDG gibi pencere WD'lerinde, timeout'tan hemen önce interrupt üretilir. Son anda crash log'u Backup SRAM'a yazılabilir.
• Soft WD (yazılımsal supervisor): Task heartbeat'lerini izler. Timeout'ta önce graceful degradation dener — hata logla, güvenli state'e geç, belki task restart.
• Hard WD (donanımsal): Soft WD kilitlenirse sistemi fiziksel olarak yeniden başlatır. Son çare.
• Soft WD akıllıdır (tek task restart edebilir), ama kendisi de yazılımdır → kilitlenebilir. Hard WD bu yüzden son güvencedir.

7. Fault Sınıflandırması
Her fault reset gerektirmez:

• Recoverable fault: Logla, degrade mode'a geç, çalışmaya devam et. Örnek: Bir haberleşme kanalı düştü → alternatif kanaldan devam.
• Unrecoverable fault: Safe state'e geç (aktüatörler güvenli konumda), WD beslemeyi bırak, kontrollü reset bekle.

Her fault için refleks reset atmak olgunluk değildir; kategorize etmek olgunluktur.

8. Reset Sonrası Tanılama (Post-Mortem)
Sistem resetten döndüğünde hiçbir şey olmamış gibi davranmamalıdır:

• Reset Reason: İşlemcinin reset register'ı okunarak hatanın WD kaynaklı olup olmadığı belirlenmelidir.
• Boot Loop Koruması: Eğer kısa sürede ardışık resetler oluyorsa sistem "Safe Mode"da başlamalıdır.
• Kalıcı Log: Hata kodu, hangi task'ın çöktüğü ve uptime bilgisi telemetri kanalıyla bildirilmelidir.
• Saha verisi: Cihazlar her boot'ta önceki reset bilgisini geri göndermeli; firmware versiyonlarına göre reset oranı trend edilmelidir — yeni sürümde artma varsa regresyon işaretidir.

9. Boot Sırasında Watchdog
Doğru başlatma akışı önemlidir:

• Clock init
• RAM init
• Kritik peripheral init
• WD aktive
• Ana loop / scheduler başlar

Bazı MCU'larda WD, power-on reset sonrası otomatik aktif gelir (configuration fuse ile). Bu durumda init kodunun WD'yi bilinçli beslemesi gerekir — aksi halde init tamamlanamadan reset atılır.

10. Güvenli Durum (Safe State) Tasarımı
WD stratejisi, donanım tasarımıyla birleşik düşünülmelidir.

Donanımsal Reset: Reset anında pinler varsayılan (pull-up/down) durumuna döner.
Kritik Çıkışlar: Motor sürücüleri veya ısıtıcılar gibi kritik çıkışların reset anında donanımsal olarak "kapalı" konumda kalması garanti edilmelidir. MCU'nun yazılımsal reset sonrası "güvenli değere yazma"sı garanti değildir.
WD stratejisi = reset + safe output design birlikte düşünülür.

11. Tam Kapsamlı Watchdog Anti-Pattern Kontrol Listesi
Bir sistemin Watchdog tasarımı, aşağıdaki maddelerden birini bile içeriyorsa "zayıf" kabul edilir:

A. Yanlış Besleme (Feeding) Hataları

• ISR İçinde Besleme: Watchdog'u bir Timer veya SysTick kesmesi içinde beslemek. (Ana döngü donsa bile kesmeler çalışmaya devam edebilir; WD sistemi resetlemez.)
• Dağınık Besleme: Kodun onlarca farklı yerinde WDT_Refresh() çağırmak. (Mantıksal akışın nerede koptuğunu izlemeyi imkansız kılar.)
• Koşulsuz Besleme: Ana döngü (super-loop) her döndüğünde, alt görevlerin başarısını kontrol etmeden besleme yapmak.
• Çoklu Görev Karmaşası: RTOS sisteminde her task'ın bağımsız olarak WD beslemesi. (Bir task kilitlense bile diğerleri sistemi "hayatta" gösterebilir.)

B. Yapılandırma ve Donanım Hataları

• Pencere (Window) Modunun Devre Dışı Olması: Sadece "geç" beslemeyi denetlemek, "aşırı hızlı" (runaway loop) döngü hatalarını kaçırmak.
• Saat Kaynağı Bağımlılığı: Watchdog'un, ana sistem saatinden (HSE/PLL) beslenmesi. (Kristal durursa WD de durur.)
• Debug Freeze Eksikliği: Debug modunda breakpoint'e düşüldüğünde WD'nin dondurulmaması. (Geliştirme sürecinde sürekli reset atılmasına neden olur.)
• Üretim Yazılımında Freeze Unutulması: Debug modundaki "dondurma" özelliğinin release sürümünde açık bırakılması. (Sahadaki gerçek donmaların WD tarafından görmezden gelinmesi.)

C. Reset ve Kurtarma Hataları

• Reset Sebebi Analizsizliği: Sistem açıldığında RCC_CSR gibi register'lara bakıp resetin WD kaynaklı olup olmadığını kontrol etmemek.
• Körleme Başlangıç: WD resetinden sonra hiçbir şey olmamış gibi sisteme devam etmek. (Hatanın kök nedenini bulmayı engeller.)
• Boot-Loop Korumasının Olmaması: Ardışık WD resetleri durumunda sistemi "Safe Mode"a geçirmemek. (Cihazın sonsuz bir döngüde kalarak donanıma zarar vermesi.)
• Telemetri Eksikliği: WD reset bilgilerini (uptime, kilitlenen task) kalıcı belleğe (EEPROM/Flash) veya merkeze raporlamamak.

D. Mimari ve Emniyet Hataları

• Tek Katmanlı Savunma: Sadece donanımsal WD kullanıp, yazılımsal (soft) bir denetleyici katmanı (Supervisor) oluşturmamak.
• Geçersiz Timeout Süresi: WD süresini "Worst-Case Execution Time" (WCET) analizine göre değil, tahmini belirlemek.
• Safe-State İhmali: Reset anında donanım çıkışlarının (PWM, Röle, Motor) güvenli konuma geçmesini donanımsal (pull-up/down) olarak garanti etmemek.
• Startup Gecikmesi: Bootloader veya uzun süren init işlemleri sırasında WD'yi beslemeyi unutmak (Init tamamlanmadan reset atılması).
• Fault Sınıflandırması Yok: Her fault için refleks reset atmak; recoverable/unrecoverable ayrımını yapmamak.

İdeal Tasarımın Özeti
İdeal bir mimari; bağımsız bir clock kullanan, pencere disipliniyle çalışan, tüm görevleri checkpoint ile denetleyen ve reset sonrası "neden öldüğünü" raporlayabilen bir yapıdır.