Gömülü sistemlerde watchdog: donunca kendini kurtarmak

Watchdog nedir, neden ana döngüde körlemesine beslenmez? Küçük ekipler için bağımsız saat, sağlık kontrolü, reset nedeni kaydı ve saha testi üzerinden sade bir rehber.

Giriş

Sahadaki bir cihaz bir gün cevap vermez. Güç var, LED yanıyor, ama haberleşme susmuş veya ekran donmuş kalmıştır. Laboratuvarda “bir reset atınca düzeldi” demek yetmez; ürünün kendi kendine toparlanması gerekir.

Watchdog (bekçi zamanlayıcı) tam bu iş içindir: yazılım belirli bir süre içinde “hâlâ sağlıklıyım” demezse donanım sistemi sıfırlar. Bu yazıda küçük ekipler için abartısız bir çerçeve kuruyoruz — neyi korur, nasıl beslenir, reset nedeni nasıl kaydedilir ve HIL/OTA ile nasıl bağlanır. Amaç katalog ezberi değil; sahada işe yarayan bir düzen.

Watchdog neyi garanti eder, neyi etmez?

Watchdog, “CPU bir yerde takıldı veya kritik iş ilerlemedi” senaryosuna karşı bir sigortadır. Tipik olarak bir sayaç geriye doğru akar; yazılım onu zamanında yenilemezse (kick / feed / refresh) reset veya kesme üretilir.

Garanti ettiği şey sınırlıdır:

• Yazılımın ilerleme gösterdiğini (veya en azından kick yolunun çalıştığını) belli bir süre içinde doğrular.
• Ana saat çökerse bile çalışan bir bağımsız saatli watchdog varsa, o çöküşü de yakalayabilir.

Garanti etmediği şeyler:

• Yanlış ama “düzenli” çalışan kod (sensör çöp üretiyor, protokol kilitli, ama kick geliyor).
• Güç rayının çökmesi veya yarı voltajda bozulma — bu brownout / supervisor işidir.
• Flash yazımı ortasında kesilen OTA — bunun için ayrı boot ve geri dönüş stratejisi gerekir.

Watchdog tek başına “güvenilir ürün” değildir; güç denetimi, reset nedeni kaydı ve testle birlikte bir pakettir.

İç mi dış mı, pencere mi süre mi?

Küçük ekiplerin sık gördüğü üç seçenek:

• MCU içi bağımsız watchdog (ör. birçok STM32’de IWDG): Ayrı bir osilatörden beslenir; ana PLL/saat bozulsa bile çalışmaya devam edebilir. Yazılımla kolayca kapatılamaması (veya bir kez açılınca reset’e kadar kapanmaması) avantajdır.
• Pencereli (window) watchdog: Yenileme hem çok geç hem çok erken olursa hata sayılır. Sonsuz döngüde “sürekli kick” yapan kodu da yakalar; zamanlama disiplini ister.
• Harici watchdog / reset supervisor: MCU’dan bağımsız bir entegre; yazılımın watchdog’u kapatabildiği veya CPU’nun tamamen kilitlendiği senaryolarda ikinci katman olur. Eşik voltajı, reset gecikmesi ve bazen aynı pakette brownout algılama sunar.

Pratik kural: çoğu ürün için önce iyi yapılandırılmış iç watchdog + brownout/supervisor yeter. Emniyet veya yüksek erişilebilirlik hedefi varsa harici katmanı düşünün. “Hangi chip en iyisi?” sorusu yerine “hangi arıza alanını kim kapsıyor?” sorun.

Besleme kuralı: sağlık toplanır, sonra kick

En sık hata, ana döngüde veya bir timer kesmesinde koşulsuz kick atmaktır. Bu yalnızca “CPU tick atıyor”u kanıtlar; sensör görevi ölmüş, CAN hattı kilitli veya bellek dolmuş olsa bile watchdog mutlu kalır.

Daha sağlam düzen:

1. Kritik görevler (haberleşme, ölçüm, güvenlik çıkışları, depolama) periyodik olarak “sağlıklıyım” bayrağı düşürür.
2. Tek bir yer — genelde düşük öncelikli bir denetçi — bu bayrakları toplar.
3. Hepsi makul sürede yeşilse watchdog beslenir; biri eksikse beslenmez ve reset gelir (veya önce yumuşak toparlanma denenir).

Kesme içinde körlemesine beslemeyin. Erken uyarı kesmesi (bazı pencereli watchdog’larda) varsa orada kick atmak yerine durumu kaydedin; sistem zaten arızalıdır.

Reset nedenini yazmazsanız, reset boşa gider

Watchdog’un değeri çoğu zaman reset’ten sonra başlar. Açılışta donanımın sunduğu reset bayraklarını (watchdog, brownout, güç-açma, yazılım reset’i) okuyun ve kalıcı bir yere (FRAM, flash’ta küçük bir log alanı, veya en azından bir sonraki oturumun okuyacağı bir ring buffer) yazın.

Saha için faydalı minimum:

• Son N reset’in nedeni ve kabaca zaman damgası / sayaç.
• Mümkünse hangi görev veya hangi alt sistem “sağlık” vermedi.
• Ardışık watchdog reset’i belirli eşiği aşarsa güvenli mod (sınırlı I/O, OTA bekleme, sıkı log) — sonsuz reset döngüsünü kırmak için.

“Bir reset attık, düzeldi” cümlesi telemetri olmadan ürün bilgisidir, teşhis değildir.

Brownout ve güç: watchdog’un kardeşi

Voltaj yavaş düşerken MCU rastgele bozulabilir; watchdog bunu “yazılım hatası” sanıp resetleyebilir veya daha kötüsü, flash yazımı ortasında bırakabilir. Bu yüzden:

• Kritik rayları eşiği ve histerezisi bilinen bir supervisor ile izleyin.
• Reset’i, raylar stabilize olana kadar tutun; “güç geldi” ile “yazılım koşsun” aynı an değildir.
• OTA ve yapılandırma yazımlarında voltaj/marj kontrolü yapın; şüpheliyse yazmayı erteleyin.

Watchdog yazılım kilitlenmesini, supervisor güç kilitlenmesini hedefler. İkisini birbirinin yerine koymayın.

Bootloader ve OTA ile çakışma

Watchdog açıldıktan sonra bootloader uzun sürerse (yavaş UART, büyük flash yazımı) süre dolup ortada reset yiyebilirsiniz. Üç pratik yol:

• Boot ve uygulama için farklı timeout (mümkünse): açılışta uzun, koşuda kısa.
• Bootloader’ın da watchdog’u bilmesi ve yazım döngüsünde beslemesi — ama yine ilerleme şartına bağlayarak (sektör yazıldı, CRC adımı geçti).
• OTA sırasında “eski imaj çalışır, yeni imaj doğrulanmadan geçilmez” düzeni; watchdog reset’i yarım yazılmış imaja mahkûm etmemeli (OTA yazısı).

Debug’da watchdog’u tamamen kapatıp sahada açmak da ayrı bir tuzak: laboratuvarda hiç görülmeyen timing hataları sahada ortaya çıkar. Mümkünse debug’da dondurma (halt’ta sayaç durur) kullanın; üretim yapılandırmasını erken açın.

HIL ve saha testi: bilerek bozun

Watchdog’u “açık” bırakmak test sayılmaz. Bilerek bozun:

• Her kritik görevi sırayla asın; reset gelmeli ve log doğru nedeni yazmalı.
• Koşulsuz kick yolunu geçici açıp kapatın; pencere varsa erken kick’i de deneyin.
• Voltajı kontrollü düşürün (brownout); davranışın watchdog senaryosundan ayrıştığını görün.
• Bu senaryoları HIL masasında tekrarlanabilir hale getirin — sahaya çıkmadan önce.

Test edilmemiş watchdog, kapalı bir sigorta kutusundaki etiket gibidir: var sanılır, günü gelince belli olur.

Sık yapılan hatalar

• Ana döngüde kör kick: Sistem “canlı” görünür, iş ölüdür.
• Kesmede besleme: Öncelik tersine döner; asıl iş açlıktan ölür, watchdog mutlu kalır.
• Reset nedenini okumamak: Aynı arıza yüzlerce kez tekrarlar, kimse fark etmez.
• OTA/boot süresini unutmak: Güncelleme ortasında reset = tuğla riski.
• Yalnızca yazılım watchdog’u: Yazılımın kapatabildiği koruma, yazılım arızasına karşı tam koruma değildir.
• Alarm fırtınası: Her reset’te agresif dış alarm; önce sınıflandırın (tek seferlik glitch mi, döngü mü).

Sonuç

Watchdog bir checkbox değil; “donunca ne olur?” sorusuna verilen yazılı cevaptır. Bağımsız saate yakın bir zamanlayıcı seçin, kick’i sağlık toplamasına bağlayın, reset nedenini kalıcı yazın, güç denetimini yanında tutun ve HIL’de bilerek bozarak doğrulayın. OTA ve bootloader ile aynı hikâyenin parçası olsun; aksi halde koruma, güncelleme anında size karşı çalışır.

TW Bilişim olarak gömülü yazılım işlerinde güvenilirliği ayrı bir “faz” değil, mimarinin parçası olarak ele alıyoruz: haberleşme, OTA, test ve saha telemetrisiyle aynı masada.

SSS

Watchdog timeout’u kaç saniye olmalı? “Sistem yanlış çalışmaya ne kadar süre devam edebilir?” sorusunun cevabı. Kullanıcıya veya aktüatöre zarar vermeyen üst sınırı seçin; gereksiz yere çok kısa tutmak sahada gürültülü reset üretir. Açılış için ayrı, daha uzun bir süre düşünün.

Pencereli watchdog her üründe şart mı? Hayır. Zamanlama disiplini ve “erken kick” riski olan tasarımlarda değerlidir. Basit periyodik işlerde iyi kurgulanmış bağımsız bir süre watchdog’u çoğu ihtiyacı karşılar.

Reset yerine kesme yetmez mi? Bazen yumuşak toparlanma (alt sistemi yeniden başlatmak) yeter. Kalıcı kilitlenmede yine tam reset gerekir. Kesmede kick atmayın; durumu kaydedip kontrollü toparlanmaya geçin.

Harici watchdog’a ne zaman geçilir? Yazılımın iç watchdog’u kapatabildiği, emniyet veya yüksek erişilebilirlik istediğiniz, veya MCU’nun tamamen kilitlenme senaryosunu da kapsamak istediğinizde. Maliyet ve PCB alanı bilinçli bir takastır.

Gömülü bir üründe watchdog, brownout ve OTA düzenini sadeleştirmek veya saha reset loglarını okunur hale getirmek isterseniz, kısa bir görüşmeyle mimarinize bakabiliriz: iletişim veya [email protected].