ОСРВ - Операционная Система Реального Времени. Основные понятия

Существует несколько определений систем реального времени (СРВ), большинство из
которых противоречат друг другу. Приведем несколько из них, чтобы продемонстрировать
различные взгляды на назначение и основные задачи СРВ.
1. Системой реального времени называется система, в которой успешность работы любой
программы зависит не только от ее логической правильности, но от времени, за которое она
получила результат. Если временные ограничения не удовлетворены, то фиксируется сбой в работе
системы.
Таким образом, временные ограничения должны быть гарантировано удовлетворены. Это
требует от системы быть предсказуемой, т.е. вне зависимости от своего текущего состояния и
загруженности выдавать нужный результат за требуемое время. При этом желательно, чтобы
система обеспечивала как можно больший процент использования имеющихся ресурсов.
2. Стандарт POSIX 1003.1 определяет СРВ следующим образом: «Реальное время в
операционных системах – это способность операционной системы обеспечить требуемый уровень
сервиса в заданный промежуток времени».
3. Иногда системами реального времени называется системы постоянной готовности (on-line
системы), или «интерактивные системы с достаточным временем реакции». Обычно это делают по
маркетинговым соображениям. Действительно, если интерактивную программу называют
работающей в «реальном времени», то это просто означает, что она успевает обработать запросы от
человека, для которого задержка в сотни миллисекунд даже незаметна.
4. Иногда понятие «система реального времени» отождествляют с понятием «быстрая
система». Это не всегда правильно. Время задержки СРВ на событие не так уж важно (оно может
достигать нескольких секунд). Главное, чтобы это время было достаточно для рассматриваемого
приложения и гарантировано. Очень часто алгоритм с гарантированным временем работы менее
эффективен, чем алгоритм, таким действием не обладающий. Например, алгоритм «быстрой»
сортировки в среднем работает значительно быстрее других алгоритмов сортировки, но его
гарантированная оценка сложности значительно хуже.
5. Во многих сферах приложения СРВ вводят свои понятия «реального времени». Например,
процесс цифровой обработки сигнала называют идущим в «реальном времени», если анализ (при
вводе) и/или генерация (при выводе) данных может быть проведен за то же время, что и анализ
и/или генерация тех же данных без цифровой обработки сигнала. Например, если при обработке
аудио данных требуется 2.01 секунд для анализа 2.00 секунд звука, то это не процесс реального
времени. Если же требуется 1.99 секунд, то это процесс реального времени.
Назовем системой реального времени аппаратно-программный комплекс, реагирующий в
предсказуемые времена на непредсказуемый поток внешних событий
Это определение означает, что:
• Система должна успеть отреагировать на событие, произошедшее на объекте, в течение
времени, критического для этого события (meet deadline). Величина критического времени для
каждого события определяется объектом и самим событием, и, естественно, может быть разной, но
время реакции системы должно быть предсказано (вычислено) при создании системы. Отсутствие
реакции в предсказанное время считается ошибкой для систем реального времени.
• Система должна успевать реагировать на одновременно происходящие события. Даже если
два или больше внешних событий происходят одновременно, система должна успеть среагировать
на каждое из них в течение интервалов времени, критического для этих событий.
Хорошим примером задачи, где требуется СРВ, является управление роботом, берущим
деталь с ленты конвейера. Деталь движется, и робот имеет лишь маленькое временное окно, когда
он может ее взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и, следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте.
Если он позиционируется раньше, то деталь еще не успеет подъехать, и робот заблокирует ей путь.
Другим примером может быть самолет, находящийся на автопилоте. Сенсорные серводатчики
должны постоянно передавать в управляющий компьютер результаты измерений. Если результат
какого-либо измерения будет пропущен, то это может привести к недопустимому несоответствию
между реальным состоянием систем самолета и информацией о нем в управляющей программе.
Различают системы реального времени двух типов - системы жесткого реального времени и
системы мягкого реального времени.
Системы жесткого реального времени не допускают никаких задержек реакции системы ни
при каких условиях, так как:
• результаты могут оказаться бесполезны в случае опоздания,
• может произойти катастрофа в случае задержки реакции,
• стоимость опоздания может оказаться бесконечно велика.
Примеры систем жесткого реального времени - бортовые системы управления, системы
аварийной защиты, регистраторы аварийных событий.
Системы мягкого реального времени характеризуются тем, что задержка реакции не
критична, хотя и может привести к увеличению стоимости результатов и снижению
производительности системы в целом.
Пример - работа сети. Если система не успела обработать очередной принятый пакет, это
приведет к таймауту на передающей стороне и повторной посылке (в зависимости от протокола,
конечно). Данные при этом не теряются, но производительность сети снижается.
Основное отличие между системами жесткого и мягкого реального времени можно выразить
так: система жесткого реального времени никогда не опоздает с реакцией на событие, система
мягкого реального времени - не должна опаздывать с реакцией на событие.
1.2.Структура СРВ.
Любая система реального масштаба времени может быть описана как состоящая из трех
основных подсистем, как изображено на рисунке 1.
Управляемая (контролируемая) подсистема (например, индустриальный завод,
управляемое компьютером транспортное средство), диктует требования в реальном масштабе
времени; подсистема контроля (контролирующая) управляет некоторыми вычислениями и
связью с оборудованием для использования от управляемой подсистемы; подсистема оператора
(операционная) контролирует полную деятельность системы. Интерфейс между управляемыми и
подсистемами контроля состоит из таких устройств как датчики и приводы. Интерфейс между
управляющей подсистемой и оператором связывает человека с машинной. 

Рисунок 1. Пример организации системы реального времени

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

реальном масштабе времени. Эти процессоры и ресурсы управляются системой программного
обеспечения, которую мы называем операционной системой реального масштаба времени
(RTOS – real time operating system).
1.3.ОСРВ и ОС общего назначения
Назовем операционной системой реального времени такую систему, которая может быть
использована для построения систем жесткого реального времени.
Это определение выражает отношение к операционным системам реального времени как к
объекту, содержащему необходимые инструменты, но также означает, что этими инструментами
еще необходимо правильно воспользоваться.
Большинство программного обеспечения ориентировано на «слабое» реальное время, а задача
СРВ – обеспечить уровень безопасного функционирования системы, даже если управляющая
программа никогда не закончит своей работы.
ОС общего назначения, особенно многопользовательские, такие как UNIX, ориентированы на
оптимальное распределение ресурсов компьютера между пользователями и задачами (системы
разделения времени), В операционных системах реального времени подобная задача отходит на
второй план - все отступает перед главной задачей - успеть среагировать на события, происходящие
на объекте.
Другое отличие - применение операционной системы реального времени всегда связано с
аппаратурой, с объектом, с событиями, происходящими на объекте. Система реального времени,
как аппаратно-программный комплекс, включает в себя датчики, регистрирующие события на
объекте, модули ввода-вывода, преобразующие показания датчиков в цифровой вид, пригодный
для обработки этих показаний на компьютере, и, наконец, компьютер с программой, реагирующей
на события, происходящие на объекте. Операционная система реального времени ориентирована на
обработку внешних событий. Именно это приводит к коренным отличиям (по сравнению с ОС
общего назначения) в структуре системы, в функциях ядра, в построении системы ввода-вывода.
Операционная система реального времени может быть похожа по пользовательскому интерфейсу
на ОС общего назначения (к этому, кстати, стремятся почти все производители операционных
системах реального времени), однако устроена она совершенно иначе - об этом речь впереди.
Кроме того, применение операционных системах реального времени всегда конкретно. Если
ОС общего назначения обычно воспринимается пользователями (не разработчиками) как уже
готовый набор приложений, то операционная система реального времени служит только
инструментом для создания конкретного аппаратно-программного комплекса реального времени. И
поэтому наиболее широкий класс пользователей операционных системах реального времени -
разработчики комплексов реального времени, люди, проектирующие системы управления и сбора
данных. Проектируя и разрабатывая конкретную систему реального времени, программист всегда
точно знает, какие события могут произойти на объекте, знает критические сроки обслуживания
каждого из этих событий.
Одно из коренных внешних отличий систем реального времени от систем общего назначения -
четкое разграничение систем разработки и систем исполнения. Система исполнения
операционных системах реального времени - набор инструментов (ядро, драйверы, исполняемые
модули), обеспечивающих функционирование приложения реального времени.
Большинство современных ведущих операционных систем реального времени поддерживают
целый спектр аппаратных архитектур, на которых работают системы исполнения (Intel, Motorola,
RISC,MIPS, PowerPC, и другие). Это объясняется тем, что набор аппаратных средств - часть
комплекса реального времени и аппаратура должна быть также адекватна решаемой задаче,
поэтому ведущие операционные системы реального времени перекрывают целый ряд наиболее
популярных архитектур, чтобы удовлетворить самым разным требованиям по части аппаратуры.
Система исполнения операционных системах реального времени и компьютер, на котором она

исполняется называют "целевой" (target) системой. Система разработки - набор средств,
обеспечивающих создание и отладку приложения реального времени.
Системы разработки (компиляторы, отладчики и всевозможные tools) работают, как
правило, в популярных и распространенных ОС, таких, как UNIX и Windows. Кроме того, многие
операционные системы реального времени имеют и так называемые резидентные средства
разработки, исполняющиеся в среде самой операционной системы реального времени.
Заметим, что функционально средства разработки операционных систем реального времени
отличаются от привычных систем разработки, таких, например, как Developers Studio, TaskBuilder,
так как часто они содержат средства удаленной отладки, средства профилирования (измерение
времен выполнения отдельных участков кода), средства эмуляции целевого процессора,
специальные средства отладки взаимодействующих задач, а иногда и средства моделирования.

1.4. Характеристики ОСРВ.

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

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

Приблизительное время реакции в зависимости от области применения ОСРВ может быть
следующее:
• математическое моделирование
- несколько микросекунд
• радиолокация
- несколько миллисекунд
• складской учет
- несколько секунд
• управление производством
- несколько минут

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

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

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

ОСРВ содержат механизмы, гарантирующие заранее вычисленное время реакции системы.
Эта гарантия достигается знанием максимального времени блокировок прерываний в системе,
времени переключения контекста, времен выполнения различных системных вызовов,
применением нужных механизмов диспетчеризации и пр. Т.е. время реакции на события для
операционных систем реального времени можно вычислить с большой точностью. Эти вычисления
невозможны для операционных систем LINUX и Windows NT - здесь можно полагаться только на
результаты тестирования, эмпирические оценки. Часто производительность компьютера
подбирается таким образом, чтобы успевать в нужные времена, но сути дела это не меняет, поэтому
риски в сложных комплексах могут оказаться велики - при небольшом изменении внешних условий
или при модификации приложений времена могут "поплыть". Что касается расширений реального
времени для LINUX и Windows NT, то здесь, по крайней мере, можно полагаться на времена,
полученные при тестировании.
Время перезагрузки системы. Этот параметр кажется второстепенным, однако были
свидетелями случаи, когда именно этот параметр целиком определял выбор дорогой операционной
системы (время перезагрузки не должно было превышать 1 секунду). Этот параметр важен для
систем, от которых требуется непрерывная работа; в этих случаях ставятся ловушки,
отслеживающие зависание системы или приложений, и, если таковое произошло, автоматически
перезагружающие систему (такие ловушки необходимы в системах повышенной надежности, т.к.
от ошибок, по крайней мере, в приложениях никто не застрахован). В таких случая важным
является такое свойство системы как ее живучесть при незапланированных перезагрузках.
Большинство операционных систем реального времени устойчивы к перезагрузкам и могут быть
прерваны и перезагружены в любое время.
Время загрузки для разных ОСРВ колеблется от секунды до нескольких десятков секунд. В
большинстве систем (OS9, VxWorks) время загрузки можно регулировать, изменяя стартовые
последовательности. В ОС LINUX время загрузки в стандартном варианте более минуты, система
неустойчива к внезапным остановам - требуется стандартная процедура завершения работы с
системой (shutdown). Однако LINUX достаточно гибок и можно создать конфигурации системы, в
которых время загрузки будет уменьшено до десятка секунд и система будет устойчива к сбоям
(использование специальной опции файловой системы). В Windows NT время загрузки более
минуты, система неустойчива к внезапным сбоям. Использование расширений реального времени
(RTX) позволяет детектировать зависания системы и выполнить в этих случаях необходимые
операции по спасению данных и по выполнению каких-то страховочных действий.
Посмотрим, какие ОС могут использоваться в системах реального времени в зависимости от
времени реакции системы.

Табл1. Требования к реактивности системы и возможные используемые ОС

Время реакции Используемые ОС
Менее 10мкс только ОСРВ Но даже они могут оказаться бессильны - это граница выбора между схемным и программным решением
10-100мкс ОСРВ
100мкс - 1МС ОСРВ, RTAI, RT Linux, расширения реального времени для WindowsNT, Windows CE
1мс можно попытаться что-то сделать с Linux и Windows NT, но не для систем, где опоздания реакции могут привести к тяжёлым последствиям

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

Аппаратное устройство несколько отличается. Для обеспечения минимального времени
простоя в случае технической неполадки процессор, память и т.д. размещаются на съемной плате, вставляемой в специальный разъем так называемой «пассивной» основной платы. В другие разъемы этой платы вставляются платы периферийных устройств. Среди процессоров таких компьютеров преобладают процессоры Intel.
Промышленные компьютеры. Состоят из одной платы, на которой размещены процессор,
контроллер памяти, память. Память может быть нескольких видов – ПЗУ ( в которой
размещается сама ОСРВ), ОЗУ (там размещаются код и данные), Флеш-память (может играть
роль диска). На плате также находятся контроллеры периферийных устройств, несколько
программируемых таймеров. Среди процессоров этих компьютеров доминируют процессоры
семейства PowerPC, Motorola 68xxx, SPARC, ARM, Intel 80x86, 80960x.
Встраиваемые системы. Устанавливаются внутрь оборудования, которым они управляют.
Для крупного оборудования могут по исполнению совпадать с промышленными
компьютерами. Для оборудования поменьше могут представлять собой процессор с
сопутствующими элементами, размещенными на одной плате с другими электронными
компонентами оборудования. Для миниатюрных систем процессор с сопутствующими
элементами может быть частью одной из интегральных схем оборудования.
В связи с особенностями оборудования ОСРВ (промышленные компьютеры и встраиваемые
системы часто являются бездисковыми.) должны обладать следующими свойствами:
Размеры системы. Для систем реального времени важным параметром является размер
системы исполнения, а именно суммарный размер минимально необходимого для работы
приложения системного набора (ядро, системные модули, драйверы и т. д.). Хотя, надо признать,
что с течением времени значение этого параметра уменьшается, тем не менее он остается важным и
производители систем реального времени стремятся к тому, чтобы размеры ядра и обслуживающих
модулей системы были невелики.
Примеры: размер ядра операционной системы реального времени OS-9 на микропроцессорах
Motorola 68xxx - 22 KB, VxWorks - 16 KB.
Возможность исполнения системы из ПЗУ (ROM). Система должна иметь возможность
осуществлять загрузку из ПЗУ. Для экономии места в ПЗУ часть системы может храниться в
сжатом виде и загружаться в ОЗУ по мере необходимости. Часто система позволяет исполнять код
как в ПЗУ, так и в ОЗУ. При наличии свободного места в ОЗУ система может копировать себя из
медленного ПЗУ в более быстрое ОЗУ.
К дополнительным свойствам ОСРВ можно отнести следующие:
Наличие необходимых драйверов устройств. Если разрабатываемая система имеет
обширную периферию, то наличие уже готовых драйверов может оказать большое влияние на
выбор операционной системы. Естественно, самый большой набор драйверов создан для
операционных системах LINUX и Windows NT. Наиболее популярные операционные системы
реального времени, такие как VxWorks, OS9, QNX, также имеют обширные наборы готовых
драйверов и, кроме того, содержат средства для их быстрой разработки.
Поддержка процессоров различной архитектуры. В связи с тем, что в промышленных
компьютерах, серверах, встраиваемых системах широко распространены процессоры разной
архитектуры с различной системой команд, ОСРВ по возможности должна поддерживать как можно более широкий ряд процессоров.
Одной из важных характеристик ОСРВ является наличие специального кроссплатформенного инструментария разработчика. Это связано с тем, что разработка СРВ
часто проводится на «обычном» компьютере, отличном по архитектуре от компьютера, на котором
будет устанавливаться СРВ. При этом ОС на этих двух компьютерах также может не совпадать.

 

1.5.Механизмы реального времени

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

Процесс проектирования конкретной системы реального времени начинается с тщательного
изучения объекта. Разработчики проекта исследуют объект, изучают возможные события на нем,
определяют критические сроки реакции системы на каждое событие и разрабатывают алгоритмы
обработки этих событий. Затем следует процесс проектирования и разработки программных
приложений. Какие же механизмы в операционных системах реального времени делают систему
реального времени (СРВ) предсказуемой?
Система приоритетов и алгоритмы диспетчеризации. Базовыми инструментами разработки
сценария работы системы являются система приоритетов процессов (задач) и алгоритмы
планирования (диспетчеризации) операционных системах реального времени.
В многозадачных ОС общего назначения используются, как правило, различные модификации
алгоритма круговой диспетчеризации, основанные на понятии непрерывного кванта времени ("time
slice"), предоставляемого процессу для работы. Планировщик по истечении каждого кванта
времени просматривает очередь активных процессов и принимает решение, кому передать
управление, основываясь на приоритетах процессов (численных значениях, им присвоенных).
Приоритеты могут быть фиксированными или меняться со временем - это зависит от алгоритмов
планирования в данной ОС, но рано или поздно процессорное время получат все процессы в
системе.
Алгоритмы круговой диспетчеризации неприменимы в чистом виде в операционных системах
реального времени. Основной недостаток - непрерывный квант времени, в течение которого
процессором владеет только один процесс. Планировщики же операционных систем реального
времени имеют возможность сменить процесс до истечения "time slice", если в этом возникла
необходимость. Один из возможных алгоритмов планирования при этом "приоритетный с
вытеснением". Мир операционных систем реального времени отличается богатством различных
алгоритмов планирования: динамические, приоритетные, монотонные, адаптивные и пр., цель же
всегда преследуется одна - предоставить инструмент, позволяющий в нужный момент времени
исполнять именно тот процесс, который необходим.
Механизмы межзадачного взаимодействия. Другой набор механизмов реального времени
относится к средствам синхронизации процессов и передачи данных между ними. Для
операционных систем реального времени характерна развитость этих механизмов. К таким
механизмам относятся: семафоры, мьютексы, события, сигналы, средства для работы с разделяемой
памятью, каналы данных (pipes), очереди сообщений. Многие из подобных механизмов
используются и в ОС общего назначения, но их реализация в операционных системах реального
времени имеет свои особенности - время исполнения системных вызовов почти не зависит от
состояния системы, и в каждой операционной системе реального времени есть по крайней мере
один быстрый механизм передачи данных от процесса к процессу.
Средства для работы с таймерами. Такие инструменты, как средства работы с таймерами,
необходимы для систем с жестким временным регламентом, поэтому развитость средств работы с
таймерами - необходимый атрибут операционных систем реального времени. Эти средства, как
правило, позволяют:
измерять и задавать различные промежутки времени (от 1 мкс и выше),
генерировать прерывания по истечении временных интервалов,
создавать разовые и циклические будильники
Здесь описаны только базовые, обязательные механизмы, использующиеся в ОСРВ.

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

 

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

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

 

2. Архитектура ОСРВ. Классы ОСРВ.

2.1.Архитектура ОСРВ

Все ОСРВ сегодня являются многозадачными системами. Задачи делят между собой ресурсы
вычислительной системы, в том числе и процессорное время.
Четкой границы между ядром (KERNEL) и операционной системой нет. Различают их, как
правило, по набору функциональных возможностей. Ядра предоставляют пользователю такие
базовые функции, как планирование синхронизация задач, межзадачная коммуникация, управление
памятью, устройствами ввода-вывода и т. п. Операционные системы в дополнение к этому имеют
файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого
уровня. Они обеспечивают также взаимодействие системы и управляющего/управляемого
оборудования.
По своей внутренней архитектуре ОСРВ можно условно разделить на монолитные ОС, ОС на
основе микроядра и объектно-ориентированные ОС. Графически различия в этих подходах
иллюстрируются рисунками 1,2,3.

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

2. Ядро не может быть прервано пользовательской задачей (non-preemptable). Это может
приводить к тому, что высокоприоритетная задача может не получить управление из-за работы
низкоприоритетной. Например, низкоприоритетная задача запросила выделение памяти, сделала
системный вызов, до окончания которого сигнал активизации высокоприоритетной задачи не
сможет ее активизировать.
3. Сложность переноса на новый архитектуры процессора из-за значительных ассемблерных
вставок.
4. Негибкость и сложность развития: изменение части ядра системы требует его полной
перекомпиляции.

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

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

 

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

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

Поскольку все приложения и сами микроядра работают в одном адресном пространстве, то
они загружаются в память, начиная с неизвестного на момент компиляции адреса. Следовательно,
приложения и микроядра не должны зависеть от начального адреса (как по коду, так и поданным
(последнее обеспечить значительно сложнее)). Это свойство автоматически обеспечивает
возможность записи приложений и модулей в ПЗУ, с их последующим исполнением как в самом
ПЗУ, так и оперативной памяти.
Микроядра по своим характеристикам напоминают структуры, используемые в других
операционных системах. Однако есть и свои различия.
Микроядра и модули. Многие ОС поддерживают динамическую загрузку компонент
системы, называемых модулями. Однако, модули не поддерживают объектно-ориентрованный
подход (напомним, микроядро фактически является представителем некоторого класса). Далее,
обмен информацией с модулями происходит посредством системных вызовов, что достаточно
дорого.
Микроядра и драйверы. Многие ОС поддерживают возможность своего расширения
посредством драйверов (специальных модулей, обычно служащих для поддержки оборудования).
Однако, драйверы часто должны быть статически связаны с ядром (т.е. образовывать с ним
связанный загрузочный образ еще до загрузки) и должны работать в привилегированном
(суперпользовательском) режиме. Далее, как модули они не поддерживают объектно-
ориентированный подход и доступны приложению только посредством системных вызовов.
Микроядра и DLL. Многие системы оформляют библиотеки, из которых берутся
функции при динамическом связывании, в виде специальных модулей, называемых DLL
(Dynamically Linked Libraries – динамически связываемые библиотеки). DLL обеспечивает
разделение своего кода и данных для всех работающих приложений, в то время как для микроядер
можно управлять доступом для каждого конкретного приложения. DLL не поддерживает объектно-
ориентированный подход, код DLL не является позиционно-независимым и не может быть записан в ПЗУ.

2.2.Классы ОСРВ 

1-й класс: исполнительные СРВ.

Это программы для программируемых микропроцессоров, встраиваемых в различные
устройства, очень небольшие и обычно написаны на языке низкого уровня типа ассемблера или
PLM. Внутрисхемные эмуляторы пригодны для отладки, но высокоуровневые средства разработки
и отладки программ не применимы. Операционная среда обычно недоступна.
Признаки систем этого типа - различные платформы для систем разработки и исполнения.
Приложение реального времени разрабатывается на host- компьютере (компьютере системы
разработки), затем компонуется с ядром и загружается в целевую систему для исполнения. Как
правило, приложение реального времени - это одна задача и параллелизм здесь достигается с
помощью нитей (threads).
Системы этого типа обладают рядом достоинств, среди которых главное - скорость и
реактивность системы. Главная причина высокой реактивности систем этого типа - наличие только
нитей(потоков) и, следовательно, маленькое время переключения контекста между ними ( в
отличие от процессов).
С этим главным достоинством связан и ряд недостатков: зависание всей системы при
зависании нити, проблемы с динамической подгрузкой новых приложений
Наиболее ярким представителем систем этого класса является операционная система
VxWorks. Область применения - компактные системы реального времени с хорошими временами
реакций.

2-й класс: минимальное ядро системы реального времени.

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

3-й класс: ядро системы реального времени и инструментальная среда.

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

4-й класс: ОС с полным сервисом.

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

 

2.3.Расширения реального времени для WindowsNT

Появление в свое время UNIX'ов реального времени означало ни что иное, как попытку
применить господствующую программную технологию для создания приложений реального
времени. Появление расширений реального времени для Windows NT имеет те же корни, ту же
мотивацию. Огромный набор прикладных программ под Windows, мощный программный
интерфейс WIN32, большое количество специалистов, знающих эту систему. Конечно,
соблазнительно получить в системе реального времени все эти возможности.
Несмотря на то, что Windows NT создавалась как сетевая операционная система, в нее при
создании были заложены элементы реального времени, а именно - двухуровневая система
обработки прерываний (ISR и DPC), классы реального времени (процессы с приоритетами 16-32
планируются в соответствии с правилами реального времени).
Конечно, даже поверхностный анализ Windows NT показывает, что эта система не годится для
построения систем жесткого реального времени (система непредсказуема - время выполнения
системных вызовов и время реакции на прерывания сильно зависит от загрузки системы; система
велика; нет механизмов защиты от зависаний и пр. и пр.). Поэтому даже в системах мягкого
реального времени Windows NT может быть использована только при выполнении целого ряда
рекомендаций и ограничений.
Разработчики расширений пошли двумя путями:
Использовали ядра классических операционных систем реального времени в качестве
дополнения к ядру Windows NT ("два в одном флаконе"). Таковы решения фирм "LP Eleknroniks" и "Radisys". В первом случае параллельно с Windows NT (на одном компьютере!) работает
операционная система VxWorks, во-втором случае - InTime. Кроме того, предоставляется набор
функций для связи приложений реального времени и приложений Windows NT. Вот как, например
это выглядит у LP Elektroniks: вначале стандартным образом загружается Windows NT, затем с
помощью специального загрузчика загружается операционная система VxWorks, распределяя под
себя необходимую память Windows (что в дальнейшем позволяет избежать конфликтов памяти
между двумя ОС). После этого полной "хозяйкой" на компьютере уже становится VxWorks, отдавая
процессор ядру Windows NT только в случаях, когда в нем нет надобности для приложений
VxWorks. В качестве канала для синхронизации и обмена данными между Windows NT и VxWorks
служат псевдодрайверы TCP/IP в обоих системах. Технология использования двух систем на одном
компьютере понятна - работу с объектом выполняет приложение реального времени, передавая
затем результаты приложениям Windows NT для обработки, передачи в сеть, архивирования и пр.
Вариант расширений реального времени фирмы VenturCom выглядит иначе: здесь
сделана попытка "интегрировать" реальное время в Windows NT путем исследования причин
задержек и зависаний и устранения этих причин с помощью подсистемы реального времени.
Решения фирмы "VenturCom" (RTX 4.2) базируются на модификациях уровня аппаратных
абстракций Windows NT (HAL - Hardware Abstraction Layer) - программного слоя, через который
драйверы взаимодействуют с аппаратурой. Модифицированный HAL и дополнительные функции
(RTAPI) отвечают также за стабильность и надежность системы, обеспечивая отслеживание краха
Windows NT, зависания приложений или блокировку прерываний. В состав RTX входит также
подсистема реального времени RTSS, с помощью которой Windows NT расширяется
дополнительным набором объектов (аналогичным стандартным, но с атрибутами реального
времени). Среди новых объектов - нити (потоки, процессы) реального времени, которые
управляются специальным планировщиком реального времени (256 фиксированных приоритетов,
алгоритм - приоритетный с вытеснением). Побочным результатом RTX является возможность
простого создания программ управления устройствами, т.к. среди функций RTAPI есть и функции
работы с портами ввода-вывода и физической памятью. Предложения VenturCom характерны еще и
тем, что они предоставляют совершенно экзотическую для NT возможность, а именно -
возможность конфигурирования Windows NT и создания встроенных конфигураций (без дисков,
клавиатуры и монитора) (Интегратор Компонентов - CI).

Источник: "Системы реального времени", учебное пособие по дисциплине "Информатика и вычислительная техника" для студентов направления 230100.68, Владикавказ 2013

http://www.kafedra-aoi.ru/folder/950SRV_LK.pdf

Категории: 

Метки: