Когда оборудование соответствует коду: как микросервисный дизайн делает оборудование умнее

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

Знакома ли эта сцена?

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

Другая точка зрения: думайте о аппаратных проектах как о наборе «маленьких команд».

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

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

Какова реальная польза от этого?

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

Как начать? От «расставания» к «хорошему сближению»

Вы можете спросить, с чего начать? Фактически, вы можете начать с самого простого разделения.

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

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

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

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

Действительно ли он подходит для моего проекта?

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

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

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

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

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