Программные продукты и системы

Значимость подхода к выработке инженерных решений с использованием расчетных моделей [1–3] в настоящее время достаточно очевидна: вследствие того, что скорость устаревания конструкторских решений на протяжении последних десятилетий постоянно растет, большинство производящих компаний ставят целью сокращение срока выхода изделий на рынок, а данный подход можно рассматривать как наиболее перспективный с точки зрения сокращения сроков и стоимости разработки, что подтверждается недавним анализом трендов в CAD-приложениях [4], где расчетное моделирование занимает второе место. Однако доля инженеров, использующих данный подход на практике, оценивается не более чем в 5 % от общего мирового количества пользователей соответствующего ПО [5]. Моделирование по-прежнему используется в основном на этапе валидации решений, а не для исследования пространства проектных параметров, и гораздо реже применяется для выработки и отбора решений на раннем этапе проектирования. Более того, упомянутые 5 % пользователей в основном являются сотрудниками крупных компаний, вслед- ствие чего применение данного подхода ограничивается не только малым количеством пользователей, но и относительно малым количеством использующих его компаний.

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

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

Вертикально интегрированные приложения

Под вертикально интегрированным приложением понимается сравнительно узкоспециализированное программное решение, реализующее некий конкретный подход к решению задачи [6]. Типичный пример – приложение, интегрирующее ряд CAD- и CAE-пакетов общего назначения, которое позволяет пользователю контролировать некоторые параметры изделия (геометрические, нагрузочные) и автоматически рассчитывает интересующие его характеристики (например, распределение нагруз­ки). Такое приложение разрабатывается на основе массы специальных знаний, однако пользователю оно предоставляет простой интерфейс для работы с комплексной моделью изделия, скрывая от него сложности реализации. Сравнительно узкая область применения и вытекающая отсюда простота интерфейса позволяют его использование даже неспециалистами, а возможности применения определяются степенью параметризации задачи, заложенной разработчиками приложения. В той или иной форме данный подход используется при решении многих реальных задач, обеспечивая возможность неявного обмена опытом и знаниями между участниками процесса.

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

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

Облачные приложения

Приложения, использующие облачные вычисления, являются одним из ключевых направлений развития современных CAE-систем. Без преувеличения можно сказать, что сегодня мы наблюдаем зарождение экосистемы специализированных облачных приложений для решения инженерных задач, частью которой являются такие пакеты, как Onshape, pSeven [8], SimScale и SimForDesign. Важно, что упомянутые приложения соответствуют основным принципам модели облачных вычислений [9]. В частности, они реализуют концепции предоставления ресурсов по требованию и легкой масштабируемости и за счет своей гибкости обеспечивают возможности по снижению стоимости использования.

Существующие облачные приложения уже развивают открытые API (это довольно естественно для сетевых сервисов), что делает возможным их прямую интеграцию. Вертикально интегрированные облачные приложения способны стать решением двух основных проблем, препятствующих широкому распространению обсуждаемого подхода. Однако в развивающейся облачной экосистеме пока еще отсутствует тот элемент, который необходим для массового создания и использования вертикально интегрированных приложений. Как отмечалось выше, эффективная разработка таких приложений требует наличия платформы для исследования пространства параметров – облачного аналога таких настольных систем, как Isight или modeFRONTIER (характерные свойства такого рода систем подробно описаны в [10]). В настоящее время не существует интеграционной платформы, разработанной специально с учетом применимости облачных вычислений и позволяющей создавать интегрированные приложения, полностью основанные на облачных технологиях.

Требования к интеграционной платформе

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

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

2.     Поддержка интеграции настольных приложений и возможность разработки гибридных интегрированных приложений. Это необходимо, по крайней мере, по двум причинам: во-первых, облачные приложения в обозримом будущем все же не смогут полностью вытеснить основные настольные CAD-системы, во-вторых, как правило, требуется интеграция с ПО, разработанным внутри компании, которое по техническим или иным причинам (например, из соображений безопасности) не может быть переведено на модель облачных вычислений. Таким образом, многие интегрированные решения будут частично основаны на настольных приложениях.

3.     Наличие собственных средств исследования пространства параметров, в частности, оптимизационных алгоритмов и средств анализа данных.

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

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

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

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

Архитектура интеграционной платформы

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

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

-      чисто настольного приложения (без сетевого взаимодействия);

-      настольного приложения, поддерживающего выполнение задач на ресурсах локальной сети;

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

-      чисто облачного приложения;

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

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

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

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

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

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

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

Рассмотрим архитектуру, учитывающую указанные необходимые свойства. В ее основе лежит клиент-серверная модель, предполагающая наличие легкой серверной части и клиентского графического интерфейса, реализованного с применением современных веб-технологий (JavaScript, HTML5). Пользователи облачной версии устанавливают соединение с сервером с помощью обычного веб-браузера, который загружает графический интерфейс клиента и представляет его пользователю как обычную веб-страницу. В облачной версии сервер использует виртуализацию на уровне операционной системы: расчет запускается в Docker-контейнере, чтобы каждый пользователь работал со своим изолированным экземпляром среды. В таком случае на стороне пользователя не требуется установка каких-либо программ, за исключением любого современного веб-браузера. Настольная версия работает в рамках той же модели: прозрачным для пользователя образом она запускает локальный сервер и открывает графический интерфейс во встроенном браузере, который автоматически устанавливает соединение с локальным сервером. Установка настольной версии, таким образом, не требует наличия браузера или какой-либо дополнительной настройки серверной части.

Сначала более подробно рассмотрим архитектуру настольной версии (рис. 1). Ее основные процессы: браузер (клиентская часть), сервер и процесс-агент. Браузер предоставляет пользователю графический интерфейс. При этом он не запрещает доступ к локальной файловой системе и не требует соблюдения принципа одного источника, но исключает переход на другие страницы, в результате создавая у пользователя впечатление работы с на­стольным ПО. Сервер – это однопользовательский HTTP-сервер, управляющий логикой составления и исполнения расчетных схем, но не работающий напрямую с графической подсистемой. Данные расчетов хранятся в проекте – директории в локальной файловой системе. Единовременно сервер обслуживает один проект; для обеспечения совместной работы пользователей над проектом должен быть предусмотрен не зависящий от файловой системы механизм блокировки файлов. Во время исполнения расчета сервер обеспечивает изоляцию задач на уровне процессов. Запуском задач управляет процесс-агент, который может запустить локальную задачу по указанию как локального сервера, так и сервера, размещенного на удаленном узле.

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

В архитектуре облачной версии системы (рис. 3) следует выделить портал (точку входа), БД, менеджер заданий и два типа ресурсов: подконтрольные и неподконтрольные системе.

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

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

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

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

Вышеописанная архитектура облачной версии делает возможным ряд существенно различных вариантов использования (рис. 4):

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

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

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

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

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

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

Критерием оптимальности при разработке данной архитектуры была минимизация количества кода (количества компонентов) за счет создания универсальных компонентов, которые могут быть использованы в различных версиях системы. Следует также отметить, что представленное решение во многом основано на практическом опыте разработки интеграционной платформы 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 Sympo­sium on Multidisciplinary Analysis and Optimization, 1998, pp. 261–268.

11.  Martins J., Lambe A. Multidisciplinary Design Optimiza­tion: a Survey of Architectures, AIAA Journ., 2013, vol. 51, no. 9, pp. 2049–2075.

12.  Бурнаев Е.В., Губарев Ф.В., Морозов С.М., Прохо- ров А.А., Хоминич Д.С. Автоматизация инженерных расчетов, анализ данных и оптимизация с помощью программного комплекса PSE/MACROS // Межотраслевая информ. служба. 2013. № 4 (165). С. 41–50.