FR 3047862 A1 20170818 FR 1651165 A 20160212 1 SYSTEME EMBARQUE ; PROCEDES DE FONCTIONNEMENT ET DE DEPLOIEMENT ASSOCIES La présente invention a pour domaine celui des systèmes embarqués exécutant des applications hétérogènes de contrôle-commande, en particulier les systèmes embarqués à bord d'un véhicule, tel qu'un véhicule ferroviaire. L'invention a également pour domaine celui des procédés de fonctionnement et de déploiement de tels systèmes embarqués. Dans le domaine des systèmes embarqués, la sûreté de fonctionnement, dans sa définition la plus générale, couvre les quatre attributs suivants : fiabilité, disponibilité, maintenabilité et sécurité (connus également par l'acronyme anglais RAMS pour Reliability, Availability, Maintainability and Safety). Concevoir un produit qui répond à un niveau requis de sûreté est difficile et coûteux, car la sûreté doit être évaluée de manière exhaustive compte tenu de la finalité du produit et de ses utilisations, c'est-à-dire de l'application qui sera exécutée par le système embarqué. De manière générale, la mise en oeuvre conjointe de moyens méthodologiques et de moyens techniques permet de répondre aux exigences de sûreté requises. Au cours des dernières années, une préoccupation commune à de nombreux domaines industriels porte sur l'intégration de différentes applications au sein d'un système embarqué unique. Cela correspond en particulier au déploiement, sur la même plateforme matérielle, de plusieurs applications logicielles hétérogènes, c'est-à-dire qui présentent des niveaux de sécurité différents, des fonctionnements indépendants ou dépendants les uns des autres, certaines applications nécessitant des opérations en temps réel ou exigeant des niveaux de disponibilité et / ou de fiabilité différents, etc. De nos jours, la protection contre les défauts aléatoires, et dans une certaine mesure, les défauts systématiques, est obtenue au moyen d'une architecture redondante qui prévoit l'exécution de plusieurs instances de la même application. Un exemple connu d'une telle architectures redondante est l'architecture de sécurité « K parmi N » (aussi dénommées « K out of N » ou KooN) où la fonctionnalité offerte par l'application est valide lorsque au moins K instances sur les N instances exécutées par le système embarqué délivrent des données de sortie cohérentes entre elles. Les différentes instances d'une même application mettent éventuellement en oeuvre une certaine diversification logicielle (différence entre les codes binaires de chaque instance) et / ou matérielle (même code binaire mais exécuté sur des calculateurs 3047862 2 différents), éventuellement combinée, pour des raisons de disponibilité, avec un certain degré de répétition des architectures redondante (noté par exemple M * KooN). La question de la sécurité liée à la cohabitation, sur une même plateforme matérielle, d'applications critiques et d'applications non critiques a été bien étudiée et a 5 conduit aux solutions d'isolation temporelle et spatiale (par exemple le standard ARINC 653 dans l'avionique, les techniques de virtualisation / hyperviseur, etc.) Cependant, la mise à l'échelle du système embarqué exécutant des applications hétérogènes et intégrant des architectures redondantes constitue un problème qui n'a pas encore trouvé de solution générique et à bas coûts. 10 Le but de l'invention est de résoudre ce problème. Pour cela l'invention a pour objet un système embarqué fournissant une fonctionnalité de contrôle / commande critique, caractérisé en ce qu'il comporte : - une couche matérielle comportant une pluralité de calculateurs connectés entre eux par au moins un réseau de communication ; 15 - une couche logicielle comportant : - une pluralité de systèmes d'exploitation temps réel, chaque calculateur exécutant un système d'exploitation ; - un intergiciel distribué ; - au moins une première instance d'une application correspondant à ladite 20 fonctionnalité de contrôle / commande critique, ladite première instance étant exécutée sur un premier calculateur et une second instance de ladite application, ladite seconde instance étant exécutée sur un second calculateur différent du premier calculateur, l'intergiciel fournissant : un service de communication mettant en oeuvre un protocole de 25 communication, dit protocole VSN pour « Virtual Safe Network », permettant l'établissement d'un canal sécurisé et authentifié entre la première instance et la seconde instance pour l'échange de messages de service cryptés entre la première instance et la seconde instance ; un service de vérification d'alignement fonctionnel propre à calculer une 30 signature pour la première instance , respectivement la seconde instance , à partir d'une pluralité de données contextuelles de la première instance , respectivement de la seconde instance , et propre à comparer entre elles les signatures de manière à déterminer si une instance est défaillante ; un service d'isolement d'une instance défaillante parmi les première et 35 seconde instances, identifiée par le service de vérification d'alignement 3047862 3 fonctionnel, en utilisant l'autre instance , considérée comme valide, pour rompre le canal entre les première et seconde instances. Suivant des modes particuliers de réalisation, le procédé comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les 5 combinaisons techniquement possibles : - les composants de la couche matérielle sont des composants qui ne sont pas validés de manière à présenter un taux de défaillance déterminé. - l'intergiciel comporte également un service de réamorçage de la redondance. 10 - le service de vérification d'alignement fonctionnel met en oeuvre un processus de vote entre les données de sortie générées par les première et seconde instances, les données de sortie constituant un type particulier de signature. L'invention a également pour objet un procédé de fonctionnement d'un système embarqué conforme au système précédent, caractérisé en ce qu'il comporte les étapes 15 consistant à établir , lors de l'initialisation du système embarqué , un canal sécurisé et authentifié entre la première instance et la seconde instance d'une même application , pour l'échange de messages de service entre la première instance et la seconde instance ; puis, au cours du fonctionnement du système 20 embarqué, vérifier périodiquement l'alignement fonctionnel entre les première et seconde instances , en calculant une signature pour chaque instance à partir d'une pluralité de données contextuelles relative à l'instance considérée, puis en comparant entre elles les signatures calculées ; et, en cas de désaccord entre 25 les signatures, isoler une instance considérée comme défaillante parmi les première et seconde instances, par rupture, par l'instance valide, du canal vers l'instance défaillante. De préférence, l'étape d'isolement est suivie d'une étape de rétablissement de la 30 redondance requise par l'application , consistant à : - démarrer une nouvelle instance de l'application en redondance de l'instance défaillante isolée et vérifier que la nouvelle instance a démarré correctement et avec un paramétrage approprié ; si l'exécution de la nouvelle instance dépend de données de configuration 35 contextuelles, recopier les données d'une instance active de l'application ; 3047862 4 exécuter la nouvelle instance avec les données d'entrée appliquées également à l'instance active de l'application, et vérifier l'alignement fonctionnel de chaque instance de l'application ; et si aucune divergence n'est détectée pendant une durée prédéterminée, 5 établir un canal sécurisé entre la nouvelle instance et la ou chaque autre instance active de l'application. L'invention a également pour objet un procédé de déploiement d'un système embarqué conforme au système précédent, caractérisé en ce qu'il comporte, pour dimensionner ledit système embarqué les étapes consistant à : 10 - spécifier les caractéristiques non-fonctionnelles de la ou de chaque application à déployer sur le système embarqué ; - choisir , pour chaque application, un patron de déploiement spécifiant pour ladite application un ensemble d'attributs de sûreté de fonctionnement ; - déterminer le nombre d'instances associées à une application devant être 15 exécutées sur le système embarqué à partir des patrons de déploiement choisis pour l'application correspondante ; - dimensionner les besoins calculatoires du système embarqué en fonction des caractéristiques non-fonctionnelles de chaque application et du nombre d'instances déterminé pour chaque application ; 20 - déterminer un plan de déploiement à partir du nombre d'instances de chaque application et des besoins calculatoires ; - dimensionner le réseau de communication, en vérifiant que la charge du réseau est compatible avec le plan de déploiement et, - configurer le système embarqué conformément au plan de déploiement. 25 De préférence, l'étape de configuration du système embarqué comporte : - le chargement de chaque instance de chaque application sur un calculateur associé conformément au plan de déploiement ; et, - l'implémentation des patrons de déploiement associés à chaque application par configuration des services de l'intergiciel réparti de la couche logicielle du système 30 embarqué. L'invention et ses avantages seront mieux compris à la lecture de la description détaillée qui va suivre d'un mode de réalisation particulier, donné uniquement à titre d'exemple non limitatif, cette description étant faite en se référant aux dessins annexés sur lesquels : 35 - La figure 1 est une représentation schématique du système embarqué selon l'invention ; 3047862 5 La figure 2 est une représentation sous forme de blocs d'un procédé de fonctionnement du système embarqué de la figure 1 ; La figure 3 est une représentation sous forme de blocs d'un procédé de déploiement du système embarqué de la figure 1 ; et, 5 Les figures 4 et 5 sont des représentations schématiques d'implémentations possibles de redondance. L'invention permet de résoudre le problème de la mise à l'échelle d'un système embarqué exécutant différentes applications hétérogènes en proposant d'abord un type particulier de système embarqué, qui se caractérise par la présence un intergiciel 10 générique spécifique. Cet intergiciel fournies différents services, qui, au cours du fonctionnement du système embarqué, permettent d'assurer le niveau de sûreté de fonctionnement requis par chaque application. Cet intergiciel autorise la mise en oeuvre d'un procédé de déploiement conduisant, 15 à partir de la spécification des applications devant être exécutées, à la définition d'un système embarqué adapté. La définition du système embarqué final comporte notamment la configuration de l'intergiciel générique pour répondre aux spécifications de niveau de sûreté de fonctionnement requis pas chaque application. En se référant à la figure 1, le système embarqué 10 comporte une couche 20 matérielle 12 et une couche logicielle 13. La couche matérielle 12 est constituée par une grappe de calculateurs composée d'une pluralité de calculateurs Ci, connectés les uns aux autres par deux réseaux, 14 et 15 respectivement. Les deux réseaux, de préférence identiques entre eux, sont standards, par exemple du type Ethernet. Le fait que le système 10 soit muni de moyens 25 de communication redondés offre une plus grande fiabilité du système dans les échanges d'informations entre calculateurs. La pluralité de calculateurs comporte N calculateurs primaires et M calculateurs secondaires. Pour le cas spécifique de la figure 1, le système embarqué 10 comporte N=4 calculateurs primaires, Cl à C4, et M=1 calculateur secondaire, C5. 30 Dans un mode de fonctionnement normal du système 10, les calculateurs primaires supportent l'exécution de l'ensemble des applications du système 10, tandis que les calculateurs secondaires, qui sont des calculateurs de remplacement, sont placés en mode veille, avec un contrôle périodique de leur état de fonctionnement et de leurs moyens de communication. 3047862 6 Lors d'une défaillance d'un des calculateurs primaires, un calculateur secondaire prend le relais et exécute les applications qui étaient auparavant exécutées sur le calculateur primaire défaillant. Le dimensionnement des cardinaux N et M se fait lors des étapes 140 et 150 du 5 procédé de déploiement, en fonction des exigences de sûreté des applications à déployer, comme cela sera décrit en détail ci-dessous. Chaque calculateur Ci est un ordinateur comportant un moyen de calcul, tel qu'un processeur, un moyen de mémorisation, tel qu'une mémoire, et une interface d'entrée/sortie, telle qu'une première carte réseau pour l'échange de messages de 10 données sur le premier réseau 14 et une seconde carte réseau pour l'échange de messages de données sur le second réseau 15. Chaque calculateur Ci comporte également un module d'alimentation propre. Les calculateurs Ci sont avantageusement identiques entre eux pour diminuer les coûts de déploiement et de maintenance du système 10. 15 Les composants de la couche matérielle 12, calculateurs et réseaux, sont des composants pris sur étagère ou composants COIS (« commercial off-the-shelf »). Ces composants COIS présentent de fait la caractéristique de ne pas être qualifiés en termes de niveau de sûreté de fonctionnement. C'est-à-dire que la couche matérielle du système embarqué n'utilise pas nécessairement des composants spécifiques ou des cartes 20 électroniques validées de manière à présenter un taux de défaillance déterminé. Bien évidemment, ces composants sont choisis en fonction de certaines caractéristiques, telles que par exemple MPU/MMU (« Memory Protection Unit / Memory Management Unit »), processeur multi-cceurs ou pas, interfaces réseaux, etc. pour offrir une capacité d'exécution déterminée, utilisée comme paramètre dans le procédé de 25 déploiement. Le système 10 est destiné à communiquer avec des systèmes embarqués équipant le véhicule ferroviaire, tels que le système de freinage, le système d'affichage en cabine, le système de gestion de la climatisation, etc. La couche matérielle 13 du système 10 comporte une couche logicielle bas niveau 30 22, qui, pour chaque calculateur Ci, est constituée d'un système d'exploitation 24 et d'un intergiciel 26. Le système d'exploitation 24, identique d'un calculateur Ci à l'autre, est un système d'exploitation temps réel du commerce, au sens où il n'est pas validé pour présenter un taux de défaillance déterminé. Il offre des services d'ordonnancement 35 temporel de l'exécution des processus des applications logicielles exécutées sur le calculateur qu'il équipe, ainsi qu'une isolation spatiale des zones mémoire accessibles par 3047862 7 chaque application logicielle exécutée. Ainsi, le système d'exploitation assure un service d'isolation spatiale et temporelle des différentes applications exécutées sur chaque calculateur. L'intergiciel 26 est générique. Il offre un certain nombre de services qui sont 5 configurés au moment du déploiement du système 10. Ces services permettent de réaliser la politique de sûreté choisie pour chaque application du système 10, comme cela sera présenté en détails ci-dessous. Le système 10 comporte une couche logicielle haut niveau 23 qui comporte une pluralité d'applications, référencées Al à A6 sur la figure 1. 10 Une application est ici une fonctionnalité particulière fournie par le système 10. Chaque application, implémentée sur le système embarqué 10, est une application ferroviaires du type de contrôle / commande. De manière générale, la présente invention n'adresse pas le cas de l'intégration de capteurs, d'actuateurs ou de passerelle, mais porte exclusivement sur le déploiement d'applications de contrôle / commande, de 15 surveillance, de maintenance, de supervision ou tout autre type d'applications industrielles embarquées. Chaque application est associée à une politique de sûreté. Suivant la politique de sûreté choisie pour une application, une ou plusieurs instances de cette application sont exécutées sur le système 10. Chaque instance d'une 20 même application est exécutée sur un calculateur différent. Par exemple, sur la figure 1, l'application Al devant respecter un niveau de sûreté élevé, trois instances de cette application sont exécutées dans le système 10 : le calculateur Cl exécute une première instance A1.1 de l'application A1, le calculateur C2 exécute une seconde instance A1.2 de l'application A1, et le calculateur C3 exécute une 25 troisième instance A1.3 de l'application Al. En revanche, l'application A6 ne devant pas être exécutée en sécurité, une seule instance A6.4 de l'application A6 est exécutée dans le système 10, en l'occurrence par le calculateur C4. Une instance d'une application peut être similaire à une autre instance de cette même application, mais un principe de diversification est souvent employé de sorte 30 qu'une instance diffère souvent d'une autre instance de la même application. Cette diversification peut provenir de manières différentes d'écrire le code source de chaque instance de l'application, de manières différentes de compiler un même code source pour obtenir des exécutables différents, etc. 3047862 8 La politique de sûreté demandée par une application particulière déployée sur la plateforme10 correspond au niveau de sécurité et au niveau de disponibilité nécessaires à la fonctionnalité résultant de la mise en oeuvre de cette application. De manière générale par niveau de disponibilité, on entend la capacité d'une 5 application à être fonctionnelle à un instant donné. L'accroissement de la disponibilité d'une application est alors obtenu par l'augmentation du nombre des instances de cette application. Le niveau de sécurité ou tolérance aux pannes, c'est-à-dire la capacité d'une application à rester fonctionnelle alors que certains composants, logiciel ou matériel, du 10 système 10 sont défaillants, demande, en cas de défaillance partielle, le respect des prescriptions fondamentales suivantes : Préserver la consistance des données, les éventuelles données erronées découlant de la panne sont détectées et traitées ; Éviter que des messages de contrôle / commande erronés soient transmis au 15 système contrôlé, les composants défaillants ne devant pas générer de messages valides ; Empêcher les composants défaillants de dégrader le fonctionnement du système (« déni de service »), afin de maintenir la performance opérationnelle. La complexité des composants matériels et logiciels mis en oeuvre ne permet pas 20 d'assurer, en sécurité, qu'un calculateur défaillant assumera automatiquement une condition restrictive. Par conséquent, le système embarqué selon l'invention met en oeuvre une stratégie de protection efficace qui repose sur les composants, logiciels et matériels, valides du système. Ce sont donc les composants valides qui portent la capacité de défendre tout dégât potentiel induit par un composant défaillant. 25 Patrons de déploiement Une politique de sûreté associée à une application est assurée par l'utilisation d'un ou plusieurs patrons de déploiement associés à cette application. Dit autrement, la politique de sûreté d'une application est définie par le choix d'un ou plusieurs patrons de 30 déploiement. De préférence, le choix d'un patron est effectué par sélection dans une bibliothèque de patrons prédéfinis. Un patron de déploiement est défini par la donnée de valeurs spécifiques pour un ensemble d'attributs de sûreté de fonctionnement. La notion de patron se rapporte 35 explicitement au concept d' « Architectural pattern » connu de l'homme du métier et par exemple illustré par le document disponible en ligne à l'adresse : 3047862 9 http://pubs.openg roup.org/architecture/tog af 8-doc/arch/ch ap28.htm I. De manière schématique, un patron de déploiement définit le nombre d'instances d'une application qu'il est nécessaire d'exécuter sur le système embarqué afin d'atteindre le niveau de sécurité et de disponibilité requis par la politique de sûreté associée à 5 l'application considérée. Le patron de déploiement définit également la manière de configurer les services de l'intergiciel 26 de chaque calculateur exécutant une instance de cette application pour réaliser la politique de sûreté associée. Dans ce qui suit, des exemples de patrons de déploiement sont donnés : - Un patron « Sécurité en configuration 2002 », propose la détection et la 10 protection d'erreurs aléatoires (et systématiques suivant le niveau de diversification logicielle entre les instances) en se basant sur une configuration 2002 comportant deux instances de l'application, ces deux instances actives devant être en alignement fonctionnel à chaque instant pour garantir la validité de la fonctionnalité correspondante. - Un patron « Sécurité en configuration 2003 » est un patron de sécurité alternatif 15 au précédent se basant sur une configuration 2003, comportant trois instances de l'application, au moins deux instances parmi les trois instances actives devant être en alignement fonctionnel à chaque instant pour garantir la validité de la fonctionnalité correspondante. - Un patron « Redondance à chaud » propose une configuration classique maître / 20 esclave basée sur une configuration 1ooL, une instance active étant choisie comme maître et les L-1 autres instances étant choisies comme esclave, la défaillance de l'instance maître conduisant à son isolement et à son remplacement par l'une des instances esclaves promue instance maître. Par redondance à chaud, il faut entendre, après la détection de la défaillance 25 d'une instance d'une application, la possibilité de configurer une autre instance déjà en cours d'exécution de manière à ce que cette autre instance vienne se substituer à l'instance défaillante. - Un patron « Réamorçage contextuel à chaud » propose le rétablissement de la redondance suite à la défaillance d'une instance de l'application ou à une action de 30 maintenance sur le système sans perte de performance globale. - Un patron « Redondance à froid» propose une redondance à froid avec, éventuellement, la capacité de pouvoir choisir parmi les instances valides sur les calculateurs primaires celle dont les données contextuelles dynamiques et les données de configuration statique vont être reprises pour l'activation de la nouvelle instance exécutée 35 sur le calculateur secondaire. 3047862 10 Par redondance à froid, il faut entendre, après la détection de la défaillance d'une instance d'une application, l'exécution d'une nouvelle instance de cette application, cette nouvelle instance venant se substituer à l'instance défaillante. Dans le système embarqué selon l'invention, les calculateurs secondaires sont dédiés aux instances permettant une 5 redondance à froid d'une application. Chaque application fournie par le système peut relever de plusieurs patrons. La composition de patrons permet d'optimiser plusieurs attributs de la sûreté de fonctionnement de cette application. Par exemple, une application critique avec des contraintes de disponibilité fortes peut être déployée avec la combinaison des 10 patrons « Sécurité en configuration 2002 » (soit deux instances de l'application), « Redondance à chaud » en mode 1002 (soit deux instances de l'application pour chaque instance de la configuration 2002), et « Redondance à froid» (soit une instance de l'application). Par exemple, le système 10 de la figure 1 a été configuré pour fournir les 15 applications hétérogènes suivantes, spécifiques du domaine ferroviaire : Al - ATP (système de protection) : cette application demande un haut niveau de disponibilité et de sécurité, elle utilise un patron « Sécurité en configuration 2003 » classique ; A2, A3 et A5 - ATO (système de conduite automatique), « Driver interface » 20 (console d'interface conducteur) et « Passenger announcement » (système d'annonces sonores aux voyageurs) : ces applications à haut niveau de disponibilité sont déployées avec un patron « redondance à froid » (en mode 1002) ; et, A4 et A6 - HVAC management (gestion de ventilation et climatisation) et 25 « Passenger information » (système d'information voyageurs) : ces applications sont déployées sans contraintes particulières, elles sont déployées avec un patron par défaut, chacune sur un unique calculateur (1001). Ainsi, par exemple, conformément à la politique de sûreté associée à l'application 30 A1, le système 10 comportera trois instances de l'application Al exécutées simultanément sur autant de calculateurs primaires. L'intergiciel 26 de chacun des calculateurs C1, C2 et C3 sera configuré pour mettre à disposition de l'instance correspondante, un service de synchronisation des différentes instances, un service de vote (ou plus généralement d'alignement des 35 données contextuelles dynamique des différentes instances), un service d'auto-test local (de vérification par une instance du maintien de ses données statiques de configuration 3047862 11 d'un cycle à l'autre) et un service de communication VSN (permettant l'isolement d'une instance défaillante). L'intergiciel 5 Les patrons de déploiement permettent la configuration des services de l'intergiciel 26 lors de la mise en oeuvre du procédé de déploiement. L'intergiciel 26 (ou « middleware » en anglais), distribué sur chaque calculateur Ci du système 10, fournis les services nécessaires à la gestion de la sécurité (spécifique au domaine d'application, ferroviaire par exemple) et à la gestion de la redondance. 10 Il offre des services génériques, qui sont répliqués sur chaque calculateur, tels que : Service de communication VSN : ce service supervise les moyens de communication du calculateur et réalise la gestion de clefs cryptographiques pour chaque canal VSN Ce service assure l'isolement d'une instance 15 défaillante (locale ou distante) en supprimant la clef cryptographique associée. L'information de défaillance est donnée par les services d'alignement, de synchronisation et d'auto-test décrits ci-dessous. Service entrées/Sorties : ce service implante la partie applicative de la pile de communication réseau de l'intergiciel exécuté sur un calculateur. Ce service 20 permet de synchroniser la mise à disposition des entrées sur N instances applicatives distribuées. Il implémente la stratégie de construction des sorties de contrôle commande selon le principe approprié (i.e. chaque partie prenante fournit une partie du message, l'ensemble est consolidé par une instance). Il vérifie les codes CRC permettant de détecter des erreurs dans la partie 25 fonctionnelle des messages en entrée et, de manière symétrique, calcule les CRC nécessaires pour la protection des messages en sortie. Le flux de messages issu de ce service est le cas échant (i.e. flux de messages critiques) véhiculé par le service de communication VSN. Service de synchronisation : service nécessaire pour toute application cyclique 30 et redondée par l'existence d'au moins deux instances. Ce service garantit l'alignement temporel des instances de l'application et apporte optionnellement des informations fonctionnelles supplémentaires. Il s'appuie directement sur le réseau. Il peut être optionnellement utilisé pour maintenir les horloges des calculateurs synchronisées avec celle d'une horloge maître (signal d'horloge 35 extérieur au système 10 ou calculateur de la grappe considéré comme calculateur maître). 3047862 12 Service de vérification d'alignement : ce service permet de vérifier l'alignement fonctionnel des différentes instances de la même application réparties sur plusieurs calculateurs. Au niveau de chaque calculateur, ce service calcule une signature de l'instance exécutée sur ce calculateur en se basant sur un 5 échantillon des données contextuelles de cette instance, transmet la signature calculée vers les autres instances et reçoit les signatures des autres instances de la même application, compare les signatures reçues avec la signature calculée, et émet un message de détection de défaillance lorsque l'issue de cette comparaison est négative, ce message étant de nature à basculer l'état 10 d'au moins une des instances dont les signatures sont comparées de la valeur valide à la valeur défaillante. Parmi les différents types de vérifications qui peuvent être faites, on peut citer la comparaison des vecteurs de sortie entre différentes instances actives d'une application. Service de gestion maître-esclave : ce service permet d'élire l'instance 15 « maître » dans un contexte de redondance du type maître / esclave, c'est-à- dire de définir le statut d'une instance. Ce service couvre les phases d'initialisation du système et de reconfiguration au cours du fonctionnement du système (choix du nouveau maître suite à un défaut du maitre précédent). Service d'entrainement : ce service permet la transmission des données 20 contextuelles d'une instance valide vers une nouvelle instance, à des fins de réamorcer à chaud la nouvelle instance. Service de maintenance : ce service permet de stocker et remonter le diagnostic de panne aux équipes de maintenance pour une intervention dans les meilleurs délais. 25 - Service d'auto-test : ce service permet de vérifier l'état de la carte du calculateur et de détecter des défauts matériels. Ce service va par exemple tester périodiquement l'état de la mémoire RAM. Il permet aussi de vérifier périodiquement que des données statiques et de configuration ne divergent pas en comparant une signature calculée à l'instant courant et une signature 30 calculée hors ligne. Il permet encore de vérifier l'état du microcontrôleur présent sur la carte et réalisant des tests basiques (stimulation/vérification). La détection d'un défaut fait basculer la chaine à l'état défaillant. L'exécution effective des autotests, leur résultat font partis des données échangées pour une vérification d'état au même titre que l'alignement des instances. 35 Ainsi, l'intergiciel 26 fournit aux calculateurs Ci des services permettant de mettre en oeuvre des mécanismes d'auto-test locaux et des mécanismes de vérification 3047862 13 d'alignement distribués. Cette combinaison permet d'atteindre un niveau de détection de défaillance élevé. Service VSN 5 La communication de messages de services entre les services ainsi configurés de l'intergiciel 26 et associés à une instance permet de réaliser la synchronisation entre les différentes instances d'une application, de surveiller la cohérence des différentes instances entre elles, et d'isoler une instance défaillante. Pour ces communications de services, l'intergiciel 26 repose sur l'utilisation d'un 10 protocole de communication spécifique, dénommé protocole VSN (selon l'acronyme « Virtual Safe Network »), entre les instances d'une même application. Les instances d'une même application étant exécutées sur des calculateurs différents, la communication entre deux instances s'effectue via l'un et/ou l'autre des réseaux 14, 15. Le protocole VSN peut être vu comme un canal de communication spécifique, dénommé canal VSN, sur ces 15 réseaux entre un premier service de communication VSN exécuté sur un premier calculateur et un second service de communication VSN exécuté sur un second calculateur, le premier service étant associé à une première instance de l'application et le second service étant associé à une seconde instance de cette application. Le protocole VSN a pour but d'offrir : 20 Un mécanisme de cryptage pour établir un canal de communication sécurisé et authentifié entre deux instances d'une même application de haute criticité, chaque instance étant exécutée sur un calculateur différent. un mécanisme d'exclusion à distance d'une instance défaillante à des fins d'isolation fonctionnelle. 25 Un mécanisme de préservation de la qualité de service pour une protection contre d'éventuelles atteintes qu'une instance défaillante ou plus généralement un composant défaillant pourrait infliger au système (cas du « flooding » par exemple). Pour cela le protocole VSN s'appuie uniquement sur des composants standards 30 de routage et des algorithmes de cryptage classiques. - Le mécanisme de cryptage Les messages de service entre instances sont cryptés, ce qui permet des échanges confidentiels « un à un » entre deux instances quelconques d'une même 35 application. 3047862 14 Après démarrage du système 10, au cours d'une phase d'initialisation du système 10, chaque service de communication VSN associé à une instance d'une application détermine un ensemble de clés de chiffrage pour communiquer avec chacun des autres services de communication VSN associés aux autres instances de la même application 5 exécutées sur d'autres calculateurs. A cet effet, est par exemple utilisé un procédé de génération de clés de type DiffieHeliman permettant d'établir et de partager de manière confidentielle une clef symétrique entre deux services de communication VSN sans intervention administrative et sans échange préalable de clés. Ainsi, à l'issue de l'initialisation, chaque service de 10 communication possède un tableau contenant un ensemble de clefs de chiffrage spécifique. Au cours du fonctionnement du système 10, le remplacement ou l'ajout d'une nouvelle instance d'une application nécessite l'enregistrement de cette nouvelle instance auprès des autres instances de la même application et l'ouverture d'un ou plusieurs 15 canaux VSN pour pouvoir établir des communications sécuritaires avec ces autres instances. Cela implique des phases successives d'entrainement, d'observation et de génération de nouvelles clés. - Le mécanisme d'exclusion 20 Le protocole VSN fournit également un mécanisme d'exclusion dynamique. Pour isoler une instance défaillante, il est suffisant que les autres instances de la grappe de calculateurs effacent leur clé de chiffrage partagée avec cette instance défaillante. L'instance ainsi isolée ne sera plus en mesure de recevoir aucun message de service et, si elle émet des messages de service, ces derniers ne seront pas exploitables par les 25 services de communication associés aux instances valides. Dans ce cas, l'instance isolée n'a plus la possibilité de participer à la production des messages de contrôle / commande sécuritaires. En effet, afin de construire ce type de message, le service de production de données de sortie a besoin des signatures issues des instances formant la structure 2002 ou 2003 active. Toute instance exclue via 30 le service de communication VSN voit ces messages de service illisibles et par conséquent ignorés par les autres instances et, de manière symétrique, toute instance valide est dans l'incapacité d'envoyer des messages de service vers cette instance isolée. Elle est virtuellement exclue du sous-groupe des calculateurs fournissant l'application critique. Supposons N instances d'une application critique utilisant deux-à-deux le service 35 de communication VSN, le processus d'exclusion se décline comme suit : 3047862 15 1. à l'issue d'une phase de vérification d'alignement, de vote, de BIST ou de synchronisation, une divergence de données ou de fonctionnement ou temporelle est détectée sur une des instances. 2. Sur les N-1 instances valides, le service ayant détecté la défaillance associe 5 localement l'instance distante à un état défaillant. Cela a pour effet, au niveau du service de communication VSN, de supprimer localement la clef symétrique utilisée pour communiquer avec l'instance en question. 3. Le canal de communication crypté entre les N-1 instances et l'instance défaillante n'est plus disponible. Le seul moyen de le remettre en oeuvre est de passer les 10 phases d'entrainement, d'observation et de réadmission dans le mécanisme VSN. - Le mécanisme de préservation de la qualité de service Le service VSN fournit également un mécanisme de restriction du trafic sur le ou chaque réseau, qui est nécessaire pour se prémunir contre un éventuel déni de service, 15 par exemple due à une surgénération de messages par un composant défaillant. En effet, un calculateur défaillant, une instance déficiente, voire une attaque informatique extérieure peuvent entraîner des congestions qui dégradent la qualité de service du réseau. Le déterminisme des flux vitaux de communication entre calculateurs s'appuie sur la réservation de bande passante au niveau des canaux virtuels de communication 20 associés à chaque calculateur. En fixant des règles de filtrage et en plafonnant le débit par canal virtuel, les commutateurs de routage assurent la qualité de service des flux vitaux, même en conditions de défaillance ou d'attaque informatique. Les patrons de déploiement définissent des allocations de bande passante et de cadencement des messages entre calculateurs, afin d'assurer le déterminisme et la 25 prédictibilité nécessaire aux échanges critiques entre instances d'une application et / ou dispositif contrôlé (synchronisation, commandes en temps réel, etc.) Ces allocations sont utilisées au cours du procédé de déploiement du système pour le paramétrage des mécanismes de protection et de filtrage mis en oeuvre par les commutateurs du réseau. Les patrons de déploiement permettent ainsi de définir une stratégie de qualité de service 30 des ressources réseaux, qui offre une garantie sur les délais de transmission et sur la bande passante disponible le long des canaux virtuels ouverts. Les mécanismes de protection et de filtrage s'appuient sur les stratégies mises en oeuvre par des commutateurs réseaux classiques : - par le contrôle des différents types de trafic entrant ou sortant des interfaces, sur 35 la base des respectifs adresses IP d'origine ou destination, d'un ordre de priorité IP, des adresse MAC et d'autres attributs des trames relayées. 3047862 16 - par la limitation de débit, permettant de plafonner (voire bloquer) à la volé la transmission de trames à partir de critères de conformité basés sur des taux moyens et ponctuels de débit par interface. L'intergiciel offre aussi une stratégie de segmentation en plages temporelles périodique, 5 avec des plages affectées exclusivement aux communications vitales (synchronisation, alignement, vote) et d'autres plages où les applications non-critiques peuvent échanger librement. Cette fonctionnalité s'appuie sur la synchronisation des horloges des calculateurs, elle permet d'assurer le déterminisme des échanges vitaux, puisqu'ils profitent, lors des plages dédiées, de toute la capacité du réseau. 10 Processus de fonctionnement En référence à la figure 2, un processus de fonctionnement 200 du système embarqué 10 va être donné. 15 A l'tape 210, lors de l'initialisation du système embarqué 10, un canal sécurisé et authentifié est établi entre, par exemple, la première instance A1.1 et la seconde instance A1.2 de l'application A1, pour l'échange de messages de service entre la première instance et la seconde instance. Puis, au cours du fonctionnement du système embarqué 10, une étape 220 de 20 vérification est réalisée périodiquement pour vérifier l'alignement fonctionnel entre les première et seconde instances, A1.1 et A1.2, en calculant une signature pour chaque instance à partir de données contextuelles relatives à l'instance considérée, puis en comparant entre elles les signatures calculées. L'étape 220 peut également mettre en oeuvre le service d'auto-test pour chaque 25 instance de l'application individuellement. Processus de protection en cas de détection de panne Lors de la détection d'une défaillance affectant une instance d'une application, l'intergiciel 26 exécute le processus de protection 230 suivant : 30 Isoler l'instance défaillante, en utilisant les instances valides (auxquelles on peut faire confiance), par exemple en empêchant l'émission de messages de services erronés par une instance défaillante vers les autres calculateurs et/ou vers le dispositif contrôlé ; préserver la qualité de service, en évitant qu'elle soit altérée par l'instance 35 défaillante, par exemple en prévenant toute saturation du réseau qui serait 3047862 17 occasionnée par l'émission incontrôlée de messages (« flooding ») par une instance défaillante ; Stocker et remonter le diagnostic de panne aux équipes de maintenance pour une intervention dans les meilleurs délais. 5 Processus de rétablissement de la redondance Puis un processus de rétablissement de la redondance 235 est exécuté. L'augmentation de la fiabilité de l'exécution d'une application peut être obtenue par des patrons de « redondance à chaud ». Suite à la perte d'un calculateur qui exécute une 10 instance redondée, le réamorçage des applications est possible afin de rétablir le niveau de disponibilité original, et cela sans obligation de redémarrer l'ensemble du système. L'augmentation de la fiabilité de l'exécution d'une application peut également être obtenue par des patrons de « redondance à froid » utilisant un calculateur secondaire de rechange. L'intergiciel 26 surveille la cohérence entre les instances d'une application à 15 haute disponibilité et, en cas de défaillance d'une instance, si une redondance « à froid » a été prévue dans le patron de déploiement de l'application correspondante, l'intergiciel lance l'exécution d'une nouvelle instance de l'application sur un calculateur secondaire. Le rétablissement de la redondance, à chaud ou à froid, ainsi que, plus généralement, les évènements de types réinitialisation programmée d'un calculateur, 20 problème d'alimentation, remplacement d'un composant, ... déclenchent les actions suivantes, réalisées automatiquement : démarrer une nouvelle instance de l'application en redondance de l'instance défaillante isolée et vérifier (étape 240) que la nouvelle instance a démarrée correctement et avec le paramétrage approprié. 25 Si l'exécution de la nouvelle instance dépend de données de configuration et contextuelles, recopier (étape 250) ces données d'une instance active de l'application : ce processus d'amorçage de la nouvelle instance est géré automatiquement par l'intergiciel sans perturbation de l'exécution de l'instance active dont les données contextuelles sont reprises ; 30 Une fois la contextualisation accomplie, exécuter (étape 260) la nouvelle instance sur données utilisées en entrée des instances valides, mais, aucun canal VSN n'est encore octroyé à cette nouvelle instance, de sorte qu'elle ne peut pas émettre des messages de service ou de contrôle / commande valides. Pendant cette période de carence, de durée paramétrable, l'intergiciel 35 vérifie l'alignement fonctionnel vis-à-vis de ou de chaque instance active et 3047862 18 valide. Si aucune divergence n'est détectée pendant cette phase, la conformité de la nouvelle instance est certifiée. Après que la nouvelle instance a été certifiée, établir (étape 270) un ou plusieurs canaux VSN en générant de nouvelles clés afin que la nouvelle 5 instance puisse établir des communications sécuritaires avec les autres instances de l'application et les dispositifs contrôlés. Incidemment, la redondance d'une application sécuritaire est généralement traitée, dans l'état de l'art, par des solutions de type 2*2002 ou 2003. Dans une architecture 2*2002 classique représentée sur la figure 3, une chaîne 10 maître 2002 50 (constituée d'une première instance A.1 de l'application A exécutée sur un premier calculateur Cl et une seconde instance A.2 exécutée sur un second calculateur C2) est redondée à chaud (aussi dénommée redondance active) par une deuxième chaîne 2002 60 (constituée d'une troisième instance A.3 de l'application A exécutée sur un troisième calculateur C3 et une quatrième instance A.4 exécutée sur un quatrième 15 calculateur C4). Si la chaîne maître 50 présente une défaillance (vote de cohérence négatif entre les données de sortie des deux instances composant la chaine), elle est neutralisée et la chaîne esclave 60 prend le contrôle. Cependant, la chaîne intégrant deux calculateurs, la défaillance du premier calculateur Cl entraîne la neutralisation de la chaîne 50 et par conséquent la désactivation du second calculateur C2. Si cette stratégie 20 assure la suppression de la chaîne 50 défaillante, elle présente le désavantage d'induire la perte d'un calculateur valide, en l'occurrence le calculateur C2. La présente invention, notamment par l'utilisation du protocole de communication VSN, permet d'envisager une nouvelle composition de redondance et sécurité, qui évite l'exclusion d'un calculateur sain. C'est ce qui est représenté sur la figure 4. 25 Premièrement, de manière classique, le patron de sécurité 2002 s'appuie sur l'exécution coordonnée de deux instances diversifiées de l'application A et B, identifiées comme A.1 sur le premier calculateur Cl et A.3 sur le troisième calculateur C3 et comme B.2 sur le deuxième calculateur C2 et B.4 sur le quatrième calculateur C4. Un patron de redondance 1 ooK est appliqué séparément pour les instances A de 30 l'application et pour les instances B de l'application. Les vérifications d'alignement sont effectués deux-à-deux d'une part sur les K instances A de l'application et d'autre part sur les K instances B de l'application. Dans cette configuration à double 1 ooK diversifiée, la divergence ou la panne d'une des instances (active ou non) est détectée au travers des auto-tests et/ou des vérifications d'alignement. Le calculateur défaillant est exclu grâce 35 aux mécanismes du protocole VSN et la stratégie 1 ooK assure le relais si nécessaire, par 3047862 19 exemple en basculant une instance non active en instance active pour remplacer l'instance défaillante. Ainsi, sur l'exemple de La Figure 4, lors de la défaillance de l'instance A.1, la chaîne 2002 70 est définie dynamiquement par le couple A.3 esclave et B.2 maître. En 5 cas de défaillance de l'instance Al et d'exclusion du premier calculateur Cl, l'instance A2 exécutée par le troisième calculateur C3 prend le relai. A la différence du cas classique, cette action n'invalide pas le calculateur C2. Évaluation de la résistance aux pannes 10 D'un point de vu matériel, trois types de composants sont identifiées dans le système : les moyens de calcul (calculateurs), les moyens de communication (réseau) et les moyens d'alimentation électrique. L'évaluation de la résistance aux pannes de cette invention n'aborde pas les moyens d'alimentation électrique - dont les dispositions à haute disponibilité sont bien 15 connues. Elle se focalise donc sur les moyens de calcul et de communication. Le cas de la défaillance d'une ressource de communication va maintenant être étudié. Le système s'appuie sur deux réseaux indépendants, qui, chacun, pourvoit à la totalité des besoins en communication de la grappe de calculateurs. Si l'un des réseaux devient inutilisable, le trafic est véhiculé par l'autre réseau, sans compromettre ni la 20 sécurité, ni les performances du système. De même, si le port de communication d'un calculateur tombe en panne, le calculateur compromis continuera à communiquer par son deuxième port sur l'autre réseau sans impact sur la performance du système. Le cas de la défaillance d'une ressource de calcul va maintenant être étudié. Le protocole VSN protège le système des menaces potentielles d'un calculateur 25 défaillant par l'isolation de la ressource défaillante et par une protection contre d'éventuelles saturations du canal de communication. Procédé de déploiement La mise en oeuvre du procédé 100 représenté à la figure 2 permet le déploiement 30 d'un système embarqué spécifique, tel que le système 10 de la figure 1. Par déploiement, on entend l'ensemble des étapes qui, à partir des spécifications des différentes applications devant être fournies par le système embarqué, permettent de dimensionner la couche matérielle et configurer la couche logicielle de la grappe de calculateurs, pour que le système obtenu soit effectivement apte à exécuter ces 35 applications conformément aux spécifications, en particulier conformément au niveau de sûreté requis pour chaque application. 3047862 20 Plus précisément, le processus de dimensionnement 100 comporte les étapes suivantes. Dans une étape 105 de sélection de matériel, la catégorie de chaque composant matériel pouvant être utilisé pour constituer le système embarqué est définie et les 5 caractéristiques fonctionnelles correspondantes évaluées. Dans une étape 110 de spécification, sont spécifiés l'ensemble des applications à déployer sur le système embarqué, chaque application ayant ses propres caractéristiques en termes non-fonctionnels (sûreté « RAMS », taille mémoire nécessaire à l'exécution d'une instance, temps de cycle, temps maximum d'exécution d'un cycle, etc.) 10 Dans une étape 120 d'association, un ou plusieurs patrons de déploiement sont choisis pour chaque application en fonction des caractéristiques non-fonctionnelles de sûreté « RAMS ». Les patrons de déploiement sont avantageusement sélectionnés depuis une bibliothèque comportant des patrons prédéfinis. Dans une étape 130 de dimensionnement des besoins calculatoires, les 15 caractéristiques non-fonctionnelles des applications sont mises à jour en prenant en compte l'impact des patrons de déploiement, qui spécifient en effet le nombre d'instances d'une application qu'il est nécessaire de déployer pour respecter la politique de sûreté associée à cette application. Dans une première étape 140 d'évaluation, le nombre N de calculateurs primaires 20 nécessaires est déterminé en fonction de différents critères, tels que : Une métrique permettant d'estimer le taux d'utilisation d'un processeur d'un calculateur par une instance d'une application, comme par exemple le rapport du temps maximum d'exécution d'un cycle sur temps de cycle de cette instance ; 25 - Une empreinte mémoire (RAM, Flash, file system,...) ; - La borne inférieure de N est imposée par l'application ayant la redondance à chaud maximale. Cette première étape d'évaluation peut par exemple mettre en oeuvre un algorithme d'optimisation permettant de répondre à des problèmes d'affectation. S'ils 30 existent des contraintes sur la non co-localisation de deux applications sur un même calculateur, alors une version quadratique du problème d'affectation pourra être utilisée. Un plan de déploiement est obtenu. A ce stade, il comporte N calculateurs primaires et les instances des applications réparties sur les différents calculateurs primaires. Dans une seconde étape d'évaluation 150, le nombre Q de calculateurs 35 secondaires de remplacement est déterminé. La présence de calculateurs de remplacement dépend de l'utilisation ou non de patron de redondance à froid. Le plan de 3047862 21 déploiement est complété avec les Q calculateurs secondaires et les instances des applications réparties sur les différents calculateurs secondaires. Dans une étape 160 de dimensionnement du réseau, le taux d'occupation du réseau est calculé afin de s'assurer de la faisabilité d'un déploiement applications étant 5 réparties de manière précise sur chaque calculateur, en vérifiant que la charge réseau est compatible avec les critères de qualité indiqués dans les patrons choisis. Une fonction permet de déterminer, à partir des allocations de bande passante indiquées dans les patrons choisis, une borne minimale et maximale de la bande passante requise, à laquelle est ajoutée une bande passante propre à chaque application. Le choix du niveau de 10 redondance R du réseau de communication est un élément de la stratégie de disponibilité. Le plan de déploiement est complété par le nombre R de réseaux. Dans une dernière étape 170 de configuration, N calculateurs primaires et Q calculateurs secondaires sont connectés par R réseaux pour former la grappe de calculateur, un système d'exploitation 24 et un intergiciel 26 sont déployés sur la grappe 15 de calculateur, et les instances des applications sont chargées sur chaque calculateur conformément au plan de déploiement. Les instances des applications attribuées à chaque calculateur sont configurées pour leur exécution et les patrons associés sont implémentés par la configuration de l'intergiciel. Un patron est un assemblage prédéterminé et paramétrable de services. Par 20 exemple, le patron dédié à la sécurité assemble le service de synchronisation, d'alignement, de communication VSN, vote des sorties et autotest, les paramètres de configuration seront le cadencement du service de synchronisation, les plages des données contextuelles dont l'alignement doit être vérifié et la cadence à laquelle elles doivent l'être, l'identification des sorties calculées par l'application qui nécessite un vote, 25 les zones de mémoire devant être testées, etc... Ces éléments de configuration sont capturés dans un fichier XML. Celui-ci est téléchargé sur le système de manière à être accessible par l'intergiciel de chaque calculateur. L'intergiciel d'un calculateur interprète ensuite le contenu de ce fichier XML en termes de valeur de configuration des codes logiciels des différents services. 30 Le système embarqué peut alors être démarré. Après une phase d'initialisation, les applications sont exécutées pour fournir, en sécurité, les fonctionnalités correspondantes. L'homme du métier constatera que la solution proposée fournit une solution pour la maîtrise des coûts, tout en améliorant la disponibilité, la fiabilité et la maintenabilité 35 sans compromettre la sécurité. 3047862 22 En effet, elle est basée sur des composants COIS et n'impose pas de couche matérielle particulière, mais donne les moyens de déployer un système adapté au besoin définis par les patrons de déploiement. Ces patrons permettent d'associer des politiques différentes à chacune des applications exécutées. 5 Elle permet d'isoler un calculateur ou une instance divergent ou défaillant de manière logicielle sans remettre en cause le fonctionnement des autres composants valides. 10 REVENDICATIONS1.- Système embarqué (10) fournissant une fonctionnalité de contrôle / commande critique, caractérisé en ce qu'il comporte : - une couche matérielle (12) comportant une pluralité de calculateurs (Ci) connectés entre eux par au moins un réseau de communication (14, 15) ; - une couche logicielle (13) comportant : - une pluralité de systèmes d'exploitation (24) temps réel, chaque calculateur exécutant un système d'exploitation ; - un intergiciel (26) distribué ; - au moins une première instance (A1.1) d'une application (A1) correspondant à ladite fonctionnalité de contrôle / commande critique, ladite première instance (A1.1) étant exécutée sur un premier calculateur (C1) et une second instance (A1.2) de ladite application, ladite seconde instance (A1.2) étant exécutée sur un second calculateur (C2) différent du premier calculateur, l'intergiciel fournissant : - un service de communication mettant en oeuvre un protocole de communication, dit protocole VSN pour « Virtual Safe Network », permettant l'établissement d'un canal sécurisé et authentifié entre la première instance (A1.1) et la seconde instance (A1.2) pour l'échange de messages de service cryptés entre la première instance et la seconde instance ; - un service de vérification d'alignement fonctionnel propre à calculer une signature pour la première instance (A1.1), respectivement la seconde instance (A1.2), à partir d'une pluralité de données contextuelles de la première instance (A1.1), respectivement de la seconde instance (A1.2), et propre à comparer entre elles les signatures de manière à déterminer si une instance est défaillante ; - un service d'isolement d'une instance défaillante parmi les première et seconde instances, identifiée par le service de vérification d'alignement fonctionnel, en utilisant l'autre instance , considérée comme valide, pour rompre le canal entre les première et seconde instances. 2.- Système embarqué selon la revendication 1, dans lequel les composants de la couche matérielle (12) sont des composants qui ne sont pas validés de manière à présenter un taux de défaillance déterminé. 3047862 24 3.- Système embarqué selon la revendication 1 ou la revendication 2, dans lequel l'intergiciel (26) comporte également un service de réamorçage de la redondance. 4.- Système embarqué selon l'une quelconque des revendications 1 à 3, dans 5 lequel le service de vérification d'alignement fonctionnel met en oeuvre un processus de vote entre les données de sortie générées par les première et seconde instances, les données de sortie constituant un type particulier de signature. 5.- Procédé de fonctionnement (200) d'un système embarqué selon l'une 10 quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte les étapes consistant à : établir (210), lors de l'initialisation du système embarqué (10), un canal sécurisé et authentifié entre la première instance (A1.1) et la seconde instance (A1.2) d'une même application (A1), pour l'échange de messages de service 15 entre la première instance et la seconde instance ; puis, au cours du fonctionnement du système embarqué, vérifier (220) périodiquement l'alignement fonctionnel entre les première et seconde instances (A1.1 ; A1.2), en calculant une signature pour chaque instance à partir d'une pluralité de données contextuelles relative à l'instance 20 considérée, puis en comparant entre elles les signatures calculées ; et, en cas de désaccord entre les signatures, isoler (230) une instance considérée comme défaillante parmi les première et seconde instances, par rupture, par l'instance valide, du canal vers l'instance défaillante. 25 6.- Procédé de fonctionnement selon la revendication 5, dans lequel l'étape d'isolement est suivie d'une étape de rétablissement de la redondance requise par l'application (A1), consistant à : démarrer une nouvelle instance de l'application en redondance de 30 l'instance défaillante isolée et vérifier (240) que la nouvelle instance a démarré correctement et avec un paramétrage approprié ; si l'exécution de la nouvelle instance dépend de données de configuration contextuelles, recopier (250) les données d'une instance active de l'application ; exécuter (260) la nouvelle instance avec les données d'entrée appliquées 35 également à l'instance active de l'application, et vérifier l'alignement fonctionnel de 3047862 25 chaque instance de l'application ; et si aucune divergence n'est détectée pendant une durée prédéterminée, établir (270) un canal sécurisé entre la nouvelle instance et la ou chaque autre instance active de l'application. 5 7.- Procédé de déploiement (100) d'un système embarqué conforme à l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte, pour dimensionner ledit système embarqué (10) les étapes consistant à : - spécifier (110) les caractéristiques non-fonctionnelles de la ou de chaque 10 application à déployer sur le système embarqué ; - choisir (120), pour chaque application, un patron de déploiement spécifiant pour ladite application un ensemble d'attributs de sûreté de fonctionnement ; - déterminer le nombre d'instances associées à une application devant être exécutées sur le système embarqué à partir des patrons de déploiement choisis pour 15 l'application correspondante ; - dimensionner (130) les besoins calculatoires du système embarqué en fonction des caractéristiques non-fonctionnelles de chaque application et du nombre d'instances déterminé pour chaque application ; - déterminer (140, 150) un plan de déploiement à partir du nombre d'instances de 20 chaque application et des besoins calculatoires ; - dimensionner (160) le réseau de communication, en vérifiant que la charge du réseau est compatible avec le plan de déploiement et, - configurer (170) le système embarqué conformément au plan de déploiement. 25 8.- Procédé de déploiement selon la revendication 7, dans lequel l'étape de configuration du système embarqué (170) comporte : - le chargement de chaque instance de chaque application sur un calculateur associé conformément au plan de déploiement ; et, - l'implémentation des patrons de déploiement associés à chaque application par 30 configuration des services de l'intergiciel réparti (26) de la couche logicielle du système embarqué. 35