Продолжая тему «Какие ваши доказательства?», посмотрим на проблему математического моделирования с другой стороны. После того как мы убедились, что модель соответствует сермяжной правде жизни, можно отвечать на основной вопрос: «а что, собственно, мы тут имеем?». Создавая модель технического объекта, мы, как правило, хотим убедиться, что этот объект будет соответствовать нашим ожиданиям. Для этого и проводятся динамические расчёты процессов и результат сравнивается с требованиями. Это и есть цифровой двойник, виртуальный прототип и прочее. модные шняги, которые на стадии проектирования решают задачу, как сделать так, чтобы мы получили то, что планировали. Как же нам быстро убедится что наша система это именно то что мы проектируем, полетит ли или поплывет ли, наша конструкция? А если полетит то как высоко? А если поплывет, то как глубоко? В данной статье рассматривается автоматизация проверки выполнения требований технического здания при создании динамических моделей технических систем. В качестве примера посмотрим на элемент технического задания для системы воздушного охлаждения летательного аппарата. Мы рассматриваем те требования, которые можно выразить численно и проверить математически на основании конкретной расчетной модели. Понятно, что это только часть общих требований к любой технической системе, но именно на их проверку мы и тратим время, нервы и деньги на создание динамических моделей объекта. При описании технических требований в виде документа можно выделить несколько видов различных требований, каждое из которых требует различных подходов для формирования автоматической проверки выполнения требований. Например, рассмотрим вот такой маленький, но реальный набор требований: Даже в таком ограниченном наборе требований можно выделить по крайней мере две категории, которые нужно по-разному обрабатывать в системе: Требования условий эксплуатации системы
Внешние условия для разрабатываемой системы при моделировании могут задаваться как граничные условия, либо как результат работы общей системы.
При динамическом моделировании необходимо убедиться, что заданные режимы работы покрываются процессом моделирования. Параметрические требования к системе 
Данные требования представляют собой параметры, обеспечиваемые самой системой. В процессе моделирования мы можем получить данные параметры как результаты расчета и убедиться, что требования выполняются в каждом конкретном расчете. Для удобства работы с требованиями существующие стандарты рекомендуют осуществить присвоение идентификатора каждому требованию. При присвоении идентификаторов очень желательно использовать единую систему кодирования.  Код требования может быть просто числом, отражающим порядковый номер требования, а может содержать в себе код типа требования, код системы или агрегата, к которому он применяется, код параметра, код расположения и многое другое, что может вообразить себе инженер. (вариант использования кодирования смотри в статье) В таблице 1 приведен простой пример кодирования требований. Для каждого расчетного требования есть алгоритм оценки соответствия расчетных параметров и заданных в требовании параметров. По большому счету, любая система управления всегда содержит в себе алгоритмы проверки требований просто по умолчанию. И даже любой регулятор их содержит. Если температура вышла за пределы, включается кондиционер. Таким образом, первый этап любого регулирования – проверка соответствия параметров требованию. А раз проверка – это алгоритм, то можно использовать те же самые средства и инструменты, которые мы используем для создания программ управления. Например, среда SimInTech позволяет создавать пакеты проектов, содержащие различные части модели, выполненные в виде отдельных проектов (модель объекта, модель системы управления, модель окружающей среды и т.п.). Проект проверки требований в этом случае становится таким же проектом алгоритмов и подключается к пакету модели. И в режиме динамического моделирования выполняет анализ на соответствие требований ТЗ. Возможный пример оформления проекта системы приведен на рисунке 1. 
Рисунок 1. Пример оформления проекта проверки.  Также как для алгоритмов управления требования можно оформлять виде набора листов. Для удобства работы с алгоритмами в средах структурного моделирования типа SimInTech, Simulink, AmeSim используются возможности создания многоуровневых структур в виде субмоделей. Такая организация позволяет группировать различные требования в наборы для упрощения работы с массивом требований, как это делается для алгоритмов управления (см. рис. 2). 
Рисунок 2. Иерархическая структура модели проверки требований.  Например, в рассматриваемом случае выделено две группы: требования для окружения и требования непосредственно к системе. Поэтому используется двух уровневая структура данных: две группы, каждая из которых является листом алгоритма. Для подключения данных к модели используется стандартная схема формирования базы данных сигналов, в которой хранятся данные для обмена между частями проекта. При создании и тестировании ПО в данную базу помещаются показания датчиков (аналогов реальных датчиков системы), которые используются системой управления.
 Для проекта тестирования в этой же базе данных могут сохранятся любые параметры, рассчитываемые в динамической модели, и таким образом использоваться для проверки выполнения требований. 
Рисунок 3. Подключение проекта проверки к комплексной модели.  Пример базового листа проверки требований представлен на рисунке 4. С точки зрения разработчика, он представляет собой обычную расчетную схему, на которой в графическом виде представлен алгоритм проверки требований. 
Рисунок 4. Лист проверки требований.  Основные части листа проверки описаны на рисунке 5. Алгоритм проверки формируется аналогично расчетным схемам алгоритмов управления. В правой части находится блок чтения сигналов из базы данных. В этом блоке происходит обращение к базе данных сигналов во время моделирования. Полученные сигналы анализируются для вычисления условий проверки требований. В рассматриваемом случае выполняется анализ высоты для определения положения самолета (находится ли он на стоянке или в полете). Для этой цели можно использовать и другие сигналы и рассчитываемые параметры модели. Условия проверки и проверяемые параметры передаются в типовые блоки проверки, в которых выполняется анализ данных параметров на соответствие заданным требованиям. Результаты записываются в базу данных сигналов таким образом, что их можно использовать для автоматического формирования чеклиста. 
Рисунок 5. Структура расчетного листа проверки требований. В качестве проверяемых параметров необязательно использовать сигналы, содержащиеся в базе данных, которые управляются параметрами, рассчитываемыми в процессе моделирования. Ничто не мешает в рамках проекта требований осуществить дополнительные расчеты, также как мы рассчитываем условия проверки. Например, такое требование:  Количество включений корректирующей системы во время полета до цели не должно превышать число 5, а общее время работы корректирующей системы не должно превышать 30 секунд. В этом случае в расчетную схему проекта требований добавляется алгоритм счетчика количества включений и общего времени работы. Каждый типовой бок проверки требований предназначен для расчета выполнения требования определенного типа. Например, в требованиях к окружению присутствует диапазон рабочих температур окружающего воздуха на стоянке и в полете. Данный блок должен получить в качестве параметра температуру воздуха в модели и определить покрывает ли данный параметр заданный диапазон температур./p>
 Блок содержит два входных порта, param и condition. На первый подается проверяемый параметр. В данном случае «Температура внешней среды». На второй порт подается булева переменная – условие выполнения проверки. Если на второй вход приходит TRUE (1), то блок выполняет расчет проверки требования. Если на второй вход приходит FALSE (0), то условия проверки не выполняются. Это необходимо для того, чтобы можно было учесть условия расчёта. В нашем случае этот вход используется, чтобы включать или отключать проверку в зависимости от состояния модели. Если ЛА во время моделирования находится на земле, то относящиеся к полету требования не проверяются, и наоборот – если ЛА находится в полете, то не проверяются требования, связанные с работой на стоянке. Этот вход также можно использовать при настройке модели, например на начальном этапе расчёта. Когда модель приводится в требуемое состояния, блоки проверки отключены, но как только система выходит на требуемый режим работы, блоки проверки включаются. В качестве параметров данного блока задаются: В некоторых случаях выход проверяемого значения означает, что система имеет запас и может работать за пределами рабочего диапазона. В других случаях выход означает, что система не справляется с удержанием заданных параметров в пределах диапазона. 
Рисунок 6. Типовой блок проверки свойства на схеме и его параметры. В результате расчета данного блока на выходе формируется переменная Result, которая принимает следующие значения: Изображение блока содержит: Внутри блока может находится достаточно сложная схема логического вывода. Например, для проверки рабочего диапазона температур блока, приведенного на рисунке 6, внутренняя схема представлена на рисунке 7. 
Рисунок 7. Внутренняя схема блока определения диапазона температур. Внутри блока схемы используются свойства, заданные в параметрах блока.
Кроме анализа соответствия требований внутренняя схема блока содержит график, необходимый для вывода результатов моделирования. Данный график может быть использован как для просмотра во время расчета, так и для анализа результатов после расчета. Результаты расчета передаются на выход блока и одновременно записываются в общий файл отчета, который создается на основании результатов по всему проекту. (см. рис. 8) Пример отчета, созданного по результатам моделирования, представляет собой файл html, созданный по заданному формату. Формат может быть произвольным образом настроен на формат, принятый в конкретной организацией. Внутри блока схемы используются свойства, заданные в параметрах блока.
Кроме анализа соответствия требований внутренняя схема блока содержит график, необходимый для вывода результатов моделирования. Данный график может быть использован как для просмотра во время расчета, так и для анализа результатов после расчета. Результаты расчета передаются на выход блока и одновременно записываются в общий файл отчета, который создается на основании результатов по всему проекту. (см. рис. 8) Пример отчета, созданного по результатам моделирования, представляет собой файл html, созданный по заданному формату. Формат может быть произвольным образом настроен на формат, принятый в конкретной организацией. 
Рисунок 8. Пример файла отчета по результатам моделирования. В данном примере настройка формы отчета выполняется непосредственно в свойствах проекта, а формат в таблице задается как глобальные сигналы проекта. В этом случае SimInTech сам решает задачу настройки отчета, а блок записи результатов в файл использует эти строки для записи в файл отчета. 
Рисунок 9. Настройка формата отчета в глобальных сигналах проекта Для автоматизации работы с настройками свойств для каждого типового блока создается типовая структура в базе данных сигналов. (см. рис. 10)  
Рисунок 10. Пример структуры блока проверки требования в базе данных сигналов. База данных сигналов, обеспечивает: Структуры базы данных сигналов для требований могут быть легко настроены на работу со сторонней системой управления требованиями, Общая схема взаимодействия с системами управления требований представлена на рисунке 11. 
Рисунок 11. Схема взаимодействия с системой управления требований. Последовательность взаимодействия тестового проекта SimInTech с системой управления требования следующая: Этапы работы с требованиями 3 — 5 могут повторятся во время процесса проектирования, когда происходят изменения в конструкции и (или) требованиях и, соответственно, необходима повторная проверка влияния внесенных изменений. Для тех кто дочитал до конца, ссылка на видео с демонстрации работы прототипа. Моделирование сложных технических систем