SPbGLTU_SimInTech_2020
.pdf
После выполнения всех этих настроек можно переходить к проверке работоспособности распределенной сетевой модели. Для этого надо запустить виртуальные машины и открыть в каждой из них свой проект, используя для загрузки проекта папку \\VBOXSVR\server\ или соответствующий сетевой диск. После того, как на каждом из узлов сети будет открыт свой проект, надо последовательно, начиная с основного проекта, выполнить их инициализацию.
Отметим, что при этом в каждом из проектов расчетное время установится в 0, а статус перейдет в состояние ”Старт” (рис. 6.24). Если в окне основного проекта нажать кнопку ”Пуск”, то начнется распределённый расчет с синхронизацией модельного времени и обменом данными из базы данных сигналов. Таким образом, распределенная модель работает на всех узлах сети. Для остановки ее работы надо в окне основного проекта нажать кнопку ”Стоп” (рис. 6.25).
Рис. 6.24. Начальная инициализация проектов на каждом из узлов сети
.
Так как все проекты уже отлажены, и требуется исследование работы распределенной модели, то в этом случае загрузка основного меню среды разработки SimInTech становится ненужной. Ускорить работу пользователя по загрузке проектов распределенной модели можно, если после запуска виртуальной машины в ее командой строке ввести команду:
"C:\SimInTech\bin\mstarter.exe"/nomainform/exitonclose
<путь_до_проекта>/start
где <путь_до_проекта> на разных узлах будет иметь разные значения:
111
\\VBOXSVR\server\tank_db_main.prt
\\VBOXSVR\server\tank_db_control.prt
\\VBOXSVR\server\tank_db_object.prt
Рис. 6.25. Остановка распределенной системы.
Выполнение этой команды (рис. 6.26) обеспечит загрузку среды SimInTech, открытие нужного проекта и его автоматическую инициализацию, а также скрытие основного меню SimInTech. Кроме того, при закрытии окна проекта будет выполнена автоматическая выгрузка среды SimInTech из памяти компьютера.
Рис. 6.26. Запуск клиента распределенной модели в работу.
Для удобства дальнейшей работы предпочтительнее создать ярлык, чтобы избавиться от необходимости многократного ввода этой команды
112
при каждом запуске проекта. Можно еще более автоматизировать работу, если использовать эту команду в автозагрузке сетевого узла. Тогда при запуске виртуальной машины сразу откроется окно нужного проекта.
Подводя итог этому разделу, можно сделать вывод, что одним из способов реализации распределенных моделей является режим, так на-
зываемого, сетевого расчёта в ручном режиме. Для организации рабо-
ты модели в этом режиме необходимо было выполнить следующие шаги.
Настроить обмен данными через сеть и синхронизацию модельного времени, используя для этого возможности базы данных сигналов SDB.
Инициализировать главный проект с включенным сервером сетевого обмена.
Инициализировать всех клиентов − проекты с включенным удалённым обменом.
Нажать кнопку ”Пуск” в окне главного проекта. При этом все проекты на разных вычислительных узлах запустятся на расчёт.
Следует отметить, что это не единственный режим реализации распределенных моделей, который используется в SimInTech. В частности, есть еще режим запуска сетевого расчёта в автоматизированном режиме (см. раздел 6.6).
6.5. Задание на лабораторную работу
Если все рекомендации, изложенные в текущем разделе, выполнены, то в результате имеется отлаженная комплексная модель на базе пакета проектов (папка tank_db_1) и работоспособная распределенная модель
(папка server).
Задания, которые предстоит выполнить, потребуют модификации и изменения в каждой из этих моделей. При этом работа с пакетом проектов по расширению его функциональности способствует получению более глубоких навыков работы с общесистемной базой данных, а задания по изменению распределенной модели должны дать представление об имеющихся в SimInTech более продвинутых способах запуска сетевого расчета. Исходя из этого подхода к изучению комплексных и распределенных моделей, в рамках данной лабораторной работы необходимо выполнить две группы заданий.
Задания по работе с пакетом проектов и его модификации.
1.Скопировать папку tank_db_1 в папку tank_db_2 , переименовать файл пакета в tank_db_pak2.pak и дальше работать с этим пакетом.
2.Расширить функциональность проекта, который теперь должен работать сразу с двумя объектами управления. Для этого в проекте
113
tank_db_object.prt скопировать полностью фрагмент блоков "Объект управления №1" в "Объект управления №2" и изменить в нем привязку к сигналам базы банных (рис. 6.27).
3.Аналогично изменить и другие проекты, сохранить сделанные изменения. После чего загрузить пакет tank_db_pak2.pak, запустить его на выполнение и протестировать работу комплексной модели, подавая сигналы на клапаны обеих цистерн (рис. 6.28).
4.Познакомиться с возможностями векторной обработки сигналов (см. раздел 6.5 и справку SimInTech [4]). Изменить проект tank_db_control.prt таким образом, чтобы в нем использовалась бы только одна версия алгоритма, который может работать с любым числом панелей и объектов управления, прописанных в базе данных. Выполнить тестирование измененного проекта.
Рис. 6.27. Модификация проекта tank_db_object.prt
5.Добавить в базу данных еще одну группу сигналов, например, Tank3 и убедится в том, что при запуске пакета проектов на выполнение появляется ошибка при загрузке проекта tank_db_control.prt.
6.Для того, чтобы выполнялась проверка возможности работы комплексной модели при текущем состоянии базы данных, а также вы-
114
водилось понятное пользователю сообщения о несогласованности базы данных, необходимо проект tank_db_main.prt дополнить следующим скриптом (рис. 6.29).
Рис. 6.28. Тестирование работы комплексной модели.
Рис. 6.29. Скрипт проверки несогласованности базы данных.
115
Рис. 6.30. Работа пакета проектов при несогласованной базе данных.
7.Проверить работу tank_db_main.prt при запуске пакета на выполнение (рис. 6.30).
8.Привести базу данных в исходное состояние и подготовить пакет проектов для его преобразования в распределенную сетевую модель.
Задания по работе с распределенной моделью и ее сетевому тестированию:
1.Выполнить тестирование новой распределенной модели в режиме сетевого расчёта в ручном режиме.
2.Используя среду виртуализации, настроить распределенную модель для запуска сетевого расчёта в автоматизированном режиме.
3.Используя сегмент реальной сети, выполнить настройку отдельных ее узлов, а также самой распределенной модели для возможности ее работы на отдельных сетевых станциях.
Три дополнительных задания:
1.Предусмотреть на панелях управления индикацию о достижении аварийно высоких и аварийно низких уровнях жидкости в цистернах.
2.Создать новый пакет проектов, который бы использовал расширенную базу данных, которая позволяла бы описывать все параметры модели, включая геометрию каждой из цистерн, индивидуальное время срабатывания каждого из клапанов и т.д.
3.Разработать пакет проектов, который объединил бы в себе возможности ручного и автоматического управления заливкой цистерн.
6.5.Векторная обработка сигналов
При моделировании сложных систем очень часто возникает ситуация, когда необходимо многократно использовать одну и ту же типовую
116
математическую модель. Среда SimInTech позволяет использовать одну математическую модель для нескольких однотипных объектов с помощью механизма векторной обработки сигналов.
В этом разделе рассматриваются некоторые аспекты векторной обработки сигналов на примере разработанной выше комплексной модели, в которой отдельные проекты связаны между собой общесистемной базой данных. Поставим задачу разработки и включения в состав пакета типового блока управления клапанами.
С этой целью в проекте tank_db_control.prt из пакета tank_db_pak2.pak оставим только одну версию алгоритма управления и изменим привязку его входных и выходных блоков к базе данных. Этот алгоритм должен быть общим для всех клапанов модели, поэтому все его внешние сигналы будут векторными. При этом каждый блок чтения или записи сигналов в список должен обрабатывать столько сигналов, сколько клапанов и объектов управления существует в базе данных.
Если в предыдущих заданиях все было выполнено правильно, то в текущей базе данных должно содержаться две группы сигналов (Panel1
и Panel2) категории ObjectPanel, и две группы сигналов (Tank1 и Tank2)
категории ObjectTank. Поэтому сейчас будет рассмотрена возможность реализации того, чтобы входные и выходные блоки проекта tank_db_control.prt получали не один сигнал, а массив сигналов.
Подробно рассмотрим это на примере блока чтение сигнала из списка, который на схеме проекта имеет текстовую подсказку «Закрыт клапан слива». Для реализации поставленной цели необходимо выполнить следующую последовательность действий.
Выполнить двойной клик на блоке, откроется диалоговое окно «Свойства».
В окне «Свойства» перейти в строку «Имена сигналов» и нажать кнопку вызова текстового редактора (рис. 6.31).
Удалить текст, который остался там от предыдущего проекта, и ввести запрос к базе данных, который для этого блока имеет вид:
{query:
category = "ObjectTank"; group = "*";
name = "ValveOutClose" }
117
Рис. 6.31. Окно текстового редактора для свойства signals.
Запрос к базе данных сигналов в SimInTech представляет собой текст в виде одной или нескольких строк, которые заключаются в фигурные скобки. Запрос начинается с ключевого слова query: и содержит несколько полей. Поля между собой разделяются символами точка с запятой. В рассматриваемом примере запрос состоит из трех полей:
category = "ObjectTank" – название категории, из которой надо получить сигналы;
group="*" – название группы сигналов, которая включается в запрос. Символ * означает, что в запрос будут включены все группы сигналов данной категории. В общем случае возможна выборка по произвольному фильтру. Так, например, доступен фильтр вида group = "Tank*".
name = "ValveOutClose" – это поле запроса определяет имя сигнала, который надо получить из базы данных.
Обратите внимание, что для конкретного блока, после окончания ввода запроса к базе данных, изменяется его вид на схеме проекта (рис.
6.32).
Изменения свойств блоков, аналогичные вышеописанным, должны быть выполнены для всех блоков чтения и записи сигналов на схеме данного проекта. При этом надо следить за тем, чтобы строки запроса соответствовали параметрам алгоритма и назначению сигналов в базе данных:
118
Закрыт клапан залива
{query:
category = "ObjectTank"; group = "*";
name = "ValveInClose" }
Рис. 6.32. Изменение вида блока на схеме после ввода запроса.
Кнопка "Залить" |
На клапан залива |
{query: |
{query: |
сategory = |
category = "ObjectTank"; |
"ObjectPanel"; |
group = "*"; |
group = "*"; |
name = "ValveInCmdOpen" |
name = "btnInput" } |
} |
Кнопка "Слить" |
На клапан слива |
{query: |
{query: |
category = |
category = "ObjectTank"; |
"ObjectPanel"; |
group = "*"; |
group = "*"; |
name = "ValveOutCmdOpen" } |
name = "btnOutput" } |
|
После изменения свойств у всех блоков чтения и записи сигналов необходимо сохранить проект tank_db_control.prt и файл пакета tank_db_pak2.pak. Затем надо повторно открыть пакет tank_db_pak2.pak.
119
После запуска его в работу появится возможность управлять разными клапанами различных объектов, используя только один типовой блок управления.
Следует обратить внимание на одну особенность этого проекта. Он будет работать нормально только в том случае, когда количество панелей будет совпадать с количеством объектов управления. Точнее говоря, когда размерности категорий ObjectTank и ObjectPanel совпадают между собой. Если в какой-либо одной из категорий появится новая группа, то при запуске проекта на выполнение будет выдаваться ошибка
(рис. 6.33).
Рис. 6.33. Ошибка при разных размерностях категорий ObjectTank и ObjectPanel.
Использование такого типового векторного алгоритма требует выполнения в пакете дополнительных проверок при его запуске на выполнение. Если принять во внимание, что основным проектом является tank_db_main, то ошибка или даже ее обработка в проекте tank_db_control, может быть просто не видна или не понятна для пользователя основного проекта комплексной модели. Это приводит к мысли о том, что дополнительные проверки по работоспособности алгоритма управления, исходя из текущего состояния общесистемной базы данных, должны выполняться в основном проекте пакета.
120