Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

Военная MBSE в 2020: мои заметки по лекции Dr. Warren Vaneman

Двухмесячной давности лекция для членов INCOSE по современному пониманию MBSE (model-based systems engineering) в INCOSE от Dr.Warren Vaneman (Professor of Practice in the Systems Engineering Department at the Naval Postgraduate School, Monterey, CA) -- https://youtu.be/BPlphC88xR4.

Инициатива с MBSE была поднята любителями SysML в INCOSE ещё в 2007 году (www.omgwiki.org/MBSE/doku.php и там сайт на OMG не случайно, ибо в MBSE доминирует SysML -- я в 2009 году даже выступил в INCOSE INSIGHT с возражениями против использования термина для одного-единственного языка моделирования, явно не лучшего языка для моделирования систем, https://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/).

В лекции Warren Vaneman этих языков системного моделирования уже множество, и он сам рулит разработкой и использованием LML (https://www.lifecyclemodeling.org/?page_id=10). Но к его чести, в лекции LML даже не особо выпячивается военная специфика не слишком выпячивается, хотя лекция полна военно-морских иллюстраций и речь лектора полна бюрократизмов из системно-инженерных стандартов DoD. Тем не менее, само содержание лекции IMHO существенно отражает специфику дорогого долгостроя военной системной инженерии и поэтому далеко от описания state-of-the-art.

Делается утверждение, что сегодня MBSE включает четыре принципиальные составляющие:

1. Языки моделирования (типа SysML, LML и т.д.. Если бы был SysMoLan, то он тоже бы попал сюда. Вот, насколько я понимаю, мой первый заход на SysMoLan, 2013 год, и это как раз из переписки в INCOSE по поводу языков моделирования в MBSE -- https://ailev.livejournal.com/1061167.html, а вот текущая цепочка текстов -- https://ailev.livejournal.com/1443879.html). Позиция Vaneman тут утопическая: "язык должен быть основан на онтологии для независимости от представлений/presentations и независим от инструментов". Развитие языков программирования показывает, что побеждает в конечном итоге не язык-стандарт со множеством его инструментальных реализаций, а один и тот же язык-компилятор (реализация языка как "стандарт языка"). Vaneman говорит, что мышление должно быть tool-agnostic, в терминах даже не языка, а онтологии этого языка -- и это так и есть, но вот множественность инструментов для этой онтологии, если она становится распространённой -- вот это утопично. Насчёт того, что ориентация на общую онтологию позволит объединять модели на разных языках, поддержанные разными инструментами -- это тоже оказалось утопией. И на замечание, что произойдёт с моделями, для которых поставщики софта прекратили поддержку инструментов, у Vaneman тоже нет ответа. Всё произойдёт: потеряем мы эти модели через десяток лет с момента их создания.

2. Практики, опирающиеся на моделирование (model-based processes) на всём жизненном цикле. Переход к этим практикам Vaneman представляет как смену культуры работы/culture change с каких-то отдельных рабочих продуктов к "виртуальному представлению"/virtual system representation. Это абсолютно совпадает с пониманием производственной культуры как совокупности практик работы, которое я дал при описании мереологии практик в https://ailev.livejournal.com/1508228.html). Vaneman подчёркивает, что это требует хорошего понимания разницы между описаниями и их артефактами, тот самый переход к "виртуальности" в обсуждениях вместо ориентации на отдельные рабочие продукты-"документов". И тут важен аспект programmatic, чтобы эта культура охватывала всех контракторов "программы" (помним, что речь идёт о военных "закупках", структурируемых по "программам", более-менее совпадающим в части менеджмента с программами проектного управления), (https://www.dsiintl.com/support/publications/article-index/independent-systems-engineering-vs-programmatic-systems-engineering/). Сюда же отнесём обсуждения управлением конфигурацией и изменениями зоопарка моделей в проекте (Vaneman это называет data governance).

3. Подходы к представлениям (presentation frameworks, список view/viewpoints и мета-модели для этого списка, соотнесённый к разным проектным ролям, которым они нужны для принятия решений). От архитектурных подходов (architecture frameworks) Vaneman предлагает отличать тем, что архитектурные описания через набор традиционных архитектурных veiwpoints/systems perspectives только часть всех описаний, нужных для работы над системой: ещё нужны описания для неархитектурных проектных ролей -- финансовые описания, описания для управления работами и т.д.. Как я понял, текущая позиция в том, что в каждом проекте нужно делать этот список представлений заново ввиду полной недостаточности всяких DoDAF и TOGAF (в которых требуются view, которые никому не нужны в проекте, но не указываются view, которые нужны и важны -- постоянный предмет критики использования этих якобы всеохватных стандартов, которые переохватны в одних частях и явно недоохватны в других).

4. "Структура"/structure (ужас полный, использование в специальной терминологии таких общих и многозначных слов должно быть запрещено инквизицией и жёстко преследоваться!) это по Vaneman необходимость отображения отношений между частями как системы, так и разными описаниями (concordance -- согласованность разных описаний одного и того же объекта и traceability -- отслеживаемость связей между описаниями). Холистичность тут, решением вроде как является интеграция данных жизненного цикла -- и Vaneman считает огромной проблемой недостаток внимания к этим вопросам. Пока он будет называть это "структурой" внимания и не будет. Опять же, пока он будет игнорировать опыт попыток интеграции данных жизненного цикла -- не будет видеть и проблем.

Конечно, его спросили: а можно ли посчитать ROI от перехода к MBSE? Он честно ответил, что нельзя. Понятно почему: ROI от того, что становишься умней и делаешь меньше ошибок посчитать нельзя. MBSE позволяет лучше управлять коллективными памятью и вниманием в инженерном проекте, делать успешными более сложные проекты -- как тут посчитать ROI? При этом переход к MBSE затратен, и если у вас простой проект (нет большого коллектива людей, малое число объектов в системе), то и затеваться с большим моделированием и его инструментарием не стоит.

Итого: старички отрасли по-прежнему думают о МBSE и говорят примерно те же слова, что и в 2007 году, только уточняя их. Жизнь же поменялась. Так, в лекции ничего не говорится о digital twins, ничего не говорится об очевидных затыках с онтологической интеграцией данных жизненного цикла (был же огромный опыт за прошедший десяток лет! Десяток лет назад PLM-системы только-только появлялись, а сейчас это общее место. И языки системного моделирования в них вроде как входили поначалу как организующее начало, но потом как-то сдулись -- я думаю, что они просто ушли в текстовую и табличную форму, это визуальные представления диаграммных языков сдулись).

То есть это хорошее описание текущего состояния и проблем, но не описание state-of-the-art и трендов. Военные всё-таки такие военные!
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 0 comments