У батальйоні безпілотних систем бригади «Азов» Нацгвардії формується показова для всієї армії розвилка: логістичні наземні роботизовані комплекси (НРК) працюють на державній системі «Хмарка», тоді як ударний підрозділ під командуванням Михайла Малкуша переходить на повністю власне програмне забезпечення. Це не просто технічна деталь, а ознака того, як бойові задачі змушують військових відмовлятися від «стандартних» рішень і будувати свій софт під конкретну тактику.
Малкуш — колишній інженер і пілот, а нині командир підрозділу ударних НРК «Азову». Його команда спеціалізується саме на машинах, які мають уражати противника, а не лише підвозити вантажі. Ця спеціалізація диктує й інший підхід до програмного забезпечення: там, де для логістики достатньо уніфікованої державної платформи, для ударних роботів доводиться створювати власний стек.
Дві екосистеми в одній бригаді: «Хмарка» для логістики, кастомний софт для бою
У бригаді «Азов» уже склалася чітка межа між двома класами НРК — і вона проходить саме по лінії програмного забезпечення. Логістичні платформи, які займаються підвозом боєкомплекту, евакуацією поранених чи транспортуванням вантажів, працюють на державній системі «Хмарка». Це розробка Центру інновацій та оборонних технологій, фактично — офіційний державний софт для керування наземними роботами.
Для логістики це логічний вибір. Там важливі стандартизація, сумісність між різними підрозділами й виробниками, можливість швидко інтегрувати нові машини в уже існуючу інфраструктуру. «Хмарка» дає саме це: єдина платформа, на якій можуть працювати різні логістичні НРК, що надходять у війська за держзакупівлями.
Але ударний підрозділ Малкуша пішов іншим шляхом. Для бойових НРК команда розгорнула власне програмне забезпечення і свідомо відмовилася від «Хмарки» як основи. Причина не в тому, що державний софт «поганий» чи «недієздатний», а в тому, що для ураження цілей потрібна інша швидкість еволюції, інша гнучкість і інший рівень контролю над усіма елементами системи.
Ударні НРК у «Азові» — це не просто «та сама платформа, але з іншим вантажем». Це інший профіль ризику, інший темп роботи, інший набір сценаріїв: від глухої оборони, де робот має не пропустити піхоту противника, до рейдів по ворожих позиціях. Під ці задачі доводиться переписувати не лише тактику, а й софт.
Чому бойовим НРК не вистачає стандартних рішень
Коли Малкуш ще працював інженером і пілотом, він уже критикував загальну тенденцію ринку: виробники масово робили великі гусеничні платформи, тоді як на передовій потрібні були малі, дешеві, швидкі колісні НРК. За дев’ять місяців ситуація змінилася: з’явилися виробники, які дають більш-менш готові рішення, у тому числі з інтегрованим софтом. Частина підрозділів пішла в «Хмарку». Але ударний підрозділ «Азову» зупинився на власному ПЗ.
Це рішення виглядає радикальним лише на перший погляд. У бойовій роботі НРК програмне забезпечення — не «додаток до заліза», а фактично головний інструмент, який визначає, чи встигне машина виконати задачу до того, як її виявлять і знищать. Для ударних платформ критичними стають:
швидкість реакції системи керування;
гнучкість у налаштуванні під конкретну місцевість і сценарій;
можливість швидко змінювати інтерфейси, логіку роботи, режими безпеки;
інтеграція з каналами зв’язку, які постійно еволюціонують.
Стандартна державна платформа, орієнтована на широку номенклатуру логістичних НРК, неминуче буде більш консервативною. Її складніше «ламати» під експериментальні тактики, складніше оперативно змінювати, складніше ризикувати, коли мова йде про бойові інновації.
Власний софт дає підрозділу Малкуша можливість рухатися швидкістю стартапу, а не великої держструктури. Якщо потрібно змінити логіку керування, додати новий режим, підлаштуватися під інший тип платформи — це можна зробити в межах свого R&D, не чекаючи оновлень «згори» і не впираючись у обмеження універсальної системи.
Власний софт як відповідь на перехід до віддаленого керування
Ще один фактор, який тисне на архітектуру ПЗ, — це перехід до віддаленого керування НРК. У підрозділі Малкуша Starlink уже став фактичним стандартом зв’язку, а прямий радіоканал розглядається як технологія, що поступово відходитиме в минуле.
Starlink, за його оцінкою, «однозначно всіх переміг»: альтернативи зараз немає, і в найближчі роки її не видно. Як резерв розглядаються схеми з ретрансляторами в повітрі та зв’язком через LTE, але в будь-якому випадку все зводиться до мережевих каналів, а не до класичного прямого радіозв’язку.
Це змінює саму логіку програмного забезпечення для НРК. Якщо раніше оператор був фізично прив’язаний до машини — умовно, сидів у кількох сотнях метрів чи кілометрів із радіопультом, — то з появою Starlink на борту робот стає вузлом у мережі. Оператор може бути за десятки кілометрів, а теоретично — і в іншому місті.
Ударний підрозділ «Азову» планує максимально переходити на віддалене керування, зменшуючи кількість пілотів на передових позиціях. Для цього створюється командний пункт (КП), з якого централізовано вестиметься робота всіх НРК. І саме тут власний софт стає критично важливим: потрібно не просто «керувати роботом», а будувати цілу мережеву систему, де:
кілька пілотів одночасно працюють із різними машинами;
забезпечується взаємодія між НРК і іншими підрозділами;
інтегруються різні канали зв’язку (Starlink, LTE, ретранслятори);
реалізуються сценарії резервування на випадок втрати основного каналу.
Уніфікована державна платформа, заточена під логістику, може не встигати за такими вимогами. Власний софт дозволяє Малкушу й його команді будувати архітектуру «під себе»: від інтерфейсів пілотів до логіки роботи з мережевими каналами.
«Хмарка» як стандарт для логістики: чому там вона доречна
На цьому тлі показово, що логістичні НРК у тій самій бригаді «Азов» працюють саме на «Хмарці». Для задач підвозу, евакуації, транспортування уніфікований державний софт виглядає природним вибором.
Логістика вимагає передбачуваності й сумісності. Машини можуть надходити від різних виробників, у різних комплектаціях, через різні канали — від державних поставок до волонтерських закупівель. «Хмарка» дає можливість звести це в єдину систему керування, де:
оператори працюють у знайомому середовищі незалежно від конкретної моделі НРК;
командири отримують уніфіковану картину руху техніки;
можна централізовано оновлювати ПЗ і протоколи безпеки.
Для логістичних задач не настільки критична мілісекундна реакція системи чи можливість «на льоту» переписати логіку роботи під нову тактику. Там важливіше, щоб платформа була стабільною, підтримуваною й офіційно інтегрованою в інші елементи військової інфраструктури.
Тому в «Азові» склалася природна диференціація: там, де потрібна стандартизація й масштабованість — логістика — працює «Хмарка». Там, де потрібна максимальна гнучкість і швидкість змін — ударні НРК — розгортається власний софт.
Малі колісні НРК, Starlink і батареї: як софт зав’язаний на «залізо»
Рішення про власне ПЗ в ударному підрозділі не можна розглядати у відриві від того, на яких платформах він працює і як їх модифікує. Малкуш послідовно відстоює концепцію малих, дешевих, швидких колісних НРК. Підрозділ активно використовує «Гієни» та «Мангал» — серійні платформи, які, однак, майже завжди потребують доопрацювання.
Один із ключових напрямів доопрацювання — енергетика. За словами Малкуша, підрозділ як мінімум удвічі збільшує ємність батарей на НРК порівняно зі штатною комплектацією. Отримані від держави «Мангал» у тій конфігурації, яка є на складі, не викидаються й не замінюються, а доповнюються: ставляться спарені батареї, формуються «скпарки» по дві батареї на один дрон.
Це не просто «хак» для збільшення запасу ходу. Це ще й вимога до софту: система керування має коректно працювати з іншою енергетичною конфігурацією, відслідковувати стан батарей, прогнозувати час роботи, враховувати зміну маси й балансу машини.
Те саме стосується зв’язку. І «Гієна», і «Мангал» можуть постачатися виробником уже зі Starlink на борту, але підрозділ не завжди отримує їх у такій комплектації, особливо коли мова йде про державні поставки. Доводиться самостійно інтегрувати термінали, вирішувати питання живлення, кріплення, захисту.
Універсальний софт, який не враховує цих модифікацій, може виявитися недостатньо гнучким. Власна система керування дозволяє Малкушу й команді адаптувати ПЗ під конкретні конфігурації «заліза», які вони реально мають у полі, а не під «ідеальну» комплектацію з презентацій виробника.
Командний пункт як центр тяжіння: чому бойовий софт не можна «винести в Київ»
Перехід до віддаленого керування НРК через Starlink породжує спокусу уявити собі майбутнє, де пілоти сидять у Києві чи Львові, а роботи воюють на фронті. У публічному просторі вже з’являлися історії про ППО-дрони, якими керують за тисячі кілометрів. На цьому тлі виникають ідеї залучати цивільних як пілотів, які «просто» керуватимуть джойстиком.
Малкуш досить жорстко відмежовує реальність від таких уявлень. Керування НРК — це не лише «їхати вперед-назад, вправо-вліво». Бойова робота — це насамперед взаємодія: з іншими пілотами, з піхотою, з артилерією, з командуванням на рівні батальйону. Це постійний обмін інформацією, ухвалення рішень у реальному часі, робота з розвідданими, координація кількох машин одночасно.
Саме тому підрозділ «Азову» будує КП на оперативній глибині, у районі виконання бойових задач, а не в глибокому тилу. Пілоти працюватимуть із цього командного пункту, а не з власних квартир. Віддалене керування зменшує їхню присутність безпосередньо на позиціях, але не скасовує потреби в спільній роботі в межах єдиного центру.
Це знову ж таки впирається в програмне забезпечення. Власний софт має підтримувати не лише інтерфейс «пілот — робот», а й інтерфейс «КП — поле бою»: відображення ситуації, координацію кількох НРК, інтеграцію з іншими системами, доступ до інформації, яка недоступна «звичайному» пілоту. Уніфікована логістична платформа на кшталт «Хмарки» просто не створювалася під такі сценарії.
Баланс між державним стандартом і фронтовим R&D
Ситуація в «Азові» добре ілюструє ширшу дилему, перед якою стоїть українська армія. З одного боку, потрібні державні стандарти на кшталт «Хмарки», які дозволяють уніфікувати роботу з НРК, спростити навчання, забезпечити сумісність між підрозділами й виробниками. Без цього неможливо масштабувати використання роботизованих систем у військах.
З іншого боку, фронтові підрозділи, які займаються бойовими НРК, змушені рухатися швидше, ніж може собі дозволити будь-яка централізована структура. Вони експериментують із платформами, батареями, каналами зв’язку, тактиками. Їм потрібен софт, який можна змінювати так само швидко, як і «залізо».
Підрозділ Малкуша вирішує цю дилему через розведення ролей: логістика йде в «Хмарку», ударні НРК — у власний софт. Це дозволяє одночасно користуватися перевагами державної платформи там, де вона доречна, і не обмежувати себе нею там, де потрібна максимальна гнучкість.
У перспективі саме такі кейси можуть підштовхнути до появи більш модульних державних рішень, які дозволятимуть бойовим підрозділам підключати власні модулі, зберігаючи при цьому базову сумісність. Але поки що фронтова реальність змушує командирів на кшталт Малкуша будувати свої програмні екосистеми паралельно з державними.
Висновок: НРК як софтова війна
Наземні роботизовані комплекси часто сприймаються як «залізо» — платформи на колесах чи гусеницях, до яких можна «прикрутити» будь-який софт. Досвід ударного підрозділу «Азову» показує протилежне: саме програмне забезпечення стає полем, де вирішується, чи буде НРК ефективним бойовим інструментом, чи залишиться дорогим експериментом.
У межах однієї бригади співіснують дві моделі. Логістичні НРК працюють на державній «Хмарці», отримуючи переваги стандартизації й масштабованості. Ударні НРК Малкуша переходять на власний софт, щоб мати свободу швидко змінюватися разом із тактикою, платформами, каналами зв’язку й організаційною структурою.
Цей розподіл навряд чи залишиться унікальним. У міру того як НРК ставатимуть масовим інструментом на фронті, армія дедалі більше нагадуватиме екосистему, де державні платформи й фронтовий R&D співіснують і взаємно впливають одне на одного. І від того, наскільки вдасться зберегти цей баланс, залежатиме, чи зможе Україна перетворити роботизовані системи з модного тренду на справжній фактор переваги на полі бою.
Джерело
Ударні НРК, віддалене керування, власний софт, маскування. Спецвипуск fpv #28 з Михайлом Малкушем