Soutenance mémoire
DES SYSTEMES REACTIFS AUX SYSTEMES INTERACTIFS DANS LES COCKPITS
Les cockpits d’avion ont beaucoup évolué ces dernières années (Figure I.1). Dans les années 70 ils étaient principalement équipés d’instruments électromécaniques, on pouvait compter une centaine de cadrans mélangeant chiffres, aiguilles et symboles. Le besoin d’une meilleure présentation et intégration des informations nécessaires au pilotage et à la navigation a conduit à la planche de bord avec écrans. Ces évolutions permettent notamment la réduction de l’équipage de vol sur les avions commerciaux passant ainsi de trois personnes à deux.
Au niveau technologique, les premiers écrans sont de type cathodique comme sur les premiers cockpits de l’A320. Ils seront ensuite remplacés par des écrans à cristaux liquides (LCD). Pendant longtemps la planche de bord reste assez simple dans son utilisation, les écrans sont de simples systèmes de visualisation ne permettant aucune entrée d’information par l’équipage. Toutes les actions de commandes et/ou contrôle sont réalisés sur les boutons physiques situés de part et d’autre du cockpit, notamment sur le panneau plafond. Ce n’est qu’avec l’introduction de l’ARINC 661 et dès le programme A380 chez Airbus, que l’on voit apparaître des planches de bord ressemblant plus à des PC avec des notions de fenêtrage et l’utilisation du clavier et d’un dispositif de pointage pour interagir avec les écrans. L’équipage a maintenant la capacité de réaliser des contrôles sur les systèmes avions directement sur les écrans. Un exemple assez parlant est présenté à la Figure I.2, où à gauche le MCDU (Multipurpose Control and Display Unit) qui possède plusieurs fonctions pour la gestion du vol, a une zone d’affichage et des boutons poussoirs physiques tout autour. Il est aujourd’hui remplacé par la MFD (Multi Function Display) qui a une interface entièrement logicielle avec une capacité d’interaction avec le clavier et un dispositif de pointage.
Sur les Airbus A320, la gestion des entrées (commande sur les boutons poussoirs physiques) est entièrement ségréguée de la gestion des sorties (affichage des informations sur les écrans). A partir de l’A380, il y a une fusion de la gestion des entrées et des sorties, on parle maintenant de système d’affichage et de contrôle encore appelé CDS (Control and Display System), par rapport à l’ancienne architecture ce sont les systèmes avions qui sont maintenant responsable de l’animation de leur page affichée, ils intègrent notamment une nouvelle application logicielle appelée UA (User Applications) qui a en charge l’animation de leurs pages. Cette capacité d’interagir avec une interface entièrement logicielle et au travers des périphériques d’entrées tels que le clavier et un dispositif de pointage est encore aujourd’hui limitée au sein du cockpit à des fonctions dites non critiques. On retrouve ainsi une interface avec des zones accessibles par le curseur et des zones où l’utilisation du curseur est interdite. Cette limitation est due au fait que le système d’affichage et de contrôle est un système critique et il doit respecter des exigences de sûreté de fonctionnement et des règles de certification strictes (ARP4754, 1996) (DO-178B, 1992). Pourtant les besoins d’évolution existent, de nouvelles fonctions sont ajoutées au sein du cockpit, l’augmentation du trafic aérien nécessite une représentation de l’information encore plus intégrée pour une meilleure gestion par les pilotes. Au niveau des équipes de recherche au sein d’Airbus, des propositions sont depuis faites pour avoir des interactions tactiles et des représentations 3D donc pour avoir un niveau d’interaction logicielle encore plus large. Des réflexions sont menées pour réduire l’interface de contrôle physique et avoir plus de contrôle logiciel via l’écran. En effet l’utilisation du logiciel apporte plusieurs avantages par rapport au matériel que sont : la flexibilité de conception, par la facilité qu’on a avec le logiciel de redéfinir la position des objets sur une interface, de changer des couleurs etc. La configuration et la reconfiguration de l’information qu’il est difficile d’avoir sur les interfaces physiques, ceux-ci nécessitant un câblage assez lourd. Mais ces évolutions sont limitées dans leur intégration à cause des contraintes de sûreté.
LE STANDARD ARINC 661
L’ARINC 661 est un standard qui a été adopté par l’AEEC (Airlines Electronic Engineering commitee) en 2001 (ARINC661, 2010). Son objectif est de définir l’interface entre le système d’affichage et de contrôle (CDS) du cockpit et les autres applications des systèmes de l’avion. Il est rédigé par les principaux acteurs de l’aéronautique : Airbus, Boeing, Thales, Rockwell Collins, Honeywell, etc.… Les objectifs principaux du standard ARINC 661 sont :
● La minimisation des coûts d’ajout ou de modification d’une nouvelle fonction d’affichage pendant la durée de vie d’un avion (qui est d’une trentaine d’années pour les avions commerciaux) ;
● L’introduction de l’interactivité dans le cockpit, en mettant en place une base pour standardiser l’interface homme machine dans le cockpit ;
● de rendre les dispositifs plus faciles à utiliser, plus efficaces (en permettant l’affichage d’informations complexes dans les systèmes du bord).
● Minimiser le coût de gestion de l’obsolescence des composants matériel dans un environnement ou les évolutions technologiques sont rapides.
Le CDS fournit des services graphiques et interactifs aux applications utilisateurs (UA) au sein du cockpit. Les applications interactives sont exécutées sur des unités d’affichage appelées Display Unit (DU) et les interactions avec les pilotes se font par le biais de l’utilisation de périphériques physiques ou graphiques tel le Keyboard Cursor Control Unit (KCCU) qui est un ensemble clavier et dispositif de pointage .
L’ARINC 661 est basé sur une architecture Client-serveur avec une ségrégation entre la partie fonctionnelle gérée par les applications avions appelées UA et la partie graphique gérée par le CDS . L’ARINC 661 utilise un concept de fenêtrage qui est comparable à celui des PC mais avec des restrictions dues à l’environnement de l’avion .
● La base physique est l’écran encore appelé Display Unit
● L’écran est composé d’un ensemble de fenêtres (windows).
● Les fenêtres sont subdivisées en couches (layer).
● Les layers sont connectées aux UA et fournies un espace d’affichage des widgets
● Les widgets sont des objets pouvant avoir une représentation graphique sur lesquels les pilotes peuvent interagir. (exemple boutons, champ de texte …) .
Les UA spécifient dans un fichier appelé UADF (User Application Definition File) leur interface, en décrivant les caractéristiques des layers et des widgets ainsi que leur structure hiérarchique.
Le protocole de communication entre le CDS et l’UA est définit en deux phases :
● Une phase de définition où l’UA crée son fichier UADF décrivant son interface graphique. Le fichier UADF est ensuite chargé dans le CDS afin d’être instancié et les paramètres à l’initialisation sont activés.
● Une phase d’exécution qui consiste en un transfert dynamique de données entre l’UA et le CDS. L’UA peut mettre à jour les paramètres des widgets au travers des « setparameters », et le CDS notifie à l’UA des actions de l’utilisateur sur son interface au travers des « Event ».
L’ARINC 661 ne définit pas le « look and feel » des widgets, c’est-à-dire le rendu graphique des widgets (« look ») et le comportement des widgets (« feel »). Le document du standard définit une bibliothèque de widgets, leurs caractéristiques et le protocole de communication entre le CDS et les UAs. Les utilisateurs du standard doivent ensuite spécifier le comportement de leur widgets et de l’interface visà-vis des caractéristiques listées dans le standard.
Le standard ARINC 661 comprenait dans sa première version sortie en novembre 2001 près 42 widgets. Il a beaucoup évolué et compte aujourd’hui à son supplément 4 plus de 60 widgets.
|
Table des matières
Introduction
Chapitre I. Problématique
I.1 Des systèmes réactifs aux systèmes interactifs dans les cockpits
I.2 Le standard ARINC 661
I.3 Développement des systèmes avioniques critiques
I.3.1 La DO-178B
I.3.2 L’AMC 25-11
I.4 L’utilisabilité
I.5 Conclusion
Chapitre II. Etat de l’Art
II.1 Les systèmes interactifs
II.1.1 Modèle d’architecture seeheim
II.1.2 Modèle d’architecture Arch/ Slinky
II.2 Les techniques de description des systèmes interactifs
II.2.1 Technique de description de l’utilisateur
II.2.2 Technique de description de l’interface utilisateur
II.2.3 Technique de description de l’interaction en entrée
II.2.4 Technique de description du dialogue et du noyau fonctionnel
II.3 Un formalisme et un outil pour la description des systèmes interactifs
II.3.1 Les réseaux de Petri et Réseaux de Petri haut niveau
II.3.2 Les objets coopératifs interactifs
II.3.3 Les ICompoNets
II.3.4 L’environnement de travail PetShop
II.4 Les principes de base de La sûreté de fonctionnement
II.4.1 Les attributs
II.4.2 Les entraves à la sûreté de fonctionnement
II.4.3 Moyens de la sûreté de fonctionnement
II.4.4 La tolérance aux fautes
II.5 Synthèse et conclusion de l’état de l’art
Chapitre III. Approches proposées pour le développement de systèmes interactifs intégrant les aspects sûreté de fonctionnement et utilisabilité
III.1 Contexte applicatif au travail de la these
III.1.1 Architecture matérielle et logicielle du CDS
III.1.2 La description des widgets dans le standard ARINC 661
III.1.3 Sûreté de fonctionnement et certification sur les systèmes interactifs de cockpit
III.1.4 L’utilisabilité du CDS
III.1.5 Hypothèses et périmètre du travail de cette thèse
III.2 Principes de la méthode proposée
III.2.1 Les widgets au cœur de l’approche proposée
III.2.2 Approche vers une conception zéro défaut
III.2.3 Approche Tolérance aux fautes
III.2.4 Les modèles de tâches
III.3 Conclusion
Chapitre IV. Application de l’approche vers la conception zéro défaut et impact sur l’utilisabilité
IV.1 Présentation de l’etude de cas et de son environnement de modélisation
IV.1.1 Définition informelle de l’étude de cas
IV.1.2 Architecture logicielle de modélisation de l’étude de cas
IV.2 Modélisation du comportement des widgets
IV.2.1 Modélisation du comportement d’un widget
IV.2.2 Exemple de modélisation du comportement de certains widgets
IV.3 Modélisation du comportement de l’UA FCU
IV.3.1 Modélisation du comportement de la Page EFIS CP
IV.3.2 Gestion de la page AFS CP
IV.4 Analyse des modèles de tâche
IV.5 conclusion
Conclusion
