नमस्कार!

यो सम्भवतः कुनै गोप्य छैन कि क्लाउड भिडियो निगरानी सेवाहरू हालसालै लोकप्रियता प्राप्त गर्दै छन्। र यो स्पष्ट छ कि यो किन हुन्छ, भिडियो "भारी" सामग्री हो, जसको भण्डारणलाई पूर्वाधार र ठूलो मात्रामा डिस्क भण्डारण चाहिन्छ। अन-प्रिमाइसेस भिडियो निगरानी प्रणाली प्रयोग गर्दा सयौं निगरानी क्यामेराहरू प्रयोग गर्ने संस्था र धेरै क्यामेराहरू भएका एक व्यक्तिगत प्रयोगकर्ताका लागि दुवै सञ्चालन र समर्थन गर्न कोष चाहिन्छ।

क्लाउड भिडियो निगरानी प्रणालीहरूले ग्राहकहरूलाई अवस्थित भिडियो भण्डारण र प्रशोधन पूर्वाधार प्रदान गरेर यो समस्या समाधान गर्दछ। क्लाउड भिडियो निगरानी क्लाइन्टले क्यामेरालाई इन्टरनेटमा जडान गर्न र आफ्नो क्लाउड खातामा लिङ्क गर्न आवश्यक छ।

क्लाउडमा क्यामेरा जडान गर्न धेरै प्राविधिक तरिकाहरू छन्। निस्सन्देह, सबैभन्दा सुविधाजनक र सस्तो विधि भनेको सर्भर वा रेकर्डर जस्ता अतिरिक्त उपकरणहरूको सहभागिता बिना क्यामेरा सीधा जडान र क्लाउडसँग काम गर्दछ।

यो गर्नको लागि, क्लाउडसँग काम गर्ने सफ्टवेयर मोड्युल क्यामेरामा स्थापना गर्न आवश्यक छ। यद्यपि, यदि हामी सस्तो क्यामेराहरूको बारेमा कुरा गर्छौं भने, तिनीहरूसँग धेरै सीमित हार्डवेयर स्रोतहरू छन्, जुन लगभग 100% क्यामेरा विक्रेताको नेटिभ फर्मवेयरले ओगटेको छ, र क्लाउड प्लगइनको लागि आवश्यक कुनै स्रोतहरू छैनन्। ivideon बाट विकासकर्ताहरूले यो समस्या समर्पित गरे लेख, जसले सस्तो क्यामेराहरूमा प्लगइन स्थापना गर्न नसक्ने कारण बताउँछ। नतिजाको रूपमा, क्यामेराको न्यूनतम मूल्य 5000 rubles ($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 Ants
गैरकानूनी

समाज
Hisilicon 3518E
Hisilicon 3518E

राम
64MB
64MB

फ्ल्यास
16MB
8MB

वाइफाइ
mt7601/bcm43143
-

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

इथरनेट
-
+

MicroSD
+
+

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

सभामुखले
+
+

IRLed
+
+

IRCut
+
+

हामीले उनीहरूसँग सुरु गर्यौं।

हामी हाल Hisilicon 3516/3518 chipsets, साथै 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 मेगाबाइट RAM मा पहुँच छ।

साथै uboot को छेउमा एक विशेष ब्लक भनिन्छ reg_info, जसले DDR प्रारम्भ गर्नको लागि निम्न-स्तर लिपि र SoC को धेरै प्रणाली दर्ताहरू समावेश गर्दछ। सामग्री reg_info क्यामेरा मोडेलमा निर्भर गर्दछ, र यदि यो सही छैन भने, क्यामेराले uboot लोड गर्न सक्षम हुनेछैन, तर लोडिङको धेरै प्रारम्भिक चरणमा स्थिर हुनेछ।

सुरुमा, जब हामीले विक्रेता समर्थन बिना काम गर्यौं, हामीले यो ब्लकलाई मूल क्यामेरा फर्मवेयरबाट प्रतिलिपि गर्यौं।

लिनक्स कर्नेल र rootfs

क्यामेराहरूले लिनक्स कर्नेल प्रयोग गर्छन्, जुन चिपको SDK को अंश हो; सामान्यतया यी 3.x शाखाबाट भर्खरको कर्नेलहरू होइनन्, त्यसैले हामीले प्राय: यस तथ्यलाई सामना गर्नुपर्ने हुन्छ कि अतिरिक्त उपकरणहरूको लागि ड्राइभरहरू प्रयोग गरिएको कर्नेलसँग मिल्दो छैनन्। , र हामीले तिनीहरूलाई कर्नेल क्यामेराहरूमा ब्याक-पोर्ट गर्नुपर्छ।

अर्को मुद्दा कर्नेलको आकार हो। जब FLASH साइज 8MB मात्र हुन्छ, तब प्रत्येक बाइटको गणना हुन्छ र हाम्रो कार्य होसियारीपूर्वक सबै प्रयोग नगरिएका कर्नेल प्रकार्यहरूलाई असक्षम पार्नु हो ताकि साइजलाई न्यूनतममा कम गर्न सकियोस्।

Rootfs एक आधारभूत फाइल प्रणाली हो। यसमा समावेश छ busybox, वाइफाइ मोड्युल ड्राइभरहरू, मानक प्रणाली पुस्तकालयहरूको सेट, जस्तै libld и libc, साथै हाम्रो सफ्टवेयर, जो LED नियन्त्रण तर्क, नेटवर्क जडान व्यवस्थापन र फर्मवेयर अद्यावधिकहरूको लागि जिम्मेवार छ।

रूट फाइल प्रणाली initramfs को रूपमा कर्नेलसँग जोडिएको छ र निर्माणको परिणाम स्वरूप हामीले एउटा फाइल पाउँछौं। uImage, जसले कर्नेल र rootfs दुवै समावेश गर्दछ।

भिडियो आवेदन

फर्मवेयरको सबैभन्दा जटिल र स्रोत-गहन भाग भनेको अनुप्रयोग हो, जसले भिडियो-अडियो क्याप्चर, भिडियो एन्कोडिङ, तस्विर प्यारामिटरहरू कन्फिगर गर्दछ, भिडियो एनालिटिक्स लागू गर्दछ, उदाहरणका लागि, गति वा ध्वनि डिटेक्टरहरू, PTZ नियन्त्रण गर्दछ र दिन स्विच गर्न जिम्मेवार छ। राती मोडहरू।

एउटा महत्त्वपूर्ण, म कुञ्जी पनि भन्न चाहन्छु, सुविधा भनेको भिडियो अनुप्रयोगले क्लाउड प्लगइनसँग कसरी अन्तरक्रिया गर्छ।

परम्परागत समाधानहरूमा 'विक्रेता फर्मवेयर + क्लाउड प्लगइन', जसले सस्तो हार्डवेयरमा काम गर्न सक्दैन, क्यामेरा भित्रको भिडियो RTSP प्रोटोकल मार्फत प्रसारित हुन्छ - र यो एक ठूलो ओभरहेड हो: सकेट, अनावश्यक सिस्कलहरू मार्फत डाटा प्रतिलिपि गर्ने र प्रसारण गर्ने।

यहाँ हामी साझा मेमोरी मेकानिजम प्रयोग गर्छौं - क्यामेरा सफ्टवेयर कम्पोनेन्टहरू बीचको सकेट मार्फत भिडियो प्रतिलिपि वा पठाइएको छैन, यसैले क्यामेराको मामूली हार्डवेयर क्षमताहरू प्रयोग गरेर इष्टतम र सावधानीपूर्वक।

उपप्रणाली अपडेट गर्नुहोस्

विशेष गर्वको बिन्दु अनलाइन फर्मवेयर अपडेटहरूको लागि दोष-सहिष्णु उपप्रणाली हो।

मलाई समस्या व्याख्या गरौं। फर्मवेयर अपडेट गर्नु प्राविधिक रूपमा परमाणु अपरेशन होइन, र यदि अपडेटको बीचमा पावर विफलता भयो भने, फ्ल्यास मेमोरीले "अण्डर-राइटन" नयाँ फर्मवेयरको अंश समावेश गर्दछ। यदि तपाइँ विशेष उपायहरू लिनुहुन्न भने, क्यामेरा त्यसपछि "इँटा" बन्नेछ जुन सेवा केन्द्रमा लैजानु आवश्यक छ।

हामीले पनि यो समस्याको सामना गरेका छौं । अद्यावधिकको समयमा क्यामेरा बन्द भए पनि, यसले स्वचालित रूपमा र प्रयोगकर्ताको हस्तक्षेप बिना क्लाउडबाट फर्मवेयर डाउनलोड गर्नेछ र सञ्चालन पुनर्स्थापना गर्नेछ।

थप विवरणमा प्रविधिलाई हेरौं:

सबैभन्दा कमजोर बिन्दु लिनक्स कर्नेल र रूट फाइल प्रणाली संग विभाजन अधिलेखन हो। यदि यी कम्पोनेन्टहरू मध्ये एक बिग्रिएको छ भने, क्यामेराले uboot बुटलोडर भन्दा बाहिर बूट गर्दैन, जसले क्लाउडबाट फर्मवेयर डाउनलोड गर्न सक्दैन।

यसको मतलब हामीले अपडेट प्रक्रियाको क्रममा कुनै पनि समयमा क्यामेरामा काम गर्ने कर्नेल र rootfs छ भनी सुनिश्चित गर्न आवश्यक छ। यस्तो देखिन्छ कि सरल समाधान भनेको कर्नेलको दुई प्रतिहरू फ्ल्यास मेमोरीमा rootfs संग भण्डारण गर्नु हो र, यदि मुख्य कर्नेल बिग्रिएको छ भने, यसलाई ब्याकअप प्रतिलिपिबाट लोड गर्नुहोस्।

राम्रो समाधान - यद्यपि, rootfs भएको कर्नेलले लगभग 3.5MB लिन्छ र स्थायी ब्याकअपको लागि तपाईंले 3.5MB आवंटित गर्नुपर्छ। सस्तो क्यामेराहरूमा ब्याकअप कर्नेलको लागि त्यति खाली ठाउँ हुँदैन।

तसर्थ, फर्मवेयर अपडेटको समयमा कर्नेल ब्याकअप गर्न, हामी अनुप्रयोग विभाजन प्रयोग गर्छौं।
र कर्नेलसँग इच्छित विभाजन चयन गर्न, दुई आदेशहरू प्रयोग गरिन्छ bootm uboot मा - सुरुमा हामी मुख्य कर्नेल लोड गर्ने प्रयास गर्छौं र यदि यो क्षतिग्रस्त छ भने, ब्याकअप एक।

यसले सुनिश्चित गर्दछ कि कुनै पनि समयमा क्यामेरामा rootfs को साथ सही कर्नेल हुनेछ, र यसले फर्मवेयर बुट गर्न र रिस्टोर गर्न सक्षम हुनेछ।

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

फर्मवेयर निर्माण गर्न, हामी gitlab CI प्रयोग गर्छौं, जसले स्वचालित रूपमा सबै समर्थित क्यामेरा मोडेलहरूको लागि फर्मवेयर बनाउँछ, र फर्मवेयर निर्माण गरेपछि, यो स्वचालित रूपमा क्यामेरा सफ्टवेयर अपडेट सेवामा तैनात हुन्छ।

सेवाबाट, फर्मवेयर अद्यावधिकहरू हाम्रा QA परीक्षण क्यामेराहरूमा, र सबै परीक्षण चरणहरू पूरा भएपछि, प्रयोगकर्ताहरूको क्यामेराहरूमा पठाइन्छ।

सूचना सुरक्षा

यो कुनै गोप्य कुरा छैन कि आजकल सूचना सुरक्षा क्यामेरा सहित कुनै पनि IoT उपकरणको सबैभन्दा महत्त्वपूर्ण पक्ष हो। Mirai जस्ता बोटनेटहरू इन्टरनेटमा घुमिरहेका छन्, विक्रेताहरूबाट मानक फर्मवेयरको साथ लाखौं क्यामेराहरू संक्रमित गर्दै। क्यामेरा विक्रेताहरूलाई सबै उचित सम्मानको साथ, म मद्दत गर्न सक्दिन तर नोट गर्नुहोस् कि मानक फर्मवेयरले धेरै प्रकार्यहरू समावेश गर्दछ जुन क्लाउडसँग काम गर्न आवश्यक छैन, तर बोटनेटहरूले फाइदा लिन सक्ने धेरै कमजोरीहरू समावेश गर्दछ।

तसर्थ, हाम्रो फर्मवेयरमा सबै प्रयोग नगरिएको कार्यक्षमता असक्षम गरिएको छ, सबै tcp/udp पोर्टहरू बन्द छन्, र फर्मवेयर अद्यावधिक गर्दा, सफ्टवेयरको डिजिटल हस्ताक्षर जाँच गरिन्छ।

र यस बाहेक, फर्मवेयरले सूचना सुरक्षा प्रयोगशालामा नियमित परीक्षण गर्दछ।

निष्कर्षमा

अब हाम्रो फर्मवेयर सक्रिय रूपमा भिडियो निगरानी परियोजनाहरूमा प्रयोग गरिन्छ। सायद ती मध्ये सबैभन्दा ठूलो रूसी संघ को राष्ट्रपति को चुनाव को दिन मतदान को प्रसारण हो।
यो परियोजनाले हाम्रो फर्मवेयरसँग 70 हजार भन्दा बढी क्यामेराहरू समावेश गर्यो, जुन हाम्रो देशको मतदान केन्द्रहरूमा स्थापना गरिएको थियो।

धेरै जटिल, र केहि ठाउँहरूमा, त्यो समयमा लगभग असम्भव समस्याहरू समाधान गरिसकेपछि, हामीले पक्कै पनि इन्जिनियरहरूको रूपमा ठूलो सन्तुष्टि पाएका छौं, तर यस बाहेक, हामीले क्यामेरा खरिदमा पनि लाखौं डलर बचत गरेका छौं। र यस अवस्थामा, बचत शब्दहरू र सैद्धांतिक गणना मात्र होइन, तर उपकरण खरिदको लागि पहिले नै पूरा भएको टेन्डरको परिणाम हो। तदनुसार, यदि हामी क्लाउड भिडियो निगरानीको बारेमा कुरा गर्छौं भने: त्यहाँ दुईवटा दृष्टिकोणहरू छन् - रणनीतिक रूपमा निम्न-स्तरको विशेषज्ञता र विकासमा निर्भर रहनुहोस्, जसले गर्दा उपकरणहरूमा ठूलो बचत हुन्छ, वा महँगो उपकरणहरू प्रयोग गर्नुहोस्, जुन, यदि तपाइँ उपभोक्ता विशेषताहरूमा विशेष रूपमा हेर्नुहुन्छ भने, व्यावहारिक रूपमा कुनै छैन। समान सस्तो भन्दा फरक।

जतिसक्दो चाँडो एकीकरण दृष्टिकोण छनोट गर्ने निर्णय गर्नु रणनीतिक रूपमा किन महत्त्वपूर्ण छ? प्लगइन विकास गर्दा, विकासकर्ताहरू निश्चित प्रविधिहरू (पुस्तकालयहरू, प्रोटोकलहरू, मापदण्डहरू) मा निर्भर हुन्छन्। र यदि महँगो उपकरणहरूको लागि मात्र टेक्नोलोजीहरूको सेट छनोट गरिएको छ भने, भविष्यमा सस्तो क्यामेराहरूमा स्विच गर्ने प्रयास सम्भवतः, कम्तिमा, धेरै लामो समय लाग्न सक्छ वा असफल पनि हुनेछ र महँगो उपकरणहरूमा फर्किनेछ।

स्रोत: www.habr.com