Когда суставы вашего робота начинают «болтаться»: кое-что об обмене данными микросервисов

Представьте, что вы собираете шестиосную роботизированную руку. Серводвигатель вращается точно, сервопривод оперативно реагирует, и все идеально — до тех пор, пока какой-то сустав внезапно не «застревает», потому что данные от другого модуля еще не переданы. Производственная линия остановилась на три секунды, и весь ритм был нарушен.

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

Хранилища данных: не техническая проблема, а проблема совместной работы

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

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

Микросервисы уже существуют, но как «квитировать» данные?

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

Существует несколько распространенных режимов:

• API-запрос: Типа спрашивать "у вас есть новые данные?" каждые несколько минут. Просто, но неизбежно с задержкой.
• очередь сообщений: Модуль "перекидывает" данные в промежуточный канал, и кому надо, тот может их получить. Это асинхронно, но порядок может быть нарушен.
• управляемый событиями: Как только данные сгенерированы, они немедленно «транслируются». Модули, которым важно это событие, могут реагировать в режиме реального времени. Это немного похоже на неврологический рефлекс: когда появляется стимул, действие происходит немедленно.

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

мощностьРешение: сделать данные такими же естественными, как «разговор».

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

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

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

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

Например: в проекте автомобиля AGV навигационный модуль публикует события местоположения в реальном времени, а рулевой механизм ведущего колеса подписывается на них для обеспечения отслеживания; Модуль управления аккумулятором регистрирует только события напряжения и температуры и в случае неисправности выдает сигнал замедления. Каждый берет то, что ему нужно, не мешая друг другу.

Какие изменения это внесло?

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

Его легко поддерживать. Если в каком-либо модуле возникла проблема, его поток данных немедленно покажет отклонения, что значительно ускорит поиск точки неисправности. Обновление или замена модуля не окажет существенного влияния, если он следует тем же «правилам диалога».

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

Итак, как начать?

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

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

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

Основанная в 2005 году, компания Kpower занимается профессиональным производителем компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в модульной технологии привода, Kpower объединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, чтобы предоставить эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.