NO342542B1 - Sanntids, bidireksonal dataforvaltning - Google Patents

Abstract

Et eksempel på fremgangsmåte for sanntids, bidireksjonal dataforvaltning omfatter det å motta en liste som beskriver ønskede data fra en feltapplikasjon, motta en liste som beskriver tilgjengelige data fra en datakilde, og abonnere på tilgjengelige data ved å avbilde den tilgjengelige data-beskrivelseslisten til den ønskede data-beskrivelseslisten, der de tilgjengelige dataene har et første dataformat og en første kommunikasjonsprotokoll og omfatter en første kontekstidentifikator for å identifisere en del av data. Fremgangsmåten omfatter videre det å modifisere de tilgjengelige dataene til å ha et andre dataformat og en andre kommunikasjonsprotokoll, der de modifiserte dataene omfatter den første kontekstidentifikatoren, og utføre en feltoperasjon basert på de første modifiserte dataene for å generere behandlede data, der de behandlede dataene omfatter den første kontekstidentifikatoren. Fremgangsmåten omfatter videre det å modifisere de behandlede dataene for å generere andre modifiserte data med det første dataformatet og den første protokollen, der de andre modifiserte dataene lagres i datakilden.

Description

BAKGRUNN

[0001] Operasjoner, så som kartlegging, boring, kabelført testing, komplettering, produksjon, planlegging og feltanalyse, blir typisk utført for å lokalisere og utvinne verdifulle brønnfluider. Kartlegging blir ofte utført med bruk av akkvisisjonsmetoder, så som seismiske avsøkere eller kartleggingsenheter, for å generere avbildninger av undergrunnsformasjoner. Disse formasjonene blir ofte analysert for å bestemme forekomst av verdier i undergrunnen, så som verdifulle fluider eller mineraler, eller for å avgjøre om formasjonene har egenskaper egnet for lagring av fluider.

[0002] Under bore- og produksjonsoperasjoner blir data typisk samlet inn for analyse og/eller overvåkning av operasjonene. Slike data kan for eksempel omfatte informasjon vedrørende undergrunnsformasjoner og utstyr samt historiske og/eller andre data.

[0003] Data vedrørende undergrunnsformasjonen blir samlet inn med bruk av en rekke forskjellige kilder. Slike formasjonsdata kan være statiske eller dynamiske. Statiske data vedrører for eksempel formasjonsstruktur og geologisk stratigrafi som definerer geologiske strukturer i undergrunnsformasjonen. Dynamiske data vedrører for eksempel fluider som strømmer gjennom de geologiske strukturene i undergrunnsformasjonen over tid. Slike statiske og/eller dynamiske data kan bli samlet inn for å finne ut mer om formasjonene og verdiene inneholdt i disse. Bakgrunnsteknikk omfatter US 2006/0290528 som beskriver en bidireksjonal telemetrianordning og fremgangsmåte derav for brønnoperasjoner, US 2004/0231851 som beskriver et trådløst brønnkommunikasjonssystem og fremgangsmåte derav, og US 6,519,568 som beskriver et system og en fremgangsmåte for elektronisk datalevering.

OPPSUMMERING

[0004] Et eksempel på fremgangsmåte for sanntids, bidireksjonal dataforvaltning omfatter det å motta liste som beskriver ønskede data fra en feltapplikasjon knyttet til et boresystem som utfører en boreoperasjon, motta en liste som beskriver tilgjengelige data fra en datakilde, og abonnere på tilgjengelige data ved å avbilde tilgjengelige databeskrivelseslisten til ønskede data-beskrivelseslisten, der de tilgjengelige dataene har et første dataformat og en første kommunikasjonsprotokoll knyttet til datakilden og omfatter en første kontekstidentifikator tildelt av datakilden for å identifisere en del av de tilgjengelige dataene. Fremgangsmåten omfatter videre det å modifisere de tilgjengelige dataene for å generere første modifiserte data med et andre dataformat og en andre kommunikasjonsprotokoll for overføring til feltapplikasjonen, der de første modifiserte dataene omfatter den første kontekstidentifikatoren for å identifisere en del av de første modifiserte dataene, og selektivt å utføre en boreoperasjon basert på de første modifiserte dataene for å generere behandlede data ved feltapplikasjonen, der de behandlede dataene omfatter den første kontekstidentifikatoren for å identifisere en del av de behandlede dataene. Fremgangsmåten omfatter videre det å modifisere de behandlede dataene for å generere andre modifiserte data med det første dataformatet og den første kommunikasjonsprotokollen, der de andre modifiserte dataene lagres i datakilden. Et eksempel på system for å fremskaffe feltdata gjennom sanntids, bidireksjonal dataforvaltning omfatter et applikasjonsprogrammeringsgrensesnitt innrettet for å motta en liste som beskriver ønskede data fra en feltapplikasjon knyttet til et boresystem tilpasset til å utføre en boreoperasjon. Der den ønskede databeskrivelseslisten vedrører til en første datakanal knyttet til datakilden. Abonnere, basert på en liste som beskriver tilgjengelige data, på tilgjengelige data fra den første datakanalen, der de tilgjengelige dataene omfatter en første datalogg og en andre datalogg vedrørende de flere boreverktøykjøringene, der den andre dataloggen er merket med en andre kontekstidentifikator. Systemet videre omfatter et dataadapter innrettet for å motta tilgjengelige data-beskrivelseslisten fra datakilden. Der den tilgjengelige data-beskrivelseslisten vedrører flere boreverktøykjøringer, der en boreverktøykjøring av de flere boreverktøykjøringene har ett eller flere boreverktøypass, der et boreverktøypass av det ene eller de flere boreverktøypassene genererer den første dataloggen vedrørende den første datakanalen, der den første dataloggen er merket med en første kontekstidentifikator. Systemet videre omfatter å formatere tilgjengelige data basert på den første kontekstidentifikatoren og den andre kontekstidentifikatoren for å generere første modifiserte data for avsending til feltapplikasjonen, hvor boreoperasjonen blir utført av feltapplikasjonen basert på de første modifiserte dataene. Et eksempel på datamaskinlesbart medium, som innlemmer instruksjoner som kan eksekveres av en datamaskin for å utføre fremgangsmåtetrinn for å fremskaffe feltdata gjennom sanntids, bidireksjonal dataforvaltning, der instruksjonene omfatter funksjonalitet for å motta en liste som beskriver ønskede data fra en feltapplikasjon knyttet til et boresystem tilpasset til å utføre en boreoperasjon. Der den ønskede data-beskrivelseslisten vedrører flere datakanaler forbundet med en datakilde. Videre omfattende å spørre datakilden basert på ønskede data-beskrivelseslisten med bruk av en flerkanal-spørring, der flerkanal-spørringen vedrører de flere datakanalene. Videre omfattende å motta en liste som beskriver tilgjengelige data fra datakilden, der tilgjengelige data-beskrivelseslisten vedrører minst én datakanal av de flere datakanalene. Abonnere, basert på tilgjengelige data-beskrivelseslisten, på tilgjengelige data fra den minst ene datakanalen, der de tilgjengelige dataene har et første dataformat og en første kommunikasjonsprotokoll. Modifisere de tilgjengelige dataene for å generere første modifiserte data med et andre dataformat og en andre kommunikasjonsprotokoll for avsending til feltapplikasjonen. Selektivt justere boreoperasjonen ved feltapplikasjonen basert på de første modifiserte dataene.

[0005] Andre aspekter ved oppfinnelsens idéer vil tydeliggjøres av den følgende beskrivelsen og de vedføyde kravene.

KORT BESKRIVELSE AV FIGURENE

[0006] For at de ovenfor angitte trekk ved sanntids, bidireksjonal dataforvaltning skal forstås i detalj, er en mer detaljert beskrivelse av sanntids, bidireksjonal dataforvaltning, som kort oppsummert over, gitt under henvisning til utførelsesformene av dette som er illustrert i de vedlagte figurene. Det skal imidlertid bemerkes at de vedlagte figurene kun illustrerer typiske utførelsesformer, og derfor ikke skal forstås som en begrensning av oppfinnelsens ramme, ettersom sanntids, bidireksjonal dataforvaltning kan realiseres i andre like virkningsfulle utførelser.

[0007] Figurene 1.1-1.4 er en skjematisk skisse av et felt med undergrunnsstrukturer som inneholder reservoarer, mens forskjellige operasjoner blir utført på feltet.

[0008] Figur 2 er en skjematisk skisse, delvis i tverrsnitt, av en boreoperasjon på et brønnsted.

[0009] Figur 3.1 er et skjematisk diagram som viser et rammeverk for å støtte sanntids dataprosesser i en boreoperasjon.

[0010] Figur 3.2 er et skjematisk diagram som viser en sanntids dataprosess i en boreoperasjon.

[0011] Figur 4 er et dybdediagram som viser flere boreverktøypass i en boreverktøykjøring i en boreoperasjon.

[0012] Figur 5 er et skjematisk diagram som viser en sanntids dataprosess i en boreoperasjon.

[0013] Figur 6 er et flytdiagram som illustrerer en fremgangsmåte ved en sanntids dataprosess i en boreoperasjon.

DETALJERT BESKRIVELSE

[0014] Konkrete utførelsesformer vil nå bli beskrevet i detalj under henvisning til de vedlagte figurene. Like elementer i de forskjellige figurene er angitt med like referansenummer for å bedre oversikten.

[0015] I den følgende detaljerte beskrivelsen er en rekke spesifikke detaljer beskrevet for å gi en mer gjennomgående forståelse. I andre tilfeller er velkjente trekk ikke beskrevet i detalj for å unngå å vanskeliggjøre forståelsen av utførelsesformer av sanntids, bidireksjonal dataforvaltning.

[0016] Generelt tilveiebringer utførelsesformer av sanntids, bidireksjonal dataforvaltning en fremgangsmåte og et system for å frembringe feltdata. Mer spesifikt omfatter bruk av sanntids, bidireksjonal dataforvaltning, blant annet, leseoperasjoner og tilbakeskrivingsoperasjoner for en rekke forskjellige feltapplikasjoner (f.eks. datainnsamlingssystemer, teknisk analyse, sanntids overvåkning, dataformidlingstjeneste og andre anvendelsesområder på oljefelter) basert på en rekke forskjellige datakilder for feltoperasjoner, så som databasesystemer, filsystemer, webtjenester, peer-applikasjoner, multi-pass-kilder, abonneringstjenester og andre datakilder. I noen utførelsesformer betrakter sanntids dataprosesser for feltdata kontekstinformasjon (f.eks. borehullsnavn, boreverktøykjøring-nummer, etc.) gjennom en leseoperasjon etterfulgt av en tilbakeskrivingsoperasjon med modifisering av data i den innblandede feltapplikasjonen.

[0017] I noen utførelsesformer av oppfinnelsen er videre sanntids dataprosesser i stand til å be om flere datakanaler i én enkelt operasjon og behandle datalogger fra flere boreverktøykjøringer og tilhørende boreverktøypass. I tillegg kan utveksling av feltdata ytelsesoptimeres for å redusere dataoverføringer og også for å styre systembelastningen i både datakildene og feltapplikasjonene. Sanntidsdataprosessene kan muliggjøre, men er ikke begrenset til, én eller flere av følgende: effektiv transparent tilbakeskriving, tilbakeskriving til flere steder, persistent lagring av tilbakeskrivingsbufre, publisering av data tilbake til datakilden, effektiv avlesning av flere datakanaler samtidig, tilgang til data fra flere operasjoner, forsyning av kontekstinformasjon til applikasjonen og reflektering av applikasjonskonteksten i brukergrensesnittet, forsyning av detaljert kontekstinformasjon tilbake til applikasjonen, transformering av spørringer og responser basert på en valgt kilde uten at det er nødvendig med en ny adapter, bruk av transformasjonene i en konfigurerbar pipeline som gir gjenbruk og modularisering av maler, spesifisering av et globalt startpunkt og endepunkt for å styre datastrømmen, etc.

[0018] Figurene 1.1-1.4 viser forenklede, representative skjematiske skisser av et felt (100) med en undergrunnsformasjon (102) som inneholder et reservoar (104), og viser forskjellige feltoperasjoner som utføres på feltet (100). Figur 1.1 viser en kartleggingsoperasjon som utføres av et undersøkelsesverktøy, så som en seismikkbil (106.1), for å måle egenskaper ved undergrunnsformasjonen. Kartleggingsoperasjonen er en seismisk kartleggingsoperasjon for å generere lydvibrasjoner (112). I figur 1.1 blir én slik lydvibrasjon (112) generert av en kilde (110) og reflekteres av flere horisonter (114) i en underjordisk formasjon (116). Lydvibrasjonen(e) (112) mottas av følere (S), for eksempel geofonmottakere (118), anordnet på jordens overflate, og geofonmottakerne (118) genererer elektriske utsignaler, referert til som data mottatt (120) i figur 1. De mottatte dataene (120) blir forsynt som inndata til en datamaskin (122a) i seismikkbilen (106.1), og som reaksjon på inndataene genererer datamaskinen (122a) en seismisk datautmatingsjournal (124).

[0019] Figur 1.2 viser en boreoperasjon som utføres av boreverktøy (106.2) som er opphengt fra en rigg (128) og drives innover i undergrunnsformasjonene (102) for å danne en brønnboring (136). En slamtank (130) anvendes for å trekke inn boreslam i boreverktøyene (106.2) via et strømningsrør (132) for sirkulering av boreslam gjennom boreverktøyene (106.2), opp brønnboringen og tilbake til overflaten. Boreverktøyene (106.2) drives innover i undergrunnsformasjonene for å komme til reservoaret (104). Hver brønn kan ha ett eller flere reservoarer som mål. Boreverktøyene (106.2) kan være innrettet for å måle nedihullsegenskaper med bruk av logging-under-boring-verktøy. Logging-under-boring-verktøyet (106.2) kan også være innrettet for å ta en kjerneprøve (133) som vist, eller bli fjernet slik at en kjerneprøve (133) kan tas med bruk av et annet verktøy.

[0020] En overflateenhet (134) anvendes for å kommunisere med boreverktøyene (106.2) og/eller virksomhet utenfor feltet. Overflateenheten (134) er i stand til å kommunisere med boreverktøyene (106.2) for å sende kommandoer til boreverktøyene og for å motta data fra disse. Overflateenheten (134) samler inn data generert under boreoperasjonen og genererer utdata (135) som kan bli lagret eller sendt ut. Dataanordninger kan være utplassert på forskjellige steder rundt om på feltet (100) (f.eks. overflateenheten (134)) og/eller på fjerne steder.

[0021] Følere (S), for eksempel måleinstrumenter, kan være utplassert rundt om på feltet for å samle inn data vedrørende forskjellige feltoperasjoner. Som vist er følere (S) utplassert på ett eller flere steder i boreverktøyene og/eller på riggen for å måle boreparametre, så som borekronetrykk, borekronemoment, trykk, temperaturer, strømningsmengder, sammensetninger, rotasjonshastighet og/eller andre parametere knyttet til feltoperasjonen. Følere kan også være utplassert på ett eller flere steder i sirkuleringssystemet.

[0022] Dataene innhentet av følerne (S) kan bli samlet inn av overflateenheten (134) og/eller andre datainnsamlingskilder for analyse eller annen behandling. Dataene kan være historiske data, sanntidsdata eller kombinasjoner av dette. Sanntidsdataene kan bli anvendt i sanntid eller lagret for senere bruk. Dataene kan også bli kombinert med historiske data eller andre innmatinger for ytterligere analyse. Dataene kan bli lagret i separate databaser, eller samlet i én enkelt database.

[0023] Datautmatinger fra de forskjellige følerne (S) utplassert rundt om på feltet kan bli behandlet for bruk. Dataene kan være historiske data, sanntidsdata eller kombinasjoner av dette. Sanntidsdataene kan bli anvendt i sanntid eller lagret for senere bruk. Dataene kan også bli kombinert med historiske data eller andre innmatinger for ytterligere analyse. Dataene kan bli lagret i separate databaser, eller samlet i én enkelt database.

[0024] Figur 1.3 viser en kabeloperasjon som utføres av et kabelført verktøy (106.3) opphengt fra riggen (128) og inn i brønnboringen (136) i figur 1.2. Det kabelførte verktøyet (106.3) er innrettet for innsetting i en brønnboring (136) for å generere brønnlogger, foreta brønntester og/eller innhente prøver. Det kabelførte verktøyet (106.3) kan anvendes som en annen metode og anordning for å utføre en seismisk kartleggingsoperasjon. Det kabelførte verktøyet (106.3) i figur 1.3 kan for eksempel innbefatte en eksplosiv, radioaktiv, elektrisk eller akustisk energikilde (144) som sender ut og/eller mottar elektriske signaler til/fra de omkringliggende undergrunnsformasjonene (102) og fluider i disse.

[0025] Følere (S), for eksempel måleinstrumenter, kan være anordnet rundt om på feltet (100) for å samle inn data vedrørende forskjellige feltoperasjoner som beskrevet over. Som vist er føleren S anordnet i det kabelførte verktøyet for å måle brønnparametere, for eksempel vedrørende porøsitet, permeabilitet, fluidsammensetning og/eller andre parametre i feltoperasjonen.

[0026] Figur 1.4 viser en produksjonsoperasjon som utføres av et produksjonsverktøy (106.4) innsatt fra en produksjonsenhet eller et ventiltre (129) i den kompletterte brønnboringen (136) i figur 1.3 for å trekke fluid fra nedihullsreservoarene til overflateanleggene (142). Fluid strømmer fra reservoaret (104), gjennom perforeringer i fôringsrøret (ikke vist) og inn i produksjonsverktøyet (106.4) i brønnboringen (136), og videre til overflateanleggene (142) via et samlenettverk (146).

[0027] Følere (S), for eksempel måleinstrumenter, kan være utplassert rundt om på feltet (100) for å samle inn data vedrørende forskjellige oljefeltoperasjoner som beskrevet over. Som vist kan føleren (S) være anordnet i produksjonsverktøyet (106.4) eller tilhørende utstyr, så som ventiltreet (129), samlenettverket (146), overflateanleggene (142) og/eller produksjonsanlegget, for å måle fluidparametre, så som fluidsammensetning, strømningsmengder, trykk, temperaturer og/eller andre parametere vedrørende produksjonsoperasjonen.

[0028] Selv om kun forenklede brønnsteder er vist, vil det forstås at feltet kan dekke områder på land, til havs og/eller over vann der det befinner seg ett eller flere brønnsteder. Produksjon kan også omfatte injeksjonsbrønner (ikke vist) for økt utvinning. Étt eller flere oppsamlingsanlegg kan være operativt forbundet med ett eller flere av brønnstedene for selektivt å samle inn brønnfluider fra brønnstedet/-stedene.

[0029] Selv om figurene 1.2-1.4 viser verktøy som anvendes for å måle egenskaper ved et felt (100), vil det forstås at verktøyene kan anvendes i forbindelse med operasjoner andre steder enn på brønnsteder, så som gruver, akvifere formasjoner, magasiner eller andre undergrunnsanlegg. Videre, selv om bestemte datainnsamlingsverktøy er vist, vil det forstås at forskjellige måleverktøy som er i stand til å avføle parametre, så som seismisk toveis gangtid, tetthet, resistivitet, produksjonsmengde, etc., i undergrunnsformasjonen og/eller dens geologiske formasjoner, vil kunne anvendes. Forskjellige følere (S) kan være anordnet i forskjellige posisjoner langs brønnboringen og/eller overvåkingsverktøyene for å samle inn og/eller overvåke ønskede data. Andre datakilder kan også være anordnet på fjerne steder.

[0030] Feltet i figurene 1.1-1.4 er vist for å gi en kort beskrivelse av et eksempel på felt som kan anvendes med sanntids dataprosesser. En del av, eller hele, feltet (100) kan befinne seg på land og/eller til sjøs. Videre, selv om ett enkelt felt beliggende på ett enkelt sted er vist, kan sanntids dataprosesser anvendes med en hvilken som helst kombinasjon av ett eller flere felter (100), ett eller flere behandlingsanlegg og ett eller flere brønnsteder.

[0031] Figur 2 viser en skjematisk skisse, delvis i tverrsnitt, av en boreoperasjon, så som boreoperasjonen i figur 1.2, på et felt i detalj. Brønnstedsystemet (400) omfatter et boresystem (311) og en overflateenhet (334). I den illustrerte utførelsesformen er et borehull (313) dannet ved rotasjonsboring på en måte som er velkjent. Fagmannen gitt denne beskrivelsen vil imidlertid forstå at sanntids dataprosesser også finner anvendelse i andre boremetoder enn tradisjonell rotasjonsboring (f.eks. slammotorbasert, retningsbestemt boring), og ikke er begrenset til landbaserte rigger.

[0032] Boresystemet (311) omfatter en borestreng (315) opphengt inne i borehullet (313) med en borekrone (310) i sin nedre ende. Boresystemet (311) omfatter også den landbaserte plattform- og boretårnenheten (312) anordnet over borehullet (313), som går gjennom en undergrunnsformasjon (F). Sammenstillingen (312) omfatter et rotasjonsbord (314), et rotasjonsrør (316), en krok (318) og en rotasjonssvivel (319). Borestrengen (315) blir rotert av rotasjonsbordet (314), drevet av en ikke vist anordning, som griper rotasjonsrøret (316) ved den øvre enden av borestrengen. Borestrengen (315) er opphengt fra kroken (318), festet til en løpeblokk (heller ikke vist), gjennom rotasjonsrøret (316) og en rotasjonssvivel (319) som muliggjør rotasjon av borestrengen i forhold til kroken.

[0033] Boresystemet (311) omfatter videre borefluid eller -slam (320) lagret i en slamtank (322) på brønnstedet. En pumpe (324) forsyner borefluidet (320) til innsiden av borestrengen (315) gjennom en port i svivelen (319), slik at borefluidet strømmer nedover gjennom borestrengen (315) som angitt av retningspilen (324). Borefluidet forlater borestrengen (315) gjennom porter i borekronen (310), og sirkulerer så oppover gjennom området mellom utsiden av borestrengen og borehullsveggen, kalt ringrommet (326). På denne måten smører borefluidet borekronen (310) og fører med seg borespon fra formasjonen opp til overflaten når det returnerer til tanken (322) for resirkulering.

[0034] Borestrengen (315) omfatter videre en bunnhullsenhet (BHA), referert til generelt som (330), nær ved borekronen (310) (med andre ord, innenfor noen vektrørlengder fra borekronen). Bunnhullsenheten (330) omfatter utstyr for måling, behandling og lagring av informasjon, og for kommunikasjon med overflateenheten. Bunnhullsenheten (330) omfatter videre vektrør (328) for å utføre forskjellige andre målefunksjoner.

[0035] Følere (S) er anordnet rundt om på brønnstedet for å samle inn data, i sanntid, vedrørende driften av brønnstedet, så vel som forhold ved brønnstedet. Følerne (S) i figur 2 kan være de samme som følerne i figurene 1.1-1.4.

[0036] Boresystemet (310) er operativt koblet til overflateenheten (334) for kommunikasjon med denne. Bunnhullsenheten (330) er utstyrt med en kommunikasjonsenhet (352) som kommuniserer med overflateenheten. Kommunikasjonsenheten (352) er innrettet for å sende signaler til og motta signaler fra overflaten ved hjelp av slampulstelemetri. Fagmannen vil forstå at en rekke forskjellige telemetrisystemer vil kunne anvendes, så som kablede borerør, elektromagnetiske eller andre kjente telemetrisystemer.

[0037] Brønnboringen blir typisk boret i henhold til en boreplan som er opprettet før boring. Boreplanen foreskriver typisk utstyr, trykk, borebaner og/eller andre parametere som definerer boreprosessen for brønnstedet. Boreoperasjonen kan da bli utført i henhold til boreplanen. Etter hvert som informasjon blir samlet inn vil imidlertid boreoperasjonen kunne måtte avvike fra boreplanen. I tillegg kan undergrunnsforholdene endre seg etter hvert som boring eller andre operasjoner blir utført. Grunnmodellen kan også bli korrigert etter hvert som ny informasjon blir hentet inn.

[0038] Figur 3.1 er et skjematisk diagram som viser et rammeverk (500) for å støtte sanntids dataprosesser i en boreoperasjon på et felt. Som vist i figur 3.1 omfatter sanntids-dataprosessene en leseoperasjon (552) og en tilbakeskrivingsoperasjon (551). Rammeverket (500) omfatter en middleware-anordning (501) og tilhørende metoder og programlagringsanordninger (og/eller lagringssteder) innrettet for å danne et grensesnitt mellom én eller flere datakilder (521) og én eller flere feltapplikasjoner (541) (eller andre programvareapplikasjoner). Den ene eller de flere datakildene (521) og den ene eller de flere feltapplikasjonene (541) (eller andre programvareapplikasjoner) mottar informasjon i form av data fra forskjellige kilder, omfattende et felt (553).

[0039] Middleware-anordningen (501) er i stand til å støtte sanntids dataprosesser, og kan være referert til som en sanntids datakobling (RTDL – Real-Time Data Link) i noen eksempler. En feltapplikasjon (541) kan være innrettet for å samvirke med RTDL-koblingen (501), og refereres til som en RTDL-bevisst programvareapplikasjon (her også kalt en RTDL-bevisst applikasjon). Basert på funksjonaliteten i RTDL-koblingen (501) kan hver programvareapplikasjon (541) omfatte et grafisk brukergrensesnitt (dvs. GUI) (511) for å motta data fra en hvilken som helst datakilde (521) uten at den trenger å være innrettet spesifikt for dataformatene og kommunikasjonsprotokollene for de mottatte dataene. Det grafiske brukergrensesnittet (511) kan bli vist for en bruker av den RTDL-bevisste feltapplikasjonen (541).

[0040] Som vist i figur 3.1 omfatter RTDL-koblingen (501) videre et applikasjonsprogrammeringsgrensesnitt (API) (509), dataadaptere (531), ønskede databeskrivelseslister (RDDL) (522), tilgjengelige data-beskrivelseslister (ADDL) (523), en tilbakeskrivingsmotor (503) og en dataekspederingsmotor (512).

[0041] API’et (509) kan omfatte ”public” metoder i RTDL-koblingen (501), som feltapplikasjonene (541) kan anrope. Disse public metodene i API’et (509) abstraherer mange forskjeller mellom sanntids-datakildene (521) og gir feltapplikasjonene (541) en ensartet måte å konsumere kildedata, som kan bli implementert i det grafiske brukergrensesnittet (511). Sett fra et brukerinteraksjonsperspektiv kan én eller flere av datakildene (521) velges gjennom det grafiske brukergrensesnittet (511) som er tilgjengelig via én av feltapplikasjonene (541), og så blir brukeren veiledet gjennom en sekvens av datakilde-spesifikke interaksjoner som fører til at de valgte dataene blir asynkront overført til applikasjonen. I denne prosessen tar dataadaptrene (531) seg av all kommunikasjon med datakildene (521), og skjuler således forskjellene i kommunikasjonsprotokollene fra feltapplikasjonene (541). Et adapter kan danne grensesnitt mot flere datakilder. De fleste datakilder kan være dynamiske og forsyne sanntidsdata til RTDL-koblingen (501), men RTDL-koblingen (501) kan også være utstyrt med funksjonalitet for å behandle lokale borejournaler med historiske data. For dynamiske datakilder kan RTDL-koblingen (501) videre være innrettet for å optimalisere vekselvirkninger med datakildene (521) for å redusere mengden dataoverføring og for å redusere systembelastningen i både datakildene (521) og feltapplikasjonene (541).

[0042] I én eller flere utførelsesformer optimaliserer RTDL-koblingen (501) vekselvirkninger med datakildene (541) ved å imøtekomme forsinkede kanaler (dvs. spredte eller vanskelig tilgjengelige feltdata). For eksempel kan forsinkede kanaler forekomme, men er ikke begrenset til, ved spørring av flere datakanaler som deler en felles indeks og minst én av datakanalene ikke spenner over hele indeksintervallet, når det er datagap for bestemte datakanaler mens andre er sanntidsdata, eller når et sent tilgjengelig databeskrivelsesvalg av brukeren forekommer under en utløpt sanntidssesjon. I dette tilfellet kan de forsinkede kanalene resultere i spørre-responser som omfatter overflødige data som tidligere er behandlet i sesjonen, noe som gjør at RTDL-koblingen (501) ikke opererer i sanntid fordi datakilder (541) kan begrense mengden data som returneres i hver spørring. RTDL-koblingen (501) kan være innrettet for å imøtekomme de forsinkede kanalene ved å utføre kontinuerlig forhåndsanalyse før spørring av ønskede datakanaler og dele inn datakanalene i uavhengige spørringsgrupper, som blir sendt som separate forespørsler. I dette tilfellet kan spørringsgruppen forbundet med de forsinkede kanalene gjentilslutte seg sanntidsspørringsgruppen når de forsinkede kanalene oppnår sanntid.

[0043] I én eller flere utførelsesformer optimaliserer RTDL-koblingen (501) vekselvirkninger med datakildene (541) basert på statusen for feltdata i datakildene (541). Eksempler på statuser for feltdata omfatter, men er ikke begrenset til inkrementelt økende, midlertidig stanset eller komplette (dvs. ingen ytterligere feltdata). RTDL-koblingen (501) kan innledningsvis bestemme som default at dataene fra hver datakilde (541) er økende. RTDL-koblingen (501) kan videre være innrettet for på forhånd å spørre etter et tidsstempel for datakildene (541) for å redusere forekomsten av unødvendige spørringer etter komplette feltdata. Når for eksempel feltdataene fra en gitt datakilde (541) er komplette, kan RTDL-koblingen (501) fastslå basert på et tidsstempel fra den aktuelle datakilden (541) at kontinuerlig spørring av den aktuelle datakilden (541) ikke lenger er nødvendig. I dette tilfellet, dersom feltdataene fra den aktuelle datakilden (541) på et senere tidspunkt økes, blir RTDL-koblingen (501) informert basert på tidsstempelet og kan gjenoppta spørring av den aktuelle datakilden (541) på normal måte.

[0044] Sekvensen av datakilde-spesifikke vekselvirkninger beskrevet over kan innlemmes i en rekke forskjellige arbeidsprosesser. For eksempel kan en ønskede data-beskrivelsesliste (RDDL) (522) bli forsynt av feltapplikasjonen (541) til RTDL-koblingen (501). En RDDL er et fleksibelt objekt som tilveiebringer et søkefilter for RTDL-koblingen (501) ved spørring av én eller flere datakilder (521) vedrørende tilgjengelige data. En RDDL (522) kan være med eller uten jokersymboler. Som følge av dette kan søkeresultater bli returnert fra spurte datakilder (521) i form av en tilgjengelige data-beskrivelsesliste (ADDL) (523). En bruker av feltapplikasjonene (541) kan da avbilde RDDL-listen og ADDL-listen for å matche tilgjengelige data med de innledende forespørslene. Et eksempel på ADDL (523) er beskrevet nærmere i forbindelse med figur 5 nedenfor. En funksjon kan også være tilgjengelig for automatisk å tilveiebringe RDDL-til-ADDL-avbildninger, uten å kreve brukerinteraksjon.

[0045] Videre omfatter RTDL-koblingen (501) også en tilbakeskrivingsmotor (503) og en dataekspederingsmotor (512). Tilbakeskrivingsmotoren (503) er innrettet for å tilveiebringe funksjonalitet for å publisere data tilbake til datakildene (521). Dataekspederingsmotoren er innrettet for å forsyne kontekstinformasjon til applikasjonen. API’et kan også anvendes for å reflektere applikasjonskonteksten innenfor det grafiske brukergrensesnittet (511). RTDL-koblingen (501) kan også være utstyrt med funksjonalitet for å transformere spørringer og responser basert på en valgt kilde, lese flere datakanaler samtidig, gi tilgang til data fra flere operasjoner, etc. Flere detaljer ved denne funksjonaliteten er beskrevet i forbindelse med figurene 5.2 og 7 nedenfor. Feltapplikasjoner og brukere kan anvende rammeverket (500) for å spesifisere globale start- og sluttpunkter for å styre sanntidsdataprosessen.

[0046] Figur 3.2 er et skjematisk diagram som viser en sanntids dataprosess (550) i en boreoperasjon på et felt (553). Sanntids-dataprosessen (550) utføres med bruk av RTDL-koblingen (550), som er hovedsaklig den samme som RTDL-koblingen (501) i figur 3.1. RTDL-koblingen (550) vist i figur 3.2 omfatter ytterligere detalj, for eksempel dataadaptere (531.1)-(531.6), en tilbakeskrivingsmotor (med kontekst) (503), dataskrivingskø (507), en loggbehandlingsmodul (504) med en spørringsklargjøringsmotor (505) og en responsbehandlingsmotor (506), en datalesingskø (508), et API (509) og en dataekspederingsmotor (med kontekst) (512)).

[0049] Som vist i figur 3.2 kan én eller flere datakilder (521) i figur 3.1 omfatte et databasesystem (521.1), en webtjeneste (521.2), en RTDL-bevisst peerapplikasjon (521.3), en multi-pass-kilde (521.4), et filsystem (521.5), en abonneringstjeneste (521.6) eller andre feltdatakilder. Hver av disse sanntids datakildene (521) kan være koblet til et gitt dataadapter, så som dataadaptre (531.1)-(531.6). For eksempel kan dataadaptrene omfatte funksjonalitet for å kommunisere med WITSML-(Wellsite Information Transfer Standard Markup Language)-API-Tjenere, kommunisere med boreakkvisisjonssystemer, konsumere sanntids borejournaler publisert på en tjener, konsumere journaler registrert av en RTDL-registreringsverktøy (f.eks. et test- og simuleringsverktøy), etc. Selv om det ikke er vist i figur 3.2 kan hver adaptertype ha et tilhørende sett av én eller flere datakilder (521). Hver datakilde (521) kan være representert av en XML-konfigurasjon, som omfatter referanser til de forskjellige adaptermetodene. I noen tilfeller kan en underklasse avledes fra et adapter for å tilveiebringe spesialoppførsel nødvendig for en datakilde. For eksempel kan kildespesifikk oppførselsdifferensiering være reflektert i XSL-(eXtensible Style-sheet Language)-transformasjoner av forespørsels- og responsmeldinger for WITSML-API-tjenerne.

[0048] Dataadaptrene (531) beskrevet over kan være innrettet for å transformere data fra én eller flere datakilder (521) basert på kravene til en feltapplikasjon (541). Her kan dataadaptrene (531) anvende transformasjonsskript for å transformere dataene fra datakildene (521). Transformasjonsskriptene kan være modulære slik at felles transformasjoner kan deles mellom flere dataadaptere (531) og datakilder (521) (dvs. en transformasjonspipeline). For eksempel kan flere datakilder (521) omfatte tilsvarende datatyper; følgelig kan de tilhørende dataadaptrene (531) ha behov for en felles transformasjon for i hvert fall en del av de tilsvarende datatyp ene. I dette tilfellet kan hvert dataadapter (531) også anvende ytterligere transformasjoner som er spesifikke for andre datakilder (521) forbundet med dataadaptrene (531). Fagmannen vil forstå at modulariseringen av transformasjonsskript letter kombinasjon av gjenbrukelige, leverandørnøytrale transformasjonsskript og leverandørspesifikke transformasjonsskript.

[0049] I tillegg kan feltapplikasjonene (541) (som også vist i figur 3.1) omfatte et akkvisisjonssystem (541.1), teknisk analyse (541.2), sanntids-overvåking (541.3), dataformidlingstjenester (541.4) eller andre applikasjonstyper (541.5). Akkvisisjonssystemet (541.1) kan være “write only” i den forstand at det kun utfører tilbakeskrivingsoperasjonen (551 i figur 3.1) uten å utføre leseoperasjoner (552 i figur 3.1). Sanntids-overvåkningen (541.3) og dataformidlingstjenestene kan være ”read only” i den forstand at de kun utfører leseoperasjoner (552 i figur 3.1) uten å utføre tilbakeskrivingsoperasjoner (551 i figur 3.1). Teknisk analyse (541.2) kan være ”read-write” i den forstand at leste data fra én av datakildene (521) kan bli modifisert, korrigert eller på annen måte behandlet av teknisk analyse (541.2) og deretter skrevet tilbake til datakilden(e) (521). I noen eksempler kan feltapplikasjonen være multikoblet i den forstand at den kan lese fra én datakilde mens den skriver tilbake til en annen datakilde. En feltapplikasjon kan samtidig være koblet til to eller flere RTDL-instanser som hver har sin egen distinkte datakilde. Den første RTDL-instansen kan anvendes for å lese data, mens den andre RTDL-instansen kan anvendes for tilbakeskriving av data. En multikoblet feltapplikasjon kan for eksempel anvendes for å muliggjøre korrelasjon mellom forskjellige brønner, eller ensarte uensartede data fra flere datakilder.

[0050] Én eller flere av datakildene (521.1)-(521.6) kan tilveiebringe mange forskjellige typer data, så som datalogger, borebaner, risikoer, meldinger, borehullsgeometrier (wbGeometry), rørdeler, operasjonsrapporter (opsReport), etc. Hver datatype kan være formatert på forskjellig måte. For eksempel kan en datalogg være formatert som et trasediagram, en regneark-liknende tabell eller ha andre passende formater. Her kan en brønnlogg representere resistivitet eller andre målinger tatt av et kabelført verktøy på forskjellige dyp som et dybdeindeksert trasediagram. En datalogg kan også være tidsindeksert, og for eksempel inneholde kroklastmålinger for forskjellige tidspunkter. En datalogg kan videre omfatte data fra flere datakanaler svarende til flere følere tilknyttet en datakilde. For eksempel kan en datalogg med et tabellformat omfatte flere kolonner med datakanaler og flere rader med data tatt ved forskjellige dyp eller tidspunkter. Hver punktoppføring vedrørende en gitt datakanal ved et gitt dyp eller tidspunkt refereres til som et datapunkt. Én enkelt rad av datapunkter som inneholder data vedrørende flere datakanaler tatt ved en felles indeksverdi refereres til som en vektor av datapunkter, eller en ”pseudo-dataramme”. Data vist i datakøene (507) og (508) kan representere datapunkter eller vektorer av datapunkter. Datakøene (507) og (508) kan også inneholde mer sammensatte datastrukturer, så som borebane- eller risikodata.

[0051] Data kan også bli tagget med kontekstinformasjon. Kontekstinformasjon kan omfatte attributter for å identifisere en datakilde, så som brønnavn (WellName), brønn-ID (WellID), borehullsnavn (WellboreName), borehulls-ID (WellboreID), seksjonsnavn (SectionName), delseksjonsnavn (SubSectionName), etc. Kontekstinformasjon kan også omfatte attributter for å identifisere datasamlingsparametre, så som loggnavn, logg-ID, kjøringsnummer, pass-nummer, passtype, etc. Videre kan detaljert informasjon om logger, kanaler og ADDL-listen (623 i figur 3.1) være tilgjengelig gjennom API’et (509).

[0052] Som også er vist i figur 3.2 kan tilbakeskrivingsmotoren (503) jobbe på data fra en datakø (507), lagt inn i køen gjennom API’et (509) fra feltapplikasjonen (541.1)-(541.5). Tilbakeskrivingsmotoren (503) kan være innrettet for å utføre flere funksjoner, som er beskrevet nedenfor. Innenfor sanntids-dataprosessene (550) kan feltapplikasjonene (541.1)-(541.5) spesifisere destinasjonen (eller målet) for tilbakeskrivingsoperasjonen (551 i figur 3.1)), men konteksten kan bli tilknyttet senere. For eksempel kan et tilbakeskrivingsanrop i API’et (509) omfatte et loggnavn og en logg-ID som et mål, men WellName, WellID, WellboreName og WellboreID kan bli bestemt og påført etter at en forbindelse til datakilden er opprettet før skriving, som er meningen med betegnelsen “med kontekst” i figur 3.2. Tilbakeskrivingsmotoren (503) kan støtte to mulige operasjoner, nemlig en ”legg til-forespørsel” for å legge til et nytt dataobjekt på datakilden og en ”oppdaterforespørsel” for å oppdatere et eksisterende dataobjekt på datakilden. Operasjonene (legg til eller oppdater) er usynlige for feltapplikasjonene (541.1)-(541.5). En ”legg til-forespørsel” kan bli sendt først, og dersom denne feiler fordi dataobjektet allerede eksisterer, kan alle fremtidige forespørsler bli konvertert til ”oppdateringsforespørsler” av tilbakeskrivingsmotoren (503).

[0053] I én eller flere utførelsesformer kan tilbakeskrivingsmotoren (503) være innrettet for å behandle generiske, leverandørnøytrale skriveforespørsler for forskjellige leverandørspesifikke datakilder (521.1)-(521.6). For eksempel kan tilbakeskrivingsmotoren (503) ta seg av ikke-standardiserte feilkoder returnert fra de forskjellige datakildene (521.1)-(521.6) når en feil oppstår. I dette tilfellet kan RTDL-koblingen (501) anvende en feilkode-normaliseringsmodell for å gjøre det mulig for tilbakeskrivingsmotoren (503) å håndtere feil fra forskjellige datakilder (521.1)-(521.6) på en ensartet måte.

[0054] Tilbakeskrivingsdata kan bli bufret i RTDL-koblingen (501) under styring av tilbakeskrivingsmotoren (503), slik at feltapplikasjonene (541.1)-(541.5) kan kjøre etter en ”fire and forget”-modell, dvs. at applikasjoner kan anvende tilbakeskrivings-API’et uten å måtte vente og se om operasjonene er umiddelbart vellykket. Følgelig trenger ikke feltapplikasjoner (541.1)-(541.5) tenke på administrering av forbindelsestilstanden til sanntids-dataprosessene. RTDL-koblingen (501) administrerer tilbakeskrivingsbufferet (507) for databufring under frakoblinger eller inntil tilbakeskrivingsoperasjonene er fullført med suksess. Databufringen kan bli utført i minne (ikke vist) og sikkerhetskopiert til disk (ikke vist). Statistikk over antall rader og tabeller i tilbakeskrivingsbufferet kan bli gjort tilgjengelig for feltapplikasjonene (541.1)-(541.5).

[0055] Eksempler på høynivå anrop for et ”RTDL.DataWriter”-objekt i RTDL-koblingen (501) er gitt i tabell 1 nedenfor.

TABELL 1

AddLogDataToCache – en datatabell (DataTable) av loggobjekter blir sendt;

AddRtdlDataObjectToCache – en ISurvey eller IRisk blir sendt; og AddWitsmlDocToCache – et komplett WITSML-dokument blir sendt, der Log-, Trajectory-, Risk-, WITSML-dokumenter er eksempler på forskjellige datatyper. Feltapplikasjonene kan anvende en egenskap WritableDataTypes i RTDL-koblingen (501) for dynamisk å sjekke hvilke WITSML-objekter en gitt datakilde støtter for skriving.

[0056] Uskrevne data i tilbakeskrivingsbufferet blir lagret til disk og lastet inn når RTDL-koblingen (501) starter opp. Dette sikrer mot tap av dataoppdateringer forårsaket av et systemkrasj. En konfigurasjonsegenskap, appUsageMode, kan settes til RO (read only), RW (read/write) eller WO (write only). Denne innstillingen kan påvirke oppførselen til RTDL-koblingen (501) og det grafiske brukergrensesnittet. Den kan settes dynamisk, eller settes i konfigurasjonsfilen for feltapplikasjonene (541.1)-(541.5). Tilbakeskrivinger kan bli satt opp forholdsvis hyppig, for eksempel hvert 5. sekund.

[0057] For eksempel kan anvendelser av tilbakeskrivingsoperasjonen (551) omfatte:

1. En applikasjon skriver tilbake indekserte loggdata, borebaner, risikoer, borehullsgeometrier, rørdeler, operasjonsrapporter, meldingsdata eller andre WITSML-objekttyper til en WITSML-datakilde;

2. En applikasjon skriver tilbake indekserte strengdata til en WITSML-datakilde; og 3. En applikasjon skriver data til en datakilde som den ikke leser fra (f.eks. et akkvisisjonssystem (541.1)).

[0058] Tabell 2 nedenfor omfatter et kodeeksempel for å illustrere, med en rekke detaljer utelatt, hvordan en applikasjon vil anvende tilbakeskrivingsfunksjonaliteten støttet av RTDL-koblingen (501).

TABELL 2

// Innledende oppsett

IDataLink2 rtdl = DataLink2Factory.CreateInstance();

IdataWriter m_WB = rtdl.DataWriter;

Rtdl.Connect();

// Én-gangs opprettelse av tabellen for å holde applikasjonens data

if (logDataTable == null)

{

// Opprett en datatabell for å holde dataene for 2 logg-kanaler som skal skrives ArrayList cols = ny ArrayList(2);

DataWriter.LogTableColumnDescriptor currentCol;

// Opprett en kolonne for poretrykk

currentCol = new DataWriter.LogTableColumnDescriptor(“PorePres”, typeof (Double), “psi”);

cols.Add(currentCol);

// Opprett en kolonne for bunnhullstemperatur

currentCol = new DataWriter.LogTableColumnDescriptor(“BhTemp”, typeof (Double), “deg”);

cols.Add(currentCol);

logDataTable = m_WB.CreateLogDataTableForWriting(eWbIndexedDataTypes.LogDepth, “ft”, cols);

}

// Den følgende koden vil bli kjørt hver gang data skal skrives. Eksempelet // viser tillegging av én rad, men flere rader kan bli lagt til.

DataRow r = m_LogDataTable.NewRow();

r[“index”] = 3012;

r[“PorePres”] = 8234.5;

r[“BhTemp”] = 247.2;

logDataTable.Rows.Add(r);

// Dette er det faktiske anropet for å legge til dataene i dataskriverens buffer, // hvor det holdes inntil tilbakeskrivingstråden kan sende det tilbake til

// kilden

m_WB.AddLogDataToCache(eWbIndexedDataTypes.LogTime, logDataTable, “Main Depth Log”, “Log-1234”);

// Etter vellykket bufring av dataene kan de bli fjernet fra applikasjonens tabell logDataTable.Clear();

[0059] Som også er vist i figur 3.2 kan spørringsklargjøringsmotoren (505) be om data ved å fremsette en spørring til datakilder (521.1)-(521.6). Spørringen kan bli fremsatt basert på RDDL-listen (622), som kan omfatte forespørsler vedrørende flere datakanaler. En betydelig ytelsesøkning kan oppnås ved å anvende flerkanalspørringer (MCQ – Multi-Channel Queries) om data fra datakilder, for eksempel en WITSML-API-tjener. I stedet for å be om én enkelt datakanal i en spørring til en datakilde, grupperer spørringsklargjøringsmotoren (505) en spørring om flere datakanaler til én enkelt forespørsel, noe som resulterer i et betydelig lavere antall forespørsler og responser og dermed reduserer den totale båndbredden og bedrer den generelle ytelsen. I en typisk boreoperasjon kan det å behandle dybdeindekserte MCQ-responser kreve passende forvaltning av offset-verdier og forsinkede kanaler, mens det å behandle tidsindekserte responser gjennom MCQ er forholdsvis enkelt. Responsbehandlingsmotoren (506) kan være innrettet for å betrakte innvirkninger av offset og etterslep mellom flere datakanaler med hensyn til en felles indeks i en datalogg. Responsbehandlingsmotoren (506) kan være innrettet for på en intelligent måte, og hyppig, bestemme hvilke datakanaler den skal involvere ved beregning av den totalt sett minste dybdeindeksen for å imøtekomme ”forsinkede datakanaler” uten å være bundet til datakanaler som ikke er aktivt økende. Responsbehandlingsmotoren (506) kan også være innrettet for å betrakte dupliserte data fra overlapper i tidligere spørringer når den behandler dybdeindekserte MCQ-responser. Her kan en datakilde (521) være innrettet for å tilveiebringe et tidsstempel som angir når datakilden (521) sist ble oppdatert. Spørringsklargjøringsmotoren (505) kan sjekke det sist oppdaterte tidsstempelet til datakilder (521) for å optimalisere datainnhenting. For eksempel kan spørringsklargjøringsmotoren (505) spesifisere at det kun skal spørres etter data oppdatert etter et spesifisert tidspunkt, idet responsbehandlingsmotoren (506) kan anvende dupliserte data fra en foregående spørring dersom dataene ikke har blitt oppdatert.

[0060] Responsbehandlingsmotoren (506) kan videre være innrettet for å styre forsinkede kanaler etter hvert som en spørring blir utført. Dersom for eksempel en forsinket kanal blir detektert, kan responsbehandlingsmotoren (506) skille ut den delen av MCQ’en som vedrører den forsinkede kanalen i en egen spørring. Her kan den opprinnelige spørringen bli fullført og de etterspurte dataene bli forsynt til en feltapplikasjon (541) mens den separate spørringen for den forsinkede kanalen fortsatt pågår.

[0061] En høynivå-algoritme og en detaljert algoritme for MCQ’en er gitt henholdsvis i tabell 3 og tabell 4.

TABELL 3

For hver dataspørring til tjeneren:

1. Bestem først min./maks. for hver kanal

2. Beregn startindeks for loggdata-spørringen

3. Spør loggen via en MCQ med bruk av den beregnede startindeksen

4. Ekspeder nye data til applikasjonen

TABELL 4

For hver gang RTDL spør WITSML-API-tjeneren om nye dataloggrader blir den kvalifiserte listen av avbildede kanaler bestemte for å spørre om data.

1. Spør om metadataene for alle logger for å bestemme gjeldende dybdeindeksintervaller for hver avbildede kanal i hver logg

a. Dette gjøres ved å spesifisere et LogCurveInfo-element for hver avbildede kanal, spesielt be om laveste og høyeste indeks.

b. Resultatet er en innledende kvalifisert liste av avbildede kanaler å spørre, én liste for hver logg

2. For hver logg

a. Filtrer bort ikke-økende kanaler: For hver avbildede kanal i loggen, dersom høyeste indeksverdi har blitt mottatt tidligere, fjern kanalen fra den kvalifiserte listen, ellers behold den i listen.

b. Behandle den kvalifiserte listen for å bestemme startindeksen for den forestående dataspørringen

i. Dataspørringens startindeks er “minimum” for den siste indeksen behandlet for alle kvalifiserte avbildede kanaler i loggen som data ble mottatt for i den foregående spørringen. [Dersom dette er den første spørringen, blir alle kanaler tatt med i beregningen av startindeksen]. c. Spør loggen via en MCQ med bruk av startindeksen

i. En MCQ er kun en loggspørringsmal der flere LogCurveInfoelementer blir spesifisert

ii. Dataene returneres i en komma-separert streng med følgende format:

<indeksverdi>, <verdi1>,<verdi2>,<verdi3>

iii. Dersom data mangler for én eller flere av kanalene, for eksempel den andre kanalen, kan en få følgende:

1000, 34.5,, 567.9

(Som kan sees over er de to tilgrensende kommaene et resultat av den manglende andre kanalen. Det kan imidlertid være andre nullverdimuligheter som også må ignoreres, f.eks. -999.25. Dette kan spesifiseres i attributten nullValue i LogCurveInfo.)

d. Ekspeder nye data til applikasjonen

i. Siden det er en felles startindeks er det mulig vi har mottatt tidligere leste data for enkelte kanaler.

ii. Derfor må RTDL-listen undersøke hver verdi før ekspedering for å unngå “dobbeltekspedering”

[0062] Algoritmen beskrevet over kan i tillegg suppleres med betraktninger for WITMSL-tjenere som ikke opprettholder en oppdatert minimumsindeks (minIndex) og/eller maksimumindeks (maxIndex) for hver datakanal. Indeksen minIndex kan bli betraktet i forbindelse med en loggretningsattributt. I en nedadgående logg kan for eksempel indeksen minIndex representere et største dyp, og er derfor større enn maxIndex.

[0063] Videre, som vist i figur 3.2, behandler responsbehandlingsmotoren (506) data mottatt fra datakildene (521.1)-(521.6) og legger data inn i datakøen (508) for utsending til feltapplikasjonene (541.1)-(541.5) via dataekspederingsmotoren (512). Ytterligere detaljer ved responsbehandlingsmotoren (506) og dataekspederingsmotoren (512) er beskrevet nedenfor i forbindelse med figur 5.

[0064] I en typisk boreoperasjon som vist i figur 2 kan boreverktøyet (f.eks. borestrengen (315), bunnhullsenheten (BHA) (330), borekronen (310), etc. vist i figur 2) gjennomløpe borehullet (313 vist i figur 2) i flere boreverktøykjøringer (f.eks. BHA-kjøring nummer 5 og 6 vist i tabell 5 nedenfor). Hver boreverktøykjør ing kan omfatte flere boreverktøypass (f.eks. passnummer P1-P4 i BHA-kjøring nummer 5 og passnummer P1-P2 i BHA-kjøring nummer 6 vist i tabell 5 nedenfor). Hvert boreverktøypass kan omfatte forskjellige typer pass (f.eks. RIH, REAM, DRILL, BREAM, STRIP, POOH, etc., som listet i tabell 5 nedenfor).

TABELL 5

[0065] Figur 4 er et dybdediagram som viser flere boreverktøypass i en boreverktøykjøring. Som kan sees i figur 4 representerer den vertikale aksen boreverktøyets dybdeposisjon og den horisontale aksen representerer tiden i boreoperasjonen. Dybdediagrammet omfatter boreverktøypass P1 RIH (651), P1 REAM (652), P1 Drilling (653), P2 BREAM (654), P2 STRIP (655), P3 STRIP (656), P3 REAM (657), P3 Drilling (658), P4 POOH (660) og en sirkuleringsperiode (659). Datalogger (f.eks. dybdeindekserte eller tidsindekserte datalogger) kan bli generert i hver av disse boreverktøypassene og bli tagget med kontekstinformasjon som refererer til detaljene ved hvert boreverktøypass.

[0066] Figur 5 er et skjematisk diagram som viser en sanntids dataprosess (650) i en boreoperasjon. Som vist i figur 5 omfatter sanntids-dataprosessen (650) én eller flere datakilder (521), en RTDL (501) og en sanntids (RT) feltapplikasjon (541), som er hovedsaklig de samme som de vist i figur 3.1. Sanntidsdataprosessen (650) i figur 5 kan omfatte flere sanntids-dataprosessdetaljer.

[0067] En boreoperasjon kan omfatte flere prosesstrinn (f.eks. boreverktøykjøringer eller -pass). Data vedrørende hvert prosesstrinn kan bli lagret og ekspedert separat. Som vist i figur 5 viser datakilden(e) (521) en multi-pass datakilde med datalogger (f.eks. loggede kjøringer (602)-(612)) innhentet fra to BHA-kjøringer (”Run 1” og ”Run 2”) i en boreoperasjon. Hver av BHA-kjøringene kan omfatte flere borepass, så som ”Drilling”, ”ReamUp”, ”ReamDown”, ”TripIn”, ”TripOut”, etc. For eksempel kan dataloggene (602)-(612) bli innhentet gjennom sekvensen vist i tabell 6 nedenfor. I disse flere BHA-kjøringene kan pass som gjentas flere ganger i én enkelt kjøring identifiseres ved entydige passnumre.

TABELL 6

1. Start “Run 1”

2. Boring

3. Røm opp, pass 1

4. Røm ned, pass 1

5. Røm opp, pass 2

6. Røm ned, pass 2

7. Boring

8. Uttrekking

9. Slutt “Run 1”

10. Start “Run 2”

11. Innkjøring

12. Boring

13. Røm opp, pass 1

14. Røm ned, pass 1

15. Boring

16. Uttrekking

17. Slutt “Run 2”

[0068] Som også er vist i figur 5 kan dataloggene (f.eks. loggede kjøringer (602)-(612)) omfatte kontekstinformasjon. For eksempel kan kontekstinformasjonen omfatte dataloggnavn så som ”Drilling, Run 1” i den loggede kjøringen (602), ”ReamUp, Run 1, Pass 1” i den loggede kjøringen (603), etc., dataloggidentifikatorer så som ”L1D” i den loggede kjøringen (602), ”L2RU” i den loggede kjøringen (603), etc., kanaldata-identifikatorer, så som ”Channels: A, B” i de loggede kjøringene (602)-(607) svarende til BHA ”Run 1” og ”Channels: A, B, C” i de loggede kjøringene (608)-(612) svarende til BHA ”Run 2”. Multi-pass-datakilder (f.eks. datakilde (521)) kan lagre datalogger i egne seksjoner, for eksempel en hovedseksjon og flere underseksjoner. Hovedseksjonen inneholder typisk alle tidsindekserte data og de dybdeindekserte dataene fra ”Drilling”-passet, mens underseksjonene under en hovedseksjon typisk inneholder dybdeindekserte data fra andre pass, for eksempel ”ReamUp”, ”TripOut”, etc.

[0069] I henhold til organiseringen av data i datakilden (f.eks. datalogger for multi-pass-datakilden(e) (521)), kan loggbehandlingsmodulen (504) (omfattende responsbehandlingsmotoren (506) og ekspederingsmotoren (512)) motta og ekspedere individuelle dataposter eller en vektor av dataposter til feltapplikasjonen (541). Et eksempel på individuelle datapunkter kan omfatte én enkelt datakanal i én enkelt rad i en tabellformatert datalogg. Et eksempel på vektor av datapunkter kan omfatte en hel rad vedrørende flere datakanaler som deler en felles indeksverdi i en tabellformatert datalogg. Datakontekstinformasjon (f.eks. ”passnummer”, ”kjøringsnummer” og retningsparametre) må forsynes til feltapplikasjonen (541) sammen med vektoren av datapunkter for datatolkning. Denne vektoren av datapunkter kan betraktes som en ”pseudo-dataramme”. En datalogg (f.eks. en hvilken som helst av de loggede kjøringene (602)-(612)) som ekspederes i vektorer blir typisk globalt ordnet etter indeksverdi, og inneholder logisk beslektede grupper med flere vedsidenliggende ”pseudo-datarammer” som deler en felles indeks som gjennomløper fortløpende verdier. For å trekke beslektede grupper ut av vektorene kan responsbehandlingsmotoren (506) og ekspederingsmotoren (512) i loggbehandlingsmodulen (504) være innrettet for å ta hensyn til at de beslektede gruppene i alminnelighet ikke trenger være eksplisitt identifisert og at datakanaler kan mangle verdier svarende til en gitt indeksverdi.

[0070] Når en sanntids-feltapplikasjon (541) ber om data fra én eller flere datakilder (521), blir en ønskede data-beskrivelsesliste (RDDL) (622) generert i RTDL-koblingen (501) som beskriver detaljer ved data som kreves av feltapplikasjonen (541). Tråden ”Channel Refresh Worker” (621.2) som kjører i RTDL-koblingen (501) kan periodisk spørre datakilden(e) (521) for å finne ut om nye datalogger er opprettet i brønnboringen eller om nye datakanaler er lagt til i datalogger som allerede er lest. ADDL-listen (623) bli oppdatert følgelig av ”Channel Refresh Worker”-tråden (621.2). For eksempel angir ADDL-listen (623), som vist i figur 5, at tilgjengelige data fra datakanal A kan finnes i datalogger L1D, L2RU, L3RDm L4RU, L5RD, L6TO, L8D, L9RU, L10RD og L11TO; tilgjengelige data fra datakanal B kan finnes i datalogger L1D, L2RU, L3RDm L4RU, L5RD, L6TO, L8D, L9RU, L10RD og L11TO; og tilgjengelige data fra datakanal C kan finnes i datalogger L8D, L9RU, L10RD og L11TO.

[0071] I tillegg kan tråden ”Data Worker” (621.1), som kjører gjennom responsbehandlingsmotoren (506) og ekspederingsmotoren (512), behandle borepass og pass uten boring på to forskjellige måter som følger:

* Vekslende loggetråd: det foretas en ”intelligent veksling” mellom de to boredataloggene L1D og L8D fordi de deler kanaler A og B, men over forskjellige indeksintervaller. Når enden av dataene er nådd for datalogg L1D, ”skiftes” det til dataloggen L2D for å lese dataene i denne. Dataloggene er sortert på forhånd i henhold til målt dybdeindeks. MCQ-logikk anvendes for å håndtere loggveksling for flere delte kanaler (f.eks. kanaler A og B), siden kanalene A og B potensielt vil kunne veksle mellom loggene L1D og L8D ved forskjellige indeksverdier. ;* Parallell loggetråd: alle loggene som ikke vedrører boring blir spurt i parallell med hensyn til retning.

[0072] Videre kan responsbehandlingsmotoren (506) legge datavektorer i kø i beslektede grupper (508.1, 508.2) (basert på kontekstinformasjon) ved å legge dem inn i separate ekspederingskøer (basert på behandlede kontekstidentifikatorer). Ekspederingsmotoren (512) kan da porsjonere data i henhold til disse kontekstoppdelte køene mens den tar hensyn til maksimal størrelse og minimum hyppighet.

[0073] Noen RTDL-applikasjoner kan være multi-pass-bevisste, mens andre ikke er innrettet for å behandle multi-pass-data. En global attributt (f.eks. en boolsk variabel MultiPassActivated) kan derfor bli satt i et API. Som default kan denne attributten være satt til ”False”. Det forventes at en applikasjon normalt ikke vil endre denne verdien under sin sesjon, og den vil være låst etter at forbindelsen er opprettet til en spesifikk brønnboring eller seksjon. Verdien til denne attributten kan påvirke hvordan tilgjengelige data blir tolket og spurt etter. Som nevnt over påvirker den også kontekstinformasjonen som blir ekspedert til applikasjonen.

[0074] RTDL-koblingen (501) kan tilveiebringe funksjonalitet for programmatisk aksess til hele tilstanden til rammeverket (500), omfattende funksjonalitet for å opprette det grafiske brukergrensesnittet gjennom API’et. Rammeverket (500) påtvinger støttede anropssekvenser slik at applikasjonen (f.eks. feltapplikasjon (541)) ikke anvender rammeverket (500) på uønsket måte. Ytterligere funksjonalitet som kan støttes av RTDL-koblingen (501) er beskrevet i tabell 7 nedenfor.

TABELL 7

● Sekvensiell playback på tvers av flere logger:

RTDL-koblingen kan avsende MP-dybdeindekserte data på to måter:

1. Playback-perspektiv:

● Send de dybdeindekserte dataene tilbake til applikasjonen sortert etter tid, med dynamisk veksling mellom forskjellige logger/pass, slik at dataene ankommer i den rekkefølgen de opprinnelig ble innhentet. 2. Parallell-perspektiv:

● Merk dataene med kontekst, men ikke forsøk å levere dem sortert etter tid

● Forvaltning av MP for tidsindekserte logger

● Kildeeksponering: Kildeinformasjonen blir gjort tilgjengelig gjennom API’et, omfattende mulighet til å se kildens ”tilpasningsevne”, dvs. hvilke objekter som støttes gjennom RTDL-koblingen.

● Ubehandlede data: Applikasjoner kan be om et velformulert og standard WITSML for et hvilket som helst objekt med bruk av API’et. Applikasjonene kan eventuelt også hente ”ubehandlede” data fra kilder. Dette lar applikasjoner anvende en RTDL-kobling for å skaffe dataobjekter fra kilder, også om RTDL-koblingen ikke vet hvordan den skal behandle dem. Dersom for eksempel en applikasjon trenger å få tak i en sideveggkjerne (SideWallCore) fra en

WITSML-API-kilde, men RTDL-koblingen ikke har noe ”ISideWallCoreData”-objekt, vil det være mulig å be om denne objekttypen ubehandlet, og få returnert WITMSL-objektet. RTDL-koblingen kan eventuelt gi støtte for å sette opp forespørselen og parse den.

● RDD’er: RDD’er tjener to formål, både som filtre og for å spesifisere ønskede data. Disse konseptene kan være atskilt slik at hvordan en applikasjon filtrerer data er forskjellig fra forespørsel om dataene.

● Håndtering av flere logger: RTDL-koblingen har funksjonalitet for å behandle samme kanal fra flere logger - noen tjenere publiserer data til forskjellige søskenseksjoner basert på hullstørrelse. For eksempel kan en ”12,5 tommers” seksjon inneholde loggdata, og en ”11 tommers” søskenseksjon bli opprettet på et senere tidspunkt som også inneholder loggdata. Disse logg-kanaldataene strømmer logisk på tvers av tid og dybde mellom disse to søskenseksjonene. ● Global indeks: Applikasjoner og brukere har mulighet til å spesifisere indeksintervaller som ”Med start fra, gå tilbake ….”. For eksempel ”Med start fra nå og tilbake 30 minutter”. Dette kan gjøres på et “globalt” nivå som gjelder for alle relevante indekserte data (både i tid og dybde).

[0075] Figur 6 viser et flytdiagram av en fremgangsmåte for en sanntids dataavlesingsprosess i en boreoperasjon. Boreoperasjonen kan for eksempel bli utført på et brønnsted (400) vist i figur 2 på et felt. Sanntids-dataprosessen kan være knyttet til data innsamlet for feltet (100) i figur 1.

[0076] Innledningsvis kan data bli bedt om av en feltprogramvareapplikasjon med bruk av en ønskede data-beskrivelsesliste (RDDL) som mottas av RTDL-koblingen (trinn 701). RTDL-koblingen kan sende en spørring til en datakilde basert på RDDL-listen, eventuelt kombinere flere datakanaler i én enkelt spørring (trinn 702). Som svar på spørringen kan RTDL-koblingen motta en tilgjengelige databeskrivelsesliste (ADDL) fra datakilden (trinn 701).

[0077] En bruker av feltprogramvareapplikasjonen kan da avbilde RDDL-listen og ADDL-listen for å velge data (ikke vist). Følgelig kan RTDL-koblingen abonnere på de avbildede tilgjengelige dataene fra ADDL-listen (trinn 703). RTDL-koblingen kan modifisere dataformatet og kommunikasjonsprotokollen i henhold til detaljene ved datakilden. Data mottatt fra datakilden kan være multi-pass-data merket med kontekstinformasjon, så som kontekstmarkører eller kontekstidentifikatorer. RTDL-koblingen kan formatere de mottatte tilgjengelige dataene basert på kontekstidentifikatorene (trinn 704) for utsending til feltapplikasjonen (trinn 705). RTDL-koblingen kan modifisere dataformatet og kommunikasjonsprotokollen i henhold til kravene til feltapplikasjonen. Feltapplikasjonen kan eventuelt behandle de formaterte dataene ved gjennomføring av en feltoperasjon og generere behandlede data mens den beholder kontekstinformasjonen (trinn 706). De behandlede dataene kan eventuelt bli skrevet tilbake til datakilden for oppdatering eller lagring

(trinn 707). Endelig kan boreoperasjonen eventuelt bli justert basert på de behandlede dataene (trinn 708).

[0078] RTDL-(Real-Time Data Link)-koblingen kan realiseres på praktisk talt en hvilken som helst type datamaskin uavhengig av plattformen som anvendes. For eksempel kan RTDL-koblingen realiseres på et datasystem som omfatter en prosessor, tilhørende minne, en lagringsanordning og en rekke forskjellige andre elementer og funksjonaliteter som er vanlige i dagens datamaskiner. Datasystemet kan også omfatte innmatingsanordninger, så som et tastatur og en mus, og utmatingsanordninger, så som en dataskjerm. Datasystemet kan være koblet til et lokalt nettverk (LAN) eller et regionalt nettverk (f.eks. Internett) via en nettverksgrensesnittsforbindelse. Fagmannen vil forstå at disse innmatings- og utmatingsanordningene kan ta andre former.

[0079] Videre vil fagmannen forstå at ett eller flere elementer i ovennevnte datasystem kan befinne seg et annet sted og være koblet til de andre elementene over et nettverk. Videre kan sanntids, bidireksjonal dataforvaltning realiseres i et distribuert system med flere noder, der hver del av sanntids, bidireksjonal dataforvaltning kan befinne seg på en egen node innenfor det distribuerte systemet. I ett eksempel svarer noden til et datasystem. Alternativt kan noden svare til en prosessor med tilhørende fysisk minne. Noden kan alternativt svare til en prosessor med delt minne og delte ressurser. Videre kan programvareinstruksjoner for å praktisere utførelsesformer av sanntids, bidireksjonal dataforvaltning være lagret på et datamaskinlesbart medium, så som en CD, en diskett, et lagringsbånd, en fil, eller en hvilken som helst annen datamaskinlesbar lagringsanordning.

[0080] Trinnene i fremgangsmåten er vist i en spesifikk rekkefølge. Det vil imidlertid forstås at deler av fremgangsmåten kan bli utført samtidig eller i en annen rekkefølge eller sekvens. I fremgangsmåten kan videre feltdataene bli vist, skjermvinduene kan tilveiebringe en rekke forskjellige fremvisninger av de forskjellige dataene som er samlet inn og/eller generert, og fremvisningen kan ha brukerinnmatinger som lar brukere skreddersy innsamlingen, behandlingen og fremvisningen av feltdata.

[0081] Det vil forstås fra den foregående beskrivelsen at forskjellige modifikasjoner og endringer kan gjøres i utførelsesformene av sanntids, bidireksjonal dataforvaltning uten å fjerne seg fra den sanne idéen. For eksempel kan fremgangsmåtetrinnene bli utført i en annen rekkefølge, og de tilveiebragte komponentene kan være integrert eller atskilte.

[0082] Denne beskrivelsen er kun ment for illustrasjonsformål, og skal ikke forstås i en begrensende forstand. Rammen til sanntids, bidireksjonal dataforvaltning skal kun bestemmes av ordlyden i de vedføyde kravene. Ord som “omfattende”, ”omdatter” og liknende i kravene er ment å bety “omfatter i hvert fall”, slik at den beskrevne opplistingen av elementer i et krav ikke er en lukket gruppe. Bruken av "et", “en” og andre entallsformer er ment å omfatte den motsvarende flertallsformen dersom denne ikke spesifikt er utelukket.

Claims (19)

P A T E N T K R A V

1. Fremgangsmåte for å fremskaffe feltdata gjennom sanntids, bidireksjonal dataforvaltning, fremgangsmåten omfatter det å:

motta en liste som beskriver ønskede data (522) fra en feltapplikasjon (541) knyttet til et boresystem (311) som utfører en boreoperasjon;

motta en liste som beskriver tilgjengelige data (523) fra en datakilde (521); abonnere på tilgjengelige data ved å avbilde den tilgjengelige databeskrivelseslisten (523) til den ønskede data-beskrivelseslisten, der de tilgjengelige dataene har et første dataformat og en første kommunikasjonsprotokoll forbundet med datakilden (521) og omfatter en første kontekstidentifikator tildelt av datakilden (521) for å identifisere en del av de tilgjengelige dataene;

modifisere de tilgjengelige dataene for å generere første modifiserte data som har et andre dataformat og en andre kommunikasjonsprotokoll for overføring til feltapplikasjonen (541), der de første modifiserte dataene omfatter den første kontekstidentifikatoren for å identifisere en del av de første modifiserte dataene;

selektivt utføre en boreoperasjon basert på de første modifiserte dataene; generere behandlede data ved feltapplikasjonen (541), der de behandlede dataene omfatter den første kontekstidentifikatoren for å identifisere en del av de behandlede dataene; og

modifisere de behandlede dataene for å generere andre modifiserte data med det første dataformatet og den første kommunikasjonsprotokollen, der de andre modifiserte dataene lagres i datakilden (521).

2. Fremgangsmåte ifølge krav 1, videre omfattende det å selektivt justere boreoperasjonen basert på i hvert fall den delen av de behandlede dataene som identifiseres av den første kontekstidentifikatoren.

3. Fremgangsmåte ifølge krav 1, der

ønskede data-beskrivelseslisten (522) vedrører flere datakanaler knyttet til datakilden (521),

tilgjengelige data-beskrivelseslisten (523) vedrører minst én datakanal av de flere datakanalene, og

de tilgjengelige dataene abonneres på fra den minst ene datakanalen ved å avbilde tilgjengelige data-beskrivelseslisten (523) til ønskede databeskrivelseslisten (522).

4. Fremgangsmåte ifølge krav 3, der

tilgjengelige data-beskrivelseslisten (523) vedrører flere boreverktøykjøringer, der en boreverktøykjøring av de flere boreverktøykjøringene har ett eller flere boreverktøypass, der et boreverktøypass av det ene eller de flere boreverktøypassene genererer en første datalogg vedrørende den minst ene datakanalen, der den første dataloggen er delen av de tilgjengelige dataene og merket med den første kontekstidentifikatoren,

de tilgjengelige dataene videre omfatter en andre datalogg vedrørende de flere boreverktøykjøringene, der den andre dataloggen er merket med en andre kontekstidentifikator; og

de tilgjengelige dataene modifiseres til det andre dataformatet basert på den første kontekstidentifikatoren og den andre kontekstidentifikatoren.

5. Fremgangsmåte ifølge krav 4, der de ett eller flere boreverktøypassene omfatter ett eller flere av et borepass, et røm-opp-pass, et røm-ned-pass og et uttrekkingspass.

6. Fremgangsmåte ifølge krav 4, der den første kontekstidentifikatoren representerer en tilhørende boreverktøykjøring.

7. Fremgangsmåte ifølge krav 1, der

datakilden (521) omfatter minst én valgt fra en gruppe bestående av et databasesystem (521.1), et filsystem (521.5), en webtjeneste (521.2), en peerapplikasjon (521.3), en multi-pass-kilde (521.4) og en abonneringstjeneste (521.6), og

feltapplikasjonen (541) omfatter minst én valgt fra en gruppe bestående av et akkvisisjonssystem (541.1), en teknisk analysetjeneste (541.2), en sanntids overvåkningstjeneste (541.3) og en dataformidlingstjeneste (541.4).

8. System for å fremskaffe feltdata gjennom sanntids, bidireksjonal dataforvaltning, systemet omfatter:

et applikasjonsprogrammeringsgrensesnitt (509) innrettet for å:

motta en liste som beskriver ønskede data (522) fra en feltapplikasjon (541) knyttet til et boresystem (311) tilpasset til å utføre en boreoperasjon, der ønskede data-beskrivelseslisten (522) vedrører en første datakanal knyttet til datakilden (521); og

abonnere, basert på en liste som beskriver tilgjengelige data (523), på tilgjengelige data fra den første datakanalen, der de tilgjengelige dataene omfatter en første datalogg og en andre datalogg vedrørende de flere boreverktøykjøringene, der den andre dataloggen er merket med en andre kontekstidentifikator, og

et dataadapter (531) innrettet for å:

motta tilgjengelige data-beskrivelseslisten (523) fra datakilden (521), der tilgjengelige data-beskrivelseslisten (523) vedrører flere boreverktøykjøringer, der en boreverktøykjøring av de flere boreverktøykjøringene har ett eller flere boreverktøypass, der et boreverktøypass av det ene eller de flere boreverktøypassene genererer den første dataloggen vedrørende den første datakanalen, der den første dataloggen er merket med en første kontekstidentifikator; og

formatere tilgjengelige data basert på den første kontekstidentifikatoren og den andre kontekstidentifikatoren for å generere første modifiserte data for avsending til feltapplikasjonen (541),

hvor boreoperasjonen blir utført av feltapplikasjonen (541) basert på de første modifiserte dataene.

9. System ifølge krav 8, der feltapplikasjonen (541) utfører en feltoperasjon basert på de første modifiserte dataene for å generere behandlede data, der de behandlede dataene omfatter den første kontekstidentifikatoren for å identifisere en del av de behandlede dataene svarende til den første dataloggen, og der dataadapteret videre er innrettet for å:

modifisere de behandlede dataene for å generere andre modifiserte data med et første dataformat og en første kommunikasjonsprotokoll, der de andre modifiserte dataene lagres i datakilden (521); og

selektivt justere boreoperasjonen basert på i hvert fall en del av de behandlede data som er identifisert av den første kontekstidentifikatoren.

10. System ifølge krav 8, der

ønskede data-beskrivelseslisten (522) videre vedrører en andre datakanal knyttet til datakilden (521),

den første dataloggen og den andre dataloggen videre vedrører den andre datakanalen, og

de tilgjengelige dataene videre blir abonnert på fra den andre datakanalen ved å avbilde den første dataloggen og den andre dataloggen i tilgjengelige databeskrivelseslisten (523) til den andre datakanalen i ønskede databeskrivelseslisten (522).

11. System ifølge krav 8, der

datakilden (521) omfatter minst én valgt fra en gruppe bestående av et databasesystem (521.1), et filsystem (521.5), en webtjeneste (521.2), en peerapplikasjon (521.3), en multi-pass-kilde (521.4) og en abonneringstjeneste (521.6), og

feltapplikasjonen (541) omfatter minst én valgt fra en gruppe bestående av et akkvisisjonssystem (541.1), en teknisk analysetjeneste (541.2), en sanntids overvåkningstjeneste (541.3) og en dataformidlingstjeneste (541.4).

12. System ifølge krav 8, der de ene eller flere boreverktøypassene omfatter ett eller flere av et borepass, et røm-opp-pass, et røm-ned-pass og et uttrekkingspass.

13. System ifølge krav 8, der den første kontekstidentifikatoren representerer en tilhørende boreverktøykjøring.

14. Datamaskinlesbart medium, som innlemmer instruksjoner som kan eksekveres av en datamaskin for å utføre fremgangsmåtetrinn for å fremskaffe feltdata gjennom sanntids, bidireksjonal dataforvaltning, der instruksjonene omfatter funksjonalitet for å:

motta en liste som beskriver ønskede data (522) fra en feltapplikasjon (541) knyttet til et boresystem (311) tilpasset til å utføre en boreoperasjon, der ønskede data-beskrivelseslisten (522) vedrører flere datakanaler forbundet med en datakilde (521);

spørre datakilden (521) basert på ønskede data-beskrivelseslisten (522) med bruk av en flerkanal-spørring, der flerkanal-spørringen vedrører de flere datakanalene;

motta en liste som beskriver tilgjengelige data (523) fra datakilden (521), der tilgjengelige data-beskrivelseslisten (523) vedrører minst én datakanal av de flere datakanalene;

abonnere, basert på tilgjengelige data-beskrivelseslisten (523), på tilgjengelige data fra den minst ene datakanalen, der de tilgjengelige dataene har et første dataformat og en første kommunikasjonsprotokoll;

modifisere de tilgjengelige dataene for å generere første modifiserte data med et andre dataformat og en andre kommunikasjonsprotokoll for avsending til feltapplikasjonen (541), og

selektivt justere boreoperasjonen ved feltapplikasjonen (541) basert på de første modifiserte dataene.

15. Datamaskinlesbart medium ifølge krav 14, der instruksjonene videre omfatter funksjonalitet for å:

generere behandlede data relatert til boreoperasjonen ved feltapplikasjonen (541), der de behandlede dataene omfatter en første kontekstidentifikator for å identifisere en del av behandlede data svarende til en første datalogg;

modifisere de behandlede dataene for å generere andre modifiserte data med det første dataformatet og den første kommunikasjonsprotokollen, der de andre modifiserte dataene lagres i datakilden (521); og

selektivt tilpasse boreoperasjonen basert på i hvert fall den delen av de behandlede dataene som er identifisert av den første kontekstidentifikatoren.

16. Datamaskinlesbart medium ifølge krav 14, der

datakilden (521) omfatter minst én valgt fra en gruppe bestående av et databasesystem (521.1), et filsystem (521.5), en webtjeneste (521.2), en peerapplikasjon (521.3), en multi-pass-kilde (521.4) og en abonneringstjeneste (521.6), og

feltapplikasjonen (541) omfatter minst én valgt fra en gruppe bestående av et akkvisisjonssystem (541.1), en teknisk analysetjeneste (541.2), en sanntids overvåkningstjeneste (541.3) og en dataformidlingstjeneste (541.4).

17. Datamaskinlesbart medium ifølge krav 15, der

tilgjengelige data-beskrivelseslisten (523) vedrører flere boreverktøykjøringer, der en boreverktøykjøring av de flere boreverktøykjøringene har ett eller flere boreverktøypass, der et boreverktøypass av det ene eller de flere boreverktøypassene genererer en første datalogg vedrørende den minst ene datakanalen, der den første dataloggen er en del av de tilgjengelige dataene og merket med den første kontekstidentifikatoren,

de tilgjengelige dataene videre omfatter en andre datalogg vedrørende de flere boreverktøykjøringene, der den andre dataloggen er merket med en andre kontekstidentifikator; og

de tilgjengelige dataene blir modifisert til det andre dataformatet basert på den første kontekstidentifikatoren og den andre kontekstidentifikatoren.

18. Datamaskinlesbart medium ifølge krav 17, der de flere boreverktøypassene omfatter et borepass, et røm-opp-pass, et røm-ned-pass og et uttrekkingspass.

19. Datamaskinlesbart medium ifølge krav 17, der den første kontekstidentifikatoren representerer en tilhørende boreverktøykjøring.