LIN State Manager (LinSM)

Le LIN State Manager convertit les souhaits de communication de ComM par réseau LIN en appels de LIN Interface. Il notifie les états résultants LINSM_FULL_COM et LINSM_NO_COM à ComM et BswM [SWS_LinSM_00126]. Il démarre directement le réveil, la mise en veille et, uniquement pour le maître, le changement de la table d'ordonnancement, et surveille les confirmations à l'aide de temporisateurs dans LinSM_MainFunction. Dans le cas de l'esclave, le maître détermine la mise en veille : seul LinSM_GotoSleepIndication déclenche LinIf_GotoSleep [SWS_LinSM_00231]. Si une transition échoue, le LinSM notifie à nouveau l'état précédent afin que les couches supérieures restent cohérentes.

plus ›

Le LIN State Manager est le gestionnaire d'état de bus pour LIN. C'est par son intermédiaire que ComM demande la capacité de communication d'un réseau (SWS ComM p. 19). Il reçoit les requêtes de mode via LinSM_RequestComMode [SWS_LinSM_00126]. Il contrôle le LinIf et notifie les états à ComM et BswM [SWS_LinSM_00229]. Le pilote LIN qui dessert un réseau reste masqué derrière le LinIf (SWS LinSM p. 28).

Diagramme de contexte : ComM et BswM contrôlent le LinSM, le LinSM contrôle le LinIf, et le LinIf renvoie des notifications via des callbacks. Sources : [SWS_LinSM_00229], [SWS_LinSM_00138], SWS LinSM p. 28

Après LinSM_Init, chaque réseau est en LINSM_NO_COM [SWS_LinSM_00155]. ComM et BswM ne sont pas notifiés à cette occasion (SWS LinSM p. 23). La communication n'est autorisée qu'en LINSM_FULL_COM. Lors de l'entrée, ComM et BswM reçoivent une notification, et le sous-état LINSM_RUN_COMMUNICATION est activé [SWS_LinSM_00301]. Seuls LINSM_FULL_COM et LINSM_NO_COM sont visibles pour le BswM [SWS_LinSM_00220].

Diagramme d'état : Pour chaque réseau, le LinSM bascule entre LINSM_NO_COM et LINSM_FULL_COM par confirmation de réveil et de veille. Sources : [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20

Le LinSM lance le réveil et la mise en veille directement au cours de l'appel. Il surveille les confirmations du LinIf à l'aide de temporisateurs dans LinSM_MainFunction [SWS_LinSM_00156] (SWS LinSM p. 28). Pour le maître, une demande de COMM_NO_COMMUNICATION conduit immédiatement à LinIf_GotoSleep [SWS_LinSM_00036]. Pour l'esclave, elle est seulement enregistrée [SWS_LinSM_00230] ; seul LinSM_GotoSleepIndication déclenche la mise en veille [SWS_LinSM_00231]. Un temporisateur Silence-after-Wakeup retarde les nouvelles tentatives de réveil [SWS_LinSM_00237].

Les changements de table d'ordonnancement n'existent que pour le maître [SWS_LinSM_00241]. Le LinSM transmet LinSM_ScheduleRequest directement au LinIf et notifie le résultat via BswM_LinSM_CurrentSchedule (SWS LinSM p. 26). Pour les erreurs, les règles suivantes s'appliquent :

• Le LinSM signale les erreurs de développement au DET, avec les codes issus de [SWS_LinSM_00053].
• L'absence de callback du LinIf est considérée comme LINSM_E_CONFIRMATION_TIMEOUT [SWS_LinSM_00224].
• Après une transition infructueuse, le LinSM rétablit l'état précédent afin que ComM et BswM restent informés de manière cohérente [SWS_LinSM_00177].

plus ›

Rôle entre ComM, BswM et LIN Interface

Le LIN State Manager (LinSM) est le gestionnaire d'état de bus pour LIN. Comme pour les autres gestionnaires d'état de bus, ComM demande par son intermédiaire la capacité de communication d'un réseau (SWS ComM p. 19). L'interface d'entrée centrale pour cela est LinSM_RequestComMode [SWS_LinSM_00126]. Le mode actuel est fourni par LinSM_GetCurrentComMode [SWS_LinSM_00122]. Le LinSM fonctionne exclusivement sur des réseaux. Le pilote LIN qui dessert un réseau est masqué par le LinIf. Par conséquent, les calculateurs (ECU) comportant plusieurs pilotes LIN distincts ne concernent pas le LinSM (SWS LinSM p. 28).

Parmi les interfaces obligatoires figurent LinIf_GotoSleep et LinIf_ScheduleRequest vers le bas ainsi que les notifications ComM_BusSM_ModeIndication, ComM_BusSM_BusSleepMode, BswM_LinSM_CurrentState et BswM_LinSM_CurrentSchedule vers le haut [SWS_LinSM_00229] (SWS LinSM p. 41). LinIf_Wakeup est appelée par le LinSM dans le déroulement du réveil (SWS LinSM p. 27). De manière optionnelle, il utilise Det_ReportError et LinIf_SetTrcvMode [SWS_LinSM_00138]. Le LinIf renvoie des informations via les callbacks suivants :

• LinSM_WakeupConfirmation [SWS_LinSM_00132]
• LinSM_GotoSleepConfirmation [SWS_LinSM_00135]
• LinSM_GotoSleepIndication [SWS_LinSM_91000]
• LinSM_ScheduleRequestConfirmation [SWS_LinSM_00129]

Les types importés tels que ComM_ModeType, NetworkHandleType et LinIf_SchHandleType sont définis par [SWS_LinSM_00219].

Diagramme de contexte : Le LinSM assure l'intermédiaire entre ComM et BswM au niveau supérieur et le LinIf au niveau inférieur ; les pilotes LIN restent masqués derrière le LinIf. Sources : [SWS_LinSM_00126], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00156], SWS LinSM p. 28, Mode-Management-Guide p. 54

Modèle d'état par réseau LIN, initialisation et composante cyclique

Au démarrage, l'état à l'échelle du module LINSM_UNINIT est actif avant tout appel d'API (SWS LinSM p. 22). LinSM_Init est synchrone et non réentrant [SWS_LinSM_00155]. La fonction reçoit un pointeur vers la configuration post-build de type LinSM_ConfigType, spécifique à l'implémentation [SWS_LinSM_00221]. Ensuite, chaque réseau se trouve dans le sous-état LINSM_NO_COM du super-état LINSM_INIT. LinSM_Init ne notifie cette première transition ni à ComM ni à BswM, car ComM n'a pas encore besoin d'être initialisé à ce moment-là (SWS LinSM p. 23). Dans l'exemple du guide de gestion des modes, une règle BswM appelle LinSM_Init(null) après Lin_Init et LinIf_Init (Mode-Management-Guide p. 54).

En LINSM_NO_COM, le bus reste silencieux (SWS LinSM p. 23). La communication sur le bus n'est autorisée qu'en LINSM_FULL_COM, et chaque réseau atteint cet état indépendamment des autres. Lors de l'entrée dans cet état, les actions suivantes sont exécutées (SWS LinSM p. 23) :

• ComM reçoit une notification avec COMM_FULL_COMMUNICATION, et BswM une notification avec LINSM_FULL_COM.
• Si LinSMTransceiverPassiveMode est configuré, le LinSM active le transceiver via LinIf_SetTrcvMode.
• Le sous-état LINSM_RUN_COMMUNICATION est activé [SWS_LinSM_00301].

Le sous-état transitoire LINSM_GOTO_SLEEP sert de transition pendant l'attente de la confirmation de mise en veille (SWS LinSM p. 20, SWS LinSM p. 21). Pour le BswM, seules deux valeurs de LinSM_ModeType sont visibles : LINSM_FULL_COM (0x01) et LINSM_NO_COM (0x02) [SWS_LinSM_00220].

La surveillance temporelle s'exécute dans LinSM_MainFunction. Cette fonction périodique gère les temporisateurs des timeouts de requête [SWS_LinSM_00156]. C'est également là qu'expirent les temporisateurs de confirmation de réveil, avec un temporisateur propre à chaque réseau (SWS LinSM p. 28). En revanche, le LinSM démarre les actions de bus proprement dites directement lors de l'appel et n'attend pas le cycle suivant de la fonction principale [SWS_LinSM_00036] [SWS_LinSM_00231].

Diagramme d'états : pour chaque réseau, le LinSM bascule entre LINSM_NO_COM et LINSM_FULL_COM par confirmation de réveil et de mise en veille ; LINSM_GOTO_SLEEP n'est qu'un état d'attente. Sources : [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM p. 20, SWS LinSM p. 21, SWS LinSM p. 24

Réveil : de LINSM_NO_COM vers LINSM_FULL_COM

Un réseau LIN est réveillé lorsque ComM demande une communication complète via LinSM_RequestComMode. Si un autre nœud réveille le bus, ce n'est pas le LinSM qui le gère, mais l'EcuM ; ce cas entraîne également une demande de la part de ComM (SWS LinSM p. 27). Le LinSM appelle alors directement LinIf_Wakeup et réinitialise le compteur du nombre maximal de répétitions. Si la LinIf est déjà réveillée, elle ignore l'appel. Avant l'appel, le LinSM démarre le temporisateur de confirmation de réveil pour le canal avec LinSMConfirmationTimeout. Cette valeur doit être 0 ou un multiple entier de la période de la fonction principale (SWS LinSM p. 28).

Si LinSM_WakeupConfirmation signale success = TRUE, le réseau passe à LINSM_FULL_COM [SWS_LinSM_00132]. Dans tous les autres cas, le LinSM rétablit l'état précédant la requête, afin que ComM et BswM reçoivent tout de même une indication de mode (SWS LinSM p. 27). Pour le slave, la LinIf ne confirme qu'après avoir reçu le premier en-tête LIN du master. Si le master ne démarre pas l'ordonnancement, la confirmation n'a pas lieu et le timeout du LinSM se déclenche (SWS LinIf p. 52).

Diagramme de séquence : le LinSM réveille le réseau immédiatement lors de l'appel, mais le changement d'état ne suit qu'avec la confirmation asynchrone de la LinIf. Sources : [SWS_LinSM_00126], [SWS_LinSM_00132], [SWS_LinSM_00224], SWS LinSM p. 42, SWS LinSM p. 27

Une seconde limite temporelle est le temporisateur de silence après réveil (Silence-after-Wakeup) avec LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Tant qu'il est actif, le LinSM retarde un nouvel appel de LinIf_Wakeup, même si ComM demande une communication complète [SWS_LinSM_00237]. Après son expiration, le LinSM redémarre le processus de réveil, pour autant que ComM continue de demander COMM_FULL_COMMUNICATION [SWS_LinSM_00236]. La condition qui démarre le temporisateur figure dans une exigence qui n'est pas présente ici. Elle n'est donc pas décrite.

Diagramme d'activité : une requête de communication complète aboutit, selon l'état des temporisateurs et le retour d'information, à LINSM_FULL_COM, à l'ancien état ou à un timeout de confirmation. Sources : [SWS_LinSM_00237], [SWS_LinSM_00236], [SWS_LinSM_00224], SWS LinSM p. 27, SWS LinSM p. 28

Mise en veille : le master effectue la requête, le slave suit le bus

Le déroulement du passage en veille (Goto-Sleep) diffère entre master et slave. Dans les deux cas, le LinSM signale l'entrée dans le mode No-Communication à BswM et ComM, même si un problème est survenu (SWS LinSM p. 24).

Pour le master :

• Si ComM demande COMM_NO_COMMUNICATION dans l'état LINSM_FULL_COM, le LinSM appelle LinIf_GotoSleep, qui envoie la commande Goto-Sleep [SWS_LinSM_10208].
• L'appel s'effectue directement [SWS_LinSM_00036]. Dans tous les autres cas, il n'a pas lieu [SWS_LinSM_10209].
• L'appel n'est autorisé que dans le sous-état LINSM_RUN_COMMUNICATION (SWS LinSM p. 24).
• Si LinIf_GotoSleep retourne E_NOT_OK, LinSM_RequestComMode renvoie également E_NOT_OK. L'état antérieur est rétabli afin que ComM et BswM reçoivent une indication [SWS_LinSM_00177].

Ensuite, la LinIf appelle LinSM_GotoSleepConfirmation [SWS_LinSM_00135]. Si le LinSM se trouve alors dans LINSM_FULL_COM/LINSM_GOTO_SLEEP, il passe à LINSM_NO_COM, indépendamment du paramètre success. Dans tout autre état, il ignore la confirmation (SWS LinSM p. 24). Le schéma de la spécification démarre un temporisateur avant LinIf_GotoSleep et l'arrête après la confirmation (SWS LinSM p. 47).

Diagramme de séquence : sur le master, ComM déclenche la mise en veille ; LINSM_NO_COM n'est atteint qu'avec la confirmation de mise en veille, un retour E_NOT_OK de LinIf_GotoSleep entraîne la notification renouvelée de l'ancien état. Sources : [SWS_LinSM_00036], [SWS_LinSM_00177], [SWS_LinSM_00135], SWS LinSM p. 47, SWS LinSM p. 24

Sur le slave, le master décide de la mise en veille. Si ComM demande COMM_NO_COMMUNICATION dans l'état LINSM_FULL_COM, le LinSM mémorise uniquement la demande et renvoie E_OK [SWS_LinSM_00230]. La LinIf signale LinSM_GotoSleepIndication lorsqu'une commande Goto-Sleep a été reçue ou qu'un timeout d'inactivité du bus (Bus-Idle) est survenu [SWS_LinSM_91000]. Ce n'est qu'alors que le LinSM appelle directement LinIf_GotoSleep [SWS_LinSM_00231]. La suite du déroulement dépend de la demande mémorisée :

• Si COMM_NO_COMMUNICATION est demandée et que LinIf_GotoSleep renvoie E_OK, ComM est informé de l'événement Bus-Sleep via ComM_BusSM_BusSleepMode [SWS_LinSM_00233].
• Si une communication complète est demandée, le LinSM redémarre le processus de réveil après la confirmation de mise en veille [SWS_LinSM_00234].

Dans la LinIf, la séquence slave place le contrôleur et, s'il est pris en charge, le transceiver en mode veille (SWS LinIf p. 137).

Diagramme de séquence : sur le slave, la demande de mise en veille de ComM est seulement mémorisée, la mise en veille étant déclenchée par l'indication de la LinIf. Sources : [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234], SWS LinSM p. 48, SWS LinSM p. 24

Changement de tables d'ordonnancement (master uniquement)

LinSM_ScheduleRequest [SWS_LinSM_00113] n'existe que si au moins un canal est configuré en tant que master [SWS_LinSM_00241]. Il en va de même pour le callback LinSM_ScheduleRequestConfirmation [SWS_LinSM_00242]. La fonction asynchrone transmet directement la requête à LinIf_ScheduleRequest, sans passer par la fonction principale. Elle renvoie la valeur de retour de celle-ci à l'appelant (SWS LinSM p. 26). L'appelant est le BswM. Il utilise LinSMScheduleIndex comme référence symbolique dont la valeur doit correspondre à la valeur dans la LinIf (SWS LinSM p. 52). Les changements d'ordonnancement de diagnostic du protocole de transport LIN passent également par le BswM et LinSM_ScheduleRequest (SWS LinIf p. 142).

Le LinSM signale le résultat via BswM_LinSM_CurrentSchedule (SWS BswM p. 80). La table d'ordonnancement signalée dépend du déroulement (SWS LinSM p. 26) :

• Si LinSM_ScheduleRequestConfirmation [SWS_LinSM_00129] confirme avant l'expiration du temporisateur, le LinSM signale la nouvelle table d'ordonnancement.
• Si le temporisateur a expiré, il signale la table d'ordonnancement inchangée.
• Si LinIf_ScheduleRequest renvoie E_NOT_OK, il signale l'ancienne table d'ordonnancement lors de l'appel suivant de la fonction principale.
• Il signale également un changement survenu sans requête préalable, tel que le passage à la table d'ordonnancement NULL effectué par la LinIf lors de la mise en veille.

Diagramme de séquence : le changement de table d'ordonnancement est directement transmis et surveillé temporellement ; le BswM reçoit dans chaque cas d'issue la table d'ordonnancement effectivement valide. Sources : [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00156], SWS LinSM p. 26, SWS LinSM p. 48

Type de nœud, configuration et différences avec les versions ultérieures

Le paramètre LinSMNodeType définit si un comportement master ou slave s'applique à un canal. C'est de cela que dépend la disponibilité de LinSM_ScheduleRequest, LinSM_ScheduleRequestConfirmation et LinSM_GotoSleepIndication [SWS_LinSM_00241] [SWS_LinSM_00242] [SWS_LinSM_00243]. Les paramètres temporels les plus importants sont LinSMConfirmationTimeout (SWS LinSM p. 28) et LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Les conteneurs LinSMSchedule référencent des tables d'ordonnancement issues de la configuration de la LinIf (SWS LinSM p. 52). Les vérifications DET dépendent de LinSMDevErrorDetect [SWS_LinSM_00239].

De nombreux passages du document sont issus de versions ultérieures. Pour R20-11, les exigences font foi, et elles divergent sur certains points :

• Le second paramètre de LinSM_ScheduleRequest s'appelle schedule dans R20-11 et est décrit comme « Pointer to the new Schedule table », bien que son type soit LinIf_SchHandleType [SWS_LinSM_00113]. Avec R22-11, il a été renommé (SWS LinSM p. 1, Release Overview p. 50) ; dans R24-11, il s'intitule ScheduleTableIdx (SWS LinSM p. 34).
• Dans R20-11, LinSM_GetCurrentComMode possède l'ID de service 0x11 [SWS_LinSM_00122] et LinSM_RequestComMode possède l'ID de service 0x12 [SWS_LinSM_00126]. Les versions ultérieures indiquent 0x41 et 0x40 et n'autorisent la réentrance que pour des réseaux distincts (SWS LinSM p. 35, SWS LinSM p. 36).
• Les callbacks ComM s'appellent ComM_BusSM_… [SWS_LinSM_00233] dans R20-11, et ComM_<Bus>SM_… dans R25-11 (SWS LinSM p. 41).

Comportement en cas d'erreur

[SWS_LinSM_00053] définit les erreurs de développement :

• LINSM_E_UNINIT (0x00)
• LINSM_E_NONEXISTENT_NETWORK (0x20)
• LINSM_E_PARAMETER (0x30)
• LINSM_E_PARAM_POINTER (0x40)
• LINSM_E_INIT_FAILED (0x50)

Lorsque LinSMDevErrorDetect est actif, les callbacks vérifient le réseau et l'initialisation, comme par exemple LinSM_GotoSleepIndication [SWS_LinSM_00239] [SWS_LinSM_00240]. Les callbacks n'ayant pas de valeur de retour, cela se limite pour eux au signalement DET (SWS LinSM p. 40, SWS LinSM p. 39). Les API avec Std_ReturnType renvoient en outre E_NOT_OK, par exemple en cas de réseau, de mode ou d'ordonnancement non valide, ou dans l'état LINSM_UNINIT (SWS LinSM p. 36, SWS LinSM p. 34). Interprétation : ces vérifications proviennent de versions à partir de R24-11 et devraient s'appliquer de manière identique quant au fond pour R20-11. Il est remarquable que la version ultérieure exige également E_NOT_OK en cas de pointeur NULL pour l'API void LinSM_GetVersionInfo [SWS_LinSM_00117] (SWS LinSM p. 34). Question Q-6b2d75dd286bdcb4 (ouverte)

Comme erreur d'exécution, LINSM_E_CONFIRMATION_TIMEOUT (0x00) est prévue pour les callbacks manquants de la LinIf [SWS_LinSM_00224]. Elle est vraisemblablement signalée via Det_ReportRuntimeError, que des versions ultérieures listent comme interface obligatoire (SWS LinSM p. 41). Question Q-06b13a07d0d60152 (ouverte) Sur le plan fonctionnel, le LinSM veille à ce que ComM et BswM voient toujours un état cohérent :

• Après un réveil échoué, il rétablit et signale à nouveau l'ancien état (SWS LinSM p. 27).
• En cas de retour E_NOT_OK de LinIf_GotoSleep, la même règle s'applique [SWS_LinSM_00177].
• Une confirmation de mise en veille conduit à LINSM_NO_COM même si success = FALSE (SWS LinSM p. 24).
• En cas d'échec d'un changement de table d'ordonnancement, le BswM reçoit l'ancienne table d'ordonnancement ou la table inchangée (SWS LinSM p. 26).

Preuves détaillées supplémentaires

• Demande de mode de ComM et mise en veille pour le master : [SWS_LinSM_00126], [SWS_LinSM_00036], [SWS_LinSM_10208], [SWS_LinSM_10209], [SWS_LinSM_00177].
• Mise en veille pour le slave : [SWS_LinSM_91000], [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234] ; ainsi que le déroulement dans SWS LinSM p. 24.
• Réveil et surveillance temporelle : [SWS_LinSM_00132], [SWS_LinSM_00235], [SWS_LinSM_00236], [SWS_LinSM_00237], SWS LinSM p. 28.
• Changement de table d'ordonnancement : [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00241], [SWS_LinSM_00242].
• Initialisation, états et types : [SWS_LinSM_00155], [SWS_LinSM_00156], [SWS_LinSM_00220], [SWS_LinSM_00221], [SWS_LinSM_00301] ; notification au BswM dans SWS BswM p. 72.
• Codes d'erreur et interfaces : [SWS_LinSM_00053], [SWS_LinSM_00224], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00219].
• Traçabilité vers les exigences SRS et liste des exigences non applicables : SWS LinSM p. 18, SWS LinSM p. 55.