Как это часто бывает, из маркетинговых или любых других соображений некоторые термины начинают использоваться как синонимы для значений, которыми изначально определялись совершенно другие сущности. В результате возникает недопонимание, когда разные стороны казалось бы говорят об одном и том же, но имеют в виду совсем разные явления. Нечто подобное стало происходить в последнее время и с термином «цифровой двойник» (digital twin) — модный термин начали применять повсюду, нередко приравнивая его к термину «симулятор». На нескольких примерах постараюсь показать, где эти термины пересекаются и где они различаются. Об этом, в том числе, я рассказывал на прошедшем недавно в МГУ форуме «Цифровизация-2019» в презентации «Особенности применения симуляторов и роботов для разработки медицинских устройств».

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

Чтобы разрешить эту «маленькую сложность», мы разрабатываем программный симулятор, который может передавать в наше ПО различные данные, имитируя сигналы реальных датчиков, которые измеряли бы параметры реальной атмосферы. Здесь мы имеем в виду именно симулятор (иногда это также называется «software-in-the-loop», SIL). Для разработки и тестирования устройства, которое отображает текущие параметры погоды, нам вполне достаточно набора данных, созданных вручную, или исторических данных, собранных различными метеостанциями в реальных условиях.

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

Вернемся к нашему примеру с разработкой метеостанций. Допустим, проанализировав результаты моделирования, мы обнаружили, что по истечении определенного периода времени лопатки турбинки, которая используется для измерения скорости ветра, деформируются вполне определенным и предсказуемым образом, что вносит искажения в результаты измерений, которые мы отправляем потребителю. Тогда мы корректируем алгоритмы ПО, чтобы с учетом деформаций наша метеостанция продолжала отправлять достоверные результаты. Если же модели покажут, что лопатки после определенного времени деформируются или даже разрушаются непредсказуемым образом, то все, что сможет сделать наше ПО, это по прошествии определенного времени добавлять к сообщению о измеренной скорости ветра флаг «недостоверный результат». Скорее всего, мы все еще сможем ориентироваться на то, что значения более сильного ветра будут отличаться от ветра более слабого, но численным значениям доверять не следует и пора бы провести техническое обслуживание метеостанции, заменив дефектный модуль.

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

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

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

Автор статьи — менеджер проектов, «Аурига».