Halo semuanya!

Mungkin bukan rahasia bagi siapa pun bahwa layanan pengawasan video berbasis cloud baru-baru ini semakin populer. Dan dapat dimengerti mengapa hal ini terjadi, video adalah konten “berat”, yang membutuhkan infrastruktur dan penyimpanan disk dalam jumlah besar untuk disimpan. Menggunakan sistem pengawasan video lokal membutuhkan sarana untuk beroperasi dan mendukung, baik dalam kasus organisasi yang menggunakan ratusan kamera pengintai, dan dalam kasus pengguna individu dengan beberapa kamera.

Sistem pengawasan video berbasis cloud menyelesaikan masalah ini dengan menyediakan pelanggan dengan penyimpanan video dan infrastruktur pemrosesan yang ada. Cukuplah bagi klien pengawasan berbasis cloud untuk cukup menghubungkan kamera ke Internet dan mengikat akunnya di cloud.

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

Untuk ini, perlu agar modul perangkat lunak yang bekerja dengan cloud dipasang 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, tetapi tidak ada sumber daya yang diperlukan untuk plug-in cloud. Pengembang dari ivideon menyediakan artikel untuk masalah ini, yang mengatakan mengapa mereka tidak dapat menginstal plug-in pada kamera murah. Akibatnya, harga minimum kamera adalah 5.000 rubel ($ 80 dolar) dan jutaan uang yang dihabiskan untuk peralatan.

Kami berhasil memecahkan masalah ini. Jika Anda tertarik pada caranya - Selamat datang di bawah kucing

Sedikit sejarah

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

Di bagian perangkat lunak kamera, pada tahap pertama kami menggunakan cara "standar" untuk tugas-tugas seperti itu: kami mengembangkan plug-in kami sendiri, yang dipasang di firmware kamera vendor dan bekerja dengan cloud kami. Namun, perlu dicatat bahwa selama desain kami menggunakan solusi yang paling ringan dan efisien (misalnya, implementasi C protobuf, libev, mbedtl, dan perpustakaan yang benar-benar nyaman tetapi terbengkalai seperti boost).

Sekarang di pasar kamera IP tidak ada solusi integrasi universal: masing-masing vendor memiliki cara sendiri untuk menginstal plugin, set API sendiri untuk firmware untuk bekerja, dan mekanisme pembaruan yang unik.

Ini berarti bahwa untuk setiap vendor kamera perlu secara individual mengembangkan lapisan volume perangkat lunak integrasi. Dan pada saat dimulainya pengembangan, disarankan untuk bekerja hanya dengan vendor pertama untuk memfokuskan upaya tim pada pengembangan logika bekerja dengan cloud.

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

Pada kamera Hikvision, kami meluncurkan proyek pilot pertama kami, pengawasan video cloud, Video Comfort.

Hampir segera setelah peluncuran, pengguna kami mulai mengajukan pertanyaan tentang kemungkinan menghubungkan kamera pihak ketiga yang lebih murah ke layanan.

Saya membuang opsi dengan penerapan lapisan integrasi untuk masing-masing vendor segera - sebagai scalable buruk dan menyajikan persyaratan teknis yang serius untuk perangkat keras kamera. Biaya kamera, memenuhi persyaratan seperti di pintu masuk: ~ $ 60-70

Oleh karena itu, saya memutuskan untuk menggali lebih dalam - benar-benar membuat firmware saya untuk kamera dari vendor mana pun. Pendekatan ini secara signifikan mengurangi persyaratan perangkat keras kamera - as lapisan cloud adalah urutan besarnya lebih efisien terintegrasi dengan aplikasi video, dan tidak ada lemak yang tidak perlu dalam firmware.

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

Pada saat itu, kami tidak punya apa-apa sama sekali. Tidak ada sama sekali.

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

Jawaban untuk semua pertanyaan harus diperoleh dengan rekayasa balik - coba-coba. Tapi kami berhasil.

Model kamera pertama tempat kami mengisi gundukan itu adalah Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, kamera D-Link, dan beberapa kamera Cina super murah yang tidak disebutkan namanya.

Teknik

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

Kami mulai dengan mereka.

Kami saat ini mendukung chipset Hisilicon 3516/3518, serta Ambarella S2L / S2LM. Jumlah model kamera adalah puluhan.

Komposisi Firmware

uboot

uboot adalah bootloader, setelah menyalakan power, boot pertama, 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 

Dari fitur-fiturnya, bootm dipanggil bootm , lebih banyak tentang itu nanti, ketika kita sampai ke subsistem pembaruan.

Perhatikan garis mem=38M . Ya, ya, ini bukan salah ketik - hanya 38 megabita RAM yang tersedia untuk kernel Linux dan semua-semua-semua aplikasi.

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

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

Kernel linux dan rootfs

Kamera menggunakan kernel Linux, yang merupakan bagian dari chip SDK, biasanya ini bukan kernel terbaru dari cabang 3.x, jadi kita sering harus menemukan bahwa driver perangkat keras tambahan tidak kompatibel dengan kernel yang digunakan, dan kita harus backport mereka ke kernel kamera.

Masalah lain adalah ukuran kernel. Ketika ukuran FLASH hanya 8MB, maka setiap byte ke dalam akun dan tugas kami adalah dengan hati-hati menonaktifkan semua fungsi kernel yang tidak digunakan untuk memperkecil ukuran menjadi minimum.

Rootfs adalah sistem file dasar. Ini termasuk busybox , driver modul wifi, satu set pustaka sistem standar, seperti libld dan libc , serta perangkat lunak pengembangan kami, yang bertanggung jawab atas logika manajemen LED, mengelola koneksi jaringan dan memperbarui firmware.

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

Aplikasi video

Bagian yang paling kompleks dan memakan sumber daya dari firmware adalah sebuah aplikasi yang menyediakan penangkapan video-audio, pengkodean video, menyesuaikan parameter gambar, mengimplementasikan analitik video, misalnya, detektor gerakan atau suara, mengendalikan PTZ dan bertanggung jawab untuk mengganti mode siang dan malam.

Yang penting, saya bahkan akan mengatakan fitur kunci - bagaimana aplikasi video berinteraksi dengan plugin cloud.

Dalam solusi tradisional 'vendor firmware + cloud plug-in', yang tidak dapat bekerja pada perangkat keras yang murah, video di dalam kamera ditransmisikan menggunakan protokol RTSP - dan ini merupakan overhead besar: menyalin dan mentransfer data melalui soket, syscalls yang berlebihan.

Kami menggunakan mekanisme memori bersama di tempat ini - video tidak disalin atau dikirim melalui soket di antara komponen perangkat lunak kamera, dengan demikian secara optimal dan hati-hati menggunakan kemampuan perangkat keras sederhana dari kamera.

Perbarui subsistem

Objek kebanggaan khusus adalah subsistem yang toleran terhadap pembaruan firmware online.

Saya akan menjelaskan masalahnya. Pembaruan firmware secara teknis bukan operasi atom, dan jika terjadi kegagalan daya di tengah pembaruan, maka akan ada bagian dari firmware baru yang "tidak direkam" pada memori flash. Jika Anda tidak mengambil tindakan khusus, maka kamera kemudian akan menjadi "batu bata", yang harus dibawa ke pusat layanan.

Kami telah mengatasi masalah ini. Bahkan jika kamera dimatikan pada saat memperbarui, ia akan secara otomatis dan tanpa campur tangan pengguna mengunduh firmware dari cloud dan memulihkan operasi.

Mari kita menganalisis teknik ini lebih terinci:

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

Jadi, kita perlu memastikan bahwa kamera memiliki kernel dan rootf yang berfungsi setiap saat selama proses pembaruan. Tampaknya solusi paling sederhana adalah menyimpan secara permanen pada memori flash dua salinan kernel dengan rootfs dan jika terjadi kerusakan pada kernel utama, muatkan dari cadangan.

Solusi yang bagus - namun, kernel dengan rootfs membutuhkan sekitar 3,5MB dan untuk cadangan permanen Anda perlu mengalokasikan 3,5MB. Pada kamera termurah, tidak ada begitu banyak ruang kosong untuk kernel cadangan.

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

Ini memastikan bahwa setiap saat kamera akan memiliki kernel yang benar dengan rootfs, dan itu akan dapat mem-boot dan mengembalikan firmware.

Sistem CI / CD untuk merakit dan menggunakan firmware

Untuk membuat firmware, kami menggunakan gitlab CI, di mana firmware untuk semua model kamera yang didukung dikumpulkan secara otomatis, setelah firmware dibuat, mereka secara otomatis digunakan untuk layanan pembaruan perangkat lunak kamera.

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

Keamanan informasi

Bukan rahasia lagi bahwa di zaman kita, keamanan informasi adalah aspek terpenting dari semua perangkat IoT, termasuk kamera. Botnet seperti Mirai berjalan di Internet, memengaruhi jutaan kamera dengan firmware standar dari vendor. Dengan segala hormat kepada vendor kamera, saya tidak dapat tidak mencatat bahwa firmware standar memiliki banyak fungsi yang tidak diminati untuk bekerja dengan cloud, tetapi berisi banyak kerentanan yang digunakan 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 dari perangkat lunak diperiksa.

Dan selain itu, firmware secara teratur diuji di laboratorium keamanan informasi.

Kesimpulan

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

Setelah menyelesaikan sejumlah tugas rumit, dan kadang-kadang bahkan secara praktis mustahil pada waktu itu, kami, tentu saja, menerima kepuasan besar sebagai insinyur, tetapi selain itu, kami menghemat jutaan dolar dalam membeli kamera. Dan dalam hal ini, penghematan tidak hanya kata-kata dan perhitungan teoritis, tetapi hasil tender yang sudah diadakan untuk pembelian peralatan. Dengan demikian, jika kita berbicara tentang pengawasan video cloud: ada dua pendekatan - secara strategis bergantung pada keahlian dan pengembangan tingkat rendah, mendapatkan penghematan besar pada peralatan di output, atau menggunakan peralatan mahal, yang, jika Anda melihat karakteristik konsumen, praktis tidak berbeda dari yang murah sama.

Mengapa penting secara strategis untuk memutuskan pendekatan metode integrasi sedini mungkin? Saat mengembangkan sebuah plugin, pengembang diletakkan pada teknologi tertentu (perpustakaan, protokol, standar). Dan jika satu set teknologi dipilih hanya untuk peralatan mahal, maka di masa depan upaya untuk beralih ke kamera murah dengan probabilitas tinggi setidaknya akan memakan waktu sangat lama atau bahkan gagal dan pengembalian ke peralatan mahal akan terjadi.