Représentation graphique du pattern de tâches

La structure de la tâche (de haut niveau) de pilotage d’un système de contrôle commande peut être résumée suivant certaines phases. On peut décrire un pattern de tâches contenant toutes les phases ainsi que leur décomposition hiérarchique. Cependant, essayer de décrire une tâche complexe en un seul pattern peut être très difficile, et la description peut vite devenir très lourde (Granlund, Lafrenière, and Carr 2001). L’intérêt premier de l’utilisation des patterns de tâches est de rendre la spécification de la tâche plus facile à lire et à interpréter (Breedvelt-Schouten, Paternò, and Severijns 1997), car il est possible d’indiquer leurs noms si elles ne sont pas détaillées dans l’arbre de tâches plutôt que de les détailler complètement. Cependant, il devient incontournable de définir les tâches complexes en un seul pattern si les sous-patterns identifiés ne peuvent être réutilisés dans des contextes autres que la supervision d’un système de contrôle-commande.

La représentation graphique simple du pattern de tâches de supervision tels que présenté dans (Bovell, Carter, and Beck 1998) permet juste de voir l’arborescence des tâches, mais on il ne présente aucune information sur la décomposition des tâches, sur les opérateurs, sur les exécutants, etc. Le langage TPML et ses variantes permettent de représenter les patterns graphiquement et textuellement mais l’instanciation des patterns se fait avec des outils spécifiques qui exploitent ces langages. Un modèle de tâches qui intègre ces patterns doit être décrit soit en CTT, soit en XIML. Les autres langages de modélisation des tâches ne sont pour le moment pas pris en compte. Il est préférable de pouvoir décrire les patterns à partir de n’importe quel langage de modélisation de tâches.

Nous avons choisi d’utiliser pour nos travaux l’outil de modélisation de tâches K-MADe pour décrire le pattern de tâches de supervision. L’intérêt de cette représentation est de pouvoir prendre en compte, déjà au niveau du pattern, les informations concernant la décomposition des tâches, les opérateurs, les exécutants, les préconditions, etc. L’idéal est d’utiliser directement les patterns sans passer par des procédures de transformations d’un langage de patterns à un langage de représentation de modèles de tâches. Cependant les procédures de transformations sont inévitables si on veut passer d’une notation de tâches à une autre. Les informations relatives à un pattern telles que Problème, Contexte, Solution et Relation peuvent être décrites dans la section « Description » du nom de la tâche principale du pattern. Ces informations aident le concepteur à comprendre le pattern de tâches.

Nous décrivons ci-dessous la conception du pattern de tâches en l’illustrant avec un système de contrôle-commande du domaine naval. Ce pattern peut, bien sûr, être adapté à d’autres domaines.

La supervision d’un système de contrôle-commande (« Superviser le système », Figure 33) s’effectue en quatre grandes tâches qui sont réalisées en parallèle par les opérateurs de la salle ou passerelle de contrôle : « Surveiller les fonctions du système », « Détection et traitement de

74

Figure 33 Description de la tâche « Superviser le système avec K-MADe

La tâche « Surveiller les fonctions du système » (Figure 34) est une tâche utilisateur itérative car elle s’effectue en permanence. Au cours de cette tâche l’opérateur doit surveiller en parallèle les paramètres du système, les variables du procédé, tendances et conditions anormales pour signaler à l’équipage dès qu’il y a une anomalie détectée afin que la procédure appropriée soit lancée.

Figure 34 Représentation graphique de la sous-tâche « Surveiller les fonctions du système avec K-MADe

La tâche « Détection et traitement de défauts » (Figure 35) est une tâche système qui peut intervenir à n’importe quel moment de la supervision du système. En effet, le système peut remonter à tout moment une ou plusieurs alarmes liées aux composants et d’autres anomalies liées aux conditions, aux variables, etc. Les actions à effectuer par les opérateurs diffèrent en fonction des défauts détectés. Par exemple en cas d’accident (Définition 1), les opérateurs doivent effectuer des actions correctives immédiates pour régulariser la situation ou mettre le système en configuration de « Repli » (Définition 2). S’il n’y a pas d’accident, l’opérateur doit tout d’abord analyser le problème, puis sélectionner des alternatives en s’appuyant sur son expertise et les procédures prédéfinies pour restaurer le système. La sélection d’une alternative suit une séquence d’action bien définie. L’opérateur doit tout d’abord identifier les actions possibles permettant de corriger le problème, puis analyser les conséquences de ces actions.

Définition 2 Configuration de Repli

Ensuite il doit comparer les avantages et les inconvénients de ces actions pour enfin choisir l’alternative la mieux adaptée. L’état du système affiché après le traitement des défauts permet à l’opérateur d’avoir la confirmation que ces actions ont bien été prises en compte par le système et ont permis de restaurer ce dernier.

La configuration de repli est la configuration à atteindre en cas de défaillance grave du système (grande fuite d’eau par exemple, sur un système de gestion d’eau). Pour les systèmes de gestion de fluide par exemple, elle consiste à refermer toutes les vannes et à arrêter tous les équipements (pompes, osmoseurs…).

75 Figure 35 La sous-tâches « Détection et traitement de défauts » avec K-MADe

76

Les « Tâches administratives » (Figure36) s’effectuent généralement par les opérateurs qui ne

sont pas chargés de surveiller le système. Certaines de ces tâches telles que les tests de surveillance et la vérification des spécifications techniques ont pour but d’assurer la sécurité des installations en cas d’accident. D’autres telles que la tenue du journal et l’écriture des rapports d’évènement ont pour but de noter les problèmes majeurs détecté sur le système, les évènements avec risque d’aggravation, les évènements qui nécessitent une classification d’urgence, etc. Les rapports précis d’évènement permettent d’identifier les défauts de conception des installations, les procédures d'exploitation, l'instrumentation et la planification d'urgence (Bovell, Carter, and Beck 1998).

Figure36 La sous-tâche « tâches administratives »

La tâche « Manipulation de commandes prévues » (Figure 37) est, quant à elle, une tâche abstraite permettant à l’opérateur de réaliser de façon semi-automatique les fonctions da haut-niveau du système et/ou de lancer toute autre commande prévue. Sur un grand nombre de systèmes de contrôle-commande, la plupart des manipulations de commandes se produisent soit au démarrage du système, soit lorsqu’il y a des arrêts normaux ou des évènements anormaux. Par exemple, à la fin de l’exécution d’une fonction qui permet de transférer de l’eau d’une soute à une autre dans un système d’eau douce, l’opérateur peut lancer une autre fonction selon l’état du système et les besoins des utilisateurs.

Les commandes prévues sont effectuées dans une séquence d’actions bien définie suivant une procédure écrite, avec des réactions du système à ces actions. Pour les commandes qui permettent de lancer une fonction, l’opérateur peut soit « Effectuer une fonction » si elle n’est pas en cours, soit « arrêter une fonction » qui est en cours. Pour effectuer une fonction, il doit cliquer sur la commande de la fonction pour la démarrer, ensuite il doit renseigner la consigne liée à la fonction en suivant une séquence d’actions bien définie. Une fois que l’opérateur a validé la consigne, l’automate local prend en compte la disponibilité des éléments (défauts, position, etc.), la disponibilité du système (les éventuels défauts des éléments et instrumentation) afin de déterminer si la demande effectuée par l’opérateur sera acceptée. Si cette demande est refusée, un message informe l'opérateur. Sinon le système se configure et l’opérateur peut évaluer en réalisant en parallèle les tâches « Surveiller les fonctions du système » et « Détection et traitement de défauts » décrites ci-dessus.

77 Figure 37 La Sous-tâche manipulation de commandes prévues avec K-MADe

78

L’annexe 4 présente l’ensemble du pattern de tâches « Superviser le système » issu de notre formalisation. La généricité de ce pattern de tâches est visible par la présence de variable dans la description de l’activité de supervision. Par exemple, dans l’annexe 2, on retrouve les noms de tâches tels que consigne (nx), affiche état (nx) et alerte (nx), qui doivent être adaptés aux différents contextes. La description des activités de supervision dans le pattern de tâches permet de recueillir, de façon globale et plus précise, des informations sur l’utilisation de système nécessaire à la mise en œuvre des spécifications fonctionnelles à travers les commandes de haut-niveau.