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

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

Одно из направлений развития программного комплекса Sonix+ - создание сервисов для организации удобной работы пользователей.

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

Изначально взаимодействие WebSonix с устройствами Sonix+ обеспечивало устройство CChannel. К сожалению протокол, применяемый в CChannel, а так же некоторые особенности устройства, значительно ограничивают скорость работы WebSonix.

Для развития интерфейса Sonix+ тоже потребовалась дополнительная функциональность, а именно создание протокола для обмена данными между 64х и 32х битными модулями Sonix+.

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

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

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

В качестве базового механизма для проектирования PyChannel подошёл Message-Oriented Middleware.

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

Для обмена данными потребуются следующие виды сообщений:

• COMMAND - Запрос на выполнение определённых действий на уровне одного физического устройства (управляющего компьютера, или сервера);
• REPLY - Сообщение с результатом выполнения процедуры (скорее всего данный тип сообщения необходим исключительно для синхронных запросов, а при работе в асинхронном режиме будет более удобным обмениваться данными с помощью команд, так как ожидание ответа вызовет блокировку устройства на время выполнения команды);
• ERROR - Сообщение с ошибкой, возникшей в процессе выполнения процедуры (повторяет идеологию REPLY, за исключением того, что клиент вместо возвращения данных вызывает исключение);
• REGISTER - Данное сообщение необходимо прежде всего для составления таблицы маршрутизации, которая содержит в себе указания о том, по какому адресу нужно отправлять сообщения исходя из имени устройства.

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

Первоначально PyChannel разрабатывался как замена CChannel. Данное устройство должно было значительно увеличить скорость обмена данными между модулями Sonix+ и Websonix.

Основным ограничением CChannel была возможность обработки единовременно только одного запроса от WebSonix. Так как WebSonix делает множество запросов к устройствам Sonix+ при этом некоторые запросы (создание гистограммы спектра с текущими измерениями) могут требовать большого времени (до нескольких минут). В итоге это приводило к длительной загрузке web страниц.

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

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

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

Сейчас в ЛНФ активно развиваются устройства, которые позволяют отображать данные с научной установки для пользователей в высоком разрешении<a href=«#citeproc_bib_item_5»>[5]</a>. Чем выше разрешение для отображения информации, тем больше оперативной памяти нужно приложению для работы.

Программа для отображения данных SpectraViewer отлично работает отдельно от Sonix+ в 64х-битном режиме. Однако базовый протокол Sonix+ поддерживают работу только с 32х-битными приложениями, что ограничивает количество используемой памяти до 2Гб<a href=«#citeproc_bib_item_6»>[6]</a>. Это уменьшает максимальное возможное разрешение, в котором интерфейс Sonix+ может отображать данные, накопленные во время измерения.

Для обхода данного ограничения было предложено транслировать вызовы из интерфейса, работающего в режиме 64х-битного приложения через PyChannel в базовый протокол Sonix+.

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

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

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

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

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

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

Функции PyChannel востребованы не только на управляющих компьютерах, но и серверах.

Таким образом PyChannel:

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