Набор показателей для дронов, предлагаемый к использованию для оценки перспективных проектов.
- Если брать текущее состояние, единственная юридически значимая метрика — это… взлётный вес. И ровно две отсечки: до 150 грамм (не требует регистрации) и до 30 кг (не является авиационным транспортным средством); всё, что тяжелее — уже требования как к самолёту. Все остальные метрики — грузоподъёмность, дальность полёта, время полёта, особенности конструкции, варианты полезной нагрузки и т.д. — существуют исключительно в продажных презентациях.
- Те метрики, которые чаще всего обсуждаются на совещаниях, касаются, как правило, исключительно особенностей использования — то есть когда дрон уже взлетел и начал делать свою работу. Давайте посмотрим повнимательнее на то, что за скобками этого процесса. То есть на весь жизненный цикл изделия — начиная от его проектирования и производства, и заканчивая утилизацией.
- Предлагаемый набор подходов к метрикам является результатом коллективной работы экспертной группы Дронницы, и опирается в основном на опыт боевой эксплуатации существующих моделей. Тем не менее, легко сделать операцию «перевода» в уме военного и гражданского вариантов применения.
- Проектирование и производство. Сегодняшний типичный дрон российского производства — это голем, собранный из закупленных у разнообразных китайских производителей ключевых узлов, с минимальным добавлением локальных изделий, в соответствии с предполагаемой задачей применения. Рано или поздно (и лучше пораньше) мы поймём, что для разворачивания индустрии нужно производить и разрабатывать не сами дроны, а ключевые узлы и компоненты — двигатели, полётные контроллеры, даталинки, оптику, модули полезной нагрузки и т.д., вплоть до мелочей — шлейфов, сервоприводов, датчиков… то есть отмотать на 1-2 стадии по цепочке переделов. Но здесь важно не совершить ошибку на уровне архитектуры — избежать «феодализма» производителей. Поэтому вопрос сводится к проектированию открытых архитектур, причём, в наиболее радикальном варианте, по модели open source software — нужно думать об open source hardware, то есть узлах с беспатентной КД, которые может производить кто угодно, с простой процедурой приёмки/сертификации.
- Хранение/транспортировка/ремонт/обслуживание. Приоритеты: эргономика, транспортабельность, простота сборки, модульность, крупноузловая компоновка (в тч облегчающая полевой ремонт), системы самодиагностики, конструктивно заложенная возможность последующих улучшений (upgradeability).
- Ключевой вопрос надёжности — это расчётный ресурс работы различных узлов. Необходимы лабораторно подтверждённые статистические расчёты, на сколько часов работы хватает того или иного двигателя, на сколько циклов зарядки рассчитан аккумулятор и т.д., вплоть до разъёмов (по опыту, в поле стандартный аккумуляторный разъём приходится менять после пары десятков подключений/отключений). Если ресурс работы того или иного узла сильно меньше расчётного срока жизни всего изделия, необходимо считать его расходником, т.е. сразу закладывать модульную архитектуру замены.
- Метрика, которая часто остаётся за скобками — это уровень требований к внешней инфраструктуре. Это касается и полётов (связь, навигация), и хранения-обслуживания. Неправильно считать, что они всегда по умолчанию должны быть «чем меньше, тем лучше». Троллейбусу нужны провода, автобусу нет, но у автономности автобуса есть свои минусы. Надо научиться видеть БАС не как летающую железку, а как часть техносферного комплекса, «надводную часть айсберга» — при этом наверху спутники, внизу локаторы, дронопорты и маяки, в воздухе — другие устройства, с которыми они обмениваются данными и т.д.
Источник: https://t.me/chadayevru/2258