При систематической проверке проектной модели на соответствие требованиям процесс разработки включает создание тестовых примеров для каждого требования. Эти тесты проверяют проектную модель, которая используется для создания производственного кода, и помогают получить уверенность в том, что проектная модель удовлетворяет требованиям. Модель спецификации - это исполняемый объект, который позволяет выполнять тестирование на основе требований, используя возможности Simulink ® Design Verifier™.
Если имеется набор требований, написанных на естественном языке, их можно преобразовать в формальные (исполняемые) спецификации с помощью Simulink. Затем они становятся моделью спецификации. В отличие от конструкторской модели, модель спецификации определяет только то, что должно быть сделано, а не то, как это должно быть сделано. Он фиксирует требования на более высоком уровне и скрывает детали на более низком уровне.
Преимущества использования модели спецификации:
Он систематически утверждает набор требований.
Он автоматизирует тестирование на основе требований.
Это помогает выявить недостающие требования, ошибки проектирования или несоответствия в требованиях и модели проектирования на ранней стадии разработки.
Для тестирования на основе требований тестовые примеры, созданные на основе модели спецификации, используются для проверки проектной модели на соответствие требованиям. Выполните следующие действия для тестирования на основе требований с использованием модели спецификации:
Требования к автору в редакторе требований. Запишите требования на естественном языке, описывающем поведение проектируемой системы.
Создайте модель спецификации. Создайте модель спецификации как исполняемое представление требований. Эта операция может выявить проблемы, которые приводят к уточнению требований.
Требования к соединению. Свяжите отдельные требования или вспомогательные требования с деталями модели спецификации.
Создайте тесты для модели спецификации. Создайте по крайней мере один тест для каждого требования, демонстрирующий его соответствие этому требованию.
Создайте подсистему преобразования тестов. В спецификациях и конструкционных моделях может не использоваться один и тот же интерфейс ввода-вывода. Преобразуйте тестовые примеры, созданные на шаге 4, с помощью тестовой системы преобразования.
Разработка модели конструкции. Разработайте модель конструкции независимо, используя документ требований. Свяжите требования с конструкторской моделью.
Проверьте конструкцию и проанализируйте покрытие. Выполните тесты, созданные на шаге 5 для конструкторской модели, которая была разработана на шаге 6, и проверьте, соответствуют ли результаты модели спецификации и требованиям. Создайте отчет о покрытии проектной модели для определения недостающего покрытия и при необходимости уточните требования.
Рабочий процесс модели спецификации
Рассмотрим модель контроллера автопилота, описанную в разделе Использование модели спецификации для тестирования на основе требований. Для этой демонстрации требования состоят из логических и временных условий разомкнутого цикла.
Чтобы создать модель спецификации для требований, выполните следующие действия.
Использование представления высокого уровня для значений сигналов
Определение предварительных условий, эффектов и ожидаемых выходных данных для каждого требования
Перечислите входные и выходные сигналы для модели спецификации, связанные с требованиями. Вы можете игнорировать сигналы, которые не связаны с имеющимися требованиями.
Это входные сигналы для контроллера автопилота, которые основаны на требованиях:
Переключатель включения автопилота: включение/отключение контроллера автопилота
Heading Engage Switch: При включении включает HDG_HOLD_MODE. В противном случае ROLL_HOLD_MODE активен
Roll Reference Target Turn Knob: циферблат, который подает требуемое значение угла крена на контроллер автопилота
Heading Reference Turn Knob: Задает значение уставки для режима курса
Угол крена самолета: текущий мгновенный угол крена самолета
Это выходные сигналы:
Команда Aileron: Вывод на привод элерона
Roll Ref Command: Вывод в окне дисплея значения уставки для привода элерона
Некоторые сигналы представлены в спецификациях на более высоком уровне. Рекомендуется представлять сигналы с использованием высокоуровневых представлений, подобных диапазонам в модели спецификации.
Рассмотрим входной сигнал «Угол крена самолета», который представляет текущий угол крена самолета и принимает любое значение в интервале от -180 до + 180 градусов.
Требования описывают поведение контроллера автопилота в терминах зон. Эти зоны моделируются с помощью перечисления Range.
Эти пять зон показаны на следующем рисунке.
Требования определяют высокоуровневые режимы контроллера точки доступа и их активные состояния следующим образом:
| Режим автопилота | Переключатель включения автопилота | Переключатель захвата заголовка |
|---|---|---|
OFF | ПРОЧЬ | Плевать |
ROLL_HOLD_MODE | НА | ПРОЧЬ |
HDG_HOLD_MODE | НА | НА |
Рассмотрим следующее требование:
"При каждом повороте кнюппеля кнюппель Крен Реперная кнюппель (Roll_Ref_TK) в нормальном диапазоне (между [-30, -3] или [+ 3, + 30] градусов), Roll Reference (Эталон крена) (Roll_Ref_Cmd) должно иметь значение Roll_Ref_TK."
Определение предварительного условия и последствий. Вышеуказанное требование состоит из двух пунктов:
Предварительное условие: Roll_Ref_TK находится либо в отрицательном нормальном диапазоне, [-30, -3], либо в положительном нормальном диапазоне, [+ 3, + 30 ].
Это предварительное условие является простым логическим выражением ИЛИ, поэтому таблицы истинности используются для выражения логических предварительных условий.
Эффект: Задать Roll_Ref_Cmd кому Roll_Ref_TKПредложение effect определяет значения выходного сигнала в ожидаемом диапазоне.
Условие предварительного условия требования определяет, когда оно становится активным, в то время как условие эффекта определяет, что требование будет делать после того, как оно станет активным.
Вышеуказанное требование не влияет на команду Aileron Ail_Cmd вывод, поэтому он рассматривается как Range.All который обозначает набор всех возможных значений.
Создание таблицы истинности требований
Закодируйте предложение предварительного условия требования в раздел «Таблица условий» таблицы истинности, а предложение эффекта - в раздел «Таблица действий».
Для индивидуального отслеживания каждого требования установите для локальной переменной REQ_ID соответствующий идентификатор требования 2.1.
Добавление цели Simulink Design Verifier в таблицу действий с помощью инструкции sldv.test (REQ_ID==2.1). Программа Simulink Design Verifier находит тест, когда выполняется команда REQ_ID 2.1.
Окончательная модель спецификации, полученная с использованием указанного выше рабочего процесса, выглядит следующим образом:
Использование модели спецификации для тестирования на основе требований