NASA поєднала SysML v2 з керуванням відмовами автономних місій

NASA показала спосіб проєктувати автономні космічні системи так, щоб керування відмовами не додавалося наприкінці як окремий «пластир». Моделі SysML v2 пов’язали з аналізом відмов, деревами помилок і рекомендаціями щодо архітектури. Підхід перевірили на ранній моделі місії HelioSwarm із дев’яти супутників.

Проблема пізнього керування відмовами

Для далекої місії оператор не завжди може миттєво втрутитися. Бортове програмне забезпечення має виявити несправність, визначити її наслідки та перейти у безпечний або резервний режим. Проте команди системного проєктування й спеціалісти з system health management часто використовують різні моделі та сховища знань.

Коли логіку Fault Management додають після завершення основного дизайну, вона змушена компенсувати вже закладені архітектурні слабкості. Це ускладнює перевірку вимог, породжує неузгоджені припущення й робить зміни дорогими. NASA профінансувала розширення інструментів Qualtech Systems, щоб аналіз відмов став частиною model-based systems engineering від початку проєкту.

Як поєднали SysML v2 та аналіз відмов

Команда додала поняття Fault Management до моделей SysML v2 і реалізувала перетворення системної моделі у представлення «простору відмов» інструментів TEAMS. На основі причин і наслідків несправностей система може формувати Failure Modes, Effects, and Criticality Analysis та Fault Tree Analysis.

Практична цінність полягає не у ще одному форматі звіту. Аналіз повертається назад у проєктування: інструмент може запропонувати місце додаткового сенсора, показати слабку точку діагностики або допомогти порівняти кілька архітектур резервування. Результат експортується у стандартизований SysML-звіт, щоб ним могли користуватися не лише фахівці конкретного пакета.

Головна зміна процесу: відмовостійкість оцінюють у контексті сценаріїв роботи системи ще до того, як конструкцію та програмні інтерфейси зафіксовано.

Демонстрація на HelioSwarm

Місія HelioSwarm використовуватиме центральний апарат і вісім малих супутників. Вони одночасно вимірюватимуть магнітні коливання та потоки протонів у різних масштабах. Для автономності це складний випадок: потрібно координувати живлення, орієнтацію, рух, тепловий режим, розділення апаратів, наукові сенсори та канали зв’язку.

Дослідники побудували SysML v2-модель верхньорівневих вимог і ключових підсистем HelioSwarm, перетворили її на модель відмов, а потім сформували FMECA та дерева помилок. Аналіз створив пропозиції щодо змін, зокрема розміщення сенсорів, і повернув їх до системного дизайну.

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

Практичні уроки для інженерних команд

• Єдині ідентифікатори важливіші за красиві діаграми. Вимога, компонент, сенсор, сценарій і режим відмови мають простежуватися між моделями та звітами.
• Перетворення моделей потрібно тестувати. Втрачене обмеження або неправильний зв’язок у генераторі може зробити FMEA переконливою, але хибною.
• Рекомендації не замінюють рев’ю. Автоматично запропонований сенсор чи резервування слід оцінювати з урахуванням маси, енергії, вартості й нових точок відмови.
• Сценарії мають містити деградовані режими. Успішна робота в номінальному стані не показує, чи збережеться головна функція після часткової несправності.

Обмеження демонстрації

NASA описує ранню модель HelioSwarm і результати інженерного аналізу, а не автономне відновлення вже запущеного угруповання. Ефективність підходу ще залежить від повноти моделі, якості бібліотеки відмов і відповідності між SysML та реальним програмним забезпеченням. Крім того, TEAMS є комерційним продуктом, тому командам варто заздалегідь перевірити переносимість моделей, формат експорту та ризик прив’язки до постачальника.

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

Джерело та права

Матеріал є самостійним українським перекладом-переказом технологічної публікації NASA Science від 25 серпня 2026 року. Автор — Andrew Dollar, редактор — NASA Science Editorial Team. Використано зображення HelioSwarm із домену NASA, не позначене окремим стороннім copyright. За правилами NASA щодо медіа матеріали агентства зазвичай не охороняються авторським правом у США, якщо не вказано інше. Перекладено, адаптовано та доповнено редакцією «Бібліотеки програміста»; NASA не схвалювала цю адаптацію.