Trei vise pentru o fabrică diferită

Există trei lucruri pe care și le-a pus cel puțin o dată oricine a pus în funcțiune o mașină industrială. Trei lucruri care nu se spun cu voce tare pentru că par utopice. Acest articol le aliniază.

O scenă, ca să începem

Tură de noapte, secția X. O linie se oprește. Panoul HMI afișează un cod: E-1423. Manualul se află într-un dulap la trei clădiri distanță. Tehnicianul care cunoaște acea mașină este în concediu. Operatorul are două căi: să sune la serviciul de asistență — care răspunde poate dimineața — sau să ghicească. În întreaga lume industrializată, scene ca aceasta se repetă de sute de ori pe noapte.

Problema nu este că lipsește un manual. Există prea multe manuale. Problema este că mașina știe foarte bine de ce are nevoie — senzorul de presiune îi spune de treizeci de secunde că ceva nu este în regulă — dar nu reușește să vorbească o limbă pe care operatorul să o înțeleagă, și când reușește să o vorbească, spune problema în loc de soluție. "Presiune în afara intervalului" nu este o frază utilă la trei dimineața. "Verificați supapa V12 a circuitului de aer, probabil s-a blocat" este.

De aici pornește munca pe care o facem. Nu un PLC nou. Nu un HMI mai frumos. O modalitate diferită de a gândi ce ar trebui să fie, în 2026, software-ul care pune în mișcare o mașină. Și trei idei fixe — numiți-le și vise — pe care încercăm să le menținem împreună.

Visul numărul unu: automatizare fără programare

Automatizarea industrială, așa cum este făcută astăzi, necesită o figură foarte particulară: cineva care știe să programeze într-un limbaj — familia IEC 61131-3, cu dialectele sale ladder, function block, structured text — care nu este folosit practic nicăieri altundeva în lumea software. Cei care cunosc aceste limbaje sunt rari, sunt scumpi și sunt aproape întotdeauna cu trei săptămâni în urmă.

Paradoxul este că cel care cunoaște cu adevărat mașina nu este programatorul. Este șeful de departament, tehnicianul de întreținere experimentat, integratorul care a instalat douăzeci de instalații similare. Acești oameni știu ce trebuie să facă mașina. Nu au nicio dorință de a învăța un limbaj de programare născut în anii '90 pentru a explica asta.

Ideea este să răsturnăm lanțul. Dezvoltatorii de software scriu componente reutilizabile — controlul mișcării, gestionarea senzorilor, secvențe operaționale — o singură dată, în limbaje moderne și cu uz general. Integratorul de mașini nu le programează: le compune, specificând verbal sau în scris ce trebuie să facă mașina. Un model lingvistic de mari dimensiuni — un LLM — acționează ca traducător: preia specificația funcțională a integratorului și o transformă într-o configurație executabilă, asamblând componentele deja scrise și testate.

Nu este fantezia "AI-ului care scrie codul în locul tău". Este ceva mai modest și mai realist: AI-ul care citește specificația ta și alege, dintre componente certificate, cum să le combine. Codul critic — cel care mișcă o axă cu un ciclu de 5 milisecunde — continuă să fie scris de un om, într-un limbaj care să garanteze determinism și fiabilitate. Dar acel cod este scris o dată pentru totdeauna și reutilizat de o sută de ori.

Visul numărul doi: mașina care se cunoaște pe sine

Astăzi, mașinile vorbesc puțin și prost. O alarmă este un cod numeric. Un diagnostic este o serie de LED-uri. Un log este un fișier binar pe care doar producătorul știe să-l deschidă. Cunoașterea modului în care funcționează această mașină, cu acele toleranțe, după acești doi mii de cicluri, se află în capul unei persoane sau într-un PDF undeva.

Al doilea vis este ca mașina să se cunoască pe sine. Nu într-un sens mistic — ci într-un sens foarte concret: documentația tehnică, parametrii de proces, cazurile tipice de defecțiune, procedurile de intervenție nu mai stau într-un dulap sau pe un server de documente separat, ci în interiorul mașinii în sine, lizibile de propriul său software. Și când ceva nu merge bine, mașina nu spune "eroare 1423". Spune "supapa V12 probabil s-a blocat, ar trebui să o verificați; între timp, pot continua în modul degradat la 60% din viteză".

Diferența este între un obiect pasiv care semnalează și un obiect activ care propune. Primul lasă problema operatorului. Al doilea o abordează împreună cu acesta.

Acest lucru necesită două aspecte care nu sunt de la sine înțelese. În primul rând, că cunoștințele despre mașină – stocate istoric în manuale, scheme electrice, desene CAD și în mintea tehnicienilor – să fie formalizate și integrate în sistem. În al doilea rând, ca sistemul să aibă un interlocutor capabil să susțină o conversație: din nou, un LLM, folosit aici nu pentru a genera cod, ci pentru a traduce simptomele în acțiuni inteligibile, în limba celui care se află în fața panoului.

Încă o dată, nu este magie. Este documentație scrisă mai bine, indexată mai bine și o interfață conversațională deasupra. Dar schimbă totul pentru cel care lucrează în schimbul de noapte.

Visul numărul trei: software-ul care rulează peste tot

Al treilea vis este cel mai tehnic și, paradoxal, cel mai politic. Astăzi, automatizarea industrială este o lume a ecosistemelor închise. Fiecare mare producător de PLC are propriul limbaj, propriul mediu de dezvoltare, propriul hardware, propriile drivere, propria rețea de distribuitori. Schimbarea furnizorului înseamnă rescrierea a totului.

Ambiția aici este să construim un sistem software care să ruleze pe hardware generic — un mini-PC industrial, un controller embedded, un server în subsol — alegând hardware-ul în funcție de buget și de performanțele necesare, nu în funcție de marca de PLC care a câștigat licitația. Un sistem de operare Linux în versiune real-time, plăci de comunicare bazate pe standarde deschise (EtherCAT pentru toate), componente software în limbaje moderne pentru părțile deterministice și în limbaje mai agile pentru cele care nu sunt.

Regula, și aici este locul unde utopia devine concretă: hardware-ul trebuie să influențeze performanța, niciodată fiabilitatea. Aceeași logică, pe o mașină mai puțin puternică, trebuie să funcționeze în mod identic — doar mai lent. Dacă timpul de ciclu trece de la 5 la 10 milisecunde, axa se mișcă cu aceeași precizie, dar la jumătate din viteză. Niciodată "aproape egal". Niciodată "funcționează cu excepția acelui caz". Același sistem, aceleași decizii, aceleași garanții.

Aceasta este partea în care inginerii experimentați încep să râdă. Știu foarte bine că timpul real este dificil, că Linux nu a fost conceput ca un sistem în timp real, că LLM-urile nu rulează pe un Raspberry Pi, că amestecarea diferitelor limbaje în același stack are mai multe capcane decât promit tutorialele. Au dreptate. Dar direcția este aceasta, iar cărămizile pentru a o construi – extensiile în timp real ale kernel-ului Linux, stack-uri EtherCAT open source mature, LLM-uri care încep să ruleze pe hardware modest – există, astăzi, pentru prima dată, toate împreună.

De ce "utopie"

Utopia este un cuvânt onest. Niciuna dintre aceste trei lucruri nu este, astăzi, un produs finit. Primul necesită LLM-uri suficient de fiabile pentru a fi utilizate într-un context productiv, și suntem abia la început. Al doilea necesită o cantitate enormă de formalizare a cunoștințelor industriale, care astăzi sunt aproape în totalitate informale. Al treilea necesită construirea de alternative deschise împotriva ecosistemelor închise care au un avantaj de douăzeci de ani.

Dar cele trei vise împreună, dacă sunt puse în linie, desenează o direcție precisă: o automatizare în care hardware-ul este o marfă, software-ul este reutilizabil, cunoștințele sunt încorporate în mașină, iar figura programatorului PLC – astăzi gâtul de sticlă al unei întregi industrii – nu dispare, ci se mută acolo unde este cu adevărat nevoie, adică să scrie componentele de bază o dată pentru toate.

În articolele care vor urma, vom povesti bucățile pe care le construim din acest puzzle. Una câte una, fără a promite că puzzle-ul este complet. Nu este. Dar conturul începe să se contureze.