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

  • مقالة
  • قراءة خلال 6 دقائق

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

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

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

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

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

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

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

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

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

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

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

  2. يقدم مثيل خدمة التزويد نسخة من أي بيانات حالة الجهاز الأولية إلى مركز 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 دائما باستدعاء webhook المخصص للتخصيص بغض النظر عن سياسة إعادة التوفير في حالة وجود ReturnData جديد للجهاز. إذا تم تعيين سياسة إعادة إدارة الحسابات على عدم إعادة التوفير مطلقا، استدعاء webhook ولكن الجهاز لن يغير مركزه المعين.

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

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

تلميح

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

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

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

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

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

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

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

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

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

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

backwards compatibility flow chart

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

REST API 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 أو إصدار أقدم

ملاحظة

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

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