Когда серводвигатели встречаются с микросервисным дизайном: эти головные боли и один поворот

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

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

В чем проблема? Не только о коде

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

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

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

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

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

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

Но как? Кто-то спросил меня: «Это просто вопрос разбиения функций на достаточно мелкие части?» Это не так просто. Раскол – это не цель, а средство. Ключ заключается в том, как сервисы взаимодействуют друг с другом, как реагировать на сбои и как совместно удовлетворять требования оборудования в реальном времени после разборки. Это требует единого взгляда на аппаратное и программное обеспечение.

От теории к действию: как сделать сотрудничество реальностью

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

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

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

Неизбежная тема: выбор и доверие

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

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

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

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

Напоминание: начните с малого, но думайте масштабно

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

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

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

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

(над)

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