Hello!

Mungkin bukan rahsia lagi bahawa perkhidmatan pengawasan video awan semakin popular baru-baru ini. Dan jelas mengapa ini berlaku, video adalah kandungan "berat", storan yang memerlukan infrastruktur dan jumlah storan cakera yang besar. Menggunakan sistem pengawasan video di premis memerlukan dana untuk beroperasi dan menyokong, baik untuk organisasi yang menggunakan ratusan kamera pengawasan dan untuk pengguna individu dengan beberapa kamera.

Sistem pengawasan video awan menyelesaikan masalah ini dengan menyediakan infrastruktur storan dan pemprosesan video sedia ada kepada pelanggan. Pelanggan pengawasan video awan hanya perlu menyambungkan kamera ke Internet dan memautkannya ke akaun awannya.

Terdapat beberapa cara teknologi untuk menyambungkan kamera ke awan. Tidak dinafikan, kaedah yang paling mudah dan paling murah ialah kamera menyambung dan berfungsi secara langsung dengan awan, tanpa penyertaan peralatan tambahan seperti pelayan atau perakam.

Untuk melakukan ini, modul perisian yang berfungsi dengan awan perlu dipasang pada kamera. Walau bagaimanapun, jika kita bercakap tentang kamera murah, maka mereka mempunyai sumber perkakasan yang sangat terhad, yang hampir 100% diduduki oleh perisian tegar asli vendor kamera, dan tiada sumber yang diperlukan untuk pemalam awan. Pemaju dari ivideon menumpukan masalah ini artikel, yang menerangkan sebab mereka tidak boleh memasang pemalam pada kamera murah. Akibatnya, harga minimum kamera ialah 5000 rubel ($80 dolar) dan berjuta-juta wang yang dibelanjakan untuk peralatan.

Kami telah berjaya menyelesaikan masalah ini. Jika anda berminat dengan cara - selamat datang ke potongan

Sedikit sejarah

Pada 2016, kami mula membangunkan platform pengawasan video awan untuk Rostelecom.

Dari segi perisian kamera, pada peringkat pertama kami mengikuti laluan "standard" untuk tugasan sedemikian: kami membangunkan pemalam kami sendiri, yang dipasang dalam perisian tegar standard kamera vendor dan berfungsi dengan awan kami. Walau bagaimanapun, perlu diingat bahawa semasa reka bentuk kami menggunakan penyelesaian yang paling ringan dan cekap (contohnya, pelaksanaan C biasa bagi protobuf, libev, mbedtls dan perpustakaan mudah tetapi berat yang ditinggalkan sepenuhnya seperti boost)

Pada masa ini, tiada penyelesaian penyepaduan universal di pasaran kamera IP: setiap vendor mempunyai cara tersendiri untuk memasang pemalam, set API sendiri untuk mengendalikan perisian tegar dan mekanisme kemas kini yang unik.

Ini bermakna bahawa bagi setiap vendor kamera adalah perlu untuk membangunkan lapisan perisian penyepaduan yang komprehensif secara individu. Dan pada masa memulakan pembangunan, adalah dinasihatkan untuk bekerja hanya dengan 1 vendor untuk menumpukan usaha pasukan untuk membangunkan logik untuk bekerja dengan awan.

Vendor pertama yang dipilih ialah Hikvision, salah satu peneraju dunia dalam pasaran kamera, menyediakan API yang didokumentasikan dengan baik dan sokongan teknikal kejuruteraan yang cekap.

Kami melancarkan projek perintis pertama kami, pengawasan video awan Keselesaan Video, menggunakan kamera Hikvision.

Hampir sejurus selepas pelancaran, pengguna kami mula bertanya soalan tentang kemungkinan menyambungkan kamera yang lebih murah daripada pengeluar lain kepada perkhidmatan.

Saya menolak pilihan untuk melaksanakan lapisan integrasi untuk setiap vendor dengan serta-merta - kerana ia tidak berskala dan mengenakan keperluan teknikal yang serius pada perkakasan kamera. Kos kamera yang memenuhi keperluan input ini: ~60-70$

Oleh itu, saya memutuskan untuk menggali lebih mendalam - untuk membuat perisian tegar saya sendiri untuk kamera daripada mana-mana vendor. Pendekatan ini mengurangkan keperluan untuk sumber perkakasan kamera dengan ketara - kerana Lapisan untuk bekerja dengan awan jauh lebih berkesan disepadukan dengan aplikasi video, dan tidak ada lemak yang tidak diperlukan yang tidak diperlukan dalam perisian tegar.

Dan apa yang penting ialah apabila bekerja dengan kamera pada tahap rendah, adalah mungkin untuk menggunakan perkakasan AES, yang menyulitkan data tanpa membuat beban tambahan pada CPU berkuasa rendah.

Pada masa itu kami tidak mempunyai apa-apa. Tiada apa-apa pun.

Hampir semua vendor tidak bersedia untuk bekerjasama dengan kami pada tahap yang begitu rendah. Tiada maklumat tentang litar dan komponen, tiada SDK rasmi cipset dan dokumentasi sensor.
Juga tiada sokongan teknikal.

Semua soalan perlu dijawab melalui kejuruteraan terbalik—percubaan dan kesilapan. Tetapi kami berjaya.

Model kamera pertama yang kami uji ialah Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, kamera D-Link dan beberapa kamera Cina tanpa nama yang sangat murah.

Teknik

Kamera berdasarkan set cip Hisilicon 3518E. Ciri-ciri perkakasan kamera adalah seperti berikut:

Xiaomi Yi Ants
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

KILAT
16MB
8MB

WiFi
mt7601/bcm43143
-

sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

mikrofon
+
+

Speaker
+
+

IRLed
+
+

IRCut
+
+

Kami bermula dengan mereka.

Pada masa ini kami menyokong cipset Hisilicon 3516/3518, serta Ambarella S2L/S2LM. Terdapat berpuluh-puluh model kamera.

Komposisi perisian tegar

uboot

uboot ialah pemuat but, ia but dahulu selepas dihidupkan, memulakan perkakasan dan memuatkan kernel linux.

Skrip pemuatan kamera agak remeh:

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

Salah satu cirinya ialah ia dipanggil dua kali bootm, lebih lanjut mengenai perkara ini sedikit kemudian, apabila kita sampai ke subsistem kemas kini.

Beri perhatian kepada barisan mem=38M. Ya, ya, ini bukan kesilapan menaip - kernel Linux dan semua, semua, semua aplikasi mempunyai akses kepada hanya 38 megabait RAM.

Juga di sebelah uboot terdapat blok khas yang dipanggil reg_info, yang mengandungi skrip peringkat rendah untuk memulakan DDR dan beberapa daftar sistem SoC. Kandungan reg_info bergantung pada model kamera, dan jika ia tidak betul, kamera tidak akan dapat memuatkan uboot, tetapi akan membeku pada peringkat awal pemuatan.

Pada mulanya, apabila kami bekerja tanpa sokongan vendor, kami hanya menyalin blok ini daripada perisian tegar kamera asal.

Linux kernel dan rootfs

Kamera menggunakan kernel Linux, yang merupakan sebahagian daripada SDK cip; biasanya ini bukan kernel terbaharu daripada cawangan 3.x, jadi kami sering perlu berurusan dengan fakta bahawa pemacu untuk peralatan tambahan tidak serasi dengan kernel yang digunakan , dan kita perlu menyandarkannya ke kamera kernel.

Isu lain ialah saiz kernel. Apabila saiz FLASH hanya 8MB, maka setiap bait dikira dan tugas kami adalah untuk melumpuhkan semua fungsi kernel yang tidak digunakan dengan teliti untuk mengurangkan saiz kepada minimum.

Rootfs ialah sistem fail asas. Ia termasuk busybox, pemacu modul wifi, satu set perpustakaan sistem standard, seperti libld и libc, serta perisian kami, yang bertanggungjawab untuk logik kawalan LED, pengurusan sambungan rangkaian dan kemas kini perisian tegar.

Sistem fail akar disambungkan ke kernel sebagai initramfs dan sebagai hasil daripada binaan kami mendapat satu fail uImage, yang mengandungi kedua-dua kernel dan rootfs.

Aplikasi video

Bahagian perisian tegar yang paling kompleks dan intensif sumber ialah aplikasi, yang menyediakan tangkapan audio video, pengekodan video, mengkonfigurasi parameter gambar, melaksanakan analisis video, contohnya, pengesan gerakan atau bunyi, mengawal PTZ dan bertanggungjawab untuk menukar hari dan mod malam.

Ciri yang penting, saya juga akan mengatakan kunci, ialah cara aplikasi video berinteraksi dengan pemalam awan.

Dalam penyelesaian tradisional 'firmware vendor + pemalam awan', yang tidak boleh berfungsi pada perkakasan murah, video di dalam kamera dihantar melalui protokol RTSP - dan ini adalah overhed yang besar: menyalin dan menghantar data melalui soket, syscalls yang tidak perlu.

Di sini kami menggunakan mekanisme memori yang dikongsi - video tidak disalin atau dihantar melalui soket antara komponen perisian kamera, dengan itu secara optimum dan berhati-hati menggunakan keupayaan perkakasan sederhana kamera.

Kemas kini subsistem

Satu perkara yang membanggakan ialah subsistem toleran kesalahan untuk kemas kini perisian tegar dalam talian.

Biar saya jelaskan masalahnya. Mengemas kini perisian tegar secara teknikalnya bukan operasi atom, dan jika kegagalan kuasa berlaku di tengah-tengah kemas kini, maka memori denyar akan mengandungi sebahagian daripada perisian tegar baharu yang "kurang ditulis". Jika anda tidak mengambil langkah khas, kamera kemudiannya akan menjadi "bata" yang perlu dibawa ke pusat servis.

Kami juga telah menangani masalah ini. Walaupun kamera dimatikan semasa kemas kini, ia akan secara automatik dan tanpa campur tangan pengguna memuat turun perisian tegar dari awan dan memulihkan operasi.

Mari lihat teknik dengan lebih terperinci:

Titik yang paling terdedah ialah menulis ganti partition dengan kernel Linux dan sistem fail akar. Jika salah satu daripada komponen ini rosak, kamera tidak akan boot sama sekali di luar pemuat but uboot, yang tidak boleh memuat turun perisian tegar dari awan.

Ini bermakna kita perlu memastikan bahawa kamera mempunyai kernel dan rootf yang berfungsi pada bila-bila masa semasa proses kemas kini. Nampaknya penyelesaian paling mudah adalah dengan sentiasa menyimpan dua salinan kernel dengan rootfs pada memori flash dan, jika kernel utama rosak, muatkannya dari salinan sandaran.

Penyelesaian yang baik - walau bagaimanapun, kernel dengan rootfs mengambil masa kira-kira 3.5MB dan untuk sandaran kekal anda perlu memperuntukkan 3.5MB. Kamera termurah hanya tidak mempunyai banyak ruang kosong untuk kernel sandaran.

Oleh itu, untuk membuat sandaran kernel semasa kemas kini perisian tegar, kami menggunakan partition aplikasi.
Dan untuk memilih partition yang dikehendaki dengan kernel, dua arahan digunakan bootm dalam uboot - pada mulanya kami cuba memuatkan kernel utama dan jika ia rosak, maka sandaran.

Ini memastikan bahawa pada bila-bila masa tertentu kamera akan mempunyai kernel yang betul dengan rootfs, dan ia akan dapat boot dan memulihkan perisian tegar.

Sistem CI/CD untuk membina dan menggunakan perisian tegar

Untuk membina perisian tegar, kami menggunakan gitlab CI, yang secara automatik membina perisian tegar untuk semua model kamera yang disokong, dan selepas membina perisian tegar, ia digunakan secara automatik ke perkhidmatan kemas kini perisian kamera.

Daripada perkhidmatan, kemas kini perisian tegar dihantar ke kamera ujian QA kami, dan setelah selesai semua peringkat ujian, ke kamera pengguna.

Keselamatan maklumat

Bukan rahsia lagi bahawa pada masa kini keselamatan maklumat adalah aspek terpenting bagi mana-mana peranti IoT, termasuk kamera. Botnet seperti Mirai sedang menjelajah Internet, menjangkiti berjuta-juta kamera dengan perisian tegar standard daripada vendor. Dengan segala hormatnya kepada vendor kamera, saya tidak dapat mengelak daripada mengambil perhatian bahawa perisian tegar standard mengandungi banyak fungsi yang tidak diperlukan untuk bekerja dengan awan, tetapi mengandungi banyak kelemahan yang dimanfaatkan oleh botnet.

Oleh itu, semua fungsi yang tidak digunakan dalam perisian tegar kami dilumpuhkan, semua port tcp/udp ditutup, dan apabila mengemas kini perisian tegar, tandatangan digital perisian diperiksa.

Dan selain itu, perisian tegar menjalani ujian tetap di makmal keselamatan maklumat.

Kesimpulan

Kini perisian tegar kami digunakan secara aktif dalam projek pengawasan video. Mungkin yang terbesar daripada mereka adalah penyiaran pengundian pada hari pemilihan Presiden Persekutuan Rusia.
Projek itu melibatkan lebih daripada 70 ribu kamera dengan perisian tegar kami, yang dipasang di pusat mengundi di negara kita.

Setelah menyelesaikan beberapa kompleks, dan di beberapa tempat, walaupun pada masa itu masalah yang hampir mustahil, kami, tentu saja, menerima kepuasan yang besar sebagai jurutera, tetapi selain itu, kami juga menjimatkan berjuta-juta dolar untuk pembelian kamera. Dan dalam kes ini, penjimatan bukan sahaja perkataan dan pengiraan teori, tetapi hasil tender yang telah selesai untuk pembelian peralatan. Sehubungan itu, jika kita bercakap tentang pengawasan video awan: terdapat dua pendekatan - bergantung secara strategik pada kepakaran dan pembangunan peringkat rendah, menghasilkan penjimatan besar pada peralatan, atau menggunakan peralatan mahal, yang, jika anda melihat secara khusus pada ciri pengguna, secara praktikalnya tidak berbeza dengan yang murah serupa.

Mengapa penting secara strategik untuk memutuskan pilihan pendekatan integrasi seawal mungkin? Semasa membangunkan pemalam, pembangun bergantung pada teknologi tertentu (perpustakaan, protokol, piawaian). Dan jika satu set teknologi dipilih hanya untuk peralatan mahal, maka pada masa akan datang percubaan untuk beralih kepada kamera murah kemungkinan besar, sekurang-kurangnya, mengambil masa yang sangat lama atau bahkan gagal dan kembali ke peralatan mahal akan berlaku.

Sumber: www.habr.com