Внутренняя синхронизация компонент модели

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

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

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

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

4.3. Синхронизация моментов появления информации для компонент модели. Чтобы обеспечить синхронизацию моментов доступности информации к компонентам модели (например, процессам), часто прибегают к следующему приему. Используют рабочий массив, который доступен только для данного процесса, и оператор условного ожидания нужного момента времени WAIT WHILE (t₁). При наступлении момента t₁ происходит перезапись рабочего массива в общее поле информации процессов модели. В более простых случаях для синхронизации моментов доступности информации компонентам модели достаточно использовать глобальные переменные модели.

4.4. Отражение конфликтных ситуаций в модели. Отражение в модели возможных конфликтных ситуаций, с которыми может столкнуться управляющая программа модели при имитации.

Ключевые моменты этапа.

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

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

Модель массива – это набор характеристик размера массива и параметров, на которые реагируют алгоритмы компонент модели.

Если необходима имитация передачи массивов между компонентами модели, то они оформляются в виде «подкрашенных» требований.

Подкраска требования – это набор характеристик модели массива, хранящийся в информационной базе.

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

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

«Разгон» имитационной модели – режим работы модели до появления начального состояния.

4.6. Организация окончания имитации. Задание условий окончания имитации очередного варианта моделирования сложной системы в виде финального блока модели.

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

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

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

4.8. Организация сбора статистики. Выбор мест установки операторов сбора статистики.

Способы фиксации статистики моделирования.

· Трассировка алгоритмов компонент модели с помощью наблюдателей модели. Позволяет отслеживать как развитие их функций во времени, так и их взаимодействие друг с другом.

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

Иногда важно фиксировать времена жизни процесса в модели – разница между моментом уничтожения (или последней пассивизации) и моментом создания (первой активизации) процесса.

· Использование набора операторов сбора статистики, предоставляемого системой моделирования. Эти операторы исследователь помещает в выбранные места в алгоритмах процессов, разрывая дополнительно временные интервалы функционирования процессов, образованные операторами синхронизации.

· Сбор стандартной статистики о функционировании компонент модели, обеспечиваемый системой моделирования не требуя от исследователя установки операторов сбора статистики. Чаще всего в состав такой статистики входят характеристики:

- число взаимодействий компонент модели,

- общее время и коэффициент использования компоненты модели,

- число отказов функционирования компоненты системы,

- время, в течение которого компонента системы находилась в аварийном состоянии.

· Использование специальных компонент модели, фиксирующих статистическую информацию о моделируемом объекте. Такие специальные компоненты (процессы, события или активности) могут активизироваться либо с заданным шагом модельного времени, либо при выполнении логических условий в ходе имитационного эксперимента на ЭВМ. В обоих случаях исследователь должен предусмотреть в алгоритме финального процесса набор процедур для вычисления статистик моделирования и на их основе определить отклики имитационной модели согласно выбранным критериям качества вариантов моделирования большой системы.

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

5. Программирование модели: программирование и отладка модели.