Автор работы: Пользователь скрыл имя, 16 Января 2014 в 09:29, контрольная работа
Целью настоящей работы является исследование средств инженерного программного пакета MATLAB для построения, отладки и тестирования моделей систем массового обслуживания (СМО).
Задачи практикума вытекают из следующих необходимостей.
ВВЕДЕНИЕ 3
1 Выбор и обоснование инструментальных средств 4
2 Ход выполнения работы 5
2.1 Анализ основных требований 5
2.2 Подсистема Канала обслуживания 6
2.3 Подсистема Очереди 7
2.4 Подсистема Источника заявок 8
2.5 Подсистема Приемника заявок 10
2.6 Обобщение модели и подготовка к моделированию 11
2.7 Моделирование 14
3 Пути совершенствования модели 18
ЗАКЛЮЧЕНИЕ 19
Список литературы 20
Важным параметром СМО является время нахождения заявки в системе. Для того чтобы его определить, в источнике и приемнике заявок введена пара таймерных блоков. Первый из них (блок "Начало времени заявки в системе" на рисунке 5) инициирует начало отсчета времени, а второй (см. подсистему Приемник заявок) останавливает таймер и снимает его показания. Заявка, прошедшая все блоки Источника и поступившая с выхода таймерного блока, считается готовой к обслуживанию в СМО.
Логическим завершением рассмотрения блоков СМО является детализации блока Приемника заявок.
Функциональная схема подсистемы Приемника заявок представлена на рисунке 7.
Конечным пунктом назначения любой заявки является блок библиотеки SimEvents, обозначенный как Приемник заявок. Он "подавляет" в себе заявку и сообщает в виде сигнала количество пришедших в него заявок. Это количество сравнивается с заданным перед экспериментом количеством заявок. Их совпадение говорит о том, что все заявки, сгенерированные и незаблокированные в источнике, прошли обслуживание. При выполнении этого условия моделирование можно остановить.
Рисунок 7 - Схема подсистемы Приемника заявок
Для определения абсолютной пропускной способности СМО необходимо разделить количество заявок, прошедших обслуживание в СМО, на время, прошедшее с момента начала моделирования. Однако в начале время равно нулю. Чтобы избежать ошибки, в течение первого шага моделирования ненулевое значение поддерживается блоком Ступенька; затем он переключается в 0 и на делитель поступает только сигнал времени. Количество же обслуженных заявок доставляется блоком считывания таймера. Этот же блок предоставляет информацию о времени полного цикла каждой заявки, а также о среднем времени нахождения заявок в системе.
Подсистема приемника заявок является последним элементом, необходимым для моделирования исследуемой СМО. На следующем этапе необходимо еще раз обозреть всю модель и обеспечить дружественный интерфейс пользователя.
Перед тем как приступить к моделированию построенной системы, будет нелишним еще раз увидеть ее общую структуру. Это позволит почувствовать "обратную связь" между детализованным представлением каждой конкретной подсистемы и ее местом в главной схеме, объединяющей все подсистемы для достижения общей цели.
Кроме того, поскольку модель требует задания нескольких параметров для различных внутренних блоков и выдает достаточно большой набор результатов, необходимо предусмотреть удобный интерфейс для пользователя модели. Основное требование к интерфейсу – отсутствие необходимости открывать окно подсистемы для настройки ее параметров или для оценки результатов моделирования. Этому требованию удовлетворяют специальные блоки Goto и From, предназначенные для передачи сигналов из одной точки модели в другую без указания их явной связи. Использование этих блоков позволяет полностью отделить интерфейсную часть модели от функциональной, а также не загромождать схему ненесущими смысла связями.
В качестве задатчиков входных параметров можно использовать блоки констант, однако более дружественным представляется применение специальных слайдерных коэффициентов. Они представляют собой блоки умножения на коэффициент. Двойной щелчок на таком блоке вызывает небольшое диалоговое окно, где можно при помощи слайдера или ввода с клавиатуры указать значение коэффициента. Слайдерные блоки применены для задания всех входных параметров проектируемой модели.
Общая схема построенной модели и ее интерфейсов представлена на рисунке 8.
Таким образом, была построена модель СМО, характеризующаяся следующими параметрами (таблица 1).
Таблица 1 - Параметры моделируемой СМО
Параметр модели |
Значение параметра |
Количество фаз, шт |
1 |
Количество каналов, шт |
1 |
Максимальная длина очереди, заявок |
10 |
Вероятность возврата заявки |
Регулируемая, от 0 до 1 |
Дисциплина обслуживания в очереди |
FIFO |
Потоки заявок и обслуживания, с которыми работает моделируемая СМО, описываются следующими параметрами (таблица 2).
Таблица 2 - Параметры потоков заявок и обслуживания
Параметр |
Поток заявок |
Поток обслуживания |
Закон распределения паузы между заявками |
Экспоненциальный |
Экспоненциальный |
Интенсивность |
Регулируемая, от 0 до 2 |
1 |
Закон распределение весов заявок |
Равномерный | |
Максимальный вес заявки |
Регулируемый, от 0 до 10 | |
Число заявок |
Регулируемое, от 1 до 50 |
- |
Кроме приведенных выше параметров будет полезным привести аналитические зависимости (формулы), расчеты по которым осуществляются в проектируемой модели. Для некоторых показателей функционирования СМО представлено две формы определения: теоретическая (используемая при расчетах показателей без моделирования) и практическая (используемая в модели).
Рисунок 8 - Общая
схема построенной модели
, (1)
где - интенсивность потока
входных заявок;
- интенсивность потока обслуженных заявок.
(2)
При практическом определении эта величина предоставляется как выходной сигнал блока очереди.
. (3)
При практическом определении эта величина предоставляется как выходной сигнал блока очереди.
, (4)
где – вероятность отсутствия заявок в системе.
При практическом определении эта величина рассчитывается по формуле (5):
, (5)
где N – количество обслуженных заявок за время T.
. (6)
При практическом определении эта величина определяется по выходному сигнала таймерного блока в подсистеме Приемника заявок.
Обладая приведенными выше данными, можно приступать к моделированию спроектированной СМО.
Чтобы убедиться в правильности построения модели, следует начать ее проверку с какого-нибудь тривиального эксперимента, результаты которого легко определить априори. В качестве такого эксперимента укажем модели интенсивность входного потока, равную 1. Максимальный вес заявки установим в 0, чтобы исключить влияние веса на время обслуживания. Кроме того, укажем вероятность возврата равной 0, опять же чтобы оценить лишь "чистое" время обслуживания и простоя в очереди. Число заявок установим равным 10.
Ясно, что при таких параметрах абсолютная пропускная способность системы должна составить около 1. Среднее время нахождения заявки в системе также должно быть небольшим. Очередь не успеет переполниться, а время ожидания в ней будет сопоставимо с интенсивностью обслуживания.
Графики результатов моделирования с перечисленными выше параметрами представлены на рисунке 9.
Рисунок 9 - Графики результатов первого эксперимента
Кроме того, дисплеи, используемые в модели, в результате эксперимента показали, что абсолютная пропускная способность системы составила 1.1 (заявки/с), среднее время пребывания заявки в системе – 2.182 с, средняя длина очереди составила 1.604 заявок.
По двум верхним графикам рисунка 9 можно проследить общую динамику процесса, происходившего в системе. В первые примерно 0.8с источник заявок бездействовал; простаивал и канал обслуживания. Однако сразу после этого источник начал интенсивно генерировать заявки, и все из вновь сгенерированных заявок, кроме первой, заняли места в очереди. Это обусловило рост их числа в очереди на нижнем правом графике. Интенсивность потока обслуживания в этот период, по всей видимости, отклонилась в меньшую сторону, однако канал продолжал работать, о чем говорит спад числа заявок в очереди в момент времени ~1.8 с. Другим подтверждением служит равномерность роста числа обслуженных заявок (левый верхний график) в период, когда на входе наблюдался явный перерыв (~3-5c). Небольшое различие в моментах поступления и выхода последней заявки говорит о близости или равенстве интенсивностей потоков заявок и обслуживания (в данной случае, очевидно, равенстве).
Для верификации остальных возможностей модели сделаем вес заявок ненулевым. Зададим поток из 25 заявок с интенсивностью 0.5 заявок/с и максимальным весом 4. Очевидно, что без учета веса такой поток заставил бы канал обслуживания бездействовать существенную часть времени моделирования (в пределе – половину этого времени). Однако введение веса заявок увеличит время обслуживания каждой из них на некоторую случайную величину, не превышающую максимального веса. В результате это должно дать "запаздывание" последней заявки на период, сопоставимый с числом поступивших заявок. Результаты моделирования с такими параметрами представлены на рисунке 10. Очередь в процессе моделирования не переполнялась, поэтому кривую обслуженных заявок можно считать неискаженной.
Рисунок 10 - Результаты моделирования с учетом весов заявок
По графикам видно, что последняя заявка вышла из системы примерно на 30 с позже момента своего поступления (общее количество заявок – 25). Наличие этой задержки подтверждает сделанные ранее предположения о характере изменения результатов.
В модели осталась еще одна не проверенная особенность – наличие обратной связи между каналом обслуживания и очередью. В предыдущих экспериментах ее влияние было исключено указанием нулевой вероятности возврата. В третьем эксперименте она будет задействована. Для этого укажем максимальный вес заявки равным нулю (чтобы не "загромождать" результаты его учетом), а вероятность возврата установим равной 0.5. Необходимо сразу отметить, что модель не различает заявок, уже возвращенных по обратной связи ранее. Для его каждому экземпляру заявки необходимо присвоить соответствующий признак (что может быть легко реализовано с помощью атрибутов сущностей библиотеки SimEvents). В связи с этим, каждая заявка может быть возвращена более одного раза. Составим поток входящих заявок из 20 штук с интенсивностью 0.9. Как и в первом эксперименте, такие параметры (без учета возможности возврата) должны привести к равномерной нагрузке на канал и общее время обслуживания почти совпало бы с периодом поступления заявок. Однако введение обратной связи существенно меняет представленную картину. Результаты моделирования с указанными параметрами представлены на рисунке 11.
Рисунок 11 - Результаты моделирования с учетом обратной связи
Первое, на что следует обратить внимание в представленных графиках, это существенное различие в общих временах поступления и обслуживания. Кроме того, на графике обслуженных заявок можно видеть несколько "пауз". Каждая из них говорит о том, что заявка (или даже несколько подряд), прошедшая обслуживание в канале, была вместо приемника заявок направлена снова в очередь. Об этом также свидетельствуют скачки числа заявок в очереди в моменты времени, соответствующие выходам обслуженных заявок из канала обслуживания. Кроме того, число "фронтов" (в том числе и мгновенных) на графике содержимого очереди получилось равным 35, в то время как число заявок в эксперименте всего 20. Это говорит о том, что всего по обратной связи в очередь вернулись 15 (не обязательно различных) заявок. Подтверждением этой цифре служат показания соответствующего дисплея в подсистеме очереди. Таким образом, полученные результаты можно считать адекватными.
Эксперименты с более сложными комбинациями параметров могут быть проинтерпретированы схожим образом.
Не вызывает сомнений тот факт, что построенная модель является по многим параметрам примитивной. Однако за счет выбранной идеологии построения и инструментальных средств MATLAB+Simulink+SimEvents она может быть улучшена во многих направлениях. Обозначим основные из них и пути их достижения:
Модель может быть улучшена и по другим показателям, но это потребует бОльших усилий, чем для перечисленных изменений.
Инженерный программный пакет MATLAB включает в свой состав инструментальные средства, позволяющие строить, моделировать и отлаживать модели СМО. Эти средства представлены комплексом Simulink и входящей в его состав библиотекой блоков SimEvents.
Блоки библиотеки SimEvents являются мощным, гибким, но легким в освоении инструментом для описания моделей СМО.
Разработанные таким образом
модели при должном тестировании
и отладке могут служить