שלום לכולם!

זה כנראה לא סוד ששירותי מעקב וידאו בענן צוברים פופולריות לאחרונה. וברור למה זה קורה, וידאו הוא תוכן "כבד", שהאחסון שלו דורש תשתית וכמויות גדולות של אחסון דיסק. שימוש במערכת מעקב וידאו מקומית מצריך כספים לתפעול ותמיכה, הן עבור ארגון המשתמש במאות מצלמות מעקב והן עבור משתמש בודד עם מספר מצלמות.

מערכות מעקב וידאו בענן פותרות בעיה זו על ידי אספקת ללקוחות תשתית קיימת לאחסון ועיבוד וידאו. לקוח מעקב וידאו בענן פשוט צריך לחבר את המצלמה לאינטרנט ולקשר אותה לחשבון הענן שלו.

ישנן מספר דרכים טכנולוגיות לחבר מצלמות לענן. ללא ספק השיטה הנוחה והזולה ביותר היא שהמצלמה מתחברת ישירות ועובדת עם הענן, ללא השתתפות של ציוד נוסף כמו שרת או מקליט.

לשם כך, יש צורך שמודול תוכנה שעובד עם הענן יותקן על המצלמה. עם זאת, אם אנחנו מדברים על מצלמות זולות, אז יש להן משאבי חומרה מוגבלים מאוד, אשר תפוסים כמעט ב-100% על ידי הקושחה המקורית של ספק המצלמה, ואין משאבים נחוצים עבור תוסף הענן. מפתחים מ-ivideon הקדישו את הבעיה הזו מאמר, מה שמסביר מדוע הם לא יכולים להתקין את התוסף על מצלמות זולות. כתוצאה מכך, המחיר המינימלי של המצלמה הוא 5000 רובל (80 דולר) ומיליוני כסף שהושקעו על ציוד.

פתרנו את הבעיה הזו בהצלחה. אם מעניין אותך איך - ברוכים הבאים לגזרה

קצת היסטוריה

בשנת 2016, התחלנו לפתח פלטפורמת מעקב וידאו בענן עבור Rostelecom.

מבחינת תוכנת המצלמה, בשלב הראשון הלכנו בדרך ה"סטנדרטית" למשימות כאלה: פיתחנו תוסף משלנו, שמותקן בקושחה הסטנדרטית של מצלמת הספק ועובד עם הענן שלנו. עם זאת, ראוי לציין שבמהלך העיצוב השתמשנו בפתרונות הקלים והיעילים ביותר (לדוגמה, הטמעת C רגילה של protobuf, libev, mbedtls וספריות נוחות אך כבדות שננטשו לחלוטין כמו boost)

נכון לעכשיו, אין פתרונות אינטגרציה אוניברסליים בשוק מצלמות ה-IP: לכל ספק יש דרך משלו להתקין את התוסף, סט API משלו להפעלת הקושחה ומנגנון עדכון ייחודי.

המשמעות היא שלכל ספק מצלמה יש צורך לפתח בנפרד שכבה מקיפה של תוכנת אינטגרציה. ובזמן התחלת הפיתוח, רצוי לעבוד רק עם ספק 1 על מנת לרכז את מאמצי הצוות בפיתוח ההיגיון לעבודה עם הענן.

הספק הראשון שנבחר היה Hikvision, מהמובילות בעולם בשוק המצלמות, המספק API מתועד היטב ותמיכה טכנית הנדסית מוכשרת.

השקנו את פרויקט הפיילוט הראשון שלנו, מעקב וידאו בענן Video Comfort, באמצעות מצלמות Hikvision.

כמעט מיד לאחר ההשקה, החלו המשתמשים שלנו לשאול שאלות לגבי האפשרות לחבר לשירות מצלמות זולות יותר מיצרניות אחרות.

דחיתי את האפשרות להטמיע שכבת אינטגרציה עבור כל ספק כמעט באופן מיידי - מכיוון שהיא ניתנת להרחבה בצורה גרועה ומטילה דרישות טכניות רציניות לחומרת המצלמה. עלות מצלמה העומדת בדרישות הקלט הללו: ~60-70$

לכן, החלטתי לחפור יותר לעומק - להכין קושחה משלי למצלמות מכל ספק. גישה זו מפחיתה באופן משמעותי את הדרישות למשאבי חומרת המצלמה - מכיוון השכבה לעבודה עם הענן משולבת בצורה הרבה יותר יעילה עם אפליקציית הווידאו, ואין שומן מיותר שלא נעשה בו שימוש בקושחה.

ומה שחשוב הוא שכאשר עובדים עם המצלמה ברמה נמוכה, אפשר להשתמש בחומרה AES, שמצפינת נתונים מבלי ליצור עומס נוסף על המעבד בעל הספק נמוך.

באותו רגע לא היה לנו כלום. שום דבר.

כמעט כל הספקים לא היו מוכנים לעבוד איתנו ברמה כל כך נמוכה. אין מידע על המעגלים והרכיבים, אין SDK רשמי של ערכות שבבים ותיעוד חיישנים.
אין גם תמיכה טכנית.

היה צריך לענות על כל השאלות באמצעות הנדסה לאחור - ניסוי וטעייה. אבל הצלחנו.

דגמי המצלמות הראשונים עליהם בדקנו היו מצלמות Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link וכמה מצלמות סיניות זולות במיוחד.

טכניקה

מצלמות המבוססות על ערכת השבבים Hisilicon 3518E. מאפייני החומרה של המצלמות הם כדלקמן:

נמלים שיאומי יי
noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
64MB
64MB

FLASH
16MB
8MB

וויי - פיי
mt7601/bcm43143
-

חיישן
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

מיקרופון
+
+

רַמקוֹל
+
+

IRLed
+
+

IRCut
+
+

התחלנו איתם.

כרגע אנו תומכים בערכות שבבים Hisilicon 3516/3518, כמו גם Ambarella S2L/S2LM. ישנם עשרות דגמי מצלמות.

הרכב קושחה

uboot

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 הוא רק 8MB, אז כל בייט נחשב והמשימה שלנו היא להשבית בזהירות את כל פונקציות הליבה שאינן בשימוש על מנת להקטין את הגודל למינימום.

Rootfs היא מערכת קבצים בסיסית. זה כולל busybox, מנהלי התקנים למודול wifi, קבוצה של ספריות מערכת סטנדרטיות, כגון libld и libc, כמו גם התוכנה שלנו, האחראית על לוגיקת בקרת LED, ניהול חיבורי רשת ועדכוני קושחה.

מערכת קבצי השורש מחוברת לקרנל כ-initramfs וכתוצאה מה-build נקבל קובץ אחד uImage, שמכיל גם את הקרנל וגם את ה-rootfs.

אפליקציית וידאו

החלק המורכב ועתיר המשאבים של הקושחה הוא האפליקציה, המספקת לכידת וידאו-אודיו, קידוד וידאו, מגדירה פרמטרים של תמונה, מיישמת ניתוח וידאו, למשל, גלאי תנועה או קול, שולטת ב-PTZ ואחראית על החלפת יום ו מצבי לילה.

תכונה חשובה, אפילו הייתי אומרת מפתח, היא האופן שבו אפליקציית הווידאו מקיימת אינטראקציה עם תוסף הענן.

בפתרונות מסורתיים 'קושמת ספק + תוסף ענן', שלא יכול לעבוד על חומרה זולה, וידאו בתוך המצלמה מועבר באמצעות פרוטוקול RTSP – וזוהי תקורה עצומה: העתקה והעברת נתונים דרך שקע, מערכות הפעלה מיותרות.

במקום זה אנו משתמשים במנגנון הזיכרון המשותף - הסרטון אינו מועתק או נשלח באמצעות שקע בין רכיבי תוכנת המצלמה, ובכך משתמשים בצורה מיטבית ובזהירות ביכולות החומרה הצנועות של המצלמה.

עדכון תת-מערכת

נקודה לגאווה מיוחדת היא תת-המערכת סובלנית לתקלות עבור עדכוני קושחה מקוונים.

תן לי להסביר את הבעיה. עדכון הקושחה הוא מבחינה טכנית לא פעולה אטומית, ואם מתרחשת הפסקת חשמל באמצע העדכון, אזי זיכרון הפלאש יכיל חלק מהקושחה החדשה "שכתובה". אם לא תנקוט באמצעים מיוחדים, המצלמה תהפוך ל"לבנה" שצריך לקחת למרכז שירות.

גם אנחנו טיפלנו בבעיה הזו. גם אם המצלמה כבויה במהלך העדכון, היא תוריד אוטומטית וללא התערבות משתמש את הקושחה מהענן ותחזיר את הפעולה.

בואו נסתכל על הטכניקה ביתר פירוט:

הנקודה הפגיעה ביותר היא החלפת המחיצה עם ליבת לינוקס ומערכת קבצי השורש. אם אחד מהרכיבים הללו פגום, המצלמה לא תעלה כלל מעבר ל-Ubootloader, שאינו יכול להוריד קושחה מהענן.

המשמעות היא שעלינו לוודא שלמצלמה יש ליבה ו-rootfs עובדים בכל עת במהלך תהליך העדכון. נראה שהפתרון הפשוט ביותר יהיה לאחסן כל הזמן שני עותקים של הליבה עם rootfs בזיכרון הפלאש, ואם הליבה הראשית פגומה, לטעון אותו מעותק הגיבוי.

פתרון טוב - עם זאת, הקרנל עם rootfs תופס כ-3.5MB ולגיבוי קבוע צריך להקצות 3.5MB. למצלמות הזולות ביותר פשוט אין כל כך הרבה מקום פנוי לגרעין גיבוי.

לכן, כדי לגבות את הליבה במהלך עדכון קושחה, אנו משתמשים במחיצת היישום.
וכדי לבחור את המחיצה הרצויה עם הקרנל, נעשה שימוש בשתי פקודות bootm ב-uboot - בהתחלה אנחנו מנסים לטעון את הליבה הראשית ואם הוא פגום, אז את הגיבוי.

זה מבטיח שבכל זמן נתון למצלמה תהיה הקרנל הנכון עם rootfs, והיא תוכל לאתחל ולשחזר את הקושחה.

מערכת CI/CD לבנייה ופריסה של קושחה

כדי לבנות קושחה, אנו משתמשים ב-gitlab CI, שבונה אוטומטית קושחה עבור כל דגמי המצלמה הנתמכים, ולאחר בניית הקושחה, היא נפרסת אוטומטית לשירות עדכון תוכנת המצלמה.

מהשירות, עדכוני קושחה נמסרים למצלמות בדיקת ה-QA שלנו, ועם השלמת כל שלבי הבדיקה, למצלמות המשתמשים.

אבטחת מידע

זה לא סוד שכיום אבטחת מידע היא ההיבט החשוב ביותר בכל מכשיר IoT, כולל מצלמות. רשתות בוטניות כמו Mirai מסתובבות באינטרנט, מדביקות מיליוני מצלמות בקושחה סטנדרטית של ספקים. עם כל הכבוד לספקי המצלמות, אני לא יכול שלא לציין שהקושחה הסטנדרטית מכילה הרבה פונקציונליות שאינה נחוצה לעבודה עם הענן, אך מכילה נקודות תורפה רבות שהבוטנטים מנצלים אותן.

לכן, כל הפונקציונליות שאינה בשימוש בקושחה שלנו מושבתת, כל יציאות tcp/udp סגורות, ובעת עדכון הקושחה נבדקת החתימה הדיגיטלית של התוכנה.

ומלבד זאת, הקושחה עוברת בדיקות שוטפות במעבדת אבטחת המידע.

מסקנה

כעת נעשה שימוש פעיל בקושחה שלנו בפרויקטים של מעקב וידאו. אולי הגדול שבהם הוא שידור ההצבעה ביום הבחירה של נשיא הפדרציה הרוסית.
הפרויקט כלל למעלה מ-70 אלף מצלמות עם הקושחה שלנו, שהותקנו בקלפיות בארצנו.

לאחר שפתרנו מספר בעיות מורכבות, ובמקומות מסוימים, אפילו באותה תקופה כמעט בלתי אפשרית, קיבלנו כמובן סיפוק רב כמהנדסים, אך חוץ מזה, חסכנו גם מיליוני דולרים ברכישת מצלמות. ובמקרה זה, חיסכון הוא לא רק מילים וחישובים תיאורטיים, אלא תוצאות של מכרז שכבר הושלם לרכישת ציוד. בהתאם לכך, אם אנחנו מדברים על מעקב וידאו בענן: ישנן שתי גישות - להסתמך אסטרטגית על מומחיות ופיתוח ברמה נמוכה, וכתוצאה מכך לחסכון עצום בציוד, או להשתמש בציוד יקר, שאם מסתכלים ספציפית על מאפייני הצרכן, הוא כמעט לא שונה מזולים דומים.

מדוע חשוב אסטרטגית להחליט על בחירת גישת האינטגרציה מוקדם ככל האפשר? כאשר מפתחים תוסף, מפתחים מסתמכים על טכנולוגיות מסוימות (ספריות, פרוטוקולים, תקנים). ואם נבחר סט טכנולוגיות רק עבור ציוד יקר, אז סביר להניח שבעתיד ניסיון לעבור למצלמות זולות, לכל הפחות, ייקח זמן רב בטירוף או אפילו ייכשל ותתרחש חזרה לציוד יקר.

מקור: www.habr.com