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

Перечисленные факторы стимулируют разработку стандартов, регламентирующих архитектурные и технологические решения, специфицирующие программные и сетевые интерфейсы для автомобильных приложений реального времени. Подобные стандарты должны способствовать расширению возможностей интеграции программных продуктов, производимых различными поставщиками программных средств. Во внедрении таких стандартов заинтересованы и крупные автомобилестроительные концерны, ("Крайслер", БМВ, "Фольксваген" и другие), стремящиеся к созданию конкуренции на рынке программных продуктов, которые они используют, потому что конкуренция позволяет приобретать программные продукты поставщиков, предлагающих наилучшее соотношение цена/качество. Для того чтобы смена поставщика не приводила бы к необходимости переработки значительной части приложений, производители требуют использования стандартов всеми поставщиками программных продуктов.

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

Проект OSEK/VDX был инициирован группой ведущих европейских производителей транспортных средств (автомобилей), большинство из которых находятся в Германии. Именно поэтому выбранная аббревиатура OSEK является сокращением немецкого названия «Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug» – «Открытые системы и интерфейсы для автомобильной электроники». Сокращение же VDX означает «Vehicle Distributed eXecutive» – название другого проекта, интеграция с которым произошла практически одновременно с началом проекта OSEK. Таким образом, даже название проекта и серии стандартов отражает интернациональный характер разработки с некоторым доминированием немецких производителей.

В рамках проекта OSEK/VDX разрабатываются несколько стандартов.

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

2. OSEK/VDX COM (Communication) – спецификация сетевой подсистемы [3]. Спецификация определяет программные интерфейсы и протоколы, предназначенные для передачи данных между узлами транспортного средства. Современный автомобиль содержит до нескольких десятков микроконтроллеров, обменивающихся информацией. Как правило, используются как минимум две подсети: высокоскоростная – для системы управления двигателем, трансмиссией и подвеской, и низкоскоростная – для кузовной электроники. Программный интерфейс обеспечивает прозрачную передачу данных, то есть единый набор функций используется для обмена сообщениями как внутри узла, так и между узлами сети. Несмотря на то что спецификация в целом обеспечивает пользователей всеми необходимыми средствами для создания локальной сети автомобиля и поддерживает другие стандарты, применяемые в автомобильной индустрии, внедрение продуктов, реализующих OSEK/VDX COM, в реальные проекты сопряжено с некоторыми проблемами. Главной является использование крупными производителями автомобилей других (нестандартных) протоколов, что затрудняет переход на OSEK/VDX COM, так как требуется либо менять сетевое обеспечение во всех узлах автомобиля, либо поддерживать одновременно как стандартный, так и нестандартный протокол, по крайней мере в некоторых узлах сети. Кроме того, в настоящей версии спецификаций отсутствует механизм передачи данных длиной в несколько бит, а именно данные такой длины составляют существенную долю сетевого трафика автомобиля. Поэтому разработка спецификаций OSEK/VDX COM продолжается.

3. OSEK/VDX NM (Network Management) – спецификация управления сетью. Спецификация определяет, каким образом информация о текущем состоянии каждого из узлов сети передается другим узлам. Для этого используется метод мониторинга, в частности, две его разновидности – прямой и косвенный. Прямой мониторинг основан на передаче специальных сообщений по логическому кольцу или логической звезде. Косвенный мониторинг основан на отслеживании обычных сообщений, передаваемых узлами. OSEK/VDX NM может быть интегрирован с другими сетевыми системами (а не только с OSEK/VDX COM), и поэтому используется в настоящее время вместе с нестандартными сетевыми системами.

4. OSEK/VDX OIL (OSEK Implementation Language) – спецификация языка конфигурации системы. Спецификация описывает язык, использующийся для конфигурации приложений, построенных на реализации OSEK/VDX. Во встроенных системах, применяемых в автомобилях, все объекты приложения конфигурируются статически на стадии компиляции. Язык OIL содержит конструкции, позволяющие описать свойства системных объектов, например, названия и приоритеты задач, параметры таймеров и сообщений и т.п. Описание конфигурации обрабатывается специальной утилитой (системным генератором), которая формирует заголовочные файлы и исходный код, описывающие системные таблицы. В настоящее время не все спецификации полностью покрываются OSEK/VDX OIL (в частности, отсутствуют описания для объектов OSEK/VDX COM), поэтому работа над этим стандартом продолжается.

Перечисленные спецификации разрабатываются разными рабочими группами во многом независимо друг от друга, но на определенных этапах производится коррекция и синхронизация спецификаций. Синхронизированные версии заносятся в спецификацию связей – специальный документ, содержащий описание всего проекта и аннотации составляющих его частей. Помимо перечисленных спецификаций, в рамках проекта OSEK/VDX разрабатываются спецификации систем, управляемых временем (time-triggered) [1]. В настоящее время, однако, разработка еще не доведена до стадии издания официальных документов.

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

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

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

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

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

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

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

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

Классы соответствия. Одним из основных требований к OSEK/VDX OS является возможность применения ОСРВ на процессорах различной мощности, начиная с 8-битных микроконтроллеров, имеющих несколько десятков килобайт ПЗУ и несколько килобайт ОЗУ, и заканчивая 32-битными процессорами, имеющими сотни килобайт ПЗУ и ОЗУ. Для выполнения этого требования спецификация, в частности, описывает четыре класса соответствия. Классы соответствия определяются следующими характеристиками: а) множественный запрос активизации (разрешен или нет в данном классе); б) поддержка задач с состоянием ожидания, то есть так называемых расширенных задач; в) количество задач на один уровень приоритета; г) обязательные (минимальные) количественные параметры ОСРВ (например, количество исполняемых задач, число поддерживаемых ресурсов для доступа к критическим секциям и т.п.).

Спецификация определяет следующие классы соответствия.

Базовый класс 1 (BCC1 – Basic Conformance Class 1). Задачи с состоянием ожидания и множественный запрос активизации не поддерживаются, только одна задача на уровень приоритета, то есть все задачи имеют разный приоритет.

Базовый класс 2 (BCC2). То же, что базовый класс 1, но поддерживаются множественный запрос на активизацию и несколько задач на один уровень приоритета.

Расширенный класс 1 (ECC1 – Extended Conformance Class 1). То же, что базовый класс 1, но поддерживаются задачи с состоянием ожидания.

Расширенный класс 2 (ECC2). То же, что ECC1, но поддерживаются множественный запрос на активизацию для задач без состояния ожидания и несколько задач на один уровень приоритета.

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

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

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

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

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

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

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

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

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

Повторная активизация уже активной задачи приводит к ошибке в классах соответствия BCC1 и ECC1. В классах BCC2 и ECC2 соответствия при этом возникает множественный запрос на активизацию, означающий, что в момент завершения задачи будет активизирован ее новый экземпляр. Следует подчеркнуть, что для множественного запроса на активизацию выполняется тот же принцип планирования равноприоритетных задач: первой запланирована – первой выполняется. По-видимому, множественный запрос на активизацию может применяться в коммуникационных приложениях, например, когда сообщения, приходящие из сети, обрабатываются задачей, активизирующейся всякий раз, когда поступает новое сообщение.

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

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

Категория 1 (ISR category 1). Обработчики этой категории не выполняют обращений к ОСРВ. Иными словами, они не изменяют состояния задач и других системных объектов. Обычно такие обработчики выполняются на самых высоких уровнях аппаратных приоритетов и предназначены для обработки событий с самыми короткими сроками выполнения, причем без участия ОСРВ.

Категория 2 (ISR category 2). Для обработчиков второй категории ОСРВ автоматически предоставляет необходимые условия для возможности вызова сервисов ОСРВ. Технически это достигается с помощью ключевого слова ISR, поэтому разработчику приложений не надо заботиться о создании контекста, позволяющего обращаться к ОСРВ.

Категория 3 (ISR category 3). Обработчики третьей категории являются как бы комбинацией обработчиков первой и второй категорий. Если в процессе выполнения обработчика нужно обратиться к ОСРВ, должен быть выполнен системный вызов EnterISR() для создания нужного контекста, а по окончании обработчика – вызов LeaveISR(), для того чтобы сообщить системе, что обработчик завершен (обработчики категории 2 неявно включают в себя эти вызовы).

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

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

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

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

Быстрое управление распознаванием прерываний позволяет разрешать и запрещать либо все прерывания процессора, либо только те, которые влияют на работу ОСРВ.

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

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

Синхронизация с помощью разделяемых ресурсов. Спецификация использует специальный протокол для доступа к ресурсам, защищающим критические секции кода. Этот протокол называется OSEK Priority Ceiling Protocol, хотя он и описывает не собственно Priority Ceiling Protocol, а протокол, имеющий несколько синонимов, например, Highest Locker Protocol или Priority Protect Protocol (в стандарте POSIX). Протокол позволяет добиться исключения тупиков и неограниченной по времени инверсии приоритетов. Это достигается за счет того, что приоритет задачи, запрашивающей разделяемый ресурс, немедленно повышается до порогового значения приоритета ресурса, который вычисляется в процессе конфигурации системы как самый высокий (или выше) приоритет всех задач, имеющих доступ к этому ресурсу. Поэтому при запросе ресурса гарантируется, что никакая другая задача, имеющая доступ к этому ресурсу, не будет переведена в состояние выполнения.

Большим достижением OSEK/VDX OS можно считать расширение этого протокола, обычно применяющегося только для задач, на обработчики прерываний для защиты критических секций кода, совместно используемых задачами и обработчиками прерываний. При этом подразумевается, что приоритеты обработчиков прерываний и задач как бы отображаются на одну шкалу и что ОСРВ способна манипулировать запрещением и разрешением уровней прерываний контроллера прерываний. Конечно, такая схема имеет вырожденный характер, если аппаратура поддерживает только один уровень прерываний, но все же может использоваться и в этом случае. Но особенно полезно использование расширения протокола на микропроцессорах, имеющих мно- гоуровневую схему прерываний, например, Moto- rola 68K.

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

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

Передача сообщений. Спецификация OSEK/ VDX OS не содержит описания механизма сообщений, отсылая к спецификации OSEK/VDX COM, в которой специально описаны два класса соответствия сети CCCA и CCCB (CCC – аббревиатура Communication Conformance Class) для локальных сообщений. CCCA описывает небуферизированные сообщения, то есть такие, содержание которых обновляется всякий раз, когда посылается сообщение. CCCB дополнительно определяет буферизированные сообщения, представляющие собой круговою очередь. Сообщения обоих типов имеют фиксированную длину (и размер очереди буферизированных сообщений), определяемую на этапе конфигурирования приложения. При поступлении сообщения может производиться активизация задачи-приемника, установка события для задачи-приемника или может вызываться пользовательская функция. Для сертификации реализации OSEK/VDX OS поставщику ОСРВ достаточно реализовать класс соответствия сети CCCA.

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

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

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

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

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

1.   Kopetz H. Real-Time Systems. Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers. MA, 1997.

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

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