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

Что такое ОСРВ?

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

Зачем она нам нужна?

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

Обзор 3 известных ОСРВ.

Внимание: дальше идет мое личное мнение.

FreeRTOS

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

Плюсы

1) Бесплатная
2) Портирована на большое количество железа
3) Мощный функционал
4) Есть различные библиотеки: графика, интернет и другое.
5) Хорошая документация.

Минусы

1)Довольно-таки сложный процесс портирования на новое железо.

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

KeilRTX

До последнего времени эта ОСРВ была коммерческой, но недавно стала открытой. Работает только на архитектуре arm. Оффициальный сайт .

Плюсы

1)Бесплатная
2)Легко портируется на новое железо(в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.

Минусы

1)Работать на в Keil с ней практически нереально
2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.

uc/os

Мощная коммерческая ОСРВ. Сайт .

Плюсы

1) Огромное количество функций и библиотек.
2) Поддерживает много железа

Минусы

1)Коммерческая.
2) Сложна в использовании.

Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.

Другие интересные ОСРВ

RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.

Особенности разработки с использованием ОСРВ

Ну во-первых надо понять следующее: ОСРВ- это не Windows. Его нельзя установить. Эта система просто компилируется с Вашей программой.
При написании программ с ОСРВ не используются функции в обычном их понимании. Вместо функций используются процессы(или таски).Отличие в том что процессы, в отличии от функций, являются бесконечными циклами и никогда не заканчиваются(если только кто-то или он сам его не убъет - то есть выгрузит из памяти).
Если включено несколько процессов, то ОСРВ переключает их, выдавая машинное время и ресурсы по очереди. Вот тут то и возникает понятия приоритета процесса- если двум процессам единовременно нужно машинное время, то ОСРВ даст его тому, у кого приоритет больше.
В ОСРВ есть специальные функции задержки- чтобы время зря не пропадало на время задержки одного процесса выполняется второй.
Теперь поговорим о такой вещи как семафор- эта такая штука, которая управляет доступом процесса к ресурсам приложения. Для каждого ресурса есть маркер - когда процессу нужен ресурс - он его забирает и пользуется данным ресурсом. Если маркера нет, то процессу придется ждать, пока его вернут. Приведу пример: разные процессы отправляют информацию по одному UART. Если бы не было семафора, то они бы отправляли байты по очереди и получилась бы неразбериха. А так первый процесс взял маркер на UART отправил сообщение и отдал второму(и так - до бесконечности).

Дополнительные библиотеки ОСРВ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Микроядро

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5)http://www.ozon.ru/context/detail/id/3092042/

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

Основными ресурсами являются процессор (процессорное время), оперативная память и периферийные устройства.

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

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

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

В настоящее время существует большое разнообразие ОС, которые классифицируются по следующим признакам:

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

o число процессов, которые могут одновременно выполняться под управлением ОС;

o тип доступа пользователя к системе;

o тип аппаратно-программного комплекса.

В соответствии с первым признаком различаются одно- и многопользовательские ОС.

Второй признак делит ОС на одно- и многозадачные.

В соответствии с третьим признаком ОС делятся на:

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

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

o системы реального времени, которые должны обеспечивать гарантированное время ответа на внешние события (более подробно см. ниже).

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

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

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

1.1 Что такое система реального времени

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

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

Что такое ОСРВ?

Зачем она нам нужна?

Обзор 3 известных ОСРВ.

Внимание: дальше идет мое личное мнение.

FreeRTOS

Плюсы

Минусы

1)Довольно-таки сложный процесс портирования на новое железо.

KeilRTX

Плюсы

Минусы

uc/os

Мощная коммерческая ОСРВ. Сайт .

Плюсы

1) Огромное количество функций и библиотек.
2) Поддерживает много железа

Минусы

1)Коммерческая.
2) Сложна в использовании.

Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.

Другие интересные ОСРВ

RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.

Особенности разработки с использованием ОСРВ

Дополнительные библиотеки ОСРВ.

Что такое реальное время (real-time)?

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

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

Иногда системой реального времени называют интерактивную систему с малым временем отклика. Рассмотрим следующий пример: набор текста в программе WinWord 2.0 на компьютере с процессором Athlon 1GHz. Время отклика в данном случае — это промежуток времени между нажатием клавиши и отображением соответствующей буквы в окне программы. Кажется очевидным, что эта величина в данном случае не имеет значения — все равно человек печатает медленнее. Ошибка заключается в подмене понятий — высокая скорость отклика совсем не означает гарантированность отклика. Загружая компьютер большим количеством ресурсоемких задач, мы можем увеличивать время отклика до бесконечности. Проделай следующий опыт: поместив ярлыки всех установленных программ (желательно, чтобы среди них были такие монстрообразные приложения, как Borland Delphi, Microsoft Office, и пара-тройка 3D-шутеров) на рабочий стол Windows95 (желательно билд 450 или более ранний:), выдели их мышью и нажми Enter. После этого винда будет громыхать жестким диском, жонглируя данными между своп-файлом и памятью, и не реагируя на какие-либо внешние воздействия, пока ты не нажмешь кнопку Reset. Обычно этого достаточно, чтобы понять, что быстрая система — не обязательно система реального времени. С другой стороны, реальное время не означает скорость выполнения программы; более того, алгоритмы, гарантирующие конечное время отклика, часто менее эффективны, чем обычные.

В англоязычной литературе упоминаются «soft real-time systems» и «hard real-time systems», но в этом случае не подразумевается программная (software) или аппаратная (hardware) реализация системы реального времени. Термин hard означает, что время отклика (LT — latency time) жестко задано, т.е. является константой. Мягкая (soft) система реального времени (RTS — real-time system) может изменять LT, что увеличивает эффективность RTS, манипулирующей процессами с различными приоритетами. Например, для оцифровки одного кадра видеопотока достаточно LT=0.033с (30 кадров/сек), а для процесса управления сервоприводами необходимо достичь значения LT порядка десятков микросекунд. Иногда термином hard обозначают классическую (описанную выше) модель RTS, а термином soft — систему, не являющуюся RTS в чистом виде, но LT которой снижена до необходимого уровня, обеспечивающего требуемую скорость обработки данных. Например, если компьютер под управлением DOS обрабатывает данные с электронного осциллографа, то это — SoftRTS, т.к. DOS — однозадачная операционная система, и, при условии достаточной скорости компьютера и нормальной работы осциллографа, ничто не должно помешать нам обрабатывать данные с достаточной скоростью (но гарантировать этого мы не можем!). В многозадачных операционных системах также возможна реализация SoftRTS, причем применяемая обычно в мультимедийных приложениях и 3D-играх, т.к. они позволяют обеспечить требуемое LT путем ухудшения качества обработки данных (снижение битрейта, уменьшение FPS, изменение разрешения экрана и глубины цвета).

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

Понимание принципа действия и основных свойств операционных систем реального времени (RTOS — Real Time Operating System) требует введения таких базовых определений, как микроядро (microkernel) и макроядро (macrokernel).

Существует две основные школы ядростроителей (не смог подобрать более точного перевода для kernel
developers:): одна считает, что ядро операционной системы должно быть компактным и быстрым, а функциональность рассредоточена в процессах, другая проповедует более традиционный подход, предоставляя ядру все базовые функции ОС, а процессам — ничего, кроме возможности вызова этих самых функций. Для обозначения первого (по перечислению, а не по времени появления) типа архитектуры в 1989 году Ирой Голдштейн и Полом Дейлом был введен термин микроядро (microkernel). Первая (теперь — в хронологическом смысле) архитектура ядра (традиционная, или монолитная (monolithic), как ее называют в англоязычной литературе) получила название «макроядро» (что наглядно доказывает низкий уровень воображения у программистов, особенно системных).

Споры о том, какая архитектура лучше, идут до сих пор. Большинство реализаций ОС UNIX построены на макроядре, в том числе наиболее популярные на сегодняшний день — Linux и FreeBSD. На микроядре построены такие операционные системы, как Mach и QNX. Впрочем, некоторые системщики не относят Mach к микрокернелам по причине большого размера ядра (оно включает в себя драйвера устройств, что типично скорее для макрокернелов). С ядром QNX сложилась обратная ситуация — оно настолько мало (и по размеру, и по
функциональности), что пришлось ввести новый термин — наноядро (nanokernel). Думаю, что споры вокруг Mach можно было бы решить тем же путем, т.е. изменением терминологии — но, судя по всему, слова сантикернел и децикернел показались программистам недостаточно благозвучными. Следует понимать, что разграничение ОС на микроядра и макроядра производится вовсе не по размеру ядра, а по его архитектуре, т.е. по соотношению между количеством функций, реализованных в ядре, и функций, реализованных вовне ядра. Другие параметры (производительность, гибкость, работа в реальном времени) не могут быть признаками такого разграничения. Кроме того, граница между макрокернелами и микрокернелами становится все более размытой благодаря тому, что многие современные монолитные ядра содержат так называемые нити (threads) и обладают способностью к «мелкозернистому» распараллериванию (а как еще перевести fine-grained parallerism?). Архитектурно такие ядра подобны микрокернелам с большим количеством процессов, работающих в разделяемой (shared) памяти.

Возможность операционной системы работать в реальном времени в значительной степени определяется архитектурой ядра. Наиболее удобными в этом плане являются микроядра (собственно, для этого они и разрабатывались), но это не означает, что все микрокернелы работают в реальном времени (Mach — микроядро, не работающее в реальном времени, что вовсе не умаляет других достоинств этой операционной системы, породившей множество потомков, в том числе NeXTStep, Hurd, BeOS и MacOSX). Существование макрокернела с полноценной поддержкой работы в реальном времени все еще под вопросом (я не нашел никаких сведений о подобном проекте, кроме, разве что, Sun Solaris 2.x, но по моему мнению (не претендующему на компетентность), это скорее SoftRTS, а не HardRTS), а вот частичная реализация — обычное дело. Например, в Linux активно внедряются упоминавшиеся ранее межпроцессорные (от слова процесс, а не процессор) нити, причем уже существует большое количество приложений (первым был Web-сервер Apache), пользующихся этим интерфейсом.

QNX RTOS

Самая популярная в России RTOS — QNX 4.0 (вообще-то Windows NT, но ты много видел людей, которые юзают эНТю именно из-за этого?). Среди других unix-клонов она также занимает уверенное положение — пенетрация (т.е. захваченная доля рынка) этой ОС составляет приблизительно 8-10% — большей распространенности добились только Linux и FreeBSD (захватившие в сумме около половины российского рынка unix-систем). Несмотря на то, что QNX изначально является коммерческой, закрытой и проприетарной, в настоящее время ее модель лицензирования допускает получение и использование на безвозмездной основе как самой ОС (в минимальной конфигурации, конечно, и не для коммерческого использования, но — повторюсь — абсолютно бесплатно и без ограничений по времени), так и исходных кодов (тоже не всех и не для всех — но и это уже немало).

В чем же крутость этой ОС? Тот факт, что она многозадачная, многопользовательская, модульная и POSIX-совместимая, может удивить разве что бородатых полярников, которые свято верят, что пингвин — это такая еда:). Кстати, ОС эта раза в 2 постарше Лынукса. Впрочем, это не показатель. Ты только подумай — 8К микроядро (да-да, восемь килобайт!). Вот это показатель! Именно так достигается рекордное время переключения контекста — 2,5 наносекунды. Дело в том, что ядро управляет только разделением времени между процессами и передачей сообщений. Даже управление процессами и распределение ресурсов для процессов осуществляется отдельной прогой, которая так и называется — менеджер процессов, причем делает это она в соответствии с POSIX 1003.4 (это специальный стандарт на ОСРВ — почитай его, если надумаешь делать GNU QNX:).

Другие характеристики тебя вряд ли заинтересуют — они и не каждому QNX-профи известны и нужны. Поэтому про 12 возможных вызовов микроядра, 32 уровня приоритета и три алгоритма разделения времени (FIFO, круговой и адаптивный) я даже и не заикаюсь.

А вот требования к оборудованию очень советую почитать внимательно:

CPU: 8088, 80286, 80386 и выше
RAM: менее 640Кб (для исполнения), 2Mб (для разработки)
HDD: 5Мб для ОС и утилит (для системы программирования
— еще 4Мб); возможна бездисковая конфигурация.

Только не думай, что требования такие скромные, потому что система примитивная. Самая современная версия QNX (Neutrino 6.2.1) почти такая же жадная до ресурсов, как ХР. Что, испугался? 🙂 Я же сказал — почти! К тому же никто не мешает тебе установить QNX4 на 386 и наслаждаться. Препарируй на здоровье!