«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.