Contraintes spécifiques à l’embarqué critique temps-réel

Le besoin de mettre en place des mesures de sécurité n’étant plus à prouver, certaines contraintes sont cependant à prendre en compte afin de comprendre les difficultés que peut représenter la mise en place de ces mesures. Les parties sui-vantes proposent tout d’abord un aperçu des ressources disponibles sur avion et les contraintes amenées par le côté "embarqué". Ensuite, les problématiques de cer-tification seront expliquées en détail avec quelques chiffres pour comprendre les contraintes industrielles associées. Finalement, la caractéristique temps-réel de ces systèmes implique aussi des spécificités quant au développement de mesures de sécurité efficaces.

1.3.2.1 Les limitations des systèmes embarqués

Comme tout système embarqué, les ressources matérielles disponibles à bord d’un aéronef sont limitées. On peut évoquer la notion de coût, par exemple, un espace mémoire robuste aux rayonnements électromagnétiques et aux températures extrêmes étant beaucoup plus cher qu’un espace mémoire qu’on retrouve habituel-lement sur ordinateur. L’espace disponible et le poids sont égahabituel-lement égahabituel-lement li-mitant, ce qui impacte les possibilités en terme d’énergie électrique et de puissance de calcul embarquable. Enfin, un aéronef étant amené à voyager dans le monde, son environnement sera amené à changer. Au-delà des aspects météorologiques, la connectivité ne sera pas la même au-dessus de Paris qu’en survolant l’océan atlan-tique, par exemple. Également, les moyens de mise à jour actuels nécessitent que l’avion soit au sol, ce qui a un coût non négligeable pour les compagnies aériennes. A titre d’exemple, les mises à jour les plus fréquentes aujourd’hui ont lieu tous les 28 jours et concernent uniquement des base de données.

L’introduction de mesures de sécurité impactera inéluctablement ces aspects. Par exemple, des mesures logicielles auront besoin de temps de calcul et de mémoire dédiée, donc un calculateur et des équipements spécifiques, donc du poids et des coûts supplémentaires. Il est important de dimensionner les ressources nécessaires pour ces mesures dans une limite acceptable. Dans ces travaux, nous considérons

1.3. Problématiques de sécurité dans l’avionique 19

Table1.2 – Quelques caractéristiques techniques d’équipements avioniques actuels

Nom Fournisseur CPU RAM Poids

CPIOM-H Thales 1.33GHz 115Mb 4kg

IPC-8303 Rockwell Collins 1.4GHz 512Mb à 2Gb 5.4kg à 6.8kg

FMC 2975A GE Aviation 0.8GHz 512Mb 10.9kg

FV-4000 Esterline 0.5GHz 512Mb 8 à 9.3kg

qu’un maximum de 5% des ressources totales disponibles peut être alloué à des mesures de sécurité.

A titre d’exemple, le Tableau 1.2 liste les ressources disponibles sur différents équipements avioniques actuels. En comparaison, on trouve aujourd’hui des ordi-nateurs de bureau ayant un processeur d’une fréquence de 2GHz à 4.5GHz, avec de multiples coeurs, et des capacités mémoire RAM de 2Gb à 128Gb. La bonne gestion des ressources est donc un élément primordial à prendre en compte pour développer une fonction embarquée.

1.3.2.2 Développement de logiciels critiques sûrs

Le développement de système critiques en aéronautique est généralement réalisé en conformité avec les normes suivantes, qui couvrent différents niveaux :

— Système:

— ARP 4754A/ED-79 (Guidelines for Development of Civil Aircraft and Systems) : processus de développement des systèmes avioniques, en in-tégrant des études pour permettre leur certification,

— ARP 4761/ED-135 (Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment) : en-semble de méthodes d’analyse et d’évaluation de la sécurité-innocuité des systèmes avioniques à des fins de certification,

— Système IMA: DO-297/ED-124 (Integrated Modular Avionics (IMA)

Deve-lopment Guidance and Certification Considerations) : contraintes de dévelop-pement spécifiques à l’IMA, définit notamment la notion de partitionnement robuste,

— Logiciel : DO-178C/ED-12C (Software Considerations in Airborne Systems

and Equipment Certification) : contraintes de développement liées à l’obten-tion de la certifical’obten-tion de logiciel avionique,

— Matériel : DO-254/ED-80 (Design Assurance Guidance for Airborne

Elec-tronic Hardware) : contraintes de développement liées à l’obtention de la cer-tification de matériel électronique avionique.

En particulier, l’ARP4761 définit différents niveaux de criticité applicables aux systèmes avioniques (en anglais, catastrophic,hazardous, major, et minor). Ce ni-veau est attribué à chaque composant après analyse des défaillances potentielles

du système et de ses conséquences sur le vol. A chaque niveau est associé une probabilité qu’une défaillance ne survienne par heure de vol. Ces exigences sont transcrites au travers des niveaux de DAL (Design Assurance Level) qui sont au nombre de cinq. Le niveau DAL A est le plus critique, et impose donc plus de vérifications/recommandations que le niveau DAL E qui est le moins critique.

Un système dont le dysfonctionnement peut provoquer un problème catastro-phique impactant la sécurité du vol ou de l’atterrissage est classé DAL A. La pro-babilité d’un tel évènement ne doit pas dépasser 1×10−9 par heure de vol. En comparaison, le dysfonctionnement d’un système de niveau DAL E ne devrait pas avoir d’effet sur la sécurité du vol et aucun seuil de probabilité d’occurrence n’est donné.

Les exigences n’étant pas les mêmes selon le niveau de DAL, le développement ou la mise à jour d’un système DAL A coûtera beaucoup plus cher que l’équivalent sur un système DAL D ou DAL E.

1.3.2.3 L’aspect temps-réel

Les niveaux de criticité impliquent également des exigences en terme de temps de réponse des fonctions avioniques. Par exemple, il est primordial que le pilote connaisse sa position précise lorsqu’il est en phase de décollage ou d’atterrissage. De même, les calculateurs ne doivent pas induire de délai entre les actions du pilote sur les commandes et le mouvement correspondant effectué par les actionneurs. Ces temps de réponse sont notamment garantis par la ségrégation temporelle telle que décrite dans la Section 1.2.2. Dans un contexte IMA, quelque soit l’état des partitions s’exécutant sur le calculateur, le temps de calcul alloué à chaque partition et l’ordre d’exécution de l’ensemble sont garantis.

L’ajout d’une mesure de sécurité dans ce contexte doit prendre en compte cette exigence pour être insérée au bon niveau. Plusieurs niveaux peuvent être considérés pour insérer une mesure de sécurité dans ce contexte. Tout d’abord, le développe-ment d’une mesure de sécurité dans une partition (applicative ou système) permet de profiter de la flexibilité offerte par l’IMA, mais ne permet pas d’observation fine de l’exécution de l’ensemble des partitions (la partition de sécurité ne sera capable d’observer l’état du calculateur et donc des autres partitions seulement pendant sa propre exécution). Ensuite, une observation continue des partitions présentes sur le calculateur peut être réalisée au travers d’une modification du noyau temps-réel (RTOS). Cependant, un RTOS capable d’héberger des partitions de niveau DAL A doit être lui-même de niveau DAL A, ce qui implique un coût très important pour une modification. Au-delà du coût de développement d’un RTOS de niveau DAL A, la modification du RTOS peut avoir un impact important sur l’exécution temps-réel des partitions hébergées, par exemple si le temps de réponse aux appels système est modifié. Enfin, le développement de mesures de sécurité au niveau hardware est également envisageable, et présente des avantages et inconvénients similaires au développement de mesures de sécurité directement dans le RTOS.