Automatic diagnostics of technical equipment of geographically distributed automated radio monitoring system

Full Text

Введение

 Развитие современных технологий в настоящее время позволило автоматизировать все основные процессы радиоконтроля и создать на основе применения дистанционно управляемых цифровых радиоприемных устройств и пеленгаторов территориально-распределённые системы, которые способны выполнять задачи радиоконтроля на национальном уровне как в интересах радиочастотной службы, так и в сфере обеспечения государственной безопасности [1, 2]. При этом нельзя не подчеркнуть значимость контроля состояния самих технических средств (далее – ТС) автоматизированной системы радиоконтроля (далее – АСР), таких как цифровые радиоприемные устройства, автоматические радиопеленгаторы, опорно-поворотные устройства, блоки электропитания и передачи данных и т.п., так как именно от их исправности зависит выполнение системой основных функций радиоконтроля. Диагностика состояния технических средств, входящих в состав системы, является важной частью работы АСР.

Одним из возможных вариантов анализа состояния АСР, рассматриваемых на примере специального математического обеспечения АРМАДА (далее – СМО-АРМАДА), является подсистема самодиагностики, которая в реальном времени ведет контроль за состоянием технических средств отдельно взятой удаленной станции радиоконтроля через работающее на ЭВМ-контроллере аппаратуры приложение диагностики. Для получения диагностических сведений с аппаратуры операторам локальных и удалённых (работающих в сети АСР) автоматизированных рабочих мест необходимо подключиться при помощи браузера к соответствующему web-серверу ЭВМ-контроллера. Такой подход к организации подсистемы диагностики рассматривался в работах [3, 4]. Подсистема имеет децентрализованную организацию, и позволяет контролировать состояние радиоаппаратуры как при автономной работе станции, так и при её работе в составе распределённой АСР.

В то же время «децентрализованная» подсистема не предоставляет функционал одновременного мониторинга всего парка действующего оборудования АСР. Так, например, оператору Центра Управления АСР, развернутой на национальном уровне, для анализа состояния всей системы радиоконтроля необходимо подключиться к web-серверу диагностики каждой из станций, а после, переключаясь между вкладками браузера (их количество пропорционально количеству радиоконтрольного оборудования), в ручном режиме производить диагностику. Помимо этого, оценка и анализ собранной телеметрии за время наблюдения недостаточно удобны из-за отсутствия возможности отображения детальной истории значений по каждому отдельному параметру.

Другим возможным подходом к организации подсистемы является использование «централизованного» варианта диагностики технических средств радиоконтроля, который основан на мониторинге оборудования посредством единого сервера диагностики, расположенного в Центре Управления АСР. Такой подход предпочтителен, если в системе развернуты дистанционно управляемые станции радиоконтроля, которые в своей локальной подсети не имеют компьютеров рабочих мест операторов, а работу технических средств радиоконтроля организует Центр управления.

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

Диагностика ТС радиоконтроля с использованием центрального сервера

 «Централизованный» подход предполагает осуществление мониторинга технических средств радиоконтроля центральным сервером диагностики в автоматическом режиме посредством подключения к ЭВМ-контроллерам каждой станции, агрегируя все данные диагностики в Центре Управления. При использовании данного подхода для получения диагностических данных операторы, как Центра Управления, так и станций радиоконтроля, могут подключаться к центральному серверу диагностики, где сосредоточена вся необходимая информация. Данный подход продемонстрирован на схеме рис. 1. 

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

На рис. 1 представлен пример системы радиоконтроля, которая состоит из двух станций и Центра Управления, в состав которой входят [3, 5]:

1. Технические средства радиоконтроля, предназначенные для выполнения задач радиоконтроля, в том числе:
   
   • выполнения панорамного анализа спектра в режиме реального времени;
   • осуществления контроля радиоканалов;
   • осуществления записи радиосигналов для последующего анализа;
   • измерения напряжённости поля источников радиоизлучения;
   • пеленгования и определения местоположения источников радиоизлучения.

2. ЭВМ-контроллеры аппаратуры, предназначенные для взаимодействия с техническими средствами радиоконтроля через драйвер аппаратуры с последующим предоставлением доступа к управлению ими через систему АСР.

3. Автоматизированные рабочие места (далее – АРМ) операторов для подключения к системе АСР, посредством которой происходит управление сетью технических средств радиоконтроля через соответствующие ЭВМ-контроллеры.

Алгоритм диагностики технических средств радиоконтроля:

1. Центральный сервер диагностики в автоматическом режиме собирает телеметрию со всей аппаратуры, подключенной в сеть АСР, подключаясь к ней через соответствующие ЭВМ-контроллеры.
2. ЭВМ-контроллеры аппаратуры, подключаясь к ТС радиоконтроля «напрямую» (в локальной подсети станции), предоставляют диагностическую информацию удалённому центральному серверу диагностики по запросам в сети АСР.
3. Центральный сервер диагностики обрабатывает и формализует полученную информацию, предоставляя её пользователям подсистемы посредством web-интерфейса.
4. Пользователи (операторы АРМ АСР) подключаются к центральному серверу диагностики для получения требуемой информации.

Такой подход даёт возможность проведения диагностики из «единой точки», объединив все средства радиоконтроля под управлением координирующей подсистемы с доступом из любого узла АСР через web-интерфейс центрального сервера. Его достоинствами являются:

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

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

Основные проблемы диагностики оборудования радиоконтроля

 Техническими средствами радиоконтроля АСР являются радиотехнические средства, в том числе аппаратура связи и передачи данных.

При проектировании и разработке структуры технических средств обычно применяется модульный метод, который позволяет получать устройства с разными характеристиками путём комбинирования и связи различных блоков в едином устройстве [5, 6]. При этом объектами диагностики в каждом устройстве радиоконтроля являются модули из его состава, каждый из которых должен возвращать необходимые параметры, в том числе:

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

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

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

 Динамическая генерация структуры объектов диагностики

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

В СМО-АРМАДА в качестве основы для управления диагностикой технических средств радиоконтроля используется протокол SNMP (Simple Network Management Protocol), как наиболее распространенный протокол для диагностики сетевых устройств, работающих в стеке протоколов TCP/IP [7].

Реализация механизма динамической генерации объектов диагностики в рамках протокола SNMP возможна с использованием так называемых SNMP Extension Agent (SNMP агентов расширения), которые исполняют роль прослоек-коннекторов между основным SNMP-агентом (SNMP-мастером или SNMP-службой в операционных системах Windows) и объектами диагностики (модулями радиоаппаратуры) и позволяют выполнять необходимые запросы к драйверу аппаратуры с последующим предоставлением диагностических данных по требованию [8].

Алгоритм работы агента расширения:

1. Обращение к драйверу аппаратуры для получения списка модулей и списка параметров диагностики каждого из модулей.
2. Формирование пространства доступных параметров для чтения и управления в базе данных MIB (Management Information Base) путём последовательного линейного присвоения Object Identifier ветви каждому доступному параметру.
3. Формирование файла-описания структуры *.mib на основе динамически сформированной базы данных MIB, что означает автоматическое генерирование текстового имени параметра каждому доступному числовому идентификатору. Для упрощения дальнейшей работы присваиваемое текстовое имя параметра содержит следующую информацию (формируется также за счёт данных от драйвера аппаратуры):
   
   • числовой номер модуля аппаратуры;
   • числовой номер типа параметра (например, входное напряжение, токи и другие);
   • строка адреса модуля.

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

 

Таблица 1. Динамическое формирование структуры базы MIB

ircosRoot0x4x00	.1.3.6.1.4.1.44664.1.5.1.1.1.0	Температура платы «T7»
ircosRoot0x66x00	.1.3.6.1.4.1.44664.1.5.1.1.2.0	Входное напряжение платы «T7»
ircosRoot0x60x00	.1.3.6.1.4.1.44664.1.5.1.1.3.0	Потребляемый платой «T7» ток

 

Дальнейшая работа заключается в отправке SNMP-запроса на IP-адрес удалённого ЭВМ-контроллера аппаратуры (используя SNMP менеджер в Центре Управления АСР). Такой запрос возможно осуществить двумя доступными способами: по OID (Object Identifier) требуемого параметра и по текстовому наименованию параметра.

Обращение по OID в рамках динамического генерирования структуры объектов диагностики на узле возможно лишь при условии, что SNMP менеджеру в Центре Управления точно и однозначно известно, какой параметр в текущий момент находится «за данным» идентификатором. При очередной инициализации SNMP агента расширения или смене аппаратуры (как и модуля аппаратуры) на узле, данный OID может быть присвоен другому блоку, о чем Центр Управления не будет уведомлён – это вызовет некорректное отображение параметров в Центре Управления и сбой подсистемы диагностики.

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

Существует два возможных пути решения данной проблемы:

• осуществлять постоянный обмен файлами-описания базы данных MIB между удалённым оборудованием и Центром Управления АСР с последующей постоянной подменой этих файлов при выполнении SNMP-запроса методом «точка-точка»;
• осуществлять разыменование параметров на удалённом оборудовании и предоставлять Центру Управления лишь таблицу связи «Имя ó OID» с привязкой к определённому IP-адресу.

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

Для реализации второго подхода в СМО-АРМАДА существует утилита «Translator», при обращении к которой Центр Управления получает соответствие имени анализируемого параметра и его OID, назначенный динамически в пределах узла. Схема такого взаимодействия представлена на рис. 2.

Алгоритм взаимодействия с утилитой «Translator»:

1. Центр Управления обращается по IP-адресу ЭВМ-контроллера аппаратуры к утилите «Translator» для получения таблицы связи статических имён параметров и динамически назначенных OID на узле.
2. Утилита формирует таблицу связей в формате, удобном для передачи.
3. Центр Управления формирует из полученной таблицы SNMP-запросы, необходимые для диагностики радиоаппаратуры.

Представленный механизм позволяет исключить неопределённость динамического назначения OID, так как Центр Управления будет формировать SNMP-запросы с использованием не встроенного разыменования через *.mib файл, а с использованием разыменования через данные от Транслятора, причем индивидуально для каждого узла.

Рис. 2. Функциональная схема взаимодействия по протоколу SNMP ТС и Центра Управления

Реализация диагностики ТС радиоконтроля через Центральный сервер диагностики при динамически изменяемой структуре оборудования

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

1. Автоматически обнаруживать территориально-распределённое радиоприёмное оборудование в сети АСР.
2. Организовывать связь подсистемы диагностики и утилиты «Translator» на уровне приложений (при условии связи Центра Управления и удалённой аппаратуры в сети АСР).
3. Интегрировать команды управления утилитой «Translator» в подсистему диагностики с их автоматическим вызовом через заданный интервал времени для поддержки актуальности таблицы соответствия на стороне Центра Управления АСР.
4. В автоматическом режиме создавать элементы данных SNMP по полученной таблице соответствия.
5. Через полученные элементы данных диагностировать сеть распределённой аппаратуры радиоконтроля, отслеживая и контролируя выход получаемых значений за допустимые границы.

С учётом сложности архитектуры сети радиоконтроля, а также сложности интеграции с существующим радиоконтрольным оборудованием и программным обеспечением для него, разработка нового кроссплатформенного web-сервера является ресурсоёмкой задачей. Вследствие этого было принято решение использования стороннего свободно-распространяемого программного обеспечения с открытым исходным кодом для осуществления возможности «бесшовной» интеграции систем диагностики и АСР.

Одной из наиболее популярных свободно распространяемых систем для распределённого мониторинга и диагностики IT-систем любых масштабов является ПО Zabbix [9].

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

1. Идентичность сетевых архитектур АСР и Zabbix.
2. Масштабируемость подсистемы диагностики на большое число узлов.
3. Шифрование передаваемого по сети трафика.
4. Поддержка стороннего ПО для расширения возможности мониторинга и диагностики [9].

Подсистема диагностики может предоставить персоналу АСР следующие возможности:

1. Диагностика распределённой системы радиоконтроля в реальном времени.
2. Графическое отображение получаемых данных.
3. Автоматический контроль состояния АСР при помощи заданных границ каждому из параметров.
4. Оповещение о нештатной ситуации.
5. Простой процесс подключения новых станций радиоконтроля к подсистеме диагностики.

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

Пользовательские параметры имеют следующий синтаксис:

Создание пользовательского параметра в Zabbix-агенте позволяет ссылаться на уникальный ключ из Zabbix-сервера. При обращении к узлу по ключу, Zabbix-агент выполняет соответствующую удалённую команду. Удалённой командой в данном случае является обращение к транслятору для получения таблицы соответствия.

Для передачи таблицы соответствия между Zabbix-сервером и Zabbix-агентом в подсистеме диагностики СМО-АРМАДА используется формат JSON (JavaScript Object Notation), который в последнее время стал наиболее популярным форматом для обмена данными между серверами и клиентами [10].

Помимо таблицы соответствия «Имя ó OID» в подсистему диагностики также можно передавать следующие параметры:

• понятные конечному пользователю имена элементов данных и их развёрнутое описание;
• единицы измерения полученных значений;
• тэг объекта диагностики для группирования параметров.

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

Получив структуру оборудования радиоконтроля на ЭВМ-контроллере аппаратуры через разработанный транслятор и настроив взаимосвязь транслятора и Zabbix-агента на узле сети, необходимо выполнить обработку пришедших данных на Zabbix-сервере.

Zabbix-сервер имеет встроенный SNMP-менеджер для опроса полученных соответствий «Имя ó OID», поэтому необходимо лишь создать соответствующий элемент данных. Однако заранее неизвестно, какие элементы данных должны быть созданы на определённом узле сети, так как к ЭВМ-контроллеру аппаратуры может быть подключена различная аппаратура радиоконтроля, поэтому «прямое» добавление наблюдаемого параметра не считается верным подходом.

Для разрешения возникшей ситуации и гибкого добавления диагностируемых параметров в Zabbix-сервере предусмотрены так называемые правила обнаружения, разделяемые на два типа:

• обнаружение сети – обнаружение узлов сети Zabbix;
• низкоуровневое обнаружение – обнаружение на основе определённых элементов данных других элементов данных, триггеров и графиков [9].

На основе представленных типов предложены два алгоритма, которые позволяют осуществлять автоматизированную диагностику ТС радиоконтроля в описываемой системе:

1. Алгоритм поиска технических средств радиоконтроля в сети АСР (рис. 3).

Рис. 3. Алгоритм обнаружения технических средств радиоконтроля

Данный алгоритм работает следующим образом:

• при вводе в эксплуатацию новой станции радиоконтроля на ЭВМ-контроллер аппаратуры устанавливается утилита «Translator» из состава СМО-АРМАДА;
• станцию подключают к внутренней сети АСР;
• сервер диагностики в непрерывном режиме сканирует всю сеть АСР и находит новую станцию радиоконтроля, в частности находит ЭВМ-контроллер радиоприёмной аппаратуры;
• сервер диагностики производит проверку (проверка №1, рис. 3), по которой определяет принадлежность найденной станции радиоконтроля и добавляет ЭВМ-контроллер аппаратуры в подсистему диагностики (действие №1, рис. 3) для выполнения дальнейших действий.

2. Алгоритм обнаружения диагностируемых параметров модулей радиоконтрольного оборудования (рис. 4).

Данный алгоритм работает следующим образом:

• после того, как ЭВМ-контроллер добавлен в подсистему диагностики, модуль сети проверяет наличие на узле драйвера взаимодействия с аппаратурой и работу SNMP-службы (проверка №2, рис. 3). Если все критерии выполняются, то модуль сети присоединяет единый шаблон диагностики (ЕШД) ТС радиоконтроля (действие №2, рис. 3);
• добавленный к узлу сети шаблон содержит модули обнаружения параметров объектов диагностики, которые начинают обращаться через механизм Zabbix-get к транслятору для получения структуры аппаратуры радиоконтроля;
• по полученной структуре каждый модуль обнаружения через прототипы элементов данных и прототипы триггеров формирует реальные элементы данных и триггеры к ним;
• элементы данных обращаются через SNMP-менеджер Центра Управления к ЭВМ-контроллерам аппаратуры для получения требуемых значений параметров;
• полученные значения становятся доступны для отображения в web-интерфейсе Zabbix-сервера, а также для автоматического контроля соответствующими триггерами.

Рис. 4. Алгоритм обнаружения параметров модулей радиоконтрольного оборудования

Рассмотрим, как выполняется диагностика технических средств радиоконтроля через web-интерфейс системы Zabbix на примере диагностики цифрового радиоприёмного устройства АРГАМАК-ИС. Внешний вид радиоприёмного устройства представлен на рис. 5 [11].

ЦРПУ АРГАМАК-ИС предназначен для визуального наблюдения и измерения параметров спектров радиосигналов в частотном диапазоне от 0,009 до 8000 МГц в составе комплексов радиоконтроля [11].

На рис. 6 показан пример обнаруженных элементов данных подключенного радиоприёмного устройства АРГАМАК-ИС.

Рис. 5. ЦРПУ АРГАМАК-ИС

Рис. 6. Диагностика радиоприёмного устройства АРГАМАК-ИС

Как видим, подсистемой диагностики были обнаружены следующие модули ЦРПУ:

• модуль цифровой обработки сигналов (модуль «Т7»);
• модуль ввода питания (модуль «BMPU»);
• модуль коммутации (модуль «Commutator IS»);
• кросс-модуль (модуль «Main»).

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

• входное напряжение модуля – 32.13 В;
• входное напряжение первого канала – 29.7 В;
• ток нагрузки по выходу второго канала – 1179 мА;
• температура модуля – 44 и другие.

Zabbix-сервер в автоматическом режиме строит графики истории изменения параметров от времени по полученным значениям от элементов данных. На рис. 7 представлены графические зависимости полученных параметров для модуля цифровой обработки сигналов.

Рис. 7. Диагностика модуля цифровой обработки сигналов радиоприёмного устройства АРГАМАК-ИС

На данном рисунке показан «комплексный экран» диагностики платы «Т7», на котором отображены графики четырёх параметров:

• входное напряжение платы (левый верхний график);
• температура платы (правый верхний график);
• потребляемый платой ток (левый нижний график);
• температура термостатированного опорного генератора (правый нижний график).

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

Web-интерфейс, хотя и позволяет производить диагностику оборудования в реальном времени, однако постоянное наблюдение за Панелью в интерфейсе подсистемы при работе оператора АСР не является его основной задачей, так как это не позволяет концентрировать внимание на радиоконтрольных задачах.

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

Такими вариантами оповещений могут быть:

• отправка SMS-уведомлений о выходе из строя радиоконтрольного оборудования и его модулей;
• отправка уведомлений на электронную почту при прогнозировании возможной неисправности аппаратуры с течением времени;
• вывод уведомлений на экране автоматизированного рабочего места оператора при помощи получения сообщений в мессенджере;
• другие способы оповещений через использование внешних утилит и API сторонних систем.

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

 Заключение

 На основе предложенного комбинированного подхода к диагностике технических средств радиоконтроля была реализована и внедрена в программное обеспечение СМО-АРМАДА подсистема диагностики. Она позволила:

• осуществлять диагностику территориально-распределённых технических средств радиоконтроля из Центра Управления АСР;
• получать данные о состоянии аппаратуры радиоконтроля в реальном времени;
• строить графические зависимости по каждому параметру с целью детальной оценки и прогнозирования неисправностей аппаратуры;
• при необходимости осуществлять индивидуальную настройку подсистемы под каждый объект диагностики;
• автоматически подключать новые узлы сети и технические средства радиоконтроля;
• извещать операторов о неисправностях ТС радиоконтроля в реальном времени с привязкой к IP-адресу ЭВМ-контроллера аппаратуры.

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

_________________________________

© Жупиков М.В., Баркалов С.В., Алексеев Д.А., Токарев А.Б., 2025

About the authors

Maksim V. Zhupikov

JC «IRCOS»

Author for correspondence.
Email: jupikovmv@ircoc.vrn.ru

Software Engineer

Russian Federation, 101B Rabochiy pr., Voronezh 394049, Russia

Sergey V. Barkalov

JC «IRCOS»

Email: barkalovsv@ircoc.vrn.ru

Senior Software Engineer

Russian Federation, 101B Rabochiy pr., Voronezh 394049, Russia

Dmitriy A. Alekseyev

JC «IRCOS»

Email: alekseevda@ircoc.vrn.ru

Deputy Director

Russian Federation, 101B Rabochiy pr., Voronezh 394049, Russia

Anton B. Tokarev

JC «IRCOS»; Voronezh State Technical University

Email: TokarevAB@ircoc.vrn.ru
ORCID iD: 0000-0002-2621-4336

Senior Staff Scientist; Dr. Sc. (Technical), Associate Professor, Professor

Russian Federation, 101B Rabochiy pr., Voronezh 394049, Russia; 84 20-letiya Oktyabrya str., Voronezh 394006, Russia

References

Supplementary files