Этот пример является второй частью двухсерийной серии, посвященной проектированию и тестированию радиолокационной системы в Simulink ® на основе набора требований к производительности. В нем рассматриваются испытания модели, разработанной в части 1, и проверка первоначальных требований. В нем показано, как использовать Simulink Test™ для настройки наборов тестов для проверки требований, связанных с компонентами системы. В примере также рассматривается сценарий, когда указанные требования были пересмотрены, что привело к изменениям в конструкции и испытаниях.
Часть 1 этого примера начинается с набора требований к производительности. Разрабатывает архитектурную модель радиолокационной системы с использованием Simulink System Composer™. Эта модель архитектуры используется в качестве виртуального испытательного стенда для тестирования и проверки конструкций радиолокационной системы. В части 1 показано, как использовать Simulink Requirements™ для привязки требований к компонентам архитектуры. В нем также показано, как реализовать отдельные компоненты архитектуры с помощью Simulink.
Перед настройкой тестов загружаем модель, построенную в части 1 примера.
open_system('slexRadarArchitectureExample');Simulink Test Manager - это инструмент для создания наборов тестов для модели. Чтобы получить доступ к диспетчеру тестов, щелкните Simulink Test на вкладке Apps, перейдите на вкладку Tests и выберите Simulink Test Manager. Чтобы приступить к тестам, мы создадим новый тестовый файл для модели, щелкнув Новый тестовый файл (New Test File). Затем мы добавим два отдельных набора тестов по одному для каждого требования. Тестовые наборы могут быть дополнительно сконфигурированы следующим образом:
Добавление описания к каждому набору тестов для краткого описания тестируемых функций;
Связывание набора тестов с одним или несколькими требованиями. Для проверки требований тесты в наборе тестов должны пройти;
Добавление обратных вызовов для установки до и после выполнения теста. В этом примере необходимо добавить глобальную переменную в базовую рабочую область для агрегирования результатов нескольких запусков Monte Carlo в одном наборе тестов.
Далее мы конфигурируем тесты в комплектах тестов. Изменения вносятся только в разделах «Тестируемая система», «Переопределения параметров», «Итерации» и «Пользовательские критерии».
В разделе Проверка системы в поле Модель должно быть задано имя модели, которое в данном примере - slexRadararArchitectureExample.
Раздел «Переопределения параметров» используется для назначения различных значений параметрам в базовой рабочей области во время выполнения теста. В этом разделе указываются целевые параметры для теста максимальной дальности и теста разрешения дальности.
Для испытания максимальной дальности задаем одну цель с RCS 1 м2 на дальности 6000 м от РЛС, как указано в R1.
Для проверки разрешающей способности по дальности задаем две цели с различными RCS, которые разделены по дальности на 70 м в соответствии с требованиями R2.
Из-за случайного шума и эффектов флуктуации цели мы можем проверить только усредненные характеристики радиолокационной системы, собранные в ходе нескольких тестовых запусков. Раздел «Итерации» теста можно использовать для настройки выполнения теста несколько раз для реализации моделирования Монте-Карло. Мы добавим пользовательский сценарий в подраздел «Итерации по сценариям». В этом примере в тест добавляется только 10 итераций. Однако для надежной проверки производительности системы потребуется больше итераций.
В разделе Настраиваемые критерии (Custom Criteria) можно указать настраиваемое правило, которое проверяет результаты теста в конце каждой итерации. Настраиваем его на выполнение helperslexRadarArchitectureTestCriteria вспомогательная функция, которая обрабатывает результаты каждой итерации теста и сохраняет их в detectionResults переменная в базовой рабочей области. Функция вычисляет количество переходов порога обнаружения. Если это число равно количеству целевых объектов в тесте, итерации считаются пройденными, в противном случае итерация объявляется неудачной. На последней итерации helperslexRadarArchitectureTestCriteria вычисляет общее число переданных итераций. Вторым аргументом для этой вспомогательной функции является процент итераций, которые должны пройти для всего теста. Для теста максимального диапазона требуется, чтобы прошло не менее 90% всех итераций. Поскольку тест разрешения диапазона моделирует две независимые цели, он требует, чтобы не менее 80% всех итераций теста были успешными.
Откройте этот набор тестов в диспетчере тестов.
open('slexRadarArchitectureTests.mldatx')После добавления тестов и их связывания с требованиями статус требований в редакторе требований указывает на то, что проверка была добавлена, но тесты еще не выполнены.
Теперь тесты могут быть запущены. После выполнения обоих наборов тестов можно проверить результаты каждой отдельной итерации с помощью инспектора данных. Вспомогательная функция настраиваемых критериев также печатает статус каждой итерации в окне команд.
Поскольку оба теста прошли, редактор требований теперь показывает, что оба требования были реализованы и проверены.
Обычно в процессе проектирования первоначальные требования пересматриваются и изменяются. В этом примере предполагается, что максимальный диапазон был увеличен до 8000 м, а разрешение диапазона было установлено на 35 м. Требования к обновлению:
R1: РЛС должна обнаруживать цель Swerling 1 Case с сечением РЛС 1 на дальности 8000 м с вероятностью обнаружения 0,9 и вероятностью ложной тревоги 1е-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');
Удобным способом изменения поведения компонентов системы является добавление альтернативной конструкции путем создания варианта. Для этого щелкните правой кнопкой мыши компонент и выберите Добавить вариант. Добавим вариант в 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 может удовлетворять обновленным требованиям, нам необходимо внести соответствующие изменения в испытания, обновив позиции целей.
Установить целевой диапазон в тесте максимальной дальности 8000 м
Изменение дальности цели в тесте разрешения дальности таким образом, чтобы цели располагались на расстоянии 35 м друг от друга
После обновления тестов необходимо устранить все проблемы с изменениями в редакторе требований. Для этого щелкните Показать ссылки (Show Links) на вкладке Требования (Requirements), затем выберите ссылки и нажмите кнопку Очистить все (Clear All) в разделе Изменить информацию (Change Information) на панели Подробно (Details) справа. После устранения проблем можно запустить тесты. Новая конструкция пройдет обновленные тесты и удостоверится, что система удовлетворяет обновленным требованиям, подтверждающим прогнозы, сделанные приложением Radar Designer.
Этот пример является второй частью двухсерийной серии, посвященной проектированию и испытанию радиолокационной системы в Simulink на основе набора требований к производительности. В нем показано, как использовать Simulink Test для тестирования модели, разработанной в части 1, как связать тест с требованиями и как убедиться в том, что требования удовлетворяются с помощью моделирования Монте-Карло. В примере также показано, как отслеживать изменения в требованиях к соответствующим компонентам и как создавать альтернативные конструкции путем добавления вариантов в модель. Часть 1 этого примера начинается с требований, которые должны быть удовлетворены окончательной конструкцией. Он использовал Simulink System Composer для разработки архитектурной модели радиолокационной системы, которая может служить в качестве виртуального испытательного стенда. Затем в части 1 показано, как использовать Simulink Requirements для связывания требований с компонентами и как реализовать отдельные компоненты архитектуры с помощью Simulink.