Что такое процессорное время в имитационном моделировании

Обновлено: 15.01.2025

1.7.1 Управление модельным временем

При разработке практически любой имитационной модели и планировании проведения модельных экспериментов необходимо соотносить между собой три представления времени:

• реальное время, в котором происходит функционирование имитируемой системы;

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

• машинное время, отражающее затраты времени ЭВМ на проведение имитации.

С помощью механизма модельного времени решаются следующие задачи:

1) отображается переход моделируемой системы из одного состояния в другое;

2) производится синхронизация работы компонент модели;

3) изменяется масштаб времени «жизни» (функционирования) исследуемой системы;

4) производится управление ходом модельного эксперимента;

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

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

Существуют два метода реализации механизма модельного времени — с постоянным шагом и по особым состояниям.

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

При использовании метода постоянного шага отсчет системного времени ведется через фиксированные, выбранные исследователем интервалы времени. События в модели считаются наступившими в момент окончания этого интервала. Погрешность в измерении временных характеристик системы в этом случае зависит от величины шага моделирования . Метод постоянного шага предпочтительнее, если:

• события появляются регулярно, их распределение во времени достаточно равномерно;

• число событий велико и моменты их появления близки;

• невозможно заранее определить моменты появления событий.

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

В общем виде алгоритм моделирования с постоянным шагом представлен на рис. 1.8 ( — текущее значение модельного времени, — интервал моделирования).

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

• принимать величину шага равной средней интенсивности возникновения событий различных типов;

• выбирать величину Dt равной среднему интервалу между наиболее частыми (или наиболее важными) событиями.

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

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

Моделирование по особым состояниям целесообразно использовать, если:

• события распределяются во времени неравномерно или интервалы между ними велики;

• предъявляются повышенные требования к точности определения взаим-ного положения событий во времени;

• необходимо реализовать квазипараллельную обработку одновременных событии.

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

Обобщенная схема алгоритма моделирования по особым состояниям представлена на рис. 1.9 (- прогнозируемый момент наступления -го события.

Копирование информации со страницы разрешается только с указанием ссылки на данный сайт

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

Прежде всего, следует определить, что следует понимать под термином «время» в имитационном моделировании. В работе Fujimoto и других работах по имитационному моделированию различают: физическое (physical), модельное (system time) и процессорное (wallclock time). Рассмотрим более подробно все эти 3 разновидности:

- Физическоевремя (physical-T_p) – это время, которое используется в реальной (физической) системе, которую моделируют. Например, мы моделируем работу некоторого предприятия в течение рабочего дня с 8.00 до 17.00.

- Модельное время (simulation time - T_s) – это представление физического времени в модели. Так работу предприятия в модельном времени можно представить отрезком времени [8.00,17.00], за единицу модельного времени (h) можно принять временной интервал в 1 минуту, в 10 минут, в 30 минут, в один час и т.д. T_s = T_p/h.

- Процессорное время (wallclock time - T_w) – время работы симулятора на компьютере. Так, например, моделирование предприятия может занять 1 час работы на компьютере.

Моделирование должно выполняться как можно скорее (as-fast-as-possible), т.е. модельное время продвигается с гораздо большей скоростью, чем процессорное. Например, работа некоторого физического процесса длится несколько суток, единицу модельного времени выбирают равной одному часу, а процесс моделирования на компьютере выполняется за 30 минут.

Иногда (при использовании тренажёров) продвижение модельного времени должно быть синхронизировано с процессорным. Такое моделирование называют моделированием в реальном времени (real time). Действительно, при использовании тренажёров человек погружается с виртуальную среду, которая должна выглядеть как можно более реалистичной.

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

Известно, что существуют различные виды имитационных моделей, в основе которых лежит та или иная концепция:

- Объекты (objects) или агенты (agents).

- Непрерывные (continues) модели (системная динамика).

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

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

В зависимости от того, какая концепция лежит в основании имитационной модели, системы моделирования делятся процессо-ориентированные, событийно-ориентированные, объектно-ориентированные, агентные.

Рассмотрим более подробно событийно-ориентированное моделирование

В событийно-ориентированных системах моделирования приняты следующие соглашения:

- модель продвигается во времени от события e_i к событию e_j, которые изменяют состояние модели,

- логика наступления событий определяет последовательность смены состояний модели, которые связаны с наступлением этих событий;

- время продвигается от события к событию;

Пусть время – частично упорядоченное множество T =1, t₂,…,t_n>. Пусть существует множество событий e_i Î E, i = 1,2. n. Любое событие может включать преобразование Sch: E ´ T ´ E, т.е. событие e_i (выполняющееся в момент времени t_i) может планировать выполнение другого события e_j в момент времени t_j и размещать его в календаре событий. Календарь событий состоит из элементов, каждый из которых содержит два поля:

- ссылку на запланированное событие (e_i);

- модельное время, на которое запланировано событие (t_i).

Таким образом, можно сказать, что календарь событий (обозначим его SE) – это список элементов l_i, где каждый элемент l_i представляет собой пару (e_i , t_i).

Управляющая программа (симулятор) должна выбрать из календаря событий событие с минимальным временем.Это время становитсятекущим модельным временем. Симулятор присваивает системной переменной с текущим модельным временем (назовём эту переменную именем Systemtime) минимальное значение времени, на которое запланировано событие из календаря событий, т.е. Systemtime = min (t_i). Далее симулятор передаёт управление событию e_i (с минимальным временем).

Цель: Необходимо выбрать очередное событие в календаре событий и передать ему управление:

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

IEEE1516 (также заменяет HLA и DIS);
OPC;
CAPE-OPEN и другие «отраслевые» стандарты.

Семейство программных технологий OPC (OLE for Process Control) предоставляющих единый интерфейс для управления объектами автоматизации и технологическими процессами также представляет значительный интерес, но только в том случае, если необходима интеграция с объектами автоматизации и технологическими процессами. Стандарт CAPE-OPEN используется для взаимодействия имитаторов, разработанных специально для химической промышленности.

В области стандартизации моделирования и имитации значительный вклад внес Институт инженеров по электротехнике и электронике (IEEE). Распределенное моделирование (имитация) – технология обмена данными между тренажерами по локальным или глобальным вычислительным сетям. Это позволяет обеспечить совместную работу отдельных имитаторов как одной управляемой системы моделирования или имитации. Концепция распределенного моделирования опирается на использовании высокоуровневой архитектуры (HLA). Практически стандарт IEEE 1516 определяет архитектуру путем использования единого API (программного интерфейса приложений). Отправными постулатами стандарта являются:

простые «монолитные» имитационные модели не могут удовлетворить потребности профессиональных пользователей;
все возможные сферы применения имитационного моделирования заранее неизвестны;
должны быть предусмотрены возможности произвольного комбинирования отдельных имитаторов в сложные имитационные системы;
архитектура распределенного моделирования должна быть максимально открыта для будущих технологий моделирования и имитации.

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

Для создания сложных имитационных систем можно комбинировать использование IEEE 1516 и OPC, получая возможность использования реального оборудования и SCADA-систем (рисунок ), что может быть достаточно полезным во многих задачах.

Обеспечение связи стандартов IEEE 1516 (являющегося базовым для имитаторов) и OPC (применяемого в SCADA-системах) может быть реализовано, как напрямую в имитаторе, так и посредством посредника. Роль такого посредника, например у меня, выполняет пакет National Instruments LabView. LabView может поддерживать математические модели любой сложности, имеет встроенную поддержку OPC, может выступать в роли OPC-сервера, имеет эффективную поддержку взаимодействия с различными платами ввода вывода, что позволяет использовать необходимое оборудование напрямую, но не имеет, к сожалению, средств взаимодействия с IEEE 1516, что требует написания соответствующих программных компонентов.

В результате использования IEEE 1516 и OPC возможно создание относительно сложных распределенных систем имитации, включающих в себя множество имитаторов, реальное оборудование, SCADA-системы и т. д.

Отдельного рассмотрения заслуживает вопрос сертификации имитатора или имитаторов относительно поддержки стандарта IEEE 1516. Сертифицируются как имитаторы (федераты в терминологии IEEE 1516), так и программные библиотеки, реализующие взаимодействие. Но целью данной сертификации не является выявление функциональных дефектов программы (только сертификация поддержки стандарта IEEE 1516).

Организации, способные провести сертификацию:

Рассмотрим вопросы построения распределенных имитационных систем на основе стандарта IEEE 1516. Базовые термины, используемые в информационном обеспечении, соответствуют терминологии стандарта на системы распределенной интерактивной имитации IEEE 1516 – это федерация, федерат, объект, атрибут и интеракция. Понятие объекта определяется как модель отдельного явления реального мира. Объекты не имеют методов, а имеют только состояния (только структура данных без функций их обработки). Состояния объектов характеризуется фиксированным набором атрибутов — точных значений, которые могут изменяться с течением времени. Каждый объект в любой момент времени характеризуется своим состоянием, которое определяется набором текущих значений его атрибутов. Федераты представляют собой математические описания поведения объектов – имитационные модели, заданные программно (реализованные на директивном языке) или представленные значениями датчиков аппаратных средств. Фактически федератами могут быть как имитаторы, так и реальное оборудование или специальное программное обеспечение. Единственным требованием является обеспечение единого интерфейса для взаимодействия. Федераты могут управлять объектами, меняя (обновления) или получая (отображая) значения их атрибутов. В частности, пользователи имитаторов также являются федератами. Совокупность всех участвующих в имитационном моделировании федератов образует федерацию.

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

Рисунок. Иерархическая схема федерации

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

Рисунок. Общий механизм взаимодействия (RTI)

Рисунок. Организация распределенной имитации и совместной работы

При создании распределенных имитационных систем, взаимодействующих через RTI, необходимо учитывать следующие важные особенности. Все элементы федератов и федерации должны быть документированы в определенных файлах (для описания федерации используются FOM (federation object model) файлы), федераты описываются в SOM-файлах (Simulation Object Model). Все данные хранятся только в федератах, RTI не хранит никаких данных, а только передает их. HLA позволяет в любой момент времени только одному федерату изменять значение какого либо атрибута (для передачи прав имеется специальый механизм управления правами). Федераты могут управлять локальным временем, в HLA используются различные внутренние механизмы управления временем (синхронизацией).

В целом, стандарт IEEE 1516 затрагивает огромное количество вопросов, связанных с созданием распределенных имитационных систем, таких как сохранение состояния федерации, возобновление состояния, различные механизмы синхронизации времени, области взаимодействия федератов и т.д. В связи со значительным объемом самого стандарта и, тем более, объемом программного кода для демонстрации всех аспектов, описанных в стандарте, далее будет продемонстрирована только принципиальная реализация «базовых» возможностей (рисунок ).

Рисунок. Блок-схема реализации базовых возможностей IEEE 1516

В качестве примера можно рассмотреть следующую федерацию, состоящую из двух федератов: радиоуправляемая машина и пульт управления. Предположим, что управления осуществляется путем установки оборотов каждого из 4-х двигателей машины и поворота передних колес. На машине установлен датчик, определяющий расстояние до препятствия и передающий сигнал на пульт управления. Для этого необходимо определить два класса объектов, cYpravlenie для пульта управления и cDatchik для датчика дистанции. Атрибутами класса cYpravlenie являются wheel1, wheel2, wheel3, wheel4, wheel_angle. Атрибутом класса cDatchik является distance. Далее показан файл описания федерации, в формате HLA 1.3 (интеракции приведены как пример).

Далее, имитатор, представляющий управление создает федерат и объект, на основе класса cYpravlenie. Имитатор, представляющий машину, также создает федерат и объект, на основе класса cDatchik. Также федераты подписываются на интересующие их изменения, т.е. федерат-машина подписывается на получение данных объектов от класса cYpravlenie (т.е. на класс cYpravlenie), а федерат-управление на класс cDatchik. Таким образом машина получает изменения от пульта управления, а пульт получает данные от датчика в машине.

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

Рисунок. Структура федерации

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

Рисунок. Пример первого этапа определения связей

На следующем этапе происходит определение необходимого количества компьютеров и соответствующее распределение федератов. Например, федерат «A» будет функционировать на компьютере «1», федераты «B, C, D» будет функционировать на компьютере «2».

Рисунок. Распределение федератов по компьютерам

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

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

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

Пример статистики по федерату:

Синхронизация времени

Как показала практика проектирования и реализации распределенных имитационных систем, наибольшее затруднение вызывают вопросы, связанные с управлением течения времени (синхронизация времени).

Программные библиотеки для реализации RTI

При выборе библиотеки отдельное внимание следуют уделять «сертификации» на поддержку IEEE 1516. Как правило, все коммерческие реализации имеют «сертификат», свободные — не имеют (многие из свободных реализаций готовятся к такой сертификации).

Таблица Коммерческие реализации:

CAE RTI CAE Inc. .
Chronos RTI Magnetar Games
MÄK High Performance RTI MÄK Technologies
HLA Direct General Dynamics C4 Systems
Openskies RTI Cybernet Systems
Pitch pRTI Pitch Technologies
RTI NG Pro Raytheon Virtual Technology Corporation

CERTI ONERA
The Portico Project littlebluefrog labs
GERTICO (German RTI based on Corba) Fraunhofer IITB
Rendezvous RTI National University of Science and Technology (NUST), Pakistan
Open HLA (ohla)

Замеры скорости взаимодействия федератов через RTI

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

Для достижения минимальных временных задержек необходимо выбирать сервер с наименьшими временными задержками прохождения пакетов (можно проверить при помощи команды ping). В качестве примера рассмотрим работу одной из созданных в НИИ ЭОР ТюмГНГУ распределенных систем. Используется 100 мегабитная сеть (задержки ping'a < 0.231 ms), временная синхронизация отсутствует (для уменьшения задержек внутри RTI), 2 компьютера, сервер (rtig) запущен на одной из машин. Параметры федерации — 2 объекта содержит по 5 атрибутов (по одному объекту на федерат/компьютер), взаимодействие между федератами двухстороннее. В результате обработки замеров получена зависимость количества взаимодействий в секунду от размера передаваемых данных.

Результаты таких замеры позволяют сделать множество выводов, например, если имитатор должен работать в заданном «реальном времени», т.е. обновляться, например, не менее 60 раз в секунду, то за одно взаимодействие (для Fast Ethernet) должно передаваться не больше 300 килобайт (если например 5 атрибутов, то по 60 килобайт каждый). В тоже время, 300 килобайт данных, передаваемых 60 раз в секунду, также указывает на возможность использования RTI для передачи голосовых и видео данных между имитаторами, а также для взаимодействия с устройствами VR.

При взаимодействии федератов через Internet минимальные задержки в большей степени определяются задержками передачи пакетов. Например, если задержки прохождения пакета между сервером и имитатором составляют 300 мсек, то максимальное количество взаимодействий в секунду не будет превышать 3.

Применение более скоростных решений, таких как IpoIB (IP over InfiniBand, RFC 4392), 10G Ethernet, Myrinet-10G и др. позволит увеличить пропускную способность и значительно снизить задержки (существующие решения позволяют производить 30 миллионов взаимодействий в секунду и более).

Взаимодействие с реальными системами

В качестве федератов могут выступать не только математические модели объектов, т. е. искусственные системы, но и реальные системы и устройства. Примерами могут служить:

1. Реальное время - время, в котором функционирует исследуемая система, определяется ходом обычных часов.

2. Системное или модельное время – это объект программы моделирования, имитирующий ход часов реального времени. Если реальная система функционирует на отрезке [t1,t2], то значение системного времени STIME тоже должно быть изменено в этих пределах, при выполнении условия STIME>t2 моделирования заканчивается

3. Компьютерное время – связано с продолжительностью выполнения программы моделирования, которое определяется эффективностью реализации программы и мощностью ресурсов компьютера.

Соотношение между различными типами времени

в имитационном моделировании

Исследуемая система

Часы реального времени

Компьютер

Программа моделир-я

Часы модульного времени

Аппаратура

Таймер

Связь 1 определяет отношение копирования, т.е. модельное время является копией реального.

Связь 2 определяет отношение управления. Таймер управляет выполнение программы моделирования.

Связь 3 определяет отношение синхронизации. Если связь 3 присутствует – это модель реального времени. Модельное время в компьютерном может только возрастать.

_{компьютерное время}

₁

₂

Эффект скачущих часов

Эффект скачущих часов свидетельствует об ошибках в программе моделирования.

Величина в общем случае никак не связана с величиной ₂- ₁ функционирования модели.

Читайте также: