3.5 Приемник данных

Этот блок является заключительным и выполняет функцию приема данных. Этот блок представлен на рисунке 29.

Р исунок 29 — Демонстрация блока приема данных.

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

Порты

Как говорилось выше блок имеет входной порт in, помимо этого есть выходной сигнальный порт #a, который показывает, сколько сущностей принял блок. Работать этот порт будет только в том случае, если его разрешить в окне параметров, а так же разрешить прием сущностей блоку.

Окно параметров

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

Р исунок 30 - Окно параметров блока приемника.

4. Построение схемы.

В данной схеме будет 5 блоков:

• генератор сущностей

• сервер

• блок очереди FIFO

• блок графического представления

• приемник

Зададим параметры для каждого блока. Основными моментами моделируемого процесса является время пребывания сущностей и сервисное время их обслуживания. Согласно техническому заданию, оба эти значения равны 2 секундам, а общее время модуляции 20 секунд. Первый параметр задается в блоке генератора сущностей(Time-Based Entity Generator), Зададим время выработки, равное 2 секундам. Это значит, что сущности будут вырабатываться с интервалом с две секунды. Для этого время распределения поставим зависимым от параметра (Intergenegation time from dialog), распределение по константе(Constant), тогда появиться поле Period, в котором и указывается интервал. Помимо этого установим галочку, чтобы сущности начали вырабатываться с началом симуляции и приоритет 300. Все эти установки представлены на рисунке 31 ниже.

Р исунок 31 — Установка параметров блока генерации сущностей.

Далее переходим к серверу и устанавливаем время сервисного обслуживания каждой сущности, равное 2. Для этого в окне параметров устанавливаем сервисное время в значение, зависящее от параметра (Dialog) и в поле ниже пишем 2. Это значит, на каждую сущность у сервера будет уходить 2 секунды.(рисунок 32, а). Далее переходим на вкладку статистики и разрешаем порт #d, чтобы знать количество сущностей, уже прошедших через блок.(рисунок 32,б)

а б

Рисунок 32 — Окно настройки сервера

Далее переходим к блоку очереди FIFO, У этого блока ставим бесконечную емкость. В значении поля «capacity» пишем «inf », что значит бесконечный. Демонстрация на рисунке 33.

Р исунок 33 - Настройка блока FIFO.

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

Далее соединяем блоки и получаем следующую схему.

Р исунок 34 — Схема моделируемого процесса.

При запуске модуляции получилось следующее. Результат представлен на рисунке 35. Из рисунка видно, что каждые две секунды с генератора поступает сущность и график растет вверх, сервер обрабатывает сущность две секунды, график идет прямо. Общее время модуляции 20 секунд, согласно техническому заданию.

Р исунок 35 — Графическое отображение результата.

Отладка программы

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

blkinfo('dd1/Single Server')

Результат представлен на рисунке 36.

Р исунок 36 — Демонстрация отладчика.

Далее создадим очередь. Для того, чтобы отобразить ее графически понадобиться еще один блок Scope. При переносе его на рабочую область ,он автоматически получит имя Scope1. Помимо этого в блоке FIFO в окне параметров на вкладке статистики(Statistics) нужно разрешить порт #n, а на схеме нужно соединить этот порт со с входным портом блока scope1. Новая схема представлена на рисунке 37.

Рисунок 37 - Схема для визуализации очереди.

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

Р исунок 38 — Образование очереди

Теперь уменьшим время на генераторе до 0.5 с. Это означает, что каждые 0.5 секунд он будет выдавать сущности, а сервер обслужит первую из них только через 2 секунды. Результат на рисунке 39.

Р исунок 39 — Демонстрация очереди, если сущности появляются быстрее, чем сервер может их обслужить.

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

Р исунок 40 — Демонстрация ситуации, когда генератор сущностей работает медленнее сервера.

Демонстрация времени ожидания сервера и утилизации

Далее посмотрим среднее время ожидания сущностей в очереди и долю времени на обслуживание сервером каждой сущности. Установим на блоке FIFO параметр среднего времени ожидания и включим порт w. У сервера на вкладке статистики также установим среднее время ожидания и утилизацию в значение on( поставим галочку). Далее дважды скопируем блок Scope1 для графического представления этих характеристик. Один из блоков назовем Departures from Server(Отправленные сущности через сервер) а второй - Server waiting Time(Время ожидания сервера). Демонстрация получившейся схемы на рисунке 41.

Р исунок 41 — Схема для моделирования заданного процесса.

Установим время вырабатывания сущностей, равное 0.5. Тогда среднее время ожидания сервера будет неубывающей функцией, потому как сервер все время занят с момента прибытия первой сущности. Демонстрация на рисунке 42.

Р исунок 42 — Демонстрация среднего времени ожидания сервера.

При таком времени интеграции утилизация также будет неубывающей, так как сервер все время занят. Демонстрация на рисунке 43.

Р исунок 43 — Демонстрация утилизации сервера.

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

Р исунок 44 — Работа сервера при увеличении времени интеграции.

Среднее время ожидания в очереди растет при малом времени интеграции (0.5 с), так как поступает все больше и больше сущностей.

Р исунок 45 — Демонстрация времени ожидания сущностей в очереди, при малом времени интеграции.

П ри большом времени интеграции, время ожидания сущности в очереди равно нулю, так как каждая приходящая сущность мгновенно обслужена сервером. Демонстрация на рисунке 46.

Рисунок 46- Демонстрация времени ожидания при большом времени интеграции.