January 4th, 2021

2019

Цифровые двойники: физика ведёт математику, математика ведёт компьютерную науку

Понятие цифрового двойника
Цифровые двойники/digital twin -- информационные/цифровые модели aka виртуальные системы для киберфизических систем, существующие на всём протяжении жизненного цикла, особенно включая эксплуатацию. Их идея появилась в рамках концепции систем PLM (product lifecycle management systems), хотя и без названия "цифровой двойник". А началось это всё с именно "двойником", а не PLM с физического "двойника" космического корабля в NASA (когда один корабль летел -- эксплуатировался, а на все действия штаба отрабатывались на его находящейся на земле физической копии). Так что "цифровой двойник" -- это примерно то же, что "PLM с акцентом на эксплуатацию".

PLM системы, как оказалось на практике, а не в академических работах про "как должно быть", не использовались даже на стадиях изготовления и проверки, и уж тем более на стадии эксплуатации. На этих стадиях работали совсем другие системы: для изготовления/строительства это были обычно разные системы операционного менеджмента (чаще всего проектного управления) с использованием 3D моделей, например, Synchro или Navisworks, а на стадии эксплуатации это были AMS (asset management system), например, Maximo. Произносились хорошие слова типа "сначала нужно построить виртуальную атомную станцию в компьютере, а уже после успеха в этом -- настоящую физическую станцию". Но это было про "построить", а до эксплуатации дело не доходило, в системной инженерии очень медленно мышление с опорой на системное моделирование выходило на полный жизненный цикл системы "от замысла до вывода из эксплуатации", а не короткий жизненный цикл проекта разработки/проектирования, иногда даже без включения стадии изготовления (это же мог быть уже другой проект, зачем о нём беспокоиться?!). Первым инженерным стандартом с требованием учёта полного жизненного цикла стал ISO 15288:2003, и даже к V-диаграмме хвостик эксплуатации (так, что она стала похожа на √¯¯-диаграмму) пририсовали относительно недавно.

Системные инженеры всегда удивлялись, что когда они приходили к owners/operators (эксплуатационщикам) с системными моделями целевой системы в использованной на стадии проектирования PLM (даже с поправками as built, сделанными в модели), то на эксплуатации их никто не ждал с распростёртыми объятиями. Ибо у эксплуатационщиков были совсем другие нерешённые задачи, и модель системы в PLM плохо подходила для решения этих задач -- проблема была не в нахождении расчётных параметров, а в понимании реально измеренных параметров системы. Но потихоньку ситуация изменилась, и появился термин цифрового двойника, указывающий на специфику моделирования именно на стадии эксплуатации. А через некоторое время появились и специализированные системы, уже отличающиеся от чистого asset management, и нацеленные на системное моделирование на стадии эксплуатации (типа https://venturebeat.com/2020/12/08/microsoft-launches-azure-digital-twins-in-general-availability/).

Концепт цифрового двойника как используемой на стадии эксплуатации виртуальной мультимодели стремительно приживается в инженерии, образовании, медицине, градостроении, и далее везде. Но мы пройдём уже знакомым путём системной инженерии, просто продолжая линию рассуждений о PLM-системах в их развитии до охвата и стадии эксплуатации тоже. "Знакомый путь" -- это тот же путь, который мы проходили, беря понятия системного мышления не из менеджмента или биологии, а из системной инженерии. Опыт показывает, что тщательно проработанный системными инженерами набор понятий учитывает и системное мышление, а ещё опирается на физическую реальность и естественные/экспериментальные науки (везде, где это можно), и избегает художественных описаний выдуманного мира, каковые описания нередко случаются у не-инженеров. Так, в PLM-системах речь идёт не просто о какой-то мультимодели (какой-то набор множества связанных моделей, и мы даже не знаем, каких), но о системной модели (моделирование ведётся обязательно на нескольких системных уровнях, обязательно включает и функциональное моделирование "мультифизики", и конструктивное с выходом на BOM/bill of materials, и компоновку/размещение с выходом на 3D модели -- иначе это не системное моделирование, и его недостаточно для инженерной работы). И да, это модели инженерии-в-большом (то есть поддержка коллективных проектов, подробней см. текст 2010 https://ailev.livejournal.com/851977.html и выход на онтологическую инженерию-в-большом в тексте 2018 https://ailev.livejournal.com/1447922.html).

Эти инженерные цифровые двойники, наследующие все наработки по линии развития PLM-систем, представляются как кибер-части киберфизической двойни/cyber-physical twins (физический двойник и цифровой двойник неразрывно связаны в "двойню"), где обязательно присутствуют:
-- физическая сущность (cyber-physical system/physical entity) в её окружении. Двигатель или целый самолёт, станок или целый завод -- эти чаще всего. Это product в product life cycle management systems.
-- цифровая сущность (digital entity), работающая имитационная модель физической сущности и её окружения. Это программа в физическом вычислителе, а не просто описание модели, код модели. Помним, что модель исполнима -- только иногда её исполняет/интерпретирует компьютер, а иногда смотрящий на описание модели человек.
-- цифровые siblings/братья/сёстры как модели для сценариев what if (то есть они не отражают актуальную физическую сущность!), что входит в их состав нужно обсуждать отдельно. Тут без обсуждения причинного вывода и контрфактуальности не обойдёшься (https://ailev.livejournal.com/1435703.html).
-- база данных с объединённой информацией от датчиков физической сущности и выходов имитационной модели, "исторические данные". Выделена отдельно, чтобы подчеркнуть пассивную природу "данных модели" (данные одни, алгоритмы обработки разные)
-- различные сервисы, работающие над базой данных и всем остальным (аналитика, презентации, включая VR для рассматривания цифрового двойника в его мире). Это и есть алгоритмы, работающие над данными, причём упор не на алгоритмы, делающие вычисления цифровой сущности.
-- соединения (работают в обе стороны) между всеми сущностями. В том числе "интеграция данных жизненного цикла" сюда (в том числе алгоритмическое обеспечение соединений, типа поддержания соответствия между моделью и физической системой путём коррекции как параметров и структуры модели, так и состояния физической системы).

Вот картинка из https://booksc.org/book/70499816/7da9d3 для любящих объяснения "на пальцах" (хотя в картинке и нет siblings):


Физическое моделирование как главное в цифровых двойниках
Центральная дисциплина в digital twin -- физическое моделирование динамической (меняющейся во времени) системы, это хорошо видно в самых разных обзорах (вот тут их несколько, https://yadi.sk/d/yzpBuICd0YJevA). Зачем вообще моделировать физического двойника (в оригинальных работах используют слово twinning -- "задваивать")? Для его оптимизации: максимизации достижения предпочтений в concerns качества (ilities, список из работы https://yadi.sk/i/SDK1wRcUg7aDjA -- хоть и не совсем ортогональный, все эти dependability и availability, существенно пересекающиеся в их описаниях):


Традиционно в PLM выделяли следующие виды моделей, и все они остаются актуальными для цифровых двойников:
-- 3D-модель (формы, shapes), к которой привязываются все остальные модели
-- физическая модель (обычно трёхмерные расчёты: прочности прежде всего, деформации, теплопроводности и теплостойкости и т.д.)
-- функциональное моделирование ("одномерные": мощность мотора или генератора, производительность станка и т.д.)
-- логические модели (правила, ограничения и т.д. -- прежде всего тут находятся правила как выходы одних моделей маршрутизировать ко входам других моделей, чтобы получилась мегамодель, отвечающая на вопросы. Интеграция данных жизненного цикла, онтологии, системность и многомасштабность -- тут).

Дальше вся дискуссия про digital twins оказывается дискуссией по основным проблемам инженерного моделирования: 3D моделирования (и инструментарий тут -- CAD), 3D физика (и инструментарий тут какой-нибудь ANSYS), и "одномерные модели".

Плюс вопросы обеспечения соответствия изменений физической системы и её модели в реальном времени -- это добавляется по сравнению с "просто системным моделированием, как в PLM". Но для обсуждения этих вопросов, специфичных именно для digital twins есть огромные заделы (типа data assimilation -- подстройка моделей погоды под актуальные данные для получения прогноза, https://en.wikipedia.org/wiki/Data_assimilation. Методы оказались там вполне подходящие для подстройки необязательно моделей погоды, но и более-менее произвольных моделей. И таких подходов к ассимиляции/assimilation есть множество, типичная работа тут "Continuous calibration of a digital twin: comparison of particle filter and Bayesian calibration approaches", https://arxiv.org/abs/2011.09810. Assimilation of continuously streamed monitored data is an essential component of a digital twin; the assimilated data are used to ensure the digital twin is a true representation of the monitored system. One way this is achieved is by calibration of simulation models, whether data-derived or physics-based, or a combination of both. Traditional manual calibration is not possible in this context hence new methods are required for continuous calibration.

Но обратимся хотя бы к классике инженерного моделирования, даже не выходящего в специфику ассимиляции как согласования модели и её актуального состояния. Какие там были продвижения? Инженеры же давно делали на стадии проектирования какие-то модели системы и её окружения, задолго до того, как эти модели начали использовать во время эксплуатации и они были обозваны "цифровыми двойниками".

Прежде всего инженеры в ходе проектирования обсчитывали принципиальные и технологические схемы, иногда называя это одноразмерным/1D моделированием, чтобы противопоставить трёхмерному прочностному и тепловому моделированию -- речь-то идёт о функциональных описаниях, и тут у математиков, системных инженеров, программистов и всех остальных терминология существенно различается. Это как раз наша задача ввести какой-то общий язык описания этого моделирования и этих вычислений, для чего и копаем digital twins в порядке обсуждения вычислительного мышления ("Вычислительное мышление, декабрь 2020: думаем о современных digital twins", декабрь 2020 -- https://ailev.livejournal.com/1546514.html).

Computer science в поддержку моделирования: хитрая физика ведёт к хитрой математике, которая ведёт к хитрым языкам, которые ведут к хитрым компиляторам
Традиционно инженеры пользовались MatLab (более удобен для вычислительных задач, чем Фортран) и SimuLink для создания имитационных моделей, программные среды для вычислений с ODE (odinary differential equations in state space form -- дифференциальные уравнения для пространства состояний входов и выходов). Это стало мейнстримом, но оказалось, что сопровождать модели в такой форме невозможно: для типовых случаев нельзя сделать библиотеки отдельных функциональных элементов, которые присутствуют в системе, и приходится каждый раз понимать, куда и как вписать очередное уточнение модели, или куда и как вписать очередное изменение модели.

Потому моделированию в ODE было противопоставлено акаузальное моделирование/acausal modeling с использованием DAE (differential algebraic equations) с алгебраическими переменными, которым a priori не могло быть придано никакого входного или выходного статуса -- порядок вычислений не мог быть предсказан, ибо непонятно заранее, где у какого-то резистора вход, а где выход в составе модели.

Но как же проходит такой трюк с переходом от ODE к DAE? А вот так: разные уравнения собираются в большую систему из сотен, или даже тысяч (а в последнее время речь идёт и о миллионах) дифференциальных уравнений, и дальше решением этой огромной системы уравнений занимается компьютер (или даже суперкомпьютер, если система реально большая). Вот сравните удобство для инженеров моделирования электрического мотора с учётом инерции его вращения при представлении модели в DAE и ODE формах (https://www.researchgate.net/publication/336846217_Multi-Mode_DAE_Models_-_Challenges_Theory_and_Implementation):

This should not come as a surprise, as the first principles of physics naturally lead to considering acausal models such as the one in Fig. 1-left. Consider, for example, the case of electric circuits. So-called circuit laws such as Kirchhoff laws, are naturally expressed as balance equations: the algebraic sum of currents in a network of conductors meeting at a point is zero; or, the sum of all the voltages around a loop is equal to zero. Similarly, some components (such as, e.g., resistors or capacitors) come with no input/output prespecified orientation. A same circuit can be assigned different input/output status for its variables, depending on which ones are declared as sources. The same situation arises in mechanics or in thermodynamics. И кроме того, Adding one more physical component is straightforward in the schematic, whereas it may need a complete redesign in the block diagram.

И в итоге были предложены специальные акаузальные (не требующие учёта порядка влияния друг на друга элементов через входы и выходы) языки программирования и вычислительные среды для них. Компания MathWorks к SimuLink с его ODE добавила SimScape с DAE, компания Siemens предлагает Amesim, но де-факто стандартом и экспериментальной средой для отработки новых идей стал язык акаузального имитационного моделирования мультифизики Modelica (https://modelica.org/), для которого было разработано полдюжины компиляторов самыми разными фирмами и университетами.

Modelica с годами распухала: кроме мультифизики в него был добавлен аппарат моделирования машины состояний, и стало возможным выражать на нём и логику управления (кибер-часть).

А поскольку разнородных средств физического/имитационного моделирования оказалось очень много, для объединения самых разных моделей на уровне обмена данных между их входами и выходами был предложен стандарт FMI (functional mock-up interface, https://fmi-standard.org/ -- поддерживается более чем 150 программными инструментами для моделирования).

Но и DAE/acausal моделирование оказалось с проблемами. Главная проблема тут -- невозможность использования Multi-Mode DAE Models (mDAE). "Multi-mode" -- это моделирование режимов, связанных с разными структурами одной и той же системы. Если у вас летит ракета с тремя ступенями, потом с двумя, потом с одной ступенью -- моделировать это нужно по-разному, это же будут лететь совсем разные ракеты, у которых только название общее, а физика совсем разная! Если у вас моделируется атомный реактор в ходе его нормальной работы, то там одна физическая модель. А если он уже начал плавиться -- то моделировать его плавление нужно по-другому, прошлая модель реактора не будет работать. Это явление носит разные имена, Multi-mode DAE models только одно из них, в математике и физике используют и другие, например, VSS (variable structure system, https://en.wikipedia.org/wiki/Variable_structure_system -- и они тоже имеют много разных подвариантов, "частных случаев"). Есть и другие имена, разные группы исследователей приходят к этой проблеме учёта изменения структуры модели вслед за структурой моделируемой физической системы в разных исследовательских ситуациях и подчёркивают в имени разные аспекты проблемы. Математика mDAE хитра, и языки акаузального физического моделирования и их компиляторы должны учитывать эту хитрость математики, иначе результаты моделирования будут кривые. Вот одна из работ 2020 года, проясняющая трудности: The Mathematical Foundations of Physical Systems Modeling Languages, https://arxiv.org/abs/2008.05166. Трудности там демонстрируются на вот таком простом примере, с которым не справляются нынешние компиляторы Modelica, и дело там не только в computer science (плохом языке моделирования и плохом его компиляторе), но и в математической-физической стороне вопроса:


После того, как разобрались с физикой и описывающей её математикой, подключается computer science, ибо нужно теперь создать язык с нужной для этой математики операционной семантикой и (оптимизирующий!) компилятор для него. Это оказывается в случае mDAE не так легко, ибо уже не хватает уровня продвинутости человечества в computer science. Исследования (computer science) и разработки (software engineering) для акаузального мультифизического моделирования идут по вот этим основным линиям:
-- реализация mDAE DSL для хорошего языка вычислительной математики, а именно Modelica в Julia (я предположил такое развитие событий в 2015 и дал языку имя Mojulica, http://ailev.livejournal.com/1168256.html, но уже в 2017 году актуальная реализация появилась и по тому же принципу получила более короткое имя Modia, я написал тогда небольшой обзор https://ailev.livejournal.com/1366789.html -- важно было, что для этого пришлось чуть-чуть доработать и сам язык Julia, и способ моделирования при помощи DSL в этом языке -- появился макрос @model). Эта линия продолжается, и наиболее актуальное описание происходящего -- работа https://www.researchgate.net/publication/336846217_Multi-Mode_DAE_Models_-_Challenges_Theory_and_Implementation.
-- реализация расширенного до уровня mDAE компилятора Modelica прямо на Julia (просто чтобы сохранить legacy: сохранить стандарт на язык, в котором уже наработано некоторое количество физических моделей), это вот тут: https://www.researchgate.net/publication/345243619_Towards_an_Open-Source_Modelica_Compiler_in_Julia. Пишем на Modelica, но внутри работает Julia (и если что не так, или нужно подкрутить солверы дифференциальных уравнений -- придётся работать на двух языках).
-- множество независимых инструментов для самых разных языков акаузального mDAE-моделирования, в том числе примером тут служит написанный на OCaml софт IsamDAE (https://team.inria.fr/modeliscale/isamdae-an-implicit-structural-analysis-tool-for-multimode-dae-systems/), именно его разрабатывали авторы анализа The Mathematical Foundations of Physical Systems Modeling Languages, https://arxiv.org/abs/2008.05166.

В какой-то мере этот тренд с использованием "языка" mDAE вместо ODE для физического моделирования похож на создание разных языков программирования для решения expression problem в самой computer science (https://en.wikipedia.org/wiki/Expression_problem, https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions, объяснение "на пальцах" https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/). Суть этой expression problem ровно в том же: разработка библиотек универсальных вычислительных элементов требует от языков программирования и реализующих их компиляторы возможности добавлять новые объекты для старых операций и новые операции для старых объектов, чтобы не нужно было переписывать весь код программы. В mDAE против ODE так же, только мы протягиваем обсуждение программных объектов и операций до моделируемых физических сущностей: или ты делаешь язык, на котором разные функциональные объекты описываются разными наборами уравнений, и просто добавляешь эти модели друг ко другу, или в языке у тебя такой возможности нет. Если не решил эту "model expression problem", то тебе нельзя сделать стандартные библиотеки, оформляющие стандартные поведения функциональных объектов. Знания моделей становятся плохо переносимыми между моделями, модели плохо модифицируемыми -- каждый раз при внесении изменений нужно переписывать и перекомпилировать всю модель.

Основные проблемы физического моделирования дифференциальными уравнениями:
-- композиция моделей (прежде всего разнофизичность моделирования, и expression problem и mDAE про это, но есть ещё и многомасштабность моделирования: объединение моделей разных системных уровней, разных масштабов времени, тут тоже свои математические и выразительные трудности в языках программирования, https://en.wikipedia.org/wiki/Multiscale_modeling -- и там тоже проблемы с ODE против DAE, плюс много чего собственного, и для этого тоже может потребоваться учёт в языках программирования/моделирования. Увы, языки программирования/моделирования не системны/многомасштабны "из коробки")
-- невязка характеристик физического и цифрового двойников, и методы, подобные data assimilation тут только часть проблемы. Так, в вычислениях тут важно real time, и поэтому возникает вопрос в том числе и о месте вычислений: edge computing, data centers и широкополосные протоколы связи типа 5G или наоборот, узкополосные с небольшим потреблением энергии из IoT. Ресуры можно экономить, заменяя "честный симулятор-на-дифурах" нейронной моделью, которая хорошо аппроксимирует этот симулятор, но требует на пару порядков меньше вычислительных ресурсов для своей работы. Типичная из подобных работ по нейросимуляции, выучиваемой по результатам классической алгоритмической симуляции -- https://arxiv.org/abs/2010.03409, Learning Mesh-Based Simulation with Graph Networks. Our results show it can accurately predict the dynamics of a wide range of physical systems, including aerodynamics, structural mechanics, and cloth. The model's adaptivity supports learning resolution-independent dynamics and can scale to more complex state spaces at test time. Our method is also highly efficient, running 1-2 orders of magnitude faster than the simulation on which it is trained).
-- недостаток вычислительных ресурсов в моделировании, при этом речь даже не идёт специфически об асиммиляции и непрерывной калибровке, а просто об уменьшении стоимости вычислений. No free lunch theorem гласит, что нет универсально быстрых алгоритмов: алгоритм, хороший для одной задачи будет плох для другой, и наоборот. Обсуждение качественного имитационного моделирования обычно связывают с суперкомпьютерами. И для удешевления и ускорения моделирования нужно делать прорывы в алгоритмике, менять физику компьютера (например, переходить к оптическим или квантовым вычислениям).

Основная мысль тут для широкой публики (то есть мысль, которую нужно знать всем культурным людям) -- это наличие цепочки:
-- описание хитрого поведения системы, то есть физическое описание динамики системы требует хитрой математики. Тут можно вспомнить ломоносовское "Математика царица всех наук, но служанка физики", и я напомню уже очень древний текст http://imperium.lenin.ru/~verbit/MATH/programma.html, раздел "почему эта программа такая, а не другая", а также огромнейшие дискуссии у меня в ЖЖ в 2009 году по поводу инженерного статуса математики -- http://ailev.livejournal.com/668305.html и https://ailev.livejournal.com/669463.html. В этих дискуссиях в ЖЖ я задаюсь методологическими вопросами о целях математики: "призываю математиков почувствовать себя не столько "исследователями", сколько инженерами (с учетом того, что в работах настоящих инженеров исследований и изысканий хоть отбавляй)", то есть не просто "искать", но "целенаправленно искать в интересных для деятельности направлениях". Из более свежего по этому направлению связи математического описания и физики -- обсуждение статуса математики David Deutsch. Он считает физику наукой о поведении объектов реального мира, а математику как науку о поведении объектов мира абстракций, computer science оказывается при этом экспериментальной наукой о доказательствах. Математика базируется на доказательствах/выводах/inference/вычислениях, которые делаются физическими вычислителями, и правильность теорий о том, какие могут быть эти доказательства на этих физических вычислителях, чтобы мы могли им доверять, определяется экспериментально. Напомню ссылку на книгу Дойча об этом: https://yadi.sk/i/SjpWiPqM4PQQSg
-- хитрая математика и алгоритмы солверов для этой хитрой математики для хитрой физики требуют хитрых языков моделирования, а для хитрых языков моделирования требуются хитрые компиляторы для разных типов физических вычислителей, это совпадает с традиционным пониманием computer science как связывающей математику с эффективным (пор ресурсам и времени) физическим вычислением.

Когда директор стадиона обсуждает цифрового двойника для своего стадиона, хорошо бы, чтобы он понимал SoTA в области моделирования. А то ему теоретики-математики без понимания сути computer science намоделируют так, что мало никому не покажется -- моделирование тут похоже на безопасность, про него ведь можно легко сказать "моделирования много не бывает", и тогда оно может съесть все деньги и ничего не дать взамен, как и излишняя безопасность. Лекарство легко может стать болезнью.

Алгоритмика мышления как исследований и вывода: моделировать может вычислитель
Но есть и альтернативное моделирование "от данных", когда физика неизвестна и люди не могут написать нужные системы дифференциальных уравнений. Тогда данные экспериментов исследуются алгоритмом (а не людьми) на предмет отражения ими какой-то неизвестной физики, а соответствующее знание физики и особенности поведения киберфизической системы отражается в распределённом представлении (machine learning, representation learning, deep learning -- https://ailev.livejournal.com/1045081.html). Берём универсальный аппроксиматор (глубокую нейронную сеть, например), и реализуем модель физической системы как неизвестную функцию, восстанавливаемую по имеющимся историческим данным.

Но и тут возможны варианты. Так, один из вариантов исследования физики компьютером -- это differentiable programming/дифференцируемое программирование. Киберфизическая система требует оптимизации, для этого мы оптимизируем для начала её описание/модель, эта модель требует дифференцируемости для возможности применить алгоритмы оптимизации, а дифференцируемость диктует то, как должен быть устроен язык и его компилятор -- и это уже вопросы к computer science. Получается, что computer science обслуживает инженерное моделирование и по этой линии обеспечения дифференцируемости. Затем в инженерии идёт переход к идее "дифференцируемое всё" как ещё один вариант моделирования как предварительного шага к последующей оптимизации, производимой на модели (обзор был в "Дифференцируемое всё: от чёрно-белой картины мира к рябенькой", 2019 год, https://ailev.livejournal.com/1464563.html, и там говорится в том числе и о differentiable architecture, сама архитектура оказывается моделируемой не дискретными "инженерными решениями", а непрерывными представлениями, на которых можно вычислять архитектурный оптимум).

Дифференцируемость кода произвольных функций задаёт весьма специфические требования к языку программирования, и тут в лидерах сегодня Swift и Julia (и обсуждается даже дифференцируемое квантовое программирование на Julia -- https://julialang.org/blog/2019/12/yao-differentiable-quantum-programming/, или классические алгоритмы машинного обучения типа XGBoost, которые делаются дифференцируемыми -- https://juliacomputing.com/blog/2020/02/ad-xgboost/).

Подход, когда моделирование выполняется не человеком, а универсальным алгоритмом (использование AI в инженерном/физическом моделировании) относительно прост, вычислительно эффективен, и при этом ещё и экономит человеческие усилия по моделированию. Против этого подхода главное возражение в отсутствии моделирования-как-объяснения. Дифференциальные уравнения позволяют как-то объяснять поведение системы (хотя тут тоже возникает много вопросов), а вот нейросетка -- это чисто предсказательная модель, применение которой весьма ограничено. Подробному рассмотрению того, чем же отличаются предсказательные модели от объяснительных (связывающих причины и следствия какой-то логикой) посвящено довольно много литературы:
-- критика со стороны авторов причинного вывода, прежде всего Judea Pearl, в том числе в The Book of Why https://yadi.sk/i/oKRCcoJVeH_q_g, но и не только. Вот последнее выступление Pearl, где он вводит понятие deep_understanding/глубокое_понимание и описывает происходящее с причинным выводом как "одомашнивание": дикие нерешаемые раньше проблемы объяснений становятся сегодня домашними и не страшными -- http://causality.cs.ucla.edu/blog/index.php/2020/12/28/edited-script-of-j-pearl-talk-at-montreal-ai-debate-2/.
-- критика со стороны эволюционной эпистемологии, и тут Дойч с его "Началом бесконечности", https://yadi.sk/i/SjpWiPqM4PQQSg, где он прямо указывает на computer science как науку о доказательствах, и необходимость доказательств для хороших объяснений.
-- тут генерация физических гипотез из экспериментальных данных (идёт поток статей про "обычную науку без учёных" -- дистилляция нейронных сетей в алгебру, переоткрытие "из данных" законов ньютоновской механики, гамильтониана и т.д., подробней в https://ailev.livejournal.com/1526085.html, где даётся ссылка на работу https://arxiv.org/abs/2006.11287 (разбор статьи вот тут: https://www.youtube.com/watch?v=LMb5tvW-UoQ).

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

Disclaimer: что не сказано, то просто не сказано, в коротком тексте всего не упомянешь
И, конечно, всё тут написанное ни в коей мере не исчерпывает ни тему математического моделирования физических систем (я даже governing equations тут не помянул ни разу!), ни тему связи модели и системы (эпистемология: как мы знаем, что эта модель и впрямь что-то важное отражает в системе), ни тему siblings как подтемы digital twins (в том числе обсуждение для этих siblings "лестницы каузальности", предложенной Judea Pearl и развиваемой дальше в работах типа "On Pearl’s Hierarchy and the Foundations of Causal Inference", https://causalai.net/r60.pdf), ни тему интеграции данных разных моделей, в том числе разных моделей по ходу жизненного цикла (онтологическая интеграция данных, софт типа Simantics как "онтологический интегратор симуляторов", https://www.semantum.fi/solutions/seas/ в digital twins такое указывается напрямую: https://www.semantum.fi/solutions/SemantumDigitalTwin/, и такого софта ведь много!), ни многих других проблем, традиционно обсуждаемых в проблематике digital twins.

Как всегда, "что не сказано, то просто не сказано, это не значит, что "не учли, не подумали"" -- помним о библиотечке обзоров digital twins https://yadi.sk/d/yzpBuICd0YJevA и при желании идём разбираться туда, там тысячи страниц свежих текстов. Просто в одном коротком тексте можно поднять только несколько проблем. В текущем тексте поднята только узкая тема связи физики, математики и computer science: физического моделирования -- его математики (линия моделирования физики дифурами людьми, линия поиска дифуров компьютером) -- его computer science и software engineering как создания языка программирования и его компилятора для физического же вычислителя (в конечном итоге одна физическая система-вычислитель/виртуальная модель моделирует другую целевую киберфизическую физическую систему -- всё физично и реально, абстрактные объекты математики там спрятаны где-то посредине).

UPDATE: обсуждение -- https://www.facebook.com/ailevenchuk/posts/10220129377358734