Soutenance mémoire
La sûreté de fonctionnement des systèmes embarqués critiques est depuis toujours un enjeu majeur qui préoccupe à la fois leurs constructeurs et leurs utilisateurs, et ce, pour plusieurs raisons. La première raison est que, dans ces systèmes, l’occurrence de certaines défaillances pourrait engendrer un évènement catastrophique avec des conséquences graves sur l’environnement ou même sur la vie humaine. La deuxième raison est que ces systèmes sont soumis à des exigences de sûreté de fonctionnement dictées ou recommandées par des standards et des normes de certification. Mais, dans un tel contexte, atteindre un haut niveau de sûreté de fonctionnement se heurte, d’une part, aux contraintes de ces systèmes en termes de poids, de volume et de consommation énergétique qui doivent être optimisés, et d’autre part, aux caractéristiques spécifiques à certains systèmes embarqués critiques, notamment, l’inaccessibilité du système pour la maintenance (par exemple, dans le domaine aérospatial), ou le fait que le système évolue dans un environnement sévère, ce qui multiplie le risque des causes de défaillances. Étant données toutes ces contraintes et entraves, atteindre le niveau requis en sûreté de fonctionnement est toujours un vrai défi à relever par les concepteurs des systèmes embarqués critiques. Ce défi devient encore plus important lorsque pour un système donné, on cherche à introduire une ou des nouvelles technologies, puisqu’étant nouvelles, elles sont par nature moins éprouvées, moins bien maîtrisées, demandant ainsi un travail supplémentaire pour pouvoir être intégrées.
Certains systèmes de « contrôle commande » font partie des systèmes embarqués critiques que nous ciblons. De manière générale, un système de contrôle commande est défini comme un système qui commande et contrôle (ou supervise) un autre système, comme par exemple une voiture, un avion, un satellite, un robot, etc. Dans tous les cas, ces systèmes sont composés de calculateurs, de capteurs et d’actionneurs, et, de plus en plus souvent, d’un réseau de communication. En effet, les systèmes de contrôle commande ne cessent de profiter des progrès technologiques au niveau des composants électroniques et informatiques, et ils adoptent ainsi des architectures de plus en plus distribuées par opposition aux anciennes architectures centralisées et ce, grâce à l’apparition des capteurs et des actionneurs intelligents qui permettent la distribution de l’intelligence du système (par exemple, la prise de décision en ce qui concerne le traitement des données). En effet, les dernières générations des capteurs et actionneurs intelligents intègrent des capacités importantes de stockage et de traitement, ainsi que des dispositifs évolués de communications numériques avec des débits de plus en plus élevés. Ces composants sont de plus en plus miniaturisés dans l’optique d’optimiser leur poids et leur consommation d’énergie, puisque ces deux aspects sont primordiaux dans le contexte des systèmes embarqués critiques. Pour illustrer ces propos, nous donnons l’exemple d’un système extrêmement critique, le système de commande de vol d’un avion (système qui gère la trajectoire de l’avion) dans lequel l’intelligence du système était centralisée dans les calculateurs, mais l’intégration des actionneurs et des capteurs intelligents dotés d’une électronique locale évoluée a permis la distribution d’une partie de cette intelligence vers ces capteurs et actionneurs. On peut également citer le domaine de l’automobile.
SYSTÈMES EMBARQUÉS CRITIQUES
Les systèmes ciblés par nos travaux sont les systèmes embarqués critiques. Nous pouvons commencer par noter que ces deux propriétés « embarqués » et « critiques » ne sont pas nécessairement corrélées : cela veut dire qu’un système embarqué peut ne pas être critique et vice-versa.
La propriété « embarqué » se traduit par le fait que le système en question est enfoui dans un autre système qui lui-même assure une fonction ou un service plus global. Nous pouvons trouver des systèmes enfouis (embarqués) dans des systèmes plus grands en taille et complexité, comme les voitures ou les avions, mais cela peut aussi être le cas des systèmes que nous utilisons dans notre vie quotidienne, à savoir le téléphone portable ou encore la machine à laver. Pour faire fonctionner ces systèmes, des systèmes y sont embarqués dans l’objectif d’exécuter des tâches précises.
La deuxième propriété des systèmes ciblés est la propriété « critique ». Un système est dit « critique » si une défaillance d’un de ses composants peut engendrer des dégâts matériels importants ou/et des conséquences graves sur l’environnement ou sur la vie humaine. Par exemple, un avion est un système critique du fait qu’une défaillance pourrait, dans certains cas, mettre en danger la vie des passagers et de l’équipage. Cette propriété écarte tous les systèmes embarqués non critiques du périmètre de nos travaux.
Étant données ces deux propriétés, les systèmes embarqués critiques ont des caractéristiques et des exigences particulières que nous allons définir dans ce qui suit.
Caractéristiques et exigences des systèmes embarqués critiques
Les SEC sont généralement des systèmes électroniques et informatiques « autonomes » et « réduits » (en poids, volume, puissances de calcul, etc.). Ainsi, la conception de tels systèmes diffère de celle des systèmes électroniques et informatiques standards par le fait, d’une part, que la composante logicielle et la composante matérielle sont intimement liées (utilisant principalement des micro-processeurs ou des microcontrôleurs), et d’autre part, par le fait de devoir tenir compte d’un ensemble d’exigences et de restrictions. Puisqu’ils sont conçus pour être enfouis dans d’autres systèmes et afin de réduire leurs coûts, tous les systèmes embarqués critiques se caractérisent selon [Armoush 2010] par :
• un poids et un volume réduits,
• des capacités mémoire et puissances de calcul réduites,
• une consommation énergétique réduite.
Certains SEC se caractérisent par :
• un environnement sévère avec des radiations, des vibrations, des variations de températures, etc., ce qui augmente les sources et les risques de défaillances,
• des possibilités limitées d’intervention et de réaction en cas de défaillance, par manque « d’accessibilité » au système (par exemple les SEC dans le domaine spatial).
Ainsi, étant données les caractéristiques communes à tous les SEC et celles spécifiques à certains, la conception des systèmes embarqués critiques doit répondre aux exigences suivantes :
• faible consommation d’énergie : des mécanismes d’optimisation de la consommation d’énergie doivent être déployés (par exemple en optimisant les temps d’exécution),
• haut niveau de performance : des mécanismes d’amélioration de la réactivité du système (afin de répondre par exemple aux contraintes temps réel) doivent être mis en place,
• haut niveau de sûreté de fonctionnement (définie à la section I.2) : cela veut dire que le système doit remplir ses fonctionnalités en satisfaisant les niveaux exigés des différents attributs de sûreté de fonctionnement ciblés, par exemple la disponibilité, l’intégrité (définis dans la section I.2), etc.
À noter que les caractéristiques et les exigences des systèmes embarqués critiques sont parfois contradictoires. Par exemple, le haut niveau de sûreté de fonctionnement requis est plus coûteux à atteindre étant donné un environnement sévère, qui augmente les sources de défaillances et demande donc la mise en place de davantage de mécanismes de tolérance aux fautes, ce qui demande davantage de ressources, alors même que les ressources sont limitées. Ainsi, satisfaire les exigences des SEC est un important défi à relever pour ses concepteurs.
Domaines d’application et exemple d’illustration
Avec les progrès en microélectronique et en informatique embarqués, le spectre des systèmes embarqués ne cesse de s’élargir, ces systèmes peuvent être de petite taille (ex : les montres intelligentes) ou de grande taille (ex : un avion) et ils peuvent être produits en quelques unités (ex : un robot médical) ou en plusieurs millions d’unités (ex : voitures). Les SEC peuvent avoir différents niveaux de contraintes de conception (en termes de consommation d’énergie, contraintes temporelles, etc.) ce qui fait qu’il existe des SEC plus contraignants que d’autres (cela dépend aussi du domaine). Le niveau de criticité (qui s’explique par le niveau de sûreté de fonctionnement ciblé) diffère aussi d’un système à un autre selon le domaine et le rôle du système. Les systèmes embarqués critiques sont déployés dans plusieurs domaines, comme le domaine avionique (civil ou militaire), automobile, ferroviaire, nucléaire, spatial, médical, etc. Nos travaux de thèse ciblent les SEC en général mais se référent plus particulièrement aux systèmes de commande de vol avioniques. Pour cela, nous les considérons comme exemple pour illustrer notre description des SEC. Le système de commande de vol est le système qui contrôle la trajectoire de l’aéronef (avion, hélicoptère ou autre). Il est composé de l’ensemble de calculateurs, du système de communication (particulièrement pour les architectures « Fly By Wire »), et des capteurs et actionneurs servant à assurer le vol de l’appareil dans les trois phases : décollage, vol et atterrissage. Le système de commande de vol contrôle les gouvernes en envoyant des ordres, déterminés à partir de la consigne du pilote et des informations issues des capteurs, aux surfaces contrôlées (les actionneurs) manuellement par le pilote ou automatiquement par l’autopilote.
Le système de commande de vol est un système embarqué critique ayant de fortes contraintes et exigences. Une défaillance d’un composant de ce système pourrait engendrer la défaillance du système ce qui peut nuire à la vie de l’équipement et des passagers au bord de l’avion. La conception de ce système est soumise à des fortes contraintes en sûreté de fonctionnement, en relation étroite avec les aspects de certification (le taux de défaillance doit être inférieur à 10⁻⁹ par heure de vol). Avec les progrès technologiques au niveau des composants et l’apparition des capteurs et actionneurs de plus en plus intelligents (dotés de capacités de mémorisation et de traitement de données), les systèmes de commande de vol ont évolué vers des architectures de plus en plus distribuées où l’intelligence du système, qui était jusque-là centralisée au niveau des calculateurs, est devenue de plus en plus répartie [Sghairi 2010]. Ces évolutions vers des architectures distribuées augmentent la complexité de ces systèmes.
|
Table des matières
INTRODUCTION
CHAPITRE I CONTEXTE GÉNÉRAL ET CONCEPTS FONDAMENTAUX
I.1 SYSTÈMES EMBARQUÉS CRITIQUES
I.1.1 Caractéristiques et exigences des systèmes embarqués critiques
I.1.2 Domaines d’application et exemple d’illustration
I.2 SÛRETÉ DE FONCTIONNEMENT : PRINCIPAUX CONCEPTS
I.2.1 Attributs
I.2.2 Entraves
I.2.2.1 Classification de base
I.2.2.2 Corrélation et relativité des définitions de base
I.2.3 Moyens
I.2.4 Sûreté de fonctionnement et certification
I.3 PROBLÉMATIQUE DE L’INTÉGRITÉ DES COMMUNICATIONS
I.3.1 Périmètre de l’intégrité des communications
I.3.1.1 Attributs d’une communication intègre
I.3.1.2 Intégrité de bout en bout
I.3.2 Corruption des communications : classification et causes d’erreurs
I.3.3 La tolérance aux fautes pour l’intégrité des communications
I.3.3.1 Redondance symétrique ou asymétrique (diversification)
I.3.3.2 Granularité de la redondance
I.3.3.3 Redondance statique (ou active), dynamique (ou passive) et hybride
I.3.3.4 Redondance temporelle ou spatiale
1) Redondance temporelle
2) Redondance spatiale
I.3.3.5 Exemples d’architectures redondantes
I.3.3.6 Conclusions et redondances retenues pour l’intégrité des communications
I.4 LES CODES DÉTECTEURS D’ERREURS POUR L’INTÉGRITÉ DES COMMUNICATIONS
I.4.1 Étude générique : description générale des codes détecteurs et des différentes familles de codes
I.4.2 Classification des codes détecteurs d’erreurs
I.4.2.1 Les codes en blocs
1) Les codes en blocs linéaires/non linéaires
2) Les codes en blocs linéaires cycliques/non cycliques
I.4.2.2 Les codes concaténés
I.4.2.3 Les codes convolutifs
I.5 CONCLUSION
ii Table des matières
CHAPITRE II TRAVAUX CONNEXES ET SOLUTIONS POUR L’INTÉGRITÉ DES COMMUNICATIONS
II.1 PRINCIPAUX CODES DÉTECTEURS D’ERREURS POUR L’INTÉGRITÉ DES COMMUNICATIONS
II.1.1 Les codes CRC
II.1.2 Fletcher
II.1.3 Adler
II.1.4 WSC
II.1.5 XOR
II.1.6 Le complément à 1
II.1.7 Le complément à 2
II.1.8 Code de parité
II.2 L’INTÉGRITÉ DES COMMUNICATIONS DANS LES RÉSEAUX EMBARQUÉS
II.2.1 ARINC 429
II.2.2 MIL-STD-1553
II.2.3 AFDX
II.2.4 TTP/C
II.2.5 LIN
II.2.6 Flexray
II.2.7 CAN
II.3 SOLUTIONS BOUT EN BOUT POUR L’INTÉGRITÉ DES COMMUNICATIONS
II.3.1 Canal noir versus Canal blanc
II.3.2 PROFIsafe
II.3.3 FSoE
II.3.4 openSAFETY
II.4 TRAVAUX ACADÉMIQUES SUR L’INTÉGRITÉ DES COMMUNICATIONS
II.4.1 Approches basées sur les codes détecteurs d’erreurs
II.4.1.1 Utilisation des CRC (à différents niveaux)
II.4.1.2 Approche d’intégrité évolutive basée sur les CRC
II.4.1.3 Utilisation des sommes de contrôle arithmétiques
II.4.1.4 Les codes flexibles
II.4.2 Approches basées sur la redondance matérielle
II.4.3 Approches basées sur la diversification des données
II.4.3.1 Description générale de la diversification des données
II.4.3.2 Diversification des données et intégrité des communications
II.5 DISCUSSION ET ORIENTATION DE NOS TRAVAUX
II.6 CONCLUSION
CHAPITRE III APPROCHE D’INTÉGRITÉ BOUT EN BOUT BASÉE SUR LES CODES DÉTECTEURS D’ERREURS
III.1 PRINCIPE GÉNÉRAL DE L’APPROCHE D’INTÉGRITÉ BOUT EN BOUT
III.1.1 Approche d’intégrité bout en bout : présentation
III.1.2 Systèmes « contraignants » ou « très contraignants » : définitions
III.1.3 Les deux approches proposées : mono-code et multi-codes
III.1.4 Stratégie de sélection des codes
III.2 APPROCHE D’INTÉGRITÉ MONO-CODE
III.2.1 Limitations des approches existantes
III.2.2 Démarche de choix des codes détecteurs d’erreurs à évaluer
III.3 ÉVALUATIONS POUR L’APPROCHE MONO-CODE
III.3.1 Contexte général
III.3.2 Évaluation du pouvoir de détection des codes
III.3.2.1 Environnements d’évaluation
1) Environnement logiciel basé sur Matlab-Simulink
2) Environnement logiciel en langage C
III.3.2.2 Scénarios mis en place
1) Scénario n°1 : simulations Matlab avec génération exhaustive
2) Scénario n° 2 : simulations Matlab avec générations aléatoires
3) Scénario N°3 : simulations C avec générations aléatoires
III.3.2.3 Résultats préliminaires sur Matlab-Simulink
III.3.2.4 Résultats étendus dans l’environnement d’évaluation en C
1) Intervalles de confiance et choix du nombre des cas de test
2) Résultats des évaluations des codes de 8, 16 et 32 bits
3) Intervalles de confiance : calcul a posteriori
III.3.3 Évaluations du coût de calcul des codes présélectionnés
III.3.3.1 Problématique de l’évaluation des temps de calcul
III.3.3.2 Environnement d’évaluation du temps de calcul
1) L’outil « PyCRC » pour les codes CRC
2) L’outil « Universal CRC » pour les codes CRC
3) L’outil pour les codes Adler et Fletcher
III.3.3.3 Fonction de mesure des temps d’exécution, métriques et scénarios ciblés
1) Fonctions clock() et times()
2) Fonction et stratégie de mesure
III.3.3.4 Évaluations sur un environnement matériel standard
1) Environnement matériel et compilateur
2) Algorithmes implémentés et principes des scénarios évalués
3) Scénarios « sans favorisation du cache »
4) Scénarios « avec favorisation du cache »
III.3.3.5 Évaluations sur un environnement matériel embarqué (carte STM32)
1) Description générale de la plateforme et de l’environnement
2) Mesures du temps
3) Évaluations : scénarios et résultats présentés
III.3.3.6 Comparaison des résultats sur environnements matériels standard et embarqué
III.4 APPROCHE D’INTÉGRITÉ MULTI-CODES
III.4.1 Caractéristiques des systèmes ciblés
III.4.2 Problème du mode commun de défaillance
III.4.3 Approche multi-codes et complémentarité des codes détecteurs d’erreurs
III.5 ÉVALUATIONS POUR L’APPROCHE MULTI-CODES
III.5.1 Contexte général
III.5.2 Résultats des évaluations de la complémentarité des codes
III.5.2.1 Scénario n°1 : approche bi-codes combinant des codes 8 bits
III.5.2.2 Scénario n°2 : approche tri-codes combinant des codes 8 bits
III.5.2.3 Scénario n°3 : approche bi-codes combinant des codes 16 bits
III.5.3 Conclusion sur l’approche multi-codes
III.6 CONCLUSION
CONCLUSION
