Trzy sny o innej fabryce

Istnieją trzy rzeczy, które zadał sobie przynajmniej raz każdy, kto kiedykolwiek uruchomił maszynę przemysłową. Trzy rzeczy, o których nie mówi się głośno, ponieważ wydają się utopią. Ten artykuł zestawia je razem.

Scena, na początek

Zmiana nocna, dział X. Linia się zatrzymuje. Panel HMI wyświetla kod: E-1423. Instrukcja obsługi znajduje się w szafce oddalonej o trzy budynki. Technik znający tę maszynę jest na urlopie. Operator ma dwie możliwości: zadzwonić po serwis — który prawdopodobnie odpowie rano — albo zgadywać. Na całym świecie uprzemysłowionym sceny takie jak ta powtarzają się setki razy każdej nocy.

Problem nie polega na braku instrukcji obsługi. Instrukcji jest zbyt wiele. Problem polega na tym, że maszyna doskonale wie, czego potrzebuje — czujnik ciśnienia od trzydziestu sekund mówi jej, że coś jest nie tak — ale nie potrafi mówić językiem zrozumiałym dla operatora, a kiedy już potrafi, opisuje problem zamiast rozwiązania. "Ciśnienie poza zakresem" nie jest przydatnym zdaniem o trzeciej w nocy. "Sprawdź zawór V12 w obwodzie powietrza, prawdopodobnie się zablokował" jest.

Właśnie od tego zaczynamy naszą pracę. Nie nowy PLC. Nie ładniejszy HMI. Sposób na inne myślenie o tym, jakim powinno być oprogramowanie, które napędza maszynę w 2026 roku. I trzy stałe idee – możecie nazwać je marzeniami – które próbujemy połączyć.

Marzenie numer jeden: automatyzacja bez programowania

Automatyka przemysłowa, w obecnej formie, wymaga bardzo specyficznej osoby: kogoś, kto potrafi programować w języku – rodzina IEC 61131-3, z jej dialektami ladder, function block, structured text – który praktycznie nie jest używany nigdzie indziej w świecie oprogramowania. Osoby znające te języki są rzadkie, drogie i prawie zawsze opóźniają się o trzy tygodnie.

Paradoks polega na tym, że osoba, która naprawdę zna maszynę, często nie jest programistą. To kierownik działu, starszy konserwator, integrator, który zainstalował dwadzieścia podobnych instalacji. Te osoby wiedzą co maszyna musi robić. Nie mają ochoty uczyć się języka programowania powstałego w latach 90., aby to wyjaśnić.

Kluczowe jest odwrócenie łańcucha. Programiści oprogramowania piszą komponenty wielokrotnego użytku — sterowanie ruchem, zarządzanie czujnikami, sekwencje operacyjne — tylko raz, w nowoczesnych i uniwersalnych językach. Integrator maszyn nie programuje ich: komponuje, określając werbalnie lub pisemnie, co maszyna ma robić. Duży model językowy — LLM — działa jako tłumacz: pobiera specyfikację funkcjonalną od integratora i przekształca ją w konfigurowalny kod, składając już napisane i przetestowane komponenty.

To nie jest fantazja o "AI, która pisze kod za ciebie". To coś bardziej skromnego i realistycznego: AI, która odczytuje twoją specyfikację i wybiera, spośród certyfikowanych komponentów, jak je połączyć. Krytyczny kod — ten, który przesuwa oś w cyklu 5 milisekund — nadal pisze człowiek, w języku gwarantującym determinizm i niezawodność. Ale ten kod jest napisany raz na zawsze i wykorzystywany sto razy.

Marzenie numer dwa: maszyna, która wie o sobie

Dzisiaj maszyny rozmawiają mało i słabo. Alarm to kod numeryczny. Diagnostyka to seria diod LED. Log to plik binarny, który tylko producent potrafi otworzyć. Wiedza o tym, jak działa ta maszyna, z tymi tolerancjami, po tych dwóch tysiącach cykli, znajduje się w głowie jednej osoby lub w pliku PDF gdzieś.

Drugie marzenie jest takie, aby to maszyna znała samą siebie. Nie w sensie mistycznym — w bardzo konkretnym sensie: dokumentacja techniczna, parametry procesowe, typowe przypadki awarii, procedury interwencyjne nie znajdują się już w szafie lub na oddzielnym serwerze dokumentów, ale wewnątrz samej maszyny, czytelne przez jej własne oprogramowanie. A kiedy coś pójdzie nie tak, maszyna nie mówi "błąd 1423". Mówi "zawór V12 prawdopodobnie się zablokował, powinieneś go sprawdzić; w międzyczasie mogę kontynuować pracę w trybie ograniczonym z prędkością 60%".

Różnica polega na tym, że mamy do czynienia z obiektem pasywnym, który zgłasza problem, a obiektem aktywnym, który rozwiązuje go wspólnie z operatorem.

Wymaga to dwóch rzeczy, które nie są oczywiste. Po pierwsze, wiedza o maszynie – historycznie przechowywana w instrukcjach obsługi, schematach elektrycznych, rysunkach CAD i w głowach techników – musi zostać sformalizowana i zintegrowana z systemem. Po drugie, system musi mieć adresata, który potrafi prowadzić rozmowę: ponownie, LLM, używane tutaj nie do generowania kodu, ale do tłumaczenia symptomów na zrozumiałe działania, w języku osoby stojącej przed panelem.

Ponownie, to nie jest magia. To lepiej udokumentowane, lepiej zaindeksowane materiały i interfejs konwersacyjny nad nimi. Ale to wszystko zmienia dla osoby pracującej na nocnej zmianie.

Marzenie numer trzy: oprogramowanie działające wszędzie

Trzecie marzenie jest najbardziej techniczne i, paradoksalnie, najbardziej polityczne. Dziś automatyka przemysłowa to świat zamkniętych ekosystemów. Każdy duży producent PLC ma swój język, środowisko programistyczne, sprzęt, sterowniki i sieć dystrybutorów. Zmiana dostawcy oznacza przepisanie wszystkiego.

Naszą ambicją jest stworzenie systemu oprogramowania, który będzie działał na uniwersalnym sprzęcie — mini-PC przemysłowym, kontrolerze wbudowanym, serwerze w piwnicy — wybierając sprzęt w oparciu o budżet i wymaganą wydajność, a nie w oparciu o to, która marka PLC wygrała przetarg. System operacyjny Linux w wersji czasu rzeczywistego, karty komunikacyjne oparte na otwartych standardach (EtherCAT we wszystkich), komponenty oprogramowania w nowoczesnych językach dla części deterministycznych i w bardziej zwinnych językach dla tych, które takie nie są.

Zasada, i tutaj utopia staje się konkretna: sprzęt musi wpływać na wydajność, nigdy na niezawodność. Ta sama logika, na mniej wydajnej maszynie, musi działać identycznie — tylko wolniej. Jeśli czas cyklu wydłuży się z 5 do 10 milisekund, oś poruszy się z tą samą precyzją, ale z połową prędkości. Nigdy "prawie tak samo". Nigdy "działa, z wyjątkiem tego przypadku". Ten sam system, te same decyzje, te same gwarancje.

To jest moment, w którym doświadczeni inżynierowie zaczynają się śmiać. Doskonale wiedzą, że praca w czasie rzeczywistym jest trudna, że Linux nie został stworzony jako system czasu rzeczywistego, że LLM nie działają na Raspberry Pi, że mieszanie różnych języków w tym samym stosie ma więcej pułapek, niż obiecują samouczki. Mają rację. Ale kierunek jest taki, a elementy składowe do jego zbudowania — rozszerzenia czasu rzeczywistego jądra Linux, dojrzałe, otwarte stosy EtherCAT, LLM, które zaczynają działać na skromnym sprzęcie — istnieją, dzisiaj, po raz pierwszy wszystkie razem.

Dlaczego „utopia”

Utopia to uczciwe słowo. Żadna z tych trzech rzeczy nie jest dziś produktem gotowym. Pierwsza wymaga LLM wystarczająco niezawodnych, aby mogły być używane w środowisku produkcyjnym, a jesteśmy dopiero na początku. Druga wymaga ogromnej pracy nad formalizacją wiedzy przemysłowej, która dziś jest niemal w całości nieformalna. Trzecia wymaga budowania otwartych alternatyw w stosunku do zamkniętych ekosystemów, które mają dwudziestoletnią przewagę.

Ale te trzy marzenia razem, ułożone w szeregu, wyznaczają jasny kierunek: automatyzację, w której sprzęt jest towarem, oprogramowanie jest wielokrotnego użytku, wiedza jest osadzona w maszynie, a rola programisty PLC — dziś wąskiego gardła całej branży — nie znika, ale przesuwa się tam, gdzie jest naprawdę potrzebna, czyli do pisania podstawowych komponentów raz na zawsze.

W kolejnych artykułach opowiemy o fragmentach tej układanki, nad którymi pracujemy. Po jednym, nie obiecując, że układanka jest kompletna. Jeszcze nią nie jest. Ale zarys zaczyna być widoczny.