Почему в вашем проекте серводвигателя всегда возникают проблемы «в данный момент»?

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

Это звучит знакомо?

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

Как создать «бесссорную» закулисье?

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

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

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

Возможно, вам нужен набор инструментов, которые «понимают машинный язык»

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

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

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

Некоторые проблемы, которые могут возникнуть на практике

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

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

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

От частей к целому, шаг за шагом

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

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

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

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

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

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