на каком языке реализована система имитационного моделирования cooja

Имитационное моделирование: создание терминов

История создания терминов

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

Напомню, что:

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

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

Понятно, что матаппарат, который был применен, — это статистическая математика. Понятно, что матстатистика не использует термины экземпляры и типы. Она работает с объектами и множествами. В итоге для написания методики я был вынужден был использовать логическую парадигму на основе которой создан стандарт ИСО 15926. Основой его является наличие объектов, классов и классов классов.

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

Примеры определений:

Операция

Событие

Источник

Обзор языков имитационного моделирования (ЯИМ)

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

1. Возможность моделирования стохастических факторов.

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

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

4. Наличие средств управления имитационным экспериментом.

5. Наличие средств для сбора статистики о характеристиках исследуемой системы с последующим статистическим анализом их значений.

Классификация языков имитационного моделирования

Универсальные алгоритмические языки Проблемно-ориентированные языки

CSMP Схема Схема Схема

DIHYSYS событий активностей процессов

SIMSCRIPT-II CSL SIMULA

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

В языках моделирования непрерывных процессов для их описания используются дифференциальные уравнения. Изменение состояния системы описывается с помощью переменных состояний и выходных переменных, динамика изменения которых задается уравнениями уровней и скоростей соответственно. Переменные состояний (уровни) описывают состояние системы в данный момент времени. Уравнения скоростей описывают, как изменяется состояние системы за некоторый отрезок времени.

Языки моделирования дискретных процессов реализуют одну из трех основных схем функционирования дискретно-событийных мониторов.

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

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

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

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

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

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

Оценка адекватности проблемно-ориентированной модели

Исследуемой системе

Объектом исследования в имитационном эксперименте является не сама исследуемая система, а её модель. Результаты, получаемые на модели, переносятся на систему, поэтому необходимо получить результаты, характеризуемые высокой информационной надежностью (достоверностью). Такая достоверность определяется:

1. Вероятностной мерой адекватности модели исследуемой системе (D1).

2. Достоверностью статистического эксперимента с моделью (D2). D2 обеспечивается методами стратегического и тактического планирования эксперимента.

В этом случае технология имитационного эксперимента включает две фазы: специфицирующую (информационную) и вычислительную (статистическую, интерпретирующую). Таким образом, информационная надежность модели D определяется как D=D1*D2.

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

– уровень предметной ориентации ПОЯМ,

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

L_ПОЯМ – длина программы в условных лингвистических единицах на проблемно-ориентированном языке моделирования,

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

Проблемная ориентация ПОЯМ приводит к сокращению описания модели.

При p=1 Nad=0. При уменьшении p увеличивается Nad. Например, для U=5 и Lпоям=250 при p=0.999 Nad=0.1; при p=0.99 Nad=1; при p=0.9 Nad=10.

С ростом сложности модели, т.е. с увеличением длины модели L_ПОЯМ и снижением индивидуальной надежности пользователя p повышение уровня предметной ориентации языка имитационного моделирования становится основным средством обеспечения адекватности модели.

Источник

Системы имитационного моделирования: выбираем подходящую

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

Эксперимент vs имитация

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

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

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

Ведущие системы для моделирования ХТП

В рамках построения системы автоматического управления теплоснабжением предприятия (одного из его сложных процессов) специалистам нашей компании “Первый инженер” потребовалось исследовать технологический процесс: проанализировать переходные процессы и выявить критические технологические участки, а также проанализировать возможности применения программного продукта в системе управления (для выработки оптимальных режимов работы системы теплоснабжения в автоматическом режиме). Так мне и пришлось изучать рынок в поиске готового программного инструмента. Результатами анализа ПО делюсь с вами. Ниже будет много таблиц.

При подготовке статьи для Хабра я пытался связаться со всеми производителями указанного ПО и уточнить данные, ведь за прошедшее время они могли усовершенствовать свои продукты. Но ответ пришел только от GIBBS. Поэтому буду рад вашим уточнениям в комментариях.

Краткие описания решений

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

В 2002 году компанию Hyprotech Ltd приобрела Aspen Technologies. Hysys вошел состав пакета инженерного модуля AspenONE Engineering пакета AspenONE под наименованием Aspen Hysys.

Программный пакет Aspen Plus (разработка Aspen Technologies) предназначен для моделирования в стационарном режиме, проектирования химико-технологических производств, контроля производительности оборудования, оптимизации и бизнес-планирования в области добычи и переработки углеводородов и нефтехимии.

gPROMS ModelBuilder является средой моделирования для стационарных и динамических систем, которая ориентирована на применение в перерабатывающей промышленности.

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

Design II – программный продукт компании WinSim Inc. – имеет все инструменты для полноценного моделирования в газонефтепереработке и включает набор из 880 различных компонентов.

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

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

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

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

* Программные комплексы в таблице имеют различные формы лицензирования: локальные, сетевые и бесплатные. Локальная лицензия предусматривает установку программы на конкретный компьютер, авторизуется и работает только на нем. Сетевая лицензия предназначена на установку продукта на несколько компьютеров, но при этом количество одновременных пользователей не должно превышать количество купленных лицензий. Бесплатная лицензия распространяется для «ознакомления» с возможностями ПО, которые имеют временные или функциональные ограничения.

Системные требования

Каждый из представленных программных продуктов предполагает минимальные системные требования для его полноценной работы – наличие ОС Microsoft и лицензии.

Характеристики программных комплексов

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

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

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

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

Модули в составе программного комплекса

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

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

Интерфейс программных комплексов

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

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

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

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

Источник

Распределенные имитационные системы

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

Семейство программных технологий 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 – это федерация, федерат, объект, атрибут и интеракция. Понятие объекта определяется как модель отдельного явления реального мира. Объекты не имеют методов, а имеют только состояния (только структура данных без функций их обработки). Состояния объектов характеризуется фиксированным набором атрибутов — точных значений, которые могут изменяться с течением времени. Каждый объект в любой момент времени характеризуется своим состоянием, которое определяется набором текущих значений его атрибутов. Федераты представляют собой математические описания поведения объектов – имитационные модели, заданные программно (реализованные на директивном языке) или представленные значениями датчиков аппаратных средств. Фактически федератами могут быть как имитаторы, так и реальное оборудование или специальное программное обеспечение. Единственным требованием является обеспечение единого интерфейса для взаимодействия. Федераты могут управлять объектами, меняя (обновления) или получая (отображая) значения их атрибутов. В частности, пользователи имитаторов также являются федератами. Совокупность всех участвующих в имитационном моделировании федератов образует федерацию.

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

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

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

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

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

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

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

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

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

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

Более подробное изложение реализации сопряжено с необходимостью представления достаточно большого листинга программы, по этой причине, читатель может самостоятельно воспользоваться примерами программ, которые поставляются вместе с программным обеспечением для поддержки RTI. Достаточно простые примеры, содержащие множество комментариев, входят в состав библиотеки The Portico Project и свободно доступны на сайте porticoproject.org. Практически все коммерческие реализации стандарта также содержат в своем составе множество примеров.

В качестве примера можно рассмотреть следующую федерацию, состоящую из двух федератов: радиоуправляемая машина и пульт управления. Предположим, что управления осуществляется путем установки оборотов каждого из 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

Список доступных реализации HLA\IEE1516 доступен на странице en.wikipedia.org/wiki/Run-Time_Infrastructure. На сегодняшний день доступно достаточно большое количество реализаций, как коммерческих, так и не-коммерческих. Большинство из реализаций выполнены на языках JAVA и C++ (именно эти языки используются в стандарте), но также существуют реализации для MatLab, Питона (проект CERTI) и др.

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

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

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

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

Для достижения минимальных временных задержек необходимо выбирать сервер с наименьшими временными задержками прохождения пакетов (можно проверить при помощи команды ping). В качестве примера рассмотрим работу одной из созданных в НИИ ЭОР ТюмГНГУ распределенных систем. Используется 100 мегабитная сеть (задержки ping’a

Источник