1.5 Требования, предъявляемые  ОС при проектировании  ОСРВ

1.5.1 Требование 1. ОС должна  быть многонитевой (multi-threaded) и прерываемой

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

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

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

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

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

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

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

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

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

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

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

1.5.5 Требование 5. Поведение  ОС должно быть  известно

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

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

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

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

2.1 QNX

Операционная  система QNX является разработкой канадской  компании QNX Software System Ltd (1981).

   Операционная  система QNX представляет собой гибрид 16/32-битовой операционной системы, которую  пользователь может конфигурировать по своему усмотрению. Наиболее часто она применяется для создания систем, работающих в реальном масштабе времени. Время, необходимое для полной инсталляции системы, включая сетевые средства, составляет всего 10-15 мин, после чего можно начинать работу. Нетребовательность системы к ресурсам проявляется уже в том, что система с необходимой и достаточной средой разработки в виде компилятора Watcom C/C++ (основной компилятор для QNX) умещается на 10 Мб.

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

   Эти идеи позволили добиться нескольких важнейших преимуществ:

• предсказуемость, означающая ее применимость к задачам жесткого реального времени. Ни одна версия UNIX не может достичь подобного качества, поскольку код ядра слишком велик. Любой системный вызов из обработчика прерывания в UNIX может привести к непредсказуемой задержке (как и в Windows NT);
• масштабируемость и эффективность, достигаемые оптимальным использованием ресурсов и означающие ее применимость для встроенных (embedded) систем. В каталоге dev присутствуют только необходимые для поставленных задач файлы, соответствующие нужным драйверам. Драйверы и менеджеры можно запускать и удалять (кроме файловой системы) динамически, просто из командной строки. Возможна также покупка только тех модулей, которые реально необходимы для обеспечения нужных функций;
• расширяемость и надежность одновременно, поскольку написанный драйвер не нужно компилировать в ядро, рискуя вызвать нестабильность системы.

 

   Система построена по технологии FLEET [Fault-tolerance (отказоустойчивая), Load-bаlаncing (регулирующая нагрузку), Еffiсiеnt (эффективная), Ехtеnsible (расширяемая), Тгаnsparent (прозрачная)], которая характеризуетмя следующим. QNX является ОСРВ на основе микроядра (размером около 10 Кб). В качестве основного средства взаимодействия между процессами система использует передачу сообщений. Благодаря этому в 32-битовой среде возможно взаимодействие процессов с 32 и 16-битовыми кодами, причем сообщения передаются между любыми процессами, независимо от того, находятся ли процессы на одном компьютере или на разных узлах сети. Пользователь, работая на одном из узлов сети, может иметь доступ к любым ресурсам остальных узлов, включая порты, файловую систему и задачи. Пользователю нет необходимости вникать в сетевой протокол, который, кстати, не является тайной, вплоть до его структуры. Он содержит пакеты, которые применяются и для передачи сообщений. Сетевой администратор распознает эти пакеты и переправляет микроядру, которое, в свою очередь, переправляет их в шину локальных сообщений. QNX распознает не только пакеты сообщений QNX-процессов. Можно также легко обращаться к сетевому администратору для передачи таких пакетных протоколов, как TCP/IP, 8MB и др. Возможно обращение к различным сетевым администраторам через один кабель.

   Операционная система QNX объединяет всю сеть ПК в единый набор ресурсов с абсолютной прозрачностью доступа к ним. Узлы могут добавляться и исключаться из сети, не влияя на целостность системы. Сетевая обработка данных в QNX является настолько гибкой, что можно объединить в одну сеть любой разнородный набор Intel совместимых компьютеров, соединенных через Arcnet, Ethernet, Token Ring или через последовательный порт, к которому также может быть подключен модем. Кроме того, возможно участие компьютера одновременно в нескольких сетях, и если одна из них окажется перегруженной или выйдет из строя, то QNX автоматически будет использовать другие доступные сети без потери информации.

   QNX имеет  некоторые ограничения, связанные  с ориентацией системы на рынок  встроенных систем реального времени:

• нет поддержки SMP;
• отсутствует запись виртуальной памяти на диск;
• неэффективная и нестандартная поддержка нитей;
• неполноценная реализация отображения файлов в памяти;
• нет поддержки UNIX-domain sockets;
• слабые средства безопасности в рамках собственного сетевого протокола.

 

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

2.1.1 Профессиональный  пакет

 

        В состав QNX входят графическая  оболочка Photon microGUI — полнофункциональная  и в то же время встраиваемая  оконная среда с расширяемой  подсистемой мультимедиа и поддержкой  аппаратно независимого многослойного  интерфейса. В её состав также включены масштабируемые шрифты и встроенная поддержка Unicode; широкий спектр файловых систем, включая образную файловую систему, файловую систему в ОЗУ или ППЗУ Flash, файловые системы QNX, Linux, DOS, CD - ROM, DVD, NFS, CIFS, пакетную файловую систему и файловую систему со сжатием; ядро с поддержкой SMP — стандартное микроядро можно заменить на SMP совместимое, предоставляющее настоящую поддержку тесно связанного SMP для многопроцессорных плат на основе MIPS, PowerPC и x 86; администратор систем высокой готовности поддерживает квитанции работоспособности для ранней диагностики отказов и предоставляет интеллектуальные механизмы перезапуска отказавших компонентов; поддержка Java две среды исполнения, оптимизированные для QNX: WebSphere Embedded Environment (стандарт Java Powered ) и WebSphere Custom Environment; POSIX API поддержка POSIX 1003.1-2003, включая многопоточность, расширения реального времени и множество других опций; стеки TCP / IP — встраиваемый стек, стек NetBSD или расширенный стек NetBSD с поддержкой IPSec и IPv6; отказоустойчивый сетевой интерфейс в QNX приложениях могут прозрачно взаимодействовать по резервированным сетевым соединениям. Если одно соединение нарушается, ОС автоматически перенаправит сетевой трафик по одному или нескольким альтернативным маршрутам. Поддерживается также балансировка нагрузки между всеми доступными соединениями для увеличения пропускной способности. Функции реального времени QNX обеспечивает быстрое, предсказуемое время реакции за счёт вытесняющего планирования, сверхмалых задержек обработки прерываний, распределённого наследования приоритетов и многих других реализованных в ней современных механизмов. В поставку профессионального пакета QNX Momentics входит всё, что необходимо на каждом этапе разработки системы, от встраивания на процессорную плату до системного анализа. Помимо графической IDE разработчики могут использовать и обычный командностроковый инструментарий, получая абсолютно такие же бинарные модули и контекст. QNX Momentics обеспечивает разработчикам свободу выбора инструментария разработки, так как его интегрированная среда основана на Eclipse — открытой платформе, поддерживаемой большим и постоянно расширяющимся сообществом компаний производителей. Eclipse также предоставляет расширяемую архитектуру подключаемых модулей, позволяющую QNX Momentics работать с практически любым типом информационного содержания. Например, в состав QNX Momentics входит множество подключаемых модулей для разработки и анализа встраиваемых образов, исходных текстов на C/C++ и прочих объектов, характерных для встраиваемых систем. Поддержка множества языков программирования ( C, C++, встраиваемый C++ или Java ), инструментальных ОС ( Windows, Solaris или QNX ) и целевых процессоров (ARM, MIPS, PowerPC, SH -4, StrongARM, XScale или x86) позволяет существенно сократить время разработки проекта независимо от его масштаба и сложности.  

Средства разработки кода QNX Momentics включают в себя:

• «мастера» проектов,
• редакторы кода,
• средства управления исходными текстами,
• средства построения проектов.

 
 

QNX Momentics поддерживает  большое количество широко распространённых  библиотек, включая 

• ANSI C,
• POSIX,
• Dinkum C++, полная версия,
• Dinkum C++, встраиваемая версия с сокращенной STL ,
• GNU C++ (только для x86),
• сжатие,
• сеть,
• графика,
• виджеты,
• XML.

 

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

• GCC v2.95x, GDB v5.x,
• LD v2.10.x, поддерживается эмуляция: i386nto, armnto, elf32bmpinto, elf32ppcnto, shielfnto,
• MAKE v3.79x,
• JDK 1.3 совместимый Java компилятор (с поддержкой инкрементной компиляции для увеличения производительности больших проектов).

 

   IDE включает  в себя встроенную поддержку  протокола управления исходными  текстами CVS включая поддержку удалённого  сервера и доступ к защищенным  репозитариям посредством sSh. Также поддерживается система управления исходными текстами ClearCase, поставляемая компанией Rational Software в виде подключаемого модуля для Eclipse.  

Возможности:

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

 

   Используя PhAB™, визуальное средство разработки приложений QNX Photon microGUI®, можно создавать полнофункциональные пользовательские интерфейсы с простотой щелчка мыши. Возможности PhAB™ включают в себя:

• готовые шаблоны PhAB;
• обширная палитра доступных элементов управления (виджетов);
• привязка к виджетам диалоговых окон или вызовов функций (предопределенные, по «горячей» клавише или по низкоуровневым событиям);
• полная поддержка со стороны интегрированной среды QNX Momentics;
• минимизация кода;
• многоязычная поддержка.