ms

Об’єкти, які обслуговані основним пристроєм

Черга об’єктів 1

Об’єкти, які обслуговані резервним пристроєм

1 Вільний резервний пристрій

Рисунок 8.4. Фрагмент мережі Петрі, що моделює розгалуження маршрутів об’єктів за ймовірностями

4. Можливості моделювання систем мережами Петрі значно розширюються, якщо припустити, що кількість зв’язків між об’єктами мережі Петрі являється довільним цілим числом. В системі PTRSIM такий зв’язок позначається стрілкою з косою рискою та надписом, що дорівнює кількості зв’язків. Наприклад, мережа Петрі, що моделює процес надходження та збирання деталей двох типів, приймає вигляд як на рисунку 8.5. Деталі першого типу надходять з відомою часовою затримкою по 10 штук разом, а деталі другого типу надходять 20 штук разом також з відомою часовою затримкою. У процесі збирання задіяні одночасно дві деталі першого типу та чотири деталі другого типу.

Рисунок 8.5. Фрагмент мережі Петрі, що моделює процес надходження та збирання деталей різного типу

5. В системах управління часто виникає ситуація, коли стан підсистеми управління залежить від поточного стану всієї системи. Наприклад, кількість товарів, які постачаються, може залежати від кількості невдоволеного попиту. Кількість товарів, які постачаються, може залежати від по-

271

точного стану запасу товарів. Такі моделі в системі PTRSIM реалізуються з використанням зв’язків у кількості, яка залежить від поточного маркірування мережі Петрі (рисунок 8.6). Формула, що визначає кількість зв’язків, передбачає використання маркірувань окремих позицій мережі Петрі, цілих чисел та арифметичних дій між ними.

Невдоволений попит

М(Невдоволений попит)

Рисунок 8.6. Фрагмент мережі Петрі, що моделює гнучку стратегію управління запасами товарів

Введення моделі в імітаційну систему PTRSIM. Система забезпечена зручним графічним інтерфейсом введення моделі. Конструктивними елементами моделі є позиції, переходи та зв’язки мережі Петрі. Розробник моделі обирає піктограми елементів за допомогою миші і розміщує їх в робочу область. Подвійним натисканням миші на піктограмі викликається діалогове вікно, в якому уточнюються параметри елементів. Передбачена можливість збільшення або зменшення масштабу зображення моделі, а також прокрутки зображення для перегляду різних частин систем, якщо вона не може поміститися на екрані. Розробник моделі може перетягувати елементи мережі Петрі на екрані, знищувати їх або копіювати.

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

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

272

ління анімацією дозволяють прискорити або уповільнити її перебіг, а також зупинити моделювання і внести зміни в модель «на ходу». Дослідження змінювання системи в модельному часі, реакції системи на змінювання параметрів надає розробнику моделі можливості упевнитись, що модель працює у відповідності до його розуміння алгоритму імітації.

Виконання імітації при заданих значеннях параметрів. При виконанні робочих прогонів моделі анімацію відключають, оскільки вона уповільнює їх виконання. Дані перехідного періоду при необхідності вилучаються указуванням інтервалу розгону моделі.

Виведення результатів імітації. Статистичні можливості системи забезпечують підраховування середнього значення кількості маркерів у позиції, сумарного значення часу роботи переходу, середнього завантаження переходу, а також виведення графіків змінювання середнього значення кількості маркерів у позиції та середнього завантаження переходу в залежності від часу моделювання. Позиції та переходи, для яких повинні збиратися статистичні дані, указуються розробником моделі.

Формулювання висновків і пропозицій. Висновки та пропозиції щодо поліпшення системи формулюються на основі ретельного статистичного дослідження моделі та за результатами факторного експерименту.

8.3. Пакет імітаційного моделювання Arena

Одним із найбільш ефективних сучасних інструментів імітаційного моделювання є система Arena, що створена Кельтоном у 1998 році [Кельтон]

та постачається компанією Systems Modeling Corporation [Systems Modeling Corporation]. Система Arena дозволяє будувати імітаційні моделі з великої кількості базових конструктивних елементів, відстежувати процес імітації, проводити аналіз результатів моделювання та виконувати оптимізацію відгуку моделі. Імітаційні Arena-моделі можуть бути побудовані для різних сфер діяльності - виробничих технологічних операцій, складського обліку, банківської діяльності, обслуговування клієнтів у маркеті і т.д. і т.п.

Основа технології Arena - мова моделювання SIMAN і система Cinema Animation. Мова SIMAN, що вперше реалізована у 1982 році, є надзвичайно гнучкою та виразною мова моделювання. Вона постійно удосконалюється шляхом додавання в нього нових можливостей. Для відображення результатів моделювання використовується анімаційна система Cinema animation, яка відома на ринку з 1984 року. Процес моделювання організований таким чином. Спочатку користувач будує у візуальному редакторові системи Arena модель, поєднуючи потрібні конструктивні елементи. За необхідності параметри конструктивних елементів уточнюються. Коли здійснюється запуск моделі, система Arena генерує відповідний до моделі код на мові SIMAN, який автоматично запускається.

273

Інтерфейс системи Arena 9.0

Вікно додатку розділене на три області:

üвікно робочого поля;

üвікно параметрів модулів;

üвікно проекту.

üВікно проекту включає декілька панелей:

üBasic Process (панель основних процесів) - містить модулі, які використовуються для моделювання;

üReports (панель звітів) - панель повідомлень: містить повідомлення, які відображають результати імітаційного моделювання;

üNavigate (панель навігації) - панель управління дозволяє відображати всі види моделі, включаючи управління через ієрархічні підмоделі.

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

Вікно властивостей модуля використовуються для настройки параметрів моделі таких як: час, витрати і інші параметри.

Конструктивні елементи пакету Arena

На рисунку 8.7 представлена панель основних процесів Basic Process.

Модуль Create є відправною точкою для вимоги в імітаційній моделі. Вимоги – це об’єкти, які обробляються в системі. Наприклад, документи у сфері бізнесу, клієнти у сфері обслуговування, деталі у сфері виробництва. Створення вимоги модулем відбувається за розкладом, або ж ґрунтуючись на значенні часу між прибуттям вимог в модель. Залишаючи модуль, вимога починає оброблятися в системі. Тип створюваної вимоги визначається в цьому модулі. Параметри модуля та їх призначення:

Name – унікальне ім'я модуля, яке буде відображено в блок схемі.

Entity Type – назва типу вимоги, який створюватиметься модулем.

Type – спосіб формування потоку прибуття. Type може мати значення Random (використовується експоненціальний розподіл з середнім значенням, визначеним користувачем), Schedule (визначається модулем Schedule), Constant (використовуватиметься, визначене користувачем, постійне значення) або Expression (потік прибуття формуватиметься по певному виразу).

274

Value – визначає середнє значення експоненціального розподілу (Random) або постійне значення часу між прибуттям вимоги (якщо Type = Constant).

Schedule Name – ім'я розкладу, який визначає характер прибуття вимоги в систему.

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

Units – Одиниці вимірювання часу між прибуттям (день, година, хвилина, секунда).

Entities per arrival – Кількість вимог, яка входить в систему за одне прибуття.

Max arrivals – Максимальна кількість вимог, яке може створити цей модуль.

First Creation – Час, через який прибуде перша вимога в модель від початку симуляції.

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

Name – унікальне ім'я модуля, яке відображається в блок схемі.

Type – визначає логічну схему модуля. Standard означає, що логічна схема знаходиться усередині модуля і залежить від параметра Action. Submodel показує, що логічна схема знаходитиметься нижче в ієрархічній моделі. Підмодель може містити будь-яку кількість логічних модулів.

Action – тип обробки що відбувається усередині модуля. Delay просто показує про те, що процес займає деякий час і не відображає використання ресурсів. Seize Delay указує на те, що в цьому модулі були розміщені ресурси і відбуватиметься затримка, ресурси захоплюватимуться (тобто будуть зайняті обробкою вимоги), і їх звільнення буде відбувається пізніше. Seize Delay Release указує на те, що ресурс(-и) були захоплені, а потім через час звільнилися. Delay Release означає, що ресурси до цього були захоплені вимогою, а в такому модулі вимога затримається і звільнить ресурс. Всі ці параметри доступні тільки тоді, коли Type = Standard.

Priority – значення пріоритету модулів що використовують один і той же ресурс де завгодно в моделі. Ця властивість не доступна, якщо

Action = Delay або Delay Release, або коли Type = Submodel.

Resources – визначає ресурси або групи ресурсів, які оброблятимуть вимогу в цьому модулі (див. Модуль Process - Ресурси).

275

Delay Type – тип розподілу або процедура, що визначає параметри затримки.

Units – Одиниці вимірювання часу затримки(день, година, хвилина, секунда).

Allocation – Визначає вартісні характеристики обробки. Value Added - означає враховувати вартісні характеристики, а Non-Value Added не враховувати.

Minimum – мінімальне значення для рівномірного і трикутного розподілу.

Maximum – максимальне значення для рівномірного і трикутного розподілу.

Value – середнє значення для нормального і трикутного розподілу або значення для постійної тимчасової затримки.

Std Dev – стандартне відхилення для нормального розподілу. Expression – вираз, що визначає значення тимчасової затримки, якщо

Delay Type = Expression.

Модуль Decide дозволяє враховувати прийняття рішень в моделі. Наприклад, розділення справ на термінові справи і нетермінові, перенаправлення недороблених або зроблених неправильно робіт на доопрацювання та інше. Модуль включає опції прийняття рішень заснованих на умові By Condition (наприклад, якщо тип вимоги Car) або заснованих на вірогідності By Chance (наприклад, 75% - true, а 25% - false). Умови мо-

жуть бути засновані на значенні атрибуту Attribute, значенні змінної Variable, типі об’єкта Entity Type або засновані на виразі Expression. Якщо поставлена умова не виконується те, об’єкт покидатиме модуль через вітку False. Параметри модуля та їх значення:

Name – унікальне ім'я модуля, яке відображається в блок схемі.

Type – тип ухвалення рішення. By Chance - вибір напряму ґрунтується на ймовірності. By Condition - перевірка на виконання умови

Percent True – значення, що визначає відсоток вимог, який підуть по напряму True

If – Тип умови, яка перевірятиметься на виконання.

Named – ім'я змінної, атрибуту або типу вимоги, який перевірятимуться при вході вимоги в модуль.

Is – математичний знак умови, наприклад більше, менше, рівно і т.д. Value – значення, з яким порівнюватиметься атрибут або змінна вимоги, що прийшла. Якщо тип умови - Expression, то у виразі повинен сто-

яти знак умови, наприклад Color<> Red

Даний модуль дозволяє виконувати перевірку не тільки однієї умови, але і декілька. Це досягається за допомогою властивості Type N-way by Chance/by Condition. Залежно від умови об’єкт йде по потрібній вітці.

276

Модуль Batch відповідає за механізм угрупування в імітаційній моделі. Наприклад, зібрати необхідну кількість даних, перш ніж починати їх обробку, зібрати раніше розділені копії одної форми, з'єднати пацієнта і його лікарняну карту прийому до лікаря. Угрупування може бути постійним або тимчасовим. Тимчасово згруповані комплекти пізніше можуть бути роз'єднані за допомогою модуля Separate. Комплекти можуть складатися з будь-якої кількості вхідних об’єктів, визначеної користувачем. Якщо указано правило групування By Attribute, то з’єднуються тільки об’єкти, що мають однакове значення указаного атрибуту. Тимчасові і вартісні характеристики вимоги, які входять у групу, можуть бути рівні сумі характеристик вимоги, які увійшли до групи, або їх добутку.

Об’єкт обслуговування прибуває в модуль, стає в чергу і залишається там до тих пір, поки в модулі не буде набрано задану кількість вимог. Коли збереться потрібна кількість вимог створюється вимога, яка представляє комплект. Параметри модуля та їх значення:

Name – унікальне ім'я модуля, яке відображається в блок схемі.

Type – Спосіб угрупування вимоги, може бути Temporary (тимчасо-

ва), Permanent (постійна).

Batch Size – кількість об’єктів, які утворюють один комплект.

Rule – Визначає, за якою ознакою групуватимуться. Якщо Rule = Any Entity, це означає що перші 3 (якщо Batch Size = 3) вимоги будуть згруповані. Якщо Rule = By Attribute, то об’єднуватиметься задана кількість вимог з певним атрибутом. Наприклад, якщо Attribute Name = Color, то всі вимоги, які мають однаковий атрибут Color, будуть згруповані.

Attribute Name – ім’я атрибуту, за значенням якого групуватимуться об’єкти.

Модуль Separate може використовуватися як для створення копій вхідної вимоги, так і для розділення раніше згрупованих вимог. Наприклад, для роз'єднання раніше згрупованих комплектів документів, для паралельної обробки рахунків і документів по одному замовленню. Правило для розділення вартісних і часових характеристик копій вимоги і розділеної вимоги визначається користувачем. Коли тимчасово згрупована вимога прибуває в модуль, вони розкладаються на складену вимогу. Вимога покидає модуль в тій же послідовності, в якій вони додавалися в комплект. Якщо модуль створює копії вимоги, то користувач може задати кількість дублікатів вимоги. У дубльованої вимоги значення атрибуту, а також анімаційна картинка такі ж, як і оригіналу. Оригінальна вимога також покидає модуль. Параметри модуля та їх значення:

Name – унікальне ім’я модуля, яке відображається в блок схемі.

# of Duplic – Кількість створюваних копій вхідної вимоги.

Type – спосіб розділення вхідної в модуль вимоги. Duplicate Original

277

- просто робить дублікати вхідної вимоги. Split Existing Batch вимагає щоб вхідна вимога була заздалегідь тимчасово згрупована.

Cost to Duplicates – розділення вартісних і тимчасових характеристик вхідної вимоги між тими, що виходять. Це значення визначається користувачем у відсотках, тобто скільки відсотків від вартісних і тимчасових характеристик вхідної вимоги піде копіям (характеристики між копіями діляться порівну).

Allocation Rule – метод розділення вартості і часу, якщо вибраний

Type=Split Existing Batch. Retain Original Entity Values - зберігає оригіна-

льні значення вимоги. Take All Representative Values – всім вимогам при-

своюється однакове значення. Take Specific Representative Values - вимога приймає специфічне значення.

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

Name – унікальне ім'я модуля, яке відображається в блок схемі.

Type – тип призначення, яке здійснюватиметься. Other може включати вбудовані в Arena змінні такі, як місткість ресурсу або кінцевий час симуляції.

Variable Name – ім'я змінної, яка змінюватиметься в цьому модулі. Attribute Name – ім'я атрибуту, який змінюватиметься в цьому модулі. Entity Type – новий тип вимоги, який привласнюється заявці в цьому

модулі.

Entity Picture – нова анімаційна картинка для вимоги, яка пройшла цей модуль.

Other – ім'я змінної в системі, яка змінюється.

New Value – привласнюване нове значення для атрибуту, змінної.

Модуль Record призначений для збору статистики в імітаційній моделі. Наприклад, для підрахування, яка кількість замовлень була виконана із запізненням, підрахування кількості роботи, що здійснюється за одну годину. Модуль може збирати різні типи статистики, включаючи час між виходами вимоги з модуля, статистику вимоги (час циклу, вартість), статистику за період часу (період часу від заданої точки до теперішнього моменту). Також доступний кількісний тип статистики. Параметри модуля та їх значення:

Name – унікальне ім'я модуля, яке відображається в блок схемі.

278

Type – визначає тип статистики, яка збиратиметься. Count - збільшуватиме або зменшуватиме статистику на задане значення. Entity Statistics збиратиме загальну статистику про вимогу, наприклад, час циклу, вартісні характеристики і т.д. Time Interval рахуватиме різницю між значенням атрибуту і поточним часом моделювання. Time Between відстежуватиме час між входженням вимоги в модуль. Expression просто фіксуватиме значення визначуване виразом.

Attribute Name – ім'я атрибуту, значення якого використовуватиметься для інтервальної статистики.

Value –значення, яке додаватиметься до статистики, коли в модуль прибуватиме вимога.

Модуль Dispose є вихідною точкою з імітаційної моделі. Наприклад, клієнти покидають відділ, закінчення бізнес-процесу. Статистика про вимогу може збиратися до того моменту поки вона не вийде з системи. Параметри модуля та їх значення:

Name – унікальне ім'я модуля, яке відображається в блок схемі. Record Entity Statistics – визначає, чи вестиметься статистика про ви-

хід вимоги з системи.

Інші модулі, представлені в панелі основних процесів, призначені для введення допоміжних даних моделі.

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

Entity Type – назва типу вимоги.

Initial Picture – графічне представлення вимоги на початку імітаційного процесу. Це значення може бути згодом змінене за допомогою модуля Assign. Проглянути анімаційні картинки можна так: Edit/ Entity picture.

Holding Cost/Hour – погодинна вартість обробки вимоги в системі. Ця вартість враховується, коли вимога знаходиться в системі, або в черзі, або в стадії обробки.

Initial VA Cost – значення, що привласнюється атрибуту вимоги «додаткова вартість». Значення атрибуту збільшуватиметься кожного разу, як тільки вимога оброблятиметься процесом з додатковою вартістю.

Initial NVA Cost – значення, що привласнюється атрибуту вимоги «не додаткова вартість». Значення атрибуту збільшуватиметься кожного разу, як тільки вимога оброблятиметься процесом з не додатковою вартістю.

Модуль Queue призначений для зміни правила розстановки вимоги в черзі. За умовчанням тип черги First in First out. Параметри модуля та їх значення:

279

Name – унікальне ім'я модуля, що відображається в блок схемі моделі. Attribute Name – ім'я атрибуту, значення якого враховуватиметься,

якщо тип = Lowest Attribute Value або Highest Attribute Value.

Type – правило розстановки об’єктів в черзі. First in First out – перший увійшов, перший вийшов. Last in first out - останній прийшов, перший вийшов. Lowest Attribute Value - перший вийде з черги той, значення атрибуту у якого нижче. Highest Attribute Value - перший вийде з черги той, значення атрибуту у якого найвище.

Модуль Resource призначений для визначення ресурсів і їх властивостей в імітаційному процесі. Ресурсом може бути, наприклад, клерк, продавець, робочий, верстат, телефонна лінія, комп’ютер та інше. Модуль включає вартісну інформацію про ресурси і місткість ресурсів. Ресурси можуть мати фіксовану місткість або ж засновану на розкладі. У ресурсів з фіксованою місткістю протягом імітаційного процесу місткість змінюватися не може. Параметри модуля та їх значення:

Name – ім'я ресурсу.

Type – метод, що визначає місткість ресурсу. Fixed Capacity - фіксована місткість ресурсу. Based on Schedule - місткість ресурсу визначається модулем Schedule.

Capacity – кількість ресурсів, що знаходяться в системі.

Schedule Name – ім’я модуля Schedule, який визначає місткість ре-

сурсу, якщо Type = Based on Schedule.

Busy / Hour – погодинна вартість обробки об’єкта ресурсом. Час враховується тільки тоді, коли ресурс зайнятий обробкою і припиняє враховуватися, коли ресурс звільняється.

Idle / Hour – Вартість ресурсу, коли він не зайнятий.

Per Use – Вартість обробки ресурсом одного об’єкта (не залежить від часу).

Модуль Schedule використовується разом з модулем Resource для визначення місткості ресурсу. Також модуль використовується разом з модулем Create для завдання розкладу прибуття вимоги. Параметри модуля та їх значення:

Name – назва розкладу.

Type – тип розкладу, який може бути Capacity (розклад для ресурсів), Arrival (для модуля Create) або Other (різноманітні тимчасові затримки або чинники).

Time Units – масштаб осі часу в графіці розкладу.

Модуль Set описує групу ресурсів, що використовуються в модулі Process. У групі можуть знаходитися декілька ресурсів. Модуль Set автоматично створює ресурси, місткість яких за умовчанням рівна 1 і без вся-

280