NO20110703A1 - Forretningsmetode realiserings-linking - Google Patents

Description

BESLEKTEDE SØKNADER

[0001]Denne søknad krever prioritet fra US foreløping søknad med serie nr. 61/345258 med tittel "Business Process Realization Linking", innlevert 17. mai 2010, som innlemmes som referanse heri.

BAKGRUNN

[0002]Data i geovitenskap-objekter som kan lagre informasjon (repository) er ofte viktige bestanddeler ved forretningsbeslutninger. For eksempel kan en forretningsbeslutning avhenge av volum av utvinnbar olje, som iboende avhenger av fysiske data og eventuelle simuleringsresultater (eksempelvis fra simulering av et geologisk miljø). I et slikt eksempel kan forretningsbeslutningstaking gjennomføres, i det minste delvis, på papir. Videre, dokumentasjon av forretningsmetodebeslutninger kan avhenge av lagring av papirer i et arkiv, for eksempel med utskrifter av enkelte relevante simuleringsresultater og eventuelt enkelte fysiske data. Slik praksis sørger ikke lett for enhetlig beslutningstaking eller revurderinger av forretningsbeslutninger (eller prosesser hvor det foretas forretningsbeslutninger). Som her beskrevet kan forskjellige teknikker valgfritt forbedre beslutningstaking og analyse av beslutninger og beslutningstakingsprosesser.

SAMMENFATNING

[0003]Ett eller flere datamaskin-lesbare media som inkluderer datamaskin-utførbare instruksjoner for å instruere et databehandlingsystem til å aksessere en mal, instantiere malen for en realisering av en datadrevet applikasjon, gjennom-føre en analyse definert av malen hvor analysen er avhengig av linking til i det minste noen data som den datadrevne applikasjon er avhengig av og utmating av informasjon basert i det minste delvis på analysen. Forskjellige andre apparater, systemer, fremgangsmåter, osv. er også offentliggjort.

[0004]Denne sammenfatning er tilveiebrakt for å introdusere et utvalg av konsepter som videre er beskrevet nedenfor i den detaljerte beskrivelse. Denne sammenfatning er ikke ment for å identifisere viktige eller essensielle trekk ved den gjenstand det kreves beskyttelse for, heller ikke er den ment til bruk som et hjelpemiddel for å begrense omfanget av den gjenstand det kreves beskyttelse for.

KORT BESKRIVELSE AV TEGNINGENE

[0005]Trekk og fordeler ved de beskrevne implementeringer kan lettere forstås med henvisning til den følgende beskrivelse sett sammen med de ledsagende tegninger.

[0006]Figur 1 illustrerer et eksempel på et system som inkluderer forskjellige komponenter for simulering av et reservoar og komponenter for en mal-basert analyse;

[0007]Figur 2 illustrerer et eksempel på et rammeverk som inkluderer et modell-simuleringslag og tilknyttede domeneobjekter;

[0008]Figur 3 illustrerer eksempler på scenarioer for en konvensjonell forretningsanalyse og en mal-basert forretningsanalyse;

[0009]Figur 4 illustrerer eksempler på en mal-basert forretningsanalyse til to forskjellige tidspunkter;

[0010]Figur 5 illustrerer et eksempel på en fremgangsmåte for gjennomføring av en mal-basert analyse;

[0011]Figur 6 illustrerer eksempler på grafiske brukergrensesnitt (Graphical User Interfaces, GUI's) som sørger for linking til entiteter og visning av taggede entiteter;

[0012]Figur 7 illustrerer eksempler på GUTer som oppviser informasjon ved-rørende entiteter for en geovitenskap-applikasjon;

[0013]Figur 8 illustrerer forskjellige komponenter som valgfritt kan implementeres i et system, for eksempel så som systemene på fig. 1 eller fig. 3 sammen med et blokkdiagram av et eksempel på en fremgangsmåte; og

[0014]Figur 9 illustrerer eksempler på komponenter i et system og et nettverkssystem.

DETALJERT BESKRIVELSE

[0015]Den følgende beskrivelse inkluderer den beste modus som for det inneværende er tenkelig for praktisering av de beskrevne implementeringer. Denne beskrivelse skal ikke forstås i en begrensende forstand, men er snarere laget utelukkende for det formål å beskrive de generelle prinsipper ved implementerin-gene. Omfanget av de beskrevne implementeringer skal bestemmes med henvisning til de bevilgede krav.

[0016]Figur 1 viser et eksempel på et system 100 som inkluderer forskjellige administrasjonskomponenter 110 for å administrere forskjellige aspekter av et geologisk miljø 150. Administrasjonskomponentene 110 kan for eksempel tillate direkte eller indirekte administrasjon av avføling, boring, injisering, utvinning, osv. med hensyn på det geologiske miljø 150.1 sin tur kan ytterligere informasjon om det geologiske miljø 150 bli tilgjengelig som tilbakemelding 160 (eksempelvis valgfritt som innmating til én eller flere av administrasjonskomponentene 110). Forskjellige linkingskomponenter 170 er også vist, hvilket tillater integrasjon av én eller flere bestemte prosesser som kan være avhengig av data eller annen informasjon tilknyttet administrasjonskomponentene 110.

[0017]I eksempelet på fig. 1 inkluderer administrasjonskomponentene 110 en seismikk-datakomponent 112, en informasjonskomponent 114, en prosesserings-komponent 116, en simuleringskomponent 120, en attributtkomponent 130, en analyse/visualiserings-komponent 142 og en arbeidsforløpskomponent 144.1 operasjon kan seismikkdata og annen informasjon tilveiebrakt per komponentene 112 og 114 mates inn til simuleringskomponenten 120.

[0018]Som her beskrevet, simuleringskomponenten 120 kan være avhengig av entiteter 122. Entiteter 122 kan være jordentiteter, så som brønner, overflater, reservoarer, osv. I systemet 100 er entitetene 122 typisk virtuelle representasjoner av faktiske fysiske entiteter som er rekonstruert med henblikk på simulering. Entitetene 122 kan være basert på data samlet inn via avføling, observasjon, osv.

(for eksempel seismikkdataene 112 og annen informasjon 114).

[0019]Som her beskrevet, simuleringskomponenten 120 kan være avhengig av et programvare-rammeverk, så som et objektbasert rammeverk. I et slikt rammeverk kan entiteter være basert på forhåndsdefinerte klasser for å muliggjøre modellering og simulering. Et kommersielt tilgjengelig eksempel på et objektbasert rammeverk er MICROSOFT® .NET™-rammeverket (Redmond, Washington), som tilveiebringer et sett av utvidbare objektklasser. I .NET™-rammeverket, innkapsler en objektklasse en modul av gjenbrukbar kode og tilknyttede datastrukturer. Objektklasser kan brukes til å instantiere objektforekomster til bruk i et program, skript, osv. For eksempel kan borehull-klasser definere objekter for representering av borehull basert på brønndata.

[0020]I eksemplet på fig. 1 kan simuleringskomponenten 120 behandle innfor-masjon for tilpasning til én eller flere attributter spesifisert av attributtkomponenten 130, som kan være et bibliotek av attributter. Slik behandling kan forekomme før innmating til simuleringskomponenten 120. Alternativt, eller i tillegg til, kan simuleringskomponenten 120 gjennomføre operasjoner på innmatet informasjon basert på én eller flere attributter spesifisert av attributtkomponenten 130. Som her beskrevet, simuleringskomponenten 120 kan konstruere én eller flere modeller av det geologiske miljø 150, som kan benyttes som basis for å simulere oppførsel til det geologiske miljø 150 (eksempelvis som respons på én eller flere handlinger, enten de er naturlige eller kunstige). I eksempelet på fig. 1 kan analyse/visualiserings-komponenten 142 tillate interaksjon med en modell eller modellbaserte resultater. I tillegg, eller alternativt, kan utgangsdata fra simuleringskomponenten 120 mates inn til ett eller flere andre arbeidsforløp, som vist med en arbeidsforløp-komponent 144.

[0021]Som her beskrevet, administrasjonskomponentene 110 kan inkludere trekk med et kommersielt tilgjengelig simuleringsrammeverk, så som PETREL® seismikk til simulering programvare-rammeverk (Schlumberger Limited, Houston, Texas). PETREL®-rammeverket tilveiebringer komponenter som tillater optimering av lete- og utbyggingsoperasjoner. PETREL®-rammeverket inkluderer seismikk til simulering programvarekomponenter som kan mate ut informasjon til bruk for økning av reservoar-ytelse, for eksempel ved å forbedre formueteam-produktivitet. Gjennom bruk av et slikt rammeverk kan forskjellige fagpersoner (eksempelvis geofysikere, geologer og reservoaringeniører) utvikle samarbeidende arbeids-forløp og integrere operasjoner for å strømlinje prosesser. Et slikt rammeverk kan betraktes som en applikasjon, og kan anses som en datadrevet applikasjon (eksempelvis hvor data mates inn for det formål å simulere et geologisk miljø).

[0022]Som her beskrevet, administrasjonskomponentene 110 kan inkludere trekk for geologi og geologisk modellering for å generere høyoppløsnings geologiske modeller av reservoarstruktur og -stratigrafi (eksempelvis klassifisering og estimering, facies-modellering, brønnkorrelasjon, overflateavbilding, strukturell analyse og forkastningsanalyse, brønnbane-design, dataanalyse, fraktur-modellering, arbeidsforløpsredigering, usikkerhets- og optimeringsmodellering, petrofysisk modellering, osv.). Spesielle trekk kan tillate gjennomføring av hurtig 2D og 3D seismisk tolkning, valgfritt for integrasjon med geologiske verktøy og engineering-verktøy (eksempelvis klassifisering og estimering, brønnbane-design, seismisk tolkning, seismisk attributt-analyse, seismisk sampling, seismisk volum-gjengivelse, geolegeme-ekstraksjon, domene-konvertering, osv.). Angående reservoar-engineering, for en generert modell, kan ett eller flere trekk tillate simulering av arbeidsforløp for å gjennomføre strømlinjeformet simulering, redu-sere usikkerhet og bistå i fremtidig brønnplanlegging (eksempelvis usikkerhets-analyse og optimering av arbeidsforløp, brønnbane-design, avansert gitterlegging og oppskalering, historietilpasningsanalyse, osv.). Administrasjonskomponentene 110 kan inkludere trekk for bore-arbeidsforløp, inkludert brønnbane-design, borevisualisering og sanntids modelloppdateringer (eksempelvis via sanntids datalinker).

[0023]Som her beskrevet, forskjellige aspekter av administrasjonskomponentene 110 kan være utvidelser eller programtillegg som opererer i henhold til spesifikasjoner i et rammeverksmiljø. For eksempel, et kommersielt tilgjengelig rammeverksmiljø markedsført som OCEAN®-rammeverk-miljøet (Schlumberger Limited) tillater sømløs integrasjon av utvidelser (eller programtillegg) i et PERTRAL®-rammeverk-arbeidsforløp. OCEAN®-rammeverk-miljøet drar fordel av

.NET®-verktøy (Microsoft Corporation, Redmond, Washington) og tilbyr stabile, brukervennlige grensesnitt for effektiv utvikling. Som her beskrevet, forskjellige komponenter kan implementeres som utvidelser (eller programtillegg) som tilpasser seg til og opererer i henhold til spesifikasjoner for et rammeverksmiljø

(eksempelvis i henhold til applikasjons-programmeringsgrensesnitt (Application Programming Interface, API) spesifikasjoner, osv.). Forskjellige teknologier som her er beskrevet kan valgfritt implementeres som komponenter i attributt-biblioteket.

[0024]Innen feltet seismisk analyse kan aspekter av et geologisk miljø defineres som attributter. Generelt hjelper seismiske attributter til med å kondisjonere konvensjonell amplitude-seismikkdata for forbedrede oppgaver med strukturell tolkning, så som fastleggelse av den eksakte lokalisering av litologiske avslutninger og hjelp til å isolere skjulte seismiske stratigrafiske trekk for et geologisk miljø. Et attributt-genereringsprosess (eksempelvis i PETREL®-rammeverket eller et annet rammeverk) kan være avhengig av et bibliotek av forskjellige seismiske attributter (eksempelvis for visning og bruk sammen med seismisk tolkning og reservoar-karakteriseringsarbeidsforløp).

[0025]I eksempelet på fig. 1 inkluderer linkingskomponentene 170 en mal-genereringskomponent 172, en mal-instantieringskomponent 174 og en analysekomponent 176. Én eller flere av linkingskomponentene 170 kan samhandle med administrasjonskomponentene 110. Foreksempel, en mal generert av mal-genereringskomponenten 172 kan konsumeres med en realisering av en simuleringsprosess (eksempelvis utførelse per simuleringskomponenten 120) for det geologiske miljø 150, for dermed å instantiere malen (eksempelvis per mal-instantieringskomponenten 174). Som her beskrevet, instantiering av en mal kan tillate en analyse (eksempelvis per analyse-komponenten 176) hvor analysen er avhengig av data tilknyttet én eller flere av entitetene 122.1 forskjellige eksempler tillater instantiering av en mal aksessering til instantierte objekter. For eksempel, en mal kan definere en forretningsmetode eller -prosess som er avhengig av informasjon tilknyttet et objekt, slik at instantieringen av forretningsmetode-malen realiserer forretningsmetoden, som, i sin tur, aksesserer informasjon tilknyttet et instantiert objekt. I det foregående eksempel kan det instantierte objekt være en av entitetene 122 (eksempelvis del av en realisering av en simulering av et geologisk miljø).

[0026]Figur 2 viser et eksempel på et rammeverk 220 som inkluderer et modell-simuleringslag 240 sammen med et rammeverk-tjenesterlag 250, et rammeverk-kjernelag 254 og et modulerlag 260. Rammeverket 220 kan være det kommersielt tilgjengelige OCEAN®-rammeverket, hvor modellsimuleringslaget 240 er den kommersielt tilgjengelige PETREL®-modell-sentriske programvarepakke som er vert for OCEAN®-rammeverksapplikasjoner. Som her beskrevet, PETREL®-programvaren kan anses som en datadrevet applikasjon.

[0027]Modellsimuleringslaget 240 kan tilveiebringe domeneobjekter 242, virker som en datakilde 247, sørge for gjengivelse 248 og forskjellige brukergrensesnitt 249. Gjengivelse 248 kan tilveiebringe et grafisk miljø hvor applikasjoner kan vise sine data, mens brukergrensesnittene 249 kan tilveiebringe et felles utseende og følelse for alle applikasjonsbrukergrensesnitt-komponenter.

[0028]I eksempelet på fig. 2 inkluderer domeneobjektene 242 entitetsobjekter 244 og egenskapsobjekter 246. Entitetsobjektene 244 kan brukes til geometrisk å representere brønner, overflater, reservoarer, osv., mens egenskapsobjektene 246 kan brukes til å tilveiebringe egenskapsverdier så vel som dataversjoner og visningsparametere. For eksempel kan et entitetsobjekt representere en brønn, hvor et egenskapsobjekt tilveiebringer logginformasjon så vel som versjonsinformasjon og visningsinformasjon (eksempelvis for å vise brønnen som del av en modell).

[0029]I eksempelet på fig. 2 kan data lagres i én eller flere datakilder 247 (eller datalagre, generelt fysiske datalagringsinnretninger), som kan være på de samme eller forskjellige fysiske steder og være tilgjengelige via ett eller flere nettverk. Modellsimuleringslaget 240 kan være konfigurert til å modellere prosjekter. Som sådan kan et bestemt prosjekt lagres, hvor lagret prosjektinformasjon kan inkludere inngangsdata, modeller, resultater og tilfeller. Således, ved komplette-ring av en modelleringssesjon, kan en bruker lagre et prosjekt. På et senere tidspunkt kan prosjektet aksesseres og gjenopprettes ved bruk av modellsimuleringslaget 240, som kan gjenskape forekomster av de relevante domeneobjekter. For situasjoner hvor data har blitt forandret, kan versjonsinformasjon påpekes, slik at en bruker kan bestemme for eksempel om hvorvidt den inneværende forekomst av et objekt som representerer en jordentitet er basert på gamle egenskapsverdier eller inneværende egenskapsverdier; idet man tar ad notam at en forandring i egenskapsverdier kan endre et modellresultat (eksempelvis for ett eller flere tilfeller).

[0030]Figur 3 viser et system 310 for en konvensjonell forretningsanalyse 230 (scenario A) og systemet 310 for en malbasert forretningsanalyse 350 (scenario B). I scenario A (konvensjonelt), opererer en bruker utstyr 315 i systemet 310 for å finne relevante data i et lager 320. Brukeren kan for eksempel ønske å anslå en sjanse for suksess for et reservoar modellert i Prosjekt 1, hvor reservoaret har tilknyttede egenskapsverdier. For å gjennomføre anslaget, må brukeren identifisere egenskapsverdiene (eksempelvis data) for prosjekt 1 og deretter hente frem verdiene. Så snart verdiene har blitt hentet frem kan brukeren gjennomføre forretningsanalysen 330 for å bestemme sjansen for suksess for reservoaret modellert i Prosjekt 1.

[0031]I scenario B (malbasert), opererer en bruker utstyr 315 i systemet 310 for å kreve instantiering av en mal X 352 med en forekomst av Prosjekt 1 360

(eksempelvis en realisering av en datadrevet applikasjon). Den instantierte mal X 354 kan kreve gjengivelse av et grafisk brukergrensesnitt (Graphical User Interface, GUI) mens Prosjekt 1 kjører (eksempelvis per modellsimuleringslaget 240 på fig. 2). Som vist i eksempelet på fig. 1, forekomsten av Prosjekt 1 360 er avhengig av data i lageret 320. Den instantierte mal 354 kan aksessere (eksempelvis linke til) disse dataene lokalt (eller fjernt) for det formål å gjennomføre forretningsanalysen 350 definert av malen X 352 (eksempelvis en sjanse for suksess for et reservoar modellert i Prosjekt 1).

[0032]Som vist i eksempelet på fig. 3, den instantierte mal X 354 kan også forårsake at data tilknyttet Prosjekt 1 blir tagget. For eksempel, der hvor den malbaserte forretningsanalyse 350 er avhengig av porøsitetsfordelingsdata for et reservoar, kan den instantierte mal X 354 forårsake at data i lageret 320 blir tagget, som angitt med taggede data 370. Så snart de er tagget kan dataene identifiseres som å være tilknyttet malen X (eksempelvis tilknyttet forretningsanalysen definert med mal X). Videre, de bestemte data som er tagget kan inkludere versjonsinformasjon, slik at forretningsanalysen kan bekreftes på ny eller gjennomføres på ny på et senere tidspunkt ved bruk av en bestemt versjon av data. Som her beskrevet, gitt løsningsmåten i scenario B, kan en bruker identifisere data over et foretak for forskjellige prosjekter som har blitt brukt til å gjennomføre en forretningsanalyse definert av malen X 352 (eller en hvilken som helst annen mal konfigurert til å forårsake tagging av data).

[0033] Generelt, et prosjekt bygget ved bruk av PETREL®-programvare inneholder såkalte dataelementer som inneholder jordentiteter (eksempelvis en brønn, en overflate, et reservoar, osv.). Jordentiteter kan karakteriseres ved egenskaper (eksempelvis logger langs en brønnboring, høydefelter over en overflate, porøsitetsfordeling i et reservoar, osv.). Jordentiteter i en datadrevet applikasjon, så som PETREL®-applikasjonen, kan være basert på domeneobjekter (betrakt eksempelvis entitetsobjektene 244 og egenskapsobjektene 246 på fig. 2). Som her beskrevet, linking kan linke til entiteter og tagging kan tagge entiteter, som i seg selv linker til data (eller "dataelementer") henholdsvis tagge data (eller "dataelementer"), eller, for eksempel, linking kan linke direkte til data og tagging kan direkte tagge data. Som her beskrevet, linking og tagging kan valgfritt forekomme på en essensielt samtidig måte (eksempelvis hvor en linkings-operasjon automatisk forårsaker at data blir tagget).

[0034]Figur 4 viser eksempler ved tidspunkter T1 og 12 for en malbasert forretningsanalyse. Ved tidspunkt T1 gjennomfører en bruker med et utstyr 415 en malbasert forretningsanalyse for en forekomst av Prosjekt 1 460 ved bruk av mal X 452 for å returnere et resultat ved T1. Ved gjennomføring av denne oppgave, i lager 420, blir data tilknyttet Prosjekt 1 tagget, som angitt med en dataadmini-strasjonskomponent 490. Malen X 452 kan for eksempel kreve tagging versjon 1.2.4 av data D_1, versjon 2.0 av data D_2, og så videre, til D_N.

[0035]Ved tidspunkt 12 gjennomfører en bruker med et utstyr 417 en malbasert forretningsanalyse for Prosjekt 1, som definert med mal X 452. Ettersom dataene for Prosjekt 1 allerede har blitt tagget ved tidspunkt T1, som å være tilknyttet malen X 452, kan brukeren valgfritt gjennomføre analysen på en alternativ måte 465 som ikke krever en kjørende forekomst av Prosjekt 1 460. Videre, som angitt i eksempelet på fig. 4, bruken kan kreve gjenopptagelse av det tidligere resultat oppnådd ved tidspunkt T1, eller brukeren kan kreve generering av et nytt resultat for tidspunkt 12. For å gjenta resultatet ved tidspunkt T1, kan brukeren identifisere de tidligere taggede data som tilknyttet med malen X 452, mens for å generere et nytt resultat for tidspunkt 12, kan brukeren instantiere malen X 452 og dermed forårsake at dataene blir tagget for tidspunkt 12 (eksempelvis med inneværende versjoner av dataene for situasjoner hvor underliggende data kan ha blitt forandret).

[0036]Selv om eksemplene på fig. 3 og 4 har blitt beskrevet i tilknytning til en forretningsanalyse, kan en feltanalyse implementeres på en lignende måte. For eksempel kan en feltingeniør definere en engineering-prosess for en feltoperasjon via en mal. I et slik eksempel kan instantiering av malen sørge for aksess til data for en realisering av et geologisk miljø av interesse. Gitt en maldefinert analyse som utgang, kan feltingeniøren ta en beslutning, essensielt i sanntid, angående feltets operasjon. For en feltprosess kan tagging forekomme for å tillate postanalyse av en feltbeslutning (betrakt eksempelvis en feltoperasjonsgransking).

[0037]Som her beskrevet, informasjon tilknyttet implementering av en forretningsanalyse, en feltanalyse, osv., kan brukes som tilbakemelding for å forbedre data, dataadministrasjon, forretningsbeslutningstaking, feltbeslutningstaking, osv. (se for eksempel tilbakemeldingsblokk 160 på fig. 1).

[0038]Som her beskrevet, et domenespesifikt språk (Domain Specific Language, DSL) kan brukes til å uttrykke en prosess så som en forretningsanalyse-metode som kan inkludere bestemmelse av en sannsynelig suksess eller fiasko. En DSL kan være dedikert til et bestemt problemdomene, en bestemt program-represen-tasjonsteknikk, en bestemt løsningsteknikk, osv. DSL'er blir generelt implementert enten med tolking eller kodegenerering. Tolking kan inkludere innlesing i DSL-skriptet og utførelse av det ved kjøretid. Kodegenerering kan inkludere parsing av DSL-skript og generering av kode (eksempelvis i et høynivåspråk, så som Java eller C). En programvare-prosess som blir brukt krever generelt en modifikasjon for å ta hånd om design, implementering, integrasjon, feilretting og vedlikehold av et DSL. Som her beskrevet, en simuleringskomponent (eksempelvis simuleringskomponenten 120 på fig. 1, simuleringslaget 240 på fig. 2, osv.) kan inkludere ett eller flere trekk for håndtering av et DSL-skript. I et såkalt piggyback-arangement, kan DSL-skript konsumeres av en komponent som genererer kode i et språk brukt av en programvare-pakke. I sin tur kan den genererte kode utføres ved bruk av den samme infrastruktur som programvarepakken. I forskjellige arrangement kan ett eller flere applikasjons-programmeringsgrensesnitt (Application Programming Interfaces, API's) være tilveiebrakt for interaksjoner mellom DSL-trekk og trekk for en programvarepakke. Faktisk implementering av DSL-skript kan inkludere det ene eller flere av parsing, tolking, kompilering, osv. Et mellomspråk kan brukes, hvor DSL-skriptet konverteres til mellomspråkskode og valgfritt integreres med annen mellomspråkskode før utførelse.

[0039]Nedenfor er et eksempel på et DSL-skript for en analysemal:

[0040]Som her beskrevet, en prosess (eksempelvis forretning, felt, osv.) kan dokumenteres som en mal for tilknytning til en simuleringsapplikasjon. Som nevnt, data som applikasjonen er avhengig av kan tilknyttes én eller flere maler. Tilknyt-ningen mellom data og en mal kan resultere i at dataene blir tagget med én eller flere tagger definert av malen. Ettersom slike data typisk blir tilknyttet en jordentitet for et prosjekt, kan tagging valgfritt betraktes som tagging av jordentiteten. Som her beskrevet, tagging kan tagge geometridata, egenskapsverdidata eller andre data. Tagging muliggjør søkemekanismer for å rapportere data tilknyttet prosesser eller deler av en prosess.

[0041]I konteksten for et geovitenskap-oppbevaringssted (eksempelvis datalager), blir en forretningsanalyse konvensjonelt gjennomført separat (dvs. ikke i direkte tilknytning til en realisering av simulering av et geologisk miljø). Som her beskrevet, ved gjennomføring av en forretningsanalyse innenfor konteksten for et geovitenskap-oppbevaringssted tillates direkte linking av data til analysen og tagging av data av analysen, hvor taggingen kan gjennomføres på en måte som er konsistent over flere oppbevaringssteder (eksempelvis realiseringer av forskjellige geologiske miljøer) for å gjøre det mulig for søkeverktøy å tilveiebringe en konsistent betraktning over flate oppbevaringssteder skreddersydd til forretningsanalysen.

[0042]Som nevnt, implementering av en analyse kan sørge for et granskings-forsøk tilknyttet et geovitenskap-oppbevaringssted på en måte som også muliggjør en konsistent metodologi for geovitenskapsanalyse over en organisasjon eller gruppe av brukere.

[0043]Figur 5 viser et eksempel på en fremgangsmåte 510. Fremgangsmåten 510 inkluderer en aksessblokk 514 for aksessering av en forretningsanalyse-mal uttrykt i et domenespesifikt språk (DSL), en instantieringsblokk 518 for instantiering av malen for en realisering av en geovitenskap-applikasjon konfigurert til å aksessere data tilknyttet et geologisk felt, en ytelsesblokk 522 for gjennomføring av en forretningsanalyse, hvor gjennomføringen inkluderer linking til bestemte data tilknyttet med det geologiske felt basert i det minste delvis på malen, og en utgangsblokk 526 for utmating av informasjon basert i det minste delvis på analysen.

[0044]Fremgangsmåten 510 er vist på fig. 5 i tilknytning til forskjellige datamaskin-lesbare media (Computer Readable Media, CRM) blokker 516, 520, 524 og 528. Slike blokker inkluderer generelt instruksjoner som er egnet for utførelse av én eller flere prosessorer (eller kjerner) for å instruere en databehandlingsinnretning til å gjennomføre én eller flere handlinger. Selv om forskjellige blokker er vist, kan et enkelt medium være konfigurert med instruksjoner for å tillate, i det minste delvis, gjennomføring av forskjellige handlinger i fremgangsmåten 510.

[0045]Som her beskrevet, en fremgangsmåte kan inkludere aksessering av en mal, instantiering av malen for en realisering av en datadrevet applikasjon, gjennomføring av en analyse definert av malen, hvor analysen er avhengig av linking til i det minste noen data som den datadrevne applikasjon er avhengig av, og utmating av informasjon basert i det minste delvis på analysen. Som her beskrevet, ett eller flere datamaskin-lesbare media kan inkludere instruksjoner for å instruere et databehandlingssystem til å aksessere en mal, instantiere malen for en realisering av en datadrevet applikasjon, gjennomføre en analyse definert av malen, hvor analysen er avhengig av linking til i det minste noen data som den datadrevne applikasjon er avhengig av, og mate ut informasjon basert i det minste delvis på analysen.

[0046]Figur 6 viser et eksempel på implementering av fremgangsmåten 510 på fig. 5 innenfor et rammeverk så som PETREL®-rammeverket (bemerk at en fremgangsmåte kan implementeres i andre typer av rammeverk). Figur 6 viser et eksempel på et grafisk brukergrensesnitt (GUI) 600 som er rettet mot å korre-spondere til det tidligere beskrevne eksempel på DSL-skript. En slik GUI kan være del av en klientdefinert analyse, og brukes under analyse av et prosjekt. Spesifikt kan GUTen 600 være en realisering av en forretningsmetode fra en mal, hvor GUTen 600 presenteres til en bruker via brukerutstyr innenfor et geovitenskap-prosjekt i et geovitenskap-applikasjonsrammeverk.

[0047]I eksempelet på fig. 6 vedrører GUI'en 600 en vurdering som involverer beregning av en sjanse for suksess basert på et mangfold av geovitenskaps-faktorer. Som del av vurderingen kan geovitenskap-arbeidsforløp og produkter generert av geovitenskap-applikasjonen sammenstilles og direkte relateres til sjansen for suksessfaktorer.

[0048]Ettersom forskjellige organisasjoner trolig vil kreve en forskjellig kombinasjon av faktorer avhengig av deres respektive forretningsmodell og geografien og geologien for et prosjekt som blir vurdert, blir prosessen presentert som en mal som kan dannes og kundetilpasses av en klientorganisasjon. Igjen, som nevnt, en slik mal kan uttrykkes via en DSL.

[0049]Som vist på fig. 6, dataelementer fra geovitenskap-prosjektet kan direkte linkes til forretningsmetoden, for å dokumentere hvilke geovitenskap-dataelementer som ble brukt til å bedømme faktorer i prosessen. I eksempelet på fig. 6 reflekterer forretningsmetoden at geovitenskapsobjekter har blitt brukt til å bedømme "kildeforekomst og kvalitet" og "strukturell/strategrafisk stenging". Spesifikt, i GUI'en 600 representerer fylte romber objekter 612 ("Jordentitet X for Prosjekt 3") og 614 ("Jordentitet Y for Prosjekt 3"). Disse entiteter fra geovitenskap-applikasjonen blir nå linket med forretningsmetoden. I forskjellige eksempler kan et forslag presenteres til en bruker via en GUI vedrørende hvilken entitet som er tilgjengelig og egnet for en definert forretningsmetode. En slik GUI kan valgfritt tillate en bruker å modifisere forretningsmetoden basert på ett eller flere forslag.

[0050]Figur 6 viser også et eksempel på en GUI 630 for ytterligere å beskrive enkelte aspekter ved tagging. Spesifikt, i eksempelet på fig. 6, vedrører GUI'en 630 entitetene 612 og 614 (eksempelvis Jordentiteter X og Y for Prosjekt 3).

[0051] Taggingen muliggjør da at data betraktes i relasjon til prosessen. For eksempel kan en GUI vise alle dataene i et geovitenskap-oppbevaringssted som er forbundet til en entitet. Tagging kan også gjøre det mulig for forretningsmetoden å styre visningsstilen til en entitet når den visualiseres i geovitenskap- applikasjonen (se eksempelvis egenskapsobjektene 246 med visningsparametere på fig. 2).

[0052]I eksempelet på fig. 6 styres taggingen av data av forretningsmetoden. Alle geovitenskap-oppbevaringssteder som bruker den samme forretningsmetode-mal kan følgelig generere det samme sett av tagger, hvilket kan muliggjøre en konsistent betraktning, evne til å søke, osv., over flere prosjekter.

[0053]Figur 7 viser eksempler på grensesnitt tilknyttet et eksempel på implementering innenfor et rammeverk så som PETREL®-rammeverket. Figur 7 viser et eksempel på en GUI 710 for Prosjekt 4 med en jordentitet med omriss av en tykk heltrukket linje referert til som "Stenging av DA nr. Y" (Closure DA No. Y) (f.eks. se piler). En GUI 720 viser entitetene 722 ("Stenging av DA nr. Y") og 724 ("Reservoar SF Porøsitet") ("Reservoar SF Porosity") som å være tagget. GUI'en 720 presenterer en utelatt undertittel for i det minste noen jordentiteter for Prosjekt 4.

[0054]Figur 8 viser eksempler på forskjellige moduler eller komponenter 800, som kan være konfigurert for implementering av en databehandlingsinnretning eller - system, og et eksempel på en fremgangsmåte 890. Som vist på fig. 8, en linkings-komponent 810 kan være konfigurert for linking av en forretningsanalyse (eller-metode) til entiteter (eksempelvis objekter, data, osv.) tilknyttet en applikasjon så som en geovitenskap-applikasjon. En slik komponent kan sørge for en GUI tilknyttet en forretningsmetode, hvor GUI'en viser én eller flere entiteter for en applikasjon, valgfritt som respons på mottak av brukerinnmating.

[0055]En DSL-maluttrykkskomponent 820 kan være konfigurert for mottak av brukerinnmating for å legge inn eller velge setninger for en DSL, hvor setningene kollektivt danner en mal som kan instantieres, for eksempel med en applikasjon så som en geovitenskap-applikasjon.

[0056]En mal-drevet entitetstaggingskomponent 830 kan være konfigurert for tagging av entiteter tilknyttet en applikasjon så som en geovitenskap-applikasjon. For eksempel kan en mal instantieres ved en realisering av et geologisk miljø for en geovitenskap-applikasjon, hvor en GUI gjengis på et display som tillater visning av entiteter av geovitenskap-applikasjonen (eksempelvis entiteter som instantiert av realiseringen). På en slik måte kan en prosess (eksempelvis en forretningsmetode eller feltprosess) gjennomføre en analyse ved bruk av informasjon tilknyttet entitetene.

[0057]En entitetstagg-adminstrasjonskomponent 840 kan konfigureres til administrering av entitetstagger. For eksempel kan en forretningsmetode tagge forskjellige entiteter tilknyttet en realisering av et geologisk miljø ved hjelp av en geovitenskap-applikasjon. I et slikt eksempel kan entitetene være agnostiske til det bestemte geologiske miljø som realiseres. Entitetene kan adminstreres basert på status (eksempelvis tagget eller ikke tagget). Administrering kan inkludere oppdatering til tagger for forskjellige prosjekter som respons på forandringer i underliggende data eller beslutninger.

[0058]En entitetsbasert prosess-granskingskomponent 850 kan være konfigurert for gransking av prosesser. For eksempel kan en forretningsmetode eller -prosess være avhengig av én eller flere entiteter for en geovitenskap-applikasjon, hvor tagging av entitetene forekommer under prosessen. Hvis forretningsmetoden eller -prosessen resulterer i en forretningsbeslutning, kan denne beslutningen granskes på et senere tidspunkt ved eksaminering av de taggede entiteter (f.eks., og tilknyttede data).

[0059]En foretakstagg-analysekomponent 860 kan være konfigurert til å analysere tagger eller taggede entiteter over et foretak (eksempelvis, inkludert partnere, entreprenører, leverandører, osv.). Der hvor applikasjonsentiteter tagges som del av en forretningsprosess, kan beslutningstaking basert på slike forretnings-prosesser analyseres over et foretak, for eksempel for å bestemme nøkkelinfor-masjon eller trender i beslutningstaking (eksempelvis i lys av ny informasjon, opplæring, osv.). Beslutninger som blir ansett som adekvate på et tidspunkt kan analyseres for å bestemme og de fremdeles er adekvate på et senere tidspunkt. Taggede entiteter kan eksamineres for å bestemme hva som fører til et forandret resultat.

[0060]En GUI-frontkomponent 870 kan være konfigurert til å implementere en prosess (eksempelvis forretningsmetode eller -prosess eller feltprosess) som er avhengig av én eller flere entiteter tilknyttet simuleringsprogramvare for simulering av et fysisk miljø. For eksempel kan en GUI presentere en forretningsmetode i forbindelse med jordentiteter tilknyttet simuleringsprogramvare, hvorved en bruker selektivt kan aktivere et grafisk kontrollelement for å velge én eller flere av entitetene for dermed å aksessere data til bruk i forretningsmetoden. GUI-komponenten 870 kan være konfigurert til å aksessere et bibliotek av entiteter, for å tillate automatisk populasjon av seleksjons-valgmuligheter for en forretningsmetode. I en bestemt løsningsmåte kan GUI-komponenten 870 instantieres via konsumpsjon av en mal uttrykt i et DSL (eksempelvis hvor DSL'et er spesifikt for en prosess, så som en forretningsmetode eller -prosess og en applikasjon så som en geovitenskap-applikasjon).

[0061]Komponentene 800 inkluderer en komponent 880, som kan inkludere ett eller flere trekk av komponentene 810 til 870 og valgfritt andre trekk.

[0062]I eksempelet på fig. 8 inkluderer fremgangsmåten 890 en seleksjonsblokk 892 for utvelgelse av en entitet av en geovitenskap-applikasjon, en taggeblokk 894 for tagging av entiteten som å være tilknyttet en forretningsanalyse (eksempelvis en forretningsmetode eller -prosess), en aksessblokk 896 for aksessering av informasjon tilknyttet den taggede entitet; og en beregningsblokk 892 for beregning av en metrikk definert av forretningsanalysen (eksempelvis forretningsmetoden eller - prosessen) basert i det minste delvis på informasjon. Som vist på fig. 8, ett eller flere datamaskin-lesbare media kan inkludere datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å velge ut en entitet av en geovitenskap-applikasjon 893, tagge entiteten som å være tiknyttet en forretningsanalyse (eksempelvis en forretningsmetode eller -prosess) 895, aksessere informasjon tilknyttet den taggede entitet 897; og beregne en metrikk definert av forretningsanalysen (eksempelvis forretningsmetoden eller -prosessen) basert i det minste delvis på informasjon 899.1 det foregående eksempel kan en entitet være basert på ett eller flere domeneobjekter (eksempelvis entitetsobjekter og egenskapsobjekter). Selv om forskjellige blokker er vist på fig. 8, kan et enkelt medium (eksempelvis et lagringsmedium) være konfigurert med instruksjoner for å tillate, i det minste delvis, gjennomføring av forskjellige handlinger i fremgangsmåten 890. Slike blokker inkluderer generelt instruksjoner som er egnet til utførelse av én eller flere prosessorer (eller kjerner) for å instruere en databehandlingsinnretning til å gjennomføre én eller flere handlinger.

[0063]Som her beskrevet, en fremgangsmåte kan inkludere velging av en entitet for en geovitenskap-applikasjon, tagging av entiteten som å være tilknyttet en forretningsmetode eller -prosess, aksessering av informasjon tilknyttet den taggede entitet; og beregning av en metrikk definert av forretningsmetoden eller - prosessen basert i det minste delvis på informasjon. Som her beskrevet, ett eller flere datamaskin-lesbare media kan inkludere datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å velge ut en entitet for en geovitenskap-applikasjon, tagge entiteten som å være tilknyttet en forretningsmetode eller -prosess, aksessere informasjon tilknyttet den taggede entitet; og beregne en metrikk definert av forretningsmetoden eller -prosessen basert i det minste delvis på informasjon. I det foregående eksempel kan en entitet være basert på ett eller flere domeneobjekter (eksempelvis entitetsobjekter og egenskapsobjekter).

[0064]Som her beskrevet, en mal kan instantieres for en realisering av en prosess, hvilket deretter vil gi en link til data tilknyttet en applikasjon. En mal kan definere en forretningsmetode eller -prosess. Som her beskrevet, et system kan være konfigurert til å kjøre en forretningsmetode eller -prosess som er rettet mot å bestemme én eller flere metrikker vedrørende for eksempel en sjanse for suksess. Et slikt system kan være konfigurert til å kjøre prosessen over tid for å se om en sjanse for suksess har blitt forandret (til det bedre eller verre). Selv om forskjellige eksempler viser til "sjanse for suksess", kan en forretningsmetode eller -prosess tilveiebringe utgangsdata som har sammenheng med andre beslutninger enn sjanse for suksess (eller fiasko).

[0065]Som her beskrevet, et system kan sørge for gransking av én eller flere prosesser basert på informasjon trukket ut under en prosesskjøring (eksempelvis forretningsprosesskjøring X ved tidspunkt t, det er kjent hvilke entiteter som en var avhengig av og hva de underliggende data var for geovitenskapspakken ved tidspunkt t per databaseinformasjon, objektadministrasjon, osv). En gransking kan tilveiebringe noe tillit til hva enkelte besluttet og hvorfor. For eksempel, for en person som fant en 53% sjanse for suksess og produksjon av 11 129 119 m<3>, hvis faktisk produksjon var forskjellig ved boring, kan det opptre en oppdatering vedrørende den underliggende forretningsprosess (eksempelvis valgfritt via en modifikasjon av en mal).

[0066]Som her beskrevet, der hvor tagging forekommer, kan taggede data være av interesse for administratorer, forskere og forretningsfolk. Videre kan tagger brukes i forskjellige typer av tilbakemeldingssløyfer. Når det gjelder administratorer, kan dataadministratorer trenge å lagre korrekt taggede data. Angående forskere, kan de trenge å vite hvilke data som forretningsfolk er avhengig av. Når det gjelder forretningsfolk, kan det trenge å vite når data oppdateres og at den har integritet.

[0067]Som her beskrevet, et system kan være konfigurert til å tillate en bruker å definere en mal via et domenespesifikt språk, for å instantiere malen i en geovitenskap-pakke, og linke til data på en måte som involverer tagging av data som en geovitenskap-pakke er avhengig av (eksempelvis for å sørge for assosia-sjoner med underliggende fysiske data). Et slikt system kan valgfritt være konfigurert til å kjøre en maldefinert prosess over tid for å se om utgangsdataene forandres over tid. I forskjellige eksempler kan et system kjøre automatisk som respons på en trigger. For eksempel, nye data eller reviderte data som blir lagret i en lagringslokalisering kan forårsake at en trigger krever aksess til én eller flere forretningsprosess-maler og instantiering av disse malene ved bruk av de nye eller reviderte data. Der hvor et resultat er forskjellig kan en e-post eller annen kommunikasjon sendes til en bruker tilknyttet en tidligere forretningsprosess-kjøring for å underrette denne brukeren om at omstendigheten har blitt forandret på en måte hvor resultatet av forretningsprosessen er forskjellig. I et slikt eksempel kan en bruker være i stand til å sette én eller flere parametere angående hvilken type av forskjell som vil være tilstrekkelig til utsendelse av melding (eksempelvis +10%, -10% eller +/-10%).

[0068]Som her beskrevet, ett eller flere datamaskin-lesbare media kan inkludere datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å mate ut informasjon for styring av en prosess. For eksempel kan slike instruksjoner sørge for utmating til en avfølingsprosess, en injeksjonsprosess, en boreprosess, en utvinningsprosess, osv.

[0069]Figur 9 viser komponenter i et databehandlingssystem 900 og et nettverkssystem 910. Systemet 900 inkluderer én eller flere prosessorer 902, et minne og/eller lagringskomponenter 904, én eller flere inngangs- og/eller utgangsinnretninger 906 og en buss 908. Som her beskrevet, instruksjoner kan være lagret i ett eller flere datamaskin-lesbare media (eksempelvis minne/lagringskomponenter 904). Slike instruksjoner kan leses av én eller flere prosessorer (eksempelvis prosessoren(e) 902) via en kommunikasjonsbuss (eksempelvis bussen 908), som kan være ledningsført eller trådløs. Den ene eller de flere prosessorer kan utføre slike instruksjoner for å implementere (fullstendig eller delvis) én eller flere attributter (eksempelvis som del av en fremgangsmåte). En bruker kan betrakte utgangsdata fra og samhandle med en prosess via en l/O-innretning (eksempelvis innretningen 906). Som her beskrevet, et datamaskin-lesbart medium kan være en lagringskomponent så som en fysisk minnelagrings-innretning, for eksempel, en chip, en chip på en pakke, et minnekort, osv.

[0070]Som her beskrevet, komponenter kan være fordelt, så som i nettverkssystemet 910. Nettverkssystemet 910 inkluderer komponenter 922-1, 922-2, 922-3,...922-N. For eksempel kan komponentene 922-1 inkludere prosessoren(e) 902, mens komponenten(e) 922-3 kan inkludere minne tilgjengelig for prosessoren(e) 902. Videre kan komponenten(e) 902-2 inkludere en l/O-innretning for visning og valgfri interaksjon med en fremgangsmåte. Nettverket kan være eller inkludere internett, et intranett, et cellenettverk, et satellittnettverk, osv.

KONKLUSJON

[0071]Selv om forskjellige fremgangsmåter, innretninger, systemer, osv. har blitt beskrevet i språk spesifikt for strukturelle trekk og metodologiske handlinger, skal det forstås at den gjenstand som er definert i de vedføyde krav ikke nødvendigvis er begrenset til de spesifikke trekk eller handlinger som er beskrevet. Snarere er de spesifikke trekk og handlinger offentliggjort som eksempler på former for implementering av de fremgangsmåter, innretninger, systemer, osv. som det kreves beskyttelse for.

Claims (20)

1. Ett eller flere datamaskin-lesbare media omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å: aksessere en mal; instantiere malen for en realisering av en datadrevet applikasjon; gjennomføre en analyse definert av malen, hvor analysen er avhengig av linking til i det minste noen data som den datadrevne applikasjon er avhengig av; og mate ut informasjon basert i det minste delvis på analysen.

2. Ett eller flere datamaskin-lesbare media som angitt i krav 1, videre omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å instantiere malen ved tolking av setninger skrevet i et domene-spesifikt språk.

3. Ett eller flere datamaskin-lesbare media som angitt i krav 1, videre omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å tagge data som den datadrevne applikasjon er avhengig av.

4. Ett eller flere datamaskin-lesbare media som angitt i krav 1, videre omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å gjengi et grafisk brukergrensesnitt med et grafisk kontrollelement for seleksjon av en entitet i den datadrevne applikasjon.

5. Ett eller flere datamaskin-lesbare media som angitt i krav 4, videre omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å motta en seleksjonskommando for seleksjon av en entitet.

6. Ett eller flere datamaskin-lesbare media som angitt i krav 1, hvor den datadrevne applikasjon omfatter en geovitenskap-applikasjon.

7. Ett eller flere datamaskin-lesbare media som angitt i krav 1, hvor malen omfatter en mal uttrykt i et domene-spesifikt språk.

8. Ett eller flere datamaskin-lesbare media som angitt i krav 1, hvor den datadrevne applikasjon omfatter en geovitenskap-applikasjon for modellering av et reservoar, og hvor malen definerer en forretningsmetode eller -prosess som inkluderer analysen som en indikator for økonomisk gjennomførbarhet av et reservoar.

9. Ett eller flere datamaskin-lesbare media som angitt i krav 8, hvor indika-toren for økonomisk gjennomførbarhet omfatter en sjanse for suksess eller fiasko.

10. Fremgangsmåte, omfattende: aksessering av en mal; instantiering av malen for en realisering av en datadrevet applikasjon; gjennomføring av en analyse definert av malen, hvor analysen er avhengig av linking til i det minste noen data som den datadrevne applikasjon er avhengig av; og utmating av informasjon basert i det minste delvis på analysen.

11. Fremgangsmåte som angitt i krav 10, hvor linkingen omfatter tagging av i det minste noen av dataene med tagger.

12. Fremgangsmåte som angitt i krav 11, videre omfattende lagring av taggene.

13. Fremgangsmåte som angitt i krav 12, videre omfattende gjennomføring av en gransking av analysen basert i det minste delvis på én eller flere lagrede tagger.

14. Fremgangsmåte som angitt i krav 11, hvor malen definerer en forretningsmetode eller -prosess.

15. Fremgangsmåte som angitt i krav 14, videre omfattende styring av taggede data med hensyn på versjoner av dataene.

16. Fremgangsmåte som angitt i krav 10, videre omfattende administrering av lagring av data basert i det minste delvis på linkingen.

17. Ett eller flere datamaskin-lesbare media omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å: velge ut en entitet i en geovitenskap-applikasjon; tagge entiteten som å være tilknyttet en forretningsmetode eller -prosess; aksessere informasjon tilknyttet den taggede entitet; og beregne en metrikk definert av forretningsmetoden eller prosessen basert i det minste delvis på informasjon.

18. Ett eller flere datamaskin-lesbare media som angitt i krav 17, videre omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å velge ut entiteten basert i det minste delvis på instantiering av en mal som definerer forretningsmetoden eller -prosessen.

19. Ett eller flere datamaskin-lesbare media som angitt i krav 17, hvor metrikken omfatter en sjanse for suksess.

20. Ett eller flere datamaskin-lesbare media som angitt i krav 17, videre omfattende datamaskin-utførbare instruksjoner for å instruere et databehandlingssystem til å lagre taggen.