Модельно-орієнтована системна інженерія для оборонних програм: SysML, цифровий ланцюжок і DoDAF

Оборонні програми мають проблему системної інженерії, яка погано масштабується. Велика програма розробки зброї — новий бойовий піхотний бронеавтомобіль, модернізація радара, авіаційний ретранслятор зв'язку — може містити від 10 000 до 50 000 окремих вимог, розподілених між десятками підсистем, кожну з яких розробляють різні інженерні команди, а часто і різні підрядники. Вимоги пишуть у Microsoft Word. Архітектуру малюють у Visio. Визначення інтерфейсів живуть у документах Interface Control Documents, які кожна команда оновлює асинхронно. Тест-плани посилаються на номери параграфів вимог, що непомітно змінилися. Коли надходить Engineering Change Proposal, троє інженерів тиждень вручну шукають по п'ятдесяти документах, що саме зачепить ця зміна.

Модельно-орієнтована системна інженерія (MBSE) замінює цю мережу документів єдиною семантично насиченою моделлю — структурованим репозиторієм вимог, елементів архітектури, поведінкових специфікацій та зв'язків простежуваності, що є авторитетним джерелом, з якого генеруються всі документи. SysML забезпечує мову моделювання. Інструменти на кшталт Cameo Systems Modeler та IBM Rhapsody надають середовище. Цифровий ланцюжок з'єднує модель із симуляцією, генерацією коду та автоматизацією тестування. Архітектурні представлення DoDAF формуються як звіти з моделі, а не підтримуються як окремі артефакти.

Ця стаття є практичним інженерним довідником для менеджерів оборонних програм, головних системних інженерів та архітекторів програмного забезпечення, які оцінюють або впроваджують MBSE. Вона охоплює контраст між документо-центричним і модельно-центричним підходами, використання SysML-діаграм для оборонних систем, простежуваність вимог у моделі, цифровий ланцюжок від вимог до прототипу, генерацію представлень DoDAF, екосистему інструментів та організаційні й управлінські виклики, що визначають успіх або деградацію MBSE-ініціативи до документо-центричності.

Чому MBSE важлива для оборонних програм

Фундаментальна проблема документо-центричної системної інженерії полягає в тому, що документи є роз'єднаними. Пишеться Специфікація системних вимог (SRS); пишеться опис архітектури з посиланнями на номери параграфів SRS; пишеться Interface Control Document із посиланнями на архітектуру; пишеться тест-план із посиланнями на ICD. Кожен документ — це знімок у часі. Коли вимоги змінюються — а в оборонних програмах вони змінюються завжди — ланцюжок ручних перехресних посилань, який підтримує узгодженість цих документів, руйнується. Номер параграфа SRS змінюється, і опис архітектури мовчки посилається на вимогу, якої вже не існує. ICD описує інтерфейс, що був перепроєктований, але так і не оновлений. Тест-план перевіряє поведінку, яку замінив ECP шість місяців тому.

MBSE вирішує це, роблячи модель єдиним джерелом правди. Вимоги, архітектурні блоки, інтерфейси та поведінкові специфікації — усі є елементами однієї семантичної моделі з типізованими зв'язками між ними. Коли вимога змінюється в моделі, інструмент миттєво показує всі архітектурні блоки, що на неї виділені, всі інтерфейси цих блоків та всі тест-кейси, що перевіряють відповідну поведінку. Аналіз впливу змін, який займає тиждень у документо-центричній програмі, займає хвилини у добре підтримуваній MBSE-моделі.

Конкретні переваги для оборонних програм — на відміну від комерційних програмних проєктів — зумовлені формальною структурою оглядів програми. Життєвий цикл розробки оборонного ПЗ включає System Requirements Review (SRR), Preliminary Design Review (PDR) та Critical Design Review (CDR) як контрактно обов'язкові вузлові точки з визначеними критеріями входу та успіху. MBSE змінює характер цих оглядів: замість оцінки узгодженості стосу документів рецензенти запитують у моделі метрики покриття — який відсоток вимог розподілено по елементах архітектури, який відсоток інтерфейсів формально специфіковано, який відсоток тест-кейсів пов'язано з вимогами. Це об'єктивні, автоматизовані міри інженерної повноти, а не суб'єктивні оцінки якості документів.

Зниження неоднозначності — ще одна головна перевага. Вимоги природною мовою є неодмінно неоднозначними — одне речення може по-різному прочитати системний інженер, що його написав, програмний інженер, що його реалізує, і тест-інженер, що його перевіряє. Коли вимога повинна бути виражена як елемент SysML Requirement із конкретним виділенням інтерфейсу, конкретним параметричним обмеженням і конкретним тест-кейсом, неоднозначність виходить назовні. Якщо команда моделювання не може погодитися, як представити вимогу в моделі, вони виявили справжню неоднозначність у вимозі, яку потрібно вирішити до початку реалізації, а не після.

SysML для оборонних систем

SysML (Systems Modeling Language) — це стандартна мова OMG для MBSE. Вона розширює UML типами діаграм, спеціально розроблених для системної інженерії: Block Definition Diagrams, Internal Block Diagrams, Requirement Diagrams, Parametric Diagrams та Allocation Tables. Розуміння того, які типи діаграм приносять реальну користь в оборонному контексті — а які споживають зусилля без пропорційного результату — є ключовим для продуктивної MBSE-програми.

Block Definition Diagrams (BDD) є найціннішим SysML-артефактом для оборонних систем. BDD визначає структурну таксономію системи: які блоки існують, які властивості й операції вони мають, як вони спеціалізуються через зв'язки узагальнення, та які типізовані порти вони відкривають для підключення до інших блоків. У контексті системи озброєння BDD відповідає на питання: які підсистеми, які їхні зв'язки декомпозиції і які типи інтерфейсів між ними? BDD — це не малюнок, це формальне структурне визначення, з якого походять усі подальші артефакти. Тип інтерфейсу, визначений на порті BDD, є авторитетною специфікацією цього інтерфейсу; ICD є генерованим звітом з нього.

Internal Block Diagrams (IBD) показують, як екземпляри блоків з'єднані для конкретного контексту. Там де BDD визначає тип «Підсистема сенсора має порт типу DataLink», IBD показує конкретне з'єднання DataLink між екземпляром підсистеми сенсора та екземпляром місійного комп'ютера в збірці системи верхнього рівня. IBD — основні архітектурні діаграми для інженерів з інтеграції: вони точно вказують, що з чим з'єднується, через який тип порту, на якому рівні збірки системи. Генеровані ICD, похідні від IBD, є внутрішньо узгодженими між підсистемами — властивість, яку неможливо гарантувати при незалежному веденні ICD.

Activity Diagrams моделюють поведінку системи у термінах дій та потоку керування. В оборонному контексті вони найкорисніші для послідовностей виконання місії (послідовність кроків від планування місії через виконання до пост-місійного аналізу), для специфікації поведінки критично безпечних режимів та для визначення операційного робочого процесу, який система повинна підтримувати. Activity Diagrams стають надмірно складними при застосуванні до низькорівневих програмних алгоритмів — такий рівень деталізації належить програмному проєктуванню, а не системній архітектурі.

Sequence Diagrams моделюють обмін повідомленнями між компонентами системи в часі. Вони цінні для специфікації безпечних протоколів (автентифікаційні рукостискання, послідовності обміну ключами), чутливих до часу протоколів координації (синхронізація системи управління вогнем між сенсором, C2 та виконавчим елементом) та послідовностей взаємодії людини і системи для критично безпечних операцій. Sequence Diagrams є поганим вибором для моделювання основної маси поведінки системи — комбінаторний вибух варіантів послідовностей робить їх непідтримуваними у великому масштабі. Зарезервуйте їх для 5–10% поведінок, де точний порядок між-компонентних повідомлень є архітектурно значущим.

Parametric Diagrams унікально цінні для оборонних систем, де обмеження продуктивності повинні розподілятися та відслідковуватися. Параметрична діаграма виражає математичні обмеження між властивостями блоків — наприклад, обмеження, що наскрізна затримка рішення про ціль є сумою затримки захоплення сенсора, затримки обробки та затримки зв'язку, і що загальна сума повинна бути менше 500 мс. Ці обмеження можна пов'язати з параметрами симуляції та оцінювати за фактичними вимірюваннями під час інтеграційного тестування, створюючи процес верифікації продуктивності на основі моделі.

Що не слід моделювати: уникайте створення sequence diagrams або activity diagrams для кожної функції системи. Надмірне моделювання створює навантаження на підтримку, що перевищує переваги від простежуваності. Моделюйте структуру архітектури вичерпно (BDD та IBD); моделюйте поведінку вибірково, зосереджуючись на безпечно-критичних, безпечно-критичних та архітектурно значущих взаємодіях.

Моделювання вимог і простежуваність

Простежуваність вимог — це можливість, яка найбільш послідовно виправдовує інвестиції в MBSE в оборонних програмах. Дисципліна управління вимогами в оборонному ПЗ еволюціонувала від матриць простежуваності на основі електронних таблиць до інтегрованої у модель простежуваності, де самі зв'язки є першокласними елементами моделі з семантичними типами.

У SysML простежуваність вимог реалізована через чотири типізовані залежності:

• «derive» — з'єднує системну вимогу із потребою зацікавленої сторони або вимогою вищого рівня, яку вона уточнює. Кожна системна вимога повинна мати принаймні один зв'язок «derive»; вимога без нього є або невиправданою, або її потреба зацікавленої сторони не змодельована.
• «satisfy» — з'єднує елемент архітектури (Block, Component, Interface) із вимогою, яку він задовольняє. Це основний зв'язок простежуваності: він відповідає на питання «яка частина системи задовольняє цю вимогу?». Розподілена вимога без зв'язку «satisfy» є нереалізованою.
• «verify» — з'єднує тест-кейс або тестову процедуру з вимогою, яку вона верифікує. Вимога із зв'язком «satisfy», але без зв'язку «verify», спроєктована, але не верифікована — прогалина, яку в документо-центричній програмі виявили б на TRR, але в моделі вона видима постійно.
• «refine» — з'єднує більш детальний елемент моделі (наприклад, машину станів або activity diagram) з вимогою, яку він розробляє. Використовується, коли вимога задовольняється поведінковою специфікацією, а не безпосередньо структурним елементом.

Матриця розподілу — яку більшість інструментів MBSE генерує як інтерактивний звіт — представляє вимоги проти елементів архітектури у таблиці перехресних посилань, де кожна клітинка вказує, чи існує зв'язок «satisfy». Ця матриця замінює матрицю простежуваності у вигляді електронної таблиці, що є центром доказів відповідності у документо-центричному підході. На відміну від таблиці, матриця, отримана з моделі, завжди актуальна: вона генерується з живої моделі, а не оновлюється вручну.

Ієрархія від потреб зацікавлених сторін до системних вимог заслуговує особливої уваги. Оборонні програми отримують потреби зацікавлених сторін з кількох джерел: операційного користувача (виражені в Концепції операцій), органу закупівель (виражені в Специфікації продуктивності системи) та похідних внутрішніх вимог (виражені в ICD підсистем і специфікаціях нижнього рівня). Моделювання всіх цих джерел як ієрархії вимог у SysML робить обґрунтування деривації явним: конкретна системна вимога існує, оскільки задовольняє конкретну операційну потребу, яка, в свою чергу, задовольняє конкретну місійну вимогу з ConOps. Коли системна вимога оскаржується — як це часто трапляється при скороченні витрат програми — модель показує саме, які операційні потреби залишаться незадоволеними при видаленні вимоги, надаючи головному системному інженеру структуровану основу для прийняття компромісного рішення.

-- SysML 2.0 textual notation: фрагмент ієрархії вимог
requirement def MissionCommunicationsNeed {
    doc /* Система повинна підтримувати канал зв'язку
         з вузлом C2 протягом усього конверту місії. */
}

requirement def DataLatencyRequirement :> MissionCommunicationsNeed {
    doc /* Наскрізна затримка голосу/даних від джерела до вузла
         C2 не повинна перевищувати 500 мс за будь-яких умов. */
    assume constraint { latencyBudget <= 500 [ms] }
}

requirement def LinkAvailabilityRequirement :> MissionCommunicationsNeed {
    doc /* Доступність каналу зв'язку повинна перевищувати
         99,5% у середньому за будь-який 24-годинний місійний період. */
}

Текстова нотація SysML 2.0, показана вище, ілюструє ієрархію деривації: DataLatencyRequirement та LinkAvailabilityRequirement є спеціалізаціями потреби зацікавленої сторони, успадковуючи її контекст та конкретизуючи вимірювані критерії приймання. Параметричне обмеження (latencyBudget <= 500 [ms]) є формальною властивістю, яку можна пов'язати з параметрами симуляції та виміряними результатами тестів, а не лише реченням, яке тест-інженери повинні інтерпретувати.

Цифровий ланцюжок: безперервність від моделі до прототипу

Цифровий ланцюжок — це пов'язаний ланцюжок даних, що з'єднує елементи моделі з їхніми подальшими реалізаціями та результатами верифікації. У контексті оборонної MBSE цифровий ланцюжок має три головні ланки: генерація коду з моделі, автоматизація тестування з моделі та симуляція з моделі.

Генерація коду з моделі є найзрілішою ланкою цифрового ланцюжка. IBM Rhapsody забезпечував генерацію коду C та C++ з машин станів і діаграм класів UML/SysML протягом двох десятиліть. Cameo інтегрується з перетвореннями SysML-to-Ada та SysML-to-C++. Генерований код є скелетом або фреймворком: модель визначає структуру інтерфейсу, переходи машини станів та типи даних; інженери реалізують обчислювальний зміст у тілах генерованих методів. Цінність полягає в узгодженості інтерфейсів: якщо SysML BDD вказує, що вихідний порт блоку несе структуру типу TargetTrack_t з полями position, velocity та classification, генеровані заголовкові файли з обох сторін кожного інтерфейсу, що використовує цей тип, є ідентичними. Клас дефектів інтеграції, спричинених двома інженерами, що незалежно інтерпретують текстовий опис ICD і приходять до дещо різних макетів структури, структурно виключений.

Автоматизація тестування з моделі з'єднує елементи SysML TestCase з фреймворками виконання тестів. У найзрілішому впровадженні тест-кейс у моделі специфікує: вимогу, яку він верифікує (через «verify»), входи до системи, що тестується (похідні від критеріїв приймання вимоги), очікувані виходи (похідні від положення «shall» вимоги) та критерій прийому/відхилення. З цих елементів моделі генератор формує тест-скрипти у цільовому тест-фреймворку — Robot Framework для системного тестування, pytest для тестування компонентів або пропрієтарні HIL-скриптові мови для апаратної інтеграції. Коли вимога змінюється, генератор повторно запускається і позначає тест-кейси, чиї очікувані виходи тепер несумісні з оновленою вимогою, замість того, щоб чекати, поки людина помітить розбіжність на TRR.

Симуляція з моделі (MBSE + SIL/HIL) — ланка цифрового ланцюжка з найвищою потенційною цінністю та найвищою складністю реалізації. SysML parametric diagrams визначають математичну структуру моделі продуктивності системи — які фізичні параметри обмежують які властивості продуктивності, виражені як constraint blocks. Ці constraint blocks можна пов'язати з симуляційними моделями Simulink або Modelica через інтеграції інструментів MBSE (інтеграція Cameo-MATLAB, ко-симуляція Rhapsody-Simulink). Результат — конфігурація симуляції, що є похідною від архітектурної моделі, а не підтримуваною паралельно з нею.

Практична зрілість цієї інтеграції суттєво варіюється. Синхронізація параметрів між моделлю та Simulink добре підтримується провідними постачальниками інструментів MBSE. Повна автоматизація тестування від моделі до HIL — коли зміна SysML-вимоги поширюється через модель на оновлені HIL-тест-скрипти без ручного втручання — вимагає значних зусиль інтеграційної інженерії та досягається менш ніж 15% оборонних програм, що заявляють про впровадження MBSE (за даними опитування INCOSE). Програми, що цього досягають, повідомляють про найбільш драматичне скорочення тривалості циклу інтеграційного тестування, як правило, на 35–50% коротші фази інтеграції порівняно з документо-центричними базовими лініями аналогічної складності системи.

Зв'язок між MBSE та формальною верифікацією оборонного ПЗ здійснюється через цифровий ланцюжок: поведінкові моделі SysML (машини станів, activity diagrams) можна транслювати у формальні мови специфікацій (TLA+, SPIN Promela) для перевірки моделей, надаючи математичні докази поведінкової коректності, що доповнюють структурну простежуваність, яку забезпечує MBSE-модель.

Архітектурні представлення DoDAF з моделі

Department of Defense Architecture Framework (DoDAF) версії 2.02 визначає обов'язкові архітектурні точки зору, які повинні виробляти програми оборонних закупівель для управління портфелем можливостей та оцінки взаємодії систем систем. У документо-центричних програмах представлення DoDAF виробляються як автономні діаграми Visio або слайди PowerPoint, оновлюються вручну перед кожним оглядом програми та хронічно не синхронізовані з інженерною моделлю, яка представляє фактичне проєктування системи.

MBSE усуває ручні зусилля з виробництва DoDAF, роблячи представлення DoDAF генерованими виходами інженерної моделі. Відображення від елементів SysML-моделі до елементів даних DoDAF стандартизовано у Unified Profile for DoDAF and MODAF (UPDM), який підтримується як плагін або нативний профіль у всіх основних інструментах MBSE.

Ключові відображення DoDAF-до-SysML для оборонних програм:

• OV-1 (High-Level Operational Concept Graphic) — похідний від діаграми варіантів використання верхнього рівня системи у поєднанні з діаграмами активностей контекстного рівня, що показують операційне середовище. У моделі операційні середовищні актори, їхні взаємодії з системою та фази місії представлені як елементи варіантів використання та актора; OV-1 є стилізованим рендерингом цих елементів в операційному контексті, а не інженерній нотації.
• OV-2 (Operational Resource Flow Description) — похідний від конекторів IBD, анотованих операційними типами інформації. Коли типи конекторів IBD включають операційну семантику (конектор несе «тактичні дані цілевказівки», а не просто ім'я типу даних), OV-2 автоматично генерується з набору конекторів, відфільтрованих за анотацією операційного потоку.
• SV-1 (Systems Interface Description) — похідний безпосередньо від IBD верхнього рівня системи, що показує фізичні екземпляри блоків та їхні з'єднання. Це найпростіша генерація DoDAF-з-моделі: SV-1 по суті є системним IBD, відрендерованим із DoDAF-сумісною іконографією та легендою.
• SV-4 (Systems Functionality Description) — похідний від моделі активностей системи, що показує, які функції виконуються якими системними вузлами. У SysML це розподіл елементів активностей по екземплярах блоків, представлений у таблицях розподілу, що безпосередньо відображаються у зміст SV-4.
• TV-1 (Technical Standards Profile) — похідний від стандартних елементів моделі, де застосовні стандарти (MIL-STD-1553, Link 16, STANAG 4586) прикріплені як теговані значення або властивості стереотипів до елементів інтерфейсу та блоків, що їх реалізують.

Автопублікація до репозиторію даних DoDAF — такого як DoDAF Architecture Registry, інструмент корпоративної архітектури або програмно-специфічний репозиторій SharePoint/Confluence — підтримується через скриптові API інструментів MBSE. Щонічна автоматизована задача може регенерувати всі представлення DoDAF, публікувати їх до архітектурного репозиторію та ставити відмітку часу публікації, щоб рецензенти знали, що представлення відображають стан моделі попереднього дня. Це якісне покращення порівняно з представленнями DoDAF, що підтримуються виділеним архітектором, який оновлює їх перед оглядами — представлення, похідні від моделі, завжди актуальні, а їхній зміст є простежуваним до елементів інженерної моделі, а не до інтерпретації проєкту архітектором.

Екосистема інструментів MBSE для оборони

Екосистема інструментів MBSE для оборони має три основні варіанти, кожен з відмінними сильними сторонами, що відповідають різним програмним контекстам.

Cameo Systems Modeler (Dassault Systèmes, колишній No Magic) є домінуючим інструментом MBSE на оборонному ринку США. Його сильні сторони — вичерпна відповідність SysML 1.x, зріла підтримка профілів DoDAF/UPDM, багата екосистема плагінів, включаючи Cameo Simulation Toolkit для параметричної симуляції, та Teamwork Cloud для масштабованого багатокористувацького колаборативного моделювання з тонким контролем доступу. Cameo використовується більшістю провідних американських підрядників у великих програмах закупівель. Його слабкі сторони — вартість (корпоративні ліцензії дорогі), крута крива навчання для інженерів без попереднього досвіду моделювання та обмежена нативна підтримка текстової нотації SysML 2.0 (очікується у циклі виходу версій 2026–2027). Для програм, де відповідність DoDAF та сумісність з провідними американськими підрядниками є першочерговими вимогами, Cameo є вибором за замовчуванням.

IBM Rhapsody є основним інструментом, коли генерація коду з моделі є першочерговою вимогою програми. Генерація коду Rhapsody з машин станів UML/SysML є найбільш зрілою в галузі, а його інтеграція з IBM Rational DOORS для управління вимогами через IBM Systems Design Rhapsody Model Manager створює зрілий конвеєр простежуваності від вимог DOORS до елементів моделі Rhapsody та генерованого коду. Rhapsody є основним інструментом для розробки вбудованого авіаційного ПЗ у програмах, де команда моделювання генерує основну частину скелету ПЗ з моделі, а інженери завершують реалізацію в межах генерованих фреймворків. Підтримка DoDAF менш зріла, ніж у Cameo, а підтримка параметрів SysML слабша. Для програм із сильним мандатом на генерацію коду вбудованого ПЗ з моделі та існуючими інвестиціями в інструментальну базу IBM, Rhapsody є відповідним вибором.

Capella — інструмент MBSE з відкритим кодом, розроблений Thales і наразі підтримуваний у проєкті Eclipse Polarsys. Capella використовує метод моделювання ARCADIA, а не SysML — його ієрархія точок зору (Operational Analysis, System Analysis, Logical Architecture, Physical Architecture) не відповідає безпосередньо типам діаграм SysML, але природно відображається на фази оборонного закупівельного циклу. Метод ARCADIA має дисципліновану послідовність опрацювання архітектури, яка спрямовує команди моделювання через правильний порядок архітектурних рішень, зменшуючи методологічну неоднозначність, що характерна для SysML-програм, де інструмент надає можливості, але не методологічне керівництво. Capella має нульову вартість ліцензії, що робить його доступним для програм з обмеженим бюджетом, менших підрядників та академічних/навчальних контекстів. Доповнення забезпечують генерацію представлень DoDAF та ко-симуляцію Simulink/FMI. Для європейських оборонних програм — особливо тих у французькій та британській оборонно-промисловій базі, де сильний вплив Thales — Capella є дедалі більш стандартним вибором.

Кваліфікація інструментів для розробки, критичної з точки зору безпеки, — це міркування, що застосовується незалежно від вибору інструменту. Будь-яка функція інструменту MBSE, що використовується для генерації артефактів, які розглядаються як докази відповідності — генерований код, генеровані тест-скрипти, генеровані звіти про верифікацію — повинна бути кваліфікована відповідно до DO-330 (для авіаційних програм) або застосовного стандарту кваліфікації програмних інструментів програми. Кваліфікація інструментів, як правило, не потрібна для функцій моделювання та простежуваності інструментів MBSE, оскільки інженери переглядають генеровані представлення перед використанням. Вона потрібна, коли вихід інструменту використовується без незалежного перегляду — зокрема, для генераторів коду та генераторів тест-скриптів, що заявляються як кредит інструменту DO-178C.

Інструмент	Основна сильна сторона	Підтримка DoDAF	Модель ліцензування	Найкраще підходить для
Cameo Systems Modeler	Відповідність SysML, DoDAF/UPDM, колаборація	Зріла (плагін UPDM)	Комерційна (висока вартість)	Програми закупівель Міноборони США, провідні підрядники
IBM Rhapsody	Генерація коду з моделі, вбудовані системи	Помірна	Комерційна (висока вартість)	Вбудована авіаційна електроніка, ПЗ-інтенсивні системи
Capella (Eclipse)	Метод ARCADIA, нульова вартість ліцензії	Через доповнення	Відкритий код (безкоштовно)	Європейська оборона, програми з обмеженим бюджетом

Виклики впровадження та отримані уроки

Впровадження MBSE в оборонних програмах частіше зазнає невдачі через організаційні фактори, ніж технічні. Інструменти зрілі, методи добре задокументовані, а докази ROI суттєві. Те, що зриває MBSE-програми, — це організаційний опір, провал управління моделлю та нездатність виміряти та продемонструвати ROI у спосіб, що підтримує прихильність керівництва протягом початкового періоду накладних витрат.

Організаційний опір моделюванню проявляється у двох формах. Перша — на основі навичок: системні інженери, навчені виробляти документи у Word і Visio, автоматично не стають кваліфікованими MBSE-моделювальниками після дводенного курсу SysML. Вони знають нотацію, але не метод — вони не знають, як декомпозувати систему на правильні блоки, як вирішити, що належить поведінковій моделі, а що належить текстовій вимозі, або як підтримувати узгодженість моделі в міру еволюції проєкту. Адекватне навчання MBSE становить 40–80 годин на інженера для початкового рівня кваліфікації плюс 6–12 місяців наставництва в рамках першої програми. Програми, що пропускають ці інвестиції і очікують, що інженери самонавчаться з документації інструменту, послідовно виробляють моделі, структурно правильні, але методологічно хибні — діаграми в інструменті моделювання без жодних зв'язків простежуваності, що не надають жодної цінності аналізу впливу змін, яка виправдовує інвестиції в інструмент.

Друга форма опору — культурна: старші інженери, що реалізовували успішні програми документо-центричними методами, сприймають MBSE як накладні витрати, нав'язані керівництвом, а не як можливість, що полегшує інженерну роботу. Це сприйняття не є повністю хибним у короткостроковій перспективі — перші 6 місяців MBSE на новій програмі справді є більшими накладними витратами, ніж документо-центричний еквівалент, оскільки інфраструктура моделі (управління, інструменти, репозиторії, шаблони) повинна будуватися паралельно з інженерною роботою. ROI стає позитивним на першому великому циклі ECP, як правило, через 12–18 місяців програми, коли аналіз впливу змін на моделі займає години замість тижнів. Програми, що відмовляються від MBSE до досягнення цієї точки перегину, несуть витрати без отримання переваг.

Провал управління моделлю є найпоширенішою технічною причиною невдачі MBSE-програми. Без визначеного права власності на модель, умов іменування елементів моделі, розкладу базової лінії, прив'язаного до віх програми, та процесу CCB для контрольованих елементів моделі, модель накопичує локальні варіації. Інженери створюють власні пакети, щоб уникнути координаційних накладних витрат. «Авторитетна» модель розходиться з інженерною реальністю, що фактично проєктується. Протягом 18 місяців програма фактично знову стає документо-центричною — інженери підтримують реальний проєкт в окремих документах і оновлюють модель перед оглядами програми для задоволення контрактних вимог.

Ефективне управління моделлю вимагає явного визначення: хто є власником кожного пакету моделі (за ім'ям, а не лише за роллю), яке затвердження потрібне для зміни елементу базової лінії, як розклад базової лінії моделі узгоджується з PDR/CDR, та які метрики покриття моделі звітуються на кожному огляді програми. Ці правила повинні бути задокументовані в SEMP та дотримуватися керівництвом програми — Головний системний інженер повинен ставитися до несанкціонованої зміни елементу моделі базової лінії з такою ж серйозністю, як до несанкціонованої зміни креслення базової лінії CDR.

Вимірювання ROI від MBSE є постійним викликом, оскільки переваги здебільшого є уникненими витратами від проблем, що не відбуваються. Дефекти інтерфейсів, яким запобіг типо-узгоджений IBD моделі, ніколи не були виявлені — їхня відсутність невидима. Безсуб'єктні вимоги, що їх виявили перевірки узгодженості моделі до CDR, ніколи не стали розбіжностями CDR — тому в метриках програми немає рядка, що показує витрати, які вони б спричинили. Програми, що успішно демонструють ROI від MBSE, роблять це, встановлюючи базові лінії до впровадження MBSE і вимірюючи конкретні метрики після: людино-години аналізу впливу змін на ECP, дефекти інтерфейсу, виявлені під час інтеграційного тесту на інтерфейс, людино-години виробництва DoDAF на великий огляд та розбіжності входу в CDR на кількість вимог. Без базових ліній до MBSE для цих метрик аргумент ROI спирається на галузеві орієнтири, а не на доказову базу програми — і цей аргумент менш переконливий для менеджерів програм, чий бюджетний тиск є негайним і конкретним.

Програми, що послідовно досягають позитивного ROI від MBSE, мають три спільні характеристики: вони починають MBSE на початку програми, а не ретрофітують її на існуючу документо-центричну програму; вони інвестують в інфраструктуру управління моделлю до початку моделювання, а не виявляють прогалини в управлінні на PDR; і вони вимірюють та звітують метрики покриття моделі (покриття розподілу вимог, рівень формалізації інтерфейсів, рівень зв'язування тестів) на кожному огляді програми, роблячи інженерну повноту моделі настільки ж видимою, як розклад і бюджет.

MBSE — це не програмний інструмент, це інженерна дисципліна, яку забезпечують програмні інструменти. Оборонні програми, що розуміють цю відмінність, інвестують в організаційні зміни, яких вона потребує, та підтримують дисципліну управління протягом усього життєвого циклу програми, послідовно виявляють, що цифровий ланцюжок від потреби зацікавленої сторони до верифікованої продуктивності системи вартий інвестицій.