CC BY
79
УДК 004.75 Дата подачи статьи: 15.03.16
DOI: 10.15827/0236-235X.114.034-040
ГИБРИДНАЯ НАСТОЛЬНО-ОБЛАЧНАЯ ПЛАТФОРМА ДЛЯ ИССЛЕДОВАНИЯ ПРОСТРАНСТВА ПАРАМЕТРОВ
(Работа выполнена при финансовой поддержке РФФИ в рамках научного проекта № 15-29-07043)
А.А. Прохоров, начальник отдела, alexander.prokhorov@datadvance.net; А.М. Назаренко, старший программист, alexey.nazarenko@datadvance.net; Н.О. Пересторонин, старший программист, nikitaperestoronin@datadvance.net; А.В. Давыдов, технический писатель, andrey.davydov@datadvance.net (Компания «ДАТАДВАНС», Научный проезд, 17, г. Москва, 11 7246, Россия)
В современной инженерной практике подход к выработке решений с использованием расчетных моделей и мета-моделей считается наиболее перспективным и выгодным с точки зрения сокращения сроков и стоимости разработки. Однако его применение сопряжено с рядом методологических и эксплуатационных проблем, вследствие чего данная практика не получает широкого распространения, оставаясь недоступной для небольших коллективов, которые часто не располагают необходимыми ресурсами. Для данного метода характерен высокий порог вхождения, обусловленный высокой сложностью и стоимостью реализации расчетных моделей, которая связана с многодисциплинарным характером современных инженерных задач. Разработка таких моделей требует как широкого спектра знаний в различных областях, так и использования различного специализированного ПО, как правило, доступного только на коммерческой основе. Помимо этого, для проведения крупномасштабных автоматизированных вычислений необходимо наличие специального высокопроизводительного программно-аппаратного комплекса, что влечет дополнительные издержки на его создание и обслуживание.
В статье рассматриваются основные вопросы применения крупномасштабных автоматизированных вычислений, необходимость в которых возникает при использовании вычислительных методов на этапе выработки инженерных решений в отличие от распространенной в настоящее время практики, когда вычислительное моделирование проводится уже на этапе валидации предполагаемых решений и не требует многократных вычислительных экспериментов. В качестве способов снижения порога вхождения обсуждаемого метода рассматриваются существующая практика создания интегрированных приложений, доступных широкому кругу пользователей, и применение облачных вычислений, что позволяет сократить накладные расходы на моделирование. Отдельное внимание уделено использованию программных средств с поддержкой облачных вычислений совместно с традиционными настольными приложениями. Сформулированы соответствующие требования к системе управления автоматизированными расчетами, поддерживающей интеграцию как с облачным, так и с настольным ПО, что делает возможным создание гибридных интегрированных приложений для решения классов сходных задач. Предложена архитектура такой системы, разработанная с учетом приведенных требований и позволяющая использовать основные компоненты системы как в облачной, так и в настольной версии с целью минимизации усилий по ее разработке.
Ключевые слова: автоматизация инженерных расчетов, облачные вычисления, интеграция, управление расчетами.
Значимость подхода к выработке инженерных решений с использованием расчетных моделей [1-3] в настоящее время достаточно очевидна: вследствие того, что скорость устаревания конструкторских решений на протяжении последних десятилетий постоянно растет, большинство производящих компаний ставят целью сокращение срока выхода изделий на рынок, а данный подход можно рассматривать как наиболее перспективный с точки зрения сокращения сроков и стоимости разработки, что подтверждается недавним анализом трендов в САО-приложениях [4], где расчетное моделирование занимает второе место. Однако доля инженеров, использующих данный подход на практике, оценивается не более чем в 5 % от общего мирового количества пользователей соответствующего ПО [5]. Моделирование по-прежнему используется в основном на этапе валидации решений, а не для исследования пространства проектных параметров, и гораздо реже применяется для выработки и отбора решений на раннем этапе проектирования. Более того, упомянутые 5 % пользователей в основном
являются сотрудниками крупных компаний, вследствие чего применение данного подхода ограничивается не только малым количеством пользователей, но и относительно малым количеством использующих его компаний.
По мнению авторов, главными предпосылками этого ограничения являются два фактора: высокая стоимость применения данного подхода и высокий порог вхождения для пользователей. Первый фактор учитывает издержки создания и обслуживания высокопроизводительного программно-аппаратного комплекса, необходимого для широкого применения моделирования в инженерных задачах. Крупномасштабные исследования требуют значительных вычислительных ресурсов наряду со специальным ПО. Для малых и средних компаний уровень окупаемости данного подхода может быть практически недостижим, учитывая стоимость лицензий на коммерческое ПО, стоимость владения высокопроизводительным расчетным комплексом и неравномерное распределение расчетной нагрузки, вследствие которого эффективность снижается
еще больше из-за возникновения простоев. Второй фактор является естественным следствием многодисциплинарного характера современных инженерных задач, требующих широкого спектра знаний в различных областях и достаточно глубокого их понимания. В крупных компаниях, интенсивно применяющих методы моделирования, часто существуют специальные группы или отделы, разрабатывающие приложения специального назначения, использование которых было бы доступно большому количеству сотрудников, работающих уже над конкретными задачами. Для многих малых компаний такое разделение рабочих процессов невозможно из-за отсутствия специалистов необходимого уровня, то есть они неспособны преодолеть порог вхождения. Ситуация, когда большинство сотрудников компании способны успешно работать над решением многодисциплинарных проблем, на практике настолько редкая, что авторы исключили ее из дальнейшего рассмотрения: наиболее близким к реальности видится подход, основанный на разделении ролей пользователей аналогично тому, как это происходит в крупнейших компаниях.
В данной работе рассматриваются способы обхода вышеупомянутых проблем, являющиеся предпосылками решения, которое может расширить область применимости методов моделирования в современных инженерных задачах.
Вертикально интегрированные приложения
Под вертикально интегрированным приложением понимается сравнительно узкоспециализированное программное решение, реализующее некий конкретный подход к решению задачи [6]. Типичный пример - приложение, интегрирующее ряд CAD- и CAE-пакетов общего назначения, которое позволяет пользователю контролировать некоторые параметры изделия (геометрические, нагрузочные) и автоматически рассчитывает интересующие его характеристики (например, распределение нагрузки). Такое приложение разрабатывается на основе массы специальных знаний, однако пользователю оно предоставляет простой интерфейс для работы с комплексной моделью изделия, скрывая от него сложности реализации. Сравнительно узкая область применения и вытекающая отсюда простота интерфейса позволяют его использование даже неспециалистами, а возможности применения определяются степенью параметризации задачи, заложенной разработчиками приложения. В той или иной форме данный подход используется при решении многих реальных задач, обеспечивая возможность неявного обмена опытом и знаниями между участниками процесса.
Существуют различные подходы к созданию вертикально интегрированных приложений: от разработки специализированных приложений с нуля с
помощью распространенных языков программирования общего назначения до использования существующих специальных сред [7]. Последние предназначены для упрощения процесса разработки приложения, что достигается за счет некоторого набора готовых интегрируемых компонентов, которые могут быть дополнительно настроены и объединены друг с другом - для этого пользователю обычно предоставляется графический интерфейс. В действительности наличие подобной платформы является необходимым условием для создания вертикально интегрированных приложений, в противном случае их реализация требует написания массы программных сценариев, поддержка и расширение которых приводят к дополнительным сложностям.
При этом даже высокоразвитые возможности интеграции сами по себе не являются достаточной базой для принятия решений: интегрированное приложение должно обеспечивать возможность его автоматизированного исследования и анализа, а не только валидации существующих решений. Поэтому наряду с набором компонентов интеграции платформа для разработки таких приложений должна предоставлять инструменты сбора и анализа данных, и сочетание данных требований в итоге является основополагающим для любой платформы исследования пространства параметров.
Облачные приложения
Приложения, использующие облачные вычисления, являются одним из ключевых направлений развития современных CAE-систем. Без преувеличения можно сказать, что сегодня мы наблюдаем зарождение экосистемы специализированных облачных приложений для решения инженерных задач, частью которой являются такие пакеты, как Onshape, pSeven [8], SimScale и SimForDesign. Важно, что упомянутые приложения соответствуют основным принципам модели облачных вычислений [9]. В частности, они реализуют концепции предоставления ресурсов по требованию и легкой масштабируемости и за счет своей гибкости обеспечивают возможности по снижению стоимости использования.
Существующие облачные приложения уже развивают открытые API (это довольно естественно для сетевых сервисов), что делает возможным их прямую интеграцию. Вертикально интегрированные облачные приложения способны стать решением двух основных проблем, препятствующих широкому распространению обсуждаемого подхода. Однако в развивающейся облачной экосистеме пока еще отсутствует тот элемент, который необходим для массового создания и использования вертикально интегрированных приложений. Как отмечалось выше, эффективная разработка таких приложений требует наличия платформы для
исследования пространства параметров - облачного аналога таких настольных систем, как Isight или modeFRONTIER (характерные свойства такого рода систем подробно описаны в [10]). В настоящее время не существует интеграционной платформы, разработанной специально с учетом применимости облачных вычислений и позволяющей создавать интегрированные приложения, полностью основанные на облачных технологиях.
Требования к интеграционной платформе
Перечислим основные требования к облачной платформе для исследования пространства параметров, способной решить проблемы, ограничивающие распространение данного подхода в решении многодисциплинарных инженерных задач.
1. Поддержка интеграции облачных приложений, очевидно, являющаяся одним из ключевых требований.
2. Поддержка интеграции настольных приложений и возможность разработки гибридных интегрированных приложений. Это необходимо, по крайней мере, по двум причинам: во-первых, облачные приложения в обозримом будущем все же не смогут полностью вытеснить основные настольные СЛВ-системы, во-вторых, как правило, требуется интеграция с ПО, разработанным внутри компании, которое по техническим или иным причинам (например, из соображений безопасности) не может быть переведено на модель облачных вычислений. Таким образом, многие интегрированные решения будут частично основаны на настольных приложениях.
3. Наличие собственных средств исследования пространства параметров, в частности, оптимизационных алгоритмов и средств анализа данных.
4. Возможность конвертировать сложное интегрированное решение в простое для применения приложения, которое может быть использовано неспециалистами для решения некоего класса инженерных задач (создание вертикально интегрированных приложений).
5. Поддержка модели развертывания в частном облаке, необходимая для того, чтобы компании, обладающие собственными возможностями для применения моделирования, могли на данной платформе разрабатывать собственные приложения для внутреннего использования.
6. Поддержка развертывания в публичном облаке. Полностью основанное на облачных технологиях решение позволит создавать интегрированные приложения, широко доступные как сервисы. Для этого необходимо, чтобы реализация как интегрируемых СЛВ/САБ-систем, так и самой интеграционной платформы была полностью основана на облачных технологиях. В такой модели публичные облачные сервисы могут быть использованы ком-
паниями, не обладающими необходимыми собственными ресурсами, за счет чего достигается снижение порога вхождения.
По мнению авторов, применение облачных вычислений в конечном счете значительно упростит совместную работу над проектами, обмен данными, использование таких ресурсоемких методов, как многокритериальная оптимизация и другие методы коллаборативной оптимизации [11], а возможности облачной интеграционной платформы, отвечающей вышеперечисленным требованиям, будут расширяться по мере развития облачных приложений.
Архитектура интеграционной платформы
Рассмотрим определенные базовые требования к интеграционной платформе с точки зрения разработки соответствующей архитектуры приложения. Можно выделить несколько свойств системы, которые необходимо принять во внимание на этапе разработки архитектуры.
1. Реализуемость ряда вариантов развертывания и использования системы, среди которых развертывание в качестве
- чисто настольного приложения (без сетевого взаимодействия);
- настольного приложения, поддерживающего выполнение задач на ресурсах локальной сети;
- настольного приложения, поддерживающего выполнение задач на ресурсах локальной сети, но с выполнением задач на ресурсах вне прямой сетевой видимости;
- чисто облачного приложения;
- облачного приложения с возможностью выполнения задач на локальном ПК пользователя.
2. Непосредственно из п. 1 вытекает необходимость разработки такой декомпозиции, которая позволила бы минимизировать количество кода за счет максимизации его повторного использования, то есть использования одинаковых универсальных компонентов и в настольной, и в облачной версии -там, где это возможно.
3. Сложность установки настольной версии должна быть низкой, то есть соответствовать уровню, характерному для настольных приложений. Кроме того, настольная версия должна быть относительно нетребовательной к ресурсам.
4. Система должна позволять интегрировать в рамках одного расчета различные задачи (приложения), работающие под управлением различных операционных систем.
5. В целях безопасности необходимо обеспечить приемлемый уровень изоляции пользователей, а также задач одного пользователя.
6. Необходима поддержка совместной работы пользователей на уровне разработки расчетной схемы как при облачном, так и при настольном использовании.
Браузер
Графический интерфейс
Приложение
Сервер
Управление данными и расчетами
Расчетная схема
Составление схемы Задачи
Расчет
Выполнение схемы Задачи
Агент
Запуск задач
Рис. 1. Архитектура настольной версии интеграционной платформы Fig. 1. The architecture of an integrated platform desktop version
7. Система должна обеспечивать масштабируемость и возможности управления нагрузкой.
Рассмотрим архитектуру, учитывающую указанные необходимые свойства. В ее основе лежит клиент-серверная модель, предполагающая наличие легкой серверной части и клиентского графического интерфейса, реализованного с применением современных веб-технологий (JavaScript, HTML5). Пользователи облачной версии устанавливают соединение с сервером с помощью обычного веб-браузера, который загружает графический интерфейс клиента и представляет его пользователю как обычную веб-страницу. В облачной версии сервер использует виртуализацию на уровне операционной системы: расчет запускается в Docker-контей-нере, чтобы каждый пользователь работал со своим изолированным экземпляром среды. В таком случае на стороне пользователя не требуется установка каких-либо программ, за исключением любого современного веб-браузера. Настольная версия работает в рамках той же модели: прозрачным для пользователя образом она запускает локальный сервер и открывает графический интерфейс во встроенном браузере, который автоматически устанавливает соединение с локальным сервером. Установка настольной версии, таким образом, не требует наличия браузера или какой-либо дополнительной настройки серверной части.
Сначала более подробно рассмотрим архитектуру настольной версии (рис. 1). Ее основные процессы: браузер (клиентская часть), сервер и процесс-агент. Браузер предоставляет пользователю графический интерфейс. При этом он не запрещает доступ к локальной файловой системе и не требует соблюдения принципа одного источника, но исключает переход на другие страницы, в результате создавая у пользователя впечатление работы с настольным ПО. Сервер - это однопользовательский НТТР-сервер, управляющий логикой составления и исполнения расчетных схем, но не работающий напрямую с графической подсистемой. Данные расчетов хранятся в проекте - директории в локальной файловой системе. Единовременно сервер обслуживает один проект; для обеспечения совместной работы пользователей над проектом должен быть предусмотрен не зависящий от файловой системы механизм блокировки файлов. Во время исполнения расчета сервер обеспечивает изоляцию задач на уровне процессов. Запуском задач управляет процесс-агент, который может запустить локальную задачу по указанию как локального сервера, так и сервера, размещенного на удаленном узле.
Наличие агента обеспечивает варианты использования настольной версии, показанные на рисунке 2: выполнение отдельных задач на ресурсах ло-
Рис. 2. Варианты использования настольной версии интеграционной платформы Fig. 2. The ways of using an integrated platform desktop version
Подконтрольные ресурсы
Рис. 3. Архитектура облачной версии интеграционной платформы Fig. 3. The architecture of an integrated platform cloud version
кальной сети (слева) и выполнение задач на узле вне прямой сетевой видимости (справа). Первый вариант также позволяет вести совместную работу с использованием настольных версий приложения за счет общего доступа к директории проекта.
В архитектуре облачной версии системы (рис. 3) следует выделить портал (точку входа), БД, менеджер заданий и два типа ресурсов: подконтрольные и неподконтрольные системе.
Портал является классическим веб-приложением, поддерживающим авторизацию и профили пользователей. Портал предоставляет пользователю список проектов и обеспечивает разграничение прав доступа пользователей к проектам для совместной работы. БД портала - SQL БД, хранящая профили пользователей. БД проектов - сетевая файловая система, подключенная к серверным контейнерам, что обеспечивает совместную работу многих пользователей над одним проектом и позволяет использовать тот же механизм блокировки, что и в настольной версии. Реализация БД проектов на основе сетевой файловой системы также делает возможным простое централизованное управление правами доступа к проектам путем задания прав доступа пользователей к файлам.
В облачной версии серверный компонент и агент запускаются в контейнерах, обеспечивающих изоляцию на уровне операционной системы. Использование контейнеров позволяет объединять расчетные средства, работающие под управлением разных операционных систем, в рамках одной расчетной схемы, а также дает возможность гибкого масштабирования путем подключения и отключения ресурсов. К подконтрольным системе ресур-
сам, таким образом, относятся сами контейнеры, система управления ими и реестр образов, развертываемых на контейнерах. Образ для развертывания в контейнере включает в себя серверную часть платформы, интегрируемое приложение (если оно используется задачей) и т.д.
Задачи из расчетной схемы (например, интегрированные настольные приложения) могут запускаться и на ресурсах пользователя, неподконтрольных системе. Как говорилось выше, такие задачи часто присутствуют в интеграционной схеме, поскольку не все ПО доступно в рамках чисто облачной модели вычислений. Гибридные облачно-настольные расчетные схемы, таким образом, будут включать в себя задачи, использующие неподконтрольные системе ресурсы и запускаемые под управлением процесса-агента.
Управление заданиями и подконтрольными ресурсами осуществляет менеджер заданий. Этот же компонент обеспечивает НТТР-маршрутизацию для представления пользователю портала графического интерфейса редактирования расчетных схем, которым управляет серверный компонент. Кроме того, менеджер заданий обеспечивает связь между серверным компонентом и процессом-агентом внутри подконтрольной инфраструктуры, а также между серверным компонентом и агентом на внешнем пользовательском ресурсе.
Вышеописанная архитектура облачной версии делает возможным ряд существенно различных вариантов использования (рис. 4):
- поддержка возможности запуска отдельных задач на ресурсах пользователя, находящихся под его контролем, но вне локальной сети, в случае ра-
боты пользователя с настольной версией приложения (см. также рис. 2, справа);
- полностью облачное использование: пользователь взаимодействует с системой только через его собственный веб-браузер, все расчеты проводятся с использованием только облачных ресурсов;
- гибридные схемы: настольная версия запускает расчетные задачи в облаке, используя контейнеры на ресурсах, принадлежащих облачной инфраструктуре; облачная версия выполняет задачи на локальном ресурсе пользователя.
Пользовательский ПК
Веб-браузер
Облачная версия
Пользовательский ПК
Портал
Задача
Агент
БД проектов
Агент
Пользовательский ПК
Настольная версия
Контейнеры
Рис. 4. Варианты использования облачной версии интеграционной платформы
Fig. 4. The ways of using an integrated platform cloud
Облачная версия платформы максимально использует компоненты, входящие в состав настольной версии. При этом за счет использования контейнеров она обеспечивает необходимый уровень изоляции пользователей и задач, поддерживает управление нагрузкой и масштабируемое потребление вычислительных ресурсов.
Несмотря на значимость расчетного моделирования в инженерных задачах, распространение подхода к выработке решений с его использованием в настоящее время ограничено. Причинами этого являются высокая стоимость и сложность программно-аппаратных комплексов, необходимых для решения многодисциплинарных задач. Данные проблемы могут быть решены за счет создания облачной вычислительной среды, которая позволила бы подготавливать, публиковать и использовать готовые расчетные схемы. Основой такой среды могут стать начинающие появляться облачные САЭ-и САЕ-системы, однако к настоящему времени еще не разработана платформа для интеграции таких
облачных приложений. К данной платформе, помимо интеграционных требований, предъявляются дополнительные требования, связанные с поддержкой принятия решений в инженерных задачах.
В настоящей работе представлен список этих требований и предложена архитектура приложения (интеграционной платформы), обеспечивающая наличие ряда необходимых свойств, таких как поддержка различных вариантов развертывания (настольное, облачное, гибридное), поддержка совместной работы пользователей при различных вариантах развертывания системы, масштабируемость и возможность управления нагрузкой, поддержка интеграции приложений, работающих под управлением различных операционных систем.
Критерием оптимальности при разработке данной архитектуры была минимизация количества кода (количества компонентов) за счет создания универсальных компонентов, которые могут быть использованы в различных версиях системы. Следует также отметить, что представленное решение во многом основано на практическом опыте разработки интеграционной платформы pSeven [12] в компании DATADVANCE в 2012-2016 гг.
Литература
1. Jenkins B. Anatomy of design space exploration. Ora Research, 2014. URL: http://oraresearch.com/2014/12/anatomy-of-design-space-exploration/ (дата обращения: 29.02.2016).
2. Jenkins B. From PIDO to design space exploration, Ora Research, 2014. URL: http://oraresearch.com/2014/12/from-pido-to-design-space-exploration/ (дата обращения: 29.02.2016).
3. Jenkins B. Before optimization: Design space exploration, Ora Research, 2015. URL: http://oraresearch.com/2015/11/before-optimization-design-space-exploration/ (дата обращения: 29.02.2016).
4. Worldwide CAD Trends 2015, Business Advantage, 2015. URL: http://www.business-advantage.com/CAD-Trends.php (дата обращения: 29.02.2016).
5. Study by: Cambashi, BeyondCAE, Front End Analytics. 2014.
6. Nagy D. Engineering Simulation: The Road(s) Ahead, NAFEMS World Congress, 2015, pp. 9-12.
7. Ladzinski M., Betts J., Tiller M., Valine G., Panthaki M. Democratizing CAE, NAFEMS World Congress, 2015, pp. 7-14.
8. Davydov A., Morozov S., Perestoronin N., Prokhorov A. The First Full-Cloud Design Space Exploration Platform, Simulation Process and Data Management, 2015, pp. 90-95.
9. Mell P., Grance T. The NIST Definition of Cloud Computing, U.S. National Institute of Standards and Technology, 2011, pp. 2-3.
10. Salas A., Townsend J. Framework Requirements for MDO Application Development, 7th AIAA/USAF/NASA/ISSMO Symposium on Multidisciplinary Analysis and Optimization, 1998, pp. 261-268.
11. Martins J., Lambe A. Multidisciplinary Design Optimization: a Survey of Architectures, AIAA Journ., 2013, vol. 51, no. 9, pp. 2049-2075.
12. Бурнаев Е.В., Губарев Ф.В., Морозов С.М., Прохоров А.А., Хоминич Д.С. Автоматизация инженерных расчетов, анализ данных и оптимизация с помощью программного комплекса PSE/MACROS // Межотраслевая информ. служба. 2013. № 4 (165). С. 41-50.
DOI: 10.15827/0236-235X.114.034-040 Received 15.03.16
A HYBRID DESKTOP/CLOUD PLATFORM FOR DESIGN SPACE EXPLORATION
(The work has been supported by the RFBR, the research project no. 15-29-07043)
Prokhorov A.A., Head of Department, alexander.prokhorov@datadvance.net;
Nazarenko A.M., Senior Programmer, alexey.nazarenko@datadvance.net;
Perestoronin N.O., Senior Programmer, nikita.perestoronin@datadvance.net;
DavydovA.V., Technical Writer, andrey.davydov@datadvance.net (DATADVANCELLC, Nauchnyproezd 17, Moscow, 117246, Russian Federation)
Abstract. Modern engineering practice shows that simulation driven design is arguably the most promising method to reduce lead time and development costs. However, its application involves a number of methodological and operational difficulties. Thus, it remains limited and in general is not available for smaller companies that lack the required resources. High entry level of this method is the consequence of high complexity and cost of implementing the simulation models required in solving modern multidisciplinary engineering problems. Development of such models requires a high level of expertise in many subject domains, as well as using various specific software products which are usually available on commercial basis only. Moreover, performing large scale simulations leads to additional costs for development and maintenance a high-performance computing system.
The paper considers the main issues of performing large scale automated simulations that are required when computational methods are applied at early design stages in order to support a search for new design decisions. On contrary, we have a yet more common practice of using simulation experiments only at the later stage of design validation, which does not require mass calculations. The paper discusses the ways of lowering the entrance level paying attention to the existing practice of developing integrated solutions that are accessible to a wide range of users, as well as to the opportunity of at least partial moving simulation experiments into a cloud, which would allow lowering simulation costs. The authors also consider developing hybrid integrated applications based both on cloud and desktop software. The paper formulates related requirements for the process integration and automation platform that would support both cloud and desktop components in order to allow developing hybrid integrated applications aimed to solve classes of similar tasks. It then proceeds to describe the software architecture developed with regard to these requirements, which allows minimizing resources required for implementation thanks to the fact that its main components can be used both in the cloud and desktop versions.
Keywords: engineering automation, cloud computing, integration, design process management.
References
1. Jenkins B. Anatomy of design space exploration. Ora Research. 2014. Available at: http://oraresearch.com/ 2014/12/anatomy-of-design-space-exploration/ (accessed February 29, 2016).
2. Jenkins B. From PIDO to design space exploration. Ora Research. 2014. Available at: http://oraresearch.com/ 2014/12/from-pido-to-design-space-exploration/ (accessed February 29, 2016).
3. Jenkins B. Before optimization: Design space exploration. Ora Research. 2015. Available at: http:// oraresearch.com/2015/11/before-optimization-design-space-exploration/ (accessed February 29, 2016).
4. Worldwide CAD Trends 2015. Business Advantage. 2015. Available at: http://www.business-advantage.com/ CAD-Trends.php (accessed February 29, 2016).
5. Study by: Cambashi, BeyondCAE. Front End Analytics, 2014.
6. Nagy D. Engineering Simulation: The Road(s) Ahead. NAFEMS World Congr., 2015, pp. 9-12.
7. Ladzinski M., Betts J., Tiller M., Valine G., Panthaki M. Democratizing CAE. NAFEMS World Congr. 2015.
8. Davydov A., Morozov S., Perestoronin N., Prokhorov A. The First Full-Cloud Design Space Exploration Platform. Simulation Process and Data Management. 2015, pp. 90-95.
9. Mell P., Grance T. The NIST Definition of Cloud Computing. U.S. National Institute of Standards and Technology, 2011, pp. 2-3.
10. Salas A., Townsend J. Framework Requirements for MDO Application Development. The 7th Symp. on Multi-disciplinary Analysis and Optimization AIAA/USAF/NASA/ISSMO. 1998, pp. 261-268.
11. Martins J., Lambe A. Multidisciplinary Design Optimization: a Survey of Architectures. AIAA Journ., 2013, vol. 51, no. 9, pp. 2049-2075.
12. Burnaev E., Gubarev F., Morozov S., Prokhorov A., Khominich D. PSE/MACROS: Software Environment for Process Integration, Data Mining and Design Optimization. Mezhotraslevaya informatsionnaya sluzhba [Interindustry Information Service]. 2013, vol. 4 (165), pp. 41-50 (in Russ.).
