FR 3104278 A1 20210611 FR 1913853 A 20191206 Système informatique (1) embarqué à bord d'un porteur, communiquant en réseau avec un concentrateur de données (2) et avec un moniteur (M), et mettant en œuvre au moins un service critique pour la sûreté de fonctionnement du porteur, le service critique étant en redondance en au moins deux instances (δ 1 , …, δ m ) sur des calculateurs respectifs différents (C 1 , …, C m ) connectés audit réseau, chaque calculateur (C k ) mettant en œuvre au moins une tâche logicielle implémentant une instance (δ k ) du service critique étant configuré pour mettre en œuvre le service critique par cadencement par le temps. Figures pour l’abrégé : Fig.1a et Fig.1b Système informatique embarqué à bord d'un porteur mettant en oeuvre au moins un service critique pour la sûreté de fonctionnement du porteur L’invention porte sur une architecture matérielle et/ou logicielle embarquée composée de services (ou composants) logiciels, en interaction avec un dispositif concentrant les données (par exemple une architecture « orientée service » munie d’un concentrateur de données ou « broker » ou « data functional bus » en langue anglaise). Certaines fonctions critiques pour la sûreté de fonctionnement sont implémentées par des systèmes embarqués complexes mis en œuvre sous forme matérielle et logicielle, telles un déclenchement d’airbags ou un freinage automatique d’urgence d’un véhicule. Il est particulièrement difficile et coûteux de développer et qualifier (voire certifier) ces systèmes au niveau de sûreté de fonctionnement suffisant, et il est d’autant plus complexe et coûteux que l’architecture matérielle ou logicielle sous-jacente est complexe. Pour améliorer la sûreté et la disponibilité de fonctions critiques implémentées en logiciel, il est courant de déployer plusieurs implémentations redondantes, en mode nommée « lock-step » qui consiste à utiliser au moins deux unités d’exécution physiques (par exemple deux calculateurs ou CPU pour acronyme de « central processing unit » en langue anglaise, sur un même système sur puce ou SoC pour acronyme de « system on chip » en langue anglaise), exécutant exactement le même code au même instant. Un dispositif matériel intégré au système sur puce détecte immédiatement lorsque les registres, ou les accès mémoire, des deux cœurs sont différents : ce qui signale qu’une défaillance est apparue dans au moins un des deux cœurs, il faut donc basculer sur un mode dégradé (par exemple redémarrer la fonction, ou la désactiver, signaler la défaillance, enclencher un mode d’exécution secondaire, etc.). Le lock-step classique n’est cependant possible qu’entre deux calculateurs physiquement proches, pour comparer leurs registres ou leurs mémoires. L’invention permet d’exploiter des calculateurs distants, connectés en réseau. Le lock-step classique nécessite des unités d’exécution identiques, exécutant exactement le même jeu de tâches logicielles (afin de que les exécutions soient cycle-à-cycle identiques, hors défaillance). Un but de l'invention est de pallier les problèmes précédemment cités, et notamment d'assurer une sûreté de fonctionnement à coût et complexité réduits. Il est proposé, selon un aspect de l'invention, un système informatique embarqué à bord d'un porteur, communiquant en réseau avec un concentrateur de données et avec un moniteur, et mettant en œuvre au moins un service critique pour la sûreté de fonctionnement du porteur, le service critique étant en redondance en au moins deux instances sur des calculateurs respectifs différents connectés audit réseau, - chaque calculateur mettant en œuvre au moins une tâche logicielle implémentant une instance du service critique, et étant configuré pour mettre en œuvre le service critique par cadencement par le temps en utilisant : - une suite croissante de dates d'activation de tâche et une suite de dates correspondantes de fin au plus tard de tâche, relatives au démarrage du système, avec un écart entre une date de fin et la date d'activation correspondante supérieur ou égal à un seuil correspondant à une estimation du temps d'exécution ou du temps de réponse de la tâche ; - une sauvegarde d'un état interne du calculateur entre deux activations successives du service par modélisation par enregistrement des états de mémoires de la tâche ; - une mise à jour de l'état interne du calculateur à chaque activation du service, démarrant après la date d'activation correspondante lit les données d'entrée (i n ) du service et calcule les données de sortie du service et les fournit au concentrateur de données, la dépendance entre d'une part l'état interne mis à jour et les données de sortie calculées et d'autre part l'état interne précédent et les données d'entrée lues étant représentée par une fonction de transfert ; et - un serveur relai, ou « proxy » en langue anglaise, configuré pour calculer une signature, caractéristique de l'exécution de l'instance du service depuis l'activation initiale du système jusqu'à la date de fin au plus tard en cours, par une chaîne de hachage dépendant d'une fonction de hachage sur nb bits, et pour transmettre la signature au moniteur ; le moniteur détectant une défaillance en analysant les signatures des instances. Un tel système permet d'assurer une sûreté de fonctionnement à coût et complexité réduits. Dans un mode de réalisation, un serveur relai est configuré pour calculer la signature par une chaîne de hachage utilisant une fonction de hachage cryptographique H, par récurrence pour chaque instance , à chaque période (ou pas de temps) , par la relation suivante : dans laquelle : représente la signature de l'instance k à la période n+1 ; représente la signature de l'instance k à la période n ; représente les données d'entrées du service de l'instance k à la période n ; et représente les données de sortie du service de l'instance k à la période n. Ainsi, la valeur est une signature caractéristique de l’historique des données d’entrée et de sortie du service critique depuis son démarrage, dont le volume de données est constant, et faible (typiquement 256 bits) au regard de l’ensemble des données d’entrées et sortie du service critique depuis son démarrage. Selon un mode de réalisation, le moniteur est configuré pour détecter une défaillance temporelle lorsqu'une signature des instances n'a pas été reçue avant la date de fin au plus tard de la période courante. Ainsi le moniteur contribue à la détection des défaillances temporelles des instances du service critique. Dans un mode de réalisation le moniteur est configuré pour comparer les signatures reçues des serveurs relais détecter une défaillance fonctionnelle lorsqu'une signature des instances diffère des autres signatures. Ainsi le moniteur détecte si au moins une des instances du service critique présente une défaillance fonctionnelle. Selon un mode de réalisation, le moniteur détecte une défaillance lorsque les signatures des instances sont égales mais qu'un état interne et/ou des données de sortie diffère des autres. Ainsi lorsque le nombre d'instances du service est au moins égal à trois, et que moins de la moitié de ces instances sont défaillantes, le moniteur est configuré pour effectuer un vote majoritaire parmi les signatures reçues à temps fournissant une signature majoritaire désignant les instances fonctionnelles, les signatures différentes de la signature majoritaire désignant les instances défaillantes, et configuré pour signaler au reste du système les instances fonctionnelles et les instances défaillantes de sorte que la transmission des instances défaillantes soit interrompue sur le concentrateur de données. Ainsi, le dispositif assure une détection et isolation des fautes fonctionnelles et temporelles des répliques, et tolérance aux pannes ce qui améliore la disponibilité globale du service. Par exemple, lorsqu’une instance est détectée comme défaillante à une période nd, le calculateur hébergeant l’instance défaillante est configuré pour récupérer une copie d'un état de mémoire interne correct d’une autre instance fonctionnelle correspondant à la période nd, redémarrer l’instance défaillante à partir de l'état de mémoire correct, et pour réinjecter à l'instance défaillante les données d’entrées depuis la période nd jusqu’à la période courante, en appliquant la fonction de transfert, éventuellement en retard par rapport aux dates de fin au plus tard correspondantes, et le moniteur est configuré, lorsque l’instance défaillante a rattrapé les instances fonctionnelles, c’est-à-dire appliqué, avant la n ième date de fin au plus tard, la fonction de transfert sur les entrées jusqu’à la période n, les signatures étant à nouveau égales, pour déclarer l’instance défaillante comme à nouveau fonctionnelle. Ainsi la séquence de signatures permet d’identifier une instance défaillante, d’identifier une instance fonctionnelle à partir de laquelle sera effectué le redémarrage et re-jeu de l’instance défaillante, puis d’identifier quand le re-jeu est terminé et l’instance à nouveau fonctionnelle. Selon un mode de réalisation, un serveur relai est un serveur logiciel implémenté sur le calculateur correspondant. Ainsi la mise en œuvre est simplifiée. Dans un mode de réalisation, un serveur relai est un serveur matériel implémenté au niveau du concentrateur de données. Ainsi, le proxy n’est pas soumis au risque de défaillance de l’exécutif logiciel comme l’instance qu’il surveille. Selon un mode de réalisation, le système comprend un réseau indépendant du concentrateur de données pour transmettre les signatures par les serveurs relais, de bande passante moins élevée et de fiabilité plus élevée que celles du concentrateur de données. Ainsi, la comparaison des signatures risque moins d’être compromise par un défaut d’intégrité ou défaut temporel lié à la transmission entre le serveur relai et le moniteur. Il est également proposé, selon un autre aspect de l'invention, un procédé de gestion d'au moins un service critique pour la sûreté de fonctionnement d'un système informatique embarqué à bord d'un porteur, le service critique étant en redondance en au moins deux instances sur des calculateurs respectifs différents connectés audit réseau, chaque mise en œuvre une instance du service critique utilise : - une suite croissante de dates d'activation de tâche et une suite de dates correspondantes de fin au plus tard de tâche, relatives au démarrage du système, avec un écart entre une date de fin et la date d'activation correspondante supérieur ou égal à un seuil correspondant à une estimation du temps d'exécution ou du temps de réponse de la tâche ; - une sauvegarde d'un état interne du calculateur entre deux activations successives du service par modélisation par enregistrement des états de mémoires de la tâche ; - une mise à jour de l'état interne du calculateur à chaque activation du service, démarrant après la date d'activation correspondante lit les données d'entrée du service et calcule les données de sortie du service et les fournit au concentrateur de données, la dépendance entre d'une part l'état interne mis à jour et les données de sortie calculées et d'autre part l'état interne précédent et les données d'entrée lues étant représentée par une fonction de transfert ; et - un calcul d'une signature par un serveur relai, caractéristique de l'exécution de l'instance du service depuis l'activation initiale du système jusqu'à la date de fin au plus tard en cours, par une chaîne de hachage dépendant d'une fonction de hachage sur nb bits, et une transmission de la signature au moniteur ; une détection d'une défaillance par le moniteur étant effectuée en analysant les signatures des instances. L'invention sera mieux comprise à l'étude de quelques modes de réalisation décrits à titre d'exemples nullement limitatifs et illustrés par les dessins annexés sur lesquels : illustre schématiquement un système selon un aspect de l'invention ; illustre schématiquement un système selon un aspect de l'invention ; et illustre schématiquement le fonctionnement d'un système de la figure 1, comprenant deux instances du service. Sur l'ensemble des figures, les éléments ayant des références identiques sont similaires. Les figures 1a et 1b illustrent schématiquement un système informatique 1 embarqué à bord d'un porteur, selon deux aspects de l'invention. Un système informatique 1 embarqué à bord d'un porteur, communique en réseau avec un concentrateur de données 2 et avec un moniteur M, et met en œuvre au moins un service critique pour la sûreté de fonctionnement du porteur, ou « safety critical » en langue anglaise, le service critique étant en redondance, i.e. exécuté en au moins deux instances δ 1 , … δ m sur des calculateurs respectifs différents C 1 , …, C m connectés audit réseau, en l'espèce deux répliques sur deux calculateurs respectifs. Chaque calculateur C 1 , …, C m met en œuvre une instance δ k du service critique, et est configuré pour mettre en œuvre le service critique en utilisant : - une suite croissante de dates d'activation R n du système et une suite de dates de fin correspondantes au plus tard D n , relatives au démarrage du système, avec un écart entre une date de fin et la date d'activation correspondante supérieur ou égal à un seuil correspondant à une estimation du temps d'exécution du service WCET. Les dates Rn et Dn respectent les inégalités suivantes : n, 0 n n+1 , 0 n n+1 , et D n -R n ≥WCET ; - une sauvegarde d'un état interne s n du calculateur (modélisation des états de mémoire, registres, variables du code) entre deux activations successives du service par modélisation par enregistrement des états de mémoires du calculateur ; - une mise à jour de l'état interne s n+1 du calculateur à chaque activation n du service, démarrant à la date d'activation correspondante R n lit les données d'entrée i n du service et calcule les données de sortie o n du service et les fournit au concentrateur de données 2, la dépendance entre d'une part l'état interne mis à jour et les données de sortie calculées s n+1 , on et d'autre part l'état interne précédent et les données d'entrée lues s n , i n étant représentée par une fonction de transfert f ; et - un serveur relai SR k configuré pour calculer une signature , caractéristique de l'exécution de l'instance du service depuis l'activation initiale 0 du système jusqu'à la date de fin au plus tard en cours D n , par une chaîne de hachage dépendant d'une fonction de hachage H sur nb bits, et pour transmettre la signature au moniteur M. Le moniteur M détecte une défaillance en analysant les signatures des instances δ 1 , … δ m . Sur la figure 1a, un serveur relai SR k est un serveur logiciel implémenté sur le calculateur correspondant C k , et sur la figure 1b un serveur relai SR k est un serveur matériel implémenté au niveau du concentrateur de données 2. La fonction de hachage H est une fonction de hachage cryptographique, c’est-à-dire qu’à un message de taille arbitraire, elle associe une empreinte h dite rapide à calculer, résistante à l’attaque par pré-image (étant donné une empreinte h, il est impossible en pratique de construire un message m tel que H(m)=h), à l’attaque par seconde pré-image (connaissant m1, il est impossible en pratique de construire un message m2 tel que H(m2)=H(m1)) ainsi qu'aux collisions (il est impossible en pratique de construire deux message différents m1 et m2 tels que H(m1)=H(m2)). Lorsqu'un service critique est redondé, plusieurs instances δ k (k=1, 2…m) implémentent la même fonction de transfert f, mais sont susceptibles de défaillances. On note X k les variables modélisant le fonctionnement de l'instance k, et X celle décrivant une instance théorique sans défaut. Chaque instance δ k répond aux mêmes contraintes temporelles R n et D n , est démarrée dans le même état initial , et reçoit les mêmes entrées avant la date R n (par envoi de message multicast ou envoi multiple). En conséquence, en mode nominal, toutes les instances calculent exactement les mêmes valeurs d’état interne , et produisent les mêmes sortie , avant la date au plus tard D n de la période en cours. Les instances ne s’exécutent pas nécessairement simultanément, elles peuvent s’exécuter sur des calculateurs de fréquences différentes, ou peuvent également être préemptées par d’autres tâches. La seule hypothèse nécessaire est que la n ième exécution, ou n ième « job » en langue anglaise, s’exécute effectivement entre les dates d'activation R n et au plus tard D n en cours. Supposons que l'instance δ 1 comporte une erreur, activée lors du n ième job : faute interne ou faute externe . L'invention permet de détecter au plus tôt ces fautes, pour signaler, et déclencher le cas échéant un mode de fonctionnement dégradé. La présente invention utilise le calcul d'une signature , caractéristique de l’exécution de chaque instance δ k depuis son démarrage jusqu’à la date au plus tard en cours D n , puis transmettre ces signatures à un moniteur M, qui les compare afin de détecter une erreur. La signature est calculée par une chaîne de hachage dans laquelle H est une fonction de hachage sur nb bits. Ce calcul peut être effectué par l'instance δ k . La signature est transmise au moniteur M via le concentrateur de données 2 avant la date plus tard en cours D n . Après la date plus tard en cours D n , le moniteur M compare toutes le signatures . En mode nominal, toutes les signatures sont égales. En supposant que le système est resté dans un mode nominal jusqu’à la date au plus tard D n-1 , le moniteur M détecte une défaillance dans les cas suivants : - si l’une des signatures n’a pas été reçue avant la date au plus tard D n , ce qui peut être dû à : - une faute temporelle au cours du nième job de l'instance δ k (calcul non terminé à temps, et violation de la date au plus tard D n ), ou - une faute temporelle dans la transmission d'un message comprenant une signature par le réseau (ou par ses pilotes ou logiciels), - si l’une des signatures diffère des autres, ce qui peut être dû à : - une perte d’intégrité de l’implémentation de fonction de transfert f k ≠f, l’activation de cette erreur conduit à un défaut de l’état interne , ou des sorties , - une perte d’intégrité, ou de disponibilité, des entrées i n reçues par l'instance k à la date d'activation Rn : , ou - une erreur de calcul de la signature par le serveur relai SR k , une perte d’intégrité, ou un retard de transmission du message contenant la signature au moniteur M : seuls ces deniers cas correspondent à un faux positif (le moniteur M signale alors un défaut sur l'instance δ k , alors qu’elle n’est pas en défaut). Un faux négatif peut se produire lorsque : - le moniteur M lui-même est défaillant; ce risque peut être réduit par divers moyens, dont la redondance du moniteur de sorte qu'il y ait au moins deux moniteurs M, M' ; - une majorité des instances δ k du service sont défaillantes et produisent la même signature : - ce risque est classiquement considéré comme suffisamment improbable pour être toléré dans le cas de défaillances de nature aléatoires, indépendantes, ou transitoires (si chaque instance a une probabilité de subir une défaillance aléatoire, et que les défaillances des instances sont supposées indépendantes, alors la probabilité que répliques soient défaillantes est ), - le risque de défauts permanents ou modes communs est classiquement réduit par des processus de conception, d’analyse et de tests rigoureux, - les signatures sont toutes égales, pourtant une réplique dévie de sa spécification, c’est-à-dire : et pourtant ; c’est-à-dire une collision pour la fonction de hachage : - pour une fonction de hachage cryptographique ou contrôle de redondance de type CRC sur nb bits, cette collision a une probabilité . En choisissant on réduit ce risque à une probabilité acceptable . (par exemple, pour une probabilité de défaillance tolérée de par heure de fonctionnement, avec comparaison de signatures à la période , soit par , bits est suffisant). Lorsque le moniteur M détecte une déviation dans les signatures reçues, il peut la signaler à un dispositif de gestion de l'état de fonctionnement ou « health management » en langue anglaise, qui aura charge de désactiver les répliques, basculer sur un mode dégradé nommé mode FT pour acronyme de « Fault Tolerant » en langue anglaise, ou de redémarrer toutes les répliques dans un état de référence. De façon complémentaire, si plus de deux répliques du service sont instanciées, le moniteur M peut déterminer, par un vote majoritaire, la ou les instances défaillantes, et les désactiver ou redémarrer sélectivement. Comme illustré sur la figure 2, pour redémarrer une instance défaillante δ k , il faut qu’une instance non défaillante δ j lui transmette une copie de son dernier état interne et de la signature corrects à l'itération n. L'instance δ k les copie alors dans sa mémoire en écrasant les valeurs précédemment calculées (probablement erronées) : et ; le cas échéant, pendant une phase de re-jeu jusqu’à la date R n+r+1 , l'instance δ k recalcule ses états internes et sorties, puis après la date d'activation R n+1 , l'instance δ k reprend le fonctionnement spécifié. L’invention permet de mettre en œuvre très efficacement le principe de redondance, avec moins de contraintes qu’un « lock-step » classique, avec une surcharge (« overhead » en langue anglaise) réseau et calculatoire limitée puisque la signature peut être réalisée par un message très court. Cette charge est encore réduite si le calcul de signature est effectué par un accélérateur matériel. A ce titre, le dispositif de génération de signature détaillé dans le brevet FR2989488B1 fournit une implémentation efficace de la signature de l’exécution. Dans le cas des fonctions sans état mémorisé (« stateless » en langue anglaise) ( ), le calcul de la signature peut être effectué par le concentrateur de données lui-même. Système informatique (1) embarqué à bord d'un porteur, communiquant en réseau avec un concentrateur de données (2) et avec un moniteur (M), et mettant en œuvre au moins un service critique pour la sûreté de fonctionnement du porteur, le service critique étant en redondance en au moins deux instances (δ 1 ,… δ m ) sur des calculateurs respectifs différents (C 1 , …, C m ) connectés audit réseau, chaque calculateur (C k ) mettant en œuvre au moins une tâche logicielle implémentant une instance (δ k ) du service critique et étant configuré pour mettre en œuvre le service critique par cadencement par le temps en utilisant : - une suite croissante de dates d'activation (R n ) de tâche et une suite de dates correspondantes de fin au plus tard (D n ) de tâche, relatives au démarrage (0) du système, avec un écart entre une date de fin et la date d'activation correspondante supérieur ou égal à un seuil correspondant à une estimation du temps d'exécution ou du temps de réponse de la tâche (WCET) ; - une sauvegarde d'un état interne (s n ) du calculateur entre deux activations successives du service par modélisation par enregistrement des états de mémoires de la tâche ; - une mise à jour de l'état interne (s n+1 ) du calculateur à chaque activation (n) du service, démarrant après la date d'activation correspondante (R n ) lit les données d'entrée (i n ) du service et calcule les données de sortie (o n ) du service et les fournit au concentrateur de données (2), la dépendance entre d'une part l'état interne mis à jour et les données de sortie calculées (s n+1 , on) et d'autre part l'état interne précédent et les données d'entrée lues (s n , i n ) étant représentée par une fonction de transfert (f) ; et - un serveur relai (SR k ) configuré pour calculer une signature ( ), caractéristique de l'exécution de l'instance ( ) du service depuis l'activation initiale (0) du système jusqu'à la date de fin au plus tard en cours (D n ), par une chaîne de hachage dépendant d'une fonction de hachage (H) sur nb bits, et pour transmettre la signature ( ) au moniteur (M) ; le moniteur (M) détectant une défaillance en analysant les signatures ( … ) des instances (δ 1 , …, δ m ). Système (1) selon la revendication 1, dans lequel un serveur relai est configuré pour calculer la signature par une chaîne de hachage utilisant une fonction de hachage cryptographique H, par récurrence pour chaque instance , à chaque période , par la relation suivante : dans laquelle : représente la signature de l'instance k à la période n+1 ; représente la signature de l'instance k à la période n ; représente les données d'entrées du service de l'instance k à la période n ; et représente les données de sortie du service de l'instance k à la période n. Système (1) selon l'une des revendications précédentes, dans lequel le moniteur (M) est configuré pour détecter une défaillance temporelle lorsqu'une signature ( ) des instances (δ 1 , …, δ m ) n'a pas été reçue avant la date de fin au plus tard (D n ) de la période courante. Système (1) selon l'une des revendications précédentes, dans lequel le moniteur (M) est configuré pour comparer les signatures reçues des serveurs relais (SR 1 , …, SR m ) détecter une défaillance fonctionnelle lorsqu'une signature ( ) des instances (δ 1 , …, δ m ) diffère des autres signatures ( ). Système (1) selon l'une des revendications précédentes, dans lequel, lorsque le nombre d'instances du service est au moins égal à trois, et que moins de la moitié de ces instances sont défaillances, le moniteur (M) est configuré pour effectuer un vote majoritaire parmi les signatures reçues à temps fournissant une signature majoritaire désignant les instances fonctionnelles, les signatures différentes de la signature majoritaire désignant les instances défaillantes, et configuré pour signaler au reste du système les instances fonctionnelles et les instances défaillantes de sorte que la transmission des instances défaillantes soit interrompue sur le concentrateur de données (2). Système selon la revendication 5, dans lequel, lorsqu’une instance est détectée comme défaillante à une période n d , le calculateur hébergeant l’instance défaillante est configuré pour récupérer une copie d'un état de mémoire interne correct d’une autre instance fonctionnelle correspondant à la période n d , redémarrer l’instance défaillante à partir de l'état de mémoire correct, et pour réinjecter à l'instance défaillante les données d’entrées depuis la période n d jusqu’à la période courante, en appliquant la fonction de transfert, éventuellement en retard par rapport aux dates de fin au plus tard correspondantes, et le moniteur (M) est configuré, lorsque l’instance défaillante a rattrapé les instances fonctionnelles, c’est-à-dire appliqué, avant la n ième date de fin au plus tard (Dn), la fonction de transfert sur les entrées jusqu’à la période n, les signatures étant à nouveau égales, pour déclarer l’instance défaillante comme à nouveau fonctionnelle. Système selon l'une des revendications précédentes, dans lequel un serveur relai (SR k ) est un serveur logiciel implémenté sur le calculateur correspondant (C k ). Système selon l'une des revendications 1 à 6, dans lequel un serveur relai (SR k ) est un serveur matériel implémenté au niveau du concentrateur de données (2). Système selon l'une des revendications précédentes, comprenant un réseau indépendant (RI) du concentrateur de données pour transmettre les signatures par les serveurs relais (SR k ), de bande passante moins élevée et de fiabilité plus élevée que celles du concentrateur de données (2). Procédé de gestion d'au moins un service critique pour la sûreté de fonctionnement d'un système informatique selon l'une des revendications 1 à 9, embarqué à bord d'un porteur, le service critique étant en redondance en au moins deux instances (δ 1 , …, δ m ) sur des calculateurs respectifs différents (C 1 , …, C m ) connectés audit réseau, chaque mise en œuvre une instance (δ k ) du service critique utilisant : - une suite croissante de dates d'activation (R n ) de tâche et une suite de dates correspondantes de fin au plus tard (D n ) de tâche, relatives au démarrage (0) du système, avec un écart entre une date de fin et la date d'activation correspondante supérieur ou égal à un seuil correspondant à une estimation du temps d'exécution ou du temps de réponse de la tâche (WCET) ; - une sauvegarde d'un état interne (s n ) du calculateur entre deux activations successives du service par modélisation par enregistrement des états de mémoires de la tâche ; - une mise à jour de l'état interne (s n+1 ) du calculateur à chaque activation (n) du service, démarrant après la date d'activation correspondante (R n ) lit les données d'entrée (i n ) du service et calcule les données de sortie (o n ) du service et les fournit au concentrateur de données (2), la dépendance entre d'une part l'état interne mis à jour et les données de sortie calculées (s n+1 , on) et d'autre part l'état interne précédent et les données d'entrée lues (s n , i n ) étant représentée par une fonction de transfert (f) ; et - un calcul d'une signature ( ) par un serveur relai, caractéristique de l'exécution de l'instance ( ) du service depuis l'activation initiale du système (0) jusqu'à la date de fin au plus tard en cours (D n ), par une chaîne de hachage dépendant d'une fonction de hachage (H) sur nb bits, et une transmission de la signature ( ) au moniteur (M) ; une détection d'une défaillance par le moniteur (M) étant effectuée en analysant les signatures ( ) des instances (δ 1 , …, δ m ).