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

    Федеральное агентство по образованию

    Федеральное государственное образовательное  учреждение

    высшего профессионального образования

    «Сибирский  федеральный университет»

    ____________________________________________________

    Лесосибирский педагогический институт -

    филиал  Федерального государственного образовательного учреждения

    высшего профессионального образования

    «Сибирский  федеральный университет» 
 

    Факультет  Физико-математический (очная форма обучения)

    Специальность «Информатика»

• ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

• (Курсовая  работа)
 
 
 
 
 
 


Исполнитель:

студент 4 курса ФМФ группы ДЛМ06-03СФИ Мигранов И.В.

Научный руководитель:

Ассистент кафедры МАиВМ

Губанова  А.А. 
 
 
 


Лесосибирск 2009

            Оглавление 


Введение
§1. Особенности операционных систем реального времени	5
1.1 Классификация операционных систем	5
1.2 Особенности  операционных систем реального  времени	8
1.2.1 Системы жёсткого и мягкого  реального времени	12
1.2.2 Архитектуры  операционных систем реального  времени	14
1.2.3 Ядро операционной системы реального времени	17
1.3 Функциональные требования к  операционным системам реального  времени	20
§2. Обзор операционных систем реального  времени	29
Заключение	41
Список  литературы	42

 


Введение 


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

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

    Цель  исследования: Обобщение теоретического материала по теме «Операционные системы реального времени» (ОСРВ)

    Объект  изучения: Операционные системы реального времени

    Предмет изучения: Практическое применение ОСРВ

    Задачи:

• проанализировать учебную и научную литературу по теме исследования;
• рассмотреть классификацию ОСРВ;
• познакомиться с особенностями ОСРВ и выделить функциональные требования к ним;
• рассмотреть наиболее популярные ОСРВ

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


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


1. Классификация операционных систем
 


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

    Основными ресурсами являются процессор (процессорное время), оперативная память и периферийные устройства.

    Управление ресурсами сводится к выполнению следующих задач: упрощение доступа к ресурсам; распределение их между процессами.

    Реализация  первой функции позволяет “спрятать” аппаратные особенности вычислительной системы и тем самым предоставить в распоряжение пользователю или программисту виртуальную машину с существенно облегченным управлением.

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

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

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

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

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


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

    В соответствии с третьим признаком ОС делятся:

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

    Четвертый признак делит ОС на одно- и многопроцессорные, сетевые и распределенные.

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

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

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

    

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


   Существует  несколько определений операционных систем реального времени (ОСРВ):

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

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

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

    Таблица 1

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

Прикладное  ПО	Потоки	Диспетчеризация
		Меж-потоковое  взаимодействие
ОСРВ	API	Обработка прерывания
	Защита  от инверсии приоритетов	Управление  потоками
	I/O	Управление  памятью
Аппаратное  обеспечение	CPU	Кэш	Устройства

 


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

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

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

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

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


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

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

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

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

    Обобщая вышеизложенный материал, выведем таблицу 2. 
 
 
 


    Таблица 2

    Сравнение ОСРВ с ОС общего назначения

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

 


    Общие характеристики СРВ: 


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


    Основные  требования к СРВ:

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


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


    Принято различать системы мягкого (soft) и  жесткого (hard) реального времени.

    В жесткой системе:

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

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

    В мягкой системе реального времени:

• повышается стоимость опоздания;
• допускается низкая производительность в случае опоздания.

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

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

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

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

    1.2.2 Архитектуры операционных  систем реального времени 


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

    

Рис. 1. Архитектура  монолитной операционной системы  


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

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

Рис. 2. Архитектура  уровневой операционной системы 


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

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

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

1.2.3 Ядро операционных  систем реального  времени 


    Ядро  операционной системы реального  времени (RTOS — Real-time Operating System) является абстрактным уровнем, скрывающим от прикладного ПО аппаратные особенности процессора (или набора процессоров), на котором прикладное ПО будет работать. Это обеспечивается за счет предоставления прикладному ПО доступа к пяти основным категориям базовых служб (функций) (рис. 4). 


    

    Рис.4. Основные службы, предоставляемые ядром  ОС реального времени 


• Управление  задачами. Самая главная группа сервисов. Позволяет разработчикам приложений проектировать программные продукты в виде наборов отдельных программных фрагментов, каждый из которых может относиться к своей тематической области, выполнять отдельную функцию и иметь свой собственный квант времени, отведенный ему для работы. Каждый такой фрагмент называется задачей. Сервисы в рассматриваемой группе обладают способностью запускать задачи и присваивать им приоритеты. Основной сервис здесь — планировщик задач. Он осуществляет контроль за выполнением текущих задач, запускает новые в соответствующий период времени и следит за режимом их работы.
• Динамическое распределение памяти. Многие (но не все) ядра ОСРВ поддерживают эту группу сервисов. Она позволяет задачам заимствовать области оперативной памяти для временного использования в работе приложений. Часто эти области впоследствии переходят от задачи к задаче, и посредством этого осуществляется быстрая передача большого количества данных между ними. Некоторые очень малые по размеру ядра ОСРВ, которые предполагается использовать в аппаратных средах с строгим ограничением на объём используемой памяти, не поддерживают сервисы динамического распределения памяти.
• Управление таймерами. Так как встроенные системы предъявляют жесткие требования к временным рамкам выполнения задач, в состав ядра ОСРВ включается группа сервисов, обеспечивающих управление таймерами для отслеживания лимита времени, в течение которого должна выполняться задача. Эти сервисы измеряют и задают различные промежутки времени (от 1 мкс и выше), генерируют прерывания по истечении временных интервалов и создают разовые и циклические будильники.
• Взаимодействие между задачами и синхронизация. Сервисы данной группы позволяют задачам обмениваться информацией и обеспечивают её сохранность. Они так же дают возможность программным фрагментам согласовывать между собой свою работу для повышения эффективности. Если исключить эти сервисы из состава ядра ОСРВ, то задачи начнут обмениваться искаженной информацией и могут стать помехой для работы соседних задач.
• Контроль устройства ввода/вывода. Сервисы этой группы обеспечивают работу единого программного интерфейса, взаимодействующего со всем множеством драйверов устройств, которые являются типичными для большинства встроенных систем.
 


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

    1.3 Назначение операционных  систем реального  времени 


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

Основные  области применения ОСРВ:

• Военная и космическая области: бортовое и встраиваемое оборудование:

— системы  измерения и управления, радары;

— цифровые видеосистемы, симуляторы;

— ракеты, системы определения положения  и привязки к местности.

• Промышленность:

— автоматические системы управления производством (АСУП) (computer aided manufacturing (CAM)), автоматические системы управления технологическим процессом (АСУГП);

— автомобилестроение: стимуляторы, системы: управления мотором, автоматическое сцепление, системы  антиблокировки колес;

— энергетика: сбор информации, управление данными и оборудованием;

— телекоммуникации: коммуникационное оборудование, сетевые  коммутаторы, телефонные станции;

— банковское оборудование (например, во многих  банкоматах работает ОСРВ QNX).

• Товары широкого потребления:

— мобильные  телефоны, например, в телефонах стандарта GSM работает ОСРВ pSOS;

— цифровые телевизионные декодеры;

— цифровое телевидение (мультимедиа, видеосерверы);

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

    1.4 Функциональные требования  к операционным  системам реального  времени 


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

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

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

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

    Каждый  поток имеет важное свойство, на основании которого ОС принимает решение о том, когда предоставить ему время процессора. Это свойство называется приоритетом потока и выражается целочисленным значением. Количество приоритетов (или уровней приоритетов) определяется функциональными возможностями ОС, при этом самое низкое значение (0) закрепляется за потоком idle ОС, который предназначен для корректной работы системы, когда ей «ничего не надо делать».

    Поток может находиться в одном из следующих  состояний:

1. Активный поток – это тот поток, который в данный момент выполняется системой.
2. Поток в состоянии готовности – поток, который может выполняться и ждет своей очереди.
3. Блокированный поток – поток, который не может выполняться по некоторым причинам (например, ожидание события или освобождения нужного ресурса).

    Далее рассматриваются функциональные требования, предъявляемые на данном этапе к  ОС применяющимся в СРВ. 


    Диспетчеризация потоков  


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

1. FIFO (First In First Out) – Первый Вошел Первый Вышел. Первой выполняется задача, первой вошедшая в очередь, при этом она выполняется до тех пор, пока не закончит свою работу или не будет заблокирована в ожидании освобождения некоторого ресурса или события. После этого управление передается следующей в очереди задаче.
2. Карусельная многозадачность (round robin). При этом методе диспетчеризации в системе определяется специализированная константа, определяющая продолжительность непрерывного выполнения потока, т.н. квант времени выполнения. Таким образом, выполнение потока может быть прервано либо окончанием его работы, либо блокированием в ожидании ресурса или события, либо завершением кванта времени. После этого управление передается следующему в очередности потоку. После окончания времени последнего потока управление передается первому потоку, находящемуся в состоянии готовности. Таким образом, выполнение каждого потока разбито на последовательность временных циклов.

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

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

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

    Для СРВ, применяющихся в обработке периодических событий, в 1970 году Лиу и Лейленд предложили математический аппарат, позволяющий определить, является ли система диспетчируемой. Этот аппарат называется «Частотно монотонный анализ» (ЧМА) (Rate Monotonic Analyzing). Эффективность этого математического аппарата привела к тому, что ЧМА был принят в качестве стандарта такими организациями как USA Department of Defense, Boeing, General Dynamics, Magnavox, Mitre, NASA, Panamax, и др. Также среди организаций, установивших ЧМА в качестве стандартного средства анализа и разработки систем жесткого реального времени можно отметить IBM Federal Sector Division, US Navy и European Space Agency.

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

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


    Уровни  приоритетов 


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

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

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

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


    Механизмы синхронизации 


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

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


    Защита  от инверсии приоритетов 


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

    Какие же механизмы защиты от этой проблемы используют разработчики операционных систем реального времени? Наиболее широко распространенный и проверенный механизм – это наследование приоритетов.

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

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

    Другой, несколько менее распространенный метод, называется Протокол Предельного  Приоритета. Метод этот заключается  в добавлении к стандартным свойствам  объектов синхронизации параметра, определяемого максимальным приоритетом потока, которые к этому объекту обращаются. Если этот параметр установлен, то приоритет любого потока, обращающегося к этому объекту синхронизации, будет увеличен до указанного уровня, и, таким образом, не сможет быть вытеснен никаким потоком, который может нуждаться в заблокированном им ресурсе. После разблокирования ресурса, приоритет потока понижается до начального уровня. Таким образом, получается нечто вроде предварительного наследования приоритетов. Однако этот метод имеет ряд серьезных недостатков. В первую очередь, на разработчика ложиться работа по «обучению» объектов синхронизации их уровню приоритетов. Во вторых, возможны задержки в запуске высокоприоритетных потоков на время отработки низкоприоритетных потоков. В целом максимально эффективно этот механизм может быть использован в случае, когда имеется один поток жесткого реального времени и несколько менее приоритетных потоков, разделяющих с ним ресурсы.

    §2. Обзор операционных систем реального  времени 


    VxWorks 


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

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

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

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

    QNX 


    Операционная  система QNX Neutrino Realtime Operating System (RTOS) [QNXNeutrino] корпорации QNX Software Systems является микроядерной операционной системой, которая обеспечивает многозадачный режим с приоритетами. QNX Neutrino RTOS имеет клиент-серверную архитектуру. В среде QNX Neutrino каждый драйвер, приложение, протокол и файловая система выполняются вне ядра, в защищенном адресном пространстве. В случае сбоя любого компонента он может автоматически перезапуститься без влияния на другие компоненты или ядро. Хотя система QNX является конфигурируемой, т.е. отдельные модули можно загружать статически или динамически, нельзя сказать, что она использует подход, основанный на компонентах. Все модули полагаются на базовое ядро и спроектированы таким образом, что не могут использоваться в других средах.  


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


    ChorusOS 


    Операционная  система ChorusOS – это масштабируемая встраиваемая ОС, широко применяемая в телекоммуникационной индустрии. В настоящее время этот бренд развивается и распространяется корпорацией Sun Microsystems [CHORUSOS]. Для компоновки и развертывания ОС ChorusOS на конкретных телекоммуникационных платформах Sun Microsystems предлагает использовать среду разработки Sun Embedded Workshop. Корпорация Sun Microsystems представляет ОС ChorusOS как встраиваемую основу для Sun’овской сети, управляемой сервисами (Sun's Service-Driven Network). В сочетании с широким набором сервисов, полной интеграцией ПО и аппаратуры, удобным администрированием и поддержкой Java-технологии, которая посвящена нуждам телекоммуникации, ОС ChorusOS дает возможность эффективно развертывать новые возможности и приложения, поддерживая надежность и функциональность современных сетей. 


    TinyOS 


    Разработка  операционной системы TinyOS связана с появлением новой концепции беспроводной связи – Motes.

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

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

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

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

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


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

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

    В системе предусмотрена также  отдельная абстракция задачи, понимаемая как продолжительный вычислительный процесс. Взаимоотношение между понятиями “команда” и “задача” следующее: команда – это атомарная составляющая задачи. Команда ставится в очередь на исполнение планировщика, затем она выполняется и может быть временно прервана обработкой события.

    Планировщик работает по принципу очереди FIFO, т.е. для передачи управления следующей задаче требуется полное завершение предыдущей задачи. Однако, в зависимости от требований приложения, могут использоваться и более сложные механизмы планирования, основанные на приоритетах или на дедлайнах. Ключевым моментом является то, что планировщик ориентирован на энергосбережение: процессор засыпает, если очередь планировщика пуста, а периферийные устройства работают, и каждое из них может разбудить систему. Когда очередь становится пустой, новый поток может быть запущен на исполнение только в результате какого-либо события, которое может возникнуть только в аппаратных устройствах. Планировщик имеет крайне малые размеры – всего 178 байтов, данные планировщика занимают только 16 байтов.

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

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

    Для обеспечения динамичности во время  выполнения была разработана виртуальная  машина, которая является надстройкой  над ОС TinyOS. Код для виртуальной машины можно загрузить в систему во время выполнения. Для работы этой виртуальной машины необходимы 600 байт оперативной памяти и менее 8 KB памяти команд 8-битового микроконтроллера. Программы виртуальной машины представляются 8-битовыми инструкциями всего трех типов, объединяемых в "капсулы" – атомарные последовательности не более чем двадцати четырех инструкций.

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

    Заключение 


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

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

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

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

    Таким образом, поставленные нами задачи решены.

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


1. Горошко Е. Г. Операционные системы реального  времени – Харьков, 2003
2. Сорокин С. В. Системы Реального Времени – СТА, 1997 №2
3. И.Б. Бурдонов, А.С. Косачев, В.Н. Пономаренко Операционные системы реального времени – 2006
4. ОС реального времени URL: http://www.eduhmao.ru/info/1/3664/22961/
5. Жданов А.А. Операционные системы реального времени – PCWeek, 1999 №8
6. А. А. Блискавицкий, С. В. Кабаев. Операционные системы реального времени (обзор) компьютерной автоматизации. URL: http://www.asutp.ru.