Какие шаги необходимо предпринять для переноса алгоритмов машинного зрения на процессор Ascend NPU?-Визуальный контроль на Huawei Ascend Atlas-Winge Technology

Техническая статья

Миграция алгоритма видения сборки в Ascend NPU подразумевает не копирование исходных файлов модели на устройство Atlas, а завершение системной адаптации формата модели, операторов, ввода и вывода, интерфейса среды выполнения и критериев приемки. Типичный путь: исправить базовую линию исходной модели, экспортировать ONNX, проверить структуру графа и операторы, использовать ATC для создания модели OM для целевого процессора Ascend, получить доступ к выводу через AscendCL, а затем завершить проверку согласованности до и после обработки, результатов обнаружения, производительности и доставки версии.

Программное обеспечение и алгоритмы визуального контроля сборки Winge Technology уже работают на Huawei Ascend Atlas 200I DK A2. Для проектов, использующих модели классификации, обнаружения объектов или сегментации, ссылки на вывод модели Ascend NPU могут быть добавлены на основе существующего доступа к камере, конфигурации ROI, записи результатов и локального развертывания.

Какие входные данные необходимо исправить перед миграцией?

Перед началом миграции следует сформировать воспроизводимый базовый пакет, который как минимум включает в себя:

Оригинальная структура обучения, структура модели, веса и сценарии экспорта;
Имя входа, размер ввода, тип данных и требования к динамическим размерам для моделей ONNX;
Методы упорядочивания цвета, масштабирования, обрезки, нормализации и расположения тензоров изображения;
Метки классификации, декодирование кадра обнаружения, пороги достоверности, правила обработки NMS или постсегментации;
Фиксированный набор проб ОК, НГ и граничных проб и их ожидаемые результаты;
Устройство Target Atlas, модель процессора Ascend, операционная система, CANN и версия пакета оператора;
Показатели приемки проекта, такие как точность, пропущенные обнаружения, ложные срабатывания, единовременное потребление времени, пропускная способность и объем памяти.

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

Шаг 1. Установите базовый уровень исходных результатов модели.

Используйте тот же набор приемочных изображений для запуска исходной модели и сохранения входных тензоров, исходных выходных данных, результатов постобработки и окончательных бизнес-решений. Проект обнаружения объектов также должен сохранять кадр обнаружения, категорию, достоверность и результаты NMS; проект сегментации должен сохранять размер маски, сопоставление категорий и результаты контуров.

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

Шаг 2. Экспортируйте и проверьте модель ONNX.

После экспорта ONNX из обучающей среды необходимо проверить:

Стабильны ли имена входных и выходных узлов?
Является ли входной размер фиксированным или динамическим размером;
Соответствуют ли версия оператора и структура графа целевой среде преобразования;
Включать ли узлы, которые используются только на этапе обучения;
Находятся ли результаты работы ONNX и результаты исходной модели в согласованном диапазоне ошибок.

На этом этапе вам следует сначала решить проблему экспорта самой модели, а затем ввести преобразование стороны Ascend, чтобы избежать переноса различий исходной модели на сторону устройства.

Шаг 3. Проверьте совместимость операторов и структуру графа.

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

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

Шаг 4. Используйте ATC для создания модели OM

В официальной документации Huawei Ascend говорится, что ATC используется для преобразования моделей инфраструктуры с открытым исходным кодом, таких как ONNX, в автономные модели OM, которые могут распознаваться процессором Ascend AI. Типичная структура команд выглядит следующим образом:

atc --model=model.onnx 
--framework=5 
--output=model_atlas 
--input_shape="images:1,3,H,W" 
--soc_version=<целевая модель процессора Ascend>

Фактические параметры должны соответствовать входным данным модели, целевому процессору и среде проекта. Во время преобразования SHA-256 команды ATC, версия среды, журнал преобразования, отчет о проверке и сгенерированный файл должны быть сохранены для отслеживания и воспроизведения процесса построения модели OM.

Шаг 5. Подключитесь к ссылке вывода AscendCL.

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

Промышленная камера или файлы изображений
-> Декодирование, обрезка и проверка качества изображения
-> изменение размера, преобразование цвета, нормализация и расположение тензоров
-> рассуждения модели OM
-> Классификация, кадр обнаружения или декодирование результатов сегментации
-> ROI с бизнес-правилами сборки
-> PASS / FAIL / UNKNOWN
-> Диаграмма доказательств, запись результатов и интерфейс рабочей станции

Интерфейс вывода отвечает только за расчет модели, а окончательное определение рабочей станции также управляет дедупликацией триггеров, качеством изображения, подтверждением результатов, ненормальным статусом, интерфейсом PLC или I/O и отслеживанием данных.

Шаг 6. Проверьте согласованность предварительной и постобработки.

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

Рекомендуется сравнивать по следующим уровням:

Входной слой: сравнить тензоры, входящие в исходную модель и модель OM;
Выходной слой: сравните форму, диапазон значений и порядок узлов исходного вывода модели;
Уровень алгоритма: сравнение категорий, полей обнаружения, масок и достоверности;
Бизнес-уровень: сравните результаты PASS, FAIL или UNKNOWN каждой выборки;
Уровень доказательств: сравните местоположения дефектов, карты аннотаций и записи результатов, чтобы увидеть, соответствуют ли они одной и той же заготовке.

Только выявляя различия слой за слоем, мы можем судить о необходимости корректировки преобразования модели, обработки данных или бизнес-правил.

Шаг 7. Полная проверка работоспособности и стабильности устройства.

Тестирование производительности следует проводить на целевых устройствах Atlas, формальных размерах изображений и фактических каналах обработки, различая:

Время получения или декодирования изображения;
Время предварительной обработки;
Время вывода одной модели;
Время постобработки и бизнес-правил;
изображение доказательства и время записи файла результатов;
Время отклика сквозной рабочей станции.

В результатах испытаний также должна быть записана версия модели, хэш файла OM, версия CANN, модель процессора, входной размер, партия, режим точности, количество прогревов и количество образцов. Точность, время производственного цикла и долгосрочная стабильность подтверждены независимыми проверками конкретных проектов и условий непрерывной эксплуатации.

Шаг 8. Формируйте поставку развертываемой версии

Официальная поставка должна содержать как минимум:

Исходная модель или исходные файлы модели в согласованном объеме;
Модель ONNX и инструкции по экспорту;
модель OM, команда ATC, журнал преобразования и контрольное значение;
Предварительная обработка, вывод, постобработка и код бизнес-интерфейса;
Операционная система, CANN, пакет оператора и список зависимых версий;
Выборочные результаты проверки, записи различий и отчеты об испытаниях производительности;
Инструкции по настройке, запуску службы, ведению журнала, обновлению, резервному копированию и откату.

Winge Technology может выполнять работу по миграции модели вместе с камерами, оптикой, ROI, I/O, интерфейсами, отслеживанием результатов и локальным развертыванием, что делает вывод модели частью полной системы контроля сборки, а не изолированной демонстрацией модели.

Какие проблемы, скорее всего, повлияют на результаты миграции?

вопрос	Общие симптомы	направление обработки
Определения входных данных несовместимы	Общий сдвиг результатов или аномальный уровень достоверности	Фиксированный цвет, размер, нормализация и тензорное расположение.
Оператор или форма несовместимы.	Преобразование ATC завершается неудачей или изменяется структура вывода.	Переписывание графа, замена оператора, динамические шестерни или индивидуальные операторы
Непоследовательная постобработка	Количество, расположение или категория кадров обнаружения различаются.	Унифицированное декодирование, пороговая обработка, NMS и восстановление координат.
Комбинация версий не фиксирована	Одна и та же модель работает по-разному в разных средах.	Фиксированная система, CANN, пакет оператора и запись о строительстве OM
Только тестирование модели требует времени	Живой бит по-прежнему не соответствует требованиям	Полная связь от сбора данных измерений до вывода результатов
Отсутствие независимого сбора валидации.	Невозможно определить, сохраняет ли миграция бизнес-результаты.	Используйте образцы OK, NG и граничные образцы, которые не участвуют в настройке параметров.

Часто задаваемые вопросы

Могут ли модели ONNX работать непосредственно на Ascend NPU?

Обычно необходимо использовать ATC для преобразования модели ONNX в автономную модель OM на основе целевого процессора Ascend и среды CANN, а затем загрузить и выполнить ее через интерфейсы на стороне устройства, такие как AscendCL.

Означает ли преобразование для создания файлов OM, что миграция завершена?

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

Нужно ли менять все традиционные правила видения на нейронные сети?

Нет необходимости. Правила ROI с фиксированными позициями и четкими границами могут продолжать сохраняться; Модели классификации, обнаружения объектов или сегментации используются для обработки изменений категорий, сложного фона и задач семантического распознавания, и эти две модели можно объединить в одном приложении Atlas.

Можно ли использовать одну и ту же модель OM непосредственно для всех устройств Atlas?

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

Как определить, совпадают ли результаты до и после миграции?

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

официальные источники

Huawei Ascend: модель ONNX преобразована в модель OM

https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html

Huawei Ascend: параметры командной строки УВД и ограничения оператора

https://www.hiascend.com/document/detail/en/canncommercial/850/devaids/atctool/atlasatc_16_0039.html

Huawei Ascend: построение модели AscendCL и разработка приложений

https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL и родственные названия принадлежат их правообладателям. В этой статье объясняются методы адаптации, предоставляемые Winge Technology для проектов видения сборки, и это не означает, что соответствующие правообладатели участвуют в конкретном проекте или одобряют его. Возможности оборудования и инструментов регулируются соответствующими официальными версиями документов, а результаты проекта зависят от фактической модели, образцов, оборудования и условий приемки.