Historikken ligger i systemet som samlet den inn. AVEVAs eget kurs i PI-administrasjon beskriver den vanlige formen: et grensesnitt leser styresystemet og sender verdiene inn i et PI Data Archive på sin egen server, og en klient spør det arkivet (PI System Administration). Ignition skriver tagghistorikk til en SQL-database, eller til en fil inne i Ignition (Ignition Tag Historian). WinCC holder trendene på WinCC-maskinen, og en CSV er en eksport noen kjører, eller et skript (WinCC Unified Logging). IGSS, som brukes i vann, har en objekt-historiker på IGSS-serveren og eksporterer graf eller logg til CSV derfra (IGSS). En fil på en annen maskin finnes når noen har satt opp en rapportjobb, eller når en operatør tar filen ut. Det er ikke det disse systemene gjør av seg selv.
Norsk Vann skrev i 2026 at en kommunes driftsdata ligger spredt på driftskontroll, ledningsregister, økonomisystem og regneark, og at rapporteringen ofte er manuelt arbeid fordi systemene er dårlig lagt til rette for direkte eksport (rapport 300/2026). Noen norske driftskontrollanlegg lagrer historikken i leverandørens sky (én av dem skriver det på sin egen side). Det første spørsmålet på anlegget er derfor hvor tallene tas ut i dag, og hvem som har lov til å lese lageret de ligger i.
Hvem
Tre personer, og den tredje venter. Den som allerede tar tall ut av driftskontrollen: en operatør, eller integratoren som bygde den. En ingeniør som kjenner anlegget, en ettermiddag, for å svare på taggene Auge avslår. IT og OT-sikkerhet når en levende lesing er ønsket, fordi det er en lesekonto og, der nettene er skilt, en brannmurregel. En første uke på en kopi av filer trenger de to første.
Hvor det kjører
Én maskin anlegget allerede eier, på nettverket der disse dataene allerede får være. En PC eller en virtuell maskin ved siden av historikeren eller SCADA-serveren, i driftssonen eller i den demilitariserte sonen. De første ukene holder det med en bærbar maskin og en kopi av filene. På Windows er det én zip, pakket ut i en mappe, med sin egen Python: ingenting installeres, og den trenger ikke administratorrettigheter. På Linux er det Python og numpy. Språkmodellen, hvis dere slår den på, kjører på den samme maskinen. Programmet settes ikke på en PLS, et panel eller en kontroller.
Det samme programmet kjører i deres egen skykonto når filene, eller en MQTT-broker, allerede ligger der: én container på Azure, AWS, Google Cloud eller deres egen Kubernetes, på et privat nett. Et anlegg som vil ha en del av arbeidet i skyen, lar leseren stå ved dataene og kjører konsollen i kontoen. Et anlegg som vil at målingene skal bli på stedet, bruker maskinen og hopper over containeren. Vi drifter ikke dataene. Hva som er låst ned, og hva vi ikke har satt ut.
Mens det kjører, bruker det ikke internett. Det finnes ingen lisensserver og ingen telemetri. Innlogging gjennom Entra ID, eller en annen identitetstjeneste, trenger en vei til den tjenesten på port 443, så et nett uten den veien bruker navngitte kontoer på maskinen. Innlogging er avslått til dere slår den på. Det et sikkerhetsteam kan sjekke, også den forseglede kjøringen, står på sin egen side.
Tre veier inn
En fil anlegget allerede lager. CSV eller Excel, på anleggets eget språk og med dets egen klokke, noen uker av det, og en instrumentindeks som PDF hvis den finnes. Dette er dag én, og det åpner ingen økt mot styresystemet. Noen tar filen ut, eller en rapportjobb anlegget allerede kjører, skriver den. Vi forutsetter ikke at den jobben finnes.
Et lesespørsmål til lageret som allerede har historikken, når bildet skal flytte seg uten at en person kopierer filer. AVEVA PI gjennom Web API, hvert kall et GET. En SQL-historiker på formen Ignition bruker. OPC UA, én utgående økt til en server anlegget allerede kjører. Hver av dem skriver timefiler inn i den samme mappen, og resten av produktet leser mappen. Hver er testet mot en server vi kjørte selv. Ingen av dem er prøvd mot en kundes PI-server, Ignition-database eller OPC UA-server. En ekte PI-server trenger sitt sertifikat og en lesekonto, og det har vi ikke satt opp. MQTT abonnerer på en broker anlegget, eller skykontoen deres, allerede kjører, og skriver de samme filene. Den publiserer ingenting. Den er testet mot en broker testene kjører, ennå ikke mot en kundes broker, og den leser ikke Sparkplug B. Vi skriver ingen driver for Modbus, S7 eller EtherNet/IP. Det laget blir hos anleggets egen gateway.
En kopi som allerede forlater driftsnettet, når en slik finnes: en rapport på tid, et filområde en jobb allerede skriver til, eller en andre historiker i den demilitariserte sonen. Ligger historikken i en leverandørs sky, er det et annet nett, og det sies før noen behandler anlegget som forseglet.
Hvor ferskt det er
Like ferskt som den siste filen i mappen, eller som siste spørsmål når en leser er på. Mappen sjekkes hvert halve minutt. Nye målinger på tagger den allerede forstår, legges til uten at anlegget regnes ut på nytt. Det regnes ut helt når taggene endrer seg, når noen svarer, og minst hver time. Det er ferskt nok til et skift, og til en sensor som døde i morges. Det står utenfor reguleringssløyfen. Første gjennomgang trenger uker med historikk, og derfor er lageret som allerede har de ukene, den nyttige kilden. En fil fra i morges alene er en tynn start. Når mappen er regnet ut, skrives skiftlappen inn i den som auge-shift.md: hva som flyttet seg, hva som ble stille, og hvilke åpne arbeidsordrer dataene fortsatt støtter. Den forrige lappen beholdes ved siden av, og den nye filen lister linjene som ikke sto i den. En språkmodell skriver den ikke. En person kan legge til en linje under Notater. Ingenting i filen sendes.
Det vi ikke har gjort
Vi har ennå ikke lest en eksport fra et norsk vannverk. Eksportene vi har målt, kommer fra forsyningsselskaper og anlegg som har publisert dataene sine i Danmark, Storbritannia, Tyskland og Spania, og fra et testanlegg. Kravene og det som feilet, står på resultatsiden.