Распутывание скрытых проблем: реально

Джейкоб Бенинский | 30 августа 2023 г.

Сегодня одной из наиболее недооцененных возможностей разработки встроенного программного обеспечения является отслеживание приложений операционной системы реального времени (RTOS). ОСРВ нашли применение практически во всех устройствах Интернета вещей и во многих автономных устройствах. Когда разработчики тестируют свои системы, они часто смотрят на поведение внешней системы, чтобы оценить, правильно ли она работает. Проблема с этим подходом заключается в том, что многие системы имеют поведение, которое должно происходить детерминировано за время менее 50 миллисекунд. Без отслеживания вы можете поверить, что система работает, но, оказавшись в руках ваших клиентов, обнаружите, что она неисправна и не работает правильно ни при каких обстоятельствах. В этом посте я расскажу вам о некоторых возможностях трассировки и поделюсь примерами того, как я обнаружил проблемы, которые, возможно, не были обнаружены, пока устройства не были в полевых условиях.

Прежде чем мы рассмотрим несколько конкретных примеров, полезно понять, как отслеживать приложение RTOS. Обычно существует две части: библиотека рекордера, которая отслеживает события в приложении RTOS на целевом объекте, и графический интерфейс визуализации, который получает и отображает данные о событиях. Несколько инструментов позволяют разработчикам собирать эти данные, например Percepio Tracealyzer, SEGGER SystemView и Microsoft Azure RTOS TraceX. Есть много других, но используемый вами инструмент будет зависеть от используемой вами ОСРВ и ваших потребностей в визуализации.

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

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

Если вы посмотрите на рисунок 1 ниже, вы увидите представление о загрузке ЦП системы. Каждый цвет на диаграмме — это отдельная задача. По оси X — время, а по оси Y — загрузка ЦП. Похоже ли это на проверенную систему, готовую перейти в руки клиентов?

Рис. 1. Пример графика использования ЦП, на котором загрузка ЦП все время достигает 100%.

К сожалению, рассматриваемая система использовала 100% ресурсов ЦП. При более внимательном рассмотрении выяснилось, что у него не были соблюдены критические сроки и он не работал детерминированно. Человеческое наблюдение было бесполезным для обнаружения этих проблем путем отслеживания приложения. Если бы продукт поставлялся таким образом, у клиентов были бы проблемы. Проведя несколько простых трассировок, мы смогли увидеть проблему и исправить ситуацию. Копнув немного глубже, мы выявили несколько мелких причин, на устранение которых ушло менее полдня, и в результате загрузка ЦП изменилась с рисунка 1 до чего-то вроде рисунка 2.

Рисунок 2. Пример графика использования ЦП, более подходящего для производственной системы.

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

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