Как прошить камеру видеонаблюдения wi fi
Как обновить прошивку видеокамер с функцией управления PTZ?
Часто при обновлении прошивки IP-видеокамер, имеющих функции PTZ (Pan-tilt-zoom), то есть управления поворотами камеры и увеличения изображения, прошивка камеры обновляется, а PTZ — нет.
Дело в том, что производитель большинства модулей для подобных видеокамер компания XM xiongmaitech не публикует прошивки с поддержкой PTZ на своих официальных ресурсах, хотя там и доступны обычные прошивки. Причем ID firmware прошивок идентичны, поэтому обновление PTZ все же возможно.
Прошивки с функцией PTZ делают для OEM продавцов, которые редко публикуют свои версии.
Но все же есть несколько способов получения прошивки
- Можно обратиться за поддержкой к продавцу камеры.
- На профильных форумах часто делятся доступными версиями прошивок.
- Получение бекапа прошивки из рабочего экземпляра камеры
- Воспользоваться этим архивом, в котором собраны версии прошивок из доступных источников.
Для получения бекапа прошивки лучше всего воспользоваться программой XM Device Explorer Free. Ее можно скачать здесь.
1. Создание резервной копии (дампа) устройства
2. Восстановление работоспособности камеры/регистратора из созданного дампа
3. Восстановление работоспособности устройства с помощью файла прошивки
4. Стирание настроек/сброс пароля.
Данное ПО может самостоятельно выбрать доступный COM порт к которому подключен USB TTL адаптер, или вы можете указать его выбрав из списка доступных. Жмем кнопку Открыть>
Программа предлагает включить питание камеры для остановки загрузки и выполнения команд U-Boot
Поставив галочку напротив пункта Режим отладки> получаем возможность просмотра лога выполнения команд. В нижней части появившегося окна доступно поле ручного ввода команд для выполнения. Далее нажав кнопку Определить> можно вывести карту разбивки файловой системы ПЗУ (флеш памяти)
Кнопкой Прошивка> возможно выбрать и загрузить прошивку в ваше устройство, для создания резервной копии текущего содержимого ПЗУ предназначена кнопка Дамп>.
Создание резервной копии настоятельно рекомендуется разработчиками, так как программа позволяет выполнить изменения после которых работа устройства будет нарушена.
Для этого нужно перейти во вкладку TFTP> включить сервер, вернуться на вкладку COM> и нажать кнопку Дамп>. После чего выбрать каталог сохранения и задать имя файла для текущего дампа.
Кнопка поможет загрузить дамп из ранее созданной резервной копии, для сброса пароля или очистки конфигурации можно воспользоваться кнопкой Очистить MTD>
С бекапом разобрались, теперь перейдет собственно к обновлению прошивки PTZ.
Дл этого нужно сперва выяснить какая именно прошивка необходима для вашей PTZ камеры, сделать это просто, посмотрите версию в мобильном приложении.
Выяснив версию прошивки PTZ которая вам необходима, зайдите в соответствующий каталог в этом архиве.
Остается только скачать нужную прошивку и выполнить ее обновление, используя стандартные методы прошивки.
p4GcRGuXFmeV4ZWTYHVAt18A2 2021-02-12T17:12:13+03:00 10, Ноябрь, 2020 | Настройка видеонаблюдения | Комментарии к записи Как обновить прошивку видеокамер с функцией управления PTZ? отключены
Компания Ростелеком активно осваивает рынок видеонаблюдения предлагая видеокамеры ведущих производителей с собственной версией программного обеспечения. При покупке оборудования существует период в течении которого доступ к сервису происходит условно бесплатно, по окончании этого периода вам необходимо выбрать один из предложенных тарифов . Стоимость тарифов — от 350 рублей в месяц, сумма не большая но оригинальные камеры от производителя имеют неплохой набор сервисных функций, как говорится прямо из коробки. В результате у пользователя возникает вопрос, можно ли выполнить Восстановление оригинальной прошивки после ростелекома.
Компания в качестве доноров использует оборудование различных брендов, наибольшее распространение получили марки Hikvision и Dahua
IP камеры из линейки Hikvision
IP камеры из линейки Dahua
Способы восстановления для разных брендов различны и в то же время схожи в том, что необходимо использовать служебные разъемы в камерах для подключения к UART интерфейсу с использованием сервера TFTP.
Подробнее о прошивке с использованием сервера TFTP можно прочитать в другой нашей статье, Восстановление прошивки Hikvision
Далее рассмотрим как выполнить Восстановление оригинальной прошивки после ростелекома на примере оборудования Hikvision
Наибольшее распространение получила линейка оборудования Hikvision, основанная на серии прошивок R2, так как прошло достаточное время с момента старта продаж и как правило льготный период использования сервисом уже окончен, эти камеры можно найти на вторичном рынке за смешные деньги.
Первые версии программного обеспечения от Ростелекома использовали практически оригинальный загрузчик и дескриптор устройства компании Hikvision с единственным ограничением, длинна файла оригинальной прошивки не позволяла выполнить обновление и процесс прерывался с ошибкой превышения длинны файла digicap.dav.
Файл digicap.dav имеет несколько степеней защиты от редактирования, но сообщество любителей бренда Hikvision располагает утилитами способными обойти эти барьеры.
Предлагаю инструкцию взятую из сети:
Вам понадобится инструменты (скачать и распаковать):
- HikTools — утилита для разборки и сборки прошивки.
- HikVision TFTP Server — утилита для восстановления прошивок камер HikVision/HiWatch
- HyperTerminal — утилита для связи через последовательный порт
- NewTuxBoxFlashTools — утилита для правки образов CRAMFS
- SADP — утилита для поиска, активации и конфигурирования сетевых параметров камер HikVision/HiWatch.
- С FTP-сервера HikVision скачиваем архив с оригинальной прошивкой. Распаковываем. Нас интересует файл digicap.dav .
- Копируем файл в папку HikTools и запускаем файл cmd_split.cmd . В папке появляется подраздел dav , в котором лежит содержимое прошивки.
- Запускаем утилиту NewTuxBoxFlashTools и открываем в ней файл app.img из подраздела dav . Интерфейс на немецком, но понять где что несложно по иконкам. Ищем в содержимом образа файл WebComponents.exe и удаляем его, сохраняем изменения. При сохранении ругнётся — это нормально.
- Запускаем файл cmd_create.cmd и получаем новую прошивку — файл с именем dav.dav .
- Удаляем старый файл digicap.dav и переименовываем файл dav.dav в digicap.dav . Получили прошивку меньшего размера.
В камеры HikVision/HiWatch заложен механизм восстановления прошивки при критических сбоях. Каждый раз, при запуске, камера получает фиксированный адрес 192.0.0.64 (или 192.168.1.64 и в течение нескольких секунд ищет TFTP-сервер по адресу 192.0.0.128 или 192.168.1.128, соответственно. Найдя его, скачивает прошивку, и прошивается.
- Задаём сетевой карте компьютера адрес 192.0.0.128/255.255.255.0 и дополнительный адрес 192.168.1.128/255.255.255.0, чтобы не проверять из какой партии камера и сделать всё за одну попытку.
- Копируем резаную прошивку в папку сервера TFTP и запускаем сервер.
- Подключаем камеру к сети и включаем питание. Наблюдаем за логом TFTP-сервера. Как только напишет, что прошивка скачана нужно его закрыть. Иначе, камера прошьётся, перезагрузится, при загрузке начнёт искать TFTP-сервер — найдёт, скачает прошивку, прошьётся, перезагрузится и так по кругу.
- Контролируем запуск камеры в рабочее состояние через SADP. Появилась в списке — значит загрузилась. Камера прошита.
- Теперь нужно сбросить пароль путём возврата к заводским установкам. Выключаем питание камеры, зажимаем кнопку RESET, подаём питание и держим кнопку нажатой 10-15 секунд. Отпускаем RESET.
- Контролируем запуск камеры через SADP. Если сброс произошёл — камера получит адрес по умолчанию — 192.0.0.64 или 192.168..1.64 и перейдёт в неактивное состояние (Inactive). Можно задавать пароль, настраивать и пользоваться. Как говорится — Enjoy!
Заранее подготовленный файл с прошивкой и TFTP сервером можно скачать в нашем файловом архиве
Подробнее о прошивке с использованием сервера TFTP можно прочитать в нашей другой статье, Восстановление прошивки Hikvision
Восстановление оригинальной прошивки после ростелекома камер Ростелеком CS-C2SHW и Ростелеком-DS-2CD-VC1W имеет некоторые нюансы:
Как обновить прошивку IP камер и видеорегистраторов?
IP камеры представляют из себя достаточно сложное устройство, управляемой микропрограммой. Как и в любых программах, она может содержать ошибки или уязвимости, которыми могут воспользоваться злоумышленники. Для устранения таких ошибок, а также для добавления новых функций, производитель выпускает обновления прошивок, которые можно самостоятельно установить.
При этом нужно правильно подготовиться к проведению обновления прошивки, иначе могут возникнуть серьезные проблемы. Для этого:
- Перед обновлением прошивки убедитесь, что файлы обновления и модель устройства совместимы.
- Если Вы не уверены, обратитесь в службу технической поддержки.
- Нельзя выключать питание и интернет кабель во время обновления.
- Нельзя обновлять устройство прошивками сторонних производителей.
- Обновление прошивки может привести выходу из строя оборудования, так что позаботьтесь о резервном устройстве.
Также для обновления прошивки потребуется узнать её версию и дату.
Для этого с помощью программы для видеонаблюдения, которую вы используете, подключаетесь к камере или регистратору, откройте свойства и зайдите в настройки (Device config):
Там выбираете «Информация» -> «Версия» (Setting->Info->Version). Нас интересует Версия системы (System) — это цифры, обведённые красным. Первые три цифры определяют конкретного сборщика оборудования (Вендора), а оставшиеся пять — это и есть версия прошивки.
При скачивании прошивки нужно выбирать файл с теми же цифрами. Дата прошивки (Build Date) означает дату её выпуска, по этим данным можно ориентироваться, на сколько старое ПО установлено в камере.
Для установки скачанной прошивки нужно зайти в пункт «Обновление» (Upgrade)
Выбрать пункт «Директория» (Browse), выбрать файл новой прошивки и нажать кнопку «Обновить» (Upgrade). После чего начнётся сам процесс обновления.
Обычно это занимает около минуты, после чего ещё одну минуту камера перезагружается. В конце обновление должна появиться табличка «Обновление успешно». Поздравляю, ваша камера/регистратор теперь имеют свежую программу.
Если появилась табличка «Обновление неудачно», скорее всего вы пытались установить неподходящую прошивку, ещё раз проверьте версию из пункта «Версия» и скачанной прошивки. Ещё такое может произойти, если вы пытаетесь обновить оборудование от другого производителя (первые три цифры отличаются от 000).
В некоторых случаях, производители защищают подмену ПО в своих продуктах, указывая в настройках прошивки дополнительный пункт Vendor, тогда обычные версии (General) ПО уже не могут быть установлены без правки InstallDesc. Тогда остается лишь обратиться в техподдержку фирмы-производителя вашего оборудования.
Главное, помните, обновление прошивки производится на свой страх и риск, и не является гарантийным случаем.
Так как у разного оборудования от разных производителей свои программы для видеонаблюдения, то обновлении прошивки может несколько отличаться. В любом случае подготовка к обновлению должна проводиться следующим образом:
1. Ваш ПК и устройство при обновлении должны находится в одной локальной сети.
2. Перед обновлением, устройство необходимо перезагрузить, программно или аппаратно.
3. Путь к файлу обновления не должен содержать русских букв и не должен быть слишком длинным.
C:\Users\stefan\Documents\прошивка для камеры
4. Запишите текущую версию вашего устройства перед обновлением для понимания изменилась ли версия после обновления. Если обновление пройдет некорректно техподдержка запросит у вас версию которая была до обновления.
5. После успешного обновления переустановите плагин для корректной работы в WEB интерфейсе.
Также помните, что нельзя перед обновлением экспортировать настройки и после обновления импортировать обратно на устройство, т.к. может возникнуть конфликт конфигурации из за смены версий и сбои в работе устройства.
После обновления прошивки видеорегистратора, обязательно сбросьте регистратор к заводским установкам, перезагрузите его через интерфейс GUI дважды. Это важно. Затем обязательно измените пароли и порты по умолчанию в целях безопасности.
Существует несколько способов обновления прошивки. Самый обычный и распространенный способ мы уже привели выше. Основные же способы обновления следуюшие:
1. Через веб интерфейс устройства
2. С помощью инструмента для обновления и поиска устройств в сети — ConfigTool
3. Обновление с помощью USB носителя (для видеорегистратора)
Обновление IP камеры через веб интерфейс доступен не каждой модели оборудования для видеонаблюдения. Старые модели камер и регистраторов до 2013 года не имеют интерфейс обновления через браузер.
Для обновления заходим в веб интерфейс устройства.
Укажите путь к файлу обновления, и нажмите Upgrade. Статус обновления можно наблюдать на веб странице, в среднем обновление занимает от 3 до 5 минут, после обновления устройство автоматически перезагрузится.
С помощью ConfigTool можно обновить любое устройство Dahua DVR, HCVR, XVR, NVR, IP камера.
Если все устройства в одной локальной сети, ConfigTool найдет их автоматически. Нажмите login для входа, затем перейдите на вкладку upgrade.
Обновление с помощью USB носителя (для видеорегистратора)
Скопируйте все файлы на usb носитель (в корень). Вставьте в регистратор USB носитель, зайдите в главное меню/Инфо/Версия. Нажмите Start для начала обновления, статус обновления можно наблюдать на экране.
В случае если регистратор отказывается принимать файл обновления с USB то переименуйте файл в update
После обновления прошивки переустановите плагин.
Заходим в C:\Program Files находим две папки : webplugin и webrec (возможно только одна папка)
Удаляем их затем переходим в C:\Program Files (x86) также удаляем webplugin, webrec.
Обе папки содержат компоненты плагина, к ОС Windows отношения не имеют.
Подключитесь к устройству через Internet Explorer, вам будет предложено скачать и установить плагин. Разрешите установку.
Вот пожалуй и все, что нужно знать об обновлении прошивки цифровых видеокамер и регистраторов.
p4GcRGuXFmeV4ZWTYHVAt18A2 2021-02-12T17:12:14+03:00 20, Октябрь, 2020 | Настройка видеонаблюдения | Комментарии к записи Как обновить прошивку IP камер и видеорегистраторов? отключены
Эта история началась больше года назад, когда в организацию были закуплены несколько относительно дешёвых китайских IP-камер Falcon Eye FE-MTR300 P2P, чтобы между сотрудниками и посетителями не происходило никаких эксцессов под присмотром большого брата.
Не сказать, чтобы всё было хорошо… Всё было средне. И нам показалось, что обновление ПО камер сможет что-то улучшить. Оказалось, что некоторые модели Falcon Eye, Tenvis, Foscam и, возможно, ещё каких-то фирм практически совпадают. Где-то кнопочки поудобнее, где-то интерфейс русский есть. И мы решились!
Обновили ПО камер на схожую модель от Tenvis TR3818. Потом почитали ещё и решили, что можно обновиться и на более крутую прошиву от другой камеры.
После обновления камера приказала долго жить. Проверки моторов при включении не происходило, динамики не шуршали, светодиод не мигал. Горел только светодиод на LAN интерфейсе, да при включении уходил одинокий широковещательный пакетик.
После такого казуса остальные камеры были развешаны по местам, а «кирпич» переселился жить к нам. Время от времени происходили попытки его реанимировать. Камера была разобрана, найдены площадки, куда можно подпаяться для доступа через консоль.
(там под проводами маркировка 3.3V, GND, TX, RX)
(платы камеры в сборе)
Пришлось взять USB-TTL преобразователь.
(есть контакт)
Подключаемся к консоли через putty или HyperTerminal и видим следующее:
U-Boot 1.1.3 (Aug 26 2014 - 17:15:00)
Board: Ralink APSoC DRAM: 16 MB
relocate_code Pointer at: 80fb0000
spi_wait_nsec: 42
spi device id: c2 20 17 c2 20 (2017c220)
find flash: MX25L6405D
raspi_read: from:2b000 len:1000
.raspi_read: from:2b000 len:1000
.============================================
Ralink UBoot Version: 3.6.0.0
--------------------------------------------
ASIC 5350_MP (Port5None)
DRAM_CONF_FROM: Boot-Strapping
DRAM_TYPE: SDRAM
DRAM_SIZE: 128 Mbits
DRAM_WIDTH: 16 bits
DRAM_TOTAL_WIDTH: 16 bits
TOTAL_MEMORY_SIZE: 16 MBytes
Flash component: 8 MBytes NOR Flash
Date:Aug 26 2014 Time:17:15:00
============================================
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:128, ways:4, linesz:32 ,total:16384
netboot_common, argc= 3
NetLoop,call eth_init !
Trying Eth0 (10/100-M)
Waitting for RX_DMA_BUSY status Start. done
Header Payload scatter function is Disable !!
ETH_STATE_ACTIVE!!
Using Eth0 (10/100-M) device
TFTP from server 51.204.51.204; our IP address is 192.168.1.5
Filename 'xx.img'.
TIMEOUT_COUNT=10,Load address: 0x80100000
Loading: ====================broadcast get file
T ====================broadcast get file
could not get file, cancel update
ret = 1
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
You choosed 3
0
Набравшись сил, мы совершили ещё один подход. Пришлось потратить нервы на то, чтобы понять, что именно в нашем случае RX преобразователя надо подключить к RX камеры, а TX к TX. Или маркировку неправильно нанесли или одно из двух. Камера начала реагировать на выбор пунктов меню, но это никак не объясняло природу магических чисел.
Тогда была скачана прошивка для Tenvis TR3818 и несколько прошивок для похожих камер, настроен tftp-сервер и выбран пункт номер 4, вход в командный интерфейс. Собственно, по ? нам выдаёт список возможных команд, где мы находим tftpboot — который загружает файл с tftp в память и bootm — который загружает приложение из памяти.
Порядок действий следующий:
- загружаем прошивку в камеру через tftpboot
- запускаем командой bootm
- Смотрим на результат, обдумываем.
И спасибо Вам! Если бы не желание порадовать хабр, возможно эта камера ещё долго бы стояла у нас в отделе.
Привет, меня зовут Олег Герасимов, я директор центра компетенций IT-кластера Ростелекома. Наша команда среди многих задач разрабатывает прошивки камер видеонаблюдения для B2B и B2C-сервисов. В предыдущей статье я рассказывал, как мы научились самостоятельно разрабатывать софт и прошивки для IP-камер, в том числе и недорогих, и подключать их к облаку.
За прошедшее время камеры с нашей прошивкой уже появились на рынке, и, судя по данным Яндекс.Маркета, — на полках магазинов цены на них начинаются от 1500 рублей. И это уже не дешевый «ноунэйм», а качественные камеры ведущих мировых брендов: Hikvision, Dahua и Uniview. На мой взгляд, это отличный результат!
Когда мы начинали работать с прошивками, количество поддерживаемых моделей камер было небольшим. В процессе разработки общих компонентов мы самостоятельно реализовывали поддержку новых моделей камер.
Тогда у нас была возможность самим выбирать, какие модели интегрировать в первую очередь, а какие нет, исходя из технических соображений.
Например, если в камере используется сенсор, под который в SDK процессора нет драйвера, то драйвер сенсора придется разработать самим. Это очень трудоемкий процесс, требующий сложной разработки и отладки. Сенсор — технически сложный компонент, и на одно изучение технического описания (Datasheet) сенсора могут уйти недели. Это, на секундочку, сотни страниц с описанием тысяч регистров, влияющих на работу сенсора, и логики взаимодействия с ними.
Первое время мы обходили стороной камеры с незнакомыми сенсорами, чтобы не застрять в деталях настройки конкретного железа, а сосредоточиться на разработке общих компонентов, которые будут использоваться в большинстве камер. Иногда нам удавалось найти уже готовые драйверы сенсора в оригинальной прошивке камеры, но это было скорее счастливым исключением из правил. Работая в таком режиме, мы поддержали около десятка моделей камер на нескольких наиболее популярных чипсетах, делая упор не на количество моделей, а на функциональность.
Следующий этап разработки прошивок для камер совпал с объявлением тендера на закупку камер. Это уже серьезное событие. Ростелеком закупал сотни тысяч камер на открытом тендере, в который могли войти любые вендоры камер, соответствующих по своим ТТХ продуктовым и техническим требованиям.
Одно из ключевых требований к поставщикам — предоставление технической информации о схемотехнике камер, например, о GPIO-выводах, к которым подключены светодиоды, кнопки, ИК фильтры и т.д. Кроме этой информации, мы просили вендоров предоставить специфичные для оборудования патчи ядра/загрузчика и исходные тексты драйверов устройств, в первую очередь, сенсоров и WI-FI чипов.
Такой подход существенно облегчил нашу задачу по поддержке новых камер. Вместо данных, добытых реверс-инжинирингом, у нас появились официальные спецификации и исходники драйверов от вендоров.
Однако по-прежнему много времени уходило на подготовку прошивок, даже когда вендоры стали делиться информацией: данные в спецификациях были неточными, драйверы не хотели заводиться на железе, а то и вовсе отказывались собираться.
Мы начали анализировать узкие места процесса. Они оказались на поверхности: больше всего времени уходило на итерации получения патчей и драйверов, багрепорты в сторону вендоров и ожидание исправлений.
Логичная мысль: дать вендорам возможность самим собирать нашу прошивку с драйверами их оборудования и конфигурациями, проверять результаты и отлаживать работу у себя, не тратя драгоценное время на переписку.
Техническое решение, с одной стороны, очевидное: сделать SDK для сборки нашей прошивки. Но есть ряд требований:
- SDK должен уметь собирать прошивки под все типы поддерживаемых SoC. На сегодня это больше 10 чипсетов от Hisilicon, Ambarella, MStar и Fullhan.
- Нельзя передавать компоненты прошивок от одного вендора другим, потому что это интеллектуальная собственность. Мы подписываем NDA, в котором обязуемся не раскрывать передаваемую информацию.
- Результаты интеграции, полученные от вендора, нужно уметь замерджить в общее дерево исходников прошивки в нашем Git.
- У вендора должна быть возможность вносить патчи и дополнения во все компоненты: ядро, загрузчик, SoC SDK и прочие.
- Нужно иметь гибкую структуру настроек, в которой будут учитываться максимальное количество возможных конфигураций оборудования.
- Для каждой пары «вендор-SoC» должна собираться универсальная прошивка, поддерживающая все камеры вендора на базе этого процессора.
- Сборка должна работать автономно и не требовать доступа в Интернет. Да, большинство разработчиков ПО для камер в Китае не имеют доступа в Интернет на рабочих местах.
Структура системы сборки, в тот момент, была не готова к такому подходу. Например, в некоторых файлах конфигурации были совмещены настройки камер от нескольких вендоров, а для сборки прошивки и загрузки пакетов требовался доступ к нашим внутренним репозиториям. Да и некоторые места системы сборки (чего греха таить) не предполагали такого масштабирования: их разработали в то время, когда поддерживался один тип процессора и две модели камеры.
Другая проблема: под каждый процессор поставляется отдельный SDK от его производителя, с уникальным набором системных компонентов: своя версия и набор патчей ядра, toolchain, uboot, системная библиотека (где-то uclibc, а может быть glibc). Под эти факторы приходится подстраивать систему сборки, а местами и код приложений. Для наглядности масштабов фрагментации вот табличка со списком версий компонентов:
Процессор | Версия Linux | Версия gcc |
---|---|---|
Hisilicon 3516a/d | 3.4.y | gcc 4.9 |
Hisilicon 3518ev100 | 3.0.y | gcc 4.4 |
Hisilicon 3518ev200 | 3.4.y | gcc 4.9 |
Hisilicon 3516cv300 | 3.18.y | gcc 4.9 |
Hisilicon 3518ev300/3516ev200/ev300 | 4.9.y | gcc 6.3 |
Hisilicon 3516cv500/dv300 | 4.9.y | gcc 6.3 |
mStar i3 | 3.18 | gcc 4.8 |
mStar i6 | 4.9 | gcc 8.2 |
Ambarella s2l | 3.10 | gcc 4.9 |
Ambarella s3l | 3.10 | gcc 5.2 |
Fullhan fh8632 | 3.0.y | gcc 4.3 |
Как видно, разброс огромный: от легаси десятилетней давности до относительно свежих ревизий.
С такими вводными нам предстоял рефакторинг системы сборки прошивок: выделить общие патчи и драйвера, которые будут доступны для всех вендоров, повторить это для 10+ поддерживаемых моделей SoC, полностью переосмыслить систему конфигурации наших компонентов. Заодно выпилить специфичные для камер костыли из init-скриптов, сделав общие и универсальные решения.
В результате мы пришли к структуре, в которой все специфичные для конкретных моделей настройки/конфигурации/makefile/патчи собраны в папках, структурированную по иерархии "Вендор → SoC → Модель камеры". Такая иерархия позволила автоматизировать сборку SDK с разделением сборок по вендорам. Вот пример, драйверы и конфигурации для камер от выдуманного вендора Megatech на чипсете Hisilicon.
Все файлы конфигурации камер перевели в формат YAML, как самый удобный для ручного редактирования, и разделили по компонентам:
- Настройки оборудования модели камеры (GPIO, наличие и тип Wi-Fi, сенсора, флаги наличия микрофонов, динамиков, дополнительные скрипты инициализации).
- Настройки видеоприложения для конкретной модели (тип сенсора, поддерживаемые разрешения, режимы синхронизации и видеозахвата, подстройки алгоритмов).
- Настройки PTZ (тип чипа, тайминги работы шаговых драйверов).
Выбор способа сборки дистрибуции SDK был очевидным. Docker оказался вне конкуренции, с его помощью можно легко передать подготовленную среду.
Мы использовали Docker практически с самого начала разработки, как в CI, так и для локальной отладки на компьютерах разработчиков.
Процесс сборки полностью автоматизирован. Docker-образы с нашим SDK собираются в общем CI под матрицу сочетаний «SoC-вендор».
Исходно у нас было два основных репозитория:
- build-tools — в нем хранятся Dockerfile, скрипты установки SoC SDK и скрипты сборки общих библиотек для поддерживаемых аппаратных платформ. В CI этого репозитория собираются Docker-образы со всем необходимым для сборки прошивки и софта под целевую платформу.
- vc-firmware — здесь хранится система сборки прошивки и компонент. К этому же репозиторию как git-submodule подключены репозитории с исходниками наших компонентов: видеоприложение, облачный агент, модуль обновления). Результатом работы CI в этом репозитории являются сами прошивки камер.
Для нового SDK добавили еще один репозиторий, vc-sdk, к которому подключили vc-firmware и build-tools как git-submodule. В CI этого репозитория сборка разделена на этапы:
- подготовка базового Docker-образа по аналогии с репозиторием build-tools;
- сборка пакетов с компонентами (видеоприложение, облачный агент, модуль обновления);
- загрузка пакетов с общими компонентами (публичные библиотеки, драйверы Wi-Fi и т.д.)
- копирование каталогов с драйверами и патчами, специфичными для вендора
В результате работы CI получается автономный Docker-образ, рассчитанный на сборку прошивок для камер на выбранном чипе вендором. Он загружался
в общий registry образов, из которого вендор может скачать свой образ.
Заключение
За этот год уже 8 вендоров освоило использование нашего SDK, с его помощью добавили поддержку работы с видеонаблюдением Ростелекома в нескольких десятков новых моделей камер. Некоторые из этих камер уже продаются.
Важно, что выбранный подход — разработка собственной прошивки на базе SDK — работает на потребителей: интеграция камер таким способом позволила организовать честную конкуренцию при тендере на закупку камер. Победители выявляются по объективным показателям: качеству оборудования и наименьшей стоимости.
Наконец, если раньше количество поддерживаемых моделей камер было ограничено силами и ресурсами команды, то сегодня эта проблема ушла в прошлое. Теперь вендоры камер могут сами добавлять поддержку новых моделей через облако РТК.
Читайте также: