Hello!

อาจเป็นความลับที่บริการกล้องวงจรปิดบนคลาวด์ได้รับความนิยมเมื่อเร็วๆ นี้ และชัดเจนว่าทำไมสิ่งนี้ถึงเกิดขึ้น วิดีโอจึงมีเนื้อหาที่ "หนัก" ซึ่งเป็นพื้นที่จัดเก็บข้อมูลที่ต้องใช้โครงสร้างพื้นฐานและพื้นที่เก็บข้อมูลดิสก์จำนวนมาก การใช้ระบบกล้องวงจรปิดในองค์กรต้องใช้เงินทุนในการดำเนินการและสนับสนุน ทั้งสำหรับองค์กรที่ใช้กล้องวงจรปิดหลายร้อยตัวและสำหรับผู้ใช้แต่ละรายที่มีกล้องหลายตัว

ระบบ Surveillance วิดีโอบนคลาวด์ช่วยแก้ปัญหานี้ด้วยการมอบโครงสร้างพื้นฐานการประมวลผลและการจัดเก็บวิดีโอที่มีอยู่แก่ลูกค้า ลูกค้ากล้องวงจรปิดบนคลาวด์เพียงแค่ต้องเชื่อมต่อกล้องกับอินเทอร์เน็ตและเชื่อมโยงกับบัญชีคลาวด์ของเขา

มีวิธีทางเทคโนโลยีหลายวิธีในการเชื่อมต่อกล้องกับคลาวด์ วิธีที่สะดวกและถูกที่สุดอย่างไม่ต้องสงสัยคือกล้องเชื่อมต่อโดยตรงและทำงานกับระบบคลาวด์ โดยไม่ต้องใช้อุปกรณ์เพิ่มเติม เช่น เซิร์ฟเวอร์หรือเครื่องบันทึก

ในการดำเนินการนี้ จำเป็นต้องติดตั้งโมดูลซอฟต์แวร์ที่ทำงานกับระบบคลาวด์บนกล้อง อย่างไรก็ตาม หากเราพูดถึงกล้องราคาถูก กล้องเหล่านั้นก็มีทรัพยากรฮาร์ดแวร์ที่จำกัดมาก ซึ่งเกือบ 100% จะถูกครอบครองโดยเฟิร์มแวร์ดั้งเดิมของผู้จำหน่ายกล้อง และไม่มีทรัพยากรที่จำเป็นสำหรับปลั๊กอินคลาวด์ นักพัฒนาจาก ivideon อุทิศปัญหานี้ บทความซึ่งอธิบายว่าทำไมพวกเขาจึงไม่สามารถติดตั้งปลั๊กอินในกล้องราคาถูกได้ เป็นผลให้ราคาขั้นต่ำของกล้องคือ 5000 รูเบิล (80 ดอลลาร์) และเงินหลายล้านที่ใช้ไปกับอุปกรณ์

เราแก้ไขปัญหานี้สำเร็จแล้ว หากคุณสนใจวิธีการ - ยินดีต้อนรับสู่การตัด

บิตของประวัติศาสตร์

ในปี 2016 เราเริ่มพัฒนาแพลตฟอร์มกล้องวงจรปิดบนคลาวด์สำหรับ Rostelecom

ในแง่ของซอฟต์แวร์กล้อง ในขั้นแรกเราได้ปฏิบัติตามเส้นทาง "มาตรฐาน" สำหรับงานดังกล่าว: เราพัฒนาปลั๊กอินของเราเอง ซึ่งติดตั้งในเฟิร์มแวร์มาตรฐานของกล้องของผู้จำหน่ายและทำงานร่วมกับระบบคลาวด์ของเรา อย่างไรก็ตาม เป็นที่น่าสังเกตว่าในระหว่างการออกแบบ เราใช้โซลูชันที่มีน้ำหนักเบาและมีประสิทธิภาพมากที่สุด (ตัวอย่างเช่น การใช้งาน C ธรรมดาของ protobuf, libev, mbedtls และละทิ้งไลบรารีที่สะดวก แต่หนักเช่นบูสต์โดยสิ้นเชิง)

ปัจจุบัน ไม่มีโซลูชันการบูรณาการแบบสากลในตลาดกล้อง IP: ผู้จำหน่ายแต่ละรายมีวิธีการติดตั้งปลั๊กอิน ชุด API ของตนเองสำหรับการใช้งานเฟิร์มแวร์ และกลไกการอัพเดตเฉพาะตัว

ซึ่งหมายความว่าสำหรับผู้จำหน่ายกล้องแต่ละรายจำเป็นต้องพัฒนาซอฟต์แวร์บูรณาการที่ครอบคลุมเป็นรายบุคคล และในช่วงเริ่มต้นการพัฒนาขอแนะนำให้ทำงานร่วมกับผู้จำหน่ายเพียง 1 รายเท่านั้น เพื่อมุ่งความสนใจไปที่ความพยายามของทีมในการพัฒนาตรรกะสำหรับการทำงานกับคลาวด์

ผู้จำหน่ายรายแรกที่ได้รับเลือกคือ Hikvision ซึ่งเป็นหนึ่งในผู้นำระดับโลกในตลาดกล้อง โดยให้บริการ API ที่มีเอกสารครบถ้วนและการสนับสนุนทางเทคนิคด้านวิศวกรรมที่เชี่ยวชาญ

เราเปิดตัวโครงการนำร่องโครงการแรกของเรา Video Comfort สำหรับกล้องวงจรปิดบนคลาวด์ โดยใช้กล้อง Hikvision

เกือบจะทันทีหลังจากเปิดตัว ผู้ใช้ของเราเริ่มถามคำถามเกี่ยวกับความเป็นไปได้ในการเชื่อมต่อกล้องราคาถูกจากผู้ผลิตรายอื่นเข้ากับบริการ

ฉันปฏิเสธตัวเลือกในการใช้เลเยอร์การผสานรวมสำหรับผู้จำหน่ายแต่ละรายเกือบจะในทันที เนื่องจากไม่สามารถปรับขนาดได้ไม่ดีและกำหนดข้อกำหนดทางเทคนิคที่ร้ายแรงกับฮาร์ดแวร์กล้อง ราคาของกล้องที่ตรงตามข้อกำหนดอินพุตเหล่านี้: ~60-70$

ดังนั้นฉันจึงตัดสินใจเจาะลึกลงไป - เพื่อสร้างเฟิร์มแวร์สำหรับกล้องของตัวเองจากผู้ขายทุกราย แนวทางนี้ช่วยลดความต้องการทรัพยากรฮาร์ดแวร์กล้องลงอย่างมาก - เนื่องจาก เลเยอร์สำหรับการทำงานกับคลาวด์นั้นรวมเข้ากับแอปพลิเคชันวิดีโอได้อย่างมีประสิทธิภาพมากขึ้นและไม่มีไขมันที่ไม่จำเป็นในเฟิร์มแวร์

และสิ่งสำคัญคือเมื่อทำงานกับกล้องในระดับต่ำ คุณสามารถใช้ฮาร์ดแวร์ AES ซึ่งจะเข้ารหัสข้อมูลโดยไม่สร้างภาระเพิ่มเติมบน CPU ที่ใช้พลังงานต่ำ

ในขณะนั้นเราไม่มีอะไรเลย ไม่มีอะไรทั้งนั้น.

ผู้ขายเกือบทั้งหมดไม่พร้อมที่จะร่วมงานกับเราในระดับที่ต่ำเช่นนี้ ไม่มีข้อมูลเกี่ยวกับการออกแบบวงจรและส่วนประกอบ ไม่มี SDK อย่างเป็นทางการของชิปเซ็ตและเอกสารประกอบเซ็นเซอร์
นอกจากนี้ยังไม่มีการสนับสนุนทางเทคนิค

คำถามทั้งหมดต้องได้รับคำตอบผ่านวิศวกรรมย้อนกลับ—การลองผิดลองถูก แต่เราจัดการได้

กล้องรุ่นแรกที่เราทดสอบคือ Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, กล้อง D-Link และกล้องจีนนิรนามราคาถูกสุด ๆ หลายตัว

เทคนิค

กล้องที่ใช้ชิปเซ็ต Hisilicon 3518E ลักษณะฮาร์ดแวร์ของกล้องมีดังนี้:

เสี่ยวหมี่ยี่มด
noname

SoC
ไฮซิลิคอน 3518E
ไฮซิลิคอน 3518E

แรม
64MB
64MB

FLASH
16MB
8MB

อินเตอร์เน็ตไร้สาย
mt7601/bcm43143
-

เซนเซอร์
ov9732 (720p)
ov9712 (720p)

อีเธอร์เน็ต
-
+

MicroSD
+
+

ไมโครโฟน
+
+

ลำโพง
+
+

IRled
+
+

ไออาร์คัท
+
+

เราเริ่มต้นกับพวกเขา

ปัจจุบันเรารองรับชิปเซ็ต Hisilicon 3516/3518 รวมถึง Ambarella S2L/S2LM มีกล้องหลายสิบรุ่น

องค์ประกอบของเฟิร์มแวร์

เรือดำน้ำ

uboot เป็นบูตโหลดเดอร์ โดยจะบู๊ตก่อนหลังจากเปิดเครื่อง เตรียมใช้งานฮาร์ดแวร์และโหลดเคอร์เนล linux

สคริปต์การโหลดกล้องค่อนข้างเล็กน้อย:

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 และแอปพลิเคชันทั้งหมดสามารถเข้าถึง RAM ได้เพียง 38 เมกะไบต์เท่านั้น

ถัดจาก uboot จะมีบล็อกพิเศษที่เรียกว่า reg_infoซึ่งมีสคริปต์ระดับต่ำสำหรับการเริ่มต้น DDR และการลงทะเบียนระบบจำนวนหนึ่งของ SoC เนื้อหา reg_info ขึ้นอยู่กับรุ่นของกล้อง และหากไม่ถูกต้อง กล้องจะไม่สามารถโหลด uboot ได้ แต่จะค้างในช่วงแรกของการโหลด

ในตอนแรก เมื่อเราทำงานโดยไม่มีการสนับสนุนจากผู้จำหน่าย เราก็เพียงคัดลอกบล็อกนี้จากเฟิร์มแวร์ของกล้องดั้งเดิม

เคอร์เนล Linux และ rootfs

กล้องใช้เคอร์เนล Linux ซึ่งเป็นส่วนหนึ่งของ SDK ของชิป โดยปกติแล้วสิ่งเหล่านี้จะไม่ใช่เคอร์เนลล่าสุดจากสาขา 3.x ดังนั้นเรามักจะต้องจัดการกับข้อเท็จจริงที่ว่าไดรเวอร์สำหรับอุปกรณ์เพิ่มเติมเข้ากันไม่ได้กับเคอร์เนลที่ใช้ และเราต้องแบ็คพอร์ตพวกมันไปที่กล้องเคอร์เนล

ปัญหาอีกประการหนึ่งคือขนาดของเคอร์เนล เมื่อขนาด FLASH มีเพียง 8MB ทุกไบต์จะถูกนับ และงานของเราคือการปิดการใช้งานฟังก์ชันเคอร์เนลที่ไม่ได้ใช้ทั้งหมดอย่างระมัดระวัง เพื่อลดขนาดให้เหลือน้อยที่สุด

Rootfs เป็นระบบไฟล์พื้นฐาน ประกอบด้วย busybox, ไดรเวอร์โมดูล wifi, ชุดไลบรารีระบบมาตรฐานเช่น libld и libcตลอดจนซอฟต์แวร์ของเราซึ่งรับผิดชอบตรรกะการควบคุม LED การจัดการการเชื่อมต่อเครือข่าย และการอัพเดตเฟิร์มแวร์

ระบบไฟล์รูทเชื่อมต่อกับเคอร์เนลในรูปแบบ initramfs และจากผลลัพธ์ของบิลด์เราจึงได้ไฟล์หนึ่งไฟล์ uImageซึ่งมีทั้งเคอร์เนลและ rootfs

แอปพลิเคชั่นวิดีโอ

ส่วนที่ซับซ้อนและใช้ทรัพยากรมากที่สุดของเฟิร์มแวร์คือแอปพลิเคชันที่ให้การจับภาพวิดีโอและเสียง การเข้ารหัสวิดีโอ กำหนดค่าพารามิเตอร์รูปภาพ ใช้การวิเคราะห์วิดีโอ เช่น เครื่องตรวจจับการเคลื่อนไหวหรือเสียง ควบคุม PTZ และรับผิดชอบในการสลับวันและ โหมดกลางคืน

สิ่งสำคัญที่ฉันบอกได้เลยว่าคุณลักษณะสำคัญคือวิธีที่แอปพลิเคชันวิดีโอโต้ตอบกับปลั๊กอินคลาวด์

ในโซลูชันแบบดั้งเดิม 'เฟิร์มแวร์ของผู้จำหน่าย + ปลั๊กอินคลาวด์' ซึ่งไม่สามารถทำงานกับฮาร์ดแวร์ราคาถูกได้ วิดีโอภายในกล้องจะถูกส่งผ่านโปรโตคอล RTSP - และนี่เป็นค่าใช้จ่ายมหาศาล: การคัดลอกและส่งข้อมูลผ่านซ็อกเก็ต, syscalls ที่ไม่จำเป็น

ในที่นี้ เราใช้กลไกหน่วยความจำที่ใช้ร่วมกัน - วิดีโอจะไม่ถูกคัดลอกหรือส่งผ่านซ็อกเก็ตระหว่างส่วนประกอบซอฟต์แวร์ของกล้อง ดังนั้นจึงใช้ความสามารถด้านฮาร์ดแวร์เล็กน้อยของกล้องอย่างเหมาะสมและรอบคอบ

อัพเดตระบบย่อย

ความภาคภูมิใจเป็นพิเศษคือระบบย่อยที่ทนทานต่อข้อผิดพลาดสำหรับการอัพเดตเฟิร์มแวร์ออนไลน์

ให้ฉันอธิบายปัญหา ในทางเทคนิคแล้วการอัปเดตเฟิร์มแวร์ไม่ใช่การดำเนินการแบบอะตอมมิก และหากไฟฟ้าขัดข้องเกิดขึ้นระหว่างการอัปเดต หน่วยความจำแฟลชจะมีส่วนหนึ่งของเฟิร์มแวร์ใหม่ที่ "ยังไม่ได้เขียน" หากคุณไม่ใช้มาตรการพิเศษ กล้องก็จะกลายเป็น "อิฐ" ที่ต้องนำไปส่งที่ศูนย์บริการ

เราได้จัดการกับปัญหานี้ด้วย แม้ว่ากล้องจะถูกปิดในระหว่างการอัพเดต กล้องก็จะดาวน์โหลดเฟิร์มแวร์จากคลาวด์โดยอัตโนมัติและไม่มีการรบกวนจากผู้ใช้และกู้คืนการดำเนินการ

มาดูเทคนิคโดยละเอียดเพิ่มเติม:

จุดที่เปราะบางที่สุดคือการเขียนทับพาร์ติชันด้วยเคอร์เนล Linux และระบบไฟล์รูท หากส่วนประกอบใดส่วนประกอบหนึ่งเสียหาย กล้องจะไม่สามารถบู๊ตได้เลยนอกเหนือจาก uboot bootloader ซึ่งไม่สามารถดาวน์โหลดเฟิร์มแวร์จากคลาวด์ได้

ซึ่งหมายความว่าเราจำเป็นต้องตรวจสอบให้แน่ใจว่ากล้องมีเคอร์เนลและ rootf ที่ใช้งานได้ตลอดเวลาระหว่างกระบวนการอัปเดต ดูเหมือนว่าวิธีแก้ปัญหาที่ง่ายที่สุดคือจัดเก็บสำเนาเคอร์เนลสองชุดที่มี rootfs ไว้ในหน่วยความจำแฟลชอย่างต่อเนื่อง และหากเคอร์เนลหลักเสียหาย ให้โหลดเคอร์เนลจากสำเนาสำรอง

วิธีแก้ปัญหาที่ดี - อย่างไรก็ตาม เคอร์เนลที่มี rootfs จะใช้เวลาประมาณ 3.5MB และสำหรับการสำรองข้อมูลถาวร คุณจะต้องจัดสรร 3.5MB กล้องที่ถูกที่สุดไม่มีพื้นที่ว่างสำหรับเคอร์เนลสำรองมากนัก

ดังนั้นในการสำรองข้อมูลเคอร์เนลระหว่างการอัพเดตเฟิร์มแวร์เราจะใช้พาร์ติชันแอปพลิเคชัน
และเพื่อเลือกพาร์ติชันที่ต้องการด้วยเคอร์เนลจะใช้สองคำสั่ง bootm ใน uboot - ในตอนแรกเราพยายามโหลดเคอร์เนลหลักและหากเสียหายก็จะเป็นอันสำรอง

เพื่อให้แน่ใจว่าในเวลาใดก็ตาม กล้องจะมีเคอร์เนลที่ถูกต้องพร้อม rootfs และจะสามารถบูตและกู้คืนเฟิร์มแวร์ได้

ระบบ CI/CD สำหรับการสร้างและปรับใช้เฟิร์มแวร์

ในการสร้างเฟิร์มแวร์ เราใช้ gitlab CI ซึ่งจะสร้างเฟิร์มแวร์สำหรับกล้องทุกรุ่นที่รองรับโดยอัตโนมัติ และหลังจากสร้างเฟิร์มแวร์แล้ว เฟิร์มแวร์จะนำไปใช้กับบริการอัพเดตซอฟต์แวร์ของกล้องโดยอัตโนมัติ

จากบริการนี้ การอัปเดตเฟิร์มแวร์จะถูกส่งไปยังกล้องทดสอบ QA ของเรา และเมื่อเสร็จสิ้นขั้นตอนการทดสอบทั้งหมดไปยังกล้องของผู้ใช้

ความปลอดภัยของข้อมูล

ไม่ใช่เรื่องเป็นความลับที่ทุกวันนี้ความปลอดภัยของข้อมูลเป็นสิ่งสำคัญที่สุดในอุปกรณ์ IoT ใดๆ รวมถึงกล้องด้วย บอตเน็ตอย่าง Mirai กำลังโรมมิ่งอินเทอร์เน็ต ทำให้กล้องหลายล้านตัวติดเฟิร์มแวร์มาตรฐานจากผู้ขาย ด้วยความเคารพต่อผู้จำหน่ายกล้อง ฉันไม่สามารถช่วยได้ แต่ทราบว่าเฟิร์มแวร์มาตรฐานมีฟังก์ชันมากมายที่ไม่จำเป็นสำหรับการทำงานกับระบบคลาวด์ แต่มีช่องโหว่มากมายที่บอตเน็ตใช้ประโยชน์

ดังนั้น ฟังก์ชันที่ไม่ได้ใช้ทั้งหมดในเฟิร์มแวร์ของเราจึงถูกปิดใช้งาน พอร์ต tcp/udp ทั้งหมดจะถูกปิด และเมื่ออัปเดตเฟิร์มแวร์ จะมีการตรวจสอบลายเซ็นดิจิทัลของซอฟต์แวร์

นอกจากนี้ เฟิร์มแวร์ยังผ่านการทดสอบเป็นประจำในห้องปฏิบัติการความปลอดภัยของข้อมูล

ข้อสรุป

ขณะนี้เฟิร์มแวร์ของเราถูกใช้งานในโครงการกล้องวงจรปิด บางทีสิ่งที่ใหญ่ที่สุดคือการออกอากาศการลงคะแนนเสียงในวันเลือกตั้งประธานาธิบดีแห่งสหพันธรัฐรัสเซีย
โครงการนี้เกี่ยวข้องกับกล้องมากกว่า 70 ตัวพร้อมเฟิร์มแวร์ของเรา ซึ่งติดตั้งที่หน่วยเลือกตั้งในประเทศของเรา

หลังจากแก้ไขปัญหาที่ซับซ้อนไปจำนวนหนึ่งแล้ว และในบางแห่ง แม้ในเวลานั้นแทบจะเป็นไปไม่ได้เลยก็ตาม แน่นอนว่าเราได้รับความพึงพอใจอย่างมากในฐานะวิศวกร แต่นอกเหนือจากนี้ เรายังประหยัดเงินได้หลายล้านดอลลาร์ในการซื้อกล้องอีกด้วย และในกรณีนี้การออมไม่ได้เป็นเพียงคำพูดและการคำนวณทางทฤษฎีเท่านั้น แต่ยังเป็นผลจากการประกวดราคาซื้ออุปกรณ์ที่เสร็จสมบูรณ์แล้ว ดังนั้น หากเราพูดถึงการเฝ้าระวังวิดีโอบนคลาวด์: มีสองวิธี - อาศัยกลยุทธ์และความเชี่ยวชาญระดับต่ำซึ่งส่งผลให้ประหยัดอุปกรณ์ได้มหาศาล หรือใช้อุปกรณ์ราคาแพง ซึ่งหากคุณดูเฉพาะคุณลักษณะของผู้บริโภคแล้ว ก็แทบไม่มีประโยชน์เลย แตกต่างจากของราคาถูกที่คล้ายกัน

เหตุใดจึงมีความสำคัญเชิงกลยุทธ์ในการตัดสินใจเลือกแนวทางบูรณาการโดยเร็วที่สุด เมื่อพัฒนาปลั๊กอิน นักพัฒนาต้องอาศัยเทคโนโลยีบางอย่าง (ไลบรารี โปรโตคอล มาตรฐาน) และหากเลือกชุดเทคโนโลยีสำหรับอุปกรณ์ราคาแพงเท่านั้น ในอนาคตความพยายามที่จะเปลี่ยนไปใช้กล้องราคาถูกน่าจะใช้เวลานานมากหรือล้มเหลวอย่างน้อยที่สุดและการกลับไปสู่อุปกรณ์ราคาแพงจะเกิดขึ้น

ที่มา: will.com