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

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

В научных кругах практически все знают о феномене “Полярное сияние”. Это необычное свечение, которое возникает в результате столкновения заряженных частиц солнечного ветра с верхними слоями атмосферы Земли, вызванное взаимодействием молекул и атомов (электронами и протонами) [6, с. 250]. Оно может принимать форму колец различных деформаций в северном или южном полушарии [1, с. 409-499].

Для прогнозирования геофизических параметров в области аврорального овала (очередной термин «полярного сияния»), используются математические модели, которые основываются на параметрах солнечного ветра и магнитного поля, полученных с помощью спутников ACE и DSCOVR в режиме реального времени. Одной из известных эмпирических моделей, разработанных Патриком Ньюэллом и коллегами из университета Джонса Хопкинса в 2009 году, является модель OVATION. Она предполагает линейную зависимость между интенсивностью полярных сияний и вероятностью их наблюдения невооруженным глазом [2, с. 108–118].

За годы развития ПО, разработчиками удалось придумать надежные подходы для проектирования архитектур [3]. Ниже представлены наиболее популярные из них:

• Многослойная архитектура (Layered Architecture);
  
• Многоуровневая архитектура (Tiered Architecture);
  
• Сервис-ориентированная архитектура (Service Oriented Architecture — SOA);
  
• Микросервисная архитектура (Microservice Architecture).
  

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

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

Актуальность

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

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

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

Улучшение модулем веб-сервиса “Aurora-Forecast”, а также предоставление анализа данных, использующиеся в работе данного алгоритма для визуализации геофизических данных прогностики в области аврорального овала, и модернизация компьютерных моделей, позволяющих проводить их срочный геопространственный анализ является актуальной
задачей, решение которой способно как значимо повлиять на изучения в области фундаментальных исследований, так и нацеленных на поддержку принятия дополнительной безопасности в управлении различными техническими объектами в Арктическом регионе и спутников от радиомагнитных влияний. Также предоставляется подробно описаные модели данных и архитектура данного ПО в этой области.

Цель, задачи, материалы и методы

Основная цель данной работы – это анализ архитектур ИС, выбор и обоснование выбора, описание и обзор её интеграции с веб-платформой по прогнозированию полярных сияний на цифровом глобусе.

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

В соответствие с целью описаной выше можно обозначить следующие основные задачи работы:

1. Анализ и сравнение архитектур информационных систем;
   
2. Анализ её интеграции с веб-платформой;
   
3. Описание используемой модели данных, логическая и физическая схема данных.
   

Научная новизна

В качестве выбранного архитектурного подхода была выбрана клиент-серверная архитектура. Опишем её более подробнее.

Современная архитектура программного обеспечения становится все более сложной, поэтому многие компании и разработчики в последнее время ориентируются на многоуровневую архитектуру (МУА). Этот подход позволяет разделить комплексное программное обеспечение на уровни и организовать взаимодействие между ними на основе принципа “клиент-сервер”. МУА может иметь разное количество уровней, в зависимости от специфических потребностей проекта.

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

Преимущества одноуровневой системы:

1. Простота развертывания;
   
2. Высокая скорость связи;
   
3. Не требует межсистемного взаимодействия.
   

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

n-уровневые системы и их преимущества:

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

Двухуровневые системы и их принцип работы:

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

Примеры использования разных систем:

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

Преимущества n-уровневых систем:

- Увеличение масштабируемости программы;

- Надежность и гибкость контроля доступа к данным;

- Высокая производительность и быстродействие;

- Легкость поддержки и разработки новых функций и возможностей.

Выбор архитектуры и его обоснование

Реализация разработанной программной системы лежит на основе характерной для веб-приложений клиент-серверной архитектуры, реализуемая посредством шаблона проектирования MVC (Model-View-Controller) с отделением бизнес-логики и данных от пользовательского интерфейса (рисунок 1). В настоящее время указанный архитектурный паттерн поддерживается многими инструментами веб-разработки, однако в работе реализация предложенных решений выполнена на базе фреймворка Django, представляющего собой фреймворк со множеством встроенных высокоуровневых возможностей и стандартизованной структурой разрабатываемых приложений.

Управляющая логика приложения задана на уровне представлений, которые, в свою очередь, размещаются в файле Views.py и задаются набором функций с входным аргументом типа HttpRequest и возвращаемым значением вида HttpResponse. Каждое представление прикрепляется к проекту соответствующей ссылкой в файле URL.py (компонент, известный как диспетчер URL). При получении пользовательского запроса контроллер через файл URL.py определяет, какой серверный ресурс должен быть использован для формирования отклика, и перенаправляет параметры запроса соответствующему представлению.

В Django файл Views.py выполняет роль контроллера, обрабатывающего поступивший запрос и формирующего ответ, вид которого для пользователя определяется шаблоном. Шаблон содержит статический HTML и динамические данные, подстановка которых в результат описывается с помощью соответствующих программных инструкций. Вызовы шаблона осуществляются непосредственно из функции в представлении с помощью метода render пакета django.shortcuts, который выполняет указанный шаблон и возвращает экземпляр объекта HttpResponse с полученным содержимым.

Задачей клиентских сценариев является рендеринг этих данных в виде набора пространственных изображений. Взаимодействие между уровнями осуществляется по протоколу HTTP(s) посредством обмена сообщениями. Базовые картографические данные передаются по HTTP-протоколу с сервера WMS (Web Map Service), при этом визуализируемые данные представлены в формате JSON (JavaScript Object Notation).

Рисунок 1. Архитектура программной системы визуализации геофизических параметров для прогнозирования полярных сияний

Интеграция архитектуры с веб-платформой.

Система функционирует по следующему протоколу на протяжении всего жизненного цикла приложения. Фоновые процессы на серверной стороне осуществляют обработку полученных точек координат в евклидовом пространстве, формируя диаграмму Вороного. Сеансы соединения с сервисами провайдеров устанавливаются с интервалом в 5 минут в соответствии с заданным протоколом. Далее, точки обрабатываются на серверной стороне путем преобразования их в JSON-массив [4], содержащий координаты и атрибутивные значения. Создание диаграммы Вороного на трехмерной модели объекта осуществляется при обработке данных GeoJSON файла, используя Евклидово пространство.

Модуль обработки точек получает на вход массив пространственных координат и атрибутивных значений. Здесь происходит интерполяция данных в соответствии с алгоритмом диаграммы Вороного и формируется множество изолиний. Сервер отправляет поток JSON-данных клиенту в виде набора изолиний. Дальнейшая обработка данных происходит на клиентской стороне веб-приложения, используя клиент-серверную архитектуру и сценарии [5].

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

Кроме того, в то же время виртуальный глобус начинает отображаться и базовый слой рендерится на нем. Для этого используются различные классы из ArcGIS API for JS, которые отвечают за создание и визуализацию глобуса в окне браузера, а также за запрос данных базового слоя к WMS-серверу.

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

Описание используемой модели данных.

Исходными данными являются данные формата GeoJSON, предназначенные для хранения географических структур данных, основанных на JSON, полученные от сервера в процессе выполнения к нему запроса. На их основе выполняется построение неструктурированной сетки многоугольников (плоскостей), полученной с использованием системы соседства (для двух точек на плоскости строится перпендикуляр, являющийся стенкой для двух полуплоскостей) в процессе триангуляции Делоне, данные полуплоскости образуют множество плоскостей O(n*log(n)), создавая необходимую диаграмму Вороного.

Используемая модель данных является множеством координатных точек, где все элементы уникальны и неупорядоченны. Данное множество точек координат (x, y) содержит уникальный код станции с камерой, фиксирующей северные сияния в небе в формате трёх символов (“ABG”), а также дополнительные атрибутивные северной составляющей.

Так как входные данные GeoJSON файла содержит массив координат с типом Feature Collection, он представляет из себя список коллекций функций, где содержаться свойства полигонов и точки координат. Программно обработка данных коллекций реализована при помощи подклассов Polygon класса Geometry, и объекта FeatureCollection, который содержит в себе свойство Feature библиотеки GeoJSON. В объекте geometry соответственно хранятся исходные точки координат, а в объекте Feature необходимые для этих точек свойства (уникальный код станции и значение северной составляющей).

Схема данных логическая и физическая

Обобщенная логическая схема функционирования программного модуля формирования диаграммы Вороного приведена на рисунке 2.

Рисунок 2. Структурная логическая схема модуля построения диаграммы Вороного

Обобщенная физическая схема функционирования программного модуля формирования диаграммы Вороного приведена на рисунке 3.

Рисунок 3. Обобщенная физическая схема функционирования модуля диаграммы Вороного

Заключение

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

1. Проанализированы архитектуры информационных систем;
   
2. Описана интеграция архитектуры с веб структурой ПО;
   
3. Описаны используемые в ПО модели данных.
   

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