Es difícil argumentar que el reloj interno del perro guardián interno es en realidad independiente de todos los demás relojes y siempre funciona como debería.
Por lo tanto, para la certificación, generalmente es mucho más fácil colocar un perro guardián externo en el tablero y decir: miren que está nuestro perro guardián, debe ser activado por la MCU en ese intervalo, que es más corto que nuestro tiempo de falla, por lo que nuestro dispositivo es seguro como lo definimos.
Para abordar algunos de los comentarios:
"y siempre corriendo como debería" - Buen punto. Puede ser más difícil demostrar que su software inicializa correctamente el perro guardián interno en todas las circunstancias que solo emplear un chip de perro guardián y consultar su hoja de datos.
Esto generalmente se prueba mediante una prueba de inserción de fallas, que usted presenta a un organismo de certificación. Entonces les muestra el código donde ocurre su inicialización, y donde ocurre la activación del perro guardián. Por lo general, le solicitan que modifique el código de tal manera que se detenga la activación del perro guardián después de un cierto tiempo y que verifique si el controlador se reinicia correctamente.
O para probar que su código no contiene un error que deshabilita accidentalmente el perro guardián interno.
Al menos en algunos controladores, el watchdog se llama independiente y tiene su propia fuente de reloj y no puede desactivarse por software, solo un reinicio del controlador desactivará el watchdog. Al menos en teoría, es fácil demostrar que no puede detenerlo con el software, pero es difícil demostrar que el reloj es verdaderamente independiente y no se detendrá bajo EMI.
O para probar que su código no se ejecuta salvajemente, restableciendo el perro guardián externo tan rápido como puede. Problema resuelto. ;-)
Para ese caso, utiliza un watchdog de ventana que debe activarse a ciertos intervalos y, si no lo hace (activarlo con demasiada frecuencia o con menos frecuencia) reiniciará el circuito. El STM32 con el que estoy trabajando tiene una ventana de vigilancia interna, pero se ejecuta desde PCLK1 que se deriva del reloj principal, por lo que no creo que sea tan útil como una vigilancia externa con su propia fuente de reloj.
O que algún genio no coloca la rutina de servicio de vigilancia dentro de un ISR de temporizador, por lo que el código principal puede fallar pero la interrupción sigue disparando y dando servicio perfectamente a la vigilancia ...
Eso ciertamente es cierto, pero espero que una revisión vuelva a poner a ese genio en su silla, pero bueno, cuando comencé, esa fue mi primera idea también: D. Durante los procesos de certificación en los que he participado, siempre observaron la parte de vigilancia del software.