عندما تفي مشاريع المحركات المؤازرة بالرمز: ملاحظة من الزاوية الميكانيكية

هناك العديد من الماكينات المفككة على مكتبي، مع لوحات الدوائر المكشوفة والتروس المتناثرة جانبًا. شاشة الكمبيوتر بجواري قيد التشغيل، وصفحة GitHub مفتوحة، وهناك مجموعة من مشاريع الخدمات الصغيرة لـ Spring Boot. سألني أحد الأصدقاء الأسبوع الماضي: "ما هي العلاقة بين المشاريع الميكانيكية وهندسة البرمجيات؟" ضحكت. إنها صفقة كبيرة.

المشكلة: اللحظة "العالقة" في مشروع ميكانيكي

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

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

التحول: عندما تلتقي الخدمات الصغيرة مع التحكم في المحركات

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

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

kpowerالممارسة: الجسر من Gears إلى Code

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

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

وقت الأسئلة والأجوبة

وسأل أحدهم: هل هذا يزيد التعقيد؟

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

سؤال آخر: "ما علاقة المشروع الميكانيكي بـ GitHub؟"

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

الشيطان يكمن في التفاصيل

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

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

التفكير غير الخطي: من آلات القهوة إلى الروبوتات الصناعية

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

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

مكتوب في

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

ربما، بالنسبة لمشروعك التالي، يمكنك البدء بقالب خدمة بسيطة لـ Spring Boot على GitHub، وتوصيل عدد قليل من المحركات الموثوقة، ثم مشاهدتها تعمل معًا كما لو كانت على قيد الحياة. وهذا الشعور أكثر حيوية من أي نظرية.

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