FR3046861A1 - Procede de synchronisation, dispositif et vehicule associes - Google Patents

Abstract

La présente invention concerne un procédé de synchronisation d'une unité maître (12) et d'une unité esclave (14), chacune adaptée pour exécuter une application qui est exécutée selon des cycles et qui prend en entrée des paramètres d'entrée et une donnée de contexte et qui retourne en sortie un résultat et une donnée de contexte. Le procédé consiste à exécuter simultanément l'application par les unités maître et esclave, et à chaque cycle, l'application est exécutée simultanément par les unités maître et esclave (12, 14), l'unité maître (12) transmettant à l'unité esclave (14) la donnée de contexte retournée par l'unité maître (12) lors du cycle précédent, la donnée de contexte retournée par l'unité esclave (14) n'étant pas transmise à l'unité maître (12), l'unité maître (12) et l'unité esclave (14) utilisant pour l'exécution du cycle courant la donnée de contexte retournée par l'unité maître (12).

Description

Procédé de synchronisation, dispositif et véhicule associés

La présente invention concerne un procédé de synchronisation d’une unité maître et d’au moins une unité esclave, chacune des unités maître et esclave étant adaptée pour exécuter une application stockée dans des mémoires respectives des unités maître et esclave, l’application étant exécutée selon des cycles et prenant en entrée des paramètres d’entrée et une donnée de contexte et retournant en sortie un résultat et une donnée de contexte, le procédé étant mis en en œuvre par un dispositif de traitement et consistant à exécuter simultanément l’application par les unités maître et esclave.

On connaît dans l’état de la technique des unités de traitement mettant en œuvre une redondance. La redondance consiste à disposer de plusieurs exemplaires d’une même unité afin d’éviter qu’une défaillance d’une seule de ces unités ne mène à la perte, par exemple, d’une fonction de sécurité. Le principe de la redondance réside ainsi dans le fait qu’une application n’est pas mise en œuvre par une seule unité mais par au moins deux unités simultanément. On distingue, en outre, la redondance froide, selon laquelle les unités sont activées quand celles déjà actives deviennent défaillantes, et la redondance chaude, selon laquelle toutes les unités fonctionnent en parallèle l’une de l’autre. En particulier, dans le cas d’une redondance chaude, les opérations effectuées par certaines unités, dites actives, sont exploitées par un équipement tiers, tel qu’un équipement à commander, tandis que celles effectués par les autres unités, dites passives, ne sont pas exploitées.

Toutefois, dans le cas d’une redondance chaude, il faut tenir compte du fait que les différentes unités sont parfois désynchronisées. Un cas de désynchronisation résulte, par exemple, du fait que, lorsqu’un cycle utilise pour sa mise en œuvre des données de contexte générées lors de la mise en œuvre d’un précédent cycle, les données de contexte calculées par les différentes unités ne sont pas identiques. De fait, la continuité contextuelle n’est pas assurée, ce se traduit par une discontinuité du contexte lorsqu’une unité passive devient active. Une telle discontinuité contextuelle est source de problème pour l’équipement tiers.

On a ainsi déjà proposé dans l’état de la technique des procédés de synchronisation destinés à pallier cette difficulté. Un tel procédé consiste à comparer, à des instants donnés, les données de contexte respectives des unités. Les données de contexte retournées par chacune des unités à la fin de la mise en œuvre d’un cycle donné sont alors comparées. Lorsque les données de contexte ne sont pas les mêmes, le procédé consiste à forcer l’état des unités de sorte à les resynchroniser.

Toutefois, un tel procédé présente notamment l’inconvénient d’être trop intrusif dans la programmation de chacune des unités. En effet, à chaque vérification de la synchronisation, la comparaison des états respectifs de chacune des unités nécessite l’exécution d’instructions logicielles.

Le but de l’invention est de proposer une solution pour la gestion de la synchronisation d’unités dans le cas d’une redondance chaude, nécessitant peu de capacités mémoire et de moyens de calcul. A cet effet, l’invention a pour objet un procédé de synchronisation, du type précité, dans lequel à chaque cycle de l’application, dit cycle courant, l’unité maître transmet à l’unité esclave la donnée de contexte retournée par l’unité maître lors de l’exécution du cycle précédent, la donnée de contexte retournée par l’unité esclave n’étant pas transmise à l’unité maître et n’étant pas exploitée par l’unité esclave, l’unité maître et l’unité esclave utilisant pour l’exécution du cycle courant respectivement la donnée de contexte retournée par l’unité maître et la donnée de contexte retournée et transmise par l’unité maître.

Suivant des modes particuliers de réalisation, le procédé selon l’invention comprend l’une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toute combinaison techniquement possible : - chacune des unités maître et esclave définit un état d’utilisation, l’état d’utilisation prenant la valeur actif lorsque les résultats retournés par ladite unité sont émis à destination d’un équipement tiers à contrôler et/ou à commander ou la valeur passif lorsque les résultats retournés par ladite unité ne sont pas émis à destination d’un équipement tiers à contrôler et/ou à commander, le procédé comprenant une étape de pilotage de l’état d’utilisation des unités maître et esclave, le contrôle consistant à : + transmettre de manière périodique un message depuis l’unité maître vers l’unité esclave, + tant que le message est reçu par l’unité esclave, maintenir l’état d’utilisation de l’unité esclave à la valeur passif, et + lorsque le message n’est plus reçu par l’unité esclave, modification de l’état d’utilisation de l’unité esclave de la valeur passif à la valeur actif ; - dès que le message n’est plus reçu par l’unité esclave, l’unité esclave utilise, à chaque cycle de l’application, la donnée de contexte retournée par l’unité esclave lors du cycle précédent, et - les données de contexte comportent au moins un élément parmi le groupe consistant en : + un état d’un graphique fonctionnel de commande des étapes et transitions, + des calculs intermédiaires, et + toute donnée persistante d’un cycle au cycle suivant. L’invention a également pour objet un dispositif de traitement, le dispositif comprenant une unité maître et au moins une unité esclave, les unités maître et esclave comprenant respectivement : - un module applicatif maître et esclave adapté pour exécuter une application stockée dans des mémoires respectives des unités maître et esclave, l’application étant exécutée selon des cycles et prenant en entrée des paramètres d’entrée et une donnée de contexte et retournant en sortie un résultat et une donnée de contexte, - un module de synchronisation maître et esclave adapté pour piloter, à chaque cycle de l’application, l’exécution de l’application à la fois par l’unité maître et par l’unité esclave, et dans lequel les modules de synchronisation maître et esclave sont adaptés pour, à chaque cycle de l’application, dit cycle courant, piloter l’exécution simultanée par les modules applicatifs de l’application et adaptés pour piloter la transmission depuis l’unité maître vers l’unité esclave de la donnée de contexte retournée par le module applicatif maître lors de l’exécution du cycle précédent, la donnée de contexte retournée par le module applicatif esclave n’étant pas transmise à l’unité maître et n’étant pas exploitée par l’unité esclave, les modules applicatifs maître et esclave recevant en entrée pour l’exécution du cycle courant respectivement la donnée de contexte retournée par le module applicatif maître et la donnée de contexte retournée et transmise par le module applicatif maître.

Suivant des modes particuliers de réalisation, le dispositif de traitement selon l’invention comprend l’une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toute combinaison techniquement possible : - chacune des unités maître et esclave définit un état d’utilisation, l’état d’utilisation prenant la valeur actif lorsque les résultats retournés par ladite unité sont émis à destination d’un équipement tiers à contrôler et/ou à commander ou la valeur passif lorsque les résultats retournés par ladite unité ne sont pas émis à destination d’un équipement tiers à contrôler et/ou à commander, les unités maître et esclave comprenant respectivement un module de contrôle maître et esclave, le module de contrôle maître étant adapté pour transmettre périodiquement un message au module de contrôle esclave, et le module de contrôle esclave étant adapté pour maintenir l’état d’utilisation de l’unité esclave à la valeur passif tant que le message est reçu, et pour, lorsque le message n’est plus reçu, modifier l’état d’utilisation de l’unité esclave de la valeur passif à la valeur actif, et - dès que le message n’est plus reçu par l’unité esclave, le module applicatif esclave est adapté pour, à chaque cycle de l’application, recevoir la donnée de contexte retournée par l’unité esclave lors du cycle précédent. L’invention a également pour objet un véhicule transport ferroviaire comprenant : - au moins un équipement tiers à contrôler et/ou à commander, et - au moins un module de contrôle et/ou de commande adapté pour contrôler et/ou commander l’équipement tiers à contrôler et/ou à commander, le module de contrôle et/ou de commande comprenant un dispositif de traitement tel que défini précédemment. L’invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple, et faite en se référant aux dessins annexés, sur lesquels : - la figure 1 est une représentation schématique du dispositif de traitement selon l’invention ; - la figure 2 est un schéma fonctionnel illustrant la mise en œuvre du procédé selon l’invention dans un mode de fonctionnement normal, et - la figure 3 est un schéma fonctionnel illustrant la mise en œuvre du procédé selon l’invention dans un mode de fonctionnement dégradé.

La figure 1 illustre un dispositif de traitement 10 selon l’invention destiné à être installé, par exemple, dans un véhicule de transport tel qu’un véhicule ferroviaire.

Le dispositif de traitement 10 est adapté pour émettre des données à destination d’un équipement tiers à contrôler et/ou à commander, tel qu’un module de gestion du freinage d’un véhicule de transport. Il respecte des normes de sécurité et est adapté pour mettre en œuvre une redondance de type chaude.

Le dispositif de traitement 10 comprend une unité maître 12 et une unité esclave 14. Les unités maître et esclave 12, 14 présentent des architectures analogues, et, par conséquent, l’unité maître 12 sera décrite par la suite et seules les différences avec l’unité esclave 14 seront décrites. Les références qui désignent des éléments analogues des unités maître et esclave 12, 14 sont suivies de la lettre A lorsqu’ils concernent l’unité maître 12 et de la lettre B lorsqu’ils concernent l’unité esclave 14.

Comme visible sur la figure 1, l’unité maître 12 est adaptée pour recevoir en entrée 16A un ensemble d’informations et pour délivrer en sortie 18A d’autres informations à destination d’un équipement tiers. L’unité maître 12 est adaptée pour exécuter une application A logicielle en définissant des cycles notés Cycle!, Cycle2, Cycle3, ..., Cycle,.!, Cycle,. De façon analogue, l’unité esclave 14 est adapté pour exécuter la même application A en définissant des cycles notés Cycle’i, Cycle’2, Cycle’3,..., Cycle’,-!, Cycle’,.

Pour des raisons de clarté, l’application est notée A dans le cas de l’unité maître et esclave 12, 14, mais son exécution diffère selon les unités, en raison des données de contexte et des entrées qui ne sont pas nécessairement les mêmes. A titre d’illustration, l’application A délivre des informations de contrôle d’un module de gestion du freinage.

En outre, dans le cas des cycles Cyclei, Cycle2, etc... mis en œuvre par l’unité maître 12, l’application A prend en entrée des paramètres d’entrée ei, e2, etc... et une donnée de contexte et retournant en sortie un résultat su s2, etc... et une donnée de contexte Ci, c2, etc... De façon analogue, dans le cas des cycles Cycle’!, Cycle’2, etc... mis en œuvre par l’unité esclave 14, l’application A prend en entrée des paramètres d’entrée e’i, e’2, etc... et une donnée de contexte et retournant en sortie un résultat s’!, s’2, etc... et une donnée de contexte c’!, c’2, etc... Pour les premiers cycles Cycles Cycle’!, la donnée de contexte est une valeur d’initialisation par défaut.

Les paramètres d’entrée ei, e’i, e2, e’2, etc... sont, par exemple, des données retournées par un équipement tiers et les résultats Si, s’i, s2, s’2, etc... sont, par exemple, des données à émettre à destination d’un équipement tiers.

Les données de contexte sont des données générées par l’application A durant un cycle et nécessaires à l’exécution de l’application A durant un cycle suivant. De fait, les données de contexte sont conservées entre la fin d’un cycle et le début du cycle suivant. Une donnée de contexte est, par exemple, un état d’un graphique fonctionnel de commande des étapes et transitions, un calcul intermédiaire à conserver pour la bonne exécution des cycles suivants. L’unité maître 12 comprend une mémoire maître 20A et un processeur maître 22A associé à la mémoire maître 20A et adapté pour exécuter des instructions logicielles stockées dans la mémoire maître 20A.

La mémoire maître 20A comprend un module applicatif maître 24A réalisé, par exemple, sous forme d’une application logicielle stockée dans la mémoire maître 20A et apte à être exécutée par le processeur maître 22A. Le module applicatif maître 24A est adapté pour mettre en œuvre l’application A.

La mémoire maître 20A comprend également un module de synchronisation maître 26A adapté pour assurer la continuité contextuelle entre les unités maître et esclave 12, 14.

Le module de synchronisation maître 26A est adapté pour transmettre au module de synchronisation esclave 26B des informations, et en particulier des données de contexte retournées lors de l’exécution de l’application A. En outre, les modules de synchronisation maître et esclave 26A, 26B sont adaptés pour déterminer la donnée de contexte à prendre en entrée pour l’exécution de l’application A.

La mémoire maître 20A comprend également un module de contrôle maître 28A adapté pour gérer un état d’utilisation de l’unité maître 12. L’état d’utilisation étant actif lorsque les résultats su s2, etc... retournés par l’unité maître 12 sont émis à destination d’un équipement tiers, ou passif lorsqu’ils ne sont pas émis à destination d’un équipement tiers. Sur les figures 2 et 3, un état d’utilisation actif est représenté en gras.

Le module de contrôle maître 28A est adapté pour transmettre périodiquement un message au module de contrôle esclave 28B. Le message indique que l’état d’utilisation de l’unité maître 12 est actif.

Le module de contrôle esclave 28B est adapté pour maintenir l’état d’utilisation de l’unité esclave 14 à la valeur passif tant que le message est reçu. En outre, il est adapté pour, lorsque le message n’est plus reçu, modifier l’état d’utilisation de l’unité esclave 14 de la valeur passif à la valeur actif.

On a représenté sur la figure 2, la mise en œuvre du procédé de synchronisation selon l’invention dans un mode de fonctionnement normal, c’est-à-dire dans lequel l’état de fonctionnement des unités maître et esclave 12, 14 prend respectivement la valeur actif et passif.

Comme visible sur la figure 2, les cycles sont mis en œuvre les uns à la suite des autres, à savoir Cycles puis Cycle2, etc..., jusqu’à Cycle, au niveau de l’unité maître 12 et Cycle’i, puis Cycle’2, etc..., jusqu’à Cycle’, au niveau de l’unité esclave 14. A chaque cycle, les modules de synchronisation 26A, 26B pilotent l’exécution simultanée de l’application A par les modules applicatifs 24A, 24B.

Lorsque l’application A exécutée par l’unité maître 12 retourne une donnée de contexte Cm lors de l’exécution d’un cycle, par exemple le cycle CycleM, le module de synchronisation maître 26A transmet au module de synchronisation esclave 26B ladite donnée de contexte cM.

Le module applicatif maître 24A prend alors en entrée ladite donnée de contexte c,. , pour l’exécution du cycle suivant Cycle,, dit cycle courant. En outre, le module de synchronisation esclave 26B reçoit ladite donnée de contexte ο,.ι pour que le module applicatif esclave 24B l’utilise pour l’exécution du cycle courant Cycle’,.

Ainsi, pour l’exécution des différents cycles Cycles, Cycle’2, etc..., l’unité esclave 14 n’exploite jamais de données de contexte c’, retournées lors de l’exécution de précédents cycle Cycles Cycle2, etc... par l’unité esclave 14.

En outre, le module de contrôle maître 28A transmet périodiquement le message au module de contrôle esclave 28B. De fait, le message étant toujours reçu dans le cas de la figure 2, le module de contrôle esclave 28B maintient l’état d’utilisation de l’unité esclave 14 à la valeur passif tandis que l’état d’utilisation de l’unité maître 12 demeure à la valeur actif.

La figure 3 illustre la mise en œuvre du procédé selon l’invention dans un mode de fonctionnement dégradé, à savoir lorsque l’état de fonctionnement de l’unité maître 12 passe de la valeur actif à la valeur passif.

Comme visible sur cette figure, l’unité maître 12 cessent d’émettre à destination d’un équipement tiers à contrôler et/ou à commander des résultats à compter du cycle Cycle,.

De fait, le module de contrôle esclave 28B ne reçoit plus le message et modifie l’état d’utilisation de l’unité esclave 14 de la valeur passif à la valeur actif. Comme visible sur la figure 3, l’état d’utilisation de l’unité esclave 14 prend la valeur actif à partir du cycle Cycle].·,. Dit autrement, au moins deux cycles s’écoulent avant que le module de fonctionnement esclave 28B modifie l’état de fonctionnement de l’unité esclave 14 à la valeur actif. A compter du moment où le module de contrôle esclave 28B ne reçoit plus le message, lors de chaque exécution des cycles Cycle’i+i, etc..., Cycle’j.i, Cycle’] suivants, le module applicatif esclave 24B prend en entrée les données de contexte c’,, etc..., c’j_i retournées par l’unité esclave 14 lors de l’exécution du cycle précédent.

Avantageusement, le dispositif de traitement comprend une liaison depuis le module de synchronisation esclave 26B vers le module de synchronisation maître 26A, le module de synchronisation esclave 26B étant adapté pour transmettre des données de contexte au module de synchronisation maître 26A. De fait, dans le cas de la figure 3, lorsque l’unité maître 12 est toujours en état de fonctionner, l’unité esclave 14 se comporte comme une unité maître, à savoir l’unité esclave 14 transmet les données de contexte retournées à l’unité maître 12 comme décrit précédemment, en référence à la figure 2. L’invention permet donc d’assurer la continuité contextuelle puisqu’il n’y a pas d’interruption dans les différentes données de contexte utilisées. Ainsi, dans le cas de la figure 2, l’exécution simultanée de l’application A par l’unité maître 12 et par l’unité esclave 14 utilise à chaque cycle la même donnée de contexte, à savoir la donnée de contexte retournée lors de l’exécution du précédent cycle par l’unité maître 12. Il en va de même dans le cas de la figure 3, dans la mesure où seul l’état de fonctionnement de l’unité esclave 14 est modifié, le fonctionnement de cette dernière étant inchangé. L’invention qui vient d’être décrite présente comme avantage d’utiliser des capacités mémoire et de calcul réduites par rapport aux procédés et dispositifs connus dans l’état de la technique puisqu’aucune opération de comparaison n’est effectuée sur les données de contexte retournées par l’unité maître 12 et l’unité esclave 14. En outre, les unités maître et esclave 12, 14 assurent également, avec des ressources réduites, la synchronisation temporelle des différents cycles.

Claims (8)

1. REVENDICATIONS

   1. - Procédé de synchronisation d’une unité maître (12) et d’au moins une unité esclave (14), chacune des unités maître et esclave (12, 14) étant adaptée pour exécuter une application (A) stockée dans des mémoires (20A, 20B) respectives des unités maître et esclave (12, 14), l’application (A) étant exécutée selon des cycles (Cyclei, CycleY Cycle2, Cycle’2, ...) et prenant en entrée des paramètres d’entrée (e^ e’·,, e2, e’2, etc...) et une donnée de contexte et retournant en sortie un résultat (s^ s\, s2, s’2, etc...) et une donnée de contexte (c-ι, c’i, c2, c’2) etc...), le procédé étant mis en en œuvre par un dispositif de traitement (10) et consistant à exécuter simultanément l’application (A) par les unités maître et esclave (12, 14), le procédé étant caractérisé en ce qu’à chaque cycle de l’application (A), dit cycle courant (Cycle,, Cycle’), l’unité maître (12) transmet à l’unité esclave (14) la donnée de contexte (Cm) retournée par l’unité maître (12) lors de l’exécution du cycle précédent (Cyclej-i), la donnée de contexte (c’M) retournée par l’unité esclave (14) n’étant pas transmise à l’unité maître (12) et n’étant pas exploitée par l’unité esclave (14), l’unité maître (12) et l'unité esclave (14) utilisant pour l’exécution du cycle courant (Cycles Cycle’) respectivement la donnée de contexte (c,.i) retournée par l’unité maître (12) et la donnée de contexte (cM) retournée et transmise par l’unité maître (12).
2. 2, - Procédé de synchronisation selon la revendication 1, dans lequel chacune des unités maître et esclave (12, 14) définit un état d’utilisation, l’état d’utilisation prenant la valeur actif lorsque les résultats (Si, s\, s2, s’2, etc...) retournés par ladite unité (12, 14) sont émis à destination d’un équipement tiers à contrôler et/ou à commander ou la valeur passiflorsque les résultats (s^ sY s2, s’2, etc...) retournés par ladite unité (12, 14) ne sont pas émis à destination d’un équipement tiers à contrôler et/ou à commander, le procédé comprenant une étape de pilotage de l’état d’utilisation des unités maître et esclave (12, 14), le contrôle consistant à : - transmettre de manière périodique un message depuis l’unité maître (12) vers l’unité esclave (14), - tant que le message est reçu par l’unité esclave (14), maintenir l’état d’utilisation de l’unité esclave (14) à la valeur passif, et - lorsque le message n’est plus reçu par l’unité esclave (14), modification de l’état d’utilisation de l’unité esclave (14) de la valeur passif à la valeur actif.
3. 3. - Procédé de synchronisation selon la revendication 2, dans lequel, dès que le message n’est plus reçu par l’unité esclave (14), l’unité esclave (14) utilise, à chaque cycle (Cycle’i+i, ..., Cycle’j-ι, Cycle’]), la donnée de contexte (c’,, c’i+i, c’].·,) retournée par l’unité esclave (14) lors du cycle précédent.
4. 4. - Procédé de synchronisation selon l’une quelconque des revendications précédentes, dans lequel les données de contexte (Ci, c’^ c2, c’2, etc...) comportent au moins un élément parmi le groupe consistant en : - un état d’un graphique fonctionnel de commande des étapes et transitions, - des calculs intermédiaires, et - toute donnée persistante d’un cycle au cycle suivant.
5. 5. - Dispositif de traitement (10) comprenant une unité maître (12) et au moins une unité esclave (14), les unités maître et esclave (12, 14) comprenant respectivement : - un module applicatif maître et esclave (24A, 24B) adapté pour exécuter une application (A) stockée dans des mémoires (20A, 20B) respectives des unités maître et esclave (12, 14), l’application (A) étant exécutée selon des cycles (Cycle!, Cycle1!, Cycle2, Cycle’2, ...) et prenant en entrée des paramètres d’entrée (βι, e’i, e2, e’2, etc...) et une donnée de contexte et retournant en sortie un résultat (si, s’i, s2, s’2, etc...) et une donnée de contexte (ci, c’!, c2, c’2l etc...), - un module de synchronisation maître et esclave (26A, 26B) adapté pour piloter, à chaque cycle de l’application (A), l’exécution de l’application (A) à la fois par l’unité maître (12) et par l’unité esclave (14), caractérisé en ce que les modules de synchronisation maître et esclave (26A, 26B) sont adaptés pour, à chaque cycle de l’application (A), dit cycle courant (Cycles Cycle’,), piloter la transmission depuis l’unité maître (12) vers l’unité esclave (14) de la donnée de contexte (cM) retournée par le module applicatif maître (24A) lors de l’exécution du cycle précédent (Cyclen), la donnée de contexte (Cn) retournée par le module applicatif esclave (24B) n’étant pas transmise à l’unité maître (12) et n’étant ^)as exploitée par l’unité esclave (14), les modules applicatifs maître et esclave (24A, .24B) recevant en entrée pour l’exécution du cycle courant (Cycles Cycle’j) respectivement la donnée de contexte (cM) retournée par le module applicatif maître (24A) et la donnée de contexte (cM) retournée et transmise par le module applicatif maître (24A).
6. 6. - Dispositif de traitement (10) selon la revendication 5, dans lequel chacune des unités maître et esclave (12, 14) définit un état d’utilisation, l’état d’utilisation prenant la valeur actif lorsque les résultats fo, s’i, s2, s’2, etc...) retournés par ladite unité (12, 14) sont émis à destination d’un équipement tiers à contrôler et/ou à commander ou la valeur passif lorsque les résultats (Si, s’·,, s2, s’2> etc...) retournés par ladite unité (12, 14) ne sont pas émis à destination d’un équipement tiers à contrôler et/ou à commander, les unités maître et esclave (12, 14) comprenant respectivement un module de contrôle maître et esclave (28A, 28B), le module de contrôle maître (28A) étant adapté pour transmettre périodiquement un message au module de contrôle esclave (28B), et le module de contrôle esclave (28B) étant adapté pour maintenir l’état d’utilisation de l’unité esclave (14) à la valeur passif tant que le message est reçu, et pour, lorsque le message n’est plus reçu, modifier l’état d’utilisation de l’unité esclave (14) de la valeur passif à la valeur actif.
7. 7. - Dispositif de traitement (10) selon la revendication 6, dans lequel, dès que le message n’est plus reçu par l’unité esclave (14), le module applicatif esclave (24B) est adapté pour, à chaque cycle (Cycle’i+1, ..., Cycle’^, Cycle’]), recevoir la donnée de contexte (c’j, c’i+1, c’j_i) retournée par l’unité esclave (14) lors du cycle précédent.
8. 8. - Véhicule de transport ferroviaire comprenant : - au moins un équipement tiers à contrôler et/ou à commander, et - au moins un module de contrôle et/ou de commande adapté pour contrôler et/ou commander l’équipement tiers à contrôler et/ou à commander, le module de contrôle et/ou de commande comprenant un dispositif de traitement (10) selon l’une quelconque des revendications 5 à 7.