DeftechSenior

ПЗ для дронів

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

Стек упорядкований за
Дедлайнами, не шарами
Звʼязок —
Вхід, а не залежність
Специфікація —
Драбина відмовостійкості

Стек є ієрархією дедлайнів

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

Політний стек найкраще читати як ієрархію дедлайнів, а не абстракцій. Політний контролер тримає апарат у повітрі на циклі жорсткого реального часу в мілісекундах; йому не можна чекати ні на що — тому він малий, детермінований і майже ніколи не є місцем для нових фіч. Автопілот над ним перетворює місію на завдання швидкості й курсу з меншою частотою. Бортовий компʼютер виконує все, що може дозволити собі спізнитися: сприйняття, планування, роботу з відео, — і його падіння не повинне дійти до ярусу нижче. Наземну станцію намальовано свідомо як вхід, а не як залежність, бо звʼязок зникне, а апарат усе одно мусить поводитися. Саме тому справжньою специфікацією є драбина відмовостійкості, а не логіка місії: що станеться, коли зникне звʼязок, коли втратиться позиція, коли сяде батарея, коли досягнуто межу. Ці чотири відповіді й відрізняють демонстрацію від того, чим можна літати.
  • Політний контролер

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

  • Автопілот

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

  • Бортовий компʼютер

    Звичайний компʼютер зі звичайним ПЗ: сприйняття, планування, відео, звʼязок. Він може спізнюватися й може падати, і ні те, ні те не має дійти до ярусів нижче.

Драбина відмовостійкості — це і є специфікація

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

УмоваРозумна поведінкаОбмін, який вона робить
Втрачено канал керуванняПродовжувати поточну місію визначений час, потім повертатися чи сідатиНегайне повернення марнує більшість вильотів, бо звʼязок зникає рутинно. Ніколи не повертатися — втратити апарат.
Втрачено визначення позиціїУтримувати позицію за інерціальною та візуальною оцінкою, потім знижуватися чи повертатися за числення шляхуЧислення шляху дрейфує. Що довше йому вірити, то далі ви від того місця, де себе вважаєте.
Низький зарядПовертатися зараз, порахувавши від відстані додому, а не від фіксованого відсоткаФіксований поріг хибний з обох боків: зарано біля дому й надто пізно на відстані та проти вітру.
Досягнуто географічну межуВідмовитися її перетинати, хоч що просить місія чи операторЦе має забезпечувати автопілот, а не наземне ПЗ, — інакше це порада, а не межа.
Бортовий компʼютер перестав відповідатиПовернутися до останнього дійсного режиму автопілота й далі летіти без ньогоАпарат втрачає розумну поведінку й далі летить — і це правильний порядок пріоритетів.

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

Автономність — це набір конкретних рішень, а не рівень

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

Вирішувати на борту

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

Утримати й спитати

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

У правого стовпця є наслідок для проєкту, який часто пропускають: щоб утримати рішення, апарат мусить уміти безпечно чекати. Система, яка має спитати людину, але не може зависнути, не може зберегти запит і не може розумно поводитися, якщо відповіді не буде, не реалізувала вимогу — вона її записала. Чекання є здатністю з власним бюджетом енергії, власною поведінкою при тайм-ауті й власною відмовостійкістю.

Симуляція є тестовим середовищем, а не зручністю

Кожен важливий тут випадок збою — це те, чого не відтвориш на справжньому апараті: втрата позиції на двохстах метрах, зупинка мотора в розвороті, зникнення звʼязку на дальньому кінці маршруту, батарея з хибним показанням. Літати такі тести дорого, небезпечно й повільно, а ті, які пережив, не повториш однаково. Тож головним тестовим середовищем є симулятор, і зрілість симуляційного стенду добре описує зрілість команди.

  • Software in the loop: справжня прошивка автопілота працює на робочій станції проти змодельованого планера й змодельованих сенсорів. Достатньо швидко для запуску на кожен коміт — саме це робить її регресійним набором, а не експериментом.
  • Hardware in the loop: справжня плата політного контролера з справжньою прошивкою, підключена до симулятора замість моторів. Саме тут зʼявляються проблеми таймінгу й баги драйверів, невидимі попередньому рівню.
  • Ін’єкція збоїв як повноцінні тест-кейси: обірвати звʼязок, заморозити сенсор, зсунути годинник, підмінити показник батареї, заклинити мотор. Кожен — скриптований кейс у наборі, а не ручний експеримент, який хтось колись зробив.
  • Відтворення зі справжніх польотів: кожен політ дає лог, а лог є вхідними даними тесту. Баг, побачений раз у повітрі, стає кейсом, що житиме завжди, — це те саме правило, що й у будь-якому регресійному наборі.

Антипатерни, які варто назвати

  • Класти нову логіку в політний контролер, бо він «ближче до заліза»: ви міняєте єдиний детермінований компонент на фічу.
  • Давати бортовому компʼютеру владу замість каналу запитів: падіння сприйняття стає падінням апарата.
  • Забезпечувати межу в наземній станції — компоненті, який гарантовано відсутній, коли це важить.
  • Тестувати лише місію й ніколи відмовостійкості: перша справжня втрата звʼязку стає першим виконанням того шляху коду.
  • Вважати політний лог артефактом лише для розбору інцидентів, а не входом для постійного тест-кейса.

Коли це застосовувати

Застосовуйте, коли

  • Коли вирішуєте, що належить політному контролеру, автопілоту й бортовому компʼютеру: вирішує дедлайн, а не мова.
  • Коли пишете чи переглядаєте конфігурацію відмовостійкості — частину специфікації, що вирішує придатність до польоту.
  • Коли визначаєте автономність як список рішень, які апарат ухвалює сам, і тих, які утримує й питає.
  • Коли будуєте тестове середовище: спершу симуляція, далі hardware in the loop, повітря — востаннє й рідко.

Уникайте, коли

  • Як джерело деталей про сприйняття чи моделі: це належить компʼютерному зору, і ця сторінка свідомо туди не заходить.
  • Як настанову щодо спільної оперативної картини — це сторінка C2; ця закінчується апаратом і його каналом.
  • Як привід проєктувати під сильний звʼязок: кожна поведінка, що від нього залежить, є неперевіреною, доки він не зникне.
  • Для системи, де людина справді завжди присутня й реагує: тутешні обмеження були б зайвим тягарем.

Було корисно?

Поділіться з тим, хто працює над тією ж задачею.