サーボモーターがマイクロサービスと出会うとき: リラックスしたアーキテクチャ上の会話

同様のものに遭遇したことがありますか?モーターは信頼性がありますが、他の多数のデバイスと連携すると、システムが予測不能になります。今日は高度な理論について話す代わりに、制御システムの構成をブロックのように再考する方法について話しましょう。

問題は細部に隠されている

Imagine you are in charge of an assembly line. 6 つのサーボ モーターが正確な位置決めを担当し、3 つのサーボが角度の微調整を完了し、ロボット アームが一定のリズムで部品を運びます。 Initially, all control logic was written in a central controller - this was very common, like cramming all the furniture into a room. It looked neat at first, but as needs changed, it required rummaging around every time it was adjusted.

ある日、包装セクションの速度を一時的に 20% 上げる必要がありますが、パラメータを調整すると実際には上流の位置決め精度に影響を与えることがわかりました。あるいは、特定のセンサーデータが異常な場合、システムログ全体が混乱し、問題の原因を追跡することが困難になります。さらに一般的には、モーター モデルの 1 つを変更する場合、関連する多くのコードを書き直す必要があります。

これらは「不具合」ではなく、システムを別の方法で編成する時期が来たというアーキテクチャからのささやきです。

マイクロサービス: 各機能に別の部屋を与える

私たちは考え方を変えることができます。各モーターの制御ロジックが独立して実行できたらどうなるでしょうか?例えば：

• 位置決めサーボ モーターは、ターゲット コマンドにどのように応答するかを自ら決定し、明確なインターフェイスを通じてシステムに「位置にいます」ということだけを伝えます。
• 圧力検出ユニットはセンサーデータの分析に重点を置き、異常が発生した場合には標準形式のリマインダーを発行します。
• 動作計画モジュールは最適なパスの計算に集中し、他のモジュールのコード変更の影響を受けません。

このアプローチには、マイクロサービス アーキテクチャと呼ばれる名前があります。用語に怯える必要はありません。その本質は単純です。大規模なシステムを、独立して開発、展開、拡張できる一連の小さなサービスに分割するということです。レゴブロックと同じように、それぞれのピースには明確な機能がありますが、結合方法は柔軟に調整できます。

「これでさらに複雑になるのでは?」と疑問に思う人もいるかもしれません。良い質問ですね。短期的には、サービス間の通信のための標準 (明確に定義されたデータ形式など) を設計する必要がありますが、長期的には、システムの意図しない結合が減少します。モジュールのアップグレードが必要な場合、すべての機能をテストするために生産ライン全体を停止する必要はありません。

このアイデアがハードウェア制御シナリオに適しているのはなぜですか?

サーボモーターや機械システムは長時間稼働しやすいという特性があります。生産ラインは 5 年または 10 年間稼働し続ける可能性があり、その間、無数の部分的およびコンポーネントの交換や新しい機能が発生します。従来のモノリシック建築は巨大な油絵のようなもので、細部を変更するにはキャンバス全体を再描画する必要がある場合があります。

マイクロサービス アーキテクチャは一連のスケッチブックのようなもので、各シートに特定の機能が記録されています。ロボットアームの掴みロジックを変更したいですか?必要なのは、サービスのその部分を更新し、インターフェイスが変更されていない状態で他のモジュールと正常に通信できるようにすることだけです。

キロパワーこのタイプのアーキテクチャの実装を顧客を支援するとき、多くの場合、いくつかの興味深い変更が見られます。

• ログがサービスごとに自然に分離されるため、トラブルシューティング時間が平均 40% 短縮されます。
• ハードウェアの反復サイクルはより柔軟になり、多くの場合、モーター モデルの変更には、対応するサービスの調整のみが必要になります。
• 新機能のテストコストが削減され、ライン全体に影響を与えることなく、特定のモジュールを隔離された環境でテストできます。

コンセプトから実践までの 3 つのステップ

このアーキテクチャに興味がある場合は、次の 3 つの手順で試してみてください。

ステップ 1: 機能の境界を描きます。一枚の紙を取り出し、物理的機能に従って制御システムを分割します。どの部分が密接に結合されていますか (同じモーターからの駆動とフィードバック処理など)?データをたまにしか交換しない部品はどれですか (例: 供給機構や品質検査ユニット)?多くの場合、自然な物理境界は、マイクロサービスのパーティショニングの開始点として適しています。

ステップ 2: 対話ルールを定義する 生産ラインの作業員が半完成品を引き渡す必要があるのと同じように、サービスでもコミュニケーションが必要です。データ形式に同意します。たとえば、すべての位置情報にはタイムスタンプ、単位、信頼レベルが含まれます。すべての指示には、簡単に追跡できるように固有の番号が付いています。これらのルールは最初から完璧である必要はありませんが、明確な規則によって後で混乱を避けることができます。

ステップ 3: 根本からリファクタリングする システム全体を一度に書き直す必要はありません。最近改善が必要なモジュール (頭痛を引き起こすパッケージ セクションのサーボ モーターなど) を選択し、最初にそれを独立したサービスに変換します。動作が安定していることを確認してから、徐々に拡張してください。この段階的な変化は、生産ラインの継続的な稼働にさらに優しいものです。

答えは質問の外にある場合もあります

私はよく冒頭で述べた友人のことを思い出します。マイクロサービスのアイデアを使用して制御ロジックの一部を再編成し始めたところ、応答遅延の問題が解決されただけでなく、予想外にもチームがより自然に分業し始めていることに気づきました。機械構造を担当するエンジニアは動作計画サービスに重点を置き、電気エンジニアは駆動制御モジュールに深く関与します。この 2 つは、同じコード ファイル内で相互に注釈を付けるのではなく、明確に定義されたインターフェイスを通じて連携します。

これもアーキテクチャの賜物かもしれません。アーキテクチャはコードを整理するだけでなく、人々が共同作業する方法も整理します。各機能モジュールの責任範囲が明確であれば、保守も並行して進められるものになります。

もちろん、どんな建築も特効薬ではありません。マイクロサービスでは、サービス間のネットワーク通信を考慮する必要があり、より詳細な監視設計が必要になります。しかし、長期的な進化と頻繁なローカリゼーションを必要とするハードウェア制御システムの場合、この「分割統治」の哲学が予期せぬ容易さをもたらすことがよくあります。

結局のところ、技術的なアーキテクチャは部屋のレイアウトのようなものです。オープンスペースにすべてを配置することを好む人もいます。オープンスペースは一目瞭然ですが、局所的に調整するのが困難です。機能ごとに別の部屋を設けることを好む人もいますが、これには初期段階でさらにいくつかの手順が必要になりますが、各スペースは自分のペースで改装できます。

現在のシステムはどのような部屋になっていますか?

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