Що залишається можливим після відмови?
Коли складна система втрачає частину обладнання, це не завжди означає кінець її роботи. Питання в іншому: що вона ще здатна робити, чому можна довіряти і чи безпечно змінювати спосіб її роботи?
Точне наукове формулювання цієї програми
Фреймворк живучості — Цей розділ збирає математичне ядро дисертації в послідовний фреймворк: від деградованого об’єкта керування та метрики живучості до простору трансформацій, часових обмежень і політики еволюції.
Коли зламалася техніка, змінилася мета — і спосіб її досягнення.
Після аварії Apollo 13 посадка на Місяць стала неможливою. Місячний модуль, призначений для іншого завдання, використали як тимчасову систему життєзабезпечення екіпажу. Ресурси були обмежені, тому від частини функцій відмовилися заради найважливішого — повернення людей.
Це історичний приклад перепризначення ресурсів, а не перевірка нашого алгоритму. Саме такі випадки допомагають зрозуміти запитання, яке ставить дисертація: як визначити, що залишилося можливим, і як обрати безпечне продовження роботи?
Детальний розбір Apollo 13 у кейсах ↗Чотири запитання замість одного «працює чи ні?»
Уявімо автономний робот, у якого відмовив привід. Він не стає автоматично придатним до роботи — але й не обов’язково втрачає всі можливості. Потрібна послідовна перевірка.
- 01
Що втрачено?
Визначити несправні та ослаблені ресурси: приводи, датчики, живлення й обчислювачі.
- 02
Чому ще можна довіряти?
Перевірити не лише обладнання, а й моделі та оцінки, за якими система приймає рішення.
- 03
Що ще дозволено?
Відкинути варіанти, які фізично неможливі або порушують вимоги безпеки.
- 04
Як діяти далі?
Обрати не просто наступний режим, а допустиму послідовність змін із часовими обмеженнями.
Робот — пояснювальний приклад, а не результат окремого експерименту.
Тепер цю ідею можна вимірювати.
У дисертації введено кількісну міру живучості S(t): вона узагальнює, яку частину важливих для місії функціональних можливостей система зберігає в поточній конфігурації. Оцінка враховує не тільки наявність функцій, а й стан ресурсів, що їх забезпечують.
Математична модель: дисертація, §2.6. Облік валідності моделей: §2.7. Умови переходів: §2.8. Планування траєкторії: §3.6.
Відкрити пояснення математичної моделі ↗Це нормована оцінка спроможності за визначеною моделлю, а не ймовірність того, що система точно виживе.
Сім частин фреймворку — від першого запитання до рішення
Тут починається поглиблене читання. Кожна частина має власну сторінку; порядок відповідає логіці дисертації, а технічні деталі можна відкривати поступово.
Після відмови система вже не є номінальною.
Номінальний об’єкт P0 після пошкодження переходить у Pd. Від цього моменту керування та реконфігурація мають спиратися на реальний деградований об’єкт, а не на проектну ідеалізацію.
Чотирирівнева ієрархія: ресурс → сервіс → функція → місія.
Ядро фреймворку — конструктивний зв’язок між ресурсами, сервісами, функціями і місією. Саме він робить живучість обчислюваною величиною S(t).
Спроможність і допустимість — це не одне й те саме.
Фреймворк розділяє структуру конфігурації Φ(cfg), її паспортну межу S̄(cfg) і поточну живучість S(t). Коректне рішення супервізора виникає лише з урахуванням усіх трьох.
Валідність моделі — теж ресурс.
Фреймворк вводить епістемічні ресурси: моделі, оцінювачі, ідентифікатори та навчені політики, валідність яких треба контролювати так само, як і фізичний стан.
Реконфігурації утворюють простір трансформацій, а не список реакцій.
Кожна допустима конфігурація є вершиною графа, а дозволений перехід — його ребром. Так реконфігурація стає задачею руху по графу еволюції.
Часові обмеження незалежні: задача, реакція, послідовність.
Фреймворк має пройти три незалежні часові перевірки: локальні дедлайни задач, наскрізний бюджет реакції і мінімальний час перебування між реконфігураціями.
Планувати треба траєкторію, а не лише наступний вузол.
Якщо конфігурація має лишатися допустимою протягом усього інтервалу перебування, задача переходить від однокрокового вибору до вибору політики еволюції.
Як читати цей розділ
Матеріал побудовано безпосередньо на основі §§2.6–2.8, §3.6, §§4.2, 4.9–4.10 дисертації.
Швидкий маршрут
01 → 03 → 06
Що змінюється після відмови, як вимірюється живучість і які часові умови не можна порушити.
Теоретичний маршрут
02 → 04 → 05 → 07
Ієрархія, епістемічні ресурси, граф еволюції та політика траєкторії.
Маршрут до реалізації
02 → 06 → Реалізація
Від абстракції до модулів і часової перевірки.
Розгорнути технічні схеми та ранні представлення моделі
Ці схеми залишено для простеження розвитку ідей. Деякі умовні позначення належать попереднім редакціям моделі; поточні означення живучості та допустимості наведено в розділах 2.6–2.8 дисертації.
Фреймворк живучості
Цей розділ збирає математичне ядро дисертації в послідовний фреймворк: від деградованого об’єкта керування та метрики живучості до простору трансформацій, часових обмежень і політики еволюції.
Від моделі до доказів
Фреймворк пояснює, як міркувати про живучість. Публікації, монографія та зареєстровані НДР показують, з яких дослідницьких напрямів ця модель виросла.