مرحبا بالجميع!

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

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

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

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

لقد نجحنا في حل هذه المشكلة. إذا كنت مهتما بكيفية - ويلكوم تحت القط

القليل من التاريخ

في عام 2016 ، بدأنا في تطوير منصة مراقبة بالفيديو قائمة على السحابة لشركة Rostelecom.

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

الآن في سوق كاميرات IP لا توجد حلول تكامل عالمية: لكل مورد طريقته الخاصة لتثبيت المكون الإضافي ومجموعة واجهات برمجة التطبيقات الخاصة به لكي تعمل البرامج الثابتة وآلية تحديث فريدة.

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

كان أول بائع هو Hikvision - أحد رواد العالم في سوق الكاميرات ، حيث يوفر واجهة برمجة تطبيقات موثقة جيدًا ودعم فني هندسي كفء.

على كاميرات Hikvision ، أطلقنا مشروعنا التجريبي الأول ، المراقبة بالفيديو السحابي ، Video Comfort.

على الفور تقريبًا بعد الإطلاق ، بدأ مستخدمونا في طرح أسئلة حول إمكانية توصيل كاميرات الطرف الثالث الأرخص بالخدمة.

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

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

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

في تلك اللحظة ، لم يكن لدينا شيء على الإطلاق. لا شيء على الإطلاق.

لم يكن جميع البائعين تقريبًا على استعداد للعمل معنا عند هذا المستوى المنخفض. لا توجد معلومات حول الدوائر والمكونات ، ولا توجد شرائح SDK رسمية ووثائق المستشعر.
لا يوجد دعم فني سواء.

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

كانت أول نماذج الكاميرات التي ملأنا بها النتوءات هي XIAOMI Yi Ants و Hikvision و Dahua و Spezvision و D-Link كاميرات والعديد من الكاميرات الصينية الرخيصة للغاية.

تقنية

كاميرات مبنية على شرائح Hisilicon 3518E. خصائص أجهزة الكاميرات هي كما يلي:

بدأنا معهم.

ندعم حاليًا شرائح Hisilicon 3516/3518 ، بالإضافة إلى Ambarella S2L / S2LM. عدد طرازات الكاميرا هو العشرات.

تكوين البرامج الثابتة

uboot

uboot هو محمل الإقلاع ، بعد تشغيل الطاقة ، يتم تشغيله أولاً ، تهيئة الجهاز وتحميل نواة لينكس.

البرنامج النصي لتحميل الكاميرا تافه للغاية:

bootargs=mem=38M console=ttyAMA0,115200 rootfstype=ramfs mtdparts=hi_sfc:256K(boot),64K(tech),4096K(kernel),8192K(app),-(config) hw_type=101 bootcmd=sf probe 0; sf read 0x82000000 0x50000 0x400000; bootm 0x82000000; setenv bootargs $(bootargs) bkp=1; sf read 0x82000000 0x450000 0x400000; bootm 0x82000000 

من الميزات ، يتم استدعاء bootm ، المزيد عن ذلك لاحقًا ، عندما نصل إلى النظام الفرعي للتحديث.

انتبه إلى mem=38M الخط mem=38M . نعم ، نعم ، هذا ليس خطأ مطبعيًا - تتوفر فقط 38 ميغابايت من ذاكرة الوصول العشوائي لـ Linux kernel وجميع التطبيقات الشاملة.

يوجد أيضًا بجوار uboot كتلة خاصة تسمى reg_info ، والتي تحتوي على برنامج نصي reg_info التهيئة DDR منخفض وعدد من تسجيلات نظام SoC. تعتمد محتويات reg_info على طراز الكاميرا ، وإذا لم تكن صحيحة ، فلن تتمكن الكاميرا من تنزيل uboot ، ولكنها ستعلق في مرحلة مبكرة جدًا من التحميل.

في البداية ، عندما عملنا بدون دعم البائعين ، قمنا ببساطة بنسخ هذه الكتلة من البرامج الثابتة الأصلية للكاميرا.

نواة لينكس والجذور

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

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

Rootfs هو نظام ملفات أساسي. يتضمن busybox وحدة التشغيل ، وحدة تشغيل وحدة wifi ، مجموعة من مكتبات النظام القياسية ، مثل libld و libc ، بالإضافة إلى برنامج التطوير ، المسؤول عن منطق التحكم LED وإدارة اتصال الشبكة وتحديث البرامج الثابتة.

نظام الملفات الجذري متصل بالنواة على أنه initramfs ، ونتيجة للتجميع ، نحصل على ملف uImage واحد يحتوي على كل من kernel و rootfs.

تطبيق فيديو

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

من المهم ، حتى أن أقول ميزة رئيسية - كيف يتفاعل تطبيق الفيديو مع المكون الإضافي السحابي.

في "البرامج الثابتة للبائعين + المكونات الإضافية السحابية" للحلول التقليدية ، والتي لا يمكن أن تعمل على أجهزة رخيصة الثمن ، يتم نقل الفيديو داخل الكاميرا باستخدام بروتوكول RTSP - وهذا يمثل عبءًا ضخمًا: نسخ البيانات ونقلها عبر مأخذ التوصيل ، و syscalls غير الضرورية.

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

تحديث النظام الفرعي

من الأشياء التي تفتخر بها بشكل خاص النظام الفرعي المتسامح لتحديثات البرامج الثابتة عبر الإنترنت.

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

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

دعونا نحلل التقنية بمزيد من التفصيل:

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

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

حل جيد - ومع ذلك ، فإن kernel مع rootfs يستغرق حوالي 3.5 ميغابايت وللنسخ الاحتياطي الدائم تحتاج إلى تخصيص 3.5 ميغابايت. على أرخص الكاميرات ، ببساطة لا توجد مساحة حرة كبيرة للنواة الاحتياطية.

لذلك ، نواة قسم النسخ الاحتياطي أثناء تحديث البرامج الثابتة ، نستخدم قسم التطبيق.
bootm القسم اللازم باستخدام النواة ، يتم استخدام أمرين bootm في uboot - في البداية نحاول تحميل النواة الرئيسية وإذا كانت تالفة ، فإن النسخ الاحتياطي.

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

نظام CI / CD لتجميع ونشر البرامج الثابتة

لبناء البرامج الثابتة ، نستخدم gitlab CI ، حيث يتم تلقائيًا جمع البرامج الثابتة لجميع طرازات الكاميرات المدعومة ، وبعد إنشاء البرامج الثابتة ، يتم نشرها تلقائيًا في خدمة تحديث برامج الكاميرا.

من الخدمة ، يتم تسليم تحديثات البرامج الثابتة إلى كاميرات اختبار ضمان الجودة ، وعند الانتهاء من جميع مراحل الاختبار ، إلى كاميرات المستخدمين.

أمن المعلومات

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

لذلك ، يتم تعطيل جميع الوظائف غير المستخدمة في البرامج الثابتة لدينا ، ويتم إغلاق جميع منافذ tcp / udp ، وعند تحديث البرنامج الثابت ، يتم التحقق من التوقيع الرقمي للبرنامج.

بالإضافة إلى ذلك ، يتم اختبار البرامج الثابتة بانتظام في مختبر أمن المعلومات.

الخلاصة

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

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

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