Hello!

Mungkin bukan rahasia lagi bahwa layanan pengawasan video cloud semakin populer akhir-akhir ini. Dan jelas mengapa hal ini terjadi, video adalah konten “berat”, yang penyimpanannya memerlukan infrastruktur dan penyimpanan disk dalam jumlah besar. Penggunaan sistem pengawasan video lokal memerlukan dana untuk pengoperasian dan dukungan, baik untuk organisasi yang menggunakan ratusan kamera pengawasan maupun untuk pengguna individu yang memiliki beberapa kamera.

Sistem pengawasan video cloud memecahkan masalah ini dengan menyediakan infrastruktur penyimpanan dan pemrosesan video yang ada kepada pelanggan. Klien pengawasan video cloud hanya perlu menghubungkan kamera ke Internet dan menautkannya ke akun cloud miliknya.

Ada beberapa cara teknologi untuk menghubungkan kamera ke cloud. Tidak diragukan lagi, metode yang paling nyaman dan termurah adalah kamera terhubung langsung dan bekerja dengan cloud, tanpa partisipasi peralatan tambahan seperti server atau perekam.

Untuk melakukan ini, modul perangkat lunak yang bekerja dengan cloud perlu diinstal pada kamera. Namun, jika kita berbicara tentang kamera murah, maka mereka memiliki sumber daya perangkat keras yang sangat terbatas, yang hampir 100% ditempati oleh firmware asli dari vendor kamera, dan tidak ada sumber daya yang diperlukan untuk plugin cloud. Pengembang dari ivideon mengabdikan masalah ini sebuah artikel, yang menjelaskan mengapa mereka tidak dapat memasang plugin pada kamera murah. Akibatnya, harga minimum kamera adalah 5000 rubel ($80 dolar) dan jutaan uang dihabiskan untuk peralatan.

Kami telah berhasil memecahkan masalah ini. Jika Anda tertarik dengan caranya - selamat datang di potongannya

Sedikit sejarah

Pada tahun 2016, kami mulai mengembangkan platform pengawasan video cloud untuk Rostelecom.

Dalam hal perangkat lunak kamera, pada tahap pertama kami mengikuti jalur “standar” untuk tugas-tugas tersebut: kami mengembangkan plugin kami sendiri, yang dipasang di firmware standar kamera vendor dan berfungsi dengan cloud kami. Namun, perlu dicatat bahwa selama desain kami menggunakan solusi yang paling ringan dan efisien (misalnya, implementasi C biasa dari protobuf, libev, mbedtls dan sepenuhnya meninggalkan perpustakaan yang nyaman namun berat seperti boost)

Saat ini, tidak ada solusi integrasi universal di pasar kamera IP: setiap vendor memiliki caranya sendiri dalam menginstal plugin, rangkaian API sendiri untuk mengoperasikan firmware, dan mekanisme pembaruan yang unik.

Artinya, setiap vendor kamera perlu mengembangkan perangkat lunak integrasi yang komprehensif secara individual. Dan pada saat memulai pengembangan, disarankan untuk bekerja hanya dengan 1 vendor untuk memusatkan upaya tim dalam mengembangkan logika untuk bekerja dengan cloud.

Vendor pertama yang dipilih adalah Hikvision, salah satu pemimpin dunia di pasar kamera, yang menyediakan API yang terdokumentasi dengan baik dan dukungan teknis teknis yang kompeten.

Kami meluncurkan proyek percontohan pertama kami, pengawasan video cloud Video Comfort, menggunakan kamera Hikvision.

Hampir segera setelah peluncuran, pengguna kami mulai mengajukan pertanyaan tentang kemungkinan menghubungkan kamera yang lebih murah dari produsen lain ke layanan ini.

Saya segera menolak opsi untuk menerapkan lapisan integrasi untuk setiap vendor - karena skalanya buruk dan memberlakukan persyaratan teknis yang serius pada perangkat keras kamera. Biaya kamera yang memenuhi persyaratan masukan ini: ~60-70$

Oleh karena itu, saya memutuskan untuk menggali lebih dalam - membuat firmware sendiri untuk kamera dari vendor mana pun. Pendekatan ini secara signifikan mengurangi persyaratan sumber daya perangkat keras kamera - karena Lapisan untuk bekerja dengan cloud terintegrasi jauh lebih efektif dengan aplikasi video, dan tidak ada lemak yang tidak terpakai di firmware.

Dan yang penting adalah saat bekerja dengan kamera pada level rendah, dimungkinkan untuk menggunakan perangkat keras AES, yang mengenkripsi data tanpa menimbulkan beban tambahan pada CPU berdaya rendah.

Saat itu kami tidak punya apa-apa. Tidak ada sama sekali.

Hampir semua vendor belum siap bekerja sama dengan kami pada tingkat yang rendah. Tidak ada informasi tentang sirkuit dan komponen, tidak ada SDK resmi untuk chipset dan dokumentasi sensor.
Juga tidak ada dukungan teknis.

Semua pertanyaan harus dijawab melalui rekayasa balik—trial and error. Tapi kami berhasil.

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

Teknik

Kamera berdasarkan chipset Hisilicon 3518E. Karakteristik perangkat keras kamera adalah sebagai berikut:

Semut Xiaomi Yi
noname

SoC
Hisilikon 3518E
Hisilikon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

WiFi
mt7601/bcm43143
-

Sensor
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Mikropon
+
+

Pembicara
+
+

dipimpin IRL
+
+

IRcut
+
+

Kami mulai dengan mereka.

Saat ini kami mendukung chipset Hisilicon 3516/3518, serta Ambarella S2L/S2LM. Ada lusinan model kamera.

Komposisi firmware

kapal selam

uboot adalah boot loader, ia melakukan booting terlebih dahulu setelah dihidupkan, menginisialisasi perangkat keras dan memuat kernel linux.

Skrip pemuatan kamera cukup sepele:

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 fiturnya adalah dipanggil dua kali bootm, lebih lanjut tentang ini nanti, ketika kita masuk ke subsistem pembaruan.

Perhatikan garisnya mem=38M. Ya, ya, ini bukan kesalahan ketik - kernel Linux dan semuanya, semua aplikasi hanya memiliki akses ke RAM 38 megabita.

Juga di sebelah uboot ada blok khusus yang disebut reg_info, yang berisi skrip tingkat rendah untuk inisialisasi DDR dan sejumlah register sistem SoC. Isi reg_info tergantung pada model kamera, dan jika tidak benar, kamera bahkan tidak akan dapat memuat uboot, tetapi akan terhenti pada tahap awal pemuatan.

Pada awalnya, ketika kami bekerja tanpa dukungan vendor, kami hanya menyalin blok ini dari firmware kamera asli.

Kernel Linux dan rootf

Kamera menggunakan kernel Linux, yang merupakan bagian dari SDK chip; biasanya ini bukan kernel terbaru dari cabang 3.x, jadi kita sering harus menghadapi kenyataan bahwa driver untuk peralatan tambahan tidak kompatibel dengan kernel yang digunakan , dan kita harus mem-back-portnya ke kamera kernel.

Masalah lainnya adalah ukuran kernel. Ketika ukuran FLASH hanya 8MB, maka setiap byte dihitung dan tugas kita adalah menonaktifkan semua fungsi kernel yang tidak digunakan dengan hati-hati untuk mengurangi ukurannya seminimal mungkin.

Rootfs adalah sistem file dasar. Itu termasuk busybox, driver modul wifi, sekumpulan perpustakaan sistem standar, seperti libld и libc, serta perangkat lunak kami, yang bertanggung jawab atas logika kontrol LED, manajemen koneksi jaringan, dan pembaruan firmware.

Sistem file root terhubung ke kernel sebagai initramfs dan sebagai hasil dari build kita mendapatkan satu file uImage, yang berisi kernel dan rootfs.

Aplikasi video

Bagian firmware yang paling kompleks dan intensif sumber daya adalah aplikasi, yang menyediakan pengambilan video-audio, pengkodean video, mengonfigurasi parameter gambar, mengimplementasikan analisis video, misalnya, detektor gerakan atau suara, mengontrol PTZ dan bertanggung jawab untuk peralihan hari dan mode malam.

Fitur yang penting, bahkan menurut saya kuncinya, adalah bagaimana aplikasi video berinteraksi dengan plugin cloud.

Dalam solusi tradisional 'firmware vendor + plugin cloud', yang tidak dapat bekerja pada perangkat keras murah, video di dalam kamera ditransmisikan melalui protokol RTSP - dan ini merupakan overhead yang sangat besar: menyalin dan mengirimkan data melalui soket, syscall yang tidak perlu.

Di sini kami menggunakan mekanisme memori bersama - video tidak disalin atau dikirim melalui soket antara komponen perangkat lunak kamera, sehingga secara optimal dan hati-hati menggunakan kemampuan perangkat keras kamera yang sederhana.

Perbarui subsistem

Yang menjadi kebanggaan tersendiri adalah subsistem yang toleran terhadap kesalahan untuk pembaruan firmware online.

Izinkan saya menjelaskan masalahnya. Memperbarui firmware secara teknis bukanlah operasi atomik, dan jika terjadi kegagalan daya di tengah pembaruan, maka memori flash akan berisi bagian dari firmware baru yang “ditulis”. Jika tidak mengambil tindakan khusus, kamera kemudian akan menjadi “batu bata” yang perlu dibawa ke pusat layanan.

Kami juga telah mengatasi masalah ini. Meskipun kamera dimatikan selama pembaruan, kamera akan secara otomatis dan tanpa campur tangan pengguna mengunduh firmware dari cloud dan memulihkan pengoperasian.

Mari kita lihat tekniknya lebih detail:

Titik paling rentan adalah menimpa partisi dengan kernel Linux dan sistem file root. Jika salah satu komponen ini rusak, kamera tidak akan bisa boot sama sekali di luar bootloader uboot, yang tidak dapat mendownload firmware dari cloud.

Ini berarti kita perlu memastikan bahwa kamera memiliki kernel dan rootf yang berfungsi kapan saja selama proses pembaruan. Tampaknya solusi paling sederhana adalah dengan terus-menerus menyimpan dua salinan kernel dengan rootfs pada memori flash dan, jika kernel utama rusak, memuatnya dari salinan cadangan.

Solusi yang bagus - namun, kernel dengan rootfs memakan sekitar 3.5MB dan untuk cadangan permanen Anda perlu mengalokasikan 3.5MB. Kamera termurah tidak memiliki banyak ruang kosong untuk kernel cadangan.

Oleh karena itu, untuk membuat cadangan kernel selama pembaruan firmware, kami menggunakan partisi aplikasi.
Dan untuk memilih partisi yang diinginkan dengan kernel, dua perintah digunakan bootm di uboot - pertama-tama kami mencoba memuat kernel utama dan jika rusak, maka cadangan.

Hal ini memastikan bahwa pada waktu tertentu kamera akan memiliki kernel yang benar dengan rootfs, dan kamera akan dapat melakukan booting dan memulihkan firmware.

Sistem CI/CD untuk membuat dan menerapkan firmware

Untuk membuat firmware, kami menggunakan gitlab CI, yang secara otomatis membuat firmware untuk semua model kamera yang didukung, dan setelah membuat firmware, firmware tersebut secara otomatis diterapkan ke layanan pembaruan perangkat lunak kamera.

Dari layanan ini, pembaruan firmware dikirimkan ke kamera uji QA kami, dan setelah semua tahap pengujian selesai, ke kamera pengguna.

Keamanan informasi

Bukan rahasia lagi bahwa saat ini keamanan informasi adalah aspek terpenting dari perangkat IoT apa pun, termasuk kamera. Botnet seperti Mirai berkeliaran di Internet, menginfeksi jutaan kamera dengan firmware standar dari vendor. Dengan segala hormat kepada vendor kamera, saya perhatikan bahwa firmware standar mengandung banyak fungsi yang tidak diperlukan untuk bekerja dengan cloud, tetapi mengandung banyak kerentanan yang dimanfaatkan oleh botnet.

Oleh karena itu, semua fungsi yang tidak digunakan dalam firmware kami dinonaktifkan, semua port tcp/udp ditutup, dan saat memperbarui firmware, tanda tangan digital perangkat lunak diperiksa.

Selain itu, firmware menjalani pengujian rutin di laboratorium keamanan informasi.

Kesimpulan

Sekarang firmware kami secara aktif digunakan dalam proyek pengawasan video. Mungkin yang terbesar adalah siaran pemungutan suara pada hari pemilihan Presiden Federasi Rusia.
Proyek ini melibatkan lebih dari 70 ribu kamera dengan firmware kami, yang dipasang di TPS di negara kami.

Setelah memecahkan sejumlah masalah yang rumit, dan di beberapa tempat, bahkan pada saat itu hampir mustahil, kami, tentu saja, menerima kepuasan besar sebagai insinyur, namun selain itu, kami juga menghemat jutaan dolar untuk pembelian kamera. Dan dalam hal ini penghematan bukan sekedar kata-kata dan perhitungan teoritis, tetapi hasil tender pembelian peralatan yang sudah selesai. Oleh karena itu, jika kita berbicara tentang pengawasan video cloud: ada dua pendekatan - secara strategis mengandalkan keahlian dan pengembangan tingkat rendah, sehingga menghasilkan penghematan besar pada peralatan, atau menggunakan peralatan mahal, yang, jika Anda melihat secara khusus pada karakteristik konsumen, praktis tidak ada. Beda dengan yang sejenis yang murah.

Mengapa penting secara strategis untuk memutuskan pilihan pendekatan integrasi sedini mungkin? Saat mengembangkan plugin, pengembang mengandalkan teknologi tertentu (perpustakaan, protokol, standar). Dan jika serangkaian teknologi dipilih hanya untuk peralatan mahal, maka di masa depan upaya untuk beralih ke kamera murah kemungkinan besar, setidaknya, akan memakan waktu yang sangat lama atau bahkan gagal dan akan terjadi kembali ke peralatan mahal.

Sumber: www.habr.com