Устройства для обработки сигналов?

Question

я наткнулся на подобных проблем, как это: Test driven development for signal processing libraries

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

Таким образом, программа ввода ввода> запуска программы> проверка вывода не подходит для обработки сигналов.

Соответствует ли соответствие требованиям к характеристикам спецификациям, что ошибок нет? Конечно нет. Тогда, если это соответствует требованию, зачем беспокоиться? Потому что жуки будут кусаться, когда-нибудь они будут.

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

У Matlab есть хорошая коллекция библиотек, и у нее есть контроль границ, управление памятью, и это двойная точность, поэтому сравнение с кодом Matlab позволяет вывести указатель из-за границы, переполнение стека и оценивать достаточную точность целых чисел, но это не дает ответа на вопрос, как «, что если MATLAB эквивалент сделал это неправильно, слишком?»

Я могу только сказать себе: попробуйте написать MATLAB эквивалент простой, так что близко к «так просто, что очевидно, нет ошибки «

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

Прошло более двух лет со времени последнего сообщения. У меня есть некоторые новые разработки в этой области.

Просьба поделиться со мной, как практикующими, вашими идеями и мнениями.

Answer 1

GNU Radio - это ориентированная на поток структура обработки сигналов, которая поставляется с большой библиотекой алгоритмов обработки сигналов, большую часть времени инкапсулированных в блоки.

Конечно, мы проводим много модульных испытаний, и мы часто находим ошибки, регрессии или угловые случаи на их основе, поэтому это имеет решающее значение для процесса разработки GNU Radio. Я не совсем уверен, что буду называть наш подход TDD, но я не думаю, что здесь есть смысл.

Дело в том, что , конечно, Обработка сигнала может быть протестирована. Почему бы и нет? Вы указываете входы, и ожидаемый результат, особенно если вы инкапсулируете свои шаги в блоках обработки сигналов. Теперь, хотя это не так просто, как ваш первый тестовый тест типа assert(square(2)==4), как разработчик алгоритма обработки сигналов, вы должны быть настолько хорошо осведомлены о том, что вы должны делать, и как вы можете математически проверьте, что обычно могут быть записаны тестовые примеры.

Теперь я могу понять вашу точку зрения: «мой тестовый сценарий настолько сложный, что могут иметь собственные ошибки», но это всего лишь указание на то, что вы еще не структурировали свою проблему в достаточно сложных подзадачах. Как вы уже заметили, мне нравится ссылаться на GNU Radio, поэтому давайте сделаем это снова: хороший тестовый процесс разработки попытается получить как можно много повторно используемых, проверенных модулей. Хорошо протестированные подразумевают, что их поведение настолько хорошо определено, что вы можете его протестировать. GNU Radio делает это в виде простых блоков, таких как «multiply», или более сложных, например «schmidl & cox OFDM sync».Вы начинаете с проверки своих более простых, а затем проверяете полную систему, в этом случае «делать информационные биты, которые я подаю в мой модулятор OFDM, из моего модулятора OFDM». Это работает как в обработке сигналов, так и в любом другом жанре - это просто требует высокого уровня понимания, что часто является тем, что люди с чистой базой компьютерных наук должны приобретать в процессе написания программного обеспечения обработки сигналов (люди, обрабатывающие сигналы , с другой стороны, часто борются с поиском хороших решений проблем, хорошо известных и легко решаемых специалистам CS); Я всегда надеюсь, что этот факт побуждает людей писать лучшие тесты (и читать больше книг тоже)).

Answer 2

Есть две проблемы здесь стоит обсуждать:

1. разложение дизайна.
2. Практическая реализация и поддержка

Они тесно связаны между собой, но различные аспекты адресации TDD в приложениях DSP.

Если в принципе разумно разлагать конструкцию фильтра «для умножения блоков», на самом деле нецелесообразно достичь желаемого тестирования. Это эквивалентно запросу разложить строковый поиск на сравнение символов или умножить на блок shift-test-and-add. Это может быть возможно, но действительно ли тесты на самом деле дают возможность проверить значимые единицы или выявить вероятный алгоритм или ошибки кодирования.

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

В дополнение к рассмотрению результата адаптивной проблемы PR, требующей больших данных или информации о состоянии, становится сходной, но неоднородной проблемой.

Мой специальный ответ заключался в создании тестового цикла, который управляет DSP и тестирует файлы, определяющие тестовые примеры. В настоящее время автономно автономно и ограничено не-native hw. Существуют ли альтернативы, которые люди используют для перемещения теста ближе к цели.