تحليل الفيديو: الاختيار بين المعالجة الطرفية والخادم المحلي والسحابة

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

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

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

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

يشمل تحليل الفيديو الاستقبال وفك الترميز، وإعداد الصور، والاستدلال، وتتبع الأجسام عند الحاجة، وإنتاج النتائج. وقد يضيف العرض أو التسجيل عبئًا آخر. وتوضّح NVIDIA في وثائق أداء DeepStream أن قياساتها تعتمد على التكوين، وأن العرض المرئي يُعطَّل للوصول إلى مستويات الأداء القصوى المنشورة.

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

إعداد بطاقة عبء لكل استخدام

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

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

مثال توضيحي بافتراض معدل نقل ثابت: ثمانية تدفقات بمعدل 3 Mbit/s تعادل 24 Mbit/s. وعند إرسالها باستمرار طوال 24 ساعة، تمثل نحو 259 غيغابايت من الفيديو بالوحدات العشرية، دون احتساب الزيادات المرتبطة ببروتوكولات الشبكة. العملية الحسابية هي 24 ÷ 8 × 86 400 ÷ 1 000. وهذا ليس استهلاكًا مرصودًا لدى عميل ولا سعرًا لخدمة سحابية.

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

عند عودة الاتصال، يجب إرسال البيانات المتراكمة بالتوازي مع البيانات الجديدة. والاتصال المصمّم لمعدل النقل الجاري فقط قد لا يملك الهامش اللازم. وإذا كان التحليل المحلي يرسل أحداثًا فقط، فقيسوا حجمها الحقيقي، بما في ذلك المقتطفات المصاحبة؛ فكلمة «بيانات وصفية» وحدها لا تحدّد متطلبات الشبكة.

تمثل منصات Jetson أحد خيارات الحوسبة المضمّنة، لكن اسمها لا يحدّد قدرة عامة على معالجة عدد معين من تدفقات الفيديو. ومع JetPack 6.2، الذي أُعلن عنه في يناير 2025، أضافت NVIDIA، من بين أمور أخرى، وضعَي 40 W وMAXN SUPER لوحدات Orin NX ضمن التكوينات المحددة. وتطلب الشركة المصنّعة التحقق من التصميم الحراري والأداء عمليًا.

لا يعبّر الوضع المختار للوحدة عن استهلاك الجهاز كاملًا. فالتخزين والواجهات والكاميرات التي قد تُغذّى منه والمكوّنات الأخرى تدخل أيضًا في الحساب. وقد يتطلب تغيير الوضع إعادة فحص الهيكل والتغذية الكهربائية وإصدار البرمجيات؛ فلا ينبغي التعامل معه كخيار بسيط بلا تبعات.

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

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

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

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

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

وثّقوا أيضًا الحسابات والتدفقات المسموح بها والسجلات وصلاحيات الصيانة. وفي المشروع الفرنسي، يوفر دليل ANSSI/CNPP لأنظمة المراقبة بالفيديو إطارًا لمراجعة البنية والأمن المنطقي. ولا يعفي موقع الحوسبة من هذا العمل.

يجب أن يكون للتحديث مسؤول، ونافذة تنفيذ، وإجراء استعادة مختبَر. وتميّز وثائق Jetson Linux R36.4 بين الآليات المتاحة والمكوّنات الإضافية اللازمة لبناء حل تحديث آمن. تحققوا دائمًا من مسار ترقية الإصدار المثبّت فعليًا.

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

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

يتيح هذا المنهج مناقشة البنية استنادًا إلى حقائق. ولاستكشاف تحليل الفيديو مع Videtics، انطلقوا من الاستخدامات المعروضة في Perception ، وللمشروعات المضمّنة من متطلبات قطاع النقل. وبعد ذلك يجب التحقق من التكوين المختار باستخدام تدفقاتكم وقيود الخدمة لديكم.