Système de régulation de température HNO3: ----------------------------------------- Question 1: Le modèle hno3_v11 est-il valide? ---------- Non! 1) il n'est pas valide de manière syntaxique. --------------------------------------------- Lors de la vérification syntaxique, il apparait qu'il existe certaines spécifications non utilisées (états ou transitions): - dans la vanne V5, lors de la validation la ligne suivante "wts(src(*-toutes),*-toutes,Vanne5);" affiche le résultat suivant: ------------------------------------------------- | transition_system Vanne5; | | | | ouverteAlimentee |- | | couper -> ouverteNonAlimentee, ; | | | | ouverteNonAlimentee |- | | e -> ouverteNonAlimentee, | | KO -> ouverteNonAlimentee, | | alimenter -> ouverteAlimentee, | | couper -> ouverteNonAlimentee, | | fermer -> fermeeNonAlimentee, | | ouvrir -> ouverteNonAlimentee; | | | | fermeeAlimentee |- | | couper -> fermeeNonAlimentee, ; | | | | fermeeNonAlimentee |- | | e -> fermeeNonAlimentee, | | KO -> fermeeNonAlimentee, | | alimenter -> fermeeAlimentee, | | couper -> fermeeNonAlimentee, | | fermer -> fermeeNonAlimentee, | | ouvrir -> ouverteNonAlimentee; | | | | < | | initial = { ouverteAlimentee }, | | tous = { ouverteAlimentee, fermeeAlimentee } | | >. | ------------------------------------------------- Cela nous montre chaque ligne non utilisée dans ce modèle ci. Le probleme vient de la transition "couper", qui n'est jamais utilise. Ainsi, on ne va jamais dans l'etat "fermeeNonAlimentee" et "ouverteNonAlimentee". Il faut donc enlever la transition "couper" qui correspond à une perte d'alimentation en eau et qui n'a donc pas à apparaitre dans ce modèle censé être sans panne. - De meme dans le systeme de synchronisation, il faut enlever les transitions eauPlus de "EauPrimaire" et "EauSecondaire" car elles correspondent a une panne que nous ne devons pas traiter. De plus la transition eauPlus n'apparait pas dans le systeme de transitions. - On corrige de la meme facon les problemes de validation syntaxique lies a Pompe, IndicateurTemperature et ControleurPannePompe. La Pompe ne tombe jamais en panne, et le ControleurPannePompe ne sert a rien. Les transitions BIP et NotBIP ne sont pas utilisees dans cette version. Conclusion: on a un modele syntaxement correcte: Le tout se trouve dans le repertoire suivant: Version11_syntaxiquememt_correcte/ - le systeme de transition : hno3_v11.st - le systeme de synchronisation: hno3_v11.ss - le fichier de validation : hno3_v11.validation 2) Probleme de coherence : -------------------------- - En lancant la simulation on obtient 32 etats Dead. En faisant un wts(Dead, *), on se rend compte que l'echangeur thermique peut se retrouver en KO alors que la vanne V1 est fermee. Cela ne correspond pas a la realite. On contraint donc le systeme de synchronisation : la transition BOOM ne peut survenir que si la vanne V1 est ouverte (dans l'echangeur thermique, BOOM entraine l'arret du systeme) version(); //MEC 4 version alpha 3.4dts(v11); //Current St : v11 //--- States : // * : 144 //initial : 1 //dead : 16 //deadlock : 16 //pbModifTemp : 0 //pbBOOM : 16 //pbPlusAir : 8 //pbMoinsAir : 4 //pbFermerV1 : 16 //pbFermerV5 : 16 //pbOuvrirV1 : 16 //pbOuvrirV5 : 16 //pbActiverAP : 16 //pbInhiberAP : 16 //--- Transitions : // * : 1280 //boucle : 1264 //boucleinitial : 1264 //stoplog(); // On obient deux fois moins d'etats Dead. Mais pbBOOM passe a 16 etats. c'est du au fait que la transitions BOOM n'est plus une incontrolable car on a impose une contrainte dessus. (Seuls les evenements qui conduisent a une explosion sont incontrolables, pas l'explosion en elle meme). On enleve donc le calcul de pbBOOM du fichier de validation. Dans l'etat actuel des choses, le systeme represente un monde reel ou le Capteur de Temperature recupere la temperature de l'Echangeur Thermique a certains intervalles de temps. Le probleme est que pendant cet intervalle de temps, la temperature de l'Echangeur Thermique peut augmenter tres significativement (jusqu'a l'explosion). Le Capteur de Temperature ne s'en est pas rendu compte. Dans notre systeme, cela est represente par le fait que l'on peut avoir plusieurs tMonte de suite dans notre Echangeur Thermique(jusqu'a l'explosion), sans avoir de tIs qui puisse le signaler au Capteur de Temperature. Cela ne va surement pas convenir au donneur d'ordre!!! Puisque comme le Capteur Thermique peut ne pas se rendre compte de la montee de temperature, il ne "previendra" pas l'Operateur via l'Indicateur de Temperature. 3) Contraintes : - On va maintenant contraindre un peu plus le systeme. On suppose que, dans le monde reel, le Capteur de Temperature fait des prises de temperature assez souvent pour etre au courant d'un changement de temperature de l'Echangeur Thermique et qu'il le signale au Controleur de Temperature. C'est ce qu'on a modelise dans le systeme de synchronisation "v11_plus_contraint". On couple donc les changements d'etats de l'Echangeur Thermique avec ceux correspondant du Controleur de Temperature et a l'indicateur de temperature. (cf dans "Version11_finale/hno3.ss" le systeme v11_plus_contraint) De meme, on contraint la relation entre la vanne V5 et l'Echangeur Thermique lors de la transition BOOM. On dit que l'explosion ne peut avoir lieu que si la vanne V5 est KO. Car si elle est OK, la temperature descend et l'explosion n'a pas lieu. Actuellement (modele sans panne), la vanne est KO lorsqu'elle est fermee. Mais la signification exacte de KO pour V5 c'est qu'elle ne peut pas fournir d'eau a l'Echangeur Thermique. Une fois les pannes introduites, KO (V5) pourra par exemple etre la consequence d'une panne de pompe. 4) modification du calcul portant sur les evenements incontrolables, afin que les resultats soient toujours l'ensemble vide. - On ne compte plus pbModifTemp (puisque l'on a contraint le changement de temperature de l'echangeur thermique). - On rajoute Dangereux := deadlock - dead (correspond aux situations ou il est inevitable qu'une explosion se produise) Dangereux = 0 veut dire qu'on a toujours le choix avant l'explosion. Dangereux != 0 veut dire qu'on peut arriver dans un etat ou il sera inevitable a partir de la qu'il y ait l'Evenement Redoute. - Pour reduire les calculs sur les autres evenements a l'ensemble vide, on ecrit: pbPlusAir := (src_incont1[4] - src(incontrolable1[4])) - dead; pbMoinsAir := (src_incont2[4] - src(incontrolable2[4])) - dead; pbFermerV1 := (src_incont1[12] - src(incontrolable1[12])) - dead; pbFermerV5 := (src_incont2[12] - src(incontrolable2[12])) - dead; pbOuvrirV1 := (src_incont3[12] - src(incontrolable3[12])) - dead; pbOuvrirV5 := (src_incont4[12] - src(incontrolable4[12])) - dead; pbActiverAP := (src_incont5[12] - src(incontrolable5[12])) - dead; pbInhiberAP := (src_incont6[12] - src(incontrolable6[12])) - dead; - On enleve les etats Dead, car de ces etats, les evenements incontrolables ne peuvent avoir lieu. Le tout se trouve dans le repertoire suivant : Version11_finale/ - le systeme de transition : hno3_v11.st - le systeme de synchronisation: hno3_v11.ss - le fichier de validation : hno3_v11.validation - le fichier de resultat : v11_finale Question 2 : Expliquez la difference entre hno3_v11 et hno3_v12. ---------- La difference se situe sur l'Operateur. Dans le modele hno3_v11, l'Operateur est completement "incontrolable", c'est-a-dire qu'il peut faire ce qu'il veut quand il le veut. Dans le modele hno3_v12, on contraint le comportement de l'Operateur par l'intermediaire de l'Indicateur de Temperature c'est-a-dire qu'il ne peut faire certaines actions que si l'Indicateur de Temperature lui donne l'autorisation (par BIP ou notBIP). Par exemple, l'Operateur ne peut pas fermerV5 s'il y a BIP c'est-a-dire si l'Indicateur Thermique est dans l'etat TSupSupTc, soit l'Echangeur Thermique est dans l'etat "danger". Ce qui peut sembler assez sain comme comportement (surtout pour lui). En fait, dans la version 11, l'utilisateur pouvait faire ce qu'il voulait et quand il le voulait. Il ne peut plus le faire dans la version 12. Les evenements lies a la la vanne V1, a la vanne V5 et le controleur de temperature ne sont plus des incontrolables. On ne fait plus apparaitre le calcul sur ces evenements dans le fichier de validation. De plus, l'Operateur a maintenant comme comportement des enchainements d'actions dont il ne peut pas devier. Voir ci-dessous : innibeAp fermerV5 fermerV1 ---------- ------------ ------------ / \ / \ / \ --- --- --- --- |0| |1| |2| |3| --- --- --- --- \ / \ / \ / ---------- ------------ ------------ activerAP ouvertV5 ouvrirV1 Le comportement de Operateur ne lui permet de manipuler V1 et/ou V5 qu'apres avoir "inhiberAP", c'est-a-dire apres avoir mis l'Air Comprime en mode manuel. Donc les vecteurs de synchronisation ( e . e . e . e . isAuto . e . e . e . e . NotBIP . e . fermerV5); et ( e . e . e . e . isAuto . e . e . e . e . NotBIP . e . fermerV5); n'ont plus raison d'etre. On met donc a jour le systeme de transition de Air Comprime. - Dans le systeme de transition Vanne1, les deux transitions suivantes ne sont pas utilisees : transition_system Vanne1; ouverte |- ouvrir -> ouverte; fermee |- fermer -> fermee, ; < Cela s'explique par le fait que selon le systeme de synchronisation c'est seulement l'Operateur qui peut ouvrir ou fermer la Vanne1. Or selon la definition d'Operateur2, celui-ci ne peut ouvrir deux fois de suite la Vanne1. (idem pour fermer). On les enleve! Question 3: ----------- Lorsqu'on veut introduire une panne : - il faut changer le systeme de transition du composant, rajouter un etat "panne" d'ou on est bloque. - indiquer dans le systeme de synchronisation que la panne peut arriver n'importe quand et qu'elle n'est pas contrainte, - finalement indiquer le comportement que la panne va induire sur les autres automates du systeme, - rajouter dans la validation une ligne pour calculer le caractere incontrolable de la panne. Exemple d'insertion d'une panne dans le circuit primaire : -------------------------------------------------------- 1) On modifie le systeme de synchronisation de EauPrincipale : transition_system EauPrincipale < width = 0 >; 0 |- e -> 0, eau -> 0, panne -> PanneEauPrim ; PanneEauPrim |- e -> PanneEauPrim, plusEau -> PanneEauPrim; < initial = { 0 } >. 2) On rajoute le vecteur de synchronisation : EauPrincipale ( e . e . e . e . e . e . panne . e . e . e . e . e); 3) le ciruit primaire d'eau vient a manquer d'eau: Cela n'a aucune incidence sur les autres automates car le circuit secondaire prend le relais. 4) on rajoute la ligne suivante dans le fichier de validation. dts(EauPrincipale); src_incont1 := src(incontrolable1); ... pbPannEauPrim := (src_incont1[7] - src(incontrolable1[7])) - dead; Insertion d'une panne dans le circuit secondaire : -------------------------------------------------- le ciruit secondaire d'eau vient a manquer d'eau: - Si le circuit primaire fonctionne, ca n'a aucune incidence sur le reste du systeme. - Si le circuit primaire et le circuit secondaire tombe en panne, la pompe n'est plus alimente en eau. -> Il faut donc aussi rajouter des etats a la pompe. -> enfin la vanne V5 doit comporter de nouveaux etats signalant qu'elle n'est plus alimentee en eau. Insertion d'une panne dans la pompe : ------------------------------------- 1) On effectue la meme demarche que precedemment. Qn rajoute l'etat PannePompe a l'automate de la pompe. 2) On rajoute un vecteur de synchronisation indiquant que la panne peut arriver n'importe quand. etant donne que l'on a mis un controleur de panne de pompe, on suppose que ce dernier est prevenu immediatement de la panne. on synchronise donc l'action du controleur de panne (FD) et la fermeture de V1 avec la panne. De meme, l'arret de la pompe se repercute immediatement sur la vanne V5 car il n'y a plus de pression dans le tuyau V1 V5 Pompe FD ( fermer . e . e . e . e . couper . e . e . panne . e . fermerV1 . e). 3) On doit changer le comportement de ComtroleurPannePompe (de maniere a ce qu'il ferme V1 quand la pompe est en panne). On regarde qui doit etre prevenu d'une panne de la pompe: -> le ControleurPannePompe, -> la vanne V5 car elle n'est plus alimentee. 4) On ne verifie pas dans le fichier de validation l'evenement incontrolable pbPannePompe, car il n'est plus vraiment incontrolable. Pour l'insertion des autres pannes, on utilise la meme technique. Question 4: ----------- 1) Modele hno3_v11.finale: comme on le dit plus haut, les elements du systeme sont dit "infaillible". Les seuls cas ou peuvent survenir une explosion sont du une maladresse de l'operateur qui peut fermer V5 et ouvrir V1. Il est aussi possible qu'une explosion puisse survenir alors que le Comtroleur Pneumatique est en mode automatique et que la vanne V5 est ouverte. Ceci est contraire au fonctionnnement attendu, et est du au fait que V5 ne stipule pas immediatement ses changements d'etats a l'Echangeur Thermique. On n'a pas voulu contraindre aussi V5. 2) Modele hno3_v12: Ce systeme est identique au precedent, mais l'operateur ne peut plus faire n'importe quoi n'importe quand. Il peut cependant toujours etre a l'origine d'une explosion en fermant V5 et en ouvrant V1. Mais on suppose qu'il aura un comportement intelligent, et donc dans un etat "dangereux" il choisira la bonne solution pour ne pas aller dans BOOM. 3) Modele hno3_v21: L'ajout d'une panne sur le systeme d'alimentation en eau primaire n'a aucun effet sur le fonctionnememt global du systeme, car le systeme secondaire prend le relai pour alimenter la pompe. L'exploxion est toujours du a un operateur ne faisant pas correctement son travail. 4) Modele hno3_v22: L'ajout de la seconde panne sur le systeme secondaire rajoute des possibilitees d'explosion. Si l'eau primaire et l'eau secondaire tombe en panne, la vanne V5 n'est plus alimentee. Si l'operateur ne ferme pas la vanneV1, dans tout les cas, la temperature va augmenter et entrainer une explosion. 5) Modele hno3_v23: On rajoute une panne sur le controleur de pompe. Ca n'a aucun effet sur le comportement du systeme dans le sens ou elle ne doit pas entrainer l'explosion. Car le ComtroleurPannePompe n'a pas de panne et ferme donc V1. On a modelise cette panne de telle sorte que si elle advient, le ComtroleurPannePompe et la vanne V5 sont tout de suite mis au courant. Les possibilites de destructions sont les memes que precedemment (l'operateur fait mal son travail). Conclusion: ----------- Nous n'avons pas eu le temps de modeliser une panne qui entraine des etats dangereux. Un schema qui pourrait en provoquer un, serait la combinaison de la panne du circuit primaire, et du circuit secondaire, et que l'operateur soit parti prendre une biere (panne: Operateur Absent). Ceci aurait pour effet de creer un etat dans le graphe qui inevitablement entraine un boom.