Методология 2025

Концепция системы часто представляется в форме какой-то гибридной диаграммы. В её основе часто – функциональная диаграмма (в системах функциональность – первична), но для функциональных объектов указано, какие конструктивные объекты будут играть эти роли, часто это делается «аннотированием» обозначений на «принципиальной схеме» указанием на то, какие конструктивы будут задействованы для воплощения этих функциональных объектов. Какого-то специального представления «отображения» функционального представления на конструктивное представление системы, например, таблицы соответствия, не делается. Иногда функциональные диаграммы в форме принципиальной схемы гибридизируются каким-то указанием разнесения её элементов на модули («функциональный насос» реализован «тремя конструктивными насосами и системой управления для них», это сделано для повышения надёжности), и часто ещё указывается и компоновка в пространстве, поэтому обозначение каких-то элементов делается состоящим сразу из нескольких имён, если это возможно: функциональное, конструктивное, пространственное и так далее (стандарт ISO 81346 как раз про правила такого именования, обозначений/designations).

Так что большая часть методологической работы часто делается сегодня в формате графовых представлений «принципиальных схем». Расчёты по таким функциональным диаграммам потоков жидкостей, электрического тока, энергии, даже денег, предметов работ, пассажиропотоков, а ещё потоков информации и т. д. учитывают «одномоментность во времени» и называются 1D-моделированием, ибо это одномерное представление – какая-то характеристика в каждом месте диаграммы разворачивается во времени.

Такое функциональное (это потоки в ходе функционирования моделируемой системы, функциональное представление – это ответ на вопрос «как работают в момент эксплуатации») моделирование чаще всего делают при помощи систем дифференциальных уравнений, учитывающих «одномоментность». Иногда такое физическое 1D моделирование называют системным моделированием, ибо речь идёт о моделировании работы системы как функционального объекта в целом на основе понимания того, как именно работают отдельные подсистемы.

В менеджменте такое моделирование чаще всего делают средствами системной динамики34 – и это хорошо, только не надо считать, что это будет единственное моделирование в ходе проекта по созданию системы. Нет, это только 1D-моделирование, но будут ещё и другие. Более того, сегодня системным моделированием чаще называют 1D-моделирование не только упрощёнными дифференциальными уравнениями системной динамики (там очень ограниченный набор элементов модели и допустимых видов уравнений в системе дифференциальных уравнений), но и полноценным физическим описанием системы. В физическом системном моделировании (physical systems modeling), узко понимаемом как численное 1D моделирование, конкурируют каузальное моделирование с системой уравнений из обычных дифференциальных уравнений (ODE) и акаузальное моделирование с системой из алгебраических дифференциальных уравнений (ADE). Каузальное моделирование требует указывать порядок решения системы уравнений, а акаузальное моделирование – нет, систему уравнений решает сам компьютер, тренд при этом – переход от каузального моделирования к акаузальному.

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

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

1D-моделирование довольно долго делалось на акаузальных языках моделирования, например, Modelica35, одновременно с графическим и текстовым представлением систем алгебраических дифференциальных уравнений. В физическом системном моделировании учитывается уже более-менее разная физика системы (механика, гидравлика, энерготеплопереносы и т.д.) или какие-то её другие свойства (например, умение производить работы, пропускать через себя поток предметов работ – иногда это называют даже factory physics). Но это всё моделирование функционирования, по факту – это моделирование метода работы системы. Вот пример представления модели на Modelica36:

Мы видим на картинке 3D-модель системы «как в САПР», а также её функциональную графическую модель (диаграмму), а также программный код, соответствующий этой диаграмме. Диаграммное представление «наглядно», но с ним очень трудно работать – при росте размера диаграммы и увеличении числа «аннотаций» каждого элемента диаграммы (по факту «аннотации» – это текст, описывающий элементы диаграммы и связи – никогда не забываем, что любую картинку надо объяснять, и к картинкам для полной понятности мы «приговариваем» большое количество текста) модель, то есть систему дифференциальных уравнений, становится удобней представлять в виде текста на языке программирования. «Резистор» становится не схемным изображением на диаграмме, а текстом программы.

По итогам эксплуатации многочисленных систем с Modelica оказалось, что диаграммное представление функциональных схем менее удобно в работе: модельеры-проектировщики проводят много времени в текстовых представлениях, а диаграммы используют главным образом в «презентациях», для красоты, которую называют «наглядностью». Любые изменения-исправления, вставки и удаления, предложение альтернатив и комментарии делаются в текстовой форме, она банально удобнее. Поэтому современные средства 1D-моделирования по факту представляют собой пакеты численного моделирования для обычных языков программирования, например, один из самых мощных таких пакетов – JuliaSim37. Отсутствие «визуальности» функционального моделирования с лихвой компенсируется удобством использования: тексты менять в ходе разработки много быстрее, чем диаграммы. И тексты можно пересылать друг другу, легко комментировать, чего не сделаешь с диаграммами – учитывая ещё и то, что откомментировать фрагмент текста программы функциональной модели можно и в чате, а вот с диаграммами всё не так просто, нужны специальные дорогие программы для работы с диаграммами, и они должны быть установлены у всех участников проекта, что обычно невозможно.

Тем самым мы от ограниченного диаграммного языка описания методов в их разложении перешли к описанию разложения метода алгоритмом, что ярко проявляется в функциональном физическом моделировании.

Инженеры в ходе проектирования обсчитывали принципиальные и технологические схемы, иногда называя это одноразмерным/1D моделированием, чтобы противопоставить трёхмерному прочностному и тепловому моделированию – речь-то идёт о функциональных описаниях, и тут у математиков, системных инженеров, программистов и всех остальных терминология существенно различается. Это как раз наша задача – ввести какой-то общий язык описания этого моделирования и этих вычислений, привязав эту терминологию и способы моделирования к современным методам разработки. «Хитрая физика» в функциональном физическом моделировании ведёт к «хитрой математике», которая ведёт к «хитрым языкам моделирования», которые реализуются достаточно необычными приёмами в разработке компиляторов и библиотек, поддерживающих моделирование в конкретных областях физики (электротехника, оптика, теплоперенос), но и не только физики – речь идёт вообще о моделировании мира в момент работы системы.

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

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

Но как же проходит такой трюк с переходом от ODE к DAE? А вот так: разные уравнения собираются в большую систему из сотен, или даже тысяч (а в последнее время речь идёт и о миллионах) дифференциальных уравнений, и дальше решением этой огромной системы уравнений занимается компьютер (или даже суперкомпьютер, если система реально большая). Вот сравните удобство для инженеров моделирования электрического мотора с учётом инерции его вращения при представлении модели в DAE и ODE формах в их диаграммном виде38:

Первые принципы физики естественным образом приводят к рассмотрению акаузальных моделей с алгебраическими дифференциальными уравнениями (DAE), таких как на рис. 1 слева. Например, рассмотрим случай электрических цепей. Законы цепей, такие как законы Кирхгофа, естественно выражаются в виде уравнений баланса: алгебраическая сумма токов в сети проводников, встречающихся в одной точке, равна нулю; или сумма всех напряжений в петле равна нулю. Это верно будет и для операционного менеджмента (потоки работ, денег, материалов в сетях/цепях поставки), в любых других системах, в которых что-то «течёт» (в том числе и «текут данные»).

Аналогичным образом некоторые компоненты (например, резисторы или конденсаторы) имеют заранее определенную ориентацию входа/выхода. В одной и той же схеме можно назначить разный статус входа/выхода её переменным, в зависимости от того, какие из них объявлены источниками. Такая же ситуация возникает в механике или термодинамике, везде, где нужно функциональное моделирование значений каких-то характеристик во времени. Кроме того, добавление ещё одного физического компонента в принципиальную схему не представляет сложности, тогда как для «вычислительной блок-схемы» на рисунке справа может потребоваться полная переработка.

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

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

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

Но и DAE/acausal моделирование оказалось с проблемами. Главная проблема тут – невозможность использования Multi-Mode DAE Models (mDAE). Multi-mode models – это моделирование режимов, связанных с разными структурами одной и той же системы. Если у вас летит ракета с тремя ступенями, потом с двумя, потом с одной ступенью – моделировать это нужно по-разному, это же будут лететь совсем разные ракеты, у которых только название общее, а физика совсем разная! Если у вас моделируется атомный реактор в ходе его нормальной работы, то там одна физическая модель. А если он уже начал плавиться – то моделировать его плавление нужно по-другому, прошлая модель реактора не будет работать. Это явление носит разные имена, Multi-mode DAE models только одно из них, в математике и физике используют и другие, например, VSS (variable structure system, – и они тоже имеют много разных подвариантов, «частных случаев»)41. Есть и другие имена, разные группы исследователей приходят к этой проблеме учёта изменения структуры модели вслед за структурой моделируемой физической системы в разных исследовательских ситуациях и подчёркивают в имени разные аспекты проблемы.

Математика mDAE хитра, и языки акаузального физического моделирования и их компиляторы должны учитывать эту хитрость математики, иначе результаты моделирования будут кривые. Вот одна из работ 2020 года, проясняющая трудности: «The Mathematical Foundations of Physical Systems Modeling Languages»42. Трудности там демонстрируются на вот таком простом примере, с которым не справляются нынешние компиляторы Modelica, и дело там не только в computer science (плохом языке моделирования и плохом его компиляторе), но и в математической-физической стороне вопроса:

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

После того, как разобрались с физикой и описывающей её математикой, подключается computer science, ибо нужно теперь создать язык с нужной для этой математики операционной семантикой и (оптимизирующий!) компилятор для него. Это оказывается в случае mDAE не так легко, ибо уже не хватает уровня продвинутости человечества в computer science. Исследования (computer science) и разработки (software engineering) для акаузального мультифизического моделирования идут по вот этим основным линиям, а основное развитие сейчас происходит в ModelingToolkit. jl43 в проекте JuliaSim44.

В какой-то мере этот тренд с использованием «языка» mDAE вместо ODE для физического моделирования похож на создание разных языков программирования для решения expression problem в самой computer science45. Суть этой expression problem ровно в том же: разработка библиотек универсальных вычислительных элементов требует от языков программирования и реализующих их компиляторов возможности добавлять новые объекты для старых операций и новые операции для старых объектов, чтобы не нужно было переписывать весь код программы. Обратите внимание, что в предыдущем предложении мы по факту говорим, что языки программирования и языки моделирования – это одно и то же, функциональное моделирование делается на языке программирования. Это отдельная долгая история, ибо на самой заре программирования «языки высокого уровня» как раз и считались языками моделирования (например, Simula46, первая версия которой появилась в 1962 году, это был первый объект-ориентированный язык). Это лишний раз подтверждает, что моделирование может и должно делаться не только на специализированных упрощённых языках моделирования, но и на самых обычных языках программирования общего назначения – но оно предъявляет специальные требования к этим языкам.

В mDAE против ODE мы расширяем expression problem с обсуждения только программных объектов и операций до обсуждения описания/моделирования физических сущностей: или ты делаешь язык, на котором разные функциональные объекты описываются разными наборами уравнений (декларативно), и просто добавляешь эти модели друг ко другу, или в языке у тебя такой возможности нет, и ты вынужден каждый раз переделывать программу при малейших изменениях моделируемой системы или малейших изменениях в идеях самого моделирования.

Если ты не решил эту «model expression problem», то тебе нельзя сделать стандартные библиотеки, оформляющие стандартные поведения функциональных объектов. Знания моделей становятся плохо переносимыми между моделями, модели плохо модифицируемыми – каждый раз при внесении изменений нужно переписывать и перекомпилировать всю модель.

Есть ещё и многомасштабность моделирования: объединение моделей разных системных уровней, разных масштабов времени, тут тоже свои математические и выразительные трудности в языках программирования47, – и там тоже проблемы с ODE против DAE, плюс много чего собственного, и для этого тоже может потребоваться учёт в языках программирования/моделирования. Увы, языки программирования/моделирования не системны/многомасштабны «из коробки».

Для моделирования в реальном времени (цифровой двойник/digital twin, скорость моделирования имеет значение, проблемы алгоритмики как алгоритмов, дающих при заданной точности вычислений максимальную скорость счёта, тут всплывают в полной мере) тоже есть множество проблем, например, высокая скорость получается за счёт различных суррогатов48 моделей (быстрых аппроксиматоров сложных функций, например, нейросуррогаты получаются на базе нейронных сетей). No free lunch theorem гласит, что нет универсально быстрых алгоритмов: алгоритм, хороший для одной задачи будет плох для другой, и наоборот. И в каждом «общем решении» всё равно будут возникать (сотнями, тысячами!) многочисленные «частные случаи», требующие отдельных способов решения. Обсуждение качественного имитационного/simulations моделирования обычно связывают с суперкомпьютерами, это не случайно. Для удешевления и ускорения моделирования нужно делать прорывы в алгоритмике, менять физику компьютера (например, переходить к оптическим или квантовым вычислениям).

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

Задания: принципиальные схемы

Поставьте отметку о выполнении:

1. Написан пост о принципиальной схеме вашей системы. Особо проверьте, что в принципиальной схеме показаны функциональные, а не конструктивные объекты. Отметьте, вы где-то нашли эту принципиальную схему, или вам пришлось её составить для этого задания самостоятельно?

2. Написан пост о принципиальной схеме организации-создателя вашей системы. Особо проверьте, что в принципиальной схеме показаны оргроли, а не оргзвенья. Отметьте, вы где-то нашли эту принципиальную схему, или вам пришлось её составить для этого задания самостоятельно?

Пример: методы создания систем AI

То, что было рассказано в предыдущем разделе, конечно, применимо не только к «железным» системам, требующим физического моделирования. В качестве примера рассмотрим функциональные описания (то есть описания ролей и методов их работы) в прикладной методологии систем AI. Конечно, если вы никогда не сталкивались с предметной областью разработки систем AI, вам трудно будет понять этот текст в части его содержания. Но вы можете обращать внимание не на собственно содержание (что там говорится про сами системы AI), а обращать внимание на форму того (мета-мета-модель фундаментальной методологии, а не мета-модель методологии систем AI), что о них говорится – какие там используются диаграммы, что рассказывается про сами методы, на какие особенности использования терминологии обращено внимание. Это примерно как логиков тренируют на тексты про сепульки: смысл непонятен, но логические ошибки могут быть очевидны. Вот так и тут: обращайте внимание на то, что говорится про методологию и методы, а термины для самих методов и ролей могут быть загадочны.

Главный посыл этого подраздела: материал курса «Методология» общеприложим к самым разным системам. При этом мы признаём, что начиная со следующего раздела мы главным образом будем рассказывать про методологию в её версии для методов работы систем-создателей в графах создания каких-то систем. Но вот первый раздел показывает, что методология вполне приложима как метод мышления о не слишком интеллектуальных «железных» агентах, хотя там термин больше используется не «метод», а «функция». Методология приложима и к методам/функциям работы таких «не совсем пока интеллектуальным» агентов, как нынешние системы AI.

Сегодня (а про завтра ничего сказать пока нельзя) центральное место в функциональной декомпозиции систем AI занимают искусственные нейронные сети. Поглядим на очень грубо составленное дерево/аутлайн системных уровней систем AI:

Стек тут – любой проход по одной вертикали в этом дереве, но помним о сложностях разложения методов в дерево. Есть сложности моделирования разбиения функциональных объектов – роли ведь тоже можно декомпозировать по-разному, трудности разложения в спектр их методов работы тут проявляются в полной мере. Так, обратите внимание, что слои есть и у голов, и у бэкбонов как частей ANN, ибо «слой» из «нейронов» вроде как составная часть ANN, но верхние слои – это «головы» (их может быть и несколько), а нижние слои – бэкбоны. Как мы и говорили, очень трудно представить «чистый стек», но и «чистое дерево» представить тоже трудно, и то же самое будет даже с графами. В следующих разделах мы покажем, как многие такие представления конвертировать в табличные, но содержательно это не убавит проблем. При разузловке/разбиении и синтезе что ролей, что их методов, придётся каждый раз в каждом проекте включать голову – и думать.

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

В текущем подразделе мы приводим пример разговора про методы работы систем AI: что там делают подсистемы и подсистемы подсистем, обмениваясь данными, это dataflow представление. Центральное место в функциональном разбиении системы AI занимает искусственная нейронная сеть (ANN, artificial neural network), подсистема системы экспертов (несколько нейронных систем объединяются как «эксперты» в смеси экспертов, MoE, mixture of experts)49:

В суперупрощённом виде мы видим функциональную диаграмму: какая-то входная информация даётся на вход маршрутизатора, который выбирает пару экспертов из четырёх возможных, а затем ответы этих экспертов как-то замешиваются в выходную информацию. Вот эти «эксперты» обычно – искусственные нейронные, ANN, artificial neural network сети с классической декомпозицией на «слои» из вычислительных «нейронов»50. Вот типичная функциональная диаграмма для ANN (традиция называет такие диаграммы «архитектурами», но в этой «архитектуре» ни слова не говорится о конструктивах, это в других предметных областях было бы «принципиальная схема»), на ней представлен трансформер/transformer51 как вид ANN, отвечающий подобного сорта функциональной диаграмме, эта «принципиальная схема» была предложена в 2017 году:

Стрелки тут обозначают движение потоков данных (dataflow), а блоки – обработчики данных (функциональные объекты, выполняющие обработки каждый по своим методам). Обработчики данных представляют по факту как-то модифицированные «слои» из отдельных «нейронов», плотно перевязанных связями.

Обзором техноэволюции ANN занимается прикладной методолог систем AI Григорий Сапунов в канале «Gonzo-обзоры ML статей»52. Основное содержание его обзоров много лет было как раз посвящено модификациям принципиальных схем ANN. В Gonzo-обзорах первый раз слово «метод» встречается 25 февраля 2019 в обзоре работы «AET vs. AED: Unsupervised Representation Learning by Auto-Encoding Transformations rather than Data»53, там фраза «Дальше в работе рассматривают только параметрические преобразования. Это типа проще реализовывать, а также проще сравнивать с другими unsupervised методами». Онтологически из фразы следует, что «unsupervised learning»:: метод – это род методов, в котором есть множество видов методов. Обратите внимание, что методы – это поведение, а до этого в подразделе мы обсуждали вроде как функциональные разбиения ролей на подроли (систем на подсистемы, в функциональном рассмотрении – разбиение функциональных объектов, а не поведения). Вот эта связанность роли и метода должна как-то удерживаться, нельзя думать про одно без другого: не может «никто» делать что-то, и «кто-то» не может ничего не делать! Опять же, роль может работать по какой-то сигнатуре метода, а там внутри можно даже менять методы в их разложении для этой сигнатуры, а роль поможет удерживать внимание на результирующем методе, абстрагируясь от его разложения.