Автоматическая проверка

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

open_system('slexRadarArchitectureExample');

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

Далее мы конфигурируем тесты в тестовых наборах. Изменения вносятся только в разделах «Тестируемая система», «Параметр», «Итерации» и «Пользовательские критерии».

Для теста максимальной области значений задаем одну цель с 1 м$${}^2$$ RCS в области значений 6000 м от радара, как указано в R1.

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

Откройте этот тестовый набор в Диспетчере тестов.

open('slexRadarArchitectureTests.mldatx')

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

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

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

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

Обычно в процессе проекта первоначальные требования пересматриваются и изменяются. В этом примере мы предполагаем, что максимальная область значений был увеличиваема до 8000 м, и разрешение области значений было установлено на 35 м. Требования к обновлению

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

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

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

Новое требование максимальной области значений выходит за пределы текущей однозначной области значений системы, который равен 7494,8 м. Чтобы удовлетворить новому требованию, нам нужно увеличить однозначную область значений. Это может быть достигнуто путем снижения PRF. Установка PRF на частоте 16 кГц приведет к однозначной области значений 9368,5 м, что намного выше необходимой максимальной области значений 8000 м.

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

The 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 может удовлетворить обновленным требованиям, мы должны внести соответствующие изменения в тесты, обновив положения целей.

После обновления тестов нам нужно устранить все проблемы с изменениями в редакторе требований. Для этого щелкните Показать ссылки на вкладке Требования, затем выберите ссылки и нажмите кнопку Удалить все в разделе Информация об изменении панели Сведения справа. Когда проблемы будут устранены, тесты могут быть запущены. Новый проект пройдет обновленные тесты и убедится, что система удовлетворяет обновленным требованиям, подтверждающим предсказания, сделанные приложением Radar Designer.

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

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