Українська оборонна промисловість здатна пройти шлях від ідеї до прототипу за лічені місяці. Однак у сучасній війні вже недостатньо просто швидко створити “найкращий роботизований комплекс/безпілотник/будь-який інший виріб”, адже остаточної версії продукту не існує.
Те, що працює сьогодні, не гарантує ефективності завтра. Детальніше – в ексклюзивній колонці для 24 Каналу.
Оборонний продукт не може довго залишатися актуальним сам по собі. Противник постійно змінює тактику та засоби протидії. Оператори виявляють, що певні дії в інтерфейсі займають надто багато часу в стресовій ситуації. Бруд, вібрація та бойові пошкодження виявляють слабкі місця компонентів. Нова місія може вимагати іншого сенсора, каналу зв’язку або бойового модуля.
Актуальність роботизованих комплексів та іншої оборонної продукції потребує постійної підтримки: збору досвіду застосування, внесення технічних змін, забезпечення сервісу та повторної перевірки системи під час наступних місій.
Дрони у війську – це початок, а не фінал
Робота над зброєю не завершується після випробувань, кодифікації або передачі військовому підрозділу. Саме тоді розпочинається новий цикл розробки.
Коли військовий повертається з місії з даними про те, що спрацювало, що відмовило і що створювало зайве навантаження, його зворотний зв’язок не повинен залишатися лише голосовим повідомленням у чаті з виробником. Цей досвід необхідно зафіксувати як конкретну технічну проблему або потребу, перевірити її причину та визначити рішення.
Інженери мають відрізнити дефект продукту від прогалини в підготовці операторів, проблеми інтеграції або наслідків застосування противником нового засобу протидії. Далі зміну потрібно узгодити, впровадити в системах, які вже перебувають у війську, а результат – перевірити під час наступного застосування.
Якщо хоча б один із цих етапів триває місяцями, засіб може втратити актуальність раніше, ніж потрапить до підрозділу. Тому швидкість адаптації безпосередньо впливає на бойову ефективність продукту і, відповідно, на боєздатність підрозділу.
Приклад ефективної співпраці військових та розробників
Можу продемонструвати, як працює цей цикл, на прикладі функції автономного проїзду, яку ми нещодавно реалізували для наших засобів, що працюють на DroidBox. Перед вечірньою місією військові звернулися до нас із запитом: роботизований комплекс мав пройти під мостом, де зникав зв’язок з оператором. Рішення було потрібне того ж дня.
Запит з фронту ми одразу перетворюємо на конкретне інженерне завдання: що саме має зробити система, за яких умов і до якого часу. У цьому випадку потрібно було забезпечити автономний проїзд ділянки без зв’язку до початку місії. Команда оцінила обмеження та визначила, яке рішення можна реалізувати за кілька годин.
До вечора ми підготували першу робочу версію функції автономного проїзду. Вона вирішувала конкретне завдання підрозділу, але ще не була повноцінною функцією продукту. Її застосування під час місії стало наступним етапом розробки: дало змогу перевірити рішення в реальних умовах і зібрати матеріал для доопрацювання.
Дійсно, такий темп можливий не для кожного доопрацювання і не завжди є доцільним. Зміни в апаратній частині, системах безпеки чи архітектурі продукту потребують проєктування та довших випробувань. Але етапи залишаються сталими – і навіть якщо вони не тривають години, важливо проходити їх без зайвих пауз і не втрачати початковий запит з поля бою.
Досвід однієї місії має покращувати всі системи
Після місії військові надали зворотний зв’язок щодо того, як функція працювала в реальних умовах і як із нею взаємодіяв оператор. На основі цих матеріалів ми вдосконалили саму функцію, додали окремий інтерфейс і включили її до загальної версії системи. Так, рішення для однієї місії стало доступним як на вже переданих у військо, так і на нових системах.
Цей цикл стосується не лише програмного забезпечення. За тією ж логікою ми працюємо і з апаратними змінами – наприклад, встановленням динаміка чи генератора, заміною гусениці або інтеграцією нового обладнання.
Запит оператора має завершитися перевіреним рішенням, яке можна застосувати на всіх засобах. Сенс постійної адаптації – не в тому, щоб змінювати систему після кожного повідомлення з фронту. Він у тому, щоб досвід одного підрозділу – виявлений недолік, нова потреба або знайдене рішення – не залишався сам на сам з собою. Сигнал оператора потрібно перевірити і, якщо запропонована зміна справді покращує застосування, впровадити її в усіх відповідних системах: і вже переданих у військо, і тих, які лише готують до постачання.
Без такого процесу корисні рішення залишаються в межах окремих підрозділів, а інші змушені знову проходити той самий шлях. Коли цикл адаптації працює, досвід однієї місії розширює можливості всього продукту.
Те саме стосується і помилок – якщо на них не відреагували вчасно і не виправили, то зі збільшенням виробництва масштабуються й однакові недоліки.
Кількість переданих засобів – лише одна частина результату. Не менш важливо, чи розвиваються їхні можливості після постачання військовим та чи зберігають вони бойову актуальність.
Виробництво масштабує кількість засобів. Адаптація – рішення, перевірені реальним застосуванням. Саме поєднання цих двох процесів створює бойову спроможність та перевагу.
Джерело: www.24tv.ua