Software & Systems

Интенсивное внедрение встроенных компьютерных систем в конструкции современных автомобилей с соответствующим расширением производства программных продуктов, автомобильных приложений, обеспечивающих функционирование таких систем, вызвало появление стандартов OSEK/VDX, регламентирующих программные и сетевые интерфейсы для автомобильной электроники [1,2]. Центральное место в ряду этих стандартов занимает спецификация OSEK/VDX OS (далее просто спецификация), регламентирующая построение операционной системы реального времени (ОСРВ), ориентированной на поддержку автомобильных приложений.

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

-    реализуют необходимый для поддержки разрабатываемого приложения класс соответствия OSEK/VDX OS [1];

-    имеют лучшие характеристики по использованию памяти (минимизация объемов занимаемой памяти, в первую очередь оперативной);

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

В данной статье описывается подход к реализации ОСРВ, который позволяет разрабатывать их версии, отвечающие этим требованиям. Вариант ОСРВ, разработанный в соответствии с этим подходом, будем называть оптимизированной реализацией ОСРВ. Этот подход был использован в Санкт-Петербургском Центре разработки программного обеспечения "Моторолы", где в течение нескольких лет ведется разработка ОСРВ по стандарту OSEK/VDX. В статье изложены два основных принципа, характеризующих подход к разработке оптимизированной реализации ОСРВ, а именно: выбор классов соответствия для реализации и выбор модели управления задачами и обработки прерываний.

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

1.  Высокопроизводительные приложения, например системы управления двигателем, требуют использования базового класса соответствия 1 (BCC1). Объясняется это тем, что  вычисления, выполняемые в таких приложениях, связаны с обслуживанием событий, жестко синхронизированных с углом поворота распредвала двигателя. При достижении определенного угла поворота запускается задача, которая выполняет вычисление и генерирует отклик, после чего задача завершается. Несмотря на то что в приложении существует несколько таких задач, все они выполняют строго определенные функции в жесткой синхронной последовательности и не содержат гибкой логики, не требуя тем самым памяти о состоянии. Именно поэтому базовые задачи, определенные в спецификации, вполне подходят для реализации нужной функциональности. Главным требованием приложения является крайне высокая скорость переключения задач и обслуживания прерываний (в пределах нескольких микросекунд на 32-битных процессорах, работающих на частоте 40 МГц).

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

3.  Вероятно, приложения типа сетевой шлюз могут использовать также ECC1.

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

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

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

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

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

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

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

·     Принцип планирования задач первой запланирована – первой активизирована распространяется и на множественный запрос на активизацию. Следовательно, требуется поддерживать упорядоченную очередь не только для активизированных задач, но и для множественных запросов. Однако для активизированных задач спецификация накладывает ограничение на их общее количество в системе (8 или 16 в зависимости от класса соответствия), в то время как для множественных запросов такого ограничения нет. Поэтому реализация множественного запроса на активизацию приводит к неограниченному количеству активизированных задач, упорядоченных как по уровням приоритета, так и по времени активизации на каждом уровне.

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

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

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

Другим существенным свойством классов соответствия является поддержка нескольких задач на один уровень приоритета. В классах BCC1 и ECC1 этого не требуется, в то время как в классах BCC2 и ECC2 такая функциональность должна быть поддержана. Безусловно, реализация схемы одна задача на уровень приоритета может быть очень эффективна, особенно на аппаратных платформах, имеющих инструкции по манипулированию битами в слове (поиск первого левого/правого установленного бита в слове). Учитывая общее ограничение на количество активизированных задач, можно реализовать планировщик и диспетчер буквально в несколько машинных команд. Это еще один аргумент в пользу отказа от реализации BCC2 и ECC2.

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

В отличие от многих других систем аналогичного назначения ОСРВ, построенная в соответствии с требованиями спецификации, реализует только один механизм доступа к разделяемым ресурсам – OSEK Priority Ceiling Protocol. Отметим, что этот протокол (и только он и ему подобные) может быть легко реализован совместно с моделью общего стека. Обычные семафоры Дейкстры требуют использования состояния ожидания, протоколы, использующие наследование приоритетов, в том числе истинный Priority Ceiling Protocol, – перевода задачи из состояния готовности в состояние выполнения при наличии уже выполняющейся задачи более высокого приоритета. Оба эти механизма не могут быть реализованы в модели общего стека.

Следует отметить, что возможен еще один тип оптимизации модели общего стека – завершение задачи как функции языка С, то есть выполнение простого оператора return. Согласно спецификации задача может завершать только саму себя, и, если завершение происходит только в теле главной функции задачи, а не во вложенных функциях, то возможно использование механизма вызова функций для работы диспетчера. Конечно, такая оптимизация возможна лишь при соблюдении ограничений по размещению вызовов завершения задач в приложении, но в определенных случаях разработчики приложений могут пойти на такое ограничение, зная о выигрыше в производительности, который достигается за счет сокращения объема контекста задач и, следовательно, времени переключения контекста. Действительно, как показано на рисунке 2, оптимизированный контекст задач включает только значение счетчика команд и значения резервируемых регистров функций. Рабочие же регистры функций не входят в контекст. Разделение регистров на резервируемые и рабочие определяется соглашениями об использовании регистров для конкретной аппаратной платформы. Обычно в процессорах с небольшим наборов регистров, таких как Motorola HC12, все они являются рабочими, а в процессорах с большим количеством регистров, таких как Motorola PowerPC, примерно половина регистров являются резервируемыми.

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

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

Для обработчиков прерываний исключительно полезно использовать модификатор функции inter-rupt компилятора с языка С. Несмотря на то что этот модификатор не определен в стандарте ANSI-C, он поддерживается во всех компиляторах, ориентированных на встроенные приложения. Модификатор заставляет компилятор сгенерировать код, сохраняющий все необходимые рабочие регистры (иногда также и резервируемые), которые не сохраняются аппаратно, поэтому в коде ОСРВ нет необходимости заботиться об их сохранении и восстановлении. Для одних аппаратных платформ, где все регистры являются рабочими, можно вообще не использовать машинных инструкций на языке ассемблера; для других все же приходится использовать некоторое их количество для сохранения и восстановления резервируемых регистров. Кроме того, в случае использования модификатора компилятор также заботится о сохранении и восстановлении программных регистров, которые размещаются в ОЗУ, но используются компилятором для временного хранения промежуточных результатов вычислений. Такие программные регистры поддерживаются, например, компилятором фирмы Cosmic для микропроцессора Moto- rola HC08.

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

Оптимизация ОСРВ по стандарту OSEK/VDX OS требует, прежде всего, знания о том, как именно используется ОСРВ в приложениях заказчика. Нет смысла реализовывать ОСРВ в полном объеме, если заказчики все равно не используют значительную часть функциональности, требующей между тем существенных накладных расходов, ухудшая производительность ОСРВ и повышая расход памяти. Тщательный выбор классов соответствия и модели управления задачами и обработкой прерываний позволяет создать фундамент, на котором можно построить реализацию ОСРВ, удовлетворяющую самым высоким требованиям заказчика.

Список литературы

1.   OSEK/VDX Operating System, Version 2.1 revision 1, 13. November 2000.

2.   OSEK/VDX Communication, Version 2.2.2, 18th December 2000.