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

Что такое ОСРВ?

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

Зачем она нам нужна?

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

Обзор 3 известных ОСРВ.

Внимание: дальше идет мое личное мнение.

FreeRTOS

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

Плюсы

1) Бесплатная
2) Портирована на большое количество железа
3) Мощный функционал
4) Есть различные библиотеки: графика, интернет и другое.
5) Хорошая документация.

Минусы

1)Довольно-таки сложный процесс портирования на новое железо.

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

KeilRTX

До последнего времени эта ОСРВ была коммерческой, но недавно стала открытой. Работает только на архитектуре arm. Оффициальный сайт .

Плюсы

1)Бесплатная
2)Легко портируется на новое железо(в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.

Минусы

1)Работать на в Keil с ней практически нереально
2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.

uc/os

Мощная коммерческая ОСРВ. Сайт .

Плюсы

1) Огромное количество функций и библиотек.
2) Поддерживает много железа

Минусы

1)Коммерческая.
2) Сложна в использовании.

Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.

Другие интересные ОСРВ

RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.

Особенности разработки с использованием ОСРВ

Ну во-первых надо понять следующее: ОСРВ- это не Windows. Его нельзя установить. Эта система просто компилируется с Вашей программой.
При написании программ с ОСРВ не используются функции в обычном их понимании. Вместо функций используются процессы(или таски).Отличие в том что процессы, в отличии от функций, являются бесконечными циклами и никогда не заканчиваются(если только кто-то или он сам его не убъет - то есть выгрузит из памяти).
Если включено несколько процессов, то ОСРВ переключает их, выдавая машинное время и ресурсы по очереди. Вот тут то и возникает понятия приоритета процесса- если двум процессам единовременно нужно машинное время, то ОСРВ даст его тому, у кого приоритет больше.
В ОСРВ есть специальные функции задержки- чтобы время зря не пропадало на время задержки одного процесса выполняется второй.
Теперь поговорим о такой вещи как семафор- эта такая штука, которая управляет доступом процесса к ресурсам приложения. Для каждого ресурса есть маркер - когда процессу нужен ресурс - он его забирает и пользуется данным ресурсом. Если маркера нет, то процессу придется ждать, пока его вернут. Приведу пример: разные процессы отправляют информацию по одному UART. Если бы не было семафора, то они бы отправляли байты по очереди и получилась бы неразбериха. А так первый процесс взял маркер на UART отправил сообщение и отдал второму(и так - до бесконечности).

Дополнительные библиотеки ОСРВ.

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

Программные продукты и системы № 4, 2001 г. garbage collection. Technical report, University of Texas at Austin, 1993. 3. Kim T., Chang N., Kim N., Shin H. Scheduling Garbage Collector for Embedded Real-Time Systems. Technical report, Seoul National University. 4. The real-time specification for Java. http://www.rtj.org. 5. International J consortium specification. Real-time Core extensions. www.j-consortium.org. 6. Никифоров В.В., Данилов М.В. Статическая обработка спецификаций программных систем реального времени. //Программные продукты и системы.- 2000.- №4.- С.13-18. 7. Henriksson R. Scheduling garbage collection in embedded systems. Lund, 1998. 8. Nilsen K., Lee S. PERC real-time API. NewMonics Inc., 1997. 9. Wilson P.R., Johnstone M.S., Neely N., Boles D. Dynamic storage allocation: a survey and critical review. Technical report, University of Texas at Austin, 1995. МЕЖДУНАРОДНЫЙ СТАНДАРТ OSEK/VDX ДЛЯ ОПЕРАЦИОННОЙ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ М.П. Червинский Одной из тенденций совершенствования конструкций современных автомобилей является расширяющееся внедрение встроенных компьютерных систем. Соответственно растет объем производства автомобильных приложений реального времени – программных продуктов, обеспечивающих функционирование этих систем. Рост объема производства сопровождается ужесточением сроков разработки программных приложений, требований снижения их стоимости с одновременным улучшением надежности, мобильности, пригодности к повторному использованию при разработке новых продуктов. Перечисленные факторы стимулируют разработку стандартов, регламентирующих архитектурные и технологические решения, специфицирующие программные и сетевые интерфейсы для автомобильных приложений реального времени. Подобные стандарты должны способствовать расширению возможностей интеграции программных продуктов, производимых различными поставщиками программных средств. Во внедрении таких стандартов заинтересованы и крупные автомобилестроительные концерны, ("Крайслер", БМВ, "Фольксваген" и другие), стремящиеся к созданию конкуренции на рынке программных продуктов, которые они используют, потому что конкуренция позволяет приобретать программные продукты поставщиков, предлагающих наилучшее соотношение цена/качество. Для того чтобы смена поставщика не приводила бы к необходимости переработки значительной части приложений, производители требуют использования стандартов всеми поставщиками программных продуктов. Большинство встроенных систем, применяемых в транспортных средствах, являются приложениями жесткого реального времени. Обработка событий, возникающих в них, ограничивается жесткими сроками, нарушение которых могло бы привести к катастрофическим последствиям . В настоящее время основной технологией, применяемой для создания автомобильных приложений реального времени и, в частности, приложений жесткого реального времени, становится использование ядра, или операционной системы реального времени (ОСРВ). ОСРВ позволя- 40 ет разработчикам приложений гарантировать работоспособность приложения на протяжении всего цикла работы системы при условии правильного выбора приоритетов задач и правильного проектирования приложения. Необходимость стандартизации автомобильных приложений, строящихся на базе ОСРВ, привела к созданию в 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. OSEK/VDX COM (Communication) – спецификация сетевой подсистемы . Спецификация определяет программные интерфейсы и протоколы, предназначенные для передачи данных между узла- Программные продукты и системы ми транспортного средства. Современный автомобиль содержит до нескольких десятков микроконтроллеров, обменивающихся информацией. Как правило, используются как минимум две подсети: высокоскоростная – для системы управления двигателем, трансмиссией и подвеской, и низкоскоростная – для кузовной электроники. Программный интерфейс обеспечивает прозрачную передачу данных, то есть единый набор функций используется для обмена сообщениями как внутри узла, так и между узлами сети. Несмотря на то что спецификация в целом обеспечивает пользователей всеми необходимыми средствами для создания локальной сети автомобиля и поддерживает другие стандарты, применяемые в автомобильной индустрии, внедрение продуктов, реализующих 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 (в частности, отсутст- № 4, 2001 г. вуют описания для объектов OSEK/VDX COM), поэтому работа над этим стандартом продолжается. Перечисленные спецификации разрабатываются разными рабочими группами во многом независимо друг от друга, но на определенных этапах производится коррекция и синхронизация спецификаций. Синхронизированные версии заносятся в спецификацию связей – специальный документ, содержащий описание всего проекта и аннотации составляющих его частей. Помимо перечисленных спецификаций, в рамках проекта OSEK/VDX разрабатываются спецификации систем, управляемых временем (timetriggered) . В настоящее время, однако, разработка еще не доведена до стадии издания официальных документов. Спецификация OSEK/VDX OS. Последним официально выпущенным документом является редакция 1 версии 2.1 от 13 ноября 2000 года. Эта редакция является результатом тщательной переработки предыдущей редакции 1 версии 2.0, в которой было обнаружено несколько серьезных дефектов и сотни мелких замечаний. Дефекты были обнаружены как разработчиками собственно ОСРВ, так и создателями приложений. Несколько дефектов были настолько серьезны, что делали невозможным создание корректно работающей ОСРВ на некоторых аппаратных платформах. Рабочая группа крайне ответственно подошла к исправлению дефектов и замечаний. Достаточно сказать, что полный список проблем и предлагаемых решений содержал больше страниц, чем собственно спецификация. Спецификация OSEK/VDX OS определяет программный интерфейс для выполнения функций ОСРВ. Программный интерфейс специфицирован на языке программирования С (используется стандарт ANSI-C), хотя реализация ОСРВ возможна и на других языках программирования. Мобильность приложений поддерживается на уровне исходного кода. Предполагается, что приложение может быть просто перекомпилировано при замене реализации ОСРВ. Однако стопроцентная мобильность все же не гарантируется, и при переносе приложения с одной платформы на другую могут потребоваться некоторые изменения как исходного кода, так и описания конфигурации. Связано это с тем, что в спецификации определены функции, зависящие от реализации, а конфигурация может включать атрибуты, предназначенные для оптимизации ОСРВ и приложения для конкретной реализации. Однако усилия по переносу приложения все же существенно ниже, чем при использовании нестандартных ОСРВ, и перенос может быть выполнен на этапе интеграции, а не собственно разработки программного обеспечения. Содержание спецификации OSEK/VDX OS. Спецификация содержит разделы, регламентирующие: архитектуру ОС, управление задачами, обработку прерываний, обработку событий, синхронизацию с помощью разделяемых ресурсов, алармы (управление по таймерам и счетчикам), передачу сообщений, обработку ошибочных ситуаций и отладку, описание системных вызовов. 41 Программные продукты и системы Имеется также раздел, определяющий особенности реализации ОСРВ и список изменений (контроль версий). Следует отметить, что спецификация разделяет нормативные требования (обязательные) и просто описательные части, поясняющие особенности спецификации. Ниже рассматриваются основные особенности ОС, отвечающих спецификациям OSEK/VDX OS. Архитектура ОС. Строго говоря, архитектура ОСРВ не описана в спецификации, поскольку не отличается от традиционно используемой в ядрах реального времени, и раздел содержит скорее общее описание принципов работы ОСРВ. ОСРВ управляет двумя типами объектов, конкурирующих за право использования процессора, – задачами и обработчиками прерывания. Задачи конкурируют на основе программно задаваемых статических приоритетов, то есть ОСРВ поддерживает планирование с фиксированными приоритетами. Обработчики прерывания имеют более высокий приоритет, чем задачи и планируются с помощью аппаратного обеспечения. Вследствие такого распределения приоритетов любое переключение контекста задач, вызванное выполнением системных вызовов в обработчиках прерываний, задерживается до завершения обработчика прерывания или завершения самого внешнего обработчика при обработке вложенных прерываний. Соответственно двум типам конкурирующих объектов спецификация определяет два уровня работы – уровень задач и уровень прерываний. Определен также логический уровень планировщика, хотя этот уровень не используется в спецификации и не виден пользователю ОСРВ. Следует отметить, что, несмотря на полностью статическое распределение приоритетов задач и обработчиков прерываний, во время выполнения приложения могут возникнуть ситуации ограниченной по времени инверсии приоритетов. Это происходит, когда низкоприоритетная задача вытесняет более приоритетные задачи или задача запрещает выполнение обработчиков прерываний вплоть до некоторого порогового уровня аппаратного прерывания. Возникновение таких ситуаций объясняется использованием протокола синхронизации при доступе к критическим секциям и полностью контролируется приложением. Однако ни при каких обстоятельствах не возникает неограниченной по времени инверсии приоритетов, что позволяет гарантировать своевременность исполнения задач при правильном статическом назначении приоритетов. Классы соответствия. Одним из основных требований к OSEK/VDX OS является возможность применения ОСРВ на процессорах различной мощности, начиная с 8-битных микроконтроллеров, имеющих несколько десятков килобайт ПЗУ и несколько килобайт ОЗУ, и заканчивая 32-битными процессорами, имеющими сотни килобайт ПЗУ и ОЗУ. Для выполнения этого требования спецификация, в частности, описывает четыре класса соответствия. Классы соответствия определяются следующими характеристиками: а) множественный запрос 42 № 4, 2001 г. активизации (разрешен или нет в данном классе); б) поддержка задач с состоянием ожидания, то есть так называемых расширенных задач; в) количество задач на один уровень приоритета; г) обязательные (минимальные) количественные параметры ОСРВ (например, количество исполняемых задач, число поддерживаемых ресурсов для доступа к критическим секциям и т.п.). Спецификация определяет следующие классы соответствия. Базовый класс 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 специфицирует два типа задач – базовые и расширенные. Базовые задачи могут быть только в одном из трех состояний – неактивном, готовом и выполняющемся. Расширенные задачи могут дополнительно находиться в ждущем состоянии. Неактивное состояние задачи похоже на программу ОС общего назначения, находящуюся на жестком диске. Предполагается, хотя и не описано явно, что неактивная задача не использует ОЗУ. Спецификация также не накладывает ограничений на количество неактивных задач в приложении, что позволяет предположить, что таких задач может быть много больше, чем активизированных. Базовые задачи поддерживают принцип однократного выполнения, то есть при активизации задача переходит из неактивного состояния в готовое, затем, в зависимости от приоритета и способа диспетчеризации, занимает процессор, переходя в состояние выполнения. После окончания работы эта задача завершается и возвращается в неактивное состояние. Задачи такого рода никогда не используются в ОС общего назначения, но они эффективны во встроенных приложениях реального времени. № 4, 2001 г. Расширенные задачи могут переходить в состояние ожидания посредством механизма событий. Если все события, которые ожидает задача, не установлены, то задача переходит в состояние ожидания до тех пор, пока хотя бы одно из ожидаемых событий не будет установлено. Спецификация не определяет способа завершения одной задачи из другой или обработчика прерывания. Поэтому переход в неактивное состояние возможен только из состояния выполнения. Иными словами, задача может завершиться только по собственной инициативе. Разновидностью завершения задачи является завершение с одновременной активизацией другой задачи или нового экземпляра той же самой задачи, что позволяет создавать цепочки задач. Повторная активизация уже активной задачи приводит к ошибке в классах соответствия BCC1 и ECC1. В классах BCC2 и ECC2 соответствия при этом возникает множественный запрос на активизацию, означающий, что в момент завершения задачи будет активизирован ее новый экземпляр. Следует подчеркнуть, что для множественного запроса на активизацию выполняется тот же принцип планирования равноприоритетных задач: первой запланирована – первой выполняется. По-видимому, множественный запрос на активизацию может применяться в коммуникационных приложениях, например, когда сообщения, приходящие из сети, обрабатываются задачей, активизирующейся всякий раз, когда поступает новое сообщение. Обработка прерываний. Спецификация требований к обработке прерываний состоит из следующих разделов: обработчики прерываний (например, запросов на прерывания от внешних устройств), селективное управление источниками прерываний, быстрое управление распознаванием прерываний. Обработчики прерываний активизируются при возникновении запросов на прерывание, обычно от внешних устройств, или от самого процессора (например, для обработки исключительных ситуаций). Спецификация определяет три категории обработчиков прерываний. Категория 1 (ISR category 1). Обработчики этой категории не выполняют обращений к ОСРВ. Иными словами, они не изменяют состояния задач и других системных объектов. Обычно такие обработчики выполняются на самых высоких уровнях аппаратных приоритетов и предназначены для обработки событий с самыми короткими сроками выполнения, причем без участия ОСРВ. Категория 2 (ISR category 2). Для обработчиков второй категории ОСРВ автоматически предоставляет необходимые условия для возможности вызова сервисов ОСРВ. Технически это достигается с помощью ключевого слова ISR, поэтому разработчику приложений не надо заботиться о создании контекста, позволяющего обращаться к ОСРВ. Категория 3 (ISR category 3). Обработчики третьей категории являются как бы комбинацией обработчиков первой и второй категорий. Если в процессе выполнения обработчика нужно обратиться к 43 Программные продукты и системы ОСРВ, должен быть выполнен системный вызов EnterISR() для создания нужного контекста, а по окончании обработчика – вызов LeaveISR(), для того чтобы сообщить системе, что обработчик завершен (обработчики категории 2 неявно включают в себя эти вызовы). Практически все вызовы, которые имеет смысл вызывать из обработчиков прерываний, разрешены в обработчиках второй и третьей категории (между обращениями EnterISR/LeaveISR). Например, обработчики прерываний могут активизировать задачу, установить событие для задачи, послать сообщение, установить аларм и т.п. Обработчики прерываний могут быть вложенными, то есть один обработчик может прервать другой. Для этого должны быть созданы соответствующие аппаратные условия. При выполнении вложенных прерываний диспетчеризация задерживается до завершения самого внешнего обработчика. Отметим две проблемы, связанные с использованием обработчиков прерываний. Первая связана с потенциальными трудностями использования локальных переменных в обработчиках, относящихся к категории 3. Проблема состоит в том, что компиляторы обеспечивают выделение памяти под локальные переменные функции-обработчика в самом начале выполнения функции. При вызове EnterISR() стек может быть подменен, и эти локальные переменные становятся неадресуемыми, то есть обращение к ним после вызова EnterISR() приведет к ошибочной адресации. К сожалению, такая ситуация может возникнуть и в том случае, когда разработчик приложения даже не определяет локальные переменные явно. Поскольку компилятор может создать скрытые локальные переменные для выполнения некоторых операций (например, для выполнения битовых операций на 8-битных процессорах). Именно поэтому спецификация указывает на существование такой проблемы, которую можно полностью избежать, лишь отказавшись вовсе от использования обработчиков третьей категории. Вторая проблема связана с вложением обработчика категории 2 или 3 в обработчик первой категории. В таком случае диспетчеризация откладывается на неопределенное время, потому что она не может быть выполнена по завершении вложенного обработчика (поскольку еще есть внешний обработчик), но и не выполняется по завершении внешнего обработчика, потому что обработчик первой категории не взаимодействует с ОС. Чтобы избежать возникновения такой ситуации, спецификация рекомендует правильно назначать приоритеты обработчикам прерываний. Включенное в спецификацию описание селективного управления источниками прерываний подвергается критике в связи с тем, что интерфейсы прикладных программ, поддерживающие запрещение или разрешение распознавания запроса на прерывание от конкретного источника (устройства), не удается специфицировать в платформонезависимом виде, поэтому не достигается переносимость приложений, использующих такие сервисы. Кроме того, при использовании этих сервисов может возникнуть 44 № 4, 2001 г. неограниченное по времени запрещение прерываний, приводящее к аппаратным ошибкам. Например, низкоприоритетная задача, запретившая на короткое время прерывания по приему байта последовательного порта, может быть вытеснена более приоритетными задачами, и тогда «короткое время» затянется на неопределенный срок, что приведет к потере приема следующих байтов. Рабочая группа, разрабатывающая спецификации, согласна с этой критикой. Возможно, функции селективного управления источниками прерываний будут удалены из следующих версий спецификации. Быстрое управление распознаванием прерываний позволяет разрешать и запрещать либо все прерывания процессора, либо только те, которые влияют на работу ОСРВ. Обработка событий. События позволяют расширенной задаче переводить себя в состояние ожидания в том случае, если событие сброшено, и переводить задачу в состояние готовности, когда событие установлено. К сожалению, спецификация не очень четко определяет отображение глобальных событий на биты, используемые задачей, но предполагается, что каждая расширенная задача владеет собственной маской событий, битовыми флагами, которыми можно манипулировать с помощью системных вызовов ОСРВ. Для встроенных приложений, на которые ориентирована спецификация, задачи классов ECC1 и ECC2 приводят к накладным расходам, связанным с использованием выделенной области ОЗУ для стека каждой задачи, и манипулированию битами событий. Поэтому разработчикам приложений следует использовать расширенные задачи с большой осторожностью. Синхронизация с помощью разделяемых ресурсов. Спецификация использует специальный протокол для доступа к ресурсам, защищающим критические секции кода. Этот протокол называется OSEK Priority Ceiling Protocol, хотя он и описывает не собственно Priority Ceiling Protocol, а протокол, имеющий несколько синонимов, например, Highest Locker Protocol или Priority Protect Protocol (в стандарте POSIX). Протокол позволяет добиться исключения тупиков и неограниченной по времени инверсии приоритетов. Это достигается за счет того, что приоритет задачи, запрашивающей разделяемый ресурс, немедленно повышается до порогового значения приоритета ресурса, который вычисляется в процессе конфигурации системы как самый высокий (или выше) приоритет всех задач, имеющих доступ к этому ресурсу. Поэтому при запросе ресурса гарантируется, что никакая другая задача, имеющая доступ к этому ресурсу, не будет переведена в состояние выполнения. Большим достижением OSEK/VDX OS можно считать расширение этого протокола, обычно применяющегося только для задач, на обработчики прерываний для защиты критических секций кода, совместно используемых задачами и обработчиками прерываний. При этом подразумевается, что приоритеты обработчиков прерываний и задач как бы ото- Программные продукты и системы бражаются на одну шкалу и что ОСРВ способна манипулировать запрещением и разрешением уровней прерываний контроллера прерываний. Конечно, такая схема имеет вырожденный характер, если аппаратура поддерживает только один уровень прерываний, но все же может использоваться и в этом случае. Но особенно полезно использование расширения протокола на микропроцессорах, имеющих многоуровневую схему прерываний, например, Motorola 68K. Алармы (управление по таймерам и счетчикам). Спецификация определяет обобщенный объект, называемый алармом, который используется для активизации задач по значениям таймеров и счетчиков, например, измерителями линейных или угловых перемещений. Каждый аларм неявно подразумевает нижележащий счетчик, отсчитывающий значение некоторой величины. Спецификация не определяет программный интерфейс для управления счетчиками, потому что они могут быть полностью реализованы аппаратно, например, с помощью прерываний часов реального времени. Следует отметить, что к одному счетчику могут быть подключены несколько алармов. Спецификация требует, чтобы ОСРВ предоставляла системный таймер. Каждому аларму назначается задача или пара задача-событие. При срабатывании аларма задача активизируется или для нее устанавливается событие. Срабатывание аларма происходит в тот момент, когда значение счетчика достигнет значения установки аларма. Аларм можно установить как на абсолютное значение счетчика, так и на относительное. Также можно установить циклическое значение аларма, организовав таким образом обработку периодических событий. Можно заметить, что алармы обеспечивают очень гибкий и мощный механизм для обработки событий. Однако реализация алармов все же достаточно громоздка, особенно в случае подключения к счетчику нескольких алармов. Передача сообщений. Спецификация OSEK/ VDX OS не содержит описания механизма сообщений, отсылая к спецификации OSEK/VDX COM, в которой специально описаны два класса соответствия сети CCCA и CCCB (CCC – аббревиатура Communication Conformance Class) для локальных сообщений. CCCA описывает небуферизированные сообщения, то есть такие, содержание которых обновляется всякий раз, когда посылается сообщение. CCCB дополнительно определяет буферизированные сообщения, представляющие собой круговою очередь. Сообщения обоих типов имеют фиксированную длину (и размер очереди буферизированных сообщений), определяемую на этапе конфигурирования приложения. При поступлении сообщения может производиться активизация задачи-приемника, установка события для задачи-приемника или может вызываться пользовательская функция. Для сертификации реализации OSEK/VDX OS поставщику ОСРВ достаточно реализовать класс соответствия сети CCCA. № 4, 2001 г. Обработка ошибочных ситуаций и отладка. Для отладки и трассировки приложений спецификация описывает процедуры-ловушки и расширенную информацию об ошибках. Ловушки предоставляются пользователем, но вызываются самой ОС. В случае возникновения системной ошибки вызывается ловушка ошибки, для того чтобы приложение идентифицировало причину ошибки и предприняло корректирующие действия. Две ловушки предназначены для отслеживания переключения контекста задачи, помогая тем самым в трассировке приложения. При старте ОСРВ вызывается стартовая ловушка, в которой можно активизировать задачи, инициализирующие приложение, и выполнить инициализацию аппаратных средств. В случае фатальной ошибки приложение может завершить ОСРВ, при этом вызывается терминальная ловушка, в которой можно выполнить сброс аппаратных средств. Расширенная информация об ошибках предоставляется системными сервисами ОСРВ в том случае, если система статически сконфигурирована для этого. В описании каждой системной функции указывается, какие коды ошибок могут быть возвращены в стандартной и расширенной конфигурациях. Например, в стандартной конфигурации активизация задачи возвращает только код успешного выполнения, а в расширенной конфигурации сообщает о неправильном идентификаторе задачи и об ошибочном множественном запросе на активизацию. Предполагается, что расширенная конфигурация должна использоваться разработчиками приложений на этапе отладки, а отлаженное приложение конфигурируется в стандартном варианте, поскольку расширенная обработка ошибок приводит к существенным накладным расходам, в особенности в части использования процессорного времени. Существует, однако, проблема, связанная с различием временных характеристик исполнения приложения в стандартной и расширенной конфигурациях (разработчикам приложений следует иметь в виду возможные последствия этого различия). Стандарт 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. 45

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

05.05.2008, ПН, 23:56, Мск

Благодаря развитию вычислительной техники в последнее время стало возможным возложить на один модуль задачи, выполняемые ранее несколькими процессорными модулями, при этом улучшив массогабаритные характеристики системы управления и снизив ее стоимость. Такая тенденция в авиационной технике привела к появлению концепции интегрированной модульной авионики - ИМА (Integrated Modular Avionics,IMA).

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

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

Документы, регламентирующие требования к ОСРВ

Стандарт DO-178 (Software Consideration in Airborne Systems and Equipment Certification) определяет требования к процессу разработки программного обеспечения и тщательности его проверки в зависимости от его уровня критичности. Уровень критичности ПО определяется на основе анализа серьезности последствий отказа в ПО. Всего предусмотрено пять уровней критичности ПО (от A до E).

MILS (Multiple Independent Levels of Secutiry) представляет собой специальный подход к проектированию ОС, препятствующий распространению ошибок прикладного программного обеспечения во время выполнения, а также упрощающий верификацию программ за счет модульности ПО. Все приложения помещаются в так называемые разделы (partitions). Разделы имеют выделенные ресурсы (область памяти, процессорное время в течение каждого цикла системы, доступ к каналам обмена и пр). Доступ к выделенным ресурсам гарантируется ОС, работающей в режиме супервизора. Таким образом, на одном процессорном модуле под управлением одной ОС может работать прикладное ПО разного уровня критичности - если сбой произойдет в менее критичном (и, соответственно, менее проверенном) ПО, это никак не повлияет на работу других разделов, так как попытки «узурпировать» чужие ресурсы будут пресечены операционной системой. Идеи MILS перекликаются с идеями ИМА и DO-178B.

Ошибка 404. Не удаётся найти страницу.

Возможно, это случилось по одной из этих причин:

– ошибка при наборе адреса страницы (URL)
– переход по «битой» (неработающей, неправильной) ссылке
– запрашиваемой страницы никогда не было на сайте или она была удалена

Вы можете:

– вернуться назад при помощи кнопки браузера Назад (Back)
– проверить правильность написания адреса страницы (URL)
– воспользоваться картой сайта или перейти на главную страницу

Стандарт ARINC-653 (Avionics Application Software Standard Interface) специфицирует интерфейс прикладного программного обеспечения APEX, поддерживающий концепцию разделов в духе MILS. Данный интерфейс включает функции управления разделами, процессами, разделением времени, коммуникациями между разделами и внутри раздела, мониторинг состояния системы. Надо отметить, что стандарт ARINC-653 описывает общепризнанный подход к реализации идей MILS для ИМА, хотя могут быть и другие реализации. Авиационная ОСРВ, соответствующая ARINC-653, имеет преимущества, так как данный стандарт хорошо известен и понятен международным сертифицирующим органам, поэтому на систему, построенную по этому стандарту, проще получить сертификат соответствия DO-178B.

Стандарт Reusable Software Components. В соответствии с DO-178B программное обеспечение той или иной системы авиационного применения проходит процедуру сертификации полностью, даже если оно использует модули (компоненты), которые уже были сертифицированы ранее в составе другой системы. Одной из последних инициатив FAA (Федеральное агентство по сертификации гражданской авиации, США) является определение критериев возможности многократного использования ПО без повторной сертификации. Компоненты, которые можно повторно не сертифицировать, называются RSC (Reusable Software Components). Чтобы получить сертификат на RSC, нужно затратить больше усилий, но затем RSC дает серьезную экономию.

Российские документы, определяющие требования к ПО (и в том числе к ОСРВ):

• ГОСТ Р ИСО/МЭК 51904-2002 ("ПО встроенных систем. Общие требования к разработке и документированию") - аналог DO-178B для военной авиации;
• КТ-178А ("Квалификационные требования часть 178А") - аналог DO-178B для гражданской авиации;
• ГОСТ Р ИСО/МЭК 12207-99 ("Информационная технология. Процессы жизненного цикла программных средств").

Сравнение ОС РВ проводилось по 13 параметрам, которые учитывают технические критерии, удобство разработки и экономические параметры.

Временные параметры ОС

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

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

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

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

Достаточно объективными данными можно считать результаты, полученные экспертами журнала Dedicated System, проводившими тестирование и практическое сравнение QNX RTOS 6.1, VxWorks AE 1.1 и Windows CE.NET на x86 платформе. Хотя на сегодняшний момент эти данные устарели, авторам данной статьи не удалось найти более свежего материала. В табл. 2 приведены выборочные данные о сравнении производительности QNX Neutrino 6.1, VxWorks AE 1.1. В отчете Dedicated Systems предпочтение с точки зрения быстродействия было отдано QNX, причем отношение баллов было установлено как 9:5 (QNX:VxWorks), потому как в процессе тестирования в VxWorks были обнаружены две ошибки, за исправлением которых пришлось обращаться в службу поддержки.

В табл. 3 приведены данные о характеристиках LynxOS. Состав использовавшихся тестов не указан. В качестве данных о характеристиках LynxOS интересна четвертая колонка (тестирование на x86-платформе). По сравнению с VxWorks и QNX, ОС РВ LynxOS показывает огромную задержку при реакции на прерывание (более чем в 5 раз). Время переключение контекста (имеется в виду время переключения между двумя потоками в одном процессе) одинаковое с QNX и меньше примерно в 1,5 раза, чем у VxWorks.

Стабильность временных параметров

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

Исходя из данных журнала Dedicated System, QNX опережает по этому критерию VxWorks как по разбросу характеристик в серии однотипных тестов (отношение максимума времени к среднему значению существенно меньше), так и с ростом нагрузки (время переключения потока при увеличении числа потоков 2...128 ед. у QNX выросло только в 1,65 раза, тогда как у VxWorks - в 2,24 раза).

По данным, полученным в компании РТСофт, известно, что LynxOS имеет приблизительно те же характеристики, что VxWorks.

Управление доступом к ресурсам

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

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

Задача процессов состоит:

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

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

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

Поддержка мультипроцессорных и распределенных систем

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

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

ОС РВ QNX предлагает поддержку многопроцессорных плат. Для VxWorks такая поддержка пока только анонсирована. Авиационной версии LynxOS с поддержкой многопроцессорных плат пока тоже не существует.

В отношении поддержки сетевых протоколов нужно отметить, что ОС РВ LynxOS, VxWorks и QNX обладают примерно равными (и широкими) возможностями. Дополнительным плюсом ОС РВ QNX является ее специальная архитектура сетевой подсистемы, обеспечивающая сетевую «прозрачность» прикладных программ: любой процесс может вызвать другой процесс на удаленном модуле так же, как и процесс на локальном модуле.

Поддержка файловых систем

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

В табл. 4 показана поддержка файловых систем каждой из рассматриваемых ОС.

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

Качество документации

Качество документации ОС РВ LynxOS, VxWorks, QNX достаточно высокое. Однако есть и нарекания по поводу документации:

• QNX - отличное описание архитектуры и принципов построения, но недостаточное описание интерфейса прикладного программирования (дано описание не всем параметрам, есть несоответствия);
• VxWorks - нет объяснения принципов работы и недостаточное описание сложного процесса конфигурирования ОС.

Тем не менее, компании работают над качеством материала. Документация на текущую версию QNX (6.3.2) существенно расширена, налицо переработка некоторых частей.

Качество технической поддержки

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

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

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

Открытость исходных кодов

Открытая ОС РВ имеет по крайней мере три преимущества:

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

С сентября 2007 года компания QSS открыла исходные коды ядра QNX (включая пакет сегментирования Adaptive Partitioning, пакет высокой готовности High Availability). Немногим позже были открыты исходные коды сетевой подсистемы. В настоящее время на официальном сайте доступна для скачивания бета-версия 6.4.0.

Надо отметить, что на сегодняшний день не все модули QNX открыты (например, нет кодов для графической и файловой систем), и лицензия налагает ограничение на использование «исходников»: только для некоммерческого применения. Тем не менее, пользователь QNX получает указанные выше преимущества бесплатно.

Исходные коды LynxOS и VxWorks доступны в продаже. Цена на такой продукт договорная.

Инструментальные средства

Наличие хороших инструментальных средств во многом определяет качество и скорость разработки прикладных программ под ту или иную ОС. Надо отметить, что LynxOS, VxWorks и QNX в настоящее время предоставляют хорошего качества инструментальные средства, которые включают интегрированную среду разработки (ИСР) и отладки прикладного ПО, средства профилирования программ (для обнаружения «узких мест» по производительности, памяти и пр.). Эргономика ИСР для данных ОС РВ в целом не уступает развитым средствам разработки для обычных ОС (например, MS Windows).

Переносимость прикладного ПО

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

Возможность написания переносимого ПО определяется в текущий момент соответствием стандарту POSIX. Все рассматриваемые ОС РВ поддерживают стандарт POSIX 1003.1. Преимущество есть у LynxOS - данная ОС обладает бинарной совместимостью с ОС Linux. То есть приложения Linux могут быть запущены под LynxOS без перекомпилирования. И, наоборот, приложения LynxOS могут быть запущены в Linux (версии 2.4.x c библиотекой языка Си glibs версии 2.2.2).

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

Поддержка процессорных архитектур

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

Соответствие авиационным стандартам

В зарубежной практике ПО для систем авионики должно иметь сертификат соответствия стандарту DO-178B. Если ПО разных уровней критичности выполняется на одном процессорном модуле, то применяемая ОСРВ должна поддерживать концепцию разделов. (Иначе доказать нераспространение ошибки практически невозможно). Как уже говорилось, лучше, если интерфейс программирования ОСРВ соответствует стандарту ARINC-653, так как стандарт хорошо известен зарубежным сертификационным органам.

LynxOS в части соответствия стандартам является лидером. Она поддерживает ARINC-653, существует достаточно примеров систем, сертифицированных по DO-178B, построенных на ее основе. Ключевым моментом является то, что компания LynuxWorks предлагает набор RSC (правда, авторам статьи ничего не известно о цене).

VxWorks соответствует стандарту ARINC-653, и системы, построенные на ее основе, могут быть сертифицированы по DO-178B (существует большое число примеров).

QNX не соответствует ARINC-653, и пока не существует систем на их основе, сертифицированных по DO-178B.

Надо отметить, что QNX-системы принципиально могут использоваться для построения ИМА, потому что QNX поддерживает свой метод обеспечения концепции разделов, который является весьма хорошей альтернативой ARINC-653 и, кроме того, позволяет экономить процессорное время.

В части аналогичных российских стандартов для военной авиации (ГОСТ Р ИСО/МЭК 51904-2002) нет еще ни одного примера сертифицированной системы, хотя принципиально на основе любой из рассматриваемых ОС можно такую систему разработать. Для ОС РВ QNX в настоящее время ведется работа по подготовке основных модулей ОС к сертификации.

Развитость системы подготовки специалистов

Быстрота и качество обучения персонала, работающего с ОС РВ и различными инструментариями по разработке и отладке ПО напрямую связано со скоростью разработки ПО и его качеством. Ведущие компании в области встроенного и системного ПО, такие как WindRiver, LynuxWorks, QSS, проводят широкомасштабную программу курсов и тренингов по изучению использования продуктов компании, в том числе и ОС РВ.

Результаты сравнения

ОСРВ QNX Neutrino является наиболее совершенной ОС с технической точки зрения, располагает хорошим набором инструментальных средств, имеет относительно невысокую цену. Микроядерная архитектура обеспечивает высокую надежность и модульность разрабатываемых систем. Дополнительным плюсом является открытость исходных кодов. Но есть и «ложка дегтя»: в настоящее время QNX практически нигде не используется в авиации, и по этому параметру данная ОС проигрывает конкурентам (LynxOS и VxWorks). Дополнительный минус QNX: несоответствие стандарту ARINC-653.

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

Работа по подготовке к сертификации QNX Neutrino по требованиям отечественных авиационных стандартов в настоящее время ведется компанией SWD Software.

ОСРВ LynxOS-178, напротив, имеет все необходимые сертификаты за рубежом, хотя по многим другим критериям выглядит менее предпочтительно, чем QNX Neutrino. Отметим, что для применения в российской авиационной промышленности ОСРВ LynxOS-178 также должна быть сертифицирована по отечественным ГОСТ.

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

Экспертная группа / R&D.CNews

Распечатать

Отличительные черты ОСРВ от ОС общего назначения

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

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

Системы жёсткого и мягкого реального времени

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

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

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

• стоимость опоздания может оказаться бесконечно велика.

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

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

Ядро операционной системы

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

Монолитное ядро

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

Достоинства : Скорость работы, упрощённая разработка модулей.

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

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

Микроядро

Микроядро предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием. Большая часть работы осуществляется с помощью специальных пользовательских процессов, называемых сервисами. Решающим критерием «микроядерности» является размещение всех или почти всех драйверов и модулей в сервисных процессах.

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

Недостатки : Передача данных между процессами требует накладных расходов.

Среда исполнения

Требования, предъявляемые к среде исполнения систем реального времени, следующие:

• небольшая память системы - для возможности ее встраивания;
• система должна быть полностью резидентна в памяти, чтобы избежать замещения страниц памяти или подкачки;
• система должна быть многозадачной - для обеспечения максимально эффективного использования всех ресурсов системы;
• ядро с приоритетом на обслуживание прерывания. Приоритет на прерывание означает, что готовый к запуску процесс, обладающий некоторым приоритетом, обязательно имеет преимущество в очереди по отношению к процессу с более низким приоритетом, быстро заменяет последний и поступает на выполнение. Ядро заканчивает любую сервисную работу, как только поступает задача с высшим приоритетом. Это гарантирует предсказуемость системы;
• диспетчер с приоритетом - дает возможность разработчику прикладной программы присвоить каждому загрузочному модулю приоритет, неподвластный системе. Присвоение приоритетов используется для определения очередности запуска программ, готовых к исполнению. Альтернативным такому типу диспетчеризации является диспетчеризация типа "карусель", при которой каждой готовой к продолжению программе дается равный шанс запуска. При использовании этого метода нет контроля за тем, какая программа и когда будет выполняться. В среде реального времени это недопустимо. Диспетчеризация, в основу которой положен принцип присвоения приоритета, и наличие ядра с приоритетом на прерывание позволяют разработчику прикладной программы полностью контролировать систему. Если наступает событие с высшим приоритетом, система прекращает обработку задачи с низшим приоритетом и отвечает на вновь поступивший запрос.

Сочетание описанных выше свойств создает мощную и эффективную среду исполнения в реальном времени.

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

Ядро может обеспечивать сервис различных типов:

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

Обзор архитектур ОСРВ

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

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

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

Рисунок 2. Архитектура уровневой ОС

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

1. Повышается надежность ОС, т.к. каждый сервис является, по сути, самостоятельным приложением и его легче отладить и отследить ошибки.

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

3. Повышается отказоустойчивость системы, т.к. «зависший» сервис может быть перезапущен без

перезагрузки системы.

Рисунок 3. Построение ОС с использованием архитектуры клиент-сервер

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

Список использованной литературы:

1) http://ru.wikipedia.org/wiki/Операционная_система_реального_времени

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5)http://www.ozon.ru/context/detail/id/3092042/

Операционные системы реального времени

1. Введение: Особенности операционных систем реального времени

1.1. Процессы, потоки, задачи

1.2. Планирование, приоритеты

1.3. Память

1.4. Прерывания

1.5. Часы и таймеры

1.6. Стандарты ОСРВ

1.6.1. POSIX

1.6.2. DO-178B

1.6.3. ARINC-653

1.6.4. OSEK

1.6.5. Стандарты безопасности

1.7. Настраиваемость операционных систем

2. Краткие характеристики наиболее распространенных ОСРВ

2.1. VxWorks

2.2. QNX Neutrino RTOS

2.3. RTEMS

2.4. ChorusOS

2.5. Расширения реального времени для Windows NT

2.5.1. RTX для Windows NT

2.5.2. INtime

2.5.3. Microsoft Windows Embedded

2.6. TinyOS

2.7. OSEK/VDX

2.8. OSE RTOS

2.9. Contiki

2.10. pSOS

2.11. INTEGRITY

2.12. LynxOS

2.13. Microware OS-9

2.14. GRACE-OS

2.15. C EXECUTIVE

2.16. CMX-RTX

2.16.1. CMX-TINY+

2.17. Inferno

3. ОС, разработанные специально для портативных устройств

3.1. ITRON

3.2. Windows CE

3.3. JavaOS

3.4. Jbed

3.5. Nucleus RTOS

3.6. EMERALDS

3.7. CORTEX

3.8. DeltaOS

3.9. Palm OS

3.10. Symbian OS (EPOC)

4. Настраиваемость операционных систем

4.1. Адаптация, осуществляемая человеком

4.1.1. Статическая адаптация, инициированная проектировщиком

4.1.2. Динамическая адаптация, инициированная администратором

4.2. Адаптация, инициированная приложением

4.2.1. Адаптация с уровня приложения

4.2.2. Адаптация на уровне ядра

4.3. Автоматическая адаптация

5. Сводные таблицы характеристик свойств ОСРВ

Приложение А. Перечень сокращений

Приложение B. Терминология

Литература

Список ОСРВ, упоминающихся в данном тексте, печати и в Сети

1. Введение: Особенности операционных систем реального времени

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

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

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

Принято различать системы мягкого (soft) и жесткого (hard) реального времени. В системах жесткого реального времени неспособность обеспечить реакцию на какие-либо события в заданное время ведет к отказам и невозможности выполнения поставленной задачи. В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами мягкого реального времени называются системы, не попадающие под определение "жесткие", т.к. в литературе четкого определения для них пока нет. Системы мягкого реального времени могут не успевать решать задачу, но это не приводит к отказу системы в целом. В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.

Мартин Тиммерман сформулировал следующие необходимые требования для ОСРВ :

ОС должна быть многозадачной и допускающей вытеснение (preemptable),

ОС должна обладать понятием приоритета для потоков,

ОС должна поддерживать предсказуемые механизмы синхронизации,

ОС должна обеспечивать механизм наследования приоритетов,

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

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

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

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

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

Рассмотрим концептуальные абстракции операционной системы через призму требований к системам реального времени.