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

А. А. Блискавицкий, С. В. Кабаев, ЗАО "РТСофт"  
 
В статье проводится обзор операционных систем реального времени.

Введение

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

Аппаратное обеспечение

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

В обзоре современных открытых стандартов для построения интегрированных  измерительных и управляющих  систем реального времени (автор  А.Н. Рыбаков), приведенном в начале данного выпуска, убедительно показана лидирующая роль шины VMEbus.

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

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

Базовые понятия  программного обеспечения реального  времени

Любая ОС обязана обеспечить полный цикл жизни программного обеспечения: создание текста программы, ее компиляция, компоновка, отладка, исполнение, сопровождение. Задачи реального времени предъявляют свои требования к вычислительно-управляющим системам, в том числе к ОС, в которых реализовано программное обеспечение реального времени. Эти требования изложены в стандарте POSIX 1003.4 рабочего комитета IEEE [3-7]. Стандарт определяет ОС как систему реального времени, если она обеспечивает требуемый уровень сервиса за вполне определенное, ограниченное время. То есть ОС реального времени должна быть предсказуемой. Правильная, но запоздалая реакция системы на внешнее событие может быть гибельной в системах безопасности атомных станций, системах управления воздушными транспортными потоками и т.д. При этом важно не только абсолютное время реакции системы, но и то, что оно определено заранее. В системе управления прокатным станом время реакции системы должно быть в пределах нескольких миллисекунд, а в системе контроля за окружающей средой - несколько минут. Но тем не менее оба эти примера - из области задач реального времени. Возникает вопрос, можно ли задачи реального времени решать с помощью систем общего назначения (MS-DOS, UNIX и т.д.)? Главное требование, предъявляемое к системам общего назначения, заключается в том, что они должны обеспечить оптимальное разделение всех ресурсов между всеми процессами. Соответственно, не должно быть высокоприоритетных задач, которые использовали бы какой-либо ресурс системы столько, сколько им необходимо. Надо все же учесть, что так или иначе, разработчики ОС достигают компромисса между механизмом приоритетности и упомянутым требованием.

UNIX стал de-facto стандартом ОС общего назначения. Он реализован и на микро-, и на суперкомпьютерах. Многие международные программные стандарты и соглашения основаны на UNIX: POSIX, SVID (UNIX System V Interface Definitions), BSD 43 UNIX Socket и т.д. Однако ОС UNIX, разработанная как система общего назначения, не имеет эффективного механизма приоритетности задач и поэтому мало пригодна для задач реального времени. В то же время многие ОС реального времени можно охарактеризовать как UNIX-подобные.

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

• многозадачность;

• легкость написания и включения в систему драйверов внешних устройств;

• хорошо развитый механизм синхронизации процессов и межзадачного обмена.

Становится очевидным  то, что задачи реального времени  необходимо реализовывать в рамках специфической системной программной  среды. В соответствии с [5] системы  реального времени можно разделить  на 4 класса.

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

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

3-й класс: ядро системы  реального времени и инструментальная  среда. Этот класс систем обладает  многими чертами ОС с полным  сервисом. Разработка ведется в  инструментальной среде, а исполнение - на целевых системах. Этот тип  систем обеспечивает гораздо  более высокий уровень сервиса  для разработчика прикладной  программы. Сюда включены такие  средства, как дистанционный символьный  отладчик, протокол ошибок и другие  средства CASE. Часто доступно параллельное  выполнение программ.

4-й класс: ОС с полным  сервисом. Такие ОС могут быть применены для любых приложений реального времени. Разработка и исполнение прикладных программ ведутся в рамках одной и той же системы.

Системы 2 и 3 классов принято  называть системами "жесткого" реального  времени, а 4 класса - "мягкого". Очевидно, это можно объяснить тем, что  в первом случае к системе предъявляются  более жесткие требования по времени  реакции и необходимому объему памяти, чем во втором. Как мы видим, среда  разработки и среда исполнения в  системах реального времени могут  быть разделены, а требования, предъявляемые  к ним, весьма различны. Рассмотрим их более подробно.

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

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

• небольшая память системы - для возможности ее встраивания;

• система должна быть полностью резидентна в памяти, чтобы избежать замещения страниц памяти или подкачки;

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

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

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

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

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

Ядро может обеспечивать сервис пяти типов:

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

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

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

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

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

Среда разработки

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

На рис. 1 приведены различные  интерфейсы и стандарты для приложений реального времени.

Стоимость проекта любой  системы реального времени определяется стоимостью программного обеспечения. Поэтому все больше внимания уделяется  среде разработки программ. Более  совершенные методы и средства разработки, отладки и поддержки прикладных программ позволяют их разработчикам  производить более качественный программный продукт за меньшее  время. Для разработки прикладных программ необходимы определенные средства: редакторы, компиляторы, компоновщики и отладчики. Символьные отладчики позволяют  разработчику, часто с удаленного терминала, отлаживать исполняемую  систему. При использовании символьного  отладчика разработчик может  ссылаться на имена переменных и  метки, иметь информацию об исходном коде в процессе отладки. Нет необходимости  заводить карту памяти и устанавливать  физическое местоположение анализируемых  переменных. Присущие отладчику свойства позволяют исследовать переменные, проверять их значения, построчно  проходить программу и расставлять  точки останова. Отладчики с большей  ошибкоустойчивостью показывают состояние  системы, т.е. какие из программ поступили  к запуску, в каком состоянии  они находятся (выполнение, ожидание), дают информацию о конкретной программе  и динамически создают новую  версию программы, включенной в систему  текущего выполнения. Необходимы бывают не только общие средства, упомянутые выше, но, зачастую, и более совершенные  средства CASE, такие, как дизайн и  средства анализа системы, анализ требований и средства трассировки, а также  средства для моделирования. Разработчики хотят иметь интегрированные  программные средства, охватывающие весь цикл разработки: анализ, проектирование, кодирование, тестирование, документирование и поддержку задачи. Для систем реального времени существуют специальные  требования к определенным областям CASE. Например, для проектирования и  анализа системы реального времени  существуют специальные методы, такие, как расширения Ward-Mellor к Структурированному Дизайну Иордана. Доступны и программные продукты, реализующие этот метод: DEC-дизайн (DEC) и TEAMWORK (Cadre).

Технические характеристики ОС реального времени

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

Таблица 1

Использование ОС реального времени в 1994 г. [1]

Хотя нас особенно интересуют системы, работающие с VMEbus, при этом не следует забывать, что ОС реального времени портируется на платформы, процессорные платы которых могут быть выполнены в различных стандартах. В таблицах 2, 3 и 4 по материалам [17] приводится более полный перечень существующих операционных систем реального времени, их основные особенности, технические характеристики и место на рынке ОС реального времени.

Рис.2 наглядно иллюстрирует положение некоторых ОС в "пространстве" адресация-класс-стандартизация [17].

Таблица 2

Таблица 3

Заключение

Существующий спектр ОС может  обеспечить все по- требности задач реального времени. Выбор системы (если абстрагироваться от цены, условий поставки и т.д.) диктует- ся только тем обстоятельством, удовлетворяет ли она усло- виям стоящей задачи. Например, если необходима операционная поддержка очень небольшой, не слишком сложной, встроенной прикладной программы, то целесооб- разно использовать Cexecutive. Если необходима очень вы- сокая скорость реакции системы, можно использовать VxWorks. Однако, в действительности, на выбор ОС влияет и ее стоимость, и наличие необходимого аппаратного обес- печения, и условия ее сопровождения. Важным фактором выбора является также поддержка системы российской ком- панией. Маркетинговые исследования, проведенные со- трудниками АО "РТСофт", проанализировавшими доступность аппаратных средств, на которых реализована система, спектр покрываемых ею конфигураций, основные технические характеристики, стоимость и условия сопро- вождения. позволяют рекомендовать для использования в отечественных системах реального времени ОС OS-9/9000.

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

Литература

1. The worldwide market tor merchant computer boards in real time and embedded applications (OEM/End user analysis).-Venture Development Corporation. 1994

2. Taking the True Measure of the Board Market. Computer Design. August 1992.

3. Harbour M. Real-Time POSIX: An Overview.- Сборник трудов международной конференции Vvconcx 93, июнь 1993 г., Москва

4. IEEE Standards Project P1003.4 POSIX Part 1: System Application Program Interface (API) - Amendment 1: Rcaltimc Extension. Draft 13.-IEEE, 1992

5. IEEE Standards Project P1003.4a Thread Extension for Portable Operating Systems. Draft 6.-IEEE, 1992

6. EEE Standards Project P1003.4b POSIX Part 1: Rcaltimc System API Extension. Draft 6.- IEEE, 1993

7. IEEE Standards Project P1003.13 Part 1: POSIX Rcaltimc A)-plication Support (AEP). Draft 5.- IEEE, 1992

8. Real-Time Operating Systems - Barbara Zikcr, DEC, 1992.

9. Bus/Board Technology & Market Report. Prepared by Warren Andrews and the editorial staff of COMPUTER DESIGN. 1992.

10. Who Makes Real Time Operating Systems. Executives, &Kcr-ncls. VMEbus Systems, 1993, v.10. N 5

11. Real Time Magazine, vol.5, Commercial Real Time Software.1991.

12. VITA Software source directory, 1991.

13. VMEbusincss, September 1991.

14. VME.VXI.FUTUREBUS+. Compatible products directory. First edition, VFEA International Trade Association. 1991.

15. IEEE Seventh Conference REAL TIME 91 on Computer Appi-cations in Nuclear, Particle and Plasma Physics. Conference Record. June 24-28, 1991.

16. Computer Design. August 1991.

17. Материалы MOTOROLA Computer Group. 1994.