Как украинские боевые роботы совершенствуются прямо на поле боя

То, что средство работает сегодня, еще не означает, что оно останется эффективным завтра. Подробнее читайте в эксклюзивной колонке для 24 Канала.

Оборонный продукт не может долго оставаться актуальным сам по себе. Противник меняет тактику и средства противодействия. Операторы обнаруживают, что определенная последовательность действий в интерфейсе занимает слишком много времени в стрессовой ситуации. Грязь, вибрация и боевые повреждения выявляют слабость отдельных компонентов. А новая миссия может потребовать другого датчика, канала связи или боевого модуля.

Актуальность роботизированных комплексов и другой оборонной продукции необходимо постоянно поддерживать – накапливать опыт применения, вносить технические изменения, обеспечивать сервисное обслуживание и вновь проверять систему во время следующих миссий.

Дроны в армии – это начало, а не финал

Работа над оружием не заканчивается после испытаний, кодификации или передачи военному подразделению. Именно в этот момент начинается новый цикл разработки.

Когда военный возвращается с миссии с данными о том, что сработало, что отказало и что создавало лишнюю нагрузку, его обратная связь не должна оставаться просто голосовым сообщением в чате с производителем. Этот опыт необходимо зафиксировать как конкретную техническую проблему или потребность, проверить ее причину и определить решение.

Инженеры должны отличить дефект продукта от пробела в подготовке операторов, проблемы интеграции или последствий применения противником нового средства противодействия. Далее изменение необходимо согласовать, внедрить в системы, которые уже находятся в войсках, а результат – проверить при следующем применении.

Если хотя бы один из этих этапов длится месяцами, средство может утратить актуальность раньше, чем оно поступит в подразделение. Поэтому скорость адаптации напрямую влияет на боевую эффективность продукта и, соответственно, на боеспособность подразделения.

Пример эффективного сотрудничества военных и разработчиков

Могу продемонстрировать, как работает этот цикл, на примере функции автономного проезда, которую мы недавно реализовали для наших средств, работающих на DroidBox. Перед вечерней миссией военные обратились к нам с запросом: НРК должен был пройти под мостом, где пропадала связь с оператором. Решение требовалось в тот же день.

Запрос с фронта мы сразу преобразуем в конкретную инженерную задачу: что именно должна сделать система, при каких условиях и к какому сроку. В данном случае требовалось обеспечить автономный проезд участка без связи до начала миссии. Команда оценила ограничения и определила, какое решение можно реализовать за несколько часов.

К вечеру мы подготовили первую рабочую версию функции автономного проезда. Она решала конкретную задачу подразделения, но еще не была полноценной функцией продукта. Ее применение во время миссии стало следующим этапом разработки: позволило проверить решение в реальных условиях и собрать материал для доработки.

Действительно, такой темп возможен не для каждой доработки и не всегда целесообразен. Изменения в аппаратной части, системах безопасности или архитектуре продукта требуют проектирования и более длительных испытаний. Но этапы остаются неизменными – и даже если они не длятся часами, важно проходить их без лишних пауз и не терять из виду исходный запрос с поля боя.

Опыт одной миссии должен улучшать все системы

После миссии военные дали обратную связь о том, как функция работала в реальных условиях и как с ней взаимодействовал оператор. На основе этих материалов мы усовершенствовали саму функцию, добавили отдельный интерфейс и включили ее в общую версию системы. Так, решение для одной миссии стало доступно как на уже переданных вооруженным силам, так и на новых системах.

Этот цикл касается не только программного обеспечения. По той же логике мы работаем и с аппаратными изменениями – например, установкой динамика или генератора, заменой гусеницы или интеграцией нового оборудования.

Запрос оператора должен завершиться проверенным решением, которое можно применить на всех средствах. Смысл постоянной адаптации не в том, чтобы менять систему после каждого сообщения с фронта. Он в том, чтобы опыт одного подразделения – выявленный недостаток, новая потребность или найденное решение – не оставался в одиночестве. Сигнал оператора необходимо проверить и, если предложенное изменение действительно улучшает применение, внедрить его во все соответствующие системы: и в те, которые уже переданы в войска, и в те, которые только готовятся к поставке.

Без такого процесса полезные решения остаются в пределах отдельных подразделений, а остальные вынуждены заново проходить тот же путь. Когда цикл адаптации работает, опыт одной миссии расширяет возможности всего продукта.

То же самое касается и ошибок – если на них не отреагировали вовремя и не исправили, то с увеличением производства масштабируются и те же недостатки.

Количество переданных средств – лишь одна часть результата. Не менее важно, развиваются ли их возможности после поставки военным и сохраняют ли они боевую актуальность.

Производство увеличивает количество средств. Адаптация – это решения, проверенные в реальных условиях. Именно сочетание этих двух процессов создает боевую мощь и преимущество.