Tre drømmer for en annerledes fabrikk

Det er tre ting som alle som noen gang har satt i gang en industriell maskin har spurt seg minst én gang. Tre ting som man ikke sier høyt fordi de virker utopiske. Denne artikkelen stiller dem opp på rad.

En scene, bare for å begynne

Nattskift, avdeling X. En linje stopper. HMI-panelet viser en kode: E-1423. Manualen ligger i et skap tre bygninger unna. Teknikeren som kan den maskinen er på ferie. Operatøren har to veier å gå: ringe support – som kanskje svarer i morgen – eller gjette. I hele den industrialiserte verden gjentar slike scener seg hundrevis av ganger hver natt.

Problemet er ikke at det mangler en manual. Det finnes for mange manualer. Problemet er at maskinen vet veldig godt hva den trenger – trykksensoren har fortalt den i tretti sekunder at noe er galt – men den klarer ikke å snakke et språk som operatøren forstår, og når den klarer å snakke det, forteller den om problemet i stedet for løsningen. "Trykk utenfor rekkevidde" er ikke en nyttig setning klokken tre om natten. "Sjekk ventil V12 i luftkretsen, den har sannsynligvis satt seg fast" er det.

Det er her arbeidet vårt starter. Ikke en ny PLC. Ikke et penere HMI. En annen måte å tenke på hva programvaren som får en maskin til å bevege seg bør være i 2026. Og tre faste ideer – du kan gjerne kalle dem drømmer – som vi prøver å holde sammen.

Drøm nummer én: Automatiser uten å programmere

Industriell automatisering, slik den er i dag, krever en svært spesifikk figur: noen som kan programmere i et språk – IEC 61131-3-familien, med sine dialekter ladder, function block, structured text – som praktisk talt ikke brukes noe annet sted i programvareverdenen. De som kan disse språkene er sjeldne, dyre og er nesten alltid tre uker bak skjema.

Paradokset er at de som virkelig kjenner maskinen ofte ikke er programmereren. Det er avdelingslederen, den erfarne vedlikeholdsarbeideren, integratoren som har installert tjue lignende anlegg. Disse menneskene vet hva maskinen skal gjøre. De har ingen lyst til å lære et programmeringsspråk som ble født på 90-tallet for å forklare det.

Ideen er å snu kjeden. Programvareutviklere skriver gjenbrukbare komponenter – bevegelseskontroll, sensoradministrasjon, operasjonsekvenser – bare én gang, i moderne og generelle programmeringsspråk. Maskinintegratoren programmerer dem ikke: de komponerer dem, og spesifiserer muntlig eller skriftlig hva maskinen skal gjøre. En stor språkmodell – en LLM – fungerer som oversetter: den tar integratorens funksjonelle spesifikasjon og transformerer den til en kjørbar konfigurasjon, og setter sammen komponentene som allerede er skrevet og testet.

Dette er ikke fantasien om "AI som skriver koden for deg". Det er noe mer beskjedent og mer realistisk: AI som leser spesifikasjonen din og velger, blant sertifiserte komponenter, hvordan de skal kombineres. Kritisk kode – den som beveger en akse med en syklus på 5 millisekunder – fortsetter å bli skrevet av et menneske, i et språk som garanterer determinisme og pålitelighet. Men den koden skrives én gang for alle og gjenbrukes hundre ganger.

Drøm nummer to: maskinen som vet om seg selv

I dag snakker maskinene lite, og dårlig. En alarm er en numerisk kode. En diagnose er en serie med LED-lys. En logg er en binær fil som bare produsenten kan åpne. Kunnskapen om hvordan den maskinen fungerer, med de toleransene, etter de to tusen syklusene, ligger i hodet på en person, eller i en PDF et sted.

Den andre drømmen er at det er maskinen som kjenner seg selv. Ikke i mystisk forstand – i en veldig konkret forstand: den tekniske dokumentasjonen, prosessparametrene, typiske feilscenarier og intervensjonsprosedyrene ligger ikke lenger i et skap eller på en separat dokumentserver, men inne i selve maskinen, lesbare av dens egen programvare. Og når noe går galt, sier ikke maskinen "feil 1423". Den sier "ventilen V12 har sannsynligvis satt seg fast, du bør sjekke den; i mellomtiden kan jeg fortsette i nedgradert modus med 60 % av hastigheten".

Forskjellen er mellom et passivt objekt som signaliserer og et aktivt objekt som foreslår. Det første overlater problemet til operatøren. Det andre takler det sammen med ham.

Dette krever to ting som ikke er selvfølgelige. For det første at maskinkunnskap – historisk sett bevart i manualer, elektriske skjemaer, CAD-tegninger og hodene til teknikere – formaliseres og integreres i systemet. For det andre at systemet har en samtalepartner som er i stand til å føre en samtale: igjen, en LLM, brukt her ikke til å generere kode, men til å oversette symptomer til forståelige handlinger, på språket til den som står foran panelet.

Igjen, det er ikke magi. Det er bedre skrevet, bedre indeksert dokumentasjon, og et samtalebasert grensesnitt over det. Men det endrer alt for den som har nattskift.

Drøm nummer tre: programvaren som kjører overalt

Den tredje drømmen er den mest tekniske og, paradoksalt nok, den mest politiske. I dag er industriell automatisering en verden av lukkede økosystemer. Hver stor PLC-produsent har sitt eget språk, sitt eget utviklingsmiljø, sin egen maskinvare, sine egne drivere, sitt eget forhandlernettverk. Å bytte leverandør betyr å skrive alt på nytt.

Ambitionen her er å bygge et programvaresystem som kjører på generisk maskinvare – en mini-industri-PC, en innebygd kontroller, en server i kjelleren – og velge maskinvare basert på budsjett og nødvendig ytelse, ikke basert på hvilket merke av PLS som vant forhandlingen. Et Linux-operativsystem i sanntidsversjon, kommunikasjonskort basert på åpne standarder (EtherCAT for alle), programvarekomponenter i moderne språk for de deterministiske delene og i mer smidige språk for de som ikke er det.

Regelen, og her blir utopien konkret: maskinvaren må påvirke ytelsen, aldri påliteligheten. Den samme logikken, på en mindre kraftig maskin, må fungere identisk – bare tregere. Hvis syklustiden går fra 5 til 10 millisekunder, beveger aksen seg med samme presisjon, men med halv hastighet. Aldri "nesten likt". Aldri "fungerer bortsett fra i det tilfellet". Samme system, samme beslutninger, samme garantier.

Dette er delen der erfarne ingeniører begynner å le. De vet veldig godt at sanntid er vanskelig, at Linux ikke ble født som et sanntidssystem, at LLM-er ikke kjører på en Raspberry Pi, at å blande forskjellige språk i samme stack har flere fallgruver enn tutorials lover. De har rett. Men retningen er den, og byggeklossene for å bygge den – sanntidsutvidelser av Linux-kjernen, modne åpen kildekode EtherCAT-stacker, LLM-er som begynner å kjøre på beskjeden maskinvare – eksisterer, i dag, for første gang alle sammen.

Hvorfor "utopi"

Utopia er et ærlig ord. Ingen av disse tre tingene er, i dag, et ferdig produkt. Den første krever LLM-er som er pålitelige nok til å brukes i en produksjonskontekst, og vi er i begynnelsen. Den andre krever et enormt arbeid med å formalisere industriell kunnskap, som i dag nesten utelukkende er uformell. Den tredje krever å bygge åpne alternativer mot lukkede økosystemer som har tjue års forsprang.

Men de tre drømmene sammen, når de settes opp på rad, tegner en klar retning: en automatisering der maskinvaren er en vare, programvaren er gjenbrukbar, kunnskapen er innebygd i maskinen, og figuren til PLC-programmereren – i dag en flaskehals i en hel industri – forsvinner ikke, men flyttes dit den virkelig trengs, det vil si å skrive grunnkomponentene én gang for alle.

I artiklene som følger vil vi fortelle om brikkene vi bygger i dette puslespillet. Én etter én, uten å love at puslespillet er komplett. Det er det ikke. Men tegningen begynner å bli synlig.