Novicam как подключить к телефону

Обновлено: 19.09.2024

Интерфейс программы IVMS 4.1

При установке видеонаблюдения в одном из офисов Саратова возникла необходимость настройки мониторинга на компьютере директора.

Выбрали программное обеспечение NOVIcam PRO IVMS 4.1, разработанное специально для регистраторов NOVIcam серии PRO, который и установлен на объекте.

Она позволяет подключиться к регистратору как по IP-адресу, так и с использованием облачного сервиса.

Рассмотрим оба варианта.

Содержание статьи:

Настройка подключения по IP-адресу.

Этот способ предпочтительней, т.к. исключает проблемы облачного сервиса - зависания, тормоза, обрывы связи, но возможен, только если регистратор и компьютер находятся в одной локальной сети, либо у компании есть статический IP-адрес.

1) Скачиваем программу NOVIcam PRO IVMS 4.1 c официального сайта компании NOVIcam, либо по прямой ссылке (тоже с официального сайта).

2) При установке игнорируем предупреждения антивирусов (ссылка и сама программа проверены - вирусов нет), все настройки оставляем без изменений, кроме галочки установки утилиты WinpCap - её убираем.

Установка программы IVMS 4.1

3) Запускаем программу иконкой на рабочем столе. Не пугаемся, если долго ничего не происходит - программа запускается от 1 до 5 минут, в зависимости от быстродействия компьютера.

Если появилось предупреждение антивируса или брандмауэра - добавляем программу в исключения. В моём случае это выбор пункта "Всегда разрешить" и сохранение изменений кнопкой "ОК".

Добавление IVMS 4.1 в исключения брандмауэра

4) При первом запуске создадим логин и пароль для входа в программу. Они могут быть произвольными и не обязаны совпадать с логином и паролем регистратора. Можно установить галочку "Вкл. автомат. авторизации", чтобы каждый раз не вводить данные заново.

Создание логина и пароля в программе IVMS 4.1

5) Так же при первом запуске откроется окно помощника - закрываем, будем работать в основном интерфейсе.

6) Открываем окно "Управление устройством", жмём "Добавить устройство" и вводим настройки:

Меню программы IVMS 4.1

Кнопка добавления устройства в программе IVMS 4.1

  • Режим добавления - оставляем в положении "IP / домен"
  • Галочка "Добавить отключенные" - не ставим
  • Псевдоним - произвольное название устройства
  • Адрес - IP-адрес, прописанный в настройках видеорегистратора
  • Порт - оставляем без изменений, если не менялся порт в настройках регистратора
  • Имя - логин для доступа к регистратору (такой же, как в регистраторе)
  • Пароль - пароль для доступа к регистратору (такой же, как в регистраторе)
  • Галочка "Экспортировать в группу" - оставляем

Добавление устройства в программе IVMS 4.1

7) После нажатия кнопки "Добавить" устройство появится в списке. Зелёная пиктограмма планеты в статусе пользователя означает успешное соединение с регистратором, серая - отсутствие связи*. При отсутствии связи следует проверять настройки программы (пункт 6 данной инструкции), ping регистратора, настройки сети в самом регистраторе, физическое подключение к сети регистратора и компьютера.

* - подключение может занять до 2 минут. Если по истечении этого времени успешного соединения не произошло - проверяем настройки.

Окно управления устройствами программы IVMS 4.1

8) Переходим на вкладку "Группа", в левой части окна щёлкаем по "Кодирование каналов" и жмём "Импорт".

Вкладка "Группа" программы IVMS 4.1

Если в левой части окна пусто (ни одной группы не создано) - жмём "Добавить группу". Имя группы можно выбрать любое.

Добавление группы в программе IVMS 4.1

9) Импортируем нужные каналы путём выделения окошка с камерой и нажатия клавиши "Импортировать", закрываем окно.

Импорт каналов программы IVMS 4.1

10) Открываем окно "Основной ракурс", выбираем тип просмотра (1, 4, 9 или 16 камер) и перетаскиваем мышкой камеры из списка в окошки.

Окно "Основной ракурс" программы IVMS 4.1

Настройка подключения с использованием облачного сервиса.

1) Подключим к видеорегистратору монитор и сделаем следующее:

  • проверим, что галочка "Enable Cloud P2P" во вкладке "Настройки сети" установлена
  • с этой же вкладки перепишем себе код проверки, состоящий из заглавных латинских букв

Сетевые настройки регистратора NOVIcam

  • откроем вкладку "Сведения о системе" и со строки "Серийный номер" перепишем вторую группу из 9 цифр - это CloudID

Вкладка "Сведения о системе" регистратора NOVIcam

2) Выполним шаги 1-5 первой части статьи.

3) Открываем окно "Управление устройством", жмём "Добавить новый тип устройства".

Меню программы IVMS 4.1

4) Ставим галочку на "P2P", жмём OK.

Выбор типа устройства в программе IVMS 4.1

  • P2P Cloud Account - придумываем логин для входа
  • Пароль - придумываем пароль
  • Подтверждение - повторяем пароль
  • E-mail - актуальный адрес почты для подтверждения регистрации
  • Код безопасности - вводим буквы/цифры с картинки слева
  • Жмём "Получить код подтверждения", ищем код в письме на почте и вводим его в поле "Код подтверждения электронной почты"

Создание аккаунта облачного сервиса в программе IVMS 4.1

Ввод логина и пароля аккаунта облачного сервиса в программе IVMS 4.1

7) Теперь стала активной кнопка "Добавить устройство" в окне "Управление устройством". Жмём её и вводим ранее записанный CloudID (9 цифр серийного номера регистратора) и код безопасности (заглавные латинские буквы). Жмём OK.

Добавление устройства облачного сервиса в программе IVMS 4.1

Добавленное устройство в облачном сервисе программы IVMS 4.1

Работа с архивом.

При подключении через облако у меня архив так и не заработал. Если у кого-то получилось его настроить - отпишитесь в комментариях.

При подключении по IP-адресу архив работает с полным функционалом.

Просмотр архива осуществляется в окне "Удалённое воспроизведение". Возможен одновременный просмотр от одной до 4 камер.

Выбор окна работы с архивом программы IVMS 4.1

Выбор камер осуществляется раскрытием списка "Камера" в левой части окна и перетаскиванием нужных камер в окошки справа.

Выбор даты осуществляется нажатием на нужное число календаря в левой части окна. Числа, в которых есть записи выделены жирным шрифтом.

Наверное, ни для кого не секрет, что в последнее время облачные сервисы видеонаблюдения набирают популярность. И понятно почему так происходит, видео — это "тяжелый" контент, для хранения которого необходима инфраструктура и большие объемы дискового хранилища. Использование локальной системы видеонаблюдения требует средств на эксплуатацию и поддержку, как в случае организации, использующей сотни камер наблюдения, так и в случае индивидуального пользователя с несколькими камерами.


Облачные системы видеонаблюдения решают эту задачу — предоставляя клиентам уже существующую инфраструктуру хранения и обработки видео. Клиенту облачного видеонаблюдения достаточно просто подключить камеру к интернету и привязать к своему аккаунту в облаке.

Есть несколько технологических способов подключения камер к облаку. Бесспорно, наиболее удобный и дешевый способ — камера напрямую подключается и работает с облаком, без участия дополнительного оборудования типа сервера или регистратора.

Для этого необходимо, чтобы на камере был установлен модуль ПО работающий с облаком. Однако, если говорить про дешевые камеры, то у них очень ограничены аппаратные ресурсы, которые почти на 100% занимает родная прошивка вендора камеры, а ресурсов необходимых для облачного плагина — нет. Этой проблеме разработчики из ivideon посвятили статью, в которой говорится почему они не могут установить плагин на дешевые камеры. Как итог, минимальная цена камеры — 5000р ($80 долларов) и миллионы потраченных денег на оборудование.

Мы эту проблему успешно решили. Если интересно как — велком под кат

В 2016 году мы стартовали разработку платформы облачного видеонаблюдения для Ростелекома.

В части ПО камер на первом этапе пошли "стандартным" для таких задач путем: разработали свой плагин, который устанавливается в штатную прошивку камеры вендора и работает с нашим облаком. Однако, стоит отметить, что при проектировании мы использовали наиболее легковесные и эффективные решения (например, plain C реализацию protobuf, libev, mbedtls и полностью отказались от удобных, но тяжелых библиотек типа boost)

Сейчас на рынке IP камер нет универсальных решений по интеграции: у каждого вендора свой способ установки плагина, свой набор API для работы прошивки и уникальный механизм обновления.

Это означает, что для каждого вендора камер необходимо индивидуально разрабатывать объемный слой интеграционного ПО. И на момент старта разработки целесообразно работать только с 1-ним вендором, что бы сосредоточить усилия команды на разработке логики работы с облаком.

Первым вендором был выбран Hikvision — один из мировых лидеров на рынке камер, предоставляющий хорошо документированное API и грамотную инженерную техническую поддержку.

На камерах Hikvision мы и запустили наш первый пилотный проект облачное видеонаблюдение Видеокомфорт.

Практически сразу после запуска наши пользователи стали задавать вопросы о возможности подключении к сервису более дешевых камер других производителей.

Вариант с реализацией слоя интеграции под каждого вендора я отбросил практически сразу — как плохо масштабируемый и предъявляющий к железу камеры серьезные технические требования. Стоимость камеры, удовлетворяющий таким требованиям на входе:

Поэтому, я принял решение копать глубже — сделать полностью свою прошивку для камер любых вендоров. Этот подход существенно снижает требования к аппаратным ресурсам камеры — т.к. слой работы с облаком на порядок более эффективно интегрирован с video application, и в прошивке нет лишнего не используемого жирка.

И что важно, при работе с камерой на низком уровне есть возможность использовать аппаратный AES, который шифрует данные, не создавая дополнительной нагрузки на маломощный CPU.


В тот момент у нас не было вообще ничего. Вообще ничего.

Практически все вендоры не были готовы работать с нами на таком низком уровне. Информации о схемотехнике и компонентах — нет, официальных SDK чипсетов и документации сенсоров — нет.
Технической поддержки так же нет.

Ответы на все вопросы приходилось получать реверс инжинирингом — методом проб и ошибок. Но мы справились.

Первыми моделями камер, на которых мы набивали шишки стали камеры Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link и несколько сверх дешевых безымянных китайских камер.

Камеры на чипсете Hisilicon 3518E. Аппаратные характеристики камер такие:


Xiaomi Yi Ants Noname
SoC Hisilicon 3518E Hisilicon 3518E
RAM 64MB 64MB
FLASH 16MB 8MB
WiFi mt7601/bcm43143 -
Sensor ov9732 (720p) ov9712 (720p)
Ethernet - +
MicroSD + +
Microphone + +
Speaker + +
IRLed + +
IRCut + +

С них мы начинали.

Сейчас поддерживаем чипсеты Hisilicon 3516/3518, а так же Ambarella S2L/S2LM. Количество моделей камер — десятки.

uboot

uboot — это начальный загрузчик, после включения питания загружается первым, инициализирует оборудование и загружает ядро linux.

Скрипт загрузки камеры достаточно тривиален:

Из особенностей — два раза вызывается bootm , подробнее об этом чуть позже, когда дойдем до подсистемы обновления.

Обратите внимание на строчку mem=38M . Да, да, это не опечатка — ядру Linux и всем-всем-всем приложениям доступно всего лишь 38 мегабайт оперативной памяти.

Так же рядом с uboot находится специальный блок, называемый reg_info , в котором находится низкоуровневый скрипт инициализации DDR и ряда системных регистров SoC. Содержимое reg_info зависит от модели камеры, и если оно будет не корректным, то камера даже не сможет загрузить uboot, а зависнет на самом раннем этапе загрузки.

Первое время, когда мы работали без поддержки вендоров, мы просто копировали этот блок из оригинальной прошивки камеры.

Ядро linux и rootfs

На камерах используется ядро Linux, входящее в состав SDK чипа, обычно это не самые свежие ядра из ветки 3.x, поэтому часто приходится сталкиваться с тем, что драйвера дополнительного оборудования не совместимы с используемым ядром, и нам приходится их бэк-портировать под ядро камеры.

Другая проблема — это размер ядра. Когда размер FLASH всего 8MB, то каждый байт на счет и наша задача — аккуратно отключить все не используемые функции ядра, что бы сократить размер до минимума.

Rootfs — это базовая файловая система. В нее включены busybox , драйвера wifi модуля, набор стандартных системных библиотек, типа libld и libc , а так же ПО нашей разработки, отвечающее за логику управления светодиодами, управление сетевыми подключениями и за обновление прошивки.

Корневая файловая система подключена к ядру как initramfs и в результате сборки мы получаем один файл uImage , в котором есть и ядро и rootfs.

Video application

Наиболее сложная и ресурсоемкая часть прошивки — приложение, которое обеспечивает видео-аудио захват, кодирование видео, настраивает параметры картинки, реализует видео-аналитики, например, детекторы движения или звука, управляет PTZ и отвечает за переключения дневного и ночного режимов.

Важная, я бы даже сказал ключевая особенность — каким образом видео приложение взаимодействует с облачным плагином.

В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это огромный оверхед: копирование и передача данных через socket, лишние syscall-ы.

Мы в этом месте используем механизм shared memory — видео не копируется и не пересылается через socket между компонентами ПО камеры, тем самым оптимально и бережно используя скромные аппаратные возможности камеры.


Подсистема обновления

Предмет отдельной гордости — подсистема fault-tolerant онлайн обновления прошивки.

Поясню проблематику. Обновление прошивки — это технически не атомарная операция и в случае если посередине обновления произойдет сбой питания, то на флеш памяти будет часть "недозаписанной" новой прошивки. Если не предпринять специальных мер, то камера после этого станет "кирпичом", который нужно нести в сервисный центр.

Мы справились и с этой проблемой. Даже если камеру выключить в момент обновления, она автоматически и без участия пользователя скачает прошивку из облака и восстановит работу.

Разберем технику подробнее:

Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой. В случае, если один из этих компонентов окажется поврежденным, то камера вообще не загрузиться дальше начального загрузчика uboot, который не умеет скачивать прошивку из облака.

Значит, нам нужно обеспечить гарантию наличия на камере работоспособного ядра и rootfs в любой момент процесса обновления. Казалось бы самым простым решением было бы постоянно хранить на флеш памяти две копии ядра с rootfs и в случае повреждения основного ядра загружать его из резервной копии.

Годное решение — однако, ядро с rootfs занимает около 3.5MB и для постоянной резервной копии нужно выделить 3.5MB. На самых дешевых камерах просто нет столько свободного места под backup ядра.

Поэтому для backup ядра во время обновления прошивки используем application партицию.
А для выбора нужной партиции с ядром как раз и используется две команды bootm в uboot — в начале пытаемся загрузить основное ядро и если оно повреждено, то резервное.


Это гарантирует, что в любой момент времени на камере будет корректное ядро с rootfs, и она сможет загрузиться и восстановить прошивку.

CI/CD система сборки и деплоя прошивок

Для сборки прошивок мы используем gitlab CI, в котором автоматически собираются прошивки под все поддерживаемые модели камер, после сборки прошивки автоматически деплоятся на сервис обновления ПО камер.


Из сервиса обновления ПО прошивки доставляются на тестовые камеры наших QA, а по завершению всех этапов тестирования и на камеры пользователей.

Информационная безопасность

Ни для кого не секрет, что в наше время информационная безопасность — это важнейший аспект любого IoT устройства, в том числе и камеры. По интернету гуляют ботнеты типа Mirai, поражающие миллионы камер со стандартными прошивками от вендоров. При всем уважении к вендорам камер, не могу не отметить, что в стандартных прошивках заложено много функционала, который не востребован для работы с облаком, однако содержит в себе много уязвимостей, которыми пользуются ботнеты.

Поэтому, весь не используемый функционал в нашей прошивке отключен, все tcp/udp порты закрыты и при обновлении прошивки проверяется цифровая подпись ПО.

И кроме этого, прошивка проходит регулярное тестирование в лаборатории информационной безопасности.

Сейчас наша прошивка активно используется в проектах по видеонаблюдению. Пожалуй самый масштабный из них — трансляция голосования в день выборов Президента Российской Федерации.
В проекте было задействовано более 70 тысяч камер с нашей прошивкой, которые были установлены по избирательным участкам нашей страны.

Решив ряд сложных, а местами, даже на тот момент практически невозможных задач, мы, конечно, получили огромное удовлетворение как инженеры, но кроме этого, и сэкономили миллионы долларов на закупке камер. И в данном случае, экономия — это не только слова и теоретические расчёты, а результаты уже случившегося тендера на закупку оборудования. Соответственно, если говорить про облачное видеонаблюдение: есть два подхода — стратегически заложиться на низкоуровневую экспертизу и разработку, получив на выходе огромную экономию на оборудовании или использовать дорогое оборудование, которое, если смотреть именно на потребительские характеристики, практически ничем не отличается от аналогичного дешевого.

Почему стратегически важно принять решение относительно выбора подхода к способу интеграции как можно раньше? При разработке плагина, разработчики закладываются на те или иные технологии (библиотеки, протоколы, стандарты). И если выбран набор технологий только под дорогое оборудование, то в дальнейшем попытка перехода на дешевые камеры с большой вероятностью, как минимум, займет безумно большое время или вообще потерпит неудачу и произойдет возврат к дорогому оборудованию.






загрузить и установить iVMS 4.5 PRO NOVIcam на вашем персональном компьютере и Mac

Проверить совместимые приложения для ПК или альтернативы

Или следуйте инструкциям ниже для использования на ПК

Если вы хотите установить и использовать iVMS 4.5 PRO NOVIcam на вашем ПК или Mac, вам нужно будет загрузить и установить эмулятор Desktop App для своего компьютера. Мы усердно работали, чтобы помочь вам понять, как использовать app для вашего компьютера в 4 простых шагах ниже:

Шаг 1: Загрузите эмулятор Android для ПК и Mac

Хорошо. Прежде всего. Если вы хотите использовать приложение на своем компьютере, сначала посетите магазин Mac или Windows AppStore и найдите либо приложение Bluestacks, либо Приложение Nox . Большинство учебных пособий в Интернете рекомендуют приложение Bluestacks, и у меня может возникнуть соблазн рекомендовать его, потому что вы с большей вероятностью сможете легко найти решения в Интернете, если у вас возникнут проблемы с использованием приложения Bluestacks на вашем компьютере. Вы можете загрузить программное обеспечение Bluestacks Pc или Mac here .

Шаг 2: установите эмулятор на ПК или Mac

Теперь, когда вы загрузили эмулятор по вашему выбору, перейдите в папку «Загрузка» на вашем компьютере, чтобы найти приложение эмулятора или Bluestacks.
Как только вы его нашли, щелкните его, чтобы установить приложение или exe на компьютер или компьютер Mac.
Теперь нажмите «Далее», чтобы принять лицензионное соглашение.
Чтобы правильно установить приложение, следуйте инструкциям на экране.
Если вы правильно это сделаете, приложение Emulator будет успешно установлено.

Шаг 3: iVMS 4.5 PRO NOVIcam для ПК - Windows 7/8 / 8.1 / 10/ 11

Теперь откройте приложение Emulator, которое вы установили, и найдите его панель поиска. Найдя его, введите iVMS 4.5 PRO NOVIcam в строке поиска и нажмите «Поиск». Нажмите на iVMS 4.5 PRO NOVIcamзначок приложения. Окно iVMS 4.5 PRO NOVIcam в Play Маркете или магазине приложений, и он отобразит Store в вашем приложении эмулятора. Теперь нажмите кнопку «Установить» и, например, на устройстве iPhone или Android, ваше приложение начнет загрузку. Теперь мы все закончили.
Вы увидите значок под названием «Все приложения».
Нажмите на нее, и она перенесет вас на страницу, содержащую все установленные вами приложения.
Вы должны увидеть . Нажмите на нее и начните использовать приложение.

Шаг 4: iVMS 4.5 PRO NOVIcam для Mac OS

Привет. Пользователь Mac!
Шаги по использованию iVMS 4.5 PRO NOVIcam для Mac точно такие же, как для ОС Windows выше. Все, что вам нужно сделать, это установить Nox Application Emulator или Bluestack на вашем Macintosh. Вы можете получить Это здесь .

Наверное, ни для кого не секрет, что в последнее время облачные сервисы видеонаблюдения набирают популярность. И понятно почему так происходит, видео — это "тяжелый" контент, для хранения которого необходима инфраструктура и большие объемы дискового хранилища. Использование локальной системы видеонаблюдения требует средств на эксплуатацию и поддержку, как в случае организации, использующей сотни камер наблюдения, так и в случае индивидуального пользователя с несколькими камерами.


Облачные системы видеонаблюдения решают эту задачу — предоставляя клиентам уже существующую инфраструктуру хранения и обработки видео. Клиенту облачного видеонаблюдения достаточно просто подключить камеру к интернету и привязать к своему аккаунту в облаке.

Есть несколько технологических способов подключения камер к облаку. Бесспорно, наиболее удобный и дешевый способ — камера напрямую подключается и работает с облаком, без участия дополнительного оборудования типа сервера или регистратора.

Для этого необходимо, чтобы на камере был установлен модуль ПО работающий с облаком. Однако, если говорить про дешевые камеры, то у них очень ограничены аппаратные ресурсы, которые почти на 100% занимает родная прошивка вендора камеры, а ресурсов необходимых для облачного плагина — нет. Этой проблеме разработчики из ivideon посвятили статью, в которой говорится почему они не могут установить плагин на дешевые камеры. Как итог, минимальная цена камеры — 5000р ($80 долларов) и миллионы потраченных денег на оборудование.

Мы эту проблему успешно решили. Если интересно как — велком под кат

В 2016 году мы стартовали разработку платформы облачного видеонаблюдения для Ростелекома.

В части ПО камер на первом этапе пошли "стандартным" для таких задач путем: разработали свой плагин, который устанавливается в штатную прошивку камеры вендора и работает с нашим облаком. Однако, стоит отметить, что при проектировании мы использовали наиболее легковесные и эффективные решения (например, plain C реализацию protobuf, libev, mbedtls и полностью отказались от удобных, но тяжелых библиотек типа boost)

Сейчас на рынке IP камер нет универсальных решений по интеграции: у каждого вендора свой способ установки плагина, свой набор API для работы прошивки и уникальный механизм обновления.

Это означает, что для каждого вендора камер необходимо индивидуально разрабатывать объемный слой интеграционного ПО. И на момент старта разработки целесообразно работать только с 1-ним вендором, что бы сосредоточить усилия команды на разработке логики работы с облаком.

Первым вендором был выбран Hikvision — один из мировых лидеров на рынке камер, предоставляющий хорошо документированное API и грамотную инженерную техническую поддержку.

На камерах Hikvision мы и запустили наш первый пилотный проект облачное видеонаблюдение Видеокомфорт.

Практически сразу после запуска наши пользователи стали задавать вопросы о возможности подключении к сервису более дешевых камер других производителей.

Вариант с реализацией слоя интеграции под каждого вендора я отбросил практически сразу — как плохо масштабируемый и предъявляющий к железу камеры серьезные технические требования. Стоимость камеры, удовлетворяющий таким требованиям на входе:

Поэтому, я принял решение копать глубже — сделать полностью свою прошивку для камер любых вендоров. Этот подход существенно снижает требования к аппаратным ресурсам камеры — т.к. слой работы с облаком на порядок более эффективно интегрирован с video application, и в прошивке нет лишнего не используемого жирка.

И что важно, при работе с камерой на низком уровне есть возможность использовать аппаратный AES, который шифрует данные, не создавая дополнительной нагрузки на маломощный CPU.


В тот момент у нас не было вообще ничего. Вообще ничего.

Практически все вендоры не были готовы работать с нами на таком низком уровне. Информации о схемотехнике и компонентах — нет, официальных SDK чипсетов и документации сенсоров — нет.
Технической поддержки так же нет.

Ответы на все вопросы приходилось получать реверс инжинирингом — методом проб и ошибок. Но мы справились.

Первыми моделями камер, на которых мы набивали шишки стали камеры Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link и несколько сверх дешевых безымянных китайских камер.

Камеры на чипсете Hisilicon 3518E. Аппаратные характеристики камер такие:


Xiaomi Yi Ants Noname
SoC Hisilicon 3518E Hisilicon 3518E
RAM 64MB 64MB
FLASH 16MB 8MB
WiFi mt7601/bcm43143 -
Sensor ov9732 (720p) ov9712 (720p)
Ethernet - +
MicroSD + +
Microphone + +
Speaker + +
IRLed + +
IRCut + +

С них мы начинали.

Сейчас поддерживаем чипсеты Hisilicon 3516/3518, а так же Ambarella S2L/S2LM. Количество моделей камер — десятки.

uboot

uboot — это начальный загрузчик, после включения питания загружается первым, инициализирует оборудование и загружает ядро linux.

Скрипт загрузки камеры достаточно тривиален:

Из особенностей — два раза вызывается bootm , подробнее об этом чуть позже, когда дойдем до подсистемы обновления.

Обратите внимание на строчку mem=38M . Да, да, это не опечатка — ядру Linux и всем-всем-всем приложениям доступно всего лишь 38 мегабайт оперативной памяти.

Так же рядом с uboot находится специальный блок, называемый reg_info , в котором находится низкоуровневый скрипт инициализации DDR и ряда системных регистров SoC. Содержимое reg_info зависит от модели камеры, и если оно будет не корректным, то камера даже не сможет загрузить uboot, а зависнет на самом раннем этапе загрузки.

Первое время, когда мы работали без поддержки вендоров, мы просто копировали этот блок из оригинальной прошивки камеры.

Ядро linux и rootfs

На камерах используется ядро Linux, входящее в состав SDK чипа, обычно это не самые свежие ядра из ветки 3.x, поэтому часто приходится сталкиваться с тем, что драйвера дополнительного оборудования не совместимы с используемым ядром, и нам приходится их бэк-портировать под ядро камеры.

Другая проблема — это размер ядра. Когда размер FLASH всего 8MB, то каждый байт на счет и наша задача — аккуратно отключить все не используемые функции ядра, что бы сократить размер до минимума.

Rootfs — это базовая файловая система. В нее включены busybox , драйвера wifi модуля, набор стандартных системных библиотек, типа libld и libc , а так же ПО нашей разработки, отвечающее за логику управления светодиодами, управление сетевыми подключениями и за обновление прошивки.

Корневая файловая система подключена к ядру как initramfs и в результате сборки мы получаем один файл uImage , в котором есть и ядро и rootfs.

Video application

Наиболее сложная и ресурсоемкая часть прошивки — приложение, которое обеспечивает видео-аудио захват, кодирование видео, настраивает параметры картинки, реализует видео-аналитики, например, детекторы движения или звука, управляет PTZ и отвечает за переключения дневного и ночного режимов.

Важная, я бы даже сказал ключевая особенность — каким образом видео приложение взаимодействует с облачным плагином.

В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это огромный оверхед: копирование и передача данных через socket, лишние syscall-ы.

Мы в этом месте используем механизм shared memory — видео не копируется и не пересылается через socket между компонентами ПО камеры, тем самым оптимально и бережно используя скромные аппаратные возможности камеры.


Подсистема обновления

Предмет отдельной гордости — подсистема fault-tolerant онлайн обновления прошивки.

Поясню проблематику. Обновление прошивки — это технически не атомарная операция и в случае если посередине обновления произойдет сбой питания, то на флеш памяти будет часть "недозаписанной" новой прошивки. Если не предпринять специальных мер, то камера после этого станет "кирпичом", который нужно нести в сервисный центр.

Мы справились и с этой проблемой. Даже если камеру выключить в момент обновления, она автоматически и без участия пользователя скачает прошивку из облака и восстановит работу.

Разберем технику подробнее:

Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой. В случае, если один из этих компонентов окажется поврежденным, то камера вообще не загрузиться дальше начального загрузчика uboot, который не умеет скачивать прошивку из облака.

Значит, нам нужно обеспечить гарантию наличия на камере работоспособного ядра и rootfs в любой момент процесса обновления. Казалось бы самым простым решением было бы постоянно хранить на флеш памяти две копии ядра с rootfs и в случае повреждения основного ядра загружать его из резервной копии.

Годное решение — однако, ядро с rootfs занимает около 3.5MB и для постоянной резервной копии нужно выделить 3.5MB. На самых дешевых камерах просто нет столько свободного места под backup ядра.

Поэтому для backup ядра во время обновления прошивки используем application партицию.
А для выбора нужной партиции с ядром как раз и используется две команды bootm в uboot — в начале пытаемся загрузить основное ядро и если оно повреждено, то резервное.


Это гарантирует, что в любой момент времени на камере будет корректное ядро с rootfs, и она сможет загрузиться и восстановить прошивку.

CI/CD система сборки и деплоя прошивок

Для сборки прошивок мы используем gitlab CI, в котором автоматически собираются прошивки под все поддерживаемые модели камер, после сборки прошивки автоматически деплоятся на сервис обновления ПО камер.


Из сервиса обновления ПО прошивки доставляются на тестовые камеры наших QA, а по завершению всех этапов тестирования и на камеры пользователей.

Информационная безопасность

Ни для кого не секрет, что в наше время информационная безопасность — это важнейший аспект любого IoT устройства, в том числе и камеры. По интернету гуляют ботнеты типа Mirai, поражающие миллионы камер со стандартными прошивками от вендоров. При всем уважении к вендорам камер, не могу не отметить, что в стандартных прошивках заложено много функционала, который не востребован для работы с облаком, однако содержит в себе много уязвимостей, которыми пользуются ботнеты.

Поэтому, весь не используемый функционал в нашей прошивке отключен, все tcp/udp порты закрыты и при обновлении прошивки проверяется цифровая подпись ПО.

И кроме этого, прошивка проходит регулярное тестирование в лаборатории информационной безопасности.

Сейчас наша прошивка активно используется в проектах по видеонаблюдению. Пожалуй самый масштабный из них — трансляция голосования в день выборов Президента Российской Федерации.
В проекте было задействовано более 70 тысяч камер с нашей прошивкой, которые были установлены по избирательным участкам нашей страны.

Решив ряд сложных, а местами, даже на тот момент практически невозможных задач, мы, конечно, получили огромное удовлетворение как инженеры, но кроме этого, и сэкономили миллионы долларов на закупке камер. И в данном случае, экономия — это не только слова и теоретические расчёты, а результаты уже случившегося тендера на закупку оборудования. Соответственно, если говорить про облачное видеонаблюдение: есть два подхода — стратегически заложиться на низкоуровневую экспертизу и разработку, получив на выходе огромную экономию на оборудовании или использовать дорогое оборудование, которое, если смотреть именно на потребительские характеристики, практически ничем не отличается от аналогичного дешевого.

Почему стратегически важно принять решение относительно выбора подхода к способу интеграции как можно раньше? При разработке плагина, разработчики закладываются на те или иные технологии (библиотеки, протоколы, стандарты). И если выбран набор технологий только под дорогое оборудование, то в дальнейшем попытка перехода на дешевые камеры с большой вероятностью, как минимум, займет безумно большое время или вообще потерпит неудачу и произойдет возврат к дорогому оборудованию.

Читайте также: