🥇Автоматическая проверка требований ТЗ в процессе динамического моделирования

Продолжая тему «Какие ваши доказательства?», посмотрим на проблему математического моделирования с другой стороны. После того как мы убедились, что модель соответствует сермяжной правде жизни, можно отвечать на основной вопрос: «а что, собственно, мы тут имеем?». Создавая модель технического объекта, мы, как правило, хотим убедиться, что этот объект будет соответствовать нашим ожиданиям. Для этого и проводятся динамические расчёты процессов и результат сравнивается с требованиями. Это и есть цифровой двойник, виртуальный прототип и прочее. модные шняги, которые на стадии проектирования решают задачу, как сделать так, чтобы мы получили то, что планировали.

Как же нам быстро убедится что наша система это именно то что мы проектируем, полетит ли или поплывет ли, наша конструкция? А если полетит то как высоко? А если поплывет, то как глубоко?

В данной статье рассматривается автоматизация проверки выполнения требований технического здания при создании динамических моделей технических систем. В качестве примера посмотрим на элемент технического задания для системы воздушного охлаждения летательного аппарата.

Мы рассматриваем те требования, которые можно выразить численно и проверить математически на основании конкретной расчетной модели. Понятно, что это только часть общих требований к любой технической системе, но именно на их проверку мы и тратим время, нервы и деньги на создание динамических моделей объекта.

При описании технических требований в виде документа можно выделить несколько видов различных требований, каждое из которых требует различных подходов для формирования автоматической проверки выполнения требований.

Например, рассмотрим вот такой маленький, но реальный набор требований:

Температура атмосферного воздуха на входе в СВО:
на стоянке − от минус 35 до 35 ºС,
в полете − от минус 35 до 39 ºС.

Статическое давление атмосферного воздуха в полете − от 700 до 1013 ГПа (от 526 до 760 мм рт. ст.).

Полное давление воздуха на входе в воздухозаборник СВО в полете − от 754 до 1200 ГПа (от 566 до 1050 мм рт. Ст.).

Температура охлаждающего воздуха:
на стоянке − не более 27 ºС, для технических блоков − не более 29 ºС,
в полете − не более 25 ºС, для технических блоков − не более 27 ºС.

Расход охлаждающего воздуха:
на стоянке − не менее 708 кг/ч,
в полете − не менее 660 кг/ч.

Температура воздуха в приборных отсеках − не более 60 ºС.

Количество мелкодисперсной свободной влаги в охлаждающем воздухе − не более 2 г/кг сухого воздуха.

Даже в таком ограниченном наборе требований можно выделить по крайней мере две категории, которые нужно по-разному обрабатывать в системе:

требования условий эксплуатации системы (п.п. 1-3);
параметрические требований к системе (п.п. 3-7).

Требования условий эксплуатации системы
Внешние условия для разрабатываемой системы при моделировании могут задаваться как граничные условия, либо как результат работы общей системы.
При динамическом моделировании необходимо убедиться, что заданные режимы работы покрываются процессом моделирования.

Параметрические требования к системе
Данные требования представляют собой параметры, обеспечиваемые самой системой. В процессе моделирования мы можем получить данные параметры как результаты расчета и убедиться, что требования выполняются в каждом конкретном расчете.

Идентификация и кодировка требований

Для удобства работы с требованиями существующие стандарты рекомендуют осуществить присвоение идентификатора каждому требованию. При присвоении идентификаторов очень желательно использовать единую систему кодирования.

Код требования может быть просто числом, отражающим порядковый номер требования, а может содержать в себе код типа требования, код системы или агрегата, к которому он применяется, код параметра, код расположения и многое другое, что может вообразить себе инженер. (вариант использования кодирования смотри в статье)

В таблице 1 приведен простой пример кодирования требований.

код источника требований R- требования ТЗ;
код тип требований Е – требования – параметры внешней среды, или условия эксплуатации
S — требования обеспечиваемые системой;
код состояния самолета 0 – любое, G – на стоянке, F – в полете;
код типа физических параметров T – температура, P – давление, G – расход, влажность H;
номер порядковый требования.

ID Требования	Описание	Параметр
REGT01	Температура атмосферного воздуха на входе в СВО: на стоянке — от минус 35ºС. до 35 ºС.
REFT01	Температура атмосферного воздуха на входе в СВО: в полете — от минус 35 ºС до 39 ºС.
REFP01	Статическое давление атмосферного воздуха в полете от 700 до 1013 гПа (от 526 до 760 мм рт. ст.).
REFP02	Полное давление воздуха на входе в воздухозаборник СВО в полете от 754 до 1200 гПа (от 566 до 1050 мм рт. ст.).
RSGT01	Температура охлаждающего воздуха: на стоянке не более 27 ºС
RSGT02	Температура охлаждающего воздуха: на стоянке, для технических блоков не более 29 ºС
RSFT01	Температура охлаждающего воздуха в полете не более 25 ºС
RSFT02	Температура охлаждающего воздуха: в полете, для технических блоков не более 27 ºС
RSGG01	Расход охлаждающего воздуха: на стоянке не менее 708 кг/ч
RSFG01	Расход охлаждающего воздуха: в полете не менее 660 кг/ч
RS0T01	Температура воздуха в приборных отсеках не более 60 ºС
RSH01	Количество мелкодисперсной свободной влаги в охлаждающем воздухе не более 2 г/кг сухого воздуха

Проект системы проверки требований.

Для каждого расчетного требования есть алгоритм оценки соответствия расчетных параметров и заданных в требовании параметров. По большому счету, любая система управления всегда содержит в себе алгоритмы проверки требований просто по умолчанию. И даже любой регулятор их содержит. Если температура вышла за пределы, включается кондиционер. Таким образом, первый этап любого регулирования – проверка соответствия параметров требованию.

А раз проверка – это алгоритм, то можно использовать те же самые средства и инструменты, которые мы используем для создания программ управления. Например, среда SimInTech позволяет создавать пакеты проектов, содержащие различные части модели, выполненные в виде отдельных проектов (модель объекта, модель системы управления, модель окружающей среды и т.п.).

Проект проверки требований в этом случае становится таким же проектом алгоритмов и подключается к пакету модели. И в режиме динамического моделирования выполняет анализ на соответствие требований ТЗ.

Возможный пример оформления проекта системы приведен на рисунке 1.

Рисунок 1. Пример оформления проекта проверки.

Также как для алгоритмов управления требования можно оформлять виде набора листов. Для удобства работы с алгоритмами в средах структурного моделирования типа SimInTech, Simulink, AmeSim используются возможности создания многоуровневых структур в виде субмоделей. Такая организация позволяет группировать различные требования в наборы для упрощения работы с массивом требований, как это делается для алгоритмов управления (см. рис. 2).

Рисунок 2. Иерархическая структура модели проверки требований.

Например, в рассматриваемом случае выделено две группы: требования для окружения и требования непосредственно к системе. Поэтому используется двух уровневая структура данных: две группы, каждая из которых является листом алгоритма.

Для подключения данных к модели используется стандартная схема формирования базы данных сигналов, в которой хранятся данные для обмена между частями проекта.

При создании и тестировании ПО в данную базу помещаются показания датчиков (аналогов реальных датчиков системы), которые используются системой управления.
Для проекта тестирования в этой же базе данных могут сохранятся любые параметры, рассчитываемые в динамической модели, и таким образом использоваться для проверки выполнения требований.

Сама динамическая модель в этом случае может быть выполнена в любой системе математического моделирования или даже в виде исполняемой программы. Единственное требование – наличие программных интерфейсов для выдачи данных по моделированию во внешнюю среду.

Рисунок 3. Подключение проекта проверки к комплексной модели.

Пример базового листа проверки требований представлен на рисунке 4. С точки зрения разработчика, он представляет собой обычную расчетную схему, на которой в графическом виде представлен алгоритм проверки требований.

Рисунок 4. Лист проверки требований.

Основные части листа проверки описаны на рисунке 5. Алгоритм проверки формируется аналогично расчетным схемам алгоритмов управления. В правой части находится блок чтения сигналов из базы данных. В этом блоке происходит обращение к базе данных сигналов во время моделирования.

Полученные сигналы анализируются для вычисления условий проверки требований. В рассматриваемом случае выполняется анализ высоты для определения положения самолета (находится ли он на стоянке или в полете). Для этой цели можно использовать и другие сигналы и рассчитываемые параметры модели.

Условия проверки и проверяемые параметры передаются в типовые блоки проверки, в которых выполняется анализ данных параметров на соответствие заданным требованиям. Результаты записываются в базу данных сигналов таким образом, что их можно использовать для автоматического формирования чеклиста.

Рисунок 5. Структура расчетного листа проверки требований.

В качестве проверяемых параметров необязательно использовать сигналы, содержащиеся в базе данных, которые управляются параметрами, рассчитываемыми в процессе моделирования. Ничто не мешает в рамках проекта требований осуществить дополнительные расчеты, также как мы рассчитываем условия проверки.

Например, такое требование:

Количество включений корректирующей системы во время полета до цели не должно превышать число 5, а общее время работы корректирующей системы не должно превышать 30 секунд.

В этом случае в расчетную схему проекта требований добавляется алгоритм счетчика количества включений и общего времени работы.

Типовой блок проверки требований.

Каждый типовой бок проверки требований предназначен для расчета выполнения требования определенного типа. Например, в требованиях к окружению присутствует диапазон рабочих температур окружающего воздуха на стоянке и в полете. Данный блок должен получить в качестве параметра температуру воздуха в модели и определить покрывает ли данный параметр заданный диапазон температур./p>

Блок содержит два входных порта, param и condition.

На первый подается проверяемый параметр. В данном случае «Температура внешней среды».

На второй порт подается булева переменная – условие выполнения проверки.

Если на второй вход приходит TRUE (1), то блок выполняет расчет проверки требования.

Если на второй вход приходит FALSE (0), то условия проверки не выполняются. Это необходимо для того, чтобы можно было учесть условия расчёта. В нашем случае этот вход используется, чтобы включать или отключать проверку в зависимости от состояния модели. Если ЛА во время моделирования находится на земле, то относящиеся к полету требования не проверяются, и наоборот – если ЛА находится в полете, то не проверяются требования, связанные с работой на стоянке.

Этот вход также можно использовать при настройке модели, например на начальном этапе расчёта. Когда модель приводится в требуемое состояния, блоки проверки отключены, но как только система выходит на требуемый режим работы, блоки проверки включаются.

В качестве параметров данного блока задаются:

граничные условия: верхний (UpLimit) и нижний (DownLimit) пределы диапазонов, которые должны быть проверены;
требуемое время выдержки системы на граничных диапазонах (TimeInterval) в секундах;
идентификатор требования ReqName;
допустимость выхода за диапазон Out_range – булевская переменная, которая определяет, является ли нарушением требования выход значения за проверяемый диапазон.

В некоторых случаях выход проверяемого значения означает, что система имеет запас и может работать за пределами рабочего диапазона. В других случаях выход означает, что система не справляется с удержанием заданных параметров в пределах диапазона.

Рисунок 6. Типовой блок проверки свойства на схеме и его параметры.

В результате расчета данного блока на выходе формируется переменная Result, которая принимает следующие значения:

0 – rNone, значение не определено;
1 – rDone, требование выполняется;
2 – rFault, требование не выполняется.

Изображение блока содержит:

текст идентификатора;
цифровые отображения параметров пределов измерения;
цветовой идентификатор состояния параметра.

Внутри блока может находится достаточно сложная схема логического вывода.

Например, для проверки рабочего диапазона температур блока, приведенного на рисунке 6, внутренняя схема представлена на рисунке 7.

Рисунок 7. Внутренняя схема блока определения диапазона температур.

Внутри блока схемы используются свойства, заданные в параметрах блока.
Кроме анализа соответствия требований внутренняя схема блока содержит график, необходимый для вывода результатов моделирования. Данный график может быть использован как для просмотра во время расчета, так и для анализа результатов после расчета.

Результаты расчета передаются на выход блока и одновременно записываются в общий файл отчета, который создается на основании результатов по всему проекту. (см. рис. 8)

Пример отчета, созданного по результатам моделирования, представляет собой файл html, созданный по заданному формату. Формат может быть произвольным образом настроен на формат, принятый в конкретной организацией.

Рисунок 8. Пример файла отчета по результатам моделирования.

В данном примере настройка формы отчета выполняется непосредственно в свойствах проекта, а формат в таблице задается как глобальные сигналы проекта. В этом случае SimInTech сам решает задачу настройки отчета, а блок записи результатов в файл использует эти строки для записи в файл отчета.

Рисунок 9. Настройка формата отчета в глобальных сигналах проекта

Использование базы данных сигналов для требований.

Для автоматизации работы с настройками свойств для каждого типового блока создается типовая структура в базе данных сигналов. (см. рис. 10)

Рисунок 10. Пример структуры блока проверки требования в базе данных сигналов.

База данных сигналов, обеспечивает:

Хранение всех необходимых параметров требований к системе.
Удобный просмотр существующих в проекте требований из заданных параметров и текущих результатов моделирования.
Настройку одного блока, группы блоков с использованием скриптового языка программирования. Изменения в базе данных сигналов приводят к изменению значений свойств блока на схеме.
Хранение текстовых описаний, ссылки на пункты ТЗ или идентификаторы в системе управления требованиями.

Структуры базы данных сигналов для требований могут быть легко настроены на работу со сторонней системой управления требованиями, Общая схема взаимодействия с системами управления требований представлена на рисунке 11.

Рисунок 11. Схема взаимодействия с системой управления требований.

Последовательность взаимодействия тестового проекта SimInTech с системой управления требования следующая:

Техническое задание разбивается на требования.
Выделяются такие требования технического задания, которые могут быть проверены путем математического моделирования технических процессов.
Атрибуты выделенных требований передаются в базу данных сигналов SimInTech в структуры типовых блоков (например, максимальная и минимальная температура).
В процессе расчета данные структур передаются в расчетные схемы блоков, выполняется анализ и результаты сохраняются базу данных сигналов.
По завершении расчета результаты анализа передаются в систему управления требованиями.

Этапы работы с требованиями 3 — 5 могут повторятся во время процесса проектирования, когда происходят изменения в конструкции и (или) требованиях и, соответственно, необходима повторная проверка влияния внесенных изменений.

Выводы.

Созданный прототип системы обеспечивает значительное сокращение времени анализа существующих моделей, на предмет соответствия требованиям ТЗ.
Предлагаемая технология тестирования использует уже существующие динамические модели и может быть использована даже для любых динамических моделей, в том числе выполненных не в среде SimInTech.
Использование пакетной организации данных позволяет создавать пакеты проверки требований, параллельно с разработкой моделей, или даже использовать данные пакеты в качестве технического задания на разработку моделей.
Технология может быть без существенных затрат интегрирована с существующими системами управления требованиями.

Для тех кто дочитал до конца, ссылка на видео с демонстрации работы прототипа.

Источник: habr.com