Γεια σε όλους!

Πιθανώς δεν είναι μυστικό ότι οι υπηρεσίες παρακολούθησης βίντεο cloud έχουν αποκτήσει δημοτικότητα πρόσφατα. Και είναι ξεκάθαρο γιατί συμβαίνει αυτό, το βίντεο είναι «βαρύ» περιεχόμενο, η αποθήκευση του οποίου απαιτεί υποδομή και μεγάλες ποσότητες αποθήκευσης δίσκου. Η χρήση ενός συστήματος βιντεοεπιτήρησης στο χώρο απαιτεί πόρους για τη λειτουργία και την υποστήριξη, τόσο για έναν οργανισμό που χρησιμοποιεί εκατοντάδες κάμερες παρακολούθησης όσο και για έναν μεμονωμένο χρήστη με πολλές κάμερες.

Τα συστήματα παρακολούθησης βίντεο cloud λύνουν αυτό το πρόβλημα παρέχοντας στους πελάτες μια υπάρχουσα υποδομή αποθήκευσης και επεξεργασίας βίντεο. Ένας πελάτης παρακολούθησης βίντεο cloud πρέπει απλώς να συνδέσει την κάμερα στο Διαδίκτυο και να τη συνδέσει με τον λογαριασμό του στο cloud.

Υπάρχουν διάφοροι τεχνολογικοί τρόποι σύνδεσης καμερών στο cloud. Αναμφίβολα, η πιο βολική και φθηνότερη μέθοδος είναι ότι η κάμερα συνδέεται απευθείας και λειτουργεί με το cloud, χωρίς τη συμμετοχή πρόσθετου εξοπλισμού όπως διακομιστή ή συσκευή εγγραφής.

Για να γίνει αυτό, είναι απαραίτητο να εγκατασταθεί στην κάμερα μια μονάδα λογισμικού που λειτουργεί με το cloud. Ωστόσο, αν μιλάμε για φθηνές κάμερες, τότε έχουν πολύ περιορισμένους πόρους υλικού, οι οποίοι καταλαμβάνονται σχεδόν 100% από το εγγενές υλικολογισμικό του προμηθευτή της κάμερας και δεν υπάρχουν απαραίτητοι πόροι για την προσθήκη cloud. Οι προγραμματιστές από το ivideon αφιέρωσαν αυτό το πρόβλημα ένα άρθρο, γεγονός που εξηγεί γιατί δεν μπορούν να εγκαταστήσουν το πρόσθετο σε φθηνές κάμερες. Ως αποτέλεσμα, η ελάχιστη τιμή της κάμερας είναι 5000 ρούβλια (80 δολάρια) και εκατομμύρια χρήματα δαπανώνται για εξοπλισμό.

Επιλύσαμε με επιτυχία αυτό το πρόβλημα. Εάν ενδιαφέρεστε για το πώς - καλώς ήρθατε στην περικοπή

Μια μικρή ιστορία

Το 2016, ξεκινήσαμε την ανάπτυξη μιας πλατφόρμας παρακολούθησης βίντεο cloud για τη Rostelecom.

Όσον αφορά το λογισμικό κάμερας, στο πρώτο στάδιο ακολουθήσαμε την «τυπική» διαδρομή για τέτοιες εργασίες: αναπτύξαμε το δικό μας πρόσθετο, το οποίο είναι εγκατεστημένο στο τυπικό υλικολογισμικό της κάμερας του προμηθευτή και λειτουργεί με το cloud μας. Ωστόσο, αξίζει να σημειωθεί ότι κατά τη διάρκεια του σχεδιασμού χρησιμοποιήσαμε τις πιο ελαφριές και αποτελεσματικές λύσεις (για παράδειγμα, απλή εφαρμογή C των protobuf, libev, mbedtls και εντελώς εγκαταλειμμένες βολικές αλλά βαριές βιβλιοθήκες όπως το boost)

Επί του παρόντος, δεν υπάρχουν καθολικές λύσεις ενοποίησης στην αγορά της κάμερας IP: κάθε προμηθευτής έχει τον δικό του τρόπο εγκατάστασης της προσθήκης, το δικό του σύνολο API για τη λειτουργία του υλικολογισμικού και έναν μοναδικό μηχανισμό ενημέρωσης.

Αυτό σημαίνει ότι για κάθε προμηθευτή κάμερας είναι απαραίτητο να αναπτυχθεί ξεχωριστά ένα ολοκληρωμένο επίπεδο λογισμικού ενοποίησης. Και τη στιγμή της έναρξης της ανάπτυξης, συνιστάται να συνεργάζεστε μόνο με 1 προμηθευτή, προκειμένου να επικεντρωθούν οι προσπάθειες της ομάδας στην ανάπτυξη της λογικής για την εργασία με το cloud.

Ο πρώτος προμηθευτής που επιλέχθηκε ήταν η Hikvision, ένας από τους παγκόσμιους ηγέτες στην αγορά καμερών, παρέχοντας ένα καλά τεκμηριωμένο API και ικανή τεχνική υποστήριξη μηχανικής.

Ξεκινήσαμε το πρώτο μας πιλοτικό έργο, το cloud παρακολούθησης βίντεο Comfort, χρησιμοποιώντας κάμερες Hikvision.

Σχεδόν αμέσως μετά την κυκλοφορία, οι χρήστες μας άρχισαν να κάνουν ερωτήσεις σχετικά με τη δυνατότητα σύνδεσης φθηνότερων καμερών από άλλους κατασκευαστές στην υπηρεσία.

Απέρριψα την επιλογή της εφαρμογής ενός επιπέδου ενοποίησης για κάθε προμηθευτή σχεδόν αμέσως - καθώς είναι ανεπαρκώς επεκτάσιμο και επιβάλλει σοβαρές τεχνικές απαιτήσεις στο υλικό της κάμερας. Το κόστος μιας κάμερας που πληροί αυτές τις απαιτήσεις εισόδου: ~60-70$

Ως εκ τούτου, αποφάσισα να σκάψω βαθύτερα - να φτιάξω το δικό μου υλικολογισμικό για κάμερες από οποιονδήποτε προμηθευτή. Αυτή η προσέγγιση μειώνει σημαντικά τις απαιτήσεις για πόρους υλικού κάμερας - επειδή Το στρώμα για εργασία με το cloud είναι πολύ πιο αποτελεσματικά ενσωματωμένο στην εφαρμογή βίντεο και δεν υπάρχει περιττό αχρησιμοποίητο λίπος στο υλικολογισμικό.

Και αυτό που είναι σημαντικό είναι ότι όταν εργάζεστε με την κάμερα σε χαμηλό επίπεδο, είναι δυνατή η χρήση υλικού AES, το οποίο κρυπτογραφεί δεδομένα χωρίς να δημιουργεί πρόσθετο φορτίο στη CPU χαμηλής κατανάλωσης.

Εκείνη τη στιγμή δεν είχαμε τίποτα απολύτως. Τίποτα απολύτως.

Σχεδόν όλοι οι πωλητές δεν ήταν έτοιμοι να συνεργαστούν μαζί μας σε τόσο χαμηλό επίπεδο. Δεν υπάρχουν πληροφορίες για τα κυκλώματα και τα εξαρτήματα, δεν υπάρχει επίσημο SDK των chipset και τεκμηρίωση αισθητήρων.
Επίσης δεν υπάρχει τεχνική υποστήριξη.

Όλες οι ερωτήσεις έπρεπε να απαντηθούν μέσω αντίστροφης μηχανικής — δοκιμής και λάθους. Αλλά τα καταφέραμε.

Τα πρώτα μοντέλα φωτογραφικών μηχανών που δοκιμάσαμε ήταν οι κάμερες Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link και αρκετές εξαιρετικά φτηνές ανώνυμες κινεζικές κάμερες.

Τεχνική

Κάμερες βασισμένες στο chipset Hisilicon 3518E. Τα χαρακτηριστικά υλικού των καμερών είναι τα εξής:

Xiaomi Yi Ants
Noname

SoC
Hisilicon 3518E
Hisilicon 3518E

RAM
300 ΜΒ
300 ΜΒ

FLASH
300 ΜΒ
300 ΜΒ

WiFi
mt7601/bcm43143
-

αισθητήρα
ov9732 (720p)
ov9712 (720p)

Ethernet
-
+

MicroSD
+
+

Μικρόφωνο
+
+

Ομιλητής
+
+

IRLed
+
+

IRCut
+
+

Ξεκινήσαμε με αυτούς.

Αυτήν τη στιγμή υποστηρίζουμε chipset Hisilicon 3516/3518, καθώς και Ambarella S2L/S2LM. Υπάρχουν δεκάδες μοντέλα φωτογραφικών μηχανών.

Σύνθεση υλικολογισμικού

uboot

Το 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 και όλες, όλες, όλες οι εφαρμογές έχουν πρόσβαση μόνο σε 38 megabyte μνήμης RAM.

Επίσης δίπλα στο uboot υπάρχει ένα ειδικό μπλοκ που ονομάζεται reg_info, το οποίο περιέχει ένα σενάριο χαμηλού επιπέδου για την προετοιμασία του DDR και έναν αριθμό καταχωρητών συστήματος του SoC. Περιεχόμενο reg_info εξαρτάται από το μοντέλο της κάμερας και αν δεν είναι σωστό, η κάμερα δεν θα μπορεί καν να φορτώσει το uboot, αλλά θα παγώσει στο πολύ πρώιμο στάδιο της φόρτωσης.

Στην αρχή, όταν εργαζόμασταν χωρίς υποστήριξη από τον προμηθευτή, απλώς αντιγράψαμε αυτό το μπλοκ από το αρχικό υλικολογισμικό της κάμερας.

Πυρήνας Linux και rootfs

Οι κάμερες χρησιμοποιούν τον πυρήνα Linux, ο οποίος είναι μέρος του SDK του τσιπ. συνήθως αυτοί δεν είναι οι πιο πρόσφατοι πυρήνες από τον κλάδο 3.x, επομένως συχνά πρέπει να αντιμετωπίσουμε το γεγονός ότι τα προγράμματα οδήγησης για πρόσθετο εξοπλισμό δεν είναι συμβατά με τον πυρήνα που χρησιμοποιείται , και πρέπει να τα επαναφέρουμε στις κάμερες του πυρήνα.

Ένα άλλο θέμα είναι το μέγεθος του πυρήνα. Όταν το μέγεθος FLASH είναι μόνο 8 MB, τότε κάθε byte μετράει και καθήκον μας είναι να απενεργοποιήσουμε προσεκτικά όλες τις αχρησιμοποίητες λειτουργίες του πυρήνα για να μειώσουμε το μέγεθος στο ελάχιστο.

Το Rootfs είναι ένα βασικό σύστημα αρχείων. Περιλαμβάνει busybox, προγράμματα οδήγησης μονάδων wifi, ένα σύνολο τυπικών βιβλιοθηκών συστήματος, όπως π.χ libld и libc, καθώς και το λογισμικό μας, το οποίο είναι υπεύθυνο για τη λογική ελέγχου LED, τη διαχείριση σύνδεσης δικτύου και τις ενημερώσεις υλικολογισμικού.

Το ριζικό σύστημα αρχείων συνδέεται με τον πυρήνα ως initramfs και ως αποτέλεσμα της κατασκευής παίρνουμε ένα αρχείο uImage, το οποίο περιέχει τόσο τον πυρήνα όσο και τα rootfs.

Εφαρμογή βίντεο

Το πιο περίπλοκο και με ένταση πόρων μέρος του υλικολογισμικού είναι η εφαρμογή, η οποία παρέχει λήψη βίντεο-ήχου, κωδικοποίηση βίντεο, διαμορφώνει παραμέτρους εικόνας, υλοποιεί ανάλυση βίντεο, για παράδειγμα, ανιχνευτές κίνησης ή ήχου, ελέγχει το PTZ και είναι υπεύθυνη για την εναλλαγή ημέρας και νυχτερινές λειτουργίες.

Ένα σημαντικό, θα έλεγα μάλιστα βασικό, χαρακτηριστικό είναι ο τρόπος με τον οποίο η εφαρμογή βίντεο αλληλεπιδρά με την προσθήκη cloud.

Στις παραδοσιακές λύσεις «υλικολογισμικό πωλητή + προσθήκη cloud», που δεν μπορεί να λειτουργήσει σε φθηνό υλικό, το βίντεο μέσα στην κάμερα μεταδίδεται μέσω του πρωτοκόλλου RTSP - και αυτό είναι τεράστιο κόστος: αντιγραφή και μετάδοση δεδομένων μέσω πρίζας, περιττές κλήσεις συστήματος.

Εδώ χρησιμοποιούμε τον μηχανισμό κοινής μνήμης - το βίντεο δεν αντιγράφεται ούτε αποστέλλεται μέσω υποδοχής μεταξύ των στοιχείων λογισμικού της κάμερας, με αποτέλεσμα να χρησιμοποιεί βέλτιστα και προσεκτικά τις μέτριες δυνατότητες υλικού της κάμερας.

Ενημέρωση υποσυστήματος

Ένα σημείο ιδιαίτερης υπερηφάνειας είναι το ανεκτικό σε σφάλματα υποσύστημα για ενημερώσεις υλικολογισμικού στο διαδίκτυο.

Επιτρέψτε μου να εξηγήσω το πρόβλημα. Η ενημέρωση του υλικολογισμικού δεν είναι τεχνικά μια ατομική λειτουργία και εάν παρουσιαστεί διακοπή ρεύματος στη μέση της ενημέρωσης, τότε η μνήμη flash θα περιέχει μέρος του "υπογραμμένου" νέου υλικολογισμικού. Εάν δεν λάβετε ειδικά μέτρα, η κάμερα θα γίνει τότε ένα "τούβλο" που πρέπει να μεταφερθεί σε ένα κέντρο σέρβις.

Έχουμε αντιμετωπίσει και αυτό το πρόβλημα. Ακόμα κι αν η κάμερα είναι απενεργοποιημένη κατά την ενημέρωση, αυτόματα και χωρίς παρέμβαση του χρήστη θα κατεβάσει το υλικολογισμικό από το cloud και θα επαναφέρει τη λειτουργία.

Ας δούμε την τεχνική με περισσότερες λεπτομέρειες:

Το πιο ευάλωτο σημείο είναι η αντικατάσταση του διαμερίσματος με τον πυρήνα του Linux και το σύστημα αρχείων ρίζας. Εάν ένα από αυτά τα στοιχεία είναι κατεστραμμένο, η κάμερα δεν θα εκκινήσει καθόλου πέρα ​​από το πρόγραμμα εκκίνησης uboot, το οποίο δεν μπορεί να πραγματοποιήσει λήψη υλικολογισμικού από το cloud.

Αυτό σημαίνει ότι πρέπει να διασφαλίσουμε ότι η κάμερα έχει λειτουργικό πυρήνα και rootf ανά πάσα στιγμή κατά τη διάρκεια της διαδικασίας ενημέρωσης. Φαίνεται ότι η απλούστερη λύση θα ήταν να αποθηκεύετε συνεχώς δύο αντίγραφα του πυρήνα με rootf στη μνήμη flash και, εάν ο κύριος πυρήνας είναι κατεστραμμένος, να τον φορτώνετε από το αντίγραφο ασφαλείας.

Μια καλή λύση - ωστόσο, ο πυρήνας με rootfs καταλαμβάνει περίπου 3.5 MB και για μόνιμο αντίγραφο ασφαλείας πρέπει να διαθέσετε 3.5 MB. Οι φθηνότερες κάμερες απλά δεν έχουν τόσο πολύ ελεύθερο χώρο για εφεδρικό πυρήνα.

Επομένως, για να δημιουργήσουμε αντίγραφα ασφαλείας του πυρήνα κατά τη διάρκεια μιας ενημέρωσης υλικολογισμικού, χρησιμοποιούμε το διαμέρισμα της εφαρμογής.
Και για να επιλέξετε το επιθυμητό διαμέρισμα με τον πυρήνα, χρησιμοποιούνται δύο εντολές bootm στο uboot - στην αρχή προσπαθούμε να φορτώσουμε τον κύριο πυρήνα και αν είναι χαλασμένος, τότε τον εφεδρικό.

Αυτό διασφαλίζει ότι ανά πάσα στιγμή η κάμερα θα έχει τον σωστό πυρήνα με rootfs και θα μπορεί να εκκινήσει και να επαναφέρει το υλικολογισμικό.

Σύστημα CI/CD για δημιουργία και ανάπτυξη υλικολογισμικού

Για τη δημιουργία υλικολογισμικού, χρησιμοποιούμε το gitlab CI, το οποίο δημιουργεί αυτόματα υλικολογισμικό για όλα τα υποστηριζόμενα μοντέλα καμερών και μετά την κατασκευή του υλικολογισμικού, αναπτύσσεται αυτόματα στην υπηρεσία ενημέρωσης λογισμικού της κάμερας.

Από την υπηρεσία, οι ενημερώσεις υλικολογισμικού παραδίδονται στις κάμερες δοκιμών QA και μετά την ολοκλήρωση όλων των σταδίων της δοκιμής, στις κάμερες των χρηστών.

Ασφάλεια Πληροφοριών

Δεν είναι μυστικό ότι στις μέρες μας η ασφάλεια των πληροφοριών είναι η πιο σημαντική πτυχή οποιασδήποτε συσκευής IoT, συμπεριλαμβανομένων των καμερών. Botnet όπως το Mirai περιφέρονται στο Διαδίκτυο, μολύνοντας εκατομμύρια κάμερες με τυπικό υλικολογισμικό από προμηθευτές. Με όλο τον σεβασμό προς τους προμηθευτές καμερών, δεν μπορώ παρά να σημειώσω ότι το τυπικό υλικολογισμικό περιέχει πολλές λειτουργίες που δεν είναι απαραίτητες για την εργασία με το cloud, αλλά περιέχει πολλά τρωτά σημεία που εκμεταλλεύονται τα botnet.

Επομένως, όλες οι αχρησιμοποίητες λειτουργίες στο υλικολογισμικό μας είναι απενεργοποιημένες, όλες οι θύρες tcp/udp είναι κλειστές και κατά την ενημέρωση του υλικολογισμικού ελέγχεται η ψηφιακή υπογραφή του λογισμικού.

Και εκτός από αυτό, το υλικολογισμικό υποβάλλεται σε τακτικές δοκιμές στο εργαστήριο ασφάλειας πληροφοριών.

Συμπέρασμα

Τώρα το υλικολογισμικό μας χρησιμοποιείται ενεργά σε έργα παρακολούθησης βίντεο. Ίσως το μεγαλύτερο από αυτά είναι η μετάδοση της ψηφοφορίας την ημέρα της εκλογής του Προέδρου της Ρωσικής Ομοσπονδίας.
Το έργο αφορούσε περισσότερες από 70 χιλιάδες κάμερες με το firmware μας, οι οποίες εγκαταστάθηκαν σε εκλογικά τμήματα της χώρας μας.

Έχοντας λύσει μια σειρά από περίπλοκα και σε ορισμένα σημεία, ακόμη και εκείνη την εποχή σχεδόν αδύνατα προβλήματα, λάβαμε, φυσικά, μεγάλη ικανοποίηση ως μηχανικοί, αλλά εκτός από αυτό, εξοικονομήσαμε επίσης εκατομμύρια δολάρια για την αγορά καμερών. Και σε αυτή την περίπτωση, η εξοικονόμηση δεν είναι μόνο λόγια και θεωρητικοί υπολογισμοί, αλλά τα αποτελέσματα ενός ήδη ολοκληρωμένου διαγωνισμού για την αγορά εξοπλισμού. Αντίστοιχα, αν μιλάμε για παρακολούθηση βίντεο στο cloud: υπάρχουν δύο προσεγγίσεις - βασιστείτε στρατηγικά σε τεχνογνωσία και ανάπτυξη χαμηλού επιπέδου, με αποτέλεσμα τεράστια εξοικονόμηση εξοπλισμού ή χρήση ακριβού εξοπλισμού, ο οποίος, αν κοιτάξετε συγκεκριμένα τα χαρακτηριστικά των καταναλωτών, πρακτικά δεν είναι διαφορετικά από παρόμοια φθηνά.

Γιατί είναι στρατηγικά σημαντικό να αποφασίζεται η επιλογή της προσέγγισης ολοκλήρωσης όσο το δυνατόν νωρίτερα; Κατά την ανάπτυξη ενός πρόσθετου, οι προγραμματιστές βασίζονται σε ορισμένες τεχνολογίες (βιβλιοθήκες, πρωτόκολλα, πρότυπα). Και αν επιλεγεί ένα σύνολο τεχνολογιών μόνο για ακριβό εξοπλισμό, τότε στο μέλλον μια προσπάθεια μετάβασης σε φθηνές κάμερες πιθανότατα, τουλάχιστον, θα διαρκέσει πολύ μεγάλο χρονικό διάστημα ή ακόμη και θα αποτύχει και θα υπάρξει επιστροφή σε ακριβό εξοπλισμό.

Πηγή: www.habr.com