Три мечты о фабрике будущего

Есть три вещи, о которых хотя бы раз задумался каждый, кто когда-либо запускал промышленную машину. Три вещи, которые не говорят вслух, потому что они кажутся утопией. Эта статья выстраивает их в ряд.

Сцена, для начала

Ночная смена, цех 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, достаточно надежных для использования в производственной среде, и мы только делаем первые шаги. Вторая требует огромной работы по формализации промышленных знаний, которые сегодня почти полностью неформальны. Третья требует создания открытых альтернатив против закрытых экосистем, которые имеют двадцатилетний опыт.

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

В следующих статьях мы расскажем о частях, из которых складываем этот пазл. По одной, не обещая, что пазл будет завершен. Его еще нет. Но очертания рисунка начинают проступать.