Watchdog Driver (Wdg)

Le pilote watchdog commande le matériel watchdog interne ou externe pour le compte du Watchdog Manager. Ce dernier ne définit qu'une condition de déclenchement limitée dans le temps via le Watchdog Interface. Tant qu'elle s'applique, le pilote déclenche lui-même le matériel ; ensuite, le watchdog expire [SWS_Wdg_00144]. Wdg_Init définit le mode par défaut et le délai d'expiration à partir de la configuration, et Wdg_SetMode commute entre les modes OFF, SLOW et FAST [SWS_Wdg_00160]. Un délai d'expiration de 0 déclenche une réinitialisation quasi immédiate, et la désactivation du watchdog n'est possible que si la configuration l'autorise.

plus ›

Le pilote watchdog Wdg commande le matériel watchdog via quatre services synchrones : Wdg_Init, Wdg_SetMode, Wdg_SetTriggerCondition et Wdg_GetVersionInfo ([SWS_Wdg_00106], [SWS_Wdg_00107], [SWS_Wdg_00155], [SWS_Wdg_00109]). L'EcuM appelle Wdg_Init. Le Watchdog Manager n'atteint le pilote que via le Watchdog Interface, qui sélectionne l'instance par DeviceIndex (SWS WdgIf p. 17). Les instances internes accèdent directement au matériel, les externes via SPI ou DIO ([SWS_Wdg_00161], [SWS_Wdg_00076]). Les deux offrent la même API [SWS_Wdg_00077].

Diagramme de contexte : EcuM initialise les instances Wdg, WdgM les commande via WdgIf. Les instances externes atteignent le matériel via Spi/Dio. Sources : [SWS_Wdg_00076], [SWS_Wdg_00161], SWS WdgM p. 86

Le cœur du module est la condition de déclenchement. Elle vaut autorisation de desservir le watchdog pour les n millisecondes suivantes. Tant qu'elle est valide, le pilote déclenche lui-même ; ensuite, le watchdog expire [SWS_Wdg_00144]. Wdg_SetTriggerCondition réinitialise le compteur et convertit les millisecondes en une valeur de compteur selon le mode ([SWS_Wdg_00136], [SWS_Wdg_00139]). La routine de service interne déclenche et décrémente tant que le compteur est supérieur à zéro. À zéro, elle ne déclenche plus ([SWS_Wdg_00134], [SWS_Wdg_00135]). Un délai d'expiration de 0 force une réinitialisation (quasi) immédiate, et un compteur expiré ne peut pas être rechargé [SWS_Wdg_00140].

Diagramme de séquence : WdgM ne fait que recharger le compteur, le déclenchement est initié par une interruption de temporisateur dans le pilote. Lorsque la valeur du compteur atteint 0, le watchdog expire. Sources : SWS Wdg Fig. 9.2 p. 31, [SWS_Wdg_00134], [SWS_Wdg_00135]

Wdg_Init définit le mode par défaut et la période de délai d'expiration à partir du jeu de configuration Wdg_ConfigType [SWS_Wdg_00001]. Wdg_SetMode commute entre WDGIF_OFF_MODE, WDGIF_SLOW_MODE et WDGIF_FAST_MODE et ne fournit E_OK qu'en cas de changement complet ([SWS_Wdg_00160], [SWS_Wdg_00103]). Il n'existe pas de désinitialisation. La désactivation s'effectue via le mode OFF [SWS_Wdg_00031], et ce uniquement si WdgDisableAllowed l'autorise [SWS_Wdg_00025].

En cas d'erreur, Wdg signale les erreurs de développement WDG_E_DRIVER_STATE, WDG_E_PARAM_MODE, WDG_E_PARAM_CONFIG et WDG_E_PARAM_TIMEOUT [SWS_Wdg_00010]. S'y ajoutent les erreurs de production WDG_E_MODE_FAILED et WDG_E_DISABLE_REJECTED ([SWS_Wdg_00016], [SWS_Wdg_00179]). Ces erreurs de production devraient être signalées via Dem_SetEventStatus [SWS_Wdg_00111]. Question Q-f0ec41b842ebbdc9 (ouverte)

plus ›

Rôle dans la pile Watchdog : le pilote qui prend lui-même en charge le déclenchement

Le pilote de watchdog Wdg commande le matériel watchdog par le biais d'une petite API synchrone comprenant quatre services, tous disponibles via Wdg.h : Wdg_Init (ID de service 0x00), Wdg_SetMode (0x01), Wdg_SetTriggerCondition (0x03) et Wdg_GetVersionInfo (0x04). Seul Wdg_GetVersionInfo est réentrant ([SWS_Wdg_00106], [SWS_Wdg_00107], [SWS_Wdg_00155], [SWS_Wdg_00109]). Il n'existe délibérément aucune interface de désinitialisation. Si le matériel et l'environnement autorisent une désactivation, elle s'effectue via Wdg_SetMode avec le mode OFF [SWS_Wdg_00031].

Les services sont appelés par le logiciel de base. L'ECU State Manager appelle Wdg_Init (SWS EcuM p. 34). Le Watchdog Manager a besoin de WdgIf_SetMode et WdgIf_SetTriggerCondition (SWS WdgM p. 86). Le Watchdog Interface mappe ces appels sur le pilote et sélectionne l'instance via un DeviceIndex basé sur zéro de type uint8. Si un seul pilote est configuré, ce mappage ne doit engendrer aucune surcharge d'exécution, par exemple au moyen de macros (SWS WdgIf p. 17). Le déclenchement temporel incombe entièrement au pilote. Le Watchdog Manager définit uniquement la condition de déclenchement (SWS WdgM p. 56 ; [SWS_Wdg_00144]).

Du côté matériel, les instances diffèrent. Une instance pour un watchdog interne accède directement au matériel [SWS_Wdg_00161]. Une instance pour un watchdog externe utilise l'API d'un gestionnaire ou d'un pilote, tel que SPI ou DIO [SWS_Wdg_00076]. De manière optionnelle, Wdg utilise Det_ReportError pour les erreurs de développement et Dem_SetEventStatus pour les états de surveillance [SWS_Wdg_00111].

Diagramme de contexte : Wdg est initialisé par EcuM et n'est commandé par WdgM qu'indirectement via WdgIf. Les instances internes accèdent directement au matériel, les externes via Spi/Dio. Sources : [SWS_Wdg_00076], [SWS_Wdg_00161], [SWS_Wdg_00111], SWS WdgM p. 86

Du démarrage du système au fonctionnement surveillé

Wdg_Init reçoit un pointeur vers un jeu de configuration de type Wdg_ConfigType. Cette structure dépend du matériel ([SWS_Wdg_00106], [SWS_Wdg_00171]). La fonction initialise le pilote et le matériel, puis définit le mode par défaut et la période de temporisation à partir de ce jeu [SWS_Wdg_00001]. En outre, elle initialise toutes les variables globales [SWS_Wdg_00100]. Elle n'écrit que dans les registres du contrôleur qui n'influencent pas les autres modules matériels et n'en dépendent pas. Un module système transversal initialise les registres partagés [SWS_Wdg_00101]. Lorsque la détection des erreurs de développement est activée, l'état interne passe de WDG_UNINIT à WDG_IDLE après une initialisation réussie [SWS_Wdg_00019].

La figure 9.1 de la spécification montre la répartition des tâches : EcuM initialise directement Wdg, après quoi WdgM commande la condition de déclenchement et le mode via WdgIf (SWS Wdg Fig. 9.1 p. 34). Point important pour les intégrateurs : dès Wdg_Init, le mode par défaut configuré et la période de temporisation initiale s'appliquent [SWS_Wdg_00001]. Si ce mode n'est pas OFF, l'instance de commande doit renouveler la condition de déclenchement dans la fenêtre temporelle, sinon le watchdog expire [SWS_Wdg_00144].

Diagramme de séquence : L'initialisation par EcuM est suivie par la définition de la condition de déclenchement et le basculement de mode par WdgM via WdgIf. Sources : SWS Wdg Fig. 9.1 p. 34, [SWS_Wdg_00001], [SWS_Wdg_00019], [SWS_Wdg_00139], SWS WdgIf p. 18

Condition de déclenchement : autorisation temporaire de rafraîchissement

Le matériel n'est pas rafraîchi par des appels de déclenchement individuels venant de l'extérieur. Au lieu de cela, une condition de déclenchement s'applique : tant qu'elle est valide, le pilote rafraîchit lui-même le matériel. Si elle devient invalide, il interrompt le déclenchement et le watchdog expire [SWS_Wdg_00144]. La spécification décrit la condition comme une « autorisation de rafraîchir le watchdog pour les n prochaines millisecondes ». L'instance de commande doit la renouveler à l'intérieur de cette fenêtre [SWS_Wdg_00144].

Wdg_SetTriggerCondition(uint16 timeout) réinitialise le compteur de temporisation conformément à la valeur transmise ([SWS_Wdg_00155], [SWS_Wdg_00136]). La valeur est interprétée en millisecondes. Le pilote la convertit en interne en une valeur de compteur [SWS_Wdg_00138] en tenant compte du mode actuel [SWS_Wdg_00139]. La valeur 0 est autorisée : elle met fin au déclenchement de manière (presque) immédiate et déclenche ainsi une réinitialisation (presque) immédiate du watchdog. Si le compteur mémorisé est déjà à 0, la fonction ignore toute nouvelle valeur [SWS_Wdg_00140]. Un compteur expiré ne peut donc plus être rechargé.

Le déclenchement effectif est assuré par une routine de rafraîchissement interne au pilote. Si le compteur de déclenchement est supérieur à zéro, elle le décrémente et déclenche le matériel [SWS_Wdg_00134]. S'il a atteint zéro, elle ne fait rien et le watchdog expire [SWS_Wdg_00135]. Si le rafraîchissement est implémenté sous la forme d'une routine d'interruption, les cadres d'interruption font partie de Wdg_Irq.c [SWS_Wdg_00079]. La figure 9.2 montre à cet effet une interruption de timer qui actionne le déclenchement de manière indépendante dans le temps de l'appel via WdgIf (SWS Wdg Fig. 9.2 p. 31).

Diagramme de séquence : WdgM ne fait que recharger le compteur de déclenchement, le déclenchement proprement dit est activé par une interruption de timer dans le pilote. Lorsque la valeur du compteur est à 0, le déclenchement n'a pas lieu et le watchdog expire. Sources : SWS Wdg Fig. 9.2 p. 31, [SWS_Wdg_00134], [SWS_Wdg_00135], [SWS_Wdg_00136], [SWS_Wdg_00093]

Diagramme d'activité : Wdg_SetTriggerCondition rejette les temporisations trop grandes, ignore les nouvelles valeurs si le compteur est déjà expiré et convertit sinon en une valeur de compteur en fonction du mode. Interprétation : La spécification ne fixe pas l'ordre des deux vérifications. Sources : [SWS_Wdg_00146], [SWS_Wdg_00140], [SWS_Wdg_00138], [SWS_Wdg_00139], SWS Wdg p. 29

Modes de fonctionnement OFF, SLOW et FAST

Wdg_SetMode fait passer le pilote et le matériel du mode actuel à WDGIF_OFF_MODE, WDGIF_SLOW_MODE ou WDGIF_FAST_MODE. Chaque mode correspond à un réglage configuré statiquement, tel qu'un watchdog à bascule ou à fenêtre avec des périodes de temporisation différentes [SWS_Wdg_00160]. Les paramètres spécifiques au matériel pour chaque mode figurent dans le jeu de configuration transmis à Wdg_Init [SWS_Wdg_00051]. Wdg importe le type WdgIf_ModeType depuis WdgIf.h [SWS_Wdg_00105]. Un modèle de configuration plus ancien présente à cet égard les conteneurs WdgSettingsFast, WdgSettingsSlow et WdgSettingsOff ainsi que WdgDefaultMode (ECUC-Parameter Fig. 5.21 p. 377).

Wdg_SetMode ne renvoie E_OK que si le basculement est intégralement exécuté et que tous les paramètres du pilote et du matériel ont pris les nouvelles valeurs [SWS_Wdg_00103]. WdgIf transmet cette valeur de retour sans modification (SWS WdgIf p. 18). Le paramètre précompilation WdgDisableAllowed détermine si le watchdog peut être désactivé. S'il est défini sur OFF, une initialisation avec un mode par défaut désactivant le watchdog est rejetée [SWS_Wdg_00025]. D'après sa description, l'erreur WDG_E_DISABLE_REJECTED couvre également un basculement de mode correspondant [SWS_Wdg_00179].

Diagramme d'états : Wdg_Init définit le mode par défaut configuré, après quoi Wdg_SetMode bascule entre les trois modes. Le mode OFF n'est accessible que si WdgDisableAllowed l'autorise. Sources : [SWS_Wdg_00160], [SWS_Wdg_00001], [SWS_Wdg_00025], [SWS_Wdg_00179], [SWS_Wdg_00031]

États internes, zones exclusives et codes d'activation

Lorsque la détection des erreurs de développement est activée, Wdg gère un état interne : WDG_UNINIT jusqu'à l'initialisation réussie, puis WDG_IDLE [SWS_Wdg_00019]. Wdg_SetMode et la routine de rafraîchissement définissent WDG_BUSY pendant leur exécution. En guise de dernière opération avant le retour, ils rétablissent WDG_IDLE ([SWS_Wdg_00018], [SWS_Wdg_00052]). Tous deux vérifient préalablement si l'état est WDG_IDLE. Dans le cas contraire, le basculement de mode ou le déclenchement n'a pas lieu, et WDG_E_DRIVER_STATE est signalé ([SWS_Wdg_00017], [SWS_Wdg_00035]). Les appels antérieurs à l'initialisation sont ainsi détectés, de même que les chevauchements entre basculement de mode et déclenchement.

Si des interruptions doivent être désactivées pour assurer la cohérence des données, par exemple lors du basculement de mode ou dans la routine de déclenchement, cela doit se faire de préférence via une zone exclusive du planificateur BSW. En tant que module MCAL, le pilote interne a également le droit de désactiver directement les interruptions [SWS_Wdg_00040]. Le guide de distribution de la BSW en explique la raison : dans les pilotes MCAL, la fonction principale, l'API de service et l'ISR peuvent accéder à des registres périphériques partagés dans leurs propres contextes d'exécution (BSW Distribution Guide p. 36).

Certains matériels exigent un code d'activation configurable ou variable. Wdg gère alors le code en interne et transmet à chaque fois la valeur correcte. Le matériel met ensuite à jour la variable interne avec le code attendu suivant [SWS_Wdg_00093]. Le cycle de déclenchement doit être choisi de manière à garantir que cette mise à jour puisse avoir lieu [SWS_Wdg_00094]. Un code initial configurable doit figurer dans le jeu de configuration. Si le code est imposé de façon fixe par le matériel, cette exigence devient sans objet [SWS_Wdg_00095].

Diagramme d'états : Lorsque la détection des erreurs de développement est activée, les états WDG_UNINIT, WDG_IDLE et WDG_BUSY s'appliquent. Les appels en dehors de WDG_IDLE sont rejetés avec WDG_E_DRIVER_STATE. Sources : [SWS_Wdg_00019], [SWS_Wdg_00017], [SWS_Wdg_00018], [SWS_Wdg_00035], [SWS_Wdg_00052]

Watchdogs internes et externes : instances, fichiers, configuration

Un calculateur peut comporter plusieurs instances Wdg, par exemple une pour un watchdog interne et une pour un watchdog externe. Les noms d'API et les noms de types spécifiques à l'instance [SWS_Wdg_00172] ainsi que les noms de fichiers de code et d'en-tête sont alors étendus conformément à SRS_BSW_00347 ([SWS_Wdg_00169], [SWS_Wdg_00170]). La figure 1 montre la structure des fichiers avec des espaces réservés tels que Wdg<xxx>.h et Wdg_<xxx>PBcfg.c (SWS Wdg Fig. 1 p. 11). Un Wdg externe doit offrir le même périmètre fonctionnel avec une API sémantiquement identique à celle d'un watchdog interne [SWS_Wdg_00077]. Son code source doit être indépendant de la plateforme de microcontrôleur [SWS_Wdg_00055]. Un exemple issu du domaine de la sécurité est un watchdog à fenêtre externe raccordé par SPI (EXP SafetyUseCase Fig. 4.1 p. 20).

La structure des fichiers de code n'est pas entièrement imposée. En cas de besoin, elle inclut Wdg_Lcfg.c pour les paramètres de l'édition de liens et Wdg_PBcfg.c pour les paramètres post-construction [SWS_Wdg_00079]. Wdg vérifie statiquement la configuration au plus tard au moment de la compilation [SWS_Wdg_00086]. Une configuration statique détermine si le code s'exécute depuis la ROM ou la RAM [SWS_Wdg_00168]. Pour le matériel externe, Wdg intègre les paramètres d'accès, tels que le canal SPI ou le port DIO, dans ses paramètres publiés et ses paramètres de configuration [SWS_Wdg_00078]. Des versions plus récentes modélisent cela sous la forme d'une référence de choix WdgExternalContainerRef vers un groupe de canaux DIO, une séquence SPI ou une séquence I2C. L'I2C n'est pas explicitement mentionné dans R20-11 (SWS Wdg p. 40). Wdg_SetTriggerCondition vérifie par rapport à la valeur maximale WdgMaxTimeout [SWS_Wdg_00146]. Le modèle des informations publiées contient en outre WdgMinTimeout et WdgResolution (ECUC-Parameter Fig. 5.22 p. 380).

Comportement en cas d'erreur

Wdg distingue les erreurs de développement, qui ne sont contrôlées pour l'essentiel que lorsque la détection des erreurs de développement est activée, des erreurs de production étendues. Les codes d'erreur sont définis [SWS_Wdg_00010] :

• WDG_E_DRIVER_STATE (0x10)
• WDG_E_PARAM_MODE (0x11)
• WDG_E_PARAM_CONFIG (0x12)
• WDG_E_PARAM_TIMEOUT (0x13)
• WDG_E_PARAM_POINTER (0x14)
• WDG_E_INIT_FAILED (0x15, sélection invalide du jeu de configuration)

Pour les erreurs de développement, Wdg requiert optionnellement Det_ReportError [SWS_Wdg_00111]. Les cas d'erreur des différents services :

• Initialisation : Si le jeu de configuration se situe hors des limites autorisées, l'initialisation ne s'effectue pas et génère WDG_E_PARAM_CONFIG [SWS_Wdg_00090]. Si le mode par défaut devait désactiver le watchdog alors que WdgDisableAllowed==OFF s'applique, elle ne s'effectue pas et génère WDG_E_DISABLE_REJECTED [SWS_Wdg_00025].
• Basculement de mode : Un état incorrect entraîne WDG_E_DRIVER_STATE [SWS_Wdg_00017]. Un mode hors plage ou des réglages matériels non autorisés entraînent WDG_E_PARAM_MODE ([SWS_Wdg_00091], [SWS_Wdg_00092]). Dans ces trois cas, aucun basculement n'a lieu et la fonction renvoie E_NOT_OK. Si le basculement lui-même échoue, par exemple en raison de réglages incohérents ou de contraintes temporelles non respectées, elle renvoie E_NOT_OK et signale WDG_E_MODE_FAILED [SWS_Wdg_00016].
• Condition de déclenchement : Si la temporisation dépasse WdgMaxTimeout, le compteur n'est pas rechargé et WDG_E_PARAM_TIMEOUT est signalé [SWS_Wdg_00146].
• Interrogation de version : Un pointeur invalide relève de WDG_E_PARAM_POINTER [SWS_Wdg_00010]. La vérification du pointeur nul pour Wdg_GetVersionInfo est décrite dans un passage documentaire issu de versions plus récentes (SWS Wdg p. 30).

Les erreurs de production WDG_E_MODE_FAILED et WDG_E_DISABLE_REJECTED concernent l'initialisation et le basculement de mode. Leur fréquence de surveillance dépend de la couche supérieure ([SWS_Wdg_00178], [SWS_Wdg_00179]). Elles sont signalées avec FAILED lorsque la définition ou la désactivation du mode échoue, et avec PASSED lorsqu'elle réussit ([SWS_Wdg_00180], [SWS_Wdg_00181], [SWS_Wdg_00182], [SWS_Wdg_00183]). Ces signalements devraient transiter par le Dem_SetEventStatus optionnellement requis [SWS_Wdg_00111]. Question (ouverte) Le cas le plus grave n'apparaît délibérément pas comme valeur de retour : en l'absence de condition de déclenchement ou si la valeur 0 est définie, le watchdog expire et le calculateur est réinitialisé ([SWS_Wdg_00135], [SWS_Wdg_00140]).

Diagramme d'activité : Wdg_SetMode vérifie l'état, le mode et les limites matérielles, effectue le basculement et signale le résultat via la valeur de retour et WDG_E_MODE_FAILED. Interprétation : L'ordre des vérifications n'est pas fixé de façon normative. Sources : [SWS_Wdg_00017], [SWS_Wdg_00091], [SWS_Wdg_00092], [SWS_Wdg_00016], [SWS_Wdg_00103], [SWS_Wdg_00018], [SWS_Wdg_00180], [SWS_Wdg_00181]

Preuves détaillées supplémentaires

• [SWS_Wdg_00144] : principe fondamental de la condition de déclenchement et de la répartition des tâches entre l'instance de commande et le pilote.
• [SWS_Wdg_00134], [SWS_Wdg_00135], [SWS_Wdg_00136], [SWS_Wdg_00140] : logique de comptage de la routine de rafraîchissement et cas particulier d'une temporisation de 0.
• [SWS_Wdg_00160], [SWS_Wdg_00103], [SWS_Wdg_00031] : modes, condition de succès et désactivation au lieu d'une désinitialisation.
• [SWS_Wdg_00076], [SWS_Wdg_00077], [SWS_Wdg_00161], [SWS_Wdg_00172] : instances internes et externes et extension de nommage (SWS Wdg p. 24).
• Schémas divergents : La figure 2 du pilote ainsi que les diagrammes de séquence du Watchdog Manager présentent WdgIf_Trigger ou Wdg_Trigger (SWS Wdg Fig. 2 p. 30, SWS WdgM Fig. 13 p. 75, SWS WdgM Fig. 17 p. 78). Cette fonction ne fait pas partie de l'API R20-11. Le mécanisme reposant sur Wdg_SetTriggerCondition y est déterminant ([SWS_Wdg_00155]).
• La figure 9.2 relative au déclenchement temporellement découplé est issue de R21-11 et des versions ultérieures. Son propos concorde avec [SWS_Wdg_00134] et [SWS_Wdg_00093] (SWS Wdg Fig. 9.2 p. 31).