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

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

open_system('slexRadarArchitectureExample');

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

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

Поскольку максимальная область значений тестирует, мы задаем единую цель с 1 м$${}^2$$ RCS в области значений 6 000 м от радара, как утверждено в R1.

Для теста разрешения области значений мы задаем две цели с различными RCS, которые разделяются в области значений на 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 этого примера, начатого с требований, которым должен удовлетворить итоговый проект. Это использовало Simulink System Composer, чтобы разработать модель архитектуры радиолокационной системы, которая может служить виртуальным испытательным стендом. Часть 1 затем показала, как использовать Simulink Requirements, чтобы соединить требования с компонентами и как реализовать отдельные компоненты архитектуры с помощью Simulink.