От визуализации к действию: Unity, машинные информационные системы, агенты искусственного интеллекта и промышленный цифровой двойник

Практическое руководство для системных интеграторов, OEM-производителей и инженеров по автоматизации

В партнерстве с Томасом Стриглом, генеральным директором realvirtual.io

Об авторе: Томас Стригл является генеральным директором realvirtual.io и имеет более чем 18-летний опыт разработки программного обеспечения для моделирования и автоматизации.

Введение

В нашем предыдущем руководстве «Проектирование, моделирование, развертывание»: Почему Unity важна для Industrial Digital Twins ? Мы обсудили Unity как платформу для создания трехмерных копий промышленных систем в реальном времени. Приведенные там аргументы сохраняют свою актуальность. В этой всеобъемлющей серии электронных книг, состоящей из двух частей, мы сосредоточимся на двух темах, которые все больше пересекаются с этой основой:

Быстрая разработка больших языковых моделей, агентов искусственного интеллекта и протокола контекста моделей (MCP): Теперь они перешли от исследовательских контекстов к инструментам, которые некоторые интеграторы начинают использовать в производственных средах.

Регламент ЕС по машинному оборудованию (ЕС) 2023/1230: Постановление было принято в 2023 году, и его полная дата вступления в силу — 20 января 2027 года — широко известна. Что сейчас меняется, так это приближение крайнего срока. Что сейчас меняется, так это приближение крайнего срока. Осталось менее двух лет, а вспомогательная основа уже сформировалась: гармонизированные стандарты пересматриваются, разрабатывается руководство по применению, а машиностроители переходят от повышения осведомленности к внедрению. Новые положения о кибербезопасности становятся эксплуатационными требованиями, а прямая поддержка структурированной цифровой документации в нормативном акте переводит документацию из статического источника в ресурс с поддерживаемым жизненным циклом.

Эти два события обычно обсуждаются отдельно. В этой серии электронных книг они рассматриваются вместе, поскольку лежащие в их основе работы значительно пересекаются. Системы искусственного интеллекта требуют структурированных и обоснованных данных. Структурированная цифровая документация, подготовленная для соответствия нормативным требованиям, также может служить основой для промышленных систем искусственного интеллекта. Четырехуровневая архитектура, описанная в части 1 (сигналы, контекст MES, документация и пространственный контекст), поддерживает как оператора, так и любые инструменты искусственного интеллекта, добавленные позже.

3D HMI — или, точнее, информационная система о машинах, которая появляется, когда оперативные машинные данные, корпоративный контекст и структурированная документация интегрируются в одну пространственную поверхность, — это место, где машинные данные, документация и информация, генерируемая искусственным интеллектом, объединяются для оператора.

Цель здесь состоит не в том, чтобы заявить о том, что искусственный интеллект преобразует фабрику, а в том, чтобы описать практические архитектурные паттерны, которые могут оказаться полезными для интеграторов, используя уже доступные инструменты и стандарты. Архитектура основана только на ее эксплуатационной ценности; в регламенте просто более четко определены сроки выхода на европейский рынок.

Часть 1

Подключенный слой: Данные, документация и 3D HMI

1. За пределами цифрового двойника

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

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

Эксплуатационные преимущества такой интегрированной среды значительны и не зависят от какого-либо нормативного контекста:

• Ускоренная диагностика неисправностей:

3D-HMI, подключенный к оперативным машинным и технологическим данным, сокращает время диагностики неисправностей, поскольку оператор может видеть уязвимый компонент в пространственном контексте, а не сопоставлять символьный код неисправности с физическим местоположением.

• Снижение экспертного барьера:

Снижает порог опыта для новых сотрудников, сменных рабочих и ротируемого персонала, что актуально практически во всех отраслях промышленности, учитывая документально подтвержденную нехватку квалифицированных технических специалистов в области механики и электротехники.

• Эффективная удаленная поддержка:

Делает удаленную поддержку значимой, поскольку сервисный специалист производителя видит то, что видит оператор, в одном и том же трехмерном контексте и может давать точные инструкции.

• Обучение без перерыва в производстве:

Позволяет проводить обучение в соответствии с реальной конфигурацией машины без остановки производства.

• Операционный контекст на уровне машины:

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

Эти преимущества предоставляются независимо от того, требуется ли пакет документации в соответствии с законодательством. Они представляют собой практическое обоснование архитектуры, описываемой в данном руководстве. Рассмотренное в разделе 3 нормативное обоснование носит параллельный характер: структурные изменения, введенные новым Регламентом ЕС по машинному оборудованию, соответствуют одной и той же архитектуре, а это означает, что нормативная деятельность и оперативная деятельность пересекаются, а не конкурируют за отдельные бюджеты.

Это меняет роль цифрового двойника. 3D-модель — это не только визуализация, но и пространственный индекс, объединяющий сигналы, корпоративные данные и документацию в форме, в которой операторы и все чаще инструменты искусственного интеллекта могут ориентироваться.

2. Четыре слоя данных, лежащие в основе работающего цифрового двойника

Используемый в работе цифровой двойник обычно взаимодействует с четырьмя отдельными слоями данных. Каждая из них неполна сама по себе.

Сигнальный слой самый быстрый и самый низкий. Входы и выходы ПЛК, положения привода, состояния датчиков, аварийные сигналы — значения, которые меняются за миллисекундные циклы. Это уровень, который уже используется виртуальным вводом в эксплуатацию и моделированием поведения, обычно с помощью OPC UA, Beckhoff ADS, Siemens S7 TCP/IP или MQTT. В большинстве случаев использования цифровых двойников достаточно цикла обновления в диапазоне 10—50 мс.

Слой MES медленнее и шире. Производственные заказы, партии, рецепты, ключевые показатели эффективности, материальные потоки, записи о качестве, показатели энергопотребления. Эти данные управляются событиями и обычно доступны через REST API, OPC UA, брокеры сообщений или прямые подключения к базе данных. Этот слой обеспечивает контекст, позволяющий интерпретировать сигнальные данные: один и тот же конвейер, работающий с одинаковой скоростью, имеет разное значение в зависимости от того, какой заказ он обрабатывает в данный момент.

Уровень документации исторически привлекал меньше всего внимания. Инструкции по эксплуатации, электрические схемы, схемы P&ID, оценки рисков, декларации соответствия, списки запчастей, версии программного обеспечения, процедуры технического обслуживания, истории обслуживания. В большинстве инсталляций этот слой используется в виде папки, сетевого ресурса или PDF-архива — поиск доступен только людям, которые знают, что им нужно. В соответствии с новым Регламентом ЕС по машинному оборудованию структура этого слоя меняется, чему будет посвящен следующий раздел.

Пространственный/контекстный слой — это сама 3D-модель. Она может служить объединяющей системой координат для остальных трех слоев. Адрес сигнала абстрактен; тот же сигнал, нанесенный на определенный клапан, который оператор может видеть и нажимать на него, интерпретируется более точно.

3. Документация в соответствии с новым регламентом по машинному оборудованию

Уже более десяти лет техническая документация, сопровождающая оборудование, поставляемое на европейский рынок, регулируется Директивой по машинному оборудованию 2006/42/EC. Знакомые обязательства — технический файл в приложении VII, инструкции по применению, декларация соответствия ЕС, 10-летний срок хранения — обычно соблюдались с помощью печатных руководств, архивов в формате PDF и бумажных деклараций.

Этот фреймворк заменяется. Регламент (ЕС) 2023/1230, новый регламент по машинному оборудованию, был принят 14 июня 2023 года и полностью вступит в силу 20 января 2027 года. Она отменяет Директиву 2006/42/EC и, будучи нормативным актом, а не директивой, применяется непосредственно во всех государствах-членах ЕС без необходимости их национального переноса.

Регламент действует уже некоторое время, но вспомогательная основа все еще дорабатывается. Запрос комиссии на стандартизацию, направленный CEN и CENELEC, был принят в январе 2025 года с целью опубликовать полный набор гармонизированных стандартов в официальном журнале к концу 2026 года. Первые проекты официального руководства по применению ожидаются с начала 2026 года, а окончательная публикация ожидается к концу 2026 года. В настоящее время ведутся практические работы по устному переводу, и проекты, выпущенные на рынок с 20 января 2027 года, должны будут соответствовать требованиям.

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

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

Цифровая документация теперь прямо разрешена: Статья 10 (7) разрешает предоставлять инструкции по использованию в цифровом формате. Статья 10 (8) разрешает предоставлять Декларацию соответствия ЕС в цифровом виде через интернет-адрес или машиночитаемый код. Инструкции по сборке частично укомплектованного оборудования (статья 11) также могут поставляться в цифровом виде. Бумажные документы по-прежнему должны предоставляться по запросу, а некоторая важная для безопасности информация для непрофессиональных пользователей должна оставаться на бумаге.

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

Кибербезопасность добавлена в качестве основного требования к охране здоровья и безопасности. Приложение III в разделах 1.1.9 (Защита от коррупции) и 1.2.1 (Безопасность и надежность систем управления) требует от систем управления противостоять разумно предсказуемым злонамеренным попыткам, которые могут привести к опасной ситуации. Функции безопасности на основе искусственного интеллекта и самообучающиеся системы явно входят в сферу применения, а для категорий высокого риска проводится более строгая оценка соответствия.

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

Что означает новое регулирование для производителей

Связанный с этим практический вопрос заключается в том, каким образом предоставленные поставщиком данные о компонентах — приводах, датчиках, клапанах, ПЛК, компонентах безопасности, ведущих устройствах IO-Link — попадают в техническую документацию производителя. Наиболее популярным здесь является структурированный формат Asset Administration Shell (AAS) — машиночитаемая спецификация цифровых двойников для отдельных компонентов, определенная IEC 63278 и Ассоциацией промышленных цифровых двойников (IDTA).

Инстанс AAS содержит паспортные данные, технические спецификации, документацию и подмодели (по безопасности, энергопотреблению, техническому обслуживанию) для одного конкретного компонента в стандартизированной форме, доступной для чтения любым потребителем с поддержкой AaS.

AAS пока еще не стал универсальным отраслевым стандартом — внедрение пока происходит лишь частично, экосистема все еще находится в стадии становления, и многие поставщики только начинают публиковать информацию. Но главное — как только критическая масса поставщиков выпустит подмодели AAS, структурированная электронная документация, соответствующая Регламенту (ЕС) 2023/1230 и в то же время обосновывающая диагностика на основе искусственного интеллекта, превращается в вопрос конфигурации, а не в проект ручной интеграции.

Поставщики, уже публикующие подмодели AAS, включают Siemens (SIMATIC S7-1500), Festo (клапанные клеммы VTSA), ABB (приводы ACS880), Pepperl+Fuchs (мастера IO-Link), WAGO и Murrelektronik. Использование AAS в качестве стандартного формата ввода данных поставщиком позволяет отслеживать цепочку компонентов на протяжении всего срока службы машины (что, согласно нормативным требованиям, требуется для технической документации, прилагаемой к оборудованию), и позволяет масштабировать структурированную документацию, на которую ссылается среда выполнения информационной системы оборудования (показанная в качестве входных данных Supplier AAS в эталонной архитектуре в разделе 6).

4. От 3D HMI до информационной системы для машин

В предыдущей электронной книге 3D HMI описывался как слой визуализации, отражающий состояние машины в пространственном контексте. С добавлением уровней MES и документации один и тот же 3D-HMI превращается в нечто большее: машинную информационную систему — единую пространственную поверхность, объединяющую текущее состояние машины, корпоративный контекст и структурированную документацию и представляющую все это оператору в нужном месте.

Терминология важна. Классический HMI представляет собой интерфейс управления и мониторинга: он показывает состояние машины и принимает данные оператора. Система управления производством (MES) находится на более высоком организационном уровне и управляет заказами и производственными данными на всех машинах и линиях. Машинная информационная система (MIS) в том смысле, в каком она используется в этой электронной книге, находится в самом устройстве: это интегрированное представление, которое объединяет все виды информации об этой конкретной машине — состояние датчиков, текущий порядок, инструкции, схемы, историю аварийных сигналов, версии программного обеспечения, декларации соответствия — на одной навигационной пространственной поверхности.

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

Определение информационной системы машины

Примечание по терминологии: машинная информационная система (MIS), используемая в этой электронной книге, на уровне активов — это термин, который мы предлагаем, а не устоявшуюся отраслевую категорию. Традиционные HMI сосредоточены на управлении машинами и взаимодействии с операторами, платформы MES управляют производством и рабочими процессами на уровне предприятия, а системы управления информацией о жизненном цикле активов обрабатывают технические данные, документацию и данные жизненного цикла. Каждая из них частично отвечает информационным потребностям оператора, но ни одна из них полностью не описывает интегрированный, специфичный для машины вид, представленный через пространственный 3D-интерфейс.

Термин «машинная информационная система» используется здесь для описания недостающего слоя: унифицированной информационной поверхности машинного уровня, объединяющей операционное состояние, корпоративный контекст и структурированную документацию в едином пространственном интерфейсе для оператора.

Типичный пример эксплуатации — диагностика неисправностей.

• В традиционном HMI оператор обычно видит код неисправности и текстовое сообщение, а затем обращается к отдельному руководству, чтобы найти соответствующий раздел.
• В более интегрированном HMI оператор может нажать на соответствующий компонент в трехмерном виде, а зритель может отобразить текущее состояние сигнала, активный производственный заказ от MES, соответствующую историю технического обслуживания и соответствующий раздел цифрового руководства — и все это под одним и тем же идентификатором компонента, который указан в файле GLB или графике сцены.

Ценность этого подхода выходит далеко за рамки устранения неисправностей.

В проектах, в которых информационная система о машинах занимает центральное место в работе оператора, обычно проявляются четыре операционных преимущества:

Более быстрое выявление неисправностей и реагирование на них: Промышленные машины часто содержат сотни датчиков, приводов и компонентов, каждый из которых имеет свой идентификатор в плоском пространстве имен. Символическое сообщение, такое как «Неисправность датчика BG2-S147», требует от оператора перевода абстрактного идентификатора в физическое местоположение. Та же неисправность, показанная на трехмерном изображении (неисправный датчик, выделенный на фактической геометрии машины), исключает этап перевода. Для сложных машин или для персонала, который не работает с системой каждый день, это разница между пятиминутным поиском и немедленным ответом.

Унифицированный операционный контекст: Когда данные MES накладываются на трехмерную сцену, оператор видит не только то, работает ли машина, но и ее производительность по отношению к активному заказу, целевому времени цикла и последним ключевым показателям эффективности. Информация об обслуживании и качестве отображается на соответствующем компоненте, а не на отдельной панели управления. Это то, что обеспечивает машинная информационная система, основанная на пространственном контексте, а не на таблицах и списках, и именно по этой практической причине этот термин более точен, чем «3D HMI», для обозначения результатов этой архитектуры.

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

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

Технические компоненты для такого типа интеграции доступны сегодня: WebSocket транслирует сигналы в реальном времени, REST или OPC UA для контекста MES, структурированную цифровую документацию, привязанную к идентификаторам компонентов, и 3D-просмотрщик (встроенный в Unity, WebGL или стек на основе браузера, такой как веб-просмотрщик realvirtual.io, с публичной демонстрацией по адресу web.realvirtual.io/demo), отображающий комбинированное представление. Оставшаяся работа интеграторов в основном носит архитектурный, а не технологический характер.

5. Архитектурные паттерны для интеграторов

Лучшие практики создания информационной системы для машин

Рассмотрение трехмерной сцены как источника геометрической и идентифицируемой истины. Идентификаторы компонентов, кинематическую структуру и метаданные можно хранить в файле сцены (например, в виде данных расширений в GLB или в метаданных префаба Unity). Затем другие системы ссылаются на эти идентификаторы без их повторного определения. Этот подход позволяет одним щелчком мыши в трехмерном виде последовательно преобразовывать сигнал, запись MES и раздел, выполняемый вручную. На скриншоте ниже эта схема показана на реальной упаковке: Unity Editor — это среда разработки, в которой машиностроитель импортирует САПР, определяет кинематику и иерархию компонентов, настраивает поведение датчиков и приводов и прикрепляет структурированные метаданные, которые передаются с каждым GameObject в течение всего срока службы машины.

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

Использование тонких специализированных адаптеров для каждого слоя данных. Адаптер WebSocket для сигналов, клиент REST или OPC UA для MES, сервис документов, предоставляющий инструкции и схемы по идентификаторам компонентов. Каждый адаптер отвечает за один источник. Такие наборы инструментов, как realvirtual.io, структурируют сигнал и сцену в соответствии с этими принципами; тот же шаблон можно распространить на MES и документацию.

Управление версиями информационной системы машины вместе с программным обеспечением. В тех случаях, когда документация предоставляется в цифровом виде, регламент по машинному оборудованию требует, чтобы декларация соответствия ЕС и инструкции по эксплуатации оставались доступными в течение всего срока службы машины, в том числе в обновлениях программного обеспечения. Прагматический ответ не ограничивается только документацией: вся информационная система машин — трехмерная сцена, карты сигналов, метаданные компонентов, структурированная документация и накопленные в течение многих лет эксплуатационные знания — сама по себе является версионным артефактом, привязанным к серийному номеру конкретной машины и выпуску программного обеспечения. Здесь нужны те свойства, которые разработчики программного обеспечения уже решили за последние два десятилетия: неизменные исторические условия, позволяющие точно реконструировать все предыдущие поставки, подписанные теги, обозначающие состояние выпуска на рынок в нормативных целях, филиалы для вариантов машин и конфигураций, специфичных для клиентов, и распределенные клоны, которые выживают у любого поставщика инструментов в течение более десяти лет — обычно это фактический срок службы промышленного оборудования, а не нормативный минимум. Git, применяемый на уровне целого пакета машины, а не только к исходному коду, замечательно соответствует этому набору свойств. Такие системы, как Gitea (архивный слой эталонной архитектуры realvirtua.io в разделе 6), превращаются в естественный формат доставки и архивирования пакетов промышленных машин, а модели управления версиями, лежащие в основе разработки программного обеспечения, напрямую влияют на ограничения, связанные с поставкой традиционного оборудования.

Предоставление набора документации через структурированный API. Служба документов, которая возвращает соответствующий раздел руководства в ответ на идентификатор компонента и код неисправности, полезна для оператора-человека. Тот же структурированный доступ также поддерживает сценарии использования, описанные в части 2, где инструменты искусственного интеллекта могут основывать свои результаты на фактической документации производителя, а не полагаться только на обучающие данные.

6. Эталонная архитектура

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

• Что касается разработки, Unity Editor использует ресурсы САПР и 3D из Unity Asset Manager и метаданные машин из источников AAS поставщиков (Siemens, Festo, ABB) и системы PDM, создавая сопоставления метаданных, сигналов и документации с ядром realvirtual.io. Затем Unity используется для настройки импортированной CAD-модели станка путем применения материалов, кинематических характеристик и ограничений движения к отдельным компонентам. Это превращает статическую геометрию в полностью интерактивную и физически реалистичную 3D-модель машины, в которой пользователи могут перемещаться и работать в режиме реального времени.

Пакет для экспорта — 3D-модель машины (GLB), данные AAS, документация и подписанная декларация соответствия — заархивирован в репозитории Gitea в виде релиза с тегами, предназначенного для 10-летнего архива, требуемого в соответствии с Регламентом по машинному оборудованию (ЕС) 2023/1230.

• Что касается поставки, то среда выполнения машинной информационной системы — realvirtual.io WEB на Three.js, TypeScript, лицензированная AGPL и самостоятельно размещаемая — развертывается из архива Gitea и подключается к работающему предприятию через rv Connect (живые сигналы), InfluxDB (временные ряды) и интерфейсы ПЛК машины, предоставляя оператору информацию о состоянии машины, документации, техническом обслуживании, управлении запасными частями и анализе.
• Ядро realvirtual.io — общий диск, датчик и кинематическое поведение — существует как в среде разработки, так и во время выполнения: в качестве компонента Unity во время разработки и виртуального ввода в эксплуатацию и в качестве компонента Three.js во время выполнения, поэтому поставляемая информационная система о машинах основана на тех же моделях поведения, которые используются при моделировании.
• Существующая система автоматизации — ПЛК, приводы, датчики, роботы, MES — находится в нижней части стека без изменений. Над ним расположены сигнальный уровень и слой MES, которые большинство интеграторов уже создают. Кроме того, служба документации, структурированная по идентификатору компонента и коду неисправности, отвечает требованиям нормативного архива и потребности оператора в быстром и достоверном справочном материале на станке.

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