CC BY
22
УДК 534.61
РАЗРАБОТКА ЭЛЕМЕНТОВ РАСПРЕДЕЛЕННОЙ БИБЛИОТЕКИ НА БАЗЕ РАСПРЕДЕЛЕННОГО РЕЕСТРА ДЛЯ СИСТЕМ МОНИТОРИНГА
И ДИАГНОСТИКИ
Э.В. Мельник, И.С. Пуха, М.В. Орда-Жигулина, Д.В. Орда-Жигулина
В данной работе предложена модель распределенной библиотеки данных, разработанная на базе технологии распределенного реестра. Предложенная модель включает в себя комплекс программ распределенного реестра, набор скриптов для обеспечения доступа и хранения данных в распределенном реестре и локальный диспетчер для организации распределенных вычислений и запуска и диспетчирования сервисов внешних подсистем для децентрализованных гетерогенных реконфигурируемых систем мониторинга и диагностики различных областей применения. Авторами была предложена децентрализованная структура организации распределенной библиотеки для современных систем мониторинга и диагностики. Применение технологии распределенного реестра позволяет с высокой эффективностью осуществить объединение разрозненных источников данных, гетерогенных вычислительных ресурсов и каналов связи с различной пропускной способностью и надежностью. Распределенный реестр является системообразующим элементом, вокруг которого строится вся система, к которому подключены все остальные компоненты. Распределенная библиотека предназначена для хранения исходных и обработанных данных, но при этом включает в себя не только распределенный реестр, а также локальные диспетчеры и функциональные приложения для организации доступа к данным.
Ключевые слова: мониторинг и диагностика, технологии интеллектуального анализа данных, туманные вычисления, Интернет вещей, децентрализованные системы поддержки принятия решений, блокчейн.
Введение. В настоящее время системы мониторинга и диагностики получили широкое распространение в различных областях человеческой деятельности от отслеживания опасных природных явлений в режиме реального времени до долгосрочной оценки социальных процессов. При создании новых систем мониторинга и диагностики важно понимать, какие важные параметры и метрики необходимо отслеживать и какие данные собирать на разных этапах и уровнях мониторинга или диагностики.
При этом любая система будет состоять состоит из множества различных компонентов. Типы и способы реализации которых зависят от области мониторинга и реализации стратегии мониторинга и диагностики. В целях создания современных систем мониторинга и диагностики для различных областей применения и на основании ранее проведенных исследований [1-10] авторами был разработан компонент системы мониторинга и диагностики, которым является распределенная библиотека на базе технологии распределенного реестра.
Разработанный компонент представляет собой комплекс программ распределенного реестра, набор скриптов для организации доступа и хранения данных в распределенном реестре и локальный диспетчер для организации распределенных вычислений и запуска и диспетчирования сервисов внешних подсистем. Данный комплекс программ может являться основой при разработке функциональных приложений от внешних подсистем, которые помимо чтения-записи данных в реестр могут осуществлять необходимую обработку данных.
Ранее были разработаны элементы методов обработки и передачи информации для систем мониторинга и диагностики для различных областей применения и методы и алгоритмы повышения надежности за счет реконфигурации ресурсов (перераспределения функций) на базе таких технологий «цифровой экономики» как «туманные», «краевые» вычисления и распределенный реестр [5-9].
Также на базе ранее разработанных методов [10] были разработаны алгоритмы работы сервисов внешних подключаемых подсистем, на основании которых при необходимости, внешние разработчики могут создавать свои функциональные приложения, обеспечивающие сопряжение подключаемых внешних систем с разработанными компонентами системы мониторинга и диагностики (рис. 1).
Копия распределенного реестра 1 из К
1
I
I
ЗЕ
Локальный диспетчер ВУ 1 Локальный диспетчер ВУ 2 Локальный диспетчер ВУ N
Сервисное приложение для записи/чтения данных Сервисное приложение д ля записи/чтения данных Сервисное приложение д ля записи/чтения данных
Функционально е приложение для подсистемы сбора, хранения и первичной обработки данных Функциональное приложение для подсистемы поддержки принятия решений Функциональ но е приложение для подсистемы сбора, хранения и первичной обработки данных Функциональное приложение для подсистемы поддержки принятия решений Функциональ но е приложение для подсистемы сбора, хранения и первичной обработки данных Функциональное приложение для подсистемы поддержки принятия решений
Промежуточное программное обеспечение
ПОДСИСТЕМА ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ
ПОДСИСТЕМА СБОРА, ХРАНЕНИЯ И ПЕРВИЧНОЙ ОБРАБОТКИ ДАННЫХ
Рис. 1. Структура копии распределенного реестра
Такие функциональные приложения помимо чтения-записи данных в реестр также должны обеспечивать необходимую обработку данных. Также был разработан алгоритм работы локального диспетчера, который обеспечивает взаимодействия функциональных приложений в распределенной среде.
Распределенный реестр является системообразующим элементом, вокруг которого строится вся система, к которому подключены все остальные компоненты. Отдельные копии распределенного реестра можно максимально «приблизить» к потребителям за счет использования устройств туманного слоя. Следовательно, целесообразно с каждой такой копией распределенного реестра ассоциировать функциональные приложения, которые занимаются обработкой данных.
Распределенная библиотека предназначена для хранения исходных и обработанных данных, но при этом включает в себя не только распределенный реестр, а также локальные диспетчеры и функциональные приложения для организации доступа к данным.
Локальные диспетчеры введены в состав распределенной библиотеки для организации взаимодействия подсистем, снижения нагрузки на сеть, снижения латентности, а также для использования ресурсов устройств туманного слоя в качестве резервных. При этом локальные диспетчеры обеспечивают распределение вычислительной нагрузки между всеми устройствами системы, перенося вычислительную нагрузку краевого и туманного слоев между слоями [1, 10].
Принципы построения распределенной библиотеки на базе распределенного реестра. Примером использования модели и циркуляции данных в ней, как показано на рис. 2 является подключение к распределенной библиотеки подсистемы сбора, хранения и первичной обработки данных и подсистемы поддержки принятия решений.
Как видно из рис. 2 в распределенную библиотеку поступают данные от подсистемы сбора данных, их описание, результаты их обработки, после чего они доступны для пользователей и экспертов. Структура распределенной библиотеки имеет четыре раздела, показанные на рис. 2. При необходимости предоставленные подсистемой сервисы могут быть выполнены в облачном или туманном вычислительном слое. Подсистема поддержки принятия решений также имеет доступ к распределенному реестру, а, значит, и к полученным данным от подсистемы сбора. От данной подсистемы в распре-
деленную библиотеку могут попадать данные о результатах когнитивного моделирования, заключение экспертов. При необходимости на вычислительных узлах облачного и туманного слоя могут исполнятся задачи моделирования.
РАСПРЕДЕЛЕННАЯ БИБЛИОТЕКА
Раздел распределенной библиотеки 1. Данные о параметрах системы в отношении которой осуществляется мониторинг и прогнозирование.
Раздел распределенной библиотеки 2. Служебные данные, необходимые для диспетчирования системы, реализации распределённого реестра, прочие данные
Раздел распределенной библиотеки 3. Данные о результатах когнитивного моделирования, прогнозов, расчетов, заключений экспертов
Раздел распределенной библиотеки 4. Данные сторонних систем (например, подсистема анализа социальной активности пользователей и т.д.)
Рис. 2. Распределенная библиотека системы мониторинга и диагностики для различных областей деятельности
Для реализации распределенной библиотеки был разработан алгоритм работы основного цикла локального диспетчера. Разработанный алгоритм обеспечивает децентрализованное взаимодействие функциональных приложений в распределенной среде без выраженного лидера и отказоустойчивость системы в целом. При этом каждому выполняемому функциональному приложению предоставляется программная библиотека для доступа к функционалу прототипа локального диспетчера. Реализованы два режима работы алгоритма: синхронный и асинхронный.
Также были разработаны алгоритмы организации доступа к данным распределенного реестра.
Алгоритмы работы модели компонента системы мониторинга и диагностики - распределенной библиотеки на базе технологии распределенного реестра.
Для разработанной модели распределенной библиотеки для систем мониторинга и диагностики различных областей применения были разработаны алгоритмы работы сервисов внешних подключаемых подсистем, на основании которых при необходимости, внешние разработчики могут создавать свои функциональные приложения, обеспечивающие сопряжение подключаемых внешних систем с разработанными компонентами системы мониторинга и диагностики (рис. 1). Такие функциональные приложения помимо чтения-записи данных в реестр также должны обеспечивать необходимую обработку данных. Для последующей реализации подобных приложений был разработан алгоритм работы локального диспетчера, который обеспечивает взаимодействия функциональных приложений между собой и с системой в распределенной среде.
Суть алгоритма работы локального диспетчера заключается в следующем: основной задачей локального диспетчера является обеспечение взаимодействия сервисных приложений в распределенной среде, включая копию реестра и отказоустойчивость системы в целом. При этом каждому выполняемому сервисному приложению предоставляется программная библиотека для доступа к функционалу прототипа локального диспетчера.
Рм
н и и и Рм
«
3
Я П
и
4
и «
и Рм В
и
Рм
Порядок цикла работы локального диспетчера, следующий:
1. Осуществляется передача сообщений другому сервису.
2. Осуществляется прием сообщений от других заданий.
3. Осуществляется удаленный вызов функций приложений, расположенных на узлах системы (обращение к функциям одного приложения со стороны другого как к обычным собственным функциям).
4. Осуществляется удаленный вызов приложением-публикатором обработчиков событий, расположенных в приложениях-подписчиках.
5. Осуществляется проверка состояния задания посредством регулярного вызова функции проверки «пульса» задания.
6. Осуществляется проверка состояния основного процесса каждого задания.
7. Осуществляется обеспечение каждого задания информацией о текущем статусе остальных заданий.
8. Если установлен признак окончания работы программы локального диспетчера, то перейти к п.9., иначе к п.1
9. Выход.
Основным механизмом обмена данными между сервисными приложениями является точка подключения.
Точка подключения - именованная группа событий и удаленно вызываемых процедур (функций), действующая в рамках всего набора компонентов функционального программного обеспечения.
В контексте событийной модели приложение, зарегистрировавшее точку подключения (инициирующие события), называется «публикатором», а приложения, получающие оповещение о событиях точку подключения - «подписчиками».
Обмен по подписке предполагает, что некоторые из задания являются источниками информации определенного вида, о чем они в начале работы «сообщают» «своему» локальному диспетчеру. Другие задания, заинтересованные в получении этой информации, должны «оформить подписку» на нее, обратившись к «своему» локальному диспетчеру. (Фактически, в данном случае коллективом локальных агентов реализуется «точка подключения» к данным определенного вида.) Далее, когда у задания-источника будет готова к отправке очередная «порция» данных, оно передает ее «своему» локальному диспетчеру, который по имеющемуся списку «подписчиков» осуществляет рассылку. Данный механизм обеспечивает гибкость управления структурой задачи, привязка задания осуществляется не к другим задания, а к данным определенного вида. Такая гибкость важна в ходе разработки задания, а также при выполнении модификации программного обеспечения распределенной системы управления.
Возможны два режима работы — синхронный и асинхронный.
При синхронном вызове источник в месте вызова дожидается результата, после чего продолжает функционирование.
При асинхронном вызове после отправки запроса выполнение задания продолжается, а для получения ответа назначается специальный обработчик, которому после получения передается результат. Имеется штатный обработчик приема результатов асинхронного удаленного вызова процедуры или события, который, как и в случае передачи сообщений и рассылки данных, помещает результат в очередь сообщений.
Также для модели компонента системы мониторинга и диагностики - распределенной библиотеки данных на базе технологии распределенного реестра были разработаны алгоритмы работы сервисных программ.
Сервисными программами называются сервисы, предоставляемые внешними подсистемами для сбора, хранения, передачи и анализа данных.
Так, кроме локального диспетчера в рамках реализации прототипа системы разработаны два набора (шаблона) сервисных программ: «подзадача приема данных» и «подзадача обработки данных». «Подзадача приема данных» осуществляет прием данных от интеллектуальных датчиков и выставляет запрос на обработку этих данных на «доску объявлений».
«Подзадача обработки данных» анализирует находящиеся в системе запросы и выполняет их обработку. Так же «подзадача приема данных» следит за активностью узла, взявшего на себя выполнения задания и, при необходимости ретранслирует новый запрос на выполнение. Далее «подзадача обработки данных» записывает итоговые данные разово или с заданной периодичностью в распределенный реестр.
Пример общей схемы функционирования сервисных программ показан на рис. 3.
Рис. 3. Конфигурация набора заданий и итоговый выбор
На рис. 3 возможные конфигурации распределение потоков данных изображены на рисунке пунктирной линией. В конфигурации подзадач приема данных задан список интеллектуальных датчиков, от которых программа принимает данные. В приведенном выше примере «Подзадача приема данных 1» принимает данные от первого и второго, а «Подзадача приема данных 2» от второго и четвертого интеллектуального датчика. При старте, если данные от приложений еще не обрабатываются, оба приложения помещают запросы на обработку в распределенный реестр на базе Ethereum, откуда приложение-обработчик «Подзадача обработки данных» выбирает одно их них. В примере «Подзадача обработки данных» подтверждает (так же через «доску объявлений» распределенного реестра) работу с приложением-публикатором «Подзадача приема данных 2» и итоговые потоки данных изображены уже сплошной линией.
Алгоритм работы сервисной программы «Подзадача приема данных» заключается в следующем:
Сервисная (служебная) программа «Подзадача приема данных» представляет собой простой детерминированный конечный автомат (ДКА) с тремя состояниями: поиск рабочего; (исполнителя); обработка данных; останов.
В одно из этих трех состояний программа может переходить в зависимости от определенных условий.
Алгоритм работы сервисной программы «Подзадача приема данных» выглядит следующим образом:
1. Инициализация функций взаимодействия с локальным диспетчером;
2. Определение конфигурации задания — списка интеллектуальных датчиков распределенной сети датчиков, с которыми происходит работа;
3. Создание именованного объекта взаимодействия с другими функциональными программами - точки подключения;
4. Начальное состояние ДКА - поиск обработчика данных;
5. Если от локального диспетчера пришла команда останова - окончание работы;
6. Если мы находимся в состоянии поиска обработчика данных, то пункт 7, иначе перейти к пункту 9;
7. Если в распределенном реестре нет записи о запросе обработки или записи о самой обработке данных, то поместить в реестр запись-запрос;
8. Если в распределенном реестре есть запись о готовности обработки данных, то установить состояние — обработка данных и перейти к пункту 9, иначе перейти к пункту 6;
9. Запись в доске объявлений не соответствует обработки данных - перейти к пункту 12;
10. Получить информацию от локального диспетчера об активности вычислительного узла, производящего обработку данных. Если узел активен, то пункт 11, иначе установить состояние останов и перейти к пункту 12;
11. Сформировать единый пакет данных от датчиков и отправить его в точку подключения, перейти к пункту 9;
12. Если запись в распределенном реестре - не соответствует обработке данных, то перейти в состояние - поиск обработчика данных и перейти к пункту 5, иначе ожидание.
Алгоритм сервисной программы «Подзадача обработки данных» заключается в следующем:
Сервисная (служебная) программа обработчика данных «Подзадача обработки данных» - так же представляет собой детерминированный конечный автомат с тремя состояниями - поиск задания, обработка задания и останов.
Более детально алгоритм работы представляет собой следующую последовательность операций:
инициализация функций взаимодействия с локальным диспетчером; определения конфигурации задания - списка возможных источников данных; начальное состояние - поиск задания;
если от локального диспетчера пришла команда останова - окончание работы; если состояние - поиск задания перейти к пункту 6, иначе перейти к пункту 10; получить из «Доски объявлений» распределенного реестра список доступных на обработку запросов;
если в списке доступных запросов, есть запрос подходящий нам, то установить в распределенном реестре признак готовности обработки данных и перейти к пункту 8, иначе перейти к пункту 4;
если не удалось подключиться к точке подключения то перейти в состояние -останов и перейти к пункту 11;
установить состояние - обработка данных, установить вычислительную нагрузку для выполнения выбранного задания локальному диспетчеру;
если состояние — обработка данных, то перейти к пункту 11, иначе к пункту 12;
если в распределенном реестре изменяется запись о текущем состоянии выполнения задания — то завершить обработку точки подключение, перейти в состояние — поиск задания и перейти в состояние 4;
если состояние - останов, то ожидание срабатывания таймаута — по окончанию переход в состояние — поиск запроса, иначе переход в состояние 4.
В описание алгоритма программы обработчика данных явным образом не упоминается операция обработки данных. Это связанно с тем, что обработчик данных является callback функцией точки подключения. Функция вызывается автоматически при условии, что приложение подключено к точке подключения, и пришел пакет данных.
Функция обработки данных выглядит следующим образом:
если формат данных соответствует ожидаемому — принять пакет данных, иначе пропустить;
поместить пакет с данными в динамический буфер;
если наступило одно из двух событий — пришло заданное количество пакетов, или наступил таймаут обработки — вызвать функцию обработки данных для накопленного массива данных, иначе перейти к пункту 2;
поместить итоговый результат в распределенный реестр.
Выводы. Были разработаны методы и алгоритмы для построения компонентов распределенной библиотеки (промежуточное (сервисное) программное обеспечение, включая локальный диспетчер, и шаблон сервисного приложения для записи/чтения данных, на базе которых могут быть разработаны функциональное приложение для подсистемы сбора, хранения и первичной обработки данных, функциональное приложение для подсистемы поддержки принятия решений и распределенный ре-естр).Вышеперечисленные методы и алгоритмы позволяют организовать децентрализованное взаимодействие всех компонентов системы и повысить их надежность, эффективность и скорость работы за счет одновременного применения таких технологий цифровой экономики как распределенный реестр, технологии интеллектуального анализа данных и «туманных и облачных» вычислений, а также локальных агентов (диспетчеров).
Для проверки работоспособности разработанных методов и алгоритмовбыла-разработана модель компонента системы мониторинга, которая представляет собой распределенную библиотеку на базе технологии распределенного реестра. Разработанная модель представляет собой комплекс программ распределенного реестра, набор скриптов для организации доступа и хранения данных в распределенном реестре и локальный диспетчер для организации распределенных вычислений и запуска и диспет-чирования сервисов внешних подсистем в децентрализованной гетерогенной реконфи-гурируемой системе мониторинга и диагностики. При этом децентрализованная структура является наиболее эффективной при построении современных систем мониторинга и диагностики, а технология распределенного реестра позволяет эффективно объединять разрозненные источники данных, гетерогенные вычислительные ресурсы и каналы связи с различной пропускной способностью и надежностью.
Публикация выполнена при поддержке ГЗ ЮНЦ РАН № АААА-А19-119011190173-6 и грантов РФФИ №18-05-80092 и 18-29-22086.
Список литературы
1. Orda-Zhigulina M.V., Melnik E.V., Ivanov D.Y., Rodina A.A., Orda-Zhigulina D.V. Combined Method of Monitoring and Predicting of Hazardous Phenomena //Computer Science On-line Conference. Springer, Cham, 2019. P. 55-61.
2. Orda-Zhigulina D. V., Orda-Zhigulina M. V., Rodina A. A. Cognitive Model for Monitoring and Predicting Dangerous Natural Processes for Hydro Ecosystem Analysis //Proceedings of the Computational Methods in Systems and Software. - Springer, Cham, 2020. - С.
3. Melnik E.V., Bulysheva N.I., Orda-Zhigulina M.V., Orda-Zhigulina D.V. Component of Decision Support Subsystem for Monitoring and Predicting of Hazardous Processes at the Base of Analysis of Macro Zoobenthos Communities of Azov Sea //Proceedings of the Com.
4. Melnik E.V., Orda-Zhigulina M.V., Orda-Zhigulina D.V., Ivanov D.Y., Rodina, A. A. Fog computing in new approach for monitoring of hazardous phenomena //Journal of Physics: Conference Series. IOP Publishing, 2019. Т. 1333. №. 7. P. 072016.
5. Мельник Э.В. и др. Применение технологий цифровой экономики при разработке средств мониторинга и прогнозирования опасных процессов и обеспечения безопасности населения и береговой инфраструктуры // Закономерности формирования и воздействия морских, атмосферных опасных явлений и катастроф на прибрежную зону РФ в условиях глобальных климатических и индустриальных вызовов. 2019. C. 289291.
6. A New Approach to Consensus: Swirlds HashGraph [Электронный ресурс]. URL: http://sammantics.com/blog/2016/7/27/hashgraph- consensus (дата обращения: 02.09.2020).
7. Hedera Hashgraph. Explained [Электронный ресурс]. URL: https ://medium.com/datadriveninvestor/hedera-hashgraph-explained- c5d8ce4730a6 (дата обращения: 02.09.2020).
8. Hedera Hashgraph, Consensus, and Scalability [Электронный ресурс] URL: https://medium.com/@saratechnologiesinc/hedera- hashgraph-consensus-and-scalability-2315133a3e33 (дата обращения: 02.09.2020).
9. LeMahieu C. Nano: A feeless distributed cryptocurrency network // Nano [Электронный ресурс] URL: https://nano. org/en/whitepaper (дата обращения: 24.03. 2018).
10. Мельник Э.В., Орда-Жигулина М.В., Орда-Жигулина Д.В., Родина А.А. Метод повышения надежности за счет реконфигурации ресурсов в системах мониторинга и диагностики опасных природных явлений // Известия Тульского государственного университета. Технические науки. 2020. Вып. 2. С. 18-26.
Мельник Эдуард Всеволодович, д-р техн. наук, заведующий лабораторией, [email protected], Россия, Ростов-на-Дону, Южный научный центр Российской Академии наук,
Пуха Иван Сергеевич, ведущий программист, ru. odissey@gmail. com, Россия, Таганрог, Научно-исследовательский институт многопроцессорных вычисли-тельныхсистем им. акад. А. В. КаляеваЮФУ,
Орда-Жигулина Марина Владимировна, научный сотрудник, [email protected], Россия, Ростов-на-Дону, Южный научный центр Российской Академии наук,
Орда-Жигулина Дина Владимировна, младший научный сотрудник, dmazhigulma@,mail.ru, Россия, Ростов-на-Дону, Южный научный центр Российской Академии наук
DESIGNING OF ELEMENTS OF DISTRIBUTED LIBRARY AT THE BASE OF DISTRIBUTED REGISTER FOR MONITORING AND DIAGNOSTICS SYSTEMS
E.V. Melnik, I.S. Puha, M.V. Orda-Zhigulina, D.V. Orda-Zhigulina
It is proposed a model of distributed data library which is based at distributed ledger technology in the current paper. The proposed model includes the set of distributed ledger programs, the set of scripts to provide access, the storage of data scripts, and a local dispatcher to organize distributed computing and dispatching services of different subsystems for decentralized heterogeneous reconfigurable monitoring and diagnostic systems for various fields of application.
Key words: monitoring and diagnostics, data mining technologies, fog computing, Internet of things, decentralized decision support systems, blockchain.
Melnik Eduard Vsevolodovich, doctor of technical sciences, head of the laboratory, evm17@,mail. ru, Russia, Rostov-on-Don, Federal Research Center The Southern Scientific Center of the Russian Academy of Sciences,
Puha Ivan Sergeevich, lead programmer, ru. odissey@gmail. com, Russia, Taganrog, Scientific Research Institute of Multiprocessor Computing Systems named after the Academician A.V. Kalyaev,
Orda-Zhigulina Marina Vladimirovna, senior researcher, ,jigulina@,mail. ru, Russia, Rostov-on-Don, Federal Research Center The Southern Scientific Center of the Russian Academy of Sciences,
Orda-Zhigulina Dina Vladimirovna, researcher, dinazhigulinaamail. ru, Russia, Rostov-on-Don, Federal Research Center The Southern Scientific Center of the Russian Academy of Sciences
УДК 004.75
ФОРМИРОВАНИЕ ОГРАНИЧЕНИЙ В ЗАДАЧЕ ПЕРЕНОСА ВЫЧИСЛИТЕЛЬНОЙ НАГРУЗКИ В РСАПР КАК УСЛОВИЕ ПОВЫШЕНИЯ
КАЧЕСТВА ПРОЕКТИРОВАНИЯ
Э.В. Мельник, И.Б. Сафроненкова, А.Б. Клименко
В работе представлен анализ особенностей функционирования систем автоматизированного проектирования (САПР) в «туманной» среде. Проведенный анализ показал, что приоритетным в РСАПР является получение как можно более качественного проектного решения, которое затем будет отражено в материальных объектах. Проведен анализ зависимостей качества решений от числа итераций в поисковых эволюционных алгоритмах. Сделан вывод о том, что возможность получить более качественное решение возрастает с увеличением числа итераций. На основании представленных выводов, сформулированы дополнительные ограничения, при которых возможно повысить качество проектного решения оптимизационной задачи САПР посредством максимизации выполненной работы за ограниченное время. Для выполнения данных условий предложено использовать метод решения задачи переноса вычислительной нагрузки на основе онтологического анализа.
Ключевые слова: РСАПР, качество решения, «туманные» вычисления, «облачные» вычисления, перенос вычислительной нагрузки, онтология.
Одной из главных целей автоматизированного проектирования РЭА и ЭВА является повышения качества изделий, что при современном уровне требований к выпускаемой продукции, невозможно достичь без использования САПР [1]. Более того, поскольку проектирование РЭА и ЭВА является сложным многоэтапным процессом, в него вовлекаются большие коллективы специалистов, зачастую географически распределенные. Децентрализация архитектуры САПР и переход к распределенным системам проектирования, позволяет решить вопросы коммуникационного обмена между коллективами разработчиков для решения общей задачи [2].
357
