Проектирование систем жесткого реального времени

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

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

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

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

Учет особенностей жестких систем реального времени

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

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

• точное определение требований приложения по распределению времени для каждого объекта.

• определение относительной важности каждого объекта для успешного функционирования приложения.

• точное определение и использование объектов контроля ресурсов.

• переход к наиболее подходящей для планировки и распределения времени программной архитектуре.

Кроме того, методы проектирования должны допускать влияние планировки на проект как можно раньше.

Жизненный цикл жестких систем реального времени

Наш подход заключается в разделении архитектурного плана на две фазы:

• логическая архитектура;

• физическая архитектура.

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

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

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