2.4 Модельный таймер, завершение моделирования.

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

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

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

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

Очевидно, выгоднее второй подход, т.к. при этом не обрабатываются моменты времени, на которые не запланировано событий.

Реальный выигрыш во многом зависит от модели и качества реализации системы.

Ближайшее событие определяется обычно на основе списков будущих событий. События в нем стоят в порядке наступления. Когда обрабатываются события, то список будущих событий может быть скорректирован.

В принципе, рассмотренный подход обеспечивает бесконечное время моделирования.

В действительности, рано или поздно, моделирование нужно прекращать.

Завершение моделирование не всегда одномоментное, например, может быть желательно не принимать новых заявок в систему, а дообслужить оставшиеся заявки.

Один из способов завершения, это - введение в модель основного события, называемого завершением моделирования.

Тогда модель должна будет запланировать это событие.

Момент завершения моделирования обычно задают числом и тогда его запланировать нетрудно. В процессе моделирования проверяется, является ли событие завершить моделирование очередным.

Если да, то таймер устанавливается на это время и интерпретатор обрабатывает процедуру конца.

Применительно к примеру с одним прибором, список будущих событий должен состоять максимум из 3-х событий:

• прибытие заявки,

• завершение обслуживания,

• завершение моделирования.

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

2.5 Одновременные события

События одновременны, если они происходят при одном значении модельного времени.

Пусть одновременно завершается обслуживание и поступает заявка.

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

1. Пусть приходит заявка и очередь не пуста. Тогда в любом случае заявка попадает в очередь.

2. Пусть очередь пуста в момент прихода заявки. Тогда:

а) пусть сначала обрабатывается завершение обслуживания. Т.к. очередь пуста, то прибор станет свободным. Когда будет обрабатываться приход заявки - прибор свободен, и заявка попадает на обслуживание;

б) пусть сначала обрабатывается приход заявки. Она попадает в очередь. Затем происходит завершение обслуживания. Далее заявка из очереди попадает на обслуживание. Т.к. все это происходит в один момент модельного времени, то результат тот же самый.

В принципе 1 вариант обработки лучше, т.к. заявка попадает на обслуживание, минуя очередь.

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

Управлять этим можно с помощью приоритетов.