Модуль p.7 · Урок 1
Урок 1: Software-defined factory — виртуальные PLC и industrial foundation models
Чему вы научитесь
- Отличать software-defined factory от обычной цифровизации цеха
- Понимать, зачем Siemens и Audi перевели часть логики на virtual PLC, а BMW и Foxconn — в цифровой двойник завода
- Разводить три слоя новой архитектуры: vPLC, digital twin platform и industrial foundation model
- Видеть, какие элементы Tier-1 стека реально повторимы на российском заводе, а какие пока нет
- Быстро отсекать маркетинг вокруг humanoid-роботов и foundation models, если у завода нет даже устойчивого MES/IIoT-контура
Дискретное производство в 2025–2026 сдвинулось не из-за одного нового алгоритма, а из-за смены архитектуры. Рынок уходит от связки «железо + закрытый PLC + разрозненные SCADA-острова» к программно-определяемой фабрике: логика управления, цифровой двойник, аналитика и копилоты начинают жить как единая программная система. Для российского завода разрыв с лидерами — не в доле отечественных MES (по опросу СПбПУ и Минпромторга 2025 года отечественными MES пользуется около 73% предприятий), а в зрелости AI-слоя над этими системами: копилоты для инженеров, виртуальные PLC, industrial foundation models пока внедрены точечно и, в большинстве случаев, не сертифицированы для работы на значимых объектах КИИ.
Три слоя software-defined factory
| Слой | Что это такое | Кто задаёт эталон | Что из этого повторять в РФ |
|---|---|---|---|
| Virtual PLC | PLC-логика уходит с жёстко привязанного контроллера в программный runtime | Siemens + Audi: первый TÜV-сертифицированный vPLC на производстве (Siemens) | Да, как архитектурный ориентир; для среднего завода это обычно последний этап после data foundation и twin, если у вас сильная команда АСУ ТП и контроль версии логики |
| Digital twin platform | Единая виртуальная модель линии, ячейки или завода для пусконаладки и оптимизации | BMW iFactory, Volkswagen DPP, Foxconn FODT (AssemblyMag, AWS, NVIDIA) | Да, но чаще через open-source стек и частичный twin, а не «двойник всего завода» |
| Industrial foundation model | Большая модель, обученная на корпусе инженерной документации, логов и automation-knowledge | Siemens + Microsoft представили industrial foundation model в 2025 году (RCR Wireless) | Частично: через локальные RAG-системы и open-weight модели, а не через западный SaaS |
flowchart LR
A[Станки, роботы, конвейеры, датчики] --> B[vPLC и edge-контур]
A --> C[OT-данные и события]
C --> D[Data layer и historian]
D --> E[Digital twin линии или завода]
D --> F[Industrial copilot и analytics]
E --> G[Виртуальный пуск, моделирование, оптимизация]
F --> H[Инженерные рекомендации, code assist, troubleshooting]
B --> I[Реальное управление производством]
G --> IЧто реально изменилось в 2025–2026
Самое важное событие — Siemens и Audi перевели virtual PLC из лаборатории в производственный контур. Siemens прямо пишет о TÜV-сертифицированном vPLC, который используется в кузовном производстве Audi Böllinger Höfe и позволяет отделить automation software от hardware lifecycle (Siemens). Для инженера это означает одну вещь: логика цеха теперь может обновляться, тестироваться и раскатываться ближе к практике IT, а не только классического OT. Но для среднего российского завода это не стартовая точка, а верхний этаж зрелости: сначала данные, twin и управляемый assistant layer, потом перенос логики в vPLC.
Следующий слой — цифровой двойник как обязательный pre-production runtime. BMW на заводе в Дебрецене использует Omniverse и цифровые модели для виртуальных предзапусков и заявляет снижение затрат на планирование примерно на 30% (AssemblyMag). Volkswagen в Digital Production Platform собрал 43 завода и 1200+ AI-приложений, а на площадке Poznań сообщил о снижении энергопотребления на 12% (AWS case study). Foxconn для FODT заявляет сокращение time-to-launch новой линии примерно на 50% (NVIDIA).
Третий слой — foundation model именно для industrial engineering. Это пока не массовый production-стандарт, а ранний фронтир. Поэтому относиться к нему нужно как к опции следующего шага после data foundation, а не как к первой закупке.
Канонические кейсы — что в них важно, кроме маркетинга
| Кейс | Что именно внедрено | Практический смысл |
|---|---|---|
| Siemens + Audi | Virtual PLC в реальном кузовном производстве, сертификация TÜV (Siemens) | Логику производства можно развязывать с конкретным контроллером и тестировать как софт |
| BMW iFactory | Цифровой двойник завода и виртуальный commissioning (AssemblyMag) | Ошибки находят до физического пуска, а не после монтажа |
| Volkswagen DPP | Единая data platform для десятков заводов и тысяч AI-приложений (AWS) | Настоящая экономика начинается не с одного пилота, а с тиражирования use case по сети заводов |
| Mercedes MO360 | Единая производственная цифровая платформа и GenAI-слой для quality workflows на сети 30+ заводов (Mercedes-Benz) | Copilot имеет смысл там, где уже есть единый workflow и единые данные |
| Siemens + Microsoft Industrial Foundation Model | Модель на корпусе Siemens automation-knowledge (RCR Wireless) | Следующий шаг после накопления инженерного корпуса, а не его замена |
Что это значит для среднего завода в России
Главная ошибка — пытаться «поставить Omniverse» или «сделать copilot для PLC», когда завод живёт на Excel, ручных переналадках и фрагментированной SCADA. Среднему заводу нужны не все три слоя сразу, а последовательность.
- Сначала data foundation. Подтянуть OPC UA, historian, события качества, справочники оборудования и маршруты производства. Для open-source стека смотрите p.9/05.
- Потом частичный digital twin. Не весь завод, а одна ячейка, сборочная линия или критический участок. Про open-source twin подробно в p.7/05.
- Потом assistant layer. Копилот инженера, подсказки по PLC-библиотеке, troubleshooting и поиск по документации. Подход к таким ассистентам разбирается в p.7/04.
- И только потом vPLC. Virtual PLC имеет смысл там, где команда умеет жить в CI/CD-подходе к логике управления и не боится software lifecycle discipline.
Где проходит граница повторяемости
| Можно брать сейчас | Пока смотреть как reference |
|---|---|
| Частичный digital twin участка | Полный twin всего завода с физически точной моделью каждой операции |
| Локальный copilot по документации и PLC-библиотекам | Industrial foundation model как первая покупка |
| Open-source data layer + MQTT/OPC UA + historian | Полная программная фабрика на западном vendor stack |
| Edge-аналитика и advisory layer | Безлюдная сборка на humanoid-роботах |
Какие организационные условия нужны
Технический стек тут вторичен. Software-defined factory почти всегда упирается в организационную зрелость.
| Что должно быть у завода | Зачем это нужно |
|---|---|
| Версионирование PLC-проектов и инженерных артефактов | Без этого vPLC быстро превращается в хаос «последняя версия_final_7» |
| Единый справочник оборудования и тегов | Twin и copilot не живут поверх разъехавшихся имён и дублирующих сущностей |
| Нормальный change control | И vPLC, и assistant layer повышают скорость изменений, а значит растёт цена ошибки |
| Команда на стыке OT + IT | Без неё twin остаётся игрушкой IT, а PLC — закрытым миром АСУ ТП |
| Исторические данные по событиям, качеству и простоям | Иначе нечего оптимизировать и не на чем проверять эффект |
Поэтому для среднего предприятия software-defined factory — это в первую очередь вопрос дисциплины инженерных изменений. Если её нет, лучше начать с одного участка и жёсткого change control, а не со слова «platform».
Выберите один производственный контур. Это может быть кузовной участок, роботизированная ячейка, окрасочная линия или механообработка. Не пытайтесь цифровизовать сразу весь завод.
Зафиксируйте состав данных. PLC tags, события MES, quality events, tool data, энергопотребление, traceability. Без этого digital twin будет декоративным.
Соберите минимальный twin. Обычно это topology + event model + process state, а не красивая 3D-графика. 3D нужен только там, где он улучшает пусконаладку или эргономику.
Добавьте assistant layer поверх реальной документации. Используйте on-prem RAG и локальный LLM по схемам из p.9/04 и p.9/02.
Только после этого обсуждайте vPLC. И только если у вас есть команда, которая умеет работать с версионированием, тестированием и безопасным релизом логики.