От громоздких универсальных машин до гибких микросервисов: как незаметно обновить ваши механические проекты

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

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

Что такое микросервисы? Вы можете понять с помощью метафоры

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

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

Почему это особенно удобно для механических проектов?

Во-первых, вам больше не придется беспокоиться об обновлении. Раньше для изменения логики управления сервоприводом можно было использовать коммуникационные модули или даже интерфейсы пользовательского интерфейса. Теперь вам нужно переместить только один из «маленьких блоков», объем тестирования меньше и риск ниже. Требуется ли итерация метода управления определенным серводвигателем? Просто обновите эту службу, а все остальное будет проигнорировано.

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

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

Однако будет ли им сложнее управлять, если он слишком разбит?

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

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

Как использовать его в реальных сценариях?

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

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

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

Звучит красиво, будет ли переход болезненным?

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

1. Определите относительно независимый функциональный модуль текущей системы (например, модуль обработки сигналов тревоги или модуль регистрации данных) и сначала отделите его в независимую службу.
2. Установите механизмы связи и инструменты мониторинга между службами.
3. Ощутив преимущества, мы постепенно будем «микрообслуживать» другие модули один за другим.

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

Откуда берутся инструменты и поддержка?

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

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

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

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