Digital Twin. Часть 2. Инструментальный Цифровой двойник

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

В первой части [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,