Программно-определяемая автоматика поверх открытых стандартов
Настройка и управление приводами вынесены на объектный уровень: единая модель машины в цифровом двойнике, из которой порождается низкоуровневая конфигурация. Фундамент открытый и детерминированный — EtherCAT, CiA-402, LinuxCNC / HAL; наш слой — двойник, порождение конфигурации и программ, наладка.
Настройки живут в двойнике. Станок — его зеркало.
Оси, шпиндель, инструменты, нули, механизм — всё в двойнике. Конфигурация порождается из него и передаётся на станок; импорт со стенда только засевает двойник, второй истины не возникает. Двусторонняя связь модели с оборудованием — критерий цифрового двойника по ГОСТ Р 57700.37-2021.
Правка здесь — изменение на станке. Версионируется, резервируется, переносится на другое железо.
Получает конфигурацию и программу, исполняет, возвращает состояние. Без ручных правок в обход двойника.
| Что | Где живёт | Чем доказано |
|---|---|---|
| Оси, ходы, пределы, приводы | двойник — поля Machine | строка .ini и пин HAL на стенде несут то же число |
| Механизм: звенья, шарниры | файл URDF — данные, а не код | одна модель открывается в карточке станка и в лаборатории; второй копии нет |
| Ноль детали, установка | установка двойника и смещение G54 | сдвиг заготовки не меняет текст программы |
| Конфигурация стойки | порождается из двойника при запуске | хеш порождённой конфигурации сверяется с тем, что лежит на стенде |
Возможность не готова, пока её видят не все четыре окна
Всё, что умеет станок, проброшено сквозь весь путь — от железа до экрана — и согласовано во всех окнах, через которые на это смотрят: одно значение, одно имя, один владелец записи.
Двойник (cncai)
Поле или факт: где это живёт в модели и откуда берётся.
Стенд (конфигурация → LinuxCNC)
Проброс: пин HAL, строка .ini, объект шины, команда агента.
Наладка (cncctl)
Настройка и наблюдение: через неё возможность задаётся и проверяется измерением.
Локальная панель у станка
Управление и контроль для оператора без облака: пуск, стоп, состояние.
Бокс у станка, VM LinuxCNC на каждый станок, своя шина на каждую VM
Контур исполнения всегда локальный. Сервер платформы может стоять в облаке или на сервере предприятия — вплоть до air-gap; на исполнение это не влияет. Развёртывание в периметре заказчика: сервер внутри сети, узлы у станков, обмен с центром — по вашему решению.
Сервер платформы
Двойник, авторинг программ, наладка и наблюдение. Облако или сервер предприятия.
Бокс у станка
Промышленный мини-ПК с агентом: принимает порождённую конфигурацию, поднимает VM, отдаёт телеметрию.
VM LinuxCNC на станок
Каждый станок — в своей VM с контуром реального времени; падение одного не трогает соседние.
Своя шина EtherCAT
Отдельный сетевой порт на станок: приводы и входы-выходы в одной шине, без разделения трафика.
Система отказывает частями, а не целиком
Это и есть проверка архитектуры: не «работает ли она», а что именно перестаёт работать, когда рвётся связь. Ниже — честный ответ по каждому уровню.
Промежуточного состояния «экран отвечает, а машина недостижима» в этой схеме не существует: рабочее место и контур управления находятся на одном устройстве у станка.
Только EtherCAT — сознательно. Разные бренды — одна машина.
Единая шина с контуром управления от 1 кГц; другие протоколы подключаются через шлюзы в EtherCAT. Диалекты CiA-402 разных производителей нормализуются к одной объектной модели оси, и разнобрендовые приводы координируются в одну машину.
Почему одна шина. Бокс ведёт несколько станков; смешение протоколов там ломает детерминизм и изоляцию станков. Порядок один: открытый слой управления на локальном Linux, мониторинг — в облако или на edge.
Логика автоматики — в одном контуре с движением
Логика узлов — осей, приводов, входов-выходов, исполнителей — работает в том же детерминированном контуре реального времени, что и движение, на локальном промышленном компьютере. Отдельный контроллер с лестничной логикой не нужен.
Узел декларирует потребности
Исполнитель объявляет методы и что ему нужно; платформа связывает это с железом. Технолог назначает оборудование, а не программирует контроллер.
Промышленный ПК вместо контроллера
Локальный компьютер — исполнитель логики и API-сервер одновременно; без проприетарного ПЛК.
Версионируемо и наблюдаемо
Логика хранится как код, наблюдается вживую и разворачивается в событийный граф.
Место в пирамиде ISA-95
Уровни 0–2 — поле, контур реального времени, диспетчеризация — закрывает один программный слой поверх EtherCAT. Вверх, к MES и ERP, данные отдаются по API; MES и ERP не подменяются.
| Уровень | Что | Роль |
|---|---|---|
| 4 | ERP — планирование предприятия | интеграция вверх |
| 3 | MES — управление производством | интеграция вверх |
| 2 | Диспетчеризация и мониторинг — живой двойник, DRO, осциллографы | наш слой |
| 1 | Контур реального времени — координация приводов на боксе | наш слой |
| 0 | Поле — приводы, входы-выходы, датчики: EtherCAT / CiA-402 | наша шина |
Что ещё не доведено до стенда
Автономный клиент-сервер
Сервер на локальном боксе, тонкие клиенты в браузере с любого устройства цеха — прототип.
Интерфейс под роли
Технолог, наладчик, оператор — каждый видит свой набор функций и данных.
Роботы-манипуляторы
KUKA KR16 как двойник: кинематика из заводского URDF, программы движения, рабочий орган — горелка и захват. 12.09 программа впервые прошла на реальных серво; станочной механики под осями пока нет. Гексапод, трипод и дельта выведены из ближнего набора и остаются в реестре как R&D.