Применение анализа времени выполнения в худшем случае для проектирования задач Rtos

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

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

В этом всеобъемлющем руководстве рассматриваются принципы, методологии и практические применения анализа WCET в проектировании задач RTOS, предоставляя инженерам встроенных систем знания, необходимые для создания надежных, предсказуемых систем в реальном времени.

Анализ времени выполнения худшего случая

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

Основополагающее значение WCET

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

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

WCET в критических системах безопасности

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

DO-178C устанавливает необходимость анализа WCET, подчеркивая его в §6.3 (Обзоры и анализы программного обеспечения), §6.3.4 (Обзоры и анализ исходного кода) и §11.20 (Обзоры выполнения программного обеспечения). Аналогичным образом, руководство DO-178C для аэрокосмической промышленности и стандарт ISO 26262 для автомобильной промышленности требуют оценки WCET вашего приложения и его критических подпрограмм в качестве доказательства для поддержки вашего аргумента сертификации.

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

Теоретические основы и вызовы

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

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

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

Методологии анализа CCET

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

Методы статического анализа

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

Статический анализ WCET-оценка была разработана как альтернатива оценке на основе измерений. Основным преимуществом статического анализа является то, что не нужно брать измерения из реальной цели, сводя к минимуму затраты и усилия. Такой подход конструирует подробные модели как потока управления программным обеспечением, так и поведения аппаратного времени, а затем объединяет эти модели для получения границ времени.

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

Процесс статического анализа обычно включает в себя несколько ключевых компонентов:

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

Анализ на основе измерений

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

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

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

Поэтому на практике оптимизм подхода, основанного на измерениях, снижается путем добавления «маржи безопасности», например, добавления 20% к самому продолжительному наблюдаемому времени исполнения.Однако определение соответствующей маржи безопасности остается проблемой, поскольку она должна сбалансировать консерватизм с практичностью.

Гибридный анализ подходов

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

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

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

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

Применение WCET-анализа для проектирования задач RTOS

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

Основы и временные требования RTOS

Задача — это часть кода, которая должна выполняться в рамках одного потока выполнения. Задача выдает процессору последовательность заданий, которые стоят в очереди и выполняются. Время, затрачиваемое заданием на активное использование ресурсов процессора, — это время его выполнения.

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

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

Расписание задач и WCET

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

Значения WCET информируют о решениях по планированию, в то время как политика планирования влияет на фактическое время выполнения задач с помощью таких факторов, как:

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

WCET Анализ ядер РТОС

Анализ времени выполнения в худшем случае (WCET) является одной из основных задач в валидации времени жестких систем реального времени. В сложных системах с операционными системами реального времени (RTOS) временные свойства системы определяются как приложениями, так и RTOS. Традиционно анализ WCET в основном касается прикладных программ, при этом важно знать, ведет ли RTOS также своевременно предсказуемое поведение.

Ядро RTOS вносит свой вклад в общее системное время с помощью различных сервисов и операций:

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

Приоритизация задач и распределение ресурсов

Анализ WCET напрямую влияет на то, как расставляют приоритеты задачи и как распределяются системные ресурсы. С точными оценками WCET разработчики системы могут:

Алгоритмы планирования Rate Monotonic Analysis (RMA) и Earliest Deadline First (EDF) полагаются на значения WCET для определения планируемости. Без точных оценок WCET эти анализы не могут обеспечить значимые гарантии поведения системы.

Внедрение анализа WCET на практике

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

Выявление критических задач для анализа

Не все задачи в ОСВТ требуют одинакового уровня анализа времени. Первым шагом в практической реализации ВСЕТ является определение того, какие задачи действительно являются критическими и требуют детального анализа. Критические задачи обычно включают:

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

Выбор инструментов анализа WCET

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

aiT — это инструмент WCET для промышленного использования. Информация, необходимая для оценки WCET, такая как вычисленные цели ветвей и границы контуров, определяется статичным анализом. Инструмент aiT от AbsInt широко используется в аэрокосмической и автомобильной промышленности для статического анализа WCET.

Уникальный инструмент анализа гибридных временных рамок Rapita называется RapiTime и идентифицируется FAA как «пример зрелого инструмента» для динамического анализа временных рамок. RapiTime представляет собой подход гибридного анализа и особенно полезен для сложных аппаратных платформ.

Другие известные инструменты включают в себя:

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

Подготовка кода для анализа WCET

Структура кода существенно влияет на осуществимость и точность анализа WCET. Следование передовым методам разработки кода в режиме реального времени способствует более эффективному анализу:

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

Статический анализ WCET

Рабочий процесс статического анализа обычно следует следующим шагам:

Шаг 1: Создайте и подготовьте исполняемый
Составьте код с соответствующими настройками компилятора, обычно отключая агрессивные оптимизации, которые усложняют анализ времени.

Шаг 2: Предоставить информацию о потоке
Аннотировать код с помощью таких фактов потока, как границы цикла, неосуществимые пути и частоты выполнения. Эта информация помогает инструменту анализа понять поведение программы, которое не может быть автоматически определено.

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

Шаг 4: Анализ выполнения
Выполните инструмент анализа WCET на подготовленном исполняемом файле. Инструмент выполнит анализ потока управления, анализ времени и анализ пути для вычисления оценок WCET.

Шаг 5: Результаты обзора
Исследуйте результаты анализа, включая вычисленное значение WCET, критический путь через код и любые предупреждения или ошибки.

Шаг 6: Итеративное и уточнение
На основе результатов анализа усовершенствовать структуру кода, добавить недостающие аннотации или отрегулировать аппаратные модели по мере необходимости. Повторить анализ до получения удовлетворительных результатов.

Проведение измерительного анализа

Для анализа WCET на основе измерений процесс значительно отличается:

Шаг 1: Инструментальный код
Добавить приборы для захвата информации о времени во время выполнения. Это может включать в себя вставку считываний временной метки в ключевые точки кода или использование возможностей отслеживания аппаратного обеспечения.

Шаг 2: Разработка тестовых случаев
Создание комплексного набора тестов, предназначенного для выполнения наихудших сценариев выполнения.Это требует глубокого понимания кода и тщательного рассмотрения вводимых комбинаций, которые приводят к максимальному времени выполнения.

Шаг 3: Выполнить на целевом оборудовании
Запустить инструментальный код на фактическом целевом оборудовании с разработанными тестовыми кейсами. Собрать измерения времени для всех исполняемых путей.

Шаг 4: Анализ измерений
Обработка собранных данных о времени выполнения для определения самого продолжительного наблюдаемого времени выполнения.Применить статистический анализ для понимания изменчивости времени и выявления выпадающих значений.

Шаг 5: Применить маржу безопасности
Добавить соответствующий запас прочности к самому продолжительному наблюдаемому времени для учета ненаблюдаемых наихудших сценариев. Маржа должна быть обоснована на основе охвата испытаниями и системной критичности.

Шаг 6: Проверка покрытия
Проверка того, что тестовые случаи достигли адекватного покрытия путей выполнения и аппаратных состояний. Используйте инструменты покрытия кода для идентификации непроверенных путей.

Внедрение гибридного анализа

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

Гибридный подход к рабочему процессу сочетает в себе элементы как статического, так и измерительного анализа:

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

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

Продвинутые темы в анализе WCET

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

Многоядерные и многопроцессорные вызовы

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

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

Многоядерные процессоры вводят несколько источников временных помех:

  • Разделенная борьба кэша: Несколько ядер, конкурирующих за общие уровни кэша
  • Спор о шине памяти: Одновременный доступ к памяти из разных ядер
  • Накладные расходы на протокол согласования: Для кэширования трафика согласованности между ядрами
  • Арбитраж с использованием общих ресурсов: Доступ к общим периферийным устройствам и I/O
  • Межъядерная связь: Передача сообщений и синхронизация накладных расходов

Для решения этих проблем требуются специализированные методы анализа, которые могут связывать помехи от совместно выполняемых задач. Подходы включают мультиплексирование с разделением по времени общих ресурсов, статическое разделение ресурсов и методы анализа WCET, учитывающие помехи.

Сложность анализа кэша

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

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

  • Классификация каждого доступа к памяти как всегда-хит, всегда-недостающий или неопределенный
  • Моделирование политики замены кэша (LRU, FIFO, псевдо-LRU и т.д.)
  • Анализ кэш-конфликтов между различными доступами к памяти
  • Учет загрязнения кэша от прерываний и упреждения
  • Обработка многоуровневых иерархий кэша

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

Трубопровод и ветвь прогнозирования эффектов

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

Современные процессоры используют сложные методы для повышения средней производительности, но эти функции усложняют анализ времени:

  • Инструкционные конвейеры: Несколько инструкций на разных этапах выполнения одновременно
  • Предсказание отрасли: Спекулятивное исполнение на основе прогнозируемых результатов ветви
  • Исполнение в непорядке: Инструкции, выполняемые в ином порядке, чем порядок программы
  • Специальное исполнение: Выполнение инструкций до того, как узнать, нужны ли они
  • Сверхкальярное исполнение: Несколько инструкций, выдаваемых за цикл

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

Обработка перерывов и упреждения

В средах RTOS задачи могут прерываться задачами более высокого приоритета или прерываниями обслуживания (ISR). Это упреждение влияет на WCET несколькими способами:

  • Прямое упреждение накладных расходов: Время, потраченное на сохранение и восстановление контекста
  • Задержка, связанная с кэшем (CRPD): Дополнительный кэш пропускает после возобновления из-за загрязнения кэша
  • Накладные расходы на промывку трубопровода: Очистка конвейера инструкций во время переключения контекста
  • TLB и ветвь предиктора загрязнения: Потеря состояния прогноза в переводе с обратной стороны

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

Вероятностный анализ WCET

Для систем, где детерминированные границы WCET слишком пессимистичны или их невозможно получить, вероятностный анализ WCET (pWCET) предлагает альтернативный подход. Вместо предоставления одного наихудшего случая, анализ pWCET производит распределение вероятностей времени выполнения.

Этот подход особенно актуален для систем с рандомизированными аппаратными функциями или при работе с чрезвычайно сложными архитектурами.Распределение pWCET позволяет системным дизайнерам принимать решения, основанные на риске, о временной марже и распределении ресурсов.

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

Интеграция с рабочими процессами развития

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

Интеграция раннего проектирования

Соображения WCET должны влиять на решения по архитектуре системы с самых ранних этапов проектирования:

  • Установить временные бюджеты основных функций системы в ходе анализа требований
  • Выберите аппаратные платформы с предсказуемостью времени
  • Разработка архитектуры программного обеспечения для облегчения анализа WCET
  • Выделение синхронизации для каждой задачи на основе предварительных оценок
  • Определить потенциальные узкие места во времени до детального внедрения

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

Непрерывная интеграция и автоматический анализ

Современные методы разработки подчеркивают непрерывную интеграцию и автоматизированное тестирование. Анализ WCET может и должен быть частью этого автоматизированного рабочего процесса:

  • Интеграция инструментов анализа WCET в систему сборки
  • Автоматический анализ времени выполнения каждого кода фиксировать или ночной сборки
  • Отслеживание тенденций WCET с течением времени для выявления регрессий времени
  • - генерировать предупреждения, когда оценки WCET превышают выделенные бюджеты;
  • Ведение базы данных результатов ВСЕТ для исторического анализа

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

Документация и прослеживаемость

Для систем, имеющих критически важное значение для безопасности, подлежащих сертификации, необходима полная документация анализа WCET:

  • Методология анализа документов и используемые инструменты
  • Запись всех предположений и аннотаций, сделанных в ходе анализа
  • Поддерживать прослеживаемость между требованиями, кодом и результатами анализа времени
  • Проверка и проверка документов по оценкам ВКЭТ
  • Обоснование пределов безопасности и консервативных предположений

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

Проверка и проверка оценок WCET

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

Стратегии тестирования и моделирования

Оценки WCET обычно включают в себя несколько дополнительных подходов:

  • Стресс-тестирование: Выполняйте систему в условиях максимальной нагрузки для наблюдения за фактическим поведением времени
  • Обоснованное тестирование: Тест с входными значениями на крайних значениях допустимых диапазонов
  • Введение ошибки: Введение неисправностей для проверки поведения системы в условиях ошибки
  • Программное обеспечение в цикле моделирования: Тест с реалистичными внешними стимулами и временем
  • Статистический анализ: Анализ временных измерений для проверки их соответствия прогнозируемым границам

Цель состоит в том, чтобы обрести уверенность в том, что оценки ВСЕТ являются безопасными (не недооцененными) и достаточно жесткими (не чрезмерно пессимистичны).

Сравнение методов анализа

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

Когда различные методы дают существенно разные оценки WCET, расследование оправдано, чтобы понять источник несоответствия.

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

Мониторинг и проверка времени выполнения

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

  • Мониторы времени выполнения, которые отслеживают фактическое время выполнения задачи
  • Нарушения сроков регистрации для пост-анализа
  • Используйте таймеры для обнаружения задач, которые превышают выделенное время
  • Собрать статистику времени для долгосрочного анализа тенденций
  • Реализуйте грациозные стратегии деградации при возникновении нарушений сроков

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

Стратегии оптимизации для сокращения ВСЕТ

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

Оптимизация кодового уровня

Несколько методов кодового уровня могут уменьшить WCET:

  • Раскрутка петли: Уменьшите накладные расходы на цикл, выполняя несколько итераций за цикл цикла
  • Функциональное наложение: Устранить накладные расходы на вызовы функций для небольших, часто называемых функциями
  • Уменьшение ветвления: Минимизируйте условные ветви, которые вызывают киоски трубопровода
  • Оптимизация структуры данных: Устройте данные для улучшения локальности кэша
  • Алгоритмические улучшения: Заменить алгоритмы с лучшей сложностью в худшем случае

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

Соображения по оптимизации компилятора

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

Для систем, имеющих критически важное значение для безопасности, рассмотрим:

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

Оптимизация уровня аппаратного обеспечения

Конфигурация оборудования может существенно повлиять на WCET:

  • Заблокировка кэша: Заблокировать критический код и данные в кэше для устранения промахов кэша
  • Память скрещпада: Используйте явно управляемую память вместо кэша
  • Отключение спекулятивных функций: Отключить предсказание ветвей и спекулятивное исполнение
  • Планы доступа к памяти: Устройте макет памяти для минимизации конфликтов доступа
  • Выбор процессора: Выбор процессора с более предсказуемыми характеристиками времени

Эти аппаратные подходы к торговле средней производительностью для повышения предсказуемости сроков и более жестких границ WCET.

Тематические исследования и реальные приложения

Понимание того, как анализ WCET применяется в реальных системах, дает ценную информацию о практических задачах и решениях.

Управление автомобильным двигателем

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

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

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

Авионика Flight Control

Системы управления полетами воздушных судов представляют собой одни из самых сложных приложений для анализа WCET. Эти системы должны соответствовать требованиям сертификации DO-178C и работать с чрезвычайно высокой надежностью.

К числу проблем относятся:

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

Статические инструменты анализа WCET, такие как aiT, обычно используются в авионике, обеспечивая детерминированные границы, необходимые для сертификации. Анализ должен учитывать все возможные режимы отказа и их временные последствия.

Управление медицинскими приборами

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

Анализ WCET для медицинских устройств должен учитывать:

  • Безопасность пациентов как первостепенная забота
  • Требования к регулированию (FDA, IEC 62304)
  • Работа с батарейным питанием с энергетическими ограничениями
  • Ненадежное поведение при любых условиях

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

Будущие тенденции и направления исследований

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

Машинное обучение и ИИ в WCET-анализе

Предлагается расширение гибридной методологии, реализующей предикторную модель с использованием машинного обучения (ML). Этот новый подход оценивает WCET на более мелких объектах кода, так называемых гибридных блоках, на основе программных и аппаратных функций. В результате гибридный анализ на основе ML обеспечивает понимание WCET на ранней стадии процесса разработки и уточняет его оценку, когда доступны более подробные функции.

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

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

Предсказуемые временем архитектуры

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

  • Предсказуемая политика замены кэша
  • Мультиплексированные общие ресурсы с разделением времени
  • Ограниченное поведение трубопровода
  • Ликвидация спекулятивного исполнения

Такие проекты, как архитектура PRET (Precision Timed) и процессор T-CREST, демонстрируют этот подход. Хотя эти процессоры могут жертвовать производительностью в среднем случае, они предлагают гораздо более жесткие границы WCET и более простой анализ.

Композиционный анализ времени

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

Такой подход позволяет:

  • Повторное использование результатов анализа сроков в проектах
  • Независимая разработка и сертификация компонентов
  • Масштабируемость для очень больших систем
  • Инкрементный анализ при изменении компонентов

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

Лучшие практики и рекомендации

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

Дизайн для анализа

Наиболее эффективный способ достижения жестких границ WCET — это разработка программного обеспечения с учетом анализа:

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

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

Сохранение сроков бюджетов

Устанавливать и поддерживать временные бюджеты на протяжении всего процесса разработки:

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

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

Инвестируйте в обучение и экспертизу

Для анализа ВСЕТ необходимы специальные знания и навыки. Организации, разрабатывающие критически важные для безопасности системы реального времени, должны:

  • Обучайте разработчиков принципам программирования в реальном времени
  • Развивать собственный опыт в инструментах и методах анализа времени
  • Взаимодействие с экспертами по анализу сроков для сложных проектов
  • Участвовать в исследованиях и разработке стандартов
  • Обмен знаниями и уроками, извлеченными в рамках проектов

Инвестиции в экспертизу приносят дивиденды за счет более эффективного развития и более качественных систем.

Безопасность и практичность баланса

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

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

Цель – системы, которые являются безопасными и экономически жизнеспособными.

Заключение

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

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

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

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

Дополнительные ресурсы

Для тех, кто хочет углубить свое понимание анализа WCET и его применения в разработке RTOS, доступны многочисленные ресурсы:

  • Академические исследования: Международный семинар по анализу времени выполнения худших случаев (WCET Workshop) ежегодно публикует передовые исследования
  • Стандарты промышленности: DO-178C для авионики и ISO 26262 для автомобилей обеспечивают руководство по требованиям анализа времени
  • Продавцы инструментов: Такие компании, как AbsInt, Rapita Systems и LDRA, предлагают комплексную документацию и обучение своим инструментам анализа WCET.
  • Онлайн-сообщества: Форумы и списки рассылки, посвященные системам реального времени, предоставляют возможности учиться у практиков.
  • Профессиональные организации: Группы по особым интересам IEEE и ACM сосредоточены на системах реального времени и встроенных вычислениях

Для получения дополнительной информации о разработке систем в реальном времени и разработке встроенного программного обеспечения посетите сообщество Embedded Systems Design. Дополнительные сведения о разработке программного обеспечения, имеющего критически важное значение для безопасности, можно найти в клубе критических систем . Сеть передового опыта ARTIST предоставляет обширные ресурсы по проектированию и анализу встроенных систем.

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