Моделювання процесу надходження повідомлень до системи обробки повідомлень(СОП)

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

б) оцінку достовірності вихідної інформації: вихідна інформація є достовірною;

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

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

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

• кількість обслугованих заявок буде більше числа необслугованих;

• завантаження 1 вантажівки буде більше завантаження 2 вантажівки, так як ймовірність запиту 1 вантажівки дорівнює 0,6, а 2 вантажівки - 0,4.

1.2. Алгоритмізація моделі системи і її машина реалізація

1.2.1. Побудова логічної схеми моделі

 

Логічна схема моделі представлена на рис. 3.

Після генерації заявок в джерелі І (блок 1) здійснюється перевірка на наявність місць у накопичувачі Н (блок 2). При відсутності місць заявці буде відмовлено в обслуговуванні (блок 3), вона буде видалена (блок 9) і залишить систему. Якщо місце у накопичувачі Н є, то заявка стає в чергу в накопичувачі (блок 4).

Далі 60% заявок надходить на перевірку зайнятості каналу К1 (блок 5). Якщо канал К1 вільний, то заявки обслуговуються в каналі К1 (блок 7). Якщо канал К1 зайнятий, то заявки надходять на перевірку зайнятості каналу К2 (блок 6). Якщо канал К2 вільний, то заявки обслуговуються в каналі К2 (блок 8). У випадку зайнятості каналу К2 триває перевірка на зайнятість (блок 5). Обслужених заявки надходять на видалення (блок 9) і залишають систему.

 

 

 

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 3. Логічна схема

1.2.2. Отримання математичних відношень

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

1.2.3. Перевірка достовірності моделі системи

На даному підетапі достовірність моделі системи перевіряється за наступними показниками:

а) можливості вирішення поставленого завдання:

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

б) точності відображення задуму в логічній схемі:

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

в) повноті логічної схеми моделі:

Перевірити наявність усіх вище описаних змінних, параметрів, залежностей, послідовності дій;

г) правильності використовуваних математичних співвідношень.

1.2.4. Вибір інструментальних засобів моделювання

 

У нашому випадку для проведення моделювання системи масового обслуговування з безперервним часом обробки параметрів при наявності випадкових факторів необхідно використовувати ЕОМ із застосуванням мови імітаційного моделювання GPSS, тому в даний час найдоступнішим засобом моделювання систем є ЕОМ, а застосування простого і доступного мови імітаційного моделювання GPSS (http://www.gpss.ru) дозволяє отримати інформацію про функції станів z_i(t) системи, аналізуючи безперервні процеси функціонування системи тільки в «особливі» дискретні моменти часу при зміні станів системи завдяки алгоритму, який моделює, реалізованого за «принципом особливих станів» (принцип d z). Крім того, високий рівень проблемної орієнтації мови GPSS значно спростить програмування, спеціально передбачені в ньому можливості збору, обробки і виведення результатів моделювання дозволять швидко і детально проаналізувати можливі наслідки імітаційного експерименту з моделлю.

1.2.5. Складання плану виконання робіт з програмування

 

Вибрана мова імітаційного моделювання GPSS має три версії: MICRO-GPSS Version 88-01-01, GPSS / PC Version 2, GPSS World Students Version 4.3.5. MICRO-GPSS має DOS-інтерфейс, чутливий до стилю  написання програми (кількістю пробілів між операндами, довжині міток та імен та ін), не містить текстового редактора. GPSS / PC позбавлений вказаних недоліків, проте інтерпретатор GPSS World Students має ряд переваг перед ним, наприклад наявність інтерфейсу Windows, покрокового отладчика, можливість збору та збереження у файлах різної статистичної інформації, візуальний введення команд. Тому для розробки моделі був обраний саме інтерпретатор GPSS World Students.

Для моделювання достатньо  використовувати ЕОМ типу IBM / PC, застосування спеціалізованих пристроїв не вимагається. У програмне забезпечення ЕОМ, на якій проводиться моделювання, повинні входити операційна система Windows (версія 9х і вище) і інтерпретатор GPSS. Витрати оперативної і зовнішньої пам'яті незначні, і необхідності в їх розрахунку при сучасному рівні техніки немає. Витрати часу на програмування і налагодження програми на ЕОМ залежать тільки від рівня знань мови та наявних навичок, які були отримані студентом на лабораторних роботах.

1.2.6. Специфікація і побудова схеми програми

 

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

Специфікація постановки задачі даного курсового проекту - визначити кількість заявок на перевезення, виконаних першим або другим вантажівкою за заданий інтервал часу роботи внутрішньозаводського транспорту (N_ОБС), і кількість заявок, які отримали відмову в обслуговуванні внаслідок переповнення заявок у диспетчера за заданий інтервал часу роботи внутрішньозаводського транспорту (N_ОТК). В якості вихідних даних задаються інтервал часу (інтенсивність) надходження заявок до диспетчера (t_пр ± Dt_пр), допустиме число заявок у диспетчера (l_доп), час виконання заявок 1 і 2 вантажівкою (t_гр1±∆t_гр1, t_гр2±∆ t_гр2), а також сеанс зв'язку, для передачі заявки на обслуговування одного з вантажівок (t_св), загрузка вантажівок(Z_ГР1,Z_ГР2).

Специфікація обмежень на параметри досліджуваної системи наступна: вихідні дані повинні бути позитивними числами. (крім того, ймовірність того, що диспетчер запросить 1 або 2 вантажівку, в сумі повинна складати 100%)

Схема програми (см. рис. 4) залежить від обраної мови моделювання.

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

Оцінка витрат машинного часу проводиться за кількома критеріями ефективності програми: витрати пам'яті ЕОМ, витрати обчислень (ідентичні часу обчислень при послідовній обробці), час обчислень («час відповіді»).

1.2.7. Верифікація і перевірка достовірності схеми програми

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

рис. 4. Схема програми

1.2.8. Проведение программирования модели

 

      Текст програми                      Коментарі

	simulate	Початок моделювання
Kont1	BVARIABLE (Q$RemQ>5)	Перевірка місць в  черзі
Provrem1	BVARIABLE (F$Rem1)	Перевірка зайнятості 1 вантажівки
Provrem2	BVARIABLE (F$Rem2)	Перевірка зайнятості 2 вантажівки
	GENERATE 6,3	Генерація вхідних заявок
	TEST E BV$Kont1,0,metdel	Чи є місця в черзі? Якщо місць немає, то переходимо на metdel
	QUEUE RemQ	да, встати в чергу
	TRANSFER .6,metrem2,metrem1	Запит 1 вантажівки з ймовірністю 0,6
metrem1	ADVANCE 1.5	Тривалість сеансу зв’язку  з 1 вантажівкою
	TEST E BV$Provrem1,0,metrem2	Перевірка зайнятості 1 вантажівки; якщо він зайнятий то перехід по мітці metrem2 на 2 вантажівку
	SEIZE Rem1	заняття 1 вантажівки
	DEPART RemQ	збір статистичних даних про вихід заявки з черги RemQ
	ADVANCE 13,7	обробка заявок 1 вантажівкою
	RELEASE Rem1	освобождение 1-го грузовика
	TERMINATE	Знищення відхилених заявок
metrem2	ADVANCE 1.5	тривалість сеансу зв'язку з 2 вантажівкою
	TEST E BV$Provrem2,0,metrem1	Перевірка зайнятості 2 вантажівки; якщо він зайнятий, то перехід по мітці metrem1 на 1 вантажівка
	SEIZE Rem2	заняття 2 вантажівки
	DEPART RemQ	збір статистичних даних про вихід заявки з черги RemQ
	ADVANCE 13,7	обробка заявок 2 вантажівкою
	RELEASE Rem2	звільнення 2-го вантажівки
	TERMINATE	Знищення відхилених заявок
metdel	TERMINATE	Знищення відхилених заявок
	GENERATE 720	Генерація тимчасових заявок для моделювання 12 годин роботи
	TERMINATE 1	Знищення тимчасових заявок
	end	закінчення моделювання

1.2.9. Перевірка достовірності програми

 

На даному підетапів остання перевірка машинної реалізації моделі проводиться таким чином:

а) зворотним перекладом програми у вихідну схему;

б) перевіркою окремих частин програми при вирішенні різних тестових завдань;

в) об'єднанням всіх частин програми і перевіркою її в цілому на контрольному прикладі моделювання варіанту системи.

На цьому підетапів необхідно також перевірити витрати машинного часу на моделювання.

 

1.3. Отримання і інтерпретація результатів моделювання системи

1.3.1. Планування машинного експерименту з моделлю системи

 

Для отримання максимального обсягу необхідної інформації про об'єкт моделювання при мінімальних витратах машинних ресурсів проведемо повний факторний експеримент з чотирма істотними факторами (змінних і параметрів).

Згідно обраними критеріями оцінки ефективності системи та цільової функції моделі виберемо наступні істотні фактори:

х₁ – допустиме число заявок на обслуговування, l_доп = 5;

х₂ – інтервал часу приходу заявок до диспетчера, t_пр = 6 мін;

х₃ – час виконання заявки 1 вантажівкою, t_гр1 = 13 мін;

х₄ – час виконання заявки 2 вантажівкою, t_гр2 = 13 мін.

Задамо рівні варіації для кожного фактора:

Dх₁= 1, Dх₂= 2, Dх₃= 3, Dх₄= 3.

Складемо матрицю плану повного факторного експерименту.

Номер досліда	Фактор х1	Фактор х2	Фактор х3	Фактор х4
0 (базовий)	5	6	13	13
1	4	4	10	10
2	4	4	10	16
3	4	4	16	10
4	4	4	16	16
5	4	8	10	10
6	4	8	10	16
7	4	8	16	10
8	4	8	16	16
9	6	4	10	10
10	6	4	10	16
11	6	4	16	10
12	6	4	16	16
13	6	8	10	10
14	6	8	10	16
15	6	8	16	10
16	6	8	16	16