Отслеживание программного обеспечения на развернутых в полевых условиях устройствах

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

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

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

В этом сценарии отслеживание программного обеспечения можно сравнить с виртуальным «самописцем полета», аналогичным тем, которые используются в авиалайнерах в случае аварии. Это неотъемлемая часть продукта, которая всегда ведет запись, предоставляя важную информацию в случае возникновения проблемы. Но в отличие от настоящих коробок с бортовыми самописцами, это программное решение, предназначенное для устранения проблем с программным обеспечением.

Одним из решений для такого рода мониторинга устройств Интернета вещей является DevAlert от Percepio (рис. 1), который состоит из трех частей:монитора встроенного ПО, небольшой библиотеки, которую вы добавляете в свое встроенное ПО для отслеживания и загрузки предупреждений; наш инструмент Tracealyzer для визуальной диагностики трасс; и облачная служба, отвечающая за категоризацию и хранение предупреждений, уведомление разработчиков, фильтрацию повторяющихся предупреждений и многое другое.

Рисунок 1. Percepio DevAlert предоставляет разработчикам Интернета вещей мгновенную обратную связь об ошибках в их устройствах, подключенных к облаку, что позволяет быстро и непрерывно улучшать программное обеспечение устройства.
(Нажмите на изображение, чтобы увеличить)

Первоначальная версия работает на AWS и предназначена для приложений RTOS, использующих ядро ​​AWS IoT, но решение может быть адаптировано для других облачных платформ.

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

По сравнению с прямым физическим подключением, таким как USB или Ethernet, облачное подключение предлагает как ограниченную полосу пропускания, так и гораздо более длительное время отклика. Для загрузки, скажем, 5 КБ данных по беспроводному интерфейсу могут потребоваться десятки или сотни миллисекунд. Однако при таком подходе трассировки не передаются непрерывно, а только когда генерируется предупреждение и только небольшая трассировка самых последних событий. Предупреждения предназначены только для необычных, но важных вещей, например, если в коде приложения была обнаружена ошибка, такая как неудачная проверка работоспособности, аппаратный сбой или сброс сторожевого таймера.

Любое подключенное к Интернету устройство должно быть защищено. Поэтому важно не вводить никаких новых векторов атак. Мы решаем эту проблему в DevAlert, полагаясь на существующее облачное подключение, а не вводя новое подключение. Это усиливает безопасность AWS и других ведущих поставщиков IoT / облачных вычислений, которые предлагают проверенные SDK для подключения к облаку, которые защищены в соответствии с передовыми практиками, такими как аутентификация устройства с использованием сертификатов X.509 и шифрованная связь с использованием TLS. Это сделало бы загрузку DevAlert такой же безопасной, как и данные обычных приложений Интернета вещей, а для дополнительной безопасности ему потребуется только односторонняя связь:он никогда не прослушивает входящие сообщения.

При таком подходе оповещения загружаются в ту же облачную учетную запись, которая обычно используется устройством, и с тем же уровнем безопасности. Попав в облако, небольшая часть данных предоставляется облачной службе. Сюда не входят фактические данные трассировки, которые могут рассматриваться как конфиденциальная информация и поэтому остаются в облачной учетной записи устройства. На рисунках 2a и 2b более подробно показаны поток данных и защитные барьеры.

Рисунок 2а. Поток данных начинается в программном обеспечении устройства, где разработчики добавляют предупреждения в исходный код. Каждое предупреждение, которое загружается в облачную учетную запись устройства, включает короткую трассировку с самыми последними событиями, предшествующими предупреждению. Наконец, подпись метаданных пересылается в облачную службу DevAlert. (Щелкните изображение, чтобы увеличить)

Рисунок 2b. Облачная служба сравнивает входящие оповещения с предыдущими оповещениями от всего парка устройств клиента и уведомляет разработчиков о любых новых проблемах. Повторяющиеся оповещения подсчитываются и сохраняются, но уведомления не отправляются. Таким образом, почтовые ящики разработчиков не переполняются, если одно и то же оповещение запускается на нескольких устройствах. (Щелкните изображение, чтобы увеличить)

Операционные расходы на получение предупреждений в облачную учетную запись обычно невысоки, хотя, естественно, они зависят от объема. Начнем с того, что до тех пор, пока не обнаружены проблемы, оповещения не отправляются. В целом, облачные провайдеры также взимают очень небольшую плату за отправку и хранение случайных предупреждающих сообщений. Большинство приложений IoT генерируют намного больше данных, что отражается в ценах на IoT / облачные сервисы. Например, отправка 1 миллиона сообщений MQTT в ядро ​​AWS IoT стоит 1 доллар США.

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

Отправка обновлений по беспроводной сети для исправления обнаруженных ошибок потенциально может стоить немного дороже, поскольку вам нужно передать гораздо больше данных на все устройства. AWS предоставляет пример ценообразования, в котором стоимость обновления парка из 600 000 устройств составляет 1275 долларов США. Тем не менее, это не очень дорого по сравнению с затратами на то, чтобы ошибка оставалась нефиксированной - это ухудшило качество обслуживания клиентов, более низкие оценки продукта, снижение продаж или даже несчастные случаи и судебные иски.

DevOps для встраиваемой разработки
Предоставление вашим IoT-устройствам возможности «звонить домой» в случае проблем с программным обеспечением имеет значительный потенциал. Прямая осведомленность об ошибках и подробная диагностика создают цикл обратной связи между разработчиками и развернутым кодом, позволяя разработчикам быстрее исправлять ошибки и быстрее выпускать обновленное микропрограммное обеспечение - см. Рисунок 3. Эта так называемая философия DevOps долгое время была стандартом в разработке мобильных приложений. и облачные приложения, а с появлением безопасных облачных платформ IoT стало возможным, чтобы встраиваемая разработка работала таким же образом.

Рисунок 3 На панели инструментов DevAlert в Tracealyzer перечислены самые последние оповещения и трассировки, о которых сообщалось.
(Щелкните изображение, чтобы увеличить)

С точки зрения бизнеса, мониторинг в стиле DevOps приводит к меньшему количеству недовольных клиентов, поскольку меньше конечных пользователей будут затронуты ошибками в производственном коде. Большинство встроенных программ содержат некоторые пропущенные при выпуске ошибки, несмотря на все усилия по проверке, но обычно они не обнаруживаются непосредственно для всех. Часто есть время, чтобы решить проблему, прежде чем это коснется многих клиентов, если вы узнаете об этом заранее. В идеале разработчики должны быть уведомлены в течение нескольких секунд о самом первом предупреждении, а предоставленная диагностика трассировки позволяет быстро анализировать и исправлять. Затем разработчики могут отправить автоматическое обновление по беспроводной сети, чтобы устранить проблему. Мгновенная диагностика и отслеживание могут значительно сократить время ремонта и минимизировать количество затронутых клиентов.

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

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

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

В целом, использование программной трассировки и облачных предупреждений на развернутых устройствах дает большие преимущества и не является сложной задачей. Однако для того, чтобы полностью использовать рабочий процесс в стиле DevOps, необходимы возможности для беспроводных обновлений и гибкая организация разработки, которая понимает ограничения тестирования программного обеспечения и важность постоянного улучшения даже после выпуска.