Nouveau modèle de simulation pour l'évaluation de la ... · PDF filemodule...

20e Congrès de maîtrise des risques et de sûreté de fonctionnement - Saint-Malo 11-13 octobre 2016

METHODE DE CALCUL DE LA DISPONIBILITE DE PRODUCTION DES SYSTEMES PETROLIER MULTI-FLUX

COMPUTATION METHOD OF PRODUCTION AVAILABILITY FOR OIL AND GAS MULTI-FLOW SYSTEMS

Auteurs : Folleau C. et Vinuesa C. Collas S. SATODEV TOTAL S.A. 25 rue Marcel Issartier CSTJF F-33700 Mérignac F-64000 Pau

Résumé Cette communication présente une méthode de modélisation et de simulation de systèmes complexes et multi-flux élaborée. Lasolution développée, fortement connotée Oil & Gas a fortiori, traite aussi bien les comportements fonctionnels et dysfonctionnels des équipements et des systèmes que les contraintes opératoires, logistiques et environnementales. Notre méthode est basée sur la génération automatique de réseaux de Petri stochastiques à prédicats, et l’écriture de formules de propagation de flux. Cette génération est faite à partir d’un bloc diagramme, les résultats sont obtenus via une simulation deMonte Carlo sur le réseau de Petri généré, ce qui permet d’obtenir toutes les informations utiles sur le système.La finalité de ce travail ainsi que celle de l’outil de modélisation associé est de travailler avec rapidité et flexibilité afin deconstituer un outil d’aide à la décision plus efficace aussi bien en phase de conception générale d’un projet qu’en phase d’ingénierie de détail.

Summary This article presents a method for modelling and simulating complex and multi-flow systems. This method is oil and gas related, it handles both functional and dysfunctional behaviours of a system and its logistics support. Our method is based on generationof Petri Nets (PN) with predicates and flow propagation formula. They are automatically generated from a bloc diagram modelling. Results are given thank to a Monte Carlo simulation on the PN, it provides useful information about the system. The objective was to offer a fast, flexible modelling tool (and method) that can provide an efficient decision-making aid forgeneral design and detailed engineering phases of a project.

Introduction

Dans un contexte économique et environnemental toujours plus exigeant, il devient indispensable de proposer des architectures systèmes performantes à coût maitrisé. Pour cela, le concepteur d’un projet pétrolier doit être en mesure d’évaluer rapidement la disponibilité de production des différentes solutions envisagées. Il est essentiel que cette disponibilité tienne compte non seulement des événements planifiés et non planifiés pouvant se produire sur les différents équipements et unités du système que du soutien logistique associé (équipes de maintenance, stock de pièces de rechange, etc.) afin d’être au plus près de la réalité d’exploitation. Plus généralement, les calculs doivent tenir compte de l’environnement opérationnel qui est le plus souvent bien plus pénalisant que les simples opérations de maintenances planifiées et curatives. Dès 2004, la société TOTAL a proposé une extension aux réseaux de Petri (RdP) afin de répondre à cette demande (Signoret et al., 2004) (Dejean et al., 2005). C’est la création d’une nouvelle version de son moteur de calcul par simulation de Monte-Carlo). Cette nouvelle révision propose notamment d’ajouter aux RdP « classiques » la gestion de variables au niveau des assertions et des prédicats avec possibilité d’introduire des formules de calculs avancées. Dès lors, les études de disponibilité de production sont effectuées par des spécialistes en réseaux de Petri. Bien que cette méthode de modélisation soit puissante et flexible, elle comporte malgré tout quelques contraintes :

- elle nécessite un niveau avancé d’expertise en réseaux de Petri stochastiques à prédicats, les modèles sont parconséquent réalisés à distance des équipes projets par des spécialistes, via un ou plusieurs intermédiaires,

- les modèles sont difficilement lisibles et donc invérifiables par les non-initiés,- les modélisations sont coûteuses en temps de réalisation,- les 3 points précédents font qu’il y a un manque de réactivité lors des modifications imprévues sur les projets.

L’enjeu est donc de proposer une solution plus lisible et compréhensible par tous et permettant de raccourcir le délai nécessaire à la prise de décision lorsqu’une nouvelle proposition d’architecture est envisagée. Par la suite, il a été montré (Signoret et al., 2013) (Buvry at al., 2012) qu’une génération automatique de RdP était faisable à partir de blocs diagrammes. Cela a donné naissance aux RBD Driven Petri Net (RBD pour Reliability Block Diagram). Le module bloc-diagramme stochastique créé alors est un outil généraliste, mono-flux, sans gestion de la rétro-propagation et n’est donc pas totalement approprié à la réalisation des études ciblées. Enfin en 2010, une nouvelle extension de langage a été réalisée dans MOCA-RP V13 afin d’exécuter des opérations plus complexes au niveau des tirs des transitions. Ces nouvelles fonctionnalités ouvrent des possibilités qui incitent en 2012 TOTAL et SATODEV à repartir de 0 pour créer un nouvel outil basé sur ce nouveau moteur et proposant une interface « métier ».

Communication 7E-2 /3 page 1/10


Génération des réseaux de Petri correspondant aux composants

En tout premier lieu, l’ensemble des besoins des projets en termes de comportements à modéliser et de résultats souhaités ont été recensés. L’objectif étant de couvrir la majorité des cas de figure qui peuvent être rencontrés lors des études de disponibilité de production, il a fallu identifier un ensemble de fonctionnalités à fournir à l’ingénieur métier en se basant sur les nombreuses études déjà réalisées. TOTAL a capitalisé 25 ans de savoir-faire en modélisation par réseaux de Petri mais automatiser la génération de ces modèles implique des contraintes supplémentaires par rapport à une saisie manuelle. Les besoins en termes de comportements à modéliser ont été identifiés :

- différents modes de défaillance, - gestion des ressources pour les opérations de réparations (pièces de rechange, équipes de maintenances), - planning des opérations de maintenance préventives, - respect de conditions pour effectuer différentes actions (démarrage, maintenance préventive, réparations...), - etc.

Un bloc peut être un composant ou un équipement, ces deux mots signifient la même chose dans cet article.

1. Etats des composants

Un composant peut avoir plusieurs états en fonction ses événements internes ou du reste du système. Par exemple, si un composant s’arrête dans une ligne de production, les composants en série sont mis en stand-by automatiquement. Les différents états sont les suivants (entre parenthèse la valeur de la variable d’état) :

- Work (1) : le composant fonctionne; - By-Pass (2) : une panne s’est produite mais elle n’a un impact sur le système qu’après un certain temps; - Degraded Failure (3) : le composant fonctionne mais dans un état dégradé; - Restart (4) : le composant est en cours de redémarrage; - Stand-By (5) : le composant est à l’arrêt; - Preventive Maintenance (6) : une maintenance préventive rend indisponible le composant; - Critical Failure (7) : panne critique du composant; - Repair (8) : le composant est en réparation ; - SIMOPS (9) : le composant est arrêté pour cause de SIMOPS (voir paragraphe 2.5); - Preservation (10) : après un arrêt prolongé, une période de « préservation » est nécessaire avant le redémarrage; - Hidden Failure (13) : panne cachée qui n’impacte généralement pas la production (tant que le composant n’est pas

réparé). De plus, comme vous pourrez le voir dans le chapitre 3, trois variables sont définies pour chaque bloc pour gérer la propagation des flux. Nk est la capacité nominale, c’est la quantité maximum que le composant peut normalement traiter pendant une unité de temps. Ak est la capacité courante du composant. Pk est la capacité potentielle, celle que pourrait avoir le composant si une condition externe (perte d’une utilité par exemple) ne l’avait pas mis dans l’état Stand-By.

Figure 1. Défaillance d'un composant et changement d’état

Equipment_Work_to_SBdrc 0.0? !Equipment_condition_to_start! Equipment_state=ite(Equipment_Condition_to_SIMOPS,9,5),Equipment_Ak=0

Equipment_SB_to_Workdrc 0.0? Equipment_condition_to_start!{ Equipment_FTS=false;if(Equipment_real_state==1 | Equipment_real_state==5){Equipment_state=ite(Equipment_startUp,4,1);Equipment_real_state=1;Equipment_Ak=Equipment_Nk;} else { if(Equipment_real_state==3){Equipment_state=Equipment_real_state;Equipment_Ak=Equipment_Nk_D;Equipment_Pk=Equipment_Nk_D;}else {}} }! PRIO 500.0

1

Equipment_Failureexp Equipment_tc*Equipment_lambda_C? Equipment_state!=5! _initialisation = true

270

Equipment_Fail

Equipment_Ask_Ressourcesdrc 0.0? Equipment_Condition_to_Repair_C!{ Equipment_priority=(100*Equipment_Repair_Priority)-repair_teams_Team_Ask;repair_teams_Team_Ask=repair_teams_Team_Ask+1;spare_parts_Spare_stock_p=spare_parts_Spare_stock_p-1;spare_parts_Spare_waiting_comp=spare_parts_Spare_waiting_comp+1; }!

282

Equipment_Wait

Equipment_Ressources_Mobilizationdrc 0.0? repair_teams_Team_in>0 & spare_parts_Spare_stock_r>0 & Equipment_Condition_to_Repair_C!{ repair_teams_Team_in=repair_teams_Team_in-1;spare_parts_Spare_stock_r=spare_parts_Spare_stock_r-1;spare_parts_Spare_waiting_comp=spare_parts_Spare_waiting_comp-1;Equipment_SIMOPS_Approach=true; }! PRIO Equipment_priority

289

Equipment_Move

Equipment_End_Repexp Equipment_mu_C? !repair_teams_Team_Stop !{ Equipment_SIMOPS_Intervention=false;Equipment_SIMOPS_Approach=true; }! MEM

Equipment_Approach_to_StartRepdrc Equipment_delay_SIMOPS_Approach!{ if(Equipment_state==7){Equipment_state=8;}Equipment_real_state=8;Equipment_SIMOPS_Approach=false;Equipment_SIMOPS_Intervention=true; }!

312

Equipment_Rep

313

Equipment_Remove

Equipment_Team_Removaldrc Equipment_delay_SIMOPS_Approach!{ Equipment_state=ite(Equipment_Condition_to_SIMOPS,9,5);Equipment_real_state=5;Equipment_Pk=Equipment_Nk;Equipment_SIMOPS_Approach=false;repair_teams_Team_Ask=repair_teams_Team_Ask-1;repair_teams_Team_in=repair_teams_Team_in+1; }!

331

Equipment_Initialisation

Equipment_Initialiseddrc 0.0? !_initialisation_required | !_initialisation!{ Equipment_previous_loss=_loss;_previous_nb_total = _nb_total;if (Equipment_delay_BP>0){Equipment_state=2;}else{Equipment_state=7;Equipment_Ak=0;Equipment_Pk=0;}Equipment_real_state=7; }!

11

Equipment_Work

2

Equipment_StandBy



2. Pannes, réparations et ressources

Pour un composant, différents types de défaillance sont définis. La panne critique provoque une perte complète et immédiate de la capacité du bloc à assurer sa fonction. La panne dégradée est une défaillance qui n’est pas critique mais qui empêche le composant d’avoir une sortie nominale. Une telle défaillance peut engendrer une panne critique avec le temps. Quand le composant subit une panne dégradée, il continue à fonctionner. Une réparation immédiate de cette panne provoquera une perte de production, c’est pourquoi la politique de maintenance préconise d’attendre un moment opportun pour effectuer la réparation des pannes dégradées. Les conditions de réparation sont par exemple l’attente d’arrêt complets ou le bon fonctionnement d’un composant en redondance. Le réseau de Petri de la Figure 1 est utilisé pour définir le processus de pannes/réparations. A chaque tir de transition, un ensemble de variable est modifié en fonction de l’état du composant et des actions qui doivent être déclenchées (appel d’équipe de maintenance, demande de pièce de rechange). La définition exacte de toutes les variables est disponible dans la documentation technique (2016) de l’outil développé. Le jeton reste dans une place jusqu’à ce que les conditions soient remplies. Les conditions sont remplies, quand les conditions définies par l’utilisateur sont vraies et quand les ressources sont disponibles.

Figure 2. Mobilisation d'une équipe de maintenance

La signification des variables de la Figure 2 est la suivante :

- Team_Ask : Nombre de composants ayant besoin d’une équipe. Variables modifiées par les composants, - Team_in_r : Nombre d’équipes mobilisées (arrivées sur site), - Team_in : Nombre d’équipe mobilisée et disponible pour effectuer une réparation, - Team_mob_duration : Durée de la mobilisation, - Nb_Team : Nombre d’équipes gérées par ce RdP, - NB_Fail : Nombre de composants en panne nécessaire pour démarrer la mobilisation de l’équipe.

Le RdP de l’équipe et le RdP du composant s’attendent l’un l’autre en fonction des valeurs des variables. En procédant de cette manière, le RdP ne dépend ni du nombre de composants, ni du nombre de modes de défaillance ni du nombre d’équipe de maintenance. Seules les variables sont modifiées pour traiter les interactions, les retouches aux RdP ne sont donc plus nécessaire en cas de rajout d‘entités (composants ou équipes). La même méthode est utilisée pour les pièces de rechange, vous pouvez le voir avant et après la place “Equipment Wait” sur la Figure1. Ceci est une vue simplifiée d’une équipe, le modèle réel peut gérer les horaires de travail et les conditions d’arrêt. De la même manière le vrai RdP des pièces de rechange gère plusieurs méthodes d’approvisionnement. Chaque RdP est réalisé suivant les préconisations qui ont été définies par (Signoret et al., 2013). Un logiciel peut facilement dupliquer les RdP de chaque composant et défaillance de manière à générer un RdP complet du système avec ses ressources. La taille du RdP du système est linéaire en nombre de composants car la complexité est liée au nombre d’entités en jeu et pas au nombre d’état du système.

3. Défauts de jeunesse

La modélisation des défauts de jeunesse est la prise en compte de la variation du taux de défaillance pendant le début de la vie du composant. Le taux de la transition “Equipment_Failure” (Figure1) est multiplié par un coefficient de jeunesse (Equipment_ tc) qui évolue au cours du temps en fonction des spécifications de l’utilisateur. La réactualisation des délais en cas de modification des paramètres de la transition est faite suivant les méthodes décrites par (Thomas et al., 2016).

4. Maintenance préventive

Les maintenances préventives, en anglais PMI (Preventive Maintenance and Inspection), sont définies dans un échéancier. Elles ne sont possibles que si le composant est dans un des états Work, Degraded Failure, Hidden Failure ou Stand-By. Si un composant est en panne ou en réparation, la PMI est repoussée et effectuée lorsque le composant repasse dans l’état stand-by. Le RdP correspondant est composé d’un enchainement de transitions « Instant Fixé à l’avance » pour le déclenchement de la PMI (partie gauche de la Figure 3) et de transition de loi Dirac correspondant à la durée de la PMI (partie droite de la Figure 3). Le franchissement des transitions de début de maintenance peut être restreint par des conditions afin de préserver la

1

Team_OUTToks = 1

2

Team_INToks = 0

t_OUT_to_INdrc Team_mob_duration? Team_Ask > Team_in_r& Team_in_r < Nb_team& Team_Ask >= Nb_fail!{ Team_in = Team_in+1;Team_in_r = Team_in_r+1; }!

t_IN_to_OUTdrc 0.0? Team_Ask < Team_in_r!{ Team_in = Team_in-1;Team_in_r = Team_in_r-1; }!



production du système puisque la maintenance implique un arrêt du composant. La partie droite est la même quel que soit le nombre de périodes et leur durée, seule la partie de gauche est générée différemment suivant les PMI saisies pour le composant.

Figure 3. RdP Maintenance préventive

5. SIMOPS

Les SIMOPS (pour SIMultaneous OperationS en anglais) signifient que l’intervention sur un composant va impacter le fonctionnement des composants alentours. La figure 3 explique les zones d’approches et d’intervention ainsi que la définition des groupes de composants.

Figure 4. Zone SIMOPS

La variable “condition_to_start” utilisée dans la transition Equipment_SB_to_Work de la Figure 1 est définie de la manière suivante: condition_to_start = user_condition & !condition_to_SIMOPS & condition_on_flows La condition_to_SIMOPS est vrai si au moins un des composants des groupes SIMOPS a positionné sa variable SIMPOS_Approach ou SIMOPS_Intervention à vrai.

6. Stand-By

Dans la méthode proposée ici, les composants ne peuvent pas tomber en panne quand ils sont en Stand-By (à l’arrêt), il est en revanche possible d’ajouter une probabilité de défaillance lors du démarrage du composant. Un composant peut être mis en Stand-By pour plusieurs raisons :

- Un événement spécifique définit par l’utilisateur en fonction des contraintes spécifiques au système - Un évènement externe comme les SIMOPS ou la perte de production en amont ou en aval.

L’arrêt automatique des composant est une amélioration importante par rapport aux méthodes qui suppose un fonctionnement continu des composants (et qui ne peuvent donc pas traiter les problèmes de redémarrage). Dans l’industrie des procédés, un équipement doit s’arrêter s’il n’y a plus de flux à traiter. L’arrêt/redémarrage des composants peut avoir un impact significatif sur la fiabilité du système, c’est particulièrement vrai avec les machines tournantes (pompes, compresseurs, …) qui ont une certaine probabilité de défaillance au démarrage. C’est pourquoi la gestion des flux est un point clef de notre méthode.

Mobilisation

Approche

Intervention

Composants impactés pendant l’approche Composants impactés pendant l’intervention Composants impactés pendant les deux périodes



Gestion des flux

L’objectif de la deuxième étape, qui fut la plus incertaine et la plus complexe, a été de proposer un ensemble de formules permettant de caractériser les flux circulant entre les équipements. S’il est trivial de définir le flux de sortie d’un bloc/équipement comme le minimum entre ce qui entre et ce que le bloc peux traiter, il est en revanche nettement plus délicat de répartir plusieurs flux dans plusieurs branches (ou sous-systèmes) en garantissant la conservation du bilan matière. Pour traiter ce problème a été introduite une notion de « demande » circulant en sens inverse du « flux réel » et qui caractérise ce que les équipements en aval peuvent traiter. Cette demande permet de faire des choix localement au niveau de chaque connecteur. Après de très nombreuses tentatives pour créer ces formules propageant les flux et les demandes, il est apparu évident qu’il était nécessaire, en plus du « Flux Réel » et de la « Demande Réelle », d’introduire la notion de « Flux Potentiel » et de « Demande potentielle » (flux qui pourraient circuler si les composants qui sont en stand-by démarraient).

7. Définition des flux

Pour décrire la propagation des flux de la Figure 5, commençons par la définition des deux premières grandeurs : le flux réel et la demande réelle. Le flux réel K est défini par un vecteur dont la dimension correspond au nombre de flux à traiter (généralement 3, un pour l’huile, un pour l’eau et un pour le gaz). Les valeurs du vecteur représentent le débit (Sm3.h-1 or kbopd par exemple) de chaque flux (Huile, eau, gaz) qui se propage à travers l’équipement. Kout (K à la sortie du composant) est égal au minimum entre Kin (K à l’entrée) et Ak (la capacité courante). Cette capacité change tout au long de la vie du composant, en fonction de ses états (marche, panne, panne dégradée …). Kin d’un composant est égal au Kout du composant qui le précède. De la même manière la demande réelle (Dr) est définie comme un vecteur dont la dimension correspond au nombre de flux. Il représente la capacité courante de la partie avale d’un composant et se propage dans le sens inverse de K. La notion de demande permet de ne pas produire plus que ce que l’aval peut traiter, d’arrêter les composants si l’aval est en panne ou si un composant en redondance suffit à répondre à la demande. Le problème des flux réels est qu’après une défaillance, tous les composants en série s’arrêtent et les flux sont nuls (K et Dr à 0). Ensuite lorsque la réparation est effectuée, les flux restent à 0 puisque les composants sont en stand-by et y restent (car Kin = 0 ou DRin = 0 est une condition de mise en stand-by). Nous sommes dans un cercle vicieux. Pour cette raison, deux flux additionnels ont été introduits : le flux potentiel (P) et la demande potentielle (Dp). Ils représentent les flux qui pourraient se propager dans le composant si le composant était dans l’état Work au lieu de Stand-By. Ainsi, s’il n’y a pas de panne, les flux P et Dp se propagent tous les deux. La condition des démarrages d’un composant est alors définie comme Pin > 0 et Kin>0, il peut donc passer de l’état Stand-By à l’état Work après sa réparation ou celle de ses blocs amonts ou avals. Le cercle vicieux est ainsi brisé. Un autre flux a aussi été défini, c’est le flux nominal (N). Ce flux est indépendant de K ou P puisqu’il ne dépend que de la capacité nominale des composants du système et un indépendant de l’état courant.

8. Composant générique

Comme expliqué précédemment les variables de flux (Kin, Kout, Drin, Drout, …) agissent comme une interface entre le modèle comportemental du composant et le modèle de propagation de flux. Les variables d’entrée peuvent faire changer le composant d’état, en plus des changements d’état intrinsèque au composant comme expliqués dans le chapitre 2. Ces changements d’état modifient les variables Ak et Pk et par conséquent les flux de sortie qui dépendent de ces 2 variables. Pour présenter les calculs effectués pour réévaluer la valeur des flux, voici quelques notations qui simplifieront l’écriture des formules. V et W sont des vecteurs de dimension n, n est le nombre de flux gérés dans le système, S est un scalaire.

𝑆 = 𝑆𝑢𝑚𝑇(𝑉) => 𝑆 = ∑(𝑉[𝑖])

𝑛

𝑖=0

𝑊 = 𝑆𝑢𝑚𝑉(𝑉1, 𝑉2, … , 𝑉𝑚) => 𝑊[𝑖] = 𝑉1[𝑖] + 𝑉2[𝑖] + ⋯ + 𝑉𝑚[𝑖] ∀𝑖 = 1, . . , 𝑛

𝑊 = 𝑃𝑟𝑜𝑑𝑆𝑉(𝑆, 𝑉) => 𝑊[𝑖] = 𝑆 ∗ 𝑉[𝑖] ∀𝑖 = 1, . . , 𝑛

𝑊 = 𝑃𝑟𝑜𝑑𝑉𝑉(𝑉1, 𝑉2, . . . , 𝑉𝑚) => 𝑊[𝑖] = 𝑉1[𝑖] ∗ 𝑉2[𝑖] ∗ … ∗ 𝑉𝑚[𝑖] ∀𝑖 = 1, . . , 𝑛

𝑊 = 0 => 𝑊[𝑖] = 0 ∀𝑖 = 1, . . , 𝑛

ite(A, B ,C) signifie si A alors B sinon C

Figure 5. Flux traversant un bloc

Bloc

Equipement

Kout

: flux réel en sortie P

out : potentiel en sortie

Drin

: demande réelle reçue

Dpin

: demande potentielle reçue N

out : nominal en sortie

flux réel en entrée : K

in

potentiel en entrée : Pin

demande réelle propagée : Dr

out

demande réelle propagée : Dpout

Nominal en entrée : Nin

Condition (Booléen)



Quatre coefficients ont été définis : Coef_K = 𝑖𝑡𝑒(𝑆𝑢𝑚𝑇(𝐾𝑖𝑛) > 0, min (1,

𝐴𝑘

𝑆𝑢𝑚𝑇(𝐾𝑖𝑛)) , 0) Coef_Dr = 𝑖𝑡𝑒(𝑆𝑢𝑚𝑇(𝐷𝑟𝑖𝑛) > 0, min (1,

𝑃𝑘

𝑆𝑢𝑚𝑇(𝐷𝑟𝑖𝑛)) , 0)

Coef_N = 𝑖𝑡𝑒(𝑆𝑢𝑚𝑇(𝑁𝑖𝑛) > 0, min (1,𝑁𝑘

𝑆𝑢𝑚𝑇(𝑁𝑖𝑛)) , 0) Coef_P = 𝑖𝑡𝑒(𝑆𝑢𝑚𝑇(𝑃𝑖𝑛) > 0, min (1,

𝑃𝑘

𝑆𝑢𝑚𝑇(𝑃𝑖𝑛)) , 0)

Pour chaque flux X parmi K P N Dr, le flux à la sortie (Xout) est défini de manière générique en fonction de son coefficient et de Xin : 𝑋𝑜𝑢𝑡 = 𝑖𝑡𝑒(𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛, 𝑃𝑟𝑜𝑑𝑆𝑉(𝐶𝑜𝑒𝑓_𝑋, 𝑋𝑖𝑛), 𝑂) ∀ 𝑋 𝜖 {𝐾, 𝐷, 𝑁, 𝑃} Avec cette approche, les flux se propagent facilement d’un composant à l’autre. Pour des raisons de généricité, les composants ne doivent avoir qu’une entrée et une sortie. Parfois il est nécessaire d’associer des flux (production de plusieurs puits, …) ou de les diviser en plusieurs branches (lors de redondance) ou encore de séparer les flux d’une même branche en plusieurs branches contenant un seul flux (cas des séparateurs Huile Eau Gaz). Trois types de connecteurs ont donc été créés : le convergent, le divergent et le séparateur.

9. Connecteur convergent

L’utilité de ce connecteur est de combiner plusieurs flux d’entrée en un seul flux de sortie. Kout, Pout and Nout sont simplement la somme de (K1,..,Kn), (P1,...,Pn) and (N1,...,Nn) mais la difficulté est de propager la demande réelle de l’aval vers les multiples branches amont dans lesquels se trouvent des systèmes eux aussi composé de connecteurs. La méthode alloue la Dr aux m différentes branches amont en fonction de leur capacité potentielle courante Pi (𝑖 ∈ {1, 𝑚}). Les formules suivantes sont utilisées : 𝑆𝑢𝑚𝑃 = 𝑆𝑢𝑚𝑉(𝑃1, 𝑃2, . . . , 𝑃𝑚)

𝐶𝑜𝑒𝑓𝑓_𝐸𝑖 = 𝑚𝑖𝑛𝑗=1𝑛 {𝑖𝑡𝑒 (𝑃𝑖[𝑗] > 0 &𝑆𝑢𝑚𝑃[𝑗] > 0, 𝑖𝑡𝑒 (

𝐷𝑟𝑖𝑛[𝑗]

𝑆𝑢𝑚𝑃[𝑗]≥ 1,1,

𝐷𝑟𝑖𝑛[𝑗]

𝑆𝑢𝑚𝑃[𝑗]) , 1)}

𝐷𝑟𝑖 = 𝑃𝑟𝑜𝑑𝑉𝑉(𝑃𝑖 , 𝐶𝑜𝑒𝑓𝑓_𝐸𝑖)

La Figure 6 présente la manière dont les flux circulent dans les connecteurs convergents.

Il est aussi possible d’utiliser des variantes sur ce type de connecteur. Quatre variantes sont disponibles.

La première variante est la « logique K sur M », au moins K sur les M branches amont doivent produire/fonctionner pour autoriser une sortie sur la branche aval.

La deuxième est la boucle simple (Figure 7), elle correspond au cas de système de puits sous-marins reliés en boucle. La perte de 2 systèmes implique la perte de ceux qui sont entre ces 2 systèmes.

La troisièmes est la boucle avec nœud spécial (Figure 8), elle a le même comportement que la boucle simple à l’exception d’une branche qui joue un rôle spécifique, si cette branche est perdue toute la production est arrêtée.

Le dernier est le connecteur prioritaire, si l’aval n’est pas capable de traiter toute la production amont, le connecteur va activer les branches amont dans un ordre précis en fonction de la priorité de chaque branche, jusqu’à ce que la capacité de l’aval soit atteinte. Il se peut que seul la première branche soit activée (envoi d’une demande) si elle suffit à combler la demande de l’aval.

Pour toutes ces variantes, le code généré pour calculer les différents flux est bien plus complexe et ne relève pas d’une simple formule. Ces codes ne peuvent être détaillés ici mais sont disponibles dans la documentation technique 2016 de l’outil exploitant cette méthode.

10. Connecteur divergent

Ce connecteur divise une unique entrée en plusieurs branches de sortie, sans changer la proportion de flux. Le pourcentage d’un flux i par rapport à la somme des flux est le même dans la branche amont et les M branches aval. Drout et Dpout sont de simples sommes des entrées. K P et N sont divisés dans les M branches proportionnellement à leur capacité. Les formules suivantes sont utilisées :

Figure 7. Boucle simple

Oil Water Gas

Kout, Pout, Nout

K1, P

1, N

1

Dr1, Dp

1

Drin, Dp

in

Km

, Pm

, Nm

Drm, Dp

m

Figure 6. Flux connecteur convergent Figure 8. Boucle nœud spécial connector



𝑆𝑢𝑚𝐷𝑟 = ∑ 𝐷𝑟𝑖𝑚𝑖=1

𝐶𝑜𝑒𝑓𝑓𝐾𝑖= 𝑖𝑡𝑒(𝑆𝑢𝑚𝐷𝑟 > 0, 𝑃𝑟𝑜𝑑𝑆𝑉 (

𝑆𝑢𝑚𝑇(𝐷𝑟𝑖)

𝑆𝑢𝑚𝐷𝑟, 𝐾𝑖𝑛) , 0)

𝐾𝑚 = 𝑀𝑖𝑛(𝐾𝑖𝑛 − ∑ 𝐾𝑖

𝑚−1

𝑖=1

, 𝐷𝑟𝑚)

𝐾𝑖 = 𝑖𝑡𝑒(𝑆𝑢𝑚𝐷𝑟 > 0, 𝑖𝑡𝑒(𝑆𝑢𝑚𝑇(𝐶𝑜𝑒𝑓𝑓𝐾𝑖)

< 𝑆𝑢𝑚𝑇(𝐷𝑟𝑖), 𝐶𝑜𝑒𝑓𝑓𝐾𝑖, 𝐷𝑟𝑖), 0)

De la même manière que pour le convergent il existe des options possibles sur le connecteur, elles ne seront pas détaillées ici.

11. Connecteur séparateur

Le connecteur séparateur permet de séparer les flux de la branche d’entrée en plusieurs branches. Cette séparation peut être parfaite (toute l’huile dans une branche, tous le gaz dans une autre, …) ou imparfaite (huile et une certain quantité de gaz dans la première, …). La répartition est définie par l’utilisateur grâce à un tableau de séparation (Figure 11). Coef Si représente le coefficient de séparation. Pour chaque colonne, la somme des coefficients doit être égale à 100%. Pour chaque sortie, le flux est calculé en utilisant le coefficient de séparation mais aussi la capacité de la partie aval de chaque branche grâce au Dri et Dpi.

Cas spécifiques

La troisième étape de notre méthode a consisté à identifier et résoudre les cas particuliers d’équipements tels que les réservoirs, les torches et les politiques de redémarrage complet du système. Ces composants spécifiques ne pouvaient pas être modélisés avec le RdP générique qui était généré pour les composants standards.

12. Réservoir

Le réservoir est un équipement souvent utilisé, sa sortie dépend non seulement des flux entrants et de la demande mais aussi du niveau du réservoir. Le RdP contient deux parties, une pour le remplissage, l’autre pour le vidage. Chaque RdP est utilisé alternativement suivant les variations de flux en amont ou en aval du réservoir. Le niveau du réservoir varie de manière discrète sur le même principe que celui défini dans (Chabot et al., 1998). Le RdP qui est trop grand pour tenir dans un article peut être demandé aux auteurs ou récupéré librement dans le répertoire Petro/Models/ de la version de démonstration du logiciel.

13. Ramp-Up

Un bloc Ramp-Up a été créé. Il ne correspond pas à un équipement mais à une politique de redémarrage du système. Cette politique n’est pas liée à un composant, mais si le système subit un arrêt complet trop long, il ne peut pas redémarrer instantanément pour des raisons opérationnelles et de sécurité. Il faut un temps important de redémarrage qui dépend de la durée de l’arrêt. Le bloc Ramp-Up dont le RdP est présenté Figure 12 ajuste la demande envoyée en amont en fonction de la politique définie.

Oil

Water Gas

K1, P1, N1

Dr1, Dp1

Km, Pm, Nm

Drm, Dpm

Kin, Pin, Nin

Drout, Dpout

Figure 9. Flux du connecteur divergent

Oil Water Gas

K1, P1, N1

Dr1, Dp1

K2, P2, N2

Dr2, Dp2

K3, P3, N3

Dr3, Dp3

Kin, Pin, Nin

Drout, Dpout

Figure 10. Flux du connecteur séparateur Figure 11. Coefficients de séparation



Résultat de calcul

Lorsque le RdP global du système est créé, il peut fournir de nombreuses informations sur le système, les composants ou les ressources, soit directement soit via l’ajout d’un RdP additionnel pour répondre à un calcul précis. Les résultats sont obtenus à travers une simulation de Monte Carlo du RdP. Tous les résultats sont fournis avec la valeur moyenne, l’écart type et intervalle de confiance demandé. Les quantiles peuvent aussi être fournis.

14. Production et perte de production

Pour chaque flux i de chaque sortie du système, la disponibilité de production est définie comme la moyenne de la variable 𝐾𝑜𝑢𝑡[𝑖] pendant le temps de mission (ou année par année) divisée par la production nominale du système (s’il n’y avait eu aucune panne). Lorsque la production est calculée, le concepteur du système doit identifier les causes des pertes de production. Deux méthodes ont été implémentées pour répondre à cette question. La première méthode compte le nombre de fois que la défaillance d’un composant est responsable de l’arrêt complet du système. Chaque fois qu’un équipement tombe en panne, son ID est mémorisé dans une table, et chaque fois que le système est arrêté le dernier équipement est considéré comme responsable de la défaillance du système. Cette méthode est une bonne méthode quand on s’intéresse plus à la réduction du nombre d’arrêt (comme une usine de fabrication d’azote liquide) qu’à des quantités de production perdue (par exemple sur une installation pétrolière). La seconde méthode s’intéresse aux quantités perdues. Lorsqu’un composant tombe en panne, la perte de production est obtenue en comparant la production avant et après la mise à jour des variables de flux.

15. Statistique sur les événements intéressants

La simulation de Monte Carlo sur le RdP fournit la fréquence moyenne de tir des transitions et le temps de séjours moyens dans chaque place. Ces informations sont très utiles car elles permettent de connaitre :

- le nombre de défaillances/réparations de chaque mode de défaillance de chaque composant, - le temps passé dans chaque état pour chaque composant, - le nombre de pièces de rechanges utilisées, - le taux d’occupation des équipes de maintenance.

16. Nombre d’arrêt système et temps de remise en service

Le MTTR (Mean Time To Recovery) est une information utile mais pas assez précise pour prendre des décisions sur la conception des systèmes comme ceux étudiés ici. Il faut connaitre la proportion des arrêts qui étaient dans les intervalles ]0h,5h] ]5h,10h] ]10h,15h] etc. ou toutes autres tailles d’intervalles qui présenterait un intérêt opérationnel ou de soutien logistique. Pour cela, pour chaque sortie, un RdP additionnel (Figure 13) est ajouté au RdP final, il vérifie la variable “No_Production”. Grace au tableau “Shutdown[]” dont la taille est égale au nombre d’intervalles souhaitées, il compte le nombre de fois où la durée de l’arrêt était dans tel ou tel intervalle.

Figure 12. Ramp-up PN



Résultat de la méthode

Avant tout, on peut dire qu’un réseau de Petri « générique » a été créé, il est configurable via de nombreux paramètres et peut-être utilisé pour simuler un nombre important de comportements intrinsèques et il propose une « interface » pour interagir avec le reste du système. Certaines de ces interactions sont gérées à travers la propagation de flux qui sont constamment (de manière discrète) réévaluées. Les formules proposées fournissent pour chaque instant de la mission des résultats en accord avec ce qu’on attend du système réelle, le tout en évitant les bouclages et blocages dus aux phases transitoires.

Quand le RdP final est généré, il peut bien entendu être simulé interactivement en mode pas à pas à travers une interface bloc diagramme conviviale afin de ne pas présenter les RdP à l’utilisateur. Cela permet de valider que les composants ont bien été saisis et qu’ils s’intègrent correctement dans la propagation du flux. Cette simulation intègre des indicateurs (les flux circulant à chaque endroit du système en temps-réels) qui sont nécessaires pour prendre des décisions sur les modifications éventuelles du système. Les ingénieurs projets ont maintenant accès à un outil de modélisation avec lequel il peuvent rapidement définir un système de production multi-flux et obtenir toutes les informations dont ils ont besoin.

Les utilisateurs peuvent personnaliser et améliorer la méthode

Afin de ne pas limiter l’utilisateur à un ensemble de scénarios prédéfinis, nous avons défini une interface de communication (par variable) entre le nouvel outil et l’outil de réseaux de Petri habituellement utilisé. Cette solution permet à l’utilisateur de :

- Modifier le RdP générique existant pour l’adapter à une situation non prévue, - Créer son propre RdP pour par exemple définir des composants aux comportements particuliers.

Ces nouveaux modèle s’intégreront parfaitement dans le nouvel outil et interagiront avec le reste du système. L’utilisateur qui serait un expert peut aussi générer le RdP complet du système afin de l’ouvrir dans le module Petri.

Figure 13. Calcul du temps de remise en service

Figure 14. Bloc diagramme avec les productions (gaz en vert in green, huile en rouge, eau en bleu)



Conclusion

A l’heure actuelle, ce nouvel outil est pleinement opérationnel et est utilisé au quotidien par les équipes fiabilistes de TOTAL. De nombreuses évolutions (ergonomies, optimisations,…) sont réalisées ou identifiées dans le but d’améliorer l’expérience de l’utilisateur et de traiter de plus en plus de cas complexes. Parmi ces futures évolutions, il est envisagé de traiter de la composante couts/gains qui est aujourd’hui encore réalisée par l’équipe projet de manière externe. Il n’existe pas de complexité technique à l’intégration des coûts dans nos réseaux de Petri, même si il reste un travail d’organisation à effectuer pour identifier les éléments sur lesquels on souhaite associer ce coût. Ce travail sera certainement effectué dans une version ultérieure de nos outils. Buvry P., Brissaud F., Varela H., 2012, Comparaison de deux outils pour les analyses de disponibilité de production, Lambda-Mu 18. Chabot JL., Hutinet T., Signoret JP., 1998, Simulation hybride méthode de modélisation intégrant phénomènes continus et discrets, Lambda-Mu 11. Dejean JP., Averbuch, D., Gainville, M., Doux, F., 2005, Développement de modèles pour la gestion intégrée des risques pour les systèmes de production pétroliers offshore, Qualita. Documentation technique de GRIF Workshop module Petro. http://team3.satodev.fr/pydio/public/technical-doc-petro Dutuit Y., Signoret, J-P., 2003, Tutorial on dynamic system modelling by using stochastic Petri nets and Monte Carlo simulation. Konbin. Signoret J.P., 1998, Modeling the behavior of complex industrial systems with stochastic Petri nets. ESREL. Signoret, J-P., Boiteau, M., Rauzy, A., Thomas, P., 2004, Disponibilité de production : les outils nouveaux sont arrivés. Lambda-Mu 14, Bourges. Signoret JP, Dutuit Y, Cacheux PJ, Folleau, C., Collas S, Thomas, P., 2013, Make your Petri nets understandable: Reliability block diagrams driven Petri nets. Reliability Engineering and System Safety. Thomas P, Dutuit Y, Signoret JP, 2016, Prise en compte des transitions dynamiques au sein des réseaux de Petri stochastiques, Lambda-Mu 20.


http://team3.satodev.fr/pydio/public/technical-doc-petro

Nouveau modèle de simulation pour l'évaluation de la ... · PDF filemodule...

Documents

Transcript of Nouveau modèle de simulation pour l'évaluation de la ... · PDF filemodule...