عندما يواجه مشروع الخدمة الصغيرة الخاص بك مشاكل في محرك سيرفو

تعمل بنية الخدمات الصغيرة على تقسيم الأنظمة الكبيرة إلى خدمات صغيرة مستقلة، وهو أسلوب ذكي. لكن في كثير من الأحيان نركز فقط على "التقسيم" و"التعاون" على مستوى البرمجيات، ولكننا ننسى أن وحدات الأجهزة التي تقود المعدات فعليًا - مثل المحركات المؤازرة وتروس التوجيه - هي المفتاح لتحويل التعليمات الرقمية في نهاية المطاف إلى إجراءات مادية. إذا لم تتمكن استجابة الأجهزة من مواكبة إيقاع البرنامج، بغض النظر عن مدى جمال مخطط الهندسة المعمارية، فستكون مجرد فكرة على الورق.

كيف "تتحدث" الأجهزة والبرامج؟

قد يتساءل أحدهم: أليس محرك السيرفو يستقبل الإشارة فقط ثم يدور؟ ما مدى علاقتها بهندسة الخدمات الصغيرة؟ في الواقع، هذا مهم جدًا. في الممارسة التقليدية، غالبًا ما نركز التحكم في الأجهزة في الخدمة. ومع ذلك، مع توسع النظام، يمكن أن تصبح هذه الخدمة متضخمة بسهولة. بمجرد أن يحتاج المحرك إلى ضبط معلماته، قد يتعين أن تتأثر وحدة التحكم بأكملها. فكرة الخدمات المصغرة هي: لماذا لا يتم فصل التحكم في كل جهاز رئيسي إلى خدمة صغيرة؟ اسمح لخدمة مخصصة بإدارة محرك مخصص، يكون مسؤولاً فقط عن تلقي التعليمات وحالة الملاحظات. إذا كانت هناك مشكلة، فلن يؤثر ذلك على المعدات الأخرى. تمامًا مثل الفرقة ذات التقسيم الواضح للعمل، يهتم كل موسيقي فقط بالجزء الخاص به، ولكنهم معًا يشكلون مقطوعة متناغمة.

ولكن على الرغم من أن الفكرة جيدة، إلا أن هناك عدة عوائق تعترض تنفيذها: أولاً، غالبًا ما تكون بروتوكولات الأجهزة ثابتة نسبيًا. كيفية جعلها تتكيف بمرونة مع استدعاء الخدمات المختلفة؟ ثانيًا، في السيناريوهات ذات متطلبات الوقت الفعلي العالية، هل سيؤدي التأخير في الاتصال بين الخدمات إلى إبطاء الاستجابة الحركية؟ ثالثًا، في حالة فشل خدمة محرك معينة، هل يمكن للنظام التحول بسرعة إلى خطة احتياطية لمنع خط الإنتاج بأكمله من التوقف عن العمل؟

فكرة تكامل أكثر "واقعية".

بدلاً من إجبار الأجهزة على التكيف مع بنية البرنامج، من الأفضل تغيير الفكرة - بناء طبقة "مترجم" بين الأجهزة والخدمات الصغيرة. يمكن لطبقة الترجمة هذه فهم التعليمات من كل خدمة وتحويلها إلى لغة يمكن للمحرك فهمها؛ كما أنه يغذي حالة المحرك في الوقت الفعلي للسماح للخدمة الأولية بمعرفة: "تم استلام التعليمات ويتم تنفيذها". بهذه الطريقة، يمكن لمستوى البرنامج الاستمرار في الاستمتاع بالمرونة التي توفرها الخدمات الصغيرة، بينما يحافظ مستوى الأجهزة على منطق قيادة مستقر وموثوق. يؤدي كلا الجانبين واجباته الخاصة ويرتبطان بسلاسة من خلال الطبقة الوسطى.

kpowerعند حل مثل هذه المشكلات، من المعتاد العمل بشكل عكسي انطلاقًا من السيناريوهات الفعلية. على سبيل المثال، في سيناريو التعاون مع الذراع الآلية، قد يتم التحكم في الماكينات الخاصة بكل مفصل بواسطة خدمات مختلفة. سنتأكد أولاً من أن خدمة التحكم لكل سيرفو خفيفة الوزن ومركزة بدرجة كافية، ثم ننسق تسلسل عملها من خلال قناة رسائل موحدة. بدلاً من الاعتماد على جدولة مركزية معقدة، يمكن للخدمات إخطار بعضها البعض من خلال الأحداث القياسية: "أنا في المكان، حان دورك". والنتيجة هي استجابة أسرع، واقتران أقل، وترقية الخدمة دون إيقاف تشغيل الذراع الآلية بالكامل.

لماذا التفاصيل تحدد النجاح أو الفشل؟

في هندسة الخدمات الصغيرة، غالبًا ما يهتم الجميع بتقسيم الخدمة، وتصميم واجهة برمجة التطبيقات (API)، والنشر في حاويات - وهي أمور مهمة بالطبع. ولكن ما يؤثر حقًا على تجربة المستخدم غالبًا ما يكون هذا الجانب: ما إذا كان الجهاز يتحرك بدقة وفي الوقت المناسب. يعد التحكم في المحركات المؤازرة في الأساس سعيًا مزدوجًا لتحقيق الدقة والأداء في الوقت الفعلي. الدقة تعني أن كل دورة يجب أن تتوقف عند الموضع المحدد؛ الوقت الفعلي يعني أن التأخير من إصدار التعليمات إلى بدء الإجراء صغير بدرجة كافية. وفي ظل بنية الخدمات الصغيرة، يتطلب ذلك تعاونًا وثيقًا في اتصالات الشبكة والتسلسل وإصدار تعليمات برنامج التشغيل. إذا كان أي رابط بطيئًا، فإن ما قد يراه المستخدم هو نصف ثانية من تردد الذراع الآلية.

ولذلك، يجب أن يؤخذ وقت استجابة الأجهزة في الاعتبار أثناء مرحلة التصميم. على سبيل المثال، قم بتعيين أولوية أعلى لخدمات التحكم الرئيسية في المحركات وتخصيص رابط اتصال أكثر استقرارًا؛ أو احتفظ بتعليمات ذاكرة التخزين المؤقت خفيفة الوزن محليًا حتى يتمكن المحرك من الاستمرار في تنفيذ الإجراءات غير المكتملة حتى لو كانت الشبكة تتقلب لفترة وجيزة. لن تظهر هذه التفاصيل في مخطط البنية، ولكنها تؤثر بشكل مباشر على "إحساس" النظام.

جعل النظام "حيا"

يجب أن يكون النظام الجيد قادرًا على التنفس والتكيف. تمنح بنية الخدمات الصغيرة مرونة البرامج، ويمكن أن تتمتع وحدات الأجهزة مثل المحركات المؤازرة وتروس التوجيه بمرونة مماثلة من خلال التغليف المعقول الموجه نحو الخدمة. عندما يزيد حمل محرك معين فجأة، يمكن لخدمة التحكم الخاصة به إرسال إشارة "طلب إبطاء السرعة" بشكل فعال إلى المنبع؛ عندما يكتشف النظام أن مجموعة معينة من الإجراءات تتكرر بشكل متكرر، يمكنه تلقائيًا إصدار أمر بتسلسل لتقليل الحركة غير الفعالة للمحرك. لم تعد الأجهزة بمثابة محطة تنفذ الأوامر بشكل صارم، ولكنها أصبحت عقدة ذكية يمكنها ردود الفعل والتعديل. هذا المزيج من تصميم البرامج والأجهزة يجعل النظام بأكمله "حيًا" حقًا ولا يمكنه التعامل مع سير العمل المعروف فحسب، بل يمكنه أيضًا التكيف مع حالات الطوارئ غير المعروفة.

ففي نهاية المطاف، تخدم الهندسة التقنية أهدافًا فعلية في نهاية المطاف. الخدمات المصغرة ليست غاية، بل وسيلة؛ المحركات المؤازرة ليست مجرد أجزاء، ولكنها امتداد لقدرات النظام. عندما يجد الاثنان طريقة مناسبة للحوار، ستجد أن: الأشياء المعقدة في الأصل أصبحت أبسط، والعمليات الصارمة في الأصل أصبحت مرنة، ومشكلات تنسيق الأجهزة التي كانت تسبب لك الصداع أصبحت تدريجيًا الجزء الأكثر استقرارًا في النظام. وكل هذا، غالبًا ما تكون نقطة البداية مجرد النظر إلى المشكلة من زاوية أخرى - بدءًا من سطر من التعليمات البرمجية، والإشارة، والدوران.

أنشئت في عام 2005،kpowerتم تخصيصها لمصنع محترف لوحدة الحركة المدمجة، ومقرها الرئيسي في دونغقوان، مقاطعة قوانغدونغ، الصين. الاستفادة من الابتكارات في تكنولوجيا القيادة المعيارية،kpowerيدمج المحركات عالية الأداء ومخفضات الدقة وأنظمة التحكم متعددة البروتوكولات لتوفير حلول نظام القيادة الذكية الفعالة والمخصصة. قدمت Kpower حلول أنظمة القيادة الاحترافية لأكثر من 500 عميل من المؤسسات على مستوى العالم مع منتجات تغطي مجالات مختلفة مثل أنظمة المنزل الذكي، والإلكترونيات الأوتوماتيكية، والروبوتات، والزراعة الدقيقة، والطائرات بدون طيار، والأتمتة الصناعية.