Матрица регрессии для обновлений прошивки дронов
Проверяйте изменения прошивки по идентификации оборудования, исходной конфигурации, моделированию, проверкам функций и основаниям для допуска к эксплуатации.
Определите, почему предлагается обновление.
Доступная версия прошивки не является полной причиной для немедленного изменения конфигурации эксплуатируемого аппарата. Определите проблему, необходимые возможности или цель обслуживания и прочитайте соответствующую информацию о выпуске. Запишите аппаратную целевую платформу контроллера, тип транспортного средства и текущую установку. Это обеспечивает ожидаемую выгоду и предотвращает получение обновления парком машин просто потому, что другой аппарат использовало загрузку с таким же названием. Ответственный технический процесс определяет, когда следует внести изменения.
Сохраняйте восстанавливаемую исходную конфигурацию
Перед авторизованной работой определите существующую прошивку, параметры, эталоны калибровки, подключенные устройства и примеры принятых задач. Сохраняйте подтверждающие записи в доступном месте проекта. Скриншот с номером версии не является полной базовой версией. Определите, какие этапы восстановления действительно поддерживаются для комбинации платы и программного обеспечения. Не думайте, что загрузка более старого файла автоматически воссоздает все предыдущие настройки или отменит все изменения.
Выполняйте проверки установленных функций.
Создайте матрицу, связывающую каждую соответствующую функцию с ее конфигурацией, ожидаемым наблюдением, тестовой средой и рецензентом. Включите датчики, средства связи, команды полезной нагрузки, интерпретацию миссии, регистрацию и применимое поведение в непредвиденных обстоятельствах. Матрица должна отражать поставляемый самолет, а не все возможные функции автопилота. Это раскрывает недостающие доказательства: успешный запуск может подтвердить работу программного обеспечения, при этом интерфейс камеры или поведение возврата могут оставаться полностью непроверенными.
Используйте моделирование для вопросов, на которые оно может ответить
Программное моделирование в замкнутом контуре (software-in-the-loop) позволяет изучить поддерживаемую логику и рабочие процессы миссии, не рассматривая реальный самолет в качестве первого эксперимента. Запишите симулятор, версию программного обеспечения, модель и предположения. Моделирование не подтверждает проводку, состояние силовой установки или работу установленных датчиков. Отделяйте эти проверки. Полезный результат показывает, какое поведение проверялось и какие физические вопросы все еще требуют утвержденного процесса наземной и эксплуатационной проверки самолета.
Просмотрите различия перед расширением развертывания
Сравните ожидаемые и наблюдаемые результаты, включая измененные значения по умолчанию, переименованные настройки, обнаружение устройств и записанные данные. Исследуйте различия, а не копируйте предыдущий файл параметров без разбора. Ограничивайте оценку фактически протестированной конфигурацией. Если нерешенная проблема влияет на требуемую функцию, сохраните четкий статус и маршрут эскалации. Внедрение в масштабах всего флота должно основываться на продемонстрированной применимости, а не на отсутствии видимой ошибки во время одной неофициальной демонстрации.
Выдайте полный комплект эксплуатационных сведений
В окончательном пакете должны быть указаны принятая прошивка, конфигурация, данные испытаний, оставшиеся ограничения и обновленные инструкции. Убедитесь, что операторы и вспомогательный персонал могут распознать, на каком самолете используется одобренная конфигурация. Сохраните предыдущие исходные данные и историю решений. Это делает обсуждение прошивки NiVO удобным для просмотра и дает надежную отправную точку для дальнейшего устранения неполадок, одновременно предотвращая ошибочное принятие номера версии за полную готовность.
