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

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

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

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

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

Кафедра ПЭ 
 
 
 
 
 
 

Реферат  

Тема:

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

  Выполнил:

  студент группы ПЭ-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 обычно используется для холостого режима.

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

     1.3. Память 

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

     Модель  без защиты – системное и пользовательское адресные пространства не защищены друг от друга, используется два сегмента памяти: для кода и для данных; при этом от системы не требуется никакого управления памятью, не требуется MMU (memory management unit – специальное аппаратное устройство для поддержки управления виртуальной памятью).

     Модель защиты система/пользователь – системное адресное пространство защищено от адресного пространства пользователя, системные и пользовательские процессы выполняются в общем виртуальном адресном пространстве, при этом требуется MMU. Защита обеспечивается страничным механизмом защиты. Различаются системные и пользовательские страницы. Пользовательские приложения никак не защищены друг от друга. Процессор находится в режиме супервизора, если текущий сегмент имеет уровень 0, 1 или 2. Если уровень сегмента – 3, то процессор находится в пользовательском режиме. В этой модели необходимы четыре сегмента – два сегмента на уровне 0 (для кода и данных) и два сегмента на уровне 3. Механизм страничной защиты не добавляет накладных расходов, т.к. защита проверяется одновременно с преобразованием адреса, которое выполняет MMU; при этом ОС не нуждается в управлении памятью.

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

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

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

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

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

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

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

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

     При описании управления прерываниями обычно различают две процедуры, а именно: программа обработки прерывания (ISR – interrupt servicing routine) – программа низкого уровня в ядре с ограниченными системными вызовами, поток обработки прерывания (IST – interrupt servicing thread) – поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.

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

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

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

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

     Большинство ОСРВ оперируют относительным временем. Что-то происходит “до” и “после”  некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, то нужен тактовый генератор и/или таймер.

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

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

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

     Наиболее  ранним и распространенным стандартом ОСРВ является стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Первоначальный вариант стандарта POSIX появился в 1990 г. и был предназначен для UNIX-систем, первые версии которых появились в 70-х годах прошлого века. Спецификации POSIX определяют стандартный механизм взаимодействия прикладной программы и операционной системы и в настоящее время включают набор более чем из 30 стандартов. Для ОСРВ наиболее важны семь из них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую поддержку в коммерческих ОС получили только три первых.

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

     Некоторые наиболее успешные компании в области  систем реального времени объявляют  о своем решении принять в  качестве стандарта спецификации одной  из своих продвинутых ОСРВ. Так  поступила компания TRON (the RTOS Nucleus), которая  в 1987г. выпустила в свет первые ITRON спецификации – ITRON1. Далее в 1989г. она разработала и выпустила спецификации µITRON для 8- и 16- битовых микроконтроллеров, а также спецификации ITRON2 для 32-битовых процессоров. ОСРВ ITRON. Этот стандарт является очень распространенным в Японии.

     Военная и аэрокосмическая отрасли предъявляют  жесткие требования к вычислительным средствам, влияющим на степень безопасности целевой системы. В настоящее  время имеются следующие стандарты  для ОСРВ в авиации – стандарт DO-178B и стандарт ARINC-653. Поскольку эти стандарты разработаны в США, стоит отметить еще европейский стандарт ED-12B, который является аналогом DO-178B.

     Распространенным  также является стандарт OSEK/VDX [OSEK], который  первоначально развивался для систем автомобильной индустрии.  

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

     В связи со стандартами для ОСРВ стоит отметить широко известный  стандарт критериев оценки пригодности  компьютерных систем (Trusted Computer System Evaluation Criteria – TCSEC) [DoD85]. Этот стандарт разработан Министерством обороны США и известен также под названием "Оранжевая книга" (Orange Book – из-за цвета обложки).

     В ряде других стран были разработаны  аналогичные критерии, на основе которых  был создан международный стандарт “Общие критерии оценки безопасности информационных технологий” (далее просто – Общие критерии) (Common Criteria for IT Security Evaluation, ISO/IEC 15408) [CC99].

В "Оранжевой  книге" перечислены семь уровней  защиты:

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

     В3 – домены безопасности. Этот уровень  предназначен для защиты систем от опытных программистов.

     В2 – структурированная защита. В  систему с этим уровнем защиты нельзя допустить проникновение хакеров.

     В1 – мандатный контроль доступа. Защиту этого уровня, возможно, удастся  преодолеть опытному хакеру, но никак  не рядовым пользователям.

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

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

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

     Что касается Общих критериев, то в них  введены похожие требования обеспечения безопасности в виде оценочных уровней (Evaluation Assurance Levels – EAL). Их также семь:

     EAL7 – самый высокий уровень предполагает  формальную верификацию модели  объекта оценки. Он применим к  системам очень высокого риска. 

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

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