Моделеориентированность в жизненном цикле ​

На V-диаграмме удобно обсуждать классический слоган системной инженерии: все возможные работы правой части диаграммы нужно переносить в левую часть. Всё, что можно сделать на стадии описания системы, нужно делать именно на этой стадии: битами много дешевле оперировать, нежели атомами, особенно если речь идёт о сложных дорогих системах типа самолёта или энергоблока атомной электростанции. Вот данные INCOSE по стоимости исправления ошибок в зависимости от стадии жизненного цикла^[1]:

Стадия обнаружения ошибки Стоимость исправления Требования x1 (единица отсчета) Проектирование x5 Строительство x12 Проверки X40 Эксплуатация X250

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

Современность, конечно, к этому добавила:

• Моделировать-таки нужно много раз (а не один раз под чётко определённые требования: концепция системы постоянно изменяется в ходе проекта, жизнь ведь не остановишь --- «зафиксировать требования» сегодня считается плохой практикой, хорошая практика --- проверить гипотезы по концепции использования, потом откорректировать по итогам проверки, проверить опять --- и так длительно развивать систему после выпуска MVP), но перед этим нужно ещё и разбить систему на модули, используя знания по архитектуре (архитектура стала отдельной от разработки с её моделированием дисциплиной, в том числе озабоченной тем, чтобы разработку разбить на максимально независимые части).
• И делать надо много раз, в том числе не всю систему, а отдельные её части. Если правильно разбить систему на части (максимально независимые, но всё-таки взаимодействующие для получения эмерджентных свойств системы в целом) и организовать способы их взаимодействия, то переделывать можно будет не всю систему, а только часть. И дальше систему нужно будет развивать, переделывая в физическом мире её отдельные части, и это будет долго («непрерывное всё» включает в себя непрерывную разработку, непрерывное изготовление, непрерывные испытания, непрерывное разворачивание, непрерывный ввод в эксплуатацию всё новых и новых версий системы со всё новыми и новыми свойствами).

Моделирования тем самым стало не меньше, а больше --- просто «много моделируй, а один раз сделай» стало само выполняться много раз.

«Моделирование в широком смысле --- это эффективное по затратам использование чего-то одного вместо чего-то другого для мыслительных целей. Это позволяет нам использовать вместо реальности что-то такое, что проще, безопаснее или дешевле чем реальность для заданной цели; модель является абстракцией реальности в том смысле, что она не может представить все аспекты реальности. Это позволяет нам иметь дело с миром упрощённым способом, обходя сложность, опасность и необратимость реальности»^[2].

Мы не тратим силы на обсуждение и обработку ненужных деталей моделируемого объекта. Модели --- это «правильные упрощения». Обсуждаем только то, что отмоделировано, то, что важно, что нужно.

Формальную (на основе математики) модель можно относительно легко проверить на формальную правильность --- вручную или даже компьютером. Это называется проверкой моделей (model checking). Так, в радиосхеме можно формально удостовериться, что все её компоненты соединены и нет неприсоединённых компонент, все соединения не имеют разрывов (то есть не идут откуда-то в никуда).

Формальную модель можно подвергнуть оптимизации (в том числе компьютерной) по самым разным критериям, в том числе многим ранжированным критериям. С формальной моделью может работать поиск/search --- искать вычислительными методами оптимальное решение в пространстве решений (при этом модель может быть даже деформализована для поиска оптимума, речь тут идёт о так называемых дифференцируемых архитектурах^[3]).

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

Формальную модель можно не делать руками, а породить/generate компьютером --- это решение проблемы сложности. Так, 2.6 триллионов транзисторов в современном микрочипе^[4] невозможно нарисовать руками на кремниевой пластине, и даже невозможно руками нарисовать принципиальную схему такого микрочипа. Но можно породить и принципиальную схему, и литографическую маску из моделей более высокого уровня абстракции на языке описания микросхем.

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

В результате произошедших изменений в распределении работ по практикам в жизненном цикле (больше ресурсов на работы по описанию системы, и поэтому меньше ресурсов на работы по воплощению системы --- и как описание делается с большей точностью и проверяется больше, так и изготавливается система с большей точностью и тоже испытывается/тестируется больше) первый же самолёт новой модели летает, что раньше было невозможно. Сегодня потеряла актуальность традиционная шутка про необходимость для каждой детали «подгонки по месту напильником». Все изготовленные (чаще всего не вручную) по тщательно продуманному и отмоделированному проекту детали просто собираются в целую систему, и она работает как описано проектировщиками. Это соответствует одному из слоганов системной инженерии: «с первого раза правильно», т.е. первое же воплощение системы должно быть работоспособно, его не нужно дорабатывать, а дорабатывать нужно описания-модели. Не всегда ещё так получается, не у всех команд и не во всех областях деятельности, но всё чаще, чаще и чаще. Так, из сорока полётов на Марс до настоящего времени только половина закончилась успешно. Но команда системных инженеров Индии сумела отправить на орбиту Марса в 2013 году ракету с первого раза^[5]. Современность к этому только добавляет: никакая ракета на Марс, никакая запущенная в эксплуатацию система не будет у вас последней. «С первого раза правильно» надо делать всё время, моделировать нужно всё время.

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

Моделирование при этом распространилось не только на левую часть V-диаграммы (описание/проектирование системы) но и зашло в правую часть --- модели начали использоваться и при изготовлении системы, а в последнее время и при эксплуатации. Для готовой эксплуатирующейся системы это получило название «цифрового двойника»/digital twin, а сама система тем самым стала «физическим двойником»/physicaltwin. Все разные вычислители с моделями, датчики и актуаторы самой готовой системы при этом связаны «цифровой нитью»/digital thread (раньше это называлось «интеграция данных жизненного цикла», то есть данные с одной стадии передавались «по водопаду» на другую стадию, это и была «интеграция данных жизненного цикла». Цифровая нить оказалась удачным маркетинговым термином в этом плане, менеджеры сразу понимали, что это «связь между собой разных компьютеров», а «интеграция данных» звучала для них абстрактно).

«Мышление моделированием» в инженерии поддерживается моделерами, а создание производственной платформы (internal development platform) для моделирования в ходе инженерии --- цифровой инженерией. Про это будет подробно в учебнике «Системная инженерия», а тут покажем новый вариант V-диаграммы, который появился в 2018 в связи с вниманием к моделированию в инженерии^[6]:

Этот новый вариант V-диаграммы от Boeing упоминает ещё один синоним для цифровой инженерии: моделеориентированная инженерия/model-based engineering/MBE. Кроме того, это не V, а MBE-ромб/diamond.

Тут уже признаётся, что моделирование (проектирование/modeling и имитационное моделирование/simulation) происходит в течение всего «жизненного цикла», но таки сам жизненный цикл даётся как однократное создание системы, развитие только подразумевается.

Конечно, системные инженеры «железных» систем уже давно понимают, что развитие систем проходит долго, но продолжают держаться за V-диаграмму и разные другие варианты, напоминающие им однократное прохождение водопада. А вот в программной инженерии от таких диаграмм уже отказались, и на их диаграммах показывают обязательно какие-то «циклы», означающие развитие: выдвижение гипотез, их проверку, переделки, адаптации к изменившимся состояниям и т.д.

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