В этом примере показано, как редактировать требования, связывать требования с их реализацией в модели и проверять их функциональность в контексте приложения БПЛА. Компоненты модели и требования включают в себя руководство и управление БПЛА, реализованным на примере доставки пакета БПЛА.
Пример доставки пакетов БПЛА показывает, как смоделировать небольшой мультикоптерный сценарий, который взлетает, летает и приземляется в другом месте в городской среде. В примере используются инкрементные итерации конструкции для повышения сложности моделирования. В этом примере репрезентативные требования к испытаниям связаны с разделами модели доставки пакетов БПЛА и проверяются с помощью набора тестов.
Чтобы начать работу, откройте пример сценария в реальном времени и получите доступ к вспомогательным файлам, нажав кнопку Открыть сценарий в реальном времени в документации или используя openExample функция.
openExample('uav/AutomateTestingForUAVPackageDeliveryExample');Simulink Requirements™ позволяет создавать, анализировать и управлять требованиями в рамках Simulink™. Этот пример содержит двадцать функциональных требований, определенных для управления и наведения контроллера полета БПЛА. Откройте предоставленный проект Simulink и набор требований. Можно также открыть файл на вкладке Требования приложения Диспетчер требований в Simulink
prj = openProject("verifications/AutomatedTestsPackageDelivery.prj"); open('uavPackageDeliveryReqs.slreqx');
Требования разделены на разделы «Руководство» и «Управление». Эти требования относятся непосредственно к секциям в многороторной модели примера доставки пакета БПЛА. Просмотрите список требований и щелкните элементы, чтобы просмотреть и отредактировать сведения справа.
Simulink Requirements позволяет связать каждое отдельное требование с компонентом модели Simulink, реализующим такое требование. Чтобы связать требования, сначала откройте многороторную модель.
open_system('MultirotorModel');Введите ракурс требований, щелкнув элемент управления «Перспективы» в правом нижнем углу холста модели.
Выберите ракурс «Требования».
В ракурсе требований перейдите к логике руководства и проверьте некоторые из внедренных требований руководства. Требования № 5 и № 6 помечены серым цветом. Пределы команд heading и yaw реализуются блоком Waypoint Follower.
open_system('MultirotorModel/Guidance Logic/Full Guidance Logic/Guidance Stateflow/Guidance Mode Selector/GuidanceLogic.WP');
Кроме того, можно перейти к реализации каждого требования из раздела Ссылки (Links) каждого требования в Редакторе требований (Requirements Editor). Откройте редактор требований. Выберите функциональное требование и перейдите в раздел Ссылки > > Реализовано по на вкладке Подробно справа.
open('uavPackageDeliveryReqs.slreqx');
Щелкните по требованию № 19 (индекс 1.2.1.4). На вкладке Подробно (Details) в разделе Ссылки (Links) щелкните ссылку theta_limit (Links), чтобы перейти к месту реализации требования в многороторной модели. Предел тета блок реализует это требование.
Чтобы обеспечить выполнение каждого из требований, этот пример включает три автоматических теста, выполняемых на модели. Чтобы узнать, как выполняются эти тесты, откройте тестовый файл в диспетчере тестов. Вы должны увидеть два тестовых пакета, ClaringLogicSuite и ControlSystemSuite.
uiopen('MultirotorModelTest.mldatx',1);
В тесте Test Guidance State Transitions используется тестовый жгут для модели. Дополнительные сведения см. в разделе Управление тестовыми жгутами (Simulink Test).
Чтобы увидеть тестовый жгут, щелкните тест Test Guidance State Transitions и разверните раздел теста System Under Test. Нажмите кнопку со стрелкой, чтобы открыть модель:
Электрический жгут содержит редактор сигналов с заранее определенным набором входов для тестирования всех фаз конечного автомата логики наведения, от взлета до посадки.
Для проверки выполнения требований во время моделирования тест реализует шесть временных оценок и связывает каждую из них с требованием. Дополнительные сведения см. в разделе Оценка временной логики с помощью временных оценок (Simulink Test).
Набор тестов системы управления состоит из двух тестов. Один из них был сосредоточен на проверке всех пределов команд контроллера, а другой - на оценке производительности контроллера. В обоих тестах используется тестовый жгут Simulink, сконфигурированный для управления системой управления под некоторыми разумными входами и оценки реакции.
Тест Cmd Limits тестовой системы управления реализует десять оценок проверки границ, чтобы убедиться, что все команды в системе управления правильно насыщены значениями, установленными требованиями. Эти оценки связаны с соответствующими требованиями. Дополнительные сведения об оценках проверки границ см. в разделе Оценка временной логики с помощью временных оценок (Simulink Test).
Тест производительности тестовой системы управления использует базовый тест критериев для оценки того, находится ли система управления в пределах границ или расходится с предварительно записанной базовой линией. Дополнительные сведения см. в разделе Сравнение выходных данных модели с данными опорной структуры (Simulink Test).
Чтобы запустить оба набора тестов, нажмите кнопку «Выполнить» на панели инструментов диспетчера тестов. После выполнения тестов статус результатов отображается в дереве Результаты и артефакты.
В качестве последнего шага откройте редактор требований и включите столбцы Состояние реализации (Implementation State) и Статус проверки (Validation Status) на панели инструментов. Цвета столбцов указывают, было ли выполнено каждое требование и проверено ли оно в ходе теста.
