NO325673B1

NO325673B1 - Objektorientert simulering av hydrokarbon reservoarsystem

Info

Publication number: NO325673B1
Application number: NO20032811A
Authority: NO
Inventors: Attila Banki; Stephen C Netemeyer
Original assignee: Exxonmobil Upstream Res Co
Priority date: 2000-12-29
Filing date: 2003-06-19
Publication date: 2008-07-07
Also published as: US7761270B2; EP1358619A4; MXPA03005798A; WO2002054332A1; EA200300742A1; DE60131298D1; CN1483181A; CA2430556A1; NO20032811D0; EP1358619B1; ATE377801T1; NO20032811L; EP1358619A1; US20020169589A1

Abstract

Det er beskrevet et datamaskinsystem for simulering av transportfenomener i et komplekst system. Systemet omfatter minnemidler, lagringsmidler og en objektorientert programvare. Programvaren omfatter et objektorientert, utvidbart klassehierarki som inkluderer et første sett generiske klasser som representerer et antall objekttyper og et andre sett generiske klasser som representerer medlemsvariabler for objekttypene. Det utvidbare klassehierarkiet tillater tillegg av ekstra objekttyper eller ekstra medlemsvariable uten noen modifikasjoner av klassehierarkiet selv. I en annen utførelse inneholder datamaskinsystemet også et logisk grensesnitt som tillater en bruker av datamaskinsystemet dynamisk å konstruere logikk for å tilpasse simulering av det fysiske systemet, et middel for å konvertere den konstruerte logikken til tilsvarende objektorientert kode, et middel for å integrere den objektorienterte koden med et hovedsimuleringssystem, samt et middel for kjøring av det integrerte simuleringssystemet.

Description

Oppfinnelsens område

Nærværende oppfinnelse gjelder numerisk simulering, og spesielt en forbedret fremgangsmåte for simulering av et hydrokarbonsystem som kan inkludere ett eller flere av følgende begreper: en underjordisk hydrokarbonførende formasjon, injeksjonsbrønner som gjennomtrenger formasjonen, produksjonsbrønner som gjennomtrenger formasjonen, strømningslinjer i overflaten, assosierte akvifere, samt fasiliteter for prosessering av overflatefluid.

Bakgrunn for oppfinnelsen

Numerisk simulering er i utstrakt bruk på industrielle områder som en måte å simulere et fysisk system ved hjelp av datamaskin. Som regel er det ønskelig å modellere transportprosessene som forekommer i det fysiske systemet. Det som blir transportert er typisk masse, energi, moment eller en kombinasjon av dette. Ved å bruke en numerisk simulering er det mulig å modellere og observere et fysisk system og å fastsette konstruksjonsparametre, uten å gjennomføre laboratorieeksperimenter og feltprøver.

Reservoarsimulering er av stor interesse fordi den avleder hvordan et virkelig hydrokarbonførende reservoar oppfører seg, ut fra hvordan en modell av dette reservoaret virker. Den typiske hensikten med reservoarsimulering er å få en forståelse av de komplekse kjemiske, fysiske og fluidstrømnings-prosessene som forekommer i reservoaret, tilstrekkelig til at man kan forutsi fremtidig virkemåte for reservoaret med rimelig presisjon, slik at hydrokarbonutvinning kan maksimaliseres. Reservoarsimulering gjelder ofte hydrodynamikk i strømninger i reservoaret, men kan i en større sammenhang også gjelde det totale hydrokarbonsystemet som kan omfatte ikke bare reservoaret, men også injiseringsbrønner, produksjonsbrønner, overflatestrømningslinjer, assosierte akvifere samt prosesseringsmidler på overflaten. Reservoarsimulerings-beregninger i slike hydrokarbon-systemer er basert på fluidstrøm gjennom hele hydrokarbonsystemet som simuleres. Disse beregningene blir utført med forskjellig grad av rigorøsitet, avhengig av kravene til vedkommende simuleringsundersøkelse og yteevnen til simuleringsprogramvaren som brukes.

Prinsippet med numerisk simulering er på numerisk måte, ved hjelp av datamaskin, å løse ligninger som beskriver et fysisk fenomen. Slike ligninger er i alminnelighet vanlige differensialligninger og partielle differensialligninger. Kjente midler til å løse slike ligninger numerisk er endelig element-metode, endelig differanse-metode, endelig volum-metode og lignende. Uansett hvilken metode som brukes blir det fysiske systemet som skal modelleres delt i celler (og et sett celler kalles gitter eller nett), og tilstandsvariablene som varierer i rommet gjennom modellen blir representert av verdisett for hver celle. Egenskapene til reservoarbergmassen, slik som porøsitet og permeabilitet antas typisk å være konstant innenfor en celle. Andre variabler, slik som fluidtrykk og fasemetning blir spesifisert på angitte punkter, ofte kalt noder, innenfor cellen. En link mellom to noder kalles en «forbindelse».

Fordi reservoarsimuleringen kan omfatte svært forskjellige fluidstrømningsmiljøer (f.eks. porøst berg, brønnrør-ledning, prosesseringsfasiliteter), kan settet med celler inkludere multiple segmenter med ulike strømningsmiljøer. Selv om de enkelte segmenter, slik som produksjonsfasiliteter og overflaterørsegmenter, kunne bli representert ved enkeltceller, vil reservoarsimulerings-programmer noen ganger dele opp slike segmenter i multiple celler.

Et sett ligninger er utviklet for å uttrykke de grunnleggende prinsippene for konservering av masse, energi og/eller moment innenfor hver celle og for bevegelse av masse, energi og/eller moment fra celle til celle. Det kan være millioner av slike ligninger. Erstatning av tilstandsvariable som varierer romlig i en modell med et endelig antall variabelverdier for hver celle blir kalt «diskretisering». For å kunne analysere et fenomen som endrer seg med tiden er det nødvendig å beregne fysiske størrelser i diskrete tidsintervaller, kalt tidstrinn, uavhengig av de kontinuerlig foranderlige betingelsene som funksjon av tiden. Tidsavhengig modellering av transportprosessene foregår derfor som en rekke tidstrinn. Simuleringen av strømning i løpet av et ønsket tidsrom blir utført ved å bevege seg fremover i tiden i diskrete trinn og å løse ligningene i hvert tidstrinn med hensyn til trykk og fluidinnhold i hver node.

Det er gjort forsøk på å utføre vidt varierende reservoar-simuleringsmetoder i en enkelt datamaskinkode. Slike «generelle» simuleringssystemer er imidlertid meget komplekse, i hovedsak fordi de er konstruert med én eller flere av følgende kapabiliteter:

(1) representere mange ulike celletyper (f.eks. ulike domener i et reservoar, brønnrørledning og fasiliteter for overflatesamling og fordeling, samt overflateprosesseringsfasiliteter), (2) bruke forskjellige beregningsmetoder med tidstrinn (f.eks. IMPES, fullt implisitt, sekvensielt implisitt, adaptivt implisitt, og/eller kaskademetoder), (3) bruke ulike måter å representere reservoarfluider

På,

(4) bruke multiple måter for beregning av transport mellom celler, (5) utføre det som blir kalt en «black-oil model», som behandler hydrokarboner som om de består av to komponenter og har evnen til å utføre representasjoner av sammensetning der hydrokarbonene blir antatt å inneholde sammensetninger som metan, etan, propan og tyngre hydrokarboner, (6) simulere injisering av damp eller in situ forbrenningsprosesser, som må ta hensyn til temperaturendringer som funksjon av tiden som krever energibalanse, samt relaterte beregninger, (7) simulere blandbare gjenopprettingsprosesser med bruk av spesielle fluidegenskaper og

transportberegninger,

(8) simulere gjenopprettingsprosesser for hydrokarbon som tar hensyn til injisering av surfactanter, polymere eller andre kjemikalier og strømningen av disse fluidene inn i reservoaret, (9) simulere injisering av kjemikalier som reagerer innbyrdes, med hydrokarbonene i reservoaret eller med reservoarberget, samt (10) simulere migrering av hydrokarboner og geologisk avsetning gjennom geologisk tid.

Historisk er det slik at fordi generelle

simuleringssystemer er komplekse, modellerer reservoar-simuleringsprogrammer typisk enten fluidbevegelse i undergrunnsreservoaret, eller fluidbevegelse i undergrunnsreservoaret inkludert forenklede beregninger, for eksempel hydraulikkmodeller, for å modellere strømning i brønnrør mellom reservoaret og overflaten. For å oppnå en mer realistisk modell av strømningen gjennom brønnene og i de tilknyttede produksjonsfasilitetene på overflaten (slik som manifolder, pumper, kompressorer, separatorer og rørledninger) har det typisk vært nødvendig med en separat simuleringsmodell for fasiliteter, som er atskilt fra reservoarsimuleringsmodellen. Siden disse modellene for simulering av reservoar og fasiliteter søker å beskrive strømningsforholdene over et langt tidsrom, typisk mange år, og simuleringene blir diskretisert i tidstrinn som dekker det ønskede tidsrommet, er det tungvint og kostbart å forsøke å få til en integrert modelleringsprosess basert på to distinkte modeller. En slik prosess vil vanligvis omfatte alternerende tidstrinn mellom de to modellene, slik at endringene som forekommer i én modell kan medtas i inngangsbetingelsene for neste tidstrinn i den andre modellen.

Ett utfordrende problem ved reservoarsimulering tidligere har vært mangelen på rigorøs modellering av transportfenomener gjennom brønnrør og overflatefasiliteter innen et reservoarsimuleringssystem. Konvensjonelle reservoarsimulatorer har typisk to betydelige begrensninger. For det første krever mange reservoarbehandlingsstudier en mer inngående modell for strømning i overflatefasiliteter enn hva som er mulig i en reservoarsimulator. For å løse dette problemet vil simulatorbrukeren typisk utvikle og vedlikeholde én simuleringsmodell for reservoarvirkemåte og en annen simuleringsmodell for fasilitetsvirkemåte, uten noen praktisk fremgangsmåte for å integrere resultatene fra de to målingene eller for lett å evaluere virkningene av endring i én modell på virkemåten til den andre modellen. For det andre vil reservoarbehandling typisk omfatte dramatiske endringer i brønn- eller fasilitetshastigheter. Fordi fasilitetshastigheter blir brukt som grensebetingelser for reservoarsimuleringsberegninger vil dramatiske endringer i disse grensebetingelsene ofte føre til en numerisk instabilitet i simuleringsberegningene som er vanskelig å håndtere.

Ett utfordrende problem ved reservoarsimulering tidligere har vært mangelen på rigorøs modellering av transportfenomener gjennom brønnrørledninger og overflatefasiliteter innen et reservoarsimuleringssystem. Konvensjonelle reservoarsimulatorer har typisk to betydelige begrensninger. For det første krever mange reservoarbehandlingssystemer en mer sofistikert strømningsmodell for overflatefasiliteter enn hva som er mulig i en reservoarsimulator. For å møte dette problemet vil simulatorbrukeren typisk utvikle og vedlikeholde én simuleringsmodell for reservoaroppførsel og en annen simuleringsmodell for overflatefasilitetsoppførsel, uten noen praktisk måte å samordne resultatene fra de to modellene på eller å greit evaluere virkningene av en endring i den ene modellen på oppførselen av den andre. For det andre vil reservoarbehandling typisk innebære dramatiske endringer i brønn- eller fasilitetshastighet. Fordi fasilitetshastighet brukes som grensebetingelser for reservoarsimulerings-beregninger vil dramatiske endringer i disse grensebetingelsene ofte føre til numeriske ustabiliteter i simuleringsberegningene som er vanskelige å håndtere.

Et annet utfordrende problem i reservoarsimulering er evnen en simulatorbruker har til å spesifisere fasilitetsbehandlingslogikk i simuleringen. For å optimalisere produksjonen av hydrokarboner fra et felt kreves det en kontinuerlig prosess med overvåking og styring av produksjonsfasiliteter og injiseringsfasiliteter i hele levetiden for feltet, hvilken kan strekke seg over 30 år eller mer. En mer nøyaktig prediktering av reservoaret med en reservoarsimulator krever at virkningen av overflate-fasilitetsstyring blir tatt i betraktning under simuleringen. De bestemte styringstiltakene, deres rekkefølge og tidspunkter er det vanskelig om ikke praktisk talt umulig å programmere inn i en simulator, fordi avvikene vil være uten begrensning og avhenge av hvert felt og hver simulatorbrukers måte å behandle feltet på. Simulatorbrukeren trenger derfor et verktøy for å kunne spesifisere for simulatoren de tilpassede kontroller og styreparametre som brukeren tror vil optimalisere produksjonen i reservoaret. Disse kontroller og styreparametre trenger så å bli en integrert del av simulatorberegninger. Kort sagt trengs det et intuitivt verktøy for å oppfange den enkelte simulatorbrukers tilpasning av fasilitetsbehandlingslogikken, omdanne denne til kjørbar kode som er integrert med reservoarsimulatorens kode, og så kjøre det resulterende systemet for å prediktere den samlede virkemåten for reservoaret i løpet av dets levetid.

Den typiske måten å løse dette problemet på har vært å utvikle programvare som gir brukeren et strukturert hjelpemiddel. Simulatorbrukeren får til disposisjon et tekstbasert redigeringsprogram eller et grensesnitt der han eller hun disponerer et sett modeller og et fast sett med nøkkelord. Ved å bruke disse modellene kan

simulatorbrukeren definere potensielle betingelser som, dersom de inntreffer under simuleringen, vil utløse en passende respons som modifiserer virkemåten for brønnene. Denne fremgangsmåten er ikke spesielt intuitiv for brukeren. Prosessen med å sette sammen modeller og nøkkelord kan være langtekkelig, og resultatet er ikke lett å avlese eller interpretere, særlig for personer som ikke har vært involvert i reservoarprosjektet fra begynnelsen. Det finnes ingen tydelig oversikt over logikken, dvs. det er ikke lett å følge resonnementet på høyt nivå bak logikken. Brukeren har begrenset innflytelse på prosessen, og remediene som er disponible for kjøring er begrenset av et endelig sett med kombinasjoner som simulatoren gjenkjenner, hvilket fører til begrenset fleksibilitet hos systemet når det gjelder å inkludere uvanlige strategier for reservoarbehandling.

Det er et behov innen industrien for et reservoarsimuleringssystem som (1) gir en mer realistisk modell av strømning gjennom brønnrør og overflatefasiliteter og (2) som fanger opp en fasilitetsbehandlingslogikk tilpasset til en bruker av reservoarsimulatoren og utfører denne som en del av en reservoarsimulering.

Fra Ferrier, G. og Wadge, G.: "An integrated GIS knowledge-based system as an aid for the geological analysis of sedimentary basins", Int. J. Geographical Information Science, 1997, vol. 11, no. 3, 281-297, er det kjent fremgangsmåter som benytter kunnskapsbaserte system og geografiske informasjonssystem for å analysere opprinnelse og diagenese i sedimentære bekker ved eksempler hentet fra Cheshire Basin i England.

Fra internasjonal patentsøknad WO 99/28767 er det kjent fremgangsmåter og apparatur for å skape, teste og modifisere geologiske underjordiske modeller.

I US patent 6063128 er det beskrevet et objektorientert datasimuleringsprogram for å konstruere en modell av objekter.

Sammenfatning av oppfinnelsen

Oppfinnelsen gjelder en fremgangsmåte og et datamaskinsystem for simulering av transportfenomener i et komplekst system. Datamaskinsystemet omfatter minnemidler, lagringsmidler, samt et objektorientert programvareprodukt. Programvareproduktet omfatter et objektorientert, utvidbart klassehierarki med generiske klasser som representerer et antall objekttyper og særskilte generiske klasser som representerer medlemsvariabler for objekttypene. Det utvidbare klassehierarkiet tillater utvidelse med ekstra objekttyper eller ekstra medlemsvariable uten noen modifikasjoner av klassehierarkiet selv.

Oppfinnelsen er spesielt nyttig for simulering av et reservoarsystem. For bruk av oppfinnelsen for en reservoar-systemmodell er det utviklet en «fasilitets-nettmodell»

(Facility Network Model - FNM) som utvider den diskretiserte reservoarsimuleringsmodellen (som består av noder og strømningsforbindelser) ut over reservoaret slik at den inkluderer noder og forbindelser for modellering av fluidstrømning i brønnrørene og produksjons- og injiseringsfasiliteter på overflaten (slik som manifolder, pumper, kompressorer, innsamlingsledninger, separatorer og rørledninger). Hver enkelt fasilitetstype blir modellert som en spesialisert type node, forbindelse eller sammenstilling av flere noder og forbindelser. I sin mest grunnleggende form kan hele simuleringsmodellen omfatte hver komponent i hydrokarbonfeltet, fra undergrunnsreservoaret, alle brønner og brønnmaskineri, samt overflatefasiliteter til og med produktleveringsuttak(ene).

Reservoarsimuleringssystemet bruker fortrinnsvis fasilitetsbehandlingslogikk (Facility Management Logic - FML) med en reservoarsimulator. FML sørger for en oversikt over logikken som er lett å bruke for brukeren av simuleringsmetoden. Bruk av FML er fleksibel og lar seg integrere med en reservoarsimulator. FML omfatter tre elementer: (1) et logikkskjema-grensesnitt, (2) en generator for C++-kode (industristandard programmeringsspråk) fra logikkskjemaet, samt (3) en spesifikk programvarekonstruksjon for å integrere koden med selve reservoarsimulatoren.

Omfanget av oppfinnelsen er definert i de etterfølgende patentkrav.

Kort beskrivelse av tegningsfigurene

Det nye reservoarsimuleringssystemet og dets fordeler vil bli bedre forstått ved hjelp av følgende detaljbeskrivelse og de vedlagte tegningsfigurene.

Figur 1 viser en diskretisert reservoarsimuleringsmodell og dens tilordnede nettverk av brønner og

overflatefasiliteter.

Figur 2 og 3 illustrerer et generisk C++ klassehierarki som viser en fasilitetsnettmodell. Figur 3 er en del av klassehierarkiet vist på figur 2. Figur 4 illustrerer et enkelt fasilitetsnettverk som en grafisk representasjon av ikoner og piler merket med navnet på fasiliteten hver enkelt representerer. Figur 5 illustrerer et logikkskjema som viser en forenklet fasilitetsbehandlingslogikk. Figur 6 viser et skjema av en liten del av et eksempel på simulator-klassehierarki. Figur 7, som er en utvidelse av skjemaet på figur 6, illustrerer hvordan dynamisk spesialisering brukes til å støtte brukerskrevne operasjoner.

Tegningene er ikke ment å ekskludere fra omfanget av det nye reservoarsimuleringssystemet andre utførelser som er resultatet av normale og ventede modifiseringer av disse spesifikke utførelsene.

Detaljert beskrivelse

Et datamaskinsystem som har minnemidler, lagringsmidler og et objektorientert programvareprodukt i henhold til nærværende oppfinnelse kan brukes ved simulering av komplekse systemer slik som to— og tredimensjonale domener av hydrokarbonsystemet som blir diskretisert i strukturerte matriser, ustrukturerte matriser eller en kombinasjon av begge. Datamaskinsystemet kan også brukes i situasjoner der beregningsløsningen fører til en topologi som har mer enn tre dimensjoner, slik det forekommer ved simulering av fluidstrømning gjennom frakturerte porøse medier. Simuleringssystemet er nyttig til simulering av en karakteristikk i et komplekst system der det forekommer et transportfenomen. Betegnelsen «transportfenomen» brukes i denne beskrivelsen i vid betydning og omfatter momentumtransport (viskøs strømning), energitransport (varmeledning, konveksjon og stråling), samt massetransport (diffusjon). Eksempelvis er simuleringssystemet spesielt nyttig til simulering av fjerning av hydrokarboner fra reservoarberg ved bruk av forskjellige gjenvinningsteknikker slik som, men ikke begrenset til, termisk baserte gjenvinningsmetoder slik som dampoversvømmingsoperasjoner, vannoversvømmingsoperasjoner og gass-drivbaserte metoder som kan virke under enten blandbare eller ikke-blandbare betingelser. Simuleringssystemet kan også brukes til å modellere transport av kontaminanter gjennom underjordiske formasjoner. I denne beskrivelsen vil simuleringssystemet bli beskrevet når det gjelder utførelse av en generell reservoarsimulering på ustrukturerte gittersystemer, hvilket er spesielt nyttig for parallell beregning ved simulering av hydrokarbonførende systemer som kan inkludere ikke bare reservoaret men også assosierte akvifere, produksjonsbrønner, injeksjonsbrønner, overflate-strømningslinjer, manifolder, separatorer, ventiler, pumper, kompressorer eller hvilken som helst annen overflateprosesserings- eller transportmidler.

I forbindelse med den detaljerte beskrivelsen av nærværende oppfinnelse skal noen termer defineres for å klargjøre betydningen av dem. En «reservoarsimuleringsmodell» er en bestemt matematisk representasjon av et virkelig hydrokarbonreservoar. En ingeniør som behandler et hydrokarbonreservoar kan opprette mange forskjellige reservoarsimuleringsmodeller, eventuelt med varierende grad av kompleksitet, for å kvantifisere reservoarets tidligere prestasjoner og forutsi fremtidig ytelse. I nærværende oppfinnelse er en reservoarsimuleringsmodell en diskretisert representasjon av reservoarets fysiske rom og brønner og overflatefasiliteter som brukes for utvinning av hydrokarbonfluider. En «fasilitet» slik uttrykket er brukt i nærværende beskrivelse, er en representasjon av et konkret stykke fysisk utstyr som tjener til å produsere hydrokarbonfluider fra et reservoar eller injisere slike i et reservoar. I videste betydning brukes termen fasilitet om hvilket som helst utstyr som måtte finnes langs strømningsveien mellom et reservoar og leveringsuttakene, nemlig de stedene der hydrokarbonfluider enten forlater modellen (produserte fluider) eller entrer modellen (injiserte fluider). Fasiliteter kan omfatte produksjonsbrønner, injiseringsbrønner, brønnrør, brønnhodeutstyr, innsamlingsrørledninger, manifolder, pumper, kompressorer, separatorer, overflaterørledninger og leveringsuttak. I noen tilfeller er termen

«overflatefasilitet» brukt for å skille slike fasiliteter fra brønner. Et «fasilitetsnettverk» er hele samlingen av fasiliteter som finnes i modellen, hvilket vil inkludere alle brønner samt overflatefasilitetene mellom brønnhodene og leveringsuttakene.

En reservoarsimuleringsmodell som omfatter et tredimensjonalt hydrokarbonførende reservoar og dets tilhørende fasiliteter er illustrert på figur 1. Reservoarsimuleringsmodellen som er vist skjematisk på figur 1 består av et diskretisert reservoar 100, gjennomtrengt av brønner 106a, 108a og 110a, anvist med stiplede streker, og inneholder ekstra fasilitetsnoder 102, 103 og 104 og fasilitetsforbindelser 112, 114, 116, 118 og 120. På figur 1 er reservoaret 100 vist å omfatte et antall volumetriske celler 101, anvist ved tynne streker. Selv om det ikke uttrykkelig er vist på figur 1, representerer hver celle 101 et tredimensjonalt romvolum som inneholder en node i sitt senter. Ikke uttrykkelig vist er også at hvert nabopar av reservoarnoder har en forbindelse mellom seg. I reservoarsimuleringsmodellen strømmer hydrokarbonfluid gjennom en forbindelse mellom et nodepar basert på trykkdifferansen mellom nodene og transportegenskapene for forbindelsen. Hydrokarbonfluider kan dermed bli transportert fra en volumetrisk celle til en volumetrisk nabocelle. Hver brønn 106a, 108a og 110a inneholder en node hver, henholdsvis 106b, 108b og 110b. Heller ikke eksplisitt vist på figur 1 er hver node tilknyttet via en forbindelse til hver av reservoarnodene som den tilhørende brønnens bane passerer gjennom. Fasilitetsnodene 103 og 104 og fasilitetsforbindelsene 112, 114, 116, 118 og 120 representerer et innsamlingsnettverk av strømningsveier som fører fluid frembrakt fra reservoar 100 inn i brønner 106a, 108a og 110a til et felles uttakspunkt 102.

Objektorientert programmering

Implementering av nærværende oppfinnelse bruker objektorientert programmering (Object Oriented Programming - OOP). De mest kjente programmeringsspråkene for OOP er Simula, Eiffel, C++, Smalltalk, Objective-C eller varianter av disse. Imidlertid er utførelsen av nærværende oppfinnelse ikke begrenset til et bestemt OOP-språk. C++ blir brukt i denne detaljbeskrivelsen for å hjelpe leseren til en bedre forståelse av og verdsettelse av fordelene ved OOP. Konstruksjon av OOP er velkjent for fagpersoner innen OOP-systemer og vil her bare bli generelt beskrevet.

I et objektorientert program er fokus primært på data og sekundært på funksjonene som berører dataene, fremfor å være primært på funksjoner og sekundært på dataene de krever. I motsetning til et program som beskrives hovedsakelig ved prosedyrer med data inn til og ut fra hver prosedyre (slik som et program skrevet i FORTRAN eller COBOL), er et objektorientert program organisert omkring «objekter». Et objekt er en datastruktur og et sett operasjoner eller funksjoner som har tilgang til datastrukturen. OOP-systemer vil typisk inneholde et stort antall objekter. Hver operasjon (funksjon) som har tilgang til datastrukturen blir kalt en «metode». Når det gjelder nærværende oppfinnelse blir dataene som et objekt inneholder kalt «medlemsvariable» og metodene som et objekt har blir kalt «medlemsfunksjoner». Et objekt kan betraktes som en smart samling av data, fordi objektets medlemsfunksjoner gir objektet evnen til å endre seg selv, dvs. å endre verdien i sine medlemsvariable.

En «klasse» er en mal for en bestemt type objekt. Klassen definerer informasjonen som er tilknyttet objektet (dets data) og operasjonene det kan utføre (dets metoder). Når et objekt blir opprettet, blir det brukt en klasse som en mal for å definere hvilke data og metoder objektet har. Et objekt sies å være en «forekomst» av klassen som definerer det. Det kan finnes mange distinkte objekter, alle forekomster av samme klasse, men hver forekomst har sine egne data og metoder.

En typisk objektorientert programkonstruksjon inneholder som sin kjerne en gruppe klasser, som samlet kan betegnes som en «datamodell». En gitt klasse i en datamodell definerer én spesifikk type «objekt» som kan inneholde data («medlemsvariable») og metoder («medlemsfunksjoner»). Datamodellen er en hoveddel av «arkitekturen» til den objektorienterte programvaren. Arkitekturen til et objektorientert programvareprodukt omfatter hele konstruksjonen av programvaren, inkludert datamodellen den er bygget rundt.

OOP tillater objekter å modellere praktisk talt en hvilken som helst entitet i den virkelige verden i form av sine karakteristika, representert av data, og av sin virkemåte, representert av de metodene den kan utføre med disse data. På denne måten kan objekter modellere konkrete ting som celler i en reservoarsimulering og abstrakte begreper som tall. Når det gjelder nærværende oppfinnelse, følger fordelene ved OOP av tre grunnprinsipper: innkapsling, arv og polymorfisme.

Objekter skjuler, eller innkapsler, den interne strukturen til sine data, dvs. den eksplisitte samlingen av medlemsvariable som et objekt inneholder og de algoritmer dets medlemsfunksjoner virker ved. I stedet for å eksponere disse implementeringsdetaljene, fremviser objekter grensesnitt som representerer deres utledninger tydelig, uten utenomliggende informasjon. Grensesnittet tillater bare et begrenset antall interaksjoner mellom verden utenfor og et objekt. I C++-programmering innebærer de fleste slike interaksjoner påkalling av medlemsfunksjoner hos objektet. Ved å påkalle et objekts medlemsfunksjoner kan utenverdenen beordre objektet til å gjøre et eller annet, men detaljene om hvordan objektet utfører denne handlingen er ikke synlig for utenverdenen.

Eksempel: En objektorientert datamodell for et programvaresystem som beregner nodeegenskaper kan ha en klasse kalt «BaseNode». Klassen BaseNode kan ha medlemsvariabler som «x_location», «y_location» og «z_location» som innehar numeriske verdier som definerer posisjonen i rommet for et objekt BaseNode, og medlemsfunksjoner for å endre verdien av koordinatverdiene x, y eller z i objektet BaseNode. Et programvaresystem bygget på datamodellen i dette eksempelet kunne inneholde kode for å opprette og modifisere et antall distinkte BaseNode-objekter. Hvert BaseNode-objekt inneholder sine egne unike verdier av medlemsvariablene, og hvert har de innbygde medlemsfunksjonene til å modifisere disse medlemsvariablene. Sett fra programvaresystemet spiller det ingen rolle om hvordan et BaseNode-objekt vedlikeholder sin lokaliseringsinformasjon. Programvaresystemet trenger bare BaseNode-medlemsfunksjoner for å innsette og hente disse dataene. Denne organiseringen av data (medlemsvariable) og kode (medlemsfunksjoner) i klasser kalles innkapsling. Nedarving tillater at programvareutviklere kan konstruere datamodellen i form av et «klassehierarki», slik at relaterte klasser etterligner den naturlige klassifiseringen av objekttyper. De tre hovedfordelene ved nedarving er at den tillater programvareutviklere å konstruere kode som innkapsler data på en effektiv måte, den tillater implementering av metoder på en spesifikk klasse, slik at disse metodene kan brukes til objekter av mange spesialiserte typer, og den fremmer gjenbruk av allerede eksisterende konstruksjon og kode. I et klassehierarki tilhører generelle data og metoder en «base»-klasse eller «superklasse». Mer spesialiserte klasser («subklasser») «arver» baseklassens data og metoder og definerer i tillegg egne data og metoder. Disse spesialiserte klassene blir «avledet» fra baseklassen. Nedarving tillater en programvareutvikler å definere klasser og de objektene som senere blir dannet av disse og relatert gjennom klassehierarkiet. Spesifikt kan klasser bli betegnet som subklasser under andre baseklasser. En subklasse arver og har tilgang til alle funksjonene i dens baseklasser som om slike funksjoner forekom i subklassen. Nedarving tillater utvidelse av tidligere skrevet kode ved å opprette nye superklasser og subklasser av objekter. Nye objekter blir beskrevet etter hvordan de skiller seg fra tidligere eksisterende objekter, slik at det ikke er nødvendig å skrive helt nye programmer for å behandler nye typer av data eller funksjoner.

Som et eksempel på et klassehierarki som illustrerer nedarving og viderefører foregående eksempel, kan det tenkes en andre klasse kalt «WellNode» som kan arve fra BaseNode-klassen. Et WellNode-objekt er både en WellNode og en BaseNode, men klassen WellNode kan definere data og kode som er spesiell for en WellNode. Dersom det defineres en tredje klasse «NetworkNode», som også arver fra BaseNode, men ikke fra WellNode, vil et NetworkNode-objekt ikke inneholde data og kode som er spesiell for WellNode. Imidlertid vil både et WellNode-objekt og et NetworkNode-objekt inneholde BaseNode-spesifikk data og kode. Dette enkle eksempelet viser bare en BaseNode-klasse med ett nivå av ekstra spesialisering (klassene WellNode og NetworkNode). Imidlertid tillater nedarving et vilkårlig antall spesialiseringslag, slik at klassen WellNode kan ha ytterligere subklasser og klassen BaseNode kan ha ytterligere superklasser.

Polymorfisme bringer innkapsling et trinn videre. En programvarekomponent kan gjøre en forespørsel hos en annen komponent uten å vite nøyaktig hva denne komponenten er. Komponenten som mottar forespørselen interpreterer denne og fastslår ut fra dens variable og data hvordan den skal utføre forespørselen. Med det enkle klassehierarkiet beskrevet ovenfor som eksempel, vil en programvarekomponent påkalle en medlemsfunksjon i et BaseNode-objekt. Programvarekomponenten trenger ikke vite om BaseNode-objektet i virkeligheten er et WellNode-objekt eller et NetworkNode-objekt. Klassehierarkiet muliggjør imidlertid at WellNode-objektet og NetworkNode-objektet kan inneholde ulike implementeringer av den påkalte medlemsfunksjonen. Hver klasse i hierarkiet kan inneholde samme abstrakte grensesnitt for medlemsfunksjonen, men de kan ha forskjellig funksjonalitet, alt etter den spesifikke objekttypen som utfører medlemsfunksjonen.

Fasilitets-nettverksmodell

Reservoarsimuleringssystemet i henhold til nærværende oppfinnelse inkluderer en fasilitetsnettverksmodell (Facility Network Model - FNM). FNM er konstruert for å minimalisere behovet for kodeendringer og rekompilering. Dette blir oppnådd ved å definere generiske klasser i klassehierarkiet FNM C++. Et representativt generisk C++-klassehierarki er vist på figurene 2 og 3. Hver rute på figur 2 (nummerert 200 til og med 218) representerer en C++-klasse. Heltrukne streker mellom klasser med en åpen trekant i den ene enden angir nedarvingsforhold mellom klasser, med baseklassen i samme ende som trekanten, og den avledede klassen i den andre enden. Stiplede streker mellom to klasser representerer assosieringer mellom objekter i disse to klassene. Teksten som merker en stiplet strek angir navnet på assosiasjonen, og nummermerkelappene på de to endene av hver assosiasjon angir kardinaliteten til assosiasjonen. Assosiasjonen «node_is_child_of» 220 for eksempel, har en merkelapp «1» ved node-enden og «0..<*>» ved forbindelses-enden. Disse merkelappene angir at hvert forbindelsesobjekt har nøyaktig 1 node som er denne forbindelsens barn (Child), og hvert nodeobjekt har null-eller-mange forbindelsesobjekter som node-objektet er et barn av. Hver generisk klasse inneholder bare det minimale settet av medlemsvariabler og medlemsfunksjoner for å definere generisk virkemåte for alle objekter av vedkommende klasse.

En generisk nodeklasse (node 203 på figur 2) er for eksempel den mest spesialiserte klassetypen i klassehierarkiet for alle fasilitetstyper som er modellert av en viss spesialisering av en node, enten denne noden representerer en plassering inne i en brønn, overflatestrømningsvei, en separator eller en annen fasilitet som kan representeres av en node. Separate generiske klasser blir brukt for å definere benevnte «attributter» for spesialiserte fasilitetstyper (se AttributeValue 211 og dens avledede klasser 212 og 213). Ved å bruke generiske fasilitetstype-klasser (200 til og med 205) og generiske navngitte attributtklasser (207 til og med 213) vil stort sett all spesifisert virkemåte for ønskede fasilitetstyper kunne defineres i en «definisjonsdatafil» (heretter kalt «DDF»). Vedlegg 6, på slutten av denne beskrivelsen, gir et eksempel på en slik fil. Hovedfunksjonen ved å bruke generiske fasilitetsklasser og generiske attributtklasser tillater at FNM kan være fleksibel og utvidbar, slik at nye fasilitetstyper eller nye attributter kan tilføres ved tillegg til eller modifiseringer av innholdet i DDF. Ved denne egenskapen unngås tillegg til eller endringer av klassene i datamodellen, som ville kreve betydelige modifiseringer i kildekoden og rekompilering av modifisert kode.

FNM-datamodellen fortsetter på figur 3, som viser en rekke klasser som holder rede på fasilitetstypene og attributtypene som er definert i DDF.

DDF inneholder tekstbeskrivelser for hver mulig fasilitetstype, slik som «WellNode», «NetworkNode», «SeparatorNode», «Well» og «NetworkConnection». Den inneholder også tekstbeskrivelser for hver av de spesialiserte benevnte attributtene for disse fasilitetstypene. Når DDF blir prosessert av programvaren, danner den et objekt «FacilityTypeSystemAttributes» (303) for hver spesialisert fasilitettype i DDF, og et objekt «AttributeDefinition» (304) for hver benevnt attributt i DDF. Et objekt «FacilityTypeSystemAttributes» arver fra baseklassene VarBase 300, VariablesAttributesBase 301 og FacilityType 302. Assosiasjonen facility_ has system_ attributes (305) relaterer et spesifikt objekt FacilityTypeSystemAttributes (definisjonen for en bestemt fasilitetstype) til alle objektene AttributeDefinition (definisjonen for en bestemt benevnt attributt) for vedkommende fasilitetstype. Etter at DDF er fullstendig prosessert, inneholder reservoarsimuleringssystemet objekter som definerer de mulige fasilitetstyper (samlingen av objekter FacilityTypeSystemAttributes 303) og attributter (samlingen av objekter AttributeDefinition 304) som hver av disse fasilitetstypene må ha. Definisjonen av tilgjengelige fasilitetstyper og benevnte attributter forblir konstant i programvaren inntil DDF blir modifisert og prosessert på nytt, noe som typisk vil forekomme bare når det er behov for nye fasilitetstyper eller attributter. Reservoarsimuleringssystemet med bruk av nærværende oppfinnelse inkluderer et grafisk brukergrensesnitt (Graphic User Interface - GUI) for definering av nettet av fasiliteter («Fasilitetsnettverk») som er en del av en gitt simuleringsmodell. GUI viser fasilitetsnettverket som en samling ikoner som er knyttet til hverandre via forbindelsespiler.

Figur 4 viser dette grafisk brukergrensesnittet for et enkelt fasilitetsnettverk. Ulike ikoner kan brukes til å representere distinkte fasilitetstyper (brønner, separatorer, nettverkskoblinger), og forbindelsespilene representerer strømningslinjer mellom de «nodelignende» fasilitetene. På figur 4 angir hver tekstrute (med «b»-subskript 401b t.o.m. 410b navnet på en fasilitet vist som ikoner eller piler (med «a»-subskript 401a t.o.m. 410a). Eksempel-fasilitetsnettverket på figur 4 inneholder tre brønner 406a, 408a, 410a og overflatestrømningsnettverket som disse brønnene er tilknyttet. Overflatenettet inneholder NetworkNodes 403a og 404a, TerminalNode 401a, NetworkConnections 405a 407a og 409a, samt TerminalConnection 402a. Brønnene 406a og 408a leverer væske som går til NetworkNode 404a via NetworkConnections 405a og 407a. Væske fra Well 410a flyter sammen med produksjonen fra de andre to brønnene i NetworkNode 403a. Fra NetworkNode 403a fortsetter væskene til leveringsuttaket TerminalNode401a.

FNM GUI har tilpassede dialoger, menyer og verktøylinjer slik at brukeren kan konstruere og modifisere et Fasilitetsnettverk på relativt enkel måte. Når en bruker legger inn en spesiell fasilitet i Fasilitetsnettet for å utføre en reservoarsimulering, vil reservoarsimuleringssystemet bruke det riktige objektet FacilityTypeSystemAttribute 303 (gitt fasilitetstypen som brukeren legger inn) til å lokalisere settet med objekter AttributeDefinition (304) som leverer systemet den informasjonen det trenger for å danne det virkelige fasilitetsobjektet (202, 203, 204 eller 205) og alle dets systemdefinerte attributtobjekter (212).

Støtte til tilpasset fasilitetsbehandlingslogikk

Den generiske C++-datamodellen for FNM muliggjør det komplementære tilpassede fasilitetsbehandlingssystemet (Custom Facility Management Logic System - FML) beskrevet nedenfor. FML-systemet er konstruert for overvåking og styring av operasjonen av fasiliteter innenfor en kjørende simuleringsmodell for å optimalisere produksjonen av hydrokarboner gjennom feltets levetid. FML virker på fasilitetsobjekter under en simuleringskjøring som er dannet av og er analog til FNM-datamodellobjektene. For å maksimalisere tilpasningsmulighetene for FML, inkluderer FNM-datamodellen brukerdefinerte benevnte attributter (klasse UserAttributeValue, 213, figur 2). En bruker kan opprette ekstra benevnte attributter for hvilken som helst av de tilgjengelige fasilitetstypene (utover dem som er definert av brukere i DDF) og så bruke disse tilpassede benevnte attributtene i deres tilpassede FML. Definisjonen på en brukerdefinert benevnt attributt blir lagret som et AttributeDefinition-objekt (218, figur 2), og blir assosiert med et FacilityTypeUserAttributes-objekt (217, figur 2) som svarer til den fasilitetstypen som attributtet er blitt definert for.

FNM kan brukes med hvilket som helst passende objektorienterte programspråk. Datamodellkonstruksjonen som inkluderer generiske fasilitetstyper, generiske benevnte attributter og brukerdefinerte attributter, er ikke begrenset til implementering i C++. FNM vil imidlertid fortrinnsvis bruke samme objektorienterte programspråk som brukes i reservoarsimuleringsprogrammet, for å muliggjøre kompatibilitet med de andre komponentene i

reservoarsimulatoren.

Ny måte å bruke et OOP-klassehierarki på

Når det gjelder datamaskinsystemet i nærværende oppfinnelse, er det tatt i bruk en ny løsning for å skille mye av medlemsvariablene fra objektene de tilhører. Klassehierarkiet omfatter to subhierarkiklasser, ett subhierarki som inneholder klasser som definerer et antall «fasilitetstyper», der det andre subhierarkiet definerer et antall «attributtverdier». Disse to subhierarkier refererer hverandre via deres respektive baseklasser - klassen med basetypen av fasilitetstype (FacBase, 200 på figur 2) har en assosiasjon eller referanse til basen som benevnes attributtverdiklasse (Value, 207 på figur 2) via klassen ValueUse (206 på figur 2). På det nåværende trinnet vil et fasilitetsobjekt referere mange forskjellige attributtverdiobjekter. Hvert attributtverdiobjekt inneholder en spesialisert enhet med data som hjelper til med å definere karakteristika for fasilitetsobjektet. Konseptuelt blir fasiliteten definert av en samling av assosierte objekter - fasilitetsobjektet selv samt alle dets assosierte attributtverdiobjekter. Denne klassearkitekturen følger ikke strengt den konvensjonelle OOP-praksisen med innkapsling, fordi en fasilitets data ikke er fullstendig inneholdt i ett enkelt objekt. Attributtverdiobjektene er imidlertid innkapslet fordi tilgangen til dem fortsatt er besørget via metoder i fasilitetsobjektet.

En annen unik karakteristisk egenskap ved

datamaskinsystemet i henhold til nærværende oppfinnelse er at både fasilitetstypeklassene og attributtverdiklassene er «generiske». Nærmere bestemt betyr dette at de mest spesialiserte klassene i hver av de to tidligere beskrevne subhierarkiene er i stand til å representere mange forskjellige, mer spesialiserte fasilitetstyper, og mange forskjellige attributtverdier. Én type spesialisert fasilitetsklasse for eksempel, er Node (203, figur 2). Denne klassen er generisk, fordi Node-objekter kan momentanvelges til å representere en rekke ulike nodefasilitetstyper, selv om klassehierarkiet ikke har en særskilt spesialisert nodeklasse for hver

nodefasilitetstype. Likedan er SystemAttributeValue (212, figur 2) en generisk attributtklasse, fordi SystemAttributeValue-objekter kan momentanvelges til å

representere en rekke ulike attributtyper, slik som skalarer med flytende komma, heltallsskalarer, strenger, listede typer, matriser med flytende komma, samt heltallsmatriser.

En hovedfordel ved klassehierarkiet som inneholder generiske klasser med fasilitetstyper og attributtverdier, er at samlingen av fasilitetstyper og attributtverdier som støttes i programsystemet lar seg modifisere (ved å definere ekstra fasilitetstyper og attributtverdier eller fjerne eksisterende slike) uten å endre klassehierarkiet, hvorved behovet unngås for rekompilering av kildekode for å ivareta endringer i fasilitetstyper eller attributtverdier. Med nærværende system er det slik at en ren tekstfil, for eksempel en ASCII-fil, som kan kalles en

«Datadefinisjonsfil», inneholder tekstinnslag som definerer hver fasilitetstype og alle attributtverdier for hver fasilitetstype. Denne Datadefinisjonsfilen blir prosessert av et program for å opprette definisjoner innen programvaresystemet. En Fasilitetstypedefinisjon er et objekt av klassen FacilityType (302, figur 3). En attributtverdidefinisjon er et objekt av klassen AttributeDefinition (305, figur 3). Når en bruker arbeider med systemet for å skape en simuleringsmodell, blir definisjonsobjektene brukt av programvaren når som helst brukeren måtte trenge å opprette en forekomst av en fasilitet samt de medfølgende attributtverdiforekomster. FNM i henhold til nærværende oppfinnelse løser tre utfordrende problemer som møter utviklerne av komplekse simuleringsmodeller av hydrokarbonførende

undergrunnsreservoarer og tilhørende

produksjonsfasiliteter:

1. Integrering av beregning av væskestrømmer i fasilitet og reservoar, noe som tidligere krevde modeller for hver som var tilstrekkelig like til å ta høyde for en enhetlig fremgangsmåte for løsning. 2. Modellen for beregning av fasilitets-væskestrømmer i henhold til nærværende oppfinnelse er fleksibel og lar seg lett utvide slik at virkemåten for eksisterende fasilitetstyper kan utvides, eller ekstra fasilitetstyper kan legges til med relativt små endringer i programvaren. 3. Fasilitetsmodellarkitekturen støtter et system med tilpasset fasilitetsbehandlingslogikk, hvilket er ønskelig for dynamisk å kunne styre virkemåten av fasiliteter under en simuleringskjøring.

Fasilitetsbehandlingslogikk

Fasilitetsbehandlingslogikk («FML») er et

programmeringssystem som er konstruert for driftsmessig styring av et fysisk system, slik som brønner og tilhørende overflatefasiliteter innenfor et

reservoarsimuleringssystem. FML omfatter tre elementer: (1) et logisk grensesnitt, heri kalt «Logikkskjema», (2) en generator for C++-kode (et industristandard programmeringsspråk) ut fra logikkskjemaet, og (3) en spesiell programvarekonstruksjon som integrerer FML-koden med selve reservoarsimulatoren.

Logikkskjema

Logikkskjemaet omfatter et grafisk brukergrensesnitt som en simulatorbruker kan bruke for dynamisk konstruksjon av et flytskjema for fasilitetsbehandlingslogikken, og derved sette brukeren i stand til å tilpasse simulering av det fysiske systemet som simuleres. Evnen til dynamisk å konstruere logikk henspiller på en brukers evne til å konstruere logikk etter behov for å løse fasilitetsbehandlingsproblemer. Logikk kan konstrueres av brukeren ved hjelp av det logiske grensesnittet. Det logiske grensesnittet kan brukes til å utføre i det minste ett trinn blant følgende: utvikling av ny logikk, valg og bruk av eksisterende logikk som enten brukeren eller en annen person har konstruert tidligere, kanskje for et annet fasilitetsbehandlingsproblem, valg og modifisering av eksisterende logikk. Flytskjemaet omfatter ikoner som representere grunnleggende logiske styringsblokker og piler som angir progresjonen av logikk fra ett ikon til et annet. Startpunktet for et Logikkskjema består av et Startikon (som representerer inngangspunktet til logikk), et Sluttikon (som representerer utgangspunktet fra logikken) samt en enkelt pil mellom disse to. Piler har én retning og representerer sekvensen ikonene blir evaluert i. Brukerens oppgave er å tenke gjennom den ønskede logikken og å modellere denne logikken ved å bygge opp et representativt flytskjema. All logikk kan være i ett høynivådiagram, eller kan brytes ned i multiple diagrammer som hver utgjør en logisk modul. Hver logiske modul kalles en Operasjon. Hovedoperasjonen «MainOperation» er Operasjonen på høyest nivå. Et forenklet eksempel på slik logikk er vist på figur 5.

Figur 5 illustrerer i diagramform ett eksempel på et forenklet Logikkskjema som viser en enkel

fasilitetsbehandlingslogikk. Denne logikken bruker tre ikontyper (tre Prosess-ikoner 512, 520 og 526, to Logikktest-ikoner, 516 og 522, samt én Sløyfe-ikon 514). I løpet av utførelsen av reservoarsimulering blir denne logikken kjørt gjentagne ganger med regelmessige mellomrom, hver gang med kontroll og styring av produksjonsbrønner. Nærmere bestemt finnes det en sløyfe over

produksjonsbrønner (Sløyfe-ikon 514) som itererer over alle medlemmer av settet «produsenter». I hoveddelen av sløyfen (ikoner 516, 520, 522, 526, 528, 530 og pilene som forbinder disse ikonene innbyrdes og til Sløyfe-ikonet 514) blir vannhastigheten i en bestemt produksjonsbrønn i settet «produsenter» kontrollert to ganger (ved Logikktest-ikoner 516 og 522). Dersom vannhastigheten er over 4000 fat per døgn ved Logikktest-ikon 516, blir brønnen gjennomgått i et forsøk på å redusere vannproduksjonen. Dersom vannhastigheten er over 5000 fat per døgn ved Logikktest-ikon 522, blir brønnen stengt (Prosess-ikon 526).

Tre typer ikon danner byggeklossene for flytskjemaet. Et Prosess-ikon brukes til å representere ligninger eller kall på operasjoner som påvirker fasiliteter for å endre deres tilstand på en eller annen måte (for eksempel for å åpne eller lukke en brønn). Et Prosess-ikon representerer utførelse av en setning, og har alltid en enkelt innoverrettet pil og en enkelt utoverrettet pil, som indikasjon på at det bare finnes en kjørevei gjennom Prosess-ikonet. Et Logikktest-ikon brukes til avgjørelser i flytskjemaet. Et Logikktest-ikon inneholder en brukerspesifisert uttrykk som utregnes til Sann (Ja) eller Usann (Nei). Et Logikktest-ikon har to utgående piler, én som følges dersom uttrykket er Sant (på figur 5 pil 518 for Logikktest-ikon 516 og pil 524 for Logikktest-ikon 522), og en annen dersom uttrykket er Usant (på figur 5, pil 519 for Logikktest-ikon 516 og pil 525 for Logikktest-ikon 522). Et «logisk testkonstrukt» omfatter Logisk Test-ikonet og all logikk langs logikkgranene Ja og Nei opp til endemerket på det logiske testkonstruktet (ikon 528 for Logisk Test-ikon 522 og ikon 530 for Logisk Test-ikon 516). Et Sløyfe-ikon brukes for sløyfing gjennom logikk, for eksempel når logikk må evalueres gjentatte ganger innenfor flytskjemaet. Sløyfe-ikonet inneholder logikken som styrer hvilken type sløyfing som vil skje (på figur 5 er Sløyfe-ikon 514 en sløyfe gjennom medlemmene i et sett). Et «Sløyfe-konstrukt» består av Sløyfe-ikonet og alle logikkikoner mellom Sløyfe-ikonets begynn-pil (515) og neste pil (531). Fasilitetsbehandlingslogikken er ofte av iterativ natur, og Sløyfe-ikon og sløyfekonstrukt er midlene som støtter dette konseptet.

FML-brukeren bygger opp et flytskjema for en ønsket anvendelse i en simuleringsmodell ved å peke og klikke i et passende grafisk grensesnitt (et logikkskjema) med en muspeker. Ved hjelp av flytskjemaet vist på GUI bestemmer brukeren hvilke av disse tre ikontypene som nå trengs, og brukeren aktiverer så en av tre verktøylinjeknapper ved å klikke på ønsket knapp. Dernest flytter brukeren markøren til en eksisterende pil på flytskjemaet som representerer innsettingspunktet for neste ikon. Når brukeren velger pilen ved å klikke på den, setter systemet inn ikonet og behandler oppretting og tilknytning av eksisterende og nye piler.

Simulatorbrukerens neste oppgave er å utfylle det innsatte ikonet med informasjon om akkurat hva ikonet skal gjøre. Dersom det er et Logikktest-ikon, for eksempel, definerer brukeren uttrykket som utgjør basis for sant/usant-testen. Er det et Sløyfe-ikon, kreves det informasjon for å spesifisere basis for itereringen og hvor mange ganger itereringen skal utføres. For et Prosess-ikon kan brukeren måtte skrive en ligning eller spesifisere detaljer om hvordan en operasjon skal påkalles. For hver av disse oppgavene kan brukeren enten skrive inn informasjon, eller kan gjøre bruk av en rekke kontekstfølsomme menyer og dialoger som veileder brukeren gjennom mange av de trinnene som trengs for å bygge opp innholdet i et ikon.

En bestemt syntaks er foretrukket for måten informasjonen blir spesifisert på i hvert ikon. Syntaksen kan være definert av et FML-spesifikt format kalt Facility Management Control Language (fasilitetsbehandlings-styringsspråk). Mye av syntaksdetaljene blir håndtert automatisk når menyene og dialogene blir brukt. Dersom brukeren skriver informasjonen til hvert ikon direkte, er det brukerens ansvar å følge syntaksreglene. Dersom brukeren foretrekker ikke å arbeide med det grafiske Logikkskjemaet, kan han eller hun alternativt arbeide utelukkende i et grensesnitt med tekstbasert logikkode (kalt Text Mode View - tekstmodusbetraktning), der brukeren kan legge inn hele Facility Management Control Language direkte som tekst, uten de visuelle hjelpemidlene som finnes i FML Logic Diagram View (ikoner, piler, menyer eller dialoger). Når en bruker først er begynt å arbeide i Text Mode View, kan han eller hun ikke gå tilbake til Logikkskjemaet som svarer til den logikken de spesifiserer. Vedlegg 1 på slutten av denne beskrivelsen inneholder en tekst fra en Tekstmodus-betraktning av logikken gjengitt i form av flytskjema på figur 5. Teksten i vedlegg 1 er i samsvar med syntaksen til Facility Management Control Language. FML vil automatisk generere denne Tekstmodus-betraktningen når først brukeren har lagt inn logikken ved hjelp av flytskjemabetraktningen. Brukeren trenger ikke å se eller arbeide med denne betraktningen dersom han eller hun ikke ønsker det. På den annen side kan noen brukere velge å legge inn all logikken direkte i en Tekstmodus-betraktning, eller de kan foretrekke å redigere, derunder legge inn, modifisere eller slette logikk når den først er i denne formen. Dersom de gjør dette, er Logikkskjema-betraktningen ikke lenger tilgjengelig for dette settet med logikk. Så lenge brukeren oppretter eller redigerer logikk bare med bruk av Logikkskjema-betraktningen, kan brukeren veksle frem og tilbake mellom de to betraktningene.

Generering av C++-kode

På det stadium da logikken er komplett og brukeren er klar til å begynne simuleringen, må systemet først omgjøre Fasilitetsbehandlings-styringsspråket til C++-kode, slik at det kan kjøres i simulatoren. Dersom Logikkskjemaet ble brukt, omgjør systemet først flytskjemaet til Fasilitetsbehandlings-styringsspråk. Konvertering av logisk kode til objektorientert kode kan utføres ved hjelp av hvilket som helst passende konverteringsmiddel. Dette er et automatisk trinn, skjult for brukeren. Dersom Tekstmodus ble brukt, blir Fasilitetsbehandlings-styringsspråket, som allerede er i betraktningen, brukt.

Systemet begynner så en prosess for å syntaksanalysere Fasilitetsbehandlings-styringsspråket for å validere syntaksen. Etter hvert som syntaksanalysen skrider frem blir syntaktisk korrekt og fullstendige stykker av Fasilitetsbehandlings-styringsspråket som representerer logikken automatisk konvertert til ANSI standard objektorientert C++-kode. Dersom det finnes syntaksfeil, blir disse rapportert. Finnes ingen feil, blir det komplette settet med C++-kode skrevet til en fil sammen med andre simuleringsdata.

Vedlegg 2 t.o.m. 5, som finnes på slutten av denne beskrivelsen, fremstiller C++-koden som er generert for eksempel-logikken på figur 5 og i vedlegg 1.

I vedlegg 2 blir de globale variable pekerne som refererer til hver fasilitet i nettet erklært og initialisert. Listen varierer basert på antall og type av fasiliteter i nettverket, samt fasilitetenes navn spesifisert av brukeren. Pekerne skal være grensesnittklasser, beskrevet i senere avsnitt og på figurene 6 og 7.

I vedlegg 3 blir alle de globale fasilitetspekerne vist i vedlegg 2 initialisert til å peke på de aktuelle fasilitetsobjektene i simulatoren.

I vedlegg 4 påkaller simulatoren ved hvert tidstrinn funksjonen som er kalt wm_initialize(). Dette sikrer at de globale fasilitetspekerne henviser til simulatorobjektene (ved å kalle wm_initialize_globals() i vedlegg 3), og simulatoren kaller så den aktuelle fasilitetsbehandlingslogikken. De resterende deklarasjonene viser ett eksempel på dynamisk spesialisering, der klassen SimWmWelllnterface er spesialisert som klassen Functor() blir erklært utelukkende for det formål å definere en metode brukt til å danne et sett produksjonsbrønner. Dynamisk spesialisering blir gjennomgått med henvisning til figur 6, nærmere beskrevet senere i denne spesifikasjonen.

Vedlegg 5 lister C++-koden for

fasilitetsbehandlingslogikken vist på figur 5 og i vedlegg 1.

Når hovedsimulatoren blir dannet, ekstraherer den C++-kode fra innfilen og legger koden inn i en fil for kompilering. Hovedsimulatoren starter C++-kompilatoren som tilhører plattformen simulatoren vil kjøre på, og kompilatoren omdanner så koden til en objektfil. C++-linkeren blir så startet, for å danne et dynamisk linkbibliotek (på NT) eller et delt bibliotek (på UNIX). Simulatoren laster så biblioteket, som forberedelse til kjøring av koden. På det punktet da hovedsimulatoren har lastet biblioteket blir det integrerte simuleringssystemet dannet som omfatter hovedsimulatoren og den tilpassede logikken.

På det riktige punktet mens det integrerte

simuleringssystemet kjører, kaller simulatoren C++-koden som svarer til MainOperation, hvilken som tidligere beskrevet enten inneholder all

fasilitetsbehandlingslogikken eller som kaller andre Operasjoner som inneholder moduler med logikk. I begge fall blir all logikken kjørt, og etter fullføring returnerer koden styringen tilbake til simulatoren. Simulatoren fortsetter så med sine beregninger, som sannsynligvis blir påvirket av måten logikken kan ha endret tilstanden til fasilitetene. Simulatoren fortsetter så å «gå fremover» i tiden og estimere virkemåten for reservoaret. Med jevne mellomrom under denne progresjonen blir samme fasilitetsbehandlingslogikk kjørt, slik at virkemåten for feltet blir kontinuerlig utvirket gjennom sin simulerte levetid. Simulatorbrukere kan så vurdere resultatene og eventuelt raffinere fasilitetsbehandlingslogikken eller inndataene til simulatoren. Til slutt, når resultatene er akseptable, kan fasilitetsbehandlingslogikken utgjøre grunnlaget for den aktuelle fasilitetsbehandlings-strategien som skal brukes i det aktuelle reservoaret.

Integrering med Reservoarsimulator

For at logikken skal kunne påvirke tilstanden i fasilitetene som simulatoren bruker, er det ikke tilstrekkelig at simulatoren kjører logikken. Logikken, eller nærmere bestemt den objektorienterte C++-koden som er generert fra logikken, er integrert med hovedsimulatorens datamodell. Kombinasjonen av hovedsimuleringssystemet og den objektorienterte C++-koden som er integrert med hovedsimulatorens datamodell benevnes kollektivt som det integrerte simuleringssystemet. For å integrere den objektorienterte C++-koden med datamodellen, og for å gjøre prosessen med effektiv blir det gjort bruk av objektorienterte datamodelleringsteknikker, særlig multippel nedarving og polymorfisme, samt dynamisk spesialisering. Den foretrukne måten å bruke objektorienterte teknikker på vil nå bli beskrevet.

Multippel nedarving og polymorfisme

For å kunne kompilere og lenke C++-koden og integrere den med simulatoren må C++-koden være informert om forskjellige sider ved simulatorens data og metoder. Dette oppnås ved å «inkludere» filer som inneholder beskrivelser av dataene og metodene. Disse filene kalles hovedfiler (header files). Disse hovedfilene blir fortrinnsvis levert sammen med simulatoren, slik at kompilering og linking lar seg gjennomføre. Etter hvert som flere hovedfiler blir inkludert i C+h—koden, vil prosessen med kompilering og linking gå langsommere. For å forbedre virkemåten er det å foretrekke å redusere antallet hovedfiler og deres data. Multippel nedarving og polymorfisme brukes fortrinnsvis for å oppnå dette.

En rekke tomme «grensesnitt»-objekter blir dannet og representerer de simulatorobjektene som virkelig inneholder data og metoder. Denne fremgangsmåten er skissert på figur 6.

Figur 6 illustrerer skjematisk en liten del av simulatordatamodellen. Den stiplede skrå streken 608 deler klasser på «grensesnittsiden» fra klassene på «simulatorsiden». Heltrukne streker med åpne triangler i den ene enden angir nedarvingsrelasjoner, med baseklassen ved triangelenden av relasjonen og den avledede klassen ved den motsatte enden. Grensesnittklassene 600 og 602 til venstre for den stiplede streken 608 er stort sett tomme.

De inneholder ingen medlemsvariable og bare tomme medlemsfunksjonsdeklarasjoner («rent virtuelle» operasjoner 1 en C++-implementering av datamodellen). Grensesnittklassen Welllnterface 602 inneholder de tomme operasjonene «shut_in» og «open». Simulatorsideversjonen av Well (606) har medlemsvariablene for et Well-objekt og den reelle implementeringen for medlemsfunksjonene «shut_in» og «open». Multippel nedarving tillater bruk og deklarering av grensesnittklassene. Simulatorsidens Well-klasse 606 arver både fra grensesnittklassen Welllnterface 602 via nedarvingspilen 609, og fra simulatorklassens Objekt 604 via nedarvingspilen 610. Klassen Welllnterface 602 er en spesialisering av Objectlnterface 600. Simulatorsidens baseklasse Object 604 arver fra klassen Objectlnterface 600 via nedarvingspilen 611. Polymorfisme tillater at den tomme grensesnittoperasjonen «open» kan kalles på grensesnittklassen Welllnterface 602 og deretter å kjøre den reelle operasjonen «open» på den virkelige simulatorklassen Well 606. Dette samme paradigmet brukes til å representere hver simulatorfasilitetsklasse med en tilsvarende grensesnittklasse.

Bare grensesnittobjektene trengs for å kunne kompilere og linke logikken. Fordi kompilatoren ser bare de enkle grensesnittklassene, vil kompleksitet og rettighetsbeskyttet informasjon forbli skjult for kompilatoren og fra hvem som helst som måtte se på filene. Fasilitetsbehandlings-styringsspråket som er vist i vedlegg 2 inneholder bare pekere til grensesnittobjekter, ikke pekere til simulatorobjekter. Fordi grensesnittobjektene er tomme, er kompilerings-/linkingsprosessen hurtig, og detaljer om settet med data og metoder som simulatoren krever, blir ikke avslørt (for eksempel overfor den som eventuelt måtte skanne datamaskinens harddisk etter filer). Multippel nedarving tillater grensesnittklassene å være relatert til simulatorklassene, og polymorfisme tillater at reelle metoder kan påkalles indirekte ved å bruke tomme metoder deklarert på grensesnittklassene.

Dynamisk spesialisering

Hver logikkoperasjon som er utviklet av en simulatorbruker er knyttet enten til fasilitetsnettverket generelt eller til en bestemt fasilitet. Valget gjøres av brukeren ut fra arten av logikk. For at disse operasjonene skal være kjørbare innenfor rammen av simulatordatamodellen som allerede er beskrevet, må Operasjonene bli til metoder av klasser. Siden C++ ikke tillater tillegg av metoder til eksisterende klasser uten rekompilering av simulatoren (eller av betydelige deler av denne), må metodene legges til nye klasser som bare logikkoden kjenner til. Dette fører til konstruksjonen der under kjøring nye klasser blir spesialisert fra de eksisterende grensesnittklassene. Denne fremgangsmåten er vist skjematisk på figur 7.

Figur 7, som utvider diagrammet på figur 6, illustrerer hvordan dynamisk spesialisering brukes for å støtte brukerskrevne operasjoner. Den diagonale stiplede streken 710 skiller grensesnittklassene 700, 702 og 704 fra simulatorklassene 706 og 708. Her har brukeren skrevet en ny operasjon kalt «special_well_logic» for fasiliteter av typen Well. For å støtte deklareringen av nye operasjoner blir grensesnittklassene automatisk spesialisert ved kjøring ved hjelp av klassedeklarasjoner som er skrevet av syntaksanalysatoren for Fasilitetsbehandlings-styringsspråk-til-C++ (derav betegnelsen «dynamisk spesialisering»). I dette eksempelet er klassen «Welllnterface_Dser» 704 dannet av syntaksanalysatoren, og den inneholder deklarasjonene til og koden som utgjør den nye logikkoperasjonen. Derfor kan både de innbygde operasjonene (fra Welllnterface 702 og Objectlnterface 700) og brukeroperasjonene (fra Welllnterface_User 704) kalles fasiliteter av type Well.

Datamodellen er utvidet, men bare for logikkoden. Resten av simulatoren er ukjent med denne utvidelsen, så fra simulatorens synspunkt er datamodellen ikke forandret, og simulatorkoden trenger derfor ikke å kompileres for å bruke den brukerdefinerte logikken. Imidlertid er logikken klar over de nye klassene og erkjenner de nye operasjonene. Fra et brukerperspektiv blir innbygde operasjoner som simulatoren kjenner til og tilpassede operasjoner som simulatoren er ukjent med, påkalt på nøyaktig samme måte. Dessuten har de nye operasjonene, som tilhører klasser som er avledet fra grensesnittklassene, tilgang til de samme innbygde operasjonene og dataene som grensesnittklassene har. Resultatet er en tilsynelatende helstøpt integrering mellom simulatorkode og tilpasset kode.

FML-systemet kan integreres av personer som er kjent innen feltet, med en reservoarsimulator som bruker objektorientert konstruksjon, fortrinnsvis kodet med C++. Forutsetningen for FML-systemet er at det må integreres ved hjelp av en simulator som har en objektorientert konstruksj on.

Det er de objektorienterte prinsippene som støtter konseptet med multippel nedarving, polymorfisme og klassespesialisering, hvilket er nødvendig for helstøpt å integrere FML med en simulator. FML kan brukes med en simulator som blir implementert ved hjelp av et annet objektorientert språk enn C++. Annen teknikker for objektorientert programmering («OOP») kunne brukes, inkludert men ikke utelukkende Simula, Eiffel, Smalltalk, Objektiv-C eller varianter av disse. Bruken av FML er ikke begrenset til et bestemt OOP-språk.

Dersom et annen OOP-system enn C++ blir brukt, må trinnet med C++-kodegenerering revideres slik at det genererer det alternative OOP-språket, noe som medfører at simulatoren også vil måtte ha en objektorientert datamodell.

Reservoarsimuleringsmodellen som har en FML-arkitektur tillater brukeren å utvikle tilpasset

fasilitetsbehandlingslogikk for simulering av praktisk talt hvilken som helst strategi. Slik sett er varianter av logikk praktisk talt uendelige.

Fleksibel og utvidbar datamodellkonstruksjon

Reservoarsimuleringssystemet bruker fortrinnsvis også objektorienterte egenskaper ved C++ til å ta hånd om problemet med utvidbarhet. Programvarekonstruksjonen bruker fortrinnsvis en samling av C++-klasser (kollektivt kalt en «datamodell») til å definere objekter med foreskrevne data (medlemsvariable) og virkemåte (medlemsfunksjoner). Medlemsvariable og medlemsfunksjoner er fast-kodet, dvs. de er definert innenfor klassene selv, dvs. at de lager utvidelser av klassene, for eksempel vil nye medlemsvariable, nye medlemsfunksjoner, nye klasser kreve kodeendringer og omkompilering.

I et typisk OOP-klassehierarki er alle medlemsvariable for en gitt klasse innkapslet i denne klassen. Objekter som er forekomster av denne klassen vil derfor beskytte og styre tilgang til sine medlemsvariable via sine åpne grensesnitt, som er medlemsfunksjonene.

Prinsippet ved det nye reservoarsimuleringssystemet og den beste måten som er uttenkt for å anvende dette prinsippet, er blitt beskrevet. Det vil være åpenbart for fagpersoner at forskjellige endringer kan gjøres med utførelsene som er beskrevet ovenfor, uten å avvike fra ånd og omfang av dette simuleringssystemet slik det er beskrevet ovenfor. Det presiseres derfor at nærværende oppfinnelse ikke er begrenset til de spesifikke detaljene som er vist og beskrevet.

Vedlegg 6

This excerpt from the Data Definitions File illustrates the hierarchical nature of facility type definitions and named attribute definitions. The facility types included in this excerpt demonstrate the base facility type levels needed to define the end-user facility type "NetworkNode." The excerpt includes the definitions for three named attributes that a NetworkNode would have. Two of the named attributes are defined at the FacObject level and the third is defined at the Node level.

Claims

1. Fremgangsmåte for simulering av transportfenomener i et fasilitetsnettverk ved hjelp av et datamaskinsystem med minnemidler, lagringsmidler, samt objektorientert programvare, karakterisert ved(a) bygging av en modell som omfatter et fasilitetsnettverk, hvor fasilitetsnettverket anvender et klassehierarki med et første sett generiske klasser som representerer en rekke objekttyper og et andre sett generiske klasser som representerer medlemsvariabler for objekttypene, idet klassehierarkiet tillater addisjon av ytterligere objekttyper og ytterligere medlemsvariabler uten noen modifikasjon av selve klassehierarkiet, (b) spesifisering av verdier for medlemsvariablene for hver fasilitet, samt (c) bruk av de spesifiserte verdiene av medlemsvariable i en matematisk simulering av transportfenomener innen fasilitetsnettverket som funksjon av tiden.

2. Fremgangsmåte i henhold til krav 1, idet fasilitetsnettet er en del av en større simuleringsmodell, der nevnte fasilitetsnettverk er i stand til å uveksle fluider med minst én annen del av simuleringsmodellen.

3. Fremgangsmåte i henhold til krav 2, idet simuleringsmodellen omfatter et fasilitetsnettverk og en hydrokarbonførende formasjon.

4. Fremgangsmåte i henhold til krav 1, hvor fremgangsmåten er en fremgangsmåte for simulering av transportfenomener i et fysisk system som omfatter et hydrokarbonførende reservoar som er gjennomtrengt av et antall brønner og overflatefasiliteter, forbundet med brønnene, idet fremgangsmåten videre omfatter følgende: a. kvantifisering av det fysiske systemet i et antall volumetriske celler, der hver volumetrisk celle er modellert som en node, og der nabonodene er i stand til å utveksle fluid gjennom forbindelser mellom nodene, b. bruk av fasilitetsobjekter og medlemsvariable objekter av klassehierarkiet i henhold til krav 1 til å modellere nodene og forbindelsen i den delen av den kvantifiserte modellen som representerer brønnene og overflatefasilitetene, c. spesifisering av geometriske fasiliteter og transportfasiliteter for hver node og forbindelse, d. spesifisering av initialbetingelsene for hver node og forbindelse, samt e. simulering som funksjon av tiden transportfenomenene i det kvantifiserte systemet.

5. Fremgangsmåte i henhold til krav 1, der fremgangsmåten er en fremgangsmåte for simulering av et fysisk system i et datamaskinsystem som omfatter minnemidler, lagringsmidler og objektorientert programvare i et hovedsimuleringssystem, idet fremgangsmåten omfatter følgende trinn: a) dynamisk konstruksjon av logikk for å tilpasse simuleringen av det fysiske systemet, b) initiering av simulering av det fysiske systemet, hvilket fører til initiering av følgende trinn: i) automatisk konvertering av logikken til tilsvarende objektorientert kode, ii) integrering av den objektorienterte koden med hovedsimuleringssystemet som omfatter en simuleringsdatamodell og simuleringsalgoritmer, hvilket fører til et integrert simuleringssystem for å simulere det fysiske systemet, samt iii) kjøring av det integrerte simuleringssystemet for å simulere det fysiske systemet.

6. Fremgangsmåte i henhold til krav 5, idet det fysiske systemet omfatter en underjordisk hydrokarbonførende formasjon.

7. Fremgangsmåte i henhold til krav 6, idet det fysiske systemet omfatter fasiliteter som inneholder fluider i tilknytning til produksjon av hydrokarboner fra den underjordiske hydrokarbonførende formasjonen.

8. Fremgangsmåte i henhold til krav 5, idet konstruksjonen av logikken omfatter bruk av et grafisk brukergrensesnitt for å utføre minst ett trinn valgt blant følgende: a) valg og bruk av eksisterende logikk, b) valg og modifisering av eksisterende logikk, samt c) utvikling av ny logikk.

9. Fremgangsmåte i henhold til krav 8, idet konstruksjonen av logikken frembringer et logisk flytskjema.

10. Fremgangsmåte i henhold til krav 8, idet konstruksjonen av logikken frembringer en tekstbasert logikkode.

11. Fremgangsmåte i henhold til krav 9, idet konstruksjonen av det logiske flytskjemaet omfatter bruk av ett eller flere ikoner, piler, dialoger, verktøylinjeknap-per og tekst for å tillate at en bruker av datamaskinsystemet kan bygge opp, redigere og visualisere fasilitetsbehandlingslogikk i form av et flytskjema.

12. Fremgangsmåte i henhold til krav 9, idet konstruksjonen av det logiske flytskjemaet omfatter bruk av tekstbasert logisk kodegrensesnitt som omfatter et grafisk tekstbehandlingsprogram som kan brukes til å legge inn, modifisere og slette linjer med alfanumerisk tekst.

13. Fremgangsmåte i henhold til krav 5, idet konverteringen av logikkoden er konvertering til C++-kode.

14. Fremgangsmåte i henhold til krav 5, idet den konverterte objektorienterte koden har evnen til å utvide simuleringsdatamodellen ved å opprette nye klasser som arver fra simuleringsdatamodellen, slik at det tillater objektorientert kode å kalle funksjoner i simuleringsdatamodellen og bruke medlemsdata fra simuleringsdatamodellen .

15. Fremgangsmåte i henhold til krav 5, idet kjøring av det initierte simuleringssystemet genererer resultater for å prediktere den samlede virkemåten av det fysiske systemet.

16. Fremgangsmåte i henhold til krav 5, idet kjøring av det initierte simuleringssystemet blir utført ved bruk av et antall sammenkoblede prosessorer.

17. Datamaskinsystem for simulering av transportfenomener i hydrokarbonreservoarer omfattende minnemidler, lagringsmidler, samt et objektorientert programvareprodukt, karakterisert ved at programvareproduktet kan opereres til å bygge en modell som omfatter et fasilitetsnettverk, hvor fasilitetsnettverket anvender et objektorientert utvidbart klassehierarki for lagring av simuleringsdata for transportfenomener, idet klassehierarkiet omfatter et første sett generiske klasser som representerer en rekke objekttyper og et andre sett generiske klasser som representerer medlemsvariabler for objekttypene, idet det utvidbare klassehierarkiet tillater addisjon av ytterligere objekttyper og ytterligere medlemsvariabler uten noen modifikasjon av selve klassehierarkiet, hvor verdier for medlemsvariablene for hver fasilitet kan spesifiseres, samt programvareproduktet kan opereres til å bruke spesifiserte verdier av medlemsvariable i en matematisk simulering av transportfenomener innen fasilitetsnettverket som funksjon av tiden.

18. Datamaskinsystem i henhold til krav 17, idet transportfenomenene omfatter ett eller flere av moment, energi og massetransport i et underjordisk hydrokarbonførende reservoar og mellom det underjordiske hydrokarbonførende reservoaret og ett eller flere leveringssteder på jordoverflaten.

19. Datamaskinsystem i henhold til krav 18, idet transporten mellom et underjordisk hydrokarbonførende reservoar og ett eller flere av leveringsstedene omfatter én eller flere transportveier som omfatter minst én av produksjons- og injeksjonsbrønntyper og én eller flere fasilitetstyper som er linket sammen så de danner et fasilitetsnettverk som hydrokarbonfluider blir transportert gjennom mellom undergrunnsreservoaret og leveringsstedene.

20. Datamaskinsystem i henhold til krav 19, idet fasilitetstypene innen transportveiene omfatter minst én fasilitet valgt fra overflatestrømningslinjer, manifolder, separatorer, ventiler, pumper og kompressorer.

21. Datamaskinsystem i henhold til krav 20, idet en tekstfil (Data Definitions File) inneholder definisjonene av de mulige fasilitetstypene som kan inkluderes i en simuleringsmodell og definisjonene av de mulige medlemsvariabletypene for hver fasilitetstype.

22. Datamaskinsystem i henhold til krav 17, idet det objektorienterte programvareproduktet omfatter et grafisk brukergrensesnitt slik at en bruker av datamaskinsystemet definerer en simuleringsmodell som inneholder det aktuelle nettverket av brønner og fasilitetsobjekter for å simulere transportfenomener inn i og ut av et bestemt hydrokarbonførende reservoar.

23. Datamaskinsystem i henhold til krav 17, idet ekstra datamedlemstyper som blir definert av brukeren av det objektorienterte programvareproduktet og datamaskinsystemet i henhold til krav 17 der en bruker av datamaskinsystemet definerer ekstra fasilitetsdatamedlemmer ved hjelp av et grafisk brukergrensesnitt, der nevnte ekstra datamedlemmer utvider funksjonaliteten av datamaskinsystemet på en måte som brukeren kan tilpasse.

24. Datamaskinsystem i henhold til krav 17, idet den objektorienterte programvaren er skrevet på dataspråket C++.

25. Datamaskinsystem i henhold til krav 17, idet lagringsmidlene omfatter en objektorientert database.

26. Datamaskinsystem i henhold til krav 17, idet det objektorienterte utvidbare klassehierarkiet er en objektorientert programvarearkitektur med et antall klasser som skiller medlemsvariable fra klassene de medlemsvariable logisk tilhører, idet nevnte programvarearkitektur omfatter følgende: a. et hierarki av fasilitetsklasser, idet de mest spesialiserte avledede klassene i hierarkiet av fasilitetsklasser (Node, Connection, Compound, Well) er konstruert for generisk å representere de typene av fasiliteter som kan modelleres, b. et hierarki av medlemsvariable-klasser, idet de mest spesialiserte avledede klassene i hierarkiet av medlemsvariable-klasser (SystemAttributeValue, UserAttributeValue, RateConstraint, PressureConstraint) er konstruert for generisk å representere de typene av medlemsvariable som en fasilitet kan ha, idet nevnte medlemsvariable er én av følgende typer: skalar eller matrise med flytende komma, skalar eller matrise med heltall, en streng, en boolsk variabel, en oppregnet type, en grense for strømningshastighet og en trykk-grense, samt c. en ValueUse-klasse (206, figur 2) som har en mange-til-én assosiasjon med baseklassen i hierarkiet av datamedlemsklasser (Value, 207, figur 2) og en mange-til-én assosiasjon med baseklassen i hierarkiet med fasilitetsklasser (FacBase, 200, figur 2), slik at hvert Value-objekt har én eller flere henvisninger til ValueUse-objektene som relaterer bruken av dette Value-objektet til FacBase-objektet som logisk eier det og styrer tilgangen til det.

27. Datamaskinsystem i henhold til krav 26, idet hele hierarkiet av klasser inkluderer klasser i tillegg til de før nevnte fasilitetsklasser og medlemsvariable-klasser, der nevnte tilleggsklasser sørger for fleksibilitet til å gjenbruke fasilitetsobjekter i multiple simuleringsrealiseringer, med hver enkelt realisering i stand til å gjenbruke all, en del av, eller ingen av medlemsvariable-objektene i én eller flere av de andre realiseringene som bruker fasilitetsobjektet, idet nevnte tilleggsklasser omfatter følgende: a. en WmSystem-controllerklasse (217,figur 2) som har en direkte én-til-mange assosiasjon med baseklassen i hierarkiet av fasilitetsklasser (FacBase, 200, figur 2), slik at et objekt av klassen WinSystem i en samling av simuleringsutførelser har direkte henvisninger til supersettet av alle fasilitetsobjekter som blir brukt i disse simuleringsutførelsene, b. en Case-klasse (215, figur 2) som har en mange-til-én assosiasjon med WmSystem-klassen, slik at et objekt av klassen WmSystem kan brukes av mange objekter av klassen Case, et Case-objekt som omfatter hele settet av data for én simuleringsutførelse, c. en ValueUse-klasse (206, figur 2) som har en mange-til-én assosiasjon med baseklassen i datahierarkiet (Value, 207, figur 2) og en mange-til-én assosiasjon med Case-klassen, slik at i en gitt simulerings-Case vil hvert objekt av klassen Value direkte referere til ett eller flere objekter av klassen ValueUse, og hvert referert objekt av klassen ValueUse relaterer bruken av Value-objektet til de Case eller de simuleringsutførelsene det er brukt i, inkludert den gitte Case.

28. Datamaskinsystem i henhold til krav 17, idet systemet er et datamaskinsystem for simulering av et fysisk system, som omfatter minnemidler, lagringsmidler samt objektorientert programvare i et hovedsimuleringssystem, idet nevnte datamaskinsystem i tillegg omfatter følgende: a) et logisk grensesnitt som tillater en bruker av datamaskinsystemet å konstruere logikk dynamisk for å tilpasse simuleringen av det fysiske systemet, b) midler for å konvertere den konstruerte logikken til tilsvarende objektorientert kode, c) midler til å integrere den objektorienterte koden med hovedsimuleringssystemet som omfatter en simuleringsdatamodell og simuleringsalgoritmer, slik at det fører til et integrert simuleringssystem, samt d) midler for å kjøre det integrerte simuleringssystemet.

29. Datamaskinsystem i henhold til krav 28, idet den konstruerte logikken omfatter fasilitetsbehandlingslogikk som er representativ for trinn for å overvåke og styre mekaniske fasiliteter som er knyttet til det fysiske systemet.

30. Datamaskinsystem i henhold til krav 28, idet det logiske grensesnittet omfatter et logisk flytskjema-grensesnitt.

31. Datamaskinsystem i henhold til krav 30, idet det logiske flytskjemagrensesnittet omfatter én eller flere av ikoner, piler, menyer, dialoger, verktøylinjeknapper, samt tekst som tillater brukeren av datamaskinsystemet å bygge opp, redigere og visualisere fasilitetsbehandlingslogikk i form av et flytskjema.

32. Datamaskinsystem i henhold til krav 30, idet det logiske flytskjemagrensesnittet omfatter ikoner som representerer grunnleggende logiske styringskonstruksjoner for sløyfekjøring, beslutningstaking, setningsutførelse og logisk inngang og utgang.

33. Datamaskinsystem i henhold til krav 32, idet ikoner som representerer logiske styringsmekanismer tillater en bruker av datamaskinsystemet å konstruere tilpassede logikkflytskj emaer.

34. Datamaskinsystem i henhold til krav 28, idet det logiske grensesnittet omfatter et tekstbasert logikk-kodegrensesnitt.

35. Datamaskinsystem i henhold til krav 34, idet det tekstbaserte logikk-kode-grensesnittet omfatter et grafisk tekstbehandlingsprogram for å utføre én eller flere av innlegging, endring og sletting av linjer med alfanumerisk tekst.

36. Datamaskinsystem i henhold til krav 34, idet den tekstbaserte logikkoden, som er et styrespråk for fasilitetsbehandling, er i stand til å bli dannet automatisk ut fra logikkflytskjemaet.

37. Datamaskinsystem i henhold til krav 36, idet styrespråket for fasilitetsbehandling er i stand til å være automatisk konverterbart til objektorientert fasilitetsbehandlingskode i form av C++.

38. Datamaskinsystem i henhold til krav 36, idet styrespråket for fasilitetsbehandling er et objektorientert språk med egenskaper og omfang som passer for å danne fasilitetsbehandlingslogikk.

39. Datamaskinsystem i henhold til krav 28, idet den objektorienterte koden er en fasilitetsbehandlings-objektorientert kode i form av C++.

40. Datamaskinsystem i henhold til krav 28, idet det logiske grensesnittet setter en bruker av datamaskinsystemet i stand til å utvikle logikk ved bruk av enten et logisk flytskjema-grensesnitt eller et tekstbasert logikk-kode-grensesnitt.

41. Datamaskinsystem i henhold til krav 28, idet den objektorienterte koden har evnen til å utvide simuleringsdatamodellen ved å opprette nye klasser som arver fra simuleringsdatamodellen, slik at den objektorienterte koden derved blir i stand til å kalle funksjoner i simuleringsdatamodellen og bruke medlemsdata fra simuleringsdatamodellen.

42. Datamaskinsystem i henhold til krav 28, idet det i tillegg omfatter midler for kompilering av den objektorienterte koden til en objektorientert fasilitetsbehandlings-objektkode for å frembringe delte biblioteker, og derved tillate lasting av de delte bibliotekene i hovedsimuleringssystemet.

43. Datamaskinsystem i henhold til krav 28, idet det i tillegg omfatter midler for kompilering av den objektorienterte koden til en objektorientert fasilitetsbehandlings-objektkode og midler til å linke fasilitetsbehandlings-objektkoden for å frembringe dynamisk linkede biblioteker, slik at det blir mulig å laste de dynamisk linkede bibliotekene inn i hovedsimuleringssystemet.

44. Datamaskinsystem i henhold til krav 28, idet dette er i stand til å kjøre det integrerte simuleringssystemet ved å påkalle den objektorienterte fasilitetsbehandlingskoden ved et antall tidstrinn i løpet av simuleringen.

45. Datamaskinsystem i henhold til krav 44, idet den objektorienterte fasilitetsbehandlingskoden er i stand til å føre styringen tilbake til hovedsimuleringssystemet etter at fasilitetsbehandlingskoden har avsluttet kjøringen for gjeldende tidstrinn.

46. Datamaskinsystem i henhold til krav 28, idet dette omfatter et antall sammenkoblede prosessorer for å utføre simuleringen.