******************** *Le modele hno3_v11* ******************** Le modele hno3_v11 est-il valide? Oui et non, car certaines specifications ne sont pas utilisees, tel que des etats ou transitions. Par exemple, dans le systeme de transitions, pour la vanne V5, la transition "couper", n'est jamais utilisee. Cela a pour effet que l'on atteint jamais les etats "fermeeNonAlimentee" et "ouvertNonAlimentee". Comme ce modele doit etre un systeme sans panne, il semble logique d'enlever la transition "couper" du systeme de transitions. On peut egalement remarquer que dans le systeme de synchronisation, il y a une transition qui est "plusEau" pour "EauPrincipale" et "EauSecondaire", qui n'est pas present dans le systeme de transition. Ce modele est considere sans panne, donc on peut enlever les lignes correspondant a ces transitions. On modifie le calcul portant sur les evenements incontrolables, afin que les resultats soient toujours l'ensemble vide, en faisant: 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; Le modele hno3_v11 est un modele sans panne, donc si tout se passe bien, il ne doit pas y avoir d'explosion. Le seul facteur declencheur d'une explosion, c'est l'operateur. Si l'operateur ne fait pas correctement son travail. Par exemple, s'il ouvre V1 et ferme V5, alors il y a explosion. Donc, l'evenement redoute ER est possible si l'operateur fait non "correctement" son travail Les fichiers sources se situent dans le repertoire Version_11. ******************** *Le modele hno3_v12* ******************** Expliquez la difference entre hno3_v11 et hno3_v12. Contrairement au modele hno3_v11, ou l'operateur pouvait faire ce que bon lui semblait, par exemple ouvrir V1 et fermer V5 sans raison particuliere, le modele hno3_v12 limite les possibilite de l'operateur. Ceci grace a l'indicateur de temperature avec "BIP" et "NotBIP". Lorsque l'indicateur de temperature fais "BIP", l'operateur ferme V1, mais ne peut pas fermer V5, surtout quand "TI" est dans l'etat "TSupSupTc". Ce qui evite une explosion. Le modele hno3_v12 etant considere sans panne, l'evenement redoute ER est impossible si l'operateur fait "correctement" son travail. En supposant que l'operateur suive les instructions "BIP" et "NotBIP" de l'indicateur de temperature, alors tout doit se passer correctement. Par contre s'il ouvre V1 et ferme V5, l'evenement redoute ER se produit. ******************** *Le modele hn03_v21* ******************** Le modele hno3_v21 n'est pas valide car il y a des problemes au niveau des incontrolables. Le modele est modifiable: comme les actions de l'operateur sont controlees par l'indicateur de temperature grace a "BIP" et "notBIP", on considere que les transitions "ouvrirV1", "fermerV1", "ouvrirV5" et "fermerV5" ne sont plus des incontrolables. Il en est de meme pour "inhiberAP" et "activerAP". L'evenement redoute ER est impossible si l'operateur fait "correctement" son travail. Les fichiers sources se trouvent dans le repertoire Version_21. **************** *Ajout de panne* **************** Nous allons maintenant ajouter des pannes au modele hno3_v21. Pour cela, il est necessaire d'ajouter un etat "panne" dans le systeme de transition pour le composant considere 1) Insertion d'une panne dans l'alimentation principale en eau de refroidissement: On change le systeme de transitionn de EauPrincipale : transition_system EauPrincipale < width = 0 >; 0 |- e -> 0, eau -> 0, panne -> 1 ; 1 |- e -> 1, plusEau -> 1; < initial = { 0 } >. On change le systeme de synchronisation en ajoutant la panne qui peut arriver n'importe quand: ( e . e . e . e . e . e . panne . e . e . e . e . e); On change egalement le fichier de validation, en ajoutant: pbPannEauPrincipale := (src_incont1[7] - src(incontrolable1[7])) - dead; Mais bien entendu, lorsque l'alimentation principale en eau de refroidissement tombe en panne, l'alimentation de secours se met en marche. Ce modele est appele hno3_v22. L'evenement redoute ER est impossible si l'operateur fait "correctement" son travail. Car si l'alimentation principale en eau tombe en panne, l'alimentation de secours qui elle ne peut tomber en panne et prend le relais. Seul l'operateur peut amener l'evenement redoute. Les fichiers sources sont dans le repertoire Version_22 2) Insertion d'une panne dans le circuit secondaire : On change le systeme de transitionn de EauSecondaire : transition_system EauSecondaire < width = 0 >; 0 |- e -> 0, eau -> 0, panne -> 1 ; 1 |- e -> 1, plusEau -> 1; < initial = { 0 } >. On change le systeme de synchronisation en ajoutant la panne qui peut arriver n'importe quand: ( e . e . e . e . e . e . e . panne . e . e . e . e); On change egalement le fichier de validation, en ajoutant: pbPannEauSecondaire := (src_incont1[8] - src(incontrolable1[8])) - dead; Si l'alimentation principale en eau tombe en panne et que l'alimentation secondaire fonctionne, alors pas de probleme. Par contre si l'alimentation secondaire tombe en panne a son tour, alors l'evenement redoute peut se produire. Car si l'operateur ne ferme pas "V1" alors la temperature va augmente et on peut aboutir a une explosion. L'evenement redoute ER est impossible si l'operateur fait "correctement" son travail. Ce modele s'appelle hno3_v23 et les fichiers sources sont situes dans le repertoire Version_23.