Верхнеуровневая архитектура: различия между версиями

Материал из CAMaaS preliminary wiki
Перейти к навигации Перейти к поиску
 
(не показаны 22 промежуточные версии 2 участников)
Строка 1: Строка 1:
== Обсужденная архитектура ==
{{UC1 brief}}


[[Файл:Top structure 3 draft.png|500px|thumb|Верхнеуровневая архитектура]]
[[Файл:Top structure 4 draft.png|500px|thumb|Верхнеуровневая архитектура]]


Use case, в котором все данные передаются через централизованную управляющую подсистему.
=== Структура ===


# Пользователь через браузер [[Веб-сервер|подключается]] к управляющей подсистеме.
На верхнем уровне системной иерархии система принципиально состоит из предметно-независимой и предметно-ориентированной подсистемы.
# Пользователь загружает необходимые скрипты
# Пользователь создает модельный проект (загружает его с локального хранилища, подключается к работе над существующим проектом, загружает его с банка данных пользователя).
# Пользователь создает/изменяет геометрическую модель.
# Управляющая подсистема делегирует вызов подсистеме геометрического моделирования
# Подсистема геометрического моделирования фактически изменяет параметры геометрической модели
# ''Подсистема геометрического моделирования сохраняет модель в СУБД 2?''
# Подсистема геометрического моделирования передает модель управляющей подсистеме
# Управляющая подсистема передает полученные данные графической подсистеме.
# Графическая подсистема передает данные для визуализации пользователю
# Браузер выполняет визуализацию модели
# Пользователь обращается к управляющей подсистеме с запросом на ассоциацию данных из [[Система управления банком данных|базы данных предметных областей]] с компонентами геометрической модели для выбранной предметной области
# Управляющая подсистема делегирует запрос подсистеме предметной области.
# Подсистема предметной области запрашивает управляющую подсистему на получение данных из базы данных предметных областей.
# Управляющая подсистема, обращаясь к базе данных предметных областей, считывает данные и передает их ответом подсистеме предметной области.
# Подсистема предметной области считывает данные и задает их ассоциацию с компонентами геометрической модели.
# Подсистема предметной области возвращает ответ управляющей подсистеме
# Управляющая подсистема возвращает ответ пользователю
# Пользователь посылает запрос на запуск процедуры моделирования управляющей подсистеме.
# Управляющая подсистема делегирует вызов подсистеме предметной области


* 3A В случае создания нового проекта, или если пользователь решает выполнить новое моделирование в выбранной им предметной области
Предметно-независимая подсистемы разрабатывается нами без какой-либо привязки к предметной области проведения модельных экспериментов.
** 1. Пользователь обращается к управляющей подсистемой с запросом на получение списка подсистем предметных областей (т.е. списка самих предметных областей).
** 2. Пользователь выбирает предметную область
* 3Б Если пользователь решает загрузить проект из СУБД2 ...


== Исходная архитектура ==
Предметно-независимая подсистема выполняет посреднические функции между [[Моделирующий пользователь|моделирующим пользователем]] с одной стороны и предметно-ориентированной подсистемой с другой, а также выполняет сервисные функции по хранению данных пользователя и предметной области, по распределению нагрузки между параллельными вычислителями предметно-ориентированной подсистемы, и по реализации политики безопасности.


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


[[Файл: Top_struct.jpg|thumb|Верхнеуровневая структурная диаграмма системы моделирования]]
Структурно, верхний уровень определяется следующими компонентами.


* ''[[Подсистема геометрического моделирования]]'' реализует хранение геометрической модели среды, в которой моделируется поле. Каждая модель ассоциирована с экземпляром [[сцены|сцена]] - хранилищем объектов. Подсистема реализует функционал сцены и хранения экземпляров сцены. Доступ к экземпляру осуществляется клиентом по имени модельного проекта. Компонент частично реализован в проекте chsvgrphc, в виде DLL-библиотеки и в совокупности с предметно-независимой визуализацией сцены. '''Новое:''' Предполагается разделить существующую реализацию следующим образом: хранилище геометрической модели выделить в удаленный сервер, а визуализацию проводить целиком на стороне клиента, выполняя репликацию геометрической модели при возникновении изменений на сервере.
# [[Веб-сервер]] - служба, принимающая HTTP запросы от клиентов и трансформирующая их в вызов точки входа подсистемы управления с соответствующими параметрами.
# [[Подсистема управления]] - динамически загружаемая веб-сервером библиотека (DLL в Windows, SO в Unix), реализующая подсистему управления. Библиотека экспортирует заданный набор интерфейсных функций, доступных веб-серверу для обработки клиентских запросов. Также предоставляет интерфейс для подсистемы предметной области, который зависит от метода реализации подсистемы предметной области - в виде также внутрипроцессного сервера (единственная доступная реализация на 15.12.2015) или в виде удаленного сервера. Программно взаимодействие реализуется в виде пары "прокси-заглушка", предоставляющей полиморфные объекты с методами по передаче вызова.
# [[Вычислительная подсистема]] - чисто логическое объединение предметно-ориентированных подсистем, реализующих высокопроизводительное моделирование в своих предметных областях. На 15.12.2015 в виде разделяемых (динамических) библиотек реализованы две предметные области - "Архитектурная акустика" и "Интеграл".


* ''[[Банк данных с системой управления | Система управления базами данных]]'' Разделяемый доступ компонентов CAM к постоянным справочным данным, необходимым при расчетах должен предоставляться отдельной обслуживающей подсистемой – банком данных. Информационное наполнение банка составляют данные, необходимые для проведения каждого имитационного эксперимента, например сведения о типичных источниках поля, о физических свойствах среды распределения поля для заданного набора внешних условий, количественные сведения, характеризующие поведение поля на границах раздела сред. Поскольку информационное наполнение определяется предметной областью, в которой выполняется моделирование, для каждой предметной области создается собственная база данных. В настоящий момент реализован базовый функционал СУБД в виде локального COM-сервера (проекты amdb_inner и amdb_outer), с прокси и заглушкой (amdv_outer_inner, amdb_outer_proxy). Поэтому теоретически реализация должна работать корректно и для удаленного сервера. На 07.07.2015 реализация может портить данные при большом количестве элементов данных и параллельных клиентов. Реализация ориентирована на быструю обработку поступающих параллельно запросов, с высокой вероятностью того, что доступ будет ограничен чтением. Также существует написанный мной сырой клиент СУБД, брошенный во времена написания диссертации "посередине", поэтому пока он не выложен в репозиторий.
[[UC1: Произвести моделирование|Главный сценарий использования системы]] частично отражает назначение этих подсистем.


* ''[[Клиент доступа к системе моделирования]]'' Пользовательский клиент, через который осуществляется доступ к системе моделирования. Сегодня клиент фактически представляет из себя простое окошко с визуализацией 3D модели сцены и [[командной строкой | командная строка клиента]]. Предоставляет пользователю интерфейс для ввода параметров моделирования и анализа в систему: объекты, степень их аппроксимации, физические размеры, которым соответствует моделируемое пространство, параметры среды распространения моделируемого физического поля, а также положение секущих плоскостей, на которых рассчитываются распределения характеристик поля.
[[File:top-modules.jpg|500px|thumb|right|Типы модулей системы моделирования]]


* ''[[Подсистема управления]]'' Централизованное управление узлами распределенной CAM, а также политика безопасности в CAM должны реализовываться сервером безопасности и управления доступными вычислительными узлами, задачей которого является хранение и предоставление адресов всех узлов системы, а также гарантия их подлинности и их авторизация. При развертывании CAM узлы системы должны регистрироваться на сервере, при этом идентификатор, адрес и ключи аутентификации регистрируемого узла должны быть занесены во внутренние базы данных сервера согласно протоколам определенным разработчиком. При необходимости клиент сервера по идентификатору должен получать адрес запрашиваемого узла лишь в том случае, если подлинность последнего подтверждена. При этом сервер исключается из набора участников информационного обмена между авторизированными узлами, таким образом, на него не налагаются требования по защите передаваемой между его клиентами информации. Это, во-первых, снижает информационную нагрузку на сервер, во-вторых, снижает роль сервера как арбитра, что является причиной недостатков множества существующих систем и протоколов безопасности [57, 92]. Этой же либо выделенной отдельно подсистемой должно осуществляться распределение нагрузки между аутентифицированными подсистемами предметной области. При этом возможно использование следующего протокола. Для каждой отдельно взятой предметной области создается реестр адресов моделирующих подсистем, не занятых выполнением моделирования. Также для каждой предметной области подсистемой создается список задач по выполнению отдельного имитационного эксперимента. Во время проведения процедуры моделирования, если реестр адресов подсистем предметной области не пуст, параметры одного имитационного эксперимента из совокупности задач, которые необходимо выполнить для осуществления моделирования, передаются по одному из адресов из реестра. Если реестр пуст, параметры заносятся в список задач, выполнение которых осуществляется по мере освобождения подсистем предметной области. Подобные схемы управления нагрузкой в параллельных и распределенных системах имитационного моделирования являются предметом исследований в работах [25, 76], посвященных принципам PDES. В соответствующих терминах сервер осуществляет хранение списка событий, которыми являются сообщения о появлении задач по проведению имитационного эксперимента с заданными параметрами. В зависимости от требований к нагрузке на CAM и к стоимости развертывания системы сервер безопасности и подсистема управления доступными вычислительными узлами могут быть включены в одну из базовых подсистем. В этом случае такая подсистема назначается основной. Тогда остальные базовые подсистемы включаются в CAM через обращение к ней. ''Сегодня управления нет, центральной является система геометрического моделирования.''
===Реализации===
====Тестовая версия 2====
Реализует сценарии внутрипроцессной и распределенной работы компонентов системы, а также два тестовых клиента, включающих управляющую подсистему в собственное адресное пространство. Реализованы следующие компоненты.
* [[control]] - разделяемая библиотека, реализующая  [[Подсистема управления | управляющую подсистему]], и реализующая интерфейс, предоставляемый веб-серверу.
* [[lb_dll]] - разделяемая библиотека, реализующая балансировщики нагрузки с интерфейсом [[ILoadBalancer]], а также провайдер балансировщиков нагрузки [[ILoadBalancerProvider]]. Библиотека может быть включена в адресное пространство подсистемы управления при соответствующей конфигурации последней. Также библиотека может быть использована сторонним процессом, который реализует циклическое прослушивание удаленных каналов связи - см. [[lb_exe]].
* [[arch_ac]] - реализация подсистемы предметной области "Архитектурная акустика".
* cmd_client - клиент, который реализует интерфейс командной строки и подключается к подсистеме управления как внутрипроцессный сервер. Выполняет моделирование в предметной области "Архитектурная акустика", "Распространение радиоволн".
* [[domain_shared]] - разделяемая библиотека, которая опционально предоставляется реализациям подсистем предметных областей и их узлам. Библиотека реализует утилитарные функции, которые могут быть использованы на обеих сторонах - например функции по распаковке/запаковке объектов, реализации каналов связи между узлами. См. рисунок.
* [[domain_exe]] - реализует пользовательский интерфейс для распределенного экземпляра подсистемы предметной области - независимо от предметной области. См. ПОП на рисунке сверху.
* [[node_exe]] - реализует пользовательский интерфейс для распределенного узла подсистемы предметной области - независимо от предметной области. Аналогичен [[domain_shared]], но для узла.
* [[lb_exe]] - реализует пользовательский интерфейс для балансировщиков нагрузки и провайдера балансировщиков нагрузки, которые реализуются разделяемой библиотекой [[lb_dll]].
* [[radio_hf]] - реализация подсистемы предметной области "Распространение радиоволн".


* ''[[Предметно-ориентированная подсистема]]'' Включает в себя подсистемы предметной области, реализованные с участием эксперта предметной области. Также включает в себя параллельный вычислительный ресурс, регистрируемый в подсистеме управления.
[[File:DIS-DDS-border.png|500px|thumb|right|Структурные компоненты, реализующие процесс на стороне экземпляра подсистемы предметной области - в случае использования функций [[domain_shared]]. Для узла определяется аналогично.]]
 
''Следующие реализации устарели и сейчас не совместимы с предметно-независимой подсистемой.''
* [[integral]] - реализация подсистемы предметной области "Интеграл" по параллельному расчету интеграла <math>\int_{a}^{b}\frac{4}{1 + x^2}\, dx</math>. При <math>a = 0</math>, <math>b = 1</math> Результат должен быть равен <math>\pi</math>.
* integral_client - аналогичный клиент, инициирующий расчет интеграла в предметной области "Интеграл".
 
=====Сборка, развертывание и запуск=====
 
'''Сборка'''
 
:- ''Windows''. Для сборки в Windows требуется [https://www.visualstudio.com/ru/vs/older-downloads/ MS Visual Studio 2015]. Файл решения control.2015.sln в корне репозитория. Собирать нужно все кроме integral.2015 и integral_client.2015 - в среде проекты можно выгрузить. Выходная поддиректория в репозиторие, в зависимости от конфигурации сборки: <code inline>.\Debug\Win32\</code>, <code inline>.\Release\Win32\</code>, <code inline>.\Debug\x64\</code>, <code inline>.\Release\x64\</code>. Для сборки требуется также установить [https://www.freepascal.org/ Free Pascal] ([https://sourceforge.net/projects/freepascal/files/Win32/3.0.2/fpc-3.0.2.i386-win32.exe/download x86] и/или [https://sourceforge.net/projects/freepascal/files/Win32/3.0.2/fpc-3.0.2.i386-win32.cross.x86_64-win64.exe/download x64] в зависимости от конфигурации сборки). Поддиректорию <code inline>...\bin\i386-win32</code> (для обеих архитектур - одинаково), в директории с Free Pascal, также нужно прописать в переменной окружения <code inline>%FreePascalBin%</code>.
 
:- ''Linux''. Для сборки используется <code inline>[https://cmake.org/ cmake]</code>. Необходимо задать текущей поддиректорию <code inline>./build</code> в репозитории, создав ее при необходимости. Из-под директории <code inline>./build</code> выполнить <code inline>cmake ..</code>, затем выполнить построение и установку с помощью <code inline>make debug_x86 install</code>, <code inline>make debug_x64 install</code>, <code inline>make release_x86 install</code>, или <code inline>make release_x64 install</code> - в зависимости от конфигурации сборки. В версиях debug включается отладочная информация (-g), отключается оптимизация (-O0). В версиях release также включается отладочная информация, но используется оптимизация -O3. Выходная директория относительно корня репозитория: <code inline>./build/bin/</code>. Для сборки под Linux необходимо следующее стороннее ПО: <code inline>make</code>, <code inline>cmake</code>, <code inline>gcc</code> версии не ниже 5.3, <code inline>uuid-dev</code>, <code inline>fpc</code> (Free Pascal), и <code inline>libxerces-c-dev</code> (Apache Xerces-C++).
 
'''Развертывание'''
 
Конфигурация компонентов реализации управляется через набор файлов INI. Наиболее простой способ проверить работоспособность системы - использовать скрипт Powershell <code inline>win_deploy_base.ps1</code> под Windows или <code inline>bash_deploy_base.bash</code> в Linux следующим образом.
# <code inline>. .\win_deploy_base.ps1</code> или <code inline>. ./bash_deploy_base.bash</code>. Скрипты реализуют набор функций, которые необходимо загрузить в оболочку указанными командами из терминала. Сделать можно из любой поддиректории репозитория.
# Для внутрипроцессной конфигурации выполнить <code inline>Deploy-DefaultInprocessConfig</code>. Для распределенной конфигурации выполнить <code inline>Deploy-DefaultTcpConfig</code>. В распределенной конфигурации компоненты системы устанавливаются на текущей машине, а доступ к ним осуществляется по адресу 127.0.0.1. Используется экземпляр подсистемы предметной области <code inline>arch_ac</code> с одним узлом.
# В Windows после <code inline>Deploy-DefaultTcpConfig</code> желательно добавить необходимые исключения в брандмауэр Windows, выполнив с административными привилегиями Powershell скрипт <code inline>add_windows_firewall_exceptions.ps1</code>.
 
'''Запуск'''
 
Запуск осуществляется из-под директории с исходным кодом соответствующего компонента.
 
''Ниже предполагается использование сборки Release и x64.''
* Для запуска <code inline>arch_ac_client</code> (в обеих конфигурациях) необходимо из-под директории <code inline>arch_ac_client</code> репозитория выполнить следующее.
** ''В Windows'': <code inline>..\Release\x64\arch_ac_client опциональная_xml_модель опциональная_схема_xsd</code>. Файлы XML и XSD задают модель среды. Они опциональны - по умолчанию используются имена <code inline>upload_model_test.xml</code> и <code inline>upload_model_test.xsd</code> из текущей директории (arch_ac_client).
** ''В Linux'': <code inline>../build/bin/arch_ac_client опциональная_xml_модель опциональная_схема_xsd</code>. Файлы XML и XSD используются аналогично.
* Для запуска распределенного балансировщика нагрузки <code inline>lb_exe</code> необходимо из-под директории <code inline>lb_exe</code> репозитория выполнить следующее.
** ''В Windows'': <code inline>..\Release\x64\lb --config=load_balancer_provider.ini</code>
** ''В Linux'': <code inline>../build/bin/lb_exe --config=load_balancer_provider.ini</code>
* Для запуска распределенной подсистемы предметной области <code inline>domain_exe</code> и загрузки <code inline>arch_ac</code> необходимо из-под директории <code inline>domain_exe</code> репозитория выполнить следующее.
** ''В Windows'': <code inline>..\Release\x64\domain_server --domain_library=arch_ac.dll</code>
** ''В Linux'': <code inline>../build/bin/domain_server --domain_library=libarch_ac.so</code>
* Для запуска распределенного узла <code inline>node_exe</code> подсистемы предметной области и загрузки <code inline>arch_ac</code> необходимо из-под директории <code inline>node_exe</code> репозитория выполнить следующее.
** ''В Windows'': <code inline>..\Release\x64\node_exe --node_library=arch_ac.dll</code>
** ''В Linux'': <code inline>../build/bin/node_server --node_library=libarch_ac.so</code>
 
'''В распределенной конфигурации клиент <code inline>arch_ac_client</code> нужно запускать в <u>последнюю очередь</u>!
 
В качестве входной модели можно использовать следующий файл.
 
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<model cx = "30" cy = "20" cz = "5" name = "Средний зал">
<domain name = "arch_ac">
<attenuation>1</attenuation>
</domain>
<polyobject name = "Стена 1 Левая">
<face>
  <vertex x = "0" y = "0" z = "0"/>
  <vertex x = "0" y = "5" z = "0"/>
  <vertex x = "0" y = "5" z = "5"/>
  <vertex x = "0" y = "0" z = "5"/>
  <domain name = "arch_ac">
<absorption> <!--Фанера на стилите-->
  <absorption_row frequency = "125">0.47</absorption_row>
  <absorption_row frequency = "250">0.39</absorption_row>
  <absorption_row frequency = "500">0.18</absorption_row>
  <absorption_row frequency = "1000">0.14</absorption_row>
  <absorption_row frequency = "2000">0.13</absorption_row>
  <absorption_row frequency = "4000">0.12</absorption_row>
</absorption>
  </domain>
</face>
</polyobject>
<sourceobject name = "Источник 1">
<position x = "2.5" y = "2.5" z = "2.5"/>
<direction x = "-1" y = "0" z = "0"/>
<top x = "0" y = "0" z = "1"/>
<domain name = "arch_ac">
  <rp>
<function>F(freq, theta, phi) = (1 + cos(theta)) * 0.5 * 0.01</function> <!--Кардиоида-->
<!--<function>F(freq, theta, phi) = 1</function>--> <!--Круговая-->
  </rp>
  <afc>
<afc_row frequency = "125">0.018456914</afc_row>
<afc_row frequency = "250">0.015403295</afc_row>
<afc_row frequency = "500">0.018799808</afc_row>
<afc_row frequency = "1000">0.010629603</afc_row>
<afc_row frequency = "2000">0.004951132</afc_row>
<afc_row frequency = "4000">0.004816578</afc_row>
  </afc>
</domain>
</sourceobject>
<plainobject>
<position x = "0" y = "0" z = "1.2"/>
<v1 x = "1" y = "0" z = "0"/>
<v2 x = "0" y = "1" z = "0"/>
</plainobject>
</model>
</source>
 
Другие файлы можно получить в частном порядке.
 
====Тестовая версия 1====
Реализует только сценарий внутрипроцессной работы компонентов системы, за исключением браузера, а также два тестовых клиента, включающих управляющую подсистему в собственное адресное пространство. Реализованы следующие компоненты.
* [[control]] - библиотека, реализующая  [[Подсистема управления | управляющую подсистему]], и реализующая интерфейс, предоставляемый веб-серверу.
* [[arch_ac]] - реализация моделирующей подсистемы предметной области "Архитектурная акустика".
* arch_ac_client - исполняемый компонент, играющий роль заглушки "пользователь-веб-сервер". Выполняет моделирование в предметной области "Архитектурная акустика".
* [[integral]] - реализация подсистемы предметной области "Интеграл" по параллельному расчету интеграла <math>\int_{a}^{b}\frac{4}{1 + x^2}\, dx</math>. При <math>a = 0</math>, <math>b = 1</math> Результат должен быть равен <math>\pi</math>.
* integral_client - аналогичный клиент, инициирующий расчет интеграла в предметной области "Интеграл".
 
[[Файл:Ver1-top.jpg|500px|thumb|right|Исполняемые модули на 15.12.2015]]
 
==См. также==
 
[[Старая версия архитектуры системы]]

Текущая версия на 17:53, 5 декабря 2018

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

Верхнеуровневая архитектура

Структура

На верхнем уровне системной иерархии система принципиально состоит из предметно-независимой и предметно-ориентированной подсистемы.

Предметно-независимая подсистемы разрабатывается нами без какой-либо привязки к предметной области проведения модельных экспериментов.

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

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

Структурно, верхний уровень определяется следующими компонентами.

  1. Веб-сервер - служба, принимающая HTTP запросы от клиентов и трансформирующая их в вызов точки входа подсистемы управления с соответствующими параметрами.
  2. Подсистема управления - динамически загружаемая веб-сервером библиотека (DLL в Windows, SO в Unix), реализующая подсистему управления. Библиотека экспортирует заданный набор интерфейсных функций, доступных веб-серверу для обработки клиентских запросов. Также предоставляет интерфейс для подсистемы предметной области, который зависит от метода реализации подсистемы предметной области - в виде также внутрипроцессного сервера (единственная доступная реализация на 15.12.2015) или в виде удаленного сервера. Программно взаимодействие реализуется в виде пары "прокси-заглушка", предоставляющей полиморфные объекты с методами по передаче вызова.
  3. Вычислительная подсистема - чисто логическое объединение предметно-ориентированных подсистем, реализующих высокопроизводительное моделирование в своих предметных областях. На 15.12.2015 в виде разделяемых (динамических) библиотек реализованы две предметные области - "Архитектурная акустика" и "Интеграл".

Главный сценарий использования системы частично отражает назначение этих подсистем.

Типы модулей системы моделирования

Реализации

Тестовая версия 2

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

  • control - разделяемая библиотека, реализующая управляющую подсистему, и реализующая интерфейс, предоставляемый веб-серверу.
  • lb_dll - разделяемая библиотека, реализующая балансировщики нагрузки с интерфейсом ILoadBalancer, а также провайдер балансировщиков нагрузки ILoadBalancerProvider. Библиотека может быть включена в адресное пространство подсистемы управления при соответствующей конфигурации последней. Также библиотека может быть использована сторонним процессом, который реализует циклическое прослушивание удаленных каналов связи - см. lb_exe.
  • arch_ac - реализация подсистемы предметной области "Архитектурная акустика".
  • cmd_client - клиент, который реализует интерфейс командной строки и подключается к подсистеме управления как внутрипроцессный сервер. Выполняет моделирование в предметной области "Архитектурная акустика", "Распространение радиоволн".
  • domain_shared - разделяемая библиотека, которая опционально предоставляется реализациям подсистем предметных областей и их узлам. Библиотека реализует утилитарные функции, которые могут быть использованы на обеих сторонах - например функции по распаковке/запаковке объектов, реализации каналов связи между узлами. См. рисунок.
  • domain_exe - реализует пользовательский интерфейс для распределенного экземпляра подсистемы предметной области - независимо от предметной области. См. ПОП на рисунке сверху.
  • node_exe - реализует пользовательский интерфейс для распределенного узла подсистемы предметной области - независимо от предметной области. Аналогичен domain_shared, но для узла.
  • lb_exe - реализует пользовательский интерфейс для балансировщиков нагрузки и провайдера балансировщиков нагрузки, которые реализуются разделяемой библиотекой lb_dll.
  • radio_hf - реализация подсистемы предметной области "Распространение радиоволн".
Структурные компоненты, реализующие процесс на стороне экземпляра подсистемы предметной области - в случае использования функций domain_shared. Для узла определяется аналогично.

Следующие реализации устарели и сейчас не совместимы с предметно-независимой подсистемой.

  • integral - реализация подсистемы предметной области "Интеграл" по параллельному расчету интеграла . При , Результат должен быть равен .
  • integral_client - аналогичный клиент, инициирующий расчет интеграла в предметной области "Интеграл".
Сборка, развертывание и запуск

Сборка

- Windows. Для сборки в Windows требуется MS Visual Studio 2015. Файл решения control.2015.sln в корне репозитория. Собирать нужно все кроме integral.2015 и integral_client.2015 - в среде проекты можно выгрузить. Выходная поддиректория в репозиторие, в зависимости от конфигурации сборки: .\Debug\Win32\, .\Release\Win32\, .\Debug\x64\, .\Release\x64\. Для сборки требуется также установить Free Pascal (x86 и/или x64 в зависимости от конфигурации сборки). Поддиректорию ...\bin\i386-win32 (для обеих архитектур - одинаково), в директории с Free Pascal, также нужно прописать в переменной окружения %FreePascalBin%.
- Linux. Для сборки используется cmake. Необходимо задать текущей поддиректорию ./build в репозитории, создав ее при необходимости. Из-под директории ./build выполнить cmake .., затем выполнить построение и установку с помощью make debug_x86 install, make debug_x64 install, make release_x86 install, или make release_x64 install - в зависимости от конфигурации сборки. В версиях debug включается отладочная информация (-g), отключается оптимизация (-O0). В версиях release также включается отладочная информация, но используется оптимизация -O3. Выходная директория относительно корня репозитория: ./build/bin/. Для сборки под Linux необходимо следующее стороннее ПО: make, cmake, gcc версии не ниже 5.3, uuid-dev, fpc (Free Pascal), и libxerces-c-dev (Apache Xerces-C++).

Развертывание

Конфигурация компонентов реализации управляется через набор файлов INI. Наиболее простой способ проверить работоспособность системы - использовать скрипт Powershell win_deploy_base.ps1 под Windows или bash_deploy_base.bash в Linux следующим образом.

  1. . .\win_deploy_base.ps1 или . ./bash_deploy_base.bash. Скрипты реализуют набор функций, которые необходимо загрузить в оболочку указанными командами из терминала. Сделать можно из любой поддиректории репозитория.
  2. Для внутрипроцессной конфигурации выполнить Deploy-DefaultInprocessConfig. Для распределенной конфигурации выполнить Deploy-DefaultTcpConfig. В распределенной конфигурации компоненты системы устанавливаются на текущей машине, а доступ к ним осуществляется по адресу 127.0.0.1. Используется экземпляр подсистемы предметной области arch_ac с одним узлом.
  3. В Windows после Deploy-DefaultTcpConfig желательно добавить необходимые исключения в брандмауэр Windows, выполнив с административными привилегиями Powershell скрипт add_windows_firewall_exceptions.ps1.

Запуск

Запуск осуществляется из-под директории с исходным кодом соответствующего компонента.

Ниже предполагается использование сборки Release и x64.

  • Для запуска arch_ac_client (в обеих конфигурациях) необходимо из-под директории arch_ac_client репозитория выполнить следующее.
    • В Windows: ..\Release\x64\arch_ac_client опциональная_xml_модель опциональная_схема_xsd. Файлы XML и XSD задают модель среды. Они опциональны - по умолчанию используются имена upload_model_test.xml и upload_model_test.xsd из текущей директории (arch_ac_client).
    • В Linux: ../build/bin/arch_ac_client опциональная_xml_модель опциональная_схема_xsd. Файлы XML и XSD используются аналогично.
  • Для запуска распределенного балансировщика нагрузки lb_exe необходимо из-под директории lb_exe репозитория выполнить следующее.
    • В Windows: ..\Release\x64\lb --config=load_balancer_provider.ini
    • В Linux: ../build/bin/lb_exe --config=load_balancer_provider.ini
  • Для запуска распределенной подсистемы предметной области domain_exe и загрузки arch_ac необходимо из-под директории domain_exe репозитория выполнить следующее.
    • В Windows: ..\Release\x64\domain_server --domain_library=arch_ac.dll
    • В Linux: ../build/bin/domain_server --domain_library=libarch_ac.so
  • Для запуска распределенного узла node_exe подсистемы предметной области и загрузки arch_ac необходимо из-под директории node_exe репозитория выполнить следующее.
    • В Windows: ..\Release\x64\node_exe --node_library=arch_ac.dll
    • В Linux: ../build/bin/node_server --node_library=libarch_ac.so

В распределенной конфигурации клиент arch_ac_client нужно запускать в последнюю очередь!

В качестве входной модели можно использовать следующий файл.

<?xml version="1.0" encoding="utf-8"?>
<model cx = "30" cy = "20" cz = "5" name = "Средний зал">
	<domain name = "arch_ac">
		<attenuation>1</attenuation>
	</domain>
	<polyobject name = "Стена 1 Левая">
		<face>
		  <vertex x = "0" y = "0" z = "0"/>
		  <vertex x = "0" y = "5" z = "0"/>
		  <vertex x = "0" y = "5" z = "5"/>
		  <vertex x = "0" y = "0" z = "5"/>
		  <domain name = "arch_ac">
			<absorption> <!--Фанера на стилите-->
			  <absorption_row frequency = "125">0.47</absorption_row>
			  <absorption_row frequency = "250">0.39</absorption_row>
			  <absorption_row frequency = "500">0.18</absorption_row>
			  <absorption_row frequency = "1000">0.14</absorption_row>
			  <absorption_row frequency = "2000">0.13</absorption_row>
			  <absorption_row frequency = "4000">0.12</absorption_row>
			</absorption>
		  </domain>
		</face>
	</polyobject>
	<sourceobject name = "Источник 1">
		<position x = "2.5" y = "2.5" z = "2.5"/>
		<direction x = "-1" y = "0" z = "0"/>
		<top x = "0" y = "0" z = "1"/>
		<domain name = "arch_ac">
		  <rp>
			<function>F(freq, theta, phi) = (1 + cos(theta)) * 0.5 * 0.01</function> <!--Кардиоида-->
			<!--<function>F(freq, theta, phi) = 1</function>--> <!--Круговая-->
		  </rp>
		  <afc>
			<afc_row frequency = "125">0.018456914</afc_row>
			<afc_row frequency = "250">0.015403295</afc_row>
			<afc_row frequency = "500">0.018799808</afc_row>
			<afc_row frequency = "1000">0.010629603</afc_row>
			<afc_row frequency = "2000">0.004951132</afc_row>
			<afc_row frequency = "4000">0.004816578</afc_row>
		  </afc>
		</domain>
	</sourceobject>
	<plainobject>
		<position x = "0" y = "0" z = "1.2"/>
		<v1 x = "1" y = "0" z = "0"/>
		<v2 x = "0" y = "1" z = "0"/>
	</plainobject>
</model>

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

Тестовая версия 1

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

  • control - библиотека, реализующая управляющую подсистему, и реализующая интерфейс, предоставляемый веб-серверу.
  • arch_ac - реализация моделирующей подсистемы предметной области "Архитектурная акустика".
  • arch_ac_client - исполняемый компонент, играющий роль заглушки "пользователь-веб-сервер". Выполняет моделирование в предметной области "Архитектурная акустика".
  • integral - реализация подсистемы предметной области "Интеграл" по параллельному расчету интеграла . При , Результат должен быть равен .
  • integral_client - аналогичный клиент, инициирующий расчет интеграла в предметной области "Интеграл".
Исполняемые модули на 15.12.2015

См. также

Старая версия архитектуры системы