مفاهيم توفير IoT Hub Device

  • مقالة

أثناء دورة حياة حل IoT، من الشائع نقل الأجهزة بين محاور IoT. قد تتضمن أسباب هذا النقل السيناريوهات التالية:

  • الموقع الجغرافي / GeoLatency: مع انتقال الجهاز بين المواقع، يتم تحسين زمن انتقال الشبكة عن طريق ترحيل الجهاز إلى مركز IoT أقرب.

  • الإيجار المتعدد: يمكن استخدام جهاز ضمن نفس حل IoT وإعادة تعيينه إلى عميل جديد أو موقع عميل جديد. قد تتم خدمة هذا العميل الجديد باستخدام مركز IoT مختلف.

  • تغيير الحل: يمكن نقل الجهاز إلى حل IoT جديد أو محدث. قد تتطلب إعادة التعيين هذه من الجهاز الاتصال بمركز IoT جديد متصل بمكونات أخرى ذات برامج خلفية.

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

إعادة تزويد الدعم داخل خدمة تزويد الأجهزة يعالج هذه الاحتياجات. يمكن إعادة تعيين الأجهزة تلقائيا إلى مراكز IoT جديدة استنادا إلى نهج إعادة التزويد الذي تم تكوينه على إدخال التسجيل للجهاز.

بَيانات حالة الجهاز

تتكون بيانات حالة الجهاز من قدرات الجهاز المزدوج والجهاز. يتم تخزين هذه البيانات في مثيل خدمة تزويد الأجهزة ومركز IoT الذي تم تعيين جهاز إليه.

Diagram that shows how provisioning works with the Device Provisioning Service.

عند تزويد جهاز في البداية مع مثيل خدمة تزويد الأجهزة، يتم تنفيذ الخطوات التالية:

  1. يرسل الجهاز طلب تزويد إلى مثيل خدمة تزويد الأجهزة. يصادق مثيل الخدمة على هوية الجهاز استنادا إلى إدخال تسجيل وإنشاء التكوين الأولي لبيانات حالة الجهاز. يعين مثيل الخدمة الجهاز إلى مركز IoT استنادا إلى تكوين التسجيل ويقوم بإرجاع تعيين مركز IoT إلى الجهاز.

  2. يقدم مثيل خدمة التزويد نسخة من أي بيانات حالة الجهاز الأولية إلى مركز IoT المعين. يتصل الجهاز بمركز IoT المعين ويبدأ العمليات.

بمرور الوقت، قد يتم تحديث بيانات حالة الجهاز على مركز IoT بواسطة عمليات الجهاز والعمليات الخلفية. تظل معلومات حالة الجهاز الأولية المخزنة في مثيل خدمة تزويد الأجهزة دون أي تغيير. تُشكل بيانات حالة الجهاز التي لم يتم المساس بها التكوين الأولي.

Provisioning with the Device Provisioning Service

اعتمادا على السيناريو، كما يتحرك جهاز بين مراكز IoT، قد يكون من الضروري أيضا ترحيل حالة الجهاز المحدثة على مركز IoT السابق عبر إلى مركز IoT الجديد. يتم اعتماد هذا الترحيل بواسطة نهج إعادة التزويد في خدمة تزويد الأجهزة.

نهج إعادة التزويد

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

  • إعادة توفير البيانات وترحيلها: هذا النهج هو النهج الافتراضي لإدخالات التسجيل الجديدة. يتخذ هذا النهج إجراء عندما ترسل الأجهزة المرتبطة بإدخال التسجيل طلبا جديدا (1). اعتمادا على تكوين إدخال التسجيل، قد يتم إعادة تعيين الجهاز إلى مركز IoT آخر. إذا كان الجهاز يقوم بتغيير مركز IoT، ستتم إزالة تسجيل الجهاز لدى مركز IoT الأولي. سيتم ترحيل معلومات حالة الجهاز المحدثة من مركز IoT إلى مركز IoT الجديد (2). أثناء الترحيل، سيتم الإبلاغ عن حالة الجهاز على أنها تعيين.

    Diagram that shows that a policy takes action when devices associated with the enrollment entry submit a new request.

  • إعادة التوفير وإعادة التعيين إلى التكوين الأولي: يتخذ هذا النهج إجراء عندما ترسل الأجهزة المقترنة بإدخال التسجيل طلب توفير جديد (1). اعتمادا على تكوين إدخال التسجيل، قد يتم إعادة تعيين الجهاز إلى مركز IoT آخر. إذا كان الجهاز يقوم بتغيير مركز IoT، ستتم إزالة تسجيل الجهاز لدى مركز IoT الأولي. يتم تزويد بيانات التكوين الأولية التي يتلقاها مثيل خدمة التزويد عند تزويد الأجهزة إلى مركز IoT الجديد (2). أثناء الترحيل، سيتم الإبلاغ عن حالة الجهاز على أنها تعيين.

    غالبا ما يتم استخدام هذا النهج لإعادة تعيين مصنع دون تغيير مراكز IoT.

    Diagram that shows how a policy takes action when devices associated with the enrollment entry submit a new provisioning request.

  • عدم إعادة التوفير أبدا: لا يتم إعادة تعيين الجهاز أبدا إلى مركز مختلف. يتم تزويد هذا النهج لإدارة توافق الإصدارات السابقة.

إشعار

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

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

  • عدد المرات التي تتوقع فيها إعادة تشغيل أجهزتك
  • الحصص النسبية وحدود DPS
  • وقت النشر المتوقع لأسطولك (الإطلاق المرحلي مقابل الكل في وقت واحد)
  • إمكانية إعادة المحاولة المطبقة على التعليمات البرمجية للعميل، كما هو موضح في التوجيه العام لإعادة المحاولة في Azure Architecture Center

تلميح

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

  • أعد محاولة عملية Hub إذا كان رمز النتيجة 429 (طلبات كثيرة جدا) أو خطأ في النطاق 5xx. لا تحاول مرة أخرى لأي أخطاء أخرى.
  • بالنسبة لأخطاء 429، أعد المحاولة فقط بعد الوقت المحدد في العنوان إعادة المحاولة بعد.
  • بالنسبة لأخطاء 5xx، استخدم التراجع الأسي، مع إعادة المحاولة الأولى بعد 5 ثوانٍ على الأقل من الاستجابة.
  • عند حدوث أخطاء أخرى غير 429 و5xx، أعد التسجيل من خلال DPS
  • من الناحية المثالية، يجب عليك أيضا دعم طريقة لتشغيل التوفير يدويا عند الطلب.

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

إدارة توافق الإصدارات السابقة

قبل سبتمبر 2018، كان لتعيينات الأجهزة إلى مراكز IoT إجراء صعب. عندما يعود جهاز خلال عملية التزويد، سيتم تعيينه فقط مرة أخرى إلى نفس مركز IoT.

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

  1. تتصل الأجهزة بإصدار API قبل توفر دعم إعادة النسخ الأصلي في خدمة تزويد الأجهزة. راجع جدول API الوارد أدناه.

  2. لا يحتوي إدخال التسجيل للأجهزة على نهج إعادة تزويد معينة له.

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

يساعد المخطط الانسيابي التالي على إظهار وقت وجود الإجراء:

backwards compatibility flow chart

يعرض الجدول التالي إصدارات واجهة برمجة التطبيقات قبل توفر دعم إعادة التزويد الأصلي في خدمة تزويد الأجهزة:

واجهة برمجة تطبيقات REST C SDK Python SDK عقدة SDK Java SDK .NET SDK
2018-04-01 والإصدارات السابقة 1.2.8 والإصدارات السابقة 1.4.2 والإصدارات السابقة 1.7.3 أو إصدار سابق 1.13.0 أو إصدار سابق 1.1.0 أو إصدار سابق

إشعار

من المحتمل أن تتغير هذه القيم والارتباطات. هذه ليست سوى محاولة عنصر نائب لتحديد مكان تحديد الإصدارات من قبل العميل وما هي الإصدارات المتوقعة.

الخطوات التالية