В SkyRover мы видим, как многие покупатели испытывают трудности с проверкой инженерных заявлений. Выбор неверного партнера рискует провалом проекта и пустой тратой бюджета. Вам нужен проверенный метод проверки поставщиков.
Для оценки научно-исследовательских возможностей поставщика запросите конкретные примеры прошлых проектов OEM и проверьте состав их инженерной команды. Убедитесь, что они владеют исходным кодом системы управления полетом для глубокой кастомизации, и запросите подробную дорожную карту разработки продукта, включающую этапы прототипирования и протоколы тестирования.
Чтобы помочь вам сделать правильный выбор, мы разбили на пункты критические вопросы, которые вы должны задать на этапе переговоров.
Какие вопросы следует задать о размере и опыте их инженерной команды?
Когда мы нанимаем инженеров для нашего завода в Чэнду, мы ищем определенные навыки. Вам нужно знать, кто на самом деле проектирует ваш дрон, а не только кто его продает.
Запросите разбивку их технического персонала по сравнению с торговым персоналом, чтобы обеспечить высокий процент инженеров. В частности, узнайте о количестве специалистов в области аэродинамики, разработки программного обеспечения и структурной инженерии, поскольку эти роли имеют решающее значение для успешного выполнения сложных индивидуальных проектов пожарных дронов.
Важность состава команды
При оценке поставщика для индивидуальных пожарных дронов общее количество сотрудников менее важно, чем соотношение инженеров к другому персоналу. Многие торговые компании в Китае могут иметь 50 сотрудников, но 45 из них — торговые представители. Настоящий производитель, способный к НИОКР, будет иметь значительную часть своей рабочей силы, посвященную техническим ролям.
Вам следует запросить организационную схему или разбивку их отдела НИОКР. Вы ищете сочетание дисциплин. Инженер-механик может спроектировать раму, но не может написать код для системы управления полетом. Инженер-программист может написать код, но не может гарантировать, что дрон останется стабильным при ветре 10 м/с.
Вертикальная интеграция технологий
Одним из наиболее критических аспектов, на которых мы настаиваем, является вертикальная интеграция. Это означает, что поставщик контролирует основную технологию. Если поставщик покупает свои системы управления полетом у третьей стороны (например, JIYI или CubePilot) без доступа к исходному коду, его возможности по кастомизации ограничены. Они могут изменить только аппаратное обеспечение; они не могут изменить то, как летает дрон.
вертикальная интеграция 1
Для пожарных дронов вам может потребоваться, чтобы дрон вел себя по-разному при переноске тяжелой бомбы для тушения пожара и когда он пуст. Это требует модификации алгоритмов полета. Если у поставщика нет инженера по алгоритмам управления, он не сможет сделать это для вас.
алгоритм управления 2
Ключевые инженерные роли, на которые стоит обратить внимание
Используйте таблицу ниже, чтобы понять, какие роли необходимы для различных типов кастомизации.
Таблица 1: Инженерные роли, необходимые для типов кастомизации
| Требование к кастомизации | Критическая инженерная роль | Почему это важно |
|---|---|---|
| Стабильность при большой нагрузке | Инженер-аэродинамик | Обеспечивает стабильность дрона при переноске тяжелых огнетушителей или водяных шлангов. |
| Индивидуальное поведение в полете | Инженер по алгоритмам управления | Модифицирует исходный код для настройки полетных параметров для конкретных миссий. |
| Безопасность данных и шифрование | Инженер по программному обеспечению/прошивкам | Защищает конфиденциальные данные и обеспечивает безопасные каналы связи. |
| Высокая термостойкость | Инженер по материаловедению | Выбирает материалы, которые могут выдерживать высокие температуры вблизи огня без плавления. |
| Модификация конструкции | Инженер-механик | Перепроектирует раму для размещения новых датчиков или механизмов развертывания. |
Проверяя наличие этих ролей в команде поставщика, вы снижаете риск задержек при аутсорсинге. Если им придется нанимать внешнего фрилансера для исправления ошибки, ваш проект застопорится. Если талант находится внутри компании, исправление произойдет немедленно.
Может ли поставщик предоставить примеры предыдущих проектов кастомизации OEM?
Наше портфолио включает в себя кастомные грузовые дроны для европейских клиентов. Увидеть доказательства лучше, чем слушать обещания при выборе производственного партнера.
Запросите портфолио тематических исследований "Проблема-Решение", демонстрирующих, как они решили конкретные технические задачи для предыдущих клиентов. Ищите доказательства сложных интеграций, таких как уникальные механизмы полезной нагрузки или модификации для высокой термостойкости, а не простое изменение логотипов или цветовых схем.
Различие между ребрендингом и инжинирингом
Существует большая разница между "White Labeling" и "OEM Development". White labeling просто означает нанесение вашего логотипа на стандартный продукт. OEM development включает в себя создание чего-то нового. Многие поставщики покажут вам стандартный дрон и скажут: "Мы можем его кастомизировать". Вам нужно копнуть глубже, чтобы узнать, делали ли они это раньше.
Попросите показать примеры "До и После". Способная команда R&D должна иметь возможность показать вам стандартную модель, а затем кастомизированную версию, которую они создали для клиента. Ищите структурные изменения. Изменили ли они шасси? Интегрировали ли они новый кронштейн для камеры? Изменили ли они отсек для батареи?
Цикл обратной связи "Поле-Лаборатория"
По нашему опыту, лучшие инновации приходят из поля. Поставщик с сильными возможностями R&D будет иметь цикл обратной связи. Это означает, что они берут данные из реальных испытаний и используют их для улучшения дизайна.
Запросите у поставщика отчет "Анализ видов и последствий отказов" (FMEA) по прошлому проекту. Этот документ показывает, что они предвидели возможные отказы (например, перегрев двигателя) и разработали решение для их предотвращения. Если они не могут предоставить этот отчет, скорее всего, они пропускают строгие инженерные этапы и просто создают прототипы, пока один из них не заработает. Это опасно для пожарного оборудования.
Анализ видов и последствий отказов 3
Оценка сложности прошлых проектов
Вы хотите оценить сложность проектов, которые они реализовали. Интеграция прожектора — это просто; интеграция капсульного пускового устройства, которое связывается с наземной станцией, — это сложно.
Таблица 2: Уровни сложности индивидуальной настройки
| Уровень | Описание | Сложность НИОКР | На что обратить внимание |
|---|---|---|---|
| Уровень 1: Косметический | Печать логотипа, изменение цвета, индивидуальная упаковка. | Низкая | Высококачественная печать, прочное покрытие. |
| Уровень 2: Модульный | Замена стандартных полезных нагрузок (камеры, освещение) с использованием стандартных портов. | Средний | Аккуратная проводка, надежные монтажные кронштейны. |
| Уровень 3: Структурный | Изменение размера рамы, длины стрелы или шасси. | Высокий | Детали, обработанные на станках с ЧПУ, формование из углеродного волокна. |
| Уровень 4: Системный | Пользовательское программное обеспечение для полетов, проприетарные каналы связи, интеграция с ИИ. | Очень высокий | Пользовательские SDK, документация API, доступ к исходному коду. |
Если поставщик демонстрирует вам только примеры Уровня 1 или Уровня 2, он может быть не готов к сложному проекту пожарного дрона. Вам нужен партнер, который уверенно работает на Уровне 3 и Уровне 4. Это гарантирует, что при возникновении уникального требования у него будет техническая глубина для его выполнения.
Предлагает ли команда R&D поддержку SDK для интеграции стороннего программного обеспечения?
Мы часто помогаем клиентам интегрировать собственное программное обеспечение ИИ в наши полетные контроллеры. Без открытого доступа ваш пользовательский дрон становится закрытой системой.
Проверьте, предоставляет ли поставщик комплексный комплект для разработки программного обеспечения (SDK) и открытую документацию API. Это позволит вашей команде интегрировать сторонние приложения, такие как алгоритмы обнаружения пожара на основе ИИ или программное обеспечение для управления парком дронов, непосредственно в систему управления полетом дрона без привязки к поставщику.
Ловушка закрытых систем
На рынке промышленных дронов аппаратное обеспечение становится товаром. Настоящая ценность заключается в программном обеспечении. Для пожаротушения вы можете захотеть использовать передовое программное обеспечение, такое как FlytBase или BlueFire, для управления и контроля в реальном времени. Или вы можете захотеть запустить пользовательский алгоритм ИИ, который автоматически обнаруживает сигнатуры дыма.
Если ваш поставщик использует "закрытую систему", вы не сможете этого сделать. Вы ограничены функциями, которые он предоставляет. Если он прекратит обновлять свое программное обеспечение, ваш дрон устареет. Открытый SDK (комплект для разработки программного обеспечения) — ключ к обеспечению долговечности ваших инвестиций.
На что обратить внимание в SDK
Когда мы сотрудничаем с клиентами по программному обеспечению, мы предоставляем документацию, объясняющую, как взаимодействовать с полетным контроллером. Вам следует запросить у поставщика документацию по его API (интерфейсу прикладного программирования). до вы подписываете контракт.
Интерфейс прикладного программирования 4
Передайте эту документацию вашей команде разработчиков программного обеспечения или техническому консультанту. Спросите их: "Хорошо ли она написана? Полная ли она?" Хороший SDK позволит вам программно управлять дроном, считывать данные датчиков и запускать полезную нагрузку.
Интеграция с технологиями пожаротушения
Пожаротушение движется в сторону автоматизации. Дроны должны обмениваться данными с другими устройствами на земле. Например, дрон может передавать тепловые координаты непосредственно на планшет пожарного.
Таблица 3: Контрольный список возможностей SDK
| Функция | Назначение | Зачем это нужно пожарным |
|---|---|---|
| Потоковая передача телеметрии | Данные в реальном времени (высота, заряд батареи, GPS). | Командирам необходимо мгновенно знать статус дрона. |
| Доступ к видеопотоку | Доступ к видеопотоку с низкой задержкой. | Программному обеспечению с ИИ требуется необработанное видео для обнаружения пожаров. |
| Управление полезной нагрузкой | Активация механизмов сброса или освещения. | Автоматический сброс шаров с огнезащитным составом. |
| Загрузка путевых точек | Отправка траекторий полета дрону. | Автоматизация маршрутов патрулирования лесов. |
| Управление подвесом | Удаленное перемещение камеры. | Автоматическое отслеживание движущегося фронта пожара. |
Если поставщик говорит: "У нас нет SDK, но мы можем написать программное обеспечение для вас", будьте осторожны. Это создает "привязку к поставщику". Вам придется платить им каждый раз, когда вы захотите внести небольшое изменение. Гораздо лучше иметь открытую платформу, где вы контролируете разработку.
Привязка к поставщику 5
Как быстро они могут предоставить 3D-чертежи или технические схемы в соответствии с моими требованиями?
Когда клиент отправляет нам запрос, наша команда дизайнеров немедленно приступает к процессу САПР. Скорость отражает эффективность внутреннего рабочего процесса поставщика.
Оцените скорость их жизненного цикла разработки продукта (PDLC), запросив график первоначальных 3D-рендеров и технических схем. Компетентная команда R&D должна иметь возможность создавать предварительные САПР-модели в течение нескольких дней, чтобы визуализировать ваши конкретные требования до начала производства.
Сила быстрого прототипирования
Время — деньги. В индустрии дронов технологии развиваются быстро. Если поставщику требуется три месяца, чтобы просто предоставить вам чертеж, к моменту завершения продукта технология может устареть.
Мы используем инструменты быстрого прототипирования, такие как 3D-печать и ЧПУ-обработка. Это позволяет нам создавать физическую деталь за часы, а не за недели. Вам следует спросить у потенциального поставщика об их оборудовании для прототипирования. Есть ли у них 3D-принтеры в штате? Есть ли у них собственные станки с ЧПУ? Если им приходится заказывать каждую прототипную деталь со стороны, процесс разработки будет мучительно медленным.
ЧПУ-обработка 6
Процесс проверки дизайна
Профессиональная команда R&D следует структурированному процессу. Они не просто начинают строить. Они начинают с дизайна.
- Анализ требований: Они выслушают ваши потребности (например, "Мне нужен дрон, который может летать 60 минут с полезной нагрузкой 5 кг").
- Концептуальное проектирование: Они создадут грубый эскиз или блок-схему.
- САПР-моделирование: Они создадут подробную 3D-модель на компьютере.
- Моделирование: Они протестируют модель в программном обеспечении, чтобы увидеть, полетит ли она.
- Прототипирование: Они построят первый физический образец.
Вам следует попросить показать примеры "От САПР до реальности". Попросите их показать вам 3D-чертеж прошлого проекта, а затем фотографию конечного продукта. Они должны выглядеть почти идентично.
Жизненный цикл разработки продукта 7
Интерпретация времени отклика
Скорость, с которой они предоставляют технические чертежи, является огромным показателем их компетентности.
Комплект для разработки программного обеспечения (SDK) 8
- 24-48 часов: Вероятно, у них есть модульная библиотека дизайна, и они могут быстро собрать концепцию. Это отлично.
- 1 неделя: Это стандартно для индивидуального дизайна, требующего новой инженерии.
- 2 недели или более: Это тревожный сигнал. Это говорит о том, что они либо перегружены работой, либо у них нет собственных специалистов для самостоятельного проектирования и они ждут внешнего подрядчика.
Также обратите внимание на формат. Профессиональные инженеры отправляют файлы STEP или подробные PDF-схемы с размерами. Если они отправляют вам набросок от руки на салфетке или расплывчатое изображение в Photoshop, они не являются серьезным производственным партнером.
Безопасность данных и шифрование 9
Заключение
Оценка научно-исследовательских возможностей защищает ваши инвестиции. Проверьте структуру их команды, запросите доказательства прошлых индивидуальных проектов, убедитесь в наличии SDK и протестируйте скорость их проектирования.
специалисты по аэродинамике 10
Сноски
1. Объясняет бизнес-стратегию контроля над несколькими этапами цепочки поставок. ↩︎
2. Обеспечивает математическую основу для управления поведением динамических систем. ↩︎
3. Определяет систематический метод выявления потенциальных сбоев в дизайне. ↩︎
4. Авторитетное определение того, как программные компоненты взаимодействуют и обмениваются данными. ↩︎
5. Объясняет зависимость от одного поставщика, что делает затраты на переключение высокими. ↩︎
6. Описывает автоматизированный производственный процесс, используемый для прецизионных деталей. ↩︎
7. Описывает полный процесс вывода нового продукта на рынок. ↩︎
8. Объясняет набор инструментов, позволяющих создавать приложения для конкретной платформы. ↩︎
9. Ссылки на авторитетные стандарты информационной безопасности и защиты данных. ↩︎
10. Определяет научные принципы, необходимые для устойчивости и проектирования полета. ↩︎
English 
Español de México 
Deutsch 
Français 
Русский 
العربية 
