Brevet FR3147393A1 — publié le 20241004

Procédé pour la surveillance de l’exécution d’un logiciel d’application (EUAP) mettant en œuvre une fonction de sécurité, comprenant la mise en œuvre d’un couplage par logiciel sur une structure d’unités de traitement asymétriques doubles, ladite structure d’unités de traitement comportant une première unité de traitement (PCPU) et une seconde unité de traitement (SCPU) ayant, en raison de ladite asymétrie, une structure matérielle différente et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement. Un premier logiciel d’exécution (RS) est exécuté sur le premier processeur (PCPU) tandis qu’un second logiciel d’exécution (SRS) qui est une version potentiellement modifiée du premier logiciel d’exécution (RS) et ayant le même comportement que celui dudit premier logiciel d’exécution, est exécuté sur le second processeur (SCPU). Figure pour l’abrégé : Fig 6 Procédé pour la surveillance de l’exécution d’un logiciel d’application mettant en œuvre une fonction de sécurité Des modes de réalisation de l’invention se rapportent à un schéma de couplage par logiciel (« software lockstep scheme » en anglais) pour la surveillance de l’exécution d’un logiciel d’application d’utilisateur final mettant en œuvre une fonction de sécurité, plus particulièrement basée sur un système sur puce (SoC) asymétrique. Dans les applications conformes à la sécurité fonctionnelle basées sur un SoC asymétrique, il est nécessaire de gérer les pannes permanentes et transitoires affectant des unités de traitement informatique (CPU) asymétriques doubles. Une première solution est une solution matérielle qui requiert cependant que le SoC ait été conçu avec des schémas de couplage intégrés au matériel. Mais si le SoC n’a pas été explicitement conçu pour des applications de sécurité avec des schémas de couplage intégrés au matériel, la solution doit être mise en œuvre par des moyens logiciels. Comme la solution est étroitement couplée à un logiciel d’application d’utilisateur final, aucune solution logicielle classique ne peut être techniquement fournie. Il existe ainsi un besoin de fournir une architecture logicielle permettant aux clients finaux de mettre en œuvre des solutions de couplage par logiciel sur un SoC ayant des CPUs asymétriques doubles qui n’ont pas été développées avec des schémas de couplage intégrés au matériel. Selon un mode de réalisation, il est proposé une façon de construire un couplage par logiciel (« software-based lock-step ») efficace et optimisé avec une modification minimale apportée au logiciel d’application d’utilisateur final d’origine. Selon un mode de réalisation, une architecture logicielle est proposée pour surpasser les schémas basiques de couplage par logiciel existants (basés sur un échange croisé) en termes d’optimisation et de flexibilité sur la classe présumée de SoCs cibles, car elle s’appuie fortement sur la caractéristique asymétrique des CPUs. Selon un aspect, un procédé est proposé pour la surveillance de l’exécution d’un logiciel d’application (le logiciel d’application d’utilisateur final) mettant en œuvre une fonction de sécurité. Le procédé selon cet aspect comprend la mise en œuvre d’un couplage par logiciel sur une structure d’unités de traitement asymétriques doubles, ladite structure d’unités de traitement comportant une première unité de traitement et une seconde unité de traitement ayant, en raison de ladite asymétrie, une structure matérielle différente et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement, ledit procédé comprenant - un partitionnement du logiciel d’application en un logiciel de démarrage et un premier logiciel d’exécution exécutant de manière séquentielle et itérative ladite fonction de sécurité sur la base d’une machine d’états au cours d’une séquence d’intervalles temporels successifs, - une fourniture d’un second logiciel d’exécution qui est une version potentiellement modifiée du premier logiciel d’exécution et ayant le même comportement (c’est-à-dire par exemple mettant en œuvre la même relation entre données d’entrée et données de sortie) que celui dudit premier logiciel d’exécution, - une exécution du logiciel de démarrage et du premier logiciel d’exécution par la première unité de traitement et une exécution du second logiciel d’exécution par la seconde unité de traitement, et au cours d’un intervalle temporel courant de ladite séquence : - une réalisation d’un traitement de contrôle comprenant au moins un traitement de comparaison réalisé à la fin de l’exécution dudit second logiciel d’exécution entre des résultats de l’exécution du premier logiciel d’exécution et des résultats de l’exécution du second logiciel d’exécution. Ainsi, la combinaison d’une structure de CPUs asymétriques doubles avec l’utilisation de deux logiciels d’exécution, dont l’un est potentiellement moins efficace, permet d’obtenir un couplage lâche et asymétrique par logiciel avec une complexité réduite des modifications du logiciel d’application d’utilisateur final tout en satisfaisant des exigences comprises dans des normes de sécurité spécifiques telles que IEC 61508, ISO 26262 pour des SoC à CPUs multiples. Les deux logiciels d’exécution peuvent ainsi être un logiciel embarqué sur un tel SoC incorporé dans, par exemple mais non limitativement, un robot aspirateur de poussières. Selon un mode de réalisation, le premier logiciel d’exécution reçoit, lors une itération courante, un premier vecteur de données d’entrée courant et un premier vecteur de variables d’état courant et délivre un premier vecteur de données de sortie courant et un premier vecteur de variables d’état mis à jour courant qui seront respectivement le vecteur de données d’entrée suivant et le vecteur de variables d’état suivant pour l’itération suivante. En d’autres termes, le premier logiciel d’exécution est modélisé pour être une machine d’états atomique qui, pour chaque itération donnée, reçoit un premier vecteur de données d’entrée courant et un premier vecteur de variables d’état courant et délivre un premier vecteur de données de sortie courant et un premier vecteur de variables d’état mis à jour courant qui seront respectivement le vecteur de données d’entrée suivant et le vecteur de variables d’état suivant pour l’itération suivante. Selon ce mode de réalisation, le traitement de contrôle comprend : a) une sélection d’au moins une itération et pour ladite au moins une itération sélectionnée : b) un stockage du premier vecteur de données de sortie correspondant et du premier vecteur de variables d’état mis à jour correspondant dans une mémoire, c) une fourniture, au second logiciel d’exécution, du premier vecteur de données d’entrée correspondant et du premier vecteur de variables d’état correspondant, et une obtention, à partir dudit second logiciel d’exécution, à un moment ultérieur au moment auquel le premier vecteur de données de sortie correspondant et le premier vecteur de variables d’état mis à jour correspondant sont délivrés, d’un second vecteur de données de sortie correspondant et d’un second vecteur de variables d’état mis à jour correspondant, d) une comparaison dudit premier vecteur de données de sortie correspondant avec ledit second vecteur de données de sortie correspondant et une comparaison dudit premier vecteur de variables d’état mis à jour correspondant avec ledit second vecteur de variables d’état mis à jour correspondant, et e) en cas de concordance à l’étape d), une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Un tel mode de réalisation permet de détecter, en cas de discordance à l’étape d), des pannes permanentes affectant la première unité de traitement et/ou la seconde unité de traitement. D’autres modes de réalisation permettent d’ajouter la capacité de détecter des pannes transitoires affectant la première unité de traitement. Plus particulièrement, selon un mode de réalisation, ledit traitement de contrôle peut en outre comprendre : f) une réalisation, au cours dudit intervalle temporel courant de ladite séquence, d’une double exécution de chaque première itération du logiciel d’exécution à l’aide du même vecteur de données d’entrée correspondant et du même vecteur de variables d’état correspondant pour les deux exécutions, et une comparaison des deux vecteurs de données de sortie et une comparaison des deux vecteurs de variables d’état mis à jour obtenus respectivement par les deux exécutions, et g) en cas de concordance à l’étape f) pour chaque double exécution de chaque itération, la répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Un tel mode de réalisation permet de détecter, en cas de discordance à l’étape f), des pannes transitoires affectant la première unité de traitement. Cette double exécution de calcul est une option qui, lorsqu’elle est mise en œuvre, conduit à une pénalité de performance temporelle plus élevée. En particulier lorsque cette option de calcul double est activée, ledit traitement de contrôle comprend en outre, au cours dudit intervalle temporel courant : - h) un comptage du nombre d’itérations du premier logiciel d’exécution exécutées au cours de l’exécution du second logiciel d’exécution, - i) une comparaison, à la fin de l’exécution du second logiciel d’exécution, de la valeur de comptage avec une valeur attendue, et - j) en cas de concordance à l’étape i), une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. En d’autres termes, dans un tel cas, le contrôle peut comprendre uniquement la vérification que le premier logiciel d’exécution a été exécuté le nombre de fois attendu (qui est connu de manière déterministe) au cours de l’exécution du second logiciel d’exécution. Pour la réalisation d’un tel niveau minimal de contrôle, un simple compteur unique est suffisant. Selon un autre mode de réalisation qui en particulier permet de détecter des pannes transitoires affectant la première unité de traitement, par exemple utilisé lorsque l’option de calcul double n’est pas activée, ledit traitement de contrôle peut en outre comprendre, au cours dudit intervalle temporel courant : - k) un stockage, pour chaque itération du premier logiciel d’exécution, du premier vecteur de données d’entrée courant correspondant, du premier vecteur de variables d’état courant correspondant, du premier vecteur de données de sortie courant correspondant et du premier vecteur de variables d’état mis à jour courant correspondant, - l) une réalisation, à la fin de l’exécution du second logiciel d’exécution, de contrôles de vraisemblance sur tous les vecteurs stockés à l’étape k), - m) en cas de contrôles réussis à l’étape l) une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Les contrôles de vraisemblance peuvent en outre comprendre, par exemple, des contrôles de violation de valeurs limites. Bien entendu, l’efficacité et la complexité de la mise en œuvre de contrôles dépendent fortement de la nature de l’algorithme mis en œuvre dans le premier logiciel d’exécution et de dépendances associées entre entrées et sorties. L’homme du métier sera apte à choisir les contrôles de vraisemblance appropriés en fonction de l’application de sécurité d’utilisateur final. Un tel mode de réalisation permet de détecter, en cas de contrôles non réussis à l’étape l), des pannes transitoires affectant la première unité de traitement. Quel que soit le mode de réalisation, ledit traitement de contrôle peut en outre comprendre, en cas de discordance à l’étape d) et/ou f) et/ou i) et/ou en cas de contrôles non réussis à l’étape l), la délivrance d’un signal d’erreur. Ensuite, l’utilisateur final peut ainsi décider quelle action doit être entreprise lors de la réception d’un tel signal d’erreur. Par exemple, lorsque l’utilisateur final souhaite mettre en œuvre un schéma opérationnel après panne ou tolérant aux pannes, le procédé peut en outre comprendre la répétition dudit traitement de contrôle pendant l’intervalle temporel suivant de ladite séquence, en dépit de la délivrance dudit signal d’erreur. Selon un autre aspect, un système sur puce est proposé, comprenant une structure d’unités de traitement asymétriques doubles, ladite structure d’unités de traitement comportant une première unité de traitement et une seconde unité de traitement ayant, en raison de ladite asymétrie, une structure matérielle modifiée et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement, ladite structure d’unités de traitement étant configurée pour réaliser le procédé pour la surveillance de l’exécution d’un logiciel d’application mettant en œuvre une fonction de sécurité. D’autres caractéristiques et avantages de la présente invention apparaîtront lors de l’examen de la description détaillée qui suit, fournissant uniquement un exemple non limitatif de modes de réalisation, en référence aux dessins annexés dans lesquels : et illustrent des modes de réalisation et de mise en œuvre de l’invention. Sur la , le signe de référence EUC désigne un dispositif ou un équipement sous commande, par exemple un robot aspirateur de poussières, comportant par exemple des capteurs classiques SM, des moteurs classiques WM commandant les mouvements des roues du robot et un système sur puce SoC configuré pour exécuter un logiciel d’application embarqué mettant en œuvre une fonction de sécurité. Le système sur puce est configuré pour recevoir des données d’entrée provenant des capteurs et délivrer des consignes aux moteurs WM. La fonction de sécurité dépend de l’application. Par exemple pour un tel robot, la fonction de sécurité peut comporter, d’une manière non limitative, les actions suivantes : « ne pas heurter un objet », « ne pas descendre les escaliers », « ne pas dépasser une vitesse choisie » ..… Comme illustré sur la , le logiciel d’application EUAP mettant en œuvre la fonction de sécurité sur le SoC est partitionné en deux sous-parties : un logiciel de démarrage STS et un premier logiciel d’exécution RS. Le logiciel de démarrage STS est une section du logiciel d’application EUAP exécutée uniquement au démarrage/à la réinitialisation du système ou au cours de périodes spéciales de maintenance/hors ligne. Il est en charge d’exécuter des diagnostics de système basiques au démarrage et de configurer correctement le SoC pour la mise en œuvre de la fonction de sécurité. Le premier logiciel d’exécution RS est une section du logiciel d’application EUAP exécutée en continu pour mettre en œuvre la fonction de sécurité. Plus précisément, le premier logiciel d’exécution exécute de manière séquentielle et itérative ladite fonction de sécurité sur la base d’une machine d’états au cours d’une séquence d’intervalles temporels successifs. Comme illustré sur les Figures 3 et 4, le premier logiciel d’exécution comporte la machine d’états atomique qui, pour chaque itération d’exécution courante, reçoit en entrée un premier vecteur de données d’entrée courant ID[k] (premier vecteur de données d’entrée) et un premier vecteur de variables d’état courant CSV[j] et produit un premier vecteur de données de sortie courant OD[i] (vecteur de données de sortie) et un premier vecteur de variables d’état mis à jour courant USV[j] qui seront respectivement le vecteur de données d’entrée suivant et le vecteur de variables d’état suivant pour la prochaine itération du premier logiciel d’exécution. Dans le cas où un signal ou des signaux provenant de/allant vers des périphériques sont utilisés pour une entrée ou des sorties, les vecteurs de données ID[k] et/ou OD[j] contiennent une copie numérique d’une valeur de signal ou de valeurs de signaux comme « modèle » des signaux eux-mêmes. Le premier vecteur de données d’entrée courant ID[k] est un ensemble de toutes données d’entrée provenant de l’extérieur (les capteurs SM) nécessaires au premier logiciel d’exécution RS, et de données supplémentaires provenant d’une exécution d’une itération précédente du premier logiciel d’exécution RS (données temporaires). Les données peuvent être d’une quelconque nature et produites par le système d’une quelconque manière (par exemple, stockées dans une mémoire volatile par un module d’accès direct à la mémoire (DMA), directement reçues par un périphérique de communication). Par exemple, dans le cas d’un robot aspirateur de poussières, les données d’entrée peuvent être par exemple des données liées à la trajectoire, des données liées aux vitesses courantes des roues, des données liées à la direction, … Le premier vecteur de données de sortie courant OD[i] est constitué de données de collection générées par le premier logiciel d’exécution RS pour mettre en œuvre la fonction de sécurité en interagissant avec le monde extérieur, et de données temporaires devant être utilisées lors de l’itération d’exécution suivante du premier logiciel d’exécution RS. Les données peuvent être d’une quelconque nature et utilisées pour interagir avec l’extérieur de différentes manières, par exemple en définissant correctement des entrées/sorties à usage général (GPIO), ou envoyées avec un périphérique de communication vers un pair distant, ou pour modifier des signaux générés comme des signaux à modulation de largeur d’impulsions (PWM) ou des lignes analogiques. Le premier vecteur de variables d’état courant CSV[j] est un ensemble de toutes les premières variables internes du premier logiciel d’exécution aptes à déterminer de manière unique le statut complet de sa machine d’états. Par exemple dans le cas d’un robot aspirateur de poussières, ces variables peuvent être, d’une manière non limitative, des variables liées aux différents états suivants : « nettoyage », « retour à la station de base », « en charge », etc. Le premier vecteur de variables d’état mis à jour courant USV[j] possède la même structure que CSV[j], la seule différence est que USV[j] est mis à jour par l’exécution de chaque itération du premier logiciel d’exécution (en d’autres termes, il reflète le statut de la machine d’états après l’exécution d’une itération d’exécution du premier logiciel d’exécution. Comme illustré sur la , le système sur puce SoC comporte une première unité de traitement ou unité de traitement principale PCPU, par exemple un processeur, et une seconde unité de traitement ou unité de traitement secondaire SCPU, par exemple un processeur. Les deux unités de traitement PCPU et SCPU forment une structure d’unités de traitement asymétriques doubles. La première unité de traitement PCPU est chargée d’exécuter le logiciel d’application. Il peut être pris en charge lors de la mise en œuvre de la fonction de sécurité par des accélérateurs matériels spécifiques utilisés au niveau d’un environnement d’exécution par le premier logiciel d’exécution RS. La seconde unité de traitement SCPU possède, en raison de ladite asymétrie, une structure matérielle différente et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement PCPU. Par exemple, en vertu de la nature asymétrique de la structure d’unités de traitement, la seconde unité de traitement n’est pas équipée de l’ensemble complet d’accélérateurs matériels disponibles (si tel est le cas) sur la première unité de traitement PCPU, ou la seconde unité de traitement peut posséder une capacité de calcul inférieure (car elle fonctionne à une fréquence d’horloge inférieure et/ou car il s’agit d’une unité de traitement plus simple ( « Computer Processing Unit » :CPU) et/ou car elle utilise une partie de sa bande passante pour exécuter d’autres tâches). La seconde unité de traitement est configurée pour exécuter un second logiciel d’exécution. Le second logiciel d’exécution SRS est une version potentiellement modifiée du premier logiciel d’exécution. Il possède le même comportement que le premier logiciel d’exécution RS (c’est-à-dire par exemple mettant en œuvre la même relation entre données d’entrée et données de sortie), de façon à produire les mêmes sorties OD[j], USV[j] lorsqu’il est alimenté avec les mêmes entrées ID[k], CSV[j]. Une mise en œuvre au niveau du code source peut être différente pour composer par exemple avec l’absence, sur la seconde unité de traitement, des accélérateurs matériels utilisés dans la première unité de traitement. Par exemple, l’absence d’une unité à virgule flottante (« Floating Point Unit :FPU ») sur la seconde unité de traitement SCPU peut être gérée dans le second logiciel d’exécution SRS par une bibliothèque logicielle mettant en œuvre des fonctions d’unité à virgule flottante. Par analogie, l’absence d’un processeur de signal numérique (« Digital Signal Processor » :DSP) sur la seconde unité de traitement SCPU peut être gérée dans le second logiciel d’exécution SRS par une bibliothèque logicielle mettant en œuvre des fonctions de processeur de signal numérique. Dans le cas où la nature asymétrique des deux unités de traitement PCPU et SCPU est simplement liée à une fréquence d’horloge/une puissance de calcul, il pourrait être supposé que le second logiciel d’exécution SRS soit principalement identique au premier logiciel d’exécution RS. Si un module logiciel de chien de garde est présent pour d’autres besoins que ceux de l’invention, il peut être géré par la première unité de traitement PCPU et en cas d’expiration d’un délai d’attente, il doit être apte à réinitialiser les deux unités de traitement PCPU et SCPU et à forcer le système à passer dans un état sécurisé. Cependant, ce module chien de garde n’est pas obligatoire pour la réalisation du procédé selon l’invention. Un autre module logiciel PSS fonctionne sur la première unité de traitement PCPU. Ce module logiciel est un logiciel dédié chargé d’exécuter des tâches de sécurité basiques telles que la copie/récupération de données vers/à partir d’une zone sécurisée, le contrôle croisé de données produites par le schéma de couplage , le signalement d’erreurs, la gestion d’un chien de garde externe. Une zone sécurisée est une zone de mémoire utilisée par l’algorithme pour stocker des données liées à la sécurité. Toutes les données stockées dans cette zone sont avantageusement protégées contre les erreurs logicielles par une somme de contrôle (par exemple une somme de contrôle simple telle que OU exclusif est suffisante). Lorsque des données (ou un ensemble de données) est (sont) récupéré(es) à partir de la zone sécurisée, leur intégrité, par le contrôle de la somme de contrôle associée, est vérifiée avant de les consommer. Il sera maintenant fait référence plus particulièrement à la pour la description d’un mode de mise en œuvre du procédé selon l’invention comportant un traitement de contrôle CHKPR. Comme mentionné ci-dessus, le premier logiciel d’exécution RS exécute de manière séquentielle et itérative ladite fonction de sécurité sur la base d’une machine d’états au cours d’une séquence d’intervalles temporels successifs Tdiag(i). Tdiag (i) est également la période temporelle ou l’intervalle temporel au sein de laquelle ou duquel le calcul du second logiciel d’exécution est exécuté par la seconde unité de traitement SCPU et les contrôles sont exécutés par le module logiciel PSS. La chronologie du système est par conséquent partitionnée en une séquence d’intervalles temporels Tdiag(i). La norme IEC 61508 définit ce que l’on appelle un « temps de sécurité de processus (PST) » comme étant une « période temporelle entre une panne, qui a le potentiel de faire émerger un événement dangereux, survenant dans l’équipement sous commande EUC et le temps pendant lequel une action doit être achevée dans l’équipement sous commande EUC pour empêcher que l’événement dangereux ne survienne ». En vertu de l’interprétation du point de vue de IEC 61508, la valeur PST est supérieure à la valeur Tdiag, donc Tdiag discrimine les applications de sécurité qui peuvent potentiellement être adressées par le procédé selon l’invention, selon le PST requis. Plus « l’émulation » de la première unité de traitement PCPU par la seconde unité de traitement SCPU via l’exécution du second logiciel d’exécution SRS est complexe, ou lente, plus Tdiag sera grand. Sur la , il est supposé qu’une option logicielle d’exécution de calcul double (qui sera expliquée plus en détail ci-après) n’est pas activée. En outre, pour des raisons de simplification de la Figure, même si, comme expliqué ci-dessus en référence à la , une itération courante (n) du premier logiciel d’exécution RS reçoit en entrée le premier vecteur de données d’entrée courant ID[k] (n) et le premier vecteur de variables d’état courant CSV[j] (n) et produit le premier vecteur de données de sortie courant OD[i] (n) et le premier vecteur de variables d’état courant mis à jour USV[j] (n) qui seront respectivement le vecteur de données d’entrée suivant ID[k] (n+1) et le vecteur de variables d’état suivant CSV[j] (n+1) pour la prochaine itération (n+1) du premier logiciel d’exécution, les indices n, n+1, n+2, ... des itérations successives ne sont pas représentées sur cette . 1) Lors de la première exécution (par exemple) du premier logiciel d’exécution RS, qui est ici par exemple l’itération (n), pendant l’intervalle temporel courant Tdiag(i), une copie locale LCP(n) de ID, OD, CSV, USV est stockée dans la zone sécurisée SMM. La copie stockée de ID/CSV est utilisée comme entrée pour l’exécution du second logiciel d’exécution SRS qui démarre immédiatement en « arrière-plan » sur la seconde unité de traitement SCPU. Le premier logiciel d’exécution RS est exécuté de manière séquentielle et itérative sur la première unité de traitement PCPU. Pour chaque itération (n), (n+1), n+2),… une copie locale LCP (n), LCP (n+1), LCP (n+2),…. des ID, OD, CSV, USV correspondants est sauvegardée dans la zone sécurisée SMM. Le second logiciel d’exécution SRS produit sa sortie OD’[i] et USV’[j]. La seconde unité de traitement SCPU informe la première unité de traitement PCPU que des données sont disponibles. Ensuite, la première unité de traitement PCPU démarre l’exécution du module PSS. Des contrôles de sécurité sont réalisés par ce module PSS. Plus particulièrement, un premier contrôle comprend une comparaison entre OD’[i] et OD[i] et entre USV’[j] et USV[j]. Si OD’[i] = OD[i] et USV’[j] = USV[j] (correspondant à une concordance), il n’y a pas de panne détectée. S’il n’y a pas de concordance, une panne permanente affectant la première unité de traitement PCPU est détectée. Un second contrôle peut être avantageusement réalisé. Plus précisément, l’ensemble de copies locales stockées LCP(n), LCP(n+1), LCP(n+2)…. est contrôlé en termes de cohérence. Ceci permet de détecter d’éventuelles pannes transitoires affectant la première unité de traitement PCPU au cours de son exécution de RS pendant l’intervalle temporel Tdiag. Ce second contrôle est réalisé par le module PSS à la fin de l’exécution du second logiciel SRS, sur toutes les copies locales LCP(p) disponibles. Ce second contrôle est par exemple basé sur des procédés de contrôle de vraisemblance, comme par exemple des contrôles de violation de valeurs limites. L’efficacité et la complexité de la mise en œuvre du second contrôle dépendent fortement de la nature de l’algorithme mis en œuvre dans le premier logiciel d’exécution RS et de dépendances associées entre entrées et sorties. En cas de concordance : - le chien de garde externe (le cas échéant) est réinitialisé, - la procédure comportant le traitement de contrôle CHKPR redémarre au point 1) ci-dessus pour l’intervalle temporel suivant Tdiag (i+1). En cas de discordance : - le résultat du diagnostic est « ÉCHEC » et il est signalé au collecteur d’erreurs système pour des actions nécessaires par un message d’erreur dédié LCLSEM, - le chien de garde externe (le cas échéant) n’est pas réinitialisé (ouvrant la voie à son intervention possible). Comme indiqué ci-dessus, lorsque des données (ou un ensemble de données) est (sont) récupéré(es) à partir de la zone sécurisée SMM, leur intégrité, par le contrôle de la somme de contrôle associée, est vérifiée avant de les consommer. En cas de contrôle qui a échoué sur la somme de contrôle, le résultat de tout le diagnostic est également « ÉCHEC » et il est signalé au collecteur d’erreurs système pour des actions nécessaires par le message d’erreur dédié SAEM. En variante, la procédure pourrait être redémarrée au point 1) ci-dessus (comme en cas de concordance) si l’utilisateur final souhaite mettre en œuvre un schéma opérationnel après panne ou tolérant aux pannes. Il sera maintenant fait référence plus particulièrement aux Figures 7 et 8 pour la description de l’option logiciel d’exécution à calcul double DCRSO. Cette option, lorsqu’elle est activée dans le premier logiciel d’exécution RS, envisage l’exécution doublée de chaque itération (ou instance) courante (n) du premier logiciel d’exécution RS, en utilisant le même ensemble d’entrées ID[k](n), CSV[j](n). Les résultats de la première exécution sont stockés dans une mémoire volatile MM1 et comparés ensuite avec les résultats obtenus par la seconde exécution. Cette comparaison est réalisée par un contrôleur logiciel CHK mis en œuvre dans la première unité de traitement PCPU. Une discordance est signalée au collecteur d’erreurs système pour des actions nécessaires par un message d’erreur dédié DCEM. Cette option, lorsqu’elle est activée, impose la pénalité de performance la plus élevée au procédé selon l’invention (presque 50 % de perte de performances sur l’exécution du premier logiciel d’exécution RS sur la première unité de traitement PCPU). Lorsque cette option est activée, le second contrôle mentionné ci-dessus peut être plus simple. Plus précisément, dans un tel cas, comme illustré sur la , le niveau minimal de contrôle est de vérifier que le premier logiciel d’exécution RS a été exécuté le nombre de fois attendu au cours d’une période d’exécution de SRS (ce nombre de fois est connu de manière déterministe). Dans un tel cas, un simple compteur CRT unique est suffisant. Les nombres d’itérations RS sont comptés (étape 90) et la valeur obtenue Nb est comparée (étape 91) avec la valeur attendue EXNb. Il est ainsi proposé ici une architecture logicielle de référence permettant à des utilisateurs finaux de mettre en œuvre une solution de couplage par logiciel sur un SoC ayant des CPU asymétriques doubles qui n’ont pas été développées avec des schémas de couplage intégrés au matériel. La mise en œuvre permet de se conformer à des exigences de normes de sécurité fonctionnelle (par exemple IEC 61508 pour les applications industrielles) avec des avantages associés : - complexité réduite des modifications du logiciel d’application EUAP, - perte de performances optimisée en s’appuyant sur les caractéristiques spécifiques des schémas de CPU asymétriques doubles. L’architecture logicielle proposée surpasse les schémas basiques de couplage par logiciel existants (basés sur un échange croisé) en termes d’optimisation et de flexibilité sur la classe présumée de SoCs cibles, car elle s’appuie fortement sur la caractéristique asymétrique des CPUs. Procédé pour la surveillance de l’exécution d’un logiciel d’application mettant en œuvre une fonction de sécurité, comprenant la mise en œuvre d’un couplage par logiciel sur une structure d’unités de traitement asymétriques doubles, ladite structure d’unités de traitement comportant une première unité de traitement (PCPU) et une seconde unité de traitement (SCPU) ayant, en raison de ladite asymétrie, une structure matérielle différente et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement, ledit procédé comprenant - un partitionnement du logiciel d’application (EUAP) en un logiciel de démarrage et un premier logiciel d’exécution (RS) exécutant de manière séquentielle et itérative ladite fonction de sécurité sur la base d’une machine d’états au cours d’une séquence d’intervalles temporels successifs (Tdiag(i)), - une fourniture d’un second logiciel d’exécution (SRS) qui est une version potentiellement modifiée du premier logiciel d’exécution (RS) et ayant le même comportement que celui dudit premier logiciel d’exécution, - une exécution du logiciel de démarrage (STS) et du premier logiciel d’exécution (RS) par la première unité de traitement (PCPU) et une exécution du second logiciel d’exécution (SRS) par la seconde unité de traitement (SCPU), et - au cours d’un intervalle temporel (Tdiag(i)) courant de ladite séquence, une réalisation d’un traitement de contrôle (CHKPR) comprenant au moins un traitement de comparaison réalisé à la fin de l’exécution dudit second logiciel d’exécution entre des premiers résultats de l’exécution du premier logiciel d’exécution (RS) et des seconds résultats de l’exécution du second logiciel d’exécution (SRS). Procédé selon la revendication 1, dans lequel le premier logiciel d’exécution (RS) reçoit, lors une itération courante, un premier vecteur de données d’entrée courant et un premier vecteur de variables d’état courant et délivre un premier vecteur de données de sortie courant et un premier vecteur de variables d’état mis à jour courant qui seront respectivement le vecteur de données d’entrée suivant et le vecteur de variables d’état suivant pour l’itération suivante, et dans lequel le traitement de contrôle comprend : a) une sélection d’au moins une itération et pour ladite au moins une itération sélectionnée : b) un stockage du premier vecteur de données de sortie correspondant et du premier vecteur de variables d’état mis à jour correspondant dans une mémoire, c) une fourniture, au second logiciel d’exécution (SRS), du premier vecteur de données d’entrée correspondant et du premier vecteur de variables d’état correspondant, et une obtention, à partir dudit second logiciel d’exécution (SRS), à un moment ultérieur au moment auquel le premier vecteur de données de sortie correspondant et le premier vecteur de variables d’état mis à jour correspondant sont délivrés, d’un second vecteur de données de sortie correspondant et d’un second vecteur de variables d’état mis à jour correspondant, d) une comparaison dudit premier vecteur de données de sortie correspondant avec ledit second vecteur de données de sortie correspondant et une comparaison dudit premier vecteur de variables d’état mis à jour correspondant avec ledit second vecteur de variables d’état mis à jour correspondant, et e) en cas de concordance à l’étape d), une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon la revendication 2, dans lequel ledit traitement de contrôle comprend en outre : f) une réalisation, au cours dudit intervalle temporel courant de ladite séquence, d’une double exécution (DCRSO) de chaque première itération de logiciel d’exécution à l’aide du même vecteur de données d’entrée correspondant et du même vecteur de variables d’état correspondant pour les deux exécutions, et une comparaison des deux vecteurs de données de sortie et une comparaison des deux vecteurs de variables d’état mis à jour obtenus respectivement par les deux exécutions, et g) en cas de concordance à l’étape f) pour chaque double exécution de chaque première itération de logiciel d’exécution, une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon la revendication 3, dans lequel ledit traitement de contrôle comprend en outre, au cours dudit intervalle temporel courant : - h) un comptage (90) du nombre d’itérations du premier logiciel d’exécution exécutées au cours de l’exécution du second logiciel d’exécution, - i) une comparaison, à la fin de l’exécution du second logiciel d’exécution, de la valeur de comptage (Nb) avec une valeur attendue (EXNb), et - j) en cas de concordance à l’étape i), une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon la revendication 2, dans lequel ledit traitement de contrôle comprend en outre, au cours dudit intervalle temporel courant (Tdiag(i)) : - k) un stockage (SMM), pour chaque itération du premier logiciel d’exécution, du premier vecteur de données d’entrée courant correspondant, du premier vecteur de variables d’état courant correspondant, du premier vecteur de données de sortie courant correspondant et du premier vecteur de variables d’état mis à jour courant correspondant, - l) une réalisation, à la fin de l’exécution du second logiciel d’exécution, de contrôles de vraisemblance sur tous les vecteurs stockés à l’étape k), - m) en cas de contrôles réussis à l’étape l) une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon l’une quelconque des revendications 2 à 5, dans lequel ledit traitement de contrôle comprend en outre, en cas de discordance à l’étape d) et/ou f) et/ou i) et/ou en cas de contrôles non réussis à l’étape l), une délivrance d’un signal d’erreur (LCLSEM, SAEM, DCEM). Procédé selon la revendication 6, comprenant en outre une répétition dudit traitement de contrôle (CHKPR) pour l’intervalle temporel suivant de ladite séquence, en dépit de la délivrance dudit signal d’erreur (LCLSEM, SAEM, DCEM). Système sur puce, comprenant une structure d’unités de traitement asymétriques doubles, ladite structure d’unités de traitement comportant une première unité de traitement (PCPU) et une seconde unité de traitement (SCPU) ayant, en raison de ladite asymétrie, une structure matérielle différente et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement, ladite structure d’unités de traitement étant configurée pour réaliser le procédé pour la surveillance de l’exécution d’un logiciel d’application (EUAP) mettant en œuvre une fonction de sécurité selon l’une quelconque des revendications précédentes.