Watchdog dan Eskalasi Fault

Kenapa halaman ini penting

Halaman ini menjelaskan bagaimana Watchdog dan Eskalasi Fault masuk ke model eksekusi ZeroKernel yang lebih besar, masalah apa yang sebenarnya diselesaikan, dan trade-off apa yang benar-benar Anda bayar saat fitur ini dipakai di firmware produksi. Tujuannya bukan melihat Watchdog dan Eskalasi Fault sebagai satu API terpisah, tetapi memahami posisinya di dalam bounded scheduling, disiplin queue, visibilitas fault, dan pemilihan profile.

Baca topik ini sebagai kontrak operasional. Mulai dari jalur paling kecil yang benar-benar jalan, pasang dulu di profile lean, lalu baru naik ke routing, diagnostics, atau state transport yang lebih kaya setelah Anda bisa membuktikan hasil timing-nya tetap layak dibanding tambahan flash dan RAM. Pola pikir ini yang menjaga ZeroKernel tetap berguna di board kecil dan tidak berubah jadi abstraksi yang gemuk.

Pola paling aman selalu sama: tentukan batas runtime-nya, jaga hot path tetap pendek, ukur efeknya dengan compare script, lalu baru naikkan kompleksitas. Contoh di bawah bukan pemanis; itu adalah pola minimum yang bisa Anda ambil ke firmware nyata saat Anda butuh integrasi yang rapi, bukan loop manual yang sulit dipertahankan.

Tiga pola yang langsung bisa dipakai

    ZeroKernel.begin(boardMillis);
ZeroKernel.addTask("Fast", fastTask, 10, 0, true);
ZeroKernel.tick();
  

    const auto key = ZeroKernel.makeTopicKey("telemetry.sample");
ZeroKernel.publishDeferredFast(key, sampleValue);
ZeroKernel.flushEvents();
  

    const auto stats = ZeroKernel.getStats();
const auto timing = ZeroKernel.getTimingReport();
Serial.println(timing.maxTickMs);
  

Apa yang perlu Anda cek saat memakainya

• Validasi timing lebih dulu, baru bentuk API. API yang terlihat rapi bukan kemenangan kalau fast miss justru naik.
• Pilih profile paling kecil yang masih cocok, lalu aktifkan modul opsional hanya saat payoff terukurnya benar-benar jelas.
• Jaga callback dan langkah transport tetap bounded supaya watchdog, panic flow, dan batas queue tetap punya arti.

Kesalahan umum yang membuat hasil jadi menyesatkan

• Jangan menyalin pola demo ke firmware produksi tanpa mengukurnya di board dan profile build yang benar-benar akan dipakai.
• Jangan membaca angka sukses tanpa membaca queue depth, timing, dan label workload di sampingnya.
• Jangan menyalakan diagnostics atau kompatibilitas berat di target lean hanya karena default-nya terasa nyaman.

Urutan kerja yang disarankan

Apa sebenarnya fungsi watchdog

Watchdog di ZeroKernel bukan thread penyelamat ajaib. Ia adalah cara runtime mengubah kegagalan cooperative yang diam menjadi state sistem yang terlihat. Dalam firmware embedded, “tidak terjadi apa-apa” justru sering menjadi bentuk failure yang paling berbahaya.

Saat task berhenti heartbeat, terlalu sering melewati budget eksekusi, atau menghabiskan failure budget-nya, watchdog memberi runtime jalur eskalasi yang terstruktur. Itu bisa berarti masuk degraded mode, mematikan pekerjaan non-kritikal, naik ke safe mode, atau memicu panic saat sistem memang sudah tidak bisa melanjutkan progress yang aman.

Tujuan utamanya adalah visibilitas dulu, respons terkontrol sesudahnya. Itulah yang membuat model cooperative tetap layak dipakai di workload perangkat nyata.

Input utama watchdog

Tiga setup watchdog yang paling umum

    ZeroKernel.setTaskHeartbeatTimeout("Sensor", 250);
ZeroKernel.heartbeatTask("Sensor");
  

Ini pola minimum untuk task kritikal yang harus membuktikan bahwa ia masih hidup selama operasi normal.

    ZeroKernel.setTaskHeartbeatTimeout("NetPump", 750);
ZeroKernel.setTaskExecutionContract("NetPump", contract);
ZeroKernel.setWatchdogPolicy(policy);
  

Ini mengikat liveness dan policy agar jalur transport yang noisy tidak boleh gagal diam-diam terlalu lama.

    if (fatalFault) {
  ZeroKernel.triggerPanic("watchdog_escalation");
}
  

Ini dipakai untuk kondisi yang memang tidak layak diteruskan karena melanjutkan eksekusi lebih berbahaya daripada berhenti.

Apa yang tidak dilakukan watchdog

Watchdog tidak bisa mem-preempt call I2C yang macet, membelah socket operation yang sedang blocking, atau memundurkan driver yang sedang tersangkut di fungsi library. Dalam runtime cooperative, ia tidak bisa memutus callback yang sedang berjalan.

Yang bisa dilakukan adalah mengungkap fault itu secepat mungkin, mencatat bahwa task telah melanggar kontraknya, dan mendorong runtime masuk ke state yang membuat kegagalan tidak lagi diam. Itu tetap keuntungan operasional yang besar, karena alternatifnya sering kali hanyalah freeze yang tidak jelas sumbernya.

Cara membaca data watchdog dengan benar

Lihat counter watchdog bersama timing counter. Jika overrun naik bersamaan dengan queue depth, akar masalahnya mungkin konsentrasi beban. Jika heartbeat timeout muncul tanpa pertumbuhan queue, kemungkinan task-nya sendiri sedang stall. Jika panic terjadi setelah failure budget terus terlampaui, execution contract kemungkinan besar justru bekerja sebagaimana mestinya.

FAQ watchdog