ms

кої вартісної інформації. Отже, якщо для ресурсів тих, що входять до групи не потрібно вартісній інформації і місткість більше 1, то можна обійтися створенням тільки модуля Set. Можливе застосування модуля для організації роботи групи працівників, наприклад, по черзі. Параметри модуля та їх значення:

Name - назва групи.

Members - перераховує ресурси, що входять до групи. Порядок перерахування ресурсів важливий, коли в модулі Process використовується правило вибору Cyclical або Preferred Order.

Resource Name - назви ресурсів що входять до групи.

Модуль Variable визначає значення змінної. Змінні, що відносяться до модуля Decide або Assign, можуть використовуватися у виразах. Наприклад, Привласнення серійного номера для ідентифікації продукції, кількість документів оброблюваних в годину. Якщо змінна не описана в модулі Variable, то її значення рівне 0. Параметри модуля та їх значення:

Name – ім'я змінної

Initial Value – первинне значення змінної. Це значення надалі може мінятися модулем Assign.

Rows – кількість рядків в розмірній змінній. Columns – кількість стовпців в розмірній змінній.

Clear Option – визначає час, коли значення змінної скидається в початкове значення.

Statistics – скидає змінну в початкове значення у будь-який момент, коли статистика була розчищена.

System – скидає змінну в початкове значення у будь-який момент, коли система була розчищена.

None – ніколи не скидає змінну в початкове значення, виключаючи передуючу першій реплікації.

Statistics – визначає, чи вестиметься статистика по цій змінній. Окрім панелі основних процесів Basic Process система Arena має па-

нель допоміжних процесів Advanced Process. Панель процесів Advanced Process містить модулі, які призначені для виконування спеціальних логічних функцій, наприклад, пов’язаних із координацією руху об’єктів обслуговування у різних частинах системи або із вибором черги при наявності в системі декількох черг. Оскільки ці блоки використовуються не часто, опишемо тільки деякі з них.

Блок Hold призначений для здійснення затримки процесу обслуговування об’єктів до виконання указаної умови або до надходження заданого сигналу.

Блок Signal призначений для генерування значення сигналу, що використовується в блоці Hold.

281

Система Arena має ще одну, третю, панель процесів Advanced Transfer, що містить модулі, які використовуються для опису процесів передачі об’єктів обслуговування із однієї частини системи в іншу, такі як, наприклад, конвеєри.

Ведення моделі

Введення моделі в системі Arena здійснюється простим перетягуванням потрібних модулів із панелі процесів (Basic Process, Advanced Process або Advanced Transfer) у вікно робочого поля. Параметри модулів, такі як час затримки, вид закону розподілу, кількість пристроїв, кількість одночасно обслуговуваних об’єктів та інші, задаються у вікні параметрів модулів. Між модулями указуються з’єднання у відповідності до логіки функціонування моделі.

Виконання моделювання

Перед тим, як розпочати процес імітації потрібно зайти в меню Run, підменю Setup і ввести в установки Replication Parameters час моделювання (Replication Length) та одиниці в яких він вимірюється (Time Units), а також одиниці часу, в яких будуть представлені результати моделювання

(Basic Time Units). Бажано також ввести в установки Project Parameters

ім’я проекту (Project Title) обрати статистичні дані, що збираються

(Entities, Queues, Resources, Processes, а також Costing).

Запуск імітації здійснюється вибором команди Go меню Run. Для перевірки моделі зручно скористатись командою Step, що запускає покрокову імітацію модельованого процесу. Управління процесом імітації здійснюють команди Pause - тимчасова зупинка процесу імітації, Fast Forward - швидка імітація, End - повернення до корегування моделі або нового запуску.

Виведення результатів моделювання

В результаті успішної імітації моделі пакетом Arena створюються звіти про результати моделювання Переглянути їх можна скориставшись панеллю звітів Reports. На панелі звітів представлено декілька видів звітів. Звіт «Короткий огляд категорій» і звіти по чотирьох категоріях, такі як Вимоги, Процеси, Черги і Ресурси.

За допомогою панелі звітів можна проглянути короткий огляд категорій Category Overview. Звіт Category Overview відображає підсумкову інформацію про вимоги, процеси, черги і ресурси. Також показує інформацію про заданих користувачем змінних і інформацію, зібрану модулем Record.

Звіт про вимоги Entities поділений на декілька частин. У частині звіту Cycle Time показаний середній, максимальний і мінімальний час існування вимоги. Час існування вимоги вважається з моменту її прибуття в систему і до того моменту, коли вимога потрапляє в модуль Dispose. Нижче представляється гістограма середнього часу циклу для кожного типу вимоги.

282

Участині NVA Cost: показано середнє, максимальне і мінімальне значення не додаткової вартості вимоги за кожним типом вимоги. Не додаткова вартість розраховується на підставі значення NVA Time.

Участині Total Cost: показано середнє, максимальне і мінімальне значення загальної вартості вимоги за кожним типом вимоги. Загальна вартість обчислюється шляхом складання вартості очікування, додаткової вартості і не додаткової вартості для кожної вимоги. Нижче представляється порівняльні гістограми середніх значень загальної вартості вимоги для кожного типу вимоги.

Участині VA Cost показано середнє, максимальне і мінімальне значення додаткової вартості вимоги за кожним типом вимоги. Додаткова вартість розраховується на підставі VA Time.

Участині Wait Cost показано середнє, максимальне і мінімальне значення вартості очікування вимоги за кожним типом вимоги. Вартість очікування підраховується виходячи з часу очікування, вартості ресурсу і вартістю знаходження вимоги в системі.

Участині Wait Time показано середнє, максимальне і мінімальне значення часу очікування вимоги за кожним типом вимоги. Час очікування - це період часу з моменту надходження вимоги в чергу (або у модулі Process чекає ресурс, або в модулі Batch чекає угрупування) і до моменту виходу з неї (почне оброблятися, або буде згрупована).

Участині WIP (Work In Process) показано середнє, максимальне і мінімальне значення часу очікування вимоги за кожним типом вимоги.

Звіт про процеси Processes поділений на декілька частин. У частині Cycle Time звіту показаний середній, максимальний і мінімальний час циклу процесу. Час циклу процесу вважається з моменту прибуття в модуль Process і до того моменту, коли об’єкт покидає модуль. У розділі представляється гістограма середнього часу циклу для кожного процесу.

Участині NVA Cost показано середнє, максимальне і мінімальне значення не додаткової вартості об’єкта по процесу. Не додаткова вартість розраховується на підставі NVA Time.

Участині Total Cost показано середнє, максимальне і мінімальне значення загальної вартості вимоги по процесу. Загальна вартість обчислюється шляхом складання вартості очікування, додаткової вартості і не додаткової вартості для кожної вимоги. У розділі представляється порівняльні гістограми середніх значень загальної вартості вимоги для кожного типу вимоги.

Участині VA Cost показано середнє, максимальне і мінімальне значення додаткової вартості вимоги за кожним типом вимоги. Додаткова вартість розраховується на підставі VA Time.

283

Участині Wait Cost показано середнє, максимальне і мінімальне значення вартості очікування вимоги за кожним типом вимоги. Вартість очікування підраховується виходячи з часу очікування, вартості ресурсу і вартістю знаходження вимоги в системі.

Участині Wait Time показано середнє, максимальне і мінімальне значення часу очікування вимоги за кожним типом вимоги. Час очікування - це період часу з моменту надходження вимоги в чергу (або у модулі Process чекає ресурс, або в модулі Batch чекає угрупування) і до моменту виходу з неї (почне оброблятися, або буде згрупована).

Участині WIP показано середнє, максимальне і мінімальне значення часу очікування вимоги за кожним типом вимоги.

Виконання анімації Анімація об’єкта обслуговування виконується за допомогою параме-

тру Entity Picture, що задається в блоці Entity. Анімаційну картинку об’єкта обслуговування можна вибрати із переліку запропонованих картинок або із бібліотеки анімаційних картинок. При запуску моделі користувач спостерігатиме рух об’єктів обслуговування від одного блоку моделі до іншого.

Анімація ресурсу виконується за допомогою панелі Resours. У вікні, що з’явиться після виклику панелі Resours, потрібно вибрати ресурс із списку ресурсів моделі. Потім обрати картинку для зображення стану «вільний» у списку картинок і перемістити її до вікна Idle. Так само обрати картинку для зображення стану «зайнятий» і перемістити її до вікна Busy. Якщо бажаної картинки в запропонованому списку не знайдено, можна скористатись бібліотеками картинок, які містяться у папці C:\Program Files\Rockwell Software\Arena у файлах з розширенням .plb. Після вибору усіх картинок ресурсу як зайнятого, так і вільного, анімаційна картинка розташовується курсором миші у потрібному користувачу місці. Розтягуванням анімаційної картинки користувач може змінювати її розміри.

Анімація черги виконується за допомогою панелі Queues. Після заповнення діалогового вікна картинка розміщується користувачем на моделі.

Візуальне зображення гістограми виконується за допомогою панелі Histograms. Зображення гістограми сильно залежить від масштабу, який обрав користувач, тому вибирати його потрібно ретельно.

Візуальне зображення значення змінної виконується за допомогою панелі Variables. Скористатись цією візуалізацією можна тільки якщо у моделі була введена змінна типу Variable.

Візуальне графічне зображення динаміки змінювання виконується за допомогою панелі Plot. Може бути виведена, наприклад, динаміка зміню-

284

вання кількості об’єктів у черзі, динаміка змінювання часу обслуговування об’єктів у моделі і т.і.

Пакет Arena містить програми, призначені для дослідженню власти-

востей системи Input Analizer, Output Analizer, Process Analizer. Професій-

на версія пакету містить також програму, що підтримує пошук оптимальних значень параметрів системи.

8.4. Приклади розв’язання задач

Задача 1. Розглянемо можливості мови на прикладі моделювання роботи служби замовлення таксі, взятий з [Томашевський,2001].

Служба замовлення таксі має 5 каналів для одночасного прийняття замовлень по телефону. Час між спробами виклику таксі розподілений за законом Ерланга другого порядку із середнім 180 секунд. Абонент затрачає 30 секунд для набирання номера і, якщо застає всі канали служби замовлення зайнятими або після з’єднання з’ясовує, що черга на обслуговування перевищує 10 замовлень (в такому випадку замовлення не приймаються), то через 60 секунд він повторює набирання номера. Після п’яти спроб абонент припиняє набирання. Служба замовлення таксі має у своєму розпорядженні 30 машин таксі для обслуговування замовлень. Час, витрачений на проїзд до клієнта, залежить від відстані до нього. Ймовірності можливих відстаней розподіляються таким чином: 2 км – з імовірністю 0,1, 8 км - з імовірністю 0,2, 9 км – з імовірністю 0,25, 11 км - з імовірністю 0,17, 12 км – з імовірністю 0,23, 20 км – з імовірністю 0,05. Вартість проїзду до клієнта клієнтом не сплачується. Швидкість руху машин рівномірно розподілена в інтервалі 45±5 км/год. Час обслуговування клієнта рівномірно розподілений в інтервалі 50±20 хвилин. Вартість попереднього замовлення складає 2 гривні, вартість проїзду 1 км складає 2 гривні.

Метою моделювання є визначення такої кількості операторівтелефоністів та водіїв таксі, при якій максимізується прибуток служби замовлення.

За умовою задачі надходження замовлення здійснюється за законом Ерланга другого порядку із середнім значенням180, що еквівалентно двом затримка за експоненціальним законом із середнім значенням 90. Тому надходження замовлень моделюється двома операторами: оператором GENERATE 90, FN$DIS, де DIS – ім’я функції, що задає експоненціальний розподіл, та оператором ADVANCE 90, FN$DIS.

Набирання номера моделюється звичайною затримкою транзакта на

30 секунд: ADVANCE 30

285

Зайняття телефоніста (одного з п’яти) моделюється наступним фрагментом:

Але за умовою задачі, якщо всі телефоністи зайняті, то клієнт із затримкою 60 секунд передзвонює, при чому, якщо всі п’ять спроб додзвонитися виявилися невдалими, то клієнт припиняє дзвонити у цю службу таксі. Тому ускладнимо цей фрагмент наступним чином. Введемо цикл, який здійснює додзвони. Кількість здійснюваних циклів залежить від значення, наприклад, першого параметру, в якому потрібно запам’ятати бажану кількість спроб додзвону. Розгалуження подій «відповідь телефоніста» або відмова реалізуємо за допомогою оператора TRANSFER BOTH,VIDP,VIDM. При виході невдалого клієнта з системи доцільно підраховувати загальну їх кількість. Для цього використовується блок SAVEVALUE NEOBSL+,1, який збільшує значення змінної з ім’ям NEOBSL на одиницю кожний роз, як до нього надходить транзакт. Вихід невдалого клієнта з системи обслуговування здійснюється оператором TERMINATE. Таким чином отримуємо наступний фрагмент програми:

Але за умовою задачі клієнт відмовляється від обслуговування також, якщо дізнався, що черга клієнтів на машини таксі надто велика (більша 10). Отже, навіть якщо клієнт додзвонився, він може відмовитись від замовлення, якщо черга надто велика. Перевірку черги можна здійснити за допомогою порівняння стандартного параметра транзакта «кількість транзактів у черзі» із заданим числом 10. Порівняння у мові GPSS здійснюється за допомогою блоку TEST L Q$KLIENT,10,VIDM – якщо значення параметру Q$KLIENT менше (L) 10, то транзакт прямує до наступного опе-

286

ратора, в противному випадку – до оператора з міткою VIDM. Якщо замовлення все ж таки прийняте, то служба замовлення бере плату з клієнта за попереднє обслуговування і ставить клієнта у чергу на обслуговування. Підраховування доходу служби замовлення здійснюється оператором SAVEVALUE DOHOD+,2000. Перехід до обслуговування клієнта здійснюється оператором безумовного переходу TRANSFER ,OBSL. Отже, остаточно фрагмент програми, що моделює обслуговування клієнтів у телефоністів, приймає вигляд:

Обслуговування клієнта машинами таксі передбачає очікування в черзі з ім’ям клієнт, зайняття машини таксі, слідування машини таксі до клієнта, поїздка машини таксі за замовленням клієнта, звільнення машини таксі, сплачування клієнтом за проїзд, підраховування кількості обслугованих клієнтів та вихід клієнта із системи. Час обслуговування за умовою задачі має рівномірний розподіл від 1800 до 4200 секунд і задається функцією DOBSL, оскільки його значення використовується для розрахунку вартості проїзду. Функція DOBSL задається у форматі С2 як неперервна і задана двома точками. Час, що таксі витрачає на слідування до клієнта не даний, але відомі швидкість машини та відстань до клієнта. Тому час слідування машини до клієнта задається змінною CHAS, яка розраховується як частка відстані до клієнта та швидкості. Відстань до клієнта за умовою задачі має дискретний розподіл, який в програмі задається у вигляді функції розподілу VIDST, що визначається шістьма точками (формат D6). Швидкість має рівномірний розподіл і задається функцією розподілу DSPEED двома точками (формат C2). Вартість проїзду задається змінною COST і розраховується як множина кількості метрів, що проїхав клієнт, на вартість одного метра. Отже, фрагмент програми, що моделює обслуговування клієнта машинами таксі має вигляд:

287

0.1,5000/0.3,8000/0.55,9000/0.72,11000/0.95,12000/1.00,20000

Фрагмент програми, що відповідає за час моделювання протягом 240 годин має вигляд:

GENERATE 864000

TERMINATE 1

Такі фрагменти програми GPSS називають лічильниками часу. Він спрацьовує таким чином. Через час 864000 з блоку GENERATE вийде транзакт і при виході його з системи лічильник транзактів TERMINATE зменшиться на одиницю. Нульова кількість транзактів в лічильнику транзактів означає завершення моделювання.

Реалізація моделі засобами мови GPSS представлена на рисунку 8.8. Результати моделювання представлені на рисунку 8.9. З результатів моделювання (час моделювання 240 годин) випливає, що кількість не обслугованих за 10 діб замовлень складає 2788 замовлень (29% усієї кількості замовлень), обслугованих замовлень – 6793 замовлення(71% усієї кількості замовлень. Середнє завантаження машин таксі велике 0,998 (29,9 машини з 30), а завантаження телефоністів – мале 0,198 (1 телефоніст із 5 телефоністів).

288

Рисунок 8.8. Реалізація моделі засобами мови GPSS

289

Рисунок 8.9. Фрагмент звіту про результати моделювання

290