Cette quatrième étape de synthèse est la dernière de la liste. Si nous faisons abstraction
des autres indéterminismes liés aux autres événements de type "résultat de diagnostic",
"résultat de décision", etc., le modèle obtenu suite à cette étape doit correspondre à la
loi de surveillance respectant chacune des propriétés recherchées.
An de limiter la profondeur d'appel à un même traitement de défaillance, deux étapes
doivent être envisagées. En premier lieu, il s'agit de localiser les boucles répétitives
conte-nues dans le modèle de référence réduit. En deuxième lieu, il s'agit de les limiter.
Pour ce faire, nous nous sommes appuyés sur le langage généré par l'automate.
Le langage reconnu parM′ est déni parΨ(s). Il est composé par l'ensemble des traces
non nulles qui conduisent à nouveau à l'état initial (égal à l'état marqué). Il est déni
par :
Ψ(s) = {s∈M′|(x0, s)→xm,|s|>0}
L'ensemble Ψ(s) est composé de séquences répétitives. Dans cet ensemble, nous
pou-vons distinguer deux types d'évolutions principales :
Ψ(s) = Ψ(sn)∪Ψ(st)
Ψ(sn) = {s∈M′|(x0, s)→xm,|s|>0, θ /∈s}
Ψ(st) ={s ∈M′|(x0, s)→xm,|s|>0, θ∈s}
Le premier ensemble caractérise les évolutions qui se déroulent en fonctionnement
nor-mal. L'exclusion de l'événementθ indique que nous ne considérons pas dans cet ensemble
les séquences qui prennent en compte les dysfonctionnements. Le deuxième ensemble est
le complément du premier. Il s'agit des séquences qui représentent les traitements de
défaillances et qui conduisent à nouveau vers une des activités appartenant au
fonction-nement normal.
An de rejeter de toutes les boucles de surveillances tout appel inni au même
traite-ment de défaillance, nous proposons de limiter le nombre de séquences itératives contenues
dans Ψ(st), hormis celles qui concernent les traitements d'urgence. En eet, limiter
l'exé-cution répétitive d'une séquence d'urgence, c'est prendre le risque de perdre tout ou partie
du procédé. En conséquence, nous proposons la procédure suivante :
120 3.7. Conclusion
défaillance. Soit s∗
i une fermeture itérative contenue dans Ψ(st) provoqué par
l'oc-currence d'un nouveau événementθ. Soitx∗i =x1, x2, ..xn|xi ∈X′ l'ensemble d'états
visités suite à l'exécution de la séquence si.
Les séquences s∗
i sont limités dans le nombre d'exécutions si et seulement si les états
visités par la séquence ne sont pas contenus dans le mode des traitements d'urgence (D1).
Cette limitation est faite en autorisant l'exécution de ces séquences un nombre maximum
n pour ensuite forcer l'application d'un traitement d'urgence. Ce forçage est fait avec
l'inclusion d'une nouvelle séquence s(i)′ avec le passage au traitement d'urgence pour
qu'il soit appliquée après avoir atteint le nombre maximum d'appels autorisés.
s∗
i →n(si)|s∗
i ∈Ψ(st), D1∈/ x∗
i(m)
si =s′
i−θ+θ′ |δ(xn, θ) =x′, x′(m) =D1
Ψ(st) = Ψ(st)−s∗
i +n(si) +s′
i
3.7 Conclusion
Dans ce chapitre, nous avons présenté notre approche de synthèse de lois de
sur-veillance. La technique proposée est parfaitement générique et donc applicable à toute
ressource/produit, à la condition bien entendu de disposer de toutes les ches techniques
les concernant. D'un point de vue utilisation, la technique de synthèse se décline en quatre
phases de ranement du modèle de référence. La première permet au concepteur
d'in-tégrer les propriétés liées aux modes de marches et d'arrêts du fonctionnement normal.
Ici, la technique retenue reprend celle proposée déjà par le GEMMA. Une extension est
cependant faite an de pouvoir l'adapter à la classe de modèle que nous utilisons. La
deuxième technique permet au concepteur d'injecter dans le modèle quatre critères qui
ont des conséquences directes sur le choix des traitements de défaillances qu'il faut
dé-clencher en fonction du type de symptôme détecté. Ces quatre critères représentent à la
fois le point de vue de la législation (Sécurité et Écologie) et le point de vue de l'entreprise
(Productivité et Qualité). Bien entendu, comme nous avons pu déjà en faire la remarque,
d'autres critères peuvent être pris en compte en fonction de l'entreprise considérée. Mais
rappelons que l'objectif essentiel de notre approche est de démontrer d'une part la
néces-sité de synthétiser des lois de surveillance respectant des propriétés, d'autre part d'établir
les diérentes classes de propriétés de la problématique, et enn de montrer la
faisabi-lité d'une telle synthèse. Si d'autres propriétés doivent être prises en compte, l'approche
générale proposée peut être facilement étendue. La troisième étape de synthèse permet
quant à elle de prendre en compte les priorités que doit établir le concepteur au sein de
deux groupes de critères. Nous avons en eet volontairement imposé que les critères de
Sécurité et d'Écologie soient toujours plus prioritaires que la Productivité et la Qualité.
Au sein d'un groupe, nous avons cependant montré les limites d'une telle marge de
exi-bilité laissée au concepteur. Si ce dernier ne classe pas, par exemple "je considère que la
productivité est aussi importante que la qualité", des conits structuraux peuvent alors
subsister dans le modèle de référence réduit. La résolution de ces conits risque alors
d'être laborieuse, étant donné que le concepteur aura à les passer tous en revue. Enn, la
quatrième technique permet de contraindre les cycles innis utilisables dans le modèle de
référence réduit. Il est en eet inimaginable d'accepter de traiter indéniment de la même
façon l'occurrence répétitive d'une même défaillance au cours de l'application d'un seul
traitement.
La suite de ce mémoire est entièrement consacrée à une application de notre approche
de synthèse de lois de surveillance sur un exemple inspiré d'une installation réelle, la
plate-forme de recherche SAPHIR du Laboratoire d'Automatique de Grenoble.
123
Quatrième partie
Exemple d'application
Chapitre 1. Présentation de la plate-forme de recherche SAPHIR 125
Chapitre 1
Présentation de la plate-forme de
recherche SAPHIR
1.1 Introduction
Dans cette partie, nous avons souhaité développer un exemple d'application de notre
approche de synthèse de lois de surveillance sur la base du procédé pilote SAPHIR du
Laboratoire d'Automatique de Grenoble. Ce choix nous a semblé judicieux pour plusieurs
raisons. Premièrement, cette plate-forme de test et de validation est exclusivement dédiée
à la recherche. Deuxièmement, elle est localisée dans le laboratoire où nous avons mené nos
travaux de recherche. Elle est donc facilement accessible. Troisièmement, et comme nous
allons le voir dans le premier chapitre de cette partie, SAPHIR se prête particulièrement
bien à l'étude des défaillances du procédé. Elle met à disposition à la fois des capteurs de
surveillance et de commande permettant de valider tout type d'approche de surveillance
(surveillance intégrée, séparée ou mixte), elle permet d'illustrer les phénomènes de
propa-gation de défaillances, elle ore un terrain propice à l'étude des stratégies de surveillance
en mettant à disposition des ressources physiques hétérogènes. Enn, sa structure
opé-rationnelle autorise l'étude de diérents types d'architectures décisionnelles en partant
des architectures purement hiérarchiques jusqu'aux structures entièrement distribuées en
passant par les architectures mixtes.
Dans le cadre de ce premier chapitre, nous allons donc plus particulièrement nous
intéresser à la présentation de la plate-forme de recherche SAPHIR. Le premier paragraphe
s'attachera à donner les caractéristiques techniques essentielles de la plate-forme. Il s'agira
notamment d'en présenter le cahier des charges général, la partie opérative, la partie
commande et enn l'architecture opérationnelle retenue dans le cadre de cet exemple
d'application. Après quoi, nous présenterons l'adéquation de SAPHIR à l'étude, le test et
la validation d'approches de surveillance, commande et supervision.
Remarque : la plupart des informations présentées ici sont extraites des
do-cuments Zamaï et al. [2000] et Zamaï [2001]. Pour plus d'informations, le
lecteur peut se reporter au site WEB http://www-lag.ensieg.inpg.fr/saphir.
Dans le document
Synthèse de lois de surveillance pour les procédés industriels complexes
(Page 120-127)