خوش آمدید!

احتمالاً بر کسی پوشیده نیست که خدمات نظارت تصویری ابری اخیراً محبوبیت پیدا کرده است. و واضح است که چرا این اتفاق می افتد، ویدیو محتوای «سنگین» است، ذخیره سازی آن به زیرساخت و حجم زیادی از فضای ذخیره سازی دیسک نیاز دارد. استفاده از یک سیستم نظارت تصویری در محل، هم برای سازمانی که از صدها دوربین نظارتی استفاده می‌کند و هم برای یک کاربر با چندین دوربین، برای کار و پشتیبانی به بودجه نیاز دارد.

سیستم‌های نظارت تصویری ابری با ارائه زیرساخت‌های ذخیره‌سازی و پردازش ویدیویی موجود به مشتریان، این مشکل را حل می‌کنند. یک مشتری نظارت تصویری ابری به سادگی باید دوربین را به اینترنت وصل کرده و آن را به حساب ابری خود پیوند دهد.

چندین روش تکنولوژیکی برای اتصال دوربین ها به فضای ابری وجود دارد. بدون شک راحت ترین و ارزان ترین روش این است که دوربین به طور مستقیم و بدون مشارکت تجهیزات اضافی مانند سرور یا ضبط کننده با ابر متصل می شود و با آن کار می کند.

برای این کار لازم است یک ماژول نرم افزاری که با ابر کار می کند روی دوربین نصب شود. با این حال، اگر در مورد دوربین‌های ارزان قیمت صحبت کنیم، آن‌ها منابع سخت‌افزاری بسیار محدودی دارند که تقریباً 100٪ توسط سیستم عامل اصلی فروشنده دوربین اشغال شده است و هیچ منبع لازم برای پلاگین ابری وجود ندارد. توسعه دهندگان ivideon این مشکل را اختصاص دادند یک مقاله، که توضیح می دهد که چرا آنها نمی توانند این افزونه را روی دوربین های ارزان قیمت نصب کنند. در نتیجه حداقل قیمت دوربین 5000 روبل (80 دلار) است و میلیون ها پول برای تجهیزات خرج می شود.

ما با موفقیت این مشکل را حل کرده ایم. اگر به چگونگی علاقه مند هستید - به برش خوش آمدید

کمی از تاریخ

در سال 2016، ما شروع به توسعه یک پلت فرم نظارت تصویری ابری برای Rostelecom کردیم.

از نظر نرم افزار دوربین، در مرحله اول مسیر "استاندارد" را برای چنین کارهایی دنبال کردیم: افزونه خودمان را توسعه دادیم که در سیستم عامل استاندارد دوربین فروشنده نصب شده و با ابر ما کار می کند. با این حال، شایان ذکر است که ما در طول طراحی از سبک‌ترین و کارآمدترین راه‌حل‌ها استفاده کردیم (به عنوان مثال، اجرای C ساده از protobuf، libev، mbedtls و کتابخانه‌های راحت اما سنگین مانند boost) کاملاً رها شده است.

در حال حاضر، هیچ راه‌حل یکپارچه‌سازی جهانی در بازار دوربین IP وجود ندارد: هر فروشنده راه مخصوص به خود را برای نصب افزونه، مجموعه‌ای از APIهای خود برای عملکرد سیستم‌افزار و مکانیزم به‌روزرسانی منحصربه‌فرد دارد.

این بدان معنی است که برای هر فروشنده دوربین لازم است که به صورت جداگانه یک لایه جامع از نرم افزار یکپارچه سازی ایجاد شود. و در زمان شروع توسعه، توصیه می شود فقط با 1 فروشنده کار کنید تا تلاش های تیم را روی توسعه منطق کار با ابر متمرکز کنید.

اولین فروشنده ای که انتخاب شد، هایک ویژن، یکی از رهبران جهانی در بازار دوربین بود که یک API مستند و پشتیبانی فنی مهندسی شایسته ارائه می کرد.

ما اولین پروژه آزمایشی خود را با استفاده از دوربین های هایک ویژن راه اندازی کردیم.

تقریباً بلافاصله پس از راه‌اندازی، کاربران ما شروع به پرسیدن سؤالاتی در مورد امکان اتصال دوربین‌های ارزان‌تر از تولیدکنندگان دیگر به این سرویس کردند.

من گزینه اجرای یک لایه یکپارچه سازی برای هر فروشنده را تقریباً بلافاصله رد کردم - زیرا مقیاس پذیری ضعیفی دارد و الزامات فنی جدی را بر سخت افزار دوربین تحمیل می کند. هزینه دوربینی که این شرایط ورودی را برآورده می کند: 60-70 دلار

بنابراین، تصمیم گرفتم عمیق‌تر کاوش کنم - سفت‌افزار خودم را برای دوربین‌های هر فروشنده بسازم. این رویکرد به طور قابل توجهی نیاز به منابع سخت افزاری دوربین را کاهش می دهد - زیرا لایه کار با ابر بسیار مؤثرتر با برنامه ویدیویی ادغام شده است و هیچ چربی غیرضروری استفاده نشده در سیستم عامل وجود ندارد.

و آنچه مهم است این است که هنگام کار با دوربین در سطح پایین، می توان از AES سخت افزاری استفاده کرد که داده ها را بدون ایجاد بار اضافی بر روی CPU کم مصرف رمزگذاری می کند.

در آن لحظه ما اصلاً چیزی نداشتیم. اصلا هیچی.

تقریباً همه فروشندگان در چنین سطح پایینی آماده همکاری با ما نبودند. هیچ اطلاعاتی در مورد مدارها و قطعات وجود ندارد، هیچ SDK رسمی چیپست ها و اسناد حسگر وجود ندارد.
همچنین پشتیبانی فنی وجود ندارد.

همه سوالات باید از طریق مهندسی معکوس - آزمون و خطا - پاسخ داده می شد. اما ما موفق شدیم.

اولین مدل‌های دوربینی که ما روی آن‌ها آزمایش کردیم، دوربین‌های شیائومی Yi Ants، هایک ویژن، داهوا، Spezvision، دوربین‌های D-Link و چندین دوربین چینی بی‌نام فوق‌العاده ارزان بودند.

تکنیک

دوربین های مبتنی بر چیپست Hisilicon 3518E. مشخصات سخت افزاری دوربین ها به شرح زیر است:

مورچه های شیائومی یی
NONAME

SoC
Hisilicon 3518E
Hisilicon 3518E

رم
64MB
64MB

FLASH
16MB
8MB

اینترنت بی سیم
mt7601/bcm43143
-

سنسور
ov9732 (720p)
ov9712 (720p)

اترنت
-
+

میکرو
+
+

میکروفن
+
+

گوینده
+
+

IRL شد
+
+

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. بله، بله، این اشتباه تایپی نیست - هسته لینوکس و همه، همه، همه برنامه ها فقط به 38 مگابایت RAM دسترسی دارند.

همچنین در کنار uboot یک بلوک خاص به نام وجود دارد reg_info، که حاوی یک اسکریپت سطح پایین برای مقداردهی اولیه DDR و تعدادی رجیستر سیستم SoC است. محتوا reg_info بستگی به مدل دوربین دارد و اگر درست نباشد، دوربین حتی نمی‌تواند uboot را بارگیری کند، اما در همان مراحل اولیه بارگذاری منجمد می‌شود.

در ابتدا، زمانی که بدون پشتیبانی فروشنده کار می کردیم، به سادگی این بلوک را از سیستم عامل اصلی دوربین کپی کردیم.

هسته لینوکس و rootfs

دوربین‌ها از هسته لینوکس استفاده می‌کنند که بخشی از SDK تراشه است؛ معمولاً اینها جدیدترین هسته‌های شاخه 3.x نیستند، بنابراین اغلب مجبوریم با این واقعیت مقابله کنیم که درایورهای تجهیزات اضافی با هسته مورد استفاده سازگار نیستند. ، و ما باید آنها را به دوربین های کرنل پورت کنیم.

مسئله دیگر اندازه هسته است. وقتی اندازه FLASH فقط 8 مگابایت است، هر بایت به حساب می آید و وظیفه ما این است که با دقت تمام توابع هسته استفاده نشده را غیرفعال کنیم تا اندازه را به حداقل برسانیم.

Rootfs یک فایل سیستم پایه است. آن شامل busybox، درایورهای ماژول وای فای، مجموعه ای از کتابخانه های استاندارد سیستم، مانند libld и libcو همچنین نرم افزار ما که مسئولیت منطق کنترل LED، مدیریت اتصال شبکه و به روز رسانی سیستم عامل را بر عهده دارد.

سیستم فایل ریشه به صورت initramfs به هسته متصل می شود و در نتیجه ساخت یک فایل دریافت می کنیم. uImage، که شامل کرنل و rootfs است.

برنامه ویدیویی

پیچیده‌ترین و پرمصرف‌ترین بخش میان‌افزار، برنامه‌ای است که ضبط ویدیویی-صوتی، رمزگذاری ویدیو، پیکربندی پارامترهای تصویر، پیاده‌سازی تجزیه و تحلیل ویدیو، به عنوان مثال، آشکارسازهای حرکت یا صدا، کنترل PTZ و وظیفه تعویض روز و حالت های شب

یک ویژگی مهم، حتی می توانم بگویم کلیدی، نحوه تعامل برنامه ویدیویی با پلاگین ابری است.

در راه‌حل‌های سنتی «سیستم‌افزار فروشنده + افزونه ابر»، که نمی‌تواند روی سخت‌افزار ارزان کار کند، ویدیوی داخل دوربین از طریق پروتکل RTSP منتقل می‌شود - و این یک هزینه سنگین است: کپی و انتقال داده‌ها از طریق سوکت، سیستم‌های غیرضروری.

در اینجا ما از مکانیزم حافظه مشترک استفاده می کنیم - ویدئو از طریق سوکت بین اجزای نرم افزار دوربین کپی یا ارسال نمی شود، بنابراین به طور بهینه و با دقت از قابلیت های سخت افزاری متوسط ​​دوربین استفاده می شود.

به روز رسانی زیرسیستم

نقطه افتخار ویژه، زیرسیستم مقاوم در برابر خطا برای به روز رسانی سیستم عامل آنلاین است.

بگذارید مشکل را توضیح دهم. به روز رسانی سیستم عامل از نظر فنی یک عملیات اتمی نیست، و اگر در وسط به روز رسانی قطع برق رخ دهد، فلش مموری حاوی بخشی از سیستم عامل جدید "تحت نوشته" خواهد بود. اگر اقدامات خاصی انجام ندهید، دوربین تبدیل به یک "آجر" می شود که باید به مرکز خدمات منتقل شود.

ما نیز با این مشکل برخورد کرده ایم. حتی اگر دوربین در حین به روز رسانی خاموش باشد، به طور خودکار و بدون دخالت کاربر، سیستم عامل را از ابر دانلود کرده و عملیات بازیابی را انجام می دهد.

بیایید با جزئیات بیشتر به تکنیک نگاه کنیم:

آسیب پذیرترین نقطه بازنویسی پارتیشن با هسته لینوکس و سیستم فایل ریشه است. اگر یکی از این اجزا آسیب ببیند، دوربین به هیچ وجه فراتر از بوت لودر uboot بوت نمی شود که نمی تواند سیستم عامل را از ابر دانلود کند.

این به این معنی است که ما باید اطمینان حاصل کنیم که دوربین در هر زمانی در طول فرآیند به‌روزرسانی، هسته و rootfs کار می‌کند. به نظر می رسد ساده ترین راه حل این باشد که به طور مداوم دو نسخه از هسته را با rootfs روی فلش مموری ذخیره کنید و اگر هسته اصلی آسیب دید، آن را از نسخه پشتیبان بارگذاری کنید.

یک راه حل خوب - با این حال، هسته با rootfs حدود 3.5 مگابایت اشغال می کند و برای یک نسخه پشتیبان دائمی باید 3.5 مگابایت را اختصاص دهید. ارزان ترین دوربین ها به سادگی فضای خالی زیادی برای یک هسته پشتیبان ندارند.

بنابراین، برای پشتیبان گیری از هسته در طول به روز رسانی سیستم عامل، از پارتیشن برنامه استفاده می کنیم.
و برای انتخاب پارتیشن مورد نظر با کرنل از دو دستور استفاده می شود bootm در uboot - در ابتدا سعی می کنیم هسته اصلی را بارگذاری کنیم و اگر آسیب دید، نسخه پشتیبان را بارگذاری کنیم.

این تضمین می کند که در هر زمان دوربین هسته صحیح با rootfs را داشته باشد و بتواند سیستم عامل را بوت و بازیابی کند.

سیستم CI/CD برای ساخت و استقرار سیستم عامل

برای ساخت فریم‌ور از gitlab CI استفاده می‌کنیم که به‌طور خودکار برای همه مدل‌های دوربین پشتیبانی‌شده فریم‌ور می‌سازد و پس از ساخت فریم‌ور، به‌طور خودکار در سرویس به‌روزرسانی نرم‌افزار دوربین مستقر می‌شود.

از این سرویس، به‌روزرسانی‌های میان‌افزار به دوربین‌های تست QA ما و پس از اتمام تمام مراحل آزمایش، به دوربین‌های کاربران تحویل داده می‌شوند.

امنیت اطلاعات

بر کسی پوشیده نیست که امروزه امنیت اطلاعات مهمترین جنبه هر دستگاه اینترنت اشیا از جمله دوربین ها است. بات نت هایی مانند Mirai در اینترنت پرسه می زنند و میلیون ها دوربین را با سیستم عامل استاندارد فروشندگان آلوده می کنند. با تمام احترامی که برای فروشندگان دوربین قائل هستم، نمی‌توانم توجه نکنم که سیستم عامل استاندارد دارای عملکردهای زیادی است که برای کار با ابر لازم نیست، اما حاوی آسیب‌پذیری‌های بسیاری است که بات‌نت‌ها از آنها بهره می‌برند.

بنابراین، تمام عملکردهای استفاده نشده در سیستم عامل ما غیرفعال است، همه پورت های tcp/udp بسته هستند و هنگام به روز رسانی سیستم عامل، امضای دیجیتال نرم افزار بررسی می شود.

و علاوه بر این، سیستم عامل تحت آزمایش منظم در آزمایشگاه امنیت اطلاعات قرار می گیرد.

نتیجه

اکنون سیستم عامل ما به طور فعال در پروژه های نظارت تصویری استفاده می شود. شاید بزرگترین آنها پخش رای گیری در روز انتخاب رئیس جمهور فدراسیون روسیه باشد.
این پروژه شامل بیش از 70 هزار دوربین با سیستم عامل ما بود که در شعب اخذ رای در کشور ما نصب شد.

با حل تعدادی از مشکلات پیچیده و در برخی جاها حتی در آن زمان تقریباً غیرممکن، البته ما به عنوان مهندس رضایت زیادی دریافت کردیم، اما علاوه بر این، میلیون ها دلار نیز در خرید دوربین صرفه جویی کردیم. و در این مورد، صرفه جویی فقط کلمات و محاسبات نظری نیست، بلکه نتایج یک مناقصه از قبل تکمیل شده برای خرید تجهیزات است. بر این اساس، اگر در مورد نظارت تصویری ابری صحبت کنیم: دو رویکرد وجود دارد - از نظر استراتژیک بر تخصص و توسعه سطح پایین تکیه کنید، که منجر به صرفه جویی زیادی در تجهیزات می شود، یا استفاده از تجهیزات گران قیمت، که، اگر به طور خاص به ویژگی های مصرف کننده نگاه کنید، عملاً هیچ است. متفاوت از ارزان های مشابه

چرا تصمیم گیری در مورد انتخاب رویکرد یکپارچه سازی در اسرع وقت از نظر استراتژیک مهم است؟ هنگام توسعه یک افزونه، توسعه‌دهندگان به فناوری‌های خاصی (کتابخانه‌ها، پروتکل‌ها، استانداردها) تکیه می‌کنند. و اگر مجموعه‌ای از فناوری‌ها فقط برای تجهیزات گران قیمت انتخاب شوند، در آینده به احتمال زیاد تلاش برای تغییر به دوربین‌های ارزان قیمت، حداقل زمان بسیار زیادی طول می‌کشد یا حتی شکست می‌خورد و بازگشت به تجهیزات گران قیمت رخ خواهد داد.

منبع: www.habr.com