Автоматизированное тестирование

До подготовки тестов загрузите модель, созданную в Части 1 примера.

open_system('slexRadarArchitectureExample')

Менеджер по Simulink Test является инструментом для создания тестовых наборов для модели. Для доступа менеджер по Тесту нажимает на Simulink Test во вкладке Apps, затем перешел к вкладке Tests и нажимает Simulink Test Manager. Чтобы начать с тестами, создайте новый тестовый файл для модели путем нажатия на New Test File. Затем добавьте два отдельных тестовых набора, один для каждого требования. Далее сконфигурируйте тестовые наборы:

Затем сконфигурируйте тесты в тестовых наборах. Изменения внесены только в Системе Под Тестом, Переопределениями Параметра, Итерациями и Пользовательскими разделами Критериев.

Для максимального теста области значений задайте единую цель с 1 м$${}^2$$ эффективная площадь рассеивания (RCS) в области значений 6 000 м от радара, как утверждено в R1.

Для теста разрешения области значений задайте две цели с различным ЭПР, разделенным в области значений на 70 м как требуется R2.

Откройте этот тестовый набор в менеджере по Тесту.

open('slexRadarArchitectureTests.mldatx')

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

Теперь тесты могут быть запущены. После выполнения обоих тестовых наборов смотрите результаты каждой отдельной итерации с помощью Data Inspector. Пользовательская функция помощника критериев также распечатывает состояние каждой итерации к Командному окну.

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

Пересмотренные требования

Распространено, что во время процесса проектирования начальные требования пересмотрены и изменены. Этот пример принимает, что новое максимальное требование области значений составляет 8 000 м, и новое требование разрешения области значений составляет 35 м. Обновленные требования:

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

Чтобы наблюдать изменения в требованиях или в реализациях компонентов системы используют Матрицу трассируемости требований.

Обновленные системные параметры

Новое максимальное требование области значений вне текущей однозначной области значений системы, которая равняется 7 494,8 м. Чтобы удовлетворить новому требованию, увеличьте однозначную область значений. Это может быть выполнено путем понижения PRF. Установка PRF к результатам на 16 кГц в однозначной области значений 9 368,5 м, которая является далеко за пределами необходимой максимальной области значений 8 000 м.

Поскольку текущий радарный проект передает немодулируемые меандры, предел разрешения системы определяется шириной импульса. Текущий предел разрешения области значений составляет 60 м. Новое требование 35 м почти в два раза ниже. Меандр, который удовлетворяет этому требованию, должен был бы быть вдвое более коротким, уменьшив доступную мощность в той же области значений наполовину. Анализ требований с помощью приложения Radar Designer показывает, что эта система не может достигнуть необходимой эффективности обнаружения в максимальной области значений 8 000 м. Достигнуть необходимой максимальной области значений и разрешения области значений, не увеличивая пик передало степень или усиление антенны, примите новую форму волны с продуктом полосы пропускания времени, который больше, чем 1. Установка ширины импульса к 1 $$\mu s$$ и полоса пропускания к 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 $$\mu s$$. Установите полосу пропускания развертки на 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 может удовлетворить обновленным требованиям, сделайте соответствующие модификации к тестам путем обновления целевых положений.

После обновления тестов очистите все проблемы изменения в Редакторе Требований. Нажмите Show Links во вкладке Requirements, затем выберите ссылки и нажмите на кнопку Clear All в разделе Change Information панели Деталей справа. Запустите тест, когда проблемы будут очищены. Новый проект пройдет обновленные тесты и проверит, что система удовлетворяет обновленным требованиям, подтверждающим предсказания, сделанные приложением Radar Designer.

Сводные данные

Этим примером является вторая часть серии из двух частей о том, как спроектировать и протестировать радиолокационную систему в Simulink на основе набора требований к производительности. Это показывает, как использовать Simulink Test, чтобы протестировать модель, разработанную в части 1, как соединить тест с требованиями, и как проверить, что требованиям удовлетворяют путем выполнения симуляций Монте-Карло. Пример также иллюстрирует, как проследить изменения в требованиях к соответствующим компонентам и как создать альтернативные проекты путем добавления вариантов в модель. Часть 1 этого примера запускается с требований, которым должен удовлетворить итоговый проект. Это использует System Composer, чтобы разработать модель архитектуры радиолокационной системы, которая может служить виртуальным испытательным стендом. Часть 1 также показывает, как использовать Simulink Requirements, чтобы соединить требования с компонентами и как реализовать отдельные компоненты архитектуры с помощью Simulink.