Промышленное производство
Промышленный Интернет вещей | Промышленные материалы | Техническое обслуживание и ремонт оборудования | Промышленное программирование |
home  MfgRobots >> Промышленное производство >  >> Industrial Internet of Things >> Интернет вещей

Автоматизация тестирования аудиоинтерфейса на встроенных платформах

В наши дни аудиоинтерфейс стал повсеместным. Он доступен на большинстве одноплатных компьютеров (SBC) для промышленного Интернета вещей (IIOT). Доступно несколько типов интерфейсов, от аналогового аудио до цифровых аудиопортов. У каждого типа этого интерфейса есть свои проблемы при проектировании и тестировании. Тестирование этих интерфейсов во время сборки и производства включает в себя полный путь от аналогового или цифрового входного каскада до цифровых аудиовходов блока обработки.

Интерфейс аудио на встроенной платформе и общий поток тракта аудиоданных в среде настройки производственного тестирования показаны ниже (рисунок 1),


Рис. 1. Тестовая установка и интерфейс аудио для встроенной платформы (Источник:автор)

На приведенной выше диаграмме показаны основные блоки / компоненты, присутствующие в пути данных. Присутствующая ИС приемника может быть ИС аналогового внешнего интерфейса, например аналого-цифровым преобразователем (АЦП), или также может быть ИС цифрового аудиоприемника. Выход IC может быть в любом последовательном формате, например, Inter-IC Sound Bus (I2S). Этот интерфейс может передавать необработанные аудиоданные в формате импульсно-кодовой модуляции (PCM).

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

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

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

Метод 1 - субъективное тестирование

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

Учитывая недостатки описанной выше техники, мы разработали инновационный способ тестирования сигналов аудиоинтерфейса и автоматизации всего процесса.

Метод 2 - Автоматическое тестирование

Чтобы понять этот метод автоматического тестирования, важно понимать некоторые фундаментальные концепции интерфейса I2S.

I2S имеет три сигнала - BCLK (битовая синхронизация), WCLK (синхронизация слов), DATA (сигналы данных). Если BCLK или WCLK неправильные (застряли на высоком / низком уровне), тогда порт аудиовхода процессора не сможет захватить и выдаст соответствующий результат, показывающий сбой тактовой частоты. Если с этими сигналами все в порядке, то захват звука будет происходить независимо от значения DATA. Теперь, если DATA застревает на 1 или 0, тогда буфер аудиоданных будет содержать все FFFF или все 0000 для каждой 16-битной выборки. Таким образом, когда мы сгенерируем контрольную сумму MD5, мы получим два соответствующих значения:MD5 (FFFF) и MD5 (0000). Для всех остальных значений аудиоданных контрольная сумма MD5 будет другой. Эта концепция может использоваться для автоматизации и проверки сигналов захвата звука.

Процедура для этого метода заключается в захвате звука, когда звук воспроизводится надлежащим образом и не находится в состоянии отключения звука. Это гарантирует, что наш аудиофайл будет только захвачен, а данные в буфере верны. После того, как буфер аудиоданных захватил около 100 выборок, можно сгенерировать его контрольную сумму MD5. Если сигнал DATA застрял на высоком уровне, его значение контрольной суммы MD5 будет таким же, как MD5 (FFFF), а если оно застряло на низком уровне, то его значение контрольной суммы MD5 будет таким же, как MD5 (0000). Если сигнал DATA переключается, тогда значение контрольной суммы MD5 будет любым другим случайным значением. Следовательно, на основе значения контрольной суммы MD5 мы можем сделать вывод о том, есть ли проблемы с сигналом DATA.

Обычно эти линии I2S будут иметь несколько сигналов данных. Мы можем продемонстрировать это на следующем примере шины I2S с четырьмя сигналами данных DATAx (x =0,1,2,3). Это можно сделать, задав аудиоданные для одного из сигналов DATA и 0 для всех остальных сигналов данных. Таким образом, мы можем сгенерировать контрольную сумму MD5 для захваченных данных всех DATAx (x =0,1,2,3) и подтвердить, что значения контрольной суммы MD5 соответствуют ожидаемым.

Если мы указали аудиоданные только для DATA0, контрольная сумма MD5 для сигналов DATA1-3 должна быть MD5 (0000), а для DATA0 это должно быть какое-то случайное значение. Это можно сделать для всех четырех сигналов данных один за другим в четырех итерациях, как показано в таблице 1.

щелкните, чтобы увеличить изображение

Таблица 1. Итерация аудиотестирования (Источник:автор)

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

Заключение

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


Аюсман Моханти (Ayusman Mohanty) - архитектор продуктов, специализирующийся на создании оборудования для систем видео- и аудиовещания и систем наблюдения. С ним можно связаться через Linkedin.



Интернет вещей

  1. Тестирование программного обеспечения в РТИ
  2. С# интерфейс
  3. Доставка данных из любого места с критически важной скоростью:встраиваемый маршрутизатор серии Cisco ESR6300
  4. Управление данными Интернета вещей при зимнем тестировании
  5. Kontron:новый стандарт встроенных вычислений COM HPC
  6. Чего ожидать от платформ Интернета вещей в 2018 г.
  7. Интернет вещей и встроенная аналитика объединяются, чтобы показать последствия изменения климата в наших са…
  8. Лучшие платформы анализа данных Интернета вещей
  9. 10 лучших платформ IIoT
  10. Как данные в режиме реального времени автоматизируют цепочку поставок с регулируемой температурой