Этим примером является вторая часть серии из двух частей о том, как спроектировать и протестировать радиолокационную систему в Simulink® на основе набора требований к производительности. Это обсуждает тестирование модели, разработанной в части 1 и верификации начальных требований. Это показывает, как использовать Simulink Test™ для подготовки тестовых наборов, чтобы проверить требования, соединенные с компонентами системы. Пример также исследует сценарий, когда установленные требования были пересмотрены, ведя к изменениям в проекте и тестах.
Часть 1 этого примера запускается с набора требований к производительности. Это разрабатывает модель архитектуры радиолокационной системы с помощью Simulink System Composer™. Эта модель архитектуры используется как виртуальный испытательный стенд для тестирования и проверки разработок радарных систем. Часть 1 показывает, как использовать Simulink Requirements™, чтобы соединить требования с компонентами архитектуры. Это также показывает, как реализовать отдельные компоненты архитектуры с помощью Simulink.
До подготовки тестов загрузите модель, созданную в Части 1 примера.
open_system('slexRadarArchitectureExample')Менеджер по Simulink Test является инструментом для создания тестовых наборов для модели. Для доступа менеджер по Тесту нажимает на Simulink Test во вкладке Apps, затем перешел к вкладке Tests и нажимает Simulink Test Manager. Чтобы начать с тестами, создайте новый тестовый файл для модели путем нажатия на New Test File. Затем добавьте два отдельных тестовых набора, один для каждого требования. Далее сконфигурируйте тестовые наборы:
Добавление описания к каждому тестовому набору, чтобы вскоре описать, какая функциональность тестируется.
Соединение тестового набора к один или несколько требований. Тесты в тестовом наборе должны передать для требований, которые будут проверены.
Добавление коллбэков для настройки прежде и очистка после тестового прогона. Этот пример требует глобальной переменной в базовом рабочем пространстве для того, чтобы агрегировать результаты нескольких запусков Монте-Карло в одном тестовом наборе.
Затем сконфигурируйте тесты в тестовых наборах. Изменения внесены только в Системе Под Тестом, Переопределениями Параметра, Итерациями и Пользовательскими разделами Критериев.
В Системе Под Экспериментальным участком, устанавливает поле Model на имя модели, которая в этом примере является slexRadarArchitectureExample.
Раздел Parameter Overrides используется, чтобы присвоить различные значения параметрам в базовом рабочем пространстве во время выполнения теста. Используйте этот раздел, чтобы задать целевые параметры для максимального теста области значений и теста разрешения области значений.
Для максимального теста области значений задайте единую цель с 1 м эффективная площадь рассеивания (RCS) в области значений 6 000 м от радара, как утверждено в R1.
Для теста разрешения области значений задайте две цели с различным ЭПР, разделенным в области значений на 70 м как требуется R2.
Из-за случайного шума и целевых эффектов колебания, возможно проверить только усредненную эффективность радиолокационной системы, собранную по нескольким тестовым прогонам. Раздел Iterations теста может использоваться, чтобы сконфигурировать тест, чтобы запуститься многократно, чтобы реализовать симуляции Монте-Карло. Этот пример добавляет пользовательский скрипт в подраздел Итераций В виде сценария, чтобы настроить Монте-Карло. Скрипт выполняет только десять итераций. Чтобы надежно проверить эффективность системы, больше итераций требуется.
Раздел Custom Criteria позволяет вам задавать пользовательское правило, которое проверяет результаты испытаний в конце каждой итерации. Сконфигурируйте его, чтобы запустить helperslexRadarArchitectureTestCriteria функция помощника, что результаты процессов каждой тестовой итерации и хранят их в detectionResults переменная в базовом рабочем пространстве. Эта функция вычисляет количество пороговых пересечений обнаружения. Если этот номер равен количеству целей в тесте, система передает тестовую итерацию, в противном случае итерация объявляется, как отказавший. В последней итерации, helperslexRadarArchitectureTestCriteria вычисляет общее количество переданных итераций. Второй аргумент к этой функции помощника является процентом итераций, которые должны передать для целого теста, чтобы передать. Максимальный тест области значений требует в наименьшем количестве 90% всей передачи итераций. Начиная с тестовых моделей разрешения области значений две независимых цели это требует в наименьшем количестве 80% всех тестовых итераций, успешны.
Откройте этот тестовый набор в менеджере по Тесту.
open('slexRadarArchitectureTests.mldatx')После добавления тестов и соединения их к требованиям, состояние требований в Редакторе Требований указывает, что верификация была добавлена, но тесты еще не были выполнены.
Теперь тесты могут быть запущены. После выполнения обоих тестовых наборов смотрите результаты каждой отдельной итерации с помощью Data Inspector. Пользовательская функция помощника критериев также распечатывает состояние каждой итерации к Командному окну.
Поскольку оба теста передали, Редактор Требований теперь показывает, что оба требования были реализованы и проверены.
Распространено, что во время процесса проектирования начальные требования пересмотрены и изменены. Этот пример принимает, что новое максимальное требование области значений составляет 8 000 м, и новое требование разрешения области значений составляет 35 м. Обновленные требования:
R1 : радар должен обнаружить цель случая Swerling 1 с эффективной площадью рассеивания (RCS) 1 м в области значений 8 000 м с вероятностью обнаружения 0,9 и вероятностью ложного предупреждения 1e-6.
R2 : Когда возвраты обнаруживаются от двух целей случая Swerling 1, разделенных в области значений на 35 м с тем же азимутом, радар должен разрешить две цели и сгенерировать две уникальных цели, сообщают 80 процентов времени.
Внесение изменений в требования в Редакторе Требований сгенерирует проблемы изменения и подсветит состояние Summary соответствующего требования красного цвета. Ссылки на компоненты, которые реализуют измененное требование и к тестам, которые проверяют его, также подсвечены. Таким образом, легко идентифицировать, какие компоненты проекта и который тестирует потребность, которая будет обновлена для того, чтобы обратиться к изменениям в требовании и протестировать их.
Чтобы наблюдать изменения в требованиях или в реализациях компонентов системы используют Матрицу трассируемости требований.
Новое максимальное требование области значений вне текущей однозначной области значений системы, которая равняется 7 494,8 м. Чтобы удовлетворить новому требованию, увеличьте однозначную область значений. Это может быть выполнено путем понижения PRF. Установка PRF к результатам на 16 кГц в однозначной области значений 9 368,5 м, которая является далеко за пределами необходимой максимальной области значений 8 000 м.
Поскольку текущий радарный проект передает немодулируемые меандры, предел разрешения системы определяется шириной импульса. Текущий предел разрешения области значений составляет 60 м. Новое требование 35 м почти в два раза ниже. Меандр, который удовлетворяет этому требованию, должен был бы быть вдвое более коротким, уменьшив доступную мощность в той же области значений наполовину. Анализ требований с помощью приложения Radar Designer показывает, что эта система не может достигнуть необходимой эффективности обнаружения в максимальной области значений 8 000 м. Достигнуть необходимой максимальной области значений и разрешения области значений, не увеличивая пик передало степень или усиление антенны, примите новую форму волны с продуктом полосы пропускания времени, который больше, чем 1. Установка ширины импульса к 1 и полоса пропускания к 5 МГц обеспечит нужное разрешение.
Откройте этот проект в приложении Radar Designer.
radarDesigner('RadarDesigner_LFMWaveform.mat')
Приложение Pulse Waveform Analyzer может использоваться, чтобы выбрать радарную форму волны из нескольких альтернатив. Этот пример использует форму волны LFM.
pulseWaveformAnalyzer('PulseWaveformAnalyzer_LFMWaveform.mat')
Удобный способ изменить поведение компонента системы состоит в том, чтобы добавить альтернативный проект путем создания варианта. Это сделано путем щелчка правой кнопкой по компоненту и выбора Add Variant Choice. Добавьте вариант в Waveform Generator и добавьте поведение Simulink в него, чтобы реализовать генерацию сигналов LFM.
Сконфигурируйте Linear FM блок путем установки ширины импульса на новое значение 1 . Установите полосу пропускания развертки на 5 МГц и свойство PRF к обновленному значению PRF 16 кГц. Запустите модель с формой волны LFM.
% Set the model parameters helperslexRadarArchitectureParameters; % Update the model parameters to use the LFM waveform helperslexRadarArchitectureParametersLFM; simOut = sim('slexRadarArchitectureExample.slx'); data = simOut.logsout{1}.Values.Data; figure; plot(range_gates, data(numel(range_gates)+1:end)); xlabel('Range (m)'); ylabel('Power (W)'); title('Signal Processor Output'); grid on;
Прежде, чем проверить, что радиолокационная система с LFM может удовлетворить обновленным требованиям, сделайте соответствующие модификации к тестам путем обновления целевых положений.
Установите целевой диапазон в максимальном тесте области значений к 8 000 м
Измените целевые диапазоны в тесте разрешения области значений, таким образом, цели расположены в 35 м от друг друга
После обновления тестов очистите все проблемы изменения в Редакторе Требований. Нажмите Show Links во вкладке Requirements, затем выберите ссылки и нажмите на кнопку Clear All в разделе Change Information панели Деталей справа. Запустите тест, когда проблемы будут очищены. Новый проект пройдет обновленные тесты и проверит, что система удовлетворяет обновленным требованиям, подтверждающим предсказания, сделанные приложением Radar Designer.
Этим примером является вторая часть серии из двух частей о том, как спроектировать и протестировать радиолокационную систему в Simulink на основе набора требований к производительности. Это показывает, как использовать Simulink Test, чтобы протестировать модель, разработанную в части 1, как соединить тест с требованиями, и как проверить, что требованиям удовлетворяют путем выполнения симуляций Монте-Карло. Пример также иллюстрирует, как проследить изменения в требованиях к соответствующим компонентам и как создать альтернативные проекты путем добавления вариантов в модель. Часть 1 этого примера запускается с требований, которым должен удовлетворить итоговый проект. Это использует System Composer, чтобы разработать модель архитектуры радиолокационной системы, которая может служить виртуальным испытательным стендом. Часть 1 также показывает, как использовать Simulink Requirements, чтобы соединить требования с компонентами и как реализовать отдельные компоненты архитектуры с помощью Simulink.