Systèmes embarqués critiques

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.

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.

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

Lire le rapport complet