Статья про корпуса зашла неплохо, аудитория “Хабра” оказалась весьма приветливой, что и сподвигло нас на продолжение. На этот раз расскажем почему не стоит продавать продукт до релиза, почему “просто скопировать все у китайцев” — не работает, и зачем спрашивать о врожденных заболеваниях у разработчика, ответственного за профили цвета и баланс белого.

К сожалению, технических деталей в статье вы не увидите, так как 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 мегабайт, а процессоры не то чтобы плохие, но низкопроизводительные. И это не тот случай, когда можно просто навалить начинки на все деньги — не забывайте, нам нужно конкурировать в цене с азиатскими производителями и их колоссальными объемами. Каждая лишняя сотня рублей в себестоимости компонентной базы — это лишняя тысяча в конечной цене, которой с удовольствием воспользуются конкуренты. 

Вместо финала

Какие же выводы должен сделать добрый читатель из нашей истории? На наш взгляд их два:

• Собственное ПО под ваше железо — необходимость, не отдавайте его на аутсорс или в руки незаинтересованной команды, это как раз тот случай когда сделать хорошо — значит сделать самому.

• Оценивайте сроки реалистично. Понятно, если ваш проект какой-то уникальный, и сравнить его не с чем — придется гадать с погрешностью плюс-минус полгода. В любом случае, не ставьте сроки во главу угла — они с очень большой вероятностью будут сорваны. 

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

Обязательно подписывайтесь на наш канал в Телеграм — там мы стараемся выкладывать интересные новости из повседневной жизни разработчика электроники в России. Также подписывайтесь на наш новый канал в Ютуб (прошлый заблокировали из-за санкций) мы будем очень рады! Ну и следите за публикациями на Хабре, скоро будет готов интереснейший материал о том как сжечь лазером матрицу камеры наблюдения (спойлер — практически нереально)!