Tre drømme for en anderledes fabrik

Der er tre ting, som enhver, der nogensinde har sat en industriel maskine i gang, har spurgt sig selv om mindst én gang. Tre ting, man ikke siger højt, fordi de virker utopiske. Denne artikel sætter dem i række.

En scene, bare for at starte

Nattevagt, afdeling X. En linje stopper. HMI-panelet viser en kode: E-1423. Manualen ligger i et skab tre bygninger væk. Den tekniker, der kender maskinen, er på ferie. Operatøren har to muligheder: ringe til support – som måske svarer i morgen – eller gætte sig frem. I hele den industrialiserede verden gentages scener som denne hundredvis af gange hver nat.

Problemet er ikke, at der mangler en manual. Der er for mange manualer. Problemet er, at maskinen udmærket ved, hvad den har brug for – tryksensoren har fortalt den i tredive sekunder, at noget er galt – men den kan ikke tale et sprog, som operatøren forstår, og når den kan tale det, fortæller den om problemet i stedet for løsningen. "Tryk uden for rækkevidde" er ikke en nyttig sætning klokken tre om natten. "Kontroller ventil V12 i luftkredsløbet, den er sandsynligvis klistret" er det.

Det er her, vores arbejde starter. Ikke en ny PLC. Ikke en flottere HMI. En anderledes måde at tænke på, hvordan softwaren, der får en maskine til at bevæge sig, bør være i 2026. Og tre faste ideer – kald dem gerne drømme – som vi forsøger at holde sammen.

Drøm nummer et: Automatiser uden at programmere

Industriel automatisering, som den er i dag, kræver en meget speciel figur: nogen, der kan programmere i et sprog – IEC 61131-3-familien, med sine ladder-, function block- og structured text-dialekter – som praktisk talt ikke bruges andre steder i softwareverdenen. Dem, der kan disse sprog, er sjældne, dyre og er næsten altid tre uger bagud.

Paradokset er, at dem, der virkelig kender maskinen, ofte ikke er programmøren. Det er afdelingslederen, den erfarne vedligeholdelsestekniker, integratoren, der har installeret tyve lignende anlæg. Disse mennesker ved hvad maskinen skal gøre. De har ingen lyst til at lære et programmeringssprog, der blev født i 90'erne, for at forklare det.

Ideen er at vende kæden på hovedet. Softwareudviklere skriver genanvendelige komponenter – bevægelseskontrol, sensorstyring, operationelle sekvenser – kun én gang, i moderne og generelle programmeringssprog. Maskinintegratoren programmerer dem ikke: de sammensætter dem, specificerer mundtligt eller skriftligt, hvad maskinen skal gøre. En stor sprogmodel – en LLM – fungerer som oversætter: den tager integratorens funktionelle specifikation og omdanner den til en eksekverbar konfiguration, der samler de allerede skrevne og testede komponenter.

Det er ikke fantasien om "AI, der skriver koden for dig". Det er noget mere beskedent og mere realistisk: AI, der læser din specifikation og vælger, blandt certificerede komponenter, hvordan de kombineres. Kritisk kode – den, der bevæger en akse med en 5 millisekunds cyklus – fortsætter med at blive skrevet af et menneske, i et sprog, der garanterer determinisme og pålidelighed. Men den kode skrives én gang for alle og genbruges hundrede gange.

Drøm nummer to: maskinen, der ved, hvad den er

I dag taler maskinerne lidt og dårligt. En alarm er en numerisk kode. En diagnose er en række LED'er. En log er en binær fil, som kun producenten kan åbne. Viden om, hvordan den maskine fungerer, med de tolerancer, efter de to tusinde cyklusser, ligger i en persons hoved, eller i en PDF et eller andet sted.

Den anden drøm er, at det er maskinen, der kender sig selv. Ikke i mystisk forstand – i en meget konkret forstand: den tekniske dokumentation, procesparametrene, typiske fejlscenarier, interventionsprocedurerne er ikke længere i et skab eller på en separat dokumentserver, men inde i selve maskinen, læselige af dens egen software. Og når noget er galt, siger maskinen ikke "fejl 1423". Den siger "ventilen V12 er sandsynligvis klistret, du bør kontrollere den; i mellemtiden kan jeg fortsætte i nedgraderet tilstand med 60% af hastigheden".

Forskellen er mellem et passivt objekt, der signalerer, og et aktivt objekt, der foreslår. Det første overlader problemet til operatøren. Det andet tackler det sammen med ham.

Dette kræver to ting, der ikke er selvfølgelige. For det første, at maskinens viden – historisk set gemt i manualer, elektriske diagrammer, CAD-tegninger og teknikernes hoveder – formaliseres og integreres i systemet. For det andet, at systemet har en samtalepartner, der er i stand til at føre en samtale: igen en LLM, der her bruges ikke til at generere kode, men til at oversætte symptomer til forståelige handlinger, på sproget hos den person, der står foran panelet.

Endnu en gang, det er ikke magi. Det er bedre skrevet, bedre indekseret dokumentation og en samtalebaseret grænseflade ovenpå. Men det ændrer alt for den, der tager natteskiftet.

Drøm nummer tre: softwaren der kører overalt

Den tredje drøm er den mest tekniske og paradoksalt nok også den mest politiske. I dag er industriel automatisering en verden af lukkede økosystemer. Hver stor PLC-producent har sit eget sprog, sit eget udviklingsmiljø, sit eget hardware, sine egne drivere, sit eget netværk af forhandlere. At skifte leverandør betyder at skrive alt om.

Ambitionen her er at bygge et softwaresystem, der kører på generisk hardware – en mini-industri-pc, en embedded controller, en server i kælderen – hvor hardwaren vælges ud fra budget og nødvendige præstationer, og ikke ud fra hvilket mærke PLC der vandt forhandlingen. Et Linux-operativsystem i realtidsversion, kommunikationskort baseret på åbne standarder (EtherCAT til alle), softwarekomponenter i moderne sprog til de deterministiske dele og i mere agile sprog til dem, der ikke er det.

Reglen, og her bliver utopien konkret: hardwaren skal påvirke ydeevnen, aldrig pålideligheden. Den samme logik skal fungere identisk på en mindre kraftfuld maskine – bare langsommere. Hvis cyklustiden går fra 5 til 10 millisekunder, bevæger aksen sig med samme præcision, men med halv hastighed. Aldrig "næsten det samme". Aldrig "virker bortset fra i det tilfælde". Samme system, samme beslutninger, samme garantier.

Dette er det punkt, hvor erfarne ingeniører bryder ud i latter. De ved udmærket godt, at real-time er svært, at Linux ikke er født som et real-time system, at LLM'er ikke kører på en Raspberry Pi, og at blanding af forskellige sprog i den samme stack har flere faldgruber end tutorials lover. De har ret. Men retningen er den, og byggestenene til at bygge den – real-time udvidelser af Linux-kernen, modne open source EtherCAT stacks, LLM'er der begynder at køre på beskeden hardware – eksisterer, i dag, for første gang alle sammen.

Hvorfor "utopi"

Utopi er et ærligt ord. Ingen af disse tre ting er i dag et færdigt produkt. Den første kræver LLM'er, der er tilstrækkeligt pålidelige til at blive brugt i en produktionskontekst, og vi er kun ved at tage de første skridt. Den anden kræver et enormt arbejde med at formalisere industriel viden, som i dag næsten udelukkende er uformel. Den tredje kræver at bygge åbne alternativer mod lukkede økosystemer, der har tyve års forspring.

Men de tre drømme sammen, når de sættes i række, tegner en klar retning: en automatisering, hvor hardware er commodity, software er genanvendeligt, viden er indlejret i maskinen, og PLC-programmørens figur – i dag en flaskehals i en hel industri – forsvinder ikke, men flyttes dertil, hvor den virkelig er nødvendig, nemlig til at skrive grundkomponenterne én gang for alle.

I de følgende artikler vil vi fortælle om de brikker, vi er ved at bygge af dette puslespil. Ét ad gangen, uden at love, at puslespillet er komplet. Det er det ikke. Men tegningen begynder at tage form.