Передача данных и планирование в облачных САПР

Тип работы:
Реферат
Предмет:
ТЕХНИЧЕСКИЕ НАУКИ


Узнать стоимость

Детальная информация о работе

Выдержка из работы

Передача данных и планирование в облачных САПР
Макаров К. А. makarovjob@yandex. ги Аннотация. В статье рассматривается принцип построения и общая архитектура системы САПР в облачной среде с использованием бизнес-модели Software as service. Рассматривается структура облачного узла. Рассмотрен алгоритм планирования задач и взаимодействия между сервисами.
Ключевые слова: облако, узел, планирование.
1 Введение
В данной статье определяется облик САПР в рамках облачного развертывания, а так же рассматриваются проблемы планирования и обмена данных между сервисами, входящими в систему подобного рода.
Облачные вычисления представляют собой особую парадигму в предоставлении вычислительных ресурсов. Которая выдвигает определенные требования к архитектуре приложения (САПР) и системе планирования, которые могут различаться в зависимости от облачной концепции. В облаке САПР будет представлена набором сервисов в составе облачного узла — системы состоящей из этих сервисов -обменивающихся сообщениями, состоящими из управляющих команд, отчетов выполнения этих команд, а также результатов работы.
Облачные вычисления ориентированы на предоставление информационных ресурсов на трех уровнях: уровне инфраструктур (IaaS), уровне платформ (PaaS) и уровне программного обеспечения (8аа8)[Радченко, 2012].
Рассматривать САПР в облачной среде будем в рамках концепций SaaS (Softwareas, а Service) -модель предоставления программного обеспечения, при которой владелец (поставщик) ПО предоставляет доступ к нему пользователям (заказчикам) через Интернет.
Концепция Saas позволит пользователям использовать возможности системы моделирования без липших затрат вычислительных ресурсов. Она даст возможность доступа к функционалу САПР как к облачным сервисам. А также даст возможности масштабирования системы и распараллеливания задач.
Будем рассматривать такую структуру САПРгде каждый сервис не зависит от других, и его можно подключить/отключить, не нарушая общей работоспособности системы:
2 Кластер, как основа сервиса
Так как облачный узел состоит из сервисов, рассмотрим в начале техническую базу сервиса. Технически, каждый сервис является неким кластером, состоящим из нескольких серверов (их число может меняться в зависимости от потребностей системы) по следующему принципу. Любую задачу, передаваемую сервису нужно распределить по серверам кластера, поэтому в нем должна быть система распределения задач, отвечающая как за балансировку нагрузки, так и за возможность обращения к конкретному серверу. Тогда между ними возможно распределение нагрузки, это удобно при планировании.
Сервис
Распреде ление задач
г-Ч
Сервер2
ь-ч
Сервер п
Ф
Репсшторий
Рис. 1 Общая схема кластера облачного сервиса.
3 Структура облачного узла
Структура узла, без учета специфики сервисов будет выглядеть так:
Представление Представление Платформа
уровень 1 уровень 2
Рис. 2 Структура облачного узла
Краткое описание основных сервисов и компонентов:
1) -Ядро (блок управления) Хранит список загруженных на узле экземпляровсервисов, их конфигурацию, коллекции выполняемых в данный момент каждым сервисом заданий и информацию об их состоянии.
2) Реестр сервисов. Служит для публикации и ведения списка сервисов, доступных для потребителей.
3) Репозиторий. Содержит метаданные о модели: определения классов, атрибутов и методов. А также промежуточные результаты расчетов и т. п. хранит процесс всего построения модели, и содержать созданные в прошлом модели для повторного использования.
В этом случае сложная модель может быть собрана из компонентов, созданных ранее другими пользователями. «Создание сложных моделей с нуля одним человеком это — трудоемкий процесс, поэтому возможность повторного использования компонентов модели резко сокращает время разработки самой модели» рассмотрено в [Фишвик и др., 2001].
4) Расчетный модуль (модули)Любой модуль для проведения конкретных расчетов (их может быть несколько)
5) Модуль формирования результатов обработка и представление пользователю результатов расчетов
6) Модуль взаимодействия между узлами
7) Модуль сбора статистики
8) Планировщик — роль планировщика в данном контексте будет заключаться в эффективном управлении вычислительными средствами. Выборе необходимых сервисов и организации соответствующий последовательностей (сервис — задача — очередь — результат)
4 Обмен данными между сервисами внутри узла
Чтобы организовать обмен данными, чтобы пользователь и процессы системы могли использовать какой-либо сервис он должен быть опубликован в реестре сервисов системы с описанием его интерфейса, за основу достаточно взятьХМЬ — описаниепо cтaндapтyWSDL).
Если интерфейс этого сервиса будет выглядеть так: get_model ()//пoлyчить модель
?е1_гер011-()//получить отчет о выполнении операции? е1_т81гисйоп ()//получить инструкцию? е1_гези11-()//получить результат ит.д.
Это будет выглядеть следующим образом:
& lt-орегайоппате-^е!КерогГ>-
& lt-раг1пате-'-уа1ие"-1уре-'-хв: 8йпщ7& gt- & lt-/орегайоп>-
& lt- орегайоппате-'- ?е11п81гисйоп & quot->-
& lt-раг1пате-'-уа1ие"-1уре-'-хв: 8йпщ7& gt- & lt-/орегайоп>-
сорегайоппате-^е1Моёе1& quot->-
& lt-inputmessage="-getModelRequest"-/>- & lt-outputmessage=, getModelResponse"-/>- & lt-/орегайоп>-
В таком случае для обмена сообщениями можно использовать БОАР-протокол. Что наилучшим образом подходит для передачи данных по модели.
5 Планирование
Целью планирования является последовательность распределений ресурсовдля выполнения заданий во временной интервал, на который они отводятся заданию. На этом интервале ресурсы считаются занятыми и недоступными другим заданиям.
Чтобы выполнить какую-то конкретную задачу в распределенной системе сервисов нужно перво-наперво определить, какие сервисы необходимы для решения этой задачи (а конкретнее какой сервис нужен для какой подзадачи- реестр сервисов предполагается по умолчанию в сервисной архитектуре. Следовательно:
Пользователи

Где и что запустить
Ресурсы распределенной
системы (сервисы узла)
Рис. 3 Схема планирования
6 Последовательность операций при планировании
1) Получение задания, сохранение информации о нем в репозитории
2) Занесение этого задания в общую очередь заданий с приоритетами
3) Дробление на подзадачи по сервисам
4) Исходя из этого создаем расписания для каждого сервиса:
5) Получение стоящих в очереди заданий-
6) Получение расписаний всех кластеров-
7) Построение аллокации ресурсов для задания-
8) Если время начала аллокации близко: резервирование- доставка задания в кластер (системе запуска).
7 Разбиение на подзадачи, декомпозиция- интеграция
В работах в области агентов и искусственного интеллектаодной из важных задач является композиция/декомпозиция между сервисами/агентами рассмотрено в [Тарасов, 2011]. Типичная схема распределенного решения задач несколькими сервисами включает следующие этапы:
1) система планирования проводитдекомпозицию исходной проблемы на отдельные задачи-
2) эти задачи распределяются между сервисами-исполнителями-
3) каждый сервисами -исполнитель решает свою задачу, подчас также разделяяее на подзадачи-
4) для получения общего результата производится композиция, интеграциячастных результатов, соответствующих выделенным задачам, (из [Тарасов В.Б. ])
8 Декомпозиция
В случае облачной САПР, состоящей из облачных сервисов и разных расчетных модулей, возникает естественная потребность в параллельных вычислениях при решении задач моделирования и расчетов. Для эффективного обеспечения этих потребностей может послужить декомпозиция — разбиение одной задачи на несколько подзадач и распределение разных видов по разным видам сервисов. Возможность декомпозиции одной задачи можно обосновать исходя из представлений модели, состоящей из набора типовых компонентов.
В условиях многопользовательского режима нужно хранить информацию и промежуточные данные в репозитории, за счет него же и предполагается осуществлять декомпозицию. Для этого нужно информацию по задаче представить в следующем виде (упрощенно):
М етада н н ы е зада ч и
И задачи данные StartDate End Date результат
Метаданные? подпроцесса
ld данные п ром е жуточ н ы й ре зул ьтзт И задачи
Рис. 4 Метаданные задачи/подзадачи
9 Объединение результатов
Происходит по промежуточным результатам, сохраненным в репозитории соответствующим процессом. Находятся все промежуточные результаты с идентификатором задачи:
Общая задача
О
Декомпозиция
адресация по серверам
I
Srvl
1
1
Srv2
Srv n
результаты
ь
Регозиторий
Q
Результаты работы сервисов
Композиция
Общий результат
Рис. 5 Декомпозиция/интеграция
10 Выводы
В статье рассмотрена примерная общая схема функционирования облачного узла САПР с описанием принципов взаимодействия сервисов и планирования т. е. распределения вычислительных ресурсов сервисов по времени. Приведен один из возможных методов разбиения на подзадачи, что является актуальной проблемой для САПР и может послужить основой для дальнейшей оптимизации.
Список литературы
[Радченко, 2012] Распределенные вычислительные системы / Г. И. Радченко. Челябинск:: Фотохуцожник, 2012. — 184 с.
[Риз, 2011] Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 е.: mi. ISBN 978−5-9775−0630−4
[Тарасов, 2011] От многоагентным систем к интеллектуальным организациям
[Фишвик и др., 2001] Исследовательские и коммерческие возможности Веб-моделирования //Теория и практика моделирования Октябрь 2001
Секция Проектирование аппаратуры

ПоказатьСвернуть
Заполнить форму текущей работой