Comments 11
Спасибо. ) Мне кажется цифровой двойник как то так выглядит ) Я его сделал пока пытался дочитать статью до определенного предела.
Почему бы не взять определение цифрового двойника а тех, кто реально их делает -
https://se.mathworks.com/discovery/digital-twin.html?s_tid=srchtitle_support_results_1_Digital+twins
Статью честно не осилил.
Но где-то в начале что-то есть про отделение "данных" от "структуры".
Для цифровых моделей между ними нет разницы . И данные перевращаются в матрицу в RAM и структура превращается в матрицу инцидентностей в RAM. И умножаются друг на друга.
Именно поэтому нейростети так легко подражают сложным моделям не имея ни малейшего представления о "структуре".
Почему бы не взять определение цифрового двойника а тех, кто реально их делает -
Цитата по ссылке:
Цифровой двойник — это цифровое представление продукта, процесса или системы, находящегося в эксплуатации или разработке. В процессе эксплуатации он отражает текущее состояние актива и включает соответствующие исторические данные; цифровые двойники используются для оценки текущего состояния актива и, что ещё важнее, для прогнозирования будущего поведения, усовершенствования систем управления или оптимизации операций. В процессе разработки цифровой двойник выступает в качестве модели будущего продукта, процесса или системы, что упрощает разработку, тестирование и валидацию.
В этом определении нет требований ни к детальности модели, ни к ее адекватности.
digital representation - это модель? Если "да", то какая? Кроме детальности и адекватности - какие еще требования к ней?
" В процессе разработки цифровой двойник ..." - это в текущей статье «Development Digital Twin».
А может всё можно было сказать проще?..
Для начала нужно определиться с определением ЦД. И пользоваться этим определением. Потому что без единого определения - упоминание ЦД это просто маркетинговый приём. Предлагаю взять определение из ISO'шного стандарта.
По сути ЦД - это короткое название определённого вида моделей, которые иначе бы надо было называть длинным, неудобопроизносимым, неудопонаписуемым и, главное, неудобочитаемым для начальства, составным термином.
ЦД работает не чудесным образом.
В силу п.3 - ЦД как модель строится под конкретную проблему. Поэтому единого требования к ЦД вне определения ЦД быть не может. Адекватность ЦД, как и любой иной модели, зависит от задачи, которую с её помощью хотят решить. И для разных задач это может быть по-разному, кому-то хватит и мониторинга хватит, а кому-то надо и прогнозировать последствия действий с реальной системой.
Итого: с любой технологией, включая ЦД, надо исходить из решаемой задачи. А не наоборот - делать модель и потом пытаться отбить затраты на её создание, пытаясь воткнуть во все щели, которые отыщутся, в надежде, что где-то да получится.
А вся маркетинговая чушь вокруг ЦД строится вокруг несоответствия ожиданий заказчиков, которые сами не понимают, что им на самом деле надо, но надеются, что ЦД решит все их проблемы чудесным образом?
ЦД ранее были? Термин достаточно свежий и есть уверенность (надежда), что в нем заложены отличия от "старых моделей". Считать, что ЦД предприятия - это просто модель, нарисованная в ARIS с наложенными на нее данными (дашбордами) из BAM - полагаю, что не верно (это и есть "вся маркетинговая чушь вокруг ЦД"). Выдача за ЦД систем типа SCADA - то же самое.
ЦД ранее были?
Из того, что ранее не наблюдалось широкого использования термина - не значит, что не было такого явления. Но для начала надо таки договориться до определения ЦД. А то когда каждый определяет его как хочет - то даже поспорить нельзя, каждый прав в своей собственной системе определений.
Термин достаточно свежий и есть уверенность (надежда), что в нем заложены отличия от "старых моделей".
Модель - настолько общий термин, что охватывает и ЦД, и то, что появится в будущем. Потому противопоставлять "ЦД" и "модели" - ну, всё равно, что говорить, что вездеход - это не транспортное средство, потому что в качестве машины мы на своём (весьма органиченном) житейском опыте привыкли видеть только то, что ездит по асфальту.
Ну, собственно, маркетинг именно на этом и играет - к "модели" все привыкли, а шильдик "ЦД" оставляет надежду на магию. Особенно в сочетании с шильдиком "ИИ".
Возможно не в тему, но выскажусь!
Задам еще один вектор "на подумать" в задаче определения и области применения цифровых двойников для промпредприятий. Для этого сначала будет кейс, потом вывод с выходом на постановку задачи для DT
Кейс
Поделюсь таким своим опытом наблюдения внедрения IT системы управления на ХХХ заводе (я не имел отношения к внедрению, я был сторонним наблюдателем): за 4 года, пока я работал с заводом, все 4 года, несмотря на огромные усилия и кампании, «запустить» IT систему не смогли((( Причина: слишком большая размерность задачи при постоянно большой изменчивости ее составляющих (количество деталей на единицу готовой продукции от 15 000 до 30 000 наименований, количество операций техпроцесса для одной детали от 10 до 50, количество единиц оборудования 1000 – 10000 единиц, количество сотрудников около 5 000 чел и т.д). Завод элементарно не мог обеспечить соответствие справочников фактическому состоянию + размерность задачи была такая, что время расчета расписаний не представляло никакой практической ценности (за время расчета гарантированно происходили изменения, которые превращали его результаты «в тыкву», т.е. требовали обязательного перерасчета).
Вывод и выход на постановку задачи для DT
Напрашивающийся вывод попытка "в лоб" (один в один) создавать цифровые двойники предприятия, начиная с определенной размерности задачи - это ОГРОМНЫЕ затраты, которые с высокой долей вероятности не окупятся в виду огромной изменчивости и необходимости скрещивания в единую аналитическую систему данных с DT и не c DT (управлением и агрегацией которых большая проблема).
Выход на постановку задачи для полезного/эффективного применения DT:
Нужен подход к снижению размерности задачи "какое минимальное количество характеристик с какого минимального количества объектов с какой максимально возможной периодичностью съема данных нужно собирать с помощью DT, чтобы собранная система позволяла организовать эффективное управление прикладным объектом (системой объектов)". Без такого решения будет гарантирован результат "Из пушки по воробьям"!
В связи с этим, обсуждение задачи DT ради DT как сферического коня в вакууме (как техническую IT задачу только), без привязки к прикладным объектам управления (особенно в случае сложной системы объектов, типа предприятие) и без решения специфической задачи размерности DT для этой сложной системы объектов - не более, чем интересное занятие с туманными перспективами. Т.е. DT - это не столько техническая или IT-задача, сколько прикладная, и постановку задачи DT нужно делать в жесткой связке с решаемой прикладной задачей и системой объектов. Например: DT для управлением надежностью оборудования - это такая то модель применения DT. DT для управления качеством операций - другая модель применения DT, хотите построить минимально работающий DT предприятия - это такой то набор объектов DT с такой то схемой агрегации данных для решения таких-то задач управления и т.п.
Нет. У меня договор о конфиденциальности, извините, но я не имею права давать информации больше, чем поделился.
Мой исходный комментарий не про проблему конкретного решения вендора (не про то, что оно слабое и т.п.), а про то, что размерность задачи имеет критическое значение, какой бы вендор не пытался ее решить. Там основные проблемы связаны не столько с дефицитом производительности (он преодолевается, производительность систем растет и это вопрос времени решения этой проблемы). Основная проблема была в том, что завод физически не успевал актуализировать многочисленные справочники (так много и так быстро происходили изменения)
Digital Twin. Часть 2. Инструментальный Цифровой двойник