Як організовано реконфігурацію системи
Шість модулів ROS2-фреймворку, каталог конфігурацій і три незалежні часові обмеження. Структура та результати аналізу наведені в розділі 4 дисертації.
§ 4.2–4.7 · АРХІТЕКТУРА
Не лише перемикання. Повний контур керування.
Система працює з чотирма рівнями абстракції: місія → функція → сервіс → ресурс. Для оцінювання стану, ухвалення рішення, безпечного переходу й контролю стійкості у роботі описано шість модулів.
| Модуль | Відповідальність |
|---|---|
| HealthMonitor | Оцінювання стану фізичних ресурсів і вхідних діагностичних даних. |
| DecisionEngine | Вибір допустимої конфігурації за станом системи та вимогами місії. |
| ReconfigManager | Організація переходу між конфігураціями, Hot Standby і Rollback. |
| StabilityAnalyzer | Перевірка умов стійкості конфігурацій і переходів. |
| ConfigStore | Зберігання каталогу доступних і верифікованих конфігурацій. |
| SafetySupervisor | Незалежний контроль безпеки та недопустимих режимів. |
§ 4.10 · АНАЛІЗ РЕАЛЬНОГО ЧАСУ
Що показує часовий аналіз
Функціональна коректність не означає своєчасність. У дисертації перевірено плановість задач, час реакції на одну відмову та допустимість послідовних реконфігурацій.
| Властивість | Розрахунок / результат | Інтерпретація |
|---|---|---|
| Плановість задач | U = 0,396; межа 0,735 | Достатня умова плановості виконується для заданого набору задач. |
| Час відгуку | max R/D = 0,176 | У розрахунковій моделі всі задачі виконують свої терміни. |
| Реакція у DEGRADED | 54,80 мс; вимога 50 мс | Поточний часовий бюджет вимогу не виконує. |
| Переключення Hot Standby | 35 мс; необхідно ≤ 30,2 мс | Потрібне скорочення часу переключення, а не послаблення вимоги. |
Три незалежні умови: виконання термінів задач; наскрізний час реакції; мінімальний інтервал між повторними реконфігураціями (формула 4.106).
Джерело: Д. О. Гуменний, дисертація, § 4.2–4.7, § 4.10.3–4.10.6, формули (4.98)–(4.106). Значення стосуються визначеної у дисертації моделі та аналізу; це не характеристика довільного апаратного виробу.
Програмний еталон, перевірки й апаратний шлях
Пов’язані інженерні матеріали. Заплановані етапи відділено від результатів, описаних у дисертації.
Чотири питання під час виконання.
Етап 2 починається лише після верифікації програмної моделі відносно математичної специфікації.
Референсне ПЗ: ядро C++ → ROS 2.
Моделі об’єкта, стану ресурсів, спроможності, рішення, стійкості та реконфігурації не залежать від ROS 2.
Планований апаратний шлях: RISC-V → SoC IP.
Обчислення спроможності, стійкості та нагляд за переходами переносяться з референсного ПЗ без зміни інтерфейсів.
Що треба довести до наступного етапу?
Реалізація має залишатися в заданих межах похибки відносно математичного еталонної моделі.