გაუმარჯოს ყველას!

ალბათ საიდუმლო არ არის, რომ ღრუბლოვანი ვიდეო თვალთვალის სერვისები ბოლო დროს პოპულარობას იძენს. და გასაგებია, რატომ ხდება ეს, ვიდეო არის „მძიმე“ კონტენტი, რომლის შესანახად საჭიროა ინფრასტრუქტურა და დიდი რაოდენობით დისკის შენახვა. შიდა ვიდეო თვალთვალის სისტემის გამოყენება მოითხოვს სახსრებს ფუნქციონირებისა და მხარდაჭერისთვის, როგორც ორგანიზაციისთვის, რომელიც იყენებს ასობით სათვალთვალო კამერას, ასევე ინდივიდუალური მომხმარებლისთვის რამდენიმე კამერით.

ღრუბლოვანი ვიდეო სათვალთვალო სისტემები ამ პრობლემას აგვარებენ მომხმარებლების არსებული ვიდეო შენახვისა და დამუშავების ინფრასტრუქტურით. ღრუბლოვანი ვიდეო მეთვალყურეობის კლიენტს უბრალოდ სჭირდება კამერის ინტერნეტთან დაკავშირება და მის ღრუბელ ანგარიშთან დაკავშირება.

არსებობს რამდენიმე ტექნოლოგიური გზა კამერების ღრუბელთან დასაკავშირებლად. უდავოა, რომ ყველაზე მოსახერხებელი და იაფი მეთოდია ის, რომ კამერა პირდაპირ აკავშირებს და მუშაობს ღრუბელთან, დამატებითი აღჭურვილობის მონაწილეობის გარეშე, როგორიცაა სერვერი ან ჩამწერი.

ამისათვის აუცილებელია, რომ კამერაზე დამონტაჟდეს ღრუბელთან მომუშავე პროგრამული მოდული. თუმცა, თუ ვსაუბრობთ იაფ კამერებზე, მაშინ მათ აქვთ ძალიან შეზღუდული ტექნიკის რესურსები, რომლებიც თითქმის 100%-ით არის დაკავებული კამერის გამყიდველის მშობლიური პროგრამული უზრუნველყოფით და არ არის საჭირო რესურსები ღრუბლოვანი დანამატისთვის. დეველოპერებმა ivideon-დან მიუძღვნეს ეს პრობლემა მუხლი, რაც განმარტავს, რატომ არ შეუძლიათ დანამატის დაყენება იაფ კამერებზე. შედეგად, კამერის მინიმალური ფასია 5000 რუბლი ($80 დოლარი) და მილიონობით ფული იხარჯება აღჭურვილობაზე.

ჩვენ წარმატებით მოვაგვარეთ ეს პრობლემა. თუ გაინტერესებთ როგორ - კეთილი იყოს თქვენი მობრძანება ჭრილში

პატარა ისტორიის

2016 წელს დავიწყეთ როსტელეკომისთვის ღრუბლოვანი ვიდეო თვალთვალის პლატფორმის შემუშავება.

კამერის პროგრამული უზრუნველყოფის კუთხით, პირველ ეტაპზე ჩვენ მივყვებოდით „სტანდარტულ“ გზას ასეთი ამოცანების შესასრულებლად: შევიმუშავეთ ჩვენი საკუთარი მოდული, რომელიც დაინსტალირებულია გამყიდველის კამერის სტანდარტულ firmware-ში და მუშაობს ჩვენს ღრუბელთან. თუმცა, აღსანიშნავია, რომ დიზაინის დროს ჩვენ გამოვიყენეთ ყველაზე მსუბუქი და ეფექტური გადაწყვეტილებები (მაგალითად, პროტობუფის, libev, mbedtls-ის მარტივი C დანერგვა და სრულიად მიტოვებული მოსახერხებელი, მაგრამ მძიმე ბიბლიოთეკები, როგორიცაა boost)

ამჟამად, IP კამერის ბაზარზე უნივერსალური ინტეგრაციის გადაწყვეტილებები არ არსებობს: თითოეულ გამყიდველს აქვს მოდულის ინსტალაციის საკუთარი გზა, API-ების საკუთარი ნაკრები firmware-ის მუშაობისთვის და უნიკალური განახლების მექანიზმი.

ეს ნიშნავს, რომ თითოეული კამერის გამყიდველისთვის აუცილებელია ინდივიდუალურად შეიმუშაოს ინტეგრაციის პროგრამული უზრუნველყოფის ყოვლისმომცველი ფენა. და განვითარების დაწყების დროს მიზანშეწონილია იმუშაოთ მხოლოდ 1 გამყიდველთან, რათა გუნდის ძალისხმევა კონცენტრირდეს ღრუბელთან მუშაობის ლოგიკის შემუშავებაზე.

პირველი გამყიდველი არჩეული იყო Hikvision, ერთ-ერთი მსოფლიო ლიდერი კამერების ბაზარზე, რომელიც უზრუნველყოფს კარგად დოკუმენტირებული API და კომპეტენტური საინჟინრო ტექნიკური მხარდაჭერა.

ჩვენ დავიწყეთ ჩვენი პირველი საპილოტე პროექტი, ღრუბლოვანი ვიდეო თვალთვალის ვიდეო კომფორტი, Hikvision კამერების გამოყენებით.

გაშვებისთანავე ჩვენმა მომხმარებლებმა დაიწყეს კითხვების დასმა სხვა მწარმოებლებისგან იაფი კამერების სერვისთან დაკავშირების შესაძლებლობის შესახებ.

მე უარვყავი თითოეული გამყიდველისთვის ინტეგრაციის ფენის დანერგვის შესაძლებლობა თითქმის დაუყოვნებლივ - რადგან ის ცუდად მასშტაბირებადია და სერიოზულ ტექნიკურ მოთხოვნებს აკისრებს კამერის აპარატურას. კამერის ღირებულება, რომელიც აკმაყოფილებს ამ შეყვანის მოთხოვნებს: ~60-70$

ამიტომ, გადავწყვიტე უფრო ღრმად ჩამეძირა - შემექმნა საკუთარი firmware კამერებისთვის ნებისმიერი გამყიდველისგან. ეს მიდგომა მნიშვნელოვნად ამცირებს მოთხოვნებს კამერის ტექნიკის რესურსებზე - იმიტომ ღრუბელთან მუშაობის ფენა ბევრად უფრო ეფექტურად არის ინტეგრირებული ვიდეო აპლიკაციასთან და არ არის ზედმეტი გამოუყენებელი ცხიმი firmware-ში.

და რაც მთავარია, დაბალ დონეზე კამერასთან მუშაობისას შესაძლებელია ტექნიკის AES გამოყენება, რომელიც დაშიფვრავს მონაცემებს დაბალი სიმძლავრის CPU-ზე დამატებითი დატვირთვის შექმნის გარეშე.

იმ მომენტში საერთოდ არაფერი გვქონდა. Საერთოდ არაფერი.

თითქმის ყველა მოვაჭრე არ იყო მზად ჩვენთან ასეთ დაბალ დონეზე სამუშაოდ. არ არსებობს ინფორმაცია მიკროსქემისა და კომპონენტების შესახებ, არ არსებობს ჩიპსეტების ოფიციალური SDK და სენსორის დოკუმენტაცია.
ასევე არ არის ტექნიკური მხარდაჭერა.

ყველა კითხვაზე პასუხი უნდა გაეცეს საპირისპირო ინჟინერიის - ცდისა და შეცდომის გზით. მაგრამ ჩვენ შევძელით.

პირველი კამერის მოდელები, რომლებზეც ჩვენ გამოვცადეთ იყო Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link კამერები და რამდენიმე ულტრა იაფი უსახელო ჩინური კამერა.

ტექნიკა

კამერები დაფუძნებული Hisilicon 3518E ჩიპსეტზე. კამერების ტექნიკის მახასიათებლები შემდეგია:

Xiaomi Yi Ants
noname

SoC
ჰისილიკონი 3518E
ჰისილიკონი 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

სენსორი
ov9732 (720p)
ov9712 (720p)

ეთერნეტის
-
+

MicroSD
+
+

მიკროფონი
+
+

სპიკერი
+
+

IRLed
+
+

IRCut
+
+

დავიწყეთ მათთან ერთად.

ამჟამად ჩვენ მხარს ვუჭერთ 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. დიახ, დიახ, ეს არ არის შეცდომა - Linux-ის ბირთვს და ყველა, ყველა, ყველა აპლიკაციას აქვს წვდომა მხოლოდ 38 მეგაბაიტზე ოპერატიული მეხსიერება.

ასევე uboot-ის გვერდით არის სპეციალური ბლოკი ე.წ reg_info, რომელიც შეიცავს დაბალი დონის სკრიპტს DDR-ის ინიციალიზაციისთვის და SoC-ის სისტემური რეგისტრების რიგს. შინაარსი reg_info დამოკიდებულია კამერის მოდელზე და თუ ის არ არის სწორი, კამერა ვერც კი იტვირთება uboot, მაგრამ გაიყინება ჩატვირთვის ძალიან ადრეულ ეტაპზე.

თავდაპირველად, როდესაც ვმუშაობდით გამყიდველის მხარდაჭერის გარეშე, ჩვენ უბრალოდ დავაკოპირეთ ეს ბლოკი ორიგინალური კამერის პროგრამული უზრუნველყოფიდან.

Linux-ის ბირთვი და rootfs

კამერები იყენებენ Linux-ის ბირთვს, რომელიც ჩიპის SDK-ის ნაწილია; ჩვეულებრივ, ეს არ არის უახლესი ბირთვები 3.x ფილიალიდან, ამიტომ ხშირად გვიწევს საქმე იმ ფაქტთან, რომ დამატებითი აღჭურვილობის დრაივერები არ არის თავსებადი გამოყენებულ ბირთვთან. და ჩვენ უნდა დავაბრუნოთ ისინი ბირთვის კამერებზე.

კიდევ ერთი საკითხი არის ბირთვის ზომა. როდესაც FLASH ზომა არის მხოლოდ 8 მბ, მაშინ ყველა ბაიტი ითვლის და ჩვენი ამოცანაა გულდასმით გამორთოთ ყველა გამოუყენებელი ბირთვის ფუნქცია, რათა ზომა მინიმუმამდე შევამციროთ.

Rootfs არის ძირითადი ფაილური სისტემა. Ეს შეიცავს busybox, wifi მოდულის დრაივერები, სტანდარტული სისტემის ბიბლიოთეკების ნაკრები, მაგ libld и libc, ისევე როგორც ჩვენი პროგრამული უზრუნველყოფა, რომელიც პასუხისმგებელია LED კონტროლის ლოგიკაზე, ქსელური კავშირის მენეჯმენტზე და პროგრამული უზრუნველყოფის განახლებებზე.

root ფაილური სისტემა უკავშირდება ბირთვს initramfs-ის სახით და აწყობის შედეგად ვიღებთ ერთ ფაილს. uImage, რომელიც შეიცავს როგორც ბირთვს, ასევე rootf-ებს.

ვიდეო აპლიკაცია

firmware-ის ყველაზე რთული და რესურსზე ინტენსიური ნაწილია აპლიკაცია, რომელიც უზრუნველყოფს ვიდეო-აუდიო გადაღებას, ვიდეოს დაშიფვრას, აკონფიგურირებს სურათის პარამეტრებს, ახორციელებს ვიდეო ანალიტიკას, მაგალითად, მოძრაობის ან ხმის დეტექტორებს, აკონტროლებს PTZ-ს და პასუხისმგებელია დღის გადართვაზე და ღამის რეჟიმები.

მნიშვნელოვანი, მე კი ვიტყოდი, საკვანძო მახასიათებელია ის, თუ როგორ ურთიერთქმედებს ვიდეო აპლიკაცია ღრუბლოვან დანამატთან.

ტრადიციულ გადაწყვეტილებებში "მყიდველის პროგრამული უზრუნველყოფა + ღრუბლოვანი დანამატი", რომელიც არ მუშაობს იაფ აპარატურაზე, კამერის შიგნით ვიდეო გადაიცემა RTSP პროტოკოლით - და ეს არის უზარმაზარი ზედნადები: მონაცემთა კოპირება და გადაცემა სოკეტის საშუალებით, არასაჭირო სისტემის ზარები.

აქ ჩვენ ვიყენებთ საზიარო მეხსიერების მექანიზმს - ვიდეო არ არის კოპირებული და არ იგზავნება სოკეტის საშუალებით კამერის პროგრამული უზრუნველყოფის კომპონენტებს შორის, რითაც ოპტიმალურად და ფრთხილად ვიყენებთ კამერის მოკრძალებულ აპარატურულ შესაძლებლობებს.

ქვესისტემის განახლება

განსაკუთრებული სიამაყის წერტილი არის დეფექტების ტოლერანტული ქვესისტემა ონლაინ firmware განახლებისთვის.

ნება მომეცით აგიხსნათ პრობლემა. პროგრამული უზრუნველყოფის განახლება ტექნიკურად არ არის ატომური ოპერაცია და თუ განახლების შუა პერიოდში ელექტროენერგიის გათიშვა მოხდა, მაშინ ფლეშ მეხსიერება შეიცავს "ქვედაწერილი" ახალი პროგრამული უზრუნველყოფის ნაწილს. თუ არ მიიღებთ განსაკუთრებულ ზომებს, კამერა შემდეგ გახდება "აგური", რომელიც უნდა გადაიტანოთ სერვის ცენტრში.

ჩვენ ამ პრობლემასაც გავუმკლავდით. მაშინაც კი, თუ კამერა გამორთულია განახლების დროს, ის ავტომატურად და მომხმარებლის ჩარევის გარეშე ჩამოტვირთავს firmware-ს ღრუბლიდან და აღადგენს მუშაობას.

მოდით შევხედოთ ტექნიკას უფრო დეტალურად:

ყველაზე დაუცველი წერტილი არის დანაყოფის გადაწერა Linux kernel-ით და root ფაილური სისტემით. თუ რომელიმე კომპონენტი დაზიანებულია, კამერა საერთოდ არ ჩაიტვირთება uboot bootloader-ის მიღმა, რომელიც ვერ ჩამოტვირთავს firmware-ს ღრუბლიდან.

ეს ნიშნავს, რომ განახლების პროცესის ნებისმიერ დროს უნდა დავრწმუნდეთ, რომ კამერას ჰქონდეს მოქმედი ბირთვი და rootfs. როგორც ჩანს, უმარტივესი გამოსავალი იქნება ბირთვის ორი ასლის მუდმივად შენახვა rootf-ებით ფლეშ მეხსიერებაზე და, თუ ძირითადი ბირთვი დაზიანებულია, ჩატვირთეთ იგი სარეზერვო ასლიდან.

კარგი გამოსავალია - თუმცა, ბირთვი rootf-ით იკავებს დაახლოებით 3.5 მბ-ს და მუდმივი სარეზერვო ასლისთვის საჭიროა გამოყოთ 3.5 მბ. ყველაზე იაფ კამერებს უბრალოდ არ აქვთ ამდენი თავისუფალი ადგილი სარეზერვო ბირთვისთვის.

ამიტომ, პროგრამული უზრუნველყოფის განახლების დროს ბირთვის სარეზერვო ასლისთვის, ჩვენ ვიყენებთ აპლიკაციის დანაყოფს.
ხოლო ბირთვით სასურველი დანაყოფის შესარჩევად გამოიყენება ორი ბრძანება bootm uboot-ში - თავიდან ვცდილობთ ჩატვირთოთ მთავარი ბირთვი და თუ დაზიანებულია, მაშინ სარეზერვო.

ეს უზრუნველყოფს, რომ ნებისმიერ დროს კამერას ექნება სწორი ბირთვი rootf-ებით და შეძლებს ჩატვირთოს და აღადგინოს firmware.

CI/CD სისტემა პროგრამული უზრუნველყოფის შესაქმნელად და განლაგებისთვის

პროგრამული უზრუნველყოფის შესაქმნელად, ჩვენ ვიყენებთ gitlab CI-ს, რომელიც ავტომატურად აშენებს პროგრამულ უზრუნველყოფას ყველა მხარდაჭერილი კამერის მოდელისთვის და პროგრამული უზრუნველყოფის შექმნის შემდეგ, ის ავტომატურად განლაგდება კამერის პროგრამული უზრუნველყოფის განახლების სერვისში.

სერვისიდან, პროგრამული უზრუნველყოფის განახლებები მიეწოდება ჩვენს QA ტესტის კამერებს, ხოლო ტესტირების ყველა ეტაპის დასრულების შემდეგ, მომხმარებლების კამერებს.

Ინფორმაციის დაცვა

საიდუმლო არ არის, რომ დღესდღეობით ინფორმაციის უსაფრთხოება ნებისმიერი IoT მოწყობილობის, მათ შორის კამერების, ყველაზე მნიშვნელოვანი ასპექტია. ბოტნეტები, როგორიცაა Mirai, ტრიალებს ინტერნეტში და აინფიცირებს მილიონობით კამერას სტანდარტული პროგრამული უზრუნველყოფით გამყიდველებისგან. კამერის გამყიდველების მიმართ მთელი პატივისცემით, არ შემიძლია არ აღვნიშნო, რომ სტანდარტული firmware შეიცავს უამრავ ფუნქციას, რომელიც არ არის საჭირო ღრუბელთან მუშაობისთვის, მაგრამ შეიცავს ბევრ დაუცველობას, რომლითაც ბოტნეტები სარგებლობენ.

ამიტომ, ჩვენს firmware-ში ყველა გამოუყენებელი ფუნქცია გამორთულია, ყველა tcp/udp პორტი დახურულია და firmware-ის განახლებისას მოწმდება პროგრამული უზრუნველყოფის ციფრული ხელმოწერა.

გარდა ამისა, firmware გადის რეგულარულ ტესტირებას ინფორმაციის უსაფრთხოების ლაბორატორიაში.

დასკვნა

ახლა ჩვენი firmware აქტიურად გამოიყენება ვიდეო თვალთვალის პროექტებში. მათგან, ალბათ, ყველაზე დიდია რუსეთის ფედერაციის პრეზიდენტის არჩევის დღეს ხმის მიცემის გადაცემა.
პროექტში ჩართული იყო 70 ათასზე მეტი კამერა ჩვენი firmware-ით, რომლებიც დამონტაჟდა ჩვენს ქვეყანაში საარჩევნო უბნებზე.

არაერთი რთული და ზოგან, თუნდაც იმ დროს თითქმის შეუძლებელი პრობლემების გადაჭრის შემდეგ, ჩვენ, რა თქმა უნდა, დიდი კმაყოფილება მივიღეთ, როგორც ინჟინრები, მაგრამ ამის გარდა, ჩვენ ასევე დავზოგეთ მილიონობით დოლარი კამერების შეძენაზე. და ამ შემთხვევაში, დანაზოგი არ არის მხოლოდ სიტყვები და თეორიული გამოთვლები, არამედ აღჭურვილობის შესაძენად უკვე დასრულებული ტენდერის შედეგები. შესაბამისად, თუ ვსაუბრობთ ღრუბლოვანი ვიდეო მეთვალყურეობის შესახებ: არსებობს ორი მიდგომა - სტრატეგიულად დაეყრდნოთ დაბალი დონის ექსპერტიზას და განვითარებას, რაც იწვევს დიდ დანაზოგს აღჭურვილობაზე, ან გამოიყენეთ ძვირადღირებული აღჭურვილობა, რომელიც, თუ კონკრეტულად დააკვირდებით მომხმარებლის მახასიათებლებს, პრაქტიკულად არ არის. განსხვავდება მსგავსი იაფისგან.

რატომ არის სტრატეგიულად მნიშვნელოვანი ინტეგრაციის მიდგომის არჩევის რაც შეიძლება ადრე გადაწყვეტილება? მოდულის შემუშავებისას დეველოპერები ეყრდნობიან გარკვეულ ტექნოლოგიებს (ბიბლიოთეკები, პროტოკოლები, სტანდარტები). და თუ ტექნოლოგიების ნაკრები არჩეულია მხოლოდ ძვირადღირებული აღჭურვილობისთვის, მაშინ მომავალში იაფ კამერებზე გადასვლის მცდელობა, სავარაუდოდ, სულ მცირე, ძალიან დიდი დრო დასჭირდება ან თუნდაც ჩავარდება და მოხდება ძვირადღირებული აღჭურვილობის დაბრუნება.

წყარო: www.habr.com