Gömülü bir cihazın aylarca çalışması, yalnızca ana döngünün normal koşullarda doğru işlemesine bağlı değildir. Haberleşme kilitlenmesi, kısa besleme düşmesi veya bozuk bir kayıt; yazılımı beklenmeyen duruma taşıyabilir. Watchdog ve brown-out mekanizmaları bu durumlarda toparlanmaya yardımcı olur. Ancak düşünülmeden eklenen bir reset, hatayı gizleyebilir veya çıkışları istenmeyen biçimde değiştirebilir.
01Watchdog hangi başarısızlığı izlemeli?
Watchdog belirli süre içinde yenilenmezse tanımlı bir tepki üretir. Temel hata, ana işlerin gerçekten ilerlediğini kontrol etmeden bir zamanlayıcı kesmesinden watchdog'u sürekli beslemektir. Haberleşme görevi kilitlenmiş olsa bile kesme çalışıyorsa cihaz sağlıklı görünmeye devam edebilir.
Daha anlamlı bir yaklaşım, kritik görevlerin ilerleme bilgilerini izlemektir. Ölçüm, kayıt ve haberleşme görevleri kendi sağlık işaretlerini günceller; denetleyici bunların beklenen zaman penceresinde ilerlediğini kontrol eder. Her görevin çevrim süresi aynı olmadığından tek bir rastgele zaman aşımı bütün sisteme uygulanmamalıdır.
02Kesme, görev ve donanım denetimi farklıdır
Örneğin ESP-IDF'de kesme watchdog'u ve görev watchdog'u farklı problemleri hedefler. Uzun süre kesmelerin engellenmesi ile bir görevin işlemciyi bırakmadan dönmesi aynı arıza değildir. Seçilen mikrodenetleyici ve yazılım sürümünün davranışı üretici dokümanından doğrulanmalıdır; bir platformun varsayılanları diğerine taşınmaz.
Hata ayıklayıcı bağlıyken watchdog davranışı değişebilir. Bu nedenle yalnızca breakpoint kullanılarak yapılan masa testi yeterli değildir. Üretime yakın derleme, gerçek zamanlama ve hata ayıklayıcı olmadan da doğrulanmalıdır. Watchdog'u kapatarak geçen test, toparlanma tasarımını doğrulamaz.
03Brown-out bir yazılım takılması değildir
Besleme gerilimi işlemcinin güvenilir çalışma aralığının altına indiğinde kodun doğru yürütüleceği varsayılamaz. Brown-out algılama, uygun eşikte reset veya başka bir güvenli davranış sağlar. Eşik seçilirken işlemci, harici bellek ve bağlı çevre birimlerinin gereksinimleri birlikte değerlendirilir.
Besleme düşmesinin nedeni de araştırılmalıdır: yetersiz regülatör, ani radyo akımı, uzun bağlantı, zayıf dekuplaj veya dış yükün etkisi olabilir. Brown-out'u devre dışı bırakmak, güç sorununu çözmez; yalnızca belirtilerini farklılaştırabilir. Gerekirse besleme gözetleyicisi ve güç sıralaması donanım tasarımına dahil edilir.
04Reset sonrası çıkışlar ne olacak?
Bir işlemcinin yeniden başlaması, bağlı röle veya sürücünün güvenli duruma geçeceğini otomatik olarak garanti etmez. Reset anındaki pin durumları, harici çekme dirençleri, çıkış sürücüsü ve aktüatörün enerji kesilmesindeki davranışı birlikte düşünülür. Güvenlik gerektiren işlevler, sıradan bir yazılım resetine bağımlı bırakılmaz.
| Olay | Tasarımda yanıtlanacak soru |
|---|---|
| Görev kilitlenmesi | Hangi işin ilerlemediği kaydediliyor mu? |
| Besleme düşmesi | Reset eşiği tüm önemli bileşenlere uygun mu? |
| Art arda reset | Sonsuz yeniden başlama yerine kontrollü mod var mı? |
| Kayıt yarım kalması | Önceki geçerli yapılandırmaya dönülebiliyor mu? |
| Bağlantı gelmemesi | Ölçüm ve yerel işlevler devam edebiliyor mu? |
05Veri bütünlüğünü resetten bağımsız ele alın
Enerji kesilirken flash veya dosya yazımı yarım kalabilir. Sürüm numarası, uzunluk, bütünlük kontrolü ve önceki geçerli kopya gibi yöntemlerle yapılandırma doğrulanabilir. CRC yanlışlıkla oluşan veri bozulmasını saptamaya yardımcıdır; kimlik doğrulama veya saldırıya karşı koruma sağlamaz.
Örnek bir ayar kaydında önce yeni içerik hazırlanıp doğrulanır, ardından geçerli sürüm işaretlenir. İşlem yarıda kesildiğinde cihaz rastgele varsayımlarla üretim parametresi seçmemelidir. Varsayılanlara dönülecekse bunun operatöre nasıl bildirileceği ve hangi çıkışların kısıtlanacağı tanımlanmalıdır.
06Hata enjeksiyonuyla doğrulayın
Planlı testte haberleşme yanıtı geciktirilebilir, bir görev bilinçli olarak durdurulabilir veya kontrollü düşük gerilim senaryosu uygulanabilir. Beklenen reset nedeni, açılış süresi, kayıt bütünlüğü ve çıkış davranışı gözlenir. Testler uygun laboratuvar düzeneğinde yapılır; çalışan makinede kontrolsüz enerji denemeleri yapılmaz.
Reset nedenini ve son sağlıklı çalışma adımını kaydetmek sonraki teşhisi kolaylaştırır. Fakat log işleminin kendisi sistemi kilitlememeli veya belleği gereksiz yıpratmamalıdır. İyi bir toparlanma mimarisi, cihazı yalnızca yeniden başlatmaz; neden durduğunu anlamaya ve güvenli biçimde tekrar hizmete almaya da yardımcı olur.
07Örnek doğrulama senaryosu
Bir haberleşme görevinin yanıt beklerken süresiz kaldığı varsayılsın. Testte ölçüm görevinin devam edip etmediği, sağlık denetiminin hangi gecikmede hatayı yakaladığı ve reset nedeninin kaydedilip kaydedilmediği izlenir. Sonra aynı hata art arda uygulanır. Cihazın sonsuz reset döngüsüne girmesi yerine tanımlanmış kontrollü davranışı göstermesi beklenir. Yapılandırma ve çıkış durumları her açılışta karşılaştırılarak toparlanmanın veri kaybı veya istenmeyen hareket üretmediği doğrulanır.
Teknik kaynaklar ve ileri okuma
Ürün ve sürüm özelindeki değerler için ilgili üreticinin güncel dokümanı esas alınmalıdır. Yukarıdaki hesaplar ve senaryolar açıklama amaçlı mühendislik örnekleridir.
