Вторая часть посвящена проблеме адекватности обоих двойников и путей её решения. Именно неадекватность модели – это основная преграда, о которую спотыкается практически всё, выдаваемое сегодня за «Цифрового двойника».   

В первой части [DT1] были рассмотрены проблемы современного «Цифрового двойника» \ Digital Twin (ЦД \ DT) и общие подходы к его идентификации, в первую очередь, его «Трехкомпонентный состав DT» («три кита» двойника): реальный объект (физический двойник, «физик», Physical Twin, PT), его модель (собственно сам DT) и обратная связь – как передача эксплуатационных данных объекта в контекст его модели (в идеале двухсторонний обмен). В идеале должен быть не только двухсторонний обмен по эксплуатационным данным, но и обмен по состоянию самой структуры объектов (синхронизация структуры), что будет подтверждать актуальность используемой модели (структурную адекватность обоих двойников). 

В большинстве случаев предлагаемые «примеры DT» представляют собой незамысловатый ребрендинг привычных (обычных) систем, т.е. скорее являются Pseudo Digital Twin \ Digital Impostor, а не Digital Twin, при этом даже имея все три компонента DT могут содержать модель не адекватную своему физическому близнецу («as-is» vs «as-really-is").

Кроме маскирования под DT обычных SCADA - систем и CASE \ BPMS типа ARIS (см. первую часть [DT1]), включая Enterprise Architecture (EA, архитектура предприятия как цифровой двойник предприятия), красивую вывеску «DT» прикручивают к системам:

- ERP, например, dia$par,

- architecture as code, например, dochub.info,

IoT-платформ, например, AWS IoT TwinMaker или Winnum (интерактивный цифровой двойник как цифровая тень).

Современный ИИ пока лишь просто повторяет маркетинговую мантру (чепуху) из ранее прочитанного и поданного ему как «обучение», например, спросите его про тот же, AWS IoT TwinMaker и получите ответ, что это тоже DT.

Типовой «DT» выглядит примерно так, как показано в презентации Цифровой двойник предприятия на платформе АСис, т.е. красивые картинки, собственное понимание термина «Цифровой двойник», никаких технологических стеков и метамоделей.

Чтобы понять реальное положение дел можно задать простой вопрос продавцам Цифровых двойников предприятия: покажите в деталях цифрового двойника (выполненного вашими технологиями) простого предприятия, например, типовой нотариальной конторы, и цифрового двойника вашей компании (разработчика). После этих вопросов диалог скорее всего прервется, т.к. «дежурные отговорки» типа "мы связаны NDA" - не сработают.

Путаница с DT возникает часто по двум причинам (подменам понятий). Первая, - это подмена DT классическим мониторингом, что технологического процесса (АСУТП), что бизнес-процесса: технологический конвейер (производственная линия) с мониторингом через SCADA или кредитный конвейер с мониторингом через BAM (Business Activity Monitoring). В случае мониторинга на выходе будут считанные в реальном времени параметры и состояния объектов мониторинга, их метрика, агрегация метрик, аналитика, графики распределений величин, дашборды и т.п. Однако при таком мониторинге самой "модели объекта" вообще может не быть.

Вторая, – это подмена DT классическим моделированием (BPM\ EA). Придуманные и визуализированные модели «as-is», ошибочно выдаваемые за DT, не гарантируют адекватность реальным процессам, реальному объекту, т.е. «as-really-is» (как есть на самом деле). Нарисовали модель, организовали обмен от датчиков реального двойника (PT) и почему-то считаем, что это и есть DT, хотя нет достаточных оснований (доказательств), что структура и состояния цифрового и физического двойников совпадают.

Ни одного подробного примера DT пока не видел, т.е. цифровой двойник - это видимо пока что лишь маркетинговый термин, за которым чаще всего лежит классическое математическое и иное (включая BPM) моделирование. Как и 15 лет назад чтобы увеличить продажи некоторые продавцы клеили на обычный сервер наклейку «cloud computing», точно также как 30 лет назад: Это вам не просто компьютер, а "Компьютер с курсором". Какой смысл, кроме маркетинга, называть старые вещи (классические технологии моделирования) новыми именами (двойниками)?

Поражают хайп-фразы типа: Сегодня Digital Twin — это не просто модное словосочетание, а ключевой инструмент оптимизации производства. 

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

Вокруг DT вертятся модные и непонятные «знаки внимания»: «digital enterprise» (предприятие с коэффициентом автоматизации единица?), Архитектор 2.0, Enterprise 3.0 (Smart Space), Индустрия 4.0 и т.п.

Например, возьмем первое предложение из «Применения Digital Twin для Индустрии 4.0: обзор»: «Цифровой двойник — это виртуальное представление объектов, процессов и систем, существующих в реальном времени». Это не DT, а просто модель. 

С таким подходом мы рисуем схему из «10 квадратиков» и смело заявляем, что это DT предприятия (например, сеть из 10 магазинов). Связь с реальным объектом? Передаем в нашу диаграмму визуализацию сигнала электронной таблички с двери каждого магазина «Открыто \ Закрыто», например, закрашивая в зеленый или красный цвет квадратик, закрепленный за соответствующим магазином. Упрощенно, но и это есть подход к разработке большинства «DT», но к «настоящему DT» подобное отношения не имеет.  

Несмотря на массовую дискриминацию термина сам концепт «Настоящий DT» все же имеет основание и потенциал реализации. Ниже для более широкого охвата проблематики DT будем рассматривать различные сферы его обсуждений (термин «применений» - пока преждевременен): изделия – вещи (например, табуретка), автоматизация бизнес-процессов (BPMN) и Process Mining (Манифест), управление технологическими процессами (SCADA) и IoT и др. Странно: обсуждений DT – много, но вот простой и «человеческий» пример «DT табуретки» не видел, и только «безотказный» ИИ готов рассказать о нем.

Динамические изделия типа «процесс» и «предприятие» (а также отрасль, государство или здание, город  или даже пациент) – куда более сложные чем «условный табурет в окружающей среде и подверженный нагрузкам» (см. выше), однако сама идея «инструментальности» в DT в нем схожа и более очевидна (понятна), что позволяет через аналогию проще донести ключевой концепт Инструментального цифрового двойника, который обычно используют для изделий типа «офис» (непроизводственная компания) и его компонент (например, кредитный конвейер) или «завод» и его компонент (например, сборочный конвейер).

Ниже показаны некоторые технологии, которые на основе своей «инструментальности» позволяют говорить о DT – как о модели с гарантированной адекватностью своему физическому близнецу (соответствие DT и PT). Ключевой момент в том, что именно введение «Инструментальности» в обеспечении адекватности модели позволяет говорить о новом подходе, который в комплексе формирует новый технологический концепт, но идейно (формально) в рамках того же привычного термина «Цифровой двойник» (цифровой и аналоговый двойники). Речь не про инструментальные считывание и передачу эксплуатационных параметров (IoT, SCADA, BAM и т.п.) - как передачу текущих параметров функционирования в модель, т.е. фактически классический мониторинг. Речь про инструментальный мониторинг (или развертывание, майнинг и т.п.) структуры \ модели.

1. Базовые условия DT

Про достаточное условие в определении DT сложно сказать, но про необходимое условие ясность есть. Базовые (необходимые) условия. DT - это модель, которая:

А) должна быть Гарантировано адекватна своему физику (реальности). Полагаю, что это достигается только инструментальными средствами, как минимум инструментами тестирования \ верификации, а как максимум генерации «физика» на основе модели или воспроизведения -восстановления модели из реального близнеца (mining, например, process mining);

Б) должна обмениваться информацией с «физиком»: оба двойника (цифровой и физический) должны иметь возможность синхронизации, в том числе, по структуре. Просто «напечатать» изделие на 3D принтере – этого мало, нужна еще его синхронизация в процессе эксплуатации, а при изменении структуры изделия (например, сломалась ножка напечатанной табуретки) – передача в модель (DT) этой информации. Синхронизация в процессе эксплуатации может предусматривать как обмен (односторонней или двухсторонний) «по данным», так и обмен информацией «по структуре» для подтверждения структурной идентичности обоих двойников. Синхронизация "по структуре" более сложный процесс, чем по "данным".

Адекватность должна быть подтверждённой «средствами объективного контроля».  Синхронизации «по структуре» в предельном случае – это и есть генерация \ восстановление одного двойника из другого. Синхронизация «до данным» - это обмен информацией о состоянии \ конфигурации, параметрах (среды, процессов): обычно от «физика» к модели, но может быть и наоборот – для загрузки новой конфигурации из модели в физический двойник. Классический пример синхронизация «по данным» - это мониторинг, например, средствами BAM, SCADA. Примером получения и обмена информацией «по структуре» может быть получение, передача и анализ рентгеновского снимка изделия (или человека, если речь про DT пациента), данных от 3D-сканера и т.п.

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

Много придумано разных аббревиатур моделирования, от CASE (где S = system или software – не важно) и BPMS (где M - что modeling, что mgmt. – без разницы) до MBSE, MDSD, MDA, MDD и т.п. Следуя определению DT, любая исполняемая модель уже удовлетворяет базовому (она уже адекватна «физику», раз его породила), но ещё не достаточному условию.

1.1. «As is» vs «as-really-is»

С одной стороны, мы можем нарисовать (более веско звучит «смоделировать») очень детальную (абсолютно подробную) планировку помещения \ здания (СПДС, BIM) или схему процесса (EPC, BPMN) и наивно считать, что это «адекватная модель объекта». Причем, ProcessGPT - это тоже в классификации "рукотворная as is". Кроме классических типов моделей «as is» & «to be» есть еще «as-really-is», которая отражает «как в реальности есть на самом деле» и она (объективная реальность) часто сильно отличается от «красивой» кем-то нарисованной схемы «as is» (субъективного взгляда).

Просто «моделирование», например, процессов предприятия в современной BPM-системе (т.е. ARIS образца 1992 года и подобные) позволяет делать только «as is», а не гарантированный «as-really-is». Какие бы слова при этом не говорились: «полно-полное» описание компании (предприятия) начиная с онтологии и заканчивая «мелко-мелкими» (атомарными) физическими процессами производства \ административными операциями (бизнес-процессами), включая, мельчайшие детали («винтики»): детальные алгоритмы и правила, роли и ИТ-компоненты (ИТ-архитектура, CMDB и т.п.). Поэтому классическое моделирование будет противопоставлено инструментальному моделированию как гарантия адекватности, т.е. «as is» vs «as-really-is».  «Инструментальное» не в смысле использования ARIS и подобных инструментов моделирования процессов и архитектур, а в смысле получение модели (или реального двойника) «автоматически».

Цитата из «Все врут! или казуистика описания бизнес-процессов»:

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

DT должен быть основан на «as-really-is» = «как есть на самом деле», а не «as is» = «как это видит субъективный взгляд художника, моделирующего процесс или архитектуру (EA)», в том числе коллективный, т.е. группы архитекторов, разработчиков, пользователей и т.п.

В этом смысле можно согласиться с утверждением, что «DT не является моделью», см. Подробное объяснение определения DT. В том смысле, что DT это много больше чем «просто модель», как минимум, модель должна быть адекватная, например, исполняемая или автогенерируемая, или хотя бы верифицируемая инструментально (не ментально, не субъективно).

2. Инструментальный подход к DT

Инструментальный способ - это без участия человека. Имеем две разные технологии: модель -> реальность и реальность -> модель. В обоих случаях «->» обозначает автоматический \ инструментальный переход. Такой (инструментальный) подход позволяет исключить человеческий фактор и автоматизировать саму процедуру создания одного из двойников или их синхронизацию по структуре (синхронизация по данным – это скорее мониторинг) \ верификацию «структурной идентичности».

«Модель -> реальность» - например, исполняемая модель bpmn (что нарисовал, то и исполнил), т.е. модель формирует реальность (как и 3D печать). Второе направление (реальность -> модель) – это, например, process mining или «архитектура как код» (например, «боевой» репозитарий + «диаграмма как код» для графической визуализации), когда реальные конфигурации автоматически формируют модель. Другой пример, - раскрытие сети lan/ wan (HP OpenView Network Node Manager и подобные).

Примеры инструментальных подходов:

• Модель -> Физический объект: 3D принтер, WFE (BPMN engine);

• Физический объект -> Модель: 3D сканер, Process mining (восстановление логики процесса по журналам событий \ логам ИТ-систем, исполняющих процесс).

Пример не инструментальных подходов:

• Модель -> Физический объект: разработать вручную комплект чертежей изделия (ЕСКД) и отдать на производство;

• Физический объект -> Модель: нарисовать схему процесса \ архитектуры в редакторе BPM \ EA (Aris \ Archi и т.п.).

Если на входе модель (DT), а на выходе физический двойник, то «модель порождает» (прямое проектирование). Если наоборот, то «физик порождает» DT (обратное проектирование).

Когда DT создан не инструментальным путем, то применяется инструментальное обратное проектирование, например, через Process mining. В зависимости от полноты и качества такого майнинга (пока это очень ограниченный инструмент) можно этот подход считать инструментом верификации модели (при наличии подробной «рукотворной» модели) \ синхронизации "по структуре" или (когда достаточно данных) полноценным генератором модели.

Примеры прототипов (DT пока еще как бы нет, т.е. не встречались пока) инструментальных двойников «прямого цикла» для вещи (stool twin) и процесса (process twin):

а) 3D-модель (CAD) (далее компиляция, например, G-code) –> среда изготовления (станок ЧПУ \ 3D-принтер) –> физический экземпляр (предмет, например, табурет-монолит);

б) Схема процесса в BPMN моделере (далее компиляция, например, в BPMN XML) -> среда исполнения (WF Engine) -> исполняемый экземпляр процесса (приложение \ программа).

Развёртывание модели в физический объект («цифровая модель – прототип изделия») может называться: авто создание объекта через «цифровой мастер» (Digital master), Model Based конструктор и т.п.

Другими слова, имеем прямое \ обратное (инструментальное) проектирование – как Pre-Manufacture \ Post-Existing «Digital Twin»: зеркало Pre-Digital Twin в лице физического объекта («физик», PD) или зеркальное отражение «физика» в цифре (Post).

Примерно, как философы можно задаваться вопросом: Что первично Идея (модель, концепт) или Материя (изделие, экземпляр)?

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

Основное внимание в статье уделено идентификации DT и принципам построения путем выделения особого класса «Инструментальный DT» (Pre-Manufacture \ Post-Existing «Digital Twin»). Использование DT, включая предсказание поведения, симуляцию, тестирование и т.п. – это отдельное тема.  

На рис. 1 а) показаны основные направления реализации DT инструментальным способом.

Варианты «Ручной способ построения и инструментальной верификации соответствия двойников» Рис. 1 а) – это компромисс (от безысходности), когда построить, например, цельную модель, инструментальными методами проблематично, но есть, например, набор мини-моделей (полученных инструментальным способом), которые могут верифицировать отдельные части общей «рукотворной» модели. Кроме верификации возможно обогащение исходной (целостной) модели данными (по структуре) из мини-моделей.

В какой-то момент модель (DT) может «рас синхронизироваться» со второй половиной (PT), при этом система контроля должна выдать сообщение (условно) «DT приболел, нужно его реанимировать \ актуализировать». В идеале конечно предпочтительнее самосинхронизирующиеся (адаптивные) модели. Например, инструментально созданное изделие, например, табуретка (3D-print), со временем в процессе эксплуатации получила повреждение (обломилась ножка) и система двойников как минимум должна это идентифицировать (через «обратную связь»), а как максимум построить новую модель (DT) с обломанной ножкой (например, 3D-scan). В идеале конечно хорошо бы и спрогнозировать ожидаемую неисправность (через модель «прочности-усталости» и т.п.), но для начала нужно с базовыми элементами DT разобраться, т.е. без прогнозирования. С более сложными примерами изделий, которые по определению «динамические системы», например, «процесс» или «предприятие», ситуация должна быть аналогичная. Под DT Предприятия (как и «Архитектура предприятия») обычно понимают модель его процессов и ресурсов процесса (HR, инструменты, входы\выходы, включая документы и продукты), модель архитектуры его ИТ-систем (инструменты) и взаимодействие с внешним миром. 

2.1. Digital Twin as Сode

Когда модель (DT) автоматически строится на основании реальных конфигов систем – это тоже вариант реализации инструментального подхода (например, architecture as code), но конечно в конечной системе должны быть соблюдены оба базовых условия полностью.

Architecture as Сode (AaC) / Infrastructure as Code (IaC, автоматическая установка, конфигурация и развертывание) и т.п. - это не про визуализацию «придуманного» (как в классическом моделировании), а формализация взятого «1:1» из физической системы или наоборот, загруженного в физическую систему (Infrastructure-from–Code). В идеале это «из коробки» двухсторонняя связь: и документирование типа Documentation as Code и deploy (развертывание, конфигурирование). Все это тоже примеры инструментальных подходов - как противопоставление ручному конфигурированию или описанию (документированию). Сама модель (модель конфигурации) может быть представлена на разных языках DSL, но в некоторых инструментах есть возможность графической визуализации артефактов системы. В данном контексте в технологиях AaC \ IaC основной акцент делаем не столько на «фишках DevOps», включая, масштабирование, удобство развертывания, повторное использование и т.п., а на решении проблемы «неактуальности архитектуры» через автогенерацию - как гарантию актуальности описания \ модели \ схемы, т.е. автодокументация, автоматическая связь архитектурного описания с реальной инфраструктурой \ архитектурой.

«Рядом» можно упомянуть технологии Diagram as code \ text to diagram (концепт визуализации по скрипту включая PlantUML, Mermaid, Graphviz, D2 и даже LaTeX), Configuration as Code, Network as Code, Policy as Code и прочее, а также «бизнес-процесс как код» и даже «предприятие как код», где отдельное направление – это «семантизация предприятия» и его формализация на каком-либо DSL (Domain-Specific Language), обладающим куда более мощной выразительностью, чем классические нотации моделирования BPM (набор из ARIS Method и т.п.) и EA (archimate \ togaf, C4 и т.п.).

Общий вектор «семантизации предприятия» это путь от «Создаём DSL для моделирования данных» к «Создаём DSL для моделирования предприятия и его цифрового двойника». У семантического предприятия «внешне» все также: схемы процессов и архитектур, цветные динамичные индикаторы на «приборной доске управления президента компании» (ПО класса «президентский мониторинг»), дашборды аналитики с объемной визуализацией (3D), анимированные KPI и т.п., но «под капотом» это модели классов, метамодели, онтологии и другая семантика через синтаксис языков OMG MOF, W3C OWL\RDF и т.п.

Только пока «под капотом» ERP и подобных систем этого нет. Вообще, стронно говорить о том же DT Предприятия, если пока еще нет нормальных (рабочих) онтологий \ метамоделей Архитектуры предприятия: archimate и togaf - это пока «детский сад», к сожалению. Точнее два «детских сада», т.к. эти две группы одного Open Group (OG) делают две разные метамодели «одного и того же». Понятно, что с чего-то нужно начинать (а начали в 1995: TOGAF 1.0), но уж «как-то не быстро».

3. MDA\MDD

В понятие «MDA\MDD» (Model Driven Architecture \ Model Driven Design \ Model Driven Development) иногда вкладывается разный смысл и есть много схожих терминов, типа MDE, MBE, MBSE, MDSD, CASE и т.п., тут мы имеем ввиду «исполняемый MDD» (executable model), т.е. когда реализация (код) автоматически генерируется из моделей. 

Небольшую хронологию инструментов executable model показал ИИ, список исполняемых инструментов UML (Executable UML 2017) см. на modeling-languages.com.

Однако подобных инструментов намного больше, назовем пару отечественных: из «классики» (UML) – Flexberry, а Runa WFE [WFE24] поддерживает две нотации (BPMN и AD UML).

Современные low code / no code имеют тут же концепцию исполняемого MDA\MDD (в идеале «программирование без программирования»): если ранее для этого использовали исполняемый UML («пионер» Rational Rose), то сейчас это в основном исполняемый BPMN (BPMN-engine).

На тему MDA\MDD недавно высказался автор плагина Rational Rose для инструмента Borland, Delphi – назвав его «анти-шаблоном» (см. Episode transcript). 

Полагаю, что OMG (не путать с OG) забросила развитие UML, переключившись с него на BPMN ввиду бесперспективности UML в части исполняемого MDA\MDD и хороших перспектив в этом направлении у BPMN-engine. Вроде бы верное направление развития «BPMN – engine», т.е. «шаг вперед» исполняемом MDA\MDD, однако все равно это технология для построения DT (модели процесса) еще недостаточна. Да и OMG похоже также как когда-то к UML потеряла интерес к развитию исполняемого BPMN.

Качество, точнее «зрелость», современных технологий характеризует их совместимость, что low-code noBPMN, что только исполняемый BPMN (совместимость BPMN-engine): не обеспечивают совместимость и похоже, что обеспечить ее нереально (много чего еще не хватает в спецификации BPMN), см. Оценку совместимости платформ low-code.

Таким образом, инструментальный переход «от модели объекта к реальному объекту» (исполняемому коду) в программировании – это генерация кода на основе модели: что «древний» MDA\MDD на исполняемом UML, что современный его «перепев» на исполняемом BPMN или в собственной нотации (noBPMN).

Однако исполняемый MDA\MDD «из 2025 года» уже позволяет говорить о прототипе DT: «цифровой двойник программы» (приложения) или, если ПО реализует бизнес-процесс, то о «цифровом двойнике процесса» (пока в основном только workflow). В нем уже штатно реализуются подсистемы управления экземплярами \ мониторинг состоянием процессов (например, через Camunda cockpit) и др. Справку по cockpit (кабина управления) см. Definition: Digital Twin Cockpit (DTC).

Исполняемость модели позволяет инструментальный переход от модели объекта (образу) к физическому экземпляру объекта (исполняемому коду). Технология WFE (WF Engine – общий случай BPMN-engine) показана на простом примере «Hello Calculator» [WFE24]. Современные технологии WFE (в первую очередь на BPMN, т.е. BPMN engine) позволяют создание DT только в совсем простых случаях \ примерах, кроме того, они еще не умеют стандартизированным методом моделировать данные для передачи в BPMN engine.

Аналогия MDD из программной инженерии в конструкторской -  это 3D печать: печатаем (инструментально преобразуем) из модели условную табуретку или программный (исполняемый) код, т.е. программное изделие.

4. Цифровой тройник

Если в системе близнецов реализованы одновременно инструментальные Pre и Post подходы, то можно говорить о «цифровом тройнике», например, если одновременно применить прямое (Pre-DT, где нет еще «физика») и обратное (Post-DT, анализ существующего «физика») проектирование, то получим Цифрового Тройника (ЦТ). Варианты ЦТ: модель –> физик –> модель’ или физик –> модель –> физик’.

Этапы «ЦТ первого типа»:

1. Pre-Digital Twin. подготовка исходной модели – прототипа, создание модели (project / model); 

2. Physical Twin. Адекватный модели физический объект, который получен через развертывание (deploy), т.е. развертывание модели в физический объект (автоматическое изготовление по модели);

3. Обновление модели цифрового двойника: сканирование или исследование цифровых «следов и теней» (mining), образованных функционированием объекта. Реализация связей «Связность по данным» (классический мониторинг) и «Связность по структуре». На выходе: новая модель (модель №2), воспроизведенная «по следам / теням» физического двойника;

4. Верификация исходной модели и модели №2. Если «физик» был изготовлен из модели №1 с дефектом (дефект производства), то сравнение двух моделей 1 и 2 это выявит.

В данном случае, имеется два инструментальных перехода: «модель-объект» и «объект-модель», т.е. формула «модель-объект-модель’» - как замкнутый инструментальный «тройной» преобразователь («тройник») или как система полного (замкнутого) цикла.

Термин «нет еще «физика» - условный, т.е. может происходить «трансформация текущего, существующего» PT по данным модели. Например, конфигурационные файлы из DT загружаются в сеть физических сетевых коммутаторов и маршрутизаторов, и физическая сеть перестраивается (фактически возникает новый сетевой сегмент, например, новые VLAN). Понятие «развертывание» / построение Physical Twin – часто условно, т.е. это не производство новых сетевых устройств, а только их конфигурирование в соответствии с моделью Pre-Digital Twin (например, запись в устройство образа Cisco IOS и конфигурационных файлов).

5. Ограничения «DT-образных» инструментальных технологий

Есть прямой и обратный инжиниринг (проектирование). Мы рассматриваем автоматизированный (инструментальный) процесс инжиниринга – как сквозной процесс от формирования модели до автоматического «воплощения» изделия из модели. Прямой инструментальный инжиниринг – это «Инструментальный способ построения» изделия (что табуретки, что программы, что предприятия, здания, города и т.п.) по чертежам (моделям). Что 3D-принтер, что исполняемый MDA\MDD – принцип схожий: из модели получаем изделие (физическое или программное изделие - код).

Обратный инструментальный инжиниринг – это инструментальный анализ (сканирование, mining и т.п.) существующего изделия и построение его модели. Термин немного «натянутый», например, «одни ИИ» считают Process Mining технологией обратного инжиниринга, другие – нет. Классика отечественного reverse engineering - Ту-4, тепловоз ТЭ1, К1810ВМ86 и многое другое - получены более «серьезными» методами реверс-инжиниринга, но идея та же. Часто есть только «черный ящик» - программа и нам нужно без знания ее алгоритма работы (кода, который обычно проприетарный) по оставляемым ею артефактам («следам и теням») получить алгоритм \ модель ее работы. Классическая обратная разработка кода – это про другое (дизассемблеры, отладчики и т.п.), но нам важна аналогия.  

Рассмотрим активные и пассивные методы. Пассивные методы обратного инжиниринга (применительно к DT) и построения модели объекта — это, например, методы анализа цифровых теней \ следов, включая Process mining \ Task Mining. Digital shadow vs digital footprint.

Для следов и теней объект должен быть «динамического вида», т. е. исследуется некая история «жизнедеятельности» объекта. Например, результат 3D‑сканирования изделия (табуретки) — это не цифровые тень или след, а скорее итоговая цифровая копия / модель, которая уже была составлена по отдельным артефактам, которые условно можно назвать «цифровыми тенями» (синтез структуры на основе обработки «теней»). Кроме того, анализ следов и теней — это пассивные методы, а сканирование все же — активный.

Иногда вводят «Development Digital Twin» как противопоставление «Usage Digital Twin»: в первом случае — создали «двойника» (пока псевдо‑двойника, статическую модель) и «забыли», во втором — двойник предполагает взаимодействие с близнецом в процессе эксплуатации. «Development Digital Twin» — назвать двойником проблематично, т.к. это всего лишь этап создания, т.е. мы предполагаем все же наличие DT на стадии эксплуатации (в связке со вторым близнецом), а этап создания DT (цифровой копии \ модели) или физического близнеца (по Pre-DT) - это только первый этап, за которым следует эксплуатация DT. Второе базовое условие DT - синхронизация в процессе эксплуатации PT - косвенно подчеркивает динамические свойства связки обоих двойников (динамику, взаимодействие).

Активные методы обратного инжиниринга и построения модели объекта – это, например, сканирование объекта, например, раскрытие вычислительной сети через ping, SNMP, WMI и т.п., т.е. это больше чем формирование сетевой топологии.

Активные и пассивные могут быть использованы как при построении модели объекта, так и при верификации и синхронизации (по данным и по структуре) модели с «физиком». Пример информации «по данным»: температура каждой ножки табуретки; пример информации «по структуре»: отсутствие одной ножки, трещина или деформация в ней.

Инструментальное развертывание (deploy), контроль – верификация как элементы DT пока ограничены и не позволяют «в лоб» формировать двойников. Тот же Process Mining даже при наличии подробного логирования («вход» для процедуры Process Mining - журналы событий) не гарантирует адекватность сгенерированной модели, например, даже при большом числе отработанных экземплярах есть ненулевая вероятность, что по некоторым возможным маршрутам ни один экземпляр так и не отработал за время формирования лога (для анализа нужно больше вариаций).

Если «вытащить» алгоритм из кода путем обратного проектирования (реверс-инжиниринга) – большая проблема, то «вытащить» алгоритм из мозга исполнителя, «который он действительно будет применять» – задача еще сложнее (фактически только пост-контроль). Даже при наличии описания алгоритма исполнитель может его не знать (не прочитать или прочитать, но не понять) или действовать со злым умыслом по иному алгоритму. Вообще DT с участием человека в процессе (моделирование поведения) – это отдельная тема, где некоторые процессы будут обозначены как «черные ящики» с непонятной логикой внутри.

Применительно к процессам (бизнес-процессам, технологическим и т.п.) – в основе модели (DT) лежит алгоритм действий. В человеко-машинной среде они распределены в «памяти» "человека – исполнителя" и в памяти машины (запрограммированный алгоритм), и только при 100% автоматизации (автоматическое устройство) – только в памяти машины. Каким-либо образом вводить в модель (DT) алгоритмы для человека – исполнителя и прогнозировать выполнение их на практике – сложно (по сути будет DT человека). Поэтому чаще разговор о DT возникает, когда имеется достаточно высокий уровень автоматизации, например, в SCADA- системах, IoT.  

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

6. Эмулятор

С эмуляторами проще и это тоже отдельный вид DT. Рассмотрим «DT сети».

Допустим есть физическая сеть на устройствах Cisco. Развернули рядом стенд на Dynamips (Cisco router emulator). Все конфиги, таблицы маршрутизации и т п. копируются в реальном времени из «физика» в цифровой двойник (сеть на Dynamips).

В момент времени t+1 мы можем на стенд подать пакет и увидеть, как он отработает. Т.е. увидеть, как отработан был бы пакет в реальной сети (на устройствах Cisco) на этот момент t+1 при условии синхронизации обоих двойников (Cisco и Dynamips) на время t.

Если "по-хорошему", то копирование конфигов должно быть не «узел – узел» (напрямую), а через промежуточный архитектурный репозитарий (история, аналитика и т п.).  Плюс визуализация (и не только сетевых соединений) и т.п., т.е. полноценный разносторонний контроль, верификация, синхронизация. Раскрытие сети в обоих случаях покажет одинаковый результат.

Ограничение такого DT: производительность, надёжность и т п., но это нормально для DT (модели). В DT важна адекватность модели, а тут полная эмуляция на dynamips. Работал с Dynamips в середине 2000-х, тогда он идеально эмулировали парк Cisco. Например, делал стенд, где виртуальные машинки с dynamips соединялись через "эмулятор канала с ошибками", параметры которого задавал в Shunra (моделировал деградацию канала связи). Если в таком стенде синхронизировать как структурную составляющую (синхронизация Dynamips с PT), так и подгружать в Shunra распределение ошибок реального канала, то видимо такой стенд можно было назвать "DT типа эмулятор".  

На рис. 1 а) показаны две группы «Симуляция» и «Эмуляция». Примеры эмуляторов: Android на windows или Cisco iOS на Windows \ Linux (Dynamips). Они реально исполняют целевой процесс, но в другой среде, они могут выступать в качестве резервного контура (в принципе на них можно подать «рабочую нагрузку»).

Пример симуляторов: Формула 1 под DOS, промышленный авиа-тренажер (даже с 4D).    

7. Технологии 3D: от табуреток до мануфактур

Рассмотрение DT велось в широком диапазоне: от DT табуретки – или иного простого изделия типа «вещь», где хорошо (наглядно) «вписываются» 3D-print / 3D-scan, далее DT программы (software), DT бизнес-процесса (от workflow до более полной модели), DT промышленного \ кредитного конвейера и даже DT предприятия (офиса \ завода). 

Технологии 3D имеют большой спектр применений: «от табуреток до мануфактур». Есть не только уже «привычные технологии», которые ищутся по запросу: 3D scanner / 3D printer. Пара ссылок «Реверс-инжиниринг на производстве при помощи 3D-сканирования» и «Реверс-инжиниринг, обратное проектирование или моделирование по сканированной модели».

Промышленной разновидностью подобного может быть Manufacturing-as-a-Service (MaaS). Упрощенно «бытовой» MaaS: покрутил перед web-камерой (условно) пластиковую табуретку и на следующий день получил дубликат (физическую копию) в ближайшем пункте выдачи заказов. В придачу будет приложена ее 3D модель: Pre-Digital Twin по которой она была изготовлена. Если с помощью условно бытового 3D – сканера можно отсканировать условную табуретку, то с помощью промышленного LiDAR-сканера и технологии фотограмметрии можно получить 3D-модель целой мануфактуры «за считанные минуты».

Однако мы помним, что автономный Pre-Digital Twin – это фактически «псевдо DT» (проектное решение с возможностью «исполнения»), а для полноценного DT необходимо «продолжение» в виде динамической системы и информационного обмена между двойниками (информационная связка двойников). 

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

Такой DT стройплощадки может (видимо) даже подсказать: ты не так начал стенку кирпичную класть, нужно (по проекту) правее на 20 сантимов или "уровень" неверно выставил и т.п. 

Чем подобный пример виртуальных строй-площадок принципиально отличается от SCADA-систем? Внешне ничем: и там и там могут быть схожие информационные потоки, схожие дашборды и т.п. Однако в SCADA (АСУТП) и модель будет построена вручную и монтаж датчиков будет также произведен вручную.

Проблема «не инструментального моделирования». Модель может быть «кривая»: не соответствовать реальному объекту, быть «грубой» / не детальной, «устаревшей» / не актуальной и т.п., т.к. создана не инструментально.

Проблема «не инструментального монтажа». Допустим АСУТП / SCADA измеряет расход в многоквартирном доме (свет, воду, теплоноситель) и монтажник подключил пары проводов от датчиков (а сами датчики пусть будут без циферблата) не к тем портам контроллера (т.е. соединил с портами соседа). В этом случае, скорее всего никто не заметит этой подмены и «как бы цифровой двойник» будет выдавать «не то» и абоненты будут платить не за себя, а за соседа. 

Такой же ход рассуждений и с BIM моделью, построенной не инструментально, с наложенными на эту модель каких-либо данных, полученных в процессе эксплуатации здания. BIM модели также часто выдают за DT.

Если мы говорим про рассмотренный выше DT строй-площадки, то там (по-хорошему) вначале по данным сканирования (т.е. инструментальным методом) строится модель уже «построенного» и только потом сравнивается с эталонной (проектной документацией) и далее с графиком работ (календарным планированием). В этом случае, система сразу даст расхождение и далее или будет перенос стены «в натуре» (ломаем и строим новую стену) или изменение (акцепт несоответствия) будет отражено в исполнительной документации (фактическое исполнение проектных решений, а каждый объект строительства – уникальный), т.е. в индивидуальном эталоне (не в типовом проекте). 

В данном примере мы имеем сущности: «рукотворный» PT (незавершённое строительство), инструментальную модель (DT) «as-really-is», «рукотворную» общую – финальную «to be», которая по стадиям строительства фрагментируется на отдельные «as is» и верифицируется с «as-really-is».  

Теоретически можно любой офис «обвесить камерами» (с распознанием лиц и т.п.), которые будут распознавать все бумажные документы на всех столах всех сотрудников и определять какой документ в каком состоянии (например, заявление на отпуск: составлено \ согласовано \ утверждено \ исполнено – выплачены отпускные). По этим документам система будет распознавать этапы процесса и строить схему «работы всей компании», включая кто в какой момент и что делает и как это соотносится с «эталонной моделью» ("как было нужно", as is). Этот промер сработает и в компаниях с нулевым уровнем автоматизации бизнес-процессов (абсолютный бумажный документооборот), а что говорить о возможностях контроля процессов со стороны DT в компаниях с высоким уровнем автоматизации?

Заключение

Напомним, что четкого «checklist» для подтверждения статуса «DT» еще нет и большинство терминов по DT имеют маркетинговый характер (задача продать старое под новой этикеткой).

Поэтому на протяжении последней пятилетки наряду с ростом интереса к теме DT мы имеем в основном примеры не DT, а псевдо DT, что дискредитирует саму идею DT. Зачем назвать старое новым термином «Цифровой двойник» в угоду хайпа? 

Однако из запросов про «checklist» у ИИ уже можно «вытянуть клещами» требования про инструментальные методы создания моделей как DT (см. пункт 7 ответа ИИ).

Наряду с формулированием двух базовых необходимых, но недостаточных условий (требований) к DT (гарантированная адекватность модели и наличие синхронизации в процессе эксплуатации и собственно сам этап эксплуатации) был предложен термин Инструментальный DT. Приставка «инструментальный» определяет использование технологий, гарантирующих адекватность модели и устраняющий субъективный фактор при создании модели (DT – это модель).

Выше были показаны базовые технологии, которые могут быть применены при построении «Цифрового двойника Инструментального типа» с гарантией адекватности модели ее физическому двойнику, т.к. один «порожден» (развернут, напечатан) из другого и верифицирован средствами объективного контроля - инструментального, т.е. не субъективной оценки пусть и группой экспертов.

Классические системы \ подходы к моделированию процессов и архитектур (ARIS и т.п.) конечно же не являются базовыми для DT и не позволяют строить ни DT процессов, ни DT предприятий, т.к. это обычное «субъективное» моделирование «as is», а далеко не требуемое в DT «as-really-is». Не являются базовыми для DT и классические системы имитационного моделирования, т.к. это тоже «субъективное» моделирование», даже если к нему подключен (наложен на модель) информационных поток от реального объекта (от датчиков IoT или BAM).

Кроме того, в дополнение к принципу «as-really-is» должна быть хорошая визуализация этой модели (схемы, графики). «As-really-is» - как показано в модели, так и исполнится в реальности. Можно нарисовать «тонны схем» в Арис (включая ARIS Simulation), но после запуска Process Mining убедиться, что все нарисованное есть не что иное как макулатура, т.к. не соответствует действительности (по многим причинам). Цифры экономии через Process Mining тут (деталей не знаю, просто попалось в новостях).

Выделим инструментальные технологии «прямого проектирования» DT: 3D-печать, executable MDA/MDD (executable model в разных нотациях: UML, BPMN, проприетарные).

Технологии «обратного проектирования» DT:

а) активные: сканирование, включая, 3D-scan, раскрытие сети (LAN\WAN) и т.п.

б) пассивные: Process mining (цифровые тени и следы).

Третья технология DT – эмуляторы (например, сеть на Dynamips) с синхронизацией с «физиком», т.е. в связке с объектом эмуляции.

Однако указанные базовые технологии «из коробки» пока не обеспечивают построение DT, т.е. им необходимы дополнения. На данном этапе мы можем говорить не о цифро-двойнике какого-либо динамического изделия (табуретки в режиме эксплуатации, программе, процессе, предприятии), а только его части. Что там говорить, пока и «приличной» онтологии / метамодели предприятия еще нет.   

Для отнесения чего-либо к «классу DT» как минимум должны быть представлены следующие артефакты: схемы структур обоих двойников (в идеале модели и метамодели обоих двойников, т.к. конструктивно они разные), доказательства адекватности модели своему физическому двойнику, описание синхронизации между двумя двойниками. Без указанных подробностей заявления о создании «изделия – DT» (включая модель предприятия) предлагаю считать не обоснованными.    

Открытые вопросы

1. Хотелось бы составить список DT, у которых есть открытое и подробное описание.

2. Обычно «тайну DT» (сокрытие деталей реализации «как бы DT») «оправдывают» через NDA. Однако если у разработчика технологии «Создание Цифрового двойника компании» нет описания DT собственной компании, то к его наработкам (технологии) серьезно вряд ли можно относиться, т.к. NDA тут уже ни при чем, а испытать и продемонстрировать «мощь» своей же технологии «прямо на собственной шкуре» - самое первое, что приходит в голову. Иначе получается «Сапожник без сапог».

Какие компании разработчики или внедренцы DT имеют DT собственный компании? Конечно требуется открытое и подробное описание.

3. Полный набор инструментальных методов реализации Цифровых двойников.

4. Онтологии Цифровых двойников. Принципы и технологии построения Цифровых двойников (не рекламные проспекты, а спецификации).

Некоторые ссылки

[DT1] Digital Twin. Часть 1. Цифровой двойник vs цифровой самозванец

[WFE24] Исполняемый BPMN в Open Source Runa WFE (WfMS). Hello Calculator и немного классификации

Как СберМобайл завод оцифровал, и кому это вообще нужно

Манифест Process Mining

Process Mining. «Рентгеновская диагностика» бизнеса

Обсуждение темы двойников с ИИ (табуретка, цифровая тень, нотариальная контора \ чек-лист DT)

Modelling for and of Digital Twins

Цифровые двойники – просто (и местами вольно) о сложном, Антон Грачевников

Visual Magic строит программы по диаграммам

Исполняемая спецификация для разработки системы