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

Министерство  образования Российской Федерации

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

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

КАЗАНСКИЙ ГОСУДАРСТВЕННЫЙ  ЭНЕРГЕТИЧЕСКИЙ УНИВЕРСИТЕТ 
 
 
 
 
 

Кафедра ПЭ 
 
 
 
 
 
 

Реферат  

Тема:

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

  Выполнил:

  студент группы ПЭ-06

Закиев  А.Р.

Проверил:

Ахметвалеева  Л.В

                     

                      
 
 
 
 

Казань 2010

 

      Содержание 

    Введение .           3

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

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

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

1.3 Память.           7

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

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

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

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

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

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

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

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

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

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

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

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

Заключение.                   27

Список литературы.                 28 
Введение 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     В связи с проблемами планирования в ОСРВ изучаются и развиваются  два подхода – статические  алгоритмы планирования (RMS – Rate Monotonic Scheduling) [LL73] и динамические алгоритмы  планирования (EDF – Earliest Deadline First).

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

процесс должен быть завершен за время его  периода,

процессы  не зависят друг от друга,

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

     Процессы  выполняются в соответствии с  приоритетами. При планировании RMS предпочтение отдается задачам с самыми короткими  периодами выполнения.

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

     Во  всех системах реального времени  требуется политика планирования, управляемая дедлайнами (deadline-driven scheduling). Однако этот подход находится в стадии разработки.

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

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