Система реального времени

Отличительные черты ОСРВ от ОС общего назначения

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

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

ОС реального времени

ОС общего назначения

Основная задача

Успеть среагировать на события, происходящие на оборудовании

Оптимально распределить ресурсы компьютера между пользователями и задачами

На что ориентирована

Обработка внешних событий

Обработка действий пользователя

Как позиционируется

Инструмент для создания конкретного аппаратно-программного комплекса реального времени

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

Кому предназначена

Квалифицированный разработчик

Пользователь средней квалификации

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

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

Системы жесткого реального времени не допускают никаких задержек реакции системы ни при каких условиях, так как:

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

  • стоимость опоздания может оказаться бесконечно велика.

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

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

Ядро операционной системы

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

Монолитное ядро

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

Достоинства: Скорость работы, упрощённая разработка модулей.

Недостатки: Поскольку всё ядро работает в одном адресном пространстве, сбой в одном из компонентов может нарушить работоспособность всей системы.

Примеры: Традиционные ядра UNIX (такие как BSD), Linux; ядро MS-DOS, ядро KolibriOS.

Некоторые старые монолитные ядра, в особенности систем класса UNIX/Linux, требовали перекомпиляции при любом изменении состава оборудования. Большинство современных ядер позволяют во время работы подгружать модули, выполняющие часть функций ядра. В этом случае компоненты операционной системы являются не самостоятельными модулями, а составными частями одной большой программы, называемой монолитным ядром (monolithic kernel), которое представляет собой набор процедур, каждая из которых может вызвать каждую. Все процедуры работают в привилегированном режиме.

Микроядро

Микроядро предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием. Большая часть работы осуществляется с помощью специальных пользовательских процессов, называемых сервисами. Решающим критерием «микроядерности» является размещение всех или почти всех драйверов и модулей в сервисных процессах.

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

Недостатки: Передача данных между процессами требует накладных расходов.

Среда исполнения

Требования, предъявляемые к среде исполнения систем реального времени, следующие:

  • небольшая память системы — для возможности ее встраивания;
  • система должна быть полностью резидентна в памяти, чтобы избежать замещения страниц памяти или подкачки;
  • система должна быть многозадачной — для обеспечения максимально эффективного использования всех ресурсов системы;
  • ядро с приоритетом на обслуживание прерывания. Приоритет на прерывание означает, что готовый к запуску процесс, обладающий некоторым приоритетом, обязательно имеет преимущество в очереди по отношению к процессу с более низким приоритетом, быстро заменяет последний и поступает на выполнение. Ядро заканчивает любую сервисную работу, как только поступает задача с высшим приоритетом. Это гарантирует предсказуемость системы;
  • диспетчер с приоритетом — дает возможность разработчику прикладной программы присвоить каждому загрузочному модулю приоритет, неподвластный системе. Присвоение приоритетов используется для определения очередности запуска программ, готовых к исполнению. Альтернативным такому типу диспетчеризации является диспетчеризация типа «карусель», при которой каждой готовой к продолжению программе дается равный шанс запуска. При использовании этого метода нет контроля за тем, какая программа и когда будет выполняться. В среде реального времени это недопустимо. Диспетчеризация, в основу которой положен принцип присвоения приоритета, и наличие ядра с приоритетом на прерывание позволяют разработчику прикладной программы полностью контролировать систему. Если наступает событие с высшим приоритетом, система прекращает обработку задачи с низшим приоритетом и отвечает на вновь поступивший запрос.

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

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

Ядро может обеспечивать сервис различных типов:

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

Обзор архитектур ОСРВ

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

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

Недостатки монолитной архитектуры.

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

2. Ядро не может быть прервано пользовательской задачей. Это может приводить к тому, что высокоприоритетная задача может не получить управления из-за работы низкоприоритетной.

3. Негибкость и сложность развития: изменение части ядра системы требует его полной перекомпиляции.

Рисунок 1. Архитектура монолитной ОС

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

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

Рисунок 2. Архитектура уровневой ОС

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

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

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

3. Повышается отказоустойчивость системы, т.к. «зависший» сервис может быть перезапущен без

перезагрузки системы.

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

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

Список использованной литературы:

1) http://ru.wikipedia.org/wiki/Операционная_система_реального_времени

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

Евгений Хухлаев
ИПМ им. М.В.Келдыша РАН, Москва
huh@spp.keldysh.ru

Сегодня становится широко распространенным желание потребителей использовать Windows NT в системах реального времени. Для этого имеется ряд весомых, на первый взгляд, причин: Win32 API считается стандартом, а на его базе разработано огромное количество программ; графический интерфейс стал сегодня очень популярным; для NT имеется немало готовых решений для коммерческих применений; в среду NT включены многие виды средств разработки. Тем не менее, возможно ли использование Windows NT для разработки системы реального времени?

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

1. «Жесткие» и «мягкие» системы реального времени

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

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

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

В зависимости от отношения к опозданиям системы реального времени делятся на «жесткие» (hard) и «мягкие» (soft).

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

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

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

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

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

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

    2. Удовлетворяет ли Windows NT требованиям, предъявляемым к ОС РВ?

    2.1. Нити и приоритеты

    Очевидно, что NT — многонитевая ОС, она позволяет вытеснение и тем самым удовлетворяет требованию 1 (см. врезку).

    В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около базового уровня или один из двух крайних уровней класса (16 или 31 для реального времени). Например, нить в процессе с базовым уровнем 24 может иметь приоритет 16, 22 — 26, 31. Очевидно, что гарантировать предсказуемость системы можно только при использовании процессов первого класса.

    Казалось бы, второе требование также удовлетворено. Но малое число возможных уровней препятствует реализации СРВ на базе NT. Большинство современных ОС РВ позволяет иметь по крайней мере 256 различных уровней. Чем больше имеется уровней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных уровней для нити в данном процессе. В результате многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной. Более того, общее число уровней для всех процессов класса только 16 и положение не спасает даже замена нитей процессами, не говоря уже о том, что переключение контекста для процессов снижает производительность.

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

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

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

    2.2. Предсказуемость системных вызовов Win32 API

    Для тестирования системных вызовов был написан процесс (принадлежащий классу реального времени), содержащий вызовы системы синхронизации нитей, и измерялось время, затраченное на каждый вызов. При запуске на Pentium 100 МГц с 24 Мбайт памяти оказалось, что максимальное значение на вызове mutex достигает 670 мкс при среднем времени 35 мкс. Это произошло потому, что во время работы теста происходили обращения к диску и по сети. Если компьютер искусственно загрузить обращениями к диску и сетевой обработкой, то задержки возрастают аж до нескольких миллисекунд. Win32 API очень богат, но не предназначен для реального времени. Например, запросы mutex обрабатываются в порядке поступления, а не в порядке приоритетов, что снижает предсказуемость. Для синхронизации нитей в одном процессе критические секции следует предпочесть всем другим способам (этот вызов затрачивает всего несколько мкс по сравнению с 35 мкс на вызов mutex).

    Несмотря на все достоинства API, ядро и менеджер ввода/вывода Windows NT недостаточно приспособлены к обработке событий реального времени на уровне приложений.

    2.3. Управление прерываниями в NT

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

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

  • Происходит прерывание.
  • Процессор сохраняет PC, SP и вызывает диспетчер.
  • ОС сохраняет контекст и вызывает ISR.
  • В ISR выполняется критическая работа (чтение/запись аппаратных регистров).
  • DPC ставится в очередь.
  • ОС восстанавливает контекст.
  • Процессор восстанавливает PC, SP.
  • Ожидающие в очереди DPC выполняются на уровне приоритета DISPATCH_LEVEL.
  • После завершения всех DPC ОС переходит к выполнению приложений.
  • ISR должно быть как можно короче, поэтому большинство драйверов выполняют значительную часть работы в DPC (которая может быть вытеснена другим ISR), ожидая окончания других DPC, ранее попавших в очередь (все DPC имеют одинаковый приоритет).

    Из документации по NT следует, что ISR может быть вытеснена другим ISR с более высоким приоритетом, и что DPC имеет более высокий приоритет, чем пользовательские и системные нити. Но поскольку все DPC имеют одинаковый уровень приоритета и ISR должна быть сведена к минимуму, ваш DPC будет вынужден ждать других и ваше приложение будет зависеть от остальных драйверов устройств непредсказуемым образом. Задержки системных вызовов, описанные в предыдущем разделе, обусловлены именно тем, что DPC от драйверов жесткого диска и сети блокируют все другие.

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

    2.4. Управление памятью в NT

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

    3. Может ли Windows NT использоваться в качестве ОС РВ?

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

  • загрузка CPU низка (DPC имеют достаточно времени);
  • критическая работа (или даже вся) делается на уровне DPC или (еще лучше) на уровне ISR. В таком случае непонятно, зачем вообще нужна ОС.
  • Но для жесткой СРВ использование Windows NT невозможно — система реального времени никогда не будет предсказуемой.Что следует изменить в Windows NT, чтобы ее можно было использовать в жестких СРВ?

    a) Класс процессов реального времени должен иметь больше уровней.

    б) Необходимо решить проблему инверсии приоритетов.

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

    г) Система прерываний должна быть заменена целиком:

  • DPC должны иметь много уровней приоритетов.
  • DPC должны быть вытесняемыми более приоритетными DPC.
  • Драйверы от третьих фирм и системные драйверы должны быть настраиваемыми (уровни прерываний ISR, уровни прерываний DPC)
  • Драйверы от третьих фирм должны быть открыты для разработчиков, должно быть известно по крайней мере максимальное время, затрачиваемое на работу ISR и DPC.
  • Должно быть известно время маскирования прерываний.
  • Готовы ли разработчики Microsoft ввести эти усовершенствования в NT или они полагают, что рынок слишком мал, и оставят его свободным для третьих фирм?

    4. Коммерческие решения, расширяющие NT возможностями обработки в реальном времени

    Существуют разные варианты использования технологии NT для разработки систем реального времени:

  • Использование NT как она есть для построения мягкой системы реального времени.
  • Реализация Win32 API над другой ОС РВ.
  • Совместная работа на одном процессоре NT и другой ОС РВ (или ее части).
  • Использование мультипроцессорной архитектуры, когда NT выполняется на одном процессоре (или более), а часть реального времени — на остальных.
  • Во многих решениях производители модифицируют HAL или ядро NT. Политика Microsoft заключается в том, чтобы не допускать никаких модификаций ядра NT, кроме драйверов устройств. Это единственно возможный способ связи с ядром. Политика компании относительно HAL другая. HAL (Hardware Abstraction Layer) — уровень аппаратных абстракций — уровень, лежащий ниже программного обеспечения, который виртуализирует интерфейс NT с аппаратурой, допуская переносимость NT с одной аппаратной платформы на другую. Такие модификации HAL, как манипуляции с часами или замена методов обработки прерываний, представляются беспримерно незаконным использованием HAL. Они создают нестандартную среду и могут привести к проблемам сопровождения, если, например, Microsoft изменит HAL в следующих версиях. Поэтому различие в решениях, предлагаемых поставщиками, заключается в попытках сделать модификации HAL минимальными.

    Также возможен перехват HAL посредством трюков с процессором Intel. Однако это можно реализовать только на платформе Intel. Механизмы перехвата посредством обработки исключительных ситуаций на уровне устройства поглощают определенную вычислительную мощность.

    4.1. Использование NT как таковой

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

    Иногда вводят усовершенствования в механизм обработки прерываний. Единственный способ сделать это — перехватить прерывание, для чего необходимо добавить специальное аппаратное расширение. LP-Elektronik, например, перехватывает прерывание и использует затем NMI (немаскируемое прерывание, не используемое на уровне NT) для обработки событий реального времени. Этот подход применим только тогда, когда процессор имеет отдельный стек прерываний. Программа NMI должна быть написана аккуратно: в ней нельзя использовать вызовы ОС и она должна быть как можно короче, чтобы не потерять другие прерывания. Такое решение дает минимальную задержку прерывания, но требует дополнительной аппаратуры. Как и в других решениях, здесь необходим дополнительный механизм связи между NT и частью реального времени. Разница в том, что при этом требуется большая аккуратность в использовании NMI.

    4.2. Реализация Win32 API над другой ОС РВ

    Добавление Win32 API к ОС, предназначенной для обработки в реальном времени, избавляет от необходимости модифицировать HAL или использовать другие трюки с NT. Преимущества такого подхода:

  • имеется переносимость,
  • небольшой след,
  • поведение ОС РВ известно.
  • Недостатки:

  • нельзя использовать стандартные приложения NT,
  • невозможно смешивание с драйверами устройств NT, поэтому весь мир коммуникаций NT недоступен,
  • другие драйверы графических устройств и приложения NT невозможно или трудно использовать;
  • ограничена возможность расширения в будущем,
  • необходимо использовать специальные средства разработки и компиляторы.
  • Среди коммерческих реализаций этого подхода — QNX и VxWorks, использующие библиотеку Willows.

    4.3. Совместная работа на одном процессоре NT и ОС РВ

    Мощность современных процессоров достаточна для одновременного функционирования NT и программ реального времени. Возможны две разновидности такого подхода:

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

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

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

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

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

  • Сохранение (почти) всей среды NT нетронутой означает, что все программное обеспечение, устройства и драйверы устройств NT можно использовать (чтобы выполнять части приложения, не связанные с реальным временем). Поддерживается совместимость с NT;
  • Можно включить защиту для задач реального времени, зависящую от используемой ОС РВ.
  • Недостатки:

  • Отсутствует переносимость между реальным временем и средой NT, за исключением случая, когда RT-API разработан на базе Win32;
  • драйверы устройств NT нельзя использовать в части реального времени;
  • Среда разработки усложняется, если для задач реального времени требуется отдельная среда;
  • Может быть много уровней задач и поэтому много уровней определений контекста. Переключение этих контекстов требует времени.
  • Известны следующие коммерческие реализации подхода, не требующего модификации аппаратуры: IMAGINATION с HyperKERNEL; RADISYS с комбинацией iRMX/NT; VenturCom с RTX, KPX и RTAPI.

    В реализации фирмы RadiSys ОС РВ iRMX работает, как первичная ОС, загружающая Windows NT в качестве низкоприоритетной задачи. Пользователь работает только с NT, не видя и не чувствуя iRMX. Все управляющие функции выполняются, как высокоприоритетные задачи iRMX, изолированные в памяти от приложений и драйверов NT. Используя функции защиты памяти внутри процессора Intel, Windows NT защищена от задач реального времени.

    Комбинация iRMX/NT преодолела трудности, которые возникают при модификации HAL и оставляют пользователя уязвимым при сбоях жесткого диска, сбоях драйверов и системных сбоях NT («голубой экран смерти»). В этом решении управляющая программа в случае краха NT может либо продолжить нормальное выполнение, либо произвести правильное закрытие системы (shutdown).

    Реализация фирмы VenturCom состоит из двух этапов. На первом — мягкая реализация RTX 3.1 содержит интерфейс прикладной программы реального времени RTAPI, который дает время реакции 1-5 мск. RTAPI 1.0 работает со стандартным NT. Единственное изменение, обеспечивающее лучшую синхронизацию событий реального времени, внесено в часы. Так как в Windows NT имеются некоторые плохо предсказуемые процессы, то RTAPI позволит построить только мягкую СРВ с небольшим временем отклика, но недостаточно предсказуемую. Впрочем, большую часть непредсказуемости NT можно устранить, ограничив доступ к системному диску и сети.

    Чтобы сделать NT более предсказуемой, необходимо прерывать ее внутренние задачи. В основе второй жесткой реализации RTX 4.1 лежит модификация HAL. В обеспечении детерминизма важную роль играют программируемые часы. В каждый тик часов — аппаратное прерывание с регулярными интервалами времени — предпочтение отдается задаче реального времени. Оставшееся время предоставляется процессам NT, в том числе и процессам мягкого реального времени. Чем чаще тикают часы, тем больше возможностей у процессора для выполнения задач реального времени. Необходимо добиться баланса между многими факторами: частота тиков, время, выделенное для обработки в реальном времени, время, выделенное для выполнения задач NT.

    4.4. Использование многопроцессорной архитектуры

    Простое решение здесь состоит в том, что NT выполняется на одной группе процессоров, а часть реального времени — на другой. Возможно применение архитектур параллельной шины с VMEbus, PCI, PMC или архитектур последовательной шины с Ethernet.

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

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

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

    Чудес не бывает. Если вы хотите сохранить высокую совместимость с NT, то надо будет заплатить и более высокую цену. Если вы интересуетесь только частью интерфейса Win32 API, то можете работать с ОС РВ, имеющей этот интерфейс.

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

    Необходимые требования к ОС для обеспечения предсказуемости

    Требование 1. ОС РВ должна быть многонитевой и допускать вытеснение (preemtible).

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

    Требование 2.Диспетчеризация должна осуществляться на базе приоритетов.

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

    Требование 3. Механизм синхронизации нитей должен быть предсказуемым.

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

    Требование 4. Должна существовать система наследования приоритетов.

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

    Чтобы избежать этого, ОС РВ должна допускать «наследование» приоритета, подталкивая нить с низшим приоритетом. Наследование приоритета означает, что блокирующая нить наследует приоритет нити, которую она блокирует (конечно, только если последняя обладает более высоким приоритетом).

    Требование 5.Временные характеристики ОС должны быть предсказуемы и известны.

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

    ГЛАВА 1. ОСНОВНЫЕ ПРИНЦИПЫ ОРГАНИЗАЦИИ ОПЕРАЦИОННЫХ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

    Общие положения и определения

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

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

    ОСРВ (Real-Time Operating Systems) – тип ОС. ОС РВ должна быть предсказуемой, т.е. необходимо добиться того, чтобы максимальное время, затрачиваемое на определенную работу, укладывалось в заранее установленный лимит, сравнимый с требованиями приложения.

    Рис. 1.1. Организация системы реального времени

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

    Интерфейс между управляющей подсистемой и оператором связывает человека с машиной.

    Управляемая подсистема представлена прикладными задачами, которые используют оборудование, управляемое подсистемой контроля. Эта подсистема строится из большого количества процессоров, управляющими такими местными ресурсами, как память и устройства хранения, и доступ к локальной сети в реальном масштабе времени. Эти процессоры и ресурсы управляются системой программного обеспечения, образующей операционную систему реального масштаба времени (RTOS – real time operating system).

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

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

    Есть много определений термина ОС РВ, иногда противоречащих друг другу. Самые распространённые из них:

    · ОС, в которой успешность работы любой программы зависит не только от её логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе;

    · стандарт POSIX 1003.1 даёт определение: «Реальное время в ОС – это способность ОС обеспечить требуемый уровень сервиса в определённый промежуток времени»;

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

    · интерактивные системы постоянной готовности;

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

    Для подобных систем характерно:

    · гарантированное время реакции на внешние события (прерывания от оборудования);

    · жесткая подсистема планирования процессов (высокоприоритетные задачи не должны вытесняться низкоприоритетными, за некоторыми исключениями);

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

    Такими ОС являются QNX, VxWorks, Windows CE, BeOS.

    Требования к ОС для обеспечения предсказуемости:

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

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

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

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

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

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

    Режим — реальное время

    Cтраница 1

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

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

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

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

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

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

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

    Режим реального времени используется, когда ЭВМ должна управлять работой какого-либо объекта или технологического процесса.  

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

    Для режима реального времени стараются применять ( если они справляются с задачей) мини — ЭВМ, поскольку этот режим, как правило, оказывается одновременно монопольным, а заставлять работать в монопольном режиме большую ЭВМ невыгодно. Кроме того, этот режим обычно ограничивает комплектацию системы только быстрыми устройствами памяти — ОЗУ, быстрые диски или барабаны. Операционная система для этого режима создается специальная, с более узкими функциями, но зато с меньшим временем реакции на обработку прерывания.  

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

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

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

    В режиме реального времени ЭВМ управляет объектом, реагируя на изменения контролируемых параметров или вмешательство оператора. Диалоговый режим обеспечивает обычно специальная программа — монитор, разрабатываемая самим пользователем. Комбинированный режим работы может быть организован, например, сочетанием режима разделения времени с режимом пакетной обработки или однопрограммным режимом.  

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

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

    2006 г.

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

    И.Б. Бурдонов, А.С. Косачев, В.Н. Пономаренко
    Препринт Института системного программирования РАН

    ОглавлениеВперёд

    1.

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

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

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

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

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

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

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

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

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

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

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

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

    ОглавлениеВперёд

    Добавить комментарий

    Закрыть меню