Моделирование работы станка с поломками

На этапах верификации и валидации осуществляется оценка функционирования имитационной модели. На этапе верификации определяется, соответствует ли запрограммированная для ЭВМ модель замыслу разработчика. Это обычно осуществляется путем ручной проверки вычисления, а также может быть использован и ряд статистических методов.

Установление адекватности имитационной модели исследуемой системы осуществляется на этапе валидации. Валидация модели обычно выполняется на различных  уровнях. Специальные методы валидации включают установление адекватности путем использования постоянных значений всех параметров имитационной модели или путем оценивания чувствительности выходов к изменению значений входных данных. В процессе валидации сравнение должно осуществляться на основе анализа как реальных, так и экспериментальных данных о функционировании системы.

Условия проведения машинных прогонов модели определяется на этапах стратегического  и тактического планирования. Задача стратегического планирования заключается  в разработке эффективного плана эксперимента, в результате которого выясняется взаимосвязь между управляемыми переменными, либо находится комбинация значений управляемых переменных, минимизация или максимизация имитационной модели. В тактическом планировании в отличии от стратегического решается вопрос о том, как в рамках плана эксперимента провести каждый имитационный прогон, чтобы получить наибольшее количество информации из выходных данных. Важное место в тактическом планировании занимают определение условий имитационных прогонов и методы снижения дисперсии среднего значения отклика модели.

Следующие этапы в процессе имитационного исследования- проведение машинного эксперимента и анализ результатов- включают прогон имитационной модели на ЭВМ и интерпретацию  полученных выходных данных. Последним этапом имитационного исследования является реализация полученных решений и документирование имитационной модели и ее использование. Ни одни из имитационных проектов не должен считаться законченным до тех пор, пока их результаты не были использованы в процессе принятия решений. Успех реализации во многом зависит от того, насколько правильно разработчик модели выполнил все предыдущие этапы процессов имитационного исследования. Если разработчик и пользователь работали в тесном контакте и достигли взаимопонимания при разработке модели и ее исследовании, то результат проекта скорее всего будет успешно внедряться. Если же между ними не было тесной взаимосвязи, то, несмотря на элегантность и адекватность имитационного моделирования, сложно будет разработать эффективные рекомендации.

Вышеперечисленные этапы редко  выполняются в строго заданной последовательности, начиная с определения проблемы и кончая документированием. В ходе имитационного моделирования могут  быть сбои в прогонах модели, ошибочные допущения, от которых в дальнейшем приходится отказываться, переориентировки целей исследования, повторные оценки и перестройки модели. Такой процесс позволяет разработать имитационную модель, которая дает верную оценку альтернатив и облегчает процесс принятия решений.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3. Описание моделируемой системы

Схема процесса выполнения заданий  на станке и поломок станка показана на 
рис. 1. Задания поступают на станок в среднем 1 раз в час. Распределение вели- 
чины интервала между ними экспоненциально. При нормальном режиме работы 
задания выполняются в порядке их поступления. Время выполнения задания 
нормально распределено с математическим ожиданием 0,5 ч и среднеквадратич- 
ным отклонением 0,1. Перед выполнением задания производится наладка станка, 
время которой распределено равномерно на интервале 0,2-0,5 ч. Задания, вы- 
полненные на станке, направляются в другие отделы цеха и считаются покинув- 
шими рассматриваемую систему. Станок время от времени ломается. Интервалы 
между поломками распределены нормально с математическим ожиданием 20 ч и 
среднеквадратичным отклонением 2 ч. При поломке выполняемое задание уда- 
ляется со станка и помещается в начало очереди заданий к станку. Выполнение 
задания возобновляется с того места, на котором оно было прервано. Когда ста- 
нок ломается, начинается процесс устранения неисправности, который состоит 
из трех фаз. Продолжительность каждой фазы распределена экспоненциально с 
математическим ожиданием, равным 45 мин. Поскольку общая продолжитель- 
ность устранения поломки является суммой независимых и одинаково опреде- 
ленных случайных величин с одинаковыми параметрами, она имеет эрлангов- 
ское распределение.

 

 

Рис 1. Схема работы станка с поломками

 

Работа станка анализируется в  течение 500 ч для получения информации о за- 
грузке станка и времени выполнения задания.

3.1 Модельное время

 

В качестве единицы модельного времени  примем одну минуту. К генерации  многочисленных случайных величин, входящих в описание системы, будем  подхо- 
дить избирательно. Чтобы генераторы случайных чисел не работали со слишком 
большими или слишком маленькими параметрами и вследствие этого не теряли 
точность при численном интегрировании и решении уравнений, будем в одних 
случаях задавать параметры распределений в минутах, а в других — в часах, ум- 
ножая во втором случае результат на 60 и округляя до ближайшего целого числа, 
а именно:

• интенсивность входного потока — 1 заявка в час;
• время обслуживания: среднее — 30 мин, отклонение — 6 мин;
• время наладки станка: среднее — 21 мин, отклонение — 9 мин;

• время безаварийной работы станка после ремонта: среднее — 20 ч, отклонение — 2 ч. Уточним, что в него не входит то время, когда станок не занят обслуживанием;
• время ремонта: средняя продолжительность фазы — 0,75 ч, отсюда параметр распределения Эрланга равен 1,33.

3.2 Используемые классы и объекты

 

Обобщим первоначальную задачу, предположив, что вместо одного станка у нас есть несколько станков (многоканальный узел). Это обобщение необходимо для того, чтобы выяснить в дальнейшем, как влияет количество (панков на производительность системы. Предположим, что каждый станок обслуживается своими 
собственными наладчиком и ремонтником, так что ни одному из станков не при- 
ходится ожидать ремонта, когда он ему потребуется. Очередь единственная, и за- 
явка попадает на первый свободный станок. Если после поломки станка сущест- 
вует хотя бы один свободный и готовый к обслуживанию станок, заявка сразу же 
переходит к нему, и обслуживание считается непрерывным. Тогда сформулиро- 
ванная задача есть частный случай, когда число каналов (станков) равно едини- 
це. Система является открытой, число заявок — переменное. Для моделирования 
системы необходимо описать класс Станок (Machine), представленный одним по- 
стоянным объектом, и класс Заявка (Client), представленный переменным чис- 
лом объектов, которые по ходу моделирования порождаются в системе и уда- 
ляются из нее. Поведение заявок в системе полностью моделируется станком, 
поэтому класс Client собственного метода run( ) не имеет. Отметим существен- 
ные особенности системы:

• прерывание обслуживания заявки и возвращение ее на дообслуживание осуществляются с учетом полученного ранее обслуживания;
• усложненное расписание работы сервера (станка), необходимость учета наладок, поломок и ремонтов.

Упорядочим имеющиеся у нас  сведения о работе станка. На рис. 2 приведена 
диаграмма его состояний и возможные переходы. Каждый переход обозначен названием метода класса Machine, который этот переход обрабатывает.

 

 

 

Рис. 2. Диаграмма состояний и  переходов станка

 

Изменяемые поля данных класса Machine должны каким-то образом обеспечи- 
вать информацию о текущем состоянии объекта и о том, сколько времени оста- 
лось до перехода в то или иное состояние. Объект класса Client при возвраще- 
нии в очередь должен наряду со временем пребывания в системе сохранять 
информацию об оставшемся времени дообслуживания, а также — в целях сбора 
статистики — изменять значение признака, свидетельствующего о том, что в его 
обслуживании был перерыв. Таким образом, класс Client имеет следующие поля 
данных:

• уникальный идентификатор объекта, равный порядковому номеру поступившей заявки;
• текущее время пребывания в системе;
• оставшееся до окончания обслуживания время. Поле данных имеет смысл 
  только для заявок, вернувшихся в очередь, и только на время их повторного нахождения в ней. Для всех остальных заявок полагаем его равным -1;

• признак прерывания (false — непрерывное обслуживание, true — обслуживание прерывалось). Заметим, что значение признака не переключается в единицу, если после поломки станка заявке сразу же удалось перейти на другой свободный и готовый к обслуживанию станок.

Неизменяемые поля данных класса Machine:

• количество станков (1);
• интенсивность входного потока (1 заявка в час);
• среднее значение времени обслуживания (30 мин);
• среднеквадратичное отклонение времени обслуживания (6 мин);
• среднее значение времени наладки (21 мин);
• максимальное отклонение времени наладки от среднего (9 мин);
• среднее время безаварийной работы (20 ч);
• среднеквадратичное отклонение времени безаварийной работы (2 ч);
• интенсивность одного этапа ремонта (1,33 заявок в час);
• количество этапов ремонта (3);

 
Изменяемые поля данных класса Machine:

• очередь заявок на обслуживание (список указателей);
• массив указателей на обслуживаемые в текущий момент заявки;
• массив времен, остающихся до окончания обслуживания;
• массив времен, остающихся до окончания наладки;
• массив времен, остающихся до окончания безаварийной работы;
• массив времен, остающихся до окончания ремонта;
• время до прибытия следующей заявки из входного потока;
• текущая длина очереди (вычисляемое поле).

 

Отметим, что отличными от -1 в  некоторых состояниях могут быть сразу два изменяемых поля данных станка — время до окончания обслуживания и время до окончания безаварийной работы.

3.3 События и методы

 

В системе с каждым из станков  могут происходить следующие  события:

• поломка станка (Breakage);
• завершение ремонта (Repalr_End);
• завершение наладки (Set_End);
• завершение обслуживания (Complete);
• прибытие новой заявки (Arrival).

Снова обратившись к рис. 2, отметим интересную особенность: между множествами переходов и событий существует связь «многие к одному» — одному пе- 
реходу соответствует одно событие, но одному событию могут соответствовать 
несколько переходов. Перечисленные пять методов программируются по текстовому описанию системы. Остановимся на некоторых нюансах:

• декремент оставшегося времени безаварийной работы следует производить только в том случае, если станок занят обслуживанием. Разыгрывать это время следует при обработке события «Завершение ремонта» (в методе Repair EndO);
• при выборке заявки из очереди время ее обслуживания следует разыграть, если это первый сеанс обслуживания, и взять из поля данных заявки — в противном случае (если это поле отлично от -1);
• необходимо предусмотреть возможность наложения событий. В частности, как поступить, если время безаварийной работы и время обслуживания истекут одновременно? С точки зрения логики, станок не может сломаться после того, как он закончил работать, поломка должна произойти раньше. Поэтому в методе run() (листинг 13.2) мы сначала фиксируем события поломок (тогда заявка уходит в очередь с временем дообслуживания, равным единице), а затем уже для остальных станков производим декременты остаточного времени пребывания в текущем состоянии.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Программная реализация на С++

При создания имитационной модели очереди с разнотипными заявками (работа порта) был выбран язык программирования C++ и написана программа на этом языке, позволяющая в полной мере отразить функционирование системы.