150 технических специалистов, собственная ОС и 6 патентов. Как работает R&D команда Ajax Systems
Ajax Systems — украинская продуктовая компания, известная разработкой и производством умной беспроводной системы безопасности, которая защищает дома пользователей от вторжений, пожаров, затоплений.
Сейчас в штате 800+ человек. Есть R&D-офисы в Киеве и Харькове. Компания представлена также в ОАЭ, Великобритании и Польше.
Ajax Systems уделяют много внимания дизайну и интерфейсам, инвестируют в собственные аппаратные и программные технологии. В компании есть запатентованные решения: свои протоколы связи Jeweller и Wings, операционная система OS Malevich, алгоритмы в датчиках.
За разработку устройств и ноу-хау отвечает R&D-команда: она насчитывает более 150 человек и состоит из четырех отделов: Device, System, QA и Automation. Мы узнали, как работает каждый из отделов и какие задачи стоят перед ними
Как все начиналось
Идея разработки собственных устройств для охранных систем впервые появилась у CEO Ajax Systems, Александра Конотопского, в 2011 году. В то время Александр руководил компанией Secur — одним из крупнейших дистрибьюторов товаров для охранной сферы в Украине. Многие устройства Secur тогда закупала в Китае, и их качество часто хромало.
Однажды покупатели пожаловались, что сирена китайского производства прекратила работать через месяц после установки. Разобрав прибор с товарищем-инженером, Александр выяснил: звуковое устройство в нем было рассчитано на 2 ампера, а установленный китайцами транзистор — на 1 ампер:
«В этот момент у меня произошел разрыв шаблона. Китайский завод, где работает 400 человек, не мог разобраться в проблеме больше года. А мой одногруппник решил ее за 15 минут»
Тогда Александр решил: если производитель, продающий продукцию по всему миру, не столь квалифицированный, как обычный выпускник украинского технического вуза, стоит попробовать составить китайцам конкуренцию. Так появилась идея разработать собственную охранную сигнализацию.
Первая линейка датчиков оказалась вполне успешной на локальном рынке, но когда команда привезла продукт на международную выставку, то никто не проявил интереса. Импортозамещающим решением было некого удивлять — нужно было что-то новое и уникальное. Тогда Александр и команда решили создать охранную систему с чистого листа — со своим протоколом связи, централью, датчиками, облачным сервером и мобильным приложением.
Линейка датчиков Ajax, какой ее знают современные пользователи, впервые появилась в 2015 году. На ее разработку ушло 3 года. Началось все c Jeweller — разработки проприетарного радиопротокола — базового ноу-хау Ajax. Jeweller обеспечивает большую дальность связи между устройствами, рекордные 2000 м на открытом пространстве, и энергоэффективность — датчики работают
Из устройств в линейке первыми появились датчики движения, открытия, разбития стекла и интеграционные модули. В 2016 году компания выпустила Ajax Hub, интеллектуальную централь, которая позволила объединить отдельные охранные устройства в охранную систему, а в 2017 году — новую операционную систему хаба OS Malevich.
Расширение продуктовой линейки Ajax
Сегодня у компании экосистема из 29 устройств. Кроме хабов, датчиков движения, открытия двери/окон, дыма, затопления и разбития стекла, есть сирены, умный ретранслятор сигнала, панель управления, тревожная кнопка, умная розетка и реле для управления электроприборами.
Компоненты для устройств заказывают у производителей со всего мира, однако все этапы производства — от монтажа DIP и SMD компонентов на платы до упаковки — происходят на заводе в Киеве. Так минимизируют использование аутсорса, сосредоточивая экспертизу внутри.
За последние 3 года объем производства Ajax Systems вырос в 13 раз и составляет более 250 000 устройств ежемесячно, а количество сотрудников на нем увеличилось с 45 до 500.
Сейчас система продается в 96 странах, ее используют более 500 000 человек. В Украине с ней работают не только частные компании, но и государственная полиция охраны.
Рассмотрим подробнее процессы в R&D-отделах Device, System, QA и Automation. R&D-директора каждого из отделов рассказали нам, как все устроено.
Device department
«Главные инженерные вызовы: Low Power, себестоимость и пригодность к массовому производству»
Этот отдел отвечает за разработку всех датчиков и устройств Ajax, софта для них, а также многих запатентованных технологий (например, протоколы Jeweller и Wings). Сейчас в команде 36 человек, и разработка новых устройств разделена на три основные направления: охранные устройства (датчики движения/вторжения), устройства home automation, пожарная безопасность.
У каждого направления есть свой проджект-менеджер, техлид, свои разработчики-изобретатели (придумывают, как будет работать устройство исходя из прикладной задачи), разработчики софта, разработчики железа.
Отдельно выделены архитектор, разработчик проприетарных радиопротоколов и ядра устройств. Эти инженеры так или иначе участвуют абсолютно во всех проектах.
Еще есть две подкоманды, которые организованы не по направлениям разработки, а по функционалу. Это команда hardware, что занимается разработкой плат. Сюда входят инженеры схемотехники и трассировщики, а также радиоинженер, отвечающий за радиочасть и электромагнитную совместимость. И команда mechanical — она состоит из конструкторов, которые разрабатывают корпусы и механику устройств, тест-стендов для масспрода и различные вспомогательные тулинги. Инженеры из этих команд на время, когда это требуется, подключаются к командам, разрабатывающим устройства.
Промышленный дизайнер сотрудничает с компанией удаленно из Эстонии.
Рабочий процесс
Если взять самый крупный воркфлоу — разработки устройства, то он строится так. Приходит идея от бизнес-команды — какое устройство должно быть разработано. К ней оформляются технические и продуктовые требования. Они передаются разработчикам, которые на основании этих требований начинают генерить идеи, как устройство будет работать и на базе чего. На стадии исследования тестируются конкурентные/похожие решения и выбираются основные компоненты: сенсоры, модули камер, процессоры и прочее.
Максим, R&D-директор Device department, рассказывает: «Есть простые задачи, где есть один способ решения — например, при создании датчика воды. А есть случаи, когда задачу можно решить разными способами. Так, движение можно детектировать PIR-сенсорами, можно микроволновым сенсором на эффекте Доплера или сделать комбинацию. А когда стали разрабатывать уличные датчики, столкнулись с еще большими сложностями. Надо было придумать, как отфильтровать все помехи, кроме движения человека: ветер, движение деревьев, уличных животных, птиц, насекомых и так далее. В результате появился уличный датчик MotionProtect Outdoor — c нашим собственным двухэтапным цифровым алгоритмом предотвращения ложных тревог Lisa.
А потом пошли еще дальше и добавили фотокамеру в беспроводной датчик на батарейках. Получился MotionCam — датчик движения с фотоверификацией тревог. Для него разработали наш второй ридиопротокол Wings — он передает снимки менее чем за 9 секунд на расстоянии до 1700 метров от хаба. Чем дальше, тем более сложные устройства мы делаем».
После стадии ресерча лид устройства и команда презентуют свою концепцию перед широким кругом R&D-специалистов (делают некую «защиту проекта»). Так идеи проходят дополнительный фильтр и после этого дорабатываются.
Дальше начинается стадия промышленного дизайна. Промдизайнеру дают входные ограничения: например, должна быть линза Френеля на лицевой части, камера в датчике — направлена под таким углом и тому подобное. И он вокруг этого рисует дизайн. Иногда делают наоборот: когда особых внешних технологических ограничений нет, сначала рисуют дизайн, а потом «засовывают» в него всю комплектацию.
Параллельно прорабатывают схему и пишут софт. В основном используют STM 8/32 і Embedded C. Далее разрабатывается плата.
«Затем, в зависимости от потребностей, мы можем напечатать на 3D-принтере корпус, а можем сделать его в хард-тулинге, то есть заказываем пресс-формы не на массовое производство, а попроще и подешевле — и отливаем прототипы из пластика. Допустим, световоды для системы антимаскинга. Их нужно сделать достаточно точно, тогда используют хард-тулинг. В результате получаем прототипы в финальном дизайне», — рассказывает Максим.
После этого прототипы проходят всестороннее тестирование разработчиками и QA. Если что-то не взлетает, переделывают и собирают новые прототипы.
Когда всё работает, как ожидалось, следует большой майлстоун, на который тратится много денег — заказывают пресс-формы уже на финальный пластик. Собирается пилотная партия в финальных корпусах, на финальных платах, и на этом «железе» тестируют релиз-кандидат прошивки.
Завершается все этапом бета-теста. Сперва идет закрытый — девайсы раздают сотрудникам. За ним стартует открытый бета-тест — для этого есть выборка активных пользователей (как в Украине, так и за рубежом).
Потом устройства передают в массовое производство.
Главные вызовы
Максим говорит так: «У каждого девайса всегда есть три основных ограничения:
- Low Power — устройства должны работать максимально долго от комплектных батарей
(5-7 лет) на расстоянии 2000 м; - себестоимость — мы делаем массовый продукт среднего ценового сегмента;
- дизайн и пригодность к массовому производству — сборка должна быть простой и быстрой, а у ключевых компонентов должно быть несколько поставщиков.
В этих ограничениях заключается вся сложность разработки устройств Ajax. Если убрать любое из них, становится кардинально проще все реализовать».
System department
«Чтобы продукт был конкурентным на рынке, нужен engineering excellence»
Отдел отвечает за создание и развитие программных продуктов: OS Malevich, облачного сервиса Ajax Cloud, мобильных и десктопных приложений.
В отделе 28 человек, они делятся на 3 команды:
- Команда Apps разрабатывает десктоп, Android и iOS приложения.
- Команда Malevich создала и развивает операционную систему OS Malevich (у команды есть отдельный R&D Lead, о ней ниже).
- Команда CSA занимается разработкой серверов и их поддержанием.
Рабочий процесс
B2C и B2B продакт-оунеры формируют для команды требования — что именно и в каком приоритете должно быть сделано. На вход поступают проектного вида задачи. Например, сделайте так, чтобы, нажав на эту кнопку, можно было заменить существующий хаб на новый. К примеру, если вы приобрели новую модель хаба, но не хотите все устройства переносить на него вручную.
Дальше, как рассказывает Александр, R&D-директор System department, начинается анализ: «Садятся лиды, команды, которые будут участвовать в разработке проекта, и делают предварительное техническое задание — дизайн, архитектуру, протоколы, взаимодействие компонентов друг с другом. Когда есть первая итерация архитектуры, понимание объема проекта, происходит кик-офф — митинг, на котором мы рассказываем остальным членам команды, что это за проект с продуктовой и технической точки зрения, зачем он нужен и как собираемся его реализовать.
Затем согласовываем и планируем даты релизов таким образом, чтобы команды друг друга не блокировали, и берем уже технические задания непосредственно в работу (у нас Agile, но в зависимости от команды и периода это может быть или Scrum, или Kanban). Мы сильно печемся о качестве продукта и о качестве кода, поэтому, например, текущее требование на сервере — это покрытие автотестами нового кода не менее 90%».
После того как часть задачи была сделана разработчиком, покрыта тестами, она передается в отдел тестирования, где QA вдоль и поперек тестируют эту часть функционала. Если нет никаких проблем, функционал включается в следующую сборку. Все сборки автоматизированы — как для приложений, так и для серверов. И в зависимости от того, какая это команда, функционал включается в следующую доставку. Если сервер — это будет деплоймент, если мобильные приложения — апдейт приложения. Немного другой процесс для инфраструктуры, там задачи доставляются, как только готовы.
По словам Александра, в команде CSA глубокая DevOps-культура: «Мы считаем, разработчикам важно понимать и заниматься операционкой, потому что задевелопить и „пусть оно как-то крутится“ — это хороший подход для аутсорсинга, но не для продукта. Продукт состоит из абсолютно всех частей — и разработать, и поддерживать, и убедиться в том, что он операционно правильно работает постоянно, не падает по ночам».
Технологический стек
На iOS — Objective C и Swift. На Objective C написана низкоуровневая логика по работе с проприетарным протоколом связи между хабом и сервером HtS, а весь пауер-код, всю хай-левел логику пишут на Swift. На Android тоже смесь Java и Kotlin, но потихоньку переписывают всё на Kotlin. На десктопе используют PyQT.
Сервер — это Java и Kotlin, для месседжинга — Akka, но переходят на NATS в новых проектах. Для хранения данных применяют MySQL, MongoDB и Redis — в зависимости от задачи. Вся инфраструктура в AWS, в амазоновском клауде. Используют Terraform и Bash, Python для ее автоматизации.
Главные вызовы
В компании говорят, что поскольку производят охранные системы, то не могут себе позволить на сервера взять джуниор infrastructure-инженера, который сделает outage. Есть зоны ответственности, где цена ошибки слишком велика, поэтому переборчивы в кадрах. Чтобы продукт был конкурентным на рынке, нужен engineering excellence. Соответственно, вкладываются в хороших специалистов, которые способны это сделать.
Александр рассказывает: «Ребятам, которых мы берем на сервер, на собеседовании задаем вопросы по базовым компьютерным наукам. Если человек использует базовые структуры, не понимая, как они работают, для меня это означает, что он и в дальнейшей работе не будет разбираться.
Для примера возьмем сервера: у нас сейчас нагрузка порядка миллиона пакетов в минуту, то есть приблизительно 17 000 в секунду. 300 000 TCP, подключений, постоянно висящих на наших серверах. Понятное дело, что есть определенные инструменты и подходы, которые могут уменьшать вероятность ошибки — performance testing, load testing и так далее. Мы все используем, но всё равно задача довольно масштабная».
OS Malevich team
«В основу новой ОС легла идея упрощения: добавление функциональности не должно снижать скорость разработки»
Команда Malevich — это часть отдела System, которая отвечает за разработку софта для хабов и ретрансляторов сигнала ReX. Для высокой надёжности этих устройств запустили собственную операционную систему реального времени OS Malevich.
Хаб относится к System потому, что вся бизнес-логика выполняется на нем (в отличие от многих других систем, где делают очень простые датчики и сложные сервера, которые принимают решения). «Когда люди сталкиваются с системами Ajax, они удивлены, что у нас решения принимаются на объекте. Хаб на OS Malevich принимает решение о вызове группы быстрого реагирования, отправляет людям SMS, звонит, включает сирены. Автономность хаба — это наше большое преимущество», — рассказывает R&D-директор Сергей.
Почему решили разработать собственную ОС
Из-за проблем с надежностью Linux лучшие профессиональные решения на рынке не работают с ней. В команде тоже придерживаются этого мнения. Операционные системы класса RTOS рассматривали серьезно. По определению в таких системах либо результат нужен за 3 миллисекунды, либо он не нужен вообще. Поэтому RTOS используют в лифтах, автомобильных тормозах, баллистических ракетах, где критична сверхнадежность. Первая версия хаба, которая продавалась, была написана на RTOS, однако существующая архитектура не позволяла стремительно наращивать функциональность. В систему заложили апдейты, и уже в полях она заменилась на первую версию OS Malevich.
Как говорит Сергей, «в основу новой ОС легла идея упрощения. Мы поставили перед собой условие: добавление функциональности не должно усложнять систему и снижать скорость разработки. Чтобы не сбиться с намеченного курса, дали проекту кодовое имя „Малевич“. Реализовали схожий с Linux механизм распределения процессорного времени, в результате чего процессор хаба даже в ресурсозатратных задачах загружен максимум на 20%. Также сделали систему модульной (сама ОС это только 1 модуль из 70) со взаимодействием элементов через API. При этом компоненты, задачи в модулях не сражаются друг с другом за приоритетность „дай мне больше процессоров, больше времени, больше памяти“ или еще что-то такое. Всё сразу договорено на берегу.
Мы понимаем, что разработка своих самодельных ОС имеет вкус изобретения велосипеда. Я не сильно ошибусь, если скажу, что все студенты-программисты писали свои операционные системы. В 90% компаний за это бьют по рукам, когда начинаешь делать что-то свое вместо того, чтобы применить готовое. Но мы приняли это решение — создавать свое, и не раз убеждались, что сделали правильный выбор.
Также адаптировали OS Malevich под работу ретрансляторов сигнала ReX. Это обеспечило Ajax еще большую автономность: если по какой-то причине радиосвязь с хабом прервется, ReX сможет частично принять управление системой на себя».
Рабочий процесс
Требования разрабатывают вместе с бизнес-отделом. Бизнес советуется с командой о том, что они могут создать. То есть бизнес принимает решения на основе своих целей, команда принимает решения на основе своих возможностей — так получается достигать требований. Дальше идет классическая разработка по Agile.
Технологический стек
Сергей рассказывает: «В Embedded-мире используют С. Python для того, чтобы поддерживать мета-программирование. Система сборки — чистый Make, чем я лично очень горжусь.
Эффективность Мake просто потрясает. Если кто новый приходит в проект, он говорит: „Ну вот, сейчас я буду собирать эту прошивочку“, подключает сборку и собирается идти обедать. Не успевает повернуться, а оно уже закончилось. То есть Make не в разы, а в десятки раз быстрее соображает, что делать, а что нет. На Make удобно записать и зависимости между модулями, и размеры таблицы, исходя из хаба, страны, всякие частоты и прочее. Файлы Make простые для чтения и сложные для написания. В общем, очень его любим.
С++ не используем. Он избыточен — в данный момент нам не нужны его фичи. Еще одна неудобная для нас особенность С++ — неотделимость от динамического распределения памяти при появлении/уничтожении класса. У нас ресурсы распределены на берегу до выхода в море (благодаря этому для вирусов в OS Malevich просто нет места) — на С++ это плохо поднимается. Также одна из наших гордостей — это когда вы смотрите на хаб в приложениях, там нет кнопки „Перезагрузить хаб“. А если бы там был С++... Если эта кнопка появляется, это косвенно означает, что там С++. То есть хаб устает, каждые две недели его надо перегрузить до какого-то начального состояния. Нашим хабам перезагрузка не требуется».
Главные вызовы
Перед командой стоят три основных челленджа. Первый и главный: не ломать старое и создавать новое. Когда «Малевич» вышел на рынок, у продукта была очень высокая планка качества. То есть если один хаб из нескольких тысяч когда-то ночью вместо «мяу» сказал «гав», разворачивалась чуть ли не вся партия, всё разбиралось и переделывалось. Когда всё это вышло и начало продаваться, люди уже привыкли к этому качеству. И вызов, который стоит сейчас: следующая версия не может быть хоть в чем-то хуже предыдущей. То есть версия 2.10 должна быть во всем лучше 2.9, обладать той же стабильностью, а технически это часто довольно сложно. Когда добавляются новые фичи, всегда где-то изменяется весь проект.
Второй вызов — это бизнес-логика, которая все время усложняется. У разных стран есть требования законодательства, как должна вести себя охранная система. Сергей приводит пример Норвегии: «У них написано в законе, если один датчик пожара на объекте закричал, то всё остальное тоже должно закричать из солидарности. Идея в том, что один датчик в подвале или на чердаке, другой — в спальне, и датчик должен заорать, даже если пожар не в этой комнате, а где-то недалеко. Они прописали, и нам пришлось это делать для сертификации. Сегодня хабы это умеют».
Третий вызов — это уменьшение стоимости разработки, автоматизация программирования. Все время появляются новые датчики, и добавление их по всей системе требует формализованной последовательности действий, на что уходит много времени. Сократить это время, довести до автоматизма появление каждого нового датчика — это один из челленджей, которыми занимается команда.
QA department
«Информации, инструментов, специалистов для тестирования hardware не хватает. Все придумываем сами»
Сейчас в отделе около 40 человек: в нем прослеживается матричная структура. Каждый сотрудник входит в общую команду QA и подчиняется Head of QA. Дальше идет разделение на команды по направлениям: Apps, Malevich, CSA, Device и Prod Automation. В каждой команде есть свой QA-lead, и он уже непосредственно ею руководит. Также каждый QA входит в команду конкретного проекта и там он подчиняется проджект-менеджеру этого проекта.
Физически все QA сидят вместе. Это позволяет специалистам из разных проектов постоянно взаимодействовать между собой, делиться опытом и помогать друг другу, особенно если тестируются элементы системы, работающие на стыке. Поскольку продукт компании — целостная охранная система, то невозможно тестировать какую-то её часть, не задействуя остальные. Например, нельзя тестировать один датчик открытия, при этом не взаимодействуя с хабом и с приложением. Получается, что все QA работают со всем оборудованием, но в то же время точечно нацелены на тот продукт, за который отвечают.
Богдан, R&D-директор QA department, говорит: «Часто такое бывает, что ребята из Mobile находят проблемы в девайсах, а ребята из девайсов находят проблемы в мобильном приложении. Иногда люди из одной команды переходят в другую. Я считаю это важным. Если команды разделить, они начнут частично дублировать работу друг друга и не будут распространять опыт.
Все наши QA — выпускники технических факультетов. У нас обязательное условие приема на работу — технический бэкграунд, хорошие знания, понимание базовых вещей из физики и математики. Когда мы нанимаем Junior QA, то в качестве тестового задания даем задачи по физике и математике за школьный курс, 8-9-й класс. Также важно, что у нас QA — это не тестировщики, а скорее Developers in Test. Они разрабатывают продукты, которые тестируют другие продукты».
Рабочий процесс
В тестировании приложений всё понятно. Выходит новый билд, QA, исходя из спецификаций, пишут тест-кейсы, тестируют. Также специалисты, которые тестируют софт, могут симулировать ОС, у них есть инструменты для этого. Например, приложения, что делают фейковую геолокацию, если у них есть взаимодействие с картами.
В тестировании девайсов всё гораздо сложнее. Допустим, выходит новый датчик, и в требованиях написано, что этот датчик должен детектировать движение в диапазоне температур от −10 до +60 градусов. Тестировщик должен это проверить, а для этого проявить креативность. Например, летом, когда на улице +30, найти морозильные камеры для продуктов, договориться о том, чтобы для теста нашлась пустая, достаточно большая камера, там проверить, как датчики работают при −10 градусах.
У команды Богдана много интересных историй: «Мы тестили датчик движения, и нужно было зимой проверить, как датчик детектирует движение при +50. Эти тесты проводились в боксах для покраски автомобилей. Мы ездили, договаривались, чтобы выделили время для теста, нам нагревали целое помещение до +40 градусов и больше.
Также регулярно приходится ездить на Окружную, тестировать дальность радиосвязи (нужен чистый эфир и три километра прямой видимости). Вот был недавно забавный случай, когда наши ребята стояли возле дороги со всем расставленным оборудованием. Со стороны выглядит довольно странно: стоит группа людей возле машины, там антенны, разложенные ноутбуки, какие-то строки, логи, и в этот момент там собирался проезжать кортеж президента. Наша группа очень заинтересовала управление государственной охраны: они начали выяснять, кто мы, что здесь делаем. Хорошо, что они знали про Ajax. Просто попросили нас временно свернуться и отъехать оттуда».
Технологический стек
Главные инструменты — это C, Python и схемотехника. На Python пишут фреймворки для автотестов, при помощи С и схемотехники создают различные hardware-устройства и тест-стенды, что помогают в тестировании девайсов.
Главные вызовы
По словам R&D директора, основные проблемы — это отсутствие информации о том, как тестировать hardware-продукты, людей с готовыми знаниями и навыками, инструментов для тестирования.
Есть компании со схожей экспертизой, но они редко ею делятся — обычно такая информация под NDA. К тому же hardware-устройства между собой отличаются, подходы и инструменты тестирования тоже разные. Также сложно найти людей, обладающих знаниями в доменной области — таких людей просто нет. Все QA, которые работают в Ajax, выросли в компании с нулевого уровня.
Сложно и с инструментами: «Если мы, например, тестим web, для автоматизации есть куча инструментов. Если пытаемся автоматизировать серверные приложения, есть API. А для тестирования IoT в целом нет никаких готовых framework или устройств. И если разработчикам нужно просто разработать продукт/устройство, то QA разрабатывает десяток вспомогательных устройств, при помощи которых это устройство тестируют. Поэтому hardware-история такая: если разработчик делает какую-то фичу за час, то QA нужно 10 часов для того, чтобы ее протестировать», — делится Богдан.
Сейчас основное направление — это автоматизация. Команда сталкивается с тем, что количество продуктов Ajax растет, при этом нельзя перестать тестировать старый функционал. Разработчики делают новый, дополняют систему, и с каждым релизом нужно проверить весь новый функционал и весь старый. Время на тестирование постоянно растет. «Тестирование только одной OS Malevich занимает 2000 человеко-часов. Этот тест мы прогоняем перед каждым релизом. Пару раз было такое, что прогоняли более десяти раз полный регресс. То есть десять раз по 2000 человеко-часов — это уже получается около 20 000 человеко-часов. Абсолютно неадекватные сроки. QA становятся „боттлнеком“ в процессе релиза: разработчики сделали версию, QA её тестируют долго, а без тестирования охранную систему мы зарелизить не можем», — говорит Богдан.
Именно поэтому команда и делает упор на автоматизацию. Сейчас автоматизировали 35% общего количества тест-кейсов на OS Malevich. Все реализовано на реальном «железе» в условиях настоящего радиоэфира. Например, чтобы работать в радиоканале на базе OS Malevich разработали Jimmitator — имитатор датчиков Ajax, которые используют Jeweller для обмена информацией с хабом. Jimmitator позволяет работать с максимальным количеством устройств и предоставляет удобный интерфейс для одновременного управления ими.
Для упрощения мануального тестирования на основе ядра Ajax PRO был разработан QA Space. Эта среда дает возможность эмулировать различные части системы, генерировать ивенты, конвертировать информацию. На ядре Ajax PRO также функционирует фреймворк для автоматизированного тестирования сервера и хаба, который позволяет в удобном виде проверять работу системы на стороне клиент-серверной части.
В перспективе планируют автоматизировать
Аналогичная ситуация в команде Device. Там специалистам приходится разрабатывать собственные устройства, которые тестируют датчики. Например, для DoorProtect Plus (датчик открытия, совмещенный с датчиком удара и наклона) разработан целый стенд с платформой, которую этот датчик наклоняет, проверяет, при скольких градусах детектирует наклон, имитирует вибрации, нажимает тампер, тестирует его радиоканал.
Automation department
«В любом финальном варианте можно что-то улучшить»
Отдел состоит из 11 человек. Здесь разрабатывают программно-аппаратные комплексы (тест-стенды) для тестирования каждого устройства в процессе производства, создают станки и роботов для автоматизации процессов сборки, а также внутренний софт для прошивки устройств и управления производством на всех этапах — от монтажа плат до упаковки готовой продукции. По сути отдел отвечает за то, чтобы производство в кратчайшие сроки могло поставить максимально качественный продукт в большом объеме. Благодаря их работе уровень брака на производстве составляет всего 0.3 процента.
По словам проджект-менеджера Антона, основное для сотрудников — ответственный подход к работе и умение быстро переключаться с одной задачи на другую. В отделе разрабатывают и поддерживают порядка 20 различных программ (не считая firmware автономных тест-блоков), и каждый разработчик должен в них разбираться.
Примеры разработок
Сейчас разработано около 40 типов различных стендов (в зависимости от датчиков), в общей сложности на производстве задействовано около 150.
Например, одна из разработок — обтискивающий станок, который повысил эффективность монтажа защитной решетки на корпусе уличной сирены StreetSiren в три раза. Есть тест-стенд, калибрующий 15 сенсорных кнопок клавиатуры KeyPad менее чем за минуту. А для проверки нового датчика с камерой MotionCam был разработан специальный тест-блок и софт с алгоритмами, что анализируют качество отснятых снимков в условиях дневного освещения и ночной съемки.
Рабочий процесс
Рабочий процесс начинается, когда у команды Device появляется прототип нового устройства либо обновление существующего. Специалисты из Automation department собирают требования по тому, какие характеристики должны быть у устройства и какие функции оно будет выполнять, разрабатывают методики внутрисхемного и функционального тестирования, определяют, через какие этапы производства устройство должно пройти и что получится на выходе. После этого начинают разработку тест-стендов и готовят софт для выпуска бета-тестовых устройств.
Пока заказывают комплектующие для стендов, параллельно могут писать firmware для них либо добавлять поддержку девайсов в софт на нужных участках производства. Когда приходят комплектующие, собирают все смонтированные платы в специально разработанный корпус, берут прототип нового устройства и начинают отладку тест-стенда, чтобы он покрывал все характеристики и требования команды Device.
Перед тем как отдать разработанный софт или тест-блок на производство, его отправляют на тщательную проверку внутреннему отделу QA в команде Automation. Проверяется корректность тестирования и прошивки девайса, а также внесение всех необходимых данных в базу на каждом этапе производства.
Технологический стек
Используют
Главные вызовы
По словам Антона, «основной вызов — это любой новый девайс. Разработка „железа“ — довольно итерационная штука. Даже если считаешь, что есть какой-то финальный вариант, скорее всего, в нем можно еще что-то улучшить. И когда команда Device улучшает что-то в своих платах, нам часто прямо на ходу приходится переделывать свои тест-блоки, изменяя параметры тестирования, чтобы выявить потенциально дефектные продукты, которые могут уйти с производства».
Итоги и планы
С 2015 года за все время разработки в компании сделали 29 девайсов, 7 основных обновлений устройств и 85 обновлений софта. Также есть 6 запатентованных ноу-хау решений.
По словам Александра Конотопского, в ближайшие два года Ajax продолжит развивать линейку умных устройств для автоматизации дома. Есть планы по профессиональным противопожарным решениям и большой роадмап по охранным устройствам. Он видит Ajax в дальнейшем как полноценную платформу, в ДНК которой безопасность будет занимать основную роль.
