RU2815598C1 - Способ создания робототехнических систем - Google Patents

Abstract

Изобретение относится к области создания робототехнических систем. Техническим результатом изобретения является повышение надежности при промышленном применении способа. Предлагается способ создания робототехнической системы, включающий передачу информации к аппаратной части робота, в виде компьютера и контроллеров робота при помощи программного обеспечения, которое выполняет функции, связанные с восприятием окружающего мира, анализом полученной информации и формированием управляющих воздействий, и работает как локально, так и через подключение к центральному облаку. В робототехнической системе выделяют главный микросервис, который инкапсулирует в себе текущее состояние робота, хранит состояние робота и планирует список задач. Каждый микросервис имеет независимую базу данных для хранения своего состояния и запускается в отдельном docker-контейнере, а также снабжается «обёртками», которые аккумулируют логи и метрики и отправляют их в общую для всех микросервисов шину. 9 з.п. ф-лы, 4 ил.

Description

ОБЛАСТЬ ТЕХНИКИ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Из уровня техники известен, в частности, метод и цифровой инструмент для разработки программных архитектур сложных киберфизических систем различных технических областей (см. US2016261466A1, опубл. 08.09.2016) (1). Для проектирования программных архитектур сложных киберфизических систем в различных технических областях таким образом, чтобы было возможно эффективное и действительно интерактивное проектирование программных архитектур сложных киберфизических систем, позволяющее экономить время и усилия, предлагается обеспечить автоматическое применение мульти- уровеня ограничений в архитектурных представлениях. Это обеспечивает:

(i) в отношении архитектурных аспектов такой сложной киберфизической системы, отображаемой в Представлениях, включая различные Сущности, связанные друг с другом, и сущности, связанные между собой через различные Представления, и

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

Подход, предложенный в (1) имеет ряд недостатков, такие как, сложность промышленного применения, которое требует доработки систем для повышения надежности.

Наиболее близким аналогом заявленного способа, по мнению заявителя, являются меры, определяющие метод и программно-вычислительный продукт для разработки, проектирования и/или развертывания сложных встроенных или киберфизических систем, в частности используемых в них сложных программных архитектур, различных технических областей (см. US11294669B2, опубл. 04.05.2022) (2). Для улучшения разработки, проектирования и/или развертывания сложных встроенных или киберфизических систем и, в частности, сложных архитектур программного обеспечения, включаемых и/или используемых в них в различных технических областях, предлагается сложный опыт или инструмент- система рекомендаций по значительным мерам. Эта система рекомендаций по мерам, в частности сформированная компьютером-программой-продуктом, предназначена для определения и предоставления соответствующих мер для эффективного улучшения процесса принятия решений во время проектирования, разработки и/или развертывания систем различных технических доменов путем автоматического обеспечение векторов, определяющих меру.

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

КРАТКОЕ ИЗЛОЖЕНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

В частном случае выполнения применяется очередь сообщений на базе Nats.

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ РИСУНКОВ

Сущность изобретения поясняется чертежами, на которых:

Фиг.1 – архитектура робототехнического приложения на высоком уровне абстракции;

Фиг.2 – архитектура робототехнического приложения на аппаратном уровне абстракции (MCB – microcontroller board, RT – realtime);

Фиг.3 – схема соединения программы с физическим устройством;

Фиг.4 – схема добавления компьютера реального времени.

Позиции на фиг.1-7 обозначают следующее:

1- компьютер робота на высоком уровне абстракции;

2- контролеры робота на высоком уровне абстракции;

3- программное обеспечение компьютера на высоком уровне абстракции;

4- мотор;

5- энкодер;

6- сенсор;

7- контроллер;

8- плата управления;

9- шина;

10- симулятор;

11- пользовательский интерфейс;

12- плата реального времени;

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

ВАРИАНТ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

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

На высоком уровне абстракции (фиг. 1) робот представляет собой аппаратную часть – компьютер (1) и контроллеры робота (hardware, HW) (2) со специализированным ПО (software, SW) (3), которое выполняет функции, связанные с восприятием окружающего мира, анализом полученной информации и формированием управляющих воздействий, которые передаются уровню hardware. ПО робота может работать как локально, так и через подключение к центральному облаку, что на сегодняшний день используется все более часто.

На аппаратном уровне (фиг. 2) часто используют следующую схему: моторы (4), энкодеры (5) и другие сенсоры (6) подключаются к контроллеру (7), который совместно с другими контроллерами подключается к плате управления (ПУ) (8). Обычно ПУ (8) представляет собой компьютер, поддерживающий работу в реальном времени, способный общаться с драйверами на частоте порядка сотен герц. Для обеспечения функциональной надёжности и безопасности широко используют конечные автоматы, то есть жёстко заданный список состояний, в которых может находиться робот с точки зрения ПУ, а также направления и условия переходов между ними.

Микросервисы, как архитектура, показали себя как эффективная парадигма, позволяющая улучшить масштабируемость в ряде предметных областей, включая критические по условиям выполнения задачи системы. Основное отличие от микросервисов в облаке: в системе робототехнических микросервисов есть необходимость выделять «главный микросервис», который инкапсулирует в себе текущее состояние робота и который не целесообразно разделять на более мелкие части. Это справедливо и для IoT (Internet of Things), где устройства обычно выполняют одну небольшую функцию.

Главный микросервис хранит состояние робота и планирует список задач. Данный микросервис удобно реализовывать с помощью дерева поведений (behavior tree, BT). Конечные автоматы трудно масштабировать, расширять и повторно использовать. В BT логика перехода состояний не рассредоточена по отдельным состояниям, а организована в виде иерархической древовидной структуры с состояниями в виде листьев Это ведёт к модульности, которая упрощает как интеграцию, так и анализ поведения системы людьми и алгоритмами. В заявленном споосбе для реализации BT используется библиотека go-behaviortree.

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

Одним из ключевых требований к микросервисам является наличие лаконичного и понятного интерфейса (application programming interface, API). Это упрощает построение сложного ПО и тестирование компонентов для улучшения качества и безопасности разрабатываемой робототехнической системы.

В микросервисной архитектуре компоненты связаны асинхронно – принята парадигма обмена сообщениями с использованием очередей. Одним из наиболее простых асинхронных механизмов является механизм «издатель–подписчик» на основе очередей сообщений. В заявленном способе применяется очередь сообщений на базе Nats. Этот механизм зарекомендовал себя как простой и быстрый. В заявленном способе обмен сообщениями вынесен в отдельный транспортный уровень, который достаточно легко может быть заменён аналогичными технологиями благодаря продуманным абстракциям. В качестве альтернативы может быть использован LCM, как более актуальный для промышленного применения механизм обмена сообщениями, который поддерживает обмен сообщениями в реальном времени. В настоящий момент существуют реализации для разных языков программирования, а применение LCM можно найти, например, в автомобильном транспорте.

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

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

В случае сложных процессов, закрытых производств, высоких требований к скорости и нагрузке, а также других особенностей системы, требующих более сложной архитектуры, поддерживается использование многоуровневых облаков. Сейчас активно развивается направление вычислений на локальном уровне: кроме облаков уже применяются на практике архитектуры с вычислениями в «тумане» (fog layer). Например, на производстве стоят локальные сервера, которые могут выступать облаком для роботов и обеспечивать работу общих микросервисов, снижая, таким образом, требования к вычислительным мощностям непосредственно на роботе. На большом заводе такие сервера могут стоять в каждом цехе и аккумулировать данные, а потом отправлять их на уровень выше и принимать внешние команды. При этом безопасность обмена сообщениями между уровнями обеспечивается гейтвеями.

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

Если программа работает с симулятором, для неё необходимо подготовить дополнительные файлы: описание мира, самого робота, другие вспомогательные настройки. Существующие и перспективные подходы к описанию роботов представлены в статье. Обычно для конфигурирования микросервисов используются файлы в формате Yaml, для каждого варианта запуска можно создать свой файл, а развернуть группу микросервисов позволяют стандартные для разработки ПО инструменты. Одним из преимуществ микросервисов является то, что они могут быть развёрнуты одновременно как в облаке, так и на роботе. Допустим, часть роботов оснащены компьютером с ограниченными вычислительными возможностями, управление для них можно осуществлять из облака, в то время как для роботов с производительным компьютером микросервисы могут быть запущены локально. Если при этом внутренний микросервис по какой-либо причине окажется нерабоспособен в рамках локального компьютера, останется запасной вариант подключиться к программе в облаке. Параллельный запуск микросервисов помогает решить проблему устойчивости, так как если один из них выйдет из строя, второй сможет обрабатывать запросы.

Применяемая база знаний или база данных содержит информацию о том, что робот «знает» о внешнем мире. Для каждого микросервиса желательно иметь отдельную базу, что позволит легко переносить его с одного устройства на другое. С точки зрения обработки, окружающий мир удобно представлять в виде дерева объектов (например, есть здание, оно состоит из комнат, в комнатах лежат вещи). Для этого могут быть использовано как хранение информации в отдельных файлах, например в форматах Yaml или Json, так и применение полноценных баз данных различного типа. Главный микросервис должен быстро принимать решения и часто работать с окружающими его объектами, поэтому следует использовать инструменты, которые помогают осуществлять быстрый поиск в дереве, а также вносить изменения в структуру объектов, поскольку реальный мир не может быть однозначно формализован и структурирован. Поэтому применение реляционных баз данных возможно, но как правило приводит к сложностям при изменении данных. Целесообразнее применение объектно-ориентированных или документо-ориентированных баз данных.

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

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

Для контроля качества применяется подход, состоящий из следующих этапов.

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

2) Тестирование. Что бы убедиться, что каждая функция работает правильно и согласно спецификации, необходимо подвергнуть эту функцию всестороннему тестированию. Это осуществляется с помощью набора тестов, которые выполняются регулярно при каждом запросе на интеграцию. Развертывается комбинация модульных и интеграционных тестов, а также набор инструментов статического анализа («линтеры»).

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

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

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

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

Обратный маятник

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

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

Второй шаг – это имплементация разработанного ПО для работы с реальной робототехнической системой. Для этого подключается контроллер (7) системы управления обратным маятником, а главный микросервис дорабатывается так, чтобы в зависимости от состояния переключателя он посылал команды или в общую шину (9) для симулятора (10), или на плату контроллера (7) (фиг. 3). На данном этапе необходимо участие специалиста по механике и электронике, чтобы получить качественный результат.

Если в результате тестирования выясняется, что система не успевает с достаточной для качественного управления частотой выполнять расчёты и передавать команды, то возможно добавление платы реального времени (12) и перенос часть низкоуровневых задач на неё (фиг. 4). При этом решение полностью разместить на RT-плате код компонента «MAIN v2» является ошибочным. Правильнее разделить функционал чувствительный и нечувствительный к требованиям выполнения в реальном времени. Это упрощает модификацию обоих компонентов в будущем. На этом этапе от программиста требуются начальные навыки работы с системами реального времени.

Антропоморфный робот

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

Этапы перехода от прототипа к реальному железу совпадают с предыдущим случаем. В примере увеличивается количество микросервисов, но архитектурно изменения невелики. Обмен сообщениями микросервисов осуществляется по основной шине. При необходимости внешнего наблюдения и управления добавляется микросервис GW (Gateway), который обеспечивает безопасность – авторизованное подключение к роботу. Это позволяет собирать и отображать данные для удалённого от пользователя или разработчика робота.

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

Рой дронов

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

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

ПРОМЫШЛЕННОЕ ПРИМЕНЕНИЕ

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

Claims (10)

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

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

3. Способ создания по п.1, отличающийся тем, что применяется очередь сообщений на базе Nats.

4. Способ создания по п.1, отличающийся тем, что использован протокол LCM как механизм обмена сообщениями, который поддерживает обмен сообщениями в реальном времени.

5. Способ создания по п.1, отличающийся тем, что при общении по сети используют общение через гейтвей или VPN.

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

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

8. Способ создания по п.7, отличающийся тем, что используют облачные сервисы с отличающимися транспортными протоколами, при условии наличия мостов, которые конвертируют сообщения между шинами.

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

10. Способ создания по п.9, отличающийся тем, что в базе знаний используют как хранение информации в отдельных файлах, например в форматах Yaml или Json, так и применение полноценных баз данных различного типа.