Dans les paragraphes précédents, nous avons défini de façon formelle les notions de ressource, mode, service, qualité de service et transition, en particulier en rattachant la dynamique du système à un modèle de processus décisionnel markovien. Cependant, cette définition formelle n’explique pas l’intention du modèle, c’est-à-dire les cas d’usage ainsi que le type de cas d’application que ce modèle est fait pour traiter.
VI.3.1 Catégorisation des qualités de service
Une approche naturelle qu’il est possible de suivre est celle de la catégorisation de la qualité de service ; il faut néanmoins noter que dans la littérature, le terme "qualité de service" renvoie le plus souvent au domaine de la gestion de flux réseaux, c’est-à-dire que la qualité de service représente une qualité de transmission de l’information, par exemple en termes de réactivité ou de débit. Des études de catégorisation de la qualité de service dans ce contexte ont été réalisées, telles que [EFJ+98], [HCM+00], [WC96] ou [GJS03]
En nous basant sur ces études et sur la connaissance du domaine avionique que nous avons évoquée précédemment, nous proposons la catégorisation suivante, sans prétention d’exhaustivité :
– Précision : désigne dans quelle mesure le service est rendu avec du bruit, des erreurs de calcul ou de mesure, ou toute autre forme d’incertitude sur la variabilité des valeurs des données.
– Disponibilité : désigne dans quelle mesure le service peut être utilisé lorsque le système en a besoin, par exemple sous la forme d’un pourcentage de temps où le service est opérationnel ou d’une probabilité que le service puisse être utilisé.
– Temps de réponse ou temps de démarrage : désigne une estimation du temps nécessaire avant de pouvoir utiliser ce service.
– Bande passante : désigne une estimation de la quantité d’informations échangées par ce service, ou de la capacité d’échange d’informations, en termes de quantité, que ce service peut fournir.
– Intégrité : désigne la fiabilité des données, c’est-à-dire une estimation de confiance sur le fait que les données demeurent dans une certaine enveloppe autour des données qui auraient été émises en situation nominale, lorsque aucune défaillance n’est survenue. – Fiabilitéa : désigne la résilience du service à des défaillances futures, sous la forme d’un
nombre de défaillances nécessaires, d’une probabilité de défaillance (de service) ou encore d’un niveau de DALb.
– Sûreté : désigne, au sens informatique, l’estimation de l’accès protégé aux données, c’est-à-dire d’un accès qui n’est pas corruptible par un attaquant extérieur ou qui au contraire a été corrompu dans une certaine mesure.
– Synchronicité : désigne la capacité ou la nécessité du service à être utilisé dans une communication directe ou dans une communication différée ; cette capacité peut être exprimée en termes de temps minimal ou maximal entre chaque requêtes, ou en capacité de mémoire tampon (buffer) sur le nombre de requêtes que le service peut accepter ou fournir, simultanément ou dans un temps court (relativement à la vitesse de traitement des requêtes).
a. reliability en anglais
b. Design Assurance Level [ARP 4761]
Catégorisation thématique de la qualité de service
service selon le sens qui est donné à la valeur. Notons par ailleurs que nous n’avons pas donné explicitement de valeurs pour les domaines que peuvent prendre ces qualités de service : en effet, chaque cas d’application nécessitera un niveau de granularité différent dans les domaines, par exemple entre un cas d’application pour lequel il sera suffisant de distinguer une qualité de service de précision "peu précis" et "très précis", et un cas d’application pour lequel on souhaitera quantifier la précision
sous la forme d’intervalles "+-10%", "+-20%",...
VI.3.2 Conséquences de la gestion de la qualité de service sur l’architecture du système
Une des conséquences implicite du modèle de gestion de modes dégradés est qu’il impose un certain nombre d’ajustements à l’architecture du système. Plus spécifiquement, il est nécessaire de disposer de méthodes permettant d’évaluer la qualité de service à certains points clés du système. Nous détaillons les cas de figure possibles dans la classification suivante :
Soit A fournissant un service à B. B peut détecter une défaillance d’un service fourni par A à partir de :
– la détection par présence/absence de signal : A ne fournit plus de service.
– la détection par mesure directe : B mesure directement la qualité du service fourni par A (exemple : mesure de la bande passante, synchronicité, temps de réponse, ...).
– la détection par qualifieur : B est informé par A de la défaillance d’un de ses services par un canal d’information supplémentaire (exemple : fiabilité, disponibilité, sécurité) ; ce changement de qualité de service est généralement causé par A suite à une défaillance (matérielle ou d’un de ses services d’entrée).
– la détection par comparaison à une référence : B détecte une défaillance du service fourni par A en comparant avec une ou plusieurs autres sources (exemple : précision).
Détection de changement de la qualité de service
Ceci nous montre par ailleurs une hypothèse que nous n’avons pas explicitée précédemment : dans la construction du modèle MDP, nous avons fait l’hypothèse d’une observabilité totale des qualités de service, ce qui implique que l’agent doit avoir un moyen d’obtenir ou d’inférer la qualité de tous les services ; ceci est immédiatement problématique dans certains cas, en particulier lorsque tous les systèmes recevant un même service ne sont pas ou plus capables de mesurer la qualité de ce service. Cette hypothèse est cependant rendue possible si nous choisissons de nous limiter à un nouveau système, c’est-à-dire un système tel que la mesure de la qualité de service en tout point peut être assurée grâce à l’ajout d’équipements, tels que des équipements d’alerte, de test et de diagnostic.
Si tel n’est pas le cas, et si les équipements de diagnostic ne permettent pas une observabilité totale des services, alors d’autres méthodes doivent être envisagées (par exemple les méthodes de résolution POMDP [PCCT13] ou planification conformante [CR00], ou il est tout du moins nécessaire de réaliser une étude supplémentaire pour s’assurer que les décisions prises par l’agent sont toujours possibles malgré ce manque d’information : si l’agent ne connaît par exemple pas la valeur de la qualité de service d’une sonde, mais qu’il n’a pas besoin de cette information pour effectuer une décision, alors la démarche que nous proposons est toujours valide. Si en revanche le fait d’avoir ou non cette information change potentiellement la décision de l’agent, alors il est nécessaire d’étudier si cela justifie l’ajout d’une mesure supplémentaire de mesure au niveau de la sonde (qui est une solution potentiellement coûteuse), ou si une logique particulière permet d’inférer la valeur de la qualité de service, ou bien encore si le fait d’avoir une décision non-optimale n’a qu’un impact mineur sur les critères de sécurité et les contraintes d’optimalité.
CHAPITRE VI. GESTION DES MODES DÉGRADÉS
Dans les paragraphes suivants, nous nous appuierons sur ces réflexions pour évaluer dans quelle mesure les cadres mathématiques existants permettent de représenter des problèmes de Gestion de Modes Dégradés.
VI.3.3 Sélection d’un modèle mathématique
Nous avons déjà partiellement effectué le choix d’un modèle mathématique lors de l’expression de la dynamique du système : en effet, nous avons choisi de représenter cette dynamique à partir d’un processus décisionnel markovien, et d’utiliser la logique PCTL pour exprimer des contraintes probabilistes sur les qualités de service. Nous pouvons à présent nous poser la question de la légitimité de ce choix, et de ses conséquences : dans quelle mesure d’autres modèles mathématiques auraient pu être utilisés, et quelles sont les conséquences de ces deux choix sur les méthodes de résolution ?
Nous avons déjà évoqué précédemment différentes classes de modèles utilisés traditionnellement dans les problèmes de décision. En particulier, nous avons isolé trois catégories principales : l’optimisation sous contraintes [Lue73], la planification classique [GNT04] et la planification probabiliste [Put94].
Parmi ces trois catégories, l’optimisation sous contraintes est la seule à ne pas être, de façon native, dynamique : bien qu’il soit possible d’encoder la dynamique d’un problème sous la forme d’un ensemble de contraintes (puisqu’il est possible de résoudre des problèmes de planification sous la forme d’une résolution de contraintes), ce cadre se prête traditionnellement à des problèmes où certains paramètres fixes doivent être déterminés. Par exemple, il serait possible d’utiliser ce type de techniques pour déterminer un ensemble de modes à fixer tels que certaines qualités de service soient maximales, ou respectent certains critères ; en revanche, ceci ne prendrait pas en compte les évolutions futures possibles, c’est-à-dire les défaillances pouvant survenir. Dans la mesure ou nous voulons garder cette prise en compte des évènements redoutés dans notre résolution - puisque nous nous intéressons à la fois à des critères d’optimalité et des contraintes de sécurité - le cadre de l’optimisation sous contrainte n’est donc pas suffisant.
Le même constat peut être établi pour le cadre de la planification classique : puisque nous avons effectué le choix d’une dynamique probabiliste, les méthodes de résolution de la planification classique ne sont pas suffisantes pour notre problème (notons que dans ce contexte le terme de "planification classique" n’englobe pas les méthodes de planification/replanification classiques qui peuvent être utilisées pour résoudre des problèmes MDP). Si nous n’avions pas choisi une dynamique probabiliste, d’autres méthodes auraient pu être appliquées, mais qui auraient répondu à d’autres problèmes ; ainsi, nous aurions pu par exemple poser la question de l’absence complète d’observabilité, par exemple en cherchant s’il existe une procédure garantissant qu’on puisse amener le système dans un état "sûr" -ou t-out du moins connu - quel que soit l’état initial. Ce type de problèmes aurait alors pu être résolu avec des méthodes de planification conformante [CR00].
Une autre hypothèse que nous aurions pu prendre est celle de l’observabilité partielle : si certaines qualités de service ne sont pas connues de l’agent, alors nous aurions dû nous orienter vers des méthodes de type POMDP ; ces méthodes ont des conditions particulières, puisque certaines actions sont alors prises non pas de façon à optimiser une qualité de service, mais de façon à déterminer dans quel état le système se trouve réellement. En faisant l’hypothèse de l’observabilité totale, nous faisons en réalité l’hypothèse que cet aspect de recherche de connaissance sur l’état du système est laissé à un système externe, de façon préliminaire à la décision ; ceci suppose en particulier que les outils de diagnostic sont parfaits, ou tout du moins parfaits sur l’ensemble des qualités de service importantes à la décision. Toutefois, il semble clair qu’un modèle basé sur l’observabilité partielle présente des caractéristiques très intéressantes, bien que nous ne l’ayons pas étudié dans nos travaux.
Enfin, il est possible de remettre en cause le choix de l’expression sous forme de contraintes PCTL pour les contraintes de sécurité. Plus spécifiquement, nous aurions pu choisir une expression de contraintes s’alliant de façon différente au modèle MDP, tel que ce qui peut être fait dans des modèles tels que CMDP [Alt99] ou les travaux de Etessami et al. [EKVY07]. Nous avions déjà évoqué dans l’état de l’art préliminaire que de nombreux modèles existent permettant d’allier MDP et contraintes sur les états ; ces modèles permettent donc d’optimiser la qualité de service, en étant robustes aux défaillances de ressources pouvant survenir, tout en évitant certaines situations. Nous avions conclu dans le cas de l’aide à la décision pour le business jet que seuls des modèles de type PCMDP avaient le niveau de
garantie que nous souhaitions en termes de respect des contraintes de sécurité, puisque dans les autres modèles il était possible d’affecter (uniquement) des préférences telles que le système trouvait qu’il était plus avantageux de passer outre ces contraintes ; dans les modèles de gestion de modes dégradés, nous avons cependant une relation forte entre les contraintes de sureté et les contraintes d’optimalité : dans presque tous les cas, la solution optimisant les contraintes d’optimalité respectera naturellement les contraintes de sécurité, puisque l’optimalité correspond en partie à maintenir l’avion en vol. De plus, la plupart des modèles ne présenteront aucune boucle dans le processus décisionnel markovien, puisque toutes les reconfigurations prises par l’agent en réaction à des défaillances seront faites pour mitiger une défaillance venant de survenir. Par conséquent, dans presque tous les cas rencontrés réellement dans le contexte industriel qui est le nôtre, il suffira d’effectuer une résolution du MDP puis de vérifier le respect des contraintes sur la solution obtenue après-coup.
Néanmoins, dans le cas général, il est possible de construire des modèles à partir du formalisme GMD qui ne peuvent être exprimés que sous la forme d’un modèle de type PCMDP. C’est en particulier le cas lorsque les critères d’optimalité et les contraintes de sécurité sont opposées, par exemple si le pilote souhaite très fortement avoir une précision élevée sur sa position, mais que reconfigurer l’avion dans ce sens pourrait potentiellement mener à une situation critique si une nouvelle défaillance survenait. Bien que de tels cas ne soient que théoriques - puisque notre expérience nous a montré que de telles situations ne semblaient pas se produire dans la réalité - le fait qu’ils existent nous force à considérer une résolution centrée autours du modèle PCMDP complet. Il est important de noter que, contrairement à ce que nous avions pu effectuer dans les chapitres précédents, le modèle PCMDP que nous construisons à partir d’un formalisme GMD nécessite des contraintes PCTL non limitées à des probabilités 0 ou 1 ;
CHAPITRE VI. GESTION DES MODES DÉGRADÉS