हॅलो प्रत्येकजण!

अलीकडे क्लाउड व्हिडिओ पाळत ठेवणे सेवा लोकप्रिय होत आहेत हे कदाचित गुपित नाही. आणि हे का घडते हे स्पष्ट आहे, व्हिडिओ "भारी" सामग्री आहे, ज्याच्या स्टोरेजसाठी पायाभूत सुविधा आणि मोठ्या प्रमाणात डिस्क स्टोरेज आवश्यक आहे. ऑन-प्रिमाइसेस व्हिडिओ पाळत ठेवणे प्रणाली वापरण्यासाठी शेकडो पाळत ठेवणे कॅमेरे वापरणाऱ्या संस्थेसाठी आणि अनेक कॅमेरे असलेल्या वैयक्तिक वापरकर्त्यासाठी, ऑपरेट आणि समर्थन करण्यासाठी निधीची आवश्यकता असते.

क्लाउड व्हिडिओ पाळत ठेवणे प्रणाली ग्राहकांना विद्यमान व्हिडिओ स्टोरेज आणि प्रक्रिया पायाभूत सुविधा प्रदान करून ही समस्या सोडवते. क्लाउड व्हिडिओ पाळत ठेवणाऱ्या क्लायंटला फक्त कॅमेरा इंटरनेटशी कनेक्ट करणे आणि त्याच्या क्लाउड खात्याशी लिंक करणे आवश्यक आहे.

कॅमेरे क्लाउडशी जोडण्याचे अनेक तांत्रिक मार्ग आहेत. निःसंशयपणे, सर्वात सोयीस्कर आणि स्वस्त पद्धत म्हणजे सर्व्हर किंवा रेकॉर्डरसारख्या अतिरिक्त उपकरणांच्या सहभागाशिवाय कॅमेरा थेट क्लाउडशी कनेक्ट होतो आणि कार्य करतो.

हे करण्यासाठी, क्लाउडसह कार्य करणारे सॉफ्टवेअर मॉड्यूल कॅमेरावर स्थापित करणे आवश्यक आहे. तथापि, जर आपण स्वस्त कॅमेऱ्यांबद्दल बोललो, तर त्यांच्याकडे हार्डवेअर संसाधने खूप मर्यादित आहेत, जे जवळजवळ 100% कॅमेरा विक्रेत्याच्या मूळ फर्मवेअरद्वारे व्यापलेले आहेत आणि क्लाउड प्लगइनसाठी कोणतीही संसाधने आवश्यक नाहीत. ivideon मधील विकसकांनी ही समस्या समर्पित केली एक लेख, जे ते स्वस्त कॅमेर्‍यांवर प्लगइन का स्थापित करू शकत नाहीत हे स्पष्ट करते. परिणामी, कॅमेराची किमान किंमत 5000 रूबल ($80 डॉलर) आणि उपकरणांवर लाखो पैसे खर्च केले जातात.

आम्ही ही समस्या यशस्वीरित्या सोडवली आहे. आपल्याला कसे स्वारस्य असल्यास - कटमध्ये आपले स्वागत आहे

इतिहास एक बिट

2016 मध्ये, आम्ही Rostelecom साठी क्लाउड व्हिडिओ देखरेख प्लॅटफॉर्म विकसित करण्यास सुरुवात केली.

कॅमेरा सॉफ्टवेअरच्या बाबतीत, पहिल्या टप्प्यावर आम्ही अशा कार्यांसाठी "मानक" मार्गाचा अवलंब केला: आम्ही आमचे स्वतःचे प्लगइन विकसित केले, जे विक्रेत्याच्या कॅमेराच्या मानक फर्मवेअरमध्ये स्थापित केले आहे आणि आमच्या क्लाउडसह कार्य करते. तथापि, हे लक्षात घेण्यासारखे आहे की डिझाइन दरम्यान आम्ही सर्वात हलके आणि कार्यक्षम उपाय वापरले (उदाहरणार्थ, प्रोटोबफ, लिबेव्ह, mbedtls ची साधी सी अंमलबजावणी आणि बूस्ट सारख्या सोयीस्कर परंतु जड लायब्ररी पूर्णपणे सोडून दिल्या आहेत)

सध्या, आयपी कॅमेरा मार्केटवर कोणतेही सार्वत्रिक एकत्रीकरण उपाय नाहीत: प्रत्येक विक्रेत्याकडे प्लगइन स्थापित करण्याचा स्वतःचा मार्ग, फर्मवेअर ऑपरेट करण्यासाठी API चा स्वतःचा संच आणि एक अद्वितीय अद्यतन यंत्रणा आहे.

याचा अर्थ असा की प्रत्येक कॅमेरा विक्रेत्यासाठी वैयक्तिकरित्या एकीकरण सॉफ्टवेअरचा सर्वसमावेशक स्तर विकसित करणे आवश्यक आहे. आणि डेव्हलपमेंट सुरू करताना, क्लाउडसोबत काम करण्यासाठी लॉजिक विकसित करण्यावर टीमच्या प्रयत्नांवर लक्ष केंद्रित करण्यासाठी फक्त 1 विक्रेत्यासोबत काम करण्याचा सल्ला दिला जातो.

निवडलेला पहिला विक्रेता Hikvision होता, जो कॅमेरा मार्केटमधील जागतिक नेत्यांपैकी एक होता, ज्याने एक चांगले-दस्तऐवजीकरण केलेले API आणि सक्षम अभियांत्रिकी तांत्रिक समर्थन प्रदान केले.

आम्ही Hikvision कॅमेरे वापरून आमचा पहिला पायलट प्रकल्प, क्लाउड व्हिडिओ पाळत ठेवणे व्हिडिओ कम्फर्ट लाँच केले.

लॉन्च झाल्यानंतर लगेचच, आमच्या वापरकर्त्यांनी इतर उत्पादकांकडून स्वस्त कॅमेरे सेवेशी जोडण्याच्या शक्यतेबद्दल प्रश्न विचारण्यास सुरुवात केली.

मी प्रत्येक विक्रेत्यासाठी एकीकरण स्तर लागू करण्याचा पर्याय जवळजवळ लगेचच नाकारला - कारण ते खराब प्रमाणात वाढवता येत नाही आणि कॅमेरा हार्डवेअरवर गंभीर तांत्रिक आवश्यकता लादते. या इनपुट आवश्यकता पूर्ण करणाऱ्या कॅमेऱ्याची किंमत: ~60-70$

म्हणून, मी खोलवर खोदण्याचा निर्णय घेतला - कोणत्याही विक्रेत्याकडून कॅमेर्‍यांसाठी माझे स्वतःचे फर्मवेअर बनवायचे. हा दृष्टिकोन कॅमेरा हार्डवेअर संसाधनांची आवश्यकता लक्षणीयरीत्या कमी करतो - कारण क्लाउडसह कार्य करण्यासाठीचा स्तर व्हिडिओ अनुप्रयोगासह अधिक प्रभावीपणे एकत्रित केला आहे आणि फर्मवेअरमध्ये अनावश्यक न वापरलेली चरबी नाही.

आणि महत्त्वाचे म्हणजे कमी पातळीवर कॅमेरासोबत काम करताना, हार्डवेअर AES वापरणे शक्य आहे, जे कमी-शक्तीच्या CPU वर अतिरिक्त भार निर्माण न करता डेटा एन्क्रिप्ट करते.

त्या क्षणी आमच्याकडे काहीच नव्हते. अजिबात नाही.

जवळपास सर्वच विक्रेते एवढ्या खालच्या पातळीवर आमच्यासोबत काम करायला तयार नव्हते. सर्किटरी आणि घटकांबद्दल कोणतीही माहिती नाही, चिपसेट आणि सेन्सर दस्तऐवजीकरणाचे अधिकृत SDK नाही.
तांत्रिक सहाय्य देखील नाही.

सर्व प्रश्नांची उत्तरे उलट अभियांत्रिकी - चाचणी आणि त्रुटीद्वारे द्यावी लागतील. पण आम्ही व्यवस्थापित केले.

आम्ही चाचणी केलेल्या पहिल्या कॅमेरा मॉडेल्समध्ये Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link कॅमेरे आणि अनेक अत्यंत स्वस्त निनावी चीनी कॅमेरे होते.

तंत्र

Hisilicon 3518E चिपसेटवर आधारित कॅमेरे. कॅमेऱ्यांची हार्डवेअर वैशिष्ट्ये खालीलप्रमाणे आहेत:

Xiaomi Yi मुंग्या
नाव नाही

सोसायटी
हिसिलिकॉन 3518E
हिसिलिकॉन 3518E

रॅम
64MB
64MB

फ्लॅश
16MB
8MB

वायफाय
mt7601/bcm43143
-

सेंसर
ov9732 (720p)
ov9712 (720p)

इथरनेट
-
+

MicroSD
+
+

मायक्रोफोन
+
+

स्पीकर
+
+

IRLed
+
+

IRCut
+
+

आम्ही त्यांच्यापासून सुरुवात केली.

आम्ही सध्या 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. होय, होय, ही टायपो नाही - लिनक्स कर्नल आणि सर्व, सर्व, सर्व अनुप्रयोगांना फक्त 38 मेगाबाइट्स RAM मध्ये प्रवेश आहे.

तसेच uboot च्या पुढे एक विशेष ब्लॉक आहे ज्याला म्हणतात reg_info, ज्यामध्ये DDR सुरू करण्यासाठी निम्न-स्तरीय स्क्रिप्ट आणि SoC चे अनेक सिस्टम रजिस्टर असतात. सामग्री reg_info कॅमेरा मॉडेलवर अवलंबून आहे, आणि जर ते बरोबर नसेल, तर कॅमेरा uboot लोड करू शकणार नाही, परंतु लोड होण्याच्या अगदी सुरुवातीच्या टप्प्यावर गोठवेल.

सुरुवातीला, जेव्हा आम्ही विक्रेता समर्थनाशिवाय काम केले, तेव्हा आम्ही मूळ कॅमेरा फर्मवेअरवरून हा ब्लॉक कॉपी केला.

लिनक्स कर्नल आणि रूटएफ

कॅमेरे लिनक्स कर्नल वापरतात, जो चिपच्या SDK चा भाग आहे; सहसा हे 3.x शाखेतील नवीनतम कर्नल नसतात, म्हणून आम्हाला अनेकदा या वस्तुस्थितीला सामोरे जावे लागते की अतिरिक्त उपकरणांसाठी ड्रायव्हर्स वापरलेल्या कर्नलशी सुसंगत नाहीत. , आणि आम्हाला ते कर्नल कॅमेऱ्यांवर बॅक-पोर्ट करावे लागतील.

दुसरा मुद्दा कर्नलचा आकार आहे. जेव्हा FLASH आकार फक्त 8MB असतो, तेव्हा प्रत्येक बाइट मोजला जातो आणि आकार कमीतकमी कमी करण्यासाठी सर्व न वापरलेली कर्नल फंक्शन्स काळजीपूर्वक अक्षम करणे हे आमचे कार्य आहे.

Rootfs ही मूलभूत फाइल प्रणाली आहे. यांचा समावेश होतो busybox, वायफाय मॉड्यूल ड्रायव्हर्स, मानक सिस्टम लायब्ररींचा संच, जसे की libld и libc, तसेच आमचे सॉफ्टवेअर, जे LED कंट्रोल लॉजिक, नेटवर्क कनेक्शन व्यवस्थापन आणि फर्मवेअर अपडेटसाठी जबाबदार आहे.

रूट फाइल सिस्टम कर्नलशी initramfs म्हणून जोडलेली असते आणि बिल्डच्या परिणामी आम्हाला एक फाइल मिळते. uImage, ज्यामध्ये कर्नल आणि rootfs दोन्ही असतात.

व्हिडिओ अनुप्रयोग

फर्मवेअरचा सर्वात जटिल आणि संसाधन-केंद्रित भाग हा अनुप्रयोग आहे, जो व्हिडिओ-ऑडिओ कॅप्चर, व्हिडिओ एन्कोडिंग प्रदान करतो, चित्र पॅरामीटर्स कॉन्फिगर करतो, व्हिडिओ विश्लेषण लागू करतो, उदाहरणार्थ, मोशन किंवा साउंड डिटेक्टर, PTZ नियंत्रित करतो आणि दिवस बदलण्यासाठी जबाबदार असतो. रात्री मोड.

एक महत्त्वाचे, मी अगदी महत्त्वाचे म्हणेन, वैशिष्ट्य म्हणजे व्हिडिओ ऍप्लिकेशन क्लाउड प्लगइनशी कसा संवाद साधतो.

पारंपारिक सोल्यूशन्स 'विक्रेता फर्मवेअर + क्लाउड प्लगइन' मध्ये, जे स्वस्त हार्डवेअरवर कार्य करू शकत नाहीत, कॅमेरामधील व्हिडिओ RTSP प्रोटोकॉलद्वारे प्रसारित केला जातो - आणि हे एक मोठे ओव्हरहेड आहे: सॉकेट, अनावश्यक सिस्कॉलद्वारे डेटा कॉपी करणे आणि प्रसारित करणे.

येथे आम्ही सामायिक मेमरी यंत्रणा वापरतो - कॅमेरा सॉफ्टवेअर घटकांमधील सॉकेटद्वारे व्हिडिओ कॉपी केला जात नाही किंवा पाठविला जात नाही, ज्यामुळे कॅमेर्‍याच्या माफक हार्डवेअर क्षमतांचा चांगल्या प्रकारे आणि काळजीपूर्वक वापर केला जातो.

उपप्रणाली अद्यतनित करा

ऑनलाइन फर्मवेअर अद्यतनांसाठी दोष-सहिष्णु उपप्रणाली हा विशेष अभिमानाचा मुद्दा आहे.

मला समस्या समजावून सांगा. फर्मवेअर अद्ययावत करणे तांत्रिकदृष्ट्या अणू ऑपरेशन नाही आणि जर अपडेटच्या मध्यभागी पॉवर फेल झाली तर फ्लॅश मेमरीमध्ये नवीन फर्मवेअरचा “अंडर-राइटन” भाग असेल. आपण विशेष उपाययोजना न केल्यास, कॅमेरा नंतर एक "वीट" होईल ज्याला सेवा केंद्रात नेणे आवश्यक आहे.

आम्ही या समस्येचा सामना देखील केला आहे. अद्यतनादरम्यान कॅमेरा बंद केला असला तरीही, तो स्वयंचलितपणे आणि वापरकर्त्याच्या हस्तक्षेपाशिवाय क्लाउडवरून फर्मवेअर डाउनलोड करेल आणि ऑपरेशन पुनर्संचयित करेल.

चला तंत्र अधिक तपशीलवार पाहू:

लिनक्स कर्नल आणि रूट फाइल सिस्टमसह विभाजन ओव्हरराईट करणे हा सर्वात असुरक्षित मुद्दा आहे. यापैकी एक घटक खराब झाल्यास, कॅमेरा uboot बूटलोडरच्या पलीकडे बूट होणार नाही, जो क्लाउडवरून फर्मवेअर डाउनलोड करू शकत नाही.

याचा अर्थ असा की अपडेट प्रक्रियेदरम्यान कधीही कॅमेरामध्ये कर्नल आणि रूटफ कार्यरत असल्याची खात्री करणे आवश्यक आहे. असे दिसते की सर्वात सोपा उपाय म्हणजे फ्लॅश मेमरीमध्ये रूटफसह कर्नलच्या दोन प्रती सतत संग्रहित करणे आणि मुख्य कर्नल खराब झाल्यास, बॅकअप कॉपीमधून लोड करणे.

एक चांगला उपाय - तथापि, रूटफसह कर्नल सुमारे 3.5MB घेते आणि कायमस्वरूपी बॅकअपसाठी तुम्हाला 3.5MB वाटप करणे आवश्यक आहे. सर्वात स्वस्त कॅमेऱ्यांमध्ये बॅकअप कर्नलसाठी इतकी मोकळी जागा नसते.

म्हणून, फर्मवेअर अपडेट दरम्यान कर्नलचा बॅकअप घेण्यासाठी, आम्ही ऍप्लिकेशन विभाजन वापरतो.
आणि कर्नलसह इच्छित विभाजन निवडण्यासाठी, दोन आज्ञा वापरल्या जातात bootm uboot मध्ये - सुरुवातीला आम्ही मुख्य कर्नल लोड करण्याचा प्रयत्न करतो आणि जर तो खराब झाला असेल तर बॅकअप एक.

हे सुनिश्चित करते की कोणत्याही वेळी कॅमेराकडे रूटफसह योग्य कर्नल असेल, आणि तो फर्मवेअर बूट आणि पुनर्संचयित करण्यास सक्षम असेल.

फर्मवेअर तयार करण्यासाठी आणि तैनात करण्यासाठी CI/CD प्रणाली

फर्मवेअर तयार करण्यासाठी, आम्ही gitlab CI वापरतो, जे सर्व समर्थित कॅमेरा मॉडेल्ससाठी स्वयंचलितपणे फर्मवेअर तयार करते आणि फर्मवेअर तयार केल्यानंतर, ते स्वयंचलितपणे कॅमेरा सॉफ्टवेअर अपडेट सेवेमध्ये तैनात केले जाते.

सेवेतून, फर्मवेअर अपडेट्स आमच्या QA चाचणी कॅमेर्‍यांना आणि सर्व चाचणी टप्पे पूर्ण झाल्यावर, वापरकर्त्यांच्या कॅमेर्‍यांना वितरित केले जातात.

माहिती सुरक्षा

हे रहस्य नाही की आजकाल माहिती सुरक्षा ही कॅमेर्‍यांसह कोणत्याही IoT उपकरणाची सर्वात महत्त्वाची बाब आहे. Mirai सारखे Botnets इंटरनेटवर फिरत आहेत, विक्रेत्यांकडून मानक फर्मवेअरसह लाखो कॅमेरे संक्रमित करतात. कॅमेरा विक्रेत्यांबद्दल सर्व उचित आदराने, मी मदत करू शकत नाही परंतु हे लक्षात ठेवा की मानक फर्मवेअरमध्ये बरीच कार्यक्षमता असते जी क्लाउडसह कार्य करण्यासाठी आवश्यक नसते, परंतु बॉटनेट्सचा फायदा घेतात अशा अनेक असुरक्षा असतात.

म्हणून, आमच्या फर्मवेअरमधील सर्व न वापरलेली कार्यक्षमता अक्षम केली आहे, सर्व tcp/udp पोर्ट बंद आहेत आणि फर्मवेअर अद्यतनित करताना, सॉफ्टवेअरची डिजिटल स्वाक्षरी तपासली जाते.

आणि याशिवाय, फर्मवेअरची माहिती सुरक्षा प्रयोगशाळेत नियमित चाचणी केली जाते.

निष्कर्ष

आता आमचे फर्मवेअर व्हिडिओ पाळत ठेवण्याच्या प्रकल्पांमध्ये सक्रियपणे वापरले जाते. कदाचित त्यापैकी सर्वात मोठा म्हणजे रशियन फेडरेशनच्या अध्यक्षांच्या निवडणुकीच्या दिवशी मतदानाचे प्रसारण.
या प्रकल्पात आमच्या फर्मवेअरसह 70 हजाराहून अधिक कॅमेरे सामील आहेत, जे आमच्या देशातील मतदान केंद्रांवर स्थापित केले गेले होते.

अनेक गुंतागुंतीच्या, आणि काही ठिकाणी, त्या वेळी जवळजवळ अशक्यप्राय समस्यांचे निराकरण केल्यामुळे, आम्हाला अर्थातच अभियंते म्हणून खूप समाधान मिळाले, परंतु याशिवाय, आम्ही कॅमेरे खरेदीवर लाखो डॉलर्सची बचत केली. आणि या प्रकरणात, बचत केवळ शब्द आणि सैद्धांतिक गणनाच नाही तर उपकरणांच्या खरेदीसाठी आधीच पूर्ण झालेल्या निविदांचे परिणाम आहेत. त्यानुसार, जर आपण क्लाउड व्हिडिओ पाळत ठेवण्याबद्दल बोललो तर: दोन दृष्टीकोन आहेत - धोरणात्मकदृष्ट्या निम्न-स्तरीय कौशल्य आणि विकासावर अवलंबून आहे, परिणामी उपकरणांवर मोठी बचत होते किंवा महागड्या उपकरणे वापरतात, जे आपण ग्राहकांच्या वैशिष्ट्यांकडे विशेषत: पाहिल्यास, व्यावहारिकदृष्ट्या नाही. समान स्वस्तांपेक्षा भिन्न.

शक्य तितक्या लवकर एकत्रीकरण पद्धतीच्या निवडीवर निर्णय घेणे धोरणात्मकदृष्ट्या महत्त्वाचे का आहे? प्लगइन विकसित करताना, विकसक विशिष्ट तंत्रज्ञानावर (लायब्ररी, प्रोटोकॉल, मानके) अवलंबून असतात. आणि जर तंत्रज्ञानाचा संच केवळ महागड्या उपकरणांसाठी निवडला गेला असेल तर भविष्यात स्वस्त कॅमेर्‍यांवर स्विच करण्याचा प्रयत्न बहुधा कमीत कमी वेळ लागेल किंवा अगदी अयशस्वी होईल आणि महागड्या उपकरणांवर परत येईल.

स्त्रोत: www.habr.com