Отладка встроенных систем — стратегии и инструменты




Ежегодно журнал Embedded System Design фиксирует высокий спрос на инструменты отладки в своем ежегодном обзоре. Количество респондентов, требующих улучшения, стабильно составляет около 32% в течение последних трех лет. Интересным фактом является то, что потребность в изменениях в инструментах программирования снизилась с 25% до 10%. Ответ на вопрос, почему это происходит, искать не приходится — те же респонденты признают, что этап тестирования и устранения неполадок проекта занимает 24% времени. Кстати, можно заметить, что используемых в настоящее время инструментов управления проектами уже недостаточно.

Отладка встроенных систем — стратегии и инструменты

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

Хорошо подготовленное программное обеспечение не обеспечивает автоматически правильную работу всего устройства. Ошибки могут возникать, например, из-за определенных условий работы, и их невозможно найти только с помощью программных средств отладки, особенно во встроенных системах. Для отладки встроенных систем тестирования и устранения неполадок применяют отладочную плату. На базе отечественной системы на кристалле Байкал-Т построена отладочная плата BFK 3.1, на сайте baikalelectronics.ru можно прочитать о плате подробнее. Использование BFK 3.1 позволяет проводить прототипирование и отладку программно-аппаратных решений на базе Байкал-Т (BE-T1000) и сократит срок запуска изделий в серийное производство.

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

Если требовалось только найти и исправить ошибки в программном обеспечении, тогда было бы достаточно симуляторов, позволяющих отслеживать выполнение отдельных инструкций. Они позволяют остановить моделирование в любой момент и подробно узнать состояние регистров и памяти микропроцессора. Это обеспечивает достаточное понимание работы микропроцессора и позволяет искать все нарушения (например, логические ошибки). Симуляторы доступны для большинства микропроцессоров, производимых сегодня. К сожалению, невозможно показать все зависимости в полной системе. Более того, расширение моделирования другими явлениями, такими как задержка памяти, взаимодействие с периферийными устройствами и датчиками или исполнительными механизмами, увеличивает сложность симулятора и значительно замедляет его.

Решения от таких компаний, как VAST (Virtual-System-Prototype Tool) или Virtutech (виртуальная платформа Simics) являются расширением традиционного моделирования. Предоставляемые инструменты включают модуль обработки инструкций микропроцессора и симулятор, который позволяет изучать взаимодействия между различными компонентами системы. Это позволяет разрабатывать программное обеспечение до производства прототипов и позволяет разработчикам участвовать в работе по обеспечению целостности всей системы.

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

Операционные системы

В последнее десятилетие наблюдается меньший интерес к операционным системам, требующим покупки лицензий, в пользу бесплатных решений, таких как Linux. Преобразование коммерческих систем в бесплатные системы с открытым исходным кодом позволяет значительно сэкономить. Аналогичные тенденции наблюдаются в случае инструментов разработки для встраиваемых систем, которые все чаще основываются на движке бесплатного пакета Eclipse. Помимо снижения затрат, это упрощает инструменты настройки, используемые конечными пользователями. Это также избавляет от необходимости создавать несколько приложений с нуля, поскольку они уже присутствуют в заимствованном коде Eclipse. Аналогичное сокращение затрат сложнее с инструментами отладки, но это не значит, что они не обходятся дешево. Многие производители предоставляют небольшие оценочные комплекты стоимостью менее 100 долларов, чтобы вы познакомились с работой того или иного компонента. Также несложно купить комплекты за несколько сотен долларов, которые десять лет назад стоили намного дороже.

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

Парадоксально, но увеличение цены микропроцессора не может быть оправдано наличием диагностического модуля, несмотря на его несомненную сложность, из-за того, что эта функция используется не в конечном продукте, а только производителем устройства при этап тестирования. Кроме того, микропроцессоры ARM, оснащенные функцией ETM (Embedded-Trace Macrocell), помогают разработчикам устранять неисправности (включая Cortex-M3). Они позволяют просматривать состояние микропроцессора в режиме реального времени. Это позволяет выполнять инструкции в обратном порядке, аналогично программам моделирования. Поэтому после возникновения ошибки вы можете вернуться к ее источнику на следующих шагах. Этот режим выполнения инструкций обеспечивается программой Multi Time Machine компании Green Hills Software.

Программное обеспечение Multi Time Machine от Green Hills Software позволяет переключаться между отладкой в ​​системе и работой с симулятором.Из-за потребности в стандартизации методов отладки микропроцессоров, используемых во встроенных системах , стандарт IEEE-ISTO 5001-2003 был разработан Forum Nexus 5001, который объединяет производителей полупроводников, компании, создающие инструменты программирования, и представителей отрасли. По общему признанию, на первом этапе это было решение для промышленной автоматизации, но оно развилось до такой степени, что теперь определяет универсальный интерфейс для инструментов программирования и отладки. Интересно, что этот стандарт имеет открытый исходный код и его можно бесплатно загрузить с веб-сайта Nexus 5001 Forum.

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

Пакеты инструментов

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

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

Взаимодействие с окружающей средой

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

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

Высокий цейтнот, который сопровождает работу над новыми продуктами, не облегчает эту задачу, и в основном используются самые простые инструменты. Более продвинутые изучаются постепенно, при выполнении последующих заданий. Эту проблему заметили, среди прочего, Green Hills Software, которая добавила настройки по умолчанию в среду Multi Time Machine, что позволяет проводить оптимальное тестирование без необходимости вникать в секреты конфигурации. Это дает ощутимые преимущества с точки зрения экономии времени разработчиков.

Оценка сроков реализации проекта

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

Один из методов основан на модели Кокомо (конструктивно-стоимостная модель), которая представляет собой алгоритм оценки стоимости проекта. Математические формулы, используемые в Cocomo, были разработаны на основе исторических данных, собранных в ходе реализации различных проектов в прошлом. Алгоритм был опубликован в 1981 году инженером-программистом Барри Боем. Также доступна расширенная модель — Cocomo II, которая включает исправления, позволяющие оценивать, помимо затрат, еще и рабочее время дизайнеров, и помогать создавать список задач. Он доступен на сайте Университета Южной Калифорнии.

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

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

После создания списка задач и назначения им времени, отведенного на выполнение, появляется возможность отслеживать текущий прогресс и сравнивать их с оценками (независимо для каждого дизайнера). Здесь есть еще одно преимущество, помимо постоянного обновления прогнозов — этот метод предоставляет данные, необходимые для статистического анализа Монте-Карло. Благодаря этому становится возможным определить период времени, в течение которого проект будет завершен, и облегчает изменение задач, поставленных перед командой, и расстановку приоритетов в работе. Более того, вы можете проверить, как изменится срок завершения работы после добавления новых или удаления ненужных функций устройства.

Производители оценочных комплектов также начинают видеть возрастающую нагрузку на дизайнеров и предпринимают соответствующие шаги. К ним относятся возможность подачи питания через порт USB и введение более простых (или беспроводных) интерфейсов связи, используемых для обмена данными между оценочным комплектом и компьютером. Во многих случаях доступны демонстрационные программы для проверки правильности работы всех компонентов шпатлевки. Крупные компании, такие как Texas Instruments, стремятся разрабатывать инструменты, аналогичные платформе Intel, на которой работает Windows. Это сделает процесс разработки программного обеспечения максимально простым, интуитивно понятным и быстрым в освоении.

Среда LabVIEW с характерным графическим языком программирования и широкими возможностями визуализации.Micrium также оправдывает ожидания дизайнеров, оказывая помощь на этапе отладки. Предлагаемое решение MC / Probe позволяет визуализировать состояние системы. Он состоит из двух частей: программного обеспечения для ПК для анализа и представления данных и программного модуля, загружаемого в тестируемое устройство. Этот модуль отвечает за управление пространством ввода-вывода микропроцессора, управление его ресурсами и связь с компьютером. Этот метод сложно назвать неинвазивным, но он позволяет тестировать микропроцессор в реальном времени, не прерывая работу.

Стоимость инструмента MC / Probe составляет около 1000 долларов США. Также на рынок средств отладки выходят такие гиганты, как National Instruments . Компания предлагает среду LabVIEW (Laboratory Virtual Instrument Engineering Workbench), которая отличается графическим языком программирования и широкими возможностями визуализации.

LabVIEW включает встроенные функции анализа и измерения для различных приложений, предоставляя разработчикам широкий выбор при создании программ тестирования. В результате они всегда адаптируются к текущим потребностям. Стоит отметить, что пакет LabVIEW также используется в системах, которые выполняют конвейерную обработку данных. Стоимость набора интегрированных программных и аппаратных средств начинается примерно от 1000 долларов США, но может легко достигать 10 000 долларов США, когда требуется большой набор специализированных дополнительных модулей.

Пример LabVIEW показывает, что дизайнеры хотят платить только за те компоненты, которые им нужны. Это представляет проблему для компаний, производящих средства отладки. Они должны учитывать необходимость предоставления модульного пакета, который может включать только элементы, выбранные покупателем. Более того, ожидания часто очень расходятся, поскольку некоторые дизайнеры готовят программное обеспечение для выбранной операционной системы и не вдаваться в подробности архитектуры. В такой ситуации просматривать содержимое регистров нежелательно. Нетрудно представить обратную ситуацию, при которой программное обеспечение создается под конкретный микропроцессор и оптимизируется на языке низкого уровня, а предварительный просмотр всех ресурсов необходим. Также существует проблема с определением, какие переменные и регистры нужно отслеживать, а какие можно опустить.

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

UML-модели

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

Знания содержимого переменных и регистров микропроцессора в некоторых случаях может быть недостаточно для тщательной интерпретации работы системы. Использование модели, подготовленной на UML (Unified Modeling Language), позволяет лучше выделить взаимодействия, происходящие в системе между отдельными функциональными блоками. На этапе тестирования целостности всей системы он позволяет легко определить, какие сигналы должны появиться в каждом месте системы.

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

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

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

Симулятор HILS

Идея моделирования в цикле HILS представлена ​​на рисунке. Устройство, обеспечивающее такое моделирование, чаще всего состоит из аналого-цифровых и цифро-аналоговых преобразователей, портов ввода-вывода, генераторов ШИМ и т. д. Наиболее важным элементом, однако, является микропроцессор, роль которого сводится к сбору входных сигналов, преобразованию их и отображать соответствующие выходные сигналы. Выходы тестируемого устройства подключены к входам, а входы тестируемой системы — к выходам.

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

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

На практике количество итераций должно быть в 5-10 раз больше, чем на проектируемом устройстве. Поэтому стоит вложиться в вычислительный блок и обеспечить максимально возможную скорость обработки данных. Итерация — это фактически процесс выборки аналогового сигнала, который появляется на входе устройства. Классический критерий Найквиста (теорема выборки) гласит, что она должна быть вдвое больше частоты высшей гармоники. Фактически, спектр сигнала не может быть ограничен определенной полосой, и чем меньше период дискретизации, тем точнее воспроизводится исходный сигнал.

Стоит спросить себя, что отличает «типичное» моделирование от работы с HILS. Первым отличительным признаком является наличие реальных сигналов на входе устройства, в отличие от моделирования, ограниченного представлением графика. Более того, моделирование не выполняется в реальном времени, поскольку время вычислений зависит от вычислительной мощности компьютера. Третье преимущество модуля HILS заключается в том, что прототип работает в «реальной» среде, аналогичной той, в которую он будет помещен позже.

Моделирование HILS позволяет записывать сигналы, присутствующие на входах и выходах тестируемого устройства. После подключения к компьютеру состояния входов и выходов могут быть сохранены после каждой итерации. Данные могут регистрироваться в виде файла на жестком диске или в оперативной памяти. Более того, можно запустить или остановить процесс сбора результатов измерений и, таким образом, избежать сбора нерелевантной информации. Возможность загружать данные в Matlab или Excel для анализа и оценки также очень ценна. При текущем развитии полупроводниковой промышленности и свободном доступе к выделенным контроллерам Ethernet ничто не препятствует непрерывной регистрации таким образом.

Некоторые программные пакеты (например, LabVIEW) поддерживают интерфейс Ethernet и позволяют сохранять, обрабатывать и визуализировать передаваемые данные с помощью графического языка программирования. Модули HILS могут оказаться отличным решением для тестирования встроенных систем. К сожалению, у них есть свои ограничения. Одна из них — невозможность остановить работу тренажера. В принципе, можно остановить микропроцессор встроенной системы, но модуль HILS по-прежнему будет выполнять свою работу — состояния ввода будут все время меняться.

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

При реализации модели UML «вручную» помните, что тип и количество требуемых тестовых функций зависит от сложности проекта, метода тестирования, операционной среды, доступной памяти и времени тестирования. Необходимо различать переменные, атрибуты, системные входные данные и контрольные точки, что требует реализации ряда инструментов для проверки каждого из этих элементов. Инструмент тестирования моделей UML разделен на две части. Первый — это DVUI (пользовательский интерфейс динамической проверки), отвечающий за отображение информации, полученной из встроенной системы, и выполнение команд. Вторая часть обеспечивает обмен информацией между DVUI и отлаживаемым программным обеспечением.

Связь с модулем, отвечающим за визуализацию данных, осуществляется через такие интерфейсы, как RS-232, TCP / IP и т. Д. Вам также понадобится промежуточный модуль, отвечающий за организацию тестовой информации, взаимодействие с тестовыми функциями, присутствующими в коде приложения, информирование DVUI о путях выполнения программы и обеспечение контроля выполнения программы. Видимость состояния системы имеет решающее значение при проверке целостности проекта. В этом случае бесценно иметь возможность читать данные, содержащиеся в отдельных объектах (экземплярах классов), что означает необходимость обеспечения доступа к ним с помощью DVUI. Список с элементами, определяющими состояние системы, становится незаменимым. Его можно получить, обогатив конструкторы классов инструкциями по сбору такой информации в специально подготовленном для этой цели списке. Когда объект больше не нужен и выгружается, вызывается деструктор, чтобы удалить его из списка.

Для отображения значений отдельных переменных необходимо преобразовать их в строку в коде ASCII. Этого можно достичь аналогично Java, где для выполнения преобразования используется метод toString. После преобразования данные могут быть отправлены в модуль DVUI и представлены лицу, тестирующему устройство. Легко представить себе противоположную ситуацию, когда разработчик должен изменить значение выбранного системного атрибута; затем используется обратный метод fromString.