SPbGLTU_SimInTech_2020
.pdf
5. ПРОСТЕЙШИЙ ПОДХОД К ОРГАНИЗАЦИИ РАСПРЕДЕЛЕННОГО СЕТЕВОГО РАСЧЕТА
Лабораторная работа № 5
Целью данной лабораторной работы является:
1.Ознакомиться с базовыми подходами к декомпозиции проекта.
2.Изучить методы использования блоков UDP и TCP серверов и клиентов.
3.Познакомиться с блоками «Мультиплексор» и «Демультиплексор».
4.Выполнить сетевое тестирование распределенного проекта.
5.Получить представление о построении в SimInTech комплексных моделей.
Полноценная организация распределённого сетевого расчёта в SimInTech с обменом данными через сеть и синхронизацией модельного времени реализуется функциями базы данных сигналов SDB и присутствует во всех библиотеках. Однако наличие в системе таких блоков, как UDP и TCP сервер и клиент, позволяет для простейших систем разрабатывать проекты, которые могут запускаться на разных узлах и обмениваться между собой нужной информацией.
Врассмотренных ранее проектах мы явно различали как модели объектов управления и исполнительных органов, так и алгоритмы управления. Совокупность отдельных объектов представляет собой обобщенную модель исследуемого объекта. Она мало зависит от того, будет ли использоваться ручное или автоматическое управление, а больше зависит от тех или иных физических параметров используемого оборудования.
Вэтих условиях более предпочтительным является хранение общей модели физического объекта или процесса на одних компьютерах, а алгоритмов управления на других. При этом следует отметить, что с каждой из этих моделей работают и специалисты совершенно разных специальностей. Поэтому общая декомпозиция упростит и их работу.
Простейшая реализация этого подхода будет рассмотрена на примере использования двух виртуальных машин, сетевые настройки которых позволяют им общаться как между собой, так и с базовым компьютером по IP протоколу.
Пусть IP-адрес основного компьютера будет 192.168.56.1, а адреса виртуальных машин Oracle VM VirtualBox имеют значения 192.168.56.101 и 192.168.56.102, соответственно. На базовом компьютере
71
также организуется общая папка, доступная для каждой из виртуальных машин. Краткая справка по настройке виртуальных машин для этой лабораторной работы приведена в разделе 5.5.
В качестве базы для выполнения данной лабораторной работы будет использован проект по управлению заливом/сливом цистерны, который потребуется разделить на два проекта, каждый из которых должен выполняться на своем компьютере. Но для реализации этой цели сначала надо познакомиться с методами использования в SimInTech блоков UDP и TCP серверов и клиентов.
5.1. Пример использования связи по UDP-протоколу
На первом этапе рассмотрим пример, в котором обмен данными между двумя частями одного проекта организован с использованием клиента и сервера UDP внутри локального хоста, в качестве которого будем использовать виртуальную машину 192.168.56.101.
В общей папке основного компьютера создадим новый проект под именем test_udp1.prt, в котором на входе блока UDP клиента формируется вектор данных. Он организуется с помощью блока «Мультиплексор» (вкладка "Векторные") и включает в себя три элемента: один синусоидальный сигнала и два источника бинарных значений типа «Меандр» (вкладка "Источники"). Приемником вектора сигналов является UDP сервер (вкладка "Обмен данными"), к выходу которого подключен объект временного графика, который позволяет контролировать тождественность передачи (рис. 5.1).
Свойства входных сигналов могут иметь произвольные значения, в том числе и те, что представлены на рис. 5.2.
Рис. 5.1. Тестовый пример работы UDP связи.
72
Рис. 5.2. Настройка свойств синусоидального сигнала и двух меандров.
Для передачи данных используются блоки UDP-клиента и UDPсервера, подробное описание свойств которых дано в разделе 5.6. В данном примере свойства имеют значения, которые представлены на рис. 5.3.
В настройках свойств в качестве типа передаваемых данных выбраны параметры Double и Byte. Указанная размерность данных [1 2] означает, что первый элемент вектора имеет тип Double, а два следующих — Byte. В качестве адреса сервера указан внутренний петлевой адрес протокола TCP/IP, при котором получателем является та же самая станция, с которой происходит посылка.
Рис. 5.3. Настройка свойств UDP-клиента и UDP-сервера.
В общем случае передача может происходить между станциями с разными IP-адресами. Но в любом случае, указанный в свойствах блока сервера UDP порт должен быть открыт для приема на этой станции.
Расположенный на схеме блок UDP-сервера осуществляет прием данных и выдает их для дальнейшей обработки. Принятый сервером вектор может быть разбит на элементы с помощью блока «Демультиплексор». Порт, прослушиваемый сервером, и тип протокола должны совпадать с теми, что указаны в блоке клиента. Если теперь запустить проект на выполнение, то графики сигналов на входе клиента и выходе
73
сервера будут отображать практически одни и те же значения, что говорит о полной корректности передачи данных (рис. 5.4).
Рис. 5.4. Графики сигналов на входе UDP-клиента и выходе UDP-сервера.
Для тестирования проекта зададим в окне «Параметры проекта» на вкладке «Параметры расчета» значение шага расчета, например, равным 0.25 (рис. 5.5). Запустим проект, а после его остановки изменим в свойствах графиков диапазон оси X от 0 до 2 секунд. Задавать тип маркера, цвет линии у графиков, диапазоны осей надо из контекстного меню, кликнув правой клавишей мыши по области графика и выбрав "Свойства", затем в открывшемся окне "Свойства графика" можно установить все параметры отображения графика: в разделе "Ось Х→Максимум" задать 2 и слева выбрать "Точки→Квадратики". Проанализируем скорость передачи по UDP при данном шаге (рис. 5.6). После этого повторим эксперимент для шага 0.1 и менее. Проанализируем результаты (рис.5.7).
Рис. 5.5. Параметры расчета проекта test_udp1.
74
Рис. 5.6. Графики входа UDP-клиента и выхода UDP-сервера за первые 2 секунды.
Рис. 5.7. Графики первых 2-х секунд при шаге 0.1.
Осталось только проверить работу проекта по внешнему IP-адресу, заменив 127.0.0.1 на 192.168.56.101. Если все работает, то можно переходить к отладке распределенного проекта.
Еще раз заменяем 192.168.56.101, но уже на 192.168.56.102.
Используя общую папку основного компьютера, сохраняем проект test_udp1.prt, а потом сохраняем его еще в виде нового проекта под именем test_udp2.prt.
Переходим в окно второй виртуальной машины с IPадресом 192.168.56.102 и загружаем в нее из общей папки проект test_udp2.prt (рис. 5.8).
Удаляем из проекта test_udp2.prt всю его клиентскую часть, оставляя без изменения только его серверную часть (рис. 5.9).
Рис. 5.8. Загрузка проекта test_udp2.prt во вторую виртуальную машину.
75
Рис. 5.9. Модифицированный проект test_udp2.prt.
Открываем окна сразу двух виртуальных машин, запуская в одном из них UDP клиент, а в другом UDP сервер (рис. 5.10).
Приведенный рисунок показывает полное совпадение результатов, что говорит о том, что первое простейшее распределенное приложение в среде SimInTech успешно построено.
Рис. 5.10. Совместное сетевое тестирование проектов test_udp1.prt и test_udp2.prt.
5.2. Использование UDP для построения распределенной модели управления цистерной
Для решения этой задачи в качестве базового будет использован проект, разработанный в разделе 3.3 данного пособия, схема которого приведена на рис. 3.15. Отличие построенного на его основе нового проекта будет заключаться в следующем.
76
Некоторые блоки базового проекта заменяются аналогичными, разработанными в предыдущем разделе, собственными библиотечными блоками.
В проекте явно выделяется две его части: объект управления и блок управления.
Между этими частями проекта организуется дуплексный канал обмена данными.
Канал формируют две пары блоков «Мультиплексор»/«Демультиплексор».
Схема нового проекта будет иметь вид как на рис. 5.11, и пока она не декомпозирована, то допускает запуск в работу на одном компьютере. Канал от блока управления к объекту управления настроен на передачу вектора из двух элементов типа Byte, а в обратную сторону передается вектор из трех элементов типа Double. Если проведенное тестирование этой схемы не выявит никаких ошибок, то можно перейти к следующему этапу и разорвать сформированные ранее линии связи, заменив каждую из них парой UDP-клиент/UDP-сервер. То есть, дуплексная связь между двумя основными частями проекта организуется с помощью двух разнонаправленных UDP-каналов (рис. 5.12). Предположим, что проект разрабатывается на виртуальной машине, адрес которой 192.168.56.101. Тогда настройки блоков UDP-клиентов должны иметь вид, аналогичный тому, что представлен на рис. 5.13.
Рис. 5.11. Модифицированная модель управления цистерной.
77
Рис. 5.12. Схема проекта с двумя UDP-каналами.
Рис. 5.13. Параметры настройки свойств UDP-клиентов.
Далее необходимо проверить работу проекта на всех режимах, и если проект работает без ошибок, то сохранить его в общей папке основного компьютера под именем tank_udp.prt.
После этого можно приступить к очередной модификации проекта, которая позволила бы разделить его на два проекта, способные совместно выполняться на двух разных рабочих станциях. Выделим для работы блока управления одну виртуальную машину, например, с IP-адресом 192.168.56.101, а модель объекта управления тогда размещается на другой виртуальной машине с IP-адресом 192.168.56.102.
5.3. Декомпозиция модели для ее распределенной работы
На предварительном этапе декомпозиции проекта необходимо войти в общую папку основного компьютера, где уже хранится файл
78
tank_udp.prt, и выполнить его копирование в два новых проекта: tank_udp_control.prt —для выделения модели блока управления, и tank_udp_object.prt — для хранения модели объекта управления.
На следующем этапе декомпозиции надо решить задачу настройки каждого из этих проектов на возможность их совместной работы в сети. Начинаем с проекта, который описывает объект управления. Для этого:
на второй виртуальной машине надо открыть файл tank_udp_object.prt и удалить из него всю левую часть проекта, которая отвечает за блок управления;
добавить временной график, который позволит контролировать работу проекта и выводить значения текущего объема цистерны и положение каждого из клапанов (рис. 5.14);
после этого надо открыть вкладку «Скрипт», где можно увидеть код, который ранее использовался для работы системы управления (рис. 5.15).
Рис. 5.14. Схема проекта tank_udp_object.prt.
Рис. 5.15. Скрипт, который в проекте tank_udp_object.prt надо удалить.
79
Этот скрипт в проекте модели объекта управления больше не нужен и должен быть удален.
После выполнения отмеченных выше действий можно перейти к настройке проекта модели блока управления. С этой целью, не закрывая проект tank_udp_object.prt во второй виртуальной машине, активируем работу первой виртуальной машины, куда загружаем проект tank_udp_control.prt и приступаем к его модификации.
В загруженном проекте tank_udp_control.prt следует удалить всю правую часть проекта, которая отвечает за объект управления (рис. 5.16).
После этого необходимо подправить скрипт блока управления. В частности, это связано с тем, что выводимое на форме значение текущего объема было определено во второй строке скрипта (рис. 5.15) через свойство state_ объекта Tank1. Но этот объект отсутствует в текущей версии проекта.
Это можно исправить, если принять во внимание тот факт, что в этой версии проекта значение текущего объема поступает по каналу связи через UDP-сервер и демультиплексор. Выделим объект «Математическая связь» и дадим ему имя,
например, CurrentVolume (рис. 5.17).
Проведенное переименование связи позволит нам исправить вторую строку основного скрипта проекта (рис. 5.18) и сделать весь скрипт этого проекта работоспособным.
Рис. 5.16. Измененная схема проекта tank_udp_control.prt.
80