В статье, несмотря на то, что она, безусловно, чистый PR и рассказывает о нашем новом крутом (мнение автора) продукте, я постарался описать наш полезный опыт.

С какими проблемами сталкивались мы и наши клиенты при организации удаленной разработки ПО для устройств, как их решали, и откуда «растут ноги» у Redd, программно-аппаратного комплекса удаленной разработки ПО для встроенных систем. Почему появилась эта «коробка», и как изменится жизнь (опять же, мнение автора) миллионов разработчиков embedded-систем, устройств интернета вещей, оборудования для авто, самолётов, связи.



Я работаю в компании, которая скромно называется МИР. Не путайте с платежной системой, к ней отношения мы не имеем.

МИР в нашем случае расшифровывается как Мастерская Инструментов Разработки.

Мы разрабатываем системное программное обеспечение для российских и зарубежных клиентов. Типичный клиент – это производитель микроконтроллеров и микропроцессоров, обычно с какой-либо нестандартной, расширенной относительно стандартных, а может быть и с собственной архитектурой.

Для них мы разрабатываем инструменты разработки: IDE, компиляторы, операционные системы реального времени, отладчики, симуляторы, профилировщики и другие компоненты SDK.

Параллельно также беремся за разработку ПО для встроенных систем. Например, для немецкого автопроизводителя делаем ПО для современных приборных панелей. Также делаем проекты в авионике, разрабатываем ПО для организации mesh-сетей из «умных счетчиков» и беспилотников, делаем нестандартное ПО для систем контроля доступа, работаем на рынке IoT (умные розетки, например). В общем – много интересных проектов, в которых получается набирать достаточно нестандартный опыт решения возникающих проблем.



Для клиентов мы внешние разработчики. Причем мы находимся в Питере, Великом Новгороде и Красноярске, а клиенты – в Москве, Зеленограде, Туле, Воронеже, Германии и Корее.

При этом мы разрабатываем программное обеспечение для устройств. А для того, чтобы программировать конкретное устройство, нужно, чтобы у программиста было это устройство.

Если кто-то вдруг не знаком с «технологией»: необходим рабочий компьютер, где установлены нужные инструменты разработки, например IDE. К этому же компьютеру должны быть подключены устройства: отладочные платы, приборные панели (если речь идет о разработке для автомобилей). Выглядит примерно как на картинке:



Разработчик пишет код на компьютере и загружает на устройство, где он выполняется.
Понятно, что без самого устройства проверить работоспособность, заниматься отладкой или оптимизацией невозможно. Кроме того, программисту важно видеть, что происходит с устройством физически: какие светодиоды моргают, что показывается на экране, куда крутится колесо.

Проблемы разработчика

И здесь начинаются проблемы. Первая, с которой сталкиваемся, – доступность оборудования.

Многие предприятия делают уникальные изделия, штучные на ранних этапах производства. Их просто физически в мире существует одна, две или пять штук. Передать их внешнему разработчику (нам) – это большая проблема и сложная задача для заказчика. Может просто не быть свободных устройств.

Например, как в случае с новым процессором 1967ВН044 от АО «ПКК Миландр». Он ещё находится в состоянии завершения ОКР, но средства разработки под него нужно делать уже сейчас.



Вторая проблема, когда изделий мало, в них возникает масса аппаратных проблем. И, если изделие к нам приехало из Москвы, и мы нашли ошибку в железе, то можем передать изделие изготовителю для исправления в течение одного дня. А если изделие пришло из Германии? Нужно отправить изделие обратно разработчику, подождать исправлений и получить обратно. Всё это и не быстро, и дорого. А ещё возникают простои программистов и сдвигаются сроки проекта, пока мы ждем исправленное устройство. А ещё встречались заказчики, которые перевозят устройство только лично из соображений безопасности. При этом аппаратные ошибки обычно находятся гораздо чаще, чем они могут позволить себе приехать.

Вообще, наличие границ в мире – одно из серьезных препятствий, постоянно причиняющих неудобства. Доставка оборудования даже из близкой к нам Европы превращается в квест, а вот из Кореи или США… Не буду конкретизировать возникающие проблемы и пути их решения, скажу лишь, что все они увеличивают и сроки, и стоимость проектов для заказчика. А значит, снижают нашу конкурентоспособность.

Еще одна проблема – оборудование может сломаться. Транспортировка – это повышение риска повреждения оборудования плюс потери времени и затраты на логистику. Оборудование нужно отключить, упаковать, передать, распаковать, подключить и настроить, включить в состав стендов.

А теперь представьте, что вы разрабатываете газоанализатор, к которому прилагаются несколько огромных и тяжелых баллонов…



или систему распыления для вертолёта.





Сейчас отладку таких систем приходится делать на эмуляторах, хотя гораздо удобнее было бы некоторые вещи проверять удалённо (например, PID регулятор двигателя распыления, когда заказчик в начале сезона экспериментирует с установкой то инжекторных, то карбюраторных двигателей, либо подкручивает переменные резисторы в системе управления ими).

Но проблемы возникают, даже если программисты находятся в одном здании.

Оборудование может «потеряться», если нет формальных процессов передачи и оно «ходит» между программистами внутри проекта. Или оборудование может «идти» к разработчику долго, если формальные процессы есть, но бюрократизированы. Не могу сказать, что мы реально теряли оборудование заказчика, но бывали ситуации, когда было непонятно, у кого конкретно в данный момент находится отладочная плата, и сколько по времени она ещё будет занята. Ситуация некритичная, решается за пять минут, но и проектов много. Зачем тратить лишнее время?

Дело усугубляется тем, что программисты – очень увлекающиеся люди. В результате, если между ними есть конкуренция за одну и ту же плату (а это часто происходит, так как мы в основном работаем с уникальным железом), то неизбежны временные «накладки» и простои сотрудников, которые его ждут.

И даже если вы гениальный руководитель и построите отличный процесс и логистику, то всё равно проиграете по эффективности решению удаленного программирования без перемещений.

Например, в таком кейсе. На финальной стадии разработки начинается тестирование. Причём оно идёт не после, а именно параллельно с разработкой, в цикле. Тестировщики проверяют сделанные функции, находят ошибки, затем программисты исправляют баги, затем нужно тестирование и так далее. Оборудование в рамках одного и того же проекта нужно как разработчикам, так и тестерам. И если ваши офисы, расположены, например, в Красноярске и в Великом Новгороде, оборудование может работать практически круглосуточно. Днем и вечером (по Москве) программисты из Новгорода пишут код, а затем ранним утром (так как разница 4 часа) подключаются тестировщики Красноярска и полноценно тестируют на том же оборудовании в своё рабочее время.

Традиционное решение

Вывод очевиден – работать с железом удалённо может быть очень выгодно. Нужно сложить всё «железо» в одном месте и дать команде удаленный доступ.

Разработчики по очереди подключаются к устройству, работают с ним, выполняют задачу и отключатся, освобождая место для следующего.

И всё в этой схеме было бы замечательно, но использование стандартного удаленного доступа к компьютеру, который подключен к изделию не работает.

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

Если всё же получится подключиться, то всё равно разработчик не сможет управлять параметрами электропитания устройства: банально не перезагрузить устройство. Чтобы нажать кнопку «вкл/выкл» или выдернуть вилку шнура питания придется звонить коллеге в офис, чтобы он сходил и сделал это руками.

А потом коллега, которому программист «сбил мысль», должен будет 5-10 минут возвращаться к ней, это не считая того времени, пока он бегал и ему по телефону объясняли, какой именно рубильник дёргать. Так набегают человеко-часы и десятки человеко-часов простоя сразу на нескольких проектах, не связанных с текущим.

К тому же непонятно, что происходит с устройством физически. Что показывается на экране или индикаторах разрабатываемого устройства, как мигают светодиоды. Нужно не всегда, но такая потребность обычно возникает в самый неподходящий момент.

Конечно, есть вариант попытаться обойти и эти ограничения. Купить дистанционно управляемое реле, чтобы была возможность перезагрузить устройство, вебкамеру, чтобы наблюдать, смонтировать это всё и настроить. Дальше, если получится донести до всех, как с этим работать, куда «зайти» и что сделать в правильном порядке, то мы уже приблизимся к решению…

За исключением того, что когда разработчиков больше, чем устройств, отсутствует централизованная и понятная организация процесса доступа. И при работе с командой придется как-то ещё отдельно договариваться, кто и когда работает с оборудованием.

Redd – комплекс удаленного программирования

Идея решить все озвученные проблемы комплексно лежала на поверхности, и мы даже сначала не могли понять, почему ещё никто ничего подобного не сделал, когда начали искать конкурентов. Какие-то решения мы нашли, но неполноценные, по частям. Все что-то делают в своей области: кто-то чисто отладку JTAG, кто-то эмуляцию, но надо же ещё и отлаживать, и стенд чтобы был, и наблюдать, и питание, и управление доступом. В комплексе никто не делает, соответственно, и полноценно работающих решений нет.

Поэтому мы начали разработку Redd (расшифровывается как Remote development device). Это программно-аппаратный комплекс, который организует доступ к микроэлектронному оборудованию через интернет или локальную сеть по ряду стандартных и настраиваемых коммуникационных протоколов.



Мы не гнались за «нано инновациями». По сути, Redd – это просто объединенные в одном устройстве понятные и простые технологии, которые в сумме дают решение проблем, которые я описал выше.

Redd может подключаться к устройству через различные интерфейсы, что снимает проблему работы с большим количеством устройств, умеет управлять питанием, и теперь можно перезагрузить устройство без чьей-либо помощи. Есть видеокамера, через которую разработчик видит, что происходит с устройством в реальном времени.



Плюс серверная часть продукта позволяет бронировать оборудование через интерфейс календарей и управляет доступом.



Технически Redd состоит из двух зависимых компонент: «удаленного терминала» и серверного ПО.



Удалённый терминал – PC совместимый компьютер на базе процессора Intel, оборудованный платой расширения интерфейсов, которую мы сами разрабатываем. В первой версии (в марте) будут доступны Ethernet и USB Host (JTAG). Во второй (в июне) – UART, Ethernet, GPIO, SPI (+SPI flash), SDIO (с переходником на эмулятор SD карты), I2C, USB 2.0 OTG, PCIe, LVDS, RS232 CMOS, силовые ключи для коммутации питания и логические ключи для активации, например, кнопок.



В устройстве имеется наиболее часто используемый набор интерфейсов, плюс имеется ПЛИС для реализации любых нестандартных вещей. Так как система спроектирована в комплексе, гарантируется отсутствие взаимных конфликтов. И интерфейсы будут переходить с проекта на проект вместе с комплексом, без необходимости закупки чего-то дополнительного.

Разрабатываемое оборудование часто невозможно постоянно испытывать в боевых условиях. Вертолёт только за диспетчерское сопровождение взлёта-посадки платит 50 Евро. Автомобиль гонять всё время — нереально. Корабли не всегда в море. В общем, нужны эмуляторы.

Как система общается с внешним миром? Через датчики, подключённые к различным шинам. Ну, и сигналы к исполнительным устройствам также выдаются по шинам. Текущая номенклатура шин довольно широка. Это может быть CAN, UART (в варианте КМОП, RS232, RS485), Ethernet, MODBUS (через тот же UART или Ethernet), цифровые линии с различными уровнями и прочее, прочее, прочее.

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

А можно вместо этих датчиков и исполнителей подключить Redd, написать имитаторы их работы (именно их, то есть, мы имитируем внешнюю среду), после чего отлаживать разрабатываемое устройство, которое думает, что оно стоит в автомобиле или ещё где-то, и мы занимаемся отладкой целевой логики. А тестеры через этот механизм смогут проверять пограничные и даже заведомо ошибочные ситуации, которые очень сложно или совсем невозможно воспроизвести при обычном тестировании.

Серверная часть комплекса располагается прямо на терминале. Разработчик через web может видеть, какие устройства и в какое время ему доступны. Может бронировать их в календаре, чтобы ему автоматически был предоставлен доступ. Он через протокол ssh подключается к терминалу, а при помощи него – к отладчику и управлению эмуляторами устройств. Кроме того, режим работы Redd может быть не только многопользовательским, но и с одновременным подключением нескольких устройств.



Таким образом Redd позволяет организовать удаленный доступ внутренних или внешних разработчиков к устройству (или группе устройств, есть возможность подключать к одному терминалу несколько устройств), спланировать и управлять доступом во времени, без физического перемещения.



Дополнительный бонус – Redd можно использовать и для демонстрации изделия внешним заказчикам и клиентам без фактической передачи. Или для организации дистанционного обучения программированию устройств, что может быть интересно для производителей микропроцессоров или для учебных заведений.

Что сейчас?

Сейчас заканчиваем разработку первой версии, выйдет в начале марта, и она уже доступна для предзаказа (естественно, на льготных условиях).

Основная задача этой статьи (кроме рекламы) – собрать обратную связь.

Пишите, если вы не согласны, что существуют проблемы, которые описаны в статье, или можете назвать те проблемы, которые я забыл.

Может быть, вы знаете решения, которые мы не нашли, или решаете эти проблемы по-своему.

Или готовы поддержать нас добрым словом (а может и не только) в разработке продукта.
Буду рад комментариям.