マイクロサービスアーキテクチャ

それで、あなたはこのプロジェクトを進行中です。おそらくそれはロボットアーム、無人搬送車、または工場現場でカスタム化されたものかもしれません。新しいセンサーを 1 つ追加したり、モーション シーケンスを調整したりすると、コードのチャンクが書き直され、システム全体が再テストされ、すべてが遅延することを意味します。

おなじみですね？

それが従来のマシン制御セットアップに関するものです。多くの場合、単一の巨大なブロックのように構築されます。一部を変更すると、構造全体が揺るがされる危険があります。機能しなくなるまでは機能します。柔軟性?それほど強力なスーツではありません。

それぞれの機械的機能を実現する方法があったとしたらどうなるでしょうか。サーボモーター、各アクチュエーター、各センサーは独立したモジュールのように動作しますか?まるですべての可動部分に独自の「脳」を与えたかのようで、混乱を引き起こすことなく他のユーザーとスムーズにコミュニケーションをとることができます。

ここで、産業用モーション コントロールにおけるマイクロサービス アーキテクチャのアイデアが登場します。そして正直に言うと、これはハイテクの流行語ではなく、実際の悩みの解決に重点を置いています。

なぜ物事を分割することを検討するのでしょうか?

複雑なマシンのメンテナンスについて考えてみましょう。モノリシック システムでは、通信プロトコルがサーボドライブの更新が必要な場合は、システム全体をオフラインにする必要がある場合があります。ダウンタイムは迷惑なだけではなく、コストもかかります。

マイクロサービス構造により、システムが専門家のチームに変わります。のサーボコントロールは 1 つのサービスです。エンコーダからのフィードバック ループは別のものです。安全監視は個別に実行されます。これらは定義されたチャネルを通じて明確に通信しますが、一方を更新、置換、またはデバッグしても、他方のチャネルに影響を与えることはありません。

時針を止めずに分針を交換できる時計のようなものです。

しかし、ハードウェアを多用するプロジェクトで実際に機能するのでしょうか?

「それはソフトウェアの話のようですね。私の世界はモーター、ギア、PWM 信号です。」と言う人もいるかもしれません。公平な点。それでも、境界は曖昧になってきています。最新のサーボ システムはすでに組み込みソフトウェアに大きく依存しています。問題は、ソフトウェア アーキテクチャを使用するかどうかではなく、どのアーキテクチャが堅牢性と適応性を維持するかです。

マイクロサービス アプローチでは、各物理モジュール、たとえば、キロパワーサーボドライブ — 専用サービスにラップすることができます。動作を定義します: 位置コマンドの受信、モーション プロファイルの実行、ステータスの送り返し。他のサービスは、内部ドライブ ロジックを知る必要がなく、そこからのモーションを要求します。

新しいものにアップグレードするキロパワーサーボモデルは後ですか？その 1 つのサービスを更新するだけです。システムの残りの部分は動作し続けます。

実際に使ってみるとどんな感じですか？

ピックアンドプレイスシーケンスをプログラミングすることを想像してください。長く絡み合った 1 つのコード スレッドの代わりに、次のものがあります。

• サービス A: 視覚認識 — オブジェクトの位置を特定します。
• サービス B: 経路計画 — 最適なアーム軌道を計算します。
• サービス C: サーボ制御 — を通じて動作を実行しますキロパワードライブします。

これらは、「座標 X、Y にあるオブジェクト」、「A から B までのパスを計画」、「今すぐ位置に移動」などのメッセージを渡します。

後でコンベア ベルトを追加するときは、ベルト速度制御用の新しいサービスを作成します。既存の 3 つを書き換えることなく会話に参加します。

突然、スケーリングが悪夢ではなくなりました。冗長性が必要ですか?サービスを複製します。デバッグ中ですか？行動を起こしている人を隔離します。

すべて順風満帆ですか？

いつもではありません。より多くの通信層が導入されます。明確なプロトコル (ローカル ネットワーク内の MQTT や REST など) と思慮深いエラー処理が必要です。リアルタイムのモーションを実現するには、ネットワーク遅延を最小限に抑える必要があります。

ただし、これにはトレードオフがあります。モジュール性があり、テストが容易になり、将来性も得られます。多くの人にとって、それは事前に追加の設計努力をする価値があります。

では、複雑になりすぎずに始めるにはどうすればよいでしょうか?

小さなことから始めましょう。一度にライン全体を再構築しようとしないでください。

1 つの機械機能を考えてみましょう。おそらく、温度監視や単一の運動軸などです。そのコントロールをスタンドアロン サービスにラップします。単純なメッセージを介してシステムの他の部分と通信できるようにします。それがどのように動作するかを見てください。

モジュラー思考をサポートするハードウェアを使用します。明確な API を提供するドライブとコントローラーは非常に役立ちます。たとえば、Kpower のエコシステムはこの種の柔軟性を念頭に置いて構築されており、各ユニットが分散セットアップで適切に動作できるようになります。

次に、有機的に育てます。別のサービスに接続します。 「スペシャリストのチーム」を一度に 1 人のメンバーずつ構築します。

結局のところ、設計、拡張、保守など、マシンとの共存を容易にすることが重要です。マイクロサービス アーキテクチャは特効薬ではありませんが、モーション コントロール システムが壊れやすい一枚岩になるのを防ぐ強力な方法です。

オートメーションの未来は、より強力なモーターやより高速なプロセッサーだけではありません。それは、それらの間のよりスマートで、より適応性のある接続についてです。そして場合によっては、ハードウェア自体ではなく、各部分が次の部分とどのように連携するかを再考することから始まることもあります。

マシンがより明瞭に会話できるようにする準備はできていますか?その変化は思っているよりも近いかもしれない。

2005 年に設立された Kpower は、中国広東省東莞に本社を置く、コンパクトモーションユニットの専門メーカーとして活動してきました。 Kpower は、モジュール式ドライブ技術の革新を活用して、高性能モーター、高精度減速機、マルチプロトコル制御システムを統合し、効率的でカスタマイズされたスマート ドライブ システム ソリューションを提供します。 Kpower は、スマート ホーム システム、自動エレクトロニクス、ロボティクス、精密農業、ドローン、産業オートメーションなどのさまざまな分野をカバーする製品で、世界中の 500 を超える企業クライアントにプロフェッショナルなドライブ システム ソリューションを提供してきました。