Etablir les modes de marche et d’arrêt (A.5)

Les applications envisagées avec notre méthode étant à la fois logicielles et matérielles, il est néces-saire de prendre en considération les modes de marche et d’arrêt. Cette activité est inspirée du GEMMA (Guide des Modes de Marche et d’Arrêt) qui est un guide permettant de structurer graphiquement le fonctionnement des systèmes automatisés de production (SAP) [Moreno and Peulot, 1997]. En effet, le GEMMA a pour vocation de regrouper par thème les états d’un SAP qui serait vu comme une machine à états finis. A ce titre, le GEMMA est utilisé en collaboration avec les GRAFCET. Nous en avons fait un outil textuel pour spécifier des modes de fonctionnement important du système. Des modes ont été supprimés car ils étaient trop spécialisés pour les SAP tandis que d’autres ont été étendus ou ajoutés.

A.5.1 Déterminer les modes de marche ! A.5.2 Déterminer les modes d’arrêt ! A.5.3 Déterminer les modes défaillants

Cette partie de l’étude est très importante car elle va permettre de structurer le fonctionnement global du système. Si généralement on souhaite que le système fonctionne en autonomie, il est nécessaire de connaître précisément tous les autres comportements : comment doit être le système avant l’arrêt ? com-ment doit être le système pour être étalonné/réglé ? comcom-ment prendre en compte les arrêts d’urgence? Même si le problème sera par la suite résolu de manière décentralisée, cette organisation des modes de fonctionnement présente l’avantage d’être facilement interprétable par le demandeur et l’utilisateur. De plus, bien qu’à intelligence décentralisée le système doit se soumettre à une législation qui impose, à raison, la présence d’arrêts d’urgence pour les systèmes physiques pouvant nuire à l’intégrité d’une personne ou d’un bien. Ainsi on établit des procédures de marches, de défaillances et d’arrêts. On peut aussi spécifier les transitions entre ces modes. Pour chacun de ces modes, un document doit préciser une description de l’état attendu du système (partie informelle) et formuler les propriétés qui permettront de caractériser l’état du système. On va donc déterminer les propriétés qui, selon qu’elles soient ou non respectées, feront que l’on sera dans un état de marche normal, défaillant ou d’arrêt.

Cette définition des modes pourra en plus, par la suite :

– mettre en exergue des modes de fonctionnement dégradés du système, – spécifier les premiers éléments nécessaires à la tolérance aux pannes, – permettre l’identification de situations de coopération ou non coopération,

– permettre de définir des états de reconnaissance utiles pour l’analyse d’un processus auto-organi-sationnel d’une application,

– prendre en compte la sécurité de l’intégrité physique de l’utilisateur éventuellement plongé dans le système physique.

Déterminer les modes de marche (A.5.1). Les modes de marches définissent les états de

fonction-nement du système mais insistent aussi sur les états d’étalonnage ou de réglage du système. A ce niveau de l’étude on n’envisage pas forcément des réglages automatiques : on souhaite obtenir du demandeur

La définition des besoins (étape A) 77

des informations très importantes qu’il ne penserait pas forcément à fournir. Selon l’application, il se peut que des modes soient inutiles voir sans aucun sens.

Les différents modes de marche que l’on peut identifier sont présentés ci-dessous :

– Marche normale : Nous allons nous intéresser dans ce mode au fonctionnement normal du système à concevoir. Ce mode a surtout un intérêt pour la sûreté de fonctionnement. On définira par exemple les propriétés que doit vérifier le système qui prouve son fonctionnement normal.

– Marche de préparation : La spécification de ce mode permet de préciser les contraintes à prendre en compte pour amener à une marche normale. Au niveau global cela se traduit généralement par des conditions sur, par exemple, les ressources disponibles à l’intérieur du système. Au niveau local, cela se traduit par des contraintes de fonctionnement pour les composants du système : un robot ne peut être disponible que si son niveau d’énergie est supérieur à un seuil, l’utilisation d’un four peut nécessiter une préchauffe d’une durée donnée etc. Comme on le pressent, l’étude de ce mode sera surtout utile pour les composants physiques du système.

– Marche de clôture : La spécification de ce mode permet de définir l’état que doit atteindre le sys-tème avant un arrêt prolongé. On va donc s’intéresser aux actions à effectuer pour pouvoir procéder à un arrêt du système : des robots mobiles peuvent avoir à se rendre dans un espace de stationne-ment etc.

– Marche de vérification en marche : Dans cet état on va s’intéresser à la possibilité/nécessité de vérifier les différentes primitives des composants du système ou de fonctionnalités globales du système. De telles procédures peuvent être nécessaires pour vérifier le bon fonctionnement ou isoler un problème.

– Marche de vérification en hors-marche : Dans cet état on va s’intéresser aux procédures de véri-fications beaucoup plus complètes mais qui nécessitent que le système suspende temporairement son fonctionnement normal. Ces procédures ne concernent pas seulement la vérification mais les modes de suspension.

– Marche d’étalonnage : La spécification de ce mode permet de définir le protocole de réglage ou d’étalonnage d’un système.

Déterminer les modes d’arrêt (A.5.2). L’étude des modes d’arrêt va permettre tout d’abord

d’iden-tifier les états d’arrêt qui peuvent survenir pour des raisons extérieures au système. On définit aussi les éventuelles procédures qui les accompagnent. Ces états permettent d’amener le système à un arrêt nor-mal ou de préparer le système à une procédure de re-initialisation. Selon l’application, il se peut que des modes soient inutiles voire sans aucun sens.

Les différents modes d’arrêt que l’on peut identifier sont :

– Repos : Il s’agit de caractériser ici l’état dans lequel se trouve le système lorsqu’il est au repos c’est-à-dire en attente de tâches à effectuer.

– Arrêt demandé en marche normale : La spécification de ce mode d’arrêt permet de s’intéresser à la suspension du fonctionnement normal sans pour autant procéder à une interruption brutale du système. Cela peut se limiter à identifier les états durant lesquels on peut arrêter le système et donc s’intéresser aux procédures pour l’y conduire. Ce mode est par exemple intéressant pour des systèmes utilisant des ressources finies. En effet, si un système peut éventuellement nécessiter qu’on interrompe son fonctionnement normal afin de le ré-alimenter. Par souci de sécurité il se peut que cette opération ne soit possible que dans des états particuliers du système.

– Arrêt demandé dans un état déterminé : La spécification de ce mode d’arrêt permet de conduire le système à un arrêt différent du précédent afin que, par exemple, une équipe de maintenance intervienne sur le système.

78 La démarche de la méthode DIAMOND

– Préparation pour remise en route après défaillance : La spécification de ce mode permet de rame-ner le système après une défaillance dans un état qui lui permettra de remettre en route le système. Cela peut se faire de manière automatique ou, éventuellement, nécessiter que des opérateurs inter-viennent pour corriger le système (initialiser un élément etc.).

Déterminer les modes défaillants (A.5.3). L’étude des modes défaillants va permettre de

spéci-fier les procédures de sécurité permettant de réagir lorsqu’une défaillance est rencontrée. Les différents modes défaillants qu’il est possible d’identifier sont:

– Marche ou arrêt en vue d’assurer la sécurité : Cet état permet de gérer le système lors d’un arrêt d’urgence. On prévoit dans cet état toutes les mesures visant à protéger l’utilisateur et le système, les cycles de dégagements et les précautions pour limiter les conséquences d’une défaillance. – Diagnostic et/ou traitement de défaillance : Ce mode traite de ce qui permet à la maintenance de

diagnostiquer l’origine de la défaillance et d’envisager le traitement approprié qui permettra le redémarrage du système après traitement de la défaillance. Dans ce mode, le système est arrêté. – Marche dégradée : Cet état permet de permet de passer outre une défaillance non résolue du

sys-tème.

Documentation liée à ce processus A.5 . A partir de toutes les informations cumulées, et donc

toutes les fiches, on renseigne trois fiches : une fiche d’étude des modes de marche (figure D.7), une fiche

d’étude des modes d’arrêt et une fiche d’étude des modes défaillants. Ces fiches doivent être validées par

le demandeur et les utilisateurs du système à concevoir. En effet, un des intérêts de ces fiches est qu’elles sont compréhensibles par des non-informaticiens.

Application au cas d’étude : Structurer le fonctionnement global du système

Pour notre application, après discussion avec le demandeur, les modes identifiés sont :

1. Mode d’arrêt : Deux modes sont pertinents. Dans cette application les autres modes ne sont pas exploités.

– Repos : Dans un état de repos, les robots sont immobiles.

– Arrêt demandé en marche normale : Si on doit le ré-alimenter un robot doit se positionner dans un coin de son camp (coté cage) en attendant la mi-temps que tous les robots soient immobiles.

2. Modes de marche : le mode de vérification en marche normale n’a aucun sens car pendant un match on ne peut pas procéder à une vérification. On peut par contre procéder à des vérifications hors marche normale.

– Marche normale : dans ce mode tous les robots doivent répondre aux requêtes de l’arbitre, aucun robot ne signale de problème, il n’y a pas d’arrêt d’urgence.

– Marche de préparation : Durant la phase de préparation les robots sont positionnés sur le terrain. Dans ce mode les robots ne doivent ni bouger ni utiliser leurs actionneurs. Ce mode prend fin quand l’arbitre déclare la période de paramétrage commencée.

– Marche de clôture : avant un arrêt prolongé les robots doivent retourner dans le camp et se rapprocher des coins pour que leur extraction soit facilitée.

– Marche de test : on peut vouloir étalonner la puissance maximale du tir. En effet, par souci de sécurité les vitesses maximales des robots et de la puissance de tir sont limitées. De plus la vitesse d’éjection de la balle n’est pas la même si on fait une passe ou un tir.

L’étape d’analyse (étape B) 79

3. Modes défaillants : seul la gestion des arrêts d’urgence est pertinente dans notre application. – Marche ou arrêt en vue d’assurer la sécurité : Si un arrêt d’urgence est activé, les robots n’ont

plus le droit de bouger.