Bonnes pratiques Watchdog ou COP [Forums - Langage C]
Bonnes pratiques Watchdog ou COP [Forums - Langage C]
Pseudo Pass se souvenir de moi     Créer un compte
ARTICLES et TELECHARGEMENTS ~ FORUMS ~ LIENS  
 
             
 
Recherche
 
   
 

Parcourir ce sujet :   1 Utilisateur(s) anonymes



(1) 2 3 »


Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Salut

Je m'interroge sur comment mettre en place efficacement le watchdog.
Je me souviens à mes débuts l'avoir mis à zéro dans des énormes boucles d'attente du change d’état d'une pin, pratique à priori la pire puisque on veut justement se protéger de la sortie impossible d'une telle boucle.

Pour trouver les bonnes pratiques j'ai déjà cherché sur google mais je ne trouve rien ou pas grand chose.
Ensuite je me suis interrogé sur les incidents qui peuvent arriver et que le watchdog doit être en capacité de solutionner.
J'ai pensé à :
-Enfermement dans une boucle à cause d'une condition qui n'arrive pas.
-Saut programme ou donnée incohérente du à un parasite qui produit une action aléatoire du programme.
-Panne matérielle qui entraine un fonctionnement non géré par le programme.

Je ne vois que ces 3 cas et je ne vois pas quelle autre conséquence cela peut avoir à part une entrée dans une boucle infinie ; l’exécution d'un opcode illégal étant géré par un autre mécanisme de sécurité.

1) y a t-il d'autres mécanismes d'erreur où le watchdog a son rôle à jouer ?
2) comment gérer le Watchdog dans une appli classique ? (pour ne pas mettre à zéro le COP là où il doit justement faire son job)
3) même question dans le cas d'un OS tel que FreeRTOS, MQX ou autre. J'ai pensé à créer une tache qui ne ferait que mettre à zéro le watchdog, suivi d'un timedelay de 80% de la période du watchdog. Est ce idiot ? trés bien ? incomplet ?

Merci par avance


-

Posté le : 26/03/2016 10:35
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1164
Hors Ligne
Salut,
Le WDOG est mis à jour sur le cycle de base du CPU.
Généralement que l'on utilise un séquenceur ou un RTOS, le cycle dure entre 1 et 10ms bien qu'il n'y ait pas de règle. Par exemple Windows c'est 10ms de mémoire.
Donc lorsque le cycle démarre ou se termine on recharge le WDOG. Bien sûr sa durée doit être supérieure au cycle de base.
Il est évident qu'on ne recharge pas le WDOG dans une IT sinon si le programme plante mais que l'IT reste appelée, : game over !

Le WDOG est utile dans les cas où il y a altértion du programme : flash ou ram corompue, CE QUI ARRIVE TRES SOUVENT (ESD, rayonnements (téléphone, usines), alim bruyantes avec dv/dt qui créent des latchup dans le CPU, radiations (en particulier dans les milieux radioactifs mais aussi aéronautique)
Ensuite cela peut être utile en cas de bug logiciel, mais attention, si bug il y a le risque de d'avoir un reset intempestif.

Dans tous les cas, pour être utile, le WDOG doit non seulement faire un reset du CPU, mais il doit être associé à une routine qui prévient l'utilisateur ou le concepteur du défaut... Sinon le truc merde mais on ne le sait pas nécessairement.
Donc il faut une routine qui lit le SRS et décode le bit WDOG à l'initialisation du CPU afin d'avertir l'utilisateur : led, msg d'erreur, sms, mail, alarme sonore, signaux de fumée, ...

pour répondre à ta question, selon moi :
Citation :
-Enfermement dans une boucle à cause d'une condition qui n'arrive pas.

oui, mais c'est une erreur de conception. Jamais au grand jamais on ne code avec une boucle qui attend une condition externe sans pouvoir en sortir. La bonne marche à suivre est de tester si la condition est présente pour dérouler une routine, pas d'attendre ! C'est un non sens logiciel
Citation :
-Saut programme ou donnée incohérente du à un parasite qui produit une action aléatoire du programme.

voir ci dessus
Citation :
-Panne matérielle qui entraine un fonctionnement non géré par le programme.
plutôt qu'une panne je parlerai de perturbation environnementale qui perturbe le logiciel comme décrit ci-dessus, ce qui est la cause seconde de défaut des logiciels après le bug du concepteur !


Posté le : 26/03/2016 10:52
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Accro
Inscrit:
28/09/2005 14:02
De Catalunya (66)
Messages: 581
Hors Ligne
Yep !

Le sujet m'intéresse beaucoup, moi qui ai galéré avec ce WDOG dernièrement ...

Je rejoint ce que dit David, et que confirme Stéphane au sujet de l'attente d'un événement externe ;

En effet, je récupère bon nombre de bout de programme officiel dans les doc Freescale ou autre, avec du code comprenant des "while".

Outre le fait qu'il est très simple de l'employer et doit surement avoir l'intérêt d'aider au développement et au débug, car plus simple, je ne comprend pas que l'on puisse l'employer souvent dans un programme.

Par exemple, dans les routines I2C que j'ai récupéré, j'ai des "while I2C_ACK" ou encore "while I2C_IF" et "while I2C_IDLE" et qui ne peuvent rien faire d'autre que d'attendre l'évènement en question, événement qui peut être issu du périphérique externe. Si pour une raison ou une autre l'événement n'arrive pas, c'est le watchdog qui va reseter ...

Alors je suppose qu'il vaudra mieux préférer le trio if/then/else avec une petite tempo afin de tester plusieurs fois si l'évènement est vrai avant de retourner l'erreur ??

Posté le : 26/03/2016 14:25
Les octets s'envolent, les écrits restent !
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Salut

[Mode a bas les boucles ON]
Non dinastar, c'est mal les boucles d'attente, je faisais référence à mes anciennes pratiques ou non seulement je mettait des boucles mais en plus je rechargeais le watchdog dedans...
Soit tu travailles avec des IT, soit par scrutation périodique (scheduler), soit avec un OS où là c'est le panard puisque tu peux attendre mais en laissant la main, l'os va faire d'autres choses et optimise tout seul le temps "perdu".
[Mode a bas les boucles OFF]

Sur les kinetis (et de mémoire c’était pareil sur les S08 que j'utilisais) le watchdog peut avoir des périodes jusqu'à plus d'une seconde.
La question c'est où et comment je le recharge mon watchdog ?
Là je suis sur OS ; si une tache bloque sur une boucle infinie à cause d'un bug, panne matérielle ou mauvaise conception alors la seconde tache que j'évoquais (qui ne ferait que recharger le watchdog) pourrait continuer à faire son job et il n'y aurait jamais détection... mon idée n’était pas bonne du coup.
je ne vois pas du tout où recharger le watchdog!




Posté le : 26/03/2016 14:45
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1164
Hors Ligne
Il est clair qu'il ne faut pas recharger le WDOG sous IT ! Autrement cela ne sert pas à grand chose.

Sous un RTOS, il faut améliorer la stratégie. D'ailleurs la stratégie ci-dessous peut tout à fait être implémenter avec un simple séquenceur de tâche.

Idéalement on veut surveiller que toutes les tâches avancent bien. On pourrait imaginer une tâche qui bloque alors que les autres avancent correctement
Si on fait une tâche périodique de priorité moindre pour recharger le WDOG on risque fort de passer à côté d'une tâche qui merdouille... On va alors implémenter une stratégie un poil plus évoluée, mais qui représente rien en taille de code ou temps d'exécution.

On creé 3 états : RUNNING, ASLEEP et UNKNOWN, à nommer comme vous voulez. Chaque fonction (EDIT : chaque tâche !) possède un registre d'état dans lequel on a ces trois flags.
Pour des raisons de portabilité, je déclarerai les registres dans chaque fonction en global pour être visible de puis la fonction WDOG plutôt que le contraire.

A l'entrée d'une fonction, on met le flag en RUNNING prouvant que la fonction vient d'être lancée correctement.... Si dans cette même fonction on se met à attendre un évènement, alors on passe en ASLEEP juste avant. Dès que l'évènement s'est produit, on repasse en mode RUNNING.

On a initialisé à la création de la tâche un deuxième registre avec une valeur initialisée qui est la tempo, multiple du cycle de base du WDOG pendant lequel on va attendre avant d'enclencher un reset. On peut décider qu'une fonction critique ne doit pas attendre plus de 100ms alors qu'une fonction non critique peut attendre 10s ! Un troisième registre sera le compteur d'attente qui s'incrémentera à chaque fois que la fonction WDOG voit un état ASLEEP.

Maintenant la fonction WDOG qui est une tâche autonome, vient lire ces registres, admettons toutes les 10ms mais on peut mettre la base de temps que l'on veut...

Si elle lit un flag RUNNING, la fonction change l'état pour UNKNOWN et elle recharge le WDOG, tout va bien.
Si elle lit un flag ASLEEP ou UNKNOWN, elle incrémente le compteur d'attente. Cela signifie que soit la fonction n'a pas été appelée depuis un moment ce qui peut être normal, soit elle est en attente d'un évènement. Au bout de quelques cycles, si ce compteur atteint la valeur initialisée c'est que soit la fonction n'a pas été appelée dans le temps imparti par le concepteur, soit elle est toujours en attente et on considère que c'est anormal. Alors on lance le reset du CPU ou autre chose d'ailleurs. L'idée, c'est qu'on fait ce que l'on veut. On peut envoyer un SMS, mettre les actionneurs en position sécurité, et faire une reset par exemple !

Une telle stratégie prend 3 octets de mémoire par fonction que l'on veut superviser (si une fonction n'a aucune attente d'évènement asynchrone ou boucle d'attente, inutile de la superviser car elle ne changera jamais d'état)

voilou. C'est tout simple en fait et ça fournit une sécurité excellente a priori en permettant de superviser chaque tâche indépendamment et de tester en plus que le tâche à bien été exécutée.

On peut affiner les stratégie en dissociant la gestion du ASLEEP et du UNKNOWN pour différencier avec des compteurs différents le temps d'attente du temps d'appel de la fonction. Ou on peut implémenter d'autres stratégies... du moment qu'on a détecté l'état de chaque fonction. On peut dans cette même fonction WDOG (qu'il conviendrait de renommer plutôt Superviseur, de faire la gestion du temps pour compter le temps passé dans une tâche. On gère deux tick, un départ et une arrivée et la fonction périodique vient comptabiliser tout ça. On range le tout dans un tableau et on a un moniteur de ressources qui a compté le temps passé dans chaque fonction. Utile pour superviser la charge du processeur...

Bref on peut faire plein de choses évoluées, très simplement !

++
Steph

Posté le : 26/03/2016 15:27

Edité par Stephane sur 26/03/2016 18:38:59
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
oh .unaise

simple, simple...

mais j'ai beau tourner le truc dans tous les sens je vois pas comment on peut tester la bonne marche/blocage d'une tache sans avoir un indicateur pour chacune d'elle.

La question subsidiaire qui me vient est : des machins renommés comme freertos ne possèdent ils pas nativement d'un tel outil ????

Posté le : 26/03/2016 16:05
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1164
Hors Ligne
Citation :
mais j'ai beau tourner le truc dans tous les sens je vois pas comment on peut tester la bonne marche/blocage d'une tache sans avoir un indicateur pour chacune d'elle.


tu n'as pas bien lu. Chaque tâche à ses propres registres d'état Running, asleep et unknow avec ses compteurs. Donc bien sûr il y a un état pour chaque tâche que tu veux surveiller. Toutes ne sont pas à surveiller : celles qui ne sont pas asynchrones ou qui n'ont pas de boucle for ne nécessitent a priori pas d'être surveillées.

FreeRTOS à ma connaissance ne possède pas une telle fonction. Après dans d'autres OS éventuellement si... Dans windows, c'est le gestionnaire de tâches
Peut-être que dans MQX il y a quelque chose aussi.
Mais honêtement, c'est tellement simple à coder en 10 lignes...



Posté le : 26/03/2016 18:37
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
j'avais bien lu

Ma remarque était juste concernant le fait que effectivement à part avec un tel mécanisme je ne voyais pas comment on pouvait savoir qu'une tache faisait pas son job, perdue quelquepart dans l'espace infini...

Pour celles qui ne nécessitent pas d'être surveillées on fait comment ? Watchdog "par défaut" dans la tache de surveillance ?
Parce que après avec un OS il est peut être bien envisageable de ne pas être asynchrone à 100% ; avec les events par exemple, equivalent du while(trucQuiArrivePas) il y a des timeout.


Posté le : 26/03/2016 19:16
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1164
Hors Ligne
oui
mais certaines tâches ne font aucun test, aucun while, aucun for... donc là tu peux te dispenser de mettre une surveillance.
Par exemple une tâche qui met un flag à jour.... Il n'y a pas de risque que le code n'aille pas à la ligne suivante sauf en cas de corruption mémoire auquel cas de toute façon les tâches suivantes ne s'éxecuteront pas

Posté le : 26/03/2016 21:20
Transférer la contribution vers d'autres applications Transférer


Re: Bonnes pratiques Watchdog ou COP
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
ouais mais en fait c'est même pas envisageable de pas avoir de tests et autres for ou while...

pourquoi je trouve rien là dessus ? 100% des applis sous os devraient avoir ce type de surveillance des taches.

Posté le : 26/03/2016 21:44
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer



 Haut   Précédent   Suivant
(1) 2 3 »



Vous pouvez voir les sujets.
Vous ne pouvez pas débuter de nouveaux sujets.
Vous ne pouvez pas répondre aux contributions.
Vous ne pouvez pas éditer vos contributions.
Vous ne pouvez pas effacez vos contributions.
Vous ne pouvez pas ajouter de nouveaux sondages.
Vous ne pouvez pas voter en sondage.
Vous ne pouvez pas attacher des fichiers à vos contributions.
Vous ne pouvez pas poster sans approbation.

[Recherche avancée]


Powered by XOOPS© The XOOPS Project
Contacter les administrateurs

Bonnes pratiques Watchdog ou COP [Forums - Langage C]