• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 05/12/2019

Développez et intégrez votre projet

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Nous espérons que vous avez apprécié votre parcours dans les chapitres métiers et le focus que nous vous avons proposé sur la certification des logiciels embarqués en aéronautique. Nous allons maintenant prendre en compte l'ensemble des informations glanées au fil du parcours pour développer notre calculateur.

En préambule, nous tenons à vous rappeler que l'architecture présentée n'a pas de réalité opérationnelle et le développement ne sera pas décliné complètement. Ce choix est volontaire car notre but n'est pas de vous faire un cours d'avionique, ni de vous transformer en ingénieur aéronautique. Il est de vous sensibiliser aux contraintes de développement des systèmes embarqués critiques et de vous en donner quelques pratiques courantes de développement. Nous aurons ainsi plus de liberté pour illustrer nos propos, notamment sur la redondance à intégrer et le contenu des briques technologiques à considérer.

De plus, en sortant volontairement du cadre d'un programme aéronef donné, nous pouvons nous permettre de mettre en avant des technologies récentes potentiellement utilisables dans les prochains développements. C'est pédagogiquement plus intéressant. Nous rappelons aux puristes que pour l'exercice, nous limitons volontairement les opérations de notre calculateur au seul contrôle des gouvernes de profondeur. Ceci étant précisé, rentrons dans le vif du sujet.

Les objectifs de sécurité du calculateur

L'analyse de sécurité, ramenée au calculateur, donne les objectifs quantitatifs suivants :

  • probabilité de perte du signal de commande de l’actionneur d'une gouverne de profondeur détectée inférieure à 10-6 ;

  • probabilité de perte simultanée du signal de commande des 2 actionneurs des 2 gouvernes de profondeur détectée inférieure à 10-7 ;

  • probabilité de perte simultanée du signal de commande des 2 actionneurs des 2 gouvernes de profondeur non détectée inférieure à 10-9.

Côté calculateur, nous avons plusieurs options dans la façon dont nous allons répondre aux critères quantitatifs de sécurité. Les composants complexes envisagés (FPGA, microcontrôleur) ayant une probabilité de défaillance d'au mieux 10-6, nous devons mettre en œuvre au moins 2 chaînes de traitement pour assurer nos objectifs quantitatifs de sécurité de 10-7 et 10-9. Nous allons explorer les 2 solutions qui se présentent.

  1. On définit plusieurs chaînes de traitement parallèles (voir schéma ci-dessous) puis on compare le résultat de chaque chaîne et on effectue un vote majoritaire pour sanctionner le résultat "valide", celui qui est envoyé aux gouvernes.

Exemple d'illustration
Chaînes de traitement parallèles

2. On définit une chaîne de commande et une chaîne de surveillance (monitoring, en anglais) qui valide ou invalide le résultat de la première chaîne : on a une architecture qu’on appelle "COM-MON" pour COMMAND/MONITORING, comme le montre le schéma ci-dessous.

Exemple d'illustration
Architecture de commande de vol COM-MON

L'architecture de commande de vol des avions Boeing privilégie la première solution. Airbus a choisi de déployer la seconde solution au sein de ses systèmes de commande de vol électriques.

Il est important de souligner que les 2 solutions donnent des résultats satisfaisants. La première a pour conséquence une architecture système plus complexe mais des calculateurs plus simples. La seconde simplifie l'architecture système mais complexifie le développement des calculateurs.

La ségrégation

Ségrégation
Exemple de ségrégation

Des pratiques pour améliorer la tolérance de ces architectures consistent à utiliser des équipes différentes pour développer chaque chaîne de traitement. Nous pouvons, en plus, contraindre les équipes à utiliser des règles de conception, de codage, des outils de compilation, soit différents, soit configurés différemment. Cela évite qu'un bug ou qu'une défaillance d'un composant matérialisé par une combinaison exceptionnelle de conditions ne produise le même effet, au même moment, sur les chaînes redondées, invalidant immédiatement le bénéfice de la redondance.

Nous pouvons, enfin, faire exécuter ces chaînes de traitement sur des composants cibles distincts. Ces composants peuvent être de marque, de modèle ou de lot de fabrication différents.

 Exemple

Chaînes de traitement différentes

Dans l'exemple de notre calculateur, nous concevons une chaîne de commande qui fait l'acquisition des signaux d'entrée (consigne pilote et position de la gouverne). Elle génère, en fonction des écarts observés et des lois de contrôle-commande prédéfinies, des consignes de déplacement qui sont envoyées à la servocommande pilotée.

On lui adjoint une chaîne dédiée à la surveillance. Cette dernière contrôle l'intégrité des calculs et des consignes émises par la chaîne de commande. Elle surveille également l'état de santé interne du calculateur et la cohérence des données issues de l'environnement extérieur utilisé par le calculateur.

La gestion de la redondance permet de masquer ou de détecter et recouvrir l'impact d'une faute pour préserver la mission. Lorsqu'on conçoit une architecture à vote majoritaire, l'algorithme de vote rejette la solution minoritaire. On masque alors la faute et on ne perd aucune donnée. C'est le cas des protocoles de communication dits à correction d'erreur qui intègrent des mécanismes permettant de reconstruire à la volée une trame partiellement reçue ou erronée. L'architecture COM-MON permet de filtrer les données afin de ne considérer que les bonnes en sortie.

Architecture matérielle

Bien, mais de quelles briques avons-nous besoin pour réaliser notre architecture, et comment les mettre en œuvre dans le contexte de criticité qui est le nôtre ?

Nous allons retrouver les éléments traditionnels que vous commencez à connaître maintenant :

  • l'alimentation du calculateur ;

  • les interfaces de communication avec :

    • le monde réel via des capteurs,

    • les autres calculateurs,

    • les actionneurs ;

  • les modules de traitement des données.

Architecture du calculateur
Architecture du calculateur

En nous rapprochant, nous retrouvons :

  • les mémoires ;

  • des blocs programmables pour réaliser les fonctions désirées ;

  • des composants d'interface physique, par exemple des connecteurs, des voyants et des boutons manœuvrables en face avant ;

  • enfin, un châssis mécanique, qui intègre l'ensemble des éléments physiques dans une même enveloppe. Il permet d’assurer la ventilation du calculateur pour garantir une température de fonctionnement en ligne avec les objectifs de fiabilité.

Le processus de conception de ces systèmes embarqués consiste à faire en permanence des allers-retours entre les résultats de l'analyse de sécurité et l'architecture, afin de vérifier que les événements redoutés soient pris en compte et que l'architecture réponde aux objectifs de sécurité.

Schéma
Bouclages entre les analyses de sécurité et la conception de l'architecture

Nous observons également attentivement à chaque itération du processus que le MTBF (Mean Time Between Failure ou encore temps moyen de fonctionnement entre 2 pannes) introduit par l'architecture de notre calculateur satisfasse à ses exigences de fiabilité.

Les blocs alimentation

Zoomons maintenant encore sur quelques blocs.

Schéma
Blocs d'alimentation

L'alimentation et son "power management" tout d'abord. Notre calculateur est alimenté en 28VDC par 2 routes électriques séparées au niveau aéronef.

Nous commençons par filtrer ces signaux contre les effets indirects de la foudre, les perturbations électromagnétiques, les pics de tension électrique du réseau et les microcoupures. Nous appliquons un étage de prérégulation de la tension d'entrée et un limiteur de courant sur chaque entrée 28VDC. Chaque circuit de protection est défini en fonction d'exigences qui se formalisent par des profils, des gabarits et des seuils à respecter. Celles-ci sont issues de l'analyse avion, déclinées au niveau système et cascadées à notre équipement.

Cette tension est routée sur chacune de nos deux chaînes (commande et monitoring). Elle est maintenue disponible en cas de perte d'une des 2 sources d'alimentation externes. Enfin, elle est dérivée en plusieurs alimentations secondaires réalisées par des convertisseurs et régulateurs de tension afin d'alimenter tous les circuits électroniques actifs de chaque chaîne et d'apporter les tensions de référence aux circuits de conditionnement des signaux. Des tensions +/-15VDC, 5VDC, 3.3VDC, 1.8VDC sont ainsi mises à disposition des composants de l'équipement, avec des niveaux de puissance calculés pour répondre aux besoins de l'électronique embarquée.

Un module appelé power management est également intégré à ce bloc alimentation. Il génère certaines des tensions secondaires et gère leur séquence d'allumage et d'extinction, de façon à éviter des erreurs d'initialisation lors de la mise sous tension des circuits. Ce module pilote également les modes standby, veille et pleine puissance des circuits intégrés, afin d'optimiser la consommation électrique du calculateur. Cette fonction participe à l'amélioration de la performance thermique de l'ensemble du calculateur et donc à son intégrité et à sa pérennité.

Les Entrées/Sorties

Schéma
Gestion des entrées/sorties

Ce bloc est positionné physiquement au plus près de la semelle, c’est-à-dire la partie mécanique du boîtier en contact avec l'aéronef ou au moins des parois du calculateur, afin de bénéficier de la meilleure conduction thermique offerte par les parties métalliques du boîtier, et limiter intrinsèquement l'élévation de température à l'intérieur de celui-ci.

Les étages de protection foudre et les filtres de protection électromagnétique sont placés au plus près des connecteurs d'interface, pour limiter la possible propagation par rayonnement interne dans le calculateur des perturbations électriques. L'énergie électrique issue de la foudre est ainsi bloquée au plus près de l'entrée et évacuée au plus vite vers la masse mécanique de l'aéronef.

Vous êtes toujours là ? OK, alors on continue ;)...

Dans un calculateur numérique, les informations analogiques sont échantillonnées en valeurs discrètes et les traitements sont effectués à des intervalles de temps successifs.

Concernant un signal d'entrée, on peut considérer que le calculateur observe la variation continue d'une valeur physique et prend des photos de cette valeur. Une photo peut être prise lors d'un événement ponctuel ou régulièrement. La valeur du signal va ainsi être considérée comme constante par notre calculateur jusqu'à l'acquisition de la valeur suivante.

Si on zoome sur le signal ainsi numérisé, celui-ci ressemble à un escalier dont les marches représentent l'amplitude du signal à chaque lecture.

Schéma
Numérisation du signal

La hauteur minimum d'une marche de notre escalier correspond à la résolution de notre numérisation. Elle est déterminée par le nombre de chiffres de bits (0 ou 1), pouvant exprimer la valeur du signal. Un signal numérisé dans un mot de 8 bits aura ainsi 256 valeurs possibles pour représenter son amplitude, un mot de 24 bits en aura 16 millions. La taille des mots va ainsi dépendre de la précision de mesure nécessaire à l'application, et du niveau de bruit qui entoure le signal. En deçà d'un certain niveau, un gain de précision n'apporte pas plus d'information pertinente sur sa valeur.

Résolution de la numérisation
Résolution de la numérisation

La période d'échantillonnage, appelée aussi période de rafraîchissement, est le laps de temps au bout duquel l'information est mise à jour. Plus ce temps est court, plus le calculateur peut observer des variations rapides du signal. Pour les sorties analogiques, une courte période réduit intrinsèquement la hauteur des marches.

Période d'échantillonnage
Période d'échantillonnage

Relation entre période et hauteur des marches
Relation entre période et hauteur des marches

Une résolution adaptée, associée à une période d'échantillonnage courte, met le système dans des conditions favorables pour agir et réagir de façon fine avec son environnement. Cette finesse de pilotage a cependant un prix. Elle impacte tous les composants de la chaîne d'acquisition ou d'émission analogique-numérique, ainsi que l'unité de traitement dans la capacité à conserver cette précision, à effectuer des opérations et calculs sur des mots de plusieurs dizaines de bits, dans le temps imparti et dans toutes les conditions opérationnelles envisagées.

Schéma
Condition de Nyquist-Shannon

Un choix de conception limitant la période d’échantillonnage peut entraîner par opposition une perte du profil du signal. Une pratique, pour éviter cela, consiste à respecter la condition de Nyquist-Shannon (voir schéma ci-dessus) en prenant une fréquence d'échantillonnage supérieure au double de la fréquence maximum du signal numérisé. Si vous êtes intéressé, des ouvrages spécialisés vous donneront les réponses à vos questions sur le sujet.

Schéma
CAN et CNA

Nous avons donc, pour gérer nos signaux analogiques, des convertisseurs analogiques-numériques (ou CAN), des convertisseurs numériques-analogiques (ou CNA) et nos unités de traitement numérique.

En amont de ces convertisseurs CAN, chaque entrée est équipée d'un filtre anti-aliasing pour nettoyer le signal à numériser.

Chaque sortie est de son côté équipée d'un filtre de lissage en aval du convertisseur CNA pour améliorer la forme du signal analogique.

Des protections contre les effets indirects de la foudre, de type diode transil, et de nouveaux filtres contre les perturbations électromagnétiques conduites par les câbles sont également rajoutés en série sur chaque ligne pour protéger notre électronique embarquée.

Protections contre la foudre
Protections contre la foudre

Le capteur analogique qui renvoie la position du vérin de la servocommande est généralement de type LVDT. Ce type de capteur utilise un ensemble de signaux électriques qui se combinent pour extraire la position du vérin. Ces signaux sont conditionnés par un bloc électronique intégré dans notre calculateur. Ce capteur a la particularité d'être fiable et robuste à une utilisation dans des environnements sévères. Il est donc bien adapté à notre contexte.

Lorsque la gouverne est braquée vers le bas, le vérin est rentré. La position du LVDT est à sa valeur minimale et la tension résultante au plus bas. Lorsque le vérin se déplace, cette tension proportionnelle à la position absolue du vérin évolue.

Schéma
Schéma de loi de commande et asservissements

Pour ce qui nous concerne, suivons le schéma ci-dessus. Le signal analogique de commande émis par le pilote (via son manche ou son sidestick), reçu par la voie d'entrée analogique dédiée, est comparé à la position de la gouverne de profondeur. Une consigne de déplacement est alors donnée à la servocommande suivant une loi de commande prédéfinie, afin de positionner la gouverne au bon niveau de braquage. En vol, l'avion modifie alors sa situation en tangage. Ce changement est enregistré par les centrales inertielles via les ADIRS qui donnent à notre calculateur la nouvelle position à considérer. Cette position est de nouveau comparée à la consigne. Elle est traitée pour annuler et maintenir nul l'écart pouvant être observé.

Nous remarquons sur le schéma plusieurs boucles d'asservissement. La première assure que la servocommande suit la consigne de déplacement qui lui est demandée. La seconde assure que la gouverne se positionne et reste à la position désirée. La troisième assure que l’avion effectue la trajectoire voulue.

Les entrées/sorties ‘Tout ou Rien’ sont conditionnées suivant un format défini dans les standards de conception de l'avionneur (ils sont en général de type GND/OPEN, 28V/OPEN).

Le réseau AFDX / ARINC664

Réseau AFDX / ARINC664
Réseau AFDX / ARINC664

Les bus de communication suivants sont intégrés au calculateur. Nous considérons pour ce cas un bus ARINC664 via un port Ethernet 10/100 Base-T et un connecteur type quadrax (voir schéma ci-dessous).

Exemple
Schéma du bus de communication

Ces liaisons numériques sont de plus en plus utilisées au niveau système pour relier les équipements et les calculateurs. En effet, ils participent activement à la réduction de la longueur et de la masse du câblage et donc à la réduction de la complexité et de la masse de l'avion. Nous les prenons en compte dans notre architecture.

Les exigences de communication

La communication ARINC664 est utilisée dans notre cas pour dialoguer avec les autres calculateurs. La liaison RS422 est utilisée pour dialoguer avec la servocommande. La ligne Ethernet dédiée et la liaison RS232 sont utilisées pour le développement et les opérations de maintenance sur le calculateur.

L'architecture logicielle

Schéma
Architecture logicielle

Le microcontrôleur que nous retenons dans notre illustration est de type monocoeur. De dernière génération, il possède des modes de veille bien adaptés aux exigences de réduction de consommation électrique. L'intégration de fonctions de communication dans le composant participe à la réduction du volume souhaité du boîtier.

La possible utilisation d'un hyperviseur permet de gérer de façon robuste l'accès aux ressources matérielles du composant, permet de séparer les applications logicielles qu'elle héberge afin de limiter l'impact d'une erreur, permet de simplifier leur gestion et faciliter la production des preuves de conformité exigées pour la certification RTCA DO-178C/EUROCAE ED-12C qui est la terminologie européenne de ce standard.

Le choix des mémoires

Schéma
Mémoires

Les mémoires utilisées sont de type DDR2 S-RAM pour permettre à l'application de s'exécuter rapidement. Ces mémoires stockent les données temporaires de calcul, les variables et les buffers. Des mémoires de type Flash sont choisies pour stocker le code exécutable des applications et pour les configurations des IP FPGA.

Des timers sont utilisés pour contrôler la durée de certaines activités notamment pour séquencer des tests à l'allumage, et aussi pour détecter un ralentissement trop important des communications entre les processus en cours d'exécution.

Le FPGA

Schéma
Schéma du FPGA

Nous considérons plusieurs FPGA dans notre architecture. Ils ont pour objectif de décharger le processeur principal des tâches qui nécessitent l'utilisation de ressources processeurs permanentes ou une parallélisation intrinsèque des traitements. Ils répondent parfaitement à des besoins de performances temps réel (comme l'asservissement bas niveau de la servocommande). Ils améliorent également la maintenabilité de notre calculateur en rendant ces fonctions indépendantes de composants matériels spécifiques et, lorsque choisis en conséquence, moins soumis aux obsolescences et variations de délais d'approvisionnement ou de prix. Ils sont vus comme des mémoires pour le microcontrôleur.

Les connecteurs participent à la ségrégation physique des signaux électriques. Les connecteurs d'alimentation sont séparés des autres. Les connecteurs véhiculant les signaux de maintenance sont également spécifiques. Les connecteurs acceptent des contacts de type et de taille différents afin de pouvoir faire passer des signaux de nature et de puissance différentes à l'intérieur d'un même corps de connecteur, sans avoir à multiplier la connectique pour cela (ce seront les signaux d’E/S, commununication, interface de programmation JTAG).

Nous intégrons au boîtier des voyants afin de faciliter la maintenance par un premier niveau de diagnostic concernant l'état du calculateur (son alimentation, les communications, les codes d'erreurs).

La testabilité

Nous ne pouvons pas décrire un tel calculateur sans parler de sa capacité d'autodiagnostic et de gestion des fautes en support du processus de maintenance.

La notion de BITE (Built In Test Equipment) est utilisée pour décrire cette activité du calculateur. La stratégie consiste à déterminer les tests à réaliser à la mise sous tension de l'équipement (PBIT), en continu (CBIT) et lors de demandes ponctuelles externes (IBIT).

En continu (Continuous Built In Test – CBIT), le calculateur surveille ses alimentations électriques, la température interne du boîtier et effectue des comparaisons sur les signaux échangés. Nous définissons à cet effet un capteur de température, relié au bloc de surveillance, pour mesurer et gérer la conduite à tenir en cas d'élévation trop importante de la température à l'intérieur du calculateur.

Le comportement consiste à réduire les fréquences des horloges des processeurs et FPGA et mettre en ‘standby’ les composants non essentiels à la production de la consigne de pilotage. En cas de poursuite de l'emballement thermique, le calculateur est déclaré inopérant pour préserver l'intégrité future de ces composants et forcer au niveau système à activer les mécanismes de redondance.

Schéma
Schéma d'architecture autotestable et chiens de garde

Un chien de garde, également appelé ‘watchdog’, est placé sur chaque FPGA et sur chaque processeur. Il a pour objectif de vérifier leur vivacité. Il est conçu pour réinitialiser le composant auquel il est rattaché, si celui-ci ne lui envoie pas périodiquement un signal qui prouve qu'il n'est pas bloqué dans un état figé ou dans une boucle infinie.

La conduite à tenir en cas de problème doit être décrite et les mécanismes d'alerte à appliquer doivent être précisés.

Mécanisme de détection d'erreur
Mécanisme de détection d'erreur

En cas d'erreur détectée, une alerte est levée au niveau système et le calculateur invalidé. Les composants savent, grâce à des statuts internes, si l'initialisation est issue d'une coupure électrique normale ou du déclenchement du watchdog en urgence. Des décisions peuvent ainsi être prises pour invalider la sortie de pilotage et remonter l'information au système.

Les changements d'état, les données contextuelles et les décisions associées sont stockés et horodatés afin de tracer l'historique des dernières opérations réalisées par le calculateur et remonter la chaîne de décision en cas de besoin.

Les informations de maintenance sont envoyées au concentrateur des données de maintenance et sont analysées par les systèmes de maintenance.

Les informations de perte d'intégrité du signal de pilotage des servocommandes sont propagées directement vers les autres calculateurs et équipements impactés, afin qu'ils se reconfigurent en conséquence. L'alarme vers le cockpit est gérée par l'intermédiaire du système de gestion des alarmes de l'aéronef.

Les chaînes COM-MON sont isolées physiquement l'une de l'autre et leurs circuits sont dédiés. Des points de piquage sont toutefois consentis afin de pouvoir réaliser les activités de surveillance.

En résumé

Vous l'avez compris, développer un calculateur embarqué critique est aussi passionnant qu’affaire de spécialistes. Derrière chaque composant, chaque bloc, chaque fonction, chaque assemblage, des questions se posent. Si nos choix ne doivent pas impacter la sécurité des biens et des personnes, différentes solutions sont envisageables. Les critères de performance, de consommation électrique, de volume et de masse, mais aussi de complexité, coût, maintenabilité, pérennité sont à comparer pour déterminer le choix le plus pertinent.

Ces choix sont à justifier dans le référentiel documentaire technique. Ils participent à la mémoire du calculateur et facilitent ses évolutions. Nous décrirons, dans le prochain chapitre, les mécanismes de vérification de ces architectures.

En attendant, prenez un bol d'air, respirez, prenez le temps de décanter toutes ces informations.

À très vite...

Exemple de certificat de réussite
Exemple de certificat de réussite