RTOS (Real-Time Operating System)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 16:53, 24 августа 2017.

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

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

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

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

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

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

Отличительные черты RTOS

Таблица сравнения операционных систем реального времени (ОСРВ) и обычных операционных систем.

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


Архитектура

Cтруктура ОСРВ эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер:

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

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

Особенности ядра

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

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

Важной частью любой ОСРВ является планировщик задач, чья функция - определить, какая из задач должна выполняться в системе в каждый конкретный момент времени. К основным методам планирования обычно относят: циклический алгоритм (в стиле round robin), разделение времени с равнодоступностью (time sharing with fairness), кооперативную многозадачность. Наиболее часто используемый в ОСРВ принцип планирования - приоритетная многозадачность с вытеснением. Основная идея состоит в том, что высокоприоритетная задача, как только для нее появляется работа, немедленно прерывает (вытесняет) низкоприоритетную. Однако диапазон систем реального времени весьма широк, начиная от полностью статических систем, где все задачи и их приоритеты заранее определены, до динамических систем, где набор выполняемых задач, их приоритеты и даже алгоритмы планирования могут меняться в процессе функционирования. Существуют, например, системы, где каждая отдельная задача может участвовать в любом из трех алгоритмов планирования или их комбинации (вытеснение, разделение времени, кооперативность). Кроме того, приоритеты тоже можно назначать по-разному. В общем случае алгоритмы планирования должны соответствовать критериям оптимальности функционирования системы. Однако, если для систем жесткого реального времени такой критерий очевиден , то для систем мягкого реального времени это может быть, например, минимальное максимальное запаздывание или средневзвешенная своевременность завершения операций. В зависимости от критериев оптимальности могут применяться алгоритмы планирования задач, отличные от рассмотренных. Например, может оказаться, что планировщик должен анализировать момент выдачи критичных по времени управляющих воздействий и запускать на выполнение ту задачу, которая отвечает за ближайшее из них (алгоритм earliest deadline first, EDF).

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

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

Планирование задач

Работа планировщика

Планировщик задач - это модуль (программа), отвечающий за разделение времени имеющихся процессоров между выполняющимися задачами. Отвечает за коммутацию задач из состояния блокировки в состояние готовности, и за выбор задачи (задач - по числу процессоров) из числа готовых для исполнения процессором. Наиболее часто используемый в ОСРВ принцип планирования - приоритетная многозадачность с вытеснением . Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путём реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого в том, что высокоприоритетная задача, как только для нее появляется работа, немедленно прерывает (вытесняет) низкоприоритетную. Но из этого выходит, что если какая-то задача в высоким, которая использует все возможные ресурсы, то никакие другие задачи с низким приоритетом не будут выполняться до тех пор, пока этот процесс не прекратит свою работу. Таким образом, разработчикам нужно тщательно программировать свои приложения с учетом приоритетов. Каждый раз, когда планировщику задач получается сигнал о наступлении некоторого внешнего события ( триггер ), он действует по след алгоритму:

  1. Определяет, должна ли текущая выполняемая задача продолжать работать.
  2. Устанавливает, какая задача должна запускаться следующей.
  3. Сохраняет контекст остановленной задачи (чтобы она потом возобновила работу с места остановки).
  4. Устанавливает контекст для следующей задачи.
  5. Запускает эту задачу.

Выполнение задачи

В обычных ОСРВ, задача имеет три состояния

  • Выполняется
  • Готова к выполнению
  • Заблокирована

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

Алгоритмы планирования

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

  • Статические алгоритмы планирования (RMS, Rate Monotonic Scheduling). Используют приоритетное вытесняющее планирование. Приоритет присваивается каждой задаче до того, как она начала выполняться. Преимущество отдается задачам с самыми короткими периодами выполнения.
  • Динамические алгоритмы планирования (EDF, Earliest Deadline First Scheduling). Приоритет задачам присваивается динамически, причем предпочтение отдается задачам с наиболее ранним предельным временем начала (завершения) выполнения.

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

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

Вытесняющее планирование с использованием круговой стратегии

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

Невытесняющее планирование на основе приоритетов

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

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

Вытесняющее планирование на основе приоритетов с точками вытеснения

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

Вытесняющее планирование на основе приоритетов с немедленным вытеснением

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

Взаимодействие между задачами и разделение ресурсов

Многозадачным системам необходимо распределять доступ к ресурсам. Одновременный доступ двух и более процессов к какой-либо области памяти или другим ресурсам представляет определённую угрозу. А именно Deadloc и Priority inversionСуществует три способа решения этой проблемы:

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

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

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

Распределение (Выделение) памяти

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

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

Примеры ОСРВ

  • QNX
  • OS-9
  • VxWorks/Tornado
  • IA-SPOX
  • RTX
  • Falcon
  • Hyperkernel

Источники

Литература

  • И. Б. Бурдонов, А. С. Косачев, В. Н. Пономаренко "Операционные системы реального времени", препринт Института системного программирования РАН, 2006 г.
  • National Instrument [Электронный ресурс]: What is a Real-Time Operating System (RTOS)? / Дата обращения: 24 декабря 2016. - Режим доступа: http://www.ni.com/white-paper/3938/en/
  • Семенюк В. "Системы реального времени". - Режим доступа: http://embedded.ifmo.ru/embedded_old/ETC/REFERAT/1998_1/HTMLRTOS/rtos97.htm

Ссылки