Tre drömmar för en annorlunda fabrik

Det finns tre saker som alla som någonsin tagit en industriell maskin i drift har undrat sig över minst en gång. Tre saker som man inte säger högt eftersom de verkar vara utopier. Den här artikeln listar dem.

En scen, bara för att börja

Nattskift, avdelning X. En linje stannar. HMI-panelen visar en kod: E-1423. Manualen ligger i ett skåp tre byggnader bort. Teknikern som kan den maskinen är på semester. Operatören har två vägar: ringa support – som kanske svarar i morgon – eller gissa. I hela den industrialiserade världen upprepas scener som denna hundratals gånger per natt.

Problemet är inte att det saknas en manual. Det finns för många manualer. Problemet är att maskinen vet precis vad den behöver – trycksensorn har berättat för den i trettio sekunder att något är fel – men den kan inte tala ett språk som operatören förstår, och när den kan tala det berättar den problemet istället för lösningen. "Tryck utanför intervallet" är ingen användbar mening klockan tre på natten. "Kontrollera ventilen V12 i luftkretsen, den har förmodligen fastnat" är det.

Det är här vårt arbete börjar. Inte en ny PLC. Inte ett snyggare HMI. Ett annorlunda sätt att tänka på vilken programvara som bör driva en maskin år 2026. Och tre fasta idéer – kalla dem gärna drömmar – som vi försöker hålla ihop.

Dröm nummer ett: automatisera utan att programmera

Industriell automation, som den ser ut idag, kräver en mycket speciell person: någon som kan programmera i ett språk – IEC 61131-3-familjen, med sina dialekter ladder, function block, structured text – som praktiskt taget inte används någon annanstans i mjukvaruvärlden. De som kan dessa språk är sällsynta, dyra och ligger nästan alltid tre veckor efter.

Paradoxen är att den som verkligen känner maskinen ofta inte är programmeraren. Det är avdelningschefen, den äldre underhållsteknikern, integratören som har installerat tjugo liknande anläggningar. Dessa personer vet vad maskinen ska göra. De har ingen lust att lära sig ett programmeringsspråk som föddes på 90-talet för att förklara det.

Tanken är att vända på kedjan. Mjukvaruutvecklare skriver återanvändbara komponenter — rörelsestyrning, sensorhantering, operativa sekvenser — en gång, i moderna och allmänna språk. Maskinintegratören programmerar dem inte: de sätter ihop dem, och specificerar med röst eller skrift vad maskinen ska göra. En stor språkmodell — en LLM — fungerar som översättare: den tar integratörens funktionella specifikation och omvandlar den till en körbar konfiguration, genom att sätta ihop redan skrivna och testade komponenter.

Det är inte fantasin om "AI som skriver koden åt dig". Det är något mer ödmjukt och mer realistiskt: AI som läser din specifikation och väljer, bland certifierade komponenter, hur de ska kombineras. Kritisk kod — den som rör en axel med en cykel på 5 millisekunder — fortsätter att skrivas av en människa, i ett språk som garanterar determinism och tillförlitlighet. Men den koden skrivs en gång för alla och återanvänds hundra gånger.

Dröm nummer två: maskinen som vet om sig själv

Idag pratar maskinerna lite, och dåligt. Ett larm är en numerisk kod. En diagnostik är en serie LED-lampor. En logg är en binär fil som bara tillverkaren kan öppna. Kunskapen om hur den maskinen fungerar, med de toleranserna, efter de två tusen cyklerna, finns i en persons huvud, eller i en PDF någonstans.

Den andra drömmen är att det är maskinen som känner sig själv. Inte i mystisk mening – utan i en mycket konkret mening: den tekniska dokumentationen, processparametrarna, typiska felscenarier och ingreppsrutiner finns inte längre i ett skåp eller en separat dokumentserver, utan inuti maskinen själv, läsbara av dess egen programvara. Och när något går fel säger maskinen inte ”fel 1423”. Den säger ”ventilen V12 har förmodligen fastnat, du bör kontrollera den; under tiden kan jag fortsätta i ett försämrat läge med 60 % av hastigheten”.

Skillnaden är mellan ett passivt objekt som signalerar och ett aktivt objekt som föreslår. Det första lämnar problemet till operatören. Det andra tar itu med det tillsammans med honom.

Detta kräver två saker som inte är självklara. Först och främst att maskinens kunskap – historiskt sett bevarad i manualer, elscheman, CAD-ritningar och teknikers huvuden – formaliseras och integreras i systemet. För det andra att systemet har en samtalsmotpart som kan hantera en konversation: återigen en LLM, som används här inte för att generera kod utan för att översätta symptom till begripliga åtgärder, på språket hos den som står framför panelen.

Återigen, det är ingen magi. Det är bättre skriven och bättre indexerad dokumentation, och ett konversationellt gränssnitt ovanpå. Men det förändrar allt för den som har nattskiftet.

Dröm nummer tre: programvaran som körs överallt

Den tredje drömmen är den mest tekniska och, paradoxalt nog, den mest politiska. Idag är industriell automation en värld av slutna ekosystem. Varje stor PLC-tillverkare har sitt eget språk, sin egen utvecklingsmiljö, sin egen hårdvara, sina egna drivrutiner, sitt eget återförsäljarnätverk. Att byta leverantör innebär att skriva om allt.

Ambitionen här är att bygga ett mjukvarusystem som körs på generisk hårdvara – en industriell mini-PC, en inbyggd styrenhet, en server i källaren – och välja hårdvara baserat på budget och nödvändig prestanda, inte baserat på vilket PLC-märke som vann förhandlingen. Ett Linux-operativsystem i realtidsversion, kommunikationskort baserade på öppna standarder (EtherCAT för alla), mjukvarukomponenter i moderna språk för de deterministiska delarna och i mer smidiga språk för de som inte är det.

Regeln, och här blir utopin konkret: hårdvaran måste påverka prestandan, aldrig tillförlitligheten. Samma logik, på en mindre kraftfull maskin, måste fungera på samma sätt – bara långsammare. Om cykeltiden går från 5 till 10 millisekunder, rör sig axeln med samma precision men med halva hastigheten. Aldrig "nästan samma". Aldrig "fungerar förutom i det fallet". Samma system, samma beslut, samma garantier.

Det här är delen där erfarna ingenjörer börjar skratta. De vet mycket väl att realtid är svårt, att Linux inte föddes som ett realtidssystem, att LLM inte körs på en Raspberry Pi, och att blandning av olika språk i samma stack har fler fallgropar än vad handledningarna lovar. De har rätt. Men riktningen är den, och byggstenarna för att bygga den – realtidsförlängningar av Linux-kärnan, mogna open source EtherCAT-stackar, LLM som börjar köras på blygsam hårdvara – finns idag, för första gången, alla tillsammans.

Varför "utopi"

Utopi är ett ärligt ord. Ingen av dessa tre saker är idag en färdig produkt. Den första kräver LLM som är tillräckligt pålitliga för att användas i en produktionsmiljö, och vi är bara i början. Den andra kräver ett enormt arbete med att formalisera industriell kunskap, som idag nästan helt är informell. Den tredje kräver att man bygger öppna alternativ mot slutna ekosystem som har tjugo års försprång.

Men de tre drömmarna tillsammans, om de ställs upp i rad, ritar en tydlig riktning: en automatisering där hårdvaran är en handelsvara, programvaran är återanvändbar, kunskapen är inbäddad i maskinen, och PLC-programmerarens roll – som idag är en flaskhals för en hel industri – försvinner inte, utan flyttas dit den verkligen behövs, det vill säga att skriva grundkomponenterna en gång för alla.

I de artiklar som följer kommer vi att berätta om de bitar vi bygger av denna pusselbild. En i taget, utan att lova att pusslet är komplett. Det är det inte. Men bilden börjar ta form.