Этот пример является второй частью серии из двух частей о том, как проектировать и тестировать радиолокационную систему в Simulink ® на основе набора требований к эффективности. В нем обсуждается тестирование модели, разработанной в Части 1, и верификация первоначальных требований. В нем показано, как использовать Simulink Test™ для настройки тестовых наборов для проверки требований, связанных с компонентами системы. Пример также исследует сценарий, когда заявленные требования были пересмотрены, что привело к изменениям в проекте и тестах.
Часть 1 этого примера начинается с набора требований к эффективности. Он разрабатывает архитектуру модель радиолокационной системы, используя Composer™ Simulink System. Эта модель архитектуры используется в качестве виртуального тестового ложа для тестирования и проверки разработок радарных систем. В части 1 показано, как использовать Simulink Requirements™ для связи требований с компонентами архитектуры. Он также демонстрирует, как реализовать отдельные компоненты архитектуры с помощью Simulink.
Перед настройкой тестов мы загружаем модель, созданную в Части 1 примера.
open_system('slexRadarArchitectureExample');Simulink Test Manager является инструментом для создания наборов тестов для модели. Для доступа к Test Manager щелкните Simulink Test на вкладке Apps, затем перейдите на вкладку Tests и нажмите Simulink Test Manager. Чтобы начать тестирование, мы создадим новый тестовый файл для модели, нажав на New Test File. Затем мы добавляем два отдельных тестовых наборов по одному для каждого требования. Тестовые наборы могут быть дополнительно сконфигурированы с помощью:
Добавление описания к каждому тестовому набору, чтобы вскоре описать, какие функциональные возможности тестируются;
Привязка тестового набора к одному или нескольким требованиям. Тесты в тестовом наборе должны пройти в порядок для проверки требований;
Добавление коллбэков для настройки до и очистки после тестового запуска. В этом примере нам нужна глобальная переменная, добавленная в базовое рабочее пространство в порядок, чтобы агрегировать результаты нескольких запусков Monte Carlo в одном тестовом наборе.
Далее мы конфигурируем тесты в тестовых наборах. Изменения вносятся только в разделах «Тестируемая система», «Параметр», «Итерации» и «Пользовательские критерии».
В разделе System Under Test поле Model должно быть задано как имя модели, которая в этом примере является slexRadarArchitectureExample.
Раздел «Переопределения параметров» используется для назначения различных значений параметрам в базовом рабочем пространстве во время выполнения теста. Мы используем этот раздел, чтобы указать целевые параметры для теста максимальной дальности и теста разрешения области значений.
Для теста максимальной области значений задаем одну цель с 1 м RCS в области значений 6000 м от радара, как указано в R1.
Для теста разрешения области значений мы задаем две цели с различными RCS, которые разделены в области значений 70 м, как требуется R2.
Из-за случайного шума и эффектов флуктуации цели мы можем только проверить среднюю эффективность радиолокационной системы, собранную во время нескольких тестовых запусков. Раздел « Итерации» теста может использоваться, чтобы сконфигурировать тест, чтобы запустить несколько раз, чтобы реализовать симуляции Монте-Карло. Добавим пользовательский скрипт к подразделу Scripted Iterations. В этом примере мы добавляем только 10 итераций к тесту. Однако для надежной проверки эффективности системы потребуется больше итераций.
Раздел «Пользовательские критерии» позволяет задать пользовательское правило, которое проверяет результаты тестирования в конце каждой итерации. Конфигурируем его для запуска helperslexRadarArchitectureTestCriteria вспомогательная функция, которая обрабатывает результаты каждой итерации теста и сохраняет их в detectionResults переменная в базовом рабочем пространстве. Функция вычисляет количество пересечений порога обнаружения. Если это количество равно количеству целей в тесте, итерации считаются прошедшими, в противном случае итерация объявляется неудачной. На последней итерации helperslexRadarArchitectureTestCriteria вычисляет общее количество пройденных итераций. Второй аргумент этой вспомогательной функции - это процент итераций, которые должны пройти для прохождения всего теста. Тест максимальной области значений требует, чтобы прошло не менее 90% всех итераций. Поскольку разрешение области значений экспериментальных моделей двумя независимыми целями, это требует, чтобы не менее 80% всех итераций теста были успешными.
Откройте этот тестовый набор в Диспетчере тестов.
open('slexRadarArchitectureTests.mldatx')После добавления тестов и связывания их с требованиями статус требований в редакторе требований указывает, что верификация была добавлена, но тесты еще не выполнены.
Теперь тесты могут быть запущены. После запуска обоих тестовых наборов мы можем просмотреть результаты каждой отдельной итерации с помощью Data Inspector. Функция помощника пользовательских критериев также печатает состояние каждой итерации в командном окне.
После того, как оба теста прошли, Редактор требований теперь показывает, что оба требования были реализованы и проверены.
Обычно в процессе проекта первоначальные требования пересматриваются и изменяются. В этом примере мы предполагаем, что максимальная область значений был увеличиваема до 8000 м, и разрешение области значений было установлено на 35 м. Требования к обновлению
R1: Радар должен обнаружить цель Swerling 1 Case с радарным сечением (RCS) 1 м в области значений 8000 м с вероятностью обнаружения 0,9 и вероятностью ложного предупреждения 1e-6;
R2: при обнаружении возвратов от двух целей Swerling 1 Case, разделенных в области значений 35 м, с тем же азимутом, радар должен разрешить две цели и сгенерировать два уникальных сообщения о целях 80 процентов времени;
Внесение изменений в требования в редакторе требований приведет к возникновению проблем с изменениями и выделит красным цветом статус «Сводка» соответствующего требования. Ссылки на компоненты, которые реализуют измененное требование, и на тесты, которые его проверяют, также подсвечиваются. Таким образом, легко определить, какие компоненты проекта и какие тесты необходимо обновить, порядок учесть изменения в требовании и протестировать их.
Эффекты изменений требований или реализации компонентов можно также удобно контролировать с помощью матрицы трассируемости требований.
Новое требование максимальной области значений выходит за пределы текущей однозначной области значений системы, который равен 7494,8 м. Чтобы удовлетворить новому требованию, нам нужно увеличить однозначную область значений. Это может быть достигнуто путем снижения PRF. Установка PRF на частоте 16 кГц приведет к однозначной области значений 9368,5 м, что намного выше необходимой максимальной области значений 8000 м.
Поскольку текущий проект радара передаёт немодулированные прямоугольные импульсы, предел разрешения системы определяется шириной импульса. Текущий предел разрешения области значений составляет 60 м. Новое требование 35 м почти в два раза ниже. Прямоугольный импульс, который удовлетворяет этому требованию, должен быть в два раза короче, уменьшая доступную степень в той же области значений вдвое. Анализ требований с помощью приложения Radar Designer показывает, что эта система не сможет достичь необходимой эффективности обнаружения в максимальной области значений 8000 м. Для достижения необходимой максимальной области значений и разрешения области значений, без увеличения пиковой передаваемой степени или усиления антенны, нам нужно принять новую форму волны с продуктом с временной шириной полосы, который больше 1. Установка ширины импульса равной 1 и пропускная способность до 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 , ширина полосы свип-сигнала устанавливается равной 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 может удовлетворить обновленным требованиям, мы должны внести соответствующие изменения в тесты, обновив положения целей.
Установите целевой диапазон в тесте максимальной области значений 8000 м
Измените целевые диапазоны в тесте разрешения области значений, чтобы цели были расположены на 35 м друг от друга
После обновления тестов нам нужно устранить все проблемы с изменениями в редакторе требований. Для этого щелкните Показать ссылки на вкладке Требования, затем выберите ссылки и нажмите кнопку Удалить все в разделе Информация об изменении панели Сведения справа. Когда проблемы будут устранены, тесты могут быть запущены. Новый проект пройдет обновленные тесты и убедится, что система удовлетворяет обновленным требованиям, подтверждающим предсказания, сделанные приложением Radar Designer.
Этот пример является второй частью двухкомпонентной серии о том, как проектировать и тестировать радиолокационную систему в Simulink на основе набора требований к эффективности. Он показал, как использовать Simulink Test, чтобы протестировать модель, разработанную в Части 1, как связать тест с требованиями и как проверить, что требования удовлетворяются при помощи симуляций Монте-Карло. Пример также иллюстрировал, как проследить изменения в требованиях к соответствующим компонентам и как создать альтернативные проекты путем добавления вариантов к модели. Часть 1 этого примера началась с требований, которые должны быть удовлетворены окончательным проектом. Он использовал Simulink System Composer, чтобы разработать архитектуру модель радиолокационной системы, которая может служить виртуальным тестовым ложем. Затем в части 1 показано, как использовать Simulink Requirements для связи требований к компонентам и как реализовать отдельные компоненты архитектуры с помощью Simulink.