Для возможности объединения отдельных имитаторов в распределенную систему имитации в настоящий момент используются следующие стандарты и технологии:
- IEEE1516 (также заменяет HLA и DIS);
- OPC;
- CAPE-OPEN и другие «отраслевые» стандарты.
Наибольший интерес представляет стандарт IEEE 1516, т. к. данный стандарт напрямую относится к имитаторам, направлен на построение систем распределенной имитации (протоколы, рекомендованные методы управления и обратной связи, системная архитектура и т.д).
Семейство программных технологий OPC (OLE for Process Control) предоставляющих единый интерфейс для управления объектами автоматизации и технологическими процессами также представляет значительный интерес, но только в том случае, если необходима интеграция с объектами автоматизации и технологическими процессами. Стандарт CAPE-OPEN используется для взаимодействия имитаторов, разработанных специально для химической промышленности.
В области стандартизации моделирования и имитации значительный вклад внес Институт инженеров по электротехнике и электронике (IEEE). Распределенное моделирование (имитация) – технология обмена данными между тренажерами по локальным или глобальным вычислительным сетям. Это позволяет обеспечить совместную работу отдельных имитаторов как одной управляемой системы моделирования или имитации. Концепция распределенного моделирования опирается на использовании высокоуровневой архитектуры (HLA). Практически стандарт IEEE 1516 определяет архитектуру путем использования единого API (программного интерфейса приложений). Отправными постулатами стандарта являются:
- простые «монолитные» имитационные модели не могут удовлетворить потребности профессиональных пользователей;
- все возможные сферы применения имитационного моделирования заранее неизвестны;
- должны быть предусмотрены возможности произвольного комбинирования отдельных имитаторов в сложные имитационные системы;
- архитектура распределенного моделирования должна быть максимально открыта для будущих технологий моделирования и имитации.
На данный IEEE 1516 является абсолютным стандартом для взаимодействия тренажеров и имитаторов в военных приложениях, что обусловлено жесткими требованиями совместимости с имитаторами, разрабатываемыми и используемыми Министерством обороны США и НАТО. В настоящее время IEEE 1516 находит все большее применение и в гражданской сфере, при разработке имитаторов для тренировки персонала сложных технических систем, в авиации, космонавтике, транспорте и т.д.
Семейство программных технологий 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).
Организации, способные провести сертификацию:
- США. The Department of Defense (DoD) Modeling and Simulation Coordination Office (M&S CO). Сайт: www.msco.mil
- Франция. ONERA. (Office National d’Etudes et Recherches Aérospatiales) is the French national aerospace research center. Сайт: www.onera.fr
- Швеция. Pitch Technologies AB. Сайт: www.pitch.se
Рассмотрим вопросы построения распределенных имитационных систем на основе стандарта 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 (интеракции приведены как пример).
;; комментарий — файл федерации (FED файл) для HLA 1.3
(Fed
(Federation Test)
(FedVersion v1.3)
(Federate "fed" "Public")
(Spaces
(Space "Geo"
(Dimension X)
(Dimension Y)
)
)
(Objects
(Class cYpravlenie
(Attribute wheel1 reliable timestamp)
(Attribute wheel2 reliable timestamp)
(Attribute wheel3 reliable timestamp)
(Attribute wheel4 reliable timestamp)
(Attribute wheel_angle reliable timestamp)
)
(Class cDatchik
(Attribute distance reliable timestamp)
)
)
(Interactions
(Class reaction BEST_EFFORT RECEIVE
(Sec_Level "Public")
(Parameter dx)
(Parameter dy)
(Parameter dz)
)
)
)
Далее, имитатор, представляющий управление создает федерат и объект, на основе класса cYpravlenie. Имитатор, представляющий машину, также создает федерат и объект, на основе класса cDatchik. Также федераты подписываются на интересующие их изменения, т.е. федерат-машина подписывается на получение данных объектов от класса cYpravlenie (т.е. на класс cYpravlenie), а федерат-управление на класс cDatchik. Таким образом машина получает изменения от пульта управления, а пульт получает данные от датчика в машине.
Построение более сложных имитационных систем предполагает достаточно серьезное проектирование. Сначала необходимо определить принципиальный состав федерации в первом приближении, т. е. федераты, объекты федератов и атрибуты объектов. При составлении схемы федерации необходимо учитывать и аппаратные компоненты распределенной имитационной систем, т. е. датчики и управляющие аппаратные устройства также должны быть представлены в виде федератов, объектов и атрибутов. На рисунке. показана структура федерации имитатора установки штангового скважинного насоса.
Рисунок. Структура федерации
После состава федерации необходимо определение связей, т. е. отражения того, какие федераты публикуют (т. е. изменяют) атрибуты объектов, а какие подписываются на изменения этих атрибутов. Как правило на этапе определения связей устанавливается большое количество «поправок» для структуры федерации. После необходимого количества итераций «уточнения» структуры и связей, проектировщики должны установить факт «правильности модели» федерации. Пример определения связей показан на рисунке (объекты, не имеющие связей скрываются).
Рисунок. Пример первого этапа определения связей
На следующем этапе происходит определение необходимого количества компьютеров и соответствующее распределение федератов. Например, федерат «A» будет функционировать на компьютере «1», федераты «B, C, D» будет функционировать на компьютере «2».
Рисунок. Распределение федератов по компьютерам
Как правило распределение федератов основано на экономичности их математической модели, если математические модели федератов не требуют значительных вычислительных ресурсов, то можно использовать один компьютер, если математические модели федератов требуют значительных вычислительных ресурсов, необходимо определение числа компьютеров и соответствующее распределение федератов.
На следующем этапе составляются файл описания федерации (см. пример выше), отражающий утвержденную «правильную модели» федерации. Затем создается программная реализация федератов, путем написания соответствующего кода для взаимодействия с RTI и кода, реализующего математическую модель федерата. На заключительном этапе необходимо тестирование распределенной имитационной системы, выявление ошибок, «перегрузок» определенных компонентов в системе (на основе статистики), правильность синхронизации и т. д.
Статистика по каждому федерату отдельно, так и по федерации в целом показывает количество и типы выполненных запросов и позволяет определить возможные проблемы в ходе работы системы.
Пример статистики по федерату:
RTIA: Statistics (processed messages)
Joined federation as car_federate
Synchronization point announced: ReadyToRun
Achieved sync point: ReadyToRun, waiting for federation...
Federation Synchronized: ReadyToRun
Time Policy Enabled
Published and Subscribed
Add instance object: obj_datchik
Removing temporary file _RTIA_3033_ExampleFederation.fed on resign federation.
Resigned from Federation
Didn't destroy federation, federates still joined
List of federate initiated services
--------------------------------------------------
1 Message::CLOSE_CONNEXION (MSG#1)
1 Message::DESTROY_FEDERATION_EXECUTION (MSG#3)
1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
1 Message::RESIGN_FEDERATION_EXECUTION (MSG#5)
1 Message::SYNCHRONIZATION_POINT_ACHIEVED (MSG#10)
1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
1 Message::SUBSCRIBE_INTERACTION_CLASS (MSG#34)
1 Message::REGISTER_OBJECT_INSTANCE (MSG#40)
1708 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
855 Message::TIME_ADVANCE_REQUEST (MSG#91)
3 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
6 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
1 Message::GET_INTERACTION_CLASS_HANDLE (MSG#116)
120516 Message::TICK_REQUEST (MSG#141)
2564 Message::TICK_REQUEST_NEXT (MSG#142)
List of RTI initiated services
--------------------------------------------------
1 NetworkMessage::ANNOUNCE_SYNCHRONIZATION_POINT (MSG#13)
1 NetworkMessage::FEDERATION_SYNCHRONIZED (MSG#15)
1 NetworkMessage::DISCOVER_OBJECT (MSG#43)
1711 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)
49 NetworkMessage::GET_FED_FILE (MSG#84)
Number of Federate messages : 125662
Number of RTIG messages : 1763
RTIA: Federate destroyed
TCP Socket 3 : total = 122015 Bytes sent
TCP Socket 3 : total = 340249 Bytes received
UDP Socket 4 : total = 0 Bytes sent
UDP Socket 4 : total = 0 Bytes received
Пример статистики по федерации в целом:
CERTI RTIG up and running ...
New federation: ExampleFederation
Looking for FOM file...
Trying... open_test.fed --> cannot access.
Now trying.../usr/local/share/federations/open_test.fed... opened.
TCP Socket 7 : total = 340400 Bytes sent
TCP Socket 7 : total = 122015 Bytes received
UDP Socket 4 : total = 0 Bytes sent
UDP Socket 4 : total = 0 Bytes received
TCP Socket 6 : total = 258616 Bytes sent
TCP Socket 6 : total = 283044 Bytes received
UDP Socket 4 : total = 0 Bytes sent
UDP Socket 4 : total = 0 Bytes received Синхронизация времени
Как показала практика проектирования и реализации распределенных имитационных систем, наибольшее затруднение вызывают вопросы, связанные с управлением течения времени (синхронизация времени).
Как правило, при установке способа синхронизации времени федерата задаются два параметра — TimeRegulating и TimeConstrained. Практически данные режимы влияют на процесс получения сообщений от других федератов и напрямую связаны с механизмом упорядочивания сообщений:
- по порядку получения (сообщения передаются в порядке их получения без контроля времени);
- приоритетный (поступающие сообщения располагаются в очереди с приоритетами, для определения приоритета сообщения используется его временная метка);
- каузальный (обеспечивает отправку сообщений федератам в порядке, согласованном с предшествующими и последующими событиями, представленными этими сообщениями);
- по временным меткам (при использовании этого сервиса сообщения будут переданы федератам в порядке их временных меток).
Также стоит отметить возможность использования различными федератами различных методов синхронизации.
Программные библиотеки для реализации RTI
Список доступных реализации HLA\IEE1516 доступен на странице en.wikipedia.org/wiki/Run-Time_Infrastructure. На сегодняшний день доступно достаточно большое количество реализаций, как коммерческих, так и не-коммерческих. Большинство из реализаций выполнены на языках JAVA и C++ (именно эти языки используются в стандарте), но также существуют реализации для MatLab, Питона (проект CERTI) и др.
При выборе библиотеки отдельное внимание следуют уделять «сертификации» на поддержку IEEE 1516. Как правило, все коммерческие реализации имеют «сертификат», свободные — не имеют (многие из свободных реализаций готовятся к такой сертификации).
Таблица Коммерческие реализации:
- CAE RTI CAE Inc.
- en.wikipedia.org/wiki/CAE_Inc.
- Chronos RTI Magnetar Games
- www.magnetargames.com/Products/Chronos
- MÄK High Performance RTI MÄK Technologies
- www.mak.com/products/rti.php
- HLA Direct General Dynamics C4 Systems
- en.wikipedia.org/wiki/General_Dynamics_C4_Systems
- Openskies RTI Cybernet Systems
- www.openskies.net
- Pitch pRTI Pitch Technologies
- www.pitch.se/products/pitch-prti/pitch-prti-overview.html
- RTI NG Pro Raytheon Virtual Technology Corporation
- www.raytheonvtc.com/products.jsp
Таблица Не-коммерческие реализации:
- CERTI ONERA
- savannah.nongnu.org/projects/certi
- en.wikipedia.org/wiki/ONERA
- The Portico Project littlebluefrog labs
- porticoproject.org
- GERTICO (German RTI based on Corba) Fraunhofer IITB
- www.iitb.fraunhofer.de/servlet/is/2920
- Rendezvous RTI National University of Science and Technology (NUST), Pakistan
- www.mcs.edu.pk/PDC-RG.html
- Open HLA (ohla)
- sourceforge.net/projects/ohla
Я лично для поддержки инфраструктуры распределенных приложений использую проект CERTI от ONERA (https://savannah.nongnu.org/projects/certi).
Замеры скорости взаимодействия федератов через 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 миллионов взаимодействий в секунду и более).
Взаимодействие с реальными системами
В качестве федератов могут выступать не только математические модели объектов, т. е. искусственные системы, но и реальные системы и устройства. Примерами могут служить:
- микрофон, предоставляющий звуковые данные;
- видеокамера, предоставляющая видео-данные;
- различные устройства ввода/вывода, например джойстики (рисунок ), принтеры и т.д.
- различные датчики и управляющие механизмы, подключенные к компьютеру через платы АЦП/ЦАП;
- реальное оборудования и SCADA-системы (рисунок 2.10.1., глава 1.4.1.) через промышленный интерфейс OPC;
- Интерфейсы к «рабочему столу» реальной операционной системы, функционирующей на отдельном компьютере или виртуальной машине (рисунок );
- устройств VR (глава 4.5.9.);
- Интерфейс к базе данных и т. д.
Такие возможности представляют значительный интерес для имитаторов и имитационных систем в целом.
