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

Санкт-Петербургский  государственный

электротехнический университет

 

 

 

 

 

 

Кафедра Автоматизированных систем

обработки информации и  управления

 

 

 

 

 

 

 

 

 

 

Реферат на тему

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Санкт-Петербург 

2012 год

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

 

1 Понятие  ОСРВ и её характеристики;

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

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

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

• Поддержка и организация выполнения всех задач;
• Управление прерываниями;
• Реализация взаимодействия процессов в системе;
• Запуск задач в назначенные моменты времени.

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

Таблица 1

Основные  отличия операционных систем реального  времени от универсальных ОС

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

 

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

ОСРВ – это  операционные системы, для которых  характерно:

1. Высокий уровень готовности:  
   Обеспечение высокого уровня готовности необходимо для обеспечения функционирования самой СРВ. В архитектуре и при реализации ОС надо учесть следующие факторы:  
   Отсутствие виртуальной памяти: 
   Виртуальная память (файл подкачки) должна быть выключена или отсутствовать. Любое обращение к дискам непредсказуемо увеличивает время реакции системы. 
    
   Отсутствие сети (непосредственное использование протоколов):  
   Сетевое окружение не должно содержать служб имен, периодических опросов узлов и других источников периодических событий. Единственным допустимым трафиком должны быть передаваемые данные. Любое непредусмотренное сообщение по сети от служб сервиса или повтор при коллизии ведет к задержкам в системе. 
    
   Система должна предоставлять пользователю расширенные возможности по работе с прерываниями 
   Система должна позволять пользователю выполнять все требуемые операции внутри обработчика прерывания; устанавливать приоритет прерываний; аппаратно блокировать неиспользуемые прерывания. Правильное программирование приоритетов прерываний позволяет свести к минимуму возможные потери информации или исключить их полностью. 
    
   Система регистрации должна писать на виртуальный диск  
   Регистрация данных - один из основных процессов в технологических системах. Для исключения задержек при записи необходимо писать в память или ставить дисковые контроллеры со специальным кэшем, позволяющем "демпфировать" неравномерную скорость потока и задержки при сбросе информации на диски.
2. Гарантированное время отклика
3. Ограниченность ресурсов памяти.  
   Данная характеристика определяется аппаратными особенностями ПК, на котором функционируют СРВ. Они подробно рассмотрены в п.2 данного пособия. ОС часто работает на бездисковом компьютере и осуществляет начальную загрузку из ПЗУ, часть системы хранится в сжатом виде и подгружается по мере необходимости; Может исполнять код, как в ОЗУ, так и в ПЗУ и копировать себя из медленного ПЗУ в быстрое ОЗУ при наличии свободного места.
4. Невысокая производительность:  
   Обеспечение высокой производительности не ставится во главу. СРВ – это небыстрая система, гораздо важнее гарантировать время выполнения.
5. Наличие средств автомониторинга.  
   СРВ обеспечивают бесперебойную работу жизненно важных систем, поэтому, если возникает сбой или выполняются какие-то нелегальные операции, ОС должна их диагностировать, при необходимости блокировать программу или изолировать друг от друга приложения, инициировать восстановление и защиту других программ либо самой системы.
6. Поддержка различного специального оборудования.  
   В соответствии с определением, СРВ управляет различным оборудованием. Связь системы с объектом обеспечивают периферийные контроллеры, таймеры.
7. Существование системы исполнения и системы разработки.  
   Системы разработки - набор средств, обеспечивающих создание и отладку приложений реального времени;  
   Системы исполнения - набор средств, обеспечивающих функционирование приложения реального времени. Размер системы исполнения обычно невелик.

 

 

Технические параметры ОСРВ

Перечислим  основные технические параметры, которые  должна обеспечивать ОС реального времени:

• Время реакции системы на прерывание (interrupt latency – латентная задержка прерывания) - интервал времени от события на объекте до выполнения первой инструкции в программе обработки этого события.
• Время реакции задачи (task response) - интервал времени от момента возникновения физического прерывания до начала выполнения первой инструкции задачи пользователя, которой предназначено прерывание.
• Время переключения контекста (context switch) - интервал времени от момента окончания выполнения последней инструкции одного процесса (потока) до момента начала выполнения первой инструкции следующего процесса (потока). Этот интервал определяет, как часто каждый из активных процессов может получать управление при заданных параметрах квантования времени.
• Задержка диспетчеризации (scheduling latency) - интервал времени от момента окончания выполнения последней инструкции пользовательского обработчика прерываний до момента выполнения первой инструкции процесса, перешедшего в состояние из-за этого прерывания;
• Максимальное время исполнения каждого системного вызова. Оно должно быть предсказуемым и не зависеть от количества объектов в системе;
• Максимальное время, на которое модули ОС и драйверы могут блокировать прерывания;
• Неустойчивость таймера (timer jitter) - разница во времени срабатывания таймера с фиксированной длительностью.
• Размеры ОС.

 
 
Til – Время задержки прерывания  
Tint – Время обработки прерывания  
Tiret – Время возврата из прерывания 
Tsl – Задержка диспетчеризации  
 
Все приведенные характеристики должны быть известны заранее и предоставлены разработчику СРВ. Без них нельзя обеспечить выполнение критических сроков обслуживания (deadline) . Требования также зависят от специфики управляемого процесса. Например, контроллер робота может требовать от встроенного компьютера ответ в течение менее 1 мс, в то время как при моделировании полета, может быть, приемлем ответ в 40 мс. При разработке текстового редактора время реакции на нажатие клавиши не должно превышать 0.1-0.2 сек.

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

Tsl > Til > Tiret

Время переключения контекста обычно на 20% больше чем Тsl . Характеристики различных ОС приведены в таблице 2.

Таблица 2

Сравнительные результаты технических параметров ОС реального времени

Технические параметры  Linux OS OS-9 QNX VXWorks Windows RTX Переключение  между заданиями, мс - 3 2.5 10 14 Задержка  прерываний, мс <20 3 2.5 10 - Аппаратная  платформа x86,   Power PC,   microSPARC x86,   Power PC, 32-bit x86,   Power PC,   MIPS x86,   SPARC,   Power PC,   MIPS x86,   Alpha Требуемое количество памяти, Kб 4 000   (run-time) 24 (ROM)   64 (RAM) 640/4000+  (GUI) 10+ 12000/16000

 

 

 

 

 

 

 

 

 

 

 

2 Основные  требования, 
предъявляемые к ОС реального времени

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

1. ОСРВ должна быть многозадачной (или многопоточной).  
   Программное обеспечение СРВ представляет собой фиксированный набор заранее разработанных модулей, а выбор программы на выполнение осуществляется по прерываниям (исходя из текущего состояния объекта) или в соответствии с расписанием плановых работ. Подробнее о планировании ОСРВ в главе 4 данного пособия.
2. Реализовано понятие приоритета задачи (потока).  
   Процессы (нити) должны иметь приоритеты, к которым разработчики СРВ сводят требования по временным ограничениям. Как определить задачу (нить), которая нуждается в ресурсах больше всего? В идеальном случае, ОСРВ предоставляет ресурсы задаче, у которой осталось меньше всего времени до истечения срока реакции на событие. Однако для реализации этого механизма нужно уметь прогнозировать, сколько времени понадобится данной задаче для завершения своей работы и сколько времени понадобится другим для того, чтобы они успели к своим критическим срокам. Подобный прогноз очень сложен в реализации, да и времени на его составление нет. Поэтому разработчики ОС используют концепцию приоритетов.
3. Должен существовать механизм наследования приоритетов.  
   В многозадачной СРВ необходимость разделения ресурсов, комбинация приоритетов потоков могут привести к таким проблемам, как инверсия приоритетов (priority inversion) и смертельный захват (deadlock) . 
   Инверсия приоритетов – это ситуация, в которой, управление получает не та ветвь исполнения, которая должна была бы получить из соображений приоритетности, а другая, с более низким приоритетом, в результате нарушается детерминированность и прогнозируемость системы.  
   Для примера рассмотрим систему с 3 потоками управления: Т1, Т2, Т3 , причём их приоритеты: T1 < T2 < T3 . Пусть потоки активируются по некоторым событиям в следующей временной последовательности: T1, T2, T3 . Если T1 захватывает некоторый монопольный ресурс, который требуется так же и T3 , и не успевает освободить его до активации Т2 , то происходит следующее:
4. - T1 не выполняется, потому, что он вытеснен T2 (в виду приоритетности);
5. - T3 не выполняется, потому, что ожидает ресурс, захваченный T1 ;

  - T2 выполняется ... вплоть до бесконечно долго.

 
Но T2 в данном примере не является потоком, подлежащим немедленному исполнению. Самый высокоприоритетный - T3 , его назначение – своевременная реакция на событие, оно не только не обработается в гарантированное время, но и вообще гарантировано не обработается.  
Чтобы устранить такие инверсии, ОСРВ должна допускать наследование приоритета: нужно динамически повысить приоритет блокирующего потока ( Т1 в рассмотренном примере) до значения максимального приоритета всех тех потоков, которые ожидают освобождения заблокированного ресурса ( Т3 в рассмотренном примере). После освобождения ресурса тут же вернуть приоритет к его исходному статическому уровню. При этом «задерживающий всех» поток быстро пройдет критическую секцию на максимальном приоритете тех, кого он «задерживает». Наследование означает, что блокирующий ресурс поток наследует приоритет потока, который он блокирует.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Типы  ОСРВ 

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

Не  существует операционных систем жесткого или мягкого реального времени! Классификация на жесткое и мягкое время верна для самих систем реального времени. А операционная система реального времени - только инструмент, помогающий построить конкретную систему реального времени. Поэтому бессмысленно говорить об ОС жесткого или мягкого реального времени. Можно говорить только о том, можно ли с помощью данной операционной системы построить систему реального времени. Конкретная ОСРВ может только предоставить возможность создать систему жесткого реального времени. Но обладание такой ОСРВ вовсе не делает вашу систему "жесткой". Для создания системы жесткого реального времени необходимо сочетание подходящих аппаратных средств, адекватной операционной системы и правильного проектирования прикладного программного обеспечения. Если, например, вы решили построить СРВ, обслуживающую TCP/IP-соединение через Ethernet, она никогда не будет системой жесткого реального времени, поскольку сам Ethernet непредсказуем. С другой стороны, с помощью ОС "Windows 3.11", невозможно создать приложение жесткого реального времени, так как непредсказуемо поведение этой ОС.

Рассмотрим  основные типы ОСРВ.

1. Типы ОСРВ по способу разработки программного обеспечения:

•Self-Hosted ОСРВ –  
Системы, в которых пользователи могут разрабатывать приложения, работая в данной ОС. Это предполагает, что ОС данного типа поддерживают: файловую систему, средства ввода/вывода, пользовательский интерфейс, имеются компиляторы, отладчик, средства анализа программ и текстовые редакторы. 
Достоинством данных систем является простой и наглядный механизм создания и запуска приложений, которые функционируют на той же машине, что и пользователь. Недостатком является то, большинство перечисленных возможностей ОС не используются во время работы промышленного компьютера и, следовательно, зря занимают ресурсы компьютера.  
Используются на “обычных” компьютерах промышленного исполнения (Глава 2 данного пособия).

• Host-target ОСРВ –  
Системы, в которых ОС и (или) компьютер, на котором разрабатываются приложения (Host) и ОС и (или) компьютер, на котором запускаются приложения (Target) различны. В качестве host-системы обычно выступает компьютер под управлением ОС “широкого назначения” UNIX, Windows, в качестве target-системы - промышленный или встраиваемый компьютер под управлением ОСРВ.  
Достоинством таких систем является использование всех ресурсов "обычной" ОС (таких, как графический интерфейс, файловая система, быстрый процессор и большой объем оперативной памяти) для создания приложений и уменьшение размеров ОСРВ за счет включения только нужных приложению компонент. Недостатком является относительная сложность программных компонент: кросс-компилятора, удаленного загрузчика и отладчика, и т.д.  
С одной стороны, рост мощности промышленных компьютеров позволяет использовать self-hosted системы на большем числе вычислительных систем. С другой стороны, увеличивающееся распространение встраиваемых систем расширяет сферу применения host-target систем (поскольку при больших объемах выпуска цена системы является определяющим фактором).

2. Типы ОСРВ по происхождению:

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

•Собственно ОСРВ –  
Специализированные ОС для применения в задачах реального времени. Системы по способу разработки ПО - Self-Hosted, Host-Target (большинство).

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

Преимущества (+) Специализированных ОСРВ:  
– Наивысшая производительность, 
– Наилучший учет особенностей оборудования, 
– Наибольшая компактность. 
 
Недостатки (-) Специализированных ОСРВ:  
– Большое время разработки, 
– Высокая стоимость, 
– Непереносимость.

3. Типы ОСРВ по внутреннему строению:

•“Классические” –  
ОСРВ, основанные на процедурном подходе к программированию. Примеры: QNX, OS-9, pSOS, VRTX, VxWorks, CHORUS.

•Объектно-ориентированные –  
ОСРВ, основанные на объектно-ориентированном подходе к разработке программного обеспечения. Пример: SoftKernel.

 

 

 

 

3.4 Примеры  ОСРВ 

ОСРВ QNX

Обзор начнем с  одной из самых распространенных ОСРВ – ОС QNX.  
QNX выпускается фирмой QNX SoftWare Systems (USA), предназначена для высокоответственных приложений, бесперебойно функционирующих годами. Надежность QNX обеспечивается ее архитектурой на основе микроядра. На рис. 2 приведена архитектура QNX.

 

<>	- МИКРОЯДРО (MicroKernel)   - МЕНЕДЖЕР ПРОЦЕССОВ (Proc)   - МЕНЕДЖЕР ФАЙЛОВЫХ СИСТЕМ (Fsys);  - МЕНЕДЖЕР УСТРОЙСТВ (Dev)  - МЕНЕДЖЕР СЕТИ (Net)

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

• МИКРОЯДРО  
Размер микроядра в QNX составляет всего около 10 Kb и оно отвечает только за диспетчеризацию процессов, передачу сообщений, переадресацию прерываний и поддержку сетевого интерфейса.  
Поддерживается диспетчеризация до 300 процессов с 32 уровнями приоритетов и 4 алгоритма планирования: FIFO, Round-Robin (карусель), Adaptive и Message-Priority.  
QNX была первой коммерчески успешной операционной системой, в основе которой лежал обмен сообщениями как единственный способ информационного обмена между взаимодействующими процессами. Сообщения в QNX представляют собой пакет байт, посланный от одного процесса к другому; большое значение придается содержанию сообщения, оно имеет смысл только для процесса-источника и процесса получателя, и ни для какого бы то ни было другого процесса.  
Обмен сообщениями обеспечивает не только передачу информации, но является способом синхронизации параллельной работы нескольких процессов. При передаче, приеме и ответе на сообщение процессы подвергаются разнообразным изменениям состояния, которые влияют на то, когда и как долго данный процесс может работать. Имея информацию о приоритетах и состояниях процессов, микроядро может управлять работой процессов как можно эффективней с точки зрения распределения ресурсов системы. Этот единственный согласующий метод - обмен сообщениями - действует внутри всей системы.  
При обычных условиях ядро недоступно - оно защищено несколькими слоями защиты. Оно становится доступно только по прямому вызову из какого-либо системного процесса или аппаратного прерывания.

• МЕНЕДЖЕР ПРОЦЕССОВ  
Отвечает за создание и удаление процессов, управление памятью, таймеры и эмуляцию сопроцессора, а также диагностику. Сертифицирован по стандарту POSIX 1003.1 и поддерживает многие расширения POSIX 1003.4. Начиная с версии 4.25, использует все возможности процессоров Intel для аппаратной защиты памяти, в том числе механизм страниц. Но свопинг на диск не поддерживается, так как это трудно совместимо с требованиями к ОС реального времени.  
Системные процессы в QNX недоступны для прямого вызова из пользовательских процессов или прикладных программ. А в остальном, они ничем не отличаются от процессов пользователя: не имеют ни скрытых, ни так называемых "частных" интерфейсов. Это предоставляет широкие возможности параллельного расширения работы системы. К примеру, для создания нового процесса в QNX пользователю необходимо всего лишь написать соответствующую программу и запустить ее. При различных вариантах запуска исполняемой программы, она может быть представлена как системный процесс или как внешний процесс пользователя.

• МЕНЕДЖЕР УСТРОЙСТВ  
Драйверы устройств в QNX - это один из видов системных процессов, которые обеспечивают устойчивую работу специфического оборудования.  
Первый запуск драйвера ничем не отличается от запуска любой другой исполняемой программы. Но после этого драйвер присоединяется к системе, т.е. ассоциируется с наиболее близким системным процессом в виде его расширения или дополнения и больше не требует никакой настройки. Однажды подключившись к системе, драйвер может принимать следующий вид: 
- Исчезнуть, как процесс, но сохранить все расширения, которые им были проведены на системном процессе, с которым он был ассоциирован; 
- Сохранить свою индивидуальность как процесса.  
При добавлении нового драйвера в системе не может произойти никаких побочных эффектов в виде, например, конфликта с другими устройствами.

• МЕНЕДЖЕР ФАЙЛОВЫХ СИСТЕМ  
QNX позволяет работать с несколькими файловыми системами одновременно. В стандартный комплект поставки входят менеджеры файловых систем POSIX, DOS (FAT-12, FAT-16, все виды разделов) и ISO9660 (CD-ROM включая расширения Rock Ridge). Файловая система POSIX семантически соответствует UNIX, при этом обеспечивается более высокая надежность (в том числе при отказе питания) и параллелизм в соответствии с POSIX 1003.1.

•МЕНЕДЖЕР СЕТИ  
Сетевое взаимодействие является узким местом в большинстве ОС и обычно создает значительные проблемы для СРВ. Для того чтобы обойти это препятствие разработчики QNX создали собственную специальную сетевую технологию FLEET и соответствующий протокол FTL (FLEET Transport Layer). Этот протокол не базируется ни на одном из распространенных сетевых протоколов типа IPX или NetBios и обладает рядом качеств, которые делают его уникальным.  
 
Системы на базе QNX внедрены во многих сотнях фирм, среди которых такие известные и крупные, как Du Pont, Ferranti-Packard, General Motors, Kodak и другие.  
Основная область применения QNX - это автоматизация в промышленности в таких отраслях как добыча и транспортировка газа и нефти, управление технологическими процессами в металлургии, машиностроении, химической промышленности, водоснабжение, энергетика (включая атомные электростанции), управление роботами. Так, фирма Texaco использует QNX для удаленного управления оборудованием по добыче нефти и газа на платформах в Мексиканском заливе. Фирмы General Electric и General Dynamics используют QNX для управления и мониторинга станов холодной прокатки стали. Фирма Maritime Nuclear, обеспечивающая часть атомной энергетики Канады, использует QNX для управления тепловыми и атомными электростанциями. QNX успешно используется в системах управления роботами (фирмы Ford, IBM, Nortern Telecom), в торговых автоматах, торговых точках, интеллектуальных кассовых аппаратах (системы POS - Point-of-Sale), объединяемых в сети. QNX широко применяется в банковском деле. Фирма VISA использует систему на базе QNX для работы с кредитными карточками. Часто QNX применяется в области коммуникаций: фирма Panasonic разработала систему речевой электронной почты на базе QNX.

ОСРВ VxWorks

ОС VxWorks компании Wind River является встраиваемой ОС реального  времени. Значительная часть используемого  в Интернет сетевого оборудования, коммутаторы, маршрутизаторы, серверы  удаленного доступа и устройства широкополосного доступа работают под управлением VxWorks.  
ОСРВ VxWorks построена по технологии микроядра, т.е. на нижнем непрерываемом уровне ядра выполняются только базовые функции планирования задач и управления коммуникацией/синхронизацией между задачами. Все остальные функции ОС более высокого уровня - управление памятью, вводом/выводом, сетевые средства, и т.д. - базируются на простых функциях нижнего уровня, Такая иерархическая организация позволяет обеспечить быстродействие и детерминированность ядра, а также легко строить необходимую конфигурацию ОС.

 
 
Рис. 3 Архитектура ОСРВ VxWorks 5.4

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

VxWorks операционная  система с кросс-средствами разработки  прикладного ПО: разработка ведется  на инструментальной машине (host) в инструментальной среде Tornado с последующей загрузкой, исполнением и отладкой на целевой машине (target), работающей под управлением VxWorks. 
Новая версия ОС VxWorks VxWorks AE (Advanced Edition) первая коммерческая ОС реального времени, предназначенная для построения высоконадежных отказоустойчивых систем. В отличие от обычной VxWorks, VxWorks AE построена по технологии "Protection Domain", позволяющей изолировать ядро ОС от приложений и приложения друг от друга. ОС VxWorks AE включает в себя средства обнаружения и изоляции отказов и восстановления после отказов и поддерживает технологии построения систем высокой готовности с коэффициентом готовности "пять девяток" 99,999%. ОС VxWorks AE портирована на ведущие CompactPCI-платформы высокой готовности, такие как CPX8000 компании Motorola Computer Group.

ОСРВ OS-9

OS-9 корпорации Microware System (США) относится к классу UNIX подобных систем и является  гибко конфигурируемой высокопроизводительной  системой реального времени.  
Основным принципом построения OS-9 является максимальная открытость структур и функций. Открытость системы достигается за счет последовательного модульного построения. Модульная архитектура позволяет масштабировать ее для применения, как в небольших встраиваемых системах, так и для решения больших сетевых задач.  
Принципиальным требованием является реентерабельность и перемещаемость программного кода. Реентерабельность достигается за счет сосредоточения постоянных частей кода в модулях памяти. Перемещаемость подразумевает создание компиляторами кода, не содержащего абсолютных адресов. Любая программа может быть загружена и исполнена с любого абсолютного адреса, и эта возможность делает тривиальной задачу размещения ОС (вместе с приложениями) в ПЗУ. 
В результате любые системные (за исключением самого ядра и модуля данных) и прикладные модули могут добавляться или удаляться из системы в процессе ее функционирования без какой-либо повторной компиляции или компоновки.  
Система OS-9 явилась одной из первых систем, в которой последовательно реализован принцип масштабирования ядер, то есть построения семейства ядер с различным набором предоставляемых функций. Смысл масштабирования вытекает из необходимости разрешить противоречие между требованием обеспечить максимальную реактивность СРВ и желанием в то же время предоставить пользователю разумный сервис. Предлагаемые решения совместить эти противоречия в одном ядре были проигрышными. Две различные задачи – обеспечение профессиональной среды в период разработки и реализация детерминизма, реактивности во время исполнения приложения, лучше всего решаются различными средствами. Ядро реального времени сознательно отказывается от поддержки среды разработки, сосредотачиваясь на временных критериях. Вся же нагрузка по предоставлению сервиса ложится на совершенно независимую часть системы, работающую в максимально приспособленной для этого операционной среде, не имеющей отношения к реальному времени. 
 
К достоинствам OS-9 можно отнести:

• Поддержка микропроцессоров серии Motorola, Intel 80386/486, Pentium, PowerPC.  
  Ценность ОС во многом определяется количеством поддерживаемых аппаратных платформ и качеством этой поддержки. OS-9 зародилась, как система для процессоров фирмы Motorola и почти целиком написана на ассемблере семейства Motorola 68k. Этим объяснялась и сложность её переноса на другие платформы и высокая эффективность на родственных процессорах. Появившееся в конце 90-х годов новое поколение высокоэффективных компиляторов языка С, способствовали переносимости на большинство других платформ.
• Переносимость широкого круга приложений.  
  Идеи, заложенные в систему, послужили исходным материалом при создании стандарта POSIX 1003. В настоящее время OS-9 поддерживает: ANSI C/C++, POSIX 1003.1, TCP/IP(NFS/RPC), Windows X11.R6(OSF Motif).
• Детерминированное, полностью вытесняемое ядро.  
  Ядро OS-9 является масштабируемым, полностью вытесняемым, поддерживает функционирование до 65535 процессов, предоставляет 65535 уровней приоритета и обеспечивает работу до 255 пользователей. Ядро OS-9 содержит более 90 системных вызовов, которые дают возможность управлять динамическим режимом диспетчеризации, распределением памяти, межпроцессорной коммуникацией и т.д. – вплоть до управления встраиваемым в ядро ОС режимом экономичного потребления питания. Характеристики производительности ядра: 5,6 мкс – время задержки прерывания), 14 мкс – время переключения контекста процесса (для процессора MC68040, 30MHz).
• Различные средства разработки  
  OS-9 предоставляет широкий набор средств разработки: локализованные (резидентные), удаленные (внешние), использующих принципиально отличные операционные среды. 
  Локализованные системы разработки функционируют в той же вычислительной среде, что и разрабатываемое приложение. Их достоинством является простота (следовательно, невысокая стоимость), быстрый переход от разработки к исполнению и наоборот, дополнительные возможности управления исполнением. 
  Удаленные (внешние) системы разработки – это и традиционные кросс-системы (такие, как PC-Bridge, работающая под управлением DOS, UniBridge , исполняющаяся в многопользовательской UNlX-среде) и профессиональные графические среды разработки ( такие как, FasTrak).
• Развитые сетевые средства
• Широкая поддержка разработчиков программного обеспечения и аппаратных средств промышленной автоматизации.  
  Семейство операционных систем реального времени OS-9 используются более 20 лет, число установленных копий превысило 5 миллионов. Спектр применений OS-9 широк – промышленная автоматизация, инструментальные и измерительные системы, системы военного и космического назначения. В последние годы она применяется в таких современных системах, как мобильные телекоммуникационные устройства, встраиваемые терминалы доступа в Интернет, интерактивные цифровые телевизионные приставки.

 

 

 

 

 

 

 

 

5 Примеры  реализации реального времени в универсальных ОС

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

Приложения  реального времени в ОС Windows NT

ОС семейства Windows – ОС “широкого назначения”. Однако разработчики стремятся задействовать  возможности Windows-систем для создания СРВ. Это объясняется следующим: 
- Программный интерфейс приложений (API) для Win32 известен большому числу программистов,  
- графический пользовательский интерфейс (GUI) стал настолько популярным, что другие ОС стараются обеспечить похожий интерфейс, 
- доступно большое количество драйверов устройств, 
- доступны многие мощные интегрированные среды разработки, 
- существует огромное число готовых приложений (в том числе, коммуникационных). 
 
ОС семейства Windows не могут служить хорошей платформой для приложений реального времени: слишком мало количество доступных приоритетов в классе реального времени; не решена проблема инверсии приоритетов; занимаемая память слишком велика для встраиваемых приложений.

Из приведенной  на рис 6 обобщенной структуры Windows NT видно, что расширения реального времени могут быть построены только на модификациях уровня аппаратных абстракций (HAL - Hardware Abstraction Level) и создании специфических драйверов. Изменять ядро Microsoft не разрешает, а исходный код HAL может предоставить своим партнерам на основе соглашения. Первый вход в обслуживание прерываний происходит именно на HAL-уровне, а единственной модифицируемой частью ядра являются драйверы устройств.

 
рис 6 Обобщенная структура Windows NT

 

 

 

 

 

Существует  несколько подходов к использованию Windows для создания СРВ. 
1. Модификация уровня аппаратных абстракций  
Одним из возможных решений является использование совместно с Windows NT подсистемы реального времени, исполняющейся на том же процессоре (если процессор один) или на выделенном процессоре(-ах) (если их несколько). Этот подход использован фирмой VenturCom в продукте RTX (Real Time Extension). Схема функционирования RTX в составе Windows NT представлена на рис.7. 
Сущность подхода заключается в использовании модифицированного уровня аппаратных абстракций HAL.

 
 
рис 7 Структура Windows NT RTX

Так как аппаратные прерывания на первом этапе обработки  попадают в HAL и затем передаются ядру, именно на базе HAL создан дополнительный диспетчер – диспетчер реального  времени. Новый HAL по прерыванию от часов реального времени передает управление этому планировщику, который следит за очередью задач реального времени, находящихся в системе и выделяет им время в соответствии с приоритетом. В RTX существует 128 фиксированных приоритетов для задач реального времени. Если в очереди таких задач нет, то управление передается стандартному планировщику Windows NT. В итоге получаем два, несвязанных между собой, набора приложений: стандартные приложения NT и приложения реального времени, управляемые HAL-диспетчером. Обеспечить взаимодействие специалисты VenturCom предлагают двумя способами: 
- используя разделяемую память: на рис.7 это взаимодействие показано стрелкой IPC (Inter Process Communication). 
- представляя систему реального времени, как устройство, которое обрабатывает специфический драйвер DD_Com (Device Drive Communication). (См рис.7). 
 
Времена исполнения кодов модифицированного и оригинального HAL совпадают, т.е. присутствие RTX не сказывается на производительности Windows в отсутствие процессов реального времени. К недостаткам относится возможность возникновения ситуации, когда процессы реального времени будут занимать все процессорное время, и Windows NT не получит управления и окажется подвешенной.