Gapet mellom «noe fysisk skjer» og «et tall dukker opp i databasen din» er der de fleste datakvalitetsproblemene bor. Hvis du bare har jobbet på databasesiden, er det gapet usynlig. Dette innlegget er et kart over det.

Vi skal følge en enkelt temperaturavlesning fra en varmeveksler hele veien til en skyapplikasjon, steg for steg. På hvert trinn viser jeg hva dataene ser ut som, hva som kan gå galt, og hva koden din bør ta høyde for.

Steg 1: Den fysiske målingen

En PT100 motstandstemperaturføler er montert i et rør. Motstanden endrer seg med temperaturen, forutsigbart men ikke perfekt. Alle PT100-er har en toleranseklasse. Klasse B (det billigere alternativet) har en nøyaktighet på ±0,3°C ved 0°C, som øker til ±1,3°C ved 300°C.

Sensoren din er allerede en tilnærming.

Det er også installasjonen å tenke på. Er sensoren montert riktig i strømmen? Er det luft rundt den som kan påvirke avlesningen? Har den vært i drift i 10 år uten rekalibrering? Sensordrift, der en sensors output gradvis avviker fra den sanne verdien over tid, er vanlig og ofte uoppdaget.

Husk: Den fysiske målingen har iboende usikkerhet. Dataene dine har feilmarginer allerede før de forlater sensoren. ±1°C er normalt. På en varslingsterskel på ±0,5°C betyr det noe.

Steg 2: Signaloverføring (4-20mA)

PT100-ens motstand konverteres til et 4-20mA strømsignal av en transmitter. Denne strømmen overføres via kabel til et inngangskort i en PLS eller fjern-I/O.

4-20mA er en svært gammel standard og bevisst enkel og vanskelig å ødelegge: det er en strømsløyfe, så motstand i kabelen påvirker ikke avlesningen, og en brutt ledning er detekterbar (0mA betyr feil, ikke null). Men den har begrensninger:

• 16mA-området (4 til 20) tilsvarer hele det tekniske området (for eksempel 0-200°C). Oppløsningen din begrenses av hvor fint analog-til-digital-omformeren på inngangskortet kan dele opp det området.
• Kabellengde og elektromagnetisk interferens kan introdusere støy. Et variabelfrekvensomformermotor i nærheten kan injisere nok støy til å få en avlesning til å hoppe med flere trinn.
• Konverteringen fra strøm til verdi bruker et kalibrert spenn. Hvis transmitteren er konfigurert for 0-200°C, men området er endret til 0-150°C og ingen har rekonfigurert det, er alle avlesninger feil skalert.

Husk: Innen den fysiske målingen har blitt et digitalt tall i PLSen, er den allerede skalert, kvantisert og potensielt påvirket av elektrisk støy.

Steg 3: PLSens skansyklus

PLSen leser inngangene sine, utfører logikken sin og oppdaterer utgangene, i en syklus som gjentas hvert 10-100ms. Når du ber om en verdi fra PLSen, får du det som lå i minnet fra siste skan.

Dette introduserer en forsinkelse på opptil én skansyklus mellom den fysiske verden og PLSens bilde av den. For trege prosesser (temperaturer, trykk, nivåer) er dette irrelevant. For raske hendelser (en ventil som åpner i 20ms) kan du gå glipp av den helt.

Tidsstempelet på en PLS-verdi er vanligvis tidspunktet den ble lest av SCADA-systemet, ikke tidspunktet den fysiske hendelsen skjedde. Disse kan avvike med sekunder avhengig av pollingfrekvens.

Husk: PLS-verdier er prøver, ikke en kontinuerlig strøm. Hendelser raskere enn skansyklusen er usynlige. Tidsstempelet er ofte «da vi spurte», ikke «da det skjedde».

Steg 4: SCADA / historikk

SCADA-systemet poller PLSen og lagrer verdier i en historikk (historian), en tidsserie-database bygget for industrielle data. Historian-systemer bruker en teknikk kalt unntaksrapportering eller deadbanding: de lagrer bare en ny verdi hvis avlesningen har endret seg med mer enn en konfigurert terskel.

Hvis temperaturen din er stabil på 73,2°C, kan historikken lagre den verdien én gang og deretter ikke igjen på en time. Dette er effektivt for lagring, men det betyr:

• Spørring i historikken etter «verdien kl. 14:32:17» returnerer den siste registrerte verdien før det tidspunktet, som kan være fra kl. 14:00. Hvis du ikke er klar over dette, ser trenden din flat ut fordi den er flat i databasen, ikke nødvendigvis flat i virkeligheten.
• Terskelen for «endret nok til å lagre» er en konfigurasjonsparameter. Hvis noen satte den til 5°C for å spare lagringsplass, vil du aldri se små svingninger.

Husk: Historikkdata er ikke et komplett register over hva som skjedde. Det er en komprimert tilnærming. Flate linjer i dataene kan bety «ingenting endret seg» eller «vi sluttet å registrere små endringer».

Steg 5: Skypipelinen

Historikken eksporterer data til skypipelinen din via en MQTT-broker, OPC-UA-server eller et spesialtilpasset API. Hvert av disse legger til egne hensyn:

• Buffering: Hvis tilkoblingen faller, bufrer det lokale systemet usendte data? Hvor lenge? Hva skjer ved gjenkobling? Sender det en burst, eller slipper det gapet?
• Resampling: Hvis skypipelinen forventer data i 1-minuttsintervaller, men historikken sender ved endring, må du resample. Forward-fill? Interpolering? Valget endrer dataene.
• Tidssoner: Industrielle systemer bruker ofte lokal tid. Skypipelinen din forventer sannsynligvis UTC. Hvis historikken er i Norge (CET/CEST), har du en sesongbasert 1-times forskyvning å håndtere.

Husk: Skypipelinen introduserer sin egen forsinkelse, bufferingsatferd og resampling-beslutninger. Hver av dem er en transformasjon som bør være eksplisitt i skjemaet ditt og dokumentert.

Steg 6: Applikasjonen din

Innen en temperaturavlesning når applikasjonen din, har den blitt:

1. Målt med iboende usikkerhet (±1°C eller mer)
2. Overført som et analogsignal og konvertert til digitalt
3. Prøvetatt ved PLSens skansyklus
4. Komprimert av deadbanding i historikken
5. Overført over et nettverk som kan bufre eller miste verdier
6. Resampled for å passe pipelinens kadense

Tallet i databasen din er ikke «temperaturen på det tidspunktet». Det er den beste tilgjengelige tilnærmingen, gitt alt det ovenstående.

Hva du kan gjøre med det

Dokumenter usikkerheten. Legg til metadata i skjemaet ditt: sensortype, nøyaktighetsklasse, historian-deadband, pollingintervall. Fremtidens deg, eller utvikleren som feilsøker en anomali kl. 02:00, trenger dette.

Vær konservativ med varslingsterskler. Hvis varselet ditt utløses når temperaturen overskrider 95°C og sensornøyaktigheten din er ±1,5°C i det området, lyver kanskje varselet.

Ikke interpoler stille. Hvis du resampler sparsomme historikkdata, gjør det synlig. En verdi fylt fra en avlesning som er 30 minutter gammel, er annerledes enn en verdi prøvetatt for 10 sekunder siden.

Valider område og endringstakt. En PT100 som måler en rørtemperatur som hopper fra 70°C til 500°C på ett sekund, er sannsynligvis en sensorfeil, ikke virkelighet. Industrielle prosesser har fysiske grenser. Håndhev dem ved inntak.

Spør operatørene. Menneskene som drifter anlegget, vet hvilke sensorer som er pålitelige og hvilke som «alltid leser litt høyt». Den kunnskapen er sjelden i dokumentasjonen.

Sensordataene du jobber med er ærlige om hva de er, hvis du vet hvordan du skal lese dem. Hele stacken er konteksten. Uten den optimaliserer du kode på toppen av usikkerhet du ikke har tatt høyde for.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.

«Hva er deres oppetidskrav?»

«99,9 prosent.»

«Det er omtrent 8 timer nedetid i året. Det kan vi jobbe med.»

«Nei, 99,9 prosent per skift. Vi kjører 24/7. Og hvis systemet går ned midt i et batchkjør, mister vi hele batchen.»

IT-utvikleren nikker, noterer noe, og regner stille om.

Hva oppetid betyr i IT

I webtjenester er oppetid et statistisk mål. Load balanceren fordeler trafikk. En rullende utrulling tar ned én instans om gangen. Hvis en deploy går galt, ruller du tilbake. Brukeren prøver forespørselen på nytt. Kanskje de ser en feilside i noen sekunder.

99,9 prosent oppetid betyr omtrent 8,7 timer nedetid per år. For de fleste webapplikasjoner er det akseptabelt. Modellen forutsetter at systemets tilstand er gjenopprettbar.

Hva oppetid betyr i OT

I industrielle styringssystemer er ikke «systemet» programvaren. Det er den fysiske prosessen programvaren styrer.

Et vannbehandlingsanlegg pauser ikke mens du ruller tilbake en SCADA-oppdatering. En sementkjerne som kjører på 1400°C venter ikke på din deployment-pipeline. En papirmaskin som kjører på 1000 meter per minutt prøver ikke på nytt når din historikk går offline.

Den fysiske prosessen fortsetter uansett om programvaren er frisk eller ikke. Og hvis programvaren mister kontrollen over prosessen, selv kortvarig, måles konsekvensene i:

• Tapte batcher
• Skadet utstyr fra drift utenfor trygge parametere
• Produkt utenfor spesifikasjon som må kastes
• I verste fall: branner, personskader, miljøhendelser

Tilbakestillingsproblemet

Webutviklere behandler tilbakestilling som et sikkerhetsnett. I industrielle systemer er tilbakestilling ofte ikke et alternativ midt i en prosess.

Hvis en PLC-programoppdatering går galt midt i en batch, kan du ikke bare gjenopprette den forrige versjonen og fortsette. Den fysiske tilstanden til prosessen har endret seg. Temperaturer, trykk og kjemiske sammensetninger er nå annerledes enn det den forrige versjonen forventet.

Dette er grunnen til at industrielle systemer har endringsstyringsprosesser som virker byråkratiske for IT-øyne: planlagte vedlikeholdsvindu, testede tilbakestillingsprosedyrer, operatørgodkjenninger. Det er ikke byråkrati for sin egen skyld. Det er bygget rundt virkeligheten at programvaren styrer noe som ikke stopper.

Hva du bør gjøre

Hvis du skriver programvare som kommuniserer med industrielle systemer:

Grasiøs degradering ser annerledes ut her. I OT betyr det at styringssystemet fortsetter å operere trygt i manuell modus mens programvaren din er nede. Utform den overgangen eksplisitt.

Test mot de fysiske begrensningene, ikke bare de programvaremessige. Hva skjer med systemet ditt når nettverket faller ut i 30 sekunder? Hva gjør PLS-en? Hva ser operatøren?

Forstå prosessen før du rører den. Operatørene som driver anlegget vet ting om feilmoder som ikke er i noen dokumentasjon. Snakk med dem før du skriver en linje kode.

SLA-tallet på kontrakten er den enkle delen. Å forstå hva det faktisk betyr for det som styres, er den vanskelige delen.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.

Jeg startet som elektriker. Så lærte jeg å skrive programvare, og de siste årene har jeg bygget IoT-løsninger i energibransjen. Til høsten starter jeg på en treårig fagskoleingeniør-utdanning i Industriell Automasjon ved siden av jobben. Studiet dekker fag som PLS, instrumentering, industrielle nettverk og OT-sikkerhet.

Det er et bevisst valg. Broen mellom IT og OT, mellom utvikleres skybaserte verden og industrielle styringssystemers fysiske verden, er et sted jeg synes er reelt interessant, og et sted der svært få er komfortable på begge sider.

Denne bloggen er der jeg skal skrive om det jeg lærer underveis. Forvent innlegg om:

• De rare og nyttige stedene der IT og OT møtes
• Industriell cybersikkerhet sett med utviklerøyne
• Praktiske eksperimenter med PLS-er, sensorer og hjemmelaber
• Erfaringer fra å bygge IoT i stor skala i energibransjen
• Det meste annet jeg finner verdt å dele underveis i studiet

Jeg skriver når jeg har noe å si, ikke på en plan. Noen innlegg blir tekniske dypdykk; andre blir kortere refleksjoner. Alt skrives i mine egne ord, og koden bak prosjektene ligger åpent på GitHub-en min.

Hvis noe av dette virker interessant, så er du velkommen tilbake.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.