La spécification diagrammatique

Les approches traditionnelles de l’analyse fonctionnelle utilisent les diagrammes de flux pour modéliser les blocs fonctionnels des systèmes de contrôle-commande (Fiorèse and Meinadier 2012). Dans la littérature nous avons quatre types de diagramme de flux. Il s’agit des diagramme de flux mécanique (Mechanical Flow Diagram (MFD)) (Turton et al. 2008), des diagrammes de données (Data Flow Diagrams (DFD)) (Le Vie and Donald 2000) qui permettent de modéliser la structure d’un système, des diagrammes de flux de commande (Control Flow

Diagrams (CFD)) (McAvinew and Mulley 2004) et des diagrammes de flux de fonctions

(Functional Flow Bloc Diagrams (FFBD)) (McAvinew and Mulley 2004) qui permettent de modéliser le comportement dynamique d’un système . Ces deux types d’approches sont connues sous le nom d’approche structurelle (DFD) et approches comportementale (CFD et FFBD) (Fiorèse and Meinadier 2012). Dans la conception des systèmes de contrôle-commande, l’approche structurelle est souvent utilisée pour construire des schémas comme le P&ID (Pipping and Intrumentation Diagram) (Turton et al. 2008) connu sous le nom de MFD et l’approche comportementale est souvent mise en œuvre à travers la méthode SADT (Structured Analysis and Design Technique (Marca and McGowan 1988)). Ces deux approches se concentrent sur la description fonctionnelle du système. Elles sont alors complétées par les modèles de tâches, généralement décrits par les concepteurs d’IHM, qui permettent de décrire les actions de l’utilisateur sur le système.

2.3.1 Spécification graphique du point de vue du système

Le P&ID est une description graphique détaillée du procédé physique suivant la norme ANSI/ISA-S5-1 (Ansi/Isa 1992). C’est un schéma structuro-fonctionnel normalisé utilisé au plus tôt dans les projets de conception de système de contrôle-commande car il offre une vue d’ensemble du système et une représentation détaillée de ses composants.

La description du procédé à travers un P&ID se base sur des symboles prédéfinis simples et facile à comprendre par tous les acteurs engagés dans la conception du système de contrôle-commande. Cette description fournit aux ingénieurs des informations nécessaires pour la conception du procédé, concernant toute la tuyauterie, l'équipement, et une grande partie de l'instrumentation.

Généralement, le P&ID sert de guide aux intervenants du projet. Par exemple, il permet aux ingénieurs mécaniciens et civils de construire et d’installer les équipements ; aux ingénieurs d’instrumentation (responsable de la conception, du développement, de l'installation, de la gestion et/ou maintenance des modules qui sont utilisés pour surveiller et contrôler les procédés) de spécifier, d’installer et de vérifier le système de contrôle-commande, etc. De plus, le P&ID sert de base pour former les opérateurs sur ce qu’ils peuvent faire sur le procédé physique et sur comment utiliser l’interface de supervision associée (Turton et al. 2008).

50 M V 2 V M 0 1 M V 2 V M 0 2 St1 Eau douce 70,00 St2 Eau douce 70,00 LT 0001 LI 0001 LS 0001 LI 0002 LS 0002 LT 0002 LAH 0001 LAH 0002 LAL 15% LIL 30% LIH 98% LAH 100% LI 1 LAL 15% LIL 30% LIH 98% LAH 100% LI 2 M V2VM03 M V2VM04 M V2VM05 M V2VM06 M V2VM07 M V2VM08 M M M 6 bar TR1 Chloration M V2VM10 Cl5 Cl6 Cl7 Cl8 Cl9 V3VM01 V3VM02 V3VM03 Lm1 H-2 PC PT PAH 6bar PIH 6,5bar PIL 5,5bar PAL 5bar PI PIC H-3 ^PT PI PIC PAH 6bar PIH 6,5bar PIL 5,5bar PAL 5bar PC H-1 PC PT PAH 6bar PIH 6,5bar PIL 5,5bar PAL 5bar PI PIC

Figure 22 Schéma P&ID d’un système de transfert de fluide

Formellement vérifié (Mesli-kesraoui, Kesraoui, et al. 2016), le PID est considéré comme une spécification graphique formelle. Cette vérification formelle est nécessaire car il est généralement construit par l'ingénieur de procédé (expert métier) (McAvinew and Mulley 2004) et peut contenir des erreurs. Il est souvent complété par des CFD qui décrivent les flux liés au pilotage du système (Fiorèse and Meinadier 2012).

2.3.1.2 SADT

SADT (Marca and McGowan 1988) fait partie des approches traditionnelles de l’analyse fonctionnelle qui s’appuient sur les techniques de décomposition et sur les représentations des flots de données pour donner l’arborescence des fonctions d’un système. Dans cette approche, le système de contrôle-commande est identifié à une fonction globale qui est ensuite décomposée en des fonctions plus détaillées. L’analyse fonctionnelle est donc considérée comme descendante car elle part du général pour aller au particulier.

Fréquemment utilisée dans l’industrie, la notation SADT permet une description graphique du système en combinant le DFD et le CFD pour tenir compte des aspects structurels et comportementaux (Fiorèse and Meinadier 2012). Cette méthode reste tout de même inadaptée à la conception des systèmes de contrôle-commande car elle ne permet pas de prendre en compte toute la dynamique du système (Moussa 2005) et n’est pas souvent cohérente avec le PID qui est une représentation structurelle du système.

2.3.2 Spécification graphique du point de vue de l’utilisateur : la modélisation des

tâches

Les approches de spécification fonctionnelle se placent du point de vue du système (et du concepteur). L’utilisateur n’y est généralement pas pris en compte. Cependant, dans la conception des systèmes de contrôle-commande, la prise en compte de l’utilisateur est incontournable car elle permet d’éviter des erreurs de d’utilisation. L’étape de spécification fonctionnelle est alors souvent complétée par l’analyse et la conception de modèles de tâches. L’utilisation des modèles de tâches dans une conception pluridisciplinaire est devenue de plus en plus répandue (Lewandowski, Bourguin, and Tarby 2007). Généralement le modèle de tâches constitue l’un des points de départ de la conception car il aide à la compréhension de

51 l’activité humaine et de l’utilisation du système à concevoir. Les principes de base des modèles de tâches ne diffèrent pas beaucoup d’une modélisation de tâches à une autre, quelle que soit l’approche utilisée (Lachaume et al. 2014).

Les modèles de tâches visent à exprimer les tâches humaines en s’appuyant sur l’analyse de l’activité pour répondre aux besoins de la conception. Les tâches sont généralement décrites suivant des mécanismes de structuration. Ces mécanismes offrent des opérateurs temporels qui permettent une décomposition hiérarchique des tâches en sous-tâches, avec une catégorisation en fonction des types de tâches. En vue d’une description plus précise de l’activité, il est possible de rajouter aux tâches des attributs tels que optionnelle, itérative, ainsi que des pré et post-condition.

2.3.2.1 Les types de tâches

Les types de tâches permettent de décrire plus aisément l’activité humaine en fournissant des informations plus précises sur la nature de la tâche (Martinie 2011). Pour les activités qui conduisent à des interactions entre le système et l’utilisateur, les types de tâches permettent de distinguer les rôles lors de la description du modèle. Dans les approches récentes de

modélisation de tâches telles que CTT (Paternò, Mancini, and Meniconi 1997), K-MAD6,

HAMSTERS (Martinie 2011), etc., on retrouve généralement au minimum quatre types de tâches : tâches système, tâches utilisateur, tâches interactives et tâches abstraites.

Les tâches systèmes concernent les fonctions exécutées uniquement par le système. Elles concernent les traitements informatiques et le retour d’information sur les résultats de ces traitements. Pour les tâches utilisateur, seul l’utilisateur est engagé dans la réalisation des tâches. Ces tâches impliquent par exemples des activités de réflexion, de prise de décision, etc. Les tâches interactives impliquent à la fois l’utilisateur et le système. Elles sont utilisées lorsqu’il y a une information à passer entre l’utilisateur et le système (l’utilisateur agit et le système répond). Les tâches abstraites sont des tâches complexes qui sont décomposables en sous-tâches de types différents.

2.3.2.2 Les opérateurs

Les opérateurs permettent de décrire la dynamique du modèle de tâches. Dans les approches de modélisation de tâches, il existe plusieurs opérateurs qui permettent d’exprimer la relation entre les sous-tâches d’une tâche décomposée. Ces opérateurs s’inspirent des opérateurs LOTOS (Paternò and Faconti 1992). Dans CTT par exemple, l’une des approches initiales de modélisation de tâches, on distingue quatre opérateurs :

- L’opérateur Enabling >> permet d’exprimer le fait que la réalisation des sous-tâches doit suivre une séquence prédéfinie.

- L’opérateur Choice [] permet d’exprimer le fait que l’utilisateur peut choisir entre plusieurs sous-tâches.

- L’opérateur Concurrent ||| d’exprimer le fait que les sous-tâches devront être exécutées simultanément.

- L’opérateur Order independant |=|permet d’exprimer le fait que les sous-tâches ne sont pas tenues d’être réalisées dans un ordre spécifique.

52

2.3.2.3 Les attributs et les conditions

Les attributs et les contextes permettent d’avoir une précision dans la description de l’activité. Parmi les attributs ceux qui reviennent souvent et qui ont des conséquences sur la dynamique du modèle (Lachaume et al. 2014) on peut noter l’attribut itération et l’attribut optionnel. L’itération indique que la tâche est répétitive. Le choix de l’attribut optionnel sur une tâche indique que, selon le contexte, la tâche peut ne pas être exécutée.

La précision sur le contexte et les conditions de réalisation d’une tâche est importante pour la description fine de l’activité. Deux types de conditions sont généralement exprimés dans les modèles de tâches. L’expression d’une précondition sur une tâche permet de définir le contexte (les prérequis de la tâche) dans lequel la tâche est réalisable. Les post-conditions, quant à elle, expriment l’état requis après l’action.