Статья про корпуса зашла неплохо, аудитория “Хабра” оказалась весьма приветливой, что и сподвигло меня на продолжение. На этот раз расскажу почему не стоит продавать продукт до релиза, почему “просто скопировать все у китайцев” — не работает, и зачем спрашивать о врожденных заболеваниях у разработчика, ответственного за профили цвета и баланс белого.
К сожалению, технических деталей в статье вы не увидите, так как 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 мегабайт, а процессоры не то чтобы плохие, но низкопроизводительные. И это не тот случай, когда можно просто навалить начинки на все деньги — не забывайте, компания должна конкурировать в цене с азиатскими производителями и их колоссальными объемами. Каждая лишняя сотня рублей в себестоимости компонентной базы — это лишняя тысяча в конечной цене, которой с удовольствием воспользуются конкуренты.
Вместо финала
Какие же выводы должен сделать добрый читатель из нашей истории? На мой взгляд их два:
Собственное ПО под ваше железо — необходимость, не отдавайте его на аутсорс или в руки незаинтересованной команды, это как раз тот случай когда сделать хорошо — значит сделать самому.
Оценивайте сроки реалистично. Понятно, если ваш проект какой-то уникальный, и сравнить его не с чем — придется гадать с погрешностью плюс-минус полгода. В любом случае, не ставьте сроки во главу угла — они с очень большой вероятностью будут сорваны.
Напоследок, как и обещали, расскажем самый курьезный случай из разработки. В какой-то момент баланс белого в тестовой версии начал незначительно уезжать, и никто не мог понять почему — проблему искали и в партии сенсоров, и сборке тестовых камер, полезли даже смотреть код. Вроде изменения незначительны, но на разных профилях ББ заметны. Через время программист, ответственный за настройку ББ и цветовых профилей наконец признался — он дальтоник, и настраивал баланс белого пиблизительно, по гистограмме, а молчал потому что боялся что его выгонят.
Следите за публикациями на Хабре, скоро будет готов интереснейший материал о том как сжечь лазером матрицу камеры наблюдения (спойлер — практически нереально)!