Изобретение относится к области информационно-измерительной техники, а именно к автоматизированным системам управления и контроля робототехническими комплексами (далее - РК), и может найти применение при передаче информации от различных пилотируемых и беспилотных летательных аппаратов (далее - БпЛА) в единую наземную (стационарную/мобильную), так и в воздушную станцию управления (далее - СУ).
С развитием технологий робототехнических комплексов и беспилотных летательных аппаратов - в частности, данные объекты получают все более широкое применение в современной технике.
Для целей настоящего описания под термином «робототехнический комплекс» понимают комплекс, состоящий из одного или нескольких роботов, их рабочих органов и любых механизмов, оборудования, приборов или датчиков, обеспечивающих выполнение роботом функционального назначения (задания).
РК осуществляет связь со станцией управления. При этом обычно РК реализует функцию приема и передачи информации в конкретную СУ с использованием определенного уникального протокола, разработанного производителем РК.
Известен российский многофункциональный беспилотный комплекс «Орлан - 10», раскрытый на странице АО «Рособоронэкспорт» (режим доступа: http://roe.ru/catalog/vozdushno-kosmicheskie-sily/bespilotniki/orlan-10e/, дата обращения: ноябрь 2021 г.), предназначенный для ведения наблюдения за протяжёнными и локальными объектами в труднодоступной местности, в том числе при проведении поисковых и ремонтных работ, представляющий собой наземную станцию управления и БпЛА, разработанный российским предприятием ООО «Специальный технологический центр». БпЛА «Орлан - 10» оснащен дневными фото и видеокамерами, стабилизированным тепловизионным прибором, системой мониторинга сотовых сетей стандарта GSM или средствами обнаружения радиостанций тактического уровня. С точки зрения установленного программного обеспечения и способов передачи информации между БпЛА и наземной СУ, БпЛА «Орлан - 10» оснащен криптозащищенным командно-телеметрическим каналом, криптозащищенным каналом передачи фото - видео информации, для каждого из которых реализовано двухступенчатое помехоустойчивое кодирование.
Основными недостатками в части реализации обмена информацией между БпЛА и наземной СУ в данном комплексе являются:
- ограниченные функциональные возможности, поскольку у данной наземной СУ обеспечена возможность обмена информацией и подачи управляющих сигналов только к БПЛА, принадлежащего комплексу «Орлан-10»;
- ограниченное количество потенциально контролируемых БпЛА c одной наземной СУ - не более четырех;
- ограниченное общее количество контролируемых БпЛА с использованием наземного комплекса управления, состоящего из нескольких наземных СУ - для трех десятков БпЛА;
- сложность реализации, т.к. для обеспечения возможности управления более чем четырьмя БпЛА, необходимо создавать локальную сеть между несколькими наземными СУ.
Известны беспилотные комплексы «Альбатрос М1», «Альбатрос М5», раскрытые на странице компании «Альбатрос» (режим доступа: https://www.alb.aero/catalog/bpla-samoletnogo-tipa/albatros-m1/ - Альбатрос М1, https://www.alb.aero/catalog/bpla-samoletnogo-tipa/albatros-m5/ - Альбатрос М5, дата обращения: ноябрь 2021 г), отличительной особенностью которых являются модульность сборки БпЛА различного назначения и исполнение наземной СУ в компактном виде.
Основными недостатками в части реализации обмена информацией между БпЛА и наземной СУ в данных комплексах являются:
- ограниченные функциональные возможности, поскольку у наземной СУ обеспечена возможность обмена информацией и подачи управляющих сигналов только к БПЛА, принадлежащего комплексу «Альбатрос»;
- ограниченное количество потенциально контролируемых БпЛА c одной наземной СУ - не более четырех.
Современные реалии, возрастающее количество РК и масштабы выполняемых ими задач диктуют необходимость построения эффективного и унифицированного комплекса управления различными РК. Для понятия эффективности в данном конкретном случае можно сформулировать общие принципы, стремление к которым объединяет решение частных задач:
- единая станция управления, способная взаимодействовать с различными РК;
- универсальные правила реализации взаимодействия станции управления с РК;
- гибкость по отношению к изменению условий задачи;
- быстрая адаптация при расширении функциональных возможностей РК во время жизненного цикла;
- обеспечение наименьшего уровня задействования человеческого ресурса при обеспечении решения;
- масштабируемость решения.
Технической проблемой, на решение которой направлено настоящее изобретение, является обеспечение функциональной возможности подключения РК разных типов и производителей к станции управления, а также включение в контур управления дополнительных робототехнических устройств в составе РК.
Технические результаты изобретения заключаются в:
- повышении эффективности управления РК различного типа и назначения;
- обеспечении унификации СУ, что позволяет в одной системе управления взаимодействовать с различными РК;
- расширении функциональных возможностей РК в части решаемых задач;
- упрощении процедуры подключения РК к СУ;
- минимизации ошибок при реализации контуров управления;
- обеспечение универсальности - при использовании предлагаемого способа РК может управляться как с наземной (стационарной/мобильной), так и с воздушной станции управления.
Данные технические результаты достигаются за счет того, что способ организации взаимодействия наземной станции управления с роботизированными комплексами методом унификации данных предусматривает при получении протокола информационного взаимодействия (далее - ПИВ) для конкретного робототехнического устройства разработку модуля поставщика данных, в котором происходит декодировка данного ПИВ, последующее создание модели «Json» для кодогенератора, после чего кодогенератор генерирует код приема/отправки структуры модели данных и саму структуру, на основе которой пишется основной код поставщика данных, и одновременно кодогенератор генерирует дополнительный модуль обработки данных для ПИВ на языке СУ для включения в состав станции управления (при этом дополнительный модуль обработки данных для ПИВ может отличаться от языка программирования поставщика данных).
Описание осуществления изобретения может быть использовано в качестве примера для лучшего понимания его сущности и изложено со ссылками на фигуры, приложенные к настоящему описанию. При этом приведенные ниже подробности призваны не ограничить сущность изобретения, а сделать ее более ясной.
Рассмотрим реализацию предлагаемого способа на примере организации управления двумя различными типами БпЛА.
Предложенный способ может быть реализован в соответствии с фигурой 1, фигурой 2, на которых представлены общая схема передачи информации через поставщика данных и модули, разрабатываемые при подключении РК с ПИВ, соответственно, где:
1 - БпЛА тип 1;
2 - БпЛА тип 2;
3 - поставщик данных 1;
4 - поставщик данных 2;
5 - универсальная НСУ;
6 - ПИВ;
7 - модуль поставщика данных для ПИВ (разрабатывается на языке программирования разработчика);
8 - декодирование ПИВ;
9 - основной код (заполнение структуры, фильтрация, трансформация);
10 - структура модели данных;
11 - код приема/отправки структуры модели данных;
12 - модель «Json» на основе ПИВ;
13 - кодогенератор;
14 - генерирование кода;
15 - сервер данных НСУ;
16 - дополнительный модуль обработки данных для ПИВ (разрабатывается на языке программирования НСУ);
17 - неизменяемый модуль НСУ (основной код приложения, не зависит от ПИВ);
18 - код приема/отправки структуры модели данных;
19 - код подготовки данных для систем отображения информации;
20 - код формирования базы данных;
21 - структура модели данных;
22 - часть кода написанная разработчиком;
23 - сгенерированная часть кода;
24 - часть кода, разрабатываемая вручную.
Решение задачи производится следующим способом: в систему связи БпЛА - наземная СУ вводится модуль поставщика данных, для унифицирования телеметрической информации, и дополнительный модуль обработки информации в ПО наземной станции управления (далее - НСУ).
Сами поставщики данных являются дополнительным набором сервисов, пересылающим данные по сети. Поставщики данных являются уникальными для протокола информационного взаимодействия, принадлежащего конкретному типу БпЛА.
Под телеметрической информацией понимаем всю совокупность данных приходящих/отправляемых НСУ.
Разработка модуля поставщика данных включает:
1) при получении ПИВ для конкретного БпЛА написание разработчиком вручную части кода, в котором будет происходить декодирование ПИВ;
2) разработку модели «Json».
Для целей настоящего описания под термином «модель «Json» - понимают модель структуры данных в формате JavaScript Object Notation (JSON).
На основе модели «Json» автоматически генерируется код:
- структуры модели данных;
- приема/отправки сформированной структуры модели данных.
Для целей настоящего описания под термином «структура» понимают: совокупность переменных, объединенных одним именем, предоставляющая общепринятый способ совместного хранения информации.
Автоматическая генерация части кода позволяет минимизировать ошибки при реализации контура управления, посредством исключения человеческого фактора.
Далее разработчик, на основе сгенерированной структуры модели данных, вручную пишет основной код для заполнения структуры, фильтрации, трансформации и т.п.
Параллельно генерируется дополнительный модуль обработки данных для НСУ, в состав которого входят:
- структура модели данных;
- код приема/отправки структуры модели данных;
- код подготовки данных для систем отображения информации;
- код формирования базы данных.
При этом модуль поставщика данных генерируется на языке удобном разработчику, который может отличаться от языка программирования дополнительного модуля обработки данных принимаемых на НСУ.
Для разработки поставщика данных эффективно использование языка С++, ПО для НСУ чаще разрабатывается на языках Java или Scala.
Дополнительный модуль обработки данных, принимаемых на НСУ полностью генерируется кодогенератором, и также является уникальным для конкретного ПИВ.
На уровне основной логики НСУ происходит полное абстрагирование от того, какая конкретная реализация поставщика данных присылает телеметрию, интересует лишь содержимое структур.
Таким образом, при добавлении нового типа БпЛА необходимо разработать новый модуль поставщика данных, сгенерировать для него часть кода, и сгенерировать модуль обработки информации на языке программирования НСУ, но вносить изменения в основном коде ПО НСУ, а также писать новый код уже не требуется, что значительно упрощает процедуру подключения РК к СУ.
Процесс управления также сводится к обмену сообщениями между поставщиками данных и системой. За счет этого внутренняя логика системы полностью абстрагируется от того, какой поставщик данных будет обрабатывать команду и как он будет это делать. В свою очередь, поставщику данных также не нужно погружаться в логику работы системы, все что нужно это отправить сообщение управления. Это значительно повышает эффективность управления РК различного типа и назначения, обеспечивает унификацию СУ, расширяет функциональные возможности РК в части решаемых задач; минимизирует ошибки при реализации контуров управления и обеспечивает универсальность - при использовании предлагаемого способа РК может управляться как с наземной (стационарной/мобильной), так и с воздушной станции управления.
В итоге вместо использования нескольких НСУ, предлагаемый способ организации взаимодействия наземной станции управления с роботизированными комплексами позволяет создать универсальную систему управления, эффективную для организации взаимодействия с различными типами РК, посредством унификации данных, передаваемых как с наземной, так и с воздушной станции управления.
Таким образом повышение эффективности управления РК различного типа и назначения, обеспечение унификации СУ, расширение функциональных возможностей РК в части решаемых задач, упрощение процедуры подключения РК к СУ, минимизация ошибок при реализации контуров управления, а также обеспечение универсальности достигается тем, что заявляемый способ организации взаимодействия наземной станции управления с роботизированными комплексами методом унификации данных предусматривает при получении протокола информационного взаимодействия для конкретного робототехнического устройства разработку модуля поставщика данных, в котором происходит декодировка данного ПИВ, последующее создание модели «Json» для кодогенератора, после чего кодогенератор генерирует код приема/отправки структуры модели данных и саму структуру, на основе которой пишется основной код поставщика данных, и одновременно кодогенератор генерирует дополнительный модуль обработки данных для ПИВ на языке СУ для включения в состав станции управления.
название | год | авторы | номер документа |
---|---|---|---|
Способ, система и устройство криптографической защиты каналов связи беспилотных авиационных комплексов | 2018 |
|
RU2704268C1 |
СПОСОБ ПОВЫШЕНИЯ ДОСТОВЕРНОСТИ КРИПТОГРАФИЧЕСКОЙ ЗАЩИТЫ КАНАЛОВ СВЯЗИ РОБОТОТЕХНИЧЕСКИХ КОМПЛЕКСОВ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ | 2023 |
|
RU2809279C1 |
СПОСОБ КРИПТОГРАФИЧЕСКОЙ ЗАЩИТЫ КАНАЛОВ СВЯЗИ МЕЖДУ НАЗЕМНОЙ СТАНЦИЕЙ УПРАВЛЕНИЯ И ОДНОВРЕМЕННО НЕСКОЛЬКИМИ УПРАВЛЯЕМЫМИ С НЕЕ БЕСПИЛОТНЫМИ ЛЕТАТЕЛЬНЫМИ АППАРАТАМИ | 2020 |
|
RU2730368C1 |
КОМБИНИРОВАННЫЙ СПОСОБ ОБНАРУЖЕНИЯ И ИДЕНТИФИКАЦИИ БЕСПИЛОТНЫХ ЛЕТАТЕЛЬНЫХ АППАРАТОВ | 2024 |
|
RU2824851C1 |
УСТРОЙСТВО ДИСТАНЦИОННОГО ИЗМЕРЕНИЯ ВЛАЖНОСТИ ПЛОСКОСЛОИСТЫХ ДИЭЛЕКТРИКОВ С ПОТЕРЯМИ | 2023 |
|
RU2804381C1 |
Способ наземной и воздушной доставки постановщиков радиопомех с использованием мобильного робототехнического комплекса радиоэлектронной борьбы | 2016 |
|
RU2652914C1 |
СПОСОБ И СИСТЕМА ФОРМИРОВАНИЯ МАРШРУТА ПЕРЕДВИЖЕНИЯ ОТ ДВЕРИ ДО ДВЕРИ | 2023 |
|
RU2807495C1 |
Способ доставки постановщиков помех и беспилотный робототехнический комплекс радиоэлектронной борьбы | 2016 |
|
RU2625206C1 |
СПОСОБ ОПРЕДЕЛЕНИЯ УСРЕДНЕННЫХ ЗНАЧЕНИЙ ГОРИЗОНТАЛЬНОЙ И ВЕРТИКАЛЬНОЙ СОСТАВЛЯЮЩИХ СКОРОСТИ ВЕТРА И ЕГО НАПРАВЛЕНИЯ | 2016 |
|
RU2616352C1 |
СПОСОБ ОПРЕДЕЛЕНИЯ УСРЕДНЕННЫХ ЗНАЧЕНИЙ ГОРИЗОНТАЛЬНОЙ И ВЕРТИКАЛЬНОЙ СОСТАВЛЯЮЩИХ СКОРОСТИ ВЕТРА И ЕГО НАПРАВЛЕНИЯ | 2016 |
|
RU2650094C2 |
Изобретение относится к способу унификации данных при взаимодействии наземной станции управления с роботизированными комплексами. Для этого разрабатывают модуль поставщика данных при получении протокола информационного взаимодействия (далее – ПИВ) для конкретного робототехнического устройства, декодируют данный ПИВ в модуле поставщика, создают модель «Json» для кодогенератора, который генерирует код приема/отправки структуры модели данных и саму структуру, на основе которой пишется основной код поставщика данных. Одновременно посредством кодогенератора генерируют дополнительный модуль обработки данных для ПИВ на языке станции управления для его включения в состав станции управления. Обеспечивается возможность подключения к станции управления РК разных типов и производителей, расширение функциональных возможностей РК. 2 ил.
Способ унификации данных при взаимодействии наземной станции управления с роботизированными комплексами, заключающийся в разработке модуля поставщика данных при получении протокола информационного взаимодействия (далее – ПИВ) для конкретного робототехнического устройства, при этом в модуле поставщика данных происходит декодировка данного ПИВ; последующем создании модели «Json» для кодогенератора, после чего кодогенератор генерирует код приема/отправки структуры модели данных и саму структуру, на основе которой пишется основной код поставщика данных, и одновременно кодогенератор генерирует дополнительный модуль обработки данных для ПИВ на языке СУ для включения в состав станции управления.
УСТРОЙСТВО ДЛЯ ОПРЕДЕЛЕНИЯ КООРДИНАТ ПОДВИЖНОГО ОБЪЕКТА С ИСПОЛЬЗОВАНИЕМ МАГНИТНОГО ПОЛЯ | 2019 |
|
RU2713456C1 |
СПОСОБ И СЛЕДЯЩАЯ СИСТЕМА ДЛЯ ОПРЕДЕЛЕНИЯ ПОЛОЖЕНИЯ И ОРИЕНТАЦИИ ПОДВИЖНОГО ОБЪЕКТА | 2000 |
|
RU2197013C2 |
СПОСОБ ОБНАРУЖЕНИЯ ПОДВОДНЫХ ФЕРРОМАГНИТНЫХ ОБЪЕКТОВ И СИСТЕМА ДЛЯ ОБНАРУЖЕНИЯ ПОДВОДНЫХ ФЕРРОМАГНИТНЫХ ОБЪЕКТОВ | 2015 |
|
RU2615050C2 |
СПОСОБ ОБНАРУЖЕНИЯ ПОДВОДНЫХ ФЕРРОМАГНИТНЫХ ОБЪЕКТОВ | 2005 |
|
RU2297650C2 |
СПОСОБ КООРДИНАЦИИ СЕТЕВОГО ОБМЕНА ДАННЫМИ | 2014 |
|
RU2610418C2 |
Авторы
Даты
2022-09-19—Публикация
2021-11-24—Подача