Nouvelles technologies pour le contrôle/commande d ...masterihm.pbworks.com/f/rapport_merlet_v1.6.pdf · Rapport de stage - Nouvelles technologies pour le contrôle/commande d’instruments

Année 2008-2009

Master 2 Pro IInteraction HHomme-MMachine

Nouvelles technologies pour le contrôle/commande d’instruments médicaux

Mémoire de fin d’études

PPhhiilléémmoonn MMEERRLLEETT

Rapport de stage - Nouvelles technologies pour le contrôle/commande d’instruments médicaux

Philémon MERLET 2 / 69

Résumé Ce rapport présente le stage de fin d’études du Master2 pro IHM que j’ai effectué au CNES

(Centre National des Etudes Spatiales), au Centre Spatial de Toulouse. Il s’agissait de préparer l’évolution d’un outil de suivi du système cardio-vasculaire des astronautes { bord d’une station spatiale, avec comme axes d’amélioration : la maintenance, l’évolutivité et la modularité ; l’ergonomie ; la performance des mesures.

J’ai donc eu l’occasion d’étudier et de choisir des technologies portant sur tous les aspects de l’application, depuis la communication avec les instruments de mesure sélectionnés par les scientifiques, jusqu’{ une description des interfaces homme-machine dans un format facilitant l’échange des données.

Parallèlement, j’ai repris les principaux éléments de l’interface du système existant, tout en m’efforçant d’améliorer les aspects les plus problématiques par le biais d’un processus de conception centrée utilisateurs.

Mots-clés Contrôle/Commande, Instruments médicaux, Impesanteur, Système cardio-vasculaire,

Médecine scientifique, Station spatiale, Station Spatiale Internationale (ISS), Astronaute, Médecin, Conception centrée utilisateur, Evaluation ergonomique, Prototypage, Java, Swing, SwiXML, Java2d, Best, Octave, Joram, JavaComm

Abstract This report presents my end-of-studies internship for the professional Human-Computer

Interactions Master2, which took place at the CNES (French Spatial Studies Center). The purpose was to prepare the evolution of a space station astronauts’ cardio-vascular system following tool, with, as improvements : maintenance, evolutivity and modularity ; ergonomics ; measurements performance.

It was for me an opportunity to study and choose technologies covering all the aspects of the application, from communication with medical instruments selected by scientists, to a human-computer interfaces description format allowing easy data exchange.

In parallel, I remade the existing system’s interface main elements, while trying to improve the problematic points through a user-centered conception process.

Keywords Control/Command, Medical instruments, Weightlessness, Cardiovascular system, Scientific

medicine, Space station, International Space Station (ISS), Astronaut, Doctor, User-centered conception, Ergonomic evaluation, Prototyping, Java, Swing, SwiXML, Java2d, Best, Octave, Joram, JavaComm



Remerciements Je tiens tout d’abord à remercier mon maître de stage, Jean-Christophe LLORET, et le chef de

projet, Patrick AUBRY, pour avoir rendu ce stage possible et m’avoir guidé et soutenu durant ces 5 mois, ainsi que mon tuteur pédagogique Philippe PALANQUE pour son aide.

Je remercie également Jullian LOPEZ, support procédures au CADMOS, qui a accepté à plusieurs reprises de me faire bénéficier de son expertise, ainsi que Marc-Antoine CUSTAUD, médecin-chercheur de l’hôpital d’Angers, qui s’est révélé être un utilisateur particulièrement enthousiaste.

Mes remerciements vont ensuite aux équipes du CNES que j’ai sollicitées pour les besoins du stage et dont l’aide m’a été précieuse, en particulier Denis MINGUILLON (Best), David FAILLEFER et Marie SAUVAUD (Octave), et Erwann POUPART (MAL/Joram). Je dois également mentionner l’équipe de la société Erems, en particulier Louis NGUYEN et Sébastien BAX.

Je remercie enfin toutes les équipes du CADMOS, du MEDES et de DECLIC, pour leur accueil chaleureux et leur bonne humeur, qui ont contribué à rendre ces 5 mois de stage très agréables.



Table des matières Résumé ................................................................................................................................................................................................ 2 Mots-clés ............................................................................................................................................................................................ 2 Abstract ............................................................................................................................................................................................... 2 Keywords ........................................................................................................................................................................................... 2 Remerciements ................................................................................................................................................................................ 3 Table des matières ......................................................................................................................................................................... 4 Table des illustrations .................................................................................................................................................................. 6 Table des annexes .......................................................................................................................................................................... 7 Introduction ...................................................................................................................................................................................... 8 Partie 1 : Contexte du stage ....................................................................................................................................................... 9

1.1. Le CNES ................................................................................................................................................................................. 9 1.2. Le service Planétologie et Micropesanteur .......................................................................................................... 9

Partie 2 : Présentation du projet ............................................................................................................................................. 9 2.1. Le projet Cardiomed ....................................................................................................................................................... 9

2.1.1. Présentation générale .................................................................................................................................. 9 2.1.2. Détails des objectifs ................................................................................................................................... 10 2.1.3. Description du système............................................................................................................................ 10

2.2. Le projet SEVE ................................................................................................................................................................ 15 2.2.1. Présentation générale ............................................................................................................................... 15 2.2.2. SEVE et Cardiomed .................................................................................................................................... 15 2.2.3. Instruments ................................................................................................................................................... 16

Partie 3 : Présentation et déroulement du stage ........................................................................................................... 16 3.1. Présentation .................................................................................................................................................................... 16

3.1.1. L’ergonomie des interfaces et des moyens d’interactions ....................................................... 16 3.1.2. Les moyens de configuration de l’interface par les équipes opérationnelles : ............... 16 3.1.3. La communication avec les instruments .......................................................................................... 17

3.2. Objectifs ............................................................................................................................................................................. 17 3.2.1. Objectifs pour le CNES .............................................................................................................................. 17 3.2.2. Objectifs pédagogiques ............................................................................................................................ 17

3.3. Environnement .............................................................................................................................................................. 17 3.4. Organisation .................................................................................................................................................................... 18

3.4.1. Livrables du stage ....................................................................................................................................... 18 3.4.2. Démarche ....................................................................................................................................................... 19 3.4.3. Planification .................................................................................................................................................. 19

Partie 4 : Analyse préliminaire .............................................................................................................................................. 20 4.1. Utilisateurs et environnements de travail ......................................................................................................... 20

4.1.1. Edition de protocoles ................................................................................................................................ 20 4.1.2. Mode sol .......................................................................................................................................................... 21 4.1.3. Mode bord ...................................................................................................................................................... 22

4.2. Etude de l’existant ........................................................................................................................................................ 23 4.2.1. Démarche ....................................................................................................................................................... 23 4.2.2. Evaluation ergonomique ......................................................................................................................... 23 4.2.3. Interview d’un utilisateur du mode sol ............................................................................................. 25 4.2.4. Retours des utilisateurs du mode bord............................................................................................. 27

4.3. Scenarii de travail ......................................................................................................................................................... 28 4.3.1. Scénario 1 : Utilisation nominale ......................................................................................................... 28 4.3.2. Scénario 2 : Utilisation avec non-respect de la procédure ....................................................... 30 4.3.3. Scénario 3 : Utilisation avec non-respect de la procédure et erreur du système .......... 30

4.4. Evaluation de l’adaptation des procédures utilisées par l’ESA { SEVE ................................................. 31 Partie 5 : Evaluation de technologies de commande et d’acquisition de mesures ......................................... 33

5.1. Méthodologie .................................................................................................................................................................. 33 5.2. Ateliers Best et Octave ................................................................................................................................................ 33

5.2.1. Présentation des plateformes Best et Octave ................................................................................. 33 5.2.2. Evaluation de l’outil Best ......................................................................................................................... 34 5.2.3. Evaluation des outils Octave .................................................................................................................. 36



5.2.4. Conclusion générale .................................................................................................................................. 38 5.3. Joram .................................................................................................................................................................................. 38

5.3.1. Présentation de Joram .............................................................................................................................. 38 5.3.2. Utilité ................................................................................................................................................................ 39 5.3.3. Facilité d’utilisation ................................................................................................................................... 39 5.3.4. Performances................................................................................................................................................ 39 5.3.5. Conclusion ...................................................................................................................................................... 39

Partie 6 : Conception de l’application interactive ......................................................................................................... 39 6.1. Déroulement de protocoles médicaux ................................................................................................................. 39

6.1.1. Focus group sur le suivi des procédures opérationnelles ........................................................ 39 6.1.2. Prototypage sur la hiérarchisation des informations ................................................................. 45 6.1.3. Système de pages d’aide .......................................................................................................................... 48

6.2. Visualisation des informations physiologiques ............................................................................................... 50 6.2.1. Prototype sur la visualisation des informations ........................................................................... 51 6.2.2. Aspect des synoptiques ............................................................................................................................ 51 6.2.3. Navigation sur les courbes de visualisation.................................................................................... 52 6.2.4. Alarmes physiologiques ........................................................................................................................... 53 6.2.5. Marqueurs temporels ............................................................................................................................... 53

Partie 7 : Réalisation du prototype fonctionnel ............................................................................................................. 53 7.1. Technologies ................................................................................................................................................................... 53

7.1.1. Contrôle/commande des instruments .............................................................................................. 53 7.1.2. Interfaces ........................................................................................................................................................ 54 7.1.3. Composants graphiques .......................................................................................................................... 57 7.1.4. Définition des protocoles et des fichiers astronautes ................................................................ 57

7.2. Conception logicielle.................................................................................................................................................... 58 7.2.1. Communication avec les instruments (noyau fonctionnel) ..................................................... 58 7.2.2. Architecture générale de l’application .............................................................................................. 60

Partie 8 : Bilan ............................................................................................................................................................................... 64 8.1. Contributions au projet .............................................................................................................................................. 64

8.1.1. Déroulement ................................................................................................................................................. 64 8.1.2. Réalisations ................................................................................................................................................... 64 8.1.3. Utilisation du prototype........................................................................................................................... 66

8.2. Apport du Master2 IHM durant le stage ............................................................................................................. 66 8.3. Bilan personnel .............................................................................................................................................................. 67

Glossaire .......................................................................................................................................................................................... 68 Références et bibliographie .................................................................................................................................................... 69



Table des illustrations

Figures

Figure 1 : Cardiopres ............................................................................................................................................ 11 Figure 2 : Boîtier et brassard HLTA ............................................................................................................... 11 Figure 3 : Page de présentation des instruments ..................................................................................... 12 Figure 4 : Page d'instructions pour l'installation du HLTA .................................................................. 13 Figure 5 : Page de vérification du Cardiopres ............................................................................................ 13 Figure 6 : Page d'expérimentation en mode sol ........................................................................................ 14 Figure 7 : Page de transfert des données ..................................................................................................... 14 Figure 8 : Work Breakdown Structure (WBS) ........................................................................................... 18 Figure 9 : Diagramme de Gantt adopté pour le stage ............................................................................. 19 Figure 10 : Logs de Cardiomed ......................................................................................................................... 24 Figure 11 : Page de connexion d'un instrument (CDPB) ....................................................................... 28 Figure 12 : Extrait d'une procédure respectant la norme ODF........................................................... 31 Figure 13 : Capture d'écran de l'application OASIS ................................................................................. 35 Figure 14 : Principe de fonctionnement de Joram ................................................................................... 38 Figure 15 : Prototype présenté lors du focus group (checkpoints) .................................................. 41 Figure 16 : Prototype présenté lors du focus group (mise en valeur des informations) ......... 41 Figure 17 : Prototype montrant l'utilisation d'images ........................................................................... 45 Figure 18 : Prototype montrant un mécanisme de cases à cocher.................................................... 46 Figure 19 : Prototype sur l'automatisation des vérifications .............................................................. 46 Figure 20 : Prototype sur la mise en forme des instructions .............................................................. 47 Figure 21 : Prototype fonctionnel sur la visualisation des paramètres .......................................... 51 Figure 22 : Fichier XML décrivant la page d'expérimentation ............................................................ 56 Figure 23 : Page d'expérimentation générée à partir du fichier XML .............................................. 56 Figure 24: Description XML du protocole implémenté .......................................................................... 58 Figure 25 : Affichage de la page d'aide "10110" (placement des électrodes) .............................. 59 Figure 26: Classes d'une application utilisant Joram .............................................................................. 60 Figure 27: Classes du prototype final ............................................................................................................ 62 Figure 28 : Vérification globale de l'ECG et vue détaillée d'une des pistes .................................... 63 Figure 29 : Diagramme de Gantt réel............................................................................................................. 64

Tableaux

Tableau 1: Gestion des risques liés au projet ............................................................................................. 20 Tableau 2 : Adaptation de certains points de la norme ODF à Cardiomed et SEVE ................... 33 Tableau 3 : Récapitulatif des solutions possibles sur la hiérarchisation des informations .... 44 Tableau 4 : Principaux choix réalisés durant le stage............................................................................. 65



Table des annexes

Annexe Nom Page des annexes

Annexe 1 Analyse de l’existant p. 2

Annexe 2 Evaluation des plateformes Best et Octave dans le cadre d’une utilisation pour SEVE

p. 7

Annexe 3 Evaluation de l’intérêt de la norme ODF dans le cadre de SEVE p. 27

Annexe 4 Interview de Marc-Antoine Custaud sur l’ergonomie du logiciel Cardiomed p. 30



Introduction Dans le cadre du master 2 professionnel Interactions Homme-Machine, un stage de fin

d’études permet de valider et d’utiliser dans un contexte professionnel les techniques et méthodes acquises durant l’année. C’est ainsi que j’ai effectué un stage de 5 mois au CNES (Centre National d’Etudes Spatiales), au Centre Spatial de Toulouse.

Intégré { l’équipe des projets Cardiomed et SEVE, au sein du service Planétologie et

Micropesanteur (DCT/PO/PM), j’ai pu, en collaboration avec les partenaires industriels et les services du CNES, participer { l’élaboration de la nouvelle génération d’un outil de suivi du système cardio-vasculaire des astronautes.



Partie 1 : Contexte du stage

1.1. Le CNES

Le CNES est un établissement public à caractère industriel et commercial chargé de proposer et de mettre en œuvre la politique spatiale de la France. Il conçoit des systèmes spatiaux, maîtrise l’ensemble des techniques spatiales, et garantit { la France l’accès autonome à l’espace : c’est un acteur majeur de l’Europe spatiale.

Créé en 1961, il compte aujourd’hui plus de 2400 salariés, répartis sur 4 centres : le siège de l’établissement à Paris, la direction des lanceurs à Evry, le centre spatial guyanais à Kourou, et enfin le centre spatial de Toulouse. C’est ce dernier le plus important, avec près de 1700 salariés.

Pour mener { bien les programmes qu’il conçoit, le CNES collabore avec de nombreux

partenaires, scientifiques et industriels. Il est également engagé dans plusieurs coopérations internationales : il assure la participation de la France à l’Agence Spatiale Européenne (European Space Agency, ESA), mais collabore également avec les agences russe (RKA), américaine (NASA)…

1.2. Le service Planétologie et Micropesanteur

Il s’agit du service chargé de la conduite des projets relatifs à la planétologie et aux sciences en micropesanteur, y compris l’utilisation de l’ISS.

Pour les projets soumis par les laboratoires scientifiques, il contribue { l’évaluation des propositions sous les aspects techniques, calendaires et organisationnels.

Dans le cadre de programmes soutenus par le CNES, il assure un support technique aux laboratoires scientifiques travaillant dans ce domaine.

Partie 2 : Présentation du projet Le stage s’inscrit dans le cadre de 2 projets du service PO/PM : Le projet Cardiomed, qui se termine en 2009, qui sert de référence et de moyen

d’évaluation de l’existant Le projet SEVE, en phase d’étude, à laquelle le stage contribue.

2.1. Le projet Cardiomed

2.1.1. Présentation générale

Cardiomed est un ensemble d’expériences pour mesurer l’impact de l’environnement en micropesanteur sur le corps humain, avec deux objectifs principaux :

Le suivi médical des cosmonautes sur l’ISS L’étude scientifique du système cardio-vasculaire et de son évolution en

micropesanteur. Il est développé dans le cadre d’une convention franco-russe entre le CNES et l’IBMP

(Institute for Bio-Medical Problems) : le CNES a la responsabilité du développement, de la qualification et de la fourniture du système C ardiomed, tandis que l’IBMP a la charge de la recette du système et de son emport sur l’ISS à bord du vaisseau cargo russe Progress.

Démarré en 2000 (signature de la convention franco-russe sur le développement du

système Cardiomed), il est actuellement en phase de recette finale à Moscou et devrait être embarqué { bord de l’ISS à la fin 2009.



2.1.2. Détails des objectifs

2.1.2.a. Suivi médical

Les astronautes effectuant de longs séjours dans des stations orbitales souffrent, à leur retour sur terre, de problèmes cardiovasculaires liés { l’apesanteur, principalement un manque de tolérance à la station debout, pouvant entraîner des syncopes. En effet, sur terre, la gravité entraîne une certaine quantité de sang dans les jambes ; mais, en apesanteur, les jambes n’ont plus besoin d’autant de sang, et le système cardio-vasculaire s’adapte très rapidement en faisant remonter 1,5 litres de sang dans la partie supérieure du corps. Lors du retour sur terre, tout le sang qui baignait le haut du corps redescend dans les jambes, entraînant une énorme modification de la tension.

Plusieurs sortes de contre-mesures sont utilisées pour prévenir ces effets et préparer les astronautes au retour sur terre, en particulier des exercices musculaires comme le vélo ergomètre, mais aussi, pour les cosmonautes russes, le LBNP (Low Body Negative Pressure), un cylindre étanche relié à une pompe à vide dans lequel les cosmonautes placent leurs jambes. Une baisse de pression effectuée par paliers oblige alors le sang situé dans le haut du corps à revenir vers les jambes.

Cardiomed fournit diverses informations physiologiques sur la réponse du système cardio-vasculaire { ces changements, permettant ainsi d’anticiper ce qui se passera lors du retour sur terre de chaque cosmonaute.

Il permet également à des médecins de suivre en temps réel, depuis le sol, les données physiologiques acquises par les instruments, notamment pour les exercices de type LBNP, qui présentent un risque pour la santé du cosmonaute et nécessitent donc une surveillance médicale.

2.1.2.b. Objectifs scientifiques

De manière générale, par le biais des mesures acquises durant les protocoles mis en œuvre, Cardiomed permet aux médecins scientifiques d’acquérir une meilleure connaissance du fonctionnement du système cardio-vasculaire. Cette connaissance ouvre la voie à la mise en place d’une meilleure préparation des astronautes au retour sur terre durant les vols habités, contribuant donc au progrès de la médecine spatiale.

Elle aura également des retombées sur les recherches en physiologie humaine, par exemple sur la compréhension du fonctionnement vasculaire des membres inférieurs. Elle devrait ainsi contribuer { l’élaboration de protocoles permettant de prévenir les troubles cardio-vasculaires (par exemple, l’hypotension orthostatique, dont souffrent 30% des personnes âgées)

2.1.3. Description du système

2.1.3.a. Composition

Le système Cardiomed est en charge de l’affichage des protocoles médicaux, de la commande des instruments, de l’acquisition et du stockage des mesures. A ce titre, il comprend :

Un ensemble d’instruments scientifiques, dérivés d’appareils existant dans le commerce, utilisés dans diverses configurations selon les objectifs de l’expérimentation

Un boîtier central qui gère l’alimentation des instruments et centralise l’acquisition des données

Un ordinateur portable (laptop), relié au boîtier central, qui contient le logiciel permettant le déroulement des protocoles et la commande des instruments, et sur lequel sont stockées toutes les données acquises durant les expériences



2.1.3.b. Instruments médicaux

Les instruments médicaux gérés par Cardiomed sont, pour certains, des instruments que l’on retrouve dans d’autres projets portant sur la médecine (en particulier Cardiolab), pour d’autres des instruments plus spécifiques. On trouve donc :

Le TCHIBIS, un pantalon de dépression (LBNP) Le Cardiopres (Figure 1), utilisé sur Cardiolab, composé d’une ceinture respiratoire

mesurant la respiration { 50 Hz, d’un ElectroCardioGramme (ECG) 1 { 12 dérivations (électrodes) effectuant des mesures { 1000 Hz, et d’un doigtier mesurant la pression artérielle à 200 Hz.

Figure 1 : Cardiopres

Un Scanner Doppler, qui mesure la vitesse du sang dans les artères Le HLTA (Figure 2), boîtier portable de mesure de pression artérielle sur 24h (mesure

par brassard)

Figure 2 : Boîtier et brassard HLTA

Le HLTE, boîtier portable de mesure ECG sur 1 ou 2 dérivations L’APLT (Air PLeThysmograph) qui mesure les variations de volume des membres (bras,

jambe) en fonction des occlusions veineuses appliquées

2.1.3.c. Fonctionnalités

2.1.3.c.1) Protocoles médicaux

Les expérimentations prises en charge par Cardiomed reposent sur des protocoles médicaux élaborés par les médecins scientifiques russes et français impliqués dans le projet, que les cosmonautes devront appliquer en vol. Le système Cardiomed a été conçu pour apporter un support au déroulement de ces protocoles : avant et après la phase d’expérimentation, une



succession de pages d’instructions aide, pas { pas, les cosmonautes { mettre en œuvre le protocole choisi.

Ainsi 5 phases sont décrites. Déballage des instruments (Figure 3) : Initialement, tous les instruments nécessaires

aux protocoles sont rangés dans des boîtes rembourrées, disposées dans le laboratoire. Cette phase permet de vérifier que tous les instruments sont bien disponibles, et de les retirer un à un.

Figure 3 : Page de présentation des instruments

Configuration (Figure 4, Figure 5) : Durant cette phase, l’astronaute va installer,

initialiser et calibrer l’un après l’autre tous les instruments utilisés au cours du protocole.

Expérimentation (Figure 6) : il s’agit de la phase de l’exercice proprement dit. Après s’être assuré que tous les instruments fonctionnent bien (phase précédente), l’astronaute va effectuer l’activité demandée par la procédure : exercice sur vélo ergomètre, mise en marche de l’instrument LBNP, ou simplement déambulation sur une longue période. Durant cette phase, Cardiomed se charge d’acquérir toutes les mesures utiles.

Désinstallation (Figure 7) : Après l’expérience, l’astronaute débranche tous les appareils, et au besoin transfère à la station sol les données acquises pendant l’exercice, à des fins de post-traitement.

Rangement : L’astronaute range tous les instruments et ferme le programme.



Figure 4 : Page d'instructions pour l'installation du HLTA

Figure 5 : Page de vérification du Cardiopres



Figure 6 : Page d'expérimentation en mode sol

Figure 7 : Page de transfert des données



Durant chaque phase, deux types de pages sont distingués : des pages dynamiques de

configuration des instruments (Figure 5, Figure 6, Figure 7), et des pages statiques, décrites en HTML, dont la mise en forme est définie par une feuille css (Figure 3, Figure 4, Figure 7).

2.1.3.c.2) Contrôle/commande des instruments

Cardiomed gère, à travers le boîtier central connecté au laptop, la communication avec les instruments. Le programme automatise autant que possible les protocoles de communication, par exemple en initialisant les instruments sans qu’aucune commande ne soit nécessaire de la part de l’utilisateur.

2.1.3.c.3) Suivi des expériences en temps réel

Dans sa version sol, Cardiomed permet la surveillance médicale des expériences depuis un centre de contrôle, en affichant en temps réel les mesures acquises par les instruments.

Dans cette version, les protocoles sont également déroulés avant l’expérience, afin que les opérateurs aient un rappel des actions effectuées par l’astronaute, et puissent l’assister si nécessaire.

Une page de visualisation des mesures acquises par les instruments est ensuite affichée. Elle reprend les éléments affichés sur la page d’expérimentation en mode bord, et peut également contenir d’autres modes de visualisation (affichage des valeurs sur une plus longue période, valeur dérivée supplémentaire…), utilisés par les médecins pour interpréter l’état de santé de l’astronaute.

2.1.3.c.4) Suivi des expériences en temps différé

Une fonction de rejeu permet de répéter le déroulement d’une expérience, { partir des mesures enregistrées pendant la session temps réel.

2.1.3.c.5) Stockage des données

Cardiomed gère l’acquisition de toutes les mesures acquises par les instruments durant l’expérience, et leur stockage dans un format spécifique utilisé pour la transmission de ces données vers le sol.

2.2. Le projet SEVE

2.2.1. Présentation générale

SEVE est un projet en fin de phase A (étude préliminaire). Il s’agit d’une coopération franco-chinoise portant sur un système semblable à Cardiomed. Comme pour Cardiomed, le CNES aurait la responsabilité du développement, de la qualification et de la fourniture du système, tandis que la partie chinoise aurait la charge de son emport sur sa future station orbitale.

Les résultats scientifiques seraient exploités, du côté français, par les mêmes médecins scientifiques qui ont participé à Cardiomed, des universités de Tours et d’Angers. L’entreprise EREMS a réalisé l’étude de faisabilité de phase A de novembre 2008 { mai 2009.

2.2.2. SEVE et Cardiomed

SEVE a globalement les mêmes objectifs que Cardiomed, et les spécifications de base du système sont les mêmes. De fait, le développement de SEVE doit hériter de l’expérience acquise et des instruments et logiciels développés dans le cadre de Cardiomed.

Toutefois, le système SEVE doit être novateur vis-à-vis de Cardiomed. Les améliorations doivent notamment porter sur :



Les domaines d’étude de la physiologie et les mesures de nouveaux paramètres L’amélioration des performances en termes de masse et d’encombrement La modularité (configuration des instruments, évolutivité du logiciel) Les performances de la mesure et la qualité des signaux L’ergonomie des Interfaces Homme-Machine Le système de traitement des données

2.2.3. Instruments

Les instruments utilisés sur SEVE doivent être au minimum aussi performants que ceux qui sont utilisés par Cardiomed. Les instruments sélectionnés pour SEVE et validés par les médecins scientifiques sont pour le moment :

Le doigtier CNAPTM, développé par CNSystems (Autriche), qui mesure la pression sanguine en continu

Le brassard HLTA, déjà utilisé sur Cardiomed, qui mesure la tension Un ECG 12 dérivations développé par CorScience (USA) Un échographe Un laser Doppler Un Doppler ultrason Dans le cadre du stage, seuls les 3 premiers instruments étaient disponibles.

Partie 3 : Présentation et déroulement du stage

3.1. Présentation

Ce stage, qui s’inscrit dans le projet SEVE, doit permettre d’étudier les améliorations technologiques correspondant aux nouvelles exigences en termes de performance et d’interfaces.

3 points en particuliers sont à améliorer.

3.1.1. L’ergonomie des interfaces et des moyens d’interactions

Les fonctionnalités offertes par SEVE étant les mêmes que celles de Cardiomed, il faut analyser l’utilisabilité de ce dernier, et, pour chaque problème rencontré, proposer une alternative plus pertinente. En particulier pour le mode vol, la solution peut passer par de nouveaux modes d’interaction de l’astronaute avec le système.

3.1.2. Les moyens de configuration de l’interface par les équipes opérationnelles :

Il faut étudier les différentes technologies permettant de faciliter le développement d’un outil d’édition de protocoles médicaux, afin de pouvoir facilement créer ou modifier ces protocoles.

Ceci concerne les pages statiques, qui décrivent les actions à effectuer, pour le moment éditées en html : il faudrait un cadre contraignant plus strictement la rédaction, afin de s’assurer que les protocoles obtenus soient conformes aux spécifications.

Les pages dynamiques, qui permettent d’envoyer des commandes aux instruments et de visualiser les mesures, devraient également être concernées : il faudrait que des utilisateurs non informaticiens puissent définir des pages de calibration des instruments et des pages de déroulement d’expérience, à travers un éditeur de pages dédié. Dans le cadre du stage, il s’agit surtout d’étudier les technologies de description d’interface permettant la mise en place d’un tel éditeur.



3.1.3. La communication avec les instruments

Il s’agit d’étudier les solutions permettant de communiquer avec des instruments et d’envoyer les mesures vers le sol, alors que certains instruments communiquent 12 dérivations différentes à une fréquence de 1000 Hz. De plus, toujours dans un souci de maintenance et d’évolutivité, ces solutions doivent rendre l’architecture du système plus facile { appréhender.

Plusieurs stages concernant le contrôle et la commande des instruments via les technologies

Web ont déjà été effectués dans le cadre de SEVE ou de Cardiomed, on doit donc maintenant évaluer la pertinence de ces solutions avec ces nouveaux instruments.

Il est également nécessaire de se tenir informé des outils en usage au CNES qui pourraient répondre à ce besoin, et d’évaluer ceux qui seraient retenus.

3.2. Objectifs

3.2.1. Objectifs pour le CNES

Pour que le stage soit utile et exploitable sur le projet SEVE, les résultats attendus sont : Une étude des technologies envisageables pour chaque amélioration à apporter,

expliquant les spécificités de chacune, ses avantages et inconvénients au regard du projet, et éventuellement une décision raisonnée sur l’intégration ou non de cette solution.

Des spécifications d’interfaces répondant au besoin d’amélioration par rapport { Cardiomed

Un prototype fonctionnel, mettant en œuvre les solutions retenues, avec un protocole médical portant sur les instruments disponibles : le CNAP, le HLTA, et l’ECG.

3.2.2. Objectifs pédagogiques

Pour que le stage soit valorisable en regard du diplôme que je prépare, il est important qu’il me permette de mettre en œuvre, au-delà des aspects techniques, les méthodologies acquises durant l’année.

En particulier, il est intéressant d’appliquer une démarche de conception centrée utilisateur à ce projet. En effet, cette démarche, qui place l’utilisateur au centre du processus de conception, donne en général de bons résultats, et peut donc aider à couvrir le besoin de la facilité d’utilisation, qu’il s’agisse des modes bord ou sol, ou encore des outils de développement.

Il s’agit donc d’atteindre les objectifs précédents, mais par le biais d’une démarche de

conception centrée utilisateurs. Dès lors, si ces deux points sont vérifiés, on pourra considérer que le stage est une réussite.

3.3. Environnement

Le stage se déroule en relation étroite avec le maître de stage, Jean-Christophe LLORET, et le chef de projet, Patrick AUBRY. Des contacts avec les médecins scientifiques impliqués dans le projet ont aussi lieu régulièrement.

Il est également possible de solliciter les équipes du CNES extérieures au projet, mais dont les connaissances peuvent nous aider ; en particulier, le stage se déroulant dans les mêmes locaux que le CADMOS (Centre d’Aide au Développement des activités en Micropesanteur et des Opérations Spatiales), qui prépare et supervise certaines des opérations qui ont lieu sur l’ISS, il est tout-à-fait envisageable de solliciter régulièrement cette équipe.



3.4. Organisation

3.4.1. Livrables du stage

La Work Breakdown Structure (WBS, voir Figure 8) décrit les livrables correspondant aux objectifs définis au 3.2.

La partie Analyse correspond aux documents résumant l’étude des domaines qui touchent au stage. Cette partie doit permettre d’acquérir une meilleure compréhension du sujet et des problématiques qu’il soulève.

La partie Conception correspond { la mise en œuvre de la démarche choisie pour résoudre ces problématiques. Les documents présents dans cette partie doivent permettre de comprendre tous les choix effectués durant le stage.

La partie Réalisation correspond au logiciel développé et au rapport final, remis au CNES et { l’équipe pédagogique.

Figure 8 : Work Breakdown Structure (WBS)

WBS

Analyse Conception Réalisation

Etude ergonomique de CARDIOMED

Maquettes papier

Etude sur l’utilisation de logiciels en vol

Evaluation des maquettes papier

Compte-rendu des séances de conception

Etude IHM de Contrôle/Commande

Etude technologies de Contrôle/Commande

Comptes-rendus des évaluations de prototypes

Prototypes intermédiaires

Prototype final

Rapport final

Etude procédures opérationnelles en sciences de la vie

Règles de définition des procédures

opérationnelles

Etude outils d’édition de procédures

Etude outils d’édition d’IHM

Evaluation des architectures et outils

envisagés

Dossier d’architecture logicielle



3.4.2. Démarche

Si tout ce qui concerne la communication entre l’application et les instruments médicaux peut être traité à-peu-près indépendamment du reste, l’adoption d’un processus de conception centré utilisateur impose une certaine forme de développement au projet.

Ainsi, une fois l’analyse des besoins et du contexte effectuée, commence une série de cycles de conception, passant par une définition de problématiques, une génération de solutions, un prototypage de ces solutions et une évaluation par les utilisateurs, qui peut ensuite générer de nouvelles problématiques.

3.4.3. Planification

3.4.3.a. Diagramme de Gantt

Le diagramme de Gantt (Figure 9) représente la planification prévue pour la réalisation des différentes phases du projet.

Figure 9 : Diagramme de Gantt adopté pour le stage

3.4.3.b. Gestion des risques

Le Tableau 1 décrit les principaux risques identifiés comme pouvant compromettre le bon déroulement du stage, en particulier concernant la disponibilité des utilisateurs et l’utilisation des technologies.

La colonne « Prévention » décrit les méthodes mises en œuvre pour éviter que ces risques ne se réalisent, et la colonne « Alternative » indique comment les surmonter s’ils surviennent malgré tout.



Risque Probabilité Prévention Alternative

Disponibilité restreinte des utilisateurs au sol

Moyenne Prévoir les réunions au moins une semaine à l’avance, bien préparer les entretiens

Avoir recours au téléphone et { l’e-mail, utiliser des pseudos-utilisateurs

Indisponibilité des utilisateurs en vol

Très élevée Solliciter des retours d’utilisateurs dès que possible

S’inspirer d’études ou de retours d’expérience réalisées pour des systèmes similaires, travailler avec des spécialistes du domaine

Pas de données pour l’utilisation réelle en vol

Très élevée S’inspirer d’études ou de retours d’expérience réalisées pour des systèmes similaires, travailler avec des spécialistes du domaine

Avoir recours à une pseudo-analyse ergonomique

Difficultés pour appréhender les technologies de TM/TC

Moyenne Solliciter le service de veille technologique et/ou les services techniques du CNES

Etendre les études qui ont déjà été faites dans le cadre du projet

Difficulté de mise en œuvre des technologies de TM/TC

Faible Commencer dès que possible à se familiariser avec les technologies envisagées

Réduire les exigences dans le cadre du prototype fonctionnel

Difficulté de mise en œuvre des technologies IHM

Faible Commencer dès que possible à se familiariser avec les technologies envisagées

Réduire l’étendue des fonctionnalités à développer

Tableau 1: Gestion des risques liés au projet

Partie 4 : Analyse préliminaire

4.1. Utilisateurs et environnements de travail

On cherche à adopter pour ce projet une démarche de conception centrée utilisateur, qui se traduit par une prise en compte des utilisateurs finaux à tous les stades de la conception.

Dans cette optique, il convient de distinguer les cas où des utilisateurs finaux sont disponibles, ce qui nous permettra de mettre en place une démarche de conception participative dans laquelle ils seront impliqués, des cas où cette mise en œuvre est impossible.

Enfin, toujours dans une démarche de conception centrée utilisateur, il est important de connaître les contextes dans lesquels ces systèmes sont utilisés si l’on veut être en mesure de proposer des solutions adaptées. J’ai donc tenté de mieux les cerner par le biais d’entretiens et d’observations.

4.1.1. Edition de protocoles

Les utilisateurs sont, en plus des équipes projet CNES et CADMOS (contrôle des procédures au sol) qui sont amenés à créer des protocoles sur demande, les médecins scientifiques qui



voudront étendre ou modifier les expériences prises en charge par le système. Les utilisateurs pouvant être impliqués sont donc les médecins qui participent aux projets SEVE et Cardiomed, ou des personnes au profil similaire qui pourraient être amenées à utiliser cet éditeur.

La conception de cet éditeur n’est pas dans les objectifs du stage : pour moi, il s’agit simplement de faciliter sa mise en œuvre. Ce point ne sera donc pas approfondi.

4.1.2. Mode sol

4.1.2.a. Utilisateurs

En mode sol, les utilisateurs sont les médecins qui supervisent, depuis une salle de contrôle, les expériences médicales qui se déroulent à bord de la station spatiale. Il peut s’agir des médecins scientifiques intéressés par les résultats des expériences, ou bien des médecins des astronautes qui suivent leur état de santé. Au cours du stage, il m’a été possible de rencontrer les médecins scientifiques actuellement impliqués dans les projets Cardiomed et SEVE.

4.1.2.b. Besoin

Le premier besoin des utilisateurs au sol est d’avoir un aperçu complet des paramètres physiologiques. Cet aspect est particulièrement important pour les expériences risquées qui se déroulent en temps-réel : certains paramètres doivent être immédiatement et clairement observables. L’application doit assister ces médecins de différentes manières, par exemple en affichant des alarmes lorsque des paramètres ont des valeurs anormales.

Le mode sol doit également permettre aux utilisateurs de voir rapidement les tâches que doivent exécuter les astronautes, et doit les aider à communiquer efficacement avec eux en cas de besoin.

4.1.2.c. Environnement de travail

4.1.2.c.1) Salle de contrôle

Lorsqu’une expérience a lieu, le suivi se fait depuis une salle de contrôle. Comme on l’a vu, le système Cardiomed n’est pas utilisé actuellement ; en revanche, la proximité de la salle de contrôle du CADMOS m’a permis d’observer le déroulement d’une autre expérience afin d’avoir un aperçu de ce contexte.

Les médecins et les opérateurs sont en liaison audio ou vidéo avec les astronautes, et ont également toujours un écran affichant les paramètres qu’ils doivent surveiller.

Ils peuvent donner aux astronautes des indications en temps-réel, afin de répondre à des demandes, de leur préciser les actions à effectuer, ou de leur demander des informations sur l’état exact du système.

De fait, les échanges oraux sont très fréquents, les astronautes informant d’eux-mêmes lors de chaque changement du système, et les opérateurs demandant souvent des informations complémentaires ou des actions correctives mineures.

Les opérateurs disposent des procédures papier correspondant { l’expérience. Ils ont aussi des feuilles qui leur servent de brouillons, afin de noter les paramètres qu’ils veulent pouvoir retrouver rapidement.

4.1.2.c.2) Utilisations alternatives

Le système Cardiomed a également été utilisé, à des fins de qualification, en domaine hospitalier. Il a aussi participé à des campagnes de bedrests (expériences au cours desquelles des sujets restent en position couchée de plusieurs jours à plusieurs mois, afin de simuler les effets de l’impesanteur) et de vols paraboliques (atteinte d’un état d’impesanteur grâce { un avion effectuant une série d’arcs paraboliques). Dans ces situations, le système est manipulé exclusivement par l’équipe médicale et l’équipe projet : les ingénieurs et les médecins



scientifiques, mais également les infirmiers qui s’occupent de la pose des instruments de mesure sur le sujet.

La plupart des remarques des utilisateurs sur le système se basent sur ces expériences, ce qui les rend bien sûr incomplètes vis-à-vis du contexte d’utilisation ciblé.

Il est également prévu que le prototype de SEVE soit utilisé, dans un premier temps, en domaine hospitalier.

4.1.3. Mode bord

4.1.3.a. Utilisateurs

Les utilisateurs en mode bord sont les astronautes sujets des expériences, et, pour certains protocoles, un astronaute tiers qui l’assiste dans la manipulation du logiciel et des instruments.

Plusieurs mois avant le vol, ils suivent un entraînement sur tous les systèmes qu’ils seront amenés à utiliser : dans le cas de Cardiomed, ils disposent de quelques heures pour se familiariser avec le fonctionnement du système et les expériences { mettre en œuvre.

Ces utilisateurs sont peu nombreux et très peu disponibles, il n’est donc pas envisageable de les faire participer directement dans le cadre du stage. Il est également difficile de les interroger, même par des moyens légers tels que l’e-mail.

4.1.3.b. Environnement de travail

Le mode bord de SEVE et Cardiomed est conçu pour être utilisé { bord d’une station spatiale : le module russe de l’ISS pour Cardiomed, le module spatial chinois pour SEVE.

Des entretiens avec l’équipe projet et avec le personnel du CADMOS m’ont permis d’en apprendre plus sur les spécificités de ce contexte. Il s’agit d’un cadre très contraignant, dont plusieurs aspects sont à prendre en compte.

4.1.3.b.1) Impesanteur

La principale caractéristique d’une station spatiale est l’état d’impesanteur, c’est d’ailleurs la raison d’être de SEVE et Cardiomed. Cet état a plusieurs conséquences sur l’utilisabilité des systèmes à bord.

Objets mobiles : Tous les objets non fixés à la station volent librement. Les appareils de mesures doivent donc systématiquement être attachés { l’astronaute. De plus, certains dispositifs d’interaction ne peuvent pas être utilisés : la souris, incontrôlable, serait inutilisable. De manière générale, les dispositifs mobiles reposant sur une position dans l’espace sont difficilement envisageables.

Perception : Les effets de l’impesanteur prolongée sur la perception de l’espace sont encore mal connus, et depuis plusieurs années des programmes scientifiques tentent d’en apprendre d’avantage. Toutefois, dans le cas général, la capacité à manipuler une interface informatique standard n’est pas altérée.

4.1.3.b.2) Environnement technique

Nouveaux dispositifs : L’environnement très critique d’une station spatiale impose l’utilisation d’appareils éprouvés, qualifiés par des organismes spécialisés. C’est la raison pour laquelle plusieurs dispositifs d’interaction innovants ne sont pour le moment pas utilisés. Concernant les technologies sans fil, il faut également s’assurer que les émissions n’interfèrent pas avec d’autres systèmes.

Bruit : Les systèmes de la station produisent en permanence un bruit important. En plus de l’influence que ce bruit a sur les astronautes, il ne permet pas d’utiliser de manière sûre la commande vocale.



4.1.3.b.3) Isolement

Equipements : Lors de manipulations telles que Cardiomed, la bonne marche de la station n’est pas en jeu. En revanche, un endommagement du système peut être difficilement réparable, pouvant nécessiter l’attente d’un vol Progress permettant l’emport du matériel de rechange.

Facteur humain : Les astronautes { bord d’une station spatiale vivent dans cet environnement 24h/24, parfois des mois durant, et tout est fait pour éviter d’engendrer un stress supplémentaire. Dans le cadre de la conception d’applications interactives, il est donc important de fournir un système { l’utilisation particulièrement aisée, faute de quoi le risque de rejet est assez élevé.

4.2. Etude de l’existant

4.2.1. Démarche

Comme on l’a vu, Cardiomed est actuellement en phase de recette finale et d’entraînement. L’étude du système existant se heurte donc au fait qu’il n’ait jamais été utilisé en conditions réelles.

Le système a déjà été utilisé pour les tests des instruments en milieu hospitalier, ainsi que lors de séances de bedrests et de vols paraboliques ; certaines limites ont été décelées lors de ces séances, mais on ne peut en aucun cas les considérer comme des cas d’utilisation nominale.

De plus, comme on l’a vu, les astronautes { l’entraînement sont très peu disponibles : même s’ils ont des choses { dire sur l’utilisabilité du système, on doit se contenter des retours qu’ils adressent { l’équipe projet du CNES, sans possibilité de les interroger directement.

Pour évaluer quelles améliorations il faut apporter au système existant en termes

d’ergonomie, il faut donc principalement se tourner vers d’autres moyens que l’implication directe des utilisateurs. C’est pourquoi j’ai choisi de m’appuyer, en plus du bon sens et de règles générales d’ergonomie, sur des études ayant déjà été menées dans ce domaine, ainsi que sur l’avis de spécialistes disponibles.

Une étude préliminaire de l’existant, permettant de comparer les caractéristiques du

système avec quelques recommandations ergonomiques générales, a tout d’abord été menée en concertation avec mon maître de stage.

Une étude avec un ergonome spécialisé dans le domaine des vols habités a ensuite eu lieu, afin de repérer des défauts et des points positifs supplémentaires, dans ce contexte spécifique.

Sur le mode sol, l’évaluation de l’existant a consisté { interviewer des médecins utilisateurs

de ce système, afin de recueillir leurs avis sur ses points positifs et négatifs. J’ai ensuite observé ces médecins simuler une session d’expérience sur Cardiomed tout en

recueillant leurs remarques.

4.2.2. Evaluation ergonomique

4.2.2.a. Ergonomie générale

Une évaluation de l’utilisabilité du système, sur la base des critères de Scapin et Bastien, a donc tout d’abord été menée sur les modes bord et sol.

L’interface du système Cardiomed présente en effet plusieurs défauts d’ergonomie générale, parfois dus au manque de robustesse. L’ensemble des défauts repérés est décrit en annexe (Annexe 1).



4.2.2.a.1) Confusions entre mode sol et mode bord

Certaines commandes apparaissent dans le mode sol, alors qu’elles ne peuvent être utilisées qu’en mode bord. (Densité informationnelle)

D’autres sont disponibles en mode bord, mais sont inutiles pour les astronautes et sont destinées aux médecins. (Densité informationnelle)

4.2.2.a.2) Navigation

Il est impossible de se déplacer uniquement au clavier dans les menus, la navigation étant incohérente ; et ce, alors que le dispositif de pointage en mode bord, une simple trackball, est peu maniable, en particulier quand il s’agit de naviguer entre le protocole principal et les pages d’aide complémentaires. (Charge de travail)

4.2.2.a.3) Apparence des interfaces

Boutons dont la fonction est peu claire : Par exemple, la page d’étalonnage d’un instrument contient un bouton ‘reset’ permettant de remettre les paramètres de visualisation par défaut ; mais un autre bouton ‘reset’ correspond { l’envoi d’une commande { l’instrument. (Guidage, Actions explicites)

Incohérences dans la présentation des logs (Figure 10) : 3 logs différents (événements de session, connexion au sol, alarmes physiologiques) sont affichés avec 3 modes de fonctionnement différents, champ de texte sur lequel on peut double-cliquer, bouton pour afficher l’ensemble du log, et compromis entre les deux. (Homogénéité/cohérence). De plus, le log des événements de session, dont une ligne est visible, n’est pas utile pour une utilisation normale (Densité informationnelle).

Gestion des alarmes physiologiques déroutante : Quand un paramètre physiologique est anormal, une fenêtre s’affiche au premier plan de l’application, récapitulant tous les paramètres ; elle ne disparaît pas tant qu’on n’appuie pas sur ‘fermer‘. Elle réapparaît dès que le statut de l’alarme change. (Charge de travail)

Figure 10 : Logs de Cardiomed

4.2.2.a.4) Aspects liés à la robustesse

Le système étant peu robuste, en particulier dans la gestion des connexions avec des instruments, plusieurs actions sont volontairement rendues impossibles. Ainsi, une fois l’expérience commencée, on ne peut plus revenir { la phase d’initialisation sans relancer le programme, ce qui interdit toute erreur dans les phases de préparation. De même, une fois la manipulation terminée, on est obligé de fermer l’application, sans possibilité de démarrer une nouvelle phase d’expérimentation, ce qui n’est pas standard. (Incitation, Homogénéité/cohérence)

Le manque de robustesse devient évident quand on ouvre une page de calibration d’instrument alors que l’appareil concerné n’est pas encore en état de marche : cette mauvaise manipulation entraîne souvent une erreur qui oblige { fermer l’application. (Protection contre les erreurs)

4.2.2.b. Cadre spatial

Si l’ambition de Cardiomed de proposer un outil facilitant le suivi et la mise en œuvre d’expériences médicales est effectivement atteinte, certains éléments sont mal adaptés au cadre d’une station spatiale, en particulier au regard des standards existant dans cet environnement. Jullian LOPEZ, support CADMOS spécialisé en facteurs humains, a accepté de me faire part de ses observations durant une simulation d’utilisation du système.



4.2.2.b.1) Messages mis en valeur

A bord de l’ISS, une sémantique particulière régit les messages importants pour la sécurité du matériel et des personnes.

Ainsi, un message signalant un risque pour le matériel est nommé ‘Caution ‘ et surligné en jaune, alors qu’un message concernant la sécurité de l’équipage est nommé ‘Warning’ et surligné en rouge. Enfin, lorsqu’il s’agit d’une situation critique pour la station, le message est nommé ‘Emergency’. Cardiomed ne tient pas compte de ces subtilités et utilise indifféremment les termes ‘Caution’ et ‘Warning’ pour des remarques, importantes mais en général non critiques, sur l’utilisation du système.

4.2.2.b.2) Procédures dégradées

Les procédures dégradées (actions à effectuer si le système ne fonctionne pas de manière nominale) sont affichées en général sous forme de messages d’avertissement, alors qu’un format spécifique serait plus adapté.

4.2.2.b.3) Schémas

Certains schémas illustrant les instructions sont peu clairs : ils n’apportent rien { l’utilisateur car les informations sont trop difficiles à discerner.

4.2.3. Interview d’un utilisateur du mode sol

Si une évaluation par des spécialistes peut permettre de dégager quelques problèmes d’utilisabilité, il est beaucoup plus efficace de se fier aux utilisateurs eux-mêmes. Ainsi, on considère généralement que des tests d’utilisabilité menés sur 5 utilisateurs différents suffisent à identifier 80% des problèmes.

Dans notre cas, pour le mode sol, seuls deux utilisateurs réels étaient identifiés : il s’agissait des médecins participant au projet Cardiomed. De plus, l’un d’entre eux s’intéressait peu aux détails de l’évolution de l’outil, qui lui convenait à partir du moment où il pouvait en obtenir les mesures voulues. Son emploi du temps étant chargé, il n’a pas pu me consacrer de temps.

L’autre médecin, Marc-Antoine CUSTAUD, a en revanche accepté de répondre à mes interrogations lors d’un entretien, rapporté de manière détaillée en annexe (Annexe 4).

4.2.3.a. Déroulement de l’interview

L’interview s’est déroulée en deux phases : une première prise de contact, via un questionnaire envoyé par e-mail, a permis de dégager quelques problématiques de base, et d’exprimer 3 points positifs et 3 points { améliorer dans le système.

Par la suite, une rencontre dans le laboratoire de Cardiomed a eu lieu le 22/04/2009. Il n’était pas question de mener un test d’utilisabilité au sens formel du terme, en effet il

aurait fallu pour cela disposer, sinon d’un laboratoire adapté, au moins d’un ensemble de tâches à accomplir et de paramètres à mesurer ; or, Cardiomed étant conçu pour naviguer de manière linéaire à travers un protocole, et pour surveiller un ensemble de paramètres représentés de manière simple, il était difficile de déterminer quels auraient été les points à observer.

J’ai donc choisi de centrer l’entretien autour d’une utilisation du système en « loud thinking » (l’utilisateur décrit { voix haute ce qu’il est en train de faire, et, plus important ici, ce qu’il perçoit et qui lui convient ou ne lui convient pas).

L’objectif était d’identifier ainsi un maximum de problèmes, voire même de générer des éléments de solution.

Durant cette réunion, nous avons simulé une manipulation de Cardiomed, et en particulier

du protocole 9 (CARDIOPRES-1, exercice mettant en œuvre le brassard HLTA, le doigtier et les électrodes Cardiopres). Cette séance a servi de support à des commentaires et remarques, au fur et à mesure que les pages se présentaient.



Le protocole a ensuite été relancé, avec cette fois des commentaires de ma part sur ce que j’avais noté lors de mon évaluation, alimentant les remarques.

Enfin, certains points, non abordés ou non complètement traités au cours de la séance, ont été approfondis par discussion.

4.2.3.b. Généralités

Les remarques du médecin recoupent plusieurs points évoqués au 4.2.2. Ainsi, bien qu’il soit satisfait des mesures fournies par Cardiomed, il déplore le manque de

robustesse du système, qui perturbe la bonne marche des expériences. Il relève également les incohérences évoquées sur l’affichage des logs, en particulier dans la

mesure où certaines informations sont inutiles pour l’utilisateur, ainsi que les incohérences sur certains éléments d’interface, sur la manipulation au clavier, ou encore sur les alarmes physiologiques.

Il rappelle aussi la nécessité de pouvoir manipuler l’interface d’une seule main, puisque dans certaines expériences il faut pouvoir tenir une électrode par exemple.

4.2.3.c. Préparation de l’expérience

4.2.3.c.1) Déroulement de protocoles

Le principe du déroulement de protocoles est satisfaisant. Une réflexion sur le format à donner à ces protocoles peut être menée, à partir de ce qui existe dans le cadre ESA par exemple.

4.2.3.c.2) Réglage des instruments

Les problèmes les plus gênants sont le ciblage des sliders (curseur difficile à manipuler à la souris) et l’incohérence de la manipulation au clavier.

Le problème des sliders serait peut-être atténué avec l’utilisation d’écrans tactiles. Pour ce qui est de la manipulation au clavier, l’idéal serait d’avoir une manipulation comparable { celle qui existe sur les échographes.

4.2.3.c.3) Page de vérification générale

Cette page, chargée en informations sur le protocole que nous avons déroulé, manque de hiérarchisation : il est difficile de s’y retrouver { travers les différents signaux affichés.

4.2.3.d. Déroulement de l’expérience

4.2.3.d.1) Alarmes

Les principales remarques concernent les alarmes : l’option de l’apparition d’une fenêtre fermable a été imposée par le fait qu’aucune donnée physiologique ne devait être cachée, et que la place déjà utilisée était maximale. Dans le protocole déroulé, en particulier, le synoptique ECG est une donnée importante qu’il faut toujours laisser visible.

Une alternative envisageable serait, plutôt qu’une place fixe pour toutes les alarmes dans l’interface (difficile en termes de place disponible), une alarme visuelle et sonore directement sur les paramètres concernés. Par exemple pour le CDPB, si la pression systolique prend une valeur critique, on grossira la valeur affichée et on la fera clignoter en rouge. Il s’agit de la technique utilisée dans les services de réanimation.

Enfin, si le matériel le permet, dans le cas d’un appareil tel que le CDPB, le fait qu’une

électrode soit débranchée devrait déclencher une alarme.



4.2.3.d.2) Marqueurs d’événements

Grâce { la barre d’espace, on peut définir des marqueurs temporels pour notifier un événement (alarme déclenchée, interruption de l’expérience…). Mais on ne peut pas nommer ces marqueurs, ce qui veut dire que pour savoir { quoi ils correspondent, il faut s’en souvenir ou le noter sur un autre support (par exemple, un dictaphone). L’intérêt de cette fonctionnalité s’en trouve significativement réduit.

4.2.3.d.3) Changement de paramètres

Lorsque l’on change les paramètres d’affichage, il faudrait garder une certaine cohérence. Ainsi, lorsqu’on change l’échelle de temps sur l’un des synoptiques du CDPB, on s’attend { ce que le deuxième synoptique du même appareil soit lui aussi modifié. On peut, par exemple, introduire une commande « garder la proportionnalité »...

4.2.3.d.4) Transfert des données

Le transfert de l’ensemble des données acquises lors de l’expérience, depuis l’instrument jusqu’{ l’ordinateur, connaît quelques problèmes.

Tout d’abord, la méthode adoptée consiste { transférer et { effacer le contenu ; mais il n’y a pas de vérification que le transfert s’est bien effectué, ce qui peut entraîner la perte de toute la session en cas de problème.

Ensuite, il y a peu de données concernant la robustesse de ce transfert. Or, dans certains cas, le temps de latence peut être vraiment important, et il faudrait avoir un moyen de savoir si le programme continue { travailler ou s’il faut le redémarrer. Il est donc nécessaire de donner plus de feedback { l’utilisateur durant cette phase, par exemple en indiquant une estimation de temps avec la fin de l’opération, ou au moins en montrant qu’il est en activité.

Enfin, il est impossible de sélectionner quelles données on veut transférer : on est obligé d’envoyer toutes les mesures conservées dans la mémoire de l’appareil, ce qui peut consommer des ressources inutilement en cas de problème sur une expérience antérieure.

4.2.4. Retours des utilisateurs du mode bord

Il aurait été intéressant de fournir aux cosmonautes russes des questionnaires portant sur l’utilisabilité de Cardiomed : bien que ce ne soit pas la méthode la plus efficace, cela aurait été préférable à une attente passive des remarques, qui ne concernaient évidemment que les problèmes les plus critiques. Toutefois, comme on l’a vu au 4.1.3.a, cette démarche ne pouvait pas être mise en place.

En revanche, en juin, des retours de la partie russe nous sont parvenus, sous forme de

rapports d’erreur (bugs). Les erreurs étaient surtout dues au manque de robustesse du logiciel, mais révélaient également un problème d’utilisabilité : certaines pages de configuration étaient ouvertes avant que l’instrument correspondant soit allumé (problème relevé aux 4.2.2.a.4), 4.2.3.b ).

Au-del{ de l’erreur technique, ce retour illustrait bien un problème de lisibilité de l’information. Lors du déroulement d’un protocole, les instructions sont en effet sensées guider les utilisateurs pour qu’ils initialisent étape par étape les instruments. Or, il suffit de regarder une page de connexion d’un instrument (Figure 11) pour s’apercevoir que, sans une concentration importante, il est facile d’omettre une étape.

Les cosmonautes n’ont justement pas forcément une concentration optimale, et, même lors des missions, ils peuvent avoir tendance à suivre les souvenirs de leur entraînement ou leur instinct plutôt qu’une procédure établie. Il est donc important de rendre immédiatement perceptibles les éléments les plus importants des protocoles.

Cela implique une réflexion sur la hiérarchisation des informations, ainsi que sur les moyens d’inciter les utilisateurs à les prendre en compte.



Figure 11 : Page de connexion d'un instrument (CDPB)

4.3. Scenarii de travail

Comme on l’a vu, le système n’a pas été utilisé en situation nominale ; de plus les utilisateurs potentiels du mode bord ne sont pas disponible. Pour bien comprendre l’usage du système, j’ai donc élaboré des scenarii de travail, basés sur les informations que j’avais pu recueillir des différentes parties prenantes ; je les ai ensuite fait commenter par mon maître de stage.

En plus d’éclaircir certains points, en particulier sur le déroulement d’une expérience médicale, il m’a permis d’illustrer les principales problématiques soulevées en phase d’analyse préliminaire, afin de permettre { l’équipe projet de mieux comprendre ma démarche.

Les scenarii décrits montrent un cas d’utilisation nominale, respectant les instructions { la lettre, puis deux cas avec lesquels les utilisateurs sont moins patients et moins rigoureux.

4.3.1. Scénario 1 : Utilisation nominale

Selon le planning mis en place dans la station, le cosmonaute prend connaissance de la procédure décrivant le protocole médical qu’il doit suivre.

Cette procédure inclut l’utilisation du système Cardiomed et référence la procédure opérationnelle de cette utilisation. Le cosmonaute se munit donc de la procédure décrivant les tâches à effectuer pour se servir du système.

// Montre le problème de la dépendance du protocole avec la procédure standard Après avoir effectué les tâches décrites au début de la procédure d’exercice (préparation de

l’exercice), il se réfère { la procédure d’utilisation du système pour lancer Cardiomed. Pour



commencer, après avoir initialisé le laptop, il exécute le programme « Cardiomed.exe » présent au démarrage.

La langue sélectionnée par défaut étant le russe, il ne modifie pas ce paramètre. Dans le menu déroulant permettant de définir le sujet de l’expérience, il choisit son

identifiant. Dans celui qui définit le protocole, conformément à la procédure, il choisit « CARDIOPRES-1 ». Il vérifie que les instruments sont bien ceux décrits dans la procédure, puis appuie sur « commencer ». L’onglet « préparation » s’ouvre.

La première page du protocole décrit les trousses Nomex (les boîtes rembourrées dans

lesquelles est rangé le matériel) nécessaires { l’opération. Le cosmonaute vérifie qu’elles sont disponibles puis appuie sur « suivant ».

Les pages suivantes lui présentent les éléments à préparer : Cardiopres, HLTA, jetables (électrodes, bactéricide…), accessoires. A chaque fois, il sort de son compartiment l’item décrit, puis déballe son contenu en vérifiant qu’il est conforme { celui décrit par Cardiomed. A la fin de cette phase, l’onglet « configuration » s’ouvre.

La page suivante lui demande de placer les électrodes. Suivant le protocole, il nettoie sa peau aux zones indiquées avec le bactéricide, se rasant au besoin, puis il place le bactéricide dans le sac de déchets, attend que sa peau soit sèche et place les électrodes. Pour juger de leur bonne installation il se réfère au schéma et à son entraînement. Il appuie ensuite sur « suivant ».

// Illustre l’importance des schémas et de l’entraînement pour l’installation des instruments

Il poursuit avec la page d’installation de la ceinture respiratoire. La procédure qu’il suit pour cet exercice spécifie de ne pas l’utiliser, aussi il saute cette page.

Il continue avec le branchement des électrodes : il se réfère aux instructions pour brancher

chaque câble { l’électrode correspondante. Il installe ensuite le HLTA. Sur la page de vérification du HLTA, il lance une mesure, puis

attend que le résultat s’affiche. C’est le cas, il en déduit que l’instrument est convenablement installé. Il prend note du fait qu’il ne devra pas faire de mouvement du bras droit pendant les mesures du HLTA.

De la même manière, il suit les instructions pour installer le doigtier Cardiopres. Lors de la phase de vérification du Cardiopres, il estime que le signal n’est pas satisfaisant. Il ouvre donc la page d’aide, et doit faire des allers-retours entre la page d’aide et la page de vérification pour suivre les différentes étapes.

// Illustre la nécessité d’une manipulation de l’interface particulièrement aisée (fixation d’instruments qui gênent le mouvement), montre le problème du passage entre pages d’aide et pages de protocole

Dans la page de vérification générale, il regarde si tous les signaux sont corrects. Il appuie ensuite sur « commencer l’expérience ».

Après avoir eu confirmation par le sol que les données sont bien reçues, le cosmonaute

laisse l’expérience se dérouler en effectuant les exercices prévus par la procédure (séance d’utilisation du vélo ergomètre { différentes cadences).

A un moment donné, un événement imprévu lui semble susceptible de fausser les mesures, aussi il appuie sur « espace » pour ajouter un marqueur d’événement. Il utilise ensuite le dictaphone de la station pour décrire l’événement.

// Montre le manque d’utilisabilité des marqueurs temporels A la fin de l’expérience, il appuie sur « terminer l’expérience ». L’onglet « Désinstallation »

s’ouvre. Il suit les instructions pour enlever les ceintures et les électrodes. Sur la page suivante il procède selon les instructions { l’écran pour transférer les données acquises par le Cardiopres



vers le laptop. 30 secondes s’écoulent avant qu’une barre de progression indique le transfert en cours. Il attend ensuite le message de confirmation du logiciel pour déconnecter l’appareil et écraser sa mémoire.

// Montre le manque de retours à l’utilisateur (feedback immédiat) sur le transfert des données

Il suit ensuite les instructions pour déconnecter et enlever tous les instruments. A la fin de cette phase, l’onglet « rangement » s’ouvre. Comme indiqué sur la procédure, il

vérifie que tous les compartiments sont bien à leur place. Il appuie ensuite sur « suivant » pour trouver la page de clôture du protocole, puis sur « fermer », ce qui termine l’exécution du programme. Conformément { la procédure, il éteint l’ordinateur.

4.3.2. Scénario 2 : Utilisation avec non-respect de la procédure

Le début de l’expérience se déroule de façon semblable au scénario précédent : le cosmonaute choisit le protocole et les paramètres à dérouler, déballe le matériel, puis commence l’installation.

Il se rappelle bien de son entraînement, aussi effectue-t-il rapidement l’installation des

électrodes et du HLTA, en regardant les images et en répétant les actions qu’il y a associées. Sur la page d’installation du doigtier Cardiopres, il regarde les images et installe rapidement

l’instrument. Il appuie ensuite sur « suivant », en oubliant de mettre l’interrupteur « CDP-HLTE » à « ON ». Le système lui indique qu’il y a un problème de connexion, et l’invite { recharger la page. Le cosmonaute utilise le menu sur le côté gauche pour retourner en arrière, actionne l’interrupteur, puis revient sur la page.

// Illustre l’importance du facteur humain dans la mauvaise utilisation des procédures Il poursuit ensuite la mise en œuvre du protocole, jusqu’{ la fin de l’expérience et le

rangement des instruments.

4.3.3. Scénario 3 : Utilisation avec non-respect de la procédure et erreur du système

Le début de la manipulation se déroule de façon semblable au scénario précédent : le cosmonaute choisit le protocole et les paramètres à dérouler, déballe le matériel, puis commence l’installation.

Il se rappelle bien de son entraînement, aussi effectue-t-il rapidement l’installation des

électrodes et du HLTA, en regardant les images et en répétant les actions qu’il y a associées. Alors qu’il ouvre la page de vérification du HLTA, il se rend compte qu’il n’a pas branché le

câble correspondant sur le boîtier Cardiomed. Il revient en arrière mais l’initialisation a déj{ commencé. Au bout de 10 secondes, un message d’erreur lui signifie que le programme va s’arrêter.

// Illustre le manque de robustesse du système associé à une défaillance humaine Le cosmonaute clique sur « OK », puis, après que le programme se soit terminé, il le relance,

branche le HLTA sans attendre d’être sur la page correspondante, et utilise le menu sur la gauche pour revenir rapidement au point où il s’était arrêté.

Il poursuit ensuite la mise en œuvre du protocole jusqu’{ la fin de l’expérience et le rangement des instruments.



4.4. Evaluation de l’adaptation des procédures utilisées par l’ESA à SEVE

Afin de proposer de meilleures solutions sur les règles de rédaction des protocoles, il était intéressant d’étudier des exemples de règles existantes. Je me suis intéressé en particulier à la norme ODF (Operations Data Files), définie par la NASA, qui règlemente { l’échelle internationale la rédaction des procédures suivies à bord de l’ISS. Un exemple de procédure respectant cette norme est illustré Figure 12.

Figure 12 : Extrait d'une procédure respectant la norme ODF

Si certaines règles, liées au contexte spécifique { bord de l’ISS (langue et vocabulaire

notamment) ou au fait que les astronautes connaissent impérativement cette norme, utilisée pour toutes les procédures à bord (entraînement), ne peuvent pas être reprises telles quelles, d’autres aspects, définis { la suite d’une démarche centrée utilisateur, sont intéressants à examiner. En effet, le document qui les présente donne pour la plupart des règles la raison de leur choix (design rationale).

L’étude complète peut être trouvée en annexe (Annexe 3) ; le Tableau 2 résume les conclusions de cette étude.



Elément de norme ESA Adaptable à Cardiomed Pertinence dans le cadre de SEVE

Procédure écrite d’une seule traite (un seul document)

Non : Cardiomed utilise un découpage en phases et en pages pour une utilisation sur ordinateur

A priori non : le découpage à l’œuvre dans Cardiomed est conservé. Cela permet notamment d’alterner des pages d’instructions et des pages dynamiques.

Description détaillée de la procédure dans un header (matériel requis, durée, membres d’équipage…)

Oui, car correspond aux pages d’initialisation et de déballage des instruments.

Certaines règles peuvent être intéressantes à prendre en compte : récapitulatif du but de la procédure, membres d’équipage requis…

Désignation des appareils sur lesquels s’effectue chaque opération : avant la ligne d’instruction

Oui mais non appliqué (appareil décrit { l’intérieur de la ligne d’instruction)

Oui

Désignation des pages logicielles sur lesquelles s’effectue l’instruction : encadrée avant l’instruction

Inutile A priori non, car les instructions sont décrites { l’intérieur même du logiciel

Découpage en instructions et sous-instructions

Pourrait correspondre au découpage en pages, avec des différences concernant la longueur des instructions. Adaptation possible moyennant une réflexion sur les instructions.

Oui, car le respect de cette règle pourrait amener plus de clarté dans la lecture des protocoles.

Numérotation des instructions et sous-instructions

Adaptable si le point précédent est respecté.

Oui

Règles sur la nomenclature des appareils

A priori non, car les appareils sont déjà nommés dans Cardiomed

A déterminer

Règles sur la nomenclature des actions (exemple : check = vérification avec le sol, verify = vérification simple ; sel = sélectionner (dans un menu)…)

Oui : il s’agit de vocabulaire Une nomenclature trop stricte n’est pas pertinente (problèmes d’entraînement, de langue) On pourra en revanche définir une série de guides pour éviter les ambiguïtés.

Utilisation d’icônes précises pour exprimer certaines instrutions (exemple : = vérification dans un menu)

Oui Eventuellement pour les instructions récurrentes, si le symbole est très clair (sinon, problème d’entraînement)

Règles de mise en page pour certaines instructions

Il faudrait alors définir de nouveaux paramètres d’affichage via la feuille de styles css.

Oui pour les règles qui apportent de la clarté, à condition que la compréhension de l’instruction ne repose pas sur ces règles (sinon, problème d’entraînement)

Règles de mise en page pour les figures et les images

Oui, mais selon les règles actuelles les images ont une place fixe dans Cardiomed

Oui



Elément de norme ESA Adaptable à Cardiomed Pertinence dans le cadre de SEVE

Affichage des icônes des interfaces , plutôt qu’une description, quand elles sont utilisées

A priori oui (parfois, une photo indique quelles commandes utiliser)

Oui si c’est utile

Règles sur l’affichage des procédures dégradées

Oui, mais : - Il n’y a pas de règle stricte pour la prise en compte des cas dégradés dans Cardiomed - Il faudrait définir de nouvelles règles dans la feuille de style css

Intéressant à envisager

Différenciation entre actions sol et actions bord

Non : Le sol n’a pas de rôle actif { jouer dans le déroulement du protocole

A priori non

Tableau 2 : Adaptation de certains points de la norme ODF à Cardiomed et SEVE

Partie 5 : Evaluation de technologies de commande et d’acquisition de mesures

5.1. Méthodologie

Lors de l’étude de technologies permettant la commande et l’acquisition de mesures depuis une station distante, deux technologies en particulier ont été évoquées : les ateliers Best et Octave, une suite d’outils internes CNES, et Joram, un service de communication asynchrone.

Afin de faire un choix, j’ai utilisé alternativement ces méthodes pour prototyper une application permettant de démarrer et d’acquérir des mesures sur l’instrument CNAP. Cela m’a donné l’occasion, en particulier pour les ateliers Best et Octave, d’évaluer l’intérêt de ces outils pour le développement d’applications interactives, mais également pour la maintenance et l’évolutivité de cette application.

5.2. Ateliers Best et Octave

5.2.1. Présentation des plateformes Best et Octave

5.2.1.a. Présentation générale

Best et Octave sont des outils internes CNES permettant de concevoir et de traiter des modèles de données pour la télécommande et la télémesure. Les détails de leur évaluation peuvent être trouvés en annexe (Annexe 2).

Ils utilisent le modèle XIF, qui est un standard XML pour la description de formats de données.

Best est la suite logicielle qui permet d’élaborer des modèles de données, avec deux composantes principales : Oasis, qui permet de créer et d’éditer des modèles, et Data Producer Editor (DPE), qui permet de générer ou de visualiser paquet par paquet des mesures correspondant à ces modèles.

Octave est l’outil d’exploitation de ces modèles. Il propose un serveur CORBA et de nombreux services : gestion de sessions, connexion { un flot de données, envoi de commandes… Il comprend également des applications graphiques qui utilisent ces services. Il est ainsi possible, sans écrire aucune ligne de code, de se connecter à un flot de télémesure



correspondant à un modèle donné, de définir des synoptiques correspondant à ce flot, puis d’envoyer des séries d’instructions dans un ordre prédéfini et de visualiser les mesures reçues.

5.2.1.b. Utilité dans SEVE

En plus de l’accès aux données depuis une station distante, Best et Octave permettent donc de créer de manière simple des modèles de données correspondant aux mesures d’un instrument, et gèrent également toutes les connexions aux instruments (dans notre cas, gestion des ports série).

Ces fonctionnalités peuvent considérablement faciliter le développement et la gestion de l’application, { condition d’être bien utilisables.

5.2.2. Evaluation de l’outil Best

5.2.2.a. Oasis

5.2.2.a.1) Utilité

Oasis est l’outil d’édition des modèles de données. Il permet de créer, d’éditer et de visualiser des modèles de manière graphique (voir Figure 13 : Capture d'écran de l'application OASIS), selon des principes simples. Cet éditeur est conçu pour être utilisé conjointement à la suite Octave, toutefois il peut également servir simplement de support à la compréhension et à la diffusion des structures de données.

Pour SEVE, la prise en charge des fonctions de décommutation par un outil graphique permettrait en premier lieu d’améliorer l’évolutivité et la maintenance du logiciel, puisqu’il est a priori plus facile de créer, d’éditer et d’analyser un modèle de données { partir d’une application graphique, plutôt que de coder un analyseur.

5.2.2.a.2) Temps d’apprentissage

Oasis permet de créer des modèles de données de façon relativement intuitive, malgré quelques défauts qui s’estompent par apprentissage. Quelques jours seulement sont nécessaires pour maîtriser les bases de l’outil.

5.2.2.a.3) Puissance d’expression

Cet outil permet de créer facilement des modèles de données respectant les conventions. Les types de champs pouvant être décrits sont très variés : données de n’importe quel type

(encodage, taille), champs optionnels, tableaux et listes… Toutefois des limites existent lorsque les protocoles de communication ne sont pas

standards. Ainsi l’un des instruments de SEVE, l’ECG 12 dérivations, envoie ses mesures sous forme de listes ayant un nombre d’éléments non prédéterminés, et sans marqueur de fin : c’est la fin du paquet qui permet de repérer la fin de la liste des mesures. De plus, le nombre de dérivations utilisées n’est pas décrit dans chaque paquet mais est définie par le moniteur.

Ces structures, par exemple, ne peuvent pas être décrites par cet outil. Pour exploiter cet outil dans Octave, il faut utiliser un « packetizer », impliquant la reconnaissance « à la main » de tout le paquet, puis la modification de ce paquet pour le « standardiser » et le renvoi à Octave.

Il s’agit donc d’un sérieux défaut portant sur l’utilité de ce produit au projet SEVE, en particulier dans le cadre du stage, une modification des appareils « sur étagère » n’étant pas envisageable.

5.2.2.a.4) Exploitation par Octave

En plus du problème cité au 5.2.2.a.3), le lien entre Best et Octave n’est pas encore au point : pour exploiter pleinement un modèle de données avec Octave, il faut passer par un plugin qui ne fait pas partie de la distribution de base de Best. De plus, pour que ces deux versions soient



compatibles, il faut modifier directement des parties du fichier XML, ce qui n’est pas du tout intuitif.

Figure 13 : Capture d'écran de l'application OASIS

5.2.2.a.5) Conclusion

Best peut être utilisé dans SEVE pour comprendre de façon approfondie les protocoles par lesquels les instruments utilisés communiquent avec le moniteur. Toutefois, il s’agit également d’un travail supplémentaire, et, pour s’assurer qu’il ait une valeur réelle pour le projet, il est important de pouvoir le réutiliser par la suite grâce à la plateforme Octave.

5.2.2.b. Data Producer Editor (DPE)

Un autre outil faisant partie de l’atelier Best est le Data Producer Editor, qui permet de tester les fichiers XIF créés avec Octave. Ainsi on peut générer des paquets de données aléatoires, ou vérifier la compatibilité du modèle créé avec des mesures présentes dans un fichier. Ces deux applications, utilisées conjointement, permettent de comprendre de façon détaillée le protocole de communication d’un instrument.



5.2.3. Evaluation des outils Octave

5.2.3.a. Services CORBA

5.2.3.a.1) Présentation

Octave repose sur un ensemble de services CORBA assurant les fonctions d’acquisition, d’envoi, de commutation/décommutation, de stockage… des données.

On peut accéder { ces services, via les outils développés par les équipes d’Octave, ou par un client personnalisé utilisant les mécanismes classiques de noms de services CORBA (ORB, NamingService…)

5.2.3.a.2) Utilité

La plateforme Octave permet, en plus de l’accès aux données depuis une station distante, la gestion de la communication avec les instruments et de la décommutation des données. Ce faisant, elle permet d’exploiter pleinement les modèles de données réalisés avec Best : ainsi on peut accéder aux noms des champs ou des types en les identifiant sous forme de chaîne de caractères.

5.2.3.a.3) Temps d’apprentissage

Octave, outil générique, fournit de très nombreux services, dont certains ne sont pas utiles pour notre projet : gestion contraignante des flots tm et tc, des utilisateurs, entraînant une multiplication des services interdépendants qu’il faut d’abord lancer (services Corba, « UserManagement », « OctaveServers », « OctaveEngine ») puis auxquels il faut accéder par leurs descripteurs CORBA.

Il faut donc compter environ une semaine { suivre des tutoriaux, avant d’espérer faire fonctionner une application complète correspondant à notre besoin (envoi de commandes, réception et traitement de mesures).

Le nombre très élevé de composants peut entraîner de nombreuses erreurs dues à

l’utilisation de mauvaises librairies, l’omission de certaines autres, voire même l’oubli du lancement de certains services. Il est en général difficile d’apprendre de ces erreurs, puisque, { moins de passer plusieurs semaines à étudier le fonctionnement de cette suite logicielle, il est impossible de se souvenir, par exemple, quelle librairie causait l’apparition d’une erreur donnée.

5.2.3.a.4) Performances

Sur l’instrument CNAP, les performances d’Octave sont très satisfaisantes : toutes les mesures arrivant du CNAP sont acquises, de manière fluide.

Octave offre donc un ensemble de services globalement performants, tout à fait adaptés aux besoins du projet

5.2.3.a.5) Conclusion

Malgré plusieurs défauts pour le développeur, en particulier la complexité et l’interdépendance entre les composants, les services CORBA fournis par Octave sont avantageusement utilisables par le projet SEVE.

Toutefois, les qualités d’Octave se révèlent entièrement dans le cadre de manipulations sur des systèmes ayant des paramètres et des structures de données beaucoup plus complexes, et le souci de généricité de l’outil entraîne des contraintes souvent inutiles pour nous.



5.2.3.b. Applications graphiques

5.2.3.b.1) Administration des services

Octave propose une série d’applications graphiques qui utilisent les services CORBA de la plateforme pour fournir des fonctionnalités de gestion des serveurs, d’acquisition et de visualisation de données, et de télécommande. Ces applications sont assez lourdes à démarrer, puisqu’elles nécessitent les services de connexion, d’identification et de serveurs de flots que nous avons vus dans la partie 5.2.3.a.3), puis, pour couvrir l’intégralité de notre besoin, 3 applications différentes, pour lesquelles l’utilisateur doit s’authentifier.

Les interfaces fournies présentent plusieurs défauts, décrits dans l’Annexe 2, mais restent

assez intuitives pour les fonctionnalités les plus simples. La définition des flots et des paramètres de connexion se fait tant bien que mal au début,

puis plus naturellement par apprentissage. En revanche, l’outil d’édition de synoptiques n’est en l’état pas assez complet pour notre

besoin : pas de possibilité d’envoyer des commandes depuis cette interface (défaut qui sera résolu dans la prochaine version), pas de possibilité d’inclure directement une courbe dans la visualisation…

5.2.3.b.2) Utilisation pour le commande/contrôle

Une fois les flots et les synoptiques définis, il est théoriquement possible d’utiliser ces interfaces graphiques pour permettre aux utilisateurs de commander et contrôler les instruments. J’ai donc prototypé une application équivalente à celle que j’ai décrite au 5.1, afin d’évaluer leur pertinence par rapport aux besoins du projet. J’ai ensuite proposé { mon maître de stage d’utiliser ce prototype, afin qu’il se prononce sur la pertinence de cette solution.

De manière générale, alors qu’on voudrait une application simplifiant au maximum la

charge de travail de l’utilisateur, ces interfaces répondent difficilement { ce besoin. Ainsi, une opération consistant à acquérir les mesures de tension par le HLTA, puis envoyer au CNAP, pour calibration, les mesures obtenues (procédure normale de calibration du CNAP), nécessiterait la suite d’action suivante :

Lancer les services Octave, ouvrir OctaveManager et lancer les flots de données Ouvrir OctaveClient Ouvrir les pages de visualisation du CNAP et du HLTA Depuis chacune de ces pages, s’abonner au flot correspondant { l’instrument Ouvrir OctaveProcedure Ouvrir la procédure d’acquisition de mesures HLTA La lancer et attendre la fin Visualiser le résultat en allant sur la page OctaveClient Dans OctaveProcedure, ouvrir la procédure de lancement du CNAP Lancer cette procédure Dans un nouvel onglet, ouvrir la procédure d’envoi de mesures NIBP au CNAP Modifier les champs correspondant à la valeur des mesures, pour les faire correspondre

à la mesure trouvée avec le HLTA Lancer cette procédure Vérifier que l’opération se déroule bien depuis la page OctaveClient On voit bien que l’on est loin du souci de simplification des actions au maximum. Ces raisons font que l’utilisation des interfaces graphiques proposées par Octave ne

correspond pas à notre besoin, en particulier pour une utilisation en vol, où la charge de travail de l’utilisateur doit être réduite au maximum.



5.2.4. Conclusion générale

Les plateformes Best et Octave, utilisées en complémentarité, fournissent un service efficace et utilisable par SEVE. Toutefois, après utilisation, certaines impressions se dégagent :

Un outil générique prévu pour des cas bien plus complexes que le projet SEVE, dont beaucoup de fonctions sont inadaptées à notre besoin ;

Un outil encore en développement, complexe à installer et à lancer, dont plusieurs modules sont incompatibles (en particulier lorsque l’on veut exploiter avec Octave le travail réalisé avec Best), et plusieurs services peu robustes

En l’état, l’utilisation de ces plateformes est donc compromise. En revanche il sera

intéressant de suivre de près leur évolution, en particulier si il est envisagé de regrouper plusieurs instruments sur une même carte synchronisée, ce qui peut rendre appréciable l’utilisation d’un outil pour la description et l’utilisation (voire la conception) de structures de données complexes.

5.3. Joram

5.3.1. Présentation de Joram

Joram (Java Open Reliable Asynchronous Messaging) est une implémentation open-source de la spécification JMS (Java Message Service) : il s’agit d’un système de communication asynchrone basé sur l’échange de messages sur un bus. La communication peut se faire suivant deux modes :

La communication point à point, basée sur des files (queues) de messages. Un client producteur (publisher) adresse un message à une queue. Ce message est consommé par un seul client (consumer) : il est stocké dans la queue jusqu’{ ce qu’il soit consommé, ou jusqu’{ la fin d’un délai.

La communication multipoints, basée sur le modèle publication/abonnement (publish/subscribe). Un producteur émet un message sur un sujet (topic) précis. Tous les clients abonnés à ce topic reçoivent alors ce message.

Un schéma illustre ces deux principes sur la Figure 14 : Principe de fonctionnement de Joram.

Figure 14 : Principe de fonctionnement de Joram



5.3.2. Utilité

Dans le cadre de SEVE, on s’intéresse au mode Publish/Subscribe : il permet à plusieurs applications, connectées au même serveur Joram, de recevoir de manière asynchrone les mesures des différents instruments.

5.3.3. Facilité d’utilisation

Les paramètres { maîtriser étant en nombre limité, il est assez facile d’utiliser les services Joram. Si un apprentissage est nécessaire pour appréhender les bases du service, on peut rapidement obtenir une application fonctionnelle. Il est d’ailleurs possible de se baser sur un exemple existant pour développer une application simple envoyant et recevant des messages.

5.3.4. Performances

Les performances constatées sur le prototype que j’ai développé semblaient satisfaisantes, puisque les mesures provenant de l’instrument le plus rapide du système (l’ECG, qui mesure 12 dérivations à 1000 Hz) étaient acquises de manière fluide. De plus, un ingénieur ayant travaillé sur une version d’Octave utilisant Joram, Erwann POUPART, m’a confirmé que les performances que sont équipe avait mesurées étaient largement suffisantes.

5.3.5. Conclusion

Même s’il ne fournit pas autant de services que les ateliers Best et Octave, Joram répond aux besoins de base de SEVE (communication entre les instruments et une station distante) de manière efficace. De plus, dans le cadre du stage, il est plus simple de gérer par soi-même l’analyse des données envoyées par les instruments, les protocoles de communication n’étant pas forcément standards.

Partie 6 : Conception de l’application interactive Pour que SEVE constitue une amélioration par rapport à Cardiomed, il était nécessaire de

mettre en place un cycle de conception centré utilisateurs, itératif, à même de répondre aux problématiques qui se présentaient en phase d’analyse puis lors de la conception. Ce cycle a commencé dès la phase d’analyse préliminaire, avec la prise en compte des remarques des utilisateurs sur le mode sol du système Cardiomed. Il s’est poursuivi de manière itérative jusqu’{ la fin du mois de juillet, à travers des réunions permettant de résoudre les unes après les autres les problématiques qui se présentaient.

6.1. Déroulement de protocoles médicaux

Pour cette partie, critique surtout en mode bord, les utilisateurs n’étaient pas disponibles, comme on l’a vu au 4.1.3.a. Ainsi j’ai été amené { me fier d’avantage { des experts du domaine spatial et des facteurs humains, à travers des réunions de groupe orientées sur les solutions à apporter à chaque problématique.

6.1.1. Focus group sur le suivi des procédures opérationnelles

L’analyse de l’existant et les retours de la partie russe avaient fait apparaître un manque de lisibilité des informations, en particulier pour les tâches complexes : il était facile d’omettre une étape du protocole.

Pour traiter cette problématique, il aurait été intéressant d’organiser un brainstorming, ce qui aurait nécessité de rassembler trois ou quatre utilisateurs autour d’une question précise et de les amener { demander de générer un maximum d’idées, avant de leur proposer de désigner celles qui leur semblent les meilleures.



C’était hélas impossible, j’ai donc décidé de procéder autrement. Ainsi un focus group a eu lieu le 16/06/2009, en présence de Patrick AUBRY, chef de projet de Cardiomed et SEVE, de Jean-Christophe LLORET, ingénieur système ayant participé { l’élaboration de Cardiomed, et de Jullian LOPEZ, opérateur du CADMOS spécialisé en facteurs humains.

La question soulevée lors de ce focus group était : Comment inciter ou contraindre les utilisateurs du système SEVE à bord, à respecter les protocoles, et notamment à effectuer toutes les actions nécessaires à la suite de l’expérience à chaque page ?

6.1.1.a. Démarche

Pour apporter des réponses { cette problématique, la réunion s’est déroulée comme suit : Une fois les participants accueillis, il leur est rappelé le problème que l’on veut tenter de

résoudre et les enjeux pour l’utilisabilité du système. Le fonctionnement de la réunion leur est présenté. Ils doivent notamment comprendre

que la réunion a deux buts principaux : d’une part une évaluation et un approfondissement d’idées déj{ existantes, d’autre part, éventuellement, la génération de nouvelles idées.

Les participants prennent connaissance de quelques idées déjà envisagées, par le biais de schémas sur une feuille de papier, brièvement décrits { l’oral (Figure 15, Figure 16).

La discussion commence sur des points dégagés des schémas papier. Lors de la discussion, toutes les solutions envisagées sont passées en revue, et les participants sont encouragés à rebondir sur les idées.

Lorsque la discussion s’est épuisée et que personne ne semble avoir d’idées supplémentaires, une synthèse est faite avant de clore la réunion.

6.1.1.b. Idées présentées lors de la réunion

6.1.1.b.1) Lisibilité des informations

Il s’agit de faciliter la lecture des informations, par différents moyens. Mise en valeur des informations cruciales, par exemple en les entourant ou en les

surlignant Hiérarchisation des informations, avec l’ajout de numéros correspondant { des étapes

sur chaque page. Compromis entre ces deux solutions, en mettant l’accent sur les informations les plus

importantes au sein du document hiérarchisé (numéro mis en valeur par exemple)

6.1.1.b.2) Contraintes utilisateur

Ces solutions obligent l’utilisateur { s’assurer qu’il a bien accompli toutes les étapes nécessaires avant de passer à la page suivante.

Cases à cocher, sur les étapes cruciales ou à chaque étape. Apparition d’un message rappelant la présence d’une manipulation importante {

effectuer avant de changer de page Variantes de ces solutions : On peut changer de page même sans cocher les pages, mais

un message de confirmation apparaît ; L’astronaute doit confirmer chaque étape par commande vocale ou tactile…



Figure 15 : Prototype présenté lors du focus group (checkpoints)

Figure 16 : Prototype présenté lors du focus group (mise en valeur des informations)

6.1.1.c. Sujets abordés lors de la discussion

6.1.1.c.1) Contraintes

Fenêtres d’avertissement ou de confirmation

Dénomination des fenêtres : Selon la norme utilisée { bord de l’ISS, les messages d’avertissement (Warning, Caution) sont réservés aux situations avec un risque réel. Il n’est donc a priori pas approprié de nommer une fenêtre informant du non-branchement d’un appareil, « avertissement ». Il s’agit en effet plutôt d’une simple information, qui, si elle n’est pas prise en compte, peut peut-être obliger à une réinitialisation du système Cardiomed, mais ne met en danger ni l’équipage ni la station.



Phénomène de répétition : La récapitulation des informations de chaque page sur une fenêtre pop-up { chaque fois que l’on change de page, sera vite ignorée par les utilisateurs, qui la fermeront certainement sans même regarder son contenu. Cette difficulté supplémentaire de la manipulation peut même entraîner un rejet du système. Si cette solution est adoptée, il faudra donc l’utiliser { bon escient.

Etapes à valider (cases à cocher)

Répétition : Comme pour le point précédent, la répétition d’une action { chaque étape peut vite

engendrer un sentiment de frustration puis de rejet. Il est donc important de réserver cette alternative à des situations très précises, ou de rendre la manipulation très naturelle.

Obligation de cocher : Si on ne peut pas passer { la page suivante tant que les cases requises n’ont pas été cochées,

il faut fournir suffisamment d’informations pour que l’utilisateur comprenne ce qui l’empêche de changer de page. Un manque d’information peut, encore une fois, entraîner le rejet du système.

Cela peut passer par une fenêtre pop-up, par un message suffisamment clair… Il s’agit de trouver un compromis entre la charge de travail et la visibilité de l’information.

6.1.1.c.2) Aspects technologiques

Automatisation

Si la technologie (fonctionnalités des instruments) le permet, il est toujours mieux d’automatiser la vérification, et de rendre le système conscient de la validation ou non d’une étape. Ainsi, une information disant que tel ou tel instrument nécessaire n’est pas encore branché, serait, si c’est possible, la meilleure solution.

Interactions naturelles

Les possibilités mentionnées au 6.1.1.c.1) pourraient susciter moins de réserves si l’interaction était plus naturelle qu’un clic sur un endroit précis ou un appui sur une touche. A cet effet, l’interaction vocale serait probablement la plus adaptée, sous réserve d’une bonne conception.

Une interaction tactile pourrait également répondre aux problématiques soulevées. Sur ce sujet, le laptop sélectionné pour SEVE disposera a priori d’un écran tactile. Il s’agit donc principalement d’identifier les fonctionnalités intéressantes { faire prendre en charge par ce mode d’interaction.

L’interaction vocale, en revanche, est encore peu utilisée dans le domaine des vols habités, toutefois une investigation plus poussée est nécessaire.

D’autres modes d’interaction possibles, comme l’interaction par gestes dans l’espace, pourraient être envisagés, en gardant { l’esprit toutes les contraintes liées { l’environnement d’une station orbitale.

6.1.1.c.3) Hiérarchisation

Types d’actions

Le problème de la hiérarchisation doit se traduire par une bonne différenciation des types d’actions : installations physiologiques (placement des instruments sur le corps), branchements (initialisation des appareils, branchement des câbles…)



Ce point est généralement respecté dans Cardiomed, puisque les différents types d’instructions sont décrits sur des pages distinctes ; il est important de le respecter également avec SEVE.

Hiérarchisation des étapes (« steps »)

Principe : Sous Cardiomed, au sein d’une même page, la plupart des étapes sont affichées de manière

équivalente, sous forme de points, avec parfois des sous-points. On peut aller plus loin de différentes manières :

Généraliser l’utilisation d’étapes générales composées de sous-étapes plus descriptives Proposer des étapes succinctes, puis afficher les précisions sous forme de pages

supplémentaires, sur le modèle des pages d’aide de Cardiomed Précautions à prendre : Une solution de ce genre suppose toutefois de savoir faire la différence entre des étapes

pouvant se contenter de peu d’explications, de par un entraînement ou une simplicité suffisants, des étapes plus compliquées nécessitant automatiquement des explications plus détaillées, qu’il serait donc malvenu de faire afficher par une action supplémentaire.

Il faut également être vigilant à la multiplication des sous-étapes, en particulier si il s’agit de les afficher par le biais de différentes pages ; en effet, dès lors qu’une « navigation » de type hypertexte est employée, il devient très facile de se « perdre ». Pour la même raison, il est important de pouvoir toujours naviguer facilement vers l’étape principale ou l’étape suivante.

6.1.1.c.4) Mode de communication des instructions

Informations graphiques

Il est en général intéressant, quand c’est possible, de se référer { une photo ou un schéma, plutôt qu’{ une description. Ainsi, un simple dessin et un bouton permettant de valider, sont plus parlants qu’une suite d’instructions détaillées. A ce sujet, certaines procédures utilisées par le CADMOS contiennent des phases où les instructions sont complètement décrites par schémas.

Dans ce cas, les instructions peuvent être complétées par des liens vers des pages d’aides plus détaillées. Il faut alors bien sûr prendre les précautions décrites au paragraphe précédent (6.1.1.c.3)).

Voix

L’énoncé, par synthèse vocale ou par enregistrement, des instructions, pourrait être intéressant à envisager, en particulier si il est couplé à une possibilité de commande vocale. Il s’agit donc d’un point dont il faut évaluer la pertinence. Il faut notamment voir si cette fonctionnalité serait effectivement utilisée dans un contexte potentiellement bruyant, et quelles sont les commandes les plus aptes à être prises en charge par ce mode.

6.1.1.d. Synthèse des résultats

6.1.1.d.1) Idées retenues

Le tableau suivant (Tableau 3) montre quelles solutions semblent les plus pertinentes en regard de la problématique.



Solution Avantages Inconvénients Précautions à prendre

Pertinence

Cases à cocher Prévention des erreurs

Charge de travail, répétition

A réserver aux étapes cruciales

/

Fenêtres de confirmation

Prévention des erreurs

Charge de travail, répétition

A réserver aux étapes cruciales

/

Actions de confirmation par commande vocale

Prévention des erreurs, interaction naturelle

Apprentissage (grammaire)

Bonne conception de l’interaction, étude de faisabilité (environnement sonore)

+

Actions par commande tactile

Prévention des erreurs, interaction naturelle

Apprentissage (gestes)

Bonne conception de l’interaction

+

Indications sur l’état du système

Compréhension du système

Paramètres inexploitables par l’utilisateur : incompréhension

Assurer une visibilité de l’information suffisante, donner des informations pertinentes

++

Hiérarchisation par types d’actions

Clarté des explications

++

Définition de sous-étapes

Lisibilité des informations

Faire un travail de réflexion sur la hiérarchisation

++

Sous-étapes sous forme de pages d’aide

Lisibilité des informations (si hiérarchisation pertinente)

Charge de travail, Charge cognitive

Informations optionnelles définies de manière pertinente, navigation très intuitive

+

Instructions graphiques

Charge de travail, clarté des informations

Manque de hiérarchisation, de linéarité

Les schémas doivent être bien conçus

++

Instructions vocales

Charge de travail Environnement bruyant

Etude de faisabilité, bonne conception ; doit être seulement complémentaire

+

Tableau 3 : Récapitulatif des solutions possibles sur la hiérarchisation des informations



6.1.1.d.2) Bilan

On voit que, si les idées évoquées ont été discutées de manière productive, peu d’idées alternatives ont été générées. Avec le recul, il aurait sans doute été plus intéressant de proposer moins de prototypes au départ, et de laisser les participants produire eux-mêmes ces prototypes, ce qui aurait permis de dégager plus d’idées sur les améliorations { apporter que de critiques sur les idées existantes.

De plus, le fait que deux des participants étaient déjà impliqués dans le projet Cardiomed, a probablement empêché une mise en cause trop profonde de l’existant.

6.1.2. Prototypage sur la hiérarchisation des informations

Suite au focus group du 16/06/2009, une série de prototypes a été réalisée, afin d’illustrer la mise en oeuvre des idées les plus pertinentes évoquées durant la réunion.

Deux types de prototypes ont été réalisés. Des prototypes papier, rendus interactifs par le biais d’un opérateur humain (en l’occurrence moi), montrent l’apparence des écrans et le séquencement des actions à effectuer. Comme on peut le voir (Figure 17, Figure 18, Figure 19), il s’agit d’écrans uniques, montrant, à chaque fois, un aspect de l’interaction (preuve de concept). En effet, le mécanisme de séries de pages suivies de manière linéaire ne nécessitait pas de prototyper une succession d’écrans { ce stade.

La mise en forme des instructions dans les pages de protocoles a été illustrée, quant à elle, par de simples fichiers texte, non interactifs (Figure 20).

Ces prototypes ont été évalués tour à tour par le maître de stage Jean-Christophe LLORET,

et par Jullian LOPEZ.

Figure 17 : Prototype montrant l'utilisation d'images



Figure 18 : Prototype montrant un mécanisme de cases à cocher

Figure 19 : Prototype sur l'automatisation des vérifications



Figure 20 : Prototype sur la mise en forme des instructions

6.1.2.a. Démarche

Pour les prototypes papier interactifs, la démarche a consisté { proposer { l’évaluateur une séquence d’actions, puis { recueillir ses commentaires.

Pour les prototypes non interactifs, il s’agissait principalement de montrer les différentes alternatives afin de recueillir une éventuelle préférence.

6.1.2.b. Résultats

Cases à cocher

Le principe des cases à cocher pour valider des steps suscite beaucoup de réserves. En effet, il semble difficile de distinguer les instructions « cruciales » du reste des informations, les séquences d’instructions étant complémentaires ; et, comme on l’a vu au 6.1.1.c.1), la multiplication des actions { valider de cette manière n’est pas souhaitable.

Une solution alternative consisterait à rendre cette vérification optionnelle, auquel cas il s’agirait plutôt d’un guide dans la lecture de la page (l’instruction en cours étant mise en valeur). Toutefois cette alternative pose des problèmes de clarté, en effet elle serait probablement peu utilisée (la charge de travail pour valider chaque étape étant trop importante), et une instruction mise en valeur sans raison entraînerait plutôt la confusion chez l’utilisateur.

Des tests utilisateurs ne pouvant être effectués pour infirmer ces réserves, il semble préférable de se passer de cette fonctionnalité dans le prototype final ; mais on pourra développer une page démontrant sa mise en œuvre, afin de l’évaluer quand ce sera possible.



Mode de représentation des informations

La page d’instructions modélisée sous forme d’images est très appréciée, il s’agit donc d’un point à généraliser. Les évaluateurs proposent également d’utiliser des symboles pour certaines instructions standards, { l’image de ce qui se fait avec la norme ODF (cf. 4.4).

Hiérarchisation

Pour les évaluateurs, les solutions comportant une hiérarchisation réelle sont plus pertinentes ; associées à une numérotation systématique, elles permettent de suivre les instructions beaucoup plus aisément.

Le système de pages d’aide présenté, qui détaille de façon optionnelle les procédures a priori triviales, est également apprécié puisqu’il permet une meilleure clarté en n’affichant que les informations les plus pertinentes.

6.1.3. Système de pages d’aide

L’analyse de l’existant avait mis en lumière une navigation peu aisée entre les pages d’aide et les pages de protocole, alors que l’une des solutions retenues pour faciliter la lecture des informations était la généralisation du concept de pages d’instructions optionnelles. Il était donc important de proposer une vraie alternative pour répondre à cette problématique.

Comme pour la problématique précédente, un brainstorming aurait probablement permis d’apporter des réponses plus pertinentes, mais ne pouvait être organisé.

Une réunion de travail a donc été organisée le 30/07/2009 avec Jean-Christophe LLORET et

Jullian LOPEZ, afin d’apporter des éléments de réponse { la question : Comment présenter les pages d’instruction optionnelles au cours de la navigation dans les protocoles médicaux, de manière à faciliter la navigation?

6.1.3.a. Démarche

Une fois les participants installés, le thème de la réunion leur a été énoncé (en effet ils connaissaient déjà tous le système Cardiomed et les exigences de SEVE). La description de quelques idées a permis d’amorcer la discussion. Les participants étaient invités, { chaque occasion, à rebondir sur les idées évoquées. Les idées recensées ont ensuite immédiatement donné lieu { un débat, afin d’évaluer sommairement leur pertinence.

6.1.3.b. Résultats de la discussion

Au cours de cette réunion, plusieurs idées ont pu être abordées et débattues.

6.1.3.b.1) Limitation des niveaux d’aide

La première remarque, est qu’il n’est pas souhaitable de proposer plus de 2 niveaux de navigation : un niveau général (instructions des protocoles), et un niveau optionnel (instructions triviales, cas dégradés). Dans le contexte d’une suite d’instructions, tout niveau supplémentaire multiplierait les risques d’égarement.

6.1.3.b.2) Navigation à travers les pages

Cette option, utilisée sur Cardiomed, consiste à « naviguer », comme sur internet, de page en page, chaque nouvelle page étant affichée sur tout l’écran.

Son adoption sur SEVE devrait passer par un nouveau mode de fonctionnement, en effet le principal problème était la charge de travail nécessaire pour passer d’une page { l’autre en cas de nécessité d’allers-retours.



On pense bien sûr aux commandes vocales, qui pourraient alléger cette charge de travail ; la reconnaissance de gestes sur la page en cours pourrait être une autre piste, mais elle ne peut être mise en œuvre sans tests utilisateurs.

6.1.3.b.3) Division de l’écran en 2 parties

Cette solution, qui consiste à afficher la page optionnelle et la page principale simultanément, dans le même écran coupé en 2, n’a pas remporté l’adhésion des participants : en effet elle pose des problèmes de lisibilité, les instructions étant affichées dans une zone plus petite.

6.1.3.b.4) Affichage dans une fenêtre «popup»

Cette solution consiste à afficher les instructions optionnelles dans une nouvelle fenêtre plus petite. Elle présente plusieurs avantages.

Affichage simultané des instructions principales et des instructions optionnelles : Cela permet d’éviter des allers-retours peu pratiques entre les pages.

Modularité du placement de la fenêtre : L’utilisateur peut s’arranger pour conserver certaines informations visibles.

Page principale toujours visible : Limite les possibilités d’erreurs de navigation. Parmi les inconvénients potentiels, on trouve la nécessité de gérer différentes fenêtres sans

« perdre » l’utilisateur, et la nécessité d’occulter une partie au moins de la page principale.

Gestion des fenêtres

Il ne faut surtout pas multiplier les fenêtres optionnelles. Ainsi il est important de savoir comment gérer leur fermeture, mais aussi de réfléchir à la façon de gérer plusieurs demandes de pages d’aides.

Fermeture automatique L’utilisateur peut a priori avoir encore besoin de la page d’aide même s’il revient (par un

clic) sur la page principale, il n’est donc pas pertinent de fermer les fenêtres optionnelles { ce moment-là.

En revanche, lorsqu’il change de page sur le protocole principal, il n’a normalement plus besoin de la page d’aide. Si elle n’est pas déj{ fermée, il paraît approprié de la fermer automatiquement à cette occasion.

Cette affirmation n’étant pas triviale, cette option peut être utilisée { des fins de démonstration dans le prototype développé, mais il sera nécessaire de l’évaluer grâce { ce prototype.

Fermeture manuelle La fermeture traditionnelle (croix en haut { droite), a priori associée { la fermeture d’un

programme, peut entraîner une confusion si elle est l’unique moyen de fermer un fenêtre optionnelle. Il semble préférable de proposer un item interactif (bouton par exemple) permettant de fermer explicitement la page d’aide. Cet item devrait être placé { la fin des instructions.

Ouverture de plusieurs pages d’aide La recommandation évoquée au 6.1.3.b.1) (limitation des niveaux d’aide) permet de

s’assurer qu’aucune suite de fenêtres ne sera ouverte. En revanche, une même page d’un protocole peut comporter plusieurs pages d’aide, que l’utilisateur pourrait donc solliciter de manière parallèle.



Dans ce cas, il semble préférable de ne pas multiplier les fenêtres à afficher, le caractère séquentiel des instructions assurant qu’il n’est pas nécessaire d’afficher deux pages d’aide simultanément. On peut donc opter pour une solution permettant d’utiliser la même fenêtre pour toute nouvelle demande de page d’aide.

Gestion de l’affichage

Pour que cette solution soit viable, il faudrait que la lisibilité des instructions de chacune des pages affichées simultanément soit optimale. Plusieurs pistes ont été envisagées.

Fenêtres transparentes L’utilisation de fenêtres optionnelles transparentes { un certain degré, pourrait permettre

d’afficher simultanément plusieurs informations. Dans le cas de pages d’instructions textuelles, cette solution pourrait nuire à la lisibilité, mais, dans le cas où l’information { voir par transparence est composée de schémas ou encore de courbes physiologiques (pages de calibration des instruments), elle mériterait d’être testée.

Redimensionnement Il pourrait être utile de permettre { l’utilisateur de redimensionner la fenêtre optionnelle.

Toutefois, cela implique aussi la possibilité de l’apparition d’une barre de défilement, vertical ou horizontal, qui est en tout cas exclue des pages d’instructions principales afin de s’assurer que toutes les informations nécessaires sont visibles.

Place de la fenêtre La place d’apparition de la fenêtre { l’écran est à considérer : en effet, une fenêtre

optionnelle s’affichant systématiquement au-dessus d’une information importante peut être irritante pour l’utilisateur. On peut par exemple mémoriser la dernière position modifiée par l’utilisateur, ou bien spécifier cette position sous forme de paramètre au sein même de la définition de la page par le rédacteur.

6.1.3.b.5) Bloc d’instructions non visible par défaut

Cette solution consiste { ne pas afficher l’aide (sous-instructions) par défaut, et à proposer un item, comme un symbole ‘+’ par exemple, permettant de rendre ces informations visibles, décalant d’autant le reste des instructions vers le bas.

Comme au 6.1.3.b.4), cette solution permet l’affichage simultané des instructions principales et optionnelles, et laisse toujours visible la page principale. Elle présente toutefois quelques inconvénients, en particulier en termes de mise en page : comme on l’a vu, il faudrait éviter les barres de défilement vertical, ce qui peut être difficile avec cette option.

6.2. Visualisation des informations physiologiques

Dans cette partie, on considère que les astronautes n’ont pas l’expertise nécessaire pour être les premiers destinataires de cette fonctionnalité (bien que des astronautes puissent être médecins de métier!).

La visualisation des paramètres physiologiques leur permet surtout de juger de la bonne marche du système et des instruments, et peut éventuellement les renseigner sur leur état de santé général ; mais les utilisateurs considérés pour la conception restent les médecins qui assistent les astronautes depuis le sol durant la mise en œuvre des protocoles.

Les problématiques dégagées ici se nourrissent donc principalement de l’interview rapportée en 4.2.3), ainsi que sur les remarques d’un utilisateur après la manipulation d’un tout premier prototype fonctionnel décrit en 6.2.1.



Il aurait été intéressant de proposer systématiquement aux utilisateurs des prototypes montrant, avec une précision incrémentale (maquettes papier, maquettes logicielles offline, prototype online, intégration au prototype final), la mise en œuvre des solutions retenues : des modifications auraient ainsi pu être apportées dès les problèmes relevés. Mais pour la plupart des choix, les médecins n’étaient plus disponibles au moment opportun, et leurs remarques ne pourront porter que sur le prototype final.

6.2.1. Prototype sur la visualisation des informations

Un peu avant le milieu du stage (mois de juin 2009), une toute première version du prototype fonctionnel était disponible. Ce prototype vertical, online, permettait surtout de tester la communication avec l’instrument CNAP, et existait en 2 version, l’une utilisant Joram et l’autre Octave (voir Partie 5 :). L’IHM, réalisée grâce { l’éditeur intégré { NetBeans, était identique dans les deux versions (Figure 21). Elle permettait :

d’envoyer des commandes (Start et Stop) de visualiser la pression sanguine continue sous forme de courbe de visualiser les pressions systolique, moyenne et diastolique sous forme textuelle

Figure 21 : Prototype fonctionnel sur la visualisation des paramètres

Ce prototype a permis de constater que les mesures acquises avec Joram ne l’étaient pas de

manière fluide, problème qui a été résolu plus tard (voir 7.1.1.b). Il a également été évalué par l’un des médecins (Marc-Antoine CUSTAUD). Celui-ci a ainsi pu

valider l’apparence générale des courbes, dans la mesure où elle était alors peu détaillée (pas de repères, pas de modifications possibles par l’utilisateur). Il a également précisé les besoins qu’il pouvait avoir pour l’évolution de ce prototype.

6.2.2. Aspect des synoptiques

Si les utilisateurs sont globalement satisfaits des fonctionnalités de visualisation des paramètres sur Cardiomed, une évolution du système est l’occasion d’améliorer tous les points possibles.

6.2.2.a. Couleurs

Malgré un grand nombre de choix différents dans le domaine de la visualisation de paramètres, aucune préférence particulière pour une option ou une autre ne ressort des



entretiens avec les utilisateurs en ce qui concerne les couleurs { utiliser. L’important est surtout de différencier de manière claire la courbe, les repères, et le fond.

Il est aisé de proposer { l’utilisateur le choix de son propre panel de couleurs au sein de l’application, comme le font certains logiciels de visualisation médicale. Toutefois cette option ne semble pas présenter d’intérêt : a priori peu utilisée quand elle est proposée, elle le serait encore moins dans le cas d’un système utilisé de manière très ponctuelle, dans le contexte assez formel d’une salle d’opérations.

J’ai donc choisi arbitrairement les couleurs, qui, dans le cas où elles ne permettraient pas d’observer de manière optimale les paramètres, pourront être modifiées dans le prototype. Ces couleurs (fond vert très sombre, courbes vert clair) étaient implémentées dans le prototype décrit en 6.2.1, et n’ont pas suscité de commentaire particulier.

6.2.2.b. Repères

Afin de connaître précisément les valeurs envoyées par les instruments, et donc l’évolution de l’état de santé des astronautes, il est nécessaire de fournir suffisamment d’indications sur les synoptiques, par le biais de repères. Aucune remarque n’a été faite par les utilisateurs sur ce point, on considère donc que les solutions { l’œuvre sur Cardiomed sont convenables.

6.2.2.c. Paramètres modifiables

On a vu, en phase d’analyse préliminaire, que certains paramètres non pertinents pouvaient être modifiés en mode sol ou en mode bord.

6.2.2.c.1) Paramètres des instruments en mode sol

En mode sol, les commandes permettant de modifier le signal des instruments devraient tout simplement être inaccessibles (mais toutefois visibles, grisées, afin que les opérateurs au sol connaissent l’interface que l’astronaute a { disposition)

6.2.2.c.2) Paramètres non pertinents en mode bord

Certains paramètres de visualisation ne sont pas exploitables par les astronautes (comme la période affichée). Dans ce cas, les commandes correspondantes sont grisées, et il existe une case à cocher nommée « Accéder aux valeurs », servant dans les situations où les médecins veulent que l’astronaute modifie le paramètre, pour une vérification par exemple.

6.2.3. Navigation sur les courbes de visualisation

Un besoin évoqué par l’utilisateur lors de l’utilisation du prototype, était la possibilité de naviguer sur les courbes de visualisation de signaux, et en particulier de revenir en arrière, au cours d’une expérience. Alors que, dans Cardiomed, seuls certains paramètres peuvent être vus sur une plage de temps plus large, les utilisateurs veulent plus de souplesse et une prise en compte de plus d’instruments.

La principale contrainte à laquelle faire face, est la nécessité de pouvoir à tout moment

observer le défilement actuel de la courbe (afin de remarquer les évolutions éventuelles de l’état de santé du sujet).

Afin d’apporter des éléments de réponse à cette problématique, et à défaut de disponibilité des utilisateurs, elle a été traitée à la suite de la réunion du 30/07/2009.

Plusieurs idées ont ainsi été évoquées : Affichage des 2 modes de visualisation dans la même interface, si la place le permet Séparation du panel de visualisation en deux parties Apparition d’une fenêtre « pop-up » supplémentaire, ne cachant pas les paramètres

importants par défaut



Apparition d’une fenêtre « pop-up » permettant de voir l’interface principale par transparence.

Il est toutefois difficile de faire un choix sans consulter les utilisateurs finaux : ainsi, dans

l’immédiat, on reprendra la méthode utilisée sur Cardiomed (apparition d’une nouvelle fenêtre), avec la possibilité de la faire apparaître de manière transparente, afin que cette technique puisse être testée.

6.2.4. Alarmes physiologiques

Comme indiqué en 4.2.3.d.1), le mode de notification d’alarme physiologique préféré par les utilisateurs est le clignotement du paramètre mis en cause. Ce clignotement peut être implémenté de différentes façons : couleur, clignotement brusque ou en dégradés, taille…

Bien que des paramètres par défaut puissent être choisis, notamment en s’appuyant sur des systèmes similaires déjà existants, il conviendrait, pour optimiser cette solution, d’effectuer des tests utilisateur mettant en œuvre ces différentes options.

Mais, comme on l’a vu, aucun test n’a pu être effectué au cours du stage, les médecins n’étant plus disponibles au moment approprié. Il est toutefois possible d’utiliser le prototype final pour les mettre en œuvre : on pourra notamment mesurer la rapidité avec laquelle les médecins remarquent l’apparition d’une alarme, mais également la perte de concentration entraînée par la persistance d’un avertissement par exemple.

6.2.5. Marqueurs temporels

Actuellement, le contexte dans lequel a été créé le marqueur temporel est en général énoncé { l’aide d’un dictaphone. Le déclenchement automatique d’un enregistreur lorsqu’un marqueur est ajouté répondrait donc convenablement au besoin.

Toutefois d’autres solutions sont envisageables. L’enregistrement audio automatique de toute la session, bien que simplifiant encore plus l’opération, semble difficile { mettre en œuvre (taille des données), et plus contraignant pour le post-traitement. En revanche, on peut réfléchir { la possibilité de décrire par un texte la raison d’être du marqueur, comme c’est le cas sur d’autres systèmes dédiés { l’acquisition de mesures dans des cadres moins contraignants.

Partie 7 : Réalisation du prototype fonctionnel Le manque de disponibilité des utilisateurs rendant difficile une évaluation des solutions

par eux { chaque stade de la conception, j’ai décidé de commencer le développement du prototype final à partir du système décrit en 6.2.1, en intégrant les unes après les autres les solutions envisagées au sein de ce prototype incrémental. J’ai tenté de laisser aux opérateurs des choix afin de pouvoir, lorsque les utilisateurs seront en mesure de les tester, expérimenter les différentes alternatives dégagées.

7.1. Technologies

7.1.1. Contrôle/commande des instruments

7.1.1.a. Envoi des mesures à des stations distantes : Joram

Suite { l’évaluation comparative qui a été faite { la Partie 5 :, la solution retenue pour la diffusion des mesures est un serveur Joram. En effet, comme on l’a vu alors, cette solution est préférable à Octave dans le cadre du stage.



L’architecture adoptée { cette occasion est décrite en détail en 7.2.1 : les mesures sont acquises sur le port série grâce { l’API JavaComm (la technologie Java la plus utilisée pour cette tâche), puis envoyées à tous les clients abonnés (applications sol et bord) via un topic Joram.

7.1.1.b. Commandes et acquisition des mesures

7.1.1.b.1) Communication entre l’application et les instruments

Pour envoyer des commandes aux instruments, on utilise une simple connexion aux ports série avec l’API JavaComm. En effet, seuls les astronautes, dont le laptop est en connexion directe avec les instruments, peuvent envoyer des commandes : il est inutile d’adopter une architecture de type réseau.

De même, comme précédemment, les mesures sont acquises grâce { l’API JavaComm. Comme on l’a vu, les premiers prototypes utilisant cette solution montraient que les

mesures étaient acquises de manière saccadée : en effet, vu le débit important des données, il était important de proposer un système de buffers solide, chose que je n’avais pas prise en compte tout d’abord. Les informations n’étant pas acquises assez régulièrement, le port série devenait encombré et pouvait même se bloquer.

7.1.1.b.2) Protocoles de communication

On notera que, les instruments étant pour la plupart nouveaux (CNAP et ECG), il m’incombait de comprendre et d’implémenter les protocoles de communication. En effet, si quelques exemples existaient (applications C/C++ développées par Erems), ils étaient incomplets et ne répondaient pas aux besoins du prototype. J’ai donc utilisé, d’une part, les documents de référence fournis avec les instruments (parfois incomplets), et, d’autre part, l’application Free Serial Port Monitor (observateur de port), afin de comprendre les successions de trames de données échangées sur les ports.

Pour vérifier mes suppositions, je me suis tout d’abord aidé de l’outil Best (voir 5.2.2), qui s’est révélé très utile pour formaliser ces nouvelles données et les corriger (erreurs de compréhension ou paquets de données non référencés dans les documents) grâce { l’outil de décommutation de paquets. Une fois la solution Best/Octave abandonnée, le mode de visualisation offert par cet outil a ensuite tout de même grandement facilité leur conversion vers un analyseur plus traditionnel.

7.1.2. Interfaces

7.1.2.a. Définition de pages au format XML : SwiXML

7.1.2.a.1) Choix de la technologie

Dans la perspective de la création d’un éditeur de protocoles, permettant de créer des pages d’expérience statiques autant que des pages dynamiques de configuration et d’expérimentation, on s’est intéressé aux technologies existantes permettant de définir des interfaces en utilisant le format XML.

Ce format étant largement utilisé à des niveaux très variés, le choix était assez large. Parmi les technologies les plus connues permettant la génération d’IHM { partir de fichiers XML, on trouve XUL (fondation Mozilla), Flex (Adobe)...

La technologie choisie pour le développement du prototype est SwiXML. Il s’agit d’un

moteur de génération d’interfaces Swing (Java) à partir de fichiers XML. Cette technologie a été sélectionnée pour : Son utilisation large et reconnue (membre de l’organisme java.net) Son appartenance au domaine de l’open-source Sa compatibilité totale avec Java/Swing Sa couverture complète du besoin



7.1.2.a.2) Puissance d’expression

SwiXML permet de définir la disposition des composants d’une interface, en utilisant le système de Layouts de Swing. Il est possible d’insérer des composants personnalisés si ils héritent de composants Swing : les méthodes portant sur les attributs (set…(xxx)) étant accessibles depuis le XML, sous forme d’attributs XML (ainsi, setY(xxx) est appelé si la balise XML déclarant l’objet contient l’attribut « y=’’xxx’’ »).

Par le biais d’une instance de classe faisant partie des attributs du moteur, les instanciations spécifiques des composants sont prises en compte par le moteur, à travers un attribut XML ‘id’.

On peut également attribuer aux composants des actions, définies antérieurement et déclarées au moteur après son initialisation.

7.1.2.a.3) Intégration dans le prototype

Afin de répondre au besoin, il est nécessaire de déclarer, dans la classe avec laquelle est initialisé le moteur SwiXML, tous les composants (panels de visualisation, boutons si nécessaire…) et toutes les actions pouvant être utilisés par l’interface Selon le fichier XML chargé, certains sont alors initialisés avec les valeurs voulues et affichés, et d’autres non.

Cela signifie que pour le moment, si l’on veut rajouter un instrument et de nouveaux composants d’interface par exemple, l’équipe projet doit mettre { jour cette classe pour prendre en compte cette nouveauté.

7.1.2.a.4) Exemple

La Figure 22 montre un exemple de description d’interface (expérience mettant en œuvre trois instruments) au format SwiXML. La Figure 23 montre, entouré en orange, le résultat obtenu { l’écran.

<?xml version="1.0" encoding="UTF-8"?> <panel layout="GridLayout(1,2,10,10)" border="TitledBorder(Experimentation)"> <panel layout="FlowLayout"> <panel layout="FlowLayout" border="TitledBorder(CNAP)"> <vbox> <panel layout="BorderLayout" border="TitledBorder(Commands)"> <vbox> <hbox constraints="BorderLayout.WEST"> <button id="cnapStartButton" action="cnapStartAction" text="Start"/> <button action="cnapStopAction" text="Stop"/> <button id="cnapChangeFingerButton" action="cnapChangeFingerAction" text="Change finger"/> </hbox> <hbox layout="FlowLayout"> <label text="Device mode : "/> <textField id="cnapDeviceModeDisplayer" disabledTextColor="black" enabled="false" columns="10"/> </hbox> </vbox> </panel> <panel layout="FlowLayout" border="TitledBorder(Continuous BP)"> <curveDisplay id="cnapCurveDisplay" width="300" height="120"/> </panel> <panel layout="FlowLayout" border="TitledBorder(Systolic/Mean/Diastolic blood pressure)"> <panel layout="GridLayout(3,2,10,10)"> <label text="Systolic : "/> <textDisplay id="cnapSbpTextDisplay"/> <label text="Mean : "/> <textDisplay id="cnapMbpTextDisplay"/> <label text="Diastolic : "/> <textDisplay id="cnapDbpTextDisplay"/> </panel> </panel> </vbox> </panel> </panel> <panel layout="FlowLayout"> <vbox> <panel layout="FlowLayout" border="TitledBorder(ECG)">



<vbox> <panel layout="BorderLayout" border="TitledBorder(Commands)"> <hbox constraints="BorderLayout.WEST"> <button id="ecgStartButton" action="ecgStartAction" text="Start"/> <button id="ecgStopButton" action="ecgStopAction" text="Stop"/> <button id="ecgConnectButton" action="ecgConnectAction" text="Connect"/> </hbox> </panel> <panel layout="FlowLayout" border="TitledBorder(ECG Lead II)"> <curveDisplay id="ecgCurveDisplayLead2" dezoom="10" width="300" height="120"/> </panel> </vbox> </panel> <label text=" "/> <panel layout="FlowLayout" border="TitledBorder(HLTA Measurements)"> <panel layout="FlowLayout"> <panel layout="GridLayout(3,2,10,10)"> <label text="Systolic BP : "/> <textDisplay id="hltaSbpTextDisplay"/> <label text="Mean BP : "/> <textDisplay id="hltaMbpTextDisplay"/> <label text="Diastolic BP : "/> <textDisplay id="hltaDbpTextDisplay"/> </panel> </panel> </panel> </vbox> </panel> </panel>

Figure 22 : Fichier XML décrivant la page d'expérimentation

Figure 23 : Page d'expérimentation générée à partir du fichier XML



7.1.3. Composants graphiques

Pour la visualisation des paramètres physiologiques, j’ai choisi Java2d : il s’agit en effet d’une librairie gratuite, bien reconnue, et permettant une grande puissance d’expression avec de bonnes performances. Elle est de plus entièrement conçue pour Java et ne pose donc pas de problèmes de compatibilité.

Une autre option possible était OpenGL (grâce { l’API jogl), mais cette solution, dont les performances et la puissance d’expression étaient équivalentes dans le cadre de ce projet, présentait des problèmes de gestion de l’affichage lors des changements de page de protocole.

Les autres composants sont les standards Swing (affichés avec le ‘Look-and-Feel’ Windows,

plus agréable). Il s’agit en effet d’un des standards les plus utilisés en Java, et qui convient très bien au projet.

7.1.4. Définition des protocoles et des fichiers astronautes

De manière similaire à Cardiomed, les protocoles sont définis en XML. La Figure 24 montre la description du protocole implémenté : les titres de pages correspondent à des fichiers SwiXML (voir 7.1.2.a), alors que les balises « init » annoncent les instruments présents sur la page.

Sur la Figure 25, on peut voir l’affichage d’une page d’instructions faisant partie de ce protocole, ainsi que les onglets (en haut) et les boutons (en bas) permettant la navigation.

<?xml version="1.0" encoding="UTF-8"?> <protocol> <unstowage> <page> <title>09010_US_PresentationListe</title> </page> <page> <title>09060_US_CNAP</title> </page> <page> <title>09060_US_ECG</title> </page> <page> <title>04050_US_HLTA</title> </page> <page> <title>10040_US_Consumable</title> </page> </unstowage> <installation> <page> <title>10110_CO_EcgElectrodesSetup</title> </page> <page> <title>10120_CO_EcgCable</title> </page> <page> <title>09140_CO_EcgConfiguration</title> <init>ecg</init> </page> <page> <title>10160_CO_EcgVerification</title> <init>ecg</init> </page> <page> <title>09140_CO_EcgGlobalVerification</title> <init>ecg</init> </page> <page> <title>04160_CO_HLTAArmcuffSetup</title> </page> <page> <title>04165_CO_HLTAArmcuffSetup2</title> </page>



<page> <title>00200_CO_HLTAVerification</title> <init>hlta</init> </page> <page> <title>10150_CO_CnapCuff</title> </page> <page> <title>10180_CO_CnapVerification</title> <init>cnap</init> </page> <page> <title>09200_CO_GeneralVerification</title> </page> </installation> <experiment> <page> <title>09400_Experimentation</title> <instruments> <instrument>cnap</instrument> <instrument>ecg</instrument> <instrument>hlta</instrument> </instruments> </page> </experiment> <uninstallation> <page> <title>09610_UI_Undress</title> </page> <page> <title>04680_UI_EcgUnInstall</title> </page> <page> <title>04680_UI_HltaUnInstall</title> </page> <page> <title>10640_UI_CnapUnInstall</title> </page> </uninstallation> <stowage> <page> <title>09900_ST_PresentationListe</title> </page> <page> <title>09910_ST_Last</title> </page> </stowage> </protocol>

Figure 24: Description XML du protocole implémenté

7.2. Conception logicielle

7.2.1. Communication avec les instruments (noyau fonctionnel)

7.2.1.a. Principes de fonctionnement de la partie Joram

Le mode de Joram qui nous intéresse pour ce prototype est le mode multipoints (voir 5.3.2) Ainsi 3 topics sont définis : CnapTopic, HltaTopic, et EcgTopic.

Les informations de chaque instrument sont transmises par un Publisher dédié : pour le CNAP et le HLTA, un message est configuré avec les propriétés « type », donnant le type d’information envoyée (type de mesure, alarme, acquittement..), et « valeur », contenant la valeur reçue de l’instrument. Pour l’ECG, qui peut avoir une fréquence de 1000 Hz (1000 mesures par seconde), il est impossible d’envoyer de manière fluide un message pour chaque mesure : on créée donc des messages contenant une série de mesures. Chaque message a une propriété « nb » correspondant au nombre de mesures, puis une suite de propriétés « valeur1 »… « valeur n » donnant les mesures.



Ces messages sont lus par des Subscribers, qui interpréteront de manière indépendante ces mesures.

Figure 25 : Affichage de la page d'aide "10110" (placement des électrodes)

7.2.1.b. Diagramme de classes du noyau fonctionnel

Ce diagramme (Figure 26) présente l’architecture qui permet { l‘application : de recevoir un signal d’un port série donné et de le transmettre au serveur Joram, de recevoir et traiter ce message. Les classes présentées correspondent aux fonctions suivantes : Mise en place du service Joram : La classe ClassicAdmin initialise le service Joram et les

topics qui seront utilisés. Lecture des ports : La classe abstraite SerialPortReader et les classes filles spécialisées

sont abonnées à un port série correspondant à un instrument. Analyse des données reçues : La classe abstraite Parser et les classes-filles spécialisées

sont des Threads qui vont effectuer les traitements sur les données envoyées par SerialPortReader.

Envoi des données traitées : La classe abstraite Publisher et les classes-filles spécialisées sont connectées au service Joram : elles créent et publient les messages correspondant aux données qu’elles reçoivent.

Mise en place de la réception : La classe abstraite Subscriber et les classes-filles spécialisées initialisent l’abonnement aux topics.

Réception des données : Les classes-filles spécialisées de la classe Joram MessageListener correspondent { l’abonnement { un topic : quand un message sur ce sujet est publié, leur méthode « onMessage » est appelée.



Exploitation des données : La classe DialogAdapter fait le lien avec la partie dialogue de l’application.

Figure 26: Classes d'une application utilisant Joram

7.2.2. Architecture générale de l’application

7.2.2.a. Modèle : Arch

Le modèle retenu pour l’implémentation du prototype final est le modèle Arch, qui distingue 5 composants.

Interaction : Il s’agit des composants permettant d’interagir avec l’application, et des

dispositifs physiques d’interaction. Dans notre cas, il s’agit de la vue principale, des écrans de protocole, des courbes, des dispositifs d’interaction éventuels…

Présentation : Il fait le lien entre les composants d’interaction et le dialogue. Il permet notamment d’accéder aux composants d’interaction indépendamment de la plateforme.



Dialogue : Il permet de maintenir l’application dans un état consistant, en vérifiant la cohérence des instructions utilisateurs et des données du système.

Adaptateur du domaine : Il gère l’adaptation des données en entrée et en sortie au domaine de l’application. Pour nous, il s’agit principalement de convertir les données physiologiques et numériques, de gérer les pages de protocoles, l’interaction entre les instruments…

Noyau fonctionnel : C’est la partie non interactive de l’application. Dans notre cas, il s’agit de gérer les ports série, et d’envoyer et recevoir les données via Joram.

En effet, le projet comportant un travail non négligeable se situant au niveau du noyau

fonctionnel, il était préférable de bien différencier chaque couche, afin de pouvoir travailler indépendamment sur chaque partie.

J’ai ainsi pu tester plusieurs solutions techniques pour la mise en œuvre du noyau fonctionnel (Octave/Joram), mais également au niveau de la restitution des données (Java2d/OpenGL), sans que les autres couches soient affectées.

Enfin, la décomposition de la présentation et de l’interaction a facilité l’intégration successive des différentes solutions au sein du prototype.

7.2.2.b. Diagramme de classes

Ce diagramme (Figure 27) montre le diagramme de classe qui correspond au prototype final.

On retrouve les composants décrits au 7.2.2.a (les classes dessinées en rouge correspondent aux composants non spécifiques au projet).

Interaction (en vert) :

MainFrame : La page principale, qui contient l’en-tête (récapitulatif du protocole et du fichier utilisateur choisi, logs), le pied de page (navigation au sein du protocole médical), et une zone dans laquelle sera affichée la page actuelle lors de l’appel { « loadCurrentPage » (visible sur la Figure 23)

InstrumentMeasurementViewer : L’interface java qui définit les méthodes nécessaires pour qu’un composant puisse afficher les paramètres envoyés par un instrument

CurveDisplay : Un composant qui affiche les informations sous forme de courbe TextDisplay : Un composant qui affiche les informations sous forme de bloc de texte CurveDisplayDetails : La fenêtre qui apparaît quand l’utilisateur double-clique sur une

vue d’un paramètre (vue plus détaillée de ce paramètre) (voir Figure 28) HelpPage : La fenêtre qui s’ouvre quand l’utilisateur demande une aide.

Présentation (en rose) :

Presentation : Une interface qui résume les opérations nécessaires pour faire le lien entre le dialogue et les composants d’interaction

MainViewManager : Il s’agit de l’implémentation de Presentation qui a été développée. Elle gère la modification des vues en fonction des mesures reçues, répercute les commandes utilisateur sur le dialogue, mais gère également les paramètres du moteur SwiXML.

Dialogue (en bleu) :

Cette classe assure la cohérence du système, en répercutant les commandes et les appels venant de l’utilisateur ou du noyau fonctionnel seulement si le système est dans un état consistant.



Figure 27: Classes du prototype final

Adaptateur du domaine (en jaune) :

Adapter : Modifie les mesures venant du noyau fonctionnel selon les paramètres qu’il connaît, par exemple coefficient de conversion des données numériques en données physiques, déclenchement d’une alarme si un seuil est atteint…

SerialPortCommander : Cette classe a la charge d’initialiser la connexion avec les instruments ; puis, au cours de la session, elle gère également l’envoi de commandes. Pour que Dialog connaisse l’état du système, les méthodes « connectInstrument » et « sendCommand » renvoient un booléen indiquant la réussite de l’opération.

ProtocolBrowser : Cette classe gère la navigation à travers les pages du protocole à travers les méthodes « goToNextPage », « goToPreviousPage ». Elle permet d’obtenir la référence de la page courante, mais également des instruments qui seront { l’œuvre sur cette page.



Noyau fonctionnel (en orange) :

Cette partie, qui correspond à la gestion des ports séries et du serveur Joram, a en grande partie été traitée en 7.2.1.b.

On peut ajouter à ce qui a été décrit : SerialPortWriter : Un thread qui envoie des commandes simples au port correspondant à

un instrument (suite de valeurs). Par exemple, pour donner au CNAP l’ordre de commencer les mesures, on lui envoie les valeurs 0x00, 0x01.

CommandsSender : Une classe qui utilise SerialPortWriter pour envoyer des commandes plus complexes. Par exemple, pour communiquer avec le CNAP, il faut lui envoyer au moins une fois par seconde le signal 0x00 – 0x08 (« ping »). Dans l’application que j’ai développée, ces pings sont envoyés toutes les 800 millisecondes par un CommandsSender dédié qui ne s’arrête que lorsque la connexion est coupée.

ParserVariables : Cette classe permet de stocker les variables utiles pour l’analyse des données (une nouvelle instance de Parser étant créée à chaque notification de réception sur le port série). Elle gère également l’enregistrement de toutes les mesures, dans un format similaire à celui des données de Cardiomed, sur le disque dur du laptop.

Figure 28 : Vérification globale de l'ECG et vue détaillée d'une des pistes



Partie 8 : Bilan

8.1. Contributions au projet

8.1.1. Déroulement

Le diagramme suivant (Figure 29) montre le déroulement réel du projet, à mettre en perspective avec le diagramme prévu présenté en 3.4.3.a.

On voit que la partie ‘communication avec les instruments’ a pris plus de temps que prévu, mais qu’elle s’est déroulée également en parallèle avec d’autres activités, en particulier la conception. En effet, de nombreux points { améliorer ont subsisté sur cet aspect, jusqu’{ tard dans le stage.

L’imbrication plus grande entre conception et prototype final s’explique quant à elle par le développement d’un prototype incrémental.

Figure 29 : Diagramme de Gantt réel

8.1.2. Réalisations

8.1.2.a. Etudes

Le Tableau 4 résume les principales propositions que j’ai formulées durant le stage, soit en termes de choix technologiques, soit en termes de recommandations sur les Interfaces Homme-Machine.



Problématique Choix Raison

Transmission des données

Joram Meilleure compatibilité avec les instruments du projet, plus simple d’utilisation dans le cadre du stage

Description des interfaces en XML

SwiXML API spécifique à Java/Swing, bonne couverture des besoins du projet

Lisibilité des informations

Division systématique en étapes et sous-étapes

Meilleure hiérarchisation

Numérotation Suivi d’une suite d’instructions plus facile

Système de pages d’aide pour les instructions triviales

Informations importantes plus lisibles

Utilisation d’images et de schémas

Compréhension des instructions facilitée

Gestion des pages optionnelles

Fenêtres supplémentaires

Affichage simultané de plusieurs niveaux d’instructions, minimisation du risque d’erreurs de navigation

Navigation dans l’interface

Amélioration de la navigation au clavier

Meilleure facilité d’utilisation

Alarmes physiologiques Alarme affichée par un clignotement du paramètre

Méthode éprouvée, fonctionnement intuitif

Navigation sur l’historique du signal

Fenêtre supplémentaire

Plus de place disponible, évolution actuelle du signal toujours visible

Tableau 4 : Principaux choix réalisés durant le stage

8.1.2.b. Prototype développé

Le prototype développé intègre de nombreux éléments dégagés de la phase d’études, remplissant ainsi les différents objectifs du stage :

Communication avec les instruments

Prise en compte des mesures des instruments les plus importantes Implémentation de la plupart des commandes Robustesse de la communication avec les instruments (gestion de cas d’erreurs pour

recommencer l’initialisation de la connexion) Communication avec Joram complètement fonctionnelle

Configuration des IHM

Système permettant une utilisation de SwiXML pour afficher à loisir un grand nombre d’informations

Ergonomie des interfaces

Affichage des paramètres sous forme de courbes ou de texte Gestion des alarmes physiologiques paramétrable Hiérarchisation et numérotation des étapes du protocole Possibilité d’ajouter des fenêtres pour le suivi détaillé des paramètres

8.1.2.c. Limites

De par l’aspect itératif propre au cycle de développement IHM, et { une disponibilité des utilisateurs moins importante que prévu, certains points de spécification des interfaces n’ont pas



pu être complètement élucidés ; et, faute de temps, quelques-unes des recommandations que j’ai dégagées n’ont pas encore pu être reprises sur le prototype final. Ainsi, le système de pages d’aide et la navigation au clavier ne sont pas encore implémentés ; les activités prévues sur les courbes (navigation dans l’historique du signal) ne sont pas disponibles ; les alertes quand des instruments ne sont pas connectés ne sont pas systématiques.

De même, si la communication avec les instruments est fonctionnelle, bien des aspects sont

encore à améliorer. Ainsi, plus de commandes et de mesures devraient être prises en compte (alarmes des instruments par exemple) ; la robustesse pourrait également être améliorée, par la prise en compte de cas dégradés ou une meilleure connaissance de l’état des instruments. Enfin, le stockage des données dans un fichier externe du laptop n’est pas optimisé.

Enfin, la technologie SwiXML choisie pour la description des interfaces a déjà montré

quelques-unes de ses limites. Si elle permet de définir assez simplement des pages d’interfaces, elle est assez complexe { mettre en œuvre, une seule classe devant gérer tous les objets dynamiques, qui doivent être uniques.

De plus, l’ajout d’un paramètre d’affichage d’une instruction est bien plus difficile { mettre en œuvre que pour un fichier HTML, où il suffit de modifier la feuille de style : ici, dans le cadre de lignes d’instructions héritant de composants Swing, il faudrait pour cela modifier à chaque fois le programme.

Une piste pour pallier ce problème pourrait être l’utilisation d’un composant permettant d’afficher des fichiers HTML, au sein du moteur SwiXML. On retrouverait alors, pour cet aspect, un fonctionnement semblable à celui de Cardiomed.

8.1.3. Utilisation du prototype

L’objectif principal du stage, le développement d’un prototype utilisable opérationnellement, a donc été globalement atteint.

Outre les séances de test et d’utilisation de ce prototype qui auront lieu dans le laboratoire de Cardiomed, il est également possible que l’application réalisée soit assez vite utilisée en milieu hospitalier, ce qui permettra de la tester dans des situations un peu plus proches du cadre réel. L’idéal serait alors de modifier l’interface en fonction des remarques émergentes, le projet étant encore à une phase peu avancée.

Par ailleurs, au cours du stage, une rencontre entre le CNES et l’ACC, l’agence des vols habités chinois, a permis de confirmer l’intérêt des deux parties pour le développement de ce projet : il est donc possible que les résultats du stage servent de base à une véritable application spatiale, qu’il s’agisse du prototype développé ou simplement des recommandations sur les interfaces.

8.2. Apport du Master2 IHM durant le stage

Au cours de ce stage, j’ai eu l’occasion d’utiliser { maintes reprises les enseignements du master IHM. Certains en particulier m’ont été très utiles.

J’ai bien sûr pu directement utiliser les compétences acquises en génie des systèmes interactifs, en programmation avancée (définition de l’architecture), en infographie, ainsi qu’en ergonomie du logiciel (évaluation de Cardiomed) ; mais j’ai également tenté de m’inspirer, dans la mesure du possible, des cours de conception participative, ce qui m’a permis, en plus de dégager les problématiques essentielles existant sur Cardiomed, de proposer des solutions à mon avis assez pertinentes.

J’ai aussi fait appel { mes acquis pour réaliser les prototypes, et surtout pour savoir clairement qu’en faire et comment les présenter, aux évaluateurs comme { l’équipe projet.

Au cours de l’évaluation de Cardiomed et des outils Best et Octave, j’ai également utilisé, dans une moindre mesure, les cours d’évaluation de l’utilisabilité, jouant le sujet évaluateur.



Les cours d’étude des situations de travail ont également facilité la mise en place d’une démarche centrée utilisateur, et m’ont préparé { collaborer avec un spécialiste en facteurs humains.

Enfin, la notion de multimodalité m’a été utile pour exprimer les différents moyens d’interaction qui pourraient être envisagés en mode bord ; quant { l’initiation au graphisme que nous avons suivie, vous n’aurez, j’espère, pas manqué de remarquer qu’elle se retrouve dans ce rapport et dans ses annexes !

8.3. Bilan personnel

Ce stage m’a permis de concevoir et développer une application complète, prenant en compte les spécificités de 2 domaines passionnants : le spatial et le médical.

J’ai donc pu être intégré à une équipe œuvrant dans ces deux domaines depuis plusieurs années. J’ai travaillé avec une grande autonomie, toute latitude m’ayant été laissée pour mener { bien mes objectifs ; ce, qu’il s’agisse des développements ou de la planification des séances de conception. J’ai toutefois bénéficié, lorsqu’il le fallait, de leur disponibilité et de leurs conseils, et même de leur soutien lorsque je voulais rencontrer des utilisateurs ou des spécialistes.

J’ai également été agréablement surpris de l’entraide que j’ai constatée au CNES, les différentes équipes que j’ai sollicitées au cours du stage faisant toujours preuve d’une grande disponibilité, même quand elles étaient complètement extérieures au projet.

Si les problématiques liées au noyau fonctionnel de l’application ont parfois pris le pas sur

les aspects de présentation et de conception centrée utilisateur, notamment au milieu du stage, je pense avoir malgré tout bien réussi à prendre en compte ces aspects, mon seul regret étant finalement le manque de disponibilité des médecins à un moment où ils auraient été très utiles.

Je pense en tout cas avoir réalisé un véritable travail de concepteur-développeur informatique spécialisé en Interactions Homme-Machine, ce qui, après tout, est probablement ce qui m’attend dans un avenir proche.



Glossaire

Noms

ISS International Space Station, la station spatiale internationale

ACC Centre des astronautes de Chine, la direction des vols habités chinois

CADMOS Centre d’Aide au Développement des activités en Micropesanteur et des Opérations Spatiales

ODF Operations Data Files, norme de rédaction de procédures définie par la NASA, utilisée sur l’ISS.

Progress Vaisseau-cargo russe transportant les équipements destinés { l’ISS

Termes scientifiques et médicaux

Bedrest Expérience médicale dans laquelle un sujet reste allongé, la tête inclinée vers le bas, pendant plusieurs semaines, afin de simuler les effets de l’impesanteur

Vols paraboliques Atteinte d’un état proche de l’impesanteur dans un avion grâce { une série d’arcs paraboliques (successions de phases d’impesanteur de 20 à 25 secondes)

Impesanteur, apesanteur, micropesanteur

Absence de pesanteur relative

ECG ElectroCardioGramme

Pression systolique A chaque battement de cœur, pression sanguine atteinte lors de la contraction (pic maximal)

Pression diastolique A chaque battement de cœur, pression sanguine atteinte lors du relâchement (pression minimale)

Termes informatiques

Java Langage de programmation informatique, orienté objets

Swing API Java utilisée pour le développement d’interfaces homme-machine

XML eXtensible Markup Language, fichier texte décrivant des données grâce à l’utilisation de balises.

HTML HyperText Markup Language, format utilisé pour décrire des pages comme celles qui existent sur le web.

CSS Cascading Style Sheets, fichier spécifiant la mise en forme d’une page HTML par le biais d’étiquettes

TM TéléMesures, mesures acquises depuis un instrument distant (terme souvent utilisé pour les mesures des satellites)

TC TéléCommandes, commandes envoyées vers un instrument distant

CORBA Common Object Request Broker Architecture, architecture logicielle permettant la communication entre un client et un serveur indépendamment du langage utilisé par chacun

Décommutation de données

Transformation des données numériques brutes envoyées par un instrument, en série de mesures directement interprétables

Critères de Bastien et Scapin

Ensemble de 18 critères d’évaluation sur l’ergonomie des IHM proposés par Christian Bastien et Dominic Scapin, { la suite d’une large synthèse sur le sujet



Références et bibliographie

Cardiomed :

J.C. Lloret, P. Aubry, L. Nguyen, V. Kozharinov, V. Grachev, E. Temnova : CARDIOMED system for medical monitoring onboard ISS, IN : ISGP, Angers, 2008

Présentations sur les sites du CNES : http://smsc.cnes.fr/CARDIOMED/Fr/ http://www.cnes.fr/web/CNES-fr/5795-cardiomed.php

SEVE :

J.C. Lloret, P. Aubry, L. Nguyen, Yanqiang Bai , Ming Yuan, Yingyui Li : SEVE system during ES-IBREP bed-rest in Beijing, IN : ISGP, Xi’an,2009

SwiXML :

Site officiel : http://www.swixml.org/ Présentation et tutoriel : http://today.java.net/pub/a/today/2006/02/21/building-guis-

with-swixml.html

Joram :

Site officiel : http://joram.ow2.org/

ODF :

National Aeronautics and Space Administration : Operations Data Files Standards, International Space Station Program

Modèle Arch:

Description du modèle : http://tel.archives-ouvertes.fr/docs/00/04/82/79/HTML/2_2modelesinterface_referen.html

http://smsc.cnes.fr/CARDIOMED/Fr/

http://www.cnes.fr/web/CNES-fr/5795-cardiomed.php

http://www.swixml.org/

http://today.java.net/pub/a/today/2006/02/21/building-guis-with-swixml.html

http://today.java.net/pub/a/today/2006/02/21/building-guis-with-swixml.html

http://joram.ow2.org/

http://tel.archives-ouvertes.fr/docs/00/04/82/79/HTML/2_2modelesinterface_referen.html

http://tel.archives-ouvertes.fr/docs/00/04/82/79/HTML/2_2modelesinterface_referen.html

Documents

Nouvelles technologies pour le contrôle/commande d ...masterihm.pbworks.com/f/rapport_merlet_v1.6.pdf · Rapport de stage - Nouvelles technologies pour le contrôle/commande d’instruments