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

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

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

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

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

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

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

في عام 2016 ، بدأنا في تطوير نظام أساسي للمراقبة بالفيديو على السحابة لـ Rostelecom.

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

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

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

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

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

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

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

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

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

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

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

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

كانت كاميرات Xiaomi Yi Ants و Hikvision و Dahua و Spezvision و D-Link وعدد قليل من الكاميرات الصينية الرخيصة للغاية التي لم يتم ذكر اسمها هي أول موديلات الكاميرا التي قمنا بحشو المطبات عليها.

تقنية

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

شياومي يي النمل
بدون اسم

شركة نفط الجنوب
هيسيليكون 3518E
هيسيليكون 3518E

رامات
64MB
64MB

عاجل جدا
16MB
8MB

واي فاي
MT7601 / bcm43143
-

الاستشعار
ov9732 (720 بكسل)
ov9712 (720 بكسل)

إيثرنت
-
+

مايكرو
+
+

ميكروفون
+
+

مكبرات الصوت
+
+

IRLed
+
+

إيركوت
+
+

بدأنا معهم.

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

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

أوبوت

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. نعم ، نعم ، هذا ليس خطأ مطبعي - نواة لينكس والتطبيقات الشاملة بها فقط 38 ميغا بايت من ذاكرة الوصول العشوائي المتاحة.

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

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

Linux kernel و rootfs

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

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

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

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

تطبيق فيديو

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اختتام

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

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

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

المصدر: www.habr.com