interactifs critiques
1.5.1 Les systèmes interactifs et la sûreté de fonctionnement
Les systèmes interactifs critiques actuels ont, jusqu’à présent et pour des raisons de sûreté de fonctionnement, mis l’accent sur l’utilisabilité plutôt que sur l’expérience utilisa-teur. La possibilité pour l’opérateur de réaliser les tâches de manière efficace est considérée comme essentielle par rapport à l’expérience qu’il en tire, ce qui est relativement contraire à la politique des grands constructeurs informatiques actuels. De plus, les systèmes interac-tifs critiques possèdent des jeux de périphériques d’entrée/sortie relativement restreints. Aujourd’hui, un cockpit d’avion Airbus possède deux ensembles clavier/souris appelés KCCU (Keyboard and Cursor Control Unit). Les interactions présentes dans les cockpits sont directement issues du paradigme d’interaction WIMP, et donc de la troisième grande
ère des interactions telles que décrites par Van Dam dans [Van Dam, 1997]. La conception
de systèmes multimodaux post-WIMP telle que définie par Van Dam , étant beaucoup plus complexe, il faut de nouvelles méthodes et processus adaptés, pour permettre leur
introduction dans les systèmes critiques [Palanque and Bastide, 1994]. Les interactions
naturelles, modernes et esthétiques de notre quotidien n’existent pas dans les systèmes interactifs des cockpits d’avions.
La conception de systèmes interactifs critiques, comparée à celle dédiée aux systèmes grand public, nécessite des précautions particulières. Le temps et les durées d’exploitation élevés de ces systèmes nécessitent la prise en compte, dès la conception, de l’intégration ou de la suppression d’un périphérique, que cela se produise durant l’opération suite à une panne, ou longtemps après la conception initiale, par exemple pour des évolutions de technologie.
En effet, La durée d’exploitation d’un modèle d’avion variant de 30 à 80 ans entre sa conception et le retrait du service du dernier modèle, ses technologies sont donc amenées à évoluer.
Le temps d’exploitation est lui aussi bien plus important que celui des systèmes grand public. Par exemple, le temps de démarrage des systèmes informatiques d’un AIRBUS A380 est d’environ 8h lorsque toutes les procédures de sécurité sont actives. Ces sys-tèmes ne sont donc que très rarement arrêtés, et doivent supporter la disparition d’un périphérique pendant leur opération.
D’un point de vue logiciel, l’interaction avec le système doit être décrite de manière
complète et non ambiguë [Palanque, 1992]. L’ingénierie des systèmes critiques ayant très
rapidement nécessité la production d’architectures logicielles et matérielles ainsi que l’uti-lisation de langages formels et de mécanismes de sûreté de fonctionnement, ces contraintes se sont naturellement retrouvées au cœur de la conception des systèmes interactifs des-tinés aux milieux critiques. Les approches zéro défaut, utilisées dans des processus de développement adaptés aux systèmes critiques sont donc aujourd’hui au cœur des proces-sus utilisés pour ce type de système. La complexité de ces systèmes amène les concepteurs à décrire de manière indépendante les techniques d’interaction pour pouvoir vérifier leurs comportements face à une spécification.
Le traitement de l’aspect critique est tributaire de celui des fautes, erreurs et dé-faillances. Nous devons tout d’abord nous pencher sur les formes qu’elles peuvent revêtir dans les systèmes interactifs critiques, et aborder leur classification.
Figure 1.9 – Classification des fautes des systèmes informatiques, extrait de
[Fayollas, 2015]
la figure 1.9 présente une version simplifiée de la classification des fautes pouvant
affecter les systèmes informatiques proposés par les travaux de Avizienis, Laprie, et al.
2004 [Avizienis et al., 2004]. Cette figure met en évidence cinq regroupements de classes
de fautes que nous avons identifiés. Ces regroupements peuvent être considérés comme des classes de fautes de haut niveau :
Fautes logicielles de développement : fautes introduites involontairement durant le développement du système. Par exemple, les erreurs de codage ou les erreurs de conception.
système. Elles relèvent de la sécurité du système. Par exemple, la prise de contrôle extérieur ou un déni de service inopiné, un crash du système.
Fautes matérielles de développement : fautes ayant une cause naturelle ou humaine et impactant le matériel durant sa conception. Par exemple, un court-circuit à l’intérieur d’un processeur ou un matériel affecté lors de son développement par l’utilisation d’une eau avec une concentration trop forte en uranium, provoquant ainsi des erreurs lors de l’utilisation de celui-ci comme ce fut le cas en 1978 pour
une usine d’IBM [Ziegler et al., 1996].
Fautes naturelles en opération : fautes causées par un phénomène naturel. Elles af-fectent le matériel (et par conséquent le logiciel) et surviennent pendant le fonc-tionnement du système. Par exemple, la modification de la mémoire suite à un rayonnement électromagnétique ou l’effacement d’un disque dur dans une zone magnétisée.
Fautes humaines en opération : fautes qui résultent d’une action humaine pendant le fonctionnement du système. Elles peuvent être matérielles et logicielles, délibérées ou non : par exemple, l’oubli d’une étape dans une procédure ou l’appui sur un mauvais bouton.
À partir de ces cinq grandes classes de fautes, on peut travailler à la réduction ou la suppression des effets de certaines d’entre elles :
• Les fautes logicielles de développement peuvent être réduites, voire supprimées en utilisant une approche zéro défaut, basée sur les méthodes formelles, méthodes suivies dans ce manuscrit.
• Les fautes malveillantes lors du développement ou au cours de l’opération sont en dehors du périmètre de ce mémoire. Elles relèvent de la sécurité informatique, qu’elle soit du ressort de l’organisation ou du développement de solutions spéci-fiques.
• Les travaux de ce mémoire ne prennent pas en compte les fautes liées au dévelop-pement du matériel, elles ne sont pas du ressort de l’informatique.
• Les fautes naturelles sont gérées à plusieurs endroits : matériellement tout d’abord, via des circuits de vérification, logiciellement ensuite, via la prévention de fautes, par l’utilisation de mécanismes de sûreté du logiciel. On peut, en utilisant certaines de ces méthodes, appliquer la sûreté de fonctionnement aux systèmes interactifs
critiques, comme dans les travaux de [Fayollas, 2015]
• Les fautes humaines en opérations sont, la plupart du temps, non traitées dans l’in-génierie des systèmes interactifs. Elles relèvent le plus souvent d’analyse d’accidents à postériori. Nous proposerons néanmoins une méthode permettant de supprimer celles déclenchées par les surprises liées à l’utilisation des systèmes interactifs.
Nous nous appuierons sur la figure 1.9tout au long de ce manuscrit pour situer les
1.5.2 Conflits entre propriétés
Des difficultés apparaissent lorsque l’on essaye d’assurer les bonnes propriétés d’un système interactif critique du fait de l’entrée en conflit de certaines des propriétés présen-tées dans ce chapitre (propriétés des systèmes interactifs, des systèmes critiques, et bien entendu, de leur combinaison).
Les systèmes interactifs critiques relèvent à la fois des propriétés des systèmes inter-actifs et de celles des systèmes critiques. Parmi celles que nous avons exposées précédem-ment, certaines peuvent être plus importantes que d’autres selon le domaine d’application des systèmes concernés. Ainsi, comparons le domaine des systèmes interactifs critiques à l’activité entrepreneuriale comme les domaines des télévisions interactives ou des jeux vidéos. L’UX (User eXperience) aura une importance primordiale dans l’activité entre-preneuriale, alors qu’elle sera reléguée à bas niveau pour les systèmes interactifs critiques où les vies humaines et l’utilisabilité sont prioritaires.
Dans tous les cas, la sûreté de fonctionnement reste primordiale. Nous nous intéressons ici aux systèmes interactifs présents dans les cockpits d’aéronefs et par extension aux systèmes interactifs critiques par rapport à la vie humaine, nous retiendrons donc les propriétés de sûreté de fonctionnement et d’utilisabilité comme étant les plus importantes à garantir.
Ces deux propriétés sont orthogonales et peuvent faire l’objet d’un conflit. Ceci a été
montré dans les travaux de [Martinie et al., 2010]. Ces derniers proposent une notation
pour aider les concepteurs de systèmes interactifs critiques dans leur choix de concep-tion. Ils mettent en évidence que certains choix de conceptions permettant de garantir la sûreté de fonctionnement du système peuvent affecter l’utilisabilité du système. De la même manière, rendre un système plus utilisable, en implantant par exemple des tech-niques d’interaction avancées, peut affecter sa sûreté de fonctionnement en introduisant des fonctionnalités supplémentaires ayant pour conséquence d’augmenter la complexité du logiciel. Ces deux propriétés sont généralement traitées de manière séparée lors de la conception et du développement du système sans étudier leur impact mutuel. Il est fondamental les prendre en compte en les traitant de manière intégrée et systématique afin de pouvoir concevoir et développer des systèmes interactifs critiques utilisables et sûrs de fonctionnement. Certains travaux proposent des solutions pour traiter ces deux propriétés communément et de manière systématique. On retrouve par exemple le
proces-sus de développement présenté dans les travaux de [Martinie et al., 2012] ainsi que ceux
de [Tankeu Choitat, 2011] présentant une approche pour le développement de systèmes
interactifs intégrant à la fois les aspects sûreté de fonctionnement et utilisabilité.
Les travaux de ce mémoire chercheront donc à fournir des moyens pour identifier, et ordonner les propriétés nécessaires à la conception d’un système interactif sûr de fonction-nement.