2.4. Разработка алгоритма моделирования
Алгоритм моделирования предназначен для управления продвижением модельного времени, для обеспечения логической согласованности (синхронизации) процессов и событий, происходящих в ИМ.
Сложность задач, решаемых алгоритмом моделирования определяется тем, что объекты реальной системы и внешней среды функционируют во времени параллельно, а реализующая его имитационная программа выполняется ЭВМ последовательно. Следовательно, процесс функционирования модели может лишь имитировать параллельность протекания процессов в реальной системе. Подобную имитацию можно реализовать с помощью различных методов продвижения модельного времени, которые применяются в зависимости от класса моделируемой системы и выбора соответствующего класса разрабатываемой ИМ (непрерывная, дискретная или непрерывно‑дискретная).
В “рафинированном” виде можно выделить лишь два принципиально отличных друг от друга методов продвижения модельного времени: метод модельных событий (ММС) и метод фиксированного шага по модельному времени (МФШ). Эти методы различаются возможностями реализации различных классов ИМ, а также точностью и адекватностью отображения реальных процессов. При разработке непрерывно‑дискретных моделей они могут использоваться в комбинации друг с другом. Эти вопросы будут далее обсуждены. В следующих же разделах рассмотрим каждый из указанных методов в отдельности.
2.4.1. Метод модельных событий
ММС, как самостоятельный метод, применим исключительно к построению дискретных моделей дискретных систем с использованием событийного подхода на основе ВС.
Сущность метода состоит в реализации для дискретных систем возможности на основе логического анализа текущего состояния ИМ генерации цепочки уходящих в «ближайшее будущее» событий, упорядоченных по времени их свершения. Условность понятия «ближайшее будущее ИМ» связано с тем, что оно определяется не величиной модельного времени, а возможностью планировать в это «будущее» очередные модельные (временные) события.
ММС реализуется с использованием СБС, представляющего собой динамическую структуру логически упорядоченных по возрастанию модельного времени записей, соответствующих этим событиям и имеющих вид, показанный на рис. 2.8.
В программной реализации для этого используется списковая структура данных, в которой записи логически упорядочиваются с помощью ссылок “вперед” и “назад” по первому атрибуту по правилу “меньшая величина – вперед” (LVF).
Событие в СБС с наименьшим временем свершения называется критическим. Назначение основных атрибутов записей событий – обеспечить синхронизацию всех процессов реальной системы, отображаемых в дискретной ИМ, и скачкообразное продвижение модельного времени от одного события к другому, следующему за ним. О назначении дополнительных атрибутов речь будет идти ниже.
Алгоритм моделирования, соответствующий ММС, представлен на рис. 2.9.
В самом начале работы алгоритма формируется начальный СБС, который дает как бы толчок дальнейшему развитию процесса функционирования ИМ. В процессе работы алгоритма первоначально сформулированный СБС будет корректироваться в следующих случаях:
при извлечении критического события (соответствующая запись из СБС удаляется);
в процессе работы алгоритма обработки критического события (могут планироваться новые события или исключаться ранее запланированные, которые не смогут произойти).
Понятие «планирование события» включает в себя следующие две процедуры:
формирование записи, соответствующей планируемому событию;
занесение сформированной записи в СБС с упорядочением ее по времени относительно уже имеющихся там записей.
При реализации алгоритма предполагается, что перед операцией извлечения критического события СБС никогда не окажется пустым. В противном случае процесс моделирования будет завершен аварийно.
В алгоритме моделирования, изображенном на рис.2.9, окончание прогона модели осуществляется, когда текущее модельное время TNOW при очередной корректировке оказывается больше заданного пользователем времени прогона модели ТР. В некоторых моделях применяется другой способ остановки: по свершению определенного временного события, соответствующего такому состоянию моделируемой системы, при котором дальнейший процесс ее функционирования (а следовательно, и ИМ) становится бессмысленным. Такие модели называют моделями с остановом (например, ИМ надежностной структуры невосстанавливаемой системы с событием «отказ системы»).
Для описания правил непрерывного пополнения СБС новыми событиями из ближайшего будущего развивающегося процесса функционирования ИМ, а также исключения из него ранее запланированных событий, которые по тем или иным причинам в результате изменившегося состояния ИМ произойти уже не могут, предлагается формировать граф – схему взаимосвязи временных событий.
Строится ориентированный граф, вершинами которого являются основные модельные события, перечень и коды которых определены при реализации событийного подхода к формализации. Дуга (i,j), обозначенная сплошной линией, показывает возможность планирования нового события c кодом j при обработке свершившего события с кодом i (рис.2.10).
Дуга (k,l), обозначенная штриховой линией показывает необходимость исключения ранее запланированного события с кодом l при обработке события с кодом k. Большинству дуг орграфа ставятся в соответствие условия, определяющие то, когда планирование или исключение событий должно реализоваться. Наличие условия будем изображать записью (i— j) над дугой орграфа с последующим описанием этого условия. Отсутствие условия для той или иной дуги будет означать по умолчанию, что определяемая этой дугой возможность корректировки СБС должна реализоваться при каждом выполнении алгоритма обработки начального для данной дуги события. Необходимо дополнительно подчеркнуть, что никаких ограничений на наличие в формируемом орграфе петель, циклов и контуров не используется.
Рассмотрим вопрос о том, как находить записи исключаемых из СБС событий, когда они не являются критическими. Возможный, но крайне не эффективный способ состоит в последовательном просмотре записей СБС и идентификации нужной записи по значениям атрибутов. Эффективный же способ состоит в следующем. Разработчик ИМ, планируя возможность исключения записи того или иного события до того, как оно станет критическим, вводит специальную ПС, определяющую адрес соответствующей записи при ее занесении в СБС. Так как адреса записей, хранящихся в списковых структурах не меняются, то в любой момент указанной ПС можно воспользоваться для нахождения нужной записи.
Теперь — о том, когда на этапе конструирования ИМ необходимо составлять граф–схему и как ее использовать в процессе построения ИМ. Возможность построения указанной граф‑схемы, обеспечивающей непрерывное развертывание процесса функционирования ИМ является, во‑первых, обоснованием возможности построения дискретной модели. Следовательно, исходя из этой задачи, ее надо сформировать в самом начале этапа формализации. Кроме того, она должна непосредственно использоваться при разработке алгоритмов обработки событий, в которых реализуется проверка условий, отображенных граф‑схемой, и, собственно, корректировка СБС.
Пример. Рассматривается простейшая одноканальная СМО с очередью и ограничением на время пребывания заявок в очереди (рис.2.11).
Рис.2.11
Процесс функционирования имитационной модели такой СМО может быть формализован с помощью следующих временных событий: вход заявки в СМО (код 1), потеря заявки (код 2), окончание обслуживания заявки (код 3).
Граф‑схема взаимосвязи событий имеет вид, показанный на рис. 2.12.
Алгоритм обработки события 1 для указанной выше СМО приведен на рис.2.13, события 2 — на рис.2.14, события 3 — на рис.2.15.
И в заключение этого раздела рассмотрим вопрос о сущности и использовании дополнительных атрибутов в записях событий.
Дополнительные атрибуты – это разновидность формы задания переменных состояния ИМ, которые хранятся в СБС в записи соответствующего события вместе с планируемым временем его свершения и кодом и необходимы в первую очередь для реализации правил его обработки в соответствии с алгоритмом обработки. Это должно облегчить работу со структурой данных, определяющих состояние ИМ. Помещая те или иные переменные состояния в дополнительные атрибуты, необходимо помнить, что простой доступ к ним будет лишь после нахождения соответствующей записи в СБС (например, когда событие, в записи которого есть дополнительные атрибуты, станет критическим). Конечно, принципиально возможно найти необходимые дополнительные атрибуты, просматривая и анализируя последовательно записи в СБС, но это как раз тот пример, как делать ненужно. Примерами дополнительных атрибутов указанного назначения в ИМ СМО в событиях, определяющих прохождение заявок через отдельные компоненты системы, являются приоритет заявки, время входа ее в систему, планируемый маршрут прохождения ее через СМО и т.п.
Во‑вторых, дополнительные атрибуты могут быть использованы для объединения алгоритмов обработки некоторых близких по смыслу и последствиям для состояния ИМ событий в единый алгоритм и уменьшения тем самым объема имитационной программы, трудоемкости алгоритмизации и программирования. Так, например, при формализации СМО с п параллельными каналами обслуживания вместо событий «конец обслуживания в i ‑м канале» (i = 1,2,...,n) можно ввести одно событие «конец обслуживания», а номер канала, в котором завершилось обслуживание, определять соответствующим значением дополнительного атрибута.
В‑третьих, дополнительные атрибуты (впрочем, как и основной атрибут — код события) могут быть использованы для вторичного упорядочения событий в СБС, когда у них совпадают значения первого основного атрибута — модельного времени (говорят, что в этом случае в ИМ образуется «узел событий»). Это может потребоваться для придания алгоритму моделирования большей определенности и адекватности реальному процессу функционирования системы. Например, в ИМ СМО без очереди (с отказами) от того, в каком порядке обработать события «вход заявки» и «окончание обслуживания», если они образуют узел событий, существенным образом зависят результаты моделирования. Если предположить, что вошедшая заявка получает информацию о завершении обслуживания предыдущей, то, очевидно, наиболее адекватным вариантом будет обработка вначале события «окончание обслуживания», а затем — «вход заявки».