NO331314B1 - Forberedt overvaking av industrielle prosjektleveranser - Google Patents

Abstract

Oppfinnelsen omhandler en datamaskinbasert fremgangsmåte for å overvåke en tett flyt av leveranser mellom leverandør(er) og kunde. Oppfinnelsen er ka- rakterisert ved at fremgangsmåten omfatter de følgende trinn: - etablere en liste av typer av produkter (ll) involvert i en eller flere prosjekter (Pi); - så for hver type av oppstrømsprodukter (li) etablere (612) i det minste en tabell (B P, RP), for hver tidsluke i en sekvens, et første flertall av en mengde (BP) tilegnet daterte behov (li, ti) ved kundestedet og en andre flertall av en andre mengde (Rp) assosiert med lagerbeholdn inger (Sj, tj) og med innkjøp (Ak, tk), og - å finne ut (618) tidspunkter for hvilke det andre flertall er mindre enn det første som indikatorer for leveransemangel og/eller behov for å utløse en leveranse.

Description

Oppfinnelsen vedrører overvåkning av leveranser mellom leverandør(er) og klient innenfor industrielle prosjekter, spesielt, men ikke eksklusivt, tunge industrielle prosjekter.

Innenfor bestemte områder kan en dårlig forsyning være både kritisk og spesielt vanskelig å håndtere. Dette er tilfelle for eksempel for oljeboringsoperasjoner og deres forsyning med hensyn til metallrør av forskjellige typer.

Det er kjent at på letestedet/borestedet (kundestedet) vil hver borering av en brønn (eller prosjekt) bli assosiert med en foreldet status hva angår behovet for metallrør (oppstrøms-produkter) for de forskjellige typer og dimensjoner av rør. Samtidig holdes det en status for varebeholdningen av disse oppstrøms-produkter idet de befinner seg på borestedet. Ordrene plasseres hos rørleverandøren i henhold til disse statuser. Produksjonstiden for rør hos leverandøren og leveringstiden mellom leverandørstedet og kundestedet fører imidlertid til, på den ene side, at en på klientsiden og/eller på leverandørsiden eller -sidene har ganske store lagre for å møte uforutsette hendelser eller endringer i et pågående prosjekt, og/eller på den annen side for å akseptere forsinkelser i utførelsen av dette prosjektet. Disse begrensningene er tunge innenfor et område slik som oljeboring. Videre er det vanskelig å håndtere disse begrensningene annet enn fra prosjekt til prosjekt.

Fra Orlicy, J. A.: "Net change material requirements planning", IBM Systems Jour-nal, 1973, USA, vol. 12, no. 1, side 2-29 er det kjent et system og en fremgangsmåte for overvåking av leveranser mellom leverandører og klienter, hvor klientens lagerbeholdninger og innkjøp kontrolleres og overvåkes slik at leveranse av varer blir gjort før en bestemt lagerstatus.

Den foreliggende oppfinnelse sørger for å avhjelpe situasjonen nevnt ovenfor.

Den tilbyr på den ene side en databehandlingsfremgangsmåte for å overvåke dårlig leveranse mellom leverandør(er) og kunde, for hvilke, på kundestedet, hvert prosjekt (Pi) er assosiert med en foreldet status av behov (Ii; tO av produkter, samtidig som det holdes en status for lagerbeholdningene (Sj; tj) og innkjøp (Ak, tk) for disse produkter,

karakterisert vedat den omfatter de følgende trinn:

a. produsere en liste av produkttyper (I,) involvert i en eller flere prosjekter (P,),

b. for hvert produkt av oppstrøms-typen (10 å etablere i det minste en tabell (Bp, Rp), og for en sekvens av tidsluker å ha valgt et oppstartstidspunkt,<*>for hver tidsluke ha en første løpende total fra oppstarttidspunktet til den aktuelle tidsluke for en første kvantitet ((Bp;) koblet til de foreldede kravene (Ii; ti) på kundestedet;<*>for hver tidsluke ha en andre løpende total fra oppstarttidspunktet og opp til den aktuelle tidsluke for en andre kvantitet (Rp) koblet til lagerholdet (Sj; tj) og innkjø-pene (Ak, tk), der innkjøpene har et tilvist skifte i henhold til en forsinkelse;

og

c. se etter de tidspunkter der den andre løpende totalen blir mindre enn den første som indikatorer på en risiko for forsyningsmangel og/eller et behov for å initiere nye forsyninger. "Innkjøp" over kan bety innkjøp utført, bestilt, planlagt eller ganske enkelt innkjøp en kan se for seg (innkjøpsbehov). En av disse muligheter kan bli valgt ved konst-ruksjon. I en utførelse kan ett eller flere av valgene bli gjort tilgjengelige for brukeren, ved et valg, i henhold til den ønskede analysemodus. Forsinkelsen kan være en forsinkelse av leveranser eller av tilgjengelighet på stedet, eller en forsinket kobling til en og/eller de andre, direkte eller indirekte. Oppfinnelsen tilbyr videre et databehandlingssystem for overvåkning av dårlig forsyning mellom leverandør og kunde, omfattende en overvåkningsmodul (50, 52) som er i stand til å lagre i minnet en datert statusliste for produktbehov (Ii; ti), assosiert med en eller flere prosjekter (Pi), og samtidig holde en status for lagerbeholdningen (Sj; tj) og innkjøp (Ak, tk) for disse produkter, karakterisert vedat overvåkningsmodulen omfatter en kontrollmodul (54), omfattende: - en nødvendighetsmodul (612a) i stand til, for hver produkttype, å produsere en første tabell, assosiert med en sekvens av tidsluker som har et valgt oppstarttidspunkt, i denne første tabell assosieres hver enkel tidsluke med en første løpende total av behov (Bp) fra oppstarttidspunktet og opp til den aktuelle tidsluke; - en ressursmodul (612b), i stand til, for hver produkttype, å produsere en andre tabell, assosiert med sekvensen av tidsluker, der denne andre tabell assosierer med hver tidsluke en andre løpende total (Rp) av varebeholdning pluss innkjøp, fra oppstarttidspunktet og opp til den aktuelle tidsluke, der innkjøpene blir skiftet tidvis i henhold til en forsinkelse (DA; DI); og - en komparator (618) for å se etter tider ved hvilke de andre løpende totaler blir mindre enn den første, som indikatorer på en risiko for leveransesvikt.

Det ovenfor nevnte er en funksjonell beskrivelse av systemet. I henhold til et annet syn vil overvåkningsmodulen omfatte: - en løpende totalmodul (612) som er i stand til å motta som parametere produkt-typebetegnelsen, en modus og et oppstarttidspunkt, og å produsere for produktty-pebetegnelsen en tabell som kan assosieres med suksessive tidsluker en løpende total for produktkvantiteter definert av modusen der hver løpende total går fra oppstarttidspunkt og opp til den aktuelle tidsluke; og

- en kontrollmodul (54) arrangert for:

<*>å kalle opp den løpende totalmodul (612) med en produkttype, og en modus som omfatter den fortløpende totale behovet på kundestedet, som igjen leverer en førs-te tabell;<*>å kalle opp den løpende totale modul (612) med den samme produkttype, og en modus som omfatter den løpende totale lagerbeholdning i tillegg til tilbehøret (for eksempel leveranser) som forsyner en andre tabell; og<*>å se etter (618) tidspunktene der de løpende totaler i den andre tabell blir mindre enn de for den første tabell som indikatorer for en risiko for forsyningsmangel.

Til slutt tilveiebringer også oppfinnelsen et produktprogram som kan defineres til å omfatte funksjonene for å utføre trinnene a. til c. for den ovenfor nevnte fremgangsmåte, og/eller å omfatte funksjonene for kontrollmodulen i systemet definert over.

Oppfinnelsen kan også dekke et produktprogram på et høyere nivå som danner en forløper for produktprogrammet nevnt over. I en objektorientert programmerings- utførelse kan dette høyere nivå for produktprogram omfatte objektklasser og en generisk versjon av kontrollmodulen.

Andre karakteristikker og fordeler av oppfinnelsen vil fremkomme ved en gjennom-gang av den detaljerte beskrivelsen under og de ledsagende tegninger, der: - Figur 1 og la beskriver den kjente generelle struktur for en oljebrønn, skjematisk begrenset til kravene for den foreliggende beskrivelse; - Figur 2 er en del av et bilde som illustrerer den kjente sammenstillingen av to rør; - Figur 2a er en modifisert versjon av figur 2; - Figur 3 er et flytdiagram som illustrerer produksjon og sammenstilling av elementer slik som de i figur 2; - Figur 4 er et diagram som illustrerer den kjente samhandlingen mellom et kunde-sted og et levera ndørsted; - Figur 5 er en modifisert versjon i henhold til oppfinnelsen for diagrammet i figur 4; - Figur 6 illustrerer funksjoner lokalisert i et databehandlingssystem; - Figur 7 er et flytskjema for operasjonene brukt for implementering av oppfinnelsen i henhold til en utførelsesform: - Figur 8 er en graf som danner et første modus for fremvisning av produktet i henhold til oppfinnelsen; - Figur 9 er en tabell som danner en andre modus for fremvisning av et produkt i henhold til oppfinnelsen; og - Figur 10 er et skjema med objekter som illustrerer et interessant alternativ til oppfinnelsen.

Tegningene inneholder essensielt elementer av en bestemt natur. De kan derfor ikke bare anvendes for å gjøre beskrivelsen enklere å forstå, men også for å bidra i retning av å definere oppfinnelsen om nødvendig.

Den foreliggende beskrivelse er supplert med et appendiks som definerer:

- i A.1.0, betegnelser;

- i A.1.1, grunnleggende elementer for implementering av oppfinnelsen; og

- i A.1.2, programvareobjekter og deres egenskaper i tilfelle av en objektorientert programmeringsimplementering.

Referanser kan gjøres direkte til avsnittet for dette appendiks som er satt for seg selv kun for å bedre forståelsen, og som sådan utgjør en integrert del av beskrivelsen.

Det foreliggende dokumentet kan inneholde elementer som er beskyttet i henhold til forfatters rettigheter (droit d'auteur) eller opphavsrett. Rettighetshaver har ingen innsigelse til identisk reproduksjon av hvem som helst for dette patentdokumentet, idet det fremstår i arkiver og/eller publikasjoner for patentkontorer. På den annen side vil nevnte rettighetshaver reservere alle sine forfatterrettigheter og/eller opphavsrett.

Den detaljerte beskrivelsen under vil bli fremvist i hovedsak med referanse til tilfellet for et oljeboringssted, men skal ikke være begrenset dertil. Rigger blir brukt for produksjon av olje og gass ved hver brønn på et sted. En slik brønn består av en sammenstilling av stålrør av et antall forskjellige typer. Figur 1 beskriver en brønn under boreprosessen med et flertall konsentriske kolon-ner av utforinger, merket TO. Disse utforinger TO er vist som svarte linjer og er omgitt av sement CO i et gråmerket område. I sentrum befinner det seg et sett av drillrør T2. Boreslam går ned dette sett av borerør, noe som gjør det mulig spesielt å fjerne fragmenter av borestener. I området Z2 er det for eksempel i periferien en utforingssammenføyning, og i sentrum en rørsammenføyning. Figur la viser igjen foringsrøret, rørene T01 - T04, opphengt i blokker som danner fåringsrørhengere CH1 til CH4 omgitt av lag av sement C01 til C04, der hver av dem ender i en bunn med en nedre flottørsko for sementring CS01 til CS04. Foringsrøret fortsetter med et brønnforingsrør L05 orientert i henhold til geometrien for reservoaret og perforert, for eksempel ved P05 for å tillate passasje av olje eller gass som vil bli ført opp av produksjonsrøret. Brønnforingsrøret L05 blir holdt på plass av brønnfåringshenger LH. Produksjonsstrengen er dannet ved produksjonsrør og et antall av tilbehør som er bl.a. sikkerhetsventilen SV og en sidelommedor SPM, der de selv er omsluttet av tverrforbindelser CO eller tilpasningsrør eller ellers av innerslitasjerør FC.

Produksjonsstrengen er opphengt ved sin topp av en produksjonsrørhenger TH og omfatter videre et antall av produksjonspakninger så som for eksempel PK og BP.

Selvfølgelig vil produksjonsstrengen kun bli senket idet boringen er fullført og bli satt inn i stedet for et sett av drillrør.

Hver brønn vil derfor kreve forskjellige typer rør som vil måtte produseres og sam-menstilles på rørproduksjonsstedet og transporteres til brønnboringsstedet der de blir satt sammen til en større lengde i brønnen. Videre vil hver brønn også kreve en sammensetning av et antall av andre formonteringer eller tilbehør, som vil bli diskutert senere.

Figur 2 viser 2 rør Ta og Tb satt sammen ved hjelp av en gjenget hylse M. Med hensyn til rørproduksjonen vil en hylse M bli festet til en rørende, for eksempel Ta. Rørene blir så transportert i enhetslengder (av omtrent 10 m) med en hylse ved sin rørende. Sammenstilling til større lengder av den frie enden av hylsen med andre rør uten hylser blir utført under riggen, og generelt ved senking av rørene inn i brønnen.

Å gjøre et sammensatt rørprodukt tilgjengelig på borestedet involverer mange operasjoner som nå vil bli beskrevet med referanse til figur 3, den venstre siden av denne viser en tidsskala rettet nedover fra et initialt øyeblikk Tf0, noe senere enn mottak for en ordre, til et sluttøyeblikk Tflsom representerer det øyeblikk når rør-produktet befinner seg på borestedet.

Rørene blir produsert fra en barre 301 som utsettes for en falseprosess ved 303, så utsettes den for en varmebehandling ved 305, etter dette vil deres ender bli gjenget ved 307 for å kunne motta hylsen.

For sin del er også hylsen produsert fra en barre 311, valset ved 313, så utsatt for varmebehandling ved 315, og etter dette gjennomgår den en oppkapping og en gjenging.

Ved 320 vil rørene så settes sammen med sine hylser som illustrert i figur 2, til en lengre størrelse definert av de begrensede transportmuligheter, og så blir sammenstillingen pakket for transport. Den endelige transportoperasjon ved 322 transpor-terer disse rørprodukter til borestedet.

En variant består i å forbinde to rør uten en mellomliggende hylse som illustrert i figur 2a. Et av rørene mottar en hannhylse, den andre en hunnhylse. Skjematisk i den nåværende situasjon vil et leverandørsted SF utføre produksjonsoperasjonen for figur 3 ved SF1, og også omfatte leverandørlagring ved SF2.

Ved kundestedets side SC, finnes det prosjekter SCI, i dette tilfellet et flertall av boreoperasjoner og en lagerbeholdning av rørprodukter SC2. Mellom de to steder må en transportenngstid tr kompenseres for. På kundesiden vil lagerbeholdningen SC2 også bli forsynt med rør som er overhalt og kommer fra rigger (etter bruk). Disse overhalte eller rehabiliterte produktene blir igjen tilgjengelige etter kontroll. Dette er en signifikant kilde til variasjon i lagerbeholdningen.

I virkeligheten er operasjonene noe mer komplekse, slik som vist i figur 5.

Leverandøren Fo vil generelt bruke et antall forskjellige fabrikker og installere ved forskjellige lokasjoner Ui til Ui; (valselinjene er for eksempel installert ved faste steder). En vil derfor implementere en leverandørproduksjonsfortegnelse PFo, der det må tas hensyn til lokale produksjonsvariasjoner DTFo om nødvendig.

På kundesiden CL, foreligger også en boreplan (kundeproduksjon) PcL så vel som lokale variasjoner i boreplanen DTcL.

Samhandlingen mellom kundesiden og leverandørsiden finner sted gjennom rørpro-dukttransportoperasjonene TR.

Per i dag leveres rørprodukter til oljeindustriens kunder enten fra produksjon etter-fulgt av en ordre (som krever en implementeringstid på fire til seks måneder), eller fra et forsendelseslager styrt på vegne av denne kunden. Disse ekstremt tunge tids- og/eller lagringsbegrensninger genererer kostnader som det er nødvendig å forsøke å redusere.

Spesielt oppstår problemet for rørprodusenten for levering av rørprodukter relatert til rigg i så stor grad som mulig uten noen mellomlagring, dvs. "just in time". Det er også ønskelig å redusere forsinkelsen mellom ordrebekreftelse og levering på stedet til seks uker, i det minste for standardrør.

Selvfølgelig kan rørproduktbehovet kunne endres betraktelig avhengig av endringe-ne i situasjonen på borestedet som i seg selv igjen er avhengig av hendelser som kan strekke seg fra en uforutsett geologisk - og/eller prøveboringshendelse til et uhell med utstyret.

En kan tenke seg at en kan delegere en person til borestedet, eller i nærheten av borestedet, for å oppdatere det forventede rørforbruket så regelmessig som mulig for å konsolidere dem, og for å overføre dem til de som er ansvarlig for planlegging av rørproduksjon.

Når antallet rigger blir stort og prognosene endres jevnlig, vil det imidlertid være menneskelig umulig å manuelt oppdatere prognosene på en troverdig måte. Videre vil koblingen mellom forsyningen av rørprodukter og forsyningen for assosierte ti I— leggsprodukter raskt bli svært kompleks.

Den foreliggende oppfinnelse søker å tilveiebringe en løsning på disse problemer.

I henhold til et aspekt av oppfinnelsen vil det ved kundestedet CL finnes et datama-skinsystem CSc, fordelaktig forbundet med et nettverk til et leverandørsidesystem CSf for rask overføring av informasjon.

Ved kundesiden ved øyeblikket Tjkan produktbehovet Ijfor en brønn Pjbli repre-sentert ved en triplett av informasjoner gitt som A.1.1.a. I virkeligheten vil produktbehovet li være en funksjon av brønnen Pi og tidspunktet, som indikert ved A.l.l.b.

På leverandørsiden vil en ved et tidspunkt Tjvære i stand til å levere supplerende forsyninger til kunden i forhold til den totalmengde Sj kunden allerede har av produktet Lj som indikert i A.l.l.c (i det etterfølgende vil totalmengden bli referert til som "stock" (lagerbeholdning) selv om dette nødvendigvis ikke svarer til den fysiske betydningen av "stock" (lagerbeholdning)).

Det fremsatte optimaliseringsproblemet består i, om en starter med data li og Tjfor alle brønner, og vekselvirker konsekvent på lagerbeholdningen Sjved tidspunktet Tj-

Figur 6 illustrerer funksjoner som er lokalisert i en datamaskin som kan være for eksempel en WEB IIS (Internet Information Service) -tjener, operert under Win-dows NT.

Ved 50 inneholder datamaskinminnet mengdene som illustrert ved A.1.1.a og A.l.l.c i Appendikset som kan bli sett på som respektivt behovene ved brønnen og tilstanden for lagerbeholdningen av produktet (ITEM). På kjent vis vil et datainnma-tingssystem ha en effekt på innholdet av minnet 50. Det kan baseres på data lagt inn av en operatør, og/eller trukket fra datamaskinbaserte fortegnelser på stedet.

Typisk vil behovene være håndtert av brønnen, oppfinnelsen trekker først og fremst fordel av at ved 52 blir en summering utført for alle brønner, som gir de TO ele-mentene i uttrykket A.l.l.b, som kan bli betraktet respektivt som en summering av ITEM (gjenstand) og en tilstand for lagerbeholdningen av ITEM. Det vil derav fremkomme et opplagt behov.

I henhold til et annet aspekt ved oppfinnelsen er det lagt til et annet løpende system for totalen illustrert ved 54 i figur 6, og som vil tillate for eksempel en fremvisning 56 for operatøren, som det også vil bli sett. Dette systemet kan også anvende en tilstand for reservering eller ordrebekreftelser som uttrykt ved A.l.l.e.

Virkemåten for mekanismen 54 vil fordelaktig støtte seg på objektorientert programmering som anvender objekter definert ved A.1.2. i tabell A.1.2 vil forsinkelsen DA være definert som følger: om produktet må bli levert ved datoen J, må dens varige forespørsel bli bekreftet innen J-DA.

Denne mekanismen vil bli beskrevet her for et gitt produkt "PROD_I", men må selv-følgelig gjentas for hver produkttype som er nødvendig for en brønn, for eksempel de tre klassene av rør TO, Tl og T2 beskrevet i forbindelse med figur 1.

I figur 7, for et produkt PROD_I illustrert ved 600, blir tre sorteringsoperasjoner utført først av alt (uttrykt i figuren ved den vanlige sorteringsinstruksjonen "sort"): - underobjektene (instances) sorterer produktene ("ITEM" objekt) i henhold til summen av dataene DP og DI, nemlig den planlagte oppstartsdato for brønnen og forsinkelsen mellom oppstartsdato for brønnen og behovet for produkter ved stedet (alle tider er uttrykt i dager i dette eksemplet); - trinnet 604 sorterer produktene i lagerbeholdningen ("STOCK"-objekter) ved deres inngangsdato til lagerbeholdningen JS; - operasjonen 606 sorterer innkjøpene i henhold til deres planlagte leveringsdato

JA.

Selvfølgelig involverer de tre operasjoner 602, 604 og 606 hver gang kvantiteter, respektivt QI, QS og QA.

Oppfinnelsen kan bli implementert ved hjelp av en eller flere datamaskintabeller, logiske eller fysiske.

Spesialister i objektorientert programmering vil forstå at et ITEM-objekt er et underobjekt (instance) for en ITEM dass (klasse) som har egenskapene definert i appendiks A.1.1.2, hver med en korresponderende verdi for egenskapen for eksempel en mengdeangivelse QI og en forsinkelse DI om ITEM-objektET er berørt.

Det skal også nevnes at sorteringen av ITEM-objekter involverer sammenheng mellom ITEM og brønnen Pjtil hvilken den er koblet, siden det er nødvendig å supplere dataene DP og DI.

Etter disse sorteringer vil oppfinnelsen gjøre foranstaltninger for å utføre en løpen-de total fra initiale øyeblikk T0.

De løpende totaler blir utført på en sekvens av tidsluker som starter fra øyeblikket T0og er av valgt varighet. I det beskrevne eksemplet er tidsmålingsenheten dager, og en tidsluke kan tilsvare en dag eller et flertall av enkeltdager om ønskelig. Operasjonen 610 består i nullstilling av en indeks for en tidsluke i sekvensen betegnet

P-

Ved trinnet 612 utføres en summering (612a) fra tidsluke 0 og opp til tidsluke p for summen av lagerbeholdninger og innkjøp innenfor hver tidsluke, som resulterer i en størrelse Rp. Tilsvarende vil en summering fra den initiale tidsluke op til tidsluken p for verdiene ITEM_i bli utført (612B) samtidig med hver av disse tidsluker som gir som et resultat Bp.

Operasjonen 614 øker p. Om en maksimumsverdi som sammenfaller med en verdi for en fremtidig valgt områdeprojeksjon, om nødvendig i stand til å bli endret, om den ikke er nådd ved 616 så vil operasjonene 612 og 614 bli gjenstand for en ny iterasjon. Når maksimumsverdien P blir oppnådd vil resultatet bli brukt ved 618.

Formen gitt til operasjonen 612 er rent illustrativ. I virkeligheten vil prosedyren

heller bli iterativ: først av alt vil resultatene R0og B0bli beregnet for tidsluken 0, så ved passeringen av den etterfølgende passasje gjennom løkka Ri og Bi en beregner resultatene av RO og BO for tidsluken =, så i den etterfølgende passasjeløkka vil en beregne Ri og Bi ved å addere respektive R0og B0det som sammenfaller med tidsluke 1, osv.

Settene av resultater Bp for p=0 til pmaxblir nå betegnet B, og settene av ressurser Rp for p=0 til pmaxblir nå betegnet R. Disse verdier kan bli fremvist som en funksjon av tiden som vist i figur 8. Risiko for forsyningssvikt fremtrer der kurven for behov B er høyere enn kurven R for lagerbeholdning pluss reservasjoner (lagerbeholdning + ordre utført eller programmert), for eksempel mellom øyeblikkene Jl og 32 som illustrert ved skravering. Disse forhold kan evalueres med datamaskin ved trinnet 618.

Det ovenfor kan implementeres ved bruk av tilleggsobjektklasser, spesielt en objektklasse (TABLE_ELEMENT) for et tabellelement omfattende en mengde (Q) og en tid (t). En tilleggsklasse kan tilveiebringes for en datatabell, kalt for eksempel SEQUENCE, og omfatte TABLE_ELEMENT for hver tidsluke i sekvensen. Antallet tidsluker kan gjøres dynamisk variable.

Resultatene kan gjøres tilgjengelige for brukeren i en hvilken som helst annen form, for eksempel i form av tabellen illustrert i figur 9 som inkluderer mer informasjon.

I en utførelsesform bruker søkeren et flertall forskjellige skjermbilder for en og samme tabell der all informasjon resulterende fra prosessen er gruppert sammen. Avsløringen om knapphet må anspore lederen (personen som representerer leve-randøren på kundestedet) og forhandle frem at handlinger skal utføres: forsynings-ønsker til leverandører, identifikasjon av en planlagt bestilling (mengde, datoer), eller forslag til endringer. Automatisk ord regenerering er tenkelig. Samtidig kan en ordrebekreftelse bli tillagt for plassering i varelager, for nye produkter, eller for re-turnering av produkter som er omarbeidet som nye.

Alle operasjoner beskrevet over kan utføres i datamaskinen CSc som er tilgjengelig ved kundestedet. De bruker den lokale produksjonsplanen PcL, som etterfølger de lokale produksjonsvariasjoner Dtcl. Disse operasjoner utgjør det som blir referert til som en produksjonskontroll som kan utføres av kunden selv, av en av leverandøre-ne, eller av en tredje part. Det er for tiden betraktet som fordelaktig at produk-sjonskontrollen blir styrt av hovedleverandøren eller en av dem. "Main supplier"

(hovedleverandør) betyr den hvis produkter er viktigst for kunden, for eksempel i term av kritisk parameter og/eller volum, og/eller forsyningsforsinkelser spesielt. Hovedleverandøren kan også være den som er best egnet til å styre behovene for kunden med hensyn til andre leveranser.

Forbindelsen med en datamaskin CSf plassert på leverandørstedet gjør det mulig å umiddelbart endre leverandørproduksjonsplanen Pfo og også overvåke de lokale produksjonsvariasjoner DTfo om nødvendig.

Selvfølgelig kan lærdom fra den foreliggende oppfinnelse også implementeres på leverandørstedet, alternativt med hensyn til hans egne leverandører.

Det faktum at en arbeider i et nettverk tillater også applikasjonen å aksessere andre databaser om nødvendig, eller andre applikasjoner tilgjengelige i nettverket to-talt transparent for brukeren.

Funksjonelt tilbyr oppfinnelsen et datamaskinbasert system for å overvåke dårlige

forsyninger mellom leverandør, omfattende en monitoreringsmodul (50, 52) som er i stand til å opprettholde i minnet en datert tilstand for produktbehov (Ii; ti) assosiert med ett eller flere prosjekter (PO samtidig som tilstanden for lagerbeholdningene (Sj, tj) og innkjøpene (Ak, tk) for disse produkter. Denne monitoreringsmodulen omfatter en kontrollmodul (54), omfattende: en behovsmodul (module de besoin (612a) som er i stand til for hver enkelt produkttype å danne en første tabell assosiert med en sekvens av tidsluker som

har et valgt starttidspunkt, denne første tabellen assosierer med hver tidsluke en første løpende total av behovene (Bp) fra oppstarttidspunktet og opp til den aktuelle tidsluke;

en ressursmodul (un module de ressurs (612B)) som er i stand til for hver produkttype å produsere en andre tabell assosiert til sekvensen av tidsluker, denne andre tabell assosierer med hver tidsluke en andre løpende total (Rp) av lagerbeholdninger pluss innkjøp, fra oppstarttidspunkt og til den aktuelle tidsluke, der innkjøpene blir faseforskjøvet i henhold til en forsinkelse DA; DI), og

en komparator (618) for å overvåke tidene ved hvilke den andre løpende total

blir mindre enn den første som en indikator for risiko for leveringsmangel.

Datamaskinmessig vil det ovenfor beskrevne påkalle to "logiske" tabeller, nemlig en tabell for behovene og en tabell for ressursene (som i seg selv kan brytes ned til en tabell for lagerbeholdning og en tabell for innkjøp). I praksis kan en enkel "fysisk" tabell bli brukt som kombinerer de to ovenfor (eller flere) tabeller, tilhørighet til en av tabellene kan for eksempel indikeres ved et felt dedikert for den hensikt.

Oppfinnelsen relaterer seg også til en datamaskinfremgangsmåte for å overvåke dårlige leveranser mellom leverandør og kunde, der på kundesiden, hvert prosjekt (Pi) er assosiert med en datert tilstand for behov (Ij, ti) for produkter, og samtidig som det holdes en tilstand for lagrene (Sj; tj) og innkjøpene (Ak, tk) for disse produkter. Denne fremgangsmåte omfatter fordelaktig de følgende trinn: b. Produsere (50) en liste av produkttyper (Ij) involvert i en eller flere prosjekter

(Pi),

b. For hvert produkt av oppstrøms-typen (li) å etablere (612) i det minste en tabell (Bp, Rp), og for en sekvens av tidsluker ha valgt et oppstartstidspunkt,<*>for hver tidsluke ha en første løpende total fra oppstarttidspunktet til den aktuelle tidsluke for en første kvantitet ((Bp;) koblet til de foreldede kravene (Ii; ti) på kundestedet;<*>for hver tidsluke ha en andre løpende total fra oppstarttidspunktet og opp til den aktuelle tidsluke for en andre kvantitet (Rp) koblet til lagerholdet (Sj; tj) og innkjø-pene (Ak, tk), der innkjøpene har et tilvist skifte i henhold til en forsinkelse;

og

b. Se etter (618) de tidspunkter der den andre løpende totalen blir mindre enn den

første som indikatorer på en risiko for forsyningsmangel.

Med hensyn til datamaskinprosessering vil det være fordelaktig å anvende en en-keltløpende totalfunksjon. Oppfinnelsen kan derfor også bli sett på som et datamaskinbasert system for å overvåke dårlige leveranser mellom leverandør og kunde omfattende en monitoreringsmodul (50, 52) som er i stand til å vedlikeholde i minnet en datert tilstand av produktbehov (Ii; ti) assosiert med en eller flere prosjekter Pi, og samtidig tilstanden for lagerbeholdninger (Sj, tj) og innkjøp (Ak, tk) for disse produkter. Denne monitoreringsmodulen omfatter: - en løpende totalmodul (612) som er i stand til å motta som parametere pro-dukttypebetegnelsen, en modus og et oppstarttidspunkt og å produsere for pro-dukttypebetegnelsen en tabell som kan assosieres med suksessive tidsluker en løpende total for produktkvantiteter definert av modus der hver løpende total går fra oppstarttidspunkt og opp til den aktuelle tidsluke; og

en kontrollmodul (54) arrangert for:

<*>å kalle opp den løpende totalmodul (612) med en produkttype, og en modus som omfatter det fortløpende totale behovet på kundestedet som igjen leverer en første tabell; og<*>å kalle opp den løpende totale modul (612) med den samme produkttype, og en modus som omfatter den løpende totale lagerbeholdning i tillegg til tilbehøret (for eksempel leveranser) som forsyner en andre tabell; og<*>å se etter (618) tidspunktene der de løpende totaler i den andre tabell blir mindre enn de for den første tabell, som indikatorer for en risiko for forsyningsmangel.

Operasjonene ovenfor blir reiterert ved en passende rate med hensyn til hastighe-ten for endring i situasjonen. Fordelaktig vil de også bli reiterert i tilfelle av for-håndsbestemte hendelser som kan omfatte i det minste en av hendelsene i en gruppe omfattende: modifikasjon av en prosjektdato av kunden, endring av ti I— gjengelighetsdato av kunden, endring av leverandørforsinkelser fra leverandøren, endring av produktmengder som skal skaffes til veie, plassering av en ordre fra kunden til leverandøren, bekreftelse på en ordre, reservasjon av et produkt fra lager, levering av et produkt.

Fremgangsmåten kan også omfatte å ta i mot en ordre ikke senere enn en dato som i det vesentlige tilsvarer oppstårtsdatoen for det aktuelle prosjekt (DP) som er økt med en tilgjengelighetsforsinkelse (DI), og redusert ved en leveringsforsinkelse

(DA).

Det har blitt vist at den foreliggende oppfinnelse fungerer ved løpende totaler.

Problemet med en løpende total er at den normalt tenderer til å øke i det uendelige. I henhold til et annet aspekt ved oppfinnelsen vil informasjonen bli "resynkronisert"

(re-synchronisées) periodevis ved fjerning av utdaterte data for således å begrense dens plassbehov så vel som dens prosesseringstider.

Fordelaktig kan denne resynkroniseringen utføres i form av nullstilling av de løpen-de totaler hver gang behovene i det vesentlige korresponderer med ressursene, og om nødvendig i den utstrekning som er kompatibelt med behovet for fastlåsing på en aktiv måte (annen enn arkivert), et "historisk" bilde av operasjonen. Ved re-synkroniseringstidspunktet vil restforskjellen mellom behov og ressurser bli merket på nytt (re-qualifié) som en lagerbeholdning.

I det beskrevne eksemplet har borerør blitt nevnt som et eksempel. Oppfinnelsen kan utvides til forskjellige typer av andre produkter anvendbare under boreoperasjoner (eller "brønnkomponenter"), spesielt de som forbindes med rør: - såkalte tilpasningsrør ment spesielt for å justere lengden av rør i henhold til den aktuelle nedstigningslengden; - tverrforbindelser (gjengede forbindelser) brukt på stedet; så vel som mer kompleks tilbehør som ikke berører rø rp rod u senter men spesialist-leverandører slik som; sikkerhetsventiler; - foringsrørhengere;

nedre flottørsko for sementering;

brønnforingshengere.

Pa et annet nivå kan det være fordelaktig å knytte bestemte rørkomponenter med hverandre i tid og i antall, spesielt for tilbehør. Et eksempel på dette er illustrert i figur 10. Det er vanlig å montere et rørtilbehør ("SUPER_ACC") omfattende to ti I— pasningsrør ("PJ") assosiert med en sikkerhetsventil ("SV"). Datamaskinmessig vil dette gi: en "sikkerhetsventil" objekt av klasse SV, spesialisert ved objektattributter som kan omfatte en identifikator SV_ID, en monteringstid SV_DLY, og en egenskap SV_LINK, som vil bli diskutert senere; - et "tilpasningsrør" objektklasse PJ, spesialisert ved objektattributtene som kan omfatte en identifikator PJ_ID og en monteringstid PJ_DLY.

Ut fra dette kan et "rørtilbehør"-utvidet objekt SUPER_ACC bli definert som omfatter et underobjekt (instance) for objektklassen SV, og to underobjekter (instances) for objektklassen PJ, som definerer tilbehøret fullt ut.

Dette kan oppnås ved linken SV_LINK som for eksempel kan være en fremgangsmåte, da betegnet SV_LINK (), som kan aktiveres for å automatisk peke ut for eksempel ved deres identifikator eller identifikatorer PJ_ID de to tilpasningsrør som

matcher med identifikatoren SV_ID for sikkerhetsventilen som er oppstartspunktet for å danne tilbehøret SUPER_ACC. Den samme fremgangsmåten kan også synteti-sere installasjonsforsinkelsene SV_DLY og PJ_DLY for direkte å definere forventede forsinkelsen SUPER_ACC_DLY som skal tilveiebringes for tilbehøret SUPER_ACC. Dette enkle eksemplet viser hvordan det er mulig å ha brønnkomponenter koblet til hverandre i tid (forsinkelsene) og i mengde (to PJ-er for en SV).

Dette kan enkelt generaliseres til mer komplekse tilfeller.

Videre er den foreliggende oppfinnelse ikke begrenset til applikasjoner på boreste-der nevnt i denne detaljerte beskrivelsen. Applikasjonen er spesielt fremragende i

den forstand at den involverer svært forskjellige produkter i store volumer som har en lang produksjonstid og krever en spredt produksjonsressurs, og som er vanskelig å transportere, og videre også tilbehør, alt for en kundeapplikasjon som er vek-tig, stor og utvikler seg av natur. Bortsett fra dette vil de leverte rørproduktene kunne brukes som de er, eller noe modifisert. For rør er generelt kun enkle opera-

sjoner utført ved kundestedet: gjenging av rør in situ, eller tilpasning av rør som avledede produkter slik som de tidligere nevnte tilpasningsrør som kan dimensjone-res på stedet. Disse operasjoner er videre generelt utført av leverandøren eller en tredje part på kundestedet.

Oppfinnelsen kan selvfølgelig anvendes a priori til andre tekniske områder der halv-fabrikataprodukter og ikke-umiddelbar håndtering/transport gjelder spesielt for rør med tidsbegrensninger.

Oppfinnelsen er imidlertid også anvendbar på mange andre områder som innehar alle eller noen av de tidligere nevnte begrensninger uavhengig av tidsskala for ut-vikling. Den kritiske parameter vil faktisk fremstå å være sammenhengen mellom kostnader for mulig tapt tid og investering.

Den foreliggende oppfinnelse relaterer seg også til programvarekoden som den involverer med hensyn til fremgangsmåten eller systemet, mer spesielt når den er gjort tilgjengelig på et hvilket som helst medium som er lesbart av en datamaskin. Uttrykket "medium lesbart av en datamaskin" dekker et lagringsmedium, for eksempel magnetisk eller optisk, så vel som et transmisjonsmiddel, slik som et digi-talt eller analogt signal.

Appendiks 1

A.1.0 - notasjoner

- Brønn: P|

- datert tilstand for produktene (Item): (Ii;ti)

- datert tilstand av lagerbeholdningene: (Sj, tj)

- datert tilstand av innkjøpene: (Ak, tk)

A.1.1 - grunnleggende elementer

♦A.l.l.a {Pi, li, ti}

<*>A.l.l.b Ii; = f(Pi,t)

<*>A.l.l.c {Ij,Sj,tj)}

<*>A. 1.1.d {Ii;ti} => {Sj; tj}

<*>A.l.l.e {Ik; tk}

A.1.2 - Objekter (programvare) og deres egenskaper

Claims (19)

1. En databehandlingsfremgangsmåte for å overvåke dårlig leveranse mellom leve-randører) og kunde, for hvilke, på kundestedet, hvert prosjekt (Pi) er assosiert med en foreldet status av behov (Ii; ti) av produkter samtidig som det holdes en status for lagerbeholdningene (Sj; tj) og innkjøp (Ak, tk) for disse produkter,karakterisert vedat den omfatter de følgende trinn: a. produsere (50) en liste av produkttyper (Ij) involvert en eller flere prosjekter (Pi), b. for hvert produkt av oppstrøms-typen (Ij) å etablere (612) i det minste en tabell (Bp, Rp), og for en sekvens av tidsluker ha valgt et oppstartstidspunkt, for hver tidsluke ha et første løpende total fra oppstarttidspunktet til den aktuelle tidsluke for en første kvantitet ((Bp;) koblet til de foreldede kravene (Ii; ti) på kundestedet; for hver tidsluke ha en andre løpende total fra oppstarttidspunktet og opp til den aktuelle tidsluke for en andre kvantitet (Rp) koblet til lagerholdet (Sj; tj) og inn-kjøpene (Ak, tk), der innkjøpene har et tilvist skifte i henhold til en forsinkelse (DA, DI); og c. se etter de tidspunkter der de andre løpende totaler blir mindre enn de første som indikatorer på en risiko for forsyningsmangel og/eller et behov for å initiere nye forsyninger.

2. Fremgangsmåte i henhold til krav 1, karakterisert vedde følgende tilleggstrinn: d. forskyve nå og da de løpende totaler til et nytt oppstarttidspunkt definert ved et tidspunkt som i det vesentlige svarer til den første totale mengde og den andre totale mengde.

3. Fremgangsmåte i henhold til et av kravene 1 og 2,karakterisert vedat trinnene b. og c. blir reiterert i nærvær av forhåndsdefinerte hendelser.

4. Fremgangsmåte i henhold til krav 3, karakterisert vedat de forhåndsdefinerte hendelser omfatter i det minste en av hendelsene i gruppen omfattende: modifikasjon av prosjektdato av kunden, modifikasjon av tilgjengelighetsdato av kunden, endring av leve-ringsforsinkelsen fra leverandøren, endring av produktmengdene som skal tilveiebringes, plassering av en ordre fra kunden til leverandøren, bekreftelse av en ordre, reservering av et produkt fra lager, levering av et produkt.

5. Fremgangsmåte i henhold til et av kravene 1 til 4,karakterisert vedat trinn c. også omfatter det å ta opp en ordre ikke senere enn en dato som i det vesentlige samsvarer med oppstårtsdatoen for det aktuelle prosjekt (DP), økt ved en tilgjengelighetsforsinkelse (DI), og redusert ved en leveranseforsinkelse (DA).

6. Fremgangsmåte i henhold til et av kravene 1 til 5,karakterisert vedat trinn b. videre omfatter de følgende undertrinnene: bl. klassifisering av behovene (602), lagerbeholdningene (604) og innkjøpene (606), ved produkt og ved effektiv dato; b2. å danne en løpende total for behov for hvert produkt (612a) og for hver tidsluke i sekvensen fra oppstartstidspunktet som tilveiebringer den første tabell; og b3. å danne en løpende total for lagerbeholdning og leveranser (612b) tilveiebrakt for hvert produkt, og i hver tidsluke i sekvensen fra oppstarttidspunktet som leverer den andre tabell.

7. Et databehandlingssystem for overvåkning av manglende forsyning mellom le-verandører) og kunde, omfattende en overvåkningsmodul (50, 52) som er i stand til å lagre i minnet en datert statusliste for produktbehov (Ii; ti), assosiert med en eller flere prosjekter (Pi), og samtidig holde en status for lagerbeholdningen (Sj; tj) og innkjøp (Ak, tk) for disse produkter, karakterisert vedat overvåkningsmodulen omfatter en kontrollmodul (54), omfattende: - en nødvendighetsmodul (612a) i stand til for hver produkttype å produsere en første tabell assosiert med en sekvens av tidsluker som har et valgt oppstarttidspunkt i denne første tabell som assosierer hver enkel tidsluke med en første løpen-de total av behov (Bp) fra oppstarttidspunktet og opp til den aktuelle tidsluke; - en ressursmodul (612b) i stand til, for hver produkttype, å produsere en andre tabell assosiert med sekvensen av tidsluker der denne andre tabell assosierer med hver tidsluke en andre løpende total (Rp) av varebeholdning pluss innkjøp, fra oppstarttidspunktet og opp til den aktuelle tidsluke, der innkjøpene blir skiftet tidvis i henhold til en forsinkelse (DA; DI); og - en komparator (618) for å se etter tider ved hvilke de andre løpende totaler blir mindre enn de første som indikatorer på en risiko for leveransesvikt.

8. Et databehandlingssystem for overvåkning av manglende forsyning mellom le-verandører) og kunde, omfattende en overvåkningsmodul (50, 52) som er i stand til å lagre i minnet en datert statusliste for produktbehov (Ii; ti) assosiert med en eller flere prosjekter (Pj) og samtidig holde en status for lagerbeholdningen (Sj; tj) og innkjøp (Ak, tk) for disse produkter, karakterisert vedat overvåkningsmodulen omfatter: - en løpende totalmodul (612) som er i stand til å motta som parametere produkt-typebetegnelse, en modus og et oppstarttidspunkt, og å produsere for produktty-pebetegnelsen en tabell som kan assosieres med suksessive tidsluker en løpende total for produktkvantiteter definert av modus der hver løpende total går fra oppstarttidspunkt og opp til den aktuelle tidsluke; og - en kontrollmodul (54), arrangert for: å kalle opp den løpende totalmodul (612) med en produkttype, og en modus som omfatter det fortløpende totale behovet på kundestedet, som igjen leverer en første tabell; og å kalle opp den løpende totale modul (612) med den samme produkttype, og en modus som omfatter den løpende totale lagerbeholdning i tillegg til tilbehøret (for eksempel leveranser), som forsyner en andre tabell; og å se etter (618) tidspunktene der de løpende totaler i den andre tabell blir mindre enn de for den første tabell som indikatorer på en risiko av forsyningsmangel.

9. System i henhold til et av kravene 7 og 8, karakterisert vedat kontrollmodulen (54) også er organisert for å forskyve nå og da de løpende totaler til et nytt oppstarttidspunkt definert ved et tidspunkt som i det vesentlige svarer til den første totale mengde og den andre totale mengde.

10. System i henhold til et av kravene 7 til 9, karakterisert vedat kontrollmodulen (54) opererer på en reiterert måte i nærvær av forhåndsdefinerte hendelser.

11. System i henhold til krav 10, karakterisert vedat de forhåndsdefinerte hendelser omfatter i det minste en av hendelsene i en gruppe omfattende: modifikasjon av en prosjektdato fra kunden, endring av tilgjengelighetsdato fra kunden, endring av leve-ringsforsinkelser fra leverandøren, endring av produktmengder som skal forsynes, plassering av en ordre fra kunden til leverandøren, bekreftelse på en ordre, reservering av et produkt fra lager, levering av et produkt.

12. System i henhold til et av kravene 7 til 11, karakterisert vedat kontrollmodulen også er arrangert for å ta i mot en ordre, men ikke senere enn en dato som i det vesentlige svarer til opp-startsdatoen for det aktuelle prosjektet (DP) som er økt med en tilgjengelighetsforsinkelse (DI) og redusert ved en leveranseforsinkelse (DA).

13. System i henhold til et av kravene 7 til 12, karakterisert vedat det videre omfatter en tilstandsmodul, som er i stand til ved kundesiden å: - klassifisere behovene (602), lagerbeholdningene (604) og innkjøpene (606) ved produkt og ved effektiv dato; - danne en løpende total (612a) for behovene som er nødvendig for hvert enkelt produkt og i hver tidsluke i sekvensen som etablerer den første tabell; og å - danne en løpende total (612b) for summen av lagerbeholdninger i tillegg til inn-kjøp skaffet for hvert enkelt produkt, og i hver tidsluke i sekvensen som etablerer den andre tabell la kontrollmodulen operere med data for tilstandsmodulen.

14. System i henhold til krav 13, karakterisert vedat kontrollmodulen (54) i det minste delvis inkorporerer tilstandsmodulen.

15. System i henhold til et av kravene 7 til 14, karakterisert vedat overvåkningsmodulen omfatter en leder for en liste av oppstrømsprodukttyper involvert i ett eller flere prosjekter.

16. System i henhold til et av kravene 7 til 15 fungerende i objektorientert programmering, karakterisert veddet omfatter: - en objektklasse for produktene (ITEM); - en objektklasse for lagerbeholdningene (STOCK); - en objektklasse for innkjøpene (PURCHASE); og - en objektklasse (TABLE_ELEMENT) for et tabellelement omfattende en mengde (Q) og en tid (t).

17. System i henhold til krav 16, karakterisert vedat det videre omfatter en objektklasse for et prosjekt (Pi).

18. Produktprogram omfattende funksjonene for å utføre trinnene a. til c. for fremgangsmåten i henhold til kravene 1 til 6.

19. Produktprogram omfattende funksjonene for å overvåke moduler i systemet i henhold til et av kravene 7 til 17.