Як побороти "шахеди"
Індустрія дронів
На четвертий рік війни залишається актуальною проблема протидії ударним БпЛА типу "шахед". Десятки (а іноді й сотні) апаратів майже щоночі знищують цивільні об’єкти, тероризують і вбивають мирних громадян.
Ця колонка не претендує на унікальність, радше – про роздуми авіаційного фахівця щодо створення системи протидії загрозам.
З чого починати розробку
Отже, розробка будь-якого літального апарата (зокрема безпілотного) починається не з 3D-моделі/креслень і не з вибору двигуна чи авіоніки, а з простого запитання: навіщо він потрібен. Спершу формулюють місію. Наприклад: "Нам потрібен БпЛА, який швидко перехоплює ворожі безпілотники перед населеними пунктами вночі та за поганої погоди". Така фраза задає рамку всьому далі: де він літатиме, хто ним керуватиме, в яких умовах і проти чого саме.
Далі цю місію "перекладають на цифри":
- замість "швидко" – конкретна швидкість і час реагування від тривоги до перехоплення;
- замість "далеко" – реальна відстань, яку апарат має пролетіти;
- замість "надійно" – скільки годин він мусить працювати без відмов, як швидко ремонтується в полі, скільки коштує одна успішна місія тощо.
Саме ці прості, але точні показники дозволяють потім чесно оцінити: вийшло чи ні.
Коли вимоги зрозумілі, команда обирає ідею конструкції. Це як вибір кузова для авто: одні форми краще для швидких перельотів, інші – для зльоту й посадки з тісних майданчиків. Інколи потрібен апарат, що може злітати вертикально, а далі летіти як літак. На цьому етапі роблять перші прикидки ваги, потрібної енергії, розмірів, компоновку тощо.
Паралельно продумують як перевіряти, що апарат справді виконує обіцяне. Створюють просту таблицю: от наші вимоги – от як ми доведемо, що вони виконані. Десь достатньо розрахунків і комп’ютерних моделей, десь потрібні стендові випробування для відпрацювання безпечного підриву корисного навантаження на відстані кількох метрів від цілі, а десь – реальні випробування на полігоні вдень, уночі й за складних погодних умов. Без такого плану легко скотитися у "вічний прототип" – щось літає, але прийняти на озброєння не можна.
Ще одна важлива частина – безпечне застосування. Якщо апарат працює над містом, заздалегідь визначають "коридори", де його можна використовувати, мінімальні висоти, на яких дозволено уражати ціль, і що робити, якщо раптом зник зв’язок. Продумують аварійний парашут, самознищення боєвого модуля, щоб він не дістався ворогу, та прості правила для оператора: де можна, де не можна, як звітувати про інциденти. Такі правила потрібні не лише для безпеки людей – без них військові просто не дадуть добро на використання над населеними районами.
Питання зв’язку й стійкості до перешкод теж вирішують одразу. Апарат має вміти діяти, навіть якщо супутникова навігація "глуха", а радіоканал зашумлений. Для цього закладають резервні способи орієнтування за камерою та датчиками, а також режим, коли БпЛА може завершити задачу або повернутися без постійного відеозв’язку з оператором.
БпЛА по суті – робот, і питання керування ним, програмного забезпечення є критичним.
Далі – експлуатація і гроші. Визначають, скільки має коштувати одна успішна місія. Для перехоплювача важливо, щоб це було відчутно дешевше за ракету зенітного комплексу і ефективніше за використання наземних стрілецьких екіпажів. Планують, які запчастини тримати на складі, які вузли мають змінюватися нашвидкоруч у польових умовах, і хто навчатиме екіпажі. Одразу домовляються з постачальниками компонентів про альтернативні рішення: сьогодні один акумулятор недоступний – має бути інший рівноцінний.
Чого варто уникати на початку? Найпоширеніші "граблі" – починати з заліза ("Ми зробили красиве крило – його спробуємо застосувати для потрібного вам завдання"), відсутність технічного завдання на виріб від замовника, відкладати план випробувань "на потім" тощо. Ліки прості: спершу – затверджений документ із вимогами та перевірками, потім – креслення.
Розробка БпЛА починається з ясної мети, потім – прості й точні цифри успіху, усвідомлений вибір конструкції, заздалегідь продуманий план перевірок, правила безпеки, і лише потім – креслення та виробництво. Така послідовність здається бюрократією, але саме вона економить місяці й мільйони, і робить різницю між "красивим прототипом у відео" та справжнім робочим апаратом, який щодня ефективно виконує свою роботу.
Хто замовник рішень?
Якщо говорити просто, замовником рішень проти ворожих БпЛА виступає держава в особі Міністерства оборони. Саме військові мають сказати: нам потрібне таке рішення, воно має працювати в таких-то умовах і коштувати не дорожче певної суми за одну успішну операцію. Далі вже спеціальне державне агентство оформлює закупівлю і контракт, а виробники зобов’язуються зробити те, що описано в цих вимогах.
Причому розуміємо, що не існує універсальних рішень – перехоплювач збиває повітряні цілі, а бомбардувальник працює по наземних об’єктах. Це різні задачі, різний набір обладнання, різні вимоги до конструкції тощо. Різні апарати, зрештою.
Як це зараз відбувається в Україні? Працює кілька "паралельних колій". Є централізовані закупівлі Міноборони. Є інноваційні програми на кшталт Brave1 та "Армії дронів", які допомагають знайти цікаві ідеї, дати грант, організувати пілотні випробування. Є ще й прямі покупки на рівні бригад і підрозділів – коли потрібно швидко, без довгих паперів і щоб не ставити на баланс.
Усе це допомагає, бо додає швидкості й гнучкості.
Але є і зворотний бік – з’являється "зоопарк" різних моделей і підходів, різні правила застосування, різні формати даних і звітів, різні вимоги до обслуговування. У підсумку – важче навчати людей, важче тримати запчастини, важче звести все до єдиної системи.
Де болить найбільше?
По-перше, не завжди є одна мова вимог. Один підрозділ хоче "швидко та дешево", інший – "далеко та потужно", третій – "щоби працювало над містом і в туман". Без узгодженого ТЗ виробники намагаються вгадати, і кожен приносить "свій найкращий варіант".
По-друге, шлях від прототипу до серійної техніки інколи затягується: немає однакового для всіх сценарію тестів і зрозумілої сходинки "маленька партія – більша партія – серія".
По-третє, коли купують із різних "кошиків", важко підтримувати спільні правила обслуговування і навчання – це відображається на готовності техніки в бою.
Що з цим робити? Найпростіше пояснення – потрібен "один господар вимог" і "один коридор у серію". Роль господаря логічно покласти на новостворені Сили безпілотних систем разом із Повітряними силами/ППО: саме вони щодня живуть цією "війною дронів" і найкраще розуміють реальні сценарії. Вони мають опублікувати й постійно оновлювати коротке, але чітке ТЗ для кожного класу БпЛА – FPV, перехоплювач, бомбардувальник, розвідник тощо. Там простими словами має бути сказано: за скільки секунд від тривоги до перехоплення ми очікуємо результат; яка мінімальна ймовірність успіху; в яких умовах апарат має працювати (ніч, туман, місто); як саме він "розмовляє" з уже наявними центрами управління і програмним забезпеченням; скільки має коштувати одна успішна операція тощо.
Другий крок – створити при Міноборони невелику, але "зшиту" команду, щось на кшталт програмного офісу. У ній разом сидять військові, закупівельники, технічні аналітики, представники інноваційних програм і оператори з війська. Завдання цієї команди – запустити майданчики для випробувань із однаковими правилами: день, ніч, туман, робота над містом і поза ним. На цих майданчиках усі нові рішення перевіряються за однаковим сценарієм, щоб було чесне порівняння "яблук з яблуками".
Третій крок – відбір і закупівля "хвилями". Спочатку невеликі партії від кількох команд, щоб подивитися на практиці. Потім – більші партії від тих, хто показав кращий результат. І нарешті – серійна закупівля. У контрактах варто відразу прописати прості й справедливі стимули: премія за нижчу вартість однієї успішної операції, за високу готовність техніки, за сумісність із єдиними правилами обміну даними; штрафи – за збої й невідповідність правилам безпеки над містом.
Четвертий крок – зберегти швидкість на фронті, але без хаосу. Підрозділи можуть і далі купувати напряму, але з каталогу схвалених моделей, які вже пройшли однакові випробування. Це дає і свободу вибору, і спільні стандарти навчання, обслуговування та запчастин.
І останнє – про гроші. Бюджет має бути не тільки на "купити залізо", а й на "довести до розуму": випробування, інтеграцію з наявними системами, навчання інструкторів, комплект запчастин. Інакше гарна ідея так і лишиться прототипом із красивого відео.
Підсумок простий: щоб отримати масові й справді корисні перехоплювачі ударних БпЛА, потрібні не лише талановиті інженери, а й порядок у вимогах та процедурах. Один відповідальний за вимоги, спільні правила тестів, хвильові закупівлі з прозорими стимулами та "каталог схвалених" для швидких потреб фронту.
Такою дорогою ми приходимо до техніки, яка не просто літає, а щодня робить свою роботу – і робить її безпечно, злагоджено та за розумні гроші. У такий спосіб ми зможемо працювати планомірно, діяти на випередження в розробках, а не наздоганяти противника за фактом появи у нього нових моделей БпЛА. Така розкладка знімає фрагментацію, створюючи системні рішення, пришвидшує серійність і дає саме те, що фронт просить: стандартизовані, сумісні й масові перехоплювачі – без "зоопарку" та подвійної роботи.
але ж, нам байден не дозволяє!
довгий нептун, перекрасили у фламінго.
і, звісно, 173 кластерні безпекові гарантії!
Інженери-конструктори, розробники БпАК створюють проектно-конструкторську документацію на БпАК, за якою підприємство виготовлятиме ці вироби. Щоб на підприємстві зрозуміли проектно-конструкторську документацію і могли виготовити БпАК, інженерна документація повинна бути створена розробниками у відповідності з певними правилами, зокрема - стандартами.
Замовник надає Виконавцю (розробнику) технічні вимоги до розробки БпАК, і на підставі цих вимог Замовника, у взаємодії з ним Виконавець (висококваліфікований розробник) створює (розробляє) головний документ на подальше проектування та розробку БпАК - технічне завдання (ТЗ).
У ТЗ інженерною мовою описане майже все те, про що розповів автор, але вже про конкретний БпАК. ТЗ на БпАК - документ з обмеженим доступом. Процес розробки ТЗ добре відомий і нам , і нашим партнерам і нашим ворогам. Зокрема, в Україні відомий ДСТУ 8788:2018 "Безпілотні авіаційні комплекси. Загальні технічні вимоги" - стандарт, який може використовуватися для розробки БпАК. Він визначає вимоги до проектування, випробувань та експлуатації безпілотників, включаючи складання ТЗ. У країнах НАТО функцію ТЗ виконують, зокрема такі документи, як Operational Requirements Document (ORD), System Requirements Specification (SRS) або Statement of Work (SOW). Ці документи визначають вимоги до системи, технічні характеристики, цілі проєкту, критерії його приймання та ін.
Ну і нам трошки відкату.
Найбільша проблема в масштабуванні їх виробництва.
Виробничі потужності рашистів поки що значно перевищують наші. Одна з добрих стратегій розвʼязання цієї проблеми - створення спільних з партнерами оборонних кластерів підприємств із виробництва БпАК. Друга - знищення виробництва та логістичних ланцюгів ворожих БпАК.
Третя - ураження місць навчання, технічного обслуговування пусків та особового складу ворога, який здійснює програмування та застосування Гераней.