Hvordan kan AI hjelpe olje og gass? Der det virker i dag
AI for olje og gass
Plattformen deres produserer allerede mer data enn noen leser: prosessdatabasen, vedlikeholdssystemet, dagsrapportene, P&ID-ene, HMS-skjemaene. AI trenger ikke mer av det. Den trenger å vite hva det betyr, hvilken pumpe P-204 er, hva som mater den, og hvem som var på skift. AI trenger kontekst, og i olje og gass er konteksten anleggsmodellen dere allerede halvveis har. Denne siden sier hvor det lønner seg i dag, og hvor det ikke gjør det ennå, på premissene til AI- og dataplattformen.
Tre steder det allerede lønner seg, og ingen av dem er en chatbot
Lese skiftet, ikke dashbordet
En overlevering i dag er en person som husker tolv timer. En agent som leser de samme taggene, alarmene og arbeidsordrene, lager utkastet ut fra det som faktisk skjedde, med hver linje sporbar til en trend eller en hendelse. Den avtroppende lederen retter det på to minutter i stedet for å skrive det på tjue.
Fra trend til arbeidsordre
En lagertemperatur som kryper oppover i tre uker, er synlig for alle som ser etter. Ingen ser på hver tagg. En agent som vet hvilke tagger som hører til hvilken pumpe, og hvordan det står til med reservedelene, lager utkast til meldingen med trenden vedlagt. En planlegger godkjenner den, eller lar være.
Tall som kan vise inngangene sine
Fakkelvolum, brenngass, produsert vann: hvert rapporterte tall er en kjede av tagger, målere og korreksjoner. Når det blir stilt spørsmål ved det to år senere, bør svaret være en vandring tilbake gjennom den kjeden, ikke en leting etter den som bygde regnearket.
Dataene dere allerede har
En modell av plattformen, matet av systemene dere allerede kjører
Ingenting her er ny instrumentering. Prosessdatabasen har tiår med tagger, ERP-systemet har hver melding og arbeidsordre, dokumentsystemet har P&ID-ene og inspeksjonsrapportene, og dagsrapportene sier hva folk så. Det som mangler, er laget som knytter dem til samme utstyr. Den operasjonelle dataplattformen kopierer dem ut over standardprotokoller, uten å røre kontrollsystemene, og legger dem inn mot en modell: hvilken anleggsdel, hvilket system, hvilket prosesstog. Å få dataene inn er den lille delen av jobben, og det tekniske bildet sier hva plattformen er bygget av.
Prosessdatabasen er ikke problemet. Den er arkivet. Det som mangler, ligger over den.
De første oppgavene
Arbeid en agent kan ta i år, med et menneske som signerer
Den riktige første oppgaven er kjedelig, gjentatt og etterprøvbar: noen gjør den hvert skift eller hver måned, dataene den trenger finnes allerede, og et menneske kan lese utkastet på noen minutter. Product Discovery er to uker brukt på å finne den oppgaven på deres plattform. Disse tre er der det som regel lander.
Overleveringen
Utkast laget fra skiftets tagger, alarmer og arbeidsordrer, med hver linje lenket til trenden eller hendelsen den kom fra. Den avtroppende lederen redigerer og signerer. Ingenting sendes som et menneske ikke har lest.
Meldingen fra en trend
Vibrasjon eller temperatur som driver på en pumpe modellen kjenner, med reservedelen og forrige overhaling slått opp. Agenten lager utkast til meldingen; planleggeren avgjør om den blir en arbeidsordre.
Den avstemte tagglisten
Hver plattform har en taggliste, et vedlikeholdshierarki og et sett P&ID-er som er uenige i kantene. Agenten foreslår koblingene, med belegg, og en ingeniør bekrefter dem. Den avstemmingen er begynnelsen på grafen.
Kontekst, om bord
Et spørsmål går gjennom anlegget, ikke gjennom tagglisten
Spør hvorfor trykket i førstetrinnsseparatoren steg klokken 03:10, og et menneske begynner med det de vet: separatoren, utløpsventilen, pumpen på oljesiden, nivåregulatoren. Den kunnskapen mangler en agent med mindre den er skrevet ned. AI trenger kontekst, og på en plattform er konteksten grafen over hva som mater hva. Med den følger spørsmålet reelle relasjoner fra symptom til årsak, og svaret kommer med veien dit. Uten den har agenten førti tusen tagger og en anelse.
Veien er resonnementet. Hvert hopp er en relasjon noen modellerte en gang.
Med vilje fiksjon
Et postkort fra en plattform som ikke finnes
Dette har ikke skjedd. Det er skrevet ut fra delene over, og det står her fordi det høres ut som en skiftrapport, og det er poenget. Hvis det plager deg, er det nyttige spørsmålet hvilken del det ville feilet uten.
Natten separatoren ikke trippet
02:40. En agent som følger førstetrinnsseparatoren, ser at nivåregulatoren jobber hardere enn strømmen forklarer. Den går grafen: utløpsventilen XV-118 på oljesiden har stått kommandert åpen i seks timer, men trykket nedstrøms sier noe annet; P-204 trekker mindre enn kurven sin; ventilen ble sist overhalt for fjorten måneder siden. Den lager et notat til kontrollrommet med de tre trendene side om side, og en melding til dagskiftet. Operatøren leser det 02:46, kjører ventilen manuelt, ser trykket falle og lukker notatet med en linje. Ingenting trippet. Meldingen godkjennes 07:15 av noen som har sovet.
Der AI ikke hjelper dere ennå
Den kjører ikke prosessen; det gjør kontrollsystemet, og det skal fortsette urørt. Den erstatter ikke prosessdatabasen, som er et godt arkiv og kan forbli et. Den kjenner ikke plattformen deres fra første dag: der tagglisten, vedlikeholdshierarkiet og P&ID-ene er uenige, finner agenten hullene før den finner noe annet, og å tette dem er ingeniørarbeid, uker av det, ikke en nedlasting. Og den skal ikke utføre noe på egen hånd. På en plattform lager agenten utkastet og et menneske signerer, som er nøyaktig slik papirarbeidet fungerer i dag. Den kjører der dataene er: på deres servere, i et lukket nett eller på maskinvare vi eier i Stavanger, under norsk lov, og koden er åpen under AGPL-3.0. Resten av argumentet står på siden om AI- og dataplattformen.
Ærlige spørsmål
Det driftsteam spør oss om
Hvordan kan AI hjelpe olje- og gassdrift i dag?
I det gjentatte, etterprøvbare arbeidet: skiftoverleveringer skrevet ut fra prosessdatabasen, alarmene og arbeidsordrene; vedlikeholdsmeldinger laget fra en trend på utstyr modellen kjenner; rapporterte tall som fakkel og brenngass som kan vise hver tagg og korreksjon bak seg; og avstemming av tagglisten mot vedlikeholdshierarkiet og P&ID-ene. I alle tilfellene lager agenten utkastet og et menneske bestemmer.
Må vi bytte ut prosessdatabasen eller kontrollsystemet?
Nei. Kontrollsystemet røres ikke, og prosessdatabasen forblir arkivet den er. Plattformen kopierer data ut over standardprotokoller som OPC-UA til en modell av driften som ligger over dem, og det laget er additivt og reversibelt.
Hvilke data trenger en AI-agent på en plattform?
Mindre enn dere tror, bedre koblet enn de er. Taggene i prosessdatabasen, vedlikeholdssystemet, dagsrapportene og dokumentene dere allerede har, festet til samme utstyr i en modell, slik at agenten vet hvilke tagger som hører til hvilken pumpe, hva som mater hva, og hva som sist skjedde med den. Den konteksten er kunnskapsgrafen, og det er den som gjør en selvsikker gjetning til et svar med en vei.
Kan driftsdataene bli i vårt eget miljø?
Ja. Plattformen er åpen kildekode under AGPL-3.0 og kjører på deres egne servere, i deres sky eller i et lukket nett. Vil dere heller slippe å drifte den, kjører IntelliStream den på maskinvare selskapet eier i Stavanger, under norsk lov, og agentene når den via MCP med rettighetene til den som spør.
Hvor bør en operatør begynne?
Med en oppgave som gjentar seg hvert skift eller hver måned, og som et menneske kan sjekke på noen minutter: overleveringen er som regel den første. Bekreft at dataene den trenger kan kopieres ut fra der de ligger, modeller bare utstyret oppgaven berører, og kjør den med et menneske som signerer hvert utkast. Product Discovery er et to ukers oppdrag bygget for å finne den første oppgaven.
Begynn med ett skift, ikke hele plattformen
Fortell oss hvilken rapport folkene deres skriver etter hukommelsen i dag, og hvilke systemer den burde kommet fra. Vi sier ærlig fra om en agent kan lage utkastet nå, og hva modellen trenger først.