6 МОДЕЛИРОВАНИЕ СИСТЕМ - Страница 2

Перед сортировкой календаря оператор K= J запоминает номер J–й записи, а оператор Z=A3(MATR+2, J) – ее время свершения. Следующий за ними блок DO 4: а) проверяет код очередной, сопоставляемой с J, записи L; б) сравнивает время двух записей; в) запоминает (обновляет K, Z) номер и время  свершения записи L. Если проверяемый код записи L равен нулю, календарь кончился и управление передается на метку 8 для обмена данными между записями J и L (K), так как в цикле DO 4 нормальный ход действий приводит к отысканию записи с временем, меньшим, чем у записи J. Если время свершения записи L оказывается больше или равным тому же для записи J, управление передается метке 4 с переходом к следующей записи календаря (в начало цикла DO 4).

 

После обработки всего календаря циклом DO 2 J=1, NNQ1 очередной оператор WRITE(1’1) A3 выводит данные в файл 1.

Извлечение первой записи. Пример процедуры извлечения первой записи из календаря:

SUBROUTINE RMOVE

DIMENSION A3(MATR+2, NNQ1)

COMMON /COM1/ MATR,…

READ(1’1) A3

TSOB=A3(MATR+2, 1)

I=A3(MATR+1, 1)

DO 1 N=1, MATR

1        ATRIB(N)=A3(N,1)

A3(MATR+1, 1)=0

WRITE(1’1) A3

CALL GRUP

RETURN

END

После копирования календаря в массив A3 из его первой записи извлекаются и запоминаются для передачи через COMMON-область: время свершения (в виде TSOB), код события I и атрибуты события (цикл DO 1). Затем код события первой записи обнуляется (запись становится условно пустой). Измененный календарь выводится в файл 1, а для восстановления порядка записей вызывается процедура GRUP.

Управление ходом  имитации. Порядок вызова рабочих процедур процессором  имитации ясен из рассмотрения следующего модуля:

SUBROUTINE SLAM

DIMENSION A2(MATR+2)

COMMON /COM1/ MATR,…

2        CALL INTLC

1         CALL RMOVE

TNOW=TSOB

CALL EVENT(I)

READ(1’1) A2

IF((TNOW.LT.TTFIN).AND.(A2(MATR+1).GT.0)) GOTO 1

CALL OTPUTN

IF(NRNS.LT.NNRNS) GOTO 2

CALL OTPUT

RETURN

END

Обновление системного времени происходит сразу после извлечения  записи из календаря. Время события TSOB передается в  SLAM через COMMON-область, как и другая информация. Обработка (реализация) события происходит после поиска соответствующей программы процедурой EVENT(J) по коду I извлеченного события (J - формальный параметр, получающий значение J=I при вызове процедуры EVENT). Оператор READ(1’1) A2 копирует первую запись файла календаря для определения одного из двух параметров, участвующих в анализе условия окончания прогона – кода записи. Проверку этого условия ведет оператор IF((TNOW.LT.TTFIN).AND.(A2(MATR+1).GT.0)) GOTO 1. Отчет по прогону и итоговый отчет оформляются соответственно процедурами OTPUTN и OTPUT. Для различения отчетов по прогонам в процедуре OTPUTN  должен быть отображен номер прогона NRNS. Вызов  OTPUTN осуществляется по результату сравнения NRNS и NNRNS в операторе IF(NRNS.LT.NNRNS) GOTO 2.

Процедура инициализации. Структура этого модуля в основном определяется объектными (пользовательскими) условиями. Обязательными являются оператор задания начального имитационного времени и оператор планирования события. Ниже дан учебный пример:

SUBROUTINE INTLC

DIMENSION A3(MATR+2, NNQ1)

COMMON /COM1/ MATR,…

TNOW=TTBEG

NRNS=NRNS+1

LO=0

MLO=0

NI=0

NL=0

READ(1’1) A3

DO 1 J=1, NNQ1

1        A3(MATR+1, J)=0

WRITE(1’1) A3

BUSY=0

CALL SCHDL(1,EXPONS(20.0), ATRIB)

RETURN

END

Здесь устанавливаются: время TNOW начала очередного прогона, номер прогона NRNS,  текущая длина LO очереди для обработки заявки, максимальное  значение MLO длины очереди (MLO увеличивается при LO>MLO и не меняется, если LO<MLO или  LO=MLO), номер NL постановки заявки в очередь К (позволяет фиксировать общее количество заявок, находившихся то или иное время в очереди в течение прогона), номер NI изъятия заявки из очереди (может использоваться для контроля обращения к файлу), содержание элементов массива A3 (предназначенных для кодов событий), состояние программы обработки (оператора приема заявки) BUSY (свободен). Последним рабочим оператором производится планирование очередного события “приход заявки”, где в качестве KEVNTZ употреблен сам код класса, а DTIME рассчитывается по формуле экспоненты.

Главный модуль. Зависит от языка программирования. Пример на фортране:

COMMON /COM1/ MATR,…

DEFINE FILE 1(K1…NZ), 2(K2…NK)

MATR=1

NNQ1=K1

TTFIN=480

TTBEG=0

NRNS=0

NNRNS=10

I1=0

I2=0

M=20.

CALL SLAM

STOP

END

Цифры 1, 2 в операторах объявления файлов – их номера; K1, K2 – количество планируемых записей; NZ, NK – указатели  рабочих записей. Переменные I1, I2 – параметры генератора случайных чисел (зависит от ЭВМ). CALL SLAM – оператор вызова процессора управления.

Обработка событий. Алгоритмы обработки (реализации) событий создаются применительно к особенностям моделируемого объекта. Рассмотрим, например, вариант модуля обработки событий класса 1 – “приход заявки”:

SUBROUTINE ARVL

COMMON /COM1/ MATR,…

CALL SCHDL(1, EXPONS(20.0), ATRIB)

ATRIB(1)=TNOW

IF(BUSY.EQ.0) GOTO 10

LO=LO+1

IF(LO.GT.MLO) MLO=LO

NL=NL+1

WRITE(2’NL) ATRIB

RETURN

10   BUSY=1

DTIMZ=10+15*RAN(I1,I2)

CALL SCHDL(2, DTIMZ, ATRIB)

RETURN

END

Оператор CALL SCHDL(1, EXPONS(20.0), ATRIB) планирует приход следующей заявки. Оператор ATRIB(1)=TNOW уточняет атрибут обрабатываемой заявки, так как переменная TNOW получила значение TSOB, равное времени прихода этой заявки до вызова процедуры ARVL (в модуле SLAM после извлечения  из календаря записи данного события). Оператор IF(BUSY.EQ.0) GOTO 10 по состоянию переменной BUSY проверяет возможность обслуживания данной заявки. Если BUSY может быть задействована, идет переход на  метку 10. При этом переменная BUSY принимает значение 1 (обслуживание заявки) и осуществляется расчет интервала  DTIMZ, который далее используется в операторе вызова процедуры планирования событий класса 2.  Отметим, что атрибут (в массиве ATRIB) заявки, подлежащей обслуживанию в будущем, точно известен.

Если в рассматриваемый момент TNOW (момент прихода обрабатываемой заявки)  BUSY=1, заявка ставится в очередь, длина последней увеличивается (LO=LO+1), корректируется переменная MLO и возрастает общее число NL находившихся в очереди заявок

Оператор WRITE(2’NL) ATRIB заносит данные о клиенте с номером NL в файл очереди.

Ниже дан пример процедуры “окончание обслуживания” (ENDSV):

SUBROUTINE ENDSV

COMMON /COM1/ MATR,…

BUSY=0

IF(LO.GT.0) GOTO 10

RETURN

10   LO=LO –1

NI=NI+1

READ(2’NI) ATRIB

BUSY=1

CALL SCHDL(2, 10+15*RAN(I1,I2), ATRIB)

RETURN

END

Поскольку процедура ENDSV означает окончание обслуживания, переменная BUSY становится равной нулю (оператор BUSY=0). Затем проверяется наличие заявок в очереди: IF(LO.GT.0) GOTO 10. Если очередь не пуста, с метки 10 производится выбор очередной заявки (LO=LO –1), увеличение номера изъятия из очереди (NI=NI+1) и выбор из соответствующей записи файла 2 атрибута события с номером NI (READ(2’NI) ATRIB).

Оператор BUSY=1 определяет новое состояние системы - проведение операции по обработке следующей заявки. Планирование операции начинается с вызова процедуры SCHDL, куда передаются фактические параметры, в том числе интервал обслуживания 10+15*RAN(I1,I2), рассчитываемый, в отличие от предыдущего примера, в операторе вызова.

Поиск алгоритма обработки. Основываясь на приведенных выше процедурах ARVL и ENDSV, организуем поиск программы обработки событий через вызов упомянутых модулей:

SUBROUTINE EVENT(J)

GOTO(1,2), J

1           CALL ARVL

RETURN

2           CALL ENDSV

RETURN

END

Код события I передается в процедуру при ее вызове (область COMMON при этом можно не указывать) . Это число в операторе GOTO(1,2), J задает метку оператора вызова соответствующей программы.

Процедуры сбора и обработки данных, как и модули их вывода (оформление отчета), оформляются изложенными выше способами и могут варьироваться в зависимости от цели имитации и объема представления материала. Например, для вывода данных о NRNS и MLO в записи 1, 2 файла 5 по соответствующему формату можно написать такую процедуру:

SUBROUTINE OTPUTN

COMMON /COM1/…

WRITE (5,1) NRNS

1                   FORMAT ('NRNS=', I2)

WRITE (5,2) MLO

2                   FORMAT ('MLO=', I2)

RETURN

END

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

 

5. СКАНИРОВАНИЕ АКТИВНОСТЕЙ

 

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

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

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

Сканирование активностей не имеет самостоятельного значения и является встроенной частью других моделей.

 

6. ПРОЦЕССНО-ОРИЕНТИРОВАННЫЙ ПОДХОД

 

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

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

Фаза выполнения имитации начинается с извлечения первого события из календаря. Обновляется время и далее производится обработка события по его алгоритму. Эти действия приводят к одному из трех результатов:

1)    транзакт направляется дальше по системе;

2)    транзакт уничтожается;

3)    транзакт задерживается в данной части (блоке, узле) системы.

 

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

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