كيف تراقب وحدة مراقبة الأجهزة (Watchdog) حالة وحدة 4G في الوقت الفعلي؟

لقد رأيت الكثير من كاميرات PTZ الشمسية عن بعد تتوقف عن العمل لأن وحدة 4G¹ تجمدت - ولم يكن هناك أحد للضغط على زر إعادة الضبط.

لا تراقب وحدة مراقبة الأجهزة (Watchdog) حالة وحدة 4G في الوقت الفعلي بشكل مباشر. إنها تراقب نبضات قلب النظام الرئيسي. إذا تعطلت وحدة المعالجة المركزية الرئيسية أو نظام التشغيل - بما في ذلك الأعطال الناتجة عن فشل مكدس 4G - فإن وحدة المراقبة تجبر على إعادة ضبط كاملة للأجهزة. تتم مراقبة حالة 4G الفعلية (قوة الإشارة، تسجيل الشبكة، صحة اتصال البيانات) بواسطة برامج خفية (daemons) تعمل على المعالج الرئيسي، وليس بواسطة شريحة وحدة المراقبة نفسها.

مراقبة وحدة مراقبة الأجهزة (Watchdog) لحالة وحدة 4G في كاميرا PTZ

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

هل تتحقق وحدة المراقبة من استجابة “الأمر AT” من المودم كل 60 ثانية؟

اعتقدت سابقًا أن وحدة مراقبة الأجهزة ترسل أوامر AT إلى المودم بنفسها. لا يعمل الأمر بهذه الطريقة.

وحدة مراقبة الأجهزة نفسها لا ترسل أوامر AT. إنها دائرة مؤقت بسيطة. يرسل برنامج خفي (daemon) على المعالج الرئيسي أوامر AT مثل AT, AT+CREG?, أو AT+CSQ إلى المودم على فترات منتظمة. إذا توقف المودم عن الاستجابة، يتوقف البرنامج عن تغذية وحدة المراقبة، ثم تقوم وحدة المراقبة بتشغيل إعادة ضبط للأجهزة.

عملية التحقق من أوامر AT لوحدة المراقبة لمودم 4G

كيف تعمل سلسلة البرامج والأجهزة فعليًا

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

وحدة المراقبة ليس لديها منفذ UART. ليس لديها القدرة على تحليل أوامر AT. إنها لا تعرف ما AT+CREG? يعني. لا يعرف ما هو المودم.

إذن من يرسل أوامر AT؟ عملية برمجية - عادةً خادم لينكس⁵ أو خيط مراقبة مخصص - تعمل على المعالج الرئيسي. تقوم هذه العملية بما يلي:

1. يفتح المنفذ التسلسلي المتصل بمودم 4G (عادةً /dev/ttyUSB0 أو ما شابه).
2. يرسل AT وينتظر موافق.
3. إذا موافق عاد، فإن برنامج المودم يعمل.
4. يرسل AT+CREG? للتحقق من تسجيل الشبكة.
5. يرسل AT+CSQ للتحقق من قوة الإشارة.
6. إذا نجحت جميع الفحوصات، يقوم الخادم بتغذية جهاز المراقبة (يكتب إلى /dev/watchdog أو يتبدّل دبوس GPIO).

ماذا يحدث عندما يتجمد المودم

إذا تجمد برنامج المودم، فلن تحصل أوامر AT على أي رد. يكتشف الخادم ذلك. قد يحاول 3 مرات. إذا فشلت جميع المحاولات، يكون لدى الخادم خياران:

نوع الفشل	استجابة البرنامج	دور الحارس
انتهاء مهلة أمر AT (تجمد البرنامج الثابت للمودم)	يحاول البرنامج الخفي إعادة تعيين المودم عبر التحكم في طاقة GPIO	الحارس غير متورط بعد
فشل إعادة تعيين المودم، يتعطل البرنامج الخفي نفسه	يتوقف البرنامج الخفي عن تغذية الحارس	فيضان مؤقت الحارس → إعادة تشغيل النظام بالكامل
ذعر نواة نظام التشغيل الرئيسي بسبب برنامج تشغيل المودم USB	لا يمكن لأي عملية تغذية الحارس	فيضان مؤقت الحارس → إعادة تشغيل النظام بالكامل

النقطة الأساسية: الحارس هو خط الدفاع الأخير, ، وليس المستجيب الأول. يقوم البرنامج الخفي بالعمل الذكي. يقوم الحارس بالعمل الوحشي.

سؤال الـ 60 ثانية

هل يحدث هذا كل 60 ثانية؟ يعتمد على تصميم البرنامج الثابت. في معظم أجهزة توجيه 4G الصناعية وكاميرات PTZ التي عملت معها، تكون فترة الاستقصاء قابلة للتكوين - عادةً ما بين 30 ثانية و 5 دقائق. مهلة الحارس⁴ عادة ما يتم تعيينها لفترة أطول (مثل 90-120 ثانية) لتجنب عمليات إعادة التشغيل الخاطئة أثناء اضطرابات الشبكة المؤقتة.

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

هل يمكن للأجهزة إعادة ضبط المودم بشكل مستقل عن نظام التشغيل الرئيسي إذا تجمد مكدس الاتصالات الخلوية؟

هذا هو السؤال الذي يبقيني مستيقظًا في الليل. إذا تعطل نواة لينكس، هل يمكن لأي شيء إنقاذ اتصال 4G؟

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

دائرة إعادة تعيين مودم مستقلة لمؤقت المراقبة

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

ليست كل تطبيقات مؤقت المراقبة متساوية. هناك فرق كبير بين مؤقت مراقبة أساسي ومؤقت مراقبة صناعي مصمم بشكل صحيح.

المستوى 1: إعادة تعيين النظام بالكامل (أساسي)

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

المستوى 2: إعادة تعيين مودم مستقل (متقدم)

في التصميمات الأفضل - خاصة في بوابات 4G الصناعية وأنظمة PTZ الشمسية المتطورة - يحتوي MCU لمؤقت المراقبة على خط GPIO منفصل متصل بدائرة التحكم في الطاقة لمودم 4G. هذا يسمح باستعادة مرحلية:

مرحلة إعادة التعيين	الإجراء	وقت الاستعادة	تأثير النظام
المرحلة 1: إعادة تعيين ناعمة	يرسل البرنامج AT+CFUN=1,1 لإعادة تشغيل المودم	10-15 ثانية	لا يوجد انقطاع في النظام
المرحلة 2: إعادة تعيين قاسية	يقوم متحكم المراقبة بسحب دبوس RESET_N إلى الأسفل لمدة 500 مللي ثانية	15-20 ثانية	يبقى النظام الرئيسي قيد التشغيل
المرحلة 3: إعادة تشغيل الطاقة	يقوم متحكم المراقبة بقطع MOSFET، وإيقاف تشغيل VCC للمودم لمدة 3-5 ثوانٍ	20-30 ثانية	يبقى النظام الرئيسي قيد التشغيل
المرحلة 4: إعادة تشغيل كاملة	يتجاوز متحكم المراقبة، ويعيد تشغيل طاقة النظام بأكمله	60-90 ثانية	تتم إعادة تشغيل كل شيء

لماذا هذا مهم لمواقع الطاقة الشمسية عن بعد

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

يمكن لمتحكم مراقبة مصمم جيدًا مع إعادة تعيين مستقلة للمودم إصلاح 80% من مشكلات 4G دون لمس النظام الرئيسي. يستمر تشفير الفيديو. يبقى متحكم محرك PTZ مهيأ. يعاد تشغيل المودم فقط.

ماذا تسأل المورد الخاص بك

عند تقييم كاميرا PTZ أو نظام 4G بالطاقة الشمسية من الصين، اطرح هذه الأسئلة المحددة:

• هل لدى متحكم المراقبة GPIO منفصل متصل بالتحكم في طاقة مودم 4G؟
• هل يمكن لمتحكم المراقبة إعادة تعيين المودم فقط دون إعادة تشغيل النظام الأساسي بأكمله؟
• ما هي مدة دورة الطاقة للمودم (كم من الوقت يتم قطع VCC)؟
• هل يتم التحكم في طاقة المودم من خلال مفتاح MOSFET⁶ أو فقط من خلال GPIO الخاص بـ SoC (والذي لن يعمل إذا كان SoC متجمدًا)؟

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

هل ستسجل وحدة المراقبة “قوة الإشارة” و “معرف الخلية” قبل تشغيل إعادة التشغيل القسري؟

لقد واجهت مواقع أعيد تشغيلها 5 مرات في ليلة واحدة. بدون سجلات، لم يكن لدي أي فكرة عما إذا كانت مشكلة إشارة، أو مشكلة في الأجهزة، أو مشكلة في الطاقة.

لا يسجل المؤقت الأساسي للأجهزة أي بيانات - ليس لديه ذاكرة للسجلات. ومع ذلك، يمكن لنظام مؤقت متقدم مع MCU مخصص وتخزين غير متطاير (EEPROM أو flash) تسجيل آخر قوة إشارة معروفة (RSSI/RSRP)، ومعرف الخلية، وسبب إعادة التشغيل، وجهد البطارية قبل تشغيل إعادة الضبط. هذه البيانات حاسمة للتشخيص عن بعد.

تسجيل المؤقت لقوة الإشارة ومعرف الخلية قبل إعادة التشغيل

لماذا يغير تسجيل ما قبل إعادة التشغيل كل شيء

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

مع تسجيل ما قبل إعادة التشغيل، تحصل على مسار جنائي. إليك ما يجب أن يسجله نظام جيد:

ما الذي يجب تسجيله

يجب أن يكتب برنامج مراقبة مصمم جيدًا البيانات التالية إلى تخزين غير متطاير قبل يتوقف عن تغذية المؤقت:

• الطابع الزمني لآخر اتصال شبكة ناجح
• مؤشر قوة الإشارة المستلمة / مؤشر قوة الإشارة المرجعية المستلمة / مؤشر نسبة الإشارة إلى الضوضاء - مقاييس جودة الإشارة من AT+CSQ أو AT+QENG
• معرف الخلية و LAC — إلى أي برج خلوي كان المودم متصلاً (من AT+CREG? أو AT+CEREG?)
• رمز سبب إعادة التشغيل — هل كان مهلة AT، فشل تسجيل الشبكة، مهلة الارتباط بالبيانات، أم انخفاض الجهد؟
• جهد البطارية وقت الفشل
• درجة حرارة المودم (إذا كانت متاحة عبر أمر AT)
• عدد محاولات إعادة التشغيل المتتالية

أين يتم تخزين هذه البيانات؟

شريحة مراقبة الأجهزة نفسها (مثل TPS3823 أو MAX6369) لا تحتوي على تخزين. إنها مجرد مؤقت ومخرج إعادة تعيين. يجب أن يتم التسجيل إما بواسطة:

1. برنامج النظام — يكتب إلى ملف على وحدة تخزين الفلاش الرئيسية للنظام قبل تشغيل إعادة التشغيل. المخاطرة: إذا تعطل النواة، لا يمكن لبرنامج النظام كتابة أي شيء.
2. MCU مراقبة الأجهزة — إذا تم تنفيذ مراقبة الأجهزة كوحدة تحكم دقيقة منفصلة (مثل STM32 أو ATtiny)، فيمكن أن تحتوي على ذاكرة EEPROM خاصة بها. يرسل النظام الرئيسي بيانات الحالة إلى MCU بشكل دوري عبر I2C أو UART. يخزن MCU آخر حالة معروفة. حتى لو تعطل النظام الرئيسي، لا يزال لدى MCU البيانات.

كيفية الوصول إلى السجلات عن بُعد

بعد إعادة تشغيل النظام وإعادة الاتصال بشبكة 4G، يجب على برنامج المراقبة:

1. قراءة سجلات إعادة التشغيل المخزنة من EEPROM أو الفلاش.
2. تحميلها إلى خادم السحابة الخاص بك أو منصة VMS.
3. تنبيهك عبر البريد الإلكتروني أو إشعار الدفع مع سبب إعادة التشغيل وبيانات الإشارة.

هذا يحول إعادة التشغيل العمياء إلى معلومات قابلة للتنفيذ. إذا رأيت أن كل إعادة تشغيل تحدث عندما ينخفض RSRP عن -110 dBm، فأنت تعلم أنك بحاجة إلى هوائي أفضل أو برج مختلف. إذا حدثت كل إعادة تشغيل عندما ينخفض جهد البطارية عن 11.2 فولت، فأنت تعلم أنك بحاجة إلى بطارية أكبر أو لوحة شمسية.

حقل السجل	أمر المصدر	القيمة التشخيصية
RSRP / RSSI	AT+CSQ أو AT+QENG="servingcell"	يحدد الإشارة الضعيفة كسبب جذري
معرف الخلية / LAC	AT+CEREG?	يكتشف مشاكل تسليم البرج
جهد البطارية	قراءة ADC من متحكم Watchdog	يحدد حلقات التمهيد المتعلقة بالطاقة
سبب إعادة التشغيل	علامة حالة برنامج الخفي	يميز تعطل المودم عن تعطل نظام التشغيل
عمليات إعادة التشغيل المتتالية	عداد في EEPROM	يشغل وضع حماية النوم العميق

كيف أمنع وحدة المراقبة من إعادة التشغيل أثناء تحديث شرعي للبرامج الثابتة؟

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

قبل البدء في تحديث البرنامج الثابت², ، يجب على البرنامج إما تعطيل مؤقت ساعة المراقبة أو تمديد مهلته إلى قيمة أطول من مدة التحديث. تدعم معظم أنظمة Linux هذا من خلال واجهة /dev/watchdog باستخدام WDIOC_SETTIMEOUT استدعاء ioctl. بالنسبة لأجهزة مراقبة الأجهزة (watchdogs) التي لا تحتوي على تحكم برمجي، يجب أن تستمر عملية التحديث في تغذية جهاز المراقبة على فترات منتظمة طوال مدة التحديث.

منع إعادة تشغيل جهاز المراقبة أثناء تحديث البرامج الثابتة عبر الهواء (OTA)

مشكلة تحديث البرامج الثابتة

قد يستغرق تحديث البرامج الثابتة (خاصةً تحديث عبر الهواء (OTA)⁷ عبر شبكة 4G) من 5 إلى 30 دقيقة اعتمادًا على حجم الملف وسرعة الاتصال. خلال هذا الوقت، يكون النظام مشغولاً بالكتابة إلى ذاكرة الفلاش. قد لا يقوم بتشغيل مهام المراقبة العادية الخاصة به. قد لا يقوم بتغذية جهاز المراقبة.

إذا تم ضبط مهلة جهاز المراقبة على 120 ثانية واستغرقت كتابة البرامج الثابتة 10 دقائق، فسيقوم جهاز المراقبة بإعادة تشغيل النظام عند علامة الدقيقتين. يتم كتابة نصف ذاكرة الفلاش. لا يمكن لبرنامج الإقلاع (bootloader) العثور على صورة صالحة. يصبح الجهاز معطلاً (bricked). تحتاج الآن إلى إرسال شخص إلى الموقع باستخدام مبرمج JTAG أو وحدة تحكم تسلسلية.

هذا ليس خطرًا نظريًا. لقد رأيته يحدث في الميدان.

ثلاث استراتيجيات لمنع ذلك

الاستراتيجية 1: تعطيل جهاز المراقبة أثناء التحديث

في أنظمة Linux، يمكنك تعطيل جهاز المراقبة عن طريق كتابة الحرف السحري V إلى /dev/watchdog ثم إغلاق واصف الملف. هذا يخبر برنامج تشغيل جهاز المراقبة بإيقاف المؤقت.

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

الاستراتيجية 2: تمديد مهلة جهاز المراقبة

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

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

الاستراتيجية 3: تغذية جهاز المراقبة من عملية التحديث

النهج الأكثر قوة هو جعل عملية تحديث البرامج الثابتة نفسها تغذي جهاز المراقبة على فترات منتظمة. بعد كتابة كل كتلة بيانات إلى ذاكرة الفلاش، تكتب عملية التحديث إلى /dev/watchdog لإعادة تعيين المؤقت.

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

ما يجب أن تطلبه من المورد الخاص بك

إذا كانت كاميرا PTZ الخاصة بك تدعم تحديثات البرامج الثابتة عبر الهواء (OTA) عبر شبكة 4G (ويجب أن تفعل ذلك، للنشر عن بُعد)، فاسأل المورد الخاص بك:

• ماذا يحدث لجهاز مراقبة النظام أثناء تحديث البرنامج الثابت؟
• هل تقوم عملية التحديث بتغذية جهاز مراقبة النظام، أم أنها تعطله؟
• هل يدعم محمل الإقلاع أقسام A/B أو التراجع عند فشل التحديث؟
• هل اختبر المورد فشل الطاقة أثناء تحديث البرنامج الثابت؟ هل يتعافى الجهاز؟

هذه الأسئلة تفصل بين الشركات المصنعة الجادة والمجمّعين الذين يضعون المكونات على لوحة. يمكن أن تكلف كاميرا معطلة في موقع شمسي بعيد ما بين 500 دولار و 2000 دولار في تكاليف إرسال شاحنة - أكثر بكثير من الكاميرا نفسها.

الخاتمة

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

---

1. نظرة عامة على تقنية شبكات الجوال 4G ومعايير الوحدات. ︎↩︎ 2. معلومات عامة حول البرامج الثابتة وإجراءات التحديث. ︎↩︎ 3. أساسيات أنظمة الطاقة الشمسية للمعدات عن بُعد. ︎↩︎ 4. مذكرة تطبيق تقنية حول مؤقتات المراقبة في الأنظمة المدمجة. ︎↩︎ 5. شرح العمليات الخلفية في أنظمة شبيهة بيونكس. ︎↩︎ 6. كيفية استخدام MOSFETs للتبديل الكهربائي في الدوائر. ︎↩︎ 7. تعريف تحديثات البرامج الثابتة عبر الهواء للأجهزة المتصلة. ︎↩︎ 8. شرح تحديثات نظام A/B للإقلاع الموثوق بعد فشل التحديثات. ︎↩︎