Три мрії для іншої фабрики

Існують три речі, про які хоча б раз запитав кожен, хто коли-небудь запускав промисловий верстат. Три речі, які не озвучують, бо вони здаються утопією. Ця стаття викладає їх послідовно.

Одна сцена, для початку

Нічна зміна, цех X. Лінія зупиняється. Панель HMI показує код: E-1423. Інструкція знаходиться в шафі за три будівлі звідси. Технік, який знає цей верстат, у відпустці. В оператора є два варіанти: викликати службу підтримки — яка, можливо, відповість вранці — або діяти навмання. У всьому індустріалізованому світі подібні сцени повторюються сотні разів щоночі.

Проблема не в тому, що немає інструкції. Інструкцій занадто багато. Проблема в тому, що верстат чудово знає, що йому потрібно — датчик тиску повідомляє йому протягом тридцяти секунд, що щось не так — але він не може говорити мовою, яку зрозуміє оператор, і коли йому вдається говорити, він описує проблему, а не рішення. "Тиск поза межами норми" — це не корисна фраза о третій ночі. "Перевірте клапан V12 повітряної схеми, ймовірно, він застряг" — ось що корисно.

З цього починається робота, яку ми ведемо. Не новий ПЛК. Не більш красивий HMI. Це інший спосіб мислення про те, яким має бути програмне забезпечення, що приводить у рух машину, у 2026 році. І три незмінні ідеї — назвіть їх мріями — які ми намагаємося об’єднати.

Мрія номер один: автоматизувати без програмування

Промислова автоматизація, у тому вигляді, в якому вона існує сьогодні, вимагає дуже специфічної фігури: когось, хто вміє програмувати мовою — сімейством IEC 61131-3, з її діалектами ladder, function block, structured text — яка практично не використовується більше ніде у світі програмного забезпечення. Хто знає ці мови, той рідкісний, дорогий і майже завжди відстає на три тижні.

Парадокс полягає в тому, що той, хто дійсно знає машину, часто не є програмістом. Це керівник цеху, досвідчений технік з обслуговування, інтегратор, який встановив двадцять подібних установок. Ці люди знають що повинна робити машина. Вони не мають жодного бажання вивчати мову програмування, створену в 90-х роках, щоб це пояснити.

Ідея полягає в тому, щоб перевернути ланцюжок. Розробники програмного забезпечення один раз пишуть компоненти, які можна повторно використовувати — керування рухом, обробка даних з датчиків, операційні послідовності — сучасними мовами програмування загального призначення. Інтегратор машини не програмує їх: він компонує їх, вказуючи голосом або письмово, що повинна робити машина. Велика мовна модель — LLM — виступає в ролі перекладача: вона бере функціональну специфікацію від інтегратора і перетворює її на виконувальну конфігурацію, збираючи вже написані та протестовані компоненти.

Це не фантазія про "ШІ, який пише код замість вас". Це дещо скромніше і реалістичніше: ШІ, який читає вашу специфікацію і вибирає, з сертифікованих компонентів, як їх комбінувати. Критичний код — той, що рухає вісь з циклом 5 мілісекунд — продовжує писати людина, мовою, яка гарантує детермінізм і надійність. Але цей код пишеться один раз назавжди і використовується сто разів.

Мрія номер два: машина, яка знає себе

Сьогодні машини мало говорять, і погано. Сигнал тривоги – це числовий код. Діагностика – це серія світлодіодів. Журнал – це бінарний файл, який може відкрити лише виробник. Знання про те, як працює ця машина, з цими допусками, після двох тисяч циклів, зберігається в голові людини або в PDF-файлі десь.

Друга мрія полягає в тому, щоб машина знала себе сама. Не в містичному сенсі – а в дуже конкретному: технічна документація, параметри процесу, типові випадки несправностей, процедури втручання більше не зберігаються в шафі або на окремому сервері документів, а всередині самої машини, доступні для її власного програмного забезпечення. І коли щось іде не так, машина не каже "помилка 1423". Вона каже "клапан V12, ймовірно, заклинило, вам слід перевірити його; тим часом я можу продовжити в режимі зниженої продуктивності на 60%".

Різниця між пасивним об’єктом, який сигналізує, та активним об’єктом, який пропонує. Перший залишає проблему оператору. Другий вирішує її разом з ним.

Для цього потрібні дві нетривіальні речі. По-перше, знання про машину — історично зберігані в посібниках, електричних схемах, кресленнях CAD та в головах техніків — мають бути формалізовані та інтегровані в систему. По-друге, система повинна мати співрозмовника, здатного підтримувати розмову: знову ж таки, LLM, який використовується тут не для генерування коду, а для перекладу симптомів у зрозумілі дії, мовою того, хто стоїть перед панеллю.

Знову ж таки, це не магія. Це краще написана, краще індексована документація та розмовний інтерфейс над нею. Але це все змінює для тих, хто працює в нічну зміну.

Мрія номер три: програмне забезпечення, яке працює всюди

Третя мрія є найбільш технічною і, парадоксальним чином, найбільш політичною. Сьогодні промислова автоматизація — це світ закритих екосистем. Кожен великий виробник ПЛК має власну мову, власне середовище розробки, власне обладнання, власні драйвери, власну мережу дилерів. Зміна постачальника означає переписати все.

Наша амбіція полягає в тому, щоб створити програмну систему, яка працюватиме на загальнодоступному обладнанні — міні-промисловому ПК, вбудованому контролері, сервері в підвалі — вибираючи обладнання на основі бюджету та необхідної продуктивності, а не на основі того, яка марка ПЛК виграла переговори. Операційна система Linux у версії реального часу, комунікаційні карти на основі відкритих стандартів (EtherCAT для всіх), програмні компоненти сучасними мовами для детермінованих частин і більш гнучкими мовами для тих, які не є детермінованими.

Правило, і тут утопія стає конкретною: обладнання повинно впливати на продуктивність, але ніколи на надійність. Та сама логіка, на менш потужній машині, повинна працювати ідентично — лише повільніше. Якщо час циклу збільшується з 5 до 10 мілісекунд, вісь рухається з тією ж точністю, але вдвічі повільніше. Ніколи "майже однаково". Ніколи "працює, крім того випадку". Одна й та сама система, одні й ті ж рішення, одні й ті ж гарантії.

Це частина, де досвідчені інженери починають сміятися. Вони чудово знають, що робота в реальному часі – це складно, що Linux не був створений як система реального часу, що LLM не працюють на Raspberry Pi, що змішування різних мов в одному стеку має більше підводних каменів, ніж обіцяють навчальні посібники. Вони мають рацію. Але напрямок саме такий, і будівельні блоки для його створення — розширення реального часу ядра Linux, зрілі відкриті стеки EtherCAT, LLM, які починають працювати на скромному обладнанні — існують сьогодні, вперше всі разом.

Чому "утопія"

Утопія – це чесне слово. Жодна з цих трьох речей сьогодні не є готовим продуктом. Перша вимагає LLM, достатньо надійних для використання у виробничому контексті, і ми лише робимо перші кроки. Друга вимагає величезної роботи з формалізації промислових знань, які сьогодні майже повністю неформальні. Третя вимагає побудови відкритих альтернатив проти закритих екосистем, які мають двадцятирічну перевагу.

Але три мрії разом, якщо їх вишикувати, малюють чіткий напрямок: автоматизація, в якій апаратне забезпечення є стандартним, програмне забезпечення можна повторно використовувати, знання вбудовані в машину, а фігура програміста ПЛК — сьогодні вузьке місце цілої галузі — не зникає, а переміщується туди, де це дійсно потрібно, тобто на написання базових компонентів раз і назавжди.

У статтях, які з’являться далі, ми розповімо про частини цієї головоломки, які ми будуємо. По одній, не обіцяючи, що головоломка буде завершена. Вона ще не завершена. Але контури починають вимальовуватися.