올바른 의사소통 방법을 선택하면 기계 프로젝트가 진정으로 "살아있게" 됩니다.

이것을 상상해 보십시오: 당신은 정밀 로봇 팔을 조립하고 있습니다. 서보 모터와 서보가 설치되어 있으며 모든 관절이 완벽하게 조정되어 언제든지 원활하게 회전할 수 있습니다. 그러나 간단한 잡기 작업을 완료하기 위해 신호가 함께 작동하도록 시도하면 신호가 안개에 갇힌 것처럼 보입니다. 지연되고 동기화되지 않으며 지침도 손실됩니다. 무엇이 문제인가요? 아마도 기계 부품 자체가 아니라 눈에 보이지 않는 "대화"에 있는 것 같습니다.

많은 자동화 및 기계 프로젝트에서 우리는 모터 토크, 기어 정확도, 구조적 강도 등 하드웨어에 집중하는 데 많은 시간을 보냅니다. 이것은 물론 중요합니다. 그러나 이 하드웨어가 "생각"하고 "협업"할 수 있도록 하는 소프트웨어 아키텍처는 종종 나중에 고려되는 것으로 간주됩니다. 오늘은 일반적으로 언급되는 두 가지 소프트웨어 아키텍처 스타일인 RESTful 웹 서비스와 마이크로서비스에 대해 이야기하겠습니다. 기술적으로 들리지만 핵심은 프로젝트의 다양한 부분이 "대화"하는 방식을 결정하는 규칙입니다.

정확히 무엇입니까? 간단한 이해

비유를 사용하려면. 귀하의 프로젝트는 오케스트라와 같습니다.

RESTful 웹 서비스는 지휘자와 각 음악가 사이의 고정되고 명확한 신호 시스템에 가깝습니다. 지휘자(주 제어 시스템)가 배턴을 올리고(GET 또는 POST와 같은 표준 HTTP 요청 전송) 바이올린 연주자(서보 모터 제어 모듈)가 정확하게 연주(동작 수행)를 시작합니다. 이 모델은 일련의 기존 규칙을 기반으로 하며 요청은 간단하고 명확하며 리소스 표현과 상태 전송에 중점을 둡니다. 명확한 지침, 직접적인 상호 작용, 안정적이고 신뢰할 수 있는 통신이 필요한 시나리오에 매우 적합합니다. 예를 들어, 중앙 제어판을 통해 여러 모터의 매개변수를 하나씩 쿼리하거나 설정할 수 있습니다.

마이크로서비스는 오케스트라의 각 부분이 고유한 아이디어와 기능을 갖춘 미니 밴드가 되는 것과 같습니다. 현 파트, 관악기 파트, 타악기 파트는 서로 독립적입니다. 내부적으로는 복잡한 조정을 하고, 외부적으로는 명확한 인터페이스를 통해 다른 부분과 협력합니다. 여기서 모터 제어, 경로 계획, 상태 모니터링과 같은 각 핵심 기능은 독립적으로 배포 및 실행되는 작은 서비스로 분할됩니다. 경량 메커니즘(종종 RESTful API)을 통해 통신합니다. 이는 엄청난 유연성을 제공합니다. 한 서비스의 업그레이드나 문제가 다른 부분에 영향을 미치지 않습니다.

어느 것을 선택해야 합니까?

이것은 '누가 더 나은가'의 경쟁이 아니라 '누가 더 적합한가'의 선택이다. 우리는 스스로에게 몇 가지 질문을 던져볼 수도 있습니다.

• 귀하의 프로젝트가 빠르게 변화하고 있나요?독립적으로 업데이트되는 마이크로서비스의 "플러그 앤 플레이" 특성은 기능을 자주 추가, 제거 또는 조정해야 한다고 예상하는 경우 매우 매력적입니다. 전체 제어 시스템을 건드리지 않고도 모션 알고리즘 모듈을 개별적으로 다시 작성할 수 있습니다.
• 팀은 어떻게 작동하나요?마이크로서비스를 사용하면 소규모 팀이 특정 서비스(예: 서보 응답 논리 최적화)를 파고드는 데 집중하고 병렬로 개발할 수 있으므로 더 빠를 수 있습니다.
• 귀하의 신뢰성 요구 사항은 얼마나 엄격합니까?RESTful 아키텍처는 일반적으로 더 간단하고 배포 및 유지 관리가 더 간단하며 문제가 상대적으로 적습니다. 성숙하고 안정적인 많은 기계 애플리케이션의 경우 이는 더욱 강력하고 관리하기 쉬운 핵심이 될 수 있습니다.
• 규모는 얼마나 큽니까?3~5개의 모터를 제어하는 ​​소형 데스크탑 기계 장치의 경우 완전한 마이크로서비스 아키텍처를 도입하는 것은 크레인을 사용하여 찻잔을 옮기는 것과 같을 수 있습니다. 그러나 수백 개의 실행 단위와 복잡한 비즈니스 프로세스 체인이 포함된 대규모 지능형 생산 라인을 구축하는 경우 마이크로서비스가 제공하는 명확한 경계와 탄력적인 확장 기능이 필요할 수 있습니다.

하나와 우리kpower수년 동안 우리와 함께 일해온 프로젝트 리더는 다음과 같이 자신의 경험을 공유했습니다. "과거에는 작은 센서 인터페이스 변경으로 인해 전체 시스템이 종료되고 다시 테스트될 때까지 항상 모든 제어 로직을 함께 묶는 것이 가장 안전하다고 느꼈습니다. 나중에 '상태 인식', '모션 제어' 및 '안전 모니터링'을 마이크로서비스로 분리하려고 시도했는데 갑자기 세상이 조용해졌습니다. 시스템의 나머지 부분은 평소처럼 실행되는 동안 우리는 링크 중 하나를 격리할 수 있었습니다."

보이지 않는 초석: 커뮤니케이션의 신뢰성

어떤 아키텍처 스타일을 선택하든 정보는 궁극적으로 물리적 네트워크를 통해 모터 드라이버로 전달됩니다. 이는 의사소통의 결정론과 실시간 특성이라는 더 깊지만 종종 간과되는 요점으로 이어집니다.

기계적 제어의 세계에서는 밀리초 지연이 "정밀도"와 "충돌"의 차이일 수 있습니다. 전통적인 HTTP 프로토콜(RESTful의 기반)은 인간이 웹 페이지를 탐색할 수 있도록 설계되었습니다. 이는 관대하고 유연하지만 메시지가 몇 밀리초 내에 전달된다는 보장은 없습니다. 이는 매우 높은 타이밍 요구 사항(예: 다축 보간)이 있는 일부 공동 작업에 숨겨진 위험이 될 수 있습니다.

이때 바닥을 살펴봐야 합니다. 이를 보완하기 위해 더욱 결정적인 산업용 프로토콜(예: EtherCAT, PROFINET)이 도입되고 있습니까? 아니면 소프트웨어 수준에서 적절한 버퍼링, 재시도 및 시간 초과를 설계했습니까?kpower고객이 서보 시스템을 통합하도록 지원할 때 우리는 종종 소프트웨어 지침에서 물리적 회전까지의 경로가 원활하고 시간을 잘 준수하는지 확인하기 위해 이 계층에 깊이 들어가곤 합니다.

아키텍처가 자신에게 맞게 작동하도록 하세요. 그 반대가 아닙니다.

그럼 원래 이야기로 돌아가 보겠습니다. 로봇 팔이 조화롭게 움직일 때 나사만 조이지 마세요. 앉아서 간단한 "대화 지도"를 그려보세요. 시스템에 어떤 모듈이 있습니까? 얼마나 자주 대화해야 합니까? 메시지가 간단한 스위치 명령을 전달했습니까, 아니면 복잡한 궤적 데이터를 전달했습니까? 당신은 속도에 대해 얼마나 까다롭나요?

모든 경우에 적용되는 정답은 없습니다. 좋은 선택은 팀을 더욱 효율적으로 만들고, 시스템을 더욱 강력하게 만들고, 프로젝트와 함께 성장할 수 있는 것입니다. 복잡성을 만들어내는 것이 아니라 숨겨야 합니다.

결국 기술은 문제를 해결하는 것입니다. RESTful의 단순성과 명확성이든, 마이크로서비스의 유연성과 강력함이든, 목적은 서보 모터와 기계 구성요소가 잘 훈련된 오케스트라처럼 정확하고 조화로우며 안정적인 음악을 연주하도록 만드는 것입니다. 그리고 당신의 "멜로디"에 가장 적합한 지휘 시스템을 찾는 것이 절반의 싸움입니다.

이는 단순한 소프트웨어 선택이 아니라 진정으로 "지능적"이고 "신뢰할 수 있는" 기계 시스템을 구축하는 방법에 대해 생각하는 것입니다. 여기에서 귀하의 프로젝트는 더욱 더 꾸준히 진행될 것입니다.

2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. Kpower는 모듈형 드라이브 기술의 혁신을 활용하여 고성능 모터, 정밀 감속기 및 다중 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다. Kpower는 스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론 및 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.