Статья про корпуса зашла неплохо, аудитория “Хабра” оказалась весьма приветливой, что и сподвигло меня на продолжение. На этот раз расскажу почему не стоит продавать продукт до релиза, почему “просто скопировать все у китайцев” — не работает, и зачем спрашивать о врожденных заболеваниях у разработчика, ответственного за профили цвета и баланс белого.
К сожалению, технических деталей в статье вы не увидите, так как NDA (и невысокая компетентность рассказчика), но, надеюсь, получится увлекательная притча.
Российское ПО: не роскошь, а необходимость
Сразу внесу ясность: отечественное ПО на отечественном оборудовании — не квасное патриотичное желание влезть без очереди в госзакупки по импортозамещению, а суровая насущная необходимость. Когда ты сам проектируешь платы и модули, какие-то опенсорсные или партнерские решения подходят все меньше и меньше, вплоть до неработоспособности.
Опять же, повторяя тезисы из прошлой статьи о корпусах — если вы вендор массмаркетного продукта, то и программного обеспечения под него полно, начиная от локализаций китайского ПО под конкретный видеомодуль, адаптаций свободного ПО, и заканчивая аутсорсно написанной прошивкой от сторонней команды. К тому же почти любой ОЕМ-производитель любезно добавит березки и кокошники в любых количествах в свою прошивку и назовет ее хоть “Кострома”, хоть “Финист”. Но если продукт уникальный, еще и с кучей опций — все это работать не будет. Тому есть несколько причин:
Необходимость постоянной синхронизации аппаратной и программной части, даже при небольших изменениях в одном или другом все перестает работать как надо;
Негибкость и закрытость готовых решений, они подходят для широкого ряда популярных видеомодулей, но не подразумевают возможность серьезных изменений под себя;
Низкие по качеству решения в том ПО, которое можно заказать у китайцев или даже отечественных аутсорсеров под свое оборудование — низкая надежность, проблемы с потоком и малый аптайм как лишь малая часть проблем в оборудовании, которое по определению должно быть беспроблемным. Сторонние разработчики не вовлекаются в суть предмета разработки.
Так что мысли о ПО «Рувер» появились почти сразу после того, как мы с коллегами сделали свою первую плату (это, кстати, была плата РоЕ).
Откуда пошла прошивка Русская
На берегу, почти 5 лет тому назад, создание собственной прошивки казалось чем-то простым: берем SDK от производителя процессора, накатываем какое-нибудь легковесное линуксовое ядро, прикручиваем простенькую веб-морду, все это дружим — и вуаля. Точнее даже так — сперва были взяты исходники уже рабочей прошивки у китайцев, и были попытки быстренько ее адаптировать.
В штат был нанят для реализации этого проекта целый (1 штука) программист из Москвы. Через полгода, когда он так и не раскурил что к чему, стало ясно что для одного человека это задача просто нереализуемая. У билдов перекомпилированной прошивки постоянно что-то отваливалось, крашилось, а Китайцы, в свою очередь, с лицом ехидной лягушки разводили руками и говорили что у них все работает, проблема со стороны лаоваев.
К тому времени начал собираться уже полноценный, но еще пока небольшой отдел разработки, частично на аутсорсе, частично из местных разработчиков в офисе. Все без исключения программисты имели огромный опыт во всем, кроме создания ПО для IP-камер. Тут, кстати, кроется одна из ключевых для нас проблем на российском рынке IT-кадров: веб-программистов невероятно много, любого уровня, хватает специалистов и в мобильной разработке, игрострое, финтехе. Но embedded-разработчиков для написания ПО даже под популярные SoC не сыскать ни на какие зарплаты — их попросту нет. В общем, пришлось растить (и приходится до сих пор) собственные кадры.
Начало было положено с SoC от Hisilicon — у них хороший, функциональный SDK, но с огромным количеством легаси-кода на Си, костылей, просто непонятных или устаревших решений. Разумеется, вся документация была на китайском, что отнюдь не добавляло простоты изучения.
В какой-то момент более опытные аутсорсеры дружно решили нас покинуть — проект для них оказался слишком сложным и оторванным от реальности, ради неясных профитов. И дело тут совсем не в оплате а даже наоборот: привыкнув работать за хорошие деньги в условиях обилия проектов, человек по понятным причинам не захочет заморачиваться с тем что ему сложно дается, да еще и ради целей которые он не разделяет. С другой стороны, команда разработчиков из Краснодара оказалась ближе к производству, к земле, к заразительному энтузиазму директора — почти все из них работают в компании до сих пор. Поэтому перед тем как покорять Эверест, убедитесь что ваша команда состоит из тех людей, кто хочет дойти до вершины, а не просто умеет лазать на пять с плюсом.
Оставшись у разбитого корыта, но приобретя реальный опыт в этом деле, было принято решение писать прошивку заново, теперь уже на C++, причем с самого начала придерживаясь полноценной архитектуры — прошлая прошивка работала на костыльно-велосипедной тяге совершеннейшим чудом.
Так родился Nexus
Конечно не планировалось останавливаться на этом названии, вообще вопрос с названиями как-то особенно не стоял. Были IP-камеры 360+1 от НИЦ “Технологии”, а прошивка, как само собой разумеющаяся, никак не называлась. Нексусом было названо ядро, но какой-то менеджер случайно услышал это, и решил что будет круто назвать так саму прошивку и продавать ее как киллер-фичу в наших камерах — отечественные камеры с отечественным ПО! Хотя, по сути, если не считать каких-то то инструментов, отечественным оно было все это время, но никого это особенно не волновало. До санкций с импортозамещением электроники было еще какое-то время, поэтому отечественное происхождение каких-либо профитов, кроме излишне навязчивого внимания государственных учреждений, не приносило.
Вскоре, ядро стало обрастать необходимым функционалом, и до какого-то момента все шло прекрасно. Камеры работали вместе со своим собственным кодом и туда оперативно добавлялись фичи. В 2021 году была пройдена добровольная сертификация и включение Nexus в реестр Минцифры (№12466 от 30.12.2021), а также была пройдена проверка НДВ в восьмом отделе ФСБ - это необходимо, если нужно ставить камеру на режимный объект. Насколько мне известно, ПО от НИЦ “Технологии” — единственное российское ПО для видеонаблюдения с сертификатом НДВ ФСБ (до известных событий такой сертификат был у Samsung, Siemens и Bosch). Эта процедура сама по себе тянет на отдельную статью, вкратце можно сказать что если ПО писал не ты, или писал ты, но давно навалил костылей — проверку пройти не удастся, тебя буквально заставят отчитываться за каждую строчку, невероятно утомительная процедура, и к тому же длительная. Плюс ко всему, сертификат получает только та версия, которая исследовалась в ФСБ — если вы решите накатить обновление по воздуху, то камера потеряет все сертификаты.
И вроде все хорошо, сиди и радуйся, развивай прошивку, добавляй фич�� — но нет, добавление функционала и стало в итоге проблемой. Изначально, проектируя ядро прошивки, стояла одна цель — сделать так, чтобы все работало, какого-то видения конечного продукта не было. Поэтому меня ожидала стандартная проблема масштабирования — то что прекрасно работало на первых порах, по мере добавления новых фич начало работать нестабильно, либо отваливалось у клиентов и потом хотфиксилось прямо на ходу. Но отказаться было нельзя — эти фичи уже были проданы!
На этом этапе было принято решение о создании специального отдела аппаратно-программного тестирования. Тестирование, конечно, было и до этого, но тестировалось все с учетом опыта тестирования веб-приложений, и тест-кейсы, и сами проверки были простые, как сейчас видим — нерелевантные. С появлением полноценного отдела тестирования ПАК (программно-аппаратных комплексов) тесты стали более приближенными к реальности — например начали проверяться просадки битрейта в сетях разного типа, время аптайма камеры, стрессовые нагрузки на видеомодуль до появления артефактов, и многое другое, о чем раньше просто не задумывались.
Примерно тогда же в команду пришел очень талантливый и замотивированный сеньор, который возглавил разработку. Разработчики начали разбирать и систематизировать все нагромождение фич, костылей и багов, в которое разросся Nexus за это время, и пришли к резонному выводу — проще будет переписать все заново, имея опыт, а самое главное — видение конечного продукта.
Третья итерация — Рувер
Следующие два года команда разрывалась между поддержкой проблемного Нексуса и грамотного развития нового ПО — Ruware или просто Рувер. Опять же, повторюсь — ядро писалось с нуля, на своей сборке, поэтому готовых решений не было, подсмотреть за кем-то не представлялось возможным. На это ушло довольно много времени — почти год. Для некоторых наших крупных клиентов в прошивку заложили уникальный функционал — например шифрование загрузчика или работа по SSM (source specific multicast). Такого точно не встретите в массмаркетных камерах видеонаблюдения, хотя для многих потребителей это может выглядеть как фича ради фичи. Но самое главное достоинство Рувер — в том что он упорядоченный, новый функционал не ломает старый, остается место для роста впоследствии.
На данный момент, весь основной ф��нкционал уже готов, ПО стабильно. Но до коммерческого релиза еще пройдет время — надо допилить дополнительный, но очень востребованный функционал, отполировать интерфейс. Вдобавок, инженеры поглядывают на смену процессоров на более мощные, на новые сенсоры — процесс разработки очень живой, приоритеты могут меняться часто, это все существенно замедляет процесс, но компания старательно ползет к релизу! Очень завидую коллегам по рынку, у которых процесс написания полностью отечественной прошивки с нуля занимает в среднем год, к сожалению мне о таком приходится только мечтать…
Можно, конечно, покритиковать за нерасторопность, но не забывайте для чего пишется ПО — памяти в камере 16 мегабайт, а процессоры не то чтобы плохие, но низкопроизводительные. И это не тот случай, когда можно просто навалить начинки на все деньги — не забывайте, компания должна конкурировать в цене с азиатскими производителями и их колоссальными объемами. Каждая лишняя сотня рублей в себестоимости компонентной базы — это лишняя тысяча в конечной цене, которой с удовольствием воспользуются конкуренты.
Вместо финала
Какие же выводы должен сделать добрый читатель из нашей истории? На мой взгляд их два:
Собственное ПО под ваше железо — необходимость, не отдавайте его на аутсорс или в руки незаинтересованной команды, это как раз тот случай когда сделать хорошо — значит сделать самому.
Оценивайте сроки реалистично. Понятно, если ваш проект какой-то уникальный, и сравнить его не с чем — придется гадать с погрешностью плюс-минус полгода. В любом случае, не ставьте сроки во главу угла — они с очень большой вероятностью будут сорваны.
Напоследок, как и обещали, расскажем самый курьезный случай из разработки. В какой-то момент баланс белого в тестовой версии начал незначительно уезжать, и никто не мог понять почему — проблему искали и в партии сенсоров, и сборке тестовых камер, полезли даже смотреть код. Вроде изменения незначительны, но на разных профилях ББ заметны. Через время программист, ответственный за настройку ББ и цветовых профилей наконец признался — он дальтоник, и настраивал баланс белого пиблизительно, по гистограмме, а молчал потому что боялся что его выгонят.
Следите за публикациями на Хабре, скоро будет готов интереснейший материал о том как сжечь лазером матрицу камеры наблюдения (спойлер — практически нереально)!
