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

Запрос «ОСРВ» перенаправляется сюда; о советском клоне системы RSX-11 см. ОСРВ СМ ЭВМ.

Операционная система реального времени (ОСРВ, англ. real-time operating system, RTOS) — тип специализированной операционной системы, основное назначение которой — предоставление необходимого и достаточного набора функций для проектирования, разработки и функционирования систем реального времени на конкретном аппаратном оборудовании.

Спецификация UNIX в редакции 2 даёт следующее определение:

Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени.

Оригинальный текст (англ.)[показатьскрыть]

Realtime in operating systems: the ability of the operating system to provide a required level of service in a bounded response time.

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

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

Операционные системы реального времени иногда делят на два типа — системы жёсткого реального времени и системы мягкого реального времени.

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

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

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

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

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

Большинство программного обеспечения ориентировано на «мягкое» реальное время. Для подобных систем характерно:

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

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

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

Отличительные черты ОСРВПравить

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

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

Архитектуры ОСРВПравить

В своем развитии ОСРВ строились на основе следующих архитектур:

• Монолитная архитектура. ОС определяется как набор модулей, взаимодействующих между собой внутри ядра системы и предоставляющих прикладному ПО входные интерфейсы для обращений к аппаратуре. Основной недостаток этого принципа построения ОС заключается в плохой предсказуемости её поведения, вызванной сложным взаимодействием модулей между собой.
• Уровневая (слоевая) архитектура. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и её сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. Главным недостатком таких систем является отсутствие многозадачности.
• Архитектура «клиент-сервер». Основной её принцип заключается в вынесении сервисов ОС в виде серверов на уровень пользователя и выполнении микроядром функций диспетчера сообщений между клиентскими пользовательскими программами и серверами — системными сервисами. Преимущества такой архитектуры:

1. Повышенная надёжность, так как каждый сервис является, по сути, самостоятельным приложением и его легче отладить и отследить ошибки.
2. Улучшенная масштабируемость, поскольку ненужные сервисы могут быть исключены из системы без ущерба к её работоспособности.
3. Повышенная отказоустойчивость, так как «зависший» сервис может быть перезапущен без перезагрузки системы.

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

Монолитная архитектура	Уровневая (слоевая) архитектура	Архитектура «клиент–сервер»

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

Основная статья: Ядро операционной системы

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

Основные сервисыПравить

Указанный абстрактный уровень предоставляет для прикладного ПО пять основных категорий сервисов:

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

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

Отличия от операционных систем общего назначенияПравить

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

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

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

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

Основная статья: Диспетчер операционной системы

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

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

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

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

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

Эти пять шагов алгоритма также называются переключением задач.

Выполнение задачиПравить

В обычных ОСРВ задача может находиться в трёх возможных состояниях:

• задача выполняется;
• задача готова к выполнению;
• задача заблокирована.

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

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

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

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

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

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

При больших загрузках системы EDF более эффективен, нежели RMS.

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

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

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

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

Выделение памятиПравить

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

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

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

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

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

ЛитератураПравить

• Зыль С. Операционная система реального времени QNX: от теории к практике. — 2-е изд. — СПб.: БХВ-Петербург, 2004. — 192 с. — ISBN 5-94157-486-X.
• Зыль С. QNX Momentics. Основы применения. — СПб.: БХВ-Петербург, 2004. — 256 с. — ISBN 5-94157-430-4.
• Кёртен Р. Введение в QNX/Neutrino 2. — СПб.: Петрополис, 2001. — 512 с. — ISBN 5-94656-025-9.
• Ослэндер Д. М., Риджли Дж. Р., Рингенберг Дж. Д. Управляющие программы для механических систем: Объектно-ориентированное проектирование систем реального времени. — М.: Бином. Лаборатория знаний, 2004. — 416 с. — ISBN 5-94774-097-4.

СсылкиПравить

• Операционные системы реального времени Архивная копия от 18 января 2009 на Wayback Machine
• Цикл статей про FreeRTOS Архивная копия от 31 декабря 2011 на Wayback Machine
• Обзор операционных систем реального времени (недоступная ссылка с 01-04-2014 [3230 дней])
• National Instruments, What is a Real-Time Operating System (RTOS)? Архивная копия от 6 октября 2014 на Wayback Machine (white paper) 2013 (англ.)