Soutenance mémoire
L’intégration des règles et des normes
A quel moment le risque est-il acceptable ? « Un risque acceptable (ISO/CEI) est défini comme un risque accepté dans un contexte donné, basé sur des valeurs courantes de notre société. » L’acceptabilité concerne le risque et non la gravité du dommage ou sa probabilité d’occurrences considérées séparément. L’acceptabilité est aussi fonction du contexte : est-ce un système précurseur avec de nouvelles technologies ou l’état d’un savoir, ou alors un système avec une mise en œuvre rodée ? Les valeurs courantes sont une comparaison avec quelque chose d’approuvé de tous : on accepte le risque de mourir en prenant l’avion si la probabilité de ce décès par cette cause est identique voire inférieure à la probabilité de décès induit par un séisme ou une crise cardiaque. Peut-on prendre un risque élevé si un dénouement fatal est inéluctable dans l’état actuel du contexte ? On parle de sécurité lors de l’absence de risque inacceptable, c’est l’équilibre entre l’idéal de la sécurité absolue, et les exigences à remplir. Le danger est caractérisé par un transfert d’énergie ou dû à un ensemble de conditions couplées, induisant une accumulation conduisant à un accident, donc capable de provoquer un dommage.
– Phénomène dangereux : source potentielle de dommage ;
– Situation dangereuse : exposition aux phénomènes dangereux ;
– Evènement dommageable : évènement déclencheur qui fait passer de la situation au dommage ;
– accident : évènement non désiré et occurrence non prévue résultant en un dommage ;
– incident : évènement qui ne conduit pas à des pertes, mais qui a le potentiel de créer des dommages en d’autres circonstances. L’analyse du risque consiste en la production d’informations en vue de la certification. La certification est possible si et seulement si l’analyse est considérée tout au long du processus de mise en place du système (développement et fabrication). L’analyse est continue et itérative. On rejoint alors les thématiques exposées dans les normes, telle que la DO-178B. C’est pour cela que lorsque l’on veut appliquer une norme pour un projet, il faut tout au long de la conception prendre en compte l’analyse des risques : on doit pouvoir la justifier pour l’industrialisation du prototype. L’étude du radar météo a été faite pendant la thèse. Bien que la thèse soit une étude scientifique, le travail fait dans ce cadre peut être largement remis en question si l’on ne passe pas beaucoup de temps à s’impliquer dans la rigueur du développement, qui représente un temps significatif dans la thèse.
La genèse de la norme et son évolution
La norme logicielle DO-178 est une norme plutôt ancienne (1982) rédigée par le comité RTCA (pVIII) afin de réglementer les nouveaux dispositifs logiciels, revue en 1985 (révision A) suite à un retour d’expérience. La révision B, la dernière à ce jour, date déjà de 1992. Cette mise à jour a été demandée en 1989 par la FAA (pVIII) suite aux évolutions rapides des technologies et aux différentes interprétations des industriels et des autorités de certifications (qui sont des problèmes récurrents). Cette norme est apparue avec les premières utilisations des logiciels embarqués en aéronautique, et n’est pas vraiment adaptée aux cibles « DSP » modernes. Le DSP est pourtant aussi ancien que la norme, mais c’est un composant « nouveau » en aéronautique compte tenu de sa maturité à ce jour. Cela s’explique sans doute par la montée en puissance récente de ces composants qui les rendent attractifs. Cependant, les DSP existent déjà en aéronautique, mais sous des « versions d’utilisation » processeur où les programmes exécutés sont calqués sur les calculateurs, c’est-à-dire suivant un séquenceur ou un RTOS (pVIII). La nouveauté de notre application est l’utilisation d’un DSP optimisé pour l’électronique de puissance, où la fréquence d’horloge est faible en comparaison des DSP de traitements numériques, et les périphériques sont reliés à de l’électronique de puissance qui demande un contrôle évènementiel. On s’écarte donc du DSP qui traite des données qui lui-même communique avec d’autres composants qui traitent des données. La sûreté de fonctionnement a ici un impact direct sur les composants électroniques, c’est donc une approche software/hardware. Cette norme est globalement trop générale pour que l’on puisse appliquer une quelconque règle au DSP en question, mais elle est aussi souvent contradictoire avec l’utilisation de celui-ci. En effet, la norme ne pouvait pas anticiper toutes les éventualités des progrès des microprocesseurs / microcontrôleurs. La révision ‘C’ de cette norme est prévue pour fin 2008, des industriels tel que Thales™ participent à son élaboration, mais la question directe des interruptions (évènements) n’a pas été abordée d’après les sources internes.
L’existence du SEU crée une difficulté actuelle
L’introduction de logiciel dans les convertisseurs statiques s’accompagne de nouveaux problèmes, dont fait partie la sensibilité aux particules provenant de l’espace, tels que les neutrons. En effet, on appelle SEU (Single Event Upset) l’effet indésirable sur les matériels informatiques dû à ces particules, car ils touchent essentiellement les mémoires, de part leurs technologies et leurs tailles. On met en relief ci-dessous les trois types récurrents : • Un registre : c’est une mémoire statique dédiée à un usage unique, liée à un périphérique ou une mémoire système très rapide et incontrôlable par une autre ressource, car c’est elle la mémoire de plus haut niveau (ex : les paramètres de passage en pile). Les registres ont dans l’ensemble une petite taille et ont des répercussions directes sur le déroulement du programme, un ou plusieurs bits qui changent d’états compromettent fortement l’exécution d’un programme. • Une RAM : c’est une mémoire dynamique où les données de calcul peuvent être erronées en changeant un ou plusieurs bits. En général, les données (au sens des variables) en RAM sont rafraîchies et écrasées de façon cyclique et à intervalles très courts. Par exemple, une donnée corrompue d’un asservissement sera perçue comme un « glitch », et sera filtrée par l’algorithme. L’impact d’une erreur est donc à relativiser. Par contre, une erreur d’un code exécuté en RAM sera d’une conséquence de toute autre nature car cela change les instructions, les adresses, etc. – 23 – Chapitre 1 • Une ROM : des données du programme altérées peuvent conduire à un bogue système selon le bit touché : un bit de variable peut changer sa valeur, cela peut être gênant ou non ; un bit de saut d’adresse conduit à un échec d’exécution. Contrairement aux composants analogiques et numériques discrets qui ont une taille et une énergie de fonctionnement significative, les composants numériques « très intégrés » ont une énergie élémentaire (pour chaque cellule mémoire) proche des énergies des particules [DOD03]. Ainsi, une particule qui traverse une cellule mémoire peut changer l’état énergétique de cette dernière, donc altérer l’état mémoire. L’aéronautique est un secteur touché par ce phénomène car l’altitude est un facteur prépondérant sur la densité des SEU (voir Fig. 9). Les SEU sont une catégorie de défauts des S.E.E. (Single Event Effect [MAJ95]) issus des particules redoutées car on ne peut pas les détecter, les canaliser ou les éviter. Ces particules ont été mises en évidence ces 20 dernières années suite à différents incidents. En 1988-1989, IBM™ a conduit des études sur des SRAM sur plusieurs avions, avant de se joindre à Boeing. Cet industriel a mis en place un laboratoire distinct nommé BREL [RLAB] sur ces thématiques, disposant d’un réseau de compétence sur différents sites, notamment le WNR à Los Alamos, sur les neutrons atmosphériques. Ainsi, il est démontré que les SEU sont corrélés avec le flux de neutrons atmosphérique [NOR93] [NOR95] [NOR96] [NOR97] [NOR98] [OBE93]. Un SEU provoque un changement d’état d’un bit. Les radiations qui en sont la source sont : – concentrées dans la ceinture magnétique terrestre et affecte le passage des satellites, – présentes dans l’espace via les rayons cosmiques galactiques, très énergétiques mais moins concentrés. L’effet est alors bien plus grave qu’un simple changement d’état, – issues du soleil dont l’activité varie (heures, jours…). Il produit des électrons, des protons et d’autres particules moins énergétiques. Les particules des radiations atmosphériques sont (voir Fig. 9): – les photons, – les particules chargées, – les neutrons. Ce sont les neutrons qui créent des SEU car il n’existe pas de blindage pour l’avion, et la quantité de protons et de pions n’est pas significative devant le nombre les neutrons. Le flux de neutrons est fonction de l’altitude et de la latitude. Les neutrons sont créés par l’interaction des rayons cosmiques avec l’O2 et le N2 dans l’air. Les densités sont : – 1.4 Neutron/cm².sec à 60000 pieds (pic), soit 18.2 km d’altitude – 0.4 Neutrons/cm².sec à 30000 pieds, soit 9.1 km d’altitude – 24 – Chapitre 1 – 0.004 Neutrons/cm².sec au sol Le changement d’état dans le silicium n’est pas du à la ionisation directe due au neutron, mais plus à la réaction nucléaire dans le silicium. Les énergies <1MeV1 sont sans effet pour le silicium. Pour l’aéronautique, les mesures laissent à penser que le spectre des énergies est compris entre 1MeV et 10MeV, en fonction de l’altitude et de la latitude. (On notera qu’on peut avoir des énergies >1000 MeV en dehors du spectre qui nous concerne). A titre d’exemple, la normalisation est donnée pour une altitude de 40000 pieds et une latitude de 40°. On a alors une densité de 0.89 neutrons/cm².sec dans l’intervalle 1-10 MeV. Dans le pire cas de vol (Paris – Anchorage), on a 2.4 neutrons/cm².sec (8600 n/cm².h) dans la gamme 1-800 MeV d’après les sources Thales Avionics™/SE. Pour les essais en laboratoire par exemple, la section efficace des neutrons atmosphériques est comparable à celle des protons pour des énergies >50 MeV. Pour un A320 d’un vol d’une heure, avec un bombardement de 1.4 neutrons/cm².s (pour altitude d’un vol court), le bombardement total est de 5000 neutrons/cm² pour une énergie de 1MeV. Pour un A340 d’un vol de 8 heures, avec un bombardement de 2.4 neutrons/cm².s (pour l’altitude d’un vol long), le bombardement total est de 70000 neutrons/cm² pour une énergie de 1MeV. Pour la comparaison avec les résultats donnés en Fig. 12 provenant du laboratoire TRIUMF – UBC, on donne les énergies en MeV et les densités de bombardement pour les conditions des tests et des essais qui permettent de reproduire les effets en laboratoire.
Le DSP, un composant numérique typique
Contrairement au FPGA qui a des fonctions créées sur mesure par le concepteur (avec les moyens associés de « triplication », de checksum, etc.), le DSP a une architecture figée en ce qui concerne les fonctions numériques. En effet, on ne parle pas de la disposition sur le silicium des fonctions mémoires, I/O, etc. des deux composants, bien que cette disposition ne soit pas anodine. Ainsi, le DSP a une structure figée qui ne permet pas de tripler les fonctions, on ne peut pas rajouter de mécanismes sur le traitement des données (ex : checksum), sauf bien sûr de façon logicielle, mais après il faudrait continuer la boucle pour être sûr que ce mécanisme ne soit pas lui-même corrompu. Le DSP est conçu pour un usage spécifique, c’est pour cela que l’on distingue les DSP de traitements de signaux (ex : audio et vidéo), des DSP dédiés à des applications comme l’électronique de puissance. Quand on choisit un DSP, on ne peut pas choisir l’architecture la plus adaptée pour mettre en œuvre des mécanismes de sécurité de fonctionnement. Ainsi, l’usage des évènements dans notre famille de DSP est voulue et orientée par notre application. Les mécanismes à mettre en œuvre pour la robustesse aux SEU seront à explorer.
Le monitoring
Le monitoring est un concept bien connu en informatique, et en informatique industrielle. Il existe beaucoup d’ouvrages relatifs à la sécurité et la sûreté de fonctionnement logicielle. Le monitoring est sur le fond identique d’une application à l’autre, mais il est décliné en autant de manières de mise en pratique possible que d’applications à monitorer. En effet, le monitoring surveille et/ou analyse des données ou/et des comportements des applications [QIU00] [TIN03]. En ce sens, les dispositifs de monitoring sont spécifiques aux grandeurs associées. La publication [PET02] « requirements-based monitors for real time systems » est une description haut niveau du principe de monitoring. La méthode s’applique assez bien à notre problématique de logiciel embarqué, qui est un programme interfacé directement avec du « matériel ». En soi, ce n’est pas une révolution, mais le DSP n’est pas souvent cité dans les exemples d’applications aéronautiques, et encore moins en termes de sûreté de fonctionnement et de normes ; ainsi, on va faire le point sur les techniques applicables. En cas d’erreur, il se produira un effet non souhaité et non souhaitable. L’erreur va générer un effet qui se décline en plusieurs niveaux, qui chacun traduit une criticité. On trouvera l’erreur catastrophique, sévère, majeure et mineure. Dans tous les cas, l’erreur doit être détectable et détectée. Comme le projet s’inscrit dans une criticité ‘C’ de la DO178B, en cas de problème majeur ou plus du RTSU (carte servomécanisme pour l’objet de l’étude), on peut basculer d’un RTSU à l’autre afin d’isoler le matériel défectueux (principe de redondance). Ainsi, une défaillance majeure ou plus n’aura pas d’effet sur les systèmes connexes (notamment sur le PFC en tête et les moteurs). Le DSP est à la base un microcontrôleur, et est ainsi doté d’un watchdog. Cet appendice, intégré au silicium du DSP, est un circuit en étroite relation avec le cœur permettant de réaliser un « reset » général. Le watchdog est configuré au démarrage de la cible, et fonctionne de façon autonome en parallèle du DSP. Lors de la configuration, le concepteur choisit comment surveiller le programme. Si au bout d’un certain time-out (périodique), le watchdog n’est pas rafraîchi, on considère qu’une erreur est survenue, et le DSP redémarre. Pour minimiser l’impact d’une erreur, la fréquence de la vérification est la plus élevée possible. C’est donc un choix arbitraire du concepteur pour avoir un compromis entre de bonnes performances du système et des tests qui détectent toutes les erreurs à effets importants.
|
Table des matières
Acronymes
Préambule
Introduction
Chapitre 1 : contexte et contraintes sur l’électronique embarquée
I. Les normes et les contraintes
A. Rappels sur la sûreté de fonctionnement
1. La décomposition de la sûreté de fonctionnement
2. Les risques et la classification
a) Définitions
b) Exemple sur l’application du radar
c) L’intégration des règles et des normes
d) La classification du risque
e) La criticité
B. La DO-178B
1. La genèse de la norme et son évolution
2. Exemples significatifs de la norme appliqués au projet
II. Sûreté de fonctionnement, hardware et software
A. Les SEU
1. L’existence du SEU crée une difficulté actuelle
2. Le SEU et le monde numérique
3. Le DSP, un composant numérique typique
4. Le SEU, une présence inéluctable, une cohabitation exigée
B. Le monitoring
1. Le principe
2. Sa mise en œuvre
3. Exemple de monitoring
4. Transposition de l’exemple à l’application du radar
C. L’analyse du fonctionnement
1. Le fonctionnement évènementiel
2. L’analyse temporelle (approche RMA)
3. L’analyse fonctionnelle (approche AMDEC)
III. Bilan des normes et analyses
Chapitre 2 : modélisation, simulation et conception de l’ensemble
I. Le système
A. La problématique de l’antenne
B. L’existant
C. La rupture technologique
II. Une étude de servomécanisme
A. Le découpage fonctionnel
B. Les boucles
III. Une approche sous Matlab®/Simulink®
A. L’étude continue
1. Le principe général
2. Le détail des axes circulaire et élévation.
B. Etude échantillonnée au format du DSP
C. L’analyse du code
D. L’analyse normative des évènements
1. La prise en compte des normes
2. L’analyse évènementielle
a) Les mécanismes
b) L’analyse temporelle
c) L’analyse fonctionnelle
d) L’analyse des flux de donnée
IV. La protection de la mécanique
V. Bilan de la simulation/conception
Chapitre 3 : indexage moteur
I. L’indexage usuel
A. La problématique
B. Les contraintes
C. Les démarrages des contrôles-moteurs
II. L’indexage automatique
A. Le phénomène recherché
B. La méthode des essais de courant par impulsions
C. Les limitations de la méthode
D. La phase statique
E. Résultats de dimensionnement de la procédure d’indexage de la phase statique
F. La phase électromécanique
G. L’organigramme fonctionnel
1. Machine à états finis de l’indexage
2. Programme de la phase statique
3. Programme de la phase électromécanique
III. Bilan de l’indexage automatique
Conclusion
Table des figures
Bibliographie
Télécharger le rapport complet
