В этом примере показано, как смоделировать основные системы массового обслуживания в дискретно-событийной симуляции с помощью блоков Entity Server и Entity Queue.
Блок Entity Queue хранит сущности долго, которые не могут быть определены заранее. Повседневным примером очереди являются люди, ждущие своей очереди для регистра хранилища. Покупатель не может определить заранее, сколько времени они должны ожидать, чтобы завершить их покупку. Можно использовать Entity Queue в различных приложениях, таких как Самолеты, ожидающие, чтобы получить доступ к взлетно-посадочной полосе или сообщениям, ожидающим, чтобы быть переданными. Блок Entity Queue имеет емкость памяти, сущность, сортирующая политику и сущность, перезаписывающую политику. На основе этих параметров блок пытается вывести сущности в зависимости от того, принимает ли нисходящий блок новые сущности.
Блок Entity Server хранит сущности долго, названный service time, затем пытается отправить сущность в зависимости от того, принимает ли нисходящий блок новые сущности. В сервисный период блоком является serving сущность, которую это хранит. Повседневным примером сервера является человек (такой как кассир банка или розничный кассир), с кем вы выполняете транзакцию со спроектированной длительностью.
Этот пример представляет основные модели с очередями, которые показывают как:
Очередь FIFO модели, очередь LIFO и Приоритетная Очередь.
Задайте сущность, перезаписывающую политики, когда очередь достигнет способности.
Настройте и варьируйтесь сервисные времена сущности.
Присвойте и измените атрибуты сущности на основе событий.
Изучите статистику длины очереди в процессе моделирования.
Эта модель показывает, как отсортировать сущности путем изменения очереди, сортирующей политику. Блок Entity Queue поддерживает три сообщения, сортирующие политики:
В обратном порядке (LIFO) — новейшая сущность в устройстве хранения данных отбывает сначала.
Метод "первым пришел - первым вышел" (FIFO) — старейшая сущность в устройстве хранения данных отбывает сначала.
Приоритет — Сущности сортируются на основе их приоритета. Можно только использовать приоритетную очередь, когда Перезапись самый старый элемент, если очередь является полным флажком, очищена.
Модель ниже показов четыре различных сущности, сортирующие поведения: FIFO, LIFO, Приоритет в порядке возрастания и Приоритет в порядке убывания.
Четыре идентичных блока Генератора Сущности генерируют 10 сущностей каждый. Каждый блок использует повторяющийся шаблон последовательности в течение времени межгенерации сущности dt.
После генерации 10 сущностей, время межгенерации dt собирается в бесконечность прекратить генерировать сущности. В блоке Entity Generator, в поле действия времени Межгенерации, используется этот код.
persistent SEQ; persistent idx; if isempty(SEQ) % Generate 10 entites with 1 second intervals. SEQ = [1 1 1 1 1 1 1 1 1 1]; idx = 1; end if idx > numel(SEQ) % Stop entity generation after generating 10 entities. dt = inf; else dt = SEQ(idx); end
Блок генерирует сущность, и он задает атрибут Attribute1 на каждой сущности. Можно использовать атрибуты, чтобы представлять функции или свойства сущностей. В этом примере первая сущность несет значение 1, и значение атрибута каждой сгенерированной сущности увеличивается 1. Чтобы достигнуть этого поведения, в блоке Entity Generator, в конечном счете вкладка действий, в Сгенерировать поле действия, этот код используется.
% Pattern: Repeating Sequence persistent SEQ1; persistent idx1; if isempty(SEQ1) SEQ1 = [1 2 3 4 5 6 7 8 9 10]; idx1 = 1; end if idx1 <= numel(SEQ1) entity.Attribute1 = SEQ1(idx1); end idx1 = idx1 + 1;
Сгенерированные сущности передаются четырем блокам Очереди Сущности. Для того, чтобы показать поведение сортировки, блоки Очереди Сущности соединяются с четырьмя идентичными блоками Логического элемента Сущности, сконфигурированными как логические элементы релиза. Логический элемент релиза позволяет одной сущности передавать, когда это получает сущность, несущую положительное (больше, чем 0) значение от его порта управления. Логические элементы блокируют сущности для первого 10 секунды и хранят их в очереди. После первых 10 секунд логические элементы позволяют одной сущности передавать в секунду на основе политики сортировки.
Симулируйте модель. Откройте Инспектора Данных моделирования и заметьте, что сущности, вылетающие от каждого блока Entity Queue, сортируются на основе очереди, сортирующей политику.
Первый график показывает сущности, вылетающие от очереди с политикой FIFO. Первая сущность с Attribute значение 1, вылетает от очереди, когда логический элемент открывает во время 11. Последующие сущности отбывают из очереди в том же порядке их генерации с увеличивающимся значением атрибута.
Второй график показывает сущности, вылетающие от очереди с политикой LIFO. Эта политика инвертирует исходную последовательность сущности начиная с сущности, несущей самое большое значение атрибута.
Третий график показывает сущности, вылетающие от приоритетной очереди что сущности видов на основе их атрибутов в порядке возрастания вместо их порядка записи в очередь. Сущность, несущая самое маленькое значение атрибута, отбывает сначала. Последующие сущности следуют за той же политикой.
Четвертый график показывает сущности, вылетающие от приоритетной очереди что сущности видов на основе их атрибутов в порядке убывания. Сущность с самым большим значением атрибута отбывает сначала, и остальная часть сущностей следуют за той же политикой.
Можно задать то, что делает блок Entity Queue, когда блок достигает своей способности путем установки сущности, перезаписывающей политику. Задайте политику путем выбора или очистки Перезаписи самый старый элемент, если очередь является полным флажком.
Если Перезапись, самый старый элемент, если очередь является полным флажком, очищен, блок, не принимает новые сущности, когда очередь полна. Это - блокирующееся поведение очереди.
Если Перезапись, самый старый элемент, если очередь является полным флажком, выбран, блок, собирается всегда принять входящую сущность путем перезаписи старейшей сущности в устройстве хранения данных. Блок перезаписывает старейшую сущность, но сущность, отбывая из блока определяется очередью, сортирующей политику.
В этой модели два идентичных блока Генератора Сущности генерируют сущности каждый 1 второй. Сущности передаются двум блокам Очереди Сущности каждый со способностью 10 и сущность FIFO, сортирующая политику. Однако Блокирующаяся Очередь сконфигурирована, чтобы не принять новые сущности, когда ее очередь полна, в то время как Очередь Перезаписи сконфигурирована, чтобы перезаписать старейшую сущность, когда ее очередь полна. Блокирование Очереди и Очереди Перезаписи соединяется с двумя идентичными блоками Сервера Сущности, каждым со значением времени обслуживания 25 секунды. Скорость генерации сущности блока Entity Generator намного выше, чем скорость обслуживания блока Entity Server. Это различие заставляет сущности накапливаться в блоке Entity Queue.
Симулируйте модель и откройте блок Sequence Viewer. Заметьте, что Генератор Сущности 1 и Генератор Сущности 2 блока первоначально генерируют сущности со значениями данных 0.8147, и сущности передаются Серверу Сущности 1 и Серверу Сущности 2. Оба блока Генератора Сущности генерируют второй набор сущностей со значениями данных 0.9058, которые хранятся в Блокирующейся Очереди Очереди и Перезаписи, потому что оба блока Сервера Сущности полны. Остальная часть сгенерированных сущностей также хранится в блоках Очереди Сущности.
Заметьте, что блок Entity Queue 1 прекращает принимать новые сущности к своему устройству хранения данных время 11. Однако Очередь Сущности 2 разрешает новую сущность с атрибутом 0.9706 к устройству хранения данных и перезаписям старейшая существующая сущность, которая имеет значение данных 0.9058.
В основной системе массового обслуживания можно использовать блок Entity Server для задержек модели на основе процессов в системе. Можно определить источник, который задает задержку путем изменения исходного параметра Времени обслуживания блока Entity Server.
Этот пример показывает четыре других источника, которые можно использовать на основе приложения:
Dialog — Можно задать постоянное значение времени обслуживания. В первом шаблоне моделирования сущности задерживаются для 2 секунды. Блок затем пытается передать сущности следующему блоку.
Signal port — Входящий сигнал Simulink® определяет время обслуживания. Во втором шаблоне моделирования блок использует значения сигналов пандуса в качестве источника времени обслуживания.
Attribute — Заданное значение атрибута сущности определяет время обслуживания. В третьем шаблоне моделирования каждая сущность несет Attribute1 со значением 4 который является источником времени обслуживания.
MATLAB action — Можно ввести код MATLAB™ в поле действия Времени обслуживания и присвоить переменную dt, который является параметром использование модели в качестве времени обслуживания. В четвертом шаблоне моделирования, случайное время обслуживания dt = rand(1,1); используется, и кодовые наборы случайное значение времени обслуживания, которое равномерно распределено между 0 и 1.
Симулируйте модель и рассмотрите результаты
Симулируйте модель и наблюдайте Инспектора Данных моделирования, который отображает сущности, переданные блоком Entity Server.
Можно присоединить атрибуты к сущностям, чтобы представлять их функции. В системе массового обслуживания можно использовать действия в качестве ответов на события и изменить атрибуты сущности. Например, можно изменить значение атрибута сущности, когда сущность вводит и выходит из блока Entity Queue. В блоке Entity Queue, в конечном счете вкладка действий, вы видите набор событий, для которых вы можете действия по созданию.
Предположим, что вы хотите смоделировать систему обслуживания клиентов в филиале банка. Ветвь имеет двух кассиров банка, каждый присвоил конкретный тип транзакции. Клиенты достигают ветви. Они выбирают номер для своей транзакции, и они направлены к правильному кассиру банка. Клиенты оставляют ветвь после того, как транзакция будет завершена.
В этом примере потребительское прибытие моделируется блоком Entity Generator. Клиенты приняты, чтобы прибыть с постоянным межвременем поступления, и Периодом является 1. Каждая сгенерированная сущность присоединяется атрибут TransactionType представлять потребительские запросы. TransactionType|is initialized as |0 потому что транзакция неизвестна, прежде чем клиенты введут ветвь.
Приемная представлена блоком Entity Queue. Когда клиент вводит приемную, им дают номер для соответствующего кассира банка. Это действие представлено путем изменения атрибутов сущности в конечном счете действия блока Entity Queue. Ниже действие, вызванное событием записи сущности с блоком Entity Queue.
Можно использовать статистику очереди, чтобы анализировать и изучить поведение очереди в симуляции. А именно, можно измериться:
Количество сущностей вылетело от очереди с нисходящим блоком.
Количество сущностей в определенном времени симуляции.
Среднее ожидание сущностей в очереди прежде, чем отбыть из блока.
Средняя длина очереди или количество сущностей извлечены из очереди блоком Entity Find.
Понимание этих статистических данных может дать понимание о поведении вашей модели. Для получения дополнительной информации о статистике очереди, смотрите, Интерпретируют Модели SimEvents Используя Статистический анализ.
Этот пример представляет две различных методики для визуализации и понимания длины очереди.
Чтобы определить, хранит ли очередь какие-либо сущности, можно вывести статистические данные, которые соответствуют количеству сущностей, сохраненных в блоке.
Чтобы вывести статистику выполняют эти простые шаги.
Включите выходной сигнал n блока очереди. В диалоговом окне блока, на вкладке Statistics, устанавливают флажок Number of entities in block, n.
От библиотеки Sinks в наборе библиотеки Simulink® вставьте блок Scope в модель. Соедините выходной порт n блока очереди к входному порту блока Scope.
Осциллограф показывает, пуста ли очередь.
Для получения дополнительной информации о визуализации статистики очереди, смотрите, Исследуют Статистику и Визуализируют Результаты симуляции.
Можно разделить очередь, чтобы изучить больше деталей о длине очереди и поведении в процессе моделирования.
Предположим, что вы хотите определить, какая пропорция времени длина очереди превышает 10 для очереди со способностью 100. Можно исследовать это при помощи пары очередей, соединенных последовательно. У очередей есть длины 90 и 10. Вместе они представляют очередь способностью 100.
Разделение исходной очереди в две меньших очереди позволяет вам собирать статистику, связанную с одной из меньших очередей. Например, можно просмотреть статистическую величину длины очереди для блока Entity Queue со способностью 90. Если существуют сущности, накопленные в очереди со способностью 90, в средних значениях, что очередь со способностью 10 полно. Таким образом, определяя пропорцию времени, когда очередь со способностью 100 имеет минимальные 10 сущностей, эквивалентно определению пропорции времени длина очереди очереди со способностью 90 больше 0.
Симулируйте модель. Заметьте что Способность Очереди Сущности 90 блок выводит Количество сущностей в блоке, n. Заметьте, что в определенных сущностях временных интервалов хранятся в блоке, который указывает что очередь со способностью 10 полно.
Визуализировать пропорцию времени когда очередь со способностью 10 полно, статистический сигнал далее обработан и сравнен с нулем.
