Можете привести две структурные схемы: в одной, что входит в физический двойник, во второй в цифровой. Желательно максимально детально, а не система 1 и система 2.
Также хотелось бы увидеть самый простой пример DT с подробным описанием и пояснением, почему это действительно DT.
Да, по текстовому описанию получать схему BPMN. Может быть какая-то модель AI уже хорошо изучила BPMN. Получатся, что тест Тьюринга проходит, а тест BPMN еще нет.
Да, это не про встраивание AI-агентов в процесс (точнее перепроверку решений AI-агентов - как в статье), а более "широко".
Для внесения корректировок в BPM-системе необходимо не только обновить BPMN-схему, но и настроить саму систему, включая программирование логики процессов и интеграции.
Существует миф, что «нарисовал картинку – схему процесса в BPMN и получил готовое приложение». Совсем нет, потому что, BPMN – это не про бизнес-процессы, а только про их пусть и важную, но только часть - про workflow (WF). Поэтому их и называть нужно не BPMS, а WFE (WF-engine) \ WFES (WF execution system).
Впрочем, некоторые так и называют свои системы, например, Runa WFE.
Чтобы исполняемый BPMN стал про бизнес-процессы, в него нужно добавить, как минимум docflow (dataflow modeling).
Когда появится нотация, которая позволит без программиста создавать по схеме процесса приложение, то ее и следует будет назвать «настоящей BPMN». Простейшие случаи, типа Hello Calculator не рассматриваем.
Пока, что исполняемая нотация BPMN недостаточно для того чтобы формализовать в код бизнес-процесс, она может только workflow, а все останове необходимое, прежде всего модель данных и docflow (номенклатура документов, их свойства, включая набор состояний документов и т.п.), программисты дописывают вручную или используются встроенные конструкторы, которые к BPMN отношения не имеют.
BPM-системы — это не про автоматизацию
Точный тезис. BPM-системы - они только про моделирование, но про полноценное, включая docflow и др. Изначально (начало 2000-х) BPM-системами (BPMS) назывались системы в которых вообще не было исполняемых движков Execution Environment: ARIS, BPWin и т.п. Это были системы моделирования бизнес-процессов (не только workflow) и произошел их ребрендинг из CASE систем в «BPM-системы». Только потом Гартнер «отжал» у них (ARIS и т.п.) бренд «BPMS» в пользу исполняемых систем, тем самым всех запутав. Изначально «управление» (management) в контексте BPMS \ BPMT (tool) не было синонимом «исполнение» (наличие WFE).
BPM-системы постепенно переходят к low-code платформам.
low-code – это инструменты, которые позволяют минимизировать программный код визуальными средствами. Это либо визуальные конструкторы, либо редакторы диаграммам, где посредством графического пользовательского интерфейса (GUI) создаются блоки, которые потом генерируются в код.
jQuery и подобные библиотеки, также сокращающие код – это не low-code, а любая BPMN WFE – это всегда low-code, т.к. уже замена части кода картинкой говорит о «low».
Dataexpress и VBA – в части создания пользовательского интерфейса – это тоже low code.
LCNC (low-code & no-code) можно поделить на три группы: BPMN-LCNC, noBPMN-LCNC и конструкторы не на процессных диаграммах:
LCNC - это «сборная солянка» любых систем «быстрой разработки», где применяется хоть какой-то визуальный конструктор, причем не обязательно графический (графический моделер). Во многих случаях этот конструктор и есть BPMN (low-code BPMN), т.е. можно разделить на две основные группы: BPMN-LCNC (Camunda etc) и noBPMN-LCNC (Pega etc).
Сегодня почти каждая система имеет какой-либо конструктор - если не для разработки, то хотя бы для конфигурирования, например, СЭД Директум 5 - для конфигурирования маршрутов задач. Обычно подобное также относят к LCNC.
Есть еще странное деление «на две большие группы: процессные движки (BPMN) и полноценные системы (BPMS)». Странность в использовании термина BPMS: получается, что бренд BPMS в очередной раз хотят "отжать", но уже у систем Camunda \ jBPM в пользу других.
Визуальное программирование - как реализация концепта «программирования без программирования» - в идеальном случае, это no-code.
Совсем простые (детские) примеры: Scratch и Lego Mindstorms EV3. Scratch – язык программирования - представляет собой визуальную среду, в которой ПО пишется с помощью блоков, см. wiki.
Модель табуретки, которая сможет предсказать нам возможное разрушение, деформацию или сохранение целостности табуретки в зависимости от того, кто на нее сядет.
Попробую угадать. В такой концепции DT являются: автопилот самолета и автомобиля, да и просто штатный бортовой комп, который смотрит динамику движения и прогнозирует запас топлива (километраж) и ещё кучу параметров.
Так и не понял: где происходит отчуждение одного двойника от другого: где "горсть" датчиков одного двойника, где второго и т.п. Межевание границ двойников и структуры обоих двойников не раскрыты у вас и во второй части.
Т.к. пока я не понимаю, что является цифровым двойником в вашем понимании.
В своей второй части расскажу про концепт Инструментальный DT. Это такой DT, у которого модель гарантированно соответствует своему физическому двойнику. В одном случае, физический двойник полностью автоматически (инструментально) создан из модели, а в другом - сама модель опять же инструментальными средствами создана из физического образа. Но эта статья (часть) пока в очереди, как напишу - пингану.
В конце этой статьи в "Продолжение следует" добавьте ссылку на вторую часть.
Вынужден повторяться: https://habr.com/ru/companies/sberbank/articles/890926/#comment_28048878 "Можете показать две структурные схемы физического и цифрового двойника?" и подобные вопросы. Может быть укрупненную спецификацию DT (лучше обоих двойников), схему деления, ТУ и т.п. Что входит в состав DT? SCADA в обоих частях присутствует (новая типа в DT, а старая в физическом)? Часть датчиков относите к физическому двойнику, а другую часть к DT?
Но на практике заказчик потому и заказывает у нас цифрового двойника, чтобы разобраться, что происходит на его производстве с точностью до грамма, секунды или любой другой метрики.
Рекорд наших задач — цифровизировать каменную дробилку 1932
вроде это ранее просто "автоматизация" называли.
В цехе есть SCADA, но дальше цеха она никуда не уходит.
Может быть вы просто усовершенствовали существующую SCADA (MES), назвав это DT? Эту мысль подтверждают 1 и остальные пункты :
Вся информация с каждого датчика анализируется, агрегируется и в конечном счёте уходит в ERP и BI. Пусть не в чистом виде, но каждая метрика вносит свой вклад.
Проект может и хороший, но видимо не про DT, во всяком случае, я не увидел DT, а лишь дополнительную систему мониторинга и расчета (судя по описанию к тому же и несложного) по ним плановых значений. Видимо нужна третья часть. Где гарантия, что модели, которые вы "зашили" в свое ПО, адекватны реальным процессам?
С таким подходом любой проект IoT можно выдать за DT. Про AIoT расскажите (что делает на заводе \ в проекте), раз упомянули (SberMobile AIoT). А самим "верстать нужные им дашборды" - это вроде как давно уже норма (если что, см. Excel). Бизнес-процессы завода как-то формализованы в этом "как бы DT"? Если да, то в какой нотации?
И в название статьи добавьте что-то (например, как у меня), чтобы не было одноименно с первой часть.
Эта IBM AT меня тогда удивила, что 8086, а уже с VGA.
"IBM AT" - как бы понятнее (хоть и не точно), чем IBM PS/2 Model 30 (8530-021) 1987 года. Когда мне его принесли была уже эпоха Pentium, но переткнув свой штатный VGA монитор в этот 8086 увидеть картинку была неожиданность.
под цифровым двойником понимают оцифрованную копию производства в режиме realtime
На примере офиса (аналогично можно переделать к заводу), упрощенно.
В офисе висят хорошие камеры. Сотрудник написал служебную записку (СЗ) на бумаге, отнес подписать начальнику, тот подписал и передал в канцелярию и т.д. по процессу.
DT на основе распознания действий, снятых видеокамерой, в режиме realtime строит модель (оцифрованную копию), включая все действия персонала, фиксируется смена состояния документа (СЗ в состоянии «на подпись», СЗ в состоянии «подписана» и т.п.), время смены состояния (момент подписания, регистрации в канцелярии) и т.п. Так понимается «оцифрованная копия офисного производства»?
При СЭД это куда проще (внутри СЭД уже все оцифровано), но DT в общем случае может охватывать как автоматизированный, так и неавтоматизированный контур.
Конечно дождемся второй части, как вашей, так и моей (моя будет не скоро, см. проект в профиле, хотя черновик есть).
Однако если есть вариант (фактура и желание) подискутировать по "Hello DT", то предлагайте совсем простой вариант DT. Мы его обсудим. Чем проще, тем лучше, например, "DT табуретки" или "DT процесса приготовления борща". Именно на совсем простых примерах и нужно проверять гипотезы и определения. Hello World - понятен (и стар), поэтому его образ переложил в Hello Calculator для исполняемых BPMN.
Почему бы не развить тему "Hello DT" на примере примитивно-примитивного DT?
И только потом рассматривать более сложные DT, типа цифровых двойников заводов / компаний и далее: цифровых двойников министерств, государств, вселенных и т.п.
А вот двойник уже может сэмулировать процесс. Что будет, если на вход подали 2M сырья, при том, что скорость конвеера стала 1,5V? Чему будет равен N? А насколько быстрее потребуется ТО конвеера?
Это называется имитационное моделирование, а не DT.
Будем ждать продолжения (разъяснения), но если вдруг найдется схожий аналог, в котором будет показано "где заканчивается первый двойник (физический) и начинается второй (DT)" - дайте ссылочку. Чем проще аналог - тем лучше, т.к. отчетливее будет видно это размежевание.
Полученного аватара нужно обработать и представить в полезном и понятном виде. Например, в виде дашборда, графика, системы предупреждения о критических отклонениях или другом виде.
Состав физического двойника:
По идее, сигнал с контроллера должен уходить в систему управления и сбора данных (SCADA). А информация из SCADA потом уйдёт в инфосистему цехового уровня (MES) и дальше в систему управления всем предприятием (ERP).
Обычно SCADA \ MES уже умеет "обработать и представить в полезном и понятном виде. Например, в виде дашборда, графика, системы предупреждения о критических отклонениях или другом виде." При чем тут тогда аватар (DT)? Часто SCADA \ MES выдают за DT. Тут не так?
Можете показать две структурные схемы физического и цифрового двойника? «Прежде, чем объединяться, и для того, чтобы объединиться, мы должны сначала решительно и определенно размежеваться» - покажите размежевание обоих сущностей физика - двойники и цифро - двойника. Также см. Digital Twin. Цифровой двойник vs цифровой самозванец
Можете привести две структурные схемы: в одной, что входит в физический двойник, во второй в цифровой. Желательно максимально детально, а не система 1 и система 2.
Также хотелось бы увидеть самый простой пример DT с подробным описанием и пояснением, почему это действительно DT.
Да, по текстовому описанию получать схему BPMN. Может быть какая-то модель AI уже хорошо изучила BPMN. Получатся, что тест Тьюринга проходит, а тест BPMN еще нет.
Да, это не про встраивание AI-агентов в процесс (точнее перепроверку решений AI-агентов - как в статье), а более "широко".
Правильно я понимаю, что вначале нужно определить Реестр данных Банка (в рамках Data Quality)?
Как это сделать (пошагово) в соответствии с требованиями ЦБ?
Про AI + BPMN:
По какой ссылке я могу зайти ввести туда текст с описанием бизнес-процесса и получить соответствующую схему (картинкой) в BPMN.
Еще лучше получить соответствующее описанию приложение (исполняемый BPMN + много кода, все равно называемое low-code).
Существует миф, что «нарисовал картинку – схему процесса в BPMN и получил готовое приложение». Совсем нет, потому что, BPMN – это не про бизнес-процессы, а только про их пусть и важную, но только часть - про workflow (WF). Поэтому их и называть нужно не BPMS, а WFE (WF-engine) \ WFES (WF execution system).
Впрочем, некоторые так и называют свои системы, например, Runa WFE.
Чтобы исполняемый BPMN стал про бизнес-процессы, в него нужно добавить, как минимум docflow (dataflow modeling).
Когда появится нотация, которая позволит без программиста создавать по схеме процесса приложение, то ее и следует будет назвать «настоящей BPMN». Простейшие случаи, типа Hello Calculator не рассматриваем.
Пока, что исполняемая нотация BPMN недостаточно для того чтобы формализовать в код бизнес-процесс, она может только workflow, а все останове необходимое, прежде всего модель данных и docflow (номенклатура документов, их свойства, включая набор состояний документов и т.п.), программисты дописывают вручную или используются встроенные конструкторы, которые к BPMN отношения не имеют.
Точный тезис. BPM-системы - они только про моделирование, но про полноценное, включая docflow и др. Изначально (начало 2000-х) BPM-системами (BPMS) назывались системы в которых вообще не было исполняемых движков Execution Environment: ARIS, BPWin и т.п. Это были системы моделирования бизнес-процессов (не только workflow) и произошел их ребрендинг из CASE систем в «BPM-системы». Только потом Гартнер «отжал» у них (ARIS и т.п.) бренд «BPMS» в пользу исполняемых систем, тем самым всех запутав. Изначально «управление» (management) в контексте BPMS \ BPMT (tool) не было синонимом «исполнение» (наличие WFE).
low-code – это инструменты, которые позволяют минимизировать программный код визуальными средствами. Это либо визуальные конструкторы, либо редакторы диаграммам, где посредством графического пользовательского интерфейса (GUI) создаются блоки, которые потом генерируются в код.
jQuery и подобные библиотеки, также сокращающие код – это не low-code, а любая BPMN WFE – это всегда low-code, т.к. уже замена части кода картинкой говорит о «low».
В простых случаях, как Hello Calculator речь идет о no-code.
Dataexpress и VBA – в части создания пользовательского интерфейса – это тоже low code.
LCNC (low-code & no-code) можно поделить на три группы: BPMN-LCNC, noBPMN-LCNC и конструкторы не на процессных диаграммах:
LCNC - это «сборная солянка» любых систем «быстрой разработки», где применяется хоть какой-то визуальный конструктор, причем не обязательно графический (графический моделер). Во многих случаях этот конструктор и есть BPMN (low-code BPMN), т.е. можно разделить на две основные группы: BPMN-LCNC (Camunda etc) и noBPMN-LCNC (Pega etc).
Сегодня почти каждая система имеет какой-либо конструктор - если не для разработки, то хотя бы для конфигурирования, например, СЭД Директум 5 - для конфигурирования маршрутов задач. Обычно подобное также относят к LCNC.
Есть еще странное деление «на две большие группы: процессные движки (BPMN) и полноценные системы (BPMS)». Странность в использовании термина BPMS: получается, что бренд BPMS в очередной раз хотят "отжать", но уже у систем Camunda \ jBPM в пользу других.
Визуальное программирование - как реализация концепта «программирования без программирования» - в идеальном случае, это no-code.
Совсем простые (детские) примеры: Scratch и Lego Mindstorms EV3. Scratch – язык программирования - представляет собой визуальную среду, в которой ПО пишется с помощью блоков, см. wiki.
Когда разработают настоящего двойника, то обязательно найдется, кто скажет: Деньги не имеют... значения. "Я хочу DT ..."
Попробую угадать. В такой концепции DT являются: автопилот самолета и автомобиля, да и просто штатный бортовой комп, который смотрит динамику движения и прогнозирует запас топлива (километраж) и ещё кучу параметров.
Так и не понял: где происходит отчуждение одного двойника от другого: где "горсть" датчиков одного двойника, где второго и т.п. Межевание границ двойников и структуры обоих двойников не раскрыты у вас и во второй части.
В своей второй части расскажу про концепт Инструментальный DT. Это такой DT, у которого модель гарантированно соответствует своему физическому двойнику. В одном случае, физический двойник полностью автоматически (инструментально) создан из модели, а в другом - сама модель опять же инструментальными средствами создана из физического образа. Но эта статья (часть) пока в очереди, как напишу - пингану.
В конце этой статьи в "Продолжение следует" добавьте ссылку на вторую часть.
Эти датчика войдут в состав DT? Какой в целом будет состав DT?
Вынужден повторяться:
https://habr.com/ru/companies/sberbank/articles/890926/#comment_28048878
"Можете показать две структурные схемы физического и цифрового двойника?" и подобные вопросы. Может быть укрупненную спецификацию DT (лучше обоих двойников), схему деления, ТУ и т.п. Что входит в состав DT? SCADA в обоих частях присутствует (новая типа в DT, а старая в физическом)? Часть датчиков относите к физическому двойнику, а другую часть к DT?
Может быть это все же Digital Impostors:
вроде это ранее просто "автоматизация" называли.
Может быть вы просто усовершенствовали существующую SCADA (MES), назвав это DT? Эту мысль подтверждают 1 и остальные пункты :
Проект может и хороший, но видимо не про DT, во всяком случае, я не увидел DT, а лишь дополнительную систему мониторинга и расчета (судя по описанию к тому же и несложного) по ним плановых значений. Видимо нужна третья часть. Где гарантия, что модели, которые вы "зашили" в свое ПО, адекватны реальным процессам?
С таким подходом любой проект IoT можно выдать за DT. Про AIoT расскажите (что делает на заводе \ в проекте), раз упомянули (SberMobile AIoT). А самим "верстать нужные им дашборды" - это вроде как давно уже норма (если что, см. Excel). Бизнес-процессы завода как-то формализованы в этом "как бы DT"? Если да, то в какой нотации?
И в название статьи добавьте что-то (например, как у меня), чтобы не было одноименно с первой часть.
"IBM AT" - как бы понятнее (хоть и не точно), чем IBM PS/2 Model 30 (8530-021) 1987 года. Когда мне его принесли была уже эпоха Pentium, но переткнув свой штатный VGA монитор в этот 8086 увидеть картинку была неожиданность.
Стоимость в нашем случае - совсем не при чем.
Так какие варианты реализации DT табуретки? Какие инструменты реализации? Какие будут входы и выходы у этого DT?
Все, что Вами указано, включая тензодатчики (как и вся SCADA на заводе, MES и т.п.), - это элементы физического двойника.
По аналогии с вашим заводом, как можно реализовать DT Табуретки?
Когда-нибудь подобное научатся формализовывать на языке знаний (Linked Data), см. Semantic BPM \ Semantic EA.
Живая сталь (хороший добрый фильм для совместного просмотра с подростком), а есть еще подобные?
Может быть есть какие-то устройства для BPM, типа Моделирование с помощью стола Metasonic Touch, но с управлением жестами?
На примере офиса (аналогично можно переделать к заводу), упрощенно.
В офисе висят хорошие камеры. Сотрудник написал служебную записку (СЗ) на бумаге, отнес подписать начальнику, тот подписал и передал в канцелярию и т.д. по процессу.
DT на основе распознания действий, снятых видеокамерой, в режиме realtime строит модель (оцифрованную копию), включая все действия персонала, фиксируется смена состояния документа (СЗ в состоянии «на подпись», СЗ в состоянии «подписана» и т.п.), время смены состояния (момент подписания, регистрации в канцелярии) и т.п. Так понимается «оцифрованная копия офисного производства»?
При СЭД это куда проще (внутри СЭД уже все оцифровано), но DT в общем случае может охватывать как автоматизированный, так и неавтоматизированный контур.
Конечно дождемся второй части, как вашей, так и моей (моя будет не скоро, см. проект в профиле, хотя черновик есть).
Однако если есть вариант (фактура и желание) подискутировать по "Hello DT", то предлагайте совсем простой вариант DT. Мы его обсудим. Чем проще, тем лучше, например, "DT табуретки" или "DT процесса приготовления борща". Именно на совсем простых примерах и нужно проверять гипотезы и определения. Hello World - понятен (и стар), поэтому его образ переложил в Hello Calculator для исполняемых BPMN.
Почему бы не развить тему "Hello DT" на примере примитивно-примитивного DT?
И только потом рассматривать более сложные DT, типа цифровых двойников заводов / компаний и далее: цифровых двойников министерств, государств, вселенных и т.п.
Это называется имитационное моделирование, а не DT.
Будем ждать продолжения (разъяснения), но если вдруг найдется схожий аналог, в котором будет показано "где заканчивается первый двойник (физический) и начинается второй (DT)" - дайте ссылочку. Чем проще аналог - тем лучше, т.к. отчетливее будет видно это размежевание.
Состав физического двойника:
Обычно SCADA \ MES уже умеет "обработать и представить в полезном и понятном виде. Например, в виде дашборда, графика, системы предупреждения о критических отклонениях или другом виде."
При чем тут тогда аватар (DT)? Часто SCADA \ MES выдают за DT. Тут не так?
Можете показать две структурные схемы физического и цифрового двойника?
«Прежде, чем объединяться, и для того, чтобы объединиться, мы должны сначала решительно и определенно размежеваться» - покажите размежевание обоих сущностей физика - двойники и цифро - двойника.
Также см. Digital Twin. Цифровой двойник vs цифровой самозванец
коллекция ссылок BPMN \ YAWL